Kann man Cyber-Physical Systems/Smart Products agil entwickeln? Und wenn ja, wie?

Cyber Physical Systems (CPS), Internet of Things (IoT), Smart Products, die Namen sind unterschiedlich, die Charakteristik gleich: In allen verbinden sich die physische und die digitale Welt. Allerdings fallen diese Kombinationen oft in die „hier wächst zusammen, was zuerst nicht so recht zusammenpasst“ – Kategorie. Das liegt nicht nur daran, wie verschiedenartig die beteiligten Ingenieursdisziplinen und ihre Ansätze sind. Der eklatanteste Unterschied zwischen Soft- und Hardware liegt in der Zeitspanne, die es dauert, um auf Veränderungen zu reagieren.
Agiles Vorgehen kann hier helfen. Theoretisch. Praktisch ist, wie eine Software-Firma zu denken, wenn es (auch) um Hardware geht, eine Herausforderung. In diesem Beitrag gebe ich Anregungen, wie man damit umgehen kann.  

Die Ausgangslage: Verschiedene Welten treffen aufeinander

In der guten alten Zeit der Produktentwicklung gab es die reine Produktentwicklung, also physische Güter, die man anfassen, durch die Gegend tragen oder zusammenschrauben konnte. Zugehörige Ingenieursdisziplinen heißen Sensorik oder Mechanik. Dann kam Steuerungssoftware dazu, nützliche, speicherprogrammierbare Steuerungen in Assembler und Rasberry Pis. Inzwischen sind Anwendungsentwicklungen in Hochsprachen wie Java oder C++ die dritte Komponente im Bunde.

Und damit wird es kompliziert.

Denn jetzt haben wir klassische Hardware- und „reine“ Softwareentwicklung, die zusammenspielen müssen. Dabei könnten diese Bereiche unterschiedlicher nicht sein. Die Hardwareentwicklung setzt traditionell auf dokumentengetriebene Entwicklungsmodelle wie das Wasserfall- oder das V-Modell. Dabei sind die Phasen fest definiert und werden sequenziell durchlaufen. Fertig ist das Produkt erst am Ende der letzten Schleife, das ist dann auch der erste Zeitpunkt, zu dem Kunden oder Benutzer das Produkt ausprobieren und Feedback geben können.

Agile Methoden wie Scrum, bisher vorwiegend in der Softwareentwicklung verbreitet, arbeiten mit einem iterativen Ansatz, bei dem schrittweise neue Features und Funktionalitäten ausgeliefert werden. Denn das ermöglicht, früh und regelmäßig Feedback zu bekommen. Allerdings ist es dazu erforderlich, am Ende jeder Iteration fertige („done“) Inkremente zu haben, die dann gemeinsam inspiziert werden können. Scrum versteht unter einem Inkrement ein potenziell auslieferbares Produktstück, das einen Schritt in Richtung des Produktziels darstellt. Es bildet die Basis für Inspect & Adapt, die Bezeichnung für das ständige Prüfen und bei Bedarf anpassen. Was die Wahrscheinlichkeit deutlich erhöht, dass das, was produziert wird, auch das ist, was die Kunden produziert sehen wollen.

Das ist ein Vorteil, der über den wirtschaftlichen Erfolg des Produktes entscheidet. Zumindest, solange wir als Axiom akzeptieren, dass Kunden die Produkte, die sie nicht (mehr) haben wollen, auch nicht kaufen würden und es sich daher lohnt, das Richtige zu produzieren.

Damit stellt sich die Frage, ob es möglich ist, bei der Entwicklung von Cyber-Physical Systems die Vorteile agiler Produktentwicklung zu nutzen. Die gute Nachricht zuerst: Ja, das geht. Die nicht ganz so gute: Dabei tauchen zusätzliche Herausforderungen auf. Diese Herausforderungen bestehen sowohl auf organisatorischer als auch auf operativer Ebene, sie erfordern wichtige Überlegungen wie:

• Wie sieht eine effiziente Zusammenarbeit der verschiedenen Disziplinen aus?
• Wie erzeuge ich ein gemeinsames Verständnis darüber, was es bedeutet, wenn ein Inkrement „fertig“ (done) ist? Zumal „done“ in der Einzeldisziplin nicht ausreicht. Inkremente müssen vollständig entwickelt, aus allen Bereichen integriert und in der Zielumgebung validiert sein, damit ein leistungsfähiges Produkt entsteht.
• Wie erstelle ich automatisierte Tests, wenn die Hardware womöglich nicht oder noch nicht verfügbar ist? Oder sehr teuer? Oder aufwändig herzustellen?

