Departement Industriële Wetenschappen en Technologie Academiejaar Cursuscode(s): KdG-IWT-MA-EI Automotive Software

.

Master IW - Elektronica-ICT Departement Industriële Wetenschappen en Technologie Academiejaar 2011-2012 Cursuscode(s): KdG-IWT-MA-EI-10-404

Automotive Software Cursusnota's Auteur(s): P. Hellinckx, P. De Meulenaere, J. Denil Titularis(sen): Peter Hellinckx Paul De Meulenaere Joachim Denil 2011

Commentaar: Eerste versie

ol ch o ge s ot eHo Gr e ld Ka re 11 20 ht py rig Co This document has been typeset using LATEX and the kdgcoursetext class. !!!NOG INVULLEN!!! NCC-2011-001 CONFIDENTIAL AND PROPRIETARY. © 2011 Karel de Grote-Hogeschool, All rights reserved.

ge s

ch o

ol

Inhoudsopgave 1 Introductie tot Automotive Software Engineering

2

Definitie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.2

Geschiedenis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

ot eHo

1.1

2 Real-time Besturingssysteem

3

OSEK overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.2

OSEK OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

Proces niveaus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.2.2

Conformance klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.2.3

Taken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.2.4

Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.2.5

Interrupt processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.2.6

Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.2.7

Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.8

Counters en Alarmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

py rig

ht

20

11

Ka re

ld

2.2.1

2.2.9

Starten, stoppen en errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

AUTOSAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Co

2.3

e

Gr

2.1

3 Automotive Datacommunicatie 3.1

3.2

18

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1.1

Het OSI-model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.2

Classificatie van protocollen . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.3

Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Theoretische Aspecten

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 i

INHOUDSOPGAVE

3.2.2

De fysische laag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.3

Datalink laag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

CAN: Controller Area Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.3.2

Fysieke lagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.3.3

Datalink laag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

CAN hogere lagen protocollen

ge s

ch o

ol

3.3.1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

TTCAN: Time-Triggered CAN . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.4.2

Vrachtwagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.4.3

Personenwagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.4.4

CAN in andere domeinen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Gr

ot eHo

3.4.1

e

de LIN bus: Local Interconnect network . . . . . . . . . . . . . . . . . . . . . . . . 56 3.5.1

Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.5.2

Fysieke laag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.5.3

Datalink laag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.5.4

Transport laag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.5.5

Applicatie laag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

ld

3.5

Terminologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Ka re

3.4

3.2.1

11

3.3

ii

ByteFlight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.7

TTP: Time Triggered Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.8

FlexRay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 3.8.1 3.8.2

Introductie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 FlexRay Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 De EPL: Electrical Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . 81

Co

3.8.3

py rig

ht

20

3.6

3.8.4

Topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

3.8.5

FlexRay Communicatie Cyclus . . . . . . . . . . . . . . . . . . . . . . . . . 83

3.8.6

Frame Formaat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

3.8.7

Coding en decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

3.8.8

Protocol Operation Control (POC) . . . . . . . . . . . . . . . . . . . . . . . 91

NCC-2011-001

KdG–IWT

Automotive Software

INHOUDSOPGAVE 3.8.9

iii

Wakeup en Startup procedure

. . . . . . . . . . . . . . . . . . . . . . . . . 94

Co

py rig

ht

20

11

Ka re

ld

e

Gr

ot eHo

ge s

ch o

ol

3.8.10 Klok synchronisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

NCC-2011-001

KdG–IWT

Automotive Software

ht

py rig

Co

11

20 Ka re ld e Gr

ot eHo

ch o

Situering cursus

ge s

ol

Inleiding

1

ch o

ol

Hoofdstuk 1

Definitie

Gr

1.1

ot eHo

ge s

Introductie tot Automotive Software Engineering

ld

Geschiedenis

Ka re

1.2

e

Test

Co

py rig

ht

20

11

Test2

2

2.1

ot eHo

ge s

Real-time Besturingssysteem

ch o

ol

Hoofdstuk 2

OSEK overzicht

Figuur 2.1: OSEK en OSEKtime overzicht

Co

py rig

ht

20

11

Ka re

ld

e

Gr

OSEK/VDX (offene systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug) is een standaard die bestaat uit 4 documenten die de eisen definiëren van 2 besturingssystemen (OSEK /OSEKtime). Ze hebben elk hun eigen communicatieservices (COM / FTCOM) gelinkt aan hun respectievelijk besturingssysteem. Ze definieert eveneens netwerk management strategieën.

• OSEK OS: Het besturingssysteem van OSEK dient als basis voor de gecontrolleerde real-time executie van concurrente applicaties en geeft ze een omgeving op de processor. De architectuur van het OSEK/VDX OS onderscheidt 3 procesniveau’s: interrupt niveau, logische niveau voor OS activiteiten en een task niveau. Bijkomend tot het managen van de procesniveau’s zijn er de services die het OS biedt: Task management, event management, resource management, counters, alarmen en error afhandeling. • OSEK COM: De communicatie specificatie verstrekt interfaces voor de overdracht van gegevens binnen de ECU’s. Deze communicatie vindt plaats tussen en in nodes(ecu’s). In figuur 2.1 kan men de plaats van de COM laag zien binnen OSEK. Het toont de interface met 3

HOOFDSTUK 2. REAL-TIME BESTURINGSSYSTEEM

4

de toepassing, netwerkbeheer en de hardware communicatie bus. De specificatie bepaalt een interactielaag en stelt vereisten aan de onderliggende netwerklaag en/of datalinklaag. De interactielaag biedt eveneens de API aan van OSEK/VDX COM voor de overdracht van berichten binnen en tussen nodes. Voor netwerk communicatie, gebruikt de interactielaag de diensten die door de lagere lagen worden aangeboden. Interne communicatie wordt afgehandeld door de interactielaag zelf.

ot eHo

ge s

ch o

ol

• OSEK NM: Netwerken hebben nood aan beheer om de betrouwbaarheid en de veiligheid van een gedistribueerd systeem te waarborgen. OSEK/VDX NM geeft steun voor verscheidene van dergelijke beheerstaken. Het basisconcept OSEK/VDX NM controleert netwerk nodes. Twee alternatieven controlemechanismen worden geboden: directe en indirecte node controle. De directe controle wordt uitgevoerd door een specifieke mededeling te sturen. Het directe toezicht op de nodes kan soms onmogelijk of ongewenst zijn. Het mechanisme van indirecte controle is daarom beschikbaar. Het is gebaseerd op het gebruik van gecontroleerde applicatieberichten. Deze indirecte controle is beperkt tot nodes die berichten verzenden tijdens hun normale operatie.

Gr

• OSEKtime OS: Het OSEKtime besturingssysteem biedt services aan voor het uitvoeren van fout-tolerante, hoog betrouwbare real-time applicaties. Er is ook een beschrijving van de Time Service specificatie. Dankzij deze specificatie is het mogelijk om taken te synchroniseren met een globale tijdsbasis. Omdat deze tijdsbasis verbonden is met het netwerk wordt de FT-COM laag gebruikt in het OSEKtime OS.

OSEK OS

20

2.2

11

Ka re

ld

e

• OSEK FTCOM: FTCom (Fault-tolerant) is verdeeld in volgende lagen: De toepassingslaag, filter, fout-tolerantie en de interactielaag. De toepassingslaag verstrekt de API. De filter voorziet mechanismen voor het filteren van berichten. De fout-tolerantielaag levert services om fout-tolerante functies te ondersteunen (algoritmen die bepalen met behulp van redundante berichten of de waarde van een pakket geldig is). De interactielaag zorgt voor de overdracht van berichten via het netwerk.

py rig

ht

Het OSEK-OS is een besturingssysteem ontworpen voor “single-processor” gedistribueerde controle systemen. Het ondersteunt tijdskritische applicaties op een breed gamma van hardware platformen. Door een zeer modulaire architectuur is het mogelijk om dit OS op zowel de low-end microprocessoren (zelfs de 8-bit microcontrollers) als op de zeer complexe ECU’s te gebruiken. We sommen enkele belangrijke eigenschappen van het OS op.

Co

• Gestandaardiseerde interfaces: De interface tussen de applicatie software en het OS is gegeven dankzij de system services. Deze zijn dezelfde voor alle implementaties van het OSEK-OS. • Schaalbaarheid: Er zijn verschillende “conformance classes”, scheduling policies en configuratie opties waardoor het OS heel schaalbaar is. • Error checking: 2 niveaus voor error checking. Een uitgebreide status voor de ontwikkelingsfase en een standaard status voor de productiefase. • Portabiliteit van applicaties: OSEK beoogt de portabiliteit van applicatie software. Door gebruik te maken van de sytem-services van OSEK wordt het zeer makkelijk om software uit te wisselen tussen verschillende implementaties. Deze portabiliteit is enkel ondersteund op

NCC-2011-001

KdG–IWT

Automotive Software


5

broncode niveau. Object code kan niet worden uitgewisseld. OSEK definieert hiervoor de OILtaal (OSEK implementation language). Deze taal beschrijft alle OSEK- specifieke objecten als taken, alarmen, … • Automotive requirements: OSEK is speciaal ontworpen voor de automotive sector. Hierdoor voldoet het aan enkele andere eigenschappen:

ol

– Statische configuratie

ch o

– Uitvoerbaar vanuit ROM

– Voorspelbaar en gedocumenteerd gedrag dat voldoet aan automotive real-time eisen.

Proces niveaus

ot eHo

2.2.1

ge s

– …

OSEK heeft 3 proces niveaus: • Interrupt niveau

Gr

• Logisch niveau voor de scheduler

e

• Taak niveau

Ka re

ld

De prioriteit van elk niveau wordt duidelijk door Figuur ??: Proces niveaus van het OSEK OS. Binnen het taak niveau worden de taken gescheduled naar gelang hun prioriteit. De prioriteit van een taak is statisch toegewezen door de ontwikkelaar. Binnen het interrupt niveau zijn er ook verschillende prioriteiten.

Co

py rig

ht

20

11

Figuur 2.2: Niveaus binnen het OSEK OS

2.2.2

Conformance klassen

Verschillende eisen van de applicatiesoftware zorgen voor verschillende eisen die gesteld worden aan het OS. Deze verschillende eisen zijn gegroepeerd in conformance klassen. Volgende klassen bestaan: NCC-2011-001

KdG–IWT

Automotive Software


6

• BCC1: enkel basis taken, 1 activatie-aanvraag per taak en slechts 1 taak per prioriteitsniveau • BCC2: zelfde als BCC1 met meerdere taken per prioriteit en meerdere activatie-aanvragen. • ECC1: BCC1 met uitgebreide taken

Taken

ch o

2.2.3

ol

• ECC2: zelfde als ECC1 met meerdere taken per prioriteit en meerdere activatie-aanvragen.

ge s

Zoals reeds aangehaald bij de conformance klassen zijn er 2 types van taken.

ot eHo

2.2.3.1 Basis taken

Gr

Basis taken geven de processor enkel vrij als de taak is afgelopen, het OS switched naar een taak met een hogere prioriteit of er een interrupt is waardoor de processor de service routine van de interrupt verwerkt. Dit geeft ons volgend model voor de basis taken. Een taak is steeds in één van de volgende states: • Running: De CPU voert deze taak uit. Slechts 1 taak kan in deze status zijn.

ld

e

• Ready: Alle vereisten zijn voldaan voor het uitvoeren van deze taak. De scheduler bepaald waneer een transitie naar de running status mogelijk is.

Ka re

• Suspended: De taak is passief en kan mogelijks worden geactiveerd naar de ready state.

20

11

In Figuur ??: Model van een basis taak kan men het model terugvinden. Hierop ziet men de transities en wanneer ze kunnen voorkomen. Terminatie van een taak is enkel mogelijk door de taak zelf. Ze zijn als het ware “self-terminating”. Deze beperking verminderd de complexiteit van het OSEK-OS.

Co

py rig

ht

Figuur 2.3: Model van een basis taak

Running

Terminate: de running taak zorgt zelf voor de transitie naar de suspended status wanneer de taak afgelopen is

Preempt: de scheduler beslist om een andere taak te starten. De huidige running taak wordt in de ready status geplaatst

Start: een ready taak is geselecteerd door de scheduler om te worden uitgevoerd.

ready

suspended

Activate: een nieuwe taak wordt in de ready state geplaatst. OSEK zorgt ervoor dat de executie start bij de eerste instructie

NCC-2011-001

KdG–IWT

Automotive Software


7

2.2.3.2 Uitgebreide taken Het grote verschil tussen een basis taak en een uitgebreide taak is een nieuwe status waarin de taak zich kan bevinden. Een taak in de waiting state kan niet verder uitvoeren omdat ze moet wachten op minstens één event.

ch o

Running

suspended

ot eHo

Preempt: de scheduler beslist om een andere taak te starten. De huidige running taak wordt in de ready status geplaatst

Start: een ready taak is geselecteerd door de scheduler om te worden uitgevoerd.

Waiting

Terminate: de running taak zorgt zelf voor de transitie naar de suspended status wanneer de taak afgelopen is

ge s

Wait: transitie wordt veroorzaakt door een sytem service. Om de operatie te hernemen is er een event nodig

ol

Figuur 2.4: Model van een uitgebreide taak

ready

Activate: een nieuwe taak wordt in de ready state geplaatst. OSEK zorgt ervoor dat de executie start bij de eerste instructie

Realease: Minstens 1 event is voorgevallen waarop de taak aan het wachten was

Gr

ld

e

2.2.3.3 Activeren van een taak

Scheduling

11

2.2.4

Ka re

Het OSEK-OS laat niet toe om parameters mee te geven bij het activeren van een taak. Wanneer men dit toch wenst te doen moet men gebruik maken van OSEK-COM of van globale variablen.

py rig

ht

20

In tegenstelling tot het conventioneel sequentieel programmeren van een ECU zorgt het multi-tasking principe ervoor dat meerdere taken concurrent kunnen worden uitgevoerd. Het mechanisme dat hiervoor verantwoordelijk is, noemt men de scheduler. De scheduler bepaalt wanneer een bepaalde taak zal starten en triggered eveneens de noodzakelijk interne OS activiteiten. De scheduler beslist om met een bepaalde taak te stoppen en een andere te hernemen. Dit noemen we een context switch. Dit impliceert dat elke taak zijn eigen context heeft (stack). Bij een context switch zal het OS de stackpointer, program counter en andere noodzakelijke registers opslaan en deze van de nieuwe taak inladen. Het aantal registers die moeten worden opgeslagen is afhankelijk van de processor.

Co

De scheduler beslist aan de hand van prioriteiten welke (ready) taak hij eerst moet starten. Taken hebben hiervoor een statische prioriteit. De laagste prioriteit is 0, hoe hoger het nummer, hoe hoger de prioriteit van de taak. Deze prioriteiten zijn statisch toegewezen aan de taken. Enkel in BCC2 en ECC2 kunnen taken met dezelfde prioriteit voorkomen. Wanneer meerdere taken met dezelfde prioriteit in de ready state zijn, is het de orde van activatie die bepaalt welke taak eerst wordt uitgevoerd. Wanneer geen enkele taak zich in de ready state bevindt zal er een idle-mechanisme worden uitgevoerd.

NCC-2011-001

KdG–IWT

Automotive Software


8

2.2.4.1 Scheduling policy

ch o

ol

• Full preemptive scheduling: Dit wil zeggen dat een taak op elk moment tijdens z’n uitvoering mag worden geswitched. De scheduler zal een running taak in de ready state zetten wanneer er een taak met hogere prioriteit ready is geworden. Met moet er rekening meehouden dat elke taak onderbroken kan worden op elk punt, waardoor synchronisatie met gedeelde data zeer nauwgezet moet worden nagekeken. Een task switch komt dus voor als een taak eindigt, bij de activatie van een taak, een transitie naar de wait-state, bij het voorkomen van een event, bij het vrijmaken van een resource of bij de terugkeer van het interrupt niveau naar het taak niveau. Een voorbeeld van dit kan je terugvinden in figuur 2.5.

ge s

Figuur 2.5: Full Preeptive scheduling voorbeeld

T1 terminated

Suspended

running

T2

running

ready

suspended running

Gr

T1

ot eHo

Activatie T1

e

Prioriteit: 0 <= T2 < T1

ld

Ka re

• Non preemptive scheduling: Hierbij gebeurt de taak switch enkel op voorgedefinieerde punten. Dit is bij de terminatie van een taak, transities naar de waiting state of het expliciet aanroepen van de schedule system call. In figuur 2.6 zie je een voorbeeld van dit.

11

Figuur 2.6: Non-preemptive scheduling voorbeeld

Suspended

py rig

ht

T1

20

Activatie T1

T2

T2 terminated

ready

running

running suspended

Co

Prioriteit: 0 <= T2 < T1

• Groups of tasks: Aspecten van preemptive en non-preemptive scheduling kunnen gecombineerd worden door groepen van taken te definiëren. Voor taken die dezelfde of een lagere prioriteit hebben dan de hoogste prioriteit in de groep zal de groep zich gedragen als non-preemptive. Bij taken met een hogere prioriteit gedraagt de groep zich als preemptive. • Mixed preemptive scheduling Wanneer preemptive en non-preemptive taken gemixte zijn noemen we dit een mixed preemptive scheduling. Wanneer de huidige taak non-preemptive is, gedraagt de scheduler zich als non-preemptive. Wanneer de huidige taak preemptive is, gedraagt de scheduler zich eveneens als preemptive. Dit heeft het voordeel wanneer er op de NCC-2011-001

KdG–IWT

Automotive Software


9

ECU enkele taken bevinden met lange executie tijd en veel korte taken. De korte taken zijn niet preemptive omdat de overhead te groot zou zijn. Terwijl de lange taken de CPU niet kunnen monopoliseren.

Interrupt processing

ol

2.2.5

ge s

ch o

Interrupts kunnen worden ingedeeld in 2 categorieën. De eerste categorie (ISR category 1) zijn de interrupts die geen gebruik maken system services tijdens hun uitvoering. Wanneer de interrupt afgehandeld is, herneemt de CPU de taak die aan het uitvoeren was. Dit type van ISR heeft dus geen enkele invloed op het taak management.

2.2.6

ot eHo

Het andere type (ISR category 2) gebruikt wel system services tijdens z’n uitvoering. Binnenin de ISR gebeurt er geen reschedule. Dit kan enkel gebeuren als de interrupt is afgehandeld, er geen nieuwe interrupt actief is en de huidige taak preemptive is.

Events

Ka re

ld

e

Gr

Events worden gebruikt voor synchronisatie doeleinden. Ze kunnen enkel gebruikt worden bij uitgebreide taken en dienen voor de transities van en naar de waiting state. Events zijn objecten die gemanaged worden door het operating systeem. Elke (uitgebreide) taak heeft een aantal events. We kunnen een event best voorstellen als een booleaans getal. Bij activatie van een taak worden alle events van deze taak op false gezet. We bedoelen hiermee dat het event nog niet voorgevallen is. De betekenis van een event is applicatie-afhankelijk en kan bijvoorbeeld het aflopen van een timer zijn of het ontvangen van data, …

Co

py rig

ht

20

11

Enkel de eigenaar van het event kan de waarde terug op false zetten om zo de transitie naar de wait state te maken en te wachten op het event. Elke taak en ISR category 2 kan het event zetten (de waarde = waar). Hiermee informeert ze de wachtende taak dat hij moet stoppen met wachten. Indien een taak in de running state is en wil wachten op event dat reeds gezet is, blijft de taak gewoon in de running state.

NCC-2011-001

KdG–IWT

Automotive Software


10

Intermezzo I: Deadlocks en Livelocks

2.2.7

Ka re

ld

e

Gr

ot eHo

ge s

ch o

ol

Deadlocks komen voor wanneer 2 taken aan het wachten zijn op het vrijgeven van een specifieke resource door de andere taak. Beschouw het volgende probleem: The Dining philosophers problem : Er zitten vijf filosofen samen rond een ronde tafel spaghetti te eten. Op elk moment tijdens hun lunch zijn ze bezig met slechts 2 dingen: denken of eten. Terwijl een filosoof aan het eten is, kan hij niet denken. En terwijl hij aan het denken is, kan hij niet eten. Vóór elk van deze filosofen staat er een bord met spaghetti. Tussen elk bord ligt er een vork. Dus op hun tafel staan er 5 borden en liggen er 5 vorken. Bij gevolg heeft elke filosoof een vork langs zijn rechtse kant en één langs zijn linkse kant. Dit zijn de enige 2 vorken waar een filosoof gebruik kan van maken om te eten. Het is moeilijk om spaghetti te eten met slechts 1 vork, daarom moet een filosoof 2 vorken hebben om te kunnen eten. Omdat de filosofen nooit met elkaar praten is dit een zeer gevaarlijke situatie. Stel dat alle filosofen gelijk beginnen te eten. Ze nemen allen de vork aan de rechtse kant. Hierdoor moeten ze wachten op een linkse vork wat een deadlock veroorzaakt. Een ander probleem kan optreden als we dit probleem willen oplossen. De filosofen zijn slimmer geworden. Ze hebben afgesproken dat na 5 minuten wachten op een vork, ze de andere vork moet terugleggen en daarna nog eens 5 minuten moet wachten voor hij terug een vork probeert vast te nemen. Hierdoor kan er geen deadlock meer voorkomen aangezien ze steeds kunnen terugkeren naar een andere status. Maar als ze opnieuw op dezelfde moment beginnen met het vastnemen van de eerste vork krijgen we een livelock. Bijvoorbeeld, ze nemen allemaal de rechtse vork. Ze wachten 5 minuten en leggen allemaal hun vork terug neer. Opnieuw wachten ze allemaal 5 minuten om terug één vork vast te nemen…

Resources

20

11

Resource management regelt het concurrent raadplegen van gedeelde resources door verschillende taken. Voorbeelden van resources zijn geheugen, hardware delen, … Implementatie van dit resource management systeem is verplicht voor alle conformance klassen.

Co

py rig

ht

Het resource management zorgt ervoor dat geen 2 taken samen een resource raadplegen . Het zorgt er eveneens voor dat priority inversion en deadlocks niet kunnen voorkomen. Elke resource is beschermd door een object dat we een binaire semafoor of mutex noemen. Wanneer een taak de resource wenst raad te plegen, vraagt hij deze aan. Dit gebeurt door middel van de system call GetResource(ID). Indien niemand anders op dat ogenblik eigenaar is van de resource, wordt de taak de eigenaar. De taak kan de resource gebruiken. Als de taak de resource niet meer nodig heeft, geeft hij deze vrij door middel van ReleaseResource(). Wanneer een taak een resource aanvraagt die op dat ogenblik bezit is van een andere taak, krijgt hij de resource niet. Het resource management systeem kan worden uitgebreid naar het interrupt niveau zodat slechts 2 taken of interrupt routines niet dezelfde resource kunnen raadplegen. Een taak kan zichzelf beschermen tegen interrupts door ze tijdelijk uit te schakelen. Dit doet men door middel van de system call DisableAllInterrupts(). Deze mechanismen zijn zeer belangrijk in de context van preemptable taken, gedeelde resources tussen taken, taken en interrupts en interrupts onderling. Indien nodig kan een taak zichzelf beschermen tegen preemption door een andere taak. Hiervoor is er een speciale resource die automatisch wordt aangemaakt (RESSCHEDULER). Interrupts kunnen NCC-2011-001

KdG–IWT

Automotive Software


11

nog wel voorkomen indien een taak deze resource bezit. Er zal achteraf geen reschedule plaatsvinden. Intermezzo II: priority inversion

Activate T1, T2, T3, Preemt T4 suspendend

runnning

T2

suspended

ready

T3

suspended

T4

running

S1 vrijgegeven door T4, reschedule

ot eHo

T1

Aanvraag tot S1

ge s

ch o

ol

Priority inversion is het fenomeen dat een taak met lagere prioriteit, de executie van een taak met hogere prioriteit uitstelt. Neem volgende situatie: Taak 4 met een lage prioriteit neemt een binaire semafoor op een bepaalde resource (S1). Taak 1 met een hogere prioriteit preempt taak 4 en moet eveneens deze resource raadplegen. Hij vraagt de semafoor S1 aan, aangezien deze reeds ingenomen is door Taak 4 zal taak 1 naar een waiting state gaan. Taak 1 kan enkel terug beginnen uitvoeren als alle taken met prioriteit tussen taak 1 en taak 4 zijn uitgevoerd en taak 4 de semafoor terug vrijgeeft. Hoewel T2 en T3 geen gebruik maken van semafoor S1, stellen ze de uitvoering van T1 wel uit.

waiting running

running

suspended

running

Gr

ready

running

ready

ld

e

ready

suspended

Prioriteit: 0<=T4

Ka re

S1 ingenomen

20

11

2.2.7.1 Priority ceiling mechanisme

ht

Om het probleem van deadlocks en priority inversion op te lossen heeft men het principe van priority ceiling toegepast.

py rig

Tijdens het genereren van het systeem krijgt elke resource zijn eigen “ceiling priority” statisch toegewezen. Deze moet gelijk of hoger zijn dan de hoogste prioriteit van alle taken die deze resource wensen te gebruiken. Maar ze moet lager zijn dan de laagste prioriteit van alle taken die de resource niet gebruiken en die toch een hogere prioriteit hebben dan de taken die de resource wel gebruiken.

Co

Voorbeeld: Resource 1 wordt gebruikt door • taak 3 met prioriteit 3 • taak 4 met prioriteit 4 • taak 6 met prioriteit 6 en niet door: • taak 1 met prioriteit 1 NCC-2011-001

KdG–IWT

Automotive Software


running

T1

Suspended

T2

Suspended

T3

Suspended

T4

Suspended

T5

Suspended run

running

ready

running

run

ready

Suspended running

ready

Suspended running

ready

ol

CP

running

Suspended

ch o

Suspended

running

run

ready

Suspend ed running

ot eHo

T1 en T5 mogen resource aanvragen Prioriteit: 0 <= T5 < T4 < T3 < T2 < T1 < T0 CP = ceiling priority: prio(T1) <= CP < prio(T0) Pijlen = request en release de resource

ge s

T0

12

Figuur 2.7: Voorbeeld van het PCP

Gr

• taak 2 met prioriteit 2

e


ld


Ka re


11

De ceiling priority van resource 1 moet bijgevolg 6 zijn. Want 6 is groter of gelijk aan de hoogste prioriteit van de taken die gebruik maken van de resource. En 6 is kleiner dan de taken die een hogere prioriteit dan 6 hebben en de resource niet gebruiken.

ht

20

Wanneer een taak een resource gebruikt en de prioriteit van de taak is kleiner dan de ceiling priority, wordt de prioriteit van de taak verheven naar deze ceiling priority. Wanneer hij de resource vrijgeeft zal zijn prioriteit terugkeren naar de normale prioriteit. Dit kan resulteren in een tijdsvertraging voor andere taken. Deze tijdsvertraging is maximaal de tijd dat de resource kan worden vastgehouden.

Co

py rig

In Figuur 2.7 hebben we 6 taken. T1 en T5 mogen beide gebruik maken van de resource. Wanneer T5 de resource aanvraagt zal zijn prioriteit stijgen naar de ceiling priority (CP) van de resource. In dit geval is ligt deze tussen de prioriteit van T1 en T0. Wanneer T0 geactiveerd wordt, heeft deze nog steeds een hogere prioriteit dan de CP van de resource. Hierdoor zal taak T5 gepreempt worden door de taak T0. Na de uitvoer van T0 kan T5 zijn werk hernemen, hij heeft nu de hoogste prioriteit dankzij de CP. Wanneer de taak T5 de resource vrijgeeft, verlaagt z’n prioriteit terug naar de normale waarde. T1 tot T4 kunnen hun taak uitvoeren. Er is geen priority inversion opgetreden. Enkel een kleine delay voor de uitvoering van T1. Ook een deadlock kan niet voorkomen aangezien de taak niet kan worden gepreempt door een andere taak die de resource nodig heeft.

2.2.7.2 Priority ceiling met extensies voor interrupts Het priority ceiling mechanisme kan optioneel ook de interrupts bevatten. Hiervoor moet elke interrupt een virtuele prioriteit worden toegewezen. Deze virtuele prioriteiten moeten hoger zijn dan NCC-2011-001

KdG–IWT

Automotive Software


13

die van de taken. De ceiling priority van een resource moet nu hoger zijn dan alle taken en interrupts die gebruik maken van de resource. Maar ze moet lager zijn dan de laagste prioriteit van alle taken en interrupts die de resource niet gebruiken en die toch een hogere eprioriteit hebben dan de taken en interrupts die de resource wel gebruiken. De rest van het algoritme blijft hetzelfde. Een interrupt kan hierdoor wel enige vertraging oplopen.

ol

Counters en Alarmen

ch o

2.2.8

ot eHo

ge s

OSEK biedt enkele services voor het verwerken van periodiek terugkerende events, bijvoorbeeld een timer. Het OSEK-OS heeft een 2-stage concept voor het afhandelen van dergelijke events. De periodieke events (sources) zijn de implementatie specifieke counters. Alarm mechanismen geven de applicatie een alarm gebaseerd op deze counters.

2.2.8.1 Counters

e

Gr

Een counter heeft steeds een bepaalde waarde uitgedrukt in ‘ticks’. OSEK biedt geen services om rechtstreeks deze counters te manipuleren. OSEK-OS handelt alle noodzakelijke acties af wanneer de counter vooruitgaat of hoe de counter vooruitgaat. Er is minimaal 1 counter die rechtstreeks afgeleid is van een (hardware of software) timer.

ld

2.2.8.2 Alarm Management

20

11

Ka re

