Universal Wellpad Controller

Overview

Universal Wellpad Controller is a reference middleware that facilitates accelerating software modernization strategies for process control and process optimization in the upstream oil and gas industry. It provides a set of essential services for experts in the field to create microservice-based solutions. Upstream oil and gas operators can innovate and optimize oil and gas production. Universal Wellpad Controller allows Original Equipment Manufacturer (OEM) or Independent Software Vendor (ISV) to incorporate solutions to meet operator needs.

The features of the Universal Wellpad Controller include:

• Data collection with Modbus
• Prioritized data exchange pathways for process control data
• Connectors for device management, Supervisory Control and Data Acquisition (SCADA), and backend data systems
• You can add new protocols, data analysis, and other capabilities to meet the specific application need

Select Configure & Download to download the reference implementation and the software listed below.  

Configure & Download

• Time to Complete: 1 hour
• Programming Language: C, C++, and Go are used in the codebase. Edge Insights Message Bus bindings are also available for Python* and Go*. bindings are also available for Python* and Go* Language
• Available Software: 
  • Edge Insights for Industrial
  • Universal Wellpad Controller microservices

Third-Party Software

The Naonworks ALITA* (Artificial Lift Innovated Technology Application) is an open architecture-based plunger lift control and automation system installed at the well site. It is a microservices-based application and builds upon industry standards such as MQTT Sparkplug and Modbus and is compatible with the Universal Wellpad Controller. The Naonworks ALITA* with Universal Wellpad Controller is enterprise-ready and virtually eliminates the challenges of stranded assets and the obsolescence of hardware and software.

Using Naonworks' user interface for ALITA, an operator can do the following:

• Integrate analytics and AI at the edge and get advanced insight
• Monitor the process parameters such as pressures, flows, and valve control in real-time
• Monitor the condition of the plunger lift at each well and across a field area or region
• Select the right hardware for the site
• Seamlessly upgrade and replace hardware in the field
• Perform upgrades to the application and the underlying software infrastructure
• Control the lift process to optimize production

You can download the ALITA application from https://download.naonworks.com.

Target System Requirements

Universal Wellpad Controller is scalable and flexible to run on a variety of Intel-based platforms. You will require devices with Atex/C1D2 certifications for commercial-scale deployment to upstream oil and gas well pads. Hardware vendors have made available a range of platforms based on the Intel Atom® processor such as 

• Intel Atom® E3930 processor for power-efficient operation
• Intel Atom® E3950 processor
• Intel® Core™ i7 processors for scalable solutions and larger and more complex sites

The base hardware requirements for Universal Wellpad Controller reference middleware are as follows: 

• 2 or more physical or virtual cores 
• Intel Atom® or Intel® Core™ processor family 
• 4 GB memory  
• 25 GB hard drive space  
• Ubuntu* 20.04 server operating system with Preempt RT Patch  
• 2 or more Ethernet connections 
• (Optional) if you are using the RS-232 or RS-485 serial ports 

To enable the Data Persistence recipe (with DataSStore and Telegraf*), for intensive data access queries or large databases, use higher performance and capacity components for CPU, memory, and storage. 

• 4 or more physical or virtual cores 
• Intel® Core™ processor family 
• 8 GB memory  
• 64 GB hard drive space 

You can also evaluate Universal Wellpad Controller on a virtualized platform based on Intel® Core™ i7 processor, such as a desktop or laptop running Windows* 10 with Hyper-V*.

How It Works 

Universal Wellpad Controller's application framework uses Docker* containers for well control applications. It comes with a preemptive Real-Time Linux* Operating System (RTOS) and policy-based real-time data bus. Your applications can reliably communicate through the included Modbus applications with commercial-quality hardened Modbus stacks.

The MQTT/Sparkplug* SCADA interface provides interoperability to the leading SCADA systems and cloud infrastructure. The reference middleware includes comprehensive Device Manageability including firmware, operating system, 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 configuration IDs.

  

 

Internal Data Sharing and Data Persistence 

