Die Tage, in denen ein Anlagen- oder Maschinenprogrammierer ein bisschen Code in ein paar Tagen geschrieben hat und für sich alleine verwalten musste, sind gezählt. Heute ist meist eine größere Anzahl von Entwicklern an einem SPS-Programm beteiligt. Zudem nimmt die Zahl der Projekte und der Versionen sowie der Umfang der Projekte ständig zu. Nicht zuletzt kann es sich keine Firma mehr leisten, aufgrund von Fehlzeiten seiner Entwickler mit einer Fehlerbehebung oder einem Umbau zu warten. Stattdessen müssen die Programme von mehreren Entwicklern und Inbetriebnehmern verstanden werden und auf dem Server zu finden sein. Soweit die Theorie – die betriebliche Praxis sieht heute jedoch vielfach noch anders aus!

Dadurch, dass in der Automatisierungstechnik selten mit rein textuellen Sprachen programmiert wird, ist die Darstellung eines Vergleichs verschiedener Versionen und das Mergen – also das Zusammenführen von Zweigen – nicht immer trivial. Ein Programmierer, der aus der Elektrotechnik kommt und es seit vielen Jahren gewohnt ist, in KOP, AS und FUP zu programmieren, greift selten auf strukturierten Text zurück und will seinen Code beim Projektvergleich auch nicht in irgendwelchen meist kryptischen Textzeilen entziffern müssen. Auch XML-Formate, die hierfür teilweise als Lösung angeboten werden, lesen viele Programmierer nicht gerne.

Ein weiteres Problem der Automatisierungstechnik sind die Baustellen-Aufenthalte. Ein Entwickler, der sich monatelang weit weg vom zentralen Server aufhält, überlegt sich üblicherweise seine eigene Methode der Sicherung. Sobald er wieder in der Firma ist, erwarten ihn dann vermutlich viele Konflikte beim Zurückladen des Projektes auf den Server. Wäre da noch die „menschliche Komponente“, die nicht außer Acht zu lassen ist: Die meisten Maschinenprogrammierer sind – bedingt durch die Historie dieses Berufs – „Einzelkämpfer“. Sie sind es noch nicht gewohnt, teamorientiert zu entwerfen und zu entwickeln und haben sich fast immer bereits einen für sie praktikablen Workflow der Versionierung erarbeitet.

Das Prinzip der Versionsverwaltung

Das Grundprinzip der Software-Versionierung: Das Ablegen verschiedener Versionen von Dateien auf einem zentralen Archiv wird Tool- unterstützt koordiniert.

© ITQ

Ungeachtet dieser „Hemmschuhe“ nimmt die Notwendigkeit eines Konfigurationsmanagements beziehungsweise einer Versionsverwaltung in der Automatisier­ungstechnik immer mehr zu. Die Versionsverwaltung zählt zu den essenziellen Werkzeugen der agilen Programmierung. Die Protokollierung des entsprechenden Entwicklers und des Datums der Änderung erfolgt hierbei meist automatisch. Zusätzlich hat der Benutzer die Möglichkeit, den Änderungsgrund anzugeben. Für die Qualitätssicherung im Bereich der Lebensmittel- und Medizinbranchen sind solche Nachweise in vielen Fällen schon Pflicht. Die grundsätzliche Funktionsweise eines Software-Versionsverwaltungssystems stellt sich aus Sicht des Benutzers so dar, dass er die Source- und Dokumentationsdateien in ein übergeordnetes Archiv, oft „Repository“ genannt, ablegt. Von dort werden die Dateien dann geladen („ausgecheckt“), lokal verändert und nach Veränderung wieder in das Archiv zurück geladen („eingecheckt“), wobei hier eine treffende Beschreibung der Veränderung anzugeben ist. Im einfachen Fall checkt sich ein Kollege die bereits geänderten Dateien aus, verändert diese und checkt sie wieder auf dem Server ein, so dass es keinerlei Konflikt geben kann.

Problematischer wird es, wenn zwei Kol­legen parallel an derselben Datei ar­beiten und im Anschluss daran einchecken wollen. Aber auch hier hilft das System in der Regel, indem es die Versionen entweder automatisch zusammenführt oder bei komplizierteren Änderungen auf einen Konflikt hinweist und das Auflösen halbautomatisch unterstützt. Die meisten Versionsverwaltungstools bieten auch den Lock-Mechanismus als einstellbare Option für bestimmte Dateien oder Dateitypen an. Das heißt: Einzelne Dateien werden vor einer Änderung durch den Benutzer gesperrt und nach Abschluss der Änderung wieder freigegeben. Während sie gesperrt sind, können andere Benutzer diese Dateien nicht ändern.

