1 Scope

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.

2 Concepts / Definitions

2.1 Introduction

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.

2.2 API Standard 17F concepts

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 5.1 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.

Interlocks (Permissive Logic) is permissive logic that needs to be satisfied before the action can initiate

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”.

2.3 MDIS Mandatory & Optional Items / Objects

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.

2.4 OPC Compliance & Certification

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.

3 Normative references

The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments and errata) applies.

4 Terms, abbreviated terms and conventions

It is assumed that basic concepts of OPC UA information modelling are understood in this document. This document will use these concepts to describe the MDIS Information Model.

4.1 MDIS definitions

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 3.

4.2 Abbreviated terms

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.

The OPC UA Specifications are also available from the IEC as IEC 62541

4.3 OPC UA Overview

4.3.1 Introduction

For the MDIS user who may not be familiar with OPC UA, the following section provides a brief overview of key features. It does not describe how MDIS makes use of these features it only describes the features available in OPC UA. MDIS specific functionality is specified in other sections of this document.

4.3.2 What is OPC UA?

OPC UA is an open and royalty free standard designed as a universal communications protocol. It is also available as IEC 62541.

OPC UA has a broad scope which delivers economies of scale for application developers. When combined with powerful semantic models, OPC UA makes it easier for end users to access data via generic commercial application. It provides an information modelling framework that allows application developers to represent their data in a way that makes sense to them.

The OPC UA model is scalable from small devices to Enterprise Resource Planning (ERP) systems. OPC UA devices process information locally and then provides that data in a consistent format to any application requesting data. For a more complete overview see OPC 10000-1.

4.3.3 Basics of OPC UA

As an Open Standard, OPC UA is based on standard Internet technologies, such as TCP/IP, HTTP, Ethernet and XML. OPC UA provides a set of services (see OPC 10000-4) and a basic information model framework.

As an Extensible Standard, OPC UA provides an information model framework which can expose vendor defined information in a standard way. More importantly all OPC UA Clients are expected to be able to discover and use vendor defined information. This means OPC UA users can benefit from the economies of scale that come with generic visualisation and interface applications. This specification is an example of an OPC UA InformationModel designed to meet the needs of developers and users in the offshore oil and gas industry.

OPC UA Clients can be any consumer of data, from devices / controllers on the network; browser based thin clients and higher level ERP systems. OPC UA applications are platform and development language dependant. The full scope of OPC UA applications are illustrated in Figure 1. For this companion specification the typical communication would be device to device or device to SCADA type communications.

OPC UA provides a robust and reliable communication infrastructure having mechanisms for handling lost messages, recovering from network interruptions, etc. With its binary encoded data it offers a high-performance data exchange solution. Security is built into OPC UA, security requirements are becoming more and more important as, increasingly, environments are connected to the office network or the internet and attackers are starting to focus on automation systems

4.3.4 Information Modelling in OPC UA

4.3.4.1 Concepts

OPC UA provides a framework that can be used to represent complex information as Objects in an AddressSpace which can be accessed with standard web services. These consist of Nodes connected by References. Different classes of Nodes convey different semantics. For example, a Variable Node represents a value that can be read or written. The Variable Node has an associated DataType that can define the actual value, such as a string, float, structure etc. It can also describe the Variable value as a variant. A Method Node represents a function that can be called. Every Node has a number of Attributes including a unique identifier called a NodeId and non-localised name called a BrowseName. An Object representing a Heater is shown in Figure 2.

Object and Variable Nodes are called Instance Nodes and they always reference a TypeDefinition (ObjectType or VariableType) Node which describes their semantics and structure. Figure 3 illustrates the relationship between an instance and its TypeDefinition.

Type Nodes are templates that define all of the children that can be present in an instance of the type. In the example in Figure 3 the BoilerType ObjectType defines two sensors: Pressure and Temperature. All instances of BoilerType are expected to have the same children with the same BrowseNames. Within a type the BrowseNames uniquely identify the child. This means Client applications can be designed to search for children based on the BrowseNames from the type instead of NodeIds. This eliminates the need for manual reconfiguration of systems if a Client uses types that multiple devices implement.

OPC UA also supports the concept of subtyping. This allows a modeller to take an existing type and extend it. There are rules regarding subtyping defined in OPC 10000-3, but in general they allow the extension of a given type or the restriction of a DataType. For example, the modeller may decide that the existing ObjectType in some cases needs an additional Variable. The modeller can create a subtype of the Object and add the Variable. A Client that is expecting the parent type can treat the new type as if it was of the parent type. With regard to DataTypes, if a Variable is defined to have a numeric value, a subtype could restrict the value to a float. This standard adds additional rules for extensions.

References allow Nodes to be connected together in ways that describe their relationships. All References have a ReferenceType that specifies the semantics of the relationship. References can be hierarchical or non-hierarchical. Hierarchical References are used to create the structure of Objects and Variables. Non-hierarchical References are used to create arbitrary associations. Applications can define their own ReferenceType by creating subtypes of the existing ReferenceType. Subtypes inherit the semantics of the parent but may add additional restrictions. Figure 4 depicts several References connecting different Objects.

The figures above use a notation that was developed for the OPC UA specification. The notation is summarised in Figure 5. UML representations can also be used; however, the OPC UA notation is less ambiguous because there is a direct mapping from the elements in the figures to Nodes in the AddressSpace of an OPC UA Server.

A complete description of the different types of Nodes and References can be found in OPC 10000-3 and the base OPC UA AddressSpace is described in OPC 10000-5.

The OPC UA specification defines a very wide range of functionality in its basic information model. It is not expected that all Clients or Servers support all functionality in the OPC UA specifications. OPC UA includes the concept of Profiles, which segment the functionality into testable certifiable units. This allows the development of companion specifications (such as OPC UA MDIS) that can describe the subset of functionality that is expected to be implemented. The Profiles do not restrict functionality but generate requirements for a minimum set of functionality (see OPC 10000-7).

The OPC Foundation also defines a set of InformationModels that provide a basic set of functionalities. The Data Access specification (see OPC 10000-8) provides a basic InformationModel for typical process or measured data. The Alarm and Condition specification (see OPC 10000-9) defines a standard InformationModel for Alarms and Conditions. The Programs specification (see OPC 10000-10) defines a standard InformationModel for extending the functionality available via Method calls and state machines. The Historical Access specification (see OPC 10000-11) defines the InformationModel associated with Historical Data and Historical Events. The aggregates specification (see OPC 10000-13) defines a series of standard aggregate functions that allow a Client to request summary data. Examples of aggregates include averages, minimums, time in state, standard deviation, etc.

4.3.4.2 Namespaces

OPC UA allows information from many different sources to be combined into a single coherent AddressSpace. Namespaces are used to make this possible by eliminating naming and id conflicts between information from different sources. Namespaces in OPC UA have a globally unique string called a NamespaceUri and a locally unique integer called a NamespaceIndex. The NamespaceIndex is only unique within the context of a Session between an OPC UA Client and an OPC UA Server. All of the web services defined for OPC UA use the NamespaceIndex to specify the Namespace for qualified values.

There are two types of values in OPC UA that are qualified with Namespaces: NodeIds and QualifiedNames. NodeIds are globally unique identifiers for Nodes. This means the same Node with the same NodeId can appear in many Servers. This, in turn, means Clients can have built in knowledge of some Nodes. OPC UA InformationModels generally define globally unique NodeIds for the TypeDefinitions defined by the InformationModel.

QualifiedNames are non-localised names qualified with a Namespace. They are used for the BrowseNames of Nodes and allow the same names to be used by different InformationModels without conflict. The BrowseName is used to identify the children within a TypeDefinition. Instances of a TypeDefinition are expected to have children with the same BrowseNames. TypeDefinitions are not allowed to have children with duplicate BrowseNames; however, instances do not have that restriction.

4.3.4.3 Companion Specifications

An OPC UA companion specification for an industry specific vertical market describes an InformationModel by defining ObjectTypes, VariableTypes, DataTypes and ReferenceTypes that represent the concepts used in the vertical market. Table 3 contains an example of an ObjectType definition.

The BrowseName is a non-localised name for an ObjectType.

IsAbstract is a flag indicating whether instances of the ObjectType can be created. If IsAbstract is FALSE then instances of this ObjectType may be created. If IsAbstract is TRUE then instances of the ObjectType cannot be created, the ObjectType must be subtyped.

The bottom of the table lists the child Nodes for the type. The Reference column is the type of Reference between the Object instance and the child Node. The NodeClass is the class of Node. The BrowseName is the non-localised name for the child. The DataType is the structure of the Value accessible via the Node (only used for Variable NodeClass Nodes) and the TypeDefinition is the ObjectType or VariableType for the child.

The ModellingRule indicates whether a child is Mandatory or Optional. It can also indicate cardinality. Note that the BrowseName is not defined if the cardinality is greater than 1. Error! Reference source not found. visually depicts the ObjectType defined in Table 3 along with two instances of the ObjectType. The first instance includes the Optional Property while the second does not.

5 Architectures

5.1 Overview

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.)

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.

5.2 DCS Implemented Functions

5.2.1 Main Process Responsibility

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 11).

5.2.2 Control and Monitoring of Subsea Equipment

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.

5.2.3 Subscriptions

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.

5.3 DCS or SCV Implemented Functions

5.3.1 Introduction

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.

5.3.2 Data Arbitration

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.

5.3.3 SEM Control Selection

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.

5.3.4 Interlocks

5.3.4.1 Introduction

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.

