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

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
0 wurc-K m

ncn '11

I Tl"St der Snftware_

I n..... ;!!." & t mp lem.-nlicrull l!. l I der Software· Komoo"~'Tlt
Mod cll icrull,l!s· und Simul at;"'lSwcrkzcu g

Werkzeu g z ur Codc gcnc ricrunl!-

Hild 1-17: Gralische Prozessdarstellun g von Kumlcn- Lietc ranlcn-B c/.ichun gcn 11 3]

Anal yse & S""l ilika ll" n cine , Sonware-Fu nkt;,,"

Ik-ill n & m pl.'mcn li.'runl: ei ner S" flw are -I' un kliOll

Ana l)'"" & Spo:,jlika'l"" eine r

IkSIj:D

K ~ l i hrl~run lt

e iner Software -Fu n ~ tion

Inh1:rütio" & T~, I einer Software· l'un ktion

&

m pl..m..nlicruJlIt eine r sonware -Fun ~l ion

s"nware-I:u nkl;un

eine r Software-" u n~lio n

K ü 1ibrl~ru n l:

eUler Software·Fon~l i on

--- _ ._ ---- - --- -- - --- _ .A n HJ ~' o;e

&

S~zifikHt l(l" ~ i ncr

Softl" arc -f on~ Iion

ßc.;il:n &; Impl~m~"l i~ru "l:

11I1~l:r:ati"n &; T """

ei ner

Softw"re_ Fun~tion

Kali hri~nJIIIl

eine r

einer

5,,1'1 W:lre- F" n~1ion

Software- fu n ~tion

"elluod.,,, & We rkuul:c

" Ud 1-18: Simuhancous Enginee ring und verschiedene Entwickhmgs urngcbungcn

1.5 Methoden und Werkzeuge fUr die Entwicklung von Software fUr elektronische Systeme 27

1.4.5 Produktion und Service von elektronischen Systemen und Software Da Software-Varianten in der Produktion und im Service einfacher zu handhaben sind als Hardware-Varianten , besteht häufig die Anforderung, variantenspezifische Ante ile eines elektronischen Systems möglichst durch Software zu realisieren. Fahrzeugvarianten führen dann zu Software-Varianten der Steuergeräte. In der Produktion und im Service muss deshalb eine Möglichkeit bereitgestellt werden , verschiedene SoftwareVarianten oder Software-Updates in die Steuergeräte zu laden oder Software-Funktionen am Ende der Produktion zu parametrieren. Im Service muss zusätzlich die Fehlersuche bei elektronischen Systemen durch geeignete Diagnoseverfahren und entsprechende Schnittst ellen und Werkzeuge unterstützt werden . Die langen Produktlebenszyklen . große Stückzahlen und die weltweite Verbreitung der Fahrzeuge sind Randbedingungen, die bei der Entwicklung geeigneter Servicekonzepte beachtet werden müssen . Methoden und Werkzeuge für Produktion und Service werden in Kapitel 6 behandelt.

1.5 Methoden und Werkzeuge für die Entwicklung von Software für elektronische Systeme In allen Entwicklungsschritten können geeignete Methoden, die durch Werkzeuge unterstützt werden , zu einer Verbesserung der Qualität und zur Reduzierung von Risiko und Kosten beitragen. Dem durchgängigen Zusammenspiel der verschiedenen Werkzeuge kommt deshalb eine besondere Bedeutung zu. In den folgenden Abschnitten werden mögliche Handlungsoptionen und ihre wesentlichen Auswirkungen bezüglich der drei kritischen Erfolgsfaktoren Qualität , Risiko und Kosten dargestellt. Das V-Modell geht implizit davon aus, dass die Benutzeranforderungen zu Beginn nahezu vollständig erfasst und analysiert werden und damit eine hinreichend genaue Spezifikation der technischen Systemarchitektur davon abgeleitet werden kann. Die Integration geht von aufeinanderfolgenden abgegrenzten Schritten aus. Die Praxis zeigt jedoch, dass diese Voraussetzungen in vielen Fällen nicht erfüllt werden . Die Benutzeranforderungen sind zu Beginn häufig nicht vollständig bekannt und werden während der Entwicklung fortgeschrieben . Spezifikationen spiegeln deshalb zunächst nur eine grobe Vorstellung des Systems wieder ; erst nach und nach werden Details festgelegt . In der Integration führen Verzögerungen bei Komponenten zu Verzögerungen der Integration und aller folgenden Schritte . Bei der unternehmensübergreifenden Entwicklung werden viele Integrations- und Testschritte durch nicht vorhandene, nicht identische oder nicht aktuelle benachbarte Komponenten eingeschränkt. Die Realität ist daher eher durch inkrementelle und iterative Vorgehensweisen gekennzeichnet, bei der Schritte des V-Modells oder das gesamte V-Modell mehrmals durchlaufen werden . Durch Methoden und Werkzeuge zur frühzeitigen Absicherung von Anforderungen, Spezifikationen und realisierten Komponenten im Labor, am Prüfstand, aber auch direkt im Fahrzeug kann eine solche Vorgehensweise filr die Entwicklung von Software-Funktionen durchg ängig unterstützt werden.

28

Einftihrung und Überblick

1.5.1 Modellbasierte Entwicklung Die interdisziplinäre Zusammenarbeit in der Software-Entwicklung, beispielsweise zwischen Antriebs-, Fahrwerks- und Elektronikentwicklung, erfordert ein gemeinsames Problem- und Lösungsverständnis. So müssen beispielsweise beim Entwurf von steuerungs- und regelungstechnischen Fahrzeugfunktionen auch die Zuverlässigkeits- und Sicherheitsanforderungen, sowie die Aspekte der Implementierung durch Software in eingebetteten Systemen ganzheitlich betrachtet werden . Die Basis für dieses gemeinsame Funktionsverständnis kann ein grafisches Funktionsmodell bilden , das alle Komponenten des Systems berücksichtigt. In der Software-Entwicklung lösen daher zunehmend geeignete modellbasierte Software-Entwicklungsmethoden mit Notationen wie Blockdiagrammen und Zustandsautomaten die Software-Spezifikationen in Prosaform ab. Neben einem gemeinsamen Problem- und Lösungsverständnis bietet die Modellierung von Software-Funktionen weitere Vorteile. Ist das Spezifikationsmodell formal, d. h. eindeutig und ohne Interpretationsspielraum, so kann die Spezifikation auf dem Rechner in einer Simulation ausgeftihrt werden und wird im Fahrzeug frühzeitig durch Rapid-Prototyping erlebbar. Wegen dieser Vorzüge hat das "digitale Pflichtenheft" inzwischen eine hohe Verbreitung gefunden . Mit Methoden zur automatisierten Codegenerierung können die spezifizierten Funktionsmodelle auf Software-Komponenten für Steuergeräte abgebildet werden . Dazu müssen die Funktionsmodelle um Designinformationen erweitert werden , die auch erforderliche nichtfunktionale Produkteigenschaften, wie Optim ierungsmaßnahmen, einschließen. Mit so genannten Laborfahrzeugen kann die Umgebung von Steuergeräten simuliert werden . Damit ist ein frühzeitiger Test der Steuergeräte im Labor möglich . Gegenüber Prüfstands- und Fahrversuchen kann damit eine höhere Flexibilität und eine einfachere Reproduzierbarkeit der Testfälle erreicht werden . Die Kalibrierung der Software-Funktionen kann final oft erst zu einem späten Zeitpunkt im Entwicklungsprozess, häufig nur direkt im Fahrzeug bei laufenden Systemen abgeschlossen werden und muss durch geeignete Verfahren und Werkzeuge unterstützt werden . Insgesamt können bei dieser modellbasierten Vorgehensweise die in Bild 1-19 dargestellten Entwicklungsschritte ftir Software-Funktionen unterschieden werden [26]: Diese Vorgehensweise kann auch in der Entwicklung von Funktions- und Steuergerätenetzwerken angewendet werden . Jedoch kommen dann weitere Freiheitsgrade hinzu, wie: •

Kombinationen aus modellierten, virtuellen und realisierten Funktionen, sowie

•

Kombinat ionen aus modellierten, virtuellen und realisierten techn ischen Komponenten.

1.5.2 Integrierte Qualitätssicherung Der systematische Entwurf von Software verfolgt das Ziel, qualitativ hochwertige Software zu entwickeln. Qualit ätsmerkmale von Software sind beispielsweise Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz , Änderbarkeit und Übertragbarkeit. Unter die Qualitätssicherung fallen alle Maßnahmen , die sicherstellen, dass das Produkt seine Anforderungen erftillt. Qualität kann in ein Produkt "eingebaut" werden , falls Richtlinien zur Qualitätssicherung und Maßnahmen zur Qualitätsprüfung etabliert sind.

1.5 Methoden und Werkzeuge rur die Entwicklung von Software fiir elektronische Systeme 29 \ lOOell der So ftware -fu nktionen

.....

~

~~~ J::-------;:.-.:~-~:~ ::-:'-.:t; ":

:':::~ ~}

Modell \"on fahrer. f ahrzeug & L'mwell

,~ ~------- ~--,-:' , LH::~'-5.oo : n _ n::_' ~Y'

CD CD

Log ische

Systemarchitcktur

•••••••••••• Technische

fJ\ \V f7\

3

System -

architcktur

\J

oV

" IOOellienm g und Sim ulation der

Software-Funktionen. sowie des Fahrzeugs. Fahrers und dcr Umwelt Rapid-Prototypin g der Sol1ware-Funktio nen im rea len fa hr/e ug Design & Implementierun g der Softw are-funktio nen Integration und Tes t der Soüware-Funkriouen mit Laborfa brveugen und Prüfständen Test & Kalihrierung der SofiwareFunktionell im Fahr/-cug

r=. ~;nn_"'--nn_--;= nn OO-~_n----' nn Lm ~~j ;rr

Implementierung der Software-Funktionen

Fahrer, Fahrzeug & Umwelt

Bild I-I '); Überblick über de n mod ellb asierten Entwic klungsproze ss

1.5.2. J Richtlinien zur Qualit ätssicherung Unter die Qualitätssicherung fallen alle ..vorbeugenden" Maßnahmen wie • • •

Einsatz von entsprec hend ausgeb ildete n. erfahrenen und geschulten Mitarbeit ern Einsatz eines geeigneten. definierten Entwiekl ungsprozesses Verwendung von Richtl inien. Maßnahm en und Standards zur Unterstützung des Prozesses

• •

Verwendung einer gee igneten Werkz eugumgebun g zur Unterstützung des Prozesses Automatisierung manueller und fehlerträchtiger Arbeitss chritte.

1.5.2.2 Maßnahmen zur Quatitatsprafung. Vatidienmg lind Verifikation Die Qualitätspr üfung umfasst alle Maßnahmen zum Auffinden von Feh lern. Qualitätspr üfungen sollten nach jed em Schrill im Entwicklungsprozess durchgeführt werde n. Sie sind also eine Aneinanderreihung von Aktivitäte n innerhalb des gesamten Entwicklungsprozesses. Bei Software wird allgemein unterschieden zwischen • •

Spezifikationsfehlern. sowie Design - u nd Implementi eru ngsfehl ern .

Einführung und Überblick

30

Unte rsuchungen haben gezeigt, dass in den meisten Entwicklungsproj e kten die Spezi fikatio nsfe hler überwie gen. Das V-Modell untersche idet deshal b bei der Qual itätsprllfung zwischen Validi eru ng und Verifikation. Validierung "USU S Verifikati on

•

Validierun g ist der Prozess zur Beurteilung eines Sys tems oder einer Komponente mit dem Zie l festz uste lle n. ob der Einsatzzweck ode r die Benut zererwart ungen erfüllt we rden.

Fu nktio nsvalid ier ung ist demnach die Prüfung, ob die Spezifikat ion die Benutzeranforderungen erfüllt. ob übe rhaupt die Benutzerakzeptanz durch eine Funktion erreicht wird. •

Verifikati on ist der Prozess zur Beurteil ung ei nes Systems oder einer Komp onente mit dem Ziel festzustellen. ob die Result ate e iner gege benen Entwick lungsphase den Vo rga ben für diese Phase entsprec hen. Softwa re-Ve rifika tion ist de mnach die Prüfung. ob e ine Implem entierun g der fU r den betreffenden Entwicklun gssch ritt vorgegebene n Spe zifikation genügt.

Unte r Einsatz der klassischen Entwicklungs-. Integ rat ions- und Qualitätssicherungsmethoden für Software könn e n Verifikation und Va lidierung häufig nicht kla r getrennt werden . Ein wese ntliche r Vortei l des Einsa tzes von Ra pid-Protoryping- Werkzeugen besteht desha lb in der damit mögliche n frühze itigen und vo m Steuergerät unabhängigen Funktionsva lidie rung mit einem Experimentle tsystem im Fahrzeug. Bild 1-20 ze igt die mög lichen v alld lerungs- und Veri fikationssch ritte bei Einsatz von Simulatio ns-. Rapid-Prototyping- und Codegenerierungswer kzeugen.

Simu latio n

R3pid-l'rotot)'ping

ExpcrimcnliC'S)'Slcm

Bild I -l ll ; Funktionsvalidicrung und Sottware-Verifik ation mit Codc gcncricrun g für das Steuerge rät

S1cucrgc rill

Sunutauon.

Rapid-Prototy ping und

1.5 Methoden und Werkzeuge ftir die Entwicklung von Software ftir elektronische Systeme 31

1.5.3 Reduzierung des Entwicklungsrisikos Ein Risiko ist ein Ereignis , dessen Eintreten den geplanten Projektverlauf entscheidend behindern kann . Es gibt verschiedene Handlungsoptionen zur Risikominimierung in der Funktionsentwicklung. Zwei mögliche Maßnahmen sollen näher betrachtet werden .

1.5.3.1 Frühzeitige Validierung von Software-Funktionen Die frühzeitige Validierung von Software-Funktionen mittels Simulation oder Rapid-Prototyping trägt auch entscheidend zur Begrenzung des Entwicklungsrisikos bei, da die Implementierung der Steuergeräte-Software erst nach erfolgreicher Validierung der Funktion im Fahrzeug erfolgt. Unnötige Iterationen in der Software-Entwicklung können dadurch vermieden werden . Das validierte Funktionsmodell kann einerseits als Spezifikation ftir Design und Implementierung durch die automatisierte, werkzeugunterstützte Codegenerierung ftir das Steuergerät verwendet werden ; andererseits als Referenz für die anschließende SoftwareVerifikation . Zur frühzeitigen Absicherung kommen folgende Validierungsmethoden in Betracht: •

Formale Spezifikation und ModelIierung

•

Simulation und Rapid-Prototyping.

Integrations- und Testsysteme ftir den Einsatz im Labor unterstützen die frühzeitige Steuergerätevalidierung ohne reales Fahrzeug. Eine solche Methode ist beispielsweise die bereits erwähnte Simulation der Umgebung eines Steuergerätes mit Laborfahrzeugen. Dabei müssen die besonderen Anforderungen der häufig unternehmensübergreifenden Entwicklungs-, Integrations- und Testaufgaben berücksichtigt werden . So stehen beispielsweise Prototypenfahrzeuge nur in begrenzter Anzahl zur Verftigung . Der Zulieferer einer Komponente verftigt meist nicht über eine komplette oder aktuelle Umgebung für die von ihm zu liefernde Komponente. Diese Einschränkungen in der Testumgebung schränken die möglichen Testschritte unter Umständen ein. Die Komponentenintegration ist ein Synchronisationspunkt für alle beteiligten Komponentenentwicklungen. Integrationstest, Systemtest und Akzeptanztest können erst durchgeftihrt werden, nachdem alle Komponenten vorhanden und integriert sind. Verzögerungen bei einzelnen Komponenten verzögern die Integration und damit alle folgenden Testschritte. Für Steuergeräte bedeutet dies, dass ein Test der Software-Funktionen erst dann durchgeftihrt werden kann, wenn alle Komponenten des Fahrzeugsystems - also Steuergeräte, Sollwertgeber, Sensoren, Aktuatoren und Strecke - vorhanden sind. Der Einsatz von Laborfahrzeugen ermöglicht die frühzeitige Prüfung von Steuergeräte ohne reale Umgebungskomponenten in einer virtuellen Testumgebung, ohne dass Testfahrer oder Fahrzeugprototypen Gefahren ausgesetzt werden . In Zukunft werden virtuelle Validierungsmethoden dieser Art weiter an Bedeutung gewinnen. Die finale Validierung einer Funktion , also die Prüfung , ob die Benutzeranforderungen erftillt werden, kann jedoch auch zukünftig nur aus der Benutzerperspektive, also durch Akzeptanztests im realen Fahrzeug, erfolgen .

Einführung und Überblick

32

1.5.3.2 Wiederverwendung von Software-Funktionen Ein wei tere r Weg zu r Risikobeg renzung führt übe r die Wied erverwendung. Vora ussetzung dafUr ist eine f\.lodularisierung des Gesa mtsyste ms und d ie Vereinba rung von Schnittstellen. die beispielsweise konform zu A UTOSAR erfo lgen kann.

Sieht bei der Software-Entwicklung die Wiederverwendung betriebsbewährtet Soft ware auf der Quelleöde-Ebene im Vorderg rund. be hinde rt dies heule oft die Einführung neuer Systemund Software-Architekturen. sowie den Umstieg au f neue Hardware-Generationen . E ine Wied erverwend ung auf Modellebe ne bietet hier ent scheid ende Vorteile. Dabei ka nn nic ht nur die Wiederverwendung von ge prüften Spezifikatio nsmodellen für Funktion und Umgebung, sowie von Designs und Implementierungen zur Risikobegrenzung beitragen. sondern auch die Wiederverwendung von Anwe ndungs- und Testfä llen. sowie von Kalibrierd aten von der Simulation über das Labor und den Prüfstand bis hin zum Fahrversuch.

1.5..1 Standardisierun g und Automa tisier ung Zu Kosteneinsparungen und Q ualitätsverbesserungen in der Funktio nsentwicklung können vo r allem Standardisierungs- und Automatisierungsanstreng ungen beitragen.

J.5../.1 Standardisierung Die Standardisierung von Verfahren und Besch reibungsformaten für Mess-, Kahb rier-, FlashProgrammier- und Diagnosewerkzeuge erfolgen vor allem in ASAM [18] und ISO [24. 25]. Diese Standa rds sind in der Fahrzeugindustrie weit verbreitet. Bild 1-21 zeigt einen Überblick tlber die vereinbarte So ftware-Architektur für Werkzeuge und die Schnittstellenstandards A S A ~I -M C D 1. 2 und 3. A utomatisicrungssyst cm

Interaktive Anwendu ng

1

Koordinationssch ich t

------'

SA,\I-)ICU I

