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.

The MDISBaseObjectType 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.

The MDISDiscreteInstrumentObjectType 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 integer values from instruments. For a limit switch or on / off switch the MDISDigitalInstrumentObjectType should be used.

The MDISDiscreteOutObjectType 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.

The MDISDigitalInstrumentObjectType 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.

The MDISDigitalOutObjectType 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.

The MDISInstrumentObjectType 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.

The MDISInstrumentOutObjectType 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.

The MDISChokeObjectType object 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).

The MDISValveObjectType object 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.

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 9.5

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

The MDISInformationObjectType (see 5.10) 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.

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)

Figure 9 - MDISBaseObjectType

Figure 10 - Base Object Hierarchy

The Table 4 defines the structure of an MDISBaseObjectType.

Table 4 - MDISBaseObjectType

Attribute	Value
BrowseName	MDISBaseObjectType
IsAbstract	True
References	Node Class	BrowseName	Data Type	TypeDefinition	ModellingRule	RW
Subtype of the BaseObjectType defined in OPC UA Part 5 – Information Model
HasComponent	Variable	Fault	Boolean	BaseDataVariableType	Mandatory	R
HasComponent	Variable	Warning	Boolean	BaseDataVariableType	Optional	R
HasComponent	Variable	Enabled	Boolean	BaseDataVariableType	Optional	R
HasProperty	Variable	TagId	String	PropertyType	Optional	R
HasComponent	Method	EnableDisable	See 5.2.3		Optional
HasComponent	Variable	FaultCode	UInt32	BaseDataVariableType	Optional	R
HasComponent	Variable	WarningCode	UInt32	BaseDataVariableType	Optional	R
HasSubtype		MDISDigitalInstrumentObjectType
HasSubtype		MDISDiscreteInstrumentObjectType
HasSubtype		MDISChokeObjectType
HasSubtype		MDISInstrumentObjectType
HasSubtype		MDISValveObjectType
HasSubtype		MDISAggregateObjectType

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

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. For the MDISBaseObjectType the default is that only the Enabled flag, TagId and Enable 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 SPCS vendor will provide a definition of what the number means. It might be a bit field or a fault code.

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. It might be a bit field or an error code. If a WarningCode is provided then the Warning flag shall also be provided.

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.

Method Declaration

EnableDisable (

[in] Enable Boolean

);

Table 5 - EnableDisable Method parameters

Argument	Description
Enable	Boolean indicator of whether the Object is to be disabled or enabled. A true indicates that the Object is enabled.

Method result codes are defined as part of the Call Service (see OPC UA Services Part 4 – Services specification). They are described in Table 94 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.

Table 6 - EnableDisableMethod AddressSpace Definition

Attribute	Value
BrowseName	Disable
References		Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
HasProperty		Variable	InputArguments	Argument[]	PropertyType	Mandatory

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.

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.

Figure 11 - MDISDiscreteInstrumentObjectType & MDISDiscreteOutObjectType

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.

Table 7 - MDISDiscreteInstrumentObjectType

Attribute	Value
BrowseName	MDISDiscreteInstrumentObjectType
IsAbstract	False
References	Node Class	BrowseName	DataType	TypeDefinition	ModellingRule	RW
Subtype of the MDISBaseObjectType (see section 5.1.1)
HasComponent	Variable	State	UInt32	BaseDataVariableType	Mandatory	R
HasSubtype	MDISDiscreteOutObjectType

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

Table 8 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.

Table 8 - MDISDiscreteOutObjectType

Attribute	Value
BrowseName	MDISDiscreteOutObjectType
IsAbstract	False
References	Node Class	BrowseName	DataType	TypeDefinition	ModellingRule	RW
Subtype of the MDISDiscreteInstrumentObjectType (see section 5.1.2)
HasComponent	Method	WriteValue	See 5.3.5		Mandatory

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.

