Build
Industrial system integration — making the plant and the business agree
Most plants do not have a data problem. They have a boundary problem: the PLC knows, the SCADA knows, the ERP does not, and a person in the middle re-types numbers from one into the other every day. We design and build those boundaries properly, with error handling, monitoring and documentation.
The problem
The integration that is actually a person
Between every two systems in most plants there is someone with a spreadsheet reconciling them. It works, in the sense that the business functions. It also means every number is a day old, every discrepancy is discovered late, and the whole arrangement depends on one person not taking leave.
- 01
Production figures re-keyed from SCADA into the ERP
- 02
Plant and finance quote different output numbers for the same period
- 03
Material consumption is booked from a standard rather than from actual usage
- 04
An integration exists but fails silently and nobody notices for days
- 05
Every new system means another point-to-point connection to maintain
What we build
Concrete deliverables
Nouns, not adjectives. This is what actually gets handed over.
- 01
Integration architecture
A designed landscape rather than accumulated point-to-point links — with a defined data flow, ownership per data object, and a single path per direction.
- 02
OT/IT boundary design
Network segmentation, a controlled data path out of the control network, and an interface that does not require exposing plant systems.
- 03
ERP integration
Production confirmations, material consumption, quality results and downtime posted into SAP, Oracle, Dynamics or your mid-market ERP through supported interfaces.
- 04
MES and quality system integration
Two-way flow of orders, recipes, results and genealogy between plant execution and business systems.
- 05
Legacy system integration
Getting data out of systems with no API — via database reads, file drops, screen data or protocol adapters — safely and reversibly.
- 06
Monitoring and error handling
Every interface monitored, with retries, dead-letter handling, and alerts when a flow stops. A silent integration failure is worse than no integration.
How it works
The technical path, step by step
Where the engineering decisions actually get made.
- 01
Map what exists
Every system, every current data flow including the manual ones, and who owns each data object. The manual flows are the requirement.
- 02
Define the contracts
For each interface: the data, the direction, the trigger, the frequency, the format, the error behaviour and the owner. Written down and agreed.
- 03
Design the boundary
Segmentation, authentication, direction of initiation, and audit. Plant systems are never exposed directly to business networks.
- 04
Build and test with real failure
Tested with the target system down, with malformed data, with duplicates, and with a network partition — because all of those will happen.
- 05
Monitor from day one
Dashboards for flow health, alerting on stoppage or backlog, and a documented runbook for each interface.
Protocols & technologies
Specifics, because vague answers cost you money later
Chosen per site according to what is installed, not according to what we would prefer to work with.
| Technology | Where it is used | Engineering note |
|---|---|---|
| OPC UA | The clean OT-to-IT boundary | Typed, secure, and the right answer where both sides support it. |
| REST / OpenAPI | Modern system-to-system | Versioned contracts, idempotent writes, proper status semantics. |
| SAP IDoc / BAPI / OData | SAP integration | Chosen with your basis team; we work to their standards rather than inventing a path around them. |
| Message queue (MQTT / AMQP / Kafka) | Decoupling and buffering | So a downstream outage becomes a backlog rather than data loss. |
| Database views / staging tables | Legacy systems with no API | Read-only views wherever possible; never writing directly into another system's tables without its owner's agreement. |
| File-based (CSV / XML) exchange | Older systems and third parties | Still common, still workable, with checksums, ordering and idempotency handled properly. |
| SFTP / secure transfer | Inter-organisation exchange | With monitoring, because file-drop integrations fail quietly by nature. |
Brownfield
Integrating systems that were never designed to be integrated
Much of this work involves systems with no API, no documentation and no vendor support. There is almost always a safe path — a read-only database view, an export the system already produces, a protocol adapter, or a screen-level interface — and part of our job is finding the one that does not put the source system at risk.
Works with
- SAP, Oracle, Dynamics, Tally and Indian mid-market ERPs
- SCADA historians of any vintage
- Legacy applications with no documented interface
- Third-party laboratory, weighbridge and quality systems
- Customer and supplier portals requiring scheduled exchange
Use cases
What people actually ask us for
Each one is a situation followed by the outcome it produces — not a feature list.
Automatic production confirmation
NowProduction is confirmed in the ERP by hand from a printed sheet.
AfterConfirmations posted from measured machine data, with exceptions flagged for review rather than everything requiring it.
Actual material consumption
NowConsumption is backflushed from a standard that is known to be wrong.
AfterActual usage captured at the line and posted, revealing real yield.
Order status to customers
NowCustomers call to ask where their order is.
AfterLive status derived from production data, exposed through a portal or an API.
Consolidating multi-plant reporting
NowEach site reports differently on a different day.
AfterOne data model, automated collection, and a group view that reconciles to each site.
Rescuing a failed integration
NowAn existing interface breaks regularly and silently.
AfterRebuilt with idempotency, retries, monitoring and alerting, plus a runbook for when it does fail.
Implementation
How a project runs
Eight stages, each producing something you own. Full detail on the process page.
- 01
Discover
1–2 conversations
- 02
Audit
1–3 days on site
- 03
Design
1–2 weeks
- 04
Engineer
2–8 weeks per phase
- 05
Integrate
1–2 weeks
- 06
Deploy
Your shutdown window
- 07
Monitor
First 4–6 weeks
- 08
Optimise
Ongoing, if you want it
Mixed-vendor machine monitoring rig
Three PLC brands and one machine with no controller at all, read through one gateway and normalised into a single tag model — the situation almost every Indian plant is actually in.
Read the write-upQuestions
System Integration — common questions
Is it safe to connect plant systems to the business network?
Not directly, and we do not do it that way. The standard arrangement is a segmented boundary: an edge or integration service sits between the two, initiates connections outward only, and exposes a defined interface. The control network is never directly reachable from IT, and the flow is auditable. This follows the Purdue model and is normally what your IT and safety functions will require anyway.
Our ERP vendor says integration is not possible.
That usually means it is not possible in the way it was asked for, or not within their support scope. There is nearly always a route — a supported interface, a read-only database view, a scheduled export. We work with the ERP partner rather than around them, because an unsupported integration that voids your support contract is not a solution.
How do you handle an integration failing at 2am?
By designing for it. Messages are queued rather than dropped, writes are idempotent so retries are safe, failures go to a dead-letter queue and raise an alert, and each interface has a runbook describing how to recover. The goal is that a failure becomes a backlog that clears itself, and a person is only involved when it does not.
Should we buy an integration platform?
Only if you have enough interfaces to justify it. For a handful of flows, a well-built service with proper monitoring is simpler, cheaper and easier to reason about. Once you are past roughly a dozen interfaces across multiple systems, a platform starts earning its licence cost. We will tell you which side of that line you are on.
Can you integrate without disturbing the existing systems?
In most cases, yes. We read rather than write wherever possible, use interfaces the vendor supports, and test against a copy before touching production. Where a write into a third-party system is genuinely required, we get that system's owner involved before doing it — never after.
Where is the person in the middle?
Show us the spreadsheet that reconciles two systems. That is where the integration belongs.