Een alarm gaat af wanneer de counter een vooraf gedefinieerde waarde bereikt. Deze waarde kan gedefinieerd worden in een relatieve waarde tegen over een huidige counter waarde (relatief alarm) of een absolute waarde (absoluut alarm). OSEK geeft services voor het activeren van taken, een event te zetten of het uitvoeren van een alarm call-back routine wanneer een alarm afgaat. Alarm call-back routines zijn kleine functies die gegeven worden door de applicatie. Ze hebben geen parameters en geen return waarde.

2.2.9

py rig

ht

Alarmen kunnen cyclisch of enkel zijn. Er zijn ook services om de status van een alarm na te gaan of om een alarm te annuleren. Meerdere alarmen kunnen aan een enkele counter verbonden zijn, maar een alarm heeft steeds maar één counter. Elk alarm is ook verbonden met slechts 1 taak of call-back routine.

Starten, stoppen en errors

Co

2.2.9.1 Hook rountines

OSEK heeft enkele systeemspecifieke hook routines om de gebruiker acties te laten uitvoeren tijdens het interne uitvoeren van OSEK. Deze hook routines hebben een hogere prioriteit dan alle taken en ISR categorie 2. Ze mogen slechts een kleine subset van de system services gebruiken.

2.2.9.2 Error handling Er zijn 2 soorten errors: NCC-2011-001

KdG–IWT

Automotive Software

14

ch o

Figuur 2.8: Opstart procedure van een OSEK gebaseerd systeem

ol


ot eHo

ge s

• Applicatie errors: Het OS kon de gevraagde service niet uitvoeren. Maar de interne data van het OS is nog intact. Gecentraliseerde error afhandeling wordt aangeroepen. Daarbovenop wordt er status informatie teruggegeven zodat er eveneens gedecentraliseerde afhandeling kan gebeuren. • Farale errors: Het OS kan niet langer aannemen dat de interne data nog correct is. Het systeem wordt afgesloten.

ld

e

Gr

De hook-routine (ErrorHook) wordt aangeroepen wanneer een return status verschillend is van E OK. Moest er binnen deze hook een fout optreden gebeurt dit niet. De gebruiker moet zelf de error afhandelen.

Ka re

2.2.9.3 Startup

11

De StartupHook dient voor het plaatsen van gebruikersspecifieke initialisatie-code. Daarna wordt de scheduler gestart en wordt de eerste applicaties uitgevoerd. Dit zijn de autostart taken en alarmen die gedefinieerd zijn tijdens het bouwen van het systeem.

20

2.2.9.4 Shutdown

py rig

ht

Het systeem wordt afgesloten met behulp van de ShutDownOS service. Deze kan aangeroepen worden door een applicatie en wordt aangeroepen bij een fatale fout. De ShutDownHook wordt aangeroepen bij het afsluiten.

2.2.9.5 Debugging

Co

PreTaskHook en PostTaskHook zijn de hooks die worden uitgevoerd bij context switchen. Deze kunnen gebruikt worden voor het debuggen of voor het meten van uitvoertijd van taken.

2.3

AUTOSAR

AUTOSAR (AUTomotive Open System Architecture) is een partnership van automotive bedrijven die samenwerken om een defacto-standaard wensen op te stellen voor automotive E/E-architectuur. Autosar bestaat uit verschillende componenten(zie figuur 2.9) NCC-2011-001

KdG–IWT

Automotive Software


15

• Software componenten: Laag boven de RTE. De interfaces verzorgen de connectiviteit tussen de RTE en de software modules. • RTE: Runtime Environment: communicatie centrum voor inter- en intra ECU communicatie. Abstractie van communicatie: biedt dezelfde services aan voor inter-en intra ECU communicatie.

– Communicatie: CAN, LIN, FlexRay, netwerkmanagement

ch o

– Services: System services als diagnostiek, geheugenbeheer, ...

ol

• Basic Software:

ge s

– Operating System: OSEK is gebruikt als basis voor het Autosar OS

11

Ka re

ld

e

Gr

ot eHo

– Microcontroller abstraction: Toegang naar de hardware. (PWM, ADC, Flash, ...)

20

Figuur 2.9: AUTOSAR overzicht

py rig

ht

Voor de cursus automotive datacommunicatie is de communicatie natuurlijk van het grootste belang. In figuur 2.10 kan men de paden van communicatie binnen een ECU bekijken.

Co

• Drivers: Dit zijn de drivers voor het verzenden en ontvangen van data op de verschillende netwerken. Er zijn drivers voor verschillende netwerken aanwezig. CAN, FlexRay en LIN behoren hiertoe. • Interface: Elk van de verschillende netwerken hebben een eigen interface. Deze beschrijven op welke wijze berichten kunnen verzonden worden op de netwerken. • TP: Dit zijn de verschillende transportlagen voor de automotive datacommunicatie protocollen. Ze bieden services als flow-controle, error controle, segmentatie en assemblage van berichten. De TP-laag geeft z’n berichten door aan de drivers via de interface. • PDU-router: De protocol Data Unit-router verzend berichten via de juiste interface. Het kan ook berichten doorgeven via de transportlaag. Een andere functie van de PDU-router is het routeren van externe berichten via een ander netwerk. NCC-2011-001

KdG–IWT

Automotive Software

16

py rig

ht

20

11

Ka re

ld

e

Gr

ot eHo

ge s

ch o

ol


Co

Figuur 2.10: AUTOSAR communicatie paden

NCC-2011-001

KdG–IWT

Automotive Software


17

• COM / signal-gateway: De COM-laag zorgt voor het transport van berichten. Ze zorgt eveneens voor filtering, endianess correctie, ... De signal gateway kan signalen uit een bericht uitpakken en als nieuw bericht verzenden naar een externe interface. • NM: Netwerk management

Co

py rig

ht

20

11

Ka re

ld

e

Gr

ot eHo

ge s

ch o

ol

• DCM: Diagnostic Communication Manager: De DCM krijgt diagnose berichten van de PDUrouter en verwerkt deze.

NCC-2011-001

KdG–IWT

Automotive Software

ch o

ol

Hoofdstuk 3

3.1

ot eHo

ge s

Automotive Datacommunicatie Inleiding

Gr

Voor de jaren ’70 waren er slechts enkele elektronische componenten in de wagen, zoals een radio. Door het invoeren van strenge normen op de uitstoot van uitlaatgassen, werd het onmogelijk om zonder elektronische hulpmiddelen nog dergelijke controle uit te voeren.

Ka re

ld

e

Hierna kreeg elektronica een steeds belangrijkere plaats binnen de automobiel. De 2e golf van vernieuwing kwam er in de jaren 80. Door de introductie van microcontrollers in de wagen, werd het mogelijk om vele andere toepassingen te ontwikkelen zoals ABS, klimaat controle, enz. Begin jaren ’90 werd de industrie gedreven door de eisen die de consumenten stelden op gebied van comfort. Ook werden de gebruikers zich steeds meer bewust van de veiligheidsaspecten.

Co

py rig

ht

20

11

Door de toename van deze intelligente eenheden was er ook noodzaak om communicatie te hebben tussen deze eenheden. Deze gebeurde via een kabelboom (bundel van bedrading). In sommige wagens zat zelfs tot 2000 meter draad met een gewicht van meer dan 100kg.

Figuur 3.1: voorbeeld van complexe bedrading binnen een wagen Dit was dan ook de reden waarom de automobielindustrie begon met haar zoektocht naar nieuwe, moderne communicatiemethodes.

18

HOOFDSTUK 3. AUTOMOTIVE DATACOMMUNICATIE

3.1.1

19

Het OSI-model

Gr

ot eHo

ge s

ch o

ol

Het OSI referentie model (Open Systems Interconnection) was een eerste stap in de richting van een internationale standaardisering van verschillende protocollen. Het heeft betrekking op systemen die open staan voor communicatie met andere systemen. Omdat dit uitvoerig behandeld is in de cursus datacommunicatie geven we hier slechts een zeer korte introductie.

e

Figuur 3.2: Het OSI model

Ka re

ld

Het OSI-model heeft 7 lagen en wordt voorgesteld in figuur 3.2. In de praktijk worden niet alle lagen van dit model gebruikt. Er zijn ook steeds verschillen van protocol tot protocol.

3.1.1.1 De Fysische laag

py rig

ht

20

11

De fysieke laag (physical layer) is de eerste laag uit het OSI model. Deze bevat de elektrische, mechanische, procedurele en functionele specificaties voor het activeren, in stand houden en deactiveren van de fysieke link tussen eindstations. De fysieke laag beschrijft alle elektrische en fysische specificaties voor de onderdelen. In deze laag worden karakteristieken als voltagelevels, kabelspecificaties connectoren (stekkers) penlayout, en maximale transmissieafstand gedefinieerd.

3.1.1.2 De Datalinklaag

Co

De datalinklaag is de tweede laag uit het OSI model en zorgt voor een betrouwbaar transport van de data over een verbinding (link). Men moet bij-voorbeeld denken aan de verbinding tussen een netwerkkaart in een computer en een router, en dan niet de kabel zelf (deze is ingedeeld in de fysieke laag), maar de signalen die over deze kabel heengaan. Adressering gebeurt op basis van het door de fabrikant ingegeven MAC-adres door een switch. De data die wordt doorgegeven via de fysieke laag kan veel fouten bevatten. Storingen van buitenaf zorgen er vaak voor dat bits verdwijnen, bijkomen of omvallen. Alle data wordt opgedeeld in pakketjes. Deze pakketjes worden frames genoemd. Per frame wordt met een aantal foutcontroles, zoals bijvoorbeeld een Cyclic Redundancy Check, bepaald of het frame correct is ontvangen. De frames zijn genummerd, waardoor de volgorde van de frames altijd achteraf gereconstrueerd kan worden. Als een frame niet goed wordt ontvangen, wordt het herhaald verstuurd, totdat het wel goed ontvangen wordt. Op deze manier is het mogelijk om data

NCC-2011-001

KdG–IWT

Automotive Software


20

betrouwbaar over te sturen op een datalijn met ruis, hoewel dit wel nadelige gevolgen heeft voor de snelheid. Een voorbeeld van een datalinklaag is Ethernet.

3.1.1.3 De Netwerklaag

ot eHo

ge s

ch o

ol

De netwerklaag is de derde laag gedefinieerd in het OSI-model, liggend tussen de datalinklaag en de transportlaag. De netwerklaag is in het model verantwoordelijk voor het overbruggen van de afstand tussen deze omliggende lagen: voor het vertalen van een conceptueel ”gesprek”(een sessie) tussen begin- en eindpunt in een netwerk in een verzameling paketten die door de verschillende verbindingen in het netwerk (de datalinks) geleid kunnen worden. De netwerklaag is daartoe verantwoordelijk voor het verdelen van een datastroom binnen een sessie (een onderdeel in het gesprek) in verschillende blokken (pakketten). Daarnaast is de netwerklaag ook verantwoordelijk voor het routeren van de pakketten door het netwerk. De beslissing over de achtereenvolgende rij computers die een pakket zullen ontvangen en doorgeven, wordt in de netwerklaag genomen. Dit moet niet verward worden met de verantwoordelijkheid van de datalinklaag, die gaat over de vraag of een pakket goed (correct, volledig, zonder fouten) is verzonden tussen twee direct verbonden computers.

Gr

3.1.1.4 De Transportlaag

Ka re

ld

e

De transportlaag is de vierde laag uit het OSI-model, en zorgt voor het probleemloze transport van data voor de applicaties tussen eindgebruikers. De transportlaag controleert de betrouwbaarheid van een verbinding door segmentatie en desegmentatie en errorcontrole. De meest gebruikte protocollen uit deze laag zijn het Transmission Control Protocol ( TCP ) en het User Datagram Protocol ( UDP ). Data-eenheden uit deze laag worden meestal segmenten (of datagrammen in het geval van UDP) genoemd.

11

3.1.1.5 De Sessielaag

py rig

ht

20

De sessielaag stabiliseert, onderhoudt en beëindigt een sessie tussen twee communicerende hosts. Deze laag synchroniseert ook de dialoog die plaatsvindt op de presentatie laag tussen twee hosts, en onderhoudt de data-uitwisseling. Een webserver bijvoorbeeld wordt door meerdere computers tegelijkertijd benaderd, dus kunnen er veel communicatie-kanalen tegelijkertijd open staan. Het is dan ook belangrijk om bij te houden welke gebruiker op welk kanaal zit. De sessielaag zorgt voor efficiënte communicatie. Problemen op de toepassingslaag en de presentatielaag worden gemeld.

Co

3.1.1.6 De Presentatielaag De presentatielaag, de zesde laag in het OSI-model bepaalt het formaat dat moet worden toegepast om data uit te wisselen. Deze laag is in feite de vertaler van het netwerk. Bij de zendende computer vertaalt deze laag de data die door de toepassingslaag wordt aangeboden in een gemeenschappelijk erkend tussenformaat. Bij de ontvangende computer vertaalt de presentatielaag het tussenformaat in een formaat dat door de toepassingslaag van die computer wordt ondersteund. De presentatielaag is ook verantwoordelijk voor protocol-conversie, het vertalen van data, ter beveiliging coderen van data, het wijzigen of converteren van de tekenset en het uitbreiden van grafische commando’s. Hij verzorgt tevens de compressie van data, waardoor het aantal te verzenden bits kan worden teruggebracht.

NCC-2011-001

KdG–IWT

Automotive Software


21

Voorbeelden zijn het serieel omzetten van berichten gebruik makend van XML and MIME-codering. Bij een ingetikte tekst wordt deze omgezet naar een mailformaat.

3.1.1.7 De Applicatielaag

Classificatie van protocollen

ot eHo

3.1.2

ge s

ch o

ol

De applicatie of toepassingslaag is de zevende laag van het OSI model Deze laag communiceert direct met de applicatie en geeft opdrachten aan de presentatielaag, de zesde laag van het OSI-model. De toepassingslaag staat het dichtst bij de gebruiker. E-mail, FTP (File transfer) e.d. communiceren op deze laag. De toepassingslaag onderscheidt zich van de andere lagen doordat deze geen services biedt naar de andere OSI-lagen, maar alleen naar de applicatie buiten het OSI-model.

3.1.2.1 Classificatie naar eigenschappen

Gr

We kunnen de verschillende protocollen makkelijk indelen volgens bepaalde eigenschappen. We geven hier enkele voorbeelden van eigenschappen.

e

• Snelheid

ld

Een belangrijke eigenschap van netwerken is hun snelheid waarmee ze de data kunnen overbrengen. Dit wordt uitgedrukt in kbit of Mbit/s

Ka re

• Toepassing

Co

py rig

ht

20

11

We kunnen onze netwerken ook indelen naar de toepassing. Zo kan er een backbone netwerk zijn die verschillende andere types van netwerken verbindt. Zoals voor powertrain, telematica, body/comfort en chasis. Figuur 3.3 laat een dergelijke architectuur zien.

Figuur 3.3: Toepassingen van netwerken in de auto

NCC-2011-001

KdG–IWT

Automotive Software


22

• Determinisme vs. Niet-determinisme

ot eHo

ge s

ch o

ol

Indien we perfect weten wanneer onze data op het netwerk zal verzonden worden noemen we ons protocol deterministisch. De tijdvertraging is constant. Zie figuur 3.4.

Figuur 3.4: vergelijking tijdvertraging tussen deterministische en niet-deter-ministische protocollen • Kost

Gr

In de automotive industrie is kost een belangrijke factor bij het bepalen van de componenten. Dit geldt dus ook voor de netwerk componenten binnen de wagen.

e

• ...

3.1.2.2

Ka re

ld

We kunnen nog tal van eigenschappen opnoemen waarin we onze netwerken kunnen indelen. Officiële classificatie SAE

11

De Amerikaans Society for Automotive Engineers heeft een standaard classificatie ontwikkeld waarin we de protocollen kunnen indelen. Deze noemen we de SAE klasse. Er zijn 3 basiscategoriën te onderscheiden:

20

• SAE Class A

py rig

ht

De eerste klasse is de zogenaamde sensor en actuator netwerken. Ze heeft zeer lage datasnelheden (tot 10 kbit/s). Dit is een zeer goedkope oplossing aangezien de meeste klasse A protocollen enkel gebruik maken van een UART. Buiten zeer veel merkgebonden protocollen behoren LIN en TTP/A tot dit type. • SAE Class B

Co

Dit zijn de netwerken met een datarate tussen de 10 en 125 kbit/s. Deze netwerken worden gebruikt voor generale dataoverdracht zoals snelheid, emissie data, ... Low-speed CAN is de meest bekende implementatie van een klasse B netwerk. • SAE Class C De laatste klasse zijn de snelle netwerken vanaf 125 kbit/s. Deze worden gebruikt voor realtime controle. Denk maar aan powertrain controle, vehicle dynamics, X-by-Wire. Protocollen als high-speed CAN, FlexRay en TTP/C behoren hiertoe. Door nieuwe evoluties binnen de sector zijn de 3 officiële basisklassen aan te vullen met een andere:

NCC-2011-001

KdG–IWT

Automotive Software


23

• Multimedia netwerken Deze klasse bevat protocollen met een zeer hoge bandbreedte. Ze hebben geen nood aan de real-time karakteristieken van de klasse C netwerken. MOST is het meest gebruikte multimedia protocol.

ol

Overzicht

11

Ka re

ld

e

Gr

ot eHo

ge s

ch o

3.1.3

3.2.1

Theoretische Aspecten

py rig

3.2

ht

20

Figuur 3.5: Overzicht van automotive protocollen

Terminologie

Co

3.2.1.1 ECU

Een ECU of Electronic Control Unit bestaat meestal uit 3 grote delen. In figuur 3.6 kan je een voorbeeld van een ECU bekijken. De host controleert en initialiseert de communicatie-controller. Ze biedt eveneens de data aan die moet worden verzonden over het netwerk. De communicatie-controller implementeert het gebruikte communicatieprotocol. Bij een CAN node vind je een CAN-controller. Bij veel automotive Systems on Chip (SoC) is de communicatie-controller mee ingepakt op de chip. Indien we toch een externe controller gebruiken, sluiten we deze meestal NCC-2011-001

KdG–IWT

Automotive Software

24

ot eHo

ge s

ch o

ol


Gr

Figuur 3.6: Voorbeeld van een ECU

e

aan via SPI of een andere externe bus. De communicatie-controller geeft status informatie en de ontvangen payload data terug aan de host.

Ka re

ld

De transceiver krijgt de te verzenden data van de communicatie-controller en vertaalt de logische spanningsniveaus naar de vereisten van de fysische laag.

3.2.1.2 Cluster

20

11

Onder cluster verstaan we het netwerk van ECU’s. Clusters kunnen aan elkaar worden gehangen tot een groot netwerk waarin gateway’s de verschillende datapakketten vertalen van het ene protocol naar het andere.

py rig

ht

3.2.1.3 Berichten en signalen

3.2.2

Co

De verschillende ECU’s sturen berichten door op het netwerk. Deze berichten (payload data) kunnen uit verschillende signalen bestaan. Een signaal is de kleinste logische eenheid dat op een netwerk verzonden wordt. Voorbeelden van signalen zijn de snelheid van het voertuig, de versnelling, de aan-of uitstand van de lichten en pinkers,...

De fysische laag

3.2.2.1 Bekabeling In deze sectie bekijken we vluchtig welke kabels er vaak worden gebruikt in de automotive context. Voor een diepgaandere studie verwijzen we naar het vak Elektromagnetische transmissie, waar eveneens de uitleg over afsluitweerstanden en dergelijke besproken worden.

NCC-2011-001

KdG–IWT

Automotive Software


25

Single wire - Earth Return De meest simpele bekabeling bestaat uit een enkele draad. De referentie bestaat uit een gezamenlijke massa. Dit type van kabel is zeer gevoelig aan elektromagnetische interferentie (EMI), en kan dus slechts op korte afstanden gebruikt worden met een lage snelheid. Voordelen:

ol

• Goedkoop

ch o

• Slechts 1 kabel • Weinig gewicht

ge s

Nadelen:

ot eHo

• Kleine afstanden • Lage bandbreedte • Hoge gevoeligheid aan storingen

ld

e

Gr

Twisted Pair Twisted pair gebruikt 2 geisoleerde draden die spiraalsgewijs rond elkaar gedraait zijn, met de bedoeling de elektromagnetische interferentie te verlagen. Op de kabels wordt een differentieel signaal gezet. Dit wil zeggen dat er op de beide kabels een tegengesteld signaal wordt geplaatst. Dit type van kabel wordt het meeste gebruikt.

Ka re

Voordelen: • Goede storingsgevoeligheid

11

• Lage kostprijs

20

Nadelen:

ht

• Relatief beperkte afstand

py rig

Plastic Optical Fiber Plastic Optical fibre maakt gebruikt van licht dat in de fibre gekoppeld wordt. Door interne reflectie propageert het signaal door de optische vezel.

Co

Voordelen:

• Zeer goede storingsgevoeligheid • Licht

• Zeer grote bandbreedte Nadelen: • Duur • Moeilijk aan elkaar te koppelen NCC-2011-001

KdG–IWT

Automotive Software


26

3.2.2.2 Topologie

ot eHo

Figuur 3.7: Point-to-point topologie

ge s

ch o

ol

Point-to-point connectie De eenvoudigste topologie bestaat uit een point-to-point verbinding tussen 2 ECU’s. Het kan worden beschouwd als de meest simpele bus.

11

Ka re

ld

e

Gr

Bus Topologie Een structuur zonder ringen en zonder actieve elementen wordt een passieve lineaire bus genoemd. Praktische beperkingen van de bus hangen af van het kabeltype en de afsluitingen.

ht

20

Figuur 3.8: Voorbeeld van een bus topologie

py rig

Ster Topologie Een sterstructuur ontstaat wanneer verschillende node’s door middel van een sterkoppelaar verbonden zijn. De ster zal in tegenstelling tot een kanaal actief deelnemen aan het transport van data op de kanalen. Hij zal signalen van een node doorsturen naar alle ander node’s. Hierdoor wordt dit ook wel eens een actieve sterstructuur genoemd.

Co

We kunnen ook een passieve ster vormen. Er is geen actief element binnen dit netwerk. Alle ECU’s worden op 1 punt met elkaar verbonden.

Hybride Topologie Het is soms ook mogelijk om combinaties te maken van bus- en sterstructuren. Deze soort topologie noemt men de hybride topologie. Men kan op deze manier oneindig veel combinaties vormen. Het voordeel van de hybrideschakeling is dat men op deze manier de voordelen van zowel de bus- als de sterstructuur kan gebruiken.

Ring Topologie vormt. NCC-2011-001

Hier verbindt elke ECU exact 2 andere ECU’s, zodanig dat dit een circulair pad

KdG–IWT

Automotive Software

27

ot eHo

ge s

ch o

ol


20

11

Ka re

ld

e

Gr

Figuur 3.9: Voorbeeld van een actieve ster

Co

py rig

ht

Figuur 3.10: Voorbeeld van een passieve ster

Figuur 3.11: Voorbeeld van een hybride topologie NCC-2011-001

KdG–IWT

Automotive Software

28

ot eHo

ge s

ch o

ol


Figuur 3.12: Voorbeeld van een ring topologie

Gr

3.2.2.3 Lijn codes

Ka re

ld

e

Bij digitaal gegevenstransport wordt gebruikgemaakt van lijncodering. Lijncodering is het representeren van een te transporteren digitaal signaal door een amplitude- en tijd-discreet signaal, dat optimaal is toegesneden op de specifieke eigenschappen van het fysieke kanaal (en van de ontvangstapparatuur). Na lijncodering kan het signaal direct in de vorm van spanningsvariaties door transmissie-apparatuur op een transmissielijn worden gezet.

Co

py rig

ht

20

11

NRZ NRZ of non return to zero is een binaire lijncodering waar de logische 1 gerepresenteerd wordt door een bepaalde spanning en de logische 0 door een andere spanning. Het signaal is niet zelf-synchroniseerbaar.

Figuur 3.13: NRZ-codering

RZ Return-to-zero (RZ) beschrijft een lijn code waarbij het signaal terugkeerd naar nul bij elke halve puls. Dit gebeurt ook wanneer er een aantal dezelfde bits achterelkaar worden gestuurd. Hierdoor is het signaal zelf-synchroniseerbaar. Maar we hebben het dubbele van de bandbreedte nodig als we de codering vergelijken met NRZ.

NCC-2011-001

KdG–IWT

Automotive Software

29

ch o

ol


ge s

Figuur 3.14: RZ-lijncodering

Ka re

ld

e

Gr

ot eHo

Manchester Encoding Manchester code (ook gekend als fase encodering) is een lijn code waarbij elke databit minstens 1 transitie heeft. Het is daarom ook zelf-synchroniseerbaar.

Figuur 3.15: Manchester-lijncodering

20

11

De regels:

• Elke bit wordt met een gelijke periode verzonden

py rig

ht

• Een 0 wordt voorgesteld door een transistie van laag naar hoog, de transitie van hoog naar laag stelt een logische 1 voor • Deze transities gelden enkel in het midden van de bitperiode

Co

• De eventuele transitie bij het begin van het signaal is overhead.

3.2.2.4 Evaluatiemethodes voor automotive netwerken Zie artikel in bijlage.

NCC-2011-001

KdG–IWT

Automotive Software


3.2.3

30

Datalink laag

3.2.3.1 Kanaal toegangsmethoden

ol

We bekijken hoe één broadcast kanaal kan worden toegewezen aan verschillende concurrerende gebruikers.

ch o

CSMA Carrier sense multiple Access is een media access control protocol waarbij een node (ECU) eerst gaat nakijken of er reeds verkeer is op de bus.

ot eHo

ge s

Carrier sense beschrijft het feit dat er eerst wordt geluisterd op de bus. Het probeert te detecteren of de bus in gebruik is. Indien dit zo is, zal de node wachten met het verzenden van data op de bus. Multiple access beschrijft dat het om een gedeeld medium gaat. Als er toch een botsing optreedt, wacht de node voor een willekeurige tijd en begint het helemaal opnieuw.

Gr

De voortplantingsvertraging heeft een belangrijke invloed op de efficiëntie van het protocol. Er is een kleine kans dat er, net nadat een node is beginnen zenden, een andere node klaar is om te zenden en naar het kanaal luistert. Als het signaal van de eerste node nog steeds niet is aangekomen, denkt de andere node dat het medium vrij is en begint ook te zenden. Hierdoor ontstaat er een botsing. Hoe groter de voortplantingsvertraging, hoe belangrijker dit effect wordt.

Ka re

ld

e

Maar zelfs als er geen voortplantingsvertraging is, kan er nog een botsing ontstaan. Stel dat er een 3e node aan het zenden is. Node 1 en node 2 wensen beide iets op de bus te zetten en zullen wachten tot de bus opnieuw vrij is. Bij het vrijkomen van de bus zullen node 1 en node 2 gelijktijdig beginnen zenden en zal er een botsing ontstaan.

20

11

CSMA/CA De vorige vorm van CSMA noemen we 1-persistent CSMA omdat de node met kans 1 gaat zenden als het kanaal vrij is. Een andere vorm van CSMA noemen we niet-persistent CSMA of CSMA/CA. Het verschil met 1-persistent CSMA bestaat erin dat wanneer het kanaal niet vrij is, de node een willekeurige tijd wacht voor er terug gezonden wordt.

py rig

ht

CSMA/CD Carrier sense multiple access met colission detection. Bij de zuivere vorm van CSMA blijft de node z’n frame versturen ook al is dit verminkt door een botsing. De node kan natuurlijk beter de transmissie beëindigen. Dit bespaart bandbreedte en tijd. Een versie van dit protocol kennen we reeds uit de cursus datacommunicatie van de 3e bach, namelijk Ethernet (IEEE 802.3).

Co

CSMA/BA We bekijken nu eens een op CSMA gebaseerd protocol dat contentie oplost zonder dat er botsingen plaatsvinden. CSMA/BA staat voor CSMA met bitgewijze arbitratie. De normale arbitrage blijft wel gelden, dus indien een node aan het sturen is wachten de andere nodes. De node die data wenst te versturen, zal eerst een adres op de bus plaatsen. We gaan er van uit dat dit adres van gelijke lengte is. Stel dat er 4 nodes gelijktijdig iets wensen te zenden. Ze hebben adressen 0001, 0100, 1001 en 1010, waarbij de 1 dominant is (dwz. ze overschrijft 0 op de bus). Node 1 en 2 plaatsen een 0 op de bus, terwijl node 3 en 4 een dominante 1 plaatsen op de bus. Node 1 en 2 detecteren deze dominante 1 en weten dat ze de arbitrage verloren hebben. Ze stoppen het arbitrage-protocol en wachten tot de volgende contentieronde. Hierna plaatsten node 3 en 4 beide een 0 op de bus. Geen van beide verliest de arbitrage. Bij de 3e bit stuurt node 3 een 0 en node 4 een (dominante) 1. Node 3 weet dat hij de arbitrage verloren heeft en wacht tot de volgende NCC-2011-001

KdG–IWT

Automotive Software


31

ot eHo

ge s

ch o

ol

contentieronde. Node 4 werkt het adres af en weet dat niemand een hogere prioriteit heeft. De bus is vrij voor het verzenden van het frame door node 4.

Gr

Figuur 3.16: Voorbeeld van CSMA/BA

e

Dit principe wordt gebruikt bij het CAN protocol.

py rig

ht

20

11

Ka re

ld

TDMA TDMA staat voor ”Time Division Multiple Access”. Het is een schema voor het delen van een communicatiekanaal onder verschillende gebruikers. Alle gebruikers hebben een totale controle over het kanaal maar enkel voor een vaste tijdsperiode. Deze tijdsperiodes worden ”timeslots”genoemd.

Figuur 3.17: Voorbeeld van een TDMA cyclus

