Many factories, utilities, warehouses and process plants in Malaysia and Singapore already have working PLCs, SCADA systems, historians, meters, drives and packaged equipment. The problem is rarely a complete lack of data. More often, useful data is trapped inside legacy OPC DA servers, proprietary drivers, isolated HMIs and inconsistent tag structures.
Replacing a functioning control system simply to make data available to MES, OEE, energy analytics, AI, digital twins or cloud applications is usually unnecessary and carries operational risk. A better engineering strategy is to preserve the proven control layer, introduce a controlled edge integration layer, normalise the data, and expose only the information that higher-level applications actually need.
The real problem is not connectivity
Brownfield integration often starts with a request such as “connect all PLC data to the cloud” or “feed the SCADA data into AI”. That sounds straightforward until the site contains several PLC generations, OPC DA, Modbus TCP/RTU, BACnet, vendor-specific Ethernet protocols, serial devices and manually maintained tag names.
A protocol converter may prove that a value can be read. That is not the same as creating maintainable industrial data. The engineering questions are whether each value has the correct timestamp, quality state, units, scaling, asset identity, source ownership, security boundary and lifecycle definition.
This is why CANS treats brownfield digitalisation primarily as an architecture and data-governance problem rather than a protocol-conversion exercise.
Why OPC UA is the natural migration layer
The OPC Foundation explicitly defines OPC UA as a migration path from OPC Classic, including OPC DA, HDA and A&E. Existing information exposed through OPC Classic servers can be mapped into OPC UA, either by native migration or through wrappers and gateways.
That makes OPC UA particularly useful in brownfield plants because it does not require every legacy PLC or SCADA package to be replaced at once. OPC UA also provides a common information model, structured address space, data quality, events, methods and a platform-independent security architecture.
The practical implication is simple: keep the legacy control system where it still performs reliably, but create a modern northbound information interface around it.
Where MQTT fits — and where it does not
MQTT is useful when industrial information must be distributed efficiently across edge, IT and cloud environments. OPC UA PubSub supports broker-based mappings including MQTT, allowing publishers and subscribers to remain decoupled.
The OPC Foundation Cloud Initiative now explicitly addresses interoperable edge-to-cloud architectures, while its June 2026 Cloud Corner identifies OPC UA Client/Server or OPC UA PubSub over MQTT as a preferred northbound interface for scalable asset onboarding into cloud, digital-twin and AI applications.
However, MQTT by itself does not create semantics. A broker carrying badly named tags is still carrying badly named tags. It also does not decide which PLC is the authoritative source, what engineering unit a value uses, or whether a stale value is safe to consume.
For scalable projects, MQTT should therefore be treated as a transport mechanism within a wider information architecture, not as a substitute for one.
A practical brownfield architecture
A typical staged architecture is:
Existing PLCs / drives / meters / packaged equipment → existing SCADA or direct protocol access → edge integration layer → normalised OPC UA information model → optional MQTT / historian / API distribution → MES, OEE, AI, energy analytics, CMMS, digital twin or cloud.
The edge layer should be engineered as a controlled boundary. It needs configuration management, logging, time synchronisation, diagnostics, certificate management, buffering or store-and-forward where justified, and clear ownership for every data object.
It should not become a collection of undocumented scripts that only one engineer understands.
What should remain inside the control network?
Closed-loop control, interlocks, trips, safety functions and time-critical sequencing should normally remain in the appropriate PLC, DCS or safety-controller architecture. Higher-level software should initially consume plant data read-only.
Write-back from optimisation or AI should only be introduced for defined use cases, through bounded setpoints, permissives, role-based access and tested fallback behaviour. A cloud outage, broker failure or WAN interruption must not stop the production line or utility process.
Selection matrix for Malaysian and Singapore plants
| Situation | Recommended approach | Avoid |
|---|---|---|
| Reliable legacy SCADA with OPC DA | Bridge or wrap OPC DA to OPC UA while retaining the SCADA control role | Full rip-and-replace solely for connectivity |
| Several PLC brands and protocols | Use an edge integration layer with protocol abstraction and a common namespace | Separate custom integration for every consuming system |
| Need AI, digital twin or cloud access | Expose a curated OPC UA/MQTT data model northbound | Sending the raw PLC address space directly to cloud applications |
| Intermittent WAN connectivity | Use local buffering and keep plant operation independent of WAN availability | Cloud-dependent control logic |
| Multiple analytics consumers | Use PubSub or brokered distribution where it genuinely reduces coupling | Duplicating point-to-point polling connections |
| Future MES/OEE/CMMS integration | Define asset hierarchy, equipment IDs and tag naming before scaling | Allowing every project to invent a new tag model |
| Write-back from optimisation or AI | Introduce only after read-only validation, with bounded setpoints and rollback logic | Direct unrestricted writes from analytics applications |
Seven checks before implementation
- Inventory the real data sources. List PLCs, SCADA servers, OPC servers, meters, drives, controllers, serial networks and vendor gateways before designing the target architecture.
- Identify authoritative ownership. Decide whether each important value should come from the PLC, SCADA, historian or another source.
- Normalise engineering context. Units, scaling, quality, timestamp, equipment hierarchy and tag naming must be explicit.
- Separate control from information flow. Keep time-critical control local and make higher layers supervisory unless the project specifically requires otherwise.
- Design cybersecurity at the boundary. Use network segmentation, least privilege, certificate management and defined inbound/outbound communication paths.
- Plan for degraded communications. Test broker loss, WAN loss, stale data, restart and reconnect behaviour.
- Commission abnormal states, not only normal states. Bad quality, duplicate timestamps, communication loss and recovery are part of the system behaviour.
Do not lift every tag just because you can
It is tempting to expose every SCADA or PLC tag because storage is cheap and future analytics may appear to need everything. In practice, this creates noise, weak ownership and unnecessary cybersecurity exposure.
A better approach is to define the business and engineering use cases first, then publish a curated set of signals with stable names and clear context. Additional data can be added deliberately as the use cases expand.
Where CANiS and CansNEXUS fit
CANiS Integration Server can provide integration and middleware functions where structured operational data has to move between plant and enterprise systems. CansNEXUS can sit above the integration layer for dashboards, industrial intelligence, digital twins, AI, analytics and cross-system visibility.
The objective is not to force a functioning plant to be rebuilt for the sake of digitalisation. The objective is to expose the right information safely and modernise progressively.
In a brownfield plant, I would leave reliable control alone. Build a clean integration boundary around it, sort out the data model, then add MES, AI or digital-twin functions in stages. Getting a value onto a dashboard is easy. Making the integration understandable and maintainable five years later is the harder part.
CAN Technology Watch — 4 September 2026
CAN in Automation’s current September 2026 technical focus is heavily centred on CAN FD: CAN SIC transceivers, bit-timing, SocketCAN tooling, CAN-FD-to-Ethernet gateways and CAN FD applications are all prominent. CiA is also highlighting CANopen integration into ROS 2 and continuing CANopen FD specification work.
The latest CAN Community News No. 11 reports that CiA 1302-1 and CiA 1302-2 for additional CANopen FD application-layer functions have been finalised and entered the internal document-quality process. The same update calls for experts to complete revised CiA 404 measuring-device specifications, including CANopen FD parameter mapping, and notes that future J1939-21/J1939-22 issues will harmonise transport-layer terminology.
For mixed CAN/Ethernet architectures, products such as the Ixxat CAN@net Basic illustrate the continuing practical need for CAN/CAN FD-to-Ethernet gateways, filtering and mapping. Kvaser continues active CAN XL development while supporting established CAN and CAN FD engineering workflows.
For machine builders, the design lesson is similar to brownfield SCADA integration: avoid unnecessary point-to-point coupling. Keep protocol boundaries explicit, use gateways deliberately, and maintain a data model that can survive the next network-generation change.
Conclusion
Brownfield digitalisation does not require a choice between “do nothing” and “replace everything”. A staged OPC UA, MQTT and edge-integration architecture can protect existing control investments while creating a cleaner path to MES, OEE, energy optimisation, predictive maintenance, AI and digital twins.
If your plant has legacy OPC DA, mixed PLC brands, isolated SCADA systems or operational data that is difficult to reuse, CANS can assess the existing architecture and define a practical migration path. Review CansNEXUS Industrial Intelligence, CANiS Integration Server or contact CANS to discuss a brownfield integration project.
Recent Comments