Wie setze ich Software-Updates im laufenden Anlagenbetrieb um?

Anbieter zum Thema

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

DevOps, die stetige Aktualisierung von Software, ist in Produktivanlagen eher unüblich. Doch auch dort fallen Bugfixes und Optimierungen an. Wie pflegt man diese ein, ohne laufende Prozesse zu unterbrechen?

Der Spruch „Do not touch a running system“ dürfte allbekannt sein. Selbstverständlich ist es nicht geboten, schnell und ungeplant noch kurz vor Abschluss eines Projekts eine vermeintlich unkritische Änderung einzubringen. Das Problem ist das „schnell noch“ und der danach nicht ausgeführte Test.

In der Praxis zeigt sich jedoch häufig, dass das konsequente Pochen auf dieses Prinzip ist meist eherverbergen soll, dass entweder die Dokumentation schlecht ist, oder die Dinge bereits zu verwoben und unüberschaubar geworden sind – oder beides.

In der IT-Welt hat sich in den letzten Jahren immer mehr das DevOps-Prinzip etabliert, in dem Software auch nach Abschluss eines Projekts noch kontinuierlich weiterentwickelt und gepflegt wird. In Produktivanlagen ist eine solche Vorgehensweise eher nicht erwünscht oder üblich: Das laufende System soll nach Möglichkeit nicht angefasst werden. Doch gibt es auch hier immer mal wieder den Bedarf nach Updates, sei es zur Beseitigung erkannter Fehler oder auch nur für Verbesserungen im Datenaustausch für IoT.

Alles muss miteinander upgedatet werden ?

Systeme bestehen aus mehreren Komponenten, und diese aus Modulen. Wenn ein System mit einer erweiterten oder korrigierten Komponente nur dann läuft, wenn alle anderen Komponenten auch upgedatet sind, dann wird es schwierig. Beispielsweise laufen die Komponenten miteinander nur mit „der“ neue Library-Version von xy. Wenn es dann in Sonderfällen seltsame Erscheinungen gibt, die beim Systemtest so nicht auffällig waren, ist guter Rat möglicherweise teuer.

Nicht nur beim Komponenten-Update auf Anlage, auch im Integrationstest ist folgende Situation typisch: In den Entwicklungsabteilungen arbeitet ein Team am Teil A einer Software, das andere Team bearbeitet Teil B. Die zunächst in der Einzelentwicklung gegen eine simulative Umgebung getestete Software läuft nicht gemeinsam. Wo anfangen? Wenn es anfänglich läuft, stellen sich später Fehlfunktionen heraus, und Team A und B schieben sich zunächst gegenseitig die Schuld zu. Nun kann es ja auch sein, dass beim Umrüsten der Testanlage ein Kabel nicht mehr richtig steckt, unbekannt und nicht erwartet, also auch nicht dort hingeschaut.

Es ist sehr hilfreich, einzelne Komponenten getrennt betrachten zu können. Beim Integrationstest sollte man bestimmte Komponenten wieder mit dem alten Stand, dessen Verhalten bekannt und getestet ist, zur Fehlersuche rücktauschen können. Bei einer Anlagenumrüstung ist es günstig, Schritt für Schritt neue Komponenten einzubauen, mit Blick auf das Gesamtverhalten.

Austauschmöglichkeit zwecks Fehlersuche

Auch bei der Fehlersuche auf Anlage ist es hilfreich, Stände tauschen zu können zwecks Beobachtung, wie sich der Fehler verhält. Fehler lassen sich durch zwei Herangehensweisen finden, die allerdings in einer Kombination angewendet werden sollten:

• Suche der Ursache durch Auswertung von Logfiles und dergleichen, Nachstellen der Umgebungsbedingungen in einer Testumgebung, Analyse des Verhaltens, Debugwerkzeuge; oder

• Austausch vermuteter Teile (Hardwarekomponenten, Software), Beobachtung des Verhaltens von außen, dazu gehört auch der Einbau des vermutet defekten Teils an anderer Stelle.