Co

Wanneer de nodes hun informatie in de timeslots hebben geplaatst, wordt de cylcus herhaald. Dit betekent dat alle nodes moeten weten wanneer ze hun informatie mogen versturen. Hiervoor moet de systeem architect een communicatie schema opstellen. In TDMA netwerken is de tijd extreem belangerijk. Hiervoor zijn er clock synchronisatiemechanismen en opstart procedures om de klokken te synchroniseren.

Flexible TDMA ”Flexible Time Division Multiple Access”laat toe om boodschappen te sturen wanneer gewenst is, zodat geen statisch slot gebruikt wordt wanneer de node niets moet versturen. Ieder node heeft een teller. Bij de start van de communicatie staan alle tellers op ”0”. De node met de hoogste prioriteit kan het eerst beginnen. Wanneer deze node informatie te versturen heeft, schrijft deze een dominante startsequentie op de bus. Alle andere nodes weten dat een frame op de bus zal geplaatst worden door de betreffende node. Wanneer het frame is verstuurd verhogen deze NCC-2011-001

KdG–IWT

Automotive Software

32

Gr

ot eHo

ge s

ch o

ol


e

Figuur 3.18: Voorbeeld van FTDMA (Byteflight)

Ka re

ld

de teller. Wanneer de desbetreffende node geen informatie te versturen heeft, zal er enkel een kleine wachtperiode zijn. Alle nodes gaan dan hun teller verhogen na deze kleine wachttijd. Daarna kan de node met de tweede hoogste prioriteit haar informatie versturen. Dit gaat door tot de maximale wachttijd of het maximaal aantal cycli is bereikt.

20

11

In het vierde slot kan node A een bericht versturen. In het eerste en zevende slot kan node A een bericht ontvangen. De andere sloten worden in deze cyclus niet gebruikt. Berichten met een hoge prioriteit zullen altijd verstuurd worden, terwijl berichten van een lagere prioriteit de rest van de bandbreedte hebben.

3.3.1

CAN: Controller Area Network

Co

3.3

Zie cursus datacommunicatie: 3e bach IWT: Elektronica-ICT.

py rig

CRC - codes

ht

3.2.3.2 Veiligheidsmechanismen

Overzicht

Het Controller Area Netwerk (CAN) is een serieel netwerk dat oorspronkelijk werd ontwikkeld voor de automotive industrie, maar is ook een populaire bus geworden voor zowel automatisatie als andere toepassingen. Het is ontwikkeld in de jaren ’80 door Bosch. In 1993 is het gestandaardiseerd door de International Standard Organisation (ISO) in de ISO-11898 norm. • Multi-master communicatie NCC-2011-001

KdG–IWT

Automotive Software


33

• Broadcast communicatie • fout-detectie en hertransmissie van berichten

Fysieke lagen

ch o

3.3.2

ol

De CAN standaard beschrijft enkel de onderste 2 lagen van het OSI-model.

ge s

In deze sectie beschrijven we de meest voorkomende vormen van de CAN fysieke laag.

ot eHo

3.3.2.1 ISO 1189811-2: High Speed CAN

High speed CAN gebruikt een twisted pair kabel (CAN-High en CAN-Low) waarop een differentieel signaal wordt geplaatst.

CAN-H CAN-L

min 2,00V 2,00V

Rust (1) nom max 2,50V 3,00V 2,50V 3,00V

Dominant (0) min nom max 2,75V 3,50V 4,50V 0,50V 1,50V 2,25V

Gr

Signaal

ld

e

Tabel 3.1: Spanningsniveaus van High Speed CAN

py rig

ht

20

11

Ka re

Dit is de meest gebruikte vorm van CAN. Het beschrijft snelheden tot 1 Mbit/s en een theoretische maximale buslengte van 40 meter. Afsluitweerstanden moeten aan de beide uiteinden van de bus worden geplaatst. De weerstanden zijn beide 120Ω.

Co

Figuur 3.19: High-speed CAN spanningsniveaus

Welke kabels er gebruikt mogen worden voor gebruik als CAN-bus, worden gespecificeerd in de ISO 11898 standaard. De belangrijkste specificaties zijn: • shielded of unshielded twisted pair kabel • nominale impedantie van 120 Ohm (min. 95 Ohm en max. 140 Ohm) • weerstand in functie van de lengte van 70 mOhm/m • lijnvertraging van 5 nsec/m

NCC-2011-001

KdG–IWT

Automotive Software


34

3.3.2.2 ISO 1189811-3: Fault-tolerant CAN Een andere vorm is de Fault-tolerant CAN. Deze gebruikt eveneens een twisted pair kabel waarop een differentieel signaal wordt geplaatst.

CAN-H CAN-L

(1) diff 5V 5V

Dominant (0) norm diff 3.6V 2.2V 1.4V 2.2V

ol

Rust norm 0V 5V

ge s

Tabel 3.2: Spanningsniveaus van Fault Tolerant CAN

ch o

Signaal

ot eHo

De maximale snelheid is 125 kbit/s. Door de lage snelheid is er geen nood aan afsluitweerstanden. Omdat er geen afsluitweerstanden zijn, is het mogelijk om af te stappen van een lineaire bus.

3.3.2.3 Andere vormen van de CAN fysieke laag

Gr

Buiten deze 2 veel voorkomende types, zijn er nog heel wat andere: • SAE J2411: Single wire

ld

Ka re

• CAN op POF: niet gestandaardiseerd

e

• ISO 11992: point-to-point

3.3.2.4 NRZ encoding en bitstuffing

20

11

De codering (encoding) of modulatie van de CAN-bus is bijzonder eenvoudig. Er wordt gebruik gemaakt van de non return to zero (NRZ) modulatiemethode, die de maximale transmissiesnelheid geeft. Dit wil eigenlijk zeggen dat er geen modulatie plaatsvindt, iedere 0 of 1 wordt als een 0 of 1 verstuurd. Dit betekent dat er gedurende 1 bittijd slechts 2 mogelijke toestanden zijn: dominant of recessief.

Co

py rig

ht

De NRZ-modulatiemethode zorgt ervoor dat niet in elke bit een stijgende of dalende flank voorkomt. Het is dus perfect mogelijk dat de bus zich lange tijd in de zelfde toestand bevindt: dominant of recessief. Wanneer er echter veel bits met eenzelfde polariteit na elkaar worden verstuurd, zijn er te weinig neergaande flanken om de CAN-modules te synchroniseren. Om dit probleem op te lossen wordt er na een bepaald aantal dezelfde bits een tegengestelde bit toegevoegd. Dit wordt bitstuffing genoemd. Als in een CAN-frame meer dan 5 bits in dezelfde (logische) toestand na elkaar moeten worden verzonden, dan wordt er automatisch na iedere reeks van 5 identieke bits een complementaire bit tussengevoegd en verzonden. Dit toegevoegde bit, dat natuurlijk geen informatie-inhoud bezit, wordt stuffbit genoemd (to stuff = opvullen).

3.3.2.5 bittiming en synchronisatie De verschillende CAN-controllers aanwezig op het CAN-netwerk moeten gesynchroniseerd worden op de data die zich op dat ogenblik op de bus bevindt omdat ze elk een eigen klok hebben. Op deze NCC-2011-001

KdG–IWT

Automotive Software

35

ol


ch o

Figuur 3.20: Bit stuffing bij CAN

ge s

klok kunnen er kleine afwijkingen ontstaan door temperatuur- en spanningswijzigingen.

e

Gr

De bittijd wordt verdeeld in vier verschillende segmenten:

ot eHo

Het is ontoelaatbaar dat er faseverschuivingen tussen de verschillende modules zouden optreden. Zowel de gegevensoverdracht als het arbitrage zou in dit geval volledig mis lopen.

Ka re

ld

Figuur 3.21: Bittijd van een CAN bit • Synchronisatiesegment: 2 modules zijn synchroon als hun op- of neergaande flank in dit gebied valt.

11

• Verspreidingstijdsegment: dit segment wordt gebruikt om de vertragingen op te vangen die ontstaan door de soms relatief grote afstand tussen 2 modules.

20

• Fasebuffersegment 1 en 2: deze worden gewijzigd, op deze manier kan men het sample point van een bit verschuiven en dus de faseverschuiving compenseren.

py rig

ht

• Sample point: Op het sample point wordt de waarde van de bit gelezen (1 of 0). Het sample point ligt tussen de 2 fasebuffersegmenten.

Co

Ieder segment wordt nu verder opgedeeld in een programmeerbaar aantal tijdskwanta. De lengte van een tijdskwantum (tq) is afhankelijk van de periode van de interne frequentiegenerator van het station en de programmeerbare schaalfactor (”Baud Rate Presealer- BRP). De waarde van die factor kan gelegen zijn tussen l en 32. De frequentiegenerator zorgt dus voor een minimum tijdskwantum dat vermenigvuldigd kan worden met de schaalfactor. Het synchroniseren vindt plaats op twee manieren: 1. Harde synchronisatie: Daar de interframe space recessief is en de start van een frame dominant, is het logisch dat alle ontvangers zich op deze overgang kunnen synchroniseren. 2. Hersynchronisatie: Hersynchronisatie is het verschuiven van het sample point zodat de volgende bitwisseling terug in het synchronisatiegebied valt. M.a.w. de bittijd wordt verlengd of ingekort. Deze synchronisatie vindt plaats bij elke bitwisseling NCC-2011-001

KdG–IWT

Automotive Software


3.3.3

36

Datalink laag

3.3.3.1 Broadcast communicatie

Ka re

ld

e

Gr

ot eHo

ge s

ch o

ol

Het CAN-concept is gebaseerd op het multimaster-principe. Dit wil zeggen dat iedere CAN-module op het CAN-netwerk, op eigen initiatief, berichten op de bus kan plaatsen. De verspreiding van de berichten verloopt volgens het broadcast-principe. Alle CAN-modules ontvangen dus alle CANberichten die op de bus verstuurd worden. Dus als een module een bericht verstuurt dat eigenlijk maar voor 1 bepaalde module bedoeld is, ontvangen alle andere modules dit bericht ook. Na ontvangst beslist elke module, via een interne lokale filter of het bericht wel voor hem bedoeld was en verdere verwerking van het bericht dus nodig is. Een dergelijke lokale filter - acceptance filter zit in elke CAN-module.

11

Figuur 3.22: Voorbeeld van een CAN-netwerk

Co

py rig

ht

20

Het broadcast communicatie mechanisme waar CAN op gebaseerd is, duidt op berichtgeoriënteerde transmissie. Een dergelijk protocol, gebaseerd op dit principe, bepaalt geen source en destination adressen maar bepaalt de inhoud van het bericht. Zo zal elk CAN-bericht een eigen identifier krijgen. Deze identifier is uniek in het hele CAN-netwerk omwille van het feit dat het de inhoud (de betekenis) van het bericht bepaalt en zijn prioriteit op het netwerk. Dit is zeer belangrijk als verschillende CAN-modules gelijktijdig op de CAN-bus willen versturen (bus arbitratie). Omwille van deze berichtgeoriënteerde transmissie en adressering wordt een grotere systeem- en configuratieflexibiliteit bekomen. Dit maakt het makkelijker om nog CAN-modules aan een bestaand CAN-netwerk toe te voegen zonder hardware of software veranderingen te doen aan het huidige netwerk. Maar enkel in het geval dat deze nieuwe CAN-modules enkel ontvangers zijn.

3.3.3.2 Arbitrage De eigenlijke data-overdracht op de CAN-bus bestaat niet, zoals gebruikelijk, uit logische nullen en enen, maar uit dominante (overheersende - 0) en recessieve (onderdanige - 1) bits. Daarbij wordt de bus door een recessieve bustoestand gekarakteriseerd die door een tweede, dominante bustoestand kan worden overschreven. Als dus een station op de bus een recessief bit uitzendt en een ander station gelijktijdig een dominant bit zendt, dan overschrijft het dominante bit het recessieve, m.a.w. de dominante toestand (het dominante bit) gaat voor de hele bus gelden. De toewijzing van de

NCC-2011-001

KdG–IWT

Automotive Software


37

logische toestanden voor deze bustoestanden gebeurt over het algemeen zodanig dat een logische nul de dominante en een logische één de recessieve toestand aangeeft.

ol

Arbitrage bij CAN gebeurt door middel van Carrier Sense Multiple Access met (non-destructieve) bitsgewijze arbitrage. Het frame-id (zie verder) wordt gebruikt voor de arbitrage. Omdat de logische 0 dominant is ten opzichte van de logische 1, heeft het bericht met het laagste frame-id de prioriteit.

ch o

3.3.3.3 Acceptance filtering

ge s

Bij de CAN-arbitrage zagen we dus eerder dat de identifier in een boodschap mee bepaalt welke boodschap eerst op de bus verstuurd kan worden. Dit is echter niet de enige functie van de identifier.

ot eHo

Elk bericht dat dus in de datalinklaag wordt samengesteld bevat een identifier. Deze identifier is een aanduiding voor de inhoud van het frame. Het geeft weer wat voor data er in deze boodschap verstuurd wordt. De identifier duidt dus NIET het doeladres (Eng. destination) aan zoals vaak misbegrepen wordt.

Gr

Voorbeeld: In een personenwagen kan het bijvoorbeeld voorkomen dat een CAN-boodschap met standaard identifier 13A de informatie van de ABS verstuurd. De ABS-informatie zal dus ten alle tijde in een CAN-boodschap met identifier 13A vervat zitten. De CAN-nodes op de bus die de ABS-informatie nodig hebben, halen dus de CAN-bootschappen met identifier 13A van de bus.

Ka re

ld

e

Elke ontvanger op de CAN-bus beslist aan de hand van een acceptance filter op de identifier of de data relevant is en dus van de bus gehaald moet worden. Dit principe wordt dan ook acceptance filtering genoemd

3.3.3.4 CAN frame formaat

20

11

Een CAN-bericht wordt in een vast formaat, een frame, verstuurd. Er zijn in principe vier verschillende frames mogelijk: 1. Data frame: Dit is een bericht waarin actuele data verstuurd wordt.

py rig

ht

2. Remote frame: Dit is een frame zonder data. Het bevat het verzoek aan andere CAN-modules om een data frame te sturen met een welbepaalde identifier en dus data. 3. Error frame: Dit frame wordt verstuurd wanneer een CAN-module een fout op de bus gedetecteerd heeft.

Co

4. Overload frame: Dit frame wordt verstuurd om wat meer tijd te laten tussen de verschillende data frames (of remote frames) indien dit nodig is. Naast deze indeling van verschillende soorten frames, kunnen we ook nog een onderscheid maken in frameformaat: Het CAN-protocol maakt gebruik van twee bericht(frame)-formaten: • CAN2.0 A: het standaard frameformaat • CAN2.0 B: het extended frameformaat NCC-2011-001

KdG–IWT

Automotive Software


38

Elk frame bestaat uit verschillende delen (velden) met elk hun specifieke functie. Zo is er een identificatie, een controlemogelijkheid, de eigenlijke data,� ingebouwd. Elk veld bestaat uit één of meerdere bits. Onderstaande figuur toont beide formaten. Hun belangrijkste velden zijn aangeduid opdat men duidelijk het verschil tussen beide kan zien. De overige velden worden verderop uitgebreid behandeld.

ot eHo

ge s

ch o

ol

Het grote verschil tussen beide is de grootte van hun identifierveld, in een standaard bericht bestaat uit de lengte van de gebruikte identifier. Bij het standaard frameformaat bestaat dit veld uit 11 bits. Bij het extended frameformaat bestaat deze uit 29 bits, de 11-bit identifier (base identifier) en een 18-bit uitbreiding (identifier extension).

Figuur 3.23: CAN Standaard Frame Formaat

Gr

Figuur 3.24: CAN Extended Frame Formaat

Ka re

ld

e

Het onderscheid tussen een standaard frameformaat en een extended frameformaat wordt gemaakt door de IDE-bit. Deze wordt als dominant verstuurd bij een 11-bit identifier en recessief bij een 29-bit identifier. Aangezien beide frameformaten over een zelfde bus kunnen verstuurd worden, is hierdoor dus bepaald welke boodschap voorrang krijgt. Een bericht met een 11-bit identifier heeft namelijk voorrang op een bericht met een 29-bit identifier.

py rig

ht

20

11

3.3.3.5 Data frame

Figuur 3.25: CAN Standaard Data Frame

Co

• SOF - Start of frame: Elk data frame begint met een dominante 0-bit, de SOF-bit. Er kan enkel een SOF-bit verstuurd worden door een CAN-node indien de bus zich in rusttoestand bevindt. (Eng: idle) • Arbitrage veld :Het arbitrageveld wordt samengesteld uit de identifier (doorgestuurd vanuit de LLC sublaag) en het RTR-bit. • Identifier: Bestaat uit 11 bits en stelt het adres van het bericht voor. Hierdoor weten de andere modules, die aangesloten zijn op de CAN, als dit bericht al dan niet voor hen bedoeld is. • RTR-bit - Remote Transmission Request-bit:Deze bit geeft weer als het een data of een remote (verzoek-) frame is. In geval van een data frame zal dit een dominante 0 zijn, in het andere NCC-2011-001

KdG–IWT

Automotive Software


39

geval een recessieve 1. Later zal blijken dat ook de prioriteit van het bericht in dit veld vervat zit, we zullen zien dat de RTR-bit ervoor zorgt dat een data frame steeds voorrang krijgt op een remote frame. • Control veld: Dit veld bestaat uit 6 bits:

ol

– IDE-bit: De identifier extention bit geeft weer als we met een standaard of een extended bericht te maken hebben. Bij een 0-bit is het een standaard bericht.

ch o

– r0-bit: bit voorbehouden voor eventuele toekomstige uitbreidingen en steeds dominant.

ge s

– DLC: de lengte van het dataveld, ook wel Data Length Code (DLC) genoemd. Dit veld bestaat uit 4 bits. Het getal dat hiering geplaats wordt geeft het aantal databytes data weer. Alle waarden vanaf 8 duiden op 8 databytes data.

ot eHo

• Dataveld: Dit is de werkelijk te verzenden data, welke 0 tot 8 bytes groot is. Elke byte bestaat dan nog eens uit 8 bits.

Gr

• CRC veld - Cyclic Redundancy Code: Dit veld bevat 15 CRC-bits en één CRC-delimiter. Hiermee controleert men of het verstuurde bericht correct ontvangen is. Alle verstuurde bits tot aan de CRC worden beschouwd als een groot binair getal en gedeeld door de constante 1100010110011001. De CRC is de restwaarde van deze deling. Bij het ontvangen van het bericht wordt de zelfde berekening uitgevoerd. Als deze waarde overeenstemt met de CRC weten we dat het bericht correct verzonden is.

Ka re

ld

e

• Bevestigingsveld (ACK-veld): Dit veld bestaat uit een bevestigingsbit (acknowledge slot) en één bit bevestigingsafsluiting (acknowledge delimiter). De zender maakt beide bits recessief 1. Als de controle, door de ontvanger uitgevoerd, positief is ( CRC klopt) dan maakt deze de bevestigingsbit dominant 0. De zender ziet dit en weet hierdoor dat minstens één ontvanger zijn bericht correct heeft ontvangen. • EOF - End of frame: Het einde van een dataframe bestaat uit 7 recessieve 1-bits.

20

11

• Interframe space: Tussen de verschillende berichten moet de bus minstens 3 bittijden vrij zijn vooraleer er een nieuw bericht op de bus kan geplaatst worden. Tijdens de interframe space en het vrij (idle) zijn van de bus heeft deze een recessieve waarde.

Co

py rig

ht

Zoals reeds gezegd is het grote verschil met het standaard frame de grootte van het identifier veld. Dit bestaat nu uit 29 bits (11+18).

Figuur 3.26: CAN Extended Data Frame

De volgende velden zijn verschillend tegen over het standaard frame formaat: • SRR - Substitute Remote Request: Deze bit wordt op de plaats verstuurd waar in het standaard CAN-data frame het RTR-bit staat. Hierdoor zal een transmitter deze bit steeds recessief 1 versturen Deze bit heeft steeds een recessieve waarde. Hierdoor heeft een standaard frame steeds voorrang op een extended. Herinner het arbitrageproces.

NCC-2011-001

KdG–IWT

Automotive Software


40

• Controleveld: Dit veld bestaat nu uit 6 bits, de eerste twee bits zijn voorbehouden voor eventuele toekomstige uitbreidingen, en zijn steeds dominant. De volgende 4 bits geven de lengte van het dataveld weer (DLC).

ol

3.3.3.6 Remote Frame

ot eHo

ge s

ch o

Door een remote-frame te zenden kan een bepaalde CAN-controller informatie vragen aan een andere CAN-controller.

Figuur 3.27: CAN Remote Frame

Gr

Een remote frame komt grotendeels overeen met een data frame. De verschillen worden hier weergegeven:

ld

e

• Identifier: De identifier die in het frame voorkomt is de identifier van het gewenste bericht. De controller die het bericht eigen aan deze identifier kent, zal het gevraagde bericht verzenden.

Ka re

• RTR-bit: De RTR-bit (remote transmission request) is bij een remote-frame recessief. • Controleveld: De datalengte (DLC) in het controleveld moet overeenkomen met de lengte van het op te vragen bericht.

20

11

• Dataveld: Het aantal bits in het dataveld bedraagt nul, er is dus eigenlijk geen dataveld aanwezig.

ht

3.3.3.7 Error afhandeling en het error frame

py rig

De foutcontrole gebeurt op twee manieren: • Op bitniveau: Hier zijn er twee controles:

Co

– Bit monitoring: Er wordt steeds door de ontvanger van de zendende module gecontroleerd of het bitniveau op de bus wel gelijk is aan het bitniveau dat uitgezonden wordt. – Bit stuffing: Hier wordt er gecontroleerd of er niet meer dan 5 dezelfde bits elkaar opvolgen, hetgeen in een stuffbit error resulteert. (Zie ook Bitstuffing) • Op berichtniveau: Hier zijn er drie controles: – CRC-check: Hiermee wordt er gecontroleerd of er geen bits door storingen veranderd zijn. – Frame check: Hier gaat men kijken als de lengte van het frame klopt. Ook is er een controle van de waarde van bepaalde bits zoals delimiters en end of frame.

NCC-2011-001

KdG–IWT

Automotive Software


41

– Acknowledge check: Door middel van controle gaat men kijken als tenminste één ontvanger het bericht heeft ontvangen. Wanneer één van de vorige fouten wordt ontdekt, wordt het lopende bericht onmiddellijk onderbroken door het zenden van een error frame.

ge s

ch o

ol

In geval van bv. een defecte module kan deze foutdetectie leiden tot het blokkeren van de CAN-bus doordat alle berichten, ook correcte, worden afgebroken door error flags. Om dit te voorkomen doet elke controller aan zelfcontrole. Hierdoor kunnen aanhoudende storingen en het uitvallen van een module vastgesteld worden. Deze zelfcontrole bestaat erin het aantal opgetreden fouten bij te houden.

ot eHo

Afhankelijk van het aantal opgetreden fouten kan een CAN-controller zich in drie toestanden bevinden: • error active • error passive

Gr

• bus off

Ka re

ld

e

Om het aantal fouten bij te houden beschikt een CAN-controller over een teller om de zendfouten (TC) te tellen en een teller om de ontvangfouten (RC) te tellen. Wanneer een fout wordt geconstateerd, verhoogt de desbetreffende teller met 8. Voor elk correct bericht neemt hij met 1 af. Zolang beide tellers een waarde kleiner dan 127 hebben is de status van de controller error active. De controller zal normaal werken.

11

Bij het vaststellen van een fout zal een active error flag gezonden worden. Als één van de tellers de waarde 127 overschrijdt, wordt de status van de bus error passive. De controller blijft normaal werken, maar bij het optreden van een fout zal hij een passive error flag zenden.

20

De controller krijgt de status bus off als de teller voor de verzendfouten de waarde 256 overschrijdt. De controller wordt nu afgesloten van de bus. Zie figuur 3.28

py rig

ht

Wanneer er een fout geconstateerd wordt, wordt het frame dat verstuurd werd onderbroken en wordt er onmiddellijk een error flag verzonden. Afhankelijk van de status van de controller, wordt er een error active of een error passive flag verzonden. Een error active flag bestaat uit 6 dominante 0-bits. Een error passive flag bestaat uit 6 recessieve 1-bits.

Co

Doordat een error flag bestaat uit 6 dezelfde opeenvolgende bits zal dit door de andere controllers als fout aanzien worden waardoor zij ook error flags gaan verzenden ten gevolge van stuff errors, bit errors of format errors. Bij een error active flag begint elk station een recessieve 1 bit te versturen zodra hun active error flag afgelopen is. Deze recessieve bit kan eventueel overschreven worden door andere stations die nog hun active error flag aan het versturen zijn (want bij het arbitrage zal de 0 het van de 1 winnen). Dit leidt in totaal dus tot minstens 6 en maximaal 12 opeenvolgende dominante bits. Wanneer een station een error passive flag (6 recessieve bits) wil zenden zal de error passive controller zijn error flag afsluiten als hij 6 opeenvolgende recessieve bits heeft gedetecteerd. Het verzenden van een error passive flag leidt echter niet altijd tot het detecteren van error(s) bij de ontvangers en dit in twee gevallen. Het eerste geval is wanneer een error passive flag gestuurd wordt tijdens arbitrage en andere nodes blijven zenden. Het tweede geval is wanneer er een error passive flag gestuurd wordt NCC-2011-001

KdG–IWT

Automotive Software

42

Ka re

ld

e

Gr

ot eHo

ge s

ch o

ol


Co

py rig

ht

20

11

Figuur 3.28: CAN toestandsdiagram

Figuur 3.29: CAN Error Frame

NCC-2011-001

KdG–IWT

Automotive Software


43

op minder dan 6 bits voor de CRC. Van zodra een error flag, active of passive, wordt afgesloten worden er nog 8 recessieve bits verstuurd. Deze 8 recessieve bits vormen de error delimiter. Een error flag vormt samen met zo een error delimiter het error frame.

ch o

ol

Na het error frame zal er terug een interframe space van minstens 3 bits zijn. Dus na minstens 23 bits in totaal kan men terug trachten van informatie op de bus te versturen. In het geval van een error passive controller zal deze interframe space echter nog gevolgd worden door 8 recessieve bits - suspend transmission (geschorste verzending) - vooraleer de bus vrij komt en er andere controllers een bericht kunnen verzenden. Hier kan dus pas na minstens 31 bits terug informatie op de bus gestuurd worden, of beter is de bus terug vrij.

ge s

Na het error frame, de interframe space en eventueel de suspend transmission zal het station dat onderbroken werd opnieuw proberen zijn boodschap te versturen.

ot eHo

3.3.3.8 Overload frame

Gr

Dit soort frames heeft als doel de datastroom te vertragen zodat de desbetreffende controller de benodigde verwerkingstijd krijgt. Er mogen maximum twee overload frames verzonden worden om een vertraging te bekomen. Er zijn twee toestanden die kunnen leiden tot overload (overbelasting-) frames:

ld

e

1. Een controller heeft onvoldoende tijd om de data te verwerken.

Ka re

2. Er wordt een dominante bit gedetecteerd in de interframe space.

ht

20

11

In het eerste geval wordt een overload flag verzonden wanneer men een interframe space verwacht, in het tweede geval direct na de dominante bit.

Figuur 3.30: CAN Overload Frame

py rig

Een overload flag bestaat uit 6 dominante bits.

Co

Door het verzenden van een overload flag wordt de normaal minimum 3 bittijden durende interframe space ingekort. Hierdoor gaan alle andere stations ook overload flags verzenden waardoor we een opeenvolging van dominante bits krijgen. Deze opeenvolging bestaat uit 6 tot max 12 bits. Wanneer een controller zijn overload frame heeft verzonden zal hij recessieve bits beginnen te verzenden, deze kunnen wel overschreven worden door dominante bits van andere stations. Van het ogenblik dat er een recessieve bit van de bus gelezen wordt, weet men dat alle stations hun overload flag hebben uitgestuurd. Hierna zendt elk station nog 7 recessieve bits, zodat een 8-bit overload delimiter bekomen wordt. We zien duidelijk dat een overload frame zeer sterk op een error frame lijkt, het enige verschil is dat een overload frame steeds tijdens een interframe space verzonden wordt.

NCC-2011-001

KdG–IWT

Automotive Software


3.4 3.4.1

44

CAN hogere lagen protocollen TTCAN: Time-Triggered CAN

ol

TTCAN is een hogere laag gebouwd op de het CAN protocol. Deze laat toe dat het event-triggered protocol toch op een time-triggered wijze kan werken. Meer nog, ze laat beide toe.

ot eHo

ge s

ch o

De bitsgewijze arbitratie van CAN zorgt ervoor dat een bericht met hogere prioriteit op de bus kan worden geplaatst zonder dat berichten met een lagere prioriteit worden vernietigd. Deze worden enkel uitgesteld. Indien er reeds een bericht verzonden wordt, zal het hoog prioritair bericht ook even worden uitgesteld tot de transmissie voltooid is. In het algemeen kan men verwachten: hoe lager de prioriteit van een bericht, hoe groter de latency . Door gebruik te maken van time-triggered operatie, kan men deze latency vermijden en de bandbreedte van CAN op een efficiëntere manier gebruiken. De CAN standaard is hiervoor uitgebreid met 2 niveau’s. Niveau 1 zorgt voor de timetriggered operatie van CAN door gebruik te maken van een referentiebericht van een tijdsmaster. In niveau 2 wordt er een globale tijdsbasis opgelegd. Een continue correctie van de klok is hiervoor nodig.

Gr

3.4.1.1 Het referentiebericht

Ka re

ld

e

