Bad Smells in Steuerungssoftware für automatisierte Produktionssysteme

1 Einleitung

Moderne automatisierte Produktionssysteme sind Cyber-Physische Produktionssysteme (CPPSs), Systeme in denen Hardware-und Softwarekomponenten eng miteinander und mit ihrer Umgebung interagieren. In diesen Systemen steigt sowohl der Softwareanteil am Gesamtsystem als auch die Komplexität stetig [1], [2], [3]. Um in der Zukunft wettbewerbsfähig zu bleiben, ist daher eine qualitativ hochwertige Software, die leicht verständlich und gut wartbar ist, wichtiger denn je. Nur saubere und gut strukturierte Softwarearchitekturen ermöglichen eine hohe Qualität automatisierter Produktionssysteme [4]. Die Qualität der Software kann dabei einerseits durch die gezielte Verwendung passender Entwurfsmuster und andererseits durch die Vermeidung oder Reduktion von schlechtem Code erhöht werden. In dieser Arbeit beschäftigen wir uns mit letzterem.

Sogenannte Bad Smells sind Strukturen [5] oder Anti-Patterns [6] in Software, die vermieden werden sollten. Es ist wichtig anzumerken, dass Bad Smells und Anti-Patterns keine Fehler in der Software sein müssen und dass Software, die diese beinhaltet, korrekt sein kann. Jedoch können sich Bad Smells negativ auf die Softwarequalität auswirken, da sie die Verständlichkeit, die Wartbarkeit und die Erweiterbarkeit eines Softwaresystems behindern können [7, 8]. Aufgrund der Wichtigkeit dieses Themas unterstützen viele Software Engineering Programmiertools bereits eine automatische Detektion von Smells in unterschiedlichem Ausmaß. Leider hinken sowohl die Tools als auch die Forschung zu Smells im Bereich der CPPSs hinterher [9]. Um diese Lücke zu schließen, haben wir uns intensiv mit dem Thema Bad Smells in IEC 61499-basierter Steuerungssoftware für automatisierte Produktionssysteme beschäftigt und bereits einige Publikationen dazu veröffentlicht [10], [11], [12].

In dieser Arbeit geben wir einerseits einen allgemeinen Überblick über das Thema Bad Smells in Steuerungssoftware als auch einen Überblick über unsere bisherigen Ergebnisse und zukünftigen Schritte zu diesem Thema, speziell für den Standard IEC 61499 [13] für verteilte Steuerungssoftware. Darüber hinaus verknüpfen wir unsere bisherigen Ergebnisse mit einem neuartigen Visualisierungskonzept für IEC 61499 Software und zeigen die Vorteile auf, die sich dadurch ergeben. Ein Hauptgrund für den Fokus auf IEC 61499 ist, dass Gsellmann et al. [14] mittels Softwaremetriken gezeigt haben, dass für gleiche Steuerungsprogramme in IEC 61131-3 und in IEC 61499, bei IEC 61499 das Potential für weniger Aufwand und bessere Verständlichkeit besteht. Aufgrund dieses Potentials ist es ein wichtiger Schritt, die Forschungslücke, die für IEC 61499 im Vergleich zu IEC 61131-3 bzw. zu allgemeinen Programmiersprachen besteht, zu schließen.

Der Aufbau der Arbeit ist wie folgt: Wir geben zunächst in Kapitel 2 eine kurze Einführung in IEC 61499. In Kapitel 3 gehen wir auf bestehende Literatur zum Thema Bad Smells in Steuerungssoftware ein. Im nächsten Kapitel fassen wir den Bad Smells Katalog zusammen, den wir in [11] vorgestellt haben. Anschließend gehen wir auf die durch Überprüfung von vordefinierten Regeln detektierbaren Smells des Katalogs ein und erweitern unsere bisherige Arbeit um eine detaillierte Beschreibung dieser Smells. In Kapitel 6 fassen wir unsere Arbeit zur Detektion des Smells Feature Envy zusammen [10]. Dieser Smell deutet auf eine suboptimale Modularisierung des Systems hin. Im nächsten Kapitel fassen wir unsere Arbeit zur KI-basierten Detektion von Codeklonen zusammen [12]. Anschließend beschreiben wir, wie unser Visualisierungskonzept für sehr große Steuerungsprogramme [15] erweitert werden kann, um detektierte Smells besser Entwickler*innen zugänglich zu machen. Abschließend diskutieren wir unsere zukünftigen Forschungsziele zu diesem Thema.

