Ein toolgestützter Ansatz für die benutzerfreundliche Definition von Funktionsbaustein-Einschränkungen

1 Einleitung

Konzepte wie Modularisierung, Abstraktion und ereignisgesteuerte Programmierung helfen, die Komplexität von Software in cyber-physischen Produktionssystemen zu beherrschen [1]. Vor diesem Hintergrund wurden domänenspezifische Modelliersprachen entwickelt, beispielsweise für eingebettete Systeme [1,2]. Verschiedene Ansätze erlauben weiters die Entwicklung von verteilten Anwendungen in der Automatisierungstechnik. Auch die in der IEC 61499^[1] definierte Modelliersprache legt den Schwerpunkt auf die Verteilbarkeit und die hierarchische Strukturierung von Steuerungssoftware. Die wiederverwendbaren Komponenten (sogenannte Funktionsbausteine, FB) können wiederum aus einer beliebigen Anzahl von FB bestehen. Alternativ kann die Funktionalität eines FB als Zustandsdiagramm oder in einer der Programmiersprachen aus IEC 61131-3^[2] implementiert werden. IEC 61499 sieht keine globalen Variablen vor und lässt Interaktionen zwischen FB nur über deren Schnittstellen zu, was die Wiederverwendbarkeit fördert [2]. Die Funktionalität der Steuerungssoftware wird nach IEC 61499 im Applikationsmodell definiert, das sich aus Instanzen von Bibliotheksbausteinen sowie aus Verbindungen zusammensetzt (Funktionsbausteindiagramm). Die Norm definiert die ereignisgesteuerte Ausführung des Applikationsmodells, wodurch eine gezielte Steuerung der Ausführungsreihenfolge von FB ermöglicht wird. Implizite Annahmen über die korrekte Verwendung eines FB werden derzeit jedoch nicht systematisch erfasst, weshalb die (Wieder-)verwendung von komplexen Bibliotheksbausteinen eine umfangreiche Dokumentation oder Expert*innenwissen erfordert. Das Fehlen solcher Informationen erschwert auch die Bereitstellung effizienter Entwicklungswerkzeuge. Die Wiederverwendung funktionierender Teillösungen erleichtert allgemein die effiziente Erstellung korrekter Software [3].

Die IEC 61499 unterstützt die Modellierung des erwarteten Verhaltens eines FB im Dienstsequenzdiagramm. Diese beschreiben jene Ereignisse, die an der Schnittstelle beobachtet werden können. Eine Beispielsequenz ist in Abbildung 1 dargestellt. Jedes Ereignis wird als Telegramm modelliert. Die IEC 61499 beschreibt ein Anforderungstelegramm als Aufruf eines im FB enthaltenen Algorithmus. Es ist Teil einer Transaktion, zusammen mit einem oder mehreren Bestätigungstelegrammen. Telegramme können grundsätzlich auch Datenwerte enthalten (sogenannte Parameter). Die normierte Semantik für Parameter beschränkt sich auf Ereignisse, die mit einer booleschen Eingangsvariable kombiniert werden. Für andere Ereignisse sollen die Namen der relevanten Variablen als Parameter des Telegramms spezifiziert werden.

Abbildung 1:

Struktur einer Dienstsequenz, die den Ereignisfluss an der äußeren Schnittstelle eines FB erfasst. Die Ereigniseingänge EE1, EE2 und der Ereignisausgang EA1 sind erfasst. Jede Transaktion beinhaltet ein Anforderungstelegramm und eine beliebige Anzahl an Bestätigungstelegrammen. Jedes Telegramm besteht aus einem Ereignis und Parametern.

Derzeit sind Modelle des erwarteten Bausteinverhaltens nicht in den Entwicklungsprozess von IEC 61499-Software integriert, sondern dienen bestenfalls als Dokumentation. Die in der Praxis seltene Verwendung von Dienstsequenzdiagrammen könnte durch (halb)automatische Erfassung von Verhaltensdiagrammen verbessert werden. Daher wollen wir Entwickler*innen dabei unterstützen, geforderte oder verbotene Abläufe für einen FB festzulegen. Dazu verwenden wir eine im Vergleich zum Standard IEC 61499 angepasste Variante von Dienstsequenzmodellen. Dadurch unterstützen wir die bereits vorgestellten Konzepte, die auf Dienstsequenzmodellen beruhen und diese Anpassungen teilweise bereits umgesetzt haben. Basierend auf zufällig generierten und/oder manuell definierten Eingangsereignissen analysieren wir das Verhalten des FB und visualisieren es als Dienstsequenz. Entwickler*innen klassifizieren die so erstellten Modelle. Die komponentenorientierte Architektur erlaubt weiters bei Bedarf eine Erweiterung auf andere Notationen von Sequenzdiagrammen.

