Softwareentwicklung für Kraftfahrzeuge 3662680459, 9783662680452, 9783662680469

Citation preview

Konrad Reif · Fabian Wolf

Softwareentwicklung für Kraftfahrzeuge

Softwareentwicklung für Kraftfahrzeuge

Konrad Reif · Fabian Wolf

Softwareentwicklung für Kraftfahrzeuge

Konrad Reif Campus Friedrichshafen Duale Hochschule Baden-Württemberg Friedrichshafen, Baden-Württemberg, Deutschland

Fabian Wolf Technische Universität Clausthal Clausthal-Zellerfeld, Niedersachsen Deutschland

ISBN 978-3-662-68045-2 ISBN 978-3-662-68046-9 (eBook) https://doi.org/10.1007/978-3-662-68046-9 Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. © Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert an Springer-Verlag GmbH, DE, ein Teil von Springer Nature 2023 Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung des Verlags. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von allgemein beschreibenden Bezeichnungen, Marken, Unternehmensnamen etc. in diesem Werk bedeutet nicht, dass diese frei durch jedermann benutzt werden dürfen. Die Berechtigung zur Benutzung unterliegt, auch ohne gesonderten Hinweis hierzu, den Regeln des Markenrechts. Die Rechte des jeweiligen Zeicheninhabers sind zu beachten. Der Verlag, die Autoren und die Herausgeber gehen davon aus, dass die Angaben und Informationen in diesem Werk zum Zeitpunkt der Veröffentlichung vollständig und korrekt sind. Weder der Verlag noch die Autoren oder die Herausgeber übernehmen, ausdrücklich oder implizit, Gewähr für den Inhalt des Werkes, etwaige Fehler oder Äußerungen. Der Verlag bleibt im Hinblick auf geografische Zuordnungen und Gebietsbezeichnungen in veröffentlichten Karten und Institutionsadressen neutral. Planung/Lektorat: Markus Braun Springer Vieweg ist ein Imprint der eingetragenen Gesellschaft Springer-Verlag GmbH, DE und ist ein Teil von Springer Nature. Die Anschrift der Gesellschaft ist: Heidelberger Platz 3, 14197 Berlin, Germany Das Papier dieses Produkts ist recyclebar.

Vorwort

Der Kundennutzen, die Technologie und die Entwicklungsprozesse von Fahrzeugen stehen vor einem radikalen Wandel. Während in der Vergangenheit vor allem die Mobilität, Optik und Fahreigenschaften im Vordergrund standen, werden die Fahrzeuge von heute und morgen zusätzlich durch den erweiterten Kundennutzen, die sogenannte „User-Experience“ (UX) definiert. Hierbei muss die Evolution der gesamten Architektur des Fahrzeugs, das nach wie vor die Basis individueller Mobilität sein wird, betrachtet werden. Darauf abgestimmte Entwicklungsverfahren und Prozesse werden diesen Wandel begleiten. Anders als die kurzen Lebenszyklen für Elektronik und Software im Bereich der IT-Systeme auf Arbeitsplatzrechnern oder Smartphones als Endprodukte sind die Lebenszyklen der Software im Fahrzeug oft an die Entwicklungsprozesse der Fahrzeugplattformen, also sehr komplexe Systeme gekoppelt. Die Kundenerwartung an die Zuverlässigkeit des Fahrzeugs ist ebenfalls höher als die an reine Softwareprodukte. Diese langen und aufwendigen Entwicklungszyklen limitieren auf der einen Seite die Entwicklungsgeschwindigkeit für neue Produkttrends oder Kundenwünsche, stellen auf der anderen Seite allerdings die abgesicherte Funktionalität mit sämtlichen Seitenaspekten und für alle Varianten im Gesamtsystem Fahrzeug sicher. Auch bei der Umsetzung von Kundenwünschen und Vorgaben in reiner Software auf dem bestehenden System können Fehler, Missverständnisse und menschliches Versagen auftreten, was entsprechende Prozesse zur Absicherung verlangt. In Software implementierte Fahrzeugfunktionen und der Kundenwert der „User Experience UX“ werden als Eigenschaft des Gesamtprodukts im System entwickelt, freigegeben und verkauft. Der durch eine neue Generation von Kunden geprägte reine Verkauf von Funktionen in Form einer Softwareaktualisierung des bestehenden Fahrzeugs ist technisch eine Erweiterung der aktuellen gängigen Praxis der Reparatur des Fahrzeugs durch Software mittels sogenannter Software-Updates. Er unterliegt damit den gleichen Rahmenbedingungen. Diese müssen genauso ohne eine physikalische Änderung auf die Architektur des Fahrzeugs angepasst sein und in diesem Zusammenhang für alle Varianten entwickelt, getestet sowie freigegeben werden. Die Zielgruppen dieses Buchs sind in erster Linie angehende Fachkräfte, Studierende und Berufseinsteiger im Bereich der Fahrzeugelektronik und Fahrzeuginformatik sowie V

VI

Vorwort

sämtliche Mitarbeitende der Automobilindustrie, die sich auf den anstehenden Wandel nachhaltig vorbereiten wollen, um Entscheidungen auf der Basis von Fakten zu treffen. Damit empfiehlt sich dieses Werk auch als fachliche Basis für Entscheidungen außerhalb der Automobilindustrie, die den digitalen Wandel nachhaltig und fundiert vorantreiben sollen. Im ersten Teil dieses Buchs stehen vor allem die allgemeine Entwicklung von Softwarebasieren Kundenfunktionen und die dazu etablierten Verfahren und akademischen Vorgehensmodelle sowie Prozesse im Vordergrund. Im zweiten Teil des Buchs werden diese allgemeinen Grundlagen durch pragmatische Erfahrungen aus der industriellen Implementierung software-basierter mechatronischer Systeme konkretisiert. Changchun, VR China Friedrichshafen

Fabian Wolf Konrad Reif

Inhaltsverzeichnis

1 Funktions- und Softwareentwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Charakteristika eingebetteter Systeme im Fahrzeug . . . . . . . . . . . . . . . . . . . . 1.1.1 Grundbegriffe der Systemtheorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2 Strukturierung, Modellierung und Beschreibung . . . . . . . . . . . . . . . . 1.1.3 Steuergeräte und Mikrocontroller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.4 Zuverlässigkeit, Sicherheit und Überwachung . . . . . . . . . . . . . . . . . . 1.2 Vorgehensmodelle, Normen und Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Normen und Vorgehensmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2 Übergreifende technische Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Funktions- und Softwareentwicklung nach dem V-Modell . . . . . . . . . . . . . . 1.3.1 Konkretisierung des V-Modells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.2 Anforderungsmanagementprozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.3 Architekturfestlegung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.4 Komponentenfestlegung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.5 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.6 Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.7 Abnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Methoden in der Funktions- und Softwareentwicklung . . . . . . . . . . . . . . . . . 1.4.1 Anforderungsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.2 Testmethoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 2 2 3 5 8 9 9 13 14 15 16 19 23 25 27 28 28 29 35

2 Softwareentwicklungsprozess in der Automobilindustrie . . . . . . . . . . . . . . . . . . 2.1 Anforderungen und Architekturentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Anforderungserhebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Systemanforderungsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3 Systemarchitekturentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.4 Komponentenanforderungsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.5 Komponentenarchitekturentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Mechanik und Elektronik-Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41 42 42 43 45 46 47 48

VII

VIII

Inhaltsverzeichnis

2.3 Softwareentwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Softwareanforderungsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Softwareentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3 Funktionssoftwareerstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.4 Sicherheitssoftwareerstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.5 Softwareintegrationstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.6 Softwaretest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Integrationstests für Komponenten und System . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Komponententest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Komponentenintegrationstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.3 Systemintegrationstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.4 Systemtest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Übergreifende Prozesse der Softwareentwicklung . . . . . . . . . . . . . . . . . . . . . . 2.5.1 Qualitätssicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.2 Funktionale Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.3 Projektmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.4 Risikomanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.5 Lieferantenmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.6 Änderungsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.7 Konfigurationsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.8 Problemlösungsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.9 Freigabemanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49 49 50 51 52 53 53 54 54 54 55 56 57 57 59 61 64 66 69 69 71 73

Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75

1

Funktions- und Softwareentwicklung

Ein wesentlicher Anteil der Innovationen in heutigen Fahrzeugkonzepten wird durch Funktionen dargestellt, die durch Software abgebildet werden. Dieser Zusammenhang zeigt sich eindrucksvoll sowohl in dem stetig wachsenden Bedarf an Speicherplatz und Rechenzeit in Steuergeräten als auch in der steigenden Anzahl von komplexen und vernetzt wirkenden Funktionen. Als Beispiel sei etwa auf Fahrerassistenz- oder TelematikFunktionalitäten verwiesen, die sich die Eigenschaften mehrerer Funktionsbereiche im Fahrzeug in Form einer intelligenten Verknüpfung zu Nutze machen. Betriebsstrategien für Hybrid- und Elektrofahrzeuge berücksichtigen die Daten verschiedener Fahrzeugfunktionsbereiche für eine optimale Nutzung der im Kraftstoff und in der Batterie gespeicherten Energie. Damit sind neue Fahrzeugfunktionen und die intelligente Vernetzung vorhandener Systeme zu einem wichtigen Differenzierungspotenzial für Fahrzeughersteller herangewachsen. Neben den genannten und viel zitierten Vorteilen komplexer mechatronischer Systeme und ihrer Vernetzung ist auf der anderen Seite die Beherrschung dieser Technik zu einer echten Herausforderung geworden. Diese drückt sich nicht nur in den zu entwickelnden technischen Umfängen, sondern auch in den Entwicklungsprozessen aus, die sowohl der internen Vernetzung beim Fahrzeughersteller Rechnung tragen müssen, als auch die Kopplung zu einem Lieferantennetzwerk beherrschen müssen. Die vernetzte Fahrzeugfunktion ist hier der Haupt-Betrachtungsgegenstand. Deshalb beginnt es mit den notwendigen Grundlagen zum Verständnis sogenannter eingebetteter Systeme, die die Darstellung von vernetzten Fahrzeugfunktionen ermöglichen. Dabei werden als Kernelement eines mechatronischen Systems der Aufbau und die Charakteristika eines Steuergerätes geschildert. Den Abschluss dieses Grundlagen-Abschnittes bildet eine

© Der/die Autor(en), exklusiv lizenziert an Springer-Verlag GmbH, DE, ein Teil von Springer Nature 2023 K. Reif und F. Wolf, Softwareentwicklung für Kraftfahrzeuge, https://doi.org/10.1007/978-3-662-68046-9_1

1

2

1 Funktions- und Softwareentwicklung

kurze Betrachtung von Aspekten der Sicherheit, Zuverlässigkeit und Verfügbarkeit; also Themenbereichen, die sich mit dem Fehlerverhalten des Systems auseinandersetzen. Im Anschluss daran werden gängige Vorgehensmodelle und technische Standards erläutert, die für die Funktions- und Softwareentwicklung im Fahrzeugbereich relevant sind. Dies geschieht vor dem Hintergrund, dass heutige Qualitätsmanagementsysteme unter anderem die Prozessgestaltung als Hebel zur Qualitätssicherung ansehen. Damit wird an dieser Stelle der genannten prozessbezogenen Herausforderung bei der Entwicklung von Fahrzeugfunktionen Rechnung getragen. Zur Konkretisierung der Vorgehensweisen bei der Entwicklung von Fahrzeugfunktionen wird im dritten Abschnitt des Kapitels ein weit verbreitetes Vorgehensmodell, das sogenannte V-Modell, für die Anwendung in der Funktions- und Softwareentwicklung aufgegriffen und Schritt für Schritt durchgegangen. Einen Schwerpunkt bildet dabei die Betrachtung von Entwicklungsprozessen auf Systemebene, den sogenannten Architekturprozessen, die mit einem einfachen Beispiel erläutert werden. Der letzte Abschnitt dieses Kapitels ist der Behandlung von Methoden gewidmet, die entlang des V-Modells angewendet werden. Aufgrund ihrer hohen Relevanz wurde der Fokus auf den Bereich des Anforderungsmanagements als einer der Schlüsselmethoden auf der einen Seite des V-Modells und der Testmethodik als einem Vertreter der anderen Seite gewählt.

1.1

Charakteristika eingebetteter Systeme im Fahrzeug

Die heutigen Fahrzeuggenerationen beherbergen eine Vielzahl von technischen Systemen, die zunehmend durch Elektronik und Software geprägt werden. Diese mechatronischen Systeme ermöglichen es, vernetzte und kundenwertige Fahrzeugfunktionen darzustellen. Bevor auf die Vorgehensweisen zur Funktionsentwicklung näher eingegangen werden kann, ist es deshalb erforderlich, die Eigenschaften dieser sogenannten eingebetteten Systeme, also ihre Struktur, ihren Aufbau, ihr Zeitverhalten und ihr Verhalten im Fehlerfall zu erläutern. Aufbauend auf Grundbegriffen der Systemtheorie werden dazu zunächst geeignete Beschreibungsformen für die funktionale und technische Sicht erläutert. Im Anschluss daran wird der Aufbau von Steuergeräten kurz erklärt. Abgerundet werden die Charakteristika eingebetteter Systeme durch Aspekte der Zuverlässigkeit, Sicherheit und Überwachung.

1.1.1

Grundbegriffe der Systemtheorie

Da für elementare Begriffe wie Funktion oder System in den verschiedenen Anwendungsgebieten der Technik unterschiedliche inhaltliche Interpretationen existieren, ist es

1.1

Charakteristika eingebetteter Systeme im Fahrzeug

3

Störgröße

Sollgröße

Istgröße –

Regler

Regelstrecke

Abb. 1.1 Blockschaltbild eines Regelsystems

im ersten Schritt notwendig, die hier gewählte Terminologie festzulegen. Dabei ist die Unterscheidung zwischen dem technischen System, das als eine von ihrer Umgebung abgegrenzte Anordnung aufeinander einwirkender Komponenten oder Subsysteme verstanden wird und einer Funktion von Bedeutung. Unter einer Funktion wird hier ein gewollter Ursache-Wirkungs-Zusammenhang aufgefasst. Damit dienen technische Systeme der Darstellung oder Realisierung von Funktionen. Die Systembestandteile können im allgemeinen Fall sowohl mechanischer, elektronischer als auch softwaretechnischer Natur sein. In Abhängigkeit von der Komplexität werden Systeme in der Regel nach geeigneten Kriterien wie z. B. nach Hierarchien strukturiert und oft modular gestaltet. Eine typische Beschreibungsweise der Systemtheorie ist das Blockschaltbild (siehe Abb. 1.1). Damit kann auch die gedankliche Trennung zwischen der Funktion (Angleichung der Istgröße an die Sollgröße) und dem System (gesamtes Blockschaltbild) nachvollzogen werden. Abb. 1.1 stellt die in diesem Zusammenhang vorherrschende, grundlegende Topologie bestehend aus Regler und Regelstrecke dar. Der Fall einer offenen Wirkungskette (Steuerung) ist in diesem Bild ebenfalls gedanklich enthalten, wenn auf die Rückführung verzichtet wird.

1.1.2

Strukturierung, Modellierung und Beschreibung

Technische Systeme im Fahrzeug zeichnen sich dadurch aus, dass eine Vielzahl von unterschiedlichen Komponenten der Disziplinen Mechanik, Elektronik und Softwaretechnik zusammenwirken. Da der Betrachtungsumfang dieses Kapitels die Anteile aus dem Bereich Software umfasst, werden in den folgenden Abschnitten dieses Kapitels nur noch Systeme mit signifikanten elektronischen Anteilen und Softwarekomponenten betrachtet. Sind umfangreiche Softwarekomponenten zur Darstellung der gewünschten Funktion notwendig, so werden diese Softwareanteile in der Regel auf einem elektronischen Steuergerät implementiert. Häufig gibt es für diese Steuergeräte keine direkten Benutzerschnittstellen. Sie verrichten ihren Dienst quasi unsichtbar. Systeme, die Steuergeräte dieser Art enthalten, werden als eingebettete Systeme bezeichnet.

4

1 Funktions- und Softwareentwicklung

Tab. 1.1 Systemebenen eingebetteter Systeme. (Nach [Sc1]) Systemebene

Beispiel für zugeordnete Funktion

Beispiel für betroffene eingebettete Systeme oder Komponenten

Fahrzeug

Vernetzte Fahrzeugfunktion: automatische Fahrgeschwindigkeitsregelung

Kombiinstrument, Steuergerät Lenksäule, Motorsteuerung, Getriebesteuerung, notwendige Aktoren und Sensoren

Fahrzeugsubsystem

Antriebsstrangfunktion Gangwahl Automatikgetriebe

Motorsteuerung, Getriebesteuerung, notwendige Aktoren und Sensoren

Steuergerät

Motorfunktion Lasterfassung

Motorsteuerung mit Softwareanteil zur Lastberechnung, notwendige Sensoren

Mikrocontroller

Softwarefunktion Klopfregelung

Softwarekomponenten zur Signalverarbeitung für Klopfsensor, Klopfereignisermittlung, und Klopfkorrektur

Komponente

Softwarefunktion für Signalverarbeitung Klopfsensor

Zur Klassifikation und Beschreibung solcher Systeme ist z. B. eine Zuordnung zu den Fahrzeugfunktionsbereichen Antrieb, aktive und passive Sicherheit, Komfort, Multimedia und Telematik sinnvoll. Ergänzend lassen sich diese Systeme auch vertikal in Systemebenen strukturieren, wie in Tab. 1.1 aufgelistet. Funktionsnetzwerke und technische Systeme sind durch Zuordnungsbeziehungen miteinander verbunden. Diese Beziehungen sind in Abb. 1.2 dargestellt. In der funktionalen Sicht werden die Wechselwirkungen durch logische Verknüpfungen, d. h. durch Festlegung der auszutauschenden Informationen und durch Definition der hierzu notwendigen Abläufe, beschrieben. Beispielsweise könnte an dieser Stelle definiert sein, dass die Motordrehzahl zyklisch zwischen Funktion 1 und Funktion 3 ausgetauscht und im Fehlerfall durch einen Ersatzwert substituiert wird. Wie in Abb. 1.2 dargestellt, werden die beteiligten Funktionen 1 und 3 zwei unterschiedlichen Steuergeräten zugeordnet, d. h. auf zwei unterschiedlichen Mikroprozessoren implementiert und zur Ausführung gebracht. Die Darstellung der Motordrehzahl entspricht in der technischen Sicht einer CAN-Botschaft, die mit 16 Bit quantisiert in einem Zeitraster von 20 ms über den CAN-Bus übertragen wird. Verbindet man in Anlehnung an [Sc1] die Beschreibungsform eines Regelkreises (siehe Abb. 1.1) mit der Zuordnung einer Fahrzeugfunktion in der logischen Sicht zu der technischen Sicht in der Implementierung in einem Steuergerät (siehe Abb. 1.2), so gelangt man zu einer zusammenhängenden Darstellung, die die Einbettung einer Fahrzeugfunktion in einen „Fahrzeugregel-kreis“ zum Inhalt hat (Abb. 1.3). Diese Sichtweise wird auch bei der sogenannten Systemarchitektur angewendet, die die im System eingesetzten elektrischen und elektronischen Komponenten, deren Anzahl, Verknüpfung und Verteilung bestimmt:

1.1

Charakteristika eingebetteter Systeme im Fahrzeug

Funktionale Sicht: Funktionsnetzwerk

Logische Verknüpfung

5

Technische Systemsicht: Steuergerätenetzwerk

Zuordnung Funktion 3

Steuergerät 1

Reale „technische“ Verbindung

Funktion 1

Funktion 4

Steuergerät 2

Funktion 5

Steuergerät 3

Funktion 2

Bussystem

Abb. 1.2 Funktionale und technische Sicht

Man spricht dabei von der logischen und von der technischen Systemarchitektur. Diese Darstellung kann sinngemäß auch auf eine tiefer liegende Ebene wie z. B. die Ebene der Fahrzeugsubsysteme übertragen werden. Die Fahrzeugfunktion in diesem Regelkreis wird einem oder, sofern die Funktion möglicherweise aus mehreren Teilfunktionen besteht, auch mehreren Steuergeräten zugeordnet. Ferner wird sie durch die vom Fahrer vorgegebenen und durch entsprechende Sollwertgeber ermittelten Sollwerte sowie Messgrößen der Fahrzeugumwelt und des aktuellen Fahrzeugverhaltens gespeist. Das Berechnungsergebnis der Funktion wird zur Stimulation von Aktoren verwendet, die das Fahrzeugverhalten auf die gewünschte Art beeinflussen. Die Blöcke in dem beschriebenen Regelkreis enthalten als Bestandteile der Regelung oder Prozessführung Modelle. Hier wird häufig zwischen Funktionsmodellen, die die Fahrzeugfunktion beschreiben, Verhaltensmodellen, die das Verhalten des Fahrzeugs, der Sensoren und Aktoren beinhalten und Umweltmodellen, die das Verhalten der Fahrzeugumwelt abbilden, unterschieden.

1.1.3

Steuergeräte und Mikrocontroller

Abb. 1.4 zeigt vereinfacht den Aufbau eines elektronischen Steuergerätes, das exemplarisch mit je drei Sensoren und Aktoren verknüpft ist. Die Sensoren liefern häufig zeitund wertkontinuierliche Signale; teilweise ist die Anbindung aber auch digital über entsprechende Subbusse durchgeführt. Spätestens bei Eintritt in den Mikrocontroller über dessen spezialisierte Peripheriekomponenten werden die notwendigen Signalwandlungen

Sensor

1 Funktions- und Softwareentwicklung

Sensor

6

Steuergerät(e)

Sollgröße

Aktor

Erfassung des Fahrerwunsches zur Sollwertvorgabe (Sensoren) Aktor

Fahrer

Istgröße

Fahrzeugverhalten

Fahrzeugumwelt

Beeinflussung des Fahrzeugverhaltens (Aktoren)

Störgröße

Fahrzeugfunktion zur Regelung des Fahrzeugverhaltens

Erfassung des Fahrzeugs und der Umwelt (Sensoren)

Abb. 1.3 Realisierung einer Fahrzeugfunktion durch einen Regelkreis

durchgeführt, sodass die Verarbeitung in den Softwarekomponenten vollständig auf Basis von wert- und zeitdiskreten Signalen geschehen kann. Unter dem Begriff Software wird in diesem Zusammenhang die Gesamtheit der Softwarekomponenten unter Einbeziehung aller Daten verstanden. Die codierten Algorithmen werden häufig als Programmcode oder Programmstand bezeichnet. Die Anpassung dieser Algorithmen an die spezifischen Eigenschaften des zu steuernden oder zu regelnden Systems und die Optimierung der Funktionsweise wird im Rahmen der Applikation oder Parametrierung der Software durchgeführt und mündet in den sogenannten Datenstand. Diese bewusste Aufteilung in Programm- und Datenstand bietet im Entwicklungsprozess eine Reihe von Vorteilen, auf die später noch eingegangen wird. Der Speicherort für Programm- und Datenstand ist der Programm- und Datenspeicher, der in Abb. 1.5 in der vereinfachten Darstellung eines Mikrocontrollers abgebildet ist. Dieser Speicher wird nichtflüchtig ausgeführt, da hier die Algorithmen und Parametersätze auch ohne anliegende Betriebsspannung gesichert sein müssen. Als Speichertechnologie wird häufig der sogenannte Flash-Speicher (EEPROM, Electrically Erasable Programmable Read-Only Memory) eingesetzt. Dieser ermöglicht es, das Steuergerät auch im verbauten Zustand im Fahrzeug vollständig neu zu programmieren und stellt damit die notwendige Flexibilität für Programm- und Datenänderungen im Service-Fall sicher.

Charakteristika eingebetteter Systeme im Fahrzeug

7

Funktion

Sensor

Sensor

Sensor

1.1

Eingangsstufen/Busankopplung

Analog-DigitalWandlung

Analog-DigitalWandlung

...

Software

Digital-AnalogWandlung

Digital-AnalogWandlung

Aktor

Steuergerät

Aktor

Ausgangsstufen/Busankopplung

Mikrocontroller

Aktor

...

Abb. 1.4 Aufbau eines Steuergeräts mit Mikrocontroller und Software

Der reine Datenspeicher beherbergt Daten, die sich während der Ausführung des Programms verändern und ist deshalb als Schreib-Lese-Speicher konzipiert. Da Daten, die sich während der Abarbeitung ändern (z. B. Adaptionswerte), häufig auch nach Abstellen des Fahrzeugs erhalten bleiben müssen, werden hier neben flüchtigen auch und nichtflüchtige Speichertechnologien eingesetzt. Alle weiteren Blöcke in Abb. 1.5 entsprechen weitgehend den Standardkonfigurationen von herkömmlichen Mikrocontrollern. Hervorzuheben ist, dass die abgebildete Überwachungseinheit die hardwareseitig implementierten Maßnahmen zur Überwachung des Programmablaufs (z. B. Watchdog oder Überwachungsrechner) beinhaltet, und nicht die funktionalen Ansätze, die in implementierter Form Teil des Programmstandes sind.

1 Funktions- und Softwareentwicklung

Programm- und Datenspeicher Mikroprozessor

in der Regel als nichtflüchtiger Lesespeicher (Flash) ausgeführt

Steuerwerk Rechenwerk

Datenspeicher Überwachung

als nichtflüchtiger oder flüchtiger SchreibLese-Speicher ausgeführt

Eingabe-, Ausgabeeinheiten

8

Abb. 1.5 Vereinfachter Aufbau eines Mikrocontrollers

1.1.4

Zuverlässigkeit, Sicherheit und Überwachung

Fahrzeugfunktionen beeinflussen in dem in Abb. 1.3 dargestellten Regelkreis das Fahrzeugverhalten. Insbesondere in den Fahrzeugfunktionsbereichen Antrieb, aktive Sicherheit und elektronische Lenkung sind Systeme angesiedelt, die auf das Fahrverhalten gezielt einwirken und damit im Falle eines Fehlers die Sicherheit der Insassen oder Personen außerhalb des Fahrzeugs tangieren oder sogar gefährden können. Vor diesem Hintergrund ist der Entwicklung dieser Systeme unter den Gesichtspunkten der Erkennung und Behandlung von Fehlern große Beachtung und systematische Sorgfalt zu schenken (siehe auch [Ju1]). Zur Beschreibung der Systemeigenschaften und des Systemverhaltens in diesem Kontext wer- den die Begriffe Zuverlässigkeit, Verfügbarkeit und Sicherheit herangezogen, die in Abschn. 9.1 definiert werden (siehe hierzu auch [Di1], [Di2], [Di3]). Im Gegensatz zu Verfügbarkeit und Zuverlässigkeit ist das bestimmende Element für die Sicherheit nicht die Funktion eines Systems, sondern das Risiko, das bei fehlerfreiem oder fehlerbehaftetem Betrieb entsteht. Aus diesem Grund haben Maßnahmen zur Erhöhung der Zuverlässigkeit eine andere Zielsetzung als (Schutz-)Maßnahmen zur Erhöhung der Sicherheit. Letztere bezwecken die Verringerung des Risikos, während die erstgenannten generell und präventiv gegen das Auftreten von Feh- lern gerichtet sind. Der Umgang mit Fehlern in Systemen erfolgt grundsätzlich in zwei Schritten: Zunächst ist durch geeignete Maßnahmen die Erkennung von Fehlerzuständen zu gewährleisten, bevor im zweiten Schritt die Fehlerbehandlung erfolgt. Für eine erfolgreiche Fehlererkennung existieren mehrere Ansätze, die in der Regel auf Vergleich beruhen. So können etwa Redundanzen im System genutzt werden, um Signalwerte zu plausibilisieren, oder es können zusätzliche Prüfinformationen mit den Signalen übertragen werden. Typisch

1.2 Vorgehensmodelle, Normen und Standards

9

ist auch die Plausibilisierung des Programmablaufs in einem Mikroprozessor durch eine Überwachungseinheit (Watchdog) oder die Plausibilisierung von Signalverläufen aufgrund physikalischer Zusammenhänge. Bei der Fehlerbehandlung werden in der Regel gestuft Maßnahmen eingeleitet, die „harmlos“ bei der Verwendung von Ersatzwerten beginnen und sich über die Abschaltung von Subsystemen bis hin zum gezielten Neustart oder irreversiblen Abschalten des Gesamtsystems erstrecken können.

1.2

Vorgehensmodelle, Normen und Standards

Nicht zuletzt wegen der zunehmenden Komplexität vernetzter elektronischer und durch Software geprägter Systeme gewinnen Maßnahmen zur Qualitätssicherung immer mehr an Bedeutung. Während traditionelle Ansätze des Qualitätsmanagements darauf ausgerichtet waren, das System oder die Software nach Abschluss der Erstellung zu testen, rückt heute zunehmend die Verbesserung des Erstellungsprozesses als indirekte Einwirkung auf die Produktqualität in den Betrachtungsfokus. Diesem Tatbestand wurde durch eine Reihe von Vorschlägen für das Vorgehen bei der Entwicklung Rechnung getragen: entweder in Form von Vorgehensmodellen, die den Charakter von Rahmenrichtlinien haben, oder in Form von Prozessbeschreibungen. Der folgende Abschnitt gibt deshalb einen Einblick in mehrere gängige Vorgehensmodelle. Zusätzlich zu den angesprochenen prozessorientierten Maßnahmen zur Qualitätsverbesserung sind die aktuellen Entwicklungen auch zunehmend durch den Einsatz von übergreifenden technischen Standards geprägt. Solche Standards werden häufig in firmenübergreifenden Kooperationen definiert; und zwar in Themenfeldern, die für die Fahrzeughersteller und die Zulieferer kein Differenzierungspotenzial bieten, sondern Synergien durch Plattformtechnologien ermöglichen.

1.2.1

Normen und Vorgehensmodelle

Während die weit verbreitete ISO-9000-Normen-Familie den Charakter eines allgemeinen Qualitätsstandards hat und nur in Teilschriften auf das Gebiet der Funktions- und Softwareentwicklung eingeht, existieren mittlerweile mehrere Vorgehensmodelle, die das Gebiet der Systementwicklung und auch den Teilbereich der Softwareentwicklung umfassen. Erwähnt seien CMMI (siehe [Kn1] und [Cm1]) und SPICE [Sp1], die insbesondere zur Reifebewertung von Prozessen und Organisationen herangezogen werden können. Weit verbreitet ist auch das V-Modell des Bundesministeriums des Inneren (siehe [Vm1] und [Vm2]). Als Gegensatz zu den sogenannten „schweren“ Vorgehensmodellen mit vielen Vorgaben, zu denen z. B. das V-Modell gehört, existieren auch Ansätze, die als „agile“ Prozesse

10

1 Funktions- und Softwareentwicklung

bezeichnet werden (vgl. hierzu [Ru1]). Als ein typisches Beispiel für diesen Typ von Vorgehensmodell gilt Extreme Programming [Be2]. Für den Bereich der Funktionssicherheit existieren eigene Normen, wie etwa die IEC 61508. Auf dieses Themenfeld wird in Abschn. 9.2 näher eingegangen. Eine Übersicht der in diesem Kontext relevanten Vorschriften findet sich in [Ju1].

ISO-9000-Familie ISO 9000 ist ein Sammelbegriff für eine Familie von Normen, die den Aufbau von Qualitäts- management-Systemen zum Inhalt hat und 1994 verabschiedet wurde. Über den Begriff der Qualitätssicherung hinausgehend wird unter einem QualitätsmanagementSystem sowohl die Organisationsstruktur und zugehörige Verantwortlichkeiten als auch die notwendigen Prozesse und Maßnahmen zum Qualitätsmanagement verstanden. Relevant für den betrachteten Kontext dieses Kapitels ist der dritte Teil der ISO 9000 (informativer Normenteil), der die Anwendung der Norm ISO 9001 auf die Entwicklung von Software beschreibt. Die ISO 9001 umfasst Nachweisforderungen an ein Qualitätsmanagement-System und wird deshalb für den externen Nachweis eines „ausreichenden“ oder angemessenen Qualitätsmanagements herangezogen. Die Anforderungen dieser Norm betreffen den gesamten Produktlebenszyklus, beginnend mit der Entwicklung über die Produktion bis zur Wartung und sind deshalb für den Bereich der Softwareentwicklung relevant. Der Schwerpunkt der Anforderungen besteht in der verbindlichen und dokumentierten Definition von Prozessen und Abläufen, deren inhaltliche Gestaltung allerdings nicht in der Norm geregelt ist, sondern dem anwenden- den Unternehmen überlassen wird. Damit besitzt diese Norm eher allgemeinen und abstrakten Charakter.

