What Is the Layered Databus Architecture Relative to Control and Optimization

Overview

The Industrial Internet Consortium's (IIC’s) Industrial Internet Reference Architecture (IIRA) is part of a series of technical documents describing that organization's view on the Industrial Internet of Things (IIoT).  The document describes a reference architecture for an IIoT system derived from a layered databus architecture framework based on the ISO/IEC/IEEE 42010:2011 standard for systems and software engineering.  The IIRA develops four viewpoints relative to: the business, usage, functions, and implementation; plus a number of cross-viewpoint system characteristics and concerns. A recent guest blogpost on ARC Advisory Group's IIoT Viewpoints blog nicely summarizes the benefits of IIRA V1.8 and enumerates the updates compared to the previous version.

This latest version discusses an additional architectural pattern: the layered databus organized as a system of systems.  Applying such an architecture would have potential implications for:

• the protocols used in the control layer
• integration with the operations and business layers
• use of aggregated, vs. non-aggregated Big Data for edge-, fog-, and cloud-based analytics, and

• the scope of cloud-based analytics and optimization provided by integrating value chain networks.

Layered Databus Architecture Pattern

IIRA describes the pattern for this multi-layered database architecture as a hierarchy of databuses for communication at different levels of the enterprise and beyond.  To a certain degree, the hierarchy resembles the six-layer, ISA95 model that describes the functions of the manufacturing process and those of operations and business management. At the lowest level of the IIRA V1.8 hierarchy, smart machines use databuses for local control, automation, and real-time analytics.

Readers will note that the text refers to “machines” when referring to physical activity.  This should not be construed as implying that the architecture applies solely to discrete manufacturing.  In fact, similar real-time buses are already in use in aerospace & defense, infrastructure, healthcare, transportation, wind energy, oil and gas drilling, and other industries.

The function of the real-time databus in the IIRA is comparable to DCSs communicating with instruments and actuators connected via I/O, machine-to- machine coordination via I/O between machines in fast packaging operations, or fieldbus communications.  With a databus, many devices and/or applications can be easily interfaced using a single connector to the databus.

The IIRA further mentions that a data-centric publish-subscribe communications model is central to the databus for the control layer as well.  While this may be somewhat of a novelty in the industrial manufacturing domain, the approach is widely used in several other sectors.  Agents on the bus do not need knowledge of each other, but subscribe to future data of a certain type to communicate.

According to IIRA, a databus is a logically connected space that implements a set of common schema and uses those to communicate between endpoints.  Each databus layer implements a common data model, allowing interoperable communications between end points at that layer.   As reflected in a recent ARC blogpost and article, manufacturers and other industrial organizations are starting to use enterprise-wide data models and could benefit from standardized approaches.

According to IIRA, higher-level systems use another databus for supervisory control and monitoring. Federating these systems into a “system of systems” enables complex, Internet-scale, potentially-cloud-based, control, monitoring and analytic applications.  These higher-level systems are the equivalents to today’s familiar control, office, and corporate networks network.  Today, these networks are mostly restricted to a single enterprise, using company networks to support internal collaboration between people and software.

The Reference Architecture Model for Industrie 4.0, (RAMI) uses a similar hierarchy that builds upon what is usually referred to as the ISA88 “physical model,” a combination of the ISA88 or IEC 62264 and ISA95 or IEC 61512 physical models.  Using the ISA88 physical model approach, RAMI extends the ISA95 physical model down to the field device and the connected product, a level that appears to be missing in IIRA.  RAMI also models the “connected world,” or the level of interconnection among enterprises in an ecosystem.  Intended to be a reference architecture, IIRA concepts and approaches can be extended when implemented.  It appears that the RAMI reference model could provide some guidance for IIRA implementers to use a standardized approach to model physical reality and extend the layers to the connected product and the connected world for cross-enterprise communication.

Implications for the Control Layer

The open Data Distribution Service (DDS) standard managed by the Object Management Group (OMG) is designed to be used with a databus. It is often used in IIC testbeds and would be a natural choice for an architecture based on IIRA. DDS has a real-time publish and subscribe protocol (RTPS) that can handle the requirements of the real-time layer.  The quality of service (QoS) of the RTPS is compatible with the required “determinism,” or guaranteed timely message delivery to enable safe closed-loop control.