5.3.4.2 Process Interlocks

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.

5.3.4.3 Product or System Interlocks

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.

5.3.5 Shutdown Sequences

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).

5.3.6 Automated Control Sequences

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.

5.3.7 Determining Valve Statuses

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.

5.3.8 Determining / Updating Choke Calculated Position

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.

5.3.9 HPU Interface

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

5.3.10 EPU Interface

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).

5.3.11 Valve Profile / Signature Validation

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.

5.3.12 Topsides Chemical Injection System Interface

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.

5.4 Subsea Controls Vendor-Implemented Functions

5.4.1 Introduction

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.

5.4.2 Managing Subsea Communications

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.

5.4.3 Operation of Subsea Devices

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.

5.4.4 Handing off Process Sensor Data to 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.

5.4.5 Configuration of Operational Parameters

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.

5.4.6 Handing off Valve Profiles / Signatures

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, but MDIS provides a recommended format (see Annex E).

5.4.7 Calculation of Engineering Values

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.

5.4.8 Handing off Product Statuses

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.

5.4.9 Handing Off Diagnostic Information

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.

5.4.10 EPU Interface

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).

5.4.11 Subsea Control Paths / Network Routing

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.

6 MDIS ObjectTypes

6.1 Overview

The following sections define the basic OPC UA Objects defined by MDIS. This includes Method definition as needed. The use cases / object interactions for each Object are defined in a separate section.

6.1.1 MDISBaseObjectType

The MDISBaseObjectType (see 6.2) is a base object that all other MDIS objects are constructed from. It is an abstract ObjectType and instances of it shall not exist. This Object will be used to create subtypes.

6.1.2 MDISDiscreteInstrumentObjectType

The MDISDiscreteInstrumentObjectType (see 6.3) is a base type and can be subtyped or instances of it can be directly created. The Object can be used with multi-state type of data (stopped, moving, faulted). It could also be used for instruments that report integer values. For a limit switch or on / off switch the MDISDigitalInstrumentObjectType should be used.

6.1.3 MDISDiscreteOutObjectType

The MDISDiscreteOutObjectType (see 6.3.4) is a subtype of MDISDiscreteInstrumentObjectType and can be subtyped or instance of it can be directly created. The Object can be used for Tristate or Multistate switches.

6.1.4 MDISDiscreteArbitrationObjectType

The MDISDiscreteArbitrationObjectType (see 6.3.6) is a subtype of MDISDiscreteInstrumentObjectType and can be subtyped or instance of it can be directly created. It adds inputs that can be selected according to the arbitration mode.

6.1.5 MDISDigitalInstrumentObjectType

The MDISDigitalInstrumentObjectType (see 6.4) is a base type and can be subtyped or instance of it can be directly created. The Object can be used to represent on / off type of functions.

6.1.6 MDISDigitalOutObjectType

The MDISDigitalOutObjectType (see 6.4.4) is a subtype of MDISDigitalInstrumentObjectType and can be subtyped or instance of it can be directly created. The Object can be used for switching on / off types.

6.1.7 MDISDigitalArbitrationObjectType

The MDISDigitalArbitrationObjectType (see 6.4.6) is a subtype of MDISDigitalInstrumentObjectType and can be subtyped or instance of it can be directly created. It adds inputs that can be selected according to the arbitration mode.

6.1.8 MDISInstrumentObjectType

The MDISInstrumentObjectType (see 6.5.3) is a base type and can be subtyped or instances of it can be directly created. The Object can be used for various types of analogues, e.g. pressure, temperatures, tank levels etc.

6.1.9 MDISInstrumentOutObjectType

The MDISInstrumentOutObjectType (see 6.5.4) is a subtype of MDISInstrumentObjectType and can be subtyped or instance of it can be directly created. The Object can be used for writing floating point values.

6.1.10 MDISInstrumentArbitrationObjectType

The MDISInstrumentArbitrationObjectType (see 6.5.6) is a subtype of MDISInstrumentObjectType and can be subtyped or instance of it can be directly created. It adds inputs that can be selected according to the arbitration mode.

6.1.11 MDISChokeObjectType

The MDISChokeObjectType (see 6.6.3) is a base type and can be subtyped or an instance of it can be directly created. A choke is a device that restricts the flow of a fluid (gases, liquids, fluidised solids, or slurries).

6.1.12 MDISElectricChokeObjectType

The MDISElectricChokeObjectType (see 6.7.3) is a base type and can be subtyped or an instance of it can be directly created. An electric choke is a device that restricts the flow of a fluid (gases, liquids, fluidised solids, or slurries) and can be positioned more precisely than a standard Choke.

6.1.13 MDISValveObjectType

The MDISValveObjectType (see 6.8.3) is a base type and can be subtyped or an instance of it can be directly created. A valve is a device that directs or controls the flow of a fluid (gases, liquids, fluidised solids, or slurries). The MDISValveObjectType represents a two-state valve type.

6.1.14 MDISCIMVObjectType

The MDISCIMVObjectType (see 6.9.3) is a base type and can be subtyped or an instance of it can be directly created. The CIMV (Chemical Injection Metering Valve) is used to regulate the flow of chemicals to a well. It can report optional housekeeping data.

6.1.15 MDISMotorObjectType

The MDISMotorObjectType (see 6.11.3) is a base type and can be subtyped or an instance of it can be directly created. A motor is a device that is used to power pump

6.1.16 MDISAggregateObjectType

The MDISAggregateObjectType (see 6.12.2) is an abstract type that all aggregate ObjectTypes shall be derived from. This ObjectType allows Clients to easily identify aggregate Objects. For more information about aggregation see 10.5

6.1.17 MDISCounterObjectType

The MDISCounterObjectType (see 6.10.3) is a base type, it is not envisioned that this object will be subtyped, but rather that this object is used as part of other aggregate objects. It provides the capability of resetting counters to some initial value.

6.1.18 MDISTimeSyncObjectType

The MDISTimeSyncObjectType (see 6.13.3) is a base ObjectType. An instance of this ObjectType shall be exposed as part of the MDISInformationObjectType, if the MDISTimeSyncObjectType is supported.

6.1.19 MDISInformationObjectType

The MDISInformationObjectType (see 6.14) is a base ObjectType. An instance of this ObjectType shall be exposed under the Objects folder. It provides information about the MDIS Information model that is supported by the Server. It can also expose additional information related to MDIS.

6.2 MDISBaseObjectType

6.2.1 Overview

The following section details the MDIS generic properties for the MDISBaseObjectType. Implementations shall ensure adherence to Mandatory [M] aspects in order to comply with the MDIS interface standardisation. Optional [O] may or may not be implemented within a project. Figure 9 provides an overview of the MDISBaseObjectType as defined by MDIS. This Object is intended to be the base object for all other MDIS ObjectTypes (see Figure 10 for an overview of inherited types)

6.2.2 MDISBaseObjectType Definition

The Table 4 defines the structure of an MDISBaseObjectType.

The RW column indicates if a Node of Variable NodeClass is readable, writeable or both readable and writeable. Other NodeClasses (Object, Method) do not support reading or writing and do not fill in this column.

By definition a Profile can require that an Optional item be provided, it cannot change the behaviour of an Object from what is described in this specification, which includes support for any Mandatory items. Profiles are described in section 14.3.

Fault – The status of the object, true if any fault exists.

Warning – The status of the object, true if any warnings exist. A warning does not require immediate operator action.

Enabled – This Variable is set as enabled (true) by default. When disabled the Object will not report any dynamic information other than a bad status code (Bad_InvalidState). It will still report configuration related information. It will disable execution of any method that might be defined as part of the Object. For the MDISBaseObjectType the default is that only the Enabled flag, TagId and EnableDisable Method report values or perform functions. Subtypes of this ObjectType may describe additional requirements for disabled Objects.

TagId – The TagId is a unique equipment identifier. This is additional information that can be used to help identify the Variable associated with the instance of this type. This field is intended to be used to store the tag id from the P&ID.

EnableDisable – This Method allows a Client to disable or enable the Object.

FaultCode – An unsigned integer that describes a fault code(s), zero indicates no fault. The FaultCode is a 32 bit mask, with 16 bits for standard defined codes and 16 bits for vendor defined codes. Each of the Subtypes of this ObjectType defined in this specification shall define a set standard FaultCodes that apply to that ObjectType (bits 0-15). In addition, the SPCS vendor may provide vendor specific bits (bits 16-31). Once a Bit is defined (given a name), then in all Objects that use that same named fault, the same bit number is used.

WarningCode – An unsigned integer that describes a warning code(s), zero indicates no warning. The SPCS vendor will provide a definition of what the number means The WarningCode is a 32 bit mask, with 16 bits for standard defined codes and 16 bits for vendor defined codes. Each of the subtypes of this ObjectType defined in this specification shall define a set standard WarningCodes that apply to that ObjectType (bits 0-15). In addition, the SPCS vendor may provide vendor specific bits (bits 16-31). Once a Bit is defined (given a name), then in all Objects that use that same named warning, the same bit number is used.

6.2.3 EnableDisable Method

EnableDisable is used to disable or enable an Object. The enable / disable operation applies to the Object in the UA Server. The call completes when the enable / disable operation is complete. The Server may or may not pass the enable / disable down to lower levels. This is Server specific behaviour.

Signature

	EnableDisable (
		[in] 0:Boolean Enable );
	

Method result codes are defined as part of the Call Service (see OPC 10000-4). They are described in Table 124 for ease of reference.

Comments

