MIMOSA is defining and validating the Open Industrial Interoperability Ecosystem™ (OIIE) specification in cooperation with  OpenO&M Initiative Members and Standards Leadership Council Members including ISA, MESA/B2MML, OPC Foundation, POSC Caesar Association, PPDM and USPI.  The OIIE™ specification is an architecture-centric specification for a supplier-neutral industrial digital ecosystem which is defined by supplier-neutral standards and specifications used in a consistent, repeatable and scalable manner.  The OIIE specification is also a primary informative reference for  ISO 18101 (the ISO OGI Technical Specification).

OIIE™ OGI Pilot

The OIIE OGI Pilot is an instance of the OIIE specification which is developed and maintained by MIMOSA.ORG in cooperation with other industry standards associations.  It uses sets of Oil and Gas Asset Classes contributed to MIMOSA by its members and industry cooperation partners, while all other aspects of the test-bed ecosystem are standard for any OIIE instance.  The OIIE OGI Pilot is an interoperability and digitalization testbed supporting the on-going development of the OIIE specification.  The OIIE OGI Pilot also serves as the testbed supporting ISO TC 184/WG 6 in the development of emerging standard ISO 18101 (the ISO OGI Technical Specification).

MIMOSA manages a range of projects and working groups to ensure the specifications stay relevant with new technologies and continue to provide interoperability with partner organizations through companion specifications.

MIMOSA is hosting an OpenO&M Joint Working Group to initiate the work to add RESTful Services (with a RESTful API) to the existing MIMOSA and OpenO&M specifications which are based on SOAP and XML Schema and used as the basis for the Open Industrial Interoperability Ecosystem (OIIE).

The Joint Working Group is initially focused on the update of the OpenO&M ISBM specification, which was developed under the umbrella of the OpenO&M Initiative. This work is being done in coordination with the ISA-95 and IEC 62264 MSM Specifications, with the intent of maintaining alignment, while also addressing new functional and non-functional requirements being introduced by the on-going OIIE OGI Pilot.

Initial Investigations are evaluating the current Internet Draft specification for JSON Schema and OpenAPI as options to be considered as an alternative for XML Schema. Since unlike much of the internet community MIMOSA is very focused on enabling Standards Based Interoperability for complex Industrial Systems and Systems of Systems, we are also evaluating the continued use of our XML Schema, with a REST API as a logical path forward for the relatively complex events which are inherently necessary in the OIIE. Contact MIMOSA if you are interested in participating.

The ISDD Project will capture existing Industry Standard Datasheets (ISDs) as machine interpretable business objects that are then fully re-usable, mappable and extensible. The effort will capture high-value properties from existing, high-value ISDs published by credible industry associations including API, ASME, IEC, ISA, ISO, NORSOK and PIP.

As ISDs were developed by Subject Matter Experts (SMEs) in various working groups by various industry associations, they used a variety of differing conventions for defining document and content structure. While some of the ISDs are available in the form of spreadsheets, the spreadsheets were almost never developed in a manner that would enable direct machine interpretability of the information they contain. This makes it very difficult to directly reuse the ISDs, without clear guidance from these same or similar SMEs, who are very familiar with all of the associated meta knowledge.

In spite of these limitations, these ISDs remain the seminal industry documents, which most process industry owner/operators and their supply chain partners use as reference documents, while trying to capture, manage and exchange the related data sets they require in order to properly support the full lifecycle of their plants, platforms and facilities. As such, while these ISDs represent the only supplier and owner/operator neutral way of identifying the data that is required, the existing process for using them is labor intensive, redundant, error prone and incomplete. This has a particularly negative impact on the Operations and Maintenance of the associated long lived physical assets, because the information needed to properly provision, integrate, operate and maintain them is not readily available in a directly reusable, supplier-neutral, machine interpretable fashion. This results in both direct costs and opportunity costs on a recurring basis over the entire life-cycle of those assets, long after the end of the capital project.

If you are interested in participating or learning more, please contact us for more information.

The joint MIMOSA and OPC Foundation CCOM OPC UA Working Group will develop an OPC UA Information Model for CCOM. The information model specified by CCOM will be defined in a UA companion specification using OPC UA constructs for the purpose of exposing CCOM information to OPC UA applications, with an initial focus on existing Use Cases relating to information exchange to and from the control system.  This will combine existing strengths of each organization for some near-term wins, where OPC UA is used to bring information from the factory floor and where MIMOSA plays its traditional role in Asset Management.

 The working group will deliver:

• An OPC UA Information Model for CCOM (Standard OPC UA companion specification, Nodeset file and prototype implementation)
• A write up for the OPC Wiki describing the Companion specification
• A trade show demonstration and information material

If you would like to contribute to this industry specification, please contact MIMOSA.

The following specifications are maintained by the MIMOSA Technical Committee:

The following specification are maintained by the OpenO&M Joint Working Group:

