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.

.)) post-build BS$ modules

.)) is aiming for AUTOSA implementation of post-build loadable concept for the purpose of reconfiguring the parts of the communication matri,. The following BS$ modules should support post-build in all #)Us &there might be other modules as well related to 1iagnostics, 3ode management, 4etwor" management, etc.(! )om - )ontains signals, P1Us Pdu - )ontains routing of P1Us )an+f - )ommunication on )A4 bus 6in+f &6inTp( - )ommunication on 6+4 bus 5r+f - )ommunication on 5le, a0 bus )anTp - )A4 transport la0er 5rTp - 5le, a0 transport la0er 5r - 5le, a0 dri%er

4ote that if for e,ample 5le, a0 is not used, then no 5le, a0 configuration needs to be programmed into the post-build area. +n case function name or lin"er s0mbol configuration t0pes appear in post-build &such as callouts(, an alread0 e,isting function name or lin"er s0mbol t0pe should be used &for e,ample it is not possible to create a new callout(. Post-build of the transport protocol is concerning onl0 gatewa0 nodes since in some cases transport la0er channels must be updated &for e,ample when new nodes appear on the destination bus(.

VCC post-build use-cases

Use-cases are based on .olcano concept with the purpose of allowing reconfiguration of parts of the communication matri,. Some e,amples of supported use-cases are! A signal is mo%ed from one position to another in the same frame. A signal is mo%ed from one frame to another. The default %alue for a signal is changed. A )A4 frame gets new frame +1. A signal is enabled or disabled. An update bit is added or remo%ed. #tc.

1ue to the 3)A6 restriction, the use-cases in%ol%ing post-build of the 3)A6 will not be supported &e,cept for the 5la, a0 dri%ers(.

7.

Post-build process

All post-build changes in the configuration should be done inside )om 1esigner tool &communication matri, reconfiguration( and #)U )onfiguration tool should be able to automaticall0 generate updated #)U) .alue )ollection containing new post-build parameter %alues. This should be done based on the updated #)U #,tract, )omplete #)U) .alue )ollection and BS$31s deli%ered from suppliers. After e,porting the Updated #)U) .alue )ollection from #)U )onfiguration tool, BS$ 8enerator recei%ed from suppliers should be used to generate new Post-Build )onfiguration &one file for all )O3 stac" modules( at .)), without the need to contact suppliers &5igure /(.

5igure /! Post-build update at .)) &solution 1(

9.

Post-build initiali2ation

This chapter describes an e,ample of how the post-build initiali2ation can be handled. *owe%er, it is not a re:uired nor recommended reali2ation b0 .)) and its purpose is to e,plain better the entire .)) post-build concept. Still, an0 ma;or de%iation from this guideline should be discussed with .)). The post-build initiali2ation is done in the #)U State 3anager. The AUTOSA %ariants of #cu3! 9.' release contains two

#cu3 5i,ed which represents an e,tended %ersion of the AUTOSA 7.1 #cu3. #cu3 5le,ible which contains new concepts such as configurable states. This %ariant will mainl0 be used in .)) pro;ects.

+n principle, configuring post-build using #cu3 5i,ed or 5le,ible re:uire some manual implementation of callouts. The following initiali2ation callouts are common for both 5i,ed and 5le,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. The main reason wh0 there cannot be post-build handling here is that modules &e.g. PO T( ma0 be needed to get the correct post-build configuration &i.e. post-build selectable(. +t is recommended to initiali2e the 1#T &if used( first. Example: 5U4)&%oid, #)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 ) - +t determines which post-build selectable to use for the complete #)U. The integrator will ha%e to write the code so that the correct configuration is chosen. Example: 5U4)&P/)O4ST&#cu3<)onfigT0pe<t, #)U3<.A , #)U3<APP6<)O4ST(, #)U3<)O1#( #cu3<1eterminePb)onfiguration& %oid ( >

AB +ntegrator code - start BA #cu3<)pnfigT0peB m0PB C '? if &#)U<is<6eft<1oor( > m0PB C Dm06eftPB)onfiguration? @ else > m0PB C Dm0 ightPB)onfiguration? @ AB +ntegration code - end BA @ AB #cu3<1eterminePb)onfiguration&( BA voidEcuM_AL_DriverInit%ne( constEcuM_Config !pe" Config$tr ) - This function is called ne,t in order to initiali2e all modules that ha%e to be initiali2ed before the OS is started &pre-compile, lin"time, and post-build configuration selectable or loadable(. The )onfigPtr is the pointer that is set in the 1eterminePB)onfiguration callout &see abo%e(. Example: 5U4)&%oid, #)U3<)O1#( #cu3<A6<1ri%er+nitOne&P/)O4ST&#cu3<)onfigT0pe<t, #)U3<.A , #)U3<APP6<)O4ST(, #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. #)U State 3anager &5le,ible(