Industries such as aerospace & defense, energy, and infrastructure need a single, real-time communications platform that can function in real time in a multi-vendor environment.    The goal of the Open Group’s Open Process Automation initiative is to define an open standard for communication within the real-time control layer between DCS, controllers, instruments, and actuators, using current practices in the aerospace & defense industry as a benchmark.  The DDS RTPS protocol will be used for the pilot project, making it a serious contender to replace proprietary DCS protocols and the current crop of fieldbus protocols in the future. 

The latest OPC standard, OPC UA, is often used to connect devices to devices, devices to software, and – increasingly - devices and software to the cloud. OPC UA employs an object-oriented, client-server approach and will soon include two distinct publish and subscribe services for device and machine integration. Collaboration between the OPC Foundation and OMG’s DDS will enable interoperability between the two approaches.  OPC UA publishers and subscribers will be able to do so via a bus using DDS. 

A realistic future scenario for process automation could be that users will gradually replace proprietary or fieldbus communications at the real-time layer with open communication protocols.  Users would therefore be able to leverage their existing investments and gradually transition to an Open Process Automation standard when this investment becomes necessary or economical. 

In the manufacturing industries, databuses are more common for communication between manufacturing operations management, business planning and business management software (see diagram on ISA95 levels).  These are often referred to as “middleware.” 

Recently, ARC has observed early implementations of data layers or data platforms that connect instruments, machines, or equipment with a real-time database infrastructure; often at the enterprise scale. These implementations can use a standardized data model and provide similar strengths as databuses.

A multi-layer databus could help meet the increasing need to communicate industrial real-time or historical data across the enterprise. Today’s proprietary installations in the real-time layer can communicate with engineering systems and manufacturing operations management applications.  These systems in turn can communicate with business planning and management applications (SCM and ERP) using classical ISA-95 B2MML or alternatively using a databus and DDS.  Industrial sites where DDS-enabled open process automation coexists with proprietary solutions are compatible with traditional interfacing with MOM and are, by definition, compatible with a multi-layer databus.  This implies that DDS could be implemented layer by layer, where and when benefits are apparent, and that a migration path towards the multi-layered bus architecture is feasible.

To Aggregate, or Not to Aggregate

As more vertical industries start implementing an enterprise-wide data model as a layer of abstraction helps make it more intuitive to identify tags and access the associated information, the layers in the IIRA would reference this common, enterprise-wide data models (ideally with the possibility to update it dynamically).  This would constitute a global implementation of such an abstraction model. 

The IIRA mentions that adapters may be needed between layers to match data models.  (ARC believes these adapters may have to be application-specific.)  Currently, some NoSQL databases provide the possibility to map historical tag naming conventions, often defined by industrial site or application, to a global data model.  These “data brokers” have this same function as the IIRA adapter. This mapping could also be useful for connecting with entities outside the enterprise boundaries.

Common data models make it feasible to share real-time and historical data across the enterprise.  But this is not always necessary. According to the IIRA, “Generally, transitions occurring between layers filter and reduce the data. This is important because the scope of control and analysis grows at each layer and the amount of data is generally reduced to match the broader scope, the higher latencies, and the higher level of abstraction.”  This reasoning is correct for business management and planning, where an aggregated view may be sufficient when the different sites can dispatch on individual lines and machines more efficiently than could be done in a centralized manner. However, with increasing product customization and personalization, the level of detail in centralized scheduling and production control may increase. 

For industrial data analytics, ARC believes granular data at the corporate level may have value for monitoring, analysis, predictions, or engineering. For those purposes, it’s not necessary for all real-time data to travel simultaneously to corporate centers or the cloud.  When something requires study, the relevant data can be retrieved from the local device or application.

The current trend to add more sensors to manufacturing processes to connect smart equipment (or their sensors) and perform predictive analytics in the cloud may create bandwidth issues.  Due to this constraint, and the increasing power of edge devices, more analysis and decision making will be done at the edge.  Only aggregated information will flow to higher layers for coordination purposes or to analyze the behavior of a fleet of assets. 

All in all, ARC agrees with the IIRA that only a selection of real-time data will end up at centralized locations, whether through aggregation or selection.

Goal of Large-scope Optimization

