DEV Community

Tech Community for Software AG Tech Community

Posted on • Originally published at on

Summary: in practice - An experience report by Phoenix Contact


This article summarizes the key messages of the IoT Developer Event in der Praxis: Ein Erfahrungsbericht von Phoenix Contact which was held on 14th of Feb. 2024 by Phoenix Contact. The event was held in German only. So, if you are a non-German speaker, you can find the key takeaways in English here. If you are a German speaker, you can watch the recording of the video directly on YouTube.

The full slide deck can be downloaded here:

PhoenixContact_Erfahrungsbericht_full.pdf (3.3 MB)

Let’s start with the Introduction.


Never heard about No problem, let me introduce the open-source edge framework to you.


The first step of an IoT project is device integration. Devices are very heterogeneous and support different kinds of IP and non-IP protocols. Especially for the non-IP or non-smart devices, which support any kind of fieldbus or offline protocol, there is an additional gateway needed that connects to the devices and bridges the data to your IoT cloud.

The requirements for the gateways and devices are very different. While the field devices themselves might have a very high data ingestion frequency, a very low processing latency & storage capacity in combination with a proprietary very optimized operating system, the gateway uses in most cases a standard or a customized standard operating system like Linux. This allows flexibility in both directions, to the field devices and to the IoT platforms in the cloud. is focused on such gateways, providing a flexible edge framework to support field device connectivity, allow edge analytics and transport the messages to multi-cloud IoT platforms. But there is much more: Let’s check out what capabilities are offered with the shortly released 1.0.0 version.

1.0.0 Release

With the release of 1.0.0 offers full support of a complete device management stack. This includes firmware & software updates, configuration & log management, remote access, health & device monitoring and support of multiple commands like restart.


Beyond that using you can fully manage your gateways and connected child devices out of the box.

It comes with a multi-cloud support, currently supporting:

  • AWS IoT
  • Azure IoT
  • Cumulocity IoT

With its low footprint, it runs on Linux-operated thin gateways only using ~40 MB of RAM and ~8 MB of disk space. It supports any Linux distribution (also custom ones like yocto) with multiple init systems running on almost all common CPU architectures (X86_64, ARM11, ARM-Corte-A etc.).

It can be easily extended by providing a well-structured plugin concept with already available community plugins like OPC-UA plugin, plugins for Linux package manager (like apt, apk, rpm & snap), a plugin to enable full container management using docker and much more.



Let’s have a look at the architecture. The main component is a Mosquitto MQTT Broker. Here all messages are collected and queued. A well-defined MQTT topic structure API allows data mappings for multiple target clouds, child device support including device management and easy extensions using plugins.

The whole architecture was designed from the beginning to be lightweight, flexible and extensible.

Device Partner Program

At Cumulocity we have a device partner program where device partners can use self-tooling to register themselves and certify their devices. In a device partner portal all (certified) devices are listed including a short summary about the company, device specs and additional assets. Potential customers can search for potential devices and approach the device partner directly.


The certification process is pretty easy. After registration, you get a tenant, where you register your devices. A certification tool will help to identify the current status of features your device supports. There are some minimum requirements that your device needs to fulfill to get the “Certified Device” tag.


Here is the good news: fulfills most of the certification requirements out of the box. Meaning, if you decide to run on your devices, they are very quickly certified.

Now, let’s check out how Phoenix Contact, a device partner of Cumulocity, made their journey to get their devices certified by using and deciding to use

About Phoenix Contact

Phoenix Contact is headquartered in Blomberg, Germany and is a manufacturer of industrial automation, interconnection, and interface solutions. They are a global company with 22.000 employees worldwide.


From Cumulocity’s perspective, Phoenix Contact offers a wide variety of devices and is a global leader in the OT market which makes the combined offering a perfect match. This combination of Cumulocity IT/Cloud expertise and Phoenix Contact OT expertise and devices has been already proven and multiple projects we have implemented together.


Phoenix Contact is an official device partner and lists multiple devices in our device partner portal.




In the field of automation, Phoenix Contact offers a wide range of programmable logic controllers (PLCs), industrial PCs (IPCs) and IO systems. While in the past it was sufficient to program PLC logic and operate it on proprietary real-time capable devices, today more flexibility is required in terms of cloud connectivity and the integration of third-party software. PLCnext Technology opens up PLCs for end customers to flexibly expand their systems and add additional functionality.