Bild 1-21: Aufbau von Werkzeugen nach ASA M-Standards

ASAM-

,\ICU 2

Derenbasis

1.5 Methoden und Werkzeuge ftir die Entwicklung von Software ftir elektronische Systeme 33 Auch Ansätze zur Standardisierung der Software-Architektur für die in den Steuergeräten eingesetzten Mikrocontroller sind inzwischen erfolgreich eingeftihrt. So wird in OSEK [17], JASPAR [49] und AUTOSAR [3] zwischen den "eigentlichen" Software-Funktionen, den Steuerungs-/Regelungs- und Überwachungsfunktionen der so genannten AnwendungsSoftware und einer Basis-Software unterschieden (Bild 1-22). Die Basis-Software ist abhängig von der Hardware, d. h. vom eingesetzten Mikrocontroller sowie von der sonstigen auf dem Steuergerät verftigbaren Hardware . Die Schnittstellen der Basis-Software sind jedoch weitgehend unabhängig von der Hardware und zudem standardisiert. In AUTOSAR wird die Basis-Software zusätzlich noch horizontal und vertikal aufgegliedert (Bild 1-22), um die Komplexit ät weiter zu reduzieren. Die Anwendungs-Software setzt auf den Schnittstellen der Basis-Software auf und ist idealerweise unabhängig von der Hardware. Sie kann damit leichter auf andere Steuergeräte portiert werden . Im AUTOSAR-Standard wird noch ein zusätzliches Bindeglied zwischen Anwendungs- und Basis-Software definiert; diese Komponente wird als AUTOSAR-Runtime Environment (RT E) beze ichnet. In AUTOSAR erfolgt sämtliche Kommunikation zwischen den SoftwareKomponenten der Anwendungs-Software untereinander sowie zwischen Komponenten der Anwendungs- und der Basis-Software über die RTE. Diese stellt die erforderlichen, standardisierten Kommunikationsmechanismen bereit (Kapitel 2). Der Vorteil dieser Architektur liegt darin , dass einzelne Software-Komponenten der Anwendungs-Software praktisch ohne Änderung derselben auf andere Steuergeräte portiert werden können . In diesem Fall muss lediglich der Kommunikationstluss innerhalb der RTE geändert werden . Die Software-Architektur und standardisierte Software-Komponenten für Mikrocontroller werden in Kapitel 2 ausftihrlich behandelt. Bisher konzentriert sich die Standardisierung hauptsächlich auf die aus Sicht von Fahrzeugherstellern und Zulieferern nicht wettbewerbsrelevanten Software-Komponenten der BasisSoftware (Bild 1-22) [27, 28]. Bei den häufig wettbewerbsrelevanten Funktionen der Anwendungs-Software liegt jedoch eine offene Standardisierung meist nicht im Interesse von Fahrzeugherstellern oder Lieferanten. Sind jedoch die haftungs- und urheberrechtliehen Aspekte geklärt, bieten sich beiden Seiten Vorteile durch eine unternehmensinterne Standardisierung, etwa durch die Bildung von Funktionsbibliotheken. Für den Fahrzeughersteller bedeutet dies, dass er Software-Funktionen lieferantenübergreifend einsetzen kann. Für den Zulieferer bietet sich die Möglichkeit, SoftwareFunktionen kundenübergreifend anzubieten.

1.5.4.2 Automatisierung Die Automati sierung von fehlerträchtigen Routineschritten führt neben Kosten- und Zeitvorteilen durch die damit erreichbare Reproduzierbarkeit, vor allem auch zu Verbesserungen der Qualität. Folgende Schritte werden zunehmend automatisiert: •

Herstellung von Funktionsprototypen mit Rapid-Prototyping-Werkzeugen

•

Generierung von C-Code für das Steuergerät (Bild 1-20).

Einführung und Überblick

34

Funk tion

'J Funktion fI

Funktion

1

1

"

1

1

1 I

A UTOS A R Runtime Environment (RT f )

T System

M emo')'

Services

Services

Commun icarion Services

Dnbourd Hardware Abstraction

Memo!)

Communicatiou

Hardware

Hardw are

Abstraction

Abstraction

Microconuullcr

Memory

Cormnunicarion

Drivers

Drivers

Drive rs

UO llerd warc Abstraction

r, Cornplcx Dcvicc

Drive rs

1/0 Drivers

Ir

l

r;-----;--, Lege nde :

0 110

o

AI' I

Bild 1-22 : Sottware-Architektur HiTMikrocontroller nach AUTOSA R Sta nda rd (3]

Bisher im Fa hrzeug d urchge führte Prüfschritte kön ne n mit Laborfa hrzeugen ins Labor verlagert und dann automatisiert werden.

Die automatisierte Durchführung vo n Kallbrie rungs-, Mess- und Testaufgaben ist durch Autornatlsie rungsschnlttstellen de r Mess- und Kalibrierwerkzeuge möglich [29]. Damit können langwierige Kalibrieraufgaben etwa am Prüfstand automatisiert werden. Hierzu ist z. B. mit A S A M -~ l C D 3 ein gee igneter Standard entwickelt worden.

Die Automatisierung von Schr itten im "rechten Ast" des V-Model ls setzt allerdings voraus. dass sie bereits während der Entwurfsphase. also im ..linken Ast" des V-Model ls. berücksichtigt wird. Stichworte sind " Design for Testabiliry'' oder "Des ign of Experiments" . Diese Themengebiete bieten gro ßes Potenzial. befinden sich aber derzeit noch stark in der Entwicklung [30.31]. Routineaufgaben. die beim Verwalten von Versionen, Konfigurati onen und Varianten durchgefü hrt werden müssen. sind häufig fehleranfällig. Durch Schnittste llen aller eingesetzten Entwicklungswerkzeuge zu Systemen zur verstons-, Konfigurat ions- und Variantenverwaltung können solche Aufgaben automatisien werden.

1.5 Methoden und Werkzeuge ftir die Entwicklung von Software ftir elektronische Systeme 35

1.5.5 Entwick lungsschritte im Fahrzeug Insbesondere die Entwicklungsschritte im Fahrzeug - meist ohne Anschluss der Entwicklungswerkzeuge an die sonst vorhandene Infrastruktur wie das Unternehmensnetzwerk - steIlen eine Besonderheit der Fahrzeugindustrie im Vergleich mit anderen Branchen dar. Simultaneous Engineering und fahrzeugtaugliche Entwicklungswerkzeuge stellen hohe Anforderungen an die Entwicklungsmethodik, insbesondere auch an den Austausch der Entwicklungsergebn isse und die konsistente Datenhaltung. Die ftir den Test und die Kalibrierung erforderliche Fahrzeug-Messtechnik muss ftir den Einsatz unter rauen Umgebungsbedingungen wie erweiterter Temperaturbereich, Feuchtigkeit, EMV-Anforderungen, variable Versorgungsspannung, Erschütterungsbeanspruchung und Bauraumeinschränkungen ausge legt werden . Auch die Benutzerschnittstelle muss fahrzeugtauglich sein. Um eine Fahrzeugfunktion, die durch ein System aus elektronischen Steuergeräten , Sollwertgebern , Sensoren und Aktuatoren dargestellt wird, im Fahrzeug validieren zu können , muss ftir die dazu eingesetzte fahrzeugtaug liche Messtechnik eine höhere Leistungsklasse gewählt werden als ftir die Sensorik der Steuergeräte des Serienfahrzeugs. Dies gilt insbesondere auch ftir die Erfassung von internen Signalen eines Steuergeräts und damit ftir die Übertragungsleistung der Schnittstelle zwischen Steuergerät und Messwerkzeug.

37

2 Grundlagen Die Zusammenarbeit verschiedener Fachdisziplinen - wie Maschinenbau, Elektrotechnik, Elektronik und Software-Technik - ist eine wesentliche Voraussetzung für die Entwicklung von Fahrzeugfunktionen, die sich insbesondere auch auf die Entwicklung von Software für elektronische Fahrzeugsysteme auswirkt. Hieran sind verschiedene Fachgebiete beteiligt, die oft simultan an unterschiedlichen AufgabensteIlungen arbeiten . Dies erfordert ein gemeinsames Problem- und Lösungsverständnis . In diesem Kapitel erfolgt daher eine Einführung in die Fachgebiete, die wesentlichen Einfluss auf die Software als Subsystem haben . Dies betrifft vor allem die Entwicklung von steuerungsund regelungstechnischen Systemen , von diskreten , eingebetteten Echtzeitsystemen, sowie von verteilten und vernetzten, zuverl ässigen und sicherheitsrelevanten Systemen . Ziel ist die Funktionsweise und das Zusammenwirken der verschiedenen SoftwareKomponenten eines Mikrocontrollers, wie in Bild 1-22 dargestellt, verständlich zu machen . Der Anspruch ist nicht die umfassende Behandlung der verschiedenen Gebiete , sondern die Darstellung von Grundlagen und Begriffen , soweit sie für die folgenden Kapitel notwendig sind. Die gewählte Begriffswelt orientiert sich an den verbreiteten Standards und - soweit möglich und sinnvoll - an deutschen Begriffen. Die englischen Begriffe werden , wo es notwendig erscheint, in Klammern angegeben . Englisch-deutsche Wortzusammensetzungen werden mit Bindestrich geschrieben. Die Reihenfolge der Behandlung der einzelnen Fachgebiete stellt keine Wertung dar. Da die verschiedenen Fachgebiete jedoch in vielfaltiger Weise voneinander abhängen, wurde die Reihenfolge so gewählt, dass diese Einführung möglichst ohne Verweise auf nachfolgende Abschnitte auskommt.

