BY 4.0 license Open Access Published by Oldenbourg Wissenschaftsverlag April 30, 2020

Automatisierte Generierung von Sicherheitstests für variantenreiche Produktionssysteme mittels ECAD

Automated safety test generation for variant-rich production systems using ECAD
Simon Ziegltrum and Birgit Vogel-Heuser

Zusammenfassung

Die effiziente und vollständige Qualitätssicherung der Sicherheitstechnik von automatisierten Sondermaschinen stellt für deren Hersteller eine große Herausforderung dar. Die Erstellung konsistenter Testprozeduren erfolgt manuell oder erfordert hohen Modellierungsaufwand. Folglich untersucht dieser Beitrag ein Konzept, um notwendige Tests vollautomatisch aus ECAD-Dokumenten abzuleiten. Hierzu werden basierend auf industriellen Checklisten Testmodelle abgeleitet sowie ein ECAD-Modell eingeführt. Anhand eines industriellen Anwendungsfalls wird die Funktionsfähigkeit des Ansatzes demonstriert sowie das Potential einer solchen Methode diskutiert.

Abstract

The efficient and complete quality assurance of the safety equipment of automated special purpose machines represents a great challenge for their manufacturers. The creation of consistent test procedures is done manually or requires high modeling effort. Consequently, this paper examines a concept to derive necessary tests fully automated from ECAD documents. For this purpose, test models are derived based on industrial checklists and an ECAD model is introduced. The functionality of the approach is demonstrated and the potential of such a method is discussed on the basis of an industrial application case.

1 Einleitung

Die Nachfrage nach immer flexibleren und verstärkt kundenspezifischen automatisierten Produktionssystemen (aPS), teils bis Losgröße 1, steigt stetig an. Dies stellt die Hersteller von Sondermaschinen vor zunehmend komplexe Herausforderungen bei der Gestaltung entsprechend angepasster Entwicklungsabläufe. Die enorme Vielfalt und Variabilität der Anlagen erfordert flexible Prozesse für Qualitätssicherung und Tests der Anlagen, da diese für jede einzelne Sondermaschine auf die jeweils unterschiedliche Funktionalität und Hardware angepasst werden müssen. Besonders kritisch ist dies für Abläufe zur Prüfung der Sicherheitstechnik, da sie stets vollständig, systematisch und mit gleichbleibend hoher Qualität getestet werden muss. Hinzu kommt, dass Anlagenfunktionen in der Regel nicht nur von einzelnen Komponenten ausgeführt werden, sondern eine Vielzahl von Komponenten im Zusammenspiel agiert. Im Kontext dieser komplexen, permanent im Wandel befindlichen Systeme stellt die wiederkehrende manuelle Identifikation und Abdeckung aller relevanten zu testenden Subsysteme für Testingenieure daher eine große Herausforderung dar.

Vorteilhaft ist deshalb ein Verfahren, bei dem Testanleitungen sowie Testzusammenstellungen für Komponenten- und Integrationstests systematisch und automatisiert aus generischen Vorlagen sowie aus den Dokumenten abgeleitet werden, die ohnehin bereits maschinenspezifisch erstellt werden müssen. Der weitere Beitrag gliedert sich wie folgt: Anhand realer industrieller Testprozeduren für Sondermaschinen werden Anforderungen für eine automatisierte Testgenerierung der Sicherheitstechnik von Sondermaschinen abgeleitet (Abschnitt 2). Davon ausgehend werden bisherige Verfahren zur modellbasierten Testgenerierung beleuchtet und auf deren Eignung geprüft (Abschnitt 3). Anschließend wird ein Anwendungsbeispiel eingeführt, anhand dessen ein alternatives neuartiges Konzept zur Testgenerierung erläutert werden kann (Abschnitt 4). Daran wird mittels realer Testprozeduren von Sondermaschinen aufgezeigt, wie diese vollständig automatisiert aus Dokumenten der Elektrokonstruktion generiert werden können. Durch Kombination digitaler elektrischer Konstruktionspläne (ECAD), die ein partielles Abbild der zu testenden Sicherheitstechnik enthalten, mit Beschreibungen der bauteilinternen Verschaltung und generischen Anleitungen atomarer Einzeltests von Teilsystemen wird die notwendige Dokumentation zur anschließenden Testdurchführung von Sicherheitsfunktionen, z. B. im Rahmen einer Inbetriebnahme, generiert (Abschnitt 5). In Abschnitt 6 wird das vorgestellte Konzept anhand dreier Testklassen unterschiedlichen Kontexts am Anwendungsbeispiel demonstriert und dessen Eignung entsprechend der Anforderungen sowie ein Ausblick auf zukünftige Arbeiten diskutiert. Abschließend wird eine Zusammenfassung des Beitrags gegeben (Abschnitt 7).

2 Anforderungen an die automatisierte Testgenerierung

Durch Auswertung von realen industriellen Testprozeduren wurden mehrere Anforderungen an eine automatisierte Testgenerierung abgeleitet. Diese haben das Ziel, gleichwertige, konsistente und vollständige Testprozeduren für die Sicherheitstechnik von Sondermaschinen effizienter automatisiert zu generieren als bisher manuell möglich. Basierend auf Experteninterviews wurden Anforderungen an das Generierungsverfahren sowohl logischer als auch organisatorischer Natur ermittelt, welche im Folgenden diskutiert werden. Die befragten Experten entstammten vier Unternehmer: zweier repräsentativer Hersteller von Sondermaschinen, einem Unternehmen mit jahrzehntelanger Erfahrung in der Optimierung des ECAD-Einsatzes als Teil der Engineeringkette sowie einem ECAD-Softwareanbieter und Trainingsunternehmen für dessen Einsatz.

2.1 Format und Umfang der Testprozeduren

Eine der wichtigsten Voraussetzungen zur erfolgreichen Testdurchführung sind nach Ansicht der befragten Firmen konsistente, vollständige und maschinenspezifische Testanleitungen. Verbreitet in der Industrie sind hierzu Protokolle in Form von Checklisten. Hierin besteht ein Test zumeist aus mehreren chronologisch auszuführenden Schritten, welche entweder organisatorischer Natur und somit unabhängig von der Maschine sind, an einer einzelnen Komponente oder an einer Vielzahl unterschiedlicher Komponenten ausgeführt werden müssen. Eine im Kontext der Sicherheitstechnik besonders große Herausforderung ist hier die Sicherstellung der Testabdeckung und somit der explizite Test jeder Sicherheitskomponente und –funktion einer Maschine über die Domänen Mechanik, Elektrik und Informationstechnik hinweg. Dies erfordert wiederum die konkrete Verknüpfung und Anreicherung der Anweisungen mit maschinenspezifischen Charakteristika. Hierzu zählt zum einen die Instanziierung eines Testfalls für jedes Sicherheitsgerät. Wurden alle Geräte einer Maschine einzeln erfolgreich getestet, folgt der systematische Test aller Sicherheitsfunktionen, welche durch Interaktion einer Vielzahl von verbauten Geräten im Zusammenspiel implementiert werden.

