DevOps aus Sicht von Softwareentwicklung und Anwendung in Anlagen

Anbieter zum Thema

MicroConsult Academy GmbH

emlix GmbH

In der Entwicklung für Anlagensoftware wird das Thema DevOps in der Regel gar nicht in Erwägung gezogen. Dabei ist die agile Entwicklungsmethode für die Erzeugung von Regelungen durchaus hilfreich, bisweilen sogar wünschenswert. Eine Betrachtung aus der Entwicklerpraxis.

Software hat es an sich, dass sie von kleinen Änderungen lebt. Dem Entwickler fallen beim Testen Mängel selbst auf, die er im Eigeninteresse behebt. Der nach einem Softwareentwicklungsschritt vom Entwickler durchgeführte Unit-Test sichert, dass dabei nichts schief gegangen ist.

Anforderungen von außen, vom Kunden, von einem Integrationstestteam, erfordern dagegen mehr Aufwand. Es muss zunächst geklärt werden, welche Dinge in der Software zu ändern ist. Das kann der Anfordernde nicht sagen, er formuliert ‚nur‘ die Requirements. Auch hier ist das Team der Softwareentwickler gefragt. Es passiert dabei durchaus, dass die Software zunächst an der falschen Stelle geändert wird, dort wo das Requirement seine Wirkung zeigen soll. Erst im Laufe der Entwicklung zeigt es sich, dass die eigentliche Funktionalität viel überschaubarer anders erbracht werden kann. Beispielsweise müssen Basisdaten in ihrer Struktur angepasst werden, was gleich etwas mehr Übersicht in die Datenhaltung bringt, anstatt an den Ausgabedaten zu basteln mit gewissen passend gespeicherten Zusatzinformationen. Das Ändern der Basisdaten ist nicht kritisch, wenn man systematisch vorgeht und die bestehenden Testumgebungen nutzt um Fehler zu erkennen.

So läuft Softwareentwicklung, etwas anders als von einem Requirements-Engineering-System mit kleinen Änderungsaufträgen vorgedacht. Die zentrale Rolle bleibt beim Softwareentwicklerteam mit Softwarearchitekturwissen oder vielleicht bei dem einem vorhandenen Architekt-Guru.

DevOps ist ein Wunsch der Softwareentwicklung

Wenn das Softwareentwickler-Team geändert und auch getestet hat, dann möchte es seine Arbeit in der Praxis eingesetzt wissen. Denn sonst kommen weitere Fehler mit dem alten Softwarestand herein, die entweder mit der Umstrukturierung schon erledigt sind, oder (weil noch nicht bedacht) sich im neuen Stand anders zeigen, und, insbesondere: Eine andere Herangehensweise der Korrektur erfordern. Kommt es immer wieder zu neuen Änderungsanforderungen mit den alten Ständen, dann entsteht immer wieder ein irgendwie anderer neuer Stand, also bei mehrfachem Einsatz der Software sehr viele verschiedene Stände. Das ist schlecht überschaubar, braucht mehr Personal, dass zwangsläufig gegeneinander arbeitet weil jeder einen anderen Blick aufgesetzt bekommt.

Die organische Herangehensweise aus Sicht der Softwareentwicklung ist also:

• Wissen, was nicht geht, sowie Requirements gesammelt zu erhalten,

• Ideen der Umsetzung, gegebenenfalls dafür auch gewisse Umstrukturierungen in der Software, zu haben

• Einen ausgiebigen eigenen Test auf Basis vorhandener Testumgebungen durchführen zu können,

• Akzeptanztest des neuen Stands beim Benutzer durchzuführen,

• Die Software beim Benutzer einzuspielen und deren Nutzung zu erreichen,

• Und das ganze wieder von vorn zu beginnen – weil Software und deren Nutzung lebt.

Dieser eigentlich einfache zyklische Ablauf wird in der Praxis allein deshalb schon komplexer wird, weil bei mehreren Nutzern unterschiedliche Requirements der Änderung anfallen, die organisatorisch nicht unbedingt gemeinsam abgearbeitet werden (können). Das heißt, dieser Zyklus läuft mehrfach gleichzeitig mit etwas unterschiedlichen Softwareständen und muss mit einem zusammenfassenden Zyklus immer wieder auf einen gemeinsamen Stand gebracht werden – zumindest wäre dies angeraten.

Wie sieht das aus den Augen der Nutzer aus?

Der Anwender selbst hat bzw. sieht meist nur einen Fehler, oder ein paar wenige. Dass dazu ein Refactoring notwendig sei, interessiert ihn erst einmal nicht. Wenn er davon hört, ist er meist sogar dagegen. „Wer weiß, was dabei noch alles kaputt geht “ ist dabei ein häufig gehörtes Argument. Das heißt, der Nutzer möchte die Korrekturen auf der Basis seines vorigen Standes.

Außerdem interessieren ihn die Anforderungen anderer nicht: entweder das sind nicht seine Anwendungsgebiete der selben Software, oder er hat dazu eine ganz andere Meinung. Hinzu kommt: Wenn der Nutzer überhaupt keine Änderungswünsche hat, bzw. er die seinigen sowieso nicht berücksichtigt sieht, wozu soll er dann neue Software einspielen. Also ist er gegen DevOps.

Wenn dann aber bei Nutzer X doch ein Fehler auftritt, der im aktuellen Stand schon längst behoben ist oder dessen Behebung basierend auf dem aktuellen Stand viel einfacher ist, dann ist die Doppel- und Mehrfacharbeit wieder da.Denn es ist nicht absehbar, ob der vorhandene Bugfix auf den alten Stand der bei diesem Anwender vorhandenen Nutzung noch passt. Schade, dass sich der Nutzer bislang gegen DevOps gesperrt hat. Wenn dann darüber hinaus zur Bearbeitung eines Fehlers bei Nutzer X gewisse Servicefunktionen notwendig sind, die in den neueren Versionen schon lange drin gewesen wären, dann ist das nicht nur sehr arbeitsaufwändig, sondern auch teuer – besonders für den betroffenen Nutzer.

