Optimierung von Automations-Software: Effizientes Variantenmanagement

Ordnung ist das halbe Leben – doch das Verwalten und die Dokumentation von Software und ihren Änderungen werden im Maschinen- und Anlagenbau leider häufig vernachlässigt. Das Projekt REDSPLAT an der TU München will das ändern.

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

MHP Management- und IT-Beratung GmbH

Parasoft® Deutschland GmbH

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

Wissen Sie genau, welche Version einer Software Sie benutzen? Bei Office-Software hilft der Click aufs Fragezeichen, aber bei anwendungsspezifischer Software für speicherprogrammierbare Steuerungen (SPS) geraten die meisten Anwender bei dieser Frage ins Stocken. Falls Sie es nicht wissen, mag es für Sie ein Trost sein, dass Sie damit nicht allein dastehen. Eine Umfrage des Lehrstuhls für Automatisierung und Informationssysteme (AIS) der TU München ergab, dass nur die Hälfte aller Unternehmen ein Variantenmanagementtool einsetzt. Die andere Hälfte nutzt Excel, konfigurationsbasierte Ansätze oder Eigenentwicklungen.

Fakt ist, dass in der Regel anwendungs- und nutzerspezifische SPS-Software nicht verwaltet wird. Die Folge: Kaum jemand weiß, wie der Stand einer Software an anderen Produktionsstandorten ist oder wie sich die vielen kundenabhängigen Varianten über die Jahre entwickelt haben. Dies gilt besonders, wenn mehrere Programmierer am gleichen Projekt arbeiten. Nicht selten kommt es zu doppelten Implementierungen derselben Funktionalität durch verschiedene Entwickler, teilweise sogar in unterschiedlichen Programmiersprachen.

Bildergalerie

Eigentlich werden zur Softwareerstellung für SPSen in der Norm IEC 61131-3 fünf Programmiersprachen definiert. Die Sprachen können innerhalb eines Softwareprojekts gemischt werden. Obwohl jede der Sprachen sich besonders gut für spezielle Funktionalitäten eignet, haben Programmierer teilweise „Lieblingssprachen“ und so passiert es, dass gleiche Funktionen nicht nur doppelt, sondern sogar in verschiedenen Sprachen implementiert sind.

Genau dies ist Inhalt des Projektes ‚Reverse Engineering Design of Software Product Lines for Automation Technology (RED SPLAT)´ und weiteren Untersuchungen. Darin werden Methoden entwickelt, um eine durch ‚clone-and-own‘ gewachsene Variantenvielfalt automatisierungstechnischer Softwareprojekte (semi-)automatisch in eine Softwareproduktlinie mit hohem Wiederverwendungsgrad zu überführen. Besonderer Fokus liegt auf den industriellen Anforderungen und die Praxistauglichkeit.

Wie kommt es zum Variantenreichtum?

Automatisierte Produktionssysteme (aPS) sind hochkomplexe mechatronische Systeme, deren Entwicklung verschiedene Disziplinen umfasst. Dabei reicht die Bandbreite von Maschinen bis zu ganzen Produktionsanlagen, was sich wiederum in der Anzahl von Eingangs- und Ausgangs-Signalen widerspiegelt, von wenigen hundert bis zu 10.000 Signalen sind möglich. Zusätzlich müssen abhängig von der Branche bestimmte Standards und Zertifikate während der Entwicklung berücksichtigt werden (z. B. Hygienevorschriften in der Lebensmittel- und Getränkeindustrie). Meist handelt es sich also um einzigartige Systeme, deren Entwicklung in Form eines interdisziplinären Projekts ausgeführt wird.

Die Lieferanten setzen zwar auf wiederverwendbare Software, um die Entwicklungszeit zu verkürzen und gleichzeitig die Entwicklungskosten zu senken. Aber die Realität ist eine andere: Während der Lebensdauer dieser Systeme müssen neue Märkte, wechselnde gesetzliche Anforderungen oder neue Technologie berücksichtigt werden. Sind kurzfristig schnelle Änderungen notwendig, was häufig bei der Inbetriebnahme oder bei der Fehlersuche in der Betriebsphase der Fall ist, werden meistens Änderungen an der Steuerungssoftware vorgenommen, da diese im Vergleich zu mechanischen und elektrischen/elektrischen Geräten leicht angepasst werden können. Die Dokumentation dazu geht während hektischer Phasen durchaus mal unter.

Es kommt aber noch eine weitere Problematik hinzu, etwa bei Unternehmen, die über mehrere Standorte verfügen. Beispielsweise wird eine Dosiereinheit in eine Anlage angebunden und hierfür ein Funktionsbaustein für die Ansteuerung 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.

Ein häufig auftretendes Szenario ist allerdings, dass die Anlagen in zwei unterschiedliche Länder verkauft werden. Ab da entwickelt der Funktionsbaustein – zumindest aus Programmiersicht – ein gewisses Eigenleben. Sprich bei der nächsten ähnlich gelagerten Aufgabe werden beide Programmierer auf ihre jeweiligen Funktionsbausteine zurückgreifen. Denn Softwarevarianten werden im Maschinen- und Anlagenbau typischerweise mittels copy-paste-and-modify Strategie (auch clone-and-own Ansatz genannt) gebildet, was die Wartung und Weiterentwicklung der Varianten behindert.

