Autosar学习----AUTOSAR_SWS_BSWGeneral（二）

天马行空工作坊

已于 2024-09-13 09:57:06 修改

阅读量427

点赞数 21

分类专栏：汽车电子中间件文章标签：学习服务器运维架构汽车电子汽车

于 2024-09-13 09:56:23 首次发布

本文链接：https://blog.csdn.net/zhangxiaio1/article/details/142093945

版权

汽车电子中间件专栏收录该内容

10 篇文章 0 订阅

订阅专栏

Autosar学习----AUTOSAR_SWS_BSWGeneral（二）

文档的前四章概述

文档的前四章主要介绍了AUTOSAR基本软件（BSW）模块的背景、设计约定、约束和代码结构。首先，文档概述了BSW模块的设计目标，即通过模块化的架构来提高汽车电子控制单元（ECU）的开发效率、可重用性和跨平台灵活性。随后，文档规范了技术术语、符号和代码示例的格式，以确保读者在理解模块规范时的一致性。在第三部分中，文档详细讨论了BSW模块的约束与假设，特别是在硬件依赖、系统资源限制、实时性要求等方面，帮助开发人员在不同环境中设计适用的模块。第四部分则重点描述了BSW模块的文件和代码结构，包括模块实现文件、头文件、配置文件和中断服务例程的组织方式，强调了文件命名规则、接口定义以及中断处理的简洁性。此外，文档还介绍了链接时间和后期编译配置源文件的使用方式，以便在不同的硬件平台上灵活配置模块。这些章节为BSW模块的设计、开发和集成奠定了坚实的基础。

5. 模块与其他模块的依赖关系

5.1 概述

文档的第五部分讨论了AUTOSAR基本软件（BSW）模块与其他模块之间的依赖关系。它指出每个BSW模块不仅仅是单独运作的，而是需要与其他模块协作才能实现系统的整体功能。这部分文档描述了模块文件结构、接口定义以及如何通过这些机制使模块之间能正确交互。

5.2 文件结构

BSW模块的文件结构中规定了模块实现和配置文件的组织方式。文件结构不仅仅定义了模块内部的文件组织，也为与其他模块进行接口通信提供了基础。文件结构定义了模块的实现文件、头文件、配置文件等的命名和组织规则，以保证模块的可扩展性和易集成性。

具体约束：

模块实现前缀：模块的文件名应遵循实现前缀规则，即模块的文件名应由模块缩写、供应商ID、供应商API前缀等组成。这样命名的目的在于确保模块在不同的供应商实现中具有一致性和可区分性。

原文举例：

模块实现前缀示例：FrIf是FlexRay接口模块的前缀，用于形成诸如API名称、符号和文件名的标识符。
EEPROM驱动模块前缀示例：Eep_21_LDExt表示该EEPROM驱动模块，其供应商API前缀为“LDExt”，供应商ID为21。

翻译后的举例：

一个典型的CAN接口模块可能会使用CanIf_MainFncs.c、CanIf_Api.c来表示其主要功能和API实现文件，以确保在不同模块和供应商间能够区分开来。

笔记：

模块实现前缀确保了在不同供应商和不同实例之间能够正确区分模块。这种命名规则对于避免代码冲突至关重要，尤其是在集成多个模块时。

5.3 导入与导出信息

AUTOSAR BSW模块规定了如何正确处理导入和导出信息，以保证模块的独立性和功能安全性。

导入信息的限制：每个模块应仅导入其所需的头文件或信息，避免过度依赖其他模块的不必要部分。这可以减少编译时间，减少模块间的耦合，避免出现意外的依赖问题。

原文举例：

NVRAM管理器不需要知道处理器的所有寄存器，因此不能因为一个实现文件中包含了处理器寄存器文件就让NVRAM管理器也导入它。

翻译后的举例：

假设一个存储管理模块仅需要从另一个模块导入某个错误码常量，它不应导入该模块的完整实现文件，只需导入相关头文件即可。
导出信息的限制：模块应只导出其他模块明确需要的API和信息，避免导出不必要的实现细节，以防止其他模块错误地使用这些功能。

原文举例：

NVRAM管理器仅应导出错误管理接口，而不应导出其内部存储逻辑或处理器相关信息。

翻译后的举例：

通信模块仅导出发送和接收消息的接口函数，例如Com_SendSignal()，而不对外暴露其内部的缓冲区管理和调度机制。

笔记：

控制导入与导出的信息是实现模块化设计的关键，有助于减少模块之间的耦合性，增加模块的独立性和安全性。
限制导入信息的数量，可以减少编译时间和模块间依赖，提高模块的可移植性。

5.4 模块接口与依赖