In the operations domain, the increasing scope of control and the trend toward layered databus architectures also open the potential for large-scope optimization.  The IIRA mentions that existing industrial control systems mostly focus on optimizing the assets in a single physical plant and adds that “the control systems of the Industrial Internet must move up a level, and optimize operations across asset types, fleets and customers.” 

Optimization involves calculating an optimal way to operate a plant or a network, and/or defining plant or network trajectories and operating points based on expected material and energy pricing; product value, specs, and orders; and resource availability.  The criteria defining “optimal”’ are generally financial, but could also include environmental or social aspects.   In refining and petrochemicals, real-time optimization of units and plants, often with a horizon of several hours, has been commonly employed for decades to maintain competitivity.  The recent trend to apply data science to industrial Big Data to perform predictive and prescriptive analytics describes a similar function, but possibly involving more statistical and mathematical modeling, as opposed to science-based or hybrid modeling.

The larger the scope of an optimization application, the larger the potential benefits.  The scope of both real-time and mid-term supply chain optimization in industrial plants and oil & gas operations has grown over the past ten years.  ARC expects that the combination of growing capabilities in infrastructure, connectivity, interoperability, model building and computational capability will lead to real-time, granular site-wide optimization; or even cross-site optimization in mid-to-long-term.

In addition to the increasing number of assets involved and longer time horizons, we’re also seeing optimization moving into more operational domains.  Combined optimization of production and quality targets, or production and maintenance targets have received increased interest.  Ultimately, we expect to see simultaneous optimization of production, quality, maintenance, and supply chain targets, for different time horizons: real-time, mid-to-long-term, and long-term.  For the real-time horizon in particular, real-time information is needed from production assets, quality analyzers, transportation, and storage units. 

According to the IIRA, this will require many legacy “dumb” assets to be retrofitted with compute, storage, and connectivity capabilities.   While most continuous process units have sufficient process-related (temperatures, levels, flows, etc.) instrumentation for real-time measurements; asset, quality, and supply chain data are generally not available in real time.   This is particularly true in brownfield installations in developed regions.  At SAP’s recent “Leonardo Live” event, BASF gave a presentation on its approach, conceived primarily for the company’s brownfield plants, in which retrofitted equipment is connected to the cloud in parallel with existing automation and production systems.  This is similar to the Namur Open Architecture approach.  Similar retrofits would be needed for many discrete processing lines, particularly those not equipped with the latest generation of smart machines.

Real-time, on-line information would support large-scope, IIoT-enabled optimization.  Real-time optimization in petrochemical plants has relatively long time horizons.  Optimum operations can be maintained for several hours, or even days, by a combination of regulatory control and multi-variable model-based control optimizing the respective dynamics of different plant units or subsections, to which the optimizer would give instructions.  This type of architecture could conceivably work via internet connections, even when experiencing short outages.

Conclusion     

With the layered databus architecture, the IIRA proposes publish-and-subscribe mechanisms (such as DDS) to all the network layers present in today’s manufacturing enterprises.  Depending on the vertical industry and the application, a bus approach could be applied to part or the entire network architecture and introduced gradually based on requirements for open automation and/or for rationalizing the interfaces between production, planning, or management applications.

The approach is compatible with the Open Group’s use of DDS for open process automation and could become a standard for the control layer.  Publish-and-subscribe mechanisms also provide an efficient way to connect enterprise applications via databuses.  This opens up the potential to use a homogeneous databus approach across the layers of the enterprise, consistent with the IIRA to enable larger scope optimization across manufacturing value chains to unlock incremental economic benefits.

Recommendations

Based on the above, ARC recommends that technology suppliers and end users alike should:

• Follow standardization initiatives such as the Open Group’s OPA automation initiative, the IIC, Platform Industrie 4.0, the Industrial Data Space, OPC UA, DDS, and ISA95.
• Assess the potential long-term benefits of these standards, and make strategic IT and automation plans that foresee upgrades, migrations, modernization using these standards.

• Attend ARC’s Industry Forums to learn about the latest updates and use cases from standardization bodies, end users, and suppliers.

 

If you would like to buy this report or obtain information about how to become a client, please  Contact Us

Keywords: Industrial Internet Consortium (IIC), Reference Architecture, Layered Databus Architecture, Industrie 4.0, RAMI 4.0, Open Process Automation, ARC Advisory Group.