Ein Software-Monolith stellt die Funktion eines Systems im Gesamten bereit. Bei Ändern eines kleinen Softwareteils ist also die Gesamtfunktion des Systems zu testen. Hieraus ergeben sich hohe Testaufwände und ein entsprechend langsameres Bereitstellen neuer Versionen. Ebenso ist bei einem Update immer die komplette Software bereitzustellen, was entsprechend große Datenpakete zur Folge hat. Ein monolithischer Ansatz hat zwar den Vorteil, schnell sichtbare Ergebnisse zu liefern, da der Vorbereitungsaufwand deutlich geringer ausfällt. Er ist jedoch in Bezug auf Wartung, Flexibilität, Transparenz und Qualität im Nachteil. Betrachtet man die Datentransparenz, ist ein Monolith eine »Black Box«, die sich lediglich schwer verändern lässt.
Die Kombination aus beiden Welten, den Microservices und der monolithischen Architektur, scheint optimal. Eine serviceorientierte Systemarchitektur hat genau das zum Ziel und stellt die Usability beim Kunden in den Fokus. Funktionen werden logisch und aus Anwendersicht sinnvoll gebündelt, die Komplexität reduziert und die Nutzung vereinfacht. Der Kunde kann sich auf sein Verfahrenswissen konzentrieren und muss sich, im Gegensatz zu Microservices, keine Gedanken über komplexe Abstraktionen seiner Funktionen machen.
Das Bündeln von Services in logische Anlagenfunktionen ermöglicht ein schnelles Entwickeln von Anwendungen. Gleichzeitig lassen sich die Vorteile von Microservices hinsichtlich Deployment, Wartung und Qualität nutzen. Die serviceorientierte Architektur wird konsequent im Front End und Back End der Software umgesetzt und bedingt hiermit ein effizientes sowie flexibles Management über das komplette System. Über die definierten Schnittstellen zwischen den einzelnen Services können Entwickler den Datenfluss jederzeit transparent darstellen und einzelne Services gezielt anpassen oder abschalten, beispielsweise um kritische Daten im System zu belassen.
Ein ebenfalls wichtiger Aspekt der serviceorientierten Architektur ist das einfache Parametrieren eines Edge-Computing-Systems. Hier kommt das Prime Tool Set von Schubert System Elektronik (SSE) zum Zug, welches den Zugang zur Systemsoftware erleichtert und so ein schnelles Einbinden des Systems in eine bestehende Infrastruktur ermöglicht. Ebenso sind verschiedene Service Tools verfügbar, die im Servicefall eine schnelle Reaktion des Herstellers ermöglichen.
Wie lässt sich mit einer serviceorientierten Systemarchitektur ein schlüssiges Edge-Computing-Konzept realisieren? Die Multiservice-Plattform (MSP) der Produktmarke »Prime Cube« von Schubert System Elektronik bietet mit einer optimierten Container Engine eine solche Plattform. Sie integriert verschiedene Services auf einer Hardware-Plattform und ermöglicht deren sicheren Betrieb. Services und Funktionen, beispielsweise Maschinen-Konnektoren, werden jeweils in einem Container umgesetzt. Der Container bringt die benötigte Infrastruktur mit, die die Funktion benötigt, um lauffähig zu sein. Somit ist die realisierte Funktion unabhängig von der Software, mit der sie entwickelt wurde. Mithilfe des Einsatzes der Container Engine von Docker sind neben selbst entwickelten ebenfalls Container von Drittanbietern integrierbar. Hiermit eröffnet sich eine weites Anwendungsfeld und es ist möglich, weitere Anlagenfunktionen auf die MSP zu verlagern.
Schubert System Elektronik steht für mehr als 50 Jahre Entwicklungserfahrung im Bereich industrieller Computersysteme – vom Sensor bis in die Cloud, von Hard- und Software über Baugruppen bis zu kompletten Systemen. SSE entwickelt und produziert mit rund 170 Mitarbeitern in Neuhausen ob Eck bei Tuttlingen. Als Teil der Gerhard-Schubert-Unternehmensgruppe gehört die SSE zu einem weltweit aktiven Familienunternehmen.
Von Alexander Matt ist Product Manager Prime Cube, David Bongermino hat die Leitung der Systemsoftware bei Schubert System Elektronik inne.