文档还规定了模块之间的接口定义和依赖关系。BSW模块通过接口与其他模块进行通信，这些接口的定义必须明确且具有一致性。

接口定义：每个BSW模块都需要定义自己的接口，确保其他模块能够通过这些接口正确调用其功能。接口通常包括API函数、宏定义、以及必要的全局数据类型声明。

原文举例：

FlexRay接口模块（FrIf）依赖于底层的FlexRay驱动模块，因此在接口定义中，FrIf模块应提供用于调用底层FlexRay硬件的API，如FrIf_SendFrame()。

翻译后的举例：

在CAN接口模块（CanIf）中，接口函数CanIf_Transmit()用于将数据发送至底层CAN驱动模块，确保通信的顺利进行。
依赖性管理：每个BSW模块必须管理其与其他模块的依赖关系，确保其导入的模块已经正确初始化，并且接口调用符合预期的时序。

原文举例：

BSW模块应在调用NVRAM存储管理模块之前，确保该模块已经完成初始化，否则将会导致错误的内存访问。

翻译后的举例：

一个存储管理模块必须确保在系统初始化后再调用CAN驱动模块，否则未初始化的CAN接口可能会导致系统崩溃。

笔记：

模块的接口定义是模块之间正确通信的基础，必须明确且符合AUTOSAR的标准化规范。
模块之间的依赖管理至关重要，必须在模块初始化和调用时序上进行严格管理，避免因为依赖问题导致的系统错误。

5.5 版本检查

为了确保模块之间的兼容性，AUTOSAR要求每个BSW模块在集成时必须执行版本检查。每个模块通过预处理器指令检查其导入的头文件版本是否与当前模块的版本一致。如果模块之间版本不兼容，系统将报告错误。

版本检查机制：每个模块应在编译时通过预处理器检查导入模块的版本号，以确保它们属于相同的AUTOSAR版本。版本检查通常包括对主要版本号和次要版本号的检查。

原文举例：

如果CAN接口模块导入了与其版本号不匹配的CAN驱动模块的头文件，系统将抛出编译错误，提示版本不一致。

翻译后的举例：

如果一个通信管理模块导入了一个旧版本的NVRAM管理模块头文件，在版本号检查中发现不一致，编译时系统将会触发版本冲突错误，以避免潜在的集成问题。

笔记：

版本检查是模块集成中的关键步骤，确保不同模块在相同的AUTOSAR版本下进行开发和集成，可以避免因版本不兼容引发的系统崩溃和错误。
开发团队应定期更新模块版本，并确保所有模块的版本号一致，尤其是在进行系统集成时。

5.6 链接时间配置源文件（Link Time Configuration Source）

AUTOSAR系统中的一些模块支持在链接时间进行配置。这种配置方法允许模块在编译完成后，系统链接时定义某些参数或功能，而不需要修改源代码。这种配置方式提高了系统的灵活性，特别是在需要为不同系统定制模块时。

定义：

链接时间配置指的是通过配置文件或配置代码在系统链接阶段对模块进行参数设置或功能选择。

案例：

在CAN接口模块中，某些参数（如缓冲区大小或通道数量）可以在链接时进行配置，以适应不同的硬件平台或应用需求，而无需修改模块源代码。

笔记：

链接时间配置使得模块在不重新编译的情况下能够灵活调整其行为，以适应不同的硬件或系统需求。

5.7 后期编译配置源文件（Post-build Time Configuration Source

与链接时间配置类似，后期编译配置允许在系统部署后，通过对配置文件的修改对模块进行定制。后期编译配置为系统在部署后的灵活性提供了更多支持，适用于需要根据具体部署环境进行动态调整的模块。

定义：

后期编译配置允许在编译和链接完成之后，通过加载不同的配置文件对模块进行调整。这样可以在不改变模块源代码的情况下，为不同的应用场景配置不同的功能。

案例：

在诊断模块（如Dem模块）中，可能需要根据具体车辆的运行状态动态调整诊断策略。这种调整可以通过后期编译配置实现，无需重新编译模块。

笔记：

后期编译配置能够进一步提升系统的灵活性，特别是在不同应用场景下对功能进行动态调整时非常有用。

5.8 中断帧实现文件（Interrupt Frame Implementation Source）

AUTOSAR中的某些BSW模块需要实现中断服务例程（ISR），用于处理硬件或软件中断。中断帧实现文件用于实现这些中断处理逻辑。中断处理是实时系统中的关键部分，因此文档中强调了其实现需要保持简洁、高效，以减少系统的延迟和资源消耗。

定义：

中断帧实现文件负责管理BSW模块中断服务例程的实现，并确保中断处理逻辑能够及时响应。

案例：

