The MDIS Companion standard will be released in December and has completed a full function Interoperability test (IOP) which included a demonstration to Operating companies of the MDIS standard. The MCS-DCS Interface Standardization (MDIS) network was formed with involvement from key industry subsea equipment vendors, topsides DCS vendors and oil and gas operating companies. Its goal is to standardize the interface between subsea systems and the platform DCS system. This includes both the communication (OPC UA) and the information model that is transferred.
MDIS was established to replace multiple interfaces with one common interface to greatly reduce incompatibility and provide the following benefits
- Reduce project lead and delivery times
- Improve reliability
- Eliminate one-time engineering
- Reduce testing
These benefits are designed to address major sources of problems in projects affecting offshore projects such as:
- Transmission of unique interface documentation for every project
- Data entry of the interface information into systems
- Multiple protocols often unique to a given vendor or legacy with technical limits.
- Interface polling based causing bandwidth issues
- Complex integration testing with multiple problems only being discovered at integration testing
Interface issues frequently delay projects, increase costs and lead too unhelpful ‘finger pointing’.
The MDIS Companion specification defines a set of standard objects that includes instruments, instrument outs, digital instruments, digital instrument outs, discrete instruments, discrete instrument outs, chokes and valves. The specification includes behavior and interaction for these objects including support for interlocks associated with the objects. The specification defines rules for extending the model in a uniform manner. This standard object model allows for the development of a generic Client interface that will work with any server with no programmatic changes, only updated configuration, even if custom object types exist. The specification also defines rules for extending the model, where the rules are geared toward allowing a client to use the extended types without the requirement of updating the interface, only configuration of the extended type.
The object models were developed for two architectures:
- Interfaced – system in which the subsea vendor provides control
- Integrated – where subsea vendor provides a gateway to the subsea system
Although two architectures are defined, systems can easily be built that provide a hybrid of the two architectures.
OPC UA supports a standard format for extracting the configuration of a server as an XML file (nodeset file format defined in OPC UA Part 5). The nodeset file allows a client to obtain and process the server configuration long before any integrated testing would be performed. A client vendor can auto-generate configurations based on the exported server configuration. This removes any data entry, greatly improving configuration reliability, reducing configuration effort and reducing testing. This will result in shortening of project lead and delivery times.
The specification also includes time synchronization requirements and a discussion on redundancy. The redundancy discussion describes a couple of typical manners in which MDIS server and clients could provide redundancy. It is expected that all MDIS solutions will be redundant. The redundancy section also includes a discussion on data arbitration which is commonly required in an MDIS system. Data arbitration is the resolution of multiple redundant sensors into a single sensor for the DCS.
To meet the objectives of reducing the costs associated with testing, the MDIS specification defines a complete set of OPC UA profiles and conformance units. The profiles are separated into the two main architectures defined by MDIS. This breakdown of functionality allows for easy generation of Compliance tests, which in turn will allow certification of both the MDIS server and client. This certification will be performed by one of the OPC Foundation independent certification labs. The product certification will ensure that the server or client will function as specified, allowing reuse of the interface on multiple projects with no changes. Interface testing will be greatly reduced on each project.
The MDIS network completed a second IOP at our September meeting, which included a demonstration session for operators to come and observe the functionality provided by all of the vendors. The IOP was very well attended.
The following vendors attended the IOP:
- CSE W-Industries
The test included 6 servers (subsea vendors) and 7 clients (DCS vendors). The provided solutions were largely hardware solutions although there was one software solution and an additional sample server. The Hardware was not actual released products in most cases, but in many cases it was near release and just awaiting final release of the MDIS Companion specification.
Each vendor tested general communications, information model testing, failover of redundant systems, model extensions including custom object types and shutdown sequences. The information model required for the test include four complete wells, where each well was composed of a number of instruments, valves, a choke and several custom equipment items such as Chemical Injection Meter Valve (CIMV) or MPFM (multi-port flow meter). The test configuration also included a SEM to further ensure that custom objects and the redundancy aspects of a system were met. The custom instruments or objects were aggregated out of the MDIS defined instruments, which allowed clients to easily configure the custom objects without programming.
As part of the IOP, MDIS client vendors (DCS systems) provided graphics and standard visualization tools. MDIS clients were required to have the ability to switch configuration between the different servers quickly. To support this requirement, a number of DCS clients generated tools that allow the generation of configurations automatically (or semi-automatically) from the exported MDIS server configuration (Nodeset Files). Client configuration tools consume these nodeset files and use them to generate the interface configuration. In some cases, even the complete DCS configuration including initial graphics were generated. These tools, once verified, ensure reliable consistent configuration greatly reducing engineering effort and testing.
Towards the end of the IOP Operators were invited to witness the testing, ask questions and generally discuss the vendors experience with the standard interface. Many operating companies attended and spent considerable time talking to their favorite vendors and observing both configuration changes as well as the functionality of the interfaces. The level of interest and questions from the operator was very impressive.
In general, all vendors were very successful in testing the interoperability of their clients and servers including complex typical project related activities. The operators were impressed with the configuration improvements and very supportive of the interface. Several operators indicated that they would require the interface on upcoming projects.