The Open Industrial Interoperability Ecosystem™ (OIIE) enables a major paradigm shift from traditional systems integration methods, to standards-based interoperability, in asset intensive industries, including process industries, integrated energy, aerospace and defense and other key critical infrastructure sectors.
The OIIE™ digital ecosystem is a supplier-neutral, industrial interoperability ecosystem, which provides a pragmatic alternative to the status quo, enabling the use of Commercial Off The Shelf (COTS) applications from multiple suppliers, as well as bespoke applications. It is defined by a standardized Industry Solutions Architecture, which enables implementations of OIIE instances for both owner/operators and their major supply chain partners that are adaptable, repeatable, scalable and sustainable at substantially lower cost than traditional methods.
The OIIE is an outgrowth of several related industry standardization activities, each of which is addressing a part of the industries requirements for standards-based interoperability. The OIIE brings these individual efforts together, with the direct participation and support of multiple participating industry standards organizations. Major parts of the OIIE include standards associated with the OpenO&M Initiative and with ISO 15926. The OIIE uses these existing standards in combination with each other, to meet the identified systems and information interoperability requirements for use cases which are defined and prioritized by the industries which are served.
Background
The OIIE was born from the collective desire of owner/operators to reduce their reliance on expensive, fragile, custom application integration, and move toward an interoperability paradigm that can be employed across a range of targeted industries. Traditionally, organizations in these sectors have been forced to use large scale systems integration methods, if they needed their complex applications and systems to work with each other in an integrated manner. This resulted in solutions which were relatively fragile and inflexible, while also being expensive and difficult to sustain.
Starting in 2000, with the MIMOSA Information Network, which was prototyped in conjunction with the MIMOSA Open Systems Architecture for Condition Based Maintenance (OSA-CBM) , using funding from the Office of Naval Research, MIMOSA has been leading efforts to establish pragmatic standards, specifications and methods so that complex platforms, plants and facilities can be better modeled, monitored and managed, fully based on published, open, supplier-neutral standards. The OSA-CBM program was a Dual Use Technology program, established with the intent of developing standards which could be shared with industry. This effort was followed by a similar effort with the US Army Collaborative Telemaintenance Program in 2002, using US Army CECOM funding. Both efforts were based on a combination of published MIMOSA open standards and specifications along with other published open standards and specifications, specifically including the use of internet related standards, along with major defacto standards for the IT platforms of choice in both military and industrial environments.
Related efforts within industry began taking place as early as 2004, when MIMOSA, OPC Foundation and the National Institute of Building Sciences organized a major standards-based interoperability demonstration at the 2004 International Maintenance Conference in December of that year. This initial collaboration and resulting conversations resulted in the formation of the OpenO&M Initiative in 2007, in which ISA, MIMOSA, OAGi, OPC Foundation and the WBF B2MML groups all agreed to cooperate to help enable the development of better solutions properly leveraging true standards based interoperability. In addition to working on their existing standards in a more cooperative fashion, the participants saw the need to fill a significant gap in existing standards, which resulted in the development and publication of the OpenO&M Information Service Bus Model (ISBM) specification in lat 2014. Another specification, the OpenO&M Common Interoperability Register (CIR) is now under development to provide a standardized object name resolution service, with a candidate specification having been published in 2015.
Starting in late 2009, MIMOSA developed the beginnings of what has now become the Oil and Gas Interoperability (OGI) Pilot, in conjunction with the ISA Expo 2009. The effort showcased what could then be accomplished in full life-cycle,standards-based interoperability, with information flowing from a capital project to the Operations and Maintenance systems, then proceeding into an OpenO&M oriented interoperability demonstration. The actual OGI Pilot was initiated in 2010 and it continues to be managed by MIMOSA, functioning as an R&D test-bed for what has now grown into the OIIE, based on oil and gas industry assets. Various owner/operators have also run internal Proof of Concept exercises and analysis in 2014 and 2015.
Due to the hard collective work which has been done over many years, the OIIE is now at the point that it can start to be deployed in production environments, even as it continues to be developed, extended and enhanced. MIMOSA collaboratively leads the OIIE effort in conjunction with other industry standards bodies, industry associations, software suppliers, system integrators, EPC contractors and academia.
Guiding Principles
A great deal has been learned in conjunction with all of the efforts mentioned above. Often, we have learned as much or more from failures and subsequent analysis of the causes than from successes.
One early fundamental realization was that no single standards organization could realistically develop, publish and manage all of the standards that were needed for a pragmatic solutions to standards-based interoperability. There is a complex mosaic of relevant existing and emerging IT and IM standards, each of which is under some form of version management, as they evolve to meet specific requirements. It simply makes much more sense to try to identify these standards and use them together with each other in a repeatable scalable manner, rather than constantly re-inventing wheels.
A more nuanced, but equally important realization was the need to work directly with the standards organizations who develop and publish the incorporated standards, so they still manage their own standards, but with an eye towards their combined use with the other standards in the OIIE. This is because we want each standards body to maintain their own standards and to also work with us , to help ensure the incorporated standards really do work together as is intended, without breaking each others mission critical features. Each standards body gains from this kind of mutually beneficial cooperation, so there is some incentive to actually maintain the effort.
The emergence of the ecosystem model, which is now generally recognized in the mobile platform markets for consumer oriented technology, is dominated by two major suppliers, with two differing business and technology models. One of them is totally proprietary and is thus tightly controlled, with highly predictable quality, but is also inherently constrained by the single supplier being in total control of every aspect of the ecosystem, which simply does not work for the heterogeneous supplier model in industrial systems and applications. The other option leverages open source, but this has many problems of its own, including fragmentation of the associated code bases and the fact that most heavy industry owner/operators want to buy and use COTS applications and systems, with commercial support models. This led to a key realization that another approach was needed for industrial systems, even though we also wished to leverage the general principles of the ecosystem model.
- The OIIE team has thus chosen to define and leverage an “open specification” model, where every aspect of the OIIE can be COTS, while also following a set of specifications, standards and methods ensuring defined levels of interoperability for identified use cases.
- Individual suppliers are free to use an open source model for their own applications and systems, if they chose to do so, but it is not mandatory, as the open specification model follows the System of Systems model, used in aerospace and defense industries, which focuses on how systems interact with each other, rather than on their internals.
- In keeping with the open specification model described above, all OIIE compliant applications must have interfaces which are compliant with the specifications, standards, methods and conventions in the OIIE, but because the OIIE is standardized, COTS application providers can implement these interfaces as COTS adapters for their existing applications or as native interfaces for new applications they may build in the future.
- Since the OIIE is designed as a supplier and application neutral ecosystem, the ecosystem administration functions and interfaces are defined separately from the collection of systems interface definitions for line of business applications in the OIIE.
- Together, the bulleted items immediately above ensure that all OIIE compliant applications from all suppliers will share the same OIIE specified meta data, systems of record and services of record definitions, which are managed for each instance of an OIIE, by an OIIE administrator working for the adopting organization.
The guiding principles discussed above shape the cooperative methods which are used to establish all aspects of the OIIE, so that it can be developed, deployed and improved in a repeatable, scalable, adaptable and sustainable manner.
Solutions Architecture
The OIIE is characterized by a solutions architecture framework for developing an enterprise architecture that employs system-of-systems interoperability. The foundation of an interoperability architecture is standards, and the OIIE uses a portfolio approach in leveraging both international and industry standards. The selection of standards is based on their capability to meet the industry-specified requirements, as well as levels of industry adoption and community engagement.
A Use Case-based approach is used to elicit common information exchange requirements from industry. These Use Cases are associated with Interoperability Scenarios that specify the systems involved, event triggers, data content, data formats and exchange mechanisms that are required to meet the industry requirements. While the Use Cases are contextualized within a representative business process, the business process itself is not standardized by the OIIE in recognition that business processes can widely differ across organisations and industries.
The OIIE prescribes the use of open, supplier-/vendor-neutral standards for several important components, including:
- An information message/service bus to provide supplier-/vendor-neutral middleware-based data transport/conveyance
- Information and message models for the representation of messages and service inputs/outputs
- Reference data for consensual interpretation of information
- A service directory to register ecosystem applications, manage service of record, and exchange service endpoint and transport configuration
- An object registry that maintains identifier mappings between internal application identifiers and canonical identifiers used as part of standard information models
- An asset interoperability register containing identifiers for all physical and logical assets and an unlimited number of relationships between them, including both full networks and breakdowns structures of any kind
Standardization of the above components allows industries to collectively reduce capital and operating costs as well as risks, because software required to support the OIIE can be developed, tested, and supported using standard adaptors and plug-and-play interoperability rather than traditional systems integration methods.
All of the standard specifications are services/performance oriented, following the “black box” model from the systems engineering community. You can build them any way you wish, but they must function as prescribed.
