Universal Wellpad Controller

Overview 

Build from a common open application reference middleware to accelerate software modernization strategies for Process Control and Process Optimization in the upstream oil and gas industry. The Universal Wellpad Controller (UWC) reference middleware provides a set of essential services for experts in the field to create microservice based solutions. Features include data collection with Modbus, prioritized data exchange pathways for process control data, connectors for device management, SCADA, and backend data systems. You can add new protocols, data analysis, and other capabilities to meet specific application needs. 

The UWC reference middleware enables upstream oil and gas operators with the flexibility to innovate and optimize their oil and gas production. It is ideal for an Original Equipment Manufacturer (OEM) or Independent Software Vendor (ISV) to incorporate into solutions to meet operator needs.  

Table 1

Time to Complete	1 hour
Programming Language	C, C++
Software	Edge Insights for Industrial UWC microservices

 

Target System Requirements

The UWC reference middleware is scalable and flexible to run on a variety of Intel-based platforms. For commercial scale deployment to Upstream Oil and Gas well pads, devices with Atex/C1D2 certifications are required. Hardware vendors have made available a range of Atom-based platforms with processors such as the Atom E3930 for power-efficient operation, E3950, and Core-i7 processors for scalable solutions and larger and more complex sites. 

The UWC reference middleware can be evaluated on a virtualized Intel-based platform such as Core-i7 desktop or laptop computer running Windows 10 with Hyper-V. 

The base hardware requirements for UWC reference middleware are: 

• Two or more physical or virtual cores 
• Intel Atom® or Intel® Core™ processor family 
• 4GB memory  
• 25GB hard disk space  
• Ubuntu* 18.04 server operating system with Preempt RT Patch  
• Two or more Ethernet connections 
• Optional: if user wishes to have RS-232 or RS-485 serial ports 

How It Works 

This open application framework uses Docker containers for Well control applications. It comes with a preemptive Real-Time Linux Operating System (RT-OS) and policy-based real-time data bus to allow for your applications to reliably communicate through the included Modbus applications with commercial quality hardened Modbus stacks.  

The MQTT/Sparkplug SCADA interface is included as well to provide interoperability to the leading SCADA systems and cloud infrastructure. The reference middleware includes comprehensive device manageability including Firmware, OS, and application lifecycle management.  

The application can subscribe to MQTT topics to receive polled data. Similarly, the application can publish data to be written on MQTT. The platform will accordingly publish or subscribe to respective topics. The MQTT topics are dynamically created by the framework based on the site configurations IDs.  

 

 

 

 

UWC Site Configurations 

UWC needs following Site configuration to function properly:  

The site configurations describe the number of wellpads and configurations of each wellpad that are managed by the UWC. The site configuration file format is YAML. The YAML configurations file contains the "ID" field and must be unique for the UWC deployment. For a complete list of fields, refer to sample YAML files included within source code (..\Others\Config\UWC\Device_Config).

You have to configure site configuration before the UWC deployment. The site configuration is fully user-defined. UWC can manage one to multiple wellpads, and each wellpad may manage multiple Modbus TCP or Modbus RTU devices, and each Modbus device can have multiple data points to monitor or control. The combination of "ID" field defines the MQTT topic name for data polling, writes and reads. 

The MQTT topic name format is as follows: 

<Device ID>/<DeviceGroupID>/<DeviceAttribute>/<Operations>  

Example topic name : flowmeter/PL0/TodaysVolume/update 

The Operations could be:  

1. <update> - This operation indicates the data polling at user-configured frequency into site configuration YAML files. 
2. <read> -  The vendor apps can initiate on-demand read of attributes using a read operation. 
3. <readresponse> - The readresponse is the response topic for the corresponding read operation from the vendor app. 
4. <write> - The vendor apps can initiate on-demand write of attributes using a write operation. 
5. <writeresponse> - The writeresponse is the response topic for the corresponding write operation from the vendor app. It indicates the status of write operations. 

 

 

 

 

Modbus Containers 

UWC supports Modbus TCP client (formerly called master) and Modbus RTU client, which issue poll and write requests to edge devices in the field that are running Modbus servers (formerly called slaves). These are developed as two separate containers, i.e., Modbus TCP container and Modbus RTU container.  

Modbus RTU Client Container 

Modbus RTU devices can be connected using RS485 or RS232 serial physical connections. Normally, with RS232, only one device is connected at one time. Hence, to communicate with two Modbus RTU devices over RS232, two different serial ports will be needed. It is also possible to have a combination of serial ports with RS-232 and RS-485 on the same device at the same time.   