CMMI Eine alternative Konzeption stellt das CMMI (Capability Maturity Model Integration) [Cm1] dar, das als Nachfolger des CMM (Capability Maturity Model) am Software Engineering Institute in Pittsburgh (SEI) entwickelt wird. Ähnlich wie in der ISO-9000-Familie besteht auch hier die Grundphilosophie darin, die Produktqualität durch verbesserte Produktentstehungsprozesse zu erhöhen und ein Instrumentarium zur Beurteilung der Prozessreife zu schaffen. Wesentlicher Betrachtungsgegenstand des CMMI sind die Systemund Softwareentwicklung (siehe auch [Kn1]). Zur Strukturierung verwendet das CMMI Darstellungsformen (stufenförmig oder kontinuierlich), Anwendungsgebiete (z. B. Softwareentwicklung), Prozessgebiete (z. B. Projektplanung) und Ziele. Unter einem Prozessgebiet wird dabei eine geeignete, thematisch orientierte Zusammenfassung von Anforderungen verstanden. Die stufenförmige Darstellung der Reifegrade des CMMI ist in Abb. 1.6 dargestellt. Der niedrigste Reifegrad wird häufig auch als „Heldenkultur“ bezeichnet, weil die Einzelleistungen von wenigen, individuellen Wissensträgern erbracht werden. Ab Reifegrad 2 werden als wesentliche Grundlage für verbesserte Prozesse ein Projektmanagement und

3

2

4

Fo im cus pro on ve pro me ce nt ss

Pr o an ces dc sm on tro easu lle d red

ly Pr o co cess ntr oll unp ed red an ict d r ab ea le, cti ve poor

1

11

Pr o pro ces jec s ch ts an arac d o ter fte ize nr df e a or cti ve Pr o org ces an s ch iza tio arac n a te r nd ize p r o d fo a c r th tiv e e

1.2 Vorgehensmodelle, Normen und Standards

5

Optimizing

Quantitatively Managed

Defined

Managed

Performed

Abb. 1.6 Reifegrade nach CMMI in der stufenförmigen Ausprägung. (Nach [Cm1], aufgrund der klareren Begriffsbildung wurden die englischen Bezeichnungen beibehalten)

ein Anforderungsmanagement gefordert. Darauf aufbauend ist der Reifegrad 3 durch die Übertragung einheitlicher Prozesse auf die gesamte Organisationsform charakterisiert, die ab Reifegrad 4 durch die Einführung von Metriken auch quantitativ beherrscht werden sollen. Der höchste Reifegrad nach CMMI sieht kontinuierliche und systematische Verbesserungsprozesse vor. Die Reifegrade in der stufenförmigen Darstellung werden für die gesamte Organisation vergeben und sind jeweils mit Prozessgebieten und konkreten Anforderungen für diese Gebiete verknüpft. Die kontinuierliche Darstellung des CMMI, die alternativ zu der stufenförmigen Darstellung unter Nutzung der gleichen Strukturelemente definiert ist, beschreibt Fähigkeitsgrade und nicht Reifegrade. Diese Fähigkeitsgrade werden pro Prozessgebiet vergeben und ergeben zusammen ein Fähigkeitsprofil für die Organisationsform, sodass insgesamt ein differenzierteres Bild als in der stufenförmigen Darstellung entsteht. Die Bewertung und Einschätzung der Prozessreife nach CMMI geschieht im Rahmen eines sogenannten Appraisals, das nach der durch das SEI definierten Methode SCAMPI (Standard CMMI Appraisal Method for Process Improvement) durchgeführt werden kann. Durch die Bewertung, aber auch durch die einhergehenden Prozessveränderungen im Rahmen der Einführung des CMMI entstehen für das jeweilige Unternehmen signifikante Aufwendungen, denen aber positive Qualitätseffekte gegenüberstehen. Deshalb und aufgrund des konkreten Bezugs zur System- und Softwareentwicklung und der konsequenten Strukturierung setzen mittlerweile eine Reihe von Automobilherstellern und Zulieferern das CMMI-Modell ein.

12

1 Funktions- und Softwareentwicklung

V-Modell Das V-Modell ist ein Vorgehensmodell, das 1992 im Auftrag des Bundesministeriums für Verteidigung entwickelt wurde und als Grundlage für die öffentliche Vergabe von Softwareausschreibungen vorgesehen war. Ursprüngliches Anwendungsgebiet des V-Modells in der Fassung von 1997 [Vm1] war die Softwareentwicklung; es wurde aber auch zunehmend in der Automobilindustrie eingesetzt. In der aktuellsten Fassung (V-Modell XT) ist der Anwendungsfokus breiter gefasst und auch komplexe Elektronik-Systeme werden unterstützt (siehe [Vm2]). Der Systementwicklungsprozess im V-Modell wird gedanklich in zwei Prozessphasen separiert. Die erste Prozessphase setzt bei den Benutzeranforderungen an, führt dann schrittweise durch einen Top-down-Prozess, der in der Implementierung von Systemelementen wie etwa Softwaremodulen endet. In der zweiten Prozessphase finden die Integration und der Test der entwickelten Elemente bis hin zur Systemabnahme statt. Diese Phase stellt somit einen Bottom-up-Prozess dar. Werden beide Teilprozesse zusammengesetzt, entsteht ein V-förmiger Gesamtablauf, der zu der Bezeichnung V-Modell geführt hat (siehe Abb. 1.7). Für die Umsetzung im Unternehmen sind die im V-Modell allgemein formulierten Vorgehensweisen durch ein sogenanntes Tayloring auf das jeweilige Anwendungsgebiet anzupassen. In der realen Anwendung ist auch davon auszugehen, dass Prozessschritte des V-Modells oder das gesamte Modell nicht nur einmal, sondern mehrfach durchlaufen werden. Insbesondere bei Entwicklungen mit hohem Innovationsgehalt, bei denen das vollständige Gerüst an Anforderungen noch nicht vollständig zu Projektbeginn definiert werden kann, sind Iterationen im V-Modell sehr wahrscheinlich.

System spezifiziert

System entworfen

Feinentwurf abgeschlossen

Abnahme erfolgt

Lieferung durchgeführt

System integriert

Systemelemente realisiert

Realisierung, Integration und Test

Spezi fikati on und Zerl egung

Benutzeranforderungen festgelegt

Abb. 1.7 Grundzüge des V-Modells (nach [Vm2]). Die Benutzeranforderungen werden im Rahmen der Projektdefinition oder Projektbeauftragung festgelegt

1.2 Vorgehensmodelle, Normen und Standards

1.2.2

13

Übergreifende technische Standards

Übergreifende technische Standards entstehen häufig durch firmenübergreifende Kooperationen. Die Zielsetzung besteht in der Regel darin, gemeinsame Definitionen für Plattformtechnologien zu finden, um Synergien zu schaffen und neuen und damit häufig kostenintensiven Technologien zum Durchbruch zu verhelfen. Neben den hier dargestellten Standards, die im Rahmen der Funktions- und Softwareentwicklung Anwendung finden, ist dieses Vorgehen auch zunehmend im Bereich der Bussysteme, z. B. bei der Definition von FlexRay oder LIN zu beobachten.

ASAM Neben der angesprochenen zunehmenden technischen Komplexität ist die Entwicklung vernetzter eingebetteter Systeme auch durch heterogene Zusammenarbeitsmodelle unterschiedlicher Unternehmen über die Phasen Entwicklung, Produktion und Service gekennzeichnet. Diese Situation hat zur Folge, dass die betrachteten Systeme in verschiedenen Konfigurationen und Umgebungen, z. B. bei der zum Teil automatischen Testdurchführung, der Parametrierung, der Fertigung und im Servicefall betrieben werden müssen. Insgesamt entsteht ein erheblicher Aufwand durch die Anpassung von Datenformaten und Schnittstellen an die genutzten Prüf-, Kalibrier- und Serviceumgebungen. Zur Verringerung dieser Adaptions- und Anpassungsaufwände entstand ab 1990 die ASAM- Initiative (Association for Standardization of Automation and Measuring Systems), die 1999 in die Gründung des ASAM e. V. einmündete und sich zum Ziel gesetzt hat, Standards für Daten und Schnittstellen in den Anwendungsfeldern Analyse, Simulation, Automation, Kalibrierung, Diagnose und Messtechnik zu entwickeln. Der ASAM-Standard wird in Kooperation von Fahrzeugherstellern und Systempartnern entwickelt und ist in mehrere Teilspezifikationen unter- gliedert. In Tab. 1.2 sind die wesentlichen Spezifikationen zusammengefasst aufgelistet. Eine intensive Weiterentwicklung und Implementierung findet dabei zurzeit im Bereich der ASAM-MCD-Spezifikation statt. Dieser Standard kann vorteilhaft und effizient im Bereich der Steuergeräte-Schnittstellen und Diagnosedatenhaltung genutzt werden. So beschreibt z. B. die MCD-2D-Spezifikation (ODX) ein Datenmodell zum Austausch von Diagnosedaten im Fahrzeug [As2].

OSEK/VDX Der Betriebssystemstandard OSEK/VDX vereinheitlicht Echtzeitbetriebssysteme mit Kommunikations- und Netzwerkdiensten, die den Anforderungen von Steuergeräten in Kraftfahrzeugen entsprechen. Er besteht aus den drei Hauptspezifikationen OSEK-OS (Betriebssystem), OSEK-COM (Kommunikation) und OSEK-NM (Netzwerkmanagement), deren inhaltliche Beziehung in Abb. 2.6 verdeutlicht ist. Basis für alle nachfolgenden Festlegungen ist das OSEK-OS, das als ereignisgesteuertes Betriebssystem fungiert. Diese Echtzeit-Systemumgebung bildet das Fundament für die Anwendungs-Software der

14

1 Funktions- und Softwareentwicklung

Tab. 1.2 Inhalte des ASAM-Standards Spezifikation

Kurzbezeichnung

Inhalte

ASAM ODS

Open Data Services

Generisches Datenmodell, Syntax und Format des Datenaustausches, Zugriff auf Datenablagen

ASAM MCD

Measurement, Calibration and Diagnostics

Schnittstellen zur Beschreibung und Integration von Steuerund Regelsystemen (Mess-, Kalibrier- und Diagnoseschnittstellen)

ASAM GDI

Generic Device Interface

Schnittstellen zur Integration von Messgeräten

ASAM ACI

Automatic Calibration Interface

Schnittstellen zwischen Optimierungs- und Automatisierungskomponenten (automatische Steuergerätekalibrierung)

ASAM CEA

Components for Evaluation and Analysis

Komponentenschnittstelle und Basisfunktionalität für die standardisierte Auswertung und Darstellung von Messergebnissen

Steuergeräte und ist Grundlage für alle anderen OSEK/VDX-Module. Kernmerkmal des Betriebssystems ist das Taskkonzept, das in seiner Basis-Fassung bereits in Abb. 2.3 dargestellt wurde.

1.3

Funktions- und Softwareentwicklung nach dem V-Modell

Wie in Abschn. 1.2.1 ausgeführt, liegen die Stärken des V-Modells in der konsequenten Top- down-Strukturierung des Entwicklungsprozesses. Diese Durchgängigkeit erweist sich dann als problematisch, wenn zu Beginn des Entwicklungsvorhabens die Informationsbasis noch nicht vollständig ist und folglich das System nicht „von oben nach unten“ entwickelt werden kann. Das gilt auch für die in der Automobilindustrie sehr verbreitete Entwicklung von Prototypen, die trotz des Reifegrads einer Versuchssoftware für den geplanten Einsatz auf öffentlicher Straße regulatorische Rahmenbedingungen einzuhalten hat. Hier handelt es sich meist um eine Untermenge der durch das V-Modell vorgegebenen Aktivitäten. In diesem Fall wird das V-Modell nicht vollständig oder in Teilschritten iterativ durchlaufen. Ergänzend zu dem eigentlichen Entwicklungsprozess, der durch das V-Modell beschrieben wird, wird ein Entwicklungsvorhaben in der Regel durch weitere parallel ablaufende Prozesse wie etwa Projekt-, Konfigurations- oder Änderungsmanagement begleitet (siehe auch [Sc1]). Gerade die Aspekte verteilter Entwicklungsanteile und die Synchronisation mehrerer Entwicklungspartner stellen heute zusätzliche Herausforderungen an das Management von Automobilprojekten. Diese Teilprozesse werden im Rahmen dieses Kapitels nur kurz angesprochen, aber nicht näher ausgeführt.

1.3

Funktions- und Softwareentwicklung nach dem V-Modell

15

Das V-Modell in seiner aktuellen Ausprägung ist zur Entwicklung von elektronischen Systemen ausgebildet. In den folgenden Unterabschnitten soll dieser allgemeine Betrachtungshorizont im Hinblick auf die Entwicklung von Fahrzeugfunktionen, die durch eingebettete elektro- nische Systeme dargestellt werden, konkretisiert werden. Dabei ist zu berücksichtigen, dass das V-Modell in seiner Eigenschaft als Vorgehensmodell einen „reinen“ oder idealen Prozess be- schreibt. In der praktischen Anwendung sind die Übergänge zwischen den einzelnen Prozessschritten zum Teil fließend. Ein größerer Schwerpunkt in der Erläuterung des V-Modells wird auf die ausführliche Darstellung der Architekturfestlegungen gelegt, die mit einem einfachen Beispiel illustriert werden. Dies geschieht vor dem Erfahrungshintergrund, dass diese Prozesse angesichts der gravieren- den Auswirkungen von Design-Fehlern großen Einfluss auf den Projekterfolg haben. Da eine Fahrzeugentwicklung in der Regel in mehrere Projektphasen unterteilt wird und den einzelnen Phasen definierte Entwicklungsstände zugewiesen werden, ist der nachfolgend beschriebene Durchlauf durch das V-Modell bezogen auf eine Projektphase zu verstehen.

1.3.1

Konkretisierung des V-Modells

In Abb. 1.8 ist das V-Modell für die Entwicklung von eingebetteten Systemen im Kraftfahrzeug dargestellt. Der Übergang von der Systementwicklung zur Softwareentwicklung ist durch die waagerechte, gestrichelte Linie markiert. An dieser Stelle im Entwicklungsprozess wird der Entwicklungsstrang der Systementwicklung in die drei Stränge der Systemanteile Aktorik und Sensorik, Steuergeräte-Hardware sowie Steuergeräte-Software aufgesplittet. Für jeden Einzelstrang wird jeweils ein eigenes V-Modell durchlaufen. In Abb. 1.8 wird der Strang der Softwareentwicklung weiter ausgeführt. Im rechten Ast des V-Modells laufen die drei Stränge dann wieder bei der Integration des gesamten Systems zusammen. Ein weiteres Charakteristikum des V-Modells ist durch die waagerechten Pfeile illustriert, die eine Querbeziehung zwischen absteigendem und aufsteigendem Ast des V-Modells herstellen. Durch diese Darstellung wird verdeutlicht, dass auf jeder Ebene des V-Modells jeweils im linken Ast diejenigen Informationen entstehen, die auf dem rechten Ast zur Ableitung von Testfällen benötigt werden. Dieser Tatbestand wird später noch ausführlich aufgegriffen. Der Informationsrückfluss von der rechten Seite des V-Modells zur linken Seite, der in Form von Spezifikationskorrekturen bedingt durch Erkenntnisse aus den Testaktivitäten stattfindet, ist in Abb. 1.8 aus Gründen der Übersichtlichkeit nicht eingezeichnet. Im Rahmen der Komponentenfestlegung wird diese Thematik noch ausführlicher aufgegriffen. In der komprimierten Darstellung des V-Modells in Abb. 1.8 ist der linke Ast durch die Spezifikationsprozess-Schritte geprägt. Bei detaillierter Betrachtung (siehe Abb. 1.10)

16

1 Funktions- und Softwareentwicklung

Testfälle

Benutzeranforderungen an die Fahrzeugfunktion festgelegt

Abnahme und Akzeptanztest

Parametrierung /Applikation des Systems

Spezifikation der logischen Systemarchitektur Testfälle Spezifikation der technischen Systemarchitektur Aktorik Sensorik

Integration des Systems, Integrationstest

Testfälle

SteuergeräteHardware

Aktorik Sensorik

SteuergeräteHardware SteuergeräteSoftware

SteuergeräteSoftware Spezifikation der Softwarearchitektur

Spezifikation der Softwarekomponenten

Testfälle

Integration der Softwarekomponenten, Integrationstest

Testfälle

Test der Softwarekomponenten

Design und Implementierung der Softwarekomponenten

Abb. 1.8 V-Modell zur Systementwicklung eingebetteter Systeme im Kraftfahrzeug

tritt zu Tage, dass jedem Spezifikationsschritt ein Prozess-Schritt vorangeht, in dem die Anforderungen an das jeweilige technische Konstrukt konsolidiert werden, um dann zu einer Lösung „entwickelt“ zu werden. Diese Trennung in die Anforderungsseite, die sich mit dem „was“ befasst, und der Lösungsseite, die sich mit dem „wie“ befasst, ist für alle weiteren Betrachtungen bedeutsam und wird im weiteren Verlauf der Darstellung noch mehrfach aufgegriffen. Der angeführte Top-down- Prozess, der durch das V-Modell konsequent beschrieben wird, drückt sich durch die diagonalen Pfeile aus, die jeweils das Ableiten von Anforderungen an die nächste tiefere Ebene symbolisieren.

1.3.2

Anforderungsmanagementprozesse

Wie im vorangehenden Abschnitt erläutert, wird der linke Ast durch das Wechselspiel zwischen Anforderungs- und Lösungsseite geprägt. Diese gedankliche Trennung hat sich insbesondere bei komplexen Entwicklungsprojekten bewährt. Das Risiko, dass zum Ende des Projektes ein Entwicklungsergebnis vorliegt, das nicht den Wünschen und den Anforderungen der Benutzer entspricht, kann dadurch verringert werden.

1.3

Funktions- und Softwareentwicklung nach dem V-Modell

17

Betrachtet man den Auszug aus dem V-Modell in Abb. 1.9, so wird deutlich, dass analog zu der Hierarchie der Systemebenen nach Tab. 1.1, die auf der Lösungsseite angesiedelt ist, auch eine Anforderungshierarchie existiert. Auf der obersten Ebene dieser Anforderungshierarchie werden in der Regel allgemeine Produktziele verankert, die in der folgenden Ebene, der Ebene der Kundenfunktionen, dann konkretisiert werden. Der Eintritt in das V-Modell geschieht genau an dieser Hierarchiestufe, an der die Anforderungen der Benutzer oder der Kunden an die Fahrzeugfunktion formuliert werden. Ergänzend zu dieser „vertikalen“ Struktur von Anforderungen können diese auch thematisch in Kategorien gegliedert werden. Häufig wird zwischen funktionalen und nichtfunktionalen Anforderungen unterschieden. Unter die funktionalen Anforderungen fallen

Analyse der Anforderungen, „Anforderungsentwicklung“

Erhobene Anforderungen

Konsolidierung der Anforderungen an die Fahrzeugfunktion

Spezifikation der logischen SA

Konsolidierung der Anforderungen an die technische SA

Ableitung der Anforderungen an die technische SA aus der logischen SA

Spezifikation der technischen Systemarchitektur

Aktorik/Sensorik

Konsolidierung der Anforderungen an die Komponenten

Konsolidierung der Anforderungen an die SW-Architektur

Konsolidierung der Anforderungen an die SW-Komponenten

Konsolidierung der Anforderungen an die Implementierung

Spezifikation der Spezifikation der Spezifikation Komponenten Komponenten der Systemkomponenten

Steuergeräte-Hardware Steuergeräte-Software

Spezifikation der SW-Architektur

Spezifikation der SWKomponenten

Design und Implementierung der SW-Komponenten

Abb. 1.9 Detaillierung des linken Asts des V-Modells: SA Systemarchitektur, SW Software, HW Hardware

18

1 Funktions- und Softwareentwicklung

Anforderungsseite

Lösungsseite

Erhobene Anforderungen der Kategorie A (z. B. an Funktionalität) Konsolidierung der Anforderungen Erhobene Anforderungen der Kategorie B (z. B. an Kosten)

...

Entwickelte Lösung

Ableitung der Anforderungen an die nächste tiefere Ebene ...

Abb. 1.10 Gegenüberstellung von Anforderungs- und Lösungsseite

dabei sowohl die Anforderungen an das gewünschte Sollverhalten als auch die Anforderungen an das nicht erlaubte Verhalten, d. h. an das, was die Funktion im Fehlerfall nicht tun darf. In diesem Kontext werden in der Regel auch die Sicherheits-, Zuverlässigkeitsund Verfügbarkeitsanforderungen angesiedelt. Unter den nichtfunktionalen Anforderungen werden typischerweise Kosten-, Termin-, Qualitäts- oder strategische Anforderungen verstanden. Zu der letzten Kategorie gehören etwa die Anforderungen, offene Standards einzusetzen (siehe Abschn. 1.2.2) oder Gleichteilkonzepte umzusetzen, wie z. B. gleiche Softwarekomponenten für mehrere Projekte. Wie in Abb. 1.10 dargestellt, startet der Anforderungsmanagementprozess auf jeder Ebene mit einer Erhebungsphase. In dieser Phase werden alle Anforderungen gesammelt, um im nächsten Schritt konsolidiert zu werden. Unter Konsolidierung wird dabei das Anwenden definierter Gütekriterien für Anforderungen, wie z. B. die Konfliktfreiheit, verstanden (siehe Abschn. 1.4.1). Im Idealprozess liegt nach diesem Schritt ein qualitativ hochwertiges Anforderungsgerüst vor, das durch verschiedene Lösungen erfüllt werden kann. Im realen Prozess wird häufig die Lösungsebene mitbetrachtet, da Anforderungskategorien wie Kosten, Qualität oder Terminsituation nur unter Berücksichtigung von Aspekten der jeweiligen Lösung zielkonfliktfrei gestaltet werden können. Nach Abschluss der Konsolidierungsphase wird die Lösung spezifiziert. Dieser Schritt wird häufig auch als „Anforderungsentwicklung“ bezeichnet. Die erarbeitete Lösung generiert dabei neue Anforderungen für die nächst tiefer liegende Entwicklungsebene. Zusätzlich zu diesen „abgeleiteten“ Anforderungen sind in der Regel noch Anforderungen aus derselben Ebene zu berücksichtigen (siehe Abb. 1.9). Bedingt durch die Top-down-Struktur des V-Modells werden die Anforderungen beim „Abstieg“ entlang des linken Astes zunehmend lösungsnäher, bis die Stufe des Komponentendesigns und der Implementierung erreicht ist.

1.3

Funktions- und Softwareentwicklung nach dem V-Modell

19

Neben der bereits erläuterten vorteilhaften Trennung in „was“ und „wie“ erlaubt der konsequente Einsatz von Anforderungsmanagement auch eine schlüssige Zuordnung von Anforderungen zu Lösungsanteilen. Insbesondere bei komplexen Systemen bleibt dadurch zu jeder Zeit transparent, durch welche Anforderungen das Entwicklungsergebnis seine Ausprägung erhalten hat. Ergänzend liefert das Anforderungsmanagement wertvolle Informationen für die parallel zur Entwicklung ablaufenden Prozesse des Projektund Änderungsmanagements, da mit jeder Anforderung auch der Anforderer erfasst und dokumentiert wird. Auf die während des Anforderungsmanagements eingesetzten Detailprozesse, Methoden und Werkzeuge wird nachfolgend noch ausführlich eingegangen (siehe Abschn. 1.4.1).

1.3.3

Architekturfestlegung

Spezifikation der logischen Systemarchitektur Wie aus Abb. 1.9 ersichtlich, folgt auf den Schritt der Anforderungskonsolidierung in der obersten Ebene des V-Modells die Spezifikation der logischen Systemarchitektur. Dieser Prozessbaustein wird häufig auch als Spezifikation der Funktionsarchitektur oder des Funktionsnetzwerks bezeichnet (vgl. [Sc1]). Zielsetzung dieses Schrittes ist es, die konsolidierten Anforderungen an die Fahrzeugfunktion in ein Funktionsmodell und damit in eine abstraktere Darstellungsform zu überführen. In dem Funktionsmodell werden die gewünschten Teilfunktionen geeignet strukturiert und gruppiert, sodass ihre Vernetzung deutlich wird. Je nach Detaillierungsgrad der logischen Systemarchitektur können an dieser Stelle auch die logischen Signale, die die Kommunikation der einzelnen Funktionen beschreiben, spezifiziert werden. Zur Verdeutlichung dieses Prozessschrittes werden in Tab. 1.3 die Kundenanforderungen an eine einfache Funktion zur automatischen Fahrgeschwindigkeitsregelung (auch Tempomat genannt) auszugsweise formuliert und jeweils mit einer eindeutigen Kennung (ID) versehen. Diese Anforderungen münden in die in Abb. 1.11 dargestellte logische Systemarchitektur. Diese gliedert sich grob in einen Erkennungsteil, eine Zustandssteuerung und die eigentliche Fahrgeschwindigkeitsregelung. Die Erkennungsebene wertet alle relevanten Eingangssignale aus und leitet daraus zum einen den Fahrerwunsch hinsichtlich des Aktivierungszustandes und andererseits die aktuelle Situation der beteiligten Aggregate ab. Diese zwei zentralen Informationen gehen in die Zustandssteuerung ein, die den Status der Funktion (z. B. „aus“, „aktiviert“ oder „regelnd“) festlegt. Das kontinuierliche Einregeln der Fahrzeuggeschwindigkeit wird über den Block „Fahrgeschwindigkeitsregelung“ abgebildet, der hierzu in das Motor- und das Getriebemanagement eingreift. Schließlich erhält der Fahrer eine optische Rückmeldung durch den Block „Anzeige“.

20

1 Funktions- und Softwareentwicklung

Tab. 1.3 Kundenanforderungen an eine automatische Fahrgeschwindigkeitsregelung (Auszug) Kennung

Anforderung

Anforderer

1.1

Die Funktion muss durch ein Bedienelement („Einschalter“) aktiviert werden können

Schulz

1.2

Bei Betätigung der Bremse muss die Funktion ohne merkliche Verzögerung deaktiviert werden

Müller

1.3

Bei Aktivierung der Funktion wird die zu diesem Zeitpunkt aktuelle Fahrzeuggeschwindigkeit als Sollgeschwindigkeit gesetzt

Meyer

1.4

Die gesetzte Sollgeschwindigkeit ist mit einer Genauigkeit von … auto- matisch einzuregeln

Meyer

Anf. 1.2

Auswertung der Pedale

Anf. 1.1

Bedienung

Erfassung und Plausibilisierung des Fahrerwunsches

Auswertung der Getriebesituation Auswertung der Fahrzeugsituation

Auswertung der Motorsituation

Erfassung und Plausibilisierung der Fahrzeug- und Umweltsituation

Zustandssteuerung Fahrgeschwindigkeitsregelung

Anzeige

Motormanagement

Getriebemanagement

Abb. 1.11 Logische Systemarchitektur einer automatischen Fahrgeschwindigkeitsregelung (Anf. Anforderung gemäß Tab. 1.3)

Zentrales Merkmal der logischen Systemarchitektur ist die Unabhängigkeit von der realen technischen Ausprägung. Sie entspricht der in Abb. 1.2 angeführten funktionalen Sicht. Oft werden in Abhängigkeit von dem relevanten Detaillierungsgrad in dieser Sicht auch die logischen Signale festgelegt. In dem gewählten Beispiel wird aus Gründen der Übersichtlichkeit darauf verzichtet. Der Zusammenhang zwischen Anforderungs-

1.3

Funktions- und Softwareentwicklung nach dem V-Modell

21

und Lösungsseite wird in Abb. 1.11 durch die beispielhafte Zuordnung zweier Anforderungen (Anforderung 1.1 und Anforderung 1.2, vgl. Tabelle 1.3) zu den jeweiligen Funktionsblöcken verdeutlicht.

Spezifikation der technischen Systemarchitektur Die technische Systemarchitektur wird aus den konsolidierten Anforderungen auf dieser Ebene gemäß Abb. 1.9 entwickelt. Dabei spielen neben den funktionalen und strukturellen Anforderungen aus der logischen Systemarchitektur auch realisierungsnahe Anforderungen wie z. B. das gewünschte Echtzeitverhalten eine Rolle. Ergänzend müssen in der Regel auch Anforderungen bezüglich Gleichteilstrategien von Steuergeräten oder Konfigurationsanforderungen wie z. B. die Zuordnung der Funktion zu einer Sonderausstattung berücksichtigt werden. Auch die für diese Ebene relevanten Aspekte der Sicherheit, Zuverlässigkeit und Verfügbarkeit (siehe Abschn. 1.1.4 und 9.1) werden an dieser Stelle berücksichtigt. Die technische Systemarchitektur legt die beteiligten Steuergeräte und deren technische Verknüpfung fest. Letztere beinhaltet das verwendete Bussystem, aber auch die Zuordnung der logischen Signale, die im Rahmen der logischen Systemarchitektur spezifiziert werden, zu den Botschaften, die auf dem jeweiligen Bus gesendet werden sollen. Als weiterer wesentlicher Festlegungsumfang wird in der technischen Systemarchitektur die Zuordnung der Funktionen zu den Steuergeräten definiert, wie in Abb. 1.2 beschrieben. In Abb. 1.12 ist eine mögliche technische Systemarchitektur für die automatische Fahrgeschwindigkeitsregelung dargestellt. Das Steuergerätenetzwerk besteht aus Motor- und Getriebesteuerung, die durch eine CAN Verbindung miteinander kommunizieren. Die Kopplung an den zweiten betroffenen Fahrzeugfunktionsbereich geschieht über ein Gateway, das die Verbindung zu den zwei weiteren Steuergeräten sicherstellt. Ergänzend sind in der Abbildung die Funktionen „Zustandssteuerung“ und „Bedienung“ den relevanten technischen Elementen beispielhaft zugeordnet.

Spezifikation der Softwarearchitektur Mit dem Übergang im V-Modell von der System- zur Komponentenebene erfolgt wie in Abschn. 1.3.1 beschrieben die Aufgliederung in mehrere Teilprozesse, die bei der Systeminte- gration auf dem rechten Ast des V-Modells später wieder vereinigt werden. Konzentriert man sich auf den Betrachtungsumfang der Steuergeräte-Software, so ist der folgende Schritt im V-Modell die Spezifikation der Softwarearchitektur in einem Steuergerät. Unter der Softwarearchitektur wird dabei die Strukturierung und Vernetzung der Softwaremodule verstanden. Diese Festlegungen umfassen daher die Schnittstellen zwischen den Modulen und diejenigen zur Außenwelt. Neben den aus der technischen Systemarchitektur abgeleiteten Anforderungen müssen an dieser Stelle häufig auch Anforderungen übergreifender Stan- dards oder firmeninterner Softwarestandards berücksichtigt werden.

...

...

...

Motorsteuerung

Pos. Wählhebel

Zustandssteuerung

Bremsschalter

1 Funktions- und Softwareentwicklung

Gaspedal

22

Getriebesteuerung

Gateway

CAN Antriebsstrang CAN Instrumentierung

Kombiinstrument

...

Bedienung

Hebel „Ein“

Steuergerät für Bedienelemente

Abb. 1.12 Technische Systemarchitektur einer automatischen Fahrgeschwindigkeitsregelung (Pos. Position)

