Komponenten sind nicht genug: Funktionsorientierte Entwicklung

Automotive-Blogger  –  0 Kommentare

Mit AUTOSAR hat die Automobil-Industrie große Schritte in der Verbesserung der Softwarearchitekturen im Steuergerät unternommen. Die Standardisierung der Architektur anhand von Komponenten erhöht sowohl die Austauschbarkeit als auch die Klarheit der Softwarestruktur. Für große komplexe Systeme reicht diese Komponentensicht allerdings nicht aus – es fehlen der Blick auf das "große Ganze" und die Zusammenhänge.

Deutlich wird das an Funktionen wie der Start-Stop-Automatik: Beim Stand an der Ampel wird der Motor deaktiviert und beim Anfahren wieder aktiviert. Im Vergleich zu den herkömmlichen kundenerlebbaren Zuständen "Motor an" und "Motor aus" kommt ein weiterer Zustand "fahrbereit", in dem der Motor automatisch aktiviert werden kann. Aus Sicherheitsgründen soll vermieden werden, dass der Motor gestartet wird, obwohl kein Fahrer anwesend ist. Für die Anwesenheitserkennung sind verschiedene technische Lösungen mit verschiedenen Vor- und Nachteilen denkbar ( z. B. Gurt-Sensor, Innenraum-Kamera, Sitzmatte).

Eine kostengünstige Variante ist der Türsensor. Wird sie in Software umgesetzt, sendet die Softwarekomponente des Türsensors eine Nachricht an die Komponente für die Start-Stopp-Automatik. Die eigentliche Motivation für dieses Signal, die Anwesenheitserkennung, geht allerdings im AUTOSAR-Modell verloren. Werden durch neue Techniken wie die Innenraumkamera andere Ansätze möglich, ist aus reinen Komponentenmodellen schwer herauszulesen, wie die Architektur umstrukturiert werden könnte. Zudem sind an der Realisierung einer Funktion oft verschiedene Steuergeräte beteiligt, die von verschiedenen Abteilungen verantwortet und von verschiedenen Firmen geliefert werden. Das führt dazu, dass eine systemische Sicht in den frühen Phasen zunehmend stärker erforderlich ist.

Einer der Ansätze hierzu ist die funktionsorientierte Entwicklung, bei der in den Phasen vor der technischen Architektur die logischen Funktionsnetze analysiert und spezifiziert werden. Diese sind noch frei von Design-Entscheidungen, wie der Frage ob eine Funktion in Hard- oder Software spezifiziert werden soll oder wie konkrete Bus-Signale umgesetzt werden. Diese Funktionen müssen sowohl in Richtung Anforderungen als auch in Richtung technische Architekturen nachverfolgt werden.

Sowohl für Methodik als auch für die Werkzeugunterstützung hat sich noch kein allgemeiner Standard etabliert. Ein erster Schritt ist die Veröffentlichung des EAST-ADL-Standards und seiner Eclipse-basierten Meta-Modell-Umsetzung EATOP. Im öffentlich geförderten Forschungsprojekt IMES bauen wir auf diese und weitere Eclipse-Techniken auf, um eine Werkzeugkette für funktionsorientierte Entwicklung darzustellen:

IMES Tooling (Bild: itemis)
  • Der Entwicklungsprozess beginnt mit den Anforderungen. Wir nutzen das Eclipse-RMF-Projekt, um ReqIF zu importieren und die Anforderungen darzustellen und zu editieren. Das ist auch die Basis für die Nachverfolgung von Anforderungen.
  • Feature-Modelle und Varianten werden mit Werkzeugen erstellt, die auf dem Eclipse-Feature-Projekt basieren und an dieses beigesteuert werden. Der Anwender erstellt die Modelle mit Xtext-Editoren in einer textuellen Notation.
  • Die Funktionsmodellierung nutzt Graphiti-Editoren, die Modelle nach dem EAST-ADL-Standard erzeugen. Dazu setzen wir auf das von der Continental AG in die Eclipse Auto IWG beigesteuerte Projekt EATOP.
  • In den frühen Phasen werden oft Funktionsprototypen in Form von Block-Diagrammen oder Zustandsdiagrammen erstellt. Bei den OEMs werden hierzu kommerzielle Werkzeuge eingesetzt – für die Demonstration nutzen wir Eclipse DAMOS.
  • Logische Funktionen werden auf die Softwarearchitektur abgebildet. Diese basiert in IMES in Artop und wird ebenfalls mit speziell entwickelten Graphiti-Editoren erstellt. Dies trifft auch auf die Bus-Topologie und die Steuergeräte zu.
  • Alle Artefakte können auf Modell-Element-Ebene nachverfolgt werden. Dazu nutzen wir das Tracing-Framework Yakindu CReMa, das aus dem Forschungsprojekt VERDE hervorging.
  • Auch auf Modellebene lassen sich Bug-Tickets und Change-Requests zuordnen. Eclipse Mylyn stellt hierzu die Infrastruktur bereit, die von IMES-Editoren genutzt wird.
  • Auf der Seite des Repositories bringen wir mit Sphinx und CDO die Projekte für Workspace-Management und Persistenz (inkl. Branching/Versioning) zusammen.

Man sieht an der obigen Skizze, dass eine Werkzeugunterstützung für die funktionsorientierte Entwicklung weite Bereiche des Entwicklungsprozesses umfasst. Daraus ergeben sich interessante Fragen über eine Werkzeugunterstützung – noch bewegen sich nicht allzu viele Anbieter auf diesem Markt. Im Wesentlichen lassen sich zwei Modelle erwarten:

  • Alles aus einer Hand: Werkzeughersteller bieten dedizierte Produkte für die funktionsorientierte Entwicklung mit dem Anspruch an, (fast) alle Anwendungsfälle abzudecken. Aufgrund der stark unterschiedlichen Ansätze in den Firmen und dem breiten Spektrum des erforderlichen Werkzeugs eine große Herausforderung, zu dem sich in der Industrie ein Trend hin zu modulareren Entwicklungen sehen lässt.
  • Ökosystem: Auf Basis der veröffentlichten Standards und "Standard"-Implementierungen wie Artop und EATOP gruppieren sich Anbieter mit unterschiedlichem Hintergrund, um Kernsystem und Erweiterungen bereitzustellen. Der Bedarf an derartigen Szenarien zeichnet sich unter anderem durch die starke Unterstützung von Artop bei OEMs und Tier-1s ab, die hiermit derartige Integrationsmöglichkeiten schaffen wollen.

Die funktionsorientierte Entwicklung ist ein noch relativ junges Thema. Neben der Werkzeuglandschaft wird sie Einfluss auf Organisationsstrukturen und Geschäftsmodelle haben.