Anforderung A1.Eine automatisiert generierte Testprozedur muss alle relevanten Aspekte der Sicherheitsgeräte und –funktionen einer spezifischen Ausprägung einer Sondermaschine abdecken.

2.2 Aufwandsminimierung zur maschinenspezifischen Modellerstellung

Neben einem möglichen Qualitätsgewinn der Testanleitungen hinsichtlich Abdeckung und Konsistenz durch den Einsatz von Testgenerierung ist ebenso ein Effizienzzuwachs bei der Testerstellung treibender Faktor der Industrie. Die Generierung von Testsuiten anhand Maschinenplänen als Modellen stellt einen Teilbereich des Modellbasierten Testens (MBT) dar. Der Einsatz von MBT ist für Firmen ökonomisch aber nur dann sinnvoll, wenn der zusätzlich notwendige Aufwand zur Modellerstellung die Defizite konventioneller Methoden nicht überwiegt. Dies ist im Sondermaschinenbau von besonders großer Relevanz. Im Unterschied zum Serienmaschinenbau müssen Modelle bei Produkten mit Losgröße 1 für jeden Auftrag spezifisch angepasst oder sogar von Grund auf neu erstellt werden. Eine Amortisierung durch vielfache Wiederverwendung eines identischen Modells ist hier nicht möglich. Ideal wäre es deshalb Dokumente zu verwenden, welche für die Konstruktion einer Maschine ohnehin bereits spezifisch erstellt werden müssen.

Anforderung A2.Die maschinenspezifische Testgenerierung muss anhand von Modellen erfolgen, welche ohne zusätzlichen Modellierungsaufwand zur Verfügung stehen.

2.3 Einmalige Formalisierung von Testfällen und Mapping-Kriterien

Die maschinenspezifische Generierung und Instanziierung von Testfällen anhand der Maschinenmodelle erfolgt im MBT anhand logischer Regeln. Diese Regeln müssen ebenso effizient und deterministisch erstellt werden können. Im Unterschied zu den Maschinenmodellen stellen Mapping-Kriterien eine Verknüpfung zwischen den variablen Modellen einer spezifischen Maschine und den zumeist statischen Testartefakten wie generischen Vorlagen dar. Sie benötigen daher eine ausreichende Parametrierbarkeit, ähnlich mit Suchmustern, um diese beiden Modelle zu verknüpfen, so dass sie nur einmalig definiert werden müssen und anschließend für viele Maschinen wiederverwendet werden können. Sie bilden die Information ab, an welchen Komponenten ein bestimmter Test ausgeführt werden muss.

Als Gegenstück zu den maschinenspezifischen Modellen sind abschließend Prototypen der zu generierenden Testfälle notwendig, welche mit Hilfe der Mapping-Kriterien maschinenspezifisch instanziiert werden, falls sie für eine Maschinenvariante zutreffend sind. Sie bilden hierzu firmenspezifische oder rechtliche Vorgaben ab, wie ein bestimmter Test durchzuführen ist.

Anforderung A3.Regeln zur Instanziierung von Testfällen auf Basis von Vorlagen sowie die Vorlagen selbst müssen nach einmaliger Definition für ein breites Spektrum an Maschinenvarianten eines Herstellers wiederverwendbar sein.

3 Bisherige Verfahren zur Testgenerierung

MBT bezeichnet ein Vorgehen, bei dem ausgehend von einem validen Modell eines Systems Under Test (SUT), bestehend aus Aufbau sowie Verhalten des Testobjekts, Testfälle zu dem Zweck abgeleitet werden, Abweichungen des realen Testobjektverhaltens vom modellierten Sollverhalten nachzuweisen oder das Vertrauen in die Übereinstimmung des Objektverhaltens mit dem Sollverhalten abzusichern [1]. Zur erfolgreichen Anwendung dieses Ansatzes im Sondermaschinenbau muss ein valides, variantenspezifisches Verhaltensmodell des aPS vorliegen, das alle für das Testen der Sicherheitstechnik relevanten Domänen des Systems wie Mechanik, Elektrik sowie Software abbildet und zudem effizient vom Hersteller erstellt werden kann.

Im Bereich des Software Engineering von aPS wurden bereits große Fortschritte hinsichtlich MBT erzielt. Weit verbreitet ist die Darstellung der Systemstruktur und des Systemverhaltens mittels formaler Modelle wie denen der UML, SysML oder Automaten [2], [3]. Genutzt werden unter anderen Sequenzdiagramme [4], Aktivitäts- und Use Case-Diagramme [5], [6], Zustandsdiagramme [7] sowie Timing-Diagramme und FMEA [8], um davon ausgehend automatisiert Tests des Systemverhaltens abzuleiten. [9] nutzen SPeNAt sowie [10] Ontologien zur Modellierung des Systemverhaltens aus Steuerungssicht sowie zur Generierung von sicherheitskritischen Testfällen. [11] nutzen Finite State Machines zur Beschreibung des Verhaltens der Steuerungssoftware. Auch wenn die betrachteten Ansätze in der Software-Domäne eine gute Testqualität und -abdeckung erzielen, sind Wechselwirkungen innerhalb der Maschinenhardware durch reine Softwaretests nur indirekt beobachtbar. Besonders im Kontext der Prüfung der Maschinensicherheit sind Funktionen teilweise redundant und deren Logik rein in Hardware umgesetzt, so dass deren Funktionsfähigkeit für die Steuerung unsichtbar bleibt.

Abb. 1 Extended Pick and Place Unit des Lehrstuhls für Automatisierung und Informationssysteme der Technischen Universität München.

Abb. 1

Extended Pick and Place Unit des Lehrstuhls für Automatisierung und Informationssysteme der Technischen Universität München.

