Automotive Software Engineering: Grundlagen, Prozesse, Methoden und Werkzeuge effizient einsetzen, 4. Auflage (ATZ MTZ-Fachbuch) 3834803642, 9783834803641 [PDF]

Zitiervorschau

lörg Schäuffele I Thomas Zurawka Automotive Software Engineering

Iörg Schäuffel e I Thomas Zurawka

Automotive Software Engineering Grundlagen, Prozesse, Meth oden und Werkzeuge effizient einsetzen 4., überarb eitete und erweiterte Auflage Mit 276 Abbildungen PRAXIS

11 VIEWEG+ TEUBNER

I ATZ /MTZ-Fachbu ch

Bibliografische Information der Deutschen Nationalbibliot hek Die Deutsche Nat ionalbibliot hek verzeichne t diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Interne t über abrufbar.

1. Auflage 2003 2. Auf lage 2004 3. Auf lage 200 6 4., überar beitete und erweiterte Auflage 2010 Alle Rechte vorbehalten

© Vieweg+Teubner I GWV Fachverlage GmbH, Wiesbaden 2010 Lektorat : Themas Zipsner

I Ellen Kra bunde

Vieweg+Teubner ist Teil der Fachverlagsgrup pe Springer Serence-Business Media. www.viewegteubner.de Das Werk einschließlich aller seiner Teile ist urhe berrechtlich gesc hüt zt. Jede Verw ert ung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für Vervielfälti gungen, Übersetzungen, Mikroverf ilmungen und die Einspeicherung und Verarbeitun g in elekt ronisc hen Systemen . Die Wiedergabe von Gebrauchsnamen, Handelsnamen. Warenbezeichnungen usw. in diesem Werk berecht igt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenscnutz-Gesetagebung als f rei zu betrachten wären und daher von je dermann benutzt werden dürften. Umschlaggestaltun g: KünkelLopka Medienentw icklung, Heidelberg Technische Redaktion: Stefan Kreickenbaum, Wiesbaden Druck und buchbindensehe Verarbeitung : MercedesDruc k, Berlin Gedruckt auf säurefreiem und chlorf rei gebleichtem Papier. Printed in Germany ISBN 978-3-83 48-03 64- 1

v

Zur Bedeutung von Software im Automobil Neue Entwicklungsmethoden zur Beherrschung der Komplexität erforderlich Auch in Zukunft ist Software die Technik, um komplexe Algorithmen im Kraftfahrzeug umzusetzen. Der nahezu exponentiell wachsende Software-Umfang wird getrieben durch die Funktionszunahme in den Feldern sicher , sauber , sparsam und seit einiger Zeit auch im Bereich der Fahrerassistenz. Die Beherrschung der daraus resultierenden Komplexität ist für Fahrzeughersteller wie Zulieferer eine Herausforderung, die nur mit leistungsfähigen Methoden und Werkzeugen möglich ist. Mit ihrer Hilfe gilt es, die sichere Funktion der Software und der Systeme zu gewährleisten. Das vorliegende Buch liefert dazu vielfältige Anregungen zur Gestaltung von Entwicklungsprozessen und zum Einsatz von Methoden und Werkzeugen . Dr. Sieg/r ied Dais, Stellvertretender Vorsitzender der Geschäftsfu hrung der Robert Bosch Gmbll, Stuttgart Standardisierung von Software und Entwicklungsmethoden Es zeichnet sich immer mehr ab, dass der neue Standard AUTOSAR von Fahrzeugherstellern und deren Zulieferern schrittweise in Serienprojekten eingeführt wird . Insbesondere ist eine breite Akzeptanz für eine standardisierte Basis-Software absehbar. Eine Angleichung der Entwicklungsmethodik von der Anforderungsanalyse bis zum Systemtest ist ein wichtiger Schritt , um weitere Synergien zu heben. Das vorliegende Buch adressiert diese neuen Themen in der 4. Auflage. Dr. Klaus Grimm , Leiter Software Technol ogy, Daimler AG, Stuttgart Vom Kostentreiber zum Wettbewerbsvorteil Technischer Vorsprung in der Automobil industrie kann nur durch eine Vorreiterrolle in der Software-Technik erreicht werden . Die erfolgreiche Zusammenarbeit von Ingenieuren unterschiedlicher Fachrichtungen in der Systementwicklung erfordert jedoch ein einheitliches Hintergrundwissen, eine gemeinsame Begriffswelt und ein geeignetes Vorgehensmodell. Die in diesem Buch dargestellten Grundlagen und Methoden demonstrieren dies anhand von Beispielen aus der Praxis sehr eindrucksvoll. Dr.-Ing. Wolfgang Runge, Geschaftsführe r, ZF Lenksysteme GmbH, Schwäbisch Gmiind Ausbildung als Chance und Herausforderung Gerade für den Raum Stuttgart spielt der Fahrzeugbau eine herausragende Rolle. Die Entwicklungszentren bedeutender Fahrzeughersteller und Zulieferer bieten hier viele Arbeitsplätze. Die Ausbildung in der Software-Technik ist ein fester Bestandteil eines Ingenieurstudienganges an der Universität Stuttgart . Dieses Buch bietet die Chance , praktische Erfahrungen in der Automobilindustrie bereits in der Ausbildung zu berücksichtigen. Viele der vorgestellten Vorgehensweisen können sogar Vorbildcharakter für andere Branchen haben . Prof Dr.-Ing. Dr. h.c. Peter Göhner, Institut ß ir Automatisierungs- und Sof tware-Technik, Universität Stuttgart

VI

Vorwort zur 4. Auflage

Vorwort zur 4. Auflage Wir freuen uns sehr , dass unser Buch inzwischen eine breite Leserschaft gefunden hat und wegen hoher Nachfrage bereits in der 4. Auflage erscheinen kann . Inzwischen liegt auch eine englische, japanische und chinesische Übersetzung vor. Uns freut zudem , dass in jüngster Zeit weltweit an zahlreichen Hochschulen Vorlesungen und Studiengänge zu Automotive Software Engineering eingeführt wurden, die dieses Buch als Grundlage für die Lehrveranstaltungen verwenden. Im Mittelpunkt der Überarbeitung für die 4. Auflage steht der AUTOSAR-Standard . Obwohl der Standard selbst teilweise noch im Fluss ist und die Einführung der AUTOSAR-Methodik in der Breite in der Automobilindustrie in vielen Fällen noch bevor steht , ist eine hohe Akzeptanz dieses Standards im Bereich der Basis-Software für Steuergeräte aus unserer Sicht absehbar. Wir haben deshalb alle Kapitel zur Software-Architektur entsprechend aktualisiert und eine Einführung in die AUTOSAR-Grundlagen aufgenommen. Auch heute , nach seiner über lOO-jährigen Geschichte, ist das Kraftfahrzeug durch eine rasante Weiterentwicklung gekennzeichnet. Seit Anfang der I970er Jahre ist die Entwicklung geprägt von einem - bis heute anhaltenden - stetigen Anstieg des Einsatzes von elektronischen Systemen und von Software im Fahrzeug. Dies führt zu gravierenden Veränderungen in der Entwicklung, in der Produktion und im Service von Fahrzeugen. So ermöglicht die zunehmende Realisierung von Fahrzeugfunktionen durch Software neue Freiheitsgrade beim Entwurf und die Auflösung bestehender Zielkonflikte. Zur Beherrschung der dadurch entstehenden Komplexität sind Prozesse, Methoden und Werkzeuge notwendig, die die fahrzeugspezifischen Randbedingungen berücksichtigen. Grundlegende charakteristische Anforderungen an Software im Automobil sind der Entwurf für eingebettete und verteilte Echtzeitsysteme bei hohen Sicherheits- und Verfügbarkeltsanforderungen sowie großer Kostendruck. Diese Anforderungen stehen bei diesem Buch im Vordergrund. Zur Entwicklung von Software für elektronische Systeme von Fahrzeugen wurde in den letzten Jahren eine Reihe von Vorgehensweisen und Standards entwickelt, die wohl am besten unter dem Begriff "Automotive Software Engineering" zusammengefasst werden können . Damit ist eine komplexe Begriffswelt entstanden, mit der wir ständig konfrontiert werden . Es wird immer schwieriger, genau zu verstehen, was sich hinter den Vokabeln verbirgt. Erschwerend kommt hinzu, dass manche Begriffe mehrfach in unterschiedlichem Zusammenhang verwendet werden . So etwa der Begriff Prozess, der im Zusammenhang mit der Regelungstechnik, aber auch mit Echtzeitsystemen oder generell mit Vorgehensweisen in der Entwicklung benutzt wird . Nach einem Überblick zu Beginn werden deshalb in diesem Buch die wichtigsten Begriffe definiert und durchgängig so verwendet. In den folgenden Kapiteln stehen Prozesse, Methoden und Werkzeuge für die Entwicklung von Software für die elektronischen Systeme des Fahrzeugs im Mittelpunkt. Eine entscheidende Rolle spielen dabei die Wechselwirkungen zwischen der Software-Entwicklung als Fachdisziplin und der übergreifenden Systementwicklung, die alle Fahrzeugkomponenten berücksichtigen muss . Die dargestellten Prozesse haben Modellcharakter. Das bedeutet, die Prozesse sind ein abstraktes, idealisiertes Bild der täglichen Praxis. Sie können für verschiedene Entwicklungsprojekte als Orientierung dienen , müssen aber vor der Einführung in einem konkreten Projekt bewertet und eventuell angepasst werden . Auf eine klare und verst ändliche Darstellung haben wir deshalb großen Wert gelegt.

Vorwort

VII

Wegen der Breite des Aufgabengebietes können nicht alle Themen in der Tiefe behandelt werden . Wir beschränken uns aus diesem Grund auf Gebiete mit automobilspezifischem Charakter.

Beispiele aus der Praxis Ein Prozess ist nur dann ein erfolgreiches Instrument für ein Entwicklungsteam, wenn die Vorteile der nachvollziehbaren Bearbeitung umfangreicher Aufgabenstellungen in der Praxis anerkannt werden. Dieses Buch soll daher kein theoretisches Lehrbuch sein , das sich jenseits der Praxis bewegt. Alle Anregungen basieren auf praktischen Anwendungsfällen . die wir anhand von Beispielen anschaulich darstellen. Die Vielzahl von Erfahrungen, die wir in enger Zusammenarbeit mit Fahrzeugherstellern und Zulieferern in den letzten Jahren sammeln konnten , wurde dabei berücksichtigt. Dazu gehören Serienentwicklungen mit den dazugehörenden Produktions- und Serviceaspekten genauso wie Forschungs- und Vorentwicklungsprojekte.

Leserkreis Wir sprechen mit dem vorliegenden Buch alle Mitarbeiter bei Fahrzeugherstellern und Zulieferern an , die in der Entwicklung, in der Produktion und im Service mit Software im Fahrzeug konfrontiert sind . Wir hoffen nützliche Anregungen weitergeben zu können. Dieses Buch soll andererseits auch eine Basis zur Ausbildung von Studierenden und zur Einarbeitung von neuen Mitarbeitern zur Verfügung stellen. Grundkenntnisse in der Steuerungsund Regelungstechnik, in der Systemtheorie und in der Software-Technik sind von Vorteil , aber nicht Voraussetzung. Sicherlich wird an einigen Stellen der Wunsch nach einer detaillierteren Darstellung aufkommen . Wir freuen uns deshalb zu allen behandelten Themen über Hinweise und Verbesserungsvorschläge. Zahlreiche Rückmeldungen der Leser zur 3. Auflage wurden bei der 4. Auflage des Buches berücksichtigt.

Danksagungen An dieser Stelle möchten wir uns besonders bei allen unseren Kunden für die jahrelange, vertrauensvolle Zusammenarbeit bedanken . Ohne diesen Erfahrungsaustausch wäre dieses Buch nicht möglich gewesen. Des Weiteren bedanken wir uns bei der BMW Group für die freundliche Zustimmung, dass wir in diesem Buch Erfahrungen darstellen dürfen, die wir in BMW Projekten - im Falle des erstgenannten Autors auch als BMW Mitarbeiter - gesammelt haben. Dies schließt auch Empfehlungen für Serienprojekte bei BMW ein . Wir bedanken uns besonders bei Herrn Heinz Merkle, Herrn Dr. Helmut Hochschwarzer, Herrn Dr. Maximilian Fuchs, Herrn Prof. Dr. Dieter Nazareth, sowie allen ihren Mitarbeitern . Viele Vorgehensweisen und Methoden entstanden während der jahrelangen, engen und vertrauensvollen Zusammenarbeit mit der Robert Bosch GmbH . Die dabei entwickelten und inzwischen breit eingesetzten Vorgehensweisen finden sich in diesem Buch an vielen Stellen wieder. Wir sagen dafür den Mitarbeiterinnen und Mitarbeitern der Bereiche Chassis Systems, Diesel Systems, Gasoline Systems, sowie der Forschung und Vorausentwicklung der Robert Bosch GmbH vielen Dank . Wir bedanken uns außerdem herzlich bei Herrn Dr. Siegfried Dais , Herrn Dr. Wolfgang Runge und Herrn Prof. Dr. Peter Göhner für ihre einleitenden Geleitworte.

VIII

Vorwort zur 4. Auflage

Abschließend bedanken wir uns bei allen unseren Kolleginnen und Kollegen , die in den letzten Jahren auf vielfältige Weise zu diesem Buch beigetragen haben . Für die sorgfältige und kritische Durchsicht des Manuskripts bedanken wir uns insbesondere bei Roland Jeutter, Dr. Michael Nicolaou, Dr. Oliver Schlüter, Dr. Kai Werther und Hans-J örg Wolff. Unser Dank gilt nicht zuletzt dem Vieweg+Teubner-Verlag und Herrn Thomas Zipsner für die wied erum sehr gute Zusammenarbeit bei der Vorbereitung der 4. Auflage. Stuttgart, Dezember 2009

Jörg Schäuffele, Dr. Thomas Zurawka

IX

Inhaltsverzeichnis

Einführung und Überblick 1.1

1.2

1.3

1.4

1.5

Das System Fahrer-Fahrzeug-Umwelt 1.1.1 Aufbau und Wirkungsweise elektronischer Systeme 1.1.2 Elektronische Systeme des Fahrzeugs und der Umwelt Überblick über die elektronischen Systeme des Fahrzeugs 1.2.1 Elektronische Systeme des Antriebsstrangs 1.2.2 Elektronische Systeme des Fahrwerks 1.2.3 Elektronische Systeme der Karosserie 1.2.4 Multi-Media-Systeme 1.2.5 Verteilte und vernetzte elektronische Systeme 1.2.6 Zusammenfassung und Ausblick Überblick über die logische Systemarchitektur 1.3.1 Funktions- und Steuergerätenetzwerk des Fahrzeugs 1.3.2 Logische Systemarchitektur für Steuerungs-/Regelungs- und Überwachungssysteme Prozesse in der Fahrzeugentwicklung 1.4.1 Überblick über die Fahrzeugentwicklung 1.4.2 Überblick über die Entwicklung von elektronischen Systemen 1.4.3 Kernprozess zur Entwicklung von elektronischen Systemen und Software 1.4.4 Unterstützungsprozesse zur Entwicklung von elektronischen Systemen und Software 1.4.5 Produktion und Service von elektronischen Systemen und Software Methoden und Werkzeuge flir die Entwicklung von Software für elektronische Systeme 1.5.1 ModeIlbasierte Entwicklung 1.5.2 Integrierte Qualitätssicherung 1.5.3 Reduzierung des Entwicklungsrisikos 1.5.4 Standardisierung und Automatisierung 1.5.5 Entwicklungsschritte im Fahrzeug

2 Grundlagen 2.1

2.2

2.3

Steuerungs- und regelungstechnische Systeme 2.1.1 ModeIlbildung 2.1.2 Blockschaltbilder Diskrete Systeme 2.2.1 Zeitdiskrete Systeme und Signale 2.2.2 Wertdiskrete Systeme und Signale 2.2.3 Zeit- und wertd iskrete Systeme und Signale 2.2.4 Zustandsautomaten Eingebettete Systeme 2.3.1 Aufbau von MikrocontroIlern

I 2 2 5 6 8 9 11 13 14 15 16 16 17 18 18 19 22 24 27 27 28 28 31 32 35 37 37 37 38 42 43 44 45 45 47 48

x

Inhaltsverzeichnis

2.4

2.5

2.6

2.7

3

2.3.2 Speichertechnologien 2.3.3 Programmierung von Mikrocontrollern Echtzeitsysteme 2.4.1 Festlegung von Tasks 2.4.2 FestIegung von Echtzeitanforderungen 2.4.3 Zustände von Tasks 2.4.4 Strategien für die Zuteilung des Prozessors 2.4.5 Aufbau von Echtzeitbetriebssystemen 2.4 .6 Interaktion zwischen Tasks Verteilte und vernetzte Systeme 2.5.1 Logische und technische Systemarchitektur 2.5.2 FestIegung der logischen Kommunikationsbeziehungen 2.5.3 Festlegung der technischen Netzwerktopologie 2.5.4 FestIegung von Nachrichten 2.5.5 Aufbau der Kommunikation und des Netzwerkmanagements 2.5.6 Strategien für die Zuteilung des Busses Zuverlässigkeit, Sicherheit, Überwachung und Diagnose von Systemen 2.6.1 Grundbegriffe 2.6.2 Zuverlässigkeit und Verfügbarkeit von Systemen 2.6.3 Sicherheit von Systemen 2.6.4 Überwachung und Diagnose von Systemen 2.6.5 Aufbau des Überwachungssystems elektronischer Steuergeräte 2.6.6 Aufbau des Diagnosesystems elektronischer Steuergeräte Steuergerätenetzwerke

Unterstützungsprozesse zur Entwicklung von elektronischen Systemen und Software 3.1 3.2 3.3

3.4

3.5

3.6

3.7

Grundbegriffe der Systemtheorie Vorgehensmodelle und Standards Konfigurationsmanagement 3.3.1 Produkt und Lebenszyklus 3.3.2 Varianten und Skalierbarkeit 3.3.3 Versionen und Konfigurationen Projektmanagement 3.4.1 Projektplanung 3.4.2 Projektverfolgung und Risikomanagement Lieferantenmanagement 3.5.1 System- und Komponentenverantwortung 3.5.2 Schnittstellen für die Spezifikation und Integration 3.5.3 Festlegung des firmen übergreifenden Entwicklungsprozesses Anforderungsmanagement 3.6.1 Erfassen der Benutzeranforderungen 3.6.2 Verfolgen von Anforderungen Qualitätssicherung 3.7.1 Integrations- und Testschritte 3.7.2 Maßnahmen zur Qualitätssicherung von Software

50 53 60 60 62 64 66 71 71 77 80 81 83 84 85 89 91 92 93 97 100 104 107 112

115 115 118 120 120 121 122 125 125 130 131 13I 132 132 134 134 138 138 139 140

Inhaltsverzeichnis

4

XI

Kernprozess zur Entwicklung von elektronischen Systemen und Software

141

4.1

142 142 143 145 145 145 146

4.2

4.3 4.4

4.5

4.6

4.7

4.8 4.9

4.10 4.11

4.12 4.13 4.14

Anforderungen und Randbedingungen 4.1.1 System- und Komponentenverantwortung 4.1.2 Abstimmung zwischen System- und Software-Entwicklung 4.1.3 Modellbasierte Software-Entwicklung Grundbegriffe 4.2.1 Prozesse 4.2.2 Methoden und Werkzeuge Analyse der Benutzeranforderungen und Spezifikation der logischen Systemarchitektur Analyse der logischen Systemarchitektur und Spezifikation der technischen Systemarchitektur 4.4 .1 Analyse und Spezifikation steuerungs- und regelungstechnischer Systeme 4.4 .2 Analyse und Spezifikation von Echtzeitsystemen 4.4 .3 Analyse und Spezifikation verteilter und vemetzter Systeme 4.4.4 Analyse und Spezifikation zuverlässiger und sicherer Systeme Analyse der Software-Anforderungen und Spezifikation der Software-Architektur 4.5.1 Spezifikation der Software-Komponenten und ihrer Schnittstellen 4.5.2 Spezifikation der Software-Schichten 4.5.3 Spezifikation der Betriebszustände Spezifikation der Software-Komponenten 4.6.1 Spezifikation des Datenmodells 4.6.2 Spezifikation des Verhaltensmodells 4.6.3 Spezifikation des Echtzeitmodells Design und Implementierung der Software-Komponenten 4.7.1 Berücksichtigung der geforderten nichtfunktionalen Produkteigenschaften 4.7.2 Design und Implementierung des Datenmodells 4.7.3 Design und Implementierung des Verhaltensmodells 4.7.4 Design und Implementierung des Echtzeitmodells Test der Software-Komponenten Integration der Software-Komponenten 4.9.1 Erzeugung des Programm- und Datenstands 4.9.2 Erzeugung der Beschreibungsdateien 4.9.3 Erzeugung der Dokumentation Integrationstest der Software Integration der Systemkomponenten 4.11.1 Integration von Software und Hardware 4.11.2 Integration von Steuergeräten, Sollwertgebern, Sensoren und Aktuatoren Integrationstest des Systems Kalibrierung System- und Akzeptanztest

147 150 154 155 156 157 158 158 160 162 163 164 165 167 169 170 172 173 174 174 175 176 177 178 179 180 180 181 183 186 187

XII 5

Inhaltsverzeichnis Methoden und Werkzeuge in der Entwicklung

189

5.1 5.2

190

5.3

5.4

5.5

5.6

Offboard-Schnittstelle zwischen Steuergerät und Werkzeug Analyse der logischen Systemarchitektur und Spezifikation der technischen Systemarchitektur 5.2.1 Analyse und Spezifikation steuerungs- und regelungstechnischer Systeme 5.2.2 Analyse und Spezifikation von Echtzeitsystemen 5.2.3 Analyse und Spezifikation verteilter und vernetzter Systeme 5.2.4 Analyse und Spezifikation zuverlässiger und sicherer Systeme Spez ifikat ion von Software-Funktionen und Valid ierung der Spezifikation 5.3.1 Spezifikation der Software-Architektur und der Software-Komponenten 5.3 .2 Spezifikation des Datenmodells 5.3.3 Spezifikation des Verhaltensmodells mit Blockdiagrammen 5.3.4 Spezifikation des Verhaltensmodells mit Entscheidungstabellen 5.3 .5 Spezifikation des Verhaltensmodells mit Zustandsautomaten 5.3 .6 Spezifikation des Verhaltensmodells mit Programmiersprachen 5.3.7 Spezifikation des Echtzeitmodells 5.3 .8 Validierung der Spezifikation durch Simulation und Rapid-Prototyping .. Design und Implementierung von Software-Funktionen 5.4 .1 Berücksichtigung der geforderten nichtfunktionalen Produkteigenschaften 5.4.2 Design und Implementierung von Algorithmen in Festpunkt- und Gleitpunktarithmetik 5.4.3 Design und Implementierung der Software-Architektur 5.4.4 Design und Implementierung des Datenmodells 5.4.5 Design und Implementierung des Verhaltensmodells Integration und Test von Software-Funktionen 5.5.1 Software-in-the-Loop-Simulationen 5.5.2 Laborfahrzeuge und Prüfstände 5.5.3 Experimental-, Prototypen- und Serienfahrzeuge 5.5.4 Design und Automatisierung von Experimenten Kalibrierung von Software-Funktionen 5.6.1 Arbeitsweisen bei der Offline- und Online-Kalibrierung 5.6.2 Software-Update durch Flash-Programmierung 5.6.3 Synchrones Messen von Signalen des Mikrocontrollers und der Instrumentierung 5.6.4 Auslesen und Auswerten von Onboard-Diagnosedaten 5.6.5 Offline-Verstellen von Parametern 5.6.6 Online-Verstellen von Parametern 5.6.7 Klassifizierung der Offboard-Schnittstellen für das Online-Verstellen 5.6.8 Management des CAL-RAM 5.6.9 Management der Parameter und Datenstände 5.6.10 Design und Automatisierung von Experimenten

192 192 196 202 207 214 216 220 220 223 226 231 231 231 243 243 251 266 270 273 276 277 279 285 286 287 288 290 291 291 292 293 294 299 302 303

Inhaltsverzeichnis

6

XIII

Methoden und Werkzeuge in Produktion und Service

305

6.1 6.2 6.3

306 307 308 309 309 310 312 313 315

6.4

Offboard-Diagnose Parametrierung von Software-Funktionen Software-Update durch Flash-Programmierung 6.3.1 Löschen und Programmieren von Flash-Speichern 6.3.2 Flash-Programmierung über die Offboard-Diagnoseschnittstelle 6.3.3 Sicherheitsanforderungen 6.3.4 Verftigbarkeitsanforderungen 6.3.5 Auslagerung und Flash-Programmierung des Boot-Blocks Inbetriebnahme und Prüfung elektronischer Systeme

7 Zusammenfassung und Ausblick

317

Literaturverzeichnis

319

Abkürzungsverzeichnis

325

Sachwortverzeichnis

327

1 Einführung und Überblick Die Erftillung steigender Kundenansprüche und strenger gesetzlicher Vorgaben hinsichtlich •

der Verringerung von Kraftstoffverbrauch und Schadstoffemissionen, sowie

•

der Erhöhung von Fahrsicherheit und Fahrkomfort

ist untrennbar mit dem Einzug der Elektronik in modernen Kraftfahrzeugen verbunden. Das Automobi l ist dadurch zum technisch komplexesten Konsumgut geworden. Die Anforderungen an die Automobilelektronik unterscheiden sich jedoch wesentlich von anderen Bereichen der Konsumgüterelektronik. Insbesondere hervorzuheben sind : •

