Vom Modell zu kontinuierlich aktualisierbaren Maschinen und Anlagen

Der Wandel hin zu einer zunehmend vernetzten Industrie, die sich gleichzeitig schnell und flexibel an neue Gegebenheiten anpassen lassen muss, stellt Anlagen- und Maschinenbauer vor einige Herausforderungen. Wie können Entwickler mit dieser Dynamik Schritt halten? Eine Möglichkeit ist die modell­basierte Entwicklung. Der Beitrag gibt Antworten auf die wichtigsten Fragen.

Software wird zu einem immer wichtigeren Bestandteil von Maschinen und Anlagen in der Industrie. Für deren Steuerung werden Prozessoren und Sensoren verbaut, die unter­schiedlichste Daten erzeugen und die sich gewinnbringend für das Industrial Internet of Things (IIoT), für Machine Learning (ML) sowie für die vorrausschauende Wartung nutzen lassen. Somit können Ausfallzeiten vermieden und die Nutzungsdauer erhöht werden. Aber auch Prozesse und Lieferketten lassen sich weiter rationalisieren beziehungsweise optimieren und der Energieverbrauch kann reduziert werden.

Gleichzeitig sollen sich Maschinen aber auch immer häufiger modular kombinieren lassen und über ihre Lebensdauer hinweg mit Software-Updates, neuen Funktionen und neuer Hardware aufrüstbar sein. Das ist gerade für die aufstrebende Outcome Economy – auch bekannt als „Machinery-as-a-Service“ – eine zentrale Voraussetzung. Diese Komplexität erschwert es, Maschinen in möglichen Konfigurationen ausgiebig zu testen und für jede auch kleinere Iteration zu wiederholen. Dadurch erhöht sich erheblich das Risiko von Fehlern und Verzögerungen bei der Inbetriebnahme vor Ort. Gleichzeitig kann dies kostspielige Ausfallzeiten für den Betreiber bedeuten, und seitens Hersteller zu erhöhten und ungeplanten Kosten führen.

Ausführbare Modelle über den gesamten Lebenszyklus hinweg

Dieser Herausforderung lässt sich mit der konsequenten Nutzung von Modellen während des gesamten Lebenszyklus einer Maschine oder Anlage begegnen. Bei diesem Ansatz, der auch als modellbasierte Entwicklung (Model-Based Design) bezeichnet wird, arbeiten Ingenieure mit ausführbaren Modellen von Hardware und Software, die sie während der Entwicklung immer weiter verfeinern. Im Rahmen ihrer Simulation lässt sich das Zusammenspiel von Mechanik, Maschinen-Software sowie den verarbeiteten Gütern in verschiedensten Szenarien testen, verifizieren und optimieren. Dazu muss kein physischer Prototyp vorhanden sein, mit dem Vorteil, dass im Rahmen der Simulation Tests unter Bedingungen möglich sind, die sich mit einer realen Maschine etwa wegen des damit verbundenen Risikos, Zeitaufwands oder der Kosten nicht reproduzieren lassen.

Modelle bieten aber noch weitere Möglichkeiten. Durch Codegenerierung wird aus ihnen direkt die später auf der Maschine laufende Software passend zur verwendeten Steuerungs-Hardware erzeugt. Das spart Zeit und vermeidet durch manuelle Programmierung entstehende Fehler. Darüber hinaus sind diese Modelle auch nach der Fertigstellung einer Maschine nützlich. Sie können etwa als digitale Zwillinge einer realen Anlage dienen und anhand von Betriebsdaten frühzeitig mögliche Defekte und Fehlfunktionen anzeigen. Auch lassen sie sich für kontinuierliche Updates von Hardware und Software einsetzen. Die hier beschriebenen Prozesse konzentrieren sich vor allem auf die Codegenerierung und die zentrale Rolle, die ihr in künftigen Entwicklungs-Workflows zukommt.

Hardware und Software parallel ­modellieren

Beim Aufbau von Modellen einer Anlage – der Regelstrecke – kommt es darauf an, dass deren Fähigkeiten und Genauigkeit sorgfältig gegeneinander abgewogen sind. Welcher Detaillierungsgrad erforderlich ist, hängt weitgehend von der Art der Anlage und der erforderlichen Regelstrategie ab. Je aufwändiger die Simulation, desto länger dauert der Modellaufbau und desto mehr Rechenleistung erfordert sie.