2.1 Steuerungs- und regelungstechnische Systeme Viele Fahrzeugfunktionen in den Bereichen Antriebsstrang, Fahrwerk und Karosserie haben steuerungs- oder regelungstechnischen Charakter. Die Methoden und Begriffe der Steuerungsund Regelungstechnik stellen deshalb ein notwendiges Grundgerüst für den Entwurf vieler Fahrzeugfunktionen dar.

2.1.1 Modellbildung Die steuerungs- und regelungstechnischen Entwurfsmethoden abstrahieren zunächst von der technischen Realisierung. Diese Abstraktion wird als Modellbildung bezeichnet. Dabei wird zwischen einer Modellbildung für das Steuer- oder Regelgerät, dem so genannten Steuerungsoder Regelungsmodell, und einer Modellbildung für das zu steuernde oder zu regelnde System, dem so genannten Steuerstrecken- oder Regelstreckenmodell, unterschieden. Die Lösung von Steuerungs- und Regelungsaufgaben ist weitgehend von den besonderen konstruktiven Gesichtspunkten eines zu regelnden oder zu steuernden technischen Systems unabhängig. Entscheidend für den Entwurf von Steuer- und Regelgeräten ist in erster Linie das

2 Grundlagen

38

statische und dyna misc he Verhalten des zu steuernde n ode r zu regelnden techni schen Systems. ln Anlehnung an den Sprachge brauch in der Automobilindustrie wird in diesem Buch vereinfachend von Steuerge räten ges proc he n. Darunt er we rden Geräte verstanden. die - unter a nderem - sowo hl Steuerungs- als auch Regelu ngsau fgabe n au sführen .

Die Art der physikalischen Größe, ob es sich also zum Beisp iel um eine Temperatur. eine Spannung, einen Druck , ein Drehmoment, eine Leistung oder eine Drehzahl hand elt. die zu steuern oder z u regeln ist, und die gerätetec hnische Rea lis ierung sind zwe itrangig. Diese Mög lichkeit z ur Abstraktion erlaubte es der Steuerungs- und Regel ungstech nik, sich zu e inem eige nständigen Fachge biet zu ent wick el n. Dadu rch . dass diese Inge nieurwis se nschaft versucht. geme insame Eige nschaften technisch völli g verschiedener Sys teme zu erkennen, um darau f basierend allgeme in anw end bare Entwurfsmethoden für Steuerungs- und Rege lungssysteme zu entwic ke ln. wu rde diese Disziplin zu ein em verbinde nden Ele me nt ve rschiede ner Fachric htunge n.

2. 1.2 Bfockschattbüder Die Mo dellbildung erfolgt oft gra fisch, vorzugs we ise mit so genan nten Blockschaltbildern zur Darstellung des Übertragungsverhaltens der Kom ponent en und der S igna lflüsse zwischen den Komp onenten e ines Systems. In Bild 2- 1 ist das Blockschaltb ild für die logische Systemarchite ktur von steuerungs- und rege lungstec hnisc hen Fahrzeugfunktionen dargestel lt.

Fahrer

Umwelt

•

l. ....

I .\\'*

So llwert gebcr Fahrzeug

Bild 2- 1:

~( SteRegler ueru ng! ,.~ Akuratorcn Überwachu ne

.+

v

.=..

Strecke

~

Senso re n

~

Mod ellbild ung mit lüockschehbildcm t1lr srcucrun gs - und regelu ngstechnische Fahrzeug-

Iunktioncn

Anhand von Bild 2- 1 können auch die wichtigsten Begriffe der Steu erungs- und Regelun gstechnik erlä ute rt werden : Die Regelun g ist e in Vorga ng. bei dem eine zu regelnd e G röße X fortlaufend erfasst . mit de r Führungsgröße W verglichen und abhängig vom Erge bnis dieses Vergleichs im Sinne e iner Angleic hung an die Führungsg rö ße beeinflusst wir d. De r s ich dabe i ergebende Wirkungsablauf findet in e inem gesc hlosse ne n Kreis. de m Regel krei s. statt. Die Regelu ng hat die Aufgabe. trotz störender Einflüsse dur ch die Störgröße Z den Wert der Regelgröße X an den durch die FUhrungsg röße W vo rgegebenen Wert anzugle ichen [32] . Die S te ue ru ng ist dagegen e in Vorgang in e inem System. be i dem ei ne oder mehrere G röße n als Eingangsgrößen andere Grö ßen a ls Ausgangsgrößen auf G rund de r dem System eig enrum-

2.1 Steuerungs- und regelungstechnische Systeme

39

liehen Gesetzmäßigkeit beeinflussen. Kennzeichen für das Steuern ist der offene Wirkungsablaufüber das einzelne Übertragungsglied oder die Steuerkette [32]. Steuerungs- und Regelungsmodelle in Form von Blockschaltbildern beschreiben die Kompo nenten eines Systems im Sinne von Übertragungsg liedern durch Blöcke und die Signalflüsse zwischen den Blöcken durch Pfeile. Im Kraftfahrzeug handelt es sich meist um Mehrgrößensysteme . Im allgemeinen Fall liegen deshalb alle Signale in Vektorform vor (Bild 2-1) . Bei den Signalen wird unterschieden zwischen den • •

Mess- oder Rückführgrößen Ausgangsgrößen der Steuerung oder des Reglers

B !L

• • •

Führungs- oder SolIgrößen Sollwerten des Fahrers Regel- oder Steuergrößen

W W*

• •

Stellgrößen Störgrößen

K X '!:.

Bei den Blöcken wird unterschieden zwischen dem Steuerungs- oder Reglermodell , den Modellen der Aktuatoren, dem Streckenmodell, den Modellen der Sollwertgeber und Sensoren , dem Fahrermodell und dem Umweltmodell. Der Fahrer kann die Funktionen der Steuerung oder des Reglers durch die Vorgabe von Sollwerten beeinflussen. Die Komponenten zur Erfassung dieser Sollwerte des Fahrers - beispielsweise Schalter oder Pedale - werden auch als Sollwertgeber bezeichnet. Sensoren erfassen dagegen Signale der Strecke . Die Führungsgrößen W können also im allgemeinen Fall von den Benutzern des Systems über einen Sollwertgeber oder von einem übergeordneten System vorgegeben werden . Im allgemeinen Fall liegen hierarchische Systeme vor. Da die steuerungs- und regelungstechnischen Modelle von der technischen Realisierung abstrahieren, ist diese Art der Modellbildung auch geeignet, um die steuerungs- und regelungstechnischen Funktionen der Software elektronischer Steuergeräte zu modellieren und ihr Zusammenwirken mit den Sollwertgebern, den Sensoren, den Aktuatoren, sowie mit den Komponenten des Fahrzeugs und anderen elektronischen Systemen zu beschreiben. Aus diesen Gründen ist die ModelIierungsmethode mit Blockschaltbildern auch in der Entwicklung von Fahrzeugfunktionen, die durch Software realisiert werden, weit verbreitet. Sie stellt trotz der Vernachlässigung wichtiger Software-Aspekte ein Bindeglied für einen durchgängigen Entwicklungsprozess dar. Beispiel : Blockschaltbild für PI-Regler Blockschaltbilder werden auch zur Beschreibung von Blöcken im Regelkreis verwendet , beispielsweise ftir den Reglerblock. Bild 2-2 zeigt ein Blockschaltbild eines Reglers mit zwei Anteilen , einem Anteil mit proportionalem Übertragungsverhalten, auch P-Anteil oder P-Glied genannt, und einem Anteil mit integralem Übertragungsverhalten, dem I-Anteil oder I-Glied. Dieser Reglertyp wird daher als PI-Regler bezeichnet. Charakteristisch für einen Regler ist der Vergleich der Regiereingangsgrößen Wund R. Wie im Falle des dargestellten PI-Reglers erfolgt dieser Vergleich häufig durch die Bildung der Differenz zwischen den beiden Eingangsgrößen, der Führungsgröße Wund

2 Grund lagen

40

der Rückführgröße R. Die berechnete Differenz, die so genannte Regelabweichung, bildet die Eingangsgröße der beiden Reglerglieder, dem P-G lied mit dem Übertragungsverhalten

X out (t)= kpXin(t) und dem

(2.1)

I-Glied mit dem Übertragungsverhalten

X out(t) = kJX in(t) dt

(2.2)

f

denen die Verstärkungsfaktoren oder Reglerparameter kp und k) zugeordnet sind . Die Ausgänge der beiden Regelglieder werden addiert und bilden die Reg Ierausgangsgröße U des PI-Reglers. Die so genannte Übertragungsfunktion des PI-Reglers ist also

U(t ) = k p(W(t) - R(t» + fk / (W(t) - R(t»dt

(2.3)

Für jeden Block des Blockdiagramms existiert eine Außen- und eine Innenansicht (Bild 2-2). Au ßena nsic ht:

w ....

R ....

PI-Reg ler .... U

Inn enan sicht: PI-Reg ler

+ R Bild 2-2: Blockschaltbild für einen PI-Regler

Modelle dieser Art für alle Blöcke des Regelkreises oder der Steuerung bilden die Basis für die Analyse, die Spezifikation, das Design , die Realisierung und den Test von Systemen. Es ist an dieser Stelle weder möglich noch beabsichtigt, auf die zah lreichen Modellbildungs-, Ana lyse- und Entwurfsverfahren für Ste uerungs- und Regelungssysteme einzugehen. Hierzu wird auf die weiterführende Literatur, wie [33, 34, 35 , 36] , verwiesen . Entscheidend für das Verhalten einer Steuerungs- oder Regel ungsfunktion ist einerseits die Übertrag ungsfunktion an sich, der so genannte Steue r ungs- ode r Regelungsalgorithm us , und andererseits die Einstellung der Steuerungs - und Reg lerparameter. Die Menge der Parameter einer Steuerungs- und Regelungsfunktion wird zusammenfassend auch a ls Para mete rsatz

2.1 Steuerungs- und regelungstechnische Systeme

41

bezeichnet. Neben skalaren Größen, wie k]>und k l im obigen Beispiel, werden in vielen Fahrzeugfunklionen auch Kennlinien und Kennfelder als Sieuerungs- und Reglerparameter verwendet. Beispiel: ZUndwinkelkennfeld Ein Beispiel ist das ZUndwinkelkennfeld, das in Motorsteuergeräten notwendig ist (Bild 2-3). Abhängig vom aktuellen Betriebspunkt des Motors, also abhängig von den Eingangsgrößen Drehzahl und Last bzw. der relativen Luftfüllu ng. sind im Zündwinkelkennfeld die fUr den Kraftstoffverbrauch und das Abgasverhalten des Motors bestmöglichen Zündwinkel eingetragen [4]. Die Werte des Zündwinkelkennfeldes sind motorspezifisch. Deshalb müssen sie in der Entwicklungsphase des Fahrzeugs ermittelt und angepasst werden.

• ZOndwinkel

Bild 2-3:

Zündwin kelkennfeld bei

Motorsteuerungen 1-1 1

Wie bereits angesprochen, ist es aus steuerungs- und regelungstechnischer Sicht zweitrangig, ob die Realisierung einer Steuerungs- und Regelungsfunktion letztlich durch ein mechanisches, hydraulisches, elektrisches oder elektronisches System erfolgt. So kann beispielsweise der oben dargestel lte PI-Regler technisch völlig unterschiedlich realisiert werden. Gerade im Fahrzeugbau bietet je doch die Realisierung von Steuerungs- und Regelungsfunktionen durch elektronische Steuergeräte in Kombination mit mechanischen, elektrischen oder hydraulischen Komponenten viele Vorteile, etwa in Bezug auf die erreichbare Zuverlässigkeit, das Gewicht, den benötigten Bauraum und die Kosten. Diese Realisierungsform wird daher meistens bevorzugt. In den folgenden Abschnitten wird aus diesem Grund auf die Wirkungsweise und den Aufbau elektronischer Steuergeräte näher eingegangen (Bild 2-4). Aus Sicht der Software-Entwicklung für die in elektronischen Steuergeräten eingesetzten Mikrocontroller, werden die Steuerungs- oder Regelungsmodelle auch als Funktionsmodelle bezeichnet; die Sollwertgeber-, Sensor-, Aktuator-, Strecken-, Fahrer- und Umweltmodetle als Um gebungsmnrteüe.

42

2 Grundlagen

r --------,

r--------,

,:" I ahrer :~----------..:" Umwelt ,: L-r-I-J L__-.- :

T r - - - - ~~------------------------~~----------------t --_ ,I ,Ir----,I Steuerung! ur--------: 1: r--------: X r--------l ß Sollwert - ' w I

,' ,

I \ gcbcr I , - - - -- - - - -

'

I

,,'4

+, I

Regler

Überw achun e

-- ---- "-

Fahrzeug

~Aktualorcn~ , __ _ _ _ _ _ _ J" ~

~

Strecke

~

__ ____ _ -'"

~

Sensoren

,~

________ .J

•

I

----- - - - - - --- ------------Steue rgerät

-

\I

0

ß

,

-'I

-4

Bild 2....: Realisierung von Steuerungs- und Regelungsfunktionen durch ein elektronisches Steuergerät

2.2 Diskrete Syste me Im Gegensatz zu mechanischen, elektrischen oder hydraulischen ßaut eilen, die analoge Komponenten darstellen, werden die Eingangsgrößen von den in elektronischen Steuergeräten typischerweise eingesetzten digitalen Mikroprozessoren diskret verarbeitet. Das bedeutet, die Steuerungs- und Rege lungsfunktionen müssen diskret realisiert werden. In diesem Abschnitt werden deshalb einige Begriffe und Grundlagen diskreter Systeme dargestellt [37, 38}. Bild 2-5 zeigt den vereinfachten Aufbau eines elektronischen Steuergeräts. Str ur 'l:r rä t

W

Eingangsstufen

W-

.\ Iikrncont rnllr r

Ausga ngs-

~,

l.:o., ß

stufen I Endstufen

1:

ß .,

Bild 2-5: Modell ei nes elektronischen Ste ue rge räts als Block eines Steuerungs- und Regelu ngssyste ms

Die von den Sollwertgebern und Sensoren erfassten externen Eingangssignale \V und B werden zunächst in den Eingangsstufen des Steuergeräts sowe it vorverarbeitet. dass sie vom Mikrocontroller als interne Eingangsgrößen lli"l und Billl weiterverarbeitet werden können. In

43

2.2 Diskrete Sys te me

ähnlicher Weise verarbeiten d ie Ausga ngs- ode r Endstufe n d ie internen Ausgangsg rößen ßut de s Mikrocontrollers in die von den Aktuat oren benötigte externe Form !l. ln der Regel handelt es s ich bei den Eingangs - und A usgangss tufen um Slgnatkondiüonfenm gs- ode r verstärke rscha ltu ngen. In der Software- Entwick lung für den Mikro prozessor e ines Mikroco ntrollers sind die inte rnen S igna le von Bedeu tung. Z ur Vere infachung de r Schreibwe ise wird im Folge nden nicht mehr zwischen interne n und e xternen S ignalen unte rsch ieden . lm Falle. dass nichts anderes ex plizit an gegeben wird . werd en im Fo lge nde n die inte rnen Signa le mit \ \'. ß. und !L bezei ch net.

2.2. 1 Zeltdiskrete Systeme und Signale Bei analogen Sys temen si nd a lle auftretenden S ignale kon tinu ierl iche Funkt ionen de r Ze it. Da bei ist e ine m Signa l X zu jedem Ze itpunkt t in ei nem bet racht eten Zeit interva ll e in ei ndeu t ige r Z ustand X(I) z ugeo rd net (Bild 2-6 a). So lche Signa le werden als zeu- und wertkennn uiertic he S i~ na le bezeichnet. Wird e in so lches Signal Xü). wie in Bild 2-6 b da rgestellt. nur zu bestimmten d isk reten Zeitpun kten t j. ta- t3, ... gemesse n ode r ..abgetastet", e ntsteht e in zeit di sk re te s. we r tko ntinuierliches Signa l ode r Abt3st sig na l. das durc h d ie Za hlenfo lge X(td '" l X(til. X(t2). X(t3)• ... I

mit k = 1. 2. 3. ...

(2.4 )

defi niert wird .

Die Zeits panne dTI( '" tk - tk_1 wird a ls Abtastra te beze ichnet. Die A btastrate kann für a lle Abtas tungen k konstant se in oder s ich ändern .

Zustand X

x, X. X~

X,

X,

X,

+---------

Zeil 1

X, 1========'-+ Zeit I

a ) zcit- und wert kontinuierlich

Zustand X

c) zeitkontinu ierlich und we rtdisk ret

Zustand X X, ~ ~

X" X~

X~ X.I Xl

-Hf-l-+-++-+--111

t1

I)

I~

t~

t"

Zeit t

XJ

:

:

:.__ :

~_

i

..

~.

~

:

:

.:._ :

-i----i----t-.--i----i---.j..-.' .: __. ~:__~ :~ _ i

L-L: i : r"

---

: , .:

i:!

---L-

: ....---~.: :~ .--:--

Bild 2-6: Abtostung eines kuntinuicrlichcn Signals

: .:._

i i : i i --- --- --- .--- --- -

17

11) zeitdisk ret und wertkorttinuierhch

