communications - drilling systems automation roadmap

Communications The Drilling Systems Automation Roadmap Communications section provides guidance to the future technologies and processes used to communicate information in all forms across all aspects of drilling systems automation.

Contents Functional Description .................................................................................................................................. 4

Performance targets (including KPI’s with dates) ......................................................................................... 4

Current and future situation of systems that use communications ............................................................. 5

Downhole Transmission Tools .................................................................................................................. 5

Current situation: .................................................................................................................................. 5

Challenges: ............................................................................................................................................ 5

Future State: ......................................................................................................................................... 5

Downhole to surface (vice Versa telemetry) review ............................................................................ 6

Surface acquisition systems ...................................................................................................................... 8


Challenges: ............................................................................................................................................ 8

Future State: ......................................................................................................................................... 8

Sub Sea Control Systems ........................................................................................................................... 8

Aggregators and Historians ....................................................................................................................... 9


Challenges: ............................................................................................................................................ 9

Future State: ......................................................................................................................................... 9

Remote Advisory Centers ....................................................................................................................... 10

Current situation: ................................................................................................................................ 10

Challenges: .......................................................................................................................................... 10

Future State: ....................................................................................................................................... 10

Scope of Communications .......................................................................................................................... 10

Rig v’s Office ............................................................................................................................................ 10

Device to Device ...................................................................................................................................... 10

Device to Process and Process to Device ................................................................................................ 11

Communications

Confidential Information Copyright © DSARoadmap.org 2017

Process to Process................................................................................................................................... 11

Interoperability ....................................................................................................................................... 11

Contextual / Situation Awareness .......................................................................................................... 11

Communication Protocols ........................................................................................................................... 11

Protocols (TCP vs UDP)............................................................................................................................ 11

WITS ........................................................................................................................................................ 12

WITSML ................................................................................................................................................... 12

Energistics Transfer Protocol (ETP) ......................................................................................................... 12

SYSML ...................................................................................................................................................... 13

OPC classic vs UA .................................................................................................................................... 13

OPC and Drilling Automation ...................................................................................................................... 13

History ..................................................................................................................................................... 13

OPC UA .................................................................................................................................................... 13

Implementation ...................................................................................................................................... 14

OPC UA and Drilling Automation ............................................................................................................ 14

Agents of Change ........................................................................................................................................ 15

Internet of Things .................................................................................................................................... 15

In Stream capabilities .............................................................................................................................. 15

Behavioral and pattern based Cyber Security ........................................................................................ 16

Problem Statement (barriers, needs, critical success factors).................................................................... 16

Barriers .................................................................................................................................................... 16

Proprietary Attitude ............................................................................................................................ 16

Lack of a common standard ................................................................................................................ 17

Lack of Open Interfaces ...................................................................................................................... 17

Way Ahead .................................................................................................................................................. 17

Standardized downhole and rig to office telemetry ............................................................................... 17

Downhole Telemetry .............................................................................................................................. 18

Timeline: (Ongoing but expect significant change in the next 5 years) .............................................. 19

State Based Information ......................................................................................................................... 19

Timeline: Imminent ............................................................................................................................ 19

Operational Intent .................................................................................................................................. 19

Timeline: Long term (5+ years) .......................................................................................................... 20

Communications


Rig Information Model ............................................................................................................................ 20

Timeline: Ongoing (~ 2-5 years) .......................................................................................................... 20

Data Federation ...................................................................................................................................... 20

Timeline: imminent through the next 2 – 5 years .............................................................................. 22

Multiplexed Communications ................................................................................................................. 22

Timeline: Imminent but developing over the next 5 years ................................................................. 23

Self-Aware devices - IOT ......................................................................................................................... 23

Timeline: Imminent but developing over the next 5 years ................................................................. 23

Future Data Values & Data Enriched to become information ................................................................ 24

Timeline: Imminent but developing over the next 2-3 years ............................................................. 24

Cyber Information ................................................................................................................................... 24

Timeline: Immediate but remains an ongoing development ............................................................. 25

Team Reference Information Section ......................................................................................................... 27

Communications mediums ..................................................................................................................... 27

Physical Systems ..................................................................................................................................... 27

Acoustical Methods ................................................................................................................................ 27

Electromagnetic Methods ....................................................................................................................... 27

Laser Comms ........................................................................................................................................... 27

Wired vs Wireless ................................................................................................................................... 27

Alternatives to wired pipe ...................................................................................................................... 28

Alternatives to BOP umbilical’s ............................................................................................................... 28

Communications Protocols ..................................................................................................................... 28

Sensor based ........................................................................................................................................... 28

BUS systems ........................................................................................................................................ 28

Latency and Bandwidth....................................................................................................................... 29

System Based .......................................................................................................................................... 31

Interoperability ....................................................................................................................................... 31

Latency and Bandwidth .......................................................................................................................... 31

Team discussion on The Internet of Things ............................................................................................ 31

Communications


Functional Description Communication (Source Wikipedia - from Latin commūnicāre, meaning "to share") is the act of conveying intended meanings from one entity or group to another through the use of mutually understood signs and semiotic rules. The basic steps of communication are the forming of communicative intent, message composition, message encoding, transmission of signal using a specific channel or medium, reception of signal, message decoding and finally interpretation of the message by the recipient. Communication in DSA is a major element that requires standards and cooperation to enable effectiveness. In this roadmap, communication is a key driver of interoperability through the collection of physical mediums and protocol standards that enable disparate solutions within the drilling automation ecosystems to interoperate and interconnect towards a given common objective. The advancement of DSA will require standards to be implemented in the communications processes and as well as agreed protocols. Systems from different companies must be able to interact between each other using a common language. WITSML was created to provide this ability for information exchange. Industries in general are adopting OPC UA as their communication means for automation and control as it is an advanced high speed system that accommodates meta data and cyber security. Recently, workgroups have been established that are interlinking WITSML and OPC UA to enable these systems to work coherently and seamlessly. Some DSA proponents have adopted another communication means Data Distribution Service (DDS). DDS is a data centric middleware layer where all data is stored along with its context, thus creating a richer information store between data acquisition and data user applications. OPC UA is also now developing the interconnectivity to DDS opening this system for further integration. Interoperability across the full spectrum of companies, systems, machines, equipment in drilling systems automation is a key to accelerating delivery of automation. Failure to create interoperability will result in only proprietary drilling systems being able to adopt significant levels of automation. Communication is a key enabler of interoperability.

Performance targets The performance targets for communication include:

- The level of interoperability with the goal to create fully interoperable systems soonest. - The latency in data, information, and advisory applications which currently exists being aligned

with the required latency for functional control through on site and remote data analysis. Streaming analysis engines are now being deployed onto assets in other industries.

- The ability of drillstring telemetry to deliver high frequency data routinely as a commodity system in most drilling operations. This KPI can translate to a commodity high frequency system or remain at current levels (commodity low frequency mud pulse / specialist high frequency hard wire pipe) with each outcome driving a different methodology for automation adoption.

Communications


Current and future situation of systems that use communications This section of the document details the individual systems within a drilling automation hierarchy that are dependent on or enriched by communications.

Downhole Transmission Tools Mud Pulse Telemetry remains the predominant solution for communication between downhole tools and surface decoding applications. Due to the bandwidth restrictions, inherent with this form of communication, all downhole tool vendors have developed proprietary solutions which provide competitive differentiation in the fidelity and volume of data that these often-complex tools can transmit in real-time while drilling. Remote directional drilling capabilities have already lead to some of the more basic forms of telemetry being encapsulated for use by 3rd party acquisition systems, but this has yet to become the norm in the more advanced forms of telemetry. With the introduction of new mediums for downhole tools communications such as wired pipe, the differentiation around telemetry systems may well disappear, leading to adoption of a standardized industry solution.

Current situation: Multiple downhole tool vendors provide a variety of downhole tools that can operate simultaneously in a bottom hole assembly. The industry is Reliant on ageing Mud Pulse Telemetry which has limited bandwidth and high latency. Proprietary software for telemetry is embedded in tool firmware. No standard for downhole real-time telemetry transmission to enable open communications. Accoustic telemetry is emerging as an effective technology for situations without mud circulation especially completions where attenuation from borehole contact is minimalized. Hard wired drill pipe has become commercial as a high data rate low latency application for downhole telemetry however it is cost prohibitive for many operations.