Die Softwarearchitektur orientiert sich in der Regel an einem Schichtenmodell. Kerngedanke der vertikalen Schichtung von Software ist es, einen hierarchischen Aufbau zu gewährleisten, in dem die höhere Schicht jeweils auf die Funktionen der niedrigeren Schichten zurückgreifen kann. Ein typisches Beispiel für eine solche Struktur ist das ISO/OSI-Schichtenmodell, das zur Beschreibung von Kommunikationssystemen dient (vgl. Abschn. 1.1.2). Auch der in Abschn. 2.2 beschriebene OSEK/VDX-Standard ist als Schichtenmodell ausgeführt. Neben der beschriebenen Festlegung der Struktur wird in der Phase der Softwarearchitektur- Festlegung auch definiert, welche Betriebszustände für die Software relevant sind und wie die Übergänge zwischen den einzelnen Zuständen sind. Typische Zustände sind z. B. des „Fahr- programm“, in dem die Software ausgeführt wird oder der „Nachlauf“, in dem ein Steuergerät nach Ausschalten der Zündung noch permanent zu sichernde Daten abspeichert.

1.3

Funktions- und Softwareentwicklung nach dem V-Modell

1.3.4

23

Komponentenfestlegung

Spezifikation der Softwarekomponenten Die Spezifikation der Softwarekomponenten kann nach [Sc1] in drei Teilschritte zerlegt werden, nämlich die Festlegung des Daten-, des Verhaltens- und des Echtzeitmodells. Der erstgenannte Schritt umfasst die Festlegung der zu verwendenden Datenstrukturen, ohne deren konkrete Implementierung zu definieren. Eine typische Festlegung in diesem Zusammenhang ist die Dimension einer Variablen (z. B. Skalar, Vektor oder Matrix). Der zweitgenannte Schritt, die Festlegung des Verhaltensmodells, dient zur Beschreibung, wie die Daten verarbeitet werden. Die Datenverarbeitung beinhaltet den Datenfluss (z. B. Rechenoperationen) und den Kontrollfluss (z. B. Schleifenoperationen). Für die Festlegung und Dokumentation des Verhaltensmodells können unterschiedliche Methoden und Werkzeuge heran- gezogen werden. Häufig wird das Verhaltensmodell zusammen mit dem Datenmodell grafisch mithilfe eines Simulationswerkzeugs spezifiziert. Im dritten Teilschritt der Spezifikation der Softwarekomponenten wird das Echtzeitverhalten der Komponente definiert. Hierzu werden die auszuführenden Anweisungen der Softwarekomponente zu Prozessen zugeordnet, die zu Tasks zusammengefasst werden (vgl. Abschn. 2.1.1). In der Regel existieren „langsame Tasks“, also Tasks, die in größeren Zeitabständen berechnet werden und „schnelle Tasks“, die für zeitkritischere Berechnungen herangezogen werden können. Durch diese Zuordnung wird das Zeitverhalten der Softwarekomponente definiert. Ergänzend muss an dieser Stelle auch die Abarbeitungsreihenfolge der einzelnen Anweisungen der Komponente festgelegt werden, da die Reihenfolge, in der der Datenfluss verarbeitet wird, Einfluss auf das Rechenergebnis hat. Da es schon für das einzelne Steuergerät üblich ist, dass Softwarekomponenten nicht aus einer Hand, sondern von unterschiedlichen Abteilungen eines Unternehmens bis hin zu unterschiedlichen entwickelnden Unternehmen entstammen, ist die Komponentenspezifikation häufig ein stark arbeitsteiliger Prozess.

Komponenten-Design und Implementierung In diesem Schritt im V-Modell wird die Softwarelösung schließlich vollständig konkretisiert. Konkretisierung bedeutet in diesem Zusammenhang, dass die implementierungsunabhängige Darstellung in eine mikroprozessornahe Lösung überführt wird. Wie in Abb. 1.9 dargestellt, müssen auch auf dieser Ebene Anforderungen berücksichtigt werden, die die funktionalen Anforderungen aus der nächst höheren Ebene ergänzen. Hierzu zählen z. B. Anforderungen, die aus dem Speicherkonzept der Prozessorplattform herrühren oder Anforderungen, die die Konfiguration der Software betreffen. An dieser Stelle wird auch die in Abschn. 1.1.3 angesprochene Trennung in Programmund Datenstand vorgenommen. Dem Datenstand werden alle Parameter zugeordnet, die zur Anpassung der Algorithmen dienen und in nachfolgenden Prozessschritten appliziert werden sollen. Unter Applikation wird dabei das Festlegen der Werte von Parametern

24

1 Funktions- und Softwareentwicklung

verstanden. Die Motivation zur Verwendung von Parametern kann dabei unterschiedlich sein. Ein typischer Beweggrund ist etwa, dass ein funktionaler Zusammenhang nicht analytisch abgebildet werden kann. In diesem Fall wird die „Modellierung“ durch Kennlinien vorgenommen, die während des Applikationsprozesses in der Regel in der realen Systemumgebung zur Erzielung der gewünschten Wirkung eingestellt werden. Häufig werden Softwareblöcke auch durch applizierbare Parameter konfiguriert. So ist es häufig zweckmäßig, die Algorithmen möglichst generisch für mehrere Anwendungsfälle, z. B. für Vier-, Sechs- und Achtzylindermotoren auszulegen, und dann für den konkreten Anwendungsfall nur die benötigten Anteile „frei zu schalten“. Der Nachteil, der durch den zusätzlich benötigten Speicherplatz des nicht genutzten Codes entsteht, wird durch die Vorteile hinsichtlich Test und Absicherung von nur einer Funktion häufig mehr als aufgehoben. Dieses Verfahren kann auch angewendet werden, um die Software für bestimmte Betriebszustände wie einen speziellen Testmodus zu konfigurieren. Neben der erläuterten Trennung in Programm- und Datenstand erfolgt in der Designund Implementierungsphase auch die konkrete Abbildung des Datenmodells auf eine prozessorspezifische Speicherarchitektur. Hierunter fallen z. B. die Festlegung der Quantisierung und die Zuordnung zu dem notwendigen Speichertyp (flüchtig, nichtflüchtig etc.). Das Verhaltensmodell, das z. B. in Form eines grafisch modellierten Datenflusses vorliegt, wird an dieser Stelle unter Einsatz des notwendigen Werkzeugs und unter Beachtung der prozessorspezifischen numerischen Verarbeitung feinspezifiziert. In der Regel liegt nach Abschluss dieses Schrittes die Softwarekomponente in Form eines Quellcodes in einer Hochsprache oder in einer maschinennahen Sprache vor. Ergänzt wird dieses Ergebnis durch Konfigurationen des Echtzeitbetriebssystems.

Komponententest Mit dem Schritt des Komponenten-Designs und der Implementierung ist der linke Ast des V-Modells vollständig durchschritten. Ab hier beginnt eine schrittweise Integration der Komponenten und Subsysteme, die jeweils von Testaktivitäten auf der jeweiligen Ebene flankiert wird. Der erste dieser Schritte auf dem rechten Ast des V-Modells ist der Komponententest, der bei reiner Betrachtung der Softwareumfänge in dem Test von Softwarekomponenten be- steht. Analoge Aktivitäten finden bei den parallel ablaufenden V-Modellen für die Steuergeräte und für die Aktorik und die Sensorik statt. Hier wird ebenfalls von Komponententests oder Modultests gesprochen. Wie in Abb. 1.8 durch den waagerechten Pfeil dargestellt, greift der Komponententest auf die Anforderungen an die Komponente und die Spezifikation der Komponente zurück. Zurückgreifen bedeutet hier, dass aus den Anforderungen und aus der Spezifikation die Testfälle für den Komponententest abgeleitet werden. Ein Testfall beinhaltet dabei immer die Festlegung der zu variierenden Eingangsparameter einer Softwarekomponente, der einzuhaltenden Randbedingungen und das geforderte Verhalten der Ausgangsgrößen. Auf die verschiedenen methodischen Ansätze, die in diesem Zusammenhang eingesetzt werden können, wird in Abschn. 1.4.2 noch ausführlich eingegangen.

1.3

Funktions- und Softwareentwicklung nach dem V-Modell

Spezifikation der Softwarekomponenten

Testfälle

25

Test der Softwarekomponenten

Änderungen aufgrund von Testergebnissen Design und Implementierung der Softwarekomponenten

Abb. 1.13 Iteratives Durchlaufen des V-Modells (unterer Teil)

Obwohl der idealtypische Ablauf des V-Modells jeweils eine rein sequentielle Abarbeitung auf dem linken und rechten Ast suggeriert, finden im realen Entwicklungsgeschehen nach Abarbeitung von Testschritten auch häufig Iterationsschritte statt. Ein Beispiel hierfür ist in Abb. 1.13 im Kontext des Komponententests angedeutet. Die Ergebnisse der Komponententests, und zwar insbesondere der nicht bestandenen Tests, führen in der Regel zu Korrekturen in der Spezifikation oder in der Implementierung, die dann erneut in den Testprozess ein- fließen.

1.3.5

Integration

Software-Integration Wie dargestellt, werden auf der untersten Ebene des V-Modells die einzelnen Softwarekomponenten implementiert und nachfolgend getestet. Um zu einem ablauffähigen Gesamtprogramm- und Datenstand zu kommen, ist der nächste Schritt die Integration der Komponenten. In die- sem Teilprozess werden alle Softwarekomponenten zusammengeführt und zu einem Softwaregebilde vereinigt, das auf einem Mikroprozessor ausführbar ist. Dabei werden die in der Softwaretechnik üblichen Schritte des Compilierens, Assemblierens und Linkens ausgeführt (vgl. auch [Br2]). Ergänzend werden an dieser Stelle auch Standarddokumentationen und so genann- te Beschreibungsdateien erzeugt. Letztere liefern die notwendigen Informationen für Produkti- ons- und Servicewerkzeuge oder Messund Kalibriertools und basieren häufig auf standardi- sierten Formaten wie etwa dem ASAM-Standard (vgl. Abschn. 1.2.2). Begleitet wird der Integrationsprozess durch Software-Integrationstests. Darunter sind Testverfahren zu verstehen, die in der Regel toolgestützt ablaufen und dafür sorgen, dass die Kompatibilität der Softwarekomponenten untereinander und die korrekte Abbildung auf die Mikroprozessorplattform, insbesondere auf die Speicherkonfiguration, gewährleistet sind.

26

1 Funktions- und Softwareentwicklung

Systemintegration Mit dem Abschluss der Software-Integration liegt ein ausführbarer Programm- und Datenstand vor, der im nächsten Aufwärtsschritt im V-Modell, in der Systemintegration, weiter integriert wird. Dazu erfolgt zunächst die Zusammenführung aller Komponenten eines Steuergerätes, also Steuergeräte-Software und Steuergeräte-Hardware. Dazu werden Programm- und Datenstand auf den Programm- und Datenspeicher des Steuergerätes, das als Real- oder Experimentalsystem vorliegen kann, übertragen. Nachfolgend findet in der Regel eine Inbetriebnahme des „geflashten“ Steuergerätes in einer Experimentalumgebung statt, um sicherzustellen, dass der Downloadvorgang korrekt abgelaufen ist. Je nach Vernetzungsgrad des Systems findet dieser Integrationsschritt für ein oder mehrere Steuergeräte statt. Zur Komplettierung der Systemintegration ist es nach erfolgreicher Steuergeräteintegration notwendig, die fehlenden Systembestandteile, nämlich die Aktoren und Sensoren, zu ergänzen. Vor dem Hintergrund der häufig hohen Komplexität und der firmenübergreifenden, arbeitsteiligen Entwicklung gewinnt dieser Schritt bei der Entwicklung von Fahrzeugfunktionen zunehmend an Bedeutung. Grundsätzlich könnte dieser Prozessschritt in der realen Zielfahrzeugumgebung erfolgen. Angesichts hoher Fahrzeugprototypenkosten und steigender Gesamtvernetzung ist es in der Regel sinnvoller, das zur Darstellung der Fahrzeugfunktion notwendige System in einer Experimentalkonfiguration zu integrieren und zu testen, bevor die Gesamtfahrzeugintegration durchgeführt wird. Diese Systemintegration kann auch vorteilhaft zur Abnahme von gelieferten Komponenten genutzt werden (vgl. [Sc1]). Die konkrete Ausprägung der Experimentalkonfiguration stellt dabei in der Regel eine größere Herausforderung dar, da die richtige Mischung aus realen und virtuellen Komponenten gefunden werden muss. Aufgrund der Tatsache, dass das zu integrierende System nur einen Ausschnitt aus dem vollständigen Fahrzeugsystem darstellt, muss das Verhalten jenseits der Systemgrenzen geeignet nachgebildet werden. Beispielhaft ist in Abb. 1.14 eine mögliche Konfiguration für die automatische Fahrgeschwindigkeitsregelung dargestellt. In dieser Konfiguration werden die Kernelemente durch die realen Steuergeräte dargestellt und die verbleibenden Umfänge durch entsprechende Modelle abgebildet. Der Botschaftsverkehr zu und von den anderen Fahrzeugfunktionsbereichen wird durch sogenannte „Restbussimulationen“ simuliert, die teilweise durch einfache Fahrzeugmodelle gespeist werden. Da das Motorverhalten nicht Schwerpunkt der Funktion ist, aber trotzdem Einfluss hat, werden die Aktoren und Sensoren des Motors mithilfe eines einfachen Motormodells nachgebildet. Integration und Integrationstest gehen in dieser Entwicklungsphase eng verknüpft einher. Die Testfälle für den Systemintegrationstest können aus den korrespondierenden Schritten des linken Astes im V-Modell abgeleitet werden.

1.3

Funktions- und Softwareentwicklung nach dem V-Modell

27

Fahrzeugmodell

...

KWG

Bremsschalter

Gaspedal

Motormodell

Restbussimulation Motorsteuerung

Getriebesteuerung Restbussimulation

Gateway CAN Antriebsstrang

CAN Instrumentierung Restbussimulation Kombiinstrument

...

Hebel „ein“

Steuergerät für Bedienelemente

Abb. 1.14 Konfiguration zur Systemintegration und zum Test der automatischen Fahrgeschwindigkeits- regelung, gestrichelte Blöcke werden virtuell durch ein Experimentalsystem nachgebildet: KWG Kurbelwellengeber

1.3.6

Applikation

Unter der Applikation (Parametrierung, Kalibrierung) wird die Feinabstimmung und Konfigu- ration der Softwarefunktionen verstanden. Je nach Charakter der zu applizierenden Funktion kann dieser Teilprozess geringere oder auch größere Aufwendungen verursachen. In der Regel verlangen Funktionen, die das Fahrzeugerlebnis prägen, wie z. B. Fahrverhaltensfunktionen aus dem Funktionsbereich Antrieb, eine intensive Abstimmung. Diese Funktionen müssen auch häufig subjektiv geprägte Anforderungen erfüllen, da sie die Wahrnehmung der Marke durch den Kunden wesentlich beeinflussen. Da das Gesamtverhalten der Funktion in der realen Umgebung abgestimmt werden soll, können viele Applikationsumfänge nur direkt im Fahrzeug bearbeitet werden. Angesichts

28

1 Funktions- und Softwareentwicklung

des expandierenden Umfangs von Softwarefunktionen und des damit einhergehenden steigenden Applikationsumfangs werden aber auch zunehmend Methoden zur Vorapplikation an Prüfständen oder mittels werkzeuggestützter Verfahren auf Basis von Erfahrungswerten vorheriger Projekte eingesetzt.

1.3.7

Abnahme

Bei der Erläuterung der einzelnen Schritte des V-Modells ist deutlich geworden, dass die Entwicklung einer Fahrzeugfunktion eine Reihe von differenzierenden und integrierenden Schritten beinhaltet, die in wechselnden Entwicklungsumgebungen mit intensiver Arbeitsteilung stattfinden. Ein Teil der Prozesse stützt sich dabei auf Modelle und ist damit von den realen Gegebenheiten abstrahiert. Ergänzend sind hierarchisch organisierte Anforderungsprozesse durchzuführen, die sich von der obersten Ebene der Benutzeranforderungen bis hin zur konkreten Lösung auf Komponentenebene erstrecken. Insgesamt beherbergt der Entwicklungsprozess also eine Reihe von Vereinfachungen, Unschärfen und letztendlich auch Fehlerquellen. Die Tatsache, dass bei komplexen Fahrzeugfunktionen eine Reihe von Ebenen im V-Modell durch- laufen wird, führt auch zu einer Distanz zwischen den Benutzeranforderungen und den Lösungen auf der untersten Ebene. Aus diesen Gründen spielt der letzte Prozessschritt auf dem rechten Ast des V-Modells, die Abnahme, eine entscheidende Rolle. Bei diesem Schritt wird in der realen Fahrzeugumgebung und im Fahrversuch getestet, ob die Funktion die Anforderungen erfüllt. An dieser Stelle wird also zum letzten Mal die Querbeziehung zwischen dem absteigenden und dem aufsteigenden Ast des V-Modells genutzt, indem aus den Kundenanforderungen Testfälle für den Akzeptanztest abgeleitet werden. Das Ergebnis aus dem Abnahmetest ist die Freigabe für die entwickelte und parametrierte Funktion.

1.4

Methoden in der Funktions- und Softwareentwicklung

Während der vorangegangene Abschnitt dazu dienen sollte, den Entwicklungsprozess von Fahrzeugfunktionen beim Durchschreiten des V-Modells zu erläutern, werden im Folgenden ausgewählte Methoden, die bei den jeweiligen Prozessschritten zum Einsatz kommen, näher erklärt. Als Schwerpunktthemen werden Anforderungsmanagement und Testmethoden behandelt. Der Fokus liegt dabei auf den für den Bereich der Funktions- und Softwareentwicklung relevanten Aspekten und weniger auf der Behandlung vollständiger mechatronischer Systeme. Ergänzend sei erwähnt, dass grundsätzlich Methode und Prozess eng thematisch verzahnt sind. Deshalb werden Prozessaspekte, soweit sie zum Gesamtverständnis notwendig sind, nicht vollständig ausgespart. Auf eine vertiefte Darstellung der methodischen Ansätze zur Begleitung der geschilderten Architektur- und Komponentenprozesse wird in

1.4

Methoden in der Funktions- und Softwareentwicklung

29

diesem Abschnitt verzichtet. Hierzu sei auf die einschlägige Literatur verwiesen (z. B. [Ba1], [Sc1] oder [Oe1]).

1.4.1

Anforderungsmanagement

Mit zunehmender Komplexität der Funktionen und der Systeme im Fahrzeug, aber auch vor dem Hintergrund negativer Erfahrungen mit gescheiterten Entwicklungsvorhaben in anderen Branchen, ist deutlich geworden, dass das systematische Erheben, Konsolidieren und Dokumentieren von Anforderungen ein wesentlicher Erfolgsfaktor ist (siehe hierzu [Ro1], [Ru1]). Diese Erkenntnis findet sich auch beispielsweise in dem in Abschn. 1.2.1 vorgestellten CMMI-Modell wieder, das in der stufenförmigen Ausprägung ab Level 2 ein Anforderungsmanagement fordert. Die Kernaspekte, die im Kontext des Anforderungsmanagements beachtenswert sind, sind in Abb. 1.15 dargestellt und werden in den nachfolgenden Abschnitten zum Teil noch ausführlich diskutiert. Neben der Erhebung und Konsolidierung der Anforderungen stehen dabei auch die so genannten Stakeholder im Mittelpunkt des Interesses. Darunter sind diejenigen Personen zu verstehen, die ein „berechtigtes“ Interesse an der Gestaltung des zu entwickelnden Systems haben. Als Vorstufe zu den Anforderungen benötigt jedes Projekt zur Entwicklung einer Fahrzeugfunktion klar umrissene und nach Möglichkeit messbar formulierte Ziele, die deshalb auch als wesentlicher Kernsaspekt angeführt sind. Als letzter Aspekt, der im Themenfeld Anforderungsmanagement zu nennen ist, ist in Abb. 1.15 der Systemumfang oder

Ziele

Stakeholder

Kernaspekte des Anforderungsmanagements

Anforderungen

Abb. 1.15 Kernaspekte des Anforderungsmnagements [Ru1]

Systemumfang, Kontext

30

1 Funktions- und Softwareentwicklung

Warum ?

Kunden- und Stakeholder-Anforderungen

Problembereich

Was?

Abgeleitete Anforderungen

Anforderungsbereich

System-, Architektur -, Komponenten-Design Wie?

Lösungsbereich Implementierung

Abb. 1.16 Abstraktionsebenen im Anforderungsmanagement

Kontext angeführt. Hierunter ist der Vorgang der Systemabgrenzung in der jeweiligen Abstraktionsebene zu verstehen.

Abstraktionsebenen Die Tatsache, dass der Anforderungsmanagementprozess über mehrere Ebenen hinweg den Entwicklungsprozess begleitet, wurde schon im Abschn. 1.3.2 im Zusammenhang mit dem V-Modell hervorgehoben. Die verallgemeinerte Form der Trennung zwischen Anforderungsseite und Lösungsseite wird in Abb. 1.16 erneut aufgegriffen und ergänzt, um die unterschiedlichen Abstraktionsebenen zu verdeutlichen. Die Anforderungen auf der höchsten Ebene, die schon mehrfach genannten Kundenanforderungen, werden in der Regel dem sogenannten Problembereich zugeordnet. Dieser Bereich verdankt seine Benennung der Tatsache, dass neue Systeme aufgrund von erkannten Defiziten oder bekannten Problemen entstehen. Er beantwortet somit die Frage: Warum wird das System entwickelt? In der nächst tieferen Ebene, in der bereits abgeleitete Anforderungen vorkommen, findet im Anforderungsbereich die Beantwortung der Frage „Was soll das System leisten?“ statt. Wie in Abb. 1.9 illustriert, beginnt ab dieser Ebene das z-förmige Wechselspiel zwischen Anforderungs- und Lösungsbereich, das in Abb. 1.16 nochmals zusammenfassend angedeutet ist.

Vereinfachter, allgemeiner Anforderungsdefinitionsprozess In den Abb. 1.9 und 1.10 wurde der Prozess zur Definition von Anforderungen auf die zwei Schritte Erhebung und Konsolidierung verdichtet. Bei differenzierterer Betrachtung lässt sich die Konsolidierung aus drei Teilschritten zusammensetzen, die in Abb. 1.17 dargestellt sind. Im ersten Schritt des vereinfachten Anforderungsdefinitionsprozesses findet das „Einsammeln“ von Anforderungen statt, das sich aus Erhebungen von Stakeholdern (siehe

1.4

Methoden in der Funktions- und Softwareentwicklung

31

Review, Prüfung

Erhebung Ableitung

Analyse Verhandlung

Modellierung Dokumentation

ID Spezifikation

Freigegebene, akzeptierte Anforderung

Konsolidierung

Abb. 1.17 Vereinfachter, allgemeiner Anforderungsdefinitionsprozess [Ru1]: ID eindeutige Identifizie- rung der Anforderung

unten) und der Ableitung aus höheren Ebenen zusammensetzt. Werden bestehende Systeme ergänzt oder optimiert, so sind diese bestehenden Systeme und deren Anforderungsdokumente auch wesentliche Quellen zur Anforderungsermittlung. Die so gewonnenen Anforderungen werden im Folgeschritt strukturiert und analysiert, um Widersprüche, Redundanzen und Unvollständigkeiten im Rohgerüst zu vermeiden. Zusätzlich erfolgt an dieser Stelle auch die Lösung von Anforderungskonflikten. Dieser Teilprozess wird durch den Titel „Verhandlung“ in der Abbildung ausgedrückt und bedeutet in der letzten Konsequenz, dass strittige Anforderungen bewertet und zur Entscheidung gebracht werden. Der nächste Teilschritt in der Anforderungsdefinition stellt die Modellierung und Dokumentation dar. Dabei werden die Anforderungen so abgebildet, dass sie zwar zur Ableitung von Lösungen hinreichend präzise sind, aber noch von den ursprünglichen Autoren der Anforderung verstanden werden. An dieser Stelle erfolgen auch erste Reviews und Überprüfungen der Anforderungen, deren Ergebnisse in die Vorgängerschritte eingespeist werden. Die modellierten und dokumentierten Anforderungen münden nach erfolgreicher Prüfung in eine Anforderungsspezifikation, die freigegebene und akzeptierte Anforderungen mit jeweils eindeutiger Kennzeichnung (ID) enthält. Die Anforderungsdokumentation erfolgt dabei häufig toolgestützt.

Stakeholder Als Stakeholder werden diejenigen Personen bezeichnet, die durch das betrachtete System oder die betrachtete Funktion betroffen sind. Damit gehören nicht nur die Entwickler des Systems zu den Stakeholdern, sondern auch Personen, die z. B. später mit dem Service betraut werden oder die Finanzierung der Entwicklung sicherstellen müssen. Da im Rahmen des Anforderungsmanagements jede Anforderung personifiziert dokumentiert werden

32

1 Funktions- und Softwareentwicklung

Tab. 1.4 Rollen von Stakeholdern. (Auszug, nach [Ru1]) Rolle

Erläuterung

Manager

Auftraggeber für die Entwicklung, trifft Entscheidungen bei Anforderungskonflikten

Fahrzeugkunde

Käufer des Fahrzeugs, für das die Funktion entwickelt wird (Anforderungen des Kunden werden häufig von Marketingabteilungen ermittelt)

Werkstattpersonal

Formuliert Anforderungen, die die Diagnosefähigkeit und Wartbarkeit des Systems betreffen

Entwickler

Steuert technologieorientierte Anforderungen ein, oftmals auf den lösungsnäheren Ebenen

Projektgegner

Hinter dem Widerstand von Projektgegnern verbergen sich häufig ernstzunehmende Anforderungen, die erschlossen werden sollten

Sicherheitsbeauftragter

Formuliert Anforderungen, die die Sicherheit des Systems betreffen

Controller

Bringt Anforderungen ein, die die finanziellen Rahmenbedingungen des Projektes betreffen

muss und die Vollständigkeit des Anforderungsgerüstes auch signifikant von der Vollständigkeit der befragten Stakeholder abhängt, kommt dem Prozess der Stakeholderermittlung hohe Bedeutung zu. Liegt keine Stakeholderliste aus einem Vorgängerprojekt vor, so bleibt als einzige Möglichkeit, unter Nutzung der Projekterfahrung von relevanten Projektleitern eine erste Möglichkeit von Stakeholdern zu bilden. Die Stakeholder werden namentlich mit Erläuterung ihrer Rolle und Entscheidungsbefugnis erfasst. Zur Verdeutlichung sind in Tab. 1.4 typische Rollen von Stakeholdern auszugsweise aufgelistet. Der Prozess der Stakeholderermittlung wird in der Regel nicht nur einmalig, sondern fortlaufend durchgeführt, da beim Durchschreiten der Ebenen des V-Modells neue Stakeholder betroffen sind oder identifiziert werden.

Charakterisierung und Qualitätsmerkmale von Anforderungen Für den Begriff einer Anforderung existiert eine Reihe von Definitionen (siehe [Ie1] oder [Ro1]), die jeweils unterschiedliche Aspekte unterstreichen. Eine anschauliche Definition, die für den thematischen Kontext dieses Kapitels geeignet ist, lautet [Ru1]: „Eine Anforderung ist eine Aussage über die Leistung eines Produktes, eines Prozesses oder der am Prozess beteiligten Personen“. Da für die Entwicklung komplexer Fahrzeugsysteme eine Vielzahl von Anforderungen berücksichtigt werden müssen, ist eine Strukturierung zwingend erforderlich. Hierzu hat es sich nach [Ru1] bewährt, die drei Hauptgruppen Art, Ebene und Priorität zu verwenden. Die Hauptgruppe „Art“ einer Anforderung ist identisch mit der in Abschn. 1.3.2 genannten thematischen Gliederung von Anforderungen. Typische Kategorien sind etwa

1.4

Methoden in der Funktions- und Softwareentwicklung

33

Tab. 1.5 Gütekriterien für Anforderungen (Auszug, nach [Ro1], [Ru1]) Merkmal

Erläuterung

Vollständigkeit

Der Anforderungssatz ist vollständig, d. h., er enthält Subjekt, Prädikat und Objekt. Die Informationen sind vollständig (z. B. kein „tbd.“, „to be done“)

Eindeutigkeit

Der Anforderungssatz ist für den betroffenen Leserkreis eindeutig, d. h., er enthält keinen Interpretationsspielraum. Benutzte Fachwörter sind definiert. Sogenannte „weak words“ wie z. B. „absolut“ oder „äußerst“ werden vermieden

Nachweisbarkeit

Die Anforderung kann durch Test oder Review verifiziert werden

Atomizität

Die Anforderung enthält genau eine Aussage

funktionale Anforderungen, Qualitätsanforderungen oder rechtliche Anforderungen. Die zweite Hauptgruppe zur Struktu- rierung von Anforderungen, nämlich die „Ebene“, ist schon anhand des V-Modells (Abb. 1.9) oder bei Betrachtung der Abstraktionsebenen des Anforderungsmanagements (Abb. 1.16) deut- lich geworden. Die dritte Hauptgruppe, die Systematisierung von Anforderungen nach Priori- tät, spiegelt eine gängige Praxis des Projektmanagements wider. Hierunter ist ein Bewertungsprozess zu verstehen, der jeder Anforderung einen „Stellenwert“ zuordnet. Dadurch werden Anforderungen, die notwendig zur Erreichung der Projektziele sind, von denjenigen separiert, die lediglich wünschenswert sind. Neben der Wahl der richtigen Struktur für die Dokumentation der Anforderungen kommt der sprachlichen Formulierung von Anforderungen, die vor der Modellierung häufig in Prosa er- folgt, hohe Bedeutung zu. Um die Qualität von Anforderungen zu sichern, hat es sich in die- sem Zusammenhang als vorteilhaft erwiesen, geeignet geschulte Mitarbeiter einzusetzen, oder den Entwicklungsprozess durch „Anforderungsmanager“ zu begleiten, die die Aussagen der befragten Stakeholder unter Beachtung von Gütekriterien ausformulieren. Beispiele für Gütekriterien sind in Tab. 1.5 aufgelistet.

Erhebung von Anforderungen Bei der Erhebung von Anforderungen ist neben der Auffindung der relevanten Stakeholder auch eine Reihe von weiteren Aspekten zu beachten. Ein Aspekt ist die Erhebungstechnik, also die Art und Weise, wie die Anforderungen im Dialog mit den Stakeholdern ermittelt werden. Sie muss an die Projektsituation, an die Erfahrungen des Anforderungsermittlers und der Stakeholder sowie an weitere Einflüsse angepasst werden. Nach [Ru1] ist auch beachtenswert, welche Bedeutung die Anforderungen für die Kundenzufriedenheit haben, da die Anforderungsermittlung und die Informationsbereitschaft der Stakeholder durch diese Einsortierung beeinflusst werden. Zur Kategorisierung der Produkteigenschaften wird häufig das Kano-Modell eingesetzt (siehe [Sa2]), das die Anforderungen in Basisfaktoren, Leistungsfaktoren und Begeisterungsfaktoren einteilt. Dabei werden unter Basisfaktoren selbstverständlich vorausgesetzte

34

1 Funktions- und Softwareentwicklung

Produkteigenschaften verstanden, die häufig in Vorgängerversionen des zu entwickelnden Systems schon enthalten sind und von Stakeholdern deshalb nicht explizit benannt werden. Leistungsfaktoren sind im Gegensatz dazu vom Kunden bewusst verlangte Eigenschaften und tragen deshalb stärker zur Kundenzufriedenheit bei. Diese Eigenschaften werden von Stakeholdern in der Regel direkt eingebracht. Als dritte Kategorie wird im Kano-Modell der Begeisterungsfaktor verwendet, der erst während der Produktnutzung durch den Kunden wahrgenommen wird. Produkteigenschaften dieser Kategorie werden im Rahmen der Anforderungserhebung häufig durch Kreativitätstechniken gewonnen. Beispiele für übliche Kreativitätstechniken, eingebettet in eine Gesamtübersicht über Ermittlungstechniken, die im Rahmen der Anforderungserhebung genutzt werden können, zeigt Abb. 1.18. Eine häufig eingesetzte Form der Anforderungsermittlung ist das Interview, das in Abb. 1.18 unter den Befragungstechniken eingeordnet ist. Wie bereits ausgeführt, ist es in der Regel sinnvoll, diese Methode durch geeignet qualifizierte Anforderungsmanager ausführen zu lassen, um die Erfüllung der genannten Qualitätsmerkmale sicherzustellen. Eine vollständige und formale Protokollierung der Interviewinhalte als Spezifikation ist hierbei selbstverständlich.