Auf diese Weise kann es passieren, dass für die gleiche Aufgabe im Laufe der Zeit zwei ganz unterschiedliche Softwarecodes entstehen. Für das Unternehmen bedeutet dies nicht nur doppelter Aufwand. Vielmehr wissen die Unternehmen oft nicht, welche Software-Codes überhaupt existieren. So gibt es beispielsweise Anwendungen, in denen die Ansteuerung von Antrieben jedes Mal neu programmiert wurde, obwohl 20 vorhandene ähnlich und zur Wiederverwendung geeignet waren.

Zudem erhält der Kunde zwar Zugriff auf Teile der SPS-Software und kann so die Originalsoftware warten und ändern. Besonders bei älteren Steuerungsprojekten liegen aber keine Modelle der Software vor, die eine Nachvollziehbarkeit des Codes ermöglichen. Nur wenige Editoren für die Programmierung der IEC 61131-3 bieten die Möglichkeit, die Softwarestruktur zu visualisieren.

Der Software Systematik und Struktur geben

Im Gegensatz dazu zeichnet sich das Konzept der Softwareproduktlinie durch eine strukturierte Variantenmodellierung und systematische Wiederverwendung von Softwarebausteinen aus. Allerdings ist der Übergang von der bisherigen Vorgehensweise zu einer strukturierten Wiederverwendung auf Basis von Softwareproduktlinien nicht einfach. Schließlich will man die bisherigen Varianten an Softwarecodes weiter nutzen und aus Zeit- und Kostengründen nicht ganz von vorne anfangen.

Beziehungen innerhalb der Software sichtbar machen

Am AIS wurde daher ein Konzept entwickelt, mit dem die Software dargestellt und auf Modularität untersucht werden kann. Dafür wird zunächst über eine Code-Analyse ermittelt, welche SPS-Software überhaupt existiert, welche Zusammenhänge in der Software bestehen und wie sie prinzipiell strukturiert ist. Im Anschluss daran folgt das Family Mining. Hierbei wird über metrikenbasierte Ähnlichkeitsverfahren herausgefunden, welche Softwareteile ähnlich sind oder nicht.

Ziel ist es aus bestehenden, kundenspezifischen Funktionsbausteinen allgemeingültige Funktionsbausteine zu entwickeln, die z.B. durch Parametrisierung für alle Antriebe in einer Anlage verwendbar sind. Dabei wurde ein Verfahren entwickelt, um für eine existierende Menge von Varianten ein Familienmodell zu erstellen, das die Gemeinsamkeiten und Unterschiede der Softwarevarianten repräsentiert.

Hierfür wird zunächst das Steuerungsprogramm nach IEC 61131-3 betrachtet und sogenannte Programmorganisationseinheiten (dies sind einzelne Programme, Funktionsbausteine und Funktionen), die den auszuführenden Code an sich beinhalten, grafisch dargestellt. Über diese Visualisierung lassen sich Programmorganisationseinheiten (POE) erkennen und beurteilen, ob diese stark kommunizieren und daher sinnvoll zu einem Modul zusammengefasst werden können. Ebenso lassen sich ungünstige Moduleinteilungen oder -granularitäten aufdecken.

Darüber hinaus wurde am AIS ein Werkzeug entwickelt, mit dem die Informationen aus dem Steuerungsprogramm eingelesen und so der Strukturgraph erzeugt wird. Mit diesem Codeanalysetool ist es möglich, die Daten so zu filtern, dass spezifische Softwareabschnitte oder -teile im Detail untersucht werden. Eine gezielte Analyse auch größerer Projekte wird somit erleichtert.

Ferner hilft dieses Codeanalysetool beim Auffinden falscher Vernetzungen zwischen POEs und verbessert das Verständnis für bestehende Codes. Um die Einsatzfähigkeit des Tools zu steigern, wird dieses laufend verbessert und an verschiedene Programmierstile der Industrie angepasst.

Veränderungen und Reife von Modulen über Jahre verfolgen

Im letzten Schritt arbeitet das Team am Lehrstuhl an einer Beurteilung, wie groß der Reifegrad eines Funktionsbausteines in bestehenden Modulbibliotheken ist. Weitere Untersuchungen des AIS haben nämlich gezeigt, dass es durchaus Bausteine gibt, die bis zu 40mal in zwei Jahren geändert wurden.

Der nun entwickelte Ansatz ist nicht nur in der Lage zu zeigen, wie oft ein Baustein geändert wurde, sondern spiegelt auch wieder, ob es sich um kleinere Anpassungen oder grundsätzliche Änderungen handelt. Dies sagt viel über die Güte einer Software aus. Auch hier sieht das AIS noch erhebliches Verbesserungspotential.

So zeigte die oben erwähnte Umfrage auch, dass die internen Freigabeprozesse einer Software nicht so gehandhabt werden, wie es in IT-Unternehmen Standard ist. Nur ein Viertel der Unternehmen aus der Umfrage lässt etwa ein Programmmodul von einem anderen Mitarbeiter als dem Modulentwickler testen. Auch hier werden vom AIS derzeit praktikable Wege gesucht, um generell die Qualität von Steuerungssoftware nachhaltig zu verbessern.

Nähere Informationen zu RED SPLAT finden Sie auf derWebseite des Forschungsprojekts.

Ebenfalls aus der Reihe „Optimierung von Automatisierungsanwendungen“ der TU München:

Softwareoptimierung für Automatisierungsanwendungen

Optimierung für Automatisierungsanwendungen: Kosten richtig einschätzen

Höhere Softwarequalität in Automatisierungsanwendungen

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

* Juliane Fischer, M.Sc., ist wissenschaftliche Mitarbeiterin am Lehrstuhl für Automatisierung und Informationssysteme der Technischen Universität München.

(ID:46301330)