WriteValue Method (defined in Table 9) is used to change the value of the State Variable in an instance of the MDISDiscreteOutObjectType. The WriteValue operation applies to the object in the subsea system. 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.

Method Declaration

WriteValue (

[in] State UInt32

);

Table 9 - WriteValue Method parameters

Argument	Description
State	UInt32 value Variable, that indicates the target state of the Variable

Method result codes are defined as part of the Call Service (see OPC UA Services Part 4 – Services specification). They are described in Table 94 for ease of reference.

Comments

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

Table 10 - WriteValue Method AddressSpace Definition

Attribute	Value
BrowseName	State
References		Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
HasProperty		Variable	InputArguments	Argument[]	PropertyType	Mandatory

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.

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.

Figure 12 - MDISDigitalInstrumentObjectType & MDISDigitalOutObjectType

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

Table 11 - MDISDigitalInstrumentObjectType

Attribute	Value
BrowseName	MDISDigitalInstrumentObjectType
IsAbstract	False
References	Node Class	BrowseName	DataType	TypeDefinition	ModellingRule	RW
Subtype of the MDISBaseObjectType (see section 5.1.1)
HasComponent	Variable	State	Boolean	BaseDataVariableType	Mandatory	R
HasSubtype	MDISDigitalOutObjectType

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

Table 12 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.

Table 12 - MDISDigitalOutObjectType

Attribute	Value
BrowseName	MDISDigitalOutObjectType
IsAbstract	False
References	Node Class	BrowseName	DataType	TypeDefinition	ModellingRule	RW
Subtype of the MDISDigitalInstrumentObjectType
HasComponent	Method	WriteState	See 5.4.5		Mandatory

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.

WriteState Method (defined in Table 13) is used to change the state of the State Variable in an instance of the MDISDigitalOutObjectType. The WriteState operation applies to the object in the subsea system. 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.

Method Declaration

WriteState (

[in] State Boolean

);

Table 13 – WriteState Method parameters

Argument	Description
State	Boolean indicator of the target state of the variable

Method result codes are defined as part of the Call Service (see OPC UA Services Part 4 – Services specification). They are described in Table 94 for ease of reference.

Comments

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

Table 14 - WriteState Method AddressSpace Definition

Attribute	Value
BrowseName	State
References		Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
HasProperty		Variable	InputArguments	Argument[]	PropertyType	Mandatory

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.

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.

Figure 13 - MDISInstrumentObjectType & MDISInstrumentOutObjectType

Table 15 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

Table 15 - MDISInstrumentObjectType

Attribute	Value
BrowseName	MDISInstrumentObjectType
IsAbstract	False
References	Node Class	BrowseName	DataType	TypeDefinition	ModellingRule	RW
Subtype of the MDISBaseObjectType (defined in 5.1.1)
HasComponent	Variable	ProcessVariable	Float	AnalogItemType (see Part 8 – Data Access)	Mandatory	R
HasComponent	Variable	HHlimit	Boolean	BaseDataVariableType	Optional	R
HasComponent	Variable	Hlimit	Boolean	BaseDataVariableType	Optional	R
HasComponent	Variable	Llimit	Boolean	BaseDataVariableType	Optional	R
HasComponent	Variable	LLlimit	Boolean	BaseDataVariableType	Optional	R
HasProperty	Variable	HHSetPoint	Float	PropertyType	Optional	RW
HasProperty	Variable	HSetPoint	Float	PropertyType	Optional	RW
HasProperty	Variable	LSetPoint	Float	PropertyType	Optional	RW
HasProperty	Variable	LLSetPoint	Float	PropertyType	Optional	RW

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 Table 16 for an illustration, for actual definition see AnalogItemType in OPC UA Part 8. Both the engineering units and engineering units’ range are required.

Table 16 – AnalogItemType definition

Attribute	Value
BrowseName	AnalogItemType
References	NodeClass	BrowseName	DataType	TypeDefinition	ModellingRule
HasProperty	Variable	InstrumentRange	Range	PropertyType	Optional
HasProperty	Variable	EURange	Range	PropertyType	Mandatory
HasProperty	Variable	EngineeringUnits	EUInformation	PropertyType	Mandatory

