Wer einen PC benutzt, ein Handy oder ähnliche Alltagselektronik, ist daran gewöhnt: in mehr oder minder langen Abständen werden online Updates geliefert. Was in diesem Bereich effizient geschieht, bietet sich auch für den automobilen Bereich an. Und warum sollte nicht ein Autofahrer, der Probleme mit seiner Software hat, das Update/Upgrade per Funk oder übers Internet erhalten? Allerdings müsste man die Steuerungssoftware für die Fahrzeugelektronik schneller aktualisieren können. Die letzte Diskussion mit den Abgaswerten von Dieselfahrzeugen hat die Notwendigkeit deutlich gezeigt, hier kurzfristiger und unkomplizierter Updates/Upgrades liefern zu müssen. Abhilfe schafft da nur Continuous Integration (CI).

Continuous Integration: Updates können auch für den automobilen Bereich per Funk oder übers Internet erfolgen.

Updates können auch für den automobilen Bereich per Funk oder übers Internet erfolgen. Dr. Barbara Stumpp

CI oder permanente Integration ist eine Methodik in der Software-Entwicklung, bei der häufig neue Software-Sequenzen in die Basissoftware integriert werden. Jede Integration verlangt, Tests um Fehler möglichst schnell zu erkennen. Das verringert Integrationsprobleme, und komplexe Software lässt sich so schneller erweitern.

Sollen aber zum Beispiel Motorfunktionen optimiert werden, erhält der Applikateur erst nach mehreren Wochen die erweiterte Software zum Testen. Im Bereich Consumer-Elektronik und dazugehöriger Software geht dies wesentlich schneller; die neue Funktionalität steht früher zu Tests bereit und der Einlaster erhält regelmäßig sein Update.

Das Problem klassischer Lösungen

Außer dieser Verzögerung generiert die normale/klassische Integration ein weiteres Problem: die Verantwortlichen warten normalerweise bis sich einiges angesammelt hat. Dann gilt es, viele neue Funktionen einzubauen und entsprechend zu testen. Die Funktionsentwickler und Applikateure bekommen ihre Software zu ihren neuen Funktionen oft erst Wochen später. Deshalb können sie die neuen Funktionen nicht zeitnah testen und der Fokus geht verloren.  So hinkt alles dem Bedarf hinterher. Nur wünschen sich die Integrationskunden regelmäßige Sonderstände.

Continuous Integration: Bisher: Bei der 'normalen' Integration wartet man normalerweise bis sich einiges angesammelt hat. Dann müssen viele neue Funktionen eingebaut und entsprechend getestet werden.

Bisher: Bei der „normalen“ Integration wartet man normalerweise bis sich einiges angesammelt hat. Dann müssen viele neue Funktionen eingebaut und entsprechend getestet werden. Dr. Barbara Stumpp

Continuous Integration

Bei der Continuous Integration dagegen sammelt sich weniger an, in der Regel nur ein bis drei neue Funktionen. Das verlangt weniger Testarbeit, denn bei weniger neuen Funktionen findet man die Fehler einfacher und schneller.  So wäre es möglich, praktisch jeden Tag einen Sonderstand auszuliefern. Damit erreicht man die erste Stufe zu CI, den Nightly Build.

Um höchste Effizienz zu bieten, arbeiten die Teams IAV daran, alles zu automatisieren. Andre Larberg, Team Manager Software and Algorithms in der Business Area Powertrain Mechatronics Diesel bei IAV, kennt die Lösung: „Jeder Schritt einer solchen Update-Kette soll automatisch ablaufen. Dazu schreibt man eine Software, die diese Updates und passende Simulationsumgebungen für Testzwecke automatisch generiert, um so den steigenden Bedarf an Software-Updates bedienen zu können.“ Und das ist kein Wunschtraum, es funktioniert! Was noch fehlt, ist die fächendeckende Anwendung. Der Vorteil: Hat man eine Update-Idee, wäre diese dann zeitnah zu testen, was Qualität und Komfort für den Entwickler erhöht.

Bei der Continuous Integration dagegen sammeln sich meist nur ein bis drei neue Funktionen an. Das verlangt weniger Testarbeit und die Updates gelangen öfter und schneller ins Auto.

Bei der Continuous Integration dagegen sammeln sich meist nur ein bis drei neue Funktionen an. Das verlangt weniger Testarbeit und die Updates gelangen öfter und schneller ins Auto. Dr. Barbara Stumpp

Zeitnah umsetzen

In Zukunft könnte es dann folgendermaßen ablaufen: Ein Entwickler stellt am Vormittag fest, dass er gerne eine kleine Änderung in einem Modul umgesetzt haben möchte und lastet diese entsprechend vollständig ein. Bei IAV sitzt ein kleines Dev-Ops-Team und setzt diesen Änderungswunsch zeitnah am Nachmittag um. Die Softwarefabrik erkennt ein Update selbstständig, der Sonderstand wird über Nacht automatisiert gebaut, validiert und abgelegt. Der Ingenieur lädt am nächsten Morgen seine neue Software herunter, probiert jetzt zeitnah seine Änderung aus und baut dies in das System ein.

Lesen Sie auf der nächsten Seite, was Entwickler von Lego lernen können.

Seite 1 von 212