The Edge Insights Message Bus (EMB), an abstraction over ZeroMQ*, is shown in Figure 1 and is the primary and most efficient data-sharing bus of the Universal Wellpad Controller. Interfacing to the Edge Insights Message bus is recommended if you are an application developer concerned with latency, performance, and timing jitter for your application. The bus uses the XPUB-XSUB model of ZMQ when the IPC mode is used by your containers. For scalability and interoperability reasons, a second bus, using MQTT*, is also available and is explained in the section MQTT-Bridge Container. 

Universal Wellpad Controller provides an optional Data Persistence recipe wherein a DataStore and a Telegraf data service are installed and configured. The Telegraf service has a plug-in that listens on the EMB ZMQ Data Bus and allows message ingestion from the Edge Insights Message Bus into the DataStore. A developer can configure the settings of the plug-in and database.  

Developers will get the flexibility to directly use the pre-build images from the Edge Software Hub or locally build the docker container images of Universal Wellpad Controller services. Also, the docker multi-stage build reduces build time for container images.

The configuration shipped by Intel has the bus connector listening for all topics on the EMB and filters to ingest only those JSON payloads for which a flag is present: dataPersist=true.

Universal Wellpad Controller Site Configurations 

Universal Wellpad Controller needs the following site configuration to function properly:

The site configurations describe the number of well pads and configurations of each well pad that are managed by the Universal Wellpad Controller. The site configuration file format is YAML. The YAML configurations file contains the "ID" field and must be unique for the Universal Wellpad Controller deployment. For a complete list of fields, refer to the sample YAML files included within the source code (.<source_code>.OthersConfigUWCDevice_Config).

You must configure the site configuration before the Universal Wellpad Controller deployment. The site configuration is fully user-defined. Universal Wellpad Controller can manage one to multiple well pads. Each well pad may manage multiple Modbus TCP or Modbus RTU devices. Each Modbus device can have multiple data points to monitor or control. The combination of the "ID" field defines the MQTT topic name for data polling, writes, and reads.

MQTT Topic Format

The MQTT topic name format is as follows: 

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

Example topic name : /flowmeter/PL0/TodaysVolume/update 

The operations can be:  

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

EMB Topic Format

Universal Wellpad Controller uses the new EMB granular topic format. This feature enables client applications to be written directly on top of EMB instead of taking an additional hop using the MQTT broker and MQTT bridge.

The new EMB topic format for publishing from "MQTT Bridge" / "KPI app" / "Client Application written directly on EMB":

<RT|NRT>/<operation>/device/wellhead/datapoint

where,

<RT/NRT> - means, real-time or non-real time respectively.

<operation> - can be "read", "write", or "polling (update)".

device/wellhead/datapoint - is the absolute path to the datapoint. (Example, /flowmeter/PL0/DP1).

Example of new topic format for this flow:

TCP-Write: NRT/write/flowmeter/PL0/DP1

TCP-read: RT/read/flowmeter/PL0/DP1

IOU-Write: NRT/write/iou/PL0/DP1

IOU-read: RT/read/iou/PL0/DP1

The new EMB topic format for subscribing from modbus master: <TCP|RTU>/<RT|NRT>/<operation>/device/wellhead/datapoint.

where,

<TCP|RTU> - indicates if the data is coming from modbus-TCP-master or modbus-RTU-master.

<RT/NRT> - implies real-time or Non-realtime respectively.

<operation> - can be "read", "write", and "polling (update)".

device/wellhead/datapoint - it is the absolute path to the datapoint. For example, /flowmeter/PL0/DP1.

Example of new topic format for this flow:

TCP-Polling: TCP/RT/update/flowmeter/PL0/DP1

TCP- writeResponse: TCP/RT/writeResponse/flowmeter/PL0/DP1

TCP-readResponse: TCP/NRT/readResponse/flowmeter/PL0/DP1

RTU-Polling: RTU/RT/update/iou/PL0/DP1

RTU-writeResponse: RTU/NRT/writeResponse/iou/PL0/DP1

RTU-readResponse: RTU/RT/readResponse/iou/PL0/DP1

Note: Vendor_Apps is used for publishing or subscribing on EMB. For more details on EMB way, refer to the README present in the IEdgeInsights/uwc/Vendor_Apps/ folder.