The EUInformation DataType is defined in Part 8 – Data Access

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.

Table 17 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.

Table 17 - MDISInstrumentOutObjectType

Attribute	Value
BrowseName	MDISInstrumentOutObjectType
IsAbstract	False
References	Node Class	BrowseName	DataType	TypeDefinition	ModellingRule	RW
Subtype of the MDISInstrumentObjectType
HasComponent	Method	WriteValue	See 5.5.5		Mandatory

WriteValue – This Method allows a Client to change the value of ProcessVariable on an instance of the 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.

Instrument WriteValue Method is used to change the value of the ProcessVariable in the MDISInstrumentOutObjectType. The Instrument WriteValue Method operation applies to the object in the subsea system. 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.

Method Declaration

WriteValue (

[in] Value Float

);

Table 18 – Instrument WriteValue Method parameters

Argument	Description
Value	Float value Variable, that indicates the target state of the Variable

Method result codes are defined as part of the Call Service (see OPC UA Services Part 4 – Services specification). They are described in Table 94 for ease of reference.

Comments

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

Table 19 – Instrument WriteValue Method AddressSpace Definition

Attribute	Value
BrowseName	Value
References	Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
HasProperty	Variable	InputArguments	Argument[]	PropertyType	Mandatory

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.

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.

Figure 14 - MDISChokeObjectType

Table 20 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.

Table 20 - MDISChokeObjectType

Attribute	Value
BrowseName	MDISChokeObjectType
IsAbstract	False
References	Node Class	BrowseName	DataType	TypeDefinition	ModellingRule	RW
Subtype of the MDISBaseObjectType
HasComponent	Variable	CalculatedPosition	Float	BaseDataVariableType	Mandatory	R
HasComponent	Variable	SetCalculatedPositionStatus	SetCalculatedPositionEnum	BaseDataVariableType	Optional	R
HasComponent	Variable	PositionInSteps	Int16	BaseDataVariableType	Optional	R
HasComponent	Variable	Moving	ChokeMoveEnum	BaseDataVariableType	Mandatory	R
HasComponent	Variable	CommandRejected	Boolean	BaseDataVariableType	Optional	R
HasComponent	Method	Move	See 5.6.4		Mandatory
HasComponent	Method	Step	See 5.6.5		Optional
HasComponent	Method	Abort	See 5.6.6		Mandatory
HasComponent	Method	SetCalculatedPosition	See 5.6.7		Mandatory
HasComponent	Variable	NonDefeatableOpenInterlock	Boolean	BaseDataVariableType	Optional	R
HasComponent	Variable	DefeatableOpenInterlock	Boolean	BaseDataVariableType	Optional	R
HasComponent	Variable	NonDefeatableCloseInterlock	Boolean	BaseDataVariableType	Optional	R
HasComponent	Variable	DefeatableCloseInterlock	Boolean	BaseDataVariableType	Optional	R
HasProperty	Variable	StepDurationOpen	Duration	PropertyType	Optional	R
HasProperty	Variable	StepDurationClose	Duration	PropertyType	Optional	R
HasProperty	Variable	TotalSteps	UInt16	PropertyType	Optional	R
HasInterlock	Variable	<InterlockPlaceholder>		InterlockVariableType	OptionalPlaceholder

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. If it is disabled (FALSE) then the choke will not act on any Move command, Step Command or SetCalculatedPosition Command and is not available from a functional point of view. The choke will still report any status information.

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.

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

Method Declaration:

Move(

[in] Position Float,

[in] OverrideInterlocks Boolean,

[in] SEM SEMEnum

);

Table 21 – Choke Move Method Arguments

Argument	Description
Position	A number (in percent) indicating the percent open to be moved to when operated.
OverrideInterlocks	Boolean indicating if the open or close command should override any defeatable interlocks
SEM	The selection of which SEM to send the command to.

Method result codes are defined as part of the Call Service (see OPC UA Services Part 4 – Services specification). They are described in Table 94 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. 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 22 specifies the AddressSpace representation for the ChokeMoveMethod.

Table 22 – Choke Move Method AddressSpace Definition

Attribute	Value
BrowseName	Move
References		Node Class	BrowseName	DataType	TypeDefinition	ModellingRule
HasProperty		Variable	InputArguments	Argument[]	PropertyType	Mandatory

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

Method Signature:

Step(

[in] Direction ChokeCommandEnum,

[in] Steps UInt16,

[in] OverrideInterlocks Boolean,

[in] SEM SEMEnum

);

Table 23 – Choke Step Method Arguments

Argument	Description
Direction	Enumeration to indicate if an open request or close request is being initiated
Steps	The number of steps to either open or close the choke
OverrideInterlocks	Boolean indicating if the open or close command should override any defeatable interlocks
SEM	The selection of which SEM to send the command to.

Method result codes are defined as part of the Call Service (see OPC UA Services Part 4 – Services specification). They are described in Table 94 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 24 specifies the AddressSpace representation for the ChokeStepMethod.

Table 24 – Choke Step Method AddressSpace Definition

Attribute	Value
BrowseName	Step
References		Node Class	BrowseName	DataType	TypeDefinition	ModellingRule
HasProperty		Variable	InputArguments	Argument[]	PropertyType	Mandatory

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

Method Signature

Abort ();

Method result codes are defined as part of the Call Service (see OPC UA Services Part 4 – Services specification). They are described in Table 94 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 25 specifies the AddressSpace representation for the choke Abort Method.

Table 25 – Choke Abort Method AddressSpace Definition

Attribute	Value
BrowseName	Abort
References		Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule

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

Method Signature:

SetCalculatedPosition(

[in] CalculatedPosition Float

);

Table 26 – Choke SetCalculatedPosition Method Arguments

Argument	Description
CalculatedPosition	A number (in percent)

Method result codes are defined as part of the Call Service (see OPC UA Services Part 4 – Services specification). They are described in Table 94 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 SetCalculatedPostionStatus to determine if an error occurred or the command completed. The SetCalculatedPositionStatus will reset on the next successful SetCalculatedPostion Method invocation.

Table 27 specifies the AddressSpace representation for the SetCalculatedPosition Method.

Table 27 – Choke SetCalculatedPosition Method AddressSpace Definition

Attribute	Value
BrowseName	SetCalculatedPosition
References		Node Class	BrowseName	DataType	TypeDefinition	ModellingRule
HasProperty		Variable	InputArguments	Argument[]	PropertyType	Mandatory

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.

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 15 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 Interlockvariables associated with it, or that they might not have an actual interlock associated.

Figure 15 - Valve Object Overview

Table 28 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.

Table 28 - MDISValveObjectType

