Since many years Edge Computing is the hot topics when it comes to connecting and creating value with data on the shop floor. The technology that originates from the cloud and IT world is making its way to the edge of the shop floor touching base with OT technology. One of the IT aspects that Edge is introducing to the shop floor is the microservice architecture.
What is a microservice architecture?
Microservice architecture is the idea of splitting an end to
end application into independent subroutines that are loosely coupled with each
other. These subroutines are designed to do only one task, but they accomplish
this one task very well. This way, every specific application is described as a
combination of the subroutines or microservices that are executed in specific
order and configuration.
The independence of the subroutines allows the developers to decouple the deployment and lifecycle of each service. Therefore, each part of the application is updated as soon as it is possible and does not have to wait for development and test of all components involved.
However, for a successful independence between the services, they need to follow a set of rules or contracts. These contracts are essential to ensure compatibility after services are updated and must be followed strictly by all services on the platform. Such contracts can be, i.e. a defined data payload format, application SDK or publisher-subscriber API with standardized naming.
Microservices as apps on Industrial Edge
Traditionally, in an automation environment, you will often encounter holistic “monolithic” applications, that are used to fulfill the use case. Consequently, you install a big application with many functionalities and use only a small portion of provided features to satisfy your desired scenario. Just imagine installing a powerful SCADA system to calculate a simple KPI with a handful of input values from a couple of machines.
Let us dive deeper into a typical digitalization use case.
We want to get data from a SIMATIC S7 controller and compare the values to a
simulation model running on the edge. If we see specific mismatch between the
measured and simulated data, then we want to send an alarm to a technician on
the shop floor who is wearing a smart watch. And finally, we want to send the
data logs to the cloud regularly.
With the microservice architecture on Industrial Edge you
would use a dedicated service for each task. SIMATIC S7 Connector would fetch
the data from the PLC, the LiveTwin application would perform the simulation
and data comparison, the Notifier service is then tasked with sending the alarm
to a wearable device and finally the Cloud Connector application send the logs
into the cloud of our choosing.
Sounds easy, right? But was is the benefit of splitting the
tasks instead of integrating it all into one Edge App, you might ask.
The main benefit comes with the independent deployment and lifecycle of each service. This means that if you install new PLCs or need to support another cloud protocol, then only the specific service that is responsible for the tasks needs to be updated. Also, for the team who is developing the service it is a lot easier to provide a small new feature when they develop and test only the one core functionality the service is designed for. This way, you can adjust you use-case faster and with less engineering effort, thus saving cost.
Service ecosystem on Edge
We have discussed the benefits of a microservice architecture on the Edge, however let us not forget the challenges of a working ecosystem. The beauty of the decoupled services works only if the various services talk to each other as designed, independent of their lifecycle. To meet this challenge on Industrial Edge, there are rules of the ecosystem between the services on how to interact with each other.
For the initial contract in Industrial Edge we chose a MQTT-based Databus which defines the standard way of communication between different services. To ensure the successful interaction between different applications, it is mandatory for every developer to implement an interface to the Databus. However, the payload format can still be application specific.
Additionally, to ensure trust and security between the
different services, the developers must use a central Identity and Access
Management (IAM). This way, the services can authenticate itself to each other using
an independent mechanism that is ensured by platform provider.
In the future, I expect further “IT-like” paradigms and technologies to become established on the shop floor. Most automation functions will be abstracted as independent services that will run on cloud, on PLC or at the edge. Every IT developer, who is familiar with state-of-the-art IT programming languages and microservices, will be able to create applications for automation, thus lowering the entrance barrier. Consequently, this will lead to a multitude of offerings on the market in competition to each other.
In this scenario, Industrial Edge with its comprehensive set
of rules can act as the orchestrator to bring order into the chaos of the
available offerings. The established microservice contracts will allow the
application developers to combine their unique values into a holistic value
proposition that customers are willing to pay for.