Modbus Containers 

Universal Wellpad Controller supports:

• Modbus TCP servers (formerly called Modbus TCP master)
• Modbus RTU servers (formerly called Modbus RTU master)

The servers issue poll and write requests to edge devices in the field that are running as Modbus clients. These are developed as two separate containers:

• Modbus TCP container
• Modbus RTU container

Modbus RTU Client Container 

Modbus RTU devices can be connected using the RS-485 or RS-232 serial physical connections. Normally, with RS-232, only one device is connected at one time. To communicate with two Modbus RTU devices over RS-232, you need two different serial ports. You can 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. If devices have a different configuration such as different parity, or different baud rate, then different Modbus RTU chains can be formed. You need two different serial ports to communicate with two different Modbus RTU networks. Ensure to check the analog signal integrity of the RS-485 chains including the use of termination resistors as per well-known RS-485 best practices.

In Universal Wellpad Controller, one Modbus RTU client can be configured to communicate over multiple serial ports. A single Modbus RTU client container handles communication with multiple Modbus RTU networks. The configuration for one Modbus RTU network such as port, and baud rate can be configured in an RTU network configuration file.

 

MQTT-Bridge Container 

Modbus containers communicate over the internal Edge Insights Message Bus (EMB). The MQTT-Bridge module enables communication with Modbus containers using MQTT. The MQTT-Bridge module reads data on ZMQ received from Modbus containers and publishes that data on MQTT. Similarly, the MQTT-Bridge module reads data from MQTT and publishes it on EMB.

The MQTT topic gets mapped to the EMB topic in the read, write on-demand requests. Similarly, the EMB topic gets mapped to the MQTT topic in the polling and read/write response operation flows. This topic mapping is done inside the MQTT-bridge container.

The new EMB topic format provides fine granular control for the applications written directly on top of EMB. Topic mapping in the MQTT-Bridge container is required for maintaining backward compatibility with the traditional MQTT protocol in addition to the new EMB topic format.

Fine granular control implies that in real-time or non-real-time, using the EMB topic format the client application can send data requests to the specific device wellhead, datapoint, operation, site ID, and so on.

Sparkplug-Bridge Container 

Sparkplug-Bridge is a container used for external data interfaces to SCADA (Supervisory Control and Data Acquisition) and similar operational control systems. Sparkplug-Bridge implements the Eclipse Foundation* Sparkplug* B specification to bridge messages using Sparkplug B to the internal data buses of the Universal Wellpad Controller. The Sparkplug-Bridge container publishes the machine model of sensors and actuators configured in the Site configurations files and reports tag data by exception (on change). The vendor apps have a well-defined topic-based interface to publish machine models and tag data. Sparkplug-Bridge supports a TLS-based secure connection with MQTT broker/EMB.

Sparkplug-Bridge container has the following Sparkplug message types for configured sensors and 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) 

Sparkplug-Bridge container updates the real-time online or offline status of sensors and actuators to the SCADA Headend.

Sparkplug-bridge connects SCADA ignition to Universal Wellpad Controller either directly through Edge Insights Message Bus (EMB) or through traditional MQTT > EMB path. SparkPlug* connection directly through EMB is new support added from Universal Wellpad Controller 2.0 onwards. This helps eliminate the latency introduced due to an additional hop in MQTT broker-MQTT bridge containers. However, backward compatibility with the MQTT protocol is still maintained.

Vendor Apps

Vendor apps are used for communicating with SparkPlug* (for virtual devices) using both Edge Insights Message Bus (EMB) and MQTT protocol. For the MQTT mode of communication, use any MQTT client like mqtt.FX. For the EMB mode of communication, use a sample publisher and sample subscriber application distributed along with the Universal Wellpad Controller distribution. In both cases, the vendor apps use the same topic and JSON payload for communication with the SparkPlug-bridge.

In EMB mode, the sample publisher and sample subscriber publish and subscribe directly through EMB to the Sparkplug-bridge service. ETCDUI provides a user interface to update the publisher topic and the JSON payload. For more details on using the ETCDUI for sample publisher/subscriber, refer to the README present in the IEdgeInsights/EtcdUI folder.

