The following section describes the two architectures that are defined by this specification. The Object models defined in other sections of this specification are affected by these architectures (see Figure 7.)

Figure 7 - Architecture Overview

This narrative and associated architecture drawing are intended to identify and represent this interface in the majority of typical system implementations. It is not intended to mandate the detailed architecture of a DCS vendor or SPCS vendor’s control system, nor is it intended to suggest or exclude a particular contracting / commercial strategy. This simplified version of the MDIS interface was used to facilitate development of the data objects and to define the data content between the DCS and SPCS vendor’s system.

Two major architectures, “Integrated” or “Interfaced”, are typically used throughout the industry and the choice will typically be decided by the Operating Company. Since the control aspects of the subsea system can be accomplished by both the DCS system or by the subsea system, the actual interface between the two systems may be different. In the Integrated architecture (Case 1), the controls system is an integrated system where all control is performed by the DCS vendor’s hardware and the standard needs to support communication of all information between the subsea gateway and the DCS control system. This enables a single HMI (or set of HMIs) to control and monitor platform and subsea operations. In the Interfaced architecture (Case 2), the SPCS vendor provides the controls for the subsea aspects of the system and the DCS system is used for monitoring and set point control purposes of the subsea system, along with topside controls. The MDIS InformationModel is able to adapt to both of these architectures.

The DCS is the primary user interface to the overall facility process including the subsea system. Process data management is handled by the DCS as well as all process alarming, alarm management and event / data archiving. Although an MCS may have an alarm or event queue, the primary facility alarm management occurs at the DCS level. Access to the various subsea control functions are managed by the DCS user access level rather than in the subsea system. The DCS also serves as the master for time synchronisation (for addition details see section 10).

Normal control and monitoring of the subsea production system is conducted at the DCS HMI. There may be a separate maintenance or configuration workstation used by the SCV, but it is not within the scope of the MDIS interface.

OPC UA supports Subscription and polling (Read) manners of obtaining data. The Subscription based manner of obtaining data should be used by default. Subscription, which is exception reporting, typically provides improved performance over the polling interface.

The functional elements of the system either reside in the DCS or SPCS depending on a particular vendor’s solution or customer’s requirements. The “Operating Company” should specify where each of these optional functions should reside. See Figure 8 for an illustration.

Data Arbitration is the system function that manages the reception and transmission of dual / redundant SPCS data.

If the Subsea system performs this function, only a single process value or operator command is typically passed between the SPCS and DCS system. If the DCS performs this function, both the A and B data values would typically be passed across the interface.

There are multiple types of data that could require arbitration. Instruments can be redundant, SEMs can be redundant and it is possible that the different types of data maybe arbitrated in different locations. I.e. in some projects, sensor data may be arbitrated by the DCS while the SEM may be arbitrated by the SPCS. Data Arbitration choices can also affect redundancy.

Certain subsea instruments may only be powered by one SEM at a time, selectable by the operator. Also, a SEM may have various modes, such as ROV mode or maintenance mode, which can be selected.

An Interlock is a control permissive that exists to prevent or warn an operator against potentially undesired operator commands being issued to the subsea system. Depending on an operator’s access level, he / she may be able to override the interlock in order to perform the desired operation. Interlocks can be categorised into two types: process interlocks and product / system interlocks, though not all customers or SCV’s make this distinction.

Process interlocks are interlocks which are specific to a particular project dependent on field layout, tree functionality, etc. These are often defined by the customer’s process requirements or by regulatory agencies; e.g., prevention of opening the tree crossover valve if the production master valve and annulus master valve are open

Interlocks defined by the SCV for the protection of the subsea system; for example, low hydraulic pressure inhibiting opening (pressurising) of a tree valve. These interlocks are typically not able to be overridden by an operator.

These are defined subsea valve operation sequences that take the subsea system to a safe state. They are initiated either by subsea process conditions, operator intervention or emergency conditions triggered from external interfaces such as the facility Safety Instrumented System (SIS).

These are multi-step control sequences triggered by the issuance of a single operator command, such as smart well (interval control valve) controls, hydrate prevention or preparation of a tree for start-up.

This refers to determination of the status of a subsea valve by evaluating some or all of the following: hydraulic output function line pressure, hydraulic flow and last command received.

This refers to the calculation of the assumed choke position based upon the number of step commands issued to the subsea choke. It may be maintained in percentage open or step position and is compared to the position transducer on the choke for calibration.

The HPU interface may include HPU control capability, data monitoring and configuration such as pump control setpoint changes.

The interface to the EPU may include monitoring of the power supply to the subsea equipment including input voltage / current, umbilical voltage(s) / current(s), line insulation monitoring data and power alarm statuses (over-voltage and over-current).

A valve profile, or signature, is a representation of the performance of a subsea valve in terms of its hydraulic fluid pressure and flow characteristics as measured at the subsea control module. Valve Profile / Signature Validation is a software function that compares a current valve profile/signature to a baseline or template signature recorded previously, typically at subsea system commissioning. Not all systems have this functionality.

The chemical injection interface may include control and monitoring capability. Typically, the interface includes verification to the subsea system of chemical delivery (flow rate and / or pressure) from the topsides chemical injection system.

These functions are assumed to be always implemented in the SPCS vendor’s equipment. In the case that the MCS is provided by a third-party supplier, the references below to the DCS may also pertain to the MCS.

The SCV’s system will manage data traffic to and from the subsea system and issue device control commands. The protocol is typically proprietary for a particular SCV and the medium and redundancy requirements are dependent upon customer requirements. The interface from the subsea gateway to the subsea system is not within the scope of the MDIS interface.

Ultimate operation or actuation of a subsea device is executed by the SCV’s system, whether requested locally, such as from an SCV engineering workstation, or remotely from the DCS.

The SCV’s system will provide current process data (e.g., pressures, temperatures, flow rates) and statuses (e.g., valve positions) to the DCS.

This includes settings for low-level subsea system functionality, such as solenoid pulse timers, pressure check settings for evaluating valve position or unintended movement, timer setpoints for determining valve failure, etc.

Valve Profiles are made available for transmission from the SCV system. The output format may vary among vendors and the data may be transmitted according to customer requirements.

The SCV system typically calculates process engineering values if raw data is received from subsea devices, though there may be exceptions where raw data transmission is required.

This refers to any available data in the subsea system not included within the definition of other objects that may be transmitted via a “generic” discrete or analogue object. This includes data that may have been considered “alarms” in legacy subsea systems, but are simply data points that are available to the DCS to manage as alarms, events or to be logged as desired. The SCV may also implement “roll-up” statuses that condense numerous statuses into fewer bits / words in order to optimise data transfer.

Diagnostic information in regard to the health of the subsea system is managed in the SCV’s system. This data would typically not be transmitted to the DCS except for summary product status data as defined above. It would be transmitted via a “generic” discrete or analogue object as desired.

The interface to the EPU may include monitoring of the power supply to the subsea equipment including input voltage / current, umbilical voltage(s) / current(s), line insulation monitoring data and power alarm statuses (over-voltage and over-current).

The SCV defines the subsea communications system architecture. Communications link control and monitoring is also performed by the SCV. Variable scan configurations (e.g. fast scan, normal scan, slow scan) may be implemented and configured by the SCV as required.