The following checklist is ordered by decisions and activities that should be defined during clarification and development of an MDIS interface specification interface.
Table 97 – 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. |
|
|
|
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. |
|
|
|
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 (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 redundant channel identical or do the instance models represent separate and redundant pathways to subsea equipment? See section 11 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. |
|
|
|
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. |
|
|