i

, ··--r----l·---~·-- t_-

d) zcit- und wertdiskret

Zeit I

44

2 Grundlagen

Beispiel: Abtastraten im Motorsteuergerät Das Motorsteuergerät führt eine Reihe von Teilfunktionen aus . Es erfasst über Sensoren den Zustand des Motors und den Fahrerwunsch und steuert die Aktuatoren des Motors an . Die beiden Grundfunktionen Zündung und Einspritzung müssen zu kurbelwellenwinkelsynchronen Zeitpunkten die Aktuatoren des Motors, z. B. die Einspritzventile, ansteuern. Bei einer Änderung der Motordrehzahl ändert sich also auch die Abtastrate dieser Funktionen . Andere Funktionen, beispielsweise die Erfassung des Fahrerwunsches über die FahrpedalsteIlung mit dem Pedalwegsensor, können dagegen in zeitlich konstanten Abständen, also mit konstanter Abtastrate, ausgeftihrt werden. Die Abtastrate dT ist ein wichtiger Entwurfsparameter für zeitdiskrete Systeme. Die erforderliche Abtastrate wird durch die Dynamik der Regel- oder Steuerstrecke bestimmt. So gilt als Faustregel ftir die Auslegung der Abtastrate bei der Regelung zeitkontinuierlicher Systeme durch zeitdiskrete Regler, dass die Abtastrate dT im Bereich von 1/10 bis maximal 1/6 der kleinsten der wesentlichen Zeitkonstanten der Regelstrecke gewählt werden sollte [34] . Das Verhalten zeitdiskreter Steuerungs- und Regelungsfunktionen hängt signifikant von der gewählten Abtastrate dT ab . In der Regel verarbeitet ein Steuergerät mehrere Regelungsfunktionen , denen unterschiedliche Abtastraten zugeordnet sind, wie im letzten Beispiel dargestellt. Tritt in einem System mindestens ein zeitdiskretes Signal auf, so spricht man von einem zeitdiskreten System. In Mikrocontrollern entsteht eine derartige Diskretisierung der Zeit etwa durch die zeitdiskrete Abtastung der Eingangssignale.

2.2.2 Wertdiskrete Systeme und Signale Infolge der beschränkten WortIänge der ftir die Erfassung der Eingangssignale üblicherweise eingesetzten Analog-Digital-Wandler, kurz A/D-Wandler, die auch als Abtastglieder bezeichnet werden [34] , entsteht zudem eine Amplitudenquantisierung oder ein wertdiskretes Signal (Bild 2-6 c). Diese Quantisierung der Amplitude ist ein nichtlinearer Effekt. Die NichtIinearität bei der Analog-Digital-Wandlung kommt z. B. in der Begrenzung des Wertebereichs durch Xmin und X max zum Ausdruck. Dabei wird jedem Zustand X(t) genau ein diskreter Wert X, der Menge eindeutig zugeordnet.

(2.5)

Die Differenz X(t) - Xi(t) wird als Quantisierungsfehler bezeichnet. Ein ähnlicher Effekt tritt auch bei der Ausgabe von Signalen des Steuergerätes, der so genannten Digital-Analog-Wandlung auf. Dabei wird in vielen Fällen ein pulsweitenmoduliertes Signal ausgegeben . Im Folgenden werden alle möglichen Verfahren zur Ausgabe von diskreten Signalen zusammenfassend als Digital-Analog-Wandlung, kurz DIA-Wandlung, bezeichnet. Bei der DIA-Wandlung wird der zugeordnete Wert X, konstant bis zum nächsten Abtastzyklus gehalten . Die DI A- Wandler werden daher auch als Halteglieder bezeichnet [34] .

45

2.2 Diskrete Systeme 2.2.3 Zeit- und wertdiskrete Sy steme und Signa le

Treten beide Dlskretislerungseffekte zusammen auf. so entsteht ein zelr- un d wertdiskretes Signa l (Bild 2-6 d). Tritt in einem System mindestens ein zeit- und wertd iskretes Signal auf. so spricht man von einem zeit- und wertdi skreten oder digitalen Syste m. Alle Größen, die als Eingangsgrößen in einem Program m verar beitet werden, das auf einem Mikrocontroll er eines elektro nischen Steuergeräts ausgeführt wird. sind zeit- und wertdiskrete Signale. Der Mikrocontroller kann als Block im Regelkreis oder in der Steuerkette gezeichnet werden. wie in Bild 2-7 dargestellt, Dabei we rden die im Allgemeinen zeit- und wertkontinuierlich en Eingangssig nale W und B auf die zeit- und wertdiskret en Signale WI.; und !!k abgebildet. Aus diesen werden in einem Programm die reit- und wertd iskreten Ausgangss ignale .!!.k berechnet. die wiederu m auf die zeit- und wenkontinu ierlichen Ausgangssig nale !L abgeb ildet werde n. Das Übertragungsverhalten der Steuerungs- und Regelungsfunktionen. sowie die Steuerungs- und Reglerparameter müssen du rch Software-Komponente n realisiert werden , die au f dem Mikrocontroller ausgefüh rt we rden.

:\lilmlContnlller ~

x.oWandlung

~

A '[). Wandlung

.=+

Sof\"'art'

1

1