The EnableDisable Method will disable or enable this Object. Once the state of an Object is changed by this Method (i.e., disabled) the state will be maintained until this Method is called again to change the state (i.e., enable). The Method will report if any error occurs while disabling or enabling the Object. Table 6 specifies the AddressSpace representation for the EnableDisable Method.

6.3 MDISDiscreteInstrumentObjectType

6.3.1 Introduction

The following section details the generic MDISDiscreteInstrumentObjectType structure and defines the properties associated with it. Additional sections define a subtype MDISDiscreteOutObjectType that allows updates to the discrete value. This is in general a vendor and operator independent description, but all users of the MDISDiscreteInstrumentObjectType or MDISDiscreteOutObjectType can add vendor specific data. The vendor specific data should be defined as part of a subtype of the MDISDiscreteInstrumentObjectType or MDISDiscreteOutObjectType defined in this document. It is assumed that the subsea system is the Server and host of the instance of the MDISDiscreteInstrumentObjectType or MDISDiscreteOutObjectType. The DCS based system is the Client in the system. It is assumed that all interactions with the instance of the MDISDiscreteInstrumentObjectType are initiated by the Client and are directed to the Server.

6.3.2 Overview

The following section details the MDIS generic properties for the MDISDiscreteInstrumentObjectType. Implementation shall ensure adherence to Mandatory [M] aspects in order to comply with the MDIS interface standardisation. Optional [O] may or may not be implemented within a project. Figure 11 provides an overview of the MDISDiscreteInstrumentObjectType as defined by MDIS, including some nested types. This figure includes all items that are inherited from the MDISBaseObjectType.

6.3.3 MDISDiscreteInstrumentObjectType Definition

Table 7 defines the structure of an MDISDiscreteInstrumentObjectType. Any vendor specified properties that have been implemented within a project should be documented within a similar format and supplied to the DCS vendor. The addition of vendor specific properties will result in a subtype of the MDISDiscreteInstrumentObjectType.

State – The state of the instance of MDISDiscreteInstrumentObjectType. This state is represented as a UInt32.

The MDISDiscreteInstrumentObjectType is a subtype of MDISBaseObjectType and inherits the FaultCode Variable. The MDISDiscreteInstrumentObjectType defines the standard FaultCodes (for bits 0-15 as defined in 6.2.2) in Table 8. All subtypes of this the MDISDiscreteInstrumentObjectType will inherit all FaultCodes defined in this table. Subtypes may define additional FaultCodes in their own table.

The MDISDiscreteInstrumentObjectType defines the standard WarningCodes (for bits 0-15 as defined in 6.2.2) in Table 9. All subtypes of this the MDISDiscreteInstrumentObjectType will inherits all WarningCodes defined in this table. Subtypes may define additional WarningCodes in their own table.

6.3.4 MDISDiscreteOutObjectType Definition

Table 10 defines the structure of an MDISDiscreteOutObjectType. Any vendor specified properties that have been implemented within a project should be documented within a similar format and supplied to the DCS vendor. The addition of vendor specific properties will result in a subtype of the MDISDiscreteOutObjectType.

WriteValue – This Method allows a Client to change the value of State on an instance of MDISDiscreteOutObjectType. The Method will return any errors that occurred on setting the value. The Client shall verify that the State actually changed to confirm the update. If the instrument is disabled, an error Bad_InvalidState shall be returned.

6.3.5 WriteValue Method

WriteValue Method (defined in Table 11) is used to change the value of the State Variable in an instance of MDISDiscreteOutObjectType. The WriteValue operation applies to the object in the subsea system. The value of the State Variable shall only be updated once the subsea system has provided a new value. For Objects that are used as a command, the value of the State Variable shall be updated directly to the value provided by the State parameter of the Method. Some systems will be able to report any errors immediately others will only be able to report that the operation was not refused. Clients are expected to monitor the State and ensure that the operation completed. If an error occurs after the Method has returned, a Fault flag shall be set and an appropriate FaultCode will be returned. The Fault (and FaultCode) will reset on the next successful WriteValue Method invocation.

Signature:

	WriteValue (
		[in] 0:UInt32 State);
	

Method result codes are defined as part of the Call Service (see OPC 10000-4). They are described in Table 124 for ease of reference.

Comments

The WriteValue Method will result in a change the value of the State Variable. The Method will report if any error occurs while writing the state of the Object. Table 12 specifies the AddressSpace representation for the WriteValue Method.

6.3.6 MDISDiscreteArbitrationObjectType Definition

Table 13 defines the structure of an MDISDiscreteArbitrationObjectType. Any vendor specified properties that have been implemented within a project should be documented within a similar format and supplied to the DCS vendor. The addition of vendor specific properties will result in a subtype of the MDISDiscreteArbitrationObjectType.

The MDISDiscreteArbitrationObjectType will select which instrument is healthy and report it. The arbitration object selects between the two sources, SourceA and SourceB base on the source and the selected ArbitrationMode. The result of the arbitration is shown in the State. The result can be either a selection of one source as default or forcing of one source (see 8.1.10 for additional details).

SourceA – a Variable that represents the value of the first source of a MDISDiscreteArbitrationObjectType.

SourceB – a Variable that represents the value of the second source of a MDISDiscreteArbitrationObjectType

ArbitrationMode – This enumeration provides information about the ArbitrationMode that is currently used (see section 8.1.10). The Average enumeration value does not apply to this arbitration ObjectType.

The MDISDiscreteArbitrationObjectType is a subtype of MDISDiscreteInstrumentObjectType and inherit the FaultCode Variable. The MDISDiscreteArbitrationObjectType defines the standard FaultCodes (for bits 0-15 as defined in 6.2.2) in Table 14 (currently empty, no additional fault codes defined). All subtypes of this the MDISDiscreteArbitrationObjectType will inherit all FaultCodes defined in this table. Subtypes may define additional FaultCodes in their own table.

The MDISDiscreteArbitrationObjectType defines the standard WarningCodes (for bits 0-15 as defined in 6.2.2) in Table 15 (currently empty, no additional warning codes defined). All subtypes of this the MDISDiscreteArbitrationObjectType will inherit all WarningCodes defined in this table. Subtypes may define additional WarningCodes in their own table.

6.3.7 SetArbitrationMode Method

SetArbitrationMode Method is used to change the arbitration strategy of the arbitration Object. If the mode cannot be changed the method shall return an error. This description applies to the following arbitration objects (MDISDigitalArbitrationObjectType, MDISDiscreteArbitrationObjectType, MDISInstrumentArbitrationObjectType).

Signature:

	SetArbitrationMode (
		[in] ArbitrationModeEnum ArbitrationMode);
	

Method result codes are defined as part of the Call Service (see OPC 10000-4). They are described in Table 124 for ease of reference. The following specific Method result codes are defined in Table 17.

Comments

The SetArbitrationMode Method will change the arbitration strategy. The Method will report if any error which occur while writing the value of the Object. Table 18 specifies the AddressSpace representation for the SetArbitrationMode Method.

6.4 MDISDigitalInstrumentObjectType

6.4.1 Introduction

The following section describes the generic MDISDigitalInstrumentObjectType structure and defines the properties associated with it. Additional sections define a subtype MDISDigitalOutObjectType that allows updates to the digital value. This is in general a vendor and operator independent description, but all users of the MDISDigitalInstrumentObjectType or MDISDigitalOutObjectType can add vendor specific data. The vendor specific data should be defined as part of a subtype of the MDISDigitalInstrumentObjectType or MDISDigitalOutObjectType defined in this document. It is assumed that the subsea system is the Server and host of the instance of MDISDigitalInstrumentObjectType or MDISDigitalOutObjectType. The DCS based system is the Client in the system. It is assumed that all interactions with the instance of the MDISDigitalInstrumentObjectType are initiated by the Client and are directed to the Server.

6.4.2 Overview

The following section details the MDIS generic properties for the MDISDigitalInstrumentObjectType; implementation shall ensure adherence to Mandatory [M] aspects in order to comply with the MDIS interface standardisation. Optional [O] may or may not be implemented within a project.

Figure 12 provides an overview of the MDISDigitalInstrumentObjectType as defined by MDIS, including some nested types. This figure includes all items that are inherited from the MDISBaseObjectType.

6.4.3 MDISDigitalInstrumentObjectType Definition

Table 19 defines the structure of an MDISDigitalInstrumentObjectType. Any vendor specified properties that have been implemented within a project should be documented within a similar format and supplied to the DCS vendor. The addition of vendor specific properties will result in a subtype of the MDISDigitalInstrumentObjectType.

State – The state of the instance of MDISDigitalInstrumentObjectType. This state is represented as a Boolean, where true indicates on and false indicates off.

The MDISDigitalInstrumentObjectType is a subtype of MDISBaseObjectType and inherit the FaultCode Variable. The MDISDigitalInstrumentObjectType defines the standard FaultCodes (for bits 0-15 as defined in 6.2.2) in Table 8. All subtypes of this the MDISDigitalInstrumentObjectType will inherit all FaultCodes defined in this table. Subtypes may define additional FaultCodes in their own table.

The MDISDigitalInstrumentObjectType defines the standard WarningCodes (for bits 0-15 as defined in 6.2.2) in Table 9. All subtypes of this the MDISDigitalInstrumentObjectType will inherit all WarningCodes defined in this table. Subtypes may define additional WarningCodes in their own table.

6.4.4 MDISDigitalOutObjectType

Table 22 defines the structure of an MDISDigitalOutObjectType. Any vendor specified properties that have been implemented within a project should be documented within a similar format and supplied to the DCS vendor. The addition of vendor specific properties will result in a subtype of the MDISDigitalOutObjectType.

