全部学习汇总： https://github.com/GreyZhang/hack_autosar

       继续梳理之前没看完的文档，《AUTOSAR_RS_ECUConfiguration》。

       无重复描述

       ECU 配置描述中每个配置信息只包含一次，即使需要配置多个模块。

       这有助于避免描述中的不一致并保持描述的紧凑。

       需要注意，仍然允许包含派生信息：如果配置参数C原则上可以从配置项A和B计算出来，那么模板中仍然可以包含C。

       用例：ECU 中使用的任务定义可能与 OS 配置和 RTE 配置相关。 但它应该只在 ECU 配置模板中定义一次。

       支持供应商特定的 ECU 配置参数

       除了在 BSW 模块的 SWS 中定义的标准配置参数之外，ECU 配置还应提供供应商特定信息的方法。

       必须确保所有 ECU 信息都可以存储在 ECU 配置描述中。 因此可以将特定项目传递给生成工具。

       用例：必须在 ECU 配置参数定义和 ECU 配置描述中存储的实际值中定义 NVRAM 管理器的特殊属性和一些工具设置。

       支持定义配置类

       ECU 配置参数定义应支持配置参数的配置类定义。

       BSW SWS 允许多个配置类：预编译时间链接时间后构建时间。

       配置参数的标准化不一定固定参数的配置类别。 相反，它可以定义模块的不同配置类实现变体。 实际的 BSW 模块实现确实修复了每个参数的配置类。 此信息必须存储在 ECU 配置参数定义中。

       不同配置类的一种描述机制

       对于所有不同种类的配置类，应该只有一种配置描述机制。 因此，无论是描述“预编译时”还是“链接时”或“后构建时”配置，描述格式都应相同。

       配置的描述应独立于 BSW 实现。 如果实现中的参数类发生变化，则可能需要其他信息，例如构建后参数的内存位置。

       ECU 配置描述应该是工具可处理的

       ECU 配置描述应可由 ECU 配置工具和生成器读取和写入。

       ECU的配置需要有工具支持。

       小结：这个跟诊断等几个模块的文档描述类似。

       根据 AUTOSAR 通用结构模板文档开发

       ECU 配置描述应根据 AUTOSAR 通用结构模板开发。

       AUTOSAR 建模已有的经验和工具应被重用。

       小结：看起来，又是重复内容。

       根据 AUTOSAR Model Persistence Rules for XML 转换 ECUC 模型

       小结：这部分在看诊断提取部分的时候也是了解过的。

       扩展处理

       ECU 配置必须允许后续扩展以支持标准的发展。

       可能必须在当前不属于标准的 ECU 配置和 ECU 资源中处理扩展/附加方面。 但在某个时间点，这些扩展将成为下一版本标准的一部分。

       支持顺序ECU配置

       应该可以分别编辑 ECU 配置描述的不同部分。

       ECU 配置描述包含几个模块的配置，这些模块的配置相互影响。 所以依赖关系必须按顺序和迭代解决。

       用例：RTE 配置编辑器可以分配 OS 任务，但 OS 配置编辑器仍然能够更改此 OS 任务的属性。

       小结：这个用例没有看懂，其他的倒是感觉还有一定的理解性。从例子看，这是说不同工具可以对同一个配置进行编辑支持？

       兼容迭代设计

       支持 AUTOSAR 方法要求的迭代设计。

       很少有任何产品的开发在没有任何设计更改的情况下完成。 设计变更总是需要对设计阶段的某些部分进行迭代。AUTOSAR 工具将被反复使用，这包括 ECU 配置。

       容器在数值侧的变量存在

       容器及其子结构的存在应在 ECU 配置参数描述中可变。

       容器包含配置描述的大部分结构。通过启用容器的可变性，可以支持许多用例。

       数值的变量存在

       在 ECU 配置参数描述中，参数或参考的存在应该是可变的。

       如果参数或引用是可选的，则值的存在可以是可变的。

       变量的数值

       ECU 配置参数描述中的参数或参考值应是可变的。

       根据变体选择器计算参数的值。

       ECU 配置参数定义中的可变下限和上限多重性

       ECU 配置参数定义中的上下多重性的定义应该是可变的。

       通过较低和较高的多重性，控制 ECU 配置参数描述中元素的存在。使边界变量允许定义的自由。

       小结：这个是不是讲的就是我之前遇到的hard以及weak的限制数值？

       ECU 配置参数定义中的变量默认值

       ECU 配置参数定义中的默认值应该是可变的。 “枚举参数定义”不支持此变体。

       默认值是为参数输入的第一个值。 为了允许有意义的默认值，这些应该是变量以调整它们。

       ECU 配置参数定义中的可变最小和最大范围

       ECU 配置参数的最小和最大范围在 ECU 配置参数定义中是可变的。

       变化与最小值/最大值之间的关系经常出现在 ECU 配置参数定义的定义中。

       TPS_ECUConfiguration 应提供公共符号的命名约定。

       TPS_ECUConfiguration 应提供公共符号的命名约定。 这尤其包括在发布文档中使用的需求 ID、模块缩写、元数据和配置符号。

       避免规范中的歧义和名称冲突。 向规范的读者提供元数据的一致统一表示。允许自动处理规范元素。

       关于ECU配置的模板需求就暂且看到这里，其实这里面的一些内容或者说是原则跟之前看到的诊断或者是基础软件模块的要求是有相似之处的。这其实是一件好的事情，这意味着继续看下去，可能文档的查看速度会越来越快了。