Softwareoptimierung für Automatisierungsanwendungen

Wo viele Menschen zusammen arbeiten, passieren Fehler. Dies gilt auch für das Erstellen von Software für Steuerungsaufgaben in industriellen Anlagen. Selbst wenn diese Fehler keine größeren Schäden anrichten, verursachen sie häufig beträchtlichen Mehraufwand. Anhand von drei Beispielen soll gezeigt werden, wie sich dies vermeiden und die Qualität von Software in automatisierungstechnischen Produktionssystemen grundsätzlich verbessern lässt.

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Technische Universität München Fak.f.Maschinenwesen, Inst.2 LS f.Carbon Composites

Mit steigender Digitalisierung nimmt auch die Anzahl der geschriebenen Programme für die unterschiedlichsten automatisierungstechnischen Anwendungen zu. Nicht immer läuft deren Entwicklung konsistent und optimal. Manchmal wird doppelt programmiert oder man verlässt sich auf ein ‚Copy & Paste‘, wobei eventuelle Fehler durchgereicht werden.

Am Lehrstuhl für Automatisierung und Informationssysteme (AIS) der Technischen Universität München beschäftigt man sich seit einigen Jahren mit diesem Thema. Dabei entwickelte man ganz unterschiedliche Ansätze, um Software gerade für automatisierungstechnische Anwendungen in der Automatisierung zu verbessern.

Zwar gibt es Erfahrungen und Ansätze aus der Informatik, um eine Software zu prüfen und zu optimieren. Diese Verfahren und Methoden lassen sich jedoch nicht ohne weiteres auf die angewendete Software in automatisierungstechnischen Anwendungen übertragen, da diese oft sehr spezifisch ist und auch die Erfahrung damit fehlt. Dennoch kann man auf solche Ansätze zurückgreifen, vorausgesetzt diese werden modifiziert. Anhand dreier Beispiele, mit denen Anwender heute tagtäglich zu tun haben, werden einige dieser Methoden vorgestellt. Allen gemeinsam ist, dass sie bereits mit Industriepartnern erprobt wurden.

Problem 1: Kostenabschätzung bei Änderungen in Anlagen

Eine Herausforderung, die auf den ersten Blick gar nicht so groß scheint, ist der Austausch von Komponenten innerhalb einer Anlage. Aber: Muss ein Sensor in einer Anlage ausgetauscht werden, betrifft dies nicht nur die Hardware, sondern auch die Software. Wird etwa ein Barcode-Sensor durch einen QR-Code-Sensor ersetzt, müssen nicht nur neue Parameter in den Software-Code eingefügt werden, sondern auch die Verkabelung, die Größe der Bohrlöcher und die Dokumentation angepasst.

Die Folge: Ob sich der Tausch lohnt, wird häufig über den Daumen abgeschätzt. Kaum jemand im Unternehmen hat wirklich einen Überblick, in welchem Gewerk, welche Änderungen nötig sind. Meist müssen unterschiedliche Abteilungen diese Informationen liefern, die in irgendeiner Weise miteinander verknüpft sind. Das macht es nicht einfacher.

Ein vielversprechender Ansatz, der am AIS erprobt wurde: In der Informatik nutzt man seit längerem Metamodelle, die alle Informationen enthalten. Aus diesen kann sich der Anwender die Informationen herausgreifen, die er benötigt. Diese Methode wurde nun erweitert, um genauer die Kosten bei Änderungen abschätzen zu können. Dafür wird quasi der Weg der Änderungen in dem Metamodell verfolgt. Als Ergebnis wird automatisch eine Aufgabenliste heraus gegeben, worin alle nötigen Änderungen erfasst werden. Diese kann dann zur Aufwandsschätzung verwendet werden. Zwar ist der Aufwand für die Erstellung eines solchen Metamodells recht hoch, aber am AIS wurde auch gezeigt, dass dieses ein vertretbares Maß annehmen kann.

Problem 2: Wildwuchs in der Programmierung

Eine andere Problematik findet sich häufig bei Unternehmen, die über mehrere Standorte verfügen. Beispielsweise wird eine Dosiereinheit in eine Anlage eingebunden und hierfür ein Funktionsbaustein geschrieben. Obwohl dieser also prinzipiell vorhanden ist, kann es vorkommen, dass er von zwei unterschiedlichen Entwicklern später angepasst oder optimiert wird.

Die Gründe sind vielfältig. Vielleicht haben die beiden nichts voneinander gewusst, weil die Projekte auf den ersten Blick unterschiedlich aussahen oder die Dokumentation war doch nicht so genau, wie man es gerne hätte.

Die Doppelarbeit wäre vielleicht noch zu verkraften. Aber ein häufiges Szenario ist, dass die Anlagen in zwei unterschiedliche Länder verkauft werden. Ab da entwickelt der Funktionsbaustein – zumindest aus Programmiersicht – ein gewisses Eigenleben. Die Funktionsbausteine werden individuell weiter entwickelt. Das bedeutet, dass bei der nächsten ähnlich gelagerten Aufgabe beide Programmierer auf ihre Funktionsbausteine zurückgreifen werden, unabhängig von dem, was der andere bereits erledigt oder nicht erledigt hat. So kann es passieren, dass für die gleiche Aufgabe im Laufe der Zeit zwei ganz unterschiedliche Software-Codes entstehen.

Für das Unternehmen bedeutet dies nicht nur den doppelten Aufwand. Vielmehr ist oft nicht einmal mehr bekannt, welche Software-Codes überhaupt existieren. So gibt es Anwendungen, in denen die Ansteuerung von Antrieben jedes Mal neu programmiert wurde, obwohl sie gleich war.

Das AIS ermittelt daher zunächst über eine Code-Analyse, welche Steuerungssoftware im Unternehmen überhaupt existiert und wie der aktuelle Stand ist. Im Anschluss daran folgt ein Family Mining. Hier wird über Ähnlichkeitsverfahren herausgefunden, welche Softwareteile ähnlich sind oder nicht. Ziel ist es allgemeingültige Funktionsbausteine zu entwickeln, die z.B. für alle Antriebe in einer Anlage gelten.

Im letzten Schritt arbeitet man an einer Beurteilung, wie weit der Reifegrad eines Funktionsbausteines in der Datenbank ist. Untersuchungen des AIS haben nämlich auch gezeigt, dass es durchaus Bausteine gibt, die bis zu 40 mal in zwei Jahren geändert wurden. Das Verfahren spiegelt also wieder, ob es sich um kleinere Anpassungen oder grundsätzliche Änderungen handelt. „Damit lässt sich die Güte einer Software sehr gut bewerten“, sagt Prof. Vogel-Heuser.

Problem 3: Simulation oder Verifizierung?

Wie beweist man, dass eine entwickelte Software in der Anlage auch in der nächsten Version noch richtig funktioniert? Der Lehrstuhl für Automatisierung und Informationssysteme der TU München kommt zu dem Schluss, dass bis vor fünf Jahren viele Anwender noch auf die Simulation gesetzt haben. Mittlerweile hat die Verifizierung zwar stark an Akzeptanz gewonnen. Die Verifizierung benötigt aber ein formales Modell – ein Weg, der bei Ingenieuren in der Praxis nicht sonderlich beliebt ist. Am AIS hat man nun einen Weg gefunden, der die Verifizierung vereinfacht. Dabei greift man auf die bewährten Methoden der Test-Tabellen zurück, die jedoch modifiziert werden, zum Beispiel in puncto Benutzerfreundlichkeit.

Auch bei der Prüfung von verschiedenen Software-Versionen wird häufig ein Trick verwendet: Der Entwickler geht davon aus, dass die erste derzeit verwendete Version richtig ist und vergleicht nur die geänderten Teile der Software. Dies spart enorm Zeit. Das AIS entwickelte auf dieser Basis ein Tool, das in einem evolutionären Prozess den Software-Code überprüft und freigibt. Ziel ist es, dass dieses Tool in gängige Automatisierung-Umgebungen integriert wird.

Die drei aufgezeigten Beispiele zeigen, dass es bereits Methoden und Konzepte gibt, um bestehende Software zu verbessern und zu optimieren. Dies führt im Ende nicht nur zu geringeren Kosten, weil Doppelarbeit vermieden wird, sondern die Qualität der Software wird nachhaltig erhöht.

Sieben Empfehlungen für bessere Software

Unabhängig von den drei in diesem Beitrag aufgezeigten Beispiel-Projekten hat das AIS festgestellt, dass im Grunde immer wieder die gleichen Verhaltensweisen zu Fehlern, Inkonsistenzen oder doppelter Arbeit führen. Daraus leiten sich die folgenden sieben Empfehlungen ab:

• Copy & Paste bzw. das Modifizieren von bewährten Funktionsbausteinen führt nicht nur oft zu einem vermehrten Programmieraufwand, sondern auch dazu, dass Fehler von einer Version zur nächsten durchgeschleift werden,

• Stattdessen sollten lieber Modulbibliotheken mit einem durchdachten Freigabeprozess verwendet werden.

• Es empfiehlt sich ein Variantenmanagement-System einzuführen, um den Überblick über die implementierten Software-Versionen zu behalten.

• Es hat sich bewährt, wenn firmeneigene Richtlinien eingeführt werden, die eine Definition oder Beschreibung der Varianten und Versionen enthalten. Hierbei ist darauf zu achten, dass diese verständlich formuliert werden.

• Einführung von formalen Methoden in den Engineering-Prozess.

• Anforderungen genau spezifizieren.

• Es hat sich gezeigt, dass eine Kostenabschätzung über den Daumen bei Änderungen in der Hard- und Software häufig zu niedrig angesetzt wird. Am AIS wurde ein systematischer Ansatz hierfür entwickelt, um solche Kosten viel genauer einzuordnen.

Wie die drei in diesem Artikel beschriebenen Verfahren im Detail funktionieren, ist Bestandteil einer Artikelserie, die im Verlauf der nächsten Ausgaben der ELEKTRONIKPRAXIS sowie auf embedded-software.engineer erscheinen wird.

* Prof. Dr.-Ing. Birgit Vogel-Heuser leitet als Ordinaria den Lehrstuhl für Automatisierung und Informationssysteme der Technischen Universität München.

(ID:46210187)