Category: System Integration & Architecture

Seven Machines, Seven Dialects

Order seven machines from seven suppliers and require OPC UA on all of them. You will get it – together with seven different information models. The same physical quantity is called Prod_Count in one machine, TotalCount in the next and stCounter.iGood in the third. One reports temperature in Celsius, another in tenths of a degree as an integer. Three different state machines describe “running”, “waiting” and “fault” in three incompatible ways.

All seven are protocol compliant. None of them is comprehensible to the others. This is the core problem of industrial integration: protocol compliance guarantees nothing about semantics. And every time a new machine is purchased, you pay the interpretation work again – in integration hours, in troubleshooting, in reports that do not add up.

Why “Connect Everything” Is Not Enough

The Unified Namespace (UNS) has become industry’s answer to the integration problem: an event-driven namespace where all systems publish and consume through a common hub instead of point-to-point connections. The pattern is sound – we use it ourselves. But in its popular form it has two weaknesses.

First: most UNS initiatives connect sources as they are and contextualise in the middleware. The namespace becomes a landfill with a good search function – the cleanup cost has moved, not disappeared, and it returns with every new source. Second: a single flat namespace where “everyone sees everything” means, in practice, that the cloud can see the valve. That is unnecessary architecturally and hard to defend from an IEC 62443 perspective.

The Model: Three Concepts

1. The Machine Interface Data Contract – Level 1.5

Normalisation must happen where the buyer’s leverage is: in procurement. A machine interface data contract specifies what data the machine must expose at its boundary – identities, states, tags, units, quality flags, update rates – and the acceptance criteria tested at delivery. The machine remains the supplier’s black box below the boundary: control loops and safety are never touched. But the data interface is yours.

The pattern is proven: the Weihenstephan Standards are in effect a machine interface contract for the food industry, OMAC PackML standardises state machines, and OPC UA companion specs do the same per industry. What is new is making it the owner’s general practice – with a delivery test as the condition for approval.

2. UNS-O – The Operational Namespace

UNS-O is the facility’s real-time namespace at levels 2-3: structured along ISA-95, identified per IEC 81346, assembled from sources that already meet their contracts. There, seven machines become seven instances of one type – and machine number eight costs almost nothing to connect. The technology can be OPC UA, MQTT or both; the pattern is the same.

Crucially: domains are branches in the namespace, not architectures of their own. An air handling unit is “machine number eight” – the same contract logic applies to facility and energy as to production. Giving each discipline its own namespace would recreate the silos one level up.

3. UNS-E – The Enterprise Namespace

The enterprise level wants answers, not raw signals. UNS-E is a governed projection of UNS-O: the same objects, the same identity (1:1 through reference designations), but aggregated, schema-controlled and curated. Publication is unidirectional by default and crosses a defined zone boundary – which makes the two-tier model a security argument, not just an architectural preference.

This is where the multidisciplinary value appears: an energy analysis can connect a compressor’s consumption to both the production order and the building’s operating mode, because production, facility and energy data share one identity backbone. For facility-domain semantics, ready-made vocabularies exist in RealEstateCore and Brick Schema.

What It Takes to Hold

Identity ownership: the 1:1 mapping between the tiers is master data and needs designated ownership. Data contracts at every boundary: the machine boundary and the UNS-O/UNS-E boundary – both with schemas, units and version control, documented as data mapping. Honesty about the facility side: BMS suppliers are less used to interface contracts than machine OEMs, and BACnet semantics are weaker than OPC UA companion specs. That is not a reason to refrain – it is the reason to set the requirement.

How to Start

1. Define a canonical information model for your most common machine type. 2. Put the interface contract with acceptance criteria into your next procurement. 3. Establish the UNS-O structure (ISA-95 hierarchy, 81346 identities) with the first contracted sources. 4. Project the first curated objects into UNS-E when a real consumer exists – not before. The model is built in the order the value appears.

MQTT: From Niche IoT Solution to Strategic Backbone of Modern Automation

In recent years, MQTT (Message Queuing Telemetry Transport) has evolved from a smart solution for individual IoT sensors to become one of the most important components in modern building and industrial automation. We are now seeing a clear shift in how the technology is used: from being something managed out at the “edge” of systems, MQTT is beginning to move into the very core of the facility’s IT infrastructure.

The Power of Lightning-Fast Deployment

When discussing the advantages of MQTT, we often end up in technical details, but we frequently forget the purely commercial gain: speed. Thanks to modern brokers such as EMQX, we have seen how you can go from drawing board to a fully functional infrastructure for an entire factory in record time.

In traditional systems, it often takes weeks or months to configure each individual node and ensure they communicate with each other. With a cloud-based or clustered MQTT solution, we are talking about minutes to set up the hub itself. For a facility owner or industrial manager, this means you can scale up from a pilot in a small plant room to covering an entire property portfolio or production line without having to rebuild the architecture from scratch.

The Problem of the Fragmented Facility

Traditionally, both building and industrial automation have been built in closed verticals. Each system – cooling, heating, lighting, production lines – has often had its own logic and its own proprietary protocols. The result has been an unmanageable tangle of integrations where data lives in isolated silos.

By elevating MQTT to a central service, we change the game. Instead of each device sending data to a local node that may then communicate with the cloud, we create a shared information bus. Here the MQTT broker becomes the central hub where all communication meets. This provides unmatched scalability: once the infrastructure is in place, it does not matter whether you add ten or ten thousand new sensors – the architecture remains the same.

Real IT/OT Convergence

One of the greatest gains from a centralised MQTT service is that we finally begin to speak a language that the IT department understands and accepts. Historically, the gap between operational technology (OT) and IT has been large, but MQTT’s lightweight nature and its ability to easily integrate with modern analytics tools and business systems (ERP, MES) bridges this gap.

When data flows centrally through a broker, it suddenly becomes available to the entire organisation. The facility owner can leverage real-time data for predictive maintenance, while the finance department can get exact energy consumption figures directly into their systems. We are now seeing solutions that handle over 100 million simultaneous connections – a level of future-proofing that traditional BMS systems have never come close to.

The Challenges We Cannot Ignore

But centralisation also comes with greater responsibility. When MQTT is made the heart of the facility’s operations, entirely different demands are placed on network robustness. We leave the “playground” stage and enter critical infrastructure:

• Security as a foundation: Simple passwords are no longer sufficient. A centralised environment requires a well-thought-out security strategy with TLS encryption and certificate management (CA). Every device that connects must be who it claims to be.
• Redundancy and reliability: If the central broker goes down, the facility must not stop functioning. Therefore we increasingly see implementations with clustered brokers and advanced failover mechanisms, built to withstand outages without losing critical data.
• Structure through Sparkplug: A common pitfall with MQTT is that data becomes unstructured – values are sent without context. Sparkplug B addresses this by ensuring all devices in the network understand each other’s data directly, a prerequisite for true interoperability.

Future Outlook

We are moving away from the era of buying “finished packages” where hardware and software are locked together. Tomorrow’s BMS and SCADA are software-defined, flexible and data-centred. By investing in a robust, centralised MQTT infrastructure, you lay the foundation for a facility that is not only smart today, but ready for technologies we have not yet even glimpsed.

MQTT is no longer just a protocol for small sensors – it is the foundation for how we will manage and optimise our buildings and production facilities for decades to come.

Are you ready to make MQTT the hub of your system?

Moving from local edge solutions to a centralised MQTT infrastructure requires the right planning around security, redundancy and network capacity. We help you navigate from strategy to operational solution.