Technology
What we work with, and how the boundary is drawn
This page exists for the engineer who has been asked to evaluate us. It is a list of what we actually read, write, program and integrate — and, more importantly, how the control network is kept separate from everything else.
Industrial protocols
What we speak on the plant side. Chosen per installed base, not per preference.
- Modbus TCP
- Modbus RTU
- OPC UA
- OPC DA
- MQTT
- Sparkplug B
- Ethernet/IP (CIP)
- Profinet
- Profibus
- Siemens S7 comms
- EtherCAT
- IO-Link
- BACnet
- IEC 61850
- DNP3
- Serial RS-232/485
Controllers & panels
Platforms we program, migrate and integrate.
- Siemens S7-1200 / 1500
- Siemens S7-300 / 400
- TIA Portal
- STEP 7
- Allen-Bradley CompactLogix / ControlLogix
- Studio 5000
- MicroLogix / SLC
- Mitsubishi FX / Q / iQ-R
- GX Works
- Delta
- Schneider M221 / M241 / M580
- Omron CP / CJ / NX
- Fatek
- Wecon
HMI & SCADA
Supervisory and operator interface platforms.
- Siemens WinCC
- WinCC Unified
- AVEVA / Wonderware InTouch
- AVEVA System Platform
- Ignition
- FactoryTalk View SE / ME
- GE iFIX
- Weintek
- Delta HMI
- Mitsubishi GOT
- Web-based HMI
Edge & gateways
Where protocol conversion, buffering and local logic happen.
- Industrial DIN-rail gateways
- Fanless industrial PCs
- Node-RED
- Custom edge services
- Store-and-forward buffering
- Local dashboards
- Remote fleet management
- Dual-NIC network segregation
Instrumentation
What we fit when a machine exposes nothing.
- Current transformers
- Energy meters
- Triaxial vibration (MEMS / IEPE)
- RTD / thermocouple
- Proximity & photoelectric
- Pressure & flow transmitters
- Level sensors
- Temperature & humidity
- Ultrasonic leak detection
- Barcode / QR / DMC / RFID
Data & platform
Where the data lands and how it is served.
- PostgreSQL
- TimescaleDB
- InfluxDB
- SQL Server
- Redis
- MQTT brokers
- Kafka / AMQP
- Docker
- On-premises deployment
- AWS / Azure / GCP
- Grafana
- REST / OpenAPI
- WebSockets
Software engineering
What the applications are built with.
- TypeScript
- Next.js
- React
- Node.js
- Python
- React Native
- Progressive Web Apps
- OpenAPI contracts
- Role-based access control
- Audit logging
- CI/CD
- Automated testing
Business systems
What we integrate with, through supported interfaces.
- SAP (IDoc / BAPI / OData)
- Oracle
- Microsoft Dynamics
- Tally
- Indian mid-market ERPs
- MES platforms
- CMMS / EAM
- LIMS & quality systems
- Power BI
- Weighbridge & third-party systems
Security
Six principles we do not negotiate on
These are the questions your IT and safety functions will ask. Here are the answers before they ask them.
- 01
The control network is never exposed
Monitoring and integration devices are dual-homed with no routing between the OT and business networks. Connections are initiated outward only. This follows the Purdue model and is normally what your IT and safety functions require anyway.
- 02
Read-only by default
Data collection is read-only unless writing is an explicit, agreed part of the scope. Where a write path exists, it is separately authenticated, rate-limited and logged.
- 03
Encrypted transport, authenticated devices
TLS on all northbound transport, with client certificates for device identity rather than shared credentials. Certificates are rotatable without a site visit.
- 04
Least privilege and audit
Role-based access with segregation of duties, and an immutable audit log recording who changed what, when, and what the previous value was.
- 05
Your infrastructure, your credentials
Systems run in your cloud account or on your servers. You hold the credentials. We do not retain standing access after handover unless a support arrangement specifically provides for it, and that access is logged.
- 06
Failure is designed for
Buffering on link loss, idempotent writes so retries are safe, dead-letter handling, and alerting when a data flow stops. A silent integration failure is worse than no integration.
What comes next
From connected machines to intelligent decisions
AI is not our identity and it is not a starting point. It is a layer that becomes useful once there is enough clean, contextualised industrial data underneath it — which is exactly what the rest of this work produces. Applied before that, it produces confident output from bad inputs.
We will tell you when a problem does not need machine learning. Most of the value in a plant's first two years of digitalisation comes from measuring things accurately and showing them to the right person quickly. That is unglamorous and it is where the return is.
Anomaly detection
Detecting behaviour that deviates from a machine's own learned normal, across many signals at once — useful once there is a year of history including real failures.
Predictive maintenance models
Moving from threshold and trend detection to model-based remaining-life estimation, on assets where the failure history supports it.
Production forecasting
Short-horizon output prediction from current state, order mix and historical performance, to support scheduling decisions during the shift rather than after it.
Energy optimisation
Identifying consumption patterns and load-shifting opportunities from measured per-asset data and tariff structure.
Natural-language plant queries
Asking a question of your plant data in plain language instead of building a report — genuinely useful, and only trustworthy when the underlying data model is sound.
AI-assisted troubleshooting
Surfacing similar past events, their causes and their resolutions when a fault occurs, from your own maintenance history.
Questions
Technical questions we get asked
OPC UA or MQTT — which should we use?
They solve different problems and are frequently used together. OPC UA is a typed, self-describing, session-based protocol, ideal between controllers and supervisory systems inside the plant. MQTT is a lightweight publish/subscribe transport, ideal for getting data out of the plant over an unreliable link. A very common architecture is OPC UA from the PLC to the gateway, and MQTT with Sparkplug B from the gateway northward.
Why Sparkplug B rather than plain MQTT?
Plain MQTT gives you a transport but no conventions: no agreed payload format, no way to discover what a device publishes, and no way to distinguish 'nothing has changed' from 'the device is dead'. Sparkplug B adds a defined payload, birth and death certificates, and state awareness — so a silent device raises an alarm instead of looking healthy.
Do you need to open a firewall port into our plant?
No. Every connection is initiated outward from the plant. There is no inbound port, no port forwarding and no exposed service on the OT network. Where remote support access is required, it is through an explicitly agreed, authenticated and logged mechanism that you can revoke at any time.
Can everything run on-premises with no cloud at all?
Yes. Gateway, database, dashboards and alerting can all run on a server inside your plant, with no external connectivity. Many plants start this way. The trade-off is that multi-site consolidation and remote access become your infrastructure problem rather than ours, which is often exactly what a customer wants.
What happens to the system if we stop working with you?
It keeps running. You hold the credentials, the infrastructure and the source code, and the documentation is written so another competent team can take it over. We use mainstream technologies for exactly this reason. We would rather earn renewal than rely on lock-in.