WriteState – This Method allows a Client to change the value of State on an instance of MDISDigitalOutObjectType. The Method will return any errors that occurred on setting the value. The Client shall verify that the State actually changed to confirm the update. If the instrument is disabled, an error Bad_InvalidState shall be returned.

6.4.5 WriteState Method

WriteState Method (defined in Table 23) is used to change the state of the State Variable in an instance of MDISDigitalOutObjectType. The WriteState operation applies to the object in the subsea system. The value of the State Variable shall only be updated once the subsea system has provided a new value. For Objects that are used as a command, the value of the State Variable shall be updated directly to the value provided by the State parameter of the Method. Some systems will be able to report any errors immediately others will only be able to report that the operation was not refused. Clients are expected to monitor the State and ensure that the operation completed. If an error occurs after the Method has returned, a Fault flag shall be set and an appropriate FaultCode will be returned. The Fault (and FaultCode) will reset on the next successful WriteState Method invocation.

Signature:

	WriteState (
		[in] 0:Boolean State);
	

Method result codes are defined as part of the Call Service (see OPC 10000-4). They are described in Table 124 for ease of reference.

Comments

The WriteState Method will result in a change the state of the State Variable. The Method will report if any error occurs while writing the state of the Object. Table 24 specifies the AddressSpace representation for the WriteState Method.

6.4.6 MDISDigitalArbitrationObjectType Definition

Table 25 defines the structure of an MDISDigitalArbitrationObjectType. Any vendor specified properties that have been implemented within a project should be documented within a similar format and supplied to the DCS vendor. The addition of vendor specific properties will result in a subtype of the MDISDigitalArbitrationObjectType.

The MDISDigitalArbitrationObjectType handles the Selection of two analog sources, SourceA and SourceB. The result of the arbitration is shown in the State. The result can be either a selection of one source as default or forcing of one source (see ArbitrationModeEnum for additional details). The arbitration object will select which instrument is healthy and report it.

SourceA – a Variable that represents the value of the first source of a MDISDigitalArbitrationObjectType.

SourceB – a Variable that represents the value of the second source of a MDISDigitalArbitrationObjectType.

ArbitrationMode – This enumeration provides information about the arbitration mode that is currently used (see section 8.1.10). For a MDISDigitalArbitrationObjectType, the average value does not apply and the High value indicates an “Or” of the two values while a low value indicates an “And’ of the two values.

The MDISDigitalArbitrationObjectType is a subtype of MDISDigitalInstrumentObjectType and inherits the FaultCode Variable. The MDISDigitalArbitrationObjectType defines the standard FaultCodes (for bits 0-15 as defined in 6.2.2) in Table 26 (currently empty, no additional fault codes defined). All subtypes of this the MDISDigitalArbitrationObjectType will inherit all FaultCodes defined in this table. Subtypes may define additional FaultCodes in their own table.

The MDISDigitalArbitrationObjectType defines the standard WarningCodes (for bits 0-15 as defined in 6.2.2) in Table 27 (currently empty, no additional warning codes defined). All subtypes of this the MDISDigitalArbitrationObjectType will inherit all WarningCodes defined in this table. Subtypes may define additional WarningCodes in their own table.

6.5 MDISInstrumentObjectType

6.5.1 Introduction

The following section details the generic MDISInstrumentObjectType structure and defines the properties associated with it. Additional sections define a subtype MDISInstrumentOutObjectType that allows updates to the instrument value. This is in general a vendor and operator independent description, but all users of the MDISInstrumentObjectType or MDISInstrumentOutObjectType can add vendor specific data. The vendor specific data should be defined as part of a subtype of the MDISInstrumentObjectType defined in this document. It is assumed that the subsea system is the Server and host of the instance of the MDISInstrumentObjectType or MDISInstrumentOutObjectType. The DCS based system is the Client in the system. It is assumed that all interactions with the MDISInstrumentObjectType are initiated by the Client and are directed to the Server.

6.5.2 Overview

The following section details the MDIS generic properties for the MDISInstrumentObjectType. Implementation shall ensure adherence to Mandatory [M] aspects in order to comply with the MDIS interface standardisation. Optional [O] may or may not be implemented within a project. Figure 13 provides an overview of the MDISInstrumentObjectType as defined by MDIS, including some nested types. Figure 13 includes all of the items that are inherited from the MDISBaseObjectType.

6.5.3 MDISInstrumentObjectType Definition

Table 28 defines the structure of an MDISInstrumentObjectType. Any vendor specified properties that have been implemented within a project should be documented within a similar format and supplied to the DCS vendor. The addition of vendor specific properties will result in a subtype of the MDISInstrumentObjectType. If a MDISInstrumentObjectType instance is disabled, the MDISBaseObjectType defaults are followed and only the HHSetPoint, HSetPoint, LSetPoint and LLSetPoint object values will be available

ProcessVariable – a Variable in engineering units that represents the value of the instance of an MDISInstrumentObjectType. It includes properties that represent the engineering units; the engineering units range and optionally the instrument range, see OPC 10000-8. The components of the MDISInstrumentObjectType Type have additional subcomponents which are defined inTable 29.

The EUInformation DataType is defined in OPC 10000-8.

HHlimit – The instrument HH state is active

Hlimit – The instrument H state is active

Llimit – The instrument L state is active

LLlimit – The instrument LL state is active

HHSetPoint – Configuration of HHSetPoint which will set HHlimit be TRUE when the ProcessVariable value is greater than “set point value”. If this limit Variable exists on an object, but has not been configured, the HHSetPoint shall have a status code of Bad_ConfigurationError and Clients shall ignore the value. When the HHSetPoint has a Status of Bad_ConfigurationError, if the HHlimit exists, it shall have a status code of Bad_ConfigurationError and the value is ignored.

HSetPoint – Configuration of HSetPoint which will set Hlimit be TRUE when the ProcessVariable value is greater than “set point value”. If this limit Variable exists on an object, but has not been configured, the HSetPoint shall have a status code of Bad_ConfigurationError and Clients shall ignore the value. When the HSetPoint is ignored, if the Hlimit exists, it shall have a status code of Bad_ConfigurationError and the value is ignored.

LSetPoint – Configuration of LSetPoint which will set Llimit be TRUE when the ProcessVariable value is less than “set point value”. If this limit Variable exists on an object, but has not been configured, the LSetPoint shall have a status code of Bad_ConfigurationError and Clients shall ignore the value. When the LSetPoint is ignored, if the Llimit exists, it shall have a status code of Bad_ConfigurationError and the value is ignored.

LLSetPoint – Configuration of LLSetPoint which will set LLlimit be TRUE when the ProcessVariable value is less than “set point value”. If this limit Variable exists on an object, but has not been configured, the LLSetPoint shall have a status code of Bad_ConfigurationError and Clients shall ignore the value. When the LLSetPoint is ignored, if the LLlimit exists, it shall have a status code of Bad_ConfigurationError and the value is ignored.

The MDISInstrumentObjectType is a subtype of MDISBaseObjectType and inherit the FaultCode Variable. The MDISInstrumentObjectType defines the standard FaultCodes (for bits 0-15 as defined in 6.2.2) in Table 8. All subtypes of this the MDISInstrumentObjectType will inherit all FaultCodes defined in this table. Subtypes may define additional FaultCodes in their own table.

The MDISDigitalInstrumentObjectType defines the standard WarningCodes (for bits 0-15 as defined in 6.2.2) in Table 9. All subtypes of this the MDISDigitalInstrumentObjectType will inherit all WarningCodes defined in this table. Subtypes may define additional WarningCodes in their own table.

6.5.4 MDISInstrumentOutObjectType Definition

Table 32 defines the structure of an MDISInstrumentOutObjectType. Any vendor specified properties that have been implemented within a project should be documented within a similar format and supplied to the DCS vendor. The addition of vendor specific properties will result in a subtype of the MDISInstrumentOutObjectType.

WriteValue – This Method allows a Client to change the value of ProcessVariable on an instance of MDISInstrumentOutObjectType. The Method will return any errors that occurred on setting the value. If the Instrument is disabled, an error Bad_InvalidState shall be returned. The Client shall verify that the ProcessVariable actually changed to confirm the update.

6.5.5 Instrument WriteValue Method

Instrument WriteValue Method is used to change the value of the ProcessVariable in an instance of MDISInstrumentOutObjectType. The Instrument WriteValue Method operation applies to the object in the subsea system. The value of the ProcessVariable value will only update once the subsea system has provided a new value. Some systems will be able to report any errors immediately others will only be able to report that the operation was not refused. Clients are expected to monitor the ProcessVariable and ensure that the operation completed successfully. If an error occurs after the Method has returned, a Fault flag shall be set and an appropriate FaultCode will be returned. The Fault (and FaultCode) will reset on the next successful Instrument WriteValue Method invocation.

Signature:

	WriteValue (
		[in] 0:Float Value);
	

Method result codes are defined as part of the Call Service (see OPC 10000-4). They are described in Table 124 for ease of reference.

Comments

The WriteValue Method will result in a change the value of the ProcessVariable Variable. The Method will report if any error occurs while writing the value of the Object. Table 34 specifies the AddressSpace representation for the WriteValue

6.5.6 MDISInstrumentArbitrationObjectType Definition

Table 35 defines the structure of an MDISInstrumentArbitrationObjectType. Any vendor specified properties that have been implemented within a project should be documented within a similar format and supplied to the DCS vendor. The addition of vendor specific properties will result in a subtype of the MDISInstrumentArbitrationObjectType.

