The definition of the MIMOSA SDAIR is a work in progress. MIMOSA welcomes all feedback and suggestions.

Structured Digital Asset Interoperability Registry

This document provides the functional requirements for a Structured Digital Asset Interoperability Registry (SDAIR), which addresses key aspects of OIIE ecosystem administration, with a focus on application neutral technical and engineering oriented MDM for Life-cycle Asset and Facilities Management, Operations and Maintenance. The basis for these functional requirements derive from industry identified requirements for maintaining separation between overall ecosystem administration and the various permutations of line of business applications, which may be included in any given instance of the OIIE, at any given moment in time. The core requirements have been refined by and validated in the OGI Pilot for the Oil & Gas Interoperability (OGI) Pilot Roadmap, which documents common data interoperability requirements between systems and standardized methods to address them. This will be an ongoing process as further OIIE Use Cases and Scenarios are defined, refined and validated in the OGI Pilot

Background

In the past, most of the As-Designed, As-Built, and As-Commissioned information that was produced during the Engineering, Procurement, and Construction (EPC) phase of a refinery/plant/platform/pipeline/rig was only available in unstructured digital document formats, e.g. PDF, Word documents, or non-standardized Excel spreadsheets, lacking the ability to be unambiguously read, exchanged and manipulated by computers. Though these documents are vital for humans and must be managed throughout the lifecycle of the infrastructure, the lack of corresponding structured digital format based on a non-proprietary industry standard results in a large problem for the O&M team as it begins the commissioning process. This greatly increases the burden on O&M staff in future years as they must continue to collect information “on the fly”, which could have been captured and put under proper management during the capital project.

Special projects are often required to get systems properly populated with information that could have been taken care of during the capital project, and systems often are never able to add the value designed into them by suppliers because they never have all of the needed setup data/information. The process is very time-consuming and error-prone. Often data entry errors occur and the resulting data in an O&M system is inaccurate and/or incomplete. Redundant data entry of the same data into multiple systems also results in a labor-intensive Management of Change (MOC) process. Additionally, it is difficult to verify consistent definitions and use of equivalent parameters across systems.

As an example, Piping and Instrumentation (P&ID) engineering drawing systems contain information about a functional location’s “requirements” in a refinery. A subset of this information is required to bootstrap O&M systems and then additional O&M parameters must be added and maintained. As parameters are adjusted during O&M, some of this information should be synchronized back to the source engineering systems. Throughout capital projects, all of this information is being continuously reviewed and often modified by both refinery personnel and contractors with responsibilities spanning from the capital project, through commissioning into the O&M phase of the refinery/plant/platform/pipeline/rig. Unfortunately, technical challenges frequently cause all parties involved to concentrate only on the information actually required to construct the asset, with a minimalist approach for populating O&M-oriented systems.

Once an asset is commissioned, all of the digital asset information begins to change on a relatively continuous basis, but frequently this takes place without the direct participation or even knowledge of the engineering systems teams. The processes put in place for the O&M phase of the asset’s life tend to focus on doing the minimum required to operate and maintain the asset. This results in an information and knowledge gap which already exists at commissioning beginning to grow on a continuous basis (with small bursts of growth taking place in conjunction with turnarounds and other activities which take on the characteristics of small capital projects).

Actual O&M data arising out of the O&M systems on a continuous basis is being generated at ever accelerating rates due to the proliferation of sensors, but this torrent of data is usually not being used to the degree it could be to add value and manage risks because it is proprietary and not properly associated with the configuration of the refinery. When configuration changes take place, the context for O&M data being captured and analyzed also changes, so without having a true MOC process in place, all O&M activities begin to become more difficult to optimize. As the MOC knowledge gap grows, the ability to manage risks in an efficient way declines as risk models require accurate configuration information in order to provide useful guidance to management.

General Requirements

The SDAIR is an active manager of technical object identification, its distributed System of Record data sources, and technical object meta-data required for engineering and O&M system interoperability. In order to establish and maintain an instance of an OIIE, both a MIMOSA SDAIR and a MIMOSA Service Directory (which manages Service of Record, based on ISBM topics and channels) are are required to manage a number of supplier and application neutral ecosystem administration functions, so that all applications in the OIIE instance at any given moment in time can properly participate in the defined system of systems. Collectively, this approach allows an OIIE administrator to have a completely standardized way of configuring and managing their own OIIE instance(s).

