You are on page 1of 8

1.

Post-build concept

Based on the time when the configuration of parameters should occur, AUTOSA defines three configuration classes! Pre-compile time, lin" time and post-build time. #ach BS$ module supports one to three configuration %ariants! Pre-compile, lin" time and post-build. #ach parameter in the AUTOSA supports one configuration class in each %ariant &chapter 1' in each S$S(. Post-build allows #)U configuration changes without the need to rebuild the #)U S$. *owe%er, not all parameters support post-build time configuration &ha%e post-build class in a post-build BS$ module %ariant(. +n the conte,t of post-build, it is possible to distinguish between post-build loadable and post-build selectable! • • Post-build loadable - replaceable configuration is located in a separate flash sector. Post-build selectable - #)U is configured with se%eral configurations lin"ed together in an #)U S$ and one of them is chosen at start-up &for e,ample software made to control both left and right door modules where the right configuration is chosen in runtime depending on the pin encoding in the *$ connector(.

+t is possible to mi, post-build loadable and post-build selectable concepts in case .)) recei%es post-build selectable #)U S$ implementation form the suppliers.

/.

.)) post-build loadable

One configuration of post-build changeable BS$ module parameters is loaded into the flash memor0 separatel0 from the #)U S$. At predefined memor0 location, pointers are a%ailable to the addresses where the parameters for each BS$ module could be found. 1uring the initiali2ation in the #)U State 3anager, these parameters are accessed and later used in runtime. 4o code is allowed in the post build area. +n case one or more parameters should be changed, new configuration is generated and loaded into the memor0 without the need to rebuild the #)U S$, as shown in 5igure 1 &note that the complete post-build area must be re-flashed so it is not possible to change single parameters or modules(.

5igure 1! Post-build loadable +t is recommended to locate post-build pointer list and the post-build configuration for each BS$ module on the same flash sector in order to support optimisation of memor0 usage &not lea%ing unnecessar0 unused space between configuration parameter sectors(. +t should also be assured that the flash area is big enough to store future configurations.

1

a0 is not used.(! • • • • • • • • )om . Post-build process All post-build changes in the configuration should be done inside )om 1esigner tool &communication matri.)). )omplete #)U) .. This should be done based on the updated #)U #.ample 5le.. An update bit is added or remo%ed. a0 transport la0er 5r . Post-build of the transport protocol is concerning onl0 gatewa0 nodes since in some cases transport la0er channels must be updated &for e.amples of supported use-cases are! • • • • • • • A signal is mo%ed from one position to another in the same frame.alue )ollection containing new post-build parameter %alues. VCC post-build use-cases Use-cases are based on . 7. P1Us Pdu .olcano concept with the purpose of allowing reconfiguration of parts of the communication matri.)A4 transport la0er 5rTp . BS$ 8enerator recei%ed from suppliers should be used to generate new Post-Build )onfiguration &one file for all )O3 stac" modules( at . 1ue to the 3)A6 restriction.)ommunication on 5le.)) is aiming for AUTOSA implementation of post-build loadable concept for the purpose of reconfiguring the parts of the communication matri. a0 configuration needs to be programmed into the post-build area. #tc.. After e.)ommunication on 6+4 bus 5r+f . The default %alue for a signal is changed.tract.5le.5le. 4etwor" management. a0 dri%er 4ote that if for e.)ontains signals.alue )ollection and BS$31s deli%ered from suppliers. an alread0 e. Some e. / .)) post-build BS$ modules . reconfiguration( and #)U )onfiguration tool should be able to automaticall0 generate updated #)U) . 3ode management.cept for the 5la. +n case function name or lin"er s0mbol configuration t0pes appear in post-build &such as callouts(.)ommunication on )A4 bus 6in+f &6inTp( .ample when new nodes appear on the destination bus(. The following BS$ modules should support post-build in all #)Us &there might be other modules as well related to 1iagnostics.alue )ollection from #)U )onfiguration tool. a0 bus )anTp . then no 5le. etc. a0 dri%ers(.porting the Updated #)U) .ample it is not possible to create a new callout(.isting function name or lin"er s0mbol t0pe should be used &for e. A signal is enabled or disabled.)ontains routing of P1Us )an+f . A signal is mo%ed from one frame to another. A )A4 frame gets new frame +1. without the need to contact suppliers &5igure /(. the use-cases in%ol%ing post-build of the 3)A6 will not be supported &e.

