Modellbasierte Entwicklung und Optimierung flexibler ...

Modellbasierte Entwicklung undOptimierung flexibler zeitgesteuerter

Architekturen im Fahrzeugserienbereich

Julian Broy

Karlsruher Institut für Technologie

Fakultät für Elektro- und InformationstechnikInstitut für Technik der Informationsverarbeitung

Modellbasierte Entwicklung undOptimierung flexibler zeitgesteuerter

Architekturen im Fahrzeugserienbereich

Zur Erlangung des akademischen Grades eines

DOKTOR-INGENIEURS

von der Fakultät für

Elektrotechnik und Informationstechnik

des Karlsruher Institut für Technologie

genehmigte

DISSERTATION

von

Dipl. Inf. (Univ.) Julian Broy

geb. in: Dachau

Tag der mündlichen Prüfung: 3. März 2010

Hauptreferent: Prof. Dr.-Ing. Klaus D. Müller-Glaser

Korreferent: Prof. Dipl.-Ing. Dr. Wolfgang Pree

Fürmeine Frau Mariana

meine Eltern Karin und Manfred

meine Großmutter Theresia

Danksagung

Diese Arbeit entstand im Rahmen einer dreijährigen Forschungsarbeit mit dem Institutfür Technik der Informationsverarbeitung der Fakultät für Elektrotechnik der Univer-sität Karlsruhe und dem Forschungs- und Entwicklungszentrum Weissach der Dr. Ing.h.c. F. Porsche AG. Ich möchte mich herzlich bei meinem betreuenden Doktorvater undAufgabensteller Prof. Klaus D. Müller-Glaser für die Übernahme des Erstgutachtensdieser Forschungarbeit bedanken. Sein exzellentes Fachwissen und die ausgezeichneteBetreuung haben äußerst zum Gelingen der Arbeit beigetragen. Weiterhin danke ichProf. Wolfgang Pree für die Übernahme des Zweitgutachtens. In gleicher Weise gebührtmein Dank meinem vormaligen Abteilungsleiter Hans Weiner und meinem Fachabtei-lungsleiter Rüdiger Roppel für die Bereitschaft diese Forschungstätigkeit im Bereich derSerienentwicklung der Vernetzung mit einem Stipendium zu fördern und auszubauen.

Die Vollendung der Arbeit wäre ohne die hilfreiche Unterstützung von einer Reihean Leuten nicht möglich gewesen. Im Speziellen danke ich dafür Jürgen Bortolazzi,Martin Döring, Klaus Echtle, Georg Färber, Daniel Gebauer, Thorsten Koch, MatthiasKühlewein, Dietmar Luz, Paul Milbredt, Nicolas Navet, Clemens Reichmann und RolfZöller.

Im Besonderen möchte ich an dieser Stelle meiner Mutter Karin für das Korrekturle-sen der Arbeit und meinem Vater Manfred für die aufgebrachte Geduld in unzähligengemeinsamen Diskussionen im Umfeld des Automotive Software Engineering innerhalbder letzten Jahre danken. Sein einzigartiges Fachwissen hat mich in meiner Tätigkeit be-stärkt und meiner Forschungsarbeit immer wieder neue Impulse verliehen. Mein Dankgilt auch den Doktorandenkollegen bei Porsche, insbesondere Carsten Bock, Jan Meinelund Matthias Wiese. Aus anfänglicher Kollegschaft wurde Freundschaft.

Wertvolle Beiträge haben die Studenten Marcel Flammer, Thomas Mair, ThibaultSchneider und Thomas Surmann geleistet. Vielen Dank für den unermüdlichen Einsatzund die fantastische Zusammenarbeit.

Mehrere Firmen haben die Arbeit in unterschiedlichen Bereichen unterstützt. MeinDank gilt Aquintos GmbH, dSpace GmbH, Mathworks Inc., TTTech-Automotive GmbHund Vector Informatik GmbH.

Abschließend möchte ich mich nochmals bei meinem engsten Umfeld bedanken fürdie Bereitschaft mich in jeder Phase der Arbeit zu unterstützen. Im Besonderen danke

vii

viii

ich meiner lieben Frau Mariana für die ungebrochene Bereitschaft unser Privatleben inden letzten Jahren in weiten Bereichen dem Interesse dieser Forschungsarbeit unterzu-ordnen. Gleichzeitig bedanke ich mich bei meinen Eltern Karin und Manfred, dass siemir meine Ausbildung ermöglicht haben und mir gemeinsam mit meinen SchwesternVerena und Nora sowie meiner Großmutter Theresia in allen Phasen der Promotiondie Daumen gedrückt haben. An dieser Stelle gebührt der Dank auch allen weiterenPersonen, die zum Gelingen der Arbeit beigetragen haben.

Zusammenfassung

Der kontinuierliche Anstieg des Umfangs elektrisch/elektronischer Funktionen im Au-tomobil zur Realisierung von steuerungs- oder regelungstechnischen Systemen stellteine komplexe Herausforderung an einen Fahrzeughersteller dar. Der Prozess der Sub-stitution mechanischer durch elektrische Komponenten hat in den letzten Jahren zu ei-nem kontinuierlich wachsenden Anteil an Software-Funktionalität im Fahrzeug geführt.Diese ist verteilt auf eine Menge an interagierenden Elektronikkomponenten, genanntSteuergeräte.

Die Systemvernetzung bietet ein etabliertes technisches Mittel zur Verknüpfung vonSteuergerätefunktionen. Bisher wurde dieser Bereich vorrangig durch ereignisgesteuer-te Kommunikationskonzepte auf Basis der Feldbustechnologie CAN realisiert. Durchdie Definition und den geplanten Umstieg auf hochperformante flexible zeitgesteuerteNetzwerktechnologien ergeben sich zukünftig Möglichkeiten um verteilte regelungs-technische Systeme hochpräzise zu realisieren.

Diese Arbeit fokussiert sich auf die Analyse und den Entwurf einer adaptierten Ent-wicklungsmethodik zur Integration verteilter Realzeitsysteme mit flexibler zeitgesteu-erter Bussystemarchitekturen im Automobil. Der Schwerpunkt liegt auf der IntegrationFlexRay-basierter Architekturen unter Berücksichtigung serienrelevanter Anforderun-gen des Fahrzeugherstellers. Auf der Basis der Analyse existierender Ansätze wird dieneue modellbasierte Entwicklungsmethode FlexZOOMED zur vollständigen Spezifikati-on von FlexRay-Systemen innerhalb zu entwickelnder Elektrik-/Elektronikarchitekturenvorgestellt. Mithilfe dieses Ansatzes können die Eigenschaften eines FlexRay-Busseshinsichtlich allgemeiner Gütekriterien einer Elektrik-/Elektronikarchitektur und in Be-zug auf busspezifische Qualitätsmerkmale analysiert werden. Ein weiterer Vorteil derFormalisierung von FlexRay durch Metamodellierung zur Optimierung des komple-xen Netzwerkkonfigurationsprozesses wird dabei herausgearbeitet. Die Tauglichkeit derentwickelten Designmethodik wird durch Applikation auf Basis einer praxisnahen Fall-studie validiert.

Abstract

The continuous increase of functionality in the field of electrical/electronic applicationsby closed loop control systems for automotive systems poses a complex challenge to ve-hicle manufacturers. In recent years the process of substituting mechanical by electricalcomponents led to a steadily growth of software based functionality in vehicles withsolutions distributed over networks of interacting electronic components, the controlunits.

Fieldbus systems provide a powerful concept in creating distributed applicationsfor electronic control units (ECUs). Initially, such networks of ECUs were based on theevent-triggered CAN fieldbus technology. New solutions and functionalities in terms ofhigh-performance closed loop control systems are currently under development. Theyare enabled by the planned next step to high-performance flexible time-triggered net-work technologies as specified by the automotive network communication protocol un-der development by the FlexRay Consortium.

This work focuses on the analysis and design of an adapted development metho-dology for the integration of distributed real-time systems with flexible time-triggeredbus architectures into automotive systems. The emphasis is on the integration of Flex-Ray based electrical electronic architectures by taking into account the constraints andrequirements of the vehicle manufacturing process. Based on the analysis of existingapproaches, the new methodology FlexZOOMED is introduced to support the com-prehensive specification and design of FlexRay systems as part of electrical/electronicautomotive architectures. This approach supports the analysis of the specific factors andproperties of FlexRay bus systems in electrical electronic architectures regarding generalquality criteria. The advantage of the formalization of FlexRay by meta modeling con-cepts is evaluated in terms of an optimization strategy and a semi-automated networkconfiguration process. The suitability of the described design methodology is validatedby a practical case study.

Inhaltsverzeichnis

Inhaltsverzeichnis xiii

Abbildungsverzeichnis xix

Tabellenverzeichnis xxv

1. Einführung 51.1. Vernetzung im Automobil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2. Problemstellung: Integration flexibler zeitgesteuerter Architekturen . . . 91.3. Ziel der Entwicklungsmethodik für flexible zeitgesteuerte Architekturen 111.4. Herausforderungen bei der Entwicklung eingebetteter Systeme im Fahrzeug 121.5. Struktur der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2. Grundlagen 162.1. Elektrik/Elektronik im Fahrzeugumfeld . . . . . . . . . . . . . . . . . . . . 16

2.1.1. Fahrzeugentwicklungsprozess . . . . . . . . . . . . . . . . . . . . . 172.1.2. Komplexitätszuwachs in der E/E-Architektur . . . . . . . . . . . . 172.1.3. Systemklassifikation automotiver E/E-Systeme . . . . . . . . . . . 18

2.2. Automotive Systems Engineering . . . . . . . . . . . . . . . . . . . . . . . . 192.2.1. Überblick und Entwicklungstrends . . . . . . . . . . . . . . . . . . 202.2.2. Systemarchitekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.2.3. Plattformkonzepte und Variantenmanagement . . . . . . . . . . . . 252.2.4. Entwicklungsprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2.4.1. Anforderungsanalyse . . . . . . . . . . . . . . . . . . . . . 292.2.4.2. Systementwurf . . . . . . . . . . . . . . . . . . . . . . . . . 332.2.4.3. Implementierung . . . . . . . . . . . . . . . . . . . . . . . 352.2.4.4. Verifikation und Validierung . . . . . . . . . . . . . . . . . 35

2.2.5. Methoden und Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . 352.2.5.1. Klassifikation . . . . . . . . . . . . . . . . . . . . . . . . . . 362.2.5.2. Notationsformen und Werkzeuge . . . . . . . . . . . . . . 36

2.2.6. Normen und Standards . . . . . . . . . . . . . . . . . . . . . . . . . 38

xiii

xiv INHALTSVERZEICHNIS

2.2.6.1. CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.2.6.2. OSEK/VDX . . . . . . . . . . . . . . . . . . . . . . . . . . 392.2.6.3. AUTOSAR . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.3. Entwicklungsmethoden der verteilten Realzeitentwicklung . . . . . . . . . 442.3.1. Grundbegriffe und Systemkontext . . . . . . . . . . . . . . . . . . . 442.3.2. Einprozessor- und Multiprozessorsysteme . . . . . . . . . . . . . . 472.3.3. Systemspezifikationsebenen . . . . . . . . . . . . . . . . . . . . . . . 532.3.4. Zeitverhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552.3.5. Zuverlässigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

2.4. Grundlagen der Fahrzeugvernetzung . . . . . . . . . . . . . . . . . . . . . 672.4.1. Controller Area Network . . . . . . . . . . . . . . . . . . . . . . . . 672.4.2. Local Area Interconnect . . . . . . . . . . . . . . . . . . . . . . . . . 732.4.3. Media Oriented Systems Transport . . . . . . . . . . . . . . . . . . 732.4.4. FlexRay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

2.5. Grundlagen der modellbasierten E/E-Architekturentwicklung . . . . . . 742.5.1. Methoden und Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . 752.5.2. E/E-Architekturentwicklung mit PREEvision . . . . . . . . . . . . 76

2.5.2.1. Modellierungsebenen . . . . . . . . . . . . . . . . . . . . . 772.5.2.2. Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . 80

2.6. Analyseverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812.6.1. Statische Architekturanalyse . . . . . . . . . . . . . . . . . . . . . . 822.6.2. Dynamische Architekturanalyse . . . . . . . . . . . . . . . . . . . . 85

3. Zeitgesteuerte Architekturen 863.1. Aspekte der Zeitsteuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

3.1.1. Abgrenzung von Ereignis- und Zeitsteuerung . . . . . . . . . . . . 883.1.2. Eigenschaften physikalischer Zeit . . . . . . . . . . . . . . . . . . . 883.1.3. Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903.1.4. Zeitgesteuerte Kommunikationssysteme . . . . . . . . . . . . . . . 913.1.5. Grundmethoden im Entwicklungsprozess . . . . . . . . . . . . . . 94

3.1.5.1. WCET-Analyse . . . . . . . . . . . . . . . . . . . . . . . . . 943.1.5.2. Schedulability-Test . . . . . . . . . . . . . . . . . . . . . . 953.1.5.3. Busscheduling . . . . . . . . . . . . . . . . . . . . . . . . . 96

3.2. Stand der Technik beim Systementwurf . . . . . . . . . . . . . . . . . . . . 973.2.1. Integrierte Entwicklungsmethoden . . . . . . . . . . . . . . . . . . 98

3.2.1.1. DECOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 983.2.1.2. Timing Definition Language . . . . . . . . . . . . . . . . . 993.2.1.3. VIETTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

3.2.2. Verifikation zeitgesteuerter Systeme . . . . . . . . . . . . . . . . . . 1003.2.3. Parametrierungsstrategien . . . . . . . . . . . . . . . . . . . . . . . 1013.2.4. Methodenvergleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

3.3. Konzepte des flexiblen zeitgesteuerten Bussystems FlexRay . . . . . . . . 1033.3.1. Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033.3.2. Physikalische Bitübertragungsschicht . . . . . . . . . . . . . . . . . 104

3.3.2.1. Topologien . . . . . . . . . . . . . . . . . . . . . . . . . . . 1053.3.2.2. Signaldefinition . . . . . . . . . . . . . . . . . . . . . . . . 1073.3.2.3. Signalübertragung . . . . . . . . . . . . . . . . . . . . . . . 1073.3.2.4. Hardwarekomponenten . . . . . . . . . . . . . . . . . . . 110

INHALTSVERZEICHNIS xv

3.3.3. Protokollschicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1103.3.3.1. Protokollausführungskontrolle . . . . . . . . . . . . . . . 1103.3.3.2. Weck- und Aufstartverhalten . . . . . . . . . . . . . . . . . 1113.3.3.3. Uhrensynchronisation . . . . . . . . . . . . . . . . . . . . . 114

3.3.4. Systemparametrierung . . . . . . . . . . . . . . . . . . . . . . . . . . 1153.3.4.1. Konfiguration der elektrischen Bitübertragungsschicht . 1163.3.4.2. Konfiguration des Netzwerkprotokolls . . . . . . . . . . . 1163.3.4.3. Knotenparametrierung . . . . . . . . . . . . . . . . . . . . 117

4. Methodik 1184.1. Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

4.1.1. Anforderungen an die FlexRay-Systementwicklung . . . . . . . . . 1194.1.2. Systemintegration von FlexRay-Architekturen . . . . . . . . . . . . 1234.1.3. Integrationsvorgehen und Optimierungspotentiale . . . . . . . . . 1254.1.4. Folgerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

4.2. Formale Systemmodellierung und -spezifikation . . . . . . . . . . . . . . . 1274.2.1. Modellierungsgrundlagen und Notation . . . . . . . . . . . . . . . 1284.2.2. Konzept der statischen Modellanalyse . . . . . . . . . . . . . . . . . 129

4.2.2.1. Entwurfsprinzipien . . . . . . . . . . . . . . . . . . . . . . 1294.2.2.2. Der Funktionsbegriff und Systemeigenschaften . . . . . . 1304.2.2.3. Funktionsnetzmodellierung . . . . . . . . . . . . . . . . . 1334.2.2.4. Abstraktion und Verfeinerung . . . . . . . . . . . . . . . . 1354.2.2.5. Zeitkettenmodell . . . . . . . . . . . . . . . . . . . . . . . . 1384.2.2.6. Schnittstellenspezifikation . . . . . . . . . . . . . . . . . . 1414.2.2.7. Physikalisches Netz . . . . . . . . . . . . . . . . . . . . . . 1464.2.2.8. Partitionierung . . . . . . . . . . . . . . . . . . . . . . . . . 149

4.2.3. Konzept der dynamischen Modellanalyse . . . . . . . . . . . . . . 1504.2.4. Parameterkonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . 152

4.2.4.1. Klassifikation von Systemmerkmalen . . . . . . . . . . . . 1524.2.4.2. Parameterstrukturierung . . . . . . . . . . . . . . . . . . . 1534.2.4.3. Parameterberechnung . . . . . . . . . . . . . . . . . . . . . 153

4.3. Metamodellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1554.3.1. E/E-Metamodellierung . . . . . . . . . . . . . . . . . . . . . . . . . 1554.3.2. Konzept der FlexRay-Metamodellierung . . . . . . . . . . . . . . . 1564.3.3. Bus- und Knotenparameter . . . . . . . . . . . . . . . . . . . . . . . 157

4.4. Domänenspezifische objektorientierte Modellierung . . . . . . . . . . . . . 1574.4.1. Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1574.4.2. Statische logische Systemarchitektur . . . . . . . . . . . . . . . . . . 1584.4.3. Statische technische Systemarchitektur . . . . . . . . . . . . . . . . 1604.4.4. Dynamisches Verhalten (Protokollebene) . . . . . . . . . . . . . . . 162

4.5. Entwicklungsaspekte flexibler zeitgesteuerter Architekturen . . . . . . . . 1644.5.1. Qualitätsparameter bei der Fahrzeugentwicklung . . . . . . . . . . 1644.5.2. Weck- und Startvorgang . . . . . . . . . . . . . . . . . . . . . . . . . 1704.5.3. Komponentenarchitektur . . . . . . . . . . . . . . . . . . . . . . . . 1704.5.4. Verlässlichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1704.5.5. Systemschnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . 1714.5.6. Globales Netzwerkscheduling . . . . . . . . . . . . . . . . . . . . . 171

4.5.6.1. Applikationssynchrones Busscheduling . . . . . . . . . . 173

xvi INHALTSVERZEICHNIS

4.5.6.2. Applikationsasynchrones Busscheduling . . . . . . . . . . 1734.5.6.3. Designziele . . . . . . . . . . . . . . . . . . . . . . . . . . . 1754.5.6.4. Systemintegration heterogener Busschedulingkonzepte . 175

4.6. Optimierung im Systementwurf . . . . . . . . . . . . . . . . . . . . . . . . 1804.6.1. Optimierungsziele in flexiblen zeitgesteuerten Architekturen . . . 1804.6.2. Systemqualität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1824.6.3. Grundlagen der mathematischen Optimierung . . . . . . . . . . . 1834.6.4. Optimierungsprobleme in FlexRay-Parametersätzen . . . . . . . . 185

4.6.4.1. Formalisierung des Optimierungsbereichs „Statisches Seg-ment“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

4.6.4.2. Formalisierung des Optimierungsbereichs „DynamischesSegment“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

4.6.4.3. Actionpointskalierung im statischen Segment . . . . . . . 1974.6.4.4. Topologieabmessungen und Systemrobustheit . . . . . . 1984.6.4.5. Zielabtastraten und Minimierung von Slotüberhängen . . 2004.6.4.6. Makrotickskalierung im Cluster . . . . . . . . . . . . . . . 201

5. Implementierung und Validierung 2025.1. FlexZOOMED-Implementierungskonzept . . . . . . . . . . . . . . . . . . . 203

5.1.1. Designfluss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2045.1.2. Modellierungsebenen . . . . . . . . . . . . . . . . . . . . . . . . . . 205

5.1.2.1. Anforderungsebene . . . . . . . . . . . . . . . . . . . . . . 2055.1.2.2. FN-Ebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2065.1.2.3. PN-Ebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2075.1.2.4. WIR-Ebene . . . . . . . . . . . . . . . . . . . . . . . . . . . 2095.1.2.5. TOP-Ebene . . . . . . . . . . . . . . . . . . . . . . . . . . . 2095.1.2.6. PK-Ebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

5.1.3. FlexRay-Parametrierungseditor (PE) . . . . . . . . . . . . . . . . . . 2115.1.4. Roundtrip-Engineering . . . . . . . . . . . . . . . . . . . . . . . . . 2125.1.5. Parameteranalysesicht (PA) . . . . . . . . . . . . . . . . . . . . . . . 213

5.2. Vorgehen bei der E/E-Architekturentwicklung . . . . . . . . . . . . . . . . 2145.2.1. Systemintegration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2145.2.2. Statische Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

5.2.2.1. Metrikkonzept . . . . . . . . . . . . . . . . . . . . . . . . . 2155.2.2.2. Regelbasierte Prüfung . . . . . . . . . . . . . . . . . . . . . 217

5.2.3. Dynamische Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 2175.3. Optimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

5.3.1. Statische Segmentauslegung (Nutzdateneffizienz) . . . . . . . . . . 2195.3.2. Dynamische Segmentgröße . . . . . . . . . . . . . . . . . . . . . . . 2205.3.3. Buszyklusauslegung (Nutzdatenvolumen) . . . . . . . . . . . . . . 221

5.4. Fallstudie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2225.4.1. Modellübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

5.4.1.1. E/E-Architekturmodell . . . . . . . . . . . . . . . . . . . . 2225.4.1.2. Variantenmanagement . . . . . . . . . . . . . . . . . . . . 223

5.4.2. Modellanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2255.4.2.1. Basiseigenschaften . . . . . . . . . . . . . . . . . . . . . . . 2255.4.2.2. Topologien . . . . . . . . . . . . . . . . . . . . . . . . . . . 2285.4.2.3. Partitionierung . . . . . . . . . . . . . . . . . . . . . . . . . 233

INHALTSVERZEICHNIS xvii

5.4.2.4. Systemoptimierung . . . . . . . . . . . . . . . . . . . . . . 2345.4.3. Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

6. Zusammenfassung und Ausblick 2376.1. Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2376.2. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Glossar 243

Abkürzungsverzeichnis 251

Literaturverzeichnis 255

Anhang 275

A. Graphische Analyse des Nutzdatenvolumens Nv(x) im statischen FlexRay-Seg-ment 275A.1. Definition des Nutzdateneffizienz-Funktionals Ne(x) . . . . . . . . . . . . 276A.2. Definition der Restriktionsabbildung Ge(x) . . . . . . . . . . . . . . . . . . 277A.3. Definitionsbereich für Nv und Ne . . . . . . . . . . . . . . . . . . . . . . . . 277A.4. Graphische Darstellung des modifizierten Nv . . . . . . . . . . . . . . . . . 277

B. Spline-Koeffizienten und Funktionswerte der Auswahlfunktion 279

C. Parameter Formalisierung 281C.1. Variablendefinitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281C.2. Konstantendefinitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285C.3. α- und β-Parameter (Ne) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286C.4. FlexRay-Parametrierungsrestriktionen . . . . . . . . . . . . . . . . . . . . . 287

D. Fallstudien 290D.1. Eingangsparametersätze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290D.2. FlexRay-Parametersätze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291D.3. Umsetzung von Modellabfragen . . . . . . . . . . . . . . . . . . . . . . . . 292D.4. Automatisches Busscheduling eines Funktionsnetzes . . . . . . . . . . . . 293D.5. Einschränkungen im Parametrierungsprozess . . . . . . . . . . . . . . . . 295

Abbildungsverzeichnis

1.1. Integrationsplattform zur Kopplung von Werkzeugen für eine durchge-hende modellbasierte FlexRay-Applikationsentwicklung . . . . . . . . . . 13

2.1. Vereinfachte Darstellung eines strukturierten Fahrzeugentwicklungspro-zesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2. Entwicklung der Anzahl der Rückrufaktionen von 1998 bis 2007 /[Kra07]/ 182.3. Mängelartbezogene Rückrufaktionen aus Sicht des Kraftfahrt-Bundesamts 182.4. Daten zu der Verteilung der an Fahrzeug-Ausfällen beteiligten Baugrup-

pen /[ADA07]/ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.5. Intelligente Fahrerassistenzsysteme zur Umfelderkennung im Überblick

/[Mic07]/ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.6. Vision zukünftiger Fahrzeugapplikationen aus Zulieferersicht /[BHWJ07]/ 222.7. Steuergeräteverteilung innerhalb des Porsche Carrera Typ 997 . . . . . . . 232.8. Abhängigkeiten und Hierarchien in logischen und technischen Systemar-

chitekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.9. Gegenüberstellung der physikalischen E/E-Architekturvarianten in den

verschiedenen Fahrzeugbaureihen . . . . . . . . . . . . . . . . . . . . . . . 262.10. Kernprozesse in der Softwareentwicklung nach dem V-Modell . . . . . . 272.11. Anforderungsklassifikation für eingebettete Systeme in der Fahrzeugent-

wicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.12. Beispielhafte Verfeinerung der Struktur für nichtfunktionale Anforderun-

gen an E/E-Systeme im Automobil . . . . . . . . . . . . . . . . . . . . . . . 302.13. Verfeinerung der funktionalen Anforderungsstruktur für E/E-Systeme im

Automobil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.14. Ausschnitt aus einer Featuredarstellung in Baumstruktur zur Strukturie-

rung von Systemfeatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.15. Spice-Reifegradlevel in der Fahrzeugindustrie /[Har06]/ . . . . . . . . . . 392.16. Softwarearchitektur auf Basis des OSEK-Konzepts /[OSE07]/ . . . . . . . 402.17. Softwarearchitektur auf Basis des OSEKtime-Konzepts /[OSE01]/ . . . . 412.18. Hardwareabstraktes Konzept des virtuellen Übertragungskanals für Ap-

plikationssoftwarefunktionen /[H. 06]/ . . . . . . . . . . . . . . . . . . . . 42

xix

xx ABBILDUNGSVERZEICHNIS

2.19. Elemente einer AUTOSAR Basissoftwarearchitektur /[H. 06]/ . . . . . . . 422.20. Elemente einer AUTOSAR CAN-Basissoftwarearchitektur /[H. 06]/ . . . 432.21. Prozess und Schnittstellen der AUTOSAR-Entwicklungsmethodik . . . . 432.22. Wirkungsdreieck Fahrer, Fahrzeug und Umwelt . . . . . . . . . . . . . . . 452.23. Szenario eines Car2Car-Kommunikationsnetzwerks /[Car06]/ . . . . . . . 462.24. Steuergerätkomponenten eingebettet in die Fahrzeugumgebung als hete-

rogenes System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462.25. Modularer Aufbau eines OSEK-konformen Steuergeräts mit geschichteten

Abstraktionsstufen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482.26. Funktionale Architektursicht auf ein ESP-Steuergerät . . . . . . . . . . . . 502.27. Systemstrukturdiagramm für das ESP-Funktionsmodul im ESP . . . . . . 512.28. Zustandsmaschine zur Darstellung der Systemmodi des ESP . . . . . . . 512.29. Datenflussdiagramm des Schemas einer Fahrdynamikregelung als Teil ei-

nes ESP-Regelsystems /[Trö05]/ . . . . . . . . . . . . . . . . . . . . . . . . 522.30. Zeitlich geordnetes Interaktionsszenario innerhalb der ESP-Regelfunktion 522.31. Physikalisch verteiltes Mehrprozessorsystem auf OSEK-Basis . . . . . . . 532.32. Systempartitionierung auf Basis von abhängigen Funktionsmodellen . . . 542.33. Klassische Darstellung der Kommunikationsbeziehungen eines Antriebs-

/Fahrwerks-CAN-Bus in Matrixform . . . . . . . . . . . . . . . . . . . . . 552.34. Darstellung der zu analysierenden Aspekte bei der Bitübertragung im

elektrischen Physical Layer (vgl. /[Fle06a] (adaptiert)/) . . . . . . . . . . . 572.35. Verzögerungspunkte für Laufzeit einer Sensor-Aktor-Kommunikations-

strecke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592.36. Zeitverhalten in ereignis-/zeitgesteuerten Netzwerkarchitekturen . . . . . 592.37. Aufgeschaukelte Busbelastung durch Bursts beim parallelen Buszugriff . 602.38. Bereiche zur Erhöhung der Systemrobustheit /[SSV06]/ . . . . . . . . . . 642.39. Konkrete Schnittstellen der E/E-Architektur mit der Systemrobustheit

/[SSV06]/ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652.40. Die E/E-Architektur segmentiert Funktionen über Domänen und besitzt

als Kernkomponente ein zentrales Gateway-Steuergerät /[Mic07]/ . . . . 682.41. Logarithmische Darstellung von maximalen Leitungslängen in Metern

pro angelegte Baudrate in kbit/s . . . . . . . . . . . . . . . . . . . . . . . . 692.42. Allgemeine Buslastentwicklung von drei verschiedenen Fahrzeugmodel-

len mit bis zu fünf Bussegmenten im Zeitraum 2001-2009 . . . . . . . . . 712.43. Vergleich von Bruttobaudrate und genutzter Baudrate mehrerer Baureihen 712.44. Regressionsanalyseergebnisse auf Basis linearer und gebrochen rationaler

Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722.45. Übersicht zu E/E-Modellierungsebenen nach dem PREEvision-Ansatz . . 772.46. PREEvision-Layout und -Sichten . . . . . . . . . . . . . . . . . . . . . . . . 802.47. Typenmodell und Instanzbildung in der FN-Ebene . . . . . . . . . . . . . 812.48. Beiträge zum Zeitverhalten des Systems innerhalb einer Punkt-Zu-Punkt-

Verbindung in einem CAN-Bussystem . . . . . . . . . . . . . . . . . . . . . 84

3.1. Beispielhafte Softwareschichtenarchitektur für ein zeitgesteuertes verteil-tes System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

3.2. Fünfstufiges Zeitkonzept der FlexRay-Technologie . . . . . . . . . . . . . . 933.3. Zusammenhang zwischen den drei Grunddisziplinen bei der Entwick-

lung zeitgesteuerter Architekturen /[Rin02]/ . . . . . . . . . . . . . . . . . 94

ABBILDUNGSVERZEICHNIS xxi

3.4. DECOS System Designfluss . . . . . . . . . . . . . . . . . . . . . . . . . . . 993.5. Beispielhafter Aufbau einer Komponente in einem TDL-Modell /[zei08]/ 993.6. Netzwerktopologievarianten für FlexRay-Architekturen . . . . . . . . . . 1053.7. Blockdiagramm zum internen Aufbau eines Sternkopplers und Beispiel

für dessen Applikation auf einem Steuergerät /[ELM07]/ . . . . . . . . . 1063.8. Asymmetrische Verzögerung am sendenden FlexRay-Bustreiber . . . . . . 1083.9. Asymmetrische Verzögerung am empfangenden FlexRay-Bustreiber . . . 1083.10. Sendesignalverkürzung im FlexRay-Sternkoppler /[Fle04b]/ . . . . . . . 1093.11. Protokollablaufkontrolle POC auf einem FlexRay-Kommunikationscon-

troller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1113.12. Szenario einer Ablaufsequenz des WakeUps mit anschließendem Cluster-

kaltstart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1123.13. Quantisierungsfehler und Mikrotickverteilungsfehler in einem Cluster . . 115

4.1. Wechselseitige Abhängigkeiten der Architektur- und der Netzwerkent-wicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

4.2. Netzwerkintegrationsvorgehen zur Definition einer FlexRay-Architektur . 1214.3. FlexRay-Parameterbaum mit farblicher Abgrenzung unidirektionaler Pa-

rameter (Startparameter) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1224.4. Unterschiede der FlexRay-Paradigmen beim Buszugriffsverfahren . . . . 1234.5. Beispiel für eine mögliche Systemerweiterung eines 4 Knoten-FlexRay-

Systems auf ein 6 Knoten-FlexRay-System mit zusätzlichem Sternkoppler 1254.6. Abstraktionsstufen der modellbasierten Entwurfsmethode MOSES . . . . 1274.7. Idee der integrierten modellbasierten Entwicklung zur statischen und dy-

namischen Analyse eines zeitgesteuerten Systemdesigns . . . . . . . . . . 1284.8. Grunddarstellung eines Systems aus funktionaler Sicht mit arbiträrer An-

zahl an Ein- und Ausgängen . . . . . . . . . . . . . . . . . . . . . . . . . . 1314.9. Signalflussdiagramm zur Darstellung des Zustandsraums eines linearen

Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1334.10. Generalisierungs-/Verfeinerungsrelation zwischen HFCs und FCs . . . . 1364.11. Modelle zum Zeitverhalten in der Funktionsnetzebene . . . . . . . . . . . 1394.12. Transformation eines Datenflussgraphen zu einem Problemgraphen auf

Basis des Zeitkettenansatzes . . . . . . . . . . . . . . . . . . . . . . . . . . . 1404.13. Spezifikationsbereiche des physikalischen Netzwerks auf PN, WIR und

TOP-Ebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1464.14. Partitionierung eines FN auf eine physikalische Netzwerkarchitektur . . . 1504.15. Beispiel für einen gezeiteten Automaten mit lokalen Invarianten /[BY04]/ 1514.16. Hierarchische Darstellung der Basisparameter zur Zusammensetzung ei-

nes FlexRay-Zyklus im Zeitbereich . . . . . . . . . . . . . . . . . . . . . . . 1534.17. Parametermodell zur Berechnung von Modelldaten/Parametern auf Basis

existierender Modelldaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1544.18. Metamodellierungsebenen nach dem MOF-Standard . . . . . . . . . . . . 1554.19. Beispielhafter Ausschnitt aus einem Metamodell zur Beschreibung von

E/E-Architekturen im Fahrzeug . . . . . . . . . . . . . . . . . . . . . . . . 1564.20. Hierarchische Dekomposition der Entwicklungsbereiche zum Systement-

wurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1564.21. Übersicht zu den Teilbereichen der FlexRay-Technologie . . . . . . . . . . 1574.22. Ausschnitt aus einem Funktionsnetz der Antriebs- und Fahrwerksdomäne 159

xxii ABBILDUNGSVERZEICHNIS

4.23. Basisstruktur eines Funktionsnetzes mit (Sender, Sendeport, Signal, Emp-fangsport und Empfänger) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

4.24. Mit der Protokollzustandsmaschine gemappte Parameter . . . . . . . . . . 1624.25. Nutzdateneffizienz als Gütekriterium des FlexRay-Schedules . . . . . . . 1654.26. Berücksichtigung physikalischer Effekte hinsichtlich der gesamten Netz-

werkrobustheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1664.27. Beschränkungen für physikalische FlexRay-Netzwerktopologien . . . . . 1674.28. Performanzaspekte innerhalb des FlexRay-Schedules . . . . . . . . . . . . 1684.29. Untersuchungsbereiche zur Analyse der FlexRay-Systemauslastung . . . 1694.30. Beispiel für synchrones Busscheduling über FlexRay . . . . . . . . . . . . 1744.31. Beispiel für asynchrones Busscheduling über FlexRay . . . . . . . . . . . . 1754.32. Zwei-Knoten-Cluster zur abgleichenden Simulation von asynchronen und

synchronen Regelung über FlexRay . . . . . . . . . . . . . . . . . . . . . . 1764.33. Grundlegende Reglerstruktur mit Sollwert, Regelungsblock und Regel-

strecke (Modell) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1764.34. PID2-Regelkonzept als Basis der implementierten Regelung . . . . . . . . 1774.35. Sollwert und darauf geregeltes Streckenmodell . . . . . . . . . . . . . . . . 1774.36. Auswirkungen von Botschaftsverlusten bei einer partiell asynchron aus-

gelegten FlexRay-Systemkonfiguration . . . . . . . . . . . . . . . . . . . . . 1784.37. Rekonstruktion des ermittelten Botschaftsverlust bei der Übertragung von

Botschaften am asynchronen FlexRay-Steuergerät . . . . . . . . . . . . . . 1794.38. Wechselseitige Abhängigkeit zwischen den allgemeinen Anforderungen

an eine Systemarchitektur und einem FlexRay-Systemdesign . . . . . . . 1814.39. Allgemeine Systemqualität nach dem ISO9126-Standard . . . . . . . . . . 1824.40. Zusammenhang zwischen Nutzdaten-, Botschafts-, Slot-, und statische

Segmentlänge eines FlexRay-Zyklus . . . . . . . . . . . . . . . . . . . . . . 1884.41. Die Performanz-Parameter (rot) korrelieren mit drei unterschiedlichen

Spezifikationsbereichen (logische und technische Systemaspekte) . . . . . 1904.42. Nutzdateneffizienz-Funktional in Abhängigkeit von den Eingangspara-

metern x2 und x7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1914.43. Zusammenhang zwischen Minislot-, Nutzdaten-, Dynamische Slot- und

dynamische Segmentlänge eines FlexRay-Zyklus . . . . . . . . . . . . . . 1934.44. Durch kubische Splines interpolierte Dichtefunktion nX(t) auf Basis der

gemessenen Punktmengen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1954.45. Actionpoint-Skalierung zur Abdeckung der im Cluster vorhandenen Prä-

zision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1974.46. Zusammenhang zwischen der MT-Skalierung und der Actionpointdefini-

tion zur Abdeckung vorgegebener Präzisionswerte . . . . . . . . . . . . . 1984.47. Bedeutung der Netzwerkpräzision bezogen auf die Slotüberhänge eines

FlexRay-Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1994.48. Mikrotickauslegung anhand des vorgegebenen MTs in μs . . . . . . . . . 200

5.1. Integrierte Darstellung des Entwicklungskonzepts FlexZOOMED . . . . . 2035.2. Idee der durchgängigen Integration eines mehrteiligen Entwicklungskon-

zepts im Designfluss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2055.3. Hierarchische Featuremodellierung aus Basis funktionaler Wirkketten . . 2065.4. Ausschnitt aus einem Funktionsnetz der Antriebs- und Fahrwerksdomäne 207

ABBILDUNGSVERZEICHNIS xxiii

5.5. Darstellung der physikalischen Netzwerksicht inklusive Aktorik/Senso-rik und Leistungsversorgung . . . . . . . . . . . . . . . . . . . . . . . . . . 208

5.6. Verkabelungskonzept in der WIR-Ebene inklusive Steckerbelegung . . . . 2095.7. Topologiemodell zur Auslegung der Verkabelungsgrößen des Bordnetzes 2105.8. Komponentenstruktur eines FlexRay-Steuergeräts inklusive seiner Hard-

und Softwaremodule sowie der Busanbindung zu einem aktiven Stern-koppler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

5.9. Exemplarischer Ausschnitt eines Metrikmodells zur Berechnung der ma-ximalen asymmetrischen Transceiververzögerung jeweils bei den Sender-und Empfängersteuergeräten . . . . . . . . . . . . . . . . . . . . . . . . . . 212

5.10. Parameteranalyse auf Grundlage spezifisch skalier- und komponierbarerDiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

5.11. Flexibel komponierbarer Parametrierungseditor mit Zugriff auf die Mo-dellebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

5.12. Ausschnitt aus einer FlexRay-PE-Metriktabelle zur Interpretation einerE/E-Architekturvariante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

5.13. Validierung des FlexZOOMED-Ansatzes . . . . . . . . . . . . . . . . . . . 2155.14. Struktur eines Metrikskripts zur hardwarespezifischen Berechnung von

FlexRay-Parametern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2165.15. Simulation des dynamischen Verhaltens mit gezeiteten Automaten . . . . 2185.16. Systemsimulation auf Basis gezeiteter Automaten . . . . . . . . . . . . . . 2185.17. Graphische Veranschaulichung des errechneten Lösungsvektors xopt,1 mit

der Optimierungstoolbox aus der Matlab/Simulink-Werkzeugkette . . . . 2195.18. Prozentuale Verteilung der abweichenden FlexRay-Parameter . . . . . . . 2265.19. Prozentuale Abweichungen zwischen ausgewählten FlexRay- und Quali-

tätsparametern für sechs untersuchte Fahrzeugederivate . . . . . . . . . . 2275.20. Analyse der physikalischen Bordnetzabmessungen . . . . . . . . . . . . . 2285.21. Topologieschaubilder zu den baureihen- und variantenabhängigen Modi-

fikationen am Kabelbaum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2295.22. Varianten-/BR-abhängige standardisierte Abweichungen im Bordnetz . . 2305.23. Auswirkung der Integration eines DaisyChain-Mittelknotens zwischen

Sternkoppler und Endknoten auf den FlexRay-Parametersatz in einer Ar-chitekturvariante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

5.24. Veränderungen im Parametersatz bei der Eliminierung des Sternkopplersin einer Architekturvariante . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

5.25. Einflüsse der Integration eines zweiten FlexRay-Sternkopplers auf den Pa-rametersatz einer Architekturvariante . . . . . . . . . . . . . . . . . . . . . 232

5.26. Veränderungen im Parametersatz bei einer Modifikation des Sensorikkon-zepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

5.27. Buslasten im statischen Segment für alle Architekturvarianten vor undnach der Makrotickskalierung . . . . . . . . . . . . . . . . . . . . . . . . . . 234

5.28. Veränderung der Systemrobustheit anhand der asymmetrischen Bitlän-genverkürzung unter Einsatz unterschiedlicher Uhrenkonzepte . . . . . . 235

A.1. Die Funktion f (x) = Lx ∗ (x − c(x)) . . . . . . . . . . . . . . . . . . . . . . . 275

A.2. Die Funktion f (x, L) = Lx ∗ (x − c(x)) . . . . . . . . . . . . . . . . . . . . . 276

A.3. Das Nutzdatenvolumen-Funktional Nv(x9, x10) mit dem gefundenen Lö-sungsvektor xopt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

xxiv ABBILDUNGSVERZEICHNIS

D.1. Tabellarische Gegenüberstellung zweier FlexRay-Parametersätze als Er-gebnis zweier unterschiedlicher E/E-Architekurvarianten. . . . . . . . . . 291

D.2. Suchmuster zur Identifikation von Steuergeräten mit FlexRay-Anschluss,die eine physikalische Verbindung zu aktiven Sternkopplern im Systemaufweisen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

D.3. Mathematischer Zyklus bei der Berechnung des gdStaticSlot . . . . . . . 295

Tabellenverzeichnis

2.1. Abgrenzung der reaktiven Systeme von weiteren Systemkonzepten . . . . 202.2. Übersicht der elektrischen Physical Layer Timing-Parameter der TBTF-

Gruppe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582.3. Übersicht und Prognose zur Entwicklung der CAN-Technologie in Seri-

enfahrzeugen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732.4. Gegenüberstellung der drei unterschiedlichen zeitgesteuerten Bussysteme

TTP, TTCAN und FlexRay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752.5. Vertikale semantische Verknüpfung zwischen den Modellierungsebenen

durch explizite Mappingstrukturen . . . . . . . . . . . . . . . . . . . . . . 79

3.1. Tabellarische Auflistung für den Prozess der Herleitung einer FlexRay--Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

3.2. Übersicht zum Umfang der Entwicklungsmethodiken von etablierten ent-wickelten Lösungen im Bereich der zeitgesteuerten Architekturen . . . . 103

3.3. Einflussfaktoren zum Zeitverhalten beim Weck- und Startvorgang einesClusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

4.1. Symbol- und Zeichenerklärung . . . . . . . . . . . . . . . . . . . . . . . . . 1294.2. Beispiel zur Übersicht der Kriterien zur Attributierung eines Funktions-

netzes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1424.3. Funktionsorientierte, modellierungsspezifische, hierarchische und quali-

tätsorientierte Klassifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . 1524.4. Parameterzuordnung zu den Modellierungsaspekten und -ebenen . . . . 1584.5. Übersicht der Kriterien zur Attributierung eines Funktionsnetzes und der

Ableitung von grundlegendenen FlexRay-Eigenschaften . . . . . . . . . . 1604.6. Zuordnung von Physical Layer FlexRay-Parametern zu Modellierungsar-

tefakten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1614.7. Ableitungen aus der dynamischen Verhaltenssicht . . . . . . . . . . . . . . 1634.8. Eigenschaften der Netzwerkknoten . . . . . . . . . . . . . . . . . . . . . . . 1764.9. Mikro-pro-Makrotick für Baudraten und Controllerfrequenzen . . . . . . 201

xxv

xxvi TABELLENVERZEICHNIS

5.1. Übersicht der aus Abs. 5.3.1 und Abs. 5.3.2 bestimmten Parameterwerte . 2215.2. Kardinalitäten der Modellelemente auf logischer und technischer Archi-

tekturebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2235.3. E/E-Konzeptvorlagen und -instanzen des Variantenmanagements . . . . 2235.4. Variantenerzeugung für die drei Fahrzeugderivate auf Basis zweier Aus-

stattungspakete pro Fahrzeugklasse . . . . . . . . . . . . . . . . . . . . . . 2255.5. Kennzahlen zum entwickelten FlexRay-Parametrierungsmodell . . . . . . 2255.6. Übersicht zu den baureihen- und variantenabhängigen Modifikationen

am Kabelbaum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

B.1. Spline-Koeffizienten von sm(t) . . . . . . . . . . . . . . . . . . . . . . . . . 279B.2. Für den Auswahlfunktionswert χm(t) gilt innerhalb des jeweiligen Gül-

tigkeitsintervalls χm(t) = 1, sonst χm(t) = 0 . . . . . . . . . . . . . . . . . 280

C.1. α-Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287C.2. β-Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

D.1. Eingangsparametersatz bei der E/E-Architekturmodellierung . . . . . . . 290

Konzept der Arbeit

Im Zentrum der Untersuchung der Anforderungen an zukünftige vernetzte eingebetteteSysteme im Automobil werden die Leistungsfähigkeit und die Grenzen aktuell einge-setzter Vernetzungstechnologien analysiert.

Erweitert wird die Untersuchung um das flexibel zeitgesteuerte Bussystem FlexRay.In dem Zusammenhang erfolgt eine Erfassung der individuellen Anforderungen diesesflexiblen zeitgesteuerten Bussystems hinsichtlich Entwicklung und Pflege im Serienein-satz.

Identifizierte Lücken im Entwurfsprozess von FlexRay-Netzwerken und deren Inte-gration innerhalb von E/E-Systemarchitekturen werden in einer modellgestützte Me-thode für die FlexRay-Systementwicklung geschlossen.

Die Tragfähigkeit des entwickelten Konzepts wird durch Implementierung und Ana-lyse einer seriennahen Fallstudie validiert.

Stichwörter:

{Requirements Engineering, System Design, System Maintenance,Optimization, Automotive Bus Systems, Modelbased Development,

Domain Specific Modeling, EE Architecture, FlexRay}

Erweiterte Zusammenfassung:

Die modellbasierte Entwicklung flexibler zeitgesteuerter Architekturen ist ein Ansatzzum integrierten Entwurf, der Analyse und Optimierung von zeitgesteuerten Feldbus-systemen innerhalb der Serienfahrzeug-Elektrik/Elektronik. Dieses Vorgehen verknüpftdabei die Vorteile der modellbasierten Elektrik/Elektronikentwicklung im Fahrzeugmit den spezifischen Aufgaben der Integration einer flexiblen zeitgesteuerten Netz-werktechnologie im Fahrzeug. Dazu zählt die durchgängige integrierte Modellierungder Systemanforderungen bezogen auf Fahrzeugausstattungsmerkmale, der elektroni-schen Fahrzeugfunktionen, den Komponenteneigenschaften (Hard-/Software), speziel-len Fahrzeugvorgaben (Geometrie und Energieversorgung) und deren Einbettung inunterschiedlichen Fahrzeugvarianten.

FlexRay bildet eine neue leistungsfähige zeitgesteuerte Feldbustechnologie zur Ver-netzung von Steuergeräten im Fahrzeug. Neben der methodischen Bewältigung derZeitsteuerung stellt der komplexe Konfigurationsprozess eines FlexRay-Systems denAutomobilhersteller vor neue Herausforderungen.

Die modellbasierte Entwicklung hat sich im Automobilbereich als standardisiertesVorgehen im Bereich der modularen Entwicklung von Fahrzeugfunktionen etabliert.Aktuell zeigt sich der Trend zur Erweiterung des modellbasierten Entwurfs in Bezug aufeine integrierte Entwicklung von Elektrik-/Elektronikarchitekturen. Im Fokus steht da-bei in erster Linie die Modellierung und die Bewertung von Elektrik/Elektronikkonzep-ten. Die Integration technischer Anforderungen für die Verifikation der Architekturengegenüber der Funktionsmodulentwicklung bildet einen weiteren Schritt in Richtungder integrierten Architekturentwicklung.

Die Arbeit untersucht welchen Beitrag die modellgestützte Architekturentwicklungzur technischen Integration flexibler zeitgesteuerter Netzwerkarchitekturen leisten kann.Am Beispiel FlexRay zeigt sich ein Zusatznutzen bei der anforderungsgerechten Defini-tion und Objektivierung des komplexen Parametersatzes. Im Serienbereich ergibt sichein Vorteil bei der statischen Analyse der zeitgesteuerten Elektrik-/Elektronik-Architek-tur durch die Anwendung einer frühzeitigen virtuellen Integration von FlexRay-Steuerge-räten im Fahrzeugentwicklungsprozess. Die Methode ist dabei als Erweiterung zu stan-dardisierten Ansätzen wie Simulation, Rapid Prototyping und Hardware-in-the-Loopzu betrachten. Durch den integrierten Ansatz lassen sich zeiteffizient und unabhängigvon der Auslieferung von Musterständen der Spielraum für Entwicklungserweiterun-gen und die Grenzen der Fahrzeugarchitektur untersuchen. Probleme bei der Integrati-on neuer Funktionskomponenten auf einem FlexRay-System und bei der Entwicklungvon FlexRay-Plattformbausteinen lassen sich dabei bereits in der Analysephase iden-tifizieren, bewerten und lösen. Das virtuelle Testen erhöht zudem die Testtiefe des Ge-samtsystems, da auch abstrakte Analysen, beispielsweise im Zeitbereich, durchgeführtwerden können.

Die Arbeit grenzt die Potentiale der statischen Architekturanalyse beim modellba-sierten FlexRay-Systementwurf von den Möglichkeiten der dynamischen Architektur-analyse ab. Offene Bereiche, welche durch Simulation als Weg für die dynamische Ar-chitekturanalyse abgedeckt werden können, werden zur Vervollständigung der Methodeergänzend skizziert und exemplarisch für das Aktivitätsverhalten des Netzwerks dar-gelegt.

Um die Eignung der modellbasierten Architekturentwicklung im Bezug auf die Flex-Ray-Systementwicklung zu bewerten, werden

(1) sämtliche Anforderungen des FlexRay-Systementwurfs zur Abstraktion der kom-plexen Systemkonfiguration zusammengefasst und strukturiert auf geeignete Modellie-rungsdomänen übertragen,

(2) die Einbettung des Konzepts in die Entwicklungsphasen des Fahrzeugentwick-lungsprozesses hinsichtlich Daten- und Modellverfügbarkeit zur Entwurfsraumexplora-tion untersucht,

(3) und resultierende Anforderungen hinsichtlich einer vollständigen technischenUnterstützung der erarbeiteten Methode in einer gekoppelten Werkzeugkette zur Ent-wicklung dargestellt.

Die „virtuelle Fahrzeugentwicklung“ ist aufgrund der Abstraktion von realen Hard--/Softwarelösungen in ihrer Aussagekraft limitiert. Die Tragfähigkeit des Vorgehens unddessen Grenzen werden im Kontext der FlexRay-Systementwicklung reflektiert. EineValidierung wird als statische Analyse im Bereich der Designdefinition der elektrischenBitübertragungsschicht des Protokolls und als dynamische Analyse zur Simulation desZustandsverhalten der Ablaufkontrolle des FlexRay-Controllers durchgeführt.

Ein weiteres Ergebnis dieser Arbeit bildet die Zusammenfassung zweckmäßiger Ein-satzbereiche modellbasierter Architekturentwicklung im Entwicklungsprozess für Flex-Ray-Systeme. Dafür dient eine erstellte seriennahe Fallstudie, welche werkzeuggestütztmit der vorgestellten Methode durchgeführt wird. Die Konformität des Anwendungs-beispiels mit den dargelegten Anforderungen einer FlexRay-Entwicklung wird darge-stellt und die Qualität der Ergebnisse dem erbrachten Aufwand gegenübergestellt.

Abschließend wird die Leistungsfähigkeit der modellbasierten Architekturentwick-lung für FlexRay-Systeme bewertet sowie Einschränkungen und Grenzen kritisch analy-siert. Ein Ausblick für potentielle Erweiterungen im Bereich der Methodik, deren Umset-zung und Anwendung sowie Schwerpunkte der weiteren Entwicklungen werden skiz-ziert.

KAPITEL 1

Einführung

Dieses Kapitel gibt einen Einstieg in das Umfeld der Vernetzung im Automobil als zentrale Grundla-ge dieser Arbeit. Es wird auf die Motivation zur Einführung flexibler zeitgesteuerter Bussysteme in derFahrzeugserienentwicklung eingegangen und die damit verbundenen Problemstellungen und Herausfor-derungen werden dargestellt. Als Konsequenz werden Qualitätsmerkmale einer systematischen Entwick-lungsmethodik für die aufgezeigten Anforderungen formuliert.

Rechnergestützte Systeme bilden gegenwärtig einen wesentlichen Bestandteil vielerAbläufe im Alltag. Neben der Schaffung vollkommen neuartiger Kommunikationsfor-men und Arten der Informationsverknüpfung in allen Anwendungen bis in den Pri-vatbereich hinein, beispielsweise das Internet oder die E-mail, zeigt sich die Bedeutungauch anhand der heute anzutreffenden Vielzahl an elektrisch/elektronischen Systemenin Gebrauchsgegenständen, den eingebetteten Systeme. Darunter fallen kleinere Gerätewie mp3-Abspielgeräte oder Mobiltelefone, aber auch größere Systeme, zu denen un-ter anderem das Automobil zählt. Die Funktionalität von Computersteuerungen wirddem Nutzer aufgrund fehlender oder nur rudimentär ausgeprägter Schnittstellen, zumBeispiel in Form eines Schalters, implizit bereitgestellt. Dadurch wird die starke Ver-breitung komplexer eingebetteter Systeme im Alltag nicht sofort offensichtlich. Da sichder Benutzer oftmals der Technik hinter diesen Systemen nicht bewusst ist, müssen zujedem Zeitpunkt auch kritische oder unerwartete Systemeingaben bedient werden kön-nen. Daraus folgt, dass beliebig komplexe Systemzustände abbildbar werden und dieSoftware jeglichen durch den Benutzer gesteuerten Zustandswechsel behandeln undauch ungültige Eingaben autonom abfangen können muss /[Sim99]/. Gleichzeitig dür-fen durch die Interaktion mit einem Benutzer als potentieller Fehlerquelle in keinemFall menschengefährdende Situationen verursacht werden /[Ber02]/. Diese Problematikkann bereits an einfachen Systemen wie Aufzug- oder Garagensteuerungen nachvollzo-

5

6 KAPITEL 1. EINFÜHRUNG

gen werden, bei denen beispielsweise ein Einklemmschutz in gefährdenden Situationeneingreift und dadurch Risiken für Mensch oder Umwelt minimiert.

Die Entwicklung von eingebetteter Software im Automobil, der so genannten Auto-motive Software, hat in der Fahrzeugbranche in den letzten Jahren mehr und mehr Zu-wachs verzeichnet und bildet mittlerweile einen wesentlichen Faktor zur Bewertung derProduktqualität sowie den Schlüssel für das Gelingen eines entwickelten Autos. Diesliegt nicht zuletzt an der Tatsache, dass durch die bereitgestellten Mittel der Elektro-und Informationstechnik sowie der Informatik neue Geschäftsfelder erschlossen werdenkönnen, welche einem Hersteller neue Möglichkeiten bieten individuelle Fahrzeugfunk-tionen zu entwickeln, um sich gegenüber der Konkurrenz zu differenzieren. Dies liegtan den zahlreichen Verknüpfungen unterschiedlicher Fachdisziplinen, die im Gesamt-system Fahrer, Fahrzeug, Umwelt ihre Anwendung finden.

Ein anschauliches Beispiel ist ACC (Adaptive Cruise Control), ein elektronisches Fah-rerassistenzsystem zur adaptiven Abstandsregelung, um die Distanz zu einem voraus-fahrenden Fahrzeug autonom konstant zu halten. In diesem System kommen Radar-sensoren, Benutzerinformationsanzeigen sowie Motor und Bremse zum Einsatz, die imZusammenspiel aufeinander abgestimmt sein müssen. Einerseits gilt es die gewünschteFahrzeugdistanz zum vorausfahrenden Fahrzeug zu garantieren. Andererseits müssendie Regelsystemeingriffe so gestaltet sein, dass die Abstandskorrekturen der hinterein-ander fahrenden Autos aufeinander abgestimmt bleiben. So lässt sich vermeiden, dasssich Bremsmanöver eines einzelnen Fahrzeugs als Kettenreaktion auf nachfolgende Au-tos verstärkt propagieren, was eventuell zum Stillstand eines Verkehrteilnehmers in die-ser Kette führt /[Raj05]/.

Aus diesem Anwendungsszenario wird offensichtlich, dass sich Ingenieure unter an-derem mit der physikalischen Eigenschaft eines Radarsensors, einem optimalen Visua-lisierungskonzept gegenüber dem Fahrer und der elektrischen Vernetzung der mecha-tronischen Komponenten beschäftigen müssen. Diese vielschichtigen Disziplinen erfor-dern daher ein hohes Maß an Fachwissen, wohldefinierte Schnittstellen zwischen denentsprechenden Fachabteilungen eines Automobilherstellers und einen passend abge-stimmten Entwicklungsprozess.

1.1. Vernetzung im Automobil

Die Einführung von vernetzten Steuergeräten hat in der letzten Dekade die entscheiden-de Weiche zur Schaffung verteilter eingebetteter Systeme im Fahrzeug gestellt. MehrereStandardisierungsgremien (vgl. Abs. 2.2.6) haben diese Entwicklung durch die Schaf-fung einheitlicher Konzepte und Standards begleitet, um den schnell wachsenden Be-reich der Fahrzeugelektrik/-elektronik (E/E) kontrolliert umsetzen zu können.

Aktuell dominieren im Wesentlichen die Bussysteme CAN (Controller Area Network,LIN (Local Area Interconnect) und MOST (Media Oriented Systems Transport) als hersteller-übergreifende Standards die Fahrzeugvernetzung. Während das CAN-Bussystem dengrößten Anteil der Fahrzeug-E/E in den Bereichen Antrieb, Fahrwerk, Karosserie, Kom-fort- und Fahrerassistenzsysteme vernetzt, wird LIN zur einfachen, kostenoptimiertenVernetzung von Systemen mit geringerer Komplextät, beispielsweise intelligente Sen-soren, eingesetzt. MOST ergänzt das gesamte Bordnetz mit der Integration verteilterMultimediasysteme, etwa in Form von Audio- und Navigationsgeräten.

FlexRay spezifiziert ein Hochgeschwindigkeitsbussystem, dessen aktuellen Einsatz-

1.1. VERNETZUNG IM AUTOMOBIL 7

gebiete im Bereich der Fahrerassistenz- und Fahrdynamiksysteme liegen. Dabei stelltdiese Technologie eine Alternative zu den CAN-vernetzten Systemen in den E/E-Domä-nen mit hohem Kommunikationsbedarf dar1.

Während sich die Technologien CAN, LIN und MOST heute bereits in der Fahr-zeugtechnik etabliert haben, zeigt sich bei FlexRay eher verhaltenes Engagement imBereich der breitflächigen Fahrzeugserienentwicklung. Das kann partiell auf den Kos-tennachteil gegenüber CAN aufgrund eines höheren Preises von Hardwarebausteinenzurückgeführt werden. Allerdings könnten bei hinreichend intensiver Auslastung mit-hilfe von FlexRay mehrere CAN-Segmente substituiert werden, was auf Architekture-bene langfristig mit Kostenvorteilen verbunden wäre. Die konservative Zurückhaltunggegenüber einer FlexRay-Serieneinführung liegt in der hohen Komplexität dieser Bus-technologie und der Vorsicht der Fahrzeughersteller gegenüber dem revolutionärentechnischen Fortschritt, der mit dem Einsatz eines zeitgesteuerten Kommunikations-protokolls in einem Serienfahrzeug verbunden ist. Speziell der Integrationsaufwandbeim FlexRay-Serieneinsatz erfordert von den Entwicklern ein wesentlich detaillierte-res Technikverständnis. Das lässt sich unter anderem auf das vom ereignisorientiertenCAN-Busprotokoll fundamental zu differenzierende zeitgesteuerte Grundkonzept ei-nes FlexRay-Feldbussystems zurückführen. Dieser Unterschied und dessen signifikanteAuswirkungen auf den Entwicklungsprozess finden sich breitflächig in den Konzeptendieser Arbeit wieder (s. Kap. 3). Eine zusätzliche integrale Anforderung, die mit dem Pa-radigmenwechsel auf ein zeitgesteuertes Bussystem einhergeht, resultiert aus der wich-tigen Schnittstelle zwischen Fahrzeughersteller und Zulieferer im Entwicklungsprozess.Die Nachhaltigkeit einer FlexRay-Entwicklung lässt sich in dem Zusammenhang durchhinreichend präzise formulierte Vorgaben des Fahrzeugherstellers an seine Zuliefererentscheidend beeinflussen.

Einschränkungen für eine Serienentwicklung

Trotz der intensiven Entwicklung des FlexRay-Standards innerhalb des FlexRay-Kon-sortiums haben sich die Fahrzeughersteller bisher im Bereich der Serienentwicklungaus den genannten Gründen noch zurückhaltend gezeigt. Mit /[Sch07], [HKL07]/ gibtes bisher von zwei großen Fahrzeugherstellern aus dem Premiumsegment offizielle An-kündigungen einer Serieneinführung innerhalb der ersten Dekade der FlexRay-Stan-dardisierung. Folgende Gründe für die zögerliche Einführung erklären diese Entwick-lung:

1. Reifegrad: Verzögerte Fertigstellungen und Überarbeitungen der offiziellen Flex-Ray-Spezifikationen haben gleichermaßen zu notwendigen Neuentwicklungen imBereich der Entwicklungs- und Analysewerkzeuge wie auch der einsetzbarenHard- und Softwarekomponenten geführt. Durch diese Entwicklung ist es füreinen Hersteller schwer abschätzbar, welche Version eines Standards sich lang-fristig für ein Fahrzeugprojekt etablieren wird.

2. Kosten: Trotz der fortschreitenden Entwicklungserfahrung und steigender Nach-frage sind FlexRay-Halbleiterbauteile aktuell teurer als vergleichbare CAN-Kom-ponenten. Da sich die im Vergleich zu CAN deutlich höhere Komplexität der

1Eine Übersicht zur technischen Abgrenzung der beschriebenen Vernetzungstechnologien wird in Abs.2.4 gegeben.


FlexRay-Technologie auch auf die benötigte Chipflächengröße von FlexRay-Kom-ponenten auswirkt, ergeben sich aktuell Kostenvorteile beim Einsatz CAN-ba-sierter Steuergeräte. Da sich der Markt an Anbietern von FlexRay-Kommunika-tionssoftware überschaubar gestaltet, wirkt sich der Kostenvorteil auch in diesemBereich zu Gunsten der CAN-Technologie aus.

3. Anwendungsdomänen: Die ursprüngliche Intension eines Systemeinsatzes im Be-reich sicherheitskritischer Anwendungen, wie der elektrischen Bremse oder Steue-rung (Brake-/Steer-by-Wire (vgl. /[AZL+06]/) hat sich im Laufe der Zeit verscho-ben. Einerseits sind die Entwicklungsaufwände und die Absicherungen eines der-artigen sicherheitskritischen Systems kostspielig und risikobehaftet. Andererseitsträgt das Kommunikationssystem nur partiell zur Gesamtsystemzuverlässigkeitbei, welches auf ergänzende Lösungen im Bereich der Hard-/Softwareentwicklungund des Entwicklungsprozesses angewiesen ist /[Kop97]/. Im Ersteinsatz FlexRayzeigt sich eine starke Fokussierung auf kommunikationslastige Systeme im Bereichder Fahrerassistenz und -dynamik /[Sch07], [HKL07]/.

4. Komplexität: Der technische Umfang und die Komplexität des Bussystems Flex-Ray ist signifikant höher im Vergleich zu den Erfahrungen im Bereich CAN. DieseFeststellung resultiert aus der verstärkten logischen Abhängigkeit der zeitgesteu-erten Bussysteme von der zu entwickelnden Anwendungssoftware und dem in derAutomobilbranche nicht verfügbaren adäquaten Entwicklungsprozess /[Rin02]/.Diese Problematik verstärkt sich durch die teilweise mehrjährige Entwicklungs-erfahrung und evolutionär fortgeschrittene Entwicklung von Fahrzeugfunktionen,etwa im Bereich der Motorelektronik oder der elektronischen Stabilitätskontrol-le, die sich nur mit hohem Aufwand auf ein zeitgesteuertes Konzept übertragenlassen. Auch die physikalischen Anforderungen an ein hochfrequentes elektri-sches Bussystem erfordern kostspielige Absicherungsmaßnahmen während derEntwicklung der technischen Bordnetzarchitektur. Verstärkt werden diese The-men durch die komplexe Parametrierung des FlexRay-Busses, der ein präzises Ver-ständnis der zu entwickelnden Systemarchitektur auf einer Vielzahl der Schichtendes ISO/OSI-Modells /[Zim88]/ erfordert. Aus diesem Grund ist bis heute keinAnwendungsdokument (Application Note) für die systematische Erarbeitung eineszielgerechten FlexRay-Systemdesigns verfügbar.

Motivation für eine Serienentwicklung

FlexRay bietet zum aktuellen Zeitpunkt neben den aufgeführten Einschränkungen aucheinige Vorteile im Serieneinsatz:

1. Reifegrad: Im Rahmen der Weiterentwicklung der FlexRay-Spezifikationen wirddarauf geachtet Fehler zu beseitigen und Funktionen zu ergänzen, die abwärts-kompatibel mit existierenden Lösungen aus den ersten Fahrzeugprojekten verein-bar sind. Gleichermaßen werden die Entwicklungszyklen des Konsortiums ver-größert, um kostspielige Hard- und Softwareentwicklungen bei beteiligten Dritt-zulieferern zu begrenzen. Die Migration der FlexRay-Protokollspezifikation vonVersion 2.1 auf 3.0 benötigte eine Entwicklungsarbeit von vier Jahren.

2. Kosten: Zur Neutralisierung der hohen Hard-/Softwarekosten werden Analysenund Modifikationen auf Architekturebene notwendig. Durch die hohe Performanz

1.2. PROBLEMSTELLUNG: INTEGRATION FLEXIBLER ZEITGESTEUERTERARCHITEKTUREN 9

des FlexRay-Busses gibt es zwei Maßnahmen, die sich bei einer Neupartitionie-rung von Softwarefunktionen anbieten. Prinzipiell lässt sich eine Vielzahl bus-lastiger Komponenten auf einem Bus verbinden. Bei der CAN-Technologie sinddabei mehrere Bussysteme, die über ein Fahrzeuggateway verknüpft werden, er-forderlich. Durch das Replizieren von Signalen durch ein Gateway auf mehrereCAN-Busse relativiert jeder zusätzliche CAN-Bus seinen Kostenvorteil aufgrundentstehender Bandbreiteneinbußen. Zusätzlich lassen sich auf dem FlexRay durchdie hochperformante Busanbindung deutlich leistungsfähigere Steuergeräte ent-wickeln, die eine Vielzahl an Funktionen mehrerer CAN-Steuergeräte integrieren.Im Extremfall führt eine Verschmelzung einzelner Komponenten zur Möglichkeitdes Wegfalls einer Komponente, beispielsweise eines Sensors.

3. Anwendungsdomänen: Der starke Anstieg der Datenkommunikation im Fahrzeuglässt sich mit der evolutionären Erweiterung durch neue CAN-Bussysteme nurmittelfristig kompensieren. Auf lange Sicht wird ein Kommunikationssystem er-forderlich werden, das den Anforderungen an schnelle und umfangreiche Daten-übertragung gerecht wird. Konkrete Anwendungsbereiche sind die Domänen Fah-rerassistenz und Fahrdynamik, die aufgrund ihrer fortgeschrittener Sensorik undDatenfusion genau diesem Anforderungsprofil entsprechen. Da FlexRay bereitseine intensive mehrjährige Aufmerksamkeit im Bereich der Protokollentwicklungund der Bordnetzabsicherung genossen hat, wird sich dieser Standard bedingtdurch seine höhere Performanz etablieren.

4. Komplexität: Die sukzessive Migration der Fahrzeugelektronik auf ein zeitgesteu-ertes Bussystem führt zu notwendigen Adaptionen im Entwicklungsprozess, diefür den Fahrzeughersteller eine große Herausforderung darstellen. Durch die teil-weise langjährige Weiterentwicklung einzelner Steuergeräte bei den Zuliefererngeneriert eine Umstellung auf synchrone Kommunikation zusätzliche Kosten, dieaktuell in einem kostenorientierten Markt schwer argumentierbar sind. Erst wennsich ein FlexRay-Bus am Rande seiner Kapazität befindet, werden entsprechendeMaßnahmen eingeleitet werden. Die Eigenschaften der Busphysik und die Hard-warekomponenten sind mittlerweile intensiv untersucht worden. Allein die Güteverschiedener Busparametrierungen ist weiterhin ein offenes Feld. Mit der Ent-scheidung der beiden Erstanwender im Fahrzeugserienbereich eigene Parameter-sätze zu konzipieren, ist es versäumt worden das eigenständige komplexe The-menfeld einer sinnvollen FlexRay-Konfiguration einheitlich zu bearbeiten. Die da-durch erforderliche Systematik zur Festlegung eines FlexRay-Systems stellt einenSchwerpunkt dieser Arbeit dar.

1.2. Problemstellung: Integration flexibler zeitgesteuerter

Architekturen

Das Kernproblem in der Anwendung flexibler zeitgesteuerter Architekturen bezieht sichauf das unzureichend vorhandene integrale Verständnis des Gesamtkonzepts der zuentwickelnden E/E-Architektur. Der Einsatz der etablierten CAN-Technologie erfordertkeine komplexe Systemparametrierung, die eine dedizierte Berücksichtigung mehrdi-mensionaler Systemaspekte vorsieht. Dazu zählen beispielsweise die physikalischen Ei-genschaften des Netzwerks, etwa Kabelspezifikation und -längen, temporale Eigenschaf-


ten in der Anwendung, etwa der Datendurchsatz pro Zeiteinheit und Latenzzeiten beider Datenkommunikation. Zusätzliche Komplexität ergibt sich durch Anforderungen ei-ner modular konfigurierbaren Ausprägung aller Netzwerkvarianten durch Hinzunahmeund Weglassen von Steuergeräten auf physikalischer Netzwerk- und Fahrzeugfunktio-nen auf logischer Funktionsebene. Speziell die flexible Integration neuer Steuergerätein den Systemverbund in späten Entwicklungsphasen des Gesamtsystems führt bei denstatisch konfigurierten zeitgesteuerten Architekturen zu Schwierigkeiten. Diese Proble-matik ist aus den bisher eingesetzten CAN-Bussen weitgehend unbekannt, da niedri-gere Übertragungsfrequenzen die Bordnetzauslegung weniger heikel beeinflussen unddas ereignisgesteuerte Kommunikationsprinzip keine statisch exakte Einpassung vonÜbertragungszeitpunkten erfordert.

Als Konsequenz lassen sich folgende Aspekte als Problemstellungen bei der Ent-wicklung flexibler zeitgesteuerter Architekturen feststellen:

• Unterstützung sämtlicher physikalischer Bordnetzkonfigurationen

• Flexible Möglichkeiten zur Systemerweiterung

• Zuverlässige und robuste Systemoperation

• Maximierter Datendurchsatz bei minimierten Übertragungszeiten

• Effiziente Systemauslastung

• Zweckmäßig garantierte Systemlebensdauer

Aufgrund der hohen Komplexität einer Systementwicklung mit diesem heterogenen An-forderungsprofil ergibt sich der Bedarf nach einer hinreichenden Entwicklungssystema-tik in der Systementwurfsphase. Vergleichbare Problemstellungen haben sich in der Ver-gangenheit im Bereich des methodischen Hardware-Entwurfs in der Halbleiterentwick-lung, insbesondere beim Hardware-/Software-Codesign gezeigt /[VG92], [Gup95]/. Indiesem Entwicklungsgebiet müssen beim Systementwurf ähnliche Nebenbedingungen,beispielsweise Systemkosten, Echtzeitanforderungen, Durchsatz und Chipflächengröße,berücksichtigt werden. Dabei haben sich mittlerweile ausgereifte Entwicklungsmetho-den etabliert, die vom Einsatz geeigneter Werkzeuge und verwendeter Heuristiken pro-fitieren.

Aktuell wird ein methodischer E/E-Architekturentwurf im Bereich der Fahrzeugse-rienentwicklung kaum oder unzureichend umgesetzt. Der erfolgreiche Umstieg unddie Integration eines flexiblen zeitgesteuerten Bussystems erfordert jedoch Weiterent-wicklungen in diesem Bereich, um die stetig wachsende Komplexität der eingesetztenE/E-Architekturen zukünftig beherrschbar umsetzen zu können. Die nachfolgende Ab-schnitte dieser Arbeit beschreiben das entwickelte Konzept FlexZOOMED (s. Abs. 1.4),eine Entwicklungsmethodik für flexible zeitgesteuerte Architekturen im Fahrzeugseri-enbereich, die einen Beitrag zur Verbesserung der Entwicklungssystematik in der E/E-Architekturentwurfsphase leistet.

1.3. ZIEL DER ENTWICKLUNGSMETHODIK FÜR FLEXIBLE ZEITGESTEUERTEARCHITEKTUREN 11

1.3. Ziel der Entwicklungsmethodik für flexible zeitgesteuerte

Architekturen

Das Ziel der Arbeit besteht in der Konzeption einer Entwicklungsmethodik zum Ent-wurf von verteilten eingebetteten Realzeitsystemen unter Verwendung einer flexiblenzeitgesteuerten Netzwerkarchitektur. Als Netzwerktechnologie bildet FlexRay als neu-artiges gemischt zeit-/ereignisgesteuertes Kommunikationssystem für hochperforman-te Applikationen das zugrunde liegende Feldbussystem. Folgende Prämissen gilt es imFahrzeugserienbereich zu beherrschen, um FlexRay zielgerichtet applizieren zu können.

Flexibilität: Die Definition einer verteilten Anwendung in einem FlexRay-Netzwerk er-fordert hohe Disziplin im Bereich System-Design. Dies kann durch den bekanntenDesignfluss des V-Modells 97 /[KNR05]/ nur eingeschränkt erfolgen. Das zu ent-wickelnde Konzept zielt auf eine flexible aber verzahnt nebenläufige Entwicklung(Concurrent Engineering) ab, welche zusätzlich Iterationsschleifen im Anwendungs-prozess toleriert.

Strukturierbarkeit: Um die hohe Komplexität einer Vielzahl an verteilten Funktionenüber FlexRay zu beherrschen, muss es möglich sein Teilaufgaben zu identifizieren(Separation Of Concerns), welche modular und nebenläufig abgearbeitet werdenkönnen (gemäß dem Prinzip „Divide et impera“). Im Raum steht dabei die Fra-ge nach Systemoptimierung, Wiederverwendbarkeit, Variantenbildung, Entwick-lungszeitverkürzung und die Integration in einen bestehenden Prozess. Ohne eineDekomposition der Systemteile wird eine Zertifizierbarkeit für sicherheitskritischeAnwendungen unmöglich.

Abstraktion: Neben der Dekomposition stellen geeignete, eventuell hierarchische, Ver-feinerungsstufen (Refinement Steps) ein wichtiges Mittel, um ein verteiltes Gesamt-system zu spezifizieren und die Komplexität zu beherrschen. Im Mittelpunkt stehtdie Definition einer FlexRay-basierten Plattform, die den Prozess der Integrationvon Systemkomponenten vereinfacht. Durch Anwendung des Geheimnisprinzipsbei der Softwareentwicklung (Information Hiding) muss das geistige Eigentum Drit-ter (Intellectual Property) geschützt oder von einem Informationsmangel abstrahiertwerden können.

Formalisierung: Die Substitution informeller Spezifikationen durch formale oder halb-formale Beschreibungsmittel stellt die Grundlage dar für die korrekte Systeminter-pretation und Implementierung. Das mächtige Mittel der Simulation kann damitstärker eingesetzt werden. Durch konkrete Modellbildung können auch die Be-reiche Funktionsspezifikation, Architekturstruktur und Kommunikationsverhaltenintegriert entwickelt werden /[FSV99]/.

Anwendbarkeit: Das entwickelte Konzept muss anwendbar (Applicability) bleiben undprozessfähig durchlaufen werden können. Dabei ist es erforderlich entwickelteTeilkonzepte geschickt zu verknüpfen, um Teilergebnisse inkrementell zusammen-zuführen. Eine skalierbar geführte wechselseitige Entwicklung zwischen System-integrator und Komponentenlieferant stellt einen wichtigen Aspekt dar, der bei-spielsweise durch globales und lokales Spezifizieren angestrebt werden kann. Spe-zifische Lösungen sollen generell ausgeschlossen bleiben, damit ein allgemeines


Einsatzspektrum für Komponentenapplikationen in verschiedenen Projekten ge-währleistet wird /[FSV99]/.

Vollständigkeit: Nicht zuletzt muss ein integrierter Ansatz den Anspruch an Vollstän-digkeit erfüllen, um eine hinreichend hohe Qualität zu generieren, da das Gesamt-system eine starke Bindung zu seinen einzelnen Komponenten über das Netzwerkaufweist. Das gilt für nichtfunktionale und funktionale Anforderungen. Dazu kön-nen auch zusätzliche Informationen mithilfe von Schablonen (Patterns) beitragen.

1.4. Herausforderungen bei der Entwicklung eingebetteter

Systeme im Fahrzeug

Eine methodische integrierte Entwicklung von vernetzten eingebetteten Systemen voll-streckt sich über eine Vielzahl an Arbeitsschritten, welche verschiedenen Phasen zuge-ordnet werden können (s. Abb. 1.1).

Knotendesign & Simulation: Jede Funktion eines Steuergeräts wird innerhalb der Kno-tendesignphase2 spezifiziert. Für die Modellierung gemischt diskret/kontinuierlicherRegelungs- oder diskreter Steuerungsaufgaben werden technisch etablierte Beschrei-bungstechniken und zugehörige Werkzeuge zur Simulation und Codegenerierung her-angezogen /[BS06, The07a, The07b]/.

Aus Applikationssicht werden die einzelnen (Teil-)Funktionen selbst wiederum in-nerhalb von Funktionsnetzen zur statischen Strukturmodellierung der Softwarearchi-tektur verbunden. Da die Funktionsmodellierung keine explizite Unterstützung zurBeschreibung der statischen lokalen Funktionsnetzarchitektur vorsieht, konzentrierensich verschiedene Hersteller auf eine entsprechende Werkzeugentwicklung /[BFM05],[dSp07], [HW04]/. In diesem Bereich hat sich jedoch bisher kein einheitlicher Ansatzzur Architekturmodellierung des Funktionsnetzes global durchsetzen können.

Ein Konzept zur Architektursimulation wird in /[Sch06]/ vorgestellt, das sich aberbislang aufgrund mangelnder Werkzeugunterstützung nicht durchsetzen konnte.

Clusterdesign & Scheduling: Jede Buskommunikation lässt sich durch Qualitätsmerk-male, beispielsweise bezogen auf Antwortzeiten und deren Varianz, Datendurchsatz,Bandbreiteneffizienz oder Zuverlässigkeit beurteilen. Zur Berücksichtigung entsprechen-der Designziele müssen entsprechende Zielwerte identifiziert und in einer geeignetenNotation, z.B. als Anforderungsvorlagen (Constraint Templates), formal definiert werden.

Eine neuartige Fragestellung im Fahrzeugserienbereich resultiert aus dem sinnvollenVerpacken von Datenelementen (Signalen) zu Netzwerkbotschaften für die Verteilungin einem zeitgesteuerten Sendeplan des Bussystems (Busschedule). Dessen Ausprägungleitet sich dabei auch von den benötigten Kommunikationsbeziehungen im Netzwerkab.

In Abstimmung mit dem Busschedule werden knoteninterne Systemprozesse (Tasks)separat für jeden Knoten sequentiell angeordnet (Scheduling) und deren Zeitverhaltenbezogen auf maximale Ausführungszeiten (Worst-Case-Execution-Time Analysis) /[KP05]/bestimmt.

2Ein Knoten bildet dabei die logische Abstraktion eines Steuergeräts von dessen Hardware.

1.4. HERAUSFORDERUNGEN BEI DER ENTWICKLUNG EINGEBETTETER SYSTEME IMFAHRZEUG 13

Cluster/Node-

Verlässlichkeits-

verifikation

(FFA, FMEA,FTA)

Code-

generatoren

(C, Ada,

Esterel,..

.)

Code-

generatoren

(HTML, XML,

XLS,...)

Systemanalyse

& Simulation

Relationales Datenbankmanagementsystem

Datenbank

Cluster/Node-

Performanz-

Optimierung

(WCET, Jittering,

Response Times)

Cluster/Node-

Parameter-

verifikation

(Parameter-

konsistenz,

Robustheit)

Integrationsplattform

RapidPrototyp

ing & Dokumentatio

n

Cluster

Sim

ulation&

Test

Optimierung &Verifikation

Node Design & SimulationNode Design & Simulation

Clu

ster

Des

ign

&S

ched

ulin

g

Optimierung & Verifikation

RapidPrototyp

ing & Dokumentatio

n

Cluster

Sim

ulation&

Test

Cluster-Design(Scheduling)

Cluster-Design(Kommunikations-

relationen)

System-Constraints-Template(NichtfunktionaleAnforderungen)

Node-Design(Scheduling)

Funktions-modellierung

(diskret)

Funktions-modellierung

(kontinuierlich/diskret)

Struktur-modellierung (Architektur)

(lokal)

Strukturmodellierung(Architektur)(global)

Abbildung 1.1.: Integrationsplattform zur Kopplung von Werkzeugen für eine durchgehendemodellbasierte FlexRay-Applikationsentwicklung

Optimierung & Verifikation: Zur Einhaltung der definierten Qualitätsmerkmale sinddedizierte Optimierungsverfahren anzuwenden. Diese entsprechen oftmals den Krite-rien allgemeiner mathematischer Mehrzieloptimierungsprobleme. Partielle komplexeEntwicklungsaufgaben, etwa beim Scheduling, die sich nicht in polynomieller Zeit rech-nergestützt lösen lassen (NP-vollständige Probleme), werden dabei oftmals regelbasiertunter Hinzunahme von Informationen (Heuristiken) gelöst. Optimierungsprobleme imGebiet der flexiblen zeitgesteuerten Systeme referenzieren auf das Systemzeitverhalten(Timing). Dabei gilt es die Performanz der Systemantwortzeiten (Response Times) globalauf die maximal tolerierbare Zeitverzögerungen aus funktionaler Sicht (Deadlines) aus-zulegen. Diese Zeiten setzen sich dabei zum Teil aus der WCET (Worst-Case-Execution-Time) und dem Jitter-Verhalten bei der Buskommunikation zusammen (s. Abs. 3.1.5.1,2.3.4).


Die Prüfung des Systems auf funktionale Korrektheit (Verifikation) wird dabei ausSicht der Systemzuverlässigkeit und zur Freigabe des Parametersatzes relevant undlässt sich im Anschluss eines Optimierungsvorgangs durchführen. Dazu zählen de-duktive Verfahren zur Bestimmung der Ausfallwahrscheinlichkeit (Fehlerbaumanalyse(Fault Tree Analysis)), die funktionalen Fehleranalyse (FFA) und die Auswirkungsanaly-se (Failure Mode and Effects Analysis) zur Identifikation von Fehlerursachen /[PASH01],[MMP01]/.

Im Bezug auf die zeitgesteuerten Architekturen muss die Parameterkonsistenz desFeldbusses sowie dessen Toleranzbereiche verifiziert werden, um Aussagen über Ro-bustheit und Lebensdauer des vernetzten Systemverbunds abzuleiten.

Rapid Prototyping & Dokumentation: Mit der Methode des Rapid Prototyping lassensich frühe Entwicklungsstände aus der Hard- und Softwareentwicklung zur prakti-schen Analyse auf Demonstratoren untersuchen /[Spr96], [Sur08]/. Dabei steht unteranderem die Überführung und Anpassung der simulierten Funktionsmodelle auf aus-führbaren Code für eine zugrundeliegenden Hardwareplattform im Vordergrund. Er-gänzend zum Rapid Prototyping lassen sich auch vorhandene Hardwareeigenschaftenund -ressourcen miteinbeziehen, was einen essentiellen Schritt bei der Codegenerie-rung für Seriensysteme darstellt. Bei den zeitgesteuerten Bussystemen interessiert da-bei vorrangig die Analyse der busspezifischen hardwarenahen Softwareschichten (Stan-dardsoftware), etwa der FlexRay-Treiber, das Modul zur Ablaufkontrolle oder Transport-und Netzwerkmanagementprotokolle /[Fla07]/. Im Idealfall lassen sich applikations-spezifische Softwaremodule, beispielsweise eine Dämpferregelung, zusammen mit derStandardsoftware unter Verwendung der spezifizierten Busparameter testen. Wesentli-cher Bestandteil des Rapid Prototypings ist der Einsatz von Codegeneratoren für Hoch-sprachen (bspw. C, Ada, Esterel). Zusätzlich werden sämtliche erzeugten Artefakte inindividueller Ausprägung dokumentiert. Dazu zählen informelle textuelle oder tabella-rische Dokumente, aber auch strukturierte Datenzwischenformate in allgemein etablier-ten Standards der Informationsverarbeitung (HTML, XML). Bei zeitgesteuerten Bussys-temen lässt sich der Schedule beispielsweise tabellarisch visualisieren und dessen Inhal-te für die Konfiguration der Standardsoftware strukturiert ablegen (ASAM FIBEX.xml/[ASA08]/).

Clustersimulation & Test: Zur Ergänzung einer singulären Rapid Prototyping Studiewird eine Cluster Simulation (Restbussimulation) zur Analyse einer isolierten Netz-werkkomponente in virtueller Umgebung des restlichen Netzwerks umgesetzt. Nur indieser Verbundanalyse lässt sich das Verhalten des Gesamtsystems in sukzessiven Er-weiterungen auf Architekturebene analysieren. Entsprechend aufgebaute virtuelle Um-gebungen eignen sich dabei in erster Linie für die schrittweise Überführung eines Ver-bunds von Demonstratoren auf seriennahe Steuergeräteprototypen. Demnach wird derÜbergang zwischen der simulativen Entwicklung und dem konkreten Test eines Prüf-lings fließend gestaltet.

Die dargestellten Aufgabengebiete im Systementwicklungsprozess einer verteiltenflexibel zeitgesteuerten Fahrzeugarchitektur beinhalten eine große Anzahl komplexerArtefakte, die im Laufe der Entwicklung entstehen. Ideal wäre eine Bündelung dieserErgebnisse in einer zugrunde liegenden Plattform, über deren Schnittstellen dediziertekommerzielle und nichtkommerzielle Entwicklungswerkzeuge durch Kopplung inte-griert werden können.

1.5. STRUKTUR DER ARBEIT 15

1.5. Struktur der Arbeit

Dieser Abschnitt gibt als Einführung eine Übersicht zu den aktuellen Vernetzungstech-nologien im Fahrzeug. Dabei werden Problemstellungen im Zusammenhang mit derEntwicklung flexibler zeitgesteuerter Architekturen im Fahrzeugserienbereich identifi-ziert. Ergänzend erfolgt eine initiale Auflistung der Aufgabenbereiche für die verteilteEntwicklung zeitgesteuerter eingebetteter Systeme, aus denen sich grundlegende An-forderungen an eine dedizierte Entwicklungsmethodik ableiten lassen.

In Kapitel 2 werden die Grundlagen der E/E-Entwicklung im Kontext der Automobil-entwicklung betrachtet. Dazu zählen neben dem gelebten Entwicklungsprozess aucheingesetzte Methoden und Werkzeuge sowie angewendete Standards. Die Eigenschaf-ten einer verteilten Echtzeitentwicklung, die Grundlagen der Fahrzeugvernetzung undder Stand der Technik im modellbasierten E/E-Architekturentwurf akzentuieren die fürdiese Arbeit signifikanten Teilbereiche der E/E-Entwicklung im Fahrzeug.

Das wiederkehrende zentrale Themengebiet der flexiblen zeitgesteuerten Architekturenwird in einem eigenständigen Kapitel 3 behandelt. Diese inhaltliche Fokussierung folgtaus dem eigenständigen Charakter zeitgesteuerter Architekturen in Bezug auf derentechnische Funktionsweise und der Implementierung der dafür relevanten Entwick-lungsmethoden. Die spezifischen Eigenschaften der in dieser Arbeit betrachteten flexibelzeitgesteuerten Bustechnologie FlexRay stehen dabei im Vordergrund.

Sämtliche Erkenntnisse aus den vorhergehenden Abschnitten fliessen in die Definiti-on der Entwicklungsmethodik FlexZOOMED (FlexRay Object Oriented Model EnhancedDesign) ein, welche in Kapitel 4 konzeptionell vorgestellt wird. Die Methodik wird formalspezifiziert und die Verknüpfung mit domänenspezifischer objektorientierter Modellie-rung hergestellt. In zwei separaten Abschnitten werden Entwicklungsaspekte für flexi-ble zeitgesteuerte Architekturen am Beispiel FlexRay zusammengefasst und Ansätze fürOptimierungen im Systementwurf aufgezeigt.

In Kapitel 5 wird die Tauglichkeit des erarbeiteten Konzepts durch eine partielle pro-totypische Implementierung der FlexZOOMED-Methodik demonstriert. Möglichkeitenund Grenzen potentieller Optimierungen zeigen sich bei der Analyse einer spezifischentwickelten Fallstudie.

Im letzten Abschnitt werden die erzielten Ergebnisse reflektiert und Schlüsse für diezukünftige Entwicklung der flexiblen zeitgesteuerten Architekturen im Fahrzeug gezo-gen. Als Ergänzung dient der Ausblick mit Ideen zum weiteren Ausbau und Vertiefungder in dieser Arbeit beschriebenen Entwicklungsmethodik.

KAPITEL 2

Grundlagen

Zum Verständnis der nachfolgenden Abschnitte werden in diesem Kapitel die allgemeinen Grundlagendes Arbeitsumfelds beschrieben. Dazu zählt der aktuell gelebte Entwicklungsprozess zur E/E-Entwicklungund dessen zugrunde gelegte Methoden, Werkzeuge und Standards. Vertieft werden die Aspekte der ver-teilten eingebetteten Realzeitentwicklung und die dabei eingesetzten Netzwerktechnologien. Abschließendwerden aktuelle Entwicklungen im Bereich des modellbasierten E/E-Architekturentwurfs charakterisiert,die in späteren Kapiteln dieser Arbeit Bedeutung erlangen.

In der Automobilentwicklung hat sich mittlerweile aufgrund des hohen Softwarean-teils in den E/E-Systemen eines Fahrzeug die Notwendigkeit ergeben die Entwicklungs-prozesse der E/E-Entwicklung an etablierte Vorgehen in der allgemeinen Softwareent-wicklung zu adaptieren. Dieser Trend wird ersichtlich durch die Themenbereiche dereingesetzten Vorgehensmodelle, Methoden, Werkzeuge und Standards. Im Wesentli-chen sind diese Entwicklungen durch die Phasen der Steuergerätespezifikation, -im-plementierung und -test geprägt. Speziell die Bereiche der verteilten Realzeitentwick-lung mit spezifischen Anforderungen sowie der strukturierten modellbasierten E/E-Architekturspezifikation und -prüfung sind allerdings aktuell noch in der Initialphaseim Bereich der Serienentwicklung. Diese erwähnten Themen werden in den nächstenAbschnitten behandelt.

2.1. Elektrik/Elektronik im Fahrzeugumfeld

Zur Abgrenzung der Zieldomäne der E/E-Entwicklungsmethoden im Fahrzeugumfeldwird initial eine Übersicht zum allgemeinen Fahrzeugentwicklungsprozess eines Fahr-zeugherstellers gegeben. Weiterhin wird die Bedeutung der Domäne der E/E-Architek-tur im Fahrzeug herausgearbeitet und die Eigenschaften E/E-unterstützter Funktionali-

16

2.1. ELEKTRIK/ELEKTRONIK IM FAHRZEUGUMFELD 17

tät im Fahrzeug auf Systemebene zusammengefasst.

2.1.1. Fahrzeugentwicklungsprozess

Jeder Fahrzeughersteller operiert nach einem für sich individuell konzipierten Fahrzeu-gentwicklungsprozess (s. Abb. 2.1).

Rahmen-heft

Form Produktions-freigabe

SOP

Inital-phase

System-definition

System-verab-

schiedung

Lasten-heft

Vorproto-typen-aufbau

Muster-aufbau

Vorgabe

Konzeptspezi-fikationsphase

System-konzeptphase

Systemproto-typenphase

System-entwurfsphase

System-freigabephase

Systemaus-lieferungsphase

BaustufenVorproto-typen

Serien-musterphasen

39 38 37 36 35 34 32 31 30 29 28 27 25 24 23 22 21 20 19 18 17 15 14 13 11 10 9 8 7 6 5 4 3 212 1263340 16

Ziel-katalog

Monate vor SOP

Abbildung 2.1.: Vereinfachte Darstellung eines strukturierten Fahrzeugentwicklungsprozesses

Dadurch lassen sich die unterschiedlichen Entwicklungsdomänen je nach Struktu-rierungsform (bspw. E/E, Antrieb, Karosserie, etc.) aber auch die unterschiedlichen Or-ganisationseinheiten prozesstechnisch verknüpfen. Der Fahrzeugentwicklungsprozessstellt einen fundamentalen Bestandteil der Fahrzeugentwicklung dar, da einerseits ver-schiedene Fachbereiche unterschiedliche Entwicklungszeiten und -etappen benötigenund andererseits Entwicklungsergebnisse zu dedizierten Zeitpunkten (Quality Gates)synchronisiert werden müssen. Zu diesen wichtigen Entwicklungszeitpunkten lassensich frühzeitig und iterativ Schwierigkeiten einer Fahrzeugentwicklung evident nach-weisen. Potentielle Fehler werden analysiert und gegebenenfalls Abhilfemaßnahmeneingeleitet.

Konkret lässt sich der Fahrzeugentwicklungsprozess in zwei Phasen untergliedern.Während am Anfang in der Vorentwicklung die Produktplanung (Konzeptfindung, -verabschiedung und -spezifikation) im Vordergrund steht, so liegt in der eigentlichenEntwicklungsphase die Konzentration auf der iterativen Entwicklung und Prüfung vonMusterständen.

Da der Fahrzeugentwicklungsprozess sämtliche Organisationseinheiten eines Unter-nehmens in ihrer Operation betrifft und einen mehrjährigen Entwicklungszeitraum um-fasst, ist eine strikte Einhaltung der dort definierten Entwicklungsschritte essentiell füralle Fachbereiche.

2.1.2. Komplexitätszuwachs in der E/E-Architektur

Aufgrund der kontinuierlich gestiegenen technischen Gesamtkomplexität in Serienfahr-zeugen hat sich die Anzahl von Rückrufaktionen seitens der Fahrzeughersteller im Lau-fe des letzten Jahrzehnts (s. Abb. 2.2) erhöht.

Beim Vergleich der Statistiken zur Anfälligkeit der Fahrzeugelektronik in Bezugauf Fahrzeugbetriebsausfälle zeigt sich ein gemischtes Bild. Einerseits lassen sich nach/[Kra05]/ Rückrufaktionen zu zwei Drittel der Fahrzeugmechanik zuordnen (s. Abb.2.3). Beim Blick auf die bei Fahrzeugpannen beteiligten Baugruppen verteilen sich je-doch 40% auf Elektronikkomponenten (s. Abb. 2.4), wobei die Hauptursachen nicht im-

18 KAPITEL 2. GRUNDLAGEN

55 64 7286

105 116137

123

167 157

1998 1999 2000 2001 2002 2003 *) 2004 2005 2006 2007

Jahr

0

20

40

60

80

100

120

140

160

180

Anzahl

*) 2003: 15 Monate

Abbildung 2.2.: Entwicklung der Anzahl der Rückrufaktionen von 1998 bis 2007 /[Kra07]/

��

��

��

� � � � �

��

� � � � � � �

� � � � � � �

! ��

�

��

��

��

��

��

�

��

��

"�� #��

�� $%� ��

��&�'�� &�� &�� &�'�� (��&�� &�'�� (�� &�'�� (��)$��*+ ��'��&��)$��*+ ��'��

Abbildung 2.3.: Mängelartbezogene Verteilung der Rückrufaktionen aus Sicht des Kraftfahrt-Bundesamts /[Kra05]/

mer im Softwarebereich zu suchen sind, sondern sich vorrangig der Batterie und demKabelstrang, insbesondere dessen Steckverbindern, zuordnen lassen.

Insgesamt lässt sich folgern, dass E/E-Probleme einen signifikanten Einfluss in derZuverlässigkeit des Fahrbetriebs leisten und die Anzahl der dort zu erwartenden Pro-bleme in den kommenden Jahren ansteigen wird.

2.1.3. Systemklassifikation automotiver E/E-Systeme

Allgemein wird im Umfeld des Einsatzes der E/E-Systeme im Fahrzeug von reaktivenSystemen gesprochen. Diese lassen sich von den interaktiven und den transformierendenSystemen abgrenzen /[Ber89], [ELLSV02], [HCRP94]/.

Reaktive Systeme sind gekennzeichnet durch eine kontinuierliche Interaktion mit ei-ner physikalischen Umgebung, deren Verhalten asynchron zu dem ablaufenden System

2.2. AUTOMOTIVE SYSTEMS ENGINEERING 19

Allgemeine Elektrik 39,7%Sonstiges 13,6%

Zündanlage 12,7%

Motor 7,8%

Räder/Reifen 7,1%Einspritzanlage 6,8%

Kühlung/Lüftung/Klima 5,8%

Kupplung/Getriebe 4,6%

Auspuffanlage 1,9%

Abbildung 2.4.: Daten zu der Verteilung der an Fahrzeug-Ausfällen beteiligten Baugruppen/[ADA07]/

verläuft. Der Prozess der Interaktion zwischen System und Systemumgebung ist dabeiin aller Regel nichtterminierend. Ein Systemstopp wird daher in aller Regel als Betriebs-ausfall oder Störung aufgefasst. Kritische Ereignisse, die aus der Systemumgebung indas System kommuniziert werden, erfordern eventuell eine umgehende Behandlungim System. Die Umgebung induziert in dem Zusammenhang die maximal akzeptier-baren Antwortzeiten für die Reaktion auf ein Ereignis, beispielsweise die Selektion despassenden Gangs in einem Automatikgetriebe auf Basis einer an der Motorsensorik ge-messenen Drehzahl. Als Konsequenz einer kurzfristigen Systemreaktion kommt es zupotentiellen Veränderungen innerhalb des Systemzustands. Eine Systemantwort ermög-licht die Aktivierung, Verstärkung oder Unterdrückung im Verhalten des eingebettetenSystems und dessen Kommunikation zur Systemumgebung.

Transformierende Systeme sind geprägt durch die Berechnung mit zu Programm-beginn vorliegenden Eingabedaten und der mit der Datenrückgabe verbundenen Pro-grammterminierung. Im Gegensatz zu den reaktiven Systemen wird der interne Ablaufeines transformierenden Systems nicht durch das Auftreten externer Ereignisse aus derUmwelt während der Ausführungszeit beeinflusst.

Bei den interaktiven Systemen wird das ausführende System mit dessen Systemum-gebung synchronisiert, beispielsweise für die Entwicklung von Betriebssystemen. ImFahrzeug bietet sich ein derartiges Szenario im Zusammenhang mit der Mensch-Maschi-ne-Interaktionsschnittstelle. Beispielhaft lässt sich dafür die Bedienung eines Einpark-assistenten unter Einbezug der Komponenten Lenkrad, Getriebewählhebel, Gaspedal,Bremse, Infotainmentsystem und Kombiinstrument nennen. Da eine Interaktion stets eina priori definiertes deterministisches Bedienszenario voraussetzt, lässt sich die Abgren-zung zu den zur Systemumgebung asynchron ablaufenden, reaktiven Systemen nach-vollziehen. Aufgrund der allgemeinen technischen Nähe zwischen den interaktiven undden reaktiven Systemen werden deren Ansätze auch integriert aufgefasst /[Wie02]/.

Zusammenfassend werden die Kernelemente der drei Systemarten dargestellt (s. Tab.2.1).

2.2. Automotive Systems Engineering

Im Fahrzeugbereich hat sich mit der Zeit eine eigenständige System Engineering-Domäneentwickelt, mit teilweise spezifischen Architekturen, Methoden, Prozessen und Stan-dards. Dieser Abschnitt erfasst dabei die wesentlichen Merkmale des Automotive SystemsEngineerings aus Sicht des E/E-Bereichs.


Reaktive Systeme Interaktive Systeme Transformierende Systeme

Interaktion Sehr hoch Hoch GeringTerminierung Unendlicher Prozess Endlicher Prozess Endlicher Prozess

Reaktion Unterbrechbar Unterbrechbar Nicht UnterbrechbarZustand Zustandsabhängig Zustandsabhängig Zustandsunabhängig

Umgebungsorientierung Ja Ja GeringAusführung Parallel Gemischt Sequentiell

Zeitanforderung (Harte) Echtzeit Echtzeit UnabhängigSynchronisation Asynchron Synchron (Keine)Asynchron

Tabelle 2.1.: Abgrenzung der reaktiven Systeme von weiteren Systemkonzepten

2.2.1. Überblick und Entwicklungstrends

Die Anzahl an E/E-Systemen im Fahrzeug hat sich in den letzten Jahren kontinuierlicherhöht. Dieser Trend zeigte sich zuerst an einzelnen Komponenten wie zum Beispiel derMotorsteuerung oder des elektrischen Fensterhebers bis zu den aktuellen vollvernetz-ten Fahrzeugen mit mehreren Feldbussystemen und intelligenten Fahrerassistenzsyste-men (s. Abb. 2.5). Beschleunigt wurde die Entwicklung aufgrund der Substitution me-chanischer durch elektromechanische Komponenten. Mithilfe von Software als Teil derKomponenten lässt sich beispielsweise in Fahrwerkssystemen wie der adaptiven Dämp-fersteuerung eine verbesserte Fahrzeugdynamik umsetzen bei gleichzeitig sinkendenGewichts- und Kostenaspekten.

Fahrzeug-Assistenzsysteme

TotwinkelüberwachungBlind-Spot-Detection

- Radar 24GHz- Infrarot- Kamera

Einparkassistent

- Ultraschall- Radar 24GHz Ultrawide- Kamera

Parkhilfe- Ultraschall- Kamera

Rückfahrhilfe- Radar 24GHz- Kamera

Heckkollisionswarnung- Radar 24GHz- Infrarot

Spurwechselassistent- Radar 24GHz- Infrarot

Night Vision - Nahes Infrarot- Fernes Infrarot

KollisionsabschwächungKombisensor aus- Radar 24GHz / 77GHz- Infrarot- Kamera

Kollisionswarnung- Radar 24GHz / 77GHz- Infrarot- Kamera

Abstandsregelung ACC mit Stop & Go

- Radar 24GHz / 77GHz- Infrarot- Kamera

Precrash- Radar 24GHz / 77GHz- Infrarot- Kamera

Lane-Departure-Warning

- Infrarot- Kamera

Lane Keeping- Kamera

Abbildung 2.5.: Intelligente Fahrerassistenzsysteme zur Umfelderkennung im Überblick/[Mic07]/

Durch die sukzessive Einführung von Software im Automobil entstehen neue Ent-wicklungsaufgaben, die es für die traditionell maschinenbauorientierte Fahrzeugent-wicklung zukünftig zu beherrschen gilt. Speziell die Möglichkeiten der Produktdiffe-renzierung über Softwarefunktionen und deren Qualität bleiben unterschätzt, wenn Par-


allelen zur Wertschöpfung im Vergleich von Hard- und Software aus der allgemeinenRechnerentwicklung im Privat- und Geschäftsbereich gezogen werden /[NR05]/.

Die Ausprägung der Integration softwarebasierter E/E-Funktionalität zeigt sich mo-mentan im Fahrzeugkontext stark gekennzeichnet durch Einzelkomponentenlösungen.Diese werden auf Basis einer verteilten Steuergeräteentwicklung mit einer Vielzahl anZulieferern umgesetzt. Dieser Entwicklungsstil lässt sich auf die interne dezentrale Or-ganisationsstruktur eines Automobilherstellers zurückführen, welche zu einer kompo-nentenorientierten Systementwicklung passt. Nach /[BGG+04]/ liegt beim Vergleichder lokalen komponenten- mit einer globalen systemorientierten Betrachtungsweise derFokus verstärkt auf der Komponentensicht (61% zu 39%). Unabhängig davon ist es aktu-ell aus Komplexitäts- und Aufwandsgründen nicht mehr möglich, die gesamten System-funktionen zentral im Fahrzeug in einer Systemkomponente integriert zu entwickeln.Ein verteiltes Systemkonzept begründet sich in der Dekomposition der Gesamtsystem-größe und der Reduzierung der Gesamtsystemkomplexität. Die räumliche Verteilungvon Komponenten im Fahrzeug, die Integration einer Vielzahl an Entwicklern sowie dieBeherrschung sicherheitsrelevanter Anforderungen bedingen eine verteilte Systement-wicklung. Zusätzlich zu der hohen Systemkomplexität und der verteilten Entwicklungwird die Fertigungstiefe zum Ziel einer kosteneffizienten Produktgenerierung niedriggehalten und in Zukunft eher ab- als zunehmen /[IKB03]/.

Als Folge der verteilten Komponentenentwicklung in der Fahrzeug-E/E sehen sichFahrzeughersteller verstärkt in der Rolle des Systemintegrators, der eine steigende An-zahl an unabhängigen Zulieferfirmen in seiner verteilten Systementwicklung berück-sichtigen muss, was die Gestaltung des Prozesses zum Systementwurf und dessen Im-plementierung maßgeblich beeinflusst. Mit der Verfolgung eines komponentenorien-tierten Entwurfs eines verteilten Gesamtsystems steigt die Signifikanz von etabliertenStandardisierungen im Bereich der Soft- und Hardwareentwicklung. Konsequenterwei-se reduziert sich der Lösungsraum für Systemarchitekturalternativen, was im Automobilzu stabilen aber sich nur langsam entwickelnden Gesamtsystemarchitekturen führt.

Um den stetigen Wachstum der E/E und deren Software innerhalb des verteiltenGesamtsystems in Zukunft besser zu beherrschen und verstehen zu können, muss auchbeim Fahrzeughersteller als Systemintegrator stärker auf eine Gesamtsystementwick-lung hingearbeitet werden. Die Summe eines lokal optimierten Systems unterliegt dabeiim Allgemeinen der Qualität eines global optimierten Systems. Diese Ideen sind allge-mein mit dem Begriff des Systems Engineerings verbunden. Dieser Ansatz wurde in derRaumfahrt geprägt, um komplexe, interdisziplinäre Entwicklungen optimiert zu koordi-nieren /[R. 95]/. Beim Entwurf eines passenden Prozesses müssen Geschäftsinteressendes Unternehmens bewahrt sowie Vorstellungen auf Kundenseite getroffen werden. Er-folgsfaktoren sind in diesem Zusammenhang eine hohe Qualität, Vertrauenswürdigkeit,Kosteneffizienz sowie eine passende Ablaufplanung während des Gesamtlebenszykluseines zu entwickelnden Systems /[INC07]/.

In der komponentenorientierten Systementwicklung im automotiven Umfeld hatsich wie in weiteren Sektoren, beispielsweise dem Avionikbereich oder der Automa-tisierungstechnik, eine Entwicklung hin zu einem effizienten, fehlerminimierenden Sys-tem Engineering-Prozess durch IT-basierte Werkzeuge bewährt. Diese CAE-Werkzeuge(Computer Aided Engineering) bieten Lösungen für eine kontinuierliche Unterstützungdes Systementwurfs und der Systemverifikation, die einerseits durch modellbasierteformalisierte Systemspezifikationen präzises Systemdesign gestatten und oftmals auchmächtige Hilfsmittel zur Simulation und Analyse bereitstellen. Die Entwicklungsverfah-


ren MIL (Model in the Loop), SIL (Software in the Loop), HIL (Hardware in the Loop) sindals Stand der Technik etabliert und tragen dazu bei, das Potential an menschlichen Feh-lern frühzeitig im Entwicklungsprozess zu diagnostizieren und zu reduzieren /[BS06]/.Gleichzeitig wird der Ansatz des Rapid Prototyping mithilfe leistungsfähiger Codegene-ratoren unterstützt, um ein modelliertes System pragmatisch auf dedizierter Hardwarezu testen /[Spr96]/.

In der globalen Entwicklung mit gesteigertem Bedarf an Mobilität, Ressourcen, Infor-mation und Kommunikation sowie Schutz und Sicherheit entstehen maßgebliche Ein-flussfaktoren für den Automobilbau. Entsprechend stellen Mobilität, Sicherheit, Komfortund Konnektivität wichtige Eckpunkte der Fahrzeugentwicklung dar.

Abbildung 2.6.: Vision zukünftiger Fahrzeugapplikationen aus Zulieferersicht /[BHWJ07]/

Diese Aspekte finden sich wieder in den Bereichen Emissionsreduzierung, Umfelder-kennung, modularisierter Systemaufbau und Systemintegration/-interaktion (s. Abb.2.6). Aus der Sicht eines Zulieferers stehen dabei die Ziele der Unfallreduzierung (durcherweiterte Fahrerassistenzsysteme), die Verbrauchsreduzierung (durch verbesserte Ein-spritztechnik, Hybrid-Antriebe, X-by-Wire), die Konnektivitätserhöhung (durch Car-to-Car-Kommunikation (vgl. Abs. 2.3.1), Integration elektronischer Geräte der Fahrzeugbe-nutzer) sowie die Komplexitätsreduzierung in der E/E-Entwicklung (durch modulareBaukastensysteme und Plattformsteuergeräte1 (vgl. Abs. 2.2.3)) im Vordergrund.

2.2.2. Systemarchitekturen

Die Systemarchitektur eines heutigen Premiumfahrzeugs enthält bis zu 70 Steuergeräte,die zum Teil über Netzwerke miteinander per Nachrichtenaustausch kommunizieren,allerdings auch jeweils Aufgaben autonom abarbeiten (z.B. Steuerungs- und Regelungs-aufgaben) (s. Abb. 2.7). Durch die Interaktionsmöglichkeit zwischen den Steuergerätenwerden Anwendungen auf verteilten Systemen realisiert, deren hoher Komplexitätsgraddurch verschiedene Abstraktionssichten im Entwicklungsprozess entscheidend verrin-gert werden muss (s. Abb. 2.8).

1In diesem Beispiel bezieht sich das Baukastensystem auf die modulare FahrzeugcockpitarchitekturCESAR (Cockpit Electro-Mechanical System Architecture) und das Plattformsteuergerät auf ein zentrales Ka-rosseriesteuergerätekonzept (Body Control Unit) /[BHWJ07]/.


Abbildung 2.7.: Steuergeräteverteilung innerhalb des Porsche Carrera Typ 997

E/E-Systemarchitektur: Allgemein wird dieser Begriff unscharf, und oftmals rein Hard-ware bezogen, benutzt. Im Allgemeinen wird darunter ein Verbund an Einzelsystemen,den Steuergeräten, verstanden, die über Bussysteme vernetzt sein können. Unterschied-liche Sensoren werden zur Datenerfassung und Aktoren zur Ansteuerung mechani-scher Komponenten über Netzwerke oder konventionell über analoge oder digitale Ver-bindungen angebunden. Im Folgenden sind die Begriffe E/E-Systemarchitektur undSystemarchitektur als synonym zu betrachten.

Im Allgemeinen wird bei Systemarchitektur zwischen zwei Sichtweisen auf das Ge-samtsystem /[SZ03], [Bee07]/ unterschieden.

Logische Systemarchitektur: Zum einem existiert ein funktionales Modell der verteiltenAnwendung, das Fahrzeugfunktionsnetzwerk, welches die Funktionen und ihre Kommu-nikationskanäle beschreibt. Auf oberster Ebene werden die technischen Fahrzeugfunk-tionen in abstrakter Form als kundenerlebare Funktionen (Features) aufgefasst. DurchVerfeinerung von einzelnen Funktionen der logischen Systemarchitektur lassen sichüber mehrere Hierarchiestufen hinweg weitere konkrete Funktionen ableiten, welchedie eigentliche algorithmische Datentransformation kapseln. Funktionen beinhalten da-bei grundlegende Rechenoperationen, die sich als Kombinationen von unterschiedli-chen Berechnungsblöcken auffassen lassen. Diese können modellgestützt als Elementvon Datenflussdiagrammen oder als Teil eines Zustandsautomaten dargestellt werdenoder durch eine textuelle Berechnungsvorschrift gegeben werden. Oftmals werden lo-gische Systemarchitekturen nicht explizit aufgeführt, da kein allgemeines Verständnisüber die Konkretisierung von Semantik und Syntax für den Zweck geeigneter Notati-onsformen gegeben ist.

Technische Systemarchitektur: Die zweite Betrachtungsebene, die technische Systemar-chitektur, leitet sich als technische Implementierung der logischen Systemarchitekturunter Berücksichtigung existierender physikalischer Einflussfaktoren ab. Dazu gehörtauf oberster Ebene der Systemverbund des Steuergerätenetzwerks und dessen Verbin-dungsausprägung (Netzwerktopologie). Weiterhin werden die spezifischen Eigenschaften


x = x+1;y = y/x;...

Logische Systemarchitektur Technische Systemarchitektur

Fahrzeugsfunktionsnetz

Taskebene

Hauptfunktion

Funktion

Subfunktion

Funktionsmodul

Netzwerk

Subnetz

Steuergerät

μP

μC

μ-Controller

Funktion 1

Funktion 2

Funktion n

Überwachung

Programm-und Datenspeicher

Datenspeicher

Eingabe-/Ausgabeeinheiten

Ausgangsstufen/Buskonnektor

Eingangsstufen/Buskonnektor

Abbildung 2.8.: Abhängigkeiten und Hierarchien in logischen und technischen Systemarchitek-turen

eines Steuergeräts, dessen Verarbeitungsgeschwindigkeit, gemessen an der Taktrate vor-handener Mikrocontroller, und dessen Ressourcen in Form von Daten- oder Programm-speichergrößen berücksichtigt. Der Zusammenhang zu den logischen Funktionen voll-zieht sich auf der Ebene von Betriebssystemtasks, welche, abgeleitet von der Betriebssys-temebene, als Prozesse eine sequentielle Ausführung von Funktionsteilen beschreiben.Tasks sind abhängig von technischen Bauteilen, dem Mikroprozessor und dessen Leis-tung und werden daher der technischen Systemarchitektur zugerechnet.

Auf Basis dieser beiden Sichtweisen erfolgt der Entwurf jedes einzelnen Steuergeräts.Es wird zwischen Standard- und Applikationssoftware unterschieden. Unter Standard-software werden plattformspezifische Software-Anteile bezeichnet, die für alle Steuerge-räte weitestgehend identisch übernommen werden. Die Applikationssoftware beinhal-tet hingegen die eigentliche Steuergerätefunktionalität, in der die Logik des steuerungs-oder regelungstechnischen Systems umgesetzt wird.

Der Systemintegrator definiert allgemein seine Anforderungen in Form von Lasten-heften. Dort werden die nichtfunktionalen und funktionalen Anforderungen bauteilbe-zogen (inklusive Applikationsebene) und plattformbezogen (ausschließlich Systemebe-ne) in separaten Dokumenten versioniert gepflegt. Durch den Einsatz von dedizierterSoftware werden die Dokumente an Entwicklergruppen innerhalb von Datenbankenbereitgestellt und miteinander verknüpft. Analog zur allgemeinen Softwareentwicklungbirgt die Anforderungserhebung, -spezifikation und -verfeinerung (Requirements Engi-neering) eine hochkomplexe, eigenständige Entwicklungsphase für ein Fahrzeugprojekt/[WW03], [Gri03]/.

Die Schnittstelle zum Zulieferer erfolgt in der Phase der Spezifikation von Hard-/-


Software jedes Steuergeräts. Während der Fahrzeughersteller die Systemsoftware aufBasis standardisierter Softwarekomponenten in der Serienentwicklung weitestgehendselbst vorgibt, wird die Applikationssoftware in der Regel direkt bei den Zulieferernumgesetzt. Neben dem zu dem Lastenheft obligatorisch vom Zulieferer entwickeltenPflichtenheft erfolgt die Applikationsentwicklung in Koordination mit dem Fahrzeugher-steller. Dabei geht der Trend zu einer aktiven Einbindung des Fahrzeugherstellers in derRolle des Systemintegrators, der sich selbst durch beigesteuerte Softwareanteile vomMarkt differenzieren möchte. Jedoch beschränken strenge Haftungs- und Verantwor-tungsvorgaben die Bereitschaft eines Automobilherstellers noch intensiver aktiv in dieEntwicklung einer Systemkomponente einzugreifen.

Demzufolge müssen auch die Komponenten- und Integrationstests der Software auf ei-nem Steuergerät von dem jeweils zuständigen Zulieferer erfolgen, da ausschließlich beiihm die Gesamtfunktionalität der Software eines Bauteils im Quellcode vorliegt. Um dieAbnahme des Herstellers für ein Steuergerät auf einem qualitativ hochwertigen Leis-tungsstand zu ermöglichen, muss herstellerseitig ein konsequentes Qualitätsmanagementgeführt werden. Dabei haben die Zulieferer die Kriterien eines Qualitätssteckbriefs imSinne einer Vorqualifikation zu erfüllen. Falls sich der Hersteller die Integration der ver-schiedenen Systemkomponenten nicht zumutet, kann auch einer der Zulieferer einesSubsegments der technischen Systemarchitektur mit dieser Aufgabe betraut werden.Nachgelagerte und für die Serienproduktion relevante Aufgaben müssen jedoch wie-der vom Systemhersteller übernommen werden wie beispielsweise die Kalibrierung derSoftware wie auch der System- und Akzeptanztest zur Verifikation und Validation desGesamtsystems.

2.2.3. Plattformkonzepte und Variantenmanagement

Um den enormen Kostendruck in der Fahrzeugserienentwicklung zu begegnen hat sichherstellerübergreifend das Bestreben zur Entwicklung von Plattformkonzepten durch-gesetzt. Diese Idee bezieht sich auf die Wiederverwendung funktionsgleicher Bauteile inverschiedenen Fahrzeugderivaten, den Baureihen, um den Anteil an Parallel- oder unnö-tiger Neuentwicklungen zu minimieren. Dieses Vorhaben fundiert nicht nur auf der glo-balen E/E-Architekturebene über die einzelnen Bussegmente hinweg, sondern beziehtsich gleichermaßen auf einzelne Steuergeräte und deren Subkomponenten. Plattformenbeziehen sich dabei auf mechanische und elektrisch/elektronische Fahrzeugkomponen-ten.

In der E/E-Architekturentwicklung lässt sich der Plattformgedanke vorrangig aufSteuergeräte anwenden, bei denen ein Basisanteil, etwa die Hardware, identisch gehal-ten wird, wobei fahrzeugspezifische Umfänge (oftmals als freigeschaltete Softwarefunk-tionen) variantenabhängig umgesetzt werden. Aus der Sicht der E/E-Entwicklung exis-tiert dabei ein intensives Bestreben einen hohen Grad an diesen Plattformkomponentenzu entwickeln, falls der Einsatz identischer Steuergeräte in verschiedenen Baureihennicht möglich ist. Je nach Quantität und Vielfalt der zu entwickelnden Fahrzeugbau-reihen eignen sich Baukastenkonzepte, beispielsweise für Premium-, Mittelklasse- undKleinwagen. Allgemein basieren die Baukästen auf einheitlichen E/E-Architekturstruk-turen mit identischen Fahrzeugdomänen (in der gröbsten Form klassischerweise mitder Unterteilung in den Komfort-, Antriebs- und Telematikbereich). Jede Fahrzeugdo-mäne wird dabei in einem Baukasten auf einen oder mehrere Bussysteme mit allgemeineinheitlichen Bustechnologien verteilt.


PlattformeinheitlichBaureihenübergreifendBaureihenspezifisch

Einheitlich positioniertSpezifisch positioniert

Bussystem ABussystem BBussystem C

Baureihe A Baureihe B Baureihe C

Abbildung 2.9.: Gegenüberstellung der physikalischen E/E-Architekturvarianten in den ver-schiedenen Fahrzeugbaureihen

Wie in Abb. 2.92 dargestellt, erhöht sich die Komplexität der E/E-Architekturen inBaukästen aufgrund regelmäßig auftretender proprietärer Abweichungen einer Baurei-he von der Plattform. So können teilweise baureihenspezifische Komponenten, auchkomplette Steuergeräte, vorkommen.

Als Zwischenstufe gilt es baureihenübergreifende Komponenten zu identifizieren,die jedoch nicht in allen Fahrzeugbaureihen vorhanden sein müssen (in dem Beispielsind spezielle Heckklappensteuergeräte in Baureihe B und C identisch, wobei in Baurei-he A auf diese Komponente verzichtet werden kann).

Selbst bei den in allen Baureihen identischen Steuergeräten, den plattformeinheitli-chen Bauteilen, kann es vorkommen, dass aus Paketierungsgründen eine unterschiedli-che Positionierung im Fahrzeug notwendig ist. Im Extremfall können Einschränkungenaus der Kabelbaumentwicklung zu einer Umpartitionierung eines einheitlichen Steuer-geräts auf ein alternatives Bussegment führen. Derartige Einschränkungen erschwerenden allgemeinen Ansatz der Plattformentwicklung.

Variantenmanagement

Aktuell erfolgt die Analyse und Pflege der Fahrzeugplattform und -varianten größ-tenteils in Form von eigenständigen Dokumenten. Dabei werden die Fahrzeugausstat-tungen den Funktionen oder Steuergeräten zugeordnet und diese in Tabellen mit denverschiedenen Fahrzeugbaureihen verknüpft. Falls die Systemarchitektur bei der Platt-formentwicklung bereits in einem elektronischen Modell vorliegt, so lässt sich das Va-riantenmanagement feingranularer betreiben. Das in Kapitel 5 umgesetzte Konzept derin dieser Arbeit definierten Entwicklungsmethodik beruht auf einem derartigen Vari-antenkonzept /[Aqu07]/. Dabei liegt die Herausforderung in der sinnvollen Erfassungund Gruppierung von Architekturelementen in Gruppen (Modellgruppen). In der Re-gel werden dabei je nach Klassifikationsmethode disjunkte Mengen entstehen. Unab-

2Die dargestellten Topologien sind stark vereinfacht und mit rein fiktiven Charakter.


hängig von dem Modell sind aus den Eigenschaften der E/E-Architektur Konzepte zudefinieren (Konzeptvorlagen), die es erlauben technische Alternativen auszuwählen (Kon-zeptinstanzen). Eine Strukturierung und Gruppierung der Konzeptvorlagen erfolgt überdas Bilden von Konzeptgruppen. Die Zuordnung der technischen Konzepte zu konkretenFahrzeugausstattungen vollzieht sich durch die Definition von Ausstattungsvorlagen. DieAusstattungsmöglichkeiten werden in dieser Arbeit mit einer Paketierung der verschie-denen definierten Ausstattungsmerkmale der E/E-Architektur in klassische Alternati-ven, etwa Basis, Medium und Premium, überführt. Die Architekturvariante lässt sich nundurch die Zuordnung einer eindeutigen Ausstattungsinstanz zu jeweils einer eindeuti-gen Konzeptinstanz aus den spezifizierten Konzeptvorlagen erzeugen. Die Anwendungdes Variantenmanagements wird in Abs. 5.4 dokumentiert.

2.2.4. Entwicklungsprozess

Der Einzug der Software in die elektronischen Systeme im Fahrzeug und deren starkerAnstieg in den letzten Jahren ging konform mit den Aussagen von G. Moore, dessen po-puläres Moore’s Law 1965 einen Wachstum an integrierten Schaltkreisen innerhalb vonelektronischen Komponenten mit dem Faktor 2 pro Jahr prophezeite /[Moo65]/. Umdiesen enormen Komplexitätszuwachs in einem für die Automobilbranche noch jungenSegment stemmen zu können, musste zwangsläufig der Gesamtfahrzeugentwicklungs-prozess auch auf die Umfänge des Systems Engineering mit hohen Software-Anteilenabgestimmt werden /[SZ03]/.

SW/ECU-Ausgangstest

(Vorqualifikation)

Systementwurf Systemintegration

Validierung (Fahrzeugerprobung)

Verifikation(Qualifizierung)

Anforderungsanalyse (Software)

Spezifikation der Software-Architektur

Spezifikation der Software-Komponenten

Design der Software-Komponenten

Implementierung der Software-Komponenten

Komponententest der Software

Analyse der logischen Systemarchitektur

Spezifikation der technischen Systemarchitektur

Integrationstest der Software

Integration der Software-Komponenten

Integrationstest des Systems

Integration der Systemkomponenten

Kalibrierung

Testergebnisse

TestfälleAnwendungsfall

Testergebnisse

Testfälle

Anforderungsanalyse (Benutzersicht)

Spezifikation der logischen Systemarchitektur

Akzeptanztest

Systemtest

Fah

rze

ug

he

rste

ller

Lie

fera

nte

n

EC

U/

Sy

ste

m

inte

gra

tor

Abbildung 2.10.: Kernprozesse in der Softwareentwicklung nach dem V-Modell

Durch die starke Einbindung von Lieferanten und Sublieferanten in die Fahrzeug-entwicklung hat sich ein iterativer Entwicklungsprozess nach dem VorgehensmodellV-Modell 97 für softwarebasierte Systeme etabliert (s. Abb. 2.10). Die zu durchlaufendenKernprozesse in diesem Konzept scheinen geeignet zur Spezifikation, Design und Im-plementierung von eingebetteten Systemen durch die in jeder Entwicklungsphase mög-liche Prüfung der Korrektheit (Verifikation) von (Teil-)Ergebnissen. In Projektentwicklun-


gen wird durch iteratives Ausführen des Vorgehensmodells die Produktfunktionalität inskalierbarer Form inkrementell erweitert und deren Qualität über entsprechende Mus-terphasen verbessert. Auch zur parallelen Entwicklung von Hard- und Software kanndieses Vorgehensmodell geeignet implementiert werden /[SZ03], S. 148/.

Mittlerweile gilt das V-Modell 97 als überholt, da neben den Vorteilen auch eini-ge Schwächen identifiziert worden sind. Im speziellen fehlt eine Skalierbarkeit auf denspezifischen Einsatzzweck, da Projekte im Allgemeinen stark unterschiedliche Anforde-rungen aufweisen können. Da die Phasen des V-Modell 97 strikt sequentiell durchlaufenwerden, ist ein agiler Ansatz in Bezug auf zeitliche Terminierungen in den Projektphasennur beschränkt umsetzbar. Auch das Zusammenspiel zwischen dem Fahrzeugherstellerin der Rolle des Auftraggebers und dem Zulieferer als Auftragnehmer lässt sich nurunsauber auf die vorgeschriebenen Projektphasen abbilden. So wird in der Automobil-branche die Schnittstelle zwischen Systemintegrator und Systemzulieferer horizontal imV-Modell vollzogen (s. Abb. 2.10). Späte Korrekturen können dabei ein hohes Projektrisi-ko darstellen. Zusätzlich können beim Übergang zwischen den einzelnen ProjektphasenInformationen durch unsaubere Schnittstellen verloren gehen. Die dabei entstehendenFehler lassen sich in der Regel auf menschliche Ursachen zurückführen, da die Infor-mationsüberführung und -interpretation oftmals durch unabgestimmte heterogene undproprietäre Werkzeugketten erfolgt, welche potentielle Fehlerquellen darstellen3.

Interessanterweise unterlaufen die meisten Softwarefehler (> 40%) bei der Definiti-on der Systemspezifikationen bzw. des Systemdesigns /[Spr96], [Gri03]/ und nicht wiehäufig angenommen während der Implementierungsphase. Diese Erkenntnis lässt sichbei der Betrachtung des Entstehungsprozesses eines E/E-Fahrzeugbauteils nachvollzie-hen. Dabei stellt sich beispielsweise die Frage wie die Korrektheit der Funktionalitäteiner Komponente gegenüber partiell informeller und partiell halb-formaler Spezifika-tionen, in Form von gering strukturierten Lastenheften des Auftraggebers, verifiziertwerden soll.

Gesamtheitlich betrachtet resultiert aus den aufgezeigten Unzulänglichkeiten des ak-tuellen Entwicklungsprozesses der Bedarf einer deutlichen Verbesserung in der funktio-nalen Gesamtspezifikation eines E/E-Fahrzeugsystems. Diese sollte sich in Bezug aufdie in den Komponenten ablaufenden Applikationen abstimmen und verfeinern lassen(System Refinement). Zusätzlich gilt es den Automatisierungsgrad der Übergänge an denSchnittstellen der Projektphasen sukzessive zu erhöhen. Gleichzeitig muss die Schaf-fung einer skalierbaren, integriert durchgehenden Entwicklungsumgebung das Ziel desSystemintegrators bilden.

Es stellt sich zwangsläufig die Frage inwieweit das klassische V-Modell 97 auf dieEntwicklung von verteilten eingebetteten Systemen in Bezug auf die Automobilindus-trie unter Hinzunahme einer Vielzahl an Projektbeteiligten aus verschiedensten Orga-nisationen passt. Verbesserte Konzepte wie beispielsweise das V-Modell XT adressierengenau diese Fragestellung /[KNR05]/. Es sollte dabei nicht vergessen werden, dass einVorgehensmodell eher eine strukturelle Vorgabe für den Gesamtproduktentwicklungs-prozess darstellt und keine konkrete technische Umsetzung der einzelnen Kernprozessevorgegeben wird. Im Folgenden wird die Applizierung des V-Modells 97 im Kontextder E/E-Entwicklung im Automobil beschrieben.

3Eine heterogene Werkzeugkette besteht aus einer Kombination von Entwicklungswerkzeugen mit un-terschiedlichen Eigenschaften und Anwendungsgebieten, die unabhängig voneinander entwickelt werden.Proprietäre Werkzeugketten beinhalten Softwareeigenentwicklungen mit einem dedizierten beschränktenAnwendungsgebiet.


2.2.4.1. Anforderungsanalyse

Das Ziel der Anforderungsanalyse basiert auf der Identifikation zwangsläufig zu er-füllender Eigenschaften einer zu entwickelnden E/E-Architektur, um den Bedarf ankundenerlebbaren Funktionen des Fahrzeugs vollständig abzudecken.

In der Praxis bezieht sich die Anforderungsanalyse auf den Prozess der Erstellung ei-nes Lastenhefts. Dieses bezieht sich dabei konkret auf physikalische oder logische Kom-ponenten eines Fahrzeugs und wird allgemein in textueller Form spezifiziert. Problemedieser Darstellungsform wurzeln in fehlenden oder ungenau darstellbaren Normen undStandards zur

• Strukturierung komplexer Inhalte,

• Spezifikation von Bedingungen, Attribute, Einschränkungen oder gesamter Algo-rithmen,

• Spezifikation der Abhängigkeiten beinhalteter Artefakte,

• Zuordnung beinhalteter Artefakte zu implementierbaren Komponenten oder Mo-dulen.

Nicht-Funktional

Funktional

Applikationsspezifisch

Systemspezifisch

BauraumLeistungs

versorgungSchnittstellen

(S/A)

Elektromagnetische

VerträglichkeitKosten

Abbildung 2.11.: Anforderungsklassifikation für eingebettete Systeme in der Fahrzeugentwick-lung

Bei der Entwicklung im Elektronikbereich des Fahrzeugs ist eine Mischung ausnichtfunktionalen und funktionalen Anforderungen zu berücksichtigen. Nichtfunktio-nale Anforderungen resultieren aus Einschränkungen

• im Bauraum (z.B. Gewichts-, Temperatureffekte, Einflüsse durch vorhandene che-mikalische Flüssigkeiten oder physikalische Kräfte, Crash-Zonen und maximaleLeitungslängen),

• in der Energieversorgung,

• durch die Anschlussstellen für Sensorik und Aktorik,

• in der elektromagnetischen Verträglichkeit (EMV),

• durch die Komponentenkosten der Steuergeräte (Prozessor, Speicher, E/A-Schnitt-stellen).


Nichtfunktionale

Anforderungen

BauraumLeistungs

versorgungSchnittstellen

(S/A)

Elektromagnetische

VerträglichkeitKosten

HW-KostenSW-KostenInteraktions

kosten

E/A-Schnittstellen

Netzwerkschnittstellen

GewichtLeitungslängen

SicherheitUmgebung

ReizbarkeitTemperatur

PhysikalischChemisch

Fehlertoleranz

Abbildung 2.12.: Beispielhafte Verfeinerung der Struktur für nichtfunktionale Anforderungenan E/E-Systeme im Automobil

Je nach Betrachtungsweise können auch Kosten für SW-Komponenten (Entwick-lungskosten, Lizenzierungen) oder auch Fehlertoleranzeigenschaften eines Steuergerätsin den nichtfunktionalen Anteil eingehen.

Funktionale Anforderungen gliedern sich pro Steuergerät in einen applikationsspe-zifischen Anteil, der die für den Fahrer nutzbare Funktionalität, beispielsweise einenParkassistenten, beinhaltet und einen systemspezifischen Anteil, der die Basisfunktio-nalität eines Steuergeräts, etwa die hardwarenahen Treiber, die Kommunikationsschich-ten und die Systemdienste, abdeckt. Dazu können nutzerneutrale Funktionen bzgl. desSystemmanagements, der Systemaktualisierung, der Systemdiagnose, der Systemkonfi-guration oder des Komponentenschutzes eines Steuergeräts gezählt werden. Zusätzlichmüssen Systemdienste definiert werden, welche teilweise applikativ, etwa bei höherenDatenprotokollen auf dem Feldbus zur Übertragung von Bedien- und Anzeigeinforma-tionen für das Cockpit des Fahrzeugs /[WW04]/, oder systembezogen beispielsweisezum Softwareupdate eines Steuergeräts oder zur dessen Kalibrierung implementiertwerden.

FunktionaleAnforderungen

Applikationsspezifisch

Systemspezifisch

Zeitkontinuierlich

ZeitdiskretEreignisdiskret

Systemmanagement

Systemaktualisierung

Systemdiagnose

System schutz

System konfiguration

Netzwerkdienste

Abbildung 2.13.: Verfeinerung der funktionalen Anforderungsstruktur für E/E-Systeme im Au-tomobil

Obwohl die beiden Klassifikationen der Anforderungen zwei grundsätzlich unter-schiedliche Aspekte der Systementwicklung spezifizieren, so gibt es trotzdem wechsel-seitige Wirkungen zwischen den beiden Ästen, die den Lösungsspielraum einschränken.Während der Systemlieferant in der Regel sein Wissen auf der funktionalen Seite zurImplementierung einsetzt, beschäftigt sich der Systemintegrator vor allem mit den nicht-funktionalen Anforderungen, da nur ihm die Informationen über das Gesamtsystem,den Systemverbund, vorliegen. Aktuell hat sich der Einsatz von Dokumentenverwal-tungssystemen mit Verweisen zur Nachverfolgbarkeit (Traceability) von Abhängigkeitendurch Verknüpfungen etabliert /[VHHM03], [Tel06], [IBM06]/. Allerdings können da-


bei in der Regel nur informelle Textblöcke angelegt werden. Eine Formalisierung derObjekte und ihres Inhalts wird nicht unterstützt, was die interpretationsfreie Umset-zung einer Spezifikation erschwert. Halbformale Beschreibungsmittel werden dabei zurVeranschaulichung herangezogen, beispielsweise in Form eines vereinfachten Zustands-automaten. Die Qualität einer formal präzisen Spezifikation auf Basis einer definiertenGrammatik lässt sich damit nicht erreichen. Teilweise werden die Anforderungen auchsehr abstrakt definiert („... die Funktion xy muss die Qualität besitzen, um den Status „Best inClass“ erreichen zu können ...“), die sich nur schwer in einem Pflichtenheft konkretisierenlassen.

Um die Schnittstelle zwischen Anforderungs- und Systemspezifikation möglichstsauber und verlustfrei zu spezifizieren, eignen sich formalisierte Notationsformen, diepräzise Semantikeigenschaften aufweisen und auf einer eindeutig definierten Syntaxbasieren (vgl. Abs. 2.3.2). Die Umsetzung einer modellgetriebenen Entwicklung bietetdie Möglichkeit zur Formalisierung von rein textuell beschriebenen Spezifikationen. In/[BFM05]/ werden die Anforderungen klassifiziert in Schichten abgebildet, welche for-mal in Modellen gepflegt werden. Dazu gehören Ebenen zur Funktions-, Vernetzungs-und Bauraumspezifikation. Ergänzend sind Sichten zur Funktionstypisierung in Biblio-theken, zur Leistungsversorgung, zur Leitungsverteilung und für den Komponenten-aufbau addiert worden (s. Abs. 2.5.2)4 /[AQU06]/. Der Vorteil dieses Ansatzes liegtin der unabhängigen Spezifikation der Anforderungen in verschiedenen Ebenen, de-ren wechselseitigen Abhängigkeiten frühzeitig inkonsistente Anforderungen aufdecken.Zusätzlich werden eine Variantenpflege und der Vergleich unterschiedlicher Lösungenunterstützt und ein Konzept zum nebenläufigen Entwickeln (Concurrent Engineering)angeboten.

Im Gegensatz zur dezentralen verteilten Systemspezifikation in Form von mehrerenLastenheften erfordert der modellgetriebene Ansatz eine verzahnte Schnittstelle zwi-schen allen beteiligten Entwicklern. Gleichzeitig muss ein durchgehend einheitlichesVerständnis für eigenständige Notationsformen sowie deren Zusammenspiel, Syntaxund Semantik vorhanden sein.

Die in dieser Arbeit definierte Entwicklungsmethodik für flexible zeitgesteuerte Sys-teme basiert partiell auf der Basis eines modellbasierten E/E-Architekturentwicklungs-werkzeugs /[Aqu07]/. Dabei wird in diesem Ansatz die Interpretation der entwickeltenAnforderungen und deren Relation zu den Produktfeatures und Fahrzeugfunktionenaus einem modellbasierten Ansatz gewonnen. Die Grundidee basiert auf der Extraktionaller Ereignisse aus dem Lastenheft und deren Zuordnung zu einer Funktionalität. DieFunktionalität selbst wird mit konkreten Objekten verknüpft, die die technischen Inhalteder Funktionalität erfüllen. Durch diesen Ansatz ergibt sich ein Szenario der Definiti-on eines Dreitupels aus dem anfordernden Objekt, der Funktionalität und dem erfül-lenden Objekt (Requestor, Function, Fulfiller). Diese RFF-Kombination wird als Wirkkettebezeichnet. Jede Wirkkette spezifiziert dabei die Ausprägung eines Ausstattungsmerk-mals. Da eine Funktionalität mehrere Ausstattungsmerkmale eines Fahrzeugs abdeckenkann, existiert die Möglichkeit auf Basis der Menge aller Wirkketten sämtliche Ereig-nisse und die korrespondierenden erfüllenden Objekte einer spezifischen Funktionalitätzu identifizieren. Diese Abbildung wird in einer spezifischen Darstellung erfasst und inAbs. 5.1.2 exemplarisch für eine Fallstudie dokumentiert.

4Einen weiteren modellbasierten Ansatz bietet die SysML-Spezifikation, die sich ebenfalls auf eine mo-dellbasierte Anforderungsdefinition stützt (s. Abs. 2.2.4.2).


Spezifikation kundenorientierter Produktsubstanzen

Beim Entwurf und der Pflege einer E/E-Architektur steht die Erfüllung der Anforderun-gen an die Fahrzeugelektronik aus Kundensicht im Vordergrund. Um diese Eigenschaf-ten des zu entwickelnden Produkts bestmöglich zu erfassen, muss in erster Linie einevollständige, abstrakte Modellierung der Systemfeatures erfolgen. Darunter verstehensich die Produkteigenschaften, die sich dem Kunden als erlebbarer Teil des Gesamtsys-tems präsentieren, beispielsweise der Einklemmschutz eines elektrischen Fensterhebers.Ein Feature darf dabei nicht zwangsläufig mit der Ausprägung physikalischer System-komponenten in Form eines Steuergeräts gleichgesetzt werden, auch wenn Featuresinhärent als Teil einer Systemkomponente existieren können. Speziell hochwertige Pro-duktsubstanzen werden über die integrierte Kombination mehrerer Teilfunktionen er-zielt, welche sich nicht immer eindeutig einzelnen Fahrzeugdomänen wie dem Antrieboder dem Infotainment zuordnen lassen. Die Idee der „aktiven Fahrsicherheit“ lässt sichdabei exemplarisch nennen. Wie in Abb. 2.14 dargestellt wird die „Aktive Fahrsicherheit“als integriertes Feature erzeugt.

Zum aktuellen Zeitpunkt gilt die strukturierte Featureentwicklung noch als For-schungsthema, da die Signifikanz dieser Entwicklungsphase industrieweit aufgrundderen abstrakten Komplexität in der Vergangenheit aus Fahrzeugherstellersicht unter-bewertet wurde. Teilweise wird die Featureentwicklung in Form rudimentärer Tabel-len und Listendarstellungen durchgeführt. Es erfolgt dabei eine unscharfe Trennungzwischen dem Begriff einer technischen Fahrzeugfunktion und deren physikalischenImplementierung im Steuergerät. Eine Strukturierung erfolgt maximal durch einfacheHierarchiebildung der Features innerhalb von in Katalogform angelegten Funktions-gruppierungen. Dabei geht die Möglichkeit der Modellierung domänenübergreifenderFeatures sowie die Darstellung der wechselseitigen Abhängigkeiten atomarer Featuresverloren.

Audioadapter

Abstandsregelung

Fondentertainment

Fahrerassistenz

Aktive FahrdynamikUnterhaltung

Featurebaum

Stabiliätskontrolle

Bremsunterstützung

Berganfahrhilfe

Antiblockierschutz

Nässeschutz

Spurwechselassistent

AktiveFahrsicherheit

FeaturegruppeFeaturegruppe

Integriertes Feature / FeaturegruppeFeature

Abbildung 2.14.: Ausschnitt aus einer Featuredarstellung in Baumstruktur zur Strukturierungvon Systemfeatures

In Abb. 2.14 wird ein Teilausschnitt einer potentiellen Featuremodellierung in Baum-struktur anhand einer fiktiven vereinfachten E/E-Systemarchitektur dargestellt. Dabeilässt sich eine Hierarchiebildung unterschiedlicher Featuregruppen und -untergruppen


erreichen. Auch die Modellierung atomarer Features an den Baumblättern wird dabeiunterstützt. Interessant wird das Einfügen der erwähnten integrierten Features, hier inForm der „aktiven Fahrsicherheit“. Es wird ersichtlich, dass eine vollständige sequenzielleAbbildung der Systemfeatures in einem einzelnen baumförmigen Graphen nicht zweck-mäßíg darstellbar ist. Speziell das Erfassen von normalisierten Anforderungen innerhalbatomarer, wiederverwendbarer Features, die Featurebaumgenerierung sowie die Hin-zunahme von Entwicklungsschablonen (Templates) zur Vervollständigung der einzelnenFeatures im Sinne der Vertiefung des Domänenwissens wird in /[HFP+06]/ behandelt.Dabei wird auch die Abbildung semantischer Aspekte zwischen den Elementen einesFeaturebaums innerhalb eigenständiger Semantikbäumen erläutert.

2.2.4.2. Systementwurf

Aufgrund unterschiedlicher Strategien zwischen Fahrzeugherstellern und der hohenKomplexität im Systemverbund existieren bis heute im E/E-Bereich noch keine einheitli-chen Standards zur Systemspezifikation unter Berücksichtigung der nicht-/funktionalenAnforderungen (s. Abs. 2.2.4.1). Allgemein lassen sich die Themen nach verschiedenenKriterien klassifizieren:

• Netzwerkebene und Komponentenebene

• Plattform und Varianten

• Applikationsebene und Systemebene

Dem Systemintegrator muss klar sein, welche Aspekte sich auf das Netzwerk auswir-ken oder durch die Spezifikation des Netzwerks beeinflusst werden und welche Anfor-derungen sich nur auf die einzelnen Komponenten beziehen. Diese Differenzierung istentscheidend, um eine verbesserte Flexibilität des Netzwerks in Bezug auf zusätzlicheSystemintegrationen zu erreichen und einen potentiellen Reengineering-Aufwand zureduzieren. Die Spezifikation auf Komponentenebene muss konsequenterweise entkop-pelt von der Netzwerkebene erfolgen. Falls aus Kostengründen eine Gleichteilestrategiefür verschiedene Fahrzeugbaureihen existiert, so wirkt sich diese Vorgabe stark auf denSystems Engineering-Prozess aus. Es gilt zu analysieren welche Komponenten (Hard-/Software) Variantencharakter aufweisen und welche Teile plattformübergreifend im-plementiert werden können.

Während sich die Netzwerk-/Komponentenunterscheidung der globalen Dekompo-sition zuwendet, zielt die Differenzierung zwischen System- und Applikationsebene aufdie funktionalen Trennung innerhalb einer Komponente. Wie in Abschnitt 2.2.4.1 be-schrieben können die nutzerneutralen Funktionen in der Regel der Systemebene zuge-ordnet werden, da sich diese vorwiegend auf Systemdienste beschränken. Die kundener-lebbare Funktionalität wird innerhalb der Komponenten auf Applikationsebene fixiert.Aus Sicht des Systementwicklers würde sich noch eine weitere Aufgliederung der Funk-tionalität in Hardware- und Softwareanteile eignen. Bei komplexen Komponenten, wiezum Beispiel der zentralen Infotainmenteinheit Head Unit (etwa für Radio, Navigation,Telefonbetrieb), werden zum Teil Lösungen unter Verwendung von konfigurierbarenFPGA-Hardwarebausteinen appliziert, die sich auf die Konzepte des Hardware/Soft-ware-Codesigns stützen. Dabei können Basisumfänge des Steuergeräts, etwa Hardwa-reabstraktionsschichten oder Graphikberechnungen, einheitlich für verschiedene An-wender eingesetzt werden, indem entwickelte logische Modelle (bspw. als VHDL-Code)


auf Hardwarebausteine abgebildet werden. Eine kundenspezifische Produktdifferenzie-rung lässt sich dabei individuell durch Adaptionen der Grundfunktionalität im Basis-modell erreichen. Aus Sicht des Fahrzeugherstellers wird diese Technik bisher einge-schränkt angewendet, da der Großteil der in Steuergeräten verbauten Chips aus an-wendungsspezifischen integrierten Schaltungen (ASIC) besteht. Diese werden kostenef-fizient und proprietär hergestellt und widersprechen im Fundament dem Plattform-konzept. Allerdings bieten sich hierbei entscheidende Vorteile im Bereich der bei derProduktion anfallenden Hardwarekosten.

Durch den starken Anstieg der Software-Komplexität durch die sukzessive Substi-tution mechanischer durch elektrische Systemlösungen auf aktuell bis zu 10 MillionenLoCs (Lines of Code) pro Fahrzeug und ca. 100 Millionen LoCs in der nächsten Genera-tion /[Bro03], [Bro06]/ fließt dem Software Engineering eine immer größer werdendeBedeutung zu. Zum Beispiel kommen zur Beschreibung des Systemverhaltens dedizier-te modellbasierte Werkzeuge zur Spezifikation von steuerungs-/regelungstechnischenAlgorithmen zum Einsatz (s. Abs. 2.2.5.2).

Für die Spezifikation und Pflege von Softwarearchitekturen hat sich im Gegensatzdazu noch kein einheitlicher Standard durchgesetzt. Dies liegt zum einen an den nichtunmittelbar in den Automotive Bereich zu übertragenen klassischen Modellierungs-techniken der Softwaretechnik. Viele Versuche die standardisierten Notationsformen fürObjektorientierung aus der allgemeinen Softwaretechnik auf den Automobilbereich zuübertragen, beispielsweise mit der Modellierungssprache UML (Unified Modeling Lan-guage), haben sich bisher als nicht ausreichend praktikabel erwiesen. Diese Spracheberücksichtigt nicht die Eigenschaften von Realzeitsystemen, beispielsweise deren Ti-ming-Anforderungen, und es fehlten bis vor kurzer Zeit noch Möglichkeiten zur Hier-archiebildung und Kapselung von Komponenten /[JHQ+03]/. Zusätzlich ergeben sichEinschränkungen aufgrund eines fehlenden Schnittstellenkonzepts zwischen den Kom-ponenten. Aus technischer Sicht ist beispielsweise keine exakte Beschreibung von Kon-nektoren zwischen Komponenten möglich, da asynchroner Signalaustausch zwischenKomponenten auf Basis von Protokollen nicht berücksichtigt wird. Diesen Einschrän-kungen hat sich die UML für Echtzeitanwendungen (UML-RT) gewidmet, die sich durchdie Option zur Modellierung der Verhaltensspezifikation für nebenläufige Systeme aus-zeichnet /[Krü01]/.

Da sich UML-RT aufgrund fehlender Architektursichten und der Abwesenheit einerformalen Überprüfbarkeit auch nicht optimal für die Entwicklung eingebetteter Systemeeignet, hat sich in den vergangenen Jahren eine Initiative zur Spezifikation einer stan-dardisierten Modellierungssprache für technische Systemarchitekturen (SysML) gebildet/[Sys06], [Wei06]/. Dieser Standard konzentriert sich auf die domänenspezifische Mo-dellierung von Systemen unter Verwendung von Systemeinschränkungen (Constraints)und unterstützt eine Trennung der logischen und technischen Aspekte in der Systemmo-dellierung. Zusätzlich existiert eine eigenständige Modellierungsform für Anforderun-gen, welche sich jeweils zu Testfällen zuordnen lassen (Traceability), um die vollständigeVerifikation der Systemanforderungen im Konzept zu garantieren. Trotz der vielseitigenEinsatzmöglichkeiten muss sich die SysML noch in der Praxis etablieren und intensiveWerkzeugunterstützung erhalten.


2.2.4.3. Implementierung

Die Implementierungsphase bezieht sich auf die Umsetzung der spezifizierten Fahr-zeugfunktionen in Steuergerätesoftware für dedizierte Steuergeräteplattformen auf Ba-sis vorliegender Lastenhefte oder entwickelter Funktionsmodelle. Grob lassen sich dreiAufgabenbereiche abgrenzen. Einerseits werden die kundenerlebbaren Funktionen inModelle umgesetzt und Seriencode generiert oder konventionell in einer Hochspra-che programmiert. Diese Funktionsmodule werden in einem weiteren Schritt mit denHardware-, Systemkonfigurations-, Betriebssystem- und Bussystemspezifischen Softwa-remodulen zu einer Gesamtsoftwarearchitektur verbunden. Dabei müssen die Hard-warekonfigurationen und deren Auswirkungen, etwa den Restriktionen beim Laufzeitund Ressourcenverbrauch, als separate Aufgabe analysiert werden. Ein entsprechendeinsatzorientiertes Hardwarelayout ist dabei zu entwerfen, welches Spielraum für Sys-temerweiterungen im Softwarebereich über den gesamten Steuergeräteentwicklungs-zyklus bietet. Gleichzeitig sollte eine Überdimensionierung der Steuergerätehardwarevermieden werden, um den stringenten Kostenanforderungen im Fahrzeugserienbereichgerecht zu werden.

2.2.4.4. Verifikation und Validierung

Im Bereich der rechten Seite des V-Modells wird grundlegend zwischen rein theoreti-scher und praktisch kombinierter Verifikation und Validierung (Testen) unterschieden.Die theoretische Verifikation stützt sich auf formalisierte Modelle des Gesamtsystems,welche mithilfe automatischer Theorembeweiser auf Korrektheit untersucht werden.Obwohl die theoretische Verifikation, im Vergleich zum praktischen Test, eine kostenef-fiziente Variante zur frühzeitigen Prüfung von Entwicklungsergebnissen im Entwick-lungsprozess darstellt, wird diese Art der Prüfung im Fahrzeugserienbereich nur ein-geschränkt berücksichtigt. Dabei birgt speziell die getrennte Entwicklung von logischerund technischer Systemarchitektur mit anschließender manueller Partitionierung dieGefahr eines Fehlverhaltens oder der Verletzung von Vorbedingungen im Zeitbereich/[BGH+06]/. Je später derartige Fehler im Entwicklungsprozess identifiziert werden,desto größer wird dabei der Behebungsaufwand, was die Relevanz der frühzeitigentheoretischen Verifikation auf Systemspezifikationsebene unterstreicht. Mit der Entwick-lung allgemein zugänglicher standardisierter formaler Modelle könnte dieser Methodezukünftig mehr Aufmerksamkeit zukommen. In /[BBG+05]/ wird das Konzept der for-malen Verifikation der niederen Schichten eines eingebetteten System im Fahrzeug aufBasis der FlexRay-Technologie erläutert.

Aktuell wird in der Fahrzeugserienentwicklung dem isolierten und dem gruppenori-entierten Steuergerätetest die größte Bedeutung zugemessen. Dabei wird die eigentlicheNetzwerkfunktionalität getrennt von den Fahrzeugapplikationen (HIL-Test (Hardware-In-The-Loop)) getestet. Partiell wird die Funktionstüchtigkeit auch direkt im Fahrzeuguntersucht (Validierung), was einerseits verlässliche Ergebnisse zulässt, aber andererseitsmit hohen Kostenaufwänden verbunden ist.

2.2.5. Methoden und Werkzeuge

Vorrangig für die Umsetzung von kundenrelevanten Funktionen haben sich mittlerwei-le ausgereifte Methoden der modellbasierten Softwareentwicklung und -generierung inder Automobilindustrie zum Stand der Technik entwickelt. Aber auch im Sinne der


Prozessautomatisierung werden für die Zwecke der Anforderungsentwicklung und -revision, der Standardsoftwareentwicklung und der Testdurchführung dedizierte Werk-zeuge eingesetzt. Im Folgenden werden die wichtigsten Vertreter aus dem Bereich desSystemdesigns und -entwurfs zur Übersicht vorgestellt.

2.2.5.1. Klassifikation

In der vernetzten Fahrzeugelektronik spiegeln sich klassischerweise zwei verschiede-ne Systemtypen wider, deren Ausprägungen definiert werden müssen. Der eine Anteilbasiert auf stark regelbasierten Konzepten, bei denen Ist-Werte, gemessen durch Sen-soren, mit durch von Sollwertgebern definierten Soll-Werten verglichen werden undpotentielle Abweichungen durch Aktoren, die über eine spezifizierte Strecke regeln kön-nen, ausgeglichen werden /[SZ03]/. Eine zweite Klasse beschreibt die Systeme, welcheeinen stark ereignisorientierten reaktiven Charakter aufweisen, der stark von den Benut-zereingaben durch Taster und Schalter des Benutzers abhängig ist. Während die Regel-/Steuerungssysteme vorwiegend in der Fahrdynamik eingesetzt werden, beschreibendie ereignisorientierten Systeme Funktionalität im Komfortsegment eines Fahrzeugs.

Die Grundeigenschaften der verschiedenen Systemarten werden in Abs. 4.2.1 tiefer-gehend betrachtet.

2.2.5.2. Notationsformen und Werkzeuge

Im Bereich der Entwicklung eingebetteter Systeme kommen mittlerweile für verschie-denste (Teil-)Aufgaben etablierte Werkzeuge mit hohem Reifegrad zum Einsatz, derenQualität aufgrund einer kontinuierlichen Weiterentwicklung und einer hohen Markt-durchdringung als Entwicklungsstandards sukzessive verbessert wird /[SHH+03]/. Umden Anteil an aufwändigen proprietären Systemlösungen gering zu halten und die An-zahl an manuellen Fehlern zu minimieren, werden die Werkzeuge eingesetzt, um dieEntwicklungszeit bei gleichzeitig steigender Qualität zu verkürzen. Dabei gilt es zu be-achten ob Werkzeuge den Entwicklungsprozess und seine Artefakte besser strukturie-ren, organisieren und versionieren sollen, beispielsweise im Bereich der Anforderungs-analyse, oder ob damit konkrete Systemdesigns spezifiziert bzw. implementiert werdensollen. Der Systemintegrator konzentriert sich dabei in der Regel verstärkt auf technischeWerkzeuge zur Anforderungsanalyse, Systemspezifikation und der Gesamtsystemvalidierungwährend der (Teil-)Systementwickler vorwiegend konkrete Systementwurfswerkzeuge ein-setzt.

Da sich die Vorgehensmodelle zur Systementwicklung bei den Systemintegratorenan den Konzepten des V-Modell 97 orientieren werden folgende Entwicklungsphasenberücksichtigt:

Anforderungsspezifikation

Im Bereich Anforderungsanalyse und -management werden die nichtfunktionalen undfunktionalen Anforderungen zumeist von getrennt operierenden Entwicklern des Syste-mintegrators durch die Erstellung von Lastenheften spezifiziert. Die Lastenhefte könnendabei für gekapselte elektrische Teilsysteme, etwa ein Steuergerät, oder übergreifendfür Querschnittssysteme, beispielsweise der FlexRay-Vernetzung, angelegt werden. Die-se Lastenhefte werden aufgrund fehlender Standards und zur Verständniserleichterung


größtenteils textuell spezifiziert, gemischt mit Abbildungen, Tabellen und teilweise halb-formalen Notationstechniken. Diese setzen sich in der Regel aus schlichten Zustandsma-schinen ohne einheitliche, vollständige Semantiken und mit zumeist textueller Syntaxzusammen. Im regelbasierten Bereich werden partielle Systemkomponenten, beispiels-weise ein Softwaremodul für die Schaltstrategie im Getriebe, durch Modelle spezifiziert.

Als etabliertes textuelles datenbankbasiertes Werkzeug zur Ablage und Verknüpfungvon Anforderungsspezifikationen (Traceability) lässt sich in dem Zusammenhang Telelo-gic Doors /[Tel06]/ (oder alternativ auch IBM Rational RequisitePro /[Int08]/) aufführen.

Steuer- und Regelbereich

Die modellbasierte Abbildung von Regelungssystemen mit automatischen, leistungs-fähigen Codegeneratoren gilt heute als Stand der Technik /[BS06, The07a, The07b]/.Die Unterstützung des Entwicklungsprozesses wird in dem Zusammenhang durch dieNotationsformen der rechnergestützten Werkzeuge zur Modellierung gemischt diskret-/kontinuierlicher Systeme, den Hybridsystemen, maßgeblich beeinflusst. So bietet dieverbreitete Entwicklungsmethodik auf Basis der CAE-Werkzeugkette MATLAB/Simu-link/Stateflow exakte Vorschriften zur Spezifikation und Partitionierung zeit-/ereignis-diskret gesteuerter Systeme auf der Grundlage von Zustands-/TransitionsbasiertenKomponenten oder zum Entwurf von kontinuierlicher Dynamik bzw. Gesetzen zurSteuerung des Systems /[Sta01]/.

Für die Entwicklung reaktiver Systeme, die einen stark ereignisgesteuerten Charak-ter aufweisen, etwa einem Sitzsteuergerät, werden Notationsformen herangezogen, dieauf der Idee von Zustandsmaschinen aufsetzen. Ebenso wie für die regelungstechni-schen Systeme gilt auch hier, dass die Notation eine halbformale Beschreibung darstellt,welche die Anbindung von Codegenerierungswerkzeugen ermöglicht. Während für Ein-zelkomponenten durch diese Entwicklung ein großer Fortschritt erzielt worden ist, stehtein vergleichbarer Fortschritt für verteilte Systeme mit mehreren physikalisch getrenn-ten Komponenten noch aus. Dies kann auf die hochkomplexen Eigenschaften einesSystemverbunds zurückgeführt werden. So müssen unterschiedliche Ressourcen undPerformanzaspekte wie auch komplett unterschiedliche HW/SW-Lösungen von Sys-temkomponenten berücksichtigt werden. In dem Zusammenhang gilt es verschiedensteSchnittstellen zu bedienen und alternative Systemausprägungsmöglichkeiten miteinzu-beziehen.

In der Regel unterscheiden sich Steuergeräte massiv in ihrem HW/SW-Design undwelche Funktionen in Hard- oder Software gelöst werden. Durch Simulationen kön-nen bei Umwandlung zwischen diesen beiden Typen beispielsweise Rundungsfehlerauftreten, welche eventuelle zu einer numerischen Instabilität führen. Speziell bei derVerwendung von Gleitpunktarithmetik kommt es aufgrund von Fehlerfortpflanzungenzu Effekten mit potentiellen Stellenauslöschungen und aufgeschaukelten Berechnungs-fehlern, deren Auswirkungen sich mit frühzeitigen Simulationen in der Entwicklunganalysieren lassen. Funktionen zur Abbildung von gemischt diskret-/kontinuierlichenReglermodellen können mithilfe von datenflussbasierten Notationen wie den Blockdia-grammen, welche aus der Regelungstechnik stammen, rechnergestützt modelliert wer-den, welche die Anschlussmöglichkeit von leistungsfähigen C-Codegeneratoren bieten.

Die Matlab/Simulink-Entwicklungsumgebung /[The07a, The07b]/ mit ergänzenderHardware und Codegeneratoren dritter Anbieter (z.B. dSpace /[BS06]/) lässt sich vor-rangig als wichtiger Vertreter im Bereich der Entwicklungswerkzeuge nennen. Als Al-


ternative existiert auch die ETAS ASCET-Produktpalette, welche ein ähnliches Anwen-dungsspektrum bedient.

Analyse stochastischer Prozesse

Ergänzend zur den geschlossenen regelungstechnischen Systemen (Closed Loop Control)treten im Fahrzeugkontext eine Vielzahl an Ereignissen auf, etwa die Betätigung ei-nes Fensterhebers, deren Existenz wahrscheinlichkeitsabhängig betrachtet werden muss.Derartige Ereignisse lassen sich am ehesten innerhalb von stochastischen Prozessen be-trachten und analysieren. In /[Bor94]/ werden für diese Bereiche stochastische Modelleverwendet, die sich werkzeuggestützt simulieren lassen. Als Werkzeugumgebung eig-net sich hierfür beispielsweise die SES/Workbench /[BTB91]/ oder Foresight /[For02]/.Die Modellierung und Simulation diskret stochastischer Prozesse hat sich im Automo-bilbereich bis heute jedoch nur eingeschränkt verbreitet.

2.2.6. Normen und Standards

Der fortschreitende Einzug von E/E-Systemen im Fahrzeug ist in den letzten 20 Jah-ren durch verschiedene Meilensteine beschleunigt worden, die heute branchenweit alsIndustriestandards anerkannt und eingesetzt werden.

Ergänzend zu dem technischen Fortschritt mit der verbreiteten Einführung der CAN-Technologie ist mit dem geschaffenen OSEK/VDX-Standard (Offene Systeme und derenSchnittstellen für die Elektronik im Fahrzeug) ein entscheidender Fortschritt in der Entwick-lung der Fahrzeug-E/E /[OSE07]/ gelungen. Dieses herstellerübergreifende Konsorti-um hat Standards in den Bereichen Steuergerätebetriebssysteme, Software-Kommunika-tionsschichten zwischen System- und Applikationsebene sowie Netzwerkmanagement(kurz NM) etabliert. Weiterhin ist eine Spezifikation zur fehlertoleranten Kommunikati-on (FTCOM) verabschiedet worden, die sich unter anderem mit der Organisation einerredundanten Datenübertragung bezüglich replizierter Signale oder Botschaften beschäf-tigt.

Parallel werden im HIS-Konsortium /[HIS07]/ prozessorientierte und produktspe-zifische Themen adressiert. Dabei ist ein Ziel harmonische Standards bezüglich der An-forderungen und Schnittstellen zu schaffen, um den Bemühungen der Zulieferer denAnforderungen der Fahrzeughersteller möglichst effizient gerecht zu werden nachzu-kommen. Dabei werden auch klassische Themen der Softwaretechnik, beispielsweisedie Prozessbewertung (Process Assessment) zur Leistungs- und Reifegradbestimmungbehandelt. Zur Bewertung der Zulieferer wird das in der Herstellerinitiative Automo-tiveSPICE /[Aut06]/ entwickelte Prozessreferenz- und Prozessbewertungsmodell her-angezogen, welches sich an den Standards ISO/IEC15504 (SPICE) und CMM(I) orien-tiert. Die Entwicklungen rund um AutomotiveSPICE beruhen auf der Erkenntnis, dassallgemeine Prozessreifegradmodelle zur Verbesserung der Softwaresystementwicklungin der Automobilbranche teilweise nur unzureichend berücksichtigt werden. Viele Her-steller haben beispielsweise den Reifegrad SPICE-Level 2 noch nicht erreichen können(s. Abb. 2.15). Weiterhin wurde in HIS ein Referenzmodell zum Software-Test erarbeitetund ein eigener Satz an Kodierrichtlinien definiert, der sich aus einer Submenge derMISRA C-Regeln /[MIS04]/ zusammensetzt. Ergänzend existieren Standardisierungenin den Bereichen Simulation und Werkzeuge, Flashprogrammierung in Steuergerätensowie Standardsoftware, etwa CAN-Treiber- oder Bootloaderspezifikationen.


SPICE-Automotive

6%

17%

3%11%

63%

Level 1 Level 2 Level 3 Nein Keine Antwort

Abbildung 2.15.: Spice-Reifegradlevel in der Fahrzeugindustrie /[Har06]/

Aktuell stehen im Mittelpunkt die Arbeiten rund um die internationale AUTOSAR-Initiative (Automobile offene Systemarchitektur) /[AUT07a]/. Auf die Ziele dieses Konsor-tiums wird in Abs. 2.2.6.3 eingegangen.

2.2.6.1. CAN

Das CAN-Feldbussystem /[Rob91]/ verkörpert einen der wichtigsten Meilensteine inder modernen E/E-Entwicklung im Automobil. Seit seinem ersten Serieneinsatz 1991 ineinem Premiumfahrzeug (Mercedes Benz S-Klasse) hat sich die Technologie als Standardweltweit im Bereich der Vernetzung für Antriebs-, Fahrwerks- und Komfortelektronikdurchgesetzt. Das Konzept ist 1983 von der Firma Bosch mit dem Ziel der Vernetzungvon Steuergeräten in Automobilen initiiert worden. Als Treiber dieser Entwicklung giltvorrangig der gewachsene Anteil an Kabelverbindungen im Fahrzeug, der sich kosten-und gewichtsmäßig negativ bei der Fahrzeugserienentwicklung auswirkt. Die techni-schen Eigenschaften der CAN-Technologie und die Erkenntnisse der Integration vonBussystemen in die Fahrzeugserienentwicklung werden in Abs. 2.4.1 erläutert.

2.2.6.2. OSEK/VDX

Im Sinne einer ersten Standardisierung von Softwarearchitekturen im Fahrzeug erwiessich die 1993 gegründete Initiative der deutschen Automobilbranche OSEK als weg-weisend in der E/E-Entwicklung. Durch die Ergänzung von OSEK durch den VDX-Ansatz (Vehicle Distributed eXecutive) aus der französischen Automobilbranche ist einharmonisierter Standard definiert worden, der internationale Akzeptanz genießt. Zielder Vereinigung war die Schaffung von Kompatibilität zwischen Steuergeräten unter-schiedlicher Hersteller und die Reduktion der Kosten für nicht applikationsspezifischeSoftwareentwicklung in Steuergeräten. OSEK/VDX umfasst übergreifend drei Kernbe-reiche:

Datenkommunikation zwischen Steuergeräte: Die Basis der netzwerkbasierten Daten-kommunikation zwischen Steuergeräten stellt eine einheitlich spezifizierte Netzwerk-schnittstelle. Diese Schnittstelle kann aber auch innerhalb eines Steuergeräts angewendet


werden. Insgesamt bildet das Datenkommunikationsmodul demzufolge eine Interakti-onsschicht im Steuergerät mit Anforderungen und Schnittstellen zur Sicherungsschicht,dem Netzwerkmanagementmodul und der Applikationssoftware.

Netzwerkmanagementkonzept: Wechselseitige Einflüsse und Abhängigkeiten zwischenden Netzwerkteilnehmern erfordern ein plattformunabhängiges Management des Netz-werks. Per Datenaustausch über das Netzwerk können Systemzustände der angeschlos-senen Steuergeräte überwacht und notwendige Maßnahmen zur Garantie von Zuverläs-sigkeit und Sicherheit des verteilten Gesamtsystems ergriffen werden.

Betriebssystemkonzept für Echtzeitsysteme: Das OSEK/VDX-OS spezifiziert Diensteund Prozesse für eine nebenläufige Ausführung mehrerer Applikationen in Echtzeit.Drei wesentliche Ausführungslevel spielen dabei eine Rolle. Dazu gehört der Umgangmit Prozessunterbrechungen, den allgemeinen Prozessen (Tasks) und den betriebssys-temspezifischen Aktivitäten, beispielsweise dem Ereignis und Taskmanagement, derVerwaltung der Betriebsmittel oder der Fehlerbehandlung.

Bus I/O Driver

OSEKtime Operating System

OSEKtime FTCom Layer

Application

Bus I/O Driver

Fault-Tolerant Subsystem

OSEK/VDXNetwork

Management

Message Filtering Layer

Fault Tolerant Layer

Application Layer

Interaction Layer

Communication Subsystem

TimeService

Bus I/O Driver

CNI Driver

Bus Communication HardwareBus Communication Hardware

Abbildung 2.16.: Softwarearchitektur auf Basis des OSEK-Konzepts /[OSE07]/

Als Erweiterung von OSEK/VDX zählt der OSEKtime-Ansatz, ein Konzept zur Er-füllung potentieller zeit- und sicherheitskritischer Anforderungen in Steuergeräten. ZuOSEKtime zählen folgende Module:

Betriebssystemkonzept für harte Echtzeitanwendungen: Das OSEKtime-Betriebssystemstellt notwendige Dienste zur Unterstützung fehlertoleranter verteilter Applikationenmit erhöhten Zuverlässigkeitsanforderungen. Die a priori und statisch zur Laufzeitfestgelegte Systemkonfiguration bietet dabei fehlertolerante Eigenschaften im Bereichdes Systemstartvorgangs, der Nachrichten-, Unterbrechungs- und Fehlerbehandlung so-wie einer Schnittstelle zur Bereitstellung von Zustandsinformationen. Eine Kernidee inOSEKtime ist die zeitliche Synchronisation der internen Prozesse mit einer vorgegebenglobalen Zeit im System.


Fehlertolerante Kommunikationsschicht FTCom: FTCom beschreibt mehrere Software-schichten auf der Applikationsebene und für die Interaktion zwischen den Steuergerä-ten. Entscheidend ist die Hinzunahme einer fehlertoleranten Schicht zum Umgang mitmehreren Instanzen von Nachrichten bei der Anwendung von redundanter Datenüber-tragung. Als Ergänzung dient ein weiterer optionaler Mechanismus zur Nachrichtenfil-terung.

OSEK Operating System

Interaction Layer

Network Layer

Data Link Layer

OSEK/VDX

NetworkManagement

OSEK COM

Bus Communication Hardware

Application

Abbildung 2.17.: Softwarearchitektur auf Basis des OSEKtime-Konzepts /[OSE01]/

In den letzten Jahren waren in erster Linie die Konzepte des allgemeinen OSEK/-VDX-Standards im Fahrzeug etabliert. Aufgrund der eingeschränkten Anwendungs-möglichkeiten der fehlertoleranten OSEKtime-Variante, sind diese Konzepte verstärktim Forschungsbereich innerhalb der E/E-Architekturen von PKWs appliziert worden.Diese Entwicklung lag nicht zuletzt an den bisher nicht verfügbaren serienreifen feh-lertoleranten Netzwerktechnologien für das Fahrzeug5. Mittlerweile werden etablierteOSEK/VDX-kompatible Softwaremodule durch adjazente Gruppen an Softwaremodu-len des AUTOSAR-Standards sukzessive ersetzt.

2.2.6.3. AUTOSAR

Die größte internationale Standardisierungsinitiative der letzten Jahre im Bereich derE/E-Entwicklung im Automobilbereich bildet das AUTOSAR-Konsortium (Automoti-ve Standard Software Architecture) /[AUT07a]/. Basierend auf dem Erfolg des OSEK-Standards in der Entwicklung von eingebetteten Systemen im Fahrzeug hat sich AU-TOSAR zum Ziel gesetzt einen allgemeinen E/E-Standard zur vereinfachten Integrationund Austauschbarkeit von Softwaremodulen zu etablieren /[H. 06]/. Die Entwicklungdes Standards umfasst dabei folgende Kernbereiche:

Modularer Aufbau von Applikationssoftware: Aufgrund des hohen Innovationspoten-tials kundenorientierter Softwarefunktionen soll zukünftig eine stärkere Trennung vonSteuergerät- und Funktionsentwicklung möglich werden. Mittelfristig werden Funkti-onsmodule als Bibliotheken separat entwickelt, welche individuell in verschiedensten

5Mit dem TTCAN-Standard /[Rob02]/ existiert zwar eine erweiterte Spezifikation des CAN-Standardszur Abdeckung der fehlertoleranten Anforderungen im Zeitbereich. Dieser Standard hat bis heute jedochin der Praxis keine signifikante Bedeutung erlangt.


Steuergeräten verbaut werden können. Ziel dieses Ansatzes ist die weitgehende Unab-hängigkeit bei der Entwicklung von Applikationssoftware von dem zugrunde liegendenSteuergerät und in der Vereinfachung der Partitionierung. So kann beispielsweise eineFensterheberfunktion unabhängig von dem Lieferanten eines Türsteuergeräts vom Fahr-zeughersteller erworben und in die E/E-Architektur integriert werden.

Basis für diesen Ansatz ist die Idee eines virtuellen Kanals VFB (Virtual Functio-nal Bus) im Fahrzeug zum Austausch von Funktionssignalen. Dieser residiert auf demKonzept einer einheitlichen Laufzeitumgebung RTE (Runtime Environment), welche inAUTOSAR-konformen Steuergeräten implementiert wird (s. Abb. 2.18).

VFB

BSW

RTE

BSW

RTE

ApplicationSWC

A

ApplicationSWC

B

ApplicationSWC

C

Communication Bus

Ports

Application

AUTOSARInfrastructure

Sensor Hardware

communication pathcommunication path

Abbildung 2.18.: Hardwareabstraktes Konzept des virtuellen Übertragungskanals für Applika-tionssoftwarefunktionen /[H. 06]/

Modularer Aufbau von Basissoftware: Zur Komplettierung der Applikationssoftwaregilt es analog einen Standard zu entwerfen, der die Architektur grundlegender Softwa-refunktionen und -dienste spezifiziert. Zu diesem Gebiet zählen hardwarespezifischerSoftwaremodule wie Speicherdienste, Hardwaretreiber und -abstraktionsschichten so-wie Treiber und Dienste für Netzwerktechnologien (CAN, FlexRay) (s. Abb. 2.19).

Legend:

AUTOSAR Release 1.0

AUTOSAR Release 2.0

ComplexDrivers

Microcontroller

AUTOSAR Runtime Environment (RTE)

MicrocontrollerDrivers

MemoryDrivers

I/O Drivers

I/O HardwareAbstraction

Memory HardwareAbstraction

MemoryServices

Onboard DeviceAbstraction

CommunicationDrivers

CommunicationHW Abstraction

Application Layer

CommunicationServices

System Services

Abbildung 2.19.: Elemente einer AUTOSAR Basissoftwarearchitektur /[H. 06]/

Besondere Aufmerksamkeit erfährt in diesem Kontext die Spezifikation und Ent-wicklung der Netzwerkkommunikationssoftwaremodule (s. Abb. 2.20). Daher wird derAusdruck Basissoftware in der Regel mit den spezifischen Modulen zur Netzwerkkom-munikation verbunden.


Communication Services

Communication Drivers

XC

P T

rans

port

Pro

toco

lon

CA

N

Communication Hardware Abstraction

CAN Driver

Driver for ext.CAN ASIC

SPIHandlerDriver

CAN Transport Protocol

PDU Router

DCMDiagnostic

Com.Manager

AUTOSAR COM

CAN NM

GenericNM

μCSPI CAN

ExternalCAN Controller

CAN Interface

IPDU multiplexer

CAN TransceiverDriver

DIO Driver

Abbildung 2.20.: Elemente einer AUTOSAR CAN-Basissoftwarearchitektur /[H. 06]/

Entwicklungsmethodik: Zur Anwendbarkeit der entwickelten Softwarearchitektur ist ei-ne konkrete Entwicklungsmethodik notwendig. AUTOSAR versteht dabei die Definitioneines Prozesses und entsprechender Schnittstellenspezifikationen hinsichtlich der Abde-ckung der Softwarekonfiguration und anschließender Codegenerierung (s. Abb. 2.21).

conforms to

- Schema -ECU

ConfigurationTemplate

- XML -ECU

ConfigurationDescription

conforms to

GenericECU

ConfigurationEditor

DedicatedModule

Generator

Provided by AUTOSAR

Provided by Implementer

automatically generated

DedicatedBSW

Module

module configuration module generation

- Schema -Configuration

ParameterTemplate

- XML -Configuration

ParameterDefinition

Autosar Integrator

edit

Abbildung 2.21.: Prozessschaubild und Schnittstellen der AUTOSAR-Entwicklungsmethodik/[H. 06]/


Die Komplexität und der Umfang der Inhalte in der AUTOSAR-Standardisierungsind allgemein sehr hoch einzustufen. Erschwerend muss dabei die Tatsache miteinbe-zogen werden, dass keine spezifischen Vorgaben hinsichtlich der Definition der konkre-ten Werkzeugentwicklung zur Unterstützung des Standards existieren.

Um den allgemeinen Anstieg der Komplexität in der E/E-Entwicklung langfristig be-gegnen zu können müssen jedoch weitere Entwicklungen im Bereich der Beschreibungs-sprachen zum Entwurf, Integration und Verifikation von Softwarefunktionen ergänztwerden. Zusätzlich müssen korrelierende Anforderungen hinsichtlich des Zeitverhal-tens und der Systemzuverlässigkeit von eingebetteten Softwarefunktionen konkretisiertwerden.

2.3. Entwicklungsmethoden der verteilten Realzeitentwicklung

In diesem Abschnitt wird der Systembegriff innerhalb dieser Arbeit mit seinen Schnitt-stellen zur Systemumwelt informell erläutert. Dabei werden Einprozessor- von den Mul-tiprozessorsystemen abgegrenzt. Auf Basis der Systemeinordnung lässt sich der Zusam-menhang zu Systemspezifikationsebenen ziehen. Zusätzlich werden die beiden signifi-kanten Kernthemen Zeitverhalten und Zuverlässigkeit im Bereich der Systementwicklungzusammengefasst.

2.3.1. Grundbegriffe und Systemkontext

Um die Anforderungen und Bedeutung des Designs eines verteilten eingebetteten Echt-zeitsystems eindeutig darzustellen, wird im Folgenden die Bedeutung der einzelnenTeilbegriffe definiert:

System: Nach /[JKR63]/ besteht ein System aus einer Reihe von Komponenten, dessenDesign zur Erfüllung eines speziellen Ziels passend zum Plan dient. Grundsetzlichentsteht ein System bei der Anordnung von miteinander in Beziehung stehendenEntitäten, die von ihrer Umgebung abgegrenzt werden können und sich als struk-turierte Einheiten auffassen lassen /[DIN97], [ISO93]/. /[Mil73]/ bezieht den Sys-tembegriff auf einen Satz an Konzepten und/oder Elementen zur Anforderungs-erfüllung. Die Definition von /[Wym76]/ konkretisiert den Begriff in technischerHinsicht. Aus seiner Sicht gehört zu einem System notwendigerweise Eingabe-,Zustands- und in einigen Fällen auch Ausgabedefinitionen. Der Zusammenhangzwischen Systemzustand und Eingabewerte ist elementar zur Beschreibung desSystemverhaltens. Jeder Systemzustand muss jederzeit über alle relevanten Infor-mationen zur Berechnung der gewünschten Systemausgabe verfügen. Der sehrallgemeine Begriff System wird in /[MG06]/ noch weiter vertieft.

Verteiltes System: Ein verteiltes System beschreibt eine Menge unterschiedlicher ört-lich getrennter Prozesse, die miteinander über den Austausch von Nachrichtenkommunizieren können /[Lam78]/./[CDK01]/ greift den Begriff technischer auf,indem nicht wie bei /[Lam78]/ von Prozessen, sondern von verteilten Hard- undSoftwarekomponenten innerhalb von Rechnernetzen gesprochen wird, die nach-richtenbasiert kommunizieren und ihre Aktionen koordinieren. Aus Sicht einesBenutzers sieht /[TS06]/ ein verteiltes System als Menge unabhängiger Computer-systeme, die dem Anwender den Eindruck suggerieren als würde es sich um einen

2.3. ENTWICKLUNGSMETHODEN DER VERTEILTEN REALZEITENTWICKLUNG 45

einzelnen Computer handeln. Tiefere Einblicke werden in /[VR01], [Web94]/ ge-geben.

Eingebettetes System: /[Kop97]/ charakterisiert ein eingebettetes System als perma-nentes Teilelement eines gut spezifizierten größeren Systems, welches als intelli-gentes Produkt bezeichnet wird. Dieses besteht aus einem mechanischen Subsys-tem, den kontrollierenden eingebetteten Computer und meistens einer Mensch-Maschine-Schnittstelle (Human Machine Interface).

Echtzeitsystem: Ein Echtzeitcomputersystem ist ein Computersystem, in dem die Kor-rektheit des Systemverhaltens nicht nur auf logischen Berechnungsergebnissen ba-siert, sondern auch von der physikalischen Instanz abhängt, welche die Ergebnisseproduziert. Entscheidend für die einwandfreie Funktionsweise zeigt sich, nebender Qualität und Korrektheit von Ergebnissen, der Zeitpunkt, wann diese Ergeb-nisse erzeugt werden /[Som01], [Kop97]/.

Wenn die verschiedenen Teilbegriffe eines verteilten eingebetteten Echtzeitsystems zu-sammengefasst werden, lässt sich demzufolge exakt das komplexe heterogene Umfelderfassen, dem die Fahrzeug-E/E zugerechnet wird. Das Gesamtsystem Fahrzeug liegtdabei eingebettet in dem wechselseitig abhängigen Echtzeitsystem, bestehend aus Fah-rer, Fahrzeug und Umwelt (s. Abb. 2.22).

Fahrer

Fahrzeug

Umwelt

Kon

tinui

erlic

he/D

iskr

ete

Ein

gabe

n

Kontinuierliche/D

iskreteS

teuerung

Kontinuierliche/Diskrete Eingaben

Kontinuierliche/D

iskreteR

egelung

Kon

tinui

erlic

he/D

iskr

ete

Rüc

kgab

en

Kontinuierliche/D

iskreteR

ückgaben

Abbildung 2.22.: Wirkungsdreieck Fahrer, Fahrzeug und Umwelt

Fahrer: Der Fahrer erhält über die Umwelt diskrete oder kontinuierliche Eingaben, bei-spielsweise Temperatur, Helligkeit, Geräusche, Verkehrsverhalten, welche direktsein Verhalten beeinflussen. Diese Vorgaben in Kombination mit seinen umwelt-unabhängigen subjektiven Zielen führen zu den Eingaben, welches das Fahrzeugüber den Fahrer erhält. Dazu gehören diskrete Aktionen, beispielsweise mittelsTaster oder Schalter und kontinuierliche Eingaben, z.B. der Lenkwinkel oder diePedalstellung, welche auf den Gesamtzustand Fahrzeug wirken.

Fahrzeug: Anhand der Fahrereingaben kann das Fahrzeug entsprechend reagieren, in-dem diese Werte an die Eingangsschnittstellen der Steuer- und Regelsystemengelegt werden. Bei den Regelsystemen werden zusätzlich die Ausgangsgrößen an


die Steuereinheit zurückgeführt, um einen Vergleich mit dem erwünschten Soll-Wert ziehen und das System in einem gewünschtem Zustand erhalten zu kön-nen. Zusätzlich leitet das Fahrzeug über Sensorik autonom Informationen aus derUmwelt ab, beispielsweise mit Regen-, Licht- oder Beschleunigungssensorik undübergibt diese als Eingaben an seine elektronischen Systeme. Als Schnittstelle zumFahrer werden Informationen kontinuierlich zum Beispiel in Form einer aktivenLenküberlagerung oder diskret durch visuelle/akustische Ausgaben im Cockpitzurückgegeben.

Umwelt: Die Schnittstelle zum Fahrer lässt sich allgemein als unidirektional beschrei-ben, da der Fahrer, abgesehen von dessen Gestik und Mimik, nicht direkt auf dieUmwelt einwirkt, sondern nur über das Fahrzeug als Zwischenschnittstelle. DasFahrzeug selbst kann im Gegensatz dazu mit der Umwelt interagieren. Als Beispielkönnte wie zu Beginn das ACC genannt werden, welches sich bei zweckmäßigemDesign auf das Verkehrsverhalten adaptiert ohne dabei kettenreaktionsartige Ein-flüsse auf die ACC-Systeme nachfolgender Fahrzeuge zu erzeugen.

Abbildung 2.23.: Szenario eines Car2Car-Kommunikationsnetzwerks /[Car06]/

Ein weitreichendes Beispiel bildet die Fahrzeug-Zu-Fahrzeug-Kommunikation (Car2Car-Communication), bei der sich die Fahrzeuge und Umwelt mithilfe von multihop Adhoc-Netzwerken gegenseitig verständigen können /[Fre05]/.

Rea

le, s

imul

ierte

Fa

hrze

ugm

gebg

ung Akt

orik

Sens

orik

Leistungselektronik

Ein

gabe

/Aus

gabe

-S

chni

ttste

lle

Analoge Signal-verarbeitung

Digitale Signal-verarbeitung S

yste

m K

ontro

lle

Ene

rgie

vers

orgu

ng

System/System-Kommunikationsschnittstelle

Opt

isch

Mec

hani

sch

Ther

mis

chEl

ektri

sch

Mag

netis

chC

hem

isch

Bio

logi

sch

Abbildung 2.24.: Steuergerätkomponenten eingebettet in die Fahrzeugumgebung als heterogenesSystem


Wenn der Ansatz auf ein Steuergerät als Standardkomponente der Fahrzeug-E/E verfei-nert wird, ergibt sich ein heterogenes System /[Bor94]/. Diese Bezeichnung entstammtder Mischung aus digitalen elektronischen Komponenten mit dazugehöriger Softwareund analogen Elektronik- sowie nichtelektronischer Sensorik-/Aktorikkomponenten.

Funktion: Jedes elektrisch/elektronische System eines Fahrzeugs wird durch die Im-plementierung eindeutiger Funktionen gekennzeichnet. Dabei propagiert sich derBegriff Funktion über die verschiedenen Fahrzeugdomänen und scheint oftmalsnicht sauber definiert zu sein. Zum Beispiel ist zu unterscheiden, ob eine Funkti-on sich auf das Interaktionsdreieck Fahrer/Fahrzeug/Umwelt oder aber auf eineSystemkomponente und dessen Ein- und Ausgabeschnittstellen bezieht. /[Gri01]/bezeichnet eine Funktion in einem eingebetteten System als das Ergebnis des Zu-sammenspiels von Rechner und Umgebung. /[SZ03]/ versteht unter Funktion dieFunktionsmerkmale eines Fahrzeugs, die durch den Benutzer, in der ersten Liniedurch den Fahrer des Fahrzeugs, direkt oder indirekt wahrgenommen werden undfür ihn einen Wert oder Nutzen darstellen. In dieser Arbeit bezieht sich die Funkti-on in gleichem Sinne auf das technisch oder durch den Menschen wahrnehmbarezeitabhängige Verhalten einzelner oder mehrerer sich in Interaktion befindlicherKomponenten des Fahrzeugs. Eine Abstraktionsstufe höher müssen Funktionenüber Funktionen zum Beispiel zur Verknüpfung von Fahrzeug- oder Fahreras-sistenzsystemen angesiedelt werden. Das bedeutet, dass Funktionen als logischeKomponenten betrachtet werden können, die die Konzepte der Hierarchisierung,Modularisierung, Strukturbildung und Atomarisierung unterstützen. Funktionensollten klar durch ihre Anforderungen und nicht durch ihre Lösungsvarianten ge-kennzeichnet sein. So spielt es auf dieser Ebene keine Rolle, ob eine Benutzerin-teraktion akustisch oder visuell zu erfolgen hat. Eine derartige Differenzierung inder Funktionsrealisierung muss sich demzufolge auf einer Designebene vollzie-hen, die getrennt vom Kontext der zugrunde liegenden Funktion betrachtet wird/[FSV99]/. Neben der informellen Darstellung lässt sich der Funktionsbegriff inder Fahrzeug-E/E auch rein mathematisch interpretieren (s. Abs. 4.2).

Die erläuterten Teilbegriffe müssen in dem Zusammenhang unter den spezifischen Ge-sichtspunkten der Automotive Embedded Systems betrachtet werden mit einem hohenGrad an Innovationen und Veränderungen in der Fahrzeugentwicklung, die im Gegen-satz zu anderen Branchen mit zusätzlichen Anforderungen im Prozess der Wertschöp-fung und für die Erfüllung gesetzlicher Vorschriften zu kämpfen hat. Das spiegelt sicheinerseits in der starken Einschränkung an technischen Ressourcen wie Speichergrö-ße und Rechenleistung im Elektronikbereich durch den Einsatz von kostenoptimiertenHardware-Komponenten und zum anderen in Anforderungen an Echtzeitfähigkeit insicherheitskritischen Systemen des Fahrzeugs wieder /[FBR+06]/. Außerdem gibt es inwenigen Branchen eine derartige Vielfalt an unterschiedlichsten Zulieferer, welche zudem Gesamtprodukt beitragen.

2.3.2. Einprozessor- und Multiprozessorsysteme

Die Konzentration der Systementwicklung hat sich in den vergangenen Jahren vorran-gig auf die Entwicklung von Komponentenlösungen auf Basis von Steuergeräten (s.Abb. 2.25 und vgl. /[SZ03]/) beschränkt. Steuergeräte haben einen gemischt diskret-/kontinuierlichen Charakter, da kontinuierliche Datenflüsse aus analogen Sensoren


empfangen und gleichzeitig durch einen Mikroprozessor oder dedizierten digitalen Si-gnalprozessor (DSP) verarbeitet werden müssen. In diesem Ansatz beziehen sich Einpro-zessorsysteme auf Steuergeräte in Form technisch gekapselter Einheiten. Obwohl in spe-ziellen Fällen auch zwei Prozessoren auf einem Steuergerät verbaut werden, motiviertdurch sicherheits- oder performanztechnische Gründe, wird bei Multiprozessorsyste-men in diesem Zusammenhang von physikalisch verteilen Komponenten gesprochen,die innerhalb eines Netzwerks verbunden sind.

Operating System

Flash Loader

Diagnostic Protocol

Network Layer

Function_2

Interaction Layer

Function_1

ECU_1

Function_3

Communication Hardware

HAL

NM

Ap

pli

ka

tio

ns

eb

en

e

Pla

ttfo

rmeb

en

e

Fu

nkti

on

sic

ht

Ko

mm

un

i-ka

tio

ns

sic

ht

Driver

Sys

tem

sic

ht

Lo

wL

evel-

Ko

mm

un

ika

tio

n

Mid

dle

wa

re-

Ko

mm

un

ika

tio

n

Hig

h-L

evel-

Ko

mm

un

ika

tio

n

Applikation

Darstellung

Sitzung

Transport

Vermittlung

Sicherung

Bitübertragung

Abbildung 2.25.: Modularer Aufbau eines OSEK-konformen Steuergeräts mit geschichteten Ab-straktionsstufen

Um die Komplexität eines Steuergeräts zu beherrschen und dessen Software-Kom-ponenten getrennt entwickeln und pflegen zu lassen, hat sich ein monolithischer An-satz als inadäquat erwiesen. Durch den OSEK-Standard (s. Abs. 2.2.6), ist ein Schrittin Richtung modulare Architektur erzielt worden. Mit der Dekomposition der Soft-ware in Module lassen sich auch verschiedene Abstraktionsstufen für ein Steuergerätdeklarieren. Neben dem ISO/OSI-Ansatz lässt sich das Steuergerät prinzipiell in dreiStufen zerlegen. Die LowLevel-Kommunikation bezeichnet die Funktionalität der Module,welche an den Schnittstellen zu den physikalischen Netzwerk-Controllern oder weite-ren Ein-/Ausgängen liegen (Hardware Abstraction Level). Die Middleware-Kommunikationdeckt die Module ab, welche System-/Kommunikationsdienste den höheren Schich-ten bereitstellen, damit diese möglichst unabhängig von den technischen Komponen-ten entwickelt werden können. Darum wird allgemein bei LowLevel- und Middleware-Software integriert von Basissoftware gesprochen. Aus der Sicht eines Echtzeitbetriebs-systems werden die abzuarbeitenden Aufgaben, in /[HOP05]/ als Jobs bezeichnet, inPakete gebündelt und innerhalb von Tasks durchgeführt. Kommunikationstasks werdennach dem für die Koordination der Tasks erstellten Ablaufplan, dem Task-Schedule, im-plementiert. Diese speziellen Tasks übernehmen die Aufgaben des Beschreibens vonPuffern des Netzwerkcontrollers und des Lesens der für die Netzwerkkommunikationallokierten Speicherplätze. Für typische Systemdienste, beispielsweise der Systemdia-gnose, dem Netzwerkmanagement oder für höhere Transportprotokollaufgaben, eignetsich die Bezeichnung Systemtasks. Die eigentlichen technisch-funktionalen Aufgaben desSteuergeräts, etwa die Ausführung eines Regelungsblocks eines E/E-Systems, werdenin Funktionsteilen als Applikationstasks abgearbeitet. Da ausschließlich die Funktions-blöcke der Applikationstasks ein Steuergerät charakterisieren, lassen sich Produktlinienanhand der spezifischen Applikations- oder Anwendungssoftware vom restlichen An-


teil an Plattformsoftware abgrenzen. Da die Bezeichnung Plattform speziell bei hoherSteuergerätestückzahl innerhalb verteilter Systeme appliziert wird, kommt der Begriffspeziell bei den Mehrprozessorsystemen zum tragen.

Die Entwicklung von Einprozessorlösungen in Form eines einzelnen Steuergerätsbietet prozesstechnische Vorteile, da sich die Verteilung von Funktionalität, beispiels-weise einem Steuer- oder Regelsystem, auf jeweils einen Zulieferer beschränkt und sichdamit einfach in den Gesamtentwicklungsprozess integrieren lässt. In diesem Zusam-menhang liegt die Anforderung für den Systemintegrator vor allem in der präzisenBeschreibung der Applikationsschnittstellen des Systems, während der Zulieferer selbstsein Wissen im Bereich der Algorithmik der zu implementierenden technischen Funk-tionen einsetzt. Dennoch spielt der Systementwurf der Funktionalität auf Anwendungs-ebene auch aus Systemintegratorsicht eine wichtige Rolle, da es in dessen Verantwor-tungsbereich liegt die komplexen Systeme präzise zu spezifizieren und zu verstehen.Dadurch ist er in der Lage die entwickelten Systemlösungen eigenständig zu testen, umdiese fehlerfrei in seine E/E-Architektur zu integrieren.

Eine Schlüsselaufgabe für die Spezifikation des Einprozessorsystems liegt in der Be-schreibung des funktionalen Verhaltens einer physikalischen Systemkomponente, einesSteuergeräts, durch entsprechende Spezifikationsformalismen. Dafür eignen sich dreiverschiedene Sichten.

Statische Architektur: Aus Sicht der logischen Funktionen des Steuergeräts könnenKomponenten hierarchisch im Form von Strukturdiagrammen beschrieben wer-den. Die Komponenten werden dabei als Blöcke beschrieben, die über dedizierteSchnittstellen in Form von Ports kommunizieren können. Die Konnektoren zwi-schen den Ports basieren je nach Modellierungssprache aus uni- oder bidirektio-nalen Signalübertragungsstrecken, die je nach Ansatz bidirektionale Ports oderunidirektionale Ein-/Ausgabe-Ports zur Kommunikation mit einer Systemkom-ponente benötigen. Welches Kommunikationsprinzip den Konnektoren zugrundeliegt kann in der Notation berücksichtigt werden. /[AUT07a]/ unterscheidet bei-spielsweise zwischen Client/Server- und Sender/Receiver-Kommunikation.

Dynamisches Verhalten: Um das dynamische Verhalten der Funktionen zu beschrei-ben, eignen sich zwei etablierte Notationsformen, welche seit der letzten Dekadein der Automotivebranche zum Systementwurf herangezogen werden. Ereignis-diskrete Vorgänge orientieren sich in dem Zusammenhang an den Konzepten derendlichen Zustandsmaschinen, deren Transitionen abhängig von einem vorgege-benen Takt gegenüber einer Vorbedingung geprüft und gegebenenfalls ausgelöstwerden. Zur präzisen Definition von Zustandsautomaten und zur Unterscheidungder Varianten Mealy und Moore wird auf /[Mea55], [Moo56]/ verwiesen. Eineweitverbreitete Darstellungsform für endliche Automaten ist von Harel entworfenworden. Seine Statecharts bieten Notationsformen zur hierarchischen Dekomposi-tion von Automaten durch Unterautomaten und zur Komposition von parallelenausführbaren Zustandsautomaten. Weiterhin lassen sich Zustandsübergänge mit-hilfe temporaler Logik ausdrücken. Eine Konzept dabei basiert auf der bedingtenErweiterung von Transitionen durch Konnektoren zur Abbildung situationsabhän-giger Wechsel in einen von mehreren paarweise disjunkten Zielzuständen. Präzi-ser werden diese und weitere syntaktische und semantische Eigenschaften vonStatecharts in /[Har84], [Har87]/ vorgestellt.


Im gemischt diskret/kontinuierlichen Bereich haben sich signalflussorientierte No-tationen etabliert, welche in Form von Blockdiagrammen dargestellt werden. Da-bei können kontinuierliche, diskrete oder gemischte Systeme, wie sie in der Steuer-und Regelungstechnik auftauchen, so genannte Hybride, modelliert und simuliertwerden. Zwischen dedizierten Ein- und Ausgangssignalen werden Blöcke model-liert, hinter denen verschachtelte Subdiagramme gelegt werden, mit denen sichdiskrete und kontinuierliche Systeme abbilden lassen.

Interaktion: Während die statische Architektur die Systemstruktur und dessen Kom-munikationsverbindungen beschreibt, stützt sich das dynamische Verhalten aufden direkten Einfluss von Eingaben auf Systemkomponenten und dessen Ausga-ben. Zwischen diesen beiden Sichten fehlt eine dritte Sicht zur Beschreibung desAblaufs der Interaktion zwischen Komponenten auf Basis von Signalflüssen. Mit-hilfe von Interaktionsszenarien lässt sich die zeitliche Abfolge von Nachrichtenspezifizieren. Vergleichbare Notationsformen bestehen in den Sequenzdiagram-men der UML /[OMG06]/ oder den MSC (Message Sequence Charts) /[Int99a]/aus dem Telekommunikationsbereich, welche in Kombination mit der Prozessbe-schreibungssprache SDL (Specification and Description Language) /[Int99b]/ verwen-det werden.

Output(Actors, Network)Input(Sensors, Network)

ESP_V2

Fct_ASR Fct_AFS

Fct_Brake_Advanced

Fct_ABSFct_HHC

Fct_BDWFct_EBP

Fct_ESP

Fct_CDCFct_CDC

Input(PowerSupply (Clamp 15, Clamp 30))

Output(PowerSupply(CAN H, CAN L))

Abbildung 2.26.: Funktionale Architektursicht auf ein ESP-Steuergerät

Exemplarisch sollen die drei Sichten anhand eines vereinfachten Steuergeräts zur Sta-bilitätskontrolle ESP (Electronic Stability Program) (s. Abb. 2.26) dargestellt werden. Fürdiesen Zweck wird ein einfacher möglicher Querschnitt auf die statische Systemstrukturdes ESP aus Sicht der funktionalen Architektur dargestellt. Dabei zeigt sich, dass ver-schiedene Funktionsmodule innerhalb dieser physischen Netzwerkkomponente verbautsind und teilweise unterschiedliche Hierarchiestufen besitzen. So werden bremsenspezi-fische Funktionen wie die Berganfahrhilfe, das Antiblockiersystem, die Bremsscheiben-wischer und die elektronische Parkhilfe in einem Modul Advanced Brake gebündelt. AmEingang liegen die Daten, die über die Sensorik oder ein Netzwerk empfangen werden,in Form von Datenströmen an, welche in der Abbildung allgemein als Eingangskanalabstrahiert werden. Analog werden am Ausgang Datenströme auf die Aktoren und dasNetzwerk gelegt. Separat werden die Ein- und Ausgänge zur Leistungsversorgung desSteuergeräts bzw. des Transceivers als Netzwerkschnittstelle dargestellt.

Eine verfeinerte Darstellung des Eingangskanals auf Signalebene (s. Abb. 2.27) veran-schaulicht, dass bereits die wenigen Signale, welche die reine Stabilisierungsfunktion be-daten, zu einem wesentlich komplexeren Systemstrukturdiagramm führen. Daraus lässt


��

��

��

��

��

��

��

��

��

��

��!"#��!�$�#%&'#�!�$�#*+��

��!"��-#�'#��-#.��

��%

��/��

��2

��4��!��.��4��!��

��4��!��.

��4��!��

��.��!��!��6�

��.�76��6��!��!��6�

��-��4��6��

��

�84

��!�

��

6�6�

��

��

��

6�7�

�7!�

��

��

�76�

�8

9��

��

�8

4�

�!��

�6�6

�

��

�:

��;

<�

�6�6

�

�$

$��

��

76��

89

��

��

��

6�

�$

$��

��:

��;

<�

�6�6

��

4��7

�

Abbildung 2.27.: Verfeinertes Systemstrukturdiagramm bezogen auf das ESP-Funktionsmodulim ESP-Steuergerät

sich ableiten, welche Bedeutung der Hierarchiebildung und der Kapselung von Funktions-blöcken in einem Modell zufließen. Ohne Abstraktionsstufen lässt sich die Komplexitäteines ESP-Steuergeräts nicht mehr sauber abbilden.

Sleep

[Inital]

[Clamp 15 On] Normal_Safe_Dynamic_State

Standby_Safe_Dynamic_State

[ESP Off]

Normal_Critical_Dynamic_State

[Wheelspeed_To_EngineTorque_Ratio_Value_Deviation]

[Compute_Wheelspeed_To_EngineTorque_Ratio] [Compute_Wheelspeed_To_EngineTorque_Ratio] / Send_CorrectionValues

[Wheelspeed_To_EngineTorque_Ratio_Safe]

[Emergency Braking Values || Wheelspeed_To_EngineTorque_Ratio_Critical]

[Clamp 15 Off]

Emergency_State

[Inconsistent Input Values || Network Bus Off ]



Abbildung 2.28.: Zustandsmaschine zur Darstellung der Systemmodi des ESP

Das dynamische Verhalten lässt sich in einen ereignisdiskreten Anteil gliedern, derdie Systemzustände (Modi) des ESP abdeckt (s. Abb. 2.28). Für den gemischt diskret/-kontinuierlichen Anteil kommt der klassische ESP-Regler zum Einsatz, der heute mitt-


lerweile in fast allen Fahrzeugen angeboten wird. Da das vollständige System umfang-reiche Strukturen aufweist und nicht öffentlich vorliegt, zeigt das Datenflussdiagrammin Abb. 2.29 lediglich den konzeptionellen Grundaufbau eines ESP-Reglers.

RegeleinrichtungBremsenvorne linksvorne rechts

hinten linkshinten rechts

Stabiler Fahrzustand

Gierrate

Querbeschleunigung

Raddrehzahl

Lenkwinkel

Abbildung 2.29.: Datenflussdiagramm des Schemas einer Fahrdynamikregelung als Teil einesESP-Regelsystems /[Trö05]/

Die Signalflüsse sind unidirektional und innerhalb der Blöcke liegen Signalverknüp-fungen vor in Form von Differentialgleichungssystemen für den kontinuierlichen Teiloder als Zustandsmaschine für den diskreten Teil.

��

��

IR_RcvBuffer

Send_Buffer_To_Memory

Read_RcvBuffers

�$��!=��>��6��6�

��!��!��6�8�$

Compute_Wheelspeed_To_EngineTorque_Ratio

Send_Value_To_Memory

Compute_CorrectionTerm

Send_Value_To_Memory

Write_Memory_To_Buffer

IR_TxBuffer

�6��

Abbildung 2.30.: Zeitlich geordnetes Interaktionsszenario innerhalb der ESP-Regelfunktion

Als Beispiel für die Interaktionssicht wird ein vereinfachter Kommunikationsablaufin Abb. 2.30 dargestellt. Ein Sensorwert wird per Unterbrechungsroutine (Interrupt Ser-vice Routine) an eine Vergleichsfunktion weitergereicht, die den aktuellen mit dem kal-kulierten Soll-Wert vergleicht und den Differenzbetrag weitergibt. Dieser geht in dieBerechnung des Korrekturwerts ein, der in einen Sendepuffer geschrieben und an einenAktor übermittelt wird.

Der wesentliche Unterschied zwischen einem Einprozessor- und einem Multiprozes-sorsystem liegt in der Nebenläufigkeit von Prozessen und den getrennten Speicherberei-chen in einem physikalisch verteilten System. Prinzipiell kann durch Softwareschichtenein System so gekapselt werden, dass sich ein physikalisch verteiltes System gegenübereinem lokalen System aus Sicht der Anwendungsfunktionen identisch verhält.


Operating System

Flash Loader

Diagnostic Protocol

Network Layer

Function_2

Driver

Interaction Layer

Operating System Operating System

Function_3

Function_2 Function_4

Function_1

Function_2 Function_4Function_3

Function_1 Function_1

Physikalischer Kommunikationskanal

ECU_1 ECU_2 ECU_3

Virtueller Kommunikationskanal

Function_3


HAL

NM

Flash Loader

Diagnostic Protocol

Network Layer

Driver

Interaction Layer


HAL

NM

Flash Loader

Diagnostic Protocol

Network Layer

Driver

Interaction Layer


HAL

NM

Funktionenebene

Plattformebene

Abbildung 2.31.: Physikalisch verteiltes Mehrprozessorsystem auf Basis des OSEK-Standards

2.3.3. Systemspezifikationsebenen

Analog zu Einprozessorsystemen gilt auch bei Plattformkonzepten die Annahme, dassdie Funktionen über einen virtuellen Kommunikationskanal unabhängig von ihrer tech-nischen Komponentenzuordnung kommunizieren können. Folgende Aspekte eines ver-teilten plattformorientierten Multiprozessorsystems gilt es zu beachten:

Funktionsbeschreibung: Als Funktionsbeschreibung gelten die gleichen Konzepte, diebereits für Einprozessorsysteme dargestellt worden sind. Zusätzlich gilt es dieFunktionen konsequent uniform zu kapseln, damit eine leichte Verschiebung in-nerhalb des verteilten Systems ermöglicht wird. Bei hinreichend guter funktio-naler Dekomposition können Funktionsbibliotheken generiert werden, welche abge-schlossene Funktionalitäten wie zum Beispiel einen Fensterheber implementieren.Dieses Konzept ist als eines der Ziele im CARTRONIC-Ansatz verfolgt worden/[FGZA03]/. Eine Standardisierung eignet sich durchaus, da viele einfache Funk-tionen im Fahrzeug mittlerweile herstellerübergreifend nahezu identisch umge-setzt werden. Allgemein wird bei der verteilten Funktionssystembetrachtung voneiner logischen Systemarchitektur /[SZ03]/ gesprochen.

Partitionierung: Die Partitionierung beschreibt die Anordnung von logischen Funktio-nen auf technischen Komponenten. Diese Zusammenführung zwischen logischerund technischer Systemarchitektur wird auch allgemein als (Mapping) bezeichnet.Die Verknüpfungsbeziehungen werden dabei in unterschiedlicher Art und Wei-se spezifiziert. Die einfachste Variante stellt die Zusammenführung in tabellari-scher Form dar. Aber auch schablonenartige Ansätze eignen sich wie zum Beispieldie Description Templates zur System- und Steuergerätebeschreibung in AUTOSAR/[AUT07a]/ oder die System Blueprints von Marchetto /[Mar97]/. In /[FM98]/setzen Faboul und Martin im Bereich Mapping auf ein so genanntes Allocation Mo-del, welches die Zuordnung einer Partitionierung beschreibt. In /[SZ03]/ wird diePartitionierung im Automotive Segment beschrieben. Eine formale Beschreibungdazu wird in Abs. 4.2 aufgeführt.

Ressourcenbeschreibung: Zur Beschreibung der Ressourcen eignet sich die technischeSystemarchitektur. Dazu gehören die konkret existierenden Komponenten, die Steu-ergeräte. Die wesentlichen Leistungsmerkmale eines Steuergeräts liegen in derzentralen Recheneinheit, gegeben durch die Performanz im Datendurchsatz undVerarbeitungszeit in einem μ-Prozessor, einem μ-Controller oder einem Logikbau-


�!��;< �!��;<

�!��;< �!��;<

�!��;<�!��;< �!��;<

�!��;< �!��;<

�!��;<

(a) Heutige Komponentensicht und resultie-rende Einschränkungen für die Partitionie-rung

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��6�6�6��7��6$6��7

(b) Anzustrebende Systemsicht mit opti-mierbaren Funktionsmodellen

Abbildung 2.32.: Systempartitionierung auf Basis von abhängigen Funktionsmodellen

stein auf FPGA-Basis. Zusätzlich wird die Speicherleistung in Form von flüchtigenRAM- und beständigen ROM- oder Flash-Speichern beurteilt. Auch die technischeSchnittstelle zur Kommunikation in einem Netzwerk, bestehend aus einem In-terface, CCs (Communication Controllers), Konnektoren, in Form von Transceivernund analogen/digitalen Ein-/Ausgabeschnittstellen I/Os (Input/Output) wird demRessourcenumfang eines Steuergeräts zugeordnet.

Netzwerkbeschreibung: Die Konfiguration eines Netzwerks muss eindeutig zur fehler-freien Kommunikation beschrieben sein. Dazu gehören die Datenkommunikationund die Sende-/Empfangsbeziehungen in Form eines Sendeschedules oder einerKommunikationsmatrix der beteiligten Komponenten, eine Netzwerk- und Kno-tenkonfiguration des Kommunikationsprotokolls und die Spezifikation des phy-sikalischen Kommunikationsmediums. In einer Kommunikationsmatrix wird derSignalaustausch zwischen den Knoten festgelegt und die Botschaften des Kommu-nikationsprotokolls spezifiziert. Dabei sind unterschiedliche Zykluszeiten für dieSignalübertragung zu berücksichtigen, womit sich das Paketieren von Botschaftenauf eine NP-harte Aufgabenstellung zurückführen lässt, die an das Bin Packing-Problem /[JDU+74]/ erinnert. Die Entwicklung von Algorithmen und Heuristi-ken zur möglichst niedrigen Belastung des Kommunikationsmediums stellt einezentrale Herausforderung in der Fahrzeugvernetzung /[SN03], [SNA00]/ dar. Dieformale Spezifikation der Kommunikation erfolgt wie in Abb. 2.33 exemplarischaufgezeigt.

Das Netzwerk wird durch folgende Kommunikationsklassen bei der Signalüber-tragung belastet:

Zyklische Kommunikation: Diese Signale kommen im Allgemeinen von Funktio-nen, die den Zustand einer Komponente regelmäßig aktualisieren müssen. In/[Kop97]/ wird auch von Zustandssignalisierung gesprochen. Entscheidendfür die Bandbreitenbelastung wirkt die Zyklus- und die Signallänge.

Spontane Kommunikation: Funktionen mit ereignisgesteuertem Charakter, etwader Wert einer Schalterposition im Cockpit, übertragen ereignisdiskret dieSchalterposition im Netzwerk, um eine Belastung durch unnötig zyklischeÜbertragung zu vermeiden. Für die Ermittlung der Busbelastung muss dierelative Häufigkeit in Verbindung mit der Signallänge berechnet werden.

Serviceorientierte Kommunikation: Zu den Servicen zählen vorrangig höherwer-tige Datentransportprotokolle, die für die segmentierte Übertragung größererDatenpakete eingesetzt werden. Wichtig für die Busbelastung ist die Häufig-


S - zyklisches Signal

S - zyklisches wenn aktiv

S - ereignisgesteuertes

Signal

M - Motorola Format

ID-Name

Byte, Bit

Position Signalname Beschreibung Air

bag

All

rad

Sta

bil

isato

rE

SP

Gate

way_S

GG

etr

ieb

eL

en

kw

inkel

Mo

tro

nic

Waeh

lheb

el

Syste

mte

ste

r

Gate

way_S

G

Gate

way_S

G

Ko

mb

i

Park

assis

ten

t

Navig

ati

on

Rad

io

Ben

utz

erz

ug

an

gG

ate

way_S

GH

eck_S

GC

lim

atr

on

icS

itzste

uerg

erä

tS

tan

dh

eiz

un

gT

arg

a_S

GT

SG

_B

eif

ah

rer

TS

G_F

ah

rer

Wert

eb

ere

ich

No

rmie

run

g

Au

flö

su

ng

Bemerkungen/

Zuordnungstabelle

BRAKE_1 ID: 0x3A1

15 ms Zyklisch DLC: 8

1.0 B_bract Bremsmomenten-Eingriff S E E E S 1.0 1=Bremsmomenten-Eingriff aktiv

1.1 B_abs ABS-Bremsung E S E E E S 1.0 1=ABS-Bremsung aktiv1.2 B_trc Traktionskontrolle-

AnforderungS E E E S 1.0 1=Anforderung TRC

1.3 B_esp ESP-Eingriff E S E E E S 1.0 1=ESP-Eingriff aktiv… … … … … … …8.0...8.7 loacc Längsbeschleunigung E S E E E S E E -1.27 ..

1.27 g0.0-254.0

0.01 g positiv = Beschleunigung negativ = Bremsung

BRAKE_2 ID: 0x3B1

20 ms Zyklisch DLC: 8

1.1…1.7 laacc Querbeschleunigung E S E E E E S E E -1.27 .. 1.27 g

0.0-254.0

0.01 g positiv = Linkskurve negativ = Rechtskurve

… … … … … … … …

ESP

Änderungen

Antrieb Diagnose Infotainment Komfort

Abbildung 2.33.: Klassische Darstellung der Kommunikationsbeziehungen eines Antriebs-/Fahrwerks-CAN-Bus in Matrixform

keit, in der diese Dienste abgerufen werden sowie der Zyklusabstand und dieLänge der Botschaften innerhalb eines Services. Beispiele für diese Servicewären Datenprotokolle für Displayinformationen oder der Diagnosebetrieb.

Eine besondere Aufmerksamkeit erfordert der Einsatz von verteilten Funktionen, fallsFunktionsbefehle direkt über den Bus verschickt werden. Dabei lassen sich Funktionendirekt aufrufen (z.B. ABS-Bremsung). Eine zweite Variante bezieht sich auf den Fahr-zustand, indem Werte über den aktuellen Fahrzeugzustand, beispielsweise Passagierge-wicht/Dämpferlast, über das Netzwerk kommuniziert werden.

Die Netzwerk- und Knotenkonfiguration hängt stark von der jeweiligen Vernet-zungstechnologie ab. Im Allgemeinen werden dort Einstellungen bzgl. der Netzwer-kübertragungsrate und der Busphysik getroffen.

Die Netzwerktopologie beschreibt den konkreten Aufbau des Feldbussystems undseines Kabelbaums (Wiring Harness). Kabelbäume in heutigen Fahrzeugen haben einehohe Komplexität, da starke Anforderungen an Robustheit und Signalqualität herr-schen. Signalreflexionen müssen niedrig gehalten werden, indem eine zweckmäßigeTopologie implementiert wird. Dabei muss auch das elektromagnetische Ein-/Abstrahl-verhalten beachtet werden. Es gibt viele Möglichkeiten die Topologie zu gestalten, in-dem Sterne, Busse und Ringe konzipiert werden, die teilweise auch kaskadiert oder inhybrider Form verbaut werden. Die Signalqualität wird durch Drosseln, Kondensatoren,Schaltungen und Widerstände optimiert.

2.3.4. Zeitverhalten

Die Analyse des Systemverhaltens bezogen auf das uniforme Fortschreiten der physi-kalischen Zeit, trägt entscheidend zur Systemspezifikation eines verteilten eingebettetenEchtzeitsystems bei. Um diese Einflüsse im Systementwurf zu verstehen, werden diegrundsätzlichen Systemqualitätskriterien im temporalen Bereich (Timing) vorgestellt.


Leistung (Performance) definiert die Verarbeitungsgeschwindigkeit von Eingabedatenbezogen auf festgelegte Zeiteinheiten. Je nach Betrachtung kann sich dies abstrakt aufeine logische Funktion oder konkret auf einen Prozessor oder ein Busprotokoll beziehen.

Latenz (Latency) bezeichnet das Zeitintervall zwischen dem Auftreten eines Ereignissesund dem Beginn einer dem Ereignis zuordbaren Systemreaktion. Aus technischer Sichtlassen sich Latenzen folglich als Summe an diversen Teilverzögerungen im System auf-fassen.

Verzögerungen (Delays) werden technisch aufgrund unterschiedlicher Einflüsse provo-ziert. Die Qualität eines Algorithmus und die maximale Rechengeschwindigkeit einesimplementierten Mikrocontrollers werden für einen Netzwerkknoten erfasst. Der Vor-gang der Datenserialisierung zur Nachrichtenübertragung und die Ausbreitungsverzö-gerung von Signalen auf einem Kommunikationsmedium werden nicht den physika-lischen Einflüssen, sondern der Netzwerkkommunikation beim Nachrichtenaustauschzugerechnet.

Schwankungen (Jitter) bezeichnen die maximale Abweichung der nominalen System-verzögerung bei der End-zu-End-Kommunikation, welche aufgrund der Summierungvon variierenden Teilverzögerungen auf der Kommunikationsstrecke entsteht. Die Vari-anz der Teilverzögerungen bezieht sich auf dynamische Effekte, verursacht durch Sys-temauslastung oder externe Einflüsse.

Zeitmodell der elektrisch physikalischen Bitübertragungsschicht

Aus Sicht eines elektrischen Übertragungsmediums stellt der Einsatz eines hochfrequen-ten Bussystems bei 10Mbit/s eine Herausforderung im Sinne einer stabilen elektrischenSignalübertragung dar. Speziell der Kodier-/Dekodierprozess an den Kommunikations-controllern (CC) sowie die Signalwandlung an den Transceiver-Schnittstellen erfordertein präzises Verständnis während des Systemdesigns.

Im Rahmen der TBTF-Analyse (Timing Budget Task Force) des FlexRay-Konsortiumssind intensive Analysen durchgeführt worden, um die Qualität der End-To-End-Kom-munikation im Netzwerk zwischen beliebigen Knoten in unterschiedlichen Topologienabzusichern (s. Abb. 2.34). Aktuell gibt es bei vereinzelten Topologien kritische Grenzen,über die hinaus eine fehlerfreie Bitübertragung nicht gewährleistet werden kann (s. Abs.5.4).

Die wesentlichen Einflussfaktoren leiten sich dabei aus folgenden Effekten ab:

• Asymmetrische Verzögerung des Bussignals

• Ausbreitungsverzögerungen bei der Signalübertragung

• Flankenpegel

• Jittereffekte aufgrund von Quarzungenauigkeiten

Beispiel:

1. Die Länge eines übertragenen Bits beträgt 100ns bei 10Mbit/s Baudrate.


59 ns (= 75 ns - 16 ns)100 ns

Nominale Bitlänge

Relevant für Transceiver: Erwartetete minimale Bitzeit am Receivereingang (TP4)

Relevant für Decoder: Erwartete Asymmetrie am logischen Eingang

75 ns (= 100 ns - 10 ns - 15 ns)Receiver Eingang Logischer Eingang

Sendersteuergerät Empfangssteuergerät

BD BDTopologieCMCESDR_t

CMCESDR_t

CC CC

Statische und stochastische asymmetrischeAusbreitungsverzögerung

10 ns 15 ns 16 ns

x ns: Beispielwerte

Abbildung 2.34.: Darstellung der zu analysierenden Aspekte bei der Bitübertragung im elektri-schen Physical Layer (vgl. /[Fle06a] (adaptiert)/)

2. Da der Decoder am 5. Sample bei 8 Samplings pro Bitlänge den Bitwert abtastet,kann eine maximale Bitverkürzung um 3 ∗ 12, 5ns = 36, 5ns toleriert werden.

3. Durch einen Beitrag des Bustreibers von 5ns und der ECU von 1ns abzüglich einespositiven Effekts bei der Umrechnung des Frame-Clock-Jitters (2 ∗ (−0, 5ns)) aufden Bit-Clockjitter (2 ∗ 0, 1ns) von 0, 9ns ergibt sich eine Toleranz von 36, 5ns −5ns − 1ns + 0, 9ns = 31, 4ns bei einem 80ns-FlexRay-Busreceiver.

In Tab. 2.2 wird eine reduzierte Übersicht zu den relevanten Parametern bei der Zeit-modellierung der elektrischen Bitübertragungsschicht bezogen auf die Bitlänge in einerTopologie dargestellt.

Zeitmodell der Protokollschicht

Bei zeitgesteuerter Kommunikation wird auch von „synchroner Datenübertragung“ inner-halb des verteilten Systems gesprochen. Informationen, gegeben als Signale innerhalbvon Botschaften, werden in einem vordefinierten Takt ausgetauscht. Dadurch lassen sichnur endliche Berechnungsvorgänge (Operationen) innerhalb eines Taktes durchführen.Um das Verhalten eines Systems über Zeit zu planen, muss eine lokale Sequenziali-sierung der Prozesse (Tasks) auf Knotenebene durchgeführt und das Ergebnis auf Eig-nung für die globale Netzwerkebene verifiziert werden (Schedulability-Analyse). Nebender Zuverlässigkeit gilt die Performanz als weiteres entscheidendes Qualitätsmerkmalin einem System als Teil einer E/E-Architektur eines Fahrzeugs. Für verteilte Multi-prozessorsysteme teilt sich diese Eigenschaft zwischen der Leistungsfähigkeit zweierKomponenten und dessen zwischengeschalteter Netzwerkkommunikation.

Für die Betrachtung der maximalen Verzögerung tges müssen zu den reinen Netz-werkübertragungszeiten mehrere Verzögerungen an den verschiedenen Schnittstellenaddiert werden:

t1 = tSensor→HostA: Beim Eintreffen eines Sensorwerts wird dieser in einer Systemtask


Verzögerungseffekte statisch (ns) stochastisch (ns)Kommunikationscontroller

I/O-Puffer 1 0,5Leiterplatten 0,5 0

EMV Transient 0 0CW/AM 0 0

Sicherheitsabstand individuell individuell

Bittakt (Clock Tree) PLL 0,5 0,16keine PLL 0 0,16

Quarztoleranz 1,5 0Bustreiber

Chip 4 0EMV 0 0

Flankensteilheiten/Schwellenwerte spezifisch spezifischSicherheitsabstand individuell individuell

Netzwerkverbindungen

Verkabelungp2p 0 4

Daisy Chain 0 8Maximum Net 0 8

Aktiver SternBustreiber 5 0

EMV 0 0Sicherheitsabstand individuell individuell

Chiptyp Monolithisch 3 0Diskret 5 0

ECU

HW-DesignLayoutDrossel 0,25 0,25

ESD-Schutz

EMV Transient 0 0CW/AM 0 0

Sicherheitsabstand individuell individuell

Tabelle 2.2.: Übersicht der elektrischen Physical Layer Timing-Parameter der TBTF-Gruppe

des Host-Betriebssystems gelesen und an eine Adresse im Speicher des Hosts Ageschrieben.

t2 = tHostA→CC−Tx: Innerhalb einer Kommunikationstask wird der aktualisierte Sensor-wert an einen Sendepuffer des Kommunikationscontrollers zum Senden über dasNetzwerk weitergereicht.

t3 = tCC−Tx→CC−Rx: Der Sendekommunikationscontroller verschickt je nach Medienzu-griffsverfahren den Sensorwert mit einer Verzögerung über das Netzwerk.

t4 = tCC−Tx→CC−Rx: Beim Eintreffen des Sensorwerts am empfangenden Kommunika-tionscontroller entsteht eine zeitliche Verzögerung durch das Ausführen einerKommunikationstask zum Auslesen des neuen Sensorwerts am Empfangspufferdes Kommunikationscontrollers und dem Schreiben an eine reservierte Adresseim Speicher des Hosts B.


t5 = tHostB: Der neue Sensorwert wird an eine Applikationstask und damit an denAlgorithmus eines Steuer-/Regelsystems übergeben, der seinerseits einen neuenWert für den reagierenden Aktor berechnet und diesen an eine reservierte Adres-se im Speicher schreibt.

t6 = tHostB→Aktor: Host B aktualisiert in einer Systemtask den Aktorwert anhand derneuen Daten an der definierten Adresse im Speicher des zugeordneten Aktors.

Input(PowerSupply

Input(Sensors)Output(Actors)

Output(PowerSupply(BP, BM))Input(PowerSupply

(Clamp 15, Clamp 30))

Input(Sensors) Output(Actors)

ACC_V1

Output(PowerSupply(BP, BM)

I/O VCC FxR-CC/- TRCV

FxR- COM- StackRTOS

Application

I/OVCC FxR-CC/- TRCV

FxR- COM- Stack RTOS

Application

Delayt1

t2

t3 t4

t5 t6

Physical Layer (Propagation Delay)Medium Access Layer (Bursts/Jitter/Delays)

(Clamp 15, Clamp 30))

Abbildung 2.35.: Verzögerungspunkte für Laufzeit einer Sensor-Aktor-Kommunikationsstrecke

Bei Übertragung einer Information zwischen den Komponenten Host A und Host Bentsteht eine netzwerkbedingte Sendelatenz. Die Gesamtverzögerung wird dabei phy-sikalisch bedingt durch eine Verzögerung bei der Signalausbreitung auf dem Übertra-gungsmedium (Propagation Delay). Zusätzlich wirken sich Netzwerkjitter (Network DelayJitter) aus, die vom Medienzugriffsverfahren des Netzwerkprotokolls abhängen (s. Abb.2.36).

��

��

��

��

��

��

��

��

��

��

��

��

��

��

JitterCSMA-Botschaft

(a) Variable Jitter innerhalb eines CSMA-basiertenNetzwerks

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Zyklische

Botschaften

TDMA-Zyklus

(b) Konstante Jitter innerhalb eines TDMA-basierten Netzwerks

Abbildung 2.36.: Unterschiedliches Zeitverhalten in ereignis- und zeitgesteuerten Netzwerkar-chitekturen

Der ereignisgesteuerte CAN-Bus unterliegt im Fahrzeug diesbezüglich stärkeren Ein-schränkungen im Vergleich mit dem zeitgesteuerten FlexRay-Cluster. Durch das CSMA-Verfahren hängt der Buszugriff bei CAN stark von den im Netzwerk aktiven Kom-ponenten ab. Durch eine Nachrichtenpriorisierung innerhalb der Arbitrierungsvorgän-ge auf dem Bus kann es zu unkalkulierbaren Verzögerungen kommen während dasTDMA-Konzept des FlexRay-Systems konstante Jitter garantiert (vgl. Abb. 2.36(a) mitAbb. 2.36(b)).


��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Abbildung 2.37.: Aufgeschaukelte Busbelastung durch Bursts beim parallelen Buszugriff

Speziell aufgeschaukelte Situationen, in denen simultan mehrere Buszugriffsanfra-gen von verschiedenen Knoten auftreten (Bursts), können eine Information innerhalbeines CAN-Busses massiv verzögern (s. Abb. 2.37). Diese Situationen entstehen oftmalsbeim Netzwerkhochlauf. Aufgrund des unzuverlässigen Verhaltens bei hohen Buslastennutzen Fahrzeughersteller die Bandbreite eines CAN-Feldbussystem sicherheitsbedingtnur zu maximal 70% aus.

Zusammenfassend kann die Gesamtübertragungsdauer einer Sensor/Aktor-System-reaktion wie folgt definiert werden:

tges =6

∑i=1

ti + tpropagationdelay + tjitter

Eine formale Analyse des Zeitverhaltens erfordert aufgrund der Heterogenität desSystems einigen Aufwand. In /[RZE+02], [RE02]/ wird ein Ansatz vorgestellt, der dasgesamte Zeitverhalten zerlegt, indem Architekturkomponenten im Gesamtsystem iden-tifiziert werden, für die bereits Analysemethoden zum Zeitverhalten bekannt sind. EineKomposition der Zeitverhalten der verschiedenen Komponenten ergibt ein komplexes,vollständiges Zeitverhalten des Gesamtsystems auf Systemebene. Das Konzept basiertgrundlegend auf der Definition ausgehender Ereignisströme (Event Streams) von Sen-dekomponenten, die assoziierte Ereignismodelle (Event Models) von Empfängerkompo-nenten treffen (matchen). Die Ereignismodelle müssen dabei die empfangenen Ereig-nisströme verarbeiten können. Dadurch kann formal der Zusammenhang der Kompo-sition von Architekturkomponenten und dem entstehenden zeitlichen Gesamtssystem-verhalten geschlossen werden. Einschränkungen bietet der Ansatz, durch seine Stan-dardereignismodelle. Diese stützen sich auf

• rein periodische,

• periodische mit Jitter,

• periodische mit Bursts und Jitter,

• rein sporadische

Übertragung. Die erzeugten Ereignisströme können das reale Verhalten lediglich appro-ximieren. Um Fehler in einem analysierten System auszuschließen, lassen sich hiermitkonservative Schranken durch eine Zeitanalyse definieren (Worst Case Bounds). Die Me-thodik wurde in dem Werkzeug SymTA/S implementiert /[HHJ+]/.


/[Kün06]/ setzt auf einem hybriden Ansatz aus simulativen und analytischen Ver-fahren auf, um die Performanz eines eingebetteten Systems zu bestimmen. Dabei liegtder Fokus darauf eine Mehrzieloptimierung durchzuführen, die der Entwickler mithilfevon Performanzindikatoren beeinflussen kann. Dies wurde mithilfe eines evolutionärenAlgorithmus entwickelt und durch ein Entwicklungsframework vervollständigt, um beider Entwurfsraumexploration eine minimale Anzahl an Komponenten zu identifizieren,deren Software im Systementwurf implementiert werden müssen.

Während das TDMA-Verfahren in einer zeitgesteuerten Architektur (s. Abs. 3) kon-stant deterministische Verzögerungen zwischen Pufferaktualisierung und Netzwerk-übertragung garantiert, treten in einer ereignisgesteuerten Kommunikation variable Ver-zögerungen auf. Bei eingeschränkt echtzeitfähigen Feldbussystemen wie dem CAN-Busspielt die Netzwerkauslastung diesbezüglich eine wichtige Rolle, da Performanz undZuverlässigkeit mit ihr gekoppelt sind.

Wichtig für die Berechnung der Netzwerkauslastung sind auch die Aktivitätszeit-punkte der Netzwerkteilnehmer, die durch die Klemmensteuerung oder externe Ereig-nisse bestimmt werden. Das selektive Abschalten von kommunikationsintensiven Kno-ten in bestimmten Situationen führt zu einem bandbreitenorientierten Teilnetzbetrieb,obwohl der Extremfall (Worst Case) einer maximalen Buslast in einem komplett aktivenNetzwerk berücksichtigt bleiben muss. Aktuell wird aufgrund des komplexeren System-verhaltens ein Teilnetzbetrieb ausgeschlossen und lediglich das Weck-/Schlafverhalteneinzelner Bussysteme im Sinne eines Netzwerk-/Energiemanagementkonzepts spezifi-ziert und angewendet.

Zusammenfassend lassen sich allgemein vier verschiedene Bereiche ableiten, die dasZeitverhalten des Gesamtsystems maßgeblich beeinflussen:

Knoten: Das dynamische Verhalten einer Netzwerkkomponente wird maßgeblich durchdie Anzahl und Ausführungszeiten der ihr zugeordneten Prozesse und deren Ressour-cenbedarf definiert. Dabei werden quantitative Aussagen über die Ausführungszeitenbenötigt, welche zeitbezogen für den jeweils schlechtesten Fall geschätzt werden müssen(WCETs). WCET-Schätzungen stellen ein altbekanntes Problem in der Systementwick-lung dar und sind bereits intensiv untersucht worden (s. Abs. 3.1.5.1).

Netzwerk: Das globale E/E-Architekturdesign wird durch die Ausprägung des Bord-netzes beeinflusst, beispielsweise durch die Einführung von Signal-Gateways und dieVerwendung heterogener Bustechnologien mit unterschiedlichen Konfigurationen. We-sentliche Elemente in dieser Betrachtung referenzieren auf die Effekte durch Burst Con-ditions, Delays und Jittern.

Erweiterung: Da eine Systemerweiterung in der Regel zu Effekten mit veränderten La-tenzen auf dem Bus (ereignisgesteuerte Kommunikation) und auf dem Knoten (Schedu-le) führt, gilt es die Anforderungen einer Kommunikationserweiterung im Lebenslaufder p2p-Kommunikationsstrecke genau zu beschreiben.

Funktionale Abhängigkeit: Bemerkenswert bei der Betrachtung der Zeitmodellierung istder Aspekt, dass bei einer Adaption im Zeitverhalten, beispielsweise durch die Modi-fikation der angenommenen WCET-Zeiten einer Task oder der Übertragungszykluslän-gen im Netzwerk, von der funktionalen Abhängigkeit zweier Steuergeräte x und y inder Regel abstrahiert wird. Die Anzahl der beteiligten Komponenten in der Kommuni-


kationsstrecke verkörpert dabei eine wichtige Kennzahl für die Erfassung der Komple-xitätstiefe einer E/E-Architektur.

2.3.5. Zuverlässigkeit

Für Systeme, die in einem sicherheitskritischen Kontext zur Umwelt stehen, gilt esAnforderungen hinsichtlich ihrer Verlässlichkeit zu erfüllen. Verlässlichkeit basiert aufder Vertrauenswürdigkeit eines Computersystems für den Anwender, der sich dessenDienste bedient und auf dessen Funktionalität verlässt. Der Begriff der Verlässlichkeit istdabei speziell bei der Entwicklung von Rechensystemen mit hohen Zuverlässigkeits- undSicherheitsanforderungen geprägt worden. Nach /[Lap91]/ korreliert Verlässlichkeit mitder englischen Bezeichnung Dependability, die als Überbegriff die Themen Verfügbarkeit(Availability), Wartbarkeit (Maintainability) und Zuverlässigkeit (Reliability) umfasst. Im Be-reich der Echtzeit-Computersysteme komprimiert sich die Terminologie auf den Begriffder Zuverlässigkeit, der daher oftmals in der Praxis auch mit dem Begriff der Verläss-lichkeit synonym verwendet wird.

Begriffsdefinitionen

Nach /[DIN90]/ ist Zuverlässigkeit definiert als „Beschaffenheit einer Einheit bezüglichihrer Eignung, während oder nach vorgegebenen Zeitspannen bei vorgegebenen Anwendungsbe-dingungen die Zuverlässigkeitsforderung zu erfüllen“. Im technischen Bereich lässt sich dieseAussage konkretisieren als die durchschnittliche Zeit zwischen den Ausfällen in einemSystem MTBF (mean-time-between-failure) mit zufällig auftretendem Ausfallverhalten.

Im Bereich der E/E-Architekturentwicklung konzentriert sich der Zuverlässigkeits-begriff auch auf die Sichtweise für strukturierte Prozesse, einem durchdachten Sys-temdesign sowie einer engen Verzahnung aller beteiligten Entwickler /[SW07]/. DieMotivation des Fahrzeugherstellers in Fragen der Zuverlässigkeit des GesamtsystemsFahrzeug mit hoher Priorität zu agieren, resultiert aus den gravierenden Auswirkungenim Falle von Fahrzeugdefekten. Besonders der komplette Verlust der Funktionstüch-tigkeit eines Fahrzeugs, bei oder zwischen den Fahrbetriebszeiten beim Kunden, wirktsich fatal auf das Qualitätsempfinden gegenüber einer Fahrzeugmarke aus und kannbei sicherheitskritischen Systemen auch zu juristischen Folgen führen. Eine Möglichkeitdie Zuverlässigkeit zu verbessern besteht in der Erhöhung der Ausfallsicherheit, etwadurch die Implementierung von Systemredundanz. Dabei ist jedoch zu beachten, dassein hinsichtlich der Ausfallsicherheit lokal optimiertes Steuergerät (z.B. Airbag) globalbetrachtet nicht zwangsläufig zu einem robusten Gesamtsystem führen muss.

Methoden zur Erhöhung der Systemzuverlässigkeit

Aus Sicht der angewandten Entwicklungsmethoden und der zugrunde gelegten Prozes-se gibt es unterschiedliche Möglichkeiten die Zuverlässigkeit der E/E-Architektur zuerhöhen (in Anlehnung an /[SW07]/):

Design: Modulare Entwicklung mit Einführung von Funktionsredundanzen, Rück-fallebenen, Fehlertoleranzen, Selbstüberwachungen, Fehlerbehandlungsstrategien,erweiterte Diagnosekonzepte,

Entstehungsprozess: Einhaltung von Designrichtlinien, Anwendung modellbasierter


Funktionsentwicklung und Simulation, Einsatz automatisierter Codegenerierung,Umstellung auf einen funktionsorientierten Entwicklungsprozess mit durchgängi-gen Werkzeugketten,

Komponenten/Kommunikation: Entwicklung von robusten Kommunikationsstrategi-en, Systemverständnis für Zeitverhalten und Steuergerätezustände bei verteiltenFunktionen,

Standardisierung: Aufbau und Integration modularer Softwarekomponenten (Vorteilder Wiederverwendung und Austauschbarkeit), Einsatz standardisierter Basissoft-warearchitekturen und Laufzeitumgebungen,

Test: Etablierung geeigneter Organisationen mit ausgereiften Prozessen, Entwicklungeiner fundierten Teststrategie, Einsatz von neuen Methoden und Technologien,

Entwicklungsprozess: Vertrauen auf standardisierte Verfahren und Prozesse, Berück-sichtigung von Lernprozessen (Lessons Learned), Förderung der internen und her-stellerübergreifenden Zusammenarbeit (Kollaborations-, Prozess-, Projekt- undQualitätsmanagement).

Robustheit

Allgemein wird der Robustheitsbegriff im Zusammenhang mit der Fahrzeugentwick-lung unscharf benutzt. Prinzipiell versteht sich darunter die Anfälligkeit von System-komponenten in Fehlerfällen im Serieneinsatz auszufallen. Besonders die Situationenwenn der Fahrzeugbenutzer von den Ausfällen bewusst betroffen wird, etwa durch Ver-lust der Funktionstüchtigkeit des Autos oder schlimmstenfalls durch das Entstehen vonSicherheitsgefährdungen, sind dezidiert in der Systemrobustheit zu analysieren.

/[Sus07]/ verbindet den Systemrobustheitsbegriff mit dem akzeptablen Verhalteninnerhalb einer größeren als der ursprünglich von den Designern angenommenen Klas-se von Situationen. In /[ISE93]/ wird Robustheit im Bezug auf den Softwarebereichkonkretisiert mit6:

Zuverlässigkeit = Korrektheit + Robustheit

Unter Korrektheit versteht sich in dieser Darstellung das Maß für die Fehlerfreiheit derUmsetzung der Produktspezifikation. Weiterhin lassen sich fehlerfreie (korrekte) undrobuste Systeme als zuverlässig in ihrer Operation deklarieren.

Zusammenfassend lässt sich somit die Robustheit als das Maß an ungeplanter, nichtverifizierter Einsatzbereiche eines Systems auffassen, in denen über eine Produktspezi-fikation hinaus eine zuverlässige und korrekte Funktionsweise gewährleistet bleibt. DieAusprägung dieses Einsatzbereiches wird dabei als Toleranzbereich aufgefasst.

Mögliche beeinflussende Faktoren im Zusammenhang mit robusten Systemen wer-den in Abb. 2.38 zusammengefasst. Bei der Konkretisierung der mit der Systemrobust-heit korrelierenden Bereiche der E/E-Architektur ergeben sich folgende Domänen, die

6Der Zuverlässigkeitsbegriff dient in diesem Zusammenhang lediglich der Einordnung des Robust-heitsbegriffs. Das verbreitete Verständnis von Zuverlässigkeit bezieht sich klassischerweise auf die mittlereLebensdauer einer Komponente MTTF (mean-time-to-failure).


Robuste Systeme

Anwenderverhalten

Toleranzen

Konstruktionsfehler / Auslegungsfehler

Softwarefehler

Änderung der Spezifikationen

Umwelteinflüsse

Fehlverhalten von Komponenten

Fertigungsprozess / Einbau

Abbildung 2.38.: Darstellung von Bereichen, die der Erhöhung der Robustheit von Systemendienen /[SSV06]/

im Designprozess zu beachten sind (s. Abb. 2.39). Das Netzwerkarchitekturdesign und -management beeinflussen die Systemrobustheit. Dazu bieten sich mehrere Ansatzpunk-te an /[SSV06]/:

• Einsatz zentraler Fahrzeuggateways zum Management des Schlaf- und Weckver-haltens der Feldbussysteme,

• Begrenzung der Netzwerkauslastung zur Segmentierung von Steuergerätegrup-pen auf Subbussystemen und eine geeignete Bündelung von Systemsignalen inBotschaften,

• Überprüfung der Einsatzmöglichkeit von Buswächtern (Bus Guardians) zur zusätz-lichen Überwachung der Buskommunikation,

• Einsatz technologieunabhängiger Standards als Option zur Komplexitätsreduzie-rung von Netzwerkmanagementmodulen oder höheren Netzwerkprotokollen/[ISO04]/,

• Physikalische Trennung des zentralen Fahrzeugdiagnosezugangs vom allgemei-nen Netzwerk,

• Fehlertolerante Botschaftsauswertung,

• Begrenzung der Weckereignisse des Gesamtsystems.

Alle Schnittstellen, die bei der Systemintegration zu berücksichtigen sind (Fahrer, Fahr-zeug, Systeme, Kommunikation, Software, Hardware, Aktorik, Sensorik) müssen hin-sichtlich der Robustheit analysiert werden.

Die beschriebenen Maßnahmen zur Robustheitserhöhung bringen teilweise auch inanderen Bereichen positive Nebeneffekte. Beispielsweise wird das Thema Energiema-nagement zur Optimierung des gesamten Energieverbrauchs im Fahrzeug bereits seitJahren restriktiv gehandhabt. Mithilfe eines intelligenten Weck-/Schlafkonzepts für dieSteuergeräte wird neben der Systemrobustheit auch der durchschnittliche Ruhestromabgesenkt und damit die Standzeiten des Fahrzeugs im Ruhezustand verlängert, was


Schnittstellen

Energiemanagement

Diagnose

Architektur

Standards / Wiederverwendung

Fehlertoleranz /Reduzierung der Komplexität

Robustes Design

Abbildung 2.39.: Konkrete Schnittstellen der E/E-Architektur mit der Systemrobustheit/[SSV06]/

als Voraussetzung für die sukzessive Erhöhung der Steuergeräteanzahl in der E/E-Architektur gilt.

Um die Robustheit allgemein bereits im Entwicklungsprozess zu erhöhen, eignensich folgende Vorgehen /[SSV06]/:

1. Überprüfung und Aussage zur Zuverlässigkeit über die ursprünglichen Spezifika-tionsgrenzen hinweg,

2. Berücksichtigung der notwendigen Robustheit beim Systementwurf und -design,

3. Logische Verknüpfungen in einer Architektur erzeugen bereits im frühen Entwick-lungsstadium eine Robustheitserhöhung des Gesamtsystems.

Zuverlässigkeit in vernetzten Systemen

Die Zuverlässigkeit (Reliability) eines Netzwerks ist entscheidend für das Einsatzspek-trum der zu übertragenden Funktionsdaten. Der Grad an Zuverlässigkeit ist mit derQualität der Fehlertoleranz des Netzwerks gekoppelt. Zur Steigerung der Fehlertole-ranz gibt es unterschiedliche Möglichkeiten /[Kop97], [Che08], [Ech90]/:

Distributed Membership: Mithilfe eines Mitgliedschaftsdiensts (Membership Service)verfügt jeder Netzwerkteilnehmer über eine Liste, in der alle weiteren fehlerfreikommunizierenden Netzwerkknoten verzeichnet sind. Entdeckt ein Knoten In-konsistenzen zwischen seiner eigenen Membership-Liste und der Liste der ande-ren Netzwerkteilnehmer, so wird sein Aktivitätszustand eigenständig auf passivzurückgesetzt. Im passiven Zustand „hört“ ein Netzwerkknoten den Busverkehrmit, kann aber selbst nicht aktiv in das System senden. Über die zyklisch mitder Übertragung aktualisierte Membership-Liste lassen sich auch korrupte Kno-ten identifizieren, die fehlerhafte Botschaften versenden. Derartige Knoten werdenaus der Mitgliedschaft ausgeschlossen. Mit niedriger Wahrscheinlichkeit könnendurch Cliquenbildung in der zeitgesteuerten Kommunikation Fehler beim Kno-tenmitgliedschaftsdienst entstehen /[MSH08]/. Dabei identifizieren sich die Teil-nehmer innerhalb von mindestens zwei Gruppen untereinander als fehlerfrei, wo-durch praktisch mehrere disjunkte Teilsysteme im Netzwerk existieren, die aus-


schließlich untereinander kommunizieren. In diesem Fall muss dafür gesorgt wer-den, dass lediglich die größte Clique die Netzwerkkommunikation fortsetzt. DieKnoten aller anderen Cliquen müssen in den Passivmodus wechseln, um sich an-schließend wieder auf die größte Clique synchronisieren zu können.

Redundanz: Der Redundanzbegriff lässt sich grundlegend auf drei Bereiche verfeinern.Informationsredundanz bezieht sich auf die Ablage von identischen Informationenin unterschiedlichen unabhängigen Speicherbereichen (Informationsreplikation).Im abstrakten Fall reicht auch eine CRC-Verschlüsselung zur redundanten Absi-cherung einer Information aus. Zeitliche Redundanz bezieht sich auf einen mehr-fachen Austausch der identischen Informationen zu unterschiedlichen Zeitpunk-ten, etwa in zwei verschiedenen Botschaften. Örtliche oder strukturelle Redundanzbezieht sich auf die Verteilung der Information über mehrere physikalisch un-abhängige Kanäle, beispielsweise der Versand zweier identischer Botschaften aufmehreren unabhängigen angebundenen CAN-Bussen.

N-Version-Programming: N-version Programming (NVP) /[Avi95]/ bildet eine Methodezur Entwicklung einer Vielzahl funktionsäquivalenter Softwarekomponenten aufBasis einer identischen Spezifikation. Dabei werden die Funktionskomponentenvollständig und unabhängig voneinander in verschiedenen Entwicklerteams erar-beitet, um die Wahrscheinlichkeit des Entstehens identischer implementierungs-bedingter Softwarefehler zu vermeiden. Durch dieses Verfahren lässt sich die Zu-verlässigkeit eines Systems verbessern, wobei der verursachte doppelte Entwick-lungsaufwand mit hohen Kosten verbunden ist.

Fehlertoleranter Physical Layer: Die physikalische Bitübertragungsschicht trägt jenach Ausprägung zur Erhöhung der Systemzuverlässigkeit bei. Dazu zählen ei-nerseits Möglichkeiten den partiellen Ausfall von Kabelleitungen zu kompensie-ren, beispielsweise wenn ein Feldbussystem statt im Zweidraht auch im Eindraht-betrieb die Funktionstüchtigkeit aufrecht erhält (s. Abs. 2.4.1). Alternativ lässt sichauch die Idee des „aktiven Sternkopplers“ anführen, der bei partiellen Defektenim Netzwerk einzelne Bereiche der Netzwerktopologie vom Rest des Netzwerksphysikalisch trennt. Dadurch wird verhindert, dass sich ein Fehler über einen ge-wissen Bereich des Netzwerks hinaus ausbreiten kann (Error Containment).

Byzantinisch robuste Fehlertoleranz: Ein wesentliches Kriterium zur Definition derAnzahl startup- und syncfähiger Netzwerkteilnehmer resultiert aus dem Kon-zept zur Vermeidung byzantinischer Fehler bei der Synchronisation. Ein byzan-tinischer Fehler bezeichnet die Existenz temporärer schädlicher Netzwerkteilneh-mer (Malign Nodes), deren korruptes Verhalten ein hohes Gefährdungspotentialfür die Netzwerksynchronisation und deren Stabilität darstellt. Das grundsätzlicheProblem wird allgemein als byzantinisches Generalsproblem bezeichnet und wird in/[LSP82]/ behandelt. Die Grundregel n = 3k + 1 ist dabei zu erfüllen, falls in ei-nem Cluster mit n Synchronisationsknoten k byzantinische Fehler toleriert werdensollen.

2.4. GRUNDLAGEN DER FAHRZEUGVERNETZUNG 67

2.4. Grundlagen der Fahrzeugvernetzung

In diesem Abschnitt werden alle aktuell in der Serienproduktion eingesetzten Netz-werktechnologien technisch erläutert. Dazu zählen die Technologien CAN, LIN, MOSTund FlexRay. Mittelfristig bildet auch die Ethernet-Technologie eine Alternative in derFahrzeugvernetzung. Da sich Ethernet mit dem TCP/IP-Protokoll bisher vorrangig alshochperformantes Anbindungskonzept für die Fahrzeugdiagnose anbietet, wird dieseTechnik in dieser Arbeit nicht weiter betrachtet. Für weitere Details wird auf einschlägi-ge Literatur weiterverwiesen /[Bil08], [Tan00]/.

2.4.1. Controller Area Network

Ein wichtiger Meilenstein ist mit der Implementierung der CAN-Datenbusspezifikation(Controller Area Network) /[Rob91]/ im Fahrzeug erreicht worden. Dieses Feldbuspro-tokoll erfüllt die essentielle Anforderung nach Echtzeitfähigkeit für performante Kon-troll-, Steuer- und Regelsysteme im Fahrzeug. Ein weiteres Erfolgskriterium resultiertaus der Schlichtheit des Protokolls, welches akzeptable Freiheitsgrade für Steuergerä-teintegrationen bietet und mit einer Datenabsicherung auf physikalischer Ebene Vor-teile beim Einsatz im Fahrzeug bringt. Innerhalb der letzten Dekade haben sich dieAnforderungen an die Vernetzung im Bereich der Kosten und der technischen Eigen-schaften der Zielsysteme (Performanz, Übertragungsfrequenz, Datendurchsatz) weiterverschärft, wodurch neue Netzwerktechnologien entstanden sind. Dazu gehören die be-reits in der Fahrzeugentwicklung etablierten Kommunikationssysteme LIN (Local AreaInterconnect) /[LIN03]/ und MOST (Media Oriented Systems Transport) /[MOS04]/.

Grundsätzlich bestehen CAN-Bussysteme aus den in Hardware umgesetzten CAN-Controllern, die durch die Verwendung von CAN-Transceivern wertdiskrete und zeit-kontinuierliche Signale erzeugen. Diese Signale werden über zwei Busadern (High undLow) an die am selben Bus angeschlossenen CAN-Empfangssteuergeräte übertragen.Die physikalische Übertragungsform ist elektrisch, wobei sich zwei Baudraten etablierthaben (125kbit/s für den Komfortbereich7 und 500kbit/s für den Antriebs- und Fahr-werksbereich). Entsprechend existieren mittlerweile mehrere CAN-Bussegmente inner-halb einer E/E-Architektur, da die verfügbare Bandbreite eines einzelnen Busses nichtmehr ausreichend für den Datenaustausch aller Steuergeräte ist. Zur Verknüpfung die-ser mehreren Bussysteme wird in der Regel ein zentrales Steuergerät (Gateway) einge-setzt, welches die Botschaften entsprechend zwischen den Bussen umleitet (Routing). DieRouting-Beziehungen aller Steuergeräte werden in einer Tabelle im Gateway-Steuergerätabgelegt. Eine aktuelle CAN-basierte E/E-Architektur wird in Abb. 2.40 beispielhaftdargestellt. Folgende technische Eigenschaften zeichnen das Bussystem speziell für denSerienentwicklung und -einsatz aus:

Übertragungssicherheit: Durch die Möglichkeit Fehler auf Netzwerkebene zu detektie-ren und zu signalisieren eignet sich das CAN-Protokoll speziell für Echtzeitanwendun-gen. Durch das CSMA/CR-Verfahren bietet der Bus die Möglichkeit einer zuverlässigenÜbertragung durch Kollisionserkennung auf Botschaftsebene. Durch den Einsatz desBitstopfens, einem extra eingeführten Füllbit (Stuff-Bit) mit komplementären Wert beifünf aufeinanderfolgenden gleichwertigen Bits im Bitstrom, bleibt die Synchronisati-

7Aufgrund der gestiegenen Performanzanforderungen wird auch in den klassischen Lowspeed-Segmenten mittlerweile mit 500kbit/s übertragen.


Batterie-sensor

MotronicGetriebe Airbag Occupant Classification

ANTRIEBHS 500kBaud

weckbar

DIAGNOSEHS 500kBaud

weckbar

Assistenz-systeme

ExtendedHS 500kBaudNicht weckbar

MostKombi Klima-

Bedien-SG Einparkhilfe Stand-heizungInfotainment

MMIHS 500kBaud

weckbar

Niveau Fahrwerk

Allrad Quersperre

ESP Lenkwinkel-sensor

Sensor-cluster FAHRWERK

HS 500kBaudweckbar

Lenkstock-schalterSitz Tür vorne

(2)Tür hinten

(2)Power Lift

Gate

Anhänger

KOMFORTHS 500kBaud

weckbar

RDKRückfahr-kamera

Bodycontroller2/hinten

Bodycontroller1/vorne

p y

Gat

eway

Abbildung 2.40.: Die E/E-Architektur segmentiert Funktionen über Domänen und besitzt alsKernkomponente ein zentrales Gateway-Steuergerät /[Mic07]/

on zwischen den Knoten gewährleistet. Durch den künstlich erzeugten Flankenwechselim Bitmuster einer Botschaft werden längere gleichwertige Bitsequenzen unterdrückt,um die Synchronisation auf den Signalflanken zeitlich limitiert auszusetzen. Ergänzenddient die Anwendung von CRC-Prüfungen (Cyclic Redundancy Check), welche dem Emp-fänger gestatten die vom Sender gesondert addierten Prüfbits in einer Botschaft zu ver-gleichen, um die Datenintegrität übertragener Botschaften zu gewährleisten. Per Bestä-tigungsdienst (Acknowledge) quittiert der Empfänger zusätzlich eine erhaltene Botschaft.

Übertragungsgeschwindigkeit: Dieses Feldbusprotokoll liefert bei einer Baudrate vonbis zu 1Mbit/s verhältnismäßig gute Latenzzeiten im Millisekundenbereich. Dadurchlässt sich die grundlegende Anforderung nach Echtzeitfähigkeit für performante Kon-troll-, Steuer- und Regelsysteme im Fahrzeug für ein breites Anwendungsspektrum er-füllen.

Prinzipiell bietet sich zur Steigerung der verfügbaren Bandbreite eine Übertragungs-geschwindigkeit von 1Mbit/s an, was allerdings zu Lasten der im Fahrzeugserienbe-reich wichtigen Übertragungsrobustheit geht. Da mit erhöhter Übertragungsgeschwin-digkeit eine höhere Busfrequenz einhergeht, werden Einschränkungen in der Flexibilitätder verbauten Leitungslängen des Kabelbaums notwendig. In Abbildung 2.41 werdenLeitungslängen in Abhängigkeit zu angelegter Baudrate dargestellt. Neben den einge-schränkten Abmessungen der physikalischen Verkabelung erschweren auch schlechteEigenschaften in der elektromagnetischen Verträglichkeit den Einsatz der maximalenÜbertragungsgeschwindigkeit von 1Mbit/s in Fahrzeugserienprojekten. In buslastigenSegmenten des Fahrzeugs werden daher bevorzugt Baudraten um 500 kbit/s implemen-tiert.

Datendurchsatz: Mit mehreren parallelgeschalteten CAN-Bussen lassen sich heute mehrals 70 vernetzte Steuergeräte im Fahrzeug umsetzen. Durch spezielle Betriebsmodi (Si-lent Mode) lassen sich einzelne Steuergeräteprogrammiervorgänge durch hohe Auslas-tung des Busses performant umsetzen.


Baudrate in kbit/s

102050 125 250 500 1000

Kab

ellä

ngen

in m

6700

3300

1300

530

270

130

40

Relevante Baudraten

1010

Abbildung 2.41.: Logarithmische Darstellung von maximalen Leitungslängen in Metern proangelegte Baudrate in kbit/s

Fehlerdetektion und -beschränkungsmöglichkeiten: Durch die Fehlerbitmarkierung undeine gezielte Deaktivierung fehlerhafter Teilnehmer lassen sich Fehler im Übertragungs-verhalten identifizieren und dessen Auswirkungen unterdrücken.

Fehlertoleranz: Die physikalische Bitübertragungsschicht zeigt bei den Betriebsfrequen-zen annehmbare Eigenschaften für die Variabilität in der Auslegung des Bordnetzes.Dabei bietet der Low-Speed-CAN-Bus bei 125kbit/s die Möglichkeit einer potentiellenEindrahtübertragung bei Ausfall einer der beiden Kabeladern in der Netzwerkverbin-dung, was den Grad an Fehlertoleranz erhöht.

Einfachheit: Ein weiteres Erfolgskriterium resultiert aus der Schlichtheit des Protokolls,welches zudem durch seine gute Integrationsfähigkeit für zusätzliche Steuergeräte undder Datenabsicherung auf physikalischer Ebene Vorteile im Automotivebereich bietet.Durch das asynchrone Datenübertragungsprinzip lassen sich Netzwerkteilnehmer oh-ne explizite zeitliche Planung des Buszugriffs hinzufügen. Lediglich die Festlegung derBotschaftspriorität führt zu externen Effekten im Bussystem durch potentielle zeitlicheVerdrängungen von Botschaften, falls diese mit vergleichsweise niedrigeren Prioritätenfestgelegt wurden. Derartige Einflüsse machen sich jedoch erst bei höheren Buslasten(>60%) bemerkbar und bleiben daher prinzipiell beherrschbar.

Reifegrad und Standardisierung: Trotz der auf den Fahrzeugeinsatz konzentrierten Ent-wicklung eignet sich der CAN-Bus auch für die Anwendung in der industriellen Auto-matisierungtechnik. Das dadurch erreichte breite Einsatzspektrum der Technologie wirddurch die international anerkannte ISO-Standardisierung 11898 /[Rob91]/ verstärkt.Diese Historie begünstigt die Unterstützung des CAN-Bussystems auf Zuliefererseiteund gilt als Treiber für ein breitgefächertes Angebot an Entwicklungs- und Analyse-werkzeugen unterschiedlicher Hersteller auf dem Markt. Zusätzlich existieren neben


mehreren etablierten CAN-Transceivern auch zahlreiche Mikrocontroller verschiedenerHalbleiterhersteller mit integrierter CAN-Zelle für dedizierte Einsatzzwecke (Antrieb,Fahrwerk, Gateway, ...) im Fahrzeug. Der Wettbewerb führt zu einem attraktiven Preis-gefüge für unterschiedlichste Produktentwicklungen.

Zur Vertiefung der theoretischen Konzepte und technischen Umsetzungen der CAN-Technologie wird auf die offizielle Spezifikation /[Rob91]/ sowie einschlägige Fachlite-ratur /[Law07], [Ets09]/ weiterverwiesen.

Analyse der CAN-Entwicklung in Serienfahrzeugen

Um die zeitliche Entwicklung des CAN-Busses in PKWs nachzuvollziehen, werden dieE/E-Architekturen eines Fahrzeugherstellers aus den letzten Jahren untersucht. Anhandausgewählter Eigenschaften kann dabei ein Ausblick auf die Weiterentwicklung zu-künftiger Netzwerkarchitekturen gegeben werden. Zur Analyse werden dabei folgendeAspekte der CAN-Netzwerkarchitektur betrachtet:

• Anzahl der vorhandenen CAN-Bussegmente, die über eine Gateway-Schnittstellemiteinander verknüpft werden

• Anzahl der insgesamt im Fahrzeug verbauten CAN-Steuergeräte

• Höhe der in der E/E-Architektur verfügbaren Bruttobandbreite

• Höhe der prozentualen Buslast unter der Worst-Case-Annahme pro CAN-Busseg-ment

• Höhe der durchschnittlichen Buslast in der E/E-Architektur unter der Worst-Case-Annahme pro CAN-Bussegment

Aus den erhobenen empirischen Daten gilt es Aussagen zu treffen, um folgende zukünf-tige Trends abzuschätzen:

• Anzahl der zu erwartenden CAN-Segmente und CAN-Steuergeräte

• Limits der aktuell definierten CAN-Segmente im Fahrzeug

• Effektivität einer weiteren CAN-Segmentierung hinsichtlich replizierter Gateway-daten

• Faktoren im Wachstum des Kommunikationsbedarfs zwischen den Fahrzeuggene-rationen

Da es bei der Abschätzung der fiktiven Netzwerkkennzahlen auf statistische Werte ausvergangenen Entwicklungen zurückgegriffen wird, soll zur Dokumentation die Wahr-scheinlichkeit entsprechender Aussagen hinzugenommen werden. In der Untersuchungwerden die verteilten Stichproben per Regressionsverfahren auf eine kubische Polynom-darstellung überführt, deren Genauigkeit und Korrektheit wahrscheinlichkeitsbehaftetberücksichtigt bleiben muss. Zur Orientierung werden daher in den anfolgenden Gra-phen (2.43, 2.44) Konfidenz- und Vorhersageintervalle für die Regressionskurven hinzu-genommen.


Zeit in Jahre

2000 2002 2004 2006 2008 2010

Busl

ast i

n %

0

20

40

60

80

100

Fahrzeugmodell A Bus AFahrzeugmodell A Bus BFahrzeugmodell A Bus CFahrzeugmodell B Bus AFahrzeugmodell B Bus BFahrzeugmodell B Bus CFahrzeugmodell B Bus DFahrzeugmodell C Bus AFahrzeugmodell C Bus BFahrzeugmodell C Bus CFahrzeugmodell C Bus DFahrzeugmodell C Bus EFahrzeugmodell C Bus B (alt)50% Buslast

Abbildung 2.42.: Allgemeine Buslastentwicklung von drei verschiedenen Fahrzeugmodellen mitbis zu fünf Bussegmenten im Zeitraum 2001-2009

Zeit in Jahre

2000 2005 2010 2015 2020

Baud

rate

in k

bit/s

0

1000

2000

3000

4000

5000

BruttobaudrateGenutzte BaudrateRegressionskurve Bruttobaudrate(Kubisches Polynom)95% Konfidenzintervall95% VorhersageintervallRegressionskurve Durchschnittsdatensatz(exponentiell)95% Konfidenzintervall95% VorhersageintervallRegressionskurve Durchschnittsdatensatz(Kubisches Polynom)

Abbildung 2.43.: Vergleich der Regressionsanalysen von Bruttobaudrate und genutzter Baudrateüber mehrere Fahrzeugbaureihen


Das Konfidenzintervall stellt dabei wahrscheinlichkeitsabhängig den Bereich für mög-liche Varianten der berechneten Regressionskurve auf Basis der erhobenen Stichprobendar8. Das Vorhersageintervall spezifiziert den Bereich zukünftiger Stichproben, in dem diegesuchten Werte mit einer vorgegeben statistischen Sicherheit zu finden sein werden.

Steuergeräte

Die Wachstumsrate CAN-basierter Steuergeräte innerhalb der E/E-Architektur kannmit einer gebrochen rationalen sowie einer linearen Funktion approximiert werden,da deren Parameter in einer Regressionsanalyse erfolgreich konvergieren. Die beidenSchätzungen unterscheiden sich erheblich bei der Prognose des zukünftigen Steuerge-rätewachstums. Diese Unklarheiten lassen sich durch komplementäre Einflüsse in derEntwicklung der E/E-Architekturen erklären.

Zeit in Jahre

2000 2005 2010 2015 2020

Max

imal

e St

euer

gerä

tean

zahl

in e

iner

Bau

reih

e

0

20

40

60

80

100

120SteuergeräteanzahlRegressionsanalyse (Rational)95% Konfidenzintervall95% VorhersageintervallRegressionsanalyse (Linear)95% Konfidenzintervall95% Vorhersageintervall

Abbildung 2.44.: Regressionsanalyseergebnisse auf Basis linearer und gebrochen rationalerFunktionen

Einerseits lässt sich eine weitere Optimierung aktueller Steuergerätelösungen hin-sichtlich benötigter physikalischer Abmessungen der verbauten Komponenten und de-ren Kosten erzielen. In Ergänzung mit der verstärkten Elektrifizierung existierenderBauteile, beispielsweise zur Reduzierung des Verbrauchs, wird der lineare Anstieg inRegressionsabschätzung plausibel. Andererseits führt der Einsatz dritter Technologienwie zum Beispiel der LIN-Bus zur Abnahme CAN-basierter Steuergeräte. Der begrenz-te Bauraum im Fahrzeug und das Bestreben Funktionen zu bündeln und integriert aufSteuergeräte zu implementieren rechtfertigt die Annahme einer moderaten Zunahmeder Anzahl an CAN-Steuergeräten. Dabei darf nicht vernachlässigt werden, dass derKostenaufwand für die Entwicklung und Organisation begrenzt bleiben muss, was sichin einer limitierten Steuergeräteanzahl ausdrückt. Konsequenterweise lässt sich das Er-gebnis der zweiten Regressionsabschätzung mit einem abnehmenden Trend des Steuer-gerätezuwachses begründen.

8Bei einem Wert für ein 95% Konfidenzintervall sind die Endpunkte des Intervalls gegeben durchx ± t(v, z) ∗ s√

n , wobei x den Erwartungswert, s die Stichprobenstandardabweichung und t(v, z) die t-Statistik für v = n− 1 Freiheitsgrade definieren sowie z = 1.96 als p-Quantil der Standardnormalverteilungspezifiziert wird


2001 2005 2009 2015Max. CAN-Segmente (pro Baureihe) 2 4 6 9,5Anstiegsfaktor (CAN-Busse/Jahr) - 0,5 0,5 0,58Max. CAN-Steuergeräte (p.B.) 9 37 52 75Anstiegsfaktor - 4,11 1,41 1,44Bruttobaudrate (kbit/s) 625 1250 3000 7000Anstiegsfaktor - 2,0 2,4 2,3Genutzte Datenrate (kbit/s) 149,09 431,25 1055,55 2500,00Anstiegsfaktor - 2,77 2,45 2,37Durchschnittliche Auslastung (in %) 23,9 34,5 35,2 35,7Bereinigtes Datenaufkommen (kbit/s) - - 621,01 1444,45Anstiegsfaktor - - - 2,33Datenanstieg (innerhalb einer Baureihe) - 26,29 35,53 -Anstiegsfaktor - 1,09 1,11 -Datenanstieg (zwischen den Baureihen) (kbit/s) - 188,99 623,83 1444,45Anstiegsfaktor - 1,78 2,45 2,32

Tabelle 2.3.: Übersicht und Prognose zur Entwicklung der CAN-Technologie in Serienfahrzeu-gen

Insgesamt kann somit geschlossen werden, dass zum aktuellen Zeitpunkt keine zu-verlässige Aussage über das Wachstum der Steuergeräte im Fahrzeug auf Basis existie-render Daten gegeben werden kann.

2.4.2. Local Area Interconnect

LIN spezifiziert ein einfaches kostenoptimiertes Bussystem mit einer Maximalbaudratevon 20kBit/s, welches vorzugsweise für Anwendungen mit begrenzter Komplexität im-plementiert wird, beispielsweise bei einfacher Sensorik/Aktorik im Fahrzeug (etwa zurAnsteuerung eines intelligenten Schalters). Der Vorteil dieses nach dem Master/Slave-Kommunikationsprinzip arbeitenden Busprotokolls liegt in dem niedrigen Preis, da dieKommunikation physikalisch im Eindrahtbetrieb umgesetzt werden kann.Gleichzeitig wird auf einen dedizierten Kommunikationscontroller in der Regel verzich-tet, da sich das Protokoll bereits mit standardisierten digitalen seriellen Schnittstellenimplementieren lässt.

2.4.3. Media Oriented Systems Transport

MOST findet seine Anwendungen im Multimediabereich. Die Spezifikation definiertim Gegensatz zu anderen Kommunikationssystemen die Schichten 1-7 des ISO/OSI-Modells und bietet damit dem Endanwender eine einheitliche definierte API (ApplicationProgramming Interface). Die Kommunikationsfunktionalität stützt sich auf die Low-Level-und Basic-Layer-System-Services, die einerseits direkt im MOST-Transceiver abgebildet(Schicht 2) und als MOST NetServices (Schichten 3-5) und Application Socket (Schicht 6)implementiert werden. Die MOST-Technologie basiert auf einer Ringtopologie, die perTokenmechanismus den Buszugriff reguliert. Der Physical Layer hat sich in Form ei-nes optischen Mediums etabliert. Bei einer Bandbreite von ca. 23Mbit/s sowie einerSystemfrequenz von 44,1 oder 48 kHz eignet sich der MOST ideal zur Übertragungvon Streaming-Daten (synchrone Datenübertragung). Dadurch können sehr gut Audio-und mit eingeschränkter Qualität Videodaten über den Ring verschickt werden. Wei-


terhin existiert ein asynchroner Datenkanal zur Paketübertragung sowie ein separaterKontrollkanal zur Konfiguration der MOST-Teilnehmer und der (a-)synchronen Daten-übertragung. Zur weiteren Information bezüglich MOST und LIN wird auf /[ZS06]/weiterverwiesen.

2.4.4. FlexRay

Das in dieser Arbeit im Mittelpunkt stehende Kommunikationssystem FlexRay wird seitdem Jahr 2000 analog zu LIN in einem herstellerübergreifenden Konsortium entwickelt,welches das Ziel verfolgt ein neues hochperformantes, fehlertolerantes und echtzeitfä-higes Kommunikationssystem zu definieren /[Fle05a]/. Als Vorlage dient das stark ver-wandte Protokoll TTP/C /[KG94], [TTT03]/, dem aus patentschutzrechtlichen Gründender Einzug in die Fahrzeugindustrie verwehrt geblieben ist. Trotzdem bilden die techni-schen Eigenschaften von TTP/C die Grundlage für das FlexRay-Protokoll, welches umdie Konzepte des proprietären optischen Bussystems für sicherheitskritische Anwen-dungen Byteflight /[BPG04]/ erweitert worden ist.

FlexRay spezifiziert ein Multi-Masternetzwerk, welches in Bus-, Stern- oder Hybrid-topologieform über ein elektrisches Medium auf der Physical Layer-Ebene (ISO/OSI-Schicht 1) kommuniziert. Besondere Eigenschaften entstehen durch die dezentrale, feh-lertolerante Uhrensynchronisation /[WL88]/ der Netzwerkteilnehmer, wodurch einZeitscheibenkommunikationsprinzip TDMA (Time Division Multiple Access) ermöglichtund damit ein deterministisches Zeitverhalten geschaffen wird. Bei der hohen Band-breite von 10Mbit/s werden die durch das Kommunikationssystem verursachten Ge-nauigkeitsschwankungen (Jitter) konstant im Mikrosekundenbereich gehalten, was eineVoraussetzung für schnelle und über die Steuergerätegrenzen hinweg verteilte Rege-lungskreise (Closed Loop Control) darstellt. Es wird ein zweiter physikalischer Kanal zurredundanten Datenkommunikation vorgehalten, um eine Voraussetzung für fehlertole-rante Kommunikation, die räumliche Redundanz (Spatial Redundancy), zu ermöglichen.Dadurch können permanente oder transiente physikalische Fehler ausgeglichen wer-den /[Tha00]/. Im Falle von byzantinischen Fehlern werden allerdings noch zusätzlicheMechanismen wie zum Beispiel die zeitlich redundante Verarbeitung von Daten (TimeRedundancy) erforderlich /[Kop97]/. Der erstmalige Einsatz von FlexRay in einer Fahr-zeugserienentwicklung erfolgte 2005 im BMW X5 in Form einer elektronischen Dämp-ferregelung /[NSF07]/.

Tab. 2.4 stellt die drei verwandten zeitgesteuerten Bustechnologien TTP, TTCAN undFlexRay zum Vergleich gegenüber. Für eine ausführliche technische Beschreibung vonFlexRay-basierten Anwendungen wird auf /[Bro05]/ weiterverwiesen. Sämtliche fürdiese Arbeit relevanten Konzepte werden in Abs. 3.3 kurz zusammengefasst.

2.5. Grundlagen der modellbasierten

E/E-Architekturentwicklung

Kernziele im E/E-Architekturdesign basieren auf dem Bestreben das GesamtsystemFahrzeug in Bezug etwa auf Hardwaretopologien, Mechanik, Regelung, Funktionalitätoder Software /[LEk04]/ integriert zu entwickeln. Im Zuge der Etablierung von mo-dellgetriebener Entwicklung eingebetteter Software im Automobil, eröffnen sich weitereFragen hinsichtlich einer Ausbreitung in die Domänen der E/E-Architekturentwicklung

2.5. GRUNDLAGEN DER MODELLBASIERTEN E/E-ARCHITEKTURENTWICKLUNG 75

Protokoll TTP TTCAN FlexRay

Übertragungs-geschwindigkeit

25 Mbit/s;höhere Baudraten

möglich

1 Mbit/s;höhere Baudraten nicht

möglich wegen CSMA/CDZugriff

10 Mbit/s;höhere Baudraten

möglich, aberaktuell nicht

EPL unterstützt

Maximale Botschaftslängefür Applikationsdaten

Variabel für jedenKnoten, bis zu 240

Bytes

Variabel für jedeÜbertragung, bis zu

8 Bytes

Bis zu 256 Bytes;Im TDMA-Segment

einheitliche Slotgröße

Uhrensynchronisation

Single fehlertolerant,verteilte

Offset-KorrigierendeSynchronisation;formal verifiziert

(mit vier oder mehrKnoten), optionale

Frequenz-Korrektur zueiner externenReferenzzeit

Master-slaveSynchronisation,

Netzwerk intern oderdurch externe Ereignisse

getrieben

Fehlertoleranteverteilte Offset- und

frequenzkorrigierendeSynchronisation

(formale Verifikationunbekannt)

Fehlerhypothese /Fehlertoleranz

Toleriert alle singulärenHardwarefehler, zwei

redundanteKommunikationskanäle

Keine systematischeFehlertoleranz, keineredundante Kanäle

Toleriert einigesingulären Hardware-

fehler;keine Fehlerhypothese

FehlerdetektionBitfehler auf demBus, Sende- undEmpfangsfehler

Bitfehler auf demBus, Sende- undEmpfangsfehler

Bitfehlerauf dem Bus

Konsistenz-unterstützung

Bestätigung,Mitgliedschaft,

CliquenvermeidungBestätigung -

Event-Handling-Strategie

Ereigniskanal überdem TDMA-Schema

(CAN-Emulation)

TDMA und zusätzlichesArbitierungsfenster

für CSMA/CA

TDMA und zusätzlichesdynamisches Segment

auf Minislot-BasisZusammensetzbarkeit

vonereignisgesteuerten

Nachrichten

Zeitlichzusammensetzbar

Nicht zeitlichzusammensetzbar

Nicht zeitlichzusammensetzbar

Verfügbarkeit Chips seit1998

Chips als Entwicklungs-muster

Chips konform zurSpecification 2.1 Rev. A

(2005)

Tabelle 2.4.: Gegenüberstellung der drei unterschiedlichen zeitgesteuerten Bussysteme TTP, TT-CAN und FlexRay

/[RK07]/. Motiviert werden diese Überlegungen durch

• Integrierte Datenhaltung sämtlicher im Produktlebenszyklus entstehender E/E-Artefakte (Funktions- und Produktdatenmanagement (FDM,PDM))

• Verknüpfung und Revision von Entwicklungsergebnissen in Form formalisier-ter Modelle (Applikationsfunktionen, Kabelbaum, physikalisches Netzwerke, etc.)und informeller Artefakte (Anforderungsspezifikationen, Ausstattungslisten, Ent-wicklerdokumentationen, etc.)

• Analyse und Optimierung ganzheitlicher E/E-Architekturen (globale Optimie-rung) nach arbiträren Problemstellungen (Kosten, Gewicht, Zeitverhalten, Zuver-lässigkeit)

• Variantenmanagement und Austausch komplexer Entwicklungsergebnisse an denSchnittstellen zu beteiligten Zulieferern im Produktentstehungsprozess

2.5.1. Methoden und Werkzeuge

Die Vorteile einer modellgetriebenen Entwicklung lassen sich erhöhen, wenn die Mo-dellierungssprache spezifisch an die vorliegende Entwicklungsbereiche adaptiert wird.Mit der domänenspezifischer Modellierung minimiert sich der Entwicklungsaufwand sowiedie Anzahl an potentiellen Fehlerquellen, indem domänenspezifisches Wissen und des-sen Designkonzepte sowie die zugehörige Quellcodeerstellung als Dreierverknüpfungintegriert entwickelt werden /[PK02]/.


Bisher hat sich noch keine allgemein standardisierte domänenspezifische E/E-Mo-dellierungssprache für den Fahrzeugbereich durchgesetzt. Diese Situation lässt sichdurch verschiedene Aspekte begründen, die den Entwicklungsfortschritt in dem Be-reich signifikant bestimmen. Beispielsweise fehlt einigen allgemeinen Standards dernotwendige Zuspruch, da die Gesamtkomplexität, der Abstraktionsgrad, die Vollständig-keit, der Reifegrad oder eine technische Werkzeugumsetzung nicht ausreichend sind. Sofokussiert die Architekturbeschreibungssprache EAST-ADL /[CCG+07]/ vorrangig aufeinen integrativen Ansatz von der Featuremodellierung bis hin zur Implementierung,wird aber durch breitere Initiativen zur Softwarearchitekturentwicklung (AUTOSAR/[AUT07a]/), der eingebetteten Systementwicklung (MARTE /[FBSG07]/) und des Sys-tem Engineerings (SysML /[Sys06]/) überlagert. Daher werden diese Entwicklungsstan-dards in ATESST /[Ini07]/ mit den EAST-ADL-Konzepten verschmolzen, was durchden starken Entwicklungsfluss in den jeweiligen Initiativen zu einer erschwerten allge-meinen Akzeptanz auf dem Markt führt.

Ein unabhängiges, standardisiertes Werkzeugangebot zum E/E-Architekturentwurfhat sich bislang nur eingeschränkt gezeigt. Diese Entwicklung bezieht sich auf das Be-streben der Fahrzeughersteller ihren Wissensstand zu schützen und konsequent fürsich zu behalten. Dadurch wird eine unabhängige standardisierte Werkzeugentwick-lung weitestgehend verhindert. Proprietäre Ansätze der Hersteller konzentrieren sichdabei einerseits auf die integrierte Entwicklung von logischen E/E-Architekturen unddem nachgelagerten Software-Generierungsprozess (ORPHEUS /[Sal06]/) oder auf dasintegrierte Funktions- und Produktdatenmanagement im Produktentstehungs- und -lebenszyklus (DEEP-C /[Sto07]/, [BZ08], [Teu08]/). Dabei wird in /[BZ08], [Teu08]/eine standardisierte Werkzeugplattform /[Kle08]/ eingesetzt, um in der Funktion alsDaten-Backbone die technische Grundlage für das integrierte Daten-, Varianten- und Ver-sionsmanagement zu legen, und die zur Abbildung anwenderspezifischer Datenmodelledient. Bei der Entwicklung AUTOSAR-basierter logischer Architekturen muss im Be-reich der unabhängigen, standardisierten Werkzeugentwicklung ergänzend Systemdesk/[dSp08]/ aufgezählt werden, welches, ähnlich dem ORPHEUS-Ansatz, verstärkt der in-tegrierten modellbasierten Entwicklung von logischen E/E-Systemarchitekturen dient.Im Bereich der reinen Planung, Analyse und Simulation des Bordnetzes und dessenSignalphysik existieren im Rahmen der technischen Architekturentwicklung eigenstän-dige modellbasierte Werkzeuge (/[Men08], [Syn08]/).

Die Idee der gesamtheitlichen modellbasierten E/E-Architekturmodellierung stelltaktuell eine aus konzeptioneller Sicht vielfältig beleuchtete Domäne in der E/E-Entwick-lung im Fahrzeug /[Wal08], [LEk04], [Cor08]/ dar. Mit PREEvision /[Aqu07]/ zeigtsich mittlerweile am Markt eine erste kommerzielle und integrierte Alternative zumheutigen proprietären oder verteilten E/E-Architekturdesign im Fahrzeugserienbereich.PREEvision konzentriert sich als Werkzeug dabei insbesondere auf den frühzeitigenmodellbasierten Entwurf von E/E-Architekturen im Fahrzeugentwicklungsprozess.

Aufgrund des intensiven Einsatzes von PREEvision zur praktischen Validierung ei-nes Teils dieser Arbeit wird das zugrunde gelegte Werkzeugkonzept anfolgend kurzerläutert.

2.5.2. E/E-Architekturentwicklung mit PREEvision

Das Werkzeug PREEvision fundiert seit 2005 als kommerziell erwerbliches Werkzeugauf dem Grundgerüst des Forschungsergebnisses E/E-Architekturbewertungswerkzeug aus


einer Kooperation zwischen DaimlerChrysler (Forschung und Entwicklung) und demForschungszentrum Informatik (FZI) der Universität Karlsruhe (TH). Der Grundgedan-ke bei der Entwicklung bezieht sich auf das Bestreben E/E-Architekturen schnell undkosteneffizient zu entwickeln unter Einhaltung restriktiver Zeit- und Kostenvorgaben.Neben dem eigentlichen Zweck der Modellierung und dem Aufbau von mehrschich-tigen Architekturmodellen zur Systemdokumentation zeigen sich Vorteile bei der Er-stellung von Berechnungsmetriken zur Modellabfrage sowie Konsistenzprüfungen undPropagationsregeln bei der Erstellung und Entwicklung des Modells. Basisfragen beider Metrikanalyse ergeben sich aus dem Vorhaben der globalen Optimierung allgemei-ner Systemeigenschaften (Kosten, Gewicht, Zuverlässigkeit, etc.).

2.5.2.1. Modellierungsebenen

Wegen der hohen Komplexität einer heutigen E/E-Architektur ist eine themenorientier-te Gliederung des Gesamtmodells erforderlich, welche sich in PREEvision auf insge-samt fünf Ebenen erstreckt. Prinzipiell deckt eine vollständige Modellierung den Ent-wurfsprozess von der Ausstattungsbestimmung eines Fahrzeugs über deren Anforde-rungsspezifikation, der Erstellung der logischen und technischen Systemarchitektur bishin zur Platzierung der Bauteile im Fahrzeug (Packaging) bei der mechatronischen Syste-mentwicklung komplett ab. Gewöhnlicherweise führt der Designfluss dementsprechendüber den sequentiellen Aufbau von Modellen in folgenden Entwicklungsebenen (s. Abb.2.45):

Sensor Block

Sensor Block

Funktions Block Funktions

Block

Funktions Block

AktorBlock

Aktor Block

Anforderung

Subanforderung

FFN-Artifakte

Gateway Steuergerät

Steuergerät

Steuergerät

Steuergerät Aktor

Aktor

Sensor

SensorCAN CAN LIN

Kabel

Kabel

Kabel

Verbauort

Verbauort

Verbauort

Verbauort

Inline

Verbauort

Verbauort

Verbauort

Verbauort

Verbau

Steueueuuuuuueueuuuuereeeegeräääääääääääääätttttttttttttt

au V V

Verbaut

platziertplatziertgeroutet

S

S Steuerät

Aktor Block

Aktor

processed from

F

forderung

Artifakte

F kti Aktor

Anforderungs / Feature-Funktionsnetzwerk (FFN)

Funktionsnetzwerk

Hardwarearchitektur

Topology

Abbildung 2.45.: Übersicht zu E/E-Modellierungsebenen nach dem PREEvision-Ansatz

1. Kundenanforderungen-Ebene (Features)

2. Funktionalitäten-Ebene (Functional Feature Network)


3. Funktionen-Ebene (Funktionsnetzwerk)

4. Komponentennetzwerk-Ebene (Komponenten)

5. Physikalische-Ebene (Bauräume)

Jede Ebene verfügt über ein eigenständig zu entwickelndes Modell. Der Anwender be-stimmt in dem Zusammenhang die sequentielle Abfolge der Bedatung der Modellie-rungsdaten im Entwicklungsprozess. Intuitiv wird dieser Vorgang im Top-Down-Verfah-ren durchlaufen. Stehen allerdings die notwendigen Daten zur Modellierung nicht per-manent zur Verfügung, lässt sich der Anwendungsprozess auch sprunghaft über mehre-re Ebenen durchführen. Sollen die logische und die technische Seite der E/E-Architekturstrikt getrennt entwickelt werden so eignet sich das Meet-In-The-Middle-Vorgehen. Dabeiwird der jeweiligen Sicht entsprechend in disjunkten Bereichen der Modellierungsebe-nen simultan entwickelt und die produzierten Artefakte anschließend bei der Partitio-nierung miteinander verknüpft (Mapping) (s. Abs. 4.2.7).

Kundenanforderungen-Ebene (FL): In der Kundenanforderungen-Ebene sind alle An-forderungen spezifiziert, die in dem Kraftfahrzeug umgesetzt werden müssen (zum Bei-spiel ein CD-Player oder ein elektronisches Stabilitätsprogramm (ESP)). Diese Anforde-rungen können beispielsweise aus dem Anforderungsmanagementwerkzeug DOORS/[Tel06]/ importiert und synchronisiert werden. Dabei erfolgt eine Strukturierung inGruppen. DOORS bietet dabei jedoch lediglich die Möglichkeit Anforderungen zu sam-meln und zu gruppieren. Es existiert keine automatisierte Konsistenzprüfung der An-forderungen oder die Möglichkeit redundante Anforderungen zu finden.

Feature-Funktionalitäten-Netzwerk-Ebene (FFN): In der FFN Ebene werden die An-forderungen weiter verfeinert, indem sie in Wirkketten abgebildet werden. Eine Wirk-kette besteht dabei aus einem Ereignis (Requestor), der die Anforderung auslöst, einemAusstattungsmerkmal (Functionality), welche bestimmt wie die Reaktion auf das Ereig-nis aussieht und einer Komponente, die die ausgelöste Anforderung erfüllt (Fullfiller)und somit die eigentliche Funktion durchführt. Das Wirkkettenprinzip reduziert dieGefahr des Entwurfs inkonsistenter oder redundanter Systemteile.

Funktionsnetzwerk-Ebene (FN): In dieser Ebene werden gemäß den erhobenen Anfor-derungen logische Funktionen entwickelt. Die Definition dieser Funktionen erfolgt zuBeginn innerhalb einer Beschreibung von Funktionsbibliotheken. Durch einen Mapping-Vorgang werden die Requestoren der FFN-Ebene als Sensorblocktyp, die Fulfiller als Ak-torblocktyp und alle Ausstattungsmerkmale als Funktionsblocktyp definiert. In der FN-Ebene wird die Nutzungshäufigkeit eines jeden Blocktyps ersichtlich und die Kom-munikationsbeziehungen zwischen den verschiedenen Funktionen, Aktoren und Sen-soren festgelegt. Die Semantik dieser logischen E/E-Architekturebene entspricht demAUTOSAR-Standard /[AUT07a]/.

Komponentennetzwerk-Ebene (KMP): Das Komponentennetzwerk beschreibt und vi-sualisiert die verschiedenen technischen E/E-Komponenten in der Systemarchitektur(Steuergeräte, Aktoren, Sensoren) und deren Verbindungen zur Datenübertragung. DieVerbindungen werden durch Bussysteme oder konventionelle Verbindungen realisiert.


Die inneren Komponentenarchitekturen (Hardware- und Softwarebausteine) der Steu-ergeräte lassen sich dabei optional in expliziter Form modellieren. In einer eigenenDarstellungsebene wird der Aufbau der angelegten Verbindungen zwischen den Kom-ponenten genauer spezifiziert (Verkabelung). Dazu zählen arbiträre elektrische Verbin-dungskomponenten (Leitungen, Kabel, Adern, etc.)9.

Physikalische-Ebene (TOP): Auf der physikalischen Ebene werden die für die techni-schen Komponenten vorgesehenen Einbauorte räumlich in verschiedenen Bauräumenplatziert. Durch die Verbindung der verschiedenen Einbauorte fügen sich die Topolo-giesegmente zu einer Gesamttopologie zusammen. Durch die Abmessung der Größevon und der Abstände zwischen den Bauräumen ergeben sich die Werte für die Dimen-sionierung der Geometrie des zu entwickelnden Kabelbaum.

Neben dem heterogenen Ebenenkonzept tragen folgende Zusatztechniken zum Gesamt-entwicklungskonzept PREEvision bei.

Mappings: Mappings verkörpern die Beziehungen zwischen den verschiedenen Ebenenin Form explizit zu definierender Objekte. Dadurch lassen sich die Anforderungen verti-kal von der obersten Ebene bis in die vorgesehenen Einbauorte auf der untersten Ebeneumsetzen. Die Mappings verknüpfen dabei folgende Artefakte (s. Tab. 2.5).

AnforderungMapping

Wirkkettenelemente (Requestor, textitFunctionality,Fulfiller)Mapping

Funktionsnetzelemente (Sensor-, Funktions-, Aktorblock)Mapping

E/E-Komponenten (Sensor, Aktor, Steuergerät)Mapping

Bordnetzeelemente (Leitungen,Kabel)Mapping

Fahrzeugtopologien (Einbauort, Topologiesegmente)Mapping

Tabelle 2.5.: Vertikale semantische Verknüpfung zwischen den Modellierungsebenen durch ex-plizite Mappingstrukturen

Variantenmanagement: Zur differenzierten Entwicklung einer Vielzahl an Fahrzeugde-rivaten und -baureihen zeigt sich ein feingranulares Variantenmanagement für die ent-wickelten Modelle als Schlüsselkriterium einer nachhaltigen E/E-Architekturplattform-entwicklung. In einem Gesamtmodell werden dabei sämtliche Architekturalternativenberücksichtigt. Das führt zur vollständigen Modellierung sämtlicher Elemente allerFahrzeugbaureihen und -derivate. Das entstehende Modell ist dadurch insgesamt in-haltlich überladen (150%-Modell) und semantisch fehlerhaft. Durch Filterung diesesGesamtmodells lassen sich alle Architekturvarianten simultan entwickeln und pflegen.Die Zuordnung der Artefakte zu den Architekturvarianten ist dabei nicht strikt definiert

9Zusätzlich lassen sich zu den Standardkomponenten der Sensorik, den Steuergeräten und der Ak-torik auch Komponenten der Leistungsversorgung hinzufügen, beispielsweise Batterie-, Generator-, undMassekomponenten.


und wird daher anwenderspezifisch gelöst.

Metrikberechnung: Die bedateten Artefakte lassen sich mithilfe arbiträr definierbarerMetriken über das Gesamtmodell berechnen. Dadurch lassen sich wichtige Eckdatender E/E-Architektur wie Gewicht, Kosten und Zuverlässigkeit erfassen. In dieser Ar-beit bildet die Metrikberechnung ein partielles Konzept der Parameterberechnung fürFlexRay-basierte E/E-Architekturen.

Regelbasiertes Prüfen: Durch das Anlegen und Pflegen von Regelwerken lassen sich un-terschiedliche Prüfungen des Modells durchführen. Dazu zählen einerseits Konsistenz-regeln zur Vermeidung von Semantikfehlern und andererseits Modellabfrageregeln, umallgemeine Eigenschaften von Modellartefakten zu erfassen. Ergänzend gestatten Propa-gationsregeln die Umsetzung konditioneller Modellaspekte aufgrund kausaler Abhän-gigkeiten in der E/E-Architektur10.

2.5.2.2. Modellierung

Das Kernprinzip des PREEvision-Ansatzes fundiert auf dem getrennten Umgang mitder Datenstrukturierung (Datenrepository), der Datenmodellierung sowie deren Konfi-guration und Bedatung in einer eigenen Sicht (Eigenschaftssicht) (s. Abb. 2.46).

Abbildung 2.46.: PREEvision-Layout mit Datenrepository, Eigenschaftssicht und Datenmodel-lierung

Jede Modellierungsebene beinhaltet eigenständige Notationsformen zur Generierungeines jeweils entsprechenden Diagramms. Im Kontext der Abbildung und Analyse von

10Beispielsweise soll in der Regel beim Hinzufügen eines Steuergeräts und eines Busses zu einer Mo-dellgruppierung auch der verbindende Bustransceiver in die Modellgruppierung aufgenommen werden.

2.6. ANALYSEVERFAHREN 81

Feldbussystemen sind die FN-, NET-, und TOP-Ebenen am bedeutendsten. Ein FN-Modell wird grundlegend in einer getrennten Abstraktion als FN-Typenmodell gepflegt,welches beliebig oft in der eigentlichen FN-Modellierung instanziert werden kann. Da-durch lassen sich mehrfach auftretende identische Strukturen des Gesamtmodells (Klo-ne) besser beherrschen und fehlerträchtige Inkonsistenzen vermeiden. In Abb. 2.47 wirdunten rechts die Kommunikation zwischen den verschiedenen Blocktypen (Aktor-, Funk-tions- oder Sensorblocktyp) explizit an den Schnittstellen und deren Signalinhalte alsAttribute spezifiziert. Oben links wird in der Abbildung zum Vergleich die instanzierteForm dieses Ausschnitts aus einem Funktionstypenmodell dargestellt.

Abbildung 2.47.: Typenmodell und Instanzbildung in der FN-Ebene

2.6. Analyseverfahren

Die Umsetzung ganzheitlicher E/E-Architekturanalysen ist zum aktuellen Zeitpunktkein standardisiertes Vorgehen der Fahrzeughersteller. Dies lässt sich teilweise mit dernoch stark dezentralen Fahrzeugentwicklung begründen. Andererseits hat sich bis heu-te keine eindeutige Methodik zur Architekturanalyse durchsetzen können. Ein Grunddafür liegt an den unzureichend verstandenen oder der fehlenden

• Vorgehensweisen (Abgrenzung von statischen/dynamischen Analysen),

• geeigneten Werkzeugen,

• Vollständigkeit bisher entwickelter Methoden,

• Kapazität an Architekturspezialisten mit integriertem Wissen über E/E-Systeme.

Die Notwendigkeit der Strukturierung komplexer Systeme ist in der Softwareentwick-lung bereits vor vielen Jahren erkannt worden /[Jac75]/. In /[Boo04]/ wird im Zu-sammenhang der Systemanalyse Folgendes konstatiert: „Entwicklungsprodukte, inklusive


Datenflussdiagramme, sind nicht in sich abgeschlossen. Sie sollten als Werkzeuge betrachtetwerden für den Zweck das Verständnis des Entwicklers in Bezug auf ein Problem und dessenImplementierung zu verbessern.“ Ein Meilenstein wird allgemein mit der Entwicklung derstrukturierten Analyse (SA) verbunden. Ziel dieser Methode ist die Formalisierung derSystemspezifikation in Bezug auf die Entwicklung von Software. Die konkrete Umset-zung der Ergebnisse aus der SA erfolgt während der Entwicklung eines strukturiertenDesigns der zu erstellenden Software. Speziell die Vorteile der technischen Spezifika-tion von Softwaresystemen mit den Hilfsmitteln der graphischen Modellierung, derhierarchischen Gliederung und eines Top-Down-Entwicklungsstils mit Funktions- undDatenflussmodellierung lassen sich in gleicher Weise auf den E/E-Architekturentwurfübertragen. Der Ursprung der Entwicklung der strukturierten Analyse liegt mitunterin der Entwicklung von SADT (Structured Analysis and Design Technique) /[DMR77]/,die sich partiell in den Grundideen der späteren Methoden der strukturieren Analyse/[DeM79]/, dem strukturierten Design /[YC75]/ und der strukturierten Programmie-rung /[Dij72]/ wiederfinden.

Die Architekturanalyse konzentriert sich auf die rein virtuelle Validierung der Sys-temanforderungen ohne Verwendung von realer Hardware /[Sch06]/. Primärziele sindstatische Aussagen über zu erwartende Auslastungen auf den Steuergeräten (Prozes-sorlast, Verbrauch an (nicht-)flüchtigen Speicher) und den verbindenden Bussystemen(Durchschnittsbuslast, Spitzenbuslast). Dabei ist von Interesse welche Entwicklung fürdie Auslastungen bei Systemerweiterungen zu erwarten ist und wann kritische Wer-te im Zeitbereich bei der Ende-zu-Endekommunikation im System (Deadlines) erreichtwerden. Im Bezug auf sicherheitsrelevante Systeme stellt sich die Frage mit welchemSystemverhalten bei (Teil-)Ausfall von Systemkomponenten zu rechnen ist.

Prinzipiell kann die Architektur nach zwei Arten analysiert werden. Die Unterschie-de dieser beiden Hauptklassen werden im Folgenden erörtert.

2.6.1. Statische Architekturanalyse

Die statische Architekturanalyse bezeichnet eine Analysemethodik, deren Fokus sichauf die Ableitung neuer Erkenntnisse auf Basis einer formal beschriebenen Architekturrichtet. Konkret werden auf Basis der initial vorliegenden Architekturdaten strukturelleEigenschaften und Prädikate geprüft /[Sch06]/.

Eine klassische statische Analyse in der Fahrzeugvernetzung ist die Berechnung derSystembuslasten aller verbauten Feldbussysteme. Diese ergeben sich aus den Datenba-sen, die den Signalaustausch zwischen den Steuergeräten in jedem Feldbussystem inForm von Kommunikationsmatrizen spezifizieren. Nachfolgend soll die Idee und dasVorgehen der Buslastanalyse in Bezug auf ereignis- und zeitgesteuerte Technologienkurz erläutert werden.

Buslastanalyse

Während der Entwicklung und Pflege von CAN-Systemarchitekturen bildet die Bus-lastanalyse einen etablierten Arbeitsschritt bei der Weiterentwicklung und Freigabe vonkonfigurierten Bussystemen für die Serienproduktion. Bei zeitgesteuerten Architekturenlassen sich die Buslasten im statischen Segment im Gegensatz dazu ohne probabilisti-sche Annahmen feststellen. Zum Vergleich mit den in 5.4 angewendeten Analysemetho-den wird das Vorgehen bei der klassischen Buslastberechung eines CAN-Bussystems


zusammengefasst.

Ereignisgesteuerte Systeme: Bei CAN-Systemen ergibt sich die Notwendigkeit der Bus-lastanalyse aufgrund der getrennten Entwicklung des Funktions- und des Netzwerkde-signs. Folgende Schritte werden dabei durchlaufen:

1. Applikation: Festlegung von Restriktionen für Signallatenzen bei der Signalübertra-gung zwischen zwei Funktionskomponenten im Funktionsdesign,

2. Partitionierung: Zuordnung von Funktionskomponenten zu Hardwarekomponen-ten,

3. Kommunikation: Zuordnung von Signalen zu Netzwerkbotschaften und Bestim-mung des Sendetyps für jede Nachricht,

4. Verifikation: Analyse der Anforderungen an das Zeitverhalten bei der Netzwerk-kommunikation zur Einhaltung der Restriktionen aus dem Funktionsdesign beigleichzeitiger Einhaltung der Buslastgrenzen des zugrunde gelegten Netzwerks.

Technisch lässt sich der Signaltransfer auf einem CAN-Netzwerk zwischen Sensor undAktor in folgende Teile zerlegen /[Rai02]/:

1. Entprellung der Sensorwertabtastung und Übergabe an die Applikation,

2. Bearbeitung des Sensorwerts in der Basissoftware und Befüllung des Sendepuffersim CAN-Treiber,

3. Verzögerung des Botschaftsversand durch Warteschlange- und Busarbitrierungs-zeiten,

4. Verzögerung im Treiber des Empfängers und der Übergabe an die Applikationmittels der Basissoftware,

5. Berechnung und Senden des Stellwerts an den Aktor.

Die Summe der einzelnen Teilverzögerungen wird in Abb. 2.48 zur Übersicht darge-stellt. Bei der Analyse der Buslast muss grundsätzlich beachtet werden, dass die Unter-suchung der WC-Buslast (Worst-Case-Busload) nicht zwangsläufig in der Realität erreichtwird. Das liegt zum Teil an den Protokolleigenschaften, die je nach Nutzung zu Unter-schieden in der Botschaftslänge (Normale und erweiterte Adressierung, Bitstopfen) füh-ren. Zusätzlich muss logischerweise der Sendetyp (zyklisch, ereignisabhängig, hybrid)für jede definierte Botschaft betrachtet werden.

/[TB94]/ etabliert für sicherheitskritische Anwendungen eine Buslastberechnungs-formel, die eine garantierte Nachrichtenverzögerung im CAN-Netzwerk GML (Guaran-teed Message Latencies) berechnet.

wm = Bm + ∑∀j∈hp(m)

⌈wm + Jj + τbit

Tj

⌉∗ Cj

Rm = Jm + wm + Cm

Cm =(⌊

34 + 8sm

5

⌋+ 47 + 8sm

)∗ τbit


Appl

ikat

ions

softw

are

Basi

sso

ftwar

eN

etzw

erk

kom

mun

ikat

ion

Tx-Task Tx-Task Tx-Task Tx-Task

LP HP HP HP HP

Rx-TaskSe

nder

Empf

änge

rTx

-Puf

fer (

Que

ue)

Busz

ugrif

f

Ji

Qi

wi Bi Cm

Abbildung 2.48.: Beiträge zum Zeitverhalten des Systems innerhalb einer Punkt-Zu-Punkt-Verbindung in einem CAN-Bussystem

Die Berechnung basiert auf der WC-Verzögerung wm für eine zum Senden verstauteNachricht m im CAN-Controller eines Steuergeräts. Mit Bm wird die längste Zeit er-fasst, durch welche die gegebene Nachricht m aufgrund Botschaften mit niedrigererPriorität verzögert werden kann. Jm bezeichnet den potentiellen beim Verstauungsvor-gang auftretenden Jitter. Cm repräsentiert das längste Zeitintervall für die physikalischenÜbertragung der Nachricht m auf dem Bus. Der Term τbit basiert auf der im Netzwerkvorliegenden Bitzeit und sm beschreibt die endliche Länge der Nachricht m in Byte.Die in der Berechnungsformel eingesetzte Nachricht j bezieht sich auf die Elemente derNachrichtengruppe hp(m), welche sämtliche Nachrichten mit einer höheren Priorität alsm beinhaltet.

Aus der Betrachtung ergeben sich dabei folgende WC-Annahmen und Abstraktionenim Hard- und Softwarebereich /[Rai02]/:

• Zyklisches Verhalten von ereignisgesteuerten Botschaften → statt des Sendetypsspontan wird mit einem zyklischen Sendetyp skaliert)

• Burst-Zustände → alle Nachrichten n sind simultan zum Zeitpunkt t = 0 sende-bereit11

• WC-Bitstuffing → maximale Vergrößerung einer Botschaft durch Bitstopfen,

• Ideale CAN-Hard- und Software → Sendelatenzen ohne Verzögerungen oder Un-terbrechungen, prioritätenorientierte Warteschlangen beim Senden und Abbruchvon wartenden Botschaften im CAN-Controller

Diese offenen Punkte lassen sich durch die Integration von Netzwerkmanagement-botschaften, einkalkulierte Hochlaufverzögerungen der Steuergeräte und mit der Be-rücksichtigung verschiedener Betriebszustände des Gesamtsystems (Service-/Fahr-betrieb) adressieren.

11Dieser Fall ist mit einem entsprechend konfigurierten OSEK-Netzwerkmanagement oder bei der Dia-gnose nicht abbildbar.


Nach Abb. 2.48 setzt sich die Gesamtlatenz bei den CAN-Bussystemen daher wiefolgt zusammen:

Latenzzeit = Warteschlangenlatenz + (Sendelatenz + Übertragungslatenz) + Empfangslatenz

Als Ergänzung lassen sich zwei Prämissen anführen, die bei der Buslastanalyse fürCAN-Bussysteme beachtet werden müssen. Dazu zählt, dass die Gesamtsendelatenzeiner Botschaft m die maximale Sendetoleranz (Deadline) Dm stets unterschreiten muss.Wenn Dm dabei kleiner als die Zykluszeit Tm ausgelegt worden ist, lassen sich Bot-schaftsverluste im Netzwerk verlässlich ausschließen. Zusätzlich müssen die Effekte derPrioritäteninversion beim Senden am Bus berücksichtigt werden12.

Als weiteres Beispiel für den Anwendungszweck der statischen Systemanalyse lässtsich der in der Softwareentwicklung bereits seit Jahren erforschte Bereich der WCET-Analyse nennen (vgl. Abs. 3.1.5.1). Das Ziel dabei ist die Analyse und Berechnungvon maximalen Ausführungszeiten WCETs (Worst Execution Times) von Softwarepro-grammen unter Berücksichtigung unterschiedlich leistungsfähiger Hardwarekonzepte/[PF99], [KLFP02], [WEE+08]/ (s. Abs. 3.1.5.1). Interessant wird die statische Analysebei der Verknüpfung und Interpretation der Ergebnisse von Teilanalysen. So erweistes sich als sinnvoll WCET-Analysen von Anwendungssoftware der Steuergeräte mitden Ergebnissen der Analyse von Übertragungslatenzen beim Signalaustausch über dieNetzwerke zu verbinden. Die Möglichkeit der Verkettung der Ergebnisse trägt dazu bei,Verletzungen im Zeitbereich bei zeitkritischen Systemen frühzeitig zu erkennen.

2.6.2. Dynamische Architekturanalyse

Die signifikante Differenzierung der dynamischen von der statischen Architekturana-lyse entsteht durch die aktive Untersuchung vorliegender Datenmodelle in Form einerSystemstimulierung mit konkreten Eingangsdaten /[Sch06]/. Dieses Szenario entsprichteiner Systemsimulation zur Überprüfung des Systemverhaltens und zur Generierungvon Ausgangsdaten, die einer Analyse unterzogen werden. Allgemein lässt sich spezielldie Simulation zur Umsetzung der dynamischen Architekturanalyse als das „Experi-mentieren mit Modellen“ auffassen /[AJ78]/. Die Analyse innerhalb des experimentel-len Vorgehens basiert auf der Interpretation von Systemreaktionen, die durch bestimmteSystemstimuli erzielt werden.

Grundsätzlich lässt sich die dynamische Architekturanalyse in den Bereichen anwen-den, bei denen eine theoretisch formale Untersuchung nicht mehr vollständig oder nurmit hohem Aufwand durchgeführt werden kann. Dazu zählen bei der allgemeinen Fahr-zeugentwicklung vorrangig Bereiche wie Betriebsfestigkeit, Crash, Fahrdynamik, Strö-mung und Verbrennung. Für den Bereich der E/E-Architektur bietet sich die funktionaleSimulation der verteilten Anwendungen auf den Steuergeräten unter Berücksichtigungtemporaler Aspekte und vorhandener Systemressourcen an /[Sch06]/. Der im Rahmendieser Arbeit relevante Teil der dynamischen Architekturanalyse konzentriert sich aufdie Simulation des Weck- und Startverhaltens eines FlexRay-Clusters im Fahrzeug.

12Die Buslastanalyse ist für die zeitgesteuerten Architekturen trivial, da das Kommunikationsverhaltenbereits durch den Busschedule vorgegeben wird. Daher kommt der Parametrierung des Bussystems umsomehr Bedeutung zu (s. Abs. 4.6).

KAPITEL 3

Zeitgesteuerte Architekturen

Das Prinzip der Zeitsteuerung steht im Kontrast zu den klassischen ereignisgesteuerten Bussystemen.Es werden die signifikanten Unterschiede zwischen diesen beiden Paradigmen herausgearbeitet und präg-nante Eigenschaften der zeitgesteuerten Architekturen dargestellt. Der Stand der Technik existierenderEntwicklungsmethoden im Kontext flexibler zeitgesteuerter Architekturen wird erläutert. Abschließendwerden die relevanten Spezifika des flexiblen zeitgesteuerten Bussystems FlexRay zusammengefasst.

Der Ursprung zeitgesteuerter Systeme korreliert mit der Entwicklung des Paradig-mas der synchronen Sprachen. Die Programmiersprachen ESTEREL und LUSTRE un-terscheiden beispielsweise strikt zwischen logischer und zeitlicher Steuerung /[Ber00],[HCRP94]/. Bei diesen Ansätzen erfolgt die Ausgabe berechneter Daten synchron mitder Dateneingabe. Dabei darf die maximale Berechnungsdauer der Ausgabedaten dieminimalen Zykluszeiten für externe Ereignisse niemals überschreiten. Dadurch lässtsich das System mithilfe der Zeitsteuerung durch gezeitete externe Ereignisse betreiben.Die Grundidee der Zeitsteuerung unter Berücksichtigung maximaler Ausführungszeiten(WCET) findet sich in der an der TU Wien entwickelten zeitgesteuerten Architektur TTA(time-triggered architecture) /[Kop98]/ wieder. Mit TTP/C (time-triggered protocol class C)/[TTT03]/ ist ein leistungsfähiges zeitgesteuertes fehlertolerantes Bussystem zur TTAhinzugefügt worden, welches sich als Entwicklungsvorlage in großen Teilen mit demflexiblen zeitgesteuerten Bussystem FlexRay überdeckt. Die technischen Aspekte (fle-xibler) zeitgesteuerter Architekturen werden im Folgenden vorgestellt.

3.1. Aspekte der Zeitsteuerung

Im Unterschied zu den ereignisgesteuerten Architekturen unterliegen die zeitgesteu-erten Architekturen strikten Richtlinien, Vorgaben und damit Einschränkungen (Cons-

86

3.1. ASPEKTE DER ZEITSTEUERUNG 87

traints) innerhalb ihrer Gesamtspezifikation /[Kop98]/. So gilt die Grundregel, dassexakte Zeit- und Wertbereiche für sauber zerlegte und gekapselte Subsysteme vorliegenmüssen. Die Subsysteme können zu einem Gesamtsystem komponiert werden (Clus-ter), wodurch zeitgesteuerte Architekturen als zusammensetzbar (composable) bezeichnetwerden können.

Eine herausragende Eigenschaft einer zeitgesteuerten Architektur ist die FähigkeitInformation in hoher temporaler Präzision zu behandeln. Im Fahrzeugbereich tritt die-se Anforderung überall dort auf, wo genaue Zustandsaussagen zu exakt bestimmtenZeitpunkten erwartet werden. Speziell hochauflösende und sich schnell ändernde Va-riablen, in /[Kop98]/ als Realtime Entity bezeichnet, erfordern ein besonderes Maß anExaktheit. Im Fahrzeug sind Schaltvorgänge im hohen Drehzahlbereich ein Beispiel füreine Funktion mit hoher temporaler Präzision. Um ein Echtzeitsystem innerhalb einerzeitgesteuerten Architektur abzubilden, müssen dessen harte und weiche Echtzeitbedin-gungen erfüllt werden. Diese Bedingungen sind in der Regel mit der Beendigung einesProzesses und der Rückgabe der entsprechend zu einem Zeitpunkt erforderlichen Infor-mationen verknüpft.

RT

OS

HAL

TT

NC

ON

F

TT

NC

ON

F

HAL

RT

OS

SNI ACI TTNI TTNI ACI SNI

RT

OSC

ON

F

RT

OSC

ON

F

NAI

SSLSSL

NAI

SC

S

SC

S

SM

OC

AM

OC

APL

AM

OC

SM

OC

APL

DEM

SFD

DEM

SFD

Sensor Interface

Hardware Abstraction Layer

Actuator Interface

Safety/Security Layer

Time Triggered Network Interface

Application Mode Control

Time Triggered Network Configuration

Safety Control Services

System Mode Control

Real Time Operating System Real Time Operating System Configuration

Discrete Event Machine

Application

Signal Flow Diagram

Network Application Interface

Abbildung 3.1.: Beispielhafte Softwareschichtenarchitektur für ein zeitgesteuertes verteiltes Sys-tem

Eine verteilte zeitgesteuerte Architektur in Form eines Clusters besteht somit auszeitgesteuerten Subsystemen, welche an wohldefinierten Schnittstellen über ein zeitge-steuertes Netzwerkprotokoll Information austauschen (s. Abb. 3.1). Folgende Abstrakti-onsebenen, Dienste, Steuerungen und Konfigurationen sind in diesem Zusammenhangvon Bedeutung:

• Schnittstellen zu Sensorik, Aktorik und dem zeitgesteuerten Bussystem,

• Allgemeine Hardwareabstraktionsschichten für Hardware-Komponenten,

• Optionale Sicherheitsebenen und -dienste,

• Schnittstellen zwischen Applikations- und Netzwerksoftware,

88 KAPITEL 3. ZEITGESTEUERTE ARCHITEKTUREN

• Steuerung der Betriebsmodi auf Applikations- und Systemebene,

• Echtzeitbetriebssystem für die Prozesssteuerung,

• Konfigurationen für Netzwerk und Betriebssystem,

• Funktionen auf Applikationsebene auf Basis formaler Notationen (Datenflussdia-gramme, Zustandsautomaten).

3.1.1. Abgrenzung von Ereignis- und Zeitsteuerung

Das Prinzip der Datenkommunikation innerhalb reaktiver Systeme bezieht sich in Ab-straktion auf die Implikation des Prinzips „Ursache → Wirkung“. Von ereignisgesteuer-ten Systemen wird gesprochen, wenn eine Kausalität die Kommunikation einer Informa-tion zwischen einem Sender und dem zugeordneten Empfänger auslöst, beispielsweiseverkapselt in einer Botschaft. Dabei wird das Zeitverhalten der Botschaftsübertragung inerster Linie von kausalen Einflüssen, welche eine Kommunikation erfordern, bestimmt.

Im Gegensatz dazu stehen die zeitgesteuerten Systeme, deren Verhalten ausschließ-lich durch das Fortschreiten einer allgemeinen vorgegebenen logischen Zeit bestimmtwird. Im Kontext der zeitgesteuerten Kommunikation wird dieses Paradigma statischdurch vordefinierte und bestimmten Sendern zugeordnete Zeitpunkte für die Botschafts-übertragung umgesetzt.

Der Bereich der vernetzten eingebetteten Systeme im Fahrzeug wird in diesem Zu-sammenhang durch heterogene Systeme bestimmt, die einerseits zeitgesteuert eine zy-klische Kommunikation zur Realisierung regelungstechnischer Algorithmen umsetzenund andererseits ereignisgesteuerte Eingriffe, etwa bei der Steuerung durch den Fahrer,verarbeiten müssen. Je nach Medienzugriffskontrolle müssen bei zeit- oder ereignisge-steuerten Bussystemen jeweils Kompromisse zugestanden werden. Bei ereignisgesteuer-ten Bussystemen wird die zyklische Kommunikation nur durch künstliche Steuerung inder Steuergerätesoftware erreicht während sich rein zeitgesteuerte Bussysteme proble-matisch im Umgang mit schnellen Reaktionen auf spontane Ereignisse zeigen. Mit denflexiblen zeitgesteuerten Bussystemen wird versucht beiden Anforderungen innerhalbeiner Technologie bestmöglich gerecht zu werden.

3.1.2. Eigenschaften physikalischer Zeit

Die Grundlage für die Qualität eines zeitgesteuerten Systems wird durch die Eigen-schaften der dem Netzwerk zugrunde gelegten physikalischen Zeit gelegt. Der folgendeAbschnitt definiert die wichtigsten Begriffe im Umfeld der Zeitsteuerung. Für Detailswird auf /[Sch96], [Kop97]/ weiterverwiesen.

Die Basis der physikalischen Zeit steht in Relation zu den existierenden physikali-schen Uhren. Diese sind in einem verteilten zeitgesteuerten Bussystem auf jedem Knotennotwendig, um den Verlauf physikalischer Zeit messen zu können. Eine Zeitmessungerfolgt im Zusammenhang mit einem Zähler und einem physikalischen Oszillator, des-sen Schwingungen den Zähler in gleichmäßigen diskreten Zeitschritten, den Mikroticks,inkrementieren. Die Schrittweite 1

f z des Zählers wird allgemein als Granularität der ge-

wählten Uhr gk bezeichnet. Die Qualität einer physikalischen Uhr orientiert sich an derQualität einer Referenzuhr.


Referenzuhr: Aus Sicht eines abstrakten Beobachters wird eine einzigartige Referenzuhrdefiniert, die im perfekten Einklang mit dem internationalen Standard der Zeit steht. Da-durch schreiten Zählschritte einer Referenzuhr synchron mit Zählschritten des interna-tionalen Zeitstandards fort. Die Referenzuhr basiert auf der Idee einer feinauflösendenUhr ohne Berücksichtigung relativistischer Effekte mit einer hohen Mikrotickfrequenzim Bereich von 1015μT/s. Durch diese feine Granularität wird es möglich Digitalisie-rungsfehler bei der Vergabe von Zeitstempeln für auftretende Ereignisse gering zu hal-ten. Durch diese absoluten Zeitstempel lassen sich einerseits die Zeitintervalle zwischendem Auftritt zweier Ereignisse bestimmen und anderseits deren logische Ordnung be-zogen auf den Zeitverlauf (temporale Ordnung) erfassen. Die Eigenschaften sämtlicherUhren des verteilten Systems (Frequenz/Granularität) werden auf Basis der μT-Anzahlder Referenzuhr gemessen. Die temporale Ordnung der Ereignisse, welche die Granu-larität der Referenzuhr gz unterschreiten, bleibt dabei unberücksichtigt.

Uhrendrift: Der Drift einer Uhr zwischen zwei Zeitpunkten i und i + 1 in μT beziffertdas Frequenzverhältnis zwischen einer Uhr k und der Referenzuhr z zum Zeitpunkt i.Der Drift wird bestimmt durch die Messung eines diskreten Zeitschritts der Uhr k mitder Referenzuhr z und anschließender Division durch die Anzahl an nominalen μTs derReferenzuhr in diesem Zeitschritt (i → i + 1). Eine perfekte Uhr unterscheidet sich da-bei nicht von der Referenzuhr. Ein gemessener Unterschied Δ

[z(μTk

i+1) − z(μTki )]

/n(k)quantifiziert die Driftrate.

Jede in einem Systemverbund verbaute freilaufende Uhr wird trotz Synchronisationmit der Referenzuhr zu einem arbiträren Zeitpunkt in endlicher Zeit jegliche begrenzterelative zeitliche Abweichung überschreiten. Perfekte Uhren lassen sich aufgrund vonTemperatureinflüssen, Spannungsschwankungen und Alterungseffekten nicht auf Schwing-quarze abbilden.

Physikalische Uhren: Zur Abbildung logischer Uhren auf elektronische Bauteile werdenOszillatoren benötigt, um ungedämpfte elektrische Schwingungen zu erzeugen. DieseKomponenten können aus selbstschwingenden Bauteilen oder aus mehreren, zu einerOszillatorschaltung zusammengefügten, Bauteilen bestehen.

Geschaltete Taktnetzwerke werden in einer Baumstruktur angeordnet (clock tree), umLaufzeitunterschiede bei der Erzeugung und Verteilung der Taktsignale in einer Bau-gruppe (skew) minimal zu halten. Durch den Einsatz der PLL-Technik (Phase-Locked-Loop) lassen sich durch phasengekoppelte Regelschleifen sehr stabile Taktgeneratorenbauen, die auf einem Referenztakt basieren und nahezu jede beliebige Ausgangsfre-quenz erzeugen können. Dadurch können beispielsweise zentrale Takte auf Quarzbasisaus einem größeren System zur Taktgeneration herangezogen werden. EntsprechendePLL-basierende Bausteine wandeln diesen zentralen Systemtakt auf den im Cluster zuapplizierenden Takt um (Translation).

Globale Zeit: Gegeben sei ein Uhrenensemble einer Knotenclusters mit jeweils einerUhr pro Knoten. Diese Uhren laufen intern synchronisiert, da die absolute zeitliche Dif-ferenz zweier arbiträrer Uhren durch die maximale Präzision des Clusters zwischenpotentiellen Synchronisationsphasen bestimmt ist. Durch die Bildung einer Submengean Mikroticks für jede Uhr wird ein nominaler Zeitschritt erzeugt, der clusterweit eineidentisch Länge besitzt. Diese Zeitschritte (Makroticks) beschreiben somit ein auf Clus-terebene einheitliches Zeitkonzept, welches als globale Zeit bezeichnet wird.


3.1.3. Synchronisation

Der Aspekt der Zeitsteuerung in einem Bussystem erfordert das Verständnis hinsicht-lich spezieller Eigenschaften zur Gewährleistung einer korrekten Ausführbarkeit derNetzwerkkommunikation. Mit entsprechender Priorität sind dabei die nachfolgendenAttribute zu behandeln, um eine optimierte Systemausprägung zu entwickeln:

Genauigkeit: Der zeitliche Versatz einer Uhr j gegenüber einer Referenzuhr z zum Zeit-punkt i wird als Genauigkeitj

i bezeichnet. Unter Genauigkeitj versteht sich die maximalezeitliche Abweichung der Uhr j zur Referenzuhr über eine arbiträre Periode, etwa derBuszykluslänge. Die periodische Synchronisation der Uhr zur Referenzuhr wird als ex-terne Synchronisation bezeichnet.

Präzision: In einer Menge an Uhren C = 1, 2, ..., n wird die maximale zeitliche Verschie-bung zweier arbiträrer Uhren (offset)

Πi = max∀j,k∈C

(o f f setj,ki )

als Präzision von C Πi zum diskreten Zeitpunkt i bezeichnet. Bei der Betrachtung derPräzision über ein arbiträres Zeitintervall, etwa der Buszykluslänge, bezeichnet max(Πi)die allgemeine Präzision des Uhrenverbunds pro Buszyklus. Die diskreten Zeitpunkteund die Präzision als absolute Abweichung einer Uhr von der Referenzuhr werden beiFlexRay in Mikroticks gemessen. Durch die endliche Driftrate einer physikalischen Uhrist eine periodische Resynchronisation der einzelnen Elemente in der Uhrenmenge C er-forderlich. Findet die Synchronisation wechselseitig ohne externe Beeinflussung statt,so wird von interner Synchronisation gesprochen. Bei FlexRay definiert sich die Cluster-präzision durch den zeitlichen Versatz der diskreten Absatzzeitpunkte eines Makrotickszwischen zwei Kommunikationscontroller (CC) im Netzwerk. Die Ratenpräzision bleibtdabei durch die lokalen Uhrenabweichungen in einem Buszyklus begrenzt, wobei sichdie Clusterpräzision prinzipiell über unendliche Zyklen aufschaukeln kann (Drift).

Mikrotick: Der kleinste diskrete Zeitschritt auf Hardwarebasis wird im Zusammenhangmit zeitgesteuerten Bussystemen als Mikrotick bezeichnet. Bei einem FlexRay-Systemsind drei unterschiedliche Mikroticklängen für die Uhrenbasis zur Konfiguration ei-nes CC zulässig μT = (12, 5ns; 25ns; 50ns). Die Mikrotickanzahl weicht in den Buszyk-len leicht voneinander ab, da unterschiedliche Mikroticklängen pro Knoten konfiguriertwerden können und sich damit der nominale Makrotick nicht zwangsläufig einheitlichdurch eine ganzzahlige Menge an Mikroticks in jedem CC umsetzen lässt.

Worst-Case und Best-Case Präzision: Aufgrund der unterstützten skalierbaren Fehler-toleranz lässt sich die Präzision in zwei verschiedene Ansätze untergliedern. Für denFall der Toleranz von byzantinischen Fehlern, einer Fehlerklasse bei ein Teilnehmer imCluster zu einem Zeitpunkt unterschiedliche Ergebnisse für ein Ereignis an verschie-dene Empfänger kommuniziert, beispielsweise für einen Zeitstempel, wird die Worst-Case-(WC)-Präzision herangezogen. Entscheidend zeigt sich eine Knotenanzahl n > 3,da nach der Regel n = 3k + 1 k byzantinische Fehler in einem n-Knotennetzwerk ab-gefangen werden können. Ausnahmesituationen bei mehr als k byzantinischen Fehlern


oder fehlenden Synchronisationsbotschaften von einem oder mehreren Steuergerätenin einem FlexRay-Doppelzyklus bleiben dabei unberücksichtigt. Die Best-Case-(BC)-Präzision geht von der Annahme aus, dass keine byzantinischen Fehler im Netzwerktoleriert werden müssen. In diesem Fall lassen sich höhere Nettodatenraten auf demBussystem umsetzen. Bei der Resynchronisation werden die Abweichungen der Uhreninnerhalb ihrer Präzision durch eine Absatzkorrektur (offset correction) zurückgesetztund Abweichungen zwischen den Taktraten jeder Uhr auf Makrotickebene korrigiert(rate correction).

3.1.4. Zeitgesteuerte Kommunikationssysteme

Als Teilgebiet der zeitgesteuerten Architekturen haben sich im Laufe der Zeit die zeit-gesteuerten Busprotokolle entwickelt. Die SAFEbus-Technologie (1992) /[HD92]/ derFirma Honeywell gilt als eine der frühen Implementierungen und kommt in der Boe-ing 777 zur Flugsteuerung zum Einsatz. Die mitunter bekannteste und am intensivstenerforschte zeitgesteuerte Bustechnologie ist das Time-Triggered Protocol (TTP) /[KG94]/.Speziell das Derivat TTP/C ist vorrangig für die Anwendung in sicherheitskritischenSystemen innerhalb der Avionik und dem Fahrzeugbereich konzipiert worden. Paral-lel zu den neuentwickelten zeitgesteuerten Protokollen hat es Versuche gegeben, denCAN-Bus als etablierte ereignisgesteuerte Technologie im Fahrzeugserienbereich um einzeitgesteuertes Paradigma zu erweitern (Time-Triggered CAN (TTCAN)) /[Rob02]/. Ak-tuell wird dem flexiblen zeitgesteuerten Bussystem FlexRay im PKW-Bereich das größtePotential zugeschrieben /[NSF07]/.

Ein wesentlicher Unterschied zwischen ereignis- und zeitgesteuerten Kommunika-tionssystemen liegt in der konkreten Konfiguration des jeweiligen Netzwerkprotokolls.Während sich der CAN-Bus im Wesentlichen durch seine Baudrate und dem physikali-schen Abschlusswiderstand konfigurieren lässt, so erfordert ein zeitgesteuertes Systemeine deutlich komplexere Konfiguration. Die im Fall von FlexRay verankerten 74 Pa-rameter spannen einen theoretischen Lösungsraum von 1048 Varianten auf /[ASH06]/.Ein zusätzlicher Aufwand besteht in der Erfüllung zahlreicher Einschränkungen für die-sen gültigen Lösungsraum mithilfe von 43 mathematischen Bedingungen (Constraints)sowie 19 Annahmen/Gleichungen, die der Parameterverbund erfüllen muss /[Fle05a]/.Die Parameter beziehen sich allgemein auf folgende Eigenschaften des Systems:

Temporale/Dynamische Ausprägung: Der zeitliche Ablauf zur Etablierung einer Bus-kommunikation (StartUp) muss zwischen den Teilnehmern koordiniert verlaufen,um eine synchrone zeitgesteuerte verteilte Interaktion zu erzielen. Es werden dielogische Startprozedur und die StartUp-autorisierten Netzwerkknoten festgelegt.Während der Kommunikation muss garantiert bleiben, dass statische vorab defi-nierte Kommunikationsbereiche (slots) zuverlässig einem Teilnehmer exklusiv zumSenden zur Verfügung stehen. Die notwendige Größe dieser Slots muss je nachgewünschter Botschaftslänge errechnet werden. Die aneinandergereihten Slots er-geben ein Kommunikationsschema (Schedule), der gleichermaßen vorab auf einefixe Länge eingestellt wird. In zyklischen Phasen müssen in dem Zusammenhangdie Teilnehmer resynchronisiert werden, um ein arbiträres Auseinanderdriften derlokalen Steuergerätezeiten zu vermeiden. Konsequenterweise werden fixe Berei-che der Bandbreite zyklisch zur Synchronisation des Bussystems erforderlich. Jenach Systemspezifikation fallen diese Bereiche zeitlich unterschiedlich lang aus


und müssen daher busspezifisch berechnet werden.

Physikalische Ausprägung: Bei einer elektrischen Bitübertragungsschicht trägt die Bus-physik aufgrund hoher Übertragungsfrequenzen einen signifikanten Beitrag zurGesamtkomplexität des Systems bei. Einflüsse auf die Signalform müssen an jederStelle der Netzwerktopologie berücksichtigt werden. Dazu zählen Veränderungenin der Bitamplitude (Dämpfung), der Bitbreite (asymmetrische Verzögerung) und beieiner Signalreflexion im System. Im Systemdesign wirkt sich dieser Sachverhalt beider Definition der Parameter zur Ausbreitungsverzögerung in den Transceivern,im Netzwerk sowie bei der Festlegung der umzusetzenden Makroticklänge aus.

Sicherheitsspezifische Ausprägung: Zu diesem Bereich zählen einerseits triviale The-men wie die Anzahl der aktiven Sternkoppler oder die Verwendung eines redun-danten Übertragungskanals im System. Andererseits gibt es auch abstrakte Pa-rameter zur Spezifikation der Weck- und Startversuche für jeden StartUp-Knotenoder zur Konfiguration des abgestuften Fehlerpropagationsmodells beim Vorlie-gen von Kommunikationsfehlern und dem daraus resultierenden Synchronisati-onsverlust im Knoten.

Der Kern des zeitgesteuerten Bussystems fundiert auf einem einfachen oder mehrstufi-gen Zeitkonzept. Bei FlexRay wird auf fünf Zeitebenen abstrahiert, um beliebig genauverschiedene Konfigurationsbereiche festlegen zu können (s. Abb. 3.21).

Zyklus: Die gröbste Abstraktionsebene beschreibt die Zyklusebene. Dazu zählt nebender eigentlichen Zykluslänge eines Parametersatzes auch die Verwendung potentiellerZyklusiterationen in denen Dateninhalte variiert werden können(→ Slot).

Segment: Der FlexRay-Buszyklus lässt sich in einen Bereich für die statische Kommuni-kation (fixe Zeitscheibenzuordnung) und für die dynamische Kommunikation (flexibleZeitscheibenzuordnung) untergliedern. Das Symbolfenster erlangt Relevanz im Falledes Einsatzes eines Buswächters (bus guardian)2 /[Fle04a]/. Über das Intervall der Netz-werkruhephase propagiert sich der Prozess der Absatzkorrektur zur Resynchronisationdes FlexRay-Clusters.

Slot: Die beiden Segmente zur Standardkommunikation (statisch/dynamisch) werdenin Zeitschlitze (slots) zerlegt. Die statische Slotlängen sind einheitlich für eine zu deter-minierende Nutzdatenlänge (<254Byte) definiert. Die dynamische Slotlänge der kurzenSlots des dynamischen Segments (minislots) ist für jeden Knoten in jedem Zyklus un-abhängig definierbar. Dabei wird über einen speziellen Parameter (pLatestTx) der letzt-mögliche Sendezeitpunkt im dynamischen Segment, abhängig von der Nutzdatenlänge,festgelegt. Dadurch wird ein Sendevorgang über die dynamische Segmentlänge hinausverhindert.

Makro: Zur Generierung einer einheitlich präzise skalierbaren Abbildung des kontinu-ierlichen Zeitverlaufs auf ein digitales System wird die Idee eines clusterweit identischen

1fokussiert auf den statischen Bereich.2Der Buswächter gibt den Buszugriff eines Netzwerkknotens nur an den vorkonfigurierten Zeitinterval-

len im Zyklus frei und erhöht somit die Fehlertoleranz des Clusters. Da aktuell der Einsatz des Buswächtersim Fahrzeugserienbereich keine Rolle spielt, bleibt dieser technische Aspekt in der Arbeit unbehandelt.


Zeitschritts (macrotick) angewendet. Die Länge ist dabei flexibel in einem Bereich zwi-schen 1 und 6 μs wählbar3.

Mikro: Die unterste Ebene bildet die Schnittstelle zu den hardwarespezifischen kleinstendigitalen Zeitschritten (microticks) eines FlexRay-Knoten. Sei k ein Knoten aus einemverbundenem Cluster mit der Knotenmenge K, so gilt4

∀k ∈ K : gdMacrotickk =∑

n=pMicroPerCycleki=1 ∗pdMicrotickk

gdMacrotickK

mitgdMacrotickk ≥ gdMacrotickK, gdMacrotickk ∈ R+0 , gdMacrotickK ∈ N+

0

Das bedeutet, dass der nominale Makrotick eines Clusters nicht zwangsläufig mit derzeitlichen Länge des durchschnittlichen Makroticks übereinstimmt.

Zyklus 63 ...Zyklus 1Zyklus 0

Statisches SegmentNIT

SWINDynamisches

Segment

Slot

Slot

Slot

Slot

Slot

Slot

Slot

Slot

Slot

Slot

Slot

Slot

Slot

Slot

Slot

Slot

Slot

Slot

Slot

Slot

Slot

Slot

Slot

Slot

Slot

MT MT MT MT MT MT MT MT MT

uT uT uTuTuT uTuT uT uTuTuT uT uT uTuT uTuT uT

Zyklu

sSeg

men

tSlo

tM

akro

Mik

ro

Abbildung 3.2.: Fünfstufiges Zeitkonzept der FlexRay-Technologie

Signalausbreitungsverzögerung: Der Datenversand in einem physikalischen Netzwerkführt zu einer statischen zeitlichen Verzögerung, die im Netzwerk je nach Länge desverbindenden Kommunikationsmediums zweier beliebiger Teilnehmer im Gesamtsys-tem variiert.

Uhrenpräzision: Durch Quarzungenauigkeiten in den verbauten Oszillatoren eines Flex-Ray-Steuergeräts kommt es zu dynamischen zeitlichen Schwankungen, welche die Ge-samtsystempräzision verschlechtern.

3Der komplette Bereich erschließt sich aus den spezifischen Definitionsbereichen für verschiedeneBaudraten in Abhängigkeit von der vorliegenden Taktfrequenz der verwendeten Kommunikationscontrol-ler und ist daher nicht vollständig für jeden Bustakt valide!

4Die Präfixe der Notation werden konform zur FlexRay-Spezifikation [Fle05a] gehalten (p = lokalerFlexRay-Knotenparameter, g = globaler FlexRay-Parameter, d = Timing-Parameter.)


3.1.5. Grundmethoden im Entwicklungsprozess

Bei der Analyse des Zeitverhaltens softwarebasierter Echtzeitsysteme liegt das Haupt-augenmerk darauf, das konzipierte System auf temporale Korrektheit zu verifizieren/[PV97a]/. Bei der Entwicklung und Umsetzung eines zeitgesteuerten Systems bezie-hen sich die Echtzeitanforderungen auf die Themen Busscheduling zur Ablaufplanungder Netzwerkkommunikation und auf das Knotenscheduling. Bei dem Letzteren stehendie drei Disziplinen WCET-Analyse (worst-case-execution-time), Analyse der Hardware-aktivitäten und der Schedulability-Test als grundlegende Entwicklungsmethoden im Fo-kus (s. Abb. 3.3).

Abbildung 3.3.: Zusammenhang zwischen den drei Grunddisziplinen bei der Entwicklung zeit-gesteuerter Architekturen /[Rin02]/

3.1.5.1. WCET-Analyse

Das Ziel der WCET-Analyse liegt in der Bestimmung der maximalen Ausführungszeitvon Codestücken in einem Softwaresystem. Dabei müssen gewisse Randbedingungenbeachtet werden, etwa dass ein Codeblock frei von Unterbrechungen ist, um die eigentli-che Grundausführungszeit zu ermitteln. Die errechneten Ergebnisse lassen sich bei derPlanung der Ausführungszeiten von Betriebssystemtasks eines Echtzeitbetriebssystemweiterverwenden.

Die stringenten Kostenanforderungen bei der Fahrzeugentwicklung implizieren dieNotwendigkeit der exakten Berechnung der WCET für eine exakte Übertragung desSoftwaresystems auf eine möglichst günstige, dass heißt ressourcenminimierte, Ziel-plattform. Allgemein wird in der Terminologie zwischen berechneter und aktuellerBCET (best-case-execution-time) und WCET unterschieden /[Pus93]/. Das Intervall derrealen Ausführungszeit des Codestücks liegt dabei eingebettet im Zeitintervall der rea-len BCET und WCET. Dieses Zeitfenster für die tatsächliche Ausführungszeit lässt sichdabei selbst in das Intervall einbetten, welches zwischen der berechneten BCET undWCET aufgespannt wird. Der Zusammenhang des Kontrollflusses zwischen einer Viel-zahl an unterschiedlichen Anweisungen mit spezifischen Ausführungszeiten lässt sichdabei graphisch als Kontrollflussgraph darstellen, indem die Knoten die Anweisungenund die gerichteten Kanten den Kontrollfluss beschreiben. Die entstehenden Pfade zwi-schen zwei Knoten im Kontrollflussgraph führen im erweiterten Kontext zur Ausfüh-rungszeit der dort verankerten Anweisungssequenzen.


Das Konzept der WCET-Analyse lässt sich allgemein in die zwei Klassen der dy-namischen und der statischen Analyse einteilen. Die dynamische Analyse beschreibteine nichtdeterministische Methode, die mit Heuristiken gezielte Modifikationen derEingangsparameter durchführt und die zugehörige Ausführungszeit des Programmsauf der Zielplattform misst. Dadurch lässt sich, wenn auch mit stochastischen Effektenbehaftet, die Ausführungsdauer des WCET-Pfades „von unten“ angenähert ermitteln/[KP96], [AHP99]/. Aufgrund dieser Näherung ist die dynamische WCET-Analyse keinzuverlässiges Mittel zur Bestimmung der WCET in sicherheitskritischen Systemen.

Komplementär zum dynamischen Ansatz wird bei der statischen WCET-Analysedie maximale Ausführungszeit unabhängig von der Zielplattform beim oder nach demKompilierungsvorgang theoretisch berechnet. Nach der Erfassung des WCET-Pfadeslässt sich die WCET durch die Modellierung der ausführbaren Pfade, welche die Aus-führungszeiten der durchschrittenen Instruktionen des Programms auf Basis der mo-dellierten Zielhardware repräsentieren, messen /[LME98]/. Die Herausforderung beidieser Methode liegt in der Ermittlung des WCET-Pfades und der deterministischenstatischen Ausführungszeiten der jeweiligen Codestrukturen /[SAHP97], [PV97b]/. DasVorgehen bei der Pfadmodellierung unter Berücksichtigung der Hardwareaktivitäten imAufbau der Mikroarchitekturen der Zielplattform (Caches, Pipelines) bildet einen eigenenForschungsbereich und wird innerhalb dieser Arbeit nicht adressiert.

Für einen detaillierten Einblick in die Konzepte der WCET-Analyse, insbesondereder Pfad- und Mikroarchitekturmodellierung wird auf /[Sha89], [PK89], [KL91], [Par92],[LME98], [FW99], /[Rin02]/ weiterverwiesen.

3.1.5.2. Schedulability-Test

Auf Basis einer WCET-Analyse folgt im nächsten Schritt eine Untersuchung, ob undin welcher Form sich die analysierten und zu Betriebssystemtasks zugeordneten Pro-grammteile auf die zugrunde gelegte Hardwareplattform abbilden lassen. Das loka-le Komponentenscheduling innerhalb eines Schedulingprozesses bezeichnet die zielge-führte Suche zur Erzeugung eines Ablaufplans für Betriebssystemkomponenten. Einwichtiger Aspekt bezieht sich auf die Einhaltung sämtlicher Ablaufzeiten der in einemlokalen System ablaufenden Prozesse. Dafür müssen die deadlines, also die spätest to-lerierbaren Zeitpunkte für den Abschluss der Ausführung der Tasks, in allen Fälleneingehalten werden. Gestaltungsspielraum bei der Umsetzung resultiert aus der Varia-bilität in der Festlegung von Anordnung, Zykluszeit und Unterbrechbarkeit einer jedenTask im Betriebssystemschedule. Der Vorgang der Suche, ob ein gültiger Schedule füreine bestimmte Konstellation an Prozessen, die sich mindestens eine gemeinsame Res-source teilen, gefunden werden kann, wird allgemein als Schedulability-Test /[Kop97]/bezeichnet.

Beim Schedulability-Test stellt sich zuerst die Frage nach einem Algorithmus, welcherzuverlässig bestimmt, ob für eine Menge an Tasks ein gültiger Schedule existiert. Auchder komplementäre Fall ist von Relevanz, um zuverlässig bestimmen zu können, obein derartiger Schedule nicht generierbar ist. In /[GJ75]/ wurde nachgewiesen, dassdie Komplexität für diesen Algorithmus zu der Klasse der NP-vollständigen Problemenzählt und sich somit nicht in polynomieller Zeit berechnen lässt. Daher reduziert sichdie Suche auf zwei alternative Testmethoden /[Kop97]/:

Hinreichender Schedulability-Test: Falls in einem Test für bestimmte Task-Konfiguratio-


nen kein Schedule gefunden wird, obwohl theoretisch eine gültige Konfiguration mög-lich ist, so wird der Schedulability-Test als hinreichend eingestuft.

Notwendiger Schedulability-Test: Für den komplementären Fall, indem ein Test eineungültige Task-Konfiguration fälschlicherweise als korrekt deklariert, wird der Schedu-lability-Test als notwendig bezeichnet.

Für die in einem Schedulability-Test berücksichtigten Tasks werden jeweils deren WCETin der Analyse eingesetzt. Die Ausführungsdauer e eines Tasks t(i) wird e(i) und dieZykluszeit eines Prozessors als p(i) bezeichnet. Eine gültige Echtzeitschedulingstrate-gie garantiert das Einhalten sämtlicher deadlines einer Taskgruppe. Für die Kalkulationder Prozessorverfügbarkeit lassen sich periodisch aktivierte Tasks m leicht zur Prozes-sorauslastung in Relation setzen.

m

∑i=1

e(i)p(i)

≤ Ul

Dieser Satz bezieht sich auf eine arbiträre Anzahl an Tasks e, die auf p Prozessoren miteinheitlichen Grundzyklen verteilt werden. Ul bezeichnet das obere Limit (upper limit),welches abhängig von der zugrunde gelegten Schedulingstrategie variiert. Beispielswei-se lässt sich die notwendige Bedingung für die Ableitung eines gültigen Schedules ausder Summe sämtlicher zu verteilender Tasks m pro Prozessor mit ∑m

i=1 e(i)/p(i) ≤ 1prüfen, falls als EDF (Earliest-Deadline-First) Schedulingstrategie festgelegt wird.

Eine Herausforderung beim Schedulability-Test ergibt sich aus den vielschichtigenDerivaten an Scheduling-Strategien, die jeweils geprüft werden müssen. Beispielswei-se basiert die RM-Strategie (rate-monotonic) mit einer statischen Prioritätenvergabe aufeinem anderen Wert für Ul. In /[LL73]/ wird bewiesen, dass die Gleichung Ul =m ∗ (21/m − 1) (≈ 0, 69) für den RM-Fall eine hinreichende Größe bildet, um zuverläs-sig zu prüfen, ob eine Menge an Tasks m in einen gültigen Schedule überführt werdenkann5.

Ähnlich zu dem Bereich der WCET-Analyse bildet die Schedulinganalyse eine ei-genständigen Forschungsbereich, der sich mit der Vielzahl an Konzepteinflüssen, etwadurch statische, dynamische oder gemischte Prioritätenvergabe oder beim Umgang mitgemischt hart/weichen Echtzeitanforderungen, zu befassen hat. Für eine Vertiefung derThematik zählen die Publikationen /[ABR+93], [TC94]/ als grundlegende Referenzenfür diesen Bereich.

3.1.5.3. Busscheduling

Aus Sicht des vernetzten zeitgesteuerten Systems sind die exakten Positionen der Kom-munikationsslots als Nebenbedingungen für das Design des verteilten Echtzeitsystemszu berücksichtigen, falls die partitionierten Funktionen über das Bussystem synchronmiteinander interagieren sollen /[ABR+93]/. Daher wird es für den Zweck eines ho-listischen Schedulingansatzes erforderlich den beim Schedulability-Test gefundenen Be-

5Das schließt nicht aus, dass bei einem größeren Wert (>0.69) niemals ein gültiger Schedule gefundenwerden kann.

3.2. STAND DER TECHNIK BEIM SYSTEMENTWURF 97

triebssystemschedule der Tasks eines jeden bussynchronen Steuergeräts mit dem Bus-schedule des zeitgesteuerten Bussystems abzustimmen.

3.2. Stand der Technik beim Systementwurf

Wie bereits einleitend in diesem Kapitel erläutert, liegt der Ursprung des zeitgesteuer-ten Paradigmas schon einige Jahre zurück, was zu einer breitflächigen Forschung undEntwicklung in diesem Kontext geführt hat. Speziell der Begriff der „Synchronität“ in ei-nem System findet sich dabei stetig in den Ansätzen wieder. Ein wichtiger Meilensteinliegt in dem Ansatz CSP (communicating sequential processes), einer Prozessalgebra, dieals Schwerpunkt auf die Interaktion kommunizierender Prozesse fokussiert. Ein Leitge-danke bezieht sich auf den nachrichtensynchronen Datenaustausch. Dabei entsteht dieNachrichtenverteilung auf Basis eines korrespondierenden Austauschs von Kommuni-kationsanweisungen zwischen den Prozessen. Dieses Szenario findet sich in der Formnicht im Fahrzeug wieder, da hier die Ausführung eines Prozesses und dessen Kom-munikationsverhalten im Netzwerk nichtdeterministisch und unabhängig von etwaigenkorrespondierenden Prozessen des verteilten Systems erfolgt.

Ein weiterer Meilenstein in der Umsetzung des zeitgesteuerten Paradigmas ist mitder Entwicklung von Esterel verbunden /[Ber00]/. Esterel definiert eine synchrone Pro-grammiersprache, die im Kontext der Entwicklung verteilter reaktiver Systeme ihre An-wendung findet. Im Vordergrund steht der Umgang mit der Ausführung parallel ablau-fender Systeme und den Aspekten präemptiver Programmierung. Eine Umsetzung derProgrammiersprache liegt heute modellbasiert in einer durchgehenden Werkzeugkettevor /[Tec08]/, die hauptsächlich bei der Entwicklung von sicherheitskritischer Softwareim Avionikbereich eingesetzt wird.

Ein interessantes Programmiermodell für harte Realzeitsysteme wird durch die Se-mantik von Giotto /[HHK01]/ definiert. Dabei stehen die periodische Interaktionenvon verteilten Tasks und deren Zustände im Vordergrund. Eine Funktion in einer Taskwird periodisch ausgeführt. Es werden neben den Eingabewerten auch Taskzuständeberücksichtigt und nach der Ausführung die ermittelten Ausgabewerte und neue gül-tige Taskzustände zurückliefert. Dabei wird analog zu einer berechneten WCET einelogische Ausführungszeit LET (logical execution time) zugrunde gelegt, die in ihrer zeitli-chen Ausprägung die tatsächliche Ausführungszeit einer Tasks in jedem Fall übersteigt.Dadurch werden deadline-Verletzungen vermieden6. Obwohl Giotto als eigenständigesProgrammiermodell sehr attraktiv für die Überführung in ein Entwicklungskonzept fürverteilte zeitgesteuerte Echtzeitsysteme erscheint, erfordert ein Serieneinsatz im Fahr-zeug ein breites ausgereiftes Portfolio für Softwarearchitekturen, Prozesse, Standardsund Werkzeuge. Mit dem auf Giotto basierenden TDL-Konzept (s. Abs. 3.2.1.2) ist mitt-lerweile eine erste spezifische Implementierung unter anderem für FlexRay entwickeltworden.

Zusammenfassend lässt sich analog zu /[MG07]/ folgern, dass aktuell noch eineLücke zwischen den meisten theoretischen Entwicklungsmethoden und deren Umset-zung in der praktischen Anwendung existiert. Dementsprechend spielen viele Ansätzeaktuell nur eine eingeschränkte oder keine Rolle bei der Entwicklung verteilter zeitge-

6Das Problem der Ermittlung der Länge einer jeden LET einer Tasks entspricht dem analogen Fall zuden Problemstellungen bei der WCET-Analyse.


steuerter Realzeitsysteme im Fahrzeugserienbereich7. Eine zukünftige Herausforderungbleibt der Nachweis der Umsetzbarkeit im industriellen Kontext unter Berücksichtigunggegebener Randbedingungen (z.B. Abstraktionsgrade, Integration von Entwicklungsar-tefakten, Kosten, Produktlebenszyklen, Standards, Werkzeuge, etc.). Daher werden dieInhalte der FlexZOOMED-Methode in der vorliegenden Arbeit weitestgehend im engenKontext zu den Anforderungen einer Entwicklung im Fahrzeugserienbereich umgesetzt.

3.2.1. Integrierte Entwicklungsmethoden

Der Bereich der modellbasierten Entwicklung zeitgesteuerter Architekturen wird in ver-schiedenen Forschungsarbeiten aus methodischer Sicht unterschiedlich behandelt. An-folgend werden mit DECOS, TDL und VIETTA drei signifikante integrierte Entwick-lungsmethoden aus den letzten Jahren als Referenzbeispiele dargestellt. Alternativ lässtsich in dem Bereich auch das Projekt SETTA /[SBV+02]/ anführen.

3.2.1.1. DECOS

Um eine möglichst flexibel einsetzbare und komponierbare Fahrzeugelektronik zur Ge-nerierung und Pflege von Fahrzeugvarianten mit verschiedenen Ausstattungsstufen zugarantieren, muss eine geeignete Plattform definiert werden. DECOS differenziert da-bei in einer Trennung zwischen der Applikationslogik und den zugrunde liegendenPlattformtechnologien, den Hardwarecharakteristika /[HOP05]/. Die in der Hardware-plattform steckenden Systemressourcen müssen dabei hinreichend detailliert gekapseltwerden, um eine Integration der Applikationsfunktionalität auf der Zielplattform zu er-möglichen. Dabei ist das Ziel eine maximale Flexibilität, Wiederverwendbarkeit und Er-weiterbarkeit im Sinne einer Pflege der Applikationsmodelle zu erreichen, unabhängigvon Technologieänderungen in der zugrunde liegenden Plattform. DECOS propagiertso genannte DAS (Distributed Application Services), welche gemäß des modellgetriebenenArchitekturkonzepts in plattformunabhängigen (Platform Independent Model) und platt-formabhängigen (Platform Specific Model) Modellen repräsentiert werden /[OMG01]/.

Die Herausforderung des verteilten System-Designs liegt in der notwendigen prä-zisen Spezifikationsform für den Systemdesigner, dessen Rolle in der Regel durch denSystemintegrator verkörpert wird. Da die Implementierung und die entsprechende Sys-temintelligenz der einzelnen Komponenten durch die jeweiligen Zulieferer bestimmtwerden, muss die Spezifikation aus Sicht des Systemintegrators durch ein Frameworkunterstützt werden, welches eine Reihe an Anforderungen mit sich bringt.

Die Verknüpfung zwischen den unabhängigen und den spezifischen Modellen er-folgt per Vorwärtstransformation, die als virtuelle Integration beschrieben wird. Die Be-zeichnung entstammt von der Idee eines Ressource Templates, welches die Hardware ab-strakt beschreibt und dabei eine virtuelle Plattform darstellt. Das plattformunabhän-gige Modell bschreibt eine Dekomposition der Systemfunktionalität in Jobs, die überwohldefinierte Zugänge (Ports) an einer verbindenden Schnittstelle (Linking Interface)kommunizieren können. Durch die Zerlegung lassen sich auch kritische Systemteilekomponieren. Deren Subsysteme können je nach Bedarf zertifiziert und validiert wer-den. Das plattformspezifische Modell beschreibt die Zuordnung der Jobs zu Partitio-nen und die Zuordnung des virtuellen Netzwerks zwischen den Partitionen zu einem

7Als weitere Beispiele lassen sich beispielsweise Ansätze mit FSM, Hybride Automaten, LSC, MSC, Pe-trinetze, Prozessalgebren, Statecharts, Temporallogik, gezeitete Automaten und Z nennen (vgl. /[MG07]/).


Platform Independent

DAS Representation

Platform Independent

DAS Representation

Platform-Independent

DAS Representation

Platform-Specific

System Representation

Resource

Specification

Executable Code

Virtual

Integration

Code

Generation

Deployment

Virtual

Integration

Code

Generation

Deployment

Abbildung 3.4.: DECOS System Designfluss

zeitgesteuerten Feldbussystem wie beispielsweise FlexRay /[Fle05a], [ZS06]/. HöhereArchitekturdienste, die an den Schnittstellen der Jobs bereitgestellt werden wie z.B. Ga-teways oder Diagnoseprüfungen werden ebenfalls in dem plattformspezifischen Modellparametriert. DECOS beschreibt die verschiedenen Hardwarekomponenten im Rahmenvon Ressourcenprimitiven (Resource Primitives), die im Metamodell der plattformspezi-fischen Lösung definiert sind.

3.2.1.2. Timing Definition Language

Die Timing Definition Language (TDL) /[FFPT05]/definiert einen formalen Ansatz zurabstrakten Spezifikation verteilter eingebetteter Systeme. Ziel in diesem Konzept ist diehardwareunabhängige Entwicklung eines verteilten Systems auf Basis eines logischenModells. Dieses Modell fundiert auf der Giotto-Programmsemantik (s. Abs. 3.2) undrichtet sich an die Entwicklung regelungstechnischer eingebetteter Systeme mit hartenEchtzeitanforderungen.

mode1

mode2

task1 [10ms]

task2 [20ms]

task1 [5ms]

task3 [1ms]

s1

s2

a1

a2

a3

Abbildung 3.5.: Beispielhafter Aufbau einer Komponente in einem TDL-Modell /[zei08]/

Ein TDL-Modell basiert grundsätzlich auf der Idee, dass sich ein verteiltes Systemaus der Interaktion zwischen Sensorik, Funktionalität und Aktorik zusammensetzt, wo-


bei die Funktionalität in Abhängigkeit des Ausführungsmodus abgearbeitet wird. EinModus spezifiziert periodisch ausgeführte Aktivitäten, welche sich aus Taskaktivierun-gen, Aktualisierungen der Aktorik-Daten und Moduswechsel in den Komponenten zu-sammensetzen. Die Ausführung der Aktivitäten, in Form von Tasks, werden je nachSystemkondition modusabhängig ausgeführt. Gleichzeitig nehmen die Modi Einflussauf die Taskausführungszeiten (s. Abb. 3.5) und werden hardwareunabhängig spezifi-ziert. Dieser Ansatz basiert auf der Idee einer logischen Ausführungszeit LET (logicalexecution time). Dabei wird analog zu einer berechneten WCET eine logische Zeit zu-grunde gelegt, die in ihrer zeitlichen Ausprägung die tatsächliche Ausführungszeit einerTask in jedem Fall übersteigt. Dadurch lassen sich deadline-Verletzungen vermeiden.

Der TDL-Ansatz ist mittlerweile als Plug-In-Lösung in die etablierten WerkzeugeMatlab/Simulink /[The07a]/ integriert worden, um die Regelsystementwicklung direktunterstützen zu können. Auf Basis generierter Artefakte (Code, Konfigurationen) lassensich hardware- oder feldbusspezifische Parameter des Systems in einer nachgelagertenWerkzeugkette konfigurieren.

3.2.1.3. VIETTA

/[Rin02]/ beschäftigt sich anschaulich mit technisch notwendigen Adaptionen des Ent-wicklungsprozesses zur Unterstützung zeitgesteuerter Systeme im Bereich automotiverAnwendungen. Speziell die Analyse der maximalen Ausführungszeiten von Softwa-reprozessen, deren Verteilung und zeitliche Ablaufplanung innerhalb der beteiligtenSteuergeräte werden intensiv untersucht. Parallel werden die Schnittstellen zur Anwen-dungsentwicklung mit klassischen modellbasierten Softwareentwicklungswerkzeugen/[Ber00], [The07a]/ und eine Einbettung des Gesamtkonzepts in den Entwicklungspro-zess beschrieben. /[Rin02]/ abstrahiert in seiner Arbeit von der konkreten Auslegungeiner flexiblen zeitgesteuerten Bustechnologie und deren Parametrierung. Der Fokuskönnte ergänzend von der exakten Spezifikation des Zeitverhaltens der Softwareprozes-se auf das Zeitkonzept der Signalkommunikation auf dem Bus erweitert werden. Wei-terhin bleiben firmenspezifische Abläufe innerhalb der Fahrzeugserienentwicklung undderen nicht-/funktionale Anforderungen, beispielsweise der Entwurf der technischenBordnetzarchitektur mit Plattform- und Variantenanforderungen, unberücksichtigt.

Im Vergleich dazu sind Teile der in /[Bro05]/ betrachteten Umfänge auf Basis einerkommerziellen Werkzeugkette entstanden, die konzeptuell in Analogie zu den Ansätzenvon /[Rin02]/ stehen. Aus heutiger Sicht lässt sich bestätigen, dass sich dieser Ansatznicht durchgesetzt hat, da eine Abbildung auf die dezentrale Organisationsform desFahrzeugherstellers in Zusammenarbeit mit mehreren Zulieferern bisher nicht definiertworden ist.

3.2.2. Verifikation zeitgesteuerter Systeme

Neben den entwurfsorientierten Ansätzen existiert mit /[Pik06]/ eine verwandte Arbeitim Bereich der formalen Verifikation zeitgesteuerter Systeme. Dabei liegt der Schwer-punkt gesamtheitlichen auf der Klasse der synchronisierten fehlertoleranten Steuerungs-und Kommunikationsarchitekturen. Auf Basis der partiell synchronen Systeme, einerErweiterung der abstrakten ungezeiteten synchronen Systeme um zeitgesteuerte Para-digmen, werden Annahmen mithilfe des mechanischen Theorembeweisens verifiziert.Dabei werden die realisierten Buskommunikationsabläufe mit der Kombination von


begrenzten Modellprüfungen (model-checking) und dem automatisierten Lösen auf not-wendige zeitgesteuerte Annahmen geprüft. Grundlage der Arbeit ist die bei der NASAentwickelte SPIDER Fly-by-wire-Busarchitektur /[NAS07]/.

3.2.3. Parametrierungsstrategien

Aktuell fehlen weiterführende Veröffentlichungen zur methodischen Entwicklung vonFlexRay-Systemkonfigurationen. Daher werden als Referenz zwei verfügbare unter-schiedliche Beschreibungen zur Entwicklung eines FlexRay-Systemdesigns betrachtet,die einerseits in Form einer Werkzeugdokumentation (Variante 1) und andererseits alsAbschnitt in dem einzigen verfügbaren FlexRay-Grundlagenbuch /[Rau07b]/ (Variante2) vorliegen.

Variante 1: In /[TTA07]/, einem dedizierten FlexRay-Designwerkzeug, erfolgt die Sys-temkonfiguration in einem Zwei-Level-Ansatz, was einer Trennung von Netzwerk- undKnotendesign entspricht. Dabei konzentriert sich die Definition des FlexRay-Parameter-satzes weitestgehend auf die Definition der Buszykluslänge, der Anzahl an statischenSlots, der statischen Slotlänge und der Nutzdatenlänge eines statischen Slots:

1. gdCycle

2. gNumberOfStaticSlots

3. gdStaticSlot

4. gStaticSlotPayload

In diesem Zusammenhang wird eine Erweiterung des Konzepts hinsichtlich einer drit-ten mittleren Abstraktionsebene zur Gruppierung von Signalen in PDUs auf Schedu-lingebene unterstützt. Dies entspricht den Anforderungen des AUTOSAR-Standards/[AUT07a]/. Dadurch wird von der Signalebene im Netzwerkdesign abstrahiert.

Variante 2: In folgender Tab. 3.1 wird der Ansatz von /[Rau07b]/ dargestellt, der zueiner pragmatischen Konfiguration eines FlexRay-Systems führt. Allerdings setzt die-ses Verfahren einige Annahmen wie die Buszykluslänge, die Nutzdatenlänge oder dieDämpfungswerte in der Uhrensynchronisation voraus, deren Herkunft nicht plausibili-siert wird.

3.2.4. Methodenvergleich

Während des Erstellungszeitraums dieser Arbeit sind drei kommerzielle Designent-wicklungswerkzeuge für die FlexRay-Systementwicklung am Markt verfügbar. Nach-folgend wird der Funktionsumfang dieser Werkzeuge im Abgleich mit den Ansätzenwissenschaftlicher Entwicklungsmethoden für zeitgesteuerte Bussysteme im Kontext ei-ner systematischen Architekturentwicklung analysiert.

Im Bereich der logischen Architekturentwicklung interessiert die Möglichkeit derfunktionalen Spezifikation einer Fahrzeugarchitektur über Funktionsmodule mit Schnitt-stellen zum Datenaustausch. Dabei ist es von Relevanz, ob den Modellen ein geeignetes


Parameter Herkunft Ableitung

Baudrate Keine Vorgabe

gdBit, gdSampletick, gdCASRxLowMax,gdWUPSymbolRxIdle, gdWUPSymbolRxLow,

gdWUPSymbolRxWindow, gdWUPSymbolTxIdle,gdWUPSymbolTxLow

Controllerfrequenz Hardware pdMicrotick, gdMacrotick, adprecisiongdCycle Keine Vorgabe pMicroPerCycle, gMacroPerCycle

gdMacrotick Keine Vorgabe pMicroPerCycle, gMacroPerCyclecClockDeviationMax Keine Vorgabe pMicroPerCycle, gMacroPerCycle

gNumberOfStaticSlots Keine Vorgabe Keine AbleitunggPayloadLengthStatic Keine Vorgabe Keine Ableitung

gPayloadLengthDynamicMax Keine Vorgabe Keine AbleitunggSymbolWindow je nach Einsatz Keine Ableitung

gdMinPropagationDelay Netzwerktopologie adprecision, pDelayCompensationgdMaxPropagationDelay dCableDelay, dBDRx10, dBDTx10, dStarDelay adprecision, pDelayCompensation

pdMaxDriftDamping Keine Vorgabe adprecision

gdMaxDriftDamping Keine Vorgabe adprecision, gdActionPointOffset,gdMinislotActionPointOffset, SafetyMargin

dBDRxia Keine Vorgabe gdTSSTransmitterdStarTruncation Hardware, cClockDeviationMax gdTSSTransmitter

gdTSSTransmitter Keine Vorgabe pDecodingCorrection

gdStaticSlot gPayloadLengthStatic, gdActionPointOffset,gdTSSTransmitter Keine Ableitung

gdMiniSlot gdMinislotActionPointOffset, adprecision,gdMaxPropagationDelay, gdTSSTransmitter Keine Ableitung

gdDynamicSlotIdlePhase gdMiniSlot, adprecision,gdMaxPropagationDelay Keine Ableitung

pOffsetCorrectionOut adPrecision Keine AbleitungpRateCorrectionOut gdCycle, cclockdeviationmax Keine Ableitung

pExternOffsetCorrection Keine Vorgabe Keine AbleitungpExternRateCorrection Keine Vorgabe Keine Ableitung

gdNIT pOffsetCorrectionOut, gNumberOfDynamicSlots,gdCycle, gNumberOfStaticSlots gOffsetCorrectionStart

gMacroInitialOffset[A/B] gdTSSTransmitter Keine AbleitunggMicroInitialOffset[A/B] Keine Ableitung

pdListenTimeout pdMaxDrift, pdAcceptedStartupRange Keine AbleitunggListenNoise Keine Vorgabe Keine Ableitung

gColdStartAttempts Keine Vorgabe Keine AbleitunggNetworkManagementVectorLength Keine Vorgabe Keine AbleitunggMaxWithoutClockCorrectionPassive Keine Vorgabe Keine Ableitung

gMaxWithoutClockCorrectionFatal Keine Vorgabe Keine AbleitungpAllowActiveToPassive Keine Vorgabe Keine Ableitung

Tabelle 3.1.: Tabellarische Auflistung für den Prozess der Herleitung einer FlexRay-Konfi-guration

Zeitmodell zugrunde liegt, welches für weiterverarbeitende Prozessschritte, beispiels-weise zum Scheduling, herangezogen wird. Unter der technischen Architekturspezifika-tion zählt die konkrete Erfassung der Netzwerktopologie sowie der Steuergerätekompo-nenten in bedateten Modellen, um integrierte Aussagen über Verkabelungsgrößen, Ver-kabelungsart oder Hardwareeigenschaften abzuleiten. Speziell beim FlexRay-Bussystemstellt der Parametrierungsprozess eine eigenständige komplexe Entwicklungsdisziplindar. Dabei stellt sich die Frage nach einer vollständigen Abbildbarkeit des Parameter-satzes im Entwicklungskonzept und ob zusätzliche Mittel zur Strukturierung des Para-metermodells vorhanden sind. Um einen ausgereiften Parametrierungsprozess durch-zuführen, spielt die Einbettung der logischen und technischen Architektur und derenVarianten eine wesentliche Rolle.

Zu den Analysemöglichkeiten zählt bei der statischen Analyse die Modellverifikati-on mithilfe statischer Prüfmethoden (Metriken, Konsistenzprüfungen, etc.) und bei derdynamischen Analyse die Simulation. Die Unterstützung hervorgehobener Methoden(WCET-Analyse, Schedulability-Test) bei der Entwicklung verteilter zeitgesteuerter Sys-teme steht dabei im Vordergrund. Zusätzlich stellt sich die Frage nach einem erhöhtenAutomatisierungsgrad während der Entwicklung. Dazu zählen Optimierungstechnikenund Möglichkeiten zur Generierung von Netzwerkschedules.

In Tab. 3.2 werden fünf verschiedene relevante Ansätze aus der Forschung und ausdem kommerziellen Bereich in Bezug auf die genannten Leistungsmerkmale direkt mit-einander verglichen. Die Inhalte der Entwicklungsansätze sind in Abs. 3.2 aufgeführt.

3.3. KONZEPTE DES FLEXIBLEN ZEITGESTEUERTEN BUSSYSTEMS FLEXRAY 103

MethodeEigenschaften DECOS VIETTA TDL DaVinci DesignerPro TTX

Forschung KommerziellLogische Architektur + + + - - -Zeitmodell + + + - - -Funktionsnetze + + + - - -Technische Architektur o o o - o -Komponenten + - + - + -Topologien - o - - - -Parametrierung - - o o o +Vollständigkeit - - + + + +Strukturiert - - - - - +Varianten - - - - - -Analyse o + + + o odynamisch o + + - - -statisch + + + + + +Schedulability o + - - - +WCET-Analyse - + - - - -Automatisierung o o o - - oOptimierung o - o - - -Scheduling + o + - - +

Tabelle 3.2.: Übersicht zum Umfang der Entwicklungsmethodiken von etablierten entwickeltenLösungen im Bereich der zeitgesteuerten Architekturen

3.3. Konzepte des flexiblen zeitgesteuerten Bussystems FlexRay

Das Hochgeschwindigkeitskommunikationssystem FlexRay stellt in dieser Arbeit dieReferenztechnologie für das zentral behandelte Thema der flexiblen zeitgesteuerten Ar-chitekturen im Fahrzeugserienbereich. Die für das Verständnis der nachfolgenden Ka-pitel notwendigen Aspekte von FlexRay werden daher kurz beschrieben.

3.3.1. Übersicht

Im Jahre 1999 hat sich eine herstellerübergreifende Initiative mit dem Ziel der Spezifika-tion einer neuen Feldbustechnologie gebildet, um den zukünftig erwarteten gesteigertenAnforderungen an E/E-Systeme in Serienfahrzeugen gerecht zu werden. Folgende Ei-genschaften stehen dabei im Vordergrund:

Performanz: Für die Verknüpfung kommunikationsintensiver verteilter Fahrzeugfunk-tionen soll eine Bandbreitenerhöhung des Netzwerks um Faktor 10 den Bedarf fürdie Umsetzung eines gesteigerten Datenaufkommens im Fahrzeug decken.

Erweiterbarkeit: Systemintegrationen innerhalb des Netzwerks sollen funktional unab-hängig komponierbar durchgeführt werden. Speziell eine Interferenz derBuszugriffszeiten bei mehreren Netzwerkteilnehmern, die verstärkt bei hoher Bus-auslastung auftreten, muss ausgeschlossen werden.

Verlässlichkeit: Die funktionale Sicherheit der im Netzwerk zu applizierenden Funk-tionen muss je nach Anforderung gewährleistet bleiben. Ein skalierbar einsetzba-res Konzept geeigneter Fehlertoleranzmaßnahmen spielt in diesem Zusammen-hang eine entscheidende Rolle.


Flexibilität: Die drei vorangegangenen Eigenschaften dürfen je nach Einsatzszenarioanwendungsspezifisch konfektioniert werden, um die individuellen Anforderun-gen des Fahrzeugherstellers erfüllen zu können.

Präzision: Durch ein deterministisches Paradigma können verteilte Systeme präziseentwickelt und aufeinander abgestimmt werden. Die Momentaufnahme eines Sys-temzustands (snapshot), die sich in verteilten Komponenten synchron verarbeitenlässt, unterstützt die Entwicklung hochperformanter verteilter Regelungen unterVerwendung eines zwischengeschalteten Bussystems.

3.3.2. Physikalische Bitübertragungsschicht

FlexRay stellt prinzipiell ein von der physikalischen Übertragungsart unabhängigesFeldbussystem dar. Aufgrund der Anforderungen einer maximaler Bandbreitenbereit-stellung und kosteneffizienter Produktion des Fahrzeugherstellers basiert die erste Ge-neration der FlexRay-Technologie auf einem elektrischen Übertragungsmedium, dasvorzugsweise mit 10Mbit/s betrieben wird.

Aus Sicht eines Fahrzeugherstellers bringen Netzwerktechnologien mit elektrischenÜbertragungsmedien eine Reihe von Anforderungen mit, die es im Fahrzeug zu beherr-schen gilt. Grund dafür sind eine Reihe von Faktoren, die zu einer stabilen Serienent-wicklung beitragen:

• Flexibilität in der Anordnung und dem vorgesehenen Verbauort für Steuergeräteim Fahrzeug,

• Geringe Anzahl an Bauteilvarianten (Hardwarebestückoptionen eines Steuerge-räts),

• Zuverlässiger Signalaustausch innerhalb der geforderten maximalen System-lebensdauer (Robustheit, Stabilität, Fehlertoleranz),

• Geringe störende Wechselwirkungen mit anderen Systemen (ElektromagnetischeStörein- und -abstrahlung),

• Austauschbarkeit von Hardwarekomponenten (Veränderungen des Hardwarelay-outs),

• Energieeffiziente Betriebsmodi (Weckbarkeit, Schlafmodus),

• Leichte Integrationsmöglichkeit weiterer Steuergeräte.

In der E/E-Entwicklung fliesst ein entsprechend großer Aufwand in die Analyse derKomponenten und deren Wechselwirkung mit umliegenden Bauteilen. Um eine kor-rekte Funktionsweise des Netzwerks zu gewährleisten, müssen die Einflüsse sämtli-cher Bauteile auf die physikalische Qualität der Signaldarstellung des Busprotokollsbeherrscht werden. FlexRay erfordert aufgrund seiner hochfrequenten Übertragungs-technik besondere Beachtung im Bezug auf die Abmessungen der für das Fahrzeugvorgesehenen Netzwerktopologien. Die Prämisse liegt auf einer verlässlichen Übertra-gung eines Bits zwischen allen möglichen Kommunikationsverbindungen im Netzwerk.Der Umgang mit den physikalischen Parametern wird als Ergänzung separat von derSpezifikation der physikalischen Bitübertragungsschicht behandelt /[Fle06b]/.


3.3.2.1. Topologien

Die Anordnung der physikalischen Netzwerkstruktur ermöglicht eine anwendungsori-entierte Konfiguration des Feldbussystems. Dies erfolgt über den Einsatz unterschiedli-cher Topologievarianten (s. Abb. 3.6):

...

...

...

...

...

...

...

...

...

...

Linearer BusAktiver

SternSternPassiverPassiver Einkanaliges Zweikanaliges

HybridHybrid

SG1SG1SG1SG1SG1

SG1SG1SG1SG1SG1

SGNSGNSGNSGNSGN

AS1AS1AS1

AS2

Abbildung 3.6.: Netzwerktopologievarianten für FlexRay-Architekturen

Passiver linearer Bus: Die Basisbusstruktur entsteht durch die Anbindung der einzelnenNetzwerkteilnehmer per Stichleitungen (Stubs) an einen längeren Übertragungskanal,der als gemeinsamer Bus die Knoten verbindet. Die Längen der Stichleitungen, derenAbstände auf dem Bus und die Maximallänge des Busses sind zu beachten.

Passiver Stern:

Bei der passiven Sterntopologie werden die Busteilnehmer per Spleißverfahren in einemPunkt des Netzwerks physikalisch verknüpft. Dabei werden die Übertragungskabel imBordnetz ohne zwischengeschaltete physikalische Terminierung in einer Komponentezusammengeführt. Als Konsequenz erhöht sich das Potential für Signalreflexionen imÜbertragungsmedium, was je nach Ausprägung zu einem Risiko für die fehlerfreie Sig-naldarstellung auf dem Bus werden kann.

Aktiver Stern:

Um die kostenrelevanten Anforderungen an den Kabeltyp im Netzwerk zu reduziereneignen sich aktive Komponenten zur Verknüpfung mehrerer Netzwerkabschnitte. Dazuzählen die aktiven Sternkoppler (s. Abb. 3.7).Diese Komponenten können ersatzweise zur passiven Sterntopologie im Netzwerk ver-baut werden, um die Netzwerkteilnehmer zu verknüpfen. Dabei werden die empfange-nen Signale jedes Sternzweigs auf alle restlichen angeschlossenen Sternzweige gespie-gelt. Ein Vorteil besteht in dem internen Logikbaustein des aktiven Sternkopplers, derdas auf dem Bus anliegende Differenzbussignal in ein im Wertebereich diskretes (digita-les) Datensignal wandelt. Dadurch ergibt sich die Möglichkeit zum gezielten Ausgleich


Microcontroller(HOST)

CommunicationController

Bus Driver

TxEN

SPI

4

INTN

TRXD1

TRXD2

BP_1 BM_1

TxD RxD VIO VCC INH

VBAT

GND

PowerSupply

ECU 1

LWULocalWakeup

to additionalstars

VBUF

BP_2 BM_2 BP_3 BM_3 BP_4 BM_4

Host Interface (SPI + Interrupt)

Single_Branch_1

Single_Branch_2....

Single_Branch_3....

Single_Branch_4....

Star Transmitter & Receiver

CentralLogic

E910.56

CommunicationController Interface

BP_1

BM_1

SCSN

SCK

SDI

RxD

TxD

Inhibit & Wake INH

LWU

TxEN

PowerSupply

Undervolt.Monitor

VBAT

VCC

VIO

SDO

INTN

GND

BP_2

BM_2

BP_3

BM_3

BP_4

BM_4

TRXD1

TRXD2

VBUF

Bus Failure Detector_1

Transmitter_1

Receiver_1

Wake up Detector_1

POR

Vref5V Regulator Overtemp.

Monitor

Abbildung 3.7.: Blockdiagramm zum internen Aufbau eines Sternkopplers und Beispiel für des-sen Applikation auf einem Steuergerät /[ELM07]/

der verzerrenden Effekte bei der Signalausbreitung im Netzwerk wie Signaldämpfungenoder -rauschen. Aktive Sterne werden daher je nach Systemkonfiguration bei bestimm-ten Verkabelungsabständen (d > 24m) der Netzwerkteilnehmer erforderlich /[Fle04b]/.Je nach Aufbau wird technisch zwischen einem monolithischen (integrierter Baustein)und einem diskreten (Verknüpfung von Einzelbausteinen) aktiven Sternkoppler unter-schieden. Dieser Unterschied beeinflusst entsprechende Effekte im Zeitbereich der Si-gnalweiterleitung.

Der Einsatz eines aktiven Sternkopplers erfordert eine frühzeitige Beachtung im Sys-tementwurf bei der Systemparametrierung. Durch die aktiven Eigenschaften entstehtbeim initialen Aufbau der Kommunikationsverbindung eine Verkürzung des eingehen-den Bussignals an den Ein- und Ausgängen im Sternkoppler aufgrund von internenReaktionszeiten. Weiterhin führt die Überbrückung des Bussignals zu einer kontinuier-lichen Verzögerung. Signalverkürzung und -verzögerung bilden elementare Bestandteileeiner FlexRay-Systemparametrierung.

Einkanaliges Hybrid:

Grundsätzlich lassen sich die drei Grundtopologien linearer passiver Bus, aktiver Sternund passiver Stern miteinander kombinieren, wobei grundsätzliche Regeln über Anzahlund Anordnung der Grundtopologieformen berücksichtigt bleiben muss /[Rau07b],[Fle04b]/. Starken Einfluss haben passive Sterntopologien auf die Signalausprägung imZeitbereich. Bisherige Analysen schließen daher passive Sterne in einkanaligen Hybrid-topologien aus /[Fle06a]/.

Zweikanaliges Hybrid:

Zweikanalige Hybridtopologien entstammen dem Wunsch nach skalierbarer Fehlerto-leranz im Sinne der Erhöhung der Netzwerkzuverlässigkeit. Alternativ könnte anstatteiner redundanten Datenübertragung eine beliebige Netzwerkbedatung auf dem zwei-


ten Kanal im Hybrid übertragen werden. Aufgrund technischer Einschränkungen, bei-spielsweise der limitierten Hardwarepufferanzahl in jedem Kommunikationscontroller,die für beide Kanäle aufzuteilen sind, verliert die unterschiedliche Bedatung der Netz-werkkanäle an Attraktivität8.

3.3.2.2. Signaldefinition

Die Datenübertragung zwischen zwei Bustreibern basiert auf einem zeit- und wertkon-tinuierlichen Signal. Dieses wird als Differenzsignal aus den beiden Spannungswertender zwei FlexRay-Kabeladern pro Kanal UBP und UBM gewonnen. Signifikant ist Vari-anz der Signalausprägung an unterschiedlichen Stellen des Netzwerks. Wesentlich da-für sind die Werte direkt am Sendetransceiver (TP1) und am Empfangstransceiver (TP4).Dazwischen lassen sich die Werte zusätzlich an den Sende- und Empfangpins der Ste-cker der zwei in dieser Übertragung beteiligten Steuergeräte messen (TP2 und TP3).Eine gültige Signalübertragung zur Darstellung eines logischen Bitwerts liegt absolutbetrachtet an der Stelle TP1 stets im Bereich zwischen |600mV − 2000mV| und bei TP4im Bereich zwischen |300mV − 2000mV|.

Signalkollisionen treten protokollbedingt im asynchronen Zustand bei der Initiali-sierung eines FlexRay-Systems auf. Zur Verhinderung von Datenverlusten werden indiesen kritischen Phasen drei Bussymbole9 (WakeUp, MediaTest und CollisionAvoidance)eingesetzt und ohne Nutzdaten übertragen werden. Da diese Signale alle durch den do-minanten Datenwert Data_0 ausgedrückt werden, führt eine Kollision in diesem Bereichzu zeitlichen Verlängerungen der angenommenen Übertragungszeiten von Data_0 desjeweiligen Symbols. Diese Effekte müssen bei der Konfiguration berücksichtigt werden.

3.3.2.3. Signalübertragung

Bei der Signalpropagation im Netzwerk wirken physikalische Effekte, die im Sinne einerzuverlässigen Funktionstüchtigkeit zu berücksichtigen sind. Daraus lassen sich Annah-men ableiten, die vorab eines Systemeinsatzes im Design eingehalten bleiben müssen.

Asymmetrische Ausbreitungsverzögerung: Eine FlexRay-Transceiverarchitektur für einelektrisches Übertragungsmedium erzeugt ein leicht asymmetrisches Signal auf der Sen-derseite (s. Abb. 3.8). Daher existieren unterschiedliche Anstiegs- und Abfallzeiten fürdie Signalflanken beim Wechsel von "´0“ auf "´1“ und umgekehrt.

dBusTx01 = dBusTx10

Zusätzlich erzeugen zwei verschiedene Treibermechanismen in der Signalerzeugung ei-ne Unterbrechung in den Signalflanken, die in die Berechnung der Anstiegs- und Fall-zeiten einfliesst. Auf der Empfängerseite ergeben sich unterschiedliche Ausprägungender Anstiegs- und Fallzeiten des Bussignals und des digitalen Signals am Decoderpin

8Aktuell spielen zweikanalige Topologievarianten, aufgrund teurer Verkabelungsaufwände bei derzei-tig eingeschränkten technischen Anwendungsmöglichkeiten, keine Rolle in der Fahrzeugserienentwick-lung. Daher werden diese Topologievarianten in der vorliegenden Arbeit nicht weiter berücksichtigt.

9Die Bussymbole bilden Steuersignale und bestehen aus clusterweit einheitlich definierten Mustern anData_0- und Data_1-Sequenzen.


90%

10%

100%

0%

uBDTx

-uBDTx

uBus@TP1

dBusTx01 dBusTx10

t

Abbildung 3.8.: Asymmetrische Verzögerung am sendenden FlexRay-Bustreiber

RxD eines FlexRay-Kommunikationscontrollers (s. Abb. 3.9). Verstärkt wird dieser Effektdurch Hysteresetoleranzen auf dem RxD-Ausgang des FlexRay-Transceivers.

300mV

-300mV

uRxData

-uRxData

uBus@TP4

t

100% VDIG

RxD

dRxD01

70% VDIG

30% VDIG

0% VDIG

dBusRx01dBDRx01

dRxD10

dBDRx10

dBDRx01

dBDRx10

Abbildung 3.9.: Asymmetrische Verzögerung am empfangenden FlexRay-Bustreiber

dBusRx01 = dBusRx10 = dRxD10 = dRx01


Sendeverkürzung: Das Setzen von Eingabe- und Ausgabeverbindungen innerhalb einesaktiven Sterns und die Aktivitätserkennung des Busses am FlexRay-Receiver benöti-gen physikalische Zeit während der Datenübertragung. Dadurch ergibt sich eine Ver-kürzung des übertragenen Bussignals um mehrere Bitlängen am Signalanfang (s. Abb.3.10). Dieser Effekt wird durch eine spezifisch addierte Startsequenz TSS (TransmissionStart Sequence) kompensiert. Die zum Übertragungsstart zeitliche Ausprägung der TSSdTSS abzüglich des kummulativen Effekts der Signalverkürzung entspricht:

1 ≤ dTSS ≤ (gdTSSTransmitter + 1) [Bit]

EMV: Elektromagnetische Einflüsse auf der elektrischen Bitübertragungsschicht desBussystems verstärken je nach Applikation einer Topologie die verschiedenen physi-kalischen Effekte bei der Signalübertragung im Fahrzeug.

1 0 X1 X20 00

dStarDelay

IN

Out

idle

Branch A

Branch B, C, D

idle

uBP

uBM

uBP

uBM

1 1

1 0 X1 X20 1 1

dStarDelay0

dTSSA

dTSSB

Abbildung 3.10.: Sendesignalverkürzung im FlexRay-Sternkoppler /[Fle04b]/

Glitches: Im Bereich der Signalübertragung können durch kurzeitige physikalische Stö-rungen (bspw. EMV-Einstrahlungen) temporäre Verfälschungen des Signalwerts entste-hen. Bei elektronischen Komponenten werden Glitches auch durch abweichende Signal-laufzeiten in Schaltungen verursacht, welche boolesche Berechnungsformeln verfälschen(race conditions). Lokal begrenzte Glitches lassen sich in FlexRay mithilfe des Mehrheits-votierungsverfahren bei der Dekodierung eines Bits ausgleichen.

Signalflanken/-pegel: Bei der Signalausprägung interessieren vorrangig die Latenzenbeim Wechsel des Signalpegels. Dies ist entscheidend, da durch die asymmetrische Si-gnalverzögerung eine Verkürzung der Signalflanken erzeugt wird. Die Auswirkungenmüssen durch schnelle Wechselzeiten des Signalpegels bei der physikalischen Bitdar-stellung beschränkt werden.


Signaldämpfung: Die Spezifikation des physikalischen Bordnetzes führt je nach Topo-logie- und Leitungseigenschaften zu Signaldämpfungen. Während des Systemdesignsmuss dabei beachtet werden, dass kritische Schwellwerte des Spannungspegels für dieDarstellung des logischen Signalwerts nicht unter- oder überschritten werden dürfen.

3.3.2.4. Hardwarekomponenten

Allgemein lassen sich die Komponenten eines FlexRay-Clusters in die Bereiche der Aus-führungseinheiten, der Busanbindung und des Übertragungskanals untergliedern. DieAusführungseinheit verkörpert die Komponente, welche die Protokollmaschine imple-mentiert. Dabei wird zwischen integrierten Lösungen, etwa dedizierte Mikrocontrollermit eingebetteten FlexRay-Logikbausteinen, und eigenständigen Protokoll-Controllern(Stand-Alone-CC) unterschieden. Während die eingebetteten Chips vorrangig als ASICsimplementiert sind, bieten sich bei den Stand-Alone-CCs auch FPGA-Varianten an. Beider Systemanbindung interessiert die Art und der Aufbau des Transceivers (Standard/-Stern, diskret/monolithisch) sowie sämtliche Bauteile, welche Einfluss auf die Signal-ausprägung nehmen (Terminierungen, Drosseln, Kondensatoren). Der Übertragungska-nal basiert auf der Spezifikation des Bordnetzes (Topologien, Kabelsegmente, Dämp-fungseigenschaften, Verzögerungseigenschaften).

3.3.3. Protokollschicht

Die Protokollschicht beinhaltet die grundlegenden Operationen, die zur Ausführungder stabilen zeitgesteuerten Kommunikation notwendig sind. Dazu zählt die System-konfiguration, das Weck- und Aufstartverhalten des Clusters, die Kodierung und De-kodierung des Netzwerksignals, die zyklische Uhrensynchronisation und das Verhaltenim Fehlerfall. Der Kern zur Koordination sämtlicher Operationen erfolgt in der Proto-kollablaufkontrolle, deren Konzept zusammen mit den wichtigsten Teilfunktionen kurzerläutert wird.

3.3.3.1. Protokollausführungskontrolle

Die Protokollausführungskontrolle POC (s. Abb. 3.11) lässt sich in Form eines endlichenAutomaten darstellen. Die Protokollalgorithmen werden dabei aus der Perspektive desprozeduralen Ablaufs in vier verschiedene Verhaltensklassen eingeteilt:

1. Verhalten zur Überführung der POC in einen startfähigen Zustand (READY). Nachdem Anliegen der Mindestspannung wird der Zustand DEFAULT CONFIG betre-ten und die POC initialisiert. Im Zustand CONFIG wird diese Ausgangskonfigu-ration verifiziert. Mit einer verifizierten Konfiguration werden die Kernprozesseinitialisiert und der Zustand READY erreicht.

2. Verhalten, das von dem READY-Zustand nach NORMAL ACTIVE führt. In diesemSchritt wird der StartUp eines Clusters oder die Integration in ein bereits aktivesCluster ausgeführt. Für den Fall eines weckfähigen Clusters kann auch eine ent-sprechende WakeUp-Prozedur angestossen werden.

3. Verhalten, das bei Erreichen des normalen Operationszustandes gegeben ist (NOR-MAL ACTIVE). Befehle und Statusinformationen werden zwischen dem Kom-


Reset

StartUpWakeUp

Ready

Config

POC Operational Control

Halt

NormalActive

NormalPassive

DefaultConfig

PowerOff

Power On

Abbildung 3.11.: Protokollablaufkontrolle POC auf einem FlexRay-Kommunikationscontroller

munikationscontroller und dem restlichen Steuergerät (Host) ausgetauscht. Wäh-rend des normalen Operationszustands wird eine permanente Fehlerüberprüfungdurchgeführt (Synchronisationsfehler). Bei detektierten Fehlern lässt sich ein Steu-ergerät optional erst in einen passiven Betriebszustand (NORMAL PASSIVE) über-führen, um eine direkte Terminierung der Integration im Cluster zu vermeiden.

4. Host-Befehle, die den regulären Verhaltensfluss unterbrechen. Zu diesen entzie-henden Befehlen zählt beispielsweise ein spezieller Freeze-Befehl, der die Protokoll-maschine beim Eintreten eines schwerwiegenden Fehlers abrupt in einen ZustandHALT überführt.

3.3.3.2. Weck- und Aufstartverhalten

Aus technischer Sicht ist der Startvorgang (StartUp) zur Erreichung einer stabilen syn-chronen Buskommunikation in einem zeitgesteuerten Bussystem als kritische Phase zubetrachten /[SK06]/.

In Abhängigkeit von der Konfigurationseinstellung können die Netzwerkknoten di-rekt nach Erreichen der Betriebsspannung den Startvorgang einleiten. Falls mindestensein Teilnehmer den Schlafmodus (Sleep) unterstützt, muss vorab des Startversuchs einWeckvorgang (WakeUp) eingeleitet werden. Beim eigentlichen Startvorgang reagierendie FlexRay-Kommunikationscontroller auf spezielle StartUp-Botschaften im Übertra-gungskanal. Ein gesetztes StartUp-Bit in den Steuerdaten der Botschaft identifiziert se-


mantisch eine StartUp-Botschaft. Auf Basis der detektierten Ankunftszeit lassen sichsomit einzelne Zeitstempel für die Netzwerkteilnehmer, die eine StartUp-Botschaft ver-sendet haben, ausrechnen. Da sich die Knoten die globale Zeit des Clusters aus deneinzelnen StartUp-Botschaften errechnen, müssen bei einem Startvorgang mindestenszwei StartUp-fähige Netzwerkteilnehmer aktiv den Clusterstart initiieren.

Ein Clusterstart, der nicht nach dem Verlassen eines Schlafmodus dem Weckvorgangfolgt, sondern direkt nach der Initialisierung der Spannungsversorgung stattfindet, wirdallgemein als Kaltstart (Coldstart) bezeichnet. Abb. 3.12 zeigt die Ablaufsequenz einespotentiellen WakeUp- und StartUp-Vorgangs. Folgendes Szenario wird hierbei exem-plarisch durchgespielt:

Spannungsv

erso

rgung

Kollision erkannt

RxIdle

RxIdle

RxLow

WakeUpSymbolRxWindow

TxIdle

TxLow

RxIdle

TxIdle

TxLow TxLow

TxIdle

TxLow

RxIdle RxIdle

RxLow RxLow RxLow

RxLow RxLow

BotschaftKnoten A

BotschaftKnoten A

BotschaftKnoten A

Schedule-Initialisierung(4*gdCycle)

gdCASRxLowMax

tStartUp

tStartUp

tStartUpNoise

Knot

en A

Knot

en B

Knote

n C

BotschaftKnoten A

BotschaftKnoten B

BotschaftKnoten A

BotschaftKnoten B

BotschaftKnoten C

BotschaftKnoten A

BotschaftKnoten B

BotschaftKnoten A

BotschaftKnoten B

BotschaftKnoten C

BotschaftKnoten A

BotschaftKnoten B

BotschaftKnoten A

BotschaftKnoten B

BotschaftKnoten C

Coldstart-Join(4*gdCycle)

Normal Active(StartUp und Integration abgeschlossen)

Knote

n A

Knot

en B

Knote

n C

Abbildung 3.12.: Szenario einer Ablaufsequenz des WakeUps mit anschließendem Clusterkalt-start

1. In dem Cluster sind drei FlexRay-Steuergeräte verbaut, darunter zwei Coldstart-Knoten (A,B) und ein Non-Sync-Knoten (C), der während des StartUp-Vorgangseine passive Rolle einnimmt.

2. Bei anliegender Spannungsversorgung sind alle Steuergeräte auf Anhieb imSchlafmodus, wobei der interne Steuergerätehochlauf unterschiedliche Zeitinter-valle beansprucht10.

3. Der von Knoten B initiierte Weckvorgang wird von dem Weckvorgang des spä-ter initialisierten Knoten A überlagert. Knoten B bricht nach der Detektion derWakeUp-Kollision den Weckvorgang ab.

10Das Anwendungsbeispiel abstrahiert von der Tatsache, ob ein unmittelbarer Schlafzustand nach demAnliegen der Spannungsversorgung sinnvoll/möglich ist.


Spannungsversorgung 50 210 msWeckvorgang 60 1896 μs ( 10Mbit/s)Prestartphase 66 10030 μs ( 10Mbit/s, gdCycle≤5ms)Synchronisationsphase 262 40000 μs ( 10Mbit/s, gdCycle≤5ms)Summe 50,4 261,9 ms ( 10Mbit/s, gdCycle≤5ms)

100,1 261,9 ms ( 10Mbit/s, gdCycle=5ms)-Spannungsversorgung 50,1 51,9 ms ( 10Mbit/s, gdCycle=5ms)

Tabelle 3.3.: Einflussfaktoren zum Zeitverhalten beim Weck- und Startvorgang eines Clusters

4. Knoten A versucht im Anschluss des Weckvorgangs das Cluster kaltzustarten.Durch den Ablauf des Timers tStartUp kann Knoten A durch die anhaltende Bus-ruhe einen Kaltstartversuch beginnen. Knoten B initialisiert seinen Timer tStartUpspäter als Knoten A. Über das CAS-Symbol (collision avoidance symbol) detektiertKnoten B, dass keine Busruhe auf dem Übertragungskanal herrscht. Während desAblauf des neuinitialisierten Timers tStartUpNoise versucht Knoten B anschließenddie am Bus anliegenden Signale einem StartUp-Vorgang zuzuordnen11.

5. Bei der Schedule-Initialisierung wird die StartUp-Botschaft des Knoten A vier Bus-zyklen lang an der richtigen Stelle im Schedule übertragen.

6. Knoten B schließt sich dem StartUp-Vorgang nach der korrekten Dekodierung undder Validierung der Zeitstempel der vier StartUp-Botschaften an. Vier Buszyklenlang wird dabei zusätzlich die StartUp-Botschaft des Knoten B gesendet, auf densich Knoten A gleichermaßen synchronisiert.

7. Nach acht Buszyklen ist eine stabile Bussynchronisation erreicht und sämtlichekonventionelle Knoten beginnen ihre Botschaften gemäß des geplanten Bussche-dules zu übertragen.

Aus dem Ablauf lässt sich entnehmen, dass mehrere Faktoren die benötigte Zeit bis zurstabilen Bussynchronisation beeinflussen:

Wie in Tab. 3.3 ersichtlich, wird die zeitliche Ausprägung des Aufstartverhaltens derKnoten signifikant durch die Latenz beim Anlegen der Spannungsversorgung und demInitialisieren der einzelnen Knoten beeinflusst. Zusätzlich spielt die Buszykluslänge fürdie Berechnung des Startvorgangs eine wichtige Rolle. Durch eine Reduzierung dieserbeiden Einflüsse lässt sich während des gesamten Weck-/Startvorgangs in einem 5ms-Zyklus bei einer Busgeschwindigkeit von 10Mbit/s eine Varianz im Bereich von 3,6%erzielen. Wird die Tatsache miteinbezogen, dass der Kaltstartknoten bereits nach demsechsten Buszyklus (respektive siebten Buszyklus beim anschließenden Kaltstartknoten)kommunikationsbereit ist, so ergibt sich ein weiterer Unterschied beim Kommunikati-onsbeginn von zwei Buszyklen.

Zeitliche Einflüsse

Folgende Zeitannahmen wirken sich verzögernd bei der Etablierung der Buskommuni-kation innerhalb der StartUp-Prozedur aus:

• Die Verzögerungsausbreitung eines gesendeten Signals im Netzwerk,11Falls kein StartUp innerhalb des Zeitintervalls tStartUpNoise am Bus durchgeführt wird hat der Knoten

B erneut die Möglichkeit selbst die Rolle des führenden Kaltstarters einzunehmen. Dadurch wird vermie-den, dass ein potentiell korrupter Knoten A einen StartUp über Knoten B kontinuierlich verhindert.


• Der potentiell mögliche Drift innerhalb der knotenlokalen Uhren,

• Die Verarbeitungsdauer bei der Ausführung von Prozessschritten im Knoten,

• Die Bereitstellungsdauer einer ausreichenden Spannungsversorgung auf demNetzwerkkanal/Knoten.

3.3.3.3. Uhrensynchronisation

Bei der Uhrensynchronisation /[Ung07]/ werden die Abweichungen der Uhren inner-halb ihrer Präzision zurückgesetzt (Offset-Korrektur) Zusätzlich wird der Startzeitpunktdes Zyklus (Ti(z)) für jeden Knoten korrigiert. Gleichzeitig wird die Taktrate τ zur Ge-nerierung der Makroticks für die Uhr eines jeden Clusterknotens neu justiert, um denPräzisionsfehler zu korrigieren (Rate-Korrektur). Entsprechend lässt sich die lokale ZeitTi eines nicht korrigierten Knotens i zum Zeitpunkt t durch

Ti(t) = τ ∗ t + Ti(0)

ausdrücken. Der Offset-Fehler entsteht durch die Akkumulation maximaler Fehler imBereich der Quantisierung, der Mikrotickverteilung, bei Rundungsfehlern und durch dieTopologie. Der Rate-Fehler, der nur alle zwei Zyklen neu berechnet wird, resultiert durchzweimalige Quantisierung, Rundungsfehler und die Ratendämpfung.

εO f f set = ΔεQuant + ΔεDist + ΔεDiv + ΔεTopεRate = 2 ∗ ΔεQuant + ΔεDiv + ΔεDamp

Genauigkeitsgrenzen

In einem FlexRay-Cluster finden sich konzeptbedingt Ungenauigkeiten, die als Fehlerim Systementwurf zu berücksichtigen sind. Diese Einflüsse resultieren aus Effekten derBusphysik und der implementierten Berechnungsterme zur Synchronisation des Netz-werks. Demzufolge korrelieren die anfolgend aufgeführten Aspekte mit der Bestim-mung der im Cluster vorhandenden Präzision /[Ung07]/.

Quantisierungsfehler: Das Versenden einer Botschaft im FlexRay-Netzwerk basiert zeit-lich auf der Mikrotickkante des sendenden Kommunikationscontrollers. Auf derEmpfängerseite wird dabei die erste Kante des Mikrotickintervalls als Empfangs-zeitpunkt akzeptiert, in dem die Botschaft detektiert wurde. Im ungünstigsten Fallfällt der Botschaftsempfang exakt auf eine Mikrotickkante, wodurch der zu dieserZeit inkrementierte Mikrotickzählerwert als gültig angenommen wird. Dadurchkann es zu einem Diskretisierungsfehler von bis zu einem Mikrotick pro Zykluskommen (errQuant < 1μT/Cycle) (s. Abb. 3.13).

Mikrotickverteilungsfehler: Der Makrotickgenerierungsprozess (MTG) des Kommuni-kationscontrollers basiert auf einem Algorithmus, der die Anzahl der Mikrotickspro Zyklus auf die Anzahl der Makroticks verteilt. Besonders im Fall der Raten-korrektur ist es jedoch nicht immer möglich, eine einheitliche diskrete Anzahlan Mikroticks auf die fixe Anzahl an Makroticks im Zyklus gleichmäßig zu ver-teilen. Dadurch entstehen in jedem FlexRay-Kommunikationscontroller eine eige-ne Anordnung von geringfügig unterschiedlich langen Makroticks im Vergleich


MTMTMT MTMTMT MTMT

MTMT MTMT MT MTMT

Frame k

Quantisierungsfehler

Slot x in Sendeknoten A

Slot x in Empfangsknoten B

Frame k

Frame kAusbreitungsverzögerung

(a) Diskretisierungsfehler gegenüber dem Sender beider Detektion einer empfangenen Botschaft auf Mi-krotickebene.

kμTs

k+1μTs

kμTs

kμTs

k+1μTs

k+1μTs

k+1μTs

kμTs

kμTs

kμTs

k+1μTs

kμTs

k+1μTs

k+1μTs

k+1μTs

kμTs

kμTs

kμTs

Slot 1 Slot x

Slot 1 Slot x Microtickverteilungsfehler

Zyklus m

Zyklus n

(b) Mikrotickverteilungsfehler auf Zyklu-sebene

Abbildung 3.13.: Quantisierungsfehler und Mikrotickverteilungsfehler in einem Cluster

zur nominellen uniformen Makrotickgröße. Durch die Abstraktion von diesemVerteilungsprozess in den Berechnungstermen der FlexRay-Uhrensynchronisationkommt es systemweit zu einer zusätzlichen Uhrenabweichung in den Knoten. EineUngenauigkeit zu den Berechnungsformeln kann mit errDist < 1μT/Cycle abge-schätzt werden (s. Abb. 3.13).

Topologiefehler: Die Verteilung von Botschaften im Netzwerk führt zu einer zeitlichenVerzögerung, die je nach physikalischem Abstand zweier Kommunikationskno-ten variiert. Je präziser die minimale Verzögerung zwischen zwei Steuergerätenspezifiziert wird, desto besser kann diese Ungenauigkeit über einen Kompensati-onswert in den Berechnungstermen ausgeglichen werden. (pdDelayCompensationgdPropagationDelayMin).

Rundungsfehler: Durch die Ganzzahlarithmetik bei der Berechnung der Ratenkorrek-tur im Kommunikationscontroller werden Ganzzahldivisionen mit einem Run-dungsfehler behaftet, der einheitlich mit errDiv < |0.5μT| taxiert wird.

Driftdämpfungsfehler: Während wiederkehrende Offsetverschiebungen im Netzwerküber den Kompensationswert pdDelayCompensation ausgeglichen werden, stellenwiederkehrende Ratenverschiebungen ein Risiko dar. Durch eine permanente Kor-rektur der Zykluslänge in die gleiche Richtung kann ein beliebiger Clusterdrift (ge-gen Null oder gegen Unendlich) entstehen. Diesem akkumulierenden Effekt wirdentsprechend mit einem Dämpfungswert entgegengewirkt, der die Ratenkorrek-tur bei geringer Abweichung im Knoten unterdrückt. Diese Dämpfung führt al-lerdings zu einem zusätzlichen Fehler in der Ratenkorrektur, der direkt Einflussauf die Gesamtpräzision des Clusters nimmt (errDamp < |pDelayCompensation ∗μTLengthMax|).

3.3.4. Systemparametrierung

Bei der Systemparametrierung interessieren die allgemeinen Aspekte der Konfigurationder physikalischen Bitübertragungsschicht sowie des Netzwerkprotokolls. Diese lassensich bis auf detaillierte Justierungen im Bereich jedes einzelnen Netzwerkteilnehmers


in Form von knotenlokalen Parametern verfeineren. Die nachfolgende Auflistung spie-gelt dabei die wesentlichen Bereiche der Konfiguration zeitgesteuerter Kommunikationwieder.

3.3.4.1. Konfiguration der elektrischen Bitübertragungsschicht

Grundlegende Parameter des elektrischen Physical Layers gilt es vorab zu ermitteln.

Baudrate: Die Baudrate beschreibt die Schrittgeschwindigkeit bei der Datenübertra-gung /[Trö05]/. Durch die Festlegung der Baudrate wird die auf dem Netzwerk verfüg-bare Bandbreite bestimmt, welche die Performanz des Bussystems beeinflusst.

Controllerfrequenz: Ein auf einem Knoten verbauter FlexRay-Kommunikationscontrol-ler wird mit einer hardwareabhängigen Taktfrequenz betrieben. Taktfrequenzen im Be-reich von 20-80Mhz decken das aktuell spezifizierte Einsatzspektrum ab.

Maximale Ausbreitungsverzögerungen: Die Identifikation der im Netzwerk entstehen-den physikalischen Ausbreitungsverzögerung bei der Signalübertragung stellt einenwichtigen Faktor zur Ableitung potentieller Topologievarianten dar.

Minimale Ausbreitungsverzögerungen: Die Ermittlung minimaler Ausbreitungsverzö-gerungen zeigt sich relevant um den Wertebereich der Ausbreitungsverzögerung unddamit unnötige Verluste in der Protokollperformanz zu vermindern.

Bustreiber: Der Signalwechsel am elektrischen Bustreiber zwischen Busruhe und Bus-aktivität und vice versa generiert ein zusätzlichen Zeitbedarf bei der Signalübertragung(dBDRxia).

Aktive Sterne: Die Signalspiegelung zur Verteilung innerhalb einer sternförmigen Topo-logie führt zu einer Signalverkürzung an den Ein- und Ausgängen beim Übertragungs-aufbau im Netzwerk zwischen zwei Teilnehmern (dStarTruncation, nStarPathM,N). Dabeimuss der physikalische Aufbau (diskret, monolithisch) des aktiven Sterns berücksichtigtbleiben.

Uhrengenauigkeit: Obwohl nach /[Fle05a]/ die Qualität der Uhrengenauigkeit mit ei-nem konstanten Wert definiert worden ist, kann der Einsatz hochwertigerer Quarze zueiner besseren Protokollperformanz führen. Daher sollte die Substitution dieses kon-stanten Faktors berücksichtigt bleiben (cClockDeviationMax, gdTSSTransmitter).

Netzwerkteilnehmer: Da die Anzahl der im Netzwerk verbauten Knoten einen Effektauf die Qualität des vorliegenden Netzwerksignals haben, darf der Einfluss eines zuge-fügten Knoten nicht unberücksichtigt bleiben.

3.3.4.2. Konfiguration des Netzwerkprotokolls

Die Parameter auf Netzwerkebene hängen bereits indirekt mit den Anforderungen derauf dem Bussystem abzubildenden Anwendungsfunktionen ab.


Anzahl der Sendeknoten: Durch die Festlegung der Menge an sendeberechtigten Netz-werkknoten ergeben sich Grenzwerte für die Anzahl einzuplanender Sendeslots im Bus-schedule.

Anteil statischer/dynamischer Kommunikation: In Abhängigkeit zur Quantität der Si-gnale eines vorhandenen Kommunikationstyps wird die Aufteilung des statischen unddynamischen Segments im Busszyklus bestimmt.

Aufstartverhalten: Die Anzahl der authorisierten Netzwerkknoten zur Ausführung vonWeck- und Startversuchen sowie die möglichen Wiederholversuche im Fehlerfall werdenclusterweit festgelegt.

3.3.4.3. Knotenparametrierung

Ergänzend zur Konfiguration der physikalischen Bitübertragungs- und der Protokoll-schicht ergibt sich die Festlegung einiger knotenlokaler Parameter, die anfolgend aufge-listet werden.

Kanalzuweisung: Jeder Knoten wird individuell einem oder beiden Kanälen auf demFlexRay-Segment zugeordnet.

Startvorgang/Synchronisation: Die Lokalisation der Start-/Synchronisationsbotschafteines Knotens im Schedule ist festzulegen12.

Weckeigenschaften: Die Zuordnung einer Weckfähigkeit eines Knotens in Bezug aufden FlexRay-Kanal und die zeitliche Ausprägung des WUP lässt sich spezifizieren.

Sendeverhalten im dynamischen Segment: Die maximal gültigen Botschaftslängen undder dazu korrespondierende spätest tolerierbare Sendezeitpunkt im dynamischen Seg-ment sind knotenabhängig festzulegen.

Uhrenkorrektur: Eingriffe in die Uhrenkorrekur sind durch Adaption des Driftdämp-fungsfaktors oder extern über die Schnittstelle zum Host-Prozessors pro Knoten mög-lich.

Fehlertoleranz: Einstellung des Knotenverhaltens im Fall von Synchronisationsfehlernund Wechsel in einen passiven oder inaktiven Zustand.

Integrationsfähigkeit: Festlegung von tolerierbaren Abweichungen in der Genauigkeitbei der Uhrensynchronisation im Sinne einer Knotenintegration in ein synchrones odersich synchronisierendes Cluster.

12In diesem Bereich könnte auch der Singleslot-Modus eingeordnet werden, um die Kommunikation aufdem Bus in kritischen Phasen, wie etwa beim Startvorgang, auf einen Slot pro Knoten zu begrenzen.

KAPITEL 4

Methodik

Einleitend werden in diesem Kapitel sämtliche FlexRay-spezifischen Anforderungen zusammengefasst,die bei der Definition der E/E-Entwicklungsmethodik zu berücksichtigen sind. Darauf aufbauend wird dasKonzept der entwickelten Methode FlexZOOMED zum eindeutigen Verständnis formal spezifiziert. Wei-terhin wird der Bezug zwischen der FlexRay-Parametrierung und der abstrakten E/E-Metamodellierunghergestellt. Anschließend wird die Umsetzung der E/E-Entwicklungsmethodik auf domänenspezifischeModelle erläutert und die umfassende Integration von Entwicklungsaspekten für flexible zeitgesteuer-te Architekturen beschrieben. Als Ergänzung dient der letzte Abschnitt, der sich in dem Kontext derentwickelten Methodik mit der Formulierung und technischen Lösung von identifizierten Optimierungs-problemen auseinandersetzt.

Mit dem Wechsel von der CAN- /[Rob91]/ auf die FlexRay-Technologie /[Fle05b],[Rau07a]/ in Fahrzeugsegmenten mit hohem Kommunikationsbedarf zwischen denSteuergeräten, vollzieht sich ein Wandel in der Entwicklungssystematik eines Fahr-zeugherstellers in Bezug auf die Weiterentwicklung seiner E/E-Architekturen. Um dieleistungsfähigen Potentiale von FlexRay auszuschöpfen, müssen neuartige Entwurfs-prinzipien beachtet werden, welche auf die Eigenschaften eines zeitgesteuerten Bus-systems zurückgeführt werden können /[Kop97], [SBV+02]/. Speziell die starke Ver-lagerung von Aufgaben innerhalb des Entwicklungsprozesses in die Anforderungs-analyse und Designphase ist dabei zu berücksichtigen /[MB97]/. Der FlexZOOMED-Ansatz setzt diese Prämissen durch eine modellbasierte Beschreibung und Analyseder FlexRay-Systemspezifikation auf der E/E-Architekturebene um. Sämtliche Inhaltedieses Kapitels bilden eine Grundlage für die konzeptionelle Umsetzung der FlexZO-OMED-Entwicklungsmethodik.

118

4.1. ÜBERSICHT 119

4.1. Übersicht

Bei der Definition einer gültigen FlexRay-Systemspezifikation eröffnet sich für den Fahr-zeughersteller eine Reihe an technischen Fragestellungen, deren Antworten sich unteranderem durch gezielte E/E-Architekturentscheidungen ergeben. Der FlexZOOMED-Ansatz fokussiert auf diese Aspekte, indem der FlexRay-Systementwurf auf die Archi-tekturebene verlagert wird. Zum Verständnis der Abhängigkeiten zwischen der Ver-netzung und der Architekturentwicklung werden diese beiden Sichten in Bezug aufdie FlexRay-Systementwicklung konkretisiert. Der folgende Abschnitt ist inhaltlich an/[BR07]/ angelehnt.

4.1.1. Anforderungen an die FlexRay-Systementwicklung

Die Entwicklung der vernetzten E/E-Systemarchitektur eines Fahrzeugs erfolgt in ei-nem bilateralen Prozess zur Abdeckung aller funktionaler/nichtfunktionaler Anforde-rungen aus Architektur- sowie aus Vernetzungssicht /[BMG07]/.

Architektursicht

Zum Entwurf und Integration eines FlexRay-Busses innerhalb einer E/E-Systemarchi-tektur müssen allgemeine Anforderungen eingehalten werden, um die Gesamtqualitäteines Fahrzeugs über seinen Lebenszyklus gewährleisten zu können. Für einen trans-parenten Integrationsprozess eines FlexRay-Systems aus Architektursicht gilt es daherdie wechselseitigen Abhängigkeiten zwischen den allgemeinen architekturellen Anfor-derungen und dem konkreten Netzwerkdesign zu beherrschen (s. Abb. 4.1).

EE-Systemanforderungen FlexRay-Systemspezifikation

ZeitverhaltenIntegrationsspielraum

Energie-/SystemmanagementPlattform- und Variantenkonzept

Diagnose-/KomponentenmanagmentTopologien

KomponentenarchitekturSystemverlässlichkeit

Elektromagnetische Verträglichkeit...

FlexRay-Schedule-Struktur

FlexRay-Kommunikationsbeziehungen

Globale FlexRay-Clusterparameter▪ Protokollrelevant▪ Protokollbezogen▪ Physical Layer-relevant

FlexRay-Knotenparameter▪ Protokollrelevant▪ Protokollbezogen▪ Physical Layer-relevant

FlexRay-Systemspezifikation

FlexRay-y Schedule-Struktur

...▪ P▪ P▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪ PPPPPPPPPP

Anforderungen aus der Applikation

Abbildung 4.1.: Wechselseitige Abhängigkeiten der Architektur- und der Netzwerkentwicklung

Bei der Integration von Steuergeräten sind in einer existierenden flexiblen zeitge-steuerten Umgebung die Eigenschaften einer FlexRay-Systemkonfiguration in Bezug aufArchitekturdesignentscheidungen zu plausibilisieren. Die folgenden Klassifikationskri-terien beeinflussen die FlexRay-Systemkonfiguration:

Zeitverhalten (Performanz): Die Applikation des flexiblen dynamischen Segments im

120 KAPITEL 4. METHODIK

FlexRay-Kommunikationszyklus bewirkt eine periodische Unterbrechung der determi-nistisch erfassbaren Datenkommunikation innerhalb des statischen Segments. Die füreine synchrone Sensordatenerfassung und -auswertung relevanten vernetzten Systemebestimmen dabei die Größen für Gesamtzykluslänge und Zyklussegmentierung.

Systemerweiterung/-integration: Eine Reservierung von FlexRay-Slots wird notwendig,um das Netzwerk für eine spätere Systemmodifikation oder -integration flexibel zu hal-ten. Multiplexing-Techniken ermöglichen dabei eine effizientere Vergabe der Bandbreiteauf Kosten einer erhöhten Systemkomplexität.

Systemmanagement: Zur Gewährleistung der Netzwerkverfügbarkeit und Optimie-rung des Energieverbrauchs müssen geeignete Coldstart- und Sync-Steuergeräte (nodes)definiert werden, welche eine korrekte Funktionsweise eines FlexRay-Netzwerks (clus-ter) auch in unterschiedlichen Varianten je nach Ausstattungswunsch ermöglichen. Einegeeignete Anzahl an Weck- und Startversuchen zur Behandlung von Fehlerszenarien istzu identifizieren.

Plattform- und Variantenbildung: Die Slots eines Kommunikationszyklus können jenach Anwendung als plattform- oder modellspezifisch ausgelegt werden. Dies beein-flusst die Freiheiten für das Scheduling von Applikationsprozessen auf den verschiede-nen Netzwerkteilnehmern (Knoten).

Quality of service: Für eine performante, effiziente Steuergeräteprogrammierung kön-nen große Botschaften mit einem hohen Nutzdatenanteil implementiert werden, welcheszu einer starken Belastung der verfügbaren Netzwerkbandbreite führen kann. Um dasNetzwerk nicht statisch mit Botschaften zu belegen, welche nur in speziellen Situatio-nen gebraucht werden, eignet sich das dynamische FlexRay-Segment. Analog zu CAN-basierten Netzwerken können dabei allerdings Lastzustände (burst effects) auftreten, diees zu beherrschen gilt.

Topologien: Da sich die physikalische Netzwerktopologie entscheidend auf die System-präzision durch Verzögerungseffekte bei der Signalausbreitung auswirkt, gilt es die Ein-führung neuer Netzwerkknoten bereits zur Systemdesignphase zu analysieren.

Komponenten: Jede Hard-/Software-Komponente eines FlexRay-Systems, beispielswei-se der Kommunikationscontroller bedingt zusätzliche individuelle Restriktionen bezüg-lich der Verwendung in einem Cluster. Beispiele sind unterschiedliche Puffereigenschaf-ten oder Speicherschnittstellen.

Systemverlässlichkeit: Schließlich sind Alterungseffekte innerhalb eines zeitgesteuertenSystems mit verteilter Echtzeit zu beachten, um eine sichere Systemoperation bei langerEinsatzdauer zu garantieren. Leichtes Abweichen der Oszillatorgenauigkeit kann hier-bei kritisch werden.

Netzwerksicht

In der Analyse- und Designphase eines FlexRay-Systems müssen folgende Hauptaufga-ben gelöst werden, um ein vollständig und funktional korrekt spezifiziertes Netzwerk

4.1. ÜBERSICHT 121

zu erhalten (s. Abb. 4.2, /[Bro07]/):

Physikalische Protokollkonfiguration

Sender-/Empfängerbeziehungen auf Signalbasis zwischen Knoteng

Framepacking von Sende-/Empfangssignalen/E///// mppppfanggggssigggnalen

Intra- und Interprozessor-kommunikationInterprozessor-kokkokokokokokkokkkkookokokokoommmmmmmmmmmmmmmmmmmmmmununununu ikikkikkkkikkatatatatatatatttttiiiiioioioioioioiooooooii nnnnnnnnnnnnCluster- und

Knotenparameter

Netzwerktopologien

FlexRay-Kommunikationsbeziehungen

Botschaftsdefinition

Task-Mapping und Scheduling

FlexRay-Parameterkonfiguration

Abbildung 4.2.: Netzwerkintegrationsvorgehen zur Definition einer FlexRay-Architektur

Netzwerktopologien: Die Wahl der FlexRay-Systemtopologie trägt entscheidend zu ei-ner späteren Protokollkonfiguration bei, da sich die Distanz der Punkt-zu-Punkt-Kom-munikation auf die Präzision eines Netzwerks auswirkt.

FlexRay-Kommunikationsbeziehungen: Um einen FlexRay-Schedule entwerfen zu kön-nen, müssen vorab die Sender-/Empfängerbeziehungen auf Basis von Signalkommuni-kation zwischen den vernetzenden Knoten definiert werden.

Botschaftsdefinition: Anhand der identifizierten Sende-/Empfangssignale werden Bot-schaften definiert. Ziel ist eine möglichst geringe Gesamtanzahl an Botschaften. DieseAnforderung wird in der Regel über Heuristiken gelöst /[SN03]/.

Task-Mapping und Scheduling: Für eine korrekte Intra- und Interprozessorkommuni-kation wird eine holistische Scheduling-Analyse zur zeitlichen Planung von Prozessen(tasks) benötigt /[PEPP06]/. Dabei gilt es zu beachten, dass für den Botschaftsversand/-empfang Sende- und Empfangsprozesse definiert werden müssen und als Stützstellenentlang des Kommunikationszyklus angeordnet werden. Dabei kann die Struktur desBusschedules abgeleitet werden.

FlexRay-Parameterkonfiguration: Die Herausforderung im FlexRay-Designprozess kor-reliert mit einer komplexen Konfiguration einer großen Anzahl an Netzwerkparameter(>80). Diese definieren die Eigenschaften des Protokolls hinsichtlich seiner komplettenAusprägung. Dazu zählen zusammengefasst folgende Eigenschaften:

• Physikalische Signaldarstellung auf dem Kommunikationsmedium,

• Zeitabhängiger Kommunikationsplan des Busses,

• Weck-, Start- und Aktivitätsverhalten,


• Fehlerkontrolle und -behebung,

• Verteilte globale Synchronisation,

In Abb. 4.3 werden sämtliche relevante Parameter (keine Konstanten/Hilfsparameter)des FlexRay-Kommunikationssystems abgebildet.

gdMaxMicrotick

gdMaxInitializationError

pClusterDriftDamping

gClusterDriftDamping

aWorstCasePrecision

gAssumedPrecision

pdBDTx

gdMaxPropagationDelayCH

LineLength

T0

pdStarDelay

pdBDRx

aFrameLengthDynamic

pLatestTx

vDTSLowMin

adOffsetCorrection

gOffsetCorrectionStart

gdNIT

adRemRateCalculation

adRemOffsetCalculation

adActionPointDifference

gMacroPerCycle

gNumberOfMinislots

nStarPath - Erklaerung,Wertebereich,Formel,Zustand,Link-to-EAA

gdTSSTransmitter

gdWakeupSymbolRxLow

dStarTruncation

dBDRxia

gdBitMax

gdStaticSlot

gdSymbolWindow

gdDynamicSlotIdlePhase

gdBit

gdWakeupSymbolTxIdle

gdWakeupSymbolTxLow

gdMinPropagationDelay

gdActionPointOffset

gdMinislotActionPointOffset

gOffsetCorrectionMax

pDelayCompensation

pMacroInitialOffset

pMicroInitialOffset

pMicroPerMacroNom

gPayloadLengthStatic

aFrameLengthStatic

gdMacrotick

pdMicrotick

pdAcceptedStartupRange

pOffsetCorrectionOut

pMicroPerCycle

gdCycle

gdBitMin

gdCASRxLowMax

dBDRxai

pSamplesPerMicrotick

pDecodingCorrection

gNumberOfStaticSlots

aBestCasePrecision

gdMinislot

gdMaxPropagationDelay

pExternOffsetCorrection

pdMaxDrift

pdListenTimeout

pRateCorrectionOut

pExternRateCorrection

gdWakeupSymbolRxIdle

gdWakeupSymbolRxWindow

Abbildung 4.3.: FlexRay-Parameterbaum mit farblicher Abgrenzung unidirektionaler Parameter(Startparameter)

Die Ergebnisse der vorhergehenden Schritte werden in einen gültigen FlexRay-Pa-rametersatz überführt. Dabei wird zwischen den globalen, auf Clusterebene gültigen,

4.1. ÜBERSICHT 123

und den lokalen Node-spezifischen Parametern unterschieden. Allgemeine Parameter,welche die grundlegenden Merkmale der Protokoll- und Physical Layer-Konfigurationcharakterisieren, werden als High-Level-Parameter zusammengefasst betrachtet (bspw.Baudrate, Datenlänge, Präzision, Verzögerungswerte, Signalverkürzung, Sternanzahl,Makro-/Mikrotick, ...). Aus den allgemeinen Parametern werden Protokoll- und Physi-cal-Layer-spezifische Parameter abgeleitet, um die Funktionsweise der grundlegendenProtokollmechanismen gegenüber einer konkreten Vernetzungstopologie zu verifizie-ren.

4.1.2. Systemintegration von FlexRay-Architekturen

Um mit einer flexiblen zeitgesteuerten Technologie wie FlexRay eine langfristige Pro-duktqualität zu gewährleisten, müssen die Eigenschaften einer Systemkonfiguration in-terpretiert und die Auswirkungen notwendiger Modifikationen verstanden werden.

FlexRay-Designparadigmen

Die Komplexität der Transformation eines FlexRay-Konzepts A in ein alternatives Kon-zept B wird anhand des Beispiels zweier Kommunikationszyklen mit unterschiedlicherZykluslänge dargestellt (s. Abb. 4.4).

Protokoll:

FlexRay-Zyklus A (5 ms)

t t

Statische Botschaft 1:




Dynamische Botschaft 1:

Leere FlexRay-Zelle:




Zyklusstart Zyklusstart

Statisches Segment Dynamisches Segment


Reserveplatz innerhalb eines FlexRay-Frames:

FlexRay-Zyklus B (10 ms)

tDynamisches ssssssssssss

SegmentStatisches Ss SSSSSS SSSSSSSSSSSSSSSegmegmegmegmegmegmegmegmegmegmegmegmegmegmegmegmegmegmegmegmmegmmegmmeeegg entententtentententenentententenennteentttenenttententenene

Abbildung 4.4.: Gegenüberstellung unterschiedlicher FlexRay-Paradigmen anhand des Buszu-griffsverfahren

Obwohl beide Ansätze optisch sehr unterschiedlich wirken, erzeugen sie ein nahezuidentisches Kommunikationsverhalten.

Performanz: Um in Zyklus B die gleichen Abtastraten wie in Zyklus A zu ermöglichen,muss die statische Botschaft 1 konsequenterweise innerhalb des Zyklus B mehrfach wie-derholt verschickt werden, was zu einer zusätzlicher Auslastung statischer Bandbreite


führt. Um die statische Botschaft 2 in den richtigen Zyklen zu senden, muss die Bot-schaft dekomponiert und einzelne Signale an den richtigen Lücken der restlichen Slotsplatziert werden, was eventuell eine Anpassung der Sende-/Empfangsbeziehungen inZyklus B benötigt.

Systemerweiterung/-integration: Weitere Systeme werden in beiden Ansätzen unter-schiedlich integriert. Während in Zyklus A auf leere Zellen oder komplett reservierteSlots zurückgegriffen wird, so ergibt sich in Zyklus B die Möglichkeit die noch leerenStellen in den einzelnen Botschaften zu belegen. Im Gegensatz zu den leeren Slots in Zy-klus A müssen allerdings in Zyklus B beim Auffüllen von Botschaften die identischenSender-/Empfängerbeziehungen übernommen werden.

Plattform- und Variantenbildung: Für eine Plattform- und Variantenbildung eignet sicheher die Vergabe einzelner FlexRay-Zellen/-Slots wie in Zyklus A, um ein kompliziertesAufsplitten von Botschaften (statische Botschaft 2) zu vermeiden.

Quality of service: Wie im dynamischen Segment für jeden Bus-Schedule ersichtlich,liegt es an dem Netzwerkdesigner, die zeitlichen Limits für die parallele Steuergeräte-programmierung einzuhalten. Durch den längeren Zyklus B wird der Einsatz parallelerTransportkanäle innerhalb eines Buszyklus notwendig, um den gleichen Datendurch-satz wie in Zyklus A zu erzielen. Je nach Leistungsfähigkeit des Empfangssteuergerätskann die Nutzdatenlänge einer dynamischen Botschaft und deren Zykluswiederholratebeliebig skaliert werden.

Systemverlässlichkeit: Da die doppelte Zykluslänge B auch einen größeren Spielraumfür Clusterdrifts zulässt, müssen alle Aspekte, die der Uhrensynchronisation zugerech-net werden können (rate-, offset-correction), entsprechend der Systempräzision und damitan verfügbare Oszillatorqualitäten im Netzwerk angepasst werden.

Physical Layer:

Für eine FlexRay-Systemintegration/-erweiterung muss offensichtlich das Layout derNetzwerktopologie adaptiert werden. Im Folgenden wird eine Erweiterung der Netz-werktopologie A mit 4 Knoten und einem Sternkoppler auf 6 Knoten und zwei Stern-kopplern dargestellt.

Topologien: Durch die Einführung eines Node E verlängert sich der Maximalabstandzwischen Knoten und Stern auf dem Sternast sowie die maximale Distanz einer Punkt-zu-Punkt-Verbindung im Cluster (Node E zu Node F). Die zusätzliche Verzögerung übereinen zweiten eingeführten aktiven Sternkoppler muss im Wertebereich der FlexRay-Parametrierung abgesichert werden.

Komponenten: Eventuelle Vorgaben des FlexRay-Kommunikationscontrollers, beispiels-weise in der Puffer-Verwendung, müssen berücksichtigt bleiben. Falls die Knoten abwei-chende FlexRay-Hard-/Softwaremodule oder -varianten /[AUT07a]/ besitzen, werdenInteroperabilitätsuntersuchungen erforderlich.

Systemmanagement: Durch eine Funktionsanalyse werden kritische Situationen identi-

4.1. ÜBERSICHT 125

Ausbreitungsverzögerung, Interoperabilität, Aufstartverhalten

Rekonfiguration als Coldstart-Nodes, Sync-Nodes

Node B Node CNode A

Node D

Node B Node CNode E

Node FNode D

Node A

Topologie A (4 Knoten, 1 aktiver Sternkoppler) Topologie B (6 Knoten, 2 aktive Sternkoppler)

Stern 1 Stern 1 Stern 2

Abbildung 4.5.: Beispiel für eine mögliche Systemerweiterung eines 4 Knoten-FlexRay-Systemsauf ein 6 Knoten-FlexRay-System mit zusätzlichem Sternkoppler

fiziert, in denen die integrierten Nodes E und F ein aktives Cluster zur Kommunikationbenötigen. Dadurch kann entschieden werden, ob die hinzukommenden Knoten kalt-startfähig ausgelegt werden müssen. Reduziert man die Topologie B auf Topologie A,so wird eine Überprüfung und eventuelle Hinzunahme von Sync-Knoten zur Sicherungeines funktionsfähigen FlexRay-Systems notwendig.

4.1.3. Integrationsvorgehen und Optimierungspotentiale

Um die beispielhaft vorgestellten Aufgaben der Modifikation eines FlexRay-Systems ausSicht der FlexRay-Konfiguration zu beherrschen, muss der Eingriff in einen FlexRay-Parametersatz verstanden sein. Dies wird am Beispiel der drei FlexRay-Parameter mitden höchsten Abhängigkeitsgraden im FlexRay-Parametergraph (vgl. Abb. 4.3) exem-plarisch erläutert:

Makrotick: Eine Analyse der Parameterverknüpfungen über einen Abhängigkeitsgra-phen zeigt, dass der Makrotick als die nominale Einheit für einen clusterweit einheitli-chen zeitlichen Schritt mit bis zu dreizehn weiteren Parametern korreliert, die wesentlichzu der Struktur des FlexRay-Schedules beitragen. Die Signifikanz des Makroticks lässtsich auch daraus ableiten, dass die verfügbare Slotanzahl in den jeweiligen Segmentenauf Basis der pro Zyklus existierenden Anzahl von Makroticks errechnet wird.

Präzision: Eine Veränderung der Vernetzungstopologie führt in der Regel zu verän-derten Verzögerungswerte des Kabelbaums. Dabei wird auch die Gesamtpräzision desClusters tangiert, da sich der Initialisierungsfehler eines einzelnen Knotens bei der Inte-gration in ein aktives FlexRay-System verstärken kann, was die Wahrscheinlichkeit fürinstabile Netzwerkhochläufe erhöht.

Statische Slotlänge: Eine Umstellung der Nutzdatenlänge für statische FlexRay-Bot-


schaften in langfristigen Projekten sollte vermieden werden, da eine Modifikation indiesem Bereich zu einer Neuberechnung der statischen Slotlänge führen würde. Ein sta-tischer Slot hängt mit acht weiteren Parametern zusammen und seine Größe bestimmtlogischerweise die Slotanzahl im statischen Segment. Folglich läuft ein Eingriff an dieserStelle auf ein komplettes Redesign hinaus.

Konsequenterweise stellt das FlexRay-Systemdesign aus Konfigurationssicht eine klas-sische Mehrzieloptimierungsaufgabe dar. Folgende Ziele gilt es dabei zu beachten:

• Nutzdateneffizienz (möglicher Datendurchsatz pro Bandbreite),

• Systempräzision hinsichtlich serienrelevanter Topologien,

• Segmentgrößen (Systemperformanz für jeweilige Applikationen),

• Slotgrößen (Bestmögliche Skalierbarkeit),

• Slotvergabe (Zielabtastraten und Verlust von statischer Bandbreite).

4.1.4. Folgerung

Wie in den vorhergehenden Abschnitten dargestellt, ist es aus Anwendersicht essen-tiell die FlexRay-Systemintegration hinsichtlich allgemeiner Fragestellungen im Archi-tekturdesign zu beherrschen. Dabei zeigt es sich entscheidend die Anforderungen ausder allgemeinen E/E-Systemarchitekturentwicklung zu präzisieren und ihren Zusam-menhang zu einer FlexRay-Systementwicklung herauszuarbeiten. So implizieren einfa-che Modifikationen des Protokollzugriffs der Sicherungsschicht oder Adaptionen derVernetzungstopologie auf der Bitübertragungsschicht bereits komplexe Migrationsent-wicklungsschritte. Daher sollte der Designansatz langfristig als Meet-In-The-Middle-Strategie erfolgen, um das komplexe Bottom-Up-Design der FlexRay-Parameter zu ver-einfachen.

Ein Wechsel zu einer standardisierten Parameterkonfiguration vereinfacht die Sys-temintegration signifikant, da die Anzahl potentiell notwendiger Anpassungen redu-ziert wird. Eine weitere Vereinfachung versprechen standardisierte Netzwerktopologienund Verkabelungsgrößen, die den Lösungsraum für FlexRay-Systeme einschränken. All-gemein führen proprietäre Modifikationen in der Regel zu aufwändigen und komple-xen Entwicklungsaufwänden, welche den Spielraum zur Erweiterung eines konzipiertenFlexRay-Systems beschränken.

Wie gezeigt, zeichnet sich der FlexRay-Standard durch die präzise Umsetzung her-stellerspezifischer Designvorgaben aus. Diese Eigenschaft fordert im Gegenzug aberein wesentlich tieferes Systemverständnis im Vergleich zu den Erfahrungen mit derCAN-Technologie. Um die Akzeptanz des Standards weiter zu verbessern ist eine Ver-einfachung der Applikation der Technologie erforderlich, um den Aufwand für kom-plexe und damit test- und kostenintensive Aufgaben im Zusammenhang mit Parame-trierungseinstellungen zu reduzieren. Grundsätzlich gilt es die Methoden der Anfor-derungs- und Systementwurfsphase in Hinblick auf die spezifischen Eigenschaften derneuen FlexRay-Technologie weiterzuentwickeln, um deren Beherrschbarkeit und um-fassende Nutzung zu garantieren. Entsprechende Konzepte werden im folgenden Ab-schnitt vorgestellt.

4.2. FORMALE SYSTEMMODELLIERUNG UND -SPEZIFIKATION 127

4.2. Formale Systemmodellierung und -spezifikation

„System analysis is frustrating, full of complex interpersonal relationships, indefinite anddifficult. In a word, it is fascinating. Once your hooked, the old easy pleasures of system

building are never again enough to satisfy you.“ - Tom DeMarco

Die Idee der modellgetriebenen Entwicklung /[Sta73]/ hat sich allgemein als rechnerge-stützte Entwurfsmethodik für komplexe verteilte Systeme etabliert. Die Sinnhaftigkeitder modellbasierten Spezifikation ergibt sich dabei aus der Möglichkeit der Formali-sierung grundlegender Aspekte im Systementwurf /[Boo91]/, dem damit entwickeltenVerständnis für die Systemzusammenhänge und der weitergehenden Automatisierungvon Entwurfsschritten.

In der Domäne der E/E-Architekturentwicklung haben sich bisher die Bereiche An-forderungsmodellierung, logische Systemarchitektur, technische Systemarchitektur, Partitionie-rung und Softwarearchitektur als signifikant herausgestellt (s. Abb. 4.15). Diese Dekompo-sition ist industrieweit allgemein akzeptiert. Deren konkrete Spezifikation, Umsetzungund Anwendung gilt allerdings noch als Forschungsbereich.

Anforderungs-Level

Analyse-Level

Design-Level

Implementierungs-Level

Partitionierungs-Level

Anfo

rder

ungsm

odel

l

Logis

che

Arc

hitek

tur

Partitionierungsmodell

Tec

hnis

che

Arc

hit

ektu

r

AUTOSAR

Abbildung 4.6.: Abstraktionsstufen der modellbasierten Entwurfsmethode MOSES /[Kle06]/

Der in dieser Arbeit entwickelte modellgetriebene Ansatz (s. Abb. 4.7) orientiert sichan den Bereichen der logischen und technischen Systemarchitektur, wobei der Aspektder Partitionierung als inhärentes Teilgebiet betrachtet wird, welches keine expliziteModellierung erfordert. Softwarearchitektonische Einflüsse werden gleichermaßen nichtauf Basis einer formalen Modellierung berücksichtigt.

Die logische Systemarchitektur spaltet sich in dem Ansatz in die statischen Funktions-netz- und die dynamischen Verhaltensmodelle auf. Ergänzend zu den dynamischen Ver-haltensmodellen lassen sich die Interaktionsmodelle hinzufügen, die allerdings keinenSchwerpunkt in dieser Arbeit darstellen.


Abtastraten (Zeitverhalten),TT-/ET-Signale,Datentypisierung, Kommunikationsbeziehungen,Plattform-/Variantenmodellierung

StartUp-/Shutdown-VerhaltenFehlerverhalten(Verlässlichkeit)

Funktion 1

Funktion 1

Funktion N

Sensoren Aktoren

Default ConfigConfig Halt

WakeUp StartUp Normal Active Passive

Ready

Quelle GW Ziel

Statisches Funktionsnetz Dynamisches Systemverhalten

Interaktionsablauf

Modell Bustechnologie & HW- Parameter & Fixpunkte- Randbedingungen

Adaption als Gesamtsystem- Simulation- Auslegung- Verifikation

Bus-SchedulingKnoten-Scheduling

Diagnosekonzept, Kalibrierung, etc. SSW-Spezifika,

HW-Spezifika,Topologien

ECU

ECU

ECU

ECUECU

Coordinator

TTOS_Task(x)TTOS_Task(Compute_Sensors)

Idle_Task()

Satellite

TTOS_Task(Sensor_1)

Idle_Task()TTOS_Task(x)

FirstFrameFlowConrol

FlowConrol

FlowConrolConsecutiveFrame

FlowConrol

ConsecutiveFrame

FlowConrol

ConsecutiveFrame

FirstFrame

Abbildung 4.7.: Idee der integrierten modellbasierten Entwicklung zur statischen und dynami-schen Analyse eines zeitgesteuerten Systemdesigns

4.2.1. Modellierungsgrundlagen und Notation

Unter der Modellbildung versteht sich in der Informatik „... die Darstellung der unterdem Gesichtspunkt einer gegebenen Aufgabenstellung wesentlichen Strukturen, Zusammenhän-ge und Vorgänge eines Anwendungsgebiets.“ /[Bro98], [BS03]/. Eine Modellbeschreibungbasiert dabei auf formalen Mitteln in Form von Datenstrukturen, Programmiersprachen,Graphiken oder logischen Formeln. Je nach Anwendungsgebiet ergibt sich eine Differen-zierung zwischen Domänenmodellen, um etwa die Struktur einer Software zu erfassen(Architekturmodell), die Programmablauflogik eines Codes zu beschreiben (Datenflussmo-dell) oder den Aufbau von Daten, beispielsweise in einer Datenbank, zu spezifizieren(Datenmodell). In dieser Arbeit liegt der Fokus vorrangig auf der Architekturmodellie-rung. Für die Entwicklung eines Systemmodells innerhalb einer arbiträr verbundenenAnzahl an Modellierungsebenen gelten grundlegende Eigenschaften, die es zu beachtengilt:

Zeitkontinuität: Bei der Spezifikation zeitsensitiver Artefakte im Modell ist zu beachten,dass die physikalische Zeit als uniformer und essentieller Bestandteil einer jeden Spezi-fikation eines reaktiven Systems berücksichtigt bleiben muss /[Rom06]/. Eine zeitinte-grierende Betrachtung innerhalb einer strukturierten Modellierung gilt als komplex undist speziell bei der Anwendungssoftwareentwicklung signifikant. Bei der Systemmodel-lierung auf Architektursebene liegt der Fokus auf den zu definierenden feingranularenDiskretisierungsstufen der Zeit.

Modellabstraktion: Aus Entwicklersicht ist eine vollständige Systemmodellierung über


sämtliche Bereiche der Architekturentwicklung aufwandsbezogen unattraktiv und ausRechnersicht aufgrund beschränkter Ressourcen technisch limitiert. Daher sind geeig-nete Abstraktionsebenen des Modellierungsgrads innerhalb und zwischen den Archi-tekturdomänen zu identifizieren.

Notationssyntax

Tab. 4.1 gibt eine Übersicht zu den syntaktischen Elementen, die später bei der Beschrei-bung des modellgetriebenen Spezifikationsansatzes verwendet werden.

R = {S, C, FC, ...} MengensymboleV = {x, y, z, ...} IndividuenvariablenF = {Ge, π, p, ...} Funktionen∧,∨,¬, ... Aussagenlogische Junktoren∼,�, ... Relationen∪,∩, ... Mengenoperationen⊆,⊂, ... Mengenrelationen∃, ∀ Quantoren{...} , (...), :, ... Hilfssymbole

Tabelle 4.1.: Symbol- und Zeichenerklärung

4.2.2. Konzept der statischen Modellanalyse

Innerhalb der statischen Modellanalyse spielen dynamische Aspekte eines Systems, wiedessen Verhalten oder die Interaktion von Systemkomponenten, eine untergeordneteRolle. Falls dynamische Eigenschaften des Systems zur Komplementierung der stati-schen Modellanalyse essentiell hinzugerechnet werden müssen, so empfiehlt sich eineKombination der beiden Analysemethoden. Die Simulation physikalischer Netzwerk-eigenschaften erfordert beispielsweise Spezialwerkzeuge, deren Simulationsergebnissejedoch als Eingabevektoren in der statischen Modellanalyse einen Mehrwert generieren.Die Einbettung der dynamischen Modelloptimierung wird für diesen Zweck exempla-risch in der Arbeit behandelt (s. Kap. 5).

4.2.2.1. Entwurfsprinzipien

Zur Verbesserung der Leistungsfähigkeit eines Modellierungskonzepts ist es zweckmä-ßig dessen Methodik auf allgemeine Anforderungskriterien der Softwareentwicklung/[EEE98], [EE84]/ anzupassen.

Modellstrukturierung: Um die hohe Komplexität der integrierten Architekturentwick-lung zu beherrschen ist es notwendig eigenständige Strukturierungskonventionen zudefinieren. Dazu zählen auch die Methoden der Generalisierung und Hierarchisierung,der Modularisierung und Modellverknüpfung (Partitionierung).

Modellvollständigkeit: Unvollständige Modellfragmente bergen Risiken in der Konzep-tion und Analyse von FlexRay-Architekturen. Daraus lässt sich die Notwendigkeit vonabgestuften Spezifikationsarbeitsständen ableiten, um iterativ ein Gesamtmodell entwi-ckeln zu können.


Modellbedatung: Die Modellbedatung erfolgt in einem mehrteiligen Prozess, indemModellattribute einer Abstraktionsstufe horizontal über das gesamte Architekturmodelladdiert werden. Dieser Prozessschritt lässt sich iterieren, um das gesamte Modell suk-zessiv auf die gewünschte Komplexitätsstufe zu verfeinern. Abstrakt lässt sich diesesVorgehen analog zu /[Bor94]/ formalisieren.

Das Prozessmodell zur iterativen Anwendung des entwickelten Konzepts stützt sich aufdie Idee ein System SYS unter gegebenen (nicht-)funktionalen Randbedingungen C(Konditionen) zu beschreiben. Das Prozessmodell wird dabei über die Summe aller Teil-prozesse inklusive deren vorliegender Randbedingungen definiert. Bei der Weiterent-wicklung mit mehreren Iterationsschritten verändert sich das Prozessmodell Pi =(SYSi, Ci) mit i Entwicklungsschritten. Dadurch lässt sich ein Transformationsschritt mauf einem Prozessmodell auch als Transformationsschritt auf dessen zugrunde gelegteSystemspezifikationen und Randbedingungen auffassen (m(P) = P′ mit P′ = (SYS′, C′).

Beispiel:

Ein Fahrwerk wechselt in den Modus „Sport“ bei Fahrzeuggeschwindigkeit v > 80km/h.Der Wechsel zwischen den Fahrwerksmodi erfolgt bei intakter Bereitstellung des Fahr-zeugniveaus in einem vorgegebenen Zeitfenster. Das vorliegende Fahrzeugniveau wirddabei aus der Menge Z aller eingehenden Höhenstandssensorwerte errechnet.

P = (kDaemp f er = kSky ∗vAu f bau

vRelativ, {v > 80, pos(Z), ∀z ∈ Z(Δt(z) < 100ms)})

4.2.2.2. Der Funktionsbegriff und Systemeigenschaften

Zum Verständnis der nachfolgenden formalen Darstellung des Modellierungskonzeptsfür verteilte flexible zeitgesteuerte Architekturen wird als Ausgangsbasis der BegriffFunktion definiert. Zusätzlich erfolgt die Einordnung der Eigenschaften eines Systemsin Bezug auf transformierende Funktionen.

Definition 4.2.1 (Funktion) Eine Funktion beschreibt eine linkstotale und rechtseindeutigeRelation f zwischen zwei Mengen D und Z. Dabei ist f eine Teilmenge des kartesischen Pro-dukts D × Z.

Im Kontext der Systembeschreibung verteilter eingebetteter Systeme bildet eine Funktioneinen transformierenden Schritt auf Eingabedaten und erzeugt zur Funktionsbeschreibung kon-forme Ausgabedaten. Falls die Eingabedaten permanent und zeitlich unbeschränkt digital (indiskreten Abständen) auf Ausgabedaten abgebildet werden, so wird von einer Transformation aufunendlichen Datenströmen gesprochen. Dieser transformierende Schritt lässt sich system- undumgebungsspezifisch als Algorithmus umsetzen.

�

Offensichtlich stehen Funkionen stets in enger Beziehung zu einem System. Allgemeinlässt sich der Begriff System und dessen Eigenschaften im Zusammenhang mit verteiltenSystemen wie folgt beschreiben /[Saw]/:


Definition 4.2.2 (System) Ein System wird durch die Systemgrenze, den (meist) zeitabhän-gigen in arbiträrer Anzahl vorliegenden Ein- und Ausgangsgrößen u(t), y(t) sowie durch dasmathematische Modell D(y) = u bzw. y = G(u) definiert. Die Abbildungsvorschriften (Opera-toren) D und G beschreiben das Ein-/ Ausgangsverhalten in impliziter bzw. expliziter Form undenthalten die Parameter p des Systems1.

SYS : U → YmitU = {u1, u2, ..., um} , Y = {u1, u2, ..., un}�

u(t) y(t)SystemEingang Ausgang

Abbildung 4.8.: Grunddarstellung eines Systems aus funktionaler Sicht mit arbiträrer Anzahlan Ein- und Ausgängen

Nach folgenden Kriterien lassen sich Systeme generell klassifizieren:

Dynamisch/statisch: Dynamische Systeme speichern den Verlauf einer Anregung u(t)und schwingen sich auf diese ein. Das Verhalten bezieht über den Verlauf derZeit und lässt sich daher in Form von Differentialgleichungen abbilden. StatischeSysteme agieren ohne das Abspeichern des Verlaufs der Anregung u(t). Eine Ab-bildung erfolgt auf Basis algebraischer Gleichungen.

Zeitkontinuierlich/zeitdiskret: Ein System heißt zeitkontinuierlich, wenn die Signal-werte zu jedem beliebigem Zeitpunkt gegeben sind, etwa bei einem Feder-Masse-System. Ein System heißt zeitdiskret, wenn die Signalwerte nur zu diskreten Zeit-punkten vorliegen.

Wertekontinuierlich/wertediskret: Wertekontinuierliche Systeme unterliegen keinenEinschränkungen innerhalb des Wertebereichs zur Abbildung einer Funktion überbedatete Systemvariablen. Physikalische Prozesse lassen sich daher exakt auf zu-geordnete physikalische Werte abbilden. Werte- oder ereignisdiskrete Systeme re-duzieren den Wertebereich auf fixe quantisierte Werte. Der Zeitpunkt einer Werte-änderung wird als Ereignis bezeichnet.

Linear/nichtlinear: Lineare Systeme basieren auf Systemgleichungen, die die Verstär-kungseigenschaft (Homogenität) und die Additions-Eigenschaft (Superposition) er-füllen. Diese Eigenschaften sind dabei für arbiträre Systemstimulationen u(t) zuallen Zeiten t erfüllt.

Homogenität:Gcu(t) = cGu(t) mit c - beliebige Konstante,

1Die Operatoren D und G werden je nach Systemeigenschaft als Differentialterme in Abhängigkeit derZeit oder als algebraische Gleichungen spezifiziert.


Superposition:Gu1(t) + u2(t) = Gu1(t) + Gu2(t) mit u1,2(t) - beliebige Signale.

Nichtlineare Systeme ergeben sich dementsprechend etwa bei Potenz-, Multiplika-tions- sowie Divisionsoperationen von mindestens zwei Signalen u1,2(t).

Zeitinvariant/zeitvariant: Ein System wird als zeitinvariant bezeichnet, wenn die zu-grunde liegende Systemgleichungen ein identisches Verhalten bei identischen Ein-gangssignalen unabhängig von einem Zeitpunkt (Verschiebungseigenschaft) aufwei-sen. Falls Systemparameter bzw. Koeffizienten in den Gleichungen ihre Werte ab-hängig mit dem Verlauf der Zeit verändern, wird der Bereich der zeitvariantenSysteme erfasst.

Kausal/nicht kausal: Ein System heißt kausal, wenn die Ausgangsgrößen ausschließ-lich vom Verlauf der anliegenden Eingangsgrößen bis zu einem Zeitpunkt t ab-hängen, wobei gilt

∃y ∈ Y : y(t) = Gu(t′) → t ≥ t′.Nichtkausale Systemgleichungen sind im Gegenzug als realitätsfern einzustufenund spielen im Zusammenhang mit reaktiven Systemen im Kontext physikalischerProzesse keine Rolle.

Finit/infinit: Finite Modelle eines System sind limitiert in der maximal möglichen Aus-prägung der Systemteile/-strukturen. Finite Systeme sind im Bereich rechnerge-stützter Systeme bedeutend, da deren Ressourcen begrenzt vorhanden sind. Infini-te Modelle unterliegen im Gegenzug keiner Beschränkung. Beispielhaft lassen sichdie Automaten aus dem zeit- und wertdiskreten Bereich anführen, die in endlicheroder unendlicher Form konstruierbar sind.

Übertragungsfunktion eines zeitkontinuierlichen linearen Systems:

Durch eine Laplace-Transformation ist es beispielsweise möglich ein System aus demZeit- in den Bildbereich abzubilden. Die Übertragungsfunktion hat die Eigenschaft, dasskein lineares Differentialgleichungssystem (LGS) im Übertragungsglied zu lösen ist.

Zustandsgleichungen eines zeitkontinuierlichen linearen Systems:

Eine Möglichkeit ein lineares System zu beschreiben basiert auf linearen Gleichungen/[Föl05]/2:

x(t) = A ∗ x(t) + B ∗ u(t),y(t) = C ∗ x(t) + D ∗ u(t).

Dabei beschreibt A eine Systemmatrix, B eine Steuerungs- oder Eingangsmatrix, C eineBeobachtungs- oder Ausgangsmatrix und D eine Durchgangsmatrix. Sind diese Matri-zen konstant, so ergibt sich ein lineares und zeitinvariantes System. Zur Lösung muss x(t)integriert werden, um x(t) berechnen zu können.

2Hinweis: x und y liegen in Vektorform vor!


x(t) =∫ t

t0

x(τ)dτ + x(t0).

Der Zustandsraum für ein lineares System lässt sich in einem Signalflussdiagramm dar-stellen (s. Abb. 4.9).

CB

D

A

+

+

++x’(t) x(t)

u(t) y(t)t

t 0

+

x(t0)

Abbildung 4.9.: Signalflussdiagramm zur Darstellung des Zustandsraums eines linearen Sys-tems

Zustandsgleichungen eines zeitdiskreten linearen Systems:

Falls die Darstellung der Zeit statt als vektorwertige Funktion mit einer Folge von Vekto-ren beschrieben wird, so lässt sich das dynamische lineare System für den zeitdiskretenBereich erfassen. Dieser Fall erlangt seine Relevanz im Kontext der Abtastung innerhalbvon Digitalrechensystemen, die im Fahrzeugumfeld vorzufinden sind. Als Konsequenzwerden die Zustandsdifferentialgleichungen für den kontinuierlichen Fall durch Diffe-renzengleichungen für den diskreten Fall substituiert (x(t) → x(k), k ∈ Z).

Während sich zeitkontinuierliche Systeme im Bereich von Anwendungssimulatio-nen eignen, zeigen sich Vorteile der zeitdiskreten Systeme im Bereich des Einsatzes inEchtzeitsystemen.

4.2.2.3. Funktionsnetzmodellierung

Zur Spezifikation logischer E/E-Systemarchitekturen eignet sich der Funktionsnetzan-satz. Der Kerns dieser Methode bezieht sich auf die im Fahrzeug vorliegende Anwen-dungsdomäne der reaktiven Systeme. In diesem Umfeld ist der Umgang mit automati-sierten Regel- und Steuerungsapplikationen und elektronischen Schaltkreisen etabliert.Dabei sind Operationen zur Transformation von Datenflüssen und auf höherer Ebeneder Einsatz von booleschen Funktionen und Transferfunktionen in Form von Blockdia-grammstrukturen von Bedeutung. Mithilfe dynamischer Gleichungen lassen sich dabeidiese Strukturen kapseln. Im Bereich der Softwareentwicklung korreliert dieser Ansatz


mit dem Konzept der Modellierung von Datenflussdiagrammen /[Kah74], [McG82]/.Das Hauptaugenmerk bei der Funktionsnetzbildung liegt auf der Strukturierung

und Modularisierung integrierter E/E-Funktionen in Komponenten. Dabei wird von derSicht der konkreten Funktionsalgorithmik, dass heißt von der konkreten Ausprägungder Funktion, beispielsweise einem Regelschleifenmodell zur Fahrwerksdämpfung, ab-strahiert.

Definition 4.2.3 (Funktionsnetz) Das Funktionsnetz fn aus der Menge FN (function net)aller Funktionsnetze wird durch eine Menge an Funktionsblöcken FC (functional component)beschrieben, welche über eine Menge an Sende- und Empfangsschnittstellen PO (ports) Datensenden und empfangen können. Das Funktionsnetz fn ist dabei aus einer arbiträren Submengeaus FC zusammengesetzt und bildet einen gerichteten Graphen. Dadurch lässt sich die logischeSystemarchitektur SYSlogic wie folgt definieren:

SYSlogic : FN → P(FC) mit P(FC) als Potenzmenge über FC,

Das bedeutet für ein Funktionsnetz fn aus FN:

SYSlogic( f n) = FCf n mit f n ∈ FN, FCf n ⊆ FC, |FCf n| ≥ 2

Die Ports PO unterscheiden sich in Sende- und Empfangsports SP (sender port) und RP (re-ceiver port), wobei SP und RP in PO strikt disjunkt auftreten.

PO = SP ∪ RP mit SP ∩ RP = ∅

Jeder Funktionsblock fc besitzt eine arbiträre Anzahl an Sende- und Empfangsports, die sich mitfolgenden Relationen

s : FC → P(SP) mit s( f c) ⊆ PO, |SP| ≥ 0,r : FC → P(RP) mit r( f c) ⊆ PO, |RP| ≥ 1

zuweisen lassen. Zwischen den Sende- und Empfangsports können injektive unidirektionaleKommunikationsbeziehungen für ein Funktionsnetz definiert werden:

π : SPf n → RPf n mit SPf n =⋃

f c∈FCf n

s( f c) ⊆ PO,

RPf n ⊆ ⋃f c∈FCf n

r( f c) ⊆ PO

Die durch die Funktion π definierten Relationen zwischen den Sende- und Empfangsports wer-den als Konnektoren aus der Menge SRC (send-receive-connector) zum Datenaustausch auf-gefasst.


SRCf n =⋃

f csend∈FCf n

⋃sp∈s( f csend)

{(( f csend, sp), ( f creceive, π(sp))) mit π(sp) ∈ r( f creceive)}

, |SRCf n ≥ 1|

Ein Element src aus SRCf n des Funktionsnetzes FN wird durch ein Zweitupel mit jeweils einemFunktionsblock aus FC als Sender und Empfänger sowie zweier Ports eindeutig definiert.

src = (( f csend, sp), ( f creceive, rp)): src ∈ SRCf n, f csend, f creceive ∈ FCf n, sp ∈ SPf n, rp ∈ RPf n

Da f csend und f creceive nicht zwangsläufig unterschiedliche Funktionsblöcke darstellen müssen,wird eine Rückkopplung im Funktionsnetz nicht explizit ausgeschlossen.In einer integrierten Betrachtung erzeugen Funktionsnetze die logische Architektur eines Sys-tems mit

• syntaktischen Schnittstellen (RP → SP),

• abstrahiertem Verhalten (=Funktionen) (FC),

• der Möglichkeit zur Komposition von Systemteilen.

�

4.2.2.4. Abstraktion und Verfeinerung

Ein entscheidender Vorteil der Funktionsnetzmodellierung ergibt sich aus den Konzep-ten der Abstraktion und Verfeinerung bereits entwickelter Funktionsnetze. Die Grundi-dee dabei basiert auf der Interpretation eines Funktionsnetzes als hierarchischen Funk-tionsblock h f c, wobei Abhängigkeiten zwischen der Menge der hierarchischen Funkti-onsblöcke und der Menge der allgemein zugrundeliegenden Funktionsblöcke existieren(vgl. Abb. 4.10).

Unter HFC (hierarchical functional component) versteht sich die Menge aller hierar-chisch komponierten Funktionsblöcke. Bei der Abstraktion eines Funktionsnetzes wer-den Substrukturen, die sich als Teilfunktionsnetz auffassen lassen, durch einen hierar-chischen Funktionsblock h f c substituiert. Dadurch gilt für die neue gültige Menge allerFunktionsblöcke FC′:

FC′ = HFC ∪ FC′′ : FC′′ ⊂ FC, HFC = ∅

Ein hierarchischer Funktionsblock enthält die in der Menge FC′ abstrahierten Elementeaus der ursprünglichen Funktionsblockmenge FC.

SYSlogic(h f n) = FCh f n mit FCh f n ⊆ FC′, FN′ = FN ∪ {h f n}


FunktionsblockFC1

(Sender/Empfänger)

FunktionsblockFC2

(Sender/Empfänger)

Initialblock S1(Sender)

Terminierungs-Block R1

(Empfänger)


(Empfänger)

HierarchischerFunktionsblock

HFC1(Sender/Empfänger)



(Empfänger)


(Empfänger)

Generalisierungs-/Verfeinerungsstufe

Abbildung 4.10.: Generalisierungs-/Verfeinerungsrelation zwischen HFCs und FCs

Die Zusammenhänge zwischen einem generalisierten und einem verfeinerten Funkti-onsnetz werden durch die Verwendung der Empfangsports RP′

f n eines hierarchischenFunktionsnetzes h f n innerhalb eines verfeinerten Funktionsnetzes f n offensichtlich. DiePorts RP′

f n werden dabei durch eine partielle Menge der Sendeports aus der MengeSPh f n des generalisierten Funktionsnetzes h f n bedatet:

RP′f n =

⋃f c∈FCf n

r( f c)\RPf n mit RP′f n ⊆ ⋃

f c∈FCh f n

r( f c) ⊆ RPh f n,

π : SP′h f n → RP′

f n mit SP′h f n ⊆ ⋃

f c∈FCh f n

s( f c)

Allgemein sind Funktionsnetze mit Vierfach-Tupeln über die Mengen der Funktionsblö-cke, der Senderelationen zwischen den zugeordneten Sende-/Empfangsports und derreferenzierten Sende-/Empfangsports (FC, π, SP, RP) vollständig beschrieben.

Für den Zweck einer Verfeinerung eines Funktionsnetzes lässt sich ein Funktions-block f b ∈ FC durch eine eigene Funktionsnetzstruktur f n substituieren. In der verfei-nerten Sicht wird ein allgemeines Funktionsnetz um Funktionsblöcke, Senderelationenund Sende-/Empfangsports erweitert. Dabei steht ein Funktionsnetz aus der Menge FNin Relation (∼) zu einem Vierfachtupel mit Teilmengen aus FC, SP und RP sowie derSendefunktion π:

Funktionsnetz Verfeinerungsstufe i:

f ni ∼ (FC, π, SP, RP)


Verfeinerungsschritt auf f c:

f c ∼ (FCf c, π f c, SPf c, RPf c) mit f c ∈ FC

Funktionsnetz Verfeinerungsstufe i + 1:

f ni+1 ∼ ((FC\ f c) ∪ FCf c, π ∪ π f c, SP ∪ SPf c, RP ∪ RPf c)

Über eine Kapselung Gei (generalization) werden die Mengen eines flachen Funkti-onsnetzes f n durch die Mengen eines hierarchischen Funktionsnetzes h f n ersetzt. Ineinem Verfeinerungsschritt �i (refinement) lassen sich einzelne Funktionsblöcke durchSubfunktionsnetzstrukturen substituieren. In beiden Fällen ergibt sich eine wachsendehierarchische Struktur, die sich in verschiedene Ebenen untergliedern lässt. Je nach Wei-terentwicklung des Funktionsnetzes entsteht dadurch, unabhängig von der Anzahl anKapselungen/Verfeinerungen, ein zyklenfreier Graph, wobei Rückkopplungen im Sys-tem bei Bedarf umgesetzt werden können. Gleichzeitig werden redundante Kommuni-kationspfade im Netzwerk vermieden und als Konsequenz die Konstruktion unsaubererFunktionsschnittstellen unterbunden. Zusätzlich werden bei der Graphentraversierungzur Analyse der Kommunikationspfade inkonsistente oder unvollständige Funktions-ketten identifiziert (Fehlen eines initialen Senderblocks oder eines finalen Empfänger-blocks).

Abstraktionsfunktion Gei:

Gei : FC → HFC : ∃ f ci, f cj ∈ FC(Gei( f ci) = Gei( f cj) → f ci ∼ f cj)

Dabei gilt es folgende Forderung für Gei zu garantieren:

Surjektivität:

∀h f c ∈ HFC∃ f c ∈ FC : Gei( f c) = h f c

Dadurch bleibt gewährleistet, dass für jeden abstrakten Funktionsblock stets ein kon-kreter Funktionsblock im Modell existieren muss.

Einzigartigkeit:

∀ f c ∈ FC : |[ f c]| = 1 → Gei( f c) = f c mit[ f c] =

{f c′ ∈ FC, Gei( f c) = Gei( f c′)

}Jedem abstrakten Funktionsblock liegt die Verschmelzung von mindestens zwei kon-kreten Funktionsblöcken zugrunde. Singuläre Funktionsblöcke einer Äquivalenzklasse([ f c]) lassen sich in einer hierarchischen Sicht ausschließlich auf sich selbst abbilden.


∀x ∈ FC : (Gei+1(x) = x) → x ∈ FC′

: f ni ∼ (FC, π, SP, RP), f ni+1 ∼ (FC′, π′, SP′, RP′), HFC ⊂ FC′, FC′ ∩ FC = ∅

In diesem Zusammenhang bleiben alle nicht-transformierten Funktionsblöcke bei einemAbstraktionsschritt i + 1 erhalten.

Aus Sicht einer übergeordneten Funktionsblockmenge

V = { f c1, f c2, f c3, ...} mit f ci ∈ FC ∪ HFC, i = N+0

mit sämtlichen konkreten und abstrahierten Funktionsblöcken lässt sich eine Verfei-nerungsrelation �i ⊆ V × V als Gegenstück zur Abstraktionsfunktion Gei definieren.Dabei gilt:

∀ f c, f c′ ∈ V : f c �i f c′ ⇔ Gei( f c) = f c′

Dadurch werden eindeutige Zuordnungen zwischen Funktionsblöcke unterschiedlicherAbstraktionsstufen garantiert.

Über mehrere Ebenen i, i + 1, ... hinweg betrachtet existiert durch �i eine partielleOrdnung sowie eine Abhängigkeitsstruktur der Funktionsblöcke in Form eines Baums.Dabei existiert für jeden Subfunktionsblock stets nur jeweils ein zugeordneter abstrakterFunktionsblock:

∀ f c, f c′, f c′′ ∈ V : f c �i f c′ ∧ f c �i f c′′ → f c′ �i f c′′ ∨ f c′′ �i f c′

4.2.2.5. Zeitkettenmodell

Ein signifikanter Vorteil der Funktionsnetzmodellierung zur Beschreibung logischerE/E-Architekturen entsteht bei der Definition eines Zeitmodells als Teil der Funkti-onsspezifikation. Diese Ideen finden sich in ähnlicher Form in den folgenden Ansät-zen /[RZE+02], [AUT07b]/ wieder und werden partiell in der Konzeption der Zeitmo-dellierung in dieser Arbeit berücksichtigt. Das Sendeverhalten in der Zeitmodellierungverwendet periodische und ereignisgesteuerte Übertragungskonzepte. Dabei gilt es imersten Fall Ungenauigkeiten in der Übertragung (Jitter) sowie mögliche Übertragungs-perioden zu spezifizieren. Die zweite Variante erfordert Angaben über Minimalwerte(Sperrzeiten) und Maximalwerte (Zeitüberschreitungen) zwischen dem Auftreten vonEreignissen.

Einbettung in die funktionale Modellierung:

1. Kommunikation zwischen sendende SW-Komponente A und empfangende SW-Komponente B,

2. Konnektor spezifiziert Zeitfluss zwischen Senderport S und Empfängerport R,


Funktionsblock A(Sender)

Funktionsblock B(Empfänger)

Sendezeitpunkt S Empfangszeitpunkt R

S R’S’

Maximales Alter

Maximale Übertragungszeit

S RMAX=DeadlineRMINMaximales Alter

EmpfangsbereichR

(R)

Konzept A)

Konzept B)

Abbildung 4.11.: Darstellung zweier Modelle zur Spezifikation des Zeitverhaltens an den Kom-munikationsschnittstellen zweier Softwarekomponenten in der Funktionsnetzebene

3. Min-Max-Modell: SRMin < SR < SRMax = MaxAge,

4. Max-Age-Modell: SR = S′R′ < SS′ + S′R′ = SR′ < MaxAge.

Im Gegensatz zur Abstraktion/Verfeinerung steht bei der Zeitanalyse die sequentielleVerkettung der Funktionskomponenten im Vordergrund.

Definition 4.2.4 (Zeitkette) Eine Zeitkette TC (time chain) beschreibt den zeitlichen Verlaufeiner Signalkommunikation auf Basis der Spezifikation eines verteilten Systems, etwa einemFunktionsnetz FN.

Die Struktur entsteht durch die Relation zwischen einer sendenden und einer empfangendenKomponente. Diese Komponenten liegen als Funktionsblöcke FC vor. Dabei wird die Basisstruk-tur eines Funktionsblocks um Zeitinformationen erweitert:

Kommunikationspfad:

P = ( f c1, f c2, ..., f cn) mit f ci, f ci+1 sind adjazent, i ∈ [0; n − 1],

Zeitabbildung:

d : C → R+0 mit C = FC ∪ SRC,

Zeitkette:

TC = (d( f c1), d(src12), d( f c2), d(src23), ..., d( f cn)),mit d( f ci) als „deadline“, d(srcij) als „sending latency“

Die in den Funktionsblöcken eingebettete Funktion, etwa eine Regelschleife oder eine Steuerung,toleriert einen zeitlichen Verzug bei der Auswertung bis zu einer bestimmten Frist (deadline).Durch diese Restriktion lässt sich eine genauere Spezifikation der Signalübertragung an der


Sende-/Empfangsbeziehung SRC ableiten. Dabei muss die Ausprägung der SRC die deadline dessendenden und des empfangenden Funktionsblocks unter allen Betriebszuständen einhalten. DieSRC unterliegt den Eigenschaften der technischen Übertragungsform zwischen den FCs (bspw.dem Übertragungskonzept (ereignis-/zeitgesteuert), des Sendetyps (spontan/zyklisch), etc.).

Durch die Addition der im FN spezifizierten Zeitinformationen ergeben sich TCs, die ent-sprechend der Gesamtsystemanforderung ausgelegt werden können.

�

Prinzipiell gleicht die Zeitkettenmodellierung dem Konzept der Transformation von Da-tenflussgraphen (DFG) in Problemgraphen bei der Partitionierung im Entwicklungsfelddes Hardware-/Softwarecodesigns /[PT07]/ (s. Abs. 4.2.2.8/s. Abb. 4.12).

FunktionsblockFC1

(Sender/Empfänger)

FunktionsblockFC2

(Sender/Empfänger)



(Empfänger)


(Empfänger)

S1

R1

FC2 R2FC1 S1

R2

FC2 R1FC1SRC1 SRC2 SRC3

Datenflußgraph Problemgraph

Zeitkettentransformation

Kommunikationsfluß

Abbildung 4.12.: Transformation eines Datenflussgraphen zu einem Problemgraphen auf Basisdes Zeitkettenansatzes

Die signaltransformierenden Knoten lassen sich durch die Hinzunahme software-technischer Eigenschaften zeitlich verfeinern, etwa im Bereich eines Betriebssystems(Unterbrechungskonzept, Prozessblockierung, präemptives Multitasking, Prozessperi-oden, Jitter) oder der Softwareinitialisierung (Offsets, Anlaufverzögerung). Eine fein-granulare Analyse heterogener Einflüsse auf eine erweiterte Zeitkettenmodellierung isteine umfassende Aufgabe, welche nicht im Rahmen dieser Arbeit behandelt wird. DasEU-Projekt TIMMO beschäftigt sich mit dieser Thematik im Kontext automotiver Rege-lungssysteme zur Ergänzung des AUTOSAR-Standards um Timing-Aspekte /[ERG08],[Ric08]/. Dieses Konsortium untersucht dabei auch die Anwendbarkeit existierenderLösungen aus Sicht der Modellierung für eingebettete Echtzeitsysteme, beispielswei-se das UML-Profil MARTE /[FBSG07]/. Aktuell liegen noch keine offiziellen Timing-Spezifikationen des TIMMO-Konsortiums vor.


4.2.2.6. Schnittstellenspezifikation

Ein wesentlicher Aspekt des Architekturdesigns bezieht sich auf das saubere, in diesemSinn korrekte und vollständige, Design der internen und externen Architekturschnitt-stellen. Dabei lässt sich der allgemeine Schnittstellenbegriff in Unterbegriffe gliedern/[Kop97]/:

1. Kontrolleigenschaften beziehen sich auf die Handhabung kausaler Aspekte im Um-gang mit Steuerungssignalen an der Schnittstelle. Beispielsweise bezieht sich dieAktivierung einzelner Tasks innerhalb eines Steuergeräts oder der Wechsel zwi-schen Systemmodi allgemein auf diese zu spezifizierenden Kontrolleigenschaften.

2. Dateneigenschaften spezifizieren die konkrete Struktur und Semantik der an derSchnittstellen übergebenen Datenelemente.

3. Temporale Eigenschaften definieren Restriktionen für Daten und Kontrollsignale imZeitbereich an der betrachteten Systemschnittstelle.

4. Das funktionale Vorhaben dient der Beschreibung notwendig zu erfüllender Eigen-schaften in der Anwendungsdomäne. Als Beispiel lassen sich Vorgaben aus Sichtder funktionalen Sicherheit /[IEC05], [ISO07], [Che08]/ innerhalb einer Anwen-dungsdomäne anführen. Entwickelte Funktionen garantieren diese Eigenschaftengegenüber den an der Schnittstelle interagierenden Partnern.

Anhand der dreiteiligen Klassifikation wird das Schnittstellenverhalten für das vorlie-gende Konzept erläutert:

Kontrolleigenschaften: Die Signifikanz der Kontrolleigenschaften eines betrachtetenSystems steigt, falls dessen Grundkonzept einen stark interaktiven Charakter hat oderunter Berücksichtigung hoher Sicherheitsanforderungen /[IEC05], [ISO07], [Che08]/ zuentwickeln ist. Im ersten Fall bezieht sich der Ansatz auf Client-Server-Systeme, bei de-nen gezielt auf Anfragesignale/-botschaften (request) reagiert wird (response). Bezogenauf ein FN wird der Ausgangsport FC_Outi mit i ∈ N+

0 ausschließlich in Abhängigkeiteiner request-Anfrage am Eingangsport FC_Ini = req mit i ∈ N+

0 bedatet (vgl. /[BS01]/).

Dateneigenschaften: Zu den Dateneigenschaften zählen die aus der Informationstheoriebekannten Typen (Integer, Real, Boolean, etc.), die Signalauflösung, Signalversätze (offsets)und optional die Signalminimal- und maximalwerte3.

Temporale Eigenschaften: An den Schnittstellen der FC findet der eigentliche Signal-austausch statt. Darunter versteht sich das Senden und das Empfangen von arbiträrdefinierbaren Daten über Sende- und Empfangsports. Dabei findet eine Transformationder temporalen Eigenschaften des eigentlichen Signals konform zu den Anforderungender zugeordneten Übertragungsform (CAN, FlexRay, etc.) statt.

Die temporalen Eigenschaften auf Signalbasis lassen sich formal spezifizieren.

3Im Bereich der automotiven Systeme gibt es die Unterscheidung zwischen Rohwert- und Filtersigna-len. Anforderungen hinsichtlich der Einhaltung von Abtastgrenzen (Nyquist-Shannon-Abtasttheorem) oderder Verwendung von Tiefpassfiltern bleiben in diesem Ansatz unberücksichtigt /[WP07], [Föl05]/.


Definition 4.2.5 (Signalzeitverhalten (signal timing)) Das Signalzeitverhalten ti wird aufeinem Architektursignal i ∈ S aus der Menge S aller Signale einer E/E-Architektur definiert. tibildet dabei ein 4-Tupel, bestehend aus dem Signaltyp ST, dem Subtyp SST, der Signallänge SLund der Signalphase SP.

t : S → ST × SST × SL × SP,∀i ∈ S : t(i) = (sti, ssti, sli, spi) ∧ sti = spontan → spi = ⊥

mit sti, sli = ⊥�

Der Signaltyp lässt sich untergliedern in spontane oder zyklische Kommunikation. DerSubtyp spezifiziert eine optionale Ergänzung des Signaltyps für hybride Signaltypenals Binärrelation auf den Mengen ST × SST mit ST = {zyklisch, spontan} und SST ={zyklisch, spontan, aktiv,⊥} (s. Tab. 4.2)4.

Tx-Rx-Beziehung TemporaleigenschaftenName Sender Empfänger ST SST SL (Bit) SP (ms)

Signal a ECU1 ECU2,3 zyklisch ⊥ 16 20Signal b ECU1 ECU4 zyklisch spontan 64 10Signal c ECU1 ∞ zyklisch zyklisch 8 20/10Signal d ECU2 ECU1 zyklisch spontan 8 40Signal e ECU2 ECU1,4 spontan ⊥ 32 ⊥Signal f ECU2 ∞ zyklisch ⊥ 24 5Signal g ECU3 ECU2 zyklisch zyklisch 80 80/5Signal h ECU4 ECU1,2 zyklisch spontan 16 40Signal i ECU4 ECU2,3 zyklisch ⊥ 32 10Signal j ECU4 ∞ spontan ⊥ 24 ⊥

Tabelle 4.2.: Beispiel zur Übersicht der Kriterien zur Attributierung eines Funktionsnetzes

Auf Basis der vollständig spezifizierten temporalen Eigenschaften sämtlicher Signaleerfolgt eine Transformation dieser Darstellung in eine buskonforme Abbildung. Flex-Ray-Systeme erfordern dabei die Zuordnung auf die einzelnen Übertragungssegmente(statisch, dynamisch) und die Platzierung an einer passenden Stelle im Gesamtschedule(scheduling). Es existiert kein eindeutiger, optimaler Algorithmus für diese Transformati-on unter Berücksichtigung von Synchronitätsanforderungen bei der Signalübertragung.Die Berechnungskomplexität des Schedulingprozesses für die Abbildung der Signale zuBusbotschaften zählt zu den NP-vollständigen Problemen /[NG97], [GJ79]/. Die Ent-wicklung proprietärer Algorithmen auf Basis unterschiedlicher Heuristiken zur Vertei-lung von Botschaften auf dem Schedule, etwa mit genetischen Algorithmen /[SP96]/bildet dabei einen eigenen Forschungszweig, der kein zentrales Thema innerhalb dieserArbeit stellt. An dieser Stelle wird auf Forschungsergebnisse weiterverwiesen /[Nos96],[NG97]/.

4Die Signaltypen werden als Abstraktion von den etablierten Sendetypen aus /[Que06], [Vec07]/ abge-leitet. Von einer feingranularen Differenzierung durch die Konkretisierung der active-Bedingung, etwa beider Interpretation des Signalwerts, der Reaktion bei Signaländerung oder der Bedatung durch Software-module, wird abstrahiert.


Die Abhängigkeit zwischen Busschedule und Signalzeitverhalten wird nachfolgendauf Grundlage des entwickelten formalen Ansatzes beschrieben, auf dessen Basis Algo-rithmen zum Scheduling aufsetzen können.

Wie oben definiert bildet das FN eine Systemstruktur, bestehend aus FC und SRC.Die Sende-/Empfangsbeziehungen lassen sich für sämtliche FC innerhalb der Konnek-tivitätsmatrix abbilden. Die Zeilenvektoren beschreiben alle n Funktionsblöcke, die eineInformation von einem bestimmten FC empfangen. Ergänzend beschreiben die Spalten-vektoren sämtliche Informationen, die eine einzelne Komponente von m Funkionsblö-cken empfängt.

Algorithmus zur Transformation eines FN in den statischen FlexRay-Schedule:

1.) Anlegen der Konnektivitätsmatrix für das FN:⎛⎜⎜⎝

SRCFC11 SRCFC12 ... SRCFC1nSRCFC21 SRCFC22 ... SRCFC2n

...SRCFCm1 SRCFCm2 ... SRCFCmn

⎞⎟⎟⎠

2.) Eliminierung aller leeren Zeilenvektoren (keine Sender):⎛⎜⎜⎝

SRCFC11 SRCFC12 ... SRCFC1nSRCFC21 SRCFC22 ... SRCFC2n

...SRCFCm′1 SRCFCm′2 ... SRCFCm′n

⎞⎟⎟⎠

3.) Partitionierung der FC des FN und Adaption der Konnektivitätsmatrix:⎛⎜⎜⎝

SRCPC11 SRCPC12 ... SRCPC1qSRCPC21 SRCPC22 ... SRCPC2q

...SRCPCp1 SRCPCp2 ... SRCPCpq

⎞⎟⎟⎠

4.) Integration der Temporaleigenschaften (Matrixverfeinerung) auf Signalebene (x):(↪→ Matrixreplikation : ∀i ∈ FC : |i_Outj| > 0 → ∃AFCi)⎛

⎜⎜⎝SRCPC111 SRCPC112 ... SRCPC11qSRCPC121 SRCPC122 ... SRCPC12q

...SRCPC1x1 SRCPC1x2 ... SRCPC1xq

⎞⎟⎟⎠⎛⎜⎜⎝

SRCPCp11 SRCPCp12 ... SRCPCp1qSRCPCp21 SRCPCp22 ... SRCPCp2q

...SRCPCpx1 SRCPCpx2 ... SRCPCpxq

⎞⎟⎟⎠

5.) Paketierung (max(Zeilenvektorsumme) ≤ 1) → Slotbelegung:(↪→ Harmonisierung bei mehreren Empfängern.)

∀i ∈ SRCPCi : max(SRCPCijk′ , SRCPCijk′+1, ..., SRCPCijk′′) +max(SRCPCi′jk′ , SRCPCi′jk′+1, ..., SRCPCi′jk′′) ≤ 1 →


SRCPCij = ((SRCPCijk′ + SRCPCi′jk′), (SRCPCijk′+1 + SRCPCi′jk′+1), ...,(SRCPCijk′′ + SRCPCi′jk′′)) ∧ SRCPCij = () mit 1 < k′, k′′ < q, 1 < j < x

Abbildung der Zeilen auf einzelne Sende-Slots im FlexRay-Schedule:

∀i ∈ SRCPCi : SRCPCij → Slotl mit 1 < i < p, 1 < j < x, 1 < l < p ∗ x

Beispiel:

Gegeben sei ein FN mit den vier Funktionsblöcken FC1−4 und den folgenden SRC ={SRC1, SRC2}. Die SRC sind über Ein- und Ausgabeports mit den FC verbunden:

SRC1 = (FC1_Out1, FC3_In1) SRC2 = (FC2_Out1, FC3_In2, FC4_In1)

Aus den SRC lässt sich im Schritt 1 die Konnektivitätsmatrix AFN erstellen:

AFN =

⎛⎜⎜⎝⊥ 0 1 00 ⊥ 1 10 0 ⊥ 00 0 0 ⊥

⎞⎟⎟⎠

In Schritt 2 werden FC3, FC4 rausgefiltert, da diese reine Empfänger darstellen.⎛⎜⎜⎝⊥ 0 1 00 ⊥ 1 10 0 ⊥ 00 0 0 ⊥

⎞⎟⎟⎠ →

(⊥ 0 1 00 ⊥ 1 1

)

In Schritt 3 wird die Konnektivitätsmatrix partitioniert. In diesem Beispiel werden diesendenden FC auf verschiedene Steuergeräte implementiert. Dabei ergibt sich keine Än-derung an AFN .

In Schritt 4 wird AFN gemäß der temporalen Signaleigenschaften verfeinert. Dadurchwird die Bedeutung der Matrixzeilen modifiziert. Sie spezifizieren alle Sendesignale derbeiden sendenden FC. Die Matrixwerte entsprechen dem Füllgrad eines einzelnen Slotsdes FlexRay-Schedules auf Basis einer einheitlichen Buszykluslänge5.

(5ms, 10ms, 20ms, 40ms) → (1,12

,14

,18)

5Signalperioden, die nicht dem Wert basecyclei, i ∈ N+ entsprechen, müssen im dynamischen Segmentübertragen werden


⎛⎜⎜⎜⎜⎜⎜⎜⎜⎜⎜⎜⎜⎜⎜⎜⎝

⊥ 0 1 0⊥ 0 1

2 0⊥ 0 1

4 0⊥ 0 1

4 0⊥ 0 1

4 00 ⊥ 1 10 ⊥ 0 1

20 ⊥ 0 1

20 ⊥ 1

4 00 ⊥ 1

818

⎞⎟⎟⎟⎟⎟⎟⎟⎟⎟⎟⎟⎟⎟⎟⎟⎠

Dabei werden durch die Ausgangsports für jede sendenden FC eine jeweils eigene Sen-dematrix erzeugt (AFN′ → (AFC1, AFC2)).

AFC1 =

⎛⎜⎜⎜⎜⎝⊥ 0 1 0 24⊥ 0 1

2 0 42⊥ 0 1

4 0 16⊥ 0 1

4 0 32⊥ 0 1

4 0 16

⎞⎟⎟⎟⎟⎠ AFC2 =

⎛⎜⎜⎜⎜⎝

0 ⊥ 1 1 320 ⊥ 0 1

2 160 ⊥ 0 1

2 240 ⊥ 1

4 0 80 ⊥ 1

818 42

⎞⎟⎟⎟⎟⎠

Durch Hinzunahme der Größenangaben der versendeten Signale für jeden Zeilenvek-tor lassen sich die Sendevorgänge mit identischen Zykluszeiten auf Signalebene pake-tieren (

[( 1

4 , 16), ( 14 , 32), ( 1

4 , 16)] → [

( 14 , 32), ( 1

4 , 32)]

und[( 1

2 , 16), ( 12 , 24)

] → [( 1

2 , 48)]

:max(signal package size) = 48). Die Größe der Signalpakete wird anschließend wiederentfernt.

AFC1 =

⎛⎜⎜⎝⊥ 0 1 0 24⊥ 0 1

2 0 42⊥ 0 1

4 0 32⊥ 0 1

4 0 32

⎞⎟⎟⎠ AFC2 =

⎛⎜⎜⎝

0 ⊥ 1 1 320 ⊥ 0 1

2 400 ⊥ 1

4 0 80 ⊥ 1

818 42

⎞⎟⎟⎠

AFC1 =

⎛⎜⎜⎝⊥ 0 1 0⊥ 0 1

2 0⊥ 0 1

4 0⊥ 0 1

4 0

⎞⎟⎟⎠ AFC2 =

⎛⎜⎜⎝

0 ⊥ 1 10 ⊥ 0 1

20 ⊥ 1

4 00 ⊥ 1

818

⎞⎟⎟⎠

Im 5. Schritt wird eine verfeinerte Paketierung auf Slotebene durchgeführt.

AFC1 =(⊥ 0 1 0 1⊥ 0 1 0 1

)AFC2 =

(0 ⊥ 1 1 10 ⊥ 3

858

78

)

Daraus folgt, dass sich das FN im statischen Segment innerhalb zweier statischer Slotsmit jeweils einer 5ms-Botschaft für FC1 und innerhalb zweier statischer Slots mit einer5ms-Botschaft sowie einer Multiplexbotschaft für FC2 im FlexRay-Schedule abbildenlässt. In der neu eingefügten rechten Spalte lässt sich dabei der Füllgrad eines jeden


Slots angeben6.

4.2.2.7. Physikalisches Netz

In der vorgestellten Modellierungssprache erfolgt die Realisierung der technischen Sys-temarchitektur auf Basis einer physikalischen Netzsicht.

Fahrzeugplattform

Steuergerät ECU1

Prozessoreinheit

ECU1.P1

Prozessoreinheit

ECU1.P2

Steuergerät ECU2

Prozessoreinheit

ECU2.P1

Steuergerät ECU6

Prozessoreinheit

ECU6.P1

Steuergerät ECU5

Prozessoreinheit

ECU5.P1

Prozessoreinheit

ECU5.P2

Steuergerät ECU4

Prozessoreinheit

ECU4.P1

Steuergerät ECU3

Prozessoreinheit

ECU3.P1

Prozessoreinheit

ECU3.P2

PCH

Übergang zwischen PN und WIR

Steuergerät ECU1

Prozessoreinheit

ECU1.P1

Prozessoreinheit

ECU1.P2

Steuergerät ECU2

Prozessoreinheit

ECU2.P1

Steuergerät ECU6

Prozessoreinheit

ECU6.P1

Steuergerät ECU5

Prozessoreinheit

ECU5.P1

Prozessoreinheit

ECU5.P2

Steuergerät ECU4

Prozessoreinheit

ECU4.P1

Steuergerät ECU3

Prozessoreinheit

ECU3.P1

Prozessoreinheit

ECU3.P2

PC1 PC2 PC3

PC4 PC5 PC6

CL1

CL2

PIN1 PIN2

PIN1 PIN2

PIN1 PIN2

PIN1 PIN2

PIN1 PIN2

PIN1 PIN2

Motorraum FahrzeugheckbereichFahrgastzelle

Steuergerät ECU1

Steuergerät ECU2

Steuergerät ECU6

Steuergerät ECU5

Steuergerät ECU4Steuergerät

ECU3

PCH

PC1PC2

PC3

PC4

PC5

PC6

LL1

LL2LL3

LL4 LL5

Übergang zwischen PN/WIR und TOP

High Ω

High Ω

Abbildung 4.13.: Spezifikationsbereiche des physikalischen Netzwerks auf PN, WIR und TOP-Ebene

Definition 4.2.6 (Physikalisches Netz) Das physikalische Netz PN komprimiert die Aspek-te der physikalischen Bordnetzkonfiguration. Dazu zählen die Steuergeräteanordnung (topolo-gy) TOP, die Systemverkabelung (wiring) WIR und die Steuergeräteplatzierung im Fahrzeug(package) PCK. Konkret lässt sich die Instanz eines Funktionsnetzes FN auf Submengen derSteuergeräte (ECU) und der physikalischen Übertragungskanäle (PCH) abbilden. Die Verknüp-fung zwischen den Steuergeräten und den Übertragungskanälen erfolgt über die Potenzmengen-bildung der steuergeräte- und netzwerkseitigen Stecker PC und NC. Die Stecker werden mit derbijektiven Funktion v aufeinander abgebildet:

6Achtung: Der Füllgrad für jeden Slot entspricht nicht der Summe des Zeilenvektors, da Signale mehrals einen Empfänger besitzen können.


PNf n = (ECUf n, PCf n, NCf n, PCHf n, v) mit ECUf n ⊆ ECU, PCHf n ⊆ PCH,

PCf n =

⎡⎣ ⋃

e∈ECUf n

c(e)

⎤⎦ mit Relation c : ECU → P(PC)

ordnet jedem Steuergerät eine Menge von steuergeräteseitigen Steckern zu,

NCf n =

⎡⎣ ⋃

p∈PCHf n

n(p)

⎤⎦ mit Relation n : PC → P(NC)

ordnet jedem physikalischen Übertragungskanal eine Menge von busseitigen Steckern zu.v : PCf n → NCf n,

definiert eine bijektive Abbildung aus der Menge der steuergeräteseitigen Steckerauf die Menge der busseitigen Stecker.

Dabei gelten folgende Prämissen:

Eindeutigkeit:

∀e, e′ ∈ ECUf n : e = e′ ⇒ c(e) ∩ c(e′) = ∅

Jeder Stecker wird exklusiv einem Steuergerät zugeordnet, wobei ein Steuergerät mehrere Steckerbesitzen kann.

Redundanz:

∀p, p′ ∈ PCHf n : p = p′ ⇒ n(p) ∩ n(p′) ⊆ NCf n,

Jeder Stecker kann eine arbiträre Anzahl an physikalischen Kanälen bedienen, wobei die Anzahlder netzwerkseitigen Stecker identisch zur Anzahl der steuergeräteseitigen Stecker ist.

Erweiterbarkeit:

Eine Erweiterung (ECU′f n, PC′

f n, NC′f n, PCH′

f n, v′) einer physikalischen Netzinstanz (ECUf n,PCf n, NCf n, PCHf n, v) lässt sich wie folgt definieren:

ECUf n ⊆ ECU′f n und PCHf n ⊆ PCH′

f n;

∀e ∈ ECUf n, e′ ∈ ECU′f n : e = e′ ⇒ c(e) ⊆ c(e′);

∀p ∈ PCHf n, p′ ∈ PCH′f n : p = p′ ⇒ n(p) ⊆ n(p′);

∀s ∈ ⋃e′∈ECUf n

c(e′) : v(s) = v′(s)

Durch diese drei Vorbedingungen erhält eine Erweiterung sämtliche Relationen c, n zwischenden Elementen in ECUf n und PCHf n. Konsequenterweise bleibt die bijektive Abbildung zwi-schen den übernommenen Elementen in dem neuen physikalischen Netzwerk identisch zu den


Elementen aus dem zugrunde gelegten physikalischen Netzwerk.TOP umfasst die Zuordnung der Steuergeräte zu verschiedenen Bustechnologien und de-

ren Instanzen in der E/E-Architektur. Zusätzlich wird das Anbindungskonzept zum Systembusspezifiziert (Standard-Transceiver, Stern-Transceiver).

WIR verfeinert das TOP-Modell um Artefakte der Bordnetzentwicklung (Stecker-, PIN-Bele-gung, Kabelattribute (Signalverzögerung, Signaldämpfung)). Dazu zählt die Untergliederungphysikalischer Übertragungskanäle PCH in partielle Übertragungskanäle PCHP zur Spezifikati-on von Bussystemen mit zwei oder mehr Kabeladern und etwaige Klemmen zur Anbindung derSpannungsversorgung der Steuergeräte.

PCK verfeinert das TOP- und das WIR-Modell durch Addition vernetzungsrelevanter Aspek-te, die sich durch den Verbau der Steuergeräte im Fahrzeug ergeben. Aus Sicht des Kommunika-tionssystems interessiert dabei ausschließlich die geometrischen Abmessungen der Verbindungenzwischen den Steuergeräten aus dem TOP-Modell.

Der Zusammenhang der drei Ebenen TOP ↔ WIR ↔ PCK, lässt sich in drei Verfeinerungs-schritten darstellen:

Ebene 0:

Das Funktionsnetz wird mit einer Menge an Steuergeräten implementiert, die über einen zeit-gesteuerten Bus kommunizieren. Dabei muss mindestens ein Steuergerät aus der Menge derexistierenden Steuergeräte verwendet werden.

p : FN → P(ECU),p( f n) = ECUf n mit f n ∈ FN, ECUf n ⊆ ECU, ECUf n = ∅

Ebene 1:

Jedem Steuergerät wird eine Teilmenge der Menge an Verkabelungselementen CL (cable element)zugewiesen, welche die Verbindung zu anderen Steuergeräten repräsentiert. Dadurch wird diephysikalische Ausprägung des zeitgesteuerten Busses in der Struktur eines Baumes mit denSteuergeräten als Knoten des Graphen definiert.

q : ECU → P(CL),f n ∼ (ECUf n, CL f n, q)

Ebene 2:

Im letzten Schritt gilt es den Baum aus Ebene 2 auf ein Fahrzeugbordnetz abzubilden, wobeije nach PCK-Anforderung eine unterschiedliche Teilmenge der Segmente des Bordnetzes WS(wiring segments) für die Platzierung der Verkabelungselemente CL benützt werden müssen.

w : CL → P(WS),f n ∼ (ECUf n, CL f n, WSf n, q, w)

Da für jedes Element aus WS ein Attribut zur Beschreibung seiner geometrischen Länge existiert,


lassen sich unter anderem die exakten Bordnetzabmessungen in Abhängigkeit zur Ausprägungeines Funktionsnetzes fn und dessen Partionierung p auf dem zeitgesteuerten Bussystem ermit-teln.

�

4.2.2.8. Partitionierung

Der Partitionierungsbegriff spielt eine signifikante Rolle bei der festen Allokation der FCvon Funktionsnetzen zu Hardwarekomponenten, etwa einem Steuergerät. Das grundle-gende Problem einer Partitionierungsaufgabe ist im Bereich des Hardware-/Softwareco-designs seit einiger Zeit Grundlage wissenschaftlicher Forschung /[KL02]/. Deren Zielelassen sich dabei in verwandter Form auf die Problemstellung der E/E-Partitionierungim Fahrzeug übertragen. Anfolgend wird der Partitionierungsbegriff genauer definiert/[KL02], [PT07]/:

Definition 4.2.7 (Partitionierung) Auf Systemlevelebene wird eine zu entwickelnde Anwen-dung als Prozessgraph (task graph) dargestellt, wobei die Prozesse Knoten des Graphen darstel-len (vgl. FN). Die Knoten lassen sich in unterschiedlicher Art und Weise umsetzen mit Auswir-kungen auf nicht-/funktionale Aspekte, etwa Hardwaregröße, Ausführungszeit und Kosten.

Die gemeinsame Bestimmung der Anzahl und Art der für eine Implementierung erforderli-chen Komponenten (Register, Speicherbänke, funktionale Einheiten, Busse) wird als Allokati-on bezeichnet. Bei der Bindung (Mapping) werden diesen Komponenten Variablen, Operatio-nen und Datenkommunikationen zugeordnet. Diese Zuordnung logischer Aspekte zu Hard- undSoftwarekomponenten als Umsetzung zu einem (verteilten) System, wird allgemein als Parti-tionierung bezeichnet. Ergänzt wird der Partitionierungsschritt durch die Ablaufplanung zurAbbildung des spezifizierten Verhaltens des Systems auf diskrete Zeitschritte und -intervalle.

Das erweiterterte Partitionierungsproblem bezieht sich auf das Mehrzieloptimierungs-problem bei der Partitionierung, etwa zur Reduzierung von Hardwarefläche, Einhaltung vonZeitfristen (deadlines) im Prozess der Allokation, Bindung und Ablaufplanung.

Formal lässt sich das Partitionierungsproblem folgendermaßen charakterisieren.

Gegeben ist eine Menge von Elementen E = {e1, e2, ..., en}. Gesucht ist eine Partition P ={p1, p2, ..., pm}, so dass

p1 ∪ p2 ∪ ... ∪ pm = E,pi ∩ pj = ∅ mit ∀i, j : i = j, pi = ∅,

c(P) = min mit c(P) als Kosten für Partitionierung P.

�

Bei der Betrachtung der Partitionierung im Bezug auf eine flexible zeitgesteuerte E/E-Architektur zeigt sich eine Beschränkung auf wenige Aspekte als ausreichend (vgl.Abb. 4.14). So interessiert vorrangig die Partitionierung eines Funktionsblocks FC ausdem Funktionsnetz FN auf die verfügbaren Steuergeräte eines Fahrzeugnetzwerks. Da-bei steht die Analyse der für eine Partitionierung determinierten Sende-/Empfangsbe-ziehungen pro Steuergerät und deren Zeitanforderungen im Vordergrund. Aus Kompo-nentensicht lässt sich die Sicht auf die Inter-/Intraprozessorkommunikation innerhalb


eines Steuergeräts verfeinern. Aus Netzwerksicht reduziert sich dieser Bereich auf ei-ne Abstraktion auf die zeitlichen Mindest- und Maximalabstände bei der Bearbeitungsequentieller Signale (s. Abs. 4.2.2.5).

FunktionsblockFC1

(Sender/Empfänger)

FunktionsblockFC2

(Sender/Empfänger)



(Empfänger)


(Empfänger)

Partitionierung

Steuergerät ECU1

Prozessoreinheit

ECU1.P1

Prozessoreinheit

ECU1.P2

Steuergerät ECU2

Prozessoreinheit

ECU2.P1

Steuergerät ECU6

Prozessoreinheit

ECU6.P1

Steuergerät ECU5

Prozessoreinheit

ECU5.P1

Prozessoreinheit

ECU5.P2

Steuergerät ECU4

Prozessoreinheit

ECU4.P1

Steuergerät ECU3

Prozessoreinheit

ECU3.P1

Prozessoreinheit

ECU3.P2

FlexRay-Bus

Abbildung 4.14.: Partitionierung eines FN auf eine physikalische Netzwerkarchitektur

Die Kostenfunktion c(P) eines Partitionierungsschritts verkörpert ein mehrdimen-sionales Optimierungsproblem, dessen Eingangsgrößen sich nicht allgemeingültig ge-geneinander abwägen lassen. Beispielsweise ist von Fall zu Fall zu unterscheiden, wieder Ressourcenverbrauch in einem Steuergerät im Vergleich zum Bandbreitenverbraucheines Feldbussystems zu gewichten ist. Eine durchgehende Analyse unterschiedlicherE/E-Architekturpartitionierungsstrategien ist eine umfangreiche Aufgabe, die nicht wei-ter innerhalb dieser Arbeit verfolgt wird.

4.2.3. Konzept der dynamischen Modellanalyse

Bei zeitgesteuerten Systemen eignet sich für die dynamische Modellanalyse das Konzeptder gezeiteten Automaten. Mit dieser Formalisierung lässt sich die Systemsimulation fürsynchrone verteilte Systeme umsetzen.

Gezeitete Automaten

Gezeitete Automaten bieten die Möglichkeit zur Simulation und Verifikation verteilterEchtzeitsysteme. Durch die Option der Simulation der virtuellen globalen Zeit eineszeitgesteuerten Bussystems eignet sich dieser Ansatz, um Aspekte der Nebenläufigkeitund Synchronisation von logischen Komponenten zu verifizieren. Nachfolgend werdenSyntax und Semantik dieser formalen Notation nach /[BY04]/ erläutert:

Definition 4.2.8 (Gezeiteter Automat) Ein gezeiteter Automat A besteht aus einem Tupel〈N, l0, E, I〉 wobei

• N eine endliche Menge an Zuständen,


start

loop

end

x:=0, y:=0

10<=y<=20enter

40<=y<=50

y:=0leave

x==1

x:=0work 10<=y<=20

y:=0

starty<=20

loopy<=50

endy<=20

x:=0, y:=0

10<=yenter

40<=y

y:=0leave

x==1

x:=0work 10<=y

y:=0

Abbildung 4.15.: Beispiel für einen gezeiteten Automaten mit lokalen Invarianten /[BY04]/

• l0 der Anfangszustand,

• E ⊆ N × B(C) × ∑×P(C) × N eine Menge an Zustandsübergängen und

• I : N → B(C) eine Zuweisung von Invarianten zu Zuständen ist.

Der Ausdruck lg,a,r→ l′ bezeichnet 〈l, g, a, r, l′〉 ∈ E.

Die Menge der Variablen C aus dem Wertebereich der reellen Zahlen mit den Bezeichnern x, y, ...bildet die Uhren eines Echtzeitsystems. Das endliche Alphabet ∑ mit den Bezeichnern a, b, ...steht für ausführbare Aktionen. B(C) bezeichnet die Menge an Clock Constraints.

�

Clock Constraints: Für die Uhren existieren Vorbedingungen (clock constraints), welchedie Ausführung von Zustandsübergängen im Automaten beinflussen. Transitionen las-sen sich dabei nur ausführen, wenn der zum aktuellen Zeitpunkt anliegende Uhrenwertdie jeweils zum Zustandsübergang zugehörige Vorbedingung erfüllt. Ein Clock Cons-traint ist eine konjunktive Formel von atomaren Vorbedingungen in der Form x ∼ noder x − y ∼ n für x, y ∈ C,∼∈ {≤, <, =, >,≥} und n ∈ N. Clock Constraints dienenals Wächter (guards) für gezeitete Automaten.

Operationale Semantik: Aus Sicht der operationalen Semantik wird der gezeitete Au-tomat aus der Kombination des gegenwärtigen Zustands mit dem gegenwärtigen dis-kreten Zeitpunkt als Transitionssystem definiert. Der Automat folgt zeitlichen Verzöge-rungen auf Basis von Verzögerungstransitionen oder als Folge von aktivierten Zustands-übergängen, den Aktionstransitionen.

Veränderungen von Zeitwerten der Uhren werden über Uhrenzuweisungen (clock assi-gnments) in Form von Funktionen zum Verknüpfen von C mit nicht-negativen reellenWerten R+ realisiert. Falls u, v solche Funktionen beschreiben, dann bedeutet u ∈ g,dass die Uhrenwerte aus u den Wächter g erfüllen. Für d ∈ R+ sei u + d die Bezeich-nung für das Clock Assignment, das alle x ∈ C zu u(x) + d verknüpft und somit eineneinheitlichen konsistenten Zeitschritt definiert. Für r ⊆ C sei [r �→ 0] u das Clock Assi-gnment, welches alle Uhren in r auf den Wert 0 zurücksetzt und gleichzeitig mit u füralle restlichen Uhren in C\r übereinstimmt.

Das gezeitetes Transitionssystem beschreibt somit Zustände als Paare 〈l, u〉 mit Tran-sitionen, die nach folgenden Regeln definiert sind:


• 〈l, u〉 d→ 〈l, u + d〉 wenn u ∈ I(l) und (u + d) ∈ I(l) für eine nicht-negative reelleZahl d ∈ R+,

• 〈l, u〉 a→ 〈l′, u′〉 wenn lg,a,r→ l′, u ∈ g, u′ = [r �→ 0]u und u′ ∈ I(l′).

Der in dieser Arbeit benutzte Dialekt der gezeiteten Automaten Uppaal /[BY04]/ be-schränkt Zustandsinvarianten auf nach unten abgeschlossene Vorbedingungen in derForm x ≤ n oder x < n mit n ∈ N.

Die Aspekte der Nebenläufigkeit und Kommunikation lassen sich mittels paralle-ler Komposition von gezeiteten Automaten erreichen. Die Applikation eines parallelenKompositionsoperators ermöglicht die Interaktion zwischen Automaten und bietet einInstrument zur Nachbildung einer Hand-Shake-Synchronisation von Prozessen. Fürweiterführende Details zum Konzept der gezeiteten Automaten wird an dieser Stelleauf /[BY04]/ weiterverwiesen.

4.2.4. Parameterkonfiguration

Der Zweck der statischen und der dynamischen Modellanalyse ergibt sich durch dieHinzunahme sämtlicher Systemparameter der flexiblen zeitgesteuerten BustechnologieFlexRay. Zur Komplexitätsreduktion wird dabei eine Zerlegung der abhängigen System-parameter innerhalb unterschiedlicher Klassen erforderlich.

4.2.4.1. Klassifikation von Systemmerkmalen

Durch den mehrdimensionalen Zusammenhang des Systemparametersatzes ist eineKlassifikation zur Komplexitätsreduzierung und zu einem besseren Verständnis des Ge-samtsystems notwendig. Vier unterschiedliche Klassifikationsmöglichkeiten bieten sichan:

Funktionsebene ModellebeneElektrischer Physical Layer TopologienKodierung/Dekodierung Netzwerke

WakeUp/StartUp FunktionsnetzeFehlerkontrolle Dynamisches Verhalten

KommunikationSynchronisation

Hierarchien QualitätsmerkmaleGesamtarchitektur (Aktorik,Sensorik) Performanz

Netzwerk (Cluster) ErweiterbarkeitKomponente (ECU) Genauigkeit

Teilkomponente (CC, Transceiver) LebensdauerLogische Module (SW) Effizienz

Zuverlässigkeit

Tabelle 4.3.: Funktionsorientierte, modellierungsspezifische, hierarchische und qualitätsorien-tierte Klassifikation

Während der Systemimplementierung zeigte sich, dass nur eine Verknüpfung diver-ser Teilklassen aus allen vier Bereichen zu gleichförmig partiellen Parametersätzen führt(s. Abs. 5).


4.2.4.2. Parameterstrukturierung

Eine Strukturierung des Parametersatzes eröffnet einen ersten Schritt zur Analyse einerFlexRay-Konfiguration und zur Identifikation von Optimierungspotentialen. FlexRay-Parametersätze lassen sich nach den Restriktionen aus /[Fle05a], [Fle04b]/ berechnen.Ein allgemeiner sequentieller Vorgang zur vollständigen Berechnung der Systempara-meter ist dafür nicht explizit vorgegeben. Prinzipiell bauen die Systemparameter auf-einander auf und lassen sich linear ableiten. Allerdings lassen sich die für die System-auslegung signifikanten Parameter, etwa die Zyklus-, Segment- oder Slotlängen, durchRelationen stufenweise auf die hardwarenahen Parameter, beispielsweise die System-präzision, die Makroticklänge oder die maximale Uhrenabweichung überführen. Jedocherschwert sich der Konfigurationsprozess, da unterschiedliche Basisparameter in derRegel zu uneinheitlichen Hardwareparametern führen. In Abb. 4.16 wird die zeitlicheZusammensetzung des FlexRay-Zyklus anhand der konfigurierbaren Parameter darge-stellt.

Abbildung 4.16.: Hierarchische Darstellung der Basisparameter zur Zusammensetzung einesFlexRay-Zyklus im Zeitbereich

Zur Optimierung der Nutzdateneffizienz (s. Abs. 4.6) wird der Fokus in der Parame-terdefinition in Richtung des Bereichs „Statisches Segment“ verschoben.

4.2.4.3. Parameterberechnung

Um einen Parametersatz unter Zielkriterien vollständig berechnen zu können, ist einParametermodell erforderlich, welches die Optimierungsmethoden der Gütekriterienund extern vorgegebene Werte, beispielsweise Hardwaredaten, berücksichtigt sowie dieableitbaren Parameterwerte unter Verwendung der bedateten SYS-Modellen ermittelt.

Definition 4.2.9 (Parametermodell) Ein Parametermodell beschreibt die Abhängigkeit me-tamodellbasierter Systemdaten unter Verwendung dedizierter Algorithmik zur vollständigen,durchgängigen Berechnung individueller Systemparameter.

Bei der Klassifizierung wird zwischen Implementierungsparametern, die bei der späterenSystementwicklung identisch übernommen werden und Analyseparametern zur Ermittlung


Generalisierung/Verfeinerung zwischen PC und CB

E/E-Model1

E/E-Model2

E/E-Model1,2

Parameter Calculation Calculation Block

Model1.Artifact1

Model1.Artifact2

Model1.Artifact3

Model1.Artifactx

Model2.Artifact1

Model2.Artifact2

Model2.Artifact3

Model2.Artifactx

Model1.Artifact1

Model1.Artifactx

Model2.Artifact3

Model2.Artifactx

Temporary Data

Model Data

Model Data

Model Data

Calculation Block

Calculation Block

Calculation Block

E/E-Model1

E/E-Model2

Model1.Artifact1

Model1.Artifact2

Model1.Artifact3

Model1.Artifactx

Model2.Artifact1

Model2.Artifact2

Model2.Artifact3

Model2.Artifactx

Model Data

Model Data

Temporary Data

Temporary Data

Calculation BlockTemporary

Data

Abbildung 4.17.: Parametermodell zur Berechnung von Modelldaten/Parametern auf Basis exis-tierender Modelldaten

abstrakter Systemqualitätseigenschaften unterschieden.Das Parametermodell Ein Parametermodell PM wird durch die Grundstruktur einer Pa-

rameterberechnung beschrieben. PM rechnet auf Basis eingehender Modelldaten MD innerhalbeines oder mehreren Berechnungsblöcke CB (calculation blocks) und schreibt die Ergebnissein das Modell zurück. Eine Parameterberechnung (parameter calculation) PC wird autark ineinem oder durch Verknüpfung mehrerer CB umgesetzt. Grundlage eines CB ist die Berechnungeiner mathematischen Funktion, eines Algorithmus oder die Verfeinerung der vorgeschaltetenCB, die temporär errechnete Daten TD (temporary data) bereitstellen. Diese Datenkanäle sindunidirektional ausgeführt, um Zyklen in der Parameterberechnung auszuschließen.

PM : MD × PC → MD,mit der Kardinalität |MD| ≥ 2 und |CB| ≥ 1.

PC : CB × TD × CB → CB,mit der Kardinalität |CB| ≥ 1 und ∃d ∈ TD(|CB| ≥ 2).

�

Wie in Abb. 4.17 dargestellt bietet die explizite Modellierung der Berechnungsvorschrif-ten auf einem existierenden Datenmodell die Chance zur strukturierten, gegliedertenErfassung von Modelldaten, eine Entwicklung und Pflege von Berechnungsformeln so-wie die Rückführung in das Originalmodell. Dadurch bietet sich die Möglichkeit ei-nes idealen Roundtrip-Engineerings zur homogenen, simultanen Entwicklung der E/E-Architekturmodelle auf Basis einer flexiblen zeitgesteuerten Architektur mit ihren zu-gehörigen Parametersätzen.

4.3. METAMODELLIERUNG 155

4.3. Metamodellierung

Metamodelle bilden die Grundlage für die Entwicklung domänenspezifischer Modellie-rungskonzepte /[FHS02], [KT08]/. Nach /[Jer03]/ wird das Metamodell als explizitesModell der Konstrukte und Regeln, welche für den notwendigen Bau eines spezifischenModells innerhalb der vorliegenden Anwendungsdomäne notwendig sind, beschrieben.Konsequenterweise verkörpert ein gültiges Metamodell eine Ontologie, wobei im Ge-gensatz eine Ontologie nicht zwangsläufig als Metamodell modelliert werden muss.Allgemein lässt sich ein Metamodell aus drei Perspektiven betrachten:

1. Als eine Menge an Bausteinen und Regeln zur Konstruktion von Modellen.

2. Als ein Modell aus der Domäne des spezifischen Anwendungsgebiets.

3. Als eine Instanz eines weiteren Modells.

4.3.1. E/E-Metamodellierung

Das Konzept des verwendeten Modellierungswerkzeugs PREEvision /[Aqu07]/ fun-diert auf einem zugrunde gelegten Metamodell. Dabei handelt es sich um ein MOF-basiertes (meta object facility) /[OMG02]/ Modell, welches semantische Regeln für dieModellbildung definiert.

UML 2.0

UML 1.x

MOF

MATLABSimulink

Statechart(D.Harel)

E/E-Architecture

Timed Automata

Simulink Modell

Statechart Modell

DatenQuelltext Objekte

PN Modell

FNModell

Timed Automata

Modell

UML Modell

instantiiertbeschreibt

beschreibt

beschreibt

instantiiert

instantiiert

konkret

abstrakt instantiiertbeschreibt

Abbildung 4.18.: Metamodellierungsebenen nach dem MOF-Standard

Abb. 4.18 visualisiert anschaulich die Abstraktionsstufen beim Übergang von konkre-ten Modellen zur abstrakten Metamodellierung. Domänenspezifische Sprachen siedelnsich beim Einsatz der MOF-Semantik auf der M2-Ebene an, um Aufbau, Abhängigkeitenund Strukturen für die Modellnotation zu definieren. Aus Benutzersicht interessiert vor-rangig die M3-Ebene zur Umsetzung von erhobenen Datensätzen in zugeordnete Mo-dellartefakte. Die folgende Abb. 4.19 zeigt einen kleinen Metamodellauschnitt, indem


die Modellierung der Komponenten Aktor, Sensor und ECU beschrieben wird. Die Hier-archie definiert, dass Sensorik/Aktorik und ECU jeweils von der Klasse ElektrikElektronikerben und über spezifische Attribute verfügen (Klemmen, Kühlung, Speicher, etc.).

Abbildung 4.19.: Beispielhafter Ausschnitt aus einem Metamodell zur Beschreibung von E/E-Architekturen im Fahrzeug

4.3.2. Konzept der FlexRay-Metamodellierung

Die Spezifikation eines FlexRay-Systemdesigns differenziert sich signifikant von derbekannten Vorgehensweise im Bereich der ereignisgesteuerten Bussysteme im Bereichder CAN-Technologie. Im Detail sind präzise Einstellungen einer individuellen Ausprä-gung des Bussystems erforderlich, die in der Applizierung ein fundiertes Verständnisder Technologie voraussetzen (vgl. /[Rau07b]/). Beim Aufbau eines FlexRay-tauglichenE/E-Metamodells müssen die Teilentwicklungsschritte im Entwurf einer flexiblen zeit-gesteuerten E/E-Architektur (s. Abb. 4.20) berücksichtigt werden.

FlexRaySystem

Electrical Physical Layer

Topologien

Knoten

Komponenten

Protocol Layer

Schedule

Kommunikations-struktur

Synchronisation

AblaufkontrolleWakeUp-Verhalten

StartUp-Verhalten

Fehler-VerhaltenBedatungPackaging

Scheduling

Abbildung 4.20.: Hierarchische Dekomposition der Entwicklungsbereiche zum Systementwurf

4.4. DOMÄNENSPEZIFISCHE OBJEKTORIENTIERTE MODELLIERUNG 157

4.3.3. Bus- und Knotenparameter

Wie in Abb. 4.21 dargestellt lassen sich die Parameter in den Klassen Physical Layer, Ko-dierung/Dekodierung, Fehlerkontrolle, WakeUp/StartUp und Kommunikation gliedern. Diesentspricht der Klassifikation auf Funktionsebene (s. Abs. 4.2.4). In Tab. 4.4 werden diewichtigsten FlexRay-Parameter gemäß der Funktionsebenenuntergliederung zusam-mengefasst. Eine domänenspezifische Modellierung dieser Parametergruppen erfolgtnach Zuordnung zwischen Parametergruppe und Modellierungsebene.

FlexRayPhysical

Layer

Codierung

Decodierung

Fehlerkontrolle

WakeUp

StartUp

Kommunikation

Abbildung 4.21.: Übersicht zu den Teilbereichen der FlexRay-Technologie

In dem Zusammenhang werden die einzelnen Funktionsebenen den Modellierungs-ebenen des FlexZOOMED-Ansatzes zugeordnet. Dabei zeigt sich speziell im Kontext derphysikalischen Bitübertragung und der (De-)Codierung eine Aufsplittung über mehre-re Ebenen hinweg. Während sich das WakeUp- und StartUp-Verhalten ausschließlichmit einer dynamischen Modellanalyse (DV) untersuchen lässt, wird die Fehlerkontrollepartiell sowohl in der statischen als auch in der dynamischen Modellanalyse abgebildet.

4.4. Domänenspezifische objektorientierte Modellierung

Wie in Abschnitt 4.1.1 beschrieben, stellt sich bei der FlexRay-Systementwicklung dieFrage nach einem Lösungsansatz zur Abarbeitung mehrerer Aufgaben entlang eines se-quentiellen Prozesses. Die Grundlage des FlexZOOMED-Konzepts basiert auf der Mo-dellierung unterschiedlicher Strukturen zur Beschreibung der zu entwickelnden E/E-Architektur.

4.4.1. Konzept

Eine sinnvolle Gliederung eines FlexRay-Designs basiert auf der Dekomposition in denEbenen der physikalischen und der architekturellen Netzwerkstruktur, dem statischenFunktionsnetz, und des allgemeinen dynamischen Verhaltens eines Systems. FolgendeEbenen und deren Bedatung im Kontext der E/E-Architekturentwicklung für Fahrzeugewerden im Folgenden erläutert.


Elektrische Bitübertragungsschicht

gAssumedPrecision gChannelsgdPropagationDelayMax gdPropagationDelayMin

gdSampleClockPeriod gSyncNodeMax

(De-)Kodierung

gdBit gdBitMaxgdBitMin gdMacrotick

gdMaxMicrotick gdTSSTransmitter

WakeUp/StartUp

gdCASRxLowMax gdMaxInitializationErrorgdWakeupSymbolRxIdle gdWakeupSymbolRxLow

gdWakeupSymbolRxWindow gdWakeupSymbolTxIdlegdWakeupSymbolTxLow gColdstartAttempts

gListenNoise gNetworkManagementVector

Kommunikation

gdActionPointOffset gdCyclegdDynamicSLotIdlePhase gdMinislot

gdMinislotActionPointOffset gdNITgdStaticSlot gdSymbolWindow

gMacroPerCycle gNumberOfMinislotsgNumberOfStaticSlots gPayloadLengthStatic

Fehlerkontrolle

gClusterDriftDamping gMaxWithouClockCorrectionFatalgMaxWithoutClockCorrectionPassive gOffsetCorrectionMax

gOffsetCorrectionStart -

Parameterklasse Modellierungsebene

Physical Layer PN (TOP,WIR,PK)Kodierung/Dekodierung PN (TOP,WIR,PK)

WakeUp/StartUp DVKommunikation FNFehlerkontrolle TOP/DV

Tabelle 4.4.: Parameterzuordnung zu den Modellierungsaspekten und -ebenen

4.4.2. Statische logische Systemarchitektur

Die logische Systemmodellierung lässt sich auf die Ebenen FN und DV abbilden.

Funktionsnetze

Zwischen den Fahrzeugfunktionen werden Daten ausgetauscht, die sich als gerichteterGraph darstellen lassen. Diese Notationsform wird als Funktionsnetz (FN) bezeichnet(s. Abs. 4.2.2.3). Folgende Attribute sind dem Funktionsnetz aus Sicht einer domänen-spezifischen Modellierung zuzuordnen:

Kommunikationstypen: Darunter versteht sich das Verhalten des Informationsaus-tauschs an den Schnittstellen der kommunizierenden Komponenten. Eine gleichförmigeintervallartige Kommunikation wird als zyklisch typisiert. Diese Art erfordert zusätzlicheInformationen über deren Zyklusrate.

Ein weiterer Typ basiert auf spontaner, als sporadisch bezeichneter, Kommunikation.Auch eine hybride Form der beiden Grundtypen existiert, falls neben einem zyklischenDatenaustausch auch speziell vordefinierte Dateninhalte oder empfangene Signale eines


Abbildung 4.22.: Ausschnitt aus einem Funktionsnetz der Antriebs- und Fahrwerksdomäne

dritten Teilnehmers ein zusätzliches unmittelbares Versenden einer Information stimu-lieren. Diese Kombination kann funktional begründet sein oder in Abhängigkeit einesbestimmten Datenelements signalbedingt erfolgen.

Kommunikationsbeziehungen: Informationen können in verschiedenen Konstellationenzwischen Netzwerkkomponenten ausgetauscht werden. Eine Punkt-zu-Punkt-Kommu-nikation zwischen zwei einzelnen Knoten wird dabei als p2p bezeichnet. Eine andereVariante bildet die Broadcast-Kommunikation zwischen einer Sendekomponente und ei-ner arbiträren Anzahl an Empfängern.

Kommunikationsgruppen: Eine Untergliederung der Menge an Kommunikationsdatenin einer Architektur ermöglicht eine entsprechende Paketierung sinnvoll komponierba-rer Datengruppen. Eine klassische funktionale Untergliederung wäre bspw. eine Eintei-lung in Applikations-, Transport-, Diagnose-, Kalibrierungsbotschaften. Eine abstraktereEinteilung bringt die Dekomposition nach dem Betriebsmodus, beispielsweise Fahrzeug-betrieb und Service-/Werkstattbetrieb. Weiterhin kann es aus sicherheitsrelevanter Sichtauch sinnvoll sein in Fehler- oder Ausnahmesituationen je nach Zustand in abgestufteModi zu gehen, um Informationen entweder zurückzuhalten oder im Netzwerk zu re-plizieren. Die Ausprägung eines Modus kann temporal für bestimmte Aktivitätszeitenfestgelegt werden oder lokal auf spezielle Gebiete des Netzes bei der Signalpropagationbeschränkt bleiben.

Das Funktionsnetz ermöglicht unter Hinzunahme der domänenspezifischen Modellie-


FunktionsnetzparameterTypen Beziehungen Gruppen

sporadisch p2p Funktionzyklisch broadcast Modus temporal

hybrid funktional Modus lokalhybrid signalbedingt Zustand temporal

Zustand lokalRelevante FlexRay-Zuordnungen

Typen → Zykluslänge, SegmentierungBeziehungen → Slot Offset, Erweiterung, Paketierung

Gruppen → Slot Offset, Erweiterung, Paketierung

Tabelle 4.5.: Übersicht der Kriterien zur Attributierung eines Funktionsnetzes und der Ableitungvon grundlegendenen FlexRay-Eigenschaften

rung eine vollständige Abbildung der logischen Datenkommunikation der E/E-Archi-tektur. Ein typisiertes Funktionsnetzwerk wird in Abb. 4.22 dargestellt. Durch die Er-gänzung der Attribute in der Funktionsnetzmodellierung wird die Ableitung grundle-gender Parameter zur Scheduledefinition eines FlexRay-Clusters ermöglicht.

Bei einer Reduzierung des Funktionsnetzes auf einen Basisumfang, bestehend auseinem 3-Tupel zwischen einem Sender FCTractionManagement, einem Signal Motordreh-zahl und einer arbiträren Nummer an Empfängern, bspw. ITT_ESP, FctElectronicStability-Control, Dämpfer_Niveau, so ergibt sich im Werkzeug PREEvision die in Abb. 4.23 bei-spielhaft dargestellte Struktur. Eine instanziierte Form des typisierten Funktionsnetz-werks wird in Abb. 5.4 abgebildet.

Abbildung 4.23.: Basisstruktur eines Funktionsnetzes mit (Sender, Sendeport, Signal, Empfangsportund Empfänger)

4.4.3. Statische technische Systemarchitektur

Bei der Zuordnung der in Abschnitt 3.3.4.1 vorgestellten relevanten Aspekte für die Defi-nition der elektrisch physikalischen Bitübertragungsschicht ergeben sich eine Reihe vonZuordnungen zwischen Netzwerkkomponenten und dedizierten FlexRay-Parametern.

Physikalische architekturelle Netzwerkstruktur

Wie in 4.1 dargestellt, fokussiert der initiale Schritt der Netzwerkkonfiguration auf die


Modellierungskomponente FlexRay-Parameter Beschreibung BeeinflusstBustreiber

Netzwerkkonnektor

dBDTx dBDTx01 + dBDTx10 gdMaxPropagationDelaydBDTxia Sendeverkürzung keine Formel

(idle → active)dBDTxai Sendeverlängerung keine Formel

(active → idle)dBDRxia Empfangsverkürzung gdTSSTransmitter

(idle → active) gdWakeup-SymbolRxLow

dBDRxai Empfangsverlängerung gdCASRxLowMax(active → idle) gdSymbolWindow

Netzwerkverbindungen

Übertragungskanal

gdMinPropagationDelay gdMinPropagationDelay pDelayCompensationgdMaxPropagationDelay gdMaxPropagationDelay pDelayCompensationLineLength LineLength gdMaxPropagationDelaydBusTxia Transitionsdauer

(idle → active)dBusTxai Transitionsdauer

(active → idle)

Aktiver Sternkoppler

Komponente

dStarTruncation Signalverkürzung(Sternkoppler)

nStarPath Anzahl der SternpfadedStarSetUpDelay SetUp-VerzögerungdStarGoToSleep GoToSleep-ModusdStarWakeUpReaction WakeUp-ReaktionszeitdBranchActive BusaktivitätserkennungdBranchFailSilentIdle Timeout für Fehlerbehe-

bungdStarDelay Ausbreitungs-

verzögerungdStarAsym

´ (Negative Flanke)dStarDelay0 Ausbreitungs-

verzögerung(Positive Flanke)

dStarTxia Ausbreitungs-verzögerung(idle → active)

dStarTxai Ausbreitungs-verzögerung(active → Idle)

ECU

Komponente

pKeySlotEnabled Sync-/Coldstart-Fähigkeit

pSamplesPerMicrotick Frequenz des FlexRay-CC

pChannelspDecodingCorrection

Netzwerkzustand BeeinflusstKomponenten → gMaxSyncNodes

Teilkomponenten → cclockdeviation, gdMa-crotick

Netzwerkanbindungen →gdStarDelaySlewratesgdAsymmetricDelaygdTSSTruncation

Netzwerkverbindungen → Baudrate

Tabelle 4.6.: Zuordnung und Ableitung von Physical Layer relevanten FlexRay-Parametern zuModellierungsartefakten einer technischen Systemarchitektur

physikalische Ausprägung der Netzwerkstruktur (s. Abb. 5.7). Der strikt sequentielleEntwurf und die Bedatung der jeweiligen technischen Modellierungsebene (TOP, WIR,


PCK) muss jedoch nicht strikt eingehalten werden. Folgende Attribute und Konfigura-tionsmöglichkeiten lassen sich der physikalischen Netzwerkstruktur zuordnen:

Leitungsspezifikation: Unter der Leitungsspezifikation versteht sich die Festlegung derexakten Daten eines Leitungstyps. Dabei werden dessen physikalische Eigenschaftenberücksichtigt. Etwaige Größen basieren auf der Leitungslänge, Leitungsdämpfung undder spezifischen Ausbreitungsverzögerung.

Komponenten: In diesem Zusammenhang werden Steuergeräte als physikalische Kompo-nenten eines Netzwerks aufgefasst. Der konkrete Aufbau des Steuergeräts bleibt dabeiunberücksichtigt, da ausschließlich die Verteilung von Komponenten auf (Sub-)Netz-werke betrachtet wird.

Teilkomponenten: Zu den Teilkomponenten zählen dedizierte Hardware-Bausteine. Da-zu gehören Host-Prozessoren, Kommunikationscontroller, Quarze (inklusive entspre-chender Konfigurationen, bspw. der Frequenz für den Kommunikationscontroller desflexiblen zeitgesteuerten Bussystems).

Netzwerkanbindungen: Die Anbindung definiert den exakten Aufbau der Busschnitt-stelle einer Komponente. Dazu können Standardtransceiver und Sterntransceiver ge-rechnet werden.

Netzwerkverbindungen: Grundlegende globale Protokollparameter des Bussystems wer-den allgemein den Netzwerkverbindungen zugeschrieben. Dazu gehört vorrangig dieanliegende Baudrate für die physikalische Bitübertragung im Netzwerk.

4.4.4. Dynamisches Verhalten (Protokollebene)

Wie in /[Fle05b]/ spezifiziert, inkludiert jeder FlexRay-Kommunikationscontroller eineeinheitlich definierte Zustandsmaschine (POC) zur Steuerung des dynamischen Verhal-tens innerhalb verschiedener Betriebszustände einer Netzwerkkomponente.

Default ConfigConfig

Halt

Normal Active

WakeUp

Normal Passive

Ready

StartUp

Default ConfigConfig

Halt

Normal Active

WakeUpUp

Normal Passive

Ready

StartUp

pWakeupPattern

gColdStartAttempts

gMaxWithout-ClockCorrectionPassive

gMaxWithout-ClockCorrectionFatal

gListenNoise

vRemainingColdstartAttempts

pAllowHaltDueToClock

pAllowPassiveToActive

pSingleSlotEnabled

pdAcceptedStartupRange

pdListenTimeoutgdCASRxLowMaxgdWakeupSymbolRxIdlegdWakeupSymbolRxLow


gdWakeupSymbolTxIdlegdWakeupSymbolTxLow

Abbildung 4.24.: Mit der Protokollzustandsmaschine eines FlexRay-Kommunikationscontrollersgemappte Parameter

Ein Teil des FlexRay-Parametersatzes bezieht sich dabei direkt auf das Verhalten der


POC (s. Abb. 4.24). Zum Verständnis werden die Zustandsübergänge und deren Zusam-menhänge mit den FlexRay-Parametern erläutert.

Protokollzustand Beeinflusst

WakeUp

gListenNoisepdListenTimeoutpWakeUpPatternpWakeUpChannel

gdWakeupSymbolRxIdlegdWakeupSymbolRxLow

gdWakeupSymbolRxWindowgdWakeupSymbolTxIdlegdWakeupSymbolTxLow

StartUp

gListenNoisepdListenTimeout

gColdstartAttemptspChannels

gdCASRxLowMaxpdAcceptedStartupRangepKeySlotUsedForStartup

pKeySlotUsedForSyncpKeySlotId

pSingleSlotEnabled

Normal Active

pClusterDriftDampingpDecodingCorrection

pMacroInitialOffset[AB]]pMicroInitialOffset[AB]]

pdMaxDriftgOffsetCorrectionStartpExternRateCorrection

pExternOffsetCorrectionpRateCorrectionOut

pOffsetCorrectionOutgMaxWithoutClockCorrectionPassive

Normal Passive pAllowPassiveToActive

Halt pAllowHaltDueToClockgMaxWithoutClockCorrectionFatal

Tabelle 4.7.: Ableitungen aus der dynamischen Verhaltenssicht

Ready → WakeUp: Die physikalischen Ausprägungen des WakeUp-Patterns (WUP)beeinflussen die Dauer eines Starthochlaufs im FlexRay-Steuergerät. Dazu werdendie Längen für die Signalzustände Idle und Low für den Sender und den Emp-fänger sowie die maximal gültige WUP-Länge, bezogen auf die Anzahl der zuversendenden WakeUp-Symbole, berechnet. Auch die maximale Ausprägung desCAS-Symbols beim empfangenden Steuergerät kann in diesem Vorgang mitein-bezogen werden. Während die konkrete Ausprägung des WUP für jede Baudratestatisch festgelegt ist, gibt es Spielräume bei der Definition der Wartezeiten im Fal-le detektierter Kommunikation auf dem FlexRay-Bus beim weckenden FlexRay-Steuergerät. Über pWakeUpPattern lässt sich die Anzahl der zu wiederholendenWakeUp-Sequenzen innerhalb eines WUP parametrieren.


Ready → StartUp → Normal Active: Beim initiierten StartUp-Vorgang müssen dreizum WakeUp-Vorgang vergleichbare Parameter bedatet werden. Die Wartezei-ten vorab eines Startversuchs und bei detektierter Kommunikation auf dem Buswährend des StartUp-Vorgangs sind dabei mit den Zeiten beim WakeUp iden-tisch. Durch den Parameter gColdstartAttempts lässt sich die Anzahl der StartUp-Versuche für jedes Steuergerät clusterweit einheitlich skalieren. Während der In-tegration eines Steuergeräts im Cluster werden die Längen auftretender CAS-Symbole sowie die Abstände zwischen den detektierten StartUp-Botschaften ge-messen und plausibilisiert (gdCASRxLowMax,pdAcceptedStartupRange). Ergänzendmuss dem jeweiligen Steuergerät mitgeteilt werden, ob und in welchem Slot esStartUp- und Sync-Botschaften versendet und ob eine Einzelslotausführung oderder komplette Schedule intialisiert werden soll.

Normal Active → Normal Passive: Während der normalen aktiven Protokollausfüh-rung werden vorrangig Parameter benötigt, welche die stabile Protokollausfüh-rung und die Uhrensynchronisation beeinflussen. Zusätzlich wird der optionaleÜbergang in einen passiven Kommunikationsmodus explizit mit einem ParametergMaxWithoutClockCorrectionPassive erfasst.

Normal Passive → Normal Active: Für den Zweck einer Steuergeräteerholung nacheinem Fehlverhalten lässt sich die aktive Rückführung eines jeden Knotens in dieKommunikation im Nachgang eines passiven Zustandes optional definieren.

Normal Passive → Halt: Für den Fall, dass die Uhrensynchronisation mit einem laten-ten Fehler behaftet ist, stellt sich die Frage, ob ein Steuergerät aufgrund nicht plau-sibler Zeitwerte aus dem Cluster desintegriert werden soll. Dies lässt sich einerseitsüber einen Parameter festlegen und andererseits mit einem Zähler versehen, derdie Anzahl fehlgeschlagener Synchronisationsversuche für eine Überführung inden HALT-Zustand spezifiziert.

4.5. Entwicklungsaspekte flexibler zeitgesteuerter Architekturen

Bei der Entwicklung eines zeitgesteuerten FlexRay-Systems ergeben sich im direktenVergleich mit den CAN-basierten E/E-Architekturen einige Fragestellungen, die im Lau-fe des Systementwurfs adressiert werden müssen. Die im FlexZOOMED-Ansatz impli-zierten Aspekte verkörpern die entscheidenden Themen, die im Zusammenhang mit derFlexRay-Systemdefinition in einer Fahrzeugserienentwicklung bearbeitet werden müs-sen. Im Folgenden werden die entsprechenden Inhalte als Grundlage der später durch-geführten Systemanalysen vorgestellt.

4.5.1. Qualitätsparameter bei der Fahrzeugentwicklung

Zur Analyse der Qualität einer FlexRay-basierten E/E-Architektur ist es entscheidendsinnvolle Bewertungskriterien zu identifizieren. Dabei wird offensichtlich, dass sich dienotwendigen Untersuchungsgebiete deutlich voneinander abgrenzen. Im Bereich derFlexRay-Parametrierung entstehen jedoch Überlappungen, die aufgrund der System-restriktionen zur Generierung des FlexRay-Parametersatzes akzeptiert und beherrschtwerden müssen. Folgende Kriterien spezifizieren die Gesamtgüte einer festgelegten

4.5. ENTWICKLUNGSASPEKTE FLEXIBLER ZEITGESTEUERTER ARCHITEKTUREN 165

FlexRay-Architektur, die während der Validierung der Arbeit auch als Qualitätsparameterbezeichnet werden7.

Effizienz: In diesem Zusammenhang wird die verfügbare Nettodatenrate erfasst. Dabeimuss zwischen dem statischen und dem dynamischen Segment differenziert werden.Daher lassen sich folgende Werte erfassen:

• Verfügbare Nutzdaten pro ms,

• Verfügbare Nutzdaten pro Zyklus bei maximaler Auslastung,

• Verfügbare Nutzdaten im statischen Segment,

• Prozentuale Einordnung vom Best Case entfernt (Statisches Segment),

• Verluste im Bereich der Einpassung des Actionpoints(Buszykluslänge ↔ Makroticklänge ↔ Systempräzision).


FlexRay-Buszyklus

Zyklusstart

54673

44554

tN

etw

ork

Idle

Tim

e

Abbildung 4.25.: Nutzdateneffizienz als Gütekriterium des FlexRay-Schedules

Aussagen über die Nutzdaten leiten sich aus dem logischen Modell auf der FN-Ebeneab. Dazu müssen alle Funktionsblöcke und deren Sendebeziehungen erfasst werden.Durch die vollständige Spezifikation des Signalzeitverhaltens lässt sich die restliche Net-tobandbreite, bezogen auf den errechneten Parametersatz und der damit determinier-ten Bruttobandbreite, bestimmen. Je nach Fragestellung lässt sich die Bandbreite proZeitschritt, die Buszyklus- oder die Bussegmentlänge berechnen. Die Ergebnisse wer-den dem errechneten Optimum gegenübergestellt. 8 Einen weiteren Indikator für dieSystemeffizienz bildet die relative zeitliche Differenz zwischen angenommener System-präzision und dem Actionpoint.

7Die Qualitätsparameter dienen dem Nachweis der Tragfähigkeit des FlexZOOMED-Ansatzes, sindallerdings keinesfalls als vollständig im Bereich der FlexRay-Systementwicklung zu betrachten.

8Dabei muss berücksichtigt werden, welche minimale Anzahl statischer Slots nicht unterschritten wer-den darf, da diese Vorgabe mit der Bestimmung der optimierten Bandbreite im statischen Segment korre-liert.


Robustheit: Ein robustes FlexRay-System erfordert einerseits eine stabile hohe Qualitätdes physikalischen Übertragungssignals im Netzwerk sowie andererseits Toleranzen beider Konfiguration der Clustersynchronisation. Daraus ergeben sich folgende Qualitäts-merkmale:

• Toleranzen in der Bitlänge eines Signals (Bitlänge und Sicherheitspuffer),

• Toleranzen in der Alterung von Systemkomponenten (Quarzungenauigkeiten),

• Toleranzen bei der Skalierung des von der Präzision abhängigen Actionpoints,

• Toleranzen für die byzantische Fehlerkompensation,

• Toleranzen im Bereich der Uhrendämpfung bei der Uhrensynchronisation.

Abbildung 4.26.: Berücksichtigung physikalischer Effekte hinsichtlich der gesamten Netzwer-krobustheit

Die Signalausprägung im Netzwerk wird durch mehrere Einflüsse beeinträchtigt (Si-gnaldämpfung, -verzögerung, -verzerrung), die auf die Eigenschaften der technischenSystemarchitektur zurückgeführt werden können (z.B. Kabelimpedanz, Reflexion,Schirmung). Durch Alterungseffekte verlieren die Quarze in den Steuergeräten an Ge-nauigkeit über die Jahre. Diese Verschlechterung muss sich in der Auslegung des fürdas Gesamtsystem wichtigen Werts der Systempräzision bei der Architekturentwicklungeinkalkuliert werden (Actionpoint-Definition). Ein interessanter Wert ergibt sich aus derSpezifikation der Uhrendämpfung, die ein Driften des Clusters verhindern soll, da einhoher Wert die Gesamtpräzision des Uhrenensembles negativ beeinflusst.

EPL Erweiterbarkeit: Entscheidungskriterien in der EPL-Erweiterbarkeit beziehen sichauf eine Minimierung des Aufwandes bei notwendigen Architekturmodifikationen, et-wa der Integration eines neuen Steuergeräts, zur Konsolidierung einer gültigen FlexRay-Systemkonfiguration. Ein Qualitätsmerkmal der technischen Systemarchitektur hängt indiesem Zusammenhang von dem erreichten Grad an Flexibilität für folgende Systemein-griffe ab:

• Umpositionierung von Steuergeräten als Zwischen- oder Endknoten (Busterminie-rungskonzept),


• Maximallängen der verbauten Leitungen im Bordnetz,

• Anzahl hinzufügbarer Leitungen (pro aktiven Sternkoppler/Hinzunahme von ak-tiven Sternkopplern),

• Anzahl hinzufügbarer Netzwerknoten in verschiedenen Fahrzeugsegmenten (Vor-ne/Mitte/Hinten).

Variabliität der Leitungslängen (Typ: m)g g y

Abbildung 4.27.: Mögliche Beschränkungen im Erweiterungsbereich der physikalischen Flex-Ray-Netzwerktopologie

Je nach Systemausbaustufe und -erweiterung wird bei einem Rollentausch eines Netz-werkteilnehmers von einem Zwischen- zu einem Endknoten und umgekehrt eine An-passung des Busterminierungskonzepts in den einzelnen Steuergeräten notwendig(Wechsel zwischen hoch- und niederohmiger Terminierung). Eine Reduzierung der An-zahl an Steuergerätevarianten mit unterschiedlicher Terminierung ist dabei signifikant.Zusätzlich interessiert die Variabilität im Bereich der Ergänzung von Busleitungen unddie Beschränkung für deren Leitungslängen. Diese Fragestellungen werden dann ent-scheidend, wenn der Platz für die Positionierung im Fahrzeug in den einzelnen Verbau-bereichen nur mehr eingeschränkt verfügbar ist.

Performanz: Dieser Bereich adressiert den in der E/E-Architektur maximal unterstütz-ten Datendurchsatz pro diskreten Zeitschritt sowie die maximal zulässige Frequenz fürdie wiederholte Übertragung von Datenpaketen. Dieser Aspekt ist von Bedeutung beider Auslegung der im System zu erwartenden Antwortzeiten für die Punkt-zu-Punkt-Kommunikation. Die Performanzwerte referenzieren auf beide Übertragungssegmen-te im Buszyklus, wobei dem statischen und dem dynamischen Segment jeweils leichtunterschiedliche Fragestellungen zukommen (vgl. Abs. 4.6). Zu diesem Bereich zählenfolgende Themen:

• Antwortzeiten innerhalb des statischen Segments (Regelsystemfrequenz),

• Antwortzeiten innerhalb des dynamischen Segments (Jitter-Toleranzen bei derÜbertragung),

• Durchsatzzeiten bei der Übertragung großer Datenpakete (Steuergeräteprogram-mierung/Multimedia).



FlexRay-Buszyklus

Zyklusstart

54673

44554

t

Net

work

Idle

Tim

e

Verdrängte Botschaft

Statische Abtastratenlimitierung durch das dynamische Segment

Abbildung 4.28.: Performanzaspekte innerhalb des FlexRay-Schedules

Aufgrund strikter Echtzeitanforderungen in regelungstechnischen Systemen sind nied-rige Antwortzeiten und die damit verbundenen kurzen Busübertragungszyklen ein ent-scheidender Vorteil bei der Applikationsentwicklung von Fahrerassistenzsystemen.Während sich diese Anforderungen in der Konfiguration des statischen Bussegmentsniederschlagen, sind die Antwortzeiten und deren Jitter-Toleranzen ein wichtiges Kri-terium für die Auslegung des dynamischen Segments. Buslastspitzen dürfen nicht zuarbiträren Verzögerungen von dynamischen Botschaften führen und im schlimmstenFall die Übertragung eines Datenpakets komplett unterdrücken. Der verfügbare Da-tendurchsatz wird je nach Anwendungszweck für das jeweilige Übertragungssegmentunterschiedlich bewertet, was unter anderem von den Anforderungen im Bereich desSteuergeräteprogrammierungsvorgangs oder den zu applizierenden Multimediafunk-tionen abhängt.

Auslastung: Die Systemauslastung bezieht sich im FlexZOOMED-Konzept auf die Ei-genschaften der logischen Systemarchitektur und der damit verbundenen Ausprägungdes FlexRay-Busschedules:

• Anteil leerer FlexRay-Zellen im statischen Segment,

• Anteil leerer FlexRay-Slots im statischen Segment,

• Erfassung existierender Sender-/Empfängerbeziehungen,

• Plattform- und Variantenauslastung.

Das Interesse für die Auslastung eines FlexRay-Busschedules ist nachvollziehbar, dadiesem Wert eine vergleichbare Bedeutung zukommt wie der Buslast bei einem CAN-Bussystem. Dabei ist ein wichtiges Unterscheidungskriterium, ob die Auslastungen derFlexRay-Zellen oder der FlexRay-Slots im Buszyklus betrachtet werden9. Durch die Ana-lyse der vorhandenen Sender-/Empfängerbeziehungen lassen sich Zentren in der Netz-werkkommunikation ermitteln, was unter dem Aspekt der plattform- und varianten-

9Eventuell sind trotz leerer FlexRay-Zellen bereits alle FlexRay-Slots partiell belegt, was eine Integrationeines neuen Sendersteuergeräts verhindern würde.



FlexRay-Buszyklus

Zyklusstart

t

Net

work

Idle

Tim

e

S1R2

S3R1,R3

S2R1

S4R3

S2R1,R2,R3

S1R2

S3R2

Lee

rer

Slo

t

Lee

rer

Slo

t

Lee

rer

Slo

t

Abbildung 4.29.: Untersuchungsbereiche zur Analyse der FlexRay-Systemauslastung

spezifischen Auslastung des Bussystems eine Hilfestellung für eine sinnvolle Architek-turweiterentwicklung bietet.

Prinzipiell lässt sich die Systemauslastung nicht nur auf Busebene, sondern auchauf Steuergeräteebene, betrachten. Durch die hohe Übertragungsfrequenz können durchden Bus induzierte Spitzenlasten in der Prozessorauslastung aufgrund einer hohen An-zahl an Unterbrechungen entstehen. Beispielsweise wird eine geplante statische Entzer-rung der Kommunikation im dynamischen FlexRay-Segment beim Systemdesign nichtunterstützt. Mit einer unterbrechungsgesteuerten Detektierung eingehender Botschaftenam Prozessor wären bei unmittelbar hintereinander gesendeten Botschaften und einerNutzdatenlänge von 25Byte beispielsweise mit einem Unterbrechungszyklus am emp-fangenden Steuergerät von ca. 20μs zu rechnen.

Fehlertoleranz: Für die Betrachtung von Aspekten der funktionalen Sicherheit interes-sieren Maßnahmen, die den Grad an Fehlertoleranz auf Netzwerkebene erhöhen10.

• Vorhandene FlexRay-Kanalredundanz,

• Anzahl eingesetzter FlexRay-Sternkoppler (kanalspezifisch),

• Zeitliche und strukturelle Botschaftsreplikation,

• Fehlerreduktionsmaßnahmen (Node-Management-Vector),

• Implementierung eines (de)zentralen Buswächterkonzepts.

Sämtliche Parameter in diesem Bereich basieren auf den technisch möglichen Umsetzun-gen rund um den Bereich der FlexRay-Spezifikation. Dabei muss berücksichtigt werden,dass eine erhöhte Fehlertoleranz aus Sicht aktueller FlexRay-Serienentwicklungen nochnicht explizit gefordert wird. Daher wird in den Fallstudien dieser Arbeit lediglich deraktive FlexRay-Sternkoppler in die Untersuchungen miteinbezogen.

10Dieser Bereich ist als einfache Ergänzung zu werten. Ein vollständiges E/E-Architekturbezogenesfunktionales Sicherheitskonzept geht über den Kontext dieser Arbeit hinaus.


4.5.2. Weck- und Startvorgang

Wie in Abs. 4.4.4 beschrieben, fundiert jeder FlexRay-Knoten im Netzwerk auf dem Kon-zept einer Protokollsteuerung POC, welche sämtliche Betriebszustände des Steuergerätsam Bus bedient. Daher ergeben sich für die Entwicklung der E/E-Architektur folgendeAspekte für den Weck- und Startvorgang:

• Betriebszustände,

• Aktivitätszeiten (WakeUp-Verhalten, Teilnetze, Netzwerkmanagement),

• Systemaktivitätsmodi (WakeUp, Normal Passive),

• Systemmanagement.

Für jeden Knoten müssen die zulässigen Betriebszustände in Bezug auf die Spannungs-versorgung (Kl.15/Kl.30) definiert werden. Dazu zählen die Konzepte zur Spezifikationdes WakeUp-Verhaltens, die Zulässigkeit von partiellen Netzwerkbetrieben und das bus-übergreifende Netzwerkmanagement. Für den Ablauf der POC müssen die Zustands-übergänge und die Unterstützung optionaler Systemaktiviätsmodi, wie das aktive We-cken des Busses oder die passive Kommunikation, im Sinne eines Fehlerdegradierungs-modells bestimmt werden. POC-übergreifend gilt es ein abstraktes Systemmanagementzu konzipieren, um das Verhalten des Netzwerks clusterweit für bestimmte Systemakti-vitätsmodi festlegen zu können.

4.5.3. Komponentenarchitektur

Die eigentliche Komponentenarchitektur eines FlexRay-Knotens lässt sich logisch inForm der zugrunde gelegten Softwarearchitektur und technisch im Sinne der Hardware-Architektur unterscheiden.

• Standardsoftware,

• Spannungsversorgung (Energiemanagement).

Bei der Standardsoftware lässt sich eine feingranulare Spezifikation auf Basis der trei-bernahen Softwaremodule durchführen, was aber prinzipiell über den Umfang des E/E-Architekturentwurfs hinausgeht. Zur Vereinfachung dient hier die Unterscheidung inAspekte unterschiedlicher Softwarekonfigurationsvarianten mit spezifischen Ressour-cenverbräuchen und Performanzeigenschaften. In Bezug auf die Hardware-Architektursind neben der bereits definierten FlexRay-Kommunikationshardware (Transceiver,Kommunikationscontroller) die Spannungsversorgungskonzepte (Klemmenkonzepte,Systemstützung (DC/DC-Wandler)) für den Zweck eines erweiterten Energiemanage-ments festzulegen.

4.5.4. Verlässlichkeit

Neben den skalierbaren Fehlertoleranzkonzepten lässt sich die allgemeine Systemver-fügbarkeit durch gezielte Festlegung der Anzahl an Steuergeräten, die zur Systemsyn-chronisation beitragen oder authorisiert sind das Netzwerk kaltzustarten, beeinflussen.

• Anzahl der StartUp-Knoten,

• Anzahl der Sync-Knoten.


4.5.5. Systemschnittstellen

Als zusätzlicher Komplexitätstreiber zählt die Herausforderung der Einbettung einesflexiblen zeitgesteuerten Bussystems in eine heterogene E/E-Architektur. Dazu zählenim Detail die Konfektion feldbusverknüpfender Gateway-Architekturen im Fahrzeugsowie die Eigenschaften der Feldbustechnologien, die mit der zeitgesteuerten Bustech-nologie durch Datenaustausch interagieren.

Gateways: Ein Gateway spezifiziert in seiner Grundlage eine einfache Verknüpfung zwi-schen mehreren Feldbussystemen zur selektiven Weiterleitung von Botschaften in ver-schiedenen Subnetzwerken (Routing). Klassischerweise wird das Routing als statischeKonfiguration a priori für dedizierte Botschaften definiert, allerdings existieren auch dy-namische Routing-Verfahren (beispielsweise bei der Änderung eines Signalinhalts oderder Detektion spezieller aktiv geschalteter Funktionen. Im trivialen Fall werden die In-formationen in identischer Ausprägung, dass heißt innerhalb einer Botschaft, von einemQuellbus zu n-Zielbussen weitergeleitet. Der komplexe Fall bezieht sich auf die Neupa-ketierung von Elementen aus mehreren Botschaften in einer neu generierten zusammen-gesetzten Botschaft oder auf die Neuberechnung von weiterzuleitenden Signalinhalten,etwa bei der Filterung von Rohwerten einer Sensormessung.

CAN-Bussysteme: Der CAN-Bus weicht durch sein ereignisgesteuertes Übertragungs-konzept deutlich von den Eigenschaften eines FlexRay-Systems ab. Daher kommt es beider Interaktion zwischen CAN- und FlexRay-Systemen zu Seiteneffekten. Speziell imBereich der Sendelatenz muss diese Tatsache berücksichtigt bleiben. So bildet sich einkritischer Bereich bei der Verknüpfung im Gateway, da eine zur FlexRay-Zeit asynchroneintreffende Botschaft im Extremfall einen FlexRay-Sendeslot verpasst und konsequen-terweise mit der Verspätung von einem Sendezyklus auf dem FlexRay kommuniziertwird.

4.5.6. Globales Netzwerkscheduling

Die Herausforderung des globalen Netzwerkschedulings auf Basis eines TDMA-Netz-werkzugriffsverfahren basiert auf den Erkenntnissen des lokalen Komponentensche-duling mit einer Berechnungskomplexität aus der Klasse der NP-harten Problemen/[PPE+06], [NGH08]/.

Mit einer holistischen Schedulinganalyse wird die Propagation der lokalen Schedu-linganalysen auf verteilte Systeme und deren Interferenzen untereinander analysiert.Als eine erforderliche Basisaufgabe muss der Schedule von Betriebssystemtasks auf denSchedule eines zeitgesteuerten Systems abgestimmt werden. In diesem Zusammenhangunterscheiden sich zwei maßgebliche Designphilosophien. Für den Zweck der Entwick-lung eines vollständig deterministischen verteilten Systems müssen die in den Steuerge-räten vorhandenen Applikationen synchron zur Buskommunikation ausgeführt werden(applikationssynchrones Busscheduling). Die zweite Variante verzichtet auf eine hart deter-ministische Umsetzung der verteilten Funktionen. In diesem Ansatz werden die Bot-schaften des zeitgesteuerten Feldbussystems arbiträr innerhalb des Busschedules ver-teilt. Dadurch lassen sich keine deterministische Latenzzeiten für die Zeitkettenmodel-lierung mehr garantieren (vgl. Abs. 4.2.2.5). Stattdessen können nur noch Maximalwertefür die Übertragungszeit angeben werden, wobei bei der Botschaftsübertragung mit Jit-


tern zu rechnen ist. Diese Variante ähnelt dem Vorgehen bei der CAN-Busentwicklung,bei der die Botschaften je nach Buslast mit geringen Auswirkungen in das Gesamtsys-tem eingefügt werden können.

Das Risiko einer rein bussynchronen Applikationsentwicklung besteht in den wech-selseitigen Abhängigkeiten zwischen der Botschaftspositionierung im Schedule unddem funktionalen Softwaredesign im Steuergerät. Zur Wahrung der Flexibilität müs-sen Möglichkeiten zur zeitlichen Verschiebung von Botschaften künstlich geschaffenwerden. Dies erfolgt durch gezielte Lückenbildung zwischen den Botschaften im Flex-Ray-Schedule. Dadurch entsteht eine flexible Erweiterbarkeit an verschiedenen lokalenStellen des Busschedules. Alternativ wäre es prinzipiell möglich das Gesamtsystem miteinem verbreiterten Synchronisationsfenster im Busschedule zu versehen, welches ge-gebenenfalls später wieder verkürzt werden könnte. Dadurch wäre eine Überarbeitungder FlexRay-Parameter und damit eine zeitliche Verschiebung der Slots im Scheduleumsetzbar, was Spielraum für die Abstimmung auf Applikationsebene bringen wür-de /[Ric07]/. Dieser Ansatz setzt jedoch einen massiven Eingriff in das Gesamtsystemvoraus, der zu einem beträchtlichen Nachbearbeitungsaufwand in allen Steuergerätenführt.

Obwohl das Busscheduling den Fragestellungen des Applikationsschedulings nahekommt, müssen ergänzende Aspekte im Bereich des FlexRay-Designs beachtet bleiben/[Ric07]/:

• Abwägung beim Verhältnis zwischen einer optimierten Systemauslastung und ei-ner maximierten Systemflexibilität,

• Berücksichtigung der Aspekte einer verteilten Systemsynchronisation, der Über-und Unterabtastung im Zyklus (Multiplexstrategien) und des entstehenden Sys-temjitters bei unregelmäßigen Abständen zwischen den bedateten Sendeslots,

• Analyse der maximalen zeitlichen Schwankungen im Bezug auf applikationsasyn-chrones Busscheduling,

• Einsatz und Erweiterung des dynamischen FlexRay-Segments.

Konsequenterweise erfordert das globale Netzwerkscheduling eine ausgereifte Metho-dik für eine holistische Zeitanalyse. Dieses Thema geht im Detail über den Fokus dervorliegenden Arbeit hinaus und wird in diesem Zusammenhang initial für die E/E-Architekturentwicklung aus Sicht der FlexRay-Systemparametrierung behandelt. Spe-ziell für den Bereich des Schedulings /[HHJ+]/ etablieren sich aktuell eigenständigespezifische Werkzeugumsetzungen, die der formalen Analyse heterogener System-on-Chip-Lösungen sowie verteilter Systeme dienen. Die Grundlage dafür basiert auf derKopplung von lokalen Schedulinganalyseproblemen unter Verwendung von Ereigniss-trömen, die das Ein- und Ausgabeverhalten von Tasks mit standardisierten Ereignismo-dellen beschreiben. Die Idee in diesem Konzept fundiert auf der Adaption des Zeitver-haltens der Ereignisse im Ereignisstrom und korreliert im Ansatz mit wissenschaftlichetablierten Methoden /[BS01], [BHS99]/.

Aus Sicht der FlexRay-Systemparametrierung bezieht sich das Schedulingproblemauf die Bestimmung geeigneter Buszykluslängen, Botschaftsgrößen und Botschaftsverteilun-gen auf das statische/dynamische Segment. Die bei der Bedatung des TDMA-basiertenstatischen Segments auftretenden Fragestellungen für FlexRay im Kontext des globalen


Netzwerkschedulings werden anfolgend zusammengefasst. In diesem Zusammenhangwerden Tupel zur Abbildung der Zeitrestriktionen eingeführt (vgl. /[NGH08]/):

• Ni, die SG-ID, welche ein Signal sendet,

• Ti, die Generierungsperiode eines Signals aus den beteiligten Software-Tasks,

• Oi, der Signal-Offset einer ersten Signalinstanz relativ zum FlexRay-Zyklusstart(Oi + k ∗ Ti),

• DLi, die Signallänge in Bits,

• Ai, das Signalalter beim Empfang der dafür bereitgestellten FlexRay-Botschaft amEmpfängersteuergerät (Framepacking, Sendeprozess, Sendelatenz auf dem Bus,Empfangsprozess, Frameunpacking).

4.5.6.1. Applikationssynchrones Busscheduling

Die Idee des applikationssynchronen Busschedulings ergibt sich aus der zeitlich de-terministischen Übertragungskette zwischen den auf unterschiedlichen Steuergerätenausgeführten Applikationstasks. Dadurch eröffnet sich die Möglichkeit der Entwicklungzeitkritischer Regelsysteme, die über die Steuergerätegrenzen auf mehreren Komponen-ten verteilt ausgeführt werden (Satelliten-Koordinator-Konzept). In Abb. 4.30 wird dasZusammenspiel zwischen zwei Satellitensensoren, einem Koordinatorsteuergerät undeinem Aktuator dargestellt.

4.5.6.2. Applikationsasynchrones Busscheduling

Beim applikationsasynchronen Busscheduling besteht das Risiko, dass sich der Sende-zeitpunkt einer Sendertask durch das Driften einer Steuergeräteapplikation verschiebt,was im Extremfall zu Botschaftsverlusten führen kann (s. Abb. 4.31). Ein Angriffspunktin diesem Bereich basiert auf der Spezifikation der zyklischen Ausführungszeiten einerApplikations- und Sendetask, die jedoch aufgrund restriktiver Vorgaben hinsichtlichRechenperformanz maximiert auszulegen sind.

Die maximal zu applizierende periodische Übertragungsrate auf FlexRay orientiertsich an der Bedingung, dass die Alterung bei der Netzwerkübertragung Ai nicht die ausder Anwendung vorausgesetzte Signalaktualität Di übersteigt:

Ti = max{

2n | n ∈ N, n ≤ 6 und ∃OFRi , so dass Ai ≤ Di

}.

Die Auslastung eines einzelnen FlexRay-Slots h lässt sich über folgende Gleichung iden-tifizieren:

Wenn gilt: ∑fi∈Gh

1CRFR

i= 1, dann werden alle 64 Zyklen eines FlexRay-Slots h benutzt.

Theorem: Ein unvollständig über seine Zyklen befüllter FlexRay-Slot lässt sich bei in-krementeller Anordnung der zu verteilenden Botschaften anhand deren Übertragungs-


Static Segment Dynamic Segment NIT

t

1 2 3 ... ... n

Non-GuaranteedGuaranteed

Slot ID / Slot Number

01

5

...

234

63

Cycle Number

n+1

NM_Mot

NM_4WD

Communication Cycle

L-PDU-Identfier:Motor_2 Slot: 44 Channel: AABase Cycle: 11 Cycle Repetition: 222

TP_Anf_Diag

TP_Ant_Getr

MinislotDynamic Slot

Getr_1

Getr_1

Getr_1

Getr_2

Getr_2

Getr_2

Motor_1

Motor_1

Motor_1

Motor_1

Motor_1

Getr_1Motor_2Motor_2Motor_2

Motor_2

Motor_2

Sen_1 Koordin

TTOS_Task(Aktivate_Aktuator)

TTOS_Task(Sensor_1)

TTOS_Task(Sensor_2)

Idle_Task

TTOS_Task(x)TTOS_Task(Compute_Sensors)

TTOS_Task(x)

Satellite_1

Satellite_2

Koordinator

Aktuator_1

TTOS_Task(x)

Idle_Task

Idle_Task

TTOS_Task(x)

NM_Getr

NM_Susp

Sen_2

Idle_Task

SWIN

Abbildung 4.30.: Beispiel für synchrones Busscheduling über FlexRay (Satelliten-Koordinator-Konzept)

perioden stets vollständig befüllen.

Beweis: Falls Slot h mit einer Gruppe G an Botschaften partiell befüllt worden ist, soist für die nächste zu platzierende Nachricht k in diesem Slot mit CRk mindestens eineLücke innerhalb des Basiszyklusintervalls [0, CRk − 1] vorzuhalten.

Dies führt zur folgenden Vorbedingung und deren Umformung:

∑fi∈Gh

1CR fi

< 1

CRk − ∑fi∈Gh

CRk

CR fi

> 0 ⇒ ∑fi∈Gh

CRk

CR fi

≤ CRk − 1

und ∑fi∈Gh

CRk

CR fi

entspricht die Auslastung des Slots h durch die platzierten Botschaften

aus der Gruppe Gh im Slotzyklusintervall [0, CRk − 1] .


Static SegmentDyn. Segm., SWIN, NIT

t

1 2 ... n

Slot ID / Slot Number

01

5

...

234

63

Cycle Number

Communication Cycle

Sen_1

TTOS_Task(Sensor_1)

OS Schedule (Ni)TTOS_Task(x)

Idle_Task

Dyn. Segm., SWIN, NIT

Sen_1

TTOS_Task(Sensor_1) TTOS_Task(Sensor_1)

1 2 ... n

Sen_1

1 2 ...

TTOS_Task(Sensor_1)

Signalalter Ai

Deadline

Puffer

Signaloffset Oi

Signalperiode Ti

Abbildung 4.31.: Beispiel für asynchrones Busscheduling über FlexRay (Satelliten-Koordinator-Konzept)

4.5.6.3. Designziele

Beim Kommunikationsdesign stehen speziell bei der Implementierung des applikations-asynchronen Busschedulings buslast- und performanzoptimierende Metriken im Vor-dergrund, welche als Scheduling-Ziele angewendet werden:

1. Identifikation einer passenden Konfiguration hinsichtlich der notwendigen Signal-aktualität aller Signale (bei applikativ asynchronem Buszugriff),

2. Platzierung von synchronisierten Kommunikationstasks in Ergänzung mit syn-chronisierten Applikationstasks (bei applikativ synchronem Buszugriff),

3. Bandbreitenoptimierte Erweiterbarkeit der Busschedules,

4. Plattform- und Variantenscheduling.

4.5.6.4. Systemintegration heterogener Busschedulingkonzepte

Neben dem Einsatz rein applikationssynchroner oder applikationsasynchroner Systemeergibt sich bei der Architekturentwicklung die Fragestellung hinsichtlich der Verwen-dung gemischt synchron/asynchroner FlexRay-Anwendungen. Zur Analyse des Verhal-tens dieser heterogen ausgelegten Systeme innerhalb eines FlexRay-Clusters wird eine


Fallstudie mit folgendem Aufbau untersucht (s. Abb. 4.32).

Regler

Regelstrecke

Applikation Einkanaliges

FlexRay-Bussystem

ECU_1 dSPACE MicroAutoBox

ECU_2 V850 RapidPrototyping-Plattform

FlexRay Standard

Software Kern

… … … …

t

Abbildung 4.32.: Zwei-Knoten-Cluster zur abgleichenden Simulation von asynchronen und syn-chronen Regelung über FlexRay

Zur Vereinfachung basiert das System auf einer 2 Knoten-FlexRay-Topologie. Fürdie Analyse des Umfelds einer performanten Regelung innerhalb einer zeitgesteuertenNetzwerkarchitektur wird der praxisnahe Fall einer FlexRay-Applikation nachgebildet.Die beiden Knoten sind nach Tab. 4.8 spezifiziert:

Bezeichnung ECU1 ECU2Applikationskonzept Synchron Asynchron

Funktionsmodule Regelmodell, Regler GatewayBotschaftstiming (Cycle Offset) (μs) 1344, 3840 320, 384, 2880

Maximale Ausführzeit (μs) 1024, 1960 1480, 1536

Tabelle 4.8.: Eigenschaften der Netzwerkknoten

Signal_ECU1_Regler_IN

Signal_ECU1_Sollwert

Signal_ECU2_Model_OUT

Signal_ECU2_Regler_OUT

Signal_ECU1_Model_IN

Sollwert

Sollwert

Model_Out

Out1

Regler MABx_ECU2

Regler

PulseGenerator

In1Out1

Model MABx_ECU2

Model

In1 Out1

CANoe_SollwertIn1 Out1

CANoe_ECU1

In1Out1

CANoe _ECU1

Abbildung 4.33.: Grundlegende Reglerstruktur mit Sollwert, Regelungsblock und Regelstrecke(Modell)

Ziel dieser Untersuchung ist die Auswirkung der Task- und Busschedules in ge-mischt synchron /asynchronen FlexRay-Applikationen auf die Qualität einer PID-Re-glerumsetzung (s. Abb. 4.34). In dem Fallbeispiel wird das Regelmodell und der Regler


innerhalb einer Echtzeitumgebung mit einem Betriebssystem für harte Echtzeitanforde-rungen (OSEKtime) (ECU1) umgesetzt. Der Datenfluss zwischen der Regelstrecke unddem Regler wird dabei über das FlexRay-Cluster in einem verteilten System realisiert.Mit der Tunnelung der Daten über ein zweites FlexRay-Steuergerät mit einer vom Clus-ter entkoppelten Betriebssystemausführung (osCAN) (ECU2) entsteht die Abbildung ei-nes asynchronen verteilten Systems. Durch die asynchrone Datenverarbeitung lassensich dabei die Wechselwirkungen zwischen der asynchronen Regelung und dem zeitge-steuerten Bussystem nachweisen.

1Out1

In1

Kp

freq_dt1(Tv)

freq_int(Tn)

Out1

PIDT2

0.3915

Constant2

2.13875

Constant1

0.01

Constant

2Model_Out

1Sollwert

Abbildung 4.34.: PID2-Regelkonzept als Basis der implementierten Regelung

Während des Datenaustauschs zwischen ECU1 und ECU2 läuft in der Untersuchungeine Zählvariable in der Kommunikation mit, deren Werte im Intervall [0; 10]] verlaufenund nach einem Sollwert (0 oder 10), der von ECU2 vorgegeben wird, nachgeregeltwerden (s. Abb. 4.35).

Zeit in Samples

0 2 4 6 8 10 12 14

Reg

elw

erte

bere

ich

0

2

4

6

8

10

12 RegelstreckeApproximierter Sollwert

Abbildung 4.35.: Sollwert und darauf geregeltes Streckenmodell

In dem Zusammenhang erfolgt eine Inkrementierung der Zählvariable in ECU1 inAbhängigkeit von dem vorgegebenen Zählvariablenwert der ECU2 in einem zeitlichenAbstand von 2 Buszyklen. In Abb. 4.36 wird ein Ausschnitt über ca. 35 Buszyklen beider aktiven Regelung dargestellt.


Zeitauflösung in 5us

0 10 20 30 40 50 60 70 80

Zähl

varia

ble

0

2

4

6

8

10

12

14 ReglerRegelmodellBotschaftsverlustDelta (Regler-Reglermodell)

Zeitauflösung in 5us

0 10 20 30 40 50 60 70 80

Zähl

varia

ble

0

5

10

15

20RegelmodellReglerModell zu Regler (Asynchron)Reglerintern (Synchron)Modellintern (Synchron)Regler zu Modell (Asynchron)

Abbildung 4.36.: Auswirkungen von Botschaftsverlusten bei einer partiell asynchron ausgeleg-ten FlexRay-Systemkonfiguration

Beobachtung 1:

Es bestätigt sich, dass die Zählvariablenanpassung des Reglermodells cntModell der Zähl-variablenanpassung des Reglers cntRegler um zwei Buszyklen nacheilt. In Zyklus 37 wirdoffensichtlich, dass bei der asynchronen Systemauslegung Jitter-Effekte entstehen, die imExtremfall zum Botschaftsverlust führen (s. Abb. 4.37).

Erklärung:

Im Falles des Botschaftsverlusts springt die nacheilende Zählvariable cntModell auf denidentischen Wert von cntRegler. Auf diesen Vorgang reagiert der Regler korrekterweisezwei Buszyklen später, indem der verfrüht auftretende Wert cntModell = 10 im Buszyklus40 durch einen übersprungenen Wert cntRegler = 1 kompensiert wird. Das erklärt die Tat-sache, dass sich der Botschaftsausfall in ECU2 zeitlich versetzt auf ECU1 propagiert. Ent-scheidend für die Entwicklung zeigt sich konsequenterweise, dass die Performanz unddie Anordnung der Sende- und Empfangsprozesse im asynchronen FlexRay-Steuergerätsignifikant Einfluss auf die Funktionsweise des verteilten Systems nehmen.

Beobachtung 2:

Neben dem in Abb. 4.37 dargestellten Botschaftsverlust kommt es, wie in Abb. 4.36ersichtlich, zu einem komplementären Effekt, bei dem je nach Sende- und Empfangs-verhalten eine Botschaft zweimal gesendet wird (Wert 10 in Zyklus 27).


Zeit

Technische Komponenten

Struktur

Daten

Logische Komponenten

Konfiguration

1 2 1 2

2 3 2 3

2 3 3 4

3 4 3 4

4 5 4 5

4 5 5 6

6 7 5 6

Regler.In Regler.Out Modell.In Modell.Out

Zyklus 0

Zyklus 1

Zyklus 2

Zyklus 3

Zyklus 4

Zyklus 5

Zyklus m

2

3

4

4

5

6

6

Zyklus n

Abbildung 4.37.: Rekonstruktion des ermittelten Botschaftsverlust bei der Übertragung von Bot-schaften am asynchronen FlexRay-Steuergerät

Erklärung:

Aus dem doppelten Sendevorgang lässt sich schließen, dass speziell die Sende-Task miteinem Jitter behaftet ist. Durch das Driften der Steuergeräteapplikation gegenüber derBuszykluszeit werden die empfangenen Werte aus Slot 65 in Zyklus x partiell bereits inSlot 5 in Zyklus x+1 auf dem Bus weiterversendet. Falls die Applikation stärker nacheiltwird die Sendetask erst nach Slot 5 in Zyklus x+1 beendet und die Information folglicherst in Slot 5 in Zyklus x+2 verschickt. Das Nacheilen wird in Abb. 4.36 durch den Wert2 gekennzeichnet und ein Botschaftsverlust durch den Wert 111.

Fazit:

Insgesamt lässt sich nachweisen, dass ein regelungstechnisches System mit bussynchronablaufenden Applikationen deterministisch auf ein zeitgesteuertes verteiltes System ab-gebildet werden kann. Zum Bus asynchron laufende Applikationen bergen jedoch dasRisiko, dass Seiteneffekte zu Botschaftsverlusten oder -wiederholungen führen, welchesich signifikant auf die Regelungsergebnisse auswirken. In der dargestellten Fallstudiewirkt sich die Problematik dadurch beispielsweise auf die Quantisierungsstufen in derRegelung aus (alle ungeraden Werte zwischen 1 und 10 werden nicht mehr abgebildet).

11Die Werte sind in Betragsform angegeben. Das bedeutet, dass die Datenweiterleitung im Regler-Modellbei Fehlern mit den Werten 1 und 2 versehen wird. Die modell- und reglerinterne Inkrementierung erfolgtdagegen innerhalb der synchronen Applikation der ECU1 und ist fehlerfrei.


4.6. Optimierung im Systementwurf

„The First Rule of Program Optimization: Don’t do it. The Second Rule of ProgramOptimization (for experts only!): Don’t do it yet.“ - Michael A. Jackson

In diesem Kapitel werden Potentiale hinsichtlich der Einstufung und Bewertung vonFlexRay-Konfigurationen dargestellt. Dabei lassen sich Aspekte eines optimierten Ein-satzes der Technologie zur Applizierung in einer gegebenen E/E-Architektur aufzeigen.

4.6.1. Optimierungsziele in flexiblen zeitgesteuerten Architekturen

Aus Sicht der Netzwerkspezifikation muss beim Entwurf einer verteilten zeitgesteuertenSystemarchitektur ein heterogenes Feld an Designanforderungen (s. Abb. 4.38) berück-sichtigt werden /[BMG07]/.

Leistung: Ein gemischt zeit-/ereignisgesteuertes Konzept erfordert ein gezieltes Erfas-sen von minimalen Abtastraten einer zyklisch zeitgesteuerten Kommunikation. DieseEinschränkung beeinflusst die Länge von Kommunikationszyklen und deren Slotver-waltung für die Inter- und die Intrakommunikation eines Mikrocontrollers.

Integrierbarkeit: Für einen langlebigen Systemeinsatz mit zusätzlichen Systemintegra-tionsaufgaben müssen Bandbreitenanteile auf Buskommunikationsebene vorgehaltenwerden. Da sich verschiedene Abschnitte eines Kommunikationszyklus unterschiedlichklassifizieren lassen und ein Vorhalt mit unterschiedlichen Konzepten erzeugt werdenkann (Multiplexing, Botschaftsvervollständigung, Reserveslots), gilt eine Integrations-strategie als hochkomplex.

Systemmanagement: Das Aktivitätsmanagement eines Busses, basierend auf der Kon-figuration jedes einzelnen Teilnehmers, hat Einfluss auf das Buskommunikationsdesign.Welche Knoten eine Coldstart- oder ein Sync-Fähigkeit erhalten ist entscheidend. Opti-mierungsziele basieren auf niedrigem Energieverbrauch und geringer Fehleranfälligkeitwährend kritischer Betriebsphasen des Systems (StartUp/ShutDown).

Plattformkonzept: Kommunikationsbeziehungen auf Netzwerkebene werden in platt-form- und knotenspezifische Anteile zusammengefasst. Die Idee der Slot- oder Signal-klassifikation in Bezug auf Applikationsdomänen muss diesbezüglich berücksichtigtwerden.

Datendurchsatz: Neben der Leistungsbetrachtung für performante Abtastraten auf Bus-kommunikationsebene interessiert vorrangig eine effiziente Bandbreitenvergabe mit ho-her Nettodatenrate. Dazu zählt auch die Anforderung eines schnellstmöglichen Ver-sendens von größeren Datenpaketen für die Zwecke einer performanten Steuergerä-teprogrammierung (z.B. bei der Bandendeprogrammierung). Die Systemstabilität und-robustheit muss dabei garantiert bleiben.

Topologien: Eine Modifikation eines Steuergerätenetzwerks in der technischen Syste-marchitektur erfordert in der Regel eine Neubewertung der physikalischen Ausprägungder Netzwerktopologie. Veränderte Leitungslängen oder das Einfügen von aktiven oder

4.6. OPTIMIERUNG IM SYSTEMENTWURF 181

Fct

FctFct

Fct Fct

Fct

FctFct

FctFct

Fct

FctFctFct

FctFct

Par

titi

onie

run

g

(Sub-)Funktionen(Applikationsebene)

OS-Schedule (Knotenebene)

Wechselseitige Designeinflüsse (Applikationsebene, Kommunikationssystemebene)

- Leistungsanforderungen (Verteilte Funktionen)

- Integrationsanforderungen (Komponentenintegration)

- Systemmanagement (StartUp-Verhalten, Aktivitätszeitpunkte)

- Plattformanforderungen (plattformspezifisch, komponentenspezifisch)

- Datendurchsatz (Diagnose/Knotenmanagement, Programmierzeiten)

- Topologieanforderungen (Kabelbaum)

- Komponentenverwendung (Hard-/Software-Spezifika)

- Zuverlässigkeitsanforderungen (Alterungseffekte, Sicherheitslevel)

Buskommunikationszyklus (ca. 5ms (max. 16ms))

Abbildung 4.38.: Wechselseitige Abhängigkeit zwischen den allgemeinen Anforderungen aneine Systemarchitektur und einem FlexRay-Systemdesign

passiven Sternkopplern erzeugen Effekte im Bezug auf das Zeitverhalten des verteil-ten Systems. Daher müssen Strategien für zweckgebundene Modifikationen an techni-schen Systemarchitekturen mit flexiblem zeitgesteuerten Kommunikationssystem erar-beitet werden.

Komponentenverwendung: Normalerweise besitzt jede Hardwareeinheit (z.B. Transcei-ver oder Kommunikationscontroller) Einschränkungen in ihrem Anwendungsspektrum.Es müssen Restriktionen hinsichtlich der Konfigurierbarkeit von Spezifikationsparame-tern, der spezifischen Pufferhandhabung, den Kodierungs- oder Dekodierungseigen-schaften oder für den Arbeitstemperaturbereich beachtet werden, welche den Zielraum


für Systemlösungen limitieren.

Zuverlässigkeit: Der Gebrauch von Kommunikationssystemen und die mit der Nutzungverbundene Kritikalität in Bezug auf die Benutzersicherheit erfordert eine gesonderteBetrachtung (vgl. Abs. 2.3.5).

4.6.2. Systemqualität

Die Erfassung der Qualitätseigenschaften einer flexiblen zeitgesteuerten Architektur istzum aktuellen Zeitpunkt nicht als Standard definiert. Daher empfiehlt sich in ersterInstanz eine Orientierung an etablierten Standards von verwandten Entwicklungsbe-reichen, beispielsweise dem ISO9126-Standard für Software-Qualität /[Int91]/ (s. Abb.4.39). Eine Betrachtung der Hauptmerkmale lässt sich in mehreren Punkten auf eineflexible zeitgesteuerte und verteilte Architektur mit hohen Performanzansprüchen über-tragen:

Abbildung 4.39.: Allgemeine Systemqualität nach dem ISO9126-Standard

Funktionalität: Aus Sicht der E/E-Architektur bezieht sich dieser Aspekt auf die Kom-ponentenkonfiguration im Netzwerk und deren Kommunikationsprofil. Sämtliche zuverbauende Halbleiterkomponenten, ausgehend von Kommunikationscontrollern undTransceiver-Architekturen (aktive Sternkoppler) bis hin zu Bauteilen wie Oszillatorenund Konzepte aus der Schaltungstechnik (PLL, Clock Tree), müssen bei der Systemin-tegration berücksichtigt werden. Das Kommunikationsprofil entsteht aus den umzuset-zenden Abtastraten, die sich aus den zu entwickelnden regelungstechnischen Systemenableiten lassen, unter Berücksichtigung der quantitativen Ausprägung dieser zu über-tragenden Daten. Entscheidend muss dabei auch das Thema aller potentiellen Kom-munikationsbeziehungen n : m im Netzwerk beachtet werden. Speziell das Thema In-teroperabilität wird im Zusammenhang mit FlexRay zwischen den Fahrzeugherstellernanalysiert /[RMBK07]/.

Zuverlässigkeit: Da zeitgesteuerte Bussysteme konzeptionell für den Einsatz in sicher-heitskritischen Systemen entwickelt worden sind, stellt sich die Frage nach einer korrek-ten Umsetzung der skalierbar einzusetzenden Fehlertoleranzmechanismen. Diese erge-ben sich bei FlexRay durch den optional implementierbaren redundanten Datenkanal,die abgestuften Fehlerbehandlung auf der Protokollebene POC, den NM-Vektor in den


Nutzdaten und die verteilte Synchronisation. In abgestufter Form stellt sich die Fragenach Wiederherstellbarkeit bei Fehlerzuständen (Recovery Mechanismen), beispielsweisenach byzantinischen Fehlern oder bei Datenverlust auf dem Kommunikationsmedium.Als eigenständiges Thema muss die Anforderung hinsichtlich der angestrebten Lebens-dauer des Systems unter Berücksichtigung eventueller Alterungseffekte innerhalb ver-bauter Komponenten behandelt werden.

Benutzbarkeit: Der Einsatz von flexiblen Kommunikationsmechanismen im Rahmenvon Multiplexing auf Zyklus-, Slot-, oder Pufferebenen erschwert die Anbindung undInterpretation innerhalb softwaretechnischer Anbindungen. Auch eine Ergänzung derFlexibilisierung mithilfe von logischem Multiplexing auf Botschaftsebene erhöht dieKomplexität bei der Applikationsverknüpfung im Steuergerät und senkt den Grad anVerständlichkeit des gesamten Kommunikationskonzepts des Systems.

Effizienz: Die Systemeffizienz überträgt die Anforderungen aus dem Funktionalitätsbe-griff, indem erstellte Kommunikationsprofile in eine effiziente Bedatung des Bussystemsumgesetzt werden. Eine Herausforderung dabei liegt in der sinnvollen Verteilung vonSignalen in den unterschiedlichen Buszyklen des Schedules sowie einer geeigneten Wahlvon Zykluslänge und Multiplexing.

Änderbarkeit: Starre Konzepte bei der Implementierung von Bussystemen erzeugen inder Regel hohe Kosten bei der Gesamtsystementwicklung im Bereich der Wiederaufbe-reitung und Weiterverwendung (Reengineering) von Einzelkomponenten oder -modulen.Daher muss der Wunsch nach simplen Modifikationen im Zusammenhang mit Kom-munikationserweiterungen oder bei Adaption der Sendeeigenschaften, beispielsweisedurch Veränderung von Empfängeradressen oder Zykluszeiten, pragmatisch umsetz-bar bleiben. Massive Eingriffe durch Austausch kompletter Komponenten (Steuergeräte)sollten unter Berücksichtung von Kompatibilitätsanforderungen realisierbar bleiben.

Übertragbarkeit: Unter Übertragbarkeit versteht sich aus E/E-Architektursicht einer-seits der Austausch von Komponenten im Entwicklungszyklus einer Fahrzeugbaureiheals auch die Möglichkeit der Plattform- und Variantenbildung auf Funktions-, Software-und Hardwareebene.

4.6.3. Grundlagen der mathematischen Optimierung

Das Gebiet der mathematischen Optimierung gilt als weitläufiger eigenständiger For-schungsbereich. Daher beschränkt sich dieser Abschnitt auf die wesentlichen Elemen-te zum Verständnis der anfolgend entwickelten Lösungen im Rahmen des FlexRay-Systemdesigns. Für eine weitere Vertiefung der adressierten Methoden und zum all-gemeinen Überblick wird auf einschlägige Literatur weiterverwiesen /[Lue97], [Alt02],[BV04]/.

Definition 4.6.1 (Optimierungsproblem) Sei D ⊂ Rn eine offene Menge f : D → R

und F ⊂ D. Dabei stellt sich das Problem, die Funktion f auf F zu minimieren in der Formminx∈F f (x). f wird in dem Zusammenhang als Zielfunktion, F als zulässige Menge und dieElemente x ∈ F als zulässige Punkte bezeichnet. Wird die Menge F durch Nebenbedingungen(Restriktionen) beschränkt, so bezeichnet minx∈F f (x) ein restringiertes Optimierungspro-


blem (OP). Die Menge F wird dabei durch Gleichungen und/oder Ungleichungen definiert.

�

Die im Kontext der FlexRay-Parametrierung entwickelten OP basieren auf eigens entwi-ckelten Zielfunktionen. Sie definieren eine Abbildung aus einem Vektorraum V in einenZahlenkörper K. Der Vektorraum wird dabei individuell für jede Zielfunktion über dienotwendig zu betrachteten FlexRay-Parametrierungsregeln gebildet. Daher werden dieOP als Funktionale aufgefasst. Bei der Suche nach der Lösung eines OP stellt sich ne-ben der Frage nach der Existenz einer Lösung für das OP auch die Frage nach derEindeutigkeit einer gefundenen Lösung. Nach /[BV04]/ korreliert die Eigenschaft einereindeutigen Lösung mit den Konvexitätseigenschaften der Zielfunktion des betrachtetenOP.

Definition 4.6.2 (Konvexitätseigenschaft) Die Menge C ⊂ Rn heißt konvex, falls für belie-bige Punkte x, y ∈ C gilt

{(1 − t)x + ty|0 ≤ t ≤ 1} ⊂ C.

Für die Verbindungsstrecke

[x, y] := {(1 − t)x + ty|0 ≤ t ≤ 1} ,

gilt [x, y] ⊂ C. Der Konvexitätsbegriff lässt sich übertragen auf die Zielfunktion f : D → R mitD ⊂ Rn und D ⊂ C mit C als nichtleere, konvexe Menge, wobei gleichermaßen folgt

f ((1 − t) ∗ x + t ∗ y) < (1 − t) ∗ f (x) + t ∗ f (y)für alle x, y ∈ C und t ∈ [0, 1].

�

Ergänzend zu den Konvexitätseigenschaften der Zielmenge und des Zielfunktionals ei-nes OP, ist es entscheidend Aussagen über deren Stetigkeit formulieren zu können. Dieserfolgt per Analyse des vorliegenden Funktionals auf Differenzierbarkeit. Dabei mussbeachtet werden, dass das vorliegende Funktional Einschränkungen aufweist, etwa mitSprungstellen in seinem Wertebereich. Die Unterscheidung und Abgrenzung passenderDifferenzierbarkeitsbegriffe werden aus /[Lue97]/ übernommen und anfolgend defi-niert.

Definition 4.6.3 (Gateaux-Ableitung) Sei X ein Vektorraum und x ∈ D ⊂ X, h sei freiwählbar in X. Wenn der Grenzwert

∂T(x; h) = limα→0

1α[T(x + α ∗ h) − T(x)]

existiert, heißt dieser Grenzwert Gateaux-Ableitung der Transformation T an der Stelle x mitRichtung h. Wenn dieser Grenzwert für alle h ∈ X existiert, dann heißt T Gateaux-differenzier-bar an der Stelle x.

�


Das als Richtungsableitung bezeichnete Gateaux-Differential lässt sich weiter verstärken,falls es sich bei X um einen normierten Vektorraum handelt. Dieser stärkere Differen-zierbarkeitsbegriff bezieht sich auf die Frechet-Ableitung.

Definition 4.6.4 (Frechet-Ableitung) Sei T eine Transformation, die auf einer offenen MengeD in einem normierten Raum X mit Wertebereich im normierten Raum Y definiert ist. Existiertfür ein festes x ∈ D und alle h ∈ D ein bezüglich h stetiger und linearer Grenzwert ∂T(x; h) ∈Y, so dass

lim‖h‖→0

‖T(x + h) − T(x) − ∂T(x; h)‖‖h‖ = 0

gilt, dann heißt T Frechet-differenzierbar an der Stelle x. ∂T(x; h) bezeichnet dabei das Frechet-Differential von T an der Stelle x in Richtung h.

�

Der nachfolgend beschriebene Zusammenhang zwischen Gateaux- und Frechet-Differ-enzierbarkeit wird aus /[Lue97]/ übernommen und aus Gründen der Vollständigkeithier aufgeführt. Für den Beweis wird auf /[Lue97]/ weiterverwiesen.

Satz 4.6.5 Wenn das Frechet-Differential von T an der Stelle x existiert, dann existiert auch dasGateau-Differential an der Stelle x und beide stimmen überein.

Sämtliche hiermit definierten Grundlagen erweisen sich als notwendig in der Analyseder im nächsten Abschnitt entwickelten Funktionale in Bezug auf die Optimierung vonFlexRay-Systemparametrierungen. Im Folgenden werden potentielle Optimierungsmög-lichkeiten von FlexRay-Systemkonfigurationen vorgestellt.

4.6.4. Optimierungsprobleme in FlexRay-Parametersätzen

Die Festlegung der Werte für einen FlexRay-Parametersatz erfolgt nach den Berech-nungsvorschriften der FlexRay-Spezifikation /[Fle05a]/. Diese setzen sich im Wesentli-chen aus einer Vielzahl an Ungleichungen und Gleichungen zusammen, welche aufein-ander aufbauen. Die Parameter definieren dabei sämtliche Konfigurationsaspekte zurEtablierung einer stabilen Netzwerkkommunikation unter den gegebenen Randbedingun-gen, etwa den konkreten gegebenen physikalischen Topologieausprägungen und den dedi-zierten Hardwareeigenschaften oder in abstrakter Form, beispielsweise über die Festlegungder bevorzugten Botschaftsgröße und Slotanzahl im statischen Segment.

Allgemeine Gütekriterien oder Kennzahlen eines für den Anwendungszweck opti-mierten Parametersatzes in einems Fahrzeugserienprojekt werden in /[Fle05a]/ nichtadressiert. Ein analoges Dokument zu /[Fle06b]/, einer Ergänzung der Spezifikati-on für die physikalische Schicht /[Fle04b]/, ist seitens des FlexRay-Konsortiums nichtstandardisiert entwickelt worden. Konsequenterweise wird die FlexRay-Technologie in-nerhalb dieser Arbeit hinsichtlich allgemeiner Gütekriterien analysiert und die iden-tifizierten Aspekte formalisiert. Auf Basis der beiden Grundspezifikationen /[Fle04b],[Fle05a]/ lassen sich in Ergänzung mit /[Rau07b]/ für Ebenen der physikalischen Über-tragungsschicht und der Protokollschicht folgende Gütekriterien identifizieren, die eszu optimieren gilt. Folgende Optimierungsbereiche beziehen sich auf die elektrischeBitübertragungsschicht:


Flexibilität: Unter Flexibilität versteht sich eine topologisch modular auslegbare Busar-chitektur, in der bestenfalls alle Permutationen einer gegebenen Steuergerätemen-ge ohne Modifikationen im Hard- und Softwarebereich realisiert werden können.Eine Vermeidung von Variantenanfertigungen für verschiedene Fahrzeugderivatestellt einen signifikanten Kostenvorteil in der Serienproduktion dar.

Erweiterbarkeit: Als Verschärfung des Flexibilitätsbegriffs gilt es die Integration neuerSystemkomponenten (ECUs) ohne Adaptionsaufwand der existierenden Lösun-gen zu berücksichtigen. Speziell die Erweiterbarkeit an verschiedenen Stellen desverbauten Bordnetzes erfordert eine Beachtung hardwarespezifischer Effekte, et-wa der Oszillatorqualität oder der Transceivereigenschaften.

Robustheit: Die Funktionstüchtigkeit der Busarchitektur in verschiedenen physikali-schen Grenzbereichen wird durch die Robustheit ausgedrückt. Temperatureinflüsseund Alterungsprozesse wirken dabei speziell als temporaler Einfluss durch eineVeränderung der Systemgenauigkeit.

Für die Protokollebene ergeben sich folgende Optimierungsbereiche:

Nutzdatendurchsatz/Zeiteinheit: Dieses Gütekriterium zielt auf die Bewertung desNetto-Nutzdatenanteil der über FlexRay übertragenen Daten bezogen auf ein be-stimmtes Zeitintervall (Makrotick, Slot, Buszyklus) (Nutzdateneffizienz). Diese Wertbezieht sich ausschließlich auf die Konfiguration des statischen FlexRay-Segments.

Übertragungslatenz/Sendeauftrag: Durch die ereignisgesteuerten Eigenschaften desdynamischen FlexRay-Segments stellt sich die Frage nach einem anwendungskon-formen Verhältnis zwischen der maximalen Übertragungslatenz eines Sendeauf-trags, etwa bei Burst-Zuständen im System, und der dafür notwendigen zeitlichenAusprägung des dynamischen Segments (Dynamisches-Segment-Layout).

Netzwerkruhephasen/Zeiteinheit: Durch das dynamische FlexRay-Segment, das Sym-bol-Fenster und die Netzwerkruhephase kommt es zu einer periodischen Unter-brechung des statischen Segments mit einer statisch festlegbaren Dauer. Eine Re-duktion dieser Dauer ermöglicht eine Aussage über die maximal abbildbare Ab-tastrate für zyklische Signale in Botschaften des statischen Segments.

Resynchronisationsphasen/Zeiteinheit: Die Netzwerkruhephase dient der Korrekturder Offsets der jeweiligen Uhren der im Cluster integrierten FlexRay-Knoten. Diezeitliche Länge der Netzwerkruhephase korreliert dabei auch mit der maximalmöglichen Korrektur des Offsets einer lokalen Zeit des FlexRay-Steuergeräts. Kon-sequenterweise bildet die statisch festgelegte Netzwerkruhephase durch das limi-tierte Intervall zur Offset-Korrektur auch eine Grenze für die maximal tolerierbareAlterung der Steuergeräteoszillatoren. Dadurch wird gleichermaßen die maximaleLebensdauer eines FlexRay-Systems mit einer dedizierten Parameterkonfigurationdediziert.

Aufstartdauer: Das Aufstartverhalten des FlexRay-Clusters und dessen Dauer hängtvon mehreren Parametern ab. Ziel ist diese Ablaufsequenz mit der bestmöglichenEffizienz und Zuverlässigkeit für eine E/E-Architektur zu konfigurieren.


Neben den reinen bussystemspezifischen Aspekten interessieren auch die nachfolgendbeschriebenen netzwerkübergreifenden Optimierungsbereiche:

Schedulability: Je nach Anforderung an das Clustern von Botschaften in einem Flex-Ray-Zyklus innerhalb des statischen Segments kann es zu Einschränkungen inder Generierung eines passenden Schedules für das Senden und Empfangen derBotschaften auf Betriebssystemebene eines Steuergeräts kommen. Ein geeignetesSchedulelayout muss diese Einschränkungen a priori als Restriktionen in der Bot-schaftsverteilung berücksichtigen.

Innerhalb dieser Arbeit haben sich die Gütekriterien auf der Protokollebene als kom-plexe Optimierungsprobleme dargestellt, die aus mathematischer Sicht nicht mehr sta-tisch sondern mit numerischen Verfahren zu lösen sind. Die Fragestellungen im Be-reich der Protokollkonfiguration erweisen sich dabei verstärkt unabhängig von exter-nen Einflüssen im Vergleich zu den vorhandenen Gegebenheiten bei der physikalischenÜbertragungsschicht im Bordnetzdesign (EMV, Energiemanagement, Verbauorte, Kabel-baumdesign, Steuergerätehardware, etc.). Speziell die Qualitätsgröße Nutzdateneffizienzin Kombination mit der Analyse des Nutzdatenvolumens im statischen Segment sowie dieDimensionierung des dynamischen Segments zur Garantie gegebener maximaler Über-tragungslatenzen von Botschaften sind im Rahmen von /[Mai08]/ intensiv untersuchtworden. Im Folgenden werden die entwickelten Ergebnisse zusammengefasst.

Im Rahmen einer optimierten FlexRay-Protokollauslegung wird die Konfigurationdes Schedules hinsichtlich seiner Effizienz im Bereich der pro Zeiteinheit verfügbarenNettonutzdatenrate untersucht. In /[Mai08]/ werden unterschiedliche Optimierungsal-gorithmen appliziert, um einerseits zweckmäßige Botschaftsgrößen im statischen Seg-ment des Schedules abzuleiten und zusätzlich eine ideale Größe des optionalen dyna-mischen Segments zu berechnen.

4.6.4.1. Formalisierung des Optimierungsbereichs „Statisches Segment“

Im Folgenden werden die erschlossenen Optimierungsbereiche formalisiert, um daraufaufbauend numerische Lösungsverfahren anzuwenden. Eine vollständige Formalisie-rung aller Optimierungskriterien impliziert umfangreiche Fragestellungen, welche füreine Lösungsfindung detailliert analysiert werden müssen. Konsequenterweise wird indieser Arbeit lediglich eine Untermenge der identifizierten Optimierungsbereiche aus-führlich untersucht. Der Fokus soll in dem Kontext auf die Themen Nutzdateneffizienzund Dynamisches-Segment-Layout beschränkt bleiben.

OP: Datendurchsatz (Nutzdatenvolumen Nv(x) und Nutzdateneffizienz Ne(x))

Der Begriff Nutzdateneffizienz erlangt seine Relevanz durch die a priori festzulegendestatische Aufteilung der Netzwerkbandbreite im statischen FlexRay-Segment. Wie inAbb. 4.40 dargestellt, gilt es bei der Parameterfestlegung für eine E/E-Architektur einenhohen Anteil an reinen Nutzdaten im statischen Segment eines Zyklus zu generieren(Nettodatenrate).

Die Dauer des statischen Segments und eines Slots im statischen Segment wird durcheinige in Abs. C.4 aufgeführte Restriktionen bestimmt. Die Nutzdateneffizienz basiertdabei auf dem im statischen Segment vorrätigen Nutzdatenvolumen innerhalb eines


Abbildung 4.40.: Zusammenhang zwischen Nutzdaten-, Botschafts-, Slot-, und statische Seg-mentlänge eines FlexRay-Zyklus

FlexRay-Buszyklus. Dieses Nutzdatenvolumen lässt sich folgendermaßen auffassen12:

NutzdatenStatischesSegment =LangeStatischesSegment

LangeSlots∗ NutzdatenSlot

Entsprechend müssen die Berechungsformeln (Restriktionen) aus /[Fle05a]/ zur Berech-nung der Länge eines statischen Slots und des statischen Segments herangezogen wer-den. Durch Umformungen ergeben sich folgende Definitionen13:

Definition 4.6.1 (Länge des statischen Segments) Sei LSegment : X → Y eine Abbildung.Dabei gelte X ⊂ R7 und Y = R . Dann ist

LSegment(x) := x9 − α2 ∗ (x18 + ceil((α1 + α5)

(x7 ∗ (1 − c6)))) − x10 − (x4 − x18)

− 2 ∗ x4 − ceil((x1 + c14 + c5) ∗ (c4 ∗ x3 ∗ (1 + c6)) + α4 + α1 + α3

x7 ∗ (1 − c6))

die Länge des statischen Segments.

�

Definition 4.6.2 (Länge eines Slots im statischen Segment) Sei LSlot : X → Y eine Ab-bildung. Dabei gelte X ⊂ R5 und Y = R. Dann ist

LSlot(x) = 2 ∗ x4 + ceil((x1 + c1 + c2 + 20 ∗ x2 + c3 + c5) ∗ (c4 ∗ x3 ∗ (1 + c6)) + α1 + α3

x7 ∗ (1 − c6))

die Länge eines Slots im statischen Segment.

�

Der Nutzdatengehalt einer Botschaft im statischen Segment wird durch die Variable x2in der Einheit [Two-Byte-Words] beeinflusst. Zur Bestimmung des Nutzdatengehalts imBezug auf die Zeiteinheit [μs] muss x2 mit 16 ∗ c4 ∗ x3 multipliziert werden. Einsetzender Formeln LSegment(x), LSlot(x) und die Adaption von x2 liefert das NutzdatenvolumenNv(x) in Abhängigkeit zur Einheit [μs] im statischen Segment:

12Eine graphische Analyse dieses Zusammenhangs ist im Anhang A aufgeführt.13Für die relevanten FlexRay-Parameter werden im Anhang C Abkürzungen eingeführt. Die Umfor-

mungen basieren auf den Restriktionen aus /[Fle05a]/ und werden in /[Mai08]/ detailliert beschrieben.


Nv(x) =LSegment(x)

LSlot(x)∗ 16 ∗ c4 ∗ x3 ∗ x2

Die Nutzdateneffizienz Ne(x) lässt sich als Nutzdatenvolumen pro zeitliche Länge in-terpretieren:

Ne(x) =Nv(x)

x7 ∗ LSegment(x)

führt mit der Substitution des aufgestellten Nutzdatenvolumens Nv(x) zu

Ne(x) =1

x7 ∗ LSlot(x)∗ 16 ∗ c4 ∗ x3 ∗ x2

In Abb. 4.42 kann die Abhängigkeit zwischen der statischen Nutzdatenlänge und derWahl des Makroticks als nominalen Zeitschritt eines FlexRay-Clusters nachvollzogenwerden. Der Vorteil eines niederwertigen Makroticks (bei 1μs mit maximaler Nutzda-tenlänge von 128 Byte-Wörtern pro Botschaft) wird hierbei ersichtlich. Allerdings giltes entsprechende Nebenbedingungen zu determinieren, welche negative Aspekte, wiedie relativ schlechte Skalierbarkeit von 256 Byte-Botschaften und die daraus resultie-rende minimale Slotanzahl im statischen Segment, miteinbeziehen. Bei der Analyse derFunktionale Nv(x) und Ne(x) muss beachtet werden, dass x in diesem Zusammenhangeine vektorielle Eingangsgröße darstellt (x ∈ D ⊂ R8 für Nv(x), x ∈ D ⊂ R5 für Ne(x)).Durch die Komponenten des Vektors �x ∈ D ⊂ R8 wird hauptsächlich das Kommu-nikationsverhalten im FlexRay-Cluster bestimmt, welche gleichzeitig Einfluss auf diePerformanz des Bussystems ausüben. Daher lassen sich die Eingangsgrößen in diesemZusammenhang auch als Performanzparameter auffassen:

Definition 4.6.3 (Performanz-Parameter) Die Funktionale Nv(x) bzw. Ne(x) hängen vonden Parametern

• x1 = gdTSSTransmitter

• x2 = gPayloadLengthStatic

• x3 = gdSampleClockPeriod

• x4 = gdActionPointO f f set

• x7 = gdMacrotick

• x9 = gMacroPerCycle

• x10 = gdNIT

• x18 = gdMinislotActionPointO f f set

ab. Sämtliche Performanz-Parameter können innerhalb ihrer Definitionsbereiche nach den in/[Fle05a]/ aufgeführten Restriktionen gesetzt werden.

�


In Abbildung 4.41 werden die FlexRay Performanz-Parameter rot markiert dargestellt.Daraus lässt sich schließen, dass die Performanz eines FlexRay-Clusters von den Funk-tionsbereichen Physical Layer, Coding/Decoding und Kommunikation abhängt. Nv und Nvbilden frechet-differenzierbare Abbildungen in den Nicht-Sprungstellen, wodurch eineordentliche Definition der Funktionale Nv und Nv erlaubt wird /[Mai08]/.

Physical LayergSyncNodeMax

gAssumedPrecision

gChannels

gdPropagationDelayMax

gdPropagationDelayMin

gdSampleClockPeriod

Wake up/ Start upgColdstartAttempts

gdCASRxLowMax

gdWakeupSymbolRxIdle

gdWakeupSymbolRxLow


gdWakeupSymbolTxIdle

gdWakeupSymbolTxLow

gListenNoise

gdMaxInitializationError

gNetworkManagementVector

KommunikationgdActionPointOffset

gdDynamicSlotIdlePhase

gdMinislot

gdMinislotActionPointOffset

gdStaticSlot

gdSymbolWindow

gMacroPerCycle

gNumberOfMinislots

gNumberOfStaticSlots

gPayloadLengthStatic

gdCycle

gdNIT

Coding/DecodinggdTSSTransmitter

gdBit

gdBitMax

gdBitMin

gdMacrotick

gdMaxMicrotick

Fehlerkontrolle gMaxWithoutClockCorrectionFatal

gMaxWithoutClockCorrectionPassive

gOffsetCorrectionStart

gClusterDriftDamping

gOffsetCorrectionMax

Cluster-Parameter

Abbildung 4.41.: Die Performanz-Parameter (rot) korrelieren mit drei unterschiedlichen Spezi-fikationsbereichen (logische und technische Systemaspekte)

Im nächsten Schritt soll versucht werden, die definierten Funktionale unter Beach-tung relevanter Restriktionen der FlexRay-Spezifikation /[Fle05a]/ zu optimieren. Indiesem Zusammenhang kommt dem Konvexitätsbegriff eine entscheidende Rolle zu.Für die Prüfung der Konvexitätseigenschaften gilt es die Hesse-Matrix zu untersuchen.Falls alle Eigenwerte der Matrix nicht negativ (positiv-semidefinit) sind, lässt sich die An-nahme der Konvexitätseigenschaft der Funktionale verifizieren. Bei der Untersuchungder Hesse-Matrizen für Nv und Nv zeigt sich, dass in beiden Fällen negative Eigenwertefür jeweils mindestens einen Eingangsvektor aus den gültigen Definitionsbereichen ge-funden werden kann (Indefinitheit) /[Mai08]/. Aus der Indefinitheit der Hesse-Matrizenlässt sich die Aussage folgern, dass die zugeordneten Funktionale keine konkaven Ei-genschaften aufweisen. Reziprok lässt sich schliessen, dass die Negation dieses Funk-tionals somit keine konvexen Eigenschaften besitzt. Als Konsequenz lässt sich folgenderSatz formulieren:

Satz 4.6.4 Das Nutzdatenvolumen-Funktional Nv(x) und das Nutzdateneffizienz-FunktionalNe(x) aus den Definitionen A.3.1 und A.3.2 sind nicht konvex auf dem jeweils gültigen Defini-tionsbereich Dv ⊂ R8 und De ⊂ R5.

�


Diese Erkenntnis hat weitreichende Konsequenzen im Kontext der Optimierung. Da diebeiden Funktionale weder konvex noch konkav sind, kann nicht sichergestellt werden,dass für das Optimierungsproblem ein Minimum existiert. Die Tragweite der Ergebnis-se der nachfolgend beschriebenen Optimierungen sind daher relativ einzuordnen. Dasheißt, dass es sich bei jedem gefundenen Minimum des Optimierungsproblems14 nichtstrikt um ein globales Minimum handeln muss.

Beispielhaft zeigt die Abb. 4.42 das Nutzdateneffizienz-Funktional Ne(x2, x7). Dabeiwerden die Eingabeparameter auf x1 = 14.625, x3 = 0.0128 und x4 = 4.0 gesetzt.

Abbildung 4.42.: Nutzdateneffizienz-Funktional in Abhängigkeit von den Eingangsparameternx2 und x7

Zur Lösung des Optimierungsproblems auf Basis des Funktionals Ne (OPNe) müssendie Restriktionen der FlexRay-Spezifikation analysiert werden. Dabei lässt sich zwischenParametern unterscheiden, die direkt das Funktional beeinflussen (α-Parameter) undParametern bei denen keine direkte Abhängigkeit besteht (β-Parameter). Diese Para-meter werden herangezogen, um mit zusätzlichen Funktionalen den Lösungsraum desOP einzuschränken. Neben dem Einsetzen und äquivalenten Umformen der FlexRay-Restriktionen werden sämtliche Nebenbedingungen in Form von Ungleichungen zu-sammengeführt15.

Im Kontext von OPNe werden sämtliche Restriktionen relevant, die in Abhängigkeitzu den Variablen aus Ne stehen. Als Einschränkung muss der existierende Definitions-bereich De beachtet und die Erfüllbarkeit der restlichen FlexRay-Restriktionen für einenLösungsvektor verifiziert werden. Die Analyse der Nebenbedingungen führt zu einerRestriktionsabbildung Ge(x), die insgesamt 15 FlexRay-Restriktionen, 10 Restriktionen

14Die Existenz eines Minimums für das OP kann unter den gegebenen Konvexitätseigenschaften nichtverifiziert werden.)

15Für alle relevanten FlexRay-Restriktionen ist die Frechet-Differenzierbarkeit in den Nicht-Sprungstellen gegeben /[Mai08]/.


zur Einhaltung von De und eine Zusatzrestriktion zur Beschränkung der Nutzdatenlän-ge der statischen Botschaften beinhaltet.

Mit der Definition von Ne(x) und der Selektion relevanter Restriktionen Ge(x) lässtsich das Optimierungsproblem vollständig formulieren. Dabei wird Ne(x) unter der Prä-misse maximiert, einen Lösungsvektor x0 ∈ De mit gültigen Parameterwerten für eineFlexRay-Konfiguration zu erhalten. Ein dazu äquivalentes Optimierungsproblem ist dieMinimierung von −Ne(x) unter der Einhaltung aller in Ge(x) definierten Restriktionen.

Definition 4.6.5 (Optimierungsproblem OPNe) Sei Ne(x) wie in Definition A.1.1 undGe(x) wie in Definition A.2.1 beschrieben. Dann wird das Optimierungsproblem{

min − Ne(x)x ∈ De, Ge(x) ≤ 0

OPNe genannt. Ein Lösungsvektor für dieses Optimierungsproblem stellt somit gültige Parame-terwerte für eine FlexRay-Konfiguration dar.

�

Zusammenfassend lässt sich OPNe als nichtlineares und nichtkonvexes Optimierungspro-blem auffassen. Diese Aussage begründet sich in dem offensichtlich nichtlinearen undnicht konvexen Nutzdatenfunktional Ne mit der ebenfalls nicht linearen Restriktionsab-bildung Ge(x), welche auf nichtlinearen Komponentenfunktionalen basiert. Die Imple-mentierung von Optimierungsverfahren für OPNe wird in Kapitel 5 beschrieben.

Eine Alternative zur Lösung von OPNe basiert auf dem allgemeinen Satz von Kuhn-Tucker /[Lue97]/. Da bei der werkzeuggestützten Berechnung im Gegensatz zuf mincon keine Lösung gefunden werden konnte (s. Abs. 5), soll die Idee und das theo-retische Vorgehen aus Vollstänigkeitsgründen nur knapp skizziert werden.

Das Funktional Ne bildet ein notwendiges Gateaux-differenzierbares, reellwertigesFunktional auf den Vektorraum X und Ge die Gateaux-differenzierbare Abbildung derRestriktionsgleichungen von X auf den normierten Raum Z mit dem positiven KegelP16. Als Ziel wird versucht ein x0 zu finden, welches Ne bzgl. Ge(x) ≤ �0 minimiert,wobei x0 einen regulären Punkt der Ungleichung Ge(x) ≤�0 darstellen muss. Dann gibtes ein z∗0 ∈ Z∗, z∗0 ≥ �0 (Z∗ ist der normierte Dualraum auf Z), so dass die Lagrange-Gleichung

−Ne(x) + 〈Ge(x), z∗0〉 ,

−Ne(x) +m

∑j=1

z∗0 ∗ gj(x)

stationär an der Stelle x0 ist. Weiterhin gilt 〈Ge(x0), z∗0〉 = 0.Zur Optimierung wird die Lagrange-Gleichung differenziert und dem Wert Null

gleichgesetzt. Gleichzeitig wird Ge in Form des euklidischen Skalarprodukts ebenfallsdem Wert Null gleichgesetzt. Dadurch soll die stationäre Stelle für die Lagrange-Glei-chung gefunden und die Gleichung 〈Ge(x0), z∗0〉 = 0 gewährleistet bleiben.

16Für die Definitionen der Begriffe „Normierter Vektorraum“, „Positiver Kegel“ und „regulärer Punkt“ wirdin diesem Zusammenhang auf /[Lue97]/ weiterverwiesen


4.6.4.2. Formalisierung des Optimierungsbereichs „Dynamisches Segment“

Das optional implementierbare dynamische FlexRay-Segment funktioniert im Gegen-satz zum statischen Segment mit einem künstlich generierten ereignisgesteuerten Kom-munikationsansatz. Die Bezeichnung „künstlich“ bezieht sich auf das feingranulare zeit-scheibenbasierte Minislotprinzip, welches niedrige zeitliche Pufferabstände zwischenden aktiven Datenübertragungsvorgängen ermöglicht. Die Erzeugung der dynamischenBotschaften weist einen probabilistischen Charakter auf, da trotz der statischen Zuord-nung von Sendeminislots zu Sendern die Netzwerkkommunikation nicht zwangsläu-fig zyklisch von den Sendern ausgeführt werden muss. Gleichzeitig führt die flexibleBotschaftslänge zu Systeminterferenzen, da der relative Sendezeitpunkt im Buszyklusvon der Sendeaktivität und der Nutzdatenlänge einer Botschaft abhängt. Im Extremfallkommt es zu zeitlichen Verschiebungen über mehrere Buszyklen.

ä

Abbildung 4.43.: Zusammenhang zwischen Minislot-, Nutzdaten-, Dynamische Slot- und dyna-mische Segmentlänge eines FlexRay-Zyklus

In Abb. 4.43 wird das Zusammenspiel der beschriebenen Systemaspekte im dynami-schen FlexRay-Segment veranschaulicht. Die Darstellung zeigt N ∈ N Steuergeräte, diemit den Wahrscheinlichkeiten pi < 1, i ∈ 1, ..., M Botschaften im dynamischen Segmentverschicken. Die M Botschaften werden injektiv auf verschiedene Minislots abgebildet.Dazu wird das dynamische Segment in insgesamt M + r Minislots aufgeteilt. r ∈ N seidie Anzahl an Minislots, die zusätzlich nötig ist, um die zeitlichen Anforderungen derFlexRay-Spezifikation zu erfüllen und das einkalkulierte Datenvolumen übertragen zukönnen. Die Größe M + r soll in diesem Abschnitt bestimmt werden. Folgende zweiDefinitionen bilden die Basis für eine strukturierte Problemlösung.

Definition 4.6.1 (Ereignisgesteuerte Botschaft) Eine ereignisgesteuerte Botschaft ist eineBotschaft, die mit einer Wahrscheinlichkeit p < 1 auf dem FlexRay-Cluster durch ein Steu-ergerät versendet wird.

�

Definition 4.6.2 (Zufallsvariable X) Sei X ∈ R+ eine stetige Zufallsvariable. X beziffert daszufällige Datenvolumen aller im dynamischen Segment verschickten Botschaften pro Zyklus.

�


Im dynamischen Segment werden in der Regel genau die ereignisgesteuerten Botschaf-ten aufgenommen, bei denen sich eine potentielle zeitliche Verzögerung beim Versendennur eingeschränkt auf das funktionale Verhalten eines an der Kommunikation partizi-pierenden Steuergeräts auswirkt.

Berechnung der dynamischen Segmentgröße

Die Selektion der Botschaften für das dynamische Segment des FlexRay-Kommunika-tionssystems wird in dieser Arbeit auf Basis empirisch ermittelter Werte eines Serien-fahrzeugs mit CAN-Vernetzung getroffen. Kennzahlen in diesem Zusammenhang be-ziehen sich auf die Erfassung der absoluten Auftrittshäufigkeit und des Datenvolumensder ausgewählten Botschaften innerhalb eigens definierter Zeitintervalle17. Grundle-gend wird bei dem Ansatz der folgende Begriff der Dichte- und Verteilungsfunktion/[RWV97]/ herangezogen:

Definition 4.6.3 (Dichte- und Verteilungsfunktion) Die Zufallsvariable X heißt stetig verteiltmit der Dichtefunktion fX, falls fX ≥ 0 im Definitionsbereich R ist und sich die Verteilungs-funktion FX von X folgendermaßen schreiben lässt:

FX(x) =x∫

−∞

fX(t)dt

�

In Abbildung 4.44 wird die im Fahrzeug ermittelte Punktmenge durch kubische Splinesinterpoliert. Dazu lässt sich in Analogie zu /[HS02]/ definieren:

Definition 4.6.4 (Spline-Funktion) Sei t ∈ R und sm(t) ein Polynom 3. Grades mit m ∈1, ..., M − 1 der Form

sm(t) = am + bm ∗ (t − tm) + cm ∗ (t − tm)2 + dm ∗ (t − tm)3

Dann heißt

s(t) =M−1

∑m=1

χm(t) ∗ sm(t)

Spline-Funktion mit der Auswahlfunktion

χm(t) =

{1 tm ≤ t ≤ tm+1

0 sonst

�

Die ermittelten Splinekoeffizienten und Werte für die Auswahlfunktion werden in Abs.B dargestellt. Die stetige Zufallsvariable X definiert das zufällige Datenvolumen für alle

17Die ermittelten Daten basieren auf dem Fahrprofil eines Fahrers in einem Serien-SUV auf einer mittle-ren Distanz von ca. 600km. Für zuverlässige Ergebnisse wäre eine Erweiterung auf unterschiedliche Fahrer,Fahrzeuge und Streckenprofile sinnvoll.


0 50 100 150 200 250 300 350 400-0.05

0

0.05

0.1

0.15

0.2

0.25

0.3

Datenvolumen pro Zyklus

rela

tive

Häu

figke

it

Abbildung 4.44.: Durch kubische Splines interpolierte Dichtefunktion nX(t) auf Basis der ge-messenen Punktmengen

im dynamischen Segment verschickten Botschaften pro festgelegten Zyklus18. Dabei giltdie Dichtefunktion nX(t) zur Einschränkung des Definitionsbereichs:

nX(t) =

⎧⎨⎩

M−1∑

m=1χm(t) ∗ sm(t) für 0 ≤ t ≤ 390

0 sonst

Konsequenterweise lässt sich daraus die Verteilungsfunktion für die Zufallsvariable Xnotieren als:

NX(x) =

⎧⎪⎪⎪⎨⎪⎪⎪⎩

0 für x ≤ 0x∫

0

M−1∑

m=1χm(t) ∗ sm(t)dt für 0 ≤ x ≤ 390

1 für x ≥ 390

Zur Berechnung des aufkommenden Datenvolumens muss der Erwartungswert der er-mittelten Funktion nX(x) berechnet werden.

Definition 4.6.5 (Erwartungswert) Sei X eine stetige Zufallsvariable mit der Dichte fX. Dannheißt

E(X) :=+∞∫

−∞

x ∗ fX(x)dx

18Der Zyklus beträgt in diesem Fall 8ms.


Erwartungswert von X, falls gilt:

+∞∫−∞

x ∗ fX(x)dx < ∞

�

Durch Einsetzten von nX(x) für fX(x) ergibt sich das erwartete Nutzdatenvolumen mitEinheit [Byte] für das dynamische Segment.

E(X) =+∞∫

−∞

x ∗ nX(x)dx =390∫0

x ∗ nX(x)dx =390∫0

x ∗M−1

∑m=1

χm(x) ∗ sm(x)dx = 1.62e + 002

Das Ergebnis 1.62e + 002 in [Byte] entspricht einem Nutzdatenvolumen von 1296 [Bit].Zur Berechnung der dynamischen Botschaftslänge müssen folgende zusätzliche Para-meter hinzugenommen werden:

Definition 4.6.6 (Anzahl der ECUs) Die Anzahl der ECUs, die im dynamischen SegmentBotschaften verschicken dürfen, wird durch den Parameter η ∈ N0 festgelegt.

�

Definition 4.6.7 (Anzahl Botschaften pro ECU) Sei i ∈ N. Dann ist ξi ∈ N0 die Anzahlder Botschaften, die die ECU i im dynamischen Segment verschicken darf.

�

Definition 4.6.8 (Anzahl verschickter Botschaften im dynamischen Segment) Der Pa-rameter ψ ∈ N0 gibt die Anzahl aller verschickten Botschaften im dynamischen Segment proZyklus vor.

�

Somit lässt sich die Anzahl der Botschaften, die im dynamischen Segment pro Zyklusverschickt werden, durch die Formel

ψ =η

∑i

ξi

darstellen. Es wird angenommen, dass sich die versendete Nutzdatengröße pro Bot-schaft gleichmäßig verteilt. Deshalb errechnet sich der Parameter β11 (=dynamischeNutzdatenlänge einer Botschaft) zu

β11 = ceil(E(X) ∗ c4 ∗ x3

ψ) = ceil(

1296 ∗ c4 ∗ x3η

∑i

ξi

)

mit Einheit [gdBit]. Jetzt lässt sich die Anzahl der benötigten Minislots im dynamischenFlexRay-Segment pro Botschaft berechnen.


Definition 4.6.9 (Anzahl Minislots pro Botschaft) Die zeitliche Länge, die eine im dynami-schen Segment verschickte Botschaft benötigt, wird mit ρ bezeichnet.

�

Mit den obigen Größen wird neben der Länge einer dynamischen Botschaft auch dieLänge des gesamten dynamischen Segments ermittelt. Die zeitliche Ausprägung einerBotschaft im dynamischen Segment wird mit einer Restriktion der FlexRay-Spezifikation/[Fle05a]/ bestimmt:

ρ = 1 + ceil(((β11 + 1) ∗ c4 ∗ x3 ∗ (1 + c6))

(x7 ∗ (1 − c6) ∗ x12)) + β13

Die Einheit ist [Minislot].

4.6.4.3. Actionpointskalierung im statischen Segment

Eine Herausforderung in der Systemparametrierung basiert auf der zweckmäßigen Ska-lierung des Absatzpunkts (Actionpoint Offset)x4 einer Botschaft im statischen Slot desFlexRay-Zyklus. Wesentliche Einflussgröße stellt die Gesamtsystempräzision dar, die imglobalen Actionpoint jedes Slots der FlexRay-Architektur abgedeckt bleiben muss (s.Abb. 4.45).

FlexRay-Botschaft Oa,i

Globaler Actionpoint

Statischer FlexRay-Slot i

Ganzzahlige Menge an Makroticks

Präzision Überhang

Abbildung 4.45.: Actionpoint-Skalierung zur Abdeckung der im Cluster vorhandenen Präzision

x4 ≥⌈

ΔTAssumedNi,j

− dmaxEPL

MT ∗ (1 − ΔTmaxQuarz)

⌉wenn ∀Ni,j : Ni ∧ Nj ∈ Cluster mit Ni = Nj (4.1)

Aus 4.1 lässt sich ableiten, dass die Wahl von x4 möglichst nah unterhalb einer ganzzah-ligen Makrotickgrenze liegen sollte. Daraus lässt sich folgern:

k ∗ MT ≥⌈

ΔTAssumedNi,j

− dmaxEPL


⌉

Aus Skalierungsgründen eignet sich eine MT-Größe in der Nähe des minimal zulässigenMT (MTMin = 1).


k ∗ MT ≥⌈

ΔTAssumedNi,j

− dmaxEPL


⌉

k ∗ MT ≥ΔTAssumed

Ni,j− dmax

EPL


MT ≥√√√√ΔTAssumed

Ni,j− dmax

EPL

k ∗ (1 − ΔTmaxQuarz)

MTMin + x ≥√√√√ΔTAssumed

Ni,j− dmax

EPL


x ≥√√√√ΔTAssumed

Ni,j− dmax

EPL


− MTMin

In Abbildung 4.46 wird eine skalierte Darstellung des MT anhand seines Überhangsx zum minimalen MT in Relation zu den umsetzbaren Actionpointgrößen und der imCluster vorhandenen Systempräzision visualisiert.

24

68

1012

1416 0

10

20

30

40

50-2

0

2

4

6

8

Clusterpräzision

Ganzahliger Multiplikator k eines MT

Del

ta d

es m

atch

ende

n M

Ts z

um m

inim

alen

MT

(=1μ

s)

Abbildung 4.46.: Zusammenhang zwischen der MT-Skalierung und der Actionpointdefinitionzur Abdeckung vorgegebener Präzisionswerte

4.6.4.4. Topologieabmessungen und Systemrobustheit

Topologievarianten beeinflussen die in FlexRay-Architekturen erreichbare Netzwerkprä-zision. Dieser Sachverhalt wird anfolgend kurz erläutert. Die Präzision eines FlexRay-Clusters basiert partiell auf dem quantitativen Beitrag der Latenzen bei der Netzwerk-kommunikation, die sich aus der Summe der an der Kommunikation beteiligten physi-


kalischen Komponenten ergeben. Durch Verzögerungen bei der Kommunikation zweierNetzwerkkomponenten n und m, welche durch die beteiligten Bustreiber, dem Netz-werkkommunikationsmedium und den potentiell verbauten aktiven Sternkopplern er-zeugt werden, existiert ein wesentlicher Einflussfaktor hinsichtlich der in der Uhrensyn-chronisation zu tolerierenden Präzision des FlexRay-Clusters.

FlexRay-Botschaft Ob,i

FlexRay-Botschaft Oc,i

FlexRay-Botschaft Oa,i

Präzision

Präzision

Statischer FlexRay-Slot i

Abbildung 4.47.: Bedeutung der Netzwerkpräzision bezogen auf die Slotüberhänge einesFlexRay-Clusters

Wie in Abb. 4.47 dargestellt, steht die Präzision in Wechselwirkung mit der Protokol-lauslegung und dem zu entwickelnden Netzwerkschedule. Ein Jitter-Effekt auf Slotebe-ne hinsichtlich einer positiven und negativen Abweichung vom normalen Absatzpunktmuss berücksichtigt bleiben, um Botschaftskollisionen bei der Verletzung von Slotgren-zen (Boundary Violations) in der Kommunikation zu verhindern. Die Netzwerkpräzisionmuss dabei in Abhängigkeit zur Granularität der existierenden minimalen diskretenZeitschritte auf Controllerebene, den Mikroticks, betrachtet werden. Diese können in ih-rer zeitlichen Ausprägung zwischen den Controllern variieren. Sogar bei einheitlichenControllern gibt es Abweichungen, da die Schrittgröße als nominaler Wert zu betrachtenist und nicht mit dem jeweils aktuellen Wert am Controller identisch sein muss.

Jeder Kommunikationscontroller verfügt über eine Uhrenquelle mit einer potentiel-len, nach oben beschränkten Abweichung von der Normfrequenz. Von dieser Uhren-quelle leitet sich für jeden Kommunikationscontroller der Mikrotick ab. Die nominaleLänge eines derartigen Mikroticks muss nicht zwangsläufig in jedem Kommunikati-onscontroller identisch sein in einem Netzwerk. Drei definierte Längen sind prinzipiellmöglich in einem Verhältnis x41 = pdMicrotick = i ∗ pdSmallestMicrotick mit i ∈ {2, 4}/[Ung07]/.

Falls die Anzahl an Mikroticks pro Zyklus (x45 = gMicroticksPerCycle) nicht durchdie Anzahl der Makroticks pro Zyklus gMacroticksPerCycle teilbar ist, können zwei ar-biträre Makroticks in ihrer zeitlichen Ausprägung in einem Zyklus im Kommunikations-controller voneinanderabweichen, da Mikro- und Makrotickgrenzen stets zeitsynchronverlaufen.

Durch die gezielte Auswahl geeigneter aktiver Sternkoppler, Verkabelungsgrößen,Quarze zur Zeitgenerierung und EMV-Schutzmaßnahmen lassen sich die durch die Sy-stempräzision verursachte Ungenauigkeiten bei der Signalausbreitung (x6 = gdMaxPro-pagationDelay) beschränken. Zur Erhöhung der physikalischen Systemrobustheit undder Robustheit in der Systemkommunikation tragen weiterhin eine abgesenkte Baudra-


te sowie eine konservative Bedatung des dynamischen FlexRay-Segments bei.

4.6.4.5. Zielabtastraten und Minimierung von Slotüberhängen

Zum Erreichen der geforderten Regelgüte durch vorgegebene Abtastraten müssen dieAnforderungen aller zu übertragenden Signale und deren Attribute im FlexRay-Parame-tersatz berücksichtigt werden. Analog zu Kapitel 4.2 lassen sich dabei unterschiedli-che Aspekte der Netzwerkkommunikation betrachten, um grundlegende Eckdaten derFlexRay-Konfiguration zu identifizieren:

4060

80100

120140

160180

200220

240

0.010.015

0.020.025

0.030.035

0.040.045

0.050

1

2

3

4

5

6

μT-Anzahl pro MTSamplingrate am FlexRay-CC

MT

Abbildung 4.48.: Mikrotickauslegung anhand des vorgegebenen MTs in μs

Einflussfaktoren für die Definition der Buszykluslänge und -segmentierung:

• Zykluszeiten aus sämtlichen Signalen der Funktionsnetznotation,

• Anzahl der Signale/Signalgruppen mit einheitlicher Sendezykluszeit,

• Klassifikation der Kommunikationstypen (zyklisch/spontan/hybrid),

• Flexibilität in der Schedulebedatung durch Multiplexing (Erweiterbarkeitsvortei-le),

• Buszyklusspezifische Paradigmen zur Abbildung bussynchroner/-asynchronerFlexRay-Applikationen (Antwortzeiten, Deadlines, Sperrzeiten).

Einflussfaktoren zur Reduktion von Slot-Überhängen (Interframe-Gap-Reduction):

• Systemgenauigkeit (Quarzqualität),

• Initialisierungsfehler bei der Knotenintegration in ein synchrones Cluster,

• Kompensation von Signalverkürzungen (truncations) während der Signalübertra-gung,

• Berücksichtigung von zuverlässig auftretenden Verzögerungen bei der Signalüber-tragung,


• Skalierung des Makroticks im FlexRay-Cluster.

Während die Systemgenauigkeit, der Initialisierungsfehler, die Signalverkürzungen unddie Signalverzögerungen von der eingesetzten Hardware abhängen, bezieht sich die Ma-krotickskalierung auf eine Adaption des Busscheduledesigns für die vorliegende tech-nische Systemarchitektur.

4.6.4.6. Makrotickskalierung im Cluster

Die Makrotickskalierung bezieht sich auf die Einpassung des MT auf Basis der individu-ellen Abtastfrequenz eines jeden FlexRay-Kommunikationscontrollers zur Ableitung derAnzahl an μTs pro MT. Als Restriktion für die Wahl des knotenspezifischen Mikroticksgilt die anliegende Abtastfrequenz in einem Bereich von 10-80MHz.

Wie in Abb. 4.48 dargestellt, lässt sich nicht der komplette Definitionsbereich für dieMT-Länge (1-6μs) auf alle Abtastraten eines FlexRay-Clusters anwenden (s. Tab. 4.9).Durch die begrenzte Samplingrate pro Mikrotick (1-4) und das Intervall für die Anzahlan Mikroticks pro Makrotick (40-240) ergeben sich ungültige Konfigurationen, die in derTabelle mit ⊥ markiert sind.

Baudrate [Mbit/s] Controllerfrequenz [MHz] Makroticklänge [μs]2,5 10 ⊥ ⊥ ⊥ 40 50 602,5 20 ⊥ 40 60 80 100 1202,5 40 40 80 120 160 200 2402,5 80 ⊥ ⊥ ⊥ ⊥ ⊥ ⊥5 10 ⊥ ⊥ ⊥ 40 50 605 20 ⊥ 40 60 80 100 1205 40 40 80 120 160 200 2405 80 ⊥ ⊥ ⊥ ⊥ ⊥ ⊥

10 10 ⊥ ⊥ ⊥ ⊥ ⊥ ⊥10 20 ⊥ 40 60 80 100 12010 40 40 80 120 160 200 24010 80 80 160 240 ⊥ ⊥ ⊥

Tabelle 4.9.: Mikro-pro-Makrotick-Verhältnisse für unterschiedliche Baudraten und Controller-frequenzen

KAPITEL 5

Implementierung und Validierung

In diesem Kapitel wird das Konzept und die prototypische Umsetzung der entwickelten modellbasiertenEntwicklungsmethodik für E/E-Architekturen auf Basis des flexiblen zeitgesteuerten Bussystems Flex-Ray vorgestellt. Dabei werden Erkenntnisse bei der Modellentwicklung zusammengefasst, die bei derDurchführung einer seriennahen Fallstudie gewonnen wurden. Das Vorgehen der FlexRay-Parameterent-wicklung wird auf Basis der statischen und dynamischen Modellanalyse konkretisiert und dessen Vorteileund Grenzen aufgezeigt.

Während des Parametrierungsvorgangs eines FlexRay-Systems müssen sämtlicheSystemeigenschaften der zu entwickelnden E/E-Architektur berücksichtigt bleiben, umeine zielgerechte, fehlerfreie Integration der FlexRay-Technologie ins Fahrzeug zu ge-währleisten. Die in Kapitel 4 erarbeitete Entwicklungsmethodik wird dabei zur stati-schen Systemanalyse auf ein E/E-Architekturmodellierungswerkzeug übertragen. Fürdiesen Zweck wurde in einem Kooperationsprojekt ein Erweiterung eingeführt, umdie komplexen Parameterberechungsregeln zweckmäßig in einer dedizierten Notations-form im Werkzeug zu integrieren. Die dynamische Systemanalyse erfolgt beispielhaftfür die Untersuchung des Weck- und Startverhaltens in einem separaten freiverfügba-ren Werkzeug zur Simulation gezeiteter Automaten. Zur Lösung der Optimierungspro-bleme wird die Entwicklungsumgebung durch ein kommerzielles Werkzeug zur mathe-matischen Optimierung ergänzt. Die konzeptionelle Umsetzung und deren Anwendungwerden zusammen mit den erhaltenen Ergebnissen für die durchgeführte Fallstudie imFolgenden erläutert.

202

5.1. FLEXZOOMED-IMPLEMENTIERUNGSKONZEPT 203

5.1. FlexZOOMED-Implementierungskonzept

Die umgesetzte Entwicklungsmethodik des FlexZOOMED-Ansatzes beruht auf der Un-tergliederung der Prozessschritte in die Bereiche abstrakte Systemspezifikation (Ausstat-tungs- und Anforderungsanalyse), konkrete Systemspezifkation (statische und dynamischeE/E-Architekturmodellierung), Systemoptimierung, Systemparametrierung und Systemana-lyse (s. Abb. 5.1).

Ausstattungen Ausstattungsfunktion Ausstattungsfunktionsabhängigkeiten

Dynamische Analyse Statische Analyse

AnalyseOptimierung Parametrierung

Top

olog

ien

Net

zwer

ke/

Ver

kab

elung

Funktionsn

etz

Sta

rtU

p/W

akeU

p-A

uto

mat

Abbildung 5.1.: Integrierte Darstellung des Entwicklungskonzepts FlexZOOMED

Die Umsetzung basiert für eine Validierung auf einer dreiteiligen Werkzeugumge-bung. Die Grundlage bildet das E/E-Architekturmodellierungswerkzeug PREEvision/[Aqu07]/, welches für die Bereiche der abstrakten und konkreten statischen Systems-pezifikation eingesetzt wird. Um den Bereich der Systemparametrierung für FlexRay--Systemarchitekturen umzusetzen, wurde das Basiswerkzeug um einen eigenständigenParametrierungseditor innerhalb eines Forschungsprojekts erweitert. Die dynamischeSystemspezifikation lässt sich nicht in PREEvision abbilden und wird daher in demzusätzlichen Werkzeug UPPAAL /[BLP+96]/ zur Spezifikation, Simulation und Mo-dellprüfung (model checking) von gezeiteten Automaten umgesetzt. Als weiterer Bau-stein wird der Bereich der Systemoptimierung mithilfe des Werkzeugs Matlab/Simu-link /[The07a]/ realisiert. Eine Einbettung der umgesetzten Matlab-Optimierungsbe-rechnungen in PREEvision generiert dabei funktional keinen entscheidenden Mehrwertund bleibt aus diesem Grund bei der technischen Implementierung unberücksichtigt.Die Gesamtsystemanalyse der Parametrierungsergebnisse und der Qualitätskennzahlender FlexRay-Architekturen wird in einer weiteren Werkzeugergänzung innerhalb einerMetriktabelle visualisiert.

Während der Erstellung der Arbeit sind auch alternative Lösungen zur Umsetzungdes FlexZOOMED-Ansatzes betrachtet worden. Beispielsweise wäre mit dem Werk-zeug MetaEdit /[Met08]/ eine vollkommen freie domänenspezifische Umsetzung derFlexRay-Architekturmodellierung möglich. Allerdings würde eine Adaption auf die

204 KAPITEL 5. IMPLEMENTIERUNG UND VALIDIERUNG

E/E-Architekturentwicklung in diesem Zusammenhang einen sehr hohen Aufwand er-fordern, der die Umsetzungstiefe innerhalb dieser Arbeit limitiert hätte. Zusätzlich zieltdas Werkzeug MetaEdit auf eine verstärkt simulative Analyse und die Generierungvon virtuellen Prototypen, was die Anforderungen der FlexRay-Systemparametrierungnicht ausreichend abdeckt. Einen ähnlicher Schluss lässt sich für das Werkzeug Visual-Sim /[Mir07]/ ziehen, welches gleichfalls für die dynamische Analyse des FlexRay-Verhaltens (dynamisches FlexRay-Segment, Timing-Analyse) interessant erscheint, aberebenfalls mit einem hohen Aufwand-/Nutzenverhältnis verbunden ist. In diesem Fallwürde sich eher die Integration eines eigenständigen Timing-Analysewerkzeugs, bei-spielsweise SymtaT/S /[HHJ+]/, anbieten, was aber nicht den Schwerpunkt der vor-liegenden Arbeit bildet und daher zurückgestellt wurde. Von einer proprietären Um-setzung des FlexZOOMED-Ansatzes auf einem herstellerinternen Werkzeug wird auf-grund eines fehlenden passenden Basissystems und hohen Kostenaufwendungen in die-ser Arbeit abgesehen.

5.1.1. Designfluss

Die Idee des implementierten Ansatzes fundiert auf dem erläuterten fünfteiligen De-signprozess. In Abb. 5.2 wird der Designfluss examplarisch in sequentieller Abfolgedargestellt. Initial werden die im Lastenheft festgelegten Ausstattungseigenschaften (fea-tures) des Fahrzeugs in ein Modell überführt. Dabei werden in diesem Beispiel spezi-elle Ausstattungsoptionen eines erweiterten Bremssystems (Nässeschutz, Bergabfahrhilfe,ABS-Bremsung) abgebildet. Jedes Ausstattungsmerkmal lässt sich nun in eine funktiona-le Beschreibungsform überführen. In diesem Fall wird beispielsweise die Bergabfahrhilfeauf eine mehrteilige Funktion Komfortbremsen abgebildet, die durch Ereignisse (Dros-selklappen geschlossen, erhöhte Geschwindigkeit, Tempostat aktiv) ausgelöst und über zuge-ordnete Komponenten (Bremse VL, Bremse VR, Bremse HL, Bremse HR) ausgeführt wird.Im nächsten Schritt wird die abstrakte Ausstattungsfunktion Komfortbremsen einer kon-kreten Realisierung ErweiterteBremsFkt im Funktionsnetz zugeordnet. Dieses Funktions-netzelement lässt sich anschließend auf eine technische Komponente, beispielsweise dasESP-Steuergerät, partitionieren. Nach der statischen Zuordnung der konkreten Funk-tion zu einer konkreten technischen Komponente erfolgt die Definition des Netzwerkssowie dessen Verkabelung, um darauf aufbauend die Topologien baureihenspezifisch(Heckmotor-Sportwagen, Mittelmotor-Sportwagen, sportlicher Geländewagen (SUV)) festzule-gen. Der mit diesen Schritten festgelegte statische E/E-Architekturentwurf wird in Abb.5.2 unter dem Kennzeichen A dargestellt.

Im nächsten übergeordneten Prozessschritt B erfolgt die dynamische und statischeBestimmung der festgelegten FlexRay-Parameter. Dabei werden die knoteninternen Pa-rameter für den dynamischen Ablauf des Weck- und Startvorgangs des FlexRay-Clustersmanuell in das Modell des gezeiteten Automaten im Werkzeug UPPAAL überführt. Dieim dynamischen Modell ermittelten Ergebnisse werden im Verbund mit den restlichenParametern aus der statischen Architekturbeschreibung in das FlexRay-Parametermo-dell eingebunden. Dieser Vorgang vollzieht sich automatisch während der Bedatung imersten Prozessschritt A.

Die Optimierung erfolgt durch den dateibasierten Austausch der FlexRay-Parameterzwischen dem E/E-Architekturmodell in PREEvision und der Optimierungswerkzeug-box aus der Matlab/Simulink-Werkzeugkette (Prozessschritt C). Anschließend lassensich die aus den drei Werkzeugen ermittelten FlexRay-Parametersätze in PREEvision


DC

B

A

Abbildung 5.2.: Idee der durchgängigen Integration eines mehrteiligen Entwicklungskonzeptsim Designfluss

in einer Metriktabelle visualisieren und variantenspezifisch vergleichen und bewerten(Prozessschritt D).

5.1.2. Modellierungsebenen

In Abs. 4.3.3 werden FlexRay-Parametergruppen den entsprechenden Modellierungs-ebenen auf E/E-Architekturebene zugeordnet. In /[Sch08]/ erfolgt eine Übertragungdes Konzepts mithilfe einer Metamodelladaption auf das E/E-Architekturmodel-lierungswerkzeug PREEvision.

5.1.2.1. Anforderungsebene

Anstelle der in Abs. 2.2.4.1 vorgestellten Featurebäumen werden die funktionalen An-forderungen an eine E/E-Architektur auf die PREEvision-spezifischen Notationsfor-men abgebildet. Grundsätzlich werden dabei Ausstattungspakete konfektioniert undje nach Klassifikationsmethode partiell in hierarchischer Form spezifiziert (s. Abb. 5.3).So lässt sich die Ausstattungsoption Stabilitätskontrolle mit verschiedenen Abstufungen(Sport, Offroad) versehen. Zusammen mit den Ausstattungsoptionen Nässeschutz undABS-Bremsung bildet die Stabilitätskontrolle zusätzlich das komponierte Ausstattungs-paket aktive Sicherheit.

Die funktionale Beschreibung einer jeden Ausstattungsoption erfolgt auf einer ei-genständigen Notationsebene. Dazu werden die in Abs. 2.5.2 beschriebenen Wirkkettenüber die Tupel (Requestor,Functionality,Fulfiller) definiert. Dabei werden alle anfordern-de Ereignisse in funktionaler Form erfasst (Drosselklappen geschlossen → dk = 0, erhöhteGeschwindigkeit → v > 50, Tempostat aktiv → ts = 1, ...) und einer übergeordneten Funk-tion Komfortbremsen zugeordnet. Die Reaktion auf die Ereignisse erfolgt über explizit


Abbildung 5.3.: Hierarchische Featuremodellierung aus Basis funktionaler Wirkketten

definierte Komponenten (in der Regel in mechanischer Form durch die Ansteuerungvon Aktoren (Bremse VL, Bremse VR, Bremse HL, Bremse HR)). In einer separaten Dar-stellung lassen sich alle Abhängigkeiten zwischen den anfordernden Ereignissen, derAusstattungsfunktion Komfortbremsen und den erfüllenden Komponenten in Graphen-form integriert betrachten.

5.1.2.2. FN-Ebene

Bei der Funktionsnetzumsetzung werden analog zu Abs. 4.4.2 folgende Inhalte spezifi-ziert:

• Funktionskomponenten und komponierte Funktionskomponenten im Sinne einerhierarchischen Funktionsuntergliederung (Knoten),

• Signale und deren Aufbau (Offsets, Auflösung, Wertebereiche,...), die zwischen denFunktionskomponenten ausgetauscht werden (Kanten),

• Zuordnung von Sendearten (Kommunikationstypen) an den Schnittstellen zwi-schen Funktionskomponente und Sendesignal (Sende- und Empfangsports),

• Gruppierung von Signalen in Gruppen (funktional, modusabhängig, zustandsab-hängig),

• Spezifikation der Sende-/Empfangsbeziehungen zwischen den Funktionen (p2p,broadcast).

In Abb. 5.4 wird das instanzierte Funktionsnetz aus der Fallstudie (s. Abs. 5.4) darge-stellt. In der entwickelten Fallstudie wird beispielsweise auf logischer Ebene die Funk-tionskette E-Gas über das Tupel der Funktionsblöcke (Gaspedalposition, Verarbeitung inder Motorsteuerung, Drosselklappenstellung) spezifiziert. Zwischen den Modulen werdendie Datensignale MO1_Pedalwert und MO3_DKW ausgetauscht. Für die Signale werden


Abbildung 5.4.: Ausschnitt aus einem Funktionsnetz der Antriebs- und Fahrwerksdomäne

Länge, Einheit, Faktoren und Maximalbereiche definiert. Die Sendeports ThrottlePos_SP1und Motronic_SP1 bekommen einen zyklischen Sendetyp mit Zykluszeit zugewiesen.Am Empfangsport Motronic_EP1 wird das spontan gesendete Signal BR1_ESP_Eingriffin Abhängigkeit von der Aktivierungszeit empfangen. Je nach Signalgruppierung (bzw.Ausstattungsoption) könnte BR1_ESP_Eingriff funktional exklusiv einem Normalmoduszugeordnet und damit im Sportmodus nicht verarbeitet werden. In diesem Ausschnittwird jedem Signal genau ein Empfänger zugeordnet, was einem p2p-Sende-/Empfangs-typ entspricht. Die Information BR6_Fahrer_bremst wird hingegen mehreren Empfän-gern zugeordnet, was je nach Partitionierung zu einer broadcast-Botschaft führen kann.

5.1.2.3. PN-Ebene

Zur Partitionierung der logischen E/E-Architektur wird vorab, analog wie in Abs. 4.2.2.7beschrieben, die statische technische E/E-Architektur entwickelt. Bei der Umsetzungder PN-Ebene lassen sich in dem Zusammenhang folgende Aspekte, die gleichermaßenmit der FlexRay-Systemparametrierung korrelieren, berücksichtigen:

• Verbaute FlexRay-Steuergeräte im Cluster (blau),

• Verbaute FlexRay-Steuergeräte mit aktiven Sternkopplern (rosa),

• Spezifikation der Netzwerkanbindungstypen (Stern-, Bustransceiver) (blau, grün),

• Systemumgebung (Sensorik/Aktorik) (grün, rot),


• Leistungsversorgung der Steuergeräte (Generatorversorgung) (orange, gelb, dunkel-rot).

In Abb. 5.5 wird die physikalische Netzwerksicht aus der Fallstudie (s. Abs. 5.4) darge-stellt.

Abbildung 5.5.: Darstellung der physikalischen Netzwerksicht inklusive Aktorik/Sensorik undLeistungsversorgung

Die Grundidee besteht aus einem variablen Architekturansatz, der je nach Ausbau-stufe bis zu neun FlexRay-Steuergeräte umfasst. Analog zu den ersten Serienentwick-lungen /[NSF07]/ wird dabei auf modulare Architekturansätze zurückgeriffen, die sichaus aktiven Sternkopplersteuergeräten und konventionellen FlexRay-Steuergeräten zu-sammensetzen. StartUp-fähige Steuergeräte werden durch rote Schraffuren in Busan-bindungen und Sync-Steuergeräte durch eine rote Umrandung der Busanbindung ge-kennzeichnet. In diesem Ansatz wird das Gateway-Steuergerät als zentrales Steuergerätaufgefasst, welches je nach Ausbaustufe mit den Steuergeräten ACC Master, ACC Sla-ve, Fahrwerkskoordinator, Dämpfungskontrolle, ESP, Getriebe, Motronic, Sensorcluster verbun-den wird. Zur Gewährleistung einer optimalen physikalischen Signalübertragung mussbei mehr als fünf Steuergeräten ein aktiver Sternkoppler eingesetzt werden, um Über-tragungsdistanzen auf Basis passiver Bustopologien auf maximal fünf Teilnehmer zubegrenzen.

Die Sensoren und Aktoren werden vollständig außerhalb des FlexRay-Clusters mitdiskreten Zugängen an die verschiedenen Steuergeräte angebracht. Je nach Architek-turvariante werden verschiedene Sensoren integriert an das Sensorcluster angeschlos-sen oder verteilt mit unterschiedlichen Steuergeräten verbunden. Zusätzlich kann aufder PN-Ebene die Leistungsversorgung der Steuergeräte für die Fallstudie modelliert


werden, um beispielsweise DC/DC-wandlergestützte Steuergeräte oder das Klemmen-konzept im nächsten Schritt abzubilden. Zusätzlich wird unter anderem in Abb. 5.5die Partitionierung der Funktion FctActiveFrontSteering auf das Motronic-Steuergerät bei-spielhaft angezeigt.

5.1.2.4. WIR-Ebene

Die konkrete Verkabelung des FlexRay-Clusters erfolgt auf der WIR-Ebene mit folgen-den Schwerpunkten:

• Topologische Anordnung des Clusters (Bus, Stern, Hybrid)

• Stecker-/Pinbelegung des physikalischen Übertragungskanals (Erweiterbarkeit)

• Klemmenspezifkation (Kl.15/Kl.30-System)

Abbildung 5.6.: Verkabelungskonzept in der WIR-Ebene inklusive Steckerbelegung

In der Fallstudie werden die Steuergeräte ACC Master, ACC Slave, CDC und Getrie-be über den aktiven Sternkoppler CCU mit den restlichen Steuergeräten verkabelt. DieHerausforderung dabei ist, dass je nach Ausbaustufe die CCU entfallen kann, wodurchdie einzelnen Steuergeräte ACC Master, ACC Slave, CDC und Getriebe je nach Stecker-belegung und Pinverfügbarkeit an den aktiven Sternkoppler ZGW angeschlossen wer-den können. In speziellen Ausstattungsvarianten lassen sich die aktiven Sternkopplerbei Verbindung mit maximal zwei weiteren FlexRay-Knoten auch als konventionelleFlexRay-Steuergeräte (mit Standard-Transceiver) auslegen.

5.1.2.5. TOP-Ebene

In der TOP-Ebene werden die Verbaubereiche der einzelnen Steuergeräte festgelegt. AusSicht der FlexRay-Systemparametrierung interessieren dabei folgende Aspekte:

• Geometrische Dimensionierung einer Topologie,

• Restriktionen für den Verbau im Fahrzeug (Topologieeinschränkungen).


Abbildung 5.7.: Topologiemodell zur Auslegung der Verkabelungsgrößen des Bordnetzes

Bei der Betrachtung unterschiedlicher Fahrzeugbaureihen (Sportwagen (Heckmotor),Sportwagen (Mittelmotor), SUV) ergeben sich unterschiedliche Anforderungen an die Po-sitionierung der Steuergeräte im Fahrzeug. In Abb. 5.7 wird die Topologie für einenSUV in den Verbauorten konkretisiert. Im FlexRay-Systemdesign müssen die Abstän-de zwischen den einzelnen Steuergeräten ermittelt werden, da sich diese direkt auf diephysikalischen Verzögerungen im Netzwerk auswirken. Im weiteren Sinne lassen sichauch Einschränkungen im Bereich der Verbauumgebung identifizieren, etwa der vor-kommende Temperaturbereich oder EMV-Einflüsse. In der Fallstudie liegt der Fokusvorrangig auf der Behandlung unterschiedlicher Topologievarianten und deren Auswir-kungen im Wechselspiel mit den verbauten Halbleiterteilen (Transceiver, Quarze) auf diemöglichen zulässigen FlexRay-Systemkonfigurationen.

5.1.2.6. PK-Ebene

Auf der PK-Ebene fliessen folgende Aspekte in den Parametrierungsprozess ein.

• Standardsoftwarespezifikationen (Varianten),

• Hardwarespezifikationen (Alterungseffekte, Performanz, Ressourcen).

Die physikalischen Komponenten werden modulorientiert gestaltet, wobei explizite Be-ziehungen zwischen den Modulen vernachlässigt bleiben. Auf der Hardwareseite inter-essieren vorrangig die Eigenschaften des Quarzes für die zeitgesteuerte Kommunikationsowie die physikalische Terminierung und auf Softwareseite der Typ der Standardsoft-ware1. In Abb. 5.8 wird ein einfaches PK-Modell mit seiner Busanbindung dargestellt.

1Die Eigenschaften der Standardsoftware bleiben in dieser Umsetzung unterspezifiziert und werdenlediglich auf verschiedene SSW-Klassen (zuliefererspezifisch) reduziert.


Abbildung 5.8.: Komponentenstruktur eines FlexRay-Steuergeräts inklusive seiner Hard- undSoftwaremodule sowie der Busanbindung zu einem aktiven Sternkoppler

5.1.3. FlexRay-Parametrierungseditor (PE)

Die konventionelle Berechnung von E/E-Architekturmetriken basiert in dem gewähl-ten Ansatz auf individuell erstellbaren Berechnungsskripten. Bei der Erfassung undBerechnung der FlexRay-Konfiguration führt dieses Vorgehen zu Einschränkungen, dadie hohe Komplexität des FlexRay-Parametersatzes eine sinnvolle Dekomposition erfor-dert. Zusätzlich sollen neben der eigentlichen Systemparametrisierung auch benutzer-spezifische Qualitätskennzahlen erfasst werden, die bei der Berechnung und Verwal-tung inhaltlich von der Systemkonfiguration datentechnisch getrennt bleiben sollten.Eine statisch kodierte Umsetzung des vollständigen Parametersatzes in einem Werk-zeug führt zu starken Einschränkungen bei der Hinzunahme von anwenderspezifischenVorgaben (speziell bei der Substitution von Spezifikationskonstanten durch Parameter).Konsequenterweise muss der E/E-Architekt die Möglichkeit besitzen die Berechungs-vorschriften zur Entwicklung des FlexRay-Designs explizit im Rahmen des Architek-turdesigns spezifizieren zu können. In dieser Arbeit wird dafür auf die Entwicklungeines FlexRay-Parametrierungseditors (PE) zurückgegriffen, um die Eigenschaften derE/E-Architektur auf einen gültigen FlexRay-Parametersatz zu übertragen.

Das Grundkonzept des Editors basiert auf einem dreiteiligen Konzept. Dabei wirddurch spezielle Modellabfrageregeln auf Basis des Metamodells auf arbiträre Artefakteder E/E-Architektur zugegriffen, etwa alle Steuergeräte mit einem aktiven Sterntran-sceiver2. Diese Artefakte und deren Attribute dienen dabei als Eingangsparameter zurUmsetzung der FlexRay-Spezifikationsrestriktionen. Diese werden dabei algorithmischin Berechnungsblöcken skriptbasiert oder als JAVA-Code implementiert. Für den Son-derfall, dass anstatt eines berechneten Ergebnisses ein konstanter Wert für einen Berech-nungsblock verwendet werden soll, kann der Benutzer diesen statischen Wert dem Be-rechnungsblock zuweisen und explizit im Graphen selektieren. Die Berechungsblöckelassen sich über Datenverbindungen arbiträr verknüpfen. Eine Spezialfunktion liefertdabei die Join-Verknüpfung (vgl. /[KE04]/) zur Zusammenfassung mehrerer Modellab-frageergebnisse. Mit speziellen Analyseblöcken lassen sich visuelle Hilfen zur Interpre-tation von Berechnungsergebnissen integrieren (Aufzählungs-, Ampel-, Skalenblöcke).

2Die Umsetzung einer Modellabfrage wird in Anhang D.3 exemplarisch dargestellt.


In Abb. 5.9 wird beispielhaft ein Ausschnitt zur Berechnung der maximalen asym-metrischen Transceiververzögerung bei den beiden Gruppen der Sende- und Empfangs-steuergeräte in Form eines Metrikdiagramms dargestellt.

Abbildung 5.9.: Exemplarischer Ausschnitt eines Metrikmodells zur Berechnung der maximalenasymmetrischen Transceiververzögerung jeweils bei den Sender- und Empfängersteuergeräten

Durch eine variantenspezifsche Aktivierung von E/E-Artefakten lassen sich unter-schiedliche Eingabevektoren bei der Durchführung von Modellabfragen erzeugen, diezu architekturspezifischen FlexRay-Parametersätzen führen. Dadurch entsteht die Mög-lichkeit verschiedene E/E-Architekturen und deren Varianten direkt miteinander zuvergleichen. Gleichermaßen wird im weiteren Sinn die Abhängigkeit zwischen denkundenspezifischen Fahrzeugausstattungsanforderungen und der technischen FlexRay-Parametrierung direkt nachvollziehbar.

Ein Vorteil bei der expliziten Umsetzung des FlexRay-Parametersatzes in Graphen-form innerhalb des PE folgt aus den individuellen Strukturierungsformen und Dekom-positionsmöglichkeiten. So lassen sich atomare Strukturen im Parametersatz erfassenund reinstanziert in diversen Kompositionen der Berechungsgraphen wiederverwen-den. Dadurch bauen die Metriken aufeinander auf und die Auswirkung einer Modifika-tion eines Berechnungsblocks innerhalb der Parameterberechnung wird offensichtlich.

5.1.4. Roundtrip-Engineering

Um eine adaptierte FlexRay-Parametrierung zu erzielen ist es notwendig sämtlicheAbhängigkeiten der Parameterberechnungsformeln einzeln modifizierbar zu gestalten.Daher kann die Definition der FlexRay-Parameter nicht statisch auf Basis fixer For-meln (Constraints) der offiziellen FlexRay-Spezifikationen erfolgen. Dies lässt sich da-durch begründen, dass in der Regel zusätzliche strikte Vorgaben, beispielsweise voneinem Zulieferer, berücksichtigt werden, die sich in das starre Korsett der FlexRay-Berechnungsformeln einfügen müssen. Für diesen Zweck lässt die Validierung des Flex-ZOOMED-Ansatzes Freiräume für die Integration berechnungsunabhängiger Werte (s.Abb. 5.11). Im Sinne eines Roundtrip-Engineering-Ansatzes können dabei in den umge-setzten Berechnungsformeln bestimmte Attribute des E/E-Architekturmodells modifi-ziert und gleichzeitig neue Attribute berechnet werden. Dadurch wird die Modellent-wicklung und die Systemparametrierung in einem parallel ablaufenden Entwicklungs-stil vollzogen.


5.1.5. Parameteranalysesicht (PA)

Auf Basis arbiträrer Berechnungsergebnisse innerhalb des PE-Editors lassen sich dieWerte der individuellen Qualitätsmerkmale einer FlexRay-basierten E/E-Architektur inForm von Analyseblöcken messen. Durch eine direkte Gegenüberstellung von skalier-baren Analyseblöcken wird die Möglichkeit zur zentralen Erfassung der Eigenschaftenvon Architekturvarianten geschaffen.

x

Nutzdateneffizienz (%)

Ist Skalenwidget; Eingänge können ausgeblendet werden. Automatische Anordnung im Zentrum

EPL Erweiterbarkeit (-)Auslastung (%)

Jeder Eingang bekommt eine Skala. Ist der Eingang ein Vektor wird für jedes Element

eine Skala erstellt

fixiert möglich. Gruppierung: Anzeige einer

geschlossenen Linie.

Abbildung 5.10.: Parameteranalyse auf Grundlage spezifisch skalier- und komponierbarer Dia-gramme

Durch die unterschiedlichen spezifisch definierbaren Grenzwerte werden die Ska-lenblöcke als Diagrammachsen spezifiziert, die zu Netzdiagrammen miteinander ver-knüpft werden können. Durch die Skalierung entsteht die Möglichkeit zur Abgrenzungund zum verbesserten Vergleich von Architekturalternativen (s. Abb. 5.10 und 5.11).

1

gdMaxPropagationDelayCH

Wert = (7 , 5 )

Berechnet = (1.5 , 7.4)

LineLength

Wert = 15Berechnet = 13


Wert=(5.3,4) Berechnet=(4.5,6)

>

>

<

>

>

>

T0

Wert = 5.7Berechnet = 3.9

pdStarDelay

Wert = 7 , 5Berechnet = 1.5

>

>

gdXYZ

Wert=5.3 Berechnet=.5

<

>

Vorgaben

>

>

> in

Name der Abfrage 2 ContextID

Check: Konsistenzcheckregelname

>

MinDelay= 0.5 s (0..60)

MaxDelay=1.5 s (0..60)



>

>

>

>

Join>>

>

Einschränkung

Modellgroup A:

Modelgrop B

>>



>

x

>

>

>

>

>

Herstellergrenzen_01

>

>

>

MaxGreenCalculation

Wert = 35.7

Berechnet = 0>

>

<

>

>

>

in

MaxCalculation

Wert = 40.9

Berechnet = 0

>

>

MinGreenCalculation

Wert =1

Berechnet = 0

>

>

MinGreenCalculation

Wert = (14, 34.4)

Berechnet = 0

>

>

^ Herstellergrenzen_01

Abbildung 5.11.: Flexibel komponierbarer Parametrierungseditor mit Zugriff auf die Modelle-bene


Als Ergänzung zur Netzdiagrammdarstellung eignet sich die zentrale Ablage sämt-licher berechneter Aspekte des flexiblen zeitgesteuerten Systems in Tabellenform. DieseMetriktabelle filtert dabei die komplexen Diagramme des PE-Editors und unterstütztdie integrierte Interpretation bei der automatischen FlexRay-Parametersatzgenerierung.In Abb. 5.12 wird der Auszug aus einer FlexRay-Parametrierungstabelle dargestellt.

Abbildung 5.12.: Ausschnitt aus einer FlexRay-PE-Metriktabelle zur Interpretation einer E/E-Architekturvariante

In diesem Beispiel gibt es nur einen Ergebnisblock. Deshalb wird nur eine Zeile in derTabelle angezeigt. Bei einem Skalen- oder einem Aufzählungsblock wird das Ergebnisan Stelle des Ampelsymbols in der zweiten Spalte dargestellt.

5.2. Vorgehen bei der E/E-Architekturentwicklung

Wie in Abs. 2.5 beschrieben, wird die eigenständige Disziplin der E/E-Architektur-entwicklung durch das Bestreben der integrierten Entwicklung der Bereiche Hardware-topologien, Mechanik, Regelung, Funktionalität oder Software motiviert. In diesem Zu-sammenhang steht die Abbildung der E/E-Architektur auf mehrere Fahrzeugbaureihenund -derivate mit stringenten Anforderungen (Kosten, Gewicht, Verbrauch, Zuverläs-sigkeit) im Vordergrund (vgl. Abb. 5.13).

Unter diesen Prämissen werden sämtliche Modifikationen an der Architektur bei derEntwicklung durchgeführt. Als Modifikation versteht sich vor allem die Architekturer-weiterung durch die Integration einzelner Komponenten, Steuergeräte und -verbünde,deren Auswirkungen am Architekturmodell analysiert werden.

5.2.1. Systemintegration

Bei der Systemintegration stehen Aspekte der technischen und der logischen E/E-Ar-chitekturentwicklung im Vordergrund. Dabei kommt den folgenden Fragestellungen diegrösste Aufmerksamkeit zu:

Technische Systemarchitektur:

• Integration eines neuen Steuergeräts,

• Veränderung am Verkabelungskonzept (Stichleitungen, Zusatzleitungen, Lei-tungslängen, Leitungstypen, Aktive Sterne),

5.2. VORGEHEN BEI DER E/E-ARCHITEKTURENTWICKLUNG 215

FlexRay-Datenmodell

Berechnung & Check

AP2: Vorschläge am Modell

Navigation

QoS durch Metriken

Varianten-bewertungVVVaVVVaVVVVVVVVVVVVVVVVVVVVVVaVVVVVVa iriririiiiiiiiriananana teteteteteteteteteteetetetettennnnnnnnnnnnnnnnnnnnnnnnnn-------bebebebebebebebeebebebebebebebebebbebebbebebebebeeebebebebbebbeebbeeewewwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww rtttttttttununununununnunununununnnunnununnununnnnnnnunnnnunnunnnngggggggggggggggggggggggggggggggggggggggg

Highlights

Synthese

Nutzdaten-effizienz

Robustheit

Erweiterbarkeit

Performanz

Auslastung

Abbildung 5.13.: Validierung des FlexZOOMED-Ansatzes

• Substitution von Subkomponenten (μC, CC, Transceiver, Quarze),

• Migration der Leistungsversorgung (Generatorstützung, Versorgungsklemmen-konzept (Kl.15/Kl.30)),

• Globale Modifikation der Systemanforderungen (Performanz, Zuverlässigkeit).

Logische Systemarchitektur:

• Integration neuer Komponenten (Standardsoftware),

• Integration neuer Funktionalität (Applikationsebene, Systemebene (z.B. Diagnose,TP, NM)),

• Datenveränderungen (Botschaftslayout, Schedulelayout),

• Globale Modifikation der Systemanforderungen (Performanz, Zuverlässigkeit).

Ergänzend müssen übergreifende Modifikationen, etwa ein verändertes Plattform- undVariantenkonzept auf beiden Ebenen berücksichtigt bleiben. Im nächsten Schritt gilt esdiese Themen bei der Systemintegration im Rahmen der statischen und dynamischenSystemanalyse zu betrachten.

5.2.2. Statische Analyse

Die statische Systemanalyse verzichtet auf Systemsimulationen und lässt sich demzu-folge idealweise regelbasiert durch Entwicklung und Pflege von Metriken, Modellsuch-regeln und dem FlexRay-Parametrierungsmodells umsetzen.

5.2.2.1. Metrikkonzept

Zur Bewertung und Analyse der E/E-Architekturmodellvarianten werden Metrikskripteentwickelt, deren logische Struktur beispielhaft in Abb. 5.14 dargestellt ist.


Suche Randsegment (RS)

Suche auf dem Weg liegende Einbauorte

Suche zu den Einbauorten gehörende Komponenten

Berechne die Gesamtlänge der Leitungssegmente

Berechne Verzögerung durch Sterne

Berechne Verzögerung durch Steuergeräte

Berechne Verzögerung durch Leitungssegmente

Berechne den Parameter gdMaxPropagationDelay

Berechne den Parameter gAssumedPrecision

Suche Nachbarsegment (NS)

Schreibe berechnete und hardwarespezifische Parameter in Datei

while NS != RS

while ! started at all RS

Abbildung 5.14.: Struktur eines Metrikskripts zur hardwarespezifischen Berechnung vonFlexRay-Parametern

In diesem Beispiel werden die beiden hardwarespezifischen FlexRay-Parameterα1 =gdMaxPropagationDelay und α5 =gAssumedPrecision auf Basis der modellierten To-pologie und der verbauten Bauteile berechnet. Als nichtfunktionales Qualitätskriteriumlassen sich dabei parallel Kostenabschätzungen durchführen, die aufgrund der verbau-ten Hardwarekomponenten anfallen. Die berechneten Parameterwerte, die Kosten unddie hardwarespezifischen FlexRay-Parameter können prozessabhängig zur Dokumenta-tion oder zum Datenaustausch extrahiert werden, beispielsweise in einem zwischenge-lagerten Optimierungsschritt (s. Abs. 5.1). Aus der TOP-Ebene werden die Längen dereinzelnen Verbausegmente ermittelt. Dadurch lässt sich der FlexRay-Parameter

• LineLengthM,N

aus /[Fle05b]/ zur Spezifikation der gesamten Segmentlänge zwischen Knoten M undKnoten N durch eine Metrikberechnung erfassen. Aus der PN-Ebene werden zusätzlicheglobale FlexRay-Parameter bzw. Konstanten hinzugenommen:

• x32 =gClusterDriftDamping

• β1 =gdMaxMicrotick

• α3 =gdMinPropagationDelay

• c6 =cClockDeviationMax

5.2. VORGEHEN BEI DER E/E-ARCHITEKTURENTWICKLUNG 217

Neben den globalen Parametern ergänzen knotenlokale Parameter die Berechnung. Da-bei spielen vorrangig die Verzögerungsparameter an den Bustransceivern beim Sendenund beim Empfangen sowie die auftretenden Latenzen bei der Signalweiterleitung imaktiven Sternkoppler

• pdBDTx

• pdBDRx

• pdStarDelay

eine entscheidende Rolle (vgl. /[Fle05a]/).

5.2.2.2. Regelbasierte Prüfung

Neben dem Metrikkonzept profitiert die Validierung der E/E-Architekturmodellierungvon der werkzeuggestützten regelbasierten Prüfung des zugrunde gelegten Werkzeugs.In diesem Kontext orientieren sich Suchmuster am vorliegenden Metamodell und unter-stützen bei der Objektidentifikation für die Metrikberechnung oder verifizieren den Mo-dellstand auf Konsistenz (s. Abb. D.2). Speziell bei der Umsetzung komplexer Plattform-und Variantenstrukturen im Modell helfen zusätzliche Propagationsregeln zum automa-tisierten Gruppieren von Modellartefakten.

5.2.3. Dynamische Analyse

Der primäre Einsatzzweck der dynamischen Architekturanalyse im Kontext der Flex-Ray-Systemparametrierung konzentriert sich auf die Parameterauslegung für das Weck-und Startverhalten des Bussystems und die Parametrierung des Fehlerdegradierungs-modells (Übergange zwischen aktiver, passiver und angehaltener Kommunikation). Er-gänzend lässt sich die Auslegung des dynamischen FlexRay-Segments per dynamischerAnalyse umsetzen. Anfolgend wird eine einfache Umsetzung der Bereiche des Weck-/Startvorgangs und des Fehlerdegradierungsmodells erläutert.

Das Weckverhalten ist getrennt von dem Startvorgang zu betrachten, da im Fahrzeugin der Regel nicht alle Steuergeräte weckfähig ausgelegt werden, sondern teilweise auchhart mit Anliegen des Zündungsplus gestartet werden. In Abb. 5.15 wird die Protokoll-ausführungskontrolle eines FlexRay-Kommunikationscontrollers als gezeiteter Automatim Werkzeug UPPAAL dargestellt3.

Beim Weckvorgang stehen vordergründig die Phasen der Weckvorbereitung (Wake-Up-Listen-Phase), des eigentlichen Weckvorgangs (WakeUp-Send-Phase) und der Detek-tion von Kommunikationskollisionen beim Weckvorgang (WakeUp-Detection-Phase) imFokus. Diese Phasen hängen im Parametrierungsprozess direkt von der Auslegung derLänge der Weckvorbereitungsphase (pdListenTimeout) in Kombination mit detektierterKommunkation auf dem Bus (gListenNoise) und der Anzahl der zu sendenden Wecksym-bolen auf dem Bus (pWakeUpPattern) ab. Diese Parameter verzweigen selbst auf dritteParameter im Bereich des maximalen Uhrendrifts, der Buszykluslänge, der Mikrotick-länge im FlexRay-Kommunikationscontroller und der maximalen Uhrenabweichung im

3Die Umsetzung der POC fokussiert auf den Bereich des Weck- und Startvorgangs und beinhaltetergänzend partielle logische Anteile, die aus den SDL-Diagrammen der FlexRay-Spezifikation /[Fle05a]/entnommen wurden.


Halt

StartUp

Ready

Normal_Passive

Normal_Activex<=8

WakeUp

pWakeUpPattern1<=30

Default_ConfigConfig

x<=6

NodeIntegration2?

PrimaryColdstarter1

FollowingColdstarter1=true,x=6

WakeUpDecoded1 & WUPFinished1StartUpAttempt!

PrimaryColdstarter1=true

WakeUpAct1?

x=pWakeUpPattern1*(gdWakeUpTxLow+gdWakeUpTxIdle),WakeUpDecoded1=true

FollowingColdstarter1

NodeIntegration1!

x=8

WakeUpDecoded1 & WUPFinished1

StartUpAttempt?

WUPFinished1=trueWakeUpAct2!

x=0,WUPFinished1=false

x=0

Abbildung 5.15.: Simulation des dynamischen Verhaltens der FlexRay-Protokollengine zweierNetzknoten auf Basis gezeiteter Automaten

Cluster. Die Komplexität in der Analyse der zeitlichen Ausprägung des Weckvorgangsergibt sich aus den bei der Berechnung potentiell unterschiedlich auslegbaren Knoten-parametern sowie den probabilistischen Effekten beim Startvorgang, etwa für unter-schiedliche WakeUp-Initiatoren, detektierten Kommunikationsgeräuschen auf dem Busoder auftretenden Weckkollisionen zwischen den FlexRay-Kommunikationscontrollern.

Calc_Rate Calc_Offset

Init_Measurement Measurement

!cycleodd

ratecalculation=vRateCorrection

cycleodd

offsetcalculation=vOffsetCorrection

x=0,cyclecounter++

Abbildung 5.16.: Simulation des dynamischen Verhaltens des verteilten FlexRay-Synchron-isationsprozesses zweier Netzknoten auf Basis gezeiteter Automaten

Bei der Umsetzung des Ablaufs der FlexRay-Protokollablaufkontrolle in zeitgesteu-erte Automaten fällt auf, dass die semantischen Eigenschaften der Automaten im Bezugauf die verteilten zeitgesteuerten Architekturen mit Einschränkungen behaftet sind. Solassen sich die Sync-Transitionen zur Synchronisation mehrerer Teilnehmer nur an aus-gewiesenen Stellen einsetzen, etwa bei der Auslösung eines WUP auf dem Bus, welchesein dritter Knoten unmittelbar empfängt und dabei im Ablauf mit dem Sender eine Syn-chronisationsschnittstelle bildet. Allerdings ist es kaum möglich die probabilistischenEffekte während des dynamischen Vorgangs im Detail umzusetzen. Als Beispiel ist diePhase zur Erkennung des exakten Zeitpunkts bei der Detektion eines WUP-Patterns

5.3. OPTIMIERUNG 219

oder einer WUP-Kollision zu nennen. Dieser Problematik wird in dem Konzept durchdie Annahme der maximalen Latenzen bei den jeweiligen Transitionen und der Analysevon tolerierbaren Worst-Case-Szenarien entgegengewirkt. Theoretisch mögliche Extrem-fälle, beispielsweise bei einem fehlerhaften permanenten Wechsel zwischen kurzzeiti-ger Busruhe und Busaktivität (Dekodierung von WUP-Symbolen), können zu arbiträrenIterationen innerhalb der Weckvorbereitungsphase führen, was den Weckvorgang glei-chermaßen unbeschränkt verzögert.

5.3. Optimierung

Während der Entstehung dieser Arbeit sind in einer Studienarbeit /[Mai08]/ Metho-den zur Optimierung der Nutzdateneffizienz (respektive des Nutzdatenvolumens) imstatischen FlexRay-Segment und zur Auslegung des dynamischen FlexRay-Segmentserarbeitet worden. Die Ergebnisse der Umsetzung und Analyse der Optimierungskon-zepte mit der Werkzeugkette Matlab/Simulink /[The07a]/ werden in diesem Abschnittzusammengefasst.

5.3.1. Statische Segmentauslegung (Nutzdateneffizienz)

Für die Formulierung der Optimierungsprobleme der Nutzdateneffizienz für ein Flex-Ray-System werden die Funktionale Ne und Nv definiert. Diese Funktionale haben dieEigenschaften, dass deren Werteverlauf mit Sprungstellen behaftet ist, wodurch mit ei-nem der beiden untersuchten Optimierungsverfahren (nach Kuhn-Tucker) werkzeugge-stützt kein Ergebnis gefunden wurde.

1 2 3 4 50

5

10

15

20

25

Number of variables: 5

Cur

rent

poi

nt

Current Point

0 0.5 1 1.5 2 2.5 3 3.5 45

5.5

6

6.5

7

Iteration

Func

tion

eval

uatio

ns

Total Function Evaluations: 30

0 0.5 1 1.5 2 2.5 3 3.5 4-0.65

-0.6

-0.55

-0.5

-0.45

-0.4

-0.35

Iteration

Func

tion

valu

e

Current Function Value: -0.3907

Abbildung 5.17.: Graphische Veranschaulichung des errechneten Lösungsvektors xopt,1 mit derOptimierungstoolbox aus der Matlab/Simulink-Werkzeugkette


Im zweiten Ansatz wird der Optimierungsalgorithmus fmincon (s. Abb. 5.17) aus demOptimierungswerkzeugsatz von Matlab/Simulink verwendet. Für die Untersuchungenwird ein Startvektor xstart,i definiert, welcher als Eingabevektor in fmincon den optimier-ten Ausgabevektor xopt,i erzeugt. Der Parameter i beschreibt die jeweilige Iterationsstufeder sequentiellen Optimierungsläufe.

xstart,i =

⎛⎜⎜⎜⎜⎝

xi1xi2xi3xi4xi7

⎞⎟⎟⎟⎟⎠

i=1→

⎛⎜⎜⎜⎜⎝

318

0.012511

⎞⎟⎟⎟⎟⎠

i=2→

⎛⎜⎜⎜⎜⎝

42

0.04156

⎞⎟⎟⎟⎟⎠

i=3→

⎛⎜⎜⎜⎜⎝

350

0.012531

⎞⎟⎟⎟⎟⎠

xopt,i =

⎛⎜⎜⎜⎜⎝

xi1xi2xi3xi4xi7

⎞⎟⎟⎟⎟⎠

i=1→

⎛⎜⎜⎜⎜⎝

6.021.0

0.012516.01.0

⎞⎟⎟⎟⎟⎠

i=2→

⎛⎜⎜⎜⎜⎝

6.021.0

0.01255.01.0

⎞⎟⎟⎟⎟⎠

i=3→

⎛⎜⎜⎜⎜⎝

421

0.0524

⎞⎟⎟⎟⎟⎠

i=4→

⎛⎜⎜⎜⎜⎝

6.0127

0.012551

⎞⎟⎟⎟⎟⎠

Dabei fällt auf, dass bei der Umsetzung benutzerspezifische Verfeinerungen des Start-vektors benötigt werden oder manche Restriktionen nicht zwangsläufig eingehalten wer-den müssen. Beispielsweise kann das Restriktionsfunktional g6(x) unberücksichtigt blei-ben, falls kein optionaler zeitlicher Sicherheitsabstand (safety margin) zur Cliquenvermei-dung beim FlexRay-StartUp in der Systemparametrierung addiert werden soll.

Bei der Modifikation des Startvektors im Bereich der Abtastperiode und des Makro-ticks ergeben sich mit xi4 und xi7 in x(opt, 3) bessere Werte für Ne(x), was allerdings zuLasten der maximalen Baudrate und damit des verfügbaren Nutzdatenvolumens Nv(x)im System geht. Aus diesem Schritt leitet sich ab, dass die buszyklusbezogene Nutzda-teneffizienz nicht strikt mit der höchsten Baudrate (10Mbit/s) erreicht wird. Als weitereOption lässt sich die potentielle Nutzdatenlänge auf das Maximum von 127 Bytewörternerhöhen, dessen Wert im finalen Lösungsvektor x(opt, 4) auch bestätigt wird. Der ein-geschränkten Skalierbarkeit des statischen Segments durch die maximal umsetzbarenBotschaftsgrößen mit der Konsequenz einer minimalen Slotanzahl muss daher durchE/E-Architekturspezifische Anforderungen einer Mindestsendeslotanzahl mit Zusatz-restriktionen entgegengewirkt werden4.

Ne(xopt,i)i=1→ 39, 1% i=2→ 52, 5% i=3→ 58, 9% i=4→ 73, 4%

Bei der Betrachtung der erzielten Nutzdateneffizienz ergeben die Analysen mit fminconeine zulässige Steigerung um 34,3%, was einer Erhöhung des ersten ermittelten Nutz-dateneffizienzwerts Ne(xopt,1) um 87,7% entspricht.

5.3.2. Dynamische Segmentgröße

Im Abs. 4.6.4.2 wird die Theorie zur Berechnung des dynamischen FlexRay-Segmentsauf Basis einer empirischen Erfassung des Datendurchsatzes pro Zeitintervall im Fahr-zeug mit einem probabilistischen Ansatz dargestellt. Zur Veranschaulichung wird an-genommen, dass 3 Steuergeräte in einem FlexRay-Cluster im dynamischen Segment

4Beispielsweise lassen sich aus der Funktionsnetznotation und der Partitionierung der logischen aufdie technische Architektur Rückschlüsse auf die Mindestsendeslotanzahl ziehen

5.3. OPTIMIERUNG 221

kommunizieren. Dabei sendet jedes Steuergerät maximal 5 Botschaften pro Buszyklus.Die Anzahl der maximal auftretenden Botschaften im dynamischen Segment entsprichtfolglich ψ = 15. Durch Einsetzen in die Gleichungen für β11 und ρ ergibt sich dabei

• eine normalverteilte Nutzdatenlänge β11 = 90 [Bit], was einem zeitlichen Wertβ11 = 9 [μs] entspricht,

• eine Anzahl ρ = 3 [Minislot] = 3 ∗ x12 ∗ x7 [μs] = 36 [μs] an Minislots, die proBotschaft benötigt werden.

Dadurch wird für eine im dynamischen Segment verschickte Botschaft mit einem Nutz-datenanteil von β11 = 9 [μs] die entsprechende zeitliche Belegung ρ = 3 [Minislots] =3 ∗ x12 ∗ x7 [μs] = 36 [μs] im Buszyklus erwartet. Konsequenterweise müssen clusterweitmindestens α2 = ψ ∗ ρ = 15 ∗ 3 = 45 [Minislot] Minislots pro Buszyklus im dynamischenSegment bei der Systemparametrierung einkalkuliert werden.

5.3.3. Buszyklusauslegung (Nutzdatenvolumen)

Durch die Betrachtung des statischen Segments bei der Optimierung der Nutzdatenef-fizienz Ne(x) und der separaten Analyse des dynamischen Segments lassen sich dieEingangsparameter des Funktionals zur Nutzdatenvolumenberechnung weitestgehendeliminieren (s. Tab. 5.1).

Parameter Wertx1 6.0x2 127.0x3 0.0125x4 5.0x7 1.0x18 5.0α2 45.0β11 9.0β13 1.0β15 12.0

Tabelle 5.1.: Übersicht der aus Abs. 5.3.1 und Abs. 5.3.2 bestimmten Parameterwerte

Dadurch ergibt sich die lineare Zielfunktion Nv(x9, x10):

Nv(x9, x10) =10161385

∗ (x9 − x10) − 109728277

In /[Mai08]/ wird Nv(x9, x10) mit den teilweise nichtlinearen Komponentenfunktiona-len der zugeordneten Restriktionsabbildung Gv(x) als nichtlineares Optimierungspro-blem im Solver fmincon gelöst. Im numerischen Lösungverfahren wird die in der Restrik-tion g8(x) auftretende Buszykluszeit auf 5000 μs begrenzt und folgender Startvektorgewählt:

xstart =(

1000100

)


Daraus ergibt sich folgender Lösungsvektor:

xopt =(

5000.014.0

)

xopt liegt auf dem Rand des gültigen Wertebereichs und ergibt für das modifizierteNutzdatenvolumenfunktional einen Wert Nv(xopt) = 3261.5 [μs]. Da sich in den vorher-gehenden Optimierungsschritten bereits ein Makrotick x7 = 1 μs ergeben hat, entsprichtdie optimierte Zykluszeit x9 = 5000 [MT] der maximal zulässigen Vorgabe von 5000 μs.Die Netzwerkruhephase im Buszyklus zur Synchronisationskorrektur wird mit mindes-tens x10 = 14.0 [MT] berechnet5.

5.4. Fallstudie

Begleitend zur Entwicklung des FlexZOOMED-Ansatzes wird die Tragfähigkeit desKonzepts durch eine Fallstudie mit einem eigens aufgebauten E/E-Architekturmodelluntersucht. Die Inhalte der entwickelten Modelle orientieren sich pragmatisch an denErkenntnissen, die sich aus der Mitarbeit an serienvorentwickelnden und -begleitendenThemen ergeben. Sämtliche Inhalte sind daher seriennah angelegt, allerdings aus Wett-bewerbsgründen ohne direkten Zusammenhang zu einer real umgesetzten E/E-Archi-tektur eines Fahrzeugherstellers.

5.4.1. Modellübersicht

Die erstellten Modelle erstrecken sich über sämtliche Bereiche des in Abs. 5.1 vorge-stellten Validierungskonzepts. Die Grundidee basiert auf der durchgängigen Abbildungzweier Features eines Bremsassistenten auf eine logische E/E-Architektur in Form eineseinfachen Funktionsnetzwerks aus dem Bereich der Fahrwerks- und Antriebssysteme.Die logische Architektur wird fahrzeugvariantenabhängig auf unterschiedlich dimen-sionierte technische FlexRay-Architekturen partititioniert. Ziel dabei ist die architektur-variantenspezifische Erfassung der FlexRay-Parametrierung. Die Erkenntnisse bei derUmsetzung und Anwendung der Fallstudie werden anfolgend zusammengefasst.

5.4.1.1. E/E-Architekturmodell

Die den Modellen zugrunde gelegte E/E-Architektur umfasst alle in Abs. 5.1 darge-stellten Modellierungsebenen. Die einkanalige FlexRay-Architektur bildet dabei die In-frastruktur zur Vernetzung von neun Steuergeräten aus dem Antriebs-, Fahrwerks-und Fahrerassistenzbereich. Es werden dabei variantenabhängig verschiedene Funkti-onspartitionierungen umgesetzt, die auf unterschiedlichen Vernetzungstopologien be-ruhen (Bus-, Stern-, Doppelsterntopologie). Für jede Baureihe werden indidividuelle Packa-ge-Anforderungen berücksichtigt. Tab. 5.2 gibt einen Überblick über die Größen derrelevanten Modellelementmengen im E/E-Architekturmodell6.

5In Abs. A.3 wird das Nutzdatenvolumenfunktional dargestellt.6Die quantitativ größeren Mengen an Lowlevel-Modellelementen, beispielsweise die Hardwarekompo-

nenten, werden dabei nicht erfasst.

5.4. FALLSTUDIE 223

Logische Architektur|FC| |SRC| |PO| |SP| |RP|

15 75 150 60 90Technische Architektur

|ECU| |PC|,|NC| |CL| |WS| |PP|9 9 16 30 18

Tabelle 5.2.: Kardinalitäten der Modellelemente auf logischer und technischer Architekturebene

5.4.1.2. Variantenmanagement

Für die Generierung von Architekturvarianten werden im ersten Schritt alle Artefakteeines Modells in disjunkte Mengen gruppiert, die einer arbiträr definierbaren Klassifika-tion angehören, beispielsweise als Gruppen der ESP-Bauteile oder des Bremsassistenten.Vereinzelte Elemente der Architektur lassen sich dabei allerdings nicht eindeutig einerGruppe zuordnen, was zu potentiellen Inkonsistenzen im Modell führen kann und fall-spezifisch behoben werden muss. Exemplarisch lässt sich die Zuordnung konventionellangebundener Sensoren in der Architektur anführen. Ein Gierratensensor lässt sich ei-nerseits der Gruppe ESP-Elemente als zugehöriges Teil des ESP-Steuergeräts zuordnen.Andererseits ist der Gierratensensor auch ein Bestandteil der Gruppe Dezentrale Sensorik,falls in der Architektur kein zentrales Sensorcluster verbaut sein sollte.

Die entwickelten Modellgruppen werden den verschiedenen Konzeptvorlagen zuge-ordnet. Entsprechend wäre die Zuordnung einer Modellgruppe FlexRay-Vernetzung zueiner Vorlage Fahrwerksysteme plausibel, falls diese auf den Inhalt der Modellgruppe,einem FlexRay-Cluster, aufbaut. In dieser Fallstudie werden folgende Konzeptvorlagendefiniert (s. Tab. 5.3):

Konzeptvorlage: SoftwarefunktionenIntegriert Bremsen Fahrwerk Traktionsmanagement

Konzeptvorlage: SensorikHigh-End-Cluster Low-End-Cluster Dezentral -

Konzeptvorlage: EnergieversorgungDC/DC-Wandler Unabhängig - -

Konzeptvorlage: SteuergeräteVollständig Gruppe A Gruppe B Gruppe C

Konzeptvorlage: Vernetzungstopologie8-fach Stern 4-fach Stern Passiver Bus -

Konzeptvorlage: HalbleiterbauteileHQ-Quarz HQ-Quarz (ink. PLL) LQ-Quarz LQ-Quarz (ink. PLL)

Konzeptvorlage: StandardsoftwareZulieferer A Zulieferer B Proprietär -

Konzeptvorlage: VerkabelungKlemmenkonzept A Klemmenkonzept B - -

Tabelle 5.3.: E/E-Konzeptvorlagen und -instanzen des Variantenmanagements

Softwarefunktionen: Diese Gruppe zielt auf die Bündelung von Strukturen aus der logi-schen Architektursicht. Dabei werden neben den Funktionsblöcken auch deren Sende-und Empfangsports sowie verbundene Konnektoren zwischen den Ports miteinbezogen.

Senorik: Auf Seite der technischen Architekturentwicklung können Sensoren unter-schiedlich angebunden sein. Es wird dabei zwischen einer rein dezentralen Anbindungder Sensoren an verschiedene Steuergeräte und einer Bündelung innerhalb einer Einheit


als Sensorcluster unterschieden. Die Größe des Sensorclusters lässt sich in verschiedeneAusbaustufen einteilen.

Energieversorgung: Bei der Energieversorgung ergibt sich eine Differenzierung zwi-schen Komponenten, welche über die Batteriespannung ohne oder mit dazwischenge-schalteten Gleichstromkonverter (DC/DC-Wandler) betrieben werden. Dieser Aspektwirkt sich bei Spannungseinbrüchen im Bordnetz aus, bei dem nicht DC/DC-Wandler-gestützte Komponenten für eine kurze Dauer ausfallen können.

Steuergeräte: Aus technischer Sicht ist eine Gruppierung auf Steuergeräteebene sinn-voll. Beispielsweise wird in dieser Fallstudie ein sekundärer ACC-Sensor stets nur imVerbund mit einem primären Radarsensor verbaut.

Vernetzungstopologie: Aufgrund der physikalischer Eigenschaften und erhöhten Kos-ten muss der Einsatz aktiver Sternkoppler im Fahrzeug genau geplant werden. Daherwird zwischen passiven Bustopologien, 4-fach- und 8-fach-Sterntopologien unterschie-den.

Halbleiterbauteile: Die in der Architektur eingesetzten Halbleiterbauteile lassen sich jenach Kostenanforderungen in unterschiedliche Qualitätsstufen untergliedern. In der be-trachteten Fallstudie fokussiert dieser Bereich auf die Eigenschaften der Quarze für dieTakterzeugung in den FlexRay-Steuergeräten, wobei zwischen hochqualitativen Quar-zen und Standardquarzen (HQ und LQ) inklusive oder ohne Verwendung von PLLsdifferenziert wird.

Standardsoftware: Eine detaillierte Modellierung und Spezifikation der Eigenschaftenvon Standardsoftwaremodulen eines FlexRay-Steuergeräts liegt außerhalb des Fokusdieser Analyse. Daher beschränkt sich das Konzept der Standardsoftware auf eine ab-strakte Unterscheidung der erreichten Sende- und Empfangslatenzen bei der Netzwerk-kommunikation, die auf die Implementierungseigenschaften der Basissoftware in denSteuergeräten zurückgeführt werden kann, beispielsweise die Dauer für die Abarbei-tung eines Sendeaufrufs im Bustreiber. Zur Vereinfachung wird die Standardsoftware jenach Zulieferer oder Eigenentwicklung mit jeweils einheitlichen Werten für das Sende-zeitverhalten attributiert.

Verkabelung: Bei der Verkabelung interessieren vorrangig die Versorgungsklemmender verschiedenen Steuergeräte. Durch die Klassifizierung der FlexRay-Busteilnehmerin Sync- und Non-Sync-Knoten muss gewährleistet bleiben, dass je nach Konzept dieFlexRay-Kommunikation gegebenenfalls bereits im Vorlauf eines Motorstarts im Fahr-zeug etabliert werden kann (Klemme-30-Steuergeräte).

Parallel zu der Entwicklung und Befüllung der Konzeptvorlagen (vgl. Tab. 5.4) werdendie entwickelten Ausstattungsvorlagen den Fahrzeugbaureihen sowie deren Ausstat-tungsvarianten zugeordnet. Die Fallstudie setzt sich dabei aus den drei Fahrzeugbau-reihen Heckmotor-Sportwagen, Mittelmotor-Sportwagen und sportlicher Geländewagen (SUV)zusammen, für die jeweils zwei Ausstattungspakete aus den Bereichen (Basis, Komfort,Sport, Premium) definiert werden. In Tab. 5.4 wird die Zuordnung der Konzepte zu denBaureihen zur Erzeugung sechs unterschiedlicher Architekturvarianten dargestellt.

5.4. FALLSTUDIE 225

Sportwagen Sportwagen Sportwagen Sportwagen SUV SUV(HM) (Basis) (HM) (Premium) (MM) (Sport) (MM) (Premium) (Komfort) (Sport)

Fahrwerk Integriert Fahrwerk Integriert Bremsen Traktions-management

Dezentral Low-End-Cluster

Low-End-Cluster

High-End-Cluster

Low-End-Cluster

Low-End-Cluster

Unabhängig Unabhängig Unabhängig Unabhängig DC/DC-Wandler

Unabhängig

Gruppe B Vollständig Gruppe B Vollständig Gruppe A Gruppe BPassiver Bus 4-fach Stern 4-fach Stern 8-fach Stern 4-fach Stern 4-fach SternLQ-Quarz(ink.PLL)

HQ-Quarz(ink.PLL)

LQ-Quarz Plattformquarz HQ-Quarz(ink.PLL)

HQ-Quarz

Zulieferer B Zulieferer B Zulieferer A Zulieferer A Zulieferer B Zulieferer AKlemmen-konzept B

Klemmen-konzept B

Klemmen-konzept B

Klemmen-konzept A

Klemmen-konzept A

Klemmen-konzept B

Tabelle 5.4.: Variantenerzeugung für die drei Fahrzeugderivate auf Basis zweier Ausstattungs-pakete pro Fahrzeugklasse

5.4.2. Modellanalyse

Die Untersuchung der spezifizierten Architekturvarianten basiert auf dem in Abs. 5.1.3erläuterten Parametrierungseditor. Für den Zugriff auf die Architekturvarianten die-nen dabei Modellstrukturen, die regelbasiert innerhalb des Gesamtmodells identifiziertwerden. Um die Anzahl der Modellsuchregeln überschaubar zu gestalten, werden Basis-regelstrukturen geschaffen, die bei Bedarf per Join-Verknüpfung transformiert werdenkönnen. Die Zusammenführung und Weiterverarbeitung der Eingangsdaten zur Ablei-tung der Architektureigenschaften durch Berechnung der konkreten FlexRay-Parameterund der entwickelten Qualitätsmerkmalen erfolgt innerhalb von 134 programmiertenBerechnungsblöcken. Zur Analyse der erhobenen und berechneten Daten dient eineVielzahl an Auswertungsstrukturen in Form von Warnschaltern und kontinuierlichenoder diskreten Wertebereichen. In Tab. 5.5 werden die Kennzahlen zum entwickeltenParametrierungsmodell zusammengefasst.

Modellsuchregeln Join-Verknüpfungen Berechnungsblöcke Auswertungsstrukturen LoC

33 13 134 253 5758

Tabelle 5.5.: Kennzahlen zum entwickelten FlexRay-Parametrierungsmodell

5.4.2.1. Basiseigenschaften

Bei der Analyse der Grundeigenschaften der aus den Fallstudienmodellen ermitteltenFlexRay-Parameter fällt auf, dass sich die Architekturderivate am umfangreichsten imBereich der Konfiguration des physikalischen Netzwerks und bei den erfassten Quali-tätseigenschaften unterscheiden. Gleichzeitig ergeben sich Interferenzen bei vereinzel-ten Parametern bei der Mikro-/Makrotickskalierung (Abweichungen bei der Ausbrei-tungsverzögerung im System) oder der Uhrensynchronisation (unterschiedliche Anzahlverfügbarer Sync-Knoten).

Die jeweils zwei unterschiedlich ausgestatteten Fahrzeugderivate der drei untersuch-ten Baureihen weisen bereits für einheitliche Eingangsparameter (s. Abs. 4.6) unter-schiedliche Ausprägungen im Bereich der ableitbaren FlexRay-Parameter auf. Auch diebei der Analyse der konzipierten Qualitätskriterien ermittelten Werte auf E/E-Architek-turebene zeigen bereits Abweichungen zwischen den spezifizierten Varianten.


-0,05

0,00

0,05

0,10

0,15

0,20

-10 0 10 20 30 40 50

Statische Slots Dynamische Slots Symbole/SWIN/NIT

Physical Layer Microtick/Macrotick Uhreninitialisierung

Uhrensynchronisation Qualität

%

�z

Abbildung 5.18.: Gegenüberstellung der prozentualen Verteilung der abweichenden FlexRay-Parameter nach Klassifikationsgruppe und der durchschnittlichen z-Standardabweichung

Abb. 5.22 visualisiert ausgewählte Parameter in einer Netzdiagrammdarstellung. Umdie Ergebnisse in Relation setzen zu können werden die stark unterschiedlichen Wer-tebereiche der betrachteten Parameter (10−3-105) mittels einer z-Standardisierung ver-gleichbar gemacht7 (vgl. /[Nac08]/). Bei der Betrachtung des vollständigen Parameter-satzes werden neben den notwendig konfigurierbaren Parametern auch die Kennzah-len für die Qualitätsanalyse, Minimal-/Durchschnitts-/Maximalwerte sowie Konstan-ten, die durch Variation zur Systemoptimierung beitragen, berücksichtigt. Dadurch er-geben sich die in Abb. 5.22 dargestellten Eigenschaften. In dem Zusammenhang lassensich folgende Erkenntnisse feststellen:

Allgemeine Konfigurationsabhängigkeiten:

• (statische Slotlänge x19, Minislotlänge x8, physikalische Erweiterbarkeit) ↔ Topo-logieart x67) ↔ Verkabelungsparameter,

• Maximale Sync-Knotenanzahl x29 ↔ Anzahl verbauter Steuergeräte,

• Maximaler Initialisierungsfehler x36 ↔ (angenommene Systempräzision x30, ma-ximale Ausbreitungsverzögerung x6).

Informelle Erkenntnisse:

• Signalübertragungslatenzen variieren in den Empfangsknoten aufgrund unter-schiedlicher Leiterplattenverzögerungen in den Steuergeräten,

• Signalverzögerungen in DaisyChain-angebundenen Steuergeräten variieren je nachSteckerspezifikation,

7Anmerkung: Die Streuung liegt in dem Zusammenhang im Spitzenbereich bei bis zu 70% des arithme-tischen Mittelwerts für vereinzelte Parameter!

5.4. FALLSTUDIE 227

-2,50

-2,00

-1,50

-1,00

-0,50

0,00

0,50

1,00

1,50

2,00

pLatestTx_MaxgdMinislot

aFrameLengthDynamic_Max

gSyncNodeMax

gdMinPropagationDelay

Kabellänge (linearer Bus)

propagationDelay (verifiziert)

propagationDelay (zwei Sterne)

propagationDelay (ein Stern)

pDecodingCorrection_Max

nStarPath

endNodeDelay

gdTSSTransmitter

Kabellänge (ein Stern)


Kabellänge (zwei Sterne)

DaisyChain-Verzögerung

gdMaxInitializationErrorpdAcceptedStartupRange_Max

gAssumedPrecisionaBestCasePrecision

Buslast (Zellen)

Buslast (Slots)

Erweiterbarkeit

Sternastanzahl

Freie Slots

Freie Zellen

Asymmetrie

Bitlänge

Robustheit

Bitlänge (@TP4)

pOffsetCorrectionOut_Max

gdActionPointOffset_Robust

actionpointconversiondelta

gdWakeUpSymbolRxLow

aFrameLengthStatic

gdCASRxLowMaxpropagationDelay (linearer Bus)

Sportwagen_(Heckmotor)_(Basis) Sportwagen_(Heckmotor)_(Premium) Sportwagen_(Mittelmotor)_(Premium)

Sportwagen_(Mittelmotor)_(Sport) SUV_(Komfort) SUV_(Sport)

Abbildung 5.19.: Prozentuale Abweichungen zwischen ausgewählten FlexRay- und Qualitäts-parametern für sechs untersuchte Fahrzeugederivate

• Bei den Derivaten mit einem aktiven Stern gibt es Bandbreitenverluste bei derUmrechnung auf den ActionPoint gegenüber den Architekturen mit zwei aktivenSternen,

• Die maximale Ausbreitungsverzögerung, die Robustheit (Signalasymmetrie) unddie Synchronisationskorrekturen werden stärker durch die Sternanzahl als durchVerkabelungseigenschaften beeinflusst,

• Die Sensordatenfusion (Sensorcluster und Umfelderkennung) trägt zu wesentli-chen Buslastunterschieden bei,

• Unterschiede zwischen den Buslasten auf Slotbasis lassen sich nicht strikt auf Bus-lasten auf Zellenbasis im FlexRay-Buszyklus übertragen.

Ein Teilbereich der Modellanalyse konzentriert sich auf die Berechnung der physikali-schen Parameter der drei FlexRay-Architekturvarianten zur Ermittlung der maximalenAusbreitungsverzögerung α1 =gdMaxPropagationDelay, welche sich im Design des Sche-dules und bei der zulässigen Synchronisationskorrektur auf Basis der Systempräzisionsignifikant auswirkt. Dabei spielen die auftretenden Topologievarianten (passiver Bus,


aktiver Stern, zwei aktive Sterne) und die Hardwareeigenschaften (Transceiver-, Quarzei-genschaften) eine wichtige Rolle.

5.4.2.2. Topologien

In dieser Betrachtung stehen Modifikationen im Bereich der Fahrzeugtopologie der un-tersuchten Fahrzeugderivate im Vordergrund. Dabei werden folgenden Vorbedingungenangenommen.

• Die Anzahl statischer Kommunikationsslots wird architekturübergreifend festge-legt,

• Der Signalaufbau der verwendeten Transceiver ist architekturübergreifend iden-tisch.

Während der Fahrzeugentwicklung ergeben sich bei der Definition des Kabelbaumspotentielle Variationen zwischen den einzelnen Segmenten des konzipierten physika-lischen Bordnetzes (s. Abb. 5.20). In diesem Fall werden Modifikationen an der Längeeinzelner Kabelsegmente sowie ein Wechsel des verwendeten Kabeltyps mit verändertenSignalverzögerungseigenschaften betrachtet8.

AS1

SG3 SG4

SG1SG2

SG1

SG2

LO1LO3

LO2LO4 LO4 LO3

LO5

LO1LO6 LO9

LO8

AS1

SG3 SG4

SG1SG2

SG5

AS2SG6

SG7

LO7

LO2

SG3

SG4

AS2

SG7

SG6

SG5AS1

LO1 LO3LO2 LO4 LO4 LO2 LO4 LO3

SG1

LO4 LO3

LO5

LO1

LO6 LO9 LO8

LO7LO2

LO2

AS1

SG4

SG2

Phy

sika

lisch

es N

etzw

erk

(Allg

emei

n)S

teue

rger

äte/

Fahr

zeug

-M

appi

ngP

hysi

kalis

ches

Net

z (V

erba

uorta

bhän

gig)

Ver

kabe

lung

sweg

e

Fahrzeug (Sportwagen Heckmotor [Basis]) Fahrzeug (Sportwagen Mittelmotor [Premium])

SG3

Abbildung 5.20.: Analyse der physikalischen Bordnetzabmessungen auf Basis des Steuer-geräte/-Fahrzeug-Mappings

8Dämpfungseigenschaften des Kabels und Temperatureinflüsse werden in diesem Zusammenhangnicht weiter berücksichtigt.

5.4. FALLSTUDIE 229

1. Kabellängenmodifikation: In dieser Untersuchung werden sechs arbiträre Elemen-te zur Verlegung der Kabelbaumelemente im Fahrzeug modifiziert, wobei dreiElemente verkürzt und drei weitere Elemente verlängert werden (s. Abb. 5.21).

Topologiesegment Längenmodifikation (mm) Fahrzeugbaureihen [Varianten]

FlexRay Star 4a 2400 → 1700 (Sportwagen HM [Basis]/HM [Premium])FlexRay Star 4b 2500 → 4700 (Sportwagen MM [Premium, Sport])FlexRay Star 6 5200 → 6100 (Sportwagen HM [Premium]/MM [Premi-

um], SUV[Komfort])FlexRay Star 7 4200 → 3000 (Sportwagen HM [Basis])FlexRay Star 8 1000 → 2000 (Sportwagen HM [Basis]/MM [Premium])FlexRay Star 9 1400 → 600 (Sportwagen HM [Premium], SUV [Sport])

Tabelle 5.6.: Übersicht zu den baureihen- und variantenabhängigen Modifikationen am Kabel-baum

FR 4a

FR 4a

FR 4b

FR 4b

FR 6FR 6

FR 6

FR 7FR

8

FR8

FR9

FR9

Fahrzeug(Sportwagen Heckmotor [Premium])

Fahrzeug(Sportwagen Mittelmotor [Premium])

Fahrzeug(SUV [Sport])

Fahrzeug(Sportwagen Heckmotor [Basis])

Fahrzeug(Sportwagen Mittelmotor [Sport])

Fahrzeug (SUV [Komfort])

Abbildung 5.21.: Topologieschaubilder zu den baureihen- und variantenabhängigen Modifika-tionen am Kabelbaum

2. Kabeltypmodifikation: Im Sinne einer Kostenoptimierung wird ein Wechsel aufeinen günstigeren Kabeltyp mit einem erhöhten Signalverzögerungswert (0, 1ns/m→ 0, 5ns/m) betrachtet.

3. Steuergerätehinzunahme (Mittelknoten): Einfügen eines Steuergeräts zur Dämp-ferregelung als Mittelknoten auf einem Sternast, beispielsweise zwischen dem Ga-tewaysteuergerät als zentralen Sternkoppler und dem Getriebesteuergerät als End-knoten in der Baureihe Sportwagen HM mit der Basisausstattung. Dieser Eingriffwirkt sich stark auf die Performanz- und Robustheitswerte des Clusters aus. Diestatischen Slotgröße erhöht sich um ca. 7% und die Minislotgröße des dynami-schen Segments um 15%, welches zum Teil durch die deutlich schlechtere Action-pointskalierung und dem daraus resultierenden größeren Actionpoint (+23%) be-dingt ist. Aber auch die um 1,5m und damit 13,5% längere Verkabelung des Clus-ters in Sterntopologie trägt zur schlechteren Performanz bei. Die Gesamtpräzisionerhöht sich deutlich um 7,7%, was letztendlich zu einer um 6,3% niedrigeren stati-schen Nutzdateneffizienz führt mit einer Absenkung der statischen Slotanzahl von


-3,00

-2,00

-1,00

0,00

1,00

2,00

3,00

4,00

pLat

estT

x_M

ax

gdM

inis

lotA

ctio

nPoi

ntO

ffse

t

gdM

inis

lot

gdAc

tionP

oint

Off

set_

Nor

mal

2

pMac

roIn

itial

Off

setB

_Max

pMac

roIn

itia

lOff

setA

_Max

gNum

berO

fSta

ticSl

ots

gdM

inPr

opag

atio

nDel

ay

Kabe

lläng

e (li

near

er B

us)

prop

agat

ionD

elay

(ver

ifizi

ert)

prop

agat

ionD

elay

(zw

ei S

tern

e)

prop

agat

ionD

elay

(ein

Ste

rn)

Kabe

lläng

e (e

in S

tern

)

gdM

axPr

opag

atio

nDel

ay

Kabe

lläng

e (z

wei

Ste

rne)

gdM

axIn

itial

izat

ionE

rror

pdAc

cept

edSt

artu

pRan

ge_M

ax

gAss

umed

Prec

isio

n

aBes

tCas

ePre

cisi

on

Busl

ast (

Zelle

n)

Busl

ast (

Slot

s)

Frei

e Sl

ots

Frei

e Ze

llen

Nut

zdat

enef

fizie

nz (S

tatic

)

pOff

setC

orre

ctio

nOut

_Max

gdAc

tion

Poin

tOff

set_

Robu

st

gdSt

atic

Slot

actio

npoi

ntco

nver

sion

delta

prop

agat

ionD

elay

(lin

eare

r Bus

)

T0

Sportwagen_(Heckmotor)_(Basis) Sportwagen_(Heckmotor)_(Premium)

Sportwagen_(Heckmotor)_(Basis) (ΔKabellängen) Sportwagen_(Heckmotor)_(Premium) (ΔKabellängen)

Sportwagen_(Heckmotor)_(Basis) (ΔKabelverzögerung) Sportwagen_(Heckmotor)_(Premium) (ΔKabelverzögerung)

-0,80-0,60-0,40-0,200,000,200,400,600,801,001,201,40

pLat

estT

x_M

ax

gdM

inis

lotA

ctio

nPoi

ntO

ffse

t

gdM

inis

lot

gdAc

tion

Poin

tOff

set_

Nor

mal

2

pMac

roIn

itia

lOff

setB

_Max

pMac

roIn

itial

Off

setA

_Max

gNum

berO

fSta

ticSl

ots

gdM

inPr

opag

atio

nDel

ay

Kabe

lläng

e (li

near

er B

us)

prop

agat

ionD

elay

(ver

ifizi

ert)

prop

agat

ionD

elay

(zw

ei S

tern

e)

prop

agat

ionD

elay

(ein

Ste

rn)

Kabe

lläng

e (e

in S

tern

)

gdM

axPr

opag

atio

nDel

ay

Kabe

lläng

e (z

wei

Ste

rne)

gdM

axIn

itial

izat

ionE

rror

pdA

ccep

tedS

tart

upRa

nge_

Max

gAss

umed

Prec

isio

n

aBes

tCas

ePre

cisi

on

Busl

ast (

Zelle

n)

Busl

ast (

Slot

s)

Frei

e Sl

ots

Frei

e Ze

llen

Nut

zdat

enef

fizie

nz (S

tati

c)

pOff

setC

orre

ctio

nOut

_Max

gdA

ctio

nPoi

ntO

ffse

t_Ro

bust

gdSt

atic

Slot

actio

npoi

ntco

nver

sion

delt

a

prop

agat

ionD

elay

(lin

eare

r Bus

)

T0

Sportwagen_(Mittelmotor)_(Premium) Sportwagen_(Mittelmotor)_(Sport)

Sportwagen_(Mittelmotor)_(Premium) (ΔKabellängen) Sportwagen_(Mittelmotor)_(Sport) (ΔKabellängen)

Sportwagen_(Mittelmotor)_(Premium) (ΔKabelverzögerung) Sportwagen_(Mittelmotor)_(Sport) (ΔKabelverzögerung)

-0,80-0,60-0,40-0,200,000,200,400,600,801,001,201,40

pLat

estT

x_M

ax

gdM

inis

lotA

ctio

nPoi

ntO

ffse

t

gdM

inis

lot

gdAc

tion

Poin

tOff

set_

Nor

mal

2

pMac

roIn

itial

Off

setB

_Max

pMac

roIn

itial

Off

setA

_Max

gNum

berO

fSta

ticS

lots

gdM

inPr

opag

atio

nDel

ay

Kabe

lläng

e (li

near

er B

us)

prop

agat

ionD

elay

(ver

ifizi

ert)

prop

agat

ionD

elay

(zw

ei S

tern

e)

prop

agat

ionD

elay

(ein

Ste

rn)

Kabe

lläng

e (e

in S

tern

)

gdM

axPr

opag

atio

nDel

ay

Kabe

lläng

e (z

wei

Ste

rne)

gdM

axIn

itial

izat

ionE

rror

pdA

ccep

tedS

tart

upRa

nge_

Max

gAss

umed

Prec

isio

n

aBes

tCas

ePre

cisi

on

Busl

ast (

Zelle

n)

Busl

ast (

Slot

s)

Frei

e Sl

ots

Frei

e Ze

llen

Nut

zdat

enef

fizie

nz (S

tatic

)

pOff

setC

orre

ctio

nOut

_Max

gdAc

tion

Poin

tOff

set_

Robu

st

gdSt

atic

Slot

actio

npoi

ntco

nver

sion

delta

prop

agat

ionD

elay

(lin

eare

r Bus

)

T0

SUV_(Komfort) SUV_(Sport)

SUV_(Komfort) (ΔKabellängen) SUV_(Sport) (ΔKabellängen)

SUV_(Komfort) (ΔKabelverzögerung) SUV_(Sport) (ΔKabelverzögerung)

Abbildung 5.22.: Variantenabhängige, BR-bezogene standardisierte Abweichungen ausgewähl-ter FlexRay-Parameter bei Modifikationen am physikalischen Bordnetz

121 auf 113. Dementsprechend steigt die Buslast neben den zu versendenden Bot-schaften des Dämpfersteuergeräts um 7% auf Zellen- und Slotbasis an. Da sich dieasymmetrische Bitverkürzung um 8% aufgrund der Wandlung des p2p-Sternasteszu einem zusätzlichen linearen passiven Bus erhöht, sinkt die Systemrobustheitum 8,9% ab. Da aber in diesem Bereich keine negativen Werte erreicht werden,kann die entstehende Sterntopologie mit zwei linearen passiven Bussen ohne Be-denken eingesetzt werden.

4. Steuergerätehinzunahme (Endknoten): Hinzunahme eines einzelnen ACC-Steuer-

5.4. FALLSTUDIE 231

0

20

40

60

80

100

120

140

gdM

inis

lot

(MT

)

gdA

ctio

nP

oin

tOffse

t(M

T)

gSyncN

odeM

ax

gN

um

ber

OfS

taticS

lots

gdM

axP

ropag

atio

nD

elay

(us)

Kab

ellä

nge

(Ste

rnto

polo

gie

) (m

)

gA

ssum

edP

reci

sion (

us)

Busl

ast

Zel

len (

%)

Busl

ast

(Slo

ts)

(%)

Asy

mm

etri

e (n

s)

Nutz

date

nef

fizi

enz

(Sta

tic)

(M

bit

/s)

�A

ctio

npoin

t (%

)

Robust

hei

t (%

)

gdSta

ticS

lot

(MT

)

Sportwagen�(Heckmotor)�(Basis) Sportwagen�(Heckmotor)�(Basis) (+Mittelknoten)

Abbildung 5.23.: Auswirkung der Integration eines DaisyChain-Mittelknotens zwischen Stern-koppler und Endknoten auf den FlexRay-Parametersatz in einer Architekturvariante

geräts für die Baureihe SUV in der Ausstattungsvariante Sport und Anhängen desKnotens an einen der bisherigen Endknoten in der Topologie, der ohne Mittel-knoten mit dem zentralen Sternkoppler verbunden ist, beispielsweise das ESP-Steuergerät. Diese Ergänzung wirkt sich in diesem Fall nicht auf den FlexRay-Parametersatz aus, da die zusätzliche Verkabelung und das hinzugefügte Steuer-gerät die vorliegende Doppelsterntopologie nicht modifiziert und auch die maxi-male Kabellänge zwischen den am weitesten voneinander entfernten Endknotennicht weiter erhöht wird (Getriebe, Motorsteuergerät).

0

5

10

15

20

25

30

35

40

45

50

Kabel

länge

(Bust

opol

ogie

) (m

)

pro

pagationD

elay

(Bust

opol

ogie

) (u

s)

Kabel

länge

(Ste

rnto

pol

ogie

) (m

)

pro

pagationD

elay

(Ste

rnto

pol

ogie

) (u

s)

gdM

axP

ropagationD

elay

(us)

gdM

axIn

itia

liza

tionE

rror

(us)

gAss

um

edP

reci

sion

(us)

Asy

mm

etri

e (n

s)

Rob

ust

hei

t (%

)

�Act

ionpoi

nt

(%)

Sportwagen�(Heckmotor)�(Basis) Sportwagen�(Heckmotor)�(Basis�PB)

Abbildung 5.24.: Veränderungen im Parametersatz bei der Eliminierung des Sternkopplers ineiner Architekturvariante


5. Eliminierung des aktiven Sternkopplers: Reduzierung eines Sternasts mit den bei-den Steuergeräten für das Getriebe und die Dämpferregelung in der BaureiheSportwagen HM mit der Basisausstattung. Durch die Eingliederung der beidenKnoten auf dem verbliebenen Sternast entsteht aus der vorliegenden aktiven Stern-topologie ein linearer passiver Bus mit vier Teilnehmern. Der Topologiewechselbewirkt eine deutliche Vergrösserung der längsten zusammenhängenden Buss-truktur um 8,4m (91,6%) (s. Abb. 5.24). Die Kabellänge der passiven Bustopolo-gie übersteigt somit die maximale Kabellänge der einfachen Sterntopologie um5,4m. Dadurch erhöht sich die im System auftretende gesamte Ausbreitungsverzö-gerung um weitere 10,7% trotz des Wegfalls des aktiven Sternkopplers. Allerdingsverbessert sich das System ohne den Sternkoppler im Bereich der asymmetrischenBitverkürzung um 4,7ns (10,3%). Dadurch lässt sich die Robustheit deutlich erhö-hen bei einer sich nur minimal verschlechternden Actionpointübersetzung.

-40.00

-20.00

0.00

20.00

40.00

60.00

80.00

100.00

120.00

140.00

gdM

inis

lot

(MT

)

gdA

ctio

nP

oin

tOffse

t(M

T)

gSyncN

odeM

ax

gN

um

ber

OfS

taticS

lots

pro

pag

atio

nD

elay

(Doppel

ster

nto

polo

gie

)(u

s)

gdM

axP

ropag

atio

nD

elay

(us)

Kab

ellä

nge

(Ste

rnto

polo

gie

) (m

)

Kab

ellä

nge

(Doppel

ster

nto

polo

gie

)(m

)

gdT

SST

ransm

itte

r(g

dB

it)

gA

ssum

edP

reci

sion (

us)

Busl

ast

Zel

len (

%)

Busl

ast

(Slo

ts)

(%)

Asy

mm

etri

e (n

s)

Nutz

date

nef

fizi

enz

(Sta

tic)

(M

bit

/s)

Robust

hei

t (%

)

gdSta

ticS

lot

(MT

)

SUV�(Sport) SUV�(AdvancedSport)

Abbildung 5.25.: Einflüsse der Integration eines zweiten FlexRay-Sternkopplers auf den Para-metersatz einer Architekturvariante

6. Integration eines zusätzlichen Sternkopplers: Erweiterung der existierenden Aus-stattungsvariante Sport der Baureihe SUV um ein zentrales Steuergerät zur Fahr-werkskoordination. Dieses Steuergerät ist standardmäßig als aktiver Sternkopplerausgelegt. Mit diesem Schritt wird die Netzwerktopologie von einer einfachen zureiner doppelten Sterntopologie umkonfiguriert. Diese Veränderung an der Topolo-gie bewirkt eine Reihe an Änderungen im FlexRay-Parametersatz. So erfordert dieum 32% höhere Ausbreitungsverzögerung einen 25% längeren Actionpoint undführt daher zu 10% größeren statischen Slots und 20% größeren Minislots (s. Abb.5.25). Dadurch senkt sich die Nutzdateneffzienz um 9,2%, was einer Reduzierungder statischen Slots von 121 auf 119 entspricht. Anhand der zusätzlichen asym-metrischen Bitverkürzung (27,8%) und der daraus resultierenden Robustheitsver-schlechterung von knapp 35% lässt sich ableiten, dass eine Doppelsterntopologiekeinesfalls die Anforderungen eines Serieneinsatzes in diesem Fall erfüllen kann.

5.4. FALLSTUDIE 233

5.4.2.3. Partitionierung

1. Funktionsverschiebung: In der Baureihe Sportwagen MM wird für die Premium-Ausstattungsvariante eine Funktion des ESP-Steuergeräts in den Fahrwerksko-ordinator integriert. In diesem Zusammenhang werden Signale aus einer Bot-schaft des ESP-Steuergeräts in eine Botschaft des Fahrwerkskoordinators umpar-titioniert (Botschaft ESP_01 → Botschaft CCU_02). Diese Veränderung bleibt ohneAuswirkungen am FlexRay-Parametersatz und am Busschedule, da die Botschaf-ten ESP_01 und CCU_02 weiterhin mit identischen Zeitverhalten versendet wer-den und lediglich Signale innerhalb der Botschaften vertauscht worden sind.

2. Integration neuer Funktionalität: Zur Verbesserung der Fahrdynamik wird in derBaureihe Sportwagen MM für die Sport-Ausstattungsvariante eine elektrische Ak-tivlenkung konzipiert. Für die Umsetzung wird eine neue Funktion in die Archi-tektur integriert, die im Zusammenspiel mit zwei weiteren bereits existierendenFunktionen (FctActiveFrontSteering, FctChassisStabilization) über zwei Empfangs-und einem Sendeport interagiert. Für die Umsetzung werden zwei Signale aus derBotschaft CCU_02 empfangen. Da die neue Funktion ins ESP-Steuergeräts parti-tioniert wird, wird eine neue Botschaft ESP_03 versendet. Zusätzlich wird einezeitliche Adaption einer Botschaft des Motorsteuergeräts (Botscha f t Mot1 → 5ms)erforderlich. Durch die logische Erweiterung wird der Parametersatz beibehalten,wobei sich die Kennzahlen für die Buslasten verändern. Dabei fällt auf, dass dieBuslast auf Slotebene stärker ansteigt als auf Zellenebene (2,7% zu 1,0%). Dies liegtdaran, dass durch die Zykluszeitanpassung die Multiplexbotschaft des Motorsteu-ergeräts auf mehrere Slots verteilt werden muss, die sich allesamt allerdings nurpartiell befüllen lassen.

3. Sensorclusterung: In der Baureihe Sportwagen HM wird für die Basis-Ausstattungs-variante ein Umstieg des dezentralen konventionellen Sensorikansatzes auf einLow-End-Sensorcluster untersucht. Für dieses Vorhaben ersetzt ein eigenes amFlexRay-Bus hängendes Sensorcluster-Steuergerät die bisher verteilt angebunde-nen Beschleunigungs- und Ratensensoren. Dabei wird neben dem Steuergerätauch sein Transceiver und der Stecker für die neue Architekturvariante berücksich-tigt. Die Anbindung erfolgt über jeweils zwei Pins zwischen Sensorcluster und Ga-tewaysteuergerät. Das verbindende Kabelsegment muss aufgrund der Partitionie-rung im Dachbereich des Fahrzeugs um zwei Topologiesegmente (FlexRay_Star_1,FlexRay_Star_Kabel5b) eine Länge von 5000mm besitzen. Auf der logischen Ebenelassen sich zwei Funktionen des Sensorclusters (FctAccelerationSensorAnalysis, Fc-tAngleSensorAnalysis) verwenden, die über neun zusätzliche Sendeports Signale invier zusätzlichen Botschaften mit spezifischen Zeitverhalten auf dem FlexRay-Busverschicken. Gleichzeitig entfällt eine Botschaft des ESP-Steuergeräts, da derenSignale jetzt innerhalb der Sensorclusterbotschaften übertragen werden. In Abb.5.26 werden die beiden Architekturkonzepte gegenübergestellt. Bei der Umstel-lung auf das Sensorcluster ergeben sich aufgrund des zusätzlichen SteuergerätsVeränderungen im Bereich der Kabellänge (24%), der Ausbreitungsverzögerung(13%) und damit auch bei der Systempräzision (5%). Die Anzahl der zur Verfü-gung stehenden statischen und dynamischen Slots bleibt durch die Veränderungunberührt, wobei die Buslast aufgrund der neuen Botschaften des Senorclustersum 1,8% auf Zellenbasis und um 2,65% auf Slotebene ansteigt.


0

10

20

30

40

50

60

70

gdM

inis

lot

(MT

)

Maxim

ale

Sync-

Knot

en

Pro

pagati

on D

elay (

1-Ste

rn)

(us)

Kab

ellä

nge

(1-S

tern

)(m

)

gdM

axP

ropagati

onD

elay

(us)

gA

ssum

edP

reci

sion (

us)

Erw

eite

rbark

eit

Ste

rnas

tanza

hl

gdA

ctio

nP

oin

tOffse

t(r

obust

) (M

T)

�Act

ionpoin

t (%

)

Busl

ast

Zel

len (

%)

Busl

ast

(Slo

ts)

(%)

Konventionelle Sensorik Einsatz eines Sensorclusters

Abbildung 5.26.: Veränderungen im Parametersatz bei einer Modifikation des Sensorikkonzepts

5.4.2.4. Systemoptimierung

Neben der Untersuchung der physikalischen Eigenschaften der E/E-Architektur inter-essiert in der Fallstudie auch die Effizienz des Busses auf logischer Ebene. Da die ver-fügbare Nettodatenrate des Bussystems direkt mit der Flexibilität in der Auslegungdes Bordnetzes korreliert, wird in diesem Abschnitt die vorher statisch festgelegte Slot-Anzahl spezifisch für jedes zur analysierende Fahrzeugderivat berechnet. Dabei wirdvorausgesetzt, dass die Topologieabmessungen in der jeweiligen Ausprägung perma-nent gültig bleiben.

0

2

4

6

8

10

12

14

Buslast Zellen (VO)(%)

Buslast Zellen (NO)(%)

Buslast (Slots) (VO)(%)

Buslast (Slots) (NO)(%)

�Actionpoint (VO) (%) �Actionpoint (NO) (%) Bandbreitenerhöhung(Slots)

SUV�(Sport) SUV�(Komfort) Sportwagen�(Mittelmotor)�(Sport)

Sportwagen�(Mittelmotor)�(Premium) Sportwagen�(Heckmotor)�(Premium) Sportwagen�(Heckmotor)�(Basis)

Abbildung 5.27.: Buslasten im statischen Segment für alle Architekturvarianten vor und nachder Makrotickskalierung

1. Performanzsteigerung: Eine Performanzsteigerung lässt sich durch eine Abstim-mung des zu konfigurierenden Makroticks mit der in der Architekturvariante vor-herrschenden Systempräzision erreichen. Für diesen Zweck werden die errechne-ten Daten für die relevante Präzision für jede Ausstattungsvariante einer Baureihein der Berechnung des Makroticks berücksichtigt. Ziel ist es die zeitliche Differenzzwischen dem Actionpoint und der Systempräzision (ΔActionpoint) zu minimie-ren. Dabei wird ersichtlich, wie in Abb. 5.27 dargestellt, dass sich die Buslast in

5.4. FALLSTUDIE 235

der Fallstudie mit einem optimierten Makrotick im statischen Segment um bis zu5% absenken lässt. Dies entspricht durchschnittlich 4,3 Slots für die sechs Archi-tekturvarianten.

2. Robustheitssteigerung: Als Referenzbeispiel für eine allgemeine Erhöhung der Ge-samtsystemrobustheit wird an dieser Stelle die Möglichkeit zur Reduzierung derBitlängenverkürzung untersucht. Für diesen Zweck werden die FlexRay-Para-metersätze für alle Architekturvarianten mit der standardmäßig vorgeschriebe-nen Quarzgenauigkeit für FlexRay-Systeme (1500ppm) berechnet. In einer erstenOptimierungsstufe substituieren genauere Quarze (300ppm) die Standardquarzein allen Steuergeräten. Als zweite Modifikation werden anschließend alle PLL-Uhrenkonzepte in den Knoten eliminiert. Bei der Umsetzung zeigt sich, dass sichdie asymmetrische Bitverkürzung beim Quarzwechsel um durchschnittlich 4,4%und bei einem PLL-Verbot um durchschnittlich 5,8% in den angelegten Archi-tekturvarianten reduzieren lässt (s. Abb. 5.28). Grundsätzlich erfüllt keine derdefinierten Topologien im Worst-Case die gegebenen Robustheitsanforderungen,wobei bereits die Uhrenmodifikation dazu führt, dass drei Varianten die Robust-heitsvorgaben für die Bitlänge erreichen. Mit dem PLL-Verbot verbessert sich dieRobustheit aller Varianten, wobei sich die Anzahl der validen Topologien nichterhöht9.

-40

-20

0

20

40

60

80

Asymmetrie (ns) Asymmetrie (Uhr)(ns)

Asymmetrie (PLL)(ns)

Robustheit (%) Robustheit (Uhr)(%)

Robustheit (PLL)(%)

Tx�Rx�Max (ns) Tx�Rx�Max (Uhr)(ns)

Tx�Rx�Max (PLL)(ns)

SUV�(Sport) SUV�(Komfort) Sportwagen�(Mittelmotor)�(Sport)

Sportwagen�(Mittelmotor)�(Premium) Sportwagen�(Heckmotor)�(Premium) Sportwagen�(Heckmotor)�(Basis)

Abbildung 5.28.: Veränderung der Systemrobustheit anhand der asymmetrischen Bitlängenver-kürzung unter Einsatz unterschiedlicher Uhrenkonzepte

5.4.3. Bewertung

Im Folgenden werden die grundlegenden Erkenntnisse aus der Fallstudie zusammenge-fasst. Die automatisierte Berechnung variantenabhängiger FlexRay-Parametersätze aufE/E-Architekturebene lässt sich im FlexZOOMED-Konzept vollständig valideren. Wäh-rend der aktiven Modellierung und Parametrierung haben sich folgende Vorteile ge-zeigt:

9Durch die durchgeführten Optimierungen lässt sich die an den Transceivern enstehende Verzögerungum ca. 25% reduzieren!


• Integrierte Betrachtung heterogener Systemaspekte (Logische/Technische Archi-tekturen),

• Unterstützung statischer und dynamischer Systemanalysen,

• Feingranulare variantenabhängige Optimierung des Architekturdesigns,

• Automatisierte Entwicklung von FlexRay-Konfigurationen (Parametersatz undBusschedule)

Die vielversprechenden Vorteile müssen jedoch eine Reihe an Einschränkungen kom-pensieren:

• Initialaufwand bei der Modellierung FlexRay-konformer Architekturen,

• Hohe Komplexität durch wechselseitige Verknüpfung der Berechnungsblöcke undModellartefakte,

• Trennung von Berechnungs- und Architekturmodellen,

• Hoher Aufwand für Modellkonsistenzsicherung und -weiterentwicklung,

• Hoher Zeit-/Rechenaufwand bei der Systemanalyse,

• Sehr hohes Expertenwissen notwendig.

Während der Implementierung des E/E-Architekturmodells, des FlexRay-Berechnungs-modells und bei der Durchführung der Systemanalyse haben sich eine Vielzahl an po-tentiellen Weiterentwicklungsmöglichkeiten gezeigt, welche im Kap. 6 im Rahmen einesallgemeinen Ausblicks erläutert werden.

KAPITEL 6

Zusammenfassung und Ausblick

In diesem letzten Abschnitt werden die in der Arbeit erzielten Ergebnisse zusammengefasst und die ausden unterschiedlichen Forschungstätigkeiten gewonnenen wissenschaftlichen Erkenntnisse dargestellt.Nach einer kritischen Bewertung der erarbeiteten Methode lassen sich Schlüsse über Potentiale für zu-künftige Entwicklungen ziehen, die in einem Ausblick integriert betrachtet werden.

Die vorliegende Arbeit befasst sich mit der Frage einer zweckmäßigen Entwicklungs-methodik für flexible zeitgesteuerten Bussysteme in der Fahrzeugserientwicklung amBeispiel der FlexRay-Technologie. Das Umfeld der Bussystementwicklung im Fahrzeugwird umfassend untersucht und dabei die zukünftigen Schwerpunkte der modellgetrie-benen Entwicklung, der Systemoptimierung und der Systemanalyse abgeleitet. Diese dreiAspekte stellen die zentralen Themen der Arbeit, deren Ergebnisse zusammengefasstwerden.

6.1. Ergebnisse

In der Grundlagenforschung zur Entwicklung eingebetteter Systeme im Automobil hatsich gezeigt, dass in naher Zukunft das Potential eines erhöhten nutzbaren Bandbrei-tenbedarfs eine treibende Kraft hochvernetzer Fahrerassistenzsysteme im PKW-Bereichdarstellen wird. Die Vorteile einer flexiblen Zeitsteuerung mit ihrer deterministischenzuverlässigen Datenübertragung sind dabei bislang als sekundär einzustufen. Diese Er-kenntnis beruht auf der Tatsache, dass flexible zeitgesteuerte Architekturen im direk-ten Vergleich mit den im Serienbereich etablierten ereignisgesteuerten Systemen miteinem Komplexitätsanstieg einhergehen. Speziell die statischen Eigenschaften und diedamit verbundene umfangreiche und mit Wechselwirkung behaftete Systemkonfigu-ration erfordern ein verstärktes Verständnis für integrierte Systementwicklung. Eine

237

238 KAPITEL 6. ZUSAMMENFASSUNG UND AUSBLICK

anwendungsbezogene allgemeine Strategie zur Systemparametrierung des Feldbussys-tems fehlt. Eine Analyse existierender Entwicklungsmethoden und -werkzeuge ver-stärkt die Erkenntnis, dass ein globales architekturbezogenes Systemdesign für flexi-ble zeitgesteuerte Architekturen bisher nur unzureichend auf den Stand der Technikabgebildet wird. Eine technisch fundierte Argumentation zur Herleitung einer E/E-Architekurbezogenen FlexRay-Systemspezifikation steht bisher aus. Daraus resultiertdie Zurückhaltung einer Vielzahl an Fahrzeugherstellern im Kontext eines FlexRay-Serieneinsatzes.

Die Analyse der Einflussfaktoren für den Entwurf eines FlexRay-Systems führt aufallgemeine Fragestellungen der E/E-Architekturentwicklung, etwa bei Systemvariantenin der logischen und technischen Systemkonfiguration. Dieser Erkenntnis wird in dervorliegenden Arbeit Rechnung getragen. In Abgrenzung zu existierenden Ansätzen isteine neuartige durchgehende Einbettung der Anforderungen für die Entwicklung einerQuerschnittstechnologie erzielt worden, wobei spezifische Anforderungen im Kontextder modellbasierten E/E-Architekturentwicklung berücksichtigt werden. Dabei werdendie logischen und technischen Aspekte auf eine akzeptable Eingangskomplexität fürdie Gesamtsystementwicklung heruntergebrochen sowie das Abstraktionsniveau aufder Systemspezifikationsebene erhöht. Dadurch lassen sich Fragestellungen des tech-nischen Systementwurfs im Entwicklungsprozess zeitlich nach vorne verlagern (FrontLoading).

Durch die Überführung des FlexRay-Entwurfs auf eine abstrakte Spezifikationsebe-ne ergeben sich zusätzliche Fragestellungen für eine optimierte Systemauslegung undAnalysierbarkeit der Architekturen. Bei der Anwendung ausgewählter Optimierungs-verfahren zeigt sich, dass der Freiheitsgrad in der Systemparametrierung nicht eindeutigeinschränkbar ist. Die systematische Hinzunahme eigens definierter Restriktionen zurEinschränkung des Lösungsraums, etwa im Bereich der Skalierung der Anzahl an ge-wünschter Slots im statischen FlexRay-Segment, ist dabei entscheidend. Speziell die Ab-leitung dieser Restriktionen aus dem E/E-Architekturmodell bleibt eine weiterführendeAufgabe. Die Integration der FlexRay-Systemparameter in statische und dynamischeArchitekturmodelle zeigt sich in der Arbeit als komplexe Aufgabe, etwa bei der Analy-se der netzwerktopologieabhängigen Parameter. Die Methoden zur Modellprüfung undParameterberechnung gilt es daher weiterzuentwickeln, um den damit verbundendenArbeitsaufwand zu verringern.

Zusammenfassend lässt sich folgern, dass die architekturorientierte FlexRay-System-entwicklung ein sinnvolles Konzept zur integrierten Fahrzeugentwicklung und -pflegedarstellt, welches allerdings mit hohem Aufwand einhergeht. Doch gerade die damitabbildbare Systemkomplexität eröffnet die Möglichkeit für ein grundlegendes System-verständnis für die Anforderungen einer zielorientierten E/E-Architekturentwicklungund -optimierung. Die in dieser Arbeit entwickelte FlexZOOMED-Methode konzentrietsich auf die systematische Herleitung FlexRay-basierter E/E-Architekturen. Im Rahmenkünftiger industrieller Entwicklungen werden partielle Konzepte der entstandenden Ar-beit zur Weiterentwicklung existierender E/E-Plattformen eingesetzt werden. Eine tiefeIntegration und weitergeführte Entwicklung der erarbeiteten Ergebnisse stellt eher einelängerfristige Herausforderung dar und ist mit einem zusätzlichen Forschungsaufwandverbunden.

Die in dieser Arbeit erzielten Ergebnisse bilden einen Ausschnitt aus einer dreijähri-gen industriellen Forschungstätigkeit im direkten Umfeld der Fahrzeugserienentwick-lung. Sämtliche Arbeitsinhalte beziehen sich auf Querschnittsumfänge aus der Fahr-

6.2. AUSBLICK 239

zeugserienentwicklung, die in keinster Weise als vollständig zu betrachten sind. Ausbli-ckend werden die interessantesten Ansatzpunkte für potentielle Weiterentwicklungenim nächsten Abschnitt erläutert.

6.2. Ausblick

Gezwungenermaßen muss sich diese Arbeit auf wesentliche Gesichtspunkte beschrän-ken. Die Durchschlagskraft der entwickelten Methodik würde sich bei einer Ausweitungdes Gesamtkonzepts auf folgende Themen erhöhen:

Busscheduling: Eine erweiterte Umsetzung des automatisierten Busschedulings aufBasis vorliegender Funktionsnetze kann die Pflege des Bussystems auf dem ab-strakten Level der Funktionsbeschreibung verbessern. Gleichzeitig wird die Inte-gration neuer Steuergeräte oder Steuergerätfunktionen vom Aufwand der manu-ellen Bedatung des Busschedules befreit.

Restfahrzeug: Während in dieser Arbeit der Fokus weitestgehend auf flexible zeitge-steuerte Architekturen autark vom Restfahrzeug gelegt worden ist, erfordert ei-ne ganzheitliche Entwicklung der E/E-Architekturen die Betrachtung sämtlichertechnischer Aspekte und Technologien. Speziell die Analyse heterogener Architek-turen auf Basis eines gemischt agierenden CAN-FlexRay-Systemverbunds ist beider Verschiebung von Funktionen zwischen CAN- und FlexRay-Steuergeräten vonhoher Bedeutung.

Komplexitätsreduktion: Die Entwicklung und Pflege modellbasierter Architekturen imKontext der FlexRay-Systementwicklung benötigt eine zeitlich und inhaltlich in-tensive Vorlaufphase zur Erhebung sinnvoller und valider Daten. Weiterhin stelltdie Integration dieser Daten in die E/E-Architekurmodelle eine anspruchsvolleAufgabe dar, die sich durch die Erhöhung des Reifegrads von Metamodellen mes-sen lässt. Eine ausgereifte Bedatung der E/E-Architektur führt aus Netzwerksichtzu kritischen Modellgrößen, die bei der Erstellung und Pflege hohen Aufwanderfordern. Auch die Fehlerfreiheit in den Modellen lässt sich durch die Restriktio-nen der Semantik eines Metamodells nur teilweise erfüllen. Dies resultiert aus derTatsache, dass sich ein Metamodell in einer permanenten Entwicklung befindetund dem Entwickler einen gewissen Spielraum in der Modellierung einräumenmuss. Um die Abbildung diverser Entwicklungskonzepte verschiedener Anwen-dungsbereiche in unterschiedlichen Industriepositionen nicht zu stark durch denDesignflow des Werkzeugs einschränken zu müssen, birgt diese Offenheit im Ent-wicklungsprozess gewisse Risiken. Eine Maßnahme zur Steigerung der Qualitätwäre die Identifikation von Klonen in einem Modell, um die Strukturierung undWiederverwendung der Modelle zu verbessern.

Sensitivitätsanalyse: Durch den hohen Grad an wechselseitigen Abhängigkeiten zwi-schen den FlexRay-Parametern kommt es bei Modifikationen in den E/E-Archi-tekturmodellen zu partiellen Veränderungen im FlexRay-Parametersatz, welche inder Analysesicht zu untersuchen sind. Um die Zusammenhänge zwischen einzel-nen Modifikationsschritten am Modell und deren Auswirkungen auf den Parame-tersatz besser zu verstehen, bieten sich Methoden zur Sensitivitätsanalyse an, um


die Eigenschaften der E/E-Architektur und die Auswirkungen von Modellände-rungen werkzeuggestützt nachvollziehen zu können.

Timing-Visualisierung: Eine explizite Darstellung der Zeitabhängigkeiten im Konzeptder Zeitkettenbildung innerhalb des Funktionsnetzwerks bildet einen weiterenSchritt zur Interpretation von funktionalen Erweiterungsmöglichkeiten der E/E-Architektur. Zusätzlich wäre es interessant, die Abhängigkeiten zwischen Teilgra-phen des Funktionsnetzwerks und deren Abbildung im Steuergeräte- und im Bus-schedule in einer eigenständigen Darstellung zu pflegen. Speziell bei der bussyn-chronen Applikationsentwicklung bietet sich dies an. Jedoch zeigt sich in dieserArbeit auch die Kritikalität der Entwicklung vernetzter busasynchroner Applika-tionen. Eine systematische Herleitung eines stabilen busasynchronen Funkionsver-bunds stellt in gleicher Weise eine Herausforderung, die in einem Zeitmodell zuanalysieren ist.

Integrierter Schedulability-Test: In Ergänzung einer Timing-Visualisierung bietet essich an auf Basis des modellierten Zeitverhaltens eine holistische Scheduling-Analy-se durchzuführen. Dazu müssten allerdings die internen zeitlichen Abläufe, diewährend der Steuergeräteausführung auftreten, explizit spezifiziert werden. Aufdieser Basis wäre ein Schedulability-Test aufsetzbar.

Automatisierte Modellierung: Die Erstellung und Pflege eines FlexRay-Architektur-modells ist mit einem beträchtlichen Aufwand verbunden. Eine sukzessive Au-tomatisierung in der Modellentwicklung würde dabei neben einer Effizienzsteige-rung in der Entwicklung des Modells auch zu einer reduzierten Komplexität undFehleranfälligkeit bei der Modellierung führen. In dieser Arbeit sind die entwi-ckelten Modellartefakte regelbasiert auf Konsistenz geprüft worden. Speziell imBereich der logischen und technischen Architekturbeschreibung wären vorkonfek-tionierte Modellkomponenten hilfreich. Dadurch würde sich der Entwicklungs-stil stärker vertikal über die Modellierungsebenen hinweg für einzelne Architek-turkomponenten gestalten, was einer Abkehr von dem Konzept der horizontalenEntwicklung einzelner Ebenen mit anschließender Ebenenverknüpfung entspricht.

Automatisierte Testfallgenerierung: Durch die vollständige Beschreibung des Flex-Ray-Clusters in der Systemarchitektur lassen sich je nach Notationsform aus denmodellierten Artefakten Testfälle ableiten, welche durch Überführung in nachge-lagerte Werkzeugketten und Prüfständen weiterverarbeitet werden.

Weiterentwickeltes Variantenmanagement: Während der Umsetzung der FlexZOOM-ED-Methode in einer integrierten Entwicklungsumgebung ist in dieser Arbeit derEntwicklungsstand des Variantenmanagements innerhalb der verfügbaren Werk-zeugkette eingesetzt worden. In diesem Ansatz lassen sich die Varianten durchangelegte Schablonen, welche ein Gesamtmodell filtern, darstellen. Der Nachteildieser Methodik liegt in der expliziten Auswahl einzelner Fahrzeugbaureihen imE/E-Architekturmodell, die anschließend unabhängig voneinander analysiert wer-den. Dadurch kann ein direkter Vergleich unterschiedlicher Architekturvariantennur sequentiell durchgeführt werden. Interessant wäre eine Weiterentwicklung zursimultanen Betrachtung von n Architekturvarianten, um die Unterschiede werk-zeuggestützt erfassen und interpretieren zu können.

6.2. AUSBLICK 241

Kostenfunktionen: Das Thema Kostenkalkulation wird in dieser Arbeit nicht gesondertberücksichtigt. Neben der technischen Untersuchung einer integrierten modellba-sierten E/E-Architekturentwicklung für FlexRay-Systeme bietet es sich durchausan die entwickelten Architekturen hinsichtlich der erwarteten Kosten zu analysie-ren. Dies kann direkt über die Betrachtung unterschiedlicher Hard-warealternativen oder abstrakt, etwa über die Gewichtung von Bandbreitenver-brauch oder der Aufwände für Systemmodifikationen, erfolgen. Für diese Belangewäre allerdings ein eigenständiges Kostenmodell inklusive spezifischer Kosten-funktionen zu entwickeln.

Probabilistische Verfeinerung der dynamischen Architekturanalyse: Einige Aspekteder FlexRay-Systembetrachtung korrelieren mit probabilistischen Annahmen, bei-spielsweise bei der Betrachtung der Netzwerkkommunikation im dynamischenFlexRay-Segment oder den Abläufen beim Netzwerkweck- und -startvorgang. In-nerhalb der erarbeiteten Ergebnisse ist für die Netzwerkkommunikation eine Ab-straktion durch die Annahme einer Normalverteilung im Auftritt der ereignisge-steuerten Botschaften geschaffen worden. Für den Weck- und Startvorgang bleibendie Auswirkungen von potentiellen Kollisionen bei der Kommunikation auf demÜbertragungskanal unberücksichtigt und werden durch Worst-Case-Annahmen er-setzt. Die Analyse der Auswirkungen der probabilistischen Einflüsse auf das Ge-samtsystem bildet eine Erweiterung.

Verfeinerung der FlexRay-Abbildungen: Während der Fokus in dieser Arbeit auf Re-striktionen in der Netzwerkkonfiguration abzielt, wäre eine verfeinerte Abbildungder FlexRay-Protokollalgorithmen speziell für die dynamische Architekturanalysedenkbar. Eine formale Darstellung dafür ist auf Basis von SDL-Notationen bereitsin der FlexRay-Spezifikation vorhanden. Dabei muss allerdings beachtet werden,dass dieser Ansatz neben einer beträchtlichen Komplexitätssteigerung stark voneiner sauberen Implementierung der verwendeten FlexRay-Bauteilen abhängt, umdie erbrachten Analyseergebnisse zuverlässig verifizieren zu können.

Erweiterung der angewendeten Optimierungsverfahren: Zur qualitativen Verbes-serung der angewandten Optimierungsverfahren müssen weitere Restriktionenformuliert werden, um den existierenden Freiheitsgrad für die Wahl der Ein-gangsparameter in der Optimierung zur verringern und die Aussagekraft der er-mittelten Ergebnisse zu verbessern.

Schnittstellenverhalten in der Komponentensicht: Während die Thematik der Ent-wicklung bussynchroner Applikationen vorrangig auf das Ausführungsverhaltender Steuergeräte auf Betriebssystemebene beschränkt wird, zeigt sich mit der Ent-wicklung des AUTOSAR-Standards /[AUT07a]/ die Notwendigkeit der fundier-ten Betrachtung treibernaher Standardsoftware. Dafür wird eine explizite Spezi-fikationsebene in der E/E-Architekturmodellierung erforderlich. Bei der Umset-zung dieser Arbeit auf eine integrierte Entwicklungsumgebung wird bisher nurzwischen Standardsoftwarevarianten als monolithische Einheiten unterschieden.Eine erweiterte Sicht zur Standardsoftwarespezifkation wäre auf Komponentene-bene zukünftig vorteilhaft.

Integrierte dynamische Architekturanalyse: Die in dieser Arbeit betrachteten Aspekteder dynamischen Analyse sind getrennt von der statischen Analyse in dem Werk-


zeug UPPAAL /[BLP+96]/ untersucht worden. Dadurch wird eine Kopplung mitsämtlichen Attributen aus dem E/E-Architekturmodell verhindert. Eine sukzessi-ve Integration einer formalisierten Notation für die dynamische Architekuranalyseinnerhalb des modellierten E/E-Architekturmodells bildet eine evolutionäre Wei-terentwicklung für die vorgestellte integrierte Entwicklungsumgebung.

Funktionale Sicherheit: Der funktionalen Sicherheit wird aufgrund des Anwendungs-felds der fortgeschrittenen Fahrerassistenzsysteme bei der FlexRay-Vernetzung zu-künftig mehr Aufmerksamkeit zukommen. Eine spannende Frage ist die integrier-te Betrachtung notwendiger Absicherungskonzepte für sicherheitskritische Archi-tekuren im System, etwa bei der Injektion von Fehlerzuständen zur Modellanalyseund den Methoden für Fehlerbehandlungen.

Korrektheitsnachweis der Parameterentwicklung: Eine zertifizierter Parametersatz istunerlässlich für die Freigabe von FlexRay-Systemen in Fahrzeugserienprojekten.Bisher werden entsprechende Testverdikte zur Zertifizierung hardwarebasiert vonunabhängigen Institutionen betreut und auf die herstellerspezifischen Parame-tersätze angewendet. Mittelfristig sollte eine Verifikation der entwickelten Para-metersätze bereits beim Hersteller erfolgen, um den Aufwand zur Freigabe zureduzieren. Eine interessante Fragestellung liegt im Korrektheitsnachweis durchdie automatisierte Prüfung des FlexRay-Parametersatzes als Teil der vorgestelltenWerkzeugumgebung.

Werkzeugkopplung zur Optimierung: Die Untersuchungen zur Optimierung von Flex-Ray-Parametersätzen mittels numerischer Optimierungsverfahren erfolgt in dervorgestellten Methode auf Basis einer autarken Untersuchung im Werkzeug Mat-lab/Simulink. Eine Werkzeugkopplung zwischen Matlab/Simulink und dem E/E-Architekturmodell in PREEvision wäre zur integrierten Optimierung des E/E-Architekturmodells vorteilhaft, um die manuellen Schritte zwischen Modellierungund Optimierung zu umgehen. Damit wäre es möglich die Methode der Architek-tursimulation /[Sch06]/ mit der statischen Architekturanalyse zu koppeln.

Glossar

Application DataDaten, welche in Tasks erzeugt und/oder verwendet werden. Im Kontext der Au-tomotive Systems werden oft Signale als Format für die Kommunikation von Tasksuntereinander verwendet..

BackboneEin Übertragungsmedium, auf dem der gesamte Datenverkehr zwischen mehrerenSystemen ablaufen kann. In der Vernetzung könnte ein Backbone einen schnellenBus darstellen, an dem die Gateways sämtlicher anderer Bussysteme hängen, umsämtliche Daten untereinander austauschen zu können..

BitstopfenUnter Bitstopfen (bit stuffing) versteht man im Zusammenhang mit der CAN-Technolgie das Einfügen eines Bits in eine monotone Datensequenz (5 gleiche Bitsmit dem logischen Wert 0 oder 1) bei der Übertragung, um die Korrektheit desübertragenen Bitstroms an den Empfänger zu signalisieren. Dieser Mechanismusgarantiert einen regelmäßigen Flankenwechsel auf der Bitebene, der zur Synchro-nisation der Netzwerknoten erforderlich ist. Der Empfänger detektiert und ent-fernt das zusätzlich eingefügte Bit, um die eigentlichen Nutzdaten wiederherzu-stellen..

Botschafts-IDDieser Identifkator definiert die Slot-Position im statischen Segment und die Prio-risierung des Rahmens für das dynamische Segment. Ein niedriger Identifikatorsignalisiert eine höhere Priorität. Es ist zwei Kommunikations-Controllern nichtgestattet Rahmen mit dem gleichen Identifikator auf dem gleichen Kanal zu ver-schicken..

BusEine physikalische Topologie für ein Kommunikationssystem, in der alle Knotenüber eigene Zugangsleitungen (Stichleitungen) an ein gemeinsames Übertragungs-medium direkt angeschlossen werden (ohne die Verwendung von Sternen, Gate-

243

244 Glossar

ways, etc.). Den Begriff Bus assoziert man zusätzlich mit dem Übertragungsmedi-um ansich..

Bus driverEine elektronische Komponente, bestehend aus einem Transmitter und einem Re-ceiver, der den Kommunikations-Controller mit einem Kommunikationskanal ver-bindet..

Bus guardianEine elektronische Komponente, die den Kommunikationskanal vor nicht autho-risierten Eingriffen (Interferenzen) schützt. Ein nicht authorisierter Eingriff beziehtsich auf einen Sendezugriff zu einem arbiträren nicht vorgesehenen Zeitpunkt imSchedule des Clusters. Dies wird erreicht durch die Freischaltung des Kanals für denKommunikations-Controller ausschließlich zu den für ihn reservierten Zeitpunktenim Schedule..

Bustreiber= Bus Driver.

ChannelSiehe Kommunikationskanal.

Channel idleDer Zustand der Ruhe auf einem Kommunikationskanal, welcher von jedem an-geschlossenen Knoten erkannt wird..

CliqueEine Menge von Kommunikations-Controllern, welche die selbe Sicht auf bestimm-te Systemeinstellungen haben, beispielsweise die globale Zeit oder den Aktivi-tätszustand von Kommunikations-Controller n. Für die Zwecke eines konsistentenCluster-StartUps dürfen sich in keinem Fall zwei konkurrierende Cliquen bilden,die durch einen simultanen StartUp versuchen jeweils einen eigenen Schedule zuinitialisieren..

ClusterEin aus mehreren Knoten bestehendes Kommunikationssystem, dessen Teilneh-mer mindestens mit einem gemeinsamen Kanal verbunden sind (Bus Topologie)oder über Sternkoppler (Sterntopologie) zusammengeführt werden. Falls alle Kno-ten zweikanalig verbunden sind werden die Kommunikationspfade zwischen ar-biträren Knotenpaaren dupliziert und die Übertragungszuverlässigkeit erhöht..

Coldstart nodeEin spezieller Knotentyp, welcher die Fähigkeit besitzt eine StartUp-Botschaft zuversenden, um eine Cluster-StartUp-Prozedur einzuleiten. Eine Anforderung andiese Knoten ist, dass sie in einem 2-Kanalnetzwerk in jedem Fall zweikanaligausgelegt sein müssen..

Communication controller (CC)Eine elektronische Komponente in einem Knoten, der für die Implementierung derProtokolle des FlexRay-Kommunikationssystems verantwortlich ist..

Glossar 245

Communication slotEin Zeitintervall, indem der Zugriff auf dem Kommunikationskanal exklusiv ei-nem Knoten gewährt wird zur Übertragung eines Rahmens mit einer Frame-ID,welche korrespondiert mit der Slot-ID. FlexRay unterscheidet zwischen statischenund dynamischen Slots..

Cycle counterDer Zähler, welcher die aktuelle Nummer des Kommunikationszyklus beinhaltet..

Cycle timeDie Zeit, innerhalb des Kommunikationszyklus, ausgedrückt in Makrotick-Ein-heiten. Zu Beginn jedes Kommunikationszyklus wird die Zykluszeit auf Null zu-rückgesetzt..

Cyclic Redundancy CheckEin Datensicherungsmechanismus, mit dem durch einen an die Botschaft ange-hängten Prüfcode, beim Empfänger die Korrektheit der eingetroffenen Datente-legramme verifiziert werden kann. Dieser Prüf-Code stellt dabei den Rest der Di-vison des Datentelegramms durch ein speziell definiertes Generatorpolynom dar.Dadurch kann mit einer erneuten Divison des Datentelegramms mit angefügtenPrüf-Code durch das Generatorpolynom beim Empfänger Fehler entdeckt werdenund gegebenenfalls die Botschaft verworfen werden..

Dynamischer SlotEin Zeitintervall innerhalb des dynamischen Segments eines Kommunikationszy-klus, welches je nach Übertragungsdauer eines Rahmens einen oder mehrere Mi-nislots andauern kann. Eine Zugriff erfolgt wie im statischen Teil über Frame-IDs,allerdings muß man die Identifikatoren hier als Priorisierungsnummer betrachten,da ein Slot nach Belieben ausgedehnt werden kann bis der nächste Teilnehmer mitder nächsthöheren ID an der Reihe ist. Ein lineares Mapping von Frame-ID zumSendezeitpunkt im Schedule wie für den statischen Bereich kann daher hier nichtbeobachtet werden. Falls in einem Slot nicht übertragen wird entspricht die Längeeines dynamischen Slots der eines Minislots..

Dynamisches SegmentEin Abschnitt des Kommunikationszyklus, in dem der MAC-Zugriff über ein Mi-nislotting-Schema kontrolliert wird, welches nach dem FTDMA-Prinzip (FlexibleTime Division Multiple Access) arbeitet. Innerhalb diesem Segments erfolgt derZugriff auf das Übertragungsmedium dynamisch anhand einer Priorisierung derzu übertragenden Botschaften zwischen den Knoten..

E/E-ArchitekturDie logische und technische Ausprägung aller zusammenhängenden Elektrik-/Elektronikkomponenten von Fahrzeugbaureihen. In der Regel bildet die E/E-Architektur die Übermenge aller potentiell verbaubarer Elektrik-/Elektronik-komponenten. Die Bezeichnung Architektur entstammt der Idee der strukturier-ten, integrierten Planung und Entwicklung aller E/E-Anteile im Fahrzeug. Aktuellverbindet man dem Begriff in erster Instanz die physikalische Ausprägung, wobeidie logische Sicht ein wesentliches Element im Entwurf darstellt..

246 Glossar

Electronical Control Unit (ECU)Die technische und praktische Umsetzung einesKnotens in einem FlexRay-System. Dazu gehört die Stromversorgung, der Host,der Kommunikations-Controller, der elektrische Bustreiber und der Bus Guardian..

FlashenDer Vorgang, indem ein ausführbarer übersetzter Code auf ein Steuergerät über-führt wird, um ihn im Cluster starten und stoppen zu lassen..

FrameEine Struktur zum Austauschen von Informationen in einem Kommunikationssys-tem. Ein Frame besteht aus einem Header-, Payload-, und Trailer-Segment. Der Hea-der überträgt Statusinformationen des gesamten Rahmens, die Payload beinhaltetdie Nutzdaten und das Trailer-Segment wird zur Rahmenverifikation mittels einesCRCs verwendet..

GatewayEin Knoten, an dem zwei oder mehrere unabhängige Kommunikationsnetze hän-gen und deren Informationen über diese Komponente hinweg zwischen den Net-zen fliessen können..

Globale ZeitEine Kombination von Zykluszähler und Zykluszeit..

Hamming AbstandDer minimale Abstand (Anzahl der von einander abweichenden Bits) zwischenzwei beliebigen Code-Wörten in binärer Schreibweise..

HostDer Host ist die Komponente einer ECU, an der die Applikations-Software ausge-führt wird. Getrennt wird der Host durch die CHI von der Protokoll-Engine..

Knoten= Node.

KommunikationskanalDie Verbindung, zwischen der die Knoten Botschaften oder Signale austauschenkönnen für die Zwecke einer Kommunikation miteinander. Diese Bezeichnungwird abstrahiert von der Topologie (Bus,Stern) und vom physikalischen Übertra-gungsmedium (elektrisch/optisch) benutzt..

KommunikationszyklusEine komplette Instanz der Kommunikationsstruktur, welche periodisch wieder-holt wird, um die Zugriffsmethode auf das FlexRay-System komprimieren zu kön-nen. Ein Kommunikationszyklus besteht aus einem statischen Segement, einemoptionalen dynamischen Segment, einem optionalen Fenster für die Übertragungvon Symbolen und ein abschließendes Segment für die Netzwerkruhe (NetworkIdle Time)..

Glossar 247

KonnektorEine Steckverbindung, um Netzwerkkomponenten miteinander zu verknüpfen..

MakrotickEin Zeitintervall, dessen Dauer von dem cluster-weiten Taktsynchronisationsalgo-rithnmus abgeleitet wird. Ein Makrotick besteht aus einer ganzzahligen Menge vonMikroticks. Ein Makrotick repräsentiert die feingranularste Einheit für die Zweckeder globalen Zeit..

Medium idleDer Zustand des physikalischen Übertragungsmediums, indem kein Knoten aktivsendet..

MicrotickEin Zeitintervall, direkt übernommen vom Oszillator des Kommunikations-Con-trollers (möglicherweise durch Verwendung eines Vorverteilers). Der Mikrotickwird nicht durch den Taktsynchronisationsmechanismus beeinflusst, da er einknotenlokales Medium darstellt. Unterschiedliche Knoten können mit unter-schiedlichen Mikrotick-Perioden arbeiten..

MinislotEin Zeitintervall innerhalb des dynamischen Segments des Kommunikationszy-klus, welches von konstanter Dauer (in Bezug auf Makroticks) ist und von demsynchronisierten FTDMA MAC-Schema für den Zweck der Arbitrierung auf demÜbertragungsmedium verwendet wird..

NetzwerkDie Kombination von Kommunikationskanälen, welche die Knoten in einem Clus-ter verbinden..

NetzwerktopologieDie Anordnung der Verbindungen zwischen den Knoten eines Netzwerks. FlexRayunterstützt Bus-, Stern-, kaskadierte Stern-, und hybride Netzwerktopologien..

NodeEine logische Einheit, verbunden in einem Netzwerk, welches in der Lage ist Rah-men zu senden und/oder zu empfangen. Ein Node ist eine Abstraktion eines Steu-ergeräts..

Null frameEin Rahmen ohne verwendbare Daten innerhalb des Nutzdatensegments. Ein NullFrame wird über ein speziell ausgezeichnetes Indikatorbit des Header Segmentsspezifiziert und hat sämtliche Bytes des Payload-Segments auf Null gesetzt..

Physikalisches ÜbertragungskanalEine Knotenverbindung zur Übertragung von Signalen für die Zwecke einer Kom-munikation zwischen den Knoten. Alle über diese Verbindung zusammenge-schlossenen Knoten teilen sich die identischen elektrischen oder optischen Signale(demzufolge ist ihre Verbindung nicht unterbrochen durch Signalverstärker, Ster-ne, Gateways, etc.). Beispiele für eine physikalische Verbindungsleitung wären ein

248 Glossar

einzelnes Backbone oder eine Punkt-zu-Punkt-Verbindung zwischen einem Knotenund einem Stern. Ein Kommunikationskanal kann durch die Kombination mehre-rer physikalischer Verbindungsleitungen zusammen mit Sternen gebildet werden..

PräzisionDie Worst-Case-Abweichung zwischen korrespondierenden Makroticks zweier be-liebiger synchronisierter Knoten in einem Cluster..

ScheduleEin zeitlich bedingter Ablaufplan, in dem die Zugriffszeitpunkte der Kommuni-kations-Controller in den einzelnen Knoten geregelt ist, um eine Koordination derKommunikation und ungewollte Konflikte bei dem Zugriff auf das Übertragungs-medium verhindern zu können..

Slot= Communication slot..

Startup frameFlexRay-Rahmen, dessen Header Segment einen speziell dafür ausgezeichnetenIndikator beinhaltet in Form eines StartUp-Bits. Sich integrierende Knoten nützendie zeitlich relevante Information dieses Rahmens für die Initialisierung währenddes StartUp-Prozesses. StartUp-Frames sind immer gleichzeitig auch Sync-Frames..

Startup slotKommunikationsslot, indem der der StartUp-Frame gesendet wird..

Statischer SlotEin Zeitintervall innerhalb des statischen Segment eines Kommunikationszyklus,welches eine konstante Anzahl von Makrotricks beinhaltet. Für jeden dieser Slotswird der Zugriff exklusiv einem einzigen Knoten gewährt für die Übertragungeines Rahmens mit einer zu der Slot-Nummer korrespondierenden Rahmen-ID. ImGegensatz zu dem dynamischen Slot beinhaltet jeder statische Slot eine konstanteAnzahl von Makroticks unabhängig davon ob der Rahmen in dem Slot eines Zyklusgesendet wurde oder nicht..

Statisches SegmentAbschnitt eines Kommunikationszyklus, indem der MAC-Zugriff per zeitgesteu-erten TDMA-Schema stattfindet. In diesem Segment ist der Buszugriff fest gere-gelt und deterministisch durch die Zuteilung von Slots anhand einer zeitlichenRegelung. Dadurch entsteht in jedem Fall ein determiniertes Verhalten für diesenBereich..

SternEine Komponente, die einen Informationstransfer zwischen mehreren physikali-schen Übertragungsmedien implementiert. Ein Stern spiegelt die Informationeneines Übertragungsmediums auf alle anderen angeschlossenen Übertragungsme-dien. Ein Stern kann aktiv oder auch passiv fungieren, also auch falls gewünschtdie Eigenschaften eines Steuergeräts annehmen..

Steuergerät= ECU.

Glossar 249

Stichleitung= Stub.

StubDies bezeichnet die Verbindung von einem Knoten in einem Netzwerk zum Über-tragungsmedium (z.B. einem Bus)..

Sync frameFlexRay-Rahmen, in dessen Header-Segment ein gesetztes Indikatorbit signalisiert,dass die zeitliche Abweichung zwischen dem erwarteten Rahmensankunftszeit-punkt und dem realen Ankunftszeitpunkt gemessen und für die Berechnung derTaktsynchronisationsalgorithmen als Eingabewerte herangezogen werden sollen..

Sync nodeDiese Knoten verfügen über die Eigenschaft Sync-Frames verschicken zu können,welche für die Taktsynchronisation im Cluster verwendet werden. In einem Clusterist die Anzahl an vorkommenden Sync Nodes auf 16 beschränkt..

Sync slotZeitschlitz im Schedule, indem der Sync-Rahmen verschickt wird..

TaskEine gekapselte Aufgabe, in deren Rahmen eine gewisse Funktionalität bereitge-stellt und umgesetzt werden muß. Diese Aufgabe kann in FlexRay zeitlich limitiertoder/und periodisch abgearbeitet werden..

Topologie= Netzwerktopologie.

Verbindungskabel= physikalische Verbindungsleitung.

WCETDie Task-spezifische maximal benötigte Zeit zur Ausführung seiner implementier-ten Funktionalität (Worst Case Execution Time)..

250 Glossar

Abkürzungsverzeichnis

ΔT . . . . Jitter zwischen zwei Komponenten

⊥ . . . . Nicht definiert

ε . . . . . Fehler (error)

μT . . . . Mikrotick auf Controllerebene

A . . . . Alter eines im Netzwerk empfangenen Signals

AFN . . . Konnektivitätsmatrix zu einem Funktionsnetz

ACI . . . Actuator Interface

AMOC . Application Mode Control

APL . . . Application

ASIC . . Application Specific Integrated Circuit

BD . . . . Physikalischer Bustreiber (Bus Driver)

BRC . . . Basisempfangskomponente

BSC . . . Basissendekomponente

C . . . . . Systemkondition

c . . . . . Kosten/Komplexität

CAE . . . Computer Aided Design

CB . . . . Berechnungsblock

CC . . . . Kommunikationscontroller (Communication Controller)

CMM(I) . Capability Maturity Model (Integration)

251

252 Abkürzungsverzeichnis

CONF . . Configuration

CR . . . . Zykluswiederholrate (Cycle Repetition)

CSMA(D) Carrier Sense Multiple Access (Detection)

d . . . . . Verzögerung (Delay)

DEM . . Discrete Event Machine

DL . . . . Länge eines zu verarbeiteten Datensignals (Data Length)

E/E . . . Elektrik/Elektronik (EE)

ECU . . . Steuergerät

EPL . . . Electrical Physical Layer

FC . . . . Funktionskomponente

FC_Ini . . Eingangsport einer Funktionskomponente

FC_Outi . Ausgangsport einer Funktionskomponente

FFA . . . Functional Failure Analysis

FMEA . . Failure Mode and Effects Analysis

FN . . . . Funktionsnetz

FPGA . . Field Programmable Gate Array

FTA . . . Fault Tree Analysis

g . . . . . Netzwerkglobal

Ge . . . . Generalisierung

HAL . . . Hardware Abstraction Layer

HIL . . . Hardware in the Loop

LL . . . . Länge einer Verbindungsleitung

MD . . . Modelldaten

MT . . . Macrotick auf Netzwerkebene

N . . . . Netzwerkteilnehmer (logisch → Knoten, physikalisch → Steuergerät)

NAI . . . Network Application Interface

O . . . . Zeitlicher Abstand relativ zum Buszyklusstart (Offset)

Abkürzungsverzeichnis 253

Oa,i . . . Slot mit Offset-Nummer i ∈ N aus Sicht des Netzwerkteilnehmers a

P . . . . . Prozess

p . . . . . Knotenlokal

PC . . . . Parameterberechung

PCH . . . Physikalischer Kanal

PCHP . . Physikalischer Kanalteil

PLL . . . Phase-Locked Loop

POC . . . Protocol Operation Control

PP . . . . Package Position

Re . . . . Verfeinerung

RP . . . . Rapid Prototyping

RTOS . . Real Time Operating System

S . . . . . Signal

SCS . . . Safety Control Services

SFD . . . Signal Flow Diagram

SIL . . . . Software in the Loop

SL . . . . Signallänge

SMOC . . System Mode Control

SNI . . . Sensor Interface

SOP . . . Start Of Production

SP . . . . Signalphase

SRC . . . Sende-Empfangsbeziehung

SSL . . . Safety/Security Layer

SST . . . Signalsubtyp

ST . . . . Signaltyp

SUV . . . Sports Utility Vehicle

SYS . . . System

T . . . . . Signalgenerierungszyklus (Applikationsspezifisch)

254 Abkürzungsverzeichnis

TBUS . . . Übertragungszyklus (Busspezifisch)

TBTF . . Timing Budget Task Force

TD . . . . Temporäre Daten

TDMA . Time Division Multiple Access

TTNCONF Time Triggered Network Configuration

TTNI . . Time Triggered Network Interface

VHDL . . Very High Speed Integrated Circuit Hardware Description Language

WCET . . Worst Case Execution Time

x ↔ y . . Parameter x korreliert mit Parameter y

Literaturverzeichnis

[ABR+93] Audsley, N. ; Burns, A. ; Richardson, M. ; Tindell, K. ; Wellings, A. J.:Applying New Scheduling Theory to Static Priority Pre-Emptive Scheduling.In: Software Engineering Journal 8 (1993), S. 284–292

[ADA07] ADAC: ADAC - Pannenstatistik 2007. http://www.adac.de, 2007

[AHP99] Atanassov, P. ; Haberl, S. ; Puschner, P.: Heuristic Worst-Case ExecutionTime Analysis. In: Proc. 10th European Workshop on Dependable Computing,Austrian Computer Society (OCG), May 1999, S. 109–114

[AJ78] A.Korn ; J.V.Wait: Digital Continuous System Simulation. Prentice Hall, 1978

[Alt02] Alt, Walter: Nichtlineare Optimierung. Eine Einführung in Theorie, Verfah-ren und Anwendungen. Vieweg, 2002 http://www.amazon.ca/exec/obidos/redirect?tag=citeulike09-20\&path=ASIN/352803193X. – ISBN352803193X

[AQU06] AQUINTOS GmbH ; AQUINTOS GmbH (Hrsg.): Benutzerhandbuch aquin-tos.EE. V.1.7. Lammstraße 21, 76133 Karlsruhe: AQUINTOS GmbH, Mai2006

[Aqu07] Aquintos GmbH: PREEvision. http://www.aquintos.com/de/products/ee.php, 2007

[ASA08] ASAM: FIBEX - Field Bus Exchange Format / Association for Standardisationof Automation and Measuring Systems - ASAM e.V. 2008 (Version 3.0). –Forschungsbericht

[ASH06] Armengaud, E. ; Steininger, A. ; Horauer, M.: Automatic Parameter Iden-tification in FlexRay Based Automotive Communication Networks. In: 11thIEEE International Conference on Emerging Technologies and Factory Automation(ETFA’06) (2006), Sep.

[Aut06] AutomotiveSPICE Initiative: Automotive SPICE. http://www.automotivespice.com, 2006

255

256 LITERATURVERZEICHNIS

[AUT07a] AUTOSAR Konsortium: Automotive Open Systems Architecture - DevelopmentPartnership -. http://www.autosar.org, 2007

[AUT07b] AUTOSAR Konsortium: Specification of the Virtual Function Bus. http://www.autosar.org, Februar 2008 2007. – Version 1.0.1

[Avi95] Avizienis, A.: The Methodology of N-Version Programming. citeseer.ist.psu.edu/avizienis95methodology.html. Version: 1995

[AZL+06] Armbruster, M. ; Zimmer, E. ; Lehmann, M. ; Reichel, R. ; Sieglin, E. ;Spiegelberg, G. ; Sulzmann, A.: Affordable X-By-Wire technology based onan innovative, scalable E/E platform-concept. In: VTC Spring, IEEE, 2006, S.3016–3020

[BBG+05] Beyer, S. ; Bohm, P. ; Gerke, M. ; Hillebrand, M. ; Rieden, T. I. ; Knapp,S. ; Leinenbach, D. ; Paul, W. J.: Towards the Formal Verification of LowerSystem Layers in Automotive Systems. In: ICCD ’05: Proceedings of the 2005International Conference on Computer Design. Washington, DC, USA : IEEEComputer Society, 2005. – ISBN 0–7695–2451–6, S. 317–326

[Bee07] Beeck, M. von d.: Development of logical and technical architectures forautomotive systems. In: Software and System Modeling 6 (2007), Nr. 2, S. 205–219

[Ber89] Berry, G.: Real Time Programming: Special Purpose or General PurposeLanguages. In: IFIP Congress, 1989, S. 11–17

[Ber00] Berry, G.: The Foundations of Esterel. MIT Press, 2000 citeseer.ist.psu.edu/62412.html

[Ber02] Berger, A.: Embedded systems design. CMP Books, 2002. – ISBN 1–57820–073–3

[BFM05] Belschner, R. ; Freess, J. ; Mroßko, M.: Gesamtheitlicher Entwicklungs-ansatz für Entwurf, Dokumentation und Bewertung von E/E-Architekturen.In: Ingenieure, VDI Verein D. (Hrsg.): VDI Berichte Nr. 1907. Düsseldorf :VDI Verlag, 2005. – ISBN 3–18–091907–8, S. 511–521

[BGG+04] Barry, A. ; Gisiger, A. ; Guido, N. ; Haak, G. ; Hartung, I. ; Heid, B.; Huber, U. ; Näher, U. ; Ollig, W. ; Radtke, P. ; Vlasits, M. ; Weber,M.: Levers for Trouble-free Electronics. In: McKinsey Automotive & Assembly(2004), September. http://autoassembly.mckinsey.com

[BGH+06] Botaschanjan, J. ; Gruler, A. ; Harhurin, A. ; Kof, L. ; Spichkova, M. ;Trachtenherz, D.: Towards Modularized Verification of Distributed Time-Triggered Systems. In: FM 2006: Formal Methods, 14th International Symposiumon Formal Methods, Hamilton, Canada, August 21-27, 2006, Proceedings Bd. 4085,Springer, 2006 (Lecture Notes in Computer Science). – ISBN 3–540–37215–6,S. 163–178

[BHS99] Broy, M. ; Huber, F. ; Schätz, B.: AutoFocus - Ein Werkzeugprototyp zurEntwicklung eingebetteter Systeme. In: Inform., Forsch. Entwickl. 14 (1999),Nr. 3, S. 121–134

LITERATURVERZEICHNIS 257

[BHWJ07] Bonschab, S. ; Hermann, T. ; Wirrer, G. ; Jausel, H.: FlexRay aus derSicht eines Elektronik-Suppliers / Euroforum 2007. Stuttgart, 8.-9. Mai 2007.– Forschungsbericht

[Bil08] Biller, Sven: Vernetzung von Mikrocontrollern mit dem Ethernet: TCP/IP Kom-munikation für Mikrocontroller und Embedded-Systeme. Vdm Verlag Dr. Müller,2008. – 978-3639014419

[BLP+96] Bengtsson, J. ; Larsson, F. ; Pettersson, P. ; Yi, W. ; Christensen, P. ;Jensen, J. ; Jensen, P. ; Larsen, K. ; Sorensen, T.: Uppaal: a Tool Suite forValidation and Verification of RealTime Systems. http://www.docs.uu.se/rtmv/uppaal/-uppaal-guide.ps.gz, 1996

[BMG07] Broy, J. ; Müller-Glaser, K. D.: The impact of time-triggered communica-tion in automotive embedded systems. In: IEEE (Hrsg.): SIES ’07 - 2nd IEEEInternational Symposium on Industrial Embedded Systems. Costa da Caparica,Portugal : IEEE, Juli 2007, S. 353–356

[Boo91] Booch, G.: Object oriented design with applications. Redwood City, CA, USA :Benjamin-Cummings Publishing Co., Inc., 1991. – ISBN 0–8053–0091–0

[Boo04] Booch, G.: Object-Oriented Analysis and Design with Applications (3rd Edition).Redwood City, CA, USA : Addison Wesley Longman Publishing Co., Inc.,2004. – ISBN 020189551X

[Bor94] Bortolazzi, J.: Untersuchungen zur rechnergestützten Erfassung, Verwaltungund Prüfung von Anforderungsspezifikationen und Einsatzbedingungen elektro-nischer Steuerungs- und Regelungssysteme. Erlangen-Nürnberg, UniversitätErlangen-Nürnberg, Dissertation, April 1994

[BPG04] Berwanger, J. ; Peller, M. ; Griessbach, R.: Byteflight-A New High-Performance Data Bus System for Safety-Related Applications. http://www.byteflight.com/, 2004

[BR07] Broy, J. ; Roppel, R.: Challenges for the integration of FlexRay systems infuture automotive electric/electronic architectures. In: 13. Internationaler Kon-gress Elektronik im Kraftfahrzeug. Baden-Baden : VDI Fahrzeug- und Verkehrs-technik, Oktober 2007

[Bro98] Broy, M.: Informatik - eine grundlegende Einführung. Zweite. Springer, 1998

[Bro03] Broy, M.: Software im Automobil - Potentiale, Herausforderungen, Trends.In: GI Jahrestagung, September, 2003

[Bro05] Broy, J.: Implementierung und Analyse eines FlexRay-Clusters zum Kosten- undKomplexitätsvergleich mit heutigen Bustechnologien. München, Technische Uni-versität München - Fakultät für Informatik - Lehrstuhl für Systemarchitektur:Betriebssysteme, Kommunikationssysteme und Rechnernetze, Diplomarbeit,Juli 2005

[Bro06] Broy, M.: Challenges in automotive software engineering. In: ICSE ’06: Pro-ceeding of the 28th international conference on Software engineering. New York,NY, USA : ACM Press, 2006. – ISBN 1–59593–375–1, S. 33–42


[Bro07] Broy, J.: Herausforderung FlexRay System - Konfiguration und Test. IIR Forum -ModellbasierterTest von Kfz-Steuergeräten 2007, Dezember 2007. – München

[BS01] Broy, M. ; Stoelen, K.: Specification and Development of Interactive Systems:Focus on Streams, Interfaces, and Refinement. 2001

[BS03] Broy, M. ; Steinbrüggen, R.: Modellbildung in der Informatik. Springer-Verlag,2003

[BS06] Büttner, F. ; Schmid, T.: BMW: Seriencode für dezentrale Regler. In: dSPACEGmbH - dSpace News (Februar, 2006), Nr. 2

[BTB91] Behroozi-Toosi, A. ; Bhatia, S.: Modelling of computer networks and sys-tems using SES/workbench. In: Circuits and Systems, 1991., Proceedings of the34th Midwest Symposium on (1991), May, S. 992–996 vol.2. http://dx.doi.org/10.1109/MWSCAS.1991.251969. – DOI 10.1109/MWSCAS.1991.251969

[BV04] Boyd, S. ; Vandenberghe, L.: Convex Optimization. Cambridge Uni-versity Press, 2004 http://www.amazon.com/exec/obidos/redirect?tag=citeulike-20\&path=ASIN/0521833787. – ISBN 0521833787

[BY04] Bengtsson, J. ; Yi, W.: Timed Automata: Semantics, Algorithms and Tools.citeseer.ist.psu.edu/703625.html. Version: 2004

[BZ08] Bortolazzi, J. ; Zöller, R.: Der Mechatronikentwicklungsprozess bei Por-sche - Ziele, Herausforderungen, Implementierung / Dr. Ing. h. c. F. PorscheAG. Vector Kongress, 2008 2008. – Forschungsbericht

[Car06] Car 2 Car Communication Consortium: Mission and Objectives. http://www.car-to-car.org, 2006

[CCG+07] Cuenot, P. ; Chen, D. ; Gérard, S. ; Lonn, H. ; Reiser, M.-O. ; Servat, D.; Sjostedt, C.-J. ; Kolagari, R. T. ; Torngren, M. ; Weber, M.: ManagingComplexity of Automotive Electronics Using the EAST-ADL. In: ICECCS’07: Proceedings of the 12th IEEE International Conference on Engineering ComplexComputer Systems (ICECCS 2007). Washington, DC, USA : IEEE ComputerSociety, 2007. – ISBN 0–7695–2895–3, S. 353–358

[CDK01] Coulouris, G. ; Dollimore, J. ; Kindberg, T.: Distributed systems (3rd ed.):concepts and design. Boston, MA, USA : Addison-Wesley Longman PublishingCo., Inc., 2001. – ISBN 0–201–61918–0

[Che08] Chen, X.: Requirements and concepts for future automotive electronic architectu-res from the view of integrated safety, Universität Karlsruhe (TH) - Fakultät fürElektrotechnik und Informationstechnik - Institut für Technik der Informati-onsverarbeitung (ITIV), Diss., April 2008

[Cor08] Cornelius, F.: EE-Architecture and Network Design from an OEM Perspec-tive / Daimler AG. Synergy Forum Äircraft meets AutomotiveSSystem Ar-chitectures, Mai 2008. – Forschungsbericht

[DeM79] DeMarco, T.: Structured analysis and system specification. (1979), S. 409–424. ISBN 0–917072–14–6


[Dij72] Dijkstra, Edsger W.: Chapter I: Notes on structured programming. (1972),S. 1–82. ISBN 0–12–200550–3

[DIN90] DIN 40041 (12/90): Zuverlässigkeit: Begriffe. Beuth Verlag, Berlin, 1990

[DIN97] DIN 19226-1: Leittechnik - Regelungstechnik und Steuerungstechnik - Stichwort-verzeichnis. Beuth Verlag, Berlin, 1997

[DMR77] Dickover, M. E. ; McGowan, C. L. ; Ross, D. T.: Software design using:SADT. In: ACM ’77: Proceedings of the 1977 annual conference. New York, NY,USA : ACM, 1977, S. 125–133

[dSp07] dSpace GmbH: dSpace SystemDesk. http://www.dspace.de/ww/de/gmb/home/products/sw/system_architecture_software/systemdesk.cfm?nv=n2, 2007

[dSp08] dSpace GmbH: SystemDesk - For planning, implementing and integrating complexsystem architectures and distributed software systems. http://www.dspace.co.uk, Oktober 2008

[Ech90] Echtle, K.: Fehlertoleranzverfahren. Berlin : Springer-Verlag, 1990

[EE84] Electrical, Institute of ; Engineers, Electronics: IEEE guide to softwarerequirements specifications. In: IEEE Std 830-1984 (1984), Feb, S. –

[EEE98] Electrical, The I. ; Electronics Engineers, Inc.: IEEE Recommended Prac-tice for Software Requirements Specifications / The Institute of Electrical andElectronics Engineers, Inc. New York, Juni 1998 (IEEE Std 830-1998). – For-schungsbericht

[ELLSV02] Edwards, S. ; Lavagno, L. ; Lee, E. A. ; Sangiovanni-Vincentelli, A.: De-sign of embedded systems: formal models, validation, and synthesis. (2002),S. 86–107. ISBN 1–55860–702–1

[ELM07] ELMOS Semiconductor AG: E910.56 star coupler. http://www.elmos.de/german/produkte/assps/detail/flexray.html. Version: 2007

[ERG08] Espinozaa, H. ; Richter, K. ; Gérard, S.: Evaluating MARTE in an Industry-Driven Environment: TIMMO’s Challenges for AUTOSAR Timing Modeling.In: Design Automation and Test in Europe (DATE). München, März 2008

[Ets09] Etschberger, K.: CAN Controller Area Network - Grundlagen, Protokolle, Bau-steine, Anwendungen. 3. Auflage. Fachbuchverlag Leipzig, 2009. – ISBN 3-446-19431-2

[FBR+06] Freund, U. ; Braun, P. ; Romberg, J. ; Bauer, A. ; Mai, P. ; Ziegenbein, D.:AutoMoDe—A Transformation Based Approach for the Model-based Designof Embedded Automotive Software. In: Proceedings of the 2006 European Con-gress on Embedded Real Time Software (ERTS). Toulouse, France, Januar 2006

[FBSG07] Faugère, M. ; Bourbeau, T. ; Simone, R. de ; Gérard, S.:MARTE: Also an UML Profile for Modeling AADL Applicati-ons. In: iceccs 00 (2007), S. 359–364. http://dx.doi.org/http:


//doi.ieeecomputersociety.org/10.1109/ICECCS.2007.29. – DOIhttp://doi.ieeecomputersociety.org/10.1109/ICECCS.2007.29. ISBN 0–7695–2895–3

[FFPT05] Farcas, E. ; Farcas, C. ; Pree, W. ; Templ, J.: Transparent distribution of real-time components based on logical execution time. In: LCTES ’05: Proceedingsof the 2005 ACM SIGPLAN/SIGBED conference on Languages, compilers, and toolsfor embedded systems. New York, NY, USA : ACM Press, 2005. – ISBN 1–59593–018–3, S. 31–39

[FGZA03] Falk, C. ; Grechenig, T. ; Zuser, W. ; (Austria), R. B.: A Vehicle Structuredbased Software Architecture. In: Software Engineering and Applications. Marinadel Rey, USA, November 2003

[FHS02] Fröhlich, P. ; Hu, Z. ; Schoelzke, M.: Imposing Modeling Rules on Industri-al Applications through Meta-modeling. In: Revised Papers from the HUMACS,DASWIS, ECOMO, and DAMA on ER 2001 Workshops. London, UK : Springer-Verlag, 2002. – ISBN 3–540–44122–0, S. 166–182

[Föl05] Föllinger, O. ; Hüthig (Hrsg.): Regelungstechnik. Einführung in die Methodenund ihre Anwendung. 8. Auflage. Hüthig, 2005

[Fla07] Flammer, M.: Untersuchungen zur Integration einer AUTOSAR-Architekturund deren Systemdienste in einem FlexRay Cluster auf Basis einer V850-Plattform.Stuttgart, Dr. Ing. h.c. F. Porsche AG, Diplomarbeit, Januar 2007

[Fle04a] FlexRay Konsortium: FlexRay Communications System Bus Guardian Spe-cification / FlexRay Konsortium. Version 2.0. http://www.flexray.com :FlexRay Konsortium, Juni, 2004. – Forschungsbericht

[Fle04b] FlexRay Konsortium: FlexRay Communications System Electrical Physi-cal Layer Specification / FlexRay Konsortium. Version 2.0. http://www.flexray.com : FlexRay Konsortium, Juni, 2004. – Forschungsbericht

[Fle05a] FlexRay Konsortium: FlexRay Communications System Protocol Specification.Version 2.1 Revision A. http://www.flexray.com, Dezember 2005

[Fle05b] FlexRay Konsortium: FlexRay Communications System Protocol Specifica-tion Version 2.1 Revision A / FlexRay Konsortium. http://www.flexray.com, Dezember Dezember, 2005. – Forschungsbericht

[Fle06a] FlexRay Konsortium: Time Budget Taskforce - Status Report 2006-02-23. Inter-nes Dokument, September 2006

[Fle06b] FlexRay Konsortium: FlexRay Electrical Physical Layer Application No-tes / FlexRay Konsortium. Version 2.0. http://www.flexray.com : FlexRayKonsortium, November, 2006. – Forschungsbericht

[FM98] Fraboul, C. ; Martin, F.: Modeling and simulation of integrated modularavionics. In: In Proceedings of the 6th Euromicro Workshop on Parallel and Distri-buted Processing, 1998, S. 102–110

[For02] Forsight: Foresight Users Guide. 5. Auflage. McLean, USA, 2000 - 2002


[Fre05] Freymann, R.: Connectivity and Safety. In: 6th European Congress on IntelligentTransport Systems and Services BMW Group Forschung und Technik, 2005

[FSV99] Ferrari, A. ; Sangiovanni-Vincentelli, A.: System Design: TraditionalConcepts and New Paradigms. In: ICCD ’99: Proceedings of the 1999 IEEEInternational Conference on Computer Design. Washington, DC, USA : IEEEComputer Society, 1999. – ISBN 0–7695–0406–X, S. 2

[FW99] Ferdinand, C. ; Wilhelm, R.: Efficient and Precise Cache Behavior Predicti-on for Real-TimeSystems. In: Real-Time Syst. 17 (1999), Nr. 2-3, S. 131–181. –ISSN 0922–6443

[GJ75] Garey, M. R. ; Johnson, D. S.: Complexity Results for Multiprocessor Sche-duling under Resource Constraints. In: SIAM J. Comput. 4 (1975), Nr. 4, S.397–411

[GJ79] Garey, M. R. ; Johnson, D. S.: Computers and Intractability : A Guide tothe Theory of NP-Completeness (Series of Books in the Mathematical Sciences).W. H. Freeman, 1979 http://www.amazon.ca/exec/obidos/redirect?tag=citeulike09-20\&path=ASIN/0716710455. – ISBN 0716710455

[Gri01] Grimm, C.: Systemtheorie für Informatiker. Einführung in die Systemtheo-rie - Vorlesungsunterlagen - Technische Informatik J. W. Goethe-UniversitätFrankfurt am Main, 2001

[Gri03] Grimm, K.: Software technology in an automotive company: major challen-ges. In: ICSE ’03: Proceedings of the 25th International Conference on SoftwareEngineering. Washington, DC, USA : IEEE Computer Society, 2003. – ISBN0–7695–1877–X, S. 498–503

[Gup95] Gupta, Rajesh K.: Co-Synthesis of Hardware and Software for Digital EmbeddedSystems. Norwell, MA, USA : Kluwer Academic Publishers, 1995. – ISBN0792396138. – Foreword By-Micheli„ Giovanni De

[H. 06] H. Heinecke et al. - AUTOSAR Development Partnership: AUTOSAR -Current results and preparations for exploitation / 7th EUROFORUM con-ference SSoftware in the vehicle". Stuttgart, Germany, 3-4 May 2006. – For-schungsbericht

[Har84] Harel, D.: Statecharts: A visual approach to complex systems / The Weiz-mann Institute of Science - Department of Applied Mathematics. 1984 (CS84-05). – Forschungsbericht

[Har87] Harel, D.: Statecharts: A Visual Formalism for Complex Systems. In: Scienceof Computer Programming 8 (1987), June, Nr. 3, 231–274. citeseer.ist.psu.edu/harel87statecharts.html

[Har06] Harrschar, P.: Future Trends of Embedded Software for Automotive Systems. 13thAnnual IEEE International Conference and Workshop on the Engineering ofComputer Based Systems, März 2006. – Potsdam


[HCRP94] Halbwachs, N. ; Caspi, P. ; Raymond, P. ; Pilaud, D.: The synchronousdataflow programming language LUSTRE / IMAG/LGI, VERILOG. 1994. –Forschungsbericht

[HD92] Hoyme, K. ; Driscoll, K.: SAFEbusTM. In: 11th AIAA/IEEE Digital AvionicsSystems Conference (1992), October, S. 68–73. – Seattle, WA

[HFP+06] Hartmann, J. ; Fleischmann, A. ; Pfaller, C. ; Rappl, M. ; Rittmann, S.; Wild, D.: Feature Net - ein Ansatz zur Modellierung von automobilspe-zifischem Domänenwissen und Anforderungen. In: Hochberger, Christian(Hrsg.) ; Liskowsky, Rüdiger (Hrsg.): GI Jahrestagung (1) Bd. 93, GI, 2006(LNI). – ISBN 978–3–88579–187–4, 761-765

[HHJ+] Henia, R. ; Hamann, A. ; Jersak, M. ; Racu, R. ; Richter, K. ; Ernst, R.:System Level Performance Analysis - the SymTA/S Approach. citeseer.ist.psu.edu/745912.html

[HHK01] Henzinger, T. A. ; Horowitz, B. ; Kirsch, C. M.: Embedded Control SystemsDevelopment with Giotto. In: LCTES/OM, 2001, 64–72

[HIS07] HIS Konsortium: Herstellerinitiative Software - Development Partnership -.http://www.automotive-his.de, 2007

[HKL07] Hietl, H. ; Kötz, J. ; Linn, G.: Bereit für FlexRay - FlexRay-Serieneinführungbei Audi. In: Elektronik automotive 01 (2007), S. S.32–36

[HOP05] Huber, B. ; Obermaisser, R. ; Peti, P.: MDA-Based Development in the DE-COS Integrated Architecture - Modeling the Hardware Platform / ViennaUniversity of Technology - Real-Time Systems Group. Wien, 2005. – For-schungsbericht

[HS02] Huckle, T. ; Schneider, S.: Numerik für Informatiker. Berlin : Springer, 2002

[HW04] Honekamp, U. ; Wernicke, M.: Development of Distributed AutomotiveSoftware: The DaVinci Methodology. In: DIPES, 2004, S. 93–102

[IBM06] IBM Corporation: Rational RequisitePro. http://www-306.ibm.com/software/awdtools/reqpro/, 2006

[IEC05] IEC/EN: 61508 - Functional safety of E/E/PE safety-related systems /IEC/TR - International Electrotechnical Commission. 1998-2005 (Teil 1 - 5). –Forschungsbericht

[IKB03] IKB Deutsche Industriebank AG: Märkte im Fokus - Automobilindustrie-zunehmender Investitions- und Finanzierungsbedarf / IKB Deutsche Indus-triebank. Wilhelm-Bötzkes-Straße 1 40474 Düsseldorf, Juni Juni, 2003 (1. Auf-lage). – IKB Report

[INC07] INCOSE: INCOSE Systems engineering handbook. INCOSE, 2007

[Ini07] Initiative, ATESST: The Modelling Approach in ATESST - Overview / Ad-vancing Traffic Efficiency and Safety through Software Technology (ATESST).http://www.atesst.org, März 2007 (1.0). – Informeller Report


[Int91] International Standards Organisation (ISO): International StandardISO/IEC 9126. Information technology: Software product evaluation: Quality cha-racteristics and guidelines for their use. 1991

[Int99a] International Telecommunication Union: Series Z: Languages and ge-neral Software aspects for telecommunication systems - Formal descriptiontechniques (FDT) - Message Sequence Chart (MSC) / ITU-T Telecommunica-tion Standardization Sector of ITU. 1999 (Z.120). – Recommendation

[Int99b] International Telecommunication Union: Series Z: Languages and ge-neral Software aspects for telecommunication systems - Formal descriptiontechniques (FDT) - Specification and description language (SDL) / ITU-TTelecommunication Standardization Sector of ITU. 1999 (Z.100). – Recom-mendation

[Int08] International Business Machines Corp.: IBM Requirements Manage-ment - Rational RequisitePro. http://www-01.ibm.com/software/awdtools/reqpro/, 2008

[ISE93] ISE Software: Building bug-free O-O software: An introduction to designby contract(TM). http://archive.eiffel.com/doc/manuals/technology/contract/page.html, 1993

[ISO93] ISO/IEC 2382-1: Informationstechnik - Begriffe - Teil 1: Grundbegriffe. BeuthVerlag, Berlin, 1993

[ISO04] ISO ; ISO (Hrsg.): Road vehicles – Diagnostics on Controller Area Networks (CAN)– Part 2: Network layer services. ISO, 2004

[ISO07] ISO/WD 26262: Road Vehicles - Functional Safety / International StandardOrganization. 2007. – Arbeitsstand

[Jac75] Jackson, M. A.: Principles of Program Design. Orlando, FL, USA : AcademicPress, Inc., 1975. – ISBN 0123790506

[JDU+74] Johnson, D. S. ; Demers, A. ; Ullman, J. D. ; Garey, M. R. ; Graham,R. L.: Worst-case Performance Bounds for Simple One-dimensional PackingAlgorithms. 3 (1974), Dezember, Nr. 4, S. 299–325. – ISSN 0097–5397 (print),1095–7111 (electronic)

[Jer03] Jernst: What are the differences between a vocabulary, a taxonomy, a the-saurus, an ontology, and a meta-model? (2003). http://www.metamodel.com/article.php?story=20030115211223271

[JHQ+03] Jeckle, M. ; Hahn, J. ; Queins, S. ; Rupp, C. ; Zengler, B. ; Fachbuchverlag,Hanser (Hrsg.): UML 2 glasklar. 1. Hanser Fachbuchverlag, 2003. – ISBN3446225757

[JKR63] Johnson, R. A. ; Kast, F. ; Rosenzweig, J. E.: The Theory and Management ofSystems. 1. Edition. New York, London : McGraw-Hill, 1963

[Kah74] Kahn, G.: The semantics of a simple language for parallel programming. In:IFIP 74. Holland, 1974


[KE04] Kemper, Alfons ; Eickler, Andre: Datenbanksysteme. Eine Einführung. 5. Ol-denbourg, 2004. – ISBN-10: 3486273922ISBN-13: 978-3486273922

[KG94] Kopetz, H. ; Grünsteidl, G.r: TTP-A Protocol for Fault-Tolerant Real-TimeSystems. In: Computer 27 (1994), Nr. 1, S. 14–23. http://dx.doi.org/http://dx.doi.org/10.1109/2.248873. – DOI http://dx.doi.org/10.1109/2.248873.– ISSN 0018–9162

[KL91] Kenny, K.B. ; Lin, K.-J.: Building Flexible Real-Time Systems Using the FlexLanguage. In: Computer 24 (1991), Nr. 5, S. 70–78. http://dx.doi.org/http://dx.doi.org/10.1109/2.76288. – DOI http://dx.doi.org/10.1109/2.76288.– ISSN 0018–9162

[KL02] Kalavade, Asawaree ; Lee, Edward A.: The extended partitioning problem:hardware/software mapping, scheduling, and implementation-bin selection.(2002), S. 293–312. ISBN 1–55860–702–1

[Kle06] Kleinod, Ekkart: Modellbasierte Systementwicklung in der Automobilin-dustrie – Das MOSES-Projekt / Fraunhofer-Institut für Software- und Sys-temtechnik, Abt. Verlässliche Technische Systeme. Version: April 2006. http://veia.isst.fraunhofer.de/. 2006 (ISST-Bericht 77/06). – Forschungsbe-richt

[Kle08] Klegraf, A.: Produkt- und Releasemanagement mit eASEE / Vector Infor-matik GmbH. Vector Kongress 2008, Oktober 2008. – Forschungsbericht

[KLFP02] Kirner, R. ; Lang, R. ; Freiberger, G. ; Puschner, P.: Fully Automatic Worst-Case Execution Time Analysis for Matlab/Simulink Models. In: ECRTS ’02:Proceedings of the 14th Euromicro Conference on Real-Time Systems. Washington,DC, USA : IEEE Computer Society, 2002. – ISBN 0–7695–1665–3, S. 31

[KNR05] Kuhrmann, M. ; Niebuhr, D. ; Rausch, A.: Application of the V-ModellXT - Report from A Pilot Project. In: Li, Mingshu (Hrsg.) ; Boehm, Barry(Hrsg.) ; Osterweil, Leon J. (Hrsg.): Unifying the Software Process Spectrum,International Software Process Workshop, SPW 2005, Beijing, China, May 25-27,Springer, 2005 (Lecture Notes in Computer Science), S. 463–473

[Kop97] Kopetz, H. ; Publishers, Kluwer A. (Hrsg.): Real-Time Systems - Design Prin-ciples for Distributed Embedded Applications. Kluwer Academic Publishers, Bo-ston, 1997. – ISBN 0–7923–9894–7

[Kop98] Kopetz, H.: The Time-Triggered Architecture. In: Proceedings of the First Inter-national Symposium on Object-Oriented Real-Time Distributed Computing. Kyoto,Japan, April 1998, S. 22–29

[KP96] Koschke, R. ; Plödereder, E.: Ansätze des Programmverstehens. In: Softwa-rewartung und Reengineering - Erfahrungen und Entwicklungen (1996), S. 159–176

[KP05] Kirner, R. ; Puschner, P.: Classification of WCET Analysis Techniques. In:Proc. 8th IEEE International Symposium on Object-oriented Real-time distributedComputing, 2005, S. 190–199


[Kra05] Kraftfahrt-Bundesamt: Jahresbericht 2005 / Kraftfahrt-Bundesamt. 2005.– Forschungsbericht

[Kra07] Kraftfahrt-Bundesamt: Jahresbericht 2007 / Kraftfahrt-Bundesamt. 2007.– Forschungsbericht

[Krü01] Krüger, Ingolf: Architekturbeschreibung mit UML-RT. Workshop Architektureingebetteter Systeme - Technische Universität München - Institut für Infor-matik - Software & Systems Engineering, Februar 2001

[KT08] Kelly, Steven ; Tolvanen, Juha-Pekka: Domain-Specific Modeling. Wiley-IEEEComputer Society Press, 2008

[Kün06] Künzli, S.: Efficient Design Space Exploration for Embedded Systems. Zürich,Eidgenössische Technische Hochschule Zürich - Information Technology andElectrical Engineering Department - Computer Engineering and NetworksLaboratory, Dissertation, April 2006

[Lam78] Lamport, L.: Time, clocks, and the ordering of events in a dis-tributed system. In: Commun. ACM 21 (1978), Nr. 7, S. 558–565.http://dx.doi.org/http://doi.acm.org/10.1145/359545.359563. – DOIhttp://doi.acm.org/10.1145/359545.359563. – ISSN 0001–0782

[Lap91] Laprie, Jean C.: Dependability: Basic concepts and terminology in English, French,German, Italian, and Japanese (Dependable computing and fault-tolerant systems).Springer-Verlag, 1991 http://www.amazon.ca/exec/obidos/redirect?tag=citeulike09-20\&path=ASIN/3211822968. – ISBN 3211822968

[Law07] Lawrenz, W. ; Hüthig (Hrsg.): CAN Controller Area Network - Grundlagen undPraxis. 5. Auflage. Hüthig, 2007. – ISBN-10: 3778529064

[LEk04] Larses, O. ; El-khoury, J.: Multidisciplinary Modeling and Tool Support forEE Architecture Design. In: Proceedings FISITA 2004 30th World AutomotiveCongress,. Barcelona, Spanien, 23 - 27 Mai, 2004 2004

[LIN03] LIN Consortium ; Report, Technical (Hrsg.): LIN Specification Package 2.0/ LIN Consortium. September, 2003. – Technical Report

[LL73] Liu, C. L. ; Layland, James W.: Scheduling Algorithms for Multiprogram-ming in a Hard-Real-Time Environment. In: J. ACM 20 (1973), Nr. 1, 46-61.http://dblp.uni-trier.de/db/journals/jacm/jacm20.html#LiuL73

[LME98] Li, Y. ; Malik, S. ; Ehrenberg, B.: Performance Analysis of Real-Time EmbededSoftware. Norwell, MA, USA : Kluwer Academic Publishers, 1998. – ISBN0792383826

[LSP82] Lamport, L. ; Shostak, R. ; Pease, M.: The Byzantine Generals Pro-blem. In: ACM Trans. Program. Lang. Syst. 4 (1982), Nr. 3, S. 382–401.http://dx.doi.org/http://doi.acm.org/10.1145/357172.357176. – DOIhttp://doi.acm.org/10.1145/357172.357176

[Lue97] Luenberger, David G.: Optimization by Vector Space Methods. New York, NY,USA : John Wiley & Sons, Inc., 1997. – ISBN 047118117X


[Mai08] Mair, T.: Modellbasierte Spezifikationstechniken zur Entwicklung und Optimie-rung von FlexRay-Systemen auf Basis von Metrikanalysen. Stuttgart, Dr. Ing. h.c.F. Porsche AG, Diplomarbeit, 2008

[Mar97] Marchetto, A.: Structured Definition of Modular Avionics ArchitecturesUsing Blueprints. In: Digital Avionics Systems Conference Bd. Volume 1, 1997,S. 3.2–24–31

[MB97] Mosnier, F. ; Bortolazzi, J.: Prototyping Car-Embedded Applications. In:Press, IOS (Hrsg.): Advances in Information Technologies: The Business Challenge.Amsterdam, 1997, S. 744–751

[McG82] McGraw, J. R.: The VAL language: Description and analysis. In: ACM TO-PLAS, Januar 1982

[Mea55] Mealy, G. H.: A Method for Synthesizing Sequential Circuits. In: Bell SystemTechnical Journal 34 (1955), Nr. 5, S. 1045–1079

[Men08] Mentor Graphics Corp.: SystemVision - System Integration, Simulation,and Analysis. http://www.mentor.com/products/sm/system_integration_simulation_analysis/systemvision/, Juni 2008

[Met08] MetaCase: MetaCase - Domain-Specific Modeling with MetaEdit+. http://www.metacase.com, 2008

[MG06] Müller-Glaser, K.D.: Systems and Software Engineering (SSE) - Vorle-sungsunterlagen. Universität Karlsruhe (TH) - Fakultät für Elektrotech-nik & Informationstechnik - Institut für Technik der Informationsverarbei-tung, http://www.itiv.uni-karlsruhe.de/opencms/de/institute/staff/index.html 2005/2006

[MG07] Müller-Glaser, K.D.: Challenges for reliable software design in automotiveelectronic control units. In: 12th International Conference on Reliable SoftwareTechnologies. Genua, Juni 2007

[Mic07] Michael, U.: Prioritäten einer Strategie - Elektronik-Entwicklung bei Porsche.Fachkongress Automobil-Elektronik, Juli 2007. – Dr. Ing. h.c. F. Porsche AG

[Mil73] Miles, R. F.: System Concepts: Lectures on Contemporary Approaches to Systems.New York : Wiley, 1973

[Mir07] Mirabilis Design: VisualSim Auto/Avionics Bus Modeling Toolkit - FlexRay Net-work System. http://www.mirabilisdesign.com/Pages/Demonstrations/automotive/FlexRay/FlexRay.html, 2007

[MIS04] MISRA: MISRA-C:2004 Guidelines for the Use of the C Language in Vehicle BasedSoftware. Motor Industry Research Association, Nuneaton CV10 0TU, UK,2004

[MMP01] Murdoch, J. ; McDermid, J.A. ; P.Wilkinson: Failure Modes and EffectsAnalysis (FMEA) and Systematic Design / University of York - High Integri-ty Systems Engineering Group; Rolls Royce plc. High Integrity Systems En-gineering Group;University of York, York, YO10 5DD UK P.Wilkinson; RollsRoyce plc; PO, 2001. – Forschungsbericht


[Moo56] Moore, E. F.: Gedanken-Experiments on Sequential Machines. In: Shannon,Claude (Hrsg.) ; McCarthy, John (Hrsg.): Automata Studies. Princeton, NJ :Princeton University Press, 1956, S. 129–153

[Moo65] Moore, G. E.: Cramming more components onto integrated circuits. In:Electronics 38 (1965), April, Nr. 8. ISBN 1–55860–539–8

[MOS04] MOST Cooperation: MOST Specification Rev 2.3 / MOST Cooperation.August, 2004. – Forschungsbericht

[MSH08] Milbredt, P. ; Steininger, A. ; Horauer, M.: Automated Testing of FlexRayClusters for System Inconsistencies in Automotive Networks. In: DELTA,IEEE Computer Society, 2008, 533-538

[Nac08] Nachtigall, Wirtz: Deskriptive Statistik. Statistische Methoden für Psychologen.5. überarbeitete Auflage. Juventa Verlag GmbH, 2008. – ISBN 3779910519

[NAS07] NASA Formal Methods Group: SPIDER homepage. http://shemesh.larc.nasa.gov/fm/spider/, 2007

[NG97] Nossal, R. ; Galla, T.: Solving NP-Complete Problems in Real-Time Sys-tem Design by Multichromosome Genetic Algorithms. In: In Proceedings ofthe SIGPLAN 1997 Workshop on Languages, Compilers, and Tools for Real-TimeSystems, pages 68-76, ACM SIGPLAN, June 1997 (1997), Jun.

[NGH08] Navet, N. ; Grenier, M. ; Havet, L.: Configuring the communication onFlexRay: the case of the static segment. In: 4th European Congress EmbeddedReal Time Software (ERTS 2008). Toulouse, France, 29. Januar - 1. February2008. 2008

[Nos96] Nossal, R.: Pre-Runtime Planning of a Real-Time Communication System/ Technische Universität Wien, Institut für Technische Informatik. Treitlstr.1-3/182-1, 1040 Vienna, Austria, 1996 (1/1996). – Research Report

[NR05] Näher, U. ; Radtke, P.: Automotive Electronics I: Managing Innovationson the Road. In: McKinsey Automotive & Assembly (2005), März, 1-24. http://autoassembly.mckinsey.com

[NSF07] Nyenhuis, M. ; Steiner, F. ; Fröhlich, M.: Das semiaktive Verstelldämpfersys-tem des BMX X5 mit verteilter Systemarchitektur. chassis.tech 2007, März 2007.– Technische Universität München, Garching

[OMG01] OMG: Model Driven Architecture (MDA): A technical perspective / ObjectManagement Group. Juli, 2001 (OMG Document No. ormsc/2001-07-01). –Forschungsbericht

[OMG02] OMG: Meta Object Facility (MOF) Specification. http://www.omg.com, April2002

[OMG06] OMG: Unified Modeling Language: Superstructure / OMG - Object Mana-gement Group. 2006 (V.2.1). – Forschungsbericht


[OSE01] OSEK/VDX: OSEK/VDX Time Triggered Operating System Specification 1.0/ OSEK/VDX. 2001. – Forschungsbericht

[OSE07] OSEK/VDX: Open systems and the corresponding interfaces for automotive elec-tronics. http://www.osek-vdx.org, 2001-2007

[Par92] Park, C.Y.: Predicting deterministic execution times of real-time programs. Seattle,WA, USA, Diss., 1992

[PASH01] Papadopoulos, Y. ; A.McDermid, J. ; Sasse, R. ; Heiner, G.: Analysis andSynthesis of the Behaviour of Complex Programmable Electronic Systems inConditions of Failure. In: Reliability Engineering and System Safety, ElsevierScience, June 2001, S. 71(3):229–247

[PEPP06] Pop, P. ; Eles, P. ; Peng, Z. ; Pop, T.: Analysis and optimi-zation of distributed real-time embedded systems. In: ACM Trans.Des. Autom. Electron. Syst. 11 (2006), Nr. 3, S. 593–625. http://dx.doi.org/http://doi.acm.org/10.1145/1142980.1142984. – DOIhttp://doi.acm.org/10.1145/1142980.1142984. – ISSN 1084–4309

[PF99] Petters, S. M. ; Färber, G.: Making Worst Case Execution Time Analysis forHard Real-Time Tasks on State of the Art Processors Feasible. In: RTCSA ’99:Proceedings of the Sixth International Conference on Real-Time Computing Systemsand Applications. Washington, DC, USA : IEEE Computer Society, 1999. –ISBN 0–7695–0306–3, S. 442

[Pik06] Pike, L.: Formal Verification of Time-Triggered Systems, Indiana University, Diss.,2006. citeseer.ist.psu.edu/pike06formal.html

[PK89] Puschner, P. ; Koza, Ch.: Calculating the maximum, execution ti-me of real-time programs. In: Real-Time Syst. 1 (1989), Nr. 2, S. 159–176. http://dx.doi.org/http://dx.doi.org/10.1007/BF00571421. – DOIhttp://dx.doi.org/10.1007/BF00571421. – ISSN 0922–6443

[PK02] Pohjonen, R. ; Kelly, S.: Domain-Specific Modeling. In: Dr. Dobb’s Journal27 (2002), August, Nr. 8, http://www.ddj.com. http://www.ddj.com/ftp/2002/2002_08/dsm.txt;http://www.ddj.com/ftp/2002/2002_08/dsm.zip.– ISSN 1044–789X

[PPE+06] Pop, T. ; Pop, P. ; Eles, P. ; Peng, Z. ; Andrei, A.: Timing Analysis of theFlexRay Communication Protocol. In: ECRTS ’06: Proceedings of the 18th Euro-micro Conference on Real-Time Systems. Washington, DC, USA : IEEE ComputerSociety, 2006. – ISBN 0–7695–2619–5, S. 203–216

[PT07] Platzner, M. ; Thiele, L.: Skriptum zur Vorlesung Hardware/Software Co-design / ETH Zürich - Institut für Technische Informatik und Kommunika-tionsnetze. 2007. – Forschungsbericht

[Pus93] Puschner, P.: Zeitanalyse von Echtzeitprogrammen (Timing Analysis for Real-Time Programs). Treitlstr. 1-3/3/182, 1040 Vienna, Austria, Technische Uni-versität Wien, Institut für Technische Informatik, Diss., 1993


[PV97a] Puschner, P. ; Vrchoticky, A.: Problems in Static Worst-Case ExecutionTime Analysis. In: Irmscher, Klaus (Hrsg.) ; Mittasch, Christian (Hrsg.); Richter, Klaus (Hrsg.): MMB (Kurzbeiträge), TU Bergakademie Freiberg,1997. – ISBN 3–86012–045–X, 18-25

[PV97b] Puschner, Peter P. ; Vrchoticky, Alexander: Problems in Static Worst-CaseExecution Time Analysis. In: MMB (Kurzbeiträge), 1997, S. 18–25

[Que06] Quecke, H. ; Vector Informatik GmbH (Hrsg.): DaVinci Network DesignerCAN - Message Timing User Documentation. Version 1.0. Vector InformatikGmbH, Februar 2006

[R. 95] R. Shishko et al. ; Aeronautics, Headquarters: N. (Hrsg.) ; Administrati-on., Space (Hrsg.): NASA Systems Engineering Handbook. SP-6105. Shishko, R.(1995). NASA Systems Engineering Handbook, SP-6105. Headquarters: Na-tional Aeronautics and Space Administration., 1995

[Rai02] Raisch, A.: Calculation of Signal Latencies and Bus Loads in Vehicle Networks.Vector Congress 2002, September 2002. – Vector Informatik GmbH

[Raj05] Rajamani, R.: Vehicle Dynamics and Control. Springer Science+Business Me-dia, 2005 (Mechanical Engineering)

[Rau07a] Rausch, M. ; Fachbuchverlag, Hanser (Hrsg.): FlexRay. Bd. 1. Auflage.Hanser Fachbuchverlag, 2007

[Rau07b] Rausch., M.: FlexRay: Grundlagen, Funktionsweise, Anwendung. 1. Auflage.München : Hanser, 2007

[RE02] Richter, K. ; Ernst, R.: Event model interfaces for heterogeneous system analysis.citeseer.ist.psu.edu/richter02event.html. Version: 2002

[Ric07] Richter, K.: Schedulinganalysen für FlexRay - Warum? In: DESIGN undELEKTRONIK Entwicklerforum 07. Ludwigsburg, 2007

[Ric08] Richter, K.: Defining a Timing Model for AUTOSAR - Status and Challen-ges. In: Software Engineering Conference - Workshop Automotive Software Engi-neering: Forschung, Lehre, Industrielle Praxis. München, Februar 2008

[Rin02] Ringler, T.: Entwicklung und Analyse zeitgesteuerter Systeme. Stuttgart, Univer-sität Stuttgart, Fakultät für Informatik, Elektrotechnik und Informationstech-nik, Institut für Automatisierungs- und Softwaretechnik, Dissertation, No-vember 2002

[RK07] Rajnak, A. ; Kumar, A.: Computer-aided architecture design & optimizedimplementation of distributed automotive EE systems. In: DAC ’07: Procee-dings of the 44th annual conference on Design automation. New York, NY, USA :ACM, 2007. – ISBN 978–1–59593–627–1, S. 556–561

[RMBK07] Rzepka, M. ; Mickisch, W. ; Brandstätter, W. ; Kaindl, M.: Validationof FlexRay(tm) networks - interoperability test concepts and experiences. FlexRayProduct Day 2007, November 2007. – Fellbach, Stuttgart


[Rob91] Robert Bosch GmbH ; ISO11898, Technical R. (Hrsg.): CAN SpecificationVersion 2.0 / Robert Bosch GmbH. Robert Bosch GmbH, 1991. – TechnicalReport ISO11898

[Rob02] Robert Bosch GmbH - Automotive Electronics Semiconductors and In-tegrated Circuits - Digital CMOS Design Group: TTCAN IP Module User’sManual. Revision 1.6, November, 2002

[Rom06] Romberg, Jan: Synthesis of distributed systems from synchronous dataflow pro-grams. München, Technische Universität München - Fakultät für Informatik- Lehrstuhl für Software- und Systems Engineering, Dissertation, Juni 2006

[RWV97] Råde, L. ; Westergren, B. ; Vachenauer, P.: Springers mathe-matische Formeln : Taschenbuch für Ingenieure, Naturwissenschaftler, Wirt-schaftswissenschaftler. 2., korrigierte und erw. Aufl. Springer,1997 http://gso.gbv.de/DB=2.1/CMD?ACT=SRCHA&SRT=YOP&IKT=1016&TRM=ppn+227443535&sourceid=fbw_bibsonomy. – ISBN 3–540–62829–0

[RZE+02] Richter, K. ; Ziegenbein, D. ; Ernst, R. ; Thiele, L. ; Teich, J.: Modelcomposition for scheduling analysis in platform design. citeseer.ist.psu.edu/richter02model.html. Version: 2002

[SAHP97] Stappert, Friedhelm ; Altenbernd, Peter ; Hard, Straight line ; Programs,Real time: Complete Worst-Case Execution Time Analysis of Straight-lineHard Real-Time Programs. In: Journal of Systems Architecture 46 (1997), S.200–0

[Sal06] Salzmann, C.: AUTOSAR - First Experiences and the Migration Strategyof the BMW Group / BMW Car IT GmbH. ARTIST2 WS - http://www.artist-embedded.org, März 2006. – Forschungsbericht

[Saw] Sawodny, O.: Systeme mit verteilten Parametern - Systemeigenschaften - Klassifi-kation von Systemen. – Universität Stuttgart - ISYS

[SBV+02] Scheidler, C. ; Boutin, S. ; Virnich, U. ; Rennhack, J. ; Grünsteidl, G.; Pisecky, M. ; Lang, R. ; Kirner, R. ; Papadopoulos, Y.: Systems Engi-neering von zeitgesteuerten Systemen - die SETTA Methodik. In: VDI/VDEGMA Fachtagung, Steuerung und Regelung von Fahrzeugen und Motoren - Auto-Reg 2002. Mannheim, Germany, April 2002, S. 663–676

[Sch96] Schedl, A.: Design and Simulation of Clock Synchronization in Distributed Sys-tems, TU Wien, Dissertation, 1996

[Sch06] Schlosser, J.: Architektursimulation von verteilten Steuergerätesystemen. Berlin,Technische Universität München, Fakultät für Informatik, Diss., 2006

[Sch07] Schedl, A.: Goals and Architecture of FlexRay at BMW. Vector FlexRay Sym-posium Stuttgart, März 2007

[Sch08] Schneider, T.: Analyse und Konzeption von Berechnungsvorschriften zur Parame-trisierung der FlexRay-Bussysteme, Universität Karlsruhe (TH), Diplomarbeit,2008


[Sha89] Shaw, A.: Reasoning about time in higher-level language software. In: IEEETransactions on Software Engineering 15 (1989), S. 875–889

[SHH+03] Schätz, B. ; Hain, T. ; Houdek, F. ; Prenninger, W. ; Rappl, M. ; Rom-berg, J. ; Slotosch, O. ; Strecker, M. ; Wisspeintner, A.: CASE Tools forEmbedded Systems / Technische Universität München. 2003 (TUM-I0309). –Forschungsbericht

[Sim99] Simon, D. E.: An Embedded Software Primer. Boston, MA, USA : Addison-Wesley Longman Publishing Co., Inc., 1999. – ISBN 020161569X

[SK06] Steiner, W. ; Kopetz, H.: The Startup Problem in Fault-Tolerant Time-Triggered Communication, 2006

[SN03] Saket, R. ; Navet, N.: Frame Packing Algorithms for Automotive Applica-tions, / Rapport de recherche de l’INRIA. 2003 (INRIA RR-4998). – For-schungsbericht

[SNA00] Sandstrom, K. ; Norstom, C. ; Ahlmark, M.: Frame packing in real-time communication. In: rtcsa 00 (2000), S. 399. http://dx.doi.org/http://doi.ieeecomputersociety.org/10.1109/RTCSA.2000.896418. – DOIhttp://doi.ieeecomputersociety.org/10.1109/RTCSA.2000.896418. – ISSN1533–2306

[Som01] Sommerville, I.: Software Engineering. Bd. 6. Auflage. Pearson Studium, 2001.– ISBN 3827370019

[SP96] Srinivas, M. ; Patnaik, L. m.: Genetic Search: Analysis Using Fitness Mo-ments. In: IEEE Trans. on Knowl. and Data Eng. 8 (1996), Nr. 1, S. 120–133. http://dx.doi.org/http://dx.doi.org/10.1109/69.485641. – DOIhttp://dx.doi.org/10.1109/69.485641. – ISSN 1041–4347

[Spr96] Spreng, M.: Rapid Prototyping elektronischer Steuerungssysteme in der Auto-mobilentwicklung. Karlsruhe, Universität Karlsruhe (TH) - Fakultät für Elek-trotechnik - Institut für Technik der Informationsverarbeitung, Dissertation,1996

[SSV06] Scharnhorst, T. ; Schwab, G. ; Valentini, H.-D.: Anforderungen an robusteE/E-Systeme im Fahrzeug. 10. Jahrestagung Ëlektronik-Systeme im Automo-bil", Februar 2006

[Sta73] Stachowiak, H.: Allgemeine Modelltheorie. 1973 http://www.amazon.de/Allgemeine-Modelltheorie-Herbert-Stachowiak/dp/3211811060/ref=sr_1_2/028-1073608-4157317?ie=UTF8&s=books&qid=1190302420&sr=1-2

[Sta01] Stauner, T.: Systematic Development of Hybrid Systems. München, TechnischeUniversität München - Fakultät für Informatik - Lehrstuhl für Software- undSystems Engineering, Dissertation, 2001

[Sto07] Storjohann, K.: Durchgängiges E/E-Produktdokumentations- und Change-Management - (DEEP-C) / DaimlerChrysler AG. VECTOR FORUM, 2007. –Forschungsbericht


[Sur08] Surmann, T.: Konfigurierung, Implementierung und Analyse eines FlexRay-Netzwerkes. Stuttgart, Dr. Ing. h.c. F. Porsche AG, Studienarbeit, 2008

[Sus07] Sussman, G. J.: Building Robust Systems an essay. Massachusetts Institute ofTechnology, Januar 2007

[SW07] Scharnhorst, T. ; Wiechmann, S.: Zuverlässigkeit von Fahrzeugelektronik. 11.Euroforum Jahrestagung Ëlektronik-Systeme im Automobil", Februar 2007. –München

[Syn08] Synopsis Corp.: Saber Design and Simulation. http://www.synopsys.com/products/mixedsignal/saber/saber.html, Juni 2008

[Sys06] SysML Partners: OMG SysML Specification V.1.0 (Final Adopted Specification).http://www.sysml.org, Mai 2006

[SZ03] Schäuffele, J. ; Zurawka, T.: Automotive Software Engineering. 1. Auflage.Vieweg Verlag, 2003. – ISBN 3–528–01040–1

[Tan00] Tanenbaum, A. S.: Computernetzwerke. 3. revidierte Auflage. München :Pearson Studium, 2000. – ISBN 3–8273–7011–6

[TB94] Tindell, K. ; Burns, A.: Guaranteed Message Latencies for DistributedSafety-Critical Hard Real Time Control Networks / Dept. Computer Science,Univ. of York. York, UK, 1994. – Forschungsbericht

[TC94] Tindell, K. ; Clark, J.: Holistic Schedulability Analysis for Distributed HardReal-Time Systems. In: Microprocessing and Microprogramming 40 (1994), S.117–134

[Tec08] Technologies, Esterel: Scade Suite. http://www.esterel-technologies.com/products/scade-suite/, Oktober 2008

[Tel06] Telelogic AB: Telelogic DOORS. http://www.telelogic.de/products/doors/index.cfm, 2006

[Teu08] Teuchert, S.: Technik treibt die Organisation - der ganzheitlich imple-mentierte funktionsorientierte Systementwicklungsprozess bei MAN / MANNutzfahrzeuge AG. Vector Kongress, 2008 2008. – Forschungsbericht

[Tha00] Thane, H.: Monitoring, Testing and Debugging of Distributed Real-Time Systems.Stockholm, Royal Institute of Technology Sweden - Department of MachineDesign - Mechatronics Laboratory, Dissertation, Mai 2000. http://www.mrtc.mdh.se/index.php?choice=publications&id=0242

[The07a] The MathWorks Inc.: Matlab. http://www.mathworks.com/products/matlab/, 2007

[The07b] The MathWorks Inc.: Stateflow. http://www.mathworks.com/products/stateflow/, 2007

[Trö05] Tröster, F.: Steuerungs- und Regelungstechnik für Ingenieure. 2. Auflage. Ol-denbourg Verlag, 2005


[TS06] Tanenbaum, A. S. ; Steen, M. van ; Hall, Prentice (Hrsg.): DistributedSystems. Principles and Paradigms. 2. Auflage. Prentice Hall, 2006. – ISBN0132392275

[TTA07] TTAutomotive Software GmbH: TTXPlan - The FlexRay Cluster Design Tool.http://www.ttautomotive.de/produkte/ttx-plan.htm, April 2007. – Ver-sion 1.2.46

[TTT03] TTTech: TTP Time-Triggered Protocol TTP/C - High-Level Specification Document- Protocol Version 1.1 - Spezifikation Edition 1.4.3. http://www.ttagroup.com/technology/specification.htm, November 2003

[Ung07] Ungermann, J.: Calculation of the FlexRay Clock Precision / Philips Rese-arch. Aachen, Dezember 2007 (TN-2007-00904). – Technical note. – Unclassi-fied Internal Document

[Vec07] Vector Informatik GmbH ; Vector Informatik GmbH (Hrsg.): DaVinciNetwork Designer FlexRay Object Properties. Version 1.1. Vector InformatikGmbH, 2007

[VG92] Vahid, F. ; Gajski, D. D.: Specification partitioning for system design. In:DAC ’92: Proceedings of the 29th ACM/IEEE conference on Design automation.Los Alamitos, CA, USA : IEEE Computer Society Press, 1992. – ISBN 0–89791–516–X, S. 219–224

[VHHM03] Versteegen, G. ; Heßeler, A. ; Hood, C. ; Missling, C. ; Verlag, Springer(Hrsg.): Anforderungsmanagement. 1. Auflage. Berlin : Springer Verlag, 2003

[VR01] Verissimo, P. ; Rodrigues, L.: Distributed Systems for System Architects. Nor-well, MA, USA : Kluwer Academic Publishers, 2001. – ISBN 0792372662

[Wal08] Walz, S.: Integrated EE-Architecture Design / Mentor Graphics (Deutsch-land) GmbH. Synergy Forum Äircraft meets AutomotiveSSystem Architec-tures, Mai 2008. – Forschungsbericht

[Web94] Weber, M.: Verteilte Systeme. Spektrum Akademischer Verlag, 1994. – ISBN0–07–113688–1

[WEE+08] Wilhelm, R. ; Engblom, J. ; Ermedahl, A. ; Holsti, N. ; Thesing, S. ; Whal-ley, D. ; Bernat, G. ; Ferdinand, C. ; Heckmann, R. ; Mueller, F. ; Puaut, I. ;Puschner, P. ; Staschulat, J. ; Stenström, P.: The Determination of Worst-Case Execution Times—Overview of the Methods and Survey of Tools. 7(2008), Nr. 3. – ACM Transactions on Embedded Computing Systems (TECS)

[Wei06] Weilkiens, T.: Systems Engineering mit SysML/UML Modellierung, Analyse,Design. Dpunkt.Verlag GmbH, 2006. – ISBN 3–89864–409–X

[Wie02] Wieringa, R. J.: Design Methods for Software Systems: YOURDON, Statemateand Uml. Science & Technology Books, 2002. – ISBN 1558607552

[WL88] Welch, J. L. ; Lynch, N.: A new fault-tolerant algorithm for clocksynchronization. In: Inf. Comput. 77 (1988), Nr. 1, S. 1–36. http://dx.doi.org/http://dx.doi.org/10.1016/0890-5401(88)90043-0. – DOIhttp://dx.doi.org/10.1016/0890–5401(88)90043–0. – ISSN 0890–5401


[WP07] W.Böge ; Plaßmann, W. ; Vieweg+Teubner (Hrsg.): Vieweg Handbuch Elek-trotechnik: Grundlagen und Anwendungen für Elektrotechniker. 4. überarb. A.Vieweg+Teubner, 2007

[WW03] Weber, M. ; Weisbrod, J.: Requirements Engineering in Au-tomotive Development: Experiences and Challenges. In: IEEESoftware 20 (2003), Nr. 1, S. 16–24. http://dx.doi.org/http://doi.ieeecomputersociety.org/10.1109/MS.2003.1159025. – DOIhttp://doi.ieeecomputersociety.org/10.1109/MS.2003.1159025. – ISSN0740–7459

[WW04] Wenzel, M. ; Wille, M.: Bedien- und Anzeigeprotokoll trennt Funktion undGestaltung. In: Elektronik Automotive 6 (2004), S. 30–32

[Wym76] Wymore, W. ; Wiley (Hrsg.): Systems Engineering Methodology for Interdiscipli-nary Teams. New York, 1976

[YC75] Yourdon, E. ; Constantine, L. L.: Structured Design. Yourdon Press, 1975

[zei08] zeitware: TDL Technology. http://www.zeitware.org/, Oktober 2008

[Zim88] Zimmermann, H.: OSI reference model—The ISO model of architecture foropen systems interconnection. (1988), S. 2–9. ISBN 0–89006–337–0

[ZS06] Zimmermann, W. ; Schmidgall, R.: Bussysteme in der Fahrzeugtechnik. View-eg Verlag, April, 2006

ANHANG A

Graphische Analyse des NutzdatenvolumensNv(x) im statischen FlexRay-Segment

Sei f : D ∈ R → R eine Abbildung mit f (x) := Lx ∗ (x − c(x)) und D = [a, b]. Die

Funktion f (x) stellt die Menge der Nutzdaten im statischen Segment pro Zyklus dar.Die Variable x sei die Länge eines Slots im statischen Segment, der fixe Parameter L dieLänge des statischen Segments pro Zyklus und c der Overhead, der pro Slot im stati-schen Segment anfällt. Damit bildet x − c(x) die Menge der Nutzdaten pro Slot. Mannehme einen linearen Verlauf von c(x) an und definiere c(x) := 1 + x

10 .

Abbildung A.1.: Die Funktion f (x) = Lx ∗ (x − c(x))

275

276ANHANG A. GRAPHISCHE ANALYSE DES NUTZDATENVOLUMENS NV(X) IM

STATISCHEN FLEXRAY-SEGMENT

Zur Veranschaulichung wird die Funktion f (x) im Definitionsintervall D = [2, 100]in Abb. A.1) gezeichnet.Der Verlauf des Graphen erscheint plausibel. Je größer ein Slotgewählt wird, desto mehr Nutzdaten können pro Zyklus im statischen Segment über-tragen werden.

Sei nun f : D ∈ R2 → R eine Abbilung mit f (x, L) := Lx ∗ (x − c(x)) und D = [a, b]2.

Die Funktion f (x, L) stellt die Menge der Nutzdaten im statischen Segment pro Zyklusdar. Zu beachten ist dabei, dass hier x und L variabel sind. Die Bedeutung der Variablenx und L behalten ihre Gültigkeit. Man definiere wieder c(x) := 1 + x

10 .Zur Veranschaulichung wird die Funktion f (x, L) im Definitionsbereich D = [2, 100]2

in Abb. A.2) gezeichnet. Der Verlauf des Graphen erscheint auch hier plausibel, da ab-hängig von der Zykluslänge L bei konstanter Slotgröße x die Nutzdaten pro Zyklusf (x, L) ansteigen. Werden die Zykluslänge L und die Slotgröße x möglichst groß ge-wählt, so können auch am meisten Nutzdaten pro Zyklus f (x, L) übertragen werden.

Abbildung A.2.: Die Funktion f (x, L) = Lx ∗ (x − c(x))

A.1. Definition des Nutzdateneffizienz-Funktionals Ne(x)

Definition A.1.1 (Nutzdateneffizienz-Funktional) Sei X = R5 ein normierter Vektorraumund Ne : De

1 ⊂ X → Y = R in den Nicht-Sprungstellen eine Frechet-differenzierbare Abbil-dung. Und es gilt:

Ne(x) =1

x7 ∗ (2 ∗ x4 + ceil( (x1+c1+c2+20∗x2+c3+c5)∗(c4∗x3∗(1+c6))+α1+α3x7∗(1−c6)

))∗ 16 ∗ c4 ∗ x3 ∗ x2

Dann heißt Ne(x) Nutzdateneffizienz-Funktional für eine FlexRay-Parameterkonfiguration.Ausgedrückt mit dem Funktional k3(x) lässt sich Ne(x) auch schreiben als :

1Der Definitionsbereich De wird in Definition A.3.2 erklärt

A.2. DEFINITION DER RESTRIKTIONSABBILDUNG GE(X) 277

Ne(x) =1

x7 ∗ (2 ∗ x4 + k3(x))∗ 16 ∗ c4 ∗ x3 ∗ x2

�

A.2. Definition der Restriktionsabbildung Ge(x)

Sämtliche Restriktionen zur Eingrenzung der Berechnung von Ne(x) werden in der fol-genden Definition in einer Abbildung zusammengefasst.

Definition A.2.1 (Restriktionsabbildung Ge(x)) Sei x ∈ De ⊂ R5. Dann heißt die in denNicht-Sprungstellen Frechet-differenzierbare Abbildung Ge : De → R26 mit

Ge(x) =

⎛⎜⎜⎜⎜⎜⎝

g1(x)g2(x)g3(x)

...g26(x)

⎞⎟⎟⎟⎟⎟⎠

Restriktionsabbildung des Nutzdateneffizienz-Funktionals Ne(x).

�

A.3. Definitionsbereich für Nv und Ne

Definition A.3.1 (Definitionsbereich Dv) Der Definitionsbereich des Nutzdatenvolumen-Funktionals Nv(x) wird mit Dv ⊂ R8 bezeichnet. Es gilt:

Dv = [3, 15] × [0, 127] × [0.0125, 0.05] × [1, 63] × [1, 6] × [10, 16000] × [2, 805] × [1, 31]

�

Definition A.3.2 (Definitionsbereich De) Der Definitionsbereich des Nutzdateneffizienz-Funktionals Ne(x) wird mit De ⊂ R5 bezeichnet. Es gilt:

De = [3, 15] × [0, 127] × [0.0125, 0.05] × [1, 63] × [1, 6]

�

Bemerkung: Der Definitionsbereich Dv wird durch die FlexRay-Spezifikation /[Fle05a]/vorgeschrieben.

A.4. Graphische Darstellung des modifizierten Nv

In Abb. A.3 wird das modifizierte Nutzdatenvolumen-Funktional Nv(x9, x10) für denerrechneten optimalen Lösungsvektor xopt, der alle FlexRay-Restriktionen erfüllt, darge-stellt.

278ANHANG A. GRAPHISCHE ANALYSE DES NUTZDATENVOLUMENS NV(X) IM

STATISCHEN FLEXRAY-SEGMENT

Abbildung A.3.: Das Nutzdatenvolumen-Funktional Nv(x9, x10) mit dem gefundenen Lösungs-vektor xopt

ANHANG B

Spline-Koeffizienten und Funktionswerte derAuswahlfunktion

Bei der konkrete Problemstellung mit M = 21 erhält man die in Tabelle B.1 aufgelistetenKoeffizienten für die Spline-Funktion sm(t). Die Tabelle B.2 zeigt die Funktionswerte derAuswahlfunktion χm(t).

Spline am bm cm dm

s1(t) 0.0000 -0.0003 0.0050 0s2(t) 0.0000 -0.0002 0.0006 0.0260s3(t) -0.0000 0.0001 -0.0012 0.0053s4(t) 0.0000 -0.0000 0.0001 0.0001s5(t) 0.0000 0.0000 0.0001 0.0013s6(t) 0.0000 0.0000 0.0012 0.0123s7(t) -0.0000 0.0001 0.0031 0.0534s8(t) -0.0000 0.0000 0.0046 0.1322s9(t) -0.0000 -0.0001 0.0034 0.2193s10(t) 0.0000 -0.0001 -0.0011 0.2460s11(t) 0.0000 -0.0001 -0.0050 0.1789s12(t) -0.0000 0.0001 -0.0042 0.0770s13(t) -0.0000 0.0000 -0.0013 0.0247s14(t) -0.0000 0.0000 -0.0003 0.0116s15(t) 0.0000 -0.0000 -0.0002 0.0075s16(t) -0.0000 0.0000 -0.0002 0.0033s17(t) -0.0000 0.0000 -0.0001 0.0008s18(t) -0.0000 0.0000 -0.0000 0.0001s19(t) 0.0000 -0.0000 0.0000 0.0000s20(t) 0.0000 0.0000 -0.0000 0

Tabelle B.1.: Spline-Koeffizienten von sm(t)

279

280ANHANG B. SPLINE-KOEFFIZIENTEN UND FUNKTIONSWERTE DER

AUSWAHLFUNKTION

Auswahlfunktion Gültigkeitsintervallχ1(t) 0 ≤ t ≤ 10χ2(t) 10 ≤ t ≤ 30χ3(t) 30 ≤ t ≤ 50χ4(t) 50 ≤ t ≤ 70χ5(t) 70 ≤ t ≤ 90χ6(t) 90 ≤ t ≤ 110χ7(t) 110 ≤ t ≤ 130χ8(t) 130 ≤ t ≤ 150χ9(t) 150 ≤ t ≤ 170χ10(t) 170 ≤ t ≤ 190χ11(t) 190 ≤ t ≤ 210χ12(t) 210 ≤ t ≤ 230χ13(t) 230 ≤ t ≤ 250χ14(t) 250 ≤ t ≤ 270χ15(t) 270 ≤ t ≤ 290χ16(t) 290 ≤ t ≤ 310χ17(t) 310 ≤ t ≤ 330χ18(t) 330 ≤ t ≤ 350χ19(t) 350 ≤ t ≤ 370χ20(t) 370 ≤ t ≤ 390

Tabelle B.2.: Für den Auswahlfunktionswert χm(t) gilt innerhalb des jeweiligen Gültigkeitsin-tervalls χm(t) = 1, sonst χm(t) = 0

ANHANG C

Parameter Formalisierung

C.1. Variablendefinitionen

Variablendefinition zur Abbildung von FlexRay-Parameterbezeichnungen in mathema-tische Berechnungsterme.

x1 := gdTSSTransmitter (C.1)

x2 := gPayloadLengthStatic (C.2)

x3 := gdSampleClockPeriod (C.3)

x4 := gdActionPointO f f set (C.4)

x5 := gdBitMax (C.5)

x6 := gdMaxPropagationDelay (C.6)

x7 := gdMacrotick (C.7)

x8 := gNumberO f Minislots (C.8)

x9 := gMacroPerCycle (C.9)

x10 := gdNIT (C.10)

281

282 ANHANG C. PARAMETER FORMALISIERUNG

x11 := gNumberO f StaticSlots (C.11)

x12 := gdMinislot (C.12)

x13 := adActionPointDi f f erence (C.13)

x14 := gdSymbolWindow (C.14)

x15 := gColdStartAttempts (C.15)

x16 := gdCASRxLowMax (C.16)

x17 := gdDynamicSlotIdlePhase (C.17)

x18 := gdMinislotActionPointO f f set (C.18)

x19 := gdStaticSlot (C.19)

x20 := gdWakeupSymbolRxIdle (C.20)

x21 := gdWakeupSymbolRxLow (C.21)

x22 := gdWakeupSymbolRxWindow (C.22)

x23 := gdWakeupSymbolTxIdle (C.23)

x24 := gdWakeupSymbolTxLow (C.24)

x25 := gListenNoise (C.25)

x26 := gMaxWithoutClockCorrectionFatal (C.26)

x27 := gMaxWithoutClockCorrectionPassive (C.27)

x28 := gO f f setCorrectionStart (C.28)

x29 := gSyncNodeMax (C.29)

C.1. VARIABLENDEFINITIONEN 283

x30 := gAssumedPrecision (C.30)

x31 := gChannels (C.31)

x32 := gClusterDri f tDamping (C.32)

x33 := gdBit (C.33)

x34 := gdBitMin (C.34)

x35 := gdCycle (C.35)

x36 := gdMaxInitializationError (C.36)

x37 := gdMaxMicrotick (C.37)

x38 := gdMinPropagationDelay (C.38)

x39 := gNetworkManagementVectorLength (C.39)

x40 := gO f f setCorrectionMax (C.40)

x41 := pdMicrotick (C.41)

x42 := pdAcceptedStartupRange (C.42)

x43 := pClusterDri f tDamping (C.43)

x44 := dBDRxai (C.44)

x45 := pMicroPerCycle (C.45)

x46 := pRateCorrectionOut (C.46)

x47 := pO f f setCorrectionOut (C.47)

x48 := pExternRateCorrection (C.48)


x49 := pExternO f f setCorrection (C.49)

x50 := pdMaxDri f t (C.50)

x51 := pdListenTimeout (C.51)

x52 := pDecodingCorrection (C.52)

x53 := pSamplesPerMicrotick (C.53)

x54 := pMacroInitialO f f set (C.54)

x55 := pDelayCompensation (C.55)

x56 := pMicroPerMacroNom (C.56)

x57 := pMicroInitialO f f set (C.57)

x58 := pLatestTx (C.58)

x59 := dBDRxia (C.59)

x60 := max(x|x = x67) (C.60)

x61 := dStarTruncation (C.61)

x62 := adO f f setCorrection (C.62)

x63 := adRemRateCalculation (C.63)

x64 := adRemO f f setCalculation (C.64)

x65 := adTxMax (C.65)

x66 := aFrameLengthDynamic (C.66)

x67 := nStarPathM,N (C.67)

C.2. KONSTANTENDEFINITIONEN 285

C.2. Konstantendefinitionen

Konstantendefinition zur Abbildung von FlexRay-Konstantenbezeichnungen in mathe-matische Berechnungsterme.

c1 := cdFSS (C.68)

c2 := 80 (C.69)

c3 := cdFES (C.70)

c4 := cSamplesPerBit (C.71)

c5 := cChannelIdleDelimiter (C.72)

c6 := cClockDeviationMax (C.73)

c7 := cCASActionPointO f f set (C.74)

c8 := cdMaxO f f setCalculation (C.75)

c9 := cCrcInit[A] (C.76)

c10 := cCrcInit[B] (C.77)

c11 := cCrcPolynomial (C.78)

c12 := cCycleCountMax (C.79)

c13 := cdBSS (C.80)

c14 := cdCAS (C.81)

c15 := cdCASRxLowMin (C.82)

c16 := cdCycleMax (C.83)

c17 := cdMaxMTNom (C.84)

c18 := cdMinMTNom (C.85)


c19 := cdWakeupMaxCollision (C.86)

c20 := cdWakeupSymbolTxLow (C.87)

c21 := cdWakeupSymbolTxIdle (C.88)

c22 := cHCrcInit (C.89)

c23 := cHCrcPolynomial (C.90)

c24 := cPayloadLengthMax (C.91)

c25 := cMicroPerMacroMin (C.92)

c26 := cMicroPerMacroNomMin (C.93)

c27 := cSlotIDMax (C.94)

c28 := cStaticSlotIDMax (C.95)

c29 := cStrobeO f f set (C.96)

c30 := cSyncNodeMax (C.97)

c31 := cVotingDelay (C.98)

c32 := cVotingSamples (C.99)

c33 := cPropagationDelayMax (C.100)

c34 := cdTxMax (C.101)

C.3. α- und β-Parameter (Ne)

In Tabelle C.1 und Tabelle C.2 werden die α- und β- Parameter auf realistische (serienna-he) Werte gesetzt. Einige davon beziehen sich auf das dynamische Segment und werdenan anderer Stelle berechnet.

C.4. FLEXRAY-PARAMETRIERUNGSRESTRIKTIONEN 287

α-Parameter Wert

α1 := x6 1.42α2 := x8 siehe Kapitel 5.3.2α3 := x38 0.15α4 := x44 0.4α5 := x30 4.715

Tabelle C.1.: α-Parameter

β-Parameter Wert

β1 := x37 0.025β2 := x53 2β3 := x58 100β4 := x55 1β5 := x56 40β6 := x24 60β7 := h2 0β8 := x61 0β9 := x59 0.45β10 := x41 0.025β11 := x66 siehe Kapitel 5.3.2β12 := x36 3β13 := x17 siehe Kapitel 5.3.2β14 := x40 6β15 := x12 siehe Kapitel 5.3.2β16 := x14 0β17 := x57 2

Tabelle C.2.: β-Parameter

C.4. FlexRay-Parametrierungsrestriktionen

Anfolgend werden die wichtigsten der für Abs. 4.6 relevanten FlexRay-Restriktionen(zur Berechnung von x1, x2, x3, x4 und x7) aufgeführt.

Restriktion 5:

g1(x) := x7 − c17 ≤ 0

g2(x) := c18 − x7 ≤ 0

Die Funktionale g1(x) und g2(x) sind stetig und Frechet-differenzierbar für alle x ∈ De.

Restriktion 6:

Der Parameter β10 kann mit Hilfe der Gleichung β10 = β2 ∗ x3 ersetzt werden. Man er-hält dadurch

g3(x) := c26 ∗ (β2 ∗ x3) − x7 ≤ 0


Das Funktional g3(x) ist stetig und Frechet-differenzierbar für alle x ∈ De.

Restriktion 7:

g4(x) := x7 − (x1 + c1 + c2 + 20 ∗ x2 + c3) ∗ (c4 ∗ x3 ∗ (1 − c6)) ≤ 0


Restriktion 11:

g5(x) := ceil( (α5−α3)(x7∗(1−c6))

) − x4 ≤ 0

Das Funktional g5(x) ist stückweise stetig für alle x ∈ De und Frechet-differenzierbar inden Nicht-Sprungstellen.

Restriktion 12:

g6(x) := ceil( (2∗α5−α3+2∗β12)(x7∗(1−c6))

) − x4 ≤ 0

Das Funktional g6(x) ist stückweise stetig für alle x ∈ De und Frechet-differenzierbar inden Nicht-Sprungstellen.

Restriktion 24:

g7(x) := β14 − (x4 ∗ x7 ∗ (1 + c6) + α1 + α3) ≤ 0


Restriktion 32:

g8(x) := round( ((x1+c1+0.5∗c13)∗c4+c29+c31)β2

) − 143 ≤ 0

g9(x) := 14 − round( ((x1+c1+0.5∗c13)∗c4+c29+c31)β2

) ≤ 0

Die Funktionale g8(x) und g9(x) sind stückweise stetig für alle x ∈ De und Frechet-differenzierbar in den Nicht-Sprungstellen.

Restriktion 33:

g10(x) := x4 + ceil(((round( ((x1+c1+0.5∗c13)∗c4+c29+c31)

β2))+β4)

β5) − 68 ≤ 0

g11(x) := 2 − (x4 + ceil(((round( ((x1+c1+0.5∗c13)∗c4+c29+c31)

β2))+β4)

β5)) ≤ 0


C.4. FLEXRAY-PARAMETRIERUNGSRESTRIKTIONEN 289

Restriktion 35:

Der Parameter β10 kann ersetzt werden durch die Gleichung β10 = β2 ∗ x3. Man erhältdadurch

g12(x) := β17 − f loor( (((5+2∗x2+3)∗10−2)∗(c4∗x3∗(1−c6)))((β2∗x3)∗(1+c6))

) ≤ 0

Das Funktional g12(x) ist stückweise stetig für alle x ∈ De und Frechet-differenzierbarin den Nicht-Sprungstellen.

Restriktion 37:

g13(x) := ceil( ((c4∗x3∗(1+c6))+β9+β7∗β8)(c4∗x3∗(1−c6))

) − x1 ≤ 0

Das Funktional g13(x) ist stückweise stetig für alle x ∈ De und Frechet-differenzierbarin den Nicht-Sprungstellen.

Restriktion 38:

g14(x) := ceil(2 ∗ (x1 + c14) ∗ (1+c6)(1−c6)

+ 2 ∗ α4(c4∗x3∗(1−c6))

) − 99 ≤ 0

g15(x) := 67 − ceil(2 ∗ (x1 + c14) ∗ (1+c6)(1−c6)

+ 2 ∗ α4(c4∗x3∗(1−c6))

) ≤ 0


ANHANG D

Fallstudien

D.1. Eingangsparametersätze

Konstr A Konstr B Konstr CdBDRxia 0.3 0.45 0.35dBDRxai 0.4 0.3 0.2pdBDRx 0.075 0.1 0.075pdBDTx 0.1 0.1 0.1

pDelayCompensationA 1 6 3pDelayCompensationB 1 3 6pExternRateCorrection 0 0 0

pExternOffsetCorrection 0 0 0pPayloadDynMax 254 254 254

pSamplesPerMicrotick 2 1 4gClusterDriftDamping 2 - -

gdCycle 5000 - -gdMacrotick 1.375 - -

gdSamplesClockPeriod 0.0125 - -gNumberOfStaticSlots 91 - -gNumberOfMinislots 286 - -gPayloadLengthStatic 9 - -cClockDeviationMax 0.0015 - -

cdWakeUpSymbolTxLow 6 - -cdWakeUpSymbolTxIdle 0.3 0.45 0.35

cVotingDelay 2 - -cStrobeOffset 5 - -

cSamplesPerBit 8 - -cChannelDelimiter 11 - -

dStarTruncation 0.15 0.25 -pdStarDelay 0.25 0.25 -

Tabelle D.1.: Eingangsparametersatz bei der E/E-Architekturmodellierung

290

D.2. FLEXRAY-PARAMETERSÄTZE 291

D.2. FlexRay-Parametersätze

Abbildung D.1.: Tabellarische Gegenüberstellung zweier FlexRay-Parametersätze als Ergebniszweier unterschiedlicher E/E-Architekurvarianten.

292 ANHANG D. FALLSTUDIEN

D.3. Umsetzung von Modellabfragen

Die Modellabfrage stützt sich auf eine Mustersuche im Modell. Die Suche erfordert einQuellobjekt (beispielweise ein Steuergerät), welches gemäß den Vorgaben des zugrun-de gelegten Metamodells nach dessen Propagationen auf andere Objekte im Systemuntersucht wird. So lassen sich Zielobjekte (beispielsweise ein Sternkoppler und derFlexRay-Konnektortyp) festlegen, die in Relation zu den gesuchten Quellobjekten ste-hen müssen. Durch eine Markierung wird determiniert, welche Objekte bei der Modell-abfrage zurückgeliefert werden sollen. Eventuell interessieren neben den Quellobjektenauch weitere Aspekte, etwa eine spezifische Relation zwischen Quell- und Zielobjektoder auch das Zielobjekt selbst.

Abbildung D.2.: Suchmuster zur Identifikation von Steuergeräten mit FlexRay-Anschluss, dieeine physikalische Verbindung zu aktiven Sternkopplern im System aufweisen.

D.4. AUTOMATISCHES BUSSCHEDULING EINES FUNKTIONSNETZES 293

D.4. Automatisches Busscheduling eines Funktionsnetzes

Listing D.1: PseudoCode zum Erzeugen des Busschedulesproc generateBusschedule ( A r c h i t e c t u r e V a r i a n t a r c h i t e c t u r e L i s t [ ] ,

Frame packedFunctionNetSignals [ ] , i n t scheduleLayout [ ] ) :

A r c h i t e c t u r e V a r i a n t a c t i v e A r c h i t e c t u r e V a r i a n t =dataBase . getActiveElementFrom ( a r c h i t e c t u r e L i s t )

Frame val idFrameList [ ] =dataBase . getActiveElementsFrom ( packedFunctionNetSignals )

i n t s t a t i c S l o t s = scheduleLayout [ g d S t a t i c S l o t s P a r a m e t e r ]i n t busCyclePeriod = scheduleLayout [ gdCycle ]i n t element = 0i n t l a s t F i l l e d S l o t = 0i n t lastScheduledSender = 0boolean r e s u l t = f a l s e

// a k t u e l l e n Slotbelegungszustand mit keinem Sender und 64 f r e i e Zel len// pro S l o t i n i t i a l i s i e r e nchar slotUsed [ ] [ ] = [ ]i n t baseValue [ 2 ] = [ 0 , 6 4 ]for i n t s l o t = 0 to s t a t i c S l o t s :do

slotUsed . append ( baseValue )od// prüfen ob Slo tanzahl der Archi tektur e r m i t t e l t wurden und ob g ü l t i g e// Botschaf ten e x i s t i e r e ni f s t a t i c S l o t s != 0

i f val idFrameList != [ ]r e s u l t = truechar scheduleTable [ 6 4 ] [ s t a t i c S l o t s ] = [ ]for i n t c y c l e = 0 to 6 3 :do

for s l o t to s t a t i c S l o t s :do

scheduleTable [ c y c l e ] [ s t a t i c S l o t s ] = " 0 "od

odopen_gen_f i le ( d i r + "/busSchedule . csv " )

// die Botschaf ten werden s e q u e n t i e l l ent lang der S l o t s im Schedulep l a t z i e r t

for Frame flexrayFrame in val idFrameList :do

// determinieren , welche Sendezyklen pro B o t s c h a f t g ü l t i g sindSigna l s i g n a l s [ ] = getSignalTimings ( f lexrayFrame )for f l e x r a y S i g n a l in s i g n a l s :do

signalCycleTime = 64* busCyclePeriodt r y :

TransmissionPort sendPorts [ ] = f l e x r a y S i g n a l .mappedTransmissionPorts

FNElement l o g i c a l S e n d e r = sendPorts [ 0 ] . mappedFNElementECU networkSender = getHWDeployment ( l o g i c a l S e n d e r )

except :p r i n t " Kein Sender wurde b i s h e r d e f i n i e r t ! "

i f f l e x r a y S i g n a l . cycleTime <signalCycleTime :signalCycleTime = f l e x r a y S i g n a l . cycleTime

f iod// Botschaf tswiederholungsrate bezogen auf Buszykluslänge e r m i t t e l nr e p e t i t i o n = getFrameCycleTime ( signalCycleTime )element = l a s t F i l l e d S l o t

i n t f r e e c e l l s = 0

294 ANHANG D. FALLSTUDIEN

i n t column = 0while element =< s t a t i c S l o t s :do

// prüfen , ob f r e i e Zel len des a k t u e l l e n S l o t s ausreichen// zum Einfügen der a k t u e l l e n B o t s c h a f ti n t f r e e C e l l s = ( i n t ) s lotUsed [ element ][1] − (64/ r e p e t i t i o n )i f ( i n t ) s lotUsed [ element ] [ 0 ] == 0 :

// f a l l s B o t s c h a f t i und B o t s c h a f t i +1 vom gle ichen Sender ,// dann wird der Frame zum Balanc ieren der S l o t s wei ter// hinten im Schedule e ingefügti f networksender . ToStr ing ( ) == lastScheduledSender . ToStr ing ( ) :

element = l a s t F i l l e d S l o t +10l a s t F i l l e d S l o t = element

else :l a s t F i l l e d S l o t = element

f inewElement [ ] = [ ]//Sender und r e s t l i c h e f r e i e Zel len des S l o t s e r m i t t e l nnewElement . append ( networkSender )newElement . append ( f r e e C e l l s )slotUsed [ element ] = newElementlastScheduledSender = networkSenderbreak

e l i f networkSender . ToStr ing ( ) == slotUsed [ element ] [ 0 ] . ToStr ing ( ) &&f r e e c e l l s > −1:slotUsed [ element ] [ 0 ] = networkSenderslotUsed [ element ] [ 1 ] = slotUsed [ element ][1] − (64/ r e p e t i t i o n )break

f ielement = element+1

odi n t i = 0while i < 6 3 :do

scheduleTable =wri tescheduleTable ( i , l a s t F i l l e d S l o t , f lexrayFrame , scheduleTable )i = i + r e p e t i t i o n

ododw r i t e _ g e n _ f i l e ( scheduleTable )c l o s e _ g e n _ f i l e ( )i f ( r e s u l t == true ) :

dataBase . setOutput ( scheduleTable )else :

dataBase . setOutput ( [ ] )f i

e l se :// f a l l s keine gül t igen Botschaf ten d e t e k t i e r t werden könnendataBase . setOutput ( [ ] )

f ie l se :

// f a l l s keine FlexRay−Parameter zum Schedule−Layout d e t e k t i e r t werden könnendataBase . setOutput ( [ ] )

f i

f c t i n t getFrameCycleTime ( signalCycleTime ) :i n t r e p e t i t i o n = 0for i n t c y c l e R e p e t i t i o n = 6 to 0 :do

i f signalCycleTime >= busCyclePeriod *2^ c y c l e R e p e t i t i o n :r e p e t i t i o n = 2^ c y c l e R e p e t i t i o n

f ireturn r e p e t i t i o n

f c t i n t [ ] [ ] writeScheduleTable ( i n t l i n e , i n t column , Frame frame , char inputTable [ ] [ ] ) :char t a b l e [ ] [ ] = inputTable// Var iable zum Anzeigen e ines b e r e i t s be legten S l o t si n t blocked = 0

D.5. EINSCHRÄNKUNGEN IM PARAMETRIERUNGSPROZESS 295

i f ( ( i n t ) t a b l e [ l i n e ] [ column ] != 0) :blocked = 1i f l i n e <63 && blocked == 1 :

// a k t u e l l e FlexRay−Z e l l e i s t b e l e g t => Funktionsrekursion mit// nächster FlexRay−Z e l l el i n e = l i n e +1writeScheduleTable ( l i n e , column , frame , t a b l e )

f ie l se :

// Name der in d i e s e r FlexRay−Z e l l e versendeten B o t s c h a f t wird e ingefügtt a b l e [ l i n e ] [ column ] = frame . getName ( )

f ireturn t a b l e

D.5. Einschränkungen im Parametrierungsprozess

Abbildung D.3.: Mathematischer Zyklus bei der Berechnung (gdStaticSlot →gMacroPerCycle → gdMacrotick → gdStaticSlot).

Lebenslauf

Zur Person Julian Broy

Derzeitige Stellung: Entwicklungsingenieur

geboren am 30. April 1981 in Dachau, Deutschland

verheiratet mit Mariana Broy

Wohnsitz: 71634 Ludwigsburg

E-Mail: [email protected]

Ausbildung

2005–2008 Promotion, Fakultät für Elektrotechnik der Universität Karlsruhe(TH) in Zusammenarbeit mit der Dr. Ing. h.c. F. Porsche AG, Ent-wicklungszentrum Weissach

2000–2005 Studium der Informatik, Technische Universität MünchenAbschluß mit Diplom mit Auszeichnung

1991–2000 Gymnasium OberhachingAbschluß mit Abitur

Berufliche Laufbahn

2008–heute Projektingenieur Vernetzung/Diagnose/Gateways, Dr. Ing. h.c. F.Porsche AG, Entwicklungszentrum Weissach

2004-2005 Diplomarbeit, Dr. Ing. h.c. F. Porsche AG, EntwicklungszentrumWeissach

2003–2004 Werkstudententätigkeit, Fakultät für Informatik, Technische Uni-versität München

2003–2004 Werkstudententätigkeiten, Pontifíca Universidade Católica Rio deJaneiro, Brasilien

2000–2003 Praktikum und Werkstudententätigkeiten, sd&m AG, München

Modellbasierte Entwicklung und Optimierung flexibler ...

Documents