Summary

In typical industrial applications for control & automation systems there are many constraints that prevent accepted best practices for updates, upgrades, patch and lifecycle management being utilized. The lifecycles on equipment and software have much longer expected lifespans. Updates and patches are reserved for high-risk potential and high impact bugs or vulnerabilities. Upgrades are reserved for when they have a clear efficiency, ROI, or support ability advantage over the existing installed systems.

None of these constraints have prevented the constant demands for data availability as most industries have seen over the last couple decades. This results in defense in depth, network isolation, layering and deeper risk analysis & impact studies being the norm for these applications. This typically makes the maintainers and system integrators of these systems prefer to operate in the typical portfolio of high hardware cost, high license cost, custom software, and hardware lock-in options available already in the market.

Utilizing a suite of hardware and software from Portainer’s Strategic Partners, this demo covers an approach that decouples the collection of data and its transmission to exterior systems from the existing control systems. Multiple options to interface to either existing Field/Remote Input/Output hardware, or additional hardware to be deployed on equipment where existing sensors may not exist.

This parallel approach removes the burden of high costs associated with modification to the existing control systems. It addresses the normal acceptances of limitations on patch, update, upgrade and lifecycle replacement of both hardware and softwareby allowing this independent data path that can keep pace with any updates or upgrades that could be required in the future with no impact on the control system itself. It also allows for a security posture that align with EnterpriseIT systems.

Strategic Partners

References utilized in configuration

‍
[Cedalo MQTT Platform documentation]
[Portainer.io documentation]
[Softing edgeConnector documentation]
[Wago technical documentation]  
[Modbus Application Protocol Specification V1.1b3]

Hardware components

Wago 750-8213 -PFC200 arm64 field compute bus coupler - field based container engine platform

Wago 750-362 - WagoModbusTCP bus coupler

•       750-439 - 8-channel digital input

•       750-537 - 8-channel digital output

•       750-496 - 8-channel analog input 0/4-20mA

•       750-563 - 2-channel analog output 0/4-20mA/ 6-18VDC 16bit

•       750-600 - End termination module

System Diagram

Deployment Process

NOTE: deployment example provided assumes existing network connectivity between hosts and will not cover certificates, keys, or encryption outside of any portion that is deployed by default in this manner.

Hardware Preparation

Ensure any additional hardware devices at the edge are updated to the latest firmware prior to starting, in this case the latest firmware for both the PFC200 &750-362 Modbus coupler were performed, but if interfacing to existing hardware the Modbus device could be excluded from updating.

Wago PFC devices are able to be deployed as runtime platforms for more typical Codesys PLC code, or within their Web-based Management UI they can be switched to function as a docker container engine host, this is what we will be utilizing as a field compute device.

From the standard management interface for the Wago 750-362 Modbus coupler or similar device verify that the modbusTCP/UDP protocols are enabled and what port they are configured for currently.

If during this process the edge compute isa new device it can be onboarded into the Portainer environment via theEnvironments -> Auto Onboarding Script Creation tool to configure a script to be run on the edge device to deploy ether the Standard Edge Agent or theEdge Agent Async. Detail about this feature can be viewed at a prior blog poston our site; Portainer Edge –Bulk Onboarding.

Portainer managed server environment

Softing License Server

The first of the two stacks to be deployed as part of this process will be the layer functioning as the server or cloud instance. This is to allow for the Softing license server and Cedalo Pro Mosquitto MQTT broker to already be up and running when the edge stack is configured.

[SoftingedgeConnector License Server]

The Softing license server container HostId that is generated on initial deployment can be viewed within the 'logs' quick action button on the respective container. This is required to setup the Softing floating license on the server.

Cedalo Management Platform, Pro Mosquitto & InfluxdbBridge

NOTE: Ensureto follow the latest instructions available depending on what version of theCedalo Management platform is utilized. For the purposes of this demo system,we are using version 3.1 to enable the bridge features within the CedaloManagement center and management of the Mosquitto Pro MQTT  broker via API.

As indicated within the Cedalo platform, the library associated with the bridge that will be utilized must be uncommented within the mosquitto.conf file before theManagement center can make changes to its associated settings.

Once the management platform is up and running, verify that the correct addressing, credentials, and any required encryption or security settings are configured to enable communication with the broker via the web interface.

 With the new features included in 3.1, the bridge connection can be configured from within the web interface either by elements within the UI or directly via the JSONeditor tab.

An example of theJSON formatted configuration including the connection section, topic Mappings, and beginning of the schemaMappings section.