TTCAN is gebaseerd op een time-triggered en periodische communicatie die geklokt is door een tijdsmaster. Deze stuurt een referentiebericht uit die makkelijk te herkennen is aan z’n identifier. Een niveau 1 referentiebericht bevat slechts 1 byte controle informatie. De rest van het CAN bericht kan gebruikt worden om signalen door te sturen. Bij een niveau 2 referentiebericht bevat het meer informatie (de globale tijdsinformatie van de tijdsmaster). De controle informatie bevat dan 4 byte, de andere 4 kunnen gebruikt worden voor signalen.

11

3.4.1.2 De Basiscyclus

Co

py rig

ht

20

De periode tussen 2 referentieberichten noemt de basiscyclus. Deze basiscyclus bestaat uit verschillende tijdsvensters van verschillende maten die berichten kunnen bevatten.

Figuur 3.31: Basis Cyclus van TTCAN De tijdsvensters van de basis cyclus kunnen gebruikt worden voor periodieke en spontane berichten. Alle berichten die op het CAN netwerk worden verstuurd zijn standaard data-berichten. Een tijdsvenster voor periodieke berichten noemen we een exclusief venster. Het begin van het tijdsvenster bepaald het punt waarop het bericht verzonden wordt. Als het gehele systeem juist gespecifieerd is (offline, door gebruik te maken van design tools), kunnen er geen conflicten optreden. Maar indien NCC-2011-001

KdG–IWT

Automotive Software


45

dit wel het geval is, zorgt de CAN datalink laag dat er geen botsing op het netwerk voorkomt. Meerdere van deze exclusieve vensters kunnen voorkomen voor een enkel bericht. Men moet er rekening mee houden dat automatische retransmissie van berichten niet mag, omdat ze de cyclus zouden verstoren.

ol

Een tijdsvenster voor spontane berichten (event-tiggered) noemen we een arbitratievenster. De bitsgewijze arbitratie van CAN zorgt ervoor dat het bericht met de hoogste prioriteit verstuurd wordt.

Gr

ot eHo

ge s

ch o

Men kan ook enkele vensters behouden voor toekomstig gebruik. Dit zijn de zgenaamde vrije vensters.

ld

3.4.1.3 Kennis van de nodes in TTCAN

e

Figuur 3.32: Types van TTCAN tijdsvensters

Co

py rig

ht

20

11

Ka re

Een node in een TTCAN netwerk hoeft niet alle berichten te kennen. De controller moet enkel weten op welke tijdstippen zijn exclusieve berichten verstuurd moeten worden en op welke tijdstippen er hij mee kan concurreren voor de bus. In figuur 3.33 kan men een voorbeeld zien waar de controller een bericht C verstuurd in de vensters 2 en 6. Een event-triggered bericht bericht F in het arbitratievenster 3. De controller is enkel ge’̈intereseerd in de ontvangst van bericht A in venster 1.

Figuur 3.33: Lokale informatie van een TTCAN controller De meeste controlelussen en taken hebben een verschillende periode, ze hebben allen verschillende patronen om berichten te versturen. De basiscyclus van TTCAN heeft hiervoor niet voldoende NCC-2011-001

KdG–IWT

Automotive Software


46

ld

e

Gr

ot eHo

ge s

ch o

ol

flexibiliteit. De TTCAN specificatie laat toe om meerdere basiscycli te gebruiken om de communicatiematrix op te stellen.

Ka re

Figuur 3.34: TTCAN communicatiematrix

20

3.4.1.4 Klok mechanismen

11

Een belangrijke beperking bij een arbitratievenster is dat het te zenden bericht past binnen het venster. Wanneer 2 arbitratievensters op elkaar volgen, kunnen deze tot een enkele samengesmolten worden. Hierin is automatische retransmissie toegelaten zolang er aan de beperking voldaan is. Omdat dit een zeer complexe zaak is maken ingenieurs gebruik van design tools.

py rig

ht

De cyclustijd is de basistijd om de werking van TTCAN te garanderen. De Netwerk Time Unit (NTU) is de bouwsteen van zo’n cyclus. In een TTCAN niveau 1 netwerk is de NTU de bittijd van het CAN netwerk. In een niveau 2 netwerk is dit de fysieke seconde. We moeten hier dus de relatie tussen de lokale oscillator en de systeem wijde NTU realiseren. Dit zien we in figuur 3.35

Co

De node afhankelijke oscillator geeft de systeem klok door aan een frequentiedeler. Deze deler realiseert de NTU door gebruik te maken van de time unit ratio (TUR). Deze TUR is bepaald per node. De NTU kan worden gebruikt om de lokale en globale klok te vormen. De node die het referentiebericht stuurt noemt men de tijdsmaster. In TTCAN niveau 2 nemen alle nodes een snapshot van hun tijdswaardes tijdens de SoF van het referentiebericht. De timemaster stuurt zijn waarde (die de enige correcte waarde is) mee in het referentiebericht. Bij ontvangst berekenen de nodes elk hun lokale afwijking (het verschil tussen de ontvangen waarde en de referentiewaarde). De globale tijd kan worden berekend door de offset op te tellen bij de lokale tijd. Als alle klokken op dezelfde snelheid lopen zorgt dit mechanisme ervoor dat iedereen dezelfde kijk heeft op de globale tijd. Spijtig genoeg is dit onmogelijk. Door kleine afwijkingen op de oscillatoren moet er een mechanisme zijn om deze afwijkingen te compenseren. Dit is de zogenaamde drift NCC-2011-001

KdG–IWT

Automotive Software

47

ot eHo

ge s

ch o

ol


Co

py rig

ht

20

11

Ka re

ld

e

Gr

Figuur 3.35: Productie van TTCAN NTU

Figuur 3.36: TTCAN Offset Correctie NCC-2011-001

KdG–IWT

Automotive Software


48

Ka re

ld

e

Gr

ot eHo

ge s

ch o

ol

correctie. Dit mechanisme zorgt voor een continue update van de TUR. Een initiëele versie van de TUR wordt geconfigureerd door de systeemingenieur. Tijdens operatie meet de controller de lengte tussen 2 frame synchronisatie pulsen. Dit zowel in lokale tijd (oscillator) als in globale tijd (fysieke seconde). Het quotient tussen deze 2 waardes geeft ons de TUR.

11

Figuur 3.37: TTCAN Drift Compensatie

20

3.4.1.5 Fouttolerantie

Co

py rig

ht

Zoals we zien speelt de tijdsmaster een zeer belangrijke rol bij de werking van het TTCAN netwerk. Daarom is het belangrijk dat we voor een fouttolerantie zorgen van de tijdsmaster. Dit kan men doen door meerdere nodes als potentiële tijdsmaster aan te duiden. Ze krijgen allen een corresponderende ID die kunnen worden gebruikt als synchronisatie bericht. Na de reset van een potentiële tijdsmaster kijkt deze of er reeds communicatie op de bus is. Indien er geen referentiebericht ontvangen wordt (tijd ≥ basiscyclus), stuurt de node een referentiebericht met z’n identifier. Deze controller neemt de rol van tijdsmaster voor zich. Wanneer een referentiebericht ontvangen wordt met een hogere ID, stopt de controller met het zenden van z’n referentieberichten en synchroniseert op de cyclus. Wanneer er een synchronisatiebericht wordt ontvangen met een kleinere prioriteit, zal de node eerst synchroniseren op dit bericht. Bij het begin van de nieuwe cyclus, stuurt hij wel z’n bericht waardoor hij de arbitrage wint. Bij het uitvallen van de tijdsmaster ontdekken de andere potentiële tijdsmasters dit. Na een korte periode (gerealiseerd door een time-out periode) stuurt een potentiële tijdsmaster z’n referentiebericht. Opnieuw zorgt de CAN-arbitrage ervoor dat slechts 1 node opnieuw tijdsmaster is.

NCC-2011-001

KdG–IWT

Automotive Software


49

3.4.1.6 Event initialisatie van de basiscyclus

Vrachtwagens

ge s

3.4.2

ch o

ol

Voor sommige applicaties is het niet wenselijk dat er een strikt time triggered schema is voor een lange periode. Dit is mogelijk in TTCAN. Als de applicatie van de tijdsmaster beslist om het periodieke schema te onderbreken stuurt hij dit door in z’n referentiebericht. Hierdoor weten de andere (potentiële) tijdsmasters dat er vanaf de volgende cyclus een gat in het schema te verwachten is. Ze nemen de taak van de tijdsmaster niet over. De applicatie van de tijdsmaster zorgt ervoor dat het schema opnieuw gëïnitialiseerd wordt. De master stuurt terug een referentiebericht.

ot eHo

3.4.2.1 J1939

Dit CAN Higher Layer Protocol is ontwikkeld door SAE (Society of Automotive Engineers) en is eigenlijk de opvolger van eerdere ontwikkelingen, vastgelegd in J1708/J1587 en J1922.

ld

e

Gr

Omdat een ver doorgedreven compatibiliteit met het J1708/J1587 protocol gewenst was, was er voor J1939 een verdere uitbreiding van de identifier van een CAN-bericht nodig. J1939 heeft er dus voor gezorgd dat er een extended versie (29 bit identifier) van CAN gekomen is. Verder werd vastgelegd dat J1939 enkel gebruik maakt van een CAN-bus met een baudrate van 250 kbit/s. Dit zorgt ervoor dat de CAN-bus een bandbreedte heeft om ongeveer 1850 CAN-berichten per seconde te sturen.

11

Applicatie Laag

Ka re

De J1939 standaard legt specificaties vast voor 5 lagen van het OSI-model. Deze lagen zijn de fysieke laag en datalinklaag, de lagen die ook in het CAN-protocol gedefinieerd zijn, de netwerk-, transport- en applicatielaag.

SAE SAE SAE SAE SAE SAE

J1939/21 J1939/31 J1939/21 J1939/11 J1939/13 J1939/15

SAE J1939/01 SAE JA1939/81

Tabel 3.3: J1939 in het OSI-model

Co

py rig

ht

20

Presentatie Laag Sessie Laag Transport Laag Netwerk Laag Datalink laag Fysieke laag

SAE J1939/71 SAE J1939/73 SAE J1939/75

• ”SAE J1939/11: Definieert een CAN High-Speed buskoppeling naar een Twisted Shielded Pair bus op 250 kbit/s en dit volgens de ISO 11898 norm. • SAE J1939/13: Definieert Off-board diagnosestekker. • SAE J1939/15: Definieert een afgeslankte versie van de fysieke laag. Hier gaat het om een Unshielded Twisted Pair. • SAE J1939/21: Beschrijft de communicatie over CAN op basis van de CA 2.0B specificatie. Voor deze communicatie wordt enkel gebruik gemaakt van het ”Extended”formaat. Het NCC-2011-001

KdG–IWT

Automotive Software


50

”Standard”formaat wordt enkel voor herstelspecifiek gebruik ingezet. Tevens beschrijft het ook verschillende netwerkdiensten voor berichtafhandeling, bevestiging van de overdracht van data evenals de overdracht van gefragmenteerde overdracht van grotere blokken.

ch o

• SAE J1939/71: Beschrijft eigenlijk de gegevens die overgestuurd worden.

ol

• SAE J1939/31: Beschrijft de overdracht van berichten tussen verschillende netwerksegmenten, hier dus CAN-segmenten. Dit dient ook om het verkeer van berichten te reduceren in de afzonderlijke segmenten.

• SAE J1939/73: Beschrijft het zelfde als J1939/71 maar dan voor diagnose.

ge s

• SAE J1939/75: Dit vormt een uitbreiding op de twee vorige specificaties.

ot eHo

• SAE J1939/01: Bevat de aanbevolen ontwikkeling voor controle en communicatie netwerken in voertuigen. • SAE J1939/81: Beschrijft netwerk management functies.

Ka re

ld

e

Gr

Het protocol is standaard in de vrachtwagen- en busindustrie. Hier wordt op een geheel andere manier gewerkt, als in de personenwagenindustrie. Een tiental bedrijven over de hele wereld maken zogenaamde ECUs (Electronic Control Units), die door de vrachtwagenconstructeurs geïntegreerd worden binnen hun totale besturing. Het J1939 protocol zorgt ervoor, dat alle units zonder probleem op elkaar aangesloten kunnen worden en elkaar ook begrijpen. Naast toepassing in de traditionele omgeving vindt dit protocol ook navolging in de agrarische industrie. Uit deze SAE J1939 zijn immers ander hogere lagen protocollen ontstaan die op J1939 gebaseerd zijn: • ISO 11992: ISO standaard voor communicatie om vrachtwagens en aanhangers. • ISO 11783: ISO standaard voor communicatie op landbouwvoertuigen.

11

• NMEA 2000: standaard voor communicatie in navigatiesystemen in de maritieme sector.

ht

20

Het toepassingsgebied van J1939 situeert zich in op CAN-gebaseerde embedded systemen die in heel breed bereik van voertuigen en transportsystemen gebruikt worden. Het heeft dus zijn plaats veroverd in o.a. volgende sectoren:

py rig

• Vrachtwagens en bussen

• Voertuigen die niet op de baan mogen rijden

Co

• Passagiers en cargotreinen • Maritieme elektronica We bekijken de opbouw van het extended CAN frame in J1939. Een CAN-bericht van het ”Extended”formaat bestaat uit een identifier van 29 bits lang en maximaal 8 bytes aan data, zoals het dus ook in de CAN-specificaties beschreven staat. Bij J1939 wordt echter de CAN-identifier ingedeeld in de volgende secties:

NCC-2011-001

KdG–IWT

Automotive Software

HOOFDSTUK 3. AUTOMOTIVE DATACOMMUNICATIE 28..26 Prioriteit

25

24

R

DP

23..16 15..8 PGN PF PS (DA/GE)

51 7..0 SA

Tabel 3.4: Opbouw van een J1939 CAN ID

ge s

ch o

ol

• Prioriteit: De drie hoogste bits van de 29-bit identifier staan in voor de busarbitrage en bepaalt dus zo de prioriteit van het CAN-bericht. Er kan dus een prioriteit van 0 tot 7 gevormd worden waarbij 0 de hoogste prioriteit vormt en 7 de laagste. Voor storingsberichten zal de prioriteit in het begin op 3 staan en bij alle andere berichten op 6. Bij het ontwerpen van een netwerk kunnen meer specifieke prioriteiten toegekend worden. Dit laat toe om de berichten op een zo optimaal mogelijk moment op de bus te plaatsen.

Gr

ot eHo

• Parameter Group Number: De Parameter Group Number kan gezien worden als een beschrijving van wat er in de datavelden van het CAN-bericht aan informatie meegestuurd wordt. In de PGN zit echter ook de manier van overbrenging van een CAN-bericht vervat, en dit in het PDU formaat veld. Dit alles geldt echter niet voor CAN-berichten met meer dan 8 bytes aan data. Bij deze berichten wordt de Parameter Group Number in het dataveld meegestuurd. Een Parameter Group Number kan ook voor meerdere/verschillende informatie staan daar het steeds interessant is om zo veel mogelijk informatie in een CAN-bericht over te sturen. De PGN bestaat uit 4 delen:

ld

e

– R - reserveringsbit: Deze bit werd door SAE gereserveerd voor toekomstig gebruik en werd op nul gezet. Deze bit biedt immers de mogelijkheid om in de toekomst het aantal Parameter Group Numbers te verdubbelen.

Ka re

– DP - Data Page Bit: Deze bit dient voor een verdere uitbreiding van het hierop volgende PF-veld. Het duidt echter een tweede mogelijkheid van PDU formaat aan. – PF - PDU Format: In het 8-bit PDU Format veld worden communicatie diensten gespecificeerd i.v.m. de overdracht van de berichten. We onderscheiden:

11

* PDU1-Format: Deelnemersgeoriënteerde overdracht * PDU2-Format: Berichtgeoriënteerde overdracht

ht

20

– PS - PDU Specific: Afhankelijk van het PDU formaat kan het PDU specifieke veld een Destination Address (DA) of GROUP Extension (GE) bevatten. Als PF een waarde heeft van 0 tot en met 239 dan PS = DA. We spreken hier van PDU1 Format. Als PF een waarde heeft van 240 tot en met 255 dan PS = GE. We spreken hier van PDU2 Format.

Co

py rig

• Source Address: Het Source Address specificeert de zender van een bericht. Elke deelnemer van het CAN-netwerk heeft immers zijn eigen adres (0..253). Zo zullen berichten die een gelijkaardige PDU-waarde hebben toch nog verschillend zijn en worden dus collisions (botsingen) voorkomen. De verschillende PGN-nummers, die het dataveld van het CAN-bericht bepaald, worden in de J1939/71 standaard gegeven. We geven een klein voorbeeldje: Men kan zien dat er nog naar een SPN nummer verwezen wordt. Dit is het Suspect Parameter Number. Dit nummer kan eveneens worden opgezocht in de standaard en bevat informatie over het veld. Een SPN heeft onder andere resolutie en offset als eigenschappen. Deze eigenschappen worden gebruikt om de meetwaarde uit het CAN-bericht om te zetten naar de werkelijke waarde: Werkelijke waarde = (Meetwaarde * Resolutie) + Offset NCC-2011-001

KdG–IWT

Automotive Software

HOOFDSTUK 3. AUTOMOTIVE DATACOMMUNICATIE PGN Nummer Omschrijving Interval Tijd Data Lengte ...

52

65268 (00FEF416) Autoband Condities 8 sec 10 byte ...

SPN beschrijving Autoband Locatie Autoband Druk Autoband temperatuur ...

SPN 929 241 242 ...

ch o

Lengte 1 byte 1 byte 2 byte ...

ge s

Locatie 1 2 3-4 ...

ol

Tabel 3.5: Voorbeeld uit de J1939/71 standaard (1)

ot eHo

Tabel 3.6: Voorbeeld uit de J1939/71 Standaard (2)

ld

e

Gr

Voorbeeld met SPN = 242 Meetwaarde = 10000 Resolutie = 0.03125 ◦ C/bit Offset = -273 ◦ C Werkelijke waarde = (10000 * 0.03125) - 273 = 39,5 ◦ C

Ka re

3.4.2.2 FMS

py rig

ht

20

11

Als we rechtstreeks op de CAN-bus van een vrachtwagen meten, zullen we CAN-boodschappen uitlezen die dus aan de J1939 standaard voldoen. Het is echter niet gewenst, vooral door de fabrikanten, om rechtstreeks op de interne CAN-bus te connecteren. Dit kan immers gevolgen hebben voor de garantie van de vrachtwagen. Naar aanleiding hiervan zijn een aantal vrachtwagenfabrikanten samen rond de tafel gaan zitten om een gemeenschappelijke interface te ontwikkelen waarop een minimum aan CAN-data op uit te lezen is. Op de CAN-bus zit immers zeer handige data zoals kilometerstand, snelheid, enz� Vandaar dat men een gemeenschappelijke interface heeft ontwikkeld als open standaard om ook aan derden bepaalde informatie, aanwezig op de CAN-bus, vrij te geven. Op deze manier is het een handig hulpmiddel om rendement en inzet verder te optimaliseren. Deze standaard wordt de FMS-Standaard genoemd. (FMS - Fleet Management System) De vrachtwagenfabrikanten die tot de FMS-Standaard Groep behoren (en die dus de FMS-Standaard ondersteunen) zijn:

Co

1. DaimlerChrysler

SPN - nummer Omschrijving Data Lengte Resolutie Offset Bereik Type PGN

242 Temprature at the surface of the tire sidewall 2 byte 0.03125 ◦ C/bit -273 ◦ C -273 tot 1735 ◦ C Measured 65268

Tabel 3.7: Voorbeeld uit de J1939/71 Standaard (3) NCC-2011-001

KdG–IWT

Automotive Software


53

2. MAN 3. Scania 4. DAF Trucks 5. IVECO

ol

6. Volvo Trucks

ch o

7. Renault Trucks

Personenwagens

ot eHo

3.4.3

ge s

Meer informatie: http://www.fms-standard.com

CAN in andere domeinen

e

3.4.4

Gr

Voor personenwagens zijn er geen echte standaarden voor handen. Elke fabrikant van personenwagens implementeert de CAN op zijn manier en die kan zeer verschillend zijn. Zelfs binnen verschillende types van wagens bij het zelfde automerk komen verschillen voor.

Ka re

ld

We bespreken hier zeer kort welke andere HLP’s er zijn voor andere domeinen.

3.4.4.1 CAN-kingdom

py rig

ht

20

11

Dit door de Zweedse firma Kvaser ontwikkelde protocol heeft een zeer hiërarchische structuur. In verschillende lagen wordt hiermee een gedistribueerd besturingssysteem opgezet. Het is eigenlijk meer een conceptueel denken, dan een echte applicatielaag. Daarom bestaan er ook mogelijkheden om het protocol eventueel te combineren met bijv. DeviceNet op één netwerk. Het toepassingsgebied lag in eerste instantie vooral bij hydraulische systemen in combinatie met robots. De laatste jaren is er echter ook succes geboekt bij de Amerikaanse Marine. Toepassingsgebieden: CAN-Kingdom wordt vooral gebruikt in op-CAN-gebaseerde embedded communication systems, in applicaties die een hoge realtime gedrag vertonen. Het heeft dus zijn plaats veroverd in o.a. volgende sectoren: • machine controle

Co

• Maritieme elektronica Voor meer info: http://www.cankingdom.org/over.htm

3.4.4.2 CANOpen CANopen is een gestandaardiseerd protocol, dat communicatie mogelijk maakt tussen toestellen van verschillende fabrikanten en dat de uitwisselbaarheid van gegevens tussen deze toestellen garandeert. Het protocol werd ontwikkeld door CAN in Automation (CiA) en werd gestandaardiseerd als CENELEC EN 50325-4. CANopen kent een breed toepassingsgebied, vooral in Europa, waar het de NCC-2011-001

KdG–IWT

Automotive Software


54

toonaangevende standaard vormt voor industriële, automatiserings- en embedded systemen. Toepassingsgebieden: CANopen wordt vooral gebruikt in low- and mid-volume embedded systems, soms ook in automation control systems. Het heeft dus zijn plaats veroverd in o.a. volgende sectoren: • Op vrachtwagens monteerbare controle systemen

ol

• Voertuigen die niet geschikt zijn om op de baan te rijden

ch o

• Passagiers- en cargotreinen • Maritieme elektronica

ge s

• Industriële automatisatie • Industriële machinecontrolesystemen

ot eHo

• Liften • Automatisatie in gebouwen • Medische uitrusting en apparatuur • Niet-industriële controlesystemen

Gr

• Niet-industriële apparatuur

ld

e

Voor meer info: http://www.can-cia.de/canopen/

Ka re

3.4.4.3 DeviceNet

Co

py rig

ht

20

11

DeviceNet is ontwikkeld door de Allen Bradley divisie van Rockwell. Inmiddels is er een onafhankelijke stichting voor opgericht, de ODVA (Open DeviceNet Vendor Association). Deze doet het beheer en de marketing voor het netwerk. Inmiddels is het netwerk met name in de V.S., maar ook in het verre oosten, uitgegroeid tot waarschijnlijk de belangrijkste veldbus in productieomgevingen. De veldbustoepassing zit in het algemeen echter een niveau hoger dan de bij CANopen omschreven embedded omgeving. We koppelen hiermee machines en apparaten aan elkaar. Voor de gebruiker is het dan ook veel meer een plug en play netwerk, waarbij kennis van het CAN-netwerk bij de gebruiker niet vereist is. DeviceNet is dan ook speciaal ontwikkeld voor industriële automatisatie en vormt daardoor een rechtstreekse concurrent voor protocols als Profibus-DP en Interbus. Bij DeviceNet is elke deelnemer op het netwerk verantwoordelijk voor het managen van zijn eigen CAN-identifiers. Dit betekent, dat bij uitbreiding van een netwerk, de nieuw toegevoegde node, zichzelf kenbaar maakt en zoekt naar identifiers voor communicatie. Evenals bij CANopen is er bij DeviceNet ook weer sprake van deviceprofielen. Hierin staat het object volledig beschreven, met klassen, instanties en attributen. Toepassingsgebieden: DeviceNet wordt vooral gebruikt in industriële automatisering, in low- and mid-volume automation systems en ook soms in controlesystemen voor machines. Het heeft dus zijn plaats veroverd in o.a. volgende sectoren: • Industriële automatisering • Industriële machinecontrole • Maritieme elektronica • Niet-industriële automatisering Voor meer info: http://www.odva.org/ NCC-2011-001

KdG–IWT

Automotive Software


55

3.4.4.4 Smart Distributed Systems

ot eHo

ge s

ch o

ol

Dit standaard protocol is ontwikkeld door Honeywell. Deze firma voert ook zelf het beheer over dit protocol en misschien daarom is het minder open dan de twee voorgaande protocollen. Er zijn overigens evenals bij CANopen en DeviceNet wel een groot aantal andere leveranciers, die het protocol ondersteunen met hun devices. De devices, die op een SDS netwerk aangesloten worden, zijn meestal sensors of eenvoudige I/O modules. Er moet dan ook altijd een master in het netwerk zijn. Dit kan een PC of PLC zijn. We kennen ook hier weer twee soorten berichten. De statusveranderingen (Change of state, alarm en set-reset signalen voor actuatoren) en berichten waarmee we andere informatie uit een sensor of I/O-module willen opvragen of invoeren. Dit geldt dan binnen het SDS protocol vooral signalen betreffende diagnostische of andere sensorspecifieke data. Het protocol is duidelijk geoptimaliseerd voor een sensor-/actuatorbus en vindt zijn toepassingen vooral in grotere conveyersystemen, waar sensoren als foto-cellen en benaderingsschakelaars in grotere getale worden toegepast. Voor meer info: http://content.honeywell.com/sensing/prodinfo/sds/

Gr

3.4.4.5 CANaerospace

Ka re

ld

e

CANaerospace wordt ondersteund door een groeiend gemeenschap binnen de Europese vliegtuigindustrie en deze van de USA. Ze wint nog steeds aan succes. Het grote succes van de CANaerospace standaard is dat deze standaard de problemen van elektronica in vliegtuigen aanpakt en vormt daardoor ook de CAN-applicatielaag voor de vliegtuigindustrie. Vooralleer CANaerospace ontwikkeld en gebruikt werd in vliegtuigen, zijn vele andere bestaande CAN Higher Layer Protocols onderzocht voor toepasbaarheid in de vliegtuigindustrie maar geen een werd geschikt bevonden voor de vliegtuigspecifieke vereisten. CANaerospace omvat niet enkel de CAN-applicatielaag maar behandelt ook hardware-zaken zoals connectoren, kabels, maximale EMI, ...

11

Voor meer info: http://www.canaerospace.com

20

3.4.4.6 MilCAN

py rig

ht

MilCAN is een open standaard die de interconnectie verzorgt tussen verschillende subsystemen in militaire voertuigen Voor meer info: http://www.milcan.org/

Co

3.4.4.7 ISObus

Deze standaard richt zich op de landbouwsector. De standaard was nodig opdat alle bedrijven die in deze sector betrokken zijn nood hadden aan een standaard, van de grote marktleiders to de nichetoeleveranciers. De IsoBus zal in heel de sector gebruikt worden en nu reedsis men bezig met de overgangsmaatregelen om de hele sector de IsoBus te laten gebruiken. Voor meer info: http://www.isobus.net/

NCC-2011-001

KdG–IWT

Automotive Software


3.5 3.5.1

56

de LIN bus: Local Interconnect network Overzicht

Fysieke laag

ot eHo

3.5.2

ge s

ch o

ol

De LIN-bus is een klein en traag netwerk dat kan gebruikt worden om sensoren uit te lezen en actuatoren aan te sturen op een zeer goedkope manier. Ze wordt voornamelijk gebruikt als aanvulling van andere netwerken, daarom wordt ze ook wel de LIN-subbus genoemd. De LIN standaard (op dit ogenblik versie 2.1) wordt ontwikkeld door het LIN-consortium waar de meeste europese autoconstructeurs aan mee werken. Applicaties voor de bus zijn onder andere de regeling van spiegels, bediening van ramen,... LIN is een allesomvattend concept dat de fysieke laag, datalink-laag, transport laag en applicatielaag beschrijft in de standaard.

ht

20

11

Ka re

ld

e

Gr

LIN specifieert een bittijd van 1 tot 20 kbit/s. De LIN bus bestaat uit een bidirectionele enkele draad (de LIN bus) die aangesloten is op de transceiver van elke LIN-node en verbonden is via een weerstand (en eventuele diode) met de positieve batterij spanning. Zie figuur 3.38

Figuur 3.38: LIN Node

Co

py rig

Voor de correcte transmissie en ontvangst van een bit, moet het signaal op de bus staan met de juiste spanningsniveau’s op het tijdstip van samplen. Massa verschuivingen en een val van de batterijspanning moeten in rekening worden gebracht.

Figuur 3.39: LIN spanningsniveau’s Het netwerk bestaat uit een master en verschillende slaves (max 15). De master heeft een keramische of kristallen klok terwijl de klok van de slaves mag bestaan uit een RC-oscillator. Het synchronistatie NCC-2011-001

KdG–IWT

Automotive Software


57

veld zorgt voor de baudrate stabiliteit.

ot eHo

ge s

ch o

ol

Het sync veld bestaat uit een byte met data 0x55. De tijd tussen 2 vallende flanken van een bit moet gemeten worden en gedeeld worden door het aantal bits. Deze flanken komen om 2,4,6 of 8 bits voor. Elk van deze kan gebruikt worden om te synchroniseren.

Figuur 3.40: Synchronisatie veld

e

Datalink laag

ld

3.5.3

Gr

Elke byte wordt verzonden tussen een starten stopbit (Buiten het break-veld: zie verder). Low level synchronisatie gebeurt door middel van de vallende flank van de startbit.