~j ['

.:; DDD 11

11

I

r.~

DiA Wandlung

~~

u

Soli" are-Komponeme 7ur vnn Steuerungsund Regelungsfunktionen

Ikr~ h n ung

Bild 2-7 : Modell ei nes Mikrocontrollers als BIIK:k eines Steueru ngs- und Regelungssystems

2.2A Zu standsautomaten Während physikalische Größen in der Regel zeit- und wertkontinui erlich e Signale sind und das Übertragungsverhalten zeit- und we rtkontinuierlicher Systeme physikali sch dur ch Differentialgleichungen beschrieben werden kann, kann das Übertragungsverhalten diskr ete Systeme durch Differenzengleichungen beschrieben werden . Durch die Ze it- und Wertedi skretisierung wird der Übergang von einem diskreten Zustand X(ld in einen Fo lgezustand X(tk+Jl auf ein Ereign is red uziert . Die Tatsache, dass in vielen diskrete n technischen Systemen häufig die Anzah l der möglichen oder releva nten Zustände und auch die Anzahl de r möglichen oder relevanten Ereignisse begrenzt ist. wird bei der Modeli bildurig mit Zustandsau lornaten ausgenutzt.

46

2 Grundlagen

Beispiel: Ansteuerun g der Tankreservelumpe Der FUll standsgeber misst den Tanki nhalt des Fahrzeugs und l iefert ein A nalogsignal

zwischen 0 V und 10 V a ls proportiona les Signal zum gemesse nen Füllsta nd. Dieses Analogs ignal w ird a ls Einga ngssig na l zur Ansteuerung de r Tankreserv elamp e ve rwendet und im Komb iinstrum ent zeit- und wertdiskret abge tas tet.

Dabei entspricht ein Analogsignalwert vo n 8.5 V dem Erreichen des Reservestand s von 5 Litern für die Tankfüll ung. ein Signalwert von 10 V entspricht dem leeren Tank und ein Signalwert von 0 V dem vo llen Tank. Folglich muss die Tankreservelampe bei einem Sig nalwe rt von größer 8,5 V eingeschaltet wer den.

Um zu vermeide n, dass die Lam pe dadurc h flackert, dass schon bei geri ngen Schwa ppbewegungen im Tan k die Lampe wie der a usges chaltet bzw. erneu t eingeschaltet wird, soll eine Hysterese realis iert we rden. Erst bei einem Füllstand vo n mehr als 6 Litern oder eine m Signalwe n von kleiner als 8,0 V soll die Tank reservelampe ausges chaltet werden, Die Schaltvo rgä nge sind in Bild 2-8 dargeste llt.

Bild 2-8: Schaltvorgänge der Tankreservelampe

Für die Ansteuerung der Tankrese rve la mpe interessieren also nur das Überschreiten der Schwe llen .Slgnalwert kleiner 8,0 V" bzw. .Stgualwe rt größe r 8,5 V", die als Ereig nisse bezeichnet werden, und der bisherige Zusta nd der Lampe "A us" bzw . " Ein", In Bild 2-9 s ind die diskreten Zustände " La mpe Aus" und ..Lampe Ein" und die m ög tlehen Übergänge zwische n den Zustände n, denen die entspreche nden Ereignisse zugeo rdnet sind, grafisch dargestellt,

2.3 Eingebettete Systeme

47

"Signalwert > 8,5 V" Legende: Lampe Aus

"Signalwert < 8,0 V"

-

[

Zustand Übergang

Bild 2-9: Zustands-Übergangs-Graf für die Tankreservelampe

Solche Zustands-Übergangs-Grafen, auch Zustandsautomaten genannt, sind eine grafische Notation zur Darstellung diskreter Systeme . Sie werden häufig zur ModelIierung von diskreten Fahrzeugfunktionen eingesetzt. Für eine ausftihrliche Darstellung zu kontinuierlichen und diskreten Signalen und Systemen wird auf die weiterftihrende Literatur , z. B. [37,38], verwiesen .

2.3 Eingebettete Systeme Elektronische Steuergeräte, Sollwertgeber, Sensoren und Aktuatoren bilden ein elektronisches System , das den Zustand der Strecke beeinflusst. Häufig ist das Steuergerät für die Fahrzeuginsassen als Komponente des Gesamtsystems "Fahrer - Fahrzeug - Umwelt" nicht einmal "sichtbar". Wird das Steuergerät beispielsweise ausschließlich für Steuerungs- und Regelungsaufgaben eingesetzt, dann hat es meist keine direkten Benutzerschnittstellen. Dies ist häufig ein Kennzeichen elektronischer Steuergeräte in den Anwendungsbereichen Antriebsstrang, Fahrwerk und Karosserie. Der Fahrer und die Fahrzeuginsassen haben in vielen Fällen nur mittelbaren, oft nur geringen und teilweise auch gar keinen Einfluss auf die Funktionen der Steuergeräte. Die Benutzerschnittstellen zur Erfassung der Führungsgrößen sind fast immer indirekt realisiert und oft eingeschränkt (Bild 2-10) . Systeme mit diesen Merkmalen werden auch als eingebettete Systeme bezeichnet. Aus Sicht des Steuergeräts können Sollwertgeber wie Sensoren zur Erfassung der Benutzerwünsche behandelt werden . In den folgenden Kapiteln werden daher Sollwertgeber, wo es zur Vereinfachung des Verständnisses beiträgt, als Sonderform von Sensoren betrachtet. In ähnlicher Weise werden alle Komponenten zur Rückmeldung von Ereignissen oder Zuständen an den Fahrer - beispielsweise durch optische oder akustische Anzeigen - als Sonderform von Aktuatoren betrachtet. Bei der Funktionsentwicklung für Steuergeräte muss also auch das Übertragungsverhalten der Steuergeräteschnittstellen, sowie das Übertragungsverhalten der Sollwertgeber, Sensoren und Aktuatoren berücksichtigt werden . Die Aktuatoren und Sensoren wiederum stellen häufig selbst Systeme dar, die aus elektrischen, hydraulischen, pneumatischen oder mechanischen und zunehmend auch elektronischen Komponenten aufgebaut sind. Im Falle, dass bei Aktuatoren bzw . Sensoren mit elektronischen Komponenten eine Vor- bzw. Nachverarbeitung stattfindet, wird auch von intelligenten Aktuatoren bzw . Sensoren gesprochen .

2 Grundlagen

48

,,...--------,, , , Umwelt ,: ,-- -- - - - -' t.

-----------:

n:

"

Steuergerät

:0 1

u

Bild 2-10: Steuergerätals cmgcbcuctcs System im Fahrzeug

Das Übe rtrag ungs ve rhalten umfa sst zum e inen da s dynam isch e Verhalt en über der Ze it, a ber auc h das statisc he Verha lten wie den physikalischen Wertebe re ich oder die physik alische A uflösung der übertragen en Signale. Z w isc hen ei ne m ei ngebetteten Sys te m und sei ne r di re kten Umgebu ng, im Fa lle e ines Ste uerge räts a lso der Reg el - ode r Steu erstrec ke. bestehe n immer d ire kte Sch nitts te llen. zw isc hen dem System un d dem Benutze r, z.B . dem Fa hrer ode r den Passagi eren. meis t nu r ind ire kte Schnittste llen. Be i der Soft wa re-E ntw ick lung ruf d ie M ikro cont roll er e ines Ste uerge räts muss au s d iesem G rund e in wichtige r Unterschi ed beac htet werden . Währ end über das dy namisc he Verha lte n der Ste uer- oder Rege lstrecke häufig besti mmte A nnahmen ge mac ht werd en kön ne n. die etwa eine Erfass ung der akt uellen Zus tandsg röße n der Strecke über e ine zyk lische Abtast urig mit feste r ode r var iabler A btastrate erm öglic he n. s ind fU r d ie Erfassung de s Fahrerw unsc hes oft ander e Annahmen vorteilhafte r. So ist be isp ielsweise im Falle von Schalte rn a ls Bed ienel ementen e in Fah rerwunsc h e her a ls e in Ereignis zu verste hen, da s von Ze it zu Ze it ein ma l auft ritt , a uf das da nn abe r umgehend reag iert werden muss.

Im Allgem e inen m Ussen dah er im Mikroco ntro lle r per iod isch e und a periodische Ereignisse vera rbeitet werde n. Ein g rund legen des Ve rstä ndnis des Aufba us. der A rbeitswe ise. der Sc hnitts tellen und de r Programmierung von Mikr ocontrollern. wie sie in Ste uergerä ten verwendet werden . ist de shal b für alle an de r Funktionse ntwicklung beteiligte n Entwickler notwend ig.

2.3. 1 Aufbau vo n l\1ikroconl rollcrn Ein Mik rocontrolle r besteht a us folgend en z usammenw irkenden Kompon enten (B ild 2- 11) {39. 40 . 4 1]: •

:\1ik ro p rozesso r a ls Zent rale inheit (eng l. Ce ntra l Processin g Unit. kur z C PU). Der Mikrop rozessor enthä lt se inerse its Ste uerwerk und Rechen werk. Das Rechenwerk führt ant hmetlsc he und log ische Ope rationen aus. Das Ste uerwerk so rgt für die A usfü hrung de r Befehle a us dem Programm speicher. Dies e rmöglicht die Anpass ung an vie lfält ige. prakti sche A nwe nd ungen durc h Programm ierun g.

2.3 Eingebettete Systeme

49

•

Ein- und Au sgabeeinheiten te ngl. Input/Output. kurz 1/0 ), die den Datenverkehr mit der Umge bung (engl. Periphery) abwickeln. Dazu zählen Ein- und Ausgabegeräte. Schaltungen für die Steuerung von Unterbrechungen (eng!. Interrupts) eines Programms. aber auch die Bussysteme zur Kommu nikation mit anderen Steuergeräten, wie CAN [2].

•

Programm- und Datenspeicher. in dem das Programm. z. B. der Steuerungs- und Regelungsalgorithmus. und die konstanten Parametersätze. z. B. die Steuerungs- und Regelnngsparameter, verlustsicher abgelegt sind. A ls Speichertechnologien dafür eignen sich nichtflüchtige Lesespeicher. Oft ist dieser Spe icher so organisiert. dass Programm und Parametersätze in unterschiedlichen Bereichen dieses Speichers liegen. Es wird daher auch von Programm- und Datenspeicher gesprochen.

•

Date nspeic her mit de n Daten, die sich wäh rend der Abarbeitung des Programms verändern. Dieser Speicherbereich wird deshalb auch Arbeitsspeicher ge nannt. Als Speichertechnologien eignen sich Schreib-l ese-Speicher. Je nach den Anforderungen de r Anwendung kommen flüchtige oder nichtflüchtige Schreib- Lese-Speicher zum Einsatz.

• •

Das Bussystem verbindet die einzelnen Elemente des Mikrocontrollers. Ein Tak tgenera tor (Oszillato r) sorgt dafür. dass alle Operatione n im Mikrocontroller mit einer festge legten Zeitrate erfolgen.

•

Überwach ungsschaltungen. häufig auch als Watchdog bezeichnet. Uberwac hen die Programmabarbeitung. J\likroconlroller J\lik roproll.'ssor

Progra mm - & Datenspeicher

Steuerwerk Reche nwerk 4.R, 16 ode r 32 Bit

Nichtflüc htiger Lesespeicher

T

Daten sp eic her Nichtfl ücht iger & flücht iger

Schreib-Lesespe ieher

,

I

Taktgcncra tor

1

,

"

,

,

, ,

1

1 110 Unterbrechungs-

,

1/0 Ereigniszählcr

steueruri g

)-

1/0 Signalerfassung & -ausgabc mit Zeitbezug

110 Analog-,'

1/0 Digitale

Digita lWandler

A usgänge

Ein-,'

1/0 Ser ielle Schn ittste lle

1 1/0 Bussteuerurig

zur K ommu-

mkation mit

Überwachungs schaltung (Watc hdog )

...

...

Bild 2- 1 1: Aufbau ei nes Mikr ocontrollers [39 )

...

...

externen

(z.B. CAN)

Ba usteinen

...

...

50

2 Grundlagen

Diese verschiedenen Komponenten eines Mikrocontrollers werden zunehmend auf einem Chip integriert. Der Mikrocontroller ist damit für sich alIeine funktionsfähig. Je nach den Anforderungen der Anwendung können zusätzliche, externe Bausteine angeschlossen werden, wie zum Beispiel externe Speichererweiterungen. Deshalb wird häufig zwischen internem und externem Speicher unterschieden .

2.3.2 Speichertechnologien Nachdem bereits die unterschiedlichen Anforderungen an Programm- und Datenspeicher genannt wurden, sollen in diesem Abschnitt die verschiedenen Technologien der Halbleiterspeicher kurz dargestellt werden . Halbleiterspeicher werden eingesetzt zur Aufbewahrung •

von Daten , wie 1I0-Daten, Zuständen und Zwischenergebnissen, die häufig und schnell geschrieben und gelesen werden müssen,

•

des Programms, das meist fest zu speichern ist, und

•

konstanten Parametersätzen, die auch häufig fest zu speichern sind .

Bei Halbleiterspeichern können die folgenden Funktionen unterschieden werden : •

Schreiben von Informationen in den Speicher,

•

kurzzeitiges oder dauerhaftes Aufbewahren von Informationen, sowie

•

Wiederauffinden und Lesen von Informationen aus dem Speicher.

Halbleiterspeicher nutzen physikalische Effekte aus, die zwei verschiedene Zustände eindeutig und leicht erzeugen, sowie erkennen lassen . Der Vorzug der Halbleiterspeicher besteht in ihrer technologischen Kompatibilität mit den in anderen Bereichen eines Mikrocontrollers eingesetzten Komponenten und damit in den Möglichkeiten der Integration . Zur Speicherung von Information werden die Zustandspaare .Jeitend/nichtleitend'' oder "geladen /ungeladen" ausgenutzt. Die zu speichernde Information muss daher in binärer Form vorliegen . Eine solche binäre Informationseinheit heißt Bit (engl. Binary Digit) und kann die logischen Zustände I und 0 annehmen. Nachfolgend werden die wichtigsten Speichertechnologien so erläutert, wie sie bereits genormt sind oder in welcher Bedeutung sie am häufigsten verwendet werden (Bild 2-12). Halbleiterspeicher sind je nach Anwendungsfall bit- oder wortorganisiert. Wort heißt dabei die Zusammenfassung von Bits, die zusammenhängend vom Mikrocontroller verarbeitet werden können. Die Wortlänge ist also gleich der Anzahl der zusammenhängend verarbeiteten Bits . Bei MikrocontrolIern sind Wörter von 4,8, 16,32 oder 64 Bits üblich . 8 Bits werden mit Byte bezeichnet (I Byte = 8 Bits) .

51

2.3 Eingebettete Systeme

Halbleiterspeicher

I

I nichtflücht ige Speicher

I

I

flüchtige Speicher

I

I

Ianwenderprograrnmiertl

herstellerprogrammiert

I

I

auf einem Programmiergerät programmierbar

in der Schaltung programmierbar

I nicht löschbar

I I

UV-löschbar

I

I

I

RO M read only memory

PROM programmable ROM

EPROM erasable PROM

statische Speicher

dynamische Speicher

SRAM static RAM

DRAM dynamic RAM

I

I

elektrisch löschbar

I Flash flash EPROM

EEP ROM electrical EPROM

Bild 2-12: Übersicht der Speichertechnologien [39]

2.3.2.1 Schreib-lese-Speicher •

RAM

Der Kurzzeitspeicher RAM (engl. Random Access Memory) erlaubt den direkten Zugriff auf jeden Speicherplatz. Eine Information kann beliebig oft eingeschrieben und ausgelesen werden . RAM sind flüchtige Speicher (engl. Vo latile RAM). Das bedeutet, dass ohne Betriebsspann ung der Speicherinha lt verloren ge ht. Bei RAM wird zwischen statischen (engl. Static RAM , kurz SRAM) und dynamischen Speichern (engl. Dynamic RAM, kurz DRAM) unterschieden [39] . Statisches RAM wird einmal beschrieben und behält seinen Speicherinhalt, solange die Betriebsspann ung vorhanden ist. Der Speicherinhalt von dynamischem RAM muss periodisch aufgefrischt werden, da sonst durc h Leckströme der Speicherinhalt verloren ge hen würde. Wird die Spannungsversorgung für das RAM mit ei ner zusätzl ichen Batterie gep uffert, so können Daten auch nichtflüchtig gespeichert werden. In diesem Fall spricht man von nichtflüchtigem RAM (engl . Non Vo latile RAM , kurz NV -RAM).

2.3.2.2 Nicht läschbare Festwertspeicher Der Langzeitspeicher ROM (eng I. Read Only Memory) erla ubt einen direkten Z ugriff zu jedem Speicherplatz, dessen Inha lt aber - wie der Name sagt - nur gelesen und nicht geändert werden kann .

52 •

2 Grundlagen ROM/PROM

ROM sind nichttlüchtige Speicher. Der Speicherinhalt bleibt auch ohne Betriebsspannung erhalten . In ihm sind üblicherweise Programmcode - wie die Algorithmen ftir Steuerungs- und Regelungsfunktionen - und konstante Daten - wie die Parametersätze von Steuerungs- und Regelungsfunktionen - gespeichert, die jederzeit abrutbar sind . Die Information kann irreversibel entweder beim Hersteller - bei einem der letzten Herstellungsschritte - oder beim Anwender durch entsprechende Verfahren an speziell vorbereiteten Speichern eingeschrieben werden . Diese programmierbaren Festwertspeicher werden auch PROM (engl. Programmable ROM) genannt.

2.3.2.3 Wiederbeschreibbare Festwertspeicher Es gibt auch Lesespeicher, deren Inhalt gelöscht und durch einen anderen Inhalt ersetzt werden kann . Dazu gehören :

•

EPROM (engl. Erasable PROM)

Dieser wiederbeschreibbare Festwertspeicher kann durch Bestrahlen mit UV-Licht vollständig gelöscht und anschließend neu programmiert werden. Diese Neuprogrammierung ist aber nur mit relativ hohem Aufwand in Spezialgeräten möglich .

•

EEPROM (engl. Electrical EPROM)

Das EEPROM wird auch als E2PROM bezeichnet. Dieser wiederbeschreibbare Festwertspeicher kann elektrisch gelöscht und neu programmiert werden . Das Löschen und Wiederbeschreiben ist entweder auf einer separaten Station oder auch im Steuergerät möglich . Beim EEPROM kann jede Speicherzeile einzeln überschrieben werden . Deshalb wird dieser Speichertechnologie auch als nichttlüchtiger Datenspeicher eingesetzt. Anwendungsbeispiele sind die Abspeicherung adaptiver Kennfelder in der Motorsteuerung nach Abstellen des Motors oder die Abspeicherung von erkannten Fehlern durch Überwachungsfunktionen im so genannten Fehlerspeicher. Der Autbau von Fehlerspeichern wird in Kapitel 2.6 ausftihrlicher dargestellt. Das EEPROM kann auch zur Ablage von SoftwareParametern verwendet werden , die für die Variantensteuerung in der Produktion und im Service von Fahrzeugen benötigt werden . Auf mögliche Verfahren dazu wird in Kapitel 6 ausftihrlich eingegangen.

•

Flash (engl. Flash EPROM)

Eine weiter entwickelte Variante von EPROM und EEPROM ist das Flash , manchmal auch Flash EPROM genannt. Bei diesem Speicher werden mit elektrischen Löschimpulsen (engl. Flash) ganze Speicherbereiche oder auch der komplette Speicherinhalt gelöscht. Anschließend können die gelöschten Bereiche neu programmiert werden. Das Programmieren des Flash-Speichers kann mit einem Programmiergerät durchgeftihrt werden . Der entscheidende Vorteil der Flash-Technologie liegt jedoch darin , dass der FlashSpeicher auch im geschlossenen und im Fahrzeug verbauten Steuergerät mit einem Programmierwerkzeug neu programmiert werden kann . Flash-Technologie wird deshalb überall dort eingesetzt, wo relativ große Datenmengen fest zu speichern, aber im Laufe des Produktlebenszyklus auch zu ändern sind , z. B. als Programm- oder Datenspeicher in Steuergeräten. Verfahren zur Flash-Programmierung werden in Kapitel 6 dargestellt.

2.3 Eingebettete Systeme

53

2.3.3 Programmierung von Mikrocontrollern Das Programm , das der Mikroprozessor eines Mikrocontrollers abarbeitet, ist in der Regel im Festwertspeicher fest vorgegeben und wird nicht für unterschiedliche Anwendungen ausgetauscht. Eine wichtige Ausnahme ist, wie angesprochen, das Laden einer neuen SoftwareVersion im Rahmen eines Software-Updates durch Flash-Programmierung. In diesem Abschnitt wird auf die Programmierung von Mikrocontrollern näher eingegangen. Als Software wird die Gesamtheit der Programme und Daten, die im Speicher eines mikrocontrollergesteuerten Systems abgelegt sind, bezeichnet. Die Programme werden von Mikroprozessoren ausgeführt. In der Software-Entwicklung müssen also die Vorgaben beispielsweise aus den Beschreibungen für Steuerungs- und Regelungsfunktionen in einen auf dem Mikroprozessor ausführbaren Programmcode und einen im Datenspeicher des Mikroprozessors abzulegenden Parametersatz umgesetzt werden .

2.3.3.1 Programm- und Datenstand Der Programmcode wird im Folgenden als Programmstand bezeichnet und muss in den Programmspeicher des Mikroprozessors geladen werden (engl . download) . Der Parametersatz wird im Folgenden als Datenstand bezeichnet und muss in den Datenspeicher des Mikroprozessors geladen werden . Oft wird vereinfachend von der Steuergeräte-Software oder dem Steuergeräteprogramm gesprochen . Dabei muss aber beachtet werden , dass ein Steuergerät auch aus mehreren Mikrocontrollern, etwa Funktions- und Überwachungsrechner, aufgebaut sein kann . Genauer ist daher die Bezeichnung Mikrocontroller-Software und die Unterscheidung zwischen Programm- und Datenstand eines Mikrocontrollers.

2.3.3.2 Arbeitsweise von Mikrocontrollern Für die Programmierung kann zunächst von einem vereinfachten Modell des Mikrocontrollers ausgegangen werden , wie in Bild 2-13 dargestellt. Der Mikrocontroller besteht danach aus dem Mikroprozessor, den Speichern für Befehle (engl. Instructions), auch Programmspeicher genannt, den Speichern für Daten , auch Datenspeicher genannt, sowie den Ein- und Ausgabeeinheiten [39]. Diese Komponenten tauschen Daten- und Steuerinformationen (engl . Data and Controllnformations) über Busse aus . Der Mikroprozessor ist die programmierbare Einheit zur Adressierung und Manipulation von Daten, sowie zur Steuerung des zeitlichen und logischen Ablaufs eines Programms. Die Speicher dienen zur Ablage von Daten und Programmbefehlen. Als Speicher für veränderbare Daten wird ein Schreib-lese-Speicher, z. B. ein RAM-Speicher, benötigt. Als Speicher für Programmbefehle und feste Daten eignen sich Lesespeicher, z. B. ROM-Speicher. Zusätzlich besitzen die meisten Mikroprozessoren einen kleinen , im Mikroprozessor integrierten Speicher, die so genannten Register, für einen schnellen Schreib- und Lesezugriff. Über die Ein- und Ausgabeeinheiten können von außen stammende Informationen eingelesen oder ausgegeben werden . Die Ein- und Ausgabeeinheiten sind in begrenztem Umfang programmierbar, um ihre Funktionalität an die Anwendung anpassen zu können . Typische Einund Ausgabeeinheiten sind Analog-Digital-Wandler zur Eingabe von Daten, sowie Pulswei-

2 Grundlagen

54

tenrnodulationsmod ule und Dlgftal-Analog-Wandler zur Ausga be von Daten. Tlmer werden zum Zählen externer Impulse oder zum Messen der Zeitspanne zwischen Ereignissen eingesetzt. Über seriel le und parallele Schnittstellen kann eine Kommunikation mit externen Komponenten oder anderen Mikrocontrollern realisiert werden. Ein Beispiel ist die digitale Datenkommunikation mit a nderen M ikroco ntrollern über CAN [2]. We itere Funktionen können je nach den Anford erun gen der Anwendun g in den Mikr ocommller integriert werden .

:\1il.; ruClIUI T" lIef

.\ Iik ro prol t"ssur

Kl"chr n.nrL.

l)al l'llsflri ch H

Program m- & Dat enspek her

Nichtflüchtiger & Ilüchtiger

Nichtfluchngcr Lesespeicher

Schrcih-rl.escspeieher

I

I 110

Bus

t:in - & ,\ usItMb......lnheiten

St...u...nI ...rk

. I

I

Eingabe

-

Lege nde: Logische Kommuni kationsverbind ung

A usgabe

Bild 2-13 : Vereinfachter A ufbau eines Mikroc ontrolle rs

2.3.3.3 Hauptoperationen \'On Mikroconrrollern Die Blöcke in Bild 2- 13 ermöglichen die Hauptoperationen des Mlkrocontrollers: • • •

Datenverarbeit ung Datenspeicherung Datenaustausch mit der Umgebung.

Mit diesen Funktionen kan n der Mikrocontroller zum Übertragen von Daten. sow ie zu deren Speicherung und Verarbeitung eingesetzt werden. In den folgenden Abschnitten werden die einze lnen Bausteine des Mikrocen trollers. die diese Operationen ermöglichen. genauer behandelt.

2.3 Eingebettet e Systeme

55

2.3.3 .../ Architektur und Bef ehlssalz von Mikroprozessoren Der Mikroprozessor bearbeitet die von au ßen über die Eingabeeinheiten eingehenden Daten und steuert den Datenfluss. In de n Registern des Mikropr ozessors werde n Operanden. Ergebnisse und Adressen abgelegt. In Bild 2- 14 ist eine typ ische Architektur eines Mikrop rozessors dargestellt [39]. :\likroconlroller :\likroproTessor Steuerwe rk

Ree henwer k

Stellersignale

Immediate-Datum relative Adresse

1 Steuerlogik

1 1 Opcr~nden-

. tt

ii1

regrstcr

1 o peranden-I registcr

r-r-

Befehlsregister Befeh ls

1

adrcssc

Programm- & J)all·nspeichcr

