uds boo oader 论文

Bootloaderwithreprogrammingfunctionalityforelectroniccontrolunitsinvehicles:Analysis,designandImplementationDavidPehrssonJesúsGarzaEXAMWORK2012ELECTRICALENGINEERINGThisthesisworkisperformedatJönköpingUniversity,SchoolofEngineering,withinthesubjectareaElectricalEngineering.Theworkispartofthetwoyearmaster’sdegreeprogrammewiththespecializationinEmbeddedSystems.Theauthorisresponsibleforthegivenopinions,conclusionsandresults.Examiner:ShashiKumarSupervisor:AlfJohanssonScope:30credits(secondcycle)Date:2012-12-18iAcknowledgementsWewouldliketothankeveryoneatQRTECHforthehelptheyhavegivenusandwewouldespeciallyliketothankAndreasKäckforthetechnicalsupportheprovidedwhenweneededit.WewillalsoliketothankLarsCarlssononQRTECHforallthehelpregardingthemasterthesis.WewouldalsoliketothanktheteachersatJTH,AlfJohanssonandShashiKumarfortheirsupport.AbstractiiAbstractInanautomotivecontexttoday’sneedoftestingfunctionswhileinfactory,correctingfaultsintheworkshoporaddingextravalueintheaftermarketmakesitveryimportanttoeasilybeabletodownloadnewsoftwaretotheelectroniccontrolunitsinvehicles.IntheplatformforstandardautomotivesoftwaredevelopmentcalledAUTOSAR,twoknownprotocolsarepresentedtospecifytheprocedureonhowtoimplementthisdownloadoperation:UnifiedDiagnosticServices(UDS)andtheUniversalMeasurementandCalibrationProtocol(XCP).HoweverthepartoftheUDSandXCPstandardsthatisaboutreprogrammingisnotcompletelyapartoftheAUTOSARstandardyet.Inthisthesis,UDSandXCPhavebeencomparedtoevaluatewhichofthetwothathasmostsupportinAUTOSARtodayandaremostlikelytobefullyintegratedintoAUTOSARinthefuture.SinceUDSalreadyhassupportinAUTOSARforsomeofthefunctionsneededforreprogrammingandbecauseofthefactthatUDSisapartoftheextensivelyusedOn-boardDiagnosticstandard(OBD-II),UDSischosentobethemostsuitableprotocolforimplementingreprogrammingfunctionalityaccordingtoAUTOSAR.AbootloaderwiththeabilitytodownloaddatahasbeendevelopedusingonlyrelevantfunctionsfromUDSandfollowingtheAUTOSARspecificationswhereitisapplicable.SammanfattningiiiSammanfattningFörattkunnatestafordonsfunktionerifabriken,åtgärdamjukvarufelunderserviceellerförattuppgraderafordonetmednyafunktionerärdetviktigtattkunnaladdanernymjukvaratillfordonetsstyrsystem.Denstandardiserademjukvaruplattformenförfordonsindustrin,AUTOSAR,innehållertvåprotokollsombådaspecificerarhurmjukvarakanladdasner:UnifiedDiagnosticServices(UDS)ochUniversalMeasurementandCalibrationProtocol(XCP).TyvärrärdedelarnaavUDSochXCPsombeskrivermjukvarunerladdninginteendelavAUTOSARän.IdethärexamensarbetetharUDSochXCPjämförtsförattutvärderavilkenavdebådasomidagslägetharstörststödförnerladdningavmjukvaraiAUTOSARochvilkensomtroligastkommerattbliendelavAUTOSARiframtiden.EftersomAUTOSARredanstödjernågraavdefunktioneriUDSsombehövsförnerladdningavmjukvarasamtpågrundavattUDSärendelavbranschstandardenförfordonsdiagnostikOBD-II,harUDSvaltssomdenmestlämpadeattidagslägetanvändasförattimplementeranerladdningavmjukvaraenligtAUTOSAR.EnbootloadersomstödjernerladdningavmjukvaraviaUDSharsedanimplementeratsenligtAUTOSAR-specifikationensålångtsommöjligt.KeywordsivKeywordsAUTOSARUDSXCPBootloaderReprogrammingECUSoftwareDownloadsCANTableofContentsvTableofContents1Introduction.............................................................................11.1BACKGROUND.............................................................................................................................11.2PURPOSEANDRESEARCHQUESTIONS..........................................................................................11.3DELIMITATIONS..........................................................................................................................21.4OUTLINE.....................................................................................................................................22Theoreticalbackground..........................................................32.1BOOTLOADER..............................................................................................................................32.2CONTROLLERAREANETWORK...................................................................................................52.2.1ConceptofCAN................................................................................................................52.3AUTOSAR.................................................................................................................................62.4UNIFIEDDIAGNOSTICSERVICES(UDS)......................................................................................92.4.1RelationshipbetweenUDSandAUTOSAR....................................................................142.4.2AnUDSusecase:FlashReprogramming......................................................................192.5UNIVERSALMEASUREMENTANDCALIBRATIONPROTOCOL(XCP)..........................................202.5.1Packets............................................................................................................................212.5.2Security...........................................................................................................................222.5.3Flashprogramming........................................................................................................222.5.4Flashmemoryaccess......................................................................................................232.5.5RelationshipbetweenXCPandAUTOSAR....................................................................252.6ODEEPQR5567DEVELOPMENTPLATFORM............................................................................282.6.1MPC5567........................................................................................................................293Methodandimplementation................................................303.1BOOTLOADERFUNCTIONALITY.................................................................................................303.1.1SetupofMCU(PrimaryBootloader)..............................................................................303.1.2ReprogrammingofMCU(SecondaryBootloader).........................................................343.1.3Creatingthebootloaders................................................................................................343.2USEOFUDS.............................................................................................................................353.3UDSMESSAGES........................................................................................................................353.3.1Frames............................................................................................................................353.3.2ImplementedUDSservices.............................................................................................363.4TOOLSUSED.............................................................................................................................573.4.1ArcticStudio...................................................................................................................573.4.2PEEDI.............................................................................................................................583.4.3SRecord...........................................................................................................................593.4.4CANalyzerandCANcaseXL...........................................................................................604FindingsandAnalysis.............................................................634.1COMPARISONBETWEENUDSANDXCP...................................................................................634.2INITIALIZATIONANDSTARTUP..................................................................................................654.3COMMUNICATION.....................................................................................................................654.3.1Dataflowthroughlayers................................................................................................654.3.2Dataflowthroughlayers,Example:...............................................................................674.3.3DiagnosticSessions........................................................................................................694.4REPROGRAMMING....................................................................................................................745Discussionandconclusions...................................................755.1INCONSISTENCIESINAUTOSARREGARDINGOPERATIONOFTHEBOOTLOADER......................755.2RESULTSOFIMPLEMENTINGACCORDINGTOAUTOSAR.........................................................775.3CONCLUSIONS...........................................................................................................................785.4FURTHERRESEARCH.................................................................................................................78TableofContentsvi6References..............................................................................79ListofFiguresviiListofFiguresFIGURE1-EXAMPLEOFBOOTSTRAPOVERVIEW4FIGURE2-CANFRAMELAYOUT[5]6FIGURE3-OVERVIEWOFAUTOSAR7FIGURE4-MAINSOFTWARELAYERSINTHEAUTOSARARCHITECTURE[8]8FIGURE5-LAYERDIVISIONOFTHEBSWLAYER[8]9FIGURE6-THEMODULESTHATRESIDESINTHELAYERS[8]9FIGURE7-UDSNETWORK11FIGURE8-THECLIENTASANOFF-BOARDTESTER.11FIGURE9-UDSALSODEFINESASECURITYLAYERINORDERTOENCRYPTDATA.13FIGURE10-POSITIONOFTHEDCMMODULEINTHEAUTOSARARCHITECTURE16FIGURE11-INTERACTIONBETWEENDCMANDOTHERMODULES18FIGURE12-XCPFRAME21FIGURE13-COMMUNICATIONOBJECTSBETWEENMASTERANDSLAVE22FIGURE14-ABSOLUTEACCESSMODEINXCP24FIGURE15-FUNCTIONALACCESSMODEINXCP25FIGURE16-XCPINAUTOSAR26FIGURE17-ODEEPQR5567DEVELOPMENTPLATFORM28FIGURE18-DIAGNOSTICSESSIONTRANSITIONS37FIGURE19:VIEWOFPEEDIDEVICE58FIGURE20:LAYOUTOFCONNECTIONSFORCOMMUNICATINGWITHPEEDIANDTARGET58FIGURE21:MAINWINDOWINCANALYZERVER.7.5.6660FIGURE22:CANCASEXLDEVICEANDINTERFACECABLE61FIGURE23:NETWORKHARDWARECONFIGURATIONWINDOW61FIGURE24:MEASUREMENTSETUPCONFIGURATIONWINDOW62FIGURE25:CAPLBROWSER62FIGURE26-COMMUNICATIONBETWEENCANTP,PDUROUTERANDDCMMODULES.68FIGURE27-PROGRAMFLOWWHENTHEECUISINTHEDEFAULTSESSION69FIGURE28-PROGRAMFLOWWHENTHEECUISINTHEEXTENDEDSESSION.70FIGURE29-PROGRAMFLOWWHENTHEECUISINTHEPROGRAMMINGSESSION,PART171FIGURE30-PROGRAMFLOWWHENTHEECUISINTHEPROGRAMMINGSESSION,PART272FIGURE31-PROGRAMFLOWWHENTHEECUISINTHEPROGRAMMINGSESSION,PART373FIGURE32-SCOPEOFTHEMCUDRIVERSPECIFICATION[36]76ListofTablesviiiListofTablesTABLE1:DIAGNOSTICSPECIFICATIONSAPPLICABLETOTHEOSILAYERS10TABLE2-SERVICESPROVIDEDBYDIFFERENTFUNCTIONALUNITSDEFINEDINTHEUDSSTANDARDAPPLIEDTOTHEIRRESPECTIVEUSECASES.14TABLE3-OSIMODEL15TABLE4-BOOTMODES30TABLE5-RCWDLOCATIONS31TABLE6-FRAMELAYOUT35TABLE7-DIAGNOSTICSESSIONCONTROLREQUESTMESSAGELAYOUT38TABLE8-DIAGNOSTICSESSIONCONTROLRESPONSEMESSAGELAYOUT39TABLE9-CONTROLDTCSETTINGSREQUESTMESSAGELAYOUT40TABLE10-CONTROLDTCSETTINGSRESPONSEMESSAGELAYOUT41TABLE11-COMMUNICATIONCONTROLREQUESTMESSAGELAYOUT42TABLE12-COMMUNICATIONCONTROLRESPONSEMESSAGELAYOUT43TABLE13-SECURITYACCESSREQUESTMESSAGELAYOUT44TABLE14-SECURITYACCESSRESPONSEMESSAGELAYOUT46TABLE15-REQUESTDOWNLOADREQUESTMESSAGELAYOUT47TABLE16-REQUESTDOWNLOADRESPONSEMESSAGELAYOUT48TABLE17-TRANSFERDATAREQUESTMESSAGELAYOUT49TABLE18-TRANSFERDATARESPONSEMESSAGELAYOUT50TABLE19-REQUESTTRANSFEREXITREQUESTMESSAGELAYOUT52TABLE20-REQUESTTRANSFEREXITRESPONSEMESSAGELAYOUT52TABLE21-ROUTINECONTROLREQUESTMESSAGELAYOUT53TABLE22-ECURESETREQUESTMESSAGELAYOUT54TABLE23-ECURESETRESPONSEMESSAGELAYOUT55TABLE24-COMPARISONOFFUNCTIONSBETWEENUDSANDXCP64ListofAbbreviationsixListofAbbreviationsAUTOSARAutomotiveOpenSystemArchitectureBAMBootAssistModuleCANControllerAreaNetworkExtRAMExternalRandomAccessMemoryMCUMicrocontrollerUnitMMUMemoryManagementUnitPBLPrimaryBootloaderPCIProtocolControlInformationSIDServiceIdentifierPDUProtocolDataUnitCANTpCANTransportProtocolRCHWResetConfigurationHalfWordROMRead-OnlyMemorySBLSecondaryBootloaderSPESignalProcessingExtensionSRAMInternalStaticRandomAccessMemoryUDSUnifiedDiagnosticServicesXCPUniversalMeasurementandCalibrationProtocolDCMDiagnosticCommunicationManagerPPCPowerPCEABIEmbeddedApplicationBinaryInterfaceTxProcessofdatatransmissionRxProcessofdatareceptionIntroduction11Introduction1.1BackgroundWithintheautomotiveindustrythereisarecurrentneedofloadingnewapplicationsoftwaretotheembeddedunitsresponsibleofvehiclefunctions,whetheritisunderdevelopment,duringmaintenanceorasapost-salesupgrade.Forthistobepossibleitisrequiredthattheseembeddedunits(alsoknownas“ECU”)supportreprogrammingthroughastandardcommunicationinterfacesuchasCAN,FlexRay,LIN,Ethernet,etc.Inrecentyears,severalcarmanufacturers,suppliersandtooldevelopershaveadoptedastandardforthemanagementofvehiclefunctionswithinbothfutureapplicationsandstandardsoftwaremodules;suchstandardisnamedAUTOSAR(AutomotiveOpenSystemArchitecture).OnecaseofsoftwaremodulemanagementispreciselytheareaofECUreprogramming.TheAUTOSARstandard,however,doesnotexactlyspecifyhowtodownloadanewapplicationprogramtoatargetprocessorwithinavehicle’sElectronicControlUnit(ECU).AUTOSARsupportstwostandardsfordiagnosticandcalibrationofvehicleparameters(UDSandXCP,respectively)whichcanalsoprovideresourcesforreprogramminganECU’sprocessor.AnanalysisofcompatibilitybetweeneachofthosestandardsandAUTOSARwillbedoneforselectingthebestofboth.Suchselectionwillleadtothedevelopmentofabootloaderthatwillsupportsystemstart-upandsoftwarefunctionalityforreprogrammingtheQR5567platformviathestandardcommunicationinterfaceCAN.ThisdevelopmentshallmeettherequirementsimposedbyAUTOSARwhereitisapplicable.ThefunctionalityofthebootloaderswillprovideasolutionthatcanbeappliedtoloadandstartsoftwareontotheplatformQR5567,whichcanthenbeusedforfurtherprototyping.Thisdevelopmentwillintendtosatisfytheneedexpressedabovesinceitsoperationcanemulatetheprocessofreprogrammingacar’sECUwhilestillduringdevelopmentinthefactory,orwhilecorrectingafailureinaserviceworkshoporevenwhensomeextrafunctionalityisprovidedintheaftermarket.1.2PurposeandresearchquestionsThepurposeistoanalysethecommunicationprotocolsXCPandUDSfromanAUTOSARperspectivetodeterminewhichoneismostsuitabletouseforreprogrammingofanECUthataredevelopedaccordingtoAUTOSAR.AftertheanalysisisdoneabootloaderthatsupportsthemoreappropriatestandardistobeimplementedonthedevelopmentplatformQR5567accordingtotheAUTOSARspecificationsasfaraspossible.Introduction21.3DelimitationsIntheanalysisofcommunicationprotocolsUDSandXCPonlyfunctionsregardingreprogrammingwillbecovered,otherpartofUDSandXCPwillnotbetakenintoconsiderationwhencomparingthem.OnlyrelevantpartsregardingreprogrammingofAUTOSARwillbeimplemented.ThisreportwillonlyfocusonCANasthecommunicationinterface,eventhoughothercommunicationinterfacesaresupportedinhardware,andXCP,UDSandAUTOSAR.1.4OutlineThefirstpartofthereport,theoreticalbackground,coversthebootloaderconceptandtheconceptsandthestandardsCAN,AUTOSAR,UDSandXCP.Thenextpart,Methodandimplementation,describesthefeaturesofUDSfromanAUTOSARperspectiveandhowUDSandAUTOSARareusedintheimplementation.Inthethirdpart,FindingsandAnalysis,theoutcomeofthefunctionsofthesoftwarethathasbeenimplementedispresented.Thelastpart,DiscussionandConclusions,includesacommentonthecoverageofbootloadersprovidedbyAUTOSAR,summarizestheworkandproposeshowitcanbefurtherdeveloped.Theoreticalbackground32Theoreticalbackground2.1BootloaderAmongthemultipleconceptionsthatexistregardingthedefinitionofabootloaderonecommonapproachisthatitisconsideredtobeafixedpieceofsoftwareorfirmwareresidingatleastpartiallyinthenon-volatilememoryareaofamicroprocessor,suchasROMorFlash.The“firm”conditionofthebootloaderisbasedontheideathatoncedesignedanddevelopedit’snotsupposedtobeobjectofmanychangesormaintenanceduringtheprocessorlifetimeasanapplicationprogramwouldeventuallyundergo.Thedifferentviewsthatexisttowardsthefeaturesandoperationthatabootloadershouldperformareoftenmotivated,forinstance,bythefollowingfactors:Theresourceseventuallyneededbyarunningapplication(time,memory,interrupts)TheresourcessupportedbyeachspecificMCU(typesofmemories,accesstospecialfunctionregisters,interruptstack).Theamountofmemoryavailableforstoringinitializationcode.Despitethesevariationsit’sacommonpracticetoimplementthebootloaderinsuchafashionthatitstartsrunningrightafterpower-up,whethercomingfromasystemsoftwarereset,externalinducedreset(incomingsignalorcommandviacommunicationinterfaceorevent-sensedconfigured),manualresetorbyjustapplyingpowersupplytotheprocessortoturniton.UsuallyembeddedprocessorsfetchandexecutecodefromtheresetvectoratadefinedaddressinROMorFlash,tofurtherjumptoanothersectionofmemorywheretheinitializationcoderesides.Thisisdonetokeeptheresetvectorsmall.Whetheritisduetherequirementsimposedbyanapplicationorthecapabilitiesofaspecificprocessor,atitscoresomeofthemostbasicandgenerallyagreedfunctionalitiesofabootloaderare:Minimalhardwareinitialization.Especiallysinceit’sthefirstcodetheCPUexecutesuponpowerup.Itmightinclude:oEnablingaccessto/initializinginternalRAMoDefaultinitializationofMCUsystemclockforprovisionoftimebaseandprescalers.oSettingupPhaseLockLoops(PLL’s)oInitializationofbaseaddressesforInterruptandExceptionTrapVectorTheoreticalbackground4oInitializationofuserstackpointeroInitializationofcacheand/orexternalmemoryifsuchmemorytypesaresupportedbytheMCU.Identificationoftypeofresetevents(software,manual,hardware,power-up,viacommunicationinterface,etc.)CopyimagefromFlashorROMtoRAMforfasterexecution.Jumptoapplication(alternativelytoOS)andpassprogramcontroltoit.InthebookReal-TimeConceptsforEmbeddedSystems[1]forexample,atypicalflowisshownforabootloaderthatisverysimilartotheonepreviouslydescribed.SuchflowcanbeappreciatedinFigure1.Figure1-Exampleofbootstrapoverview[1]Becauseofitskeyrole,thebootloaderusuallyoccupiesspecialbootblocksintheflashROM,whichhavehardwareprotectionagainstaccidentalerasureandcorruption.Whenitcomestothefeaturesconsideredasconvenienttohaveinabootloader,thefollowingareamongstthemostimportant:Theoreticalbackground5ChecksumverificationofapplicationcodeRemotebootcapabilityReceptionofnewapplicationcode(viaacommunicationinterface)ExecutingflashreprogrammingroutinesfromRAMReceptionofanewflashimageInthisregard,theauthorsofBestPracticesinBootLoaderDesign[2]considera“goodtrait”tohavetheabilitytoperformnetworkboottoquicklydownloadafirmwareimagetothetargetdeviceoveranetworkusingstandardInternetprotocols.AsimilarcapabilityisproposedinReal-TimeConceptsforEmbeddedSystems[1]asitdescribesthewholeconceptofhavingaloaderonthetargetside(embeddedsystem)todownloadanimageintoRAMfromahostsystemviaaserialconnectionorevenEthernet,aftercompletingthenecessaryinitializationwork.2.2ControllerAreaNetworkTheControllerAreaNetwork(CAN)isaserialcommunicationbusprotocoldevelopedbyRobertBoschGmbHandwasfirstreleasedin1986.[3]TheuseofCANhavegrownrapidlysincethebeginningofthe90’sduetotheincreasednumberofECU’susedincarsandothervehicles.TodayCANisoneofthemostwidelyusedcommunicationbussystemintheautomotiveindustry.ItisoneoffiveprotocolsthatareusedinOn-boarddiagnostics(OBD-II)andallcarsandlighttrucksmodels2008andonwardsoldintheUSAhaveCANmandatoryfordiagnosticpurpose.[4]2.2.1ConceptofCANTheCANprotocolcoverstwolayersintheISO/OSIReferenceModel,PhysicalLayerandDataLinkLayer,allLayersaboveisimplementationspecific.TheDataLinkLayerconsistsoftwosublayers,LogicLinkControlsublayer,whichforexampledecideswhichmessagesthatarereceivedareaccepted,andMediumAccessControlsublayer,whichiscontrollingFraming,Arbitration,ErrorChecking,ErrorSignalingandFaultConfinement.ThePhysicallayerhandlestheactualtransferofbitsbetweenthenodeswithrespecttoallelectricalproperties.[5]ACANnetworkconsistsofnodeswhichareidentifiedbyanidnumberinthearbitrationfield.Thearbitrationfieldisusedforprioritizationof