Challenges: Wired Pipe is proprietary technology and expensive however the vendor has opened their business model to a variety of sales options including purchasing by drilling contractors. There is a lack of business incentives to create alternative high speed telemetry system.

Future State: Hi fidelity high bandwidth open technology solution is developed as a data highway from subsurface to surface. Vendors no longer differentiating on telemetry capabilities allowing full pass from source to user. The expectation of this change is that the industry becomes willing to cooperate on standards and communication while competing on innovation at the implementation level. An alternative hard wire system emerges that matches the current system in data rate and adds power down capabilities.

Communications


Downhole to surface (vice Versa telemetry) review The argument is that a digital backbone from downhole to surface (and vice versa) is needed for systems automation. The requirements are that the digital backbone be reliable, bi-directional and of known latency, but not necessarily of high bandwidth. A lot can be achieved with modern compression techniques, and real-time compression factors in excess of 3x or more are common.

There are several competing MWD telemetry technologies available and in development. In no particular order: EM, mud pulse, acoustic, wired systems, fiber optic. Each of these has its own attributes currently and each has a varying likelihood for their use in systems automation.

Electromagnetic (EM): basically, the bi-directional transmission of a modulated signal through the earth. Very low frequency, current maximum raw data rate in the order of 10 bps. Pros are no moving parts, quite simple downhole construction, easily modulated signal. Cons are power requirements in saline muds, blocking of natural isolators (such as halites, anhydrite) – so a geological specificity, effect of drilling noise especially at depth, and depth limitation (about 15,000 feet in areas conducive to EM telemetry). Downlinking requires some power, so good electronics required to avoid barbequing domestic animals. In summary, a good telemetry method but limited in data rate and applicable in niche areas. Can be extended in depth and data rate with long-wire systems, repeaters, wired casing or close existing wellbores. Since transmission is not limited to the current wellbore, systems can interfere, even with several miles’ separation. While good for MWD work, not a likely contender for automation.

Mud Pulse: the mainstay of the MWD industry, transmission of information encoded in a modulated series of pressure pulses in the mud stream. Most common is signal transmission along the bore of the pipe, but signal transmission is also possible in the annulus. System is single hop (no repeaters needed) with maximum raw data rates of about 40 bps in the field, higher rates (up to about 80 bps) have been demonstrated in the lab. System includes electro-mechanical downhole pulsers, and receivers on surface are often one or more (an array) of pressure transducers. Highly sophisticated pulsers are able to generate well controlled pressure pulses, and very high levels of signal processing are applied on surface to receive the signal. Reach of these systems is considerable, and all extended reach wells have successfully used mud pulse telemetry. Cons: downlinking is quite slow and is by flow bypass, pump control, or rotary sequences; mud properties can affect data rate; drilling noise can “pollute” transmission bandwidth. The most important deficiencies are the variable latency which depends on mud properties, and the very slow and intrusive downlinking methods involved. The issue for automation is the signal transmission time (latency), which creates a problem if there are any delays. Mud pulses travel with about 1200 m/sec through mud, which creates a delay that is very bad for automation. Models are then required, which can be calibrated from time to time with downhole data. Automated systems may be adapted to use this technology (for example, RSS systems), but it is not a likely long-term contender for surface-downhole control systems.

Combination Mudpulse / EM: the EM in this combination system has an enhanced range through an improved ability of the downhole tool to inject current into the formation, a seventy percent improvement in surface signal strength has been observed. This telemetry combination was developed

Communications


to address reliability of data signals. The system monitors signal strength and adjust the primary data channels from one to the other system.

Acoustic: otherwise known as stress-wave telemetry. In this means of telemetry, a modulated signal is acoustically generated in the steel of the pipe. There have been many attempts at this mode of transmission with a few commercial variants in existence. Basically, an electromechanical transmitter is used to generate an axial or torsional signal downhole, and accelerometers are used, attached to the drillstring on surface, to receive the signal. Due to the jointed nature of the drillstring, its acoustic response is rather like a comb-filter and consist of a sequence of pass and stop bands (the same is also true of the mud pulse channel due to the repetitive structure of internal upsets). Transmission occurs within a passband, although some techniques take advantage of the low noise propagation characteristics of the stop band. Data rate is claimed to be about 50 to 80 bps, although higher rate systems have been demonstrated (180 bps). The cons to this system are attenuation along the string, in particular non-stationary attenuation due to contact between the pipe and borehole wall. Due to this fact, and others, bi-directional acoustic telemetry is a challenge. Travel speed is fast (in excess of 16,000 fps) so latency is considerably less of a problem compared to mud pulse. However, attenuation limits the applicability of this technique to relatively short distances unless a multi-repeater system is used, and borehole contact probably limits applicability in modern boreholes. Application is limited to niche areas, perhaps more in production rather than drilling. Not a likely choice for a reliable automation system.

Wired Systems: there are actually many wired systems in existence, but perhaps we can split them into two camps - continuous wire and segmented wire. E-line systems are an example of a continuous wire system that has been employed for years in coiled tubing operations, and have shown their worth in delivering data for operational control. While data rates are quite low (I believe around 300 bps), there is no reason why these rates cannot be made considerably faster. The Anaconda composite pipe system was an example of a continuous wire system that failed to transition to the commercial market. I believe the main market for systems automation will be segmented pipe since this allows rotation of the drillstring to handle high axial drag and cuttings loads, the drilling of extremely complex wellbores, and the use of existing infrastructure. Applications developed for segmented pipe can easily transfer to continuous systems. At the moment there is only one commercial wired pipe system - the IntelliServ wired pipe. It allows high bandwidth, low latency, bi-directional data transfer between downhole and surface. It also opens access to distributed sensor locations along the string. There is a believe that a wired pipe system is needed for full implementation of systems automation. The patent on hard wire pipe expires circa 2020 potentially opening the market to compeition.

There are other telemetry systems in the wings, some being continuous wire that can be run with segmented pipe (as via a spooler), and continuous or segmented fiber optic systems. One fiber optic (monofilament) system was developed by Sandia and shown to operate in a well at Catoosa. Again, all these systems have failed to make the step from engineering prototype to commercial system, largely because of economics. Given a different commercial environment – the need for closed loop control, real-time imaging, fewer processors downhole, and systems automation -- the drive to market might be quite different. However, what is required is a reliable low latency, bi-directional communication

Communications


system for systems automation and that is most likely to be delivered to a wide market on a wired system for segmented pipe.

Surface acquisition systems As with downhole tool communications, rig data acquisition systems today are mainly proprietary systems which do not allow easy inter-connectivity to other systems. There are some data exchange technologies in place but they may rely on specific configurations of serial interfaces or some flavor of Fieldbus system. It may be possible to interconnect and read sensor values but often there is no associated metadata that gives additional information about the measurement type and its units of measurement. For example, how does a particular sensor measurement communicate that it contains data that is a hook load measurement in metric tonnes? For the future, the advent of low-cost, small, powerful processors along with emerging standards for interoperability and data exchange, coupled with domain standards for the drilling automation use cases can enable an environment where systems can inter-connect to extract the quantity and quality of information required to drive drilling automation applications.

Current situation: Multiple different surface acquisition and sensor systems are present at the well site No agreed standard for communications technology between the systems Insufficient metadata associated with sensor measurements (type, units, quality) No agreed data model and naming conventions for data description and exchange

Challenges: Broad agreement on the various communications standards Define industry domain data model and naming conventions Security between networked system components

Future State: Systems are discoverable and self-describing "Plug and Play" interconnectivity between systems Ability to connect to any rig data acquisition system (with appropriate security credentials)

Sub Sea Control Systems Today’s subsea communications consists of wire, optical fiber and acoustic technology. The Deepwater Horizon incident exposed many weaknesses in these forms of communication from the control systems on the rig floor to the BOP on the ocean floor and the ability to affect change should a catastrophic event occur. New forms of communication to include LED (Light Emitting Diodes) and Optical Laser forms currently used by the United States Navy for many years are now becoming available to our industry. Undersea Free Space Optical (UFSO) Communications: wireless, high speed data transfer between fixed and/or mobile platforms, nodes and sensors are enabling applications not possible with

Communications


any other technology. Recent breakthroughs in UFSO communication architecture and technology are enabling a wide range of affordable undersea communication applications.

