This section details requirements to standardise redundancy across the MDIS interface. SPCS and DCS should be connected using two segregated communication channels. Designation of the primary communication channel between the SPCS and DCS shall be controlled at the DCS. Automatic reconnection / recovery in the event of a failed communication channel shall be implemented. Failure of either channel shall generate an alarm at the DCS. Communication configurations other than what is defined here may be used. However, it should be specified elsewhere and should be agreed between all parties prior to implementation. Additional redundancy options including physical and logical configuration should be based on required project availability.
In general, redundant communication between the SPCS and DCS shall:
- Facilitate active redundancy which enables a seamless transfer to a secondary controller in the event of a primary controller failure.
- Prevent or minimise the loss of subsea production due to a single-component failure or common-mode failure.
The information model available in MDIS OPC UA servers is affected by data arbitration choices (see 5.3.2).
OPC Redundancy is described in the following section.
OPC UA redundancy provides a standard manner for OPC UA Clients to determine which OPC UA Servers are redundant and the status of the Servers. In OPC UA redundant system all redundant servers provide:
- an identical information model,
- an identical instance address space.
The information model (list of Objects Variables…) between redundant Servers is always identical. In an MDIS system, the information (actual values) exposed in a redundant set of OPC UA servers may be identical in some cases. MDIS systems typically include arbitration which is described in Section 5.3.2. The arbitration process can result in Servers in which the Servers have an identical instance address space, but it can also result in Servers that do not have identical instance address space.
In all MDIS redundant Servers, the standard Redundancy Objects as described in Part 4 and Part 5 shall be supported. In addition, depending on if the data is identical on the servers the following apply:
On Servers where all data is identical: The server pair shall support either TRANSPARENT_4 redundancy or HOT_3 redundancy or HOT_AND_MIRRORED_5 redundancy including all associated objects and behaviours as described in Part 4 and Part 5.
- On Servers where not all data is identical: The Server redundancy type cannot be specified and redundancy support shall always identify as NONE_0.