Universal Wellpad Controller

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 platforms based on the Intel Atom® processor such as the Intel Atom® E3930 processor for power-efficient operation, Intel Atom® E3950 processor, and Intel® 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 Intel® Core™ i7 desktop or laptop processor family running Microsoft 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 the 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: 

///  

Example topic name : flowmeter/PL0/TodaysVolume/update 

The Operations could be:  

1. - This operation indicates the data polling at user-configured frequency into site configuration YAML files. 
2. -  The vendor apps can initiate on-demand read of attributes using a read operation. 
3. - The readresponse is the response topic for the corresponding read operation from the vendor app. 
4. - The vendor apps can initiate on-demand write of attributes using a write operation. 
5. - 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 RS-485 or RS-232 serial physical connections. Normally, with RS-232, only one device is connected at one time. Hence, to communicate with two Modbus RTU devices over RS-232, 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 RS-485 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 the 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 the Eclipse Foundation* Sparkplug* specification and enables bidirectional communication with SCADA Headend. The 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) 

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

Key Performance Indicator (KPI) Applet Container 

UWC 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 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 the main page. 

 

8. Save the current setting by clicking the  button. 

9. Reboot the machine and select the RT kernel from the 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

 

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 reference middleware is successfully installed. Now write your process control application and optimization app using the MQTT based Publish-Subscribe interface. You can refer to the 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 image 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., without 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, which is available at universal_wellpad_controller/Universal_Wellpad_Controller_1.0/uwc. 

 

Support Forum 

If you're unable to resolve your issues, contact the Support Forum.