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.
Time to Complete | 1 hour |
Programming Language | C, C++ |
Software |
|
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:
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 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:
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 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.
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 (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.
SCADA-RTU container updates realtime online/offline status of sensors & actuators to the SCADA Headend.
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.
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.
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
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.
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.
To continue learning, see the following guides and software resources:
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)
If you are experiencing Docker images pull issues, please check the following:
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.
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.
Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex.