A CAN To FlexRay Migration Framework

Waterford Institute of Technology
Ireland
InstitiidTeicneolaochtaPhortLirge
ire
A CAN to FlexRay Migration

Framework
Richard Murphy B.Sc. (Hons)
M.Sc. Thesis
(Supervisor)Frank
Walsh B.A., B.A.I., M.Sc.
SubmittedtoWaterfordInstituteofTechnologyAwardsCouncil,September2009
Acknowledgments
Acknowledgments
Iwouldliketothanksincerelythefollowingpeople,forwithouttheirinputthisthesis
wouldnothavebeenpossible.
IwouldliketothankmysupervisorFrankWalshforhisideasandinputespeciallywhen
thingswerenotgoingtoplanhewasalwayswillingtogiveuphistimetodiscussany
issues.Iwouldalsoliketothankthegroupleader,BrendanJackmanforhisassistance
andinputanytimeitwasaskedofhim.AbigthankyoumustgotoGareth,Roband
WeiDawhohelpedmeanytimeIaskedevenwhiletheywerebusyconductingtheir
ownresearch.
I would like to thank Sumitomo Ystrad. The financial backing of Sumitomo has made
this thesis possible. I would like to especially thank Paul, Jim and Eamonn whose
hospitalityandassistancewassecondtononeduringmyvisitsthere.
FinallyIwouldliketothankmyparentsMiloandKittywhobackedmebothfinancially
andwithencouragement.WithoutthemIwouldnotbewhereIamnow.
Declaration
Declaration
IRichardMurphy,declarethatthisthesisissubmittedbymeinpartialfulfilmentofthe
requirement for the degree M.Sc., is entirely my own work except where otherwise
accredited.Ithasnotatanyothertimewholeorinpartbeensubmittedforanyother
educationalaward.
Signature:
RichardMurphy
9thofOctober2009
ii
Abstract
Abstract
Oneofthefirstelectronicscomponentsusedinanautomobilewasthefuse.Additional
features were developed such as engine management systems. These additional
featuresincreasedtheamountofwiringinawiringharness.Thiscontributedtowards
thenecessitytodevelopthebusstructureinthe1980s.Thedefactobusstructurein
the automotive industry became CAN (Controller Area Network). By using a bus
structure this resulted in less hard wiring being required in the production of an
automobile which further lead to a reduction in production cost. CAN is an event
triggered protocol which denotes it is nondeterministic and it has a theoretical
bandwidthlimitof1Mbit\s.Thepracticallimitisnearer500kbit\s.Duringthe80sand
90s, automotive electronics development increased; this was primarily driven by
increaseddevelopmentofsafetyfeaturessuchasABS(AntilockBrakingSystem).The
increaseinthenumberoffeaturesandnodescausedincreasedtrafficonthebus.The
CANprotocolwillbeunabletomeettherequirementsfortheextraapplications.
This resulted in the development of FlexRay in 2000 by a consortium originally

consisting of amongst others BMW, Daimler Chrysler, Freescale and Philips. This
protocol can implement both timetriggered and eventtriggered messages,
determinism, fault tolerance, redundancy and can operate at 10Mbit\s. Newly
developedtechnologieshavehighinitialcoststhereforebeinginitiallymoreexpensive
than established technologies. This could result in it being financially unworkable to
replace a complete automotive bus with FlexRay. FlexRay can possibly be used for
mission critical applications such as powertrain applications, while other protocols
suchasCANandLIN(LocalInterconnectNetwork)maypossiblybeusedforlesscritical
applications.
The aim of this research is to design and develop a framework that allows the
implementationofaCANapplicationontheFlexRayprotocol,without degradingthe
applicationsperformance.
iii
TableofContents
Table of Contents
Acknowledgments.......................................................................................................i
Declaration.................................................................................................................ii
Abstract.....................................................................................................................iii
TableofContents......................................................................................................iv
TableofFigures..........................................................................................................x
TableofTables.........................................................................................................xv
TableofEquations..................................................................................................xvii
SectionIThesisOverview.........................................................................................1
1
ThesisOverview:.................................................................................................2
1.1
ProblemSpecification.....................................................................................2
1.2
SpecifiedSolution...........................................................................................3
1.3
ResearchQuestions........................................................................................4
1.4
DocumentLayout...........................................................................................5
SectionIILiteratureReview......................................................................................7
2
AutomotiveNetworksReview:...........................................................................8
2.1
Introduction....................................................................................................8
2.2
ComputerNetworks.......................................................................................8
2.3
NetworkFunction...........................................................................................9
2.4
NetworkTopologies......................................................................................10
2.5
LAN(LocalAreaNetwork)&WAN(WideAreaNetwork).............................13
2.6
CommunicationProtocol..............................................................................14
2.7
AutomotiveNetworksHistory......................................................................15
2.8
AutomotiveNetworksDescription................................................................16
iv
TableofContents
2.9
ECU...............................................................................................................20
2.10
AutomotiveNetworkProtocols....................................................................22
2.11
Conclusion....................................................................................................25
2.12
References....................................................................................................27
CAN(ControllerAreaNetwork):........................................................................28
3.1
Introduction..................................................................................................28
3.2
CANPhysicalStructure.................................................................................29
3.3
CANFrameFormat.......................................................................................30
3.4
BusArbitration..............................................................................................34
3.5
CANErrorHandling.......................................................................................35
3.6
CANProtocolFeatures..................................................................................39
3.7
TTCAN(TimeTriggeredControllerAreaNetwork)Introduction...................40
3.8
Conclusion....................................................................................................43
3.9
References....................................................................................................44
FlexRay:............................................................................................................45
4.1
Introduction..................................................................................................45
4.2
FlexRayFeatures...........................................................................................46
4.3
FlexRayCycleStructure.................................................................................48
4.4
FlexRayNodeStructure................................................................................50
4.5
FlexRayFrameStructure...............................................................................52
4.6
FlexRayTimingHierarchy..............................................................................56
4.7
CommunicationCycle...................................................................................58
4.8
Conclusion....................................................................................................62
4.9
References....................................................................................................63
AutomotiveEmbeddedSystemsDesign:...........................................................64
5.1
AutomotiveEmbeddedSystemDesign.........................................................64
TableofContents
5.2
DistributedArchitecturesIntroduction.......................................................64
5.3
RealTimeOperatingSystem(RTOS).............................................................66
5.4
OSEK/VDX.....................................................................................................67
5.5
ProcessModels.............................................................................................70
5.6
TaskSchedulingPolicies................................................................................70
5.7
TaskGraphs..................................................................................................74
5.8
CriticalPathAnalysis(CPA)...........................................................................74
5.9
TaskGraphAnalysis......................................................................................77
5.10
DesignProcess..............................................................................................87
5.11
Conclusion....................................................................................................90
5.12
References....................................................................................................91
AutomotiveNetworkMigration:.......................................................................93
6.1
AutomotiveNetworkMigration....................................................................93
6.2
Introduction..................................................................................................93
6.3
ProtocolMigrationRequirements................................................................93
6.4
SidebySideMigration(UsingaGateway)....................................................95
6.5
FullMigration..............................................................................................100
6.6
Conclusion..................................................................................................112
6.7
References..................................................................................................114
LiteratureReviewConclusion..........................................................................116
7.1
Conclusion..................................................................................................116
7.2
References..................................................................................................119
SectionIIIFrameworkDevelopment.....................................................................120
8
MigrationFrameworkRequirements:.............................................................121
8.1
Introduction................................................................................................121
8.2
MigrationRequirements.............................................................................121
vi
TableofContents
8.3
ApplicationDefinition.................................................................................122
8.4
CANParameterAbstraction........................................................................123
8.5
Migration....................................................................................................124
8.6
FlexRayFrameImplementation..................................................................124
8.7
FlexRayApplicationConfiguration..............................................................125
8.8
Conclusion..................................................................................................126
CANtoFlexRayMigrationMethodology:........................................................127
9.1
Introduction................................................................................................127
9.2
FrameworkDevelopment...........................................................................127
9.3
SystemImplementation..............................................................................129
9.4
Verification.................................................................................................130
9.5
ImplementationofAnalysisFindings..........................................................130
9.6
ApplyingFrameworktoaRealWorldApplication......................................131
9.7
GenericCANtoFlexRayDevelopment........................................................131
9.8
StaticSegmentDevelopment.....................................................................132
9.9
DynamicSegmentDevelopment.................................................................140
9.10
Conclusion..................................................................................................143
9.11
References..................................................................................................147
10 DevelopmentToolsandApplications:.............................................................148
10.1
Introduction................................................................................................148
10.2
Hardware....................................................................................................148
10.3
Software.....................................................................................................154
10.4
Conclusion..................................................................................................169
10.5
References..................................................................................................170
SectionIVTesting&Results.................................................................................171
11 SystemModel.................................................................................................172
vii
TableofContents
11.1
Introduction................................................................................................172
11.2
TractionControl&AdaptiveCruiseControlSummary................................172
11.3
ApplicationModels.....................................................................................173
11.4
Hardware....................................................................................................178
11.5
Software.....................................................................................................181
11.6
ExtractionMethod......................................................................................182
11.7
VerificationofParameterConsistency........................................................182
11.8
ValidationCheck.........................................................................................183
11.9
Conclusion..................................................................................................183
11.10
References................................................................................................184
12 FrameworkImplementationProcedure:.........................................................185
12.1
Introduction................................................................................................185
12.2
Abstract(TC)Implementation(TestCase1)...............................................185
12.3
DynamicSegmentVerification....................................................................197
12.4
FinalAbstractCaseParameters..................................................................201
12.5
ExperimentalImplementation(ACC)(TestCase2).....................................202
12.6
DynamicSegmentAnalysis.........................................................................209
12.7
FinalExperimentalCaseParameters...........................................................211
12.8
VerificationofTimeTriggeredProperties(TestCase3).............................213
12.9
FinalPracticalCaseParameters..................................................................219
12.10
Conclusion................................................................................................220
12.11
References................................................................................................222
13 TestResults&Verification:.............................................................................223
13.1
Introduction................................................................................................223
13.2
TestCase2:ACCConfiguration...................................................................224
13.3
CANResults.................................................................................................225
viii
TableofContents
13.4
FlexRayResults...........................................................................................245
13.5
DiscussionofResults...................................................................................272
13.6
TestCase3:VerificationofTimeTriggeredProperties...............................277
13.7
Conclusion..................................................................................................282
SectionVConclusion............................................................................................283
14 Conclusion:.....................................................................................................284
14.1
ResearchSummary.....................................................................................284
14.2
SummaryofTestingandResults.................................................................285
14.3
ResearchQuestions....................................................................................287
14.4
AreasforFutureResearch..........................................................................288
SectionVIAppendices...........................................................................................290
AppendixA..................................................................................................................I
14.5
PublishedMaterial...........................................................................................I
AppendixB.................................................................................................................II
14.6
Bibliography....................................................................................................II
AppendixC................................................................................................................V
14.7
Calculations.....................................................................................................V
ix
TableofFigures
Table of Figures
FIGURE21:ASIMPLENETWORKEXAMPLE................................................................................................9
FIGURE22:BUSTOPOLOGY......................................................................................................................10
FIGURE23:STARTOPOLOGY....................................................................................................................11
FIGURE24:RINGTOPOLOGY....................................................................................................................12
FIGURE25:MESHTOPOLOGY...................................................................................................................12
FIGURE26:TCP/IPMODEL........................................................................................................................14
FIGURE28:COSTVSDATARATEOFDIFFERENTAUTOMOTIVEPROTOCOLS..........................................17
FIGURE29:BASICNETWORKCONFIGURATION........................................................................................18
FIGURE210:POINTTOPOINTNETWORK................................................................................................19
FIGURE211:ABASICNODECOMPRISINGOFASENSORANDECU..........................................................20
FIGURE212:MICROPROCESSORBLOCKDIAGRAM..................................................................................21
FIGURE213:TIMETRIGGEREDSLOTSONANETWORK............................................................................24
FIGURE31:CANSRELATIONTOTHEOSIMODEL.....................................................................................29
FIGURE32:TERMINATINGRESISTORS(TOSTOPREFLECTION)................................................................30
FIGURE33:CANSTANDARDFRAMEFORMAT..........................................................................................31
FIGURE34:CANEXTENDEDFORMAT.......................................................................................................31
FIGURE35:REMOTEFRAME.....................................................................................................................32
FIGURE36:ERRORFRAMEFORMAT.........................................................................................................33
FIGURE37:OVERLOADFRAMEFORMAT..................................................................................................33
FIGURE38:ARBITRATIONPROCESS..........................................................................................................35
FIGURE39:TTCANMATRIXCYCLE............................................................................................................41
FIGURE310:TTCANSAMPLEWINDOWTIME...........................................................................................42
FIGURE41:POSSIBLEFLEXRAYIMPLEMENTATION..................................................................................46
FIGURE42:STARANDBUSTOPOLOGYCOMBINATION............................................................................48
FIGURE:43:FLEXRAYCYCLESTRUCTURE..................................................................................................49
FIGURE44:NODEARCHITECTURE(CONSORTIUM,2005)........................................................................50
FIGURE45:NODECOMPONENTS.............................................................................................................51
FIGURE46:ROLETHECHIHASINTHEPEINTERACTINGWITHTHEHOSTPROCESSOR(CONSORTIUM,
2005).................................................................................................................................................52
FIGURE47:FRAMEFORMAT(CONSORTIUM,2005).................................................................................53
FIGURE48:PAYLOADSEGMENTCONTAININGTHENETWORKMANAGEMENT(NM)VECTOR&MESSAGE
ID.......................................................................................................................................................54
FIGURE49:FLEXRAYTIMINGHIERARCHY(CONSORTIUM,2005).............................................................57
TableofFigures
FIGURE410:POSSIBLEFLEXRAYFRAMECYCLECONFIGURATION............................................................58
FIGURE51:BASICDISTRIBUTEDARCHITECTURE......................................................................................65
FIGURE52:GENERALNODEPROPERTIES.................................................................................................65
FIGURE53:OSEKMODELVSOSI7LAYERMODEL...................................................................................69
FIGURE54:BASICTASKGRAPH.................................................................................................................70
FIGURE55:SIMPLEACTIVITYCONFIGURATION........................................................................................75
FIGURE56:SAMPLEPROCESSMODEL......................................................................................................76
FIGURE:57:ALTERNATIVEACTIVITYTASKCONFIGURATIONS..................................................................76
FIGURE:58:SAMPLECOMPLEXCPAMODEL............................................................................................77
FIGURE:59:TASKCONTENTS....................................................................................................................77
FIGURE:510:TWOTASKS,T1&T2,CONNECTEDBYAMESSAGEM1......................................................78
FIGURE511:TASKT1SRELEASEANDDEADLINEPARAMETERS................................................................78
FIGURE512:TASKGRAPHEXAMPLE(HURLEY,1994)...............................................................................79
FIGURE513:GANTTCHARTFORTASKSINFIGURE512(HURLEY,1994).................................................79
FIGURE514:FOURPHASESOFATASKSEXECUTION................................................................................83
FIGURE61:PROTOCOLCOMMONFUNCTIONALITY.................................................................................94
FIGURE62:CONVERTERBETWEENTWODIFFERENTPROTOCOLS...........................................................94
FIGURE63:EXAMPLEGATEWAYUSAGE...................................................................................................95
FIGURE64:AUTOSARGATEWAYSTRUCTURE..........................................................................................97
FIGURE65:FLOWCHARTCONVERTINGFLEXRAYTOCAN(SUKHYUNSEOL,2006)................................99
FIGURE66:ALGORITHMFORGENERATINGANINDIVIDUAL(SHANDING,2005)..................................103
FIGURE67:NETWORKTOPOLOGYSYNTHESISALGORITHM(ALOUL,2005)...........................................106
FIGURE68:DESIGNHEURISTIC(TRAIANPOP,2002)..............................................................................107
FIGURE69:TTANDDYNSCHEDULABILITYALGORITHMS(TRAIANPOP,2006)......................................107
FIGURE610:OPTIMISEDBUSCONFIGURATIONALGORITHM(TRAIANPOP,2007)...............................108
FIGURE611:GLOBALSCHEDULINGALGORITHM(TRAIANPOP,2006)...................................................110
FIGURE81:FRAMEWORKDEVELOPMENTSTAGES.................................................................................122
FIGURE91:STFRAMEDATAGRAPHPROFILE.........................................................................................137
FIGURE92:ILLUSTRATIONOFPERIODICITYANDDISTANCECONSTRAINT.............................................139
FIGURE93:STSCHEDULINGALGORITHM...............................................................................................145
FIGURE94:DYNSCHEDULINGALGORITHM............................................................................................146
FIGURE95:FLEXRAYEXTRACTIONPARAMETERS...................................................................................146
FIGURE101:FUJITSUSK91F467DFLEXRAYSTARTERKIT......................................................................150
FIGURE102:FLEXRAYPHYSICALLAYERDRIVERMODULE......................................................................151
FIGURE103:VN3600FLEXRAYINTERFACE.............................................................................................152
FIGURE104:CANCARDXL........................................................................................................................153
FIGURE105:FLEXRAYPASSIVESTAR......................................................................................................153
FIGURE106:SOFTUNEWORKBENCHV6.................................................................................................154
xi
TableofFigures
FIGURE107:FMEFRFLASHPROGRAMMER...........................................................................................155
FIGURE108:DECOMSYS::DESIGNERPRO...............................................................................................156
FIGURE109:FLEXRAYNODEANDCLUSTERCONFIGURATION...............................................................157
FIGURE1010:CONSTRAINTVIOLATION..................................................................................................157
FIGURE1011:SAMPLEFRAMESCHEDULE..............................................................................................159
FIGURE1012:ECUCONFIGURATIONSCREEN.........................................................................................160
FIGURE1013:COMMSTACKFLEXRAYCONTROLLERSTATEMACHINE(EGGENBAUER,2006)...............161
FIGURE1014:FLEXRAYSAMPLEFLOWDIAGRAM..................................................................................167
FIGURE1015:FLEXRAYFRAMEPANEL....................................................................................................168
FIGURE1016:CAPLBROWSERPANEL.....................................................................................................168
FIGURE111:ABSTRACTIMPLEMENTATIONSTAGES..............................................................................173
FIGURE112:TRACTIONCONTROLTASKGRAPHMODEL........................................................................174
FIGURE113:ACCTASKGRAPHREPRESENTATION..................................................................................176
FIGURE114:ACCBLOCKDIAGRAMREPRESENTATION...........................................................................177
FIGURE115:TESTCASETHREETASKGRAPHCONFIGURATION............................................................178
FIGURE116:CANPHYSICALTESTCONFIGURATION...............................................................................180
FIGURE117:FLEXRAYPHYSICALTESTCONFIGURATION........................................................................181
FIGURE121:FIRSTFRAMEWORKDEVELOPMENTSTAGE.......................................................................186
FIGURE122:MIGRATIONSTEPTWO.....................................................................................................186
FIGURE123:FRAMEWORKDEVELOPMENTSTAGETHREE.....................................................................187
FIGURE124:PATHP4ONTHETRACTIONCONTROLMODEL.................................................................190
FIGURE125:FLOWCHARTDEVELOPMENTSTAGEFOUR........................................................................192
FIGURE126:STAGEFIVEDEVELOPMENT..............................................................................................193
FIGURE127:PAYLOADGRAPHPROFILE..................................................................................................195
FIGURE128:CONFIGUREDABSTRACTPARAMETERS.............................................................................201
FIGURE129:PAYLOADGRAPHPROFILE..................................................................................................207
FIGURE1210:CONFIGUREDABSTRACTPARAMETERS...........................................................................212
FIGURE1211:FRAMEWORKDEVELOPMENTSTAGESIX.........................................................................212
FIGURE1212:PATHTHROUGHTASKGRAPH..........................................................................................214
FIGURE1213:PAYLOADGRAPHPROFILE................................................................................................217
FIGURE1214:CONFIGUREDABSTRACTPARAMETERS...........................................................................220
FIGURE131:STANDARDTASKNODALASSIGNMENT.............................................................................224
FIGURE132:MINIMALTASKNODALASSIGNMENT................................................................................225
FIGURE133:STAGESEVENOFTHEFRAMEWORKDEVELOPMENT........................................................225
FIGURE134:NORMALBUSLOAD............................................................................................................227
FIGURE135:MESSAGETRANSMISSIONTIMESATNORMALLOAD........................................................228
FIGURE136:APPLICATIONCYCLETIMESATNORMALLOAD..................................................................229
FIGURE137:NUMBEROFFRAMESPERCYCLEATNORMALLOAD.........................................................230
xii
TableofFigures
FIGURE138:60%BUSLOAD....................................................................................................................231
FIGURE139:MESSAGETRANSMISSIONTIMESAT60%LOAD................................................................232
FIGURE1310:APPLICATIONCYCLETIMESAT60%LOAD.......................................................................232
FIGURE1311:NUMBEROFFRAMESPERCYCLEAT60%LOAD...............................................................233
FIGURE1312:MAXIMUMBUSLOAD.......................................................................................................234
FIGURE1313:MESSAGETRANSMISSIONTIMESATMAXIMUMLOAD...................................................235
FIGURE1314:APPLICATIONCYCLETIMESATMAXIMUMLOAD............................................................236
FIGURE1315:NUMBEROFFRAMESPERCYCLEATMAXIMUMLOAD...................................................237
FIGURE1316:MESSAGETRANSMISSIONTIMESATNORMALLOAD......................................................238
FIGURE1317:APPLICATIONCYCLETIMESATNORMALLOAD................................................................239
FIGURE1318:NUMBEROFFRAMESPERCYCLEATNORMALLOAD.......................................................239
FIGURE1319:MESSAGETRANSMISSIONTIMESAT60%LOAD..............................................................240
FIGURE1320:APPLICATIONCYCLETIMESAT60%LOAD.......................................................................241
FIGURE1321:NUMBEROFFRAMESPERCYCLEAT60%LOAD...............................................................242
FIGURE1322:MESSAGETRANSMISSIONTIMESATMAXIMUMLOAD...................................................243
FIGURE1323:APPLICATIONCYCLETIMESATMAXIMUMLOAD............................................................244
FIGURE1324:NUMBEROFFRAMESPERCYCLEATMAXIMUMLOAD...................................................245
FIGURE1325:NOREDUNDANCYNORMALBUSLOADCHA....................................................................247
FIGURE1326:NOREDUNDANCYNORMALBUSLOADCHB....................................................................248
FIGURE1327:MESSAGETRANSMISSIONTIMESNORMALLOAD...........................................................249
FIGURE1328:APPLICATIONCYCLETIMESNORMALLOAD.....................................................................250
FIGURE1329:NUMBEROFSTFRAMESPERCYCLE(NOREDUNDANCY)................................................251
FIGURE1330:NUMBEROFDYNFRAMESPERCYCLENORMALLOAD....................................................251
FIGURE1331:MESSAGETRANSMISSIONTIMESHIGHDATARATE........................................................253
FIGURE1332:APPLICATIONCYCLETIMESHIGHDATARATE..................................................................254
FIGURE1333:NUMBEROFDYNFRAMESPERCYCLEHIGHDATARATE.................................................254
FIGURE1336:NUMBEROFDYNFRAMESPERCYCLEATNORMALLOAD...............................................257
FIGURE1342:NUMBEROFDYNFRAMESPERCYCLEATNORMALLOAD...............................................263
FIGURE1345:NUMBEROFSTFRAMESPERCYCLEHIGHDATARATE....................................................266
xiii
TableofFigures
FIGURE1347:MESSAGETRANSMISSIONTIMESATNORMALLOADS....................................................268
FIGURE1348:APPLICATIONCYCLETIMESATNORMALLOADS..............................................................268
FIGURE1349:NUMBEROFDYNFRAMESPERCYCLEATNORMALLOADS.............................................269
FIGURE1353:MESSAGETRANSMITTIMES(MINIMALCONFIGURATION).............................................275
FIGURE1354:MESSAGETRANSMITTIMES(NORMALCONFIGURATION)..............................................275
FIGURE1355:CANCONFIGURATIONTESTTHREE..................................................................................279
FIGURE1356:GRAPHOFCANAPPLICATIONEXECUTIONTIMES............................................................280
FIGURE1357:FLEXRAYCONFIGURATIONTESTTHREE...........................................................................281
xiv
TableofTables
Table of Tables
TABLE31:CANERRORSTATES..................................................................................................................38
TABLE61:EXAMPLECANNETWORK.......................................................................................................111
TABLE101:OFFSTATE............................................................................................................................162
TABLE102:STARTUPSTATE...................................................................................................................163
TABLE103:ONSTATE.............................................................................................................................164
TABLE104:ONLINESTATE......................................................................................................................164
TABLE105:CONFIGURATIONSTATE.......................................................................................................165
TABLE106:RESETSTATE.........................................................................................................................165
TABLE107:WAKEUPSTATE....................................................................................................................165
TABLE108:ANALYSISFUNCTIONBLOCKOVERVIEW..............................................................................166
TABLE111:TRACTIONCONTROLTASKFUNCTIONS...............................................................................174
TABLE112:ADAPTIVECRUISECONTROLTASKFUNCTIONS...................................................................175
TABLE121:PARAMETERCM&JMIDENTIFICATION.................................................................................188
TABLE122:WMFIVEITERATIONSOFTHEQUEUINGDELAY...................................................................189
TABLE123:WORSTCASERESPONSETIME.............................................................................................189
TABLE124:OBTAININGSLACK................................................................................................................190
TABLE125:TASKGRAPHPARAMETERS..................................................................................................191
TABLE126:FINALTASKGRAPHPARAMETERS........................................................................................191
TABLE127:MESSAGEDEADLINES...........................................................................................................192
TABLE128:PAYLOADCALCULATIONS.....................................................................................................194
TABLE129:INITIALDYNAMICDATA.......................................................................................................197
TABLE1210:DYNAMICCOMMUNICATIONTIME...................................................................................198
TABLE1211:MPARAMETERS................................................................................................................199
TABLE1212:WM(T)PARAMETER............................................................................................................200
TABLE1213:DYNAMICRESPONSETIMES...............................................................................................200
TABLE1214:CANINITIALPARAMETERS.................................................................................................203
TABLE1215:OBTAININGSLACKPARAMETER.........................................................................................203
TABLE1216:TASKGRAPHPARAMETERS................................................................................................204
TABLE1217:FINALTASKGRAPHPARAMETERS......................................................................................204
TABLE1218:MESSAGEDEADLINES.........................................................................................................205
TABLE1219:PAYLOADCALCULATIONS...................................................................................................206
TABLE1220:APERIODICCANDATA........................................................................................................210
TABLE1221:MPARAMETERS................................................................................................................210
TABLE1222:WM(T)PARAMETER............................................................................................................211
xv
TableofTables
TABLE1223:DYNAMICRESPONSETIMES...............................................................................................211
TABLE1224:CANINITIALPARAMETERSTESTCASETHREE....................................................................213
TABLE1225:OBTAININGSLACKPARAMETER.........................................................................................214
TABLE1226:TASKGRAPHPARAMETERS................................................................................................215
TABLE1227:FINALTASKGRAPHPARAMETERS......................................................................................215
TABLE1228:MESSAGEDEADLINES.........................................................................................................216
TABLE1229:PAYLOADCALCULATIONS...................................................................................................216
TABLE131:NORMALBUSLOAD..............................................................................................................227
TABLE132:MESSAGEDEADLINES...........................................................................................................228
TABLE133:60%BUSLOAD......................................................................................................................230
TABLE134:MAXIMUMBUSLOAD...........................................................................................................234
TABLE135:MESSAGEDELAYS.................................................................................................................235
TABLE136:NORMALBUSLOAD..............................................................................................................237
TABLE137:60%BUSLOAD......................................................................................................................240
TABLE138:MAXIMUMBUSLOAD...........................................................................................................242
TABLE139:MESSAGEDELAYS.................................................................................................................244
TABLE1310:STANDARDBUSLOAD.........................................................................................................247
TABLE1311:REVISEDFLEXRAYMESSAGEDEADLINES...........................................................................248
TABLE1312:HIGHDATARATEBUSLOAD...............................................................................................252
TABLE1313:NORMALBUSLOAD............................................................................................................255
TABLE1319:NUMBEROFCANFRAMESPERSECOND............................................................................273
TABLE1320:NUMBEROFFLEXRAYFRAMESPERSECOND.....................................................................273
TABLE1321:ACCCANAPPLICATIONCYCLESTANDARDDEVIATION......................................................276
TABLE1322:ACCFLEXRAYAPPLICATIONCYCLESTANDARDDEVIATION...............................................277
TABLE1323:APPLICATIONIDS................................................................................................................278
TABLE1324:APPLICATIONEXECUTIONTIMES.......................................................................................279
xvi
TableofEquations
Table of Equations
EQUATION51:UTILISATIONBOUND........................................................................................................72
EQUATION52:WCET................................................................................................................................80
EQUATION53:MESSAGEDELAY...............................................................................................................80
EQUATION54:RECURRENCERESPONSETIME.........................................................................................81
EQUATION55:RESPONSETIME................................................................................................................83
EQUATION56:RESPONSETIME(INCLUDINGJITTER)...............................................................................83
EQUATION57:COMMUNICATIONTIME...................................................................................................83
EQUATION58:BLOCKINGDELAY..............................................................................................................84
EQUATION59:QUEUINGDELAY...............................................................................................................84
EQUATION510:REOCCURRENCEQUEUINGDELAY..................................................................................84
EQUATION511:CONVERGENCE...............................................................................................................84
EQUATION512:RESPONSETIME..............................................................................................................84
EQUATION513:RECURRENCERESPONSE................................................................................................85
EQUATION514:UPDATEDRESPONSETIME.............................................................................................85
EQUATION515:WORSECASEDELAY........................................................................................................85
EQUATION516:UPDATEDWCRT..............................................................................................................85
EQUATION517:UPDATEDDELAY.............................................................................................................86
EQUATION518:TRANSMISSIONTIME......................................................................................................86
EQUATION519:SIMPLIFIEDTRANSMISSIONTIME...................................................................................86
EQUATION61:USEDMESSAGESIZEOFNODEI.....................................................................................103
EQUATION62:MAXIMUMMESSAGESIZEOFNODEI............................................................................103
EQUATION63:DATAELEMENTOPTIMUMPERIOD................................................................................104
EQUATION64:OVERALLFITNESS...........................................................................................................104
EQUATION65:SLOTDURATION.............................................................................................................105
EQUATION66:SLOTREUSE....................................................................................................................106
EQUATION67:MNEWTRANSMISSIONSLOTPORTIONWITHINPERIOD(MNEW).......................................106
EQUATION68:DYNWORSECASERESPONSETIME................................................................................109
EQUATION69:WORSECASEDELAYM..................................................................................................110
EQUATION610:COMMUNICATIONTIME...............................................................................................110
EQUATION91:CANMESSAGESET..........................................................................................................132
EQUATION92:MESSAGECOMPONENTS................................................................................................132
EQUATION93:TASKGRAPHEXECUTIONTIME.......................................................................................132
EQUATION94:INTERMEDIATETASKSCHEDULING................................................................................133
EQUATION95:TOTALAVAILABLESLACK................................................................................................133
xvii
TableofEquations
EQUATION96:SLACKPERTASK..............................................................................................................133
EQUATION97:PARAMETERVALIDATIONCHECK...................................................................................134
EQUATION98:TRANSMISSIONDEADLINE..............................................................................................134
EQUATION99:TRANSMISSIONDELAY....................................................................................................134
EQUATION910:FLEXRAYFRAMESIZE....................................................................................................135
EQUATION911:FRAMESPERAPPLICATIONCYCLE(STDATA)...............................................................135
EQUATION912:TOTALREQUIREDBYTES...............................................................................................136
EQUATION913:SLOTDURATION...........................................................................................................138
EQUATION914:DISCRETISEDSLOTDELAY.............................................................................................138
EQUATION915:PERIODICITYANDDISTANCECONSTRAINTVALIDATION..............................................140
EQUATION916:TOTALDYNCOMMUNICATIONTIME...........................................................................141
EQUATION917:MINIMUMNUMBEROFREQUIREDDYNSLOTS...........................................................141
EQUATION918:SLOTQUANTITYVERIFICATION....................................................................................141
EQUATION919:DYNAMICWORSTCASERESPONSETIME.....................................................................142
EQUATION920:COMMUNICATIONTIME...............................................................................................142
EQUATION921:MDELAY......................................................................................................................142
EQUATION922:NUMBEROFUNUSEDMINISLOTS................................................................................143
EQUATION923:WM(T)DELAY.................................................................................................................143
EQUATION121:TASKRESPONSETIME...................................................................................................187
EQUATION122:MESSAGETRANSMISSION/COMMUNICATIONTIME...................................................187
EQUATION123:REVISEDTOTALFLEXRAYDATA....................................................................................194
EQUATION124:RESPONSETIMEANALYSISEQUATION.........................................................................198
EQUATION125:TOTALDYNCOMMUNICATIONTIME...........................................................................198
EQUATION126:MDELAY......................................................................................................................199
EQUATION127:WMDELAY.....................................................................................................................199
EQUATION128:RESPONSETIMEANALYSISEQUATION.........................................................................209
EQUATION129:MDELAY......................................................................................................................210
EQUATION1210:WMDELAY...................................................................................................................210
xviii
SectionIThesis
Overview
ThesisOverview
1 Thesis Overview:
1.1 ProblemSpecification
The aim of this research is to develop a framework to migrate an application from

CAN,aneventdrivennetworkprotocol,usedprincipallyinautomotiveapplicationsto
FlexRay, a timetriggered protocol. Within the automotive industry the predominant
networkhasbeenCAN(ControllerAreaNetwork)andthisisdiscussedingreaterdetail
in Chapter 3. In the past eight to ten years it has been realised by automobile
manufacturers that the CAN protocol will not be sufficient for future application
requirements (Thomas Noltey, 2005). This is the main reason behind FlexRays
development. The FlexRay protocol is not intended necessarily to replace CAN.
Throughbeingabletooperateasingleprotocolforanapplicationthiscanreducethe
complexityassociatedwithoperatingmultipleprotocolsviagateway/s.Consideration
ofvariousaspectsofeachprotocolaretobetakeintoaccountsuchascost,knowledge
of all protocols and the time required to implement these protocols are some
examplesofsomeofthepossibleissuesencountered.
As consumers expect higher luxury levels in automobiles, this increases the loads on
thecurrentnetworkprotocols(Schedl,2007).This,combinedwiththeeverincreasing
amountofsafetyapplicationsbeingdeveloped,hasresultedinpredictionsbyDrAnton
Schedl atthe Vector FlexRay Symposium 2007amongst others, that current network
protocolswillnotbeabletocopewiththisdemandinthenearfuture(Schedl,2007).
In 2000 the FlexRay consortium was founded by automobile manufacturers BMW,
Daimler Chrysler and semiconductor manufacturers Motorola semiconductors
products sector (now Freescale semiconductors) and Philips semiconductors. Other
leading companies in the automotive industry soon joined. It is anticipated that
2
ThesisOverview
FlexRay will replace CAN (as the defacto automobile network) for critical and safety
applications.
WhileFlexRayisanticipatedasthesolutiontosafetycriticalhighspeedapplications,it
is also anticipated that CAN technology will continue to be used in less critical
applications. A migration from the CAN network to the FlexRay network would be
requiredwhereCANhasreachedmaximumcapacityornewfeaturesareaddedtoan
application that requires some of the features provided for on the FlexRay network.
This research aims to provide a framework that will allow applications that have
previously operated on the CAN network, to successfully operate on the FlexRay
network.
1.2 SpecifiedSolution
One solution is to develop a framework to migrate from the CAN network to the
FlexRaynetwork.Toachieveasuccessfulmigrationaminimumrequirementisthatthe
minimumtimingparametersintheCANnetworkareatleastachievedorexceededin
the FlexRay network. This requires a detailed understanding of both network
technologies,butspecificallytheFlexRaynetworkasitismorecomplex.
ThesisOverview
1.3 ResearchQuestions
Question1:
Whatarethebenefitsofusingthemigrationframeworkversustheuseofagateway?
Question2:
What migration techniques used in other or similar protocols are applicable in this
research?
Question3:
Whatparametersarerequiredinrelationtotheapplicationandnetworkprotocol,for
migrationtobeundertaken?
ThesisOverview
1.4 DocumentLayout
Thethesisisarrangedasfollows;
SectionI:ThesisOverview
This section, Thesis Overview presents the problem specification and the
researchquestions.
SectionII:LiteratureReview
The Literature Review section discusses the background of automotive
networks before presenting the CAN and FlexRay protocols in depth. An
embedded system overview is discussed before the section concludes with a
reviewofmigrationprocedurescarriedoutbyotherauthors.
SectionIII:FrameworkDevelopment
This section, Framework Development, presents the requirements and
methodologyforundertakingthismigrationprocedure.
SectionIV:Testing&Results
Section IV, Testing & Results, presents the system model and the actual
migrationframework.Thesectionproceedswiththeabstractandexperimental
implementations of the generic model and the ACC (Adaptive Cruise Control)
referencemodelandtheVerificationofTimeTriggeredproperties.Thesection
concludeswithapresentationoffindingsandadiscussionofresults.
SectionV:Conclusion
Section V contains the conclusion, and any potential future work that would
improvethisresearch.
SectionVI:Appendices
SectionVIconcludesthethesiswiththeappendices.
5
ThesisOverview
1.4.1 References
THOMASNOLTEY,H.H.,LUCIALOBELLO(2005)AutomotiveCommunicationsPast,
CurrentandFuture
SchedlDA,2007,GoalsandArchitectureforFlexRayatBMW,1stVectorFlexRay
Symposium,Stuttgart,Germany.
SectionIILiterature
Review
AutomotiveNetworksReview
2 Automotive Networks Review:
2.1 Introduction
This chapter contains a general assessment of what a computer network is, and
reviewscommonnetworktopologies.TheTCP/IPandOSIreferencemodellayersare
presented due to their use in the transportation of data packets. This leads onto a
historyofautomotivenetworksdiscussingvariousclassesofautomotiveprotocols.The
ElectronicControlUnit(ECU)ispresentedduetoitscoreuseinthedevelopmentand
implementationofnetworksintheautomotiveindustry.Finallyautomotiveprotocols
are discussed at eventtriggered and timetriggered level and a direct comparison is
madebetweenthenaturesofbothprotocols.
2.2 ComputerNetworks
A network is a series of points or nodes interconnected by communication paths

(Harbeck,2006)
TheInternetisthemostcommondatanetworkthatpeoplecomeintocontactwithon
adailybasis.TheInternetevolvedfromasmallacademicresearchprojectinvolvinga
few dozen sites to become a vast worldwide system of interconnected networks
providing various functions and services. The first computer networks were
timesharing networks that used mainframes and attached terminals (Teare, 1999).
Timesharingistheconceptofmultipleusersgettingaccesstotheprocessorduringthe
processorsidletime.
By networking remote locations to these powerful computers (timesharing) the
required tasks could be completed more economically. Currently an entire industry
providesnetworkingtechnologiesandservices.
2.3 NetworkFunction
AnetworkconsistsoftwoormoredevicesinterconnectedasillustratedinFigure21.
One of the earliest network types was built to allow several computers to share a
singleprinter.
Figure 2-1: A Simple Network Example
A networks function is the transportation of data (e.g. data from a computer to a

printer).Networkingcanbecomplexbecausetherearesomanydifferenttechnologies
availablethatcanbeusedtoconnecttwoormorenetworkstogether(Comer,2001).
As data networks were developing during the 1970s and the 1980s the automotive
industry was also starting to realise the advantages of implementing networks in
automobiles. Originally, automobiles had relatively small quantities of electric and
electroniccomponents,usuallyintheformofclosedloopcircuits.Forexample,oneof
the earliest applications was the control and operation of lights. Additional features
suchaswindscreenwipersandenginemanagementsystemsincreasedthecomplexity
and volume of wiring in the wiring harness. This led to the development of the bus
structureinthe1980s.Thedefactobusstructureintheautomotiveindustrybecame
theControllerAreaNetwork(CAN).Thestructuresofconventionaldatanetworksand
automotive networks have some similarities. In the following section the features of
both network types are discussed at network level in relation to the following;
topology,architectureandprotocols.
2.4 NetworkTopologies
ThetermTopologyreferstothelayoutoftheinterconnectingdevicesonanetwork.
There are two types of topologies; thephysical topology which describes the cable,
node,andconnectorarrangements,andthereisthelogicaltopologywhichdescribes
the arrangement of devices on a network (Steinke, 2000). The following description
dealswithphysicaltopologies.
ThemainphysicaltopologiesareBus,StarandRing.Thenamesaregiveninrelationto
the general shape of each network. The type of topology used depends on the
configurationrequirementsofthesystem.
2.4.1 BusTopology
TheBusTopology(showninFigure22)canconsistofacommonmedium,suchasco
axial cable (10 base2 (thin net) or 10 base5 (thick net)) or un/shielded twisted pair
(Institute,2002).
Figure 2-2: Bus topology
All the other nodes on the network can be directly connected off this. Because all
nodes share a common bus they can also share communication. The beginning and
endofthebusareterminatedtopreventsignalreflectingbackdownthecable.Ifthe
central bus fails (e.g. the cable is cut) nodes at either sideof the break can cease to
functioncorrectly,iftheyarerequiredtocommunicatewitheachother.UsingtheCAN
protocol information travels along the central bus and whichever node requests the
10
informationmatchesthemessageIDandthenitcanextracttheinformationfromthe
bus.IfthemessageIDdoesnotmatchthenodeIDthenodedoesnotgainaccessto
thatmessage.Ifasinglenodeisremovedfromthenetworkitdoesnotaffecttherest
ofthesystem.
2.4.2 StarTopology
The Star Topology is based on the principle of a centralised host through which all
other nodes communicate (Figure 23). If one node wants to communicate with
another node it is required to send the data through the central processor and then
distribute it to the desired node. If the central processor node fails, subsequently
communicationishalted.
Figure 2-3: Star Topology
2.4.3 RingTopology
The Ring Topology or Ring Network consists of each node being connected totwo
othernodestoformaringasillustratedinFigure24.Ifonenodesendsdatatoanode
that is not directly connected, the data has to go through all the other nodes in its
path.Thedatacantraveltwopaths(leftorright)togettoitsdestinationnode.
11
Figure 2-4: Ring Topology
2.4.4 MeshTopology
InafullyconnectedMeshTopology(asillustratedinFigure25)everynodeisdirectly
connected to all other nodes on the network. This makes it possible for all nodes to
send dataat the same time. This also allows for redundancy to be incorporated into
any system using a mesh topology configuration. A message can take an alternative
routeifonerouteiscorruptedorblocked.Duetotheamountofwiringrequiredthisis
consideredacostlyapproach.
Figure 2-5: Mesh Topology
12
2.4.5 HybridTopology
ThesethreetopologytypescanbecombinedtomakeHybridTopologiessuchasaTree
Topology where there is a central bus and there is a ring and/or star topologies
branchingoff.
2.5 LAN(LocalAreaNetwork)&WAN(WideAreaNetwork)
Networkscangenerallybecategorisedinoneoftwofundamentalgroups;LAN(Local
AreaNetwork)andWAN(WideAreaNetwork).Theseincorporatesomefeaturesfrom
theOSI(OpenSystemsInterconnect)modelwhichisdiscussedindetailinsection2.9.
2.5.1 LAN
LANs connect as few as two devices together or as many as a few thousand. The
interconnectionbetweenthedevicescanbeviacableorwirelessmeans.LANsusually
connectdevicesthatareinrelativecloseproximitytoeachothersuchasaworkstation
andaprinterinthesamebuilding.InaLAN,aservercancontaindataapplicationsand
servicesthatotherdevicesareallowedaccess.Ethernetisatechnologythatiswidely
associated with LANs. Ethernet LAN primarily deals with the physical and datalink
layers (Teare, 1999). The MAC layer on a LAN uses a method called Carrier Senses
Multiple Access/Collision Detection (CSMA/CD) for dealing with contention on the
network. A device using CSMA/CD, listens on the network when it has data to be
transmittedand,ifnootherdeviceisusingthenetworkittransmits.Aftertransmission
itlistenstoseeifacollisionhasoccurred.Ifacollisionhasoccurredeachmessageis
retransmittedafterarandomlengthoftime.Ifanumber ofotherdevicesareusing
the network, performance degrades due to the increased number of collisions.
Introducing switches on a network subdivides the network into smaller collision
domainsresultinginlesscontentionandimprovedperformance.
13
2.5.2 WAN
WANsareusedtoconnectmultipleLANsoveralargerarea.AWANusesdedicatedor
switched connections to link computers in geographically remote locations that are
too widely dispersed to be directly linked to the LAN (Parnell, 1997). They can be
connected via public telecommunications system or private communications. The
Internetisanexampleofapubliccommunicationssystem.
2.6 CommunicationProtocol
Acommunicationprotocolisasetofrulesorstandardsthatenablescommunications
or data transfer between two endpoints (SearchNetworking.com, 2007). A protocol
enables communication between a host and a remote host as long as the
communication takes place on the same level. If the rules are not kept then
communication cannot occur. The TCP/IP reference model is illustrated in figure 26
butisnotpresentedindetailasitisnotcoveredinthescopeofthisresearch.
Figure 2-6: TCP/IP Model
14
2.7 AutomotiveNetworksHistory
Asdatanetworksbeganevolving,theautomotiveindustrywasbeginningtoaddmore
electronic components and features to automobiles, such as air conditioning and
electricwindows.Whiledatanetworks were developedtoimprovequality ofservice
and increase data transfer rates, the automotive industries initial motivation would
havebeenfundamentallyfinancial.Thishaschangedinrecentyearsasthenumberof
safety critical applications increases and consumers demand more comfort
applicationssuchasclimatecontrol.Theintroductionofanetworkedbusstructurein
automobileshasleadtoareductioninthesizeofwiringharnesses.Reducingthesize
ofawiringharnessalsoyieldedareductionintheweightoftheautomobileandinturn
thiswouldimprovefuelefficiency.
While initially introducing networks in cars reduced weight, this also lead to other
safety/nonsafety applications being developed, this increased weight and power
consumption.Theavailabilityofintegratedcircuitsinthe1960sandthe1970sallowed
furtherdevelopmentofautomotiveelectronicsandthedevelopmentoftheelectronic
controlunit(ECU).TheuseoftheECUallowedenginemanagementparameterstobe
varieddependingonexternalconditionslikeengineloadandairtemperature.Atthe
time, the main factor pushing automotive electronics development was exhaust
emissions regulations. Mechanical methods alone could not provide the means to
meet these new requirements while maintaining performance and efficiency
(Fischerkeller, 2007). It was then realised that the microcomputer adapted for
automotive use could address the requirements for emission controls while
maintainingperformanceforthedrivingenthusiast.Themicrocomputercouldhandle
data from the spark timing with variations in the load speed, inputs from sensors
providing data on crankshaft position, coolant temperature etc (Jurgen, 1999).
Increased development of integrated circuits allowed car manufacturers to eliminate
passivecomponents.Thenwiththedevelopmentofmicroprocessor,electronicengine
15
controls, antilock braking systems and trip computer revolutionised automobile

electronics(Buchholz,2006).
Originally, as automobile manufactures started to develop more electronic based

applications for cars, there was no link between the electronics industry and the
automotive industry. The automotive industry wanted the technology to be as
economical as possible, but within the electronics industry all new technologies are
initially expensive (due to research and development costs) and then become more
cost effective due to improvements in production methods, product life cycles and
widespreadadaption.
It is no coincidence that during the 1980s the seminal breakthrough in automotive

network development was facilitated by the production of more powerful ICs
(IntegratedCircuits).TheCANprotocolwasalsodevelopedduringthisperiodandby
theearly1990shadbecomethedefactostandardintheautomotiveindustry.There
have been other variants of this protocol such as TTCAN, CANOpen, DeviceNet, CAN
Kingdom and J1939. Proprietary variants such as J1850 PWM, J1850 VPM and ISO
91412weredevelopedindividuallybymanufacturersbutthesearenotincludedinthe
scopeofthisresearch.Therearealsothreeotherprimaryautomotiveprotocols.Local
Interconnect Network (LIN) was developed as a low cost, lower speed alternative to
CAN for use primarily in noncritical body control unit (BCU) functions. The Media
Oriented System Transport (MOST) protocol was developed with high bandwidth
infotainmentsystemsspecificallyinmind.TheFlexRayprotocolwasdevelopedforuse
insafetycriticalapplications.
2.8 AutomotiveNetworksDescription
Automotive networks can be classified by their protocols. There are four main
protocolsCAN,LIN,FlexRayandMOST.Eachprotocolisselectedforitsabilitytomeet
thesystemrequirementswhilekeepingtheimplementationandbuildcostsaslowas
possible.TherelativecostperdatarateisillustratedinFigure28.
16
Figure 2-7: Cost Vs Data Rate of Different Automotive Protocols
Ageneralruleofthumbisthatthefastestnetworkstendtobethemostexpensiveas
is illustrated by Figure 28. LIN operates at speeds with a maximum data rate of 20
Kbit/sandistypicallyusedinapplicationsthatrequirethedrivertoinitiateoperation.
In critical applications that occur rapidly or do not require the driver to initiate
operationthefasternetworkssuchasCANandFlexRaywithspeedsofupto10Mbit/s
(1Mbit/sforCAN)areusedeventhoughtheyaremoreexpensivetoimplementthan
LIN. In 1994 the Society of Automotive Engineers (SAE) defined the classification of
fourclassesofnetworks;ClassA,ClassB,ClassCandD.
ClassA:Datarates10kbits/orlower
ClassB:Dataratesfrom10to125kbits/s
ClassC:Dataratesfrom125kbits/sto1Mbit/s
ClassD:Dataratesover1Mbit/s
ClassAisusedinthebodyelectronicsofthecarandanexampleisLINasmentioned
above. Class B is used to share information between ECUs to reduce the number of
sensors required. A low speed CAN network would fall into this category. A class C
network would be utilised by a realtime highspeed communications system i.e.
17
powertrain or chassis applications using high speed CAN. And finally the class D
network is used by MOST and FlexRay in applications that require predictability and
faulttolerance(NICOLASNAVET,2005).
While the protocol parameters change from protocol to protocol a basic network
structurecan be summarised inFigure 29.CAN (Controller Area Network) is the de
facto network standard in the automotive industry. CAN operates on a peertopeer
basisi.e.nomasterorslave,amessageistransmittedandthenodethatrequiresthe
datagainsaccesstothedataandprocessesit.
Figure 2-8: Basic Network Configuration
In Figure 210 we see an illustration of a network configuration where each node is

directly connected to every other node on the network (pointtopoint). Figure 25
(meshtopology)isalsoanexampleofthisasispreviouslyexplained.Forasimplefour
node system there is not much system complexity, but modern high to medium end
automobiles have over 70 interconnected ECUs therefore dramatically increasing
system complexity (A. Albert1, 2005). Networking eliminates redundant wiring
becauseasensoronlyhastobewiredtothenearestcontrollerandthecontrollerwill
transmittheinformationoverthenetwork(JaredBusen,2006).
18
Figure 2-9: Point-to-Point Network
Networking improves many aspects within the automotive industry such as design
flexibility, diagnostics and reduced wiring/weigh/cost (Philip Koopman, 1998). Design
flexibilityisimprovedbecausedesignersjusthavetodesignasfarasthecontrollerand
thenetworktakestheinformationtotherequiredcontrollerinadifferentpartofthe
automobile.Havingonecentralaccesspointonthenetworkandconnectingthisinto
thediagnosticstoolenableserrormessagesonthebustobereadandanalysed.This
enables problems to be located quicker than having to test each functional area
individually.
Networkingallowstheprovisionforscalabilitywithinasystem.Thisallowsasystemto
grow as more applications are added. A system can only grow if in the initial design
stageprovisionismadeforpossibleexpansionorincreaseddatathroughputatalater
stage.
2.8.1 GenericNodeComposition
Examining the components of a typical automotive network node reveals a general

outlinesimilartothatinFigure211.HereasensorprovidesinputdatatoanElectronic
Control Unit (ECU). The sensors data is processed in the ECU and transmitted across
19
thenetworksothatanyrequiredactionswillbetakenifnecessary.Foroutputdatawe
couldhaveanactuatorinplaceofthesensor.
Figure 2-10: A Basic Node Comprising of a Sensor and ECU
BeforetheintroductionofECUsintoenginemanagementsystemstheamountoffuel
inacylinder,quantityofairmixedinandtheignitiontimeofthesparkplugswereall
parameterssetbythedesigneratdesigntime.ByintroducingECUsthisenabledthese
parameters to be mapped depending on varying engine load values, quality of air
mixture etc. By having optimum operating conditions the car can achieve its best
performance as efficiently as possible. With greater emphasis on reducing carbon
emissions, it is with the aid of an ECU that these regulations can be met. The ECU
receives data from the sensor and uses data tables and calculations to make
adjustmentstotheactuatingdevices(Jurgen,1999).TheECUcanalsohelptoperform
systemdiagnosiswheneveranerroroccurs.
2.9 ECU
Theelectroniccontrolunit(ECU)inanautomobilehasthreemainfunctions;
Performdecisionmakingcapabilities(e.g.adjustintakevalues)
Performarithmeticcalculations
Storedata
Readinputsfromsensors
PerformActuationsbasedondecisions
20
The ECU is based around the microprocessor because it can perform the three basic
requirementsasmentionedabove.Modernautomobilesneedprocessingcapabilities
ofcomputersandcomputersarebasedaroundmicroprocessors.The microprocessor
acts as a CPU (Central Processing Unit) for a computer. Early microprocessors
processeduptoeightbitsatatimebutnowadaysmicroprocessorsareavailablein16
bitand32bitformat,whichenableshigherprocessingspeeds.
TheCPUworksinasequentialmannerandaclock,usuallyacrystalclock,controlsthe
timing.Thisenablesfrequenciesofseveralmegahertzgivinghigherprocessorspeeds
and greater accuracy for clock samples. When an instruction is received and needs
temporarystorageintheCPUitisstoredinthememoryregisters.Withintheregisters
eachwordreceivedisstoredinmemory.
Figure 2-11: Microprocessor Block Diagram
Figure212illustratesamicroprocessorwithassociatedregisters.Italsoillustratesthe
program counter that keeps track of where any instructions are stored and what
instructions the CPU requires running. The ALU (Arithmetic Logic Unit) performs the
arithmeticcalculationsinbinary.AnydatathatisbeingprocessedbytheALUisstored
intheaccumulatoruntilthecalculationisfinished.Thecontrolunitdirectsmovement
of data in the computer. What enables a microprocessor to carry out instructions in
21
thedesiredmanneraretheinstructionsitreceives,theseinstructionswouldusuallybe
conveyedviasoftwarethroughaprogram.
A basic computer can consist of the following elements; a microprocessor, extra

memory,inputsandoutputs.Dataisstoredataspecificaddressismemoryand,when
theprocessorrequiresdata,fetchesitfromthataddress.
When storing data in memory the type of memory used is influenced by the tasks
function.SourcecodedoesnotchangeandthereforewouldbestoredinROM(Read
Only Memory). If the same task was performed repeatedly without change in the
processthenROMtypeofmemorycanbeselected,anexampleofthiswouldbeona
fuel management system that uses fixed data. If the data is only required for a
temporaryperiodthenRAM(RandomAccessMemory)canbeused.Oncethepoweris
disconnectedfromthistypeofmemorythedataislost.Anexampleofthiswouldbea
trip computer in a automobile (also called runtime data) (Hillier, 1996).Nonvolatile
RAM (NVRAM) is also used in instances where stored data is not to be erased. The
primaryareawhereNVRAMisusedisindatarecordingsuchasintheodometer.
Abusinterconnectsthecomponentsofthemicroprocessor;thesebusesarenamedin
relationtothedatatheycarrysuchastheaddressbus,databusandcontrolbus.For
an automotive based computer the inputs and outputs would typically be sensors,
transducersandactuators.
Current practice in the automotive industry is that the physical network bus
interconnecting between nodes is a cable. Connectors attach the cable to the
hardware.Theprotocolisacontributingfactorwhencablespecificationsareset.
2.10 AutomotiveNetworkProtocols
Asdiscussedintheprevioussectiononereasonforintroducingnetworksintomodern
automobiles was due to the increased levels of new features and applications in
automobiles. Design engineers decide what protocol is run on the network. Some
22
considerationsthathavetobetakenintoaccountwhendecidingwhatprotocolshall
beusedare;
Istheapplicationcritical?
Whatspeedsarerequiredfortheapplication?
Whatcostsareassociatedwitheachprotocol?
Isthetechnologyreadilyavailabletodeveloptheapplicationwiththechosen
protocol?
Theanswertothesequestionswilloftendecidetheprotocolchosen,whetheritisan
eventtriggered(ET)ortimetriggered(TT)system.
2.10.1 EventTriggeredProtocols
Inaneventtriggered(ET)system,trafficgetsputontothenetworkafteraneventhas
occurredsuchasthedriverpressingthebrakes.Thisisasynchronoustransferbecause
there is no predetermined time at which these events will occur. Because any event
canoccuratanytimeinanyorder,thenetworkhastohaveadevelopedsystemthat
will avoid collisions if two messageson two separatenodes trytogainaccessto the
network at the same time. This is achieved by tagging each message with a priority
level.Themessagewiththehighestprioritywillbegrantedaccesstothebusonceitis
free.Thisisanefficientuseofbandwidthduetothefactthatonlymessagesthatneed
tobetransmittedwillbelookingforaccesstothenetwork(NICOLASNAVET,2005).An
eventtriggeredcommunicationcontrollerdoesnotneedadispatchingtablebecause
thetransmissionofamessageistriggeredbyasendcommandfromthehost(Kopetz,
2000).
23
2.10.2 TimeTriggeredProtocols
Withthetimetriggered(TT)protocol,transmissionoccursatpredefinedpointsintime
(AndreiHagiescu,2007).Activitiescanonlyoccurwiththeprogressionoftimeandthe
activity is predefined. This requires the network to have a predefined schedule that
assignsactivities/tasksasectionofthetime(timeslot)toperformtherequiredaction.
Eachtaskismadeupofmessages.Ifamessageisnottransmittedinitsdefinedtime
slotitwaitsuntilitsnexttimeslot.
InFigure213,amessageisassignedslottwo(S2)inwhichtotransmit.Ifthemessage
doesnotobtainaccesstothebusinslot(S2)itsnextassignedslotwhereitwillgeta
chancetogainaccesstothebusisinslotseven(S7).
Figure 2-12: Time Triggered Slots on a Network
A timetriggered communication controller contains a dispatching table in its local

memory that determines what point in time a particular message is transmitted or
whenthatmessageisexpectedtobereceived(Kopetz,2000).Ifanewnodeisadded
tothenetworkallothernodesneedtobeupdatedduetoachangeintheschedule(if
the new node was an unplanned addition). This can result in inefficient bandwidth
usageassomemessagesmightnotneedtotransmitthewholetime,butwillneedto
beallocatedslotsbythesystemdesigner(AndreiHagiescu,2007).
2.10.3 ComparisonofEventTriggeredandTimeTriggeredNetworks
ET systems have an advantage over TT systems when it comes to adding new nodes
onto the network. With ET systems the new node can be added on where as in TT
systems the new node has to be scheduled into the system at design time. This
24
involvesthesystemdesignerreorganisingthesystemscheduletoaccommodatethe
newIDsonthenewnode.AsstatedpreviouslybandwidthefficiencyisgreateronET
systemsbecauseamessagecanbetransmittedifbandwidthisavailablewhereasona
TT system a messagecan only transmitwhenit hasbeen scheduledtodo soeven if
therearenomessagesscheduledintheslotsbeforeit.TTsystemscanbefaulttested
to a higher degree because the designer has the schedule prior to execution. In ET
systems run time testing is critical for catching potential faults due to the aperiodic
natureoftheprotocol.AlsoinTTnetworks,sincetheapplicationdoesnotcontrolthe
timings there is a common time base for all nodes which allows the communication
controllertosynchronisetothemessageschedule(Hartwich,2007).
After considering these features the properties of each protocol can be examined.
Only CAN and FlexRay are discussed as LIN and MOST were not encountered during
thisresearch.
2.11 Conclusion
In this chapter the concept of computer networks was introduced starting with the
general principle and moving onto automotive systems. Differing network topologies
andarchitectureswerediscussedbeforeanexampleoftheTCP/IPreferencemodelis
presented,whoseprotocolisusedextensivelyintheInternet.Thesevenlayersofthe
OSIreferencemodelareexplainedasthisreferencemodelisusedtocomparelayers
ofotherprotocols.Abriefhistoryaboutthereasonsforusingofnetworkswithinthe
automotive industry is presented along with an overview of a nodes hardware
composition. Finally the chapter concludes with a discussion on TT and ET protocols
andacomparisonofstrengthsandweaknessofthetwo.
This chapter presents the necessary background to understanding the purposes and
requirementsofnetworkswithintheautomotiveindustry.Bypresentingdatanetwork
models such as the OSI model this allows comparisons to be made when discussing
automotive protocols in later chapters such as the comparison made in Chapter 3
between CAN and the OSI model. By presenting an overview of the various network
25
types (TT and ET) the limitations and advantages of each architecture type are
revealed.
26
2.12 References
A.Albert1BP,F.Voetz1,2005,SimulationEnvironmentforInvestigatingtheImpactsof
TimeTriggeredCommunicationonaDistributedVehicleDynamicsControl
System,1stInternationalECRTSWorkshoponRealTimeandControl,
AndreiHagiescuUDB,SamarjitChakraborty,PrahladavaradanSampath,P.Vignesh,V.
Ganesan,S.Ramesh,2007PerformanceAnalysisofFlexRaybasedECU
Networks
BuchholzK,2006,Electronicshistorylesson.
http://www.sae.org/automag/electronics/092002/
CasadJ2001TeachYourselfTCP/IPin24Hours:Sams)
ComerDE2001ComputerNetworksandInternets:PrenticeHall)
FischerkellerSRaR,2007,LatestTrendsInAutomotiveElectronicSystemsHighway
MeetsOffHighway?
HarbeckR,2006,Network,
http://searchnetworking.techtarget.com/sDefinition/0,sid7_gci212644,00.html
[15/03/2008]
HartwichF,2007,ImplementationConceptforBoschFlexRayCommunication
controller,1stVectorFlexRaysymposium,Stuttgart.
HillierVAW1996HilliersFundamentalsofAutomotiveElectronics:StanleyThornes
Ltd)
InstituteNBR,2002,INFORMATIONCOMMUNICATIONTECHNOLOGY(ICT)
DEVELOPMENTSESTABLISHMENTOFTHEFIRSTSWITCHBASEDLOCALAREA
NETWORKATNBRI(NBRILAN),[26/02/2008]
JaredBusenLEJaBK,2006,HowAutomotiveNetworksareConfigured,
http://www.asashop.org/autoinc/jan2006/mech2.htm[10Feburary2008]
JurgenRK1999AutomotiveElectronicsHandbook:McGrawHill)
KopetzH,2000,AComparisonofCANandTTP,Editor,ConferenceName,Conference
Location.
NICOLASNAVETYS,FRANOISESIMONOTLION,ANDCDRICWILWERT,2005,Trends
inAutomotiveCommunicationSystems,Editor,PROCEEDINGSOFTHEIEEE,
ParnellT1997LANTimesaGuidetoWideAreaNetworks:OsborneMcGrawHill)
PhilipKoopmanET,GeoffHendrey,1998,TowardMiddlewareFaultInjectionfor
AutomotiveNetworks,Editor,ConferenceName,ConferenceLocation.
SearchNetworking.com,2007ProtocolDefinition
http://searchnetworking.techtarget.com/sDefinition/0,sid7_gci212839,00.html
[19thMarch2007],
SteinkeS2000NetworkTutorial:CMPBooks)
StevensWR1994TCP/IPIllustratedvolVolume1:AddisonWesley)
TeareD,1999,InternetworkingHistory.(Internet:Cisco
Press)http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/introint.htm
#wp1020552[12thOctober2006]
27
CAN(ControllerAreaNetwork)
3 CAN (Controller Area Network):
3.1 Introduction
Robert Bosch GmbH originally developed CAN in 1986. It was designed as an

asynchronous serial bus network for connecting devices, sensors and actuators in a
system or subsystem, and was developed to be robust in electromechanically noisy
environments.Itwasinitiallydevelopedforautomotiveapplicationsbutalsohasbeen
usedinIndustrialapplicationsthataresubjecttonoise(Corrigan,2002).
The CAN protocol is an ISO standard (ISO 11519 for applications up to 152Kbps, ISO
11898forapplicationsupto1Mbps)andincludesaphysicallayerandDataLinkLayer,
layers1and2respectively,oftheOSImodelasillustratedinFigure31.Onlylayers1
and2oftheOSImodelhavebeendefinedforCAN;theDataLinkLayeriscomposedof
theLogicalLinkControl(LLC)sublayerandtheMediaAccessControl(MAC)sublayer
((CiA), 2008, cia.org, 20012007). In layer two the data for transfer is encapsulated
within the network level information packets and a unique identifier is assigned to
eachofthese"communicationobjects"(Rufino,1997,(CiA),2008).
28
Figure 3-1: CANs relation to the OSI model
The CAN standard version is a CarrierSense MultipleAccess protocol with Collision

Detection and Arbitration on Message Priority (CSMA/CD+AMP)(Corrigan, 2002).
CSMA requires each node on a bus to wait a prescribed period of inactivity before
attemptingtosendamessage.CarrierSenseentailsthatthedevicesattachedtothe
network listens for other signals on the line before transmitting. If there are other
devicestransmittingonthatlinethelisteningdevicewaitsuntilthelineisclearbefore
transmitting. MultipleAccess allows many devices to connect and share the same
network.
TransmissionoccursiftheCANnoderequeststhetransmissionofamessageandthe
message is the highest priority message that wins arbitration over other messages
trying to gain access to thenetwork. The Arbitration processis explained in detail in
section3.2.2andFigure35.
3.2 CANPhysicalStructure
CANprioritisesmessagesbyconfiguringtheirIDs.Payloadlengthsofeightbytesorless
are sent on a serial bus. A CAN bus is a balanced twowire interface running over a
29
shielded twisted pair, unshielded twisted pair or ribbon cable. In some applications
differentkindsoflinksareusede.g.opticalorradiolinks.Itisnotuncommontouse
differenttransmission mediums forapplicationswithspecificrequirements.Electrical
signals on the bus will be reflected back at the end of the line unless the lines are
correctly terminated as illustrated in Figure 32. The node may receive a reflected
signalinsteadoftheintendedsignalandthiswillcauseinaccuraciesifthesignalsare
different.Placingaresistoratbothterminatingendsofthebuscanfixthisandavoid
unnecessarilylongstubendsofthebus.
Figure 3-2: Terminating Resistors (to stop

reflection)
ThebitencodingusedisNonReturntoZero(NRZ)encodingwithbitstuffingfordata
communicatingonadifferentialtwowirebus.Asequenceofmorethanfiveidentical
bits is a violation of the bitstuffing rule. The CAN bus is a broadcast type bus. This
necessitates that if a message is broadcast all other connecting nodes receive the
message, but only the node requiring the message will react to it and process it
accordingly.
3.3 CANFrameFormat
TherearetwotypesofCANframeformat;
StandardFrame
Formatted: Bullets and Numbering
ExtendedFrame
The standard frame is presented in Figure 33 and the CAN extended frame is
presentedin Figure 34. Standard CAN (2.0A) uses an11bit identifierwhileextended
CAN(2.0B)usesa29bitidentifier(Corrigan,2002).
30
Figure 3-3: CAN Standard Frame Format
The arbitration field in standard CAN comprises of the 11bit identifier and the RTR
(RemoteTransmissionRequest)frame.
Figure 3-4: CAN Extended Format
In extended CAN the arbitration field comprises of a 29bit identifier, RTR frame, IDE
(IDentifierExtension)frameandSRR(SubstituteRemoteRequest)field.StandardCAN
hasonereservebitr0;ExtendedCANhastworeservebitsr0andr1.Thereservedbits
andtheDLC(DataLengthCode)ofbothframetypesarecontainedinthecontrolfield.
CANiscomprisedoffourdifferentframetypesthatcontrolmessagetransferandthey
are;
DataFrame
RTRFrame
ErrorFrame
OverloadFrame
31
Dataframe
The data frame isthe most common message typeandismadeupofthedata field,

arbitration field, the CRC (Cyclic Redundancy Check) field and the acknowledgment
fieldasisillustratedinFigure33.ThisframeinteractswiththeMAClayer(layer2)on
theOSImodel.Thearbitrationfielddeterminesthepriorityofthemessagewhentwo
ormorenodesarecontendingforthebus.Thedatafieldcontainszerotoeightbytes
ofdataandtheCRCfieldcontainsthe16bitchecksumusedforerrordetection.The
acknowledgementfieldisusedwhenamessageisreceivedandtheACKbitoverwrites
the recessive bit at the end of correct message transmission. The transmitter checks
for the presence ofan ACK bitand retransmits the message if no acknowledge bitis
detected.
Remotetransmissionrequestframe(RTR)
The remote frame is intended to solicit thetransmission of data fromanother node.

There are two main differences between this and the data frame; first this type of
messageisexplicitlymarkedasaremoteframeinthearbitrationfieldandsecondlyit
contains no data. The RTR bit is dominant is a data frame and recessive in a remote
frame.TheremoteframeispresentedinFigure35(BOSCH,1991).
Figure 3-5: Remote Frame
32
Errorframe
Theerrorframeistransmittedwhenanodedetectsanerrorinamessageandcauses
all other nodes in the network to send an error frame to confirm they also have
detectedtheerror.Theerrorframecontainstwofields;ErrorFlagandErrorDelimiter.
TheerrorflagisfollowedbythesuperpositionoferrorflagsasillustratedinFigure36.
Toterminateanerrorframecorrectlythebusmayneedtobeidleforthreebittimes
(BOSCH,1991).
Figure 3-6: Error Frame Format
Overloadframe
Theoverloadframeistransmittedwhenanodebecomestoobusyanditgivesanextra
delaybetweenmessages.Itissimilartotheerrorframeinformat.Theoverloadframe
contains two fields; the Overload Flag and the Overload Delimiter. At most two
overload frames can be transmitted to delay the next data or remote frame. The
overloadframeisillustratedinFigure37(BOSCH,1991).
Figure 3-7: Overload Frame Format
33
3.4 BusArbitration
Busarbitrationisthemethodbywhichmessagesgainaccesstothenetworkwhentwo
ormoremessagesrequestaccessatthesametime.
Each message is tagged with a priority (lowest value is the highest priority). Each
message identifier must be unique and assigned at design time. The message ID
definestheprioritylevel.TheCANprotocolusesnondestructivebitwisearbitrationto
control access to the bus. It is non destructive as the node winning arbitration
continues on with the message without the losing message being destroyed or
corruptedbyanothernode.Thenodethatlosesarbitrationjoinsthequeueagain.This
guarantees access to the bus for the controller with the highest priority message.
There can be some latency if a message is already being transmitted or a higher
prioritymessagewantsaccesstothebus.Ifalowprioritymessageandahighpriority
message are vying for bus access, there will be greater latency for a lower priority
message.
Forthisnondestructivebitwisearbitrationtotakeplacesomepreconditionshaveto
be established. First the logic states need to be defined as dominant or recessive.
Second the transmitting node must monitor the state of the bus to see if the logic
stateitistryingtosendactuallyappearsonthebus(Pazul,1999).Normallylogichigh
isassociatedwithaoneandalogiclowisassociatedwithazerohowevertheCANbus
definesalogicbitzero(0)asthedominantbitandlogicbitone(1)astherecessivebit.
Thedominantbitstatewillalwayswinarbitrationovertherecessivebitstatetherefore
thelowerthevalueofthebitidentifier(valueofallzeros)thehigherthepriorityofthe
message.Messagesthatneedtobetransmittedmoreoftenonthenetworkshouldbe
assigned a higher priority ID e.g. Data coming from engine management is of higher
criticalitythandataforairconditioningifonthesamebus.
IftwonodesaretryingtogetaccessthebussaynodesAandBandnodeAwins
arbitration.BecausethenodesarecontinuouslymonitoringtransmissionnodeBsees
that the bus state does not match what it transmitted so it stops transmitting. This
allowsnodeAtocontinuewithtransmission.Bothnodesvieforthebusagainonce
34
node A releases control and both nodes want to retransmit at the same instant.
Figure38showsthisprocess.
Figure 3-8: Arbitration Process
3.5 CANErrorHandling
Errorhandlingpreventsasinglenodefromlockingthenetwork(Corrigan,2002).The
CANprotocolintotalincorporatesfiveerrorcheckingmethods(BOSCH,1991);
BitError
StuffError
CRCError
FormError
AcknowledgmentError
When the CAN controller detects an error it transmits an error frame. Every CAN
controlleronthebuswilltrytodetecterrorsinitsmessages.Thenodethatdiscovers
the error will transmit an error flag. By transmitting an error flag the bus traffic is
destroyed and any other node thatdetectstheerror flag will also discardits current
message. Each node maintains two error counters, a transmit error counter and a
receiveerrorcounter.Theerrorcountersaremodifiedaccordingly.
1. When a RECEIVER receives an error the RECEIVE ERROR COUNT is
increased by one except when the received error was a bit error sent
duringanACTIVEERRORFLAGoranOVERLOADINGFLAG.
35
2. Whenthereceiverdetectsadominantbitasthefirstbitaftersending
anerrorflag,thereceiveerrorcountwillbeincreasedby8.
3. Whenthetransmittersendsanerrorflagthetransmitterincreasesthe
errorcountby8.Twoexceptionsare:
If
the
TRANSMITTER
is
error
passive
and
detects
an
ACKNOWLEDGMENTERRORbecauseofnotdetectingadominantACK
anddoesnotdetectadominant bitwhilesendingitsPASSIVEERROR
FLAG
If the TRANSMITTER sends an ERROR FLAG because a STUFF ERROR occurred during
ARBITRATION whereby the STUFF BIT is located before the RTR bit, and should have
beenrecessive,andhasbeensentasrecessivebutmonitoredasdominant.
4. IfaTRANSMITTERdetectsaBITERRORwhilesendinganACTIVEERROR
FLAGoranOVERLOADFLAGtheTRANSMITERRORCOUNTisincreased
by8.
5. IfaRECEIVERdetectsaBITERRORwhilesendinganACTIVEERRORFLAG
oranOVERLOADFLAGtheRECEIVEERRORCOUNTisincreasedby8.
6. Anynodetoleratesupto7consecutivedominantbitsaftersendingan
ACTIVE ERROR FLAG, PASSIVE ERROR FLAG or OVERLOAD FLAG. After
detecting the 14th consecutive dominant bit (in case of an ACTIVE
ERROR FLAG or an OVERLOAD FLAG) or after detecting the 8th
consecutivedominantbitfollowingaPASSIVEERROR FLAG,andafter
each sequence of additional eight consecutive dominant bits every
TRANSMITTER increases its TRANSMIT ERROR COUNT by 8 and every
RECEIVERincreasesitsRECEIVEERRORCOUNTby8.
7. After the successful transmission of a message (getting ACK and no
erroruntilENDOFFRAMEis finished)theTRANSMITERRORCOUNTis
decreasedby1unlessitwasalready0.
8. Afterthesuccessfulreceptionofamessage(receptionwithouterrorup
totheACKSLOTandthesuccessfulsendingoftheACKbit),theRECEIVE
36
ERROR COUNT is decreased by 1, if it was between 1 and 127. If the

RECEIVEERRORCOUNTwas0,itstays0,andifitwasgreaterthan127,
thenitwillbesettoavaluebetween119and127.
9. AnodeiserrorpassivewhentheTRANSMITERRORCOUNTequalsor
exceeds 128, or when the RECEIVE ERROR COUNT equals or exceeds
128.Anerrorconditionlettinganodebecomeerrorpassivecausesthe
nodetosendanACTIVEERRORFLAG.
10. AnodeisbusoffwhentheTRANSMITERRORCOUNTisgreaterthanor
equalto256.
11. An error passive node becomes error active again when both the
TRANSMITERRORCOUNTandtheRECEIVEERRORCOUNTarelessthan
orequalto127.
12. A node which is bus off is permitted to become error active (no
longer bus off) with its error counters both set to 0 after 128
occurrence of 11 consecutive recessive bits have been monitored on
thebus.
UsingtheerrorcounterstheCANnodenotonlydetectserrorsbutalsocontainsthem
bydetectingtheconstanttransmissionoferrorframes.TheCANbuschangesbetween
Error Active, Error Passive and BusOff depending on the error counter value (Daniel
Mannisto,2003).TheparametersareillustratedinTable31.Theyalsoensurethata
nodecannottieupthebusbyrepeatedlyretransmittingerrorframes.
37
Table 3-1: CAN Error States
128
>255
127
255
Errors
Comment
Errors Errors
Errorcounteroperatesas
Error
Active
normal,iferroroccurserror
flagissentandmessageis
destroyed
Canonlysendoutpassiveerror
flagonceanerrorisdetected,
Error
Passive
canstillsendandreceive
messages.Cannotbecome
erroractiveuntilcounterfalls
below128
Canonlyenterthisstatedueto
transmiterrorcounter
exceeding255.Nodethatis
BusOff
busoffcannotinfluencethe
businthisstate.Controllerand
counterresetandstart
sequencesaresent
The maximum and minimum data rate for a CAN network is 1Mbps and 10Kbps
respectively. Cable length depends on the data rate being used. Normally all the
devicesinthesystemtransferatauniformandfixedbitrate.Themaximumlinelength
is1km;40metresat1Mbps.Terminationresistorsareusedateachendofthecable.
38
3.6 CANProtocolFeatures
TheCANprotocolprovidesfourprimarybenefits;
A standardised communication protocol simplifies and economises interfacing

subsystemsfromvariousOEMsontoacommonnetwork
The communication load is shifted from the host CPU to the intelligent
peripheralthatgivesthehostCPUmoretimetorunitssystemtasks
Usingamultiplexednetworkvastlyreducesthesizeofthewiringharnessand
eliminates pointtopoint wiring. This can increase the efficiency of a vehicle
duetothefactitiscarryinglessweight
The broad market appeal of CAN is that it can be employed in multiple

industries (aerospace, manufacture of automobiles (robotics)) and motivates
the semiconductor industry to manufacture and develop competitively priced
CANdevices
BecauseCANisamaturetechnologyandhasbeendevelopedoveranumberofyears,
the cost of developing and improving CAN based systems has fallen. The CAN
communication network is an eventtriggered architecture. This means that the
occurrenceofaneventisrecognisedbythesystemasachangeataninputorsensor
etc.ByoperatingamessageprioritysystemCANisdeployableinrealtimedistributed
systems. For realtime deployment to work there has to be a guaranteed minimum
messagedeliverytime,wheretheworstcasedelaysshouldnotbeallowedexceedthe
maximum delay. Alsoan 8bit microcontrollerwith aslittleas 4K of memory and 256
bytesofRAMisabletosupportaCANapplication.OneofthemaindrawbacksofCAN
is its nondeterministic nature. This makes it impossible to test completely a CAN
basedsystemforeverypossibleerrorthereforemakinglivetestingmuchmorecritical
to enable delivery of an error free product to the customer. One of the major
disadvantagesofCANistherestrictedroomforfurtherdevelopmentofapplicationsas
thebandwidthlimitationsarebeingreached(i.e.lackofscalability).TraditionallyCAN
systemsweredesignedtohavebusloadsof3040%.Thisincreasedfurthertobusloads
39
of 80% with the development of scheduling tools such as Volcano Network

Architecture (Robert I. Davis, 2007). To guarantee message delivery times a certain
percentage of the bandwidth needs to be unused to prevent the blocking of low
prioritymessagesathighbusloads.Futurescalabilitycannotbeimproveduponfurther
inthesetypeCANsystemswithoutaddingadditionalCANsubbuses.
3.7 TTCAN(TimeTriggeredControllerAreaNetwork)Introduction
TTCANaddressessomeoftheshortcomingofCANsuchasnondeterminismthrough
the use of TT architecture. TTCAN offers a predefined timetriggered method of
scheduling CAN messages for synchronous message transfer. For asynchronous
message transfer, TTCAN instigates message transfer with occurrence of an event
(Centre,19982005).
3.7.1 TTCANCycleStructure
TomaximisetheuseofTTCANoverCANthenetworkrequiresadeterministicelement.
Thisallowsareductioninlatency(jitter)valuesofhighprioritymessagesgettingaccess
tothebus,thereforeprovidingadeterministicaspecttothenetwork.Atimemaster
basescommunicationontheperiodictransmissionofareferencemessage.Oncethis
reference message is sent by a node all other nodes on the network synchronise
themselvestothis.ThisprovidesCANwithquasieventtriggeredprotocolfeatures.
An advantage of using the TTCAN based system is the possibility of transmitting an
eventtriggered window during a timetriggeredslot.This isachievedbytransmitting
the eventtriggered message in the arbitrating time window. During this window ET
messages vie for access to the network. This is achieved through the arbitration
method CAN uses, if there is more than one message looking for access to the
network.
40
TheTTCANcommunicationcycleiscalledamatrixcycleasseeninFigure39(G.Leen,
2001).
Figure 3-9: TTCAN Matrix Cycle
The start of each cycle is denoted by its reference message. The time masters
reference messages are used to guarantee the operation of CAN. This operates on
extensionlevel1.Extensionlevel1guaranteestheTToperationofCANbasedonthe
reference message of a time master. The reference message on this extension level
only requires one byte for control information the rest of the bytes (7bytes) can be
usedfordata.Inextensionlevel2agloballysynchronizedtimebaseisestablishedand
acontinuousdriftcorrection among the CAN controllers is realised.Onextensionlevel
2, a global synchronisation time base is used to counter any drift that occurs. This
extension level requires 4 bytes for control information and additional bytes can
containdata(ThomasFhrer,2000).
AscanbeseenfromFigure39thematrixcycleismadeupofabasecycle.Eachbase
cycleisthelengthfromonereferencemessagetothestartofthefollowingreference
message. In between the reference messages are time windows. Each window per
base cycle can be different but all base cycles have to contain the same properties
41
relatingtotimewindows.Timewindowscanbeusetotransmitperiodicoraperiodic
messagesdependingontheconfigurationbythedesignengineer.Thismeansthatthe
cycleisfixedandisnotchangedwhileonline.Thetimewindowthattransmitsperiodic
messages is called an exclusive window, where as a time window for aperiodic
messagesarecalledarbitrationwindowsasillustratedinFigure3.10.Afterthesecond
arbitrationwindowthecyclerepeatstobuildupintoamatrix.
Figure 3-10: TTCAN Sample Window Time
TTCANcanbeimplementedwhereCANhasalreadybeenimplemented,andiscovered
under the standard ISO118984 (A. Albert, 2003). TTCAN is compatible with the
existingCANnetworkastheyhavethesamephysicallayer.
TTCANhasadvantagesoverCANsuchasitcontainstimetriggeredandeventtriggered
properties. This means TTCAN is deterministic yet still has some of the flexibility of
CAN that allows for more efficient bandwidth usage. TTCAN can also be used in
companiesthathaveinvestedinknowledgeofCANbecausethetoolsandequipment
are cross compatible. Even though TTCAN offers improved bandwidth utilisation was
developedafterOneareawhereitdoesnotofferincreasedbandwidthwhencompared
tothemaximumbandwidthavailableinCAN.fallsdownisithasthesamebandwidth
limitationsasCAN.
42
3.8 Conclusion
In thischapter the specifics of theCAN protocol are discussed in depth. The chapter
starts off with an overview oftheCAN layers in relation to theOSI reference model.
Then the CAN frame format is explained in relation to the standard 11bit frame
formatandthe32bitformat.Arbitrationanderrorcheckingareextensivelydiscussed
as these parameters play a significant role in the successful implementation of CAN.
TTCAN is also discussed in this chapter due to it being derived from CAN. The
differencesbetweenCANandTTCANarediscussedasisthecyclestructureofTTCAN.
Because CAN is an established protocol it continues to be widely used within the

automotiveindustry.Factorssuchasintegrationintoacompanysdevelopmentmodel
andavailabilityof expertise will ensure thattheCAN protocol willnot facea sudden
discontinuation in use. It has also been recognised by the automotive industry that
CANisincapableofprovidingforthefuturerequirementsofallapplications.TTCANis
furtherproofthatTTfeaturesinaprotocolarerequiredintheautomotivesector.This
has lead to alternative protocols such as FlexRay and TTTech (TTTech joined the
FlexRay consortium (Technology, 2005)). It appears that through the volume of
research(theFlexRayconsortiumhaveextendedtheiragreementuntil31stDecember
2009)andthroughproductreleases,FlexRaywillbethedefactoautomotiveprotocol
(ThomasNoltey,2005)whereCANisnotsuitable.
43
3.9 References
(CIA),C.I.A.(2008)CANOpen,06/11/2008
A.ALBERT,R.S.,A.TRACHTLER(2003)'MigrationfromCANtoTTCANforaDistributed
ControlSystem'9thinternationalCANConference,Munich,
BOSCH(1991)CANSpecificationVersion2.0.
CENTRE,C.A.S.R.(19982005)TTCAN,03/03/2008
CIA.ORG,C.(20012007)CANPhysicalLayer,
CORRIGAN,S.(2002)IntroductiontoControllerAreaNetwork(CAN)
DANIELMANNISTO,M.D.(2003)AnOverviewofControllerAreaNetwork(CAN)
Technology.mBus.
G.LEEN,D.H.(2001)TTCAN:anewtimetriggeredcontrollerareanetworkTTCAN:a
newtimetriggeredcontrollerareanetwork,12/02/2008
PAZUL,K.(1999)ControllerAreaNetwork(CAN)Basics.MicrochipTechnologyInc.
ROBERTI.DAVIS,A.B.,REINDERJ.BRILANDJOHANJ.LUKKIEN(2007)ControllerArea
Network(CAN)SchedulabilityAnalysis:Refuted,RevisitedandRevised.Springer
Science+BusinessMedia.
RUFINO,J.E.(1997)AnOverviewoftheControllerAreaNetwork.InstitutoSuperior
Tecnico,intheTechnicalUniversityofLisbon.
TECHNOLOGY,P.E.(2005)TTAutomotivejoinsFlexRayConsortium,05/11/2008
THOMASFHRER,B.M.,WERNERDIETERLE,FLORIANHARTWICH,ROBERTHUGEL,
MICHAELWALTHER,ROBERTBOSCHGMBH(2000)'TimeTriggered
CommunicationonCAN'Proceedings7thInternationalCANConference,
Amsterdam,RobertBoschGmbH
THOMASNOLTEY,H.H.,LUCIALOBELLO(2005)AutomotiveCommunicationsPast,
CurrentandFuture
44
FlexRay
4 FlexRay:
4.1 Introduction
This chapter describes the FlexRay protocol in detail. Specific areas of focus are on
FlexRaysphysicalstructure,framestructureandcommunicationcycleoperation.The
followingsectionsarecriticaltothedevelopmentofthemigrationframeworkasthey
formthecoreoftheFlexRayprotocol.
FlexRay offers reliable, realtime capable, highspeed data transmission between

electricalandmechatroniccomponents.TheFlexRayconsortiumwasfoundedby;
Automobilemanufacturers
Semiconductormanufacturers
Expertsincommunicationtechnology
Andsystemsupplierstobenefittheautomotiveindustry foundedtheFlexRay
consortium
All companies involved jointly developed a new standard that is openly available to
membersandisintendedtosupplementtheestablisheddatabussesofCAN,LINand
MOST. A communication network is the backbone of an Xbywire system. Initial
developmentofXbywirewillinvolvehavingthemechanicalandhydraulicmechanism
as a back up to the critical devices such as steering, breaking etc (Thomas Fhrer,
2000).
FlexRayisanalternativeprotocoltocomplementexistingprotocolsasillustratedincan
Comment [FW1]: Complementexisting
protocolsandfurthermore,address
implementationsthatarenotsuitable....
beseenfromFigure41.
45
FlexRay
Figure 4-1: Possible FlexRay Implementation
TheobjectivesoftheFlexRayconsortiumarethejointdevelopmentofaninnovative
andhighqualitycommunicationsystemandacomprehensiveinfrastructureforfuture
distributed applications. This involves developing the specifications for the
communication protocol, the physical layer, the bus guardian, hardware and the
softwareinterfaces.TheconsortiumwasfoundedbyBMW,DaimlerChrysler,Motorola
semiconductors products sector (now Freescale semiconductors) and Philips
semiconductorsin2000.Intotal103companiesarepartoftheFlexRayconsortium;7
of whichthem ares core members, 25 as premium associate members, and 71 as
associatemembers(Consortium,2008).
4.2 FlexRayFeatures
The FlexRay consortium was set up because it became obvious that existing data
transfer rates used within the chassis, body and power trains of todays vehicles will
reach their limits in the next generation systems. The main features of FlexRay are
(Consortium,2008);
46
FlexRay
Synchronousandasynchronousdatatransmission
Supportofafaulttolerantscalabletimebase
Scalableelectrical/electronicarchitecturessupportingamultipleofplatforms
Singlechannelgrossdatarateof10Mbits/s
Deterministicdatatransmissionwithguaranteedmessagelatencyandmessage
jitter
Supportforredundanttransmissionchannels
Faulttolerantandtimetriggeredservicesavailableinhardware
Arbitrationfreetransmission
Supportforbusandstartopologies
Fasterrordetectionandsignalling
Supportofwakeupandsleepfunctionalityviathebus
FlexRay can attain ahas data transfer rate of 20Mbit/s over dual channels or a data
rateof10Mbit/sonasinglechannel.FlexRaysupportsdeterministicdatatransferand.
FlexRay supports numerous network topologies such as pointtopoint, passive star,
linearpassivebus,activestarnetwork,cascadedactivestarsandhybridtopologies.For
interconnection two primary topologies are proposed; star based interconnection
topology and a bus based interconnection topology. Both of these interconnection
methods can use dual channel systems. The star configuration can be deployed in
distributedconfigurationsuchthattwostarbasedsubsystemsareconnectedbystar
tostarlinks.Adistributedsystemcanalsobedesignedbycombiningthestarandbus
approachallowingseveralnodestobeconnectedtoabranchofthestarasshownin
Figure42.
47
FlexRay
Figure 4-2: Star and Bus Topology Combination
4.3 FlexRayCycleStructure
FlexRay communication is based on 64 occurs in reoccurring communication cycles,

composedofaStaticSegment(ST),DynamicSegment(DYN),NetworkIdleTime(NIT)
andanoptionalSymbolWindow,asillustratedinFigure43.Thecommunicationcycle
isthefundamentalelementofthemediaaccessschemewithinFlexRay.FlexRayoffers
twomediaaccessschemes;TDMA(TimeDivisionMultipleAccess)andadynamicmini
slotting based access scheme. The duration of the cycle is fixed when the network
isbecomesconfigured.Atimewindow,whichisdefinedbythecommunicationcycle,
can be divided into two parts, a static segment and a dynamic segment. In addition
each cycle can contain a symbol window that is used for run time testing, and a
networkidletimethatallocatesacommunicationsfreeperiodupontheconclusionof
eachcommunicationcycle.
48
FlexRay
Figure: 4-3: FlexRay Cycle Structure
The purpose of the static segment is to provide a time window for scheduling a
numberoftimetriggeredmessages.Thispartofthecycleisreservedforsynchronous
communication, which guarantees a certain frame latency and jitter through fault
tolerantclocksynchronization.Themessageswhicharetobetransferredthroughthe
staticsegmentmustbeconfiguredbeforestartingcommunication(offline).Forthisto
be achieved the static segment uses a TDMA based communication scheme. In the
dynamic part of the communication cycle each device may transfer eventtriggered
messages, which are prioritised by frame ID. Temporal characteristics of the
communication cycle are defined at design time and stored statically in each node.
Nodesthatrequiregreaterbandwidthareassignedmoreslotsthanthosethatrequire
lessbandwidth.
Currently most Hhighspeed vehicle control systems are today networked byusing
CAN.IfoneofthewiresintwowireCANbecomescutorshorts,thetimingbehaviour
oftheCANbusbecomesunpredictable.Whenonewireiscutorshortedinterference
can increase on the bus because the inverted voltages on each wire minimise the
interferencecancellingeffect.WithexcessinterferenceCANbusdatacanberendered
uselessforitsintendedpurpose.OneofthemajoraimswhendevelopingFlexRaywas
49
FlexRay
scalable fault tolerance. Using this approach FlexRay could be used in nonfault
tolerant systems as well as fault tolerant systems. FlexRay provides scalable fault
tolerancebyameansofadualchannelsystemwithmixedconnectivity(somenodes
connectedtobothchannelsothernodesconnectedtoonlyone).
4.4 FlexRayNodeStructure
EachFlexRaynodeconsistsofacontrollercomponentandadrivercomponentascan
beseeninFigure44.
Figure 4-4: Node Architecture (Consortium, 2005)
Thecontrollercomponentincludesahostprocessorandacommunicationcontroller.
The driver component includes the bus drivers and optional bus guardians. The bus
guardian protects the communication channels from transmission faults that violate
theTDMAscheme.Thebusguardianalsopreventsmalfunctionsbyonlygrantingbus
access for sending a message at predefined times for each node. The bus driver
connectsboththecommunicationcontrollertothebusandthebusguardianaccessto
the bus. The host informs the bus guardian which time slots the communication
50
FlexRay
controllerhasallocated.Thebusguardianthenallowsthecommunicationcontrollerto
transmitdataonlyinthesetimeslots.Ifthebusguardiandetectsagapinthetimingit
disconnects the communication channel. A summary of how each component of a
FlexRaynodeinteractswithanothercomponenttoenabledatatobetransmittedonto
thenetworkisillustratedinFigure45.
Figure 4-5: Node Components
4.4.1 CHI(ControllerHostInterface)
TheFlexRaycore(betweenthehostprocessorandtheprotocolengine)ispartitioned
such that the Protocol Engine (PE) is responsible for all FlexRay specific protocol
handlingandtheControllerHostInterface(CHI)handlesalltasksofintegratingFlexRay
functionality into the rest of the system. Figure 46 shows how the protocol engine
interfaceswiththehostprocessorviatheCHI.
51
FlexRay
Figure 4-6: Role the CHI has in the PE interacting with the host processor (Consortium, 2005)
The CHI provides host access to the FlexRay protocols cores configuration; (control
andstatusregister).asAlsotheCHIprovidesaccesstowellastotthemessagebuffer
configuration, (control and status register). The FlexRay buffers hold the FlexRay
frames (Receive and Transmit frames) including the frame header, payload data and
frame status information. The message buffer data is stored in the FlexRay memory
andthemessagebuffercontrolstructuresareimplementedintheCHI.Differentend
user applications have different requirements therefore the core should be
configurabletooptimiseapplicationperformance.
4.5 FlexRayFrameStructure
The FlexRay frame format is illustrated in Figure 47. The frame consists of three
segments;theheadersegment,thepayloadsegmentandthetrailersegment.Whena
node configuration appears on the network it is transmitteds on the network,
transmissionoccursinthisorder(header,payloadandtrailer).
52
FlexRay
Figure 4-7: Frame Format (Consortium, 2005)
4.5.1 HeaderSegment(5bytes)
ReserveBit
The1bitreservebitisreservedforfurtherdevelopmentsoitshallbeignoredandset
tozero.
PayloadPreambleIndicator
The payload preamble indicator (1 bit) indicates if the payload section contains an
optional network management vector as illustrated in Figure 48a. If the message is
transmittedinthestaticsegmentitindicatesthepresenceofanetworkmanagement
vector(seeFigure48a).Ifitistransmittedinthedynamicsegmentitindicatesifthere
is a message ID (see Figure 48b). If it is set to zero neither are contained in the
payloadpreambleindicator.
53
FlexRay
Figure 4-8: Payload segment containing the Network Management (NM) Vector & Message ID
NullFrameIndicator
Thenullframeindicator(1bit)indicateswhetherthereisanullframe.Ifthenullframe
issettozerotheframecontainsnovaliddataandallbytesinthepayloadsectionare
settozero.
SyncFrameIndicator
TheSyncframeindicator(1bit)indicateswhetherornottheframeistobeusedfor
system synchronisation. When set to a zero the frame is not considered for
synchronisation,otherwiseitisconsideredforsynchronisation.
StartUpFrameIndicator
Thestartupframeindicator(1bit)indicatesiftheframeisastartupframeotherwise
isgivenavalueofoneotherwiseitisgivenavalueofzero.Onlycoldstartnodescan
transmitstartupframes.
FrameID
TheframeID(11bits)definestheslotinwhichtheframeshouldbetransmitted.The
frameIDrangesfrom1to2047,anIDvalueofzeroisinvalid.Thenodetransmitsthe
frameIDwiththemostsignificantbit(MSB)beingtransmittedfirstanddecreasingin
order(totheLSB).
54
FlexRay
PayloadLength
The payload length (7 bits) indicates the size of the payload segment. It is set by
getting the number of payload data bytes and dividing it by two (e.g. a frame that
containedapayloadsegmentof72byteswouldbetransmittedwithalength36).The
payloadlengthisfixedwhensentinthestaticsegmentbutmayvaryforframessentin
thedynamicsegment.
HeaderCRC
TheheaderCRC(cyclicredundancycheck)(11bits)usesaCRCcodecalculatedoverthe
sync frame indicator, the start up frame indicator, the frame ID and the payload
length. The communication controller (CC) calculates the header CRC of a received
frameinordertocheckthattheCRCiscorrect.TheheaderCRCoftransmittedframes
is calculated offline and is provided to the communication controller during
configuration. Computation of the header CRC is done by first shifting in the sync
frame indicator then the MSB of the frame ID followed by the rest of the frame ID,
thentheMSBofthepayloadlengthandthesubsequentbitsofthepayloadlength.The
headerCRCistransmittedwiththeMSBtransmittedfirst.
CycleCount
The cycle count (6 bits) keeps track of the value of the cycle counter at the time of
frametransmission.
4.5.2 PayloadSegment(0254bytes)
Because the payload segment contains twobytewords it must contain an even

numberofbytes.Thebytesarenumberedstartingatzeroandincreasingbyonebyte
witheverysubsequentbyteafter.InFigure4810Data0isreferredtoasthefirstbyte
andData1asthesecondbyteassoforth.Forframesinthedynamicsegmentthefirst
two bytes may contain the message ID field. For frames in the static segment up to
55
FlexRay
twelvebytesmaybeusedtoindicateanetworkmanagementvector.TheMSBofeach
bytewillbetransmittedfirstwiththesubsequentbytesfollowing.
4.5.3 TrailerSegment(3bytes)
Thetrailersegmentcontainsa24bitCRCfortheframe.TheCRCframecontainsaCRC
code computed over the header segmentand thepayload segment of theframe (all
fields within these segments are included). The CRC is computed using the same
generatorpolynomialonbothchannelsbutadifferentinitialisationvectorisusedfor
eachofthetwochannels.Theframefieldsarefedintothegeneratorstartingwiththe
reserved bit and ending with the least significant bit (LSB) of the last byte of the
payload segment. The CRC frame is transmitted starting with the MSB descending in
sequencetotheLSB(Consortium,2005).
4.6 FlexRayTimingHierarchy
Having discussed the FlexRay frame format the next critical component to
understandingFlexRayisitstiminghierarchy.Thetiminghierarchycanbebrokeninto
fourdistinctlevelsforanalysis:
Level1:MicroTicklevel(T)
Level2:MacroTicklevel(MT)
Level3:ArbitrationGridLevel
Level4:CommunicationCycleLevel
Level 1 (Microtick): The T is a time unit that is extracted from the communication
controllersoscillatorclock.Aprescalarvaluecanbeusedifnecessary.Themicrotick
valueisgiveninunitsofmicroseconds.Thesmallesttemporalgranularityofanodeis
inT.
56
FlexRay
Level2(macrotick):TheMTvalueisanintegermultipleofTs.ThenumberofTsper
MTcanfluctuatebetweennodesandalsofluctuatebetweenMTsonthesamenode
(Consortium,2005).ActionpointsdesignatewhentransmissionsontheMTlevelstart.
TheMTfigureisalsopresentedinmicroseconds.
Level 3 (arbitration grid level) is where the static slots are defined for the static
segmentandminislotsaredefinedforthedynamicsegment.
Level 4 (communication cycle) is composed of the static segment, dynamic segment,

network idle time and optional symbol window. The symbol window is where media
accesstakesplace.Networkidletimeiswherenotransmissiontakesplaceexceptto
applyclockcorrectionvaluesanditisrequiredtoconcludeeverycommunicationcycle.
ThenumberofMTspercycleshallbeanintegervalueandthisisconstantthroughall
nodesinaspecificcluster(Consortium,2005).AllfourlevelsareillustratedinFigure4
9.
Figure 4-9: FlexRay Timing Hierarchy (Consortium, 2005)
Asmentionedpreviouslytherearetwomediaaccessschemes, TDMAandadynamic
minislottingaccessscheme(or flexibletimedivisionmultipleaccess(FTDMA)asitis
sometimesreferred).ThestaticsegmentoperatesrunsontheaTDMAschemeandthe
dynamicsegmentoperatesarunsonthedynamicminislottingscheme.Eachstaticslot
57
FleexRay
DMAschemeisobtaineedfromtheearbitration
nlevel.The minislotscchemealso
o
fortheTD
obtainsitssbaseminislotfromth
hislevelascanbeseen
ninFigure449.
mmunicatiionCycle
4.7 Com
Ray commu
unication cyycle frame is composed of the ST segmen
nt the DYN
N
The FlexR
segmentttheoptionaalsymbolwindowand theNIT(Neetworkidle Time).Itissduringthee
NIT that calculationss are carrieed out for the offset and phasee as discusssed in thee
section4.7
7.5.Figure410illustraatesanexaampleoftheecompositiionofaFlexxRayframee
fortransm
missioninacommunicaationcycle.Thecomm
municationccycleisasilllustratedin
n
Figure43
3previously.
Figure 4-100: Possible FlexRaay Frame Cycle C

Configuration
The comm
munication cycle is composed
c
o an integger numbeer of macro
of
oticks. Thee
number of
o macrotickks per cyclee is the sam
me for all nodes
n
in a ccluster. Also
o all nodess
should haave the sam
me cycle vaalue at any given instance of tim
me. The cyccle counterr
valueranggesfrom063.Oncethecycleco
ounterreachesthemaaximumvalu
ueitresetss
and startss counting again from
m zero in the next communica
c
ation cycle. The cyclee
countervaalueisincreementedatthestartoffeachcomm
municationcycle.
58
8
FlexRay
4.7.1 WakeUp
Foraclusterwakeupallbusdriversarerequiredtobesuppliedwithpower.Startup
occurs on all channels synchronously. At least one node in the cluster requires an
external wakeup source. The CC (Communication Controller) provides the host with
the ability to transmit the wakeup pattern and it prevents a disturbance on the
communication channel once communication occurs. The host sets the configuration
in the CC as to what channel is to be woken up. Each channel available is woken
separately. Both channels must not be woken at the same time to prevent a faulty
node disturbing communication simultaneously on both channels with its
transmission.
Thewakeuppatterncausesanyfaultfreenodetochangefromsleepmodetowake
upifitisstillinsleepmode.Thebusdriverofthereceivingnoderecognisesthewake
uppatterandtriggerswakeup.Duringthewakeupprocedureanynumberofnodes
cantryandwakeupachannel.Thisissueisresolvedduringthewakeupprocess.The
wakeuppatterniscollisionresilient.Ifafaultcausestwonodestotransmitwakeup
patternsthesignalresultingfromthecollisioncanwakeupothernodes.
4.7.2 CommunicationStartUp
AsFlexRayisbasedonaTDMAscheme,synchronicityhastobepresentforsuccessful
communication.Anodehastobeinthewakeupstatebeforestartupcancommence.
Startupisinitiatedbyacoldstartnode.Onlyanodeassignedasacoldstartnodemay
initiate this process. The node that starts the cluster is called the leading coldstart
nodeandthenodesthatfollowarecalledthefollowcoldstartnodes.
Start up is initiated by the coldstart node transmitting a CAS (Collision Avoidance

Symbol). Only this coldstart node can transmit in the four cycles that follow this
transmission. Next other coldstart nodes are allowed transmit then all other nodes
follow.ThecoldstartnodecontainsthepKeySlotUsedForStartUpparametersettotrue
and the header contains the startup frame indicator set to one. The
59
FlexRay
pKeySlotUsedForStartUpparametersetabitthatsignifiesthenodeasbeingacoldstart
node. If the cluster contains three nodes or less each node shall be considered a
coldstartnode.Eachnodeisalsoconfiguredtobeasyncframe,enablingeachnodeto
also be a sync node. Only startup frames can be transmitted during the startup
process.ForafollowcoldstartnodefirstitlistensontheFlexRaychannelforFlexRay
frames.Onreceptionofavalidpairofstartupframes,thenodetriestoderiveitsclock
correction and schedule from the coldstart node. If this is unsuccessful it collects all
sync frames and performs clock correction in the following double cycle. If clock
correction does not signal any errors and the node continues to receive sufficient
framesfromthenodeithadintegratedupon,ittransmitsitsstartupframe.Ifthisis
unsuccessfulitreturnstolistenmode.
For noncoldstart nodes, the node listens to the FlexRay channel to receive FlexRay
frames. It searches for two coldstart nodes that transmit startup frames that fit its
own schedule. If this is unsuccessful or clock correction throws an error the node
aborts integration and tries again from the start. Once two valid startup frames are
receivedthenodecanleavethestartupphaseandmoveintotheoperationphase.
The coldstart inhibit mode is available to prevent the node initialising the
communicationcycle.Thismodecanbeusedtoprohibitactivestartupattemptsofa
nodeordelaystartupattempts.
4.7.3 ClockStartUp
Beforesynchronisation can occur,clock startup has to take place. This isdependent

on the start and initialisation of the MTG (Macro Tick Generation) process and the
initialisationandstartoftheCSP(ClockSynchronisationProcess).Theclockwithinthe
node can be started through the coldstart node process if it is the leading coldstart
nodeoritadoptstheinitialisationvaluesofacoldstartnode.
60
FlexRay
4.7.4 ColdStart
Ifnocommunicationisdetectedonthechannels,aleadingcoldstartnodeneedstobe
assigned to trigger communication. This leading coldstartnode initiates the startup
procedure by sending start up frames. There has to be a minimum of two faultfree
coldstart nodes for successful startup. There is a limit of between 231 coldstart
attemptsthatcanbemadeasspecifiedby(Consortium,2005).
4.7.5 NodeSynchronisation
AsFlexRayisrunonadistributedcommunicationssystemeverynoderequiresitsown
individual clock. This leads to the challenge of synchronising every node because
operating a timetriggered protocol requires a global time base. This is achieved in
FlexRay through the usetransmission of sync frames being transmitted.
Synchronisation can be divided into two concurrent processes; the macrotick
generationprocess(MTG)andtheclocksynchronisationprocess(CSP).
The MTG controls the cycle and MT counter and applies rate and offset correction
values.ThisisachievedbyadjustingthenumberofTperMT.
The CSP is achieved by performing initialisation at the start of a cycle and then
calculatingandstoringthenewdeviation,offsetandratecorrectionvalues.Thereare
asetofprecisiondifferingvaluesallowedtobeselectedfrom.Therearetwotypesof
precisiondiffering values to chose from; offset (phase) and rate (frequency)
differences. FlexRay combines both of these to calculate offset and rate correction
valuesthatinturnsynchronisesthelocaltimebaseofeachnode.
SynchronisationontheFlexRaynetworkiscarriedoutinanumberofstages.AFlexRay
driverimplementsthesestepsThedriveroperationexaminedindetailinthisthesisis
the DECOMSYS COMMSTACK and is discussed in detail in Chapter 10 the
COMMSTACK<FLEXRAY> that is a controller software driver package. Other software
61
FlexRay
driverpackagesareavailablefromcompaniessuchasFujitsu(emea,2008)andVector
(Informatik,2008).
Theversionusedis1.8.2fromDECOMSYS.TheFlexRaycontrollerisresetthereforeno
accesstothecontrollerispermitted.
Resetisperformedagain
1causestransitiontotheConfigstateresethasbeencompleted
Wakeup:TheFlexRaycontrollertransmitsawakeuppattern
Abortcausesthetransmissionofthewakeuppatterntobeabortedimmediatelyand
returnstotheoffstate.
4.8 Conclusion
Over the past few years the development of the communication hardware has been
the main priority, butas this reaches a more advanced stagewecan startlooking at
developing the required applications can now be investigated. Due to FlexRays
characteristics (Large bandwidth, deterministic behaviour and fault tolerance) it is
ideallysuitedtotheroleofacentralbackboneoffutureECUarchitectures.Withthe
introduction of a new bus system, there is awe need to be able to incorporate the
older systems and products as well as being able to integrate support for the new
FlexRayfeatures.Whentestinganddevelopingthesesystemsitisvitalthattheycan
betestedunderrealtimeconditions.
JudgingbythestrengthandbackingofthecoreandassociatemembersoftheFlexRay
consortium it appears that it will becomes a dominant standard in automotive
distributedapplications.Themostprobablelikelyuseforitinthenearfuturewillbeas
a backbone network used in conjunction with other networks such as CAN and LIN.
These other networks are not expected to become redundant; instead these will be
used for other (less critical) control systems in the automobile. By the fact that the
FlexRay consortium agreed to extend their agreement from the 1st of January 2009
until31stDecember2009demonstratesthattheyareintentontakingthetechnology
forward.TheFlexRayconsortiumwasformedoutofnecessityduetopresentprotocols
62
FlexRay
notbeingabletomeetpredicteddemandsoffuturevehicles.TTCANwentsomeway
towardsmeetingtheserequirementsbutitwasnotabletofullycopethewayFlexRay
couldwithextrabandwidthrequirements.OnepotentialmajoradvantageforFlexRay
over other protocols is the reserve for future functional extensions (Schedl, 2007).
FlexRay will very likely become the defacto standard for invehicle communications
(TraianPop,2007).
4.9 References
ConsortiumF,2005,FlexRayprotocolspecificationVersion2.1RevisionA,[15th
December2005]
ConsortiumF,2008,TheFlexRayConsortiumWebsite,http://www.flexray.com
emeaF,2008,FlexRayProductOverview.
http://mcu.emea.fujitsu.com/mcu_product/overview_FlexRay.htm
InformatikV,2008,XLDriverLibrary.http://www.vector
worldwide.com/vi_xl_driver_library_en.html
SchedlDA,2007,GoalsandArchitectureforFlexRayatBMW,1stVectorFlexRay
Symposium,Stuttgart,Germany.
ThomasFhrerBM,WernerDieterle,FlorianHartwich,RobertHugel,Michael
Walther,RobertBoschGmbH,2000,TimeTriggeredCommunicationonCAN,
Proceedings7thInternationalCANConference,Amsterdam.
TraianPopPP,PetruEles,ZeboPeng,2007,BusAccessOptimisationforFlexRaybased
DistributedEmbeddedSystems,EDAA,
63
AutomotiveEmbeddedSystems
5 Automotive Embedded Systems

Design:
5.1 AutomotiveEmbeddedSystemDesign
Inthischapter,methodsofautomotiveembeddeddesignarediscussed.Firstthereisa
reviewoftheconceptofdistributedarchitecturesandrealtimeoperatingsystemsin
the context to the automotive industry. Secondly, design approaches for automotive
embedded systems are discussed. Thirdly, scheduling techniques are reviewed and
finallyanalysisandconclusionsarepresented.
5.2 DistributedArchitecturesIntroduction
Computerarchitectureisconcernedwiththedesignandperformanceofthesystemas
awhole(Jordan,2004).Indistributedsystemsprocessingpowerisdistributedamong
computers in a cluster or network (Englander, 2000). Communication protocols and
standards used in data networks allow data to be transferred between different
systems. This allows each system to do part of the processing giving higher overall
throughput and fault tolerance. This allows tasks that involve mass amounts of
computation to carry out this computation across the network of connected
computers.
The complexity and physical distribution of modern activesafety automotive

applicationsrequirestheuseofdistributedarchitectures(AbhijitDavare,2007).
Indistributedcomputingthefacttherearemultipleautonomouscomputersshouldbe
transparent to the end user (Lobur, 2003). When a command is executed in a
distributed operating system it selects the processors, manages transport to the
64
processors and stores results (Tanenbaum, 1996). In computer networking all file
management has to be called explicitly (Tanenbaum, 1996). This is where a true
distributed system varies from a networked system. A basic distributed architecture
consistsofamorethanonenodeconnectedbyacommunicationbusasillustratedin
Figure51.
Figure 5-1: Basic Distributed Architecture
5.2.1 BasicNodeDesign
Each node (as illustrated in Figure 52) contains a CPU, communications controller,
memory and an interface for an IO (Input/output). Typical IO interfaces are the
receptionofdatafromasensororasignaltoactuateanactuator.
Figure 5-2: General Node

Properties
The node architecture for a FlexRay node is to some extent different to the general
exampleinFigure52.ThisisduetoaCHI(ControllerHostInterface)beingrequiredto
interact between the CPU and the communication controller. The CHI explicitly
65
implements the FlexRay protocol and is independent of the CPU (Traian Pop, 2007).
TheFlexRaynodearchitectureispresentedindetailinFigure44.
The communication bus is configured according to the protocol being implemented.

Tasks can be assigned to processors through software and communicate with each
otherusing messages.Eachtaskiscapableofcommunicatingwithanothertaskona
separate processor by transmitting a message on the communication bus. The tasks
canbeperiodicoraperiodicwithorwithoutprecedenceconstraints.Thedeadlinescan
besoft(noncritical)orhard(critical)dependingontheapplicationrequirements.
5.3 RealTimeOperatingSystem(RTOS)
Theprimarydifferencebetweenrealtimesystemsandothercomputersystemsisthat
the response time is viewed as the crucial part of the application software in a real
timesystem(E.DouglasJensen,1985).
Realtime and embedded systems operate in environments that offer restricted
memory and processing power. For this reason an operating system capable of
respondinginrealtimeisrequired.IntheseenvironmentsanRTOScanbedesignedto
extract fast and predictable realtime responses (Schaffer, 2006). A hard realtime
system is one that has fatal errors if deadlines are missed. Soft realtime systems
deadlinesarenotascriticalashardrealtimedeadlines,ifdeadlinesaremissed.
Distributed architectures supporting the execution of hard realtime applications are

not only common in automotive systems, but also in avionics and industrial control
systems(AbhijitDavare,2007).ARTOShasasetoffunctionsthatarerequiredtobe
carried out when implementing an application on the host system. Some of these
functionsarepreemption,timesharing,interrupthandlingandmemoryallocation.
66
5.3.1 RTOSFunctions
The operating system controls tasks that carry out specific functions. The task to be
executedisdefinedbyaschedule(TT)ortheoccurrenceofanexternalevent(ET).
Through the use of interrupts a task with a high priority can get executed if a lower
prioritytaskiscurrentlybeingexecuted.Aninterruptdeclaresthatataskwithahigher
prioritythanthetaskcurrentlybeingexecutediswaitingforexecution.Oncethelower
prioritytaskfinishesexecutionthehigherprioritytaskisthenexecuted.Ifpreemption
isimplementedthehigherprioritytaskwillbeexecutedbeforealowerprioritytaskis
finished executing. The lower priority task is then executed if it is the next highest
prioritytaskisscheduledforexecution.Withoutpreemptionthehighprioritytaskwill
havetowaituntilthelowerprioritytaskisfinishedexecutionbeforeitgetsexecuted.
Aninterrupthandlerisrequiredtoenablepreemption.Whenamessageisavailable
for execution it notifies the interrupt handler and it is assigned an interrupt priority
and placed in the interrupt queue, the position in the queue depends on its priority
level. The interrupt request handler (IRQ) notifies the system that an interrupt is
pendingatacertainlocation,sothesystempausesmomentarilywhileitdecideswhat
actionisrequiredtodealwiththependinginterrupt.Theinterruptcanbeahardware
interrupt(externalinterrupt)orsoftwareinterrupts(fromaninstructionset).
5.4 OSEK/VDX
OSEK/VDXisasetofstandardsfordistributedrealtimearchitecturesdevelopedbya
consortiumofEuropeanautomobilemanufacturersandsuppliersinconjunctionwith
the University of Karlsruhe, Germany (Lemieux, 2001). The OSEK/VDX RTOS is widely
usedwithintheautomotiveindustry.Theprimaryparametersstandardisedare;
TheOperatingSystem(OS)
Communication(COM)
NetworkManagement(NM)
TheOSEKImplementationLanguage(OIL)
67
5.4.1 OS(OperatingSystem)
TheOSEKOSisasingleprocessorOSdesignedfordistributedembeddedcontrols.The
OS specification is intended to give an efficient utilisation of the environment
resourcesforautomotivecontrolapplications(OSEK,2005).Thissystemcanbeapplied
in applications that require a compact, realtime distributed system that is not
automotivebasedsuchasconsumerelectronicsitems.
5.4.2 COM(Communications)
The OSEK standard supports both intertask communication and interprocess

communication. The OSEK/VDX model covers five layers that are defined by the OSI
referencemodelasillustratedinFigure53;
Application
Interaction
Network
Datalink
Physical
InFigure53thelayersoftheOSEKmodelthatarealsodefinedintheOSIreference
model are shaded in (Layers 1, 2, 3, 6 & 7). The Interaction layer is similar to the
presentationlayerintheOSImodel.Thisiswheretheexchangeofdatabetweentasks
isspecified.
68
Figure 5-3: OSEK model Vs OSI 7 layer Model
5.4.3 NM(NetworkManagement)
The NM specification was designed primarily for the automotive industry. The basic
function of NM is to monitor the status of the nodes on the network, report status
information to the application and to handle APIs (Application Programming
Interfaces)forcontrolofNMcomponents.
5.4.4 OIL(OperatingsystemImplementationLanguage)
Since OSEK is a static operating system the definition of the system objects used is
requiredbeforecompiletime(Informatik,2008).TheOILfileiscomposedoftwoparts;
theimplementationspecificpartandtheapplicationspecificpart.Theimplementation
specific part is supplied with the OSEK/VDX implementation (Lemieux, 2001) and
should not be changed. The application specific part can be changed as deemed
necessarybythedesignerduringapplicationdevelopment.
69
5.5 ProcessModels
A process model shows the relationship between processes that make up a system.
Thishelpsidentifychangesthatmayberequiredinhelpingthesystemfunctionmore
efficiently.Whenimplementingaprocess modelthefirstbasicparameteristoknow
what system you are modelling. You can break down the model to the following
configurations
ETsystem
TTsystem
Mixedsystem
Asystemcanbebrokendownintosetofbasiccomponents.AsillustratedinFigure54
a simple task graph contains Tasks T1 andT2, the message m1 and the task graph
period.EachtaskcanrunonthesameECU,orintheotherextremeeverytaskinatask
graphcanrunonaseparateECU.
Figure 5-4: Basic Task

Graph
5.6 TaskSchedulingPolicies
There are a number of scheduling policies (procedural rules) to consider when

formalising a scheduling solution in a realtime system. Some of the methods for
consideration are earliest deadline (ED), deadline monotonic (DM), rate monotonic
70
(RM),leastslackscheduling(LSC),prioritypromotion(PP)andmixedtrafficscheduling
(MTS).Theprimaryobjectiveofanyschedulingpolicyistomeetthemessageandtask
deadlines. Scheduling methods are classed as fixed priority scheduling, static priority
schedulingordynamicpriorityscheduling.
5.6.1 DynamicPriorityScheduling
Dynamicpriorityschedulingallowsatasksprioritytobealteredduringruntime.This
increasestheoverheadrequiredtoimplementthisschedulingmethod.Thismethodis
nondeterministicwhichisnotidealforrealtimesystems(Oshana,2007b).
5.6.2 LeastSlackScheduling
Inthisschedulingmethodtheslackiscalculatedfromtheabsolutedeadlineminusthe
executiontimeforthetasktocompleteexecution.Thetaskwiththeleastslackisthen
giventhehighestprioritytobestguaranteeitwillmeetitsdeadline.
5.6.3 EarliestDeadline(ED)
Theearliestdeadlinemethodassignsthehighestpriorityvaluestotasksthathavethe
shortesttimeinwhichtocomplete.Thismethodworksinasystemthathasplentyof
capacity and uses preemption, but once the system starts to overload performance
degradesrapidly(Carey,1991).Thisisduetotasksthathavenotalreadymissedtheir
deadline, but are closest to missing them, being assigned the highest priority value.
This then results in tasks that can still make their deadline not being assigned the
highestpriorityvalues.Thetaskthatisclosesttoitsdeadlinemightnotactuallybeable
to complete in due time. If the processor utilisation bound is greater than 100%
deadlines will start to be missed. The utilisation bound is calculated by each process
executiontimedividedbyitsperiodaspresentedinEquation51.
71
Process ExecutionT ime

= Utilisation Bound
Process Period
Equation 5-1: Utilisation Bound
5.6.4 FixedPriorityScheduling
Fixedpriorityschedulingrequiresthatthepriorityofataskisnotchangedinrealtime.
The message or task schedule has to be known prior and scheduled offline in a
schedulingtable.Thisapproachdoesnotallownewmessagesthatarecreatedduring
theruntimetobeprocessed.
Twoofthemostcommonprotocolsthatusethismethodareratemonotonic(RM)and
deadline monotonic (DM). The most significant advantages of these methods are
simpleimplementationandgoodexploitationofavailablebandwidth(Natale,2000).
5.6.4.1 RateMonotonic(RM)
UsingtheRMschedulingmethodthehigheratasksfrequencythehigheritspriority,
therefore the task with the shortest period has the highest priority (Buttazzo, 2004).
WhenusingRMthefollowingcanbeassumed(Sha,1991)
Taskswitchingisinstantaneous.
Tasksaccountforallexecutiontime.
Taskinteractionsarenotallowed.
Tasksbecomereadytoexecutepreciselyatthebeginningoftheirperiodsand
relinquishtheCPUonlywhenexecutioniscomplete.
Taskdeadlinesareidenticalwithtaskperiods.
Taskswithshorterperiodsareassignedhigherpriorities;thecriticalityoftasks
isnotconsidered.
Task execution is always consistent with its rate monotonic priority: a lower
prioritytaskneverexecuteswhenahigherprioritytaskisreadytoexecute.
72
Using these factors, worstcase latencies can be calculated then compared to the
timingrequirementstodetermineifdeadlinesshallbemet.
5.6.4.2 DeadlineMonotonic(DM)
Deadline monotonic was derived from the rate monotonic scheduling; it is a

generalised version. The task with the shortest deadline has the highest priority; the
priorityisderived fromitsmessageID.Notaskcanhaveataskdeadlinelongerthan
thetaskperiodbecausethetaskneedstobefinishedbeforeitcanrunagain.
Both (RM and DM) systems require the highest priority task running, but in practice
thisisnotalwayspossible.Itisimpossibletogetimmediatetransitionbetweentasks
duetoatransitionperiodexisting;thistransitionperiodcanbeassmallasafactionof
amillisecond.
5.6.5 MixedTrafficSchedule
Mixed Traffic Scheduling (MTS) is employed through a combination of; fixed priority
schedulinganddynamicscheduling.
Oneexampleofthisapproachwasby(Shin,1995)whereaMTSconsistingofEDand
DMbutwithouttheneedforlongIDswasimplemented.Thenonpreemptiveversion
of DM is used so that once a message starts transmission it always completes.
Simulated results from Shin show that in terms of timing, MTS has superior
performancewhencomparedtoED.
73
5.7 TaskGraphs
Task graphs visually represent the parameters associated with each task that
comprisesanapplication.Thetaskgraphalsoshowsthesequenceoftasksthatrequire
executiontosuccessfullyexecutetheapplication.Taskgraphsareusedtoanalyseand
adjust constraints when developing an algorithm. They can also be used in ECU task
allocation, network/process design and performance modelling (Vikram Adve, 2006).
Thus a graph is a way of representing connections or relationships between pairs of
objects (Michael T. Goodrich, 2002). Task graph analysis involves similar techniques
used in critical path analysis. This allows for an abstract representation of the
applicationorsystem.
5.8 CriticalPathAnalysis(CPA)
CriticalPathAnalysis(CPA)techniquesweredevelopedseparatelyinGreatBritainand
the USA around the 1950s and 1960s. In Great Britain in the 1950s the Operational
Research (OR) section of the Central Electricity Generating Board, investigated
methods concerned with the overhaul of a generating plant. This led to a technique
identifying the longest irreducible sequence of event. Using this technique the
overhaultimeofaplantwasreducedby42%,inthe1960sthiswasfurtherreducedby
32%(Lockyer,1974).AlsointheUSAinearly1958theUSnavyspecialprojectsoffice
setupateamtodealwiththeplanningandcontrolofcomplexworks.Thiswasknown
as Performance Evaluation Review Task (PERT). This work resulted in early arrow
diagram drawings. Furthermore, in 1958 the US air force implemented a technique
calledCriticalPathMethod(CPM)tocontrollargeprojects(Lockyer,1974).
CPAtechniquesareusedacrossawidevarietyofindustriesfromconstruction,sales,
marketing,productionoranysectorwhereprojectplanningisrequired.Pathanalysis
wasdevelopedbecausethepreviousmethodssuchasGanttchartsdidnotsufficiently
demonstratetheinterrelationshipbetweenvarioustasks(Lockyer,1974).Anexample
ofthiswouldbethedesignernotbeingabletodeducebyexaminingaGanttthattaski
74
is or is not permissible for execution with or without precedence constraints. A

precedence constraint is if task i is unable to start execution until task i1 has been
received.
Using CPA the network undergoing planning can be abstracted and thought of as a
model. The model undergoing CPA is composed of activities/tasks connected by
arrows. Arrow diagrams themselves are graphical models scientifically drawn that
represent the logical sequence of the network (Reynaud, 1970). The arrow as
illustratedinFigure55showstheactivitiesprogression.Theactivityprogressiontakes
placeinthedirectionofthearrow.Themostbasicconfigurationisonenodeandone
arrowasillustratedinFigure55.Theheadofthearrowindicatesthecompletionofan
activity.
Figure 5-5: Simple Activity

Configuration
The expected duration of the activity is indicated by the placing of a value as a

subscriptonthearrowindicatingthedirectionofprocessflowasillustratedinFigure
56(forexampletheactivitydurationABwilltake2units).
75
Figure 5-6: Sample Process Model
Dummy activities are sometimes used. These are activities that do not require
resources, but can take time (Gordon, 1991). This is illustrated with a broken arrow
andisusedinsituationswheretwoormoreparallelactivitieshavethesameheadand
tail.Thedummyactivityisusedtodemonstratedifferentprocesspaths.Adummypath
isalsousedtoindicatelogicconditions(e.g.precedenceconstraints).
Furtherdevelopingtheactivitygraphrepresentation,constraintssuchasearliesttime
tocommenceactivityandlatesttimetofinishanactivitycanbeillustrated.Twowidely
usedconfigurationsareseeninFigure57.HereArepresentsthenodallabel,Eisthe
earliestdeadlineandListhelatestdeadline.
Figure: 5-7: Alternative Activity Task

Configurations
Process models using CPA techniques can range from the extremely simple as per
Figure55,tothecomplicateasperFigure58,andwithhighercomplexityifrequired.
76
Figure: 5-8: Sample Complex CPA Model
5.9 TaskGraphAnalysis
EachtaskonataskgraphcanberepresentedasillustratedinFigure59,itcontainsthe
tasknumberandtheprocesstimeforthattask.Taskgraphscancontainaslittleasone
task and there is no upper limit. Task graphs can be segmented to show different
processrunningondifferentsystemsandeachtaskisconnectedbyalineshowingthe
directionofdatatransfer.Thenumberonthislineisthemessagenumber(Figure510)
forcommunicationbetweentwotasks(Lockyer,1991).
Figure: 5-9: Task Contents
77
Figure: 5-10: Two Tasks, T1 & T2, connected

by a message m1
From the task graph, each tasks processing time and the task graph period can be
calculated. The release time (time atwhich the task is available forexecution)ri and
thedeadlinetime(timeatwhichthetaskhascompletedexecutionofdesignatedtask)
diforeachtaskcanalsobeindividuallycalculated.InFigure511,T1hasbeenassigned
a release time of 15ms and a deadline time of 18ms. Any unrequited task graph
process time that was previously designated for the execution of tasks can now be
consideredslack.Thisslackinthesystemcanbeevenlyassignedtoeachtaskonthe
pathasper(Aloul,2005).Thiswillincreasetheamountoftimethateachtaskhasto
processitsmessage.
Figure 5-11: Task T1s

release and deadline
parameters
78
Figure 5-12: Task Graph Example (Hurley, 1994)
TheassignmentoftaskstoprocessorscanbepresentedinGanttcharts.Ifthediagram
inFigure512isused,combinedwiththetaskparametersshown,itcanbeproventhat
differentpathchoicesareavailable.
Figure 5-13: Gantt Chart for Tasks in Figure 5-12 (Hurley, 1994)
Figure 513 demonstrates the advantage of having multiple processors (distributed

architecture) because the total execution time of all the tasks (if they were all
processed on one processor) would be 15units but the execution time is down to
9unitsusingthisconfiguration.Therearerestrictions,oneofwhichisthatsometasks
cannotexecuteuntiltheprevioustaskisfinished.ForexampleT4cannotbeprocessed
79
until T1 has been executed but T6 can be processed before T4 if T6 does not have
restrictionssuchasrequiringinputfromT4andT3.
5.9.1 WorstCaseExecutionTime(WCET)&BestCaseExecutionTime(BCET)
WCET and BCET analysis is used to determine if performance goals are met and if
interruptshavesufficientlyshorttimetoreact(JakobEngblom,2000).TheBCETisthe
shortest execution time, while the WCET is the longest execution time (Reinhard
WilhelmJE,2006)
TheOncethereleasetimesanddeadlinetimesarecalculatedforeachtaskinasystem
(includingtheslackifappropriate),thereisenoughinformationavailabletocalculate
the WCET for each task. Equation 52 can be used to test if the obtained WCET is
feasible. Where the WCET should be less than or equal to the deadline minus the
releasetime,otherwiseitcannotbeguaranteedthatthetaskwillmeetitsdeadlines.
The message delay is the time from the signal being generated, passing through the
ECU/sandcommunicationbus/esandarrivingatitsdestinationcompletingexecution
asperEquation53(e.g.actuatinganactuator)(AndreiHagiescu,2007).
w d r
Equation52:WCET
The WCET, deadline and release time can be used to calculate the message delay as
showninEquation53.
delay(mi ) = d r w
Equation53:MessageDelay
The BCET is the quickest time from when a message leaves one task and the time
taken until it completes execution. This includes time spent propagating through the
80
network.Factorssuchasbandwidthlimitations,latencyinthesystemandjitteraffect
theBCET.
When developing automotive applications the state space is too large to completely
determine all possible combinations therefore giving absolute WCETs. One method
around this is to get endtoend execution times for a set of scenarios or test cases.
Theproblemwiththisapproachisthattheminimumandmaximumtimesobtainedfor
that particular test case will lead to an overestimation of the BCET and
underestimationoftheWCET,whichisnotsafeforhardrealtimesystems(Reinhard
WilhelmJE,2006).
5.9.2 ResponseTimeAnalysis(RTA)
ResponseTimeAnalysisdeterminesifdeadlinetimesaremet.Beforethefinalsystem
or application parameters aredefinedthere is amethod for examining if thechosen
systemwillmeetitsrequireddeadlines.ThismethodrequirestheWCRT(WorstCase
ResponseTime)tobecalculatedandthencomparedtotherequireddeadline.Ifapre
emptive model is used the execution time and period of each task are required.
Equation 54, (Burns, 1994b), calculates the execution time based on the maximum
interferencefromahigherprioritytask.
win +1 = ci +
win
T C j
0
jhp ( i )
j Where wi = c i
Equation54:RecurrenceResponseTime
Where hp(i) is the set of all higher priority tasks than task i. Task i is delayed by
executiontimeCjwherejisaperiodictask.TheperiodicintervaltimeisTj.
Togetanindicationofwhetherthetasksmeetthesystemconstraintsfirstlysumthe
response times and then subtract the results from the deadline constraint (Oshana,
2007a).
81
Inthisframeworktheresponsetimeofamessageiscrucialindeterminingifthetasks
and applications meet their required deadlines. While tools are available that
determinestheWCRTofamessagethisresearchdidnothavetheappropriatedbudget
oraccesstothesetoolssotheequationsusedindevelopingthesetoolswereused.In
1994 schedulability analysis was developed for CAN showing WCRTs (Robert I. Davis,
2007). In 1995 work by Tindell and Burns was adopted by automotive manufacturer
Volvo Car Corporation. Using these works, configuration and schedulability analysis
wassuccessfullycarriedoutandimplementedontheCANbusintheVolvoS80.This
lead to the release of Volcano Network Architect by Volcano Communications
Technologies AB (Robert I. Davis,2007).Thisallowed improvementstoscheduling as
messagetimingscouldnowbeguaranteed.Themethodspreviouslyusedtocalculate
WCRTs were underutilising bus bandwidths.Using a systematic approach, bandwidth
utilisationtoincreasedfromthe3040%markto80%(RobertI.Davis,2007).
Worksby(Burns,1994a),(Burns,1994b),(RobertI.Davis,2007)and(Tindell,1994)are
used primarily in this framework in abstracting the necessary equations before
obtainingWCRTs.
In(Burns,1994b)theauthorpresentsfourphasesofatasksexecutionasillustratedin
Figure514.Hereaistheinitialcontextswitch,bistheTasksActualExecution,cisthe
internalactionsafterthelastobservableeventanddisthecontextswitchawayform
the task. The author explains that utilisation analysis is more appropriate in cases
where the task set conforms exactly to the rate monotonic model. If the deadline is
lessthanorequaltotheperiodEquation55canbeused.
82
Figure 5-14: Four Phases of a Tasks Execution
Ri = Ci + Bi + I i
Equation55:ResponseTime
Where B is the blocking time, C is the computational time, I is the interference. The
authorprovidesequationstocalculatecomputationaldeadlines,periodsandmultiple
iterations. The author specifically assumes no jitter in the test system and therefore
doesnotprovideforitinanyofthecalculations.Howeverin(Burns,1994b)theauthor
discusses message queuing jitter as also discussed by (HerKert, 1996). This led to a
proposedWCRTasinEquation56.HereJmisthequeuingjitterofamessage,wmisthe
worstcasedelayofamessage(duetohigherprioritymessagespreemptingandlower
priority message already on the bus) and Cm is the time taken to physically send the
messageontothebus.
Rtm = J m + wm + Cm
Equation56:ResponseTime(IncludingJitter)
Cm is presented in Equation 57. Here sm denotes the bounded size of messages in

bytes and bit is the bus bit time. The constants and coefficients in equation 57 are
presentedby(Burns,1994b).
34 + 8sm
Cm =
+ 47 + 8sm bit
5
Equation57:CommunicationTime
BmisgivenbyEquation58wherelp(m)isthesetoflowerprioritymessages.
83
Bm = max (ck )
jhp ( m )
Equation58:BlockingDelay
The term wm is presented as in Equation 59 but is rewritten as in Equation 510 to

allowforarecurrencerelationduetotherebeingnosimplemethodofpresentingin
termsofwm.
wm = Bm +
wm + j j + bit

C j
Tj
jhp ( m )
Equation59:QueuingDelay
wmn+1 = Bm +
wmn + j j + bit

C j
jhp ( m )
Tj

Equation510:ReoccurrenceQueuingDelay
Wherehp(m)isthesetofmessageswithahigherprioritythanm,Tjistheperiodof
message j. Bm is the longest time a messages can be delayed by a lower priority
0
messageandisdefinedbyEquation58.Avalueofzerocanbeusedfor wm .Iteration
proceedsuntilEquation511issatisfied
wmn +1 = wmn
Equation511:Convergence
In(Tindell,1994)theauthorpresentstheworstcaseresponsetimeasperEquation5
12.HereCiistheworstcasecomputationtimeofatask,hp(i)isthesetoftaskswitha
higherprioritythantaski.Tjistheminimumtimebetweensuccessivearrivalsoftaskj.
Biisthelongesttimethattaskicouldspendblockedbyalowerprioritytask.
r
ri = Ci + Bi + i C j
jhp ( i ) T
j
Equation512:ResponseTime
84
FortherecurrencerelationEquation513illustratesthis.Again,asinpreviousworks,
zeroisasuitablevalueforri.
rn
ri n+1 = Ci + Bi + i C j
jhp ( i ) T
j
Equation513:RecurrenceResponse
Theauthorincludesjittervaluesintheseequationsandtheassumptionthatpriorities
are unique is made here also.Equation 513 will guarantee convergence if processor
utilisationislessthan100%andthetaskdeadlineislessthantheperiodforsituations
wherethetaskisnotreleasedimmediatelyandisplacedinapriorityorderrunqueue.
Equation514canbeusedwherewiisgivenbyEquation515.
ri = J i + wi
Equation514:UpdatedResponseTime
J j + wi
wi = Ci + Bi +
C j
jhp ( i )
Tj
Equation515:WorseCaseDelay
InEquation515thetermJiistheworstcasedelaybetweenataskarrivingandbeing
released and is termed release jitter. This can be an issue if the worst case time
betweensuccessivereleasesisshorterthantheworstcasetimebetweenarrivals.To
account for a later release of a task being delayed by noncompletion of an earlier
release,thetimespentintherunqueuemustbelessthanthetaskperiod.Applying
thistoEquations514and515resultsinEquations516and517respectively.
ri = max ( J i + wi (q) qTi )

q =0 ,1, 2K
Equation516:UpdatedWCRT
85
J j + wi (q)
wi (q) = (q + 1)Ci +
C j
jhp ( i )
Tj
Equation517:UpdatedDelay
PreviousEquations, 516 and517 areguaranteed to produce aresult ifutilisationis

lessthanorequalto100%.
In (Robert I. Davis, 2007) the authors determine Cm as per Equation 518 where the
maximumbitstuffingisassumed.Heregisavalueof34whichrepresentsthe11bit
identifierformat(itwouldbeavalueof54forthe29bitidentifierformat).Theterm
bitisthetimefor1bitonthebus.
g + 8s m 1
C m = ( g + 8sm + 13 +
) bit
4
Equation518:TransmissionTime
Equation5.18issimplifiedtoEquation5.19.
Cm = (55 + 10sm ) bit
Equation519:SimplifiedTransmissionTime
In(RobertI.Davis,2007),theauthorsassumethatcommunicationisattainedthrough
a CAN bus and that the highest priority message queued at a node is entered into
arbitration.Thesystemisassumedtocontainastaticsetofhardrealtimemessages,
whereeachmessagehasafixedidentifierandhenceauniquepriority.Eachmessage
hasthemaximumnumberofdatabytessmandamaximumtransmissiontimeCm.The
authorsdefinetheresponsetimeofamessageas
Thelongesttimefromtheinitiatingeventoccurringtothemessagebeingreceivedby
thenodesthatrequireit.
Amessageissaidtobeschedulableifitsresponsetimeislessthanitsdeadline.The
systemisthensaidtobeschedulableifallthemessagesinthesystemareschedulable.
The authors use the same response times in their equations as stated previously in
Equations56and512.
86
5.10 DesignProcess
Whendesigninganautomotivesystemoneofthefirsttasksundertakenistodeciding
on the design process required. Two methods available are heuristic and algorithmic
design. Both these methods can provide a suitable solution but there are different
approachesineachmethod.Eachprocesswilltakeacertainamountoftimebeforea
validanswerisextracted.Thedesignerhastodecidewhichsolutionbestoptimisesthe
timetakentodevelop asolution. Someproblemsdonot haveanypossibleutilisable
outputs. Others are only fully solvable using optimised results if an appropriate
method is used in the design approach. These problems are called NP problems and
different classifications of them are explained in the following section. Heuristic and
Geneticalgorithmsarealsodiscussedinthefollowingsection.
5.10.1 NPProblem
TheNPinaNPproblemstandsforNondeterministicPolynomial.Foraproblemtobe
classifiedasNPithastobesolvableinpolynomialtimebyanondeterministicTuring
Machine(Weisstein,2008).AproblemcanalsobeconsideredtobeNPifitssolution
can be guessed and it is deemed nondeterministic because there is no particular
methodtoguessing.ThenondeterministicTuringmachineisacomputationaldevice
andcanbesimulatedinC++orotherlanguages.Ittakesinmanypathsandcomputes
themtoobtainaresult.TostudyaproblemforNPcompletenesstheinputnhastobe
thenumberofbitsrequiredtoencodetheinput.Itisalsoassumedthatcharactersand
numbersintheinputareencodedusingareasonablebinaryencodingschemesothat
each character uses a constant number of bits and each integer M>0 is represented
withatmostclogMbits,foraconstantc>0(MichaelT.Goodrich,2002).
AproblemcanbedeterminedNPcomplete,NPhardandP.AproblemisNPhardifthe
algorithmforsolvingitcanbeeasilyconvertedtosolveanyotherNPproblem.NPhard
meansatleast ashardasany NPproblem(Weisstein,2009).AproblemthatisNP
hardisconsideredtobeNPcomplete.Aproblemmightnothaveanefficientsolving
87
algorithm if it is NP complete. The general bin packing problem is known to be NP

complete(Nossal,1996).EachNPcompleteproblemisasdifficultasanother.Someof
the classical examples are satisfyability, vertex cover, knapsack and travelling
salesperson.
5.10.2 Heuristics
Taking a heuristics design approach involves using experience gained when making
decisions.
Aheuristicapproachcanbetakenduringthedesignprocessthathasmultiplepossible
solutions. The designer thenselects a solution that bestsuits andthen recreatesthe
processtofindanewsetofsolutions.Bycontinuingtheprocessthisconvergestoan
optimal result. This approach does not have a formal method or step approach. This
process is appropriate when searching for an optimal solution and is used for mixed
systems and single structured systems. An example of a mixed system would be
FlexRay or TTCAN where the parameters of either of the system can change (e.g.
timingandsegmentsizes)whichwillgiveadifferentsolutioneachtime(Skiena,1997).
AsinglestructuredsystemisCAN,LINandMOSTtonamebutthreeexamples.
5.10.3 Algorithms
An algorithm is a procedure for solving a problem. Using an algorithmic approach in

the design process follows a set of predefined steps. In this approach there is a
definitive result. The problem to be scheduled would have its characteristics and
parametersdefinedwhichcreatessomerestrictionsinthedesignprocess.
Algorithmdesignprocesscanbesummarisedinthefollowingsteps(Turner,1996)
1. Clarify the problem; Note any assumptions and simplifications. Constantly

restatedtheproblem
88
2. Defineinputs;tosetoutwhatconstitutesallowableinputsandwhatdatatypes
theseare
3. Defineoutputs;Statewhatexpecteddatatypesareandtheirformat
4. Write first pass algorithm solution; this will show up any issues overlooked
and ambiguities of language. Write down the improved version and redo
processasnecessary
5. Implementsolutionincode;hereanyprogrammingtechnicalitieswillshowup.
6. Uponsuccessfulerrorfreecompilationcompareresultswiththoseexpected
7. Comprehensive test process; devise a comprehensive test procedure that
coversasmanypossiblesolutionscenarios
Thealgorithmmethodcanalsobeusedasanoptimisationapproachdependingonthe
rigidnessoftheparameterconstraintsandrepeatedlyreinputtingthesolutionset.
5.10.4 GeneticAlgorithm(GA)
GeneticAlgorithmsuseastochasticandheuristicmethodtogiveamutatedsolution.
Thismutatedsolutionisthenappliedtoafitnessfunctiontogiveanoptimalsolution
set.
GAs (Genetic Algorithms) are easiest explained using the concept of natural genetics
wherebyinthemajorityofcasesonlythestrongest,fittestandsmartestsurvive.This
produces offspring better than the previous generations. GAs have been successfully
appliedtooptimisationproblemslikewirerouting,schedulingadaptivecontrol,game
playing, cognitive modelling, transportation problems, travelling salesman problems,
optimal control problems, database query optimisation etc (Michalewicz, 1996). The
geneticalgorithmitselfdoesnotcontainanyapplicationspecificparameters;theseare
not included until the fitness function is developed. The fitness function results can
thenbefedbackintotheGAforfurtheroptimisationoftheresults.GAsshouldnotbe
purely considered optimisation algorithms. An example of this is in evolution;
sometimes luck is involved in the survival process. Similar to genetic algorithms, an
optimisationsolutionandanonoptimalsolutioncouldbeaccepted.
89
5.11 Conclusion
Thischapterbeginsbydiscussingdistributedarchitecturesandbasicnodedesign.Next
thereisabriefdiscussiononRTOSandtheOSEK/VDXwhichisastandarddeveloped
by European automobile manufacturers. Some scheduling policies used in realtime
embeddedsystemsarepresented.ThehistoryofCPAandsomeassociatedparameters
are introduced. This leads into task graphs which are introduced as a method of
visuallyrepresentingtasksandapplicationdata.FromthetaskgraphsBCET,WCETand
RTAparameterscanbederived.NextthetypeofNPproblemcanbediagnosedtohelp
determinethedesignapproach.TheHeuristicmethod,algorithmicandGAapproaches
to design have been discussed. This chapter gives an overview into the types of
approachesusedinthisresearchandsimilarworkcarriedoutthathasbeenreviewed
duringthecourseofthisresearch.
After review scheduling methods and design processes used by other authors, the
strengthsandweaknessesofeachapproachcanbeassessed.Usingtaskgraphanalysis
allows the application undergoing migration to be assigned into its component sets.
This allows any slack in the system to be redistributed among other tasks in the
application.TaskgraphanalysisisacriticalcomponentintheabstractionofCANand
FlexRayparameters.
Afterexaminingdesignprocessesinsection5.9itisapparentthatnoneofthesewillfit
directlyintomyapplicationtestcases.Onefactorforthisisthatthesedesignprocess
weredesigned for testcases carried out using simulation and not in realtime.Some
aspectsofthedesignprocessescanbeincorporatedintotheapplicationtestcasee.g.
algorithmapproachallowingthestepsinthedesignprocessbedefined.
Thedesignapproachestakenintheautomotiveindustryhavealsobeenusedinother
industry sectors such data networks, telecommunications and industrial computing
(realtimesystems)(VasiliosPasias,2006).
90
5.12 References
ABHIJITDAVARE,Q.Z.,MARCODINATALE,CLAUDIOPINELLO,SRIKANAJAN,ALBERTO
SANGIOVANNIVINCENTELLI(2007)'PeriodOptimisationforHardRealTime
DistributedAutomotiveSystems'DAC2007,SanDiego,Calafornia,USA,ACM
ALOUL,N.K.A.F.(2005)'TheSynthesisofDependableCommunicationNetworksfor
AutomotiveSystems'SAEInternalional2005,
ANDREIHAGIESCU,U.D.B.,SAMARJITCHAKRABORTY,PRAHLADAVARADAN
SAMPATH,P.VIGNESH,V.GANESAN,S.RAMESH(2007)PerformanceAnalysis
ofFlexRaybasedECUNetworks.ACM.
BURNS,A.(1994a)Fixedpriorityschedulingwithdeadlinespriortocompletion
BURNS,K.T.A.A.(1994b)GuaranteeingMessageLatenciesonControlAreaNetwork
(CAN)
BUTTAZZO,E.B.A.G.C.(2004)SchedulabilityAnalysisofPeriodicFixedPriority
Systems.IEEE.
CAREY,J.R.H.M.L.M.J.(1991)EarliestDeadlineSchedulingforRealTimeDatabase
Systems.IEEE.
E.DOUGLASJENSEN,C.D.L.,HIDEYUKITOKUDA(1985)ATimeDrivenScheduling
ModelforRealTimeOperatingSystems.IEEE.
ENGLANDER,I.(2000)TheArchitectureofComputerHardwareandSystemsSoftware,
Wiley.
GORDON,K.L.A.J.(1991)CriticalPathAnalysisandotherprojectnetworktechniques,
TheBathPress.
HERKERT,K.J.L.A.A.(1996)'JitterControlinTimeTriggeredSystems'International
ConferenceonSystemSciences,Hawaii,IEEE
INFORMATIK,V.(2008)SolutionsforOSEK/VDX,20/02/2008
JAKOBENGBLOM,A.E.,FRIEDHELMSTAPPERT(2000)'StructuredTestingofWorst
CaseExecutionTimeAnalysisMethods'WorkinProgresssessionofthe21st
IEEERealTimeSystemsSymposium(RTSS2000),Orlando,Florida,USA,IAR
Systems
JORDAN,V.P.H.A.H.F.(2004)ComputerSystemsDesignandArchitecture,Pearson
PrenticeHall.
LEMIEUX,J.(2001)ProgrammingintheOSEK/VDXEnvironment,CMP.
LOBUR,L.N.A.J.(2003)ComputerOrganizationandArchitecture,JonesandBartlett
Publishers.
LOCKYER,K.G.(1974)AnintroductiontoCriticalPathAnalysis,PitmanPublishing.
LOCKYER,K.G.(1991)Criticalpathanalysisandotherprojectnetworktechniques.,
Pitman.
MICHAELT.GOODRICH,R.T.(2002)AlgorithmDesign,Wiley.
MICHALEWICZ,Z.(1996)GeneticAlgorithms+dataStructures=Evolutionprograms,
Springer.
NATALE,M.D.(2000)'SchedulingtheCANbuswithEarliestDeadlineTechniques'
ProceedingsoftheThe21stIEEERealTimeSystemsSymposium(RTSS00),
91
NOSSAL,R.(1996)PreRuntimePlanningofaReliableRealTimeCommunication
System.InstitutfurTechnischeInformatik,TechnichalUniversityofVienna.
OSEK(2005)OperatingSystemSpecification2.2.3.
OSHANA,R.(2007a)RealTimeOperatingSystemsforDSP.
OSHANA,R.(2007b)RealTimeOperatingSystemsforDSPpart6.DSPDesignLine.
REINHARDWILHELMJE,A.E.,NIKLASHOLSTI,STEPHANTHESING,DAVIDWHALLEY,
GUILLEMBERNAT,CHRISTIANFERDINAND,REINHOLDHECKMANN,TULIKA
MITRA,FRANKMUELLER,ISABELLEPUAUT,PETERPUSCHNER,JAN
STASCHULAT,PERSTENSTROM(2006)'TheWorstCaseExecutionTime
ProblemOverviewofMethodsandSurveyofTools'ACMTransactionson
EmbeddedComputingSystems,
REYNAUD,C.B.(1970)TheCriticalPath,GeorgeGoodwinLimited.
ROBERTI.DAVIS,A.B.,REINDERJ.BRILANDJOHANJ.LUKKIEN(2007)ControllerArea
Network(CAN)SchedulabilityAnalysis:Refuted,RevisitedandRevised.Springer
Science+BusinessMedia.
SCHAFFER,P.N.L.A.J.(2006)ExactlyWhenDoYouNeedRealTime?20/03/2006
SHA,L.,KLEIN,MARKH.,ANDGOODENOUGH,JOHNB(1991)RateMonotonicAnalysis.
SHIN,K.M.Z.A.K.G.(1995)'NonPreemptiveSchedulingofMessagesonController
AreaNetworkforRealTimecontrolApplications'ProceedingsoftheRealTime
TechnologyandApplicationsSymposium(RTAS95),
SKIENA,S.(1997)HowtoDesignAlgorithms.DepartmentofComputerScience
SUNYStonyBrook.
TANENBAUM,A.S.(1996)ComputerNetworks,prenticeHallInc.
TINDELL,K.(1994)HolisticSchedulabilityAnalysisforDistributedHardRealTime
Systems.
TRAIANPOP,P.P.,PETRUELES,ZEBOPENG(2007)'BusAccessOptimisationfor
FlexRaybasedDistributedEmbeddedSystems'EDAA,
TURNER,D.B.A.J.(1996)UnderstandingAlgorithmsandDataStructures,McGrawHill.
VASILIOSPASIAS,D.A.K.A.R.C.P.(2006)'HeuristicAlgorithmsforEfficientWireless
MultimediaNetworkDesign'IEEE,Proceedingsofthe32ndEUROMICRO
ConferenceonSoftwareEngineeringandAdvancedApplications(EUROMICRO
SEAA'06,
VIKRAMADVE,R.S.(2006)CompilerSynthesisofTaskGraphsforParallelProgram
PerformancePrediction,10/03/2008
WEISSTEIN,E.(2008)Mathworld.com,18/02/2008
WEISSTEIN,E.W.(2009)NPProblem,12/01/2009
92
AutomotiveNetworkMigration
6 Automotive Network Migration:
6.1 AutomotiveNetworkMigration
Migration(athardwarelevel,softwarelevelorboth)isachangefromonesystemto
another. Methods of analysing an embedded system at task and message level in
conjunction with developing timing constraints were examined in the previous
chapter.Theimplementationoftheseconstraintsonthechosenprotocoliscriticalto
achieving asuccessful migration. This chapter discusses two approaches to achieving
successful migration; gateways and full conversion methods. Both methods are
discussedwithreferencetopreviousworksbydifferentauthors.
6.2 Introduction
Automotive network migration at the application level, involves changing from one
protocol and successfully executing on a different protocol without compromising
functionalityorpracticality.
When undertaking the migration process key parameters such as timing analysis,
predictability analysis and optimisation procedures were examined in works carried
outby(ShanDing,2005),(Aloul,2005)and(TraianPop,2007).Someofthepotential
methodsforundertakingtheseprocedureswerediscussedinChapter5.
6.3 ProtocolMigrationRequirements
Migrationtoamultiprotocolsystemisrequiredifnosingleprotocolisablemeetthe
designer and manufacturers requirements such as equipment costs, bandwidth
requirements and determinism. If a specific protocol is unable to meet the specified
93
Autom
motiveNetworkMigrration
n alternative protocol allows theese specified requirem

ments to bee
requiremeents but an
met,then
nmigration canalsotaakeplacebetweentheesetwopro
otocols.Intthissecond
d
instanceittisthenetw
workcompo
onentthatiischanged.
In order to
t successfu
ully convertt from one protocol to another there
t
has to
t be somee
commonffunctionalittyinterms oftheprotocol(Lam, 1989)asillu
ustratedin Figure61..
Here node X1 comm
municates with
w node X2
X using protocol X aand similarly node Y1
communiccateswithn
nodeY2usingadifferentprotoco
olY.IfX1n
needstocommunicatee
withY2itisunableduetonocommonfuncctionalityexxisting.
Figuure 6-1: Protocol Common

C
Functioonality
An examp
ple of this common functionalitty is some form of protocol
p
co
onverter ass
illustrated
dinFigure6
62whereC
Cistheconvverter.
Figure 6-2: Convverter between tw

wo
differentt protocols
One reaso
on for a laack of compatibility between
b
prrotocols is the need to
t improvee
functionallity as new protocols replace old
der ones. O
Older protocols are sacrificed forr
superiorq
quality(Lam
m,1989).AnexampleofthisisaLINnetworkbesideaCA
ANnetworkk
asdiscussedinChaptter3.Thisp
placementccoupledwitthdifferentprotocolsb
beingmoree
94
4
efficient at transferring different types of information leads to numerous protocols

potentiallyoperatinginasinglesystem.
When a migration takes place it is insufficient to map a single message from one
protocol to the new protocol. A sequence of events such as tasks in one protocol
shouldbemappedsoastoattainproperflow,nounduetermination,nodeadlock,no
unexpectedreceptionorerrors(ZP.Tao,1992).
Therearetwomethodsfornetworkmigration,theseare;
SidebySideMigration
FullConversion
6.4 SidebySideMigration(UsingaGateway)
Agatewayenablesmigrationofnecessarydataandparametersfromoneprotocolto
another(SukHyunSeol,2006).
Inthesidebysidemethodthereareatleasttwodifferentprotocolsinoperationon
eithersideofagateway.Thegatewayisusedtocarryouttheconversionprocessof
theprotocolsparameters.Agatewaycancarryouttheconversionofmorethanone
protocol.
DatatransfertakesplacethroughanECU.ThisECUiscalledagatewayasillustratedin
Figure 63. Communication occurs in a single direction or in both directions as
illustratedinFigure63.
Figure 6-3: Example Gateway Usage
95
6.4.1 Gateways
A gateway allows separate protocols to engage with each other. This enables the
transferofdatabetweendifferentnetworks.Duetothevarietyofnetworksavailable
whendevelopingagatewaythesystemdesignermustconsiderthefollowingquestions
(Smith,2005)
Whatapplicationswillbeused?
Whichnetworksneedtobebridged?
Whatisthebridgetopology?
IsDMA(DirectMemoryAccess)required?
Whatsizeshouldthedatabuffersbe?
Whatbusshouldbeusedforinternaltransfer?
Howwideshouldthisbe?
Whatarbitrationmechanismshouldbeemployed?
Howmuchprocessingpowerisrequired?
Thequestion,Whichnetworksneedtobebridged?isacomplexquestioninitsown
right. To take the example of CAN and FlexRay (as per Figure 63) they both have
different payloads; CAN 8 bytes max, FlexRay 254 bytes max, thereby requiring a
gateway able to handle both these payload ranges. The CAN data would need to be
buffered up to a larger data rate but this would lead to jittering delays while the
informationisbeingbufferedsotherearetradeoffstobeconsidered.
Ideally the processors primary objective is to keep processing; the DMA feature can
accordinglybeincluded.DMAcandealwithdatatransfersbetweenthegatewayand
memoryinterfacesleavingtheprocessortodealwithprocessingduties.
The AUTOSAR (Automotive Open Systems Architecture) partnership consisting of
leading OEMs (Original Equipment Manufacturers) and tier one suppliers defines a
gatewaystructure(AUTOSAR,2007).
96
6.4.2 AUTOSARGatewayStructure
AUTOSAR defines the basic gateway structure as illustrated in Figure 64. The upper
layercontainsthecommunicationparametersfortheexchangeofdatabetweenECUs.
The lower layer contains the interfaces and the drivers for the protocols. A router
connects theupper layer and lower layer, and communication(COM) is containedin
theupperlayer.COMisamethodforexchangingdatabetweendifferenttasksonan
ECUoronmultipleECUs(Jackman,2007).
Figure 6-4: AUTOSAR Gateway Structure
Usingthesidebysidemigrationexample,thecharacteristicsofthefirstprotocolare
maintaineduntilsuchtimeastheconversiontakesplace.Thefeaturesofthesecond
protocol cannot be utilised until after the conversion has taken place. For example
using a gateway to convert from CAN to FlexRay (as illustrated in Figure 63), some
features of CAN (e.g. being a pure eventtriggered system) and some features of
FlexRay(e.g.determinismanddualchannels),areunablebeusedonbothprotocols.
BecauseCANisamatureprotocolincomparisontoFlexRayautomotivemanufacturers
might prefer to work with CAN as much as possible (if previous developments using
theCANprotocolwereundertaken),andswitchtoFlexRaywhendeemedcompletely
necessarytotakeadvantageofsomeofitspropertiesasdiscussedinChapter4.In(A.
Albert,2003)agatewayisusedtoconvertreceivedCANdatatoaTTCANnetworkfor
useinavehicledynamicmanagementsystemwhichcontained;anelectronicstability
97
program, active front steering and an electronic active roll stabiliser. Off the shelf
gateways can be purchased from companies such as NEC (GmbH, 2007) and TZM
(Mikroelektronik,2008)tonamebuttwo.
Examplesofdifferentfunctionalgatewaysare;invehicle,intervehicleandvehicleto
infrastructure communication. Examples of each of the above are infotainment
systems, live traffic and travel information and remote diagnostics for more efficient
breakdownassistance(GuidoGelen,2006).
Specific migration issues involved in migration of the FlexRay protocol data and
parameterstotheCANprotocolareillustratedinFigure65.
98
6.4.3 FlexRaytoCANMigration
Figure 6-5: Flow Chart Converting FlexRay to CAN (Suk-Hyun Seol, 2006)
In this section issues such as extracting necessary data for the FlexRay protocol and
configurationforthecorrecttransmissionintheCANprotocolareexamined.
FromFigure65(SukHyunSeol,2006)messagetransferstartswhenthefirstmessage
buffer is full until the data is transferred to memory. Then the data length, ID and
payloadareextractedfromthemessageframe.SubsequentlytheIDfieldisconverted
from a FlexRay 12 bit field to a CAN 29 bit ID field. The data length is then split in
lengthsof8bytesegments.AfterthattheID,datalengthandpayloaddataarecopied
tothehostsmessagebuffersfromthequeue.Eachtimeamessageistakenfromthe
queue a counter is decremented and any time a message is put into the queue the
99
counter is incremented. Finally the message frames are transmitted on the CAN bus
(SukHyunSeol,2006).
The above format deals with converting from a TT protocol to an ET protocol. Other
research has dealt with converting different TT protocols. (Shehryar Shaheen, 2006)
developed a gateway for TT control networks. These included FlexRay, Byteflight,
TTP/CandTTCAN.Inthisapproachthepacketroutingarchitectureandmessagequeue
format were abstracted from conventional gateway design methods. Other issues
were encountered that would not occur on general data communications networks
such as timely reliable delivery of all message frames across the gateway (Shehryar
Shaheen, 2006). This is due to the different network characteristics of a TT network
fromanETnetwork.
6.5 FullMigration
Thefullconversionmethodimpliescompletemigrationfromoneprotocoltothenew
protocol.Forafullconversiontobedeemedsuccessful,allnecessaryparametersthat
were fulfilled in the old system need to be at least met if not improved in the new
system. For example, it would not make sense to have safety critical applications on
the CAN network when they were previously on the FlexRay network, if the
characteristics of the FlexRay protocol were critical to successful implementation of
theapplication.
6.5.1 MigrationtoaTT(TimeTriggered)Protocol
Many authors have researched the area of migrating to a TT protocol including

(Kanchi,2007),(WeiZheng,2005),(Aloul,2005),(AndreiHagiescu,2007),(TraianPop,
2007).
Some protocols are easier to migrate to a TT system than others. One such case is
where the initial protocol and the new protocol contain common properties. An
100
example of this case is a migrating from TTCAN to FlexRay. Both of these protocols
contain TT and ET properties. Migrating from an ET system to a TT system requires
moreplanning(thanfromTTtoET)becauseascheduletableneedstobedeveloped
prior to runtime. This is achieved in (Suri, 2004) where the authors use the TTP/C
protocol as a base and sporadic data transfer is included in the modified frame
structure. Migration is accomplished through the development of a Sporadic
Information Transfer (SIT) bit in the frame header file. This SIT bit can either send
sporadicdataorrequestadditionalslotstotransmitsporadicdata.Smallamountsof
sporadicdataaretransmittedintheSITsectionofthe framebutiflargeamountsof
sporadicdataarerequiredtheywillbesentintherequestedadditionalslots.
6.5.2 MigrationtoanET(EventTriggered)Protocol
One of the more difficult systems to migrate is a TT protocol system onto an ET

protocol system. There is no guarantee that deadlines will be met due to the
characteristicsofbothdomains.
It is not enough to just make sure deadlines from one protocol are met in the new
protocol.Maximumutilisationoftheframeisanothercriticalobjectiveinachievinga
successful migration. In the above example since the payloads of both protocols are
knownitispossibletodeterminethatoneTTCANframeof8bytes(maxsize)willfitin
a FlexRay frame of 127 twoword bytes (maximum size). If more than one TTCAN
frameisaccommodatedintheFlexRayframe,bandwidthutilisationisincreased.The
majorstumblingblocktodoingthisisoptimisingtheframesizes.Thisisachievedusing
optimisationandbestfitalgorithmsasdiscussedin(AbhijitDavare,2007)and(Traian
Pop,2003)aspresentedinChapter5.
In (Andrei Hagiescu, 2007) the authors migrate to the DYN (dynamic) domain in the
FlexRaynetwork.Theauthorscommencebydeclaringthattheworstcaseendtoend
delayvaluesaremoreappropriatetocalculate.Thisisduetothepossibilitythatasa
signalpropagatesthroughasystemitwillpossiblygetmodifiedbyschedulingpolicies
itencountersinthesystem.Anexampleofthisisamessageoriginatingfromasensor
passingovermultipleECUsandactivatinganactuator.Theauthorstakeaframework
101
by(S.Chakraborty,2003)andmodifyittomodeltheFlexRayprotocol.MultipleECUs
are modelled on the FlexRay bus with application tasks mapped onto the ECUs. The
worstcase length of specified tasks is a constant. The framework developed allows
DYNmessagesbetransmittedovertwocyclesallowingmessageslargerthantheDYN
domaintobetransmitted.
6.5.3 MigrationtoaMixedSystem
WhenmigratingfromanETorTTsystemtoamixedsystemthedesignerdetermines
where each segment domain transfers to in the new protocol. This could involve a
directtransfertoitsequivalentdomain(staticordynamic)inthemixedsystemorto
thealternativedomaininthemixedsystem(staticordynamic).Earlierworkhasbeen
carriedoutmigratingtoamixedsystembutthedesignerdoesnotfullyutilisebothTT
and ET aspects of these systems. (Shan Ding, 2005) and (Cummings, 2008) are
examplesofthisasexplainedinsections6.5.4and6.5.5respectively.
6.5.4 GA(GeneticAlgorithm)Approach
In (Ding Shan, 2005) the author restricts migration to only the static segment of a
mixed system protocol using a GA static scheduling method. (Shan Ding, 2005)
presents an application representing a set of task graphs Gi containing tasks Ti and
edgesconnectingthetasksEi.Eachnodecontainsknownworstcaseexecutiontimes
Ci,periodsTiandadeadlineDi.Theauthorusestheconstraints;ResponseTime(RT),
Freshness Time (FT), Maximum Response, Maximum Freshness Time, Response and
Freshness Constraint, Input and Output Constraint and Slot Redundancy to develop
anindividualalgorithm.ThisindividualalgorithmispresentedinFigure66.
102
Figure 6-6: Algorithm for generating an individual (Shan Ding, 2005)
Theresultsobtainedareoptimisedbyselectingroutesaccordingtotheirfitnessthen
applyingcrossoverandmutation.
(Nossal,1996)alsopresentsaGAthatgeneratesastaticscheduleforbusaccesstothe
TTP(TimeTriggeredProtocol).TheGAincludesafitnessfunction.Theauthorpresents
the planning method (heuristic based GA) in developing an algorithm that is then
applied to the chosen TDMA protocol. Below is a list of constraints from the
communicationsystemthatarenecessaryfortheplanningalgorithmtocomplete.Two
requirementstobefulfilledarerequirementsbytheapplicationandrequirementsby
the protocol. The message size is calculated in Equation 61 and the maximum
message size is calculated from Equation 62. Where M is the bus message, i is the
node,jistheTDMAcycle,sdisthesizeinbitsanddisthedataelement.
2
ms ij = s d [bit ]
d M ij
Equation61:Usedmessagesizeofnodei
MSi = max{msij }[bit ]

1 j C
Equation62:Maximummessagesizeofnodei
103
TheoptimumperiodiscalculatedfromEquation63whereodistheoptimumperiod,
rn is the receiving node and l is the maximum latency from the sending node to the
receiving node. RNd is the receiving nodes communication latencies, rprn is the
smallestperiodofanytaskreceivingdataelementdatnodern.
od =
}}
min
l min p d , rp rn
( rn, l ) RN d
Equation63:Dataelementoptimumperiod
Nextthefitnessfunctionisappliedtocheckthevalidityoftheschedule.Anoptimum
ratio of 1 (actual period and maximum period) is desirable. A ratio greater than 1
should be avoided as it violates the applications temporal requirements such as
scheduledperiodslargerthanthemaximumperiod.Aratiolessthan1meansthedata
element is transmitted more often than required and therefore would constitute a
wasteofbandwidth.
TheoverallfitnessfunctionisdefinedbyEquation64.Foracompletederivationsee
(Nossal,1996),whereDisthenumberofdataelements.
F=
D
d =1
f(
a d *tTDMA
pd
Equation64:OverallFitness
Both of these GA scheduling methods do not take account of scheduling aperiodic

signals.Thiswillleadtounderutilisationofthebandwidthinaprotocolthatcontains
TTandETdomains.
104
6.5.5 OtherApproaches
OtherapproachespreviouslytakenarediscussedinthissectionsuchastheHeuristic
design method and other developer specific paradigms. There is a commonality
between them in that all methods develop schedulability analysis and optimisation
techniques.In(TraianPop,2002),(TraianPop,2003),(TraianPop,2006),(TraianPop,
2007),(JanCarlson,2003)theauthorstaketheheuristicapproach.
(Aloul,2005)synthesiseseachapplicationtasktoascheduledmessagelevelusingonly
a TDMA protocol. Task graphs are used to develop message clustering once the
parameterssuchasdeadlinedi,releasetimeri,executiontimeciandtaskTiareknown.
Slack is calculated and distributed among the tasks to obtain a worstcase response
timeforeachtaskwi.Amessagedelaydelay(mi)iscalculatedaspresentedinEquation
53 in Chapter 5. Once the bandwidth is known a slot size can be calculated from
Equation65.
slot = min{size(mi )}/ B speed

s
j
i
Equation65:SlotDuration
An algorithm is then developed to first synthesise (Figure 67) the network topology
and then to cluster the network topology. A message period equal to a harmonic
multiple is required to enable scheduling of multiple task graphs with different
periods.
105
Figure 6-7: Network Topology Synthesis Algorithm (Aloul, 2005)
Transmission slot reuse is applied to increase bandwidth utilisation. This is achieved

throughEquations66and67.
period (mnew )
nreuse = ni
.ni
mi
mi arrival ( mi )
Equation66:SlotReuse
size(mnew )
speed
nreuse
B j . slot
Equation67:mnewtransmissionslotportionwithinperiod(mnew)
Howeverin(Aloul,2005)nomentionismadeofusinganETprotocolormixedsystem
whichincreasesbandwidthutilisationwhencomparetopureTTsystems(asdiscussed
inChapter2).
In (Traian Pop, 2002) the authors develop a design heuristic algorithm for mixed
time/eventtriggereddistributedembeddedsystemsaspresentedinFigure68.
106
Figure 6-8: Design Heuristic (Traian Pop, 2002)
Thisdesignheuristicinvolvesthreeprimarysteps;
Buildinitialconfiguration
Mappingandpartitioning
Buscycleoptimisation
In (Traian Pop, 2006) the authors build on their previous work to specify
implementationontheFlexRayprotocol.Theapplicationmodelwasdevelopedusing
acyclic task graphs and timing analysis was performed on the ST (static) and DYN
(dynamic)segments.TheschedulabilityalgorithmsarepresentedinFigure69.
Figure 6-9: TT and DYN Schedulability Algorithms (Traian Pop, 2006)
107
Havingpriorknowledgeofthescheduledtasksisrequiredtocarryout schedulability
analysis of the TT domain. This means a scheduling table can be set up. The DYN
domain analysis is carried out by determining the worst case response time (WCRT).
Thisincludestakingintoaccountthetransmissiondelaycausedbythetransmissionof
higherprioritytasks.BlockingbytheSTdomainalsohastobeconsidered.Thisworkis
improved on in (Traian Pop, 2007) where the authors propose a FlexRay bus
configuration for a specific application. An algorithm is developed to optimise bus
accessontheFlexRaynetworkasisillustratedinFigure610.
Figure 6-10: Optimised Bus Configuration Algorithm (Traian Pop, 2007)
While there are proposed techniques for looking at ET (dynamic) protocols such as
CAN, these techniques are not applicable when considering the dynamic segment of
the FlexRay protocol. (Valenzano, 2004) examines the Byteflight protocol but
implements a quasiTDMA transmission scheme to guarantee message transmission.
This is not fully compatible to the ET nature of the dynamic segments in FlexRay.
Another technique as proposed in (Oshana, 2007) involves making the dynamic
segmentasbigasthelargestdynamicmessagetorun.Thiswillguaranteealldynamic
messages get transmitted but it is an inefficient method if the DYN messages have
differentperiods.Forexampleifthereare10messagestorunand9haveperiodsof
1msandonemessagehasaperiodof4ms.Thisresultsinthedynamicsegmentof4ms
being required. The predominant DYN message size being transmitted (90% of the
time)isa1msmessage.Thisresultsinaninefficientallocationofbandwidth.
In(WeiZheng,2005)theauthorsfocusonTTscheduling.Theauthorsusetwometrics
toobtainthedesigngoalinschedulinghardrealtimedistributedembeddedsystems.
108
Theseareextensibilityandscalability.Theprincipleoforthogonalisationisusedwhere
afunctionaldescriptionisfirstappliedandthenfunctionalcomponentsaremappedto
architectural components. The system is represented by direct acyclic graphs. Task
parameters are consistent with other methods examined previously in this chapter
suchasWCET,ReleaseTime,Deadline,Period,StartTime,andFinishTimeetc.These
constraints were then used to develop feasibility constraints. The schedule is
consideredfeasibleifitsatisfiesconstraintsimposedbythearchitecture(WeiZheng,
2005). The inclusion of scalability and extensibility metrics allows limited design
changeswithoutmodifyingtheexistingschedule.Thisisachievedthroughaddingslack
into the system. The system cost function is then compared to another optimisation
techniqueofminimisingtheendtoenddelay,whichisthenprovedsuccessfulunder
testedconditions.
In (Traian Pop, 2006) the authors propose methods for scheduling a FlexRay
communicationprotocol.FortheSTsegmenttheSCS(StaticCyclicScheduling)andthe
FPS(FixedPriorityScheduling)approachisused,FPSisalsousedintheDYNsegment.
TheauthoriterativelybuildsupascheduledtableforSCStasks.Thisleadstheauthor
todeveloptheschedulingalgorithmpresentedinFigure611.Theauthorsdevelopthe
DYN segment separately based on the RTA principle discussed in Chapter 5. A
maximumworstcaseresponsetimeiscalculatedusingEquation68.
Rm(t ) = m + wm (t ) + Cm
Equation68:DYNWorseCaseResponseTime
WhereRmisworstcaseresponsetime,misthelongestdelaysufferedduringonebus
cycleifamessageisgeneratedbysendertaskjustafteritsslothaspassed,wmisthe
worst case delay caused by transmission of ST messages and higher priority DYN
messagesandCmisthecommunicationtimeontheparticularbus.
Each equation segment (m, wm and Cm) is further analysed to accurately determine
anyissuesthatcouldarisetodelayamessagesresponse.
109
Equation69showsmasafunctionoftheSTsegmentthemessagesframeidentifier
andgdMinislotminusthetotalbuslength.
m = Tbus (STbus + FramIDm .gdMinislot)

Equation69:Worsecasedelaym
Figure 6-11: Global Scheduling Algorithm (Traian Pop, 2006)
Equation 610 illustrates the communication time Cm, where Frame_size(m) is the
messageframesizeandbus_speedistheoperatingbandwidthspeed
Cm =
Frame _ size ( m )
bus _ speed
wm is the maximum amount of delay on the bus from ST messages, higher priority
messages hp(m), lower frame identifier messages lf(m) and unused DYN slots with
frameidentifierslowerthanthosecurrentlysending,whichequalsoneminislotms(m).
FrameID(m) reuse is not part of the FlexRay specifications but is considered by the
authorsinanalysingtheDYNsegment.
Developing these equations (68, 69 and 610) further an optimal solution for
BusCycles(m)isobtainedusinganILP.Theauthorsdeterminetheworstcasedelayfor
110
BusCyclesm(t), produced by lf(m,t) and ms(m,t), adding up to the delay produced by

messagesinhp(m,t).
In(Cummings,2008)theauthorpresentsasampleCANnetworkanddescribeshowit
is transitioned over to the FlexRay network. The primary criticisms of FlexRay by the
authorareinrelationtoitscostandcomplexity.InthesampleCANnetworkpresented
thestandard11bitidentifierischosen.Thebusrateof500Kbit/sisalsoapplied.The
authorpresentsatableofdataasillustratedinTable61.
Table 6-1: Example CAN Network
Number Frames Average Bus

of
Per
Frames
Second
Payload Time
Per
Second
500
8.0
262ms
200
7.0
145.2ms
100
6.7
165.9ms
50
7.1
97.6ms
20
5.4
25.4ms
ThisexampleCANnetworkhadabusloadcalculatedat75%.Addingtwomoreframes
at2msperiodsincreasesbusloadbeyondwhatisavailable.Theauthordeducesthatit
ismorecostbeneficialtoimplementFlexRaythanoperatetwoCANnetworkswitha
gatewayinbetween.TheFlexRaynetworkissetuptophysicallycompareascloseas
possibletotheCANconfiguration.TheFlexRayconfigurationparametersare;
111
Asinglechannelat10Mbit/s
2StaticFrames
Payloadof2Bytes
125DynamicFrames
1000sCycleTime
Two static frames are included as FlexRay requires two synchronisation frames for
startup.Thedesignerprovidesmoredynamicframesthanisrequired.The1mscycle
timeischosenbecausepreviousCANratesweremultiplesof1ms.
TheauthorconcludesthatimplementingthissetupallowscontinueduseofsomeCAN
design practices but comes at a cost of deferring redundancy and determinism.
FlexRays performance is improved over CAN and there is further room for
improvement through the possibility of increasing the frequency at which the DYN
framesaretransmitted.
6.6 Conclusion
Thischapterstartsbypresentinganintroductiontoautomotivenetworkmigrationand
some of the basic requirements. Following this section a discussion of sidebyside
migration methods (gateways) and examples are given of other works carried out in
thisareaareoffered.Thenextpartdiscussesfullconversionmethods.Thisisbroken
down into migrations to TT protocols, ET protocols and mixed systems. Then the
genetic algorithm approach is discussed with examples of implementations by other
authors.Thechapterconcludeswithadiscussionofothermethodsandtheoutcomes
obtained. All previous works are backed up by methods and results to verify the
findings.
Thischaptergoessomewaytowardsansweringresearchquestionnumbertwo.Thisis
achieved by presenting cases where some authors have implemented gateways to
enable the operation of CAN, where FlexRay was initially used. Other cases are
presented where systems are completely specified to operate on a single protocol
112
only.Duetotheircharacteristicssomeprotocolsaremorestraightforwardtoconvert
thanothers.Numerousauthorshavecarriedoutpreviousworkonprotocolmigration.
Each authors implementation techniques differ but some works contain similarities.
Allapproachesdeliveredvalidresults.
113
6.7 References
A.ALBERT,R.S.,A.TRACHTLER(2003)'MigrationfromCANtoTTCANforaDistributed
ControlSystem'9thinternationalCANConference,Munich,
ABHIJITDAVARE,Q.Z.,MARCODINATALE,CLAUDIOPINELLO,SRIKANAJAN,ALBERTO
SANGIOVANNIVINCENTELLI(2007)'PeriodOptimisationforHardRealTime
DistributedAutomotiveSystems'DAC2007,SanDiego,Calafornia,USA,ACM
ANDREIHAGIESCU,U.D.B.,SAMARJITCHAKRABORTY,PRAHLADAVARADAN
SAMPATH,P.VIGNESH,V.GANESAN,S.RAMESH(2007)PerformanceAnalysis
ofFlexRaybasedECUNetworks.ACM.
AUTOSAR(2007)AUTOSARSpecification.AUTOSAR.
CUMMINGS,R.(2008)'EasingtheTransitionofSystemDesignsfromCANtoFlexRay'
SAEInternational,Detroit,
DINGSHAN,M.N.,TOMIYAMA,HIROYUKI,TAKADA,HIROAKI(2005)AGABased
SchedulingMethodforFlexRaySystems.5thACMinternationalconferenceon
EmbeddedsoftwareEMSOFT'05.JerseyCity,NJ,USA.
GMBH,N.E.E.(2007)FlexRaySolutionsbyNECElectronics,11/03/2008
GUIDOGELEN,E.W.,SVENLUKAS,CARLHERBERTROKITANSKY,BERNHARDWALKE.
(2006)ArchitectureofaVehicleCommunicationGatewayforMedia
IndependentHandover.
JACKMAN,W.Z.A.B.(2007)'UsingSimulationforDesigningInVehicleNetwork
Gateways'SAEInternational,Detroit,
JANCARLSON,T.L.A.G.F.(2003)'EnhancingTimeTriggeredSchedulingwithValue
BasedOverloadHandlingandTaskMigration'SixthInternationalSymposiumon
ObjectOrientedRealTimeDistributedComputing(ISORC'03),IEEE
KANCHI,J.R.P.A.S.(2007)AnOptimizedRealTimeDistributedControlSystem
SchedulerforTDMABasedProtocols.
LAM,K.L.C.A.S.S.(1989)DerivingaProtocolConverter:aTopDownMethod.ACM.
MIKROELEKTRONIK,T.(2008)FlexRayProducts,11/03/2008
NOSSAL,R.(1996)PreRuntimePlanningofaReliableRealTimeCommunication
System.InstitutfurTechnischeInformatik,TechnichalUniversityofVienna.
OSHANA,R.(2007)RealTimeOperatingSystemsforDSP,part8,13/02/2008
S.CHAKRABORTY,S.K.A.L.T.(2003)AGeneralFrameworkforAnalysisngSystem
PropertiesinPlatformBasedEmbeddedSystems.
SHANDING,N.M.,HIROYUKITOMIYAMAANDHIROAKITAKADA(2005)'AGABased
SchedulingMethodforFlexRaySystems'Proceedingsofthe5thACM
internationalconferenceonEmbeddedsoftware,JerseyCity,NJ,USA,
SHEHRYARSHAHEEN,D.H.A.G.L.B.(2006)Agatewayfortimetriggeredcontrol
networks.ScienceDirect.
SMITH,P.(2005)Automotivegatewaysspearheadincarnetworkintegration.
AutomotiveDesignLine.
114
SUKHYUNSEOL,S.W.L.,SUNGHOHWANGANDJAEWOOKJEON(2006)
'DevelopmentofNetworkGatewayBetweenCANandFlexRayProtocolsfor
ECUEmbeddedSystems'SICEICASEInternationalJointConference2006,
Bexco,Busan,Korea,
SURI,V.C.A.N.(2004)'TTET:EventTriggeredChannelsonaTimeTriggeredBase'
NinthIEEEInternationalConferenceonEngineeringComplexComputer
SystemsNavigatingComplexityintheeEngineeringAge,
TRAIANPOP,P.E.,ZEBOPENG(2002)HolisticSchedulingandAnalysisofMixed
Time/EventTriggeredDistributedEmbeddedSystems.
TRAIANPOP,P.E.,ZEBOPENG(2003)DesignOptimizationofMixedTime/Event
TriggeredDistributedEmbeddedSystems.ACM.
TRAIANPOP,P.P.,PETRUELES,ZEBOPENG(2007)'BusAccessOptimisationfor
FlexRaybasedDistributedEmbeddedSystems'EDAA,
TRAIANPOP,P.P.,PETRUELSES,ZEBOPENG,ALEXANDRUANDREI(2006)Timinig
AnalysisoftheFlexRayCommunicationProtocol
VALENZANO,G.C.A.A.(2004)PerformanceAnalysisofByteflightNetworks.IEEE.
WEIZHENG,J.C.,CLAIDIOPINELLO,SRIKANAJAN,ALBERTOSANGIOVANNI
VINCENTELLI(2005)ExtensibleandScalableTimeTriggeredScheduling.IEEE.
ZP.TAO,M.G.(1992)SynthesizingCommunicationProtocolConverter:AModeland
Method.ACM.ACM.
115
LiteratureReviewConclusion
7 Literature Review Conclusion
7.1 Conclusion
Modernautomobilescontainaneverincreasingnumberofelectroniccomponentsdue
anincreasingnumberofcriticalandnoncriticalapplications.Theincreasednumberof
theseapplicationsisdrivenbyconsumersdesiresfor morecomfortapplicationsand
also improvements in the development of safety applications. It is apparent that no
singleprotocolwillmeetalltherequirementsofallapplications.Thisisevidentbythe
widevarietyofprotocolswithdifferingfeaturessuchas;varyingbandwidth,different
costsandlevelsofcomplexitiesattheprotocolnetworklayer.
Networkshaveproventheiruseandeffectivenesseitheronasmallscaleorlargescale,
notonlyintheautomotiveindustrybutinanyindustrywherecommunicationiscritical
foroperation.
By implementing a chosen protocol the characteristics of the network that operates

thatprotocolaredefined.TherearefourpredominantautomotiveprotocolsCAN,LIN,
MOSTandFlexRay.Eachofthesehastheirownmeritsofuseintheirrequiredsetting.
CAN is used for BCU (Body Control Unit) applications, LIN is used in noncritical BCU
applications but has lower cost and speed than CAN. MOST is used for infotainment
purposesinanautomobileandFlexRayisplannedforuseinhighspeedsafetycritical
applications.
FlexRayhasanadvantageoverotherexistingprotocolsinthatitutilisesbothETandTT
characteristics and has greater bandwidth. Primarily due to cost factors, FlexRay will
not be the only network in an automobile; this leads to the existence of multiple
networksinastructure.Toenableapplicationscurrentlyexecutingonolderprotocols
to take advantage of FlexRays features, migration to FlexRay will be required.
116
Completemigrationmaybenecessaryiftheolderprotocoldoesnothavethefeatures
tosuccessfullyimplementanapplication.Ifcompletemigrationisnotnecessarythena
gateway(as discussed in Chapter 6) could be aviable solution to working with more
thanoneprotocol.
Therearemanyapproachesthatcanbeundertakenduringthemigrationprocess.The
two process discussed (Algorithmic and Heuristic) offer suitable solutions for most
cases. The method chosen will depend on a number of factors such as system
parameters, the application requirements, available hardware and software. To
efficiently migrate from one network protocol to another the application is firstly
analysed at task level and modelled in a task graph. Each task is then synthesised at
message level. An optimal frame size can be found from a combination of; the
messages release time, deadline time, WCET, slot size and slot delay as explained in
Chapter5.
As discussed previously in Chapter 6 most of the work previously available by other

authorsfocusesonimplementingtheETprotocolinthestaticsegmentoftheFlexRay
frame. This results in scheduled messages meeting their deadlines but bandwidth
utilisation is not optimised. To improve bandwidth utilisation in FlexRay, use of the
DYN(ET)domainisrequired.
If each task schedule is configured in advance, it is this feature that makes time
triggered networks deterministic and predictable but if the networks schedule is not
set up but activated on the occurrence of an event this is called an eventtriggered
network.Whenchoosingthetypeofnetworkinanautomobiletherearesomefactors
thatneedtobetakenintoconsiderationsuchaswhatapplicationsshallbeexecuted.
For example powertrain or air conditioning systems. If powertrain data is being
transmitted on the network a FlexRay based protocol would be one possible option,
but if it is the air conditioning system that runs on the network then maybe the LIN
protocolmaybemoresuitable.Itisalsopossibletoexecutemorethanoneprotocol
117
onthenetwork;aspertheabovecasewecouldhavebothnetworksrunningonthe
onevehicle.Thishasbeenachievedonmodernvehiclesusinggateways.
Withsoftwarebecomingincreasinglypredominantinthedevelopmentprocesswithin
the automotive industry choosing the right network for the correct application is a
major factor in cost. The worldwide value creation in automotive electric/electronics
(including software) amounts to an estimated 127 billion in 2002 and an expected
316 billion in 2015 according to a Mercer study (Alexander Pretschner, 2007).
Software will make up an estimated 40 percent of this value creation by 2010
(AlexanderPretschner,2007).
118
7.2 References
ALEXANDERPRETSCHNER,M.B.,INGOLFH.KRGER,THOMASSTAUNER(2007)
'SoftwareEngineeringforAutomotiveSystems:ARoadmap'FutureofSoftware
Engineering(FOSE'07),
119
SectionIIIFramework
Development
MigrationFrameworkRequirements
8 Migration Framework Requirements:
8.1 Introduction
Chapter 6 describes methods other authors have used when scheduling various
protocolsonembeddedsystems.Inthischapterthefullmigrationmethodischosen.
Thisisduetoitbeingdeemedthemostsuitablealternativetotheuseofagateway.
The chosen migration method reduces the complexity of multiple protocols by
employing a single protocol system. This chapter presents the process by which the
migrationframeworkwasdeveloped.InChapter9themigrationprocedurethatdeals
with the actual migration steps undertaken are presented. The framework was
developed through logical procedural steps that allows for a variety of CAN
configurations to be processed once a set of basic parameters are obtained and
defined.ThemigrationframeworkisstartedbydefiningtheCANapplicationthatwill
undergo the migration procedure. The migration procedure is summarised and
graphicallyrepresentedinFigure81.
8.2 MigrationRequirements
Byundertakingthismigrationproceduretheconfigurationoftasksisnotaffected.This
isbecausethismigrationprocedureisappliedtothemessagesofeachtaskclusteror
application.TasksarenotrequiredtobereassignedtodifferentECUsatanystageof
themigrationprocedure,butcanbedonesotoreducetheamountofdatatransferred
on the network. The physical layer of the original system (CAN) is replaced with the
physical layer of the migrated system (FlexRay). From the CAN system, the CAN
controller is substituted with a FlexRay driver. The FlexRay driver requires a
communications controller (CC). The CC can be integrated into the MCU. A FlexRay
physical layer interface is required to meet the FlexRay standard physical layer
121
MiggrationFramew
workReequirem
ments
interface specification. The communicaations stacck or COMMSTACK links thee

applicationtotheFle
exRaycomm
municationscontroller.
Figu
ure 8-1: Framework Development Stages
8.3 App
plicationD
Definition
ObtaintheeCANappliicationthattwillbeuseedtounderrgothemigrationprocedure.Thiss
is the app
plication from which the migrattion will prroceed from
m and also
o the exactt
applicationthatistobeimpleme
entedinFleexRay.
122
2
8.4 CANParameterAbstraction
Extracting the parameters from the CAN application is required so the critical
propertiesof the CANapplication are integrated intothe FlexRayparameters. This is
donebyrepresentingtheapplicationintaskgraphformatandanalysingitsproperties
suchasthosepresentedin8.4.2.
8.4.1 CANGraphAbstraction
The migration framework can be undertaken on the premise that the CAN
configuration is already setup and operational. Once this condition is met the CAN
applicationneedstoberepresentedintaskgraphformat.Thisisdonebyabstracting
each process, whether it is functional or computational, as an activity on the task
graph. The activities are placed on the task graph in an order that meets the
precedence constraint requirements. Activities are linked to each other by an arrow,
withthearrowheadindicatingtheprogressionflowthroughthetaskgraph.
8.4.2 CANAnalysis
TheCANsystemisrepresentedintaskgraph format,the nextstepistoabstractthe

initial CAN parameters. The set of CAN components are all directly derived from the
taskgraphandarelistedbelow;
Taskgraphrelease(start)timeri
Taskgraphdeadline(end)timeDi
WorstCaseExecutionTime(WCET)
Taskperiod
The releasetime ri will have an initial value of zero as this is the release time of the
firsttask.ThedeadlinetimeDiwillbeavalueatwhichalltasksinthetaskgraphhave
123
completed execution. The WCET value can vary depending on hardware (CAN
controller)andsoftwareconstraints(Jitter).Thisvaluecanbeobtainedbymeansofa
specialistapplicationthatextractstheWCETofeachmessage.Thisvaluecanalsobe
calculated(usingEquation56)ifnecessaryparametersareknown.Theseparameters
arethejitterjm,queuingdelay/interferencewmandcommunicationtimeCm.Thefinal
parameter for definition before migration can commence is the CAN message set
MCAN,anditsassociatedparametersCANmiandwi.Theseparametersareexplainedin
section9.8.
8.5 Migration
Thebasicparametersaredefined,themigrationprocedure(asperChapter9)canbe
undertaken.TheresultingFlexRayparametersMFRandFRcompsetwillbeeitheridealfor
implementationorasclosetoidealasispossibleduetootherconstraintcomplexities
mentioned.Suchisthecomplexityandvolumeofparametersforconfiguration,there
aresomeparameterswhosevaluesinterconnectandareinterdependentwithrespect
toeachother.TheFlexRayparameterswillbeintheformoftimeunitsorslotnumber
units.
8.6 FlexRayFrameImplementation
The FlexRay parameters extracted from the framework are used to configure the
FlexRayframe.EachFlexRayparametercanbeconfiguredmanuallyinXMLfileformat.
Thisapproachhasagreaterchanceofresultinginconfigurationconstrainterrors.Ifa
FlexRaydesignertoolisusedthiswillflagerrorsandviolations.Thedesignertoolfor
example will detect if by adjusting one parameter this affects and results in a
constraint violation in a separate parameter. The designer tool can generate CHI
(Controller Host interface) files that contain critical FlexRay frame parameters. The
frame parameters can also be contained in a FIBEX (Field Bus Exchange) file. Then
124
whenimplementingtheFlexRayframeittakesontheparametersassociatedwiththe
CHIorFIBEXfile.
8.7 FlexRayApplicationConfiguration
Configure and implement the FlexRay application based on the CAN application and
theFlexRayframeparameters.TheFlexRayapplicationsstructuredoesnotchangeby
undertakingthemigrationprocedure.Ifthereisasituationthatrequiresthephysical
structuretochange,returntosection8.1andstartover.AnydifferenceintheFlexRay
application structure, when comparedto the CAN application structure,can result in
different parameter values being extracted from the framework when compared to
thosethatwouldhavebeenobtainedotherwise.
8.7.1 Validation
To validate migration the deadlines of both systems need to be compared. The

frameworkisvalidatedbyexaminingexecutiontimesandbusloads.Thisallowsadirect
comparison between both protocols. The migration benefits can be summarised in
threescenarios.
ScenarioI
Here both CANandFlexRay meet their respective deadlinesbutdueto low bus load
volumes CAN messages get access to the bus faster than they do on the FlexRay
protocol.Inthissituationundertheseconditionsthereisnobenefittoimplementing
FlexRay unless other features of FlexRay are required by applications using the bus.
TheCANbusisatthe30%busloadmarkinthisscenario.
125
ScenarioII
In this scenario both CAN and FlexRay meet their required deadlines but the CAN
messages are suffering some delays getting access to the bus when compared to
ScenarioI.ImplementationofFlexRayismorejustifiablethaninScenarioIbutthereis
equallyasstrongacasetobemadeforthecontinueduseoftheCANbus.Thedesigner
willhavetomakeadecisionbasedonanumberoffactorssuchasfutureloadsonthat
bus and if FlexRays features are required for the implementation of other
applications,togivebuttwofactors.CANbusloadisatapproximately60%busload.
ScenarioIII
In this Scenario some CAN deadlines are being violated and/or busload has reached
saturation. CAN busload exceeds the maximum attainable value and complete
migrationisjustifiable.
8.8 Conclusion
Through the implementation of the steps discussed in this chapter a successful

migrationframeworkwasdeveloped.Thesestepsaresummarisedintheflowchartin
Figure 81. The chapter presents the steps necessary to process an application
originally configured to operate on theCAN network and is now requiredto operate
ontheFlexRaynetwork.
126
CANtoFlexRayMigrationMethodology
9 CAN to FlexRay Migration

Methodology:
9.1 Introduction
Thisresearchisdeemedasuccessuponachievingasuccessfulimplementationofthe
referenceCANapplicationontheCANprotocol,andthenmigratingandimplementing
the same application using the FlexRay protocol, by applying the framework. The
approachtakenissimilartotheapproachusedbyPop(2007).Thisinvolvesexploring
taskdeadlineonthemessagelevel.Messagelevelanalysistechniquesaredesignedto;
DetermineifdeadlinesaremetintheSTsegment
ObtaintheFlexRayframelength
FindtheWCRTsintheDYNsegment
9.2 FrameworkDevelopment
Todevelopaframework,initialparametersneedtobedetermined,implementedand
tested. Initial parameters are obtained from the reference CAN application such as
initial release time, task graph deadline, task execution times etc, as specified in
section8.4.2.
127
9.2.1 SystemDefinition
When migrating from CAN to FlexRay the first notable issue is that the two network
protocols are different in their fundamental principle of operation. CAN operates on
the principle of an ET protocol and FlexRay operates both an ET and a TT type
protocols.
BeforeanymigrationcantakeplaceCANdataisrequired.Thisdatacanbegenerated
bytheuserusingparametersthatprovideafairrepresentationofaCANsystem.The
recorded CAN data is analysed to obtain deadline timings and bus parameters that
FlexRaywillneedtomeetuponsuccessfulmigration.
9.2.2 DefiningCANDatainFlexRayFormat
AllCANtrafficisET,therebycriticaltaskscanbegivenhigherpriorityIDstoaidaccess
tothebus.AftertheCANparametersareobtainedthedesignerisrequiredtodecide
whereintheFlexRaycommunicationcyclethisdatacanbeplaced.Apossiblesolution
is to place all ET CAN messages into the DYN segment of the FlexRay frame. This
ensurestheETcharacteristicsofCANaremetthroughtheuseoftheETcharacteristics
ofFlexRaysDYNsegmentasimplementedbyCummings(2008).Howeveritdoesnot
makeefficientuseofFlexRaysfeatures,suchashavingbothaSTandDYNsegment;it
onlytakesadvantageofthehighbandwidthavailable.
FlexRays bus bandwidth was also necessary to consider. The options available were
2.5MBit/s, 5MBit/s and 10MBit/s. The value chosen would have a major bearing on
other system parameters specified in appendix A and B of the FlexRay specifications
v2.1revA.
IfcertainCANmessagesareschedulableandoccuratpredefinedmomentsintimea
schedulingtablecanbeconstructedastotheexactmomentintimewhenamessage
willrequiretransmissionandhowoftenthisoccurs.Duetoamessagebeingtriggered
for transmission on a predefined moment in time, the network protocol responsible
128
for transmission is considered a timetriggered protocol. FlexRays ST segment fulfils

thisrequirement.AllcriticalschedulablemessagescanbeplacedintheSTsegmentof
theFlexRayprotocoltoguaranteetransmission.
ApossiblealternativetoimplementingallthecriticaldataintheSTsegmentistoplace
someofthecriticaldataintheDYNsegment.TheDYNsegmenthasadefinedsegment
intheFlexRaycycle;thereforeifasinglemessagewasassignedthehighestpriorityin
this segment on its own it would be guaranteed to get access to the bus. As more
messagesareadded,theirprioritieswillbelowerthantheinitialmessagetherebynot
guaranteeingtimelyaccesstothebus.Thisapproachisnotinvestigatedfurtherinthis
researchastheonlywayofguaranteeingcriticalmessagesgetaccesstothebusisby
allocatingthemslotsintheSTsegment.
9.3 SystemImplementation
To achieve a successful system implementation the CAN application is implemented

separately to the FlexRay implementation. First the reference CAN application is
implemented and the consequential data is logged for analysis. Through the
framework the FlexRay frame, cluster and message parameters are obtained. Using
these parameters the reference application is implemented in FlexRay and its
consequentialdataisloggedforanalysis.
9.3.1 PeriodicTaskAnalysis
Theaimoftheanalysisatthisstageistodeterminedeadlinesatthemessagelevelof
the periodic tasks. The technique described in Aloul (2005) is used to synthesise the
periodic tasks in the ST segment onto message level. The ST segment slot size is
definedatthisstage.AheuristicapproachistakenwhenchoosingtheSTpayloadsize.
ThisthenallowstheFlexRayframesizetobedefinedandaFlexRaycycleperiodisalso
obtained.
129
9.3.2 AperiodicTaskAnalysis
Due to the nature of the DYN segment a different approach has to be taken to that
usedfortheperiodictasks.Aperiodictasksarescrutiniseddowntotheirmessagelevel
using a RTA procedure. Because each message is aperiodic a WCRT is calculated for
each message so the designer knows under the worst circumstances what the
maximumdelayforeachmessageis.
9.4 Verification
TheapplicationrunningontheFlexRayprotocolisrequiredtomeetorimproveonthe
timingandbusparametersobtainedusingthesameapplicationontheCANprotocol.
UnderverysmallbusloadsCANisabletomarginallybeatFlexRaytimingsduetothere
being a reduced chance of messages been blocked or delayed. At higher busloads
FlexRaysadditionalbandwidthshouldenableittohandlehighervolumesofdata.This
isverifiedintheTestingandResultssection.
9.5 ImplementationofAnalysisFindings
TheFlexRayframecanbeconfiguredasperresultsobtainedinanalysisoftheSTand
DYN segments. At this stage there could be discrepancies between values calculated
andachievablevalues.Thisisaresultofconfigurationvaluesbeingdifferentfromthe
achievableminimumormaximumparameterranges.Asolutionascloseaspossibleto
the calculated results is used in this scenario. This solution is attainable from the
FlexRayframedesignerprogram,orthroughtheexaminationofFlexRaysconstraints
inappendixAandBofFlexRaysspecifications.
130
9.6 ApplyingFrameworktoaRealWorldApplication
Using the framework steps in the abstract implementation (a Traction Control

application); the framework is applied to a realworld application configuration. Bus
statistics are recorded and compared to those achieved using the CAN protocol. The
abstractimplementationcontainsmorenodesthantheexperimentalimplementation
(anAdaptiveCruiseControlApplication)modelandisalsousedtoacquireassociated
FlexRayparameters.
9.7 GenericCANtoFlexRayDevelopment
The experimental implementation of the application was processed in the same

physical development environment where possible. This includes both the reference
CANimplementationoftheapplicationandthereferenceFlexRayimplementationof
theapplication.Thisallowedadirectcomparisonbetweenthetwosetups.Thesame
can be said for the third test case Verification of TimeTriggered Properties, both
CAN and FlexRay implementations were implemented in CANalyzer. These
implementationtestcases(TractionControl,AdaptiveCruiseControlandVerification
ofTimeTriggeredPropertiesarepresentedindetailinChapter11).Theinitialmodel
forobtainingtheSTsegmentsizeandcycleperiodwasabstractedfrom(Aloul,2005)
asdescribedinsection6.5.5.TheDYNsegmentsizewasdevelopedfromworkcarried
out by (Traian Pop, 2006) as described in section 6.5.5. Key to obtaining the FlexRay
frameandclusterconfigurationparameterswassynthesisingtheapplicationtaskstoa
message level. As FlexRay is composed of a static and dynamic segment, messages
transmitted in the static segment are scheduled prior to execution while messages
transmitted in the dynamic segment are event triggered and it is not known exactly
whentheseeventswilloccur.ThisleadtoRTAapproachbeingusedinconfigurationof
theDYNsegment.
TheCANmessagesetMCAN(Equation91)iscomposedofCANmessages,CANmi,which
connecttasksonthetaskgraph,whereiisthenumberofmessagesonthetaskgraph.
131
M CAN = {CAN m1 K CAN mi }

Equation91:CANMessageSet
The CAN message parameter set is composed of a component set of message size
(size(mi)), message ID (IDi)and the message period (period(mi)). This is illustrated in
Equation92.
CAN mi = ( size(mi ), IDi , period (mi ))

Equation92:Messagecomponents
9.8 StaticSegmentDevelopment
Initial requirements before a message can be scheduled are the tasks worst case
execution time (WCET) (wi), process deadline time Di, release time ri and the task
period.ThefinaltaskgraphdeadlineDiisobtainedbysummingalltheperiodsinthe
task graph. Each individual task can be compiled into a task graph which shows the
executiontimeofeachtaskandthetaskdeadline.Anyprecedenceconstraintsoneach
taskshouldbetakenintoconsiderationatthisstage.Thetaskgraphexecutiontimeis
calculatedbysummingupeachtasksexecutiontimealongthechosenpathofthetask
graph.Thelongestpathistheonethatwillfinishatthelatesttime.Tofindtheworst
possible time a task will take to complete, select the longest path in the task graph
(Equation93).
wi = longest path through task graph

Equation93:TaskGraphExecutionTime
Thereforetheexecutiontimeofapathiisthesumofeachtasksexecutiontimealong
thechosenpath.TheWCETisdependentonavarietyoffactorssuchastheprocessor
thetaskisbeingexecutedonandthetaskpriority.WCETiscalculatedfromthelongest
132
path a task takes from the moment it is called until it has successfully completed
execution.
9.8.1 TaskScheduling
Toscheduleanintermediatetaskriandwioftheintermediatetaskarerequired.The
intermediatetaskdeadlineiscalculatedasillustratedinEquation94.
d i = wi + ri
Equation94:IntermediateTaskScheduling
Any slack in the system can then be calculated and equally reallocated among each
task.FirstthetotalslackTotalSlackiisrequired.Thisisobtainedbysubtractingthetask
graphdeadlinefromthesumoftheexecutiontimesalongachosentaskgraphpathas
presentedinEquation95.
TotalSlacki = Di ci
Equation95:TotalAvailableSlack
The total available slack is then reallocated equally among the number of tasks (x)
alongthechosepathasillustratedinEquation96.
slacki =
TotalSlacki
pathx
Equation96:SlackperTask
Withthenewslackreallocated,eachtasksreleasetimerianddeadlinetimediisnow
recalculatedtoincludetheslack.
Afterthefinalri,diandwiareknownweperformachecktodetermineifthevalues
obtainedthusfarwillpotentiallyleadtoaschedulablesolution.Equation97isusedin
133
determiningthisresult.SchedulingisconsideredsuccessfuliftheWCETislessthanor
equaltodiminusri.
wi d i ri
Equation97:ParameterValidationCheck
9.8.2 MessageDeadline
Once the final ri, di and wi are known we use these parameters to calculate the
deadline of each message as illustrated in Equation 98. This deadline is the
transmission deadline time td(mi), by which time transmission of the message is
requiredtohavebeencompleted.
td (mi ) = d i ri wi
Equation98:TransmissionDeadline
Anyfactorsaffectingadelayintransmissionneedalsobeaccountedfor.DuetotheST
segmentbeingTTthereisnonetworkcontentionwhenamessagetriestoaccessthe
bus.ResultingfromthisthetransmissiondelayiscalculatedasperEquation99.
transmission delay =
size( mi )
Bus speed
Equation99:TransmissionDelay
For multirate task graphs the LCM (Lowest Common Multiple) of all coupled task
graphperiodsisusedtoguaranteethetimelyexecutionofalldeadlines.Anexampleof
thisisiftherearetwotaskgraphswithperiodsof2msand5msrespectively.Ahyper
cycleof10msisrequiredtoguaranteetimelytransmissionofallmessages.
134
9.8.3 PayloadDefinition
To calculate the slot delay and the transmission time, the message size and frame
payload size parameters need to be finalised. All the messages that require
transmission are summed up and the header and trailer bytes are included to give a
morerealisticframesizeinbytes.Theheaderandtrailerdataarecollectivelytermed
the overhead, as this data accompanies the payload but is not required by the
application. The number of message transmissions required to transmit all data is
calculated.Indeterminingtheframesizethepayloadsizealsoneedsdefining.Thisis
duetothepayloadbeingpartoftheFlexRayframe.
Before obtaining the total number of FlexRay frames required to transmit the entire
CAN payload data at the chosen payload it was required to know the FlexRay frame
size.TheFlexRayframesizeisdeterminedbyEquation910.Startatapayloadsizeof
one byte and increase by a value of one byte with each iteration. Payload sizes are
requiredtobeanevenintegervalue.
FRsize(mi ) = ( pd j + Oh )
Equation910:FlexRayFrameSize
Equation911presentsthetotalnumberofframesrequiredtotransmitallSTdataat
the chosen payload size pdj. Where j is an integer value in one application cycle. In
Equation912CfFRisthenumberofframesprecycle.Ifthesize(mi)parameterincludes
bitstuffingthiswillleadtoadatacycletotalsize(intermsofnumberofbytes)thatis
toolarge.
n
size(mi )
Cf FR =

pd j
i =1
Equation911:FramesperApplicationCycle(STData)
Atthesetpayloadsizethenumberofframesrequiredtotransmitthecompletecycle
data can be found. Start at a payload size of one byte and increase in single integer
135
values until ten consecutive increases in the total number of bytes is obtained. Now
that the total number of required frames per application cycle is found the total
amount of data for transmission is also known using Equation 912. D is the total
transmitteddataatthechosenpayloadvalue.
D = Frame Size Cf FR
Equation912:TotalRequiredBytes
A list is generated containing the total number of bytes required to transmit all the
dataatthechosenframesize.Graphingthis dataresultsinagraph withthegeneral
profilesimilartothatasillustratedinfigure91.Eachregiononthegraphisexplained
inthefollowingparagraphs.
Region1:Payloadsizesareinitiallyverysmallinrelationtothetotalamountofdata
fortransmissionthereforealargenumberofframesarerequiredtotransmitthedata.
Astherearemoreframesthereisalsomoreoverheadaccompanyingthoseframes.To
giveanexample,ifthereare40Bytesfortransmissionintotalandthepayloadsizeis1
Bytethen40framesarerequired.Ifthepayloadisincreasedto2Bytesthenonly20
Bytes would be required. This means the overhead is reduced from 40 frames to 20
frames.
Region 2: This is the region from which the payload and frame size are chosen. The
lower limit is reached in terms of the total number of bytes transmitted per chosen
payload size; therefore the payload reaches its optimal size in relation to the total
number of bytes transmitted. This continues the trend of less total data due to less
overhead.Thetotaldatatransmittedstartstoincreaseduetothepayloadcontinuing
toincrease.
Region 3: The payload is continuing to increase. The increase is linear because the
numberofframesrequiredhasreacheditsoptimalpointandcannotbereducedany
further.Forexampleifthereare3messagesfortransmission(regardlessofhowsmall
thepayloadsize)allthedatacannotbetransmittedinlessthan3frames.
136
Figure 9-1: ST Frame Data Graph Profile
The payload and frame value are chosen heuristically. The chosen value is not
necessarily the value that results in the smallest total number of bytes for
transmission. A smaller or larger payload value might better suit the applications
requirements. A smaller payload size requires more frames to transmit the same
quantityofdata.Choosingalargerpayloadsizecanresultinalargerframesizewhich
allowsreducedsystemgranularity.
9.8.4 STSlotSize
In the ST segment a task transmits a message and that message is transmitted in an

assigned slot. In this framework this assignment is implemented as follows. T1
transmitsm1whichisassignedtoslot1,T2transmitsm2whichisassignedtoslot2
and so forth until all messages have been assigned a unique slot. Each message
requires an individual slot due to there beingnoslot reuse inthe ST segmentof the
FlexRayprotocol.
137
Each message has a period, period(mi) equal to its deadline td(mi). Transmission slot
durationgdStaticSlotiscalculatedbysummingthemessagepayloadsizeandmessage
overheadandthendividingbythebusbandwidth(913).
gdStaticSlot =
size( payload i ) + size(overheadi )

s
Busspeed
Equation913:SlotDuration
9.8.5 Discretisation
Bydiscretisingtheslotdurationthemessageperiodcanbeexpressedasafunctionof
slots instead of as a function of time. This allows greater ease in setting the FlexRay
frame parameters. Message period is now expressed in terms of transmission slot
intervals.Thisisachievedbydividingtd(mi)bygdStaticSlot(914).
td (mi )
td ( M i ) =
gdStaticSlot
Equation914:DiscretisedSlotDelay
The discretised slot duration td(Mi) is labelled so to differentiate it from the

undiscretisedslotdurationtd(mi).
9.8.6 PeriodicityandDistanceConstraints
Toguaranteeamessagewillmeetitsdeadlinestwoconstraintsareinvoked;
Periodicity: The minimum message period, pmin, is required to be a multiple

harmonicofabaseperiod,pbase.
Distance:Thedistancebetweentwosuccessivemessagesmustbelessthanor
equaltothemessageperiod,period(mi).
138
CANto
oFlexR
RayMigrrationM
Methodology
To obtain
n a FlexRayy frame cyycle that meets
m
both
h these con
nstraints w
we use thee
minimum message period,
p
pmin,, as our staarting pointt (the smallest td(Mi) value). Wee
obtain a pbase value that is a multiple
m
haarmonic perriod of pminn. The otheer messagee
periods caan be adjusted downw
wards (if m
message peeriods are increased th
here is thee
possibilityyofmissinggdeadlines)).Thisallow
wstheperio
odicityconsstrainttobemet.Thee
distancecconstraintissmetbecau
usethedisttancebetweenslot1incycle1andslot1in
n
cycle 2 is constant and so on. Also
A as the cycle perio
od is modiffied to pmin or less (ass
defined by the perio
odicity consstraint) and
d the distan
nce betweeen slot 1 in successivee
cyclesisleessthanor equaltoth
hemessageperiod.Wh
hereslot1 ismentioneeditisalso
o
applicableefortheran
ngeofslots1,2,3..n,wheren isthenumb
berofSTslo
ots.
Figure 9-2: Illlustration of Periiodicity and Distaance Constraint
Examiningg Figure 92
2, if Pmin iss 6 and pbaase containss a value o
of 1.5, this meets thee
distanceaandperiodiccityrequirements.Thissisbackedu
upbyEquattion915.
WhenschedulingtheeFlexRayframeitissu
uggestedto reducetheecyclesize asmuchass
possible without
w
excceeding anyy timing con
nstraints. This is to aid
d the DYN ssegment in
n
accessingtheFlexRayybusasfrequentlyaspossible,th
herebyenab
blingDYNm
messagesto
o
betransm
mittedmorefrequentlyonthebus,ifrequired
dbytheapp
plication.
915isused
dinthevaliidationofthepbasevalueasamultipleharmo
onic,which
h
Equation9
allowstheeperiodicityyanddistan
nceconstraiintstobefinalised.
139
9
2 k pbase p min < 2 k +1 pbase

Equation915:PeriodicityandDistanceConstraintValidation
Thenumberofiterationsrequiredtovalidatewhatkisequaltoin2kpartofEquation
915,canbedeterminedfromthenumberof(integer)iterationstakentogetfrompmin
topbaseminusone.Forexampleifpminwas48msandpbasewas3ms,therebykisequal
to4(5iterationsminus1).
36122448
2 4 3 48 < 2 4+1 3
48 48 < 96
Any modifications still have to meet the periodicity and distance constraint
requirements.
9.9 DynamicSegmentDevelopment
AstheDYNsegmentisusedtotransmitaperiodicmessagesthesecannotbescheduled
priortotransmission.ThisleadstotheuseofRTAindeterminingtheworstcasedelay
of each DYN message. Some parameters that can affect the transmission of the DYN
messagesare;
TheearliestamessagecanbetransmittedinaslotintheDYNsegmentisafter
theSTsegmenthasfinishedtransmission
DYN messages are assigned on a priority basis; therefore higher priority

messagescanpotentiallyblockordelaylowerprioritymessages
Transmission of a message cannot occur if the minislot counter value is less

than the pLatestTx value. The frame and payload sizes are calculated as per
DYNmessagesizes.
Onlyonenodecantransmitonthebusatanyonetime
140
Onlyoneslotisassignedtoanodeatanyonetime
The node determines when the slot counter value is equal to the frame
identifiervalue.
TheDYNsegmentsizeisalreadydefined.ThisisbecausetheSTsegmentssize,FlexRay
cycle size and the NIT (obtained through a FlexRay designer tool) (Dependable
ComputerSystems,2007)parametersarepredefinedthroughourSTsegmentanalysis.
ThisleavestheremainingtimeallocatedfortheDYNsegment.
FirstacheckisrequiredtoassessifitispossibleforallDYNmessagestotransmitinthe
DYNsegment.Forthistobepossiblethenumberofminislotsshouldbegreaterthan
or equal the number of DYN tasks. If this is not the case some tasks will not be
allocatedaslotfortransmission.Reducingtheminislotsizeasper(Consortium,2005)
allowsmoreslotstobeallocatedwithoutincreasingtheDYNsegmentsize.
ToverifyiftheDYNsegmentislargeenoughforthetransmissionofallDYNtaskswe
need to view the DYN segment size as a function of the number of minislots. This is
done using Equation 917. Here the total communication time of all DYN messages
(Equation916)isdividedbythenumberofminislot.Ifthenumberofprovidedslotsis
greaterthanorequaltothenumberofrequiredslots,transmissionispossibleunder
correctscheduling.ThisisshowninEquation918.
TotalDYN C m = (C m1 KC mn )
Equation916:TotalDYNCommunicationTime
Required Slots =
TotalDYN C m
gdminislot
Equation917:MinimumNumberofRequiredDYNSlots
No. of allocated slots No. of required slots
Equation918:SlotQuantityVerification
141
The maximum worst case delay, calculated using Equation 919 takes into account
delays caused by other DYN messages, the ST segment and associated FlexRay
parameters.
Rm (t ) = C m + m + wm (t )
Equation919:DynamicWorstCaseResponseTime
Where;
Rmisworstcaseresponsetime
CmasrequiredforSTsegment,isthemessagecommunicationtime,Equation920
m is the longest delay suffered during one bus cycle if a message is generated by
sendertaskjustafteritsslothaspassed,Equation921
wmistheworstcasedelaycausedbytransmissionofSTmessagesandhigherpriority
DYNmessages,Equation923
The communication time, as illustrated in Equation 920 is the DYN frame size
multipliedbythebus bittime.The DYN frame sizeiscomposedoftheDYN message
andassociatedoverhead.ThesameoverheadvalueascalculatedpertheSTsegmentis
used.
Cm = DYNFramei Bit Time
m = FR(t ) ( STbus + Cm + NIT )
Equation921:mDelay
WhereFR(t)isthelengthoftheFlexRaybusandSTbusisthelengthoftheSTsegment,
andCmisthetimetheDYNmessageitselftakesonthebus.
wmcanbecausedbyhigherprioritymessageshp(m),andunusedDYNslotswithlower
priority identifiers. Each unused minislot gives a delay of one minislot ms(m). The
singleminislotenablestheminislotcountertoincrementtothenextminislotvalue.In
142
the worst case to obtain the minislot number it is assumed that all messages of a
higherpriority(thanthecurrentmessage)havetransmittedinthepreviouscycle.This
resultsinequation922.
ms(m) = Total DYN minislots 1
Equation922:NumberofUnusedMinislots
Forthiscalculationtheworstcasedelayoccursifthemessagerequirestransmissionat
the moment the pLatestTx value is the same as the minislot counter. Therefore all
minislotsafterthisvaluecannotbeusedfortransmission.ThisisillustratedinEquation
923.
wm (t ) = STbus + hp(m) + ms(m) + ( pLatestTx.gdMinislot ) + NIT
Equation923:wm(t)Delay
Using Equation 919 presents the WCRT delay of a DYN message. This enables the
network designer to know how many FlexRay cycles it will take to guarantee the
transmissionofeachDYNmessage.
9.10 Conclusion
Initial CAN parameters are processed to deliver the CAN message parameters MCAN.
The component set of MCAN parameters are the message size (size(mi)), message ID
(IDi)andthemessageperiod(period(mi)).Theseparametersallowthedevelopmentof
the FlexRay cluster configuration parameters. The cluster configuration parameters
concernedare;
CycleLength
- gMacroPerCycle
STSegment
- gNumberofStaticSlots
143
- gdStaticSlot
- gPayloadLengthStatic
DYNSegment
- gdMinislot
NetworkIdleTime
- gdNIT
The cluster parameters are necessary when configuring the FlexRay frame. From the
frameworktheFlexRaymessagesetisMFR={FRm1.....FRmn}.Themessagesetisdefined
asFRmn= (FRperiod, FRsize and wi), where FRsize and wi are the same valuesas forMCAN
because theapplicationtaskset does notchange. TheFlexRay frame componentset
cannowbedefinedasFRcompset=(ST,DYN,andNIT).WithfurthersubdivisiontheST
segmentis composed of the parameter set FRST = (slotsize, numslot, STpayloadsize). The
DYNsegmentiscomposedoftheparametersetFRDYN=(mslotsizeandDYNpayloadsize).
ThenetworkidletimeisthefinalparametersetFRNIT=(NITsize).
Once complete migration has taken place from the CAN protocol to the FlexRay
protocol the system designer should have all necessary parameters to configure the
FlexRay frame. The framework defines the frame size, slot sizes and payload sizes in
thestaticsegmentandDYNsegmentminislotandpayloadsizes.
To summarise, the framework can be analysed in algorithmic format. Figure 92

presents the algorithm for the ST segment, Figure 93 presents the DYN segment
algorithm and Figure 94presents the FlexRay clusterand frame parameter message
sets.
144
STSegment
GraphicallyrepresentappinTGformat
CANparameters(ri,Di,)
ifWCRTnotavailable
Determineusingjm,wmandCm
for MCAN ={CANm1....CANmi} CAN message set
definition
{
CANmi=(size(mi),IDi,period(mi))
}
ExtractIntermediateDeadlines
ReallocateSlack
Obtainrecalculatedrianddideadline
forvalidationcheck
{
widiri
}
definetransmissiondeadlinetd(mi)
determinetransmissiondelay
ifmultirategraphs
useLCMtoobtaincyclesize
else
Definepdjpayloadsize
usingFRsize(mi),Oh,CfFR
fortotalbytesrequiredatchosenframesizeD
{
determinegdStaticSlotsizeofstaticslot
}
discretisetd(Mi)
Verifyviaperiodicityanddistanceconstraint
pminandpbase
2k.pbasepmin2k+1.pbase
End;
ReturnSTParameters/*STslotsize,payload,frame
size*/
Figure 9-3: ST Scheduling Algorithm
145
DYNSegment
Determine total DYN communication time

TotalDYNCm
verify{
slotquantity
WCRT
Cmcommunicationtime
m longest delay during one bus cycle if
slothasjustpassed
}
for
{
wm(t)delaycausedbySTmsgsandhp(mi)
}
end;
Return max delay /*Max possible delay for DYN
msgs*/
Figure 9-4: DYN Scheduling Algorithm
Frame&ClusterParameters
flexRaymessagesetisdefinedasMFR={FRm1.....FRmn}
for
{
FRmn=(FRperiod,FRsizeandwi)
}
flexRaycomponentsetFRcompset=(ST,DYN,andNIT)
for
{
FRST=(slotsize,numslot,STpayloadsize)
FRDYN=(mslotsizeandDYNpayloadsize)
FRNIT=(NITsize)
}
end;
returnFlexraydata/*STandDYNconfigdata*/
Figure 9-5: FlexRay Extraction Parameters
146
9.11 References
AloulNKaF,2005,TheSynthesisofDependableCommunicationNetworksfor
AutomotiveSystems,SAEInternalional2005,
ConsortiumF,2005,FlexRayCommunicationsSystemProtocolSpecificationVersion
2.1RevisionA.p245,
CummingsR,2008,EasingtheTransitionofSystemDesignsfromCANtoFlexRay,SAE
International,Detroit.
DependableComputerSystemsD,2007,DesignerPRO4.3.0.In:Designerpro,Designer
Pro<Light>andDesignerPro<System>,
PopT,2007,AnalysisandOptimisationofDistributedEmbeddedSystemswith
HeterogeneousSchedulingPolicies,DepartmentofComputerandInformation
Science,LinkpingUniversityInstituteofTechnology
TraianPopPP,PetruElses,ZeboPeng,AlexandruAndrei,2006,TiminigAnalysisofthe
FlexRayCommunicationProtocol,Editor,ConferenceName,Conference
Location.
147
DevelopmentToolsandApplications
10 Development Tools and Applications:
10.1 Introduction
Thissectiondescribesallthephysicalhardwareandthesoftwareapplicationsusedin
the development and implementation of the chosen applications. For the abstract
implementations the only hardware used was the pc upon which the FlexRay frame
parameters were developed. From the software perspective, for the abstract
implementation the FlexRay designer tool was used to verify parameters extracted
from the framework. The experimental implementation involved the use of all
hardware and software mentioned in this chapter. During the initial development of
thegenericapplicationthedesignercansettheparametersaspertheapplication.This
includes the number of nodes, tasks, channels. For implementation of the ACC
configuration, restrictions such as the minimum number of tasks shall be defined by
theapplication.FortheimplementationofthethirdtestcaseCANalyzerwasusedto
configureandprocessboththeCANandFlexrayconfigurations.
10.2 Hardware
10.2.1 FlexRayDevelopmentKit
TheinitialstageofimplementingtheCANandFlexRayapplicationwascarriedouton
the SK91F467FlexRay which is illustrated in Figure 101. Each starter kit can be
considered a CAN node or a FlexRay node depending on the protocol on which the
application is running. The CAN and FlexRay ACC applications were built tested and
debugged using this starter kit. The starter kit allows the developer to use CAN and
FlexRayandispartoftheFujitsuMB91460series.Atthecoreofthestarterkitisa32
bitflashMCU(microcontrollerunit);thisMCUistheMB91F467D.TheFujitsuFlexRay
148
communications controller (CC) MB88121B enables FlexRay communication. The

starter kit can be used in standalone mode or in monitor debugger mode. Using the
FlexTiny FR, the physical layer, as specified in the FlexRay specifications is achieved.
Thisdeviceispluggedintotheportsprovidedontheboards.
Themainfeaturesofthestarterkitarelistedbelow(Europe,2007);
Supports32bitFlashmicrocontrollerMB91F467D
SupportsFlexRayCCMB88121
OnboardMemory:32Mbit(4MByte)SRAM
ItispossibletoconnecttheFlexRayCCindifferentwaystotheMCU
Allmicrocontrollerresourcesavailableforevaluation
Incircuitserialflashprogramming
ThreeselectableRS232orLINUARTinterfaces
ThreeHighSpeedCANinterfaces
TwoFlexRaychannels(ChA,ChB)
FlexRayphysicallayerRS485available
FlexRayphysicallayerdrivermodulefromTZM(FT1080)connectable
16UserLEDs
149
Figure 10-1: Fujitsu SK-91F467D FlexRay Starter Kit
10.2.2 KeyParameters
10.2.2.1
FlexRayPhysicalLayer
The physical layer connection is achieved through a RS485 transceiver or a physical

layerdrivermodule fromTZM,calledFlexTiny (FT1080).Itcanbepluggedinandby
passes this transceiver. The FlexTiny FR (FlexRay) is illustrated in Figure 102. This
device offers a physical layer connection as specified in the FlexRay physical layer
specifications.
150
Figure 10-2: FlexRay Physical Layer Driver

Module
10.2.3 CANChannels
There are three high speed CAN channels available (CAN0, CAN1 and CAN2) for
connectiontotheCANcontrollerthrough9pinDsubconnectors.
10.2.4 Interfaces
There are 4 push button switches that are connected to the MCU. These can act as
external inputs, reload timer triggers, and input capture. There is also a separate
system reset button. There are 16 output LEDs connected to two ports (port 16 and
25).
10.2.5 VN3600FlexRayinterface
TheVectorVN3600asillustratedinFigure103isaUSBFlexRayinterface.
151
Figure 10-3: VN3600 FlexRay Interface
The VN3600 carries out analysis with the use of the Bosch ERay CC and start up is
enabled through the use of the MB88121B CC (GmbH, 2008). Each interface allows
access for one FlexRay cluster (Channel A & B) therefore if the designer wishes to
integrate more clusters, more interface units are required. It supports the maximum
payloadof254bytes,itcancoldstartaclusterwithoutanadditionalnodeandperforms
startupandsynchronousmonitoring.
10.2.6 CANcardXL
TheCANcardXLisaCANPCMCIAinterfacesuitablefornotebookordesktop(illustrated
inFigure104).
152
Figure 10-4: CANcardXL
It contains two (independent) CAN channels that are configured for 11 or 29 bit
identifiers.Itcanbeusedforerrordetectionandremoteframegeneration.
10.2.7 PassiveStar
The TZM FlexPS asillustrated in Figure 105 (FlexRayPassive Star) allowsthe userto
configureuptosixpassivebranches.ItwasdevelopedwiththeFlexRayphysicallayer
test working group. It also contains a car body ground connection and several test
points. Use of the FlexPS enables a more realistic network topology over direct
connectionbetweenchannels.ChannelAandChannelBbussesrequireaFlexPSeach
otherwiseconflictwilloccuronthebus.
Figure 10-5: FlexRay Passive Star
153
10.3 Software
10.3.1 FRFamilySoftuneWorkbench
TheFRfamilySoftuneworkbenchthatwassuppliedwiththestarterkitwasversion6
as can be seen in Figure 106. Softune workbench enables programs to be built and
compiled.
Figure 10-6: Softune Workbench V6
Oncethe programis successfully built and compileda .mhx (Motorola hex) (Manual,
2006)outputfileisproduced.Iftwonodesarebeingbuiltforexamplea.mhxfilewill
be required for each node. Next application is the FME (Fujitsu Microelectronics
Europe)FRFlashprogrammerwhoseinterfaceisillustratedinFigure107.
154
Figure 10-7: FME FR Flash Programmer
The appropriate MCU device is selected along with the baud rate and port number.
Oncetheseparametershavebeenselectedthe.mhxfileisselectedtobeflashedinto
thememoryofthestarterkit.Eachnodehastobeflashedseparately.
If monitor debugger mode of the workbench is required then once the program is
successfullybuiltandcompiledthedebuggeristhenstarted(themonitordebugkernel
isrequiredtobepreflashloadedtoeachboardbeforemonitordebugmodecanbe
entered). When the debugger is running the program can be stepped through as
required.Breakpointsandwatchwindowscanbeset.
155
10.3.2 DECOMSYSDESIGNERPRO
DECOMSYS Designer Pro is used to set the FlexRay cycle parameters. The actual
versionusedwasDECOMSYS::DESIGNER_PRO<LIGHT>4.3.0asillustratedinFigure10
8.
Figure 10-8: DECOMSYS::DESIGNER PRO
DECOMSYS designer pro has five sub headings with which the FlexRay frame details
aredefinedbedefinedin:
HardwareArchitecture
FlexRayFrameConfiguration
CommunicationPlanning
ECUSoftware
ECUConfiguration
HardwareArchitecture
TheFlexRaynetworknameiscreatedandtheChannelusage(A,B,A&Bornone)is
defined. Each node ECU is named and the communication controller (CC) is also
selected.
156
FlexRayFrameConfiguration
HerethemainparametersoftheFlexRayframearedefinedsuchascyclelength,static
segment size, dynamic segment size, slot size and mini slot size. A graphical
representationoftheframeisshownasillustratedinFigure109.
Figure 10-9: FlexRay Node and Cluster Configuration
Theseparametersarethenusedtocalculateotherrequiredparameters.Ifaconstraint
violationhasoccurreditishighlightedinredwiththeconstraintnumber.InFigure10
10constraint#18isviolatedforexample.
Figure 10-10: Constraint Violation
157
ThisconstraintnumbercanbecheckedintheFlexRayspecificationsappendixB.Once
theseparametersaremet,selectthefinishbuttontokeeptheconfiguration.
CommunicationPlanning
FlexRay frames are created and named. Each frame is assigned an associated signal
value.Theframescheduleisbuilthere.Eachframehasthefollowingparameters:
FrameTriggering
Frame
Channel
Slot
BaseCycle
CycleRepetition
Tx(transmit)CC
Rx(receive)CC
TxECU
RxECU
Report
Service
Thedynamiccyclehastwoparametersspecifictoitscycle:MinislotandTxtype.
AsampleFramescheduleisshowninFigure1011.
158
Figure 10-11: Sample Frame Schedule
ECUSoftware
This area is used to configure the periodic tasks for any application and interrupt
service routines. The files generated here are used by OSCONFIG (Operating System
CONFIGuration) in the ECU driver configuration (Dependable Computer Systems,
2007).Thesefileswerenotrequiredforimplementationinthisresearchandasaresult
theywillnotbediscussedanyfurther.
ECUConfiguration
The ECU driver configuration allows buffers to be assigned and generate the code
requiredfortheCOMMSTACKconfiguration.
159
Figure 10-12: ECU Configuration Screen
Figure1012showstheECUconfigurationscreenwiththeframevalues.TheAutoBA
(Buffer Assignment) tab automatically assigns the buffer configuration for each slot.
Thishastobecompletedforeachnode.Thecodegenerationtabpresentstheoutput
pathofthegeneratedcode.Codehastobegeneratedforeachnode.
Threefilesaregenerated;node.ccfg(configuration),node.hcfgandnodememorycfg.
ThesefilesarethenincludedintheSoftuneworkbenchwhencreatingandcompilinga
program. This ensures the frame parameters for the application will be the same as
thoseconfiguredinthedesigner.
160
10.3.3 COMMSTACK
Figure 10-13: COMMSTACKCOMMSTACK FlexRay Controller State Machine (Eggenbauer, 2006)
Before synchronisation can occur a node has to be online and. This is achieved
throughtheCOMMSTACKCOMMSTACK.Figure1013showsthepossiblestatesfrom
theoffstatetotheonlinestate.Thestatesarepresentedindetaillaterinthechapter.
DECOMSYSCOMMSTACKstructureismadeupoffourmainsections:
Theapplication(Configuration)
COMMSTACK(Library)
Hardware(FlexRay)
Hardware(Configuration)
Theapplicationconsistsofallthespecificationsrequiredbeforetheapplicationbuild
takesplace.
161
The COMMSTACK contains all of the library files information data that the host CPU
requirestocarryoutitsfunctionswhilebeingasmodularaspossible..Thisincludesthe
connectionschemafortheCC(communicationscontroller)hardware.
A FlexRay hardware node contains a minimum of one communication controller but
cancontainmoreifrequired.
Thehardwareconfigurationcontainsthedevicemappingandtheresetconfiguration
of the CC device(s). The static segment configuration data is required at precompile
time.
ThestatemodelcontrolshowtheCOMMSTACKbehavesinanysituation.InFigure10
13,eachstateiscontainedinanovalwhilethearrowsshowtheactiontakingplace.
Tables101107showthedifferentstatesoftheCOMMSTACKFlexRaydriver.
10.3.3.1
OffState
Table 10-1: Off State
Off
The FlexRay CC is not able to access the network nor is it
state configurable.ThisstateisenteredaftertheCOMMSTACKis
initialisediftheCCisdetectedsuccessfullyandthecluster
isnotyetsynchronised.
Reset
Reset performs a hard reset of the

FlexRayCC
EnterConfig
ENTERCONFIGENABLESTHECCTOBE
CONFIGURED
SendWakeUpChA SendWakeUpChA
enables
the
transmissionofthewakeuppatternon
channelAofthededicatedCC.
162
1.
2. Off state: The FlexRay CC is not able to access the network nor is it
configurable.ThisstateisenteredaftertheCOMMSTACKisinitialised
if the CC is detected successfully and the cluster is not yet
synchronised.
3. ResetperformsahardresetoftheFlexRayCC
4. EnterConfigenablestheCCtobeconfigured
5. SendWakeUpChAenablesthetransmissionofthewakeuppatternon
channelAofthededicatedCC.
6. SendWakeUpChBenablesthetransmissionofthewakeuppatternon
channelBofthededicatedCC.
10.3.3.2
StartupState
Table 10-2: Start-up State
Startup The FlexRay CC enters the Startup state. Either

state
activeorpassivestartupisinitiateddependingon
configuration.
Abort
Returnsbacktotheoffstateexitingthe
startupprocess.
Action takes place once startup is
10.3.3.3
OnState
163
Table 10-3: On State
On
This state is entered once the CC and the cluster
state
are successfully synchronised. Buffer access for

COMMSTACKAPIfunctionsareturnedoff
Online
Online state is entered once the on

statehasbeensuccessful.
Halt
Halt immediately returns to the off

state at the end of the current
communicationcycle.
10.3.3.4
OnlineState
Table 10-4: Online State
Online
The FlexRay controller is synchronised to the

networkandthesoftwaredriverisabletoaccess
transmissionandreceptionbuffers.
Offline
Offlinestateisentered.
Halt
Halt immediately returns to the off

state at the end of the current
communicationcycle.
Abort
Abort causes the state to be
10.3.3.5
ConfigurationState
164
Table 10-5: Configuration State
Config THEFLEXRAYCONTROLLERCANBECONFIGURED.
LeaveConfig LeaveConfig
transition
occurs
when exiting the Config state.

Transition takes us into the off
state.
Abort
Leaves the config state, enters the

off state
10.3.3.6
ResetState
10.3.3.7
WakeupState
10.3.3.8
VectorCANAlyzer.FlexRay
Table 10-7: Wakeup State
Wakeup FlexRay controller transmits a wakeup pattern

Table 10-6: Reset State
Reset
Abort causes the transmission of the

Abort
The FlexRay controller is reset therefore no
wakeup pattern to be aborted
access to the controller is permitted.
immediately and returns to the off
Reset
1
1
state.
Reset is performed again
Transition occurs once the wakeup
Causes transition to the Config state
pattern
has
been
successfully
reset has been completed
completed
165
CANalyzerisatool foranalysing CANand FlexRaynetworks.Theversionusedinthis

researchis6.1.33(SP3).TheprimaryfunctionofCANalyzeristomonitortrafficonthe
network(GmbH,2007),otherfunctionsinclude;
Listentobusdatatraffic
Displaydatamessagesegments
Statisticsonmessagefrequency
Insertpreparedfunctionalblockssuchasfiltersgeneratorblocks
Recordinformationforofflineevaluations
CANalyzercontainsincreasedfunctionalitythatenablestheusertoprogrammatically
implement application specific parameters. This can be achieved through the use of
function blocks (e.g. test case three) or by using CAPL (CANalyzer Programming
Language). CANalyzer contains the necessary browser for creation, building and
compilationofCAPLprograms(GmbH,2007).
A Flow diagram (FlexRay example is illustrated in Figure 1014) is used to show the
functionsofthebusmonitoringfunctionblockssuchas;Statistics,Busstatistics,Trace,
Data,GraphicsandLogging.Table108givesanoverviewofeachfunctionblock.
Table 10-8: Analysis Function Block Overview
Function
Comment
Block
Statistics
Shows the mean frequency or spacing of

message/s.
BusStatistics Displays the statistics such as frames per

second,frameerrorsandnullframestoname
a few parameters. CAN data is acquired from
theCANcontroller
Trace
Displaysthetracedataoninputlines
166
Figure 10-14: FlexRay Sample Flow Diagram
Functionblockscanbeincludedtoadddataontothenetwork.Thiscanbedonetwo
ways;insertingaFlexRayframepanelasseeninFigure1015.Thisallowstheuserto
configuretheframeparametersincludingthepayloaddataandframeID.Thesecond
ways is by inserting a CAPL function block and writing the system parameters in the
CAPLbrowser(seeillustration1016).
167
Figure 10-15: FlexRay Frame Panel
Figure 10-16: CAPL Browser Panel
OnefeatureofCANAlyzer.FlexRayisthatCANandFlexRaycanbeanalysedatthesame
time.ThisisachievedthroughtheuseofaCANcardXLfortheCANbusandtheVN3600
FlexRayinterfacefortheFlexRaybus.BothareproducedbyVector.
168
10.4 Conclusion
Thischapterpresentsthetools requiredto progress fromtheimplementationofthe

CANapplicationtotheverificationofFlexRaypropertiestothefinalimplementationof
the FlexRay application. The features of the hardware tools required are presented,
suchastheFujitsudevelopmentenvironment,CANcardXLandtheVN3600alongwith
the any software tools used such as, DECOMSYS designer and Softune monitor
debugger.
169
10.5 References
DependableComputerSystemsD,2007,DesignerPRO4.3.0.In:Designerpro,Designer
Pro<Light>andDesignerPro<System>,
EggenbauerM,2006,COMMSTACK<FLEXRAY>1.8.DependableComputerSystems)
EuropeFM2007SK91F467FLEXRAYUserGuideFMEMCUUG91001716:Fujitsu
MicroelectronicsEurope)
GmbHVI,2007,CANalyzerHelp.
GmbHVI,2008,VN3600Datasheet.In:VectorInformatikGmbH,
ManualFSC,2006,FRFAMILYSOFTUNETMWORKBENCHOPERATIONMANUALforV6
CM71003283E.Fujitsu)
170
SectionIVTesting&
Results
SystemModel
11 System Model
11.1 Introduction
In this chapter the implementation models are presented. All preconditions to

migrationhavebeenpresentedtogetherwithanyconfigurationtechniquesrequired.
Thetestenvironmentandthetestcasesaredescribed.
Thetheoreticalimplementation(testcase1)usesaTC(TractionControl) model.The
physical implementation model (test case 2) used was an ACC (Adaptive Cruise
Control) system. The final test case, test case 3, The Verification of TimeTriggered
Properties was implemented using a straight forward task graph configuration. The
hardware and software used in the test case implementations are presented along
withthespecifiedconfigurations.
11.2 TractionControl&AdaptiveCruiseControlSummary
Tractioncontrolinvolvesreducingtheamountofslipbetweenthetyreandthesurface
(YoichiHori,1997)forexample,roadorice.Thisisdonebylimitingthepowerbeing
deliveredtothewheelthatisslipping.ThesamesensorthatisusedfortheAntilock
BrakeSystems(ABS)canbeusedindeterminingslip.
Adaptive cruise control allows the vehicle to maintain a preset speed without the
dangerofhittingthevehicleinfrontifitstops.Oncethedriversetsthedesiredspeed
thevehiclewillremainatthatspeedaslongasthereisnoobstacleinfront.Ifavehicle
infrontisencounteredtravellingataslowerspeedthanyourvehiclethenthebrakes
are applied accordingly. A sensor at the front of the vehicle detects any obstacles. If
the vehicle in front accelerates away your vehicle will accelerate back to its desired
presetspeed.
172
SyystemM
Model
plicationM
Models
11.3 App
TestCase1: Tractio
onControl
The first test case will be sttrictly an abstract

a
im
mplementatiion. This will
w involvee
obtaining a CAN app
plication an
nd processiing it throu
ugh the miggration framework to
o
obtaintheeFlexRayfrrameparam
meters.This testcasew
willdemonsstratethefrrameworkss
ability to produce viable FlexRay fram
me and clu
uster param
meters. The abstractt
implemen
ntation only requires five stagges of the process flow diagrram to bee
undertakeen.Thefivestagesarehighlighted
dinorangeiinFigure1111.
Figurre 11-1: Abstractt Implementation Stages
The TC m
model used was presen
nted in (Alo
oul, 2005) and is illustrated in Figure 112..
EachtaskssfunctionissdescribedasinTable111.
173
3
SyystemM
Model
Table 11-1: Traction Control Task Funnctions
Function
n
Task
ReadLeftRearWheelSpeed
T1
ReadLeftFrontWheeelSpeed
T2
ReadRighttRearWheelSpeed
T3
ReadRighttFrontWheeelSpeed
T4
CalculateH
HandWheeelPosition
T5
CalculateYYawRate
T6
ReadLaterralAcceleraationSensorr
T7
The TC model
m
has ten
t tasks, with each task performing a calculation or action
function. Communicaationbetweeenthetassksisdemo
onstratedw
withconnecttingarrowss
showingthedirection
ncommuniccationtakesplacein.
Figure 11-2: Traction C

Control Task Grapph Model
DuetotheTCmodelnotbeing implementtedonthe developmeentenvironm

menttheree
wasnoreq
quirementttoassigntaaskstocertaainnodes.
174
4
SystemModel
TestCase2: AdaptiveCruiseControl
The second test case will be an experimental implementation of an ACC CAN

application. Upon successful migration, precisely the same application will be
implemented in FlexRay using the frame and cluster parameters obtained from this
framework.Thissecondtestcase,togetherwithdemonstratingtheframeworksability
toproduceviableFlexRayparameters,isadifferenttaskgraphconfigurationscenario
compared to the first test case. This second test case also demonstrates that the
parametersobtainedcanbeimplementedinarealFlexRaycluster.Allsevenstagesof
theflowdiagraminFigure111arerequiredinthistestcase.
TheACCmodelusedintheexperimentalimplementationcaseisamodifiedversionof
amodelpresentedby(Riis,2007)and(Madsen,2007).Forthisthesis,theapplication
was modelled using a two node system. The system has six tasks, and each task
directlyinteractswithanothertaskontheapplication.ThisisillustratedinFigure113.
Thedirectionofmessagetransferisindicatedbythedirectionofanarrow.Eachtaskis
assignedtoanodewiththeactiontasksassignedonnode1(N1)andcomputational
tasksassignedonnode2(N2).ThetaskfunctionsarepresentedinTable112.
Table 11-2: Adaptive Cruise Control Task
Functions
Function
Task
ObtainVehicleVelocity
T1
Obtain
Distance
to T2
VehicleinFront
Calculate Relative Speed T3
ofVehicleinFront
Calculate
Desired T4
Velocity
C l l
Ab l
T5
175
SyystemM
Model
modelinataaskgraphfo
ormat.
Figure113illustratesstheACCm
Figurre 11-3: ACC Tassk Graph Represeentation
Communiccationoccu
ursbetween
ntasksviam
messages.M
Messagesaaretransmitttedonthee
bus.TheA
ACCapplicationdataissconfigured
dtotransm
mitintheSTsegment.P
Precedencee
constrainttsweredeffinedinthe application
n.Anexampleofapreecedenceconstraintiss
where m3
3 could not be transm
mitted unlesss m1 and m
m2 have beeen receiveed in Figuree
113.ThetasksareassignedtotthesamenodesintheCANandFFlexRayconffigurations..
T1transm
mitsm1inslot1;T2traansmitsm2inslot2an
ndsoforth. Figure114
4illustratess
theblockdiagramrep
presentatio
onoftheAC
CCwithtaskksassignedtoeachnod
de.
176
6
SyystemM
Model
Figure 11-4:
1
ACC Blockk Diagram Repressentation
ocatingthe ACCapplicaationdatattoeitherth
heSTorDYN
Nsegment,,
InFlexRayy,whenallo
thefollow
wingapproachistaken inthistesttcase.Allm
messagesthatinteract inacriticall
application are placeed in the deeterministicc ST segment. All dataa that is no
ot used in a
a
criticalapplicationisplacedinth
henondeteerministicD
DYNsegmen
nt.
TestCase3: VerificcationofTim
meTriggeredPropertiies
Tests casee three, th

he verificattion of tim
metriggered
d propertiees, demonsstrates thee
effectiven
ness of the FlexRay pro
otocol at guaranteeingg constant application
n execution
n
times. Thiis test casee will involvve undergoiing all stagees of the m
model flow diagram in
n
Figure 111. The CAN
N and FlexRay data shall be gen
nerated usin
ng CANalyzzer.FlexRay..
This test case demo
onstrates th
hat if prior considerattion is not taken wheen decidingg
messageIIDs,thiscan
ndegradeC
CANperforrmance.As longastheemessagessinFlexRayy
arecompaarableinte
ermofpriorrityandIDss,itisdemo
onstratedth
hatthetimetriggered
d
propertiessofFlexRayyresultinno
operformancedegrad
dationwhen
ncomparedtoCAN.
For thefin
naltest casse Verificattion of Tim
meTriggered
d Properties thetask graph wass
composed
dasperFigu
ure115.Beecausethesimplistictaaskgraphissnotfromaarealworld
d
177
7
SyystemM
Model
e
task does not have
h
a preedefine function. All aassociated task graph
h
example each
parameters are with
hin the rangges of the real world parameterrs, as used in the two
o
previousttestcases(TTCandACC)).
Figure 11-5 : Test

T Case Three
Task Graph Configuration
For this teest case alll application data is allocated to the ST seggment. Anyy additionall
datarequiredtoincrreasethebu
usloadisalssoallocated
dtotheST segment.TThisisdonee
so as to d
demonstratte that as long as eacch messagee has an alllocated slot in the STT
segment, transmissio
onshallnottbedelayed.Thereis noDYNdaatatransmittedinthiss
testcase.
11.4 Harrdware
Eachnodeeisimplementedonth
heSK91F46
67Ddevelo
opmentboard(twonod
desintotall
hence two boards were
w
requirred). The aapplication is flash loaaded onto each nodee
individuallyandthessystemisco
onfiguredasspertherefferenceapp
plication.
FortheCA
ANimplemeentationtheCANchan
nnelsaredirectlylinkeedtogetherrusingCAN
N
cables in the traditiional CAN bus structure formatt. A splice from the CAN cablee
178
8
SystemModel
connects to the CANcardXL which is inserted into the laptop containing

CANalyzer.FlexRay,formonitoringandbusloadingpurposes.
The physical layer is as per the FlexRay specifications through the use of the TZM
FlexTinyasdescribedinChapter10.Node1(N1)CHAisconnectedtopassivestarAand
N2(Node2)CHAisconnectertopassivestarA.N1CHBisconnectedtopassivestarB
andN2CHBisconnectertopassivestarB.PassivestarAandBarethenconnectedto
the VN3600 FlexRay interface via FlexRay cabling. The cabling from the node to the
passivestarisdoneusingCANcablesasthisdoesnotaffectperformanceinthistest
case.IfwakeupsymbolsareakeyfeatureoftheFlexRayframeisitsuggestedtouse
FlexRay cabling instead. The VN3600 FlexRay interface connects to the laptop
containingCANalyzerviaaUSBconnection.BoththeCANandFlexRaycablesare9pin
dsubconnections.
The physical test environment used only applies to the ACC experimental
implementation, test case two. For test case three, CANalyzer was used to generate
theCANdatawhiletheFlexRaydatawasgeneratedusingCANalyzerandtheVN3600
FlexRayinterface.Theinterfacewasrequiredtocoldstartthenode.
AlltoolsandapplicationsusedwerepresentedinChapter10.
11.4.1 CANHardwareConfiguration
The CAN configuration was set up by connecting two CAN nodes together with CAN
specified cables and D9 connectors. A Tbus was used to splice off the CAN signal
which was fed into the CANcardXL adaptor card. This configuration is illustrated in
Figure116.
179
SyystemM
Model
Figure 11-66: CAN Physical Test Configuration
exRayHardw
wareConfigguration
11.4.2 Fle
AN configurration. Thiss
The FlexRay configurration was somewhat different from the CA
was to present a mo
ore realisticc bus structture configu
uration. Thee FlexRay passive
p
starr
ducedtodeemonstrate
etheextra configurationoptionsof FlexRayyoverCAN..
wasintrod
ThetradittionalCANcconfiguratio
onisthesin
nglebusstrructure.Tw
woFlexRayn
nodesweree
implemen
nted using the FlexRaay developm
ment kits. Both channels of FleexRay weree
utilised.ChannelAon
nnode1wasconnecteedwithchaannelAonn
node2viattheFlexRayy
passive sttar. Channeel B on nod
de 1 was connected
c
w
with chann
nel B on no
ode 2 via aa
separate passive star. The two channels cannot
c
be crossed
c
oveer because this would
d
cause thee CRC to flaag an errorr. Channel A and chan
nnel B on the
t passivee star weree
connected
dtotheVN
N3600FlexR
Rayinterface.Thephyssicallayerinterfacesaareinserted
d
into the designated slots (on the develo
opment boards) to meet
m
the sp
pecification
n
standardsforthephyysicallayer.TheFlexRayVN3600 interfacecconnectstothelaptop
p
viaaUSB connector anddataissextracted viaCANalyyzer.FlexRayy.Thecableesusedaree
thesameasfortheC
CANtestcasseexcepton
ne.Thisisthecablethatconnectssfromeach
h
passivestaarintotheFlexRayinteerface.CAN
Ncablesweresufficien
ntforthisteestcasebutt
in a case where wakke up symbols are tran
nsmitted it is recomm
mended to u
use FlexRayy
180
0
SyystemM
Model
specifiedccabling.WithoutthistthereisaprobabilitytthattheFlexRaysignallwouldnott
getdecod
dedcorrectly.Thiscablewassupp
pliedwithth
heFlexRay interface.TTheFlexRayy
testconfiggurationisiillustratedinFigure117.
Figure 11-7: FlexRay Phhysical Test Conffiguration
11.5 Softtware
The softw
ware requireed for impleementing the respectiive applicattions are prresented in
n
this sectio
on. One key software componen
nt is the ap
pplication ccode. This defines
d
thee
applications featurees such ass preceden
nce constrraints. The protocolss that thee
applications operatee on are ceentral to th
he research
h. These prrotocols aree CAN and
d
FlexRayan
ndarediscu
ussedindeepthinChap
pters3and4respectivvely.Thefeeaturesand
d
merits of each havee previouslyy been exp
plained in depth.
d
Each
h protocolss individuall
parameters are provvided throu
ugh the CAN controlleer for CAN application
ns, and thee
communiccation con
ntroller forr FlexRay application
ns. The A
ACC appliccation wass
implemen
ntedinCcode.Insituationswhereeadditionaldataisloaadedontotthebusthiss
data has been
b
generratedby CA
ANalyzer.FleexRay. This allowed fo
or the configguration off
themessaageID,perio
odandpaylload.Otherroptionsinccludehavingatransmiissioncyclicc
181
1
SystemModel
or transmission activated upon transmission of a defined message. The additional

frames (CAN or FlexRay) are not incorporated into the initial system design. This is
becausethisdataisusedtodemonstratehowFlexRayisabletohandleadditionaldata
quantities without adversely affecting the performance of the preconfigured ACC
applicationdata.
11.6 ExtractionMethod
TheCANapplicationisinitiallydefinedandrepresentedasataskgraph.Thenextstep
is to extract the parameters through the framework. In these three test cases the
initial CAN data figures were input to Microsoft Excel. This application was used
because it was easily accessible and simple to use. Calculations could be easily
processed and through the modification of any equations elements, this allowed for
any changes to propagate through all other equations that were associated with the
parameter. The graphing of data (such as payload data) was also carried out using
MicrosoftExcel.
11.7 VerificationofParameterConsistency
Verification is required before parameters can be accepted as valid. This is

accomplishedusingtheDECOMSYSdesignerapplicationwhosefeaturesareexplained
in Chapter 10. If the ideal parameters obtained from the framework are not
implementablethesewillbeexposedinthedesignertoolandtheimplementablevalue
isdisplayed.Ascanbethecase,thevalueobtainedfromtheframeworkmightneed
slight tweaking due to another constraints being violated. These constraints can be
calculated manually since each constraint and all the sub elements are presented in
appendixBoftheFlexRayspecificationsv2.1.
182
SystemModel
11.8 ValidationCheck
ToconfirmthatmigrationissuccessfulthedeadlinesofeachCANtaskarecompared
withthoseobtainedthroughtheFlexRayimplementation.Thisaloneisnotasufficient
checkastheapplicationdeadlinehastobemetalso.TheCANandFlexRayapplication
timesarecomparedinaddition.Busloadsareexaminedtodetermineifthereisalink
betweendeadlinesbeingmissedandincreasingbusloads.CANandFlexRaybusloads
areincreasedtodetermineifFlexRayhastheextraperformancecapacityithasbeen
claimedtopossess.
For test case three Verification of TimeTriggered Properties, verification is carried
outsolelythroughacomparisonofapplicationexecutiontimes
11.9 Conclusion
This chapter presents the structure, implementation and purpose of the three test
cases. The applications used in obtaining the results are presented along with the
configuration of the CAN and FlexRay test environment. The chapter concludes by
presentingthemethodsusedindeterminingifmigrationwassuccessfulandnecessary.
183
SystemModel
11.10 References
MADSEN,J.P.K.A.S.H.(2007)DesignOptimisationofFaultTolerantEventTriggered
EmbeddedSystems.INPOP,P.(Ed.)KongensLyngb.
RIIS,P.(2007)SimulationofaDistributedImplementationofanAdaptiveCruise
Controller.DepartmentofComputerandInformationScience.Linkoping
University.
YOICHIHORI,Y.T.A.Y.T.(1997)TractionControlofElectricVehicleBasedonthe
EstimationofRoadSurfaceCondition
184
FrameworkImplementationProcedure
12 Framework Implementation
Procedure:
12.1 Introduction
This chapter examines how the process of migration was defined and presents the
implementationprocedurethatwasundertakenforthethreetestcases.Theabstract
implementation is presented initially, followed by the experimental implementation
and finally, concluding with the verification of timetriggered properties
implementation. The abstract implementation is not implemented in the physical
developmentenvironment.ItprovidesanexampleofhowFlexRaysframeandcluster
parameterscanbeextractedfromthemigrationframework.Theresultsdeterminingif
migration is successful are presented in Chapter 13 only for the experimental
implementation that was applied to the development environment and test case
three,verifyingFlexRaystimetriggeredproperties.
12.2 Abstract(TC)Implementation(TestCase1)
Themodelchosenfortheabstractapplication(Figure121)presentedahighlevelof
complexity in relation to the number of branches and nodes it contained. While a
simpler task graph model (containing less branches and nodes) would also have
sufficed (see test case three), by using this more complex model the frameworks
strength in dealing with increased complexity is demonstrated. The associated
application task data was extracted from vehicles made available by the industrial
partner (SEWSE Ystrad). Choosing the CAN application is step one of the migration
frameworkdevelopmentstageasillustratedbyFigure121.
185
Figure 12-1: First

Framework Development
Stage
12.2.1 TaskGraphModel
Step two is task graph abstraction (Figure 122). The task graph model was adapted
from(Aloul,2005)andpresentedindetailinChapter11.Byusingthetractioncontrol
modelitpresentssufficientdetailinrelationtothenumberoftasksandbranches,to
provide a realistic structure. Figure 112 illustrates the traction control task graph
structure. The CAN bus speed of 125kbit/s is used in calculations. Calculations are
basedonFlexRaydatabusrateof10Mbit/s.
Figure 12-2 : Migration

Step Two
12.2.2 ParameterAnalysis
TheCAN datausedinthisabstractcasewasobtainedfromanelectricSmartCar(ST
data)andaPeugeot207(DYNdata).ThedatawasloggedusingCANalyzer.Thetimings
presented are actual task periods used in mass produced vehicles. This method of
obtaininginitialCANparametersdemonstrateshowtheframeworkcanoperateonce
the tasks parameters are presented in the message domain. This proves that the
frameworkssuccessisnotapplicationconfigurationdependant.Thisrelatestostage
threeoftheframeworkdevelopment(Figure123),extractingtheCANparameters.
186
Figure 12-3: Framework

Development Stage Three
12.2.3 ExecutionTime
Onefinalparameter,jitter,wasrequiredbeforeRTAcouldbeemployedtoobtainthe
CAN tasks WCETs. The jitter value varies depending on the CAN controller and also
variesforeachindividualmessage.SpecialistsequipmentsuchasthatbyAgilentand
Tecktronix can be bought that extract jitter times. This specialist equipment was not
readilyavailableduringthisresearch.Jittervaluesusedweretakenfrom(Burns,1994).
ThejittervalueswereobtainedfromtheIntel82527standaloneCANcontroller.Itwas
considered more appropriate to use real jitter values even if they had come from a
differentCANcontrollerthanjustrandomlyselectingjittertimes.Havingthemessage
periods and the message sizes (in bytes) allowed RTA to be use in determining the
WCETofthemessages.UsingEquation121aspresentedin(RobertI.Davis,2007)the
responsetimeiscalculated.ThisresponsetimeistakenastheWCETofeachtask.
Rt m = J m + wm + Cm
Equation121:TaskResponseTime
EachelementofEquation121isexplainedsection5.9.2.Theinitialdatarequiredto
obtain the response time is presented in Table 121. A CAN bus of 125kbit/s was
chosen.Thisresultsinabittimeof8s.Thecommunicationtimeofeachmessageat
theselectedsizeinbitsiscalculatedfromEquation122,aspresentedinTable121.
Cm = (55 + 10sm ) bit

Equation122:MessageTransmission/CommunicationTime
187
Table 12-1: Parameter Cm & Jm Identification
Task Period Message Stuffed

(ms)
Cm
Jm
Size
Message Size (ms)
(s)
(Bytes)
(Bits)
T1
135
1.08
600
T2
105
0.84
700
T3
135
1.08
400
T4
135
1.08
800
T5
85
0.68
1100
T6
125
1.00
900
Jittervaluesaretakendirectlyfrom(RobertI.Davis,2007)andareshowninTable12
1.TheblockingdelayBmiscalculatedasperEquation58andthequeuingdelaywmis
calculatedfromEquation510.Theinitialblockingdelayiszero.Duetothepossibility
ofmultipleiterationsthequeuingdelaywillnotbethesameineverycycletherefore
multipleiterationsarerequired.Thenumberofiterationswilldependonthenumber
ofcyclesrequiredtodeterminethattheWCRTvalueisnotcontinuallyincreasing.The
numberofdecimalplacesinthisvaluewillalsoaffectwhenavalueisdeterminedto
havenotchanged.Forexampleifonedecimalplaceisusedandavalue2.7msdoesnot
changeafterthedefinednumberofiterations,itcanbedeterminedthattheWCRTis
not continually increasing. If six decimal places are used instead it is observed that
betweenthefirsttwoiterationsthevaluechangesfrom2.766566msto2.778301ms,
thereby taking more iterations before it can be determined to have remained
constant. In this test case five iterations to six decimal places (values in ms) were
requireduntiltwoconsecutivevaluesdidnotchange.Table122displayswmqueuing
delaysthatareusedindeterminingtheresponsetimes.
188
Table 12-2: wm Five Iterations of the Queuing Delay
Queue W1(ms)
W2(ms)
W3(ms)
W4(ms)
W5(ms)
Delay
w1
1.086566
1.09830
1.098428
1.098429
1.098429
w2
1.089540
1.10127
1.101402
1.101403
1.101403
w3
1.093946
1.10568
1.105808
1.105809
1.105809
w4
1.102673
1.11440
1.114534
1.114536
1.114536
w5
1.104180
1.11591
1.116041
1.116043
1.116043
w6
1.113260
1.12499
1.125121
1.125123
1.125123
1 113493
1 12522
1 125355
1 125356
1 125356
OncethethreeparametershavebeenacquiredforEquation121thisallowstheWCRT
for eachmessage to be calculated.The figures requiredare presented in Table 123.
There are five iterations provided as this is the point at which the response time
stabilises.
Table 12-3: Worst Case Response Time
Msg Rtm1
Rtm2
Rtm3
Rtm4
Rtm5
(ms)
(ms)
(ms)
(ms)
(ms)
m1
2.766566
2.778301
2.778428
2.778429
2.778429
m2
2.629540
2.641275
2.641402
2.641403
2.641403
m3
2.573946
2.585681
2.585808
2.585809
2.585809
m4
2.982673
2.994408
2.994534
2.994536
2.994536
m5
2.884180
2.895915
2.896041
2.896043
2.896043
m6
3.013260
3.024995
3.025121
3.025123
3.025123
m7
2 293493
2 305228
2 305355
2 305356
2 305356
189
FrameeworkIImplem
mentatio
onProceedure
12.2.4 CalculatingSlack
Theslack requirescaalculatingan
ndreallocattingtoobtaainthefinalintermediatereleasee
(ri) and deeadline (di) times. Thee initial ri time
t
is zero
o ms and th
he final deaadline Di iss
2.6second
ds. Di is ob
btained by summing all
a task perriods. The sslack on eaach path iss
illustrated
dinTable1
124.Oncettheslackperpathiskknown,the riandditimesofthee
intermediatetaskscaanbeobtain
ned.PathP
P4isthelon
ngestpaththroughtheetaskgraph
h
(Figure12
24).
Figure 12-4: Path P4 on tthe Traction Conttrol Model
Theappliccationdeadlineis2.6secondswhiichisobtain
nedbysummingthetaaskperiods.
Table 12-4: Obtaining

O
Slack
TotalEExecution
FinalSlacckperPath
Time(ms)
perTaask(ms)
T1,T5,T8,T9
10.38797
6477.4030
P2
T2,T5,T8,T9
T
10.25094
6477.4373
P3
T3,T5,T8,T9
T
10.19535
64774512
P4
T4,T5,T8,T9
T
10.60407
6477.3490
P5
T1
1,T5,T8,T10
10.10858
6477.4729
P6
T2
2,T5,T8,T10
9.971552
6477.5071
P7
T3
3,T5,T8,T10
9.915958
6477.5210
P8
T4
4,T5,T8,T10
10.32468
6477.4188
Path
TasksonPath
h
P1
190
0
12.2.5 FinalTaskGraphParameters
The recalculated ri and di values are presented in Table 125. These figures include
slackreallocation.
Table 12-5: Task Graph Parameters
WCET
Task (ms)
Slackper
ri(ms)
di(ms)
task(ms)
T1
2.778429
0.000000 2.778429 647.4030
T2
2.641403
0.000000 2.641403 647.4373
T3
2.585809
0.000000 2.585809 647.4512
T4
2.994536
0.000000 2.994536 647.3490
T5
2.896043 2.994536E 656.2341 647.3490
T6
3.025123
0.000000 3.025123 647.5071
T7
2 305356
0 000000 2 305356 647 5210
The first validation check performed as per Equation 97 can be carried out. These
results are displayed in Table 126. A green box represents a valid configuration and
redboxrepresentsaninvalidconfiguration.
Table 12-6: Final Task Graph Parameters
Recal
ri Recalc
di ValidationCheck(ms)
Task (ms)
(ms)
T1
0.000000
650.1814
2.778429<650.1814
T2
0.000000
650.0787
2.641403<350.0787
T3
0.000000
650.0370
2.585809<650.0370
T4
0.000000
650.3435
2.994536<650.3434
T5
650.3435
1300.589
2.896043<(1300.589650.3435)
T6
0.000000
650.5322
3.025123<650.5322
T7
0 000000
649 8264
2 305356<649 8264
ThefiguresinTable126areusedinmigratingtoFlexRay.Thisisstagefour(Figure12
5)inthemigrationdevelopmentflowchart.
191
Figure 12-5:
Flowchart
Development Stage
Four
12.2.6 MessageDeadlines
Each messages transmission deadline is represented by Equation 98 and the

transmissiondelayisgiveninEquation99.Thetransmissiondelayisthedelayonthe
CANbus.ThesevaluesarepresentedinTable127.
Table 12-7: Message Deadlines
Transmission
Transmission
Deadline(ms)
Delay(s)
m1
647.4030
512
m2
647.4373
32
m3
647.4512
512
m4
647.3490
512
m5
647.3490
192
m6
647.5071
448
m7
647 5210
512
12.2.7 PayloadConfiguration
Sections 12.2.7 to 12.3.2 are required for stage five of the migration as per the
flowchart(Figure126).
192
Figure 12-6 : Stage Five Development
TheCANmessagesizeswerepresentedinTable121.ForthisFrameworkanoverhead
sizeof14Bytesisconfigured.Thiscomprisesof;
5BytesHeader
3BytesCRC
4 Bytes Clock and Security (there is a minimum variance required between

messagesfromdifferentnodessothereisnooverlap.Includesasafetymargin
of4s)
2BytesTSS
ThetotalFlexRayframesizeiscomposedoftheoverheadandthepayload.Thetotal
number of frames required to transmit the entire payload data at a chosen payload
sizecanbefound.Thisfigureisroundeduptothenearestintegervalue.Thisvaluecan
beusedtodeterminethetotaldatafortransmissionincludingpayloadandoverhead
data. These figures are presented in Table 128. The number of messages required
column is presents how many FlexRay messages would be required to transmit the
CANdataatthechosenpayload.Thisincludesalloverheads.Itiscalculatedbydividing
theCANpayloadbytheFlexRaypayload.
193
Table 12-8: Payload Calculations
FlexRay
Number of
Frame
Messages
Size
Required
15
65
975
16
34
544
17
25
425
18
18
324
19
17
323
20
17
340
21
16
336
22
10
220
23
10
230
10
24
10
240
11
25
10
250
12
26
10
260
13
27
10
270
Payload
Size
Total
Bytes
By focusing specifically on the FlexRay frame in the abstract implementation the

payload is configured as a twobyteword. This allows only even payload values be
consideredforconfiguration.This resultsinEquation123.Theconditionmax occurs
oncetherehavebeentenconsecutiveinstancesofDincreasing.
D = Frame Size Cf FR
Forevenpdjvaluesof pd j = { j < j + 1...... j + 10}
Equation123:RevisedTotalFlexRayData
BygraphingtheCycleDataversusPayloadSizeresultsinthegraphinFigure127.
194
PayloadValue
1200
TotalData(Bytes)
1000
800
600
400
200
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
PayloadSize(Bytes)
Figure 12-7: Payload Graph Profile
Apayloadsizeof12Bytesresultsinaframesizeof26Bytesbeingchosen.TheFlexRay
busspeedisspecifiedat10Mbit/s.
12.2.8 StaticSlotSize
ThesizeofthestaticslotiscalculatedasperEquation913andisverifiedbelow.
12 Bytes + 14 Bytes
gdStaticSlot =
10 Mbit / s
26 Bytes
gdStaticSl ot =
= 21s
10 Mbit / s

At a payload size of 12 Bytes the smallest configurable ST slot size is 35s due to
configurationrestrictionsoftheDECOMSYSdesignerprogram.
195
12.2.9 Discretising
Thesmallestmessageperiodwhosevalueisobtainedfromtheminimumtd(mi)value
is 647ms, rounded down. With each ST slot size of 35s this results in a discretised
td(Mi)valueof18485slots.
12.2.10
PeriodicityandDistanceRequirement
To configure theFlexRay frame and the STsegment soas toassist theDYN segment
data in gaining access to the bus, the message periods are modified as explained in
section9.8.6.
Tomeettheserequirementsthepminvalueismodified(downfrom647ms)to640ms.
ThisresultsinaminimumFlexRayframeof1.25s.With10STslotsof35seach,the
outcomeisaSTsegmentsizeof350s.ThiscoupledwithanNITof21MTandeachMT
being1s,resultsinaDYNsegmentsizeof879s.
Provingthatandframesizemeetstheperiodicityanddistancerequirement:
1.25ms2.5ms5ms10ms20ms40ms80ms160ms320ms640ms
Equation915providesaformalvalidationasalsoprovenbelow.
29 1.25ms 640ms < 210 1.25ms
640ms 640ms < 1280ms
196
12.3 DynamicSegmentVerification
TheDYNsegmentcalculationsarebasedon(TraianPop,2006)andexplainedindetail
insection9.9.WithaDYNsegmentsizeof879sandaminislotsizeof6sthisresults
in146minislots.Thisnumberof146minislotsallocatesenoughslotstotransmiteach
DYNmessage.Thereisenoughcapacitytoincreasetheminislotsizeifrequired.
12.3.1 InitialDynamicData
TheinitialCANdatafortransmissionintheDYNsegmentispresentedinTable129.
Table 12-9: Initial Dynamic Data
CAN
Task
Message
Size
(Bytes)
Stuffed
Task
Message
Period
Size(Bits)
(ms)
T1
135
20
T2
135
20
T3
135
10
T4
135
20
T5
135
20
T6
135
20
T7
135
20
T8
135
20
12.3.2 DynamicSegmentAnalysis
TheStuffedMessageSizecolumnwascalculatedasperstuffedmessagesizesinTable
121.ThedynamicsegmentRTAiscarriedoutusingamodifiedversionofEquation12
1asrepresentedbyEquation124.
197
Rm (t ) = C m + m + wm (t )
Equation124:ResponseTimeAnalysisEquation
ThevalueCm(Table1210)canbecalculatedaspertheSTsegmentusingthebittime.
First the total FlexRay data including the overhead is calculated. The overhead is
calculated using the same method as that used for ST segment data. Once the total
communicationtimeofallFlexRaydataisknow,itcanthenbeassessedwhetherthere
isenoughtimeallocatedintheDYNsegmentforthetransmissionofallDYNdatainthe
best case scenario, with no delays. Column two, FlexRay frame size, includes any
overhead.Thebittimeis0.1s.
Table 12-10: Dynamic Communication Time
Message
FlexRayframeSize
(Bytes)
Cm(s)
m1
22
17.6
m2
22
17.6
m3
22
17.6
m4
22
17.6
m5
22
17.6
m6
22
17.6
m7
22
17.6
m8
22
17.6
m9
20
16.0
TotalCm(s)
204.8
The total communication time of 204.8s is obtained from equation 125 where n is
thenumberofDYNmessages.
TotalDYN C m = (C m1 KC mn )
Equation125:TotalDYNCommunicationTime
This provides enough time to transmit the DYN data if no blocking occurs. There are
879savailablepercycle.
198
Thenextvaluefordefiningism,thedelaycausedbyamessagebeinggeneratedjust
afteritsslothaspassed.ThisresultsinEquation126.
Equation126:mDelay
Theparametersforeachmessagedelaymandassociatedparametersareshownin
Table1211.
Table 12-11: m Parameters
Message
(s)
NIT m
(s) (s) (s)
m1
17.6
861.40
m2
17.6
861.40
m3
17.6
861.40
m4
17.6
861.40
m5
17.6
861.40
m6
17.6
861.40
350 17.6
21 861.40
m8
17.6
861.40
16 0
863 00
m7
FR(t)(s) STbus Cm
1250
Thefinaldelayvariableforcalculationiswm,thedelaycausedbythetransmissionof
STmessagesandhigherpriorityDYNmessages.ThisisillustratedinEquation127.
Equation127:wmDelay
Thewm(t)parametersarepresentedinTable1212.
199
Table 12-12: wm(t) Parameter
Message
hp(m)
pLatestTx.gdminisl
(s)
ot(s)
Ms(m)(s)
wm(t)
(s)
m1
0.0000
48
0.0000
419
m2
17.600
48
6.0000
443
m3
35.200
48
12.000
466
m4
52.800
48
18.000
490
m5
70.400
48
24.000
513
m6
88.000
48
30.000
537
m7
105.60
48
36.000
561
m8
123.20
48
42.000
584
m9
140 80
48
48 000
608
The pLatestTx value was 138 minislots, which was obtained from the designer tool.
SubtractingpLatestTxthisfromthetotalnumberofminislots(146)resultsinavalueof
8 minislots. These 8 minislots are unusable for transmission. Using Equation 923
allowsthems(m)valuetobeobtained.
To obtain the final worst case response time, sum the three parameters (Cm, m and
wm)foreachmessage.ThisgivestheresultingdelaysasdisplayedinTable1213.
Table 12-13: Dynamic Response Times
Message
Cm
(s) (s)
wm(t) Rm(t)
Frame
(s)
Cycles
(ms)
m1
17.6 861.40
419
1.2980
1.0384
m2
17.6 861.40
443
1.3216
1.05728
m3
17.6 861.40
466
1.3452
1.07616
m4
17.6 861.40
490
1.3688
1.09504
m5
17.6 861.40
513
1.3924
1.11392
m6
17.6 861.40
537
1.4160
1.1328
m7
17.6 861.40
561
1.4396
1.15168
m8
17.6 861.40
584
1.4632
1.17056
200
12.4 FinalAbstractCaseParameters
Usingtheframework,migrationisundertakencommencingwiththeCANapplication
as illustrated in Figure 112. The FlexRay parameters are obtained by following the
proceduralsteps.TheFlexRayparametersobtainedare:
FrameLength(1250s)
StaticSegmentSize(350s)
PayloadSize(62bytewords)
StaticSlotSize(35s)
NIT(21s)
DYNSegmentSize(879s)
TheParametersastheyareconfigurableinthedesignertoolareillustratedinFigure
128.
Figure 12-8: Configured Abstract Parameters
201
FromtheframeworkaFlexRayframesizeof1.25msisacquired.Thisiscomposedofa
STsegmentof350s(10slotsofsize35s),aDYNsegmentsizeof879s(146slotof
6sinsize)andaNITof21s.
These parameters would be used to configure the FlexRay frame but this step is not
implementedinthistestcase(itisusedintestcasestwoandthree).
12.5 ExperimentalImplementation(ACC)(TestCase2)
While the above traction control model proved that it is possible to successfully
abstract the parameters necessary to configure a FlexRay frame, these results were
not implemented in hardware. This is required to back up the claim that the
parameters obtained allow a FlexRay application to operate successfully meeting
deadline, timing and busload constraints. This is proven using an Adaptive Cruise
Control(ACC)system.Acompletelynewapplication,thatresultedinadifferent(tothe
Traction Control application previously used) task graph configuration, was used to
demonstrate that the previous migration was not a once off chance occurrence. The
resultsvalidatingdeadlinesandbusloadsarepresentedinChapter13.
TheACCmodelusedisalsofoundin(Madsen,2007)and(Riis,2007).Themodelwas
modified slightly to increase the complexity. By adding a precedence constraint that
themessagesofTask1andTask2(inanyorder)havetobereceivedbyTask3before
Task3canproceed.ThisresultsintheACCtaskgraphasillustratedinFigure113.The
CAN bus bit rate is 125kbit/s and the FlexRay bus used is specified at a bit rate of
10Mbit/s
202
In (Madsen, 2007) the author provides the WCET values. The initial CAN parameters
used in this testcase are presented in Table 1214. The maximum messagesizes are
usedinallmessages.Theinitialreleasetimeriis0msandthefinaltaskgraphdeadline
Diis120ms.
Table 12-14: CAN Initial Parameters
Task WCET Deadline Period Size

(ms)
(ms)
(ms)
Node
(Bytes)
T1
20
20
T2
20
20
T3
20
20
T4
20
20
Thetaskswereassignedtoanodeonthebasisofthefunctionperformed.Theaction
taskswereplacedonnode1andthecomputationaltaskswereplacedonnode2.
12.5.2 IntermediateTaskValues
To be able to find the intermediate task deadlines the slack requires reallocation
equally among all tasks. There are only two possible paths in this task graph
configuration.Table1215presentstheslackpertaskoneachpath.
Table 12-15: Obtaining Slack Parameter
FinalSlackperPathperTask
Path
TasksonPath
TotalExecutionTime(ms)
P1
T1,T3,T4,T5,T6
16
17.3333
P2
T2 T3 T4 T5 T6
16
17 3333
(ms)
203
AscanbeseeninTable1216aslackof17.33msistobereallocatedequallyamongall
tasks.
Task
WCET(ms)
Ri(ms)
Di(ms)
Slack(ms)
T1
17.3333
T2
17.3333
T3
17.3333
T4
17.3333
6
T5
8
14
17.3333
Equation97verifiesthetaskgraphparametersasillustratedinTable1217.
Task Recalri(ms)
Recalcdi(ms)
ValidationCheck(ms)
T1
17.3333
0<17.33333
T2
17.3333
0<17.3333
T3
34.6666
57.6666
6<(57.666634.6666)
T4
57.6666
76.9999
2<(57.999976.9999)
76 9999
100 3333
6 (100 3333 76 9999)

transmissiondelayisgiveninEquation99.ThesevaluesarepresentedinTable1218.
204
Transmission
Transmission
Deadline(ms)
Delay(s)
m1
17.333
512
m2
17.333
512
m3
17.000
512
m4
17.333
512
The overhead is defined as 14 Bytes as specified in section 12.2.7. As previous, the

payloadischosenheuristicallydependingonthetotalnumberofbytestransmittedper
payloadandframesize.Table1219presentsthepayloadcalculations.
205
FlexRay
Number of
Frame
Messages
Size
Required
15
40
600
16
20
320
17
15
255
18
10
180
19
10
190
20
10
200
21
10
210
22
110
23
115
10
24
120
11
25
125
12
26
130
13
27
135
Payload
Size
Total
Bytes
GraphingtheCycleDataversusPayloadSizeresultsinthatgraphinFigure129.
206
PayloadValue
700
TotalData(Bytes)
600
500
400
300
200
100
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
PayloadSize(Bytes)
The payload size of 10 Bytes is chosen which results in a frame size of 24 Bytes
includingthecalculatedoverhead.
12.5.5 StaticSlotSize
The size of the static slot is calculated as per Equation 913 and verification is
presentedbelow.Aslotsizeof19.2sisobtainedbutthisisroundedupto20s.
10 Bytes + 14 Bytes
gdStaticSlot =
10 Mbit / s
24 Bytes
gdStaticSl ot =
= 20 s
10 Mbit / s

At a payload size of 10 Bytes the smallest configurable ST slot size obtained using
DECOMSYS designer is 33s. For the purpose of implementation a static slot size of
207
40s is chosen as it allowed a uniform fit for slot delays, otherwise a ST slot size of
33sischosen.
12.5.6 Discretising
Thesmallestmessageperiodwhosevalueisobtainedfromtheminimumtd(mi)value
is14ms.WitheachSTslotsizeof35sthisresultsinadiscretisedtd(Mi)valueof400
slots.
12.5.7 PeriodicityandDistanceRequirement
ToconfiguretheFlexRayframeandtheSTsegment,soastoassisttheDYNsegment
data gaining access to the bus, the message periods are modified as explained in
section9.8.6.
To meet these requirements the pmin value of 14ms is chosen. This results in a
minimum FlexRay frame of 1.75ms. With 6 ST slots of 40s each this results in a ST
segment size of 240s. This coupled with an NIT of 25MT with each MT being 1s,
resultsinaDYNsegmentsizeof1485s.
Provingthatandframesizemeetstheperiodicityanddistancerequirement:
1.75ms3.5ms7ms14ms
Equation9.15providesaformalvalidationasprovedbelow.
23 1.75ms 14ms < 2 4 1.75ms
14ms 14ms < 28ms
208
12.5.8 DynamicSegmentVerification
Thedynamicsegmentsizeis1485sasworkedoutintheprevioussection.Thisworks
outat247minislotswitheachminislotsize6MTs.EachMTis1s.Thereareonlytwo
tasks transmitted in the DYN segment. There are enough slots allocated for the
numberofmessages.Eachmessageisconfiguredtobe4Bytesinsize.
12.5.9 InitialDynamicCANData
CAN data was assigned on the basis that at a minimum of one task would be
designatedtoeachnode.Thisformatwaschosentoguaranteeonedynamicmessage
wouldbetransmittedonthebusfromeachnode.Thedynamictaskswereconfigured
totransmitatsemitimeswithinadefinedrange.Thisrangewasbetween020ms.This
aspect was implemented to demonstratethat dynamic messages could getaccess to
thebusregularlyoneithernodeatrandomtimes.
12.6 DynamicSegmentAnalysis
RTAiscarriedoutusingEquation128.
Rm (t ) = C m + m + wm (t )
Equation128:ResponseTimeAnalysisEquation
ThevalueCmcanbecalculatedaspertheSTsegmentpreviously.FirstthetotalFlexRay
data including the overhead is required. The overhead is calculated using the same
methodappliedintheSTsegment.Thisresultsinanoverheadof14Bytes.Oncethe
totalcommunicationtimeofallFlexRaydataisknowitcanthenbeassessedwhether
thereisenoughtimeallocatedintheDYNsegmentforthetransmissionofallDYNdata
in the best case scenario with no delays. Column three, FlexRay frame size, includes
anyoverhead.ThisisshownincolumnthreeinTable1220.
209
Table 12-20: Aperiodic CAN Data
Message
m1
FlexRay
FlexRay
Cm
TotalCm(per
BitTime
Size(Bytes)
(s)
Node)(s)
18
17.6
0.1s
14.4
Thetotalcommunicationtimeof14.4spernodeallowsenoughtimetotransmitthe
DYNdataifnoblockingoccurs.Thereare1485savailable(intheDYNsegment)per
cycle.
Thenextvaluefordefiningism,thedelaycausedbyamessagebeinggeneratedjust
afteritsslothaspassed.ThisresultsinEquation129.
Equation129:mDelay
Theparametersforeachmessagedelaymandassociatedparametersareshownin
table1221.
Table 12-21: m Parameters
Message
m1
FR(t)(s) STbus Cm(s) NIT

(s)
1750
240
m(ms)
(s)
14.4
1.4806
25
ThefinaldelayvariableforcalculatingiswmthedelaycausedbythetransmissionofST
messagesandhigherpriorityDYNmessages.ThisisshowninEquation1210
Equation1210:wmDelay
210
Table 12-22: wm(t) Parameter
hp(m) STbus pLatestTx.

Message (s)
(s)
NIT(s)
gdminislot
ms(m) wm(t)
(s)
(s)
(s)
m1
48
0 0000
303
The pLatestTx value was 239 minislots which was obtained from the designer tool.
SubtractingpLatestTxthisfromthetotalnumberofminislots(247)resultsinavalueof
8minislots.These8minislotsareunavailablefortransmission.Equation922produces
thems(m)value.
To obtain the final worst case response time, sum the three parameters (Cm, m and
wm)foreachmessage.ThispresentstheresultingdelaysasdisplayedinTable1223.
Table 12-23: Dynamic Response Times
Message
m1
2
Cm
(s) (s)
wm(t) Rm(t)
Frame
(s)
Cycles
(ms)
14.4 1480.6
303 1.7980
14 4
317
1.027429
12.7 FinalExperimentalCaseParameters
TheFlexRayparametersobtainedfortheexperimentalimplementationcaseare:
FrameLength(1750s)
PayloadSize(52wordbytes)
StaticSlotSize(40s)
NIT(25s)
DYNSegmentSize(1485s)
Figure1210illustratestheparametersastheyappearusingtheFlexRayconfiguration
designertool(DECOMSYSdesigner).
211
The final FlexRay frame size is 1.75ms. This is composed of a ST segment of six slots
40sinsize,aDYNsegmentof247slots6sinsizeandfinallyaNITof25s.
These final case parameters are used in stage six (Figure 1211) of the migration
framework development. These parameters are used to configure the FlexRay
applicationsparametersthatwereimplementedinthedevelopmentenvironment.The
resultsofthisimplementationarepresentedinChapter13.
Figure 12-11: Framework Development Stage

Six
212
12.8 VerificationofTimeTriggeredProperties(TestCase3)
This test case was configured to demonstrate that bus loading would not have an
adverseeffectontheexecutiontimeofanapplicationconfiguredtooperateontheST
segment of the FlexRay protocol. For this verification it is required to assign all
application data to the ST segment. This is due to the ST segment containing time
triggered properties. The task graph model is presented in Figure 115. The results
validating deadlinesand busloads are presented in Chapter 13. TheCAN bus bit rate
usedis125kbit/sandtheFlexRaybusbitrateusedisspecifiedat10Mbit/s
TheWCETparametersareinkeepingwiththoseusedintheprevioustwotestcases.
The initial CAN parameters used in this test case are presented in Table 1224. The
maximum message payload size is used in all messages. The initial release time ri is
0msandthefinaltaskgraphdeadlineDiis40ms.
Table 12-24: CAN Initial Parameters Test Case Three
Task WCET Deadline Period Size

(ms)
(ms)
(ms)
(Bytes)
T1
T2
T3
T4
T5
213
FrameeworkIImplem
mentatio
onProceedure
es
12.8.2 InttermediateTaskValue
he intermed
diate task d
deadlines th
he slack neeeds to be reallocated
d
To be able to find th
equally am
mong all taasks. There are is onlyy one possib
ble path th
hrough this task graph
h
configurattion(Figure1212).
Figuree 12-12:
Path Through
T
Taskk Graph
Table122
25presentsstheslackp
pertaskoneeachpath.
Taable 12-25: Obtainning Slack Param

meter
Path
P1
TTasksonPaath
T
T1,T2,T3,T4,
T5,
T6 & T7
TotalExecutionTime(ms)
28
FinalSlaackperPath
hperTask
(ms)
1.714
AsillustratedinTable1226asslackof1.714msisto bereallocaatedequallyyamongalll
tasks.
214
4
Task
WCET(ms)
Ri(ms)
Di(ms)
Slack(ms)
T1
0.000
5.714
1.714
T2
5.714
11.429
1.714
T3
11.429
17.143
1.714
T4
17.143
22.857
1.714
T5
22.857
28.517
1.714
Equation97verifiesthetaskgraphparametersasillustratedinTable1227.
Task Recalri(ms)
Recalcdi(ms)
ValidationCheck
T1
0.000
5.714
0<5.714
T2
5.714
11.429
5.714<11.429
T3
11.429
17.143
11.429<17.143
T4
17.143
22.857
17.143<22.857
T5
22.857
28.517
22.857<28.517

transmissiondelayisgiveninEquation99.ThesevaluesarepresentedinTable1228.
215
Transmission
Transmission
Deadline(ms)
Delay(s)
m1
1.714
512
m2
1.714
512
m3
1.714
512
m4
1.714
512
m5
1 714
512
Theoverheadisdefinedas14Bytesasspecifiedinsection12.2.7.Asinprevioustest
cases the payload is chosen heuristically depending on the total number of bytes
transmittedperpayloadandframesize.Table1229presentsthepayloadcalculations.
FlexRay
Number of
Frame
Messages
Size
Required
15
56
840
16
28
448
17
21
357
18
14
252
19
14
266
20
14
280
21
14
294
22
154
23
161
10
24
168
11
25
175
12
26
182
Payload
Size
Total
Bytes
216
GraphingtheTotalDataversusPayloadSizeresultsinthegraphinFigure1213.
PayloadValue
TotalData(Bytes)
1000
800
600
400
200
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
PayloadSize(Bytes)
The payload size of 14 Bytes is chosen which results in a frame size of 28 Bytes
includingthepredeterminedoverheadStaticSlotSize
ThesizeisthestaticslotiscalculatedasperEquation913andisverifiedbelow.Aslot
sizeof22.4sisobtainedbutthisisroundedupto23s.
14 Bytes + 14 Bytes
gdStaticSlot =

10Mbit / s
28 Bytes
gdStaticSl ot =
= 23s
10 Mbit / s
At a payload size of 14 Bytes the smallest configurable ST slot size using DECOMSYS
designeris37s.Beingunabletosetthestaticslotsizetothefigureextractedfromthe
framework,thisintroducesredundancyintoeachstaticslot.
217
12.8.6 Discretising
Amessagedeadlinedelaytd(mi)valueof1.7msisextractedfromtheframework.Each
ST slot is of size 37s, this results in a discretised td(Mi) value of 459 slots as per
equation914.
12.8.7 PeriodicityandDistanceRequirement
ToconfiguretheFlexRayframeandtheSTsegment,soastoassisttheDYNsegment
data in gaining access to the bus the message periods are modified as explained in
section 9.8.6. For this test case all data used for loading the bus is placed in the ST
segment. This resulted in four extra messages being added to the bus. This
configuration demonstrates that by adding extra data in the ST segment the timing
deadlinesoftheapplicationarenotaffected.Thefourextramessageswereassigned
thehighestidentifierspossibletofurtherdemonstratethatthisdoesnotaidaccessto
thebus.DYNslotswereconfiguredbutunusedforthepurposeofdemonstratingtheir
potentialuse.
Tomeettheserequirementsthepminvalueof1.024msischosen(refertosection9.8.6
forfurtherdetails).ThisresultsinaminimumFlexRayframeof512s.TheSTsegment
comprised of 11 ST slots of 37s each, resulting in a ST segment size of 407s. This
coupledwithanNITof18MTwitheachMTbeing1s.ThisresultsinaDYNsegment
sizeof87s.
Provingtheframesizemeetstheperiodicityanddistancerequirement:
0.512ms1.024ms
Equation9.15providesaformalvalidationasprovenbelow.
21 0.512ms 1024ms < 2 2 0.512ms
1.024ms 1.024ms < 2.048ms

218
InthistestcasethereisnoDYNsegmentverification.WhileDYNslotswereincludedin
the configuration this was done to demonstrate that they could be included if
required.ImplementingtheDYNsegmentwouldnotaddtothistestcaseduetothe
DYN segment being eventtriggered and the purpose of this test case was to
demonstrateFlexRaystimetriggeredproperties.
12.9 FinalPracticalCaseParameters
TheFlexRayparametersobtainedforthepracticalimplementationcaseare:
FrameLength(512s)
PayloadSize(72wordbytes)
StaticSlotSize(37s)
NIT(18s)
DYNSegmentSize(87s)
Figure1214illustratestheparametersastheyappearusingtheFlexRayconfiguration
designertool(DECOMSYSdesigner).
219
ThefinalFlexRayframesizeis512s.ThisiscomposedofaSTsegmentofelevenslots
37s in size, a DYN segment of 14slots 6s in size and finally a NIT of 18s. These
parameters are used to configure the FlexRay application. The results of this
implementationarepresentedinChapter13.
12.10 Conclusion
Thischapterpresentstheactualmigrationinthecontextofapplyingfactsandfigures
to the abstract case. There are three test cases presented; The Abstract
Implementation, The Experimental Implementation and The Verification of Time
TriggeredProperties.
Theabstractimplementation(TC)demonstratedtheabilityoftheframeworktohandle
a complex structured application with complex constraints. The Experimental
220
implementation(ACC)demonstratedtheframeworksabilitytohandlerealconstraints
and also the frameworks flexibility in handling a different scenario application. The
third test case, Verification of TimeTriggered Properties, simply assigns data (both
fromtheapplicationandloadeddata)totheSTsegment.Adifferenttaskgraphisalso
processed through the framework compared to the previous two test cases. This
chapter presents the parameters necessary to configure a FlexRay frame for all test
cases.
To assess the frameworks success in delivering parameters that are capable of

producing a successful FlexRay configuration; task, application and deadlines are
required.ThesearepresentedundervaryingbusloadsinChapter13.
221
12.11 References
AloulNKaF,2005,TheSynthesisofDependableCommunicationNetworksfor
AutomotiveSystems,SAEInternalional2005,
BurnsKTaA,1994,GuaranteeingMessageLatenciesonControlAreaNetwork(CAN).
MadsenJPKaSH,2007,DesignOptimisationofFaultTolerantEventTriggered
EmbeddedSystems,
RiisP,2007,SimulationofaDistributedImplementationofanAdaptiveCruise
Controller,DepartmentofComputerandInformationScience,Linkoping
University
RobertI.DavisAB,ReinderJ.BrilandJohanJ.Lukkien,2007ControllerAreaNetwork
(CAN)SchedulabilityAnalysis:Refuted,RevisitedandRevised
TraianPopPP,PetruElses,ZeboPeng,AlexandruAndrei,2006,TiminigAnalysisofthe
FlexRayCommunicationProtocol,Editor,ConferenceName,Conference
Location.
222
TestResults&Verification
13 Test Results & Verification:
13.1 Introduction
Chapter12presentedtheparametersasextractedfromthemigrationframeworkafter
undergoing themigrationprocedure.TheAbstractImplementation(TC)(TestCase1)
(Section 12.2) demonstrated the frameworks success at extracting results from a
complex application scenario. The Experimental Implementation (ACC) (Test Case 2),
whilehavingreducedcomplextaskgraphstructure,theACCmodeldemonstratedthe
generality of the framework under diverse conditions. The Verification of Time
Triggeredproperties(TestCase3)presentedanotherdiversetaskgraphstructure.To
fully verify the migration procedure the Experimental Implementation was
implementedintestingenvironment.
The ACC application was implemented in both CAN and FlexRay separately on the
FujitsuSK91F467DdevelopmentboardsasperthesystemdesignspecifiedinChapter
11.TheframeworkisconsideredsuccessfuliftheCANapplicationisconfiguredonthe
FlexRay protocol. Verification was carried out by obtaining message and application
deadlinesundervariousbusloadconditionsandcomparingtheresultsobtainedfrom
the CAN and FlexRay implementations. The FlexRay application was tested without
redundancyconfigured(onlyCHAtransmitstheACCdata)andwithredundancy(ACC
data is transmitted on CH A and CH B) to verify that it does not adversely affect
timings.
The third test case results were obtained by configuring the CAN and FlexRay
configurationsusingCANalyzersblockgeneratorfunction.Thetestcaseisconsidered
successful if the FlexRays applications timings are not affected by increases to the
busload.
223
13.2 TestCase2: ACCConfiguration
The node configuration is illustrated in Figure 131 and 132. The same tasks are
assigned to the same nodes for the CAN and FlexRay implementations. All busload
dataisrecordedovera30secondperiodandtheCANbusoperatesat125kbit/swhile
FlexRayoperatesat10Mbit/s.Wherea30secondsampleperiodisnotrequireda30
cycleperiodsufficesinsuchinstances.
The messages ID1ID6 (ACC application messages) are assigned to the ST segment in
FlexRaybecausetheyareconsideredcriticalandID7andID8areassignedtotheDYN
segmentduetothembeingperceivedlesscriticalthantheapplicationdata.
The Standard Configuration is illustrated in Figure 131: The red lines indicate the
messagesthataretransmittedacrossthebus.
Figure 13-1: Standard Task Nodal Assignment
224
T
TestRe
esults&
&Verificcation
mal Configguration is illustrated in Figure 132: Thee red lines representt

The Minim
communiccationacrossthebus. Thebluelinesareon
nlyforcomm
municationwithinthee
node.
Figurre 13-2: Minimal Task Nodal Assignment
This chaptter completes stage seven

s
of the framewo
ork development as illustrated in
n
Figure133.
Figure 13-3: Stage

Sevenn of the
Fram
mework
Devellopment
NResults
13.3 CAN
TheCANttestcasesw
weredivided
dintotwossubsectionsstoprovideemorecom
mprehensivee
testing;
225
5
CANStandardInthiscasealldataistransmittedacrossthebus.Itispossible
anothernodeorapplicationcouldpotentiallyrequirethisdata.SeeFigure131.
CAN Minimal In this minimal configuration only the data required by inter
communicating nodes is transmitted. All intra communicating data is not
transmitted.SeeFigure132.
CANalyzer detects a message when it appears on the bus; this is not necessarily the
startoftheapplicationcycle.Theapplicationcyclestartswhenthefirstmessageinthe
applicationisgenerated.IntheCANtestcasesitisassumedthattheapplicationcycle
starts919sbeforethefirstmessageappearsonthebus.Thisvalueof919sischosen
because this is the time worked out for a message to appear on the bus after it has
beengenerated.BecauseTestcase1wascompletelytheoreticalnophysicaltestingis
required.AllresultsthatfollowareforTestsCases2and3.
13.3.1 TestCase2: CANStandardCases

Test Case2 results are split into CAN and FlexRay results. A further subdivision is
createdwhereresultsaredividedintocategoriesCase1,2forCANand3,4forFlexRay
andthefinaldivisionisintoA,B,CforCANandA,B,CandDforFlexRaydependingon
loadlevels.TheFlexRaysubcategoriesareexplaininaparagraphpriortotheresults
beingpresented.
TestCase3isdividedintotwocategories,CANandFlexRay.
13.3.1.1
CASE1A:NormalLoad
In this test case the total bus load is averaging at 33.09% for all CAN messages. The
individualbreakdownispresentedinTable131
226
Table 13-1: Normal Busload
Msg
Minimum Maximum Average
ID
Busload% Busload% Busload%
ID1
0.74
0.84
0.77
ID2
0.74
0.84
0.77
ID3
0.74
0.84
0.77
ID4
0.74
0.84
0.77
ID5
0.74
0.84
0.77
ID6
0.74
0.84
0.77
ViewingTable131itisobviousthattheapplicationdatafromtheACCsystem(IDs16)
isnotloadingtheCANbustoanycriticallevels.ThisisgraphicallyrepresentedinFigure
134.
Busload
BusLoad%
40
35
ID1BusLoad
30
ID2BusLoad
25
ID3BusLoad
20
ID4BusLoad
15
ID5BusLoad
10
ID6BusLoad
ID7BusLoad
0
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29
Time(ms)
ID8BusLoad
TotalBusLoad%
Figure 13-4: Normal Busload
Message deadlines and application deadlines will require examination. With 30.09%
busloadoverallmessageandapplicationdeadlinesshouldbereadilyattainable.Each
CANmessagehasadeadlineasshowninTable132.OnlyapplicationmessagesofID1
227
ID6areshownhereasmessagesID7andID8arepseudorandomlysent.Thisresultsin
higher bus loads for ID7 and 8. From Figure 135 the times that the application
messagesweretransmittedonthebusareillustrated.
MessageTransmissionTimes
25
Time(ms)
20
15
10
5
0
1
11 13 15 17 19 21 23 25 27 29
CycleNumber
ID1
ID2
ID3
ID4
ID5
ID6
Figure 13-5: Message Transmission Times at Normal Load
The deadlines for each message are presented in Table 132. It is immediately
apparentthatnoneofthedeadlinesareviolated.
MessageID
Deadline(ms)
20
40
60
80
Toexaminethemessagedeadlinesinrelationtotheapplicationdeadlineitshowsthat
the application deadline is easily attainable. The maximum cycle time was 21.12ms,
withaminimumof19.69ms.Theaveragecycletimewas19.10ms,whicheasilyallows
228
the120msdeadlinetimetobemet.ThisisillustratedinFigure136,wheretheYaxes
arescaled.Thestandarddeviationintheapplicationcycletimeis369s.
0.022
0.14
0.12
0.1
0.08
0.06
0.04
0.02
0
0.0215
0.021
0.0205
0.02
CycleLength(s)
CycleDeadline(s)
ApplicationCycleTime
0.0195
1
9 11 13 15 17 19 21 23 25 27 29
CycleNumber
CycleDeadline
ActualCycleTime
Figure 13-6: Application Cycle Times at Normal Load
Finally it can be shown how many frames are sent per cycle. This value can be
compared with FlexRays ST and DYN segments separately. Segregating the data it is
shownthatsixmessagesbetweenID1toID6aretransmittedperapplicationcycleas
predicted. The total number of frames per cycle value fluctuates in CAN due to the
messages with set deadlines and the messages with random transmit times both
transmittinginthesamecycle.Thestandarddeviationis5.99framespercycle.Figure
137 shows the number of frames fluctuating per cycle due to both the application
dataand random data being displayed. The maximum number of frames percycle is
53,withtheaveragebeing42.43.
229
NumberofFrames
frames/cycle
60
50
40
30
20
10
0
1
11 13 15 17 19 21 23 25 27 29
CycleNumber
frames/cycle
Figure 13-7: Number of Frames per Cycle at Normal Load
13.3.1.2
Case1B:60%Load
Increasing the busload to 60% is accomplished through the addition of two extra
messages generated by CANalyzer. These messages we assigned IDs close to the
highest priorities available (ID 11 and ID 12). The messages were set to transmit at
periodsof7ms.ThebusloadvaluesarepresentedinTable133below.
Table 13-3: 60% Busload
Msg
Min
Max
Average
ID
Load% Load% %
ID1
0.74
0.84
0.78
ID2
0.74
0.84
0.77
ID3
0.74
0.84
0.77
ID4
0.74
0.84
0.77
ID5
0.74
0.84
0.77
ID6
0.74
0.84
0.78
ID7
13.64
18.56
16.05
230
ThefigurespresentedinTable133areillustratedingraphformatinFigure138.
BusLoad
70
BusLoad(%)
60
50
40
30
20
10
0
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29
Time(ms)
ID1BusLoad%
ID2BusLoad%
ID3BusLoad%
ID4BusLoad%
ID5BusLoad%
ID6BusLoad%
ID7BusLoad%
ID8BusLoad%
ID11BusLoad%
ID12BusLoad%
TotalBusLoad%
Figure 13-8: 60% Busload
With an average busload of 58.71% and the maximum not exceeding 61.80% it is
expectedthatdeadlinesarenotviolated.TheCANmessagedeadlinesarethesameas
for the previouscase 1A. Onlymessages of ID1ID6 areshown here as messages ID7
andID8arerandomlysentandmessagesID11andID12aretransmittingperiodically
every7ms.Figure139illustratesthetransmittimesoftheapplicationmessages.The
deadlinesareaspresentedinTable132.Thefinalmessagetransmittimeasseenfrom
the graph in Figure 139 is at the 20ms mark where as the deadline is 120ms. The
applicationisthereforestillmeetingitsdeadlines.
231
25
Time(ms)
20
15
10
5
0
1
11 13 15 17 19 21 23 25 27 29
CycleNumber
ID1
ID2
ID3
ID4
ID5
ID6
Figure 13-9: Message Transmission Times at 60% load
ExaminingthedeadlinesinrelationtotheapplicationdeadlineFigure1310illustrates
that the application deadline is not violated (the Yaxes are scaled). The maximum
cycletimeis21.45mswithaminimumof19.70ms.Theaveragecycletimeis20.28ms
which is well below the 120ms deadline time. There is a standard deviation in the
applicationcycleof503s.
0.15
0.0225
0.1
0.0215
0.05
0.0205
0.0195
CycleLength(s)
CycleDeadline(s)
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29
CycleNumber
CycleDeadline
ActualCycleLength
Figure 13-10: Application Cycle Times at 60% load
232
Figure 1311 illustrates the number of transmitted frames fluctuating per cycle. The
maximum number of frames per cycle is 86 at 60% load; with an average of 75.63
framespercycleandastandarddeviationof5.22framespercycles.Asintheprevious
casetherearesixapplicationmessagestransmittedperapplicationcycle.
frame/cycle
NumberofFrames
90
80
70
60
50
1
11 13 15 17 19 21 23 25 27 29
CycleNumber
frame/cycle
Figure 13-11: Number of Frames per Cycle at 60% load
13.3.1.3
Case1C:MaximumLoad
To obtain a maximum busload, another two extra messages were generated on the
bus with IDs of 10 and 13. These were again generated by CANalyzer. The messages
ID1013 were set to transmit at 1ms periods to put as much data on the bus as
possible.ThebusloadvaluesarepresentedinTable134below.
233
Table 13-4: Maximum Busload
MsgID
MinLoad%
MaxLoad%
Average%
ID1
0.74
0.84
0.77
ID2
0.74
0.84
0.77
ID3
0.74
0.84
0.77
ID4
0.74
0.84
0.77
ID5
0.74
0.84
0.77
ID6
0.74
0.84
0.77
ID7
10.12
13.27
11.66
ID8
8.26
12.34
10.32
ID10
9.93
28.58
17.49
ThefigurespresentedinTable134areillustratedingraphicallyinFigure1312.
Figure 13-12: Maximum Busload
Withanaveragebusloadof96.29%,itisexpectedthatdeadlineswillbemissed.This
should be more pronounced for the lower priority messages. Only the applications
messages(ID1ID6)areshownhere.MessagesID7andID8arerandomlysentandnot
considered critical and messages ID1013 are set to transmit periodically every 1ms
234
and are present with the purpose of loading the CAN bus. The application messages
arestillmeetingtheirdeadlinesasillustratedbelowinFigure1313.
Time(ms)
40
35
30
25
20
15
10
5
0
1
11 13 15 17 19 21 23 25 27 29
CycleNumber
ID1
ID2
ID3
ID4
ID5
ID6
Figure 13-13: Message Transmission Times at Maximum Load
In Figure 1313 all message deadlines are being met. The deadlines are provided in
Table132.
ThemessagesgeneratedbyCANalyzerwiththelowerprioritiesarestrugglingtomeet
theirdeadlines.ThisresultsinmessageswithID1013beingdelayedgainingaccessto
thebusbyapprox4mslaterthanwhatwasset.ThisisillustratedinTable135.
Table 13-5: Message Delays
Msg Set
ID
Min Max
Period (ms) (ms)
Average
(ms)
(ms)
ID10
0.98
496.10
5.48
ID11
0.97 402.39
5.40
Examining the deadlines in relation to the application deadline, it shows that the
applicationdeadlineisstillnotbeingviolatedeventhoughthelowerprioritymessages
experiencecontentionwhenaccessingthebus.Thereasonfortheapplicationdeadline
235
notbeingviolatedisduetothemessageperiodsbeingsignificantlylargerthanthose
notassociatedwiththeapplication.Thisresultsinthemessagesgettingaccesstothe
bus due to higher priority and occurring less frequently. The maximum application
cycle time was 33.77ms with a minimum of 33.32ms. The average cycle time was
33.57ms which is vastly below the 120ms deadline time. The standard deviation is
91.34s.Figure1314illustratesthiswiththeYaxesscaled.
0.0331
0.0329
0.0327
0.0325
CycleLength(s)
CycleDeadline(s)
0.14
0.12
0.1
0.08
0.06
0.04
0.02
0
0.0323
1
9 11 13 15 17 19 21 23 25 27 29
CycleNumber
CycleDeadline
ActualCycleLength
Figure 13-14: Application Cycle Times at Maximum Load
Figure 1315 illustrates the number of frames fluctuating per cycle. The maximum
number of frames per cycleis 125, at themaximum load, with anaverage of124.20
framespercycle.Thestandarddeviationfigureof0.48framespercyclesissmalldue
to the upper limit being reached in terms of the number of frames that the bus can
physically handle. There are six application messages (ID1 ID6) transmitted per
applicationcycleinkeepingwithpreviouscaseresults.
236
frame/cycle
NumberofFrames
125.5
125
124.5
124
123.5
frame/cycle
123
122.5
122
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31
Cycle
Figure 13-15: Number of Frames per Cycle at Maximum Load
13.3.2 CANMinimalCases
TheminimalconfigurationtestcasesareconfiguredasperFigure132.Itisexpected
thattheresultsobtainedintheminimaltestcasewouldbesimilartothoseobtained
throughthenormaltestcase.
13.3.2.1
CASE2A:NormalLoad
In this test case the total bus load is averaging at 33.40% for all CAN messages. The
individualbreakdownispresentedinTable136
MsgID
Min
Max
Average%
Load%
Load%
ID1
0.74
0.84
0.77
ID2
0.74
0.84
0.77
ID5
0.74
0.84
0.77
ID6
0.74
0.84
0.77
ID7
14 11
18 00
16 01
237
ViewingTable136itisexpectedthatthislevelofbusloading(Max32.40%)shouldnot
affectanymessagestimingbasedonobservationsintheprevioustestcase.
Messagedeadlinesandapplicationdeadlineswillbeexamined.EachCANmessagehas
adeadlineof20msasitwasintheNormalCase.OnlymessagesofID1,2,5and6are
presentedhereasmessagesID3and4arenottransmittedacrossthebus.Messages
ID7andID8arerandomlytransmitted.EachmessagedeadlineisaspresentedinTable
132. Figure 1316 illustrates the message transmit times. The results are similar to
thoseobtainedintheprevioustestcase
MessagesTransmissionTimes
30
Time(ms)
25
20
15
10
5
0
1
11 13 15 17 19 21 23 25 27 29
CycleNumber
ID1
ID2
ID5
ID6
TheapplicationdeadlineisnotcorruptedasillustratedinFigure1317.Themaximum
cycle time was 24.51ms and a minimum of 23.54ms. The average cycle time was
23.77mswhichisbelowthe120msapplicationdeadlinetime.Thestandarddeviation
in the application cycle is 328.43s. In the minimal configuration there are four
messagesperapplicationcycle.Thisistwolessthaninthenormalconfiguration.The
YaxesinFigure1317arescaled.
238
0.14
0.12
0.1
0.08
0.06
0.04
0.02
0
0.025
0.0245
0.024
CycleLength(s)
CycleDeadline(s)
0.0235
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29
CycleNumber
CycleDeadline
ActualCycleTime
Figure 1318 displays the number of frames fluctuating per cycle. The standard
deviation is 5.05 frames per cycle. The maximum number of frames pre cycle is 49,
withtheaveragebeing40.06framespercycle.
NumberofFrames
frame/cycle
55
50
45
40
35
30
25
20
1
11 13 15 17 19 21 23 25 27 29
CycleNumber
frame/cycle
Figure 13-18: Number of Frames per Cycle at Normal Load
239
13.3.2.2
Case2B:60%Load
Increasingthebusloadto60%requiredtheadditionoftwoextramessagesgenerated
byCANalyzer.TheseadditionalmessagesweassignedIDsclosetothehighestpriorities
available(ID11andID12).Themessagesweresettotransmitatperiodsof7ms.The
busloadvaluesarepresentedinTable137below.
Table 13-7: 60% Busload
MsgID
MinLoad%
MaxLoad%
Average%
ID1
0.74
0.84
0.77
ID2
0.74
0.84
0.77
ID5
0.74
0.84
0.77
ID6
0.74
0.84
0.77
ID7
14.38
18.19
15.72
ID8
9.56
12.99
11.35
ID11
13.18
13.36
13.26
ID12
13 18
13 27
13 26
Time(ms)
30
25
20
15
10
5
0
1
11 13 15 17 19 21 23 25 27 29
CycleNumber
ID1
ID2
ID5
ID6
Figure 13-19: Message Transmission Times at 60% Load
Withanaveragebusloadof56.78%andthemaximumnotexceeding59.30%itwould
beexpectedthatmessagescompletedinadvanceoftheirdeadlines.TheCANmessage
deadlinesareaspresentedinTable132.Onlytheapplicationmessages(ID1,2,5,and
6)arepresentedhereasmessagesID7andID8arerandomlysentandmessagesID11
240
andID12aretransmittingperiodicallyevery7ms.AlldatageneratedbyCANalyzergets
access to the bus without any delays therefore meeting the associated message
deadlines.ThemessagetransmittimesareillustratedinFigure1319.
0.14
0.12
0.1
0.08
0.06
0.04
0.02
0
0.0269
0.0264
0.0259
0.0254
0.0249
CycleLength(s)
CycleDeadline(s)
0.0244
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29
CycleNumber
CycleDeadline
ActualCycleLength
Figure 13-20: Application Cycle Times at 60% Load
Examining the deadlines in relation to the application deadline it is proven that the
applicationcompletespriortoitsdeadlineinFigure1320.Themaximumcycletimeis
26.04ms with a minimum of 24.47ms. The average cycle time is 25.04ms which is
belowthe120msdeadlinetime.Thereisastandarddeviationof475.50s.
Figure1321showsthenumberofframesfluctuatingpercycle.ThestandardDeviation
is4.58framespercycle.Themaxnumberofframespercycleis82at60%load,withan
averageof72.83framespercycle.
241
NumberofFrames
frame/cycle
85
80
75
70
65
60
55
50
1
11 13 15 17 19 21 23 25 27 29
CycleNumber
frame/cycle
Figure 13-21: Number of Frames per Cycle at 60% Load
13.3.2.3
Case2C:MaximumLoad
Toobtainthemaximumbusloadtwoextramessagesweregeneratedonthebuswith
IDsof10and13aswasdoneinCase1C.ThemessagesID1013weresettotransmitat
1ms periods to place as much data on the bus as possible. The busload values are
presentedinTable138below.
Table 13-8: Maximum Busload
Msg Min
ID
Max
Average Total Total Average
Load% Load% %
ID1
0.74
0.84
0.77
ID2
0.74
0.84
0.77
ID5
0.74
0.84
0.77
ID6
0.74
0.84
0.77
ID7
13.18
16.89
14.79
ID8
9.65
12.71
11.05
Min
Max
96.23 96.60
96.39
242
With an average busload of 96.39% it would be expected that deadlines are missed.
This would be more pronounced for lower priority messages. Only application
messages (ID1, 2, 5 and 6) are shown here due to messages ID7 and ID8 being
randomly sent and messages ID1013 areset to transmit periodically every 1ms. The
applicationmessageswithID1,2,5and6arestillmeetingtheirdeadlinesasillustrated
belowinFigure1322.ThedeadlinesarepresentedinTable132.
30
Time(ms)
25
20
15
10
5
0
1
11 13 15 17 19 21 23 25 27 29
CycleNumber
ID1
ID2
ID5
ID6
Figure 13-22: Message Transmission Times at Maximum Load
Because of the large amount of slack in each message (e.g. ID5 transmission time of
17.235ms and a deadline of 100ms) and the low transmission frequency when
comparedtotheothermessagesinthesystem,itisunlikelythattheapplicationwill
failinitscurrentconfiguration.ThemessagesgeneratedbyCANalyzerwiththelower
prioritiesarestrugglingtomeettheirdeadlines.ThisresultsinmessageswithID1013
being delayed gaining access to the bus by approx 4ms after what was set. This is
illustratedinTable139.
243
Table 13-9: Message Delays
Msg Set
ID
Min Max
Period (ms) (ms)
Average
(ms)
(ms)
ID10
0.98
2012.66
5.39
ID11
0.97 2001.95
5.83
Examining application execution and deadline times (Figure 1323) it shows that the
applicationcompletesexecutionpriortoitsdeadlineasinthepreviousCANtestcases.
Themaximumcycletimewas26.03msandaminimumof24.76ms.Theaveragecycle
timewas25.68mswhichisbelowthe120msdeadlinetime.Thestandarddeviationis
338.72s.TheYaxesarescaledinFigure1323.
0.027
0.14
0.12
0.1
0.08
0.06
0.04
0.02
0
0.0265
0.026
0.0255
0.025
CycleLength(s)
CycleDeadline(s)
ApplicationCycleTimes
0.0245
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29
CycleNumber
CycleDeadline
ActualCycleTime
Figure 13-23: Application Cycle Times at Maximum Load
Figure 1324 presents the number of transmitted frames fluctuating per cycle with a
standard deviation of 0.50. The maximum number of frames per cycle is 125 at the
maximumload,withanaverageof124.50framespercycle.
244
Frame/Cycle
NumberofFrames
125.5
125
124.5
124
123.5
123
1
11 13 15 17 19 21 23 25 27 29
CycleNumber
Frame/Cycle
Figure 13-24: Number of Frames per Cycle at Maximum Load
13.4 FlexRayResults
TheFlexRayresultsaredividedintotwosections;
WithoutRedundancy
WithRedundancy
Withineachofthesesectionstherearefurthersubdivisions:
Standard
StandardHighDataRate
Minimal
MinimalHighDataRate
The Standard configuration refers to Figure 131 and the Minimal configuration
referstoFigure132.
245
TheCANmessageswithID1ID6areassignedtotheSTsegmentandmessagesID7and
ID8areassignedtotheDYNsegment.Whereloadingofthebusisrequiredthisdata
was placed in the DYN segment because this data is not guaranteed to meet its
deadlinesbecauseoftheETnatureoftheDYNsegment.Iftheloadeddatawasplaced
in the ST segment it would be guaranteed to get access to the bus if scheduled
correctlyduetotheTTnatureoftheSTsegment.
TheSTmessagesaretransmittedonchannelA(CHA)andtheDYNdataistransmitted
onchannelB(CHB).WheredataisloadedontothebusbothCHAandCHBareused.
The application message cycle is assumed to begin once the latest dynamic message
hastransmittedinthepreviouscycle.ThisassumptionisnecessarybecauseCANalyzer
onlyrecordswhenmessagesappearonthebusnotwhenthemessagesaresignalled
for transmission by the MCU through the communications stack. In the FlexRay test
case the application cycle is assumed to start 1.391ms before the message of ID 1
appears on the bus. This is the time between the last DYN message of the previous
cycleandthecurrentSTmessageinthecurrentcycle.
13.4.1 WithoutRedundancy
13.4.1.1
Case3A:StandardNormalLoad
Due to the FlexRay bus operating at 10 Mbit/s it would be expected that at normal
busloads FlexRay would be using less of its percentage total capacity than the CAN
equivalent. This is demonstrated in Table 1310. Even by combining these two loads
onto a single channel, the busload would still be considerably less than the CAN
equivalent.
246
Table 13-10: Standard Busload
Msg
Min
Max
Average
ID
Load% Load% %
ST
ID1
0.02
0.02
0.02
ID2
0.02
0.02
0.02
ID3
0.02
0.02
0.02
ID4
0.02
0.02
0.02
ID5
0.02
0.02
0.02
ID6
0.02
0.02
0.02
Total
0 13
0 14
0 14
ThesebusloadsareillustratedgraphicallyinFigures1325and1326.TheIDs16have
thesameloadssotheyappearasonelineonthegraphbehindeachother.
BusLoad%
BusLoadCHA
0.16
0.14
0.12
0.1
0.08
0.06
0.04
0.02
0
ID1BusLoad
ID2BusLoad
ID3BusLoad
ID4BusLoad
ID5BusLoad
ID6BusLoad
1 3 5 7 9 11131517192123252729
TotalBusLaod%A
Time(ms)
Figure 13-25: No Redundancy Normal Busload CH A
ThebusloadsarehigheronCHBduetothemessagesallocatedtherehavingsmaller
periodthanthemessagesonCHA.ThereforeCHBdataisonthebusmorefrequently.
247
BusLoadCHB
BusLoad%
2
1.5
1
0.5
0
1
11 13 15 17 19 21 23 25 27 29
Time(ms)
ID7BusLoad
ID8BusLoad
TotalBusLoad%B
Figure 13-26: No Redundancy Normal Busload CH B
Fromtheframeworkinsection12.5.7themessagesperiodsaremodifiedto14msas
illustratedinTable1311.
Table 13-11: Revised FlexRay Message

Deadlines
MessageID
Deadline(ms)
14
28
42
56
Figure 1327 illustrates that the messages easily meet their deadlines. Due to some
messageshavingdifferentWCETstherewillbeslightvariationsbetweenthemessages
actualcycletimes.
248
30
Time(ms)
25
20
15
10
5
0
1
11 13 15 17 19 21 23 25 27 29
CycleNumber
ID1
ID2
ID3
ID4
ID5
ID6
Figure 13-27: Message Transmission Times Normal Load
To examine if the each message deadline can combine to complete the application
beforetheapplicationdeadlineof84ms,Figure1328isexamined.Themaximumcycle
time is 24.33ms and a minimum of 24.33ms. The average cycle time was 24.33ms
whichissignificantlybelowthe84msdeadlinetime.Therewasslightdeviationwhich
resultedinastandarddeviationof183ns.
249
CycleLength(s)
0.1
0.08
0.06
0.04
0.02
0
1
11 13 15 17 19 21 23 25 27 29
CycleNumber
ActualCycleTime
CycleDeadline
Figure 13-28: Application Cycle Times Normal Load
IntheSTsegmentthenumberofframespercycleisstatic(6framespercycle)asthe
applicationdataisscheduledatfixedpointsintimeasillustratedinFigure1329.This
correspondstothesixframestransmittedbytheapplicationdatainCAN.IntheDYN
segmentthenumberofframespercycleisrandomduetotheETnatureoftheDYN
segment.ThisisillustratedinFigure1330.
250
NumberofFrames
frame/cycleST
7
6
5
4
3
2
1
0
1
11 13 15 17 19 21 23 25 27 29
CycleNumber
frame/cycleST
Figure 13-29: Number of ST Frames per Cycle (No Redundancy)
Thereareamaximumof68framespercycleintheDYNsegmentwithanaverageof
63.03framespercycle.Thestandarddeviationis3.96framespercycle.
NumberofFrames
frame/cycleDYN
70
60
50
40
1
9 11 13 15 17 19 21 23 25 27 29
CycleNumber
frame/cycleDYN
Figure 13-30: Number of DYN Frames per Cycle Normal Load
251
13.4.1.2
Case3B:StandardatHighDataRate
AtaHighDataRate(HDR)loadsinFlexRaythereistwicetheamountofdataonthe
buswhencomparedtothemaximumamountofdataontheCAN.EvenatthisHDRthe
FlexRaybuswouldbeexpectedtohavecapacitytohandleahighervolumeoftrafficif
itwasrequiredtodoso.
In addition to the two messages transmitted from the development boards (ID7 and
ID8)thebusisloadedwithmessages(hex)ID9,a,b,c,d,e,fand10.Thesemessages
aresetfortransmissiononceineveryFlexRaycommunicationcycleatapayloadof8
Bytes.
ThebusloaddataispresentedinTable1312.
Table 13-12: High Data Rate Busload
MsgID
Minimum
Maximum Average
Load%
Load%
Load%
ST
ID1
0.02
0.02
0.02
ID2
0.02
0.02
0.02
ID3
0.02
0.02
0.02
ID4
0.02
0.02
0.02
ID5
0.02
0.02
0.02
ID6
0.02
0.02
0.02
Total
0.13
0.14
0.14
DYN
ID7
0.69
0.77
0.73
ID8
0.62
0.79
0.72
ID9
1.10
1.10
1.10
IDa
1.10
1.10
1.10
IDb
1 10
1 10
1 10
252
The DYN data was split for transmission between CH A and CH B. This was done to
demonstratetheaffectofadditionaldataonthereferenceapplicationsdeadlines.The
dataloadedonCHAisassignedidentifiersIDd,e,fand10whilethedataloadedon
CHBisassignedidentifiersIDa,b,cand9.
Figure 1331 illustrates that the application messages meet the required application
deadlines.
Time(ms)
ApplicationMessageExecution
Times
30
25
20
15
10
5
0
1
11 13 15 17 19 21 23 25 27 29
CycleNumber
ID1
ID2
ID3
ID4
ID5
ID6
Figure 13-31: Message Transmission Times High Data Rate
To examine if the each message deadline can combine to complete the application
beforetheapplicationdeadlineof84ms,Figure1332isexamined.Themaximumcycle
time was 24.33ms and a minimum of 24.33ms. The average cycle time was 24.33ms
whichisconsiderablylessthanthe84msdeadlinetime.Thestandarddeviationinthe
cycletimesis183ns.
253
CycleLength(s)
0.1
0.08
0.06
0.04
0.02
0
1
11 13 15 17 19 21 23 25 27 29
CycleNumber
CycleTime
CycleDeadline
Figure 13-32: Application Cycle Times High Data Rate
IntheSTsegmentthenumberofframespercycleisstaticatsixframespercycle.In
theDYNsegmentthenumberofframespercycleisaperiodicduetotheETnatureof
theDYNsegment.ThisisillustratedinFigure13.33.TheDYNdatacontainsamaximum
of455framespercyclewithanaverageof444.70framespercycle.Thereisastandard
deviationof5.08framespercycle.
NumberofFrames
frames/cycleDYN
460
450
440
430
420
1
9 11 13 15 17 19 21 23 25 27 29
CycleNumber
frame/cycleDYN
Figure 13-33: Number of DYN Frames per Cycle High Data Rate
254
13.4.1.3
Case3C:MinimalNormalLoad
Theminimalconfigurationatnormalloadswouldbeexpectedtoyieldslightlyreduced
busloads (compared to the standard configuration) in the ST segment as two less
framesperapplicationcyclearetransmittedontheFlexRaybus.Table1313presents
thebusloads.
Msg
ID
Load%
Load%
Load%
ST
ID1
0.02
0.02
0.02
ID2
0.02
0.02
0.02
ID5
0.02
0.02
0.02
ID6
0.02
0.02
0.02
Total
0.09
0.09
0.09
Ifapplicationmessagesareabletomeettheirdeadlinesneedsdetermining.Figure13
34isusedindeterminingthis.Itisillustratedthatallmessagesmeettheirdeadlinesas
definedinTable1311.
255
Time(ms)
30
25
20
15
10
5
0
1
9 11 13 15 17 19 21 23 25 27 29
CycleNumber
ID1
ID2
ID5
ID6
Determining if the each message deadline can combine to complete the ACC
application before the application deadline of 84ms, Figure 1335 is examined. The
maximum,minimumandaveragecycletimesareall24.33ms.Thisconsistencyinthe
applications timing is in keeping with the TT nature of the ST segment in which the
application data was assigned. The maximum ACC application cycle time of 24.33ms
allows the application to complete greater than three times quicker than what is
required(84msdeadlinetime).Thereisastandarddeviationof254ns.
256
CycleLength(s)
0.1
0.08
0.06
0.04
0.02
0
1
11 13 15 17 19 21 23 25 27 29
CycleNumber
CycleTime
CycleDeadline
ThereareconstantlyfourframesperACCapplicationcycle;thisisinkeepingwiththe
expectedresults.IntheDYNsegmentthenumberofframespercycleisaperiodicdue
to the ET nature of the DYN segment. This results in a standard deviation of 4.46
frames per cycle. There are a maximum of 69 frames per cycle in the DYN segment
withanaverageof61.6framespercycle.Figure1336illustratesthis.
NumberofFrames
frames/cycleDYN
80
70
60
50
40
1
9 11 13 15 17 19 21 23 25 27 29
CycleNumber
frame/cycleDYN
Figure 13-36: Number of DYN Frames per Cycle at Normal Load
257
13.4.1.4
Case3D:MinimalatHighDataRate
AtHighDataRates(HDR)thereistwicetheamountofdataonthebuswhencompared
to the maximum amount of data on the CAN bus. Even at this HDR the FlexRay bus
wouldbeexpectedtohavecapacitytohandlemoremessagesifitwasrequiredtodo
so.
Inadditiontothetwomessagessentfromthedevelopmentboards(ID7andID8)the
busisloadedwithmessages(hex)ID9,a,b,c,d,e,fand10.Thesemessagesareset
fortransmissiononceineverycommunicationcyclewithapayloadof8Bytes.
MsgID

Load%
Load%
Load%
ST
ID1
0.02
0.02
0.02
ID2
0.02
0.02
0.02
ID5
0.02
0.02
0.02
ID6
0.02
0.02
0.02
Total
0.09
0.09
0.09
DYN
ID7
0.64
0.78
0.72
ID8
0.58
0.77
0.71
ID9
1.10
1.10
1.10
IDa
1.10
1.10
1.10
IDb
1.10
1.10
1.10
TheloadeddatageneratedfromCANalyzerisassignedtoeachchannelaspertestcase
3B. Figure 1337 illustrates that message deadlines are not violated. The message
258
closesttomissingitsdeadlineismessageID1.Ithas12.61msslackwhichallowsittoo
comfortablytomeetitsdeadlineof14ms.ThedeadlinesarepresentedinTable1311.
Time(ms)
30
25
20
15
10
5
0
1
11 13 15 17 19 21 23 25 27 29
CycleNumber
ID1
ID2
ID5
ID6
Figure 1338 presents the ACC application cycle times. The maximum cycle time was
26.08msandtheminimumwas22.58ms.Theaveragecycletimewas24.33ms.Aswith
all previous test cases the ACC application cycle time is within the ACC application
deadline.Thestandarddeviationis559.50s.
CycleLength(s)
0.1
0.08
0.06
0.04
0.02
0
1
11 13 15 17 19 21 23 25 27 29
CycleNumber
CycleTime
CycleDeadline
259
As in the previous minimal configuration results (Case 3C) there are only four
application frames per ACC application cycle. In the DYN segment the number of
frames per cycle is aperiodic due to the ET nature of the DYN segment. This is
illustratedinFigure1339.Thestandarddeviationis5.17framespercycle.Therearea
maximumof452framespercyclewithanaverageof442.1framespercycle.
NumberofFrames
frames/cycleDYN
460
450
440
430
420
1
9 11 13 15 17 19 21 23 25 27 29
CycleNumber
frame/cycleDYN
13.4.2 WithRedundancy
Inthefollowingtestcases4A,B,CandD,redundancywasimplementedforthedata
transmittedintheSTsegment.ThisinvolvedduplicatingthedataonCHA.CHBdata
wasconsideredtheredundantdatainthesetestcases.
13.4.2.1
Case4A:StandardNormalLoad(IncludingRedundancy)
DuetotheFlexRaybusoperatingat10Mbit/sitwouldbeexpectedthatnormalACC
application busloads with the two DYN messages would be less than the CAN
equivalent.ThisisverifiedinTable1315.TheSTdatacombinestheloadsofCHAand
CHB.
260
Msg
ID
Load%
Load%
Load%
ST
ID1
0.04
0.05
0.05
ID2
0.04
0.05
0.05
ID3
0.04
0.05
0.05
ID4
0.04
0.05
0.05
ID5
0.04
0.05
0.05
ID6
0.04
0.05
0.05
Total
0.27
0.28
0.27
From the frameworkinsection1.5.6the messages periods are modified to14ms (as

was the case for the nonredundancy test cases). Figure 1340 illustrates that the
messagescontinuetoeasilymeettheirdeadlines.
30
Time(ms)
25
20
15
10
5
0
1
11 13 15 17 19 21 23 25 27 29
CycleNumber
ID1
ID2
ID3
ID4
ID5
ID6
Figure1341presentstheACCapplicationcyclestime.Examiningiftheeachmessage
deadline can be combined to complete the application cycle, before the application
261
deadlineof84ms,seeFigure1341.Themaximumcycletimeis24.33ms,theminimum
and average times are also 24.33ms. This consistency of application cycle times is a
primeexampleofthedeterministicpropertiesofFlexRay.Thereisastandarddeviation
of183ns.
CycleLength(s)
0.08
0.06
0.04
0.02
0
1
9 11 13 15 17 19 21 23 25 27 29
CycleNumber
CycleTimeCHAST
CycleDeadline
ThenumberofframesperACCapplicationcycleisstaticattwelve(6frameseachon
channelAandB).Thisisinkeepingwithtestcases3Aand3Bwhereredundancyisnot
implemented(therefore,6framesintotal),buttheapplicationconfigurationshavenot
changed. In the DYN segment the number of frames per cycle continues to be
aperiodicduetotheETnatureoftheDYNsegment.ThisisillustratedinFigure1342.
There is a maximum of 73 frames per cycle in the DYN segment with an average of
64.03framespercycle.Thestandarddeviationis4.02framespercycle.
262
NumberofFrames
frames/cycleDYN
75
70
65
60
55
50
1
9 11 13 15 17 19 21 23 25 27 29
CycleNumber
frame/cycleDYN
Figure 13-42: Number of DYN Frames per Cycle at Normal Load
13.4.2.2
Case4B:StandardatHighDataRate(IncludingRedundancy)
ThistestcaseisconfiguredthesameasCase3Bexceptredundancyisimplemented.At
HighDataRates(HDR)thereistwicetheamountofdataonthebuswhencomparedto
themaximumamountofdataontheCAN.EvenatthisHDRtheFlexRaybuswouldbe
expectedtohavethecapacitytohandlemoremessagesifitwasrequiredtodoso.
InadditiontothetwoDYNmessagestransmittedfromthedevelopmentboards(ID7
and ID8) the bus is loaded with messages (hex) ID 9, a, b, c, d, e, f and 10. These
messagesaresettotransmitonceineverycommunicationcycleintheDYNsegment
withapayloadof8Bytes.
ThebusloaddataispresentedinTable1316wheretheredundantdataisincluded.
263
Msg
Min
Max
Average
ID
Load% Load% %
ST
ID1
0.04
0.05
0.05
ID2
0.04
0.05
0.05
ID3
0.04
0.05
0.05
ID4
0.04
0.05
0.05
ID5
0.04
0.05
0.05
ID6
0.04
0.05
0.05
Total
0.27
0.28
0.27
DYN
ID7
0.65
0.77
0.72
ID8
0.67
0.76
0.72
ID9
1.10
1.10
1.10
IDa
1.10
1.10
1.10
IDb
Figure 1343 illustrates the message complete transmission prior to their deadlines.
Fluctuationsoccuratplus/minusoneframecycle.Thisiscausedbyamessageeither
beingreadyonecycleearlieroronecyclelaterthanthestandardmessageexecution
time.
264
30
Time(ms)
25
20
15
10
5
0
1
11 13 15 17 19 21 23 25 27 29
CycleNumber
ID1
ID2
ID3
ID4
ID5
ID6
ThetimelyexecutionoftheACCapplicationdeadlinesof84msisverifiedinFigure13
43.Table1311containsthemessagedeadlines.Themaximumcycletimewas26.08ms
and a minimum of 22.58ms. The average cycle time was 24.10ms which means the
application has completed execution 59.9ms before the deadline time. The standard
deviationis759.66s.
CycleLength(s)
0.1
0.08
0.06
0.04
0.02
0
1
11 13 15 17 19 21 23 25 27 29
CycleNumber
CycleTimeSTCHA
CycleDeadline
265
There are twelve application frames in the ST segment as explained in the previous
testcase.ThisisillustratedinFigure1345.IntheDYsegmentthenumberofframes
percycleislesscyclicduetotheETnatureoftheDYNsegment.Thisisillustratedin
Figure1346.
NumberofFrames
frames/cycleST
14
12
10
8
6
4
2
0
1
11 13 15 17 19 21 23 25 27 29
CycleNumber
frame/cycleST
Figure 13-45: Number of ST Frames per Cycle High Data Rate
TheDYNdatacontainsamaximumof458framespercyclewithanaverageof446.60
framespercycle.Thestandarddeviationis6.34framespercycle.
NumberofFrames
frames/cycleDYN
460
450
440
430
1
9 11 13 15 17 19 21 23 25 27 29
CycleNumber
frame/cycleCHB
266
13.4.2.3
Case4C:MinimalNormalLoad(IncludingRedundancy)
Theminimalconfigurationatnormalbusloads(nodataloading)wouldbeexpectedto
yield slightly reduced busloads (compared to Standard configuration) in the ST
segment, due to two less frames per application cycles being transmitted on the
FlexRaybusperchannel.Table1317presentsthebusloads.
Msg
ID
Load%
Load%
Load%
ST
ID1
0.04
0.05
0.05
ID2
0.04
0.05
0.05
ID5
0.04
0.05
0.05
ID6
0.04
0.05
0.05
Total
0.09
0.09
0.09
DYN
Figure 1347 determines if the individual messages execution times meet their
deadlines.Eachmessageeasilymeetsitssetdeadlines.Theassociateddeadlinesareas
presentedinTable1311.
267
Time(ms)
MessageTranmissionTimes
30
25
20
15
10
5
0
1
9 11 13 15 17 19 21 23 25 27 29
CycleNumber
ID1
ID2
ID5
ID6
Figure 13-47: Message Transmission Times at Normal Loads
Combining message times to build the application execution time, this enables the
success of the ACC application to be determined. If the final message completes
execution before the application deadline then the ACC application can successfully
execute.Figure1348presentsthis data.Themaximum, minimumand averagecycle
timesare24.33ms.Thereisastandarddeviationof305ns.
CycleLength(s)
0.1
0.08
0.06
0.04
0.02
0
1
9 11 13 15 17 19 21 23 25 27 29
Cyclenumber
CycleTimeCHAST
CycleDeadline
Figure 13-48: Application Cycle Times at Normal Loads
TheSTsegmentapplicationtransmitseightapplicationframesintotal(4perchannel)
as expected. This produces a horizontal straight line when graphed. In the DYN
268
segmentthenumberofframespercycleisaperiodicduetotheETnatureoftheDYN
segment.Thereareamaximumof66framesperapplicationcycleintheDYNsegment
withanaverageof56.16framespercycleandastandarddeviationof4.58framesper
cycle.Figure13.49illustratesthenumberofDYNdataframesfromCHB(asthereisno
loadinginthistestcasealltheDYNdataistransmittedonCHB).
NumberofFrames
frames/cycleDYN
70
60
50
40
1
9 11 13 15 17 19 21 23 25 27 29
CycleNumber
frame/cycleDYN
Figure 13-49: Number of DYN Frames per Cycle at Normal Loads
13.4.2.4
Case4D:MinimalatHighDataRate(IncludingRedundancy)
This test case contains the same configuration as Case 3D with the addition of
redundancy being implemented for the ACC application data in the ST segments. At
HighDataRates(HDR)thereistwicetheamountofFlexRaydata(intermsofthetotal
numberofframes)onthebuswhencomparedtothemaximumamountofdataonthe
CAN bus. Even at this HDR the FlexRay bus would be expected to have capacity to
handleadditionalmessages.
In addition to the two messages transmitted from the development boards (ID7 and
ID8)thebusisloadedwithadditionalmessagesof(hex)IDs9,a,b,c,d,e,fand10.
Thesemessagesaresetfortransmissiononceineverycommunicationcycleconfigured
withapayloadof8Bytes.
269
MsgID
Minimum
Maximum
Average
Load%
Load%
Load%
ST
ID1
0.04
0.05
0.05
ID2
0.04
0.05
0.05
ID5
0.04
0.05
0.05
ID6
0.04
0.05
0.05
Total
0.18
0.18
0.18
DYN
ID7
0.61
0.79
0.71
ID8
0.62
0.78
0.72
ID9
1.10
1.10
1.10
IDa
1.10
1.10
1.10
IDb
1.10
1.10
1.10
Figure 1550 illustrates that the message deadlines are not exceeded. The actual
deadlinesarepresentedinTable1311.
270
Time(ms)
30
25
20
15
10
5
0
ID1
ID2
ID5
ID6
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29
CycleNumber
AsinallprevioustestcasestheACCapplicationcyclecompletesexecutionpriortothe
deadline; 59.67ms prior in this test case at a worst case scenario. Figure 1351
illustrates the applications cycle times over a 30 application cycle period. The
maximum ACC application cycle time was 24.33ms with the minimum and average
timealso24.33ms.Thestandarddeviationis253.7ns.
CycleLength(s)
0.1
0.08
0.06
0.04
0.02
0
1
9 11 13 15 17 19 21 23 25 27 29
CycleNumber
ActualCycleLength
CycleDeadline
271
The number of ACC application frames remains constant at eight for the minimal
configuration. In Figure 1352 the DYN data contains a maximum of 447 frames per
cycle with an average of 440.16 frames per cycle. The standard deviation is 3.92
framespercycle.
NumberofFrames
frames/cycleDYN
450
445
440
435
430
425
1
9 11 13 15 17 19 21 23 25 27 29
CycleNumber
frame/cycleDYN
13.5 DiscussionofResults
UsingbothprotocolstheACCapplicationwassuccessfullyimplementedandexecuted
inallscenarios.Thereisahigherthroughputinthenumberofframesinonesecondin
FlexRaywhencomparedwithCAN.Thenumberofframespersecondineachscenario
andtestcasearepresentedinTable1319and1320.
272
13.5.1 CANData
Table 13-19: Number of CAN Frames per Second
Standard Busload Min
Max Average
Case1A
391
357.31
667
634.38
Normal 329
(30%)
Case1B
60%
603
Case1C
Max
1034 1040 1037.52
(100%)
Minimal Busload Min
Max Average
Case2A
349
Normal 297
327.76
(30%)
13.5.2 FlexRayData
Table 13-20: Number of FlexRay Frames per Second
No
Busload Min
Max Average
Case3A
Normal 781
878
Case3B
Normal 4689 5442 5374.07
Redundancy
828.18
HDR
Case3C
Minimal 741
844
799.89
Case3D
Minimal 5288 5426 5366.07

HDR
Redundancy Busload Min
Max Average
Case4A
934
Normal 865
899.29
Atmaximumbusloadsincase1Cor2Cthemessageswiththelowestprioritiesmissed
theirdeadlines.ThesemessagesID10, 11, 12 and13weregainingaccesstothebus
laterthan5msonaverageasopposedtotheirscheduledtimeofevery1ms.Thesetwo
test cases resulted in a maximum of 1040 and 1041 frames per second respectively.
273
Compare this to the FlexRay test cases of 3D and 4D. Here eight extra messages are
added for transmission in the frame cycle (1.750ms). This was successfully achieved
whileattainingamaximumthroughputof5426and5488framespersecondintotal
overbothchannels.InthesetestcasesthethroughputofFlexRayversusCANwasfive
times larger for FlexRay. At 1041 frames per second the CAN bus has reached its
maximumcapacitybusloadof96.60%whereasat5488framespersecondtheFlexRay
busisat10.43%busload.
It is recorded that at 60% loads the application cycle time was starting to increase
when comparedto theapplicationtime atnormalbusload. Incase1Athemaximum
applicationcycleis21.12ms,thisthenincreasesslightlyto21.45msincase1B.Incase
2Athemaximumapplicationtimeis24.51msbutthisincreasesto26.04msincase2B.
In case 1A the minimum application cycle time cycle is 19.69ms and this is almost
unchanged at 19.70ms in case 1B. In case 2A the minimum application cycle time is
23.54msbutthisincreaseto24.47msincase2B.
Finallyincase1Atheaverageapplicationexecutiontimeis19.10mscomparedwitha
timeof20.28msincase1B.Incase2Atheaverageapplicationcycletimeis23.77ms
comparedtotheaverageapplicationcycletimeof25.04msincase2B.
Theseindividualmessagetransmittimescanbeviewedindividuallyanditisobserved
that as busloads increase so does the transmit time of each message. Figure 1353
illustrates that the message transmit times are increasing as the busloads increase.
Messages ID5 and ID6 transmit times increase the most as they are further into the
applicationcycle.
274
Time(ms)
MessageTransmitTimes
30
25
20
15
10
5
0
30%
60%
100%
Busload(%)
m1
m2
m5
m6
Figure 13-53: Message Transmit Times (Minimal Configuration)
Figure 1353 illustrates the message transmit times increasing as the busloads
increase. The messages that transmit later in the application cycle are adversely
affectedtoagreaterdegreethanthemessagestransmittedearlierintheapplication
cycle.InFigure1354,thetransmittimesofmessagesixaredelayedgreaterthanthe
transmittimesofmessageoneforexample.
Time(ms)
MessageTransmitTimes
40
35
30
25
20
15
10
5
0
20%
30%
40%
50%
60%
70%
80%
90% 100% 110%
Busload(%)
m1
m2
m3
m4
m5
m6
Figure 13-54: Message Transmit Times (Normal Configuration)
275
The deterministic nature of FlexRay is illustrated by the ACC application completion

times. Seven of the eight FlexRay test cases completed transmission at 24.33ms, the
exception being test case 3D where transmission was completed at 24.10ms.This is
regardlessofbusloadswhichasillustratedinFigures1353and1354busloadsaffect
theapplicationsexecutiontimesinCAN.
Comparing these CAN values to those obtained in FlexRay produces the following
results.ThesmallestapplicationcycletimeinFlexRayis22.58mscomparedwith19.69
ms at 357.31 frames per second in CAN. It could be stated than CAN is faster than
FlexRaybuttoputitincontextCANsquickestapplicationcycletimewasachievedat
normal(30%)busloadlevelswhileFlexRaysquickestcyclestimewasachievedunder
HRD conditions with a through put of 5488 frames per second. This is where the
deterministic feature of FlexRay is advantageous. Messages can be scheduled for
transmissionwithagreaterdegreeofcertaintythatthosescheduledontheCANbus.
Testcasethreeinvestigatesthisfurther.
Examining the standard deviations in the ACC application cycle times allows
comparisons be made between the deterministic ST segment in FlexRay and the ET
natureofCAN.Table1321.
Table 13-21: ACC CAN Application Cycle
Standard Deviation
TestCase
Standard
Number
Deviation(s)
1A
396
1B
503
1C
91.34
2A
328.43
Table1322presentsthestandarddeviationsintheACCapplicationcycle.
276
Table 13-22: ACC FlexRay Application

Cycle Standard Deviation
TestCase
Standard
Number
Deviation
3A
183ns
3B
183ns
3C
254ns
3D
559.50s
4A
183ns
AgeneralsummarisationisthattheFlexRayACCapplicationcycletimeshaveahigher
degreeofconsistencywhencomparedtothetimesobtainedinCAN.Thisresultsinall
theCANstandarddeviationtimingsbeinginunitsof microsecondswhiletheFlexRay
timingshavesixoftheeightrecordingsinunitsofnanoseconds.Becauseofthenature
of FlexRays ST segments, unless a message transmits at the same instance in every
applicationcycle,theactualtransmissionwillbeamultipleoftheFlexraycycleearlier
orlatereachtime.InthisACCexampleifamessagegetsdelayedbyoneframecycle
(1.750ms)thenthemessagecannottransmitforoneframecycle.Ifthesamescenario
is examined in CAN the message is able to transmit as soon as it is ready therefore
resulting in a smaller standard deviation time by not having to wait a predefined
period.
13.6 TestCase3: VerificationofTimeTriggeredProperties
First the CAN data is presented and then the FlexRay data is compared to the CAN
results.
To verify the timetriggered properties of Flexray, the application execution times in

CAN under various busloads are compared to the application execution times in
FlexRay.MultiplebusloadsarenotrequiredintheFlexRaytestbecauseconfiguration
277
will be implemented in such a way so the maximum amount of data (for this
configuration)getsaccesstothebuswithoutrestrictions.
13.6.1 CANTesting
Figure 1355 contains the CAN configuration set up as viewed in CANalyzer. The
messageIDsarepresentedinTable1323.Thefinalblockgeneratorattheendofthe
diagramhasanXthroughitbecausetheadditionaldatawasnottransmittedatthat
stage.ThisfunctionblockcontainedIDs4,30,175and350.Thesevalueswerechosen
becausetheygaveaspreadofrangesacrossallapplicationIDs.
AllCANdataisconfiguredforthemaximumpayloadof8bytesandthebusrateisset
to125kbit/s.
Table 13-23: Application IDs
MessageID
CAN
Block
Label (Figure
1255)
1
Timer40ms
20
Msg1
50
Msg20
150
Msg50
Busloads of 17%, 30%, 48%, 63% and 100% are logged. This provides a gradual
progression for increased busloads. At 17% busload only the application data was
transmitted.Ata30%busloadtheloadedmessagesaretransmittedperiodicallyevery
7ms.Thisisincreasedtoevery3msat48%busload.At63%busloadthemessagesare
transmittedevery2msandfinallytheloadedmessagesaretransmittedevery1msat
maximumbusload.
278
Figure 13-55: CAN Configuration Test Three
Table 1324 presents the busload values and the associated application execution
times.
Table 13-24: Application Execution Times
Busload
(%)
App
App
Execution Deadline
Time(s)
(s)
17
0.007472
0.04
30
0.007962
0.04
48
0.009164
0.04
Presenting this data graphically (Figure 1356) demonstrates the extent of the CANs
inabilitymeettimingdeadlinesoncecapacityhasbeenreached.
279
ApplicationExecutionTimes
1
Time(s)
0.2
0.04
0.008
0.0016
0%
20%
40%
60%
80%
100%
120%
Busload(%)
ApplicationExecutionTime(s)
ApplicationDeadline(s)
Figure 13-56: Graph of CAN Application Execution Times
13.6.2 FlexRayTesting
TheFlexRaydatawasgeneratedusingtheCANalyzerconfigurationinFigure1357.The
FlexRaybuswassetforadatarateof10Mbit/s.TheVectorVN3600FlexRayinterface
wasusedasacoldstartnode.
280
Figure 13-57: FlexRay Configuration Test Three
Duetotheframesizebeingsetto512s(seesection12.7)itwasdecidedtoconfigure
all FlexRay data (including messages not associated with the application data) to
transmitineverycycle(thismaximisesbusload).Thisincludedtheapplicationdataand
the loaded data. From Figure 1357 it is observed that there are eight FlexRay
generationblocks.Thisisduetothefourextraframesnotassignedtotheapplication
beingtransmittedfromonesinglefunctionblockgenerator.ThisistheFPblockatthe
bottomofthestack.TheIDsareassignedtoeachslotinthestaticsegment.Theloaded
data(comprised of fourmessages from the CAN results,section 13.6.1) are assigned
thefirstfourslotstherebyhavingIDs1to4.IDs5to11areassignedtotheremaining
staticslots.Thisconfigurationischosentodemonstratethatassigningmessagesinany
orderwillnothaveanyeffectonresults.
By transmitting all eleven messages ID1 to 11 in every FlexRay frame cycle (512s in
length),thisresultsinabusloadof48.75%
281
13.7 Conclusion
AtlowbusloadlevelstheCANACCapplicationcompletesexecutionbeforetheFlexRay
application. As CAN busloads increase the application execution times started to
increasealso.DuetotheconfigurationoftheCANapplication,itsdeadlineswerelikely
to be missed as busloads increase. This was due to the priorities assigned to the
messages not allowing the application data access to the bus as more messages are
transmitted with increased frequency. The deterministic nature of FlexRay is proven
throughtheconsistencyatwhichtheACCapplicationcompletesexecution.
ByFlexRayhavingagreaterthanfivetimeshigherthroughput(at10%busload)than
CAN(atmaximumbusload),thisdemonstratesFlexRaysextrabandwidthfeature.
TheSTdataobtainedfromCHAwastheexactsameastheSTdatafromCHBwhere
redundancy wasimplemented. This further aids the chance of successful reception
andtransmissionoftheseFlexRayframes.
FlexRaystimetriggeredpropertieswereverifiedintestcasethree.Thisisprovenby
examiningtheapplicationsexecutiontimes.UsingtheCANprotocol,CANwasunable
to meet its application deadline of 40ms once the bus was loaded with four extra
messages transmitting periodically every 1ms. Comparing this to FlexRay where the
configuration allowed all eleven messages to transmit every 512s. The FlexRay
applicationdatathereforewasabletocompleteexecutionbeforethereviseddeadline
of7.168msdeadline.
282
VerificationandResults
SectionVConclusion
Conclusion
14 Conclusion:
14.1 ResearchSummary
This chapter providesa summary of theresearchcarriedout, theresearchquestions

arereaddressedandareasofpotentialinfutureresearcharesuggested.
The research began with a broad but indepth examination of automotive protocols
suchasCAN,LINandFlexRay.Thisgaveanunderstandingoftheunderlyingprincipleof
eachprotocol.Afocuswasplacedontimetriggeredandeventtriggeredprotocolsas
FlexRay contained both elements within its frame structure. Previous works were
reviewedprimarilyontimetriggerednetworks,sincetherewasonlyaminimalamount
of work carried out on the FlexRay protocol at the time. Further investigation into
possible methods of scheduling eventtriggered and timetriggered protocols was
undertaken.
Investigative research was carried out into methods used by other authors in the
schedulingofTimeTriggeredandEventTriggeredprotocols.Allpossibletradeoffsand
features of previous works that could help or hinder my work using the FlexRay
protocol were defined. The features of CAN that were required on the FlexRay
applicationweredefinedatthisstagebydecidingwhatwouldconstituteasuccessful
migration.FromthisaprimaryframeworkwasdevelopedfortheSTandDYNsegments
ofFlexRay.Thisevolvedintothefinishedmigrationprocedure.
Furtherindepthresearchwasrequiredintothefeaturesofthedevelopmentboards.
Research was also carried out in parallel into the use and features of
CANalyzer.FlexRay and DECOMSYS designer pro <light>; these programs would
required in depth knowledge for the development of the FlexRay frame and cluster
andalsofortheanalysisofdata.ThepossibilitiesweretogenerateeithertheCANor
284
Conclusion
FlexRaydatafromCANalyzerortogenerateitfromtheFujitsudevelopmentboards.As
the development boards provided greater flexibility for configuration purposes (in
termsofthereferenceapplication)thismethodwasusedwherepossible.
14.2 SummaryofTestingandResults
To verify the framework three test cases were devised. Each test case provided the
frameworktoprocessadifferentapplicationtaskgraphconfiguration.
TestCase1:
The abstract Traction Control Application was processed through the framework to
extractFlexRayframeandclusterparameters.Thetaskperiodsusedweretakenfrom
datalogged from production vehicles (Peugeot207 and an electric Smart Car).Upon
extraction of FlexRay parameters, these parameters were processed using the
DECOMSYSdesignertooltorevealanyparameterviolations.Theaimofthistestcase
wastoextracttheFlexRayparameters;thereforeitwasnotimplementedinhardware.
TestCase2
FollowingthisareferenceACCapplicationwasprocessedthroughtheframework.This
application was configured on the development boards and associated data logged.
Using the ACC application allowed the framework to process a different task graph
structure.ThisallowedtheACCapplicationtobeprocessedthroughtheframeworkto
extract the associated FlexRay frame and cluster parameters. Using these extracted
parameterstheACCapplicationwasimplementedinFlexRay.Theassociateddatawas
logged using CANalyzer. Using the parameters extracted from the framework the
FlexRay configuration of the ACC was setup. This was implemented on the
developmentboardsanddatawasloggedinCANalyzer.
BusloadsanddeadlineswereexaminedfromtheCANresultsandcomparedtothose
obtainedfromFlexRay,todetermineiftheFlexRayapplicationperformedcomparable
totheCANcase.
285
Conclusion
The end results demonstrated that at low data rates CAN performed marginally
superiorthanFlexRay.ThiswasduetotheETnatureoftheCANprotocolallowingthe
messagestransmitonthebuswhenrequired,whereasinFlexRaydataisonlygranted
accesstothebusaccordingtoaschedule.OncedataratesincreasedFlexRayprovided
deterministic and constant timings. The extra capacity of FlexRay was also
demonstratedwithoutcompromisingtheACCapplicationdeadlines.
TestCase3
TheaimofthirdandfinaltestcasewastoverifyFlexRaystimetriggeredpropertiesby
demonstratingitsconstantexecutionofthetestapplicationwhencomparedtoCAN.
The test application was processed through the framework to obtain necessary
FlexRayparameters.ThetestapplicationforbothCANandFlexRaywereimplemented
using CANalyzers function block generators. These parameters were then
implementedinCANalyzeronaFlexRaynetwork.TheapplicationtimingsforCANwere
loggedoverfivebusloadsstartingat17%andfinishingatmaximumload.TheFlexRay
datawasloggedatabusloadlevelof48%.AtthislevelFlexRaywasabletotransmit
thesamenumberofmessagesatahigherfrequencythanCANwasabletocopewith.
In addition to this the FlexRay application execution timings we transmitted every
FlexRayframecycle.TherebytheconsistencyofFlexRaysexecutionoftheapplication
wasproven,whereasCANfailedtomeetdeadlinesunderthemaximumbusload.
286
Conclusion
14.3 ResearchQuestions
Question1:
Whatarethebenefitsofusingthemigrationframeworkversustheuseofagateway?
The full migration procedure reduces the complexity associated with having multiple
protocolsinoperationsidebyside.Thisisachievedbyemployingasingleprotocolthat
allowstheapplicationsfeaturescontinueduse,whileatthesametimeutilisingother
featureofthenewerprotocol.Agatewaymightbemoresuitableifapartialmigration
meetssystemrequirements,whereascompletemigrationreducessystemcomplexity.
Question2:
What migration techniques used in other or similar protocols are applicable in this
research?
FlexRayisauniqueprotocolandthereisnootherprotocolexactlylikebutitthereare
similar protocols like TTCAN for example. Also using some features of protocols that
have commonalities to segments within FlexRay can aid in the development of a
migrationprocedure.Themigrationtechniquesapplicabletothisresearchincludetask
graphanalysis,WCETanalysisandRTAanalysis.
Question3:
Whatparametersarerequiredinrelationtotheapplicationandnetworkprotocolfor
migrationtobeundertaken?
Theapplicationparametersextractedfromtheframeworkare;
287
Conclusion
Taskgraphrelease(start)timeri
Taskgraphdeadline(end)timeDi
WorstCaseExecutionTime(WCET)
Taskperiod
These parameters require the CAN application to be presented in task graph format
beforeapplicationparametersareextracted.
Theframeparametersthattheframeworkprovidesare;
FrameLength
StaticSegmentSize
PayloadSize
StaticSlotSize
NIT
DYNSegmentSize
These parameters are extracted from the framework and can be input to a FlexRay
designertooltodeterminetheassociatedparameters,iftheyarenotalreadyknown.
These frame and cluster parameters allow the configuration and implementation of
theFlexRayapplication.
14.4 AreasforFutureResearch
The migration framework was a success in extracting the FlexRay parameters

necessaryformigration,butthereisroomforfurtherresearchinsomeareas;
Inthereferenceapplication,theonlymethodofrecordinganeventwaswhen
itappearedonthebus.Toobtainmoreaccuratetimingsitissuggestedtotry
288
Conclusion
and record when a message is generated and received by the MCU. In this
thesisthiswasattemptedthroughtheUARTbutthiswasnotpracticaldueto
thedelaythiscausedonthemessagetimings.
While every effort was made to ensure the test cases were as close to real
world a possible, to truly determine the effectiveness of the framework and
parameterstheyshouldappliedtoaliveapplicationsonautomobiles.
Automate the migration process thereby providing initial configuration

parametersallowingthefinalFlexRayparameterstobederived.
Perform parameter validation checks in the framework instead of using a

separatedesigntool.Thiswouldspeedupthemigrationprocedure.
Acostbenefitanalysiscouldbecarriedouttodefineabreakevenpointinthe
migrationprocess.
289
SectionVIAppendices
AppendixA
Appendix A
14.5 PublishedMaterial
An oral presentation and a paper were presented at the AAE conference 2008. This
tookplaceattheRBSWilliamsF1centre,Oxfordshire,onthe23rdofSeptember2008.
Thepresentationandpaperwerebasedontheresearchpresentedinthisthesis.The
paperandpresentationweretitledCANtoFlexRayMigrationFramework
AppendixB
Appendix B
14.6 Bibliography
AjayK.VermaPB,PaoloIenne,2007ProgressiveDecomposition:
AHeuristictoStructureArithmeticCircuits
andRRaAHandErnsR,2007AutomotiveSoftwareIntegration
Bing Wu D L, Jesus Bisba, Ray Richardson, and Jane Grimson V W, Donie
OSullivan,1997,TheButterflyMethodology:AGatewayfreeApproachforMigrating
Legacy Information Systems, Proceedings of the 3rd International Conference on
EngineeringofComplexComputerSystems(ICECCS97),
BroyM,2006,ChallengesinAutomotiveSoftwareEngineering,ICSE06,
Christoph A. Herrmann A B, Kevin Hammond, and Steffen Jost HW L a R P, 2007,
AutomaticAmortisedWorstCaseExecutionTimeAnalysis.
Chuan Ku Lin HW Y, MuSong Chen, and ChiPan Hwang 2007 A Neural Network
ApproachforControllerArea
NetworkMessageSchedulingControlIAENGInternationalJournalofComputerScience
FischerkellerSRaR2007LatestTrendsInAutomotiveElectronicSystems
HighwayMeetsOffHighway?AgriculturalEngineeringInternational:theCIGREjournal
GmbHRB2004BOSCHAutomotiveHandbook6thedition
Guido Gehlen E W, Sven Lukas, CarlHerbert Rokitansky and Bernhard Walke, 2006,
ArchitectureofaVehicleCommunicationGatewayforMediaIndependentHandover.
HaraldHeineckeJB,BMWGroup,KlausPeterSchnelleNM,Bosch,HelmutFennelO
W, Continental, Thomas Weber J R, DaimlerChrysler, Lennart Lundh T S, Ford Motor
Company, Peter Heitkmper R R, General Motors, Jean Leflour A G, PSA Peugeot
Citron, Ulrich Virnich S V, Siemens VDO, Kenji Nishikawa K K, Toyota Motor
Corporation and Thomas Scharnhorst B K, Volkswagen,2006, AUTOSAR Current
results and preparations for exploitation, 7th EUROFORUM conference Software in
thevehicle,Stuttgart,Germany.
II
AppendixB
HelmutFennelSB,Continental,HaraldHeineckeJB,SimonFrst,BMWGroup,Klaus
Peter Schnelle W G, Nico Maldener, Bosch, Thomas Weber F W, Jens Ruh,
DaimlerChrysler, Lennart Lundh T S, Ford Motor Company, Peter Heitkmper R R,
General Motors, Jean Leflour A G, PSA Peugeot Citron, Ulrich Virnich S V, Siemens
VDO, Kenji Nishikawa K K, Toyota Motor Corporation and Klaus Lange T S, Bernd
Kunkel, Volkswagen 2006 Achievements and exploitation of the AUTOSAR
developmentPartnership
LeiJUARaSC,2007,SchedulabilityAnalysisofMSCbasedSystemModels.national
universityofSingapore)
ObermaisserR,2006,ReuseofCANbasedLegacyApplicationsin
TimeTriggeredArchitectures.
PaskvanJRPaJ,2007ExperimentalJitterAnalysisinaFlexCANBasedDriveby
WireAutomotiveApplication
R.C.Papademetriou V P D A K,2006, Heuristic Algorithms for Efficient Wireless
Multimedia Network Design, Proceedings of the 32nd EUROMICRO Conference on
SoftwareEngineeringandAdvancedApplications(EUROMICROSEAA'06),
Rausch M, 2006, FlexRay Speeds automotive safety applications. Automotive DEsign
Line.com)www.automotivedesignline.com
Reinhard Wilhelm J E, Andreas Ermedahl, Niklas Holsti, Stephan Thesing, David
WhalleyGB,ChristianFerdinand,ReinholdHeckmann,TulikaMitra,andFrankMueller
I P, Peter Puschner, Jan Staschulat, Per Stenstrom, 2001 The WorstCase Execution
TimeProblem
OverviewofMethodsandSurveyofTools
SchoeberlRKaM,2007ModelingtheFunctionCacheforWorstCaseExecution
TimeAnalysis
Schwefel J J M a HP, 2005, Markov Chainbased Performance Analysis of FlexRay
DynamicSegment.edAHadan
SpuriM,1996,HolisticAnalysisforDeadlineScheduled
RealTimeDistributedSystems.
Steininger E A a A, 2006, Automatic Parameter Identification in FlexRay based on
AutomotiveCommunicationNetworks.edMHorauer
III
AppendixB
SukHyun Seol Sw L, SungHo Hwang and Jae Wook Jeon,2006, Development of

NetworkGatewayBetweenCANandFlexRayProtocols
For ECU Embedded Systems, SICEICASE International Joint Conference 2006, Bexco,
Busan,Korea.
Suri V C a N,2004, EventTriggered Channels on a TimeTriggered Base, Ninth IEEE
international cinference on Engineering Complex Computer Systems Navigating
ComplexityintheeEngineeringAge,
ThomasNolteyHH,LuciaLoBelloz,2005,AutomotiveCommunicationsPast,Current
andFuture.
ZP.TaoMG,1992SynthesizingCommunicationProtocolConverter:
AModelandMethod
IV
AppendixD
Appendix C
14.7 Calculations
AbstractImplementationCalculations
ParameterCm&JmIdentification
MessageSize(Bytes) BitSizeEquation MessageSize(Bits)
CmEquation
Cm
Jm (s)
55+(10*8)
135
135*8s
1.08
600
55+(10*5)
105
105*8s
0.84
700
55+(10*8)
135
135*8s
1.08
400
55+(10*8)
135
135*8s
1.08
800
55+(10*3)
85
85*8s
0.68
1100
55+(10*7)
125
125*8s
1.00
900
55+(10*8)
135
135*8s
1.08
100
55+(10*8)
135
135*8s
1.08
100
55+(10*8)
135
135*8s
1.08
200
55+(10*2)
75
75*8s
0.60
400
(ms)
AppendixD
wmFirstIteration
Queue
wmEquation
wm(ms)
w1
1.08ms+(((0ms+0.6ms+8s)/100ms)*1.08ms)
1.086566
w2
1.08ms+Sum((((0ms+0.6ms+8s)/100ms)*1.08ms),(((0ms+0.7ms+8s)/200ms)*0.84m
Delay
s))
w3
s),(((0ms+0.4ms+8s)/100ms)*1.08ms))
w4
s),((0ms+0.4ms+8s)/100ms)*1.08ms),(((0+0.8ms+8)/100ms)*1.08ms))
w5
1.089540
1.093946
1.102673
s),(((0ms+0.4ms+8s)/100ms)*1.08ms),(((0+0.8ms+8)/100ms)*1.08ms),(((0+1.1ms+8
1.104180
s)/500ms)*0.68ms))
w6
1.113260
s)/500ms)*0.68ms),(((0+0.9ms+8s)/100ms)*1ms))
w7
s)/500ms)*0.68ms),(((0+0.9ms+8s)/100ms)*1ms),(((0+0.1ms+8s)/500ms)*1.08ms)
1.113493
)
w8
1.114659
,(((0+0.1ms+8s)/100ms)*1.08ms))
w9
1.115109
,(((0+0.1ms+8s)/100ms)*1.08ms),(((0+0.2ms+8s)/500ms)*1.08ms))
w10
1.115721
,(((0+0.1ms+8s)/100ms)*1.08ms),(((0+0.2ms+8s)/500ms)*1.08ms),(((0+0.4ms+8s)/
400ms)*0.60ms)
VI
AppendixD
wmSecondIteration
Queue
wmEquation
wm(ms)
w1
1.08ms+(((1.086566ms+0.6ms+8s)/100ms)*1.08ms)
1.09830
w2
1.08ms+Sum((((1.086566ms+0.6ms+8s)/100ms)*1.08ms),(((1.089540ms+0.7ms+8s)/200ms
Delay
)*0.84ms))
w3
)*0.84ms),(((1.093946ms+0.4ms+8s)/100ms)*1.08ms))
w4
1.10127
1.10568
)*0.84ms),(((1.093946ms+0.4ms+8s)/100ms)*1.08ms),(((
1.11440
1.102673ms+0.8ms+8)/100ms)*1.08ms))
w5
)*0.84ms),(((1.093946ms+0.4ms+8s)/100ms)*1.08ms),(((1.102673ms+0.8ms+8)/100ms)*1.
1.11591
08ms),(((1.104180ms+1.1ms+8s)/500ms)*0.68ms))
w6
1.12499
08ms),(((1.104180ms+1.1ms+8s)/500ms*0.68ms),(((1.113260ms+0.9ms+8s)/100ms)*1ms))
w7
1.08ms+Sum((((1.086566ms+0.6ms+8s)/100ms)*1.08ms),(((1.089540ms+07ms+8s)/200ms)
*0.84ms),(((1.093946ms+0.4ms+8s)/100ms)*1.08ms),(((1.102673ms+0.8ms+8)/100ms)*1.0
8ms),(((1.104180ms+1.1ms+8s)/500ms)*0.68ms),(((1.113260ms+0.9ms+8s)/100ms)*1ms),(
1.12522
((1.113493ms+0.1ms+8s)/500ms)*1.08ms))
w8
08ms),(((1.104180ms+1.1ms+8s)/500ms)*0.68ms),(((1.113260ms+0.9ms+8s)/100ms)*1ms)
1.12639
,(((1.113493ms+0.1ms+s)/500ms)*1.08ms),(((1.114659ms+0.1ms+8s)/100ms)*1.08ms))
w9
1.12684
,(((1.113493ms+0.1ms+8s)/500ms)*1.08ms),(((1.114659ms+0.1ms+8s)/100ms)*1.08ms),(((
1.115109ms+0.2ms+8s)/500ms)*1.08ms))
w10
1.12745
,(((1.113493ms+0.1ms+8s)/500ms)*1.08ms),(((1.114659ms+0.1ms+8s)/100ms)*1.08ms),(((
1.115109ms+0.2ms+8s)/500ms)*1.08ms),(((1.115721ms+0.4ms+8s)/400ms)*0.60ms)
VII
AppendixD
wmthirdIteration
Queue
wmEquation
wm(ms)
w1
1.08ms+(((1.098301ms+0.6ms+8s)/100ms)*1.08ms)
1.098428
w2
1.08ms+Sum((((1.098301ms+0.6ms+8s)/100ms)*1.08ms),(((1.101275ms+0.7ms+8
Delay
s)/200ms)*0.84ms))
w3
s)/200ms)*0.84ms),(((1.105681ms+0.4ms+8s)/100ms)*1.08ms))
w4
1.101402
1.105808
s)/200ms)*0.84ms),(((1.105681ms+0.4ms+8s)/100ms)*1.08ms),(((1.114408ms
1.114534
+0.8ms+8)/100ms)*1.08ms))
w5
1.116041
+0.8ms+8)/100ms)*1.08ms),(((1.115915ms+1.1ms+8s)/500ms)*0.68ms))
w6
+0.8ms+8)/100ms)*1.08ms),(((1.115915ms+1.1ms+8s)/500ms*0.68ms),(((1.1249
1.125121
95ms+0.9ms+8s)/100ms)*ms))
w7
1.08ms+Sum((((1.098301ms+0.6ms+8s)/100ms)*1.08ms),(((1.101275ms+07ms+8
s)/200ms)*0.84ms),(((1.105681ms+0.4ms+8s)/100ms)*1.08ms),(((1.114408ms+0
.8ms+8)/100ms)*1.08ms),(((1.115915ms+1.1ms+8s)/500ms)*0.68ms),(((1.12499
1.125355
5ms+0.9ms+8s)/100ms)*1ms),(((1.125228ms+0.1ms+8s)/500ms)*1.08ms))
w8
+0.8ms+8)/100ms)*1.08ms),(((1.115915ms+1.1ms+8s)/500ms)*0.68ms),(((1.124
1.126521
995ms+0.9ms+8s)/100ms)*1ms),(((1.125228ms+0.1ms+s)/500ms)*1.08ms),(((1.
126394ms+0.1ms+8s)/100ms)*1.08ms))
w9
s)/200ms)*0.84ms),(((1.105681ms+0.4ms+8s)/100ms)*1.08ms),(((1.114408s0.8
ms+8)/100ms)*1.08ms),(((1.115915ms1.1ms+8s)/500ms)*0.68ms),(((1.124995m
1.126970
s+0.9ms+8s)/100ms)*1ms),(((1.125228ms+0.1ms+8s)/500ms)*1.08ms),(((1.1263
94ms+0.1ms+8s)/100ms)*1.08ms),(((1.126844ms+0.2ms+8s)/500ms)*1.08ms))
w10
+0.8ms+8)/100ms)*1.08ms),(((1.115915ms+1.1ms+8s)/500ms)*0.68ms),(((1.124
995ms+0.9ms+8s)/100ms)*1ms),(((1.125228ms+0.1ms+8s)/500ms)*1.08ms),(((1
1.127582
.126394ms+0.1ms+8s)/100ms)*1.08ms),(((1.126844ms+0.2ms+8s)/500ms)*1.08
ms),(((1.127456ms+0.4ms+8s)/400ms)*0.60ms)
VIII
AppendixD
wmFourthIteration
Queue
wmEquation
wm(ms)
w1
1.08ms+(((1.098428ms+0.6ms+8s)/100ms)*1.08ms)
1.098429
w2
Delay
s)/200ms)*0.84ms))
w3
1.08ms+Sum((((1.098428ms+0.6ms+8s)/100ms)*1.08ms),(((1.101402s+0.7ms+8s
)/200ms)*0.84ms),(((1.105808ms+0.4ms+8s)/100ms)*1.08ms))
w4
1.101403
1.105809
1.114536
.8ms+8)/100ms)*1.08ms))
w5
1.116043
w6
+0.8ms+8)/100ms)*1.08ms),(((1.116041ms+1.1ms+8s)/500ms*0.68ms),(((1.1251
1.125123
21ms+0.9ms+8s)/100ms)*ms))
w7
1.125356
1ms+0.9ms+8s)/100ms)*1ms),(((1.125355ms+0.1ms+8s)/500ms)*1.08ms))
w8
1.126522
1ms+0.9ms+8s)/100ms)*1ms),(((1.125355ms+0.1ms+s)/500ms)*1.08ms),(((1.12
6521ms+0.1ms+8s)/100ms)*1.08ms))
w9
1ms+0.9ms+8s)/100ms)*1ms),(((1.125355ms+0.1ms+8s)/500ms)*1.08ms),(((1.1
1.126972
26521ms+0.1ms+8s)/100ms)*1.08ms),(((1.126970ms+0.2ms+8s)/500ms)*1.08m
s))
w10
1.127584
s),(((1.127582ms+0.4ms+8s)/400ms)*0.60ms)
IX
AppendixD
wmFifthIteration
Queue
wmEquation
wm(ms)
w1
1.08ms+(((1.098429ms+0.6ms+8s)/100ms)*1.08ms)
1.098429
w2
Delay
s)/200ms)*0.84ms))
w3
s)/200ms)*0.84ms),(((1.105809ms+0.4ms+8s)/100ms)*1.08ms))
w4
1.101403
1.105809
1.114536
+0.8ms+8)/100ms)*1.08ms))
w5
1.116043
w6
.8ms+8)/100ms)*1.08ms),(((1.116043ms+1.1ms+8s)/500ms*0.68ms),(((1.125123
1.125123
ms+0.9ms+8s)/100ms)*ms))
w7
.8ms+8)/100ms)*1.08ms),(((1.116043ms1.1ms+8s)/500ms)*0.68ms),(((1.125123
1.125356
ms+0.9ms+8s)/100ms)*1ms),(((1.125356ms+0.1ms+8s)/500ms)*1.08ms))
w8
1.126522
3ms+0.9ms+8s)/100ms)*1ms),(((1.125356ms+0.1ms+s)/500ms)*1.08ms),(((1.12
6522ms+0.1ms+8s)/100ms)*1.08ms))
w9
1.126972
s))
w10
1.127584
s),(((1.127584ms+0.4ms+8s)/400ms)*0.60ms)
AppendixD
ObtainingSlack
Path
P1
P2
P3
P4
P5
P6
P7
P8
P9
P10
P11
P12
Tasks
Execution Times of Tasks on
onPath
ChosenPath(ms)
T1,T5,T
2.778429+2.896043+
8,T9
2.306522+2.406972
T2,T5,T
2.641403+2.896043+
8,T9
2.306522+2.406972
T3,T5,T
2.585809+2.896043+
8,T9
2.306522+2.406972
T4,T5,T
2.585809+2.896043+
8,T9
2.306522+2.406972
T1,T5,T
2.778429+2.896043+
8,T10
2.306522+2.127584
T2,T5,T
2.641403+2.896043+
8,T10
2.306522+2.127584
T3,T5,T
2.585809+2.896043+
8,T10
2.306522+2.127584
T4,T5,T
2.585809+2.896043+
8,T10
2.306522+2.127584
T6,T8,T
3.025123+2.306522+
2.406972
T6,T8,T
3.025123+2.306522+
10
2.127584
T7,T8,T
2.305356+2.306522+
2.406972
T7,T8,T
2.305356+2.306522+
10
2.127584
Total
Execution
Time(ms)
Calculate
Slack
per
PathperTask(ms)
Final Slack per

Path per Task
(ms)
10.38797
(26000.01038797)/4
647.4030
10.25094
(26000.01025094)/4
647.4373
10.19535
(26000.01019535)/4
6474512
10.60407
(26000.01060407)/4
647.3490
10.10858
(26000.01010858)/4
647.4729
9.971552
(26000.009971552)/4
647.5071
9.915958
(26000.009915958)/4
647.5210
10.32468
(26000.009915958)/4
647.4188
7.738617
(26000.007738617)/3
864.0871
7.459229
(26000.007459229)/3
864.1803
7.018850
(26000.007018850)3
864.3270
6.739462
(26000.006739462)/3
864.4202
XI
AppendixD
PayloadCalculations
Payload
Size
FlexRay
Frame
Size
15
16
17
18
19
20
21
22
23
10
24
11
25
12
26
13
27
14
28
15
29
16
30
17
31
18
32
19
33
20
34
Calculation of the Number of Messages

Required
(8/1)+(5/1)+(8/1)+(8/1)+(3/1)+(7/1)+(8/1)+(8/1)+(8/
1)+(2/1)
(8/2)+(5/2)+(8/1)+(8/1)+(3/1)+(7/2)+(8/1)+(8/1)+(8/
1)+(2/1)
(8/3)+(5/1)+(8/1)+(8/1)+(3/1)+(7/3)+(8/1)+(8/1)+(8/
1)+(2/1)
(8/4)+(5/1)+(8/1)+(8/1)+(3/1)+(7/4)+(8/1)+(8/1)+(8/
1)+(2/1)
(8/5)+(5/1)+(8/1)+(8/1)+(3/1)+(7/5)+(8/1)+(8/1)+(8/
1)+(2/1)
(8/6)+(5/1)+(8/1)+(8/1)+(3/1)+(7/6)+(8/1)+(8/1)+(8/
1)+(2/1)
(8/7)+(5/1)+(8/1)+(8/1)+(3/1)+(7/7)+(8/1)+(8/1)+(8/
1)+(2/1)
(8/8)+(5/1)+(8/1)+(8/1)+(3/1)+(7/8)+(8/1)+(8/1)+(8/
1)+(2/1)
(8/9)+(5/1)+(8/1)+(8/1)+(3/1)+(7/9)+(8/1)+(8/1)+(8/
1)+(2/1)
(8/10)+(5/1)+(8/1)+(8/1)+(3/1)+(7/10)+(8/1)+(8/1)+(
8/1)+(2/1)
(8/11)+(5/1)+(8/1)+(8/1)+(3/1)+(7/11)+(8/1)+(8/1)+(
8/1)+(2/1)
(8/12)+(5/1)+(8/1)+(8/1)+(3/1)+(7/12)+(8/1)+(8/1)+(
8/1)+(2/1)
(8/13)+(5/1)+(8/1)+(8/1)+(3/1)+(7/13)+(8/1)+(8/1)+(
8/1)+(2/1)
(8/14)+(5/1)+(8/1)+(8/1)+(3/1)+(7/14)+(8/1)+(8/1)+(
8/1)+(2/1)
(8/15)+(5/1)+(8/1)+(8/1)+(3/1)+(7/15)+(8/1)+(8/1)+(
8/1)+(2/1)
(8/16)+(5/1)+(8/1)+(8/1)+(3/1)+(7/16)+(8/1)+(8/1)+(
8/1)+(2/1)
(8/17)+(5/1)+(8/1)+(8/1)+(3/1)+(7/17)+(8/1)+(8/1)+(
8/1)+(2/1)
(8/18)+(5/1)+(8/1)+(8/1)+(3/1)+(7/18)+(8/1)+(8/1)+(
8/1)+(2/1)
(8/19)+(5/1)+(8/1)+(8/1)+(3/1)+(7/19)+(8/1)+(8/1)+(
8/1)+(2/1)
(8/20)+(5/1)+(8/1)+(8/1)+(3/1)+(7/20)+(8/1)+(8/1)+(
8/1)+(2/1)
Number
of Calculation
Total
Total
Messages
for
Required
Bytes
65
65*15
975
34
34*16
544
25
25*17
425
18
18*18
324
17
17*19
323
17
17*20
340
16
16/21
336
10
10*22
220
10
10*23
230
10
10*24
240
10
10*25
250
10
10*26
260
10
10*27
270
10
10*28
280
10
10*29
290
10
10*30
300
10
10*31
310
10
10*32
320
10
10*33
330
10
10*34
340
Bytes
XII
AppendixD
ExperimentalImplementationCalculations
ObtainingSlack
Path
P1
P2
Tasks
Path
on
T1,T3,T4,T
5,T6
T2,T3,T4,T
5,T6
Execution Times of Total

Tasks on Chosen Path Execution
(ms)
Time(ms)
FinalSlackper
Calculate Slack per
Path per Task
PathperTask(ms)
(ms)
0+0+6+2+6+2
16
(12016)/6
17.3333
0+0+6+2+6+2
16
(12016)/6
17.3333
XIII
PayloadCalculations
Payload
Size
FlexRay
Frame
Size
15
16
17
18
19
20
21
22
23
10
24
11
25
12
26
13
27
14
28
15
29
16
30
17
31
18
32
19
33
20
34
CalculationoftheNumberof NumberofMessages
MessagesRequired
(8/1)+(8/1)+(8/1)+(8/1)+(8/1)
+(8/1)
(8/1)+(8/1)+(8/1)+(8/1)+(8/1)
+(8/1)
(8/1)+(8/1)+(8/1)+(8/1)+(8/1)
+(8/1)
(8/1)+(8/1)+(8/1)+(8/1)+(8/1)
+(8/1)
(8/1)+(8/1)+(8/1)+(8/1)+(8/1)
+(8/1)
(8/1)+(8/1)+(8/1)+(8/1)+(8/1)
+(8/1)
(8/1)+(8/1)+(8/1)+(8/1)+(8/1)
+(8/1)
(8/1)+(8/1)+(8/1)+(8/1)+(8/1)
+(8/1)
(8/1)+(8/1)+(8/1)+(8/1)+(8/1)
+(8/1)
(8/1)+(8/1)+(8/1)+(8/1)+(8/1)
+(8/1)
(8/1)+(8/1)+(8/1)+(8/1)+(8/1)
+(8/1)
(8/1)+(8/1)+(8/1)+(8/1)+(8/1)
+(8/1)
(8/1)+(8/1)+(8/1)+(8/1)+(8/1)
+(8/1)
(8/1)+(8/1)+(8/1)+(8/1)+(8/1)
+(8/1)
(8/1)+(8/1)+(8/1)+(8/1)+(8/1)
+(8/1)
(8/1)+(8/1)+(8/1)+(8/1)+(8/1)
+(8/1)
(8/1)+(8/1)+(8/1)+(8/1)+(8/1)
+(8/1)
(8/1)+(8/1)+(8/1)+(8/1)+(8/1)
+(8/1)
(8/1)+(8/1)+(8/1)+(8/1)+(8/1)
+(8/1)
(8/1)+(8/1)+(8/1)+(8/1)+(8/1)
+(8/1)
Required
Cacl for
Total
AppendixD
Bytes
Total
Bytes
40
40*15
600
20
20*16
320
15
15*17
255
10
10*18
180
10
10*19
190
10
10*20
200
10
10/21
210
5*22
110
5*23
115
5*24
120
5*25
125
5*26
130
5*27
135
5*28
140
5*29
145
5*30
150
5*31
155
5*32
160
5*33
165
XIV
5
5*34
170
AppendixD
XV

A CAN To FlexRay Migration Framework

Uploaded by

Copyright:

Available Formats

A CAN To FlexRay Migration Framework

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A CAN To FlexRay Migration Framework

Uploaded by

Copyright:

Available Formats

Waterford Institute of Technology

A CAN to FlexRay Migration

Walsh B.A., B.A.I., M.Sc.

This resulted in the development of FlexRay in 2000 by a consortium originally

The aim of this research is to develop a framework to migrate an application from

2 Automotive Networks Review:

A network is a series of points or nodes interconnected by communication paths

Figure 2-1: A Simple Network Example

A networks function is the transportation of data (e.g. data from a computer to a

Figure 2-2: Bus topology

Figure 2-3: Star Topology

Figure 2-4: Ring Topology

Figure 2-5: Mesh Topology

Figure 2-6: TCP/IP Model

controls, antilock braking systems and trip computer revolutionised automobile

Originally, as automobile manufactures started to develop more electronic based

It is no coincidence that during the 1980s the seminal breakthrough in automotive

Figure 2-7: Cost Vs Data Rate of Different Automotive Protocols

Figure 2-8: Basic Network Configuration

In Figure 210 we see an illustration of a network configuration where each node is

Figure 2-9: Point-to-Point Network

Examining the components of a typical automotive network node reveals a general

Figure 2-10: A Basic Node Comprising of a Sensor and ECU

Figure 2-11: Microprocessor Block Diagram

A basic computer can consist of the following elements; a microprocessor, extra

Figure 2-12: Time Triggered Slots on a Network

A timetriggered communication controller contains a dispatching table in its local

3 CAN (Controller Area Network):

Robert Bosch GmbH originally developed CAN in 1986. It was designed as an

Figure 3-1: CANs relation to the OSI model

The CAN standard version is a CarrierSense MultipleAccess protocol with Collision

Figure 3-2: Terminating Resistors (to stop

Formatted: Bullets and Numbering

Figure 3-3: CAN Standard Frame Format

Figure 3-4: CAN Extended Format

The data frame isthe most common message typeandismadeupofthedata field,

The remote frame is intended to solicit thetransmission of data fromanother node.

Figure 3-5: Remote Frame

Figure 3-6: Error Frame Format

Figure 3-7: Overload Frame Format

Figure 3-8: Arbitration Process

ERROR COUNT is decreased by 1, if it was between 1 and 127. If the

Table 3-1: CAN Error States

A standardised communication protocol simplifies and economises interfacing

The broad market appeal of CAN is that it can be employed in multiple

of 80% with the development of scheduling tools such as Volcano Network

Figure 3-9: TTCAN Matrix Cycle

Figure 3-10: TTCAN Sample Window Time

Because CAN is an established protocol it continues to be widely used within the

FlexRay offers reliable, realtime capable, highspeed data transmission between

Figure 4-1: Possible FlexRay Implementation

Figure 4-2: Star and Bus Topology Combination

FlexRay communication is based on 64 occurs in reoccurring communication cycles,

Figure: 4-3: FlexRay Cycle Structure

Figure 4-4: Node Architecture (Consortium, 2005)

Figure 4-5: Node Components

Figure 4-7: Frame Format (Consortium, 2005)

Because the payload segment contains twobytewords it must contain an even