2 IEC 61499 Grundlagen

In diesem Kapitel gehen wir auf die Grundlagen von IEC 61499 ein, die zum Verständnis der nachfolgenden Kapitel wichtig sind. Details, die darüber hinausgehen, werden nicht betrachtet. Daher sei an dieser Stelle auch auf den Standard [13] verwiesen.

IEC 61499 ist eine domänenspezifische Modellierungssprache, die für verteilte Steuerungssoftware in CPPSs verwendet wird. Eine IEC 61499-Anwendung ist ein Netzwerk von Funktionsbausteinen. Jeder Funktionsbaustein (FB) hat eine definierte Schnittstelle, die aus mehreren eingehenden und ausgehenden Event-und Datenverbindungen besteht. Ein Eingangsevent löst eine bestimmte Prozedur innerhalb des FBs aus. Nach Abschluss kann ein Ausgangsevent ausgelöst werden. Zusätzlich kann jeder Event mit Datenverbindungen verknüpft sein. Wenn eine Datenverbindung mit einem Event verknüpft ist, werden die Daten aktualisiert, sobald der Event auftritt.

Was sich hinter der Schnittstelle des FBs verbirgt, hängt von der Art des FBs ab. Ein Simple Funktionsbaustein (SFB) ist ein FB, der einen Algorithmus in einer beliebigen Programmiersprache enthält. Auch wenn die Sprache durch IEC 61499 nicht festlegt ist, hat sich IEC 61131-3 Strukturierter Text hierfür etabliert.

Ein Basisfunktionsbaustein (BFB) ist ein FB, der einen Zustandsautomaten enthält, das sogenannte Execution Control Chart (ECC). Das ECC besteht aus Zuständen, die über Transitionen verbunden sind. Die Transitionen verfügen über eine Bedingung, die dazu führt, dass ein Wechsel zu einem anderen Zustand nur dann möglich ist, wenn diese Bedingung erfüllt ist. Die Bedingung kann dabei aus einer Eventbedingung, einer Booleschen Bedingung, einer Kombination oder keiner Bedingung bestehen. Eine Eventbedingung ist immer dann wahr, wenn der entsprechende Eingangsevent auftritt. In der Booleschen Bedingung können Eingangsvariablen und interne Variablen des FBs verwendet werden. Die kombinierte Bedingung ist wahr, wenn beide Bedingungen gleichzeitig erfüllt sind und die Variante ohne Bedingung ist immer wahr. Darüber hinaus wird Transitionen auch eine Priorität zugeordnet, wenn ein Zustand über mehr als eine Ausgangstransition verfügt. Die Priorität legt fest, in welcher Reihenfolge die einzelnen Transitionen überprüft werden. Wenn die Bedingung einer Transition wahr ist, werden folglich die Transitionen mit niedrigerer Priorität nicht mehr überprüft. In Abbildung 1 ist ein ECC mit den verschiedenen Arten von Transitionen dargestellt.

Abbildung 1:

ECC mit mehreren Zuständen und Transitionen mit unterschiedlichen Prioritäten und Bedingungen.

Zusätzlich gibt es noch Zusammengesetzte Funktionsbausteine (ZFBe) und Unteranwendungen, die jeweils ein Funktionsbaustein Netzwerk (FBN) kapseln. Diese Bausteine bieten also eine Möglichkeit zur Modularisierung und Wiederverwendung von IEC 61499 Software.

3 Verwandte Arbeiten