Attribute	Value
BrowseName	MDISValveObjectType
IsAbstract	False
References	Node Class	BrowseName	DataType	TypeDefinition	ModellingRule	RW
Subtype of the MDISBaseObjectType
HasComponent	Variable	Position	ValvePositionEnum	BaseDataVariableType	Mandatory	R
HasComponent	Variable	CommandRejected	Boolean	BaseDataVariableType	Optional	R
HasComponent	Variable	SignatureRequestStatus	SignatureStatusEnum	BaseDataVariableType	Optional	R
HasComponent	Variable	LastCommand	CommandEnum	BaseDataVariableType	Optional	R
HasComponent	Variable	NonDefeatableOpenInterlock	Boolean	BaseDataVariableType	Optional	R
HasComponent	Variable	DefeatableOpenInterlock	Boolean	BaseDataVariableType	Optional	R
HasComponent	Variable	NonDefeatableCloseInterlock	Boolean	BaseDataVariableType	Optional	R
HasComponent	Variable	DefeatableCloseInterlock	Boolean	BaseDataVariableType	Optional	R
HasComponent	Method	Move	See 5.7.4		Mandatory
HasInterlock	Variable	<InterlockPlaceholder>		InterlockVariableType	OptionalPlaceholder	R
HasProperty	Variable	OpenTimeDuration	Duration	PropertyType	Optional	R
HasProperty	Variable	CloseTimeDuration	Duration	PropertyType	Optional	R
HasSignature	Object	<ValveSignature>		FileType	Optional

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 7.1.4 for a description of the possible enumerations).
• LastCommand – The enumeration reflects the last command sent to the equipment by the SPCS (see 7.1.5 for a description of the possible enumerations).
• Enabled – This Boolean reflects if the valve is available for control. If it is disabled (FALSE) than the valve will not act on any Move command and is not available from a functional point of view. The valve will still report any status information (CommandRejected). One of the cases for a disabled valve is when the valve is placed out of service.
• Position – This enumeration provides information about the current position of the valve (see section 7.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 5.7.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 16 provides an example of how this interlock Variable is used and could be deployed.

Figure 16 - Interlock example

Note: in OPC UA it is allowed to have a Node which is the target of multiple 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 ValveObjectType. The name shall include a timestamp. The FileType ObjectType (defined in Part 5 – Information Model) includes two properties (illustrated below), for all MDIS instances both of these properties shall have the value False. For additional detail see 5.10.3.

HasProperty	Variable	Writable	Boolean	PropertyType	Mandatory
HasProperty	Variable	UserWritable	Boolean	PropertyType	Mandatory

Vendor specific subtypes of this object type are allowed. They may add additional vendor specific information or may change some Optional items to Mandatory.

Move Method is used to open or close a valve.

Method Declaration:

Move(

[in] Direction CommandEnum,

[in] OverrideInterlocks Boolean,

[in] SEM SEMEnum,

[in] Signature Boolean,

[in] ShutdownRequest Boolean

);

Table 29 - Move Arguments

Argument	Description
Direction	The enumeration indicates whether the command is to open the valve or to close the valve
OverrideInterlocks	Boolean indicating if the open or close command should override any defeatable interlocks
SEM	The enumeration indicates which SEM to send the command to.
Signature	Boolean indicating if a profile /signature should be generated by this move command request. If the optional Variable SignatureRequestStatus is not provided on the Object, this parameter is ignored by the Server.
ShutdownRequest	Boolean indicates that this command is part of a shutdown sequence.

Method result codes are defined as part of the Call Service (see OPC UA Services Part 4 – Services specification). They are described in Table 94 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 30 specifies the AddressSpace representation for the Move Method.

Table 30 - Move Method AddressSpace Definition

Attribute	Value
BrowseName	Move
References	Node Class	BrowseName	DataType	TypeDefinition	ModellingRule
HasProperty	Variable	InputArguments	Argument[]	PropertyType	Mandatory

The following tables detail the generic properties for the MDISAggregateObjectType; implementation shall ensure adherence to Mandatory [M] aspects to comply with the MDIS interface standardisation. Optional [O] may or may not be implemented within a project. Figure 17 provides an overview of the MDISAggregateObjectType as defined by MDIS. This Object is intended to be the base object for all aggregate ObjectTypes. See section 9.5 for additional details on data aggregation.

Figure 17 – MDISAggregateObjectType

Table 31 defines the structure of an MDISAggregateObjectType. The MDISAggregateObjectType is a subtype of MDISBaseObjectType and requires that all subtypes include, as a minimum, the Fault information. All other components are Optional and only components that are required by the aggregate are needed.

Table 31 – MDISAggregateObjectType

Attribute	Value
BrowseName	MDISAggregateObjectType
IsAbstract	True
References	Node Class	BrowseName	Data Type	TypeDefinition	ModellingRule	RW
Subtype of the MDISBaseObjectType defined in section 5.1.1
HasComponent	Object	<InstrumentPlaceholder>		MDISInstrumentObjectType	Optional Placeholder
HasComponent	Object	<InstrumentOutPlaceholder>		MDISInstrumentOutObjectType	Optional Placeholder
HasComponent	Object	<DigitalInstrumentPlaceholder>		MDISDigitalInstrumentObjectType	Optional Placeholder
HasComponent	Object	<DiscreteInstrumentPlaceholder>		MDISDiscreteInstrumentObjectType	Optional Placeholder
HasComponent	Object	<DigitalOutPlaceholder>		MDISDigitalOutObjectType	Optional Placeholder
HasComponent	Object	<DiscreteOutPlaceholder>		MDISDiscreteOutObjectType	Optional Placeholder
HasComponent	Object	<ValvePlaceholder>		MDISValveObjectType	Optional Placeholder
HasComponent	Object	<ChokePlaceholder>		MDISChokeObjectType	Optional Placeholder
HasComponent	Variable	<InterlockPlaceholder>		InterlockVariableType	Optional Placeholder

The MDISAggregateObjectType is an abstract ObjectType; instances of this ObjectType cannot be created. Object instances can only be created of subtypes of this ObjectType. In OPC UA it is legal to add additional Object or Variable Reference(s) to an instance of an Object, (i.e. add Variable or Object to an instance that are not defined in the type), but in MDIS we are restricting this in that a Client is not required to process or handle any Objects or Variables that are not part of a type.

The subtypes of MDISAggregateObjectType are allowed to include other subtypes of MDISAggregateObjectType. For example, a Well that is defined as a subtype of MDISAggregateObjectType might include an MPFMAggregateObjectType which is also a subtype of MDISAggregateObjectType.

<InstrumentPlaceholder> denotes that a subtype of this ObjectType may define any number of Objects of this type as part of a subtype. Each object instance shall have a unique BrowseName and must be of MDISInstrumentObjectType.

<InstrumentOutPlaceholder> denotes that a subtype of this ObjectType may define any number of Objects of this type as part of a subtype. Each object instance shall have a unique BrowseName and must be of MDISInstrumentOutObjectType.

<DigitalInstrumentPlaceholder> denotes that a subtype of this ObjectType may define any number of Objects of this type as part of a subtype. Each object instance shall have a unique BrowseName and must be of MDISDigitalInstrumentObjectType.

<DiscreteInstrumentPlaceholder> denotes that a subtype of this ObjectType may define any number of Objects of this type as part of a subtype. Each object instance shall have a unique BrowseName and must be of MDISDiscreteInstrumentObjectType.

<DigitalOutPlaceholder> denotes that a subtype of this ObjectType may define any number of Objects of this type as part of a subtype. Each object instance shall have a unique BrowseName and must be of MDISDigitalOutObjectType.

<DiscreteOutPlaceholder> denotes that a subtype of this ObjectType may define any number of Objects of this type as part of a sub type. Each object instance shall have a unique BrowseName and must be of MDISDiscreteOutObjectType.

<ValvePlaceholder> denotes that a subtype of this ObjectType may define any number of Objects of this type as part of a subtype. Each object instance shall have a unique BrowseName and must be of MDISValveObjectType .

<ChokePlaceholder> denotes that a subtype of this ObjectType may define any number of Objects of this type as part of a subtype. Each object instance shall have a unique BrowseName and must be of MDISChokeObjectType.

<InterlockPlaceholder> denotes that a subtype of this VariableType may define any number of Variables of this type as part of a subtype. Each Variable instance shall have a unique BrowseName and must be of InterlockVariableType.

In some systems, a MDIS Server might be on an isolated network, one in which there is no NTP or other source of time synchronization signals. In these systems, the MDIS Server would need to be able to obtain a minimum time synchronization signal from the Client. This ObjectType and associated method is designed to allow this minimum time synchronization. It should only be used if a better time synchronization system, such as NTP, is not available. The accuracy of this type of time synchronization could be in the range of seconds.

If this Object is supported, a single instance of this Object shall exist on a Server. The Object shall have a name TimeSynchronization and the instance shall exist as part of the MDISInformationObject.

The following section details the MDISTimeSyncObjectType. This optional type allows a Client to provide time synchronization information to a Server. The Client can call the SetTime Method periodically to ensure the Server time does not drift. This Method does not return until the time on the Server has been updated or an error is returned.

Figure 18 - MDISTimeSyncObjectType

Table 32 defines the structure of an MDISTimeSyncObjectType.

The current time on the Server is available as part of the ServerStatus provided by all OPC UA Servers.

Table 32 - MDISTimeSyncObjectType

Attribute	Value
BrowseName	MDISTimeSyncObjectType
IsAbstract	False
References	Node Class	BrowseName	DataType	TypeDefinition	ModellingRule	RW
Subtype of the BaseObjectType
HasComponent	Method	SetTime	SetTime Method is defined in 5.9.4		Mandatory

SetTime – This method allows a Client to set time on the Server.

SetTime Method (defined in Table 33) is used to set the time on the Server. If an error occurs this Method shall return an error code indicating the failure to set the time (see Table 35).

Method Declaration

SetTime (

[in] TargetTime UtcTime

);

Table 33 - SetTime Method parameters

Argument	Description
TargetTime	The UTC Time that the Server shall use to update its internal clock.

Method result codes are defined as part of the Call Service (see OPC UA Services Part 4 – Services specification). They are described in Table 94 for ease of reference.

Comments

The SetTime Method will change the time on the Server. Table 10 specifies the AddressSpace representation for the SetTime Method.

Table 34 - SetTime Method AddressSpace Definition

Attribute	Value
BrowseName	SetTime
References		Node Class	BrowseName	DataType	TypeDefinition	Modelling Rule
HasProperty		Variable	InputArguments	Argument[]	PropertyType	Mandatory

Table 35 – SetTime Result Codes

Symbolic Id	Description
Bad_InvalidTimestamp	The timestamp is outside the range allowed by the Server or an error occurred setting the Server time.
	.

MDIS defines flags, general status information and other optional data collections that need to exist in a standard manner on MDIS Servers to allow for easier interoperation between Clients and Servers. This information is provided via the MDISInformationObjectType.

The following section details the MDISInformationObjectType. This ObjectType defines a standard structure for organization of some basic Server information. An instance of this object is required for all versions of MDIS Servers 1.2 and greater. An instance of this ObjectType shall exist under the Objects folder on all OPC UA MDIS Servers. Clients are required to be able to handle Servers which do not contain this object. The Client shall assume any Server that does not contain an instance of this ObjectType is a version 1.1 or 1.0 MDIS Server.

Figure 19 - MDISInformationObjectType

Table 7 defines the structure of an MDISInformationObjectType.

Table 36 – MDISInformationObjectType

Attribute	Value
BrowseName	MDISInformationObjectType
IsAbstract	False
References	Node Class	BrowseName	DataType	TypeDefinition	ModellingRule	RW
Subtype of the BaseObjectType (see Part 5 – Information Model)
HasComponent	Object	TimeSynchronization		MDISTimeSyncObjectType	Optional
HasComponent	Object	Signatures		FolderType	Optional
HasComponent	Variable	MDISVersion	MDISVersionDataType	MDISVersionVariableType	Mandatory	R

TimeSynchronization – this is an instance of the MDISTimeSynchronizationType object, that allows a Client to provide time information to a Server if required. See 5.1.11 for additional details.

Signatures is a folder that contains all of the currently available signatures (profiles). The individual signature(s) are stored as FileObjects and the format of the file(s) is vendor specific.

MDISVersion provides information about the version of the MDIS specification that is implemented by the Server. This is provided to assist the Client in determining what should be available and can also be used for automated testing of the Server.