Man hängt an der Serviceleitung, hofft auf Hilfe und trifft auf abweisendes Verhalten. Neulich konnte ich mit einem sehr erfahrenen Fahrzeugmechatroniker sprechen. Seine Aussage war ernüchternd: "Es ist ein Desaster. Kaum jemand weiß noch genau, was bei einem bestimmten Problem zu tun ist."
Ein Kunde kommt mit einem Problem in die Werkstatt. Der moderne Ansatz besteht zunächst darin, eine On-Board-Diagnose durchzuführen. Dafür wird ein elektronisches Gerät von außen an das Auto angeschlossen. Es verbindet sich über eine Datenverbindung mit dem Fahrzeug und kann Informationen anzeigen, die dem Mechatroniker bei der Suche nach dem Fehler helfen.
Hinter diesem System steckt eine eigene Norm. Außerdem schreibt der Gesetzgeber seit Jahrzehnten vor, dass neu zugelassene Autos eine On-Board-Diagnose unterstützen müssen. Bei der Hauptuntersuchung können damit beispielsweise abgasrelevante Daten überprüft werden. Auch der Fahrzeugmechatroniker kann diese Informationen nutzen, um mögliche Defekte einzugrenzen.
Schwierig wird es, wenn die Ursache des Problems selbst in der Software liegt. Dann kann es passieren, dass ein Fehler angezeigt wird, obwohl die eigentliche Ursache ganz woanders liegt. Der Kunde freut sich verständlicherweise nicht über eine hohe Rechnung, wenn ein schwer erreichbares und teures Bauteil ausgetauscht wird und die Diagnose danach immer noch denselben Fehler meldet.
In den Werkstätten sitzen die Mitarbeiter deshalb nicht selten am Telefon und versuchen, über die Servicehotline des Herstellers mehr herauszufinden. Es ist schwer, jemanden zu finden, der ein kompliziertes Problem wirklich versteht und einen Lösungsansatz kennt. Wobei selbst das noch geht.
Leider kommt es auch vor, dass aufgrund eines Softwarefehlers niemand die eigentliche Ursache des Problems verstanden hat und deshalb auch niemand einen wirklichen Lösungsansatz anbieten kann. Stattdessen werden Vorgehensweisen empfohlen, die das Problem nicht lösen, sondern das System lediglich so austricksen, dass der Fehler nicht mehr angezeigt wird.
Auch Menschen, die überhaupt keinen Bezug zu Technik haben, können sich diese Situation gut vorstellen. Denn eigentlich geht es um ein Problem unserer Zeit: Unsere technischen Systeme werden immer komplexer, gleichzeitig wird es immer schwieriger, jemanden zu finden, der das Gesamtsystem versteht und gezielt helfen kann.
Speziell die Autoindustrie hat aus verschiedenen Gründen Entwicklungsprozesse etabliert, die Mitarbeitern möglichst klar definierte Aufgaben zuweisen. Mitarbeiter sollen austauschbar sein, Arbeiten sollen an externe Unternehmen vergeben werden können und Zulieferer müssen klar definierte Standards einhalten. So soll die Entwicklung möglichst gut planbar und skalierbar werden.
Daran ist zunächst nichts falsch. Klare Prozesse, standardisierte Schnittstellen und eine Aufteilung der Arbeit sind bei der Entwicklung komplexer Systeme notwendig. Aber irgendwann kippt das Ganze. Dann wird aus sinnvoller Arbeitsteilung eine Zerstückelung, bei der niemand mehr den Überblick über das Gesamtsystem hat.
Zusätzlich entsteht ein erhebliches Sparpotenzial. Wenn Arbeit in klar abgegrenzte Arbeitspakete aufgeteilt wird, können diese ausgeschrieben und verschiedene Anbieter gegeneinander antreten. Der Konkurrenzkampf beginnt, und damit auch der Preiskampf.
Über Jahre hinweg kann sich so eine Kultur entwickeln, in der Softwareentwicklung immer stärker in einzelne Aufgaben und Arbeitspakete zerlegt wird. Jeder bekommt seinen kleinen Bereich und optimiert diesen. Aus motivierten und stolzen Mitarbeitern werden dabei Menschen, die nur noch ihren abgegrenzten Teil der Aufgabe erfüllen und denen die Chance genommen wird, das Gesamtsystem zu verstehen.
Und dann wird aus dieser Situation heraus eine "Softwareoffensive" ausgerufen, weil man das enorme Innovationspotenzial von Software erkannt hat.
So funktioniert es nicht!
Da schustert der Dienstleister des Vertrauens ein Skript für die Softwareintegration eines Steuergeräts für den Antriebsstrang zusammen. Die Entwicklung läuft nach AUTOSAR auf einem passenden Betriebssystem. Daran arbeiten zum Teil eigene Mitarbeiter, aber auch verschiedene Teams von Dienstleistern. Die Hardware und die dem Standard entsprechende Basissoftware kommen von einem Zulieferer.
Die Entwicklung sogenannter physikalischer Modelle, also Softwareteile, die das Verhalten noch nicht entwickelter Komponenten des Antriebsstrangs mathematisch nachbilden, wird an spezialisierte Firmen vergeben. Standardisierte Schnittstellen ermöglichen es, viele Softwarekomponenten unabhängig voneinander zu entwickeln und später zu integrieren. Dadurch kann die Softwareentwicklung parallel zur Entwicklung von Komponenten wie Hydrauliksystemen oder Getriebekomponenten vorangetrieben werden.
Bis die ersten sogenannten Hardware-in-the-Loop-Tests mit Prototypen der Komponenten aufgebaut werden, sind bereits mehrere Softwareentwicklungszyklen durchlaufen und erste lauffähige Versionen vorhanden. Mit Tests im fertigen Produkt werden schließlich Zeitpunkte festgelegt, zu denen die Produkte in die Serienfertigung gehen sollen.
Doch zu diesem Zeitpunkt ist oft noch nicht alles fertig. Weitere Funktionen sollen eingebaut und Fehler behoben werden. Die Serienbetreuung beginnt.
Einzelne Verträge mit Dienstleistern laufen aus, der Preiskampf beginnt erneut und siehe da: Ein anderer Dienstleister übernimmt die Softwareintegration.
Ein Modellentwickler mit über Jahre gewachsenem Spezialwissen geht in den Ruhestand und versucht, sein Wissen an seinen Nachfolger zu übergeben. Der Zulieferer für Basissoftware und Steuergerät möchte die Umstrukturierung nutzen, um Fehlerkorrekturen in die Software einzupflegen. Die Softwarekomponententests werden zur Kostensenkung in ein Land mit geringeren Lohnkosten ausgelagert.
Der neue für die Integration zuständige Dienstleister hat Schwierigkeiten, das vorhandene Integrationsskript zu verstehen. Die Übergabe vom bisherigen Dienstleister war kurz und schmerzlos.
Mit der neuen Basissoftware können bei der Integration bestimmte Softwareteile nicht aufgelöst werden. Der Projektkoordinator stellt fest, dass Daten des Zulieferers nicht vollständig in die interne Versionsverwaltung übernommen wurden.
Kein Problem. Jetzt läuft die Integration zumindest wieder durch.
Aber passt das auch zu den verschiedenen Produktvarianten, die durch Präprozessor-Makros im Modellcode hinterlegt sind? Kann das mal jemand herausfinden? Wie werden diese Makros über das Integrationsskript festgelegt?
Ach so, der damals zuständige Dienstleister spricht nur gegen Bezahlung mit uns und das Budget gibt das nicht her.
Bitte durch Reverse Engineering herausfinden.
Oh je. Ein anderer neuer Dienstleister, der für die Umsetzung der Modelle in Programmcode zuständig ist, hat durch einen unerfahrenen Mitarbeiter den Softwarestand beschädigt. Sein Auftrag war es eigentlich nur, Warnungen in der Datenbibliothek zu beheben. Was er auch gemacht hat.
Die Applikateure melden sich von der Teststrecke. Mit dem aktuellen Integrationsstand funktioniert etwas nicht. Sie gehen wieder eine Version zurück. Bitte ASAP beheben!
Das Problem an diesem Beispiel ist nicht, dass einer der Beteiligten seine Aufgabe grundsätzlich falsch erfüllt. Jeder arbeitet innerhalb seines Verantwortungsbereichs. Genau hier liegt das Problem. Das Wissen, die Verantwortung und die Entscheidungsfähigkeit verteilen sich immer weiter auf verschiedene Unternehmen, Teams und Spezialisten. Am Ende funktioniert vielleicht jeder einzelne Prozessschritt, aber niemand kann mehr sicher sagen, wie das Gesamtsystem eigentlich funktioniert.
Das sogenannte Look-and-Feel ist für Kunden besonders wichtig. Leistungsstarke Zentralrechner mit dem Betriebssystem Android Automotive und einem eigenen In-Car-App-Store sind heute das Erste, was dem Kunden auf großen Bildschirmen ins Auge fällt. Navigation, Unterhaltung, Fahrzeugdaten, Wettervorhersage, Social Media und Telefonie sind integriert und leicht zugänglich.
Das ist die sichtbare Software. Die Software, die man beim Verkaufsgespräch zeigen kann. Sie lässt sich auf großen Bildschirmen präsentieren und mit bunten Bildern und schönen Animationen verkaufen.
Dahinter steckt allerdings eine ganz andere Welt.
In einem modernen Fahrzeug arbeiten zahlreiche Steuergeräte und Softwarekomponenten zusammen. Ein Teil dieser Software übernimmt zeitkritische oder sicherheitsrelevante Funktionen. Software im Antriebsstrang kann beispielsweise Funktionen enthalten, für die Anforderungen an die funktionale Sicherheit gelten. Je nach konkreter Sicherheitsanalyse können dafür zusätzliche Maßnahmen wie Überwachung, Diagnose oder Redundanz erforderlich sein.
Auch beim automatisierten und autonomen Fahren steigen die Anforderungen an die Systemarchitektur. Zahlreiche Systeme müssen miteinander kommunizieren und zuverlässig Daten austauschen. Berechnungen können auf leistungsfähigen Zentralrechnern zusammenlaufen, während andere Funktionen weiterhin auf spezialisierten Steuergeräten ausgeführt werden.
Es gibt also eine große Menge zeitkritischer und sicherheitsrelevanter Software, von der ein Kunde beim Verkaufsgespräch kaum etwas sieht oder mitbekommt.
Das Erste, worüber sich ein Kunde dagegen ärgert, ist das, was ihm über das Infotainment-System präsentiert wird.
Mit der Rechnung des ersten Kundendienstes beginnt er, weitere Dinge zu hinterfragen. Qualitätsmängel werden nach und nach sichtbar und unzureichend beantwortete Fragen an die Servicekraft lassen den ersten Frust aufkommen.
Von der versprochenen Innovation ist dann wenig zu spüren. Stattdessen steht plötzlich ein kostenoptimiertes Allerweltsfahrzeug vor der Tür.
Wie konnte das nur passieren?
Es muss wieder mehr Wertschätzung für Mitarbeiter geben. Und zwar für die eigenen Mitarbeiter ebenso wie für die Mitarbeiter von Zulieferern und Dienstleistern.
Gerade bei komplexer Softwareentwicklung ist es problematisch, wenn Mitarbeiter weder Verantwortung für größere Zusammenhänge übernehmen können noch die Möglichkeit bekommen, das jeweilige Gesamtsystem, an dem sie arbeiten, zu verstehen.
Wie kann man über Jahre hinweg so viel Potenzial verlieren und dabei Unsummen an Geld ausgeben? Gut, dass durch unzählige Sparmaßnahmen immer weiter optimiert wird und dabei das Wichtigste auf der Strecke bleibt.
Man hat doch erkannt, dass gerade in der Softwareentwicklung und insbesondere in der Entwicklung eingebetteter Systeme ein riesiges Innovationspotenzial liegt. Doch was passiert? Man versucht, dieses Potenzial mit immer neuen Organisations- und Prozessansätzen zu erschließen, während gleichzeitig Mitarbeiter auf immer kleinere Aufgabenbereiche verteilt werden.
Auf der anderen Seite entstehen Wissensmonopole, weil einzelne Experten oder Dienstleister Wissen besitzen, das innerhalb der Organisation nur schwer verfügbar ist.
Auch künstliche Intelligenz wird dieses Problem nicht einfach lösen können. Sie kann bei der Entwicklung unterstützen, aber fehlendes Systemverständnis nicht automatisch ersetzen. Sie kann auch keine Unternehmenskultur reparieren, in der Wissen in einzelnen Expertensilos gefangen ist.
Eine Kurskorrektur besteht deshalb darin, weniger auf reines Prozessdenken und mehr auf Architekturdenken zu setzen.
Dabei geht es nicht darum, Prozesse abzuschaffen. Prozesse sind notwendig, um komplexe Entwicklungen planbar und beherrschbar zu machen. Es geht darum, Prozesse wieder als Werkzeug zu verstehen und nicht als Motivation zu nutzen, durch neue Silos Kosten zu senken.
Jeder einzelne Mitarbeiter muss die Chance bekommen, aus seinem Expertensilo auszubrechen und das Gesamtsystem zu verstehen. Ein Entwickler muss nicht jedes Detail des Fahrzeugs kennen. Aber er sollte verstehen können, welche Rolle seine Software im Gesamtsystem spielt, von welchen Komponenten sie abhängt und welche Auswirkungen Änderungen auf andere Teile des Systems haben können.
Das Erlernen von Architekturdenken in der Embedded-Softwareentwicklung ist ein Schlüssel zu mehr Innovationskraft. Daraus kann eine bessere Entwicklungskultur entstehen, in der Wissen geteilt wird und neue Mitarbeiter von erfahrenen Kollegen an Entwicklungsbereiche mit echtem Innovationspotenzial herangeführt werden.
Dafür braucht es keine Pseudoschulungen mit nutzlosen Zertifikaten. Es braucht Menschen, die bereit sind, ihr Wissen weiterzugeben, Verantwortung zu übernehmen und anderen zu zeigen, wie aus einzelnen Softwarekomponenten ein funktionierendes Gesamtsystem entsteht.
Vielleicht könnte diese Kurskorrektur tatsächlich die Softwareoffensive sein, die die Entwicklung eingebetteter Software in Deutschland braucht: Nicht mehr Prozesse, sondern mehr Menschen, die verstehen, was sie mitentwickeln und wie das Gesamtsystem funktioniert.
Für den Start sind Sie hier genau richtig. Die Inhalte dieser Seite führen auf motivierende Weise an genau dieses Architekturdenken heran. Es wird gezeigt, wie man mit objektorientierten Ansätzen Software für eingebettete Systeme unter Windows oder Linux entwirft und entwickelt. Um tiefgreifendes Wissen aufzubauen, wird außerdem gezeigt, wie man eine Basissoftware auf dem blanken Metall entwickelt. Sie ist sicherlich weit von einer klassischen Zertifizierung entfernt, lässt dafür aber keine Frage offen und liefert Antworten auf Fragen zu etablierten Systemen.
Viel Spaß auf lowbat.org — Architekturdenken statt Prozessdenken