Statische Code Analyse von Steuerungssoftware für automatisierte Produktionssysteme fokussiert stark darauf, frühzeitig Fehler in den Programmen zu finden (z.B. [16, 17]). In dieser Arbeit beschäftigen wir uns mit der Detektion von Bad Smells und Codeklonen, die zu schlechter Wartbarkeit führen können.

4 Bad Smells in IEC 61499 Software

In Sonnleithner et al. [11] haben wir einen ersten Schritt in Richtung der Definition von Bad Smells in IEC 61499 Software gemacht. Hierbei haben wir einen Katalog mit insgesamt 17 Bad Smells in IEC 61499 vorgestellt (siehe Tabelle 1). In den Katalog sind die Smells von Hagge und Wagner [21], die wir in Kapitel 3 beschrieben haben, eingegangen. Darüber hinaus haben wir die von Fowler und Beck [30] vorgestellten Bad Smells und die von Brown et al. [6] beschriebenen Anti-Patterns auf ihre Übertragbarkeit auf IEC 61499 untersucht und gegebenenfalls ebenso hinzugefügt. Als übertragbar wurden dabei jene Smells und Anti-Patterns definiert, die sich auf Sprachmerkmale beziehen, die von der IEC 61499 unterstützt werden. Deshalb wurden beispielsweise Smells, die sich auf Vererbung beziehen, nicht übernommen. Darüber hinaus wurden IEC 61499 spezifische Smells identifiziert, die noch nicht in verwandten Arbeiten beschrieben wurden.

Dieser Katalog soll einerseits als Referenz für Entwickler*innen dienen, um die Codequalität zu verbessern, und andererseits als Ausgangspunkt für zukünftige Forschung zu diesem Thema. Neben dem Wissen darüber, welche Muster in der Software vermieden werden sollten, also der Definition von Bad Smells, ist es ebenso wichtig, die Smells auch automatisch detektieren zu können. Dafür braucht es einerseits Detektionsmethoden und andererseits eine konkrete Implementierung dieser Detektionsmethoden in Entwicklungswerkzeugen. In den folgenden Kapiteln gehen wir auf unsere Arbeit zu unterschiedlichen automatisierten Detektionsmethoden von Smells ein.

5 Regelbasierte Detektion

Einige Bad Smells, die in IEC 61499 Software auftreten, können über vordefinierte Regeln und deren Überprüfung detektiert werden. Diese Regeln werden ähnlich zu einer Booleschen Bedingung formuliert und können somit entweder erfüllt oder verletzt sein. Dadurch sind diese Smells besonders einfach detektierbar und die Qualität der Software kann mit geringem Aufwand verbessert werden. Diese Smells haben wir in Sonnleithner et al. [11] bereits grundlegend vorgestellt. Nachfolgend geben wir eine erweiterte Beschreibung aller mittels regelbasierter Detektion aufspürbaren Smells dieses Katalogs. In 4diac IDE, eine open-source Entwicklungsumgebung für IEC 61499 Software, die Teil des Eclipse 4diac™ Projekts [31] ist, wurde die regelbasierte Detektion einiger dieser Smells mittels OCL bereits integriert [32] und kann damit einfach in beliebigen IEC 61499 Szenarien eingesetzt und evaluiert werden.

Toter Zustand: Ein Zustand im ECC eines FBs ist ein toter Zustand, wenn er keine eingehenden Transitionen hat oder wenn kein Pfad, beginnend beim Startzustand über die gerichteten Transitionen zu diesem Zustand führt.

Tote Transition: Eine Transition im ECC eines FBs ist eine tote Transition, wenn es nicht vorkommen kann, dass sie überprüft wird. Dies ist der Fall, wenn eine andere Transition, die beim gleichen Zustand beginnt, eine höhere Priorität und keinen Bedingungsausdruck hat. Sobald ein Zustand also eine Transition hat, die keinen Bedingungsausdruck hat, werden andere Transitionen mit niedrigerer Priorität nicht mehr überprüft und sind somit tot. Eine Transition ohne Bedingungsausdruck sollte somit immer die niedrigste Priorität haben. Eine tote Transition kann in weiterer Folge auch zu einem toten Zustand führen.

