This scenario details the batch handover of design information that occurs most often at two gates in the capital project lifecycle – Approved for Construction and Approved for Commissioning & Closeout. This information originates from the Engineering Design Systems (which stores Plant Breakdown Structures, Logical P&IDs and PFDs) and is sent to the O&M Structural Registry.
Actors
| Engineering Design System | Send plant breakdown structure, logical P&ID and PFD topology data |
|---|---|
| Structural Registry | Receive and register O&M-related engineering network, segment and tag data |
| Commissioning Team | Receive and review the plant breakdown structure, logical P&ID and PFD topology and trigger the pre-commissioning of O&M systems |
Triggers
The primary information flows typically occur after passing the Approved for Construction (representing Issued for Construction data) and Approved for Commissioning & Closeout (representing As-Built data) gates. The handover of information is conducted on a systems basis – as different sections of the plant are approved and signed-off, the related and relevant information can then be incrementally exchanged.
In instances where there are modifications made to the logical structure of the plant between Issued For Construction and As-Built datasets, data revisions are tracked from the data previously sent to the O&M Register. This revision tracking may use the same mechanism as used in Use Case 2 for updates.
Data Content
The information exchanged are those necessary to properly provision O&M systems. Master data includes several functional sub-categories. The logical structural arrangement of the plant (hereafter referred to as a topology) is derived from P&ID and PFD information and forms the basis for the asset registry of many O&M. For the components in the structure, it should contain the identification properties (ID, tag, name), categorical properties (in relation to the reference data described above), interconnections, flow and intended physical sequence of equipment, data sheet properties that represent the requirements of installed equipment, controls and instrumentation, and associated metadata. Where topologies show interconnections between functional segments, breakdown structures show decomposition of segments. Breakdown structures are a hierarchical view of a system to show the composition of the functional segment.
To provide a level of traceability and diagrammatic arrangement for systems that require it (typically HMI applications), the relationship between the logical structural elements and their originating diagram as well as associated data (e.g. positioning and scale) are also exchanged. Document data is also included, such as the information in the title block, canvas size and origin position, to provide context.
P&ID Data Requirements
- Functional location, identifier, tag and classification
- Engineering properties
- Transmitter OPC tag
- Transmitter range and unit of measure
- Plant breakdown structure
- Nozzles/ports and classification
- Directed connections between nozzles/ports
- Canvas dimensions
- X, Y coordinates for functional locations
- Symbol orientation
Data Formats
The data published from and sent by the Engineering Design System must comply with ISO 15926 standardized templates and reference data.
The data published to and received by the Structural Registry must conform to MIMOSA CCOM BODs.
MIMOSA CCOM Reference Types
For the purposes of reference data management, the following MIMOSA CCOM types may be referenced:
- AssetType
- AttributeType
- BreakdownStructureType
- DataSheetType
- MeasurementLocationType
- MeshType
- NetworkConnectionType
- SegmentType
- UnitType
MIMOSA CCOM Business Object Documents
The following MIMOSA CCOM BODs should be supported:
- SyncEngineeringDiagram
- SyncSegments
- SyncBreakdownStructures
Data Formats
Transform Engine
Data transformation is required for this scenario and the OpenO&M-ISO 15926 Transform Engine converts the necessary data from an ISO 15926 format in the Reference Environment to the MIMOSA OSA-EAI CCOM in the Execution Environment. A one-way mapping from ISO 15926 to MIMOSA CCOM is required. Identifier transformation is only required for updates to data already sent from the Reference Environment to the Execution Environment.
Transformation Rules
- Plant Items become Segments with the identifier placed in the IDInInfoSource field (with a corresponding RegistrationInfoSource); tag placed in the Tag field and classification mapped to a SegmentType.
- Attributes/properties for a functional location need to be placed on an Engineering Data Sheet. The data sheet can have a single top-level parameter group with all Attributes contained within that group.
- For instruments that are allocated a range, these are placed on an Engineering Data Sheet.
- Transmitters have a corresponding Measurement Location created. Any OPC tag properties are placed in the MeasurementSourceAddress field.
- Nozzles become Measurement Location Ports on the Plant Item Segment identified in the assembly relationship.
- Topological connections become PortConnections within a PortMesh. For connections without a corresponding port, a port of a suitable type (e.g. directed fluid, electrical, mechanical) should be created and connected.
- X, Y coordinates and canvas dimensions are placed on a P&ID Data Sheet attached to the respective Plant Item Segment or Document Asset.
ISBM
The communication between all systems occurs via the ISBM using publish-subscribe services.
Due to the large volume of data output from these source systems, data may be sent to the Structural Register incrementally. The ISBM may also provide alternative transfer mechanisms for performance and scalability purposes.
Implementation Requirements
The Engineering Design System must implement a client for the ISBM Provider Publication and Channel Management (only the GetChannel operation) Services.
The Structural Registry must implement a client for the ISBM Consumer Publication and Channel Management (only the GetChannel operation) Services. The Structural Registry may implement the ISBM Notify Listener Service for message notification.
The Transform Engine must implement a client for the ISBM Provider Publication, Consumer Publication and Channel Management (only the GetChannel operation) Services. The Transform Engine may implement the ISBM Notify Listener Services for message notification.
Suggested Channel/Topic Configuration
A channel should be created for the handover of engineering data and should conform to the following format:
/Enterprise/Enterprise Subdivision/.../ISO18435:D0.2
For example:
/Enterprise/Refinery A/Area A/Light Ends Area/ISO18435:D0.2
As outlined in the document ISBM Guidelines, topics should match the message content. Correspondingly, the following topic format should be used:
OIIE:S1:V1.0/StandardXMLSchemaName{:Version}
For example:
OIIE:S1:V1.0/ISO15926:XMPLANT:V3.3.3 OIIE:S1:V1.0/ISO15926:PROTEUS:V3.3.3 OIIE:S1:V1.0/ISO15926:OWL OIIE:S1:V1.0/CCOM:SyncEngineeringDiagram:V1.0 OIIE:S1:V1.0/CCOM:SyncSegments:V1.0 OIIE:S1:V1.0/CCOM:SyncBreakdownStructures:V1.0