[12] beschreibt einen Ansatz zur Modellierung aller Domänen von aPS mittels SysML4Mechatronics. Die umfassende Darstellung von Sicherheitsverschaltungen und deren Weiterverwendung zur Generierung systematischer Testsuiten fehlt aber bisher. In [13] wird ein semi-automatischer Ansatz zum Testen von aPS verfolgt, indem der Tester mittels Human Machine Interface in den Testablauf integriert wird. Testfälle müssen aber auch hier sowie in [14] einzeln manuell mit Hilfe eines Tabellenformats definiert werden.

Trotz eingehender Untersuchung und Fortschritten von Modelbasierten Systems Engineerings (MBSE) in der Wissenschaft, findet MBSE in der Industrie bisher noch wenig Anwendung [15]. Häufig werden ein fehlender Mehrwert und der zu große Aufwand zur Erstellung der Modelle als Hemmnisse der Industrie genannt [16]. Zur Aufwandsreduktion bei der Modellerstellung und dem MBT im variantenreichen Maschinenbau existieren eine Vielzahl möglicher Ansätze: [17] setzt beispielsweise Feature-Modellierung zur Erstellung der Verhaltensmodelle sowie der Selektion varianten-relevanter Testfälle ein. Gleiches gilt für eine Vielzahl etablierter Verfahren zum Modul- und Variantenmanagement in der variantenreichen Softwareentwicklung [18]. Laut einer Expertenbefragung unter führenden deutschen Herstellern von variantenreichen Maschinen werden Modelle soweit möglich aus Baukastensystemen konfiguriert, Modelle mittels Copy-Paste-Modify erstellt oder 200 %-Modelle manuell auf die jeweilige Maschinenvariante reduziert [19], [20]. Selbst unter Einsatz dieser Maßnahmen stellen Sondermaschinen mit Losgröße 1 jedoch eine Herausforderung dar. Alle betrachteten Methoden erfordern zumindest eine partielle Ähnlichkeit der aPS, sei es durch Aufbau aus einem ähnlichen Pool an Subsystemen oder der Überschneidung von Anforderungen oder Features. Zudem sind besonders die Verschränkungen der einzelnen Subsysteme für den Test der Sicherheitstechnik essentiell, die bei generischer Modellerstellung meist manuell ergänzt werden müssten. Wird die Sicherheitstechnik wie häufig als nichtfunktionale Anforderung modelliert, kann der Zusammenhang zu involvierten Features und Komponenten des Systems kaum erfasst werden oder erfordert die zusätzliche explizite Modellierung der Abhängigkeiten [21].

Zusammenfassend wurde bereits eine Vielzahl an Konzepten zum MBT von variantenreichen aPS untersucht. Diese Konzepte erfordern jedoch teilweise die gesonderte, zusätzliche Erstellung und Validierung spezialisierter SUT-Modelle je Maschinenausprägung z. B. im frühen Engineering. Weitere Konzepte betrachten nur einen Teil der für die Sicherheitstechnik von aPS relevanten Disziplinen der Mechanik, der Elektrik/Elektronik sowie der Software, was die Berücksichtigung essentieller interdisziplinärer Abhängigkeiten unmöglich macht. Eine dritte Gruppe an Ansätzen leitet die notwendigen Testfälle mittels gesonderter Maßnahmen zum Variantenmanagement her [22], die aber für aPS mit Losgröße 1 nicht geeignet sind. Keine der betrachteten Methoden unterstützt folglich bisher die Generierung von Testprozeduren für die Sicherheitstechnik des variantenreichen Sondermaschinenbaus. Ebenso wenig wurde bisher die Generierung domänenübergreifender Tests der Maschinensicherheit auf Grundlage von variantenspezifischen Bauplänen wie Stromlaufplänen betrachtet.

4 Einführung des Anwendungsbeispiels „xPPU“

Zusätzlich zu drei später für die Evaluation der vorgestellten Konzepte verwendeten industriellen Projekte wird im Folgenden ein Anwendungsbeispiel in Form eines Labordemonstrators vorgestellt, welches als Basis zur Erläuterung in den darauffolgenden Abschnitten dient.

Bei der extended Pick and Place Unit (xPPU) des Lehrstuhls für Automatisierung und Informationssysteme der Technischen Universität München handelt es sich um eine automatisierte Produktionsanlage mit Mechanik im verkleinerten Maßstab, jedoch ausgerüstet mit industrierealistischer Automatisierungstechnik und Funktionalität (Abbildung 1) [23]. Aufgabe der xPPU ist die Bearbeitung und Logistik verschiedener Werkstücke. Die Maschine verfügt hierfür über ca. 30 elektropneumatische Aktoren sowie 70 Sensoren und wird zentral von einer SPS gesteuert. Im Anwendungsfall werden im speziellen die Tests der Sicherheitsfunktionen der Maschine betrachtet. Die Sicherheitstechnik der Maschine ist Großteils fest verdrahtet und besteht aus einem globalen Sicherheitskreis. Der Nothalt wird mittels eines von fünf Nothalt-Tastern, eines Lichtvorhangs oder einer überwachten Zugangstür ausgelöst. Als Folge hiervon sollen mittels eines Sicherheitsschaltgeräts alle Aktoren der Maschine in den jeweiligen sicheren Zustand übergehen. Dies beinhaltet neben der Abschaltung der Leistungs- und Steuerungsspannung der meisten Aktoren auch die Abschaltung der Funktionen durch die Steuerungslogik der SPS selbst.

Für die xPPU existieren umfangreiche digitale Dokumente des ECAD wie Stromlauf-, Klemmen- und Schaltschrankaufbaupläne sowie exemplarische Testprozeduren, welche in enger Zusammenarbeit mit und umfangreicher Beratung durch Industriepartner erstellt worden sind und wie man sie auch für eine kommerzielle Maschine finden würde. Die Pläne wurden dabei wie in vielen Firmen heute üblich funktional und nicht anhand der Einbauorte der Geräte strukturiert. Die Benennung der Betriebsmittelkennzeichen (BMK) erfolgte nach EN 61346, erweitert durch eine firmenspezifische Nomenklatur. Die Dokumente liegen digital maschinenlesbar für die verbreitete ECAD-Umgebung e3.series der Zuken GmbH vor.

5 Konzept