Aggregators and Historians An aggregator is defined as a “snapshot” of the state of all operations in a drilling operation provided on a continuous basis. Wikipedia’s definition for data aggregation is “the compiling of information from databases with intent to prepare combined datasets for data processing”. The aggregator provides a single copy of all information that all agents and displays will use. It is the critical data hub for automation, a black box recorder for the rig. As OPC UA has the facility for methods and device control, the aggregator can morph into the communications box and become an all-in-one solution. Then the communications box becomes the control center for the drilling operation incorporating all the data input and displays with all the human controllers (driller, directional driller, mud engineer, LWD operator, …) in the same room using and sharing the same real time data. As automation increases the level of human control in the control center will be reduced, similarly many of the supervisory control functions will be removed to the remote-control center when an expert operator can supervise control of multiple drilling operations. A historian is the act of taking the snapshot cache and storing it. Historians have all kinds of limits and scopes to determine when values are moved to storage based on their characteristics (frequency, noise level, variability, etc.) – although mostly based on the limitations of the underlying computer system (speed, bandwidth). The historian is required to track the changes in state. The historian is best combined with the aggregator and becomes part of the control center with real time back up to the remote operations center form where it is available to be used by anyone in the center of excellence and in the enterprise level of the organization. This historian data provides the real information for analysis / improvement studies as well as required capture of well data.

Current situation: Limited data aggregation on the rig site – mainly independent data acquisition systems that share some data using WITSML There is a missed opportunity to aggregate for improved displays and performance.

Challenges: The data needs to have context and be available in a readily shared nonproprietary format – OPC-UA The various data owners must decide to share the data for the benefit of the overall operation which probably requires leadership from the operators.

Future State: Data is aggregated in a control room for automation application and human interface displays where all key personnel actively engage in this one location.

Communications


All the data is logged into a historian and communicated to the remote control center and thence to the center of excellence for analysis, data mining, etc.

Remote Advisory Centers Remote operations have established themselves as a norm in the drilling industry. Although the technology is no longer new there remain issues with the direct value they provide to the drilling operation and, in particular, to automated drilling systems. Solutions can be generally categorized into two main fields. Firstly, there are centralized surveillance solutions, which has a tendency to be a passive surveillance solution with little input directly to the drilling operation in real-time. Secondly there are point to point solutions which meet a very specific goal such as remote control of sliding operations.

Current situation: Centralized or point to point solutions Passive surveillance or very specific workflows

Challenges: The remote data lacks the context that is available at the rig site There remains a lack of trust in remote advisory systems by those on the rig site

Future State: Integrated bidirectional human and machine communications Contextually enriched real-time communications

Scope of Communications The Scope of communications has been broken down into 6 key paths.. The key paths are:

Rig v’s Office Future communications solutions need to be appropriate and scalable within both the office based and rig based environments. The needs for these two areas differ in both latency of information transfer and in terms of underlying functionality. Currently the Rig is more focused on the tactical responses whereas the office infrastructure is essentially more strategic and analytical in nature. These disparate needs do overlap, and how future communications infrastructure, whether it is soft computing or machinery control, needs to interact in a seamlessly integrated operational environment. For example, an automated drilling process needed to run processor intensive task such as geomechanical models or needs to reference data sets that are too large to be housed at the rig site. Rig to office communication needs to allow the systems at the rig to be augmented or even superseded by systems running in remote locations by multiple vendors

Device to Device Within the rig environment there are multiple devices which will need to share integrated communications in order to achieve automation. Many of these devices may be installed, maintained

Communications


and operated by different parties during the drilling process. An example of this would be a MWD tool that communicated tool face and survey information directly to a “smart” top drive that would be automatically hold tool face or build a curve.

Device to Process and Process to Device Within an automated solution there will need to be some method applying artificial or human process control and decision making. Communication needs of an automated drilling system that enable devices to be picked off the shelf and plug in seamlessly with the process systems in place on the rig such that measurements, advice and control sequences can pass back and forth without the need for excessive integration. For example, a control process using two way communication with the pumps, draw works and other devices to maintaining wellbore stability according to defined processes.

Process to Process In certain scenarios, multiple vendors will need to communicate across processes such that the automation system is able to make decisions based on multiple contexts. This will require the ability for process solutions to communicate across multiplex of ongoing decision making processes. For example, an anti-collision directional drilling process communicating with a wellbore stability process to coordinate device commands while drilling ahead in order that neither acts outside the other’s process protection envelope.

Interoperability Interoperability promises to reduce integration efforts and accelerate innovation within automation. Multiple proprietary systems that are in place require standards to provide the required levels of interoperability, Interoperability, as has already occurred in industrial automation, will ensure that devices and processes can be replaced “plug and play” with any alternate that meets the required specifications. Specifically, the ability to replace a system (company and technology dependent) with an alternative can be seamless from the communications perspective.

Contextual / Situation Awareness For an intelligent automation process to exist, systems and sub systems need a clear communications protocol that can share contextual and situational analysis such that advisory and control systems make the appropriate decisions. Different information will need to be passed between the various actors to ensure a seamless response to changing well conditions. When a system is actively controlling a kick event provision needs to be made for it to notify other control processes that an event is in progress which overrides other systems intent and it acquires the necessary data to perform.

Communication Protocols

Protocols (TCP vs UDP) TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) are complimentary protocols which are both at work in the transport layer of TCP/IP.

Communications


TCP contains all the information required for maintaining connections, ordering transmissions, multiple packet management, and requesting rebroadcasts of out-of-order packets. UDP is a very lightweight, single packet transmission protocol with no concept of connections, reception order, or error checking. TCP is the obvious choice of protocols for control, whereas UDP is better for bandwidth limited cases where a few errors in transmission are tolerable.

WITS WITS is a streaming communications format used to exchange rig data between service companies and operators. Although the specifications offer a multi-level format, reality reveals the use of only level 0. This is a basic, ASCII based, transfer of discrete data records. Each data item has an embedded header, which is decoded to identify what the data is. This can be follow the defined standard identifiers, or be a user agreed-upon extension to the standard. The transmission is a one way, and serial with no error checking or rebroadcast capabilities. Most companies offer some form of buffering for breaks in transmission. Only data values are broadcast, no information on units or any other metadata is included. It has no programming interface.

WITSML WITSML was created in 2000 as a successor to the previous WITS standard. WITSML is web-based and built on platform and language independent XML. It defines a drilling domain data model in XML schema and a data access API that is implemented using SOAP (Simple Object Access Protocol). The mandate of WITSML is "to promote the right-time, seamless flow of well data between operators and service companies, as well as regulatory agencies, to speed and enhance decision-making and reporting". For drilling automation, the WITSML object model is lacking in the description of rig objects and real-time drilling metadata. There are currently no WITSML objects that address the topic of device control. WITSML may not be "real-time" down to the levels of speed and latency that this normally implies but it is used extensively today to drive drilling decision applications such as geo-steering, drilling optimization, well bore pressure control and formation pressure testing. Current development of the WITSML standard is focused on high-speed binary data transfer using WebSocket technology to be able to traverse firewalls and wide-area networks, connecting drilling rigs with real-time support and decision centers.

Energistics Transfer Protocol (ETP) ETP is a new data exchange specification that enables the efficient transfer of data between applications and systems. It defines a data streaming mechanism so that data receivers do not have to poll for data and can receive new data as soon as they are available from a data provider. The initial use case is for real-time data; however, it is anticipated that ETP will be expanded to include functionality for data discovery and historical data queries. ETP has initially been implemented as a companion to the WITSML standard and has the potential to be the cornerstone for the next major revision of WITSML. ETP is also expected to be used by other Energistics standards.

Communications


SYSML Systems Modeling Language (SysML) is general purpose visual modeling language for systems engineering applications. SysML supports the specification, analysis, design, verification and validation of a broad range of systems and systems-of-systems. These systems may include hardware, software, information, processes, personnel, and facilities

OPC classic vs UA OPC Classic is software used to transfer data between different control systems. It was based on Microsoft COM technology. As such it was not portable or extensible to distributed systems. OPC Classic has different access methods for real-time data (DA), historical data (HDA), and alarms and events (A&E). Each data object contains only 3 attributes: a value, a timestamp, and a status. OPC UA is the path forward from OPC Classic. Communications have changed from COM to a platform independent, service-oriented architecture for process control. Data objects are now structured to allow for both process data and device metadata. OPC UA supports two transfer methods: a binary protocol (opc.tcp) and a web service based protocol (http). The binary protocol offers the best performance/least overhead, while the web server protocol offers a XML parser, SOAP, and HTTP. This system allows for rig devices to be accurately modeled and exposed for both data and controls.

