The implementation of a Unified Namespace architecture requires a well thought-out design. A central aspect is the selection of components for system integration, microservices and the message broker. However, not only the selection is crucial for successful scaling. But also the question of the level in the IT/OT architecture at which the components are installed and operated (hosting level). A common question here is which hosting level is optimal for the message broker. This article therefore highlights the guiding principles for selecting the optimum level – store floor, edge or cloud.
Broker Hosting Options in the Unified Namespace (UNS) Architecture
In principle, the broker can be installed and operated at any level of the IT/OT architecture. From machine control (e.g. possible in CtrlX from Bosch Rexroth) to the cloud (e.g. Microsoft Azure). When selecting the optimum level, the following rule of thumb applies: The hosting level – whether cloud, virtual or physical edge – should be selected as high as possible and as low as required. This keeps the infrastructure flexible and adaptable while at the same time enabling a scalable implementation of the UNS architecture. This decision always depends on the requirements of the specific use-case and the desired functionality. The following guiding principles apply.
Guiding Principle No. 1: Balance between Standardization and Individuality
Even though standardization is preferable on enterprise level, factories retain a degree of individuality that needs consideration in the UNS design. Factories within the same company often exhibit unique setups, such as unique OT/IT system landscapes, value stream organization, and current market challenges. Consequently, companies lean towards enterprise-wide standardization for as many use-cases as possible while allowing individual use-cases to address specific factory needs. This philosophy also characterizes the UNS design. This is because the modular and distributed architecture enables individual and at the same time scalable implementation. Components such as the Message Broker are often installed multiple times on different architectural levels – wherever they are needed. This distributed broker architecture supports both individual factory use-cases (Factory UNS) and company-wide use-cases (Enterprise UNS). The brokers are connected to each other via so-called bridges in order to synchronize relevant data and events in real-time.
Guiding Principle No. 2: Balance between Latency and Scalability
As a rule of thumb, placing the i-flow broker closer to the shop floor enhances low-latency communication, while positioning it higher in the architecture enhances scalability (for detailed information, refer to the next section). Manufacturing use-cases typically span both ends of this spectrum, leading to the implementation of local i-flow brokers (e.g., factory UNS) that are passed up to higher level i-flow brokers (e.g., enterprise UNS). In highly distributed setups, you might even encounter multiple local i-flow brokers at each production line, production area, or factory.
Broker Hosting: Physical vs. Virtual Edge
While the scalability advantage of the cloud is widely recognized, the advantage and disadvantage of a physical edge (e.g., e.g. hosting on central line server or industrial PCs) and a virtual edge deployment (e.g., virtual machines in a data center) may not. Especially in production, where industrial devices generate large amounts of data, it is crucial to minimize latencies, enable fast reactions to critical events and aggregate high-frequency machine data for processing in IT systems. This is exactly what hosting on the edge is predestined for. In general, the advantages of edge hosting for industrial IoT use-cases are:
- Decentralized Data Processing: Data processing and aggregation closer to its source (e.g., to align OT data frequency with IT system capabilites).
- Saving Bandwidth and Cloud Costs: Less data transfer to the cloud.
- Faster Response Times: Critical processes benefit from minimal latency.
Physical Edge Advantages
- Data Preprocessing: Reduce network load through local data preprocessing close to the production line.
- Closed Loops: Achieve lower latency ( < 10ms) by running control loops (e.g. analytical algorithms) directly on physical edge devices.
- Offline Scenarios: Operate seamlessly without data center connectivity.
- Security: Translate non-secure protocols to secured ones (e.g., for PLCs lacking support of encryption).
Virtual Edge Advantages
- Higher Availability: Virtual machines (VMs) offer enhanced availability.
- Better Scalability: VMs provide better scalability, particularly for large-scale operations.
- Lower Operational Costs: Reduce operational costs without additional hardware and wiring in the cell.
Getting Started in the Unified Namespace Architecture
To strike a balance between efficiency and system complexity, many customers start their broker deployment at a level aligned with the requirements of the initial use-cases. As your industrial ecosystem evolves, adapt your broker network accordingly. Introduce new i-flow brokers to accommodate additional use-cases. A common progression involves starting with a broker at the virtual edge level. Later, during expansion across multiple factories, you can consolidate all local i-flow UNS instances into a centralized broker for an enterprise-wide UNS structure.
Conclusion
The optimal hosting level for the message broker is a decisive factor for the success of a UNS architecture. With the guiding principles – the balance between standardization and individuality as well as between latency and scalability – a flexible and future-proof infrastructure can be created that meets both local and company-wide requirements.