The following initiali2ation callouts are common for both 5i. The main reason wh0 there cannot be post-build handling here is that modules &e.plain better the entire . configuring post-build using #cu3 5i. The post-build initiali2ation is done in the #)U State 3anager. +n principle. it is not a re:uired nor recommended reali2ation b0 .ed and 5le.tended %ersion of the AUTOSA 7. #cu3 5le.ible which contains new concepts such as configurable states.1 #cu3.ible re:uire some manual implementation of callouts.g. The integrator will ha%e to write the code so that the correct configuration is chosen. #)U3<)O1#( #cu3<A6<1ri%er+nit=ero & %oid ( > 1et<+nit&(? @ AB #nd of #cu3<A6<1ri%er+nit=ero&( BA • EcuM_Config !pe" EcuM_Deter#ine$bConfiguration( void ) . an0 ma. Example: 5U4)&P/)O4ST&#cu3<)onfigT0pe<t. *owe%er.A . Post-build initiali2ation This chapter describes an e.)) pro. The AUTOSA %ariants of #cu3! • • 9.)) &solution 1( 9.)) and its purpose is to e.ed or 5le. Example: 5U4)&%oid.' release contains two #cu3 5i.ects.e. #)U3<)O1#( #cu3<1eterminePb)onfiguration& %oid ( > 7 . #)U3<.ible #)U State 3anagers &the0 are called in the same order(! • voidEcuM_AL_DriverInitZero( void ) .This is called first and should not handle the initiali2ation of modules that ha%e post-build.)) post-build concept.+t determines which post-build selectable to use for the complete #)U. +t is recommended to initiali2e the 1#T &if used( first.ed which represents an e.or de%iation from this guideline should be discussed with . post-build selectable(.)).5igure /! Post-build update at .ample of how the post-build initiali2ation can be handled. Still. This %ariant will mainl0 be used in . #)U3<APP6<)O4ST(. PO T( ma0 be needed to get the correct post-build configuration &i.

start BA #cu3<)pnfigT0peB m0PB C '? if &#)U<is<6eft<1oor( > m0PB C Dm06eftPB)onfiguration? @ else > m0PB C Dm0 ightPB)onfiguration? @ AB +ntegration code . after the OS is started. 5i.t in order to initiali2e all modules that ha%e to be initiali2ed before the OS is started &pre-compile. #cu3<)fgPtr ( > AB Automaticall0 generated init calls BA 3cu<+nit&#cu3<)fgPtr-E#cu33odule)onfiguration ef-E#cu33cu)fgPtr(? $dg3<+nit&#cu3<)fgPtr-E#cu33odule)onfiguration ef-E#cu3$dg3)fgPtr(? AB Post build loadable init calls BA )om<+nit&PB6oadable O3F'G(? Pdu <+nit&PB6oadable O3F1G(? @ AB #nd of #cu3<A6<1ri%er+nitOne&( BA 1. #)U3<. Example: 5U4)&%oid. #)U3<APP6<)O4ST(. This is configured in the #cu31ri%er+nit6istTwo configuration container.ible #)U State 3anager /. and post-build configuration selectable or loadable(. lin"time.This function is called ne. 5le. +n addition to the common #cu3 callouts.ible #)U State 3anager will initiali2e the Sch3 and Bsw3 modules in the following wa0! sd EcuM Flexible StartPostOS Sequence «module» EcuM::EcuM «module» SchM::SchM «module» BswM::BswM SchM_Init() BswM_Init(const BswM_ConfigType ) 5igure H! Additional initiali2ation of 5le.ed #cu3 has the following initiali2ation callouts! 9 . #)U State 3anager &5le. #)U3<)O1#( #cu3<A6<1ri%er+nitOne&P/)O4ST&#cu3<)onfigT0pe<t.end BA @ AB #cu3<1eterminePb)onfiguration&( BA • voidEcuM_AL_DriverInit%ne( constEcuM_Config !pe" Config$tr ) . • #)U State 3anager &5i. The )onfigPtr is the pointer that is set in the 1eterminePB)onfiguration callout &see abo%e(.ed( EcuM_AL_DriverInit &o .ible( +n addition to the common #)U State 3anager initiali2ation.A .AB +ntegrator code .3odules that need OS support but do not need access to the 4% A3 manager are initiali2ed here.

)onsistenc0 chec" Since the post-build configurations are located in separate flash sector. A complete flash sector should be dedicated to the post-build parameters &the blue part(. it must be assured that the correct pre-compile and lin"-time configuration is used. The contents of these init callouts are similar to #cu3<A6<1ri%er+nitOne. J . The 4% A3 3anager is handling data that the application reads and writes into persistent memor0. $rong generator The post-build area should also contain a uni:ue %ersion number of the generator. There must be a function that can be called from an0 conte. $rong module &e. and a reser%ed area for A3 should be dedicated for the post-build configurable buffers &for e. )orrupt post-build area or no post-build configuration loaded. there must be a wa0 to detect the following faults! • • • 1. A3 and A3 memor0 areas must be reser%ed and the location and si2e must be agreed with . There should be a mechanism to a%oid the following problems! • • • 7. 3ismatch between P)A6T and PB $hen generating the post-build configuration.g.)) &5igure I(. $rong %ersion of the generator is used in comparison to what was originall0 used.• EcuM_AL_DriverInit 'ree .g. $rong generator is used to produce the post-build configuration. ha%e sa%ed persistent data in #/(. This is configured in the #cu31ri%er+nit6istThree configuration container. +n the initiali2ation phase.pected should be detected in generation time. A3 and A3 post-build areas are information that the Tier-1 puts into the Target +nformation file &see 5igure 9(. A3 and A3 needed b0 the post-build configurations ma0 increase when new configurations are loaded.3odules that need OS support and need access to the 4% A3 manager are initiali2ed here &e. using )O3 generator instead of P1U generator(. 4ote that 4% A3 3anager is not to be confused with post-build.t which is able to determine if the P) and 6T configurations match the PB configuration. lin"-time and post-build configurations. $rong %endor of the generator. There should be a mechanism to chec" if the pointer %alue is correct &for e. This must be ta"en into account when integrating the software on the #)U and possible usage of memor0 which is greater than e.ample 7 +-P1Us(. these chec"sum are compared. Both 4. The location and si2e of the 4. 3ismatch between pre-compile. )orrupt post-build area The #cu3 initiali2ation code fetches the post-build configuration pointers in the pointer table at the beginning of the post-build area. /. 6ocation of BS$ modules configurations 5or post-build loadable configurations of the BS$ modules.ample ha%ing some %alue stored in the other "nown place in the post-build area and comparing its content(. 4. This can be done b0 placing a P) and 6T chec"sum in the P) and 6T configuration and also placing the same chec"sum in the PB configuration.