The MDISInstrumentArbitrationObjectType provides for the selection between two analog sources, SourceA and SourceB. The result of the arbitration is shown in the ProcessVariable. The result can be either an average, a selection of one source as default or forcing of one source. See the ArbitrationModeEnum for a complete list of possible modes.

SourceA – a Variable in engineering units that represents the value of the first source of a MDISInstrumentArbitrationObjectType. The EngineeringUnits and Range of the ProcessVariable apply to this value.

SourceB – a Variable in engineering units that represents the value of the first source of a MDISInstrumentArbitrationObjectType. The EngineeringUnits and Range of the ProcessVariable apply to this value.

ArbitrationMode – this enumeration identifies the current arbitration mode. For the complete list of arbitration modes, see section 8.1.10. [note: the selected mode might be different than the current mode reflected in this parameter, for example in the case of a failure the current mode might indicate SourceA even if Average was selected, due to a SourceB failure]

DiscrepancySetPoint – the value represents the maximum allow difference between the SourceA and SourceB values expressed as a percentage based on the full range of the instrument. This value can only be between 0 and 100. For example, if SourceA was 10.0 and SourceB was 20.0 and the instrument range was 0 to 200, the percentage would be 5%.

The MDISInstrumentArbitrationObjectType is a subtype of MDISInstrumentObjectType and inherits the FaultCode Variable. The MDISInstrumentArbitrationObjectType defines the standard FaultCodes (for bits 0-15 as defined in 6.2.2) in Table 36 (currently empty, no additional fault codes defined). All subtypes of this the MDISInstrumentArbitrationObjectType will inherit all FaultCodes defined in this table. Subtypes may define additional FaultCodes in their own table.

The MDISInstrumentArbitrationObjectType defines the standard WarningCodes (for bits 0-15 as defined in 6.2.2) in Table 37 (currently empty, no additional warning codes defined). All subtypes of this the MDISInstrumentArbitrationObjectType will inherits all WarningCodes defined in this table. Subtypes may define additional WarningCodes in their own table.

6.6 MDISChokeObjectType

6.6.1 Introduction

The following section details the generic MDISChokeObjectType structure and defines the properties associated with it. This is in general a vendor and operator independent description, but all users of the MDISChokeObjectType can add vendor specific data. The vendor specific data should be defined as part of a subtype of the MDISChokeObjectType defined in this document. It is assumed that the subsea system is the Server and host of the instance of the MDISChokeObjectType. The DCS based system is the Client in the system. It is assumed that all interactions with the instance of the MDISChokeObjectType are initiated by the Client and are directed to the Server.

6.6.2 Overview

The MDISChokeObjectType is a basic component of any subsea control system. Subsea and surface trees have a choke valve and it is used for regulating the flow volume and with it the back pressure of liquids or gas. This document will address the hydraulic choke valve found in subsea production and water injection trees. Implementation shall ensure adherence to Mandatory [M] aspects in order to comply with the MDIS interface standardisation. Optional [O] may or may not be implemented within a project. Figure 14 provides an overview of the Choke Object as defined by MDIS. It includes all items that are defined by the MDISBaseObjectType. It illustrates that an interlock might have one or more <InterlockVariables> associated with it, or that they might not have an actual interlock associated.

6.6.3 MDISChokeObjectType Definition

Table 38 defines the structure of an MDISChokeObjectType. Any vendor specified properties that have been implemented within a project should be documented within a similar format and supplied to the DCS vendor. The addition of vendor specific properties will result in a subtype of the MDISChokeObjectType. When an MDISChokeObjectType Instance is disabled the MDISBaseObjectType defaults are followed and only the StepDurationOpen, StepDurationClose and TotalSteps values will be available.

CalculatedPosition – A floating point number that represents the estimated percent open of the choke. This value can be updated using the SetCalculatedPosition Method.

SetCalculatedPositionStatus – an enumeration that reflect the status of a SetCalculatedPosition Command. This variable is present if the SetCalculatedPosition command can return asynchronously.

PositionInSteps – An Int16 that represents position in steps for the choke.

CommandRejected –– A flag that, if set to True, indicates that the choke has rejected the last command issued to it. The command could be rejected for a number of reasons. Possible reasons for rejecting a command include:

Loss of subsea communication reported by the SPCS.

An active interlock.

The choke is in the disabled state

Enabled – This Boolean reflects if the choke is available for control. The behaviour follows the MDISBaseObjectType.

Moving – An enumeration indicating the confirmed operation of the choke, (confirmed by SPCS Vendor). Possible status for a choke is moving and stopped.

Move – This Method allows an operator to increase or decrease the size of the opening in the choke. This command moves the choke to the percent value provided as part of the command.

Step – This Method allows an operator to increase or decrease the size of the opening in the choke. This command moves the choke the number of steps provided as part of the command.

Abort – This Method allows an operator to cancel any currently active move or step command.

SetCalculatedPosition – This Method is used to calibrate the CalculatedPosition. It can only be called when the choke is not moving.

EnableDisable – The choke, when disabled, places a non-defeatable interlock set on Move and Step functionality, in addition to the functionality described in the MDISBaseObjectType.

StepDurationOpen – SPCS open step duration period. This is the time in milliseconds for the choke to open one step.

StepDurationClose – SPCS close step duration period. This is the time in milliseconds for the choke to close one step.

TotalSteps – Total number of steps is the max steps of a choke.

<InterlockPlaceholder> – The number of interlock Variables will change based on the project and even choke instance. The Variables shall be of InterlockVariableType or a subtype of it. They will be referenced by a HasInterlock Reference and will contain an InterlockFor Reference. Clients can use this information to categorise the interlocks appropriately.

The following Variables indicate that an interlock is set (TRUE) or is not set (FALSE). The Variable shall be the target of an InterlockFor Reference from an instance of an InterlockVariableType that describes the actual interlock.

NonDefeatableOpenInterlock – The open choke command is interlocked and cannot be overridden.

DefeatableOpenInterlock – The open choke command is interlocked and can be overridden.

NonDefeatableCloseInterlock – The close choke command is interlocked and cannot be overridden.

DefeatableCloseInterlock – The close choke command is interlocked and can be overridden.

The MDISChokeObjectType is a subtype of MDISBaseObjectType and inherit the FaultCode Variable. The MDISChokeObjectType defines the standard FaultCodes (for bits 0-15 as defined in 6.2.2) in Table 39. All subtypes of this the MDISChokeObjectType will inherit all FaultCodes defined in this table. Subtypes may define additional FaultCodes in their own table.

The MDISChokeObjectType defines the standard WarningCodes (for bits 0-15 as defined in 6.2.2)in Table 40. All subtypes of this the MDISChokeObjectType will inherit all WarningCodes defined in this table. Subtypes may define additional WarningCodes in their own table.

6.6.4 Choke Move Method

Move Method is used to adjust the opening size in a choke.

Signature:

	Move (
			[in] 0:Float		Position,
			[in] 0:Boolean	OverrideInterlocks,
			[in] SEMEnum		SEM);
	

Method result codes are defined as part of the Call Service (see OPC 10000-4). They are described in Table 124 for ease of reference.

Comments:

The Move Method initiates a move command. Parameters include the position value in percent, overriding of any interlocks and the SEM selection to use for the command. The Position Method argument value shall be between 0 and 100. The server shall return Bad_OutOfRange if the Position Method argument value is outside of this range. After receiving the new commanded position, the choke will start to move. The Method will complete when the command has been accepted. The move operation may or may not have completed when the Method returns. The Method returns errors only if the operation cannot be started. The Client must monitor the Moving Variable to determine when the move operation actually finishes.

If a Server does not support an Override of defeatable interlocks, then this parameter will be ignored by the Server. If any interlocks are active the appropriate error code is returned.

If a Server does not support the selection of SEM, this parameter is ignored.

Table 42 specifies the AddressSpace representation for the choke Move Method.

6.6.5 Choke Step Method

Choke Step Method is used to adjust the opening size in a choke.

Signature

	Step (
			[in] ChokeCommandEnum		Direction,
			[in] 0:UInt16				Steps,
			[in] 0:Boolean			OverrideInterlocks,
			[in] SEMEnum				SEM);
	

Method result codes are defined as part of the Call Service (see OPC 10000-4). They are described in Table 124 for ease of reference.

Comments

The choke Step Method initiates a move command. Parameters include the direction (open or close), the number of steps to step, overriding of any interlocks and the SEM selection to use for the command. After receiving the command, the choke will start to move. The Method will complete when the command has been accepted. The move operation may or may not have completed when the Method returns. The Method returns errors only if the operation cannot be started. The Client must monitor the Moving Variable to determine when the Step command actually finishes.

If a Server does not support an override of defeatable interlocks, then the OverrideInterlocks parameter will be ignored by the Server and if any interlocks are active the appropriate error code is returned.

If a Server does not support the selection of SEM, the SEM parameter is ignored.

Table 44 specifies the AddressSpace representation for the Choke Step Method.

6.6.6 Choke Abort Method

Choke Abort Method is used to cancel any active move command in the Choke.

Signature:

	Abort ();

Method result codes are defined as part of the Call Service (see OPC 10000-4). They are described in Table 124 for ease of reference.

Comments

