This Recommended Practice provides guidance for use in specifying and implementing the OPC Unified Architecture (UA) for use as a standard communication interface for use between a Distributed Control System (DCS) and a Subsea Production Control System (SPCS) for control of subsea equipment.

Guidance for specifying minimum requirements when implementing MDIS are provided to ensure:

• Equipment compatibility when integrating the MCS or Subsea Gateway with the DCS.
• Safe and effective operation of equipment controlled by the MCS or Subsea Gateway from the DCS. Successful integration of the DCS with the MCS or Subsea Gateway during project execution.

These checklists and associated text maybe used directly in an RFQ, or maybe adjusted as needed.

Physical architecture, defined in Section 5.1, should be specified. The location of the following minimum set of functionality, in the DCS or SPCS, is dependent on physical and “Operating Company” requirements and should be clearly specified prior to project execution:

• Data Arbitration
• Communication Channel Selection
• SEM Control Selection
• Process Interlocks
• Product Interlocks
• Shutdown Sequences
• Automated Control Sequences
• Valve Status Validation
• Choke Position Validation
• Interfacing with the HPU
• Interfacing with the topside chemical injection system
• Validation of Valve Profiles / Signatures

While functional logic has been prescribed by MDIS; implementation of specific functionality is not mandatory and should be specified on a project basis. As a minimum any MDIS implementation should ensure exchange of all required information required to safely line up, start up, operate and shutdown subsea equipment.

Interfaces with external interfaces with other third-party systems (i.e. historians) and external interfaces between SPCS and DCS for use other than for control and monitoring of subsea equipment are not specified through the use of the MDIS OPC UA Companion Specification and should be specified on a project basis.

It is recommended that all encryption or application-level security requirements that are specified should be based on a network security assessment. If encryption on the protocol level is required, it is recommended to use encryption algorithms specified by OPC UA. Any advanced security features, if implemented, should have the option to be disabled and not adversely affect system performance.

No provision for user level security is considered for the MDIS Interface. The MDIS Interface is controller to controller communication and is not user restricted. All user level security should be implemented in the SPCS and DCS.

To maximise efficient use of bandwidth and performance, communication should be subscription based, by default.

The OPC UA interface is exception driven and a publishing interval of 2 seconds or less should be used between the SPCS and the DCS. Update rates from subsea to the SPCS is outside the scope of MDIS and can be much longer than 2 seconds. Maximum allowable update rates for individual controllers should be determined and based on system architecture and hardware capabilities.

It is expected that update rates will vary according to general categories of data. Critical data will have update rates that could be under 1 second while housekeeping data might have update rates in the 1-minute time range. These data rates shall be constant for the supported counts of Objects. i.e. if a device supports 3 wells (say 3000 critical values and 10,000 housekeeping values), the 1 second and 1 minute data rates will be support, not just for 1 well, but for the advertised 3 wells.

Conformance units provided general ranges of performance numbers that a product can be tested against. It is understood that performance will vary according to the hardware provided and the other loading on the hardware. The ConformanceUnits do not guarantee any performance, but they will point out performance issues earlier. i.e. a device that can support 5000 objects as part of a test is may not support 5000 when it is fully loaded with non-MDIS functionality, but it is likely that it would still be able to support 3000 objects. These conformance units are included to provide some general bench marks for performance.

Systems can be architected to include multiple server/devices to offset load. These number are targeted to allow better choice of configuration. For example, if 10,000 objects are desired and the software can only pass 5000 objects, the system should be architected to have at least 2 devices, but to allow for other factor, it might be a good idea to target 3 devices.

Requirements should be developed on a project basis to provide sufficient bandwidth between the SPCS and DCS to ensure all commands, issued both during normal operation and shutdowns, are passed across the interface effectively.

Evaluation of communication performance and testing requirements should take into account any latency or communication limitations due to physical system architecture constraints between SPCS and the DCS. (i.e. radio communication).

Data prioritisation should be considered on a system level by each project and should take into consideration functional requirements for safe and effective operation of control of subsea equipment.

Data exchange across the interface should, unless otherwise specified be prioritised in the following manner:

• High Priority:Information required for process control.
• Low Priority:Information that is not required for process control (i.e. diagnostics, housekeeping).

An interface specification should be developed between the SPCS vendor, DCS vendor and the “Operating Company” prior to the implementation of MDIS. The interface specification should provide the required fidelity to ensure all project specific requirements have been met. During the development of this specification it is recommended to review the project check list in Section B.8.

The SPCS vendor shall maintain revision control of the UANodeSet file that is being utilised by the project.

External interfaces (i.e. historians, condition monitoring systems, etc.) should also be specified however are outside the scope of this specification.

The MDIS communication link shall be verified between the SPCS and DCS. Testing shall include both normal operation and failure scenarios. Redundancy and performance requirements should be tested under full load (i.e. shutdown conditions). Time synchronisation should be verified.

Clients and Servers that have passed independent MDIS certification should require less integration testing. Integration testing should be focused on the project configuration rather than base MDIS functionality. It is recommended prior to any integration testing that the interface specification, defined in Section C.6 and OPC UA UANodeSet files be finalised and agreed between SPCS and DCS vendors as early as possible. Integration testing should only be attempted when the SPCS and DCS software has reached an acceptable level of maturity.

It is recommended that, during project execution, preliminary integration testing be performed to validate the data exchange across the MDIS Interface off critical path, prior to full onsite integration testing. In addition to validating data exchange, this testing should allow for verification of graphical displays, redundancy and data prioritisation. Validation of performance and full functionality, including shutdowns, sequences and interlocks, should be performed during full onsite integration testing using the hardware that will be supplied to the project.

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 System Introduction. Agree on weekly / biweekly regular meetings Lessons learned of previous implementations 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.
	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.