der Einsatz unter oft rauen und wechse lnden Umgebungsbedingungen in Bezug auf Temperaturbereich, Feuchtigkeit, Erschütterungen oder hohe Anforderungen an die elektromagnetische Verträglichkeit (EMV)

•

hohe Anforderungen an die Zuverlässigkeit und Verftigbarkeit

•

hohe Anforderungen an die Sicherheit und

•

vergleichsweise sehr lange Produktlebenszyklen.

Diese Anforderungen müssen bei begrenzten Kosten , verkürzter Entwicklungszeit und zuneh mender Variantenvielfalt in Produkte umgesetzt werden , die in sehr großen Stückzahlen hergestellt und gewartet werden können . Unter diesen Randbedingungen stellt die Umsetzung der zahlreichen Anforderungen an elektronische Systeme von Fahrzeugen eine Entwicklungsaufgabe von hohem Schwierigkeitsgrad dar. In der Entwick lung von Fahrzeugelektronik ist neben der Beherrschung der zunehmenden Komp lexität vor allem ein konsequentes Qualitäts-, Risiko - und Kostenmanagement eine wichtige Voraussetzung für den erfolgreichen Absch luss von Projekten. Ein grundlegendes Verständnis der Anforderungen und Trends in der Fahrzeugentwicklung ist die wichtigste Voraussetzung, um geeignete Methoden für Entwicklung, Produktion und Service von elektronischen Systemen zu entwickeln und durch praxistaugliche Standards und Werkzeuge unterstützen zu können . In diesem Übersichtskapitel erfolgt ausgehend von einer Analyse der aktuellen Situation eine Darstellung der zukünftigen Perspektiven und Herausforderungen. Neben der Organisation der interdisziplinären und firmenübergreifenden Zusammenarbeit müssen auch viele Zielkontlikte gelöst werden. Nach einem Überblick über die elektronischen Systeme des Fahrzeugs und deren Funktionen folgt eine Einftihrung in Vorgehensweisen zur Entwicklung von elektronischen Systemen und Software ftir Fahrzeuge. Dabei müssen zah lreiche Wechselwirkungen zwischen der Systementwicklung in der Automobilindustrie (eng\. Automotive Systems Engineering) und der Software-Entwicklung (engl. Automotive Software Engineering) beachtet werden . Abschließend werden modell basierte Entwick lungsmethoden vorgestellt, welche die verschiedenen Aspekte berücksichtigen. In den weiteren Kapite ln des Buches erfo lgt eine ausftihrliche Behandlung von Grund lagen, Prozessen, Methoden und Werkzeugen für Entwicklung, Produktion und Service von Software ftir die elektronischen Systeme von Fahrzeugen. Der Schwerpunkt liegt dabei auf den Fahr-

2

Einftihrung und Überblick

zeugsubsystemen Antriebsstrang, Fahrwerk und Karosserie. Der Bereich der Multi-MediaSysteme wird dagegen nicht behandelt.

1.1 Das System Fahrer-Fahrzeug-Umwelt Das Ziel jeder Entwicklung ist die Fertigstellung einer neuen oder die Verbesserung einer vorhandenen Funktion des Fahrzeugs. Unter Funktionen werden dabei alle Funktionsmerkmale des Fahrzeugs verstanden. Diese Funktionen werden vom Benutzer, etwa dem Fahrer des Fahrzeugs, direkt oder indirekt wahrgenommen und stellen einen Wert oder Nutzen ftir ihn dar. Die technische Realisierung einer Funktion, ob es sich also letztendlich um ein mechanisches, hydraulisches, elektrisches oder elektronisches System im Fahrzeug handelt, hat dabei zunächst eine untergeordnete Bedeutung. Elektronische Komponenten in Kombination mit mechanischen, elektrischen oder hydraulischen Bauteilen bieten jedoch bei der technischen Realisierung viele Vorteile, etwa in Bezug auf die erreichbare Zuverlässigkeit, das Gewicht, den benötigten Bauraum und die Kosten . Wie keine andere Technologie ist deshalb heute die Elektronik die Schlüsseltechnologie zur Realisierung vieler Innovationen im Fahrzeugbau. Fast alle Funktionen des Fahrzeugs werden inzwischen elektronisch gesteuert, geregelt oder überwacht.

1.1.1 Aufbau und Wirkungsweise elektronischer Systeme Auf Aufbau und Wirkungsweise elektronischer Systeme des Fahrzeugs soll daher am Beispiel des elektrohydraulischen Bremssystems näher eingegangen werden . Beispiel: Aufbau des elektrohydraulischen Bremssystems [I] In Bild I-I ist der Aufbau des elektrohydraulischen Bremssystems (engl. Sensotronic Brake Control, kurz SBC) von Bosch [I] dargestellt. Die elektrohydraulische Bremse vereint die Funktionen des Bremskraftverstärkers, des Antiblockiersystems (ABS) und der Fahrdynamikregelung, auch elektronisches Stabilitätsprogramm (ESP) genannt. Die mechanische Betätigung des Bremspedals durch den Fahrer wird in der Bremspedaleinheit erfasst und elektrisch an das so genannte elektronische Steuergerät übertragen . In diesem Steuergerät werden unter Verwendung dieses Sollwertes und verschiedener Sensorsignale, wie z. B. dem Lenkwinkelsignal oder den Raddrehzahlsignalen, Ausgangsgrößen berechnet, die wiederum elektrisch zum Hydroaggregat übertragen werden und dort durch Druckmodulation in SteIlgrößen für die Radbremsen umgesetzt werden . Über die Radbremsen wird das Fahrverhalten des Fahrzeugs, die so genannte Strecke, beeinflusst. Die Radbremsen werden daher als Aktuatoren bezeichnet. Das Steuergerät kommuniziert über einen Bus, etwa über CAN [2], mit anderen Steuergeräten des Fahrzeugs. Dadurch können Funktionen realisiert werden, die über die bisher genannten Funktionen hinausgehen. Ein Beispiel daftir ist die Antriebsschlupfregelung (ASR) , die eine übergreifende Funktion zwischen Motorsteuerung und Bremssystem darstellt.

l.l Das System Fa hrer-Fahrzeug- Umwe lt

3

andere Fahri:euge Werbeug (z. B. Dia gnc setester]

Fahrer Lenkwinkel-

sensor

Raddrehz ähl-

sensor

Bus _ - - - - , Elektronische Steuergeräte

~~~~~~~~~~~~~~

Radbremse (Aktuator)

~~2::;;~2:::~R~,~,m;;:;src Slale

FlexRay S"'e

"1.n~er

MaI,"~er

Cornm" n;

00

über in die

Ausfallwahrscheinlichkeit F(t) . Entsprechend ist das Komplement der Ausfallwahrscheinlichkeit die Zuverlässigkeitsfunktion R(/) R(/)

= 1- F (/ )

(2.8)

R(t) drückt also aus, mit welcher Wahrscheinlichkeit im Zeitraum 0 bis I eine Betrachtungseinheit funktionsfähig ist. Anstalt der Zuverlässigkeitsfunktion R(/) wird häufig auch die Ausfallrate A(t) verwendet. Sie spielt in Zuverlässigkeits- und Sicherheitsanalysen eine wichtige Rolle .

Die empirische Ausfallrate A(t) ist definiert durch das Verh ältnis der Anzahl der Ausfälle im Intervall (I , 1+ 01) zur Anzahl der Betrachtungseinheiten, die zum Zeitpunkt I noch nicht ausgefallen sind : },(t) = n(1+ &) - n(/) No - n(t)

(2 .9)

Für No ----> 00 und 01 ----> 0 konvergiert die empirische Ausfallrate A(t) gegen die Ausfallrate A(/) , die mit den obigen Definitionen durch die Zuverlässigkeitsfunktion R(/) ausgedrückt werden kann : A(t) = __1_ . dR(t)

R(/)

dt

(2.10)

2.6 Zuverlässigkeit, Sicherheit, Überwachung und Diagnose von Systemen Ist die Ausfallrate A(t) = 4

R(t) =

_L dR(t) 4

=

kon stant, erg ibt sich die Zuverlä ssigkeitsfunktion zu

oder

dt

95

(2.II)

R(t) = e- At

(2 .12)

Die Ausfallwahrscheinlichke it folgt in diesem Fall einer statistischen Exponentia lverteilung . In vielen Fällen änd ert sich die Au sfallrate 4(t) mit der Zeit. Ein charakteristischer Verlauf ist in Bild 2-54 darg est ellt und wird auch als .Badewannenkurve'' bezeichnet. Eine solche Verteilung der Ausfallwahrs ch einli chkeit wird in der Wahrscheinlichkeitstheorie als Weibull-Verteilung bezeichnet.

Zuverlässigkeitsfunktion R(t)

o

b=====::::~===.~

Nutzungszeit t

o

Ausfallrate ;\,(t)

ausfälle

Hild 2-54: Definition der Zuverlässigkeitsgrößen

zufällige Ausfalle

Beispiel: Empirische Bestimmung der Ausfallrate 1000 Mikrocontroller werden gleichzeitig und gleichartig 1000 Stunden getestet. Dabei werden 10 Ausfa lle bei ungefähr konstanter Ausfallrate beobachtet. Wie groß ist die Ausfallrate? Mit

No = 1000

und

n( 1000h)

R(IOOOh) = No - n(l OOOh) N

o

=

990 1000

=

10

berechnet sich

= 0 99 '

Mit R(lOOOh)=e- Ao\ OOOh erhält man für die Ausfallrate

4'" 1.10 - 5 Ausf älle Stunde

10.\0- 6 Ausfälle Stunde

10 ppm

Die Abkürzung ppm steht für parts per million .

Ausfälle Stunde

96

2 Grundlagen

2.6.2.2 Definition der mittleren aus/allfreien Arbeitszeit MTTF Für die mittlere ausfallfreie Arbeitszeit (engl . Mean Time To Failure, MTT F) gilt bei einer großen Anzahl N von Betrachtungseinheiten:

MTTF= lim

I N

-"~

N -->"" N

(2.13)

L. i=l

Bei konstanter Ausfallrate - und nur dann - gilt: MTTF=

I

(2 .14)

~

Beispiel: Empirische Bestimmung der MTTF 30 Mikrocontroller mit einer konstanten Ausfallrate A von 10-6 Ausfällen/Stunde werden in einem Fahrzeug eingesetzt. Wie groß ist die MTTF unter der Annahme, dass der Ausfall eines Mikrocontrollers toleriert werden kann? Mit No = 30 und

n(MTTF)

R(MTTF) = No -n(MTTF)

No

=

1

berechnet sich

29

30

Mit R(MTTF) = e A-MTTF erh ält man für die MTTF '" 3,4 · I0 4 Stunden» 3,87 Jahre

2.6.2.3 Definition der mittleren Aus/allzeit MTTR Für reparaturfähige Systeme, wie Fahrzeuge, muss die ausfallfreie Arbeits- oder Betriebszeit TB und auch die Ausfallzeit TA betrachtet werden (Bild 2-55). Au sfall verhalten für die Betrachtungseinheit i

nicht :::::::: : : :

-~ ~ L_-------J,'i --t:= =t :t= t r T B!

T A!

T B2

u

Z';l
$ 0 e

D~~--'

~

xa

Bild 4 -2 ~: Kontrollnuss zur Fcstlcgung der Ausführungsreihenfolge in ASCET [74]

4.6.3 Spezifika tion des Echtze itmodells Neben dem Daten- und Verhaltensmodell muss das Echtzeitmodell einer Software-Komponente festgelegt werden, da mit die Spezifikation vollständig ist. Dabei müssen die Anweisungen einer Software-Komponente Prozessen zugeordnet werden. Die Prozesse wiederum müssen Tasks zugeordnet werden. Für die Tasks werden die Echtzeitanforderungen festgelegt.

Betsptct: Festleg ung der Echtzeitanforderungen lm Einführu ngsb eis piel in Bild 4-29 sind die beiden Anweisungen dem Prozess I bereits zugeordnet. Um das Echtzeitverhalten vollständig zu spez ifizieren. muss der Prozess I noch einer Task zugeordnet werden. Dies ist in Bild 4-30 da rgestellt. Der Prozess I ist wie die Prozesse 2 und 3 der Task A zugeordnet.

Task A ~

----,

~A~

Prozess I

Prozess 2

Prozess 3

A",' ~i,""g A""~i" m~

------ ---------------------------_._ Start Task A

---

-

:::::::::

----Zeil t

Relativ e Deadline

,\ kt i\ ie ru n ~

T llsk .\

Bild 4-30: Zuordnung von Berechnungen zu Prozessen und Tasks

-1.6.3.1 Zustandsabhangiges. reaktives Ausf uhmngsmodelt Für sreucrungs- und regelungstechn ische Software-Funktionen kann häufig ein allgemeines Ausflihrungsmodel l zugrunde gelegt werden. wie es in Bild 4·3 1 dargestellt ist.

4 Kernpro zess zur Entwicklung von elektronischen Systemen und Software

168

Die Software-Funktion unterscheidet zwischen einer Initialisierungsberechnung, die einmalig nach dem System start ausgeführt wird , und einer Berechnung, die wiederholt wird . Der Initialisierungsanteil, der Prozess alnib wird durch die Initialisierungs-Task zum Zeitpunkt tlnit aktiviert . Der wiederkehrende Anteil, der Prozess ap, wird von einer zyklischen Task A in einem festen oder variablen zeitlichen Abstand dT A aktiviert. Bei der ersten Ausführung des Prozesses ap werden Zustandsinformationen des Initialisierungsprozesses alnit verwendet. Bei den weiteren Ausführungen werden Zustandsinformationen der jeweils vorangegangenen Ausführung des Prozesses ap verwendet, etwa Ergebnisse der vorangegangenen Berechnung oder auch der zeitliche Abstand dTA zur vorangegangenen Ausführung. Software-Funktionen mit diesen Merkmalen werden auch als zustandsabhängige, reaktive Systeme bezeichnet [75].

Akti vierung durch Initialisierungs- Task zum Zeitpunkt t lnil 1 1

-