Modbus RTU protocol with RS485 physical transport uses a twisted pair of wires in a daisy-chain shared media for all devices on a chain. The communications parameters of all devices on a chain should be the same, so, if different devices have different configuration (e.g., different parity, different baud rate, etc.), then different Modbus RTU chains can be formed. To communicate with two different Modbus RTU networks, two different serial ports will be needed. It is important to verify the analog signal integrity of the RS-485 chains including the use of termination resistors as per well-known RS-485 best-practices. 

In UWC, one Modbus RTU client can be configured to communicate over multiple serial ports. Hence, a single Modbus RTU client container handles communication with multiple Modbus RTU networks. The configuration for one Modbus RTU network (e.g., port, baud rate, etc.) can be configured in a RTU network configuration file. 

MQTT-Export Container 

Modbus containers communicate over internal Edge Insights for Industrial data bus (ZMQ). The MQTT-Export module enables communication with Modbus containers using MQTT. The MQTT-Export module reads data on ZMQ received from Modbus containers and publishes that data on MQTT. Similarly, the MQTT-Export module reads data from MQTT and publishes it on ZMQ. 

SCADA-RTU Container 

SCADA RTU container (Supervisory Control and Data Acquisition – Remote Terminal Unit) implements Eclipse Foundation’s SparkPlug specification and enables bidirectional communication with SCADA Headend. SCADA RTU container publishes machine model of sensors & actuators configured in the Site configurations files and reports tag data by exception (on change). The vendor apps have well-defined interface topic-based interface to publish machine model and tag data. SCADA-RTU supports TLS based secure connection with MQTT broker. 

SCADA-RTU container has the following Sparkplug Message Types for configured sensors & actuators in site configuration files and vendor applications.  

• Edge node birth (NBIRTH) 
• Edge node death (NDEATH) 
• Device birth (DBIRTH) 
• Device death (DDEATH) 
• Device data Messages (DDATA)  
• Device command (DCMD) 

SCADA-RTU container updates realtime online/offline status of sensors & actuators to the SCADA Headend. 

Key Performance Indicator (KPI) Applet Container 

The UWC platform offers infrastructure creating priority data pathways from field devices through to the application microservice layer. Whether the included application layer microservices (such as MQTT Export or SCADA RTU) or an application built by a developer for controlling a gas well or monitoring, it is important to be able to measure and evaluate the performance of the data pathways through the middleware. The “KPI Application” is a microservice provided to give the developer ability to do just that.  In addition, the KPI application can be used as a starting point (i.e., a sample application) for a developer who wants to connect these segments of data pathways into functions such as single-input, single-output PID Control loops and/or Event-Response functions.  

In the KPI Application configuration, a data “loop” is defined as the pairing of one read operation and one write operation: the “polling read” mechanism of UWC platform is used for the read operation and the “on-demand-write” operation is used for the write segment. In the sample application, a simple time delay is inserted. For a real control loop function, mathematical and/or boolean logic would be inserted into the data flow in place of the simple delay. A sensor of the wellpad, such as a pressure sensor, would deliver values to the read function and an actuator, such as a valve positioner, would receive the control signal from the write operation. In the current implementation, the read and write both use Modbus protocols. 

This KPI application can either be executed based on MQTT communication or based on Edge Insights for Industrial (EII) internal data bus (ZMQ) communication.  

The KPI Application also logs all data received as a part of control loop application in a log file.  A set of timing parameters of the loop performance are included in the log file including the total loop delay which is defined as the time between the trigger for the polling interval through until the KPI application has the confirmation message from the edge device that the control signal write was received. In addition to the timings, error codes from all layers of the system are collected and logged. This data can be used for measuring performance of the system. 

In the current version of UWC, only one KPI Application container can be instantiated at a given time due to the mappings to create the pathways through the EII bus (ZMQ) bus connecting the Modbus containers to the application containers. This version of EII bus supports only one subscribe; hence multiple KPI instance of KPI Application is not supported through EII bus. However, multiple instance MQTT based communication KPI application is supported.    

Get Started

Prerequisites  

• Internet connection (with proper proxy settings, if any) is required for installation. 
• Install Ubuntu 18.04 Server OS. 
• Make sure you have all the MQTT required client certificates/keys for SCADA RTU container in place as follows: 
  • CA Certificate – CA certificate  
  • Client Certificate – Client Certificate File 
  • Client Key – Client Private Key 

