<![CDATA[
<BODY>
<H1>www.aud24.net : R. Stücka: "Software im Kraftfahrzeug"</H1>
<P> <BR>
[<A href="/">www.aud24.net</A>] [<A href="../index.html">back</A>]
</P>
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0>
<TR>
<TD VALIGN=top>
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0>
<TR>
<TD VALIGN=TOP CLASS=detailBereichRedaktion>Bereich >
Redaktion
> <B><FONT color="#CC3300">Fachbeiträge</FONT></B></TD>
<TD ALIGN=right VALIGN=bottom CLASS=detailDatum>05.03.2001</TD>
</TR>
</TABLE>
</TD>
<TD VALIGN=top> </TD>
<TD VALIGN=top> </TD>
</TR>
<TR>
<TD VALIGN=top CLASS=detailFirma ID=topSpace>Telelogic Deutschland GmbH:</TD>
<TD VALIGN=top> </TD>
<TD VALIGN=top> </TD>
</TR>
<TR>
<TD VALIGN=top CLASS=detailTitel>R. Stücka: "Software im Kraftfahrzeug"</TD>
<TD VALIGN=top> </TD>
<TD VALIGN=top> </TD>
</TR>
<TR>
<TD VALIGN=top CLASS=detailSubtitel>Formale Methoden für die Entwicklung komplexer Softwaresysteme in der praktischen Anwendung</TD>
<TD VALIGN=top> </TD>
<TD VALIGN=top> </TD>
</TR>
<TR>
<TD VALIGN=top>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0>
<TR>
<TD VALIGN=top CLASS=detailContent>Es gibt formale Methoden, die mit bestechender Eleganz, wohldurchdachter Konsistenz und im mathematischen Sinne korrekt, präzise und mit allen notwendigen und hinreichenden Bedingungen vollständig definiert sind. Leider werden in der praktischen Anwendung oft Mängel evident, die einen wirtschaftlich sinnvollen Einsatz verhindern. So z.B. beim Beweis der semantischen Korrektheit von Programmen: Bei Software-Modulen überschaubarer Größe (am besten nicht mehr als eine einstellige Anzahl von Statements) kommt man in endlicher Zeit zu einem Ergebnis; der Aufwand wächst jedoch leider exponentiell mit dem Umfang des Programms. Andererseits kann bei der heutigen Komplexität und Größe von Software-Systemen im Kfz das ‚Spaghetti-Prinzip‘ auf Dauer auch nicht funktionieren. Daher gilt es, formale Methoden zu identifizieren und gegebenenfalls anzupassen, die in der Praxis tatsächlich wirkungsvolle Unterstützung bei der Entwicklung von komplexen Programmen bieten.<BR><BR>Einleitung<BR><BR>Bereits heute werden vielfältige Funktionen im Kfz durch ECUs gesteuert. Die Anzahl der ECUs wird weiter steigen, die Zahl der weltweit pro Jahr in neuen Fahrzeugen eingesetzten Microprozessoren liegt jetzt schon bei über 500 Mio. und wird in den nächsten Jahren weiterhin stark wachsen. Für den Bereich ‚In-Car Computing‘ werden Wachstumsraten von durchschnittlich 97% jährlich erwartet (VDC, 2000). Gleichzeitig steigt die Bedeutung der intelligenten Vernetzung von Funktionen, die von unterschiedlichen ECUs im Kfz ausgeführt werden, und damit die Komplexität der Software. Das Gesamtsystem ‚Fahrzeug‘ setzt sich aus einer Vielzahl auf verteilten Komponenten ablaufender Software-Module zusammen, die miteinander und je nach Anwendung auch mit dem Fahrer kommunizieren. Für die Software-Entwicklung liegt die Herausforderung nicht mehr nur in der Konzeption und Implementierung intelligenter Algorithmen zur Lösung der Einzelaufgaben, sondern darüber hinaus in der Gestaltung integrativer Funktionen und deren Umsetzung auf verteilte Systeme. <BR>Formale Methoden zur Unterstützung des gesamten Entwicklungsprojektes setzen bei der Identifikation der Anforderungen ein, helfen bei der Ausgestaltung der Funktionalität, begleiten die Spezifikationsphase, erleichtern die Codierung und sind unverzichtbar für den systematischen Test auf Komponentenebene, für Subsysteme und das Gesamtsystem. Je nach Anwendungsbereich sind unterschiedliche methodische Ansätze empfehlenswert, um z.B. die Entwicklung besonders sicherheitsrelevanter Systeme zu begleiten. In der Praxis bewährt haben sich methodengestützte Werkzeuge, die auf bestimmte Bereiche des Entwicklungsprozesses zugeschnitten sind. Neue Ansätze zur weiteren Optimierung ergeben sich aus der Verknüpfung und Interaktion dieser Werkzeuge, so dass eine bruchlose Einbettung des gesamten Entstehungsprozesses möglich wird. <BR><BR>Hauptteil<BR><BR>Frage: Was soll das System leisten ...<BR>Das ist bereits eine der schwierigsten und gleichzeitig am häufigsten unterschätzten Fragen im gesamten Entstehungsprozess. Die meisten Probleme im weiteren Projektverlauf haben ihren Ursprung in einer unvollständigen, ungenauen oder widersprüchlichen Beschreibung der an ein zu entwickelndes System gestellten Anforderungen. Es reicht eben nicht, als Anforderung zu definieren: ‚Der Fahrer-Airbag soll sich entfalten, wenn der Aufprall mit mehr als 30km/h erfolgt‘. Es gibt in diesem Zusammenhang eine Reihe von Fragen, die besser vor Beginn der Spezifikation der Software geklärt werden, z.B. was bei einem seitlichen Aufprall passiert, ob das Entfalten stufenweise vor sich gehen soll, wann der Airbag wieder zusammenfallen soll und er das auch tun soll, wenn es einen weiteren Aufprall gibt etc. Diese Auflistung verdeutlicht die Komplexität anhand nur einiger offener Fragen.<BR>Jeder intuitive Ansatz zur Identifikation der Anforderungen birgt ein hohes Risiko, dass einzelne Aspekte schlicht vergessen werden. Die spätere Einbringung von zunächst vergessenen Anforderungen oder Rahmenbedingungen führt zu unkalkulierbaren Verzögerungen im Gesamtprojekt. Schlimmstenfalls müssen grundlegende Design-Entscheidungen revidiert werden, um nachträglich identifizierten Anforderungen gerecht werden zu können.<BR>In der Praxis bewährt hat sich die Unterstützung einer strukturierten Anforderungsanalyse durch professionelle Werkzeuge. Ein ausgereiftes Werkzeug wie z.B. Telelogic ‚Doors‘ hilft nicht nur beim ‚Finden‘ sondern auch beim ‚Einhalten‘ der Anforderungen. Das in Doors implementierte Vorgehensmodell sorgt implizit für eine strukturierte und disziplinierte Requirement Management Prozedur. Um sicherzustellen, dass nicht nur die notwendigen sondern auch alle hinreichenden Anforderungen identifiziert werden können, stellt das Werkzeug einen unternehmensweiten Kontext her: Nicht nur die ausgewiesenen technischen Spezialisten sondern auch ‚fachfremde‘ Teammitglieder, z.B. aus dem Marketing, sind mit Doors in der Lage, ihren Beitrag zur Requirement-Analyse zu leisten. Das Werkzeug stellt das Rahmenwerk für die Beschreibung der Anforderungen, ohne die Kreativität oder die technische Machbarkeit zu beeinflussen. Gleichzeitig bietet das Werkzeug eine Art Monitor-Funktion - es ermöglicht die kontinuierliche Überwachung, ob die gefundenen Anforderungen durch das entstehende System abgedeckt werden.<BR><BR><BR>... und wie beschreibe ich das System?<BR>Das bekannte V-Modell orientiert sich an dem klassischen Top-down Ansatz für den Systementwurf. Im analytischen Bereich (der Quadrant oben links) wird man zunächst die Anforderungen auf einer relativ abstrakten Ebene visualisieren. Eine adäquate Notation in diesem Stadium des Projektes ist die Unified Modeling Language UML. Für den Bereich der Automobil-Hersteller und ihrer Zulieferer gibt es bereits speziell zugeschnittene Subsets der UML. Diese sind in dieser Form zwar noch nicht standardisiert, werden jedoch bereits in verschiedenen Projekten angewandt und sollen hier nicht thematisiert werden. <BR>Als Resultat der Anforderungsanalyse liegen alle durch das Zielsystem zu erfüllenden Anforderungen in einer sauber strukturierten Form vor, die einzelnen Anforderungen sind jedoch auf unterschiedliche Weise verbal oder mit Hilfe von Formeln niedergelegt. Das eigentliche Problem - und damit die interessante Frage - besteht nun in der Umsetzung der Anforderungen in eine formale Notation mit Hilfe der UML. Auch hier ist letztendlich die Wahl des geeigneten Werkzeuges der Schlüssel zur Lösung - in diesem Fall zu einer Methode der Transformation der Anforderungen in die UML Notation. Postuliert man eine Anbindung zwischen dem für das Requirement Management eingesetzten Werkzeug und dem UML-Werkzeug ergibt sich alles weitere von selbst, und mögliche Fehlerquellen werden ausgeschaltet.<BR>Vor diesem Hintergrund wurde vor einiger Zeit ein Projekt der Bayrischen Forschungsstiftung aufgesetzt mit dem Ziel der Integration der Werkzeuge Telelogic Doors und Telelogic Tau UML Suite in ein gemeinsames Vorgehensmodell. Als Ergebnis steht dann ein Entwicklungs-Kontext zur Verfügung, in dem die unterschiedlichen Informations-, Daten-, Beschreibungs- und Interaktionsmodelle, die für Anforderungsanalyse und -management, Projektmanagement und Systemspezifikation eingesetzt werden, konsistent und nachvollziehbar ineinander überführt werden können (soweit dies sinnvoll ist).<BR><BR><BR>Die Implementierung - nur noch Formsache?<BR>Um den besonderen Anforderungen der in der Automobilindustrie eingesetzten Softwaresysteme gerecht zu werden, gilt es die Schwächen der UML im Hinblick auf die Beschreibung der Architektur und des Echtzeitverhaltens auszugleichen. Daher empfiehlt es sich, in der nächsten Verfeinerungsstufe, im konstruktiven Bereich des V-Modells, als Notation die Specification Definition Language SDL für das detaillierte Design des Systems und der Komponenten einzusetzen. Insbesondere das Echtzeitverhalten und die Interaktion von Komponenten können mit SDL eindeutig und vollständig beschrieben werden.<BR>Die Transformation des UML Modells nach SDL ist im ITU Standard Z.109 niedergelegt und kann größtenteils automatisch erfolgen. Ein entsprechender Umsetzer von UML nach SDL gehört zum Lieferumfang der Telelogic Tau UML Suite.<BR>Die automatische Übersetzung von UML nach SDL liefert eine Systembeschreibung, die je nach Bedarf sofort simuliert oder weiter spezifiziert und anschließend simuliert werden kann. Die gleichzeitige Übersetzung von Sequenzdiagrammen in Message Sequence Charts (MSCs) erlaubt die Generierung von Test-Fällen, so das bereits in dieser frühen Projektphase Testkonzepte für den System- und Komponententest erstellt werden können (siehe Abb. 2).<BR>Der entscheidende Vorteil der Kombination von UML mit SDL liegt darin, dass nicht nur die notwendigen formalen Echtzeit-Erweiterungen bereits zur Verfügung stehen, sondern auch, dass SDL sich bereits seit vielen Jahren im industriellen Einsatz bewährt hat. <BR>Für die automatische Erzeugung von Source Code aus SDL stehen verschiedene Generatoren für die populärsten Sprachen, wie z.B. C, C++ oder Java, zur Verfügung. Ein Echtzeit-Kernel kann ebenfalls automatisch erzeugt werden, es werden jedoch auch Echtzeit-Betriebssysteme, z.B. OSEK oder VxWorks, unterstützt.<BR><BR><BR>Auf dem Weg zum serienreifen Produkt<BR>... gilt es jetzt noch die notwendigen Tests so zu planen, dass sie den maximal möglichen Wirkungsgrad erreichen. Auch für diese Projektphase gibt es Werkzeuge, die in die formale Methodik integriert sind und die Architektur und Modellierung des Systems reflektieren und formalisiert umsetzen. Bei Einsatz der Telelogic Tau TTCN Suite führt der Weg direkt von der in SDL vorliegenden Spezifikation in die standardisierte Notation von Testsequenzen mit Hilfe der Tree & Tabular Combined Notification TTCN. Diese automatisch erzeugten Testsequenzen arbeiten nach dem ‚black-box‘-Prinzip. Das Modul unter Test wird durch das Senden von Test-Messages stimuliert und die korrekte Verarbeitung anhand empfangener Antwort-Messages überprüft.<BR>Zur Überprüfung, ob der erzeugte Code grundlegenden Qualitätsansprüchen genügt und ob die Testsequenzen wirklich alle Pfade im Code erreichen, empfiehlt sich der Einsatz von professionellen Qualitätsmanagement-Werkzeugen. Solche Werkzeuge überprüfen die Qualität der Software nach einer Reihe formaler Kriterien, die projektspezifisch angepasst werden können. Als Ergebnis werden aussagefähige Kennzahlen erzeugt und in verschiedene graphische Darstellungsformen oder Listen umgesetzt. So können z.B. besonders fehleranfällige Module leicht identifiziert werden oder ungenügend getestete Pfade lokalisiert werden. Das Qualitätsmanagement-Werkzeug Telelogic Logiscope bietet darüber hinaus noch die Möglichkeit, die Einhaltung vorher festgelegter Regeln zu überprüfen, so dass das Fehlerrisiko deutlich verringert wird.<BR><BR>Zusammenfassung<BR><BR>Der konkrete Nutzen formaler Vorgehensmodelle zeigt sich in der praktischen Anwendbarkeit und in den daraus resultierenden Vorteilen für die Projektbeteiligten und das Unternehmen. Die besondere Stärke des hier skizzierten Vorschlags liegt in der Kombination der einzelnen Werkzeuge (siehe Abb. 3). Jedes für sich wurde lange erprobt und kontinuierlich optimiert. Jedes für sich bietet für eine bestimmte Projektphase höchst wirkungsvolle Unterstützung beim Einsatz formaler Methoden. Die Durchgängigkeit und das Ineinandergreifen der einzelnen Werkzeuge durch neue Methoden der Transformation spiegeln die Notwendigkeit und den Trend zur durchgängig formalen Methodik wieder. Dabei verhindert die jahrelange praktische Erfahrung mit den Werkzeugen, dass die Abstraktion sich zu sehr vom konkreten Einsatz entfernt.<BR>Gerade die Automobilbranche ist geprägt von hoher Innovationskraft und ständig kürzer werdenden Entwicklungszyklen. Sinnvoller Einsatz formaler Methoden ermöglicht kürzere Entwicklungszeiten und damit alle sich daraus direkt oder indirekt ergebenden Vorteile: geringere Entwicklungskosten, schnellerer Return-on-Investment und gleichzeitig weniger Reklamationen und zufriedenere Kunden, weil die Produkte ‚reifer‘ sind, wenn sie in die Serie gehen. Und dann kommen die Kunden zurück, nicht die Produkte.<BR></TD>
</TR>
<TR>
<TD CLASS=detailQuelle> </TD>
</TR>
</TABLE>
</TD>
<TD WIDTH=28 VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=1 HEIGHT=1 ALT=""></TD>
<TD WIDTH=174 VALIGN=top></TD>
</TR>
<TR>
<TD VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=393 HEIGHT=1 ALT=""></TD>
<TD WIDTH=28 VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=28 HEIGHT=1 ALT=""></TD>
<TD WIDTH=174 VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=174 HEIGHT=1 ALT=""></TD>
</TR>
</TABLE>
<P><I>Diese Seite wurde am 22.09.2006, 13:54 Uhr aktualisiert</I></P>
</BODY>
]]>