Co

py rig

ht

20

11

Ka re

Zoals reeds aangegeven bestaat een LIN netwerk uit een enkele master en meerdere slaves. Een frame bestaat steeds uit een header gedeelte dat steeds door de master verzonden wordt. De master of een enkele slave kan hierop een response sturen. De nodes worden gepolled. De slave (of master node) die de data stuurt noemen we de „publisher”. Alle andere nodes kunnen zich inschrijven om de data te ontvangen.

Figuur 3.41: LIN Frame

• Break veld: Dit veld duidt het begin van een frame aan. Het bevat minstens 13 bits van de dominante waarde gevolgd door een break-delimiter van een enkele recessieve bit. Een slave node gebruikt een drempelwaarde van 11 opeenvolgende dominante bits om dit veld te detecteren. • Synchronisatie veld: Door de opeenvolgende 01 combinatie kan de slave node synchroniseren op de klok van de master node. NCC-2011-001

KdG–IWT

Automotive Software


58

• PID: Het protected Identifier veld bestaat uit volgende delen: – Frame Identifier: De eerste 6 bits bevatten de frame-identifier. Deze geeft de inhoud van het frame weer.

ol

* 0 - 59: gebruikt om signalen over te dragen * 60 - 61: Diagnostische en configuratie data * 62 - 63: Gereserveerd voor toekomstig gebruik

ch o

– Pariteitsveld: 2 bits. De pariteit wordt berekend door volgende formules:

ot eHo

ge s

* P 0 : ID0 ⊕ ID1 ⊕ ID2 ⊕ ID4 * P 1 : ¬(ID1 ⊕ ID3 ⊕ ID4 ⊕ ID5)

Figuur 3.42: LIN PID mapping

Gr

• Data: Een frame bevat tussen de 1 en 8 databytes. De Least Significant Byte wordt eerst verzonden (little endian).

Ka re

ld

e

• Checksum: We onderscheiden 2 types checksum: de standaard en exteded versie. De standaard versie wordt enkel berekend over de databytes terwijl de extended eveneens de PID meerekent. Bij LIN1.x nodes en LIN2.x frames met ID 60-63 wordt de standaard versie gebruikt. Bij de gewone communicatie met LIN2.x nodes wordt de extended versie gebruikt.

11

Tussen elke byte is er een interbyte spacing door interrupt latency en software runtime in de node. Tussen de header en responons is er een response space.

20

3.5.3.1 Timing en Scheduling

Co

py rig

ht

De master node regelt de communicatie met de andere nodes door een time-triggered shedule te gebruiken. De slaves kennen dit schema niet en geven enkel een respons wanneer ze gepolled worden. Dit wordt geïmplementeerd aan de hand van schedule tables. Meerdere schedule tables kunnen aanwezig zijn in de master node. De applicatie van de master node initialiseert deze. Een actieve schedule table wordt cyclisch herhaald. De timing hangt af van de timebase, jitter en slot delay. De timebase is de timer van de master node. Jitter is de tollerantie van de schedule taak binnen de masternode. Slot delay zorgt ervoor dat de slave voldoende tijd heeft om z’n respons te versturen (inclusief de jitter die ontstaat in de slave node).

Figuur 3.43: LIN Schedule voorbeeld

NCC-2011-001

KdG–IWT

Automotive Software


59

3.5.3.2 Frame Types • Unconditional Frame (ID 0 - 59): Dit is het standaard LIN frame type. Het wordt gebruikt voor cyclische communicatie tussen de verschillende LIN-nodes. Het frame-ID wordt geassocieerd met een enkele respons van een publisher. Dus slechts 1 node kan het antwoord formuleren.

Ka re

ld

e

Gr

ot eHo

ge s

ch o

ol

• Event triggered frame (ID 0 - 59): Dit frame type wordt geassocieerd met meerdere nodes die events hebben die zelden voorkomen. Ze moeten wel dezelfde lengte hebben en mogen geen signalen in de eerste databyte hebben. Deze bevat de PID van het unconditional frame dat gelinkt is aan de data van het event triggered frame. Er wordt enkel een respons gestuurd als de data na de laatste polling is upgedate. Indien er collision voorkomt op de bus, gaat de master node over in een collision resolution schema. Hij polled de unconditional PID’s die ge-linkt zijn aan het event triggered frame afzonderlijk. Een voorbeeldje verduidelijkt dit: Er bestaat een event triggered frame met ID=0x10. Het event-triggered frame is gelinkt aan 2 unconditional frames met id 0x11 en 0x12. Het collision resolution schema bevat de unconditional frames. Zie figuur 3.44.

11

Figuur 3.44: LIN Collision resolution voorbeeld

py rig

ht

20

• Sporadische frames: Sporadische frames zijn een groep van unconditionele frames. Ze worden enkel gestuurd wanneer de signalen binnen de data zijn upgedate. Sporadische frames worden enkel door de master gestuurd. Wanneer meerdere frames zijn upgedate, wordt enkel diegene met de hoogste prioriteit verzonden. De andere moeten wachten tot het volgende sporadische frame mag worden verzonden.

Co

• Diagnostische frames (ID 60 - 61): Het frame met ID 60 wordt enkel verzonden door de master. Het bevat in de eerste byte de PID van een slave die op het volgende frame met PID 61 een respons moet toevoegen. Verder bevat het configuratiedata en diagnose informatie. De frames hebben steeds 8 databytes. • Gereserveerde frames: Voor toekomstig gebruik.

3.5.3.3 Netwerk Management Het netwerkmanagement aspect van LIN bevat het in slaap doen van de cluster en het wekken van de cluster. Elke node binnen de LIN-cluster mag het netwerk wekken. Het wakeup bericht bestaat uit een periode van 250 µs tot 5 ms dominante (0) bits. De andere nodes ontvangen dit bericht en zullen NCC-2011-001

KdG–IWT

Automotive Software


60

na 100 ms klaar staan om berichten te verzenden en ontvangen. Indien de master node na een periode van 150 ms geen break-veld stuurt, zal de node opnieuw overgaan tot het opwekken van de bus (de master node is niet wakker geworden). Indien er na 3 maal nog steeds geen antwoord volgt, zal de node een langere periode wachten (groter dan 1,5 seconde).

ch o

ol

Enkel de masternode kan de cluster doen inslapen. Hij doet dit door een diagnose bericht(PID: 60) te sturen met het commando go-to-sleep, databyte 0 staat op 0x00 terwijl de rest op 0xFF.

3.5.3.4 Status management

ge s

De bedoeling van status management is het detecteren van fouten. De bedoeling is 2-voudig:

ot eHo

• Vervangen van defecte nodes vergemakkelijken.

• De nodes in een limp-home toestand plaatsen wanneer er een fout gevonden wordt.

ld

Transport laag

Ka re

3.5.4

e

Gr

Het status management systeem wordt in de masternode geïmplementeerd. Hij leest hiervoor een bepaalde status bit die door de slave nodes wordt gepubliceerd in een unconditional frame, de zogenaamde response-error bit. Wanneer de slave node een fout detecteert zet hij deze bit op 1. Hierdoor kan de masternode enkele conclussies trekken over de status van het netwerk.

Applicatie laag

20

3.5.5

11

De LIN-standaard definieert een transport laag die gebruikt wordt voor diagnose van de subbus via het CAN-netwerk. Dit valt echter buiten het bestek van deze cursus. Indien men hier toch meer over wenst te weten: http://www.lin-subbus.org

ht

LIN defineert een API die de onderliggende details van het netwerk afschermt voor de applicatieprogrammeur. De API is opgesplitst in 3 secties:

py rig

• Core API: initialisatie, verwerking en signaal gebaseerde interactie tussen de verschillende nodes op het netwerk. • node configuratie API

Co

• transport laag API (optioneel) De volledige API kan je bekijken in de LIN standaard: http://www.lin-subbus.org.

3.6

ByteFlight

Byteflight is een protocol ontwikkeld door BMW in samenwerking met verschillende semiconductor bedrijven waaronder motorola (tegenwoordig Freescale) en Siemens Semiconductors (tegenwoordig NCC-2011-001

KdG–IWT

Automotive Software


61

Infineon). Het adresseert vooral toepassingen rond passieve veiligheid. Het wordt door BMW gebruikt voor de communicatie tussen de verschillende modules voor het ABS-systeem en voor een shift-by-wire systeem in de BMW-7 serie. Andere toepassingen bevinden zich in de aeronautische industrie.

ol

Hoewel dit protocol in de toekomst niet (veel) meer gebruikt gaat worden is het interessant om het toch te bespreken. Dit om de evolutie te begrijpen die zich heeft afgespeeld in de automotive datacommunicatie.

Co

py rig

ht

20

11

Ka re

ld

e

Gr

ot eHo

ge s

ch o

De Byteflight standaard beschrijft de fysieke laag en datalink laag van het OSI-model. Speciale aandacht bij het opstellen van de specificaties is uitgegaan naar snelheid, determinisme en excellente data integriteit. Dit is noodzakelijk bij netwerken voor veiligheidsgerelateerde toepassingen.

NCC-2011-001

KdG–IWT

Automotive Software

F2000G316

Seoul 2000 FISITA World Automotive Congress June 12-15, 2000, Seoul, Korea

ch o

Josef Berwanger* , Martin Peller, Robert Griessbach

ol

byteflight A New Protocol for Safety Critical Applications

BMW AG, EE-211 Development Safety Systems Electronics, Knorrstrasse 147, 80788 Munich, Germany

Gr

ot eHo

ge s

There is a clear trend in automobile development towards using electronic systems instead of mechanical components and towards realizing an increasing number of convenience and safety functions while at the same time taking into consideration the environment. Consequently, vehicle electronics are becoming increasing complex and the number of functions, sensors, and actuators is growing fast. These requirements cannot be met with a central control unit. The solution is to network the various electronic modules using a high-performance data bus. This makes it possible to reduce the complexity of the wiring and to make multiple use of sensor data in order to integrate the individual functions in such a way that they form an intelligent overall vehicle. The high-performance bus required to make this possible is now available: Together with the companies Motorola, ELMOS, Infineon and Tyco EC, BMW AG has developed the byteflight high-performance data bus for safety-related applications. Fully integrated, inexpensive electronic components are already available for the construction of a complete bus system based on fiber optics technology. The first application in highvolume automobile production will start within the next year and will include passive-safety and body functions. Keywords: High Speed Databus Protocol

Data-transmission methods that have been available until now have been either event-controlled or timecontrolled. Event-controlled (or asynchronous) protocols (e.g. CAN) only transmit data when a transmission request is

The basis for byteflight data communication (2) is formed by cyclical synchronization pulses (SYNC pulses). These pulses make a common time-base available for all

e

2.1 DATA TRANSMISSION METHOD

present. Bus access is usually controlled either by priority or by chance. Nevertheless, latency times can only be determined statistically, and are therefore not suitable for hard real-time requirements. The advantage of this new protocol is the flexible use of the bandwidth by different nodes and the ease of system expansion. Data protocols that are purely time-controlled (synchronous, e.g. TTP) grant transmission time to each node in accordance with a pre-defined sequence. With this protocol, the latency times for the messages are deterministic. The number of messages is prescribed by the number of time slots, and therefore cannot generally be changed during operation. Assignment of the bandwidth to different nodes is permanent, so that later expansion to include new nodes or new functions require reconfiguration of the entire system. The byteflight protocol unites the advantages of the synchronous and asynchronous methods. It guarantees deterministic latencies for a specific number of highpriority messages and flexible use of transmission bandwidth for low-priority messages. For special cases, it is possible to configure the software driver to allow a purely synchronous or purely asynchronous operating mode. Furthermore, the protocol permits easy expansion and adaptation for different variations in the equipment and functions. The transmission rate of 10 Mbps should meet the high requirements of next vehicle generations.

ld

1 INTRODUCTION

Co

py rig

ht

20

11

Ka re

A data bus system that is to be used in safety-related areas must satisfy the highest requirements concerning transmission rate, reliability and interference immunity. To make it possible to integrate safety-related functions, the data protocol must be fault-tolerant and deterministic, and must feature excellent data integrity. Another fundamental prerequisite for such a system is for it to be compatible with the current background issues of automobile development (such as ever-shortening development periods, fast reaction times for new market requirements, consideration of many different vehicle and equipment variations, modular construction optimized for installation space, and high quality standards with low system costs). Good diagnosis capabilities for effective service demand flexible utilization of the bandwidth. Easy expansion capability is required to accommodate the rising number of functions. Since none of the previously known data protocols were able to meet all of these requirements, BMW has developed the byteflight high-performance data bus system (1)**.

2 DATA COMMUNICATION

* **

2.2 FTDMA (FLEXIBLE TIME DIVISION MULTIPLE ACCESS)

Corresponding author. e-mail: [email protected] Numbers in parentheses designate references at the end of paper. 1

Synchronization Pulse cycle time t_cyc = 250 µs

1

2

3

4

...

30 wait time 220 t_wx

3

20

wait time t_wx

95

150

ID=3

Figure 1 - Flexible Time Division Multiple Access - FTDMA The slot counters for nodes A and B are shown. Node A sends identifier 4, node B sends identifiers 1 and 7. Transmission slots 1, 4, and 7 (shown here in red) last as long as necessary to transmit the message. Since there are no transmission requests present for identifiers 2 and 3 in this cycle, slots 2 and 3 are not used and appear only as very short waiting slots (shown here in green). For a message to be sent in a cycle, its transmission request must have been present at the rising edge of the sync pulse for that cycle. The waiting period between the message with identifier IDt-1 and the following message with identifier ID can be calculated with the following formula (2):

ot eHo

ge s

ch o

ol

nodes and for the application software. Any byteflight node can be configured as a SYNC master that generates the clock base for all nodes. The cycle time is the time interval between the synchronization pulses. In the current implementation of byteflight, this interval is set to 250 µs at data rate of 10 Mbps (Figure 1). In between the synchronization pulses, all nodes can send messages. In this process, all nodes are on the same footing. Bus access is governed autonomously and timecontrolled by the protocol controller implemented in the hardware. This is done in such a way that an ascending identifier sequence occurs within a cycle. An arrangement for all bus system nodes establishes that an identifier may only be used by one single node. This ensures that there are no collisions on the bus. The bus protocol controller, which works autonomously from the host CPU, also ensures that a single given identifier is not sent more often than once per cycle. The point of time for bus access is controlled solely by the bus controller, and cannot be influenced by the host CPU. The CPU can only present the data to be transmitted via a Dual Port RAM, or read out the received data. Bus access is regulated according to the Flexible Time Division Multiple Access method (FTDMA). With this method, all nodes start ‘slot counters’ that are triggered by the synchronization pulse. The slot counters begin at zero and count up to the highest identifier value possible. When a slot counter reaches an identifier value for which a transmission request is present, the corresponding message is transmitted via the bus, and all the slot counters stop at the current value for the duration of the transmission. Once the transmission is complete, the slot counters begin to count upwards again. Figure 2, which was recorded with a logic analyzer, shows an example of this transmission process (3).

Waiting period t_wait = t_0 + t_delta * (ID - ID t-1)

ht

20

11

Ka re

ld

e

Gr

The fixed portion of the waiting period t_0 is used for maintaining the minimum interval of 1100 ns between two messages. Since the optimal values for t_0 and t_delta are derived from the signal propagation delays within a bus system, these parameters have been made programmable in the byteflight modules. The FTDMA procedure described above is thus a purely time-controlled bus-access process. Nevertheless, it allows the guaranteed or deterministic transmission of a specific number of high-priority messages in every communication cycle even when the bus capacity is fully used, and simultaneously permits flexible and statistic assignment of the bandwidth for the rest of the messages if bus load is low enough. This can also be seen in Figure 3. In the operational mode depicted, the 10 highest-priority messages are transmitted synchronously and cyclically every 250 µs. The second portion of the communication cycle can be used for event-controlled messages.

A: B:

Co

A:

py rig

SYNC

0

20

40

60

80

100

120

140

160

B:

transmit slots:

01

04

07

Zoom between ID=1 and ID=4

01

short wait slots:

02 03

Figure 2 - Distributed synchronized slot counters 2

04

t / µs

1

2

3

... 10

35

1

2

high priority messages

3

... 10

38

75

time slots for low priority messages, e.g. convinience, diagnosis

Figure 3 - Synchronous and asynchronous transmission

ch o

ge s

ot eHo

2.3 MESSAGE STRUCTURE

Ka re

ld

e

Gr

byteflight messages (Figure 4) consist of a 6-bit starting sequence, an identifier byte, a length byte, up to 12 data bytes, and two CRC (Cyclic Redundancy Check) bytes. The CRC used ensures a hamming distance of h = 6 to provide a high level of data integrity. For bit synchronization, each byte is framed by one start bit and one stop bit. The bit length is 100 ns at a gross data rate of 10 Mbps.

2.4 REDUNDANT SIGNAL CHANNEL FOR THE ALARM STATUS

levels and error-handling strategies based on this. Only messages that have been received with a valid CRC are made available for the host CPU to read. Due to the optical data transmission that is available, a star network topology is used in the pilot application. In addition, a specially developed star coupler module makes it possible to shut off nodes that, for example, do not follow the bus protocol or cause transmission errors. Thanks to their steady light shut-off function, the optical transceivers can prevent the bus being blocked by a permanently on transmitter. With bus topologies, it is not possible to shut off faulty nodes from a central point. Here, however, thanks to the purely time-controlled access, the decentralized use of a bus guardian with its own clock supply is possible at every node. If the SYNC master, and thus the synchronization pulse, fails to function, a specific node (substitute SYNC master) can be configured by its µC as a master. This node then sends the sync pulses, and the data transmission is guaranteed. Additionally, it is possible to select a redundant system configuration. Two byteflight clusters can, for example, be operated in parallel, each having a SYNC master.

ol

Despite the guaranteed transmission of a specific number of high-priority messages, flexibility is not lost. This is a factor of growing importance as development periods shorten and the number of vehicle and equipment variations rise. In this way, it is possible to add highpriority messages, and the guaranteed transmission of these messages can be proved analytically. It is also possible to add asynchronous messages. In this case, verification of the latency times can be accomplished via statistical observations, as with the CAN protocol, for example. It is not necessary to make software changes at nodes that are already used in the system.

20

11

The byteflight protocol offers another special characteristic that is particularly necessary for passive safety systems: To show an alarm or arming status, the SYNC master has the capability of changing the type of synchronization pulse that is used. This status is recognized by all byteflight controllers and the physical driver modules, and can be used to enable specific safety functions. The switching of the synchronization pulse has no impact on the communication sequence or protocol behaviour.

ht

2.5 STRATEGIES FOR ERROR HANDLING

Co

py rig

Since the data transmission of safety-related signals is generally cyclical and has an update rate of 250 µs, there is no repeat mechanism at protocol level for transmission errors. The protocol has been configured such that at the latest, even when there is heavy interference, communication resumes when the next synchronization pulse is sent. Furthermore, in order to detect even the smallest deviations of the clocks in the byteflight nodes, there are high-performance mechanisms for recognizing synchronization errors at both the cyclical and message

3 AVAILABLE BUS CONTROLLERS For the design of a byteflight node, a Motorola MC68HC912BD32 with an integrated byteflight controller (4) can be used. The 16-message buffer can be freely configured as a transmission buffer, FIFO-receive buffer or dedicated receive buffer. The FIFO-receive function also has a programmable acceptance filter. Each dedicated receive buffer filters just one specific identifier out of the flow of data and always contains the most up-todate message for this identifier. The microcontroller is available in an 80-pin QFP package and is compatible with the pins and software of Motorola’s 68HC912B family. The controller has 1 kByte of RAM, a 768-Byte EEPROM and 32-kByte flash EEPROM. The flash memory can be programmed via a bus download and therefore makes it possible to perform a quick software update for the vehicle without the time-consuming step of removing the control units. bus idle

bus idle t_bit = 100 ns

ID

LEN

D0

D11

CRCH

CRCL

2x ‘0’ bits at message end

start sequence

Figure 4 - Message format 3

7,7 mm

ELMOS 100.34 IC

VDD2 Al

ch o

transmitter LED mounted on receiver diode

ol

Chip On Chip:

DI VDD1 GND DO

ge s

Infineon 6 pin package

ot eHo

Figure 5 - Optical transceiver for bidirectional transmission

transceiver module. This module (Figure 5) contains the LED driver circuit and the receiver amplifier with peak detection for transforming the photo-current into digital levels. There are also several logical functions (such as a shut-off for constant light, and detection of the synchronization pulse). Furthermore, there is an integrated optical diagnostic function for monitoring the optical transmission quality. The transceiver’s light-emitting diode (LED) and photodiode are mounted one above the other using chip-on-chip technology in order to achieve optimal coupling of both components with the optical fiber. The transceiver modules have been integrated directly into the control unit plug connector, since optimization of the coupling losses was to be combined with the elimination of the need for a cost-intensive adjustment process. To make this possible, Tyco EC (formerly Siemens EC) – working in close cooperation with BMW – and Infineon designed a special transceiver housing (8) that significantly simplifies installation of the plug connector and simultaneously permits very precise positioning of the cable’s plug-in elements. Furthermore, new cable harness components and production processes were jointly developed in order to make it possible to realize reliable and cost-effective mass production with conventional, fully automatic equipment while simultaneously meeting the high requirements for processing reliability and the capacity for handling mechanical and thermal loads. Figure 6 shows the schematic diagram of a byteflight network. The active star coupler consists of the ASIC E100.39 (9) from ELMOS. It receives the bus signals from the individual nodes via the transceiver, performs a logical AND operation, and then distributes the signals back to all nodes. It is also possible to link nodes to the ASIC star coupler electrically. The star coupler offers the errorhandling and optical diagnosis possibilities that were described earlier. It is located in a 64-pin QFP package and makes it possible to link together 22 nodes, to read out diagnosis information via an SPI interface, to turn off the connected nodes individually (prevention of a bus blockade caused by a “babbling idiot”), and to regenerate the signal pulse form.

ld

e

Gr

The E100.38 standalone byteflight controller (5) available from ELMOS is register-compatible to the HC12BD32. It offers the possibility of building up byteflight control units using other processor types from the HC12 family, Motorola PowerPC, Siemens C16x, or other microcontrollers commonly available on the market. The standalone controller is housed in a 44-pin QFP package. All modules support optical diagnosis, optical wake-up via the data bus, and sleep modes. A standby current lower than 50 µA per byteflight node is reached.

Ka re

4 TOPOLOGY

Co

py rig

ht

20

11

Due to the high data rate, the issue of electromagnetic compatibility takes on special significance. Electrical links would have to be protected against external influences by implementing special measures during the manufacturing of the vehicle harness. This is usually accomplished by using shielded or twisted cables. Despite the high production complexity (and thus expense) associated with this, it does not provide electrical isolation of the individual components. For this reason, a physical layer was developed based on plastic optical fiber (POF) technology and implemented as a star topology. For data bus systems, optical transmission has the advantage that it remains undisturbed by electromagnetic interference. Additionally, connected system components are electrically isolated from one another, which rules out the possibility of the individual modules influencing each other in an undesired manner. Thanks to the star-shaped bus structure, the rest of the network (with all safety components) is still fully functional when one of the system components is removed. The individual nodes are connected together via fiberoptic cables and an active star coupler. The fiber-optic lines are operated bidirectionally using half-duplex transmission. In order to connect each node, there is an optical transceiver module (6) made by Infineon (formerly Siemens Semiconductor) inside the star coupler. Transmitting and receiving diodes, and the ELMOS E100.34 (7) transceiver chip are integrated into this

4

Tx

Star Net Coupler Rx

Tx

Rx

Rx

Optical Transceiver Optical Transceiver Optical Transceiver

POF

POF

POF Optical Transceiver

Rx

Tx

Rx

byteflight

µC (Motorola, Siemens, etc.)

µC HC12BD32 (Motorola)

ot eHo

ge s

(ELMOS 100.38)

byteflight controller

ch o

Optical Transceiver Tx

byteflight controller µC HC12BD32 (Motorola)

ol

Tx

(ELMOS 100.39) Tx Rx

ECU Type 2

ECU Type 1

Figure 6 - Example of a byteflight topology

5.1 byteflight DEVELOPMENT TOOLS

e

Gr

important for the deterministic behavior of distributed safety-related and closed loop control systems. Using the synchronization pulses, which are transmitted at 250-µs intervals, the byteflight bus protocol makes a time base (accurate to 100 ns) available to the applications. With this signal, both the hardware and software can be synchronized at all network nodes involved – independently of the software. The sync pulse is used to initiate the synchronous (high priority) software routines; then the asynchronous (low-priority) routines are processed in the remaining cycle time. In the synchronous portion, no interrupts are permitted, but they are permitted in the asynchronous portion of the software. In order to support fast processing of the high-priority routines, the high-priority messages are received in the dedicated receive buffers, while the low-priority messages are received in the FIFO mode. The dedicated receive buffers always contain the most up-to-date data received, and a bit in a control register indicates the arrival of a new message. Since the application software knows the identifier and the length of the high-priority messages, the point of time when the message arrives can also be determined with great accuracy. When a message is not transmitted (for instance, when a node fails), only the short time period of a waiting slot passes before the next message can be transmited, instead of the longer time period of a transmission slot. Consequently, the messages that follow are sent earlier than they would be if the system did not have a fault. This results in reception jitter of 5 to 17 µs, depending on message lengths. Since the application software knows how “old” the data is (the data has to be entered into the transmission register before the synchronization pulse) this avoids any disadvantage in the functioning of control loops or the time behavior for safety-related applications. Thanks to the protocol’s deterministic behavior for high priority messages (which can be transmitted in every cycle) and to the fact that the reception jitter caused by the failure of a message is insignificant, the system has a good composability in the

ld

5 DEVELOPMENT TOOLS AND TEST METHODS

Ka re

As an alternative, the bus protocol permits the electric linking of all nodes (when using suitable physical drivers) to form a bus topology. To accomplish this, the transmission rate must be lowered, since there are currently no suitable electrical transceivers available for automotive applications that permit a transmission rate of 10 Mbps.

py rig

ht

20

11

There are many development tools available. For example, there is a bus analysis device that permits online analysis, recording (with off-line analysis afterwards), and simulation the bus traffic. All the analysis device’s functions can be controlled with the aid of a userprogrammable DLL interface; this makes it possible for the device to be integrated into the developer’s own simulation and test environments. The device is connected to the byteflight network optically, or – for laboratory tests – via an electrical interface. Beyond that, the IXXAT company is currently developing a PCMCIA card with byteflight and two CAN interfaces, and a byteflight analyzer tool based on the IXXAT CAN -Analyzer.

5.2 byteflight CONFORMANCE TEST

Co

In order to guarantee the compatibility of the two byteflight implementations, Motorola HC12BD32 and ELMOS E100.38, a byteflight conformance test was developed together with Steinbeis Transferzentrum Prozessautomatisierung. This test compares the implemented protocol in each case with the specification. Both byteflight implementations have already been successfully in use together in test vehicles for some time now.

6 SOFTWARE STRUCTURE The clock synchronization of all bus nodes is very 5

E100.38 standalone controller and a high-performance microcontroller, and is already working in test vehicles.

time domain. The time behavior at the communication level is independent from the time behavior of the application software.

9 EXAMPLES OF APPLICATIONS

7 FLEXIBILITY

Due to its deterministic behavior and high data rate, the byteflight protocol is suitable for applications in the area of passive safety, and thanks to the high level of flexibility, it is suited for body and convenience functions. The protocol can also be used in active safety applications. In order to reach the fault-tolerance levels required by such applications, the corresponding redundancies must be planned into the system configuration. Variations that can be used to accomplish this include a doubling of the network so that each node has two controllers (such as an HC12BD32 and a standalone E100.38), two transceiver modules, two fiberoptic interfaces and two star couplers available (Figure 7). The transmission rate of 10 Mbps and high level of immunity to electromagnetic interference made possible by optical transmission, offer tremendous advantages for the use of the byteflight data bus system in industrial automation and in the aerospace industry. Due to the large production volumes that occur in the automobile industry, this system also features considerable cost advantages over current technologies.

ot eHo

ge s

ch o

ol

byteflight permits simple expansion of a system by adding further functions to control units that are already in place, or by incorporating more bus nodes (for example, optional equipment). The system can be supplemented by new messages without the software of existing control units having to be adapted. The system’s expansion characteristics allow a high level of flexibility in production (different equipment variations with the same sub-assemblies). They also make it possible to use the same control units in different model series and with different configurations of the vehicle electrical system.

8 GATEWAY: NETWORKING WITH OTHER DATA BUSES

Gr

The growing complexity of future motor vehicles and the constantly rising demands on the performance of the vehicle communication system have led to a situation in which networking of the control units can no longer be accomplished with a single data bus. In order to limit the bus load and adapt the performance capabilities of a data transmission to the given requirements, it makes sense to consolidate certain functional areas to form sub-systems and to join the sub-systems together with a data bus to form a network. The need to exchange vehicle-specific data between the individual sub-systems or to ensure the overall diagnosis of all control units in all sub-systems using a single diagnostics interface, makes it necessary to connect the buses using a gateway. For system integration it is very important, that the byteflight protocol supports all services of the internationally standardized KWP2000 (Keyword Protocol 2000). Such a gateway function for two CAN buses with different transmission rates, one diagnostics line, and byteflight has already been realized with the aid of the

py rig

Star Net Coupler

ht

20

11

Ka re

ld

e

10 CONCLUSIONS

OT

OT

POF

Star Net Coupler

µC HC12 BD32

OT

Co

Tx

Rx

byteflight 1

POF

OT 2 Tx

OT 1

OT 2

Rx

Tx

byteflight 2

µC (Motorola PPC, Siemens 16x, etc.)