Ermittlungstechniken

Abb. 1.18 Ermittlungstechniken im Anforderungsmanagement. (Auszug, nach [Ru1])

...

Mind Maps

Unterstützende Techniken

Workshops

...

Vergangenheitsorient. Techniken

Reuse

...

Interview

Befragungstechniken

Fragebogen

...

Beobachtungstechniken

Feldbeobachtung

...

Wechsel der Perspektive

Brainstorming

Kreativitätstechniken

1.4

Methoden in der Funktions- und Softwareentwicklung

1.4.2

35

Testmethoden

Während der linke Ast des V-Modells durch Anforderungs- und Spezifikationsschritte geprägt ist, findet auf dem rechten Ast die Integration und der Test statt (siehe Abb. 1.8). Der Vorgang des Testens hat dabei nicht nur technische, sondern auch ökonomische, psychologische und organisatorische Facetten, die den Erfolg einer Entwicklung nachhaltig beeinflussen können (siehe hierzu auch [Br1] und [My1]). Die Schwerpunkte des Kapitels über Testmethoden werden dabei auf die Zuordnung zum V-Modell und damit auf die verschiedenen Testebenen, auf Verfahren zum Testfallentwurf sowie auf wesentliche Grundlagen und Prinzipien gelegt. Dies umfasst auch Aspekte der Psychologie, Ökonomie und Organisation. Auf die Betrachtung operativer Themenstellungen der Testdurchführung, des Ablaufs und der Auswahl geeigneter Testumgebungen wird im Rahmen dieses Kapitels verzichtet. Näheres hierzu findet man in [Br1], [De1] und [Sc1].

Grundbetrachtungen Die Kerngedanken des Testens werden durch folgende Begriffsdefinition deutlich [My1]: Testen ist ein Prozess, ein Programm mit der Absicht auszuführen, Fehler zu finden. Unter einem Programm wird im Kontext der Funktions- und Softwareentwicklung im Fahrzeug entweder eine Softwarekomponente oder ein integrierter Stand von Softwarekomponenten oder ein über mehrere Steuergeräte verteilter Umfang von Software verstanden. Entscheidend in der Definition ist die formulierte Absicht, Fehler zu finden und nicht etwa, den Nachweis zu führen, dass die Software fehlerfrei ist. In dieser gedanklichen Ausprägung ist der notwendige „destruktive“ Charakter, der dem Testen innewohnt, bewusst hervorgehoben. Als Schlussfolgerung ergibt sich, dass ein erfolgreicher Test dann vorliegt, wenn tatsäch-lich ein Fehler gefunden wurde. Bei konsequenter Weiterverfolgung dieses Gedankenganges liegt ebenfalls der Schluss nahe, dass es vorteilhaft sein kann, die „konstruktive“ Aufgabe des Entwicklers, also das Spezifizieren und Implementieren von der „destruktiven“ Aufgabe des Testens, personell zu trennen. Diese personelle und damit häufig auch organisatorische Trennung, die z. B. in der Bildung eines von der Entwicklung separierten „Testteams“ bestehen kann, wird auch als „Vier-Augen-Prinzip“ bezeichnet. Neben der soeben beschriebenen psychologischen Facette des Testens sind die in diesem Zusammenhang relevanten ökonomischen Aspekte ebenfalls von grundlegender Natur. Dies resultiert aus der Tatsache, dass es in der Regel kombinatorisch nicht möglich ist, selbst eine „einfache Funktion“, also eine Funktion geringer Komplexität, vollständig zu testen. Vollständig bedeutet in diesem Zusammenhang, dass alle Kombinationen der erlaubten, aber auch der unerlaubten Eingangsparameter der Funktion, einschließlich der zugehörigen „richtigen“ Ausgangsparameter getestet werden (vgl. [My1]). Da Entwicklungsprojekte hinsichtlich Zeit und Budget Begrenzungen unterliegen, ergibt sich aus dieser Erkenntnis der Zwang, die Testaktivitäten auf die richtigen Schwerpunkte

36

1 Funktions- und Softwareentwicklung

und damit auf die richtigen Funktionsumfänge auszurichten. Diese Schwerpunkte können dabei anhand verschiedener Kriterien abgeleitet werden. Die Kriterien orientieren sich zum einen an der Wahrscheinlichkeit, dass Fehler vorliegen, und zum anderen an dem Schadensausmaß, das bei „Übersehen“ eines Fehlers zu erwarten ist. Letzteres führt z. B. dazu, dass sicherheitsrelevante Funktionen häufiger und intensiver getestet werden als nicht sicherheitsrelevante Funktionen. Die Fehlerwahrscheinlichkeit kann z. B. aus dem Innovationsgrad, der Komplexität oder dem Vernetzungsgrad einer Funktion abgeschätzt werden. Ein Anhaltspunkt können in diesem Zusammenhang aber auch die Ergebnisse vorhergehender Tests des gleichen Softwareumfangs sein. Häufig deuten in einem bestimmten Teil einer Software gefundene Fehler darauf hin, dass in diesem Teil noch weitere Fehler zu erwarten sind. Sind die richtigen Schwerpunkte für die Testaktivitäten definiert, so ist als Folgefragestellung der geeignete Testansatz oder die geeignete Teststrategie zu wählen. Hierunter soll die Auswahl der passenden Methoden zur effektiven und effizienten Ermittlung und Durchführung der Testfälle verstanden werden. Häufig werden die relevanten Verfahren in statische und dynamische Verfahren unterteilt (siehe [Sc1]). Dabei umfassen die statischen Verfahren Tests, bei denen die Funktion nicht zum Ablauf gebracht wird, sondern die im Entwicklungsablauf entstehenden Dokumentationen untersucht werden. Demgegenüber beinhalten die dynamischen Testverfahren die Ausführung der Software in einer entsprechend gewählten Testumgebung.

Testfallentwurf für dynamische Tests Die wesentliche Fragestellung, die sich aus den Vorüberlegungen für erfolgreiche dynamische Tests ableitet, besteht darin, welche Untermenge aller denkbaren Testfälle die größte Wahrscheinlichkeit zum Finden möglichst vieler Fehler bietet. Zur Beantwortung dieser Frage können zwei grundsätzlich verschiedene Ansätze gewählt werden: der BlackboxTest und der White- box-Test. Der Wesensunterschied dieser zwei Ansätze besteht in dem unterschiedlichen Kenntnisgrad über die Interna der zu testenden Funktion. Der Blackbox-Test betrachtet den Testumfang als ein Objekt, von dem nur die Schnittstellen nach außen hin und das definierte Verhalten bekannt sind. Dieses Verhalten wird im Kontext des V-Modells in der Regel durch die Anforderungen beschrieben. Damit sind die gewählte Struktur oder die gewählten Algorithmen, die in der Spezifikation beschrieben sind, für den Blackbox-Test nicht bekannt. Ziel des Tests ist es, Abweichungen von den Anforderungen zu ermitteln. Im Gegensatz zum Blackbox-Test verwendet der Whitebox-Test bei der Definition der Testfälle explizit das Wissen über die innere Struktur und die Logik einer Funktion. Dabei orientiert sich dieser Testansatz an den in der Funktion vorhandenen logischen Pfaden. Nicht vorhandene, aber notwendige Pfade werden durch diesen Ansatz allerdings nicht entdeckt.

1.4

Methoden in der Funktions- und Softwareentwicklung

37

Beide Testansätze führen bei „vollständiger“ Anwendung in der Regel zu einer Explosion an Testfällen, da entweder die Kombinatorik der Eingangssignale und Ausgangssignale oder die Kombinatorik der internen logischen Pfade der Funktion zu berücksichtigen ist. Deshalb sind methodische Ansätze zur Reduktion im Sinne einer sinnvollen Auswahl der Testfälle notwendig. Bei der Anwendung des Blackbox-Tests kann diese Eingrenzung z. B. durch die Einführung von Äquivalenzklassen, durch Grenzwertanalyse oder durch die Verwendung von Ursache- Wirkungsgraphen vollzogen werden (vgl. [My1], [Wa1]). Der Whitebox-Ansatz kann durch verschieden „starke“ Kriterien, wie z. B. die Forderung nach Abdeckung aller Sprünge oder Bedingungen konkretisiert werden. Insgesamt empfiehlt es sich, sowohl Blackbox- als auch Whitebox-Tests zu einer gesamthaften Strategie für die Testfallableitung zu kombinieren. Alternativ oder ergänzend können auch Mischformen der beiden Ansätze gewählt werden. Man spricht dabei häufig von sogenannten Graybox-Tests.

Testverfahren für statische Tests Statische Testverfahren finden ohne tatsächlichen Ablauf der Funktion auf einem Steuergerät statt. Häufig werden diese Verfahren auch als „nicht Computer-unterstützte“ Verfahren bezeichnet. Eine der wesentlichen Motivationen für die Anwendung dieser Ansätze ist die allgemein akzeptierte Erkenntnis, dass die Fehlerbeseitigungskosten mit zunehmendem Fortschritt eines Projektes überproportional steigen. Bezogen auf den beschriebenen Ablauf im V-Modell ist es also vorteilhaft, bereits im linken Ast des V-Modells Fehler zu finden, bevor die Schritte der Implementierung und Integration ausgeführt werden. Typische statische Verfahren sind Code-Inspektionen, Walkthroughs und Peer Ratings oder Reviews, die in unterschiedlichen Detailausprägungen durchgeführt werden können (siehe hierzu [Br1] und [My1]). Zur Verdeutlichung der Kerngedanken soll an dieser Stelle auf die zwei erstgenannten Verfahren ausführlicher eingegangen werden. Sowohl Code-Inspektionen als auch Walkthroughs basieren auf dem Gedanken des „Vier- Augen-Prinzips“. Bei beiden Verfahren werden Design und Implementierung der Softwarekomponente in einem Team analysiert. Dieses Team sollte dabei neben dem Verantwortlichen für die Implementierung, also dem Autor der Software, auch einen Testspezialisten enthalten, der die beschriebene „destruktive“ Sichtweise einnimmt. Ergänzend hat es sich bewährt, den Analyseprozess, aber auch den anschließenden Fehlerbeseitigungsprozess durch einen erfahre- nen Moderator oder Qualitätsingenieur zu begleiten. Die Code-Inspektion erfolgt in einer konzertierten, vorbereiteten Sitzung des Teams und besteht darin, den Code Anweisung für Anweisung durchzugehen. Dieser Durchgang wird durch Erläuterungen des Software-Autors begleitet, der seine Software damit präsentiert. Vorteilhaft ist der Einsatz von Checklisten, die typische Fehler wie etwa fehlende Initialisierungen von Variablen oder Berechnungsfehler aufgrund von unterschiedlichen Quantisierungen enthalten.

38

1 Funktions- und Softwareentwicklung

Die für die Code-Inspektion beschriebene Grundkonstellation des Teams wird auch für den Walkthrough genutzt. Zur Ausweitung des „Vier-Augen-Prinzips“ und zur Integration alternativer Sichtweisen ist zusätzlich das Hinzuziehen von neuen Mitarbeitern oder Mitarbeitern anderer Projekte von Vorteil. Im Gegensatz zur Inspektion besteht der Walkthrough dann je- doch nicht in dem Durchgehen des Codes, sondern in dem gedanklichen Durchspielen von Testfällen. Dieses Vorgehen dient dazu, die kritische Auseinandersetzung mit der Komponente zu stimulieren. Code-Inspektion und Walkthrough leben einerseits von dem „destruktiven“ Blickwinkel des Testens und andererseits von den Effekten der Gruppendynamik. Wichtig für einen nachhaltigen Erfolg und für die Akzeptanz der Methode ist allerdings die richtige Balance zwischen dem Konkurrenzkampf um das Finden möglichst vieler Fehler und dem gemeinsamen Ziel, die Qualität der Software zu erhöhen, ohne dass der Software-Autor zum „Schuldigen“ wird. Die in diesem Abschnitt dargestellten statischen Verfahren sind aufgrund ihrer Herkunft vordringlich auf den untersten Ebenen des V-Modells angesiedelt. Grundsätzlich ist aber eine Übertragung von Teilaspekten dieser Ansätze auf höhere Ebenen im linken Ast des V-Modells problemlos möglich und vor dem Hintergrund der genannten Fehlerkostenzusammenhänge auch zielführend. So bietet sich auch für die Architekturprozesse der Einsatz von Reviews unter der Anwendung des „Vier-Augen-Prinzips“ an, um Fehler in dieser Entwicklungsphase rechtzeitig zu erkennen.

Tests auf den verschiedenen Ebenen des V-Modells Bereits bei der Darstellung des V-Modells in Abschn. 1.3 war deutlich geworden, dass sich sowohl das Anforderungsmanagement und die Spezifikation als auch die korrespondierenden Testschritte auf unterschiedlichen Abstraktionsebenen abspielen. Diese Struktur wird in Tab. 1.6 erneut aufgegriffen. Im Folgenden sollen die Testaktivitäten orientiert am V-Modell etwas ausführlicher beleuchtet werden. Der Komponententest dient dazu, Fehler in der implementierten Softwarekomponente zu finden. Hierzu wird in der Regel eine Mischung aus Blackbox- und Whitebox-Test eingesetzt. Während der Whitebox-Test unter Berücksichtigung der Spezifikation und des Designs der Komponente aufgesetzt wird, fokussieren sich die Anteile des Blackbox-Tests stärker auf das funktionale Verhalten, das in den Anforderungen formuliert ist. Eingebettet in einen Entwicklungsprozess, der sich stark auf virtuelle Komponenten, also Modelle abstützt, wird der Black- box-Komponententest häufig in einer entsprechenden Softwareumgebung durchgeführt, die alle notwendigen Stimulanzsignale durch entsprechende Modelle bereitstellt. Dieser Ansatz wird als „Software in the Loop“ (SIL) bezeichnet. Moderne Entwicklungswerkzeuge bieten in diesem Zusammenhang in der Regel zusätzlich die Möglichkeit, die grafisch spezifizierte Softwarekomponente auch direkt in einer Software-in- the-Loop-Umgebung zu testen. Diese Tests erlauben es, Fehler in der Spezifikation gemessen an den Anforderungen zu finden, machen jedoch keine Aussage bezüglich Fehler in der Implementierung.

1.4

Methoden in der Funktions- und Softwareentwicklung

39

Tab. 1.6 Testschritte im V-Modell. (Nach [Sc1]) Testebene

Testtyp

Erläuterung

Komponente

Komponententest Modultest

Test gegen Anforderungen an die Komponente und Spezifikation der Komponente

Integrierte Software oder Programmstand

Software-Integrationstest

Test gegen Anforderungen an die Softwarearchitektur und Spezifikation der Softwarearchitektur

Integriertes System

System-Integrationstest Systemtest

Test gegen Anforderungen an die logische und die technische Systemarchitektur und die zugehörigen Spezifikationen

Parametriertes System

Akzeptanztest

Test gegen die Benutzeranforderungen

In der nächsten Testebene werden nicht mehr einzelne Module, sondern die Zusammensetzung von Softwarekomponenten betrachtet, häufig bezogen auf ein Steuergerät und damit als Programmstand eines Steuergerätes. Der Schwerpunkt der an dieser Stelle durchgeführten Tests ist weniger funktional, sondern setzt mehr Schwerpunkte bezüglich Kompatibilität (siehe Abschn. 1.3.5). Bei der darauf folgenden Systemintegration und den korrespondierenden Systemtests ist der Fokus deutlich in Richtung Funktionalität ausgeprägt. Als Quelle für BlackboxTestfälle wird die logische und die technische Systemarchitektur herangezogen. Die Verwendung von White- box-Ansätzen ist dagegen an dieser Stelle eher unüblich. Ergänzende Aspekte und Anforderungen, die an dieser Stelle testbar sind, können etwa das Verhalten des Systems unter Belastungen verschiedener Art sein. Da hier in der Regel die Software auf der Zielhardware abläuft, ist es nämlich möglich, die Eigenschaften des Mikroprozessorsystems in die Tests mit einzubeziehen. Eine Belastung für eine Motorsteuerung kann z. B. in der Simulation der Maximaldrehzahl des Motors bestehen, da in diesem Betriebspunkt aufgrund der kurbelwellensynchronen Taktung der Steuerung die kürzesten Rechenzyklen vorliegen. Die genutzte Testumgebung beinhaltet, wie in Abschn. 1.3.5 ausgeführt, meistens virtuelle und reale Komponenten. In Analogie zu dem geschilderten Software-in-the-Loop-Ansatz wird hier die Bezeichnung „Hardware in the Loop“ (HIL) verwendet. Die höchste Hierarchiestufe im Sinne der verschiedenen Testebenen wird mit Erreichen der Abnahme im V-Modell erreicht. Der korrespondierende Abnahmetest ist ein Blackbox-Test, in dem überprüft wird, ob die Benutzeranforderungen erfüllt werden. Bei diesem Test erweist sich die erläuterte Trennung zwischen Entwickler und Tester als besonders gewinnbringend, zumal komplexe Fahrzeugfunktionen in der Regel von mehreren Entwicklern über die verschiedenen Phasen des V-Modells gestaltet werden.

40

1 Funktions- und Softwareentwicklung

Entscheidend für den Erfolg des Abnahmetests ist es, die Perspektive des Benutzers, also des Fahrzeugkundens einzunehmen. Um diese wesentliche Randbedingung sicherzustellen, ist bei Fahrzeugherstellen die Abteilung, die die Fahrzeugfunktionalität freigibt, in der Regel von der entwickelnden Abteilung organisatorisch getrennt.

2

Softwareentwicklungsprozess in der Automobilindustrie

In diesem Teil soll der Fokus auf der Tätigkeit der Softwareentwicklung und dem Softwaretest im Sinne der Erstellung von Programmen zur Implementierung der funktionalen Anforderungen und der Durchführung von Tests liegen. Dabei ist ein wesentlicher Aspekt, dass die Software im Automobil immer nur Teil eines mechatronischen Systems aus Mechanik, Elektronik und Software ist. Für eine ausführlichere Darstellung sei auf [Wo2] verwiesen. Als Ergänzung zum ersten Teil sind die Prozessbeschreibungen deutlicher als konkret zu implementierende und durchzuführende Prozessschritte gehalten, die an die industrielle Praxis angelehnt sind. Das in vielen Teilaspekten sicherheitsrelevante System „Automobil“ als Ganzes erfordert ein umsichtiges Vorgehen in der Softwareentwicklung und deren Test. Der Fokus dieses Teils liegt darum sehr stark auf einem strukturierten, gerichteten Vorgehen, ohne die Produkttechnik der Mechanik, Elektronik und Software direkt zu betreffen. Die Stringenz des Vorgehens und das Verständnis für die dazu notwendigen Arbeitsschritte sind die Basis für die Entwicklung zukünftiger Produkte. Die hier vorgestellten Methoden und Vorgehensweisen stellen eine Konkretisierung der geforderten Entwicklungsprozesse auf abstrakter Ebene dar. Der Anspruch an dieser Stelle ist, allgemeine Vorgehensweisen als „Best Practices“ aller Systemhersteller zusammenzufassen, die auch in Gremien wie ASAM und AUTOSAR diskutiert werden. Es ist eine Kernkompetenz der Fahrzeughersteller und Zulieferer, die erläuterten generischen Praktiken in konkrete Anweisungen und Abläufe für den Arbeitsalltag der Produktentwicklung umzusetzen. Objektorientierte Vorgehensweisen aus der Softwareentwicklung für IT-Systeme oder dem Bereich des Mobilfunks spielen in der Programmierung von Steuergeräten eine eher untergeordnete Rolle. Bei der konkreten Entwicklungstätigkeit wird sowohl auf den

© Der/die Autor(en), exklusiv lizenziert an Springer-Verlag GmbH, DE, ein Teil von Springer Nature 2023 K. Reif und F. Wolf, Softwareentwicklung für Kraftfahrzeuge, https://doi.org/10.1007/978-3-662-68046-9_2

41

42

2 Softwareentwicklungsprozess in der Automobilindustrie

Weg der Erstellung von Software mittels Schreiben von Programmcode, zum Beispiel in der Programmiersprache C, als auch auf die automatische Codegenerierung aus einer modellbasierten Programmbeschreibung eingegangen. Die Softwareentwicklung erfolgt schrittweise im Sinne des bereits eingeführten und hier detaillierten V-Modells. Der Fokus dieses Kapitels liegt auf der strukturierten Erhebung und Weiterverarbeitung von Anforderungen und der Erstellung der diese Anforderungen eindeutig und nachweisbar umsetzenden Software. Basierend auf dem Themenkomplex der funktionalen und nichtfunktionalen Anforderungen sowie deren Umsetzung in der Architektur wird die Entwicklung der Mechanik und der Elektronik kurz erläutert. Diese Themen sind für die Systementwicklung in der Automobilindustrie die Grundlage für die Softwareerstellung. Hierbei wird vor allem auf die Phasen des Feinentwurfs und die Implementierung im V-Modell eingegangen, da hier nach der bereits beschriebenen Konkretisierung der Anforderungen und deren Strukturierung durch die Definition der Architektur die eigentliche Codierung und der Test stattfinden. Es wird auf übergreifende Themen des Projektmanagements der Softwareentwicklung eingegangen und die zugehörigen Werkzeuge sowie ein beispielhaftes Analyseverfahren für Rechenzeit von Software im industriellen Umfeld vorgestellt. Bei den konkreten Beschreibungen müssen die aufgezählten Dokumente und Ergebnisse in ihrer jeweiligen Gesamtheit vorliegen. Bei den Vorgehensbeschreibungen ist die sequentielle Abarbeitung der Handlungsanweisungen in der genannten Reihenfolge zu beachten.

2.1

Anforderungen und Architekturentwurf

Im folgenden Abschnitt wird gezeigt, wie im Systementwurf die Anforderungen von Ihrer informellen Erhebung beim Anfordernden, deren formale Ablage in Form einer Spezifikation, über die Architektur und die Feinspezifikation bis in die konkreten Anforderungen der Softwareentwicklung, also über das Lastenheft bis in den konkreten Code systematisch heruntergebrochen und verfeinert werden. Dieses Vorgehen wird auch als Architekturentwurf bezeichnet.

2.1.1

Anforderungserhebung

Der Prozess der Anforderungserhebung bildet die systematische Aufnahme der Anforderungen auf Dokumentenebene und den Dialog mit dem Anforderer oder Kunden ab. Der Begriff des Kunden wird hier nicht als Endkunde, sondern als herstellerinterner Kunde im Sinne eines Nachfolgers in der Prozesskette der Anforderungserhebung verstanden. Der Prozess erzeugt so das Arbeitsprodukt Lastenheft als eindeutige Basis für das

2.1

Anforderungen und Architekturentwurf

43

zu erstellende Produkt. Die Anwendung des Prozesses „Anforderungserhebung“ erzeugt ein gemeinsames Verständnis der geforderten Eigenschaften eines zu produzierenden Systems. Dies geschieht oft im Dialog oder sogar mittels der Bewertung funktionaler Prototypen durch Kunden zusammen mit den Entwicklern. Das Ziel ist die Erstellung eines Dokuments, welches die Kundenwünsche in detaillierter und aussagekräftiger Form repräsentiert. Dieses als Lastenheft bezeichnete Dokument beinhaltet alle relevanten Versionsstände der übergebenen Dokumente, z. B. die Information, welche Teile der übergebenen Dokumente zu beachten sind, eine tabellarische Übersicht dieser Dokumente sowie eine vollständige Liste von aus den Dokumenten abgeleiteten Anforderungen. Die Abstimmung über anzunehmende und abzulehnende Anforderungen zwischen Auftraggeber (Kunde) und Auftragnehmer ist ebenso Teil des Prozesses wie das Erstellen und Verteilen der abschließenden Baseline des Lastenheftes. Eine Baseline beinhaltet alle für das Lastenheft notwendigen Dokumente und weiteren Artefakte, d. h. weitere Dateien wie Quellcodes oder Testspezifikationen in einer festgelegten Version. Nach dem Einsammeln (durch Fragen und Einfordern vom Kunden) und Prüfen (auf Konsistenz) der systembeschreibenden Dokumente und der mitgeltenden Unterlagen wird eine lokale Bibliothek der Dokumente angelegt und eine Übersicht aller Dokumente und ihrer Versionen erstellt. Nach dem Ermitteln und Abstimmen, welche Teile der mitgeltenden Dokumente wirklich für dieses Projekt notwendig sind, um die relevanten Anforderungen zu erkennen, sind alle Anforderungen so zu formulieren, dass Anforderungsqualitätskriterien wie Umsetzbarkeit, Testbarkeit, Lesbarkeit, Eindeutigkeit, Widerspruchsfreiheit, usw. erfüllt sind. Nicht akzeptierbare Anforderungen müssen mit dem o. g. Kunden im Sinne der Prozesskette der Anforderungserhebung nachverhandelt oder ablehnt werden. Die abschließende Tätigkeit ist das Erzeugen und Verteilen der Baseline (Grundlinie) über alle Dokumente des Auftraggebers und die daraus erzeugten Dokumente. Diese Baseline (Grundlinie) wird als Lastenheft bezeichnet. Sie enthält alle Dokumente und weiteren Artefakte (s. o.) in einer festgelegten Version. Dies wird durch das Konfigurationsmanagement sichergestellt. Das Lastenheft repräsentiert den abgestimmten Stand, welche Eigenschaften das System haben soll. Alle Projektteilnehmer sind über den aktuellen Stand des Lastenheftes informiert.

2.1.2

Systemanforderungsanalyse

Die Anwender des Prozesses Systemanforderungsanalyse sammeln, analysieren, kategorisieren, verhandeln und priorisieren die Systemanforderungen. Das Ergebnis ist ein geprüftes Systempflichtenheft als technische Implementierung des Lastenhefts. Aus den Systemanforderungen im Lastenheft werden die Anforderungen des Pflichtenheftes abgeleitet. Weitere Systemanforderungen aus anderen Anforderungsquellen werden

44

2 Softwareentwicklungsprozess in der Automobilindustrie

dem Pflichtenheft hinzugefügt. Andere Anforderungsquellen können z. B. Normen, Gesetze, Randbedingungen aus Test und Produktion, systematisch erhobene Erfahrungen, Managemententscheidungen und protokollierte Absprachen sein. Zur Analyse muss jede Systemanforderung im Pflichtenheft dabei so formuliert werden, dass sie eine funktionale oder eine nichtfunktionale Anforderung darstellt, die in sich widerspruchsfrei, eindeutig formuliert und umsetzbar ist. Sie muss auf Systemebene testbar und zu anderen Anforderungen widerspruchsfrei sein. Redundanzen müssen vermieden und die Anforderungsquelle eindeutig referenziert sein. Die Systemanforderungen werden den Systemfunktionen zugeordnet. Anforderungen bzgl. Software, Hardware und Mechanik, welche nur dort testbar sind, werden nicht als Systemanforderung akzeptiert. Sie werden gegebenenfalls später als Modulanforderungen in den Software-/Elektronik- und Mechanikpflichtenheften eingetragen, falls sich ihre Einhaltung als sinnvoll erweist. Den geforderten Funktionen des Systems werden relevante funktionale und technische Anforderungen zugeordnet. Zu den geforderten Funktionen werden Anwendungsfälle entwickelt. Wenn nötig, wird dieses um Sequenzdiagramme im Sinne der UML, der Unified Modeling Language ergänzt. Das Ziel ist, Widersprüche und Anforderungslücken zu entdecken und mit dem Kunden zu schließen. Das System wird durch erste Diagramme und Anwendungsfälle vollständig beschrieben und gegen die Systemumgebung abgegrenzt. Notwendige Eigenschaften der Systemumgebung werden erfasst und an den Kunden kommuniziert. Es wird zusätzlich explizit vereinbart und dokumentiert, was nicht zum Systemumfang gehört. Das verhindert Missverständnisse und falsche Erwartungshaltungen. Die Wichtigkeit einer schnellen Umsetzung wird im Dialog mit dem Anforderer ermittelt. Sie ermöglicht eine erste Releaseplanung. Das Erstellen des eigentlichen Releaseplans ist nicht Teil der Aktivität. Die erste Pflichtenheft-Baseline wird erzeugt und verteilt. In dieser ist jede Anforderung mit dem Lastenenheft verlinkt. Es wird nach Risiken gesucht, die die Prozesserfüllung behindern können. Der Systemanforderungsingenieur informiert den Projektleiter schriftlich über Risiken für den Erfolg der Prozessbearbeitung und stimmt ggf. Gegenmaßnahmen ab. Danach erstellt der Systemanforderungsingenieur das Pflichtenheft durch Kopieren der akzeptierten Anforderungen aus dem Lastenheft und sorgt für eine initiale Verlinkung im Anforderungsmanagement. Im Projekt werden weitere Randbedingungen aus zusätzlichen Quellen hinzugefügt und mit der versionierten jeweiligen Quelle verlinkt. Die Anforderungen werden so formuliert, dass nur atomar testbare Systemeigenschaften, prüfbare Prozessanforderungen oder nichtfunktionale Anforderungen an das System im Pflichtenheft erscheinen. Die Widerspruchsfreiheit und andere Qualitätskriterien werden dabei beachtet. Der Systemanforderungsingenieur unterstützt die anderen Mitarbeiter im Projekt, indem er die Übersicht und die Versionierung von Quelldokumenten (die nicht zum Lastenheft gehören) pflegt und die Verlinkung der Anforderungen in diese Dokumente überprüft. Es wird eine Zusammenführung der Anforderungen auf funktionaler

2.1

Anforderungen und Architekturentwurf

45

und Systemschnittstellenebene vorgenommen. Auf dieser Ebene werden erneut Widersprüche sowie Definitionslücken gesucht und zusammen mit dem Kunden beseitigt. Ein erstes Bild des Systems entsteht. Sich ergebende zusätzliche Anforderungen an die Systemumgebung oder notwendige Abweichungen gegenüber dem Lastenheft werden dem Kunden mitgeteilt und mit diesem abgestimmt. Auswirkungen auf die Betriebsumgebung werden bewertet und kommuniziert. Es wird ein Lastenheft für den Kunden erzeugt und abgestimmt. Danach werden die Anforderungen priorisiert und den Releases zugeordnet. Abschließend wird eine Baseline über alle erstellten Dokumentversionen gezogen und diese werden verteilt. Diese Baseline wird als Pflichtenheft bezeichnet. Zum Schluss erfolgt ein Review des Pflichtenhefts. Nach erfolgreicher Implementierung des Prozesses System-Anforderungsanalyse sind die Systemanforderungen und Systemschnittstellen identifiziert sowie die Systemanforderungen kategorisiert und auf Korrektheit sowie Testbarkeit geprüft. Der Einfluss der Systemanforderungen auf die Arbeitsumgebung ist bekannt und die Implementierung der einzelnen Systemanforderungen ist priorisiert. Die Konsistenz und Nachverfolgbarkeit (Traceability) zwischen den Kunden- und Systemanforderungen ist sichergestellt. Notwendige Abweichungen von den Kundenanforderungen sind mit dem Auftraggeber abgestimmt und dokumentiert sowie die vollständigen Systemanforderungen abgestimmt, mit einer Baseline versehen und verteilt.

2.1.3

Systemarchitekturentwurf

