Kfz-Industrie will ihre Software endlich in den Griff kriegen

DaimlerChryslers Forschungs- und Technologievorstand Thomas Weber musste jüngst bei seinen Kunden Abbitte leisten und, was die Entwicklung von Kfz-Software betrifft, für die Zukunft Besserung geloben. “In der Vergangenheit ist bei allen, die mit der Elektronik experimentiert haben, der Spieltrieb durchgegangen”, musste er gestehen und hatte dabei nicht nur BMWs vielgescholtenes iDrive-Konzept im Sinn, sondern durchaus auch so manche Entwicklung aus Stuttgart.
Zu kritisieren gibt es dabei außer den nicht immer benutzergerechten Bedienkonzepten vor allem die Zuverlässigkeit. Dabei sind heute stabile und komplexe Software-Systeme für die Automobilindustrie wettbewerbsentscheidend, und die Situation wird sich künftig noch verschärfen. Trotz des schon hohen Anteils an Elektrik und Elektronik in den heutigen Kraftfahrzeugen – zunehmend auch in der Mittel- und Unterklasse – wird nach übereinstimmender Ansicht der Protagonisten in den Entwicklungsabteilungen der großen Autobauer dieser Anteil noch weiter zunehmen.

“Die Bordnetze eines Automobils der Oberklasse gleichen heutzutage dem IT-Netzwerk eines mittelständisches Unternehmens, wo 70 bis 90 Steuer-Rechner mit Bussen verbunden sind, über die ein intensiver Datenaustausch stattfindet”, charakterisiert Dr. Jürgen Bielefeld von BMW die gegenwärtige Lage in der Branche. Das erfordere ein wesentlich tieferes Verständnis der Software-, Kommunikations- und Systemtechnik als es den traditionell “maschinenbau-geprägten” Fahrzeugentwicklern bisher abgefordert worden sei. Nur mit einer durchgängigen Modellierung statt der heute immer noch vorherrschenden eher informellen Vorgehensweise sei aber die heute anstehende Systemkomplexität noch beherrschbar.

Modellbasierte Entwicklung

BMW ist denn auch zusammen mit der Volkswagen AG und Siemens VDO der industrielle Kernpartner des Fraunhofer-Instituts für Software- und Systemtechnik in Dortmund und Berlin (ISST), dessen Abteilung ‘Verlässliche Technische Systeme’ seit Jahren an formalen Methoden für die modellbasierte Software-Entwicklung arbeitet. Die Fraunhofer-Leute bauen dabei auf den drei Modell-Komponenten ‘Entwicklung’, ‘Simulation’ und ‘Test’ auf. Bisher ist allerdings erst die Komponente ‘Entwicklung’ voll praxistauglich, die Verknüpfung dieser Modell-Komponente mit den Modulen ‘Simulation’ und ‘Test’ ist noch Teil der internen Forschungsarbeit des ISST.

Gerade diese Verknüpfung bringe auf mittlere Sicht enorme ökonomische Vorteile, ist Institutschef Professor Herbert Weber überzeugt. Eine rein funktionale Modellbildung allein sei nicht ausreichend. Eine bestimmte Lösung könne beispielsweise nur deshalb nicht funktionsfähig sein, weil nicht genügend Ressourcen bereitgestellt werden könnten. Ein solches Manko werde aber nur durch eine Ressourcen-Simulation aufgedeckt, denn die funktionale Simulation laufe in einem solchen Fall ja fehlerfrei ab. Neben der funktionalen und der Ressourcen-Modellierung ist im Konzept des ISST noch eine Simulations-Modellierung vorgesehen. Aus den Simulationen können dann durch das Festlegen von Beobachtungspunkten die Testdaten und Testabläufe gewonnen werden.

Modellbasierte Softwareentwicklung hilft nicht nur bei der Integration der Entwicklungsschritte und bei der schnelleren Umsetzung in ausführbare Softwaremodule, sondern unterstützt auch die Kommunikation aller Prozessbeteiligten untereinander. Ein derartiges Entwicklungsmodell stellt indes hohe Anforderungen an formales Können und Disziplin bei der Anwendung. Ist diese Bedingung erfüllt und liegen beispielsweise die erstellten Modelle in der Teile-Datenbank in verschiedenen Sichten vor (Entwicklung, Simulation, Test etc.), dann “bilden diese nicht mehr nur eine Entscheidungshilfe bei einer speziellen Aktivität der Entwicklung, sondern stellen das Entwicklungsergebnis selbst dar”,  sagt Dr. Bielefeld.

Automotive Open System Architecture (AUTOSAR)

Modellbasierte Entwicklungsmethoden zielen auf Wiederverwendbarkeit und Qualitätssicherung und induzieren schon deshalb offene Systemarchitekturen. In dem Projekt ‘Automotive Open System Architecture’ (AUTOSAR) entwickelt ein Konsortium der wichtigsten deutschen  Automobilproduzenten und Automobilzulieferer genau solch eine offene Systemarchitektur. “Oftmals sind die technischen Randbedingungen wie CPU-Last, Speicherbedarf oder Kommunikationsvernetzung schon in der Entwurfsphase bekannt”, erläutert Dr. Jürgen Mottok vom Automobilzulieferer Siemens VDO und folgert daraus: “Durch die Erstellung von Modellen für das Gesamtsystem, die einzelnen Hardware-Komponenten und die Software-Module wird ein systematischer methodischer Umgang mit diesen Informationen ermöglicht.”

In einer offenen Systemarchitektur kommunizieren vor allem die Software-Komponenten vor der ‘materiellen’ Entwicklung der Elektronik-Teile über einen virtuellen Funktionsbus miteinander. Erst durch den Einsatz von Konfigurationswerkzeugen, so Mottok weiter, werde unter Berücksichtigung der Modellbeschreibungen entschieden, auf welchem Hardware-Modul eine bestimmte Software-Komponente angeordnet wird, ob also die Kommunikation lokal oder über ein Busprotokoll erfolge.

Genau diese als Partitionierung bezeichnete Vorgehensweise werde durch den AUTOSAR-Prozess unterstützt werden. Die Software-Komponenten nutzen nach Darstellung von Mottok dabei eine standardisierte Schnittstelle, die von der AUTOSAR-Laufzeitumgebung einer jeden Hardware-Komponente bereitgestellt werde. Alle Funktionsdomänen eines Automobils (Fahrwerk, Antrieb, Karosserie/Komfort, Multimedia/Telematik, Mensch-Maschine-Schnittstelle und Sicherheit) werden gleichermaßen in dieser offenen Architektur abgebildet, was nicht zuletzt eine domänen-übergreifende Akzeptanz der Projektziele ermöglicht. 

Durch eine derartige offene Architektur ändert sich auch das Geschäftsmodell der Automobil-Zulieferer. Sind diese bis dato für alle Schichten der Software-Architektur zuständig gewesen, ermöglicht eine Schnittstelle wie AUTOSAR, dass beispielsweise Applikations-Software im Wettbewerb der Zulieferer austauschbar wird. Die Differenzierung ergibt sich in Zukunft allein durch den Funktionsumfang und die Implementierung der jeweiligen Funktionen.