Testen 4.0 in der Automatisierungstechnik: Agiles modellbasiertes Testen vernetzter Systeme und Komponenten
Testing 4.0 in Industrial Automation: Agile Model-Based Testing of Networked Systems and Components
A. Löcklin, Institut für Automatisierungstechnik und Softwaresysteme, Universität Stuttgart;
C. Kotsch, Dr.-Ing. K. Krüning, BASF SE, Ludwigshafen am Rhein;
M. Rentschler, Balluff GmbH, Neuhausen auf den Fildern;
Prof. Dr.-Ing. C. Ebert, Vector Consulting Services GmbH, Stuttgart;
M. Müller, Prof. Dr.-Ing. Dr. h. c. M. Weyrich, Institut für
Automatisierungstechnik und Softwaresysteme, Universität Stuttgart;
Kurzfassung
Die Flexibilisierung von Produktionsanlagen ist notwendig, um in einem volatilen Marktumfeld erfolgreich sein zu können. Durch die Bereitstellung und Pflege geeigneter Schnittstellen und Betriebsmodi, sowie dem Umbau von Anlagen, kann auf geänderte Anforderungen an die Produktion reagiert werden. Für die Realisierung derartiger hochflexibler und rekonfigurierbarer Anlagen ist ein erhöhter Engineering- und Testaufwand notwendig. Jede zusätzliche Funktion samt aller damit verbundener Abhängigkeiten müssen vor Inbetriebnahme mehrfach von Herstellern, Integratoren und Betreibern überprüft werden.
Damit der resultierende erhöhte Testaufwand auch zukünftig handhabbar bleibt, werden in dieser Veröffentlichung folgende Ansätze vorgestellt, um ein effizientes und wirkungsvolles Testen im Bereich der flexiblen Produktion zu ermöglichen: Zum einen lässt sich durch eine auf Richtlinien basierende Modularisierung von Anlagen und Komponenten der Testaufwand reduzieren. Auch sorgen Agile Teams für eine verbesserte Kommunikation zwischen Entwicklungs- und Testabteilungen. Überdies ermöglicht die Anwendung von Digitalen Zwillingen einen effektiveren Informationsaustausch zwischen den Stakeholdern und Modellbasiertes Testen ermöglicht Vorteile bei der Testautomatisierung. Alle Ansätze sind jeweils eigenständig wirksam, aber zusammengenommen ergeben sich zusätzliche Synergieeffekte.
1. Herausforderungen für das Testen vernetzter Systeme und Komponenten
Geänderte Marktanforderungen haben in den letzten Jahren für eine stärkere Fokussierung der Flexibilität von Produktionsanlagen gesorgt [1–4]. Allerdings sorgen die Steigerungen von Flexibilität und Effizienz der Produktion in der Prozessindustrie und diskreten Fertigung für eine Erhöhung des Testaufwands bei den eingesetzten Komponenten und Systemen [5, 6].
Diese müssen über viele unterschiedliche Schnittstellen verfügen, um flexibel in verschiedensten Nutzungsszenarien eingesetzt werden zu können. Die umfassende Vernetzung aller an der Produktion beteiligten Assets ermöglicht darüber hinaus Effizienzsteigerungen durch die Realisierung flexibler Systemreaktionen bei unerwarteten Ereignissen wie etwa Ausfällen in der Lieferkette. Die dadurch entstehenden zusätzlichen internen und externen Abhängigkeiten sorgen für mehr Aufwand bei der Komponentenentwicklung und können Schwierigkeiten bei der Inbetriebnahme verursachen.
Bei allen Beteiligten, also Komponentenherstellern, Systemintegratoren und Systembetreibern, steigen die notwendigen Testaufwände für einen effizienten und in getesteten Grenzen flexiblen Produktionsbetrieb [5, 6]. Die Nutzung des vollen Potentials flexibler Produktionsanlagen und die Erreichung maximaler Effizienz ist nur möglich, wenn die notwendigen Testaufwände noch bewältigt werden können.
In diesem Beitrag werden zunächst in Kapitel 2 Lösungsansätze vorgestellt, welche dann an einer Beispielanlage aus der Prozessindustrie in Kapitel 3 und 4 erläutert werden. Am Ende folgt ein Ausblick in Kapitel 5.
2. Testaufwand durch effizienteres Engineering reduzieren
Nicht mehr zu bewältigende Testaufwände können die Inbetriebnahme verzögern oder zu Teilfreigaben führen, die nicht einen flexiblen, sondern nur einen in sehr starren Grenzen definierten Betrieb erlauben. Der Grundsatz von exponentiell steigenden Fehlerbeseitigungs- kosten, je später Fehler entdeckt werden, gilt auch hier. Je später im Lebenszyklus einer Anlage eine Funktion überprüft wird, desto aufwändiger ist die Beseitigung möglicher Fehler, beispielsweise da Experten und Messgeräte nicht mehr verfügbar oder Zugangsmöglichkeiten eingeschränkt sind [6]. Deshalb müssen frühzeitig Maßnahmen zur besseren Bewältigung des Testaufwands ergriffen werden. Hierzu bieten sich folgende Strategien an:
• Testaufwand reduzieren
• Testdurchführung beschleunigen und Testen effizienter gestalten
• Testpriorisierung auf Basis von Kritikalitätsbewertungen
Im Folgenden werden die ersten beiden Strategien weiter betrachtet, eine Testpriorisierung sollte zusätzlich immer erwogen werden. Die Überprüfung des vollen Funktionsumfangs von
Komponenten und Teilsystemen stellt eine Bestätigung der Anlagenflexibilität dar und erfordert die Durchführung aller Tests. Daher sollten im Rahmen einer Priorisierung keine Testfälle eingespart werden. Um Testaufwand zu reduzieren und die Testdurchführung zu beschleunigen werden vier Ansätze vorgestellt. Durch die in Kapitel 2.1 beschriebene Modularisierung und Standardisierung von Komponenten wird eine Reduktion von Testaufwand möglich. Eine Verbesserung der Effizienz von Testprozessen kann erreicht werden mittels der früheren Einbindung von Testexperten im Zuge agiler Entwicklungsprozesse (Kapitel 2.2), der einfacheren Bereitstellung von Information durch Digitale Zwillinge (Kapitel 2.3) sowie einer Erhöhung von Testautomatisierung (Kapitel 2.4).
2.1. Wiederverwendung und Modularisierung reduzieren Testaufwand
Der Testaufwand einer Komponente oder eines Systems ist abhängig vom Funktionsumfang, weil jede bereitgestellte Funktion getestet werden muss. Eine Reduktion des Funktionsumfangs ist meist nicht möglich, da sich dieser aus den Marktanforderungen ergibt.
Die verbleibende Möglichkeit zur tatsächlichen Reduktion von Testaufwänden stellt die Wiederverwendung von Komponenten, Teilsystemen oder Anlagen dar. Bei Wiederverwendung von Software müssen bereits durchgeführte Tests nicht wiederholt werden. Bei der Wiederverwendung von Hardware müssen lediglich Mängel im Herstellungsprozess durch Tests abgesichert werden.
Wiederverwendung profitiert von einer durchdachten Modularisierung von Strukturen auf Software-, Hardware- und Funktionsebene. Ein häufig wiederverwendetes Modul rechtfertigt hohe Investitionen in Qualitäts- und Effizienzoptimierungen. Je häufiger ein bestimmtes Modul eingesetzt wurde, desto weniger Qualitätsmängel treten bei einer erneuten Wiederverwendung und der zur Freigabe notwendigen Integrations- und Systemtests auf. Und jeder durch die Wiederverwendung von Komponenten eingesparte kundennahe Abnahme- oder Factory Acceptance Test spart besonders zeitkritischen Testaufwand. Darüber hinaus ergeben sich für Standardkomponenten eine bessere Ersatzteil- und Knowhow- bzw.
Expertenverfügbarkeit im Fehlerfall.
Aufgrund der in der Domäne der Produktions- und Automatisierungstechnik großen Heterogenität von Komponenten und Anwendungsszenarien erfordert Modularisierung auch eine von ingenieurwissenschaftlichen Prinzipien getriebene Standardisierung, um der Bildung von modularisierten aber trotzdem schlecht wiederverwendbaren Insellösungen entgegenzuwirken. Die in Kapitel 4.1 beschriebene Reduktion von Testaufwand durch Modularisierung am Beispiel einer Anlage aus der Prozessindustrie nutzt daher den Module- Type Package (MTP) Standard.
2.2. Agile Teams verbessern Kommunikation
Für eine bessere Bewältigung des Testaufwands kann die Effizienz von Testprozessen erhöht werden. Verzögerungen im Bereich des Testentwurfs werden häufig durch die mangelnde Testbarkeit von Anforderungen verursacht. Diese auch häufig als testability bezeichnete Eigenschaft von Anforderungen drückt aus, wie einfach Tests und notwendige Testdaten, wie zum Beispiel Grenzwerte, aus Anforderungen abgeleitet werden können. Je präziser eine Anforderung vorliegt, desto höher deren Testbarkeit. Die möglichst frühe Einbindung von Testexperten in einem agilen Engineering Prozess kann die Testbarkeit von Anforderungen verbessern, da diese mehr Fokus auf klar definierte Grenzwerte und Verhalten in Ausnahmefällen legen. Dadurch wird der Interpretationsspielraum bei der späteren Testfallerstellung reduziert und Missverständnisse vermieden. Darüber hinaus erhalten Testexperten bereits in frühen Projektphasen ein vollständigeres Bild des Testobjekts und können rechtzeitig organisatorische Abhängigkeiten erkennen und verteilte Testaufgaben sowie die Entwicklung von Testautomatisierungslösungen einplanen.
2.3. Digitale Zwillinge für effizienten Informationsaustausch
Ein häufiger trivialer Grund für Verzögerungen von Engineering- und Testprozessen stellt die mangelnde Verfügbarkeit von Informationen dar [6, 7]. Das Digitale Zwilling Konzept hilft verstreut vorliegende Informationen an einer zentralen Stelle zu bündeln [8, 9]. Mittels teilautomatisierter Informations-Synchronisierung zwischen realer Anlage und der digitalen Beschreibung wirkt ein Digitaler Zwilling der schleichenden Obsoleszenz von Komponenten- bzw. Systemdokumentation entgegen. Für einen automatisierbaren Informationsaustausch zwischen Abteilungen oder Unternehmen müssen semantische Lücken, also wenn etwa gleiche Dinge unterschiedlich benannt oder gemessen werden, durch Standards zur Informationsbeschreibung abgebaut werden. Die inzwischen durch die Industrial Digital Twin Association (IDTA) [10] vorangetriebene Entwicklung der Verwaltungsschale (engl. Asset Administration Shell) stellt hierbei einen Ansatz für die Verknüpfung verschiedener Standards und formalisierter Informationsbereitstellung durch einen Digitalen Zwilling dar.
2.4. Modellbasierte Testautomatisierung
Neben der Kostenoptimierung ist ein Hauptziel von Testautomatisierung die beschleunigte Bewältigung von Testaufwänden. Dabei werden zwischen der Automatisierung der Testausführung und der Testfallgenerierung unterschieden. Eine automatisierte Ausführung von Testfällen bedingt einen zusätzlichen Entwicklungsaufwand und lohnt sich nur bei wiederkehrenden Testaufwänden. Die in diesem Beitrag betrachtete automatisierte
Generierung von Tests kann hingegen auch bei einmaliger Testausführung eine Aufwandseinsparung erzielen. Ein im Bereich Softwareentwicklung sehr erfolgreich eingesetzter Ansatz zur Testfallgenerierung stellt das Modellbasierte Testen dar. Anstatt Testfälle manuell zu entwerfen, wird beim Modellbasierten Testen die Abstraktionsebene beim Testfallentwurf erhöht und Testexperten überführen Anforderungen und Spezifikationen in formalisierte Modelle, etwa Zustandsautomaten. Der anschließende Entwurf von konkreten Testfällen kann dann automatisiert mit Hilfe von Softwarewerkzeugen erfolgen, Testfälle werden nicht mehr entworfen, sondern generiert. Für die Analyse der Modelle nutzen die Softwarewerkzeuge Techniken wie etwa Pfadtraversierung oder Mutationsgenerierung und berechnen gleichzeitig Metriken der Testabdeckung, um automatisiert ausreichend Testfälle aus den Modellen zu generieren. Empirischen Studien zufolge können mit modellbasierter Testfallgenerierung Testaufwände schneller bewältigt werden [11, 12] und es werden mehr kritische Fehler gefunden [13, 14], allerdings entstehen initiale Mehraufwände bei der Einführung von Modellbasierten Testverfahren [12, 15].
2.5. Bessere Bewältigung von Testaufwand
Die in den Kapitel 2.1 bis 2.4 vorgestellten Ansätze zur besseren Bewältigung von Testaufwänden stellen einzelne Puzzlestücke für das Testen vernetzter Systeme und Komponenten dar. Eine reine Beschleunigung von Testprozessen mit den in Kapitel 2.2 bis 2.4 beschriebenen Maßnahmen kann scheitern, wenn Testaufwände aufgrund immer komplexerer Anlagen unendlich ansteigen. Durch die in Kapitel 2.1 beschriebene Wiederverwendung und standardisierte Modularisierung von Komponenten und Systemen kann Testaufwand wieder reduziert werden. Eine höhere Agilität durch die in Kapitel 2.2 beschriebene frühe Einbindung von Testexperten in das Requirements Engineering erleichtern die Testplanung und verbessern die Testbarkeit von Anforderungen. Bei abteilungs- und unternehmensübergreifenden Großprojekten ist hierfür ein reibungsloser Austausch stets aktueller Informationen notwendig, einen Ansatzpunkt hierfür stellt, wie in Kapitel 2.3 beschrieben, die Verwendung von Digitalen Zwillingen dar. Die durch Digitale Zwillinge verbesserte Modellverfügbarkeit sowie Fortschritte bei der Einführung von modell- getriebenem Engineering machen zudem die Einführung von Modellbasierter Testfallgenerierung greifbar, welche zu einer Aufwandseinsparung führt.
Alle vier Ansätze wirken auch für sich genommen und wenn alle beschriebenen Puzzlestücke zusammenwirken ergeben sich Synergieeffekte. Dies wird im Folgenden beispielhaft an einer Demonstrationsanlage aus der Prozessindustrie erläutert. Je modularer und formalisierter eine Anlage aufgebaut wurde, desto leichter können Agile Entwicklungsprozesse angewendet,
Digitale Zwillinge erstellt und modellbasierte Testfallgenerierung etabliert werden. Die Abkürzung Testen 4.0 soll dabei nicht als Revolution aufgefasst werden, sondern damit wird verdeutlicht, dass flexible, vernetzte Anlagen große Herausforderungen im Bereich des Testens mitbringen und Testprozesse entsprechend weiterentwickelt werden müssen.
3. Vorstellung des Open Automation Demonstrators aus dem Bereich Modularisierung
Für die weitere Erläuterung der in Kapitel 2 dargestellten Ansätze dient als Praxisbeispiel die in Abbildung 1 dargestellte Demonstrationsanlage aus dem Bereich der Prozessindustrie. Als Demonstrator für die modulare Automation in der chemischen Industrie wurde ein Testsystem gebaut, das im Fachzentrum für Automatisierungstechnik der BASF Ludwigshafen für die Evaluierung neuer Prozessleitsysteme sowie neuer Leitsystemversionen eingesetzt wird. Mit diesem Demonstrator können alle gängigen Funktionen eines Prozessleitsystems einer realen Anlage getestet werden. Das Testsystem wurde zunächst ohne den Fokus Modularisierung vor etwa zehn Jahren aufgebaut. Ziel war es, alle wesentlichen Funktionalitäten, die in den Anlagen und am Verbundstandort Ludwigshafen implementiert sind, in ein kompaktes Testsystem zu integrieren und auf dem Stand der Technik zu halten. Im Rahmen der Erneuerung des Demonstrators wurde die in Kapitel 4.1 beschriebene Modularisierung mittels Module-Type Package (MTP) realisiert [16].
Das Testsystem besteht aus vier Wasserbehältern, die mit Verrohrung verbunden sind. Jeder Tank hat ein Auslassventil und zwei Einlassventile. Alle Tanks besitzen eine Kühlfunktion und zwei der Tanks zusätzlich eine Heizfunktion. Um das Medium zwischen den Tanks zu transportieren, sind zwei Pumpen im Testsystem verbaut und fest verrohrt.
Abbildung 1: Open Automation Demonstrator for the Chemical Industry
Der Demonstrator deckt zwei Anlagentypen ab: Kontianlagen und Batchanlagen. Ein einfaches Rezept einer Batchanlage ist, aus den Vorratsbehältern eins und zwei, im Behälter drei eine Reaktion in einem bestimmten Verhältnis hervorzurufen. Die Reaktion wird durch Kühlen und/oder Heizen hervorgerufen. Der Behälter vier dient als Tanklager. Die Ansteuerung der Module erfolgt über Services. Dieses einfache Rezept zeigt schon sehr deutlich die Anforderung an die Automatisierung: Während in einem herkömmlichen Leitsystem die Funktionalität auf einem sehr niedrigen Abstraktionsniveau in Form von Funktionsbausteinen und Logikgattern implementiert wurde, ist bei der modularen Automation wie in Abbildung 2 dargestellt die Software-Kapselung auf einem hohen Abstraktionsniveau ein zentrales Ziel.
Abbildung 2: Vorkonfektionierte Services ersetzen individuelle Logik
4. Testen 4.0 am Beispiel des Open Automation Demonstrators
Die in Kapitel 2 vorgestellten Ansätze zum effizienten und wirkungsvollen Testen von vernetzten Komponenten und Systemen werden im Folgenden weiter vertieft.
4.1. Modularisierung mittels Module-Type Package
Ein verfahrenstechnischer Umbau von Bestandsanlagen ist sehr teuer. Oberstes Ziel ist es daher, keinerlei verfahrenstechnische Änderungen wie Zusatzarmaturen, Verrohrung oder zusätzliche Absperrventile einzubauen und so nah wie möglich an der existierenden Implementierung zu bleiben. Die nachträgliche softwaretechnische Modularisierung erleichtert die Skalierung einer Gesamtanlage, den Test der Anlagen im Vorfeld, wie auch das Ergänzen zusätzlicher Funktionen mit der Sicherheit, dass vorhandene Funktionen nicht verändert wurden. Der Migrationsaufwand für das Leitsystem reduziert sich, da elementare Steuerungsfunktionen von Modulen gekapselt sind.
Über die Kapselung der Software erreicht man eine funktionale Modellierung. Hierbei werden in den Modulen Services implementiert, z. B. für das Temperieren und Transportieren.
Vergleicht man nun das herkömmliche Leitsystem mit dem Modularisierungsansatz, so entsprechen die Services der Module den Grundfunktionen eines Batchs (siehe ISA 88), jedoch mit einem höheren internen Automatisierungsgrad versehen und dadurch im Rahmen von Systemtests besser testbar.
Bei dem Umbau des Demonstrators in ein modular automatisiertes System ist die erste Aufgabe, Module zu definieren. Durch den Zuschnitt der Module des Demonstrators auf Softwareebene ergeben sich vier Module, mit jeweils einem Behälter, mit zugehörigem Equipment, wie Aktorik und Sensorik. Die Definition der Module auf Softwareebene zeigt, dass aufgrund der Brownfield-Automatisierung und der fehlenden Zusatzarmaturen, sowie einem nicht modularen verfahrenstechnischen Aufbau, gewisse Einstiegshürden zu nehmen waren.
Die Zuordnung der Pumpen für den Transport des Mediums zwischen den Behältern stellte hierbei die größte Hürde dar, diese wurden als geteiltes Equipment realisiert, das mehreren Modulen zur Verfügung steht.
Durch die modulare Automatisierung kann das Skalierungsverhalten einer Bestandsanlage verbessert werden. Die neu zu implementierenden Funktionen können im Vorfeld nahezu vollständig getestet werden. Die Stillstandszeit der Anlage reduziert sich deutlich oder ist gar nicht mehr notwendig. Anlagenteile können schneller erweitert werden, neue Funktionalitäten können in laufende Anlagen per Plug & Produce implementiert werden, ohne auf die Verfügbarkeit der Anlage zu verzichten.
4.2. Agiles Testen mit Test-Driven Requirements Engineering
Requirements Engineering und Test werden häufig getrennt behandelt. Das hat zur Folge, dass in vielen Projekten Anforderungen erst sehr spät auch aus der Testperspektive analysiert werden, häufig erst, wenn erste Systembestandteile bereits teilweise realisiert sind. Durch diese gängige Praxis ergeben sich zwei Nachteile: Unzureichende Anforderungsqualität wird zu spät entdeckt und die Testfall-Erstellung ist aufwändiger und fehleranfälliger aufgrund eines Mangels an Kontextinformationen aus der Requirements-Engineering Phase. [17]
Test-Driven Requirements Engineering (TDRE) setzt hier an. Durch den Einbezug von Testingenieuren beim Requirements Engineering steigt die Qualität von Anforderungen sowie die Verzahnung mit der Testfall- und Testautomatisierungs-Entwicklung. Bei der Umsetzung von TDRE werden Kundenanforderungen direkt in Testfälle übersetzt. Eine Automatisierung dieses Vorgangs ist bei formalisiert vorliegenden Anforderungen möglich, also wenn Anforderungen über eine konsistente Struktur samt messbaren Vor- und Nachbedingungen
verfügen [18]. Bei der im Kapitel 4.1 beschriebenen Modularisierung mittels Module-Type Package werden beispielsweise standardisierte Zustandsautomaten genutzt. Darauf aufbauend können, wie in Kapitel 4.4 beschrieben, Modelle entwickelt und für eine automatisierte Testfallgenerierung eingesetzt werden.
Ein gutes Traceability Konzept, also die Verknüpfung von Anforderungen, Tests und sonstigen Entwicklungs-Artefakten, ist eine Grundvoraussetzung für erfolgreiches TDRE. Die in Kapitel 4.3 beschriebene Verwaltungsschale kann hierfür als zentraler Zugriffspunkt für Entwicklungs-Artefakte dienen. Erfolgreich angewendet ermöglicht Test-Driven Requirements Engineering eine Reduktion von Doppelarbeit durch eine verbesserte Vollständigkeit, Genauigkeit und Klarheit von Anforderungen. Auch das unzulässige Ausblenden von Problembereichen, etwa durch die Annahme schwer zu rechtfertigender Randbedingungen, kann reduziert werden. Gemäß [18] können durch Test-Driven Requirements Engineering die Durchführungsdauern und Kosten von Testprozessen um bis zu 30% gesenkt werden.
4.3. Verwaltungsschale als standardisierter Digitaler Zwilling
Die Grundfunktionalität Digitaler Zwillinge liegt in der virtuellen Repräsentation von Assets und der Bereitstellung von untereinander verknüpften domänenspezifischen Modellen [8]. Digitale Zwillinge können für unterschiedliche Zwecke eingesetzt werden [8], in [19] werden unterschiedliche Anwendungszwecke im Rahmen der Verifikation und Validierung analysiert.
Wie in Abschnitt 2.3 beschrieben, stellt bereits die Beschleunigung des Informationsaustauschs einen großen Nutzen von Digitalen Zwillingen dar. Die Bereitstellung von Informationen ist eine Grundanforderung und -herausforderung bei Absicherungs- und Testprozessen [6]. Nur wenn alle Informationen rechtzeitig und umfassend vorliegen, kann Testaufwand effizient bewältigt werden.
Abbildung 3: Digitale Zwillinge betten sich bestehende Unternehmens-IT ein und bündeln mehrere Schnittstellen, was die Zusammenarbeit mit externen Partnern erleichtert
Externe Partner
…
…
… Digitaler Zwilling/
Verwaltungsschale
Komponente
Die Hauptaufgaben eines Digitalen Zwillings liegen in der domänenübergreifenden, Gegenstands-individuellen (instanzspezifischen) Informationsbereitstellung und Unterstützung beim Lifecycle Management. Hierzu betten sich Digitale Zwillinge, wie in Abbildung 3 dargestellt, in die bestehende Unternehmens-IT [9] ein und ermöglichen eine neue instanzspezifische Repräsentation. Insbesondere bei der Zusammenarbeit und Kommunikation mit externen Partnern kann dann ein Digitaler Zwilling als zentrale Schnittstelle dienen. Dadurch können Schnittstellen zu verschiedenen IT-Systemen gebündelt und die Kommunikation mit externen Partnern vereinfacht werden.
Abbildung 4: Hersteller, Integratoren und Betreiber nutzen eigene Digitale Zwillinge
Die Verwaltungsschale (englisch Asset Administration Shell) [10] wurde als grundlegendes Konzept für die Realisierung von Digitalen Zwillingen entwickelt. Wie in Abbildung 4 dargestellt, stimmen Hersteller, Integratoren und Betreiber ihre jeweiligen Digitalen Zwillinge auf ihre Anforderungen und Anwendungen ab. Während herstellerseitig vor allem die Verwaltung und übersichtliche Darstellung von Spezifikationselementen und Einsatzszenarien im Fokus steht, dienen Digitale Zwillinge auf Betreiber-Seite zur Vereinfachung der Kommunikation in Wartungsphasen und im Fehlerfall. Digitale Zwillinge, die sich am Ansatz der Verwaltungsschale orientieren, nutzen bestehende Standards und stellen standardisierte Submodelle zur Verfügung. Durch die Standardisierung der Inhalte und Schnittstellen ermöglicht die Verwaltungsschale den einfachen Informationsaustausch zwischen den Digitalen Zwillingen sowie zwischen Ihren Herstellern, Integratoren und Betreibern.
Für den in Kapitel 3 vorgestellten Open Automation Demonstrator wurde für einen Flüssigkeitstank eine Verwaltungsschale erstellt. Hierin wurden, wie in Abbildung 5 dargestellt, UML-Modelle gespeichert, welche die Funktionsweise des Tanks beschreiben, und Testfälle,
Hersteller Integrator Betreiber
……
Verwaltungsschale
Komponente 1
Verwaltungsschale
Komponente n
Verwaltungsschale
Teilsystem 1
Verwaltungsschale
Teilsystem m
…
Verwaltungsschale Anlage 1 in Umgebung
Alpha
Verwaltungsschale Anlage p in Umgebung Omega
……
welche der Überprüfung des durch den Tank angebotenen Service „Temperieren“ dienen. Die Verwaltungsschale der Komponente Tank würde im Falle eines realen Produkts vom Hersteller erstellt und könnte sowohl Integratoren als auch Betreibern zur Verfügung gestellt werden. Mit den hinterlegten Informationen ist eine Überprüfung der Einhaltung von Standards sowie mittels Ausführens der Testfälle eine Überprüfung der korrekten Funktion möglich. Die Verwaltungsschale wurde mit dem Open Source Tool „AASX Package Explorer“ [20] erstellt.
4.4. Testautomatisierung mittels Modellbasiertem Testen erhöhen
Ein Synergieeffekt durch die in Kapitel 4.1 beschriebene Modularisierung nach MTP ist die erleichterte formalisierte Beschreibung der Funktionsweise von Komponenten und deren Services. Die durch ISA 88 und VDI/VDE/NAMUR 2658 ermöglichte standardisierte Beschreibung von Zustandsautomaten und Bezeichnern unterstützt bei der initialen Modellierung, da existierende Modelle anderer Komponenten zu großen Teilen übernommen und wiederverwendet werden können. Die in Abbildung 5 gezeigten UML-Modelle beschreiben den Service „Temperieren“ des in Kapitel 3 vorgestellten Open Automation Demonstrators.
Durch die standardisierte Beschreibung der Services ist eine hohe Übertragbarkeit der erstellten UML-Modelle auf andere Services und Anlagen gewährleistet.
Eine verbesserte Modularisierung und Standardisierung sorgen für eine größere Verfügbarkeit von Modellen und damit Synergieeffekte im Bereich des modellgetriebenen Engineerings.
Modelle erleichtern die Kommunikation zwischen Entwicklerteams sowie über Unternehmens- grenzen hinweg, da zwischen nicht formalisierten Anforderungen und fertiger Software bzw.
Hardware durch Anforderungs-, Blockdefinitions- und Zustandsdiagramme weitere Beschreibungsformen auf verschiedenen Abstraktionsniveaus verfügbar sind.
Abbildung 5: Verwaltungsschale des Flüssigkeitstanks umfasst Modelle und die daraus automatisiert generierten Testfälle
Formalisierte Beschreibung Flüssigkeitstank:
UML-Zustandsdiagramme:
… UML-Klassendiagramm:
Service Temperieren
(Generierte) Testfälle:
Verwaltungs- schale
MoMuT
Modellbasiertes Testen Werkzeug automatisiert
Test:
1. ~~~~~
2. ~~~~~
3. ~~~~~
… X. ~~~~~
Test:
1. ~~~~~
2. ~~~~~
3. ~~~~~
… X. ~~~~~
Test:
1. ~~~~~
2. ~~~~~
3. ~~~~~
… X. ~~~~~
Test:
1. ~~~~~
2. ~~~~~
3. ~~~~~
… X. ~~~~~
Test:
1. ~~~~~
2. ~~~~~
3. ~~~~~
… X. ~~~~~
Test:
1. ~~~~~
2. ~~~~~
3. ~~~~~
… X. ~~~~~
Test:
1. ~~~~~
2. ~~~~~
3. ~~~~~
… X. ~~~~~
Test:
1. ~~~~~
2. ~~~~~
3. ~~~~~
… X. ~~~~~
Test:
1. ~~~~~
2. ~~~~~
3. ~~~~~
… X. ~~~~~
Test:
1. ~~~~~
2. ~~~~~
3. ~~~~~
… X. ~~~~~
Test:
1. ~~~~~
2. ~~~~~
3. ~~~~~
… X. ~~~~~
Test:
1. ~~~~~
2. ~~~~~
3. ~~~~~… X. ~~~~~
Modelle können wie in Kapitel 2.4 erläutert für Testautomatisierung eingesetzt werden.
Ausgangspunkt bei jeder modellbasierten Testautomatisierung ist die Auswahl eines geeigneten Werkzeugs, welches automatisiert aus Modellen Tests generieren kann.
Werkzeuge des modellbasierten Testens unterstützen eine oder mehrere Modellierungssprachen wie etwa UML, BPMN, SysML oder proprietäre, werkzeugspezifische Sprachen, einen Überblick bietet [21]. Als Werkzeug zur automatisierten Testgenerierung wurde zur Erprobung der in dieser Veröffentlichung beschriebenen Inhalte das Open Source Werkzeug MoMuT [22–24] eingesetzt. Die Abkürzung MoMuT steht für Model-based Mutation Testing for UML und bezeichnet inzwischen eine ganze Familie von Werkzeugen zur Testfallgenerierung. MoMuT kann unter anderem direkt aus UML Zustandsdiagrammen automatisch Testfälle generieren. Im Falle des Flüssigkeitstanks des Open Automation Demonstrators wurde für den entsprechend modellierten Service „Temperieren“ mit 17 generierten Testfällen eine vollständige Testabdeckung erreicht. Die generierten Testfälle umfassen eine Schritt-für-Schritt-Anleitung zur Testdurchführung mittels der über die grafische Benutzeroberfläche zugänglichen Bedienelemente.
Zur Untersuchung der Potenziale von modellbasiertem Testen mit dem UML-orientierten Werkzeug MoMuT wurden die Funktionen des in Kapitel 3 vorgestellten Open Automation Demonstrators formalisiert beschrieben. Für einen Wassertank wurde der Service
„Temperieren“ als UML-Zustandsdiagramm modelliert. Für die Definition der im Zustands- diagramm genutzten Variablen und Funktionsaufrufe wird zudem ein UML-Klassendiagramm benötigt. Beide Diagramme wurden mit dem Open Source UML-Editor Eclipse Papyrus [25]
erstellt und folgen der durch ISA 88 bzw. IEC 61512 vorgegebenen Bezeichnungen. Neben Zuständen des Regelbetriebs wurden auch Fehlerzustände modelliert.
In Abbildung 5 ist das Vorgehen bei der modellbasierten Testautomatisierung nochmals dargestellt. Der in Kapitel 3 vorgestellte Open Automation Demonstrator verfügt über insgesamt vier Flüssigkeitstanks. Für einen davon wurde, wie in Kapitel 4.3 beschrieben, eine Verwaltungsschale realisiert. Die Verwaltungsschale speichert neben allgemeinen Informationen und Dokumenten auch die für die modellbasierte Testautomatisierung notwendigen UML-Diagramme sowie die daraus generierten Testfälle. Die Modellierung in UML wurde manuell durchgeführt. Da es sich bei dem betrachteten Tank um eine standardisierte, zu Module-Type Package konforme Komponente handelt, besteht der Großteil des Modellierungsaufwands in der Übersetzung von bestehenden Beschreibungsformen in UML. Module-Type Package sorgt für eine bessere Wiederverwendbarkeit von Software, dies trifft auch für die Modellierung mit UML zu, die entstandenen UML Modelle lassen sich effizient für ähnliche Komponenten wiederverwenden. Das für den Service „Temperieren“ erstellte
Zustandsdiagramm folgt den Vorgaben des Werkzeugs MoMuT und kann von diesem eingelesen werden. Vollautomatisiert generiert MoMuT anschließend Testfälle, welche dann ebenfalls in der Verwaltungsschale gespeichert werden.
Es lassen sich an diesem Beispiel vier unterschiedliche Ebenen von Testautomatisierung aufzeigen. So kann das Ziel einer Testautomatisierung darin bestehen, vorliegende Dokumentation und Modelle auf Konformität zu Normen und Richtlinien zu prüfen, also die Modelle oder die Dokumentationsinfrastruktur zu überprüfen. Dies stellt die Eingangsstufe in das automatisierte Testen dar.
Dem übergeordnet ist die in diesem Kapitel beschriebene Testautomatisierung. Mit der hier vorgestellten Methodik werden automatisiert Tests für eine einzelne Komponente, einen einzelnen MTP Container, einen einzelnen Service, etc. generiert. Dadurch wird die Testentwurfsphase beschleunigt.
Die nächste, dritte Stufe ist die automatisierte Testgenerierung für Anlagen, welche aus mehreren Komponenten bestehen bzw. mehrere MTP Container umfassen und mehrere, voneinander abhängige Services anbieten. Vor einer Testgenerierung müssen dann die Modelle einzelner Komponenten bzw. Services zu einem Anlagenmodell zusammengeführt werden. Methoden der Modellorchestrierung werden in [26, 27] diskutiert.
Stufe 4 richtet sich anschließend an die automatisierte Testausführung. Bei Stufe 2 und 3 werden Testfälle automatisch generiert und müssen manuell abgearbeitet werden, was bei sich wiederholenden Tests ineffizient ist. Für eine Vollautomatisierung des Testens müssen die einzelnen Testfallschritte über Skripte automatisiert ausführbar und auswertbar gemacht werden. Es existieren hierfür unterschiedliche Ansätze, weit verbreitet ist beispielsweise das Keyword-Driven Testing, ein Überblick wird in [5] gegeben. Je nach Testgegenstand muss auch das Testbett, also die Umgebung in der die Tests durchgeführt werden, automatisiert werden. Gängige Konzepte sind dabei „Hardware-in-the-Loop“ (HiL) und „Software-in-the- Loop“ (SiL). Die automatisierte Testausführung und Auswertung ist unabhängig davon, ob Testfälle manuell oder automatisiert erstellt werden. Modellbasierte Testfallgenerierung der Stufen 2 und 3 erzeugt Testfälle mit hoher Systematik hinsichtlich der Überdeckung und Benennung, dadurch ergeben sich Vorteile für die Automatisierung der Testausführung [15].
5. Zusammenfassung und Ausblick
Flexible, vernetzte Produktionsanlagen und ihre Komponenten weisen eine erhöhte Komplexität auf [3, 4]. Aufgrund zusätzlicher Schnittstellen und Betriebsmodi können verschiedene Einsatzzwecke unterstützt und die Flexibilität einer Anlage erhöht werden. Jede zusätzliche Funktion und Abhängigkeit erhöht aber den Engineering- und Testaufwand [5, 6].
Um notwendige Testaufwände auch zukünftig bewältigen zu können, wurden in dieser Veröffentlichung vier Ansätze vorgestellt:
• Die nach Standards orientierte Modularisierung von Komponenten und Anlagen mittels Module-Type Package (MTP) ermöglicht eine Reduktion von Testaufwand. Durch Wiederverwendung steigt die Qualität sowie die Knowhow- und Ersatzteilverfügbarkeit, gemeinsame Standards verhindern die Bildung von Insellösungen.
• Ein Wandel hin zu agileren Test- und Entwicklungsteams verbessert die Kommunikation. Durch die Umsetzung von Test-Driven Requirements Engineering (TDRE), also der Einbindung von Testexperten in frühen Projektphasen, kann die testability von Anforderungen gesteigert werden, da Testexperten viel Erfahrung und Fokus auf Grenzwerte und Ausnahmesituationen einbringen. Durch eine Steigerung der Qualität und Testbarkeit von Anforderungen können daraus effizienter Tests abgeleitet und entworfen werden.
• Um den Informationsfluss zu verbessern eignet sich der Einsatz von Digitalen Zwillingen. Die Verwaltungsschale eignet sich zur zentralen Informationsbereitstellung auch über Unternehmensgrenzen hinweg und wirkt dem Problem unterschiedlich aufgefasster, unvollständiger oder obsoleter Dokumentation entgegen. Ein effizienter Informationsfluss reduziert Wartezeiten oder Unklarheiten beim Testfallentwurf.
• Für eine bessere Bewältigung von Testaufwand kann zudem Testautomatisierung erwogen werden. Es lassen sich die automatisierte Testausführung und Testgenerierung unterscheiden. Modellbasierte Testfallgenerierung hat auch bei selten ausgeführten Tests einen positiven Einfluss auf den Testaufwand.
Jeder Ansatz kann einzeln angewendet werden, zusammengenommen werden zusätzliche Synergieeffekte erzielt. Eine nach Standards durchgeführte Modularisierung erleichtert das Requirements Engineering, sowie die Erzeugung von Digitalen Zwillingen und formalisierter Modelle für Modellbasiertes Testen. Agilität und ein Abbau von Abteilungsgrenzen verbessern das Erkennen von wiederverwendbaren Lösungen sowie das gemeinsame Arbeiten an Dokumentation und Modellen. Digitale Zwillinge fördern die Standardisierung von Inhalten und erleichtern die Informationsbereitstellung in Form von Dokumenten und Modellen. Modelle des Modellbasierten Testens verbessern dank einer gesteigerten Anschaulichkeit und höherem Abstraktionsniveau die Kommunikation zwischen Experten und fördern die Standardisierung.
Das Testen vernetzter Komponenten und Systeme ist aufwändiger, durch die Anwendung und Kombination der beschriebenen Ansätze wird die Weiterentwicklung von Testprozessen und ein effizientes und wirkungsvolles Testen im Bereich der flexiblen Produktion erreicht.
Danksagung
Die Autoren bedanken sich bei allen Mitgliedern des VDI/VDE GMA Fachausschusses 7.25 und Veranstaltungsteilnehmern für die Diskussion der Inhalte im Rahmen des VDI Expertenforums „Testen vernetzter Systeme und Komponenten“.
6. Literaturverzeichnis
[1] J. Bernshausen, A. Haller, T. Holm, M. Hoernicke, M. Obst und J. Ladiges, „Namur Modul Type Package – Definition“, atp, Jg. 58, S. 72, 2016, doi: 10.17560/atp.v58i01- 02.554.
[2] H.-P. Wiendahl et al., „Changeable Manufacturing - Classification, Design and Operation“, CIRP Annals, Jg. 56, Nr. 2, S. 783–809, 2007, doi:
10.1016/j.cirp.2007.10.003.
[3] T. Müller, N. Jazdi und M. Weyrich, „Intelligentes Rekonfigurationsmanagement
selbstorganisierter Produktionssysteme in der diskreten Fertigung“ (de), VDI-Kongress AUTOMATION, 2020, doi: 10.18419/opus-10928.
[4] T. Müller, N. Jazdi, Jan-Philipp Schmidt und M. Weyrich, „Cyber-Physical Production Systems: enhancement with a self-organized reconfiguration management“ (en), Procedia CIRP, 2020, doi: 10.13140/RG.2.2.12562.48323/1.
[5] M. Weyrich et al., „Testen vernetzter Systeme für die Industrie 4.0“, atp, Jg. 60, Nr. 03, S. 26–33, 2018, doi: 10.17560/atp.v58i03.2343.
[6] Testen vernetzter I4.0-Systeme: Grobplanung verteilter Testprozesse, 4004 Blatt 1, VDI/VDE, Apr. 2020.
[7] D. Méndez Fernández und S. Wagner, „Naming the pain in requirements engineering: A design for a global family of surveys and first results from Germany“, Information and Software Technology, Jg. 57, S. 616–643, 2015, doi: 10.1016/j.infsof.2014.05.008.
[8] B. Ashtari Talkhestani et al., „An architecture of an Intelligent Digital Twin in a Cyber- Physical Production System“, at - Automatisierungstechnik, Jg. 67, Nr. 9, S. 762–782, 2019, doi: 10.1515/auto-2019-0039.
[9] R. Heidel, M. Hoffmeister, M. Hankel und U. Döbrich, Hg., Industrie4.0 Basiswissen RAMI4.0: Referenzarchitekturmodell mit Industrie4.0-Komponente, 1. Aufl. Berlin, Wien, Zürich, Berlin, Offenbach: Beuth Verlag GmbH; VDE Verlag GmbH, 2017.
[10] IDTA, IDTA - Industrial Digital Twin Association e.V. [Online]. Verfügbar unter:
https://idtwin.org/ (Zugriff am: 4. Mai 2021).
[11] C. Brandes, „Testkosten senken, Qualität steigern“, IT Management, Juli-August, 2015.
[12] M. Winter, T. Roßner, C. Brandes und H. Goetz, Basiswissen modellbasierter Test:
Aus- und Weiterbildung zum ISTQB® Foundation Level–Certified Model-Based Tester, 2. Aufl. Heidelberg: dpunkt.verlag, 2016.
[13] C. Schulze, D. Ganesan, M. Lindvall, R. Cleaveland und D. Goldman, „Assessing model-based testing: an empirical study conducted in industry“ in Companion
Proceedings of the 36th International Conference on Software Engineering, Hyderabad India, 2014, S. 135–144, doi: 10.1145/2591062.2591180.
[14] A. Marques, F. Ramalho und W. L. Andrade, „Comparing Model-Based Testing with Traditional Testing Strategies: An Empirical Study“ in IEEE Seventh International Conference on Software Testing, Verification and Validation Workshops, OH, USA, 2014, S. 264–273, doi: 10.1109/ICSTW.2014.29.
[15] V. Gudmundsson, M. Lindvall, L. Aceto, J. Bergthorsson und D. Ganesan, „Model- based Testing of Mobile Systems – An Empirical Study on QuizUp Android App“, Electron. Proc. Theor. Comput. Sci., Jg. 208, S. 16–30, 2016, doi:
10.4204/EPTCS.208.2.
[16] M. Krauss et al., „Open Automation Demonstrator für die chemische Industrie“, atp, Jg.
62, 6-7, S. 60–67, 2020, doi: 10.17560/atp.v62i6-7.2476.
[17] C. Ebert, Systematisches Requirements Engineering: Anforderungen ermitteln, dokumentieren, analysieren und verwalten, 6. Aufl. Heidelberg: dpunkt.verlag, 2019.
[18] C. Ebert und R. Ray, „Test-Driven Requirements Engineering“, IEEE Softw., Jg. 38, Nr.
1, S. 16–24, 2021, doi: 10.1109/MS.2020.3029811.
[19] A. Löcklin, M. Müller, T. Jung, N. Jazdi, D. White und M. Weyrich, „Digital Twin for Verification and Validation of Industrial Automation Systems – a Survey“ in 25th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA), 2020, S. 851–858, doi: 10.1109/ETFA46521.2020.9212051.
[20] M. Hoffmeister A. Orzelski et al., admin-shell-io. [Online]. Verfügbar unter:
https://github.com/admin-shell-io (Zugriff am: 8. April 2021).
[21] Z. Micskei, Model-based testing overview, tools and projects. [Online]. Verfügbar unter:
http://mit.bme.hu/~micskeiz/pages/modelbased_testing.html (Zugriff am: 3. Mai 2021).
[22] MoMuT – Model-based Mutation Testing. [Online]. Verfügbar unter: https://momut.org/
(Zugriff am: 4. Mai 2021).
[23] W. Krenn, R. Schlick, S. Tiran, B. Aichernig, E. Jobstl und H. Brandl, „MoMut::UML Model-Based Mutation Testing for UML“ in IEEE 8th International Conference on Software Testing, Verification and Validation (ICST), Graz, Austria, 2015, S. 1–8, doi:
10.1109/ICST.2015.7102627.
[24] R. Schlick, „MoMuT – Eine Transfer-Geschichte über modellbasiertes Testen“ (en), Lecture Notes in Informatics (LNI), S. 195–200, 2020, doi: 10.18420/SE2020_56.
[25] Papyrus. [Online]. Verfügbar unter: https://www.eclipse.org/papyrus/ (Zugriff am: 8. April 2021).
[26] A. Zeller und M. Weyrich, „Composition of Modular Models for Verification of Distributed Automation Systems“, Procedia Manufacturing, Jg. 17, S. 870–877, 2018, doi:
10.1016/j.promfg.2018.10.139.
[27] M. Grochowski et al., „Formale Methoden für rekonfigurierbare cyber-physische
Systeme in der Produktion“, at - Automatisierungstechnik, Jg. 68, Nr. 1, S. 3–14, 2020, doi: 10.1515/auto-2019-0115.