SparkPlug* can communicate with the rest of the Universal Wellpad Controller containers in either of the following modes:

• MQTT mode (which is Sparkplug-bridge > internal-MQTT-Broker > MQTT-bridge > EMB)
• EMB mode (which is Sparkplug-bridge > EMB)

Note: For more details on the working of vendor apps, refer to the README present in the IEdgeInsights/uwc/Vendor_Apps/ folder.

Key Performance Indicator (KPI) Container 

Universal Wellpad Controller offers infrastructure creating priority data pathways from field devices through to the application microservice layer.

The KPI application or KPI app is a microservice that enables developers to measure and evaluate the performance of the data pathways through middleware. This can be done for application layer microservices such as MQTT-Bridge or Sparkplug-Bridge or for an application built by a developer for controlling or monitoring a gas well.

Additionally, the KPI app can be used as a starting point or 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 app configuration, a data loop is defined as the pairing of one read operation, and one write operation: the polling read mechanism of the Universal Wellpad Controller 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 or Boolean logic would be inserted into the data flow in place of the simple delay. A sensor of the well pad, 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 app can either be executed based on MQTT communication or based on Edge Insights Message Bus (ZMQ) communication.

The KPI app in the MQTT mode uses the traditional MQTT protocol on the MQTT topic format for communicating with Universal Wellpad Controller whereas it uses the new granular topic format for communication in EMB mode.

The KPI app also logs all data received as a part of the control loop application in a log file. A set of timing parameters of the loop performance is included in the log file including the total loop delay, which is defined as the time between the trigger for the polling interval until the KPI app 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 the performance of the system.

Although the default recipes ship with a single instance of the KPI app, you can extend the Universal Wellpad Controller to have multiple applications by updating the recipes. This is possible because the EMB used supports an xPUB-xSUB-based ZMQ broker underneath. Allowing multiple publishers & subscribers to perform pub/sub on the EMB supports multiple publishers and multiple subscribers. As always zero, one, or more KPI app instances can connect concurrently to the MQTT bus.

Pre-processor flag should be used for enabling or disabling the KPI app on high-performance or low-power processors:

1. By default, the pre-processor flag UWC_HIGH_PERFORMANCE_PROCESSOR is disabled in the KPI app for the Debug mode and Release mode. 
2. To enable the KPI app on the high-performance processor in the Release or Debug mode, go to <Sourcecode> -> kpi-Tactic -> KPIApp -> Release/Debug -> src directory
3. Open the subdir.mk file and then add the option - DUWC_HIGH_PERFORMANCE_PROCESSOR in the line, where the GCC compiler is invoked.     
4. To disable the pre-processor flag in the KPI app, remove the option -DUWC_HIGH_PERFORMANCE_PROCESSOR added in above step 2 for both the Release mode and Debug mode. 

Note: High-performance processors are Intel® Core™ processors and low-power systems are Intel Atom® processors.

Get Started

Prerequisites  

• An Internet connection (with proper proxy settings, if any) is required for installation. 
• Install Ubuntu* 20.04 Server OS using the ISO image ubuntu-20.04.2-live-server-amd64.iso Server OS.
•  Apply RT kernel patch (optional). Refer to the following steps to choose and apply the RT patch for the kernel and OS version. Make sure you have all the MQTT required client certificates/keys for the Sparkplug-Bridge 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 Sparkplug-Bridge Docker container to establish a secure TLS connection with the external MQTT broker. The Sparkplug-Bridge container acts as a client to the external MQTT broker. The SCADA Head-end (external system) also connects to the external 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 their own deployment of the MQTT broker. Sometimes client certificates are provided by the external service providers who manage 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.

Steps to Choose and Apply RT Kernel Patch 

The latest version of the Universal Wellpad Controller has been tested with Ubuntu 20.04.2 LTS. Check the Kernel version corresponding to the Ubuntu OS version being used and map it with the correct RT Kernel patch.

Use the following links to map the Kernel version with the RT Kernel patch: 

•  https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/ 
•  https://mirrors.edge.kernel.org/pub/linux/kernel/