Da wir oft bei Kunden im CPS-Umfeld unterwegs sind, haben wir diese Überlegungen schon häufig angestellt und Wege gefunden, mit den Herausforderungen umzugehen. Hier sind einige Lösungsvorschläge.

Elementarer Anfang: Zusammenarbeit

Wenn ein integriertes „done“ Inkrement entstehen soll, müssen die unterschiedlichen Bereiche eng zusammenarbeiten, so weit, so verständlich.

Nur werden zur Entwicklung von Hardware, Steuerungssoftware und Anwendungsentwicklung jeweils Menschen mit unterschiedlichen Fähigkeiten und Kompetenzen gebraucht. Deshalb bilden viele Firmen für jeden Bereich eigene Teams. Diese Teams sind nicht interdisziplinär (engl. cross-functional), sie sind spezialisiert. Scrum fordert jedoch explizit interdisziplinäre Teams, deren Mitglieder über alle Fähigkeiten verfügen, „um in jedem Sprint Wert zu schaffen.“ [1, p. 5] Unterschiedliche Fähigkeiten und Kompetenzen in einem Team zu bündeln soll die Zusammenarbeit verbessern und die Produktivität steigern. Spezialisierte Teams arbeiten meist isoliert von anderen Teams. Das ist das glatte Gegenteil von dem, was agiles Vorgehen verlangt.

Wie kann ich die Zusammenarbeit in CPS-Teams verbessern? Ideal sind gemischte, also interdisziplinäre Teams. So oder so ist es äußerst wichtig, die Kommunikation zwischen den Teams zu fördern. Ein regelmäßiger Austausch zwischen den Teams, idealerweise auf täglicher Basis und vor Ort, kann dabei helfen, Integrationsprobleme zwischen den einzelnen Bereichen zu vermeiden oder zumindest zu verringern. Gemeinsame Iterations-Events für spezialisierte Teams sind nützlich, um das Verständnis des Gesamtszenarios zu fördern und Hürden und Hindernisse zwischen den Teams abzubauen.

Der Werkzeugkasten der Teamzusammenarbeit enthält weitere Techniken und Ansätze, die ich zur Nachahmung ausdrücklich empfehle: Beispielsweise Swarming, bei dem sich mehrere Teammitglieder zusammenschließen, um gemeinsam an einer wichtigen Sache zu arbeiten. Das ist auch teamübergreifend ein guter Ansatz. Paarprogrammierung und Communities of Practice ermöglichen einen Know-how-Transfer über Teamgrenzen hinweg. Das verhindert Wissenssilos und fördert den Teamgedanken. Probiert es aus!

Fertig ist, wenn alle Bereiche fertig sind

Der – etwas komplexe- Begriff „integrated done Inkrement“ bedeutet, dass die Inkremente der Teams aus den verschiedenen Bereichen in einem gemeinsamen Inkrement zusammengeführt werden. „Done“ ist es also erst, wenn diese Integration erfolgreich abgelaufen ist. Es nützt nichts, wenn beispielsweise ein Team der Anwendungsentwicklung in einem Sprint Software erstellt, die alle Softwaretests meistert, dann aber im Zusammenspiel mit der Hardware plötzlich Fehler produziert. Gewissheit über die Qualität der Artefakte bringt nur der Test neuer Software-Features auf der Ziel-Hardware.

Gleiches gilt für Hardware oder Steuerungssoftware, die isoliert erstellt und getestet wurde. Je häufiger und frühzeitiger Ihr auf der Ziel-Hardware testet, desto weniger Probleme gibt es bei der späteren Integration. Es gibt einen Satz, den jedes agile Team im CPS-Umfeld beherzigen sollte: „Es ist Done, wenn es auf der Maschine deployt ist“. Am besten nehmt ihr diesen Satz auf in eure Definition of Done.

Was ist eine Definition of Done und was bringt sie?