Toter FB: Ein FB wird als toter FB bezeichnet, wenn er keine eingehenden Eventverbindungen hat und somit nicht aufgerufen wird. Hier gibt es jedoch Ausnahmen. IEC 61499 definiert Dienstschnittstellen-Funktionsbausteine (DSFBe), welche unterlagerte Dienste von Steuerungsgeräten kapseln. Diese Dienste können auch Benachrichtigungen an Anwendungen senden und benötigen daher nicht immer Eingangsevents.

Terminaler Zustand: Wenn ein Zustand im ECC eines FBs zwar erreicht werden kann, aber selbst über keine ausgehenden Transitionen verfügt, spricht man von einem terminalen Zustand. Sobald ein terminaler Zustand betreten wird, gibt es keinen Rückweg mehr.

Unbenutzter Event: Von einem unbenutzten Event spricht man, wenn ein Eingangsevent innerhalb des FBs nicht verwendet wird bzw. wenn ein Ausgangsevent nicht im FB ausgelöst wird. Bei einem BFB wäre das der Fall, wenn ein Eingangsevent in keiner Transition vorkommt bzw. wenn ein Ausgangsevent in keiner Aktion vorkommt.

Tote Daten: Dieser Smell kann an verschiedenen Stellen auftreten. Einerseits kann man von toten Daten sprechen, wenn Dateneingangs-bzw. -ausgangsvariablen innerhalb des FBs nicht verwendet werden. In diesem Fall tritt der Smell für den Typ des FBs auf. Andererseits kann man von toten Daten sprechen, wenn innerhalb der Anwendung zwar der Event, der mit den Daten verbunden ist, verwendet wird, aber die Daten nicht verbunden bzw. nicht konfiguriert wurden. In diesem Fall wäre es ein Smell der Instanz des FBs.

Veränderliche Daten: Dieser Smell tritt auf, wenn im Algorithmus innerhalb eines FBs auf einen Dateneingang geschrieben wird. In der Folge kann das zu unvorhergesehenem Verhalten führen, wenn beispielsweise ein anderer Algorithmus ebenfalls den Wert dieses Dateneingangs benötigt und nicht mehr den korrekten Wert zur Verfügung hat.

Toter Event: Ein Event ist tot, wenn er zwar benützt wird, aber immer ignoriert wird. Dies ist in BFBen der Fall, wenn der entsprechende Event nur in toten Transitionen vorkommt.

Endlosschleife: In IEC 61499 Software kann es zu unerwünschten Endlosschleifen kommen, wenn eine Transition im ECC ohne Bedingung (also eine Transition, deren Bedingung immer wahr ist) wieder im gleichen Zustand endet. Darüber hinaus können auch in FBNen ungewollte Endlosschleifen auftreten. Mit den aktuellen Mitteln sind diese Endlosschleifen allerdings nicht mehr durch reine Regelüberprüfung detektierbar, sondern bedürfen einer genaueren Analyse des Verhaltens der FBe. Mithilfe von Verhaltensmodellen [33] könnte dieser Smell in der Zukunft auch in FBNen mit Regeln detektiert werden.

6 Metrikbasierte Detektion von Feature Envy

Feature Envy ist ein Smell, der auf eine schlechte Modularisierung der Software hindeutet. Dieser Smell tritt auf, wenn Komponenten eines Moduls mehr mit Komponenten anderer Module interagieren, als mit solchen des eigenen Moduls. Im Rahmen unserer Industriekooperation haben wir gelernt, dass Modularisierung ein essenzielles Thema für die Entwicklung und Wartung von Steuerungssoftware darstellt. Insbesondere in Anbetracht ihres langen Lebenszyklus benötigen anpassungsfähige und flexible Produktionssysteme modulare und wiederverwendbare Software [34]. Deshalb gebührt dem Smell Feature Envy besonderes Augenmerk.

