This Checklist provides general guidance for use in tender and development cycles for implementing the MDIS Interface between a Distributed Control System (DCS) and a Subsea Production Control System (SPCS) for control of subsea equipment.
The following checklist is ordered by decisions and activities that should be defined during clarification and development of an MDIS interface specification interface.
Table 178 – Checklist – FEED Scope
No |
Item Description |
Comments |
√ |
|
The Operator, DCS vendor and SPCS vendor should assign dedicated persons to develop requirements for the interface. |
Knowledge of latest MDIS Specification is recommended. |
|
|
Operator to schedule Kick-off or Workshop with DCS vendor and SPCS vendor to discuss checklist items. |
For example
|
|
|
Agree on system architecture. The Operator shall decide which MDIS architecture (Integrated, Interfaced or Other) is applicable. The definition of architecture should document where all functional logic should reside, as per Section B.2. |
|
|
|
Create an overview drawing of the hardware and network architecture. Decide on Interface setting (IP ranges and class). Define hardware components on both systems that are related for the interface. |
|
|
|
Schedule Cyber Security Meeting for the MDIS Interface |
|
|
|
DCS vendor to provide OPC Foundation accredited Test Lab certification report (OPC UA Client), if available, to the Operator. |
|
|
|
SPCS vendor to provide OPC Foundation accredited Test Lab certification report (OPC UA Server), if available, to the Operator. |
|
|
|
Select responsible Party (DCS or SPCS) for implementing shutdown Sequences. |
|
|
|
Select responsible Party (DCS or SPCS) for implementing automated Sequences. |
|
|
|
Select responsible Party (DCS or SPCS) for implementing Product Interlocks. |
|
|
|
Select responsible Party (DCS or SPCS) for implementing Process Interlocks. |
|
|
|
Select responsible Party (DCS or SPCS) for creation and managing the Product Alarms/Warnings. Specify detail level of product alarms (summary alarm or specific information) |
SPCS Vendor should provide diagnostic information. |
|
|
Select responsible Party for changing Setpoints for Alarms & Interlocks (if applicable) |
|
|
|
SPCS Vendor to present specific Subsea Communication & Arbitration Philosophy |
|
|
|
Select responsible Party (DCS or SPCS) for creation and managing Process Alarms/Warnings. |
|
|
|
Define where information from redundant physical measurements is arbitrated. |
Example: Should the SPCS or DCS be responsible for arbitrating information from redundant pressure / temperature transmitters that are measuring the same process variable? |
|
|
Define where management of redundancy in subsea equipment is arbitrated. |
Example: Should the SPCS or DCS be responsible for assigning which SEM is used to command valve actuation? Should the SPCS or DCS be responsible for assigning a “primary” or “backup” SEM? |
|
|
Define where redundant information due to multiple communication channels is arbitrated. |
Example: Dependent on system design a single process sensor value might be available through various communication channels. Should the SPCS or DCS be responsible for determining which value is used for display to the operator and used as input to interlocks and automated sequences? |
|
|
Define the instance model for redundant systems |
Example: Is the instance model on each OPC Server identical or do the instance models represent separate and redundant pathways to subsea equipment? See section 12 for more details. |
|
|
Make a list of all MDIS Object types that will utilized on the project. |
Object types that are not utilized on the project can be skipped from following optional item selection. |
|
|
Operator, DCS and SPCS to select required optional References and Methods for all MDIS objects: - MDIS Discrete Instrument - MDIS DiscreteOut Instrument - MDIS Digital Instrument - MDIS DigitalOut Instrument - MDIS Instrument - MDIS InstrumentOut - MDIS Valve - MDIS Choke - Etc. |
It is recommended to start discussions assuming all objects use all mandatory and optional References and Methods and remove items that are not project relevant. |
|
|
Supported arguments for the MDIS Valve and MDIS Choke Move-Method calls should be documented. |
Available Move-Method calls are defined in the MDIS Valve and MDIS Choke objects. |
|
|
Faults and warning codes warning provided in SPCS system should be defined. Specific actions to be initiated by the DCS in the event of a fault or warning code should be documented. |
For example: A workshop for specific alarms & actions should be conducted after interface specification is finalized. |
|
|
Agree on standardised methodology for naming of Objects used on the interface (Hierarchy / Field structure) |
Project specific equipment specific tag identifiers can be used on the interface to name equipment. |
|
|
SPCS Vendor to prepare list of available MDIS Aggregated Objects and Vendor specific Subtypes of MDIS Objects. |
This list should provide sufficient detail to allow development of software by both the DCS and SPCS provider. |
|
|
The structure of address space across the interface (folder structure or MDIS Aggregated object) should be defined. |
Address space structure should be clearly documented by the SPCS vendor and be reviewed by the DCS vendor to ensure no incompatibility. |
|
|
A method for time Synchronization shall be defined. |
|
|
|
FEED work should be documented to clarify expectations during project execution. |
|
|
The following checklist documents activities that should be considered during project execution.
Table 179 – Checklist - Project Execution
No |
Item Description |
Comments |
√ |
|
SPCS Vendor should create a project specific MDIS Interface specification for DCS. |
This MDIS Interface specification should be based on documented FEED discussions. |
|
|
SPCS Vendor to schedule date for delivery of MDIS NodesetFile(s) for DCS Vendor. |
More than one date might be scheduled, where each date would provide a NodesetFile that includes additional object definitions. For example, an initial NodesetFile might contain just the first prototype of a well and subsequent NodesetFiles might contain a more detailed well and then multiple instances of the well. Also, some Objects might include additional optional items as the well model is finalized. |
|
|
Schedule date for first MDIS interface connection Test. SPCS vendor, DCS vendor and Operator should agree on test cases for first MDIS interconnection test. |
First interconnection test should cover test cases such as redundancy, time synchronization, performance, etc. |
|
|
Check possibility/availability of an online SPCS OPC UA MDIS Server to support and accelerate interface development. |
Operator to support/provide infrastructure (e.g. use own infrastructure or cloud systems) if link between SPCS and DCS Vendor cannot be established. |
|
|
DCS Vendor to prepare Interface Test procedure. Schedule review cycle for Operator and SPCS vendor. |
|
|
|
Schedule Date for final MDIS interface connection Test (full project configuration, including sequences and interlocks, etc.). |
|
|
The following Checklist documents activities that should be completed complete as part of a project closeout.
Table 180 – Checklist - Project Closeout
No |
Item Description |
Comments |
√ |
|
Feedback lessons learned and improvements from project execution to MDIS working group. |
Feedback should be provided from all parties (Operator, DCS, SPCS). Feedback could include discussion of specification features, feedback on this checklist, future features that could be added to specification etc. |
|