The choke Abort Method will try to cancel any active choke Move or Step commands. If no Move or Step command is in progress, the command will be ignored and return successful. The Method will complete when the command has been accepted. The abort operation may or may not have completed when the Method returns. The Method returns errors only if the operation cannot be started. The Client shall monitor the Moving and if provided the CommandRejected Variables to determine if the abort was successful or failed. Table 45 specifies the AddressSpace representation for the choke Abort Method.

6.6.7 Choke SetCalculatedPosition Method

SetCalculatedPosition Method is used to synchronise the CalculatedPosition to the actual choke position.

Signature:

	SetCalculatedPosition (
			[in] 0:Float Position);
	

Method result codes are defined as part of the Call Service (see OPC 10000-4). They are described in Table 124 for ease of reference.

Comments:

The SetCalculatedPosition Method is used to set the CalculatedPosition. It can only be called when the choke is not moving. The parameter is the calculated position. This method may return when the CalculatedPosition has been updated or it may return a status of Completes_Asynchronously. If it returns Completes_Asynchronously the Client will have to monitor the SetCalculatedPositionStatus to determine if an error occurred or the command completed. The SetCalculatedPositionStatus will reset on the next successful SetCalculatedPosition Method invocation.

Table 47 specifies the AddressSpace representation for the SetCalculatedPosition Method.

6.7 MDISElectricChokeObjectType

6.7.1 Introduction

The following section details the generic MDISElectricChokeObjectType structure and defines the properties associated with it. This is in general a vendor and operator independent description, but all users of the MDISElectricChokeObjectType can add vendor specific data. The vendor specific data should be defined as part of a subtype of the MDISElectricChokeObjectType defined in this document. It is assumed that the subsea system is the Server and host of the instance of the MDISElectricChokeObjectType. The DCS based system is the Client in the system. It is assumed that all interactions with the instance of the MDISElectricChokeObjectType are initiated by the Client and are directed to the Server.

6.7.2 Overview

The MDISElectricChokeObjectType is a basic component of any subsea control system. Subsea and surface trees have a choke valve and it is used for regulating the flow volume and with it the back pressure of liquids or gas. This document will address the electric choke valve found in subsea production and water injection trees. Implementation shall ensure adherence to Mandatory [M] aspects in order to comply with the MDIS interface standardisation. Optional [O] may or may not be implemented within a project. Figure 14 provides an overview of the Choke Object as defined by MDIS. It includes all items that are defined by the MDISBaseObjectType. It illustrates that an interlock might have one or more Interlock variables associated with it, or that they might not have an actual interlock associated.

6.7.3 MDISElectricChokeObjectType Definition

Table 38 defines the structure of an MDISElectricChokeObjectType. Any vendor specified properties that have been implemented within a project should be documented within a similar format and supplied to the DCS vendor. The addition of vendor specific properties will result in a subtype of the MDISElectricChokeObjectType. When an MDISElectricChokeObjectType Instance is disabled the MDISBaseObjectType defaults are followed.

ActualPosition – A floating point number that represents the percent open of the choke.

CommandRejected – A flag that, if set to True, indicates that the choke has rejected the last command issued to it. The command could be rejected for a number of reasons. Possible reasons for rejecting a command include:

Loss of subsea communication reported by the SPCS.

An active interlock.

The choke is in the disabled state

Enabled – This Boolean reflects if the choke is available for control. The behaviour follows the MDISBaseObjectType.

Moving – An enumeration indicating the confirmed operation of the choke, (confirmed by SPCS Vendor). Possible status for a choke is moving and stopped.

Move – This Method allows an operator to increase or decrease the size of the opening in the choke. This command moves the choke to the percent value provided as part of the command.

Abort – This Method allows an operator to cancel any currently active move command.

EnableDisable – The choke, when disabled, places a non-defeatable interlock set on Move functionality, in addition to the functionality described in the MDISBaseObjectType.

<InterlockPlaceholder> – The number of interlock Variables will change based on the project and even choke instance. The Variables shall be of InterlockVariableType or a subtype of it. They will be referenced by a HasInterlock Reference and will contain an InterlockFor Reference. Clients can use this information to categorise the interlocks appropriately.

The following Variables indicate that an interlock is set (TRUE) or is not set (FALSE). The Variable shall be the target of an InterlockFor Reference from an instance of an InterlockVariableType that describes the actual interlock.

NonDefeatableOpenInterlock – The open choke command is interlocked and cannot be overridden.

DefeatableOpenInterlock – The open choke command is interlocked and can be overridden.

NonDefeatableCloseInterlock – The close choke command is interlocked and cannot be overridden.

DefeatableCloseInterlock – The close choke command is interlocked and can be overridden.

The MDISElectricChokeObjectType is a subtype of MDISBaseObjectType and inherit the FaultCode Variable. The MDISElectricChokeObjectType defines the standard FaultCodes (for bits 0-15 as defined in 6.2.2) in Table 49. All subtypes of this the MDISElectricChokeObjectType will inherit all FaultCodes defined in this table. Subtypes may define additional FaultCodes in their own table.

The MDISElectricChokeObjectType defines the standard WarningCodes (for bits 0-15 as defined in 6.2.2) in Table 50. All subtypes of this the MDISElectricChokeObjectType will inherit all WarningCodes defined in this table. Subtypes may define additional WarningCodes in their own table.

6.8 MDISValveObjectType

6.8.1 Introduction

The following section details the generic MDISValveObjectType structure and defines the properties associated with it. This is in general a vendor and operator independent description, but all users of this MDISValveObjectType can add vendor specific data. The vendor specific data should be defined as part of a subtype of the MDISValveObjectType defined in this document. It is required that the subsea system is the Server and host of the valve Object. The DCS based system is the Client in the system. It is required that all interaction with the valve Object is initiated by the Client and is directed to the Server.

6.8.2 Overview

The valve Object is a basic component of any subsea control system. Subsea and surface trees have a large variety of valve configurations and combinations of manual and / or actuated (hydraulic or pneumatic) valves. Implementation shall ensure adherence to Mandatory [M] aspects in order to comply with the MDIS interface standardisation. Optional [O] may or may not be implemented within a project. Figure 16 provides an overview of the MDISValveObjectType as defined by MDIS. The figure includes all items inherited from the MDISBaseObjectType. It illustrates that an interlock might have one or more Interlock variables associated with it, or that they might not have an actual interlock associated.

6.8.3 MDISValveObjectType Definition

Table 51 details the generic properties for the MDISValveObjectType. Any vendor specified properties that have been implemented within a project should be documented within a similar format and supplied to the DCS vendor. The addition of vendor specific properties will result in a subtype of the MDISValveObjectType. When an MDISValveObjectType Instance is disabled the MDISBaseObjectType defaults are followed and only the OpenTimeDuration and CloseTimeDuration values will be available.

The following items describe status information from the valve:

SignatureRequestStatus – The collection of data required for a valve signature may take some time after the completion of a Move command. The SignatureRequestStatus Variable indicates the status of the current signature request (see 8.1.4 for a description of the possible enumerations).

LastCommand – The enumeration reflects the last command sent to the equipment by the SPCS (see 8.1.5 for a description of the possible enumerations).

Enabled – This Boolean reflects if the valve is available for control. The behaviour follows the MDISBaseObjectType.

Position – This enumeration provides information about the current position of the valve (see section 8.1.7 for additional details).

CommandRejected – A flag that, if set to True, indicates that the valve has rejected the last command issued to it. The command could be rejected for a number of reasons. Possible reasons for rejecting a command include:

Loss of subsea communication reported by the SPCS.

An active interlock.

The valve is in the disabled state.

For any of the following Variables, if they are true, there shall be at least one instance of an InterlockVariableType that describes the active interlock.

NonDefeatableOpenInterlock – The open valve command is interlocked and cannot be overridden.

DefeatableOpenInterlock – The open valve command is interlocked and can be overridden.

NonDefeatableCloseInterlock – The close valve command is interlocked and cannot be overridden.

DefeatableCloseInterlock – The close valve command is interlocked and can be overridden.

The following items are related to valve control: These items allow information to flow from the DCS to the SPCS. All commands from the DCS to SPCS may require access controls to ensure that only appropriate personnel initiate them.

Move – This Method causes the valve to open or close (see 6.8.4 for additional details).

<InterlockPlaceholder> – The number of interlock Variables will change based on the project and even valve instance. The Variables shall be of InterlockVariableType or a subtype of it. The interlock contains an InterlockFor Reference to one of the previously described flags. Clients can use this information to categorise the interlocks appropriately. Figure 17 provides an example of how this interlock Variable is used and could be deployed.

Note: in OPC UA it is allowed to have a Node which is the target of multiple 0:HasComponent References, this allows a single interlock to be shared between multiple Objects; such as a low pressure interlock that maybe shared by all of the valves and chokes in a system.

The following items describe configuration related items:

OpenTimeDuration – Estimated max time to travel to open position, used for DCS systems to indicate a move fail condition if time is exceeded. Time is provided in milliseconds. The OpenTimeDuration can be used for any kind of valve (hydraulic, electric, etc.). [Note: this time is an estimate and Clients may need to allow for additional delays in transmitting and receiving any move commands].

CloseTimeDuration - Estimated max time to travel to close position, used for DCS systems to indicate a move fail condition if time is exceeded. Time is provided in milliseconds. The CloseTimeDuration can be used for any kind of valve (hydraulic, electric, etc.) [Note: this time is an estimate and Clients may need to allow for additional delays in transmitting and receiving any Move commands].

