The image below depicts the highest level modeling of the Open Industrial Interoperability Ecosystem™ (OIIE) information and systems architecture.
ISO 15926 is officially titled as Industrial automation systems and integration – Integration of life-cycle data for process plants including oil and gas production facilities and it is generally understood to be the official ISO ontology for all oil and gas information. Because this results in a rather broad ontology (taking into account all of the asset classes involved in upstream, downstream and pipelines), many experts working in capital projects on a cross industry basis have developed strategies to utilize this standard much more broadly. In effect, ISO 15926 is positioned to be a key reference information standard for most industry groups that are aggregated under the umbrella of critical infrastructure. While the general approach of leveraging ISO 15926 for all industry groups to which it is logically applicable makes a great deal of sense, this also results in a problem domain and scope that is almost unbounded. This has sometimes made it difficult to find ways to assist the efficient development and maturation of ISO 15926 and the associated Reference Data Libraries that are required for it to achieve its promise.
Standards developed by organizations included in the OpenO&M Initiative tend to have somewhat more defined scopes and many of the standards have matured through multiple release levels addressing both changes in industry requirements and changes in Information Technology which they leverage. In particular, this effort will be including the use of standards and specifications developed by ISA, MIMOSA, OAGi, OPC Foundation and WBF. The initial focus will be to meet the Operations and Maintenance (O&M) oriented interoperability requirements by building on a combination of systems engineering models based in MIMOSA CCOM, which can be automatically populated by a series of feeds of machine readable information from the engineering systems, which will be “speaking” various dialects of ISO 15926. The OpenO&M ws-ISBM and ws-CIR specifications will be used to provide supplier neutral connectivity between the various systems in a system of systems model focused on the information exchanges and events being propagated through Layer 3 of the Purdue Reference Model. As the system of systems is provisioned through this approach and the physical asset is prepared for Operations and Maintenance, the other key standards will play their various roles in support of the execution environment Plant (or Platform) to Business (P2B) Stack.
OIIE Simplified Systems Connectivity and Services Architecture
The figure below shows high-level systems architecture detailing generic system classes as well the connectivity and services within the system of systems. An information service bus approach is used for connectivity between applications. The goal of the information service bus is to support data exchanges in use cases that are designed around an event-driven architecture or service-oriented architecture within a single, consistent model. Recognition is given to the fact that automation and control networks for Layer 2 operations and below are typically segregated from corporate networks by a DMZ. A shared reference data management platform provides classes, taxonomies and ontologies for shared data context in data exchanges.
Primary Architecture Components
Supplier-provided productized ecosystem adapters
Moving the responsibility of the support model for application interfaces from the owner/operator to the supplier itself is both a key business and technical driver of supplier-provided productized ecosystem adapters. Suppliers will design, implement, test, self-certify, and support application interfaces used for data exchanges within the ecosystem. These applications must conform to the open standards specified by scenarios referenced within the OIIE Architecture. Suppliers are responsible for the support of the integrated adapters due to their productized nature, avoiding breakage of custom adapters.
Standard information and message models for representation of messages and service inputs/outputs
Open standards are used for information and message models within the OIIE Architecture. For layer three communications, the OAGIS BOD architecture is used to structure the message model. For layer two communications based on OPC UA, the OPC UA message model is used.
The type of information standard used depends on the domain of the exchange:
- Energistics PRODML is used to exchange product volume reports, production operation reports, well test reports, distributed temperature surveys, fluid analysis reports and wireline formation tests
- Energistics WITSML is used to exchange bottom hole assembly runs, cementing operations, geology and lithology of a wellbore, wellbore trajectories and coordinates, drill reports, fluid reports, formation markers, well log curves, mud logs, stimulation/fracture jobs, survey programs of a wellbore, and wellbore geometry
- ISO 15926 is used to exchange reference information including piping and instrumentation diagrams and data sheets from engineering
- ISO 22745/29002 is used to exchange characteristic data including data sheets from product suppliers
- MIMOSA CCOM is used to exchange lifecycle engineering of physical assets including functional segments, models, assets, data sheets, breakdown structures, mesh networks, types and taxonomies within operations and maintenance
- OPC UA is used to exchange real-time and historical time series data, alarms and events
Structured Digital Asset Interoperability Register (SDAIR) for ecosystem administration
The MIMOSA SDAIR specification addresses key aspects of OIIE ecosystem administration, with a focus on application-neutral technical and engineering oriented Master Data Management for life-cycle asset and facilities Management. The SDAIR enables the management of the system of record for systems of record, providing among other things, the basis for peer-to-peer based automated information provisioning for all applications that will be part of an OIIE instance. In the loosely coupled peer-to-peer OIIE, the SDAIR plays a significant role in Management of Change, by keeping a full audit log of all individual changes to asset configuration published by each OIIE compliant system. It also enables the management and mapping of Industry Standard Datasheet Definition (ISDD) instances to an owner/operator or supplier’s own unique internal standards for datasheet oriented properties. It accomplishes this in flexible manner, which enables linking to both systems views and multiple breakdown structure views of the plants, platforms and facilities being managed in any given OIIE instance. The systems views and breakdown structures can be imported from one or more designated OIIE-compliant Engineering Design systems of record. It also enables multiple, locally unique identifiers, to be federated to a single true UIID. All information elements, their relationships to each other and their properties are managed and exchanged based on the MIMOSA CCOM information model, which supports a full network model, where each element, defined relationship and their properties are associated with true UUIDs.
Common Interoperability Registry for identifier mapping of shared data between applications
The OpenO&M Web Service Common Interoperability Registry (ws-CIR) provides a 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.
The ws-CIR is used to map between one identification scheme and another for a given object. A common case is for an application interface adapter mapping between internal application identifiers and the data exchange scheme (e.g. MIMOSA CCOM). In this case, the ws-CIR would register two objects – one for the application and one for the data exchange scheme. The ws-CIR would store the identifier for each object, for example, an integer against the object in the application and a UUID for the object in MIMOSA CCOM. This then allows two applications to communicate with each other using shared identifiers which are then translatable to objects within their own internal application.
Service Directory for applications to register ecosystem service endpoints and transport configuration
The MIMOSA Service Directory specification provides a specification for a Web Service interface for interactions with a Service Directory. This supports the standardized registration and lookup of OIIE services with corresponding scopes and ISBM configuration information.
The Service Directory provides centralized configuration management for the routing of services within an ISBM. An administrator defines applications, the services that each application supports (e.g. publishing information or responding to requests), the scope of the service (e.g. a region or site, a data class such as equipment types, or for an instance of a data class such as a pump), and the corresponding ISBM endpoint, channel, topics, and tokens. An application would then register the services it can provide for a scope with the Service Directory and receive the corresponding ISBM configuration information. Subsequently, applications that need to subscribe or request data would query the Service Directory for a service type and scope and receive the applicable ISBM configuration.
Information Service Bus Model to provide message-based middleware layer based on standard services
The OpenO&M Information Service Bus Model (ISBM) provides a standard interface to any ESB or to any other message or file exchange system that offers guaranteed message and storage or caching of exchanged messages.
The ISBM allows an application to connect to a message middleware using consistent Web Service calls for publish/subscribe and request/response services. The publish/subscribe pattern supports event-driven architecture-based dialogs, while the request/response pattern supports service-oriented architecture-based dialogs. Applications agree upon a shared channels and topics before they can communicate using XML messages. Security tokens are exchanged between applications and an ISBM Service in advanced, and are used to ensure that only appropriate authorized applications can communicate on a given channel.
Ecosystem management and governance to achieve effective enterprise interoperability
While the above building blocks provide technical elements to construct an ecosystem, the ecosystem needs to be appropriately managed and governed in order to achieve any effective interoperability. Some of the key requirements for this to occur are:
- Single System of Record (SoR) for any given data class or object to ensure that the authoritative source for the class/object is known. This relationship may be particular to a certain scope, for example, to a certain region or site (e.g. SoR of data sheets for North America), data class (e.g. SoR of data sheets for pumps) or specific data object (e.g. SoR for data sheets for P-1000).
- Single Request Service Provider for a given scope to ensure against multiple service providers producing conflicting information.
- Supplier separation between key platforms to ensure suppliers do not try to subsume other application areas and subvert the ecosystem through the introduction of proprietary connections or performance manipulation.
- Appropriate caching to limit the number of requests to the ws-CIR and Service Registry and appropriate cache flushing management applied when changing identifiers or services.