OPC and Drilling Automation OPC is the interoperability standard for the exchange of data in industrial automation.

History Origin The standard was first released in 1996, with the purpose of abstracting PLC protocols, such as Modbus and Profibus, into a standardized interface which acts as a “middle-man” and allows seamless machine-to-machine interactions. The original standard, now known as OPC Classic was restricted to the Microsoft operating system. OPC originally stood for OLE (object linking and embedding) for Process Control, and was based on Microsoft’s COM/DCOM technology. This technology was widely adopted, with 3500 companies across multiple industries, with 22,000 different products.

OPC UA Starting in 2004, the OPC Foundation, retitled as the Open Platform Communications Foundation in 2011, created a path forward from the original communications model, based on a cross-platform, web service-oriented architecture for process control. The main characteristics of the new communications stack (standard: IEC 62541), known as OPC UA were:

• Platform independence, from embedded chips to general purpose computers, including ANSI C, C++, Java, and .Net implementations;

• Scalability from smart sensors to mainframes; • Secure, multi-threaded operations, based on new network standards;

Communications


• A full, three-dimensional mesh network of nodes serves as the information model. This allows information to be modeled in an object-oriented fashion, merging data with its’ metadata;

• A singular access method for real-time, historical, and alarms & events.

Implementation As a commercially available standard, OPC UA was chosen by the SPE DSA-TS committee to be the basis of a proposed automated drilling solution. The combination of a secure, networked based protocol, with two-way device communications and the ability to model rig objects, make OPC UA a strong contender for any automated drilling solution. As of today, there are over 450 companies who are OPC Foundation members, with an estimated 17 million machine and factory installations. Some example industries that are reaping the benefits of OPC UA are:

• Transportation – Deutsche Bahn – monitoring a system of safety devices on rail tracks, bridges, dams and tunnels;

• Automotive – Kromberg and Schubert – product (wiring systems, mechatronic and plastic parts) control and coordination across a network of manufacturing plants;

• Chemical Manufacturing – Saudi Arabian Fertilizer Company – Recovery from a serious cyber-attack that resulted in disconnecting the network between manufacturing/process plants and their corporate network;

• Energy Monitoring – City of Aachen – monitor the consumption of water, electricity, and heat across 170 public buildings;

• Food and Beverage - Weber Maschinenbau – robotic slicer for sausages, meats, and cheeses; • Oil & Gas – Railroad Commission of Texas – monitoring of the production of over 700 wellheads; • Oil & Gas – Integration Objects – integration of a network of refineries, pipelines and pumps,

and LNG plants; • Water Treatment – Joint Water and Wastewater Authority, Vogtland – used decentralized,

independent embedded controllers form an intelligent control network for potable water and wastewater plants (~ 600 plants).

The current technology trend towards the 4th Industrial revolution (German initiative Industry 4.0), leads to concepts such as platform independence, decentralized intelligent controllers, standardized communications and security. OPC UA is well positioned in such a world, as applications for the IoT (Internet of Things), and base technology for M2M (Machine-to-Machine). As an open foundation, the OPC Foundation is at the nexus of collaboration efforts between a variety of standards organizations, and is heavily involved in the oil industry based SLC (Standards Leadership Council).

OPC UA and Drilling Automation As can be seen from the above examples, OPC UA has application across a series of oil field tasks, most specifically drilling and the monitoring of production. To integrate with the existing oil field/oil company infrastructure and standards, the OPC Foundation has begun an initiative to allow data servers based on Energistics’ standards (WITSML, PRODML, RESQML) to interoperate with OPC UA servers. This would allow the standardization of the flow of data from field acquisition (via OPC UA) to corporate data storage and application specialists (via WITSML/PRODML) in a secure fashion. The list of tasks facing this committee can be summarized as:

Communications


• Define the mapping between a WITSML/PRODML object (like Well, Wellbore or Log objects) and an OPC UA version of the object. This entails creating a method for automatically browsing a WITSML/PRODML object and generating the OPC UA information model for that object;

• Determine the protocol for the data transfer communications between server types. This solution may be an internal or external to the servers

• Integrate the DSA-TS information model for drilling rigs into both OPC UA and WITSML (v2) dta models.

The committee is currently defining an OPC UA information model that will match the WITSML/PRODML objects. The expected timeline for deliverables on this first step is scheduled for fall of 2016. The main benefit of this effort is to make the flow and formatting of data both automatic and invisible to the end user. In addition, real-time data should be included in the data flow. DSA-TS additions should result in some new WITSML objects, specifically for real-time drilling operations.

Agents of Change

Internet of Things The Internet of Things is a growing network of objects – from industrial machines to consumer goods – that can share information and complete tasks on their own. There is an exponential growth in consumer goods that do this. For example, refrigerators can now detect milk consumption patterns and order directly from the grocery store for delivery before the milk runs out. The connected car is now able to integrate and present information about the nearest gas station as it runs low on fuel and can interact with the GPS to navigate rapidly to the location. This network of objects that can interact and have levels of self-awareness is called the Internet of Things, (IoT). Made up of millions of sensors and devices that generate incessant streams of data, the IoT can be used to improve drilling automation in many ways. The Internet of Things consists of three main components:

• The things (or assets) themselves. • The communication networks connecting them. • The computing systems that make use of the data flowing to and from these things.

In Stream capabilities Traditional analytics must wait until data is persisted in some form of data store. To be run in stream they needed to be embedded as firmware in the control or acquisition system. This placed a barrier to innovation on the data stream by effectively locking out 3rd party agents. Event Stream Processing (ESP) engines, a subset of complex event processing (CEP) technology, can compute in-memory, in-stream and in-real time at a millisecond interval. Coupling this with real-time subscription communications systems enables drilling automation to place more complex algorithms, either physics or data driven, into the data stream and solve issues like:

• Identifying and stopping security breaches; • Predicting and recommending actions to mitigate against mechanical issues • Determining context and then adding it back into the stream to enrich the flow of information

Communications


Behavioral and pattern based Cyber Security Rule based cyber security solutions are important. However, with an ever-increasing level of sophistication in attacks these are now being enhanced with behavioral and pattern based solutions. These new defense systems can detect hostile activity anywhere on the network with real-time monitoring of massive amounts of data. Coupled with this powerful analytic technique they reveal anomalies and connections that would otherwise be missed. Analytical cyber defenses can uncover hidden relationships and identify subtle patterns of behavior that may indicate zero-day and advanced persistent threats (APT), such as low-and-slow attacks, which are much harder to detect because they happen over time.

Problem Statement (barriers, needs, critical success factors) A lack of aligned direction on communication strategies across systems on drilling rigs is hindering the pace of innovation on automation systems. For the industry to accelerate development of automation solutions this needs to be resolved in a consistent and agreed upon manner. To provide an effective mechanism of aligning the needs of the various components and systems within drilling automation and the capabilities required of the communications system an agile methodology has been proposed. The intent if these use cases is not to solve the needs of the system but to identify the barriers, needs and critical success factors. The agile methodology provides one of the fastest methods to deliver new technology into the field especially technology that is software based or software related. The ability to design systems and test them in a virtual environment subsequently completely reconfigure them so not destroy heavy investment into hard ware that is subsequently lost.

Barriers The barriers to achieving an open communication system for a fully interoperable drilling automation system are not technical; they are perceptions of commercial needs. The technical barriers have already been overcome in industrial automation.

Proprietary Attitude Many companies in oil and gas drilling / completion activities believe that proprietary systems block competitors from entering specific operations. Specifically this includes machine control, machine data, data transmissions systems from downhole (telemetry) and extends to preventing access to information in an attempt to block participation. Some companies claim that access to their control systems encounters liability issues. This barrier can and will be overcome through the following:

- Control of any machine or equipment through the DSA Framework (based on ISA 95) hierarchy will send instruction to the machine that the machine can execute as is within its proprietary system or respond that it has certain limitations which the control system must respect in sending its instructions.

Communications