[/1

'I'

Information

Initialisierungsberechnung alnil

Aktivierung durch Task A zum Zeitpunkt

tAcl

A0

1-

T 1

:/1

Aktivierung durch Task A zum Zeitpunkt t Acl A I = t Acl A 0 + dT A -

1

'I'

Infor- 1/1 mation 'I'

Wiederkehrende Berechnung a p

-----

Wiederkeh rende Berechnung a p

Aktivierung durch Task A zum Ze itpunkt t Acl A n = t Acl A n-l + dT A 1

-

-

1

[/1 'I'

Wiederkehrende Berechnung a p Zei t t

Bild 4-3 I : Zu standsabhäng iges, reaktives Ausftihrungsmodell für Software-Funktionen

Es ist also eine Aufteilung der Software- Funktion in mindesten s zwei Prozesse a'nit und ap notwendig. Häufig werden Software-Funktionen auch in mehr als zwei Prozesse aufgeteilt, die dann von verschiedenen Tasks aktiviert werden . So können etwa die wiederkehrenden Berechnungen einer Funktion auf mehrere Prozesse aufgeteilt und von unterschiedlichen Tasks mit verschiedenen Echtzeitanforderungen quasiparallel aktiviert werden .

4.6.3.2 Zustandsunabhängiges, reaktives Ausführungsmodell In manchen Fällen ist die Annahme zulässig und vorteilhaft, dass nach durchgeführter Initialisierung ein Prozess nur dann ausgeführt werden soll, wenn ein bestimmtes Ereignis eintritt, ohne dass die Vorgeschichte eine Rolle spielt. In diesem FaH kann ein anderes Ausführungsmodell, wie es in Bild 4-32 dargestellt ist, zugrunde gelegt werden . Wieder ist eine Aufteilung der Software-Funktion in zwei Prozesse b1nit und b E erforderlich. Jedoch wird der Prozess b E nur bei Eintreten des Ereignisses E von Task B aktiviert. Ein solches Ereignis E könnte beispielsweise die Betätigung eines Schalters zur Steuerung der Software-Funktion durch den Fahrer sein. Auch der Prozess bE kann wiederholt ausgeführt werden . Jedoch werden bei der Ausführung des Prozesses bE keinerlei Zustandsinformationen der vorangegangenen Ausführung von b E verwendet. Solche Software-Funktionen werden auch als zustandsunabhängige, reaktive Systeme bezeichnet [75].

4.7 Design und Implementierung der Software- Komponenten Aktivicrung d urch

Aktivicrung durch Task n bei Ereignis E

lnitialisic rungs-Task zum Zei tpunkt tim,

,,

-

[,1

•

,,

Info r-

Aktivicrung durch I ask B bei Ere ignis

I

I nitialisicrungsbcrcc hnung b,""

[,1

Vi

•

•

• Wiederke hren de Berechnung b~

Wiederkeh rende Berechnung b~

A ktivicrung du rch Task A be i Ereignis E

,,

[

[,1

mation

169

Wiede rkeh rende Berec hnung b~

•

Ze il t Hild 4-32 : Zustand sunab hängiges. reak tives Ausflihrungxrnodcllfür Soft ware-Funktionen

Häufig treten Mischform en dieser beide n AusfUhrungsmodelle au f. Für die Modellie rung der Inte raktion zwischen den Prozessen unterschiedl icher Tasks müssen in Ec htzeitsystemen die in Ab schn itt 2.4.6 dargestellten Mec hanismen des Ec htzeitbetriebssyste ms berüc ksichtigt werden. Es kann also zu Rückwirkun gen des Echtzeitmodell s auf das Datenmodell kommen.

4.7 I>esign und Implementierun g de r Software-Komponenten In der Designpha se müssen alle Deta ils der konkrete n Implement ieru ng für das Daten-. Verhalte ns- und Echtzeitmodell einer Software- Komponente festgelegt werde n ( Bild 4· 33). Bei de n Daten ist j etzt zusätz lich zw ische n Variablen und unverände rlichen Parametern zu untersche ide n.

Test-

Spezifi kauen ei ner So fbvarc-Kompcncnte

••

()csil!n &

Datenmodell (Variablen & Param eter)

-

Design einer

Soüw arc-Komponcr uc

crgcbrussc

Implem cnlierun~ einer

Softw are-Kompone nte

Ve rhalten smod ell

Implementierun g einer Softw ere- Kompoucutc (z.H Quclleodc)

Bild 4-33 : Design und Implementierung der Softw are-Kompo nente n

•

Echtzenmodell

Testflllle (Design)

170

4 Kernprozess zur Entwicklung von elektronischen Systemen und Software

4.7.1 Berücksichtigung der geforderten nichtfunktionalen Produkteigenschaften Beim Design und der Implementierung von Software-Komponenten für Seriensteuergeräte muss neben der Umsetzung der spezifizierten Software-Funktionen eine Reihe weiterer Randbedingungen berücksichtigt werden, die sich aus den geforderten nichtfunktionalen Produkteigenschaften ergeben. Dazu gehören beispielsweise die Trennung von Programm- und Datenstand . Ein weiteres Beispiel sind Kostenschranken, die häufig zu einer Beschränkung der verfügbaren Hardware-Ressourcen filhren .

4.7.1.1 Unterscheidung zwischen Programm- und Datenstand Die Trennung von Programm- und Datenstand wird häufig eingesetzt, da damit die Handhabung von Software-Varianten in der Entwicklung, aber auch in Produktion und Service erleichtert wird . In anderen Anwendungsbereichen erfolgt die Entwicklung von Programm- und Datenstand gemeinsam . In der Automobilindustrie ist bei Steuergeräten die Unterscheidung zwischen der Entwicklung von Programm- und Datenstand aus verschiedenen Gründen vorteilhaft. Der Datenstand umfasst dabei alle durch das Programm nicht veränderbaren Daten , etwa die Parameter von Steuerungs- und Regelungsfunktionen . So kann ein einheitlicher Programmstand durch unterschiedliche Datenstände an verschiedene Anwendungen, beispielsweise an verschiedene Fahrzeugvarianten, angepasst werden . Dies führt zu Kosten- und Zeiteinsparungen in der Entwicklung - beispielsweise in der Qualitätssicherung, die für den Programmstand nur einmal notwendig ist. Weitere Merkmale, die zu dieser Vorgehensweise führen, sind : •

Die Erstellungszeitpunkte für Programm- und Datenstand sind unter Umständen unterschiedlich. So muss häufig der Datenstand, beispielsweise im Rahmen der fahrzeugindividuellen Kalibrierung von Software-Funktionen, auch noch zu sehr späten Zeitpunkten unabhängig vom Programmstand geändert werden.

•

Die Erstellung von Programm- und Datenstand erfolgt häufig in unterschiedlichen Entwicklungsumgebungen und von verschiedenen Mitarbeitern - oft sogar über Unternehmensgrenzen hinweg.

•

Die Trennung von Programm- und Datenstand ist nicht nur in der Entwicklung sinnvoll, sondern führt auch zu Vorteilen beim Variantenmanagement in Produktion und Service.

4.7.1.2 Beschränkung der Hardware-Ressourcen Beim Design und der Implementierung der Software-Komponenten müssen vielfach auch Optimierungsmaßnahmen wegen beschränkter Hardware-Ressourcen beachtet werden. Eine Ursache dafllr sind die häufig bestehenden Kostenschranken bei elektronischen Steuergeräten, die bei hohen Stückzahlen zu begrenzten Hardware-Ressourcen führen . Beispiel: Kostenschranken bei Steuergeräten Stark vereinfacht ergeben sich die Kosten eines Steuergeräts als die Summe der Entwicklungskosten und der Herstellungskosten dividiert durch Anzahl n der produzierten Steuergeräte:

171

4.7 Design und Imp lementierung der Software-Komponenten Gesamtkosten pro Steuergerät "" (Entwicklungskosten + Herstellungskosten)/n

Bei hohen Stückzahlen führt dies dazu, dass die zu den Stückzahlen proportionalen Herstellkosten die Kosten eines Steuergeräts dominant beeinflussen (Bild 4-34). Kosten pro Steuerger ät Legende : Herstellungskosten pro Steuergerät Entwicklungskosten pro Steuergerät Gesamtkosten pro Steuergerät -

-

-

-

-

-

-

-

-

~ 0..:--... "",,:,

........ . .

-- . . - .. - . . _.. -

_

Anzahl n der produz ierten Steuergeräte

Bild 4-34: Abhängigkeit der Kosten pro Steuergerät von der produzierten Stückzahl Dabei sind die Kostenstrukturen für Hardware und Software sehr unterschiedlich . Unter der Annahme, dass für die Vervielfältigung der Software nahezu keine Kosten anfallen, werden die Produktionskosten hauptsächlich durch die zu den Stückzahlen proportionalen Hardware-Kosten beeinflusst. Bei hohen Produktionsstückzahlen ist deshalb der Druck zur Reduzierung der zu den Stückzahlen proportionalen Hardware-Herstellungskosten in vielen Fällen sehr groß. Dies wirkt sich dann in begrenzten Hardware-Ressourcen aus , da häufig preiswerte Mikrocontroller in Seriensteuergeräten eingesetzt werden, die nur Integerarithmetik unterstützen und deren Rechenleistung und Speicherplatz sehr begrenzt ist. Um möglichst vie le Software-Funktionen mit einem Mikrocontroller darstellen zu können , sind in der Software-Entwicklung in diesen Fällen Optimierungsanstrengungen notwendig, so dass die verfügbaren Hardware-Ressourcen möglichst effektiv genutzt werden. Je nach den Randbedingungen der Anwendung ist dann ein Ziel bei der Software-Entwicklung, RAM -Bedarf, ROM -Bedarf oder Programmlaufzeit zu reduzieren . Als Gr undregel bei vielen eingesetzten Mikrocontrollern kann dabei dienen, dass der RAM -Bedarf sehr viel stärker als der ROM -Bedarf zu berücksichtigen ist, da RAM Speicher ungefähr die IOfache Fläche von ROM -Speicher auf dem Chip ben ötigt und deshalb auch etwa das IOfache von ROM -Speicher kostet. Dabei dürfen der dadurch steigende Aufwand für Entwicklung und Qualitätssicherung, sowie die bei begrenzten Ressourcen in der Entwicklung zunehmenden Qualitätsrisiken nicht übersehen werden. In der Praxis hat sich deshalb der Ansatz als vorteilhaft erwiesen, die Optimierung der zu den Stückzahlen proportionalen Herstellkosten mit einer Plattformstrategie für Hardware- und Software-Komponenten zu kombinieren. Über verschiedene Konfigurationsparameter können beispielsweise standardisierte Software-Komponenten an die jeweiligen Anforderungen der konkreten Anwendung angepasst werden.

172

4 Kernprozess z ur Entw icklung vo n elektroni sche n Syste me n und So ftwa re

Zwisc hen den verschiedenen Proj ektziele n. a lso Q ua lhäts-, Kosten- und Terminziele n. bestehen a lso viele Abhä ngigkeiten und Zielkonflikte. Dabe i mu ss beachtet werde n. dass e ine Oplimie rungsmaßna hme nicht durch daraus entstehende zusätzliche Au fwände überk ompensiert wird.

Von den zah lreichen Optim ierungsmaßnahmen. die in der Praxis zu m Einsatz kommen, we rden in Abschnitt 5.4. [ einige anhand von Beispielen dargestellt. Viele Optimierungsmaßnahmen habe n a uch Rückwir kungen auf die Spez ifikatio n der Software-Architekt ur und de r So ft-

ware-Komponenten.

·40 7.2 Design und Im plem en tierun g des Date nmodeüs Beim Design und der Implementi eru ng des Datenmodells eine r Softw are- Kom ponente wird untersc hiede n zwischen Variablen und durch das Progra mm nicht verä nder baren Param etern. Für j ede So ftware-Komponente s ind für alle Daten Des ign- Ent sche idungen bez üglich de r prozessor interne n Darstellung und des Speiche rseg ments des Mikroco ntrollers für die Ablage zu treffen . So müssen Variablen in ei nem Sc hreib-Lesespe icher. etwa im RAM, abgelegt werden . während Parameter in ein em Lesespeieber. etwa im ROl\.l, ges peic hert werde n kö nnen. Beispiel: Abbil dung zw ische n der physikalischen Spez ifikation und der Imple me ntierung Die Darste llung des Signals Moto rtemp eratur auf der phys ika lischen Spezifikationse bene und de r konkreten Implementierungsebene ist in Bild 4-35 dargeste llt. Diese Abbild ung muss beispielsweise bei Mess- und Kalibrierwerkzeuge n in umgekehrter Richtung d urchgeführt werd en. Im Mess- und Kallbrierwerkzeug sollen die lmpleme ntierungsg rößen in den spezifizierte n. physika lischen Einhe ile n dargestellt werden. Da zu benöligen die Mess- und Kalibrie rwe rkzeu ge Informat ione n zu dieser Abbildungsvo rschrift für alle relevante n Daten. Diese Informalionen werden in der Beschr e ibuug sdatei abge legt. Im Standard ASA1\.-I·~IC D 2 [ 18] sind Besc hreibun gsfo rmate für die Funktionsum fänge Messen, Ka librie ren (engl. Calibration ) und Diagnose festge legt.

physikalische s Sig nal ..phys"

I.

• Bezeichnung in KIRrtt"t:

I Motortemperalur I •ph ysikalis(he . :inh eit:

Ph vstkalls che l)a'rs t{'lIu n ~

I'm rechnungsrc rme b Quant isierung:

.................. •....••••••.••• •.•••.•••••' om«. hu ptem enne run gstlarstell ung

• \I in inllll-/l\l nim al..e rt : physikalisc he Darstellung :

Implememierungsdarsrellung: Impl ementierung als Variable im RA\1" impf"

T mot

• n ...teithnung im ("0at cn'l an ds

Kom pilieren

-...j Assemble rcodeKom pon clllc

As s.:mh lkrcn

...j Maschinencode-

Lin ken

Komponente

Programmstand

------------------

Spclchcradresscu

1la lcnstand

Bild

~ -J9:

Erzeugung des Programm- und Datenstands

4.9.2 Erzeug ung der Bcschretbun gsdatelen Die Konsistenz zwischen dem Programm- und Datenstand. sowie den Beschreibungsdateien für die Oflboard-Werkzeuge stellt eine gr undsätzliche Anforderung dar. Das Erstel len der software-spezifischen Teile der Beschreibungsdateien ist daher eine Aufgabe, die im Rahmen der Software-Integration geleistet werden muss. In Bild 4-40 ist ein möglicher Ablauf zur Erzeugung einer Beschreibungsdatei HIT M ess-. K allbrier- und Diagnosewerkzeuge nach dem Standard ASAM-MCD 2 dargestellt.

Spc;ilikali ol\ eilK'T Software-Komponente

Implemenl ierung eine r Sottw are-Komponente in Q uellen de

I E r f eUl:Unl: dc r- Besch reihun gsd at ei fur Me,"sen. Kuhb rieren & Diagn ose

Speicheradressen

Z usalLinli,ml atiollen (z B. Werkzeu g-

seh n ins lclle)~

1 i\ Si\ \1 -\1C D 2Gcncne rung

i\SA\1-MC Il2-

eecr

Bild

~ -~O:

Erzeugung der Bcschrcibnngsdurcicn für Mcss-. Kalibricr- und Diagnosewerkzeuge

Dadurch, dass die Spezifikation einer Software-Komponente als Grundlage für das Design und die Implementierung. sowie für die Erzeugung der Beschreibungsdatei verwendet wird. kann die Konsistenz zwischen Programm- und Datenstand, sowie der Beschreibungsdatei gewährleistet werden.

178

4 Kernprozess z ur Entw icklung von elekt roni sche n Syste me n und So ftwa re

Die fllr die Beschreibungsdatei notw endigen Spezifikations informationen könn en alternativ auch in der Implementierung, etwa a ls Kommenta re im Q uelleode , abgeleg t werde n. Auch dieser zweite Pfad ist in Bild 4-4 0 e ingezeichnet. Die A SAI\1-rv1CD 2-Gener ierung verwendet die Spezifi kat ions- und Designinform ationen für

alle Daten und benötigt keine weiteren Eingaben. S eide Verfahren extrahieren die notwendigen Adressinfo rrnationen aus der Datei, die vo m Linker erz eugt wurd e.

.t,9.3 Erzeugung der Dok u mentation Eine Dokum entation der durc h So ftwa re rea lisierten Fahrzeugfunktionen ist aus verschiedenen Gründen erforderlich: •

Die Dokumentation ste llt ei n Arte fakt dar. das für a lle Unterstützungsprozesse in der So ftwar e-Entwicklung selbst benötigt wird. Auch die a usgeprä gte und oft firmen überg reifend e Arbeitsteilung, die langen Produkt lebe nszyklen. sow ie die damit verbundene lange Wartungsphase für die Soft ware erfordern e ine ausführflehe Doku ment ation.

•

Alle folgend en Entwick lungssc hritte - w ie Integratio n. Test und Kalibrieru ng des Systems - benötigen eine Dokumentation.

•

Eine Dokumentation ist für die Fahrzeugproduktion und im wel twei ten Se rvice notwend ig.

•

Fur den Gesetzgeber ist e ine Dokumentation notw endig. etwa a ls Bestandteil für die Beantragun g der Zulassung e ines Fahrze ugs zum Straßenve rkehr.

Die Erwartungen, die diese verschied ene Benutzergruppen (Bild 4·4 1) an eine Dokumentation habe n. fallen erwartungsg emä ß se hr untersc hiedlich aus. Allein wegen des Umfangs, des untersc hiedlich a usge prägten technischen Grundlagen- und Detailverständnisses. verschiede ner Sprachvariante n und Änderungszy klen ist eine ein heitl iche Dokum entation für a lle G rupp en nicht zielführend. Einheitlich ist j edoch die funktionsorienti erte Sicht auf das Fahrzeug. Die Dokum entation kann deshalb funktionso rientiert aufgebaut werden . Die mode llbasierte Spezifikatio n kann als G rundlage für die Doku mentat ion von Software- Funktionen verwendet werden .

* * 0Jj!J -: * * * Gesetzgeber

Produktion

!

Service

Do kumentation

1ikr ocontrollcr, Slcucrg cr'Jt. Expcrhn cmicrsystc m. ... mit auslu hrbarcm t' mg.rolmm. und DalcnstarlU Bild -1 --1 5: Scffware- Hurdware-ln tegration

-1. 11.1.2 Flash-Program mierung Zur Prog rammie rung des Flash-Speiebers sind Prog rammie rroutinen im Mikrocont roller notwendig, die vom Flash-Program mie rwe rkze ug mit Date n ve rsorgt wer den. Mit Hilfe dieser Tec hno logie ist beispie lsweise e in Soft wa re-Update be i im Fahrzeug verbautem Ste uergerät möglich. Hier be i ist jedoch darau f zu achte n, dass der Spe icherbe reic h. in dem die FlashProgrammierr outine n selbst liegen . nicht ge löscht wird. Auf die Flash-Programmier ung von Steuerge räten wird in den Absc hnitte n 5.6 und 6.3 ausfiihrlicher e ingega ngen .

4.11.2 Integration vo n Steuerge rä te n, Sollwe rtge be rn. Sensore n u nd Aktuatoren Aus der a rbeits teiligen, firmen übergreife nden Entwic klung der Ko mpon e nten - wie Steuergeräte n. Sollwertgebe rn. Sensoren und Aktnatoren - erge ben sic h e ine Reihe von beso nderen Anforderungen an gee ignete Integrations- und Testwerkzeuge für ele ktronische Systeme des Fahrzeugs : •

Einer de r in Bild 4-1 dargestellten Tes tschritte stellt me ist a uch de n Abna hmerest des Fahrze ughers tellers für die vom Zulieferer gelieferte Komponente oder das ge lieferte S ubsystem da r.

•

Während der Entwicklung s ind die zur Verfügung stehende n Prototypenfa hrzeuge nur in begrenzter Anzahl vorha nden. Die Kom po nent enlieferante n ver fügen meist nicht über ei ne komplette oder aktue lle Umgebung fU r die zu liefe rnde Komp onente. Diese Umgebung ist Illr j ede Komponente untersc hied lich ( Bild 4-46 ). Diese Einschränkungen in der Test umgeb ung sc hränken die mög lichen Testsc hritte auflieferantensei te unter Umständen e in.

•

Die Kompone nteninteg ration ist e in Sy nchronisationspunkt für alle bete iligte n Ko mpcn entenentwic klu ngen. Integ rations test . Syste mtest und Akzep tanztes t kö nnen erst durchgefU hrt werde n, nachdem alle Kom ponenten vor ha nden si nd. Auf diese Weise verzögern a uftre-

4 Kernprozess zur Entwicklung von elektronische n Systemen und Software

182

tende Verspätungen in den Lieferterminen einzelner Komponenten die Integration des gesamten System s und daher die A usfUhrung al ler darauf fo lgenden Testschritte ( Bi ld 4-47).

,

Lieferant I

,; !,

Liefera nt 2

,

Lieferant 3

Fahr zeughersteller

----------------,----------------T----------------r---------------Ko mpo nente X

Su bsys tem B

Komponente Y

o

Fahrzeug

o

----------------,----------------T----------------r---------------Komponentenumgcbung

Subsystemumgebung

Komponentenumge bung

Sys temumgebung

lJild -1--16: Unters ch iedliche Umge hunge n für Komponenten. SubS)'SIC mC und System e

•

"a"

Komponente X

0

Komponente Y

0

I

Version V I

E 0

'"

I

0

0

I

Vers ion V I Vers ion V2

0

5e,

0

Subsystem B

Fahrzeug

.0I

0

I

0

I

Ve rsion V2

I

.0I

Vers ion V2

~~

@J~

Konfiguration KI

Ze it

•

Ze it

•

Ze it

•

Ze it

Versi on V3

Version V I

~

•

Version V3

ß.

Ko nfig u ratio n K2

Bild -1 -47: Ahhäng igkcircn zwis che n Komponenten- und Sys tem test

4.12 Integrationstest des Systems

183

4.12 Integrationstest des Syste ms Integrations- und Testwerkzeuge für Fahrzeugsysteme berücksichtigen die im letzten Abschnitt dargestellten beso nderen Randbedingungen und verringern die bestehenden Abhängigkeiten und damit das Entwicklungsrisiko. Die Durchführung von Tests kann durch Werkzeuge automatisiert unterstützt werden. In Bild 4-48 sind die Vora ussetzungen und Ergebnisse des Integrat ionstests dargestellt.

Sysle m oder Subsystem

•

Testfalle

Inlcllra l i o n ~ l c~1

des Systems

Testergebnisse

Bild

~ -~8.

.. ..

Integration ste st des Systems

Vorhandene Komponenten. Subsysteme und Komponenten der Systemumge bung werde n als reale Komponenten integriert. N icht vorhande ne Komponenten. Subsysteme und Komponenten der Systemumgebung werden durch Model1 ierung und Simulation. also durch virtuelle Kompo nent en. nachgebildet. Die Test umge bung für eine reale Komponente ist mit einer virtuellen Integrationsplattform verbunden, die die in Bild 4-49 grau gezeic hneten Komponenten nachbildet. Hierbei sind alle Kombi nationen denkbar. Beispielswe ise können Komponenten des Systems oder der Systemumgebung virtuell sein. Integrations- und Testwerkzeuge müssen die folgenden Anforde rungen erfüllen: •

Die virtuelle Testumgebung steht allen Entwic klungspan nern zur Verfügung. Als Abnahmetest kann einer der in Bild 4- 1 dargestellten Testschritte frei gewählt werden. Der Abnahmetest kann beim Lieferanten und beim Fahrzeughersteller mit der gleichen virtuellen Testumgebung durchgefü hrt werde n.

•

Jede r Partner ver fügt über die gleichen virtuellen Komponenten. Angepasst an die jeweilige Situation können daraus Testumgebungen aufgebaut werden (Bild 4-49a1b ).

•

Das Risiko VOll Verzögerungen der Integration durch Verzögerunge n bei einzel nen Komponenten kann verringen werde n. da auch beim Systemtest nicht vorhandene reale Komponenten zunächst durch virtuelle Komponenten nachgebildet werde n können (B ild 4-49c1d ). Auch eine Kombination aus realen und virtuellen Komponenten ist möglich.

•

Die Umgebung besteht zunäc hst vollständig aus virtuellen Komponenten. Diese werden schrittweise durch reale Komponenten ersetzt. Dies erfolgt auf allen Ebenen des Systems.

4 Kernprozess zur Entwicklung vo n elektronische n Systemen und So ftware

184

Test-

a) Komponente

objekt

,

, ---li

r~ - - - - -- - - - -,

.:.' 0''----'":

i,------..-..!._-_. ~ - -J. r

Il.egende: D

real

D

b) Subsystem r - - - - - - - - - - -,

c ) Fahrzeug

,---li r---"" "11

I II

I

"7 .----1

.:.

L_i l__ J

virtuell

li D O 110 h O

I

Hild -I4 ? : Testobjekt und Tcstumgebung

Beispiel: Virtuelle Netzwerkumge bung für das Komb iinstrument In Bi ld 4-50 sind die Kompone nten einer v irtuellen Netzwerkumgebung für das Kombi-

instrument dargestellt. Eine Testumgebung dieser Art wird auch als Restbus-Simulation bezeichnet. D ie Funkt ionsmodelle können als Basis

dener Systemkomponent en verwendet we rden.

lS.Stcucrgcrät

:\IOS1

, Ml- Sys tcrn

Hild -I-50: Virtuelle Netzwerkumgebung für das Kom biinstrument

ruf die Nachbi ldung nicht vorhan-

4.12 Integrationstest des Systems

185

Integratio ns- und Testverfahren dieser Art bieten weitere Vorteile:

•

Viele Prüfschritte. die ohne Testumgebung nur im Fahrzeug durchgeführt werden können, können dam it ins Labor oder an den Prüfstand verlagert werden .

•

Gege nüber Fahrversuchen wird dadurch die Repr oduzierba rkelt der Test- und Anwendungsfälle verbessert oder überhaupt erst möglich . Zudem können die Tes ts aut omatisiert werden .

•

Extrems ituatio nen können ohne Gefährdung von Tes tfahrern oder Prototypen getestet werden.

Ein durchgäng iger Integ rations- und Testprozess von virtuellen Schritten, wie einer Simulation, über Zwischenstufen im Labor und Prüfstand bis ins Fahrze ug ist dam it möglich (Bild

4-5 1).

\"irluell

La bor und Pr ürsta nd

Im

FlI brltu~

Legende:

D

rc'likrucnmmllcr

So tlwarc

S.

~

W·

Sollwertgcbcr

X

Funk tion

r,

fl

p -

S,

W

~\Wandlung N D-

~ Funktion

S, Funktion I S8 S:.J C,

DiAIl Wandlung

.l.!.

Y

f+1" kllialUrer~

S.,

Sensoren

~ Wundhmg \ M I)-

.J Funktion I S11 r

SIO SI~

k

Funktion S , F u n ~li(ln f r, SI'

,

I

sr

S II Funktion

Bild 5-6 :

~

er

r,

ls.,

l.egcude:

f,: SottwareFunktion S,: Signal

Entwurf der technischen Systemarchitektur des Steue rungs- und Rcgchmgsxystcms

Die in Bild 5-3 dargestellt en Steuerungs- und Regelun gskomponenten könn en auch gemeinsam du rch ein Steuergerät realis ie rt werden. wie in Bild 5-6 dargeste llt. Die Rege lungs- und Steuerungskomponente n I ... 7 sollen du rch Sollwe rtge ber, Sensoren. Aktnatore n. A/DWandler, DIA- Wandler und die Softwa re-Funktionen f ... f7 realisiert werde n.

196

5 Methoden und Werkzeuge in der Entwicklung

Wie in Bild 2-60 dargestellt, kann diese Vorgehensweise auch für die Spezifikation der Überwachungs- und Diagnosefunktionen eingesetzt werden . Als Ergebnis liegt für alle Software-Funktionen fn eine Spezifikation der Steuerungs-, Regelungs- und Überwachungsstrategie, der Ein- und Ausgangssignale und der notwendigen Abtastrate dTn vor. Die in den folgenden Abschnitten dargestellten Verfahren gehen von diesen Informationen aus.

5.2.2 Analyse und Spezifikation von Echtzeitsystemen Sollen mehrere Software-Funktionen mit unterschiedlichen Abtastraten durch ein Steuergerät oder ein Steuergerätenetzwerk realisiert werden , so erfolgt die Aktivierung der SoftwareFunktionen durch verschiedene Tasks , an die unterschiedliche Echtzeitanforderungen gestellt werden. Die Einhaltung der Echtzeitanforderung einer Task ist bei vielen Anwendungen im Fahrzeug von großer Bedeutung. Bei der Analyse und Spezifikation des Echtzeitsystems müssen in diesem Fall die Auswirkungen, die sich aus der Zuteilungsstrategie des Betriebs- und Kommunikationssysterns ergeben , genau berücksichtigt werden . Mit Verfahren zur Zuteilbarkeitsanalyse (engl. Schedulability Analysis) ist es möglich , die Einhaltung der Echtzeitanforderungen, wie sie in Bild 2-18 definiert wurden , frühzeitig abzuschätzen und zu bewerten , also schon bevor das Echtzeitsystem zum Einsatz kommt . Dabei kann zwischen einer Analyse der Zuteilbarkeit eines Prozessors an verschiedene Tasks und einer Analyse der Zuteilbarkeit eines Busses an verschiedene Teilnehmer eines Kommunikationssystems unterschieden werden . Die für beide Aufgabengebiete verwendeten Methoden sind recht ähnlich . In diesem Abschnitt wird eine mögliche Vorgehensweise anhand der Prozessorzuteilung behandelt. In praktischen Anwendungen werden diese Analyseverfahren durch geeignete Entwurfs- , Verifikations- und Überwachungsprinzipien ergänzt. Als Ergebnis liegt eine Spezifikation des Echtzeitsystems vor, bei dem alle SoftwareFunktionen ggf. in Prozesse aufgeteilt und die Prozesse Tasks zugeordnet wurden . Ohne Einschränkung der Allgemeingültigkeit wird zunächst angenommen, dass für alle Tasks des Echtzeitsystems die Echtzeitanforderungen in einheitlicher Weise definiert werden durch : •

die konstante oder variable Zeitspanne zwischen zwei Aktivierungen einer Task, in Bild 57 als Aktivierungsrate bezeichnet, und

•

eine zum Aktivierungszeitpunkt relativ vorgegebene Zeitschranke bis zu der die Ausführung einer Task abgeschlossen sein soll. Diese Zeitschranke wird als relative Deadline bezeichnet.

5.2 Ana lyse d er log isch en Sys temarc h ite ktur

-".

-". I

: Aktivieru ng ,.

197

•

Ausführungszeit

Aktlvlcrun g

,.

Aus fOhru ngsze it

Tas k A Zeit t Res onsc-Zc it

Resnonsc-Zen

Relat ive Deadline

Relative Deadline

Aktiv ieru n israrc Bild ~-7 : Definition der Echtzeitanforderungen für die Zutcilharkcitsanalysc um Beispiel der Task A

Eine Ve rletz ung der Ec htzei ta nforder ung für e ine Ta sk liegt dann vor. fa lls die A usfüh rung de r Task n icht innerha lb d ie ser vo rgegebe ne n Ze itsc hranke abgesch lossen wi rd - a lso fa lls: Respon se-Ze it > relati ve Deadline

( 5. 1)

Die Respon se-Ze it ist ke ine kon stante Größe; sie wird durch verschiedene Fa ktor e n bee influsst . Ein e typi sche Ve rte ilung der Respon se-Ze it eine r Tas k ist in Bi ld 5-8 da rgestel lt. Krit isch fü r d ie Ve rletzu ng d er Echtzeitanforderung ist der grö ßte auftretend e Wert der Respo nseZei t t en gl. Warst C as e Re sponse Time, kurz W C RT ). Der Nac hwe is, dass die Echt zeitan forderu ng en e inge ha lten werd en. ist du rch Tests unt er ve rsc hiede nen Rand bed ing un gen und gleichzei tiger Messu ng der Respo nse-Z eit m it eine m au sreich end hoh en Ve rtraue ns nive au häufi g nicht mög lich . Mit zune hme nder A nza h l vo n Tasks und komplexer en Echtze itan forde rungen und Z ute ilungsstrateg ie n ist d ieser Nac hweis d urch Tests o ft sogar unm ögli ch . Auch nach ..er fo lgre ich" ab ge schlosse ne n Tests kann es möglich se in. dass die A usfU hrung e iner Task in krit isch en Situat ione n ers t nach der Dea dl ine ab gesc hlossen w ird . In d iese n Fä llen w ird dann d ie Echtze ita nfo rde rung ver letzt. da der in den Te sts beobacht ete und ge messene größte Wert der Respo nse-Zeit n icht mit dem grö ßte n auftretenden Wert ide ntisch ist.

WahrscheinIichkeir

relative

Deadline

t

kleinster auftretender Wert (Best Cese)

t

Response-Zeit von Task A

größter beobachteter

größter auftretender wert

Wen

( Werst Case )

Bild ~-S : Wahrscheinlichkeitsverteilung der Response-Zeit fllr die Task A

198

5 Methoden und Werkzeuge in der Entwicklung

Typischerweise wird deshalb in der Praxis eine Kombination aus dreierlei Maßnahmen eingesetzt: •

Zuteilbarkeitsanalyse zur Bewertung von Realisierungsalternativen

•

Verifikation der Ergebnisse der Zuteilbarkeitsanalyse durch Messungen nach der Realisierung

•

Online-Überwachung der Deadline durch das Echtzeitbetriebssystem (Deadline-Monitoring) und anwendungsspezifische Reaktion auf Deadline-Verletzungen

5.2.2.1 Zuteilbarkeitsanalyse Das Ziel der Zuteilbarkeitsanalyse ist, unter Verwendung aller bekannten Parameter die Einhaltung der Echtzeitanforderungen in allen Fällen vorab abzuschätzen . Für ein Echtzeitsystem ergibt sich also die Anforderung: Worst Case Response Time :S relative Deadline

(5 .2)

Dazu muss also die Worst Case Response Time (WCRT) bestimmt oder abgeschätzt werden. Im einfachen Fall , wie in Bild 5-7 dargestellt, wird die Response-Zeit zum einen durch die Zeitspanne zwischen Aktivierung und Start der Ausftihrung einer Task bestimmt, zum anderen durch die Ausftihrungszeit (engl . Execution Time) der Task. Der allgemeine Fall ist schwieriger, da die Ausftihrung einer Task z. B. durch die Ausftihrung einer oder mehrerer anderer Tasks mit höherer Priorität, die zudem zeit- oder ereignisgesteuert aktiviert werden können, unterbrochen werden kann . Auch die dabei entstehenden Unterbrechungszeiten und die Ausftihrungszeit, die das Betriebssystem beispielsweise für einen TaskÜbergang selbst benötigt, beeinflussen die WCRT. Allgemein kann die WCRT einer Task in zwei Schritten bestimmt oder abgeschätzt werden. •

Im ersten Schritt erfolgt eine Bestimmung oder Abschätzung der maximal notwendigen Ausftihrungszeit für jede Task (engl . Worst Case Execution Time, WCET). Außerdem müssen die Ausftihrungszeiten, die das Betriebssystem selbst benötigt, bestimmt oder abgeschätzt werden.

•

Im zweiten Schritt kann unter Berücksichtigung der Echtzeitanforderungen und der Zuteilungsstrategie eine Abschätzung erfolgen, ob die Bedingung (5 .2) für alle Aktivierungen der entsprechenden Tasks erfüllt werden kann oder nicht.

Beispiel: Zuteilbarkeitsanalyse Der geplante Tagesablauf eines Managers soll auf Zuteilbarkeit untersucht werden . Der Manager schläft alle 24 Stunden 8 Stunden lang. Er isst alle 8 Stunden für 30 Minuten. Alle 1,5 Stunden trinkt er 15 Minuten und alle 2 Stunden telefoniert er 30 Minuten. Dabei darf das Essen um maximal 30 Minuten verzögert werden, das Trinken ebenfalls um 30 Minuten, Telefonieren dagegen nur um 15 Minuten . Das Schlafen soll innerhalb von 24 Stunden abgeschlossen sein . Daraus ergeben sich die Deadlines für Schlafen 24 Stunden, ftir Essen I Stunde, für Trinken 45 Minuten und für Telefonieren 45 Minuten . Unter der Annahme einer präemptiven Zuteilungsstrategie nach dem Basis-Zustandsmodell für Tasks nach AUTOSAR (Bild 2-20) soll geprüft werden, ob der Manager ne-

5.2 Analyse der logischen Systemarchitektur

199

ben diesen Tätigkeiten weitere Termine wahrnehmen kann. Insgesamt muss der Manager bisher also 4 Tasks ausführen: • •

Task A: "Schlafen" Task C: ,.Trinken"

Task B: ..Essen" Task 0 : "Telefonieren"

• •

Die Prior itäten sind Telefonieren vor Essen vor Trinken vor Schlafen. Der geplante Tagesa blauf kann in tabellarischer Darstellung mit den Prioritäten, Aktivlerungs-, Deadline- und Ausführungs zeite n zusammengefasst werden, Tabelle 5- 1: T a hc lle !i- I :

Ta~k- Li ste

des Managers

Aktivierungszeit

Deadl ine

AusfU hrungszeit

Prlorlt ät

8'

1

Task A

alle 24

h

24 .

Tas k B

alle 8

h

60 min

30 rnin

3

Tas kC

alle I,5 h

45 min

15 min

2

Task D

alle 2

45 min

30 min

4

h

Die Zuteilbarkeit kann anhand des folgenden Ausführungsszenarios untersucht werden:

=

Priorität

i~ i- ~ ; ;

Task D Tas\,

! !

u

-:,

Task C

,

Tas\, A

-. .. t,

Task-Zustan d: ready runnin g ~: :::~ suspended

2

0

i; i i

4

i-; ,i

b;

0

p -

o

o

;

6

8

10

~

12

i- ii; ; i ! ,P- i ; -I i; !pi i i 0

14

0

16

18

o

0

,i ;

~

i i

,i ;

'==-"

2U

!

i

22

24

Zeit

Bild !i-'1: Zuteilungsdiagramm vor der Op tim ierun g

•

Tas k D - "Te lefonieren" - mit der höchsten Priorität wird - wie erwartet - ohne Verletzung der Echtzeitanforderungen alle 2 Stunde n ausgeführt.

•

Task B - " Essen" - wird um 6. 14 und 22 Uhr gleichzeitig mit Task D aktiviert, wegen geringerer Priorität aber erst nach Task D. also mit einer Verzögerun g von 30 Minuten. ausgeführt. Die Deadl ine wird gerade noch eingehalten,

•

Tas k C - "Trinken" - wird alle 90 Minuten aktiviert, wegen geringer Prior ität kann die AusfU hrung jedoch durch Task Bund Task D unterbrochen oder verzögert werden. In vier Fällen wird die Deadline von 45 Minuten gerade noch eingehalten. Der w orst Case tritt um 6 Uhr ein. Die Response-Zeit ist hier 75 Minuten und die Deadline wird verletzt, Bereits 15 Minuten nach Abschluss der AusfU hrung, wird die Task C erneut aktiviert.

5 Methoden und Werkzeuge in der Entwicklung

200

•

Tas k A - ..Schlafen" - hat die ge ringste Priorität und wird erst mit einer Verzögerung von 75 Minuten gestartet und wie erwartet häufig unterbrochen. Von der Aktivie rung bis zum Ende der Ausführung vergehen über 15 Stunde n.

Die kritische Situation um 6 Uhr bei Tas k C. sowie die Grenzsituationen be i Task B zur Verletzung der Echtze itanforderungen können durch verschi edene Maßnahmen entschä rft werd en. In Bild 5- 10 ist ein Szenario dargestellt. bei de m Task B nicht zeitgleich mit Task D aktiviert wird. sondern je weils um eine Stunde versetzt. also um 7, 15 und 23 Uhr. Dadurch können die Echtzeitanforderungen von Task B immer sicher erfUl lt werden. Auch die kritische Situation von Task C um 6 Uhr wird so entschä rft. A llerdings wird weiterh in in fünf Fällen die Deadlin e ger ade noch eingehalten. Eine Erhöhung der Deadline von Task C auf beispielsweise 60 Minuten oder die Erhöhung de r Priorität wären - falls möglich - weitere Ma ßnahmen zur Reduzierung kritischer Situationen. Wie erwartet wirken sich die getroffenen Maßnahmen nicht aufTas k A mit der geringsten Priorität aus.

..

Priorität

i

ij

Task D

Task II

i

.j • i

Task C

•

,

Task ,\

2 Bild

i

i-

s.ro,

,

i

!'" i! • ! i i

.! ,P. ,;

•

•

i

i-

ii

i

i-

~

,P- •

! • i i

~

•

~

! !

r .! ;

i

!

6

8

10

12

Zuteilungsdiagramm nach der Optimierung

"

16

18

i

~

20

i-

• •

• r----+t.:..:J

J"TlJ :

~- - - - ~ XZlIQg

.

Y1

.. , :

,

,

i L-----_-_~--j co-. ---{I]-----=+L:.J 109 ):31

IX1~IQ9 1------- - -------- --------- -------- - -V----~~

.~

•• •• --- - - • • -

~

'12

co- -------------------_.: X21log

Bild 5-30 : Spezifikation Boote scher Ausdrüc ke als Blockdiagram m in ASC ET [74 1

Regeln

XI

X'

X3

YI

R1

0

0

0

0

1'2 0

R2

0

0

1

0

0

R3 R4 R5

0

1

0

0

0

0

I

1

0

0

1

0

0

0

0

R6

I

0

1

I

0

1

1

0

1

1

1

I

1

0

1

'7

.8

' -- - y -- - ' Beding ungen

'-~y-~ A ktionen

Bild 5-3 1: Spezifikation Bootescher Ausdrücke als Entscheidungsta belle

Wie Boo lesche Ausdrücke. können auch Entscheid ungstabellen optimiert werden. So sind in Bild 5-31 nur die letzten drei Regeln R6 bis R8 relevant, da nur in Abhängigkeit dieser Regeln eine der Aktionen Y I od er Y2 ausgeführt werden soll (Bild 5·32).

5.3 Spezifikation von Software- Funktionen und Validierung der Spezifikation

Relevanle { Regeln

XI

X2

X3

YI

\'2

R6

I

0

I

I

0

R7

I

I

0

I

I

R'

I

I

I

0

I

'- -

- y- -

-'

225

'-~y-~

Bedingungen

Aktionen

Bild 5-32 : Optimierung dcr Entscheidungstabelle

Tritt eine Aktion mehrfach bei verschiedenen Regeln auf, so kann die Entscheidungstabelle weiter optimiert werden, indem die Regeln dieser Aktion zunächst paarweise betrachtet werden. Beide Regeln können in einer OD ER-Verknüpfung zusammengefasst werden. Deshalb können sie, wenn sich die beiden Regeln in nur einer Bedingung unterscheiden, vereinfacht werden. da dann die sich unterscheidende Bedingung irrelevant ist. In Bild 5·3 2 treten die Aktion YI und die Aktion Y2 j e zweimal auf. Bei der Aktion Y2 unterscheiden sich die beiden Regeln nur in Bedingung X3. die deshalb irrelevant ist. Hier kann deshalb weiter vereinfacht werde n, indem die Regeln R7 und RS zusammengefasst werden. Irrelevante Bedingungen werden mu " in der Entscheidungstabe lle gekennzeichnet (Bild 5-33). Bei Aktion Y l kann dagegen nicht mehr weiter optimiert werden.

Re levante {

Regeln

"7

"'

,

XI

Xl

I I

I I y

Relevante Bedingungen

X3

,

• •

Y2 I I

~~

Irrclcvamc Aktion

Bedingung

Bild 5 -33 : Optimicrung der Entscheidungstabelle fürAktion Y2

Verschiedene Entscheidungstabellen können auch sequentiell miteinander verknüpft werden, wie beispielsweise in Bild 5·34 dargestellt. Entscheidungstabellen können vorteilhaft überall dort zur Spezifikation von Funktionen eingesetzt werden. wo eine Reihe von Bedingungskombinationen zur Ausführung einer Reihe von versc hiedenen Aktionen führen. Zusammenhänge dieser Art kommen beispielsweise in Überwachungsfunktionen häufig vor. Für eine ausführliche Darstellung zu Entscheidungstabel len wird auf die Literatur, wie [73. 74], verwiesen.

226

5 Methoden und We rkzeuge in der Entwicklung Entscheidungs. tal>cllc 2

Entscheidungs-

tabelle I Xl

Xl

X3

11

mm mm

X4 XS -

YI

Y2

Entscheidungstabelle 3

iiimll---

Y3

~~~~Y4 Bild

~-J4 :

Sequentie lle Vcrknüpfung von Entscheidungstabellen

5.3.5 Spezifikation d es Verhaltens mod ells mit Z usta ndsa uto ma ten Bei viele n Soft ware- Funktionen hängt das Ergebnis nicht nur von den Eingängen . sonde rn auch von einem Ereignis und der Histor ie. die bis da hin durch laufen wurde, ab. Zum Beschreiben de rartige r Zusa mmenhänge eig nen sic h Zustandsautornaten. Die hier beha ndelten Zustandsautomaten orientieren s ich a n den Zustandsaut omaten nac h Moo re. Mealy und Harel

[73. 74. 831· Zustandsautomaten können als Zustandsdiag ramme geze ichnet werd en. Die Z ustä nde (engl. States) werden dabei durch beschriftete Rechtecke mit abgerundeten Ecken dargestellt. Die möglichen Übe rll:änll:e (eng l. Transitions) werden durch beschriftete Pfeile dargestellt. Ein Übergang wird in Abhängigkeit einer Bedingung (engl. Condition) durchgeführt. die dem Übergang zugeordnet ist.

5.3.5. J Spezifikation flacher Zustandsautomaten Beisp iel: Spezifikation der Ansteuerung der Tankreservelampe mit Zustandsautomaten Die Ansteuerung der Tankreservelampe (Bild 2.9) soll als Beispiel für die Spezifikation von Software-Funktionen mit Zustandsautomaten fongesetzt werden. Für die Ansteuerung der Tankreservelampe interessieren nur die Bedingungen ..Signalwen > 8.5V" bzw. .S ignalwert < 8.0 V·· und der bisherige Zustand ..Lampe Aus" bzw. ..Lampe Ein" (Bild 5·35 ). Bedingung ____

--.....Signalwen > 8.5 v ..

Übergang

Zustand Lampe Ein

••Signalwert -e 8.0 v··

Hild 5--35: Spezifikation von Zuständen. Übergängen und Bedingungen

5.3 Spezifikation von Software-Funktionen und Validierung der Spezifikation

227

•

Bisher wurde noch nicht festgelegt, wann die so genannten Aktionen (eng I. Actions) " Lampe einschalten" bzw. " Lampe ausschalten" ausgeführt werden sollen . Diese Aktionen können wie die Bedingungen den Überg ängen zugeordnet werden. In diesem Fall spricht man von Übergangsaktionen (eng I. Transition Actions). Solche Zustandsautomaten werden als Mealy-Automaten bezeichnet. Alternativ können die Aktionen auch den Zuständen zugeordnet werden . Man spricht von Zustandsaktionen (engl. State Actions). Solche Zustandsautomaten werden als MooreAutomaten bezeichnet. Moore- und Mealy-Automaten können auch kombiniert werden, d. h. Aktionen können Zuständen und Übergängen zugeordnet werden. Die Aktionen " Lampe einschalten" und "Lampe ausschalten" in diesem Beispiel sollen den Übergängen zugeordnet werden .

•

Es muss auch festgelegt werden, in welchem Zustand sich der Zustandsautomat beim Start befindet. Dieser Zustand wird Startzustand genannt. Im Fall der Tankreservelampe wird man als Überwachungsmöglichkeit für die Funktionsfähigkeit der Lampe festlegen , dass die Lampe bei jedem Start des Fahrzeugmotors für eine gewisse Zeitspanne eingeschaltet wird . Unabhängig vom Tankfüllstand kann so bei jedem Start des Fahrzeugs erkannt werden, ob die Lampe noch funktionsfähig ist. Der erste mögliche Zustandsübergang soll erst nach einer Verzögerung von zwei Sekunden erfolgen, d. h. die Lampe soll nach dem Start mindestens zwei Sekunden eingeschaltet bleiben . Deshalb wird ein neuer Zustand .Funktionskontrolle" mit einem Übergang nach "Lampe Ein" als Startzustand eingeführt. Der Startzustand in einem Zustandsautomaten wird mit (S) gekennzeichnet. Im Zustand " Funktionskontrolle" wird die Aktion " Lampe einschalten" durchgeführt.

Der so erweiterte Zustandsautomat ist in Bild 5-36 dargestellt:

C2 : "Signalwert > 8,5 V" A2 : "Lampe einschalten"

(S)

c; "Zeitspanne> 2 s" Lampe Aus

CI: "Signalwert < 8,0 V" Al: "Lampe ausschalten"

Legende: Ci: Bedingung (engl. Condition) Ai: Aktion (engl. Action) (S): Startzustand (eng!. Start State)

Bild 5-36: Zuordnung der Aktionenund Definition des Startzustands

Bei der Zuordnung von Aktionen zu Zuständen kann unterschieden werden zwischen: •

Aktionen, die nur beim Eintritt in den Zustand ausgeführt werden (Entry-Aktionen)

•

Aktionen, die beim Verlassen des Zustands ausgeführt werden

(Exit-Aktionen)

•

Aktionen, die beim Verweilen im Zustand ausgeführt werden

(Static-Aktionen)

228

5 Methoden und Werkzeuge in der Entwicklung

Wie in Bild 5-37 dargestellt. ist eine Entry-Aktion eines Zustands äquivalent zu einer Übergangsaktion, die allen zu einem Zusta nd führenden Übergängen zugeordnet wird. Genauso ist eine Exil-Aktion eines Zustands äquivalent zu einer Übergangsaktion. die allen von einem Zu stand wegführenden Übergängen zugeordn et w ird.

Entry- Aktlon: A l

Static- Aktlon: --

Exit-A ktion: A l

Hild 5-37: Äquivalente Aktio nen in Zusta ndsautornaten

Zustandsautomaten verhalten sich determ inistisch, wenn es von jedem Zustand aus zu jede r Eingabe von Eingangsgrößen nur höch stens einen Zustandsübergang gibt. Nichtdetermin istische Situationen könnt en z. B. entstehen, falls mehrere Bedingungen verschiedener Übergänge. die von einem Zustand weg führen. gleichzeitig wahr sind. Situationen dieser Art können durch die Vergabe von Prioritäten ausgeschlossen werden, indem jedem von einem Zustand wegführenden Übergang eine untersch iedliche Pri orität zugeordnet wird. Die Prioritäten werden in der Regel in Form von Zahlen spezi fiziert. Im Folgenden definiert eine größere Za hl eine höhere Priorität. In Bild 5-38 führen drei Übergänge vom Zustand X weg . Im Falle. dass die Bedingung C2 wahr ist, wäre das Verhalten des im Bild links dargestellten Zustandsautomaten nicht deterministisch, da zwei Übergänge möglich wäre n. Durch die Einführung einer Priorität, wie auf der rechten Se ite im Bild dargestellt. wird festgelegt. dass in diesem Fall der Übergang mit Priorität (3) und die Aktion A2 ausgefüh rt werde n.

c,

c,

Zustand X

C, A,

c! A,

C,

A,

Priorität:

C, A,

"

(3)

C! A,

Bild 5-38 : Deterministische Zustan dsa uto maten d urch Vergabe vo n Priorit äten

2)

C, A.,

5.3 Spezifikation von Software-Funktionen und Validierung der Spezifikation

229

Für einen Zustandsautomaten muss außerdem das Ereignis festgelegt werden, bei dem die Bedingungen der vom aktuellen Zustand wegführenden Übergänge geprüft, und ggfs. die entsprechenden Aktionen und Übergänge ausgeführt werden. Dieses Ereignis zur Berechnung des Zustandsautomaten wird beispielsweise in Bild 5-39 durch die Methode "triggerO" vorgegeben, die jedem Übergang zugeordnet wird .

Zustand X triggert)

(3) (2) triggen)

Al

A;

(1 )

C2

C,

Zustand Y

triggert)

C3 A3

Zustand W

Bild 5-39 : Methode "triggerO" zur Berechnung des Zust andsautomaten

Bei jedem Aufruf der Methode "triggerO" werden die folgenden Berechnungen ausgeführt: •

Prüfung der Bedingungen für die vom aktuellen Zustand wegführenden Übergänge nach absteigender Priorität

•

Falls eine Bedingung wahr ist

•

•

Durchführung der Exit-Aktion des aktuellen Zustand

•

Durchführung der Übergangsaktion des Übergangs

•

Durchführung der Entry-Aktion des neuen Zustands

•

Übergang in den neuen Zustand

Falls keine Bedingung wahr ist •

Durchführung der Static-Aktion des aktuellen Zustands

Es wird also bei jedem Aufruf der Methode "triggerO" maximal ein Zustandsübergang durchgeführt.

5.3.5.2 Spezifikation von Übergängen mit Verzweigungen Treten Bedingungen etwa der Form CI & C2 bzw . Cl & C3 an Übergängen auf, die vom selben Zustand wegführen, kann dies übersichtlicher mit verzweigten Übergängen dargestellt werden. Die beiden Darstellungen in Bild 5-40 sind äquivalent. Die Bedingungen und Aktionen in Zustandsautomaten können auf verschiedene Art und Weise spezifiziert werden, z. B. als Blockdiagramm, Entscheidungstabelle oder auch als unterlagerter Zustandsautomat. Alternativ ist auch die Spezifikation in einer Programmiersprache möglich .

230

5 Meth oden und Werkzeuge in der Entw icklun g

Zus tand X

Zustand X

(I )

c,

.. Verzwei gun gs-

,,/ punkt (2}C

Zustand V

Zustand W

Zustand V

ru c,

Zustand W

Hild 5-411: Äqui valente Mod ellicrung von Z ustandsübergängen

5.3.5.3 Spezifikation hierarchischer Zustandsautomaten Mit zunehm ender Anzah l von Zuständen und Übergängen we rden Zu standsdiagra mme schnell unüb ersichtlich. Durch hierarchisch gesc hac htelte Z ustä nde kann die Über sichtlichkeit erha lte n werde n. Es ent stehen hierarc hisc he Zusta ndsd iagramme mit Ba siszust änden und Hierarchiezuständen . •

Für j eden Hierarchiezustand wird e in Basisz ustand als Startzustand festgele gt. Übergänge, d ie zu einem Hierarchiezustand führen. bewirken einen Übergan g in diesen Startzustand.

•

After nativ kann ein Hie rarchiezusta nd mit Gedäc htni s d efi niert werden. Be i j edem Überga ng. der zu ei nem Hiera rchiezustand führt, welcher mit ei nem ..H·· für History geke nnzeic hnet ist. wird der zu letzt eingenomm ene Basiszustand in diesem Hierarchiez ustand wieder e inge nommen. Der Startz ustand de finiert dann de n Bas iszustand für de n erste n Eintritt in de n Hierarc hiezustand.

Übergä nge kön nen auch über Hiera rchieg renzen hinweg festgelegt werd en. Daher muss die Priorität von Übergängen. die von ei nem Basiszustand wegführen. gegenübe r Übergä ngen. die von e inem Hierarchiez usta nd wegfü hren, ein deu tig ge rege lt werden. Entspreche ndes g ilt für die Reihenfolge de r Durchführung de r Akti o nen. d ie für den Hiera rchiezustand und den Bas iszustand festgelegt sind. (S)

Zustand Z Zustand V

(S)

( I)

(2 )

(I)

Zusta nd W

ßild

~-I I :

Hierarchischer Zustandsautomat

5.3 Spezifikation von Software-Funktionen und Validierung der Spezifikation

231

Ein Beispiel für einen hierarchischen Zustandsautomaten ist in Bild 5-41 dargestellt. Auf der obersten Hierarchieebene sind die Zustände X, Y und Z definiert. Der Startzustand ist der Zustand X. Die Zustände V und W sind Basiszustände des Hierarchiezustands Z. Der Basiszustand V ist der Startzustand des Hierarchiezustands Z. Der Übergang vom Zustand Y zum Hierarchiezustand Z führt also zu einem Übergang in diesen Startzustand V, genauso wie der direkte Übergang von Zustand X über die Hierarchiegrenze des Zustands Z zum Zustand V. Für eine ausführliche Darstellung wird auf die Literatur, z. B. [74], verwiesen.

5.3.6 Spezifikation des Verhaltensmodells mit Programmiersprachen Die Festlegung des Verhaltens einer Software-Komponente in einer Programmiersprache wird häufig bevorzugt, wenn ein Verhalten zu formulieren ist, das nur umständlich oder unverständlich datenflussorientiert oder zustandsbasiert beschrieben werden kann . Ein Beispiel dafür sind Such- oder Sortieralgorithmen mit zahlreichen Schleifen und Verzweigungen . Beispiel: Spezifikation der Software-Komponente " Integrator" in der Programmiersprache C Bild 5-42 zeigt die Methoden der Software-Komponente "Integrator" aus Bild 5-27 in der Sprache C [84].

5.3.7 Spezifikation des Echtzeitmodells Neben der Spezifikation des Daten- und Verhaltensmodells einer Software-Komponente muss das Echtzeitmodell festgelegt werden (Bild 4-31 und 4-32) . Wird ein Echtzeitbetriebssystem eingesetzt, so muss die Konfiguration des Echtzeitbetriebssystems definiert werden . Neben den verschiedenen Betriebszuständen , den Übergängen und Übergangsbedingungen muss die Zuteilungsstrategie, sowie die Task-Prozess-Liste für jeden Betriebszustand spezifiziert werden . Durch die Prozess- und Message-Schnittstellen der Module und die Berechnung von dT durch das Betriebssystem kann die Spezifikation der Echtzeitanforderungen von der Verhaltensspezifikation der Module und Klassen getrennt werden . Für die verschiedenen Betriebszustände müssen die Initialisierungs- und die wiederkehrenden Prozesse festgelegt werden.

5.3.8 Validierung der Spezifikation durch Simulation und Rapid-Prototyping Die Analyse der Software-Anforderungen und ihre formale Spezifikation, beispielsweise durch Software-Modelle, reichen oft nicht aus, um eine ausreichend klare Vorstellung von dem zu entwickelnden Software-System zu erhalten oder den Entwicklungsaufwand vorab abzuschätzen. Es werden deshalb häufig Anstrengungen unternommen, Methoden und Werkzeuge einzusetzen, die es erlauben, die formal spezifizierten Software-Funktionen zu animieren, zu simulieren oder auch im Fahrzeug erlebbar zu machen und so eine Software-Funktion frühzeitig zu validieren . Die Nachbildung und Ausführung einer Software-Funktion auf einem Rechner wird als Simulation bezeichnet. Die Ausführung einer Software-Funktion auf einem Rechner mit Schnittstellen zum Fahrzeug, einem so genannten Experimentiersystern, wird Rapid-Prototyping genannt.

232

5 Methoden und Werkzeuge in der Entwicklung /* Variablen */ extern rea164 memory;

extern rea164 dT; /* Methode compute{) */ void compute (rea164 in, rea164 K, rea164 MN, rea164 MX, sint8 E)

rea164 if E {

temp_l;

=

temp_l memory + in * (K * dT); if (temp_l > MX) { temp_l

= MX;

}

if (temp_l < MN) { temp_l memory

= MN;

= temp_l;

/* Methode out{) */

rea164 out (void) return (memory);

/* Methode init{) */ void init (rea164 IV, sint8 I) i f I{

memory

IV;

Bild 5-42: Spezifikation der Methoden der Klasse " Integrator" in der Sprache C [84]

Soll das Modell der Software als Basis für Simulations- und Rapid-Prototyping-Verfahren verwendet werden , dann werden Modell-Compiler benötigt, die es ermöglichen, das Spezifikationsmodell direkt oder indirekt in Maschinencode zu übersetzen, der auf einem Simulationsoder Experimentiersystem ausgeführt werden kann. Die für den Modell-Compiler erforderlichen Designentscheidungen werden dabei entweder implizit im Modell festgelegt oder vom Modell-Compiler zunächst so getroffen, dass das spezifizierte Modell möglichst genau nachgebildet wird .

5.3 Spezifikatio n von Software- Funktio nen und Valid ierung der Spe zifikation

233

In Bild 5· 43 ist der Aufb au eines Ra pid-Prototyping-We rkzeugs [74] dargestellt . Das mit eine m Modellierwerkzeug spezifizierte Modell einer Softwa re- Funktion wird von eine m ModellCompiler zunächst in Quelleode übersetzt . Im zweite n Schritt wird dieser Quelleod e mit einem Compiler-Too l-Set in einen Programm- und Datenstand für das Experimentiersystem übersetzt. Mit einem Dow nload- oder Flash-Pro gra mmierw erk zeug wird der Progra mm- und Datenstand a uf das Experimentiersystem geladen und kann da nn au sgefü hrt werd en. Die Ausfüh rung ka nn mit einem so genannten Experimentierwerkzeug gesteue rt, pararne triert, animiert und beobachtet werden. Neben der Basis für das späte re Design und die Implementierung stelle n die Software-Mode lle in diesem Fall auch die Grund lage für Simulations- und Rap id-Prototyping-M ethod en dar. Bei Verw end ung eines Exper imentiersystems kann so die Validierung der Software- Funktionen frühzeitig und una bhä ngig vo m Steuergerät erfo lgen. Darüber hina us kann das Expcrimentie rsystem später als Referenz für die Steuergeräte- Verifi kation verwen det we rden.

5.3.8.1 Simulation In viele n Fällen solle n in de r Simulation nicht nur die Softwa re-Funktion an sich nachgeb ildet werde n, sondern es interessiert auc h das Zusa mme nspiel der Software- Funktio nen mit de r Hardware, mit den Sollwertgebern. Se nsoren und Akruatoren. sow ie mit der Strecke.

Rapid-Prutcu yping-We rkzcug

Modcllicrwcrkzcu

Modell de r SoftwareFun ktionen Modell-Compiler

H

Quellcode-

Ko mponente

~

Expcrimcnticrsystem

1 Download Werk zeug

J_ Co m pile r-Tool, Se t

\"I lJI

werk zcu g

Pw gm rnnl' tand

... .. .. ... ... ..... ... Datenstand

1

Flash Programmierwe rkze ue

Expcrnue nnc rsystcm mit ausführba rem Prog ram m- & Datenstand

Bild 5~J : Aufbau

Expcrimemicr-

Rapid- Prototypi ng-W c rkl-cugclI [74)

E xpcrtmcnucrsysrcm

234

5 Methoden und Werkzeuge in der Entw icklun g

---:l

~---------------------- ----------- ---,

: I

I

I

F'h~.'J.

1:.

Sollwert-

IV

geher

umw~ ~

!!

Xi Strecke I;l;

Aklualorcn ~

I

I

I

Sensoren

!!

Puhrzcus

Bild 5...U : Mod ellbild ung und Sim ulation für Software-Funktionen und Umgebungskomponenten

Dann muss a uch für diese aus Sicht der Software-Entwic klung so ge nannte n Umgebungsko mpon enten eine Modellbildung durc hge führt werden. Es e ntste ht e in virtuelles Fa hrer-, Fahrzeug- und Umweltmodell, das mit dem virtuellen Steuerge räte- und So ftwa re-Modell verbunden wird . Dieses Modell kann dann a uf eine m Simulation ssyste m. beispielswe ise einem pe, ausgeführt werd en (Bild 5· 44). Die se v o rgehen swelse wird a uch a ls Model-jn-the-Loop Simulation, kurz MiL-Simu lation , bezeichn et und ist auch zur Entwicklung vo n Fahrzeugfunktio nen geeignet. die nicht durch So ftware realisiert werden. Auf die Modellbildung und Simu latio n für Umgebungskomponenten wird nicht näher e ingegange n. Für e ine aus führlic he Dars tellun g wird a uf die Literatur, z. B. [35J, verw iese n.

j.3.8.2 Rapid-Prototyp ing Da de r Begriff Prototyp in der Aut omobili nd ustrie in versc hiedenen Zusa mmenhängen benutzt wird, ist eine geneuere Definition und Abgre nzun g des Beg riffs bei Verw endung in Zusa mmenh ang mit de r So ftware-Entw icklung notw endig. Im a llgeme inen w ird im Fahrzeugba u unter e inem Prototy p e in erstes Muster e iner g roßen Se rie von Produkten, ei nes Massenp rodu kts. verstanden. Ein Software- Prototy p unterschei det sich davon . denn die Vervielfältigung ei nes Softwa re- Prod uktes stellt kein techni sches Problem dar. Im a llgemei nen ist e in Prot otyp ein techni sches Modell eines neuen Produkts. Dabei kann zw ischen nicht funktionsflihigen Prototy pen. wie beisp ielswe ise Windk analmodellen. funktionsfä hige n Proto typen. wie Prototypfahrzeugen. oder seriennahe n Prototype n, wie Vorserien fa hrzeuge n, unte rschieden werd e n. Unter ei ne m Software-Prototyp wird in diesem Buch immer ei n funktionsfähiger Prototyp vers ta nden, der Software-Funktio nen - durchaus mit unterschi edlichen Zielricht ungen und in untersc hiedlic her Ko nkretlslerung - im praktische n Einsatz ze igt. Unter Raptd- Protntyptng

235

5.3 Spezifikatio n von Software- Funktio nen und Validierung der Spe zifikation

werden in diesem Zusammen hang Methoden zur Spezifikation und Ausfü hrung von So ftwareFunktionen im realen Fahrzeug zusammengefasst. wie in Bild 5-45 in einer Übersicht da rgestellt. Versch iedene Methoden unter Venv endung von Entwick lungssteuergeräten und Ex perimeneiersystemen werden in den folgenden Abschnitten beha ndelt . Entwicklungssteuergeräte werde n dabei grau dargestellt. Wegen der Schnittstellen zum realen Fahrzeug muss die Ausfiihrung de r Software-Funktionen auf dem Experimentlersystem unter Echtze itanforde rungen erfolgen. Als Experimentiersysteme kommen meist Echtzeitrechensysteme mit deutlich höherer Rechenleistung als Ste uergeräte zum Einsatz. Damit sind Softw are-Optimierungen z. B. wege n begrenzter Hardware-Ressourcen zunächst nicht notwendig, so dass der Modell-Compiler das Modell unter der Annahme einheitlicher Design- und Implement ierungsentscheidungen so übersetzen kann, dass das spezifizierte Verhalten mögl ichst genau nachgeb ildet wird. Modular aufgebaute Experiment iersysterne können anwe ndungsspezifisch konfiguriert werden, beispielsweise bezüglich der benötigten Schnittstellen für Eingangs- und Ausgangssignale. Das ganze System ist für den Einsatz im Fahrzeug ausgelegt und wird z. B. über einen PC bedient. Damit können die Spezifikationen von Software-Funkt ionen direkt im Fahrzeug validiert und ggfs. geändert werden, wobe i Änderungen am Programm- und Datenstand möglich sind.

~"re, I -.--rW · gc

Fahrlcug

z, -6

r+ . Reg~~ rt!l

Sollwert- W -ber

Umwelt

Steuerung!

Ubcrwac un

R

W Ji

X

Aktuatoren ~

--

~ Steuerge rät

Hild

5-~ S:

Strec ke

~

Sensoren Ji. .

~ ~~

~

,I

!!

Expcr imcntic r-

system

Rapid- Prorcty ping fiir Software-Funktionen im realen Fuhrzeug

5.3.8.3 Horizontale und vertikale Prototypen Bei der Prototypenentwic klung können zwei versc hiedene Zielrichtungen unterschieden werden: •

lI ori zon tale Prototype n ziele n auf die Darstell ung eines breiten Bereichs eines Software Systems, stellen aber eine abstrakte Sicht dar und vernachlässigen Details.

•

Vertikale Prototypen stellen dagegen einen eingeschränkten Bereich eines SoftwareSyste ms recht detailliert dar.

236

5 Methoden und Werk zeuge in der Entw icklung

Bild 5· 46 zeigt die Zielricht unge n horizonta ler und vertikale r Prototypen anband eines Ausschnitts aus dem Software-Syste m. Sof'twarc-Arch he ktu r

Vcrtikakr Prototyp -~-::"1 - - - - - '

Jl c 11 11 11 11

__I

,

-~

~

l_

-,.-__ - -T---) A_I IL

--- -

_

~

~ _

,

~,

~1:_~~ ~~~Jl~ 11

I,

I

L -.-J' L-',:::r:.~ ~_·L'-~ :

:

r-lr,r-T_~~ :

11

::I, :I

lJ!.b~!.6odb-- MI '\:

~y. '" 0 " pny. ntin

a phy, m",

aphy, M AX

Biltl 5-65: Zusammenhang zwischen physikalischer Größe und Implementierung

5.4 Design und Implementierung von Software-Funktionen

261

Bei den Grenzwerten ist zum einen der Wertebereich, der sich aus der Darstellung auf der Implementierungsebene ergibt, zu beachten. Im Bild 5-65 hat aimpl die Darstellung uint8 mit dem Wertebereich {O, I, 2, ..., 255} oder allgemein mit dem Wertebereich {aimpl MI N, ..., aimpl MAX} ' Entsprechend erhält man für dieses Beispiel für den physikalisch darstellbaren Wertebereich die oberen und unteren Grenzen: aphys MIN

= (aimpl MIN- Koa)/K la = (-Koa)/K la

aphys MAX = (aimpl MAX-KOa)/Kla = (255- Koa)/Kla

(5.27) (5.28)

Dieser Wertebereich darf nicht mit dem Bereich der physikalisch auftretenden Werte mit den Grenzen aphys min und aphys max verwechselt werden, dem auf der Implementierungsebene der Wertebereich {aimpl min ... a impl max] zugeordnet werden kann. Für die Größen bund c gelten ähnliche Beziehungen. Im linearen Bereich gilt: aimpl (aphys) = KIa • aphys + Koa

(5.29)

bimpl (bphys) = K1b • bphys + KOb

(5.30)

cimpl (Cphys) = KIe • Cphys + Koe

(5.31)

Da auf der Implementierungsebene nur Festpunktwerte dargestellt werden können, muss in jedem Fall noch eine Rundung durchgeführt werden, die in der Darstellung in Bild 5-65 weggelassen wurde. l/Kli wird auch als Quantisierung oder Auflösung und KOi als Versatz oder Offset bezeichnet. Die Addition der physikalischen Größen auf der Implementierungsebene kann nach dem folgenden Algorithmus erfolgen: •

•

Schritt I : Entfernen der Offsets von aimpl und bimpl aimpU = aimpl - KO a

(5.32)

bitnpU= bimpl - KOb

(5.33)

Schritt 2: Angleichen der Quantisierung von aimpU und bimpU aimpl_2 = aimpU • KIJ Kla

•

Schritt 3: Addition CimpU = aimpl_2 + bimpU

•

(5.35)

Schritt 4: Angleichen an die Quantisierung von cimpl cimpl_2 = cimpU • KIel KIb

•

(5.34)

(5.36)

Schritt 5: Einrechnen des Offsets von Cimpl cimpl

= cimpl_2 + Koe

(5.37)

Alternativ kann ab Schritt 2 auch mit der Quantisierung von aimpl gerechnet werden. In diesem Fall muss bimpl an die Quantisierung von aimpl angeglichen werden. Schritt 4 ändert sich dann entsprechend . In der Regel wird man wegen der höheren Genauigkeit auf die feinere Quantisierung angleichen. Eine dritte Alternative wäre, ab Schritt 2 direkt mit der Quantisierung des Ergebnisses Citnpl zu rechnen.

262

5 Methoden und Werkzeuge in der Entwick lung Bei geschickter Auswahl einer dieser Alternativen kann die Anzahl der notwendigen Umquantisierungen gering gehalten werden. Bei geschickter Wahl der Quantisierungen durch K la, KIb und K lc können die notwendigen Umrechnungen durch Schiebeoperationen ausgeführt werden. Dazu empfiehlt es sich , die Quantisierungen so zu wählen, dass die Verhältnisse Klb /Kla, Klc /Klb, ... Werte aus der Menge {2 1, 22, ..., 2n} annehmen . Bei identisch gewählten Quantisierungen entfallen die Schritte 2 und/oder 4 vollständig. Durch Intervallarithmetik mit den Schranken aimpl min und aimpl max kann vorab geprüft werden, ob die Zwischenergebnisse mit dem Wertebereich aimpl MIN und aimpl MAX der gewählten Darstellung des Operanden a ohne Überlautb ehandlung dargestellt werden können oder nicht. Durch Korrekturen der Parameter K 1i und KOi können numerisch günstigere Intervalle vorgegeben werden, so dass die Genauigkeit der berechneten Ergebnisse höher ist. Begrenzungen und Überlautbehandlungen können vermieden werden, wenn die Zwischenrechnungen mit einer Darstellung größeren Wertebereichs ausgeführt werden. We itere Optimierungen sind durch eine Aufteilung in Online- und Offl ine-Berechnungen möglich . So können etwa die Divisionen in (5.34) und (5.35) offline berechnet werden . Optimierungen dieser Art wurden im letzten Beispiel zur Erleichteru ng des Verständnisses bewusst vernachlässigt.

5.4.2.8 Physikalische Modelleb ene und Implem entierungsebene Wie das letzte Beispiel zeigt, macht eine Unterscheidung zwischen der physikalischen und der Implementierungsebene für Algorithmen Sinn , da so physikalische Zusammenhänge und mikroprozessorspezifische Details der Implementierung, etwa die Wahl der Quantisierung, der Wortlänge und der Strategie für die Integerarithmetik getrennt betrachtet werden können. Auf der physikal ischen Ebene eines Modells kann zwischen wertkontinuierlichen, wertdiskreten und Booleschen Größen unterschieden werden : •

Wertkontinuierliche Größen repräsentieren meist wertkontinuierliche, physikalische Signale - wie beispielsweise Temperaturen, Drehzahlen oder Drücke.

•

Wertdiskrete Größen repräsentieren natürliche Größen - wie die Anzahl der Zylinder in einem Motor oder die Anzahl der Gangstufen in einem Getriebe.

•

Boolesche Größen beschreiben Zustandspaare - wie etwa eine SchaltersteIlung, der ein Zustand des Paares {" Ein" , " Aus" }, { " Wahr", "Falsch"} , {"I ", "O"} oder allgemein {TRUE, FALSE} zugeordnet werden kann .

Soll eine wertkontinuierliche Größe in Festpunktdarstellung implementiert werden, muss sie dazu diskretisiert werden . Dieser Aspekt der Wertediskretisierung gewinnt bei der DatenmodelIierung deshalb häufig zentrale Bedeutung. Das bedeutet, dass jedem physikalischen Wert Xphys gen au ein diskreter Implementierungswert Xitnpl der Menge {XI , X2, X3, '" ,X n} eindeutig zugeordnet werden muss .

mit

Ximpl min ::; Ximpl ::; Ximpl max

(5.38)

5.4 Design und Implementierung von Software-Funktionen

263

Diese Abbildung wird in der Regel durch eine Umrechnungsformel und die Angabe von Minimal- und Maximalwerten auf physikalischer Modellebene oder Implementierungsebene beschrieben. Während beim Design der Software-Komponenten die Transformation von der physikalischen Modellebene in die Implementierungsebene durchgeführt werden muss , ist beim Messen steuergeräteintemer Größen in späteren Entwicklungsphasen, aber auch in Produktion und Service die Umrechnung von Implementierungsgrößen in physikalische Einheiten notwendig.

5.4.2.9 Einige Hinweise zur Implementierung in Festpunktarithmetik Entscheidend für die Güte des Resultats eines Algorithmus ist der relative Fehler. Wie in den letzten Abschnitten gezeigt, wird die numerische Genauigkeit durch Ganzzahldivisionen. sowie durch Überlauf- und Unterlaufbehandlungen begrenzt. Für die Implementierung können davon eine Reihe von Hinweisen und Richtlinien abgeleitet werden : Hinweise für Ganzzahldivisionen •

Der relative Fehler von Ganzzahldivisionen ist groß . Ganzzahldivisionen sollten deshalb möglichst vermieden werden .

•

Divisionen durch 0 sind nicht definiert und müssen als Ausnahme behandelt werden . Eine Möglichkeit ist der Ausschluss über Begrenzungen oder Abfragen.

•

Divisionen durch I und - I sind trivial und können mit einer ähnlichen Strategie vermieden werden .

•

Divisionen durch Werte aus der Menge {21, 22, ..., 2 n } können bei nicht vorzeichenbehafteten Größen effektiv durch Schiebeoperationen ausgeführt werden .

•

Können Divisionen nicht vermieden werden, so sollte möglichst am Ende eines Algorithmus dividiert werden, damit der relative Fehler erst spät in das Resultat eingeht.

•

Je größer das Ergebnis der lntegerdivision, desto geringer ist der relative Fehler. Deshalb sollte der Zähler nach Möglichkeit wertmäßig wesentlich größer als der Nenner gewählt werden . Dies kann beispielsweise durch Vorgabe eines Offsets oder eine Umquantisierung mittels Schiebeoperation vor der eigentlichen Division erreicht werden . Nach der Division muss im Verlauf des Algorithmus der ursprüngliche Offset oder die ursprüngliche Quantisierung natürlich wieder hergestellt werden .

Beispiel: Berechnung der Division Cphys

=

aphys/bphys

Die Variablen aimpl und temp liegen in uintl6-Darstellung vor; die Variablen bimpl und CiInpl in uint8-Darstellung. Die physikalischen Werte sind gegeben mit aphys = 79, bphys

=

5. Der exakte Wert von Cphys wäre 79/5

=

15,8.

Die Umrechnungsformeln sind gegeben mit aimpl (aphys)

=

K la . aphys + KOa

=

1 . aphys + 0

(5.39)

bimpl (bphys)

=

K 1b . bphys + KOb

=

1 . bphys + 0

(5.40)

Cimpl (Cphys)

=

K I c . Cphys + Koc

=

1 . Cphys + 0

(5.41 )

5 Methoden und Werkzeuge in der Entwicklung

264 Der Wertebereich ist gegeben mit aimpl min

=

0 und aimpl max = 255

bimpl min

=

2 und bimpl max = 10

Für die Berechnung von Cphys = aphyslbphys wird folgender Algorithmus gewählt: •

Schritt I : aimpl = aimpl «

•

Schiebeoperation um 8 Stellen für aimpJ, um den vollen 16-Bit-Wertebereich zu nutzen. 8 = aimplo 2 8

Für aphys = 79 erhält man aimpl = 79

°

2 8 = 20 224

Schritt 2: Durchführen der eigentlichen Ganzzahldivision temp = aimpl / bimpl Dies entspricht 15,7968 ...

Für bphys = 5 erhält man temp = 20 224 /5 = 4 044 ° 28

Gegenüber der Integerdivision 79/5 = 15 kann durch die Umskalierung in der Größe temp eine wesentlich höhere Genauigkeit erreicht werden. •

Schritt 3: Rückskalierung des Ergebnisses um 8 Stellen Die Größe temp muss im weiteren Verlauf des Algorithmus wieder auf die Skalierung von Citnpl gebracht werden : Cimpl

=

temp » 8

Dabei entsteht ein relativer Fehler und Genauigkeit geht verloren . Dieser Schritt sollte deshalb möglichst spät im Algorithmus durchgeführt werden . Weitere Rechenschritte sollten die genauere Zwischengröße temp verwenden.

Hinweise für Additionen, Subtraktionen und Multiplikationen •

Für Additionen, Subtraktionen und Multiplikationen wird die Genauigkeit durch Überlaufund Unterlaufbehandlungen begrenzt.

•

Es können verschiedene Strategien zur Über- und Unterlaufbehandlung gew ählt werden . Möglich sind beispielsweise Umskalierung, Begrenzung, Erweiterung des Wertebereichs durch Typkonvertierung oder Zulassen des Überlaufs/Unterlaufs mit oder ohne Erkennung und Reaktion im Algorithmus.

•

Bei einer Umskalierung des Wertebereichs nimmt die relative Genauigkeit über den ganzen Wertebereich ab, auch wenn kein Über- oder Unterlauf auftritt.

•

Bei einer Begrenzung des Wertebereichs nimmt die relative Genauigkeit nur im Falle des Auftretens einer Über- oder Unterlaufsituation ab.

•

Über die Umrechnungsbeziehung von physikalischen Signalen in Implementierungsgrößen kann der Offset so eingestellt werden , dass die Berechnungen auf der Implementierungsebene überwiegend " in der Mitte" des gewählten Wertebereichs stattfinden. Dies ermöglicht auch die prozessorinterne Darstellung mit geringerer Wortl änge . Dieser Vorteil schlägt sich besonders bei großen Datenstrukturen, wie offsetbehafteten Kennlinien und Kennfeldern, in geringerem Speicherbedarf nieder. Offsets führen u. U. aber zu zusätzlichen Umrechnungsoperationen bei der Verknüpfung verschiedener Signale. Von Kennlinien und Kennfeldern und einigen anderen Ausnahmen abgesehen, empfiehlt es sich daher meist , Offsets in Umrechnungsformeln möglichst zu vermeiden .

5.4 Design und Implementierung von Software-Funktionen •

265

Multiplikationen und Divisionen mit Werten aus der Menge {2 1, 2 2, ... , 2 n} können effektiv durch Schiebeoperationen ausgeführt werden . Rechts-Schiebeoperationen sollten bei vorzeichenbehafteten Größen unter Umständen vermieden werden . Stattdessen sollte mit der normalen Division gearbeitet werden.

Hinweise zur Fehlerfortpflanzung •

Selbst durch exakt ausgeführte Operationen, wie Additionen, Subtraktionen oder Multiplikationen , kann ein relativer Fehler der Eingangsgrößen rasch verstärkt werden .

•

In diesem Zusammenhang sollten insbesondere auch Begrenzungen, die etwa durch die Argumentübergabe bei Unterprogrammaufrufen implizit wirksam werden können , beachtet und ihr Einfluss auf Zwischenergebnisse abgeschätzt werden.

5.4.2.10 Einige Hinweise zur Implementierung in Gleitpunktarithmetik Auch bei der Implementierung in Gleitpunktarithmetik muss beachtet werden , dass die Menge Ader Maschinenzahlen für Gleitpunktzahlen endlich ist. Dies rührt unvermeidlich zu Rundungsfehlern bei den arithmetischen Operationen. Genauso wie für die Festpunktarithmetik gelten auch hier die Assoziativ- und Distributivgesetze nicht, da die exakten arithmetischen Operationen durch Gleitpunktoperationen approximiert werden . Obwohl nicht alle numerischen Probleme durch Gleitpunktarithmetik gelöst werden , bietet der größere numerische Wertebereich doch den Vorteil , dass die Einflüsse von numerischen Rundungsfehlern, Über- und Unterläufen wesentlich geringer sind und häufig vernachlässigt werden können . Die Skalierung von physikalischen Größen - eine häufige Fehlerquelle bei der Implementierung in Integerarithmetik - ist nicht notwendig. Allerdings führt die höhere numerische Genauigkeit auch zu einer größeren Wortlänge und damit zu einem erhöhten Speicher- und Laufzeitbedarf. So kann etwa die Sicherung und Wiederherstellung von Gleitpunktdaten bei präemptiver Zuteilungsstrategie in Echtzeitbetriebssystemen zu beträchtlichen Laufzeiteinflüssen führen . Für viele Anwendungen wird daher eine Lösung gewählt, bei der Festpunkt- und Gleitpunktarithmetik kombiniert werden . Das Bewusstsein und Verständnis der allgemeinen numerischen Methoden bleibt deshalb essentiell wichtig, um Probleme zu lösen wie [87] : •

Konvertierung von Festpunktzahlen in Gleitpunktzahlen und umgekehrt

•

Umgang mit " Division-durch-N ull"-Bedingungen

•

Fortpflanzung von Approximationsfehlern, die zum Beispiel durch Filter- und Integrationsalgorithmen entstehen können

•

Fortpflanzung von Rundungsfehlern

Hinweise für Vergleiche und Divisionen •

Sind Vergleiche von Festpunktzahlen unkritisch, so sollten Vergleiche zweier Gleitpunktzahlen a und b auf Gleichheit in vielen Fällen vermieden werden . Stattdessen wird empfohlen, die Differenz delta = [a - b] gegenüber einer Schranke eps zu vergleichen, wobei auch die relative Genauigkeit berücksichtigt werden muss, etwa in der Form delta < [a • eps] oder delta < [b • eps].

•

Divisionen durch 0 müssen durch Bedingungen oder Abfragen ausgeschlossen werden .

266

5 Methoden und Werkzeuge in der Entwicklung

5.4.2.11 Modellierun gs- und Implementierungsrichtlinien Die Optimierungen für Seriensteuergeräte hängen zum einen von der Anwendung, zum anderen von der Hardware-Plattform ab. Deshalb ist eine enge Zusammenarbeit zwischen dem für die modellbasierte, physikalische Spezifikation verantwortlichen Funktionsentwickler und dem für das Design und die Implementierung zuständigen Software-Entwickler notwendig. Eine wichtige Voraussetzung für zielführende Optimierungsmaßnahmen sind Modeliierungsund Implementierungsrichtlinien. Das Funktionsmodell muss die explizite Spezifikation aller software-relevanten Informationen ermöglichen, ohne dass das physikalische Verständnis unnötig erschwert wird. Ein Beispiel für Modellierrichtlinien sind die MSR-Standards [78], ein Beispiel für Implementierungsrichtlinien sind die MISRA-Richtlinien [88]. Durch eine Trennung von Spezifikation und Design wird auch eine später eventuell notwendige Portierung auf neue Hardware-Plattformen ermöglicht. Dazu müssen dann im Idealfall nur die hardware-spezifischen Design-Entscheidungen angepasst werden . Die Konsistenz von Spezifikation und Design stellt ein grundsätzliches Problem bei der Funktionsentwicklung dar. Verschiedene Werkzeuge zur Daten- und VerhaltensmodelIierung unterstützen diese Entwurfsschritte. Werkzeuge ermöglichen auch die Festlegung von Richtl inien in Form von Basisblockbibliotheken, Skalierungsempfehlungen und Namensbezeichnungen für Variablen , sowie von Formelbibliotheken, Ablageschemata und Interpolationsroutinen für Kennlinien und Kennfelder.

5.4.3 Design und Implementierung der Software-Architektur Auch die Software-Architektur muss unter Berücksichtigung der Merkmale des ausgewählten Mikrocontrollers und des Steuergeräts konkretisiert werden , so dass alle Anforderungen, die an das Seriensteuergerät gestellt werden , berücksichtigt werden . Die Architektur orientiert sich dabei zunehmend an AUTOSAR [3].

5.4.3.1 Basis- und Anwendungs-Software Die Unterscheidung zwischen zwei Software-Schichten, der Basis- und der AnwendungsSoftware, ist in AUTOSAR definiert. Bei der Spezifikation in Abschnitt 5.3 wurde eine Architektur für die Software-Funktionen festgelegt. Die dort spezifizierten Software-Komponenten, die zur Darstellung einer Software-Funktion notwendig sind, können in der Design-Phase als Komponenten der Anwendungs-Software in die in Kapitell und 2 eingeführte SoftwareArchitektur integriert werden . Bild 5-66 zeigt beispielhaft einen Architekturentwurf, bei dem die Software-Funktionen durch Module realisiert wurden und über die AUTOSAR RTE untereinander oder mit Software-Komponenten auf anderen Steuergeräten kommunizieren . Für die Module wurde die in Bild 5-24 eingeführte Darstellung verwendet. In den folgenden Abschnitten werden Methoden zur Implementierung und Konfiguration von Software-Komponenten behandelt - insbesondere solche Methoden, die durch Werkzeuge automatisiert unterstützt werden können . Die dadurch mögliche Gewährleistung der Übereinstimmung zwischen Spezifikation und Implementierung einer Software-Komponente trägt entscheidend zu einer Verbesserung der Software-Qualität bei.

5.4 Design und Implementierung von Software- Funktionen

""

I

Funktion f j :'.Iud u l j

,.,

""""

I I

Funktion f 1 :'.l ud ul I

267

I

Funktion f 2 :'.lodu l 2

,•e

~

§

""

"t

~

~

0

•

-------,, ---Jl-------------Jl------ ----- --Jl----------Jl-------J:--- ---

I

AlJTOSAR Runtime Envi ronme nt ( RTE)

------- ---'\-------------9'----------------------------------1'-,,---AUTOSAR COM

Diagnosric Comrnunication

h I~===='-'===E=< .P Manager

CAN Stare

Generio

Fun ktion f :'.Iodu l ~

~ . -

~

Nctw ork

M'l11t Manager 1~='f~ 11 CAN

I' DU Routcr

Nctwork Mgm t

( CAN Interface

I

l

I

CANDrivcr

,

,

00

i

u Bild 5-66: Software-A rc hitektu r mit Verwend ung von standard isie rten Software- Komponenten

5.-1.3.2 Standardisierung von Soft ware-Komponenten der Basis-Soft ware Die Standardisierung der Basis-Software bietet viele Vorteile. Die Standardisierung ist möglich, da die Basis-Software-Komponenten aus Sicht eines Fahrzeugherstellers keine direkte Wettbewerbsrelevanz besitzen . Die Standardisierung erleichtert die Integration der von verschiedenen Lieferanten entwickelten Steuergeräte im Fahrzeug. Die Qualitätssicherung für diese Software-Komponent en kann zentral durc hgeführt werden. Bereits standa rdisierte Software-Komponenten sind beispielsweise •

Betriebssysteme nach AUTOSAR [3] und OSEK [ 17]

• •

Kommunikation und Netzwerkmanagement für CAN, LIN und FlexRay nach AUTOSAR (3] EEPROM/Flash Speichermanagement nach A UTOSAR [3]

•

Diagnoseprotokolle nach ISO [24, 25J und Fehlerspeichermanagement nach AUTOSAR [3]

•

tnrerpolauons-Cx c -Krypto- und Watchdogroutinen nach AUTOSAR [3]

•

Input Capture Unit- (ICU), PWM-, Analog Digital Converter- (ADC ), Digital Input Output- (0 10 ), General Purpose Timer (GPT) Treiber nach AUTOSAR [3]

Die Anpassung dieser Software-Komponenten an verschiedene Anwendungen erfolgt durch Konfigurationsparameter.

5 Methoden und Werkzeuge in der Entwicklung

268

Viele Vorteile bietet auch die Standardisierung der Flash-Programmierung einschließlich der notwendigen Software-Komponenten und der erford erlichen Sicherheitsmechanismen zum Schut z vor unbefugtem Zugriff. In diesem Bereich werden erhebliche Anstrengungen zur Standardisierung unternommen . Nach Einführung eines entsprechenden Konzepts wären alle Software-Komponenten, die zur Unterstützung der Offboard-Schnittstellen eines Seriensteuerger äts für • • •

Diagnose Software-Parametrierung Software-Update

in der Produktions- und Servicephase notwendig sind, standardisiert. Während der Entwicklung müssen oft weitere Schnittstellen unterstützt werden , etwa für das Messen und Kalibrieren oder auch für Bypass-Anwendungen. Protokolle für Mess- und Kalibrieranwendungen sind durch ASAM [18] standardisiert, beispielsweise das CAN Calibration Protocol , kurz CCP oder das Extended Calibration Protocol , kurz XCP . Die dafür notwendigen Software-Komponenten müssen nur während der Entwicklungsphase in die Software-Architektur integriert werden. Sie entfallen wieder in der Produktions- und Servicephase. Auch Komponenten der Anwendungs-Software bieten Potential zur Standardisierung, etwa die Elemente einer steuerungs- und regelungstechnischen System-Bibliothek, wie sie im Rahmen von MSR-MEGMA [78] festgelegt sind .

5.4.3.3 Konfiguration von standardisierten Software-Komponenten Über Konfigurationsparameter können standardisierte Software-Komponenten an eine spezifische Anwendung angepasst werden. Dieser Konfigurationsschritt kann durch Konfigurationswerkzeuge automatisiert werden . Beispiele sind die Konfiguration des Echtzeitbetriebssystems, oder auch die Konfiguration der Kommunikations- und Diagnose-Software-Komponenten der Basis-Software. In Bild 5-67 ist die automatisierte Generierung der Konfiguration für die Software-Komponenten zur Kommunikation im Steuergerätenetzwerk dargestellt. Die Kommunikationsmatrix des Steuergerätenetzwerks wird dazu in einer zentralen Datenbank abgelegt. Editoren ermöglichen die Bearbeitung der kommunikationsrelevanten Parameter durch verschiedene Sichtweisen auf die Kommunikationsmatrix - wie die Signal sieht, die Nachrichtensicht, die Bussicht, die Teilnehmersicht oder auch die Funktionssicht. Export-Schnittstellen unterstützen verschiedene Austauschformate - etwa in Form von Beschreibungsformaten für Entwicklungs- oder Messwerkzeuge - zur Verteilung der Kommunikationsmatrix an die verschiedenen Entwicklungspartner. Über Import-Schnittstellen können Teilumfänge zusammengeführt und auf Konsistenz geprüft werden . Die automatisierte Übernahme der Daten in Lasten- und Ptlichtenhefte ist über eine Dokumentationsschnittstelle möglich .

Dadurch kann die Konsistenz zwischen Implementierung, Dokumentation und Beschreibungsformaten für alle relevanten Daten zur Beschreibung der Kommunikation im Steuergerätenetzwerk sichergestellt werden. Übertragungsfehler, etwa durch die manuelle Konfiguration von Software-Komponenten, können vermieden werden. Ähnliche Anforderungen bestehen im Bereich der Diagnosedaten (Bild 5-68) . Die zentrale Verwaltung der Diagnosedaten in einer Datenbank ermöglicht die automatisierte Konfiguration der Software-Komponenten für die Diagnose und gew ährleistet beispielsweise die Konsistenz zwischen Fehlerspeicherbeschreibung für den Diagnosetester, etwa im Format ASAM-

269

5.4 Design und Implementierung von Software-Funktionen

MCO 20 . und der Implementierung im Steuergerät. Eine weitere Aufgabe. die automatisiert werden kann. ist die Integration der Diagnosedaten verschiedener Steuergeräte zu einem Datenstand für das Fahrzeug und deren Prüfung auf Konsistenz. \l.'e rkz..:ug

Impo rt Misch e n Prüfe n

I~I ~

Daten bank

Edito re n fllr Spezifikation & Design der Kom munikationsmarrb, Gcncricnmg

EJ

Export

Genesie nmg

Konfig uratio n für Ko mmunikationsSoft ware- Komponen te

D

Expo rt- &

Import-Formate l. II A UTOS A R Do kumentatio n

~

nild 5-(.7: Auto matisierte Konfiguratio n der Komm unik ations schich t

Werkzeug Impo rt M ische n

Prüfen

I~I~ Editor en für Spezifikation & De sign der Diagnosedaten Generierun g

Dek la rationen & Deli -

nitioncn fl lr Diag noseSoft ware-Korn poncntc

ASA M-MC I>2D AUTOS A R Daten-

bank

Generlerung! Export Ge nerlerung

D

Duk w ncmation

fKonfiguratio n flir Diag noseSoftw are-Ko mpo nente

I~

Hihl S-6!~: Automat isierte Konfiguration der Diagnoseschicht und Gencricmng der Diagnosebeschreibung

270

5 Methoden und Werkzeuge in der Entwicklung

5.4.4 Design und Implementierung des Datenmodells In der Produktion und im Service von Fahrzeugen rühren länder- und kundenspezifische Ausstattungsoptionen zu einer Vielzahl von Fahrzeugvarianten, die beherrscht werden müssen . Diese Fahrzeugvarianten führen auch zu Software-Varianten für die Steuergeräte. Verfahren zur Reduzierung der in Produktion und Service benötigten Vielfalt der SteuergeräteHardware -Typen sind zur Beherrschung der Varianten notwendig. Verfahren , die durch eine Variantenbildung des Datenstandes möglich sind, werden in diesem Abschnitt dargestellt. •

Bei Verfahren , die in der Produktion eingesetzt werden, stellen die Anforderungen an die zeitliche Dauer zum Einstellen einer Programm - oder Datenstandsvariante eines Steuergeräts eine wichtige Randbedingung dar. Die maximal zulässige Zeitdauer wird durch die Taktzeit der Produktion vorgegeben. Die Verfahren können vor oder nach dem Einbau des Steuergeräts ins Fahrzeug eingesetzt werden .

•

Bei Verfahren, die im Service verwendet werden , verlangt die weltweite Ersatzteilelogistik nach einer möglichst geringen Anzah l verschiedener Steuergeräte-Hardware-Typen . Programm - und Datenvarianten können wesentlich kostengünstiger weltweit verteilt werden als Hardware -Komponenten. Ein Ausbau des Steuergeräts aus dem Fahrzeug im Service rührt zu hohen Kosten . Deshalb ist ein Konzept zum Einstellen, Ändern oder Laden von Programm - und Datenvarianten vorteilhaft, bei dem ein Steuergeräteaustausch oder -ausbau nicht notwendig ist.

•

Auch die Fahrzeugbenutzer, etwa der Fahrer oder die weiteren Insassen, möchten selbst zunehmend ein persönliches Profil für viele Software-Funktionen über eine BenutzerschnittsteIle vorgeben und abspeichern. Dazu gehören beispielsweise Einstellungen von Sitz-, Lenkrad - und Spiegelposition, sowie Einstellungen der Radiosender, der Heizung und Klimaan lage. Diese personenbezogenen Parameter können beispielsweise über fahrer spezifische Kennungen, die im Schlüssel abgelegt werden , verwaltet werden .

Alle diese Anforderungen müssen beim Design und der Implementierung von Daten berücksichtigt werden . In den Abschnitten 5.4.4 .2 und 5.4.4.3 werden zwei verschiedene technische Verfahren zur Einstellung von Datenvarianten ausführlicher dargestellt: •

die Einstellung durch Flash-Programmierung und

•

die Einstellung über Konfigurationsparameter.

5.4.4.1 Fest1egung des Speichersegments Neben der Art der Darstellung im Prozessor muss für jedes Datum festgelegt werden , in weIchem Speichersegment des Mikrocontrollers es abgelegt werden soll. Es muss also definiert werden , ob eine Größe im flüchtigen Schreib- /Lesespeicher - beispielsweise im RAM - , im nichtflüchtigen Lesespeicher - etwa im ROM, PROM, EPROM oder Flash - , oder in einem nichtflüchtigen Schreib -/Lesespeicher - wie dem EEPROM oder dem batteriegepufferten RAM - gespeichert werden soll.

5.4 Design und Implementi erun g von Software- Funktionen

271

5..1, .1. 2 Einstellung von Datenvaria nten durch Flas h-Programmierung Dieses Verfahren kann bei Steuerge räte n mit Flash-Technologie eingesetzt werden , Hierzu kann der komp lette Flash-Bereich - mit dem Progra mm- und dem variantenspez ifisc hen Datenstand - ode r nur ein Teilb ereich de s Flash-Speichers - etwa nur der Datenstand - beispielsweise am Ende der Fahrz eugprodu ktion programm iert werden. Davon ist die Bezeic hnung Bandendeprogramm ierun g (e ngl. End of Line Progra mming) abgeleitet. Dieses Ve rfahren wird zunehm end auch fiir So ftwa re-Updates für Fahrze uge im Service eingesetzt. Im Se rvice erfolgt die Programmierung zunehmend über die zentrale Diagnoseschn ittstelle des Fa hrze ugs. so dass das Steuergerät dazu nicht aus dem Fahrze ug ausgebaut werden muss. Auf das Verfah ren zur Flash- Programmierung im Service wird in Abschnitt 6.3 ausfü hrIich einge gange n. Zur Verkürzung der notwendige n Ze itdaue r für die Flash-Programm ierung werden Progra mmund Datenstand hä ufig getre nnt programm ie rt. ln der Produktion kann dadurch beispielsweise der variantenunabhäng ige Progra mmstand bereits be i der Steu ergerä teherstellung program miert we rden und nur de r fahrzeugspezifische. variantenabhä ngige Datenstand wird a m Ende der Fahrzeug prod uktion programmiert. Am Beispiel einer Kenn linie ist in Bild 5-69 das Variant enm ana gement durch Flash-Programmienmg dargestellt , va riante 1 Variante 2 y ,

x

_J.

L-__ J,

._~::\;!

I

, ,---

--.;J ",--"'--" . , ..., ,

_l.__ ..l

_.I •

_~_ _

y

-

- --

-+ ~ ..._-- ... I

Variante 3

,

,

x J-1a.\h

Bild 5-(,9: Darcnstandsprogrannnicrung am Beispiel einer Kennlinie

5..1..1.3 Einstellu ng mn Datenvarianten durch Korf tgurationsparamet er Eine zweite Lösung ist die parall ele Ab lage unterschiedlicher Datenva riante n im nichtflüc htigen Festwert speic her des Steue rgeräts. Durch eine Para metrierung am Bandende wird nur eine der Datenvarianten über ein en dafür vorgesehenen Software-Sc halter oder Software- Paramete r ausgew ä hlt. Diese r Softwa re-Pa rameter wird beisp ielsweise im EEPROr-.-t a bge legt. Da dadurch aus mehreren möglic hen Versionen von Datenständen eine Kon figuration nach Bild 3- 12 erst a m Bandeende festgelegt wird, wird dieses Verfahren auch als Bandendekonfiguration (engl. End of Line Configuration) bezeichnet . Alternativ kann diese Kon figu ration auch erst beim Sta rten des Fahr zeugs festgele gt werden . In diesem Fall we rden die Kon figurationsinfonn ationen für alle Steuergeräte des Fahrze ugs mit dem beschriebenen Verfahren in einem zentralen Ste uerge rät abgele gt. Dieses Steuergerät

272

5 Methoden und Werkzeuge in der Entwicklung

sendet diese Information - beispielsweise nach Einschalten der Zündung - über eine Nachricht an alle betroffenen Teilnehmer im Netzwerk, die daraufhin die entsprechende Konfiguration auswählen. Auch dieses Verfahren wird für die Software-Konfig uration für Fahrzeuge im Feld über die zentrale Fahrzeugdiagnoseschnittstelle verwendet. Es eignet sich auch zur Parametrierung von Funktionen durch den Benutzer selbst. Bild 5-70 zeigt das Konfigurationsmanagement durch Software-Parameter am Beispiel einer Kennlinie. Auch Kombinationen der verschiedenen Verfahren sind de nkbar.

y

Variante I

___ ___ __J ___ __ -L __ ~

I

~

I

I

~

I

I

I

~.

I

1---+--+--4~-~--'-~--~-~.I , I I ' I ; - -. ---t----t-- , --- -t . 1---+-

x

~

~

I _ _ --1I _ __.. I __ -1, _ _ .... I -_ ..• ___+I I I I I •

y ___

E...x

Variante 2

, , , , , ,

~

___L __ J ___ L __ -L __ J .

l- -- + - - -~ - - ~ -- - t -- -~-~~ ·

x

,2

i- -- + ....l_...;. _ ~--:+ - - ~ . :-- -),~--l_--~-, , ~-----:---~, , ,

~

~

Kontigurationsparatnetcr

, , , , ,

,

y

2

---l-.

; - - - .. ---!--- .. - - - .. ---I--- ....

,

~ EE PROJI

x

Variante 3 ~;~ + - --r- -i -- - t -- -r -- i-

"--.,

i--"'-+-j---I--+--j· , I •. • • I I I .~

~

~ . ~. . .

i - -- T---r- - ~-- r ---r--l '

:---r---i--1- ~~-: -r- - - 1 ' , , , , , ,

• ___ " ___!-__ -l _ _ .. __ .•._ _ ... .

x RO.»

1Ji1t! S-70: Datenstandspara mctricrung a m Beispiel ei ner Kennlinie

5.-1.-1. -1 Generierung von Datenstrukturen und Beschreibungsdateien Durch die zentrale Verwaltung und die automatisierte Gener ierung VOll Datenstrukturen und Beschreibungsdateien für die Mess- und Kalibrierdaten kann ein weiterer Entwick lungsschritt automatisiert werden (Bild 5-7 1). In einer Datenbank werden die Mcss- und Kalibrierdaten eines Mikrocontrollers zentral abgelegt. Dabei werden die physikalische Spezifikation. die Design- und Implementierun gsentscheidungen für alle Daten. sowie die Festlegung der Abbildungsvorsc hrift. etwa durch Um-

273

5.4 Design und Implementi erun g vo n So ftware- Funkt ionen

rechnun gsformeln. zusammen verw a ltet. A us der Datenbank kö nnen dann einerse its Datenstrukturen für eine Entwicklungsu mgeb ung. beisp ie lsweise in der Sprache C. gene rie rt werde n. And ere rseits ste hen nac h Einlesen der Adressinfonu ation auch alle Informationen zur Verfügung. um ei ne Beschrei bungsdatei im Fo rmat ASA M-MCD 2MC zu erzeuge n. d ie von Mess-, Kalib rier- und Diagnose werkzeugen ve rwende t w ird. Dadurc h wird d ie Ko nsisten z zwischen Daten beschreibung für Mess- und Kalib rierwer kzeuge und der Implementieru ng der Daten ge währle istet.

Werkzeug Import Mischt: Prüfen

~

Ed itoren fü r Spezifikation & Design der Daten

ASAM-MCD 2MC AUlOSAR Datenban k

Generiorung Export Ocnerte-

Gcncrieruna

r:~ Import

D

Dokumc nratio n

Speiche radressen

Deklarationen & Dd i nitionen Illr Daten Bild 5-7 1: Automatisierte Gcucricrung \'011 Datenstrukturen und der Dutcubcschrcibung 189]

5A .5 Design und Im plemen tierun g des Verha lte nsmode lls Die Konsiste nz zw ischen Spezifikation. Doku mentat ion und der vo llstä nd ige n Im plement ie rung vo n So ftware- Komponente n ka nn du rch den Einsatz von Codegenerierungs werkze uge n gew ährleis tet werd en ( Bild 5-72 ). Die modellbasierte Spezifikation. d ie auch für die Sim ulation oder das Rapid- Pro totyp ing verwe ndet wird . wird a ls Basis für d ie au tomatisierte Codegenerier ung genutzt. Daz u müssen für d ie auf der phys ikalischen Ebene spezifiz ierten Daten und für d ie Algorithmen d ie not wendigen Desig nentsche idungen get roffe n werden. Für d ie Daten si nd die Festlege nge n. wie in Bild 5-7 1 da rgestel lt, notwendig. Fü r d ie Algo rithmen ist die Fest reg ung der Da rste llungsform für A rgu ment e und Rückgabewerte. so wie d ie Z uord nung zu d en Speicherseg mente n des Ste uergeräts erfo rderlich. Bei Impleme nt ieru ng in Intege rarithmetik müssen weitere Fest legu ngen, etwa bezügli c h der Strateg ie zur Behand lung von Rundu ngsfehlern. Über- und Unte rlaufsituationen wie in Abschnitt 5.4.2 darge stellt. getroffe n werd en. Diese Definitionen werden durch e in Design wer kzeu g unterstützt.

274

5 Method en und Werkzeuge in der Entwicklung

Mit diesen Informationen ist die automatisierte Generierun g von vollstä ndigen SoftwareKomp onenten, z. B. in Quellcode. möglich. die dann in einer kon ventionellen So ftware-Entwick lungsumgebun g weiterverwendet und zu einem Programm- und Datenstand des Mikrocontrollers integr iert werden können. Diese Vergehensweise wird daher auch als .,Methode zusätzlicher Programmierer" bezeichnet (Bild 5-72). Kann zusätzlich auch die Software-Architektur beschrieben werden und können die Komponenten der Basis-Software integ riert und konfiguriert werden. so ist mit Integration eines Compiler Tool Sets für de n jeweiligen Mikrocontroll er auch die Generierung eines vollständigen Programm- und Datenstandes möglich (Bild 5-72). Diese v er gehensweise wird deshalb als •.Methode lntegratic nsplattform" bezeichnet.

Modellierw erkzeu Spezifikationswe rkzeug

Designwerkzeug

Modell (Spezifikation & Design)

Modell-Compiler

I I I I I I I I I I I I I

Konfigurationswerkze uge

Codegenerierungs& Integrationswerkzeug

Plattform-

SoftwareKomponente ~

Quellcode-

1+1Komponente

I ..Methode zusätzlicher Programmierer"

~~I I I I I

Compiler-Tcc l-Set

Programmstand

-------------------- ..Methode Datenstand

I ntegrationsplan form''

HiItJ !i-72: Automatis ierte Gcncncrung von Softwarc-Komponcmcn lind des Programm- lind Datenstands (74]

Beispie l: Design und Implementierung der Klasse ..lntegrator'' Die in Bild 5-27 spez ifizierte Klasse ..Integrator" soll implementiert werden. Dazu werden die folgenden Designentscheidungen für die Daten getroffen:

5.4 Design und Impl em entierung vo n Software- Funktion en Bezeichn ung X

Darstellung

Formel Ximpl(Xphys) = Klo Xphys

E/computeO in/computei)

uint8 uintl 6

Kj =

I K, = 256

uintl6

K, = 256 K, = 256

K/compute O MN/computc O MX/comp uteO return/outt)

uint32 uint32 uintl6

l/iniu)

uint8

IV/initO memory

uintl6 uint32

dT

uintl6

K, = 256 K. = 256 Kl = I K, = 256 K, = 256 x, = 1024

Wertebere ich auf der physikalische n Ebene X,mpl true/false 0 ... 100 0 ... 255.996

275 Wertebereic h auf der Implementierungsebene Xphys 1/0 0 ... 25 600 0 ... 65 535

0 ... 16 777215 .99 0 ... 16777 215.99

o... 4 294 967 295 o... 4 294 967 295

0 ... 255.996 true/false

0 ... 65 535 1/0

0 ... 100 0 ... 16777215 .99

o... 4 294 967 295

0 ... 63.999

0 ... 65535

0 ... 25600

Bild 5-73: Designentscheidungen für die Daten und Schnittstellen der Klasse "Integrator" Eine mögli che Impl em ent ierung in der Sprache C der Methode "com puteO" in Festpunktarithmetik ist in Bild 5-74 dargestell t. Für die Algo rithme n werden dabei zusätz liche Designentscheidungen berücksichtigt, etwa in Be zug auf die Behandlung vo n Überund Unterlaufsituatio ne n . /* Variablen */ extern uint32 memory; extern uint16 dT; /* Methode compute() */ void compute (uint16 in, uint16 K, uint32 MN, uint32 MX, uint8 E)

uint32 t1uint32, t2uint32, t3uint32; if E { /* Überlaufbehandlung 15 Bits */ t1uint32 = MX » 1; /* min=O, max=2147483647, impl=128phys */ t2uint32 = « (uint32) (in» 5) *( ( (uint32) K * dT) » 10) ) » 4) + (memory » 1); /* min=O, max=2357192447, impl=128phys+0 */ t3uint32 = (uint32)«t2uint32 MN) ? t3uint32 : MN; /* min=O, max=4 294967295, impl=256phys+0 */ }

Bild 5-74: Implementierung der Methode "computeO" der Klasse " Integrator" als Funktion in der Sprache C

5 Method en und Werkzeuge in der Entwick lung

276

5.5 Integrati on und Tes t von Softwa re-F unktionen In diesem Abschnitt werden Verifikations- und Validierungsmethoden behandelt, die in der lntegration s- und Testphase für Software- Funktionen eingesetzt werden . Wegen der unternehmensübergre ifenden Integrations- und Testschritte in der Automobil elektronikent wick lung spielen Verfahren. bei dene n nicht vorhandene reale Komponenten durch Modcl lierung und Simulation virtue ll nachgebildet werden. eine wicht ige Rolle. Der Aufba u dieses Abschnitts orientiert sich an den folgenden Integrations- und Festurngebungen: •

Simulationsumgebungen

•

Laborfa hrzeuge und Prüfständ e

•

Experimentier-. Prototyp- und Serie nfahrzeuge

Die Synchronisation der versch iedenen Verifikations- und Validierungsschritte zwisc hen allen Entwicklungspartnern und Entwicklungsumgebungen, etwa die Abstimmung der Kompon entenmodelle und Testfalle. muss bereits bei der Proj ektplanung berücksichtigt werde n.

Start

Ziel

Software Aktua .,,'-"-"~ torcn

Entwicklungsfortschritt Legende: ~ Systemmode ll Bild

~-7!i :

( I ] Svstcm-

e!:] rcalisicrung

D

Umgebungsmode ll

D

Umgeb ungsrcafisicrung

Ausgangs- und Zie lsituation für die Integration und den Test von SOt1waTC und Systemen

Einige Validierun gsverfahren. wie Rapid-Prot otyping für spezifizierte Software-Funktionen, die bereits in der Spezifikationsphase eingesetzt werden können. wurden in Abschnitt 5.3 behandelt. Diese Verfahren können mit den in diesem Absch nitt beschriebenen Verfahre n kom binie rt werd en. Hier stehen Verfahren im Vordergrund. mit denen implementierte SoftwareFunktionen frühzeitig in einer teilweise virtuellen, teilw eise realen Umgebung verifiziert und

5.5 Integration und Test von So ftware-Funktionen

277

va lid iert werden kö nnen. Dabei werde n versc hied ene ty pische Zwischensc hritte herau sgeg riffen. Ausgan gs- und Zielsituation sind in Bild 5-75 dargestellt. Ein Überblic k über d ie versc hiede ne n Zwischensch ritte bei der Integratio n zei gt Bild 5-76. Die Model le de r log ischen Systemar chitekt ur kö nnen als Grund lage für d ie Nachbild ung nicht vo rhand ener Syste mkom pone nte n die nen . Anhand beispielhaft a usgewählter A usschnitte aus Bild 5-76 werd en in den folg ende n Absc hnitten verbre itete lnteg rations-. Ve rifikatio ns- und Validi erun gsmethoden dargestel lt.

Simulierter Bus

Kild S-76: Zwischcnschriue bei der Integration lind beim Test von Sott ware lind Systemen

Der frühestmög liche Va lidierun gssch ritt ist die Sim ulatio n des Modells e iner Ste ueru ngs- und Regelungsfunktio n z usam men mit e inem Modell des zu ste uernden oder zu rege lnde n Systems. Im Sim ulationsmodel l können die Kom ponenten So llwe rtge ber. Steueru ng/ Regler ode r Überwachu ng, Aktnatoren . Strec ke und Sensoren nachgebildet wer den. Für vie le Fahrzeugfunktionen inte ress ie ren bei der S imulation auch der Einflu ss des Fa hrers und der Umw e lt auf das Systemver halte n. Fah rer und Umwe lt kö nnen da zu a ls we itere Ko mponenten berücksic htigt werd en, w ie in Bild 5-44 darg estellt. Da a lle Ko mponenten d urch virtuelle Mode lle re präsentiert werden, werden ke ine Ec htzeita nforderungen an geeignete Mo dellb ildungs- ode r Sim ulat ionsve rfahren ges tellt. An d ieser Stelle so ll nicht we iter auf d ie Model lbildu ng für Fa hrzeugkomponente n e ingega ngen werden. Eine ausführliche Darste llung findet sich z. B. in P5 ].

5.5.1 S o ft wa re-in- t he- L oo p-S im u la t io nc n Werden rea lisie rte So ftware- Kom ponenten in einer s imulierten Umge bung ausge führt, so wird d iese Ve rgehensweise auc h als So ftware-in -the- Loop -Simulation, kur z S iL-Simulation, bezeic hnet. Mit Blick auf e ine Reg elungsfunktion ist d iese Beze ich nung sc hlüssig. Eine Soft wareFunkt ion , durch d ie beispie lsweise eine Regel ungsfunktio n in der Anwend ungs-So ftwa re rea lis iert wird. kann als e ine Ko mpone nte im Regelkreis Iengl. Loo p) modelliert und ausge führt werd en, wie in Bild 5-77 beisp ielhaft dargestellt . Diese Vorgehenswe ise ist j edoch a uch für eine ga nze Reihe we itere r Anwe ndun gsfa lle vortei lhaft, wo kein Regelk re is besteht . So könn en zum Beispiel a uch So ftware-Komponente n du rch d ie Ste ueru ngs. oder Übe rwachungsfunktione n realisiert we rde n, oder So ftwa re-Kompo nenten der Bas is-So ftware, etwa d ie Kom munikatio nssc hicht. auf d iese Art und We ise verifiz iert und valid iert werd en.

278

5 Methoden und Werkzeuge in der Entwick lung

Gegenüber Bild 5-44 ändert sich in diese m Fall der Aufb au des Simulationsmodel ls nicht wesentlic h. Jedoch müssen die M odellkomponenten viel konkreter festgelegt werden . So muss die Modellbildung für das Steuergerät so weit konkretisiert werde n. dass die Analog-DigitalWandl ung und die Digital-Analog-Wandlung der Sig nale. sowie das .Echtze itverhalten" möglichst genau berücksichtigt werden. Erst dann können. wie in Bild 5· 77 dargestellt. realisierte Softwa re- Kompo nenten in diese Simulationsumgebung integriert und ausgeführt werden. Die implementierte Softwar e- Komponente als Prüfling w ird dann in einer virtuellen Umgeb ung auf einer Entwicklungs- und Simulationsplattform . z. B. au f einem Pe, ausge führt. Echtzeitanforderunge n an die Ausführung der Simulation werden dabei nicht gestellt. Mit Software-in-the-Loop-Sim ulationen können eine ganze Reihe dynamischer Software-Tests frühzeitig ohne reales Steuergerät du rchgeführt werden. beispielsweise Komponententests mit Code-A bdeckungsanalyse n (eng!. Code Coverage Ana lysis).

- - ------------------- - -------------Umwelt

Fahrer •

j

w-

Sollwertge bcr ~

~~ ~

t

W

4

Ste uerung/ Realer Übc m:ac hun

,.

r

,f+

z.1

~

Aktnatorun

Strecke

Ä

Sensore n

~

___ _ _ __ _ _ _ _ _ _ _ _ _ _ _ __ __ _ _ __ __ _ _ _

"

Ste ue rg e r ät _' I i li. fl~ o n t rn l l c r

-

W

"

.;;.

w"

Soft'" a re

A/D· Wandlung ~

N DWandl ung

~

I',

~!

11

Prüffinge

Bih.l 5· 77: Soft.... are-in-the-Loop-Simulution

DIA· Wandlu ng

-+

~?= So ftwa re-Kom pone nte zur Bcrech nung einer Ste uerung sund Regelu ngsfunktion

I'

5.5 Integration und Test von Softwa re-Funktionen

279

5.5.2 Laborfahrzeuge und Prüfständ e Eine ganze Klasse von Methoden und Werkzeugen. die zur Verifikat ion und Validierung eingesetzt werde n. sobald Hardware und Software eines Steuergeräts zur Verfügung stehen. werden unter den Bezeichnungen Laborfahrzeuge und Prüfstände zusammengefasst. Ziel kann dabei, wie in Bild 5-78 da rgestellt. der Betrieb eines realen Steuergeräts in einer te ilweise virtuellen. teilweise realen Umgebung sein. Gegenüber den oben da rgeste llten Simulationsverfahren. müssen deshalb Echtzeitanforderungen bei der Modellbildung und Ausfü hrung der Simulation der Umgebungskomponenten berücksichtigt werden. Steht die Verifikat ion und validierung von Regelungsfunktionen im Vorde rgrund. so kann das Steuergerät, w ie in Bild 5-78. als Komponente im Regelkreis betrachtet werde n. Aus diesem Grund wird diese Ve rgehensweise häufig auch als Hardware-in-the-Loo p-Simulation. kurz Hil.-Simularicn, bezeichnet. Ähnlich wie die SiL-Simulation ist diese v e rgehensweise jedoc h nicht auf Regelungsfunktion en beschränkt. sondern kann fllr eine ganze Reihe weite rer Anwendun gsgebiete eingesetzt werden. von denen nachfolgend einige beispielhaft herausgegriffen werden. Diese verschiedenen Ver fahren werden unter der Bezeichnun g Laborfahrzeuge zusammengefasst. Mit Blick auf die Software eines Steuergeräts stehen verschiede ne Aspekte im Vordergrund , beispielsweise die Verifikation und Validierung des Echtzeitverhahens, des Onboard - und Oflboard -Kommunikationsverhaltens im Netzwerk oder auch die Überprüfung der Steuerungs/Regelungs- und Überwachungsfunktionen.

5.5.2.1 PI'l!(lImgebuJlgjiir ein Steuergerät Das Laborfahrzeug kann als ein Software- und Hardware-Prüfstand für ein Steuergerät verwendet werden (Bild 5-78). Statische und dynamische Vorgänge der Umgebung des Steuergeräts werden in Echtzeit simuliert.

r-----------------------------------,

I I I

Fahr er

z

ll:.

I

Sollwert-

I

Sensoren

gc bc r Fahrzeu

I I I

Umwelt

B

Prüfling

Kilt! S--7H; Betrieb des Steuergeräts in einer virtuellen Umgehung 1901

5 Met hod en und Wer kzeu ge in de r Entwick lung

280

Die Eingangssignale des Ste uergeräts werden dur ch ein Umgebun gsmodel l nachgeb ildet und das Steuergerät damit stim uliert. Eingänge des Steuergeräts sind. wie in Bild 5-78 dargestellt , d ie S igna lve ktore n W und .ß. Der Ausgan gssignat vektor !! wird a ls Eingangsgröße für die Sim ulatio n der Umg ebun g im Labo rfahrzeu g verw endet. Bild 5-7 9 verdeutlicht d en Aufbau des Laborfahrze ugs L ABC AR. Das Umgeb ungsmodel l wird übersetzt und auf e inem Ec htzeitrechnersy ste m ausgeführt. Dort erfo lgt ne ben de r Ausftihru ng der Modelte d ie Au sga be de r Sig na lvektoren W und B des Ste uergeräts, so wie die Erfass ung des Sig nalve ktors j]. Über e ine n Bedienrechner könn en die Ex perimente inte raktiv vom Ben utzer oder automati siert ges te uert werde n. Modelländerun gen a n den Umgebun gskomp onenten werden dur ch Modelherwerk zeuge unterst ützt.

Laborfa hrzeug

Modeltierwcrkzcu g

Auto matisieru ng Model l der Umgeh ung

•

I

Modell-Compiler Echtzeitrechncr-

system

~ DownloadWerkzeug

I Au sr ührbare s Modell der Umgehung

Expcrimcmicrwer kzeug

~

~

FlashProgrammierwerkz · U\!

Echtzeitrechne rsystcm mit aus führbarem Mode ll der Umge hung

//

~

-:

~' ~ /

Billl 5-79: A ufbau lies Laborfahrzeugs I.AllCAR 1901

Beispiel : Prüfumge bung für die Ste uerungs- und Regelun gsfunktionen eines Steuergeräts Eine ty pisc he Anw endung ist die Prüfung des dynamischen Verha ltens der Ste ueru ngsund Regelungsfunktionen e ines Ste ue rge räts. Dies sc hließt nebe n den So ftwa reFunkt ionen in de r An wendungs-Software auch die Signalvera rbe itung in der BasisSoftware , sowie in de r Hard ware des Steuergeräts ein.

5.5 Integration und Test von Software-Funktionen

281

Die beliebige Vorgabe der Eingangssignale des Steuergeräts ermöglicht große Freiheitsgrade bei der Durchführung von Experimenten: •

Die Vorgabe der Umgebungsbedingungen für das Steuergerät, beispielsweise Temperatur, Luftdruck oder Luftfeuchtigkeit über die beliebige Stimulation der Eingangssignale ermöglicht die einfache Prüfung der Software-Funktionen unter extremen Bedingungen.

•

Extreme Fahrsituationen können ohne Gefährdung von Testfahrern oder Prototypenfahrzeugen nachgestellt werden .

•

Alterungs- und Ausfallsituationen an Sollwertgebern, Sensoren , Aktuatoren oder Kabelverbindungen können beliebig vorgegeben werden . Damit können z. B. adaptive Regelungsfunktionen durch Vorgabe von Alterungseffekten bei Signalen getestet werden .

•

Überwachungsfunktionen können durch Vorgabe unplausibler Signale systematisch geprüft werden .

•

Bauteiletoleranzen beispielsweise in Sollwertgebern, Sensoren und Aktuatoren können beliebig vorgegeben werden und ihre Auswirkungen auf die Robustheit von Steuerungs- und Regelungsfunktionen können überprüft werden .

•

Gegenüber Tests an Prüfständen oder im Fahrzeug können die Betriebspunkte ohne Einschränkungen beliebig vorgegeben werden, beispielsweise bei einem Motor im vollständigen Drehzahl-Last-Bereich.

Alle Prüfungen sind reproduzierbar und können automatisiert ausgeführt werden . Weitere Hardware-Komponenten, Aggregate oder Fahrzeuge sind dazu nicht notwendig. Bei einem Aufbau des Laborfahrzeugs wie in Bild 5-78 wird das Steuergerät als .Black Box" betrachtet. Das funktionale Verhalten des Steuergeräts kann nur anhand seiner Ein- und Ausgangssignale bewertet werden . Für einfache Steuergerätefunktionen reicht diese Vorgehensweise zwar aus, zur Prüfung komplexerer Funktionen ist aber die Integration eines Messverfahrens für steuergeräteinterne Zwischengrößen erforderlich.

5.5.2.2 Inbetriebnahme und Prüfumgebungfür Steuergerät, Sollwertgeber, Sensoren und Aktuatoren Das im letzten Abschnitt dargestellte Verfahren kann auch auf die Prüfung der Sollwertgeber, Sensoren und Aktuatoren eines Steuergeräts ausgeweitet werden . Dazu werden die realen Sollwertgeber, Sensoren und Aktuatoren in den " Regelkreis" eingebaut und gleichfalls als Prüflinge betrachtet (Bild 5-80) . Die Modellbildung im Laborfahrzeug beschränkt sich dann auf Modelle der Strecke , des Fahrers und der Umwelt. Modelle für die Sollwertgeber, Sensoren und Aktuatoren sind nicht mehr notwendig. Das Laborfahrzeug muss in diesem Fall die Ausgangsgrößen W * und X, sowie die Eingangsgrößen X unterstützen und der Hardware-Aufbau entsprechend angepasst werden . Auch Kombinationen zwischen simulierten und realen Aktuator- und Sensorkomponenten sind möglich .

282

5 Methoden und Werkzeuge in der Entwicklung

,,r---- ------- ----------- -----,,, ,, ,, z ... , ... : Fahrer

...

Umwelt

I}V·

Sollwen" her

~i Steue rung! ~

I"Ubcrwachuna Regle r

gc

\.R

Fuhrzeuu

W·

Aktunte ren

, I

\

\.

SOllw~rt~ - \ ~t~lI:g~r: gcbcr

X Sensoren

~~~ ~

a

f./ ~

r-,

,

n,

I Strecke I" 'I Sensoren rI J!r+

~

:

Aklu'llo ren k> I

-------- - -' Prüflinge

~4

..' '

Labor-

''';.

, ~~I "

fahrzeug

,l i

•'

w·

r+

r4

lnvtrumcr uicrung

Bild S-SO: Bet rieb (90 ]

VOll

Steuergerät. Sollwertgebern . Sensoren und Aktnatoren in virtueller Umgehung

Beispiel: Prüfumgebung für Steuerungs-/Regelungs- und Überwachungssysteme Gegenüber dem vorigen Beispiel können mit diesem Aulbau komplette elektronische Steuerungs-Regelungs- und Ü berw achungssysteme geprüft werden. Zur Prüfung der Sollwertgeber, Aktnatoren und Sensoren ist die Messung von verschiedensten Signalen in diesen Komponenten notwendig. Diese Signale werden meist durch eine zusätzliche Sensorik - die so genannte Instr umentier ung - zum Beispiel an den Sensoren und Aktuatoren eines Fahrzeugsystems aufgenommen. Ebenso wird die Erfassung steuergeräteinteme r Zwischengrößen als Instrumentierung des Steuergeräts bezeichnet. Dazu kann eine Instrumentierung dieser Komponent en und des Steuergeräts mit einem Mess-, Kalibriet- und Diagnosesystem in das Laborfahrzeug integriert werden. Der Zugriff auf das Steuergerät kann über verschiedene Offboard-Schnittstellen erfolgen, etwa über die Offboard-Diagnoseschnittstelle. Die darstellbaren Testfälle gehen an einigen Stellen über die Testsituationen des letzten Beispiels hinaus. Jedoch bestehen an anderen Stellen gegenüber der obigen Situation auch Einschränku ngen, etwa bezüglich der Vorgabe von Alterungseffekten in Sensoren oder der Vorgabe von Extrem- und Fehlersituationen.

5.5.2.3 Inbetriebnahme und Pn ifilmgebullg fi'ir ein Steuergeratenetzwerk Sind die zu prüfenden Funktionen durch ein verteiltes und vem etzres System realisiert, dann ist die Erweiterung des Verfahrens auf die Prüfung mehrerer Steuergeräte erforderlich. Die Instrumentierung muss auf mehrere Steuergeräte erweitert werden (Bild 5-8 J).

5.5 lntegratlon und Test von Softwa re-Funktionen

283

Häufig werden die Tests in Stufen durchgeführt. So können z. B. zunäch st die Kommuni kation zwischen den Steuergeräten über den Bus und die relevanten Komponenten der BasisSoftware geprüft werden. Erst in einem weiteren Schritt werde n die Komponenten der Anwendungs-Softwa re getestet (Bild 5-66).

r-----------------------------------, I

J

I

I

Fahrer

Umwelt

z

ll:*

1

Sollwert-

I

I

~ r 8 1: Bet rieb \'1111 mehrere n Steue rgeräten in virtue ller Umgehu ng 1901

In beiden Fällen können nicht vorhandene Steuergeräte durch simu lierte Steuergeräte ersetzt werden, die dann Komponenten des Umge bungsmodells sind, das auf dem Echtzeitrechncrsystem ausgeführt wird. Das Echtzeitrechnersystern benötigt dazu eine Schnittstelle zum Kommun ikationssystem. dem Bus. Die virtuelle Nachbildung des Kommunikati onsverhaltens von Steuerge räten und die Kopplung zu einem realisierten Teilsystem des Netzwerks zur Prüfung der Kommunikation im Steuergerätenetzwerk wird auch als Restbussimulation bezeichnet [91]. Ein Anwendungsbeispiel ist in Bild 5-82 dargestellt.

5.5.2.4 Prtfstand Der Übergang von Laborfahrzeugen zu Prüfständen ist fließend. Reichen elektrische Signale zum Betrieb der Aktuatoren nicht aus. beispielsweise bei elektrohydraulischen Aktnatoren. dann wird eine dafür geeig nete Testumgebung im allgemeinen als Hydraulikprüfstand bezeichnet. Gegenüber Laborfa hrzeugen werden also weitere. reale Komponenten des Gesamtsystems. beispielsweise der Strecke wie in Bild 5-83 dargestellt, als Prüfling in die Prüfumgebung integriert. Auch die reale Vorgabe von Zustandsgrößen der Umwelt, beispielsweise der Umgebungstemperatur in Kälte- oder Wänneprüfständen, ist möglich. Ähnliches gilt für die Vorgabe von Sollwerten durch eine n realen Fahrer. beispielsweise in Rollen prüfständen. Nicht vorhandene reale Komponenten werde n virtuell nachgebildet, etwa durch ein Fahreroder Umweltmodelt. die ein dynamisches Belastungsprofil vorgeben. Diese virtuellen Kompo-

284

5 Methoden und Werkzeuge in der Entwicklung

nenten können durchgängig bei Laborfahrzeugen und Prüfständen verwendet werden. Zur Nachbildung wird ein Echtzeitrechnersystem, beispielsweise ein Laborfahrzeug. in den Prüfstand integriert (Bild 5-83). r-----------------------------------~

I

I

:

F .:. u

R

-----

y Aktnatoren

-----

~

-- ,

I

X

Strecke

~

Sensoren

B...

I

------------

Instrumentierung Hild 5-K..J: Instrumentierung im Experimentalfahrzeug186J

Ein solches Mess-, Kalibrier- und Diagnosesystem ka nn auc h mit eine m Rapid-P rototypingSys tem. wie in Bild 5-47 dargestellt. kom binie rt werden.

5 Methoden und Werkzeuge in der Entwicklung

286

Beim Übergang vom Prototyp- zum Serienfahrzeug ändert sich mit dem Wechsel vom Entwicklungs- zum Seriensteuergerät in vielen Fällen die für die Instrumentierung zur Verfügung stehende Offboard-Schnittstelle des Steuergeräts. Im Gegensatz zum Prototypfahrzeug steht beim Serienfahrzeug meist nur noch der Steuergerätezugang über die zentrale OffboardDiagnoseschnittstelle des Fahrzeugs oder die Offboard-Diagnoseschnittstelle des Steuergeräts zur Verfügung, teilweise noch ein Zugang zu den Kommunikationssystemen. Für die Messfunktionalität ist dieser Übergang meist mit einer Abnahme der Übertragungsleistung der Offboard-Schnittstelle verbunden, für die Kalibrierfunktionalität mit einer Einschränkung der verstellbaren Parameter und einer Änderung der Arbeitsweise.

5.5.4 Design und Automatisierung von Experimenten Die Definition von Testfällen sollte bereits frühzeitig beim Entwurf berücksichtigt werden . Der Aufbau der Experimente kann sich an verschiedenen Kriterien orientieren - etwa an den Fahrzeugfunktionen, an den Komponenten eines Fahrzeugsystems oder an den Fahrsituationen . Beispiele für funktionsorientiertes Testen von Software-Funktionen sind Testfälle für •

Steuerungs- und Regelungsfunktionen

•

Überwachungs- und Diagnosefunktionen

Beispiele für system- und komponentenorientiertes Testen sind Testfälle für SoftwareKomponenten wie •

Echtzeitbetriebssystem

•

Kommunikationsschicht und Netzwerkmanagement

•

Diagnoseschicht

Beispiele für situationsorientiertes Testen von Software-Komponenten sind eine Aufteilung In

•

Normalfälle

•

Extremfälle

•

Fehlerfälle

Die Automatisierung von Testaufgaben hängt mehr von der Prüfumgebung als vom Testfall ab. Sie erfordert eine formale Beschreibung der Experimente. Die Automatisierung ist am Laborfahrzeug oder Prüfstand natürlich einfacher möglich als im Fahrzeug. Die Automatisierung von Tests bietet enormes Potential zur Kostenreduzierung. Im Rahmen dieses Buches wird jedoch nicht näher auf den Entwurf und die Automatisierung von Experimenten eingegangen. Für den Entwurf von Experimenten (eng\. Design of Experiments) wird auf die Literatur, wie [30, 31], verwiesen.

5.6 Kalibrierung von Software-Funktionen

287

5.6 Kalibrierun g von Software-Funktionen Die Einstellung der Parameterwerte der Software-Funktionen wird als Kallbrierung bezeichnet. Die Parameter liegen in der Regel in Form von Kennwerten. Kennlinien und Kennfeldern in der Software vor. Die Einstellung der Parameterwerte muss häufig für j eden Typ und jede Variante eines Fahrzeugs individuell erfolgen. Dazu werden Mess- und Kalibriersysteme eingesetzt. Die unterschiedlichen Einsatzmöglichkeiten von Mess- und Kalibrietsystemen an Laborfahrzeugen. an Prüfständen bis hin zum Einsatz im Fahrzeug wurden bereits in Abschnitt 5.5 skizz iert. In diesem Abschnitt wird die Arbeitsweise von Mess- und Kalibriersystemen dargestellt. Ein Mess- und Kalibriersystem besteht aus einem Mess- und Kallbrierwerkzeug, einem oder mehreren Steuergeräten mit jeweils einem oder mehreren Mikrocontrollem mit geeigneten Offboard-Schnittstellen und einer Zusatzmesstechnik. die auch Instrumentierung genannt wird. Alle mit der Instrumentierung erfassten Signale müssen im Messwerkzeug einheitlich dargestellt werden. Dies betrifft sowohl den Wertebereich als auch den Zeitbereich der erfassten Messsignale. Für die erfassten diskreten Signale des Mikrocontrollerprogramms bedeutet dies, dass eine Umrechnung von der lrnplementlerungsdarstetlung in die physikalische Darstellung im Messwerkzeug erforderlich ist. .\ I ess. u nd

OlTh oll rd

Kllli llrie nl erli.ll.·u ~

Kennlinie KL

x

,I

Si nal S

x

,~

Verstellen

Messen

Kennlinie KL

Signal S

'-,

X'nI,,11

•

:\ I ikroco illrollc r

'"

.""

~. t,mpl ~

Y~ I

,

Ze ll

Onboud

Lege nde:

phvs:

physikalische Darstellung

impl:

l r uplc mcnucnmg sdarstctlung

Kild S-H5: Unboard- und Uffbourd-Berechnun gcn bei Mess- und Kulibricrs ysremen [86J

Änderungen der Paramete rwerte. etwa der Werte von Kennlinien und Kennfe lde rn, müssen im Werkzeug durch Editoren auf Implementi erungsebene und - wie die Darstellung von Messsignalen - auf physikalischer Ebene unterstützt werden. Bild 5-85 zeigt beispielhaft die phy-

288

5 Methoden und Werkzeuge in der Entwicklung

sikalische Sicht und die Implementierungssicht auf eine Kennlinie KL und ein gemessenes Signal S. Eine konsequente Unterscheidung zwischen Arbeitsschritten, die vom Mikrocontroller im Steuergerät, also onboard durchgeführt werden , und Arbeitsschritten, die durch das Mess- und Kalibrierwerkzeug, also offboard ausgeführt werden, ist sehr hilfreich (Bild 5-85) . Ziel dieser Entwicklungsphase ist die Erstellung oder die Anpassung des Datenstandes, also der Pararneterwerte, die in Form von Kennwerten, Kennlinien und Kennfeldern im Speicher des Mikrocontrollers abgelegt werden und mit denen das Programm des Mikrocontrollers arbeitet. Zur Kalibrierung von Software-Funktionen die durch verteilte und vernetzte Systeme realisiert werden , müssen Mess- und Kalibriersysteme ein Netzwerk von Mikrocontrollern und Steuergeräten unterstützen. In den folgenden Abschnitten wird vereinfachend nur ein Mikrocontroller und ein Steuergerät betrachtet. Ausgangspunkt ist die Bereitstellung eines Steuergerätes, also eines Hardware- und SoftwareStandes. Der Software-Stand besteht aus einem Programmstand und einem initialen Datenstand für jeden Mikrocontroller des Steuergeräts . Das Mess- und Kalibriersystem benötigt zusätzlich eine Beschreibung des Software-Standes, die in der Regel in Form einer zusätzlichen Datei im Format ASAM-MCD 2 vorliegt. Neben Informationen zur Umrechnung zwischen physikalischer und Implementierungsebene für alle Mess- , Kalibrier- und Diagnosedaten sind darin auch Informationen zur Schnittstelle zwischen Werkzeug und Mikrocontroller abgelegt. Ziel dieses oft aufw ändigen Entwicklungsschritts ist die Anpassung des Datenstands. Dabei stehen verschiedene Aspekte im Vordergrund. Beispiele sind die Anpassung an verschiedene Betriebspunkte, der Langzeitbetrieb von Systemen - um Alterungseffekte durch Parameter und Algorithmen kompensieren zu können - , Flottenversuche - um Fertigungstoleranzen von Bauteilen beurteilen zu können - oder die Kalibrierung von Varianten.

5.6.1 Arbeitsweisen bei der Offline- und Online-Kalibrierung Bei der Arbeitsweise mit Kalibriersystemen kann generell zwischen der Offline- und der Online-Kalibrierung unterschieden werden . Bei der Offline-Kalibrierung wird die Ausführung der Steuerungs-/Regelungs- und Überwachungsfunktionen, des so genannten Fahrprograrnms, während der Änderung oder Verstellung der Parameterwerte unterbrochen . Dadurch führt die Offline-Kalibrierung zu vielen Einschränkungen. Insbesondere beim Einsatz an Prüfständen und bei Versuchen im Fahrzeug muss dazu immer auch der Prüfstands- oder Fahrversuch unterbrochen werden. Hier ist deshalb ein Verfahren sinnvoll , das die Online-Kalibrierung unterstützt. Bei der OnlineKalibrierung können die Parameterwerte verstellt werden , während das Fahrprogramm durch den Mikrocontroller ausgeführt wird. Das bedeutet, dass die Verstellung der Parameterwerte bei gleichzeitiger Ausführung der Steuerungs-/Regelungs- und Überwachungsfunktionen und damit beispielsweise während des regulären Prüfstands- oder Fahrzeugbetriebs möglich ist. Die Online-Kalibrierung stellt höhere Ansprüche an die Stabilität der Steuerungs-/Regelungsund Überwachungsfunktionen, da das Mikrocontrollerprogramm während des Verstellvorgangs durch das Werkzeug auch für eventuell auftretende Ausnahrnesituationen, wie beispielsweise kurzzeitig nicht monoton steigende StützsteIlenverteilungen bei Kennlinien, robust ausgelegt sein muss .

5.6 Kalib rierun g von Software-F unktionen

289

Die Onllne-Kalibrierung ist für langw ierige und iterative Abstimma ufgabe n der Pa rameter vo n Funktionen mit eher geringe r Dynamik . beispielsweise zur Abstimmung von Motorsteuerun gsfunktionen am Motorprüfstand. gee ignet. Bei der Kalibrierung der Parameter von Ste uerungsund Regelun gsfunkti onen mit hoh er Dynam ik oder hoher Sicherheitsrelevanz werden Parameter zwar nicht wä hrend der a ktive n Ausführung der Ste uerungs- und Regelun gsfunktionen verstellt. dennoc h kann auch hie r d urch die Onl ine- Kalibr ie rung eine ite rative Ve rge hensweise besse r unterstützt und die Unte rbrechung des Fa hrprog ramms verm ieden werden. Ein Beispiel ist die Abstimmung vo n ABS-Funktionen in Bremsmanövern. Hier wird zwa r nicht während des eigentlichen ABS- Reg lereingrifTs verstellt. Denn och kann die Ze itspa nne zw ischen zwe i Fah rversuchen durch die Online-Kalibri erung reduziert werd en. Beispielhaft s ind zwei mögliche Arbeitswe isen bei der Offlin e- und Onlin e-Kalibrierung in Bild 5-8 6 einande r gegenübe r gestellt.

O min e-- Kalib rieru " 11: Start

Programm- und Datenstand in den Mikrocontroller laden

On line- Kallbrleru nl:, Start [

Programm- und Datenstand in den Mikrocontroller laden

J

[

I

Aus fiihrung des Fahrpros ram m e starten

]

du rchfüh ren

[

Experiment und Messung starten

I

Messdaten analysieren

[

Mcssdatcn analys ieren

]

Parameterwerte ändern

[

Parameterwerte ändern

I

[

Neue Para mete rwerte in Mikrocontroller laden

I

A usführung des Fahr-

programm s starten

Experiment und Messung

1

Ncucn Datenstand erzeugen Ausführung des Fahrprogramms unterbrechen

Ncucn Datenstand in den Mikrocontroller laden

Kitt! S-H6: Untersch iedliche Arbeitsweisen bei O ffline- und Dnlinc-Kalibricrung Die Anforder ungen an On line- und Offlin e-Kalibriersysterue sind also unte rschiedlich. So kommen O ffline-Kalibriersys teme mit den Funktione n Messen. Oflboard- Verstellen von Param etern und Laden von Programm- und Datenstan d. beispielswe ise du rch Flash-Programmie rung, in de n Mikrocontroller aus. Für Online-Kalibriersysteme sind zusätzliche Funktionen notw endig, die das Ändern von Pa rametern ohne Unterbrec hung des Fa hrprogramms

290

5 Methoden und Werkzeuge in der Entwic klung

erm öglichen. Die folgende n Abschnitte orientieren sich an den notwe ndigen Funktionen für die Offlin e- und On line-K alib rierun g.

5.6.2 Softwa re-Update durch Flash-Programmierung Zur Inbetriebna hme des Steuerge räts müssen zunächst der Programm- und Date nstand in den Programm. und Datenspeic he r de s Mikrocontrollers ge laden werden. Entwick lungsste uerge räte werd en in der Regel mit Flash-Speicher ausgerüstet. so dass ein Software-Update für den Programm- und Daten stand durch Flas h-Progra mmierung erfolgen kann ( Bild 5-87) . Wie in Bild 4-23 dargestellt . wird für das So ftwa re-Update durch Flash- Programmierung typischerwe ise ein eigener Betriebszu stand der Software festgelegt. in dem die AusfU hrung de r für de n normalen Fahrzeugbetr ieb notwendigen Ste uerungs- /Reg elungs- und Über wachungs funktionen unterbrochen wird. Der Überga ng in den Betriebszustand ..So ftwa re-Update" wird vo m Flash- Programmierwerkzeug a ngesto ßen und darf nur unter bestimmt en Bedingun ge n e rfolge n. Beispielsweise wäre eine solc he Bedin gun g bei Motorsteuergeräten die Erke nnung des Motorstillstands. also Motordrehzahl = O.

Offi,oard

Mess- und Kalibrierwerkzeuu

Progr ammsrand Datens tand

ASAM-MCD2· Datei

Programmsta nd

FlashProgra mmierung

Programmsta nd

Daten stand

F1a,hProgramm ierung

Datenstand

Fla,h 1\likrocunlroller

Onhua rd

Bild s-87 : Flash- Progrummic rung von Programm- und Datens tand

Im Betriebszustand ..Software-Update" werden da nn sowohl der Programmstand als a uch der Datensta nd in den Flash-Speic her des Mikrocont rollers übertragen. Für ein Update des Datenstands im Steuergerät nac h Absc hluss einer Kali briera ufgabe wird die separate FlashProgr ammie rung des Datenstands unterstützt. Anschli eßend wird - wiederum angestoße n vom Flash- Progra mmierwerkze ug - der Betrieb szu stand .•Softwa re-Update" vom Mikrocontroller wiede r verlasse n und es erfolgt der Übergang in den Betrieb szustand ..Norrnalbe trieb", wo die

5.6 Kalibrierung von Software-Funktionen

291

Steuerungs-/Regelungs- und Überwachungsfunktionen des Fahrprogramms ausgeführt werden . Der Ablaufbeim Software-Update durch Flash-Programmierung wird in Kapitel 6.3 behandelt. Mit den aktuell eingesetzten Flash- Technologien können nur ganze Speicherbereiche, so genannte Flash-Segmente, entweder gelöscht oder neu programmiert werden . Das bedeutet, dass der Datenstand in anderen Flash-Segmenten als der Programmstand abgelegt werden muss, wenn Programm- und Datenstand getrennt programmiert werden sollen . Bei der FlashProgrammierung muss deshalb speicherorientiert gearbeitet werden . Einzelne geänderte Parameter können mit der derzeitigen Flash-Technologie nicht ins Flash programmiert werden .

5.6.3 Synchrones Messen von Signalen des Mikrocontrollers und der Instrumentierung Die Auswirkungen von Parameteränderungen werden in der Regel anhand von Messungen beurteilt. Ziel ist, das Zusammenwirken aller Komponenten eines Fahrzeugsystems bei der Ausführung einer bestimmten Fahrzeugfunktion anhand verschiedenster Messsignale zu beobachten. Ein Beispiel für eine solche experimentelle Prüfung der Funktionen des Motorsteuergerätes ist etwa die Prüfung des Verhaltens der Lambdaregelung bei einem Kaltstart. Dieses Experiment kann an einem Kälteprüfstand oder auf einer Kaltlanderprobung im Fahrzeug durchgeführt werden . Ohne eine Instrumentierung aller an der Funktion beteiligten Fahrzeugkomponenten durch eine gee ignete Messtechnik und die synchrone Erfassung und Aufzeichnung von Messdaten im Mikrocontroller und den instrumentierten Komponenten ist eine Beurteilung der Funktion meist nicht möglich. Das Mess- und Kalibriersystem muss dazu die Erfassung von sich ändernden Signalen im Mikrocontroller während der Ausführung des Programms - also die Messung von Größen , die im RAM des Mikrocontrollers abgelegt sind - synchron mit der Erfassung von zusätzlichen Signalen der Instrumentierung in der Umgebung des Steuergeräts durch eine geeignete Messtechnik unterstützen (Bild 5-84) . Dies kann auch die Erfassung von Signalen des Fahrers und der Umwelt einschließen. Diese zusätzlichen Signale werden häufig an den Sensoren und Aktuatoren der Fahrzeugfunktion aufgenommen. In vielen Fällen interessieren auch die aktuellen Umgebungsbedingungen wie Luftdruck oder Lufttemperatur - oder weitere Signale - wie Drehmomente, Drücke, Temperaturen oder Abgaswerte - an verschiedenen Messstellen im Fahrzeug. Auch der für eine Funktion relevante Datenverkehr im Kommunikationsnetzwerk des Fahrzeugs soll in vielen Fällen synchronisiert aufgezeichnet werden . Sinnvollerweise wird für die Instrumentierung deshalb eine höhere Leistungsklasse als für die Fahrzeugsensoren verlangt. Für die Messtechnik stellt die zeitliche Synchronisation der verschiedenen Erfassungsraten von Signalen des Mikrocontrollers mit der Messwerterfassung der örtlich verteilten, dezentralen Instrumentierung besondere Anforderungen dar , etwa bezüglich der Vergabe von Zeitstempeln und der Synchronisation einer systemweiten Uhrzeit (Bild 2-53) .

5.6.4 Auslesen und Auswerten von Onboard-Diagnosedaten Neben den Parametern von Steuerungs- und Regelungsfunktionen müssen auch die Parameter von Überwachungs- und Onboard-Diagnosefunktionen, beispielsweise Schwellwerte für Plausibilitätsprüfungen, eingestellt werden.

5 Methoden und Werkzeu ge in der Entwicklung

292

Für die experimentelle Überprüfung der Funktionsfäh igkei t des Onbo ard- Dlagnosesystems ist neben der beschriebenen Messtechnik auch das Auslesen und Auswerten der Diagnosedaten aus dem Fehlerspeicher des Mikrocontroll ers erforderlich. Vor einem Experiment sollte der Fehlerspeicher auch gelösc ht werden können. Das bedeutet. währe nd der K alibrierang ist bereits die Grundfunkti onal lrät eines Oftboard-Diagnosesystem s erforde rlich (Bild 2-64 ). Die erforderlichen Beschreibungsinformationen fü r die Klartextdarstellung der Fehlerspeicherinhalte und die Umrechnun g von Signalen in die physikalische Darstellun g durch das Messund Kalibrierwerkzeug sind Bestandte il der Beschreibungsdatei im Format ASAM- t\tCD 2. Auf den Aufbau von Oflboard-D iagnosewerk zeugen wird in Kap itel 6 etwas näher eingegangen.

5.6.5 Offline-verstellen von Parametern Mit den Informationen der Beschreibungsdatei können im Kalibri erwerkzeug die Werte der Parameter des Dat enstands. also die Werte vo n Kennwerten. Kenn linien oder Kennfeldern. auf physika lischer Ebene da rgeste llt werden. Parameteränderungen können durch grafische oder tabellar ische Editoren des Kalibrierwerkzeugs komfortabel unterstützt werden. Der Datenstand im Flash-Speicher des Mikrocontrollers wird in den folgenden Abschnitten als Referenzstand oder auch Referenzseite des Mikroco ntrollers bezeic hnet. entsprec hend der Datenstand im Kalibrierwerkzeug als Referenzseite des Werkz eugs (B ild 5-88). Zum Verstellen von Parametern wird im Werkzeug eine Kop ie der Referenzseite angelegt. die so genannte Arbeitsseite. Der Datenstand der Arbeitsseite kann verändert werden, während die Referenzseite unveränd erbar ist.

Mess- und Klilibril'f"\\'ukzl'ul!:

Daten stand (Rd ere nl , eile )

Ollhoard

Kopieren

Datenstand (Arbcib,ei le)

Sichern

/

Flash · Pmgrammicrung

F1 ashUilload~ Programmierung

Datenstand ( Rctcrcnzscncj

F1 a, h :'Ilikroc onlroller

Onbourd

IJiltl S-8H: U fflin e-Vc rsrcllcn von Parametern des Datenstands

293

5.6 Kalibrierung von Software-Funktionen

Die Änderungen der Arbeitsseite können auf die Referenzseite des Werkzeugs gesichert werden. Die Referenzseite stellt somit eine Vergleichsbasis zu den weiteren Änderungen auf der Arbeitsseite dar. Alternativ stellt die Referenzseite nach einem Laden der aktuellen Werte aus dem Mikrocontroller (eng!. Upload] ein Abbild des aktuellen Zustandes im Steuergerät dar. Erst bei erneuter Flash-Programmierung wird die Arbeits- oder die Referenzseite des Werkzeugs ins Flash des Mikrocontrollers geladen. Dazu muss wieder der Betriebszustand des Mikrocontrollers gewechselt und die Ausführung des Fahrprogramms unterbrochen werden.

5,6.6 Onü ne-versteüen ..'on Para m etern Soll die Verstellung von Parametern auch online möglich sein. dann muss dazu das Konzept der Arbeits- und Referenzseite auf den Mikrocontroller ausgedeh nt werden. Dies erfolgt dadurch. dass für die Online-Kalibrierung die zu kalibrierenden Daten vom RO Moder Flash-Bereich in einen vom Programm nicht verwendeten, freien RAM-Bereich kopiert werden, in dem die Arbeitsseite liegt (Bild 5-89). Mikrocontroller und Kalibrierwerkzeug arbeiten synchronisiert mit den Kalibrierdaten in diesem RAM·B ereich, der auch KahbrierRAM (engl. Calibration RAM, kurz CAL-RA:\I) genannt wird (Bild 5- 1, Bild 5-89) . Während auf der Referenzseite des Mikrocontrollers - im Flash - speicherorientiert und mit Unterbrechung der Ausführung des Fahrprogramms verstellt werden muss, kann auf der Arbeitsseite des Mikrocontrollers - im CAL-RAM - parameterorientiert und während der Ausführung des Fahrprogramms durch das Kalibrierwerkzeug verstellt werden.

:\1 t'S.~·

und

Kopieren

Innenstan d (Refe renzseitc ]

nasn-

Onbnard

Kalibrkl'\\trk ~eu~

I

I Daten stand

Sich ern

Upload

I(Arbcitsscitej

Down load

..,,-----, Uploa d

Pm grammicrung

Kopieren

Date nstand I ( Rcfcrcnzscitc) Aash

Mlkrocomrouer

Sic he rn (F lash-

Daten stand (Arhcits,e itc)

Program- CA L·RA M micrung j

Onhoitrd

Hild 5-89: Dnlinc-Vcrstcllcn von Parametern des Datenstand s m it dem We rkze ug INCA 186 ]

294

5 Methoden und Werkzeuge in der Entwicklung

Die Software des Mikrocontrollers muss dazu im Fahrprogramm auf die Arbeitsseite zugreifen. was durch Modifikationen in der Software oder Hardware des Mikrocontrollers erfolgen kann. Verschiedene Verfahren dafür werden im nächsten Abschnitt dargestellt.

5.6.7 Klassifizi erung der O ffboa rd-Sch nittstellen für das O nline-Verst ellen Auf den CAL·RAM·Bereich kann das Kalibrie-werkzeug über verschiedene Schnittstellen des Mikrocontro llers zugreifen. Grundsätzlich kann unterschieden werden. ob CAL- RAM im Mikrocontroller vorhanden oder nicht vorhanden ist und ob ein Werkzeug über den parallelen Bus des Mikrocontrollers oder über eine serielle Schnittstelle des Mikrocontrollers auf das CAL-RMvl zugreift (Bild 5-90 ).

I

I

/ "',0-- - - , CA L-RA J\I

im Mikrocon troller vorhanden

im Mikroco ntroller nicht vorhan den

/' Zugriff übe r serielle Schnittstelle

Zugri ff über parallele Sc hnittstelle

/' ~ r---_

Zug riff über serie lle Schnittstel le

Zugriffüber para llele Schnittstelle

Ser ientcchnologic

Entwicklu ngs technologic

Entwicklun gstcchnolog ic

Serien-

Entw icklungs-

technolugte

tcchnologrc

Entwicklu ngs tcchnologic

Methode I

Methode 2

Methode 3

Methode 4

Methode 5

Methode 6

Bild

~-90 :

Klassifizierung der Schnittstellen zwischen Mikro contr oller und We rkze ugen

Bei den seriellen Schnittstellen ist ein weiteres Unterscheidungsmerkmal zu berücksichtigen. Es kann eine serielle Schnittstellentechnologie gewählt werden. die auch im Seriensteuergerät eingesetzt wird und dort beispielsweise fllr die Otlboard-Diagnosekommunikation oder die Onboard-Kommunikation verwendet wird. Weit verbreitete Beispiele für eine solche Serientechnologie sind die K-Leilung [5] oder CAN [2]. Alternativ kann eine Schnittstelle verwendet werden. die nur in der Entwicklungsphase vorhanden ist und dort beispielsweise für Download und Debugging der Software verwendet wird. Beispiele sind NEXUS [92] oder JT AG [93]. Dagegen werden Zugriffe über den parallelen Bus des Mikrocontrollers nur in der Entwickluugsphase eingesetzt. FOr die Klassifizierung der Schnittstellen erhält man so die in Bild 5-90 dargestellte Gesamtsieht. Alle in der Praxis auftretenden Schnittstellen können einer der dargestellten Methoden I bis 6 zugeordnet werden. die in den folgenden Abschnitten anhand vereinfachter Blockdiagramme kurz vorgestellt und bewertet werden.

5.6 Kalibrierung von Software-Funktionen

295

Die Blockdiagramme sind beispielsweise dahingehend vereinfacht. dass nur zwischen im Mikrocontro ller vorhandenem CAL-RAM und nicht im Mikrocontroller vorhandenem, also zusätzlichem CAL-RAM unterschieden wird. Dabei wird vernachlässigt, ob das CA L-RMvl sofern beide Varianten beim eingesetzten Mikrocontroller technisch möglich sind - durch internes oder externes RAM realisiert wird. Auch die Art der Realisierung - etwa durch eine Erweiterung des Steuergeräts oder durch eine Erweiterung des Mikrocontrollers in der Entwicklungsphase - wird vernachlässigt.

5.6. 7.1 Serielle. seriennahe Sch nittstelle mit internem ('AL -RAAI (Methode I) Die Methode I - also die Verwendung einer seriel len Schnittstelle, die auch im Seriensteuergerät eingesetzt wird - bietet in Verbindung mit internem CAL-RAM die Vorteile, dass auf Steuergeräteseite fast keine Hardware-Änderungen gegenU ber dem Seriensteuergerät notwendig sind und die Technologie für den Einsatz im Fahrzeug geeignet ist {Bild 5-91 ). Das CALRAM wird im Seriensteuergerät nicht mehr benötigt. Aus Kostengründen können in Entwicklungssteuergeräten Entwicklungsmuster der Mikrocontro ller mit zusätzlichem CA L-RAM verwendet werden. Ist dies nicht möglich. fiihrt dieses CAL-RAM unter Umständen zu zusätzlichen Hardware-Kosten im Seriensteuergerät.

Steuergerät Mikroc ontroller RO MI Flash Mikropron""sor

w crk zc ug RA M

CAL . RAM

CAN- i K· Leitungsschnill _ stelle

CANiK· Leilung

CAN -IK· Leitungsschniu _ stelle

Hihl 5-9 1: Serielle. seriennahe Schniustelle mit internem CAL· RAM (Methode I)

Die Übertragungsleistung der Serienschnittstelle ist aus Kostengründen begrenzt und erfüllt nicht immer die hohen Anforderungen, die an die Messtechnik in der Entwicklungsphase gestellt werden. Häufig werden die K-Leitung [5], die auch für die Oflboard-Diagnosekommunika uen verwendet wird, oder die CAN-Schnittstelle, die für die Onboard-Kommunikation und zunehmend auch für die Offboa rd-Diagnosekommunikation eingesetzt wird, dafür verwendet. Wird die Schnittstelle parallel auch für die Onboard-Kommunlkation eingesetzt. wie beispielsweise CAN, so ist sie oft schon zu einem hohen Grad ausgelastet. In vielen Fällen wird deshalb eine separate. zweite CAN-Schnittstelle ausschließlich für die Offboard-Kommun ikation mit dem Entwicklungswerkzeug genutzt, so dass die Onboard-Kommunikation dadurch nicht zusätzlich belastet wird.

296

5 Methoden und Werkzeuge in der Entwic klung

In be ide n Fällen wird je doc h der Mikroco ntroller dadurch belastet. dass die Kom munikation zwischen Mikrocontroller und Werkzeug dur ch Software-Komp onenten realisiert wird, die zusätzliche Ressourcen. also La ufzeit und Speicher. beleg en. Für die Online-K alibrierung ergebe n sich in vielen Fä llen Einsc hränkun gen durch die begrenzte Größe des CA L-RAM-Bereichs. Die Anzahl der Kennw erte , Kenn linien und Kennfelder, die geme insam kalibriert werde n könn en. wird dadurch begrenzt. Dieses Problem kann zwar dur ch eine dyna mische Verwaltung und Zuteilung des CAL- RA~l · Bereic hs ent schärft werd en, das CA L-RA M-Man age ment belegt aber wie die Oflboard-Ko mmunik ation in j ede m Fall zusätzliche Ressour cen des Mikrocont rollers. Methoden zum CAL -RAM-Ma nage ment werd en in Abschnitt5 .6.S behandelt.

5.6.7.2 Serielle Entwicklungss chnittsteile mit internem CAL· RAM (Methode 2) Auch die Method e 2 - also die Verw endung ein er ser iellen Entw icklungssc hnittstelle in Verbindu ng mit interne m CAL -RA M - bietet den Vorteil, dass auf Steuergeräteseite nur geringe Hardware-Änderun gen gegenüber dem Seriensteuergerät notw endi g sind. Die Entwic klungsschnitts tclle n, wie NE XUS [92J oder JT AG [93J, sind jedoc h zum Teil für andere Einsatzfelde r - etw a für Debuggin g - konzipi ert. Andere Entwicklungsschnitt stellen sind spe zifisch für den Mik rocontroller ausgeprägt. Me istens erfüllen diese nicht alle Anforderunge n für den Einsatz im Fa hrzeug unter raue n Beding ungen. Eine Wandlun g auf eine für den Fahrzeuge insatz a usgelegte Schnittstel le muss deshalb direkt im Steuergerät durchgeführt werden. Eine Lösung nac h diesem Prinzip unter Verwe ndung eines so genannte n seriellen ETKs [94] ist in Bild 5-92 da rgestellt. Steuergerät Mikrocontroller

Wer kzeug ROM/

Flash Mikro_

RAM CA LRAM

pro~_e"ur

z.B. N EX USSehni tl _ stelle

Serieller

HK

Werkzeu g· schnittstelle

Werkzeugschnittstel le

I

Bild 5-92: Serielle Entwicklungsschnittstelle mit internem CAL· KA M (Methode 2)

Die Übertragungsleist ung der Entwicklungsschnittste llen ist meist wesentl ich höher als die der Serienschn ittstellen und e rfU llt die höheren Anforde rungen an die Me sstechnik in der Entwic klungspha se. lsr die Kommunika tion zwisc hen Mik rocontroller und Werkzeug bei Verwe ndung einer solc hen Entwicklungssc hniltstelle dur ch Hardware real isiert, dann sind da für keine Erwe itenmge n oder Änderungen in der Software des Mik rocontrollers notwendi g. Entsprechend geringer ist in vielen Fällen auc h de r Einfluss dieses Ve rfa hrens auf die Lau fzeit.

297

5.6 Kalibrierung von Software- Funktionen

Wie bei der Methode I. ergeben sich j edoch weiterhin für die Onlln e-Kalibrierung in vielen Fällen Einschränkungen durch die Begrenzung der Größe des CAL-RAM-Bereichs und der Mikrocontro ller wird weiterhin durch das CAL-RAM-Manageme nt belastet.

5.6.7.3 Parallele Entwicklungsschnittstelle mit internem CAL · RAM (Methode 3) Alternativ kann auch, sofern möglich. eine parallele Entwicklungsschnitt stelle nach Methode 3 verwendet werden. wie in Bild 5-93 dargestellt. Die Leistungsmerkmale sind ähnlich zu der Methode 2, jedoch sind die Hardware-Modifikationen im Steuergerät wesentlich umfangreicher als bei einem Zugriff über eine serielle Schnittste lle. ln der Praxis hat diese Methode daher eine geringe Bedeutung.

I

Steuergerät Mikroc ontroller ROM I Flash

Werkzeug "AM

CA L