开始一个全新的文件的梳理，《AUTOSAR_RS_ECUConfiguration》。
1 本文档的范围
ECU 配置是在 AUTOSAR ECU 开发过程中执行的一项活动。
ECU 配置的输入是系统配置描述的一部分，称为系统配置的 ECU 提取。ECU 配置的活动是为一个 ECU 内的所有软件提供配置信息。这涵盖了从 RTE 配置上的 AUTOSAR SW 组件到大量基础软件模块。
ECU 配置的输出是用于实际生成和构建 ECU 可执行文件的 ECU 配置描述。
本需求文档的主要重点是 ECU 配置描述的格式。
1.1 文档约定
AUTOSAR 文档中需求的表示遵循 [TPS_STDT_00078] 中指定的表格，请参阅标准化模板，支持可追溯性一章 ([2])。
[TPS_STDT_00053] 中规定的用于表达义务的口头形式应用于指示要求，请参阅标准化模板，支持可追溯性一章 ([2])。
2 相关文档
2.1 输入文档
以下输入文档已用于制定这些要求：
• AUTOSAR 基本软件模块的通用要求 [3]
• 运行时环境的 AUTOSAR 要求 [4]
• AUTOSAR 方法 [1]
• AUTOSAR 术语表 [ 5]
• AUTOSAR 通用结构模板 [6]
• XML 的 AUTOSAR 模型持久性规则 [7]
2.2 规范文档
本文档中收集的要求将通过两个规范文档来满足：
• ECU 配置规范 [8] 该文档提供了配置方法的概要和 ECU 配置参数的开发指南。
• ECU 配置参数XML [9] 该文档包含了 BSW、RTE、SWComponents 和 ECU 集成的 AUTOSAR 标准化配置参数的规范。
这个表格相比之前的文档也没有增加的信息，跳过。
看需求的页数其实是不少的，没想到这个需求跟踪矩阵不大。
ECU配置的需求
关于模板的需求
本节中的要求都涉及如何定义 ECU 配置模板。
ECU配置描述应该是一个ECU整个配置信息的根。
ECU 配置模板将成为在特定 ECU 上集成软件的支柱。 任何必要的配置信息都应在此模板中汇总或引用。
软件集成基本上意味着解决软件特定部分之间的相互依赖关系。只有在所有相关信息都可以访问的情况下，才能正确执行解析过程。
需要注意，此要求并不意味着将所有相关信息都复制到模板中。可以包括对其他模板中元素的引用以避免模型中的冗余元素。
用例：ECU 配置模板将包括对使用元模型的 SW 组件部分描述的 SW 组件的引用。
它还允许在任务中指定可运行对象的排序，这是任何其他模板未指定的。
支持从依赖容器引用
应该可以定义从参数容器到ECUC 参数定义中的其他参数定义以及其他AUTOSAR 模板中用于标准化AUTOSAR 配置参数的元素的引用。
如果两个容器之间存在引用，则假定引用容器与被引用容器之间存在依赖关系。
用例：此类相关性的示例包括：
• PortPin 引用使用此 Pin 的驱动程序
• IPdu 中 COM 信号的 BitPosition 由 SystemTemplate 中的 SignalPosition 定义
指定ECU配置参数定义
必须捕获（看意思似乎更该翻译成描述） ECU 配置参数的定义及其约束，例如配置类、值范围、多重性。
对配置参数的约束对于识别和验证很重要。这还包括实际参数本身的有效性，例如范围和预定义值。
支持强制和可选配置参数的标准化
在 ECU 配置参数定义的标准化中，应该可以定义一个参数是强制性的还是可选的。 可选和强制的定义如下： 强制参数必须由该模块的所有实现实现。它必须始终存在于完整的 ECU 配置描述中。一个可选参数可以被一个实现省略。
如果澄清并非每个实现都需要支持该参数，则无论如何都可以标准化不适用于每个实现的参数。
需要注意，对于具体实现，参数要么受支持，然后必须出现在 ECU 配置中，要么不受支持，然后不得出现。 因此，对于具体实现，不再存在可选性，仅在参数定义的标准化版本中存在。
需要注意，实现仍然可以选择修复强制参数的值（例如，目标代码交付修复了预编译参数的值）。 无论如何，选择的值必须在 ECU 配置描述 [8] 中说明。
用例：PORT 模块中的参数 ACTIVATE_PULLUP 仅在硬件支持时才需要。 因此，如果目标硬件不支持上拉，则 PORT 模块的实现可以省略该参数。
支持强制和可选容器
应该可以将配置参数分组到容器的层次结构中。应该可以定义一个容器是强制性的还是可选的。
可选和强制的定义如下： 模块中定义的强制容器必须由该模块的所有实现实现。 它必须始终出现在完整的 ECU 配置描述中。 该容器的所有参数和子容器也必须存在，除非它们是可选的。
一个可选的容器可以被一个实现省略。 如果省略了可选容器，则在该容器中定义的所有参数和子容器也将被省略，无论它们是定义为可选的还是强制的。
小结：最后一条的描述有点奇怪，既然参数以及子容器有强制的，其父容器居然不是强制的！
如果澄清并非每个实现都需要支持该容器，则不适用于每个实现的容器无论如何都可以标准化。
用例：ADC 模块可为微处理器的每个 ADC 通道定义一组参数。 如果特定微控制器上没有 ADC 通道，则这些参数都没有用。 如果定义了一个通道，那么应该填写该通道的所有必需参数。因此，最好定义一个包含必需参数的可选容器，而不是定义多个可选参数（然后可以相互独立地省略）。
这一次的小结暂且到此，虽然看上去的内容不多，但是感觉这部分的介绍过于抽象。消化理解一下，然后继续后面的探索之旅。