In Sonnleithner et al. [10] haben wir bestehende Ansätze diskutiert, die in anderen Bereichen verwendet werden, um Feature Envy aufzuspüren, und sie anschließend auf IEC 61499-basierter Steuerungssoftware angewendet.

Zur Detektion von Feature Envy innerhalb von FBNen in IEC 61499 Software wurden zwei Ansätze genauer untersucht. Der erste ist der von Nongpong [35] vorgestellte Feature Envy Factor. Der zweite Ansatz basiert auf einem von Simon et al. [36] entwickelten Distanzmaß.

7 KI-basierte Detektion von Codeklonen

Techniken der Künstlichen Intelligenz (KI) haben sich in verschiedenen Bereichen etabliert, um Situationen mit großen Mengen an unstrukturierten Daten zu bewältigen [38]. Insbesondere verwenden mehrere Ansätze KI-Techniken in textuellem Code, um ähnliche Codeteile zu identifizieren, wie z.B. das Auffinden von Codeklonen mit Neuronalen Netzen [39, 40].

Auf der Grundlage von KI-Techniken haben wir einen allgemeinen Ansatz zur automatischen Erkennung sich wiederholender Muster mit Hilfe von Techniken des maschinellen Lernens in CPPSs [12] vorgeschlagen. Die Phasen dieses Ansatzes sind in Abbildung 2 dargestellt. Die beiden Schlüsselaspekte dieses Ansatzes sind die Kandidatenauswahl und die Ähnlichkeitseinbettung. In IEC 61499 sind die BFBe bereits Instanzen vordefinierter gemeinsamer Typen. Daher betrachten wir FBNe (d.h. Unteranwendungen, ZFBe) als Analysekomponenten in der Referenzimplementierung. Die Hierarchie der FBNe wird zur Definition der Kandidatenauswahlmethode verwendet. Um einen Ähnlichkeitsindex für jeden Kandidaten zu berechnen, haben wir für jede Unteranwendung einen Vektor mit einer Reihe von Merkmalen erstellt, die sowohl absolute als auch strukturelle FB-Metriken enthalten, wie z.B. die Anzahl der internen FBs und den Konnektivitätsgrad. Diese Merkmale werden manuell definiert, aber wir können auch ein Neuronales Netzwerk (NN) trainieren, um aussagekräftige Ähnlichkeitseinbettungen zu erstellen. Wir ziehen auch eine optionale Projektions-Phase in Betracht, um den Dimensionsraum vor dem Clustering zu reduzieren. Dadurch wird ein potenzieller Verlust an aussagekräftigen Unterscheidungen aufgrund hochdimensionaler Vektoren vermieden [41].

Abbildung 2:

Phasen der Ähnlichkeitsanalyse: Auswahl, Einbettung, Projektion und Clustering. Adaptiert von Unterdechler et al. [12].

Die Dimensionen dieser Vektoren werden zur Berechnung eines Ähnlichkeitsindexes verwendet. Auf der Grundlage dieses Indexes werden die Unteranwendungen in Gruppen ähnlicher Unteranwendungen geclustert. Wir haben diesen Ansatz auf eine Fallstudie aus der Industrie angewendet und konnten ähnliche Unteranwendungen als Ergebnis aufzeigen. Durch Refaktorierung dieser Unteranwendungen in gemeinsame Typen können wir die Wiederverwendbarkeit und Wartung der Artefakte verbessern. Allerdings haben wir auch ähnliche Unteranwendungen ohne funktionale Zusammenhänge gefunden, also falsch-positive Ergebnisse. Ein Schwellwertparameter wird verwendet, um die Genauigkeit des Clustering zu verfeinern. In Abbildung 3 sind die gefundenen Ähnlichkeitsgruppen bei steigendem Schwellwert dargestellt. Die Anzahl der Elemente in den Clustern wächst, weil neue Klone gefunden werden, aber auch nicht zusammenhängende Unteranwendungen beginnen übereinzustimmen. Daher kann dieser Vorschlag nützliches Feedback für die Technik liefern, um relevante Komponenten zu finden, die Kernplattform zu erhalten und den Entwicklungsaufwand in zukünftigen Projekten zu reduzieren. Obwohl die genaue Analyse der Präzision außerhalb des Rahmens unserer bisherigen Arbeit lag, wurden die genauesten Ergebnisse mit einem Schwellwert von 0,1 (in Abbildung 3 rot hervorgehoben) erzielt, bei dem alle Klone identifiziert wurden (Recall oder Precision = 1), obwohl auch einige falsch-negative Ergebnisse ausgegeben wurden (falsch-negativ Rate = 0,04). Bei niedrigeren Schwellwerten nahm die Präzision ab (weniger richtig-positive Ergebnisse) und bei höheren Schwellwerten stieg die Zahl der falsch-positiven Ergebnisse.