Parts of the PLCnext open ecosystem:

  • PLCnext Control – Hardware for the PLCnext Technology ecosystem, which features scalable controllers and is IT secure by design in accordance with IEC 62443.
  • PLCnext Engineer – PLCnext Engineer software platform, which can be extended flexibly and individually with function add-ins.
  • PLCnext Store – Open software store with apps ranging from software libraries for accelerated programming to fully programmed apps.
  • PLCnext Community – Benefit from crowd knowledge, get support, find code examples and stay in touch with Phoenix Contact automation experts.

PLCnext Control Portfolio


The offering of Phoenix Contact Control devices varies from devices that are very closely attached to machines up to gateways and industrial PCs to aggregate and filter machine data to forward them to any cloud. All of them use the open ecosystem approach of PLCnext Technology. On the left in the picture, you see small industrial control units with an ARM Cortex-A processor. When performance is needed, a BPC computer with an Intel i7 processor might be the right choice. In the middle, you see edge gateways, the EPCs which contain an SSD to store data but also bridge the machine data to other systems.

PLCnext Architecture


As an operating system, PLCnext Linux is used which is a customized Linux based on the yocto framework to harden it against the industrial OT requirements in the field. It is real-time capable and minimized so all unnecessary components, that would allow any potential attacks, are removed.

On top, there is the PLCnext Runtime System running which has been opened by supporting multiple interfaces & SDKs to implement custom extensions. The runtime is programmable using the programming language IEC 61131-3, Matlab Simulink, C# or C++. The PLCnext Store offers pre-build apps that can be deployed to the runtime system.

PLCnext store App for

When Phoenix Contact initially started thinking how to integrate to Cumulocity IoT and other cloud platforms. They discussed the use of implementing their own app using the MQTT SmartREST Interface for Cumulocity and others for other clouds or using as a multi-cloud solution.


The decision was quickly made not to invest in any custom app due to effort and time constraints but to use to benefit from the additional functionality like device management capabilities which are offered out of the box. is packaged as an app deployed on the Linux runtime system and containing all relevant components. Another main benefit is that additional functionality is added to over time. In comparison to a custom native app, this new functionality comes out of the box.

If a custom app would have been built, most likely the feature set would have been reduced to just sending measurements because no additional time and resources are available to maintain & develop new functionality.

Another main benefit is that using the device certification process went very smoothly with almost all necessary requirements already met resulting in a certificate in the end. This convinced Phoenix Contact once more that using was the right way to go.


Let’s have a look at what is part of a PLCnext App. A PLCnext App is a SquashFS filesystem container with all required packages installed. In regards to the Mosquitto MQTT Broker, mapper, additional plugins and a bunch of bash scripts are used to perform the mapping between the device capabilities to operations.

image integration

The main task of the integration was to make run on Phoenix Contact devices which don’t use any common package manager like apt or init-system but custom ones. thin-edge was shipped as Debian package in version 0.8.1 which couldn’t be used because systemd was a requirement. So they were repackaged with added custom scripts for the legacy init system.

So for the software management custom install and remove scripts were created. Same for the legacy sysv-init system to start & stop services. is very flexible by allowing defining custom init scripts in a system.toml so this was not a big deal. In 1.0.0 additional functionality has been added which makes it even easier to adapt thin-edge and some scripts might reduced or even removed.


The thin-edge app should be easy to use for end customers. So the capability of thin-edge to create test certificates and upload them to Cumulocity to register the device is used. Before registering the device a Python script is used to collect system information and add them to the device object using a inventory.json where custom, hardware and software fragments can be defined.

Another plugin was developed to handle the software management capabilities of out of the cloud. The plugin concept works here very well as only an executable or script must be available to allow the installation of software, which were provided to list, install or remove software. All the cloud transport of the software installation lifecycle is handled out of the box by, only the local functionality must be provided and integrated to


Support & Feedback

What happens if something is not working as intended? Phoenix Contact started very early with and not everything was working right away which resulted in several issues created in the open-source project. The positive about that is that the project and team are very active: It was always possible to discuss the issues with developers which very often resulted in direct help & solution. Some other things like bugs were tracked and fixed in a very short time period.

Also very positive is the openness of the system to get the correlated debug output and logs to tackle down issues.

Overall this was an excellent development experience with the project team.


Next steps & Outlook

Phoenix Contacts wants to invest in using additional capabilities of Firmware updates are planned using rauc updates which is a tool to support A/B updates for embedded Linux systems. supports this but it must be adopted.

Also, a Certification Authority (CA) should be integrated to issue trusted certificates directly integrated into the device management.



Read full topic

Top comments (0)