Unsere Hauptbeiträge sind (i) eine Adaption der IEC 61499, um die Klassifizierung von Dienstsequenzen zu erlauben, (ii) der vorgestellte Ansatz zur benutzerfreundlichen Definition von FB-Einschränkungen als Dienstsequenz und (iii) die Möglichkeit zur automatischen Erzeugung von Überwachungsbausteinen aus Dienstsequenzen. Der Ansatz basiert auf unserer Infrastruktur zur Interpretation von IEC 61499-Modellen [4] und ist kompatibel mit allen in der IEC 61499 definierten Arten von FB. Der vorliegende Artikel erweitert den Konferenzbeitrag [5]. Alle entwickelten Werkzeuge werden als Teil des Open-Source-Projekts Eclipse 4diac™^[3] veröffentlicht.

2 Wissenschaftlicher Hintergrund

In der Automatisierungstechnik verwendete Modelliersprachen sind die Unified Modeling Language (UML), die davon abgeleitete Systems Modeling Language (SysML) sowie domänenspezifische Modelliersprachen [6]. Die Adaption einer bekannten Modelliersprache bringt Vorteile hinsichtlich der Akzeptanz durch Nutzer*innen und der Verfügbarkeit von Modellierwerkzeugen im Vergleich zur Einführung gänzlich neuer Ansätze [6]. Die in diesem Artikel vorgestellte Methode zur Definition von FB-Einschränkungen verwendet daher eine Variante der in der IEC 61499 normierten Dienstsequenzdiagramme.

Dienstsequenzdiagramme können bei der Erstellung von IEC 61499-Modellen für Synthese [7], Test [8] oder Überwachung [9] von Funktionalität genutzt werden. Die Diagramme beschreiben in erster Linie, wie ein Dienst aufzurufen ist. Dorofeev et al. [7] synthetisierten einen Orchestrierungs-FB, welcher untergeordnete Funktionalitäten gemäß der in den jeweiligen Bausteintypen spezifizierten Dienstsequenzen aufruft. Hametner et al. [8] realisierten ein Konzept zur Nutzung von Dienstsequenzmodellen als Grundlage für Softwaretests. Erwartete Datenwerte werden im Parameterfeld festgelegt, wobei eine im Vergleich zur Norm leicht angepasste Schreibweise verwendet wird. Die Autoren merkten die eingeschränkte Ausdrucksfähigkeit von Dienstsequenzdiagrammen an und schlugen eine Erweiterung mit zusätzlichen Sprachelementen vor. Die vorgeschlagenen Möglichkeiten zum Aufruf von Unterprogrammen, Schleifen und Verzweigungen sind zum Beispiel in den Sequenzdiagrammen der UML^[4] vorhanden. Wenger et al. [9] beschrieben eine Methode zur Überwachung des Bausteinverhaltens direkt in der Ausführungsumgebung, wobei das erwartete Verhalten ebenfalls als Dienstsequenzmodell vorliegt. Wiederum enthält das Parameterfeld erwartete Datenwerte. Darüber hinaus werden auch Wertebereiche und Zeitangaben modelliert. Alle vorgestellten Arbeiten gehen von einer manuellen Erstellung der Dienstsequenzdiagramme aus. Eine Reduktion des Modellierungsaufwands erhöht daher auch die Nutzbarkeit bestehender Ansätze. Mithilfe von Werkzeugen ermittelte Einschränkungen könnten daher einen wertvollen Beitrag zu den beschriebenen Methoden leisten.

Steuerungssysteme sind für die Interaktion mit der realen Welt konzipiert. Bei solchen Systemen hängen realistische Ausführungsszenarien von der Umgebung ab. Infolgedessen schlugen Prenzel und Steinhorst [10] Szenariomodelle als Grundlage für die Planung von Software-Updates für IEC 61499-Anwendungen vor. Darüber hinaus ist die Ermittlung von Parametern wie der Worst-Case-Ausführungszeit (WCET) unerlässlich für zeitkritische Systeme. Szenarien bieten ein Mittel zur Abschätzung der WCET, da sie die Reaktion auf eine Dienstanforderung erfassen. Lednicki et al. [11] haben derartige Transaktionen nicht als Dienstsequenz visualisiert, die in ihrem WCET-Modell erfassten Informationen sind aber ähnlich.