Abbildung 3:

Die gefundenen Ähnlichkeitsgruppen hängen vom Schwellwert ab. Adaptiert von Unterdechler et al. [12].

Die Refaktorierung bleibt eine Herausforderung, welche die Unterstützung von Fachleuten erfordert. Andere Techniken werden in Betracht gezogen, um die Genauigkeit der Ergebnisse zu verbessern. Grapheneinbettungen können dabei helfen, die Graphenstruktur zu verarbeiten und davon Informationen abzuleiten [42, 43]. Auch Graph Neural Networks (GNNs) wurden dafür mit Erfolg verwendet [44].

8 Repräsentation detektierter Smells

Sobald eine automatische Detektion von Bad Smells in einer Entwicklungsumgebung implementiert ist, stellt sich die Frage, wie die Ergebnisse den Entwickler*innen präsentiert werden sollen. Klassischerweise erfolgt dies direkt über eine Markierung an der Stelle, wo der problematische Teil des Codes auftritt oder durch eine Markierung von Dateien, die problematischen Code enthalten. Diese Markierungen erlauben allerdings keinen Überblick über das Gesamtsystem. Dafür wird oft eine tabellarische Repräsentation verwendet, in der alle gefundenen Probleme des Gesamtsystems aufgelistet werden. Mit dieser Art der Repräsentation wird zwar ein Überblick über die Anzahl der gefundenen Probleme gegeben, allerdings ist es in der Praxis unter Umständen mühsam, die Tabelle durchzuarbeiten. Daher schlagen wir vor, für die Repräsentation der gefundenen Smells für die Entwickler*innen das Visualisierungskonzept zu verwenden, das wir in Sonnleithner et al. [15] vorgestellt haben. Dieses Visualisierungskonzept beruht auf der Repräsentation der Hierarchie der FBe als Wurzelbaum, der mit einem Circle Packing Layout [45] dargestellt wird und der Repräsentation der Verbindungen zwischen den einzelnen FBen als Graph, der dem Wurzelbaum überlagert wird. Um die Übersichtlichkeit der resultierenden Visualisierung zu gewährleisten, wird Edge Bundling [46] verwendet, das Verbindungen, die ähnliche Quellen und Senken haben, bündelt.

Diese Visualisierung der gesamten Softwarestruktur lässt sich mit den Ergebnissen der in dieser Arbeit zusammengefassten Analysen erweitern. In Abbildung 4 ist die resultierende Visualisierung eines Beispielsystems dargestellt. Bausteine, bei denen ein Smell detektiert wurde, werden dabei farblich markiert. Je nach Schweregrad wird orange oder rot verwendet. Eine weitere Eigenschaft mit der wir gerade experimentieren, ist wie von Fuchs et al. [47] vorgeschlagen, die Größe der Kreise aufgrund von Metriken anzupassen.

Abbildung 4:

Visualisierung eines Softwaresystems mit dem Konzept, das wir in Sonnleithner et al. [15] vorgestellt haben. Detektierte Smells sind farblich markiert.