Ein praktischer Weg zum Aufbau von Modellen mit mittlerem Detailniveau besteht in der Nutzung von 3D-CAD-Dateien. Modellierungswerkzeuge wie Simscape können diese importieren. Als Beispiel ist in Bild 01 in der Mitte ein Roboterarm dargestellt. Seine importierten CAD-Baugruppen enthalten die vollständige Geometrie sowie die Massen, Trägheiten und Gelenke des echten Arms mit dessen Antrieben. Durch Kombination solcher Einzelmodelle lassen sich vollständige Anlagen entwickeln und aufbauen, deren Simulation das Verhalten zuverlässig wiedergibt. Dazu ist keinerlei Steuerstrategie erforderlich.

Auch die Steuerungs- und Logik-Software lassen sich weit­gehend unabhängig von der Hardware entwickeln. Dazu werden entweder vereinfachte Anlagenmodelle an sie angebunden oder lediglich Signale erzeugt, die von der realen Anlage zu erwarten sind. Je detaillierter Hardware- und Software-Modelle ausge­arbeitet sind, desto genauer bilden sie das Verhalten der fertigen Maschine ab und können miteinander kombiniert werden.

Diese Entwicklungsphase nennt man Desktop-Simulation. In ihr findet bereits ein Großteil der grundlegenden Hardware- und Software-Tests sowie der Verifikation statt. Gleichzeitig stellt das Zusammenführen von Hardware- und Software-Modellen die erste Phase einer virtuellen Inbetriebnahme dar, wie in Bild 02 zu sehen. Durch diese Parallelisierung der Entwicklung wird nicht nur Zeit gespart (gestrichelte Pfeile), sondern es werden auch mögliche Fehler früher entdeckt und direkt dort korrigiert, wo sie entstehen. Die so aufgebauten Hardware- und Software-Modelle stellen gemeinsam eine bereits weitgehend ausgereifte Maschine dar, die nun gebaut werden kann.

Codegenerierung auf Knopfdruck

Eine jetzt noch zu nehmende Hürde im Entwicklungsprozess ist die Übersetzung der Steuerungs- und Logik-Algorithmen in Programmcode. Als Sprache dafür kommen beispielsweise C/C++, HDL sowie Strukturierter Text und Kontaktpläne nach ICE 61131-3 in Frage. Die manuelle Übersetzung, Fehlerbereinigung und Optimierung dieses Codes ist sowohl aufwändig als auch fehleranfällig. Der große Vorteil von vorhandenen Simulationsmodellen besteht darin, dass sich aus ihnen der Code praktisch auf Knopfdruck generieren lässt. Durch Wahl der gewünschten Zielplattform wird er automatisch an verschiedenste Entwicklungsumgebungen (IDEs) der Steuerungshersteller angepasst. Welche Sprache dabei eingesetzt wird, ist sekundär. Ein weiterer Vorteil der automatischen Codegenerierung ist, dass der Code für unterschiedliche Zielplattformen erzeugt werden kann und somit ein Wechsel auf eine andere Plattform leichter ist.

Diese Codegenerierung wird durch geeignete Tools wie etwa den Simulink Coder für C/C++ Code oder den PLC Coder gesteuert, der die Codegenerierung für Strukturierten Text und Kontaktpläne nach IEC 61131-3 beherrscht. Dieser lässt sich direkt an die Entwicklungsumgebungen unterschiedlicher Hersteller anbinden, zum Beispiel Automation Studio von ABB / B&R, TwinCAT von Beckhoff Automation oder TIA Portal / Step7 von Siemens, sodass Steuerungsentwickler einfach in ihrer vertrauten Umgebung weiterarbeiten können.

Die Plattformunabhängigkeit von Simulationsmodellen stellt einen nicht zu unterschätzenden Vorteil dar. Sind Maschinenbauer etwa auf Märkten mit unterschiedlichen Präferenzen für Steuerungshersteller aktiv, müssen sie die jeweilige Software nicht neu schreiben oder anpassen. Sie wird schlicht durch Wahl des Targets neu generiert. Zudem kann später jederzeit mit geringem Aufwand auf eine andere Plattform gewechselt werden. Dies ist erforderlich, wenn es zu Bauteil- oder Baugruppenabkündigungen kommt oder wenn aufwändigere Berechnungen hinzukommen, die FPGAs, SoCs oder ASICs benötigen. Einmal ent­wickeltes geistiges Eigentum lässt sich praktisch universell weiternutzen. Das ermöglicht die Flexibilität, eine optimale Hardware-Lösung für die jeweilige Applikation zu erhalten.

