MIMOSA is a 501 (c) 6 not-for-profit industry trade association dedicated to developing and encouraging the adoption of open, supplier-neutral IT and IM standards enabling interoperability and digital transformation for asset lifecycle management spanning plants, platforms and facilities. MIMOSA standards support key functional and interoperability requirements for Critical Infrastructure Management on a cross-sector basis, addressing the highly heterogeneous and interdependent nature of critical infrastructure. MIMOSA standards and specifications enable Digital Twins to be defined and maintained on a supplier-neutral basis, while also using those Digital Twins to provide Context for Big Data (IIOT and other sensor-related data) and Analytics. Mutually beneficial collaboration with other industry associations provides a pragmatic basis for Industrial Digital Transformation based on the Open Industrial Interoperability Ecosystem (OIIE). Explore the Resource Guide for an overview of MIMOSA standards, specifications, and initiatives. Visit our Collaborations page to learn about the working groups hosted by MIMOSA and partner organisations.
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).
Learn MoreOIIE™ 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).
News
Events
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 OIIE 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. Like 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 CII/MIMOSA Joint Working Group aims to develop best practices for standards based interoperability in capital projects leveraging the combined strengths of CII and MIMOSA. It will develop formal OIIE Use Cases for capital projects based on Industry Functional Requirements developed by CII, starting with those associated with Advanced Work Packaging (AWP). These OIIE Use Cases will be validated in the OIIE Oil and Gas Interoperability (OGI) Pilot before they are published and licensed for use on a world-wide royalty free basis. Once the jointly developed OIIE Use Cases are validated in the pilot, CII and MIMOSA intend to submit them to ISO TC 184/WG 6 for inclusion in future parts of ISO 18101.
The Joint Working Group is governed by the MOU between MIMOSA and CII, announced in July 2020, in which agreement was made to use the Open Industrial Interoperability Ecosystem (OIIE) as the interoperability framework for CII best practices.
The JWG reports to CII Interoperability Subcommittee to facilitate the cooperation between various interoperability initiatives and ensure alignment with CII priorities and industry requirements.
The JWG meets 2nd and 4th Monday every month at 8 am Central Time. If you would like to participate, contact us.
The OIIE Capital Projects Working Group, co-led by Independent Project Analysis (IPA) and MIMOSA, aims to facilitate the interoperability of digital tools used to develop and execute industrial-sector capital projects. The Working Group was launched in December 2020, which began the process of gathering the requirements and opportunities from participants that will guide the Working Group’s short and long-term efforts.
A survey was conducted to determine the highest priority needs of the industry. The following three sub-teams were formed within the working group based on the feedback received in the survey:
- Cost Estimation
- Purchasing
- Asset Installation
Each sub-team meets 2nd and 4th Tuesdays at 7 am Central Time every month, where subject matter experts provide the industry input and requirements, which are used to develop OIIE Use Cases to be piloted using OIIE OGI Pilot.
The main working group meets once 3rd Tuesday every month at 7 am Central Time where sub-teams report on their progress and industry partners share knowledge and provide input to set priorities for the group.
If you are interested in participating in this working group or any of the sub-teams, please register here. (Note: the event series is over for 2021 and a new event series will be created in the 2022 New Year)
The Open Industrial Interoperability Ecosystem (OIIE) Australian Working Group, co-developed by NERA and MIMOSA, aims to leverage and enhance the OIIE specifications by stimulating innovation from Australian SMEs, operators, and academia. This working group provides Australian organizations with a vehicle to participate in the development and use of emerging interoperability standards which are critical to the future productivity of the mining and energy resources sectors.
This working group was launched in April 2020 by organizing webinars to introduce the working group and OIIE specifications to Australian industry. Refer to the white paper to read more about the objectives of this working group and the benefits that OIIE specifications can bring to the Australian mining and energy resources sector.
A series of workshops have been conducted for the working group participants to understand the concepts and implementations of OIIE Components and Specifications.
Participants of this working group leverage the OIIE instances made available through The Australian OIIE Interoperability Laboratory hosted by the Industrial AI Research Centre, University of South Australia. This shared infrastructure promotes the development, testing, and eventually deployment of interoperable solutions by participants.
As part of the initial efforts of this working group, a 3 year project was established in the FEnEx CRC to develop and pilot Open Specifications for Analytics Interoperability with multiple Australian industry and government partners..
If you are interested in participating in this working group, contact us.
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:
ISBM
The OpenO&M ISBM is an open standard that provides a vendor-neutral interface to the communication infrastructure of the OIIE™ Architecture. 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 ISBM specification is available on the OpenO&M website. All releases of the ISBM can also be downloaded directly from the MIMOSA 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.