The SDAIR ties together functional locations, serialized equipment assets, product make/models, breakdown structures, topologies and data sheets together. Instead of a data warehousing-style approach of copying all data to a centralized repository, the SDAIR uses a system of “pointers” to reference data in other systems. This lightweight approach allows decentralized master data management leading to greater flexibility, yet ensuring sufficient coordination and data quality assurance.

Mandatory SDAIR, functions include:

  • Mapping multiple, human readable Tag Identifiers to single, immutable UUIDs- Many brownfield plants, fields and platforms will have multiple generations of upgrades and additions which have been managed by differing project teams, which may have used differing codification schemes for the human readable identifiers associated with functional locations and unique assets. Different areas and units often have different codification/tagging schemes and the same functional location or asset may also have multiple tags (and their identifiers) associated with multiple different applications in the owner/operators application landscape. In all cases, the actual interoperable information exchanges in an OIIE are to be based on the immutable UUIDs, not on the human readable (and changeable) identifiers they are associated with. This approach enables interoperability to be sustained, even if new tagging schemes are deployed in the future and it means that multiple existing schemes can stay in place, while still enabling interoperability. An SDAIR must be able to manage these relationships, based on the MIMOSA CCOM information model.
  • Maintaining the Primary Enterprise Breakdown structure used for OIIE administration purposes- Many applications are capable of maintaining one or more breakdown structures, but they often do not have the ability to fully support other breakdown structures which are not applicable to their own functional domain or which are beyond the scope of the plant, platform or facility or sub-unit thereof, for which they are responsible at any given moment in time. An SDAIR must have the capability to generate and maintain the Primary Enterprise Breakdown Structure, so that it can be used for centralized administration purposes, including mapping of applications and ISDD properties to sites, areas and units.
  • Managing the ISDD instances and providing the mapping functions to the corresponding portions of the enterprise breakdown structures, associated with any specific OIIE instance- This mandatory functional capability enables an OIIE administrator to manage the instances of ISSDs, which are used by the enterprise associated with the OIIE instance. The ISDD instances can be extended for the enterprise requirements, while also maintaining version management. It also enables those ISDD instances to be mapped to his entire enterprise, using a breakdown structure, to support detailed mapping to differing internal conventions for different plants, platforms or facilities or any sub-units thereof, at any given moment in time.

Optional, but important SDAIR functions include:

  • Maintaining an MOC Audit Trail for every OIIE MOC event which is published by every OIIE compliant application shown to be a valid system of record for such an event- While this is not currently considered to be a mandatory function for an SDAIR, as it is not directly responsible for managing the OIIE critical meta data environment, it is a very powerful and useful function in the peer to peer oriented OIIE. Many different applications can be designated to be the systems of record for different types of information in different areas of the enterprise, at any given moment in time, using the mandatory function described above. The MOC audit trail allows every change published by each of those authorized systems to be logged and then used for audit purposes.
  • Recursing back to itself as a designated SoR for important OIIE information- This may be used in instances where O&M systems are insufficient in providing such functionality or where the SDAIR is elected as a staging area during a capital project before transferring custody to the more permanent SoRwhich has no other designated system of record<l/li>
  • Maintaining an unlimited number of both breakdown structures and systems views for any given OIIE Instance
  • Maintaining an accurate record of the relationship between functional locations and uniquely defined assets

The SDAIR shall implement the functions as dictated by the REG-LOCATION, REG-ASSET and REG-MATERIAL/PRODUCT systems in the OIIE Use Cases. This includes a native OpenO&M Information Service Bus Model adapter with support for publish-subscribe and request-response. It shall also import and export in compliance with the MIMOSA CCOM data structures for Engineering Handover and O&M Provisioning as directed by Use Case 1 and Use Case 10.

CRUD Support

The SDAIR shall support both read-only access and read/write access to the register, with create, update, soft-delete, and hard-delete functionality as dictated by the REG-LOCATION, REG-ASSET and REG-PRODUCT systems in the OIIE Use Cases.

Management of Change Logging / Auditing Support

The SDAIR shall log when each data item was created, updated, and deleted and by which user account.

System of Record CRUD Management

The SDAIR shall manage the creation, reading, update, and delete (CRUD) of System of Records for the enterprise and manage the association of one System of Record for each data set collected in an enterprise, along with each system’s internal identification for unambiguous direct access. The System of Record is the source of truth for that data set. The SDAIR is the System of Record for all other Systems of Record – providing a registry that other systems can query in order to determine if incoming messages are authorizes sources of truth for a given data set.