Im Systemarchitekturentwurf werden die Anforderungen einem System der E/EArchitektur des Fahrzeugs zugeordnet, welches sie erfüllen kann. Aus den Anforderungen werden die Systemkomponenten abgeleitet. Sind alle Anforderungen den Systemkomponenten zugeordnet, wird deren Zusammenspiel und die vollständige Beschreibung durch Simulation oder Review geprüft. Der Systemarchitekt prüft, ob alle notwendigen Informationen für den Systemarchitekturentwurf vorhanden sind, erstellt die Systemarchitektur und verifiziert die Systemarchitektur durch manuelle Prüfung oder Simulation. Es wird ein formales Review der Systemarchitektur als Vorbereitung der Baselineerstellung durchgeführt und die Systembaselinearchitektur wird kommuniziert. Nach erfolgreicher Implementierung des Prozesses „Systemarchitekturentwurf“ im Projekt ist eine Systemarchitektur erstellt, welche die einzelnen Elemente des Systems identifiziert und spezifiziert. Die Systemanforderungen sind den Elementen des Systems zugeordnet und die internen und externen Schnittstellen der Systemelemente sind definiert. Die Systemarchitektur ist gegen die Systemanforderungen verifiziert und die Konsistenz sowie die Transparenz zwischen der Systemarchitektur und den Systemanforderungen ist sichergestellt. Die Systemanforderungen, die Systemarchitektur und

46

2 Softwareentwicklungsprozess in der Automobilindustrie

deren Zusammenhänge sind allen beteiligten Parteien kommuniziert und durch Baselines freigegeben.

2.1.4

Komponentenanforderungsanalyse

Die Anwender des Prozesses Komponentenanforderungsanalyse sammeln, analysieren und kategorisieren die Komponentenanforderungen. Das Ergebnis ist eine geprüfte Komponentenanforderungsspezifikation. Aus den Beschreibungen des funktionalen und nichtfunktionalen Verhaltens in der Systemarchitektur werden die Anforderungen der Komponentenspezifikation abgeleitet. Weitere Komponentenanforderungen aus anderen (komponentenspezifischen) Anforderungsquellen werden der Komponentenspezifikation hinzugefügt. Andere Anforderungsquellen können z. B. Normen und Gesetze, Randbedingungen aus Test und Produktion, die Verfügbarkeit spezifischer Technik sowie systematisch erhobene Erfahrungen und Designempfehlungen von Kunden sein. Widersprüche zur bereits bestehenden Komponentenspezifikation werden geklärt und Entscheidungen dokumentiert sowie begründet. Jede Anforderung in der Komponentenanforderungsspezifikation muss dabei so formuliert sein, dass sie eine funktionale oder nichtfunktionale Anforderung für die Komponente darstellt, die in sich widerspruchsfrei, eindeutig formuliert, umsetzbar und testbar ist. Sie muss zu anderen Anforderungen widerspruchsfrei und die Anforderungsquelle eindeutig referenziert sein. Der Komponentenanforderungsingenieur erstellt die Komponentenanforderungsspezifikation durch Ableiten der funktionalen und nichtfunktionalen Anforderungen aus der Architekturbeschreibung der Systemarchitektur und stellt dabei die bidirektionale Verfolgbarkeit und Durchgängigkeit zwischen den Systemarchitekturbeschreibungen und den Komponentenanforderungen sicher. Das Systemlastenheft wird nach für diese Komponente relevanten Designempfehlungen durchsucht. Ob diese Designempfehlungen Einfluss auf die Komponente haben, wird vom Komponentenanforderungsingenieur und dem Komponentenarchitekten entschieden. Wenn eine Designempfehlung umgesetzt werden soll, wird sie als Anforderung in die Komponentenanforderungsspezifikation übernommen. Nach der Analyse der an die Komponenten gestellten Anforderungen werden Rückwirkungen der Komponente auf die Komponentenumgebung (System und Systemumgebung) vom Komponentenanforderungsingenieur mit dem Systemarchitekten abgestimmt. Beispiel: Eine Rückwirkung kann sich ergeben, wenn die geforderte Genauigkeit von Ausgangswerten der Komponente auf Grund zu geringer Genauigkeit der Eingangswerte nicht erreicht werden kann. Dann muss entweder die Komponentenanforderung oder die Architektur angepasst werden. Es wird eine Baseline für Komponentenanforderungsspezifikation erstellt und diese verteilt.

2.1

Anforderungen und Architekturentwurf

47

Nach erfolgreicher Implementierung des Prozesses Komponentenanforderungsanalyse sind die Komponentenanforderungen identifiziert sowie die Komponentenanforderungen kategorisiert und auf Korrektheit und Testbarkeit geprüft. Die inhaltliche Konsistenz der abgeleiteten Komponentenanforderungen ist sichergestellt und die einzelnen Komponentenanforderungen sind priorisiert (Priorität abgeleitet aus der Systemebene). Die Konsistenz und Nachverfolgbarkeit (Traceability) zwischen den Komponentenanforderungen und der Systemarchitektur ist sichergestellt sowie die Baseline der Komponentenanforderungsspezifikation verteilt.

2.1.5

Komponentenarchitekturentwurf

Auf der Grundlage der Komponentenanforderungen wird eine geeignete Komponentenarchitektur entworfen. Die Komponentenarchitektur enthält Software-, Elektronik- und Mechanik-Komponenten. Der Komponentenarchitekturentwurf wird im V-Modell auch als Grobentwurf bezeichnet. Aus den Anforderungen werden die Architekturelemente abgeleitet. Sind alle Anforderungen der Komponentenarchitektur zugeordnet, werden sowohl deren Verhalten und Eigenschaften als auch deren Zusammenspiel durch eine Analyse geprüft. Nach einem abschließenden formalen und fachlichen Review der Komponentenarchitekturspezifikation wird die Komponentenarchitektur freigegeben. Der Komponentenarchitekt prüft, ob alle notwendigen Informationen für den Komponentenarchitekturentwurf vorhanden sind, erstellt die Komponentenarchitektur. Und analysiert die Komponentenarchitektur mittels geeigneter Analysemethoden. Es wird ein formales Review der Komponentenarchitektur durchgeführt bevor die freigegebene Komponentenarchitektur kommuniziert wird. Nach erfolgreicher Anwendung des Prozesses Komponentenarchitekturentwurf im Projekt wurden relevante Designempfehlungen geprüft, in Anforderungen umgesetzt oder verworfen. Es wurde eine Komponentenarchitektur erstellt, welche die einzelnen Elemente der Komponente identifiziert und spezifiziert. Die Komponentenanforderungen sind den Elementen der Komponente zugeordnet und die internen und externen Schnittstellen der Komponente sind definiert. Die Komponentenarchitektur ist gegen die Komponentenanforderungen verifiziert und die Konsistenz und Transparenz zwischen der Komponentenarchitektur und den Komponentenanforderungen ist sichergestellt. Die Komponentenanforderungen, die Komponentenarchitektur und deren Zusammenhänge sind allen beteiligten Parteien kommuniziert und durch Baselines freigegeben. Mit den so vorliegenden Arbeitsergebnissen ist der Architekturentwurf abgeschlossen und es kann in die Phase der Entwicklung der konkreten technischen Subsysteme Mechanik, Elektronik-Hardware und Software in der E/E-Architektur übergegangen werden. Im Sinne der Vergabe von Entwicklungsgewerken kann hier statt einer Eigenentwicklung die eindeutige Spezifikation an den Lieferanten übergeben und weiterverfolgt werden.

48

2.2

2 Softwareentwicklungsprozess in der Automobilindustrie

Mechanik und Elektronik-Hardware

Für die Umsetzung der funktionalen und nichtfunktionalen Anforderungen kann man in die Software in der Automobilindustrie nicht isoliert betrachten. Die Software ist immer Teil eines mechatronischen Gesamtsystems aus Mechanik, Elektronik-Hardware und Software. Die Systementwicklung muss diese Aspekte berücksichtigen, die Mechanik- und Elektronikentwicklung sollen hier aber nur oberflächlich erwähnt werden. Das Ziel der Mechanikentwicklung ist zunächst, funktionierende mechanische Bauteile und Baugruppen entsprechend dem geforderten Musterstand zu entwickeln, welche alle in der Systemarchitektur zugewiesenen Anforderungen erfüllen. In der Mechanik-Anforderungsanalyse werden die Anforderungen aus der System- und Komponentenebene auf die Mechanikebene (konkrete Bauteile und Baugruppen) heruntergebrochen. In der Baugruppenanforderungsanalyse werden die Anforderungen an die mechanischen Baugruppen oder Einzelteile identifiziert und diesen zugewiesen. Die aus den Anforderungen abgeleiteten Bauteillastenhefte bilden die Grundlage für die mechanische Konstruktion. In der Entwicklung und Konstruktion wird ein Design erzeugt, mit dem die Mechanikanforderungen realisiert und diese gegenüber den funktionalen Anforderungen geprüft werden können. Dieses wird als Baugruppe hergestellt und erst als Einzelteil sowie später im System erprobt. Das Ziel der Hardwareentwicklung oder auch Elektronikentwicklung ist es, analog zur Mechanikentwicklung funktionierende elektronische Bauteile und Baugruppen entsprechend dem geforderten Musterstand zu entwickeln, welche alle in der Systemarchitektur zugewiesenen Anforderungen erfüllen. Der Begriff der Module wird genauso wie für Software hier für die Baugruppen der Mechanik und Elektronik verwendet. Es handelt sich in der Praxis oft um die kleinsten herstell- und testbaren Teile. Dieses Vorgehen unterstreicht den Systembegriff. Im Bereich der Softwareentwicklung wird oft gleichbedeutend der Begriff Units für Module verwendet. Die Systemarchitektur beschreibt das System in seinen abstrakten Einzelteilen. Aus dieser Gesamtbeschreibung sind die für die Hardware relevanten Teile zu identifizieren und in Hardwareanforderungen zu erstellen. Parallel sind übergreifende Dokumente (thermisches Konzept, EMV-Konzept, …) zu erstellen oder zu detaillieren. Durch Review(s) erfolgt die Verifikation der Konzeptdokumente wie z. B. Schaltpläne und Platinenlayouts sowie der Hardwareanforderungen der Schnittstellendokumente. Auf Basis der Hardwareanforderungen werden funktionale Module festgelegt. Sie sollen möglichst rückwirkungsfrei funktionieren, d. h. dass eine Änderung an einem Modul keinen Einfluss auf die anderen Module hat. Weiterhin sollen sie einfache Schnittstellen untereinander haben. Damit soll gewährleistet werden, dass der weitere Entwurf und die Implementierung modular erfolgen können. Anschließend wird das in der Hardwarearchitektur funktional beschriebene Modul durch ein elektronisch geeignetes Design (Elektronikbaugruppen, Platinen, Schaltungen,

2.3

Softwareentwicklung

49

…) realisiert. Die erstellten Schaltpläne werden verifiziert und vor allem unter Beachtung sicherheitstechnischer Aspekte analysiert. Nach erfolgreichem Abschluss des Prozesses Hardwaredesign liegen Schaltpläne vor. Die Schaltungen sind durch Simulation, Messungen, Reviews oder einer Kombination daraus verifiziert, formal unter dem Aspekt der funktionalen Sicherheit analysiert und damit für die weiteren Prozesse als endgültig anzusehen. Danach werden das Layout oder sogar Netzlisten für Elektronikbausteine und damit alle Produktionsdaten erstellt. Die Produktion oder ein Prototypenbau erstellt Prototypen, die dann durch Test verifiziert werden können. Hier ist eine enge Abstimmung zwischen Mechanik und Elektronik notwendig.

2.3

Softwareentwicklung

Im folgenden Abschnitt soll die konkrete Entwicklung für die funktionale Software und die Software des Überwachungskonzepts aus den Anforderungen gezeigt werden. Pragmatische Voraussetzungen sind ein Prototyp des elektronischen Systems zur Ausführung der Software, eine Entwicklungsumgebung und ein Basissoftwaresystem, das die Lauffähigkeit der funktionalen Softwaremodule sicherstellt.

2.3.1

Softwareanforderungsanalyse

Die Softwareanforderungsanalyse dient dazu, die Anforderungen aus der übergeordneten Architektur oder dem Lastenheft abzuleiten und zu dokumentieren. Aus den Beschreibungen des funktionalen und nichtfunktionalen Verhaltens in der Systemarchitektur und Komponentenarchitektur werden die Anforderungen in der Softwareanforderungsspezifikation abgeleitet. Weitere Softwareanforderungen aus anderen Anforderungsquellen werden der Softwareanforderungsspezifikation hinzugefügt. Andere Anforderungsquellen können z. B. Normen und Gesetze, Randbedingungen aus Test und Produktion, systematisch erhobene Erfahrungen und Designempfehlungen von Kunden sowie begründete Abweichungen vom formalen Sicherheitskonzept sein. Widersprüche zur bereits bestehenden Softwareanforderungsspezifikation werden geklärt und die Entscheidungen dokumentiert und begründet. Auf Basis des übergeordneten Architekturdokuments und weiterer mitgeltender Unterlagen werden die Anforderungen an die Software abgeleitet und in einer Softwareanforderungsspezifikation dokumentiert. Die Softwareanforderungsspezifikation beinhaltet sowohl funktionale als auch nichtfunktionale Softwareanforderungen, deren Abhängigkeiten analysiert werden müssen und deren Widerspruchsfreiheit gewährleistet sein muss. Nach erfolgreicher Anwendung des Prozesses Softwareanforderungsanalyse sind die Softwareanforderungen kategorisiert und auf Korrektheit und Testbarkeit überprüft. Die

50

2 Softwareentwicklungsprozess in der Automobilindustrie

Softwareanforderungen sind bezüglich ihrer Implementierung priorisiert und die Konsistenz und Nachverfolgbarkeit zwischen der übergeordneten Architektur und den Softwareanforderungen ist sichergestellt. Der aktuelle, geprüfte Stand der Softwareanforderungen ist mit einer Baseline versehen und deren Freigabe an die Projektleitung kommuniziert.

2.3.2

Softwareentwurf

Der Softwareentwurf (Softwarearchitektur) stellt alle Softwarebauteile in einer hierarchischen Struktur dar. Dies wird im V-Modell auch als Feinentwurf bezeichnet. Zweck des Prozesses Softwareentwurf ist es, ein Softwareentwurfsdokument (Softwarearchitekturdokument) zu entwickeln, welches die Softwareanforderungen umsetzt und gegen die Anforderungen verifiziert werden kann. Bei sicherheitsrelevanter Software werden die Ziele verfolgt, eine Softwarearchitektur bereitstellen, welche die Sicherheitsanforderungen berücksichtigt sowie die Softwarearchitektur gegen die Softwareanforderungsspezifikation zu verifizieren und freizugeben. Der Prozess Softwareentwurf folgt auf den Prozess Softwareanforderungsanalyse und wird während der gesamten Softwareentwicklung iterativ durchgeführt. Dadurch soll sichergestellt werden, dass die Softwarearchitektur den aktuellen Softwareanforderungsstand oder die Korrektur von Entwurfsfehlern wiedergibt. Nach der Analyse der Softwareanforderungen erfolgt die Entwicklung einer statischen Softwarearchitektur, in der Softwareelemente, deren Verhalten, Eigenschaften und Abhängigkeiten beschrieben werden. Es existiert eine bidirektionale Traceability (Rückverfolgbarkeit) zu den Softwareanforderungen, die die Entscheidungen der Architekturmodellierung dokumentiert und die Sicherheitsrelevanz von Softwareelementen basierend auf deren Softwareanforderungen erkennen lässt. Es folgt der Entwurf der Schnittstellen inklusive ihrer Spezifikation wie beispielsweise deren Wertebereich und Name. Nach der Entwicklung einer dynamischen Softwarearchitektur anhand der funktionalen und nichtfunktionalen Anforderungen erfolgt die Abschätzung der Laufzeit, die Festlegung von Scheduling-Verfahren und die Aufteilung der Funktionen zu Tasks oder Interrupts. Es folgt die Prüfung der Architektur auf Änderungen und Entscheidung über die Durchführung der Analysemethode. Nach der Schätzung des Ressourcenverbrauchs der Architektur und Berechnung der Worst Case Execution Time WCET (maximale Rechenzeit) pro Task sowie Vergleich mit den Anforderungen erfolgt die Definition von Softwareverifikationskriterien basierend auf der dynamischen Softwarearchitektur, den Schnittstellen und der Ressourcennutzung. Die Organisation und Durchführung von Reviews sowie Prüfung der formalen Aspekte der Softwarearchitektur sowie das Baselining und die Kommunikation der Architektur schließen die Aktivitäten ab. Nach erfolgreicher Implementierung des Prozesses Softwareentwurf im Projekt ist die Softwarearchitektur entsprechend den Softwareanforderungen definiert und die einzelnen

2.3

Softwareentwicklung

51

Elemente der Software den Softwareanforderungen sind zugeordnet und nachverfolgbar. Die internen und externen Schnittstellen der Softwarekomponenten sind definiert und die Softwarearchitektur ist detailliert beschrieben, sodass Komponenten umgesetzt und getestet werden können. Bei sicherheitsrelevanter Software liegen das Softwarearchitekturdokument, welches alle (sicherheitsrelevanten) Softwareanforderungen berücksichtigt, der Sicherheitsplan (überarbeitet) und die Softwareanforderungsspezifikation (überarbeitet) als Prozessergebnisse vor.

2.3.3

Funktionssoftwareerstellung

Der Prozess der Funktionssoftwareerstellung oder Softwarecodierung beschreibt die Erstellung von funktionaler Software ohne sicherheitsrelevante Einstufung. Es handelt sich um Code der Ebene 1, also die Umsetzung der vom Kunden geforderten Funktionalität wie beispielsweise eine Geschwindigkeitsregelung. Ziel ist die Erstellung von ablauffähigen Software-Units, sowie die deren isolierte Verifikation, sodass sie den Softwareentwurf richtig wiedergeben. Der Prozess Funktionssoftwareerstellung wird nach dem Prozess Softwareentwurf durchgeführt. Hier werden die in der Softwarearchitektur spezifizierten Software-Units erstellt. Um den Durchlauf des Prozesses Funktionssoftwareerstellung zu beschleunigen, kann bereits nach dem Review des Unit-Konzeptes mit der Erstellung der Testfallspezifikation und Testvektoren sowie der anschließenden Implementierung der Testcases für den Black-Box-Test begonnen werden. Black-Box-Tests sind Tests, die das Input- und OutputVerhalten der Software-Unit testen. Hierfür ist der innere Aufbau der Software-Unit nicht relevant. Dem gegenüber gibt es die White-Box-Tests. Diese testen das innere Verhalten der Software-Unit, wie z. B. Schleifen und weitere Kontrollstrukturen. Da hierfür die innere Struktur bekannt sein muss, kann die Erstellung dieser Testfallspezifikation und der entsprechenden Testfälle erst nach dem Review der Unit-Spezifikation beginnen. Diese parallelen Aktivitäten müssen beim Review der Testfälle und der Testfallspezifikation wieder zusammengeführt werden. Die Tätigkeiten der Testfallspezifikation und die Verfahren zur Auswahl der Testfälle werden im weiteren Verlauf des Kapitels erläutert. Nach erfolgreicher Implementierung des Prozesses Software-Erstellung existiert für jede Software-Unit ein Entwurf und eine Unit-Spezifikation. Es wurden die SoftwareUnits nach ihrer Unit-Spezifikation erstellt. Für jede Software-Unit existiert eine Testspezifikation, Testdaten und zugehörige Testskripte. Für jede Anforderung an die SoftwareUnit gibt es mindestens einen Modultest. Die Korrektheit des Codes ist sichergestellt und die Softwaremodule sind gemäß der Unit-Teststrategie getestet. Die Ergebnisse der Tests sind protokolliert und es ist ein Testbericht erstellt. Nach erfolgreichem Test liegt ein Unitfreigabebericht für die Software-Unit vor.

52

2.3.4

2 Softwareentwicklungsprozess in der Automobilindustrie

Sicherheitssoftwareerstellung

Der Prozess Sicherheitssoftwareerstellung beschreibt die Erstellung einer SoftwareUnit mit sicherheitsrelevanter Einstufung. Zweck des Prozesses „SicherheitssoftwareErstellung“ ist die Erstellung von ablauffähigen Software-Units für den Einsatz in einem sicherheitsrelevanten Bereich sowie deren Verifikation, damit diese den Software-Entwurf richtig wiedergeben. Die erstellten Software-Units mit sicherheitsrelevanter Einstufung können als sogenannte Überwachungssoftware oder Ebene-2 Software zur Kontrolle von Software ohne sicherheitsrelevante Einstufung im Sinne des Drei-Ebenen-Konzepts genutzt werden. Dabei kann eine Software-Unit mit sicherheitsrelevanter Einstufung mehrere SoftwareUnits ohne sicherheitsrelevante Einstufung überwachen. Hierfür muss jedoch insbesondere auf das Zusammenwirken der Software-Units ohne sicherheitsrelevante Einstufung geachtet werden. Dadurch erhalten die überwachten Softwaremodule (eines oder mehrere) die sicherheitsrelevante Einstufung der Sicherheitssoftware. Der Prozess Sicherheitssoftwareerstellung wird nach dem Prozess Softwareentwurf durchgeführt. Hier werden die in der Softwarearchitektur spezifizierten Software-Units erstellt. Um den Durchlauf des Sicherheitssoftware-Prozesses zu beschleunigen, kann ebenso wie bei der Erstellung der Funktionssoftware bereits nach dem Review des UnitKonzeptes mit der Erstellung der Testfallspezifikation und Testvektoren sowie der anschließenden Implementierung der Testfälle für Black-Box-Tests begonnen werden. Auch hier ist der innere Aufbau der Software-Units nicht relevant und es gibt zusätzlich die White-Box-Tests. Diese testen ebenfalls das innere Verhalten der Software-Units. Da auch hier die innere Struktur bekannt sein muss, kann die Erstellung dieser Testfallspezifikation und der entsprechenden Testvektoren erst nach dem Review der Unit-Spezifikation beginnen. Diese parallelen Aktivitäten müssen beim Review der Testvektoren und der Testfallspezifikation ebenso wieder zusammengeführt werden. Nach erfolgreicher Implementierung des Prozesses Sicherheitssoftwareerstellung existiert für jede Software-Unit ein Entwurf und eine Unit-Spezifikation. Die Software-Units wurden nach ihrer Unit-Spezifikation erstellt und es existiert für jede Software-Unit eine Testspezifikation, Testdaten und zugehörige Testskripte. Für jede Anforderung an die Software-Unit gibt es mindestens einen Modultest. Die Korrektheit des Codes ist sichergestellt und die Softwaremodule sind gemäß der Unit-Teststrategie getestet. Die Ergebnisse der Tests sind protokolliert und es ist ein Testbericht erstellt. Nach erfolgreichem Test liegt ein Unitfreigabebericht für die Software-Unit vor.

2.3

Softwareentwicklung

2.3.5

53

Softwareintegrationstest

Im Softwareintegrationstest werden die einzelnen Software-Units integriert und die integrierte Software wird gegen die Softwarearchitektur getestet. Der Zweck des Softwareintegrationstestprozesses besteht darin, die Softwareeinheiten in größere Gruppen zu integrieren und so die integrierte Software zu erstellen, die mit dem Softwaredesign übereinstimmt sowie dann das Zusammenwirken der Softwarebausteine zu testen. Der Prozess Softwareintegrationstest wird nach dem Prozess Softwareerstellung durchgeführt. Hier wird getestet, ob die erstellten Softwareunits zu einer Gesamtsoftware integriert werden können. Nach erfolgreicher Implementierung des Prozesses Softwareintegrationstest im Projekt sind eine Strategie zur Integration der Software (Integrationsstrategie) und eine Strategie zur Verifikation der Integration (Integrationsteststrategie) definiert. Die einzelnen Softwareunits sind gemäß der Integrationsstrategie integriert und die integrierten Softwareunits sind unter Verwendung der Testfälle verifiziert. Die Ergebnisse des Integrationstests sind dokumentiert und die Konsistenz und bilaterale Nachverfolgbarkeit zwischen den integrierten Softwareunits und der Softwarearchitektur, mit besonderem Augenmerk auf die Schnittstellen, ist sichergestellt.

2.3.6

Softwaretest

Der Softwaretest ist die letzte Integrationsstufe auf Softwareebene, d. h. noch ohne die anwendungsspezifische Elektronik und Mechanik des Systems. Es wird gegen die Software-Anforderungen getestet und nach Bestehen aller Tests die Gesamtsoftware freigegeben. Zweck des Prozesses Softwaretest ist die Verifikation, dass die Software den Softwareanforderungen entspricht. Der Prozess Softwaretest wird im Anschluss an den Prozess Softwareintegrationstest durchgeführt. Aus den Softwareanforderungen erstellt die Softwareentwicklung die Softwaretestfälle. Durch die Tests wird sichergestellt, dass die integrierte Software den Softwareanforderungen entspricht. Nach erfolgreicher Implementierung des Prozesses Softwaretest im Projekt ist eine Strategie zum Testen der Software gemäß den Prioritäten der Software-Anforderungen erstellt. Es ist eine Regressionsteststrategie entwickelt und bei Regressionstests angewendet sowie eine Testspezifikation für die Softwaretests erstellt, welche die Übereinstimmung mit den Softwareanforderungen demonstriert. Regressionstests testen eine neuere Version gegen eine ältere Version der Software, um einerseits die aktuellen Änderungen isoliert zu prüfen und andererseits die Änderungsfreiheit am Rest der Software sicherzustellen. Hierzu ist das oben erläuterte modulare Konzept notwendig. Die Konsistenz und

54

2 Softwareentwicklungsprozess in der Automobilindustrie

bidirektionale Nachverfolgbarkeit zwischen den Softwareanforderungen und der Testspezifikation einschließlich der Testfälle ist sichergestellt und die Software unter Verwendung der erstellten Testfälle getestet.

2.4

Integrationstests für Komponenten und System

Im folgenden Abschnitt wird gezeigt, wie die Software in die Komponenten (Mechanik und Hardware) und das System integriert und dort getestet wird. Auf dieser Ebene handelt es sich noch nicht um das gesamte Fahrzeug, sondern um eine mechatronische Komponente wie eine Lenkung.

2.4.1

Komponententest

Beim Komponententest erfolgt die Prüfung und Freigabe der Komponente. Ziel des Komponententests ist es, nachzuweisen, dass die Komponentenanforderungen korrekt und vollständig umgesetzt wurden und die Komponente freigegeben werden kann. Der Komponententest wird im Anschluss an den Komponentenintegrationstest zu den Releases (Meilensteinen) durchgeführt. Die Komponententests werden direkt auf der vollständig integrierten Komponente durchgeführt. Die Gesamtteststrategie gibt das Vorgehen für die Testaktivitäten in dem Prozess vor. Nach erfolgreicher Anwendung dieses Prozesses wurde eine Teststrategie erstellt, welche beschreibt, wie die Komponente gegen die Anforderungen getestet werden kann. Es ist eine Testspezifikation für die integrierte Komponente erstellt worden, welche die Übereinstimmung mit den Komponentenanforderungen demonstriert. Die Komponente ist durch die spezifizierten Testfälle verifiziert und die Ergebnisse der Tests sind dokumentiert. Die Konsistenz und bilaterale Transparenz zwischen den Komponentenanforderungen und der Komponententestspezifikation ist hergestellt sowie eine Strategie für „Regressionstests“ (Testwiederholung) definiert und bei Änderungen der Komponentenelemente angewendet worden.

2.4.2

Komponentenintegrationstest

Beim Komponentenintegrationstest wird die Komponentenarchitektur geprüft. Es erfolgt eine Mechanik-, Hardware- und Softwareintegration nach spezifisch definierten Prozessschritten. Der Komponentenintegrationstest soll dazu dienen, Inkonsistenzen zwischen den verbundenen Fahrzeugfunktionsbereichen aufzudecken. Zweck des Prozesses Komponentenintegrationstest ist der Test der einzelnen Komponenten in ihrem Zusammenspiel

2.4

Integrationstests für Komponenten und System

55

mit den direkten Schnittstellenpartnern der Komponenten untereinander. Bei diesem Test kommt es darauf an, mehrere unabhängig voneinander entwickelte Komponenten mit einer Vielzahl gemeinsamer Schnittstellen zu erproben. Der Komponentenintegrationsprozess wird im Anschluss an die Freigabe der Teilsysteme (Hardware, Mechanik, Software) zu jedem Release (Meilenstein) durchgeführt. Dies gilt für alle Versionen, die ausgeliefert werden sollen. Nach erfolgreicher Anwendung dieses Prozesses ist eine Komponentenintegrationsund Komponentenintegrationsteststrategie entwickelt worden. Diese berücksichtigt die Komponentenarchitektur und deren Priorisierung. Es ist eine Komponententestspezifikation für die Komponentenintegrationstests erstellt worden. Diese Tests verifizieren, ob die Schnittstellen zwischen den Teilsystemen der Komponenten (Hardware, Software, Mechanik) übereinstimmen. Die Komponente ist entsprechend der Integrationsstrategie integriert und die integrierten Teilsysteme sind unter Verwendung der Testfälle verifiziert. Die Ergebnisse der Integrationstests sind vollständig dokumentiert. Die Konsistenz und bilaterale Nachverfolgbarkeit zwischen der Komponentenarchitektur und der Komponentenintegrationstestspezifikation ist sichergestellt. Es ist eine Regressionsteststrategie entwickelt, die bei Testwiederholungen (wegen Änderungen an Teilsystemen der Komponente) angewendet werden kann.

2.4.3

Systemintegrationstest

Im Prozess Systemintegrationstest werden die Integration und der Test der Systemarchitektur geprüft. Der Prozess Systemintegrationstest umfasst sowohl das Erstellen von Strategien zum Integrieren und Testen des Gesamtsystems als auch deren Durchführung. Der Systemintegrationstest dient dazu, nachzuweisen, dass die unabhängig voneinander entwickelten Komponentenschnittstellen und Komponentenfunktionen der Spezifikation der Systemarchitektur entsprechen. Inkonsistenzen zwischen den verbundenen Komponenten bzw. in deren Zusammenwirken werden im Rahmen des Integrationstests aufgedeckt. Der Systemintegrationsprozess wird im Anschluss an die Freigabe der Komponenten zu jedem Release (Meilenstein) durchgeführt. Nach erfolgreicher Anwendung dieses Prozesses ist eine Systemintegrations- und Systemintegrationsteststrategie entwickelt sowie eine Systemintegrationstestspezifikation für die Systemintegrationstests erstellt worden. Diese Tests dienen sowohl zur Verifikation der Übereinstimmung der Schnittstellen zwischen den Systemkomponenten als auch zur Verifikation deren korrekten funktionalen Zusammenwirkens. Das System ist entsprechend der Integrationsstrategie integriert und die Systemarchitektur ist unter Verwendung der Systemintegrationstestfälle verifiziert. Dabei sind die

56

2 Softwareentwicklungsprozess in der Automobilindustrie

Ergebnisse der Integrationstests vollständig dokumentiert. Die Konsistenz und bidirektionale Nachverfolgbarkeit zwischen der Systemarchitektur und der Systemintegrationstestspezifikation ist sichergestellt und eine Regressionsteststrategie entwickelt, die bei Testwiederholungen (wegen Änderungen an Systemelementen) angewendet werden kann.

2.4.4

Systemtest

Im Systemtest erfolgt die Prüfung und Freigabe des Gesamtsystems. Ziel des Systemtests ist es, nachzuweisen, dass die Systemanforderungen korrekt und vollständig umgesetzt wurden und das System freigegeben werden kann. Der Systemtest wird im Anschluss an den Systemintegrationstest zu den Releases (Meilensteinen) durchgeführt. Die Systemtests werden direkt auf dem Gesamtsystem durchgeführt, die Gesamtteststrategie gibt das Vorgehen für die Testaktivitäten in dem Prozess vor. Nach erfolgreicher Anwendung dieses Prozesses wurde eine Teststrategie erstellt, welche beschreibt, wie das System gegen die Anforderungen getestet werden kann. Es ist eine Testspezifikation für das integrierte System erstellt worden, welche die Übereinstimmung mit den Systemanforderungen demonstriert. Das System ist durch die spezifizierten Testfälle verifiziert und die Ergebnisse der Tests sind dokumentiert. Die Konsistenz und bilaterale Transparenz zwischen den Systemanforderungen und der Systemtestspezifikation ist hergestellt. Es ist eine Strategie für „Regressionstests“ (Testwiederholung) definiert und bei Änderungen der Systemelemente angewendet worden. Mit dem Abschluss dieses Prozessschritts sind die technische Erstellung und der Test der Software fertig. Die Software kann zum Betrieb im Produkt genutzt werden, sowohl in Prototypen als auch im Endprodukt. Der Nachweis der Konformität der Entwicklung des Produkts für verschiedene Projektphasen und Sicherheitseinstufungen wird in firmenspezifischen Freigabeverfahren mit einer Dokumentation sichergestellt und im Mehraugenprinzip durch Entwickler, Tester, Sicherheitsbeauftragte, Qualitätssicherer, Vorgesetzte und Projektleitung per Unterschrift bestätigt. Diese konkrete Umsetzung in Form von Geschäftsprozessen und deren Effizienz zeichnen die wirtschaftlich arbeitenden Unternehmen aus und zeigen oft die hohe Qualität einer Systemherstellung, die oft über Jahre gewachsen ist.