Zur Realisierung einer automatisierten Testfallgenerierung für die Sicherheitstechnik einer Sondermaschine gemäß den identifizierten Anforderungen soll nun anhand der xPPU ein alternatives Konzept schrittweise aufgezeigt werden. Zur Abhilfe der Probleme bestehender Ansätze wäre es besser, die gewünschten Prozeduren zu Test und Fehlersuche aus detaillierten anlagenspezifischen Dokumenten der fortgeschrittenen Entwurfsphase vollautomatisch zu generieren, da diese ohnehin für die Ausfertigung der Anlage erstellt werden müssen. In modernen mechatronischen Automatisierungsanlagen scheinen hierfür besonders die Dokumente der Elektrokonstruktion wie Stromlauf- und Schaltschrankaufbaupläne geeignet zu sein, da diese sowohl den Informationsfluss als auch den elektrischen, pneumatischen und hydraulischen Energiefluss in der Anlage abbilden. Ebenso stellen sie die Schnittstelle zwischen Mechanik und Software dar. Durch eine Trennung der Dokumenterstellung in eine für die Produktfamilie einmalige Erstellung von Vorlagen und die anschließende variantenspezifische Generierung der Testsuite und Testartefakte durch Instanziierung und Parametrierung ließen sich die Mängel bisheriger Ansätze des MBT von automatisierten Sonderfertigungsanlagen beseitigen.

Aufbauend auf der Untersuchung gängiger, seitens der Industriepartner aktuell eingesetzter Dokumente und Verfahren zum Sicherheitstest sicherer variantenreicher Maschinen- und Anlagenautomatisierung, gliedert sich der neue Ansatz in folgende Schritte, deren Vorteile und Besonderheiten in den folgenden Unterkapiteln eingehend beschrieben werden:

  1. 1.

    Einmalige Erstellung generischer Basistestfälle für wiederkehrende Komponenten

  2. 2.

    Variantenspezifische Generierung von Testfällen mittels Mapping-Kriterien zwischen Testfallvorlagen und ECAD-Komponenten

  3. 3.

    Eliminierung von falsch-positiven Testmatches mittels Pfadverfolgung im ECAD

5.1 Einmalige Erstellung generischer Basistestfälle

Wie in Experteninterviews mit den industriellen Projektpartnern und durch Auswertung gängiger industrieller Testsuiten ermitteltet werden konnte, weisen aktuell in der Praxis eingesetzte Testfälle einen stark heterogenen Aufbau auf. Um diesen Charakter auch in diesem Konzept abbilden zu können, ist das den Testfall und -vorlagen zugrunde liegende Modell mit entsprechend großen Freiheitsgraden entworfen worden (Abbildung 2). Testfallvorlagen stellen Prototypen dar, auf deren Grundlage in folgenden Schritten maschinenspezifische Testfälle instanziiert und parametriert werden können. Jede Testfallvorlage kann dabei über beliebig viele Testschritte verfügen, mittels derer die einzelnen Schritte einer Testsequenz chronologisch repräsentiert werden können. Jeder dieser Testschritte kann wiederum aus beliebig vielen Anweisungen bestehen.

Abb. 2 Ausschnitt des Test-Datenmodells.

Abb. 2

Ausschnitt des Test-Datenmodells.

Auf Grundlage der untersuchten bestehenden Testprozeduren der Industrie besteht der Ablauf eines Testfalls generell aus vier Phasen (Abbildung 3), welche als beliebig viele Testschritte modelliert werden:

  1. 1.

    Dem Wechsel des SUT in definierte Vorbedingungen, z. B. Aktivierung des Automatikmodus der xPPU und Anfahren der Förderbänder

  2. 2.

    Der Stimulation einer Komponente, z. B. Unterbrechen des Lichtvorhangs

  3. 3.

    Der Beobachtung oder Messung der Testbedingung in Form der Reaktion einer Komponente auf die Stimulation, z. B. Stopp eines Förderbandes prüfen, sowie Entscheidung über Erfolg oder Fehlschlag des Tests

  4. 4.

    Die Rücksetzung des Testsubjekts auf definierte Nachbedingungen, z. B. Rücksetzen des Nothalts

Wie in Abschnitt 2 beschrieben, können drei verschiedene Typen von Testfallvorlagen unterschieden werden, abhängig von der Anzahl involvierter Testkomponenten:
  1. Komponententests, welche eine einzelne spezifische Hardwarekomponente testen, z. B. Dokumentation der Seriennummer eines Notaustasters der xPPU.

  2. (Sub-)Systemtests, bei denen während des Tests eine spezifische Komponente manipuliert, der Effekt jedoch an einer anderen Komponente beobachtet wird, z. B. Abschaltverhalten eines Förderbandmotors beim Auslösen eines Notausschalters.

  3. Komponentenunabhängige Tests, welche die gesamte Maschine betreffen und nicht einzelnen Komponenten zugeordnet werden können, z. B. Absperren des Arbeitsbereichs vor Beginn der Sicherheitstests.

Für jeden Testschritt kann jeweils eine Komponente, an der potentiell eine Aktion durchzuführen ist, in Abhängigkeit des Vorlagentyps generisch referenziert werden. Diese Komponente wird auch Testkontext genannt. Ein Platzhaltersystem erlaubt dabei eine Parametrierung der Tests während der Instanziierung und somit die ergonomische Darstellung der Tests für den Tester, z. B. durch Einsetzen von Komponentennamen oder –attributswerten. Der Kontext kann dabei komponentenunabhängig auf nichts, auf die Stimulationskomponente oder die Observationskomponente gesetzt werden. Während atomare Komponententests analog zu Unittests aus dem Softwareengineering lediglich die Funktionalität einer einzelnen Komponente überprüfen, decken (Sub-)Systemtests die Funktionalität zweier miteinander verbundener Komponenten sowie der dazwischenliegenden Komponenten im Zusammenspiel ab. Komponentenunabhängige Tests wurden im Modell zur Vereinfachung den Vorlagen der Komponententests zugeordnet, bei denen lediglich kein Testkontext gesetzt wird. Eine Komponente kann einem Testschritt dabei z. B. zur Stimulation und im nächsten Testschritt eine andere für die Beobachtung einer Testreaktion zugewiesen werden. Auf diese Weise können ebenfalls Tests von Sicherheitsrelais einschließlich des dazwischenliegenden Signalpfads abgebildet werden: Wird ein bestimmter Nothalt-Taster ausgelöst, erhält der Benutzer so Anweisungen, entsprechend der Anforderungen den Zustand aller beobachtbaren Komponenten im Signalpfad bis hin zum zugehörigen Sicherheitsrelais und der Anzeige im Human-Machine-Interface zu überprüfen.

