This document defines the OPC UA MDIS companion specification. This standard is an Oil and Gas standard for interfacing the Subsea Production Control System (SPCS), with a Master Control Station (MCS) or a Subsea Gateway, to the Distributed Control System (DCS). This specification includes:
- A description of common terms,
- Supported architectures,
- Information models representing the data that is shared between the systems,
- Methods used in the flow of information,
- Profile & ConformanceUnits describing the grouping of functionality,
- Recommended Practices for the use of MDIS.
MDIS was created to define a standard object model that is transported on a common high performance efficient interface between topside and subsea systems in Oil and Gas installations. The selected protocol (OPC UA) includes independent third-party certification.
This document makes use of a number of terms and concepts that are described in this section. OPC defined terms or terms defined in this document are in italics and camel case.
DCS (Distributed Control System) is the production facility control system provides a centralised control system for the facility for the operators and is used to monitor and control the subsea production system. The DCS system will normally host the OPC UA Client.
MCS (Master Control Station) is the central control node containing application software required to control and monitor the subsea production system.
Subsea Gateway provides a communications interface on the surface to the subsea control equipment over the subsea vendor’s communication system. The Subsea Gateway may form part of the overall MCS. The MCS or Subsea Gateway will normally host the OPC UA Server.
SCV (Subsea Controls Vendor) equipment refers to the subsea vendor supplied equipment and principally includes the subsea gateway in “Integrated” architecture or the subsea gateway and MCS in “Interfaced” architecture (see section 4 for additional details). It is intended to classify the functionality that is delivered by the subsea vendor whether it is implemented in the MCS or subsea gateway.
Note: The MCS may be supplied by a vendor other than the subsea or DCS vendor.
HPU (Hydraulic Power Unit) is the unit which provides low pressure and high pressure hydraulic supplies for the control of subsea wells.
EPU (Electrical Power Unit) is the unit which provides power to the subsea system.
The Customer is the end user, typically the “Operating Company”.
The Operator is the human being executing an operation, not to be confused with the “Operating Company”.
MDIS has standardised on the following definitions for Mandatory and Optional items. In all cases (Mandatory or Optional), if the item is available, the functionality described by the definition of the item must be correct and verifiable.
Mandatory
Objects specified as Mandatory will be required in all Objects and cannot be deleted. In OPC terms, a Mandatory item must exist on every Node of the NodeClass, for example if an MDISValveObjectType defines a Mandatory item Position then every instance of the MDISValveObjectType must have an item Position available.
Optional
Objects have functionality that may or may not be included; if they are included the OPC Client will know how to handle them. In OPC terms, an Optional item may or may not exist on every Node of the NodeClass, for example if an MDISValveObjectType defines an Optional item OpenTimeDuration then some instances of the MDISValveObjectType may contain an item OpenTimeDuration, but other instances may not. Clients are required to be able to handle the case where the item does not exist.
In regard to OPC Testing for Compliance and Certification the following concepts apply. The actual requirements for certification are defined on a project basis, but the standard third party certification provided by the OPC Foundation provides the following:
Compliance - Assurance that the OPC UA Server or Client fulfils all functionality that it claims to support in terms of Profiles and that of all exposed interfaces function as defined in the specifications.
Interoperability - Testing of products against other products, this includes all functionality, data types and access rights.
Robustness - The testing of failure cases including handling of lost communication, communication recovery. All problems must not affect other connections, quality information must be correctly reported, and audit entries are generated as needed. In short, end users are aware of any problem and problems are resolved automatically where possible.
Efficiency - The testing of products under load, forcing of noisy / bad communications and ensuring that products continue to work. Measuring CPU, RAM, threads, handles etc. and ensuring that even under the poor communications, heavily loaded Servers and Clients continue to function and not leak resources.
Usability - Verify that products are delivered with some level of documentation and that the documentation that is provided is accurate and understandable. Verify that the product functions as advertised and an end user would understand what is being provided.
Certification - Validation of Server or Client products. Certification includes compliance, interoperability, robustness, efficiency and usability testing and results in a seal of approval from an OPC Foundation test lab upon meeting or exceeding defined acceptance criteria.
Table 1 lists OPC UA definitions which are used in this document, they are included here as a reference. Additional information can be found in the reference documents listed in section 2.
Table 1 - OPC UA Terms and Definitions
|
Term |
Definition |
|
AddressSpace |
The collection of information that an OPC UA Server makes visible to its Clients. See Part 3 – Address Space Model for a description of the contents and structure of the Server AddressSpace. |
|
Attribute |
A primitive characteristic of a Node. All Attributes are defined by OPC UA, and may not be defined by Clients or Servers. Attributes are the only elements in the AddressSpace permitted to have data values. See Part 3 – Address Space Model for additional details. |
|
ConformanceUnit |
As defined by the OPC Foundation: a specific set of OPC UA features that can be tested as a single entity. As it applies to MDIS a ConformanceUnit may describe a specific Object or part of a specific Object. It may also describe general functionality such as redundancy or performance. For each ConformanceUnit one or more test cases will exist to ensure that the defined functionality is provided. The test cases may be automatically executed in a Compliance Test Tool (CTT) or they may require some level of manual interaction. See Part 7 – Profiles for additional details. |
|
Facet |
A Profile that describes a subset of functionality. This functionality must be paired with other Facets or Profiles to provide an operating Server or Client. See Part 7 – Profiles for additional details. |
|
InformationModel |
An organisational framework that defines, characterises and relates information resources of a given system or set of systems. The core address space model supports the representation of InformationModels in the AddressSpace. See Part 5 – Information Model for a description of the base OPC UA Information Model. |
|
Method |
A callable software function that is a component of an Object. See Part 4 – Services for a basic definition and see Part 10 – Programs for advanced uses. |
|
Node |
The fundamental component of an AddressSpace. See Part 3 – Address Space Model for additional details. |
|
NodeClass |
The class of a Node in an AddressSpace. NodeClasses define the metadata for the components of the OPC UA Object Model. They also define constructs, such as Views, that are used to organise the AddressSpace. See Part 3 – Address Space Model for additional details. |
|
Object |
Objects from an object-oriented technology point of view would have the following definition. Objects share two characteristics: They have state (Attribute) and behaviour (Method). A bicycle has states (current gear, current pedal cadence, current speed) and behaviour (changing gear, changing pedal cadence, applying brakes). An object stores its state in fields (Variables) and exposes its behaviour through functions (Methods). Functions operate on an object's internal state and serve as the primary mechanism for object-to-object communication. Hiding internal state and requiring all interaction to be performed through an object's functions is known as data encapsulation, a fundamental principle of object-oriented programming. In programming languages this object will have a third characteristic: The identity, which will help to find and use the object. From an OPC UA point of view the following definition is used: A Node that represents a physical or abstract element of a system. Objects are modelled using the OPC UA Object Model. Systems, subsystems and devices are examples of Objects. An Object is defined as an instance of an ObjectType. See Part 3 – Address Space Model for additional details. |
|
Object Instance |
A synonym for Object. See Part 3 – Address Space Model and Part 5 – Information Model for additional details. |
|
ObjectType |
A Node that represents the TypeDefinition for an Object. See Part 3 – Address Space Model and Part 5 – Information Model for additional details. |
|
Profile |
A specific set of capabilities, to which a Server or Client may claim conformance. The capabilities are defined by a set of ConformanceUnits. Each Server or Client may claim conformance to more than one Profile. The OPC Foundation provides a base list of Server and Client Profiles and Facets in an online database which is also documented in an OPC UA specification, Part 7 – Profiles. The online database can be found here: |
|
Property |
A Variable that is a leaf and cannot have any children. See Part 3 – Address Space Model and Part 5 – Information Model for additional details. |
|
Reference |
An explicit relationship (a named pointer) from one Node to another. The Node that contains the Reference is the source Node, and the referenced Node is the target Node. All References are defined by ReferenceTypes. See Part 3 – Address Space Model and Part 5 – Information Model for additional details. |
|
ReferenceType |
A Node that represents the TypeDefinition of a Reference. The ReferenceType specifies the semantics of a Reference. The name of a ReferenceType identifies how source Nodes are related to TargetNodes and generally reflects an operation between the two, such as “A contains B”. See Part 3 – Address Space Model and Part 5 – Information Model for additional details. |
|
UANodeSet |
The root of the AddressSpace defined in an XML document. It defines a set of Nodes, their Attributes and References. See Part 6 – Mappings for additional details. |
|
Variable |
Variable is a Node that contains a value and can have children. See Part 3 – Address Space Model and Part 5 – Information Model for additional details. |
|
VariableType |
A Node that represents the TypeDefinition for a Variable. See Part 3 – Address Space Model and Part 5 – Information Model for additional details. |
The abbreviations, acronyms and definitions listed in Table 2 are typical and primarily focused on Subsea projects although some Topsides specific terms are also included.
Table 2 - Abbreviations, Acronyms and Definitions
|
Abbreviations, Acronyms & Definitions |
|
|
API |
American Petroleum Institute |
|
CIMV |
Chemical Injection Metering Valves |
|
CSV |
Comma Separated Values |
|
DCS |
Distributed Control System |
|
EPU |
Electrical Power Unit (Part of PCU) |
|
ERP |
Enterprise Resource Planning |
|
EU |
Engineering Units |
|
FEED |
Front End Engineering Design |
|
HMI |
Human Machine Interface |
|
HTTP |
Hypertext Transfer Protocol |
|
IEC |
International Electrotechnical Commission |
|
JIP |
Joint Industry Project |
|
LVDT |
Linear Variable Displacement (Differential) Transmitter |
|
MCS |
Master Control Station (Subsea Process Control System) |
|
MDIS |
MCS-DCS Interface Standardisation (Industry JIP) |
|
MPFM |
Multiphase Flow Meters |
|
NTP |
Network Time Protocol |
|
OLE |
Object Linking & Embedding |
|
OPC |
Open Process Control (original Classic was OLE for Process Control) |
|
OPC UA |
OPC Unified Architecture |
|
ROV |
Remotely Operated Vehicle |
|
SCADA |
Supervisory Control And Data Acquisition |
|
SCV |
Subsea Controls Vendor |
|
SEM |
Subsea Electronics Module |
|
SIS |
Safety Instrumented System |
|
SPCS |
Subsea Production Control System |
|
TCP/IP |
Transmission Control Protocol / Internet Protocol |
|
UML |
Unified Modelling Language |
|
URL |
Uniform Resource Locator |
|
XML |
Extensible Mark-up Language |