- Accessing data from machines and equipment through an understanding that playing on the team will grow the business. Furthermore, operators can, and will, specify in contracts the quality of the data, the calibration and maintenance of the sensors and the requirement to share the data. Blocking this progress will simply alienate a supplier and create a feeling that the data is untrustworthy through being inaccurate and unreliable.

Lack of a common standard The use of proprietary communications systems without a common standard inhibits the progress of automation. The industry’s willingness to adopt OPC UA for high rate data and control combined with the development of the interface between OPC UA and the commonly used information system of WITSML will open up the communications avenues through standard solutions. OPC UA offers significant advantages in speed, fidelity, meta data (knowledge on the data) and security which will realize cross company benefits.

Lack of Open Interfaces The oil and gas drilling / completion industry has progressed in creating interfaces that enable cooperation between sensors / control companies and telemetry systems. Gyro while drilling companies can connect into multiple company mud pulse telemetry systems, the current hard wired pipe system encapsulates packages on information from third party sensors and transmits them to the surface where they are un-encapsulated and decoded. A common standard that enables all downhole to surface and vice versa transmission systems will enable multiple sensor and control loops to manage aspects of downhole operations.

Way Ahead

Standardized downhole and rig to office telemetry The telemetry of drilling data requires multiple levels of technology. There needs to be an underlying level of connectivity provided by established information and communications technology such as TCP/IP networking on top of satellite, mobile phone or other proprietary connectivity (e.g. wired pipe). On top of this there may also be one or more layers of web technology such as HTTP(S) and/or Web Socket. With the basic networking established we can then implement our industry-specific data telemetry formats based on more specific standards such as OPC-UA or WITSML/ETP. These provide the additional items of domain-specific context and metadata that make them useful for real-world applications such as drilling automation. The implementation stack could look something like this:

IT Industry Drilling Industry

WebSocket WITSML/ETP

Communications


HTTP OPC-UA, WITSML

TCP/IP stack OPC-UA

Satellite, Mobile/Cell Phone network, Wired Pipe

Proprietary solutions

Downhole Telemetry Benefits we expect to be realized are:

• Plug n’ Play for data and services • Removes barriers for service provision, enables more companies to compete • Provides greater confidence in the reliability, accuracy and meaning of the data due to

enhanced metadata and context awareness. Downhole to surface telemetry could remain as is with the capabilities of mud pulse telemetry for most operations, with some using hard wired pipe for analysis and testing. Alternatively, hard wired pipe could become a differentiator on high specification offshore rigs creating a niche environment with very high data rate capabilities. Hard wired pipe could be developed into a commodity which enables most rigs across the entire fleet to offer high data rate capability. Alternative technologies could be developed that provide much higher data rates and bandwidth than mud pulse without achieving hard wired pipe capabilities. Such technologies would predominate and define the surface to downhole control capability. A future down hole telemetry story is:

- Hard wired pipe is added to high spec floating rigs and jack up rigs to provide a differentiator to the potential client. They are used to attract contracts since they provide a real-time conduit for the operator (the client) to collect down hole wellbore date with the intention to upgrade subsurface models real time with the value add that best decision making can be made in the uncertain exploration and appraisal environment. Such pipe will also enable advancement of real time surface control on downhole parameters.

- An alternative hard wired system becomes available that has lower cost, pipe retrofit and power transfer abilities. This system is a first step to commoditized hard wire telemetry systems and the current hard wire pipe OEM reacts with accelerated manufacturing efficiencies and reduced pricing that both accelerate adoption. The two competing systems become a win / win in growth of each system.

- Mud pulse / EM telemetry continue to show small advances in bits per second but cannot overcome the latency effect.

- A new telemetry technology emerges that offers a higher data rate than mud pulse and EM with less latency than mud pulse. This system provides a new opportunity for reliable low cost improved rate and latency system that builds a bridge for additional automation opportunities.

Communications


Timeline: (Ongoing but expect significant change in the next 5 years) Rig to Office telemetry using web and WITSML standards is possible today but will mature over the next 5 years as the standard is developed further to accommodate additional data types and drilling processes. Standardized downhole to surface telemetry is a longer-term goal but can be prototyped on existing wired pipe systems. Interim solutions may include BHA to BHA high speed communication allowing BHA tools to communicate with BHA sensors to provide a real-time feedback without a high-speed communication to the surface. The proprietary nature of the current wired pipe systems is a barrier to standards adoption.

State Based Information One of the objectives of an automated drilling will be to endow the system with the ability to operate in an autonomous fashion. A logical “vision” of such a system would be drilling on the ocean floor, where one would input a location with at target and the system would automatically deploy to the location and drill a well to the target without human intervention. To reach this state of development, we must first mechanize the individual tasks that comprise drilling and add in contextual information, so that system has a reference to the current drilling task and knows what steps are to follow. This contextual information must contain the idea of state – where the program is in the process of drilling. The simplest version of this is the idea is rig state, are we rotate drilling, slide drilling, washing/reaming, tripping in/out, or making a connection. By knowing the current rig state, the process variables can be tweaked to optimize performance, just as in refining and chemical engineering. By knowing the next or future states, supply chains can also be optimized, minimizing the time spent between states. State based contextual information is a pointer to a series of steps in a process. Its main concern is the current “state” of the environment.

Timeline: Imminent One requirement of implementing state based information is a solid knowledge of the individual steps involved in the process. Attempts for drilling automation such as Drill-A-Stand have defined the process steps, from slips-out to slips-in drilling. As such, rig states as mentioned above can be defined and implemented to control the set points for each of individual tasks. One caveat is that rig states have been subject to proprietary development, which may or may not be consistent needs of drilling automation rig states. Additional state based information will be developed as groups of mechanized tasks are brought on-line. The major quality issue will be the consistency of definition, so that the state has incontrovertible and common meaning.

Operational Intent Contextual information is not limited to the knowledge of state based context. In almost all cases, the contextual steps will be modified by external forces, such as economic and natural forces. For instance, hurricanes or tornados can cause the orderly steps in the drilling process to be interrupted for reasons of safety. Economic forces such as contractual obligations (rig is supposed to be at site X by date Y to prevent losing a lease) can also modify both the sequence of individual tasks as well as the individual task itself. Operational intent is a modifier to either process or process task.

Communications


Timeline: Long term (5+ years) The current state of focus in drilling automation is on mechanization of individual tasks. The chain of process steps has had some initial attempts at organization. Operational intent can only be defined once both the tasks and the process steps have both a non-changing definition and a “standardized” content. One can only measure deviations from a process if that process is well defined.

Rig Information Model The most basic issue facing drilling automation is the organization and publishing of drilling data. Automation can occur without data organization, but it will be proprietary, non-portable, and cost inefficient. Drilling automation will not develop on a grand scale until it is cost efficient, especially for low-cost, unconventional objectives. To make drilling automation cost effective, drilling data must be organized such that common interface or portal can be used by automation algorithms. The current business model of drilling is a major inhibitor to drilling automation. Third party vendors interface to the rig data network which supplies operators with drilling data. Variations in implementation and architecture result in variations in the data content and quality received. In addition, vendors who are responsible for delivering data (such as MWD/LWD data) may vary from well-to-well. The Rig Information Model (RIM) is an attempt to organize the drilling data. It must consider variations in rig construction (different rigs have different sensors and capabilities) and changes to the rig in real-time. Because of these issues, the RIM is different than WITS0, in that the RIM defines locations where similar data can be found, and not a specific list of data items. RIM is intended to provide a query capability, so that external programs (both control and passive models) can determine the rig configuration as well as the available data. The RIM is also differs from WITSML, in that the data is organized by drill rig and not by the well/wellbore. The final key to the RIM is that each data object has a one-to-one correspondence with piece of rig hardware. Each software object models a specific device, with the same root template inherited for each object. Rig modelling then becomes the summation of the modeled parts. When one part of the rig is changed, only the software model for that one part changes. If kept in conjunction with a data historian, then a true record of rig evolution will be kept. Finally, the RIM has the facilities for recording and converting units, as well as asset tracking (who wrote this piece of information and when).

Timeline: Ongoing (~ 2-5 years) A first-pass proposal for a RIM has been developed and vetted against the data required to Drill-A-Stand. The fetal data structure is in the process of “standardization” and upon committee birth will likely be administered by a standards committee (Energistics). From there, the industry will determine how and when the RIM will evolve. The expected time frame for version 1.0 would be from one to two years.