Virtuelle Anlage gegen reale ­Steuerung: Hardware-in-the-Loop

Mit der Generierung des Softwarecodes ist die Entwicklung noch nicht beendet. Es muss geprüft werden, ob sich die Steuerungs-Software auch auf der später eingesetzten SPS unter Echtzeit­bedingungen so verhält, wie in der Simulation. Anstatt gegen die Maschine – die vielleicht noch gar nicht gebaut ist – testet man die Regelung gegen eine Maschinensimulation. Dazu wird die Software generiert, auf die SPS überspielt und gegen ein ebenfalls in Echtzeit ausgeführtes Regelstreckenmodell getestet. Dieser Schritt wird Hardware-in-the-Loop (HiL) genannt und ist in vielen Branchen fest etabliert und bewährt.

Die Erzeugung eines echtzeitfähigen Regelstreckenmodells kann etwa mit Simulink Real-Time in Kombination mit einem Speedgoat-Rechner erfolgen. Hierzu werden lediglich die benötigten E/A-Treiber und die Speedgoat Library in das Modell eingefügt, das danach auf Knopfdruck in C-Code umgewandelt und auf den Speedgoat-Rechner heruntergeladen und ausgeführt wird. Der Entwicklungsrechner mit Matlab/Simulink als Entwicklungsumgebung (IDE) kann während des gesamten Prozesses mit der SPS verbunden bleiben. Auf ihm lassen sich Daten, Sig­nale und Zustände der Steuerung live überwachen und protokollieren. Wieder arbeiten Entwickler in einer vertrauten Umgebung, was die Beurteilung der Simulationsergebnisse erleichtert. Neben der eingesparten Zeit und Personalkosten ermöglicht das Testen gegen eine virtuelle Regelstrecke auch die Reproduktion von Fehlerbedingungen, die in der Realität Anlage oder Personal gefährden würden.

Simulationsbasierte Tests sparen Zeit

Der Hardware-in-the-Loop-Schritt (HiL) stellt sicher, dass die Software auch auf der realen SPS so arbeitet, wie sie soll. Auftretende Fehler werden unmittelbar im Modell behoben und der Code direkt innerhalb der HiL-Umgebung erneut generiert, was eine rasche ­Iteration ermöglicht. Zudem können Steuerungsparameter vom Entwicklungsrechner aus live angepasst werden. Neben dem Debugging kann also bereits eine Voroptimierung der Steuerung ohne Maschinen-Hardware erfolgen. Bei einer konventionellen Arbeitsweise wäre dies erst nach der physischen Integration möglich.

Simulationsbasierte Tests lassen sich automatisieren und ohne Eingriff durch den Ingenieur ausführen, beispielsweise mit Simulink Test. Hiermit lassen sich auch Regressionstests durchführen. So wird sichergestellt, dass Modifikationen wie bei einem Software-Update keine neuen Fehler verursachen. Zudem erlauben sie die Einbindung in Workflows für die Continuous Integration/Continuous Deployment (CI/CD), also das Verschieben von Code von einem Entwicklungs- und Bereitstellungsschritt in einen anderen. Dieser Prozess wird auch für Maschinenbauer immer wichtiger. Besonders nützlich ist dies außerdem für Maschinen, die in unterschiedlichen Konfigurationen angeboten werden. Varianten von Hardware und Software können – weitgehend automatisiert – im Modell durch Auswahl von Modulen zusammengestellt, in Code umgewandelt, getestet und die Ergebnisse protokolliert werden. Vergleichbare Testreihen wären mit physischen Maschinen aus Zeit-/Kostengründen kaum machbar.

Datenfluss: Vorteile einer disziplinübergreifenden Entwicklung

Auch im Maschinenbau haben sich die Produktzyklen erheblich verkürzt. Kunden wünschen sich flexibel durch Software- und Hardware-Updates auf neue Aufgaben und Materialien umrüstbare Maschinen. Bereits heute sind zudem viele Maschinen in größere Netzwerke integriert und liefern beispielsweise Daten an Edge-Geräte oder für die Unternehmens-IT. Künftig werden aber ganze Maschinenflotten Teil des Industrial Internet of Things (IIoT) sein. Sie werden zudem wegen der größeren Zahl von Sensoren und Prozessoren erheblich mehr Daten produzieren als heute. Bereinigte Flottendaten fließen beispielsweise an den Betreiber oder Hersteller zurück und bilden dort Erfahrungswerte, auf dessen Grundlage etwa Energieverbrauch und Zuverlässigkeit von Maschinen generell oder für bestimmte Umgebungen optimiert werden können. Daneben dienen diese Daten zur kontinuierlichen Weiterentwicklung von Anlagen und Software.

