Essential Characteristics of a UNS Architecture in a Life Sciences Manufacturing Facility

A UNS (unified namespace) architecture is a scalable and effective connectivity and data integration solution for operational technology (OT) systems and equipment.

It is ideally suited for manufacturing facilities in the life sciences sector, not least because of its adaptability and flexibility. The ability to integrate legacy platforms and systems into a UNS architecture also enhances its suitability in the life sciences sector. 

Various components are required to develop a UNS architecture. They include: 

• Broker – the central hub of the hub-and-spoke model that acts as the touchpoint for live data. 

• Communication protocol – typically MQTT, the widely recognized standard for machine-to-machine data transfer in manufacturing and industrial environments. 

• Namespace – the structure for publishing data. 

• IIoT platform – for DataOps and data management. 

• Data persistence layer – such as a historian for persistent data storage. 

• Edge protocol and edge compute – solutions for nodes in the environment (normally legacy systems and equipment) that are not compatible with the chosen communication protocol, i.e., MQTT. 

While critical, the components themselves are not enough to develop an effective, scalable, and value-adding UNS architecture. There are also essential characteristics that should be applied to ensure the implemented solution is fit for purpose and facilitates future modernization, improvement, and digital transformation initiatives. 

Open Architecture 

It's important to utilize as many open standards as possible when developing a UNS architecture. Using MQTT as the communication protocol is a good example, as MQTT is an open standard. 

It may not be possible to avoid proprietary technologies altogether, however. To optimize the open architecture philosophy when considering proprietary technologies, it's important to conduct an ease of replacement analysis when assessing vendors. In other words, how easy will it be to change a component to a different vendor if requirements change in the future? The aim is to avoid getting locked into a particular vendor. 

Report By Exception 

There are two main data transfer methods for publishing data to the central hub (the broker): 

• Report by exception 

• Poll response

With report by exception, data is only transferred by nodes on the system when there is a change. 

With poll response, the various nodes on the system are polled frequently to check if there has been a change in the data. 

Both options work, but poll response puts a lot more load on the network as more data is exchanged. The more streamlined report by exception approach is more preferable. 

Where a node in the system doesn't offer report by exception as an option, a conversion solution should be developed to enable report by exception capabilities. 

Edge Driven 

The basic principle of an edge-driven philosophy in a UNS architecture is that machine-to-hub communication should be implemented in the protocol of choice as close to the edge (the source of the data) as possible. 

This is straightforward for nodes within the system that offer MQTT as a communication option. The challenge comes with nodes where MQTT is not available as standard. 

Adopting an edge-driven philosophy means deploying edge compute capabilities as close to these nodes as possible, adjacent to them ideally. The edge compute capabilities implemented at each node should convert the data from the native protocol to MQTT. Where necessary, the data should also be normalized and contextualized by the edge compute engine before being published to the centralized hub. Having this edge compute capability onboard the equipment offers flexibility to perform DataOps at the edge that might otherwise be done centrally. 

Operational Technology Focus 

The theory behind a UNS architecture can be applied to any environment, network, or technology infrastructure. In reality, however, communication and data exchange solutions are likely to already exist at the operations management and business planning levels of an organization's technology stack. These communication and data exchange solutions will be part of the organization's IT infrastructure. 

It's at the operational technology (OT) level in life sciences sector organizations where there are the biggest integration, communication, and data exchange challenges. It is within these OT environments that a UNS architecture can have the biggest impact. 

Conclusion: Focus on Today, Design for the Future 

Delivering a UNS project involves two priorities: achieving today's objectives and ensuring adaptability for future needs. In other words, a UNS architecture must deliver immediate benefits while facilitating (rather than hindering) future factory and production process modernization initiatives. 

The essential characteristics outlined in this blog – open architecture, report by exception, edge driven, and OT focused – enable a focus on today with a design for the future. 

For more information, download our whitepaper: Unified Namespace – Optimized System Connectivity and Data Exchange in Your Smart Factory.