2.5

Übergreifende Prozesse der Softwareentwicklung

2.5

57

Übergreifende Prozesse der Softwareentwicklung

Nach den technischen Themen der Anforderungen, deren Strukturierung durch die Definition der Architektur und der Codierung inklusive Test wird nun auf die übergreifenden Themen des allgemeinen Projektmanagements im industriellen Umfeld der Softwareentwicklung eingegangen. Ohne diese Themen ist eine kommerzielle und professionelle Softwareentwicklung in der Automobilindustrie nicht möglich. Sie sorgen sorgt für eine saubere Strukturierung der Softwareentwicklung, die im Umfeld sicherheitsrelevanter Systeme gefordert wird und zur wirtschaftlichen Entwicklung von Software beitragen und damit letztendlich die Wertschöpfung am Produkt sicherstellen kann.

2.5.1

Qualitätssicherung

Im Prozess Qualitätssicherung (QS) wird durch die Prüfung seitens einer organisatorisch unabhängigen Instanz sichergestellt, dass die Arbeitsprodukte gemäß der definierten Prozesse erstellt und definierte Qualitätskriterien erfüllt werden. Zusätzlich stellt dieser Prozess sicher, dass definierte technische Entwicklungsprozesse eingehalten werden. Die folgende Beschreibung stellt eine Konkretisierung für die Softwareentwicklung im Umfeld der Fahrzeughersteller und Zulieferer dar. Über die formalen und prüfenden Aspekte hinaus unterstützt der Prozess Qualitätssicherung in seiner jeweiligen Ausprägung auch die Erreichung der Unternehmensziele wie • • • • • •

Kundenzufriedenheit, Produktqualität, Prozessqualität, Termintreue, Produktivität, Budgettreue.

Der Grad der Unabhängigkeit der qualitätssichernden Instanz hängt ebenso vom zu entwickelnden Produkt ab. Teilweise reicht eine unabhängige Instanz innerhalb der entwickelnden Firma nicht aus und es müssen externe Audits oder Assessments durchgeführt werden. Dies kann sowohl vom entwickelnden Unternehmen gewünscht als auch durch Gesetze und Normen für sicherheitsrelevante oder besteuerungsrelevante Systeme gefordert werden.

58

2 Softwareentwicklungsprozess in der Automobilindustrie

QM-Planung Die QM-Planung umfasst den gesamten Prozess der Planung des Qualitätsmanagements (QM) mit den Vorgaben für die Qualitätssicherungsaktivitäten. Ziel des QMPlanungsprozesses ist es, die Vorgaben für die Planung, die Durchführung und die Steuerung der Qualitätssicherungsaktivitäten festzulegen. Dazu gehören insbesondere die Festlegung der Qualitätsziele und die davon abgeleiteten Methoden, die zur Qualitätssicherung zu verwenden sind. Die Durchführung des Prozesses wird über folgende Aktivitäten definiert: Die Organisationsstruktur des Projektes sind zu prüfen und die Organisationsstruktur für die Qualitätssicherungsaktivitäten ist bereitzustellen. Es folgt die Entwicklung des Qualitätsmanagementplans mit den Zielen, Vorgaben und Methoden für die Planung und Durchführung von Qualitätssicherungsaktivitäten. Den Abschluss bildet die Prüfung und Freigabe des Qualitätsmanagementplans. Bei korrekter Durchführung des Prozesses liegen klare Qualitätsziele für das Projekt und das Produkt, definierte Methoden, die im Rahmen von Qualitätssicherungsaktivitäten anzuwenden sind, Vorgaben für die Planung, Durchführung und Steuerung der Qualitätssicherungsaktivitäten, vereinbarte Eskalationswege sowie ein definierter Feedbackund Verbesserungskreislauf (Lessons Learned) vor. Es erfolgt eine Sensibilisierung der Projektmitarbeiter für Qualitätsthemen.

QS-Planung Die QS-Planung umfasst den gesamten Prozess der Planung der konkreten Qualitätssicherungsaktivitäten (QS) im Projektverlauf. Inhalt ist die Ausplanung der Qualitätssicherungsaktivitäten entsprechend der Vorgaben aus dem Qualitätsmanagementplan inklusiver inhaltlicher und terminlicher Zuordnung zum Projekt. Die Durchführung des Prozesses wird durch die Planung der Qualitätssicherungsaktivitäten und die Prüfung und Freigabe des Qualitätssicherungsplans definiert. Die Ergebnisse des Prozesses sind eine Übersicht über die erforderlichen Arbeitsprodukte und deren zugeordnete QS-Maßnahmen, eine Zuordnung der QS-Maßnahmen zu den geplanten Freigaben im Verlauf des Projektes, die Feinplanung der Inhalte und Termine der QS-Maßnahmen für die nächste(n) Freigabe(n), die Festlegung der anzuwendenden Prozesse und das Mapping der Arbeitsprodukte zu den geforderten Arbeitsprodukten aus der Automotive SPICE. Ein abgestimmter, operativer Qualitätssicherungsplan liegt vor.

QS-Durchführung Die QS-Durchführung umfasst alle Schritte der Durchführung der Qualitätssicherungsaktivitäten entsprechend dem Qualitätssicherungsplan. Es erfolgt das Sicherstellen der geforderten Qualität von Prozessen und Produkten durch Qualitätssicherungsaktivitäten inklusive Reporting. Das impliziert die Verfolgung von Abweichungen entsprechend den Vorgaben aus dem Qualitätssicherungsplan und dem Qualitätsmanagementplan.

2.5

Übergreifende Prozesse der Softwareentwicklung

59

Die Durchführung des Prozesses beinhaltet das Prüfen der Prozesseinhaltung und der Arbeitsprodukte, die Ableitung von Verbesserungsmaßnahmen, deren Verfolgung und die Erstellung des QS-Statusberichts. Neben eine regelmäßige Einschätzung über den Grad der Prozesseinhaltung liegt eine Übersicht über die Vollständigkeit und den Reifegrad der erforderlichen Arbeitsprodukte vor. Das frühzeitige Erkennen von Schwächen im Entwicklungsprozess und von Risiken, die das Erreichen der Projektziele verhindern können sowie von Verbesserungspotenzialen wird ermöglicht. Korrektur- und Vorbeugungsmaßnahmen sowie die Dokumentation von im Mehraugenprinzip geduldeten Abweichungen liegen vor und die Sensibilisierung der Projektmitarbeiter für Qualitätsthemen ist erfolgt.

2.5.2

Funktionale Sicherheit

Die funktionale Sicherheit beschreibt die Prozesse zur Durchführung von Sicherheitsaktivitäten für alle Phasen des Sicherheitslebenszyklus. Dem Prozess „Funktionale Sicherheit“ liegt die Norm ISO 26262 für funktionale Sicherheit von elektrischen und elektronischen Systemen in Personenkraftwagen zugrunde. Die verfolgte Zielsetzung der Norm ist die Erreichung einer systematischen und konsistenten Vorgehensweise, die für alle Phasen des in der Automobilindustrie definierten Lebenszyklus anwendbar ist. Die Phasen des Sicherheitslebenszyklus werden auf die Phasen des Produktlebenszyklus abgebildet. Es ergibt sich dabei eine Einteilung in „Konzeptphase“, „Produktentwicklung“ sowie „Produktion, Betrieb, Service und Entsorgung“. Die Phase „Funktionale Sicherheit“ stellt in diesem Kontext drei Prozesse bereit: • Konzeption, • Produktentwicklung, • funktionale Absicherung. Die genannten Prozesse berücksichtigen im Fokus dieses Kapitels ausschließlich den Produktentwicklungsprozess, d. h. den Teil des Lebenszyklus vom Beginn der Entwicklung bis zum Produktionsstart und betrachten ganz spezifische Sicherheitsaktivitäten. Die Planung, Koordination und Dokumentation der Sicherheitsaktivitäten für alle Phasen des Sicherheitslebenszyklus sind die Schlüsselaufgaben des Sicherheitsmanagements im Projekt.

Konzeption Die Konzeption beschreibt die Konzeptphase eines Projektes aus der Perspektive der funktionalen Sicherheit. Das als grobe Architektur vorliegende sicherheitsbezogene System wird in Bezug auf Gefährdungen und Risiken analysiert, die in direktem Bezug zu funktionaler Sicherheit

60

2 Softwareentwicklungsprozess in der Automobilindustrie

stehen. Anschließend erfolgt die Ableitung von funktionalen Sicherheitsanforderungen. Das sind Maßnahmen, die ergriffen werden, um die funktionale Sicherheit zu gewährleisten. Der Prozess geht davon aus, dass die Komponente, also der Entwicklungsgegenstand, in Form der Systemarchitektur bereits definiert wurde. Im Rahmen einer sicherheitskritischen Entwicklung stellt dieser Prozess die „Konzeptphase“ gemäß ISO 26262, Teil 3 als Teil des Sicherheitslebenszyklus dar. Zunächst wird die Einflussanalyse erstellt, sofern es sich um eine Änderung des Items oder um eine Weiterentwicklung handelt. Es folgen der Sicherheitsplan, die Gefährdungsund Risikoanalyse durchführen, das Ableiten des funktionalen Sicherheitskonzeptes, das Herunterbrechen auf technische Sicherheitsanforderungen und die Verfeinerung der funktionalen Sicherheitsanforderungen in realisierungsabhängige, technische Sicherheitsanforderungen. Den Abschluss bildet die Bereitstellung eines Validierungsplanes. Der Sicherheitslebenszyklus ist in Bezug auf das Item initiiert und die Ergebnisse einer Einflussanalyse liegen vor. Der Sicherheitsplan ist aufgesetzt und die Ergebnisse der Gefährdungsanalyse und Risikobewertung (Hazard Analysis and Risk Assessment, HARA) liegen vor. Dies sind die Gefährdungen, die aus Fehlfunktionen des Items entstehen können und deren Klassifizierung sowie die daraus abgeleiteten Sicherheitsziele. Das funktionale Sicherheitskonzept liegt vor (Anforderungen zur Erreichung der Sicherheitsziele) und der Validierungsplan ist fertiggestellt.

Produktentwicklung In dieser Phase erfolgt die Darstellung der in der Produktentwicklung projektbegleitenden Aktivitäten im Rahmen der funktionalen Sicherheit. Der Prozess Produktentwicklung befasst sich mit den Aktivitäten, die durch die Mitarbeiter der funktionalen Sicherheit projektbegleitend durchgeführt werden, um die Einhaltung der ISO 26262 zu gewährleisten. Dabei verteilen sich die Aktivitäten, an denen die Rolle „Projektsicherheitsmanager“ beteiligt ist, auf sämtliche Entwicklungsprozesse. Die einzelne Aktivität „Sicherheitsaktivitäten verfolgen“ dient der Darstellung des genannten Sachverhaltes, stellvertretend für alle Aktivitäten, an denen der Projektsicherheitsmanager beteiligt ist. Die Durchführung dieses Prozesses spiegelt die Ausführung der Tätigkeiten wieder, die für die Rolle des Projektsicherheitsmanagers definiert sind. Es handelt sich um die Einhaltung der terminlichen Anforderungen seines Projektbereichs, die Koordination der für die Sicherheit relevanten Beteiligten und Abstimmung in technischen sowie terminlichen Fragen unter Einbindung der Projektleitung sowie Koordination und das Review der beteiligten Zulieferer oder Gewerkenehmer für einzelne Arbeitspakete. Gewerkenehmer sind hierbei die Firmen, die Arbeitspakete als eigenständiges Gewerk bearbeiten und damit für das Ergebnis und nicht nur für die Durchführung verantwortlich sind. Die Teilnahme an projektspezifischen Besprechungen und Arbeitsgruppen ist sichergestellt und es erfolgt die Steuerung der sicherheitsrelevanten Tätigkeiten in den Fachfraktionen. Die Darstellung und Präsentation des Projekts in (Sicherheits- und QS-)

2.5

Übergreifende Prozesse der Softwareentwicklung

61

Assessments, die Abstimmung zu sicherheitsrelevanten Punkten mit dem Kunden und mit dem Validierer bilden den Abschluss.

Funktionale Absicherung Bei diesen Aktivitäten handelt es sich um absichernde Maßnahmen während des Sicherheitslebenszyklus. Der Prozess „Funktionale Absicherung“ beschreibt Aktivitäten, die sich mit absichernden Maßnahmen während des Sicherheitslebenszyklus befassen, die gemäß der Norm ISO 26262 gefordert sind und in der Verantwortung der Rollen der funktionalen Sicherheit liegen. Die konkrete Umsetzung der Maßnahmen sind ebenfalls im Kapitel zur funktionalen Sicherheit detailliert. Nach der Erstellung und Prüfung der Validierungstestspezifikation erfolgt die Anfertigung der Sicherheitsbewertung zu einem Musterstand und die Organisation und die konkrete Durchführung eines Sicherheitsassessments. Nach der Durchführung dieses Prozesses liegen die Validierungstestspezifikation, die Sicherheitsbewertung und das Ergebnis eines Sicherheitsassessments vor. Die Ausprägung des Prozesses „Funktionale Sicherheit“ kann durch die Sicherheitseinstufung des Systems explizit gefordert sein. Der Grad der Unabhängigkeit der durchführenden Instanz hängt ebenso vom zu entwickelnden Produkt ab. Die konkreten für die Softwareentwicklung notwendigen Prozessschritte werden ebenso im Kapitel zur Funktionalen Sicherheit detailliert. Eine unabhängige innerbetriebliche Instanz zur Durchführung der Aktivitäten der Funktionalen Sicherheit des entwickelnden Unternehmens reicht nur für den Verlauf der Produktentwicklung aus. Für die Zulassung des Systems zum Verkauf an Endkunden müssen externe Audits oder Assessments durchgeführt werden. Das Verfahren hierzu wird durch aus der Gesetzgebung hervorgehende Normen geregelt.

2.5.3

Projektmanagement

Das Projektmanagement umfasst die Planung, Steuerung und Kontrolle der Projektaktivitäten, die zur Erreichung des Projektziels durchgeführt werden. Das Projektmanagement stellt sicher, dass das Projekt innerhalb der vorgegebenen Zeit, den genehmigten Kosten und der geforderten Qualität abgewickelt wird. Der Zweck des Projektmanagements besteht darin, die Aktivitäten, Aufgaben und Ressourcen, die für die Bearbeitung eines Projekts oder der Erbringung einer Dienstleistung erforderlich sind, im Kontext der Anforderungen und Bedingungen des Projekts zu ermitteln, festzulegen, zu planen, zu koordinieren und zu überwachen.

Projektstart Beim Projektstart werden alle einleitenden Aktivitäten für die Projektvorbereitung durchgeführt.

62

2 Softwareentwicklungsprozess in der Automobilindustrie

Ziel ist es, sicherzustellen, dass alle Voraussetzungen für die Initiierung des Projekts geschaffen werden und ausreichend Informationen für die Definition und Bestätigung des Projektumfangs vorhanden sind. Beim Projektstart wird der Projektleiter bestimmt und das Projekthandbuch inkl. der Stakeholderanalyse und Projektrisiken erstellt und geprüft. Die Projektorganisation wird festgelegt, die Projektstruktur geplant, die Freigabestrategie erstellt und geprüft und die Projektlisten angelegt. Zum Abschluss ist ein Projektleiter definiert, das Projekthandbuch mit Stakeholdern und Projektrisiken ist in einer ersten Version erstellt. Die Projektorganisation ist festgelegt, die Projektstruktur geplant, die Freigabestrategie und die Projektlisten erstellt.

Projektplanung In der Phase der Projektplanung wird inhaltlich ein Lösungskonzept erstellt, um die vorgegebenen Ziele zu erreichen. Ziel der Projektplanung ist ein ausgewähltes Lösungskonzept zur Realisierung mit einer Detailplanung. Die Planung der Realisierung ist hochgradig abhängig von Projekt, Unternehmen und Rahmenbedingungen. Die Detailziele bzw. Ziele für die Teilprojekte und -systeme sind festzulegen und Ziele bei Bedarf zu überarbeiten. Die Lösungsvarianten sind zu entwickeln und auf Zielkonformität zu prüfen. Detaillierte Lösung(en) mit ausführungsreifen Plänen müssen ausgearbeitet werden. Der Mittel-, Kosten- und Ressourcenbedarf ist zu überprüfen und anzupassen sowie die Qualifizierung der Softwarewerkzeuge entsprechend der ISO 26262 durchzuführen. Die Planungsergebnisse müssen mit allen Projektbeteiligten abgestimmt werden. Am Ende der Phase Projektplanung sind die Arbeitspakete definiert, die Aufwände und Kosten abgeschätzt, die Wirtschaftlichkeit des Projekts berechnet, die Abläufe strukturiert, die Kapazitätsplanung erstellt, die Termin- und Ressourcenplanung durchgeführt, die Releaseplanung abgestimmt, die Qualifizierung der Softwarewerkzeuge angestoßen und die Kickoff-Veranstaltung oder ein vergleichbarer offizieller Projektstart durchgeführt worden.

Projektdurchführung Der Prozess Projektdurchführung steuert zyklisch die Termine, Aufgaben, Risiken und offene Punkte über die gesamte operative Projektlaufzeit und kommuniziert diese an alle Projektbeteiligten. Der Zweck des Prozesses Projektdurchführung ist, die anfallenden Arbeiten zuzuweisen und zu verfolgen sowie erzielte Fortschritte zu kommunizieren und ggf. benötigte Korrekturmaßnahmen einzuleiten, damit das Projekt innerhalb seiner Toleranzen (Termine, Kosten, Qualität, s. o.) bleibt. Das Ziel ist es, sicherzustellen, dass alle Arbeiten überwacht und gesteuert werden und die Risiken sowie die offenen Punkte unter Kontrolle sind.

2.5

Übergreifende Prozesse der Softwareentwicklung

63

Die Aufgaben des Prozesses wiederholen sich in abgestimmten Zyklen über den gesamten operativen Projektverlauf hinweg. Nach der Abstimmung des Releaseplans werden die Arbeitspakete und Projektrisiken verfolgt, die Projektzeitpläne gepflegt und die Regeltermine durchgeführt. Nach Bedarf sind Statusberichte zu erstellen und zu kommunizieren sowie das Projekthandbuch zu aktualisieren und zu prüfen. Nach erfolgreicher Durchführung des Prozesses im Projekt ist der Release-Plan auf dem aktuellen Stand freigegeben und kommuniziert, die Arbeitspaketeliste vervollständigt, der Projektzeitplan gepflegt und kommuniziert. Die Risikoverfolgungsliste ist aktualisiert und Maßnahmen abgeleitet. Die Offene-Punkte-Liste ist gepflegt und kommuniziert sowie alle Regeltermine abgehalten. Die Statusberichte sind erstellt und kommuniziert, sowie das Projekthandbuch auf dem aktuellen Stand freigegeben und kommuniziert.

Projektabschluss Der Projektabschluss definiert einen Zeitpunkt, an dem ein eindeutiges Ende des Projekts erreicht wird, die Ergebnisse übergeben werden und das Projektteam aufgelöst werden kann. Der Zweck des Prozesses ist es, einen Zeitpunkt zu definieren, an dem die Abnahme des Projekts bestätigt wird. Es ist anzuerkennen, dass die ursprünglich in dem Projektauftrag definierten Ziele (und genehmigten Änderungen der Ziele) erreicht worden sind, damit die Ergebnisse an den Auftraggeber übergeben und das Projektteam aufgelöst werden kann. Ziel des Prozesses ist es, zu verifizieren, dass das Projekt abgenommen werden kann. Es ist sicherzustellen, dass für alle offenen Punkte und Risiken Empfehlungen für Folgeaktionen vorliegen und die Erfahrungen dokumentiert sind. Beim Projektabschlusses werden die positiven und negativen Projekterfahrungen gesammelt und dokumentiert. Das Projektabschlussprotokoll wird erstellt und die tolerierten Abweichungen von den initialen Projektzielen dokumentiert. Bei Bedarf werden notwendige Nachbesserungen festlegt, die Projektergebnisse übergeben, die Projektleitung entlastet und das Projektteam wieder in die Struktur der Organisation eingegliedert. Nach erfolgreicher Durchführung des Prozesses sind die positiven und negativen Projekterfahrungen dokumentiert, das Projektabschlussprotokoll erstellt und die tolerierten Abweichungen von den initialen Projektzielen dokumentiert. Die notwendigen Nachbesserungen sind festgelegt und die Projektergebnisse an den Auftraggeber übergeben. Die Projektleitung wird vom Auftraggeber entlastet, das Projektteam in die Organisation wieder eingegliedert und das Projekt damit offiziell beendet. Im Sinne der Pflege und ggf. Nachbesserungen an einem Produkt aus den Erfahrungen, die durch seinen Einsatz geschehen bietet es sich an, die daraus resultierenden Aktivitäten als neues Projekt aufzusetzen.

64

2.5.4

2 Softwareentwicklungsprozess in der Automobilindustrie

Risikomanagement

Das Risikomanagement ist in der Darstellung der übergreifenden Prozesse bis hier nicht explizit gezeigt worden. Es handelt sich um einen Prozess, der sich durch alle bisher gezeigten übergreifenden Prozesse des Projektmanagements zieht. Das Risikomanagement ist nicht nur im Finanzsektor eine wichtige Ergänzung zu den Tätigkeiten innerhalb der Compliance-Aktivitäten von Unternehmen und wird oft zentral in einer entsprechenden Organisationseinheit gehalten. Hier soll eine konkrete Umsetzung der in der Lehre, Literatur und auch oft in Anforderungen sehr abstrakt dargestellten Vorgehensweise für Softwareprojekte in der Automobilindustrie vorgeschlagen werden. Diese Methode regelt die Mindeststandards für das Managen von Risiken und die Koordination der dafür notwendigen Tätigkeiten in Projekten. Sie setzt den Rahmen für das Identifizieren, Analysieren, Bewerten und Überwachen von Risiken, sowie den Umgang mit diesen Informationen. Das Einhalten dieser Regelungen unterstützt einen geordneten Arbeitsablauf (geplantes, dokumentiertes, qualitätsgesichertes Vorgehen). Die Strategie für das Beherrschen von Risiken beinhaltet ein frühes (rechtzeitiges) Erkennen von Risiken, das Zuordnen der Risiken in die der Fachgruppe bzw. das Herunterbrechen der Risiken und deren Zuordnung zu Bauteilen bzw. Systemen. Die Analyse der Risiken auf Bauteil und Systemebene sowie die Definition und Durchführung von abgestimmten Maßnahmen und die kontinuierliche Verfolgung der Risiken und Maßnahmen sowie die Konsolidierung der Informationen zu Risiken auf Bauteil und Systemebene und die Eskalation in die zugehörige Fachgruppe sowie in die Linie (disziplinarische Organisationform) der Unternehmensstruktur. Die konkreten Erfahrungen sind zu dokumentieren (Lessons Learned), um diese für Folgeprojekte bereitzustellen. Zuständig und verantwortlich für die Durchführung des Risikomanagements ist der jeweilige Projektleiter. Verpflichtet und befugt für die Mitwirkung im Risikomanagement ist jeder Mitarbeiter des Projekts. Als Basis für die Projektplanung sind die relevanten Risiken vor dem Projektstart zu erfassen und zu bewerten. Eine angemessene Planung berücksichtigt die Risiken, und ignoriert sie nicht in Form einer zu optimistischen Planung zum zweifelhaften Zweck der Bewerbung um ein Projekt.

Identifizieren und Bewerten der einzelnen Risiken Zur erstmaligen Identifikation ist eine Risikosammlung durchzuführen. Es hat sich bewährt, dies in der Form eines extern moderierten Workshops durchzuführen, an dem die relevanten Projektbeteiligten und weitere betroffene Personen teilnehmen und der Moderator Erfahrungen im Risikomanagement einbringt. Unterstützt wird die Identifikation der Risiken z. B. durch die Anwendung von QS-Methoden wie FMEA (Failure Mode Effects Analysis – Fehlermöglichkeits- und Einflussanalyse). Basierend auf der Themenpriorisierung werden die von den Teilnehmern genannten Risiken schriftlich festgehalten und strukturiert.

2.5

Übergreifende Prozesse der Softwareentwicklung

65

Für jedes identifizierte Risiko ist gemeinsam eine Einschätzung für die Eintrittswahrscheinlichkeit (EW) und die potenzielle Schadenshöhe (PSH) durchzuführen. Daraus errechnet sich die Risikopriorität 1, 2 oder 3. Die einzelnen Risiken und deren Bewertung werden in der initialen Risikoverfolgungsliste dokumentiert.

Analyse von Risiken Zumindest bei Risiken mit der Risikopriorität 1 (hoch) ist eine detailliertere Analyse durchzuführen. Schriftlich anzuführen sind die mögliche Ursachen bzw. das Szenario für den Eintritt des Risikos. Was muss passieren, damit das Risiko eintritt? Die möglichen Folgen im Risikofall und deren Auswirkungen. Welche weiteren Effekte treten ein, wenn das Risiko eintritt? Welche technischen Alternativen gibt es und welche organisatorischen Szenarien könnten helfen, das Risiko zu vermindern oder zu vermeiden?

Risikobewertung Ein Risiko besteht aus einer eindeutigen Bezeichnung und Beschreibung des Risikos, der Eintrittswahrscheinlichkeit (EW) des jeweiligen Risikos, angegeben in % oder einem Begriff oder einer Aussage wie • • • • •

praktisch auszuschließen, unwahrscheinlich, Die Wahrscheinlichkeit des Eintritts ist 50:50, Die Wahrscheinlichkeit des Eintritts ist hoch, Das Risiko wird mit Sicherheit eintreten.

Weitere Aspekte sind die potenzielle Schadenshöhe (PSH), angegeben in e, der Terminverzug, oder die gern verwendeten Ampeldarstellungen rot, gelb, grün sowie die Art des Risikos (T Time; C Cost; Q Quality) und die Risikopriorität.

Priorisierung Mit der Priorisierung werden die Schwerpunkte für die Risikobetrachtung gesetzt: Die Priorisierung enthält die Themen, welche je nach Projekttyp entsprechende Teilaspekte des Projektes umfasst. Die sind beispielsweise alle dem Projekt zugeordneten Bauteile oder alle Funktionen laut Funktionsliste. Zu jedem Thema sind Indikatoren für die Themenpriorität anzuführen (z. B. Komplexität, Innovationsgrad, Sicherheitsrelevanz, etc.). Bei jedem Thema ist als Bewertung der Erfüllungsgrad des Indikators anzugeben, z. B. Skala 1 bis n oder in %. Basierend auf den Bewertungen ist für jedes Thema eine Kennzahl zu berechnen (z. B. gewichtetes Produkt der einzelnen Bewertungen). Diese Kennzahl dient dann zur Zuordnung zu den Prioritätsstufen I, II, oder III. Allen identifizierten Risiken sind präventive und korrektive Maßnahmen zuzuordnen sowie ein Risikotransfer durchzuführen.

66

2 Softwareentwicklungsprozess in der Automobilindustrie

Risikoverfolgungsliste Die Risikoverfolgungsliste umfasst für jedes Risiko mindestens eine wirksame Gegenmaßnahme, d. h. die Vorstellung von Maßnahmen zur Risikominderung bzw. Schwächung sowie eine belegbare Kontrollaktivität: Diese Aktivität soll die Wirksamkeit der Maßnahme bewerten und Aussagen treffen, ob eine Maßnahme umgesetzt wurde, die präventiv oder im Notfall greift. Es wird ein Termin zur Risiko-Neubewertung geplant und eine verantwortliche Person für die Risikoüberwachung definiert. Mögliche Anmerkungen zur Risikosammlung können präventive Maßnahmen zur Risikovermeidung samt Verantwortlichen, korrektive Maßnahmen bei Risikoeintritt (Notfallplan) samt Verantwortlichen, Information zu bereits durchgeführten Maßnahmen, Aufzeichnungen über durchgeführte Neubewertungen und Statusänderungen sowie der Status des Risikos (eingetreten, offen, erledigt, Maßnahmen aktiv) sein. Das Risikomanagement ist wie alle übergreifenden Prozesse eine kontinuierliche Tätigkeit im Entwicklungsprozess. Es kann im Rahmen der Grundsätze Governance, Risk and Compliance einer Firma explizit gefordert und konkret ausgestaltet sein. Gerade diese Aktivität wir oft im Rahmen der Assessments und Audits zur Produktzulassung oder bei der Untersuchung der Ursachen eingetretener Schäden geprüft.

2.5.5

Lieferantenmanagement

Das Lieferantenmanagement beschreibt die Gestaltung, Lenkung und Entwicklung von allgemeinen Abnehmer-Lieferanten-Beziehungen. Mit der Änderung der Gesetzeslage zur Arbeitnehmerüberlassung und deren konkreter Umsetzung zum Zeitpunkt der Erstellung des Buchs kommt diesem Prozess gerade in der Entwicklung eine besondere Bedeutung zu. Es ist im Vorfeld festzulegen und entsprechend auszugestalten, ob es sich bei der Beziehung um eine Arbeitnehmerüberlassung oder eine Gewerkevergabe handeln soll. Das Lieferantenmanagement unterstützt die Bemühungen, gemeinsam mit dem Lieferanten die Produkte schneller, günstiger und qualitativ optimal zu entwickeln. Es dient in seiner Gesamtheit zur Kontrolle des Lieferanten, um frühzeitig im Zuge des Risikomanagements festzustellen, ob der Lieferant oder Gewerkenehmer ggf. nicht normund spezifikationskonform Leistungen erbringt. Des Weiteren dient es zur Absicherung und zur Nachweisbarkeit, alles Erdenkliche dafür getan zu haben, um zukünftige Risiken, Fehler und Auffälligkeiten im späteren Serienbetrieb des entwickelten Produktes zu vermeiden und im Zweifel vor Gericht nachzuweisen. Das Ziel ist eine professionelle und dennoch partnerschaftlich enge und intensive Zusammenarbeit mit dem Lieferanten, um „Reibungsverluste“ bei der Zusammenarbeit zu vermeiden und um gleichermaßen Zeit, Kosten und Ressourcen zu sparen sowie dabei trotzdem die geforderte Qualität der Leistungen zu erzielen. Das Lieferantenmanagement besteht bei den hier betrachteten Entwicklungsprojekten aus den Prozessen Lieferantenauswahl, Lieferantensteuerung und letztendlich auch

2.5

Übergreifende Prozesse der Softwareentwicklung

67

der Lieferantenausphasung am Ende oder sogar während des Projekts. Es wird nicht auf die sozialen oder arbeitsrechtlichen Rahmenbedingungen zur Beschäftigung und Vertragsgestaltung der beim Gewerkenehmer angestellten Mitarbeiter eingegangen, die beim Entwickler oder Hersteller des Produkts vor Ort die Gewerke oder Dienstleistungen erbringen.

