How to Build a Better Control System Utilizing Microservices and APIs

Factories are making a fundamental shift away from monolithic architectures towards microservices. Individual services can be developed, updated and scaled independently of each other. This can significantly improve the flexibility and adaptability of automation systems. It will be easier to add or change functions without impairing the overall system. REST APIs form the bridges that allow the various software components to communicate and interact with each other. The control system ctrlX CORE from Bosch Rexroth is an example. The system makes it possible to integrate these concepts.

Microservices and APIs play a key role when it comes to designing future automation systems with a view to making processes agile, flexible, and innovative.

Imagine a machine user would like to integrate information about the total running time of their machine into their MES (manufacturing execution system). Traditionally, this requires a communication interface between the IT world (MES) and the OT world (control system). In this case, the OEM must tinker with the machine’s PLC code. With the ctrlX CORE and its REST APIs, this process is much easier. The end user can easily retrieve the required information via the REST API without having to make any adjustments to the control system. This information can then be used in a microservice within the MES.

We caught up with Ralf Opper, business development manager at Bosch Rexroth to get more detail on the value of building a control system utilizing microservices and APIs.

Explain the shift away from monolithic architectures towards microservices.

Ralf Opper: Think about it in a similar way you utilize your smartphone, both for personal and business use. How you use your smartphone is largely depending on the apps you are using. Apps are like microservices independent of the overall system.

A traditional machine controller (PLC, PAC,…) runs on a monolithic architecture. Once the code is written, it is compiled and downloaded as a single file. It limits scalability and future adaptability. A machine controller, in particular, is now tasked with OT and IT tasks. But, by design, it is very limited and certainly wasn’t intended to be compatible within an IT infrastructure.

Let’s take machine or process data transparency as one example. With the ctrlX OS architecture, we can deploy individual apps (microservices) like InfluxDB for example and access any data point that is part of the architecture (fieldbus devices, OPC devices, MQTT,…) and now store it in a time series data base right at the machine level (edge) for data transparency, data tracing and inspect and correlate data points over days, weeks or months. No additional hardware required. The same applies if you want to add remote connectivity - there are 4 different apps we can offer at this time.

How is this a step forward in control system results?

Ralf Opper: The fact that ctrlX OS is not monolithic means that each app is completely containerized. Using the above example of data transparency, this task will not interfere with critical machine or process tasks, even if added later. It is highly flexible as we know from our smart devices. Take the example of different navigation apps on your smartphone. You choose the one that fits your needs best. If a different or better solution becomes available at a later time it is easy to deploy and use.

You can do this in manufacturing as well when embracing frameworks that support microservices to adapt to changing industry trends like IoT, AI, ML or just simpler and more user-friendly machine control to simplify certain tasks. 

We also see reduced hardware inventory levels as a single controller “SKU” can fulfill many different tasks - simply depending on the app’s “solutions” installed.

What are the steps involved in moving from monolithic architectures towards microservices?

Ralf Opper: Switching to a solution provider that offers a microservice framework like ctrlX OS. Take a look here to understand that the vision of an automation world in which competitors become partners and users help to shape the solutions is becoming reality. You see technology partners joining ctrlX OS as their choice of operating system going forward. Co-creation of solutions is the outcome which benefits our customers with best-in-class solutions across the board.

A pillar for this is ctrlX World, an ecosystem we have built around ctrlX OS with already over 90+ partners that provide solutions in form of apps.

Again, think about your smart phone. If it is an iPhone for example, you do not just have Apple apps running on it. The Apple store is full of apps created by partners. Great analogy here too are the navigation apps.

How will this move result in improved flexibility and adaptability of automation systems?

Ralf Opper: You can choose the best tool for the task at hand based on your criteria and use case. For automation use cases this means choices and apps for PLC, Motion, Vision & Sense, Robotics, IoT, AI, ML Connectivity, Security, Safety, and many more.

But it is also opening the toolsets available to build your own apps for your applications. It can be a mixture of traditional PLC coding (in our case via CodeSys) and any higher programming language like C++, Python, or low code language like Blocky and many more.

Modularization becomes easier in form of apps and gives you the flexibility and adaptability required on today’s market and deploy future proof solutions.

This also lays the foundation for new business models like SAAS.

The use cases where our ctrlX CORE is deployed ranges from traditional machine and motion control to IoT gateways, remote connectivity device, web HMI or all these application at once on a single device – simply by installing an app.

For the machine builder, it also means utilizing solutions in the form of apps that, in many cases, do not require any programming but rather a simple setup. This results in better time to market while also raising the bar as far as differentiation to competitor solutions that still use traditional systems.

This could be as simple as providing a web based OEE dashboard with data trending capabilities that can be accessed remotely and exchanges data with an existing MES system. There are apps we recommend in this application use case that allow a customer to develop this solution in a few steps on our ctrlX CORE, with no additional hardware required.

How do REST APIs form bridges that allow the software components to communicate and interact with each other?

Ralf Opper: REST API is used as an internal and external interface to read and write to the Datalayer. The Datalayer is the “central data highway” of ctrlX OS and makes the interaction and data exchange between apps straight forward as it is built into the system.

This enables users for example to communicate with external software architectures like a MES or ERP system.