在定时器模块中，当定时器溢出时会触发中断服务例程，模块必须快速响应定时器溢出事件，并执行相应的任务调度。该实现文件应尽可能保持中断逻辑的简洁，避免进行复杂计算或占用大量时间。

笔记：

中断帧实现文件必须实现高效的中断服务例程，以确保系统的实时性。复杂的处理应移至主程序或后台任务中执行。

5.9 头文件结构（Header File Structure）

BSW模块的头文件定义了模块的API、数据类型和宏，这些文件是模块与外部交互的重要接口。文档中详细规定了头文件的结构，以确保模块间的接口定义一致，并遵循AUTOSAR的命名和结构要求。

定义：

头文件用于声明模块的公共接口、数据类型、常量和宏定义。每个模块必须提供一个或多个头文件供其他模块引用。

结构要求：

实现头文件：每个BSW模块的头文件必须包含模块的API声明，以及必要的全局数据类型和常量的声明。头文件应避免包含不必要的内部实现细节，确保模块的接口清晰简洁。
保护机制：头文件必须包含保护机制（如#ifndef、#define），以避免多次包含导致的编译错误。

案例：

在CAN接口模块中，头文件CanIf.h中声明了API接口函数（如CanIf_Transmit()）和必要的常量定义（如CAN_MAX_MESSAGE_LENGTH），其他模块可以通过包含该头文件来调用CAN接口的功能。
笔记：

头文件是模块与外部交互的关键，必须遵循AUTOSAR的标准化要求，以确保模块间接口的统一和规范。
头文件应尽量减少内部实现细节的暴露，防止模块之间的耦合度过高。

5.10 版本检查

版本检查机制：每个模块应在编译时通过预处理器检查导入模块的版本号，以确保它们属于相同的AUTOSAR版本。版本检查通常包括对主要版本号和次要版本号的检查。

原文举例：

如果CAN接口模块导入了与其版本号不匹配的CAN驱动模块的头文件，系统将抛出编译错误，提示版本不一致。

翻译后的举例：

如果一个通信管理模块导入了一个旧版本的NVRAM管理模块头文件，在版本号检查中发现不一致，编译时系统将会触发版本冲突错误，以避免潜在的集成问题。
笔记：

版本检查是模块集成中的关键步骤，确保不同模块在相同的AUTOSAR版本下进行开发和集成，可以避免因版本不兼容引发的系统崩溃和错误。
开发团队应定期更新模块版本，并确保所有模块的版本号一致，尤其是在进行系统集成时。

5.10 代码生成

AUTOSAR的BSW模块依赖于大量的配置，而这些配置通常通过工具生成相应的代码。代码生成部分主要包括对配置文件（如 .arxml 文件）进行解析，然后生成相应的C代码和头文件。这部分生成的代码通常是模块的配置项和接口的实现。

自动化配置
：AUTOSAR的配置工具（如ECU配置工具）会根据 .arxml 文件生成用于初始化、参数设定和接口定义的代码。开发人员可以通过这些工具定义BSW模块的具体参数，比如CAN接口的通道数、诊断服务的处理策略等。

举例：

ECU配置：开发人员使用AUTOSAR工具为某个ECU定义通信参数（如CAN总线速度、消息过滤规则等），这些参数会被生成到CAN模块的配置源文件中（如 Can_Cfg.c）。CAN模块通过读取这些生成的配置文件来初始化相应的硬件和软件组件。

生成的代码文件：

配置源文件（Configuration Source Files）：如 *_Cfg.c 和 *_Cfg.h 文件，这些文件包含了模块的初始化数据和配置项。配置文件的生成依赖于开发人员在配置工具中的选择。
API定义：工具还会生成模块的接口函数（API），这些API的实现或多或少依赖于配置工具的输出文件。

举例：

对于通信管理模块，生成的配置文件可能包含Com_ConfigType结构体的定义，该结构体持有系统中的信号组、消息等信息。在运行时，通信模块会根据这些配置文件来正确处理消息的发送和接收。

总结

第五章主要讨论了AUTOSAR基本软件（BSW）模块的依赖关系和文件结构。模块通过文件结构和模块实现前缀进行组织，确保在集成时的清晰性和一致性。该章节还介绍了如何通过链接时间配置源文件和后期编译配置源文件灵活配置模块，以适应不同的硬件平台。中断帧实现文件用于处理中断，强调简洁和高效。头文件结构定义了模块的接口，确保了模块间的正确通信。模块间的导入与导出信息以及依赖性管理通过定义明确的接口和版本检查进行控制，以确保系统的稳定性。通过代码生成，工具可以自动处理模块的配置、依赖关系和错误检查，保证系统的可扩展性与适应性。