SOAs sind ein Architekturstil zur Realisierung modularer, verteilter Systeme, in denen Komponenten, die als Services bezeichnet werden, einander Funktionalitäten als Dienste zur Verfügung stellen. Eine kohäsive Anwendung ist dabei eine Kombination mehrerer Services, die kooperieren, um ein bestimmtes Ziel zu erreichen. Dadurch, dass zusätzlich ein unabhängiges Deployment der einzelnen Services möglich ist, erfolgen die Softwareentwicklung und Updates zielgerichtet und in kürzeren Zyklen als bei monolithischen Systemen wie der klassischen speicherprogrammierbaren Steuerung. Es müssen lediglich einzelne Services und nicht das Gesamtsystem aktualisiert werden. Zur Umsetzung von Updates und zum initialem Deployment können Methoden des kontinuierlichen Deployments eingesetzt werden. Das heißt, die einzelnen Container müssen automatisiert auf Zielsystemen bereitgestellt und zur Laufzeit bei Updates aktualisiert werden können. Das wird als Orchestrierung bezeichnet. Für spezielle Echtzeit-SOAs wurden bereits einige Orchestrierungsansätze entwickelt. Diesen ist vor allem der Nachteil gemein, dass dem Design einzelner Services strenge Rahmenbedingungen gesetzt sind. Deshalb sind Module, die für unterschiedliche SOAs, wie z.B. das Robot Operating System und die IEC61499, entwickelt wurden, nicht interoperabel. Zur Flexibilisierung der Steuerungssoftware wird also ein Mechanismus benötigt, mit dem auch heterogen gestaltete Steuerungscontainer orchestriert werden können. Eine solche Lösung wurde am ISW entwickelt.
Analyse-getriebene Echtzeitorchestrierung
Der Lebenszyklus eines verteilten Echtzeitsystems (DRTApp) beginnt mit einer Beschreibung des verwendeten Ausführungsmodells und der Komposition der DRTApp aus einzelnen Services (Containern). Anschließend weist ein Scheduler, der entweder in einen Echtzeitorchestrator oder ein externes Tool integriert sein kann, den in Containern gekapselten Services, Scheduling-Parameter zu. Um Rückschlüsse auf das Echtzeitverhalten der bereitzustellenden DRTApp zu ziehen, werden spezifische, mit dem Scheduling-Modell verbundene Validatoren und benutzerdefinierte Validatoren verwendet. Schließlich werden Service-Konfigurationsdateien und Deployment-Beschreibungen für die Laufzeitumgebung einer bestimmten Art von Deploymenteinheit generiert. Beispiele für unterstützte Laufzeitumgebungen sind Kubernetes und Docker für Container. Die DRTApp-Beschreibung ist hierbei aussagekräftig genug, um Dienste und deren Kommunikationsverbindungen über ein gemeinsames Kommunikationssystem wie Time-sensitive Networking zu beschreiben. Darüber hinaus können Rahmenbedingungen, QoS-Anforderungen und einfache Ressourcenanforderungen von Diensten sowie deren Gegenstücke, die bereitgestellten Ressourcen von Rechenknoten beschrieben werden. Neben einer graphischen Modellierungssprache steht dem Anwender auch eine textuelle domänenspezifische Sprache (DSL) zur Modellierung der Services und Anwendungen zur Verfügung.
Umsetzung des Analyse- und Orchestierungswerkzeugs
Die Grammatik der DSL ist in der Metasprache textX geschrieben. Kommunikationsverbindungen und -flüsse werden als Kanten modelliert, während Rechenknoten, CPUs, Aufgaben und Dienste als grafische Knoten modelliert werden. Die grafische Modellierungssprache basiert auf der Graphical Language Server Platform (GLSP), einem Opensource-Framework für die Erstellung von Diagrammeditoren. Als Plattform für den grafischen Editor wurde eine Visual-Studio-Code-Erweiterung gewählt. Dadurch kann der Benutzer nahtlos zwischen der textuellen und der grafischen Darstellung des Modells wechseln.
Anwendung in der Stuttgarter Maschinenfabrik
In einer klassischen Fabrik hat jede Maschine ihre eigene Computing-Hardware und ein dediziertes Steuerungssystem. Ein Vorteil der Cloud-basierten Steuerungstechnik ist, dass Dienste auf beliebiger Rechnerhardware ausgeführt werden können. Im Anwendungsfall der Forschungsfabrik des ISW werden containerisierte SPSen, CNC-Kernel und Robotersteuerungen auf mehreren Edge-Knoten mit Hilfe des beschriebenen Werkzeugs orchestriert. Dabei werden die Soll- und Istwerte an drei Maschinen der Maschinenfabrik, eine Dreiachs- und eine Fünfachs-Fräsmaschine sowie einen Sechsachsroboter, in Echtzeit über Time-Sensitive Networking übermittelt. Mit Hilfe der vorgestellten Lösung kann hier sichergestellt werden, dass die notwendigen End-zu-Ende-Latenzen eingehalten werden.