+n addition to the common #)U State 3anager initiali2ation, after the OS is started, 5le,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,ible #)U State 3anager /. #)U State 3anager &5i,ed( EcuM_AL_DriverInit &o - 3odules that need OS support but do not need access to the 4% A3 manager are initiali2ed here. This is configured in the #cu31ri%er+nit6istTwo configuration container.

+n addition to the common #cu3 callouts, 5i,ed #cu3 has the following initiali2ation callouts!

EcuM_AL_DriverInit 'ree - 3odules that need OS support and need access to the 4% A3 manager are initiali2ed here &e.g. ha%e sa%ed persistent data in #/(. This is configured in the #cu31ri%er+nit6istThree configuration container. 4ote that 4% A3 3anager is not to be confused with post-build. The 4% A3 3anager is handling data that the application reads and writes into persistent memor0.

The contents of these init callouts are similar to #cu3<A6<1ri%er+nitOne.

)onsistenc0 chec"
Since the post-build configurations are located in separate flash sector, there must be a wa0 to detect the following faults! 1. )orrupt post-build area or no post-build configuration loaded. $rong generator is used to produce the post-build configuration. 3ismatch between pre-compile, lin"-time and post-build configurations. )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. There should be a mechanism to chec" if the pointer %alue is correct &for e,ample ha%ing some %alue stored in the other "nown place in the post-build area and comparing its content(. /. $rong generator

The post-build area should also contain a uni:ue %ersion number of the generator. There should be a mechanism to a%oid the following problems! 7. $rong %ersion of the generator is used in comparison to what was originall0 used. $rong %endor of the generator. $rong module &e.g. using )O3 generator instead of P1U generator(. 3ismatch between P)A6T and PB

$hen generating the post-build configuration, it must be assured that the correct pre-compile and lin"-time configuration is used. There must be a function that can be called from an0 conte,t which is able to determine if the P) and 6T configurations match the PB configuration. 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. +n the initiali2ation phase, these chec"sum are compared.

6ocation of BS$ modules configurations

5or post-build loadable configurations of the BS$ modules, 4. A3 and A3 memor0 areas must be reser%ed and the location and si2e must be agreed with .)) &5igure I(. A complete flash sector should be dedicated to the post-build parameters &the blue part(, and a reser%ed area for A3 should be dedicated for the post-build configurable buffers &for e,ample 7 +-P1Us(. Both 4. A3 and A3 needed b0 the post-build configurations ma0 increase when new configurations are loaded. This must be ta"en into account when integrating the software on the #)U and possible usage of memor0 which is greater than e,pected should be detected in generation time. The location and si2e of the 4. A3 and A3 post-build areas are information that the Tier-1 puts into the Target +nformation file &see 5igure 9(.

5igure I! Post-build configuration in memor0 5igure I shows also the order in which the0 should be configured. +t is possible to ha%e another order if there is a technical reason, otherwise the order abo%e should be "ept &then all #)Us will use the same order which can be good for debugging aspects(. The reason to ha%e a predefined order is to minimi2e the ris" of getting wrong post-build configuration at initiali2ation in the #cu3.

#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(, the following should be configured! EcuMModuleId! Short name of the module &e.g. )om, Pdu , +pdu3(. EcuMModule(ervice! 4ame of the AP+ call e,cept the Short name and the parameters. This is t0picall0 L+nitM for all modules e,cept T# where LStartM is used. This ma0 also differ between #)U State 3anager implementations since AUTOSA does not gi%e a clear description.

The #cu31ri%er+nit6istOne contains one #cu31ri%er+nit+tem for each BS$ module &all modules e,cept #cu3(. The order of the post-build modules should be as listed abo%e. +n 5i,ed #cu3, the container #cu35i,ed)onfiguration contains references to BS$ modules with post-build configurations, while in 5le,ible #cu3 the container#cu35le,)onfiguration contains these references. Both 5le,ible and 5i,ed #cu3Ks contain a static list of post-build configuration reference parameters.

#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(, and this list can be located in a specific location &such as together with the configurations(. This is howe%er not clearl0 specified in the #cu3 specification, so it ma0 not be supported in the #cu3 generator. +f so, some manual wor" is needed. Example of what EcuM generator should generate: EcuM_)enerated_ !pes*' t0pedef struct

> AB Post-build configuration pointers BA )O4STP/)O4ST&)om<)onfigT0pe, #)U3<PB)58, )O3<PB)58()om)fgPtr? )O4STP/)O4ST&Pdu <)onfigT0pe, #)U3<PB)58, P1U <PB)58( Pdu )fgPtr? )O4STP/)O4ST&)an+f<)onfigT0pe, #)U3<PB)58, )A4+5<PB)58( )an+f)fgPtr? )O4STP/)O4ST&)anTp<)onfigT0pe, #)U3<PB)58, )A4TP<PB)58( )anTp)fgPtr? )O4STP/)O4ST&6in+f<)onfigT0pe, #)U3<PB)58, 6+4+5<PB)58( 6in+f)fgPtr? )O4STP/)O4ST&5r+f<)onfigT0pe, #)U3<PB)58, 5 +5<PB)58( 5r+f)fgPtr? )O4STP/)O4ST&5rTp<)onfigT0pe, #)U3<PB)58, 5 TP<PB)58( 5rTp)fgPtr? )O4STP/)O4ST&5r<)onfigT0pe, #)U3<PB)58, 5 <PB)58( 5r)fgPtr? @ #cu33odule)onfiguration efT0pe? EcuM_$+cfg*c STAT+) )O4ST&#cu33odule)onfiguration efT0pe, #)U3<)O4ST( #cu33odule)onfig.alue C > D)om<PBcfg, DPdu <PBcfg, D)an+f<PBcfg, D)anTp<PBcfg, D6in+f<PBcfg, D5r+f<PBcfg, D5rTp<PBcfg, D5r<PBcfg, @? 4ote that #cu3 cannot be configured with the instance names abo%e &e.g. )om<PBcfg(. Also, note that the pointer is located in the same area the pointer points to. This must be configured in the compiler<cfg.h file &where all these macros are defined( and assured after running the lin"er.