Dies ähnelt dem in der Softwareindustrie etablierten DevOps, einer zyklischen Verzahnung von Entwicklung (Development) und Betrieb (Operation) eines Produkts, wie in Bild 03 dargestellt. Die Arbeit der Entwickler endet hier nicht mit der Auslieferung des Produkts. Betriebsdaten (gelber Pfeil „Continuous Telematics“) fließen an den Hersteller zurück und werden ausgewertet und für Aktualisierungen genutzt („Plan“). Dazu dienen etwa digitale Zwillinge von Maschinen – im Prinzip sind dies die während der Entwicklung erzeugten Modelle in einer neuen Rolle.

Auf Grundlage dieser Auswertungen wiederum werden Anpassungen und Optimierungen erarbeitet (Pfeil „Design“), durch Codegenerierung („Build“) in die Modelle integriert und getestet („Test“). Der letzte getestete Build wird dann als Update ausgeliefert (gelber Pfeil „Continuous Deployment“) und auf die Maschine aufgespielt („Deploy“). Zentraler Vorteil dieses Zyklus ist seine weitgehende Automatisierbarkeit. Jede Aktualisierung wird in die Modelle eingebaut und dann durch automatische Build- und Testverfahren validiert, bevor sie in die Auslieferung gehen. Hersteller physischer Produkte profitieren damit von dem in der Software-Branche etablierten Continuous Deployment (CD). ­Jede Erweiterung und Aktualisierung wird zudem zuerst in einer virtuellen Umgebung getestet, wodurch sich Folgeprobleme weit­gehend ausschließen lassen.

Synergien nutzen: Softwareentwicklung und operationale IT

Ein nicht unerheblicher Nebeneffekt der Anwendung von DevOps auf physische Produkte ist, dass sich die bislang sehr unterschiedlichen Welten, in denen Maschinenbauer und Software-Entwickler arbeiten, annähern. Beide Seiten verwenden künftig Modelle, die intuitiv verstanden und als Simulation ausgeführt werden können. Das erleichtert gegenseitiges Verständnis und Erfahrungsaustausch und eröffnet neue Synergien.

Die immer weitere Verlagerung von Entwicklungs- und Planungsprozessen auf softwaregestützte Methoden ermöglicht es aber auch, etwa DevOps-Aktivitäten in die Cloud, auf High-Throughput-Umgebungen und unterschiedliche Standorte zu verteilen. Die Infrastruktur dafür wird durch Software gebildet, und damit durch eine Ressource, die sich leicht durch neue Instanzen erweitern lässt. Dieser flexible Zugriff macht Prozesse skalierbar und erhöht damit die Reaktionsfähigkeit, erfordert aber stets nur die Vorhaltung oder Buchung der gerade benötigten Ressourcen.

Einstieg in die Outcome Economy

Der modellbasierte Ansatz mit Codegenerierung erleichtert so unter anderem den Einstieg in die Outcome Economy, weil er Ergebnisse verlässlicher berechenbar und dem Kunden anhand konkreter Auswertung von Alternativen leichter verständlich macht. Das schafft das Vertrauen, das Maschinenbauer in dieses für sie noch relativ neue Umfeld benötigen.

Die hier vorgestellten Methoden haben sich in verschiedenen Branchen bewährt. Es gibt also Expertise, die eine schrittweise Einführung erlaubt, sowohl auf Seiten der Ingenieure als auch auf Seiten der Anbieter von Lösungen und Dienstleistungen. Maschinen­hersteller haben damit die Chance, sich dieser Prozesse zu bedienen, ohne selbst bei Null anfangen zu müssen. Gleichzeitig haben sie die Sicherheit, dass sich durch die daraus resultierenden positiven Effekte die Investition in kurzer Zeit amortisiert und sie bei der Entwicklung von Alleinstellungsmerkmalen unterstützt werden.

Textquelle: MathWorks

Bildquelle: Beitragsbild Seventyfour – stocke.adobe.com, sonstige MathWorks