some manual wor" is needed.ed #cu3.5igure I! Post-build configuration in memor0 5igure I shows also the order in which the0 should be configured.cept the Short name and the parameters. the container #cu35i. so it ma0 not be supported in the #cu3 generator. The order of the post-build modules should be as listed abo%e. The #cu31ri%er+nit6istOne contains one #cu31ri%er+nit+tem for each BS$ module &all modules e. Pdu . This ma0 also differ between #)U State 3anager implementations since AUTOSA does not gi%e a clear description. otherwise the order abo%e should be "ept &then all #)Us will use the same order which can be good for debugging aspects(. EcuMModule(ervice! 4ame of the AP+ call e. +pdu3(. the following should be configured! • • EcuMModuleId! Short name of the module &e.ible and 5i.g.ible #cu3 the container#cu35le. The reason to ha%e a predefined order is to minimi2e the ris" of getting wrong post-build configuration at initiali2ation in the #cu3. This is t0picall0 L+nitM for all modules e.cept #cu3(. Both 5le.)onfiguration contains these references. while in 5le. )om. #cu3 generated cAh-files The idea is that the #cu3 generator produces a list of initiali2ation pointers &e:ual to the list shown in 5igure I(.ed #cu3Ks contain a static list of post-build configuration reference parameters. +n 5i. Example of what EcuM generator should generate: EcuM_)enerated_ !pes*' t0pedef struct N .ed)onfiguration contains references to BS$ modules with post-build configurations. This is howe%er not clearl0 specified in the #cu3 specification. +f so. #cu3 configuration BS$ modulesK configurations 5or each module to be initiali2ed b0 the #cu31ri%er+tem container &the minimum set of BS$ modules that ha%e post-build loadable configurations is shown in 5igure I(. +t is possible to ha%e another order if there is a technical reason. and this list can be located in a specific location &such as together with the configurations(.cept T# where LStartM is used.

)A4+5<PB)58( )an+f)fgPtr? )O4STP/)O4ST&)anTp<)onfigT0pe.)) re:uires post-build loadable for communication stac" modules.)) re:uires post-build loadable on communication stac" modules.alue-EPdu )fgPtr(? )an+f<+nit&#cu33odule)onfig. #)U3<PB)58. AB Post build loadable init calls BA )om<+nit&#cu33odule)onfig. #)U3<. Some e. 5 <PB)58( 5r)fgPtr? @ #cu33odule)onfiguration efT0pe? EcuM_$+cfg*c STAT+) )O4ST&#cu33odule)onfiguration efT0pe. #)U3<APP6<)O4ST( #cu3<)fgPtr( > AB Automaticall0 generated init calls BA .g.h file &where all these macros are defined( and assured after running the lin"er. 3ultiple post-build loadable . 5 +5<PB)58( 5r+f)fgPtr? )O4STP/)O4ST&5rTp<)onfigT0pe. Also.alue-E6in+f)fgPtr(? 5r+f<+nit&#cu33odule)onfig..> AB Post-build configuration pointers BA )O4STP/)O4ST&)om<)onfigT0pe. #)U3<PB)58. D5r+f<PBcfg. This is not currentl0 used. The #)U supplierAintegrator uses post-build selectable for some modules. #)U3<PB)58..alue-E5r)fgPtr(? @ AB #nd of #cu3<A6<1ri%er+nitOne&( BA 3ultiple post-builds +t ma0 happen that multiple post-build areas are needed.A . D6in+f<PBcfg. #)U3<PB)58.alue-E)anTp)fgPtr(? 6in+f<+nit&#cu33odule)onfig.An #)U supplier ma"es a door module that can be located in either left or right door. #)U3<PB)58. #)U3<)O4ST( #cu33odule)onfig. )O3<PB)58()om)fgPtr? )O4STP/)O4ST&Pdu <)onfigT0pe. • H . #)U3<PB)58. post-build loadable is needed for the diagnostic modules. @? 4ote that #cu3 cannot be configured with the instance names abo%e &e.+n an ad%anced #)U. 5 TP<PB)58( 5rTp)fgPtr? )O4STP/)O4ST&5r<)onfigT0pe. #)U3<PB)58. D)anTp<PBcfg. )A4TP<PB)58( )anTp)fgPtr? )O4STP/)O4ST&6in+f<)onfigT0pe. +nitiali2ation callouts 5or post-build loadable. +n parallel . #)U3<)O1#( #cu3<A6<1ri%er+nitOne&P/)O4ST&#cu3<)onfigT0pe<t. DPdu <PBcfg. +n parallel . D)an+f<PBcfg.alue-E)om)fgPtr(? Pdu <+nit&#cu33odule)onfig. 6+4+5<PB)58( 6in+f)fgPtr? )O4STP/)O4ST&5r+f<)onfigT0pe. onl0 the 1ri%er+nitOne callout is interesting! 5U4)&%oid. #)U3<PB)58.alue-E)an+f)fgPtr(? )anTp<+nit&#cu33odule)onfig. D5rTp<PBcfg. D5r<PBcfg.alue-E5rTp)fgPtr(? 5r<+nit&#cu33odule)onfig. )om<PBcfg(. This must be configured in the compiler<cfg.ample use-cases! • Post-build selectable and loadable .alue C > D)om<PBcfg. P1U <PB)58( Pdu )fgPtr? )O4STP/)O4ST&)an+f<)onfigT0pe. note that the pointer is located in the same area the pointer points to.alue-E5r+f)fgPtr(? 5rTp<+nit&#cu33odule)onfig.

