Modeling Events in Accordance with the ISA-95 Standard

Many standards and templates exist that can be leveraged by architects to more efficiently model events in a way that makes them more easily reusable by others across their organization. For this exercise I will show this using ANSI ISA-95, Enterprise-Control System Integration, which can be applied to situations that involve control-based automation solutions such as Industrial (4.0) Internet of Things (IIoT).

The imperative for organizations is operational efficiency, and there is not a single layer in the architecture that can influence the outcome in isolation. ISA-95 employs domain-driven architecture, and an abstract model is provided to define domain responsibilities and boundaries.

Figure 1: ISA-95 Domain model

The model is made up of 5 layers, where Level 0 is the actual process and Level 4 encompasses ERP systems and cloud resources, such as digital analytics. Each level in the architecture presents its own challenges but particularly to Levels 0, 1 and 2. Disparate devices and control layers like HMI (Human Machine Interface) and SCADA (supervisory control and data acquisition) are normally not the focus for event driven transformation. The integrations are tightly coupled for good reason.

A plethora of standards likely exists here, and equipment manufacturers often implement proprietary interfaces which may be used for existing integration. Standards do exist however, including the OPC Unified Architecture, that provide frameworks and protocols. In many interactions however the information being output is event based. Think ‘report by exception’ scenarios where notifications are only omitted by a device when something occurs, like a threshold being breached. These are exactly the events suitable for publication.

MQTT has gained wide adoption and acceptance as a lightweight pub/sub protocol well adapted for these scenarios. MQTT clients connect to a broker and can participate in event exchange using publish/subscribe. Some devices are MQTT enabled and in these cases a direct connection can be established, in most cases gateways would be required to connect into the SCADA system. These would become both MQTT aggregators and access points into the event mesh and universal namespace

Figure 2: Conceptual Model

In terms of the universal namespace the conceptual domain models provided by ISA-95 provides a solid foundation for developing the universal namespace. Considering the model above it is easy to convert the hierarchical model into a topic hierarchy:

ENTERPRISE/SITE/AREA/PROCESSCELL/UNIT
ENTERPRISE/SITE/AREA/PRODUCTIONUNIT
ENTERPRISE/SITE/AREA/PRODUCTIONLINE/WORKCELL

Each layer in the (now) topic hierarchy has semantic context. The hierarchical levels are tokenized with the ‘/’ character. These hierarchical topics are used to identify events published to the mesh.

There is an alternative to this ‘first principles’ approach and that it to leverage another standard, Sparkplug B, which provides a framework for the application of MQTT into an Industrial IIoT environment. The specification covers the following:

• Topic namespace
• MQTT State Management
• Topic Payload Definitions

Many examples exist for those interested in using Sparkplug B. The specification and examples are freely available from the Eclipse Foundation.

Putting it to Work

I’ll now use some of these tools and standards to model a flow and applications. The ultimate goal is to deliver the AsyncAPI artifacts to the development team so they can develop the producer and consumer applications using an unambiguous specification.

The scenario for this example is that I have an existing event being published from the SCADA system and being consumed by the MES. I want to reuse the same event stream, with some filtering, to provide data newly developed cloud analytics platform. To help with the architecture and specification of the flow we’ll leverage ISA-95 for the domain definitions and Sparkplug B for the event schema (payload) and topic definition.

I’ll be working in Solace PubSub+ Event Portal to create an AsyncAPI definition for an event consumer in Azure Cloud, which will ultimately push the data into the analytics platform.

Upon logging into Event Portal, I can review the current domains and event flows.

Figure 3: As is domain interaction model

I can see that an existing event (labelled ‘1’) is being published from Level 2 in Level 3. I can drill into the domains for further detail. By drilling into the Level 3 domain I can see that this is a SCADA event that’s consumed by the MES, and by drilling into the event itself I can see details about its description, topic, and schema.

Figure 4: SCADA Event based on Sparkplug B Spec

Now armed with the information I need to proceed, I have made the decision that I can reuse the existing event to provide a real-time event stream into the upcoming analytics application running on Azure. My job, as the architect/designer, is to specify the new application in terms of its event API requirements.

I start by navigating to the Level 4 domain and create the new application. I can specify that the new application will subscribe to the SCADA event. In addition I can add a level of granularity to the subscription that will filter the events, so only those from ‘Site1’ and where message type is ‘NDATA’ or ‘DDATA’.

Figure 5: Apply wildcard subscriptions to filter event stream

With this the event flow specification is complete, so I can generate the AsnycAPI schema and deliver the artifact to the development team.

Figure 6: AsyncAPI generation and output

The domain model now reflects the ‘to be’ event flows, which means the knowledge is captured and available to the next team tasked with delivering a new business capability.

Figure 7: To be domain interaction model

Conclusion

I hope this post has shed some light on how standards and templates can help architects and developers more efficiently develop and reuse applications and functionality, specifically ISA-95 in the area of control-based automation and IoT solutions.