Allgemein können Sequenzdiagramme Nutzungsszenarien von Systemen und FB beschreiben. In einem modellbasierten Ansatz nutzen Panjaitan und Frey [12] UML-Diagramme, aus denen sie automatisiert IEC 61499-Software generieren. Sie setzen Sequenzdiagramme sowohl zur Beschreibung von Schnittstellen zu physischen Komponenten als auch zur Beschreibung von Szenarien der Ausführung in einer bestimmten Betriebsart ein. Das Sequenzdiagramm zeigt in diesem Fall die Interaktionen zwischen Komponenten für einen bestimmten Ablauf. Sequenzdiagramme können Informationen speichern, die nicht Teil der ausführbaren Software werden.

Unser Konzept zielt auf Steuerungssoftware ab, die sich noch in der Entwicklung befindet, weshalb die nötigen Informationen in erster Linie durch Simulation gewonnen werden. Die Visualisierung als Dienstsequenz wird gewählt, um die Möglichkeiten der IEC 61499 auszuschöpfen. Die komponentenbasierte Architektur ermöglicht grundsätzlich jedoch auch, dass die Ausführungsprotokolle in anderen Diagrammen dargestellt werden.

3 Identifizierte Herausforderungen

Die Norm IEC 61499 enthält keine umfassende Sprachdefinition für Dienstsequenzmodelle. Anforderungen für verschiedene Verwendungen wurden in einer früheren Arbeit zusammengefasst [13] und werden hier diskutiert, sofern sie die Definition von FB-Einschränkungen betreffen.

1. Modellierung der erwarteten Datenwerte Die Norm berücksichtigt nur die Anforderung und Bestätigung von Diensten. Selbst bei dieser engen Auslegung ist die Angabe von erwarteten Datenwerten für die korrekte Anforderung eines Dienstes mit Parametern unerlässlich. Für die Namen der einem Ereignis zugeordneten Variablen ist das Parameterfeld vorgesehen. Datenwerte sind nicht berücksichtigt.

2. Modellierung von Vorbedingungen In Dienstsequenzdiagrammen ist keine Angabe von Vorbedingungen vorgesehen. Vordefinierte Anfangszustände sind besonders nützlich bei der Modellierung von Szenarien, die nach dem Auftreten eines Fehlers beginnen. Manche Arbeiten gehen davon aus, dass jede Dienstsequenz mit dem Anfangzustand beginnt (z. B. [14]), was für die Definition von FB-Einschränkungen nicht praktikabel ist. Für einen FB könnte zum Beispiel gelten, dass zwei Ereignisse immer direkt nacheinander auftreten. Eine solche verpflichtende Bedingung wäre in allen Zuständen des FB gültig, nicht nur als Teil einer bestimmten Dienstsequenz. Falls die Ausgangsereignisse vom Zustand des FB abhängen, müssen sie als separate Dienstsequenzen mit den entsprechenden Vorbedingungen angegeben werden.

3. Klassifizierung von Szenarien Dienstsequenzen definieren mögliche Szenarien für die Verwendung eines FB. Es ist unklar, ob ein Szenario für alle Ausführungen, nur für eine Teilmenge davon oder für keine der Ausführungen gültig ist. Die Speicherung dieser Informationen ist für die Verwendung von Dienstsequenzen als Mechanismus zur Erfassung von Beschränkungen unerlässlich.

4. Hoher Modellierungsaufwand Die Erstellung von Dienstsequenzen für bestehende FB bedeutet einen hohen Aufwand für Entwickler*innen. Obwohl dessen Funktionalität bereits implementiert ist, soll das erwartete Verhalten spezifiziert werden. Das gleiche Verhalten wird also aus verschiedenen Sichten modelliert. Einige der verfügbaren Entwicklungsumgebungen erzwingen eine Reihenfolge der Operationen bei der Modellierung von Funktionsblöcken; nur Ereignisse, die in der Schnittstelle angegeben wurden, können als Ereignis für das Telegramm ausgewählt werden. Dies kann sicherstellen, dass die erstellten Modelle gültig sind, kann aber die Nützlichkeit von Dienstsequenzen für die anfängliche Spezifikation des erwarteten Verhaltens weiter verringern.