Durch diese Art der Repräsentation der detektierten Smells erhalten Entwickler*innen sofort einen Überblick über die Qualität des gesamten Systems. Darüber hinaus lässt die Visualisierung auf den ersten Blick erkennen, welche Module stärker von Smells betroffen sind als andere. Mit der Visualisierung lassen sich unsere Arbeiten zur Code Analyse und Smell Detektion verbinden und sie gewährt so den Entwickler*innen einen detaillierteren Einblick in den Zustand ihrer Software, als das nur durch die Auflistung der Ergebnisse z.B. der Klon Detektion möglich wäre. Erste Evaluierungen mit industriellen Nutzern zeigten bereits die Vorteile und die möglichen Verbesserungen des Entwicklungsprozesses unter Verwendung dieser Darstellungen. Basierend auf dieser sehr positiven Rückmeldung ist eine detaillierte Studie in Planung.

9 Zusammenfassung

In diesem Artikel haben wir unsere Arbeiten zum Thema Bad Smells in Steuerungssoftware für automatisierte Produktionssysteme mit Fokus auf IEC 61499 Software zusammengefasst und gegenübergestellt. In den letzten Jahren konnten zu diesem Thema wesentliche Fortschritte erzielt werden. Ein Katalog, der mögliche Smells in IEC 61499 Software auflistet, wurde vorgestellt. Es wurde evaluiert, welche dieser Smells regelbasiert detektierbar sind. Zur Detektion des Smells Feature Envy, der auf eine schlechte Modularisierung des Systems hindeutet und deshalb besonders wichtig ist, wurden zwei Ansätze diskutiert. Auch für Codeklone, die zu Wartbarkeitsproblemen in der Software führen können, wurde eine erste Möglichkeit zur Detektion mit KI-basierten Algorithmen präsentiert. Wichtig ist nochmals zu erwähnen, dass es sich hier nicht um eine Detektion von Fehlern in der Software handelt, sondern um die Detektion von potentiell schlechten Softwarestrukturen. Die Bewertung der Auswirkung muss dem Anwender überlassen werden und ist abhängig vom Anwendungsfall. Daher haben wir die Ergebnisse dieser Analysen mit einem neuartigen Visualisierungskonzept für Steuerungssoftware verknüpft, um die Ergebnisse besser den Entwickler*innen zu präsentieren und sie so im Entwicklungsprozess zu unterstützen. Durch die Kombination dieser Arbeiten ergibt sich somit ein zusätzlicher Mehrwert im Entwicklungsprozess, weshalb wir hier diesen Überblick über die Analysemöglichkeiten für IEC 61499 Software gegeben haben.

Als einen unserer nächsten Schritte planen wir die Weiterentwicklung von Detektionsmethoden für Bad Smells in IEC 61499 Software. Darunter fällt sowohl die Betrachtung von Smells, für die wir noch keine Detektionsmethoden entwickelt haben als auch die weitere Evaluierung der bereits existierenden Methoden. Insbesondere planen wir die Metriken zur Identifikation von Feature Envy als auch die KI-basierte Codeklondetektion auf echte Industriesysteme anzuwenden und (z.B. im Rahmen von Workshops) mit unserem Industriepartner zu evaluieren. Darüber hinaus planen wir eine Kombination unserer Arbeit zum Thema der Detektion von Bad Smells mit werkzeugunterstützter automatisierter Refaktorierung (siehe z.B. [37, 48]). Diese Kombination würde eine (semi)automatische Auflösung von Bad Smells ermöglichen und dadurch die Wartung von Steuerungssoftware wesentlich vereinfachen. Aufgrund der Nähe von IEC 61499 zu IEC 61131-3, IEC 61499 baut in vielen Bereichen auf IEC 61131-3 auf, denken wir, dass unsere Ergebnisse auch breitere Anwendung in der Entwicklung von IEC 61131-3-basierter Steuerungssoftware finden können.