Grundsätzlich lässt sich zwischen drei Arten der Versionsverwaltung unterscheiden: lokal, zentral und verteilt. Bei der lokalen Versionsverwaltung wird die Historie einfach lokal auf dem Entwicklungsrechner gespeichert. Beim zentralen Ansatz ist lokal auf dem Rechner ein Client installiert, der dann zum Ein- und Aus-Checken auf einen zentralen Server zugreift. Mit verteilten Versionsmanagementsystemen können Projekte lokal auf dem eigenen Rechner versioniert und – sobald sich die Gelegenheit dazu ergibt – wieder in das zentrale System eingefügt werden. Gerade letztere Variante ist in der Automatisierungstechnik immer öfter gefragt, da hier die Programme nicht selten auf der Baustelle, sprich nicht immer mit direktem Zugriff auf den Firmenserver fertiggestellt beziehungsweise erweitert werden.

In den einzelnen Repositories hat es sich bewährt, die Unterverzeichnisse „Trunk“, „Tags“ und „Branches“ anzulegen. Der Trunk (Stamm) beinhaltet das aktuelle Arbeitsverzeichnis. Dort werden die täglichen Entwicklungs­arbeiten getätigt. Ein Gesetz, an das sich die Entwickler zu halten haben, ist dabei, dass Änderungen, die in den Trunk eingecheckt werden, immer compilierbar sind. In Tags (Markierungen) werden spezielle Markierungen während des Projektfortschritts erzeugt. Eine solche Markierung ist beispielsweise eine neue auslieferbare Version der Anwendung. Branches (Verzweigungen) stellen schließlich parallele Entwicklungsstränge dar. Dies ist zum Beispiel der Fall, wenn eine Version abgeschlossen ist und nach einer Auslieferung weitergepflegt wird. Eine Weiterentwicklung von abgeschlossenen Versionen ist in der Regel dann notwendig, wenn nachträglich Fehler bekannt werden, die direkt zu beheben sind, noch bevor eine neue Version zur Auslieferung kommen kann. Branches sollten auch dann anlegt werden, wenn eine Weiterentwicklung oder Optimierung am Trunk zu tätigen ist, die den Trunk für längere Zeit nicht übersetzbar machen würde. Um die Änderungen auch in die neue Version einzupflegen, lassen sich verschiedene Zweige mit einem „Merge“ zusammenführen.

Die Vor- und Nachteile der gängigen Tools

Beispielhafte Historie einer Software-Entwicklung: Verwaltung von Releases und Parallel-Entwicklungen in Branches beziehungsweise Tags und anschließendes Zurückführen in die Hauptentwicklung.

© ITQ

Das derzeit wohl bekannteste freie Versionsverwaltungstool ist Subversion, kurz SVN. Bei diesem Freeware-Tool handelt es sich zunächst um eine reine Kommandozeilen-Applikation. Im Internet findet sich jedoch eine breite Palette an grafischen Frontends. Meist werden die Programme TortoiseSVN (Open Source) oder SmartSVN von der Firma Syntevo verwendet, wobei SmartSVN vor allem in der Professional-Version mehr Features bietet,  jedoch weniger performant ist.

Subversion ist eine zentrale Versions­verwaltung. Die Verwaltung der Daten geschieht also auf einem einzigen Server in einem Archiv (Repository). Für jedes Projekt wird üblicherweise ein eigenes Repository verwendet. Es ist aber auch möglich, mehrere Projekte in einem gemeinsamen Verzeichnis abzulegen. Das Mergen von Branch oder Tag mit dem Trunk kann Subversion automatisiert durchführen – jedoch nur solange die Änderungen klar erkennbar sind. Bei parallelen Änderungen an beiden Zweigen gilt meist, bestimmte Konflikte noch per Hand zu lösen. Was Subversion unter anderem auszeichnet, ist die effiziente Art, wie Verzweigungen und Markierungen gespeichert werden. Das Tool erzeugt dafür keine physische Kopie, sondern nutzt Verlinkungen zum Haupt-Entwicklungsstrang. Grundsätzlich handelt es sich bei Subversion um ein sehr leistungsfähiges Werkzeug, das aber für die Hochsprachenprogrammierung entwickelt wurde. Dementsprechend erfüllt es nicht alle Anforderungen der Automatisierungstechnik zum Beispiel in puncto grafischem Vergleich oder dezentraler Verwaltung.

Um Änderungen an einzelnen Datenbausteinen feststellen zu können, sind Steuerungsprogramme, deren gesamter Code in einer einzigen Projektdatei verwaltet wird, zuerst zu modularisieren. Dies ist zum Beispiel bei Codesys-basierten Systemen sowie bei Systemen von Rockwell oder Siemens der Fall. Um den Ein-Check-Vorgang auto­matisiert durchführen zu können, gibt es die Möglichkeit, Tools für die Durchführung der Modularisierung zu schreiben. Das bedeutet speziell für Siemens, die Quellen zu exportieren, bei Rockwell l5k-Dateien zu erstellen und auch bei Codesys die einzelnen Module zu exportieren. Ein ähnliches Prozedere hat nach dem Aus-Check-Vorgang zu erfolgen: Die vom Kollegen geänderten Dateien müssen wieder ins Projekt eingefügt werden. Dieser Import und Export kann durchaus einige Minuten in Anspruch nehmen.