<ValveSignature> - The reference shall point to an instance of FileType, where the file contains valve signature information. The name of this object is project or vendor specific, but it should be related to the name of the instance of the MDISValveObjectType. The name shall include a timestamp. The FileType ObjectType (defined in OPC 10000-5 (older version), OPC 10000-20 (newer versions)) includes two properties (illustrated below), for all MDIS instances both of these properties shall have the value False. For additional detail see 6.14.3.

Vendor specific subtypes of this ObjectType are allowed. They may add additional vendor specific information or may change some Optional items to Mandatory. A standard file content is defined in Annex E.

The MDISValveObjectType is a subtype of MDISBaseObjectType and inherit the FaultCode Variable. The MDISValveObjectType defines the standard FaultCodes (for bits 0-15 as defined in 6.2.2) in Table 52. All subtypes of this the MDISValveObjectType will inherit all FaultCodes defined in this table. Subtypes may define additional FaultCodes in their own table.

The MDISValveObjectType defines the standard WarningCodes (for bits 0-15 as defined in 6.2.2) in Table 53. All subtypes of this the MDISValveObjectType will inherit all WarningCodes defined in this table. Subtypes may define additional WarningCodes in their own table.

6.8.4 Valve Move Method

Move Method is used to open or close a valve.

Signature

	Move (
			[in] CommandEnum		Direction,
			[in] 0:Boolean		OverrideInterlock,
			[in] SEMEnum			SEM,
			[in] 0:Boolean		Signature,
			[in] 0:Boolean		ShutdownRequest);

Method result codes are defined as part of the Call Service (see OPC 10000-4). They are described in Table 124 for ease of reference.

Comments:

The Move Method initiates a move operation. Parameters include opening or closing of the valve, overriding of any interlocks, the SEM selection to use for the command, if a profile / signature is being requested for this move operation or if a shutdown is being requested. The Method will complete when the command has been accepted. If the command has not been accepted by the Server, then the Method returns an error indicating the operation could not be performed. In the case when the Move command is accepted by the Server, the move operation may or may not be complete at the time the Method returns to the Client. Therefore, the Client must monitor the Position of the valve to determine when the Move command actually finishes.

The OverrideInterlocks, SEM, Signature and Shutdown are optional parameters, but OPC UA Methods do not allow for optional parameters. These parameters must always be provided. On a Server basis the parameter may be configured to not be utilised. If a Server is configured to not utilise a parameter, this is because the functionality is not required.

Table 55 specifies the AddressSpace representation for the Move Method.

6.9 MDISCIMVObjectType

6.9.1 Introduction

The following section details the generic MDISCIMVObjectType and defines the properties associated with it. This is in general a vendor and operator independent description, but all users of the MDISCIMVObjectType can add vendor specific data. The vendor specific data should be defined as part of a subtype of the MDISCIMVObjectType defined in this document. It is assumed that the subsea system is the Server and host of the instance of the MDISCIMVObjectType. The DCS based system is the Client in the system. It is assumed that all interactions with the instance of the MDISCIMVObjectType are initiated by the Client and are directed to the Server.

6.9.2 Overview

The Chemical Injection Metering Valve (CIMV) is a basic component of any subsea control system. CIMVs regulate the flow of a chemical delivered to subsea production system. This document will address the CIMV found in subsea production trees. Implementation shall ensure adherence to Mandatory [M] aspects in order to comply with the MDIS interface standardisation. Optional [O] may or may not be implemented within a project. Figure 18 provides an overview of the CIMV Object as defined by MDIS and the MDISCIMVObjectType. It includes all items that are defined by the MDISBaseObjectType.

6.9.3 MDISCIMVObjectType Definition

Table 56 defines the structure of an MDISCIMVObjectType. Any vendor specified Properties that have been implemented within a project should be documented within a similar format and supplied to the DCS vendor. The addition of vendor specific properties will result in a subtype of the MDISCIMVObjectType. When an MDISCIMVObjectType Instance is disabled the MDISBaseObjectType defaults are followed - no additional values will be available.

The components of the MDISCIMVObjectType have additional references which are defined in Table 57.

OperationMode – An enumeration that reflects the current operating mode of the CIMV (see 8.1.8 for a description of the possible enumerations).

FlowRate – A float value that indicates the current inhibitor flow rate. It includes properties that represent the engineering units, the engineering units range and optionally the instrument range. Refer to table 16 for illustration.

TargetFlowRate – A float value that indicates the flow rate which the CIMV will automatically try to maintain when the OperationMode is set to “Flow” (refer to 8.1.8). It includes properties that represent the engineering units, the engineering units range and optionally the instrument range. Refer to table 16 for illustration. The SetFlowRate method (refer to 6.9.5) can be used to change this value.

TotalFlow – A float value that indicates the accumulated volume of inhibitor which has been injected since it was last reset. It includes properties that represent the engineering units, the engineering units range and optionally the instrument range. Refer to table 16 for illustration. If the TotalFlow is provided then the ResetTotalFlow Method shall also be provided.

Position – A Float that represents the current position in percent open for the CIMV.

TargetPosition – A Float that represents the position in percent open which the CIMV will automatically try to maintain when the OperationMode is set to “Position” (refer to 8.1.8). The SetPosition method (refer to 6.9.6) can be used to change this value.

Moving – An enumeration indicating the confirmed operation of the CIMV (confirmed by SPCS Vendor). (see 8.1.9 for a description of the possible enumerations)

TotalMotorRuntime – A value that indicates the accumulated duration of time that the motor has run since it was put into service. The object includes a reset method (see 6.10).

MotorOperationsCount – A value that indicates the total number of motor operations that have been completed since it was last reset. The object includes a reset method (see 6.10).

DeviceCurrent – The measure of the Electrical current being consumed by the device (e.g., motor operations). It includes properties that represent the engineering units, the engineering units range and optionally the instrument range. Refer to table 16 for illustration.

InletPressure – Current pressure on the upstream side of the throttling valve. Upstream in this case means closer to the source of the inhibitor chemical than the throttling valve. It includes properties that represent the engineering units, the engineering units range and optionally the instrument range. Refer to table 16 for illustration.

InternalPressure – Current pressure at the stem of the throttling valve. It includes properties that represent the engineering units, the engineering units range and optionally the instrument range. Refer to table 16 for illustration.

OutletPressure – Current pressure on the downstream side of the throttling valve. Downstream in this case means further from the source of the inhibitor chemical than the throttling valve. It includes properties that represent the engineering units, the engineering units range and optionally the instrument range. Refer to table 16 for illustration.

CommandRejected –– A flag that, if set to True, indicates that the CIMV has rejected the last command issued to it. The command could be rejected for a number of reasons. Possible reasons for rejecting a command include:

Loss of subsea communication reported by the SPCS.

An active interlock.

The CIMV is in the disabled state

Enabled – This Boolean reflects if the CIMV is available for control. The behaviour follows the MDISBaseObjectType.

SetOperationMode – This Method commands the CIMV into one of its operating modes – Position control mode, Flow control mode or Manual control mode.

SetFlowRate – This Method sets the CIMV flow rate when in flow control mode. The CIMV must be in flow control mode in order to invoke this method. It shall return an error if it is not in FlowControlMode

SetPosition – This Method sets the CIMV position when in position control mode. The CIMV must be in position mode in order to invoke this method. It shall return an error if it is not in PositionControlMode

SetManual – This Method allows an operator to open or close the CIMV to the specified percentage. The CIMV must be in manual mode in order to invoke this method. It shall return an error if it is not in ManualControlMode

Abort – This Method allows an operator to cancel any currently active SetOperationMode, SetFlowRate, SetPosition or Move command and return the operation mode to manual.

NonDefeatableCloseInterlock – The close CIMV command is interlocked and cannot be overridden.

NonDefeatableOpenInterlock – The open CIMV command is interlocked and cannot be overridden.

NonDefeatableCommandInProgressInterlock – A CIMV command is progress and no new commands can be issued until the current command ends or is stopped.

<InterlockPlaceholder> – The number of interlock Variables will change based on the project and even CIMV instance. The Variables shall be of InterlockVariableType or a subtype of it. They will be referenced by a HasInterlock Reference and will contain an InterlockFor Reference. Clients can use this information to categorise the interlocks appropriately.

The MDISCIMVObjectType is a subtype of MDISBaseObjectType and inherit the FaultCode Variable. The MDISCIMVObjectType defines the standard FaultCodes (for bits 0-15 as defined in 6.2.2) in Table 58. All subtypes of this the MDISCIMVObjectType will inherit all FaultCodes defined in this table. Subtypes may define additional FaultCodes in their own table.

The MDISCIMVObjectType defines the standard WarningCodes (for bits 0-15 as defined in 6.2.2) in Table 59. All subtypes of this the MDISCIMVObjectType will inherit all WarningCodes defined in this table. Subtypes may define additional WarningCodes in their own table.

6.9.4 SetOperationMode Method

SetOperationMode Method is used to change the operation mode of the CIMV.

Signature

	SetOperationMode (
			[in] CIMVOperationModeEnum		Mode,
			[in] SEMEnum					SEM,
			[in] 0:Boolean				ShutdownRequest);

Method result codes are defined as part of the Call Service (see OPC 10000-4). They are described in Table 124 for ease of reference.

Comments

The SetOperationMode Method initiates a change of operation mode command. Parameters include selection of operation mode and the SEM selection to use for the command. The method will complete when the command has been accepted. If the command has not been accepted by the Server, then the Method returns an error indicating the operation could not be performed. In the case when the SetOperationMode command is accepted by the Server, the operation may or may not be complete at the time the Method returns to the Client. Therefore, the Client must monitor the OperationMode of the CIMV to determine when the SetOperationMode command actually finishes. If the CIMV current OperationMode is the same as the mode specified in the SetOperationMode Method argument then the Server shall return a successful operation result but ignore the command. If the requested Mode is not support (i.e. Manual) the method shall return an error Bad_OutOfRange, indicating that the requested mode is not supported.