Die Variante a) kommt erst als zweites zum Zuge, schon deshalb weil nicht bei jedem Problem die Entwicklermannschaft eingebunden werden kann. „Was macht ein Inbetriebsetzer, wenn er an seinem Auto einen Platten hat? Er wechselt systematisch die Räder und schaut ob der Fehler wandert.“ - Reparaturpersonal hat oft einen geschulten Blick, an welchem Teil die Ursache festgemacht werden könnte, aus Erfahrung, wiederholte Beobachtung von Situationen, ohne die genauen inneren Abläufe in diesen Teilen zu kennen.

Komponenten aufwärts- und abwärtskompatibel halten

Nun muss dies auch funktionieren können. Es ist notwendig, dass geänderte Komponenten mit alten Ständen der anderen Komponenten verträglich sind. Möglicherweise sind damit zwar neue Funktionalitäten noch nicht nutzbar, da diese eben in mehreren Komponenten zueinander passende Nachbesserungen erfordern. Jedoch ist die Funktionalität an sich, oder die bisherige bekannte Funktionalität, testbar.

Die Schnittstellen müssen nicht nur formal zueinander passen sondern auch funktional. Wenn sie nicht formal passen, helfen Schnittstellenkonverter. Das kann in einer Software eine Zwischenschicht, ein Adapter oder Wrapper sein. In Hardware könnte ein Protokollumsetzer Alt und Neu miteinander verbinden. Beides bedeutet Aufwand, der jedoch gerechtfertigt ist, wenn für einen Technologiesprung eine Schnittstelle formal geändert wird (beispielsweise von RS232 auf 2-Draht-Ethernet).

Die funktionale Kompatibilität ist kritischer zu betrachten. Was ist funktionale Kompatibilität? Wenn es ein Request auf die Abfrage eines bestimmten Wertes gibt, mit einer Identifikationsnummer, dann muss der Partner formal antworten, auch wenn dieser Wert in der geänderten Komponente keine Rolle mehr spielt. Eine solche funktionale Kompatibilität ist meist mit nicht allzu großem Aufwand realisierbar, man muss es nur wollen.

Schnittstellen kompatibel und „auf Zukunft“ festlegen

Die Fragen sind: Welche Daten, welche Bedeutung der Daten an gleicher Position, Zykluszeit-Vorschriften, strenge Versionskontrolle an den Schnittstellen.

Die Versionskontrolle (Platzierung eines Versionsidentifikators als Bestandteil der Schnittstelle) kann in aller Strenge die Mischung Neu und Alt vollständig verhindern. Die Versionskontrolle sollte sich auf die Schnittstellenspezifikation selbst beziehen und nicht auf die Version der Implementierung. Nur so hat man die Chance der Mischung.

