Skip to main content

Domain-specific Language for Real-Time Container Deployment

· 5 min read
Marc Fischer
Research Assistant @ ISW Uni Stuttgart
Moritz Walker
Research Assistant @ ISW Uni Stuttgart

Static configurations and slow adjustments to changing requirements characterise today's production systems. In order to be able to deal with variable external influences, these systems must become more flexible. Modular, virtualised real-time architectures, which are implemented as distributed real-time systems, are a fundamental building block for making automation systems more flexible from a software point of view. However, the additional modularity and flexibility come at the cost of greater complexity. In order to enable developers to design and manage robust systems with regard to real-time properties, a tool has been developed at the ISW based on a domain-specific language, which allows the analysis of real-time behaviour as well as the automated real-time orchestration of container-based control applications with Kubernetes and Docker-Compose. This article was first released in SPS-MAGAZIN in German.

Intro

SOAs are an architectural style for realising modular, distributed systems in which components, referred to as services, provide each other with functionalities as services. A cohesive application is a combination of several services that cooperate to achieve a specific goal. The fact that the individual services can also be deployed independently means that software development and updates can be carried out in a targeted manner and in shorter cycles than with monolithic systems such as the classic programmable logic controller. Only individual services need to be updated, not the entire system. Continuous deployment methods can be used for updates and initial deployment. This means that the individual containers must be provided to the target systems automatically and it must be possible to update them at runtime. This is referred to as orchestration. A number of orchestration approaches have already been developed for special real-time SOAs. The main disadvantage they have in common is that strict conditions are set for the design of individual services. Therefore, modules developed for different SOAs, such as the Robot Operating System and IEC 61499, are not interoperable. To make the control software more flexible, a mechanism is needed with which heterogeneously designed control containers can also be orchestrated. Such a solution has been developed at ISW.

Analysis-driven real-time orchestration

Basic concept of the orchestration solution for real-time containers. The realisation was implemented as a web IDE.

Figure 1: Basic concept of the orchestration solution for real-time containers. The realisation was implemented as a web IDE [1].

Figure 1 provides an overview of the key information that the software components involved in real-time orchestration require. The lifecycle of a distributed real-time system (DRTApp) begins with a description of the execution model used and the composition of the DRTApp from individual services (containers). Subsequently, a scheduler, which can be integrated either into a real-time orchestrator or an external tool, assigns scheduling parameters to the services encapsulated in containers. To draw conclusions about the real-time behaviour of the DRTApp to be deployed, specific validators and user-defined validators associated with the scheduling model are used. Finally, service configuration files and deployment descriptions are generated for the runtime environment of a specific type of deployment unit. Examples of supported runtime environments are Kubernetes and Docker for containers. The DRTApp description is meaningful enough to describe services and their communication connections via a common communication system such as time-sensitive networking. In addition, framework conditions, QoS requirements and simple resource requirements of services as well as their counterparts, the provided resources of computing nodes, can be described. In addition to a graphical modelling language, a textual domain-specific language (DSL) is also available to the user for modelling services and applications.

Implementation of the analysis and orchestration tool

The DSL grammar is written in the textX metalanguage. Communication links and flows are modelled as edges, while compute nodes, CPUs, tasks and services are modelled as graphical nodes. The graphical modelling language is based on the Graphical Language Server Platform (GLSP), an open-source framework for creating diagram editors. A Visual Studio Code extension was chosen as the platform for the graphical editor. This allows the user to switch seamlessly between the textual and graphical representations of the model.

Application in a real shop floor

Screenshot of the Visual Studio Code extension for orchestrating and analysing real-time applications. Here, the communication chain of a CNC core is analysed. After successful analysis, the specified real-time system is deployed at the push of a button via Kubernetes. Figure 2: Screenshot of the Visual Studio Code extension for orchestrating and analysing real-time applications. Here, the communication chain of a CNC core is analysed. After successful analysis, the specified real-time system is deployed at the push of a button via Kubernetes.

In a traditional factory, each machine has its own computing hardware and a dedicated control system. One advantage of cloud-based control technology is that services can be executed on any computer hardware. In the ISW research factory application, containerised PLCs, CNC kernels and robot controllers are orchestrated on several edge nodes using the tool described. The setpoints and actual values of three machines in the machine factory – a three-axis and a five-axis milling machine, as well as a six-axis robot – are transmitted in real time via Time-Sensitive Networking. With the help of the presented solution, it can be ensured that the necessary end-to-end latencies are guaranteed.