Das agile Framework Scrum versteht unter einer „Definition of Done (DoD)“, eine klar definierte Liste von Kriterien, die erfüllt sein müssen, damit ein Produkt-Inkrement "fertig" ist.

Der Sinn besteht darin, einen objektiv messbaren Qualitätsstandard zu etablieren, an den sich alle an der Produktentwicklung beteiligten Teams halten müssen. Nur Arbeitsergebnisse (z.B. neue Features, Hardwaremodule usw.), die der Definition of Done entsprechen, dürfen als Teil des Inkrements betrachtet werden. Das soll sicherstellen, dass ein verwendbares Inkrement erstellt wird, das einen Mehrwert erzielen kann [1, p. 13]. Im Sinne der DoD müssen die Soft- und die Hardware den festgelegten Qualitätsanforderungen genügen und integriert auf der Hardware fehlerfrei laufen.

Damit reicht es nicht, wenn sich einzelne Bereiche eine individuelle DoD geben, benötigt wird eine gemeinsame DoD als bereichsübergreifender gemeinsamer (Mindest-)Standard. „Mindest“ bedeutet, dass sich jeder Bereich darauf verlassen kann, dass die anderen diesen Standard auf jeden Fall einhalten. Wenn sie ihn erweitern, ist das fein, absenken oder reduzieren dürfen sie ihn nicht. Fertig ist das Inkrement dann, wenn alle Teile integriert sind. Dieser Standard wird dabei nicht nur am Ende jeder Iteration erreicht, sondern auf täglicher Basis, durch konsequente Integration, Testautomatisierung und Zusammenarbeit.

Testautomatisierung: Wir fangen mal mit der Software an…

Software manuell zu Testen ist normalerweise keine gute Idee, dafür ist es zu zeitaufwändig, verursacht zu hohe Kosten und birgt darüber hinaus das erhöhte Risiko, Fehler zu übersehen. Tests zu automatisieren ist eine effiziente Alternative.

Entsprechende Software-Tools testen automatisch und wiederholt, wobei die tatsächlichen Ergebnisse systematisch mit den erwarteten verglichen werden. Das bringt mehrere Vorteile: Fehler werden früher im Entwicklungsprozess erkannt, Tests können beliebig oft mit gleichbleibender Qualität wiederholt werden und der gesamte Entwicklungszyklus verkürzt sich. Automatisierte Tests senken die Total Cost of Ownership von IT-Produkten und ermöglichen eine schnellere Time to Market.

Automatisierte Tests sind auch Grundvoraussetzung für weitere Prinzipien des professionellen Software Engineerings, z.B. CI/CD-Pipelines. Dabei werden Code-Änderungen automatisch zusammengeführt in ein gemeinsames Repository mit anschließender Build- und Test-Phase (Continuous Integration (CI)).

Continuous Delivery/Deployment (CD)) beschreibt den Grundsatz, Softwareänderungen in Produktionsumgebungen automatisiert bereit zu stellen. Das sorgt für eine stabilere, effizientere und agilere Produktentwicklungsumgebung. Automatisierte Prozesse beschleunigen die Auslieferung neuer Features. Daraus resultiert ein deutlicher Wettbewerbsvorteil, weil es möglich ist, auf Marktanforderungen schnell(er) zu reagieren.

Was unterscheidet Testautomatisierung in klassischen Softwareentwicklungsprojekten von der Testautomatisierung in CPS-Projekten?

In CPS-Projekten verlassen wir die reine Software-Welt, jetzt wird zusätzlich auch Hardware entwickelt. Kaum überraschend, dass es dann nicht mehr ausreicht, Hard- und Software isoliert voneinander zu testen. Erst im Zusammenspiel wird klar, ob sie zusammen die gewünschte Funktionalität liefern können. Es ist daher elementarer Bestandteil des Testens, zu prüfen, ob die Integration wie gewünscht läuft.

Wie hilft mir Testautomatisierung in CPS?

In der Hardware-Entwicklung sind, aus unterschiedlichen Gründen, manuelle Tests häufig. Testautomatisierung kann hier helfen, die gesamten oder einzelnen Teile der Hardware mit vorgegebenen Signalen anzusteuern oder virtuell zu simulieren und dadurch reproduzierbare Tests zu ermöglichen.