Web Service Information Service Bus Model

The OpenO&M Web Service Information Service Bus Model (ws-ISBM) is an open standard that provides a vendor-neutral interface to an Enterprise Service Bus (ESB) by defining standard on-ramp and off-ramp SOA services that hide the specific ESB implementation. It is an open, supplier-neutral standard that can be used in any industry, as it allows the transmission of any information model, including MIMOSA CCOM, ISO 15926, MESA B2MML and OAGIS.

Specification

The ws-ISBM specification is available on the OpenO&M website. All releases of the ws-ISBM can also be downloaded directly from the MIMOSA ws-ISBM repository. All feedback is welcome.

Background

The typical IT environment is a federation of systems. The term “federation” in the IT world is applied to collections of applications from multiple vendors that work together to support business processes. A federation may include separate applications for engineering, operations, maintenance, material management, order processing, supply chain management, customer relations, and production scheduling. Even when a company has selected a primary Enterprise Resource Planning (ERP) vendor, there is often a federation of legacy systems supporting unique business processes. Federated systems are expensive and integration efforts are often a major portion of IT budgets. An increasingly common method to reduce integration costs is an Enterprise Service Bus (ESB). These are not electronic busses in the sense of an electrical backplane bus. Instead, they are specialized applications that run on redundant servers and act as concentrators and distributors of data. Manufacturing systems that shall exchange data with business systems need to connect to the company’s ESB.

Enterprise Service Buses are an architectural concept that includes proprietary web service standards, message based communications, message routing capabilities, and service discovery mechanisms. All of the ESB elements are normally based on XML technologies and web services. The data transfer element handles transporting XML messages from one application to another through the common server. This eliminates point-to-point interfaces and provides a centralized mechanism to manage and view inter-application communication.

Many enterprise IT suppliers offer ESBs; however, a few companies have also built their own ESB systems focused on their unique integration problems. Once a company has selected an ESB system, the IT department will attempt to have all applications that exchange data (including manufacturing applications) use the ESB instead of implementing point-to-point connections. Unfortunately, there is little interoperability between different ESB systems, so each application interface shall be customized for the chosen ESB.

In order to further interoperability and allow software suppliers to build in such capability into their products, the OpenO&M ws-ISBM provides a standard interface or an abstract layer to any ESB as seen in the following diagram:

Development History

The OpenO&M ISBM specification was jointly developed by ISA and MIMOSA under the MIMOSA Technical Committee, rotating between member organizations to host conference calls. The specification was refined through practical use in the OGI Pilot, where both provider/consumer and service provider implementations were undertaken by multiple software suppliers across different product classes. The ISBM specification was then extracted into two specifications: an abstract model that was published as ISA-95 Part 6 and an implementation specification based on SOAP Web Services that was published as OpenO&M ws-ISBM. This process was undertaken in order to provide a pathway to international standardization of the abstract model via IEC, as well as allowing multiple implementation specifications using different technologies (e.g. SOAP Web Services vs JSON/REST) but based on a common abstract model.

Web Service Common Interoperability Registry

The OpenO&M Web Service Common Interoperability Registry (ws-CIR) is an open standard that provides a vendor-neutral specification for a Web Service interface for interactions with an object identification registry. This supports the harmonization and standardized lookup of locally-unique identifiers for an identical object (including data dictionary classifications and attributes) used in multiple information systems. Each system typically maintains its own set of identifiers for its objects. For example, System A may use a set of auto-incrementing integers; System B may use strings; System C may use UUIDs. As the objects in each of these systems may be the same business object (albeit instantiated in three different systems), in order to link the three objects, the ws-CIR is used to define an overarching identifier.

The specification details a XML data structures and a set of SOAP Web Services that OpenO&M systems should support so that systems throughout an enterprise can harmonize and cross-reference their internal system objects. The server supports the harmonization of distinct, semantically-meaningful identifiers for the same tangible objects across multiple systems by generating a non-semantically meaningful 128-bit OpenO&M Common Interoperability Registry ID (CIRID). The CIRID is generated in compliance with the time-based generation mechanism of the Universal Unique IDentifier (UUID) definition found in ISO/IEC 9834-8:2008.

Each compliant system should utilize the ws-CIR when creating new objects in their local system, associating their locally-unique identifier with the CIRID. Once all systems have registered their objects with the ws-CIR and an equivalency matching process has been conducted, the ws-CIR can be used to translate between identifiers.

Status

The OpenO&M ws-CIR specification is currently in draft and is being taken to international standardization to IEC via ISA-95. This involves the extraction of an abstract model (ISA-95 Part 7) and extraction of an implementation model using SOAP Web Services, using the same development process as the OpenO&M ws-ISBM.

Specification

The ws-CIR specification is available on the OpenO&M website. All releases of the ws-CIR can also be downloaded directly from the MIMOSA ws-CIR repository. All feedback is welcome.