5. Nötige Softwareentwicklungs-Kenntnisse Die zunehmende projektübergreifende Wiederverwendung von Komponenten erhöht auch den Nutzen von Dokumentation, Einschränkungen und Testfällen, die für eine Komponente spezifiziert werden. Die Definition von FB-Einschränkungen erfordert jedoch Erfahrung in der Softwareentwicklung. Viele Annahmen an das Umgebungsverhalten erscheinen offensichtlich und werden daher möglicherweise nicht gespeichert. Dennoch könnten sie nützlich sein, insbesondere wenn eine Komponente in anderen Kontexten wiederverwendet wird als ursprünglich vorgesehen.

4 Szenariomodelle

Um die im vorigen Abschnitt genannten Herausforderungen vollumfänglich zu adressieren, sind einerseits geringfügige Erweiterungen der IEC 61499 erforderlich, andererseits werden bessere Entwicklungswerkzeuge benötigt. Wir diskutieren nun Szenariomodelle sowohl in allgemeinen Modelliersprachen als auch in der domänenspezifischen IEC 61499, um daraus Erweiterungen für die Norm zu identifizieren, die für die Spezifikation von Einschränkungen geeignet sind.

5 Architektur zur Klassifikation

Mit den im vorigen Abschnitt vorgeschlagenen Erweiterungen können Dienstsequenzen als Notation für Einschränkungen des erwarteten Verhaltens einer FB-Schnittstelle dienen. Eine werkzeuggestützte Spezifikation kann den Entwicklungsaufwand für die Definition solcher Einschränkungen erheblich reduzieren (H4). Die in diesem Abschnitt vorgeschlagene Architektur ermöglicht die werkzeuggestützte Aufzeichnung von Einschränkungen mit benutzerdefinierten Eingangswerten für einen Bausteintyp. Ein Überblick über die Architektur ist in Abbildung 2 dargestellt. Zur Analyse des Bausteinverhaltens ist eine Ausführungsumgebung für IEC 61499-Modelle erforderlich.

Abbildung 2:

Methode zur Klassifikation einer Dienstsequenz. Für eine a Abfolge an Eingangsdaten berechnet eine b Laufzeitumgebung die c Ergebnisse der Ausführung. Basierend auf den d Ausführungsprotokollen wird das Verhalten als Dienstsequenzmodell visualisiert. Ein*e Entwickler*in e klassifiziert die Dienstsequenz, welche dann als Teil des Bausteintyps gespeichert wird.

Entsprechend der Nomenklatur von Dubinin und Vyatkin [17] kann die Schnittstelle eines Bausteintyps formal als ein Tupel (EI⁰, EO⁰, VI⁰, VO⁰, IW, OW) beschrieben werden. Hierbei bezeichnet:

E I 0 = e i 1 0 , e i 2 0 , … , e i k 0 die Menge an Ereigniseingängen;

E O 0 = e o 1 0 , e o 2 0 , … , e o l 0 die Menge an Ereignisausgängen;

V I 0 = v i 1 0 , v i 2 0 , … , v i m 0 die Menge an Dateneingängen;

V O 0 = v o 1 0 , v o 2 0 , … , v o n 0 die Menge an Datenausgängen.

IW und OW sind Mengen sogenannter WITH-Verbindungen zwischen Ereigniseingängen und Dateneingängen, beziehungsweise Ereignisausgängen und Datenausgängen. Ein Eingangsereignis e i trig j ist ein Signal, das am Ereigniseingang e i j 0 auftritt. Ein Eingangsereignis e i trig j oder eine Folge an Eingangsereignissen,

zusammen mit den zugehörigen Dateneingängen vi _i ⊆ VI, dienen als Eingangsinformationen für das Klassifikationssystem:

Jeder Ereigniseingang hat zugehörige Dateneingänge, die sich wie Parameter eines Methodenaufrufs verhalten und als Teil der Menge IW angegeben werden. Die zu den Dateneingängen vi _i zugehörigen Werte müssen für jedes Eingangsereignis angegeben werden.