Eine Simulationstechnik, bei der reale Hardware mit virtuellen Komponenten in einer Testumgebung verbunden wird, ist Hardware in the Loop (HIL). Hier wird ein zu testender Hardware-Bestandteil (z.B. ein Steuergerät) mit einem Softwaresimulator verbunden. Der Softwaresimulator erzeugt in Echtzeit realistische Signale, die das tatsächliche Betriebsumfeld nachbilden und als Eingabe dienen. Das Testobjekt erkennt keinen Unterschied zwischen dem Simulator und einem echten anderen Hardware-Bestanteil, seine Reaktion ist in beiden Fällen gleich. Das ermöglicht es, die Reaktionen auf die Eingabe zu messen und auszuwerten, obwohl das reale Hardwareteil gar nicht beteiligt ist. Anders gesagt ermöglicht Hardware in the Loop, unter realistischen Bedingungen zu testen, ohne die gesamte Hardware vollständig physisch aufzubauen. Das reduziert die Entwicklungszeit und die Kosten erheblich.

Bei der Entwicklung von CPS lässt es sich manchmal nicht vermeiden, dass die Hardware für Tests (temporär) nicht zur Verfügung steht. Vor allem wenn die Hardware sehr teuer ist und deswegen nur eine oder wenige Testmaschinen existieren, können Wartungs- und Refaktorisierungsarbeiten an der Hardware dafür sorgen, dass es gerade nicht möglich ist, physikalische Komponenten für Softwaretests zu bekommen.

In diesen Umgebungen schlägt die Stunde der digitalen Zwillinge (engl. Digital Twins). Das sind virtuelle Nachbildungen von physischen Objekten, Prozessen oder Systemen. Sie simulieren das Verhalten des physischen Systems und können für automatisierte Softwaretests verwendet werden. Digitale Zwillinge empfehlen sich besonders, wenn die realen Tests hohe Kosten verursachen oder wenn Entscheidungen während der Entwicklung mit Prototypen teuer, sehr langsam oder sehr gefährlich sind. So werden im Automobilbau digitale Zwillinge eingesetzt, um Crashtests zu simulieren. Dadurch kann man bspw. bei kleineren Änderungen an der Karosserie darauf verzichten, einen teuren Prototyp erst physisch zu bauen und umgehend im Wortsinn an die Wand zu fahren. Physische Prozesse können vorhergesagt, optimiert und überwacht werden, ohne dabei direkt in die reale Umgebung eingreifen zu müssen.

Ein Disclaimer zum Abschluss des Themas Testen: Diese Techniken ersetzen nicht das integrierte Testen von Hard- und Software auf der Zielplattform! Das gilt für alle Testgranularitäten, von Komponententests bis hin zu Systemtests.

Man kann Cyber-Physical Systems agil entwickeln

Ja, agile Entwicklung für CPS ist möglich, auch wenn es dabei einige Herausforderungen gibt. Hier nochmal die entscheidenden Punkte in der Zusammenfassung:

• Um integrierte Inkremente zu erstellen, müssen die verschiedenen Disziplinen eng zusammenarbeiten. Interdisziplinäre Teams, regelmäßiger Austausch, gemeinsame Events, Swarming und Paarprogrammierung sind dafür nützlich.
• Ein einheitlicher Qualitätsstandard, der für alle Teams gilt, ist essenziell. "Es ist Done, wenn es auf der Maschine deployt ist" sollte als Grundsatz gelten. Eine teamübergreifende Mindest-Definition of Done hilft, integrierte Inkremente sicherzustellen. Jedes Team kann diese Mindest-DoD erweitern und verschärfen.
• In Cyber-Physical Systems ermöglichen automatisierte Testverfahren, die Total Cost of Ownership signifikant zu reduzieren. Sie bilden die Grundlage dafür, neue Funktionen kontinuierlich bereit zu stellen, in hoher Qualität. Benötigt werden sowohl isolierte als auch integrierte Tests in allen Granularitäten. Hardware-in-the-Loop-Simulationen und digitale Zwillinge helfen beim isolierten Testen, ersetzen jedoch nicht das Testen auf der Zielplattform.

Kurz gesagt: Agile CPS-Entwicklung erfordert konsequente Integration, Testautomatisierung und disziplinübergreifende Zusammenarbeit. Und sie lohnt sich.

 

[1]	Ken Schwaber, Jeff Sutherland: Der Scrum Guide