{

   "connections": [

       {

           "name":"influxdb-edgeconndemo",

           "connection": {

               "driver":"influxdbv2",

               "hostname":"influxdb",

               "port": 8086,

               "database":"mqtt_data",

               "credentials": {

                   "token":"INFLUXDB_AUTHTOKEN"

               },

               "organization":"portainer",

               "debug": false

           },

           "topicMappings": [

               {

                   "name":"wago-modbus-mapping",

                   "schemaMapping":"wago-750362-schema",

                   "target":"modbus_data",

                   "mqttTopics": [

                      "softing/wago/modbus/#"

                   ]

               }

           ]

       }

   ],

   "schemaMappings": [

       {

           "name":"wago-750362-schema",

           "mapping": [

               {

                   "source":"[payload][client_id]",

                   "target":"client_id",

                   "targetType":"tag"

               }

           ]

       }

   ]

}

Edge Software deployment & configuration

Softing edgeConnector - Modbus

The second stack deployed contains the Softing edgeConnector Modbus container.

Example edgeConnector docker-compose file:

services:

   edgeconnector:

       image:softingindustrial/edgeconnector-modbus

       container_name: edgeconn-demo-connector

       ports:

           - 1443:443

       volumes:

           - edge_connector_config:/config

           - edge_connector_mqtt:/mqtt

       restart: unless-stopped

volumes:

 edge_connector_config:

 edge_connector_mqtt:

Once the SoftingedgeConnector container is deployed, navigate to its web interface and login using the default credentials (admin/admin).

For this application there are 4 main areas we need to configure within the edgeConnector; License server, Modbus, MQTT Connections, and MQTT publisher.

To configure the Softing license server visit the General Settings -> Licenses -> LicenseServer Configuration from the left side menus.

The next configuration to complete is the Modbus specific configuration. From here the end point will be defined, any required credentials and the IO mapping that will need to be created. Below is an example using information from the Wago 750-362Manual in section 11.2 Modbus functions, the Modbus Mapping section of the coupler's web interface and the Softing Modbus guide & Syntax information in the below links.

[Softing edgeConnector Modbus guide]

[Softing edgeConnector Modbus syntax]

Modbus interface specific address spaces can be created and assigned from this location also to segregate or combine endpoint data as desired. An example of the mapping is also provided below. This file can be a plain .txt file when uploaded via the Softing edgeConnector UI

Example IO Mapping:

NOTE: For compatibility with parsing performed by Cedalo, InfluxDB bridge default characters used by Softing within the MQTT payload template require adjustment.

# WAGO 750-362modules

# I/O in physicalorder of mounting

# actual modbusaddressing orders more complex models earlier in address structure

‍

# ===== MODULE 1: 750-439 (8DIO/DIA) - Position 01

# Digital Inputs

m01ch01di=IRX8.0

m01ch02di=IRX8.1

m01ch03di=IRX8.2

m01ch04di=IRX8.3

m01ch05di=IRX8.4

m01ch06di=IRX8.5

m01ch07di=IRX8.6

m01ch08di=IRX8.7

m01ch08di=IRX8.8

m01ch08di=IRX8.9

m01ch08di=IRX8.10

m01ch08di=IRX8.11

m01ch08di=IRX8.12

m01ch08di=IRX8.13

m01ch08di=IRX8.14

m01ch08di=IRX8.15

‍

# ===== MODULE 2:750-537 (8DO/DIA) - Position 02

# Digital Outputs

m02ch01do=HRX515.0

m02ch02do=HRX515.1

m02ch03do=HRX515.2

m02ch04do=HRX515.3

m02ch05do=HRX515.4

m02ch06do=HRX515.5

m02ch07do=HRX515.6

m02ch08do=HRX515.7

‍

# ===== MODULE 3:750-496 (8AI 0/4-20mA) - Position 03

# Analog InputValues

m03ch01ai=HR0

m03ch02ai=HR1

m03ch03ai=HR2

m03ch04ai=HR3

m03ch05ai=HR4

m03ch06ai=HR5

m03ch07ai=HR6

m03ch08ai=HR7

‍

# ===== MODULE 4: 750-563 (2AO 0-20mA) - Position 04

# Analog OutputValues

m04ch01ao=HR512

m04ch02ao=HR513

After finishing theModbus configuration page next will be the Connectivity -> MQTT -> MQTTConnections & Publisher sections.

Here the typical MQTT interface settings are required that would be specific to the deployed use case. For this demo we are just using basic authentication to the Cedalo broker using dynamic_security when deploying the server stack.

Once our connection is successful, we can move on to the publisher section. From here we can select the connection we just created and name the request as well as MQTT specific payload handling; the main setting we will focus on is the payload definition.

