- By Charlie Gifford, David Daff
Summary
Fast Forward
- Real-time knowledge is required for Industry 4.0 end-to-end process management.
- The Operations Event Model and the Notification Model contextualize all data associated with an operations event into a single publish-subscribe message.
- The operations event message is a very powerful way to communicate event information.
New challenges and opportunities for manufacturing technologies and standards across industries
By Charlie Gifford and David Daff
Harmonizing the installed base of large, distributed, heterogeneous plant systems (technology and businesses) brings many challenges. The systems span multiple reliable and unreliable networks containing the instrument/device (ISA-95 Level 1); intelligent device, process control, and supervisory control and data acquisition (SCADA) functions (Level 2); operations management functions (Level 3); and enterprise planning and logistics functions (Level 4). Automation and enterprise vendors, as well as international standards groups (i.e., IEC, ISO, OAGi, OPEN Group/OPA, ISA, OPC UA, and Industrial Internet Consortium), have adjusted their offerings to address various approaches to the IIoT and smart manufacturing requirements. The common theme in new technology, solutions, and standards development is the ability to interoperate over loosely coupled publish-and-subscribe systems (including intelligent devices and machines) with flexible, lightweight messages.
Most vendors and standards groups are focused on the exchange mechanics per the open systems interconnection (OSI) model's layers 2-7 or the TCP/IP model's four layers for the Internet exchanges. However, there has been a great lack of focus on the business document format and schema standards for the data exchange. Without this focus, data integrity is ultimately compromised in deployment, lifecycle change, analytics, and report elements. Over the past four years, the ISA95 committee has been directly addressing evolving requirements by updating its data exchange object models (Part 2's operations and Part 4's work information models). Specifically, the smart manufacturing and IIoT requirements are addressed with contextualized data exchanges between the large installed base of distributed, heterogeneous systems in plants and equipment (100+) and in support of supply-chain operations. In 2015, with the formation of the Process-Centric Messaging working group by the ISA95 committee, the new Operations Event Model (updated Part 2, approved September 2017) and Notification Model (updated Part 5, approval in 2018) contextualize all data associated with an operations event into a single publish-subscribe message. These models are "transport agnostic" to work with any existing and new IIoT protocol technologies.
"Knowledge" engineered
Beyond the marketing rhetoric and technical explanations of smart manufacturing and IIoT, the underlying requirement to make the smart device, machine, or system deliver value is the engineering of the "knowledge worker" for the Industry 4.0 cyber-physical connection. The cyber-physical connection is engineered by providing on-shift information exchanges directly to the available assigned specialist for each operations event. The cyber-physical connection supports intraplant same-shift troubleshooting, problem solving, and situational decision making in real time. The knowledge worker correctly executes his or her engineered response to each abnormal event before a series of costly abnormal events cascades into large losses of capability, capacity, and margin per unit.
Exchange of data without context is valueless. It further deteriorates value as corrupted data. As shown in figure 1, the exchanged data has its greatest value when exchanged within the context of the operations situation or event at the knowledge stage. In the information stage, the smart device/machine/system collects data and contextualizes it into operations patterns to create accurate information by applying root-cause analysis, contextualized reporting, or analytics (operation or financial). To avoid operating a plant or supply chain in the review mirror of periodic reports or analytics, information must be actionable. This happens through engineering the workflow responses of the knowledge worker as the assigned specialist to each abnormal (and normal) operations event. When a known operations pattern has an alert or alarm, the smart device/machine/system directs the right response alternatives to the available on-shift knowledge worker to prioritize and execute the corrective action.
As the engineered responses of the knowledge stage evolve with practice, the organization derives principles to understand and predict behavior. As smart systems are further developed to characterize a plant's operations patterns and response results, the understanding stage is engineered in the form of simulations and predictive models for more accurately planning and executing available plant resources to meet customer and rescheduling demands. This is artificial intelligence.
Realizing KPI value
By characterizing and aligning the operations performance and financial metrics through continuous improvement methods (another day's article), the criteria for operations alerts, alarms, and resource test specifications are used to engineer the operations responses, priorities, and controls to effectively lower the unit cost and other financial metric dependencies.
A significant amount of untapped value exists in every manufacturing operation and physical process (figure 2). The recoverable value is typically from compromised margin and profit from the increased cost of lost capacity and capabilities when resources are constrained (equipment, material, and personnel). This limits the scheduling and workflow alternatives of events like downed equipment, rework, or ineffective storage. The cascading effects of abnormal events are minimized by engineering the manufacturing systems for on-shift corrective action to adverse conditions. The more time a system takes to convert data from the physical process or operations workflow to event information, the less value the response action brings.
The knowledge worker in today's smart plant is empowered with the "standard work" from smart tools, procedures, and operations processes. New product introduction, make-to-order, or expedited processes are optimized to achieve time-to-volume more quickly to maximize margin. The lean method of standard work for response tasks must be applied across the manufacturing execution system (MES) and operations management systems for knowledge workers to be cross trained quickly through common definitions in their user interfaces/faceplates for every work cell and machine in the plant. This a must for smart manufacturing to happen.
A guiding principle is that the primary system functionality gives operators and supervisors "same shift" feedback for all points of daily data collection. This drives the knowledge worker to care about continuous improvement. To characterize process and product quality, the resulting culture focuses daily on what to improve through performance feedback.
Once the work process waste streams (lean value-stream analysis) and process variances (Six Sigma) are identified, the specific metrics and standard event responses as workflows for each adverse event are engineered across interactive operations management systems. The engineered event response is electronically pushed to the accountable on-shift specialist. He or she must acknowledge and then commit to addressing the adverse event or escalating it to the next specialist or supervisor in the workflow based on the situation's priority. These engineered workflows are enforced with on-shift responses of each step.
When the specialist accepts the task, all the collaborating department workflow applications (e.g., MES, operations scheduling, inventory movement, quality operations, asset management, tool calibration and cage management, warehouse management, and intraplant inventory operations) dispatch prioritized event messages and job orders to stage all required documents (i.e., SOPs, checklist), tools/equipment, and parts and materials at the adverse event location. The critical smart manufacturing requirement is to stage all resources for the specialist at the location, so the specialist can quickly perform the corrective action and minimize the capacity loss of production flows. Smart manufacturing requires the supporting departments' on-shift knowledge worker to also drive these staging activities by workflow messages and alerts.
The point here is the knowledge stage is defined by this workflow engineering of manufacturing operations management (MOM) and process control applications, with the knowledge worker trained in each operations event response procedure and remedy. Otherwise, smart manufacturing is not so smart. It would be constrained to the information stage, where the plant and its workers drive in the review mirror based on use-interface alerts and out-of-shift periodic reports and analytics.
In the past 30 years, return on investment typically comes from how well the manufacturing system enables the plant worker to reduce or eliminate-in near real time-the cascading effects and cost of adverse events. Smart manufacturing is making this a science, not an art.
Same information challenges
Smart manufacturing devices, machines, and systems must support the operations event message approach for IIoT to achieve the business case for on-shift, reliable decision making.
Issues
- What is the business case for IIoT and smart manufacturing for my plant type with its existing systems and infrastructure?
- How does a manufacturer best apply IIoT interface methods to its existing plant systems (150+ per typical plant) and infrastructure to realize the real-time Industry 4.0 cyber-physical connection for the knowledge worker?
- The current data exchanges between manufacturing systems primarily emphasize synchronous (request/response) data-centric transactions based on a dated notion that networks cannot provide guaranteed message delivery. The result is:
- The existing receiving systems and controllers require processing logic to interpret multiple data-centric messages for an event.
- Data-centric messages are frequently received or processed out of order, lost, or delayed.
- Receiving systems process incorrect event data when executing their functions to produce bad decision making.
- Data-centric exchanges do not provide a consistent package for the complete process, operations event, or the exception as required for the IIoT or the Industry 4.0's cyber-physical connection.
- Manufacturers require more flexible, extensible manufacturing operations and automation data exchange models for out-of-the box configuration of intraplant data exchanges (not custom mapping) to meet specific event-driven requirements.
Solution
- Real-time messages interoperate across existing heterogeneous messaging and system implementations. This is the operations event publish-subscribe message provided by an industrial event-driven architecture across process control/SCADA, MOM, and enterprise resource planning (ERP) systems.
- IIoT interfaces as lightweight asynchronous event-driven sematic formats and communications are designed for the timing required to support real-time cyber-physical connections of operations events.
- A single operations event message shall contain all changed data for the event.
- An operations event message shall be self-describing based on reusable standard event record definitions, so all information receivers apply only a single structured interpretation of the operations event.
- An operations profile method (ISA-95 Part 8, Manufacturing Operations Profiles, Working Draft 02) defines the reusable operations event definitions across messaging implementations.
- An operations profile represents a description of the information exchange semantics for the scope of a defined process, workflow, industry, and corporate scope (Levels 2, 3 and 4).
- Each operations event message (and ISA-95 exchanges in general) is executed and validated to an operations event profile in an operations profile.
Operations event defined
ISA-95 Part 2 defines an operations event as a notification of manufacturing operations action (production, quality, maintenance, inventory movements) that occurred within an activity, function, task, operation, or phase. Not all real-world events warrant the manufacturing system creating an operations event message. Examples of operations events are:
- completion of an activity function or task (work schedule created, released, or dispatched)
- completion of a business process step (job order started or completed, operations schedule created, released, or dispatched)
- resource status changes (i.e., resource acquired, released, available, committed)
- physical process step actions (i.e., material lot created, updated, deleted)
ISA-95 Operations Event Model
The overview of the Operations Event Model (figure 3) illustrates how the updated Part 2 standard defines operations event message occurrence by the exchanged objects for the operation event definition and operations event definition class, which are documented in an operation profile for a specific process. This pattern follows the same structure used in the ISA-95 Material Model.
- Operations event: The object noun for an instance that contains the changed data for the event published within a notify transaction of the Notification Model.
- Operations event definition: The formal, explicit operations event definition for the event occurrences, operations event. The definition of the operations event message is transmitted by the provider to consumers and subscribers. Typically, many events are transmitted that follow a specific definition.
- Operations event class: Operations event definitions may be grouped by common meaning or structural components into an operations event class.
- Operations event profile: The operations event classes and operations event definitions are typically specified in a plant's user requirements and associated system functional specifications as an operations event profile or similar reusable form as a description of the information exchange semantics for a defined scope. It also enables message partitioning to avoid name clashes and allow cooperation of message specifications from different sources in implementations. This concept is not defined by ISA-95.
The overview of the Operations Event Model (figure 3) illustrates the operation event definition and the relationship with the operations event message occurrence.
As shown in figure 4, The Unified Modeling Language (UML) diagram of the Operations Event Model shows the operations event object primarily defining an event occurrence by the operations event record in an occurrence message. The self-describing operations event messages contain all the information explicitly or via reference links for the required information describing the operations or process control event. The operations event definition record specification and operations event class record specification define the message definition of the event structure of the set of changed data objects. They are used to configure different operations event occurrences to a known explicit event structure or definition.
Real-time industrial EDA
The operation event message is a post/publish-notify/subscribe (typically) independent asynchronous process. An industrial event-driven architecture (EDA) typically consists of:
- operations event producers
- operations event consumers
- publication systems
- operations event channels
An operations event producer (publisher) does not have to know about the subscribing operations event consumers (receivers) and their data subset requirement that is logically processed out of the operations event message. The consumers apply the operations event definition from the producer to know explicitly how to logically parse the operations event message. The receiver only abstracts the event information required to control its operations or physical processes. Depending on the manufacturing operations or process control requirements (what is being made and how), the industrial real-time EDA takes on various forms:
- An operations event producer may manage the assembly and control triggers of operations events.
- An operations event channel may manage the control triggers and distribution of operations events.
- The operations event message can be generated from applications or from inside the plant's data exchange infrastructure/mediation components.
- The EDA implementation is typically applied in combination with other messaging exchange patterns, such as request-response, depending on the requirements.
- The EDA can be applied over a variety of technology landscapes with or without an enterprise service bus (ESB), manufacturing service bus (MSB), or similar environments to non-ESB environments.
- The data exchange infrastructure may be performed using many non-ESB/MSB approaches, such as .NET, a rich-site-summary (RSS) feed, an atom feed (Atom Syndication Format, an XML language used for Web feeds), an APP (Atom Publishing Protocol, a simple HTTP-based protocol for creating and updating Web resources), or a simple file-share method (peer-to-peer [P2P] file sharing for exchanging large files on an intranet).
- With IIoT, many transport protocols and methods can be introduced into industrial environments for data exchange.
Common MOM events
In 2017, the ISA95 committee produced working draft 01 for ANSI/ISA-95.00.09-ed1, Enterprise-Control System Integration− Part 9: Common Manufacturing Operations Management Events. This working draft will be going through development through 2018; however, the common operations events are defined in the context of the ANSI/ISA-95.00.03-2013 - Part 3: MOM Generic Activity Model for the common process-centric operations events per function. Figure 6 from the working draft shows some of the proposed common operations events, where each noun is explicitly defined with the ISA-95 Part 2 (operations) and Part 4 (work) objects in the operations event record.
Operations event example:
ResourceAcquired
The operations event ResourceAcquired notifies the subscribing plant systems containing the dependent MOM functions of the acquisition and release of new physical resources into the plant. The physical resources may have been acquired through processes, such as procurement, personnel management, or production processes producing material lots or sublots. Figure 7 shows an example of the MOM functions subscribing to the resource management function through their associated plant systems. The publishing system may be either the MES, product life-cycle management system, or ERP system. The system publishes the operations event, resource acquired, when a new resource is available for scheduling and use in operations.
The operations event message is a very powerful method for communicating event information across the plant and enterprise in a single structured message.
Reader Feedback
We want to hear from you! Please send us your comments and questions about this topic to InTechmagazine@isa.org.