Abb. 3 Standardmodell eines Testablaufs.

Abb. 3

Standardmodell eines Testablaufs.

5.2 Variantenspezifische Generierung von Testfällen

Für die variantenspezifische Generierung der Testfälle auf Grundlage von einmalig durch Experten spezifizierten Testfallvorlagen wurden abhängig vom Typ der Vorlage geeignete Mapping-Kriterien zwischen Vorlagen und Maschinenkomponenten identifiziert. Das Mapping aller Testfälle erfolgt dabei basierend auf ECAD-Dokumenten, selbst von Testfällen welche Mechanik oder Softwarefunktionalität einschließen. Zur Identifikation bekannter Komponenten im ECAD wurden wiederkehrende Gruppen von Testfällen in bestehenden industriellen Checklisten auf Gemeinsamkeiten hin untersucht. Basierend auf Analysen von Unterlagen mehrerer Firmen des Sondermaschinenbaus konnten dabei sowohl Muster in BMKs als auch z. B. Artikelnummern als geeignete Zuordnungskriterien ermittelt werden. Am Beispiel von e3.series der Zuken GmbH wurde ein Datenmodell erstellt, welches die geeignetsten Merkmale für ein Mapping aufzeigt (Abbildung 4). Ein Gerät bezeichnet dabei die logische Instanz eines Betriebsmittels im Stromlaufplan. Es ist Träger des BMK. Dem Gerät kann eine Komponente zugewiesen werden, welches einem realen Bauteil entspricht. Ein Gerät muss dabei nicht zwingend über eine Komponente verfügen, z. B. im Fall von Dummygeräten wie Erdungspunkten. Symbole stellen in der Objektstruktur die grafischen Repräsentanzen eines Geräts im Stromlaufplan dar. Alle diese Objekte können zudem über benutzerdefinierte und firmenspezifische Attribute in Form von Schlüssel-Wert-Paaren verfügen. Einen Sonderfall stellen Betriebsmittelgruppen dar, da diese aus mehreren Geräten bestehen, welche einer übergeordneten Betriebsmittelgruppe zugeordnet sind und alle dasselbe BMK besitzen. Die Geräte verfügen aber immer noch über unterschiedliche Attribute und können somit anhand dieser in allen untersuchten Anwendungsfällen unterschieden werden.

Abb. 4 Ausschnitt eines ECAD-Datenmodells.

Abb. 4

Ausschnitt eines ECAD-Datenmodells.

Manche Komponenten wie Pneumatikventile können sowohl sicherheitsrelevant als auch -irrelevant eingesetzt werden. Viele Firmen verwenden hierfür bereits interne Namenskonventionen und frei definierbare Zusatzattribute im ECAD-Modell, um z. B. den zugehörigen Sicherheitskreis zu hinterlegen und somit zur Klassifikation einzusetzen. Alle komponentenunabhängigen Tests mussten in den betrachteten Use Cases für alle Ausprägungen einer Maschinenfamilie durchgeführt werden, weshalb hier keine zusätzlichen Filtermechanismen notwendig sind. Komponententests jedoch können durch eine Kombination von Regulären Ausdrücken sowie boolescher Algebra verbauten Komponenten zugeordnet werden. Dabei können die Suchmuster sowohl positiv als auch negativ formuliert werden. Durch direkten Zugriff über eine Programmierschnittstelle (API) auf die maschinenlesbaren ECAD-Dokumente stehen sämtliche Bauteilattribute sowie das BMK für das spätere Mapping der Komponententestfallvorlagen zur Verfügung. Um die Skalierbarkeit der Algorithmen auf Projekte industrieller Größe zu gewährleisten, kommen Caching-Mechanismen zum Einsatz. Dabei werden alle relevanten Daten (vgl. Abbildung 4) vor Beginn der Testgenerierung via API ausgelesen und in vorab optimierten Datenstrukturen relational abgelegt. Nach Auswahl aller gewünschten Vorlagen durch einen Testingenieur werden die Suchmuster iterativ mit den einzelnen Betriebsmitteln abgeglichen und somit auf die für die jeweiligen Testfallvorlagen relevanten Geräte reduziert.

Für das Mapping von Systemtestfallvorlagen können zu Anfang ebenfalls die Kriterien der Komponententests zur Identifikation der Manipulations- und Observationskomponenten angewendet werden. Durch Permutation aller so gefundenen Komponenten ergeben sich eine Vielzahl an möglichen Komponentenpaaren, welche aber nicht zwingend miteinander interagieren und für die ein Mapping eines Tests somit nur potentiell sinnvoll wäre (Abbildung 5). Bereits in dieser Stufe der Testgenerierung von Systemtests können aber falsch-positive Tupel eliminiert werden. Häufig teilen miteinander verschaltete Komponenten in industriellen Anlagen auf Grund firmenspezifischer Nomenklatur Teile ihrer Benennung, wie z. B. einen Laufindex. Diese Eigenschaft kann mittels Backreferences innerhalb der Regulären Ausdrücke genutzt werden, um gleiche Fragmente der Benennung im Suchmuster zu annotieren und so lediglich Gerätepaarungen mit gleicher Nummerierung zu testen. Beispielsweise soll –QM2 mit –M2 und –QM3 mit –M3 getestet werden aber nicht kreuzweise.

Abb. 5 Exemplarische Mapping-Kriterien eines Systemtests.

Abb. 5

Exemplarische Mapping-Kriterien eines Systemtests.

5.3 Eliminierung von falsch-positiven Testmatches mittels Pfadverfolgung