Depending on the address space selection that was made when setting up the Modbus connection, expand the tree associated previously to the object level and the modbusconnection name should be a listed folder. The folder can be double clicked to add all child points or expanded again to view and add individual items to the payload.

Once completed thedatapoints can be verified to the Cedalo broker either through external client(MQTT explorer or similar) or by utilizing the tree explorer from within theCedalo Management center directly.

NOTE: For this demo the Cedalo influxdb bridge being utilized currently cannot parse"." within the payload that Softing utilizes by default. Example of payload adjustment below:

{

   "topicName":"@topicName@",

   "clientId":"@clientId@",

   "timestamputc":"@timestamp.utc@",

   "timestamplocal":"@timestamp.local@",

   "m01ch01di":"@edgeconndemo/Objects/750362/m01ch01di/value@",

   "m01ch02di":"@edgeconndemo/Objects/750362/m01ch02di/value@",

   "m01ch03di":"@edgeconndemo/Objects/750362/m01ch03di/value@",

   "m01ch04di":"@edgeconndemo/Objects/750362/m01ch04di/value@",

   "m01ch05di":"@edgeconndemo/Objects/750362/m01ch05di/value@",

   "m01ch06di":"@edgeconndemo/Objects/750362/m01ch06di/value@",

   "m01ch07di":"@edgeconndemo/Objects/750362/m01ch07di/value@",

   "m01ch08di":"@edgeconndemo/Objects/750362/m01ch08di/value@",

   "m02ch01do":"@edgeconndemo/Objects/750362/m02ch01do/value@",

   "m02ch02do":"@edgeconndemo/Objects/750362/m02ch02do/value@",

   "m02ch03do":"@edgeconndemo/Objects/750362/m02ch03do/value@",

   "m02ch04do":"@edgeconndemo/Objects/750362/m02ch04do/value@",

   "m02ch05do":"@edgeconndemo/Objects/750362/m02ch05do/value@",

   "m02ch06do":"@edgeconndemo/Objects/750362/m02ch06do/value@",

   "m02ch07do":"@edgeconndemo/Objects/750362/m02ch07do/value@",

   "m02ch08do":"@edgeconndemo/Objects/750362/m02ch08do/value@",

   "m03ch01ai":"@edgeconndemo/Objects/750362/m03ch01ai/value@",

   "m03ch02ai":"@edgeconndemo/Objects/750362/m03ch02ai/value@",

   "m03ch03ai": "@edgeconndemo/Objects/750362/m03ch03ai/value@",

   "m03ch04ai":"@edgeconndemo/Objects/750362/m03ch04ai/value@",

   "m03ch05ai":"@edgeconndemo/Objects/750362/m03ch05ai/value@",

   "m03ch06ai":"@edgeconndemo/Objects/750362/m03ch06ai/value@",

   "m03ch07ai":"@edgeconndemo/Objects/750362/m03ch07ai/value@",

   "m03ch08ai":"@edgeconndemo/Objects/750362/m03ch08ai/value@",

   "m04ch01ao":"@edgeconndemo/Objects/750362/m04ch01ao/value@",

   "m04ch02ao":"@edgeconndemo/Objects/750362/m04ch02ao/value@"

}

Which results in aMQTT payload similar to below.

{

   "topicName":"softing/wago/modbus/750362/",

   "clientId": "750362",

   "timestamputc": "08/29/202501:32:56 PM",

   "timestamplocal":"08/29/2025 01:32:56 PM",

   "m01ch01di": true,

   "m01ch02di": false,

   "m01ch03di": false,

   "m01ch04di": false,

   "m01ch05di": false,

   "m01ch06di": false,

   "m01ch07di": false,

   "m01ch08di": false,

   "m02ch01do": false,

   "m02ch02do": false,

   "m02ch03do": false,

   "m02ch04do": true,

   "m02ch05do": true,

   "m02ch06do": true,

   "m02ch07do": false,

   "m02ch08do": false,

   "m03ch01ai": 5560,

   "m03ch02ai": 3,

   "m03ch03ai": 3,

   "m03ch04ai": 3,

   "m03ch05ai": 3,

   "m03ch06ai": 3,

   "m03ch07ai": 3,

   "m03ch08ai": 3,

   "m04ch01ao": 0,

   "m04ch02ao": 0

}

Solution Process improvements with Strategic Partners

Portainer is constantly working with our strategic partners to develop solution demonstrations, best practices and improvement proposals for existing solutions. In support of this solution approach all components are in various stages to directly improve the potential for automation and efficiency with this use case to further explore the simplification of of edge data availability while maintaining security and repeatability without solutions requiring custom engineering work for each deployment.