Lieferantenauswahl Die Lieferantenauswahl soll potenzielle Lieferanten identifizieren. Das Ziel der Lieferantenauswahl ist, eine einheitliche Methodik für die Analyse potenzieller und bestehender Lieferanten bereitzustellen, um basierend auf den Ergebnissen strategische Entscheidungen zu treffen. Auf operativer Ebene bedeutet dies, die Leistung der Lieferanten vergleichbar zu machen, Optimierungspotentiale aufzudecken und die Beschaffungskosten zu senken. Auf Basis des Qualifizierungs- und Bewertungsberichts ist es möglich, die für das angeforderte Produkt jederzeit geeignete Lieferantenauswahl zu treffen und damit das optimale Preis-Leistungsverhältnis zu erhalten. Die Lieferantenauswahl beinhaltet die Suche nach potenziell geeigneten neuen oder bestehenden Lieferanten (intern oder extern) sowie die Festlegung von Kriterien und die Auswahl der Lieferanten nach der Bewertung. Weiterhin sind die Qualifizierung der Lieferanten und deren Leistungen, die Überprüfung der Lieferanten sowie die Beauftragung der Lieferanten notwendig. Das Ergebnis der Lieferantenauswahl muss mindestens sein, dass alle Lieferanten aus dem Lieferantenpool folgende geforderten Kriterien erfüllen: • • • • •

Qualität, Service, Lieferzeit, Lieferfähigkeit, Preis.

Die Lieferantenauswahl wird sowohl für die Auswahl neuer Lieferanten als auch für die auftragsbezogene Auswahl bestehender Lieferanten genutzt. Die Auswahl schließt sowohl externe als auch interne Lieferanten ein. Interne Lieferanten können dabei eigene Komponentenwerke oder Entwicklungsabteilungen eines Unternehmens sein.

Lieferantensteuerung Die Lieferantensteuerung beinhaltet die stetige Beobachtung des Lieferanten, sowie die Einleitung von Maßnahmen, sofern der Lieferant nicht gemäß den Anforderungen die vertraglichen Leistungen erbringt oder nachbessert. Die Lieferantensteuerung soll den Auftraggeber über den gesamten Projektverlauf stets in die Lage versetzen, genau zu wissen, welchen Status das Projekt bei seinem Lieferanten

68

2 Softwareentwicklungsprozess in der Automobilindustrie

hat und welchem Reifegrad dessen Leistungen entsprechen. Durch die Lieferantensteuerung soll frühzeitig erkannt werden, ob der Lieferant gemäß den Anforderungen Qualität, Quantität, Kosten und Termine einhält. Geschieht dies nicht, werden über die Lieferantensteuerung jene Maßnahmen kontrolliert, die den Lieferanten in die Lage versetzen, genau jene Parameter wieder angebots- und auftragskonform durch Nachbesserung einzuhalten. Die Lieferantensteuerung beinhaltet die genaue Definition der Lieferantenkommunikation, deren Wege, Inhalte, Regeln und Eskalationsmechanismen. Wesentliche Punkte sind die regelmäßige Überwachung und Kontrolle des Lieferanten und dessen Leistungen sowie die Prüfung und Kontrolle alle eingehenden Lieferobjekte und Arbeitsprodukte des Lieferanten. Das ganzheitliche Claim-Management (Die Einforderung der Nachbesserung oder Kompensation bei Abweichungen) über den gesamten Projektlebenszyklus muss ebenfalls definiert werden. Die Lieferantensteuerung erfolgt über die gesamte Dauer der Lieferantenbeauftragung. Sie erfolgt zu bestimmten Themen in einem regelmäßigen Turnus, teilweise beim Lieferanten vor Ort. Reviews, Assessments und Audits ergänzen die Lieferantensteuerung und bilden eine Informationsbasis für Steuerungsmaßnahmen durch den Auftraggeber. Das Ergebnis der Lieferantensteuerung muss mindestens sein, dass der Lieferant folgende Projektziele einhält: • Qualitätsziele • Kostenziele • Terminziele Ist dies nicht gegeben, sorgt die Lieferantensteuerung dafür, Verfehlungen durch den Lieferanten frühzeitig zu erkennen um ggf. qualifiziert gegensteuern zu können und somit die Risiken der Ergebnisabweichungen zu mindern oder das Claim-Management einzuleiten.

Lieferantenausphasung Die Lieferantenausphasung ist die gezielte Beendigung des Geschäftsverhältnisses, falls der Lieferant die geforderten Leistungen nicht gemäß Vertrag oder der eigenen Bedürfnisse erfüllt oder angemessen nachbessert. Ziel der Lieferantenausphasung ist die gezielte und geplante Beendigung des Geschäftsverhältnisses. Es soll ferner sichergestellt werden, dass keine neuen Bestellungen für den betreffenden Lieferanten mehr generiert werden. Das Ergebnis der Lieferantenausphasung sollte die Definition eines genauen Zeitplans zur Ausphasung des Lieferanten, die Reduktion der Bestellvolumina bis auf „0“, und die Sicherstellung, dass der Lieferant keinerlei strategische Bedeutung mehr für das Projekt aufweist beinhalten. Die Kommunikation der offiziellen Beendigung des Geschäftsverhältnisses an den Lieferanten, die Kündigung der Lieferantenverträge und die Entfernung des Lieferanten aus den Systemen sind die abschließenden Schritte.

2.5

Übergreifende Prozesse der Softwareentwicklung

2.5.6

69

Änderungsmanagement

Das Änderungsmanagement beschreibt jegliche Änderungen von technischen Anforderungen am Produkt bis zur Anpassung von organisatorischen Rahmenbedingungen im Projektverlauf oder Prozessen.

Vorbereitung Änderungsmanagement Dieser Prozess beschreibt die vorbereitenden Tätigkeiten für das Änderungsmanagement. Ziel des Prozesses ist, eine funktionsfähige Umgebung für die Verfolgung von Änderungen zu schaffen. Der Änderungsmanagementverantwortliche erstellt eine Änderungsmanagementstrategie. Anschließend wird diese mit dem gewählten System (hierzu gibt es etliche Systeme am Markt der Entwicklungswerkzeughersteller) umgesetzt und getestet. Nach den erfolgreichen Tests ist das System bereit zur Nutzung und kann zur Lösung von Problemen eingesetzt werden. Zusätzlich wird für die Projektmitarbeiter ein methodenspezifischer User-Guide zur Verfügung gestellt. Als Ergebnis ist die Strategie für das Änderungsmanagement definiert und umgesetzt. Das Änderungsmanagementsystem ist aufgesetzt und zur Verwendung freigegeben. Die Nutzer der Systems können über einen User-Guide mit dem System arbeiten.

Änderung Dieser Prozess beschreibt die operativen Tätigkeiten für das Änderungsmanagement. Das Ziel des Prozesses ist, eine Änderung nachverfolgbar zu erfassen und umzusetzen. Die Änderung wird durch einen Projektmitarbeiter im System erfasst. Diese Änderung wird analysiert und über die weitere Vorgehensweise entschieden. Dafür wird oft ein Gremium, das sogenannte „Change Control Board“ eingerichtet, um das Mehraugenprinzip zu gewährleisten. Die Änderung wird in dem jeweiligen Entwicklungsprozess oder der Organisation des Projekts umgesetzt. Es ist ein ebenfalls vom zugehörigen Entwicklungsprozess abhängiger Test der Änderung notwendig. Bei einer Organisationsänderung ist diese über die Betätigung funktionierender Prozesse im Mehraugenprinzip zu validieren. Abschließend wird geprüft, ob alle Formalien zur Änderung erfüllt wurden. Am Ende ist die Änderung eindeutig erfasst, eingeplant und ggf. bereits umgesetzt und gereviewed.

2.5.7

Konfigurationsmanagement

Das Konfigurationsmanagement ist ein unterstützender Prozess für alle Entwicklungsaktivitäten. Es legt fest, welche Versionen der Software, Dokumentation und weitere Dateien oder Arbeitsprodukte als Zusammenfassung in bestimmten Baselines in den unterschiedlichen Projektphasen ausgeliefert werden. Weiterhin stellt es die Möglichkeiten für eine verteilte, parallele Entwicklung und konsistente Zusammenführung der Ergebnisse zur Verfügung. Hier soll das konkrete Vorgehen im Projekt im Fokus stehen.

70

2 Softwareentwicklungsprozess in der Automobilindustrie

Zu Projektanfang muss eine Umgebung mit Konfigurationsmanagement-Werkzeugen und -Regeln etabliert werden. Nach Abschluss des Aufbaus unterstützt das Konfigurationsmanagement den Entwicklungsablauf durch zyklisch wiederkehrende Aktivitäten.

Konfigurationsmanagement-Aufbau Dieser Prozess beschreibt den Aufbau einer betriebsbereiten KonfigurationsmanagementUmgebung in Form eines Verwaltungswerkzeugs als IT-System oder Datenbank (auch hierzu gibt es etliche Systeme am Markt der Entwicklungswerkzeughersteller, oft sind sie mit dem Änderungsmanagement integriert). Ziel dieses Prozesses ist es, ein Konfigurationsmanagement-System gemäß den Projektanforderungen aufzusetzen. Dieser Prozess schafft die Rahmenbedingungen, um die Konfigurationsmanagementziele (z. B. die Integrität der Produkte) zu gewährleisten. Der Konfigurationsmanager ist für das initiale Aufsetzen der Konfigurationsmanagement-Umgebung für ein neues Projekt verantwortlich. Es wird eine reduzierte Konfigurationsmanagement-Umgebung erstellt, die es erlaubt, das Projektmanagement und die Systemanalysen vorzunehmen. Schon hier hat der Konfigurationsmanager sicherzustellen, dass eine Zugangskontrolle und eine Datensicherung der Konfigurationsmanagement-Umgebung existiert. Mit der Kenntnis der groben Systemarchitektur kann eine feinere Planung der KonfigurationsmanagementVorgänge erfolgen, sodass daraus resultierende Konfigurationsmanagement-Strukturen, Konfigurationsmanagement-Objekte, Releases und Lieferbeziehungen bestimmt und geplant werden können. Es werden die notwendigen IT-Ressourcen durch den Konfigurationsmanager beantragt, die Systeme entsprechend erweitert und die Festlegungen im Konfigurationsmanagement-Plan festgehalten. Eine Anleitung und Schulung für die Nutzer der Konfigurationsmanagement Umgebung ist ebenfalls zu erstellen. Als Ergebnisse sind die Anforderungen an das Konfigurationsmanagement-System definiert und festgehalten und die benötigten Strukturen und Releases in den Konfigurationsmanagement-Werkzeugen aufgesetzt. Diese Strukturen unterliegen einer Datensicherung und einer Zugangskontrolle. Die Konfigurationsmanagement-Objekte sind identifiziert und beschrieben und die Lieferbeziehungen für das Projekt sind beschrieben und ggf. implementiert. Die automatischen Prozesse zur Code- oder Objekterzeugung sind beschrieben und implementiert. Der Konfigurationsmanagement-Plan ist erstellt und freigegeben sowie die notwendigen Konfigurationsmanagement-Verfahren beschrieben und dem Projekt-Team bekannt. Die Konfigurationsmanagement-Umgebung ist gegen die Anforderungen geprüft und für den Betrieb freigegeben. Eine Datensicherung ist sichergestellt.

Konfigurationsmanagement Betrieb Dieser Prozess beschreibt die Durchführung der konkreten KonfigurationsmanagementTätigkeiten. Das Ziel des Prozesses ist es, die Zusammenstellung von Arbeitsergebnissen allen am Projekt beteiligten Parteien in richtiger und vollständiger Art und Weise zur

2.5

Übergreifende Prozesse der Softwareentwicklung

71

Verfügung zu stellen. Dabei ist es wichtig, dass die Inhalte der Arbeitsergebnisse und Zusammenstellungen zu einem bestimmten Zeitpunkt beschrieben werden können. Der Prozess Konfigurationsmanagement-Betrieb beinhaltet die Konfigurationsmanagement-Aktivitäten, die nach dem KonfigurationsmanagementAufbau regelmäßig erforderlich sind. Die anfallenden Aufgaben werden vom Konfigurationsmanager organisiert und überprüft. Die Durchführung obliegt je nach Aktivität den Projektmitarbeitern, dem Buildmanager oder dem Konfigurationsmanager selbst. Dabei ist die Reihenfolge der Aktivitäten durch die Projektvorgänge gesteuert, sodass sich eine andere Reihenfolge der Aktivitäten ergeben kann als hier dargestellt. Die Auslöser für die Aktivitäten sind immer von den Entwicklungsprozessen getrieben und werden (meist) durch Änderungsanträge (Changerequests) im Rahmen des eng verwobenen Änderungsmanagements ausgelöst. Beispiele hierfür sind das Einchecken von Dateien, das Erstellen von Baselines oder Produkten sowie der Abschluss von Tests. Eine „Änderung“ ist damit auch ein einfacher operativer Arbeitsauftrag mit einem Arbeitsprodukt. Ebenso können Aktivitäten dieses Prozesses durch Entscheidungen des Projektmanagements ausgelöst werden (z. B. durch eine veränderte Release-Planung oder die nachträglich geplante Erklärung einer Freigabe). Die Erstellung von Produktkonfigurationen und deren Software-Produkten werden vom Buildmanager ausgeführt. Besteht eine Produktkonfiguration aus Teilen, die in unterschiedlichen Umgebungen oder Organisationen entwickelt worden ist, kann der Einsatz eines Integrationsmanagers oder -testers den Buildmanager unterstützen. Begleitende Aktivitäten finden regelmäßig statt – unabhängig vom Entwicklungsfortschritt. Zu diesen Aktivitäten gehört die Konfigurationsmanagement Reporterstellung. Die Ergebnisse sind gepflegte und beschriebene Konfigurationselemente (Dateien, Baselines, Produkte) und der Konfigurationsmanagement-Plan.

2.5.8

Problemlösungsmanagement

Das Problemlösungsmanagement beschreibt jegliche Änderungen aufgrund von technischen Problemen über organisatorische Rahmenbedingungen im Projekt bis zu allgemeinen Problemen der an der Entwicklung beteiligten Organisationseinheiten und Lieferanten. Das Problemlösungsmanagement muss mit einer Eskalationsstrategie verbunden sein, die nicht durch die disziplinarische Struktur des Unternehmens übergangen werden kann. Positive Beispiele sind ein anonymes Hinweisgebersystem oder Ombudsmänner. Im Folgenden ist der Fokus stärker auf die konkreten Arbeitsschritte im Projekt gelegt, in dem das Problemlösungsmanagement als normale Arbeitstätigkeit verstanden wird.

72

2 Softwareentwicklungsprozess in der Automobilindustrie

Vorbereitung Problemlösungsmanagement Dieser Prozess beschreibt die vorbereitenden Tätigkeiten für das Problemlösungsmanagement. Das Ziel des Prozesses ist es, eine funktionsfähige Umgebung für die Verfolgung von Problemen zu schaffen. Der Problemlösungsmanagementverantwortliche erstellt eine Problemlösungsmanagementstrategie, die mit dem gewählten System umgesetzt und getestet wird. Nach erfolgreichen Tests ist das System zur Nutzung bereit und kann zur Lösung von Problemen eingesetzt werden. Es wird ein Problemlösungsmethodenhandbuch für die Projektmitarbeiter zur Verfügung gestellt. Als Ergebnisse sind die Strategie für das Problemlösungsmanagement definiert und umgesetzt, das Problemlösungsmanagementsystem ist aufgesetzt und zur Verwendung freigegeben und die Nutzer des Systems können mithilfe eines Problemlösungsmethodenhandbuchs mit dem System arbeiten.

Problemlösung Dieser Prozess beschreibt die operativen Tätigkeiten für das Problemlösungsmanagement. Das Ziel des Prozesses ist die Unterstützung der Mitarbeiter des Projekts bei der Lösung von Problemen, die z. B. nicht durch einen Projektmitarbeiter selbst gelöst werden können oder eine Einplanung der Bearbeitung im Projektplan erfordern sowie einen hohen Ressourcenaufwand benötigen und vom (Teil-)Projektleiter autorisiert werden müssen. Das Problem oder dessen Lösung muss dokumentiert werden. Ein Problem ist eine Aufgabe mit Handlungsbedarf, z. B. eine schwierige, ungelöste Aufgabe, schwer zu beantwortende Frage, komplizierte Fragestellung, allgemeine Schwierigkeit. Oft sind Probleme unterteilt in „schlecht strukturierte Probleme“ und „gut strukturierte Probleme“. Um ein Problem lösen zu können, kann es sinnvoll sein, es in einfachere Unteraufgaben zu zerteilen oder auf ein bereits gelöstes Problem zurückzuführen. Hierbei ist ein personenunabhängiger, gelebter Prozess „Lessons-Learned“ im Rahmen von Projektabschlüssen sehr hilfreich. Das konkrete Problemlösen geschieht zwischen zwei möglichen Extremen: • Versuch und Irrtum (engl. trial and error), • Lernen durch Einsicht. Ein Problem wird von einem Projektmitarbeiter zur Kenntnis genommen. Dabei kann es sich um organisatorische Probleme, technische Probleme bezüglich des zu entwickelnden Produktes oder IT-technische Probleme handeln. Zuerst muss der Mitarbeiter bewerten, welcher Art das Problem ist. Organisatorische Probleme werden mündlich oder schriftlich der Projektleitung gemeldet, die sich im Rahmen der regelmäßigen Projektrunden oder mit außerordentlichen Maßnahmen für eine Abstellung des Problems sorgt. Offene organisatorische Probleme werden dann im Rahmen der OPL (Offene-Punkte-Liste) der Projektstatusrunde verfolgt und zum Abschluss gebracht. IT-technische Probleme werden an eine zentrale IT-Stelle

2.5

Übergreifende Prozesse der Softwareentwicklung

73

gemeldet (soweit vorhanden) und dort erfasst. Diese beauftragt die zuständige Stelle mit einer Problemlösung und verfolgt die Problemlösung. Des Weiteren befasst sich der Prozess der Problemlösung nur mit der Abstellung technischer Probleme an dem zu entwickelnden Produkt. Wird ein technisches Problem entdeckt, so ist der übliche Meldeweg die Erfassung als Problemmeldung im Problemmanagementwerkzeug. Ist aber aufgrund des Problems Gefahr für Leib und Leben oder ein hoher wirtschaftlicher Schaden für das Unternehmen zu erwarten, so ist Projektleitung unmittelbar mündlich oder schriftlich zu verständigen. Hierfür muss wie oben erläutert eine Eskalationsstrategie vereinbart werden. Das Problem wird durch einen Projektmitarbeiter im Problemmanagementwerkzeug erfasst. Anschließend wird das Problem analysiert und nach der Analyse über die weitere Vorgehensweise entschieden. Fällt die Entscheidung für eine Problemlösung, so ist sie gemäß dem zugehörigen Entwicklungsprozess umzusetzen, zu prüfen und ggf. zu akzeptieren. Falls die Problemlösung nicht akzeptiert wurde, ist sie in einem weiteren Entwicklungsdurchlauf zu überarbeiten. Wenn die Problemlösung in der Prüfphase akzeptiert wurde, wird zum Ende des Problemlösungsprozesses die vollständige Durchführung aller Aktivtäten gemäß dem Prozess überprüft und danach die Problemmeldung abgeschlossen. Als Ergebnis ist das Problem ist identifiziert und festgestellt, wie kritisch das Problem für das Projektergebnis ist. Falls nötig wurden Sofortmaßnahmen durchgeführt. Das Problem ist eindeutig erfasst und analysiert und die Problembehebung ist definiert. Für das Problem wurde eine Problemlösung umgesetzt die getestet ist und deren Testergebnisse dokumentiert sind.

Trendberichterstellung Dieser Prozess beschreibt die nach Absprache regelmäßige Erstellung von Trendberichten. Die Trendberichte werden dem Projektmanagement bereitgestellt. Ziel und Zweck dieses Prozesses ist es, Trends bei der Problemlösung zu identifizieren und zu visualisieren. Die aufbereiteten Metriken werden dem Projektmanagement zur weiteren Analyse und Ableiten von Maßnahmen bereitgestellt. Die Daten werden durch Report vom Problemlösungsmanagementverantwortlichen bereitgestellt. Die dort enthaltenen Daten werden durch den Projektcontroller in Form eines Trendberichts in eine Projektmanagement-geeignete Form aufbereitet, um beispielsweise häufig auftretende Probleme leicht erkennbar zu machen. Auch hier hat sich die Ampeldarstellung etabliert. Als Ergebnis ist der Problemtrendbericht erstellt.

2.5.9

Freigabemanagement

Die Prozesse des Freigabemanagements bilden die Übersicht zu den Freigabeaktivitäten, die in die Planungs-, Entwicklungs- und Absicherungsprozesse des restlichen Prozessmodells eingebettet sind.

74

2 Softwareentwicklungsprozess in der Automobilindustrie

Freigabevorbereitung Bei der Freigabevorbereitung werden alle benötigten Aktivitäten und Dokumente zur Vorbereitung einer Freigabe abgelegt. Zweck des Prozesses der Freigabevorbereitung ist eine übersichtliche Auflistung aller für die Vorbereitung einer Freigabe relevanten Aktivitäten und Dokumente. Die Freigabestrategie muss projekt- bzw. ausprägungsbedingt angepasst werden. Dazu gehört die projektabhängige Übersicht der Freigabearten und -stufen. Das impliziert auch die Anpassung der Dokumentenlandschaftsübersicht. Ferner muss in diesem Dokument definiert werden, wie im Rahmen des Projekts mit Freigaben nach Änderungen umgegangen wird. Bei einer Projektausprägung mit Lieferanten wird in diesem Dokument festgelegt, wer und wie die Freigabedokumente des Lieferanten geprüft werden. Die Vorbereitung der Freigabe erfolgt entsprechend der beschriebenen Abläufe in den einzelnen für die Freigabe relevanten Aktivitäten. Nach abgeschlossener Vorbereitung kann die Freigabe durchgeführt werden.

Freigabedurchführung Bei der Freigabedurchführung werden alle benötigten Aktivitäten und Dokumente zur Durchführung einer Freigabe abgelegt. Zweck des Prozesses Freigabedurchführung ist eine übersichtliche Auflistung aller für die Durchführung einer Freigabe relevanten Aktivitäten und Dokumente. Es wird der Softwarefreigabebericht erstellt, in dem die Vollständigkeit und Richtigkeit der erforderlichen Arbeitsprodukte (z. B. Softwareteststatusliste, SoftwareIntegrationsfreigabebericht, Software-Unitfreigabeberichte, Applikationshinweise) dokumentiert wird. Durch den Softwarefreigabebericht wird bestätigt, dass die erstellte Software gemäß den Inhalten der abgestimmten Prüflisten entwickelt und dokumentiert ist. Sollten Einschränkungen in dem Freigabebericht bestehen, werden diese dokumentiert. Die Durchführung der Freigabe erfolgt entsprechend der beschriebenen Abläufe in den einzelnen für die Freigabe relevanten Aktivitäten. Das Ergebnis des Prozesses „Freigabe durchführen“ ist eine abgeschlossene Freigabe. Das zusammenfassende Freigabedokument bestätigt dabei die Konformität der Aktivitäten und Arbeitsprodukte mit den für dieses Produkt vorgesehenen Prozessen. Sie wird im Mehraugenprinzip geprüft, unterschrieben und mit dem Produkt ausgeliefert. Die rechtliche Relevanz der Unterschriftsberechtigungen ist im Produkthaftungsgesetz geregelt und soll nicht Bestandteil dieses Buchs sein. Mit der durchgeführten Freigabe ist die Softwareentwicklung aus organisatorischer Sicht abgeschlossen. Es bleibt erneut zu betonen, dass es sich bei dieser Darstellung um generische „Best Practices“ aus der Erfahrung und nicht um konkrete Geschäftsprozesse handelt. Deren konkrete Ableitung obliegt jedem Unternehmen selbst und wird seiner Struktur, Kultur und auch der Sicherheitseinstufung des im jeweiligen Projekt zu entwickelnden Produkts entsprechen.

Literatur

[Ae1] Automotive Electronics Council (AEC), AEC – Q100 Rev – F.2: Stress Qualification for Integrated Circuits [Ai1] Aidam, R.; Kocher, P.; Recknagel, R.-J.: Alternative Seitencrashsensoren. VDI-Berichte Nr. 1794. VDI-Verlag, Düsseldorf (2003) [An1] Analog Devices: New iMEMS Angular Rate-Sensing Gyroscope. In: Analog Dialog 37-03. www.analog.com (2003) [As1] Assmann, B.: Technische Mechanik, Bd. 3: Kinematik und Kinetik, 11. Aufl. Oldenbourg (1998) [As2] ASAM Association for Standardisation of Automation- and Measuring Systems: ASAM MCD-2D (ODX) Data Model Specification, Version 2.0.1 (2005) [As3] Association for Standardisation of Automation and Measuring Systems. http://www.asa m.net [Au1] Audi AG: Selbststudienprogramm 325, Audi A6 ’05 Aggregate. – Firmenschrift [Au2] AUTOSAR Specification of RTE Software, Version 3.1.0, Release 4.0. www.autosar.org [Au3] AUTOSAR Methodology, Version 1.2.2, Rlease 3.2. www.autosar.org [Ba1] Balzert, H.: Lehrbuch der Software Technik, 2. Aufl. Spektrum, Heidelberg (2000) [Ba2] Bach, F., Hoffmann, V.: Hierarchische Busvernetzung – Multiplex Belichtungssteuerung. VDI-Berichte Nr. 1415, VDI-Verlag, Düsseldorf (1998) [Ba3] Basshuysen, R., van, Schäfer, F. (Hrsg.): Handbuch Verbrennungsmotor, 6. Aufl. Vieweg+Teubner, Wiesbaden (2012) [Ba4] Baumann, K.-H., Justen, R., Schöneburg, R.: Pre-Crash-Erkennung, ein neuer Weg in der Pkw-Sicherheit. VDI-Berichte Nr. 1471. VDI-Verlag, Düsseldorf (1999) [Ba5] Barr, M.: Programming Embedded Systems in C and C++. OReilly Media (1999) [Ba6] Bauer, M.: Vermessung und Ortung mit Satelliten: GPS und andere satellitengestützte Navigationssysteme, Wichmann (2002) [Ba7] Basshuysen, R. van: Ottomotor mit Direkteinspritzung, 2. Aufl. Vieweg+Teubner Verlag, Wiesbaden (2008) [Be1] Bender, M.: Introducing the MLX4 – a Microcontroller for LIN. In: Automotive Electronics, EDN Europe, S. 22–26. (2004) [Be2] Beck, K.: eXtreme Programming. Addison-Wesley, München (2000) [Be3] Beil, F.; Schürmann, B.: Integration der Bordnetzfunktion – ein Schritt zu einem Gesamtkonzept in der Fahrzeugelektrik. VDI Tagung Elektronik im Kraftfahrzeug, Baden-Baden (1996) [Be4] Berg, F. A.; Egelhaaf, M.; Krehl, M.; Niewöhner, W.: RolloverCrashtests und Unfallanalysen. VDI-Berichte Nr. 1794. VDI-Verlag, Düsseldorf (2003) © Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert an Springer-Verlag GmbH, DE, ein Teil von Springer Nature 2023 K. Reif und F. Wolf, Softwareentwicklung für Kraftfahrzeuge, https://doi.org/10.1007/978-3-662-68046-9

75

76

Literatur

[Be5] Berwanger, J., Kuffner, W., Peteratzinger, M., Reichart, G., Schedl, A.: FlexRayExploitation of a Standard and Future Prospects, Convergence Transportation Electronics Conference, SAE (2006) [Be6] Bertsche, B.; Lechner, G.: Zuverlässigkeit im Fahrzeug- und Maschinenbau, überarbeitete Auflage. Springer, Berlin, Heidelberg (2004) [Bi1] Bielefeld, M., Bieler, N.: Modulare Hybrid-Antriebssysteme. In: ATZ Automobiltechnische Zeitschrift, 107. Jahrgang, Ausgabe 9 (2005) [Bi2] Birolini, A.: Zuverlässigkeit von Geräten und Systemen. Springer, Berlin, Heidelberg (1997) [Bl1] Block, R.: 3-dimensionale numerische Feldberechnung und Simulation eines Klauenpolgenerators. Dissertation, RWTH Aachen, Shaker, (1993) [Bö1] Reif, K. (Hrsg.): Sensoren im Kraftfahrzeug. Vieweg+Teubner Verlag, Wiesbaden (2010) [Bö2] Börcsök, J.: IEC 61508 – eine Norm für viele Fälle. atp Heft 12 Jahrgang 44, S. 48–55 (2002) [Bo1] Robert Bosch GmbH (Hrsg.): Ottomotor-Management, 3. Aufl. Vieweg Verlag, Wiesbaden (2005) [Bo2] Reif, K. (Hrsg.): Sensoren im Kraftfahrzeug. Vieweg+Teubner Verlag, Wiesbaden (2010) [Bo3] Robert Bosch GmbH (Hrsg.): Konventionelle und elektronische Bremssysteme. Bosch Gelbe Reihe (2001) [Bo4] Robert Bosch GmbH (Hrsg.); Konrad Reif (Autor); Karl-Heinz Dietsche (Autor) und 160 weitere Autoren: Kraftfahrtechnisches Taschenbuch, 27. Aufl. Vieweg+Teubner Verlag, Wiesbaden (2011) [Bo5] Robert Bosch GmbH (Hrsg.): Dieselmotor-Management, 4. Aufl. Vieweg Verlag, Wiesbaden (2004) [Bo6] Robert Bosch GmbH: CAN Specification, Version 2.0. www.can.bosch.com. (1991) [Br1] Broekman, B., Notenboom, E.: Testing Embedded Software. Addison-Wesley, London (2003) [Br2] Broy, M.: Informatik. Eine grundlegende Einführung. Bd. 1 und 2. Springer Verlag, Berlin, Heidelberg (1998) [Br3] Brewerton, S., Schneider, R., Eberhard, D.: Implementation of a Basic SingleMicrocontroller Monitoring Concept for Safety Critical Systems on a Dual-Core Microcontroller SAE 2007 World Congress, 2007-01-1486 [Br4] Breuer, B. (Hrsg.); Bill, K.-H. (Hrsg.): Bremsenhandbuch. Vieweg Verlag, , vollst. überarb. u. erw. Auflage. (September 2006) [Br5] Brockhaus, Naturwissenschaften und Technik. Brockhaus Verlag, Wiesbaden (1989) [Bu1] Bubb, H.: Der Fahrprozess – Informationsverarbeitung durch den Fahrer. VDA Technischer Kongress, Stuttgart (2002) [Bu2] Bundesverband Güterkraftverkehr Logistik und Entsorgung (BGL) e. V., Daten & Fakten, Frankfurt a. M. (2010) [Ca1] CAN in Automation, CiA DS 301 V4.0.2: CANopen application layer and communication profile. www.can-cia.org. (2002) [Ch1] Chen, Yi-Fu: Bird-view Surrounding Monitor System for Parking Assistance, Institute of Computer Science and Information Engineering, National Central University (2008) [Cm1] Carnegie Mellon Software Engineering Institute (SEI): CMMI (Capability Maturity Model Integration). www.sei.cmu.edu/cmmi. (2002) [Co1] Cormen, T. H., Leiserson, C. E., Rivest, R. L., Stein, C.: Introduction to Algorithms, Second Edition. The MIT Press (2001) [Da1] Dach, H.; Gruhle, W.-D.; Köpf, P.: Pkw-Automatgetriebe, 2. Aufl. Verlag Moderne Industrie, Bonn (2001)

Literatur

77