Data Federation One of the challenges we face in data management is centered on how we manage the presentation logic of data. Traditional data storage system aggregate data into storage based on footprint size and or what appears to be most logical. This presents two challenges. Firstly, not all consumers of data require the same logical associations across data, and secondly, physical aggregation of the data like this is not

Communications


agile enough to rapidly adopt new data into the architecture, leaving some data stranded and having to be handled by exception. In some cases this can lead to more than one aggregation solution being used in the same location. See figure below.

Simple view of a physical aggregation solution

This can be partially solved by the use of cloud architectures, where data can simply be stored in its native format as it is acquired without the need for logical associations. This does not solve the problem of how to rapidly integrate new data, and data that may move location. It also doesn’t answer how to present data such that it is logical to the consumer application. This is where Data Federation bring real value to the data architecture.

Cloud based data federation

The underpinning technology is known as Representational state transfer. REST consists of coordinated constraints that are then applied to components, connectors, and data elements, within a distributed hypermedia system. The system is then able to ignore the details of component implementation and protocol syntax to focus on the roles, interaction and interpretation of the disparate components of the data architecture. The data federator employs a virtual data layer that understands the location of data and can be updated as new data appears, or existing data moves. The Federation layer virtualizes the data in a logical hierarchy that can be pre-defined from both the enterprise level and the consumer level. The benefits here is that the burden of processing and data management is removed from the

Communications


processing elements of the system that are using the data. The virtualization layer can also be used to provide common attributes required across disparate systems such as the synchronized clocking of data time stamps.

Timeline: imminent through the next 2 – 5 years Data virtualization, federation and cloud technologies that can deliver data lakes at the rig site of information stored in its native format but made available for consumption via predefined virtualization is available today and is already being implemented in other industries. We can expect this to become the norm for rig site data aggregation and storage over the coming years.

Multiplexed Communications Multiplexed communications is a technique whereby multiple data streams can be combined into a single stream. This provides the advantage of being able to send different data at different data rates, thus enabling information of higher frequency and importance to be granted greater throughput rates than those deemed to be less time critical to an operation. The system comprise 2 units. The MUX which multiplexes the input data into the combined stream and the DEMUX which compiles that data back out to its native format.

There are 6 common methods of multiplexing in use.

• Space-division: The use of different physical communication mediums • Frequency-division: Use of different underlying frequencies to modulate signal transmission • Time-division: divides available bandwidth into individual time slots for data transmission • Polarization-division: Channels are separated based on electromagnetic polarization • Orbital angular momentum: Uses electromagnetic radiation and can be combined with the

physical methods above ( can achieve data rates up to 2.5Tbs) • Code-division: multiple data sources broadcast data simultaneously on the same frequency. The

system can then implement several frequency bands to transmit multiple data sources at differing rates. These various multiplexing techniques and combinations of them are used throughout many industries where bandwidth is constrained (GPS, In Car Communications systems, Smart Phones etc.)