µC HC12 BD32

OT

POF

POF

OT 1

The deterministic behavior of the byteflight protocol, flexible use of bandwidth, expandability of the system, high data transmission rates and data integrity, high level of communication interference immunity made possible by fiber-optic transmission, the possibility of download via the data bus, and the capability of online diagnosis predestine this protocol to become a transmission protocol standard in the automotive arena (Table1). The first use of byteflight in mass production will take place at BMW within the next year in a networked passive safety system, into which body and convenience equipment functions have also been integrated.

Tx

OT - Optical Transceiver POF - Plastic Optical Fiber ECU - Electronic Control Unit

ECU Type 1

Rx

byteflight 1 µC (HC12BD32) ECU Type 2

Figure 7 - Redundancy concept 6

Rx

byteflight 2

Table 1 - Comparison of CAN / TTP / byteflight Feature

CAN

TTP (10)

byteflight

Message transmission Message identification Data rate

asynchronous

synchronous

message identifier

time slot

asynchronous and synchronous message identifier

1 Mbps gross up to 58 % net NRZ with bit stuffing

2 Mbps gross up to 37 % net modified frequency modulation (MFM) not defined

Clock synchronization Temporal composability Error containment (physical layer) Babbling idiot avoidance Extensibility

not provided

Flexibility

flexible bandwidth for each node several µC families and transceiver chips

not supported partially provided

ol

ch o

provided with special physical transceiver possible by independent bus guardian only if extension planned in original design

not provided

Gr

excellent

only one message per node and TDMA cycle microcoded RISC chip available, physical transceiver and independent bus guardian not available

11

Ka re

Availability of components

distributed, in µs range supported

ot eHo

constant for all messages

e

Latency jitter

ge s

transceivers up to 1 Mbps bus load dependent

Physical layer

ld

Bit encoding

extension possible for high priority messages with affect on asynchronous bandwidth flexible bandwidth for each node HC12BD32, E100.38 byteflight standalone controller, E100.39 star coupler ASIC, optical transceiver available

[7] ELMOS AG, Product Specification E100.34.

20

REFERENCES

10 Mbps gross up to 53 % net NRZ with start/stop bits optical transceiver up to 10 Mbps constant for high priority messages according t_cyc by master, in 100 ns range supported for high priority messages provided by optical fiber and transceiver chip provided via star coupler

[8] O. Schoenfeld, Transceivers for in-car optical buses, POF Conference 1999, Tokyo.

[1] R. Griessbach, J. Berwanger, M. Peller: byteflight neues Hochleistungs-Datenbussystem für sicherheitsrelevante Anwendungen, ATZ/MTZ „Automotive Electronics“, January 2000, Friedrich Vieweg & Sohn Verlagsgesellschaft mbH.

ht

[9] ELMOS AG, Product Specification E100.39.

py rig

[10] Handouts, TTA/X-By-Wire Workshop, Vienna, December, 3rd 1998.

[2] BMW AG, EE-211, byteflight Specification.

APPENDIX

[3] BMW AG, EE-211, Workshop SI Bus Publication, Munich, May 6th 1999.

More details about the byteflight protocol, the protocol specification, the controllers and the optical transceiver are available via:

Co

[4] Motorola, 68HC912BD32TS/D Technical Summary. [5] ELMOS AG, Product Specification E100.38.

http://www.byteflight.com

[6] Infineon/ELMOS, Specification for SPFOBI 002 Transceiver.

7


TTP: Time Triggered Protocol

Co

py rig

ht

20

11

Ka re

ld

e

Gr

ot eHo

ge s

ch o

ol

3.7

69

NCC-2011-001

KdG–IWT

Automotive Software

ol

Introduction to TTP/C and TTP/A

ge s

ot eHo

Gr

Complemental to such a communication system will be a transducer bus that provides an interface to the various sensors and actuators of such a system. Besides real-time capabilities such a transducer bus must also support non-real-time access for configuration and maintenance. It is the objective of this paper to describe two time-triggered protocols that fulfill the above described requirements. The TTP/C protocol provides a highly dependable real-time communication service with a fault-tolerant clock synchronization and membership service. TTP/C is suitable for X-by-wire systems in the automotive and avionics domain. The time-triggered fieldbus TTP/A is intended for the integration of smart transducers in all types of distributed real-time control systems. Although the first target are automotive applications, TTP/A has been designed to meet the requirements of process control systems as well. TTP/A provides a well-defined smart transducer interface to the sensors and actuators of a network. TTP/A has no fault tolerance mechanisms by default, but supports deterministic real-time communication with low latency and small jitter. TTP/A supports low cost implementations on wide set of available component-off-the-shelf microcontrollers. The following sections of this paper are organized as follows: Section 2 explains the principles of the Time-Triggered Architecture that are common to both protocols. Section 3 introduces the principles of operation of TTP/C. Section 4 ex-

py rig

ht

20

11

Ka re

ld

e

TTP/C and TTP/A are the real-time protocols of the Time-Triggered Architecture (TTA). Both protocols use a Time-Division Multiple Access (TDMA) scheme to enable collision-free bus allocation. TTP/C focuses on the interconnection of components in order to form a highly dependable realtime system that is sufficient for critical applications such as X-by-wire in the automotive and avionics domains. TTP/C implements a replicated bus system and a guardian that prevents babbling idiot failures. TTP/A aims at an easy and economically integration of sensors and actuators into a network. TTP/A can be implemented on low-cost microcontrollers, which suggests each transducer having a TTP/A interface. The interface concept of TTP/A supports a modular design and an easy integration and management of transducers.

Richard Ipp TTTech Computertechnik Schönbrunnerstraße 7 Vienna, Austria [email protected]

ch o

Wilfried Elmenreich Institut f¨ ur Technische Informatik Vienna University of Technology Vienna, Austria [email protected]

1 Introduction

Co

Distributed electronic control systems promise an improvement of cost, safety, weight reduction, and maintainability in several domains. The decreasing cost of electronic microcontrollers has led to a shift from traditional electro-mechanical solutions to distributed electronic control systems in the automotive domain. Avionic systems depend on reliable communication systems with a second focus on weight. The requirements from these domains call for a dependable real-time communication system that interconnects the control nodes.

Fieldbus with Transducers

plains the principles of operation of the TTP/A protocol. Section 5 compares both approaches and depicts an architecture that integrates both protocols. The paper is concluded in Section 6.


Workshop on Time-Triggered and Real-Time Communication Systems

Host Computer

Host Computer

ol

CNI Communication Controller

Central Guardian

Central Guardian

ge s

Host Computer CNI


ot eHo

Communication Controller

Host Computer

Figure 2: Star network topology

Gr

• Since the star coupler is spatially apart from the nodes the star topology is resistant against spatial proximity faults.

ld

e

• The central guardians isolate arbitrary node failures. Slightly-off-specification faults, which are not caught in the bus topology are handled by performing a signal reshaping of the sender’s message.

Ka re

Host Computer



The Time-Triggered Architecture (TTA) [1] establishes a framework for the implementation of dependable distributed real-time embedded applications. The basic building block of the TTA is a node, which comprises a network interface, a timetriggered communication controller, and a host computer. Nodes within a TTA cluster exchange data using the TTP/C communication protocol, which uses a TDMA scheme for bus arbitration. Each node forms a fault containment region. In order to tolerate the loss of a communication channel, two replicated channels connect the nodes to build a cluster.


ch o

2 The Time-Triggered Architecture

Host Computer

Host Computer

Host Computer

CNI

CNI

CNI





Bus Guardian

Bus Guardian

Bus Guardian

Bus Guardian

• Since only one bus guardian per channel is necessary, the star approach is economically attractive [2].

20

11

CNI

replicated Bus

3 The TTP/C Protocol

Figure 1: Bus network topology

ht

TTP/C is a fault-tolerant time-triggered protocol that provides:

py rig

Currently, the TTA supports two network topologies, the bus and the star topology. In the bus topology (see Figure 1) each node is equipped with a bus guardian component that controls access of the node’s communication controller to the communication medium. The bus guardian is implemented as a separate component so that in case of failure of a component the node is prevented from sending outside its assigned time slot, i. e., preventing a babbling idiot failure of a node. The star topology implements two star couplers that act as central bus guardians (see Figure 2). The star approach has several advantages over the bus approach:

Co

• An autonomous fault-tolerant message transport at known times and with minimal jitter between the CNIs of the nodes of a cluster by employing a TDMA strategy on replicated communication channels. • A fault-tolerant clock synchronization that establishes the global time base without relying on a central time server. • A Membership service to inform every correct node about the consistency of data transmission. This service can be viewed as a

2

Introduction to TTP/C and TTP/A

Co

py rig

ht

20

11

Ka re

ld

e

Gr

ot eHo

ge s

ch o

ol

distributed acknowledgment service that in- containment regions, each can fail in an arbitrary forms the application promptly if an error in way. Under this assumption the probability of two concurrent independent component failures is the communication system has occurred. small enough to be considered a rare event that • Clique avoidance to detect faults outside the can be handled by an appropriate never-give-up fault hypothesis, which cannot be tolerated (NGU) strategy. However, it should be noted at the protocol level. that a very prompt error detection mechanism is needed to ensure that two consecutive single In TTP/C communication is organized into faults are not becoming concurrent. TDMA rounds as depicted in Figure 3. A TDMA As for hardware faults, TTP/C is designed to round is divided into slots. Each node in the com- isolate and tolerate single node faults. By inmunication system has its sending slot and must troducing a bus guardian it is guaranteed that send frames in every round. The frame size allo- a faulty node cannot prevent correct nodes from cated to a node can vary from 2 to 240 bytes in exchanging data. The bus guardian ensures that length, each frame usually carrying several mes- a node can only send once in a TDMA round, sages. The cluster cycle is a recurring sequence of thereby eliminating the problem of babbling idTDMA rounds; in different rounds different mes- iots that monopolize the communication medium. sages can be transmitted in the frames, but in Moreover, TTP/C implements a never-give-up each cluster cycle the complete set of state mes- strategy (NGU) for multiple fault scenarios: if sages is repeated. The data is protected by a a node detects faults that are not covered by 24 bit CRC (Cyclic Redundancy Check). The the fault hypothesis, it notifies the application. schedule is stored in the message descriptor list The application may now decide either to shut(MEDL) within the communication controller. down in fail-safe environments or to restart in failThe clock synchronization is necessary to pro- operational environments with an agreed consisvide all nodes with an equivalent time concept. In tent state among all nodes of the distributed sysdoing so it makes use of the common knowledge tem. of the send schedule. Each node measures the difference between the a priori known expected 3.2 Fault Tolerance and the observed arrival time of a correct message to learn about the difference between the senders The mechanisms described above ensure fault tolclock and the receivers clock. A fault-tolerant erance at the communication subsystem level in average algorithm needs this information to peri- TTP. These mechanisms of the communication odically calculate a correction term for the local subsystem guarantee that faulty nodes cannot clock so that the clock is kept in synchrony with prevent correct nodes from communicating and all other clocks of the cluster. The membership serve as communication platform for the appliservice uses a distributed agreement algorithm to cation. At the application level fault tolerance determine whether, in case of a failure, the out- needs to be implemented by a fault tolerance layer going link of the sender or the incoming link of and an appropriate application design. Fault tolerance can be realized by replicating a software the receiver has failed. The core algorithms of TTP/C have been for- subsystem on two failsilent nodes. Tolerance of mally verified to prove their correctness. Real a single arbitrary node failure can be ensured by tests with multi-million fault injections and heavy TMR (Triple Modular Redundancy) voting. Both mechanisms will tolerate single compoion radiation experiments and experiments with electromagnetic interferences have been carried nent faults with the respective failure semantics and are thus fit to handle both transient and perout successfully. manent hardware faults. To re-establish tolerance to single component faults despite the presence 3.1 Fault Hypothesis and Fault Handling of a permanent hardware fault, TTP/C supports Provided that the components of a properly con- the implementation of transparent hot-stand-by figured TTP/C based system are in different fault spares.

3

ch o

ol

Workshop on Time-Triggered and Real-Time Communication Systems

ge s

Figure 3: Frames, messages, slots, TDMA round, and cluster cycle in TTP/C communication Therefore state consistency should be supported as a basic service of the communication subsystem that satisfies the following properties. Provided that the fault hypothesis holds, a system is termed consistent if

ot eHo

Fault tolerance is realized by a redundant unit in the network taking over the function of a defective unit, without being noticed at the function level. This is why data consistency is necessary.

3.3 Support for Consistency

• All correct nodes agree on the same data,

Data consistency can facilitate the design and development of complex distributed systems considerably. In single node systems consistency can be taken for granted because data written to memory is available to all software subsystems at the same time and all subsystems read the same value, provided that the node is correct. In distributed systems it is no longer justified to assume this kind of consistency. There are two reasons for this: Firstly, message transmission delays that have an effect on the current state must taken into consideration; it is not guaranteed that a message arrives at all receivers at the same point in time. Secondly, individual nodes may fail or messages may get lost. Design and programming in a distributed system become laborious and difficult, especially for complex applications, if state consistency is not supported at the communication platform level independent from the application. Applicationindependent support of state consistency is not only capable of relieving the application CPU of executing consistency protocols but, more important, of verifying the correctness of complex consistency algorithm for all applications. This makes it necessary to implement data consistency at the communication controller side of the CNI. The huge number of possible node failures, communication failures, or differences in message arrival timing and sequence would make the logic of the application subsystem large and complex.

Gr

• All nodes agree on the data sent by a correct sender

ld

e

• All correct subsystems deliver the received value at the same point in time.

20

11

Ka re

It is assumed that a node sends data to a series of receiving nodes. TTA is designed to support communication consistency in the hardware directly on the protocol level. The mechanisms that support consistency are described in the following.

3.4 Membership and Acknowledgment

Co

py rig

ht

A major philosophy in the design of TTP/C is that the protocol should transmit data consistently to all correct nodes of the distributed system and that, in case of a failure, the communication system should decide on its own which node is faulty. These properties are achieved by the membership protocol and an acknowledgment mechanism. Each node of a TTP/C based cluster maintains a membership list with all nodes that are considered to be correct. This information is updated locally in accordance with successful (or unsuccessful) data transmissions and thus reflects the local view of the receiving node on all other nodes. With each transmission, each receiver sees and checks the senders membership that is included

4

Introduction to TTP/C and TTP/A in the senders transmission or hidden in the CRC calculation. Acknowledgment: After transmission, node A seeks acknowledgment from the other nodes in order to determine whether the transmission was accepted at the receiver (on the communication level). This is achieved by checking the membership list of the first (and possibly second) successive sender. If these nodes show node A in their membership list, they state that As transmission was successfully received. Otherwise, A is informed that the transmission was unsuccessful. Due to the time-triggered principle, re-transmission of the state message is done in the next cycle.

ol

Figure 4: Real-time and on-demand frame partitioning

ch o

3.5 Consistency and Events

ot eHo

ge s

In addition to the mechanisms for guaranteed, timely, and consistent transmission of real-time data, TTA also provides mechanisms for the exchange of event data. The need for event data usually arises from on-demand diagnosis, parameter calibration, and debugging. The TTA event transport mechanism is based on the allocation of dedicated bandwidth for event data. A TTP/C frame can carry up to 240 bytes. Part of the frame can be used for event messages. The event-triggered messages are piggy-backed on TTP/C frames. This partitioning of each slot in state data, event data, and spare bandwidth for future extensions is depicted in Figure 4. An important property of this scheme is that the bandwidth for on-demand transmission is arbitrated only among the event messages on each node, not between the event messages of all nodes in the system. This node-local arbitration has the advantage that it ensures full temporal composability. This cannot be attained in case of global bandwidth contention. Furthermore, all fault isolation capabilities of the TTA apply to these dynamically arbitrated channels. A faulty node cannot possibly occupy the channels of some correct node. Furthermore all consistency mechanisms described earlier are also valid for the event messages. This enables TTA to extend full consistency from time-triggered to event-triggered messages. Even though the use of a node-local bandwidth is less efficient with respect to the overall bandwidth than the use of a system-wide bandwidth, extensive studies with large car manufacturers have shown that the described event transport mechanism satisfies their requirements completely. A standard diagnostic protocol, for example, can be implemented with as little as 0.8% net bandwidth of a 10 Mbit/s TTP/C system.

Ka re

ld

e

Gr

Membership Consistency Check: Due to the strict round-robin scheme of the TDMA round, each node sees and checks the membership lists of all other nodes in one TDMA round. Each sender with a different membership list is assumed as incorrect. This ensures a consistent view of all nodes, which accept each other in the membership, i.e., they communicate successfully with one another.

Co

py rig

ht

20

11

Clique Avoidance: In order to detect multiple component faults and inconsistencies and to support the never-give-up strategy, the clique avoidance mechanism is active. Before each send operation of a node the algorithm checks if the node is a member of the majority clique. In case the node is in a minority clique, this means that a very rare fault scenario outside the fault-hypothesis has occurred which led to an inconsistency. This condition is signaled to the application software, which can decide whether to initiate fail-stop or fail-operational activities. The combination of these algorithms together with the common time base established by the clock synchronization provides communication consistency. This guarantees that all correct nodes receive the same information at the same point in time. TTA thus provides the application software with a very powerful programming model that allows efficient handling complex distributed software systems.

5

Workshop on Time-Triggered and Real-Time Communication Systems In order to support the migration of other software systems, an implementation of the widely used TCP/IP protocol and of the CORBA IIOP protocol on top of the basic TTP/C communication service is in progress.

Sensor

Distributed Application

Local Sensor Application

Actuator

Local Sensor Application e.g., Control


Distributed Interface File System

Figure 5: Logical Network Structure

ch o

ol

4 The TTP/A Protocol TTP/A is a low-cost fieldbus protocol for the interconnection of smart transducers. The protocol has been standardized in 2002 by the Object Management Group (OMG) as smart transducer interface standard[3]. The standard comprises TTP/A as the time-triggered transport service within a distributed smart transducer subsystem and defines a well-defined interface between the transducers and a CORBA network. The smart sensor technology offers a number of advantages from the points of view of technology, cost, and complexity management [4]:

Gr

ot eHo

ge s

file system (IFS), which is encapsulated in each smart transducer. The IFS provides a unique address scheme for transducer data, configuration data, selfdescribing information and internal state reports of a smart transducer [7]. It establishes a stable intermediate structure that is a solid base for smart transducer services. The implementation of the IFS is economically feasible to assign local intelligence even to low-cost I/O devices like 8-Bit microcontrollers with 4 Kbytes Flash ROM and less than 64 bytes of RAM memory. The IFS is the source and sink for all communication activities and acts as a temporal firewall [8] that decouples the local transducer application from the communication activities. A time-triggered sensor bus will perform a periodical time-triggered communication to copy data from the IFS to the fieldbus and write received data into the IFS. The ROund Descriptor List (RODL), a predefined communication schedule defines time, origin, and destination of each protocol communication. The instants of updates are specified a priori and known by the communicants. Thus, the IFS acts as a temporally specified interface that decouples the local transducer application from the communication task. Each transducer can contain up to 64 files in its IFS. An IFS file is an index sequential array of up to 256 records. A record has a fixed length of four bytes (32 bits). An IFS record is the smallest addressable unit within a smart transducer system. Every record of an IFS file has a unique hierarchical address (which also serves as the global name of the record) consisting of the concatenation of the cluster name, the logical name, the file name and the record name. Besides access via the master node, the local applications in the smart transducer nodes are also able to execute a clusterwide application by communicating directly with each other. Figure 5

Ka re

ld

e

• Electrically weak non-linear sensor signals can be conditioned, calibrated and transformed into digital form on a single silicon die without any noise pickup from long external signal transmission lines [5].

ht

20

11

• The smart sensor contains a well-specified digital communication interface to a sensor bus, offering “plug-and-play” capability if the sensor contains a reference to its documentation in form of an electronic data sheet as it is proposed in the IEEE 1451.2 Standard [6].

py rig

• It is possible to monitor the local operation of the sensing element via the network and thus simplify the diagnosis at the system level.

Co

The internal complexity of the smart-sensor hardware and software and internal failure modes can be hidden from the user by well-designed fully specified smart sensor interfaces that provide just those services that the user is interested in.

4.1 Interface File System The information transfer between a smart transducer and its client is achieved by sharing information that is contained in an internal interface

6

Introduction to TTP/C and TTP/A Real-Time Service Interface

depicts the logical network view for such a clusterwide application.

Configuration and Planning Interface

Diagnostics and Management Interface

4.2 The Three Interfaces of a Smart Transducer

Interface File System

ol

In order to support complexity management and composability, it is useful to specify distinct interfaces for functional different services [4]. As depicted in Figure 6, a smart transducer node can be accessed via three different interfaces.

Read and Write Access

ch o


ge s

Sensor or Actuator

py rig

ht

20

11

Ka re

ld

e

Gr

ot eHo

Real-Time Service (RS) Interface: This interface provides the timely real-time services to Figure 6: Three Interfaces to a Smart Transducer Node the component during the operation of the system. TDMA slots. A slot is the unit for transmission Diagnostic and Maintenance (DM) Interface: of one byte of data. Data bytes are transmitted This interface opens a communication in a standard UART format. Each communicachannel to the internals of a component. It tion round is started by the master with a sois used to set parameters and to retrieve called fireworks byte. The fireworks byte defines information about the internals of a compothe type of the round and is a reference signal for nent, e. g., for the purpose of fault diagnosis. clock synchronization. The communication patThe DM interface is available during system tern for each round is predefined via the RODL, operation without disturbing the real-time which is distributively stored in all nodes. The service. Usually, the DM interface is not protocol supports eight different firework bytes time-critical. encoded in a message of one byte using a redundant bit codesupporting error detection. One fireConfiguration and Planning (CP) Interface: This interface is necessary to access con- works byte is a regular bit pattern, which is also figuration properties of a node. During used by slave nodes with an imprecise on-chip osthe integration phase this interface is used cillator for startup synchronization (see figure 7). to generate the “glue” between the nearly Generally, there are two types of rounds: autonomous components. The CP interface is not time-critical. Multipartner round: This round consists of a configuration dependent number of slots and an assigned sender node for each slot. The 4.3 Principles of Operation configuration of a round is defined in a datastructure called “RODL” (ROund Descriptor TTP/A is a time-triggered protocol used for List). The RODL defines which node transthe communication of one active master with or mits in a certain slot, the operation in each among smart transducer nodes within a cluster.

Co

This cluster is controlled by the master, which establishes a common time base among the nodes. In case of a master failure, a shadow master can take over control. Every node in this cluster has a unique alias, an 8 bit (1 byte) integer, which can be assigned to the node a priori or set via the configuration interface. The bus allocation is done by a Time-Division Multiple-Access (TDMA) scheme. Communication is organized into rounds consisting of several

UART−Frame 11 − bit

3

4

5

Synchronize Pattern

6

7

IBG

odd

2

Stop

1

MSB

LSB

Start

0

Partity

IRG

TTP/A Slot − 13 bit

Figure 7: Synchronization Pattern

7

Workshop on Time-Triggered and Real-Time Communication Systems Multipartner Round Slot 1

Slot 2

Slotn

DataByte

...

Slot 0

FB (Master) ...

DataByte

t

Last slot of round FB..................Fireworks Byte, sent by master DataByte......sent either by master or slave

Figure 10 depicts a fault-tolerant architecture with two TTP/C nodes and two TTP/A networks containing a set of transducers. Each TTP/C node controls vice versa one master node of one TTP/A network and a shadow node to the other TTP/A network. The dotted ovals around the transducers indicate that these transducers are redundantly measuring the same real-time entity. The given example tolerates an arbitrary node failure of any node in the network. Since measurements from different sensors of the same realtime entity are not replica deterministic, it is necessary to run an agreement protocol between the TTP/C application in order to get a consistent system state.

ol

Slot 0

FB (Master) DataByte

obeying a time-triggered schedule, the TTP/A and TTP/C system can be synchronized in order to support synchronous interaction of all nodes in the network.

ch o

Figure 8: Example for a TTP/A multipartner round

ot eHo

ge s

individual slot, and the receiving nodes of a slot. RODLs must be configured in the slave nodes prior to the execution of the corresponding multipartner round. An example for a multipartner round is depicted in Figure 8.

Gr

Master/slave round: A master/slave round is a special round with a fixed layout that establishes a connection between the master and a particular slave for accessing data of the node’s IFS, e. g. the RODL information. In a master/slave round the master addresses a data record using a hierarchical IFS address and specifies an action like reading of, writing on, or executing that record.

Ka re

ld

e

Besides stand-alone implementations of TTP/A [9, 10, 11], there exist also some prototype implementations of the TTP/A master protocol for TTP/C nodes. The most modular solution comes in the form of a PCMCIA card [12] which can be used as I/O card in a TTP/C node (or any other computer system with a PCMCIA interface). Figure 11 depicts the size of the PCMCIA gateway card (without cover). The card hosts a microcontroller and provides interfaces to a TTP/A and CAN bus. The microcontroller can be configured via the PCMCIA interface and runs the TTP/A master protocol.

ht

20

11

The master/slave rounds establish the DM and the CP interface to the transducer nodes. The RS interface is provided by periodical multipartner rounds. Master/slave rounds are scheduled periodically between multipartner rounds as depicted in Figure 9 in order to enable maintenance and monitoring activities during system operation without a probe effect.

py rig

5 Integration of TTP/C and TTP/A

TTP /A Master

By integrating both protocols into the timetriggered architecture, TTP/A and TTP/C well complement each other. Since both protocols are

Co

Shadow Master

MP Round

Real-Time Service Data

Secondary TTP /A Bus

TTP/C Host Application

Cluster Cycle Time MS Round

Primary TTP /A Bus

MS Round

MP Round

Diagnostics and Management Data

t

Shadow Master TTP /A Master

TTP/C Host Application

CNI

CNI

TTP/C Communication Controller

TTP/C Communication Controller

TTP /C Communication Service

Figure 10: Integrated architecture with two TTP/C nodes and TTP/A networks

Figure 9: Recommended TTP/A Schedule

8

Introduction to TTP/C and TTP/A [2] TTTech Computertechnik, Schönbrunnerstraße 7, Vienna, Austria. The Time-Triggered Architecture – A Platform for Safety-Critical Applications in the Automotive Industry, 2002. Available at http://www.tttech.com.

ol

[3] Object Management Group (OMG). Smart Transducers Interface V1.0, January 2003. Specification available at http://doc.omg.org/formal/2003-01-01 as document ptc/2002-10-02.

ch o

Figure 11: PCMCIA Gateway Card in comparison to size of 2 Euro coin

[4] H. Kopetz. Software engineering for real-time: A roadmap. In Proceedings of the IEEE Software Engineering Conference, Limmerick, Ireland, 2000.

ge s

6 Conclusion

ht

20

11

Ka re

ld

e

Gr

ot eHo

Although TTP/C and TTP/A are both timetriggered real-time communication protocols, [5] P. Dierauer and B. Woolever. Understanding they are not in a competing situation. smart devices. Industrial Computing, pages 47– TTP/C focuses on the interconnection of com50, 1998. ponents in order to form a highly dependable realtime system that is sufficient for critical applica- [6] L. H. Eccles. A brief description of IEEE P1451.2. Sensors Expo, May 1998. tions such as X-by-wire in the automotive and avionics domains. [7] H. Kopetz, M. Holzmann, and W. Elmenreich. A universal smart transducer interface: TTP/A. On the other hand TTP/A supports an easy International Journal of Computer System Sciintegration of sensors and actuators into a netence & Engineering, 16(2):71–77, March 2001. work. The cost of a TTP/A transducer node are typically below the cost of the transducer, which [8] H. Kopetz and R. Nossal. Temporal firewalls in large distributed real-time systems. Proceedsuggests each transducer having a TTP/A interings of the 6th IEEE Workshop on Future Trends face. The interface file system concept provides of Distributed Computing Systems (FTDCS ’97), a common name space for the data items that pages 310–315, 1997. are exchanged among the transducer nodes and a master node. It establishes a stable intermedi- [9] P. Peti and L. Schneider. Implementation of the TTP/A slave protocol on the Atmel ATmega103 ate structure that is a solid base for many new MCU. Technical Report 28/2000, Technische services. Universität Wien, Institut f¨ ur Technische InforThe common principles of TTP/C and TTP/A matik, Vienna, Austria, August 2000. support an integration of both systems in order to create dependable economically feasible control [10] R. Obermaisser and A. Kanitsar. Application of TTP/A for the Otto Bock Axon bus. Technical systems with distributed sensing.

py rig

Report 27/2000, Technische Universität Wien, Institut f¨ ur Technische Informatik, Vienna, Austria, July 2000.

Acknowledgements

[11] R. Kapeller. Design and implementation of a TTP/A master and gateway controller on a 32bit microcontroller. Master’s thesis, Technische Universität Wien, Institut f¨ ur Technische Informatik, Vienna, Austria, 2001.

Co

This paper was supported by the European IST project NEXT TTA under contract No. IST-200132111.

References

[12] M. Borovicka. Design of a gateway for the interconnection of real-time communication hier[1] C. Scheidler, G. Heiner, R. Sasse, E. Fuchs, archies. Master’s thesis, Technische Universität H. Kopetz, and C. Temple. Time-Triggered ArWien, Institut f¨ ur Technische Informatik, Treitlchitecture (TTA). Advances in Information Techstr. 3/3/182-1, 1040 Vienna, Austria, 2003. nologies: The Business Challenge, IOS Press, 1997.

9


3.8 3.8.1

79

FlexRay Introductie

ch o

ol

FlexRay kwam tot stand uit de samenwerking tussen BMW en Daimler Chrysler (tegenwoordig Daimler) nadat de twee automobielconstructeurs realiseerden dat de huidige systemen niet voldeden aan de noden van de toekomstige applicaties inclusief x-by-wire toepassingen.