Step 1: Apply RT Kernel Patch (Optional)

Install Prerequisites

Install all the prerequisites using the following command:

sudo apt-get install -y libncurses-dev libssl-dev bison flex build-essential wget libelf-dev

NOTE: You will see a prompt to update the package runtime. Click Yes to update. 

Apply Patch

The following is the recommended OS and Kernel version:

• Linux OS version: Ubuntu 20.04.2 LTS
• Kernel version: 5.4.0-80

To apply the patch, complete the following steps:

1. Run the following command to create a working directory: 

mkdir ~/kernel && cd ~/kernel

2. Download the kernel in the ~kernel directory created in step 1. 

• Download Kernel manually from https://www.kernel.org/pub/linux/kernel/ or use the following command to download it from the command line inside the current directory: 

wget https://mirrors.edge.kernel.org/pub/linux/kernel/v5.x/linux-5.4.129.tar.gz

• Download the preempt rt patch from https://www.kernel.org/pub/linux/kernel/projects/rt/ or use the following command to download it from the command line inside the current directory. 

wget https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/5.4/older/patch-5.4.129-rt61.patch.gz

• RT patch Kernel version recommendation is to get PREEMPT_RT version 5.4.129-rt61 

3. Untar the Kernel using the following command:

tar -xzvf linux-5.4.129.tar.gz

4. Patch the Kernel:

cd linux-5.4.129 
gzip -cd ../patch-5.4.129-rt61.patch.gz | patch -p1 --verbose 

5. Launch the graphical UI for setting configurations. The following command launches a graphical menu in the terminal to generate the .config file.

make menuconfig

6. Select the preemption model as Basic RT using the Tab key. 

• Select General setup and then, press the Enter key. 
• Select Preemption Model (Fully Preemptible Kernel (Real-Time)) and then, press the Enter key. 
• Select Fully Preemptible Kernel (Real-Time) and then, click the Enter key. 
• Select Save and then go to the main page using the Esc key.  

7. To save the current setting, click <Save> and then, click <Exit> to exit the UI. 

8. Compile the kernel. In a production environment, the system key management infrastructure allows you to ensure that the patched Kernel works with the Secure Boot flow. When Secure Boot is not used, comment out the CONFIG_SYSTEM_TRUSTED_KEYS and CONFIG_MODULE_SIG_KEY lines from the /boot/config<version> file. Failure to do one of these two things will cause the following `make` commands to fail. After commenting out the above keys, if make -j20 failed with the "certs" error, remove the linux-5.4.129 directory and continue the installation from step 3.

make -j20 
sudo make INSTALL_MOD_STRIP=1 modules_install -j20 
sudo make install -j20 

9. Verify that initrd.img-'5.4.129-rt61, vmlinuz-'5.4.129-rt61, and config-'5.4.129-rt61 are generated in the /boot directory and then update the grub. 

cd /boot 
ls  
sudo update-grub

10. Verify that there is a menu entry containing the text "menuentry 'Ubuntu, with Linux '5.4.129-rt61" in the /boot/grub/grub.cfg file 

11. To change the default Kernel in grub, edit the GRUB_DEFAULT value in /etc/default/grub as required. 

NOTE: 0 is the 1st menu entry.

12. Reboot and verify using the following command: 

sudo reboot

13. After the system reboots, open the terminal and run the uname -a command to check the kernel version.

 

Step 2: Install the Use Case

To install the use case, complete the following steps:

1. Select Configure & Download to download the use case:

2. In a new terminal, go to the downloaded folder location and unzip the downloaded folder.

unzip universal_wellpad_controller.zip

3. Go to the edge_insights_industrial/ directory. 

cd edge_insights_industrial/ 

4. Change permission of the executable edgesoftware file. 

chmod 755 edgesoftware

5. Run the following command to download the modules. 

./edgesoftware download

6. Go to the build directory to install the pre_requisites script, where <version> indicates the downloaded version of Edge Insights for Industrial.

cd Edge_Insights_for_Industrial_<version>/IEdgeInsights/build/  
sudo ./pre_requisites.sh

NOTE: If the machine is in a proxy environment, run the following command:

sudo ./pre_requisites.sh --proxy=<proxy-address>:<port-number>

7. After successful installation, you should log off and log in to update the prerequisites installation changes.

 8. Run the following command to install: 

./edgesoftware install

NOTE: For Docker pull-related issues during the installation process, refer to the Troubleshooting section at the end of this document.

NOTE: During reinstallation, if the modules are already installed successfully then you will receive a prompt to select the Yes or No option to skip the module installation. If you do not enter the Yes or No option in the prompt then the system skips the module installation.

9. During the installation, enter the product key in the prompt. The download confirmation email from Intel contains the product key. 

10. Take the config of each module from ETCDUI or from the individual modules in the case of DEV mode only. The following prompt displays the supported installation modes (use cases).

• Regular Universal Wellpad Controller use cases without Data Persistence:
  • Use case 1 is with a minimal set of Universal Wellpad Controller containers required to run the Universal Wellpad Controller. The containers include:
    • Modbus-master TCP & RTU
    • MQTT-Bridge Internal MQTT broker
    • ETCD server
    • ETCD UI
    • Other base Edge Insights for Industrial services and Universal Wellpad Controller services
  • Use case 2 is a minimal set of Universal Wellpad Controller containers (from use case 1) along with the KPI-tactic app.
  • Use case 3 is a minimal set of Universal Wellpad Controller containers along with the KPI app, Sparkplug-Bridge, SamplePublisher, and SampleSubscriber vendor apps.
  • Use case 4 is to run use case 3 without the KPI app.
• Data Persistence and Its Use cases: Data persistence is a feature of the Universal Wellpad Controller wherein the data coming from the end Modbus devices can optionally be stored in the DataStore. The data points that need to be stored in the database can be configured in the datapoints YML configuration file as true or false for the “dataPersist” field. 
  • As shown in the following screenshot, use cases 5 to 8 are for the Data Persistence feature of the Universal Wellpad Controller. 
    • Use case 5 is with a minimal set of Universal Wellpad Controller containers along with Data Persistence. 
    • Use case 6 is a minimal set of Universal Wellpad Controller containers along with Data Persistence and the KPI-tactic app. 
    • Use case 7 is a minimal set of Universal Wellpad Controller containers along with data persistence and Sparkplug-bridge service. 
    • Use case 8 is to run a sample database publisher service, which publishes the sample data into the DataStore.
    • Use case 9 is with a minimal set of Universal Wellpad Controller containers that are required to run Universal Wellpad Controller middleware along with SamplePublisher and SampleSubscriber applications. The sample apps are used to demonstrate the usage of EMB new topic format for applications written directly on EMB.
    • Use case 10 is a use case having all modules of Universal Wellpad Controller - KPI app, SparkPlug-bridge, Telegraf, DataStore, ZmqBroker, EtcdUI container, MQTT-Bridge, Modbus-master (TCP and RTU), SamplePublisher, and SampleSubscriber.

11.  Universal Wellpad Controller docker images are pushed to the Edge Software Hub, and pulled during the ./edgesoftware install step. Developers can either pull pre-built images directly from DockerHub or locally build the container images. To install manageability, you will be prompted with Yes or No options. Choose the appropriate option to continue with the installation.

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

NOTE: The modules that start with “edgeinsights/”  as a prefix are the EII container images. These module images are pulled from the ESH docker registry.

Summary and Next Steps 

You have successfully installed Universal Wellpad Controller reference middleware. Now you can write your process control application and optimization app using the MQTT-based Publish-Subscribe interface. 

Learn More 

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

• Edge Insights for Industrial
• modconn
• Alita App

Troubleshooting 

Installation Failure 

You might encounter issues during installation if the target system has existing Docker images and containers. 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 Installation Fails

If Docker CE installation failed due to dpkg error while executing pre_requisites.sh file, rerun the sudo ./pre_requisites.sh command step to troubleshoot the issue. This issue occurs due to apt docker-ce package uninstall and reinstall scenario.

Installation Script Fails

If the ./edgesoftware install script fails, you can try the manual installation. For more information, refer to the README files in the IEdgeInsights/uwc folder. 

Support Forum 

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