- By Dennis Brandl
- March 31, 2016
- Factory Automation
- The old pyramid model of control is being replaced with a new model of zones and intrazone conduits based on ISA and IEC standards.
- The new model uses two main communication models, based on OPC UA for high-speed tightly coupled systems and B2MML message exchanges for low-speed loosely coupled systems.
- Users should focus on zones and conduits to develop a new federated system architecture.
Efficient manufacturing requires devices and software working together
By Dennis Brandl
Most manufacturing environments are federated systems. In manufacturing, the term federation describes a collection of devices and software from multiple vendors that must work together to support business and operational processes. In theory, integrating federated systems is not too hard. Most devices have some form of communication available, and most software has some method for importing and exporting files, some way to request information, and some way to respond to requests. In practice, there are multiple issues to address to integrate federated systems, including the meaning and format of the exchanged data; the meaning of names, identifiers, and enumeration values; the devices and applications that actually send and receive data; and finally the technologies used for sending and receiving the exchanged data.
Fortunately, a set of standards for federated systems is making the practice of integration easier. The use of OPC UA (Unified Architecture), the ISA-95, Enterprise Control System Integration standard, the MESA B2MML (Business to Manufacturing Markup Language), and message exchange models make integration easier and also change the integration architecture used in manufacturing environments.
The original ISA-95 standard defined an information model for exchanges of information between business systems and manufacturing operations systems. The 2012 release of ISA-95 Part 4: Objects and Attributes for Manufacturing Operations Management Integration, and the planned 2016 release of the equivalent IEC 62264-4 standard, has added information models for data exchange between manufacturing execution systems (MESs), laboratory information management systems, warehouse management systems, tank farm systems, asset management systems, and other manufacturing operations management systems. The MESA B2MML Version 6.0 2013 release provided an implementation of the ISA-95 Part 4 models. The ISO 22400 KPI standard and the MESA KPI-ML Version 1.0 2015 release provide a vendor-independent way to exchange key performance indicator (KPI) information, using a similar structure as ISA-95.
OPC UA was released in 2009. It provides an industrial Ethernet, TCP/IP, and user datagram protocol (UDP)/IP-based, platform-independent, service-oriented communication architecture. It includes the functionality of the original OPC standard but uses standard Internet technology, security, and the ability to handle complex data. OPC UA has been internationalized through the IEC 62542 standards.
When the ISA, OPC Foundation, IEC, and MESA standards are combined, they provide a new capability for federated system integration and a new integration architecture. In traditional architectures, devices are “mostly dumb,” at least in respect to communications. They only respond to requests for information across a dedicated fieldbus, or they may have hardwired connections to controllers. Controllers are fieldbus masters that typically “poll” the devices on a regular schedule. The controllers usually communicate to higher-level systems, such as human-machine interfaces and data historians. Most software applications also “poll” for data on a regular schedule. Networks are optimized for operating in master-slave configurations, and there is often only a single master allowed on each network segment. Traditional architectures resemble pyramids, with the levels of the pyramid generally corresponding to the ISA-95 activity levels, as illustrated in figure 1. This pyramid architecture and segmentation into ISA-95 layers is just an artifact of technology limitations. Limited CPU capability, networking capability, and memory in devices and controllers have limited the architecture choices to hierarchical networks of devices and controllers.
Figure 1. The traditional control pyramid
Faster networks, smarter devices, and a desire for interoperable software applications is driving a new architecture. In the new architecture, every device is a data publisher and exposes selected information using standard exchange models. Publish/subscribe protocols, such as those in the OPC UA Part 4 specification and the IEC 62641-4 standard, and those defined in ISA-95 Part 6: Message Service Model and implemented in the Open O&M specification, eliminate the need for master-slave polling protocols. Software applications and devices become data subscribers. Any application or device can implement functions associated with multiple activity levels.
New architectures are defined as collections of peer-to-peer zones, with zones identified by similar security and communication speed requirements (figure 2). If real-time control is needed among a collection of devices, then they operate within a single zone. If a collection of devices need a common protection policy, then they operate within a single zone. The system architecture is defined by the organization of devices and applications into self-consistent zones with secure communication between zones. Communication between zones is through secure conduits, with the selected conduit technology optimized for speed, security, and data complexity requirements. The traditional control pyramid is being replaced by a web of zones and interzone conduits.
Figure 2. Web of multilevel speed and security zones
Functions in multiple ISA-95 activity levels are often implemented in a single zone, and conduits between zones may also operate at more than one ISA-95 level. Single devices and applications may also implement multiple level functions, such as providing control, monitoring, KPI generation, and historical data collection.
Within a zone there are several options for communication: hardwired, fieldbus, OPC, OPC UA, and message exchanges. The specific speed requirement within each zone dictates the method used. Many companies are moving to OPC UA for intrazone communication when high-speed and tightly coupled processes are needed. Communication across zones also has options for system integration. However, performance between zones is usually less important than support for occasional disconnections, loosely coupled data requirements, and little process integration. Many companies use a secure message exchange system based on B2MML or some other form of XML messages for interzone communications. Table 1 lists the general characteristics of B2MML and OPC UA that are used to help determine the appropriate interzone and intrazone communication model. Table 1 illustrates the differences between the XML queued message-based integration model of B2MML, and the binary connection-based message model of OPC UA, and how they complement each other.
Table 1. Communication characteristics
|Integration attributes||B2MML/MSM||OPC UA|
OPC UA companion specifications
|Security model defined||Yes||Yes|
|Data types||Complex||Simple and complex|
|Typical data sizes||Large, 10 KB – 10 MB||Small, 1 KB – 10 KB|
|Connection persistence||Temporary disconnected||Continuous connections|
|Primary use characteristics||Low speed,
loosely data coupled,
high data coupled,
OPC UA devices (servers) expose a “view” of their internal data. The term view is used in the same manner as a database view. It may or may not represent the underlying data structures, but defines the server’s representation of externally accessible data. The OPC UA clients that read the data must understand the defined view. This means that the clients and servers must have high data coupling. A change in the server representation often requires a change in the client systems. This coupling is limited when the data types are simple, such as tagged values, but can be high for complex data, such as analyzers, printers, case packers, and filling machines. OPC UA is also high speed, providing a binary representation of data and relatively short message frames. This makes OPC UA suitable for real-time control and also for synchronized processes. OPC UA works best in situations where the devices are continuously connected and control high-speed synchronous processes.
Software applications using B2MML import and export information using a standard “data exchange model.” This model does not represent the internal data structure of an application, but provides a vendor- and application-independent way to represent commonly exchanged information objects. This results in loose data coupling, because a change in one application does not require changes in other applications. The downside is that B2MML imports and exports are slower and are usually performed using a queued message exchange system, such as an enterprise service bus or manufacturing service bus. Queued message exchange systems provide guaranteed message delivery at the expense of reading and writing messages to permanent storage to handle service disruptions and equipment failures.
The OPC Foundation has recently released the first OPC UA 95 companion specification, which adds ISA-95 object model representations of equipment, personnel, material, and physical assets. This joint effort between the OPC Foundation, the ISA95 committee, and MESA illustrates how these standards can be used together in a federated system architecture. Figure 3 illustrates the types of integration information exchanged in federated systems, and which standards define the associated information models.
Figure 3. Types of data exchanges in federated environments
The following example of a federated environment illustrates how OPC UA handles high-speed, continuous connection requirements, coupled with the lower speed and limited communication throughput of a typical ERP system using B2MML.
Material must be identified in shop floor production. Each material lot’s status (available, not certified, not released) is maintained in the corporate ERP system, and only material that has a status of available may be used in production.
- Material lots are identified by bar code in the MES as part of a normal workflow. The MES releases the material for use in production only if its status is available.
- The ERP system cannot be queried for the material status at the rates required for shop floor operations, and the ERP system only publishes material lot status changes on a scheduled basis (every shift).
- A material cache application is:
- a subscriber to B2MML material lot information from the ERP system
- a local cache of material lot statuses
- an OPC UA server that exposes the OPC UA 95 material models
- The material cache application maintains the last received status for each material lot and makes it available through OPC UA.
- The material cache application also subscribes to material lot status changes. It receives published lot statuses from the ERP in a B2MML format and makes the information available in an OPC UA 95 format.
In summary, limitations in network performance, CPU capability, and memory size in devices, controllers, and servers have forced the traditional pyramid control architecture in many facilities. However, faster networks, more powerful and inexpensive processors, and abundant memory enable a more flexible architecture for manufacturing facilities. A new architecture, based on the ISA/IEC 62443 standards of zones and conduits, merged with the OPC UA (IEC 62541), ISA-95 (IEC 62264), and MESA B2MML standards, provides increased flexibility and robust system architectures. Companies implementing the new architecture for federated manufacturing systems will have systems that are more secure, easier to integrate, and easier to update. When considering your new system update or new installation, focus on zones and conduits to develop the new federated system architecture, and look to the ISA and IEC standards for guidance and direction.
We want to hear from you! Please send us your comments and questions about this topic to InTechmagazine@isa.org.