💥💥🔍 🔍 欢迎来到本博客❤️❤️💥💥
🐡优势:❤️博客内容尽量做到通俗易懂,逻辑清晰。
⛳️座右铭:恒心,耐心,静心。
⛳️ 欢迎一起交流分享
目录
配置规范
10.1 配置规范简介
本节补充了相应BSW模块规范第10章的内容。建议阅读以下文档以获得更全面的理解:
- AUTOSAR分层软件架构
- AUTOSAR ECU配置规范
该文档详细描述了AUTOSAR的配置方法论和配置元模型。以下内容仅为该主题的简要概述,不能替代ECU配置规范文档。
10.1.1 配置和配置参数
配置参数定义了BSW模块实现的通用部分的可变性。这意味着只有通用或可配置的模块实现可以根据系统和ECU配置时使用的软件和硬件进行适配。配置参数的配置可以在软件过程中的不同时间实现:编译前、链接前或构建后。文中使用“配置类”一词来指代特定的配置时间点。不同的配置类将导致不同的实现和设计过程,具体规定在本文件及BSW模块自身的规范中。
10.1.2 变体
变体描述了一组配置参数。在一个变体中,参数只能属于一个配置类。不同的使用案例需要不同类型的可配置性,因此提供了以下配置变体:
- VARIANT-PRE-COMPILE:仅允许在“编译前”实现单个配置参数。
- VARIANT-LINK-TIME:允许在“编译前”或“链接时”实现单个配置参数。
- VARIANT-POST-BUILD:允许在“编译前”、“链接时”或“构建后”实现单个配置参数。
10.1.3 容器
容器持有一组配置参数。这意味着所有配置参数都保存在容器中,子容器可以引用其他子容器,并且可以为这些引用分配多重性。多重性定义了包含参数的可能实例数量。配置参数被聚集到容器中,通常是因为:
- 配置参数在逻辑上属于同一组(例如,适用于整个NVRAM管理器的一般参数)。
- 配置参数需要实例化(例如,NVRAM管理器的内存块规范参数——这些参数必须为每个内存块实例化)。
10.1.4 配置参数表
配置参数表分为三个部分:
- 一般部分
- 配置参数部分
- 包含/引用容器的部分
10.1.4.1 一般部分
包含配置参数的基本信息。
10.1.4.2 配置参数部分
- 名称:通过名称标识参数。
- 描述:解释配置参数的意图。
- 类型:指定参数的类型(例如,uint8…uint32),如果可能则标记为“–”。
- 单位:指定参数的单位(例如,ms),如果可能则标记为“–”。
- 范围:指定参数的范围(或可能值),如果可能则标记为“–”。
- SWS项目要求ID:与参数相关的要求标识。
- 容器名称:通过名称标识容器。
- 描述:解释容器的意图和内容。
- 后构建变体:指示该容器在不同后构建变体中是否可以有不同数量的实例。
- 多重性:描述参数在不同后构建变体中的实例数量。
10.1.4.3 包含/引用容器的部分
描述引用有效(子)容器的名称及其多重性和范围/依赖性。
10.1.5 配置类标签
配置参数部分通过标签补充了每种类型的配置类的额外说明:
- 编译前:指示配置参数是否应为编译前配置类。
- 链接时:指示配置参数是否应为链接时配置类。
- 构建后:指示配置参数是否应为构建后配置类。
10.2 一般配置规范
10.2.1 配置文件
有关配置文件结构的更多信息,请参见第5.1章。配置数据文件应具有可读性和可理解性。
10.2.2 配置参数的实现名称
配置参数的名称在相应的BSW模块规范中定义。示例包括:
- 名称:EepNormalWriteBlockSize
- 描述:在正常模式下,每个作业处理周期内写入的字节数。实现类型为Eep_LengthType。
配置参数名称的规范要求与API函数和实现文件的命名原则相同。所有配置参数名称应以模块缩写或其大写形式开头。
10.2.3 Pre-Compile Time Configuration
预编译时配置参数在编译开始之前设置,因此相关配置必须在源代码级别完成。这种配置允许将静态配置与实现解耦。示例代码如下:
/* File: CanTp_Cfg.h */
/* Pre-compile time configuration */
#define CANTP_USE_NORMAL_ADDRESSING STD_OFF
#define CANTP_USE_NORMAL_FIXED_ADDRESSING STD_OFF
#define CANTP_USE_EXTENDED_ADDRESSING STD_ON
10.2.3 编译前配置
编译前配置参数在编译开始之前设置,因此相关配置必须在源代码级别完成。这种配置允许将静态配置与实现解耦。
10.2.4 链接时配置
链接时参数的使用允许在交付为目标代码的BSW模块中实现可配置功能。这种配置在编译后、链接前实现。
10.2.5 构建后配置
10.2.5 Post-Build Time Configuration
后构建时配置机制允许BSW模块在以目标代码形式部署时实现可配置功能。后构建时配置的主要特点和要求如下:
-
后构建配置数据结构的实现:
- 如果BSW模块具有后构建时配置参数,则后构建配置数据必须在一个结构中定义,即后构建配置数据结构。
-
配置指针的使用限制:
- 每个BSW模块的后构建配置数据结构应通过配置指针进行引用。只有ECU状态管理器(EcuM)包含指向需要在BswM初始化之前初始化的后构建配置数据结构的配置指针。其余的BSW模块通过BswM使用配置指针进行初始化。
-
后构建配置数据的存储:
- 后构建配置数据位于一个单独的段中,可以独立于实际代码加载。这种情况适用于可加载的CAN配置等场景。为了实现配置的独立加载,必须知道这些参数的内存布局。
-
指向后构建时可配置数据的引用指针:
- 如果BSW模块在运行时依赖于后构建配置数据,则应使用指向外部配置实例的引用(指针)。该引用应通过BSW模块的初始化函数(即
<Mip>_Init()
)通过一个常量限定的函数参数提供。
- 如果BSW模块在运行时依赖于后构建配置数据,则应使用指向外部配置实例的引用(指针)。该引用应通过BSW模块的初始化函数(即
-
示例代码:
- 示例代码展示了如何定义后构建时配置数据结构和初始化函数:
/* File: ComM_PBcfg.h */ ... /* Type declaration of the Configuration Type */ struct ComM_ConfigType_Tag { ... }; ... /* File: ComM_PBcfg.c */ #include <ComM.h> ... /* post-build time configurable data */ const ComM_ConfigType ComM_Config = { ... }; ... /* File: ComM.h */ #include <ComM_PBcfg.h> ... /* Forward declaration: */ typedef struct ComM_ConfigType_Tag ComM_ConfigType; extern void ComM_Init(const ComM_ConfigType * ComMConfigPtr); ...
- 示例代码展示了如何定义后构建时配置数据结构和初始化函数:
-
固定内存位置的后构建配置:
- 如果后构建配置放置在固定的内存位置,并且没有BSW模块的配置使用在后构建时需要解决的变更点(variation points),则可以将引用解析为常量指针。在这种情况下,将固定指针传递给BSW模块的初始化函数。任何间接引用应尽可能简单。
-
后构建时配置参数的定义:
- 所有后构建时配置参数在后构建时配置源文件中定义,并在后构建时配置头文件中声明。
总结来说,后构建时配置为BSW模块提供了灵活性,使其能够在不重新编程ECU的情况下,根据不同的配置需求进行调整。通过定义后构建配置数据结构和使用配置指针,模块能够在运行时根据需要加载和初始化配置。
10.2.6 配置变体
独立于配置类(编译前、链接时和构建后),配置变体使ECU能够在车辆中根据所选配置变体重用不同角色。不同的配置变体可以在同一配置中存在,这些变体通过不同的变更点进行指示。