- By Bill Poole
- Automation IT
Summary
- The ISA-95 standards are used worldwide for the integration of enterprise and control systems.
- ISA-95 advancements support the near real-time, process-centric, and event-driven integration between manufacturing operations management processes, improving the ability to automate these processes and respond to operational events in line with Industrie 4.0.
- It is easier to implement ISA-95 with COTS products without proprietary extensions or customizations.
Adopted worldwide, ISA-95 improvements continue adding value
By Bill Poole
The proposed improvements to the ISA-95 affect the Parts 2, 4, and 5 standards, and include two new parts:
- Part 8: Manufacturing Operations Management Information Exchange Profiles
- Part 9: Common Operations Management Events
The vast majority of the improvements have now been submitted as comments to the ISA95 committee and are either reflected in the latest working drafts or will be reflected in updated working drafts that will be distributed to the committee soon. This work has been done with significant support from several committee members who have reviewed and provided feedback on and improvements to the comments submitted by this core team. The core team responsible for this work was Bill Poole, Manufacturing Intelligence; Brad Keifer, Enterprise Transformation Partners; Charlie Gifford, 21st Century Manufacturing Solutions; Matthew Strack, BHP Billiton; Gavan Hood, Simul-Tech; and Paul Beesley, Runge Pincock Minarco.
The goals to improve ISA-95 include:
- providing support for near real-time, process-centric, and event-driven integration between manufacturing operations management (MOM) processes, improving the ability to automate these processes and respond to operational events in near real time in line with the principles of Industrie 4.0
- improving the ability of ISA-95 to be implemented in commercial-off-the-shelf (COTS) products without proprietary extensions or customizations for “out of the box” interoperability between different products from different vendors
- improving the applicability of ISA-95 to operations that make significant use of mobile equipment, such as transportation, mining, and agriculture
- improving the ability to benchmark operational performance within and between plants, and within and between organizations
This article outlines the major proposed improvements to the ISA-95 standards for achieving these goals.
Improved integration between ISA-95 information models
Consider an operations schedule released from an enterprise resource planning (ERP) system to a finite capacity scheduling system, which in turn produces a work schedule (in ISA-95 vernacular). The operations schedule is expressed against a level 4 model of the value chain used by the ERP system, while the finite capacity scheduling system operates against a level 3 model of the value chain. For the finite capacity scheduling system to properly interpret the operations schedule and produce a work schedule, it must understand how the level 3 model of the value chain relates to the level 4 model.
Job orders from the work schedule are then dispatched to the execution management activity, which must know which workflow specification is needed to execute each job order. As each workflow is executed, job responses are reported against each step in the workflow and against each job order in the work schedule. Job responses must be reported against the steps in the executed workflow for it to be possible to analyze the performance of the workflow’s execution.
Actual results must then be reported back to level 4. Therefore, it must be possible to determine the segment requirements (line items in the operations schedule) to which each job response corresponds. This is only possible if a relationship has been previously established between job orders in the work schedule and segment requirements in the operations schedule.
New relationships have been proposed between some ISA-95 information models to achieve this. Improving the integration between the information models improves process integration between level 4 and level 3 processes and between level 3 processes.
Profiles
ISA-95 defines the objects and their attributes needed to support most MOM information exchanges; however, it would not be practical to define all objects and attributes for every use case in every manufacturing organization in every industry. Profiles (described in the newly proposed Part 8 of the standard) are intended to provide a formal extension mechanism for ISA-95, so that organization-specific, industry-specific, and vendor-specific extensions can be described and supported by relevant software products.
A “profile” describes a set of extensions and usages for ISA-95 that is specific to a given use case, organization, or industry. For example, a profile could be established for the mining industry that defines a standard truck equipment class (with a standard ID) with a standard set of properties (each with a standard property ID). The profile would specify clear definitions for the equipment class and its properties.
Consequently, it would be possible to define equipment capability properties, such as maximum speed, maximum load, power/acceleration, and fuel burn rate, in a standard way so that the equipment capability master data could be configured once and then reused by different software products. Any two or more software products implementing the mining profile would then be able to exchange truck capability information directly “out of the box,” without having to translate this data between the applications.
Note that Part 8 is not itself a profile. Part 8 provides the required structure of profiles and guidance for defining them. It will be up to organizations adopting ISA-95 and industry consortiums to define profiles in accordance with Part 8.
Operations events
It is a common requirement to exchange information between software systems in accordance with an event that occurred. For example, a given unit of production work may consume one or more material lots and produce one or more material lots. The production work itself is represented as a job response in ISA-95.
If the new and updated material lot information is communicated in a separate message to the job response, then the receiving systems may need to wait for all the information corresponding to this single unit of production work to arrive before it can be processed. This requires systems to temporarily store messages until all related messages have been received\, so they can be processed together. This adds complexity to these software systems, making them more difficult and expensive to develop and maintain.
Furthermore, communicating the job response and new and updated material lot information does not communicate the event that occurred that resulted in the new job response and new and updated material lots. Knowing which event occurred is often important for determining the way receiving systems process the data corresponding to the event.
It has been proposed that an operations event object, which allows the representation of an event, be introduced in Part 2. In the above example, this might be a “work performed” event. This single event object can then contain the job response and all new and updated material lot information. It has also been proposed that a “notify” verb be introduced in Part 5, which would then allow a message to contain a notification of an operations event, with all information relevant to that event in a single message.
Each receiving system is therefore guaranteed to get all the necessary information to process each message in that message, eliminating the need to put messages aside until all related messages have been received before processing them.
Implementing organizations are free to define whatever types of operations events they require (as operations event definitions). Each operations event definition identifies the objects (defined in Parts 2 and 4) that are permitted in the event payload. Several predefined events are proposed in Part 9, so it is possible for COTS products supporting Part 9 to notify each other of events defined in Part 9 “out of the box.”
A profile may define a set of standard operations event definitions beyond those proposed for Part 9\, making it possible for any two COTS products supporting that profile to exchange operations events in accordance with those definitions out of the box.
Specialization of physical process definitions
Physical processes in a value chain are defined with the process segment and operations definition models in Part 2 and the work definition and workflow specification models in Part 4. It is common for physical processes to be engineered in a generalized way and then later specialized to apply to specific equipment in different locations within and between plants. The generalized process definitions are then reused as they are applied to equipment-specific process definitions.
It has been proposed to make it possible to define “abstract” process definitions in ISA-95 (process segments, operations definitions, work masters, workflow specifications, and workflow specification nodes), which can then be specialized to create “concrete” process definitions. An abstract process definition may itself be a specialization of another abstract process definition. Under the proposal, if a process definition is a specialization of another process definition, it may hold a reference to the process definition it specializes.
This is also beneficial for benchmarking performance between different specializations of standard abstract process definitions. Key performance indicators (KPIs) may be defined against an abstract process definition, which then can be measured against data recorded against any derived concrete process definitions. This allows the performance of each concrete process to be compared using these KPIs.
Combined with the proposed profile mechanism, this makes it possible to define industry-specific standard process definitions with corresponding standard KPIs in a profile. This improves the ability to benchmark performance between manufacturers in each industry.
Spatial information
Spatial systems and information are becoming increasingly prevalent in manufacturing operations. Any equipment with a GPS communicates spatial information in the form of GPS coordinates. Spatial information is often important for managing operations using mobile equipment. For example, a production order may require equipment to be dispatched to “bay 5,” but the only way to determine the direction to send the equipment or whether the equipment is in bay 5 is to evaluate its GPS coordinates against a “geo-fence,” which spatially describes the boundary of bay 5.
Therefore, in these types of manufacturing operations, it is typical for schedules and actuals to have a spatial component. The proposed improvement to ISA-95 adds an attribute to several objects that can hold spatial information. This proposed improvement also provides a means of exchanging 3D plant models, which are increasingly being used in information exchanges between engineering and maintenance functions.
Operational locations
It has been proposed that a new information model be added to Part 2 to describe operational locations within a plant. An operational location is a logical or physical location where personnel, equipment, and/or material may be located at any given time.
The operational location model allows organizations to define a hierarchy of operational locations, describing which operational locations contain which other operational locations. It also allows an organization to define classes of operational locations, such as a bay, bin, hatch, or stockpile footprint.
This improvement makes it possible to evaluate compliance of shorter-term schedules against longer-term schedules. The shorter-term schedules are expressed against more granular operational locations than the longer-term schedules, because the hierarchy of operational locations is defined.
Combined with the proposed spatial information improvement, this makes it possible to define the spatial boundary of any given operational location, which as described above supports “geo-fencing.” For example, in mining it is important for safety to define blast exclusion zones. An operational location class could be defined for blast exclusion zones. Each blast exclusion zone could then be defined as an operational location belonging to the blast exclusion zone operational location class with a defined spatial boundary, which can then be respected by scheduling and execution systems.
Measurement uncertainty
Managing manufacturing operations depends heavily upon measurements made of physical processes as they are performed, as well as the resources (e.g., equipment\, personnel, and material) involved in those processes. No measurement is 100 percent accurate. The level of uncertainty of any given measurement may be material to a decision being made based on that measurement. Therefore, there is value in being able to communicate uncertainty information as part of the measurement.
For example, a lab may perform a test that measures the amount of moisture in a sample of ore. The test may yield a different measurement uncertainty depending upon the test method and lab equipment used. A measurement may be made quickly “in line,” with more accurate results arriving later from “offline” testing. Both the “in-line” and “offline” tests may measure the same properties of the sample, but with different levels of uncertainty.
It is proposed that all measurement quantities and values in ISA-95 carry information about the uncertainty of the measurement. In the example above, the uncertainty of the value of the moisture property of each lot would be reduced when the “offline” results arrive for the lot.
Test specification criteria and quality targets
Test specifications in ISA-95 define a set of tested properties of one or more resources. However, they do not currently provide a way to define the criteria against which the values of those tested properties are to be evaluated to determine a specific test outcome (such as a pass or fail outcome).
It is proposed that it be possible to define test criteria against a test specification for each test outcome that determines that outcome. For example, a quality target may be set requiring pH to be between 6.2 and 6.5. A “pass” outcome is therefore achieved if the criteria of “pH ≥ 6.2 and pH ≤ 6.5” is met, with a “fail” outcome in any other circumstance.
The ability to define test criteria and outcomes against a test specification also lets companies set quality targets for production runs. Where different quality targets must be set for each production run, a test specification may be defined against the scheduled production lot.
However, this approach is inadequate for industries where production is not scheduled against specific lots, which is common in process industries. It has therefore been proposed that it be possible to reference test specifications from any production material requirement in any production order. This allows companies to make a batch to the specification that is given in the production order for that batch.
Exciting additions
There are several exciting additions to ISA-95 currently proposed that will work to further the standard’s alignment with the principles of Industrie 4.0 and improve the ability for software product vendors to achieve interoperability between their products and other vendors’ products out of the box. It is hoped that this will better enable manufacturing organizations to realize real operational performance gains at a lower cost of implementation.
Reader Feedback
We want to hear from you! Please send us your comments and questions about this topic to InTechmagazine@isa.org.