File Structure of AUTOSAR BSW Modules

Question

I noticed in the last versions of AUTOSAR that the standard does not provide the file structure to follow for BSW modules.

Before, the *.c, *.h files and the different interactions between them were clearly defined, here is an example from the CAN Driver:

- Version 4.3.1

- Version R23-11

Does anyone have an idea on why is that?

Answer 1

Got some info out of our TechBoard Architecture&BSW.

The file structure chapter does not contain the file layout structure anymore, because even in the past, it was incomplete, missing certain information and would have made the diagram less readable.

The information, what the BSW module defines or imports is now part of the chapter 8 API specification:

• the imported types include a table with
  • module from where to import
  • the header where the type can be found
  • the imported type itself

• the types a module defines and also the functions contain in its specification table the element "available via"

• the mandatory and optional interfaces again have each a table with the function itself and the header by which it as available

As you can see, the exclusive areas are provided by the SchM_CanIf.h generated by the Configuration tool. If CanIf would have a CanIf_MainFunction, this would also come from the SchM_CanIf.h now.

As you can see, CanIf would include CanTp.h to access actually CanTp_RxIndication from CanTp, but for CanSM, to access CanSM_ControllerBusOff, there is a separate interface header CanSM_CanIf.h. CanSm itself specifies this again over the API description of CanSM_CanControllerBusOff in the "availabel via CanSM_CanIF.h".

The remaining information can be taken from the AUTOSAR_SWS_BSWGeneral, which is the base of all BSW module specification.

Especially chapter 5 is here the source of information:

Implementation sources could be mandatory (e.g. the static code of a BSW module) or optional (e.g. depending on configuration generation).

There is also a specific naming like <Mip>_Cfg vs <Mip>_LCfg vs <Mip>_PBCfg vs <Mip>_Irq.

You have the freedom for design of configurations to include <Mip>_Cfg.c and <Mip>_LCfg.c parameters into the <Mip>_PBCfg.c configuration file in case you use PostBuild configuration, and mix them in maybe a single data structure of the PostBuild config. Then you would not need the <Mip>_Cfg.c and <Mip>_LCfg.c files.

There is no table for the headers, but there are also some rules.

• <Mip>_Cfg.h for Precompile config, e.g. enable/disable features
  • like #define CAN_DEVERRORDETECT STD_ON
  • or #define CANTRCV_WAKEUP_SUPPORT STD_ON to enable certain code parts/functions/variables, but some other parameters are maybe configured by a PostBuild configuration e.g. <Mip>_PBCfg.c contains
    • PbCfg_A: .CanPncFrameId = 0x500
    • PbCfg_B: .CanPncFrameId = 0x501
• <Mip>_LCfg.h for Linktime config
• <Mip>_PBCfg.h for PostBuild config
• Rte_<Mip>_Types.h for types used in RTE in order to not declare them twice (Impl header vs Rte Header). This should be included by Module Implementation header. The types are actually generated in Rte_Type.h which the Rte_<Mip>_Types.h includes
  • e.g. NvM.h -include-> Rte_NvM_Types.h -include-> Rte_Types.h
• Rte_<Mip>.h - Rte Interfaces of BSW/SWC, should not be included by Implementation header file, but actually source file
  • NvM.h should NOT include Rte_NvM.h
  • NvM.c should include Rte_NvM.h
• SchM_<Mip>.h - declaration of MainFunctions and ExclusiveAreas, shall also be included by source files and not through other headers

So, in the end, you have more freedom, better definitions of where things are defined, and by the other rules in AUTOSAR_SWS_BSWGeneral also some guidelines, what to define where, and where you should not define it. But you have to read a bit more to gather the info.

I guess, the post is long enough to stop here. :D