In einer Laufzeitumgebung kann die Reaktion eines FB auf eine Eingangssequenz erfasst werden. Hierbei können durch ein einzelnes Eingangsereignis auch mehrere Ausgangsereignisse erzeugt werden. Nachfolgend werden mögliche Quellen für die Eingangssequenz erläutert:

• Benutzerdefinierte Eingangsdaten Kombinationen aus Eingangsereignissen und Datenwerten können manuell festgelegt werden, um bekannte, wichtige Szenarien zu erfassen. Außerdem können so bestimmte Einschränkungen bereits anhand des unfertigen Bausteintyps definiert werden.

• Zufällige Eingangsdaten Für jeden Datensatz wird ein Eingangsereignis zusammen mit Werten für die zugehörigen Dateneingänge zufällig ausgewählt. Zufällige Eingabesequenzen helfen bei der Identifizierung von Szenarien, die für Entwickler*innen intuitiv sind und daher bei der manuellen Spezifikation nicht berücksichtigt werden. Darüber hinaus sind einige Szenarien spezifisch für den Anwendungsfall einer Komponente und können in dem Kontext, für den eine Komponente ursprünglich entwickelt wurde, nicht relevant sein. Dies gilt insbesondere für verbotene Szenarien, wenn Entwickler*innen aus Erfahrung wissen, dass eine bestimmte Reihenfolge von Ereignissen im realen System nicht vorkommt. Daher eignen sich zufällige Eingaben am besten zur Erfassung von Szenarien für unerwartete Anwendungsfälle einer Komponente und von Szenarien, die Entwickler*innen nicht in Betracht ziehen (aufgrund von Unvollständigkeit der Spezifikation, mangelnder Schulung oder Zeit). Die identifizierten Szenarien können jedoch auch weniger relevant sein.

• Laufzeitanalyse Software von lauffähigen Gesamtsystemen kann während ihrer Ausführung überwacht werden. Die Laufzeitanalyse eignet sich am besten für die Identifizierung von Szenarien, die in einem bestimmten Anwendungsfall häufig auftreten, erfordert aber vollständige und betriebsbereite Systeme. Im Gegensatz zur zufälligen Generierung kann sie Fehlerszenarien nicht schon vor ihrem Auftreten simulieren.

Gemäß der Norm muss die Ausführungsumgebung des FB sicherstellen, dass immer nur ein Ereignis an einem FB eintrifft. Weiters müssen die in Abschnitt 4.2 eingeführten Vorbedingungen berücksichtigt werden. Der in der Vorbedingung definierte Ausgangszustand muss eingestellt werden, bevor das erste Eingangsereignis zugestellt wird.

• Ausführung in einer Laufzeitumgebung Viele Entwicklungsumgebungen exportieren Bausteintypen als Code in Allzwecksprachen. Nach dem Kompilieren dieses Codes können die Bausteininstanzen in der Laufzeitumgebung ausgeführt werden. Der Export der Ausführungsprotokolle muss möglich sein.

• Ausführung in einem Interpreter Ein Interpreter modifiziert das Modell direkt ohne vorherigen Export. Er ermöglicht die Ausführung unvollständiger Modelle und den Zugriff auf interne Daten im Gegensatz zu einer Laufzeitumgebung wie 4diac FORTE. So kann beispielsweise ein bestimmter Startzustand gemäß der definierten Vorbedingungen eingestellt werden. Durch Interpretieren eines teilweise fertigen Modells kann die Definition von FB-Einschränkungen frühzeitig erfolgen. Ist beispielsweise die Einschaltlogik noch nicht fertig implementiert, kann durch Setzen des entsprechenden Zustands häufig dennoch eine Analyse der weiteren Betriebszustände erfolgen.

Zur Modellerstellung sind Ausführungsprotokolle erforderlich, in denen die Ausgangsereignisse festgehalten werden, die durch eine bestimmte Eingangssequenz I erzeugt wurden. Diese Ausführungsprotokolle müssen in ein Modell umgewandelt werden, das die Einschränkungen in einem Szenariomodell grafisch darstellt. In unserem Kontext werden Dienstsequenzen verwendet, eine Erweiterung auf andere Szenariomodelle, wie die in Abschnitt 4.1 besprochenen, ist aber grundsätzlich möglich. Schließlich wird das grafische Modell angezeigt und durch den Entwickler oder die Entwicklerin klassifiziert.