Universally-Unique Identifier (UUID) Support for Objects

The SDAIR shall support the assignment, registration and system-wide use of an ISO/IEC 9834-8 compliant Universally Unique Identifier (UUID) for all technical objects, which are used to identify an object throughout its life. These UUIDs can be used by all enterprise or plant-level systems to identify and reference an entity regardless of whether an entity has been assigned multiple, disparate identifiers throughout its lifetime. By assigning each entity a UUID, it becomes possible to refer to each entity as an individual, each having its own characteristics, life history and information trail, flow pattern through the real world and its own sequence of interactions with other entities. This repository of UUIDs, each referencing its own unique entity, is a crucial component for the SDAIR’s task of acting as a principal data repository for every unique entity from a plant or enterprise level.

Information Scope

The SDAIR shall management any asset-related master information that must be shared between two or more systems. This includes:

  • Organization, site, and functional locations
  • Breakdown structures and mesh networks
  • Serialized assets
  • Location-asset associations
  • Manufacturers and make/models
  • Data sheets, templates and properties
  • Bills of material
  • Documents
  • Systems (including applications and databases)
  • Any reference data (types/classes) that is referenced by the above objects
  • Reference data sets utilized by sites and systems

MIMOSA OIIE Use Case support

As specified by the REG-LOCATION, REG-ASSET and REG-MATERIAL/PRODUCT requirements in the OIIE Use Cases, the SDAIR shall support:

  • Both the OpenO&M ws-ISBM publish-subscribe and request-response models
  • The MIMOSA CCOM BOD imports and exports for the corresponding CCOM information it internally manages.

This gives all systems that are plugged into the ISBM a principal reference location regarding the status/location/history of any particular technical object in a plant or enterprise. The SDAIR shall keep data in these connected systems fresh by publishing events regarding major or even specific modification to these entities onto the ISBM as specified in the OIIE Use Cases.

The SDAIR may support:

  • Exchanges with a MIMOSA Service Directory implementation to acquire ws-ISBM configuration
  • Direct import of ISO 15926 formats used within the scenarios of Use Case 1, bypassing transformation to MIMOSA CCOM

Reference Data Support

The SDAIR shall support the import of reference data from any of the following standards in a CCOM format:

  • ISO 14224 Reference Data Support
  • ISO 22745 / ISO 29002 / eOTD Standards Support
  • MIMOSA CCOM Reference Data Library

The SDAIR shall be able to reference other Reference Data Libraries (including ISO 15926 Reference Data Libraries) as the System of Record for any managed reference data.

Detailed Requirements from OIIE Use Cases

The SDAIR shall support the management of major structured Digital Assets as specified in the OIIE Use Cases.

Requirements from Enterprise Capital Project Data Strategy

Enterprise-wide Taxonomy CRUD Management

Supporting the MIMOSA CCOM model for taxonomy management, the SDAIR shall allow for CRUD management of multiple taxonomies referencing a common set of type classifications in an enterprise. The SDAIR shall enable support of ISO 14224 classifications and other industry standard entries with associated ISO 15926 reference data identification. The SDAIR shall also support CRUD management of customized enterprise taxonomies.

The SDAIR shall support enterprise-wide taxonomies for:

  • TO Classes – Functional Location Classes and Equipment Classes
  • Property Types
  • Measurement Location Types
  • Units of Measure

Enterprise-wide TO Class Data Sheet Templates CRUD Management with Inheritance

The SDAIR shall be able to create Data Sheet Groups with Properties on a named Data Sheet Template which is associated with a TO Class and shall support the inheritance of any pre-defined Data Sheet Template from a predefined TO class (normally from a more generic class) and support additional Data Sheet Group CRUD.

Enterprise-wide TO Class Measurement Location Set Templates CRUD Management with Inheritance

The SDAIR shall be able to create Groups with Measurement Locations on a named Measurement Location Set Template which is associated with a TO Class and shall support the inheritance of any pre-defined Measurement Location Set Template from a predefined TO class (normally from a more generic class) and support additional Measurement Location Set CRUD.

Requirements from Engineering Design

The SDAIR shall support the ability to visualize and re-define breakdown structures and plant hierarchies to any level of detail. The SDAIR shall support multiple TO breakdowns of an enterprise, site, area, work center and work unit and be able to use TO entries from these structures to create additional breakdown structures. In addition, it shall support constituent TO components.