If a Server does not support the selection of SEM, the SEM parameter is ignored.

ShutdownRequest is a Boolean that indicates that this command is part of a shutdown sequence. It should be noted that the responsibility for the shutdown is on the DCS and operator side. All nondefeatable interlocks of the subsea system will be overridden which can cause damage to the subsea system.

Table 61 specifies the AddressSpace representation for the SetOperationMode Method.

6.9.5 SetFlowRate Method

SetFlowRate Method is used to set a target flow rate.

Signature

	SetFlowRate (
			[in] 0:Float		FlowRate,
			[in] SEMEnum		SEM,
			[in] 0:Boolean	ShutdownRequest);
	

Method result codes are defined as part of the Call Service (see OPC 10000-4). They are described in Table 124 for ease of reference.

Comments

The SetFlowRate Method commands the CIMV to automatically maintain the given flow rate. Parameters include the requested flow rate, overriding of any interlocks and the SEM selection to use for the command. The FlowRate Method argument is of datatype float however the actual units are device specific. Refer to FlowRate and TargetFlowRate component of MDISCIMVObjectType discussed in 6.9.3. The Method will complete when the command has been accepted. After receiving the new commanded flow rate, the CIMV will update the TargetFlowRate to the value of the FlowRate input parameter and will automatically maintain the target rate. The CIMV must be in operation mode Flow (refer to 8.1.8) otherwise the Method shall return Bad_InvalidState. The operation may or may not have completed when the Method returns. The Method will return an error if the operation cannot be started.

If a Server does not support the selection of SEM, the SEM parameter is ignored.

ShutdownRequest is a Boolean that indicates that this command is part of a shutdown sequence. It should be noted that the responsibility for the shutdown is on the DCS and operator side. All nondefeatable interlocks of the subsea system will be overridden which can cause damage to the subsea system.

Table 63 specifies the AddressSpace representation for the SetFlowRate Method.

6.9.6 SetPosition Method

SetPosition Method is used to set a target position.

Signature

	SetPosition (
			[in] 0:Float		Position,
			[in] SEMEnum		SEM
			[in] 0:Boolean	ShutdownRequest);

Method result codes are defined as part of the Call Service (see OPC 10000-4). They are described in Table 124 for ease of reference.

Comments

The SetPosition Method commands the CIMV to move to and automatically maintain the position. Parameters include the requested position, overriding of any interlocks and the SEM selection to use for the command. The Position Method argument is of datatype float and represents percent of open. The Position Method argument value shall be between 0 and 100. The server shall return Bad_OutOfRange if the Position Method argument value is outside of this range. The Method will complete when the command has been accepted. After receiving the new commanded position, the CIMV will store the value of the input param Position in the TargetPosition and will automatically maintain the position. Refer to Position and TargetPosition component of MDISCIMVObjectType discussed in 6.9.3. The CIMV must be in operation mode Position_1 (refer to 8.1.8) otherwise the Method shall return Bad_InvalidState. The operation may or may not have completed when the Method returns. The Method will return an error if the operation cannot be started.

If a Server does not support the selection of SEM, the SEM parameter is ignored.

ShutdownRequest is a Boolean that indicates that this command is part of a shutdown sequence. It should be noted that the responsibility for the shutdown is on the DCS and operator side. All nondefeatable interlocks of the subsea system will be overridden which can cause damage to the subsea system.

Table 65 specifies the AddressSpace representation for the SetPosition Method.

6.9.7 SetManual Method

CIMV SetManual Method is used to open or close the CIMV to a specified percent of open position.

Signature:

	SetManual (
		[in] CIMVMoveEnum		Direction,
		[in] 0:Float			Delta,
		[in] SEMEnum			SEM,
		[in] 0:Boolean		ShutdownRequest);

Method result codes are defined as part of the Call Service (see OPC 10000-4). They are described in Table 124 for ease of reference.

Comments

The SetManual Method commands the CIMV to move in the specified direction (open or close) the specified delta. Parameters include Direction 4 (refer to 8.1.9), the delta value in percent, overriding of any interlocks, the SEM selection to use for the command and if this is a shutdown request. After receiving the new commanded position, the CIMV will start to move. The server shall return Bad_OutOfRange when the Delta method argument value would result in the CIMV moving to a position less than 0 or greater than 100. For example, if the current position is 50, the method shall not be called with a Delta method argument value > 50 in either the open or close direction. The Method will complete when the command has been accepted. The move operation may or may not have completed when the Method returns. The CIMV must be in operation mode Manual_4 (refer to 8.1.8) otherwise the Method shall return Bad_InvalidState the Method returns an error if the operation cannot be started. The Client must monitor the Moving Variable to determine when the move operation actually finishes.

If a Server does not support the selection of SEM, the SEM parameter is ignored.

ShutdownRequest is a Boolean that indicates that this command is part of a shutdown sequence. It should be noted that the responsibility for the shutdown is on the DCS and operator side. All non defeatable interlocks of the subsea system will be overridden which can cause damage to the subsea system.

Table 67 specifies the AddressSpace representation for the Move Method.

6.9.8 Abort Method

CIMV Abort Method is used to halt any in-progress command, hold current position and return the operation mode to manual.

Signature:

	Abort ( );
	

Method result codes are defined as part of the Call Service (see OPC 10000-4). They are described in Table 124 for ease of reference.

Comments

In manual operation mode (refer to 8.1.8), the Abort Method will try to cancel any active CIMV Move command and hold current position. If no Move command is in progress, the command will be ignored and return successful. In position or flow operation mode (refer to 8.1.8), the Abort Method will try to cancel any activity associated with the current operation mode, hold current position and set the CIMV to manual operation mode. The Method will complete when the command has been accepted. The abort operation may or may not have completed when the Method returns. The Method returns errors only if the operation cannot be started. The Client shall monitor the Moving Variable and the OperationMode Variable and, if provided, the CommandRejected Variables to determine if the Abort command was successful or failed

Table 68 specifies the AddressSpace representation for the Abort Method.

6.9.9 ResetTotalFlow Method

ResetTotalFlow Method is used to reset the TotalFlow counter.

Signature:

	ResetTotalFlow (
		[in] 0:Float Initial);

Method result codes are defined as part of the Call Service (see OPC 10000-4). They are described in Table 124 for ease of reference.

Comments

Table 68 specifies the AddressSpace representation for the ResetTotalFlow Method.

6.10 MDISCounterObjectType

6.10.1 Introduction

The following section details the generic MDISCounterObjectType structure. This ObjectType can be used as part of any aggregate that requires a duration to be included, such as TotalRunTime. This is in general a vendor and operator independent description, but all users of the MDISCounterObjectType can add vendor specific data. The vendor specific data should be defined as part of a subtype of the MDISCounterObjectType defined in this document. It is assumed that the subsea system is the Server and host of the instance of the MDISCounterObjectType. The DCS based system is the Client in the system. It is assumed that all interactions with the instance of the MDISCounterObjectType are initiated by the Client and are directed to the Server.

6.10.2 Overview

The following section details the MDIS generic properties for the MDISCounterObjectType. Implementation shall ensure adherence to Mandatory [M] aspects in order to comply with the MDIS interface standardisation. Optional [O] may or may not be implemented within a project. Figure 20 provides an overview of the MDISCounterObjectType as defined by MDIS.

6.10.3 MDISCounterObjectType Definition

Table 71 defines the structure of an MDISCounterObjectType. Any vendor specified properties that have been implemented within a project should be documented with a similar format and supplied to the DCS vendor. The addition of vendor specific properties will result in a subtype of the MDISCounterObjectType.

How this value is calculated is server specific. The name of an instance of this ObjectType shall indicate what the object is, such as TotalMotorRuntime, for an example of how this Object is used see 6.9

6.10.4 SetCount Method

SetCount Method is used to Set the Count. This Count maybe any counter.

Signature:

	SetCount (
		[in] 0:Number Initial);
	

Method result codes are defined as part of the Call Service (see OPC 10000-4). They are described in Table 124 for ease of reference.

Comments

The SetCount Method command resets the value of the Count Variable. The Count Variable, may immediately start incrementing depending on how it is defined.

Table 73 specifies the AddressSpace representation for the SetCount Method.

6.11 MDISMotorObjectType

6.11.1 Introduction

The following section details the generic MDISMotorObjectType structure and defines the properties associated with controlling a Motor. This is in general a vendor and operator independent description, but all users of the MDISMotorObjectType can add vendor specific data. The vendor specific data should be defined as part of a subtype of the MDISMotorObjectType defined in this document. It is assumed that the subsea system is the Server and host of the instance of the MDISMotorObjectType. The DCS based system is the Client in the system. It is assumed that all interactions with the instance of the MDISMotorObjectType are initiated by the Client and are directed to the Server.

6.11.2 Overview

The following section details the MDIS generic properties for the MDISMotorObjectType. Implementation shall ensure adherence to Mandatory [M] aspects in order to comply with the MDIS interface standardisation. Optional [O] may or may not be implemented within a project. Figure 20 provides an overview of the MDISMotorObjectType as defined by MDIS, including some nested types. Figure 20 includes all of the items that are inherited from the MDISBaseObjectType.

6.11.3 MDISMotorObjectType Definition