Implementation built on top of multiplexing technologies are already beginning to make their way into industrial applications. One example of this is Time Triggered Gigabyte Ethernet. In this scenario communication is time splice in a synchronous solution such that the same information can be transmitted between devices on multiple physical connections and thus provide secure and synchronous communications with built in physical redundancy. (http://mil-embedded.com/articles/orion-avionics-designed-reliability-deep-space/).

Communications


Timeline: Imminent but developing over the next 5 years Although these technologies are available for implementation today, we also see some significant leaps in combinations of multiplexing and time sliced redundant communications medium over the next 4-5 years.

Self-Aware devices - IOT Spectacular advances in technology have introduced increasingly complex and large scale computer and communication systems. Autonomic computing has been proposed as a grand challenge that will allow systems to self-manage this complexity, using high-level objectives and policies defined by humans. Internet of things (IoT) will exponentially increase the scale and the complexity of existing computing and communication systems; the autonomy is thus an imperative property for IoT systems. One of the key tenets of the IOT is the ability for devices within the systems to be able to share information between themselves whilst continuing with their primary task (measurement, control, advice etc.)This fundamentally changes the architecture of the system from a sequential and centralized system to one of pluralities decentralized information flow. In the scenario it is imperative that the communications solution can provide the not just the connectivity but the synchronous elements of data movement. This ties very well with the multiplexing section noted above and technologies such as TTGB.

Timeline: Imminent but developing over the next 5 years Timing of the introduction of IOT will undoubtedly be osmotic in nature. It is likely that IOT devices will gradually appear on the rig and their self-aware capabilities will be phased in piecemeal as the system of systems grows. For this reason introduction will and in fact has already begun, but the IOT inferred value will gradually appear over the following 4-5 years, Specific KPIs might include:

• Security: Tightly integrated hardware and software security from the edge to the cloud, along with data protection and policy management, delivers trusted data to automation systems that deliver value to end users

• Interoperability: Modular, standardized technologies seamlessly communicate to one another, accelerating automation and reducing the cost of deploying and maintaining complex IoT solutions

• Manageability: Device, security, and advanced data management provide end users with the capabilities to easily manage large-scale IoT systems built from multiple venders products and services

• Analytics: Delivering trusted data and the capability to run analytics near the sensors and streaming the results along with raw data to the cloud enabling real-time insights and streamlining operations

Communications


Future Data Values & Data Enriched to become information We can already see from the IOT section above that the communication of information at the rig site will develop beyond sensors measurements at specified horizons such as depth and time. In addition to this many companies are also now including the ability to predict or project future states of the system. In support of this we note that data historian vendors such as OSISoft have already begun rolling out next generation data solutions that include projected or future values that are associated with particular sensor or device values at any given horizon. A good example of how this would look in a drilling automation system is a communication stream that provides the current Inclination of the drill bit as well as the expected inclination in 3 ft. based on some form of predictive algorithm.

Timeline: Imminent but developing over the next 2-3 years Although the technology exists to do all of the predictive or projected calculations today, the communications structures to transmit this information associated with current values is only now being released to the market. It make take another year before this capability really begins to take hold on the drilling system, with the initial roll out of these solutions likely to be downstream in pipeline integrity and refinery operations first.

Cyber Information The primary the objective DSA-R Communications cybersecurity is to ensure that a rig survives a cyber-event without loss of function in critical applications. Manufacturers, Developers, Integrators, Information and Operational Technology staffs face the challenge of providing cybersecurity for very different technologies, architectures, and data types (IT vs. IACS). Sourcing, transmitting, and storing data in highly connected computer environments demands new approaches to cybersecurity. Requests and requirements for broadband connectivity to critical systems will arguably continue to increase, making the routing of control system data over non-control networks a common (and expected) practice. This desire for more information sharing has led to increased cybersecurity risks inherent in more open and more connected networks (SCADA). The most obvious risk is the possibility of connections to unprotected networks (“Internet of Things” or IoT…). But in practice, vulnerabilities exist within all the system architecture layers – from the user interfaces through the applications and into the data storage and presentation functions. Even when security controls and embedded security features protect these system layers, malicious or careless introduction of un-authorized software into the control system domain is relatively straightforward. The future state of controls and data security in drilling automation systems (“Rig of Things,” or RoT) is ultimately a safety issue and relies on hardware and software architectures that provide seamless connectivity while maintaining and protecting as-designed functional performance. The practice of proving security for user interfaces, evolving applications, and sensitive data while simultaneously providing defined communication services and responding to cyber threats, will be increasingly automated and transparent to integrated control systems.

Communications


Emerging security systems will mine and analyze combinations of already-available data, and monitor network behavior patterns to expose and neutralize risky connections and harmful software functions. Data communications will evolve from unprotected protocols that provide no inherent security, to purpose-built protocols that incorporate security structures that discern and respond to anomalous behavior within the protected network and connected devices. Network devices will become context-aware, can take advantage of protocols that include security handles or tags by default, and can automatically reconfigure as needed without human intervention. Compensating controls will be developed and implemented for legacy systems without disrupting the useful mission of the communicated data itself. Inherent to automatically re-configuring security systems is the historically troublesome impact of self-reconfiguring software on highly integrated systems; but, with attention to quality engineering programs, developers can arguably overcome these potentially blocking problems. Key elements for providing security for emerging on-asset control systems include but are not limited to:

• Clear security policy and rigorous policy execution • Sensing communications protocols that are context-aware and resilient • Sensing and communicating field devices that are context-aware and resilient • Federated, authenticated identities for communicating on-asset devices and endpoints

(assumes agreement that all data communications must be protected) • Federated, authenticated identities for communicating remote devices and endpoints (assumes

agreement that all data communications must be protected) • Automated vulnerability prediction, detection, patching between and within system

architecture layers; • Automated security intrusion sensing, monitoring, remediation, and contingency capability • Definition and arbitration of data ownership (automated?) • Metadata (or descriptors) collection, storage, and analysis capability

The way ahead will rely heavily on reliable (human and machine) identity enrollment and authentication practices, disciplined software engineering practices, ubiquitous on-asset sensing and communicating technologies, “future-friendly” equipment design, and disciplined system support behavior by personnel who interact with critical offshore control systems – really, just plain adherence to quality engineering principles and practices.

Timeline: Immediate but remains an ongoing development Given the nature and growing prevalence of cyber threats, we assume that the elements listed above will be implemented onto communication protocols as a priority over the next 1-2 years.

Cyber Security Source - Siv Hilde Houmb

Key aspects included under the heading of Cyber Security include:

Communications


- Secure communication (remote, internally, etc) - Integrity of data, communication, software, etc. - Availability of services/data/communication/software/etc. - Confidentiality of data and perhaps also services and communications

The solutions and actions to address Cyber Security concerns fits nicely with part of the MODU cybersecurity framework profile that USCG is developing together with NIST NCCoE and IADC and other industry interest groups. Current state is defining the core mission objectives for a MODU and mapping cybersecurity to these core missions. IADC guidelines are currently under development: minimum cybersecurity requirements; hardening, network segmentation and situational awareness/monitoring guidelines. Managing cyber risks is a critical success factor for drilling automation. Cyber Risk Management, or Cybersecurity, is the process of protecting information, systems, services and communications by preventing, detecting, and responding to cyber-attacks.” Cybersecurity encompasses protection against malicious and non-malicious actors, insiders and outsiders, to maintain the operational integrity of the drilling process. Part of the roadmap is to develop a cybersecurity program for drilling automation that are based on the following:

• NIST Cybersecurity Framework for Improving Critical Infrastructure Cybersecurity • ISA/IEC 62443 Series of Standards on Industrial Automation and Control Systems (IACS) Security • IADC Guidelines for Assessing and Managing Cybersecurity Risks to Drilling Assets and other

IADC cybersecurity guidelines • MODU Cybersecurity Framework Profile

The IADC / API draft cyber security management plan is attached as Appendix II

2015 2016 2017 2018 2019 2020Standardized downhole and rig to office telemetryState Based Information:Operational Intent:Rig Information Model:Data Federation: Multiplexed CommunicationsSelf-Aware devices - IOT Future Data Values & Data Enriched to become informationCyber Information Virtual Federation

AvailableAdopted

https://www.nist.gov/sites/default/files/documents/cyberframework/cybersecurity-framework-021214.pdf

http://www.iadc.org/ebookstore/ebook-iadc-guidelines-assessing-managing-cybersecurity-risks-drilling-assets/

Communications


Appendix I - Team Reference Information Section For Team use not for publication

Communications mediums Automating the drilling process requires the use of some form of computer to implement a predefined set of actions. The current trend towards distributed computing systems requires that these systems communicate with each other to establish the overall state of the “system”. In order for this communications to occur, there needs to be a physical medium over which to communicate.

Physical Systems There are 2 possible physical systems for establishing communications: acoustic and electromagnetic. Acoustic methods such as speech or mud pulses require a fluid media for transmission. Electromagnetic methods require either a semi-conductive medium (electrical methods) or a transmitter/receiver pair for wave propagation.

Acoustical Methods Acoustic methods are used in the presence of high conductive materials that effectively channel away electromagnetic energy. Propagation rates are much slower than electromagnetics (speed of sound << speed of light), and tend to be noisy and of lower bandwidth. Transmission distances are also very limited.

Electromagnetic Methods This is the preferred method of communication. It is faster and of higher bandwidth than acoustic methods. There are two subcategories of electromagnetic methods: one based of electricity (voltages over a conductor) and one based on wave propagation (light and wireless comms).

Laser Comms Laser communications are a potential future communications solution for delivering more information per second with high signal to noise ratios and low loss transmission. Laser communications has two drawbacks: alignment of the transmitter/receiver and diffusion due to the media the laser is transmitted through. This may be useful for rig-to-rig and possibly rig-to-sea floor communications, but probably not for wellbore communications.

Wired vs Wireless Wired communications are the most common, generally over copper (twisted pair – both shielded and non-shielded, or coaxial cable). Fiber optics can also be considered a wired communications. It has the advantages of broadbanding, decent bandwidth, and relatively low error rates. It is also tolerant of harsh environments, such as the borehole (wired pipe). The disadvantages of wired communications is found in its physical presence (pulling, tripping, breaking, wear, time & energy routing and installing) and the potential for noise from inductive pickup (especially in non-shielded versions).Wireless communications are the least intrusive communications method, as there is little/nothing to break or trip over and greatly simplifies mobilizing/demobilizing the rig. Their bandwidth is nearly as good as the wired version, although transmission losses will be higher. The main issues with wireless

Communications


communications are reduced range, the signal losses due to interaction with the transmission media (weather, electrical storms, and interference from other electrical source in the frequency range of transmission) and reduced life scan, especially for the transmitter.

Alternatives to wired pipe The borehole is a very hostile environment. From the fracturing of rocks, the mechanical horsepower of the rotating drill string, the interaction with the drilling fluid, to the elevated temperatures at depth, this is not the environment for fragile equipment. As such acoustic methods (mud pulse) are industry standard, despite hideous transmission speeds and bandwidth. Wired pipe is an alternative to mud pulses. It has barely sufficient bandwidth to communicate downhole data to the surface for automation purposes. The downside is the expense of wired pipe. If this technology is influenced by Moore’s law, then it is possible that the price will drop with both time and manufacturing volume. It’s current usage is limited to prototypes and proofs-of-concept. It may eventually be possible to use some form of electromagnetic (wireless) communications, which uses a section of the drill string as an antenna (variable phased array). This could be useful in the horizontal sections of the borehole. Vertical sections would still pose a problem (insufficient antenna gain).

Alternatives to BOP umbilical’s Not familiar enough with rig to sea floor communications to comment.

Communications Protocols The drilling industry has few standards in communications protocols. Serial and peer-to-peer protocols are used, and there exists a significant variety of proprietary protocols for both methods. These protocols were developed transmit a device data value and confirm its’ reception. In the early phases of development (1970s) communications hardware was far less expensive than computing power. Centralized computing centers relied on protocols such as ASCII, HART, and Modbus for data delivery. The rapid development of microprocessors has made it economical to process data at its source and rely upon networking to share the results.

Sensor based

BUS systems BUS based systems represent the current state of control and data acquisition systems used on drilling rigs. These can be subdivided into centralized control systems and distributed control systems. The basic idea is that one needs a hierarchy of devices, with deterministic response times, to control the “system”. As mentioned above the older systems used centralized controls and communicated via a master-slave protocol like Profibus. The later distributed control systems communicate via a peer-to-peer network and use protocols like Foundation Fieldbus. There has been a migration path to using Ethernet as the communication media for most of these protocols, although propriety protocols may be restricted to a specific media.

Communications


Latency and Bandwidth Latency will be an issue for device control. The more distributed the control system is, the more likely latency will cause problems. However, compared to human response time, automated response times should be better. Moore’s law should be expected to reduce latency as an issue within the next decade. Bandwidth should not be an issue at the rig site. However, as the possibility of running both information manufacturing and control programs off-site increase, the more bandwidth will become an issue. The first step should be to measure the bandwidth required to move real-time rig data to an off-site data center to determine the scale of the problem.

Fieldbus Bus power Cabling redundancy

Max devices Synchronization Sub millisecond cycle

AFDX No Yes Almost unlimited

No Unknown

http://en.wikipedia.org/wiki/AFDX

http://en.wikipedia.org/wiki/AFDX

Communications


AS-Interface Yes No 62 No No

CANopen No No 127 Yes No

CompoNet Yes No 384 No Yes

ControlNet No Yes 99 No No

CC-Link No No 64 No No

DeviceNet Yes No 64 No No

EtherCAT No Yes 65,536 Yes Yes

Ethernet Powerlink

No Optional 240 Yes Yes

EtherNet/IP No Optional Almost unlimited

Yes No

Interbus No No 511 No No

LonWorks No No 32,000 No No

Modbus No No 246 No No

PROFIBUS DP No Optional 126 Yes No

PROFIBUS PA Yes No 126 No No

PROFINET IO No Optional Almost unlimited

No No

PROFINET IRT No Optional Almost unlimited

Yes Yes

http://en.wikipedia.org/wiki/AS-Interface

http://en.wikipedia.org/wiki/AS-Interface

http://en.wikipedia.org/wiki/CANopen

http://en.wikipedia.org/wiki/CANopen

http://en.wikipedia.org/w/index.php?title=CompoNet&action=edit&redlink=1

http://en.wikipedia.org/w/index.php?title=CompoNet&action=edit&redlink=1

http://en.wikipedia.org/wiki/ControlNet

http://en.wikipedia.org/wiki/ControlNet

http://en.wikipedia.org/wiki/CC-Link_Industrial_Networks

http://en.wikipedia.org/wiki/CC-Link_Industrial_Networks

http://en.wikipedia.org/wiki/DeviceNet

http://en.wikipedia.org/wiki/DeviceNet

http://en.wikipedia.org/wiki/EtherCAT

http://en.wikipedia.org/wiki/EtherCAT

http://en.wikipedia.org/wiki/Ethernet_Powerlink

http://en.wikipedia.org/wiki/Ethernet_Powerlink

http://en.wikipedia.org/wiki/EtherNet/IP

http://en.wikipedia.org/wiki/EtherNet/IP

http://en.wikipedia.org/wiki/Interbus

http://en.wikipedia.org/wiki/Interbus

http://en.wikipedia.org/wiki/LonWorks

http://en.wikipedia.org/wiki/LonWorks

http://en.wikipedia.org/wiki/Modbus

http://en.wikipedia.org/wiki/Modbus

http://en.wikipedia.org/wiki/PROFIBUS

http://en.wikipedia.org/wiki/PROFIBUS

http://en.wikipedia.org/wiki/PROFINET_IO

http://en.wikipedia.org/wiki/PROFINET_IO

http://en.wikipedia.org/wiki/PROFINET_IO#PROFINET_and_isochronous_communication

http://en.wikipedia.org/wiki/PROFINET_IO#PROFINET_and_isochronous_communication

Communications


SERCOS III No Yes 511 Yes Yes

SERCOS interface

No No 254 Yes Yes

Foundation Fieldbus H1

Yes No 240 Yes No

Foundation Fieldbus HSE

No Yes Almost unlimited

Yes No

RAPIEnet No Yes 256 Under Development

Conditional

Fieldbus Bus power Cabling redundancy

Max devices Synchronisation Sub millisecond cycle

System Based

Interoperability A certain degree of interoperability exists between WITS, WITSML, and OPC. Most of the information that is described by WITS can be found in WITSML, and it is possible to map data between the two. However, there is no certainty that any specific piece of data is guaranteed to exist across the standards. OPC UA has the potential for containing a complete view of drilling operations, due to its information model, but a lot of work still needs to be done to define a drilling domain model that encompasses control and evaluation needs such that interoperability can be seamless. Some limited form of interoperability can exist, but variability in rig equipment configurations will make this a difficult promise to deliver.

Latency and Bandwidth Important for different applications. Low latency is needed for equipment control. Low latency requires High bandwidth is important for collection and aggregation of large data sets.

Team discussion on The Internet of Things IoT in DA will probably be more of an Intranet of Things rather than an Internet of Things I think this is where the ISA 95 model of levels becomes very pertinent. I agree that the rig site would essentially be an intranet, but there still need to be communication across Level 4 (enterprise) and Levels 0-2 ( Rig site). Of particular concern in my mind is the security aspect of anything gaining access to

http://en.wikipedia.org/wiki/SERCOS_III

http://en.wikipedia.org/wiki/SERCOS_III

http://en.wikipedia.org/wiki/SERCOS_interface

http://en.wikipedia.org/wiki/SERCOS_interface

http://en.wikipedia.org/wiki/Foundation_Fieldbus_H1

http://en.wikipedia.org/wiki/Foundation_Fieldbus_H1

http://en.wikipedia.org/w/index.php?title=Foundation_Fieldbus_HSE&action=edit&redlink=1

http://en.wikipedia.org/w/index.php?title=Foundation_Fieldbus_HSE&action=edit&redlink=1

http://en.wikipedia.org/wiki/RAPIEnet

http://en.wikipedia.org/wiki/RAPIEnet

Communications


a control system from outside of the intranet. Should we consider this within the remit of communication? I believe we should at least document it and setup a collaboration with the system team to discuss their thoughts on this. - IoT potentially exposes more security issues due to the accessibility of more parts of the system. Every component could be exposed to malicious attacks See above.. I completely agree - IoT will require a very robust, fault-tolerant architecture to account for “things” coming and going from the network This could be managed within the ISA95 reference architecture model. I would consider the system level and context to be key elements in governing this. - IoT will almost certainly be built on top of IPv6 and continue to use TCP/IP type communications either wired or wirelessly So what elements of a DSA IAT would need to be added to IPV6 and TCP/IP for IAT to become a reality ? Worth of a session with the team and John MacPhersons Sensors team on just this 1 subject ? - The technology behing IoT is still evolving rapidly and will probably see significant change over the next few years - IoT will be able to function over many different communications media (wired, wireless, optical, acoustic, etc.) - IoT will still require higher level technology to enable it to contribute to DA. Standard ontology and taxonomy (Semantic Web)so that “things” understand each other’s messages - - I agree, and I think this is something we should collaborate with the sensors and systems team on at least beginning to roadmap - - IoT will be event-driven. Devices will react to events from other devices and applications And Events will be both simple and complex. A great point and I see that as being where we really start the develop the comms roadmap. For this to happen what do these simple and complex events look like, and how will they be consumed and created by a DSA solution. - DA control applications will need to be significantly smarter to be able to cope with the range of information that can come from IoT - It will be a struggle to introduce this new technology. We are still using 30 year old RS232 and WITS today In my mind this is a change management issue. How do we create a compelling enough story to encourage people to make the change (how do we set the house on fire) Not all of these things are specific to our “Communications” part of DSA-R but this is probably an area where we need to engage with some of the other groups. Agreed lets figure out which teams we need to collaborate with and I can setup some intersections. I agree with 99% of what you've said. The niggle would be IPv4 vs. IPv6, although you really need the address space provided by IPv6 to make IoT useful.

Communications


It's part of the "cheap chips" trends. These chips will be deployed in an extremely decentralized fashion, putting silicon at the data acquisition location. That allows processed information to be transmitted as opposed to raw data. What affect will this have on media bandwidth? We will no longer need to stream the raw data to a centralized location for processing, it will be stored for reference at it's acquisition point, where it can still be requested. Processed information will the transmission media payload. This, theoretically, should reduce the bandwidth requirements, however the reality may be different, as the data structure of processed information is much more complex than a raw sensor value. IoT has one major caveat in my mind. It requires a "standardized" view of the each object. If there is a mismatch between what object A does and how object B views object A's function, then the processed data stream from object A may be misinterpreted by B. This would imply that IoT will have limited scope. It can useful on a drilling rig, where all the interplay between objects is well defined. I think this is a verbose restatement of your intranet vs. internet comment. Other than that, IoT is a fancy title for an ideal situation, like using Camelot as a model for governance. My guess it that IoT is and will always be vaporware. It's an ideal to aspire to, but will only function in a within a well defined and limited scope environment. The real limit is human understanding, but in a Borg world (excuse the Star Trek reference) it could work. For DA it's already happening. We've moved from Modbus system to Fieldbus systems. OPC UA pushes the processing power out even further, to individual rig devices, while separating out the control functions to centralized program. Perhaps the control logic can eventually be decentralized, but we will still need to centralize the logic (pseudo driller) in order to understand it.

Communications


Appendix II – IADC API Cyber Risk Management Plan

Communications


communications - drilling systems automation roadmap

Documents