Wurden mittels der Suchmuster aus Abschnitt 5.2 mögliche Komponentenpaare zur Instanziierung von Systemtests aus Testfallvorlagen identifiziert, müssen falsch-positive Suchtreffer und somit unnötige oder gar falsche Tests eliminiert werden. Hierfür kann im nächsten Schritt überprüft werden, ob diese Paarungen an Komponenten in der finalen Maschine miteinander interagieren. Existieren beispielsweise mehrere Nothalt-Taster und mehrere Aktoren in einer Anlage, können diese zwar mittels ihrer Attribute gefunden werden, besonders aber in Anlagen mit mehreren Sicherheitszonen muss nicht jeder Aktor für jeden Sicherheitstaster abgeschaltet werden. Da ein Stromlaufplan umfangreiche Informationen über Signal- und Energiefluss innerhalb der Maschine enthält, kann durch dessen Analyse automatisiert festgestellt werden, ob zwei Komponenten eines Systems miteinander interagieren und somit gemeinsam getestet werden müssen. Die exakte Funktionsweise der entwickelten Pfadverfolgung soll nicht im Fokus dieses Beitrags liegen. Im Gegensatz zu konventionellen ECAD-Systemen können Signale hiermit jedoch auch über Bauteile mit veränderlicher interner Kontaktierung wie z. B. einem Schütz hinweg verfolgt werden. Hierzu ist die Einbeziehung einmalig annotierter Informationen über den bauteilinternen Signalfluss der Bauteile notwendig. Die Annotation erfolgt jedoch auf Typenebene und kann so für eine Vielzahl an Bauteilinstanzen auf einfache Weise wiederverwendet werden. (Abbildung 6)

Abb. 6 Exemplarische Pfadverfolgung von Stromeinspeisung bis Aktor.

Abb. 6

Exemplarische Pfadverfolgung von Stromeinspeisung bis Aktor.

Ausgehend vom Stimulationsgerät eines potentiellen Tests wird der Pfad zum Observationsgerät im Stromlaufplan mittels Breitensuche vorwärts bis zu mehreren parametrierbaren Abbruchkriterien gesucht. Da Signalpfade sowie deren Testabdeckung in realen Maschinen sehr komplex gestaltet sein können, wurden auch für die Signalpfadverfolgung Algorithmen entwickelt und um Optionen zur Anpassung und Filterung der Suche ergänzt, um die Korrektheit und die Skalierbarkeit der Suchergebnisse auch für Stromlaufpläne von industriellem Umfang sicherzustellen (Abbildung 7). Im Fall des Sauggreifers der xPPU, welcher bei Nothalt ein gegriffenes Werkstück nicht lösen darf, kann z. B. ebenso nach Tupeln gefiltert werden, die über keinen gültigen Signalpfad zur Abschaltung verfügen. Somit können auch Tests zur Prüfung dieses sicheren Zustands generiert werden.

Abb. 7 Optimierungsdialog für Pfadsuche und Systemtestgenerierung.

Abb. 7

Optimierungsdialog für Pfadsuche und Systemtestgenerierung.

6 Exemplarische Anwendung und Evaluation

Zur Bewertung des vorgestellten Konzepts wurden die Algorithmen prototypisch implementiert und eingehende Versuche mit vier Sondermaschinen mittels der ECAD-Software e3.series der Zuken GmbH durchgeführt: der xPPU sowie als drei industriellen Beispielen einem Kühlwasserpumpsystem, einer Verpackungsanlage und einer hydraulischen Presse. Im Fall der Kühlwasserpumpe wurden mehrere repräsentative Tests entsprechend des Konzepts formalisiert und anschließend vollautomatisch generiert. Die hierzu für die Pfadverfolgung im Vorfeld einmalig notwendige Annotation der ECAD-Bauteildatenbank durch einen Konstrukteur betrug für die 285 einzigartigen Komponenten circa sechs Stunden.

Organisatorische Tests finden zumeist zu Beginn einer Inbetriebnahme oder eines Sicherheitstests statt. Für die xPPU wurde die Absperrung des Arbeitsbereichs vor Testbeginn exemplarisch als komponentenunabhängiger Test modelliert. Eine komponentenunabhängige Testfallvorlage wird immer exakt einmal instanziiert, was auch den konventionell erstellten Testanleitungen entspricht.

Ein typischer Gerätetest der xPPU, welcher im Kontext einer Sicherheitsprüfung häufig durchgeführt wird, ist die Kontrolle aller Seriennummern der sicherheitskritischen Komponenten. Bei den Nothalt-Tastern der xPPU handelt es sich um speziell für sicherheitskritische Anwendungen entwickelte Taster der Firma Siemens. Da diese Taster in der xPPU ausschließlich für diesen Zweck Verwendung finden, können sie beispielsweise über den Artikelnamen der zugeordneten Komponenten im ECAD-Datenmodell problemlos identifiziert und ein Test instanziiert werden. Ebenso können die Türüberwachung anhand dessen Sensors und der Lichtvorhang identifiziert und durch Nutzung von Boolescher Algebra im selben Mapping-Pattern berücksichtigt werden. Der entsprechende Reguläre Ausdruck für das Attribut „Component Name“ lautet beispielsweise „3SB3201-1HA20|1016477|1016478|6025100“.

Für den Test des Sicherheitskreises der Anlage müssen entsprechend der Sicherheitsverriegelungen alle Nothalt-Sensoren zusammen mit dem Anhalten der Bewegung aller relevanten Aktoren der xPPU getestet werden. Zusätzlich notwendig ist jedoch auch die Kontrolle der Abschaltung von Softwarelogik, Steuer- sowie Leistungsspannung der Aktoren. Wie soeben beschrieben können alle Nothalt-Sensoren mittels Artikelnummern identifiziert werden. Anhand der Artikelnummern können ebenso alle Pneumatikventile und Elektroantriebe der xPPU identifiziert und gemeinsam mit den Sensoren zu potentiellen Testsubjekttupeln permutiert werden. Im nächsten Schritt wird anhand des Stromlaufplans der xPPU ermittelt, ob zwischen den potentiellen Testpaaren jeweils eine elektrische Verbindung besteht. Da die meisten Aktoren der xPPU im sicheren Zustand gestoppt werden müssen, ist diese Suche für die Mehrzahl der Aktoren erfolgreich, woraufhin die vollständigen Testprozeduren korrekt erzeugt werden. Aktoren wie z. B. ein pneumatischer Sauggreifer der xPPU, welche im sicheren Zustand explizit nicht deaktiviert werden dürfen, sind elektrisch nicht mit dem zentralen Sicherheitsschaltgerät verbunden und erhalten somit auch keine Testinstanz für diese Vorlage. Die Abschaltung der Steuer- und Leistungsspannung kann visuell z. B. am Leistungssteller der Motoren überprüft werden. Der zu einem Motor gehörige Leistungssteller kann ebenso über dessen Artikelnummer und den gefundenen Signalpfad identifiziert sowie in den Test eingeschlossen werden. Die Abschaltung der Softwarelogik kann z. B. anhand einer LED an der Ausgangsklemme der SPS verifiziert werden. Diese enthielten in den betrachteten Beispielen im ECAD das BMK oder den Softwarevariablennamen des gesteuerten Aktors als Attribut, was zusammen mit der Pfadverfolgung die Erstellung eines gesonderten Tests der Logikspannung über die diskutierten Mapping-Kriterien ermöglicht.

Die Evaluation des Softwareprototypen anhand der industriellen Anwendungsfälle verlief ebenso erfolgreich. Im ersten Fall wurden fast 50 % einer aktuell produktiv eingesetzten Inbetriebnahme-Checkliste in die Softwareprototypen eingepflegt und erfolgreich vollautomatisch reproduziert. Für alle enthaltenen Testschritte konnten ohne bzw. selten mit minimalen Anpassungen der Stromlaufpläne geeignete Marker für die vollautomatische Testgenerierung in den Stromlaufplänen identifiziert werden. Seitens des zweiten Anwendungsfalls wurden die Softwareprototypen anhand eines Teilausschnitts einer aktuell produzierten Maschine in Form eines vertikalen Durchstichs evaluiert. Trotz Selektion besonders schwierig zuzuordnender Testfälle konnten auch hier die gewünschten Checklistenausschnitte auf Grundlage der Testfallvorlagen wie angestrebt vollautomatisch reproduziert werden. Die notwendige Rechenzeit für die Generierung der Testsuite betrug jeweils nur wenige Minuten. Obwohl die Softwareprototypen speziell für die ECAD-Umgebung e3.series umgesetzt worden sind, wurde die Übertragbarkeit der Konzepte auch auf andere ECAD-Systeme von zwei befragten Beratungsunternehmen im Bereich der Elektroprojektierung als sehr gut eingeschätzt. Für künftige praktische Versuche mit anderen Softwaresuiten müsste das partielle ECAD-Datenmodells für e3.series auf ein voraussichtlich sehr ähnliches Modell der zu erprobenden Suite gemappt sowie die Softwareprototypen für die jeweils hochgradig herstellerspezifische API adaptiert werden. Bereits im prototypischen Implementierungsstand konnte die Funktionsweise der Konzepte mit e3.series erfolgreich nachgewiesen werden. Es konnten alle erprobten Tests realer industrieller Anwendungsfälle mit Hilfe des Systems vollautomatisch reproduziert werden (vgl. A1). Die maschinenspezifischen Informationen für das Mapping der Testfälle auf Komponenten der realen Anlage konnten Großteils aus den Stromlauf- und Schaltschrankaufbauplänen einer Maschine entnommen werden. Die notwendigen Zusatzattribute könnten nach Einschätzung der industriellen Experten bei Bedarf künftig in die firmeneigene Bauteildatenbank einmalig integriert und somit automatisch für weitere Projektierungen übernommen werden. Die Aktualisierung von Bauteilen eines vorhandenen Stromlaufplans mit neueren Bauteilversionen aus einer Datenbank stellt eine Standardfunktionalität vieler ECAD-Umgebungen dar und ermöglicht somit auch die effiziente Anwendung der Konzepte auf bereits existierende Maschinen (vgl. A2). Die Wiederverwendbarkeit der einmalig spezifizierten Testfallvorlagen und Mapping-Kriterien war in den betrachteten Anwendungsfällen vollständig gegeben. Dies beruht vor allem auf etablierten firmeneigenen Namenskonventionen, welche für alle Sondermaschinen eines Herstellers verwendet werden. Im Fall eines Entwicklungsdienstleisters, der die Nomenklatur des jeweiligen Auftraggebers einsetzt, könnten aber dennoch zumindest die Benennungsregeln der EN 61346 sowie die Komponentenattribute seitens der Zulieferer wie Artikelnummer oder –name verwendet werden. (vgl. A3)

Zukünftiges Verbesserungspotential liegt zum einen in der möglichen Fusion von Tests. Haben mehrere Tests dieselben Vorbedingungen und Stimulationen könnten die Beobachtungen der einzelnen Tests zeitgleich durchgeführt werden ohne die Stimulation zu wiederholen. Zum anderen konnten während der Erprobung große Ähnlichkeiten zwischen der Verfolgung von Strompfaden und der von Hydraulik- und Pneumatikpfaden aufgezeigt werden. Durch Erweiterung der Konzepte könnten somit künftig auch diese teilweise im ECAD enthaltenen Pläne in die Auswertungen eingeschlossen werden.

7 Zusammenfassung

Der Beitrag zeigte eine Methode zur vollständig automatisierten Generierung von Testprozeduren für die Sicherheitstechnik von variantenreichen automatisierten Sondermaschinen anhand von ECAD Dokumenten. Basierend auf der Analyse industrieller Testprozeduren wurden drei generische Testklassen abgeleitet sowie ein partielles ECAD-Datenmodell eingeführt. Anhand von Suchmustern in Betriebsmittelkennzeichen und Bauteilattributen sowie einmalig erstellter generischer Vorlagen wurden mittels Konstruktionsdokumenten wie Stromlauf- oder Schaltschrankaufbauplänen maschinenspezifische Testabläufe erstellt. Zur Filterung von falsch-positiv identifizierten (Sub-)Systemtests wurde die Möglichkeit einer Signalpfadsuche eingeführt, um die Interaktion zwischen möglichen Testkomponenten zu verifizieren. Basierend auf einem akademischen Labordemonstrator sowie drei industriellen Use Cases wurde das Konzept anschließend exemplarisch angewendet und erfolgreich evaluiert. Dadurch konnten das Potential der Methode sowie künftige Verbesserungsmöglichkeiten aufgezeigt werden. Der Fokus der weiteren Arbeiten wird somit auf der Fusion von überlappenden Testfällen, der Auswertung komplexerer Netzwerkstrukturen sowie der Einbeziehung von Pneumatik und Hydraulik in die Betrachtungen liegen.

Funding statement: Teile der beschriebenen Konzepte und Ergebnisse wurden im Rahmen des Projekts EfiMA – „Effiziente Fehlersuche für sichere variantenreiche Maschinen- und Anlagenautomatisierung“ – erarbeitet, welches durch die Bayerische Forschungsstiftung gefördert wird.

Literatur

1. M. Utting, A. Pretschner and B. Legeard, “A taxonomy of model-based testing approaches,” Softw. Testing, Verif. Reliab., vol. 22, no. 5, pp. 297–312, Aug. 2012, doi: 10.1002/stvr.456. Search in Google Scholar

2. A. C. Dias Neto, R. Subramanyan, M. Vieira and G. H. Travassos, “A survey on model-based testing approaches,” pp. 31–36, 2008, doi: 10.1145/1353673.1353681. Search in Google Scholar

3. J. Zander, I. Schieferdecker and P. J. Mosterman, Model-Based Testing for Embedded Systems. 2017. Search in Google Scholar

4. M. Reider, S. Magnus and J. Krause, “Feature-based testing by using model synthesis, test generation and parameterizable test prioritization,” Proc. – 2018 IEEE 11th Int. Conf. Softw. Testing, Verif. Valid. Work. ICSTW 2018, pp. 130–137, 2018, doi: 10.1109/ICSTW.2018.00041. Search in Google Scholar

5. J. Hartmann, M. Vieira, H. Foster and A. Ruder, “A UML-based approach to system testing,” Innov. Syst. Softw. Eng., vol. 1, no. 1, pp. 12–24, 2005, doi: 10.1007/s11334-005-0006-0. Search in Google Scholar

6. R. Hametner, D. Winkler, T. Östreicher, S. Biffl and A. Zoitl, “The adaptation of test-driven software processes to industrial automation engineering,” IEEE Int. Conf. Ind. Informatics, pp. 921–927, 2010, doi: 10.1109/INDIN.2010.5549620. Search in Google Scholar

7. R. Hametner, B. Kormann, B. Vogel-Heuser, D. Winkler and A. Zoitl, “Test case generation approach for industrial automation systems,” ICARA 2011 – Proc. 5th Int. Conf. Autom. Robot. Appl., pp. 57–62, 2011, doi: 10.1109/ICARA.2011.6144856. Search in Google Scholar

8. S. Rösch, Model-based testing of fault scenarios in production automation. sierke VERLAG – Internationaler Wissenschaftsverlag, 2016. Search in Google Scholar

9. J. Krause and C. Diedrich, “Modellbasierte Testgenerierung aus Spezifikationen mit parallelem Verhalten,” GI Jahrestagung, pp. 333–338, 2010. Search in Google Scholar

10. R. Sinha, C. Pang, G. S. Martinez, J. Kuronen and V. Vyatkin, “Requirements-Aided Automatic Test Case Generation for Industrial Cyber-physical Systems,” Proc. IEEE Int. Conf. Eng. Complex Comput. Syst. ICECCS, vol. 2016-Janua, pp. 198–201, 2016, doi: 10.1109/ICECCS.2015.32. Search in Google Scholar

11. J. Provost, J. M. Roussel and J. M. Faure, “Testing programmable logic controllers from finite state machines specification,” 2011 3rd Int. Work. Dependable Control Discret. Syst. DCDS’11 – Conf. Proc., pp. 1–6, 2011, doi: 10.1109/DCDS.2011.5970309. Search in Google Scholar

12. K. E. T. Kernschmidt, Interdisciplinary structural modeling of mechatronic production systems using SysML4Mechatronics. 2019. Search in Google Scholar

13. S. Ulewicz and B. Vogel-Heuser, “Guided semi-automatic system testing in factory automation,” IEEE Int. Conf. Ind. Informatics, pp. 142–147, 2017, doi: 10.1109/INDIN.2016.7819148. Search in Google Scholar

14. A. Weigl et al., “Generalized test tables: A powerful and intuitive specification language for reactive systems,” Proc. – 2017 IEEE 15th Int. Conf. Ind. Informatics, INDIN 2017, pp. 875–882, 2017, doi: 10.1109/INDIN.2017.8104887. Search in Google Scholar

15. B. Vogel-Heuser and F. Ocker, “Maintainability and evolvability of control software in machine and plant manufacturing — An industrial survey,” Control Eng. Pract., vol. 80, no. December 2017, pp. 157–173, 2018, doi: 10.1016/j.conengprac.2018.08.007. Search in Google Scholar

16. B. Motamedian, “MBSE Applicability Analysis,” Int. J. Sci. Eng. Res., vol. 4, no. 2, pp. 1–7, 2013. Search in Google Scholar

17. A. Arrieta, G. Sagardui, L. Etxeberria and J. Zander, “Automatic generation of test system instances for configurable cyber-physical systems,” Softw. Qual. J., vol. 25, no. 3, pp. 1041–1083, 2017, doi: 10.1007/s11219-016-9341-7. Search in Google Scholar

18. E. Neumann, J. Fischer, F. Ocker, S. Diehm, M. Schwarz and B. Vogel-heuser, “Formalization of Design Patterns and Their Automatic Identification in PLC Software for Architecture Assessment,” accepted IFAC World Conference 2020, IFAC-PapersOnLine, vol. 53, no. 1, 2020. Search in Google Scholar

19. D. Schäfer, Variantentechnologie unter besonderer Berücksichtigung von Elektrotechnik-CAD. Shaker, 2003. Search in Google Scholar

20. B. Vogel-Heuser, J. Fischer, S. Feldmann, S. Ulewicz and S. Rösch, “Modularity and architecture of PLC-based software for automated production Systems: An analysis in industrial companies,” J. Syst. Softw., vol. 131, pp. 35–62, 2017, doi: 10.1016/j.jss.2017.05.051. Search in Google Scholar

21. A. Rink, Entwicklung einer Methode für die systemtechnische Auslegung verteilter und sicherheitskritischer Führungsfunktionen für Fahrzeugantriebe. Bergische Universität Wuppertal, 2002. Search in Google Scholar

22. S. Rösch, S. Ulewicz, J. Provost and B. Vogel-Heuser, “Review of Model-Based Testing Approaches in Production Automation and Adjacent Domains-Current Challenges and Research Gaps,” J. Softw. Eng. Appl., vol. 08, no. 09, pp. 499–519, 2015, doi: 10.4236/jsea.2015.89048. Search in Google Scholar

23. B. Vogel-Heuser, C. Legat, J. Folmer and S. Feldmann, “Researching Evolution in Industrial Plant Automation: Scenarios and Documentation of the Pick and Place Unit,” Tech. Rep., no.  TUM-AIS-TR-01-14-02, 2014. Search in Google Scholar

Erhalten: 2020-02-26
Angenommen: 2020-03-26
Online erschienen: 2020-04-30
Erschienen im Druck: 2020-05-27

© 2020 Ziegltrum and Vogel-Heuser, publiziert von De Gruyter

This work is licensed under the Creative Commons Attribution 4.0 Public License.