+nitiali2ation callouts
5or post-build loadable, onl0 the 1ri%er+nitOne callout is interesting! 5U4)&%oid, #)U3<)O1#( #cu3<A6<1ri%er+nitOne&P/)O4ST&#cu3<)onfigT0pe<t, #)U3<.A , #)U3<APP6<)O4ST( #cu3<)fgPtr( > AB Automaticall0 generated init calls BA ... AB Post build loadable init calls BA )om<+nit&#cu33odule)onfig.alue-E)om)fgPtr(? Pdu <+nit&#cu33odule)onfig.alue-EPdu )fgPtr(? )an+f<+nit&#cu33odule)onfig.alue-E)an+f)fgPtr(? )anTp<+nit&#cu33odule)onfig.alue-E)anTp)fgPtr(? 6in+f<+nit&#cu33odule)onfig.alue-E6in+f)fgPtr(? 5r+f<+nit&#cu33odule)onfig.alue-E5r+f)fgPtr(? 5rTp<+nit&#cu33odule)onfig.alue-E5rTp)fgPtr(? 5r<+nit&#cu33odule)onfig.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. Some e,ample use-cases! Post-build selectable and loadable - An #)U supplier ma"es a door module that can be located in either left or right door. The #)U supplierAintegrator uses post-build selectable for some modules. +n parallel .)) re:uires post-build loadable on communication stac" modules. 3ultiple post-build loadable - +n an ad%anced #)U, post-build loadable is needed for the diagnostic modules. +n parallel .)) re:uires post-build loadable for communication stac" modules. This is not currentl0 used.

Example of post-build selectable and loadable 3i,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, the same post-build loadable must be used. This is illustrated in the following e,ample! 5U4)&P/)O4ST&#cu3<)onfigT0pe<t, #)U3<.A , #)U3<APP6<)O4ST(, #)U3<)O1#( #cu3<1eterminePb)onfiguration& %oid ( > AB +ntegrator code - start BA #cu3<)onfigT0peB m0PB C '? if&#)U<is<6eft<1oor( > m0PB C Dm06eftPB)onfiguration? @ else > m0PB C Dm06eftPB)onfiguration? @ AB +ntegrator code - end BA @ AB #cu3<1eterminePb)onfiguration&( BA 5U4)&%oid, #)U3<)O1#( #cu3<A6<1ri%er+nitOne&P/)O4ST&#cu3<)onfigT0pe<t, #)U3<.A , #)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-E)om)fgPtr(? Pdu <+nit&#cu33odule)onfig.alue-EPdu )fgPtr(? )an+f<+nit&#cu33odule)onfig.alue-E)an+f)fgPtr(? )anTp<+nit&#cu33odule)onfig.alue-E)anTp)fgPtr(? 6in+f<+nit&#cu33odule)onfig.alue-E6in+f)fgPtr(? 5r+f<+nit&#cu33odule)onfig.alue-E5r+f)fgPtr(? 5rTp<+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,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, right( the #)U will ha%e.