ge s

In September 2000, verenigden BMW en DaimlerChrysler hun krachten, samen met Philips en Motorola (tegenwoordig FreeScale) om het FlexRay Consortium op te richten. Sinds de op richting is het consortium gegroeid met meerdere van de grootste automotive spelers waaronder Bosch, General Motors,...

ot eHo

Industriële experts voorspellen dat Flexray de de-facto standaard zal worden voor high-speed controle applicaties in voertuigen.

FlexRay Node

e

3.8.2

Gr

Het consortium is nog steeds actief en zal tegen het einde van 2009 een nieuwe versie van het protocol vrijgeven. Daarna wordt er voorspeld dat het protocol uit handen zal worden gegeven aan een standardisatie organisatie.

Ka re

ld

• host: De processor van de host verwerkt alle informatie die verkregen wordt via de kanalen of die gestuurd moet worden op de kanalen. Deze staat niet rechtstreeks in verbinding met de kanalen, maar wordt intern verbonden met de communicatie-controller en de bus driver(s) van de node.

20

11

De host en de communicatie-controller delen heel wat informatie. De host levert controleen configuratie informatie aan de CC, en tevens payload data die verstuurd wordt tijdens de communicatiecyclus. De CC levert status informatie aan de host en levert payload data ontvangen van de communicatieframes.

py rig

ht

• Communication controller: De communicatie-controller zorgt ervoor dat alle datatransfer binnen de node goed verloopt. Hij zal dan ook communicatie data met de host uitwisselen. Dit kan data zijn die de host op de kanalen wil versturen, maar ook data die de communicatiecontroller via de bus driver(s) heeft ontvangen. Het is dus een tweerichtingsverkeer. Dit geldt ook zo voor de configuratie data en de status informatie die wordt uitgewisseld. Op deze manier blijven beide componenten op de hoogte van de huidige status van de node en zal de configuratie hieraan ook aangepast kunnen worden.

Co

De interface tussen de CC en de BD bestaat uit 3 digitale electrische signalen. Twee zijn uitgangen van de CC (TxD en TxEN) en één is een uitgang van de BD (RxD). De CC gebruikt de TxD (Transmit Data) lijn voor het versturen van het actuele signaal naar de BD die het op zijn beurt op de communicatielijnen tussen de nodes kan plaatsen. De TxEN dient om het verzoek van de CC aan de BD aan te geven waarbij de BD het signaal dat op de TxD lijn wordt aangeboden op de communicatielijnen tussen de nodes kan plaatsen. De BD gebruikt de RxD lijn om de actuele ontvangen informatie van de communicatielijnen tussen de nodes door te sturen naar de CC • Bus driver (transceiver): De bus driver is een elementair onderdeel van de node. De bus driver is de link met de kanalen voor de communicatie-controller. Alle te versturen informatie NCC-2011-001

KdG–IWT

Automotive Software

80

py rig

ht

20

11

Ka re

ld

e

Gr

ot eHo

ge s

ch o

ol


Co

Figuur 3.45: Interne componenten van een FlexRay node

NCC-2011-001

KdG–IWT

Automotive Software


81

ol

passeert dus eerst voorbij de bus driver alvorens deze op het kanaal wordt geplaatst. Ook zal de data op het kanaal via de bus driver naar de communicatie-controller worden gestuurd. De communicatie-controller en de bus driver wisselen dus ook communicatie data uit. Dit wordt gestuurd door het controle signaal van de communicatie-controller. Wanneer de communicatiecontroller dan data wil verzenden, zal deze via een aparte lijn naar de bus driver gaan. Het controle signaal van de communicatie-controller zal dan de bus driver het commando geven om deze op het kanaal te plaatsen.

ge s

ch o

Het ligt voor de hand dat voor elk kanaal dus een aparte bus driver vereist is. Een van de redenen dat een dubbelkanaals node dus duurder is dan een enkelkanaals node, is dat er een extra bus driver voorzien moet zijn en daarbij ook de bijhorende interne verbindingen. De communicatie-controller zal dan ook hiervoor geconfigureerd moet worden.

ot eHo

Het optionele controle signaal dat via de bus driver naar de voeding loopt, is voorzien zodat een slaapmodus gebruikt kan worden binnen de functies van de node. De bus driver is namelijk het enige onderdeel van de node dat steeds voorzien moet zijn van voeding. Hierdoor kan een zeer efficiënte en economische toestand gecreëerd worden, bijvoorbeeld bij stilstand van een wagen. Er is dan minimum stroomverbruik in de gehele kring. Wanneer de bus drivers een wakeup patroon zouden ontvangen op een van de kanalen, zullen deze de voeding naar de andere componenten aansturen en zo de node activeren.

e

Gr

• Bus Guardian: De bus guardian is een optioneel, maar toch zeer belangrijk component binnen het FlexRay protocol. In tegenstelling tot het CAN protocol dat volledig asynchroon verloopt, heeft FlexRay zowel een synchroon als een asynchroon verloop.

Ka re

ld

Het probleem met synchrone data transfer is niet alleen dat het kanaal constant belast wordt, maar dat de data ook op het juiste moment op het kanaal geplaatst moet worden. Wanneer een node binnen het netwerk defect zou zijn, kan het gebeuren dat deze data wil versturen op de verkeerde momenten. Dit verschijnsel wordt binnen de elektronica een babbling idiot genoemd. Om te voorkomen dat door zo’n defecte node het hele netwerk niet meer zal functioneren, wordt gebruik gemaakt van de bus guardian.

ht

20

11

De bus guardian vormt een extra link tussen de communicatie-controller en de bus driver. De bus driver zal geen data kunnen versturen op de kanalen zonder toestemming van de bus guardian. De communicatie-controller stuurt de data wel naar de bus driver, maar zal eveneens de bus guardian informeren over het moment waarop de bus driver de informatie pas mag versturen op het kanaal. De bus guardian zal enkel werken binnen het statisch segment van de communicatie cyclus (zie verder).

3.8.3

Co

py rig

Dit voorkomt niet dat errors zullen plaatsvinden wanneer de node defect zou zijn. Maar er wordt wel voorkomen dat heel de communicatie op het kanaal verstoord wordt. Op deze manier zal de werking van het netwerk grotendeels verzekerd blijven en wordt dus ook de fouttolerantie verhoogd.

De EPL: Electrical Physical Layer

Het datalink-laag protocol van FlexRay is onafhankelijk van de gebruikte fysische laag. 2 verschillende fysieke lagen worden besproken. We bekijken hier enkel de elektrische fysieke laag van FlexRay. Een FlexRay netwerk kan opgebouwd worden met één of met twee kanalen. In deze gevallen spreekt men over respectievelijk enkelkanaals en dubbelkanaals netwerken. Het gebruik van meer kanalen verhoogt de bedrijfszekerheid. Nodes moeten niet met beide kanalen verbonden zijn in het dubbelkanaals netwerk.

NCC-2011-001

KdG–IWT

Automotive Software


82

Een kanaal bestaat uit 2 draden, bus plus (BP) en bus min (BM). De Flexray standaard definieert enkel de karakteristieken van de kabels en de connectoren. We geven een klein overzicht van deze. De kabels mogen al of niet afgeschermd zijn zolang zij maar aan volgende karakteristieken voldoen: Kabel:

ol

• Kabeldemping: max. 85 db/km bij 5 MHz

ch o

• Differentiele impedantie: 80 - 110 Ω

ge s

• Lijn vertraging: Max. 10 ns/m Connector:

ot eHo

• Contact weerstand: Max. 50 Ω • Impedantie van de connectoren: 70 - 200 Ω

11

Ka re

ld

e

Gr

• Length of the connector: Max. 150 mm

20

Figuur 3.46: FlexRay Spanningsniveaus

ht

De EPL beschrijft 4 toestanden op de bus:

py rig

• Idle LP ( low power ): BP and BM op massa niveau • Idle status: geen stroom wordt gestuurd naar BP en BM, gemeenschappelijk spanningsniveau van 2,5 V, recessieve bit

Co

• Data 1: Spanning van BP is hoger dan BM, dominante bit • Data 0: Spanning van BM is hoger dan BP, dominante bit

3.8.4

Topologie

Bij FlexRay kunnen tot 70 units aan elkaar gekoppeld worden. Er zijn oneindig veel combinaties die we kunnen gebruiken om een FlexRay netwerk te vormen. Toch kunnen we enkele grote onderscheiden in de types van topologie binnen het FlexRay protocol.

NCC-2011-001

KdG–IWT

Automotive Software


83

Een Flexray netwerk kan worden geconfigureerd als een één kanaals netwerk of als een dubbel kanaals netwerk. Het tweede kanaal kan gebruikt worden om de bandbreedte te verhogen of als redundant kanaal voor veiligheidscritische toepassingen. Alle FlexRay netwerken zijn lineair; dit wil zeggen dat er geen ringstructuren voorkomen.

ol

Verder kunnen de structuren worden onderverdeeld in 3 groepen:

ch o

• Busstructuur • Sterstructuur

ge s

• Hybride structuur

ot eHo

Nodes kunnen gekoppeld worden aan één kanaal of beide kanalen. De topologiën van beide kanalen hoeven niet dezelfde te zijn. We kunnen bijvoorbeeld een sternetwerk hebben voor kanaal A en een busnetwerk voor kanaal B. Het wordt wel geadviseerd dat de propagatievertraging in beide netwerken bijna hetzelfde is.

Gr

Het netwerk noemen we een cluster. Een node kan communiceren met andere nodes in de cluster indien deze aan hetzelfde kanaal zijn verbonden.

ld

e

Bij een stertopologie en hybride topologie kunnen we nog een extra element in het netwerk vinden, de sterkoppelaar. De ster zal de informatie, die van één verbonden kanaal afkomstig is, sturen naar alle andere verbonden kanalen.

FlexRay Communicatie Cyclus

20

3.8.5

11

Ka re

De sterkoppelaar veroorzaakt een vertraging op het netwerk. Door deze vertraging kunnen er maximaal 2 sterkoppelaars tussen 2 arbitraire nodes op het netwerk zijn. Sterkoppelaars kunnen ook een bus guardian hebben. Hierdoor is een bescherming van de fysieke laag geïmplementeerd in een centraal punt.

py rig

ht

FlexRay combineert statische TDMA ( synchroon gedeelte ) en flexibele TDMA ( asynchroon gedeelte ) in één cyclus. Hiervoor wordt het schema in 2 delen verdeeld ( meer gedetailleerd in 4, maar uitleg volgt later ). Het eerste deel is voor het statische TDMA en het 2 de deel voor het dynamische gedeelte. Ieder node kent zijn eigen transmissiesloten. Er is dus geen gemeenschappelijke kennis van het communicatieschema tussen de nodes.

Co

Er zijn 2 extra delen in de cyclus, het symbol window(SW) en de network idle time (NIT) of netwerk rusttijd. • Statische Slot: Het statische slot is een verplicht deel van de communicatiecyclus. Het totaal aantal slots per statisch segment ligt vast voor alle node’s, maar is wel instelbaar binnen het protocol. Eén frame past altijd in één slot. Alle frames in een statisch segment hebben dezelfde lengte. Om de transmissies op juiste wijze te kunnen plannen, heeft elke node een slot counter voor kanaal A en een slot counter voor kanaal B. Deze slot counters houden het nummer bij van het huidige slot binnen een segment. Wanneer een statisch slot eindigt wordt de teller met 1 verhoogd. Het statisch segment eindigt wanneer de teller van de statische sloten een NCC-2011-001

KdG–IWT

Automotive Software

84

ge s

Figuur 3.47: FlexRay Communicatie Cyclus

ch o

ol


Ka re

ld

e

Gr

ot eHo

vooropgesteld aantal heeft bereikt. Een node kan enkel een frame versturen in een voor haar toegewezen slot. FlexRay gebruikt het frame ID ( frame identifiër ) om te traceren in welk slot een frame dient te worden verstuurd.

11

Figuur 3.48: FlexRay Statische Segment

20

Figuur 3.48 toont de verschillende transmissie patronen die mogelijk zijn binnen een statisch segment. In slot 1 zendt de node een frame op kanaal A en op kanaal B. In slot 2 zendt de node enkel een frame op kanaal A. Dit kan evengoed ook enkel verzonden worden op kanaal B. In slot drie wordt geen enkel frame verzonden.

py rig

ht

Synchronisatie frames bijvoorbeeld zullen altijd verstuurd worden op beide kanalen. Gewone frames mogen echter op één kanaal verzonden worden.

Co

• Dynamische Slot: Het dynamische segment zorgt voor het asynchrone karakter binnen de synchrone communicatie. Het dynamisch segment bevat een set van opéénvolgende dynamische sloten, die elk één of meerdere mini-sloten bevatten die geen vaste toewijzing krijgen. Deze minislots zullen dus ook niet altijd gebruikt worden, het dynamisch segment is dus een optioneel veld. De minislots zijn een potentiële start van een frame. In tegenstelling tot het statisch segment, dat een vaste tijdsduur heeft, zal de tijdsduur van het dynamisch segment variëren. Op deze manier kunnen binnen het dynamisch segment frames van een verschillende lengte worden opgenomen. Hierdoor wordt geen bandbreedte verspild. De tellers voor het dynamisch gedeelte zijn dezelfde als voor het statisch gedeelte en worden dus niet gereset na het statisch gedeelte. Een ander verschil met het statisch segment is dat de slot counters voor kanaal A en kanaal B binnen het dynamisch segment niet gelijk moeten lopen. Binnen het statisch segment zullen dan ook alle slots gelijktijdig verlopen. Bij het NCC-2011-001

KdG–IWT

Automotive Software

85

ge s

Figuur 3.49: FlexRay Dynamische Segment

ch o

ol


Gr

ot eHo

dynamisch segment is dit echter niet het geval. Op Figuur 3.49 is duidelijk te zien dat alle minislots normaal gezien dezelfde lengte hebben in de tijd. Wanneer echter een dynamisch slot wordt gebruikt, kan deze de lengte hebben van verschillende minislots. Een dynamisch slot zonder transmissie heeft bijgevolg de lengte van een gewoon minislot. Doordat niet alle dynamische slots op beide kanalen worden verstuurd, zal het verloop van de minislots ook niet simultaan verlopen. Op deze manier wordt de lengte van het optionele dynamische segment beperkt. De tijdsduur van het dynamisch segment wordt dus bepaald door het al dan niet plaatsvinden van communicatie binnen dit segment.

ld

e

Wanneer het slot eindigt, wordt de slotteller voor dat kanaal met 1 verhoogd. Dit gaat door tot ofwel:

Ka re

– De slotteller voor het desbetreffende kanaal zijn maximal heeft bereikt. – Het dynamisch segment het maximale aantal mini-slots heeft bereikt. Dit betekent het einde van het dynamisch gedeelte. Indien één van deze condities wordt bereikt, zal de node de slotteller naar 0 resetten voor de volgende communicatiecyclus.

20

11

Een node kan enkel verturen in een voor haar toegewezen dynamisch slot. Deze toewijzing is dezelfde als voor een statisch segment: door het gebruik van de frame ID. Het dynamisch segment kan evenzeer geen minisloten bevatten: het is dus een optioneel veld.

py rig

ht

• Symbol Window: Binnen het symbool raam kan één enkel symbool verzonden worden. Arbitratie voor het symbool raam is niet voorzien binnen het protocol. In de FlexRay standaard zijn 3 symbolen gedefinieerd maar slechts 1 type kan verzonden worden in het symbol window. Dit is het MTS (Media access Test Symbol). Het symbol window is een optioneel segment van de communicatie cyclus.

Co

• Nework Idle Time (NIT): De network rusttijd is het tweede verplichte deel aan het einde van een communicatiecyclus. Gedurende deze netwerk rusttijd zal geen communicatie plaatsvinden. Deze periode heeft verschillende doelen: – De communicatie-controller voert verschillende berekeningen uit (bijvoorbeeld: berekening van de clock correctie waardes, error behandeling, updaten van errorindicaties en tellers enz�). – De offset correctie. Op het einde van iedere oneven cyclus zal de NIT verlengd of ingekort worden afhankelijk van de offset correctie.

NCC-2011-001

KdG–IWT

Automotive Software

86

ot eHo

Figuur 3.50: FlexRay Frame Formaat

ge s

ch o

ol


3.8.5.1 Cycle Multiplexing

Frame Formaat

11

3.8.6

Ka re

ld

e

Gr

Sommige processen hebben niet dezelfde bandbreedte nodig als anderen. Om te voorkomen dat deze bandbreedte zou verloren gaan, kunnen wij cylcus multiplexing toepassen. Bijvoorbeeld: Indien een complete cyclus 2 ms duurt en er zijn 2 processen die elk om de 4 ms een frame dienen te versturen, dan kunnen beide systemen sturen in hetzelfde slot, maar in verschillende cycli. De nodes houden bij welke cylclus lopende is. Flexray kan differentiëren tussen 64 cycli. Er is maar 1 voorwaarde: de beide processen moeten binnen dezelfde nodes lopen. Het is niet toegestaan dat 2 nodes in hetzelfde statische slot schrijven, zelfs in verschillende cycli. Het dynamische slot is hierin minder beperkend. 2 nodes kunnen hier wel in hetzelfde dynamische slot schrijven als dit in een verschillende cyclus is.

ht

20

Communicatie binnen het FlexRay protocol kan verlopen via twee onafhankelijke kanalen, kanaal A en kanaal B. Het signaal op deze kanalen wordt onderscheiden door twee verschillende niveaus, HOOG en LAAG. De node’s gebruiken de non-return to zero (NRZ) signaalcodering voor het coderen en decoderen van de signalen.

py rig

Een node zal het frame zo op het netwerk plaatsen dat de header eerst verschijnt, gevolgd door de payload en dan door het trailersegment.

Co

• Header: Het Flexray header segment bestaat uit 5 byte ( 40 bits ). Deze bytes bevatten volgende onderdelen: – Vlaggen (5 bits): 5 vlaggen zijn gedefinieerd: * reserved: De gereserveerde bit is een bit die voorzien is voor uitbreiding van het protocol in de toekomst. Een zendende node zal deze bit dus zetten naar een logische ’0’ terwijl ontvangende node’s deze bit gewoon zullen negeren. * Payload Preamble Indicator: Deze bit geeft aan of het eerste deel van het payload segment gereserveerd zal worden voor informatie over de inhoud van het payload segment ( vector ). Als deze indicator op nul gezet wordt, zal de data in de payload niet voorafgegaan worden door extra informatie over de inhoud. Als de indicator NCC-2011-001

KdG–IWT

Automotive Software


87

Ka re

ld

e

Gr

ot eHo

ge s

ch o

ol

echter op één gezet wordt, zal de zendende node extra data kunnen verzenden aan het begin van het payload segment. Ontvangende node’s kunnen dan aan de hand van deze indicator, het frame op een juiste manier interpreteren. De ruimte die voor deze extra data wordt voorzien, is op voorhand bepaald. Indien het frame verstuurd wordt in het statisch segment duidt dit op de aanwezigheid van een ”netwerk management vector”. Indien het fame verstuurd wordt in het dynamisch segment duidt dit op de aanwezigheid van een ”message ID”. * Null Frame Indicator: Deze indicator geeft aan of het frame wel of niet een null frame is. Een null frame is een frame dat geen nuttige data bevat in het payload segment van het frame. Dit wordt gebruikt om lege statische slots op te vullen. Als deze indicator naar nul gezet wordt, zal het payload segment geen geldige data bevatten. Alle bytes in het payload segment worden dan naar nul gezet. Wanneer het payload segment data bevat, zal de null frame indicator op één worden gezet. * Sync Frame Indicator: Deze indicator geeft aan of het frame wel of niet een synchronisatie frame is. Synchronisatie frames zijn frames die gebruikt worden voor het synchroniseren van communicatie over het netwerk. Wanneer de synchronisatie indicator op nul is gezet, zal geen enkele ontvangende node dit frame beschouwen als een synchronisatie frame. Wanneer deze indicator echter op één gezet is, zal elke node die dit frame ontvangt het frame gebruiken om zich te synchroniseren. Een node kan slechts één synchronisatieframe per cyclus versturen. Dit wordt verstuurd in het statisch segment. * Startup Frame Indicator: Deze indicator geeft aan of het frame wel of niet een startup frame is. Startup frames vervullen een speciale rol in de startup procedure. Enkel coldstart node’s kunnen startup frames verzenden. Deze indicator zal op één gezet worden voor alle startup frames van coldstart node’s. Een frame waarvan de startup frame indicator op één gezet is, zal ook altijd zijn synchronisatie frame indicator op een hebben staan. Een coldstart node kan slechts één startup frame versturen per communicatie cyclus en per kanaal.

20

11

– Frame ID (11 bits): De frame ID definieert het slot waarin het frame moet worden verzonden. Een frame ID wordt niet meer dan één keer gebruikt op elk kanaal binnen een communicatie cyclus. Elk frame dat verzonden kan worden in een cluster krijgt een ID toegewezen. De frame ID varieert van 1 tot 2047. Nul is een ongeldig frame ID.

py rig

ht

– Payload Lengte (5 bits): De lengte van het payload segment wordt in dit veld aangegeven. De grootte van het payload segment wordt echter gehalveerd weergegeven. Een frame met een payload segment van 72 bytes krijgt bijgevolg een payload lengte van 36. De payload lengte is vast bepaald voor frames verstuurd in het statische segment van een communicatie cyclus. In dynamische segmenten kan de payload lengte echter sterk variëren van cyclus tot cyclus

Co

– Header CRC (11 bits): De header CRC bevat een cyclic redundancy check code (CRC) die wordt berekend over de synchronisatie frame indicator, de startup frame indicator, de frame ID en de payload lengte. communicatie-controllers van node’s berekenen de header CRC van een ontvangen frame om na te kijken of deze overeenkomt met de header CRC in het frame. Om te voorkomen dat een defecte communicatie-controller de synchronisatie-frame of startup-frame indicator zou veranderen wordt de CRC code berekend in de processor van de host en doorgestuurd naar de communicatie-controller. De communicatie-controller zal de header CRC van een ontvangen frame berekenen om te controleren of de CRC correct is. De veelterm is: x 11 + x 9 + x 8 + x 7 + x 2 + 1 – Cyclus nummer (6 bits): De cycle counter geeft het nummer weer van de huidige cyclus op het moment dat het frame verstuurd wordt. De node’s houden de cycle counter bij NCC-2011-001

KdG–IWT

Automotive Software


88

en zullen de waarde hiervan dus meesturen in dit veld van het frame.

ch o

ol

• Payload:Het FlexRay payload segment bevat 0 tot 254 bytes. Aangezien de payload lengte uit two-byte woorden bestaat, zal het payload segment altijd uit een even aantal bytes zijn samengesteld. De bytes van het payload segment worden numeriek geteld beginnend bij nul na de eerste byte die op het header segment volgt. De individuele bytes worden dus aangeduid als Data0, Data1, Data2, ... met Data0 als eerste byte van het payload segment. Voor frames die in het dynamische gedeelte verstuurd worden, kunnen de eerste twee bytes van het payload segment optioneel gebruikt worden voor het verschaffen van extra informatie over de inhoud van het payload segment (Message ID). Voor frames in het statische segment kan een gedeelte van 0 tot 12 bytes gereserveerd worden voor dit doel (Network Management Vector).

ot eHo

ge s

– Network Management Vector: De lengte van de NM vector is geconfigureerd tijdens de configuratie statuus. The NM vector is geschreven in de applicatie. Er zijn geen mechanismes geïmplementeerd in de controller om deze data te gebruiken. – Message ID: De message ID identificeert de inhoud van de data. De message ID wordt geprogrammeerd in de applicaite van de zendende node. De ontvanger kan deze data gebruiken om specifieke data uit te filteren.

e

Gr

• Trailer: Het FlexRay trailer segment bevat slechts één veld, een 24-bit CRC voor het frame. De CRC wordt berekend door de controller voor het versturen of ontvangen van een frame. Het frame CRC veld bevat een cyclic redundancy check code (CRC) die berekend wordt over het header segment en het payload segment van het frame. Deze berekening omvat alle velden binnen deze segmenten.

3.8.7

Ka re

ld

De veelterm is: x 24 +x 22 +x 20 +x 19 +x 18 +x 16 +x 14 +x 13 +x 11 +x 10 +x 8 +x 7 +x 6 +x 3 +x +1

Coding en decoding

3.8.7.1 frame codering

20

11

Een node zal de NRZ (Non-return to Zero) methode toepassen voor het coderen en decoderen van een communicatie element

py rig

ht

• Transmission Start Sequence (TSS): Het wordt gebruikt door een node voor het initialiseren van de communicatie. De TSS opent de poort van een actieve ster. De TSS bestaat uit een opeenvolging van 3 - 15 lage bit. Het aantal bits is afhankelijk van het aantal actieve sterren in het netwerk en een parameter van de transceivers.

Co

• Frame Start Sequence (FSS): De node zal een FSS bit toevoegen achter de TSS bitstream. Het wordt gebruikt voor het compenseren van een eventuele quantization error in de eerste byte van de TSS. De FSS bit bestaat uit 1 HIGH bit. • Byte Start Sequence (BSS): Levert bit stream timing informatie naar de ontvangende nodes. BSS bestaat uit een hoge bit gevolgd door een lage bit. Iedere byte van een frame zal verstuurd worden als een uitgebreide byte bestaande uit een BSS gevolgd door 8 databits. • Frame End Sequence (FES): De FES markeert het einde van de laatste byte sequentie van een frame. Het bestaat uit een LAGE en een HOGE bit. Voor een frame in het statische segement zijn dit de laatste bits die verstuurd worden. Bij frames in het dynamische segment wordt de FES gevolgd door een dynamische eind sequentie ( Dynamic Trailing sequence , DTS ). NCC-2011-001

KdG–IWT

Automotive Software


89

• Dynamic Trailing Sequence (DTS): De DTS is enkel voor frames in het dynamisch segment. Dit voorkomt vroegtijdige detectie door de ontvangers van een kanaal in rust. De DTS bestaat uit 2 delen; een variabele lengte in tijd waarin de TxD uitgang tussen de CC en de BD op een laag niveau staat en en een vaste lengte waarbij deze uitgang op het hoog niveau staat.

ch o

ol

Om een frame te versturen assembleert de node een bitstroom gebruik makende van bovenstaande elementen. Het protocol, hetwelke wordt beschreven door het CODEC proces omvat volgende stappen: 1. Verdeelt het frame onder individuele bytes.

ge s

2. Plaatst een TSS bij het begin van een sequentie. 3. Voegt een FSS op het einde van de TSS.

ot eHo

4. Maakt een uitgebreide byte sequentie voor iedere byte in het frame. Dit wordt gedaan door het plaatsen van een BSS voor iedere byte. 5. Creëert een continue bitstroom door het aaneenschakelen van deze byte sequenties. 6. Berekent de CRC en voegt deze aan de bitstroom.

Gr

7. Appendeert een FES op het einde van een bitstroom.

Figuur 3.51: FlexRay Codering

py rig

ht

20

11

Ka re

ld

e

8. Indien het frame wordt verstuurd in het dynamisch segment, wordt een DTS geappendeert

3.8.7.2 symbool codering

Co

FlexRay specifieert 3 types van symbolen die worden voorgesteld door 2 verschillende symboolbitpatronen. • Collision Avoidance Symbol(CAS) en Media Access test symbol (MTS): De node codeert het CAS en MTS symbool op exact dezelfde manier. Ontvangers maken het onderscheid tussen beide symbolen door de protocolstatus (zie verder) van de node. Het coderingsproces maakt geen onderscheid voor deze 2 symbolen. Het CAS symbool start met het TSS symbool, gevolgd door een LAAG niveau met een duurtijd van cdCAS. • WakeUp symbol (WUS): Het wake up signaal bestaat uit een aantal lage ”gdWakeupSymbolTxLow”bits gevolgd door een aantal hoge ”gdWakeupSymbolTxIdle”bits. Een node genereert een wake-up patroon (WUP) door het verschillend maal herhalen van het wake up symbool NCC-2011-001

KdG–IWT

Automotive Software

90

Gr

ot eHo

ge s

Figuur 3.52: FlexRay CAS en MTS symbool

ch o

ol


Ka re

3.8.7.3 sampling en majority voting

ld

e

Figuur 3.53: FlexRay WUS symbool

11

Een node zal bemonstering doen op iedere ontvangen input RxD van beide kanalen. Voor iedere klokperiode (8 keer de netwerksnelheid) van elk kanaal zal de node het niveau van de bus digitaliseren. De node slaat kortstondig de meest recente metingen van de input op.

20

De node zal een meerderheidskeuze maken over de gedane RxD metingen. Het doel van de meerderheidskeuze is het uitfilteren van spanningspieken in het RxD inputsignaal ( het ”sampled RxD”signaal is de ingang en het ”voted RxDïs de uitgang ).

py rig

ht

Het voting window is een schuifregister met 5 samples waarin de laatste meting telkens aan de rechterkant wordt ingevoerd en bij iedere meting één bit naar links doorschuift. Doordat we telkens een oneven aantal bits in het schuifregister hebben zal ofwel het aantal hoge of het aantal lage signalen de meerderheid hebben.

Co

De decoder zal continu de laatst opgeslagen metingen ”cVoting samplesëvalueren. Dit zijn de metingen binnen het keuze venster. De decoder zal het aantal HOGE metingen optellen. Indien de meerderheid van de metingen HOOG zijn, dan zal het uitgangssignaal ”zVotedVal”hoog zijn. Figuur 3.54 geeft een voorbeeld van sampling en meerderheidskeuze. Spanningspieken die slechts gedurende één of twee klokperiodes aanwezig zijn worden onderdrukt. Het gefilterd signaal ”zVotedVal”heeft een vaste vertraging van enkele klokperiodes tegenover RxD.

