From c7b97dbc62cabbc8ce6023891a7ddb348696bc0e Mon Sep 17 00:00:00 2001 From: Henrik Wahlqvist Date: Wed, 25 Sep 2024 09:20:18 +0200 Subject: [PATCH] Update docs matching ecuType refactorisation Change-Id: I2537d05337f732162ddee43eab61103048853e6c --- docs/project_config.md | 397 +++++++++++++++++++++++++++-------------- 1 file changed, 259 insertions(+), 138 deletions(-) diff --git a/docs/project_config.md b/docs/project_config.md index 46c1396..40abb97 100644 --- a/docs/project_config.md +++ b/docs/project_config.md @@ -1,29 +1,22 @@ # Project Configuration Files -Configuration files needed by the build system. The "entry point" is the project configuration file given as a command line argument to build.py. This file can contain references to other configuration files and to the software [unit definition files](unit_config.md). +Configuration files needed by the build system. +The "entry point" is the project configuration file given as a command line argument to build.py. +This file can contain references to other configuration files and to the software [unit definition files](unit_config.md). -## Project Config +## Configuration Settings -The project config file contains project specific configuration settings and references to other configuration files. -It is a json file that should be located in the project root. -The project configuration file can override keys/values in the base configuration file. +### File Versioning -Example ProjectCfg.json: +The build system compares the version information in the configuration files with the application version +to make sure a consistent configuration is used. -```json -{ - "ConfigFileVersion": "0.2.1", - "BaseConfig" : "../../ConfigDocuments/BaseConfig.json", - "UnitCfgs": "conf.local/rasters.json", - "ProjectInfo" : { - "projConfig" : "ABC_123", - "a2LFileName": "A2L.a2l", - "ecuSupplier" : "CSP", - "ecuType" : "", - "unitCfgDeliveryDir": "./output/UnitCfgs" - } -} -``` +- "ConfigFileVersion": "0.2.1" + - Project configuration file version. +- "BaseConfigFileVersion": "0.2.1" + - Base configuration file version. +- "UnitsConfigFileVersion": "0.2.1" + - Units configuration file version. ## Base Config @@ -59,121 +52,6 @@ Example BaseConfig.json: } ``` -## Units Config - -The units config file contains information about included software units and scheduling rasters. -The software units are executed in the order they are defined within each time raster definition. - -```json -{ - "UnitsConfigFileVersion": "0.2.1", - "Projects": { - "GEP3_HEP7": { - "Rasters": { - "2ms": [], - "10ms": [ - "VcScBCoord", - "VcScCVehMtn", - "VcScAAccPed" - ], - "100ms": [ - "VcTmEdMon", - "VcAcCtrl" - ] - }, - "SampleTimes": { - "2ms": "0.002", - "10ms": "0.010", - "100ms": "0.100" - } - } - } -} -``` - -## Configuration Settings - -### File Versioning - -The build system compares the version information in the configuration files with the application version -to make sure a consistent configuration is used. - -- "ConfigFileVersion": "0.2.1" - - Project configuration file version. -- "BaseConfigFileVersion": "0.2.1" - - Base configuration file version. -- "UnitsConfigFileVersion": "0.2.1" - - Units configuration file version. - -## ProjectInfo - -### projConfig - -The name of the project. -This name is used in all the configuration files to identify the project. - -### ecuSupplier - -Ecu supplier name. -This is used to choose supplier dependent code generation (possibly in combination with ECU Type), e.g. the core dummy file generation. - -### ecuType - -Ecu type name. -This is used to choose supplier dependent code generation (possibly in combination with ECU Supplier), e.g. the core dummy file generation. - -### unitCfgDeliveryDir - -If this key is defined, the build system will deliver all the unit configuration files into the directory specified. - -### didDefFile - -The name of the file defining all DIDs of the project. - -### srcCodeDstDir - -The source code destination directory. - -### logDstDir - -The log files destination directory. - -### configDir - -The path to a folder containing all the configuration files of the project. -Used to find codeswitches, core-id and DID definition files. - -### interfaceCfgDir - -The path to a folder with csv-files defining the supplier interface configuration. -The files shall be comma separated files, with the delimiter ';'. - -The following files shall exists in the folder: -CAN-Input.csv, CAN-Output.csv, EMS-Input.csv, EMS-Output.csv, LIN-Input.csv, LIN-Output.csv, Private CAN-Input.csv and Private CAN-Output.csv. - -### prjUnitSrcDir - -A file path where the superset of the source code files are found. -This path can/shall use wildcards. -E.g. "./Models/SSP*/Beta/Vc*/src", will match all folders under the Models folder which start with SSP, -and then all folders in Beta starting with Vc, which have a src folder. -The build system only includes files from software units referenced by the units config file. - -### prjUnitCfgDir - -A file path to the unit definition files. -This file is a json file containing all the relevant meta data for the function. -E.g. input parameters, output parameters, calibration labels, local measurement variables, etc... -The unit definition file must match the filename pattern "config_*.json" - -### coreDummyFileName - -Defines the file names of the dummy Core Identifier c code, which is generated by the build environment. - -### useGlobalConst - -If declared, this module is included in the build. If the string is empty no module is included - ### NvmConfig This key configures the NVM area sizes, and the filename of the c-files generated to defined the NVM. @@ -191,7 +69,7 @@ However, the standard says that struct members should be placed in memory in the } ``` -### baseNvmStructs +### NvmStructs This json file holds the order for NVM signals in the structs, it also holds area size and allowed signals. We want to preserve the order for signals. @@ -224,11 +102,254 @@ E.g. Position_16Bit_195 the signal position will then be filled in by buildscrip This key defines the name of the c-files generated, which defines the NVM areas. +### ProjectTemplates + +[ecuType](#ecutype) is used to separate different types of projects. +However, powertrain-build has, as of fda739bc13a2cdd9a3a72e8762fe8443cf6a88da, +been refactored so that it is possible to choose different options individually. + +This key is used to set individual options to match the old ECU types, see example below. + +```json +{ + "ProjectTemplates": { + "Dummy": { + "generalAsilLevelDebug": "B", + "generalAsilLevelDependability": "B", + "generateCalibrationInterfaceFiles": false, + "generateCoreDummy": true, + "generateDummyVar": true, + "generateInterfaceHeaders": false, + "generateYamlInterfaceFile": false, + "propagateTagName": true, + "useA2lSymbolLinks": true, + "useSwcNameAsPrefix": false + } + } +} +``` + +Also see [CodeGenerationConfig](#codegenerationconfig) as the values in there take priority over these. + +#### generalAsilLevelDebug + +Set the ASIL classification for the generated debug and interface files. +Default is "B". + +#### generalAsilLevelDependability + +Set the ASIL classification for the generated "safe" debug and interface files. +Default is "B". + +#### generateCalibrationInterfaceFiles + +Generate calibration interface files, only available when "generateYamlInterfaceFile" is true. +Default is False. + +These files can be used together with a certain type of calibration strategy in the Autosar environment known as double buffering. +The files generates a certain variable called "c\\_TriggerReadRteCData" which can be toggled to read the rest of the calibration variables. +This makes the CPU not overload reading all the calibration variables from the RTE every iteration. + +#### generateCoreDummy + +Generates a file defining dummy versions of functions towards e.g. supplier interface type functions. +Default is False. + +#### generateDummyVar + +Generates a file defining missing signals/variables between Simulink models/source code. +Default is False. + +#### generateInterfaceHeaders + +Generate interface header files, for more information see [MemoryMapConfig](#memorymapconfig). +Default is False. + +Instead of generating required header files, +custom header files can be copied to the output foler by listing them in "includesPaths". +Paths should be relative to the location of *ProjectCfg.json* file. + +#### generateYamlInterfaceFile + +Generate a yaml file containing all metadata for the project. +Default is False. + +#### propagateTagName + +Add the Git tag to the file "vcc_sp_version.h". Currently only used for old Volvo projects. +Default is False. + +#### useA2lSymbolLinks + +Use "SYMBOL_LINK" in the generated A2L file. +Default is False. + +#### useSwcNameAsPrefix + +Use the software component name as prefix in the "common" functions and structs generated by powertrain-build. +"softwareComponentName" needs to be set in [ProjectInfo](#projectinfo). +Default is False. + +## Rasters json File + ### SampleTimes The key "SampleTimes" defines the names of the available time rasters, and the value defines the scheduling time in seconds. ### Rasters -The key "Rasters", defines which units that are scheduled in that raster, -and the order of the list defines the order the units are executed within the raster. +Each \ key defines which units that are scheduled in that raster, +the order of the list defines the order the units are executed within the raster. + +## Project Config + +The project config file contains project specific configuration settings and references to other configuration files. +It is a json file that should be located in the project root. +The project configuration file can override keys/values in the base configuration file. + +Example ProjectCfg.json: + +```json +{ + "ConfigFileVersion": "0.2.1", + "BaseConfig" : "../../ConfigDocuments/BaseConfig.json", + "UnitCfgs": "conf.local/rasters.json", + "ProjectInfo" : { + "projConfig" : "ABC_123", + "a2LFileName": "A2L.a2l", + "ecuSupplier" : "CSP", + "ecuType" : "", + "unitCfgDeliveryDir": "./output/UnitCfgs" + } +} +``` + +### ProjectInfo + +#### projConfig + +The name of the project. +This name is used in all the configuration files to identify the project. + +#### ecuSupplier + +Ecu supplier name. +This is used to choose supplier dependent code generation (possibly in combination with ECU Type), e.g. the core dummy file generation. + +#### ecuType + +Ecu type name. +This is used to choose supplier dependent code generation (possibly in combination with ECU Supplier), e.g. the core dummy file generation. + +#### unitCfgDeliveryDir + +If this key is defined, the build system will deliver all the unit configuration files into the directory specified. + +#### didDefFile + +The name of the file defining all DIDs of the project. + +#### srcCodeDstDir + +The source code destination directory. + +#### logDstDir + +The log files destination directory. + +#### configDir + +The path to a folder containing all the configuration files of the project. +Used to find codeswitches, core-id and DID definition files. + +#### interfaceCfgDir + +The path to a folder with csv-files defining the supplier interface configuration. +The files shall be comma separated files, with the delimiter ';'. + +The following files shall exists in the folder: +CAN-Input.csv, CAN-Output.csv, EMS-Input.csv, EMS-Output.csv, LIN-Input.csv, LIN-Output.csv, Private CAN-Input.csv and Private CAN-Output.csv. + +#### prjUnitSrcDir + +A file path where the superset of the source code files are found. +This path can/shall use wildcards. +E.g. "./Models/SSP*/Beta/Vc*/src", will match all folders under the Models folder which start with SSP, +and then all folders in Beta starting with Vc, which have a src folder. +The build system only includes files from software units referenced by the units config file. + +#### prjUnitCfgDir + +A file path to the unit definition files. +This file is a json file containing all the relevant meta data for the function. +E.g. input parameters, output parameters, calibration labels, local measurement variables, etc... +The unit definition file must match the filename pattern "config_*.json". + +#### coreDummyFileName + +Defines the file names of the dummy Core Identifier c code, which is generated by the build environment. + +#### useGlobalConst + +If declared, this module is included in the build. If the string is empty no module is included. + +### includesPaths + +Use this key to list files that should be included in the source code. +Paths should be relative to the location of *ProjectCfg.json* file. + +### CodeGenerationConfig + +Use the field to choose specific code generation options in powertrain-build. +Key value pairs specified in this struct takes priority over the ones specified in [ProjectTemplates](#projecttemplates). +Afformentioned chapter also describes the available options and their default values. + +### MemoryMapConfig + +This configuration is required when [generateInterfaceHeaders](#generateinterfaceheaders) is set to true. + +Example: + +```json +{ + "MemoryMapConfig": { + "memMapPrefix": "DUMMY", + "includeHeaderGuards": false, + "includeMemMapForCalibration": false, + "projectDefines": { + "START": { + "code": "#define DUMMY_START_SEC_CODE", + "const": "#define DUMMY_START_SEC_CONST_UNSPECIFIED", + "disp": "#define DUMMY_START_SEC_VAR_INIT_UNSPECIFIED", + "cal": "#pragma section \".XcpCalibrationSection\"" + }, + "STOP": { + "code": "#define DUMMY_STOP_SEC_CODE", + "const": "#define DUMMY_STOP_SEC_CONST_UNSPECIFIED", + "disp": "#define DUMMY_STOP_SEC_VAR_INIT_UNSPECIFIED", + "cal": "#pragma section" + } + } + } +} +``` + +#### memMapPrefix + +Prefix of the generated memory map file, e.g. *DUMMY__MemMap.h*. + +#### includeHeaderGuards + +Adds header guards to e.g. *DUMMY__MemMap.h*. + +#### includeMemMapForCalibration + +Also adds the `#include "DUMMY__MemMap.h"` to the calibration header files. +Might not be necessary when using `#pragma section ".XcpCalibrationSection"`. + +#### projectDefines + +A dict with "START" and "STOP" keys each defining key value pairs for what to include in the header file +for code, constants, calibration variables and measurable variables. + +See example above.