Abwärtskompatibilität („Neu kann mit Alt“) bedeutet immer zugleich Aufwärtskompatibilität („Alt muss später mit irgendeinem Neu harmonieren“. An Schnittstellen sind also folgende Dinge zu bedenken:

• Handelt es sich um eine Datenschnittstelle (etwa in einem Telegramm), dann hilft eine Längenangabe am Anfang des Datensatzes zusammen mit einer Versionskennung. Man kann dann in späteren Versionen die Daten erweitern und formalistisch abwärtskompatibel bleiben.

• Wenn in einem Datensatz mehr Daten stehen als erwartet (von einer neuen Softwareversion gesendet), dann sind die zusätzlichen Daten einfach zu ignorieren. Die alte Software unterstützt folglich nicht alle neu erwarteten Funktionen.

• Wenn in einem Datensatz weniger Daten stehen als erwartet (von der alten Software gesendet), dann sind die nicht erhaltenen Daten mit einem zielführenden Defaultwert zu besetzen, der möglicherweise in der neuen Komponente auch über Parametrierung fest vorgegeben werden könnte.

• Es kann auch umgekehrt sein: Die neue Software liefert bestimmte Werte für die alte Komponente nicht mehr. Wenn die alte Software damit zurechtkommt, spart man sich folgendes: Die neue Schnittstellenversion muss wegen der Abwärtskompatibilität bestimmte Daten senden, auch wenn sie keine Bedeutung mehr haben, möglicherweise nur als Sondermodus aktiviert.

• Wenn die Bedeutung der Daten an einer Position geändert ist, dann kann dies zu beträchtlicher Inkompatibilität führen. Das spricht gegen das Weglassen von alten Daten in einer neuen Version, weil irgendwann die Positionen mit neuen Daten besetzt werden. Es gibt eine Lösung für dieses Problem, die etwa der Herangehensweise in XML im Gegensatz zu einfacher Binärcodierung in Datenfiles entspricht: Die Bedeutung der einzelnen Datenpositionen muss deklariert werden. In XML ist es egal, an welcher Position im File etwas steht. Wichtig ist die eindeutige Element- und Attribut-Bezeichnung einschließlich der Verwendung von Namespaces, dann wird es verwechslungssicher. Dieses Prinzip in Datensätzen eines Kommunikationstelegramms zu etablieren, mit knappen Speicherplatz, geht aber so einfach nicht.

• Die Lösung des Problems kann eine Datagramm-Konfiguration sein, die entweder als extra (längeres) Telegramm initial gesendet wird, oder per Parametrierung, als Konfigurationsfile oder dergleichen, mitgegeben wird. Im zweiten Fall ist es allerdings nicht mit dem einfachen Austausch der Komponente Alt gegen Neu getan. Es wäre nun interessant, bei Verwendung von Ethernetkommunikation mit a priori genügenden Ressourcen in der Anlaufphase solche Konfigurationstelegramme von vorn herein festgelegt zu wissen.

Der Vergleich mit althergebrachten analogen Schnittstellen soll als Vergleichsbasis zum Verständnis dienen: Auch bei analogen Schnittstellen gibt es zuweilen Stecker, die in Buchsen mit mehr Pins passen, aber eben nicht alle Pins versorgen. Das gab es schon bei den alten Diodenbuchsen zwischen Tonband und Röhrenradio, 3-polige und 5-polige Variante für Mono oder Stereo. Wenn Signale nicht passen dann ist es bei Hardwareteilen die Frage ob beim Zusammenstecken etwas kaputt geht oder eine Teilfunktion nicht geht. Jedenfalls ist eine strenge Kompatibilitätsüberprüfung, die sich nicht nur auf die Schnittstelle sondern sogar auf die Funktion dahinter bezieht, nicht zuträglich und sollte zumindestens verantwortlich abgeschaltet werden können.

Es soll allerdings in diesem Artikel nicht der Überprüfung der Verträglichkeit etwa von Akku und Ladegerät, Computerstromversorgung oder Tintenpatronen gegen geredet werden. Das ist Consumerbereich, dort sollte alles sehr wohl aufeinander abgestimmt sein weil sonst die Anzahl möglicher Fehlerfälle zu groß wird. Für sicherheitsrelevante Software – Verhindern einer Verwechslung, gelten selbstverständlich ebenfalls strenge Regeln, die jedoch etwa bei einem Softwaretest im Labor mit auffälligen Sondermaßnahmen (darf nicht im Betrieb versehentlich passieren) aufgehoben werden können sollten.

DevOps

Nunmehr kann partielles Development and Operation betrieben werden in dem man einzelne Komponenten hochrüstet, die verträglich sind mit den anderen nicht erneuerten Teilen. Man kann somit an bestimmte Stellen neue Funktionalitäten nutzen, dort wo sie technisch erwünscht sind oder mehr Service bieten und die Arbeit erleichtern. Man kann die neuen Features kennen und schätzen lernen, etwa in dem man zunächst nur eine Instanz von mehreren Gleichen hochrüstet und das Verhalten einschätzt. Das ist jedenfalls besser, als gar nicht hochzurüsten, weil man den notwendigen Testaufwand scheut.

Wenn eine Komponentensoftware sich jedoch langjährig bewährt hat und sich schnittstellenverträglich verhält, dann kann sie auch beibehalten werden - sei es aus Zeit- oder Aufwandsgründen, oder nur aus Gründen der Vertraulichkeit. Dennoch wäre es interessant zu wissen wie ein Austausch oder eine Änderung möglich wäre – auf die Zukunft besehen.

DevOps aus Sicht von Softwareentwicklung und Anwendung in Anlagen

Grafische objektorientierte C-Programmierung mit Simulink

* * Hartmut Schorrig war langjähriger Entwicklungs- ingenieur bei Siemens und betreibt die IT-Plattform vishia.org.

(ID:46498746)