The above MQTT client certificates/keys are required for the SCADA RTU docker container to establish a secure TLS connection with the external MQTT broker. The SCADA RTU container acts as a client to the external MQTT broker. The SCADA Head-end (external system) also connects to the MQTT broker. The required client certificates are "client key", "client certificate" and CA certificate. The client and MQTT broker server must use the same CA (certificate authority). The server client certificates can be generated using OpenSSL commands for own deployment of MQTT broker. Sometimes client certificates are provided by the external service providers who manages MQTT broker deployment.  

NOTE: If the host system already has Docker images and containers, you might encounter errors while building the packages. If you encounter errors, refer to the Troubleshooting section at the end of this document before starting the installation.

Step 1:  Steps to Apply RT Kernel Patch (Optional) 

This will update Ubuntu 18.04 server image with RT Linux Kernel Patch (one-time setup). 

1. Go to the universal_wellpad_controller/ directory. 

cd universal_wellpad_controller/

2. Grant execute permission to install_kernel.sh script. 

chmod +x install_rt_patch.sh

3. Start the patch installation by using this command: 

./install_rt_patch.sh

NOTE: You will be prompted with the kernel configuration option (graphical menu in the terminal) to enable Real-Time. Follow the screenshot below to navigate. 

4. Select and enter on General Setup option. 

 

5. Select and enter on Preemption Model (Voluntary Kernel Preemption (Desktop). 

 

6. Select and Enter on Fully Preemptible Kernel (RT).

 

7. After successful selection click Tab and move to Exit prompt to come back to main page. 

 

8. Save the current setting by clicking on <Yes> button. 

9. Reboot the machine and select the RT kernel from grub menu. 

10. After restarting you can check if the kernel is RT or not by running the following command: 

uname -v | cut -d" " -f1-4

Step 2: Install the Use Case

Follow the steps below to install. 

1. Open a new terminal, go to the folder location and unzip the downloaded package.

unzip universal_wellpad_controller.zip

2. Go to the universal_wellpad_controller/ directory. 

cd universal_wellpad_controller/ 

3. Change permission of the executable edgesoftware file. 

chmod 755 edgesoftware

4. Run the command below to install. 

./edgesoftware install

NOTE: Refer to the Troubleshooting section at the end of this document if you encounter any Docker pull-related issues during the installation process. 

5. During the installation, you will be prompted for the Product Key. The Product Key is contained in the email you received from Intel confirming your download. 

6. There are four supported installation modes: three use-cases and one sub-use-case.

7. When the installation is complete, you see the message Installation of package complete and the installation status for each module.

Summary and Next Steps 

UWC middleware software is successfully installed. Now write your process control application and optimization app using MQTT based Publish-Subscribe interface. You can refer UWC user guide at universal_wellpad_controller/Universal_Wellpad_Controller_1.0/Document for more information on the MQTT publish-subscribe topics, how to configure wellpads, how topics are dynamically created base configurations, and troubleshooting. 

Learn More 

To continue learning, see the following guides and software resources: 
 

• Edge Insights for Industrial 

Troubleshooting 

Installation Failure 

You might encounter issues during installation if the target system has existing Docker images and containers. Please stop the container and remove the Docker images.  

To remove all stopped containers, dangling images, and unused networks: 

sudo docker system prune –volumes

To stop Docker containers: 

sudo docker stop $(sudo docker ps -aq)

To remove Docker containers: 

sudo docker rm $(sudo docker ps -aq)

To remove all Docker images: 

sudo docker rmi -f $(sudo docker images -aq)

Docker Image Pull Issue

If you are experiencing Docker images pull issues, please check the following: 

• This issue can be because of the latest pull rate limitations introduced by Docker Hub. Check this Docker site to help determine the exact pull limit that’s applicable on the system where you are trying to pull the publicly available Docker Hub images, such as Ubuntu, Python, etc.

NOTE: This limit is only applicable for the 6-hour window.

• If someone sees this issue with anonymous user (pull limit of 100), i.e., w/o docker login, you can create an account at https://hub.docker.com and try to do the build after logging in using the below command. 

  docker login -u <username> -p <password> 

   

• The other alternative is to use a paid subscription at https://www.docker.com/pricing.

 

 

Installation Script Fails

If the ./edgesoftware install script fails, you can try manual installation. Please refer to the release notes and user guide in the Document folder at universal_wellpad_controller/Universal_Wellpad_Controller_1.0/Document and the UWC source code is available at universal_wellpad_controller/Universal_Wellpad_Controller_1.0/uwc.