#)U3<.alue-E5r+f)fgPtr(? 5rTp<+nit&#cu33odule)onfig.A .alue-E)anTp)fgPtr(? 6in+f<+nit&#cu33odule)onfig. I . right( the #)U will ha%e.A .alue-E)an+f)fgPtr(? )anTp<+nit&#cu33odule)onfig.alue-E6in+f)fgPtr(? 5r+f<+nit&#cu33odule)onfig. #)U3<APP6<)O4ST(.end BA @ AB #cu3<1eterminePb)onfiguration&( BA 5U4)&%oid.Example of post-build selectable and loadable 3i. the same post-build loadable must be used.alue-E)om)fgPtr(? Pdu <+nit&#cu33odule)onfig.ing post-build selectable and loadable will not be a problem as long as the following restriction is followed! egardless of post-build that is selected in the #cu3<1eterminePb)onfiguration call.ample! 5U4)&P/)O4ST&#cu3<)onfigT0pe<t.start BA #cu3<)onfigT0peB m0PB C '? if&#)U<is<6eft<1oor( > m0PB C Dm06eftPB)onfiguration? @ else > m0PB C Dm06eftPB)onfiguration? @ AB +ntegrator code . #)U3<)O1#( #cu3<A6<1ri%er+nitOne&P/)O4ST&#cu3<)onfigT0pe<t. #)U3<)O1#( #cu3<1eterminePb)onfiguration& %oid ( > AB +ntegrator code .alue-EPdu )fgPtr(? )an+f<+nit&#cu33odule)onfig. This is illustrated in the following e.ample shows that regardless of if it is a left or right configuration the same post-build loadable configuration will be used. This wor"s since the correct post-build configuration can be downloaded when it is "nown which role &left. #)U3<. #)U3<APP6<)O4ST( #cu3<)fgPtr( > AB Automaticall0 generated init calls BA 3cu<+nit&#cu3<)fgPtr-E3cu)fgPtr(? $dg+f<+nit&#cu3<)fgPtr-E$dg+f)fgPtr(? O AB Post build loadable init calls BA )om<+nit&#cu33odule)onfig.alue-E5rTp)fgPtr(? 5r<+nit&#cu33odule)onfig.alue-E5r)fgPtr(? @ AB #nd of #cu3<A6<1ri%er+nitOne&( BA Abo%e code e.