Dat enspeieh er

I

I

Arithmetischlogische Einheit Daten Adressen

Schrclb-rl.csc puffc r

I

Adresspuffcr

Befehls-

I

IlO

Ein- & Ausi:a hl·elnheiten

zeiger

Einszabe I

...

Allsstabc

Bild 2-14: Typische Architektur eines Mikroprozessors [39[

Mögliche Erweiterungen zur Erhöhung der Rechenge schwindigkeit wurden zur Vereinfachung des Verständnisses wegg elassen. Die Architektur kann du rch die Menge aller Register. die dem Programmierer zur Verfügung stehen. beschrieben werden. Selten veränderte Konfigurat ionen werd en durch speziel le Steuerr egister eingestellt. Dadurch sind die Steuerregister eine quasi-statische Erweiterung der Befehle. Das Interrupt-Co ntrolRegister legt zum Beispiel fest. welc he Unte rbrec hungen. so genannte lnterrupts, zugelassen und welche ges perrt werden . Durch weitere Steuerregister kann die Funktionalitä t der Arithmetisch-logischen Einhe it (eng!. Arithmetic Logic Unit. kurz ALU) oder der Ein- und Ausgabee inheiten festgelegt werd en. Manche Op erat ionen können die Abarbeitung des Programms durch den Mikrop rozessor beeinflussen. Wenn zum Beispiel eine Anforderung zur Unte rbrechung. eine Imerrupt-Anforderung. von außen eingeht. kann dies eine Prog rammverzw eigung an eine definierte Speicher-

56

2 Grundlagen

adresse erzeugen. Während der Verarbeitung der dort abgespeicherten, so genannten Interrupt-Service-Routine, können nur Interrupts mit höherer Priorität diese Routine unterbrechen. Alle anderen Interrupt-Anforderungen werden gespeichert und erst nach Beendigung der laufenden Interrupt-Service-Routine bearbeitet. Die dabei anfallenden Zustandsinformationen könnten im Befehlsspeicher zwischengespeichert werden. Dies würde jedoch u. U. zu sehr langen Befehlen führen . Daher werden neben den Steuerregistern spezielle Register in den Mikroprozessor integriert, die den Zustand oder Status des Mikroprozessors speichern. Solche Statusregister sind unter anderem das Programm-Status-Register, das Interrupt-Status-Register oder das Multiplier-Status-Wort. Eine solche in Hardware realisierte Interrupt-Logik wird auch als Hardware-Interrupt-System bezeichnet. Um die Zahl der Lade- und Speicheroperationen des Mikroprozessors zu reduzieren, sind häufig mehrere spezielle Rechenregister, so genannte Akkumulatoren, im Mikroprozessor integriert. Dadurch können Zwischenergebnisse und häufig benötigte Variablen im Mikroprozessor gehalten werden. Die damit mögliche Verringerung der Lade- und Speicheroperationen ermöglicht die Erhöhung der Taktrate und führt auch zu einer Senkung des Strombedarfs des Mikroprozessors. Operandenspeicher Es gibt verschiedene Möglichkeiten, die in arithmetischen Berechnungen oder logischen Operationen zu verknüpfenden Informationen, die so genannten Operanden, vor und nach einer Rechenoperation bereitzustellen. Nach dem Speicherort der Operanden werden folgende Architekturen bei Mikroprozessoren unterschieden : •

Speicher-Speicher-Architektur Die Spe icher-Speicher-Architektur verwendet zum Bere itstellen der Operanden den allgemeinen Schreib-/Lesespeicher, z. B. das RAM . Dabei werden die Speicheradressen der Operanden und des Ergebnisses einer arithmetischen Operation explizit im Befehl verknüpft. So können mit einem einzigen Befehl z. B. zwei Operanden, die beide im RAM abgelegt sind , addiert werden . Das Ergebnis kann dann gleich wieder zurück in den RAMSpeicher geschrieben werden . Die Benennung " Speicher-Speicher-Architektur" ist vom Speicherort der Operanden abgeleitet.

•

Akkumulator-Architektur Die Akkumulator-Architektur besitzt eine im Mikroprozessor integrierte Speicherzelle, die sowohl als Quelle als auch als Ziel jeder arithmetischen Operation fest vorgegeben ist. Diese Speicherzelle wird Akkumulator genannt. N ur die Adresse des zweiten Operanden wird im Befehl codiert. Vor jeder arithmetischen Operation muss der erste Operand durch einen Ladebefehl aus dem Speicher in den Akkumulator kopiert werden . Nach der Operation wird das Ergebnis aus dem Akkumulator zurück in den Speicher kopiert.

•

Speicher-Register-Architektur Bei der Speicher-Register-Architektur (engI. Memory Register Architecture) ist eine ganze Reihe von Registern im Mikroprozessor integriert. Beide Operanden werden explizit im Befehl codiert. Jedoch kann nur einer der beiden Operanden direkt mit der Speicheradresse im Speicher angesprochen werden . Der zweite Operand und das Ergebnis werden in einem der Register adressiert. Ähnlich wie bei der Akkumulator-Architektur muss einer der Operanden vor dem Rechenschritt vom Speicher in ein Register kopiert werden . Nach der Operation wird dann das Ergebnis in den Speicher zurückgeschrieben. Wenn jedoch die Zahl

2.3 Eingebettete Systeme

57

der Register groß genug ist, können Zwischenergebnisse in Registern gehalten werden und müssen nicht ständ ig hin und her kopiert werden. Die Benennung "Speicher-RegisterArchitektur" ist wiederum vom Speicherort der Operanden abgeleitet. •

Register-Register-Architektur Die Register-Register-Architektur (engl . Load Store Architecture) adressiert beide Operanden einer Operation explizit in den Registern. Vor jeder Operation müssen daher beide Operanden erst in die Register geladen werden . Das Ergebnis wird dann wieder in den Speicher zurück kopiert.

Operandenadressen Ein weiteres Unterscheidungsmerkmal ist die mögliche Anzahl von implizit und explizit codierten Adressen. Ein einfaches Beispiel solI dies verdeutlichen . Die Operation C = A + B benötigt drei Adressen : •

Adresse von Operand A

•

Adresse von Operand B

•

Adresse von Ergebnisoperand C

•

Explizite Adressierung Befehlssatz-Architekturen (engl . Instruction Set Architectures), die die freie Wahl dieser drei Adressen erlauben, also die Mögl ichkeit zur expliziten Codierung von drei Adressen bieten, heißen Non- Destructive- Instruction-Set-Architektu r .

•

Implizite Adressierung Da aber drei Adressen häufig eine zu große Zahl von Bits in der Codierung eines Befehls belegen, wird bei vielen Architekturen eine implizite Adressierung benutzt. Bei der impliziten Adressierung wird eine der Adressen der beiden QuelIoperanden auch als Zieladresse verwendet. Zum Speichern des Ergebnisses der Operation wird also die Adresse eines der Quelloperanden benutzt und damit wird dieser überschrieben, d. h., er ist danach zerstört. Dieser Zerstörvorgang hat zur Bezeichnung Destructive-Instruction-Set-Architektur geführt .

Die volIständige Menge der Befehle eines Mikroprozessors wird Befehlssatz genannt. Befehlssatz-Architekturen von Mikroprozessoren unterscheiden sich neben dem Operandenspeicher und den Operandenadressen in vielen weiteren Punkten, etwa in der Länge der Befehle oder in der Art der Befehlsausführung [39]. Bei der hardware-nahen Programmierung sind viele weitere, oft spez ifische Details des eingesetzten Mikrocontrollers zu beachten. Dazu gehören beispielsweise weitere Besonderheiten bei der Verarbeitung von Interrupts, bei der Speicherorganisation, bei der Flash-Programmierung oder verschiedene mögliche Betriebszustände des MikrocontrolIers zur Reduzierung der Stromaufnahme (engl , Power Reduction Modes). Auf diese Punkte wird in den folgenden Kapiteln nicht weiter eingegangen. Stattdessen wird auf die Dokumentation des jeweiligen MikrocontrolIers verwiesen .

2 Grundlagen

58

2.3.3.5 Architektur von Ein- lind Ausgabeeinheuen Die Ein- und A usga bee inhe iten e rmöglic hen es, externe Signale e inz ulese n und Ober ausgehende Signale die zu steuernden Größen zu beeinflussen. Ein- und A usgabeeinheiten ermögliehen dadurch di e Ver knUpfung des Mikroprozessors mit seiner Umwelt. Jede Ein- und A usga-

bee inheit besitzt e inen Ansc hluss an den interne n Bus des Mikrocontrollers und exte rne Anschlüsse, so genannte Pins, an die beispielsweise Sensoren und Aktnatoren angeschlossen werde n können .

Bild 2· 15 zeigt den schematischen Aufbau einer Ein- und Ausgabee inheit [39]. Deren Aufgaben unterteilen sic h in: •

Ko mmunikation mit dem internen Bus des Mikrocontrollers

•

Ko mmunikation mit der Umwe lt

•

Date nsp e icherun g

•

Überwac hung und Ze itste uerung

•

Fehlererkennu ng.

vuk roc cnt rouer .\ 1ikropmzesscr

Da ten speicher

Pr ogr amm- & Date nspeicher

Nic htfl uchtiger &

Nichttlücluigcr Lesespeicher

Flüchtiger Schreib -zl.esespeieher

I

I

Bus

I

1/0

Ein-

s: .\u s~aht't i n hti t j

Datcnrcgistcrl l Steuerr egiste r IIStatw;rcgislcr Steuerlogik

T lutcrruptleitu ng

.I

Eingabe

Ausgabe

Bild 2- 15: Typische Arc hitekt ur ei ne r fi n- und Ausgabe einheit [391

2.3 Eingebettete Systeme

59

Adressierung Nach Art der Adressierung der Ein- und Ausgabeeinheiten wird unterschieden zwischen: •

Isolated-I/O Für den Speicher des Mikroprozessors und den Speicher der Ein- und Ausgabeeinheiten existieren zwei getrennte Adressbereiche. Die Programmierung der Ein- und Ausgabeeinheiten unterliegt starken Einschränkungen, da nur spezielle Befehle für die Ein- und Ausgabeeinheiten verwendet werden können .

•

Memory-Mapped-I/O Der Mikroprozessor, sowie die Ein- und Ausgabeeinheiten besitzen einen Speicher mit gemeinsamem Adressbereich . Das hat den Vorteil , dass die große Anzahl von Befehlen zur Adressierung von Speichern des Mikroprozessors auch für die Ein- und Ausgabeeinheiten verwendet werden kann. Allerdings wird dabei Adressraum belegt, was vor allem bei Mikroprozessoren mit einer Wortlänge von 4 oder 8 Bit nachteilig ist. Hingegen nutzen Mikroprozessoren mit einer Wortlänge von 16 oder 32 Bit in der Regel nur noch MemoryMapped-l/O-Architekturen.

Betriebsart Ein weiteres Unterscheidungsmerkmal von Ein- und Ausgabeeinheiten sind die unterstützten Betriebsarten. Es können vier verschiedene Betriebsarten unterschieden werden : •

Programmed-I/O Die Ein- und Ausgabeeinheit wird direkt vom Mikroprozessor gesteuert. Der Mikroprozessor steuert über ein einziges Programm die gesamte Funktionalität. Dabei muss der Mikroprozessor warten , während eine Ein- und Ausgabeeinheit eine Operation ausführt. Diese Betriebsart wird deshalb nur bei Mikroprozessoren verwendet, die ausschließlich Ein- und Ausgabetätigkeiten ausführen . Dies ist zum Beispiel bei intelligenten Sensoren oder Aktuatoren der Fall.

•

Polled-I/O Die Ein- und Ausgabeeinheit ist in der Lage, eigenständig Operationen auszuführen, wobei die Ein- und Ausgabedaten in speziellen Puffern zwischengespeichert werden . Der Mikroprozessor überprüft periodisch den Zustand der Ein- und Ausgabeeinheit und überträgt bei Bedarf neue Daten. Diese Betriebsart ist vor allem für Mikroprozessoren geeignet, die nur ein durch Software realisiertes Interrupt-System, ein so genanntes Software-InterruptSystem, besitzen.

•

Interrupt-Driven-I/O Die Ein- und Ausgabeeinheit bearbeitet alle Ein- und Ausgabeoperationen eigenständig und signalisiert dem Mikroprozessor über eine so genannte Interrupt-Leitung, wenn neue Daten anliegen oder eine Operation des Mikroprozessors notwendig ist. Der wesentliche Vorteil hierbei ist, dass der Mikroprozessor und die Ein- und Ausgabeeinheiten parallel arbeiten können . Das Programm des Mikroprozessors muss nur unterbrochen werden , wenn die Ein- und Ausgabeeinheit die Unterstützung des Mikroprozessors benötigt.

60 •

2 Grundlagen Direct-Memory-I10-Access (DMA) Die Ein- und Ausgabeeinheiten können in dieser Betriebsart mit dem Speicher ohne eine Beteiligung des Mikroprozessors direkt Daten austauschen . Diese Betriebsart wird vor allem von Mikroprozessoren der oberen Leistungsklasse unterstützt. Ähnlich wie bei der Interrupt-Driven-I/O wird für diese Betriebsart eine Hardware benötigt, die alle anstehenden Anforderungen priorisiert und gegebenenfalls sperrt.

Die Software-Komponenten, die diese hardware-nahen Aspekte der Ein- und Ausgabeeinheiten eines Mikrocontrollers abdecken, werden in AUTOSAR in der Basis-Software, genauer dem Microcontroller Abstraction Layer , zusammengefasst. Die ftir die Kommunikation notwendigen Software-Komponenten werden in Abschnitt 2.5 und 2.6 betrachtet. Ein grundlegendes Verständnis des Interrupt-Systems des Mikrocontrollers ist auch erforderlich, um die Einflüsse auf das Echtzeitverhalten des Mikrocontrollers beurteilen zu können .

2.4 Echtzeitsysteme An die Ausführung von Steuerungs- und Regelungsfunktionen durch den Mikroprozessor - im Folgenden kurz Prozessor genannt - werden wie bereits angesprochen auch zeitliche Anforderungen gestellt. Man spricht daher von Echtzeitsystemen. In diesem Abschnitt werden die notwendigen Begriffe, Grundlagen und der Aufbau von Echtzeitsystemen, insbesondere von Echtzeitbetriebssystemen, behandelt.

2.4. t Festlegung von Tasks Um die verschiedenen Verfahren für die Verwaltung und Zuteilung der Ressourcen eines Prozessors oder eines Netzwerks von Prozessoren beschreiben zu können, ist es vorteilhaft, zunächst alle Aufgaben, die bearbeitet werden sollen , in gleicher und allgemeiner Weise zu betrachten . Auf einem Netzwerk von Prozessoren können mehrere Aufgaben gleichzeitig bearbeitet werden . Jede solche potentiell oder tatsächlich parallel zu bearbeitende Aufgabeneinheit, die von einem Prozessor oder einem Netzwerk von Prozessoren eingeplant und ausgeftihrt werden kann, wird im Folgenden als Task bezeichnet. Dabei ist es zweitrangig, ob die verschiedenen Tasks tatsächlich parallel auf einem Netzwerk von Prozessoren oder quasi parallel auf einem einzigen Prozessor zur Ausftihrung kommen . Die Definitionen in diesem Buch orientieren sich an AUTOSAR [3] und OSEK-OS [17]. Das AUTOSAR-OS basiert auf dem Industriestandard OSEK-OS (ISO 17356-3 [50]), ftihrt hier jedoch einige Einschränkungen und Erweiterungen ein . Anstelle des in der Literatur häufig verwendeten Begriffs Prozess ftir eine parallel zu bearbeitende Aufgabeneinheit wird aus diesem Grund in diesem Buch der BegriffTask verwendet. Ziel dieses Abschnitts ist die Darstellung der Definition und Organisation der Abarbeitung von Tasks abhängig von der Zeit. Beispiel: Verschiedene Tasks der Motorsteuerung In der Motorsteuerung können etwa die Teilfunktionen "Zündung" oder "Einspritzung" oder "Erfassung des Pedal werts" als Tasks aufgefasst werden, die vom Mikrocontroller des Motorsteuergeräts mit festgelegten zeitlichen Anforderungen ausgeftihrt werden müssen . Im Folgenden werden Tasks, wie in Bild 2- 16 als Balken dargestellt.

61

2.4 Echtzeitsys teme Task A .Z nndung'' Task B . Einspritzung"

Task C ..Erfassung Pcdalw cn "

Bild2-16: Verschiedene Tasks der Motorsteuerung

Um nicht unterschiedliche Bezeichnungen im Zusammenhang mit der Abarbeitung einer Task verwenden zu müssen - wie beispielsweise .Z ünden''. .. Einspritzen" oder ..Erfassen" - wird zusammenfassend von der AusfUhrung einer Task gesprochen. Die Ausführung einer Task auf einem Prozessor erfolgt sequentiell. Das bedeutet. der Prozessor führt einen Befehl nach dem anderen aus. Die Reihenfolge der Ausführung der Befehle einer Task durch den Prozessor wird bei allen folgenden Abbildungen durch eine Zeitachse dargestellt. die von links nach rechts eingezeichnet wird. Sollen mehrere Tasks quasi parallel auf einem Prozessor ausgeführt werden. so ist eine zeitliche Aufteilung des Prozessors auf die verschiedenen Tasks erforderlich. Zu bestimmten Zeitpunkten muss zwischen den verschiedenen Tas ks umgeschaltet werden. Diese zeitliche Darstellung der so ge nannten Zuteilung des Prozessors an die verschiedenen Tasks wird als Z uteilungsdiagramm bezeichnet (Bild 2- 17). Beispiel: Zuteilung des Prozessors an drei Tasks Im Bild 2-17 ist ein Zuteilungsdiagramm des Prozessors für die drei Tasks A. B und C dargestellt. Task C Task B Task A

- III

r:Zdtt

Bild 2· 17: Zuteilungsdingramm des Prozessors fü r die drei Tasks A. B und C

Wie in Bild 2· 17 ersichtlich. kann eine Task durch verschiedene Zustände charakterisiert werden. In Bild 2·1 7 ist j eweils der Zeitabschnitt eingezeichnet. zu dem die entsprechende Task auf dem Prozessor ausge führt wird. Dieser Ta skzust an d wird - wie in AUTOSAR-OS und OSEK-OS - in diesem Buch mit ..running" bezeichnet. So ist zu Beginn die Task A im Zustand .ju rming". Nach Umschaltung des Prozessors auf eine andere Task - im Bild 2·17 auf die Task B - nimmt diese Task den Zustand ..running'' ein. und so weiter.

2 Grundlagen

62

Da aber jewe ils nur eine Tas k auf dem Pro zesso r ausgeführt werd e n kann, kann sich zu jedem Zeitpunkt auch nur eine Task im Zustand .runntng'' befi nden. Deshalb muss nach der Umsc haltung die davor ausgeführte Task - im Bild 2- 17 beispielswe ise d ie Tas k A - einen a nderen Z ustand einnehmen.

In den folge nden Abschnitten werde n die verschiedenen, möglichen Zustände von Tas ks, die Ereignisse, die zu einer Ta skum schaltung führen, und verschiedene Strategien zur T askumsc ha lt ung in Echtz e itsystemen dargeste llt.

2..4.2 Fest legun g von Echtzeita nforder unge n Zunächst so ll genau festgelegt werden, wie die ze itlichen Anforderun gen an Tas ks gee ignet besc hrieben werden kön nen. um s ie in Ec htze itsystemen e inplanen und steuern zu kö nnen . Daz u ist e ine ko nsequente Unterscheid ung zwischen Ze itpunkt und Ze itspanne notwendig.

2.-1.2. J Aküvierungs- und Deadli ne-Zeitpunkt ein er Taste Zwe i wesentliche Parameter, die Tasks in Ec htze itsystemen von Tasks in Nic ht-Echtze hsystemen unterscheiden, sind der Aktivierungs- und der Deadline-Zeitpunkt einer Task (Bild

2· ' 8, [42]. Akuvie runcsra tc

Ausfilhrun israre A usführungszeit I

A usführungszeit 2

I Start

Ausführung

von Ta\k A

En~~

~.tj'

I Ende

Resp onse-Zeit 2

Res unse-Zeit I

Rctarive Deadline Zeitpunkt

Absolute

Akuvic rung I

Deadline I

Relative Deadline Zeit punkt der Aktivicrung 2

A bso lute Deadline 2

Hild 2- IK: Festlcgung von Echtzeitanforderungen 1-121

•

Der Akt tvie r ungszelt punkr e iner Tas k ist der Ze itpunkt. zu dem die AusfU hrung der Task in e inem Echtzeitsyste m angesto ßen oder freigege ben wird.

•

Der Deadline-Zeitpunkt e iner Task ist der Ze itpunkt, zu dem die AusfUhrung der Task spä testens abg esc hlossen sein soll.

•

Die Response-Zeit ist die Ze itspanne vom Ze itpunkt der Aktivierung bis zum Ende de r AusfUhrun g e iner Task.

2.4 Echtzeitsysteme

63

•

Die maximal zulässige Response-Zeit wird auch als die relative Deadline einer Task bezeichnet. Der Deadline-Zeitpunkt einer Task, manchmal auch als absolute Deadline bezeichnet, kann durch Addition der relativen Deadline zum Zeitpunkt der Aktivierung berechnet werden .

•

Die Zeitspanne zwischen zwei Aktivierungen einer Task wird auch als Aktivierungsrate bezeichnet. Die Aktivierungsrate darf nicht mit der Zeitspanne zwischen zwei Ausführungen der Task, der so genannten Ausführungsrate. verwechselt werden .

Eine solche Randbedingung zum Zeitverhalten einer Task, die also in Form eines Zeitfensters für die Ausführung angegeben wird, wird Echtzeitanforderung genannt. Im einfachsten Fall kann die Echtzeitanforderung an eine Task durch ihre Aktivierungszeitpunkte und die dazugehörigen relativen oder absoluten Deadlines beschrieben werden . Häufig werden Echtzeitanforderungen an Tasks durch die Aktivierungsrate oder ein Aktivierungsereignis und eine relative Deadline festgelegt. Wichtig ist die Unterscheidung zwischen den Echtzeitanforderungen an eine Task, die Zeitschranken für die Ausführung der Task darstellen , und der benötigten Zeitspanne für die Ausführung , die auch als Ausführungszeit (engl. Execution Time) der Task bezeichnet wird . Wird, wie in Bild 2-18, die Ausführung einer Task nicht unterbrochen , so ist die Ausführungszeit die Zeitspanne zwischen Start und Ende der Ausführung der Task . Wird die Ausführung einer Task unterbrochen, so ergibt sich die Ausführungszeit einer Task als die Summe der Zeitintervalle zwischen Start und Ende der Ausführung der Task, in denen der Prozessor der Task zugeteilt wird.

2.4.2.2 Harte und weiche Echtzeitariforderungen Echtzeitsysteme müssen also zu gegebenen Eingangswerten korrekte Ausgangswerte innerhalb eines vorgegebenen Zeitintervalls zur Verfügung stellen . Häufig werden Echtzeitanforderungen in zwei Klassen eingeteilt: Harte und weiche Echtzeitanforderungen . Es gibt in der Literatur viele verschiedene Definitionen für harte und weiche Echtzeitanforderungen. Dieses Buch orientiert sich an der folgenden Definition , die sich an den FestIegungen in [42] anlehnt. Eine Echtzeitanforderung an eine Task ist hart und die Task ist eine harte Echtzeit-Task, wenn die Validierung gefordert wird, dass die spezifizierten Echtzeitanforderungen der Task immer erfüllt werden . Unter Validierung wird ein Nachweis mittels einer nachprüfbaren und korrekten Methode verstanden . Entsprechend werden alle Echtzeitanforderungen an eine Task als weich bezeichnet und die Task ist eine weiche Echtzeit-Task, wenn ein Nachweis dieser Art nicht gefordert wird. Harte Echtzeitanforderungen an Tasks dürfen also nicht mit der Sicherheitsrelevanz oder der "Geschwindigkeit" von Tasks verwechselt oder gar gleichgesetzt werden . Beispiel : Echtzeitanforderungen an die Funktionen eines Motorsteuergeräts Die Dynamik der zu steuernden oder zu regelnden Subsysteme des Motors ist sehr unterschiedlich. Dies führt zu unterschiedlichen Echtzeitanforderungen an die Funktionen des Motorsteuergeräts.

64

2 Grundlagen Bei den Funktionen, die kurbelwellensynchron und damit mit variabler Abtastrate ausgeführt werden müssen, treten die geringsten Abtastraten bei hohen Motordrehzahlen auf. Die geringsten Abtastraten für die Berechnung der Einspritzung und Zündung liegen abhängig von der Zylinderanzahl und der maximalen Motordrehzahl im Bereich von ca. ein bis zwei Millisekunden. Sehr geringe Abtastraten werden auch an Funktionen zur Lageregelung der Ein- und Auslassventile oder für die brennraumdruckgeführte Motorsteuerung gestellt. Hier treten Abtastraten im Bereich von ca. 50 Mikrosekunden bei der Ventillageregelung und von ca. 5 Mikrosekunden bei der Brennraumdruckerfassung auf. Andere Subsysteme weisen dagegen eine deutlich geringere Dynamik auf und die entsprechenden Funktionen, wie etwa zur Steuerung der Motorkühlung, kommen mit wesentlich größeren Abtastraten aus. Kennzeichnend für das Echtzeitsystem von Motorsteuerungen ist daher eine hohe Anzahl von Tasks, für die verschiedene, teilweise harte Echtzeitanforderungen mit konstanten und variablen Aktivierungsraten vorgegeben sind .

2.4.2.3 Festlegung von Prozessen Eine Menge von verschiedenen Aufgabeneinheiten mit identischen Echtzeitanforderungen kann entweder als eine Menge von Tasks behandelt oder zu einer einz igen Task zusammengefasst werden . In diesem Zusammenhang wird in diesem Buch der Begriff Prozess verwendet. Eine Folge von Prozessen mit identischen Echtzeitanforderungen kann zu einer Task zusammengefasst werden (Bild 2-19) . Die Echtzeitanforderungen werden dabei nicht für die Prozesse vorgegeben, sondern für die Task. Die Prozesse einer Task werden in der statisch festgelegten Reihenfolge nacheinander ausgeführt. Task

r

l I

.-A.-

, I

Proxess 1 yProzps 2\... ~

I

I

I I

I I Start

I Bild 2-19: Festlegung von Prozessen und Tasks

2.4.3 Zustände von Tasks 2.4.3.1 Basis-Zustandsmodell für Tasks nach A UTOSAR-OS und OSEK-OS Wie aus Bild 2-18 ersichtlich, ist zur Einhaltung einer Echtzeitanforderung einer Task nicht zwingend erforderlich, dass der Aktivierungszeitpunkt mit dem Beginn der eigentlichen Ausführung, dem Startzeitpunkt, zusammenfällt. In der Zeitspanne nach der Akt ivierung und vor der Ausführung befindet sich die Task in einem besonderen Zwischenzustand, der etwa dann eingenommen werden kann , wenn der Prozessor gerade mit der Ausführung einer anderen Task besch äftigt ist. Dieser Zustand wird - wie in AUTOSAR-OS und OSEK-OS - in diesem Buch mit "ready" beze ichnet. Dagegen wird der Zustand der Task vor der Akt ivierung und

2.4 Echtzeitsysteme

65

nach der Ausftihrung "suspended" genannt. Diese Zustände und die Übergänge zwischen ihnen können anschaulich in einem Zustandsautomaten dargestellt werden. Bild 2-20 zeigt das so genannte Basis-Zustandsmodell ftir Tasks nach AUTOSAR-OS und OS EK-OS. Die Abkürzung OS steht ftir Operating System.

running

~;",I' start

preempt

[

suspended Bild 2-20 : Basis-Zu standsmodell für Tasks nach AUTOSAROS und OS EK-OS V2.2.1 (eng!. Basic Task Stat e Mod el)

,------~] ~i"," ready

Die Übergänge werden mit .a ctivate'', "start", "preempt" und "tenn inate" bezeichnet. Auf Bild 2-18 übertragen, findet der Zustandsübergang "activate" zum Aktivierungszeitpunkt statt , der Übergang "start" zum Startzeitpunkt und der Übergang "terminate" zum Endzeitpunkt der Ausftihrung. Der Zustandsübergang "preempt" ist ftir Situationen vorgesehen, bei denen mehrere Tasks um den Prozessor konkurrieren . Abhängig von der gewählten Strategie zur Zuteilung des Prozessors kann es dabei vorkommen, dass eine Task im Zustand " running" von einer anderen, konkurrierenden Task vor Beenden der Ausftihrung verdrängt wird . In diesem Fall führt die verdrängte Task den Zustandsübergang " preempt" durch . Verschiedene Zuteilungsstrategien werden in Abschnitt 2.4.4 ausftihrlicher behandelt.

2.4.3.2 Erweitertes Zustandsmodell für Tasks nach A UTOSA R-OS und OSEK-OS Neben diesem Basis-Zustandsmodell ist in AUTOSAR-OS und OS EK-OS ein erweitertes Zustandsmodell ftir Tasks definiert. Es ist in Bild 2-2 I dargestellt und legt einen weiteren Zustand "waiting" für Tasks fest.

running

~i"*

/ waiting

]

start

preempt

"I~ [~

ready

[

suspended

]~'"

Hild 2-21 : Erweitertes Zustandsmodell für Tasks nach A UTOS AR-OS und OSEK-OS V2.2.l (eng!. Extended Task State Model)

Dieser Zustand "waiting" kann von einer Task eingenommen werden, wenn an bestimmten Stellen die Task ihre Ausftihrung unterbrechen und auf das Eintreten eines Ere ig nisses warten

66

2 Grundlagen

muss. bevor die Ausführung fortgesetzt werden kann. Der Überga ng in diesen Wa rtezu stand wird dabei von der Task se lbst angestoßen . Während dieses Wartezu standes kann der Prozessor einer ande ren Task zugeteilt werden . Die zusätz lich notwendigen Zustandsilbergänge werden mi t ,.wait" und •.release- bezeichnet.

2A A Strategien für d ie Zuteilung des Prozessors In diesem Abschnitt sollen verschiedene Strategien zur Z ute ilung (eng!. Sched uling) des Prozessors dargestellt werden. Eine so lche Strategie mu ss in erster Linie eine Auswahl treffen in Sit uationen. bei den en mehrere Tas ks um die Zuteilung eines Prozessor konku rrieren . Ausgehend vom erwe iterten Task-Zustandsmodell ist eine derart ige Situation in Bild 2-22 dargeste llt. Hier konku rriere n fünf Ta sks im Zustand ..ready" um den Prozessor. Allgeme in kann zu jed em Ze itpunkt die Situation dadurch dargestellt werden. dass sich in j edem Zustand eine gew isse Anzahl von T ask s befind en. Man kann unterscheiden zw isc hen der Menge der nicht aktiven Tasks im Zustand .x uspended", der Menge der be reiten T'asks im Zustand ..ready", der Menge der wartend en Tasks im Zustand .waiting'' und der Me nge der ausgeführte n 'tasks im Zusta nd .running''. Die letztgenannte Menge umfasst bei einem einzigen Prozessor natür lich nur ein Element [43]. Au,genlhne Ta,k

• runnmg )

~m" " Menge der

start

wartende n Tasks

Menge der nicht aktiven 'lasks

acuv atc

rclc ase

Legende: Cl Tas k im Zustand ,.su' pc ndcd··

Menge der bereiten

t::I

Tas k im Zustand ..ready"

•

Tasks

~

Task im Zustand ..running:' Tas k im Zustand ..waiting''

ß ild 2-22: Verwaltung VOll Tasks durch Zustandsmengen [43)

Echtzeitbetriebssysteme unterstützen neben de n vorges tellten ve rsc hiede nen Zustands modellen auc h versch iedene Strateg ien zur Zuteilung des Prozessors. Die für die Rea lisierung der Zuteilungsstrategie notwendige Ko mpone nte des Betriebssystems wird als Schedule r bezeichnet. Die für de n Start der Ausführung notwendige Komp onente des Betriebssyste ms wird als Dispateher bezeichnet. Der Aufbau von Echtzeitbetriebssyste me n wird in Kapitel 2.4.5 dargestellt.

2.4 Echtzeitsysteme

67

2...1..1.1 Zuteilung nach der Reihenf olge Eine mögliche Strategie zur Zuteilung des Prozessors an die Menge der bereiten Tasks ist die Zuteilung in der Reihenfolge der Aktivierungen. Die Menge der bereiten Tasks wird daz u in einer Wartesch lange verwaltet. die nach dem First-In-First-Out-Prinzip. kurz FIFO-Prinzip. organisiert ist. Das bedeut et. dass später aktivierte Tasks warten müssen. bis die Ausführung früher akt ivie rter Task s abgeschlossen ist, was unter Umständen fl uch eine längere Ze itspanne in Anspruch nehmen kann .

Zuteilung nach einer Priorit ät

2..1.~.2

Eine sich nicht an der Aktivierungsreihenfolge orientierend e Strateg ie lässt sich etwa dadurch realisieren , dass Zutei lungsrege ln auf eine Ska la von Prioritäten abgebildet und die Menge der bereiten Tas ks nach diesen Prioritäten sortiert wird.

2.~. ~. 3 Zuteilung nach einer komb inierten Reihenf otge- Priorit äts-Strategi e Jeder Task kann eine solche Priorität zugeordnet werden. Dabei entspricht eine höhere Zahl einer höheren Priorität. Tasks mit gleicher Priorität we rden nach dem FIFO-Prinzip verwaltet. Die Menge der bereiten Tasks wird insgesamt nach der in Bild 2-23 dargestellten komb inierten Strategie verwa ltet. Dabei kom mt immer die "ä lteste" Task mit der höchsten Priorität ..oben links" als nächstes zur Ausführung. Zunehmende Priorität

3 2

'lask . die als n ächstes ausgeführt wird

/

I

Artefakt

.:\ ·-·-r~~a~!:~lrs~;~~~~~-· ~ ~,:~c: ·- ·-·-·- ·- ·-·- ·

Prozcsssr hnn ' ß . : ."nuller-

: I der logischen: : : SYSlem-:

: alllnrocnmgcll, : arc'hilcklur

I

-----------' -----------'

_ ._ .-

S _ . y~,,,m .

urchitc ktur iAna~:s;d;;r-liSpC-;iilkalioiil : logisc hen : :llcr lcdmischcn: Systemll System- : :

L ! Tf t!i! $ 1 ._ ~

;

Y

~~~ =&j

+

c

a

/ 1/P,az.'I!'> $ 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