[De1] Deutschmann, R., Günther, F., Roch, M., Reuss, H.-C., Kessler, F., Bohne, W., Krug, C.: Neue Strategien und Lösungen zur Testautomatisierung für die Validierung von Steuergeräte-Software. 6. Internationales Stuttgarter Symposium für Kraftfahrwesen und Verbrennungsmotoren, Stuttgart (2005) [De2] Decius, N., Klein, H., Fortkort, K., Olk, J., Tuttor, W., Schöllmann, M.: Modulare Bordnetzarchitektur für Hybridfahrzeuge. In: ATZ Automobiltechnische Zeitschrift. Jahrgang 107, Ausgabe 12 (2005) [Di1] Norm DIN 40042: Zuverlässigkeit elektrischer Geräte, Anlagen und Systeme – Begriffe (1970) [Di2] Norm DIN 40041: Zuverlässigkeit – Begriffe (1990) [Di3] Norm DIN VDE 31000 Teil 2: Allgemeine Leitsätze für das sicherheitsgerechte Gestalten technischer Erzeugnisse – Begriffe der Sicherheitstechnik – Grundbegriffe (1987) [Di4] Norm DIN 72552-2: Klemmenbezeichnungen in Kraftfahrzeugen, Bedeutungen (1971) [Di5] Norm DIN 44300: Informationsverarbeitung – Begriffe [Di6] Dijkstra, E.W.: Selected Writings on Computing: A Personal Perspective (Springer Series in Cognitive Development). Springer, Berlin (April 1982) [Di7] Dittmar, G., Nolting, J.: Wärmebildgeräte im Kraftfahrzeug zur verbesserten Nachtsicht, DGZfP-Berichtsband 86, Thermografie-Kolloquium an der Universität Stuttgart (2003) [Do1] Douglass, B. P.: Doing Hard Time. Object Technology Series. Addison-Wesley, MA (1999) [Do2] Donges, E.: Aspekte der aktiven Sicherheit bei der Führung von Personenkraftwagen. Automobilindustrie 27 (1982) [Ec1] Wirtschaftskommission der Vereinten Nationen für Europa (UN/ECE), Regelung Nr. 48: Einheitliche Bedingungen für die Genehmigung der Fahrzeuge hinsichtlich des Anbaus der Beleuchtungs- und Lichtsignaleinrichtungen (2004) [Ec2] Wirtschaftskommission der Vereinten Nationen für Europa (UN/ECE), Regelung Nr. 98: Einheitliche Bedingungen für die Genehmigung der Kraftfahrzeugscheinwerfer mit Gasentladungs-Lichtquellen (2003) [Ec3] Wirtschaftskommission der Vereinten Nationen für Europa (UN/ECE), Regelung Nr. 112: Einheitliche Vorschriften der Kraftfahrzeugscheinwerfer mit Glühlampen für asymmetrisches Abblendlicht oder Fernlicht oder für beides (2003) [Ec4] ECE-R 79: Uniform provisions concerning the approval of vehicles with regard to steering equipment (2005) [Ec5] Wiener Übereinkommen über den Straßenverkehr, Convention on road traffic, Wien (1968) [Eh1] Ehrfeld, W. (Hrsg.): Handbuch Mikrotechnik. Hanser-Verlag, München (2002) [Eh2] Ehlgen, T., Pajdla, T.: Monitoring surrounding areas of truck-trailer Combinations, Proceedings of the 5th International Conference on Computer Vision Systems (2007) [En1] Enders, M.: Intelligentes Pixellicht. VDI-Berichte Nr. 1646. VDI-Verlag, Düsseldorf (2001) [En2] Norm DIN EN 61082-1: Dokumente der Elektrotechnik – Teil 1: Allgemeine Regeln (1993) [En3] Norm DIN EN 50342: Blei-Akkumulatoren – Starterbatterien – Allgemeine Anforderungen, Prüfungen und Kennzeichnung (2001) [En4] d’Entremont, K.: Light-Duty Vehicles in Tripped-Rollover Situations. Safety Brief Bulletin 1(4) (1995) [Et1] Etschberger, K.: Controller-Area-Network. Grundlagen, Protokolle, Bausteine, Anwendungen. 3. Aufl. Hanser Verlag, München (2002) [Eu1] Europäische Gemeinschaft: Richtlinie 74/60/EWG des Rates zur Angleichung der Rechtsvorschriften der Mitgliedstaaten über die Innenausstattung der Kraftfahrzeuge (1974) [Eu2] Europäische Gemeinschaft: Richtlinie 2003/102/EG des Europäischen Parlaments und des Rates zum Schutz von Fußgängern und anderen ungeschützten Verkehrsteilnehmern vor

78

[Eu3]

[Fl1] [Fl2] [Fl3] [Fm1] [Fm2] [Fr1] [Fü1] [Ga1] [Ge1] [Gi1] [Ha1] [Gr1]

[Gr2] [Gr3] [Gr4]

[Gu1]

[Ha1] [Ha2] [Ha3] [He1] [He2]

[He3] [He4]

Literatur und bei Kollisionen mit Kraftfahrzeugen und zur Änderung der Richtlinie 70/156/EWG des Rates (2003) Europäische Gemeinschaft: Richtlinie 70/157/EWG des Rates zur Angleichung der Rechtsvorschriften der Mitgliedstaaten über den zulässigen Geräuschpegel und die Auspuffvorrichtung von Kraftfahrzeugen (1970) FlexRay Communications System. Protocol Specification Version 2.0. www.flexray.com. (2004) FlexRay Communications System. Bus Guardian Specification Version 2.0. www.flexray. com. (2004) FlexRay Communications System. Electrical Physical Layer Specification Version 2.0. www.flexray.com. (2004) U.S. Department of Transportation National Highway Traffic Safety Administration: Federal Motor Vehicle Safety Standard FMVSS 118 (1971) U.S. Department of Transportation National Highway Traffic Safety Administration: Federal Motor Vehicle Safety Standards, Part 571, Safety Assurance (1998) Fröhlich, T.; Hamm, M.: Einfluss von adaptiven Scheinwerfer-Technologien auf die zukünftige Bordnetzstruktur. VDI-Berichte Nr. 1789. VDI-Verlag, Düsseldorf (2003) Fürst, S. u. a.: AUTOSAR – A Worldwide Standard is on the Road, 14th International VDI Congress Electronic Systems for Vehicles, Baden-Baden (2009) Gad-el-Hak, M. (Hrsg.): The MEMS-Handbook. CRC Press, London (2002) Gelb, A.: Applied Optimal Estimation. M.I.T. Press, Cambridge, Massachusetts (1992) Gintner, K.: Ein Sensor auf Basis des anisotropen magnetoresistiven Effektes. Univ., Diss, Erlangen (1999) Halliday, D., Resnick, R.: Fundamentals of Physics. Wiley, New York (1988) Grezmba, A.: LIN-Bus – Die Technologie. Teil 1: Netzwerkarchitektur mechatronischer Systeme und Übersicht über die Technologie sowie das Protokoll In: Elektronik Automotive, Heft 4 (2003) Grezmba, A.: LIN-Bus – Die Technologie. Teil 2: Fehlererkennung und Fehlerbehandlung, Netzwerkmanagement, Bitübertragungsschicht. In: Elektronik Automotive, Heft 5 (2003) Grezmba, A.: LIN-Bus – Die Technologie. Teil 4: Hardware – Transceiver und Controller. In: Elektronik Automotive, Heft 1 (2004) Gruhle, W.-D., Jauch, F., Knapp, T., Rüchardt, C.: Modellgestützte Applikation einer „Geregelten Wandlerüberbrückungskupplung“ in Pkw-Automatgetrieben. VDI-Getriebetagung, Friedrichshafen (1995) Gussmann, V., Draxlmeyr, D., Reiter, J., Schneider, T., Rettig, R.: Intelligent Hall Effect based Magnetosensors in Modern Vehicle Stability Systems, Convergence Transportation Electronics Conference, Detroit, SAE (2000) Halliday, D., Resnick, R.: Fundamentals of Physics. Wiley, New York (1988) Hamm, M.: Adaptives Licht: Innovative Vernetzung von Systemen in der Lichttechnik. VDI-Berichte Nr. 1547. VDI-Verlag, Düsseldorf (2000) Haken, K.-L.: Grundlagen der Fahrzeugtechnik. Carl Hanser Verlag, München (2007) Hering, E., Martin, R., Stohrer, M.: Physik für Ingenieure. VDI-Verlag, Düsseldorf (1989) Heinecke, H., Schedl, A., Berwanger, J., Peller, M., Nieten, V., Beischner, R., Hedenetz, B., Lohrmann, P., Bracklo, C.: FlexRay – ein Kommunikationssystem für das Automobil der Zukunft. In: Elektronik Automotive (September 2002) Hella KGaA Hueck & Co: Hella Licht Research & Development Review 2000. – Firmenschrift Heinol, H. G.; Schwarte, R.: Photomischdetektor erfasst 3D-Bilder. In: Elektronik, Heft 12 (2000)

Literatur

79

[He5] Heim, A.: Intelligenter Batteriesensor: Schlüsselkomponente für das Energiemanagement der Zukunft, Tagung „Elektronik im Kraftfahrzeug“ Baden-Baden, VDI-Bericht Nr. 1789, VDI-Verlag, Düsseldorf (2003) [Hi1] Hubert, Hietl, Kötz, J., Linn, G.: Bereit für FlexRay – FlexRay-Serieneinführung bei Audi, Elektronic Automotive 1, S. 32–36 (2007) [Hi2] Herstellerinitiative Software. http://www.automotive-his.de/. (2008) [Ho1] Horowitz, P., Hill, W.: The Art of Electronics. Cambridge University Press, Cambridge (1990) [Ho2] Horn, B.: Robot Vision. MIT Press, Cambridge (MA) (1986) [Ho3] Homann, M.: OSEK. Betriebssystem-Standard für Automotive und Embedded Systems. mitp (2004) [Ho4] Hoffmeister, K.: AUTOSAR – Entwicklung leicht gemacht. In: Elektronik Automotive 12006 [Ho5] Hofmann-Wellenhof, Lichtenegger, Wasle: GNSS – Global Navigation Satellite Systems: GPS, GLONASS, „Galileo & more“. Springer, Berlin, Heidelberg (2007) [Ie1] IEEE Institute of Electrical and Electronics Engineers: IEEE Std 610.12–1990. IEEE Standard Glossary of Software Engineering Terminology, IEEE Press (1990) [Ie2] Norm IEC 60617: Internationale Standards über graphische Symbole für Schaltpläne (1996) [Ie3] Norm IEC 750: Kennzeichnung von elektrischen Betriebsmitteln (1983) [Ie4] Norm IEC EN 60529: Schutzarten durch Gehäuse (IP-Code) [Ie5] Norm IEC EN 61508: Functional safety of electrical/electronic/programmable electronic safety-related systems, Part 1–7 (2000) [Ie6] Norm IEC TR 62380: Technical Report, Reliability Data Handbook – Universal Model for Reliability Prediction of Electronic Components, PCBs and Equipment (2004) [In1] Infineon, H.: Publics MCD Corporate Publishing, 2. Auflage, München (2001) [Is1] Norm ISO 7498-1: Information technology – Open Systems Interconnection – Basic Reference Model: The Basic Model (1994) [Is2] Norm ISO 11898-1: Road vehicles – Controller Area network (CAN) – Part 1: Data link layer and physical signalling (1999) [Is3] Norm ISO 11898-2: Road vehicles – Controller Area network (CAN) – Part 2: High speed medium access unit (1999) [Is4] Norm ISO 11898-3: Road vehicles – Controller Area network (CAN) – Part 3: Low speed medium access unit (1999) [Is5] Norm ISO 11898-4: Road vehicles – Controller Area network (CAN) – Part 4: Time triggered communication (2000) [Is6] Norm ISO 11992: Road vehicles – Electrical connections between towing and towed vehicles; interchange of digital information. Part 1: Physical layer and data link layer (2003) [Is7] Norm ISO 9141: Straßenfahrzeuge; Diagnosesysteme; Anforderungen für den Austausch digitaler Informationen (1992) [Is8] Norm ISO 15622: Road vehicles – Adaptive Cruise Control Systems – Performance requirements and test procedures (2002) [Is9] Norm ISO 17356: Open interface for embedded automotive applications (2005) [Is10] Norm ISO/TR 15497: 2000 Road vehicles – Development guidelines for vehicle based software [Is11] Norm ISO 26262 Entwurf: Straßenfahrzeuge – Funktionale Sicherheit, FAKRA [Is12] Norm ISO/DIS 22901-1: Road Vehicles – Open diagnostic data exchange – Part 1 Data model specification [Is13] Norm ISO 22900: 2008 Road vehicles – Modular vehicle communication interface (MVCI)

80

Literatur

[Is14] Norm ISO 22900-2: Road vehicles – Modular vehicle communication interface (MVCI) – Part 2: Diagnostic protocol data unit application programming interface (D-PDU API) [Is15] Norm ISO 14229: 1998 Road vehicles – Diagnostic systems – Diagnostic services specification [Is16] Norm ISO 15031-1 bis 7: Road vehicles – Communication between vehicle and external equipment for emissions-related diagnostics [Is17] Norm ISO 15765-2: 2004 Road vehicles – Diagnostics on Controller Area Networks (CAN) [Is18] Norm ISO 14229-1: 2006 Road vehicles – Unified diagnostic services (UDS) – Part 1: Specification and requirements [Is19] Norm ISO 27145: Road vehicles – Implementation of WWH-OBD communication requirements – Part 1: General information and use case definition [Je1] Jersak, M., Richter, K., Sarnowski, H., Gliwa, P.: Laufzeitanalysen zur frühzeitigen Absicherung von Software, ATZ Elektronik 01/2009, Jahrgang 4 [Ju1] Jung, C., Woltereck, M.: Vorschlag eines Funktionssicherheitsprozesses für die verteilte Entwicklung sicherheitsrelevanter Systeme. Elektronik im Kraftfahrzeug/VDI-Gesellschaft Fahrzeug- und Verkehrstechnik. VDI-Verlag, Düsseldorf (2003) [Ki1] Kiesewetter, W., Klinkner, W., Reichelt, W., Steiner, M.: Der neue Brake Assist von Mercedes-Benz. In: ATZ Automobiltechnische Zeitschrift, Jahrgang 99, Ausgabe 6. (1997) [Ki2] Kindel, O.; Friedrich, M.: Softwareentwicklung mit AUTOSAR. Grundlagen, Engineering, Managment in der Praxis. 1. Aufl. dpunkt. verlag (2009) [Kn1] Kneuper, R.: Verbesserung von Softwareprozessen mit Capability Maturity Model Integration. dpunkt. verlag, Heidelberg (2003) [Kn2] Knuth, D. E.: The Art of Computer Programming Volume 3, 2. Aufl., Addison Wesley (1998) [Ko1] Konik, D.; Müller, R.; Prestl, W.; Tölge, T.; Leffler, H.: Elektronisches BremsenManagement als erster Schritt zu einem Integrierten Chassis Management. In: ATZ Automobiltechnische Zeitschrift, Jahrgang 101, Ausgabe 4 (1999) [Ko2] Kopetz, H.: Real-Time Systems. Springer, Berlin, Heidelberg (1997) [Kö1] Köhler, B.-U.: Konzepte der statistischen Signalverarbeitung. Springer, Heidelberg (2005) [Kr1] Kröger, R., Unbehauen, R.: Elektrodynamik. B.G. Teubner Verlag, Stuttgart (1997) [Kr2] Kruse, R.; Schäfer, H.; Wähner, L.: Integrierter Starter-Generator für das 42-V-Bordnetz. In: ATZ Automobiltechnische Zeitschrift, Jahrgang 104, Ausgabe 7–8 (2002) [Ku1] Kuchling, H.: Taschenbuch der Physik. 19. aktualisierte Auflage, München: Fachbuchverlag Leipzig im Carl-Hanser-Verlag (2007) [La1] Langwieder, K., Bäumler, H.: Charakteristik von Nachtunfällen. In: Progress in Lighting. TH Darmstadt 1997, PAL 1997. – Proceedings [La2] Lang, H.-P.; Knödler, K.; Kocher, P.; Rölleke, M.; Oswald, K.: Erweiterte Crashsensierung mit zusätzlicher Beschleunigungssensorik, Radarsensoren und Winkelgeschwindigkeitssensoren. VDI-Berichte Nr. 1471. VDI-Verlag, Düsseldorf (1999) [Li1] LIN Local Interconnected Network: LIN Specification Package Version 2.1. www.lin-sub bus.org. (2006) [Li2] Liu, J.: Real-Time Systems. Prentice Hall (2000) [Li3] Liggesmeyer, P., Rombach, D. (Hrsg.): Software-Engineering eingebetteter Systeme. Spektrum Akademischer Verlag (2005) [Lo1] Lovric, T.: Sicherheitsanforderungen an Fahrerassistenzsysteme, TÜV Nord, Sachverständigentag (2006) [Ma1] Köhler, B.-U.: Konzepte der statistischen Signalverarbeitung. Springer, Heidelberg (2005) [Ma2] Mattes, W.; Mayr, K.; Neuhauser, W.; Steinparzer, F.: BMW 6-Zylinder-Dieselmotor mit Euro-4-Technik. In: MTZ Motortechnische Zeitschrift, Jahrgang 65, Ausgabe 7–8 (2004)

Literatur

81

[Ma3] Marscholik, C., Subke, P.: Datenkommunikation im Automobil Grundlagen, Bussysteme, Protokolle und Anwendungen. Hüthig Verlag (2007) [Ma4] Mandl, P.: Grundkurs Betriebssysteme. Architekturen, Betriebsmittelverwaltung, Synchronisation, Prozesskommunikation. 2. Aufl. Vieweg+Teubner Verlag, Wiesbaden (2010) [Ma5] Maurer, M., Stiller, C. (Hrsg.): Fahrerassistenzsysteme mit maschineller Wahrnehmung. Springer Verlag, Berlin, Heidelberg (2005) [Mi1] MISRA The Motor Industry Software Reliability Association: Guidelines for the Use of the Language in Vehicle based Software. http://www.misra.org.uk (1998) [Mi2] Mitschke, M., Wallentowitz, H.: Dynamik der Kraftfahrzeuge, 4. Aufl. Springer, Berlin, Heidelberg (2004) [Mi3] Miedreich, M., Schober, H.: Fußgängerschutzsystem mit faseroptischem Sensor. In: ATZ Automobiltechnische Zeitschrift, Jahrgang 107, Ausgabe 3 (2005) [Mi4] MIL-HDBK-217, Reliability Prediction of Electronic Equipment, Revision F-2 (1991) [Mo1] MOST Specification Rev. 2.4. www.mostcooperation.com (2005) [Mo2] MOST Dynamic Specification Rev. 1.1. www.mostcooperation.com (2005) [Mo3] Morgan, G.: AUTOSAR – ein Projekt zur Entwicklung von Steuergeräte-Software. In: Elektronik Automotive 1-2006 [Mü1] Münzenberger, R.; Kramer, T.: Absichern des Echtzeit-Verhaltens durch virtuelle Integration, INCHRON GmbH, 4. Tagung – Simulation und Test für die Automobilelektronik, IAV, Berlin (2010) [My1] Myers, G.: Methodisches Testen von Programmen, 7. Aufl. Oldenbourg Verlag (2001) [Na1] Naumann, R: Spannungs-, strom- und impendanzbasierte Methoden der Batteriediagnose – Möglichkeiten und Grenzen. Haus der Technik Fachbuch „Energiemanagement und Bordnetze“. Expert Verlag, Renningen (2004) [Ni1] Nishi, Y., Doering, R. (Hrsg.): Handbook of Semiconductor Manufactoring Technology. Marcel Decker Inc., New York (2000) [Od1] Open DeviceNet Vender Association (ODVA): DeviceNet Specifications, Volumes I and II, Rev. 2.0. www.odva.org (1998) [Od2] Odenthal, D.: Ein robustes Fahrdynamik-Regelungskonzept für die Kippvermeidung von Kraftfahrzeugen. Techn. Univ., Diss, München (2001) [Oe1] Oestereich, B.: Objektorientierte Softwareentwicklung. Analyse und Design mit der UML 2.0. 6. Aufl. Oldenbourg Verlag (2004) [Ol1] Olk, J., Rosenmayr, M.: Systematische Entwicklung des Energiemanagements. Tagung „Elektronik im Kraftfahrzeug“, Baden-Baden. VDI-Bericht Nr. 1789. VDI-Verlag, Düsseldorf (2003) [Ol2] Olk, J., Schöllmann, M., Rosenmayr, M.: Trends bei der Batterieüberwachung mit Sensoren. Tagung des DGES: Hybrid- und Brennstoffzellen-Fahrzeuge: Energiemanagement – Aufgaben und Strukturen. Ingolstadt (Juni 2005) [Ol3] Olk, J., Körner, A.: Komponenten für strukturierte Bordnetze, Haus der Technik Fachbuch „Energiemanagement und Bordnetze“. Expert-Verlag, Renningen (2004) [Os1] OSEK/VDX Operating System Specification 2.2.3. www.osek-vdx.org (2005) [Os2] OSEK Open systems and the corresponding interfaces for automotive electronics: Binding Specification 1.4.2. www.osek-vdx.org (2004) [Pa1] Paul, R.: MOS-Feldeffekttransistoren. Springer, Berlin, Heidelberg (2002) [Pr1] ProdHaftG Gesetz über die Haftung für fehlerhafte Produkte [Pr2] Schröder-Preikschat, W.: „Echtzeitbetriebssysteme“, in Software Engineering eingebetteter Systeme, Hrsg. Peter Liggesmeyer und Dieter Rombach, Elsevier: Spektrum-Verlag (2005) [Pr3] Press, W. H., Teukolsky, S. A., Vetterling, W. T., Flannery, B. P.: Numerical Recipes: The Art of Scientific Computing, 3rd ed. (gebundene Ausgabe), Cambridge University Press (2007)

82

Literatur

[Ra1] Rausch, M.: Optimierte Mechanismen und Algorithmen in FlexRay. In: Elektronik Automotive (2002) [Ra2] Radio Technical Commission for Aeronautics: DO-178B, Software Considerations in Airborne Systems and Equipment Certification (1992) [Ra3] Rasmussen, J.: Skills, Rules and Knowledge; Signals, Signs and Symbols and other Distinctions in human performance Models. IEEE Transactions on Systems, Man and Cybernetics, SMC 13(3) (1983) [Re1] Reif, K.; Unbehauen, R.: The extended Kalman filter as an exponential observer for nonlinear systems, IEEE Trans. Signal Processing SP-47, 2324–2328 (1999) [Re2] Reif, K., Yaz, E., Günther, S., Unbehauen, R.: Stochastic stability of the discrete-time extended Kalman filter, IEEE Trans. Autom. Contr. AC-44, 714–728 (1999) [Re3] Rettig, R., Katzmeier, E.: Sensors for Transmission Applications: Requirements, Status and Future Trends. Third international CTI Symposium on Innovative Automotive Transmissions. Würzburg (2004) [Re4] Reif, K., Milbredt, P.: Weckvorgang und Hochlauf von FlexRay-Vernetzungen, 8. Internationales Stuttgarter Symposium für Automobil- und Motorentechnik, Bd. 2, S. 441–451 (2008) [Re5] Reif, K., Renner, K., Saeger, M.: Fahrzustandschätzung auf Basis eines nichtlinearen Zweispurmodells. ATZ Automobiltechnische Zeitschrift, Jahrgang 109, 682–687 (August 2007) [Re6] Reich, A., Spängler, O.: Diagnose als wesentlicher Faktor zum Beherrschen der Elektronik. In: Elektronik Automotive, Sonderausgabe Audi A4 (2007) [Re7] Reif, K. (Hrsg.): Dieselmotor-Management im Überblick (einschließlich Abgastechnik). Vieweg+Teubner Verlag, Wiesbaden (2010) [Re8] Reif, K. (Hrsg.): Fahrstabilisierungssysteme und Fahrerassistenzsysteme. Vieweg+Teubner Verlag, Wiesbaden (2010) [Re9] Reichelt, S., Schmidt, K., Gesele, F., Seidler, N., Hardt, W.: Nutzung von FlexRay als zeitgesteuertes automobiles Bussystem im AUTOSAR-Umfeld. In: Workshop über Mobilität und Echtzeit. Boppard am Rhein (2007) [Re10] Rennert, P., Schmiedel, H., Weißmantel, C.: Kleine Enzyklopädie Physik: Thun. Verlag Harri Deutsch, Frankfurt a. M. (1987) [Ri1] Rieth, P., Drumm, S., Harnischfeger, M.: Elektronisches Stabilitätsprogramm – die Bremse, die lenkt. Verlag Moderne Industrie (2001) [Ri2] Richter, K., Feiertag, K., Rudorfer, M., Scheickl, O.; Ainhauser, C.: How Timing Interfaces in AUTOSAR can Improve Distributed Development of Real-Time Software. GI Jahrestagung, S. 662–667 (2008) [Ro1] Robertson, S., Robertson, J.: Mastering the Requirements Process. ACM Press (1999) [Ro2] Rosenmayr, M., Schöllmann, M., Gronwald, F.: Batteriediagnose mit dem Intelligenten Batteriesensor IBS Haus der Technik Fachbuch „Energiemanagement und Bordnetze“. ExpertVerlag, Renningen (2004) [Ru1] Rupp, C.: Requirements-Engineering und -Management. Professionelle, iterative Anforderungsanalyse für die Praxis. 3. Aufl. Carl Hanser Verlag, München (2004) [Ru2] Runkler, T.A.: Data Mining. Vieweg+Teubner Verlag, Wiesbaden (2009) [Sa1] SAE J2411: Single Wire CAN Network for Vehicle Applications (2000) [Sa2] Sauerwein, E.: Das Kano-Modell der Kundenzufriedenheit. Deutscher Universitätsverlag, Wiesbaden (2000) [Sa3] SAE J2534/1: Recommended Practice for Pass-Thru Vehicle Programming [Sc1] Schäuffele, J.; Zurawka, T.: Automotive Software Engineering, 4. Aufl. Vieweg+Teubner Verlag, Wiesbaden (2010)

Literatur

83

[Sc2] Schoeppe, D., Bercher, N., Guerrassi, D., Spadafora, P.: Common-Rail-Technologie für zukünftige Diesel Fahrzeuge mit niedrigen Emissionswerten. 13. Aachener Kolloquium Fahrzeug und Motorentechnik (2004) [Sc3] Schatz, O.: Sensoren für die Sicherheit, IIR AutomobilTechnologieKongress AutoTec (2003) [Sc4] Schoof, J.: OSEK/VDX-OS Betriebssystemstandard für Steuergeräte in Kraftfahrzeugen, P. Holleczek (Hrsg.), PEARL 2000 – Echtzeitsysteme und Linux, Informatik aktuell. Springer Verlag, Berlin, Heidelberg, S. 43–52 (2000) [Sc5] Schneider, B.: Der Photomischdetektor zur schnellen 3D-Vermessung für Sicherheitssysteme und zur Informationsverarbeitung im Automobil, Dissertation, Universität-Gesamthochschule Siegen (2003) [Sc6] Schneider, R., Kalhammer, M., Eberhard, D.; Brewerton, S.: Basic Single-Microcontroller Monitoring Concept for Safety Critical Systems. SAE 2007 World Congress, 2007-01-1488 [Sc7] Schmidt, K., Gesele, F.: AUTOSAR-konforme Entwicklung von Fahrwerksfunktionen mit TargetLink. In: dSPACE Anwenderkonferenz 2007. München (2007) [Sc8] Schwarz, H.-R., Köckler, N.: Numerische Mathematik. Vieweg Verlag, Wiesbaden (2004) [Sp1] SPICE: http://www.squi.qu.edu.au/spice [St1] StVZO, § 30 Straßenverkehrszulassungsordnung Deutschland [Su1] Sundaram, P., D’Ambrosio, J. G.: Controller Integrity in Automotive Failsafe System Architectures. SAE 2006 World Congress, 2006-01-0840 [Te1] Teepe, G.: Durchgängige Elektronikarchitekturen auf der Basis von einheitlichen Standards entwirren das Kfz-Netzwerk. In: Elektronik Automotive (Juni 2003) [Te2] Telcordia: SR-322 Reliability Prediction Procedure for Electronic Equipment (2001) [Te3] Technology and Maintenance Council: RP1210A-TMC standard. A software driver that interfaces a PC or PDA to a specific communication device like a Vehicle Link Adapter [Ti1] Tietze, U., Schenk, C.: Halbleiter-Schaltungstechnik. Springer, Berlin, Heidelberg (2002) [Un1] Unbehauen, R.: Systemtheorie, Bd. 1, Allgemeine Grundlagen, Signale und lineare Systeme im Zeitbereich und Frequenzbereich. Oldenbourg (2002) [Un2] Unbehauen, R.: Grundlagen der Elektrotechnik 1. Verlag, Berlin, Heidelberg (1999) [Vd1] Verband der Automobilindustrie: Qualitätsmanagement in der Automobilindustrie – System FMEA, Failure Mode and Effects Analysis. Bd. 4.2. (1996) [Vd2] Verband der Automobilindustrie: Qualitätsmanagement in der Automobilindustrie – QMSystemaudit. Bd. 6.1. (1998) [Vd3] Verband der Automobilindustrie: Qualitätsmanagement in der Automobilindustrie – Zuverlässigkeits-Methoden und -Hilfsmittel. Bd. 3.2. (2000) [Vd4] Norm VDI 4003: Zuverlässigkeitsmanagement (2005-07) [Ve1] Vesely, W., u. a.: Fault Tree Handbook. NUREG-0492, U.S. Nuclear Regulatory Commission, Washington DC (1981) [Vi1] Vieler, C. et al.: Strukturkonzepte zur Realisierung zukünftiger Sicherheitsanforderungen. VDI-Berichte Nr. 1794. VDI-Verlag, Düsseldorf (2003) [Vm1] Bundesministerium des Inneren: AU 250/1 Entwicklungsstandard für IT-Systeme des Bundes: Vorgehensmodell (1997) [Vm2] V-Modell: http://www.v-modell-xt.de (2005) [Vo1] Vollrath, M.; Schießl, C.: Belastung und Beanspruchung im Fahrzeug – Anforderungen an Fahrerassistenz. Integrierte Sicherheit und Fahrerassistenzsysteme. VDI-Berichte Nr. 1864, 1. VDI Verlag, Düsseldorf (2004) [Vo2] Volkswagen AG: Selbststudienprogamm 316, Der 2,0 l TDI Motor. – Firmenschrift [Vo3] Volkswagen AG: Selbststudienprogramm 298, Der Touareg, Elektrische Anlage. – Firmenschrift

84

Literatur

[Vo4] Volkswagen AG: Selbststudienprogramm 350, Der 3,0 l V6 TDI-Motor. – Firmenschrift [Vo5] Volkswagen AG: Selbststudienprogramm 330, Das Dieselpartikelfiltersystem mit Additiv. – Firmenschrift [Vö1] Völklein, F., Zetterer, T.: Einführung in die Mikrosystemtechnik. Vieweg Verlag, Braunschweig (2000) [Wa1] Wallentowitz, H., Reif, K. (Hrsg.): Handbuch Kraftfahrzeugelektronik – Grundlagen – Komponenten – Systeme – Anwendungen. 2., verbesserte und aktualisierte Auflage. Vieweg+Teubner Verlag, Wiesbaden (2010) [Wa2] Wagner, G.; Flerlage, F.: Reifegradbestimmung durch gezieltes Fehlermanagement. In: Elektronik Automotive, Sonderausgabe Audi A4 (2007) [We1] Weghaus, L.: DCDC-Wandler im Kraftfahrzeug. Haus der Technik Tagung Energiemanagement und Bordnetze, Essen (2007) [Wi1] Winner, H., Hakuli, S., Wolf, G. (Hrsg.): Handbuch Fahrerassistenzsysteme. Vieweg+Teubner Verlag, Wiesbaden (2012) [Wö1] Wörn, H., Brinkschulte, U.: Echtzeitsysteme. Springer, Berlin, Heidelberg (2005) [Wo2] Wolf: Fahrzeuginformatik. Springer, Berlin, Heidelberg (2018) [Zh1] Zhao, Y.: Vehicle Location and Navigation Systems. Artech House Publishers (1997) [Zi1] Zimmermann,W; Schmidgall, R.: Bussysteme in der Fahrzeugtechnik: Protokolle und Standards. 5.Aufl. Springer, Wiesbaden (2014). Kapitel 4 + 5 [Zi2] Zimmermann,W; Schmidgall, R.: Bussysteme in der Fahrzeugtechnik: Protokolle und Standards. 5. Aufl. Springer, Wiesbaden (2014). Kapitel 6