全部学习汇总： GitHub - GreyZhang/hack_autosar: learning autosar documents, aha, very hard!
继续学习AUTOSAR，梳理《AUTOSAR_RS_ECUConfiguration》文档。
来自软件组件的需求
支持AUTOSAR软件组件集成
AUTOSAR SW组件应在ECU上实例化。必须提供相关信息，以使其能够在该ECU上集成和执行。
AUTOSAR软件组件的支持服务配置
ECU配置应支持AUTOSAR SW组件和AUTOSAR服务之间接口的配置。
在ECU配置期间，需要配置AUTOSAR SW组件服务访问的特定值。
用例：SWC需要具有符号ID的NVRAM块。NVRAM管理器配置正在分配特定的ID值，需要在SWC中配置这些值。
一个OS任务中可运行实体的执行顺序
应能够描述具有跨软件组件边界的操作系统任务的可运行实体的执行顺序。
SW-C模板只能描述一个SWC内可运行实体的执行顺序约束。但必须能够描述映射到特定OS任务的SWC可运行实体之间的执行顺序，以建立控制流算法，其中控制流以定义的顺序从一个SW-C传递到下一个SW-C。
用例：三个周期性执行的可运行实体映射到一个OS任务。必须定义在激活OS任务时这些可运行实体的执行顺序。
对配置参数定义的要求
支持通用配置编辑器
ECU参数定义应以工具可处理格式定义。参数定义应包含足够的信息，以支持通用配置编辑器。
通用配置编辑器可以读入标准化和硬件供应商特定参数的参数定义。然后，它可以显示所有定义的参数，并允许用所有定义的参数填写ECU配置说明。
用例：减少配置ECU所需的配置编辑器的数量。简单的BSW模块应可通过通用配置编辑器进行配置。这也减少了BSW供应商的工作量，他们不需要为简单的BSW模块编写特定的配置编辑器。
处理需求
这些要求提供了文档的目标信息。它们只是在用于传达操作并将在稍后阶段删除的意义上提供信息。
确定机制而不是标准
WP 产品只会确定可用于配置 ECU 的方法和机制，但不会确定配置工程师必须考虑的任何工程权衡（例如在性能和尺寸之间）。
这些机制独立于应用程序，因此无法评估所有潜在影响。利用应用程序构建机制的工程师必须考虑特定于应用程序的权衡。
用例：配置参数定义只会定义有效范围，但不会提供寻找最佳设置的算法。
阐明配置术语
确保通过词汇表条目或其他文档充分解释引入 AUTOSAR 的所有配置术语。
用例：“预编译配置”、“链接时配置”和“构建后配置”等术语的含义取决于它们在开发中的应用点。 工作包必须确保所使用的任何术语对于它可能出现的每个上下文都得到充分澄清。
4.6 外部要求
这些是 ECU 配置描述本身无法满足的要求。 这些要求适用于其他 AUTOSAR 工作产品。
BSW 模块的内存需求
BSW 模块应提供有关模块内存需求的信息。当内存需求取决于实际配置时也是如此。
所需的内存量通常取决于模块的配置，最迟在配置后最终确定。
用例：COM 堆栈的构建后数据大小不同，具体取决于发送和接收的帧数，生成的代码的代码大小 (ROM) 可能会有所不同。 RAM 和 EEPROM 中的数据结构也可能不同。
识别未初始化的资源。
ECU 配置应识别 ECU 中存在的未使用资源。
未由任何 BSW 模块（标准 AUTOSAR 或复杂设备驱动程序）使用的资源不会由 ECU 软件初始化。 这可能会影响 ECU 的稳健性并导致意外中断或导致虚假 EMC 问题。注意：这是对工具的要求 - 而不是模板）
用例：当识别出未使用（因此未初始化）的资源时，用户可以向 ECU 添加适当的驱动程序，这些驱动程序至少初始化这些资源（例如 显式禁用未使用的中断或 I/O 端口）。
识别微控制器寄存器的冲突使用
ECU 配置工具应识别由多个 BSW 模块以不一致方式配置和/或访问的微控制器寄存器。
BSW 模块（AUTOSAR 驱动程序、复杂驱动程序等）可以直接访问微控制器寄存器。 当 BSW 模块（甚至可能来自不同供应商）被集成到单个 ECU 中时，这些模块可能会尝试以不同方式配置相同的微控制器寄存器。 必须识别此类冲突。（跟上面一样，注意：这是对工具的要求——不是对ECUC模板的要求）
用例：GPT 驱动程序使用寄存器的 4 LSB，ICU 使用同一寄存器的 4 MSB。 如果两个模块都写入整个寄存器（8 位），则它们会覆盖彼此的配置设置。 一旦识别出冲突，就可以使用不同的 BSW 模块实现或不同的 BSW 配置来解决问题。
小结：这个在配置过程中应该可以识别，如果集成的是代码，应该很难处理。
初始化未使用内存的配置选项
AUTOSAR 构建环境应提供配置选项以将未使用的内存初始化为默认值。
有故障的 ECU 软件可能会访问通常不使用的内存位置。有故障的 ECU 软件甚至可能会尝试在未使用的内存位置执行代码。未使用的 RAM 包含随机数据，在错误的读取访问或执行的情况下，这些数据可能会导致非确定性行为。未使用内存的初始化提高了可靠性。（注意：这是构建工具/环境的要求 - 而不是模板）
用例：用 HALT 指令填充未使用的内存（尤其是 ROM/FLASH），以提高对不需要的代码执行的鲁棒性。 用默认值（0 或 HALT 指令）填充 RAM，以减少指针操作不当时非确定性行为的威胁。
小结：这个在我遇到的项目中，有通过linker来实现类似填充效果的例子。是否可以再startup等中实现，也是可以考虑的。Flash，应该在初始设计的时候考虑初始值的状态。
这样，整个ECU配置的部分就梳理晚了。这次主要看了SWC、参数配置以及来自外部的一些需求信息。