6 Werkzeugunterstützung

Wir haben eine Werkzeugunterstützung für die benutzerfreundliche Definition von FB-Einschränkungen als Sicht in 4diac IDE implementiert, die in Abbildung 3 gezeigt ist. Während im Bausteineditor oben die Schnittstelle oder die Implementierung angepasst werden, erlaubt die untere Sicht die Konfigurierung und Klassifikation von Dienstsequenzen. Durch Auswahl der entsprechenden Kategorie wird die aktuelle Dienstsequenz gespeichert und eine neue wird geladen und angezeigt. Eine Dienstsequenz kann auch übersprungen werden, da insbesondere bei zufällig generierten Modellen die Redundanz hoch ist.

Abbildung 3:

Überblick über 4diac IDE. Der Editor (links) zeigt die Schnittstellenbeschreibung des FB SortierSteuerung. Die Klassifikationssicht (rechts) erlaubt die Aufzeichnung, Beurteilung und Speicherung von Dienstsequenzen dieses Bausteins. Die Sicht kann als eigenes Fenster herausgelöst werden, um die gleichzeitige Ansicht verschiedener Informationen zu erlauben. Entwickler*innen können eine gewünschte initiale Ereignisabfolge oder Datenwerte angeben.

Die Implementierung folgt der zuvor beschriebenen komponentenorientierten Architektur. Dadurch bleiben alle Elemente austauschbar und können beliebig erweitert werden. Folgende Alternativen wurden zunächst realisiert:

• Eingangssequenzen können manuell definiert oder zufällig erzeugt werden. Auch manuell definierte Teilsequenzen ergänzt durch Zufallssequenzen sind möglich. Die Länge der Eingangssequenz ist auswählbar.

• Als Laufzeitumgebung wird ein Modellinterpreter ohne Echtzeitfähigkeit eingesetzt.

• Ausführungsprotokolle liegen zunächst als Datenstruktur vor. Sie werden dann gemäß den Übersetzungsregeln aus einer früheren Arbeit [4] in Dienstsequenzmodellen grafisch visualisiert.

• Die Klassifizierung erfolgt über die entwickelte Sicht auf Basis der vorgeschlagenen Kategorien.

Die Dienstsequenzen mit Ereignissen und Daten können direkt im normierten XML-Format gespeichert werden. Die Norm IEC 61499 definiert auch einen Namen und ein Kommentarfeld für diese Sequenzen. Die Klassifizierung und die Vorbedingung (d. h. der Startzustand) sind jedoch benutzerdefinierte Erweiterungen, die für unseren Prototyp implementiert wurden. Für die Speicherung dieser Informationen haben wir den Mechanismus der Attribute gewählt. Das XML-Element Attribute ist für die Speicherung von werkzeugspezifischen Erweiterungen, wie grafischen Visualisierungshinweisen, vorgesehen. Die aktuelle Implementierung schränkt daher die Portabilität der Typdefinition ein. Andere Entwicklungsumgebungen würden verbotene Szenarien nicht korrekt erkennen. Die Verwendung der Dienstsequenzen ohne weitere Bearbeitung würde zu fehlgeschlagenen Testfällen führen. Für die Anwendung unserer Methode sind neue XML-Elemente für Vorbedingungen und die Klassifizierung in weiteren Ausgaben der Norm erforderlich.

Nach der Speicherung können Entwickler*innen Dienstsequenzen im grafischen Typeneditor manuell bearbeiten. Dies erlaubt die Verallgemeinerung von Dienstsequenzen. In manchen Fällen können die spezifischen Datenwerte entfernt werden, sodass der gesamte Wertebereich des Datentyps abgedeckt ist.

7 Anwendungsfall: Überwachung der Ausführung

Der Nutzen von FB-Einschränkungen ergibt sich vor allem aus der Integration dieser Informationen in den Softwareentwicklungsprozess für FB. Sie können beispielsweise zur Fehlererkennung genutzt werden.

Wenn eine verbotene Dienstsequenz während der Ausführung beobachtet wird, liegt möglicherweise ein Fehler des Steuerungssystems vor. Aus Arbeiten zur Softwarearchitektur von Steuerungssoftware ist bekannt, dass die Fehlererkennung von der Implementierung des Verhaltens getrennt werden sollte. Diese kann als eigener FB realisiert werden [18]. Um eine Abfolge von Ereignissen zu erkennen, muss die Historie als Zustand des FB gespeichert werden. Dafür sind insbesondere Basisfunktionsbausteine geeignet, da ihre Funktionalität als Zustandsdiagramm implementiert wird.

