This section defines information related to Instance Objects, value handling, UANodeSet and customised Objects

An MDIS Server shall include an instance of the MDISInformationObjectType under the Objects folder.

Figure 24 – MDIS Instance illustration

Any other structure under in the MDIS Server is vendor or project specific. Figure 24 provides an illustration of one possible instance structure, it is not the only available structure. Several of the items are optional and might not appear. The valve signature objects illustrate that valves might include multiple signatures for a given valve, no signatures for a given valve and that the single folder might contain signature from multiple trees. The naming use is project / vendor specific but might have to handle all of these cases. Signatures might also exist for other objects such as chokes.

The MDISInformation node is formally defined in Table 119.

Table 119 – MDISInformation definition

Attribute	Value
BrowseName	MDISInformation
References	NodeClass	BrowseName	TypeDefinition
OrganizedBy by the Objects Folder defined in OPC 10000-5
HasTypeDefinition	ObjectType	MDISInformationObjectType
ConformanceUnits

Data overflow at the SPCS shall be detected by the Client. This shall be performed through the use of a queue size greater than 1 on subscriptions and monitoring of the overflow bit in all received values. If an overflow occurs the Client shall generate some notification, but the exact notification is Client vendor specific.

In OPC UA an AddressSpace is separated into Namespaces, where each Namespace defines the owner of the address space contained in it. The MDIS Namespace shall not be modified in any manner, it is owned by MDIS. Any implementation (custom types / instances) shall be in a separate Namespace from the MDIS Namespace.

Any custom types or subtypes of the standard MDIS Types, as defined in Section 10.5.2 should be separated from instances via Namespaces. This enables custom types to be shared across DCS vendors and SPCS vendors during early phases of project development and allows the DCS vendors to begin implementation of the custom types within the DCS software. It also allows reuse of types between projects.

When UANodeSet files are passed from the SPCS vendors to the DCS vendors, the whole address space is to be exchanged (i.e. the exchanged UANodeSet files shall include the MDIS Namespace and any custom Namespaces). A Namespace can be in a single UANodeSet file and multiple files are provided or the entire address space can be in a single UANodeSet file. Having all Namespaces shall enable the DCS vendors to understand any forward References as forward References can create ambiguity within developed UANodeSet files.

The length of the namespace URLs used for defining Namespaces should be less than 128 characters. This is to enable smaller devices like controllers to be able to store Namespaces. NamespaceUri usually reference back to the company that is the owner of the Namespace.

The NodeIds should be integers. If using strings, the length of the NodeIds shall be less than 32 characters. This shall enable smaller devices like controllers to process NodeIds efficiently.

NodeIds shall be fixed. When a Server restarts NodeIds shall not be changed. NodeIds should not be reused on a project. Any change in NodeIds shall require Clients to reconfigure the connection based on new generated UANodeSet files. Once a Nodeset file is delivered to a DCS vendor from the SPCS vendor the NodeIds in the file are fixed. Future NodeSet files might add or delete nodes. But in any future Nodeset file shall not change the Nodeid of any Objects that have been delivered in the prior NodeSet file.

For custom types the instance hierarchy shall be represented via HasComponent (standard OPC UA Reference) or a custom ReferenceType that has been subtyped from HasComponent or Organizes References only.

This section provides guidance on creation of modified and composite objects for use in compliance with MDIS standards. Standard MDIS Objects defined in Section 6 shall be used wherever possible. In the event that standard Objects cannot represent a given subsea component or piece of equipment, a new Object shall be developed by collection, aggregation or extension of existing Objects. Use of collection, aggregation or extension to model subsea equipment is dependent on vendor implementations.

Object collection shall be implemented using folders and should be used to group components or equipment that are physically grouped together in a common structure. Several examples of where object collection could be utilised would include modelling Subsea Electronics Modules, Electronic Power Units and Wells.

Object aggregation shall be implemented by creating a subtype of the MDISAggregateObjectType and should be used to group relevant objects to represent a complex piece of equipment that cannot be represented by a single MDIS Object. A specific example of where Object aggregation could be used would be modelling Multiphase Flow Meters (MPFMs). Aggregated Objects have specific rules, defined below, to allow Clients to be able to discover them and easily support them.

Object extension shall be implemented by creating a subtype of an existing MDIS Object and should be used when an existing MDIS Object, such as a valve Object, has additional information or functionality that needs to be represented. An example might be a vendor specific valve, that follows all of the rules associated with a MDISValveObjectType, but includes additional diagnostic information related to the vendor specific valve. Extension of Objects applies to models defined in section 6 and listed below:

• MDISInstrumentObjectType
• MDISInstrumentOutObjectType
• MDISInstrumentArbitrationObjectType
• MDISDigitalInstrumentObjectType
• MDISDigitalOutObjectType
• MDISDigitalArbitrationObjectType
• MDISDiscreteInstrumentObjectType
• MDISDiscreteOutObjectType
• MDISDiscreteArbitrationObjectType
• MDISValveObjectType
• MDISChokeObjectType
• MDISElectricChokeObjectType
• MDISCIMVObjectType
• MDISMotorObjectType

Subtyping MDISBaseObjectType and MDISCounterObjectType is not allowed.

Figure 25 illustrates an extension that adds a simple diagnostic variable.

Figure 25 – Extension Example

Rules for developing aggregated and extended objects are provided in Table 120. To minimise variability, when aggregating or extending objects only instances of the following VariableTypes and ObjectTypes shall be used:

• Standard MDIS Objects defined in section 6.
• BaseDataVariableType
• DiscreteItemType (Variable)
• AnalogItemType (Variable)

Table 120 – Aggregation and Extension Decision Matrix

Description	Aggregation	Extension
Require new NodeId on TypeDefinition level	Yes	Yes
0) Define new ObjectType with any non-MDIS parent	No	No
1) Define new ObjectType with any MDIS parent (subtyping MDIS ObjectTypes - MDISValveObjectType, MDISChokeObjectType, MDISElectricChokeObjectType, MDISMotorObjectType, MDISCIMVObjectType, MDISDigitalInstrumentObjectType, MDISInstrumentObjectType, MDISDiscreteInstrumentObjectType or any subtype of these types)	No	Yes
2) Define new ObjectType with MDISAggregateObjectType as parent	Yes	No

The operations described in Table 121 are valid operations in a generic OPC UA Server, but for an MDIS Server they are restricted as described in the table. All changes shall be based on type changes. Instance specific changes are not allowed.

Table 121 – General rules that apply to existing MDIS types

Description	Aggregation	Extension
Add MDIS Object instance to an instance of an existing MDIS ObjectType (or subtype).	No	No
Add non-MDIS Object instance to existing MDIS ObjectType (or subtype).	No	No
Add non-MDIS Object instance to an instance of an existing MDIS ObjectType (or subtype).	No	No
Add Method to an existing MDIS ObjectType (or subtype).	No	No
Add a Variable instance to an instance of an existing MDIS ObjectType (or subtype).	No	No
Add a Variable instance to an existing MDIS ObjectType.	No	No
Base MDIS Object’s compliance to MDIS OPC UA specs shall be demonstrable (CTT).	Yes	Yes

When extending an existing ObjectType, the rules described in

Table 122 apply to the MDIS Objects defined in Section 6. These rules apply to MDISValveObjectType, MDISChokeObjectType, MDISElectricChokeObjectType, MDISMotorObjectType, MDISCIMVObjectType, MDISInstrumentObjectType, MDISDigitalInstrumentObjectType, MDISDiscreteInstrumentObjectType or any subtype of these types; they do not apply to the MDISBaseObjectType and the MDISAggregateObjectType. The MDISBaseObjectType cannot be extended or subtyped by a vendor or project. Only the MDIS working group can extend the MDISBaseObjectType or create new a subtype of it. The MDISAggregateObjectType has its own set of rules. Extending existing ObjectTypes are restricted to limit available additions to allow Clients to pick up the new types without requiring coding changes to the Client.

Table 122 – Rules for subtypes

Description	Extension
Add a BaseDataVariableType instance to the newly create subtype of an MDIS ObjectType (MDISValveObjectType, MDISChokeObjectType, MDISElectricChokeObjectType, MDISCIMVObjectType, MDISMotorObjectType, MDISDigitalInstrumentObjectType, MDISDiscreteInstrumentObjectType, MDISInstrumentObjectType or any subtype of these types), with a DataType of one of the OPC BaseDataType excluding structure.	Yes
Add an instance of an AnalogItemType to the newly created subtype of an MDIS ObjectType.	Yes
Add an instance of a DiscreteItemType to the newly created subtype of an MDIS ObjectType.	Yes
Change ModellingRule from Optional -> Mandatory for any of existing properties or components.	Yes

Table 123 describes rules for creating an aggregate object. They only apply as described.

Table 123 – Aggregation Related Rules

Description	Aggregate
Add a MDIS Object InstanceDeclaration to the newly created subtype of MDISAggregateObjectType	Yes
Add a MDIS Variable instance to the newly created sub type of the MDISAggregateObjectType	Yes
Add a MDIS defined Reference to the newly created subtype of MDISAggregateObjectType.	Yes

Clients are expected to be able to handle new aggregate Objects, even if the Client only lists them as separate MDIS Objects and Variables of which they are composed. Clients are not required to handle an extension Object’s additional Variables, but they are required to support instances of the extension object. Clients that are unable to handle the extension Object’s additional Variables shall treat the extension object as an instance of the parent standard MDIS ObjectType. It is expected that some projects will require supporting the additional Variables defined in an extension Object.

ObjectTypes that are not an aggregated, extended or collection ObjectType can only be defined by the MDIS organisation. If a vendor (or group of vendors) determines that an ObjectType might be a candidate for creation as a new ObjectType, the proposed ObjectType needs to be submitted to or proposed to the MDIS organisation. If the MDIS organisation determines that a new ObjectType is to be created, it will be incorporated into the MDIS OPC UA Companion Specification. These new Objects shall be reviewed and validated by the MDIS organisation members.

The following is an example for creating an aggregated model of a simple MPFM Object. A generic model of a MPFM could have the following items:

• GasFlow (32 bit, float)
• WaterFlow (32 bit, float)
• OilFlow (32 bit, float)

The following figure illustrates the resulting TypeDefinition with example Object instances. It includes three instances of MDISInstrumentObjectType Objects that represent the flows. As can be seen in the example figure, a common type definition allows for multiple identical Object instances to be created.

Figure 26 – Aggregated ObjectType Definition

A vendor does not have to generate aggregate Objects; it can just provide a list of the base MDIS Objects that are being exposed. For example, a Well might not be configured as a subtype of MDISAggregateObjectType it might be a folder that contains the MDIS Objects that comprise the Well. If a structure is to be repeated, generating a subtype of the MDISAggregateObjectType for the structure can simplify testing and Client configuration work.