Ergo: Die Intension für DevOps geht von der Entwicklung aus. Der Nutzer ist häufig

natürlicherweise dagegen und muss vom Sinn dessen wirklich überzeugt werden. Mit

Serviceverträgen, gute Partnerschaft, Vertrauen. Am einfachsten geht dies bei Betriebssystemen. Dort ist der Nutzungseffekt für Updates schnell erklärt: Böse Leute haben leider vorhandene Sicherheitslücken entdeckt, die mit dem Update geschlossen werden.

Mit den Updates werden teils auch neue schicke Features versprochen. Leider kann man die meisten Nutzer mit diesen Argumenten nicht so vordergründig locken, aber etwas wirken sie durchaus.

Wie bedeutet dies für Software in Produktionsanlagen?

Was läuft, läuft. In Produktionsanlagen läuft meist der gleiche Ablauf tagtäglich ab. Und dieser ist getestet und abgenommen. Kein Bedarf für DevOps.Aber stimmt das?

Wenn eine neue Anforderung auftritt dann gilt oben gesagtes genauso. Beispielsweise hat man in einer neue Anlage B, die mit der gleichen Grundsoftware läuft, schon längst ein verbessertes und bewährtes Diagnose- oder Datenlogsystem eingebaut. Das könnte man nun in Anlage A für die anliegende Anforderung gut brauchen. Diese ist aber nicht verfügbar.

Wie bekommt man einen konservativen Kunden, bei dem seiner Meinung alles bestens läuft, dazu, einen neuen Softwarestand einzuspielen? Das wichtigste ist, dass diese Software glaubhaft für den Anwender für seine Anwendung unter seinen Bedingungen gut getestet ist. Dazu steht aber nicht die Anlage selbst zur Verfügung, die muss produzieren. Eine Lösung ist hier der Digitale Zwilling bzw. Digital Twin.

Simulation und Digital Twin

Damit ein digitaler Zwilling umgesetzt werden kann, muss es schon bei bzw. vor der Auslieferung des gewünschten Softwarestandes ein abgestimmtes Verhältnis für einen simulativen Test geben. Der Kunde (Abnehmer) muss dabei unmittelbar integriert sein. Es ist nicht sehr vertrauensbildend, wenn der Lieferant der Software nach seinem Gutdünken eine Simulationsumgebung baut, die der Abnehmer formell akzeptiert (in Verhandlungen mit gut gekleideten Herren (und neuerdings manchmal auch Damen), aber die wirklichen Abnehmer, die Ingenieure die die Anlage kennen, bei Fehlern reagieren müssen mit Überstunden und Geisteskraft, sind nicht dabei.

Das digitale Gegenstück, der Twin, muss also gemeinsam erarbeitet werden. Ideal ist e,s wenn Abnehmer und Lieferant sich über das gleiche Simulationstool und gewisse Herangehensweisen einigen. Die Digital-Twin-Simulation soll eigentlich vom Abnehmer entwickelt werden, in Zusammenarbeit mit dem Lieferant, der möglicherweise aus anderen Anlageneinsätzen wichtige Erfahrungen mitbringt, diese aber dann erklärenderweise in Verständigung einbringt.

Gibt es eine abgestimmte Simulationsumgebung für die Software, dann kann diese zweimal instanziiert werden, beim Lieferanten und Entwickler der Software für die Eigentests, und beim Abnehmer für simulative Akzeptanztests. Das gilt auch für Sonderfalluntersuchungen nur aus Sicht des Anwenders, die nicht bisheriger Vertragsbestandteil ist, aber den Anwender interessiert.

Testgetriebene Entwicklung

Gibt es neue Anforderungen des Abnehmers, dann sollen diese zunächst in die Digital-Twin-Simulation quasi als neue Anforderung oder Anlagenverhalten eingebracht werden. Man sollte zuerst testen, wie sich die bisherige Software mit diesen neuen Anforderungen verhält. Dann kann man sehr viel genauer formulieren, welches neue Verhalten gewünscht ist.

Wie genau die simulative Realisierung des Anlagenverhaltens ist – diesbezüglich gibt es gute Entwicklungen in einigen Simulationstools. Das ist deren Herausforderung.

Die neue Software ist da

Gibt es einen neuen Softwarestand mit der Bitte, diesen auch in die Anlagennutzung zu bringen, dann kann sich der Abnehmer mit nicht zu großen Aufwand simulativ selbst ein Bild von dessen Funktionsfähigkeit oder von dem Nutzen von Erweiterungen machen. Das sollte weniger kosten als der mögliche Ärger bei noch nicht vorhergesehenen Problemen, die aber statistisch kommen.

Schließlich muss alles mit Kosten-Nutzen-Analyse belegt werden. Nach dem selbst ausgeführten Simulationstest könnte die Bereitschaft, die Software einzuspielen und in einem Nachtschicht-Testlauf zur Akzeptanz zu bringen, sehr viel höher sein. Wenn diese Vorgehensweise schon mehrfach ausgeübt wurde und die Praxis bewährt ist, dann gibt es nur noch das Problem des Einschleichens der Routine, weil beim 25-sten mal nicht mehr ausgiebig genug getestet wurde und dann passiert es. Doch das ist ein anderes Problem, DevOps ist dann schon geschafft.

ISO 29119 und der agile Ansatz: Geht das zusammen?