Als möglicher Anwendungsfall wird hier die automatische Generierung von Bausteinen zur Überwachung des FB-Verhaltens während der Ausführung besprochen. Die als verboten klassifizierten Dienstsequenzen dürfen nicht auftreten. Soweit dies durch die Implementierung des FB selbst sichergestellt ist, dienen die definierten Szenarien als Ausgangsbasis für Testfälle. Zum Teil handelt es sich aber auch um Annahmen über den Einsatz des FB. Ein Beispiel stellt eine als verboten klassifizierte Folge von Eingangsereignissen dar, die durch physische Komponenten ausgelöst werden könnten. Sollte eine solche verbotene Abfolge dennoch auftreten, liegt ein Fehler vor, auf den das System reagieren muss.

Anhand eines einfachen Beispiels zeigen wir für verbotene Sequenzen die Erstellung eines Basisfunktionsbausteintyps zur Überwachung der Ausführung (Abbildung 4). Der FB SortierSteuerung soll das zur TeilId gehörige Förderband aktivieren. Ein Teil der Kategorie 1 soll demnach nicht an Band 3 verteilt werden, was als falsche Sortierung modelliert wird (Dienstsequenz). Für dieses Szenario soll nun ein Überwachungsbaustein erzeugt werden. In Abbildung 4 sind die Schnittstelle und das Zustandsdiagramm des FB FalscheSortierung gezeigt.

Abbildung 4:

Generierung eines Bausteins zur Erkennung einer falschen Sortierung in Zusammenhang mit der SortierSteuerung. Das verbotene Szenario ist in der Dienstsequenz modelliert. Der Überwachungsbaustein und die Implementierung des Zustandsdiagramms (unten) wurden automatisch erzeugt.

Folgende Umformungsregeln für die Erzeugung von Überwachungsbausteinen wurden identifiziert:

1. Es wird ein Basisfunktionsbausteintyp erstellt. Als Typname für den Überwachungsbaustein wird der Name der Dienstsequenz gewählt.

2. Für jedes Ein- oder Ausgangsereignis des zu überwachenden FB wird ein Ereigniseingang erzeugt. Auch Ereignisse, die nicht in der Sequenz modelliert wurden, unterbrechen diese und müssen demzufolge berücksichtigt werden.

3. Ein Ausgangsereignis DETECTED zeigt an, dass das gewählte Szenario eingetreten ist.

4. Für die in der Dienstsequenz angeführten Datenwerte müssen Dateneingänge vorgesehen werden.

5. Im Zustandsdiagramm muss ein Zustand für jedes Telegramm erzeugt werden.

6. Das im Telegramm enthaltene Ereignis wird als Bedingung einer Transition angegeben. Die Transition wird zwischen den Zuständen vor und nach dem angegebenen Ereignis erzeugt. Die Bedingung wird durch Datenwerte ergänzt, sofern diese in der Dienstsequenz modelliert wurden.

7. Jeder interne Zustand muss weiters für alle anderen Ereignisse, die auftreten könnten, Transitionen zum Startzustand vorsehen. Diese unterbrechen das in der Dienstsequenz modellierte Szenario. Eine Transition mit der Bedingung 1 ist immer wahr und der Zielzustand wird daher sofort aktiv. Eine solche Bedingung wäre daher nicht geeignet, um in einer einzelnen Transition alle Ereignisse zu identifizieren, die nicht Teil der Sequenz sind und den internen Zustand daher zurücksetzen müssen.

Nach Auswahl der zu identifizierenden Sequenz erlaubt 4diac IDE die automatische Erzeugung eines Überwachungsbausteins nach diesen Umformungsregeln. Der generierte Baustein muss zusammen mit dem ursprünglichen FB verwendet werden. Dazu kann auch ein hierarchischer Baustein inklusive der notwendigen Verbindungen automatisch erzeugt werden, um den Aufwand insbesondere bei mehreren zu überwachenden Sequenzen zu verringern.

8 Evaluierung