NCC-2011-001

KdG–IWT

Automotive Software

91

ch o

ol


Protocol Operation Control (POC)

ot eHo

3.8.8

ge s

Figuur 3.54: Flexray Majority Voting

3.8.8.1 Principes

ld

e

Gr

In dit hoofdstuk wordt beschreven hoe de core-mechanismen worden gemodelleerd in antwoord op de commando’s van de host en de protocol condities. Met de POC wordt het Protocol Operation Control bedoeld. Dit is een term die nog veel zal voorkomen in deze bespreking en zal daarom altijd worden afgekort met POC. De POC omvat alle functies die uitgevoerd moeten worden binnen het FlexRay protocol. Er zijn 4 core-mechanismen opgenomen in het FlexRay protocol:

2. Media Access Controle 3. Frame en Symbool Processen

20

11

4. Kloksynchronisatie

Ka re

1. Codering en decodering

3.8.8.2 POC status diagram

py rig

ht

Er zijn verschillende toestanden die een node doorloopt om volledig operationeel te worden. Vanaf het moment dat de communicatie-controller de POC operational toestand heeft bereikt, spreken we over elke toestand als de POC:[toestand].

Co

• POC:default config: Deze toestand zal aangenomen worden zodra de communicatie-controller het POC operational status bereikt. De POC:default config toestand kan ook binnengegaan worden vanuit de POC:halt fase. Eénmaal in de POC:default config toestand, zullen alle standaard instellingen worden aangenomen. Er zal nu gewacht worden op bevelen van de host betreffende aanpassingen van deze configuratie. Dan zal overgegaan worden naar de POC:config toestand. • POC:config: In de POC:config toestand zal de host de communicatie-controller configureren. Dit is de enige toestand waarin instellingen van de node gewijzigd kunnen worden. Bepaalde instellingen zijn bijvoorbeeld het vooropgestelde kanaal dat de node zal moeten activeren binnen de wakeup procedure wanneer we spreken over coldstart node’s. De POC:config toestand kan ook terug bereikt worden vanuit de POC:ready toestand. Op deze manier moet de node NCC-2011-001

KdG–IWT

Automotive Software

92

Figuur 3.55: FlexRay core-mechanismes

Co

py rig

ht

20

11

Ka re

ld

e

Gr

ot eHo

ge s

ch o

ol


NCC-2011-001

KdG–IWT

Automotive Software

93

e

Gr

ot eHo

ge s

ch o

ol


ld

Figuur 3.56: FlexRay POC status diagram

Ka re

niet steeds opnieuw geïnitialiseerd worden voor het veranderen van bepaalde instellingen. Indien de communicatie-controller correct is geconfigureerd wordt een signaal terug gestuurd naar de host CONFIG_COMPLETE.

20

11

• POC:ready: In deze toestand is de node gereed voor het starten van bepaalde procedures zoals wakeup en startup. Alle instellingen zijn aangenomen en de communicatie-controller wacht op verdere instructies van de host.

py rig

ht

• POC:wakeup: De host zal een wakeup bevelen wanneer wordt waargenomen dat een kanaal nog niet opgewekt is. Dit wil zeggen dat de node’s op dat kanaal zich nog altijd in de slaapmodus bevinden. De wakeup procedure zal gestart worden. Nadat de wakeup procedure voltooid is, zal de POC:ready toestand terug aangenomen worden.

Co

• POC:startup: Wanneer wordt waargenomen dat een kanaal al reeds opgewekt is, zal er overgegaan worden naar de startup procedure. Deze procedure zal de communicatie in een netwerk starten. Een succesvolle startup zal dan ook resulteren in de POC:normal active toestand waarin zonder problemen frames verzonden en ontvangen kunnen worden. • POC:normal active: Dit wordt bereikt na een succesvolle startup procedure. In deze toestand wordt aangenomen dat de node errorvrij is of dat errors zodanig binnen grenzen liggen dat de normale werking van de node nog verzekerd wordt. De node blijft voldoende gesynchroniseerd binnen het tijdsschema zodat de communicatie binnen het netwerk niet verstoord wordt. • POC:normal passive: Binnen deze toestand is de synchronisatie met het tijdsschema zo ver achteruit gegaan, dat het verzenden van frames zou kunnen leiden tot botsingen met andere node’s. De node zal geen frames meer verzenden, maar wel ontvangen. Aan de hand van ontvangen frames zal de node proberen zichzelf terug te synchroniseren. Wanneer de node terug synchroon loopt zal deze weer overgaan naar de POC:normal active toestand. NCC-2011-001

KdG–IWT

Automotive Software


94

• POC:halt: Wanneer errors blijven plaatsvinden in de POC:normal passive toestand of wanneer errors erg genoeg zijn, zal de communicatie-controller over gaan naar de POC:halt toestand. Er wordt aangenomen dat het niet mogelijk is om terug te gaan naar de POC: normal active toestand en dus worden POC acties stop gezet zodat de node opnieuw geïnitialiseert kan worden.

ol

Wakeup en Startup procedure

ch o

3.8.9

ot eHo

ge s

In deze sectie beschrijven we de overgang van de cluster slaap mode naar de volledig operationele mode. We beschrijven tevens de integratie van nodes in een reeds werkende cluster. We starten met een overzicht van hoe een cluster kan worden gewekt. Daarna zien we hoe een cluster volledig operationeel wordt.

3.8.9.1 Wakeup

Wakeup is de procedure om alle nodes in een cluster van de slaapmodus naar readymodus te brengen.

py rig

ht

20

11

Ka re

ld

e

Gr

We nemen aan dat alle busdrivers van voeding zijn voorzien. Een busdriver kan de andere delen van een node wakker maken zijnde de host en de communicatie-controller wanneer hij een wakeup patroon ontvangt op zijn kanaal. Dit gebeurt wanneer de busdriver een wake up patroon ontvangt op één van zijn kanalen. Tenminste één node moet extern gewekt worden. De host controleert volledig de wake-up procedure. De communicatie-controller geeft de host de mogelijkheid tot het onafhankelijk zenden van een speciaal wakeup patroon op elk van zijn beschikbare kanalen. Het wakeup patroon mag niet op beide kanalen tegelijk verstuurd worden om te voorkomen dat een defecte node de communicatie op een cluster verstoort. De host configureert welk kanaal door de commnicatiecontroller kan worden gewekt. De controller zorgt ervoor dat de communicatie die op het kanaal komt niet wordt verstoord. Zelfs een node die slechts met één kanaal is verbonden kan de cluster wakker maken. Wanneer een wakeup patroon is verstuurd zullen alle andere foutvrije nodes dit ontvangen en wakker worden. De bus driver en communicatie-controller kunnen dit patroon herkennen. De bus driver dient dit patroon te herkennen om de andere onderdelen van de node te ontwaken. De communicatie-controller moet het alleen hebben om botsingen van het wakeup patroon op te lossen. De communicatie-controller kan niet controleren of alle nodes die aan het kanaal zijn gekoppeld zijn gewekt na het versturen van het wakeup patroon, gezien de nodes geen feedback kunnen geven tot aan de startup fase. De host is zich bewust van eventuele fouten bij de wakeup en zal hiernaar reageren. De procedure is fout tolerant. Deze probeert de situatie op te lossen wanneer meerdere nodes tegelijk proberen de cluster te wekken. Indien twee patronen toch tegelijk verstuurd worden zal het resulterende patroon toch nog de andere nodes wekken.

Co

De host configureert het wakeup kanaal wanneer de communicatie-controller zich in de configuratie toestand bevindt. Bij het begin van een wakeup toestand zal geluisterd worden of er nog communicatie is op het kanaal. Deze periode duurt ten minste langer dan een wakeup procedure om te voorkomen dat een wakeup patroon wordt vertuurd op een kanaal dat reeds is gewekt. Wanneer communicatie wordt gedetecteerd, zal de procedure worden onderbroken. Wanneer geen communicatie wordt gedetecteerd zal de controller het wakeup patroon op het desbetreffende kanaal versturen. De host initialiseert de procedure wanneer de communicatie-controller in de ready toestand is. De communicatie-controller verlaat dan de ready toestand, begint met de wakeup procedure en probeert een wakeup patroon te versturen op het betreffende kanaal.

NCC-2011-001

KdG–IWT

Automotive Software

95

ot eHo

ge s

ch o

ol


Gr

Figuur 3.57: FlexRay wakeup status diagram

Ka re

ld

e

De communicatie-controller kan niet tijdens het versturen van een wakeup patroon detecteren of een andere node tegelijk een wakeup patroon verstuurt. Daarom gaat de sturende node luisteren naar het kanaal op de rustfases van het wakeup patroon. Indien er geen communicatie werd gedetecteerd gedurende de rustfases, was de verzending succesvol. Indien er activiteit was op de bus tijdens het versturen van een wakeup signaal, dan gaat de controller naar een monitoring status. In deze status gaat de controller de oorzaak van de botsing trachten te achterhalen.

20

11

De communicatie-controller keert dan terug naar de ready toestand en signaleert de status van de wakeup poging naar de host bij het completeren van de wakeup procedure • UNDEFINED: De controller heeft de wakeup procedure niet uitgevoerd.

py rig

ht

• RECEIVED_HEADER: Wanneer de controller een frame header zonder code aantasting heeft ontvangen op één van beide kanalen tijdens de initiële luisterfase. • RECEIVED_WUP: Wanneer de controller een geldig wakeup frame heeft ontvangen op het geconfigureerde kanaal gedurende de intiële luisterfase.

Co

• COLLISION_HEADER: De controller heeft een collision herkend tijdens het versturen van het wakeup patroon door het ontvangen van een geldige header tijdens de detectie fase in het wakeup patroon. • COLLISION_WUP: De controller heeft een collision herkend tijdens het versturen van het wakeup patroon door het ontvangen van een wakeup patroon tijdens de detectie fase in het wakeup patroon. • COLLISION_UNKNOWN: De controller heeft een collision herkend tijdens het versturen van het wakeup patroon zonder een geldig signaal te ontvangen.. • TRANSMITTED: Het patroon was succesvol verstuurd. NCC-2011-001

KdG–IWT

Automotive Software


96

Voorbeeld van een enkelskanaals wakeup: 1. De host configureert de communicatie-controller. De koudstart inhibit mode zal gestart worden door het setten van de koudstartinhibit flag 2. De host controleert of een wakeup patroon was ontvangen door de busdriver.

ol

3. De host plaatst de busdriver in normale mode.

ge s

ch o

4. Indien een wakeup patroon was ontvangen zou de node een startup procedure dienen te starten in plaats van een wakeup te doen. Indien geen wakeup patroon is ontvangen door de busdriver, kan deze een wakeup starten van het aangekoppeld kanaal. Dit kan eventueel lijden tot een wakeup van beide kanalen indien het over een tweekanaalscluster gaat. 5. De host configureert de wakeup kanaal parameter naar de communicatie-controller.

ot eHo

6. De host beveelt de controller tot de start van de wakeup procedure.

7. De communicatie-controller zendt het resultaat van de wakeup poging terug

Gr

8. De host beveelt de communicatie-controller om de koudstart inhibit flag te clearen en de startup procedure te beginnen. Voorbeeld van een dubbelkanaals wakeup:

ld

e

1. De host configureert de communicatie-controller. Hij veronderstelt dat beide kanalen in rust zijn. De koudstart inhibit mode zal geset worden.

Ka re

2. De host controleert welk kanaal een wakeup patroon heeft ontvangen. 3. De host plaatst de busdrivers in de normale mode.

11

4. Indien beide kanalen wakker zijn gaat deze over naar stap 11. Indien beide kanalen in slaap zijn, zal de host één van beide wakker maken. Indien één kanaal in slaap mode is en de andere is wakker, dan kan het andere kanaal worden wakker gemaakt(1).

20

5. De host configureert de wakeup kanaal parameter. 6. De host activeert de busdriver van het betreffende kanaal dat dient te worden gewekt.

ht

7. De host beveelt de controller om de wakeup procedure te starten.

py rig

8. De controller stuurt het resultaat van de wakeup poging terug.

Co

9. Indien het resultaat TRANSMITTED is, neemt de host aan dat het kanaal wakker is en gaat verder naar stap 11. Indien het resultaat RECEIVED_HEADER of COLLISION_HEADER is, neemt de host aan dat beide kanalen wakker zijn. De host gaat naar stap 11. Wanneer het resultaat RECEIVED_WUP or COLLISION_WUP is, neemt de host aan dat het geconfigureerde kanaal wakker is en gaat terug naar stap 4. In het laatste geval bij COLLISION_UNKNOWN zal een applicatie specifiek herstel noodzakelijk zijn. 10. De host beveelt de communicatie-controller om de start up te beginnen. 11. Indien beide kanalen wakker zijn, gaat de host bevel geven aan de controller om de coldstart inhibit mode te clearen. Zoniet zou de host wachten op bevestiging van de bus driver betreffende ontvangst van een wakeup patroon. De bus driver wordt dan weer in de normale mode geplaatst. Zodra alle kanalen wakker zijn beveelt de host de controller om de coldstart inhibit mode te verlaten. NCC-2011-001

KdG–IWT

Automotive Software

97

ot eHo

3.8.9.2 Startup

ge s

Figuur 3.58: FlexRay wakeup voorbeeld

ch o

ol


Alvorens een startup kan worden geïntialiseerd dient de cluster wakker te zijn. In tegenstelling tot de wakeup procedure wordt de startup procedure op beide kanalen tegelijk uitgevoerd.

Gr

Alleen een beperkt aantal nodes kan een coldstart initialiseren, deze nodes worden coldstart nodes genoemd. Binnen FlexRay bestaan er 4 verschillende nodes zijnde de leidende coldstart node, de volgende coldstartnodes, de synchronisatienodes en de gewone nodes.

Ka re

ld

e

Een coldstart begint met de transmissie van een Collision Avoidance Symbol (CAS). De node die dit symbol verstuurt is de enige node die startup frames kan versturen binnen de 4 eerste cycli achter het CAS. Deze node is de leidende coldstart node. Hierna kunnen andere coldstart nodes toetreden, deze worden volgende coldstart nodes genoemd. Finaal kunnen de niet-koudstartnodes de startup procedure beëindigen.

ht

20

11

coldstart nodes dienen te worden verbonden met alle kanalen van de cluster. Alle koudstartnodes kunnen de startup initialiseren. Iedere coldstartnode eindigt zijn startup procedure wanneer één van deze een stabiele communicatie heeft opgezet met een andere coldstart node. Niet coldstart nodes vereisen startupframes van ten minste 2 coldstart nodes. In netwerken met meer dan 3 nodes moeten er minstens 3 coldstart nodes zijn. In kleinere netwerken moeten alle nodes als coldstart nodes geconfigureerd worden.

py rig

De coldstart inhibit vlag verzekert dat de node zelf geen startupframes kan versturen. Hierdoor kan de node niet actief een startup beginnen. Het kan wel startupframes versturen éénmaal de leidende coldstart node het leidende coldstart kanaal heeft gekozen.

Co

De communicatie-controller kan de normale werkingsstatus binnen treden via 3 verschillende wegen. Twee van deze paden zijn beperkt voor coldstart nodes, terwijl één pad voorzien is voor niet coldstart nodes. Het status diagram hierachter is een vereenvoudigde versie van het echte diagram. Alle error paden zijn weggelagen. Zie Figuur 3.59 • Pad van de leidende coldstart node: Een coldstart node start de procedure door te luisteren naar de bus. Enkel wanneer er geen communicaite op de bus is zal deze een coldstart procedure beginnen. In de eerste cyclus zal hij een CAS (Collision Avoidance Symbol) symbool versturen. Vanaf dat moment zal de node startup frames versturen. Wanneer verschillende nodes een CAS symbool willen versturen zal dit voorkomen worden zodanig dat slechts één enkele node op de bus komt. Wanneer geen fouten worden gesignaleerd, gaat de node in werking. Vanaf de 5 de cyclus kunnen andere coldstart nodes beginnen met startup frames te versturen. NCC-2011-001

KdG–IWT

Automotive Software


98

• Pad van de volgende coldstart nodes: De volgende coldstart node probeert te integreren in het schema. Hij zal klokcorrecties uitvoeren en hieruit het tijdschema halen. Vanaf de 5 de cyclus van de leidende coldstart node zal hij zijn eigen startup frames versturen. Indien voor de volgende 3 cyclussen de klokcorrectie geen fouten signaleert en het signaal van de leidende coldstart node correct op de bus komt zal de volgende coldstart node in werking treden.

ht

20

11

Ka re

ld

e

Gr

ot eHo

ge s

ch o

ol

• Pad van een niet coldstart node: Niet coldstart nodes hebben frames nodig van tenminste 2 coldstart nodes. Wanneer de niet coldstart node startup frames ontvangt gedurende 4 cycli, zal de niet coldstart node klokcorrecties uitvoeren en zien of deze passen in zijn schema. De niet coldstart nodes komen operationeel na het ontvangen van geldige startupframes van 2 opeenvolgende dubbele cycli van tenminste 2 coldstartnodes. Niet coldstart nodes moeten ten minste 8 cylci hebben ontvangen na het versturen van het CAS symbol van de leidende coldstart node, alvorens deze operationeel worden.

py rig

Figuur 3.59: FlexRay startup procedure

We kunnen volgende toestanden onderscheiden:

Co

• COLDSTART_LISTEN: In deze status zal de coldstart node proberen vast te stellen of er al dan niet al frames worden verstuurd en of er al dan niet al coldstart pogingen worden ondernomen. Wanneer een geldig startup frame is gedetecteerd, probeert de coldstart node te integreren op de andere coldstart node. Het verlaat de COLDSTART_LISTEN status en begint de INITIALIZE_SCHEDULE status. Wanneer geen CAS symbool of een startup frame is gedetecteerd binnen een vooropgestelde tijdsduur, volgt de coldstart node het pad van de leidende coldstart node. De coldstartnode gaat dan over naar de COLDSTART_COLLISION_RESOLUTION status. • COLDSTART_COLLISION_RESOLUTION: De bedoeling is om botsingen tussen verschillende coldstart pogingen van coldstart nodes te detecteren en op te lossen. Het aantal keren dat een node in deze status mag komen is vooraf bepaald, dit is het aantal keren dat een NCC-2011-001

KdG–IWT

Automotive Software


99

node een coldstart mag initiëren. Wanneer een complete header of CAS symbool is ontvangen zal de communicatie-controller de coldstart onmiddellijk stop zetten. Hierdoor blijft maar één node op het leidende coldstart pad. De node zendt zijn startup frames gedurende de eerste 4 cylci en gaat de COLDSTART_CONSISTENCY_CHECK status beginnen.

ge s

ch o

ol

• COLDSTART_CONSISTENCY_CHECK: In deze status controleert de leidende coldstart node of de frames verstuurd door een andere coldstart node passen in zijn schema. Niet-coldstart nodes zullen in deze fase nog geen frames verzenden. Indien geen geldige frames ontvangen worden in de even cylci, wordt aangenomen dat de andere coldstartnodes nog niet klaar waren om hun eigen schema te initialiseren. Wanneer dit gebeurt zal de COLDSTART_GAP fase worden binnen gegaan en zal dezelfde node een andere coldstart poging proberen. Indien een geldig startup frame wordt ontvangen in de even cyclus maar er zijn fouten in de oneven cyclus dan wordt de coldstart poging vroegtijdig afgesloten. Enkel wanneer geldige startup frames in de even en oneven cycli worden ontvangen gaat de node in werking.

ot eHo

• COLDSTART_GAP: De leidende coldstart node stopt met het versturen van startup frames. Alle andere nodes die proberen hierop te integreren stoppen met hun poging. Indien een CAS of geldig frame is ontvangen gedurende één cyclus, onderbreekt de node zijn coldstart poging. De coldstartnode gaat opnieuw naar de COLDSTART_COLLISION_RESOLUTION status.

ld

e

Gr

• INITIALIZE_SCHEDULE: Wanneer een node een geldig startupframe ontvangt in de luisterfase gaat de node naar de INITIALIZE_SCHEDULE fase. Indien een node een tweede geldig startup frame ontvangt, gaat de klok synchronisatie hieruit zijn werkschema opmaken. Indien geen tweede geldig startupframe wordt ontvangen, gaat de node terug naar de INTEGRATION_LISTEN toestand.

Ka re

• INTEGRATION_COLDSTART_CHECK: Nazicht of de klok-aanpassingen juist kunnen worden uitgevoerd. Indien enige fout wordt gesignaleerd, wordt de integratie afgebroken. De node moet een paar van geldige startupframes ontvangen.

20

11

• COLDSTART_JOIN: Alleen de coldstart node’s die de leidende node volgen, zullen deze fase doorlopen. Bij het binnengaan van deze fase starten ze met de transmissie van startup frames. De node’s blijven dit herhalen in de volgende cyclussen. Hierdoor kunnen de leidende node en de volgende node’s nakijken of hun schema’s overeenkomen met elkaar. Wanneer tijdens deze fase de node’s aan de hand van de startup frames synchroon kunnen lopen, zal de node de startup verlaten en de operationale toestand binnengaan.

py rig

ht

• INTEGRATION_LISTEN: In deze status wacht de node op een geldig startup frame of op het moment waarop coldstart verboden modus wordt verlaten. Wanneer er dan een geldig startup frame wordt ontvangen zal de INITIALIZE_SCHEDULE status worden gestart.

Co

• INTEGRATION_CONSISTENCY_CHECK: Alleen niet-coldstart node’s passeren deze fase. In deze fase zal de node namelijk controleren of de klok correcties correct uitgevoerd kunnen worden en of er genoeg coldstart node’s startup frames aan het verzenden zijn die overeenkomen met het eigen schema van de node. In de eerste even cyclus dient een geldig frame van de leidende node of 2 geldige frames van andere coldstart nodes worden ontvangen. Daarna dienen 2 geldige startup frame paren van 2 opeenvolgende dubbele cycli te worden ontvangen om te kunnen overstappen naar de actieve werking.

3.8.10

Klok synchronisatie

In een netwerk heeft elke node zijn eigen klok. Men probeert er voor te zorgen dat de interne klok van alle node’s steeds gelijk loopt. Maar door temperatuurschommelingen, spanningsschommelingen en NCC-2011-001

KdG–IWT

Automotive Software

100

ot eHo

ge s

ch o

ol


Figuur 3.60: Flexray startup voorbeeld

Tijdhiërarchie

Co

py rig

ht

20

11

Ka re

3.8.10.1

ld

e

Gr

productie toleranties, kan de interne klok van een node in de kring na verloop van tijd afwijken van de interne klok van andere node’s. Zelfs als alle node’s eerst synchroon liepen. Aangezien binnen het FlexRay protocol communicatie synchroon verloopt, is het van groot belang dat alle node’s zich houden aan hetzelfde tijdsschema. Daarom moeten de node’s steeds weer gesynchroniseerd worden als blijkt dat de interne klok van een node begint af te wijken.

Figuur 3.61: FlexRay tijdshiërarchie

• Microticks zijn tijdseenheden die direct afgeleidt zijn van de oscillator klok van de communicatiecontroller van de node gebruik makend van een prescaler. Microticks zijn dan ook controllerspecifieke eenheden. Ze kunnen een verschillende lengte hebben bij verschillende communicatiecontrollers en kunnen dus niet gesynchroniseerd worden tussen de verschillende nodes. • Macroticks zijn de kleinste tijdseenheden die gesynchroniseerd worden tussen de node’s binnen een netwerk. Binnen toleranties is de lengte van een macrotick in een netwerk dus gelijk. Elke NCC-2011-001

KdG–IWT

Automotive Software


101

macrotick bestaat uit een aantal microticks. Maar het aantal microticks per macrotick kan dus verschillen binnen een node, maar ook van controller tot controller.

ol

• Een cyclus bestaat uit een aantal macroticks. Het aantal macroticks per cyclus zal identiek zijn voor alle node’s binnen een netwerk en zal ook gelijk blijven voor elke cyclus. Op elk moment moeten de node’s dus tegelijk dezelfde cyclus nummer hebben. Dit wordt bijgehouden met de cycle counters van de node’s.

3.8.10.2

ge s

ch o

• Wanneer een node dus vaststelt dat zijn lokale tijd niet meer synchroon loopt met de globale tijd, zal hij bij bepaalde macroticks een zeker aantal microticks toevoegen of afnemen. Dit wordt gedaan totdat de node terug binnen de grenzen gesynchroniseerd is.

Fault tolerant midpoint (FTM) algoritme

Ka re

ld

e

Gr

ot eHo

Voor kloksynchronisatie gebruikt FlexRay een verdeeld algoritme. Sommige node’s in de cluster dienen te worden geconfigureerd als synchronisatie node’s. Ieder van deze nodes kan één synchronisatieframe zenden in het statisch segment van een cyclus. Ten minste 3 nodes dienen te worden geconfigureerd als synchronisatienode, met een maximum van 15 node’s. Deze nodes dienen aan beide kanalen van het netwerk te worden gekoppeld. Het synchronisatieframe wordt verstuurd op beide kanalen in hetzelfde statische slot. Alle nodes meten het tijdverschil ( in microtics ) tussen de verwachte en waargenomen aankomsttijd van de sycnchronisatie frames ontvangen in het statisch segment en dit per kanaal. Deze waarden worden opgeslagen in een dridimentionele matrix met de dimenties lijn nummer, kanaal nummer en cyclus nummer ( even of oneven ). Iedere dimentie heeft een afwijkingswaarde ( negatief of positief ), een booleaanse indicatie die aangeeft of de data geldig is en een booleaanse indicatie die aangeeft dat het syncronisatieframe een startup frame was. Op deze gegevens wordt een fouttolerant midpoint algoritme toegepast. Het algoritme werkt als volgt:

11

1. Een parameter k wordt berekend, gebaseerd op het aantal waardes in de lijst.

20

• k = 0 wanneer 1 - 2 waardes in de lijst zijn. • k = 1 wanneer 3 - 7 waardes in de lijst zijn. • k = 2 wanneer meer dan 7 waardes in de lijst zijn.

py rig

ht

2. De gemeten waarden worden gesorteerd en de k grootste en k kleinste waardes worden geschrapt.

Co

3. De grootste en de kleinste waardes die overblijven worden gebruikt voor het berekenen van het middenpunt. Van deze 2 waardes wordt het gemiddelde genomen en deze waarde wordt gebruikt als de correctieterm. De berekende waardes worden vergeleken met vooraf geconfigureerde limieten. Indien de berekende waardes binnen deze limieten vallen dan wordt de node aanzien als zijnde gesynchroniseerd. Wanneer één van de waardes ( offset of rate ) niet binnen deze limieten is, gaat de node in de passieve of halt mode afhankelijk van het geconfigureerd verloop.

3.8.10.3

Berekening van de Offset correctie waarde

De offset correctie of fase correctie wordt toegepast om te verzekeren dat de cylci beginnen op hetzelfde moment binnen een cluster. De berekening van de offset correctie gebeurt in iedere cyclus, NCC-2011-001

KdG–IWT

Automotive Software


102

maar de aanpassing gebeurt enkel in de onevencycli. Wanneer de correctiewaarde is berekend, zal de Netwerk rusttijd van de oneven cycli verlengd of verkort worden. De berekening is gebaseerd op één enkele cyclus en moet voltooid zijn alvorens de offset correctiefase begint.

ol

• Selectie van de opgeslagen afwijkingswaardes. Enkel waardes gemeten in de huidige communicatiecyclus worden gebruikt. Indien een synchronisatie frame ID een verschillende waarde heeft voor kanaal A en kanaal B, dan zal de kleinste waarde geselecteerd worden.

ge s

• Het fouttolerante midpoint algoritme wordt uitgevoerd.

ch o

• Het aantal synchronisatieframes wordt gecontroleerd. Wanneer geen synchronisatieframes ontvangen worden, dan wordt een error flag gezet.

3.8.10.4

Berekening van de Rate Correctie waarde

ot eHo

• De corectieterm wordt vergeleken met specifieke limieten. Indien de correctieterm te lang of te kort is, dan wordt deze op de minimale of de maximale waarde gezet. Een error flag wordt gezet.

Ka re

ld

e

Gr

De rate correctie of frequentie correctie zorgt ervoor dat de tijdsduur van een macrotick ( en diengevolge een cyclus ) voor iedere node even groot is. Rate correctie wordt geïmplementeerd door het toevoegen of verwijderen van een aantal microticks in een macrotick. De berekening gebeurt na het statisch segment van een oneven cyclus. De berekening gebeurt over de statische segmenten van een dubbele cyclus.

11

• Paren van afwijkende waarden worden geselecteerd. Deze paren zijn synchronisatieframes ontvangen op hetzelfde kanaal in hetzelfde statische slot van twee opeenvolgende communicatiecyli. De verschillen in tijd tussen de synchronisatieframes van een paar worden berekend. Indien er 2 paren zijn voor een gegeven frame ID (kanaal A en kanaal B) dan wordt het gemiddelde genomen van beide.

20

• Het nummer van de ontvangen synchronisatieframes wordt gecontroleerd. Een errorflag wordt geset indien geen synchronisatieframes worden ontvangen.

ht

• Het fout-tolerante midpoint algoritme wordt uitgevoerd.

py rig

• Een dempingswaarde wordt toegepast op de berekende waarde.

Co

• De correctieterm wordt gecontroleerd met specifieke limieten.

NCC-2011-001

KdG–IWT

Automotive Software

Departement Industriële Wetenschappen en Technologie Academiejaar Cursuscode(s): KdG-IWT-MA-EI Automotive Software

Recommend Documents