Als Evaluierungsgrundlage dienen einerseits Experimente zur Modellierung von FB-Einschränkungen. Andererseits wird mit der automatischen Erkennung verbotener Szenarien eine Anwendungsmöglichkeit diskutiert, die Einsparungspotenziale des Entwicklungsaufwands aufzeigt.

8.1 Test des Klassifikationssystems

Wir haben unsere Realisierung der Architektur in Abbildung 2 mit denselben Bausteintypen wie [4] evaluiert. Dazu gehören die in der Norm definierten Basisfunktionsbausteintypen und ein eigener Bausteintyp für die Orchestrierung einer Station in einem Produktionssystem (SortierSteuerung). Die von uns implementierten Erweiterungen ermöglichen die manuelle Klassifizierung bestehender Dienstsequenzen. Im Typen-Editor haben wir Vorbedingungen und die Klassifikation für die manuell definierten Dienstsequenzen des Bausteins SortierSteuerung ausgewählt.

Das System ermöglicht weiters die Generierung neuer Dienstsequenzen, die direkt klassifiziert werden. Ausgewählte Dienstsequenzen, die wir automatisch für den Baustein SortierSteuerung generiert haben, sind in Abbildung 5 dargestellt. Im Vergleich zur manuellen Spezifikation von Dienstsequenzen erzeugt der automatisierte Prozess eine größere Vielfalt an Einschränkungen (unerwartete Varianten) und spart Zeit. Da der SortierSteuerung-FB sehr spezifische Datenwerte erfordert, war jedoch nur ein kleiner Teil der vollständig generierten Einschränkungen relevant, was auf notwendige Verbesserungen der Generierung von Eingangssequenzen hinweist. Durch die Angabe des FehlerCode als Anfangsparameter konnte die Relevanz erhöht werden (aufgezeichnet wurden zehn Sequenzen mit bis zu drei Eingangsereignissen).

Abbildung 5:

Automatisch aufgezeichnete Dienstsequenzen für einen FB. Sie sind als verboten, verpflichtend und bedingt klassifiziert.

9 Zusammenfassung

Dienstsequenzen können als Modell des beobachtbaren Verhaltens an der Schnittstelle eines FB dienen, was die Automatisierung von Testfällen oder die Überwachung ermöglichen kann. Für die Spezifikation von FB-Einschränkungen als Dienstsequenzen werden Erweiterungen vorgeschlagen. Diese erlauben die Modellierung von Vorbedingungen, einer Klassifikation und spezifischer Datenwerte.

Das vorgeschlagene Werkzeug ermöglicht die Generierung von Dienstsequenzen, die von dem/der Entwickler*in als verbotenes, mögliches oder obligatorisches Verhalten einer Komponente klassifiziert werden. Die Entwickler*innen stützen sich dabei auf ihr implizites Wissen über die beabsichtigte Verwendung der Komponente und die Umgebung des Systems. So kann beispielsweise eine bestimmte Reihenfolge von Ereignissen unerwartet sein und in einem funktionierenden System niemals auftreten. Die modulare Architektur unseres Klassifikationssystems ermöglicht es, es an individuelle Bedürfnisse anzupassen. Solche Anpassungen können zusätzliche oder andere Quellen von Eingabedaten oder die direkte Ausführung in einer Laufzeit umfassen, wenn genaue Zeitinformationen erforderlich sind. Derzeit können Dienstsequenzen nur für Basisfunktionsbausteintypen generiert werden. Sobald andere Bausteintypen vom Interpreter unterstützt werden, wird unser System die Klassifizierung von Sequenzdiagrammen für jede Art von FB ermöglichen.

Künftige Arbeiten werden darauf abzielen, die Relevanz der erzeugten Dienstsequenzen zu erhöhen. Die generierten Eingaben könnten besser auf den FB zugeschnitten werden, wenn mehr Informationen über die erwarteten Daten verfügbar wären. So könnte beispielsweise die Definition von Teilbereichen oder einer Reihe von diskreten erwarteten Werten die Anzahl der zu erfassenden Eingaben begrenzen. Darüber hinaus können einige Szenarien auf der Grundlage der bereits verfügbaren Informationen klassifiziert werden. Wenn eine Dienstsequenz ein Unterszenario enthält, das als verboten markiert wurde, muss auch das längere Szenario verboten sein. Eine solche Unterstützung durch das Werkzeug kann Ingenieur*innen bei der Definition von Einschränkungen und dem erwarteten Verhalten einer Komponente unterstützen.