全部学习汇总： GitHub - GreyZhang/hack_autosar: learning autosar documents, aha, very hard!
继续看AUTOSAR的文档，梳理一下《AUTOSAR_RS_ECUConfiguration》。
ECUC客户端的需求
BSW的预编译时间配置
对于定义为预编译时可配置的配置参数，BSW 在预编译时的参数配置应是可能的。
出于效率原因，某些 AUTOSAR BSW 模块的配置参数被定义为预编译时可配置。 ECU 配置需要支持这些参数。
小结：这里的效率应该是说软件的执行效率，如果不通过预编译的处理，应该就会增加很多逻辑判断以及附加的代码块。
BSW的链接时间配置
对于定义为链接时间可配置的配置参数，链接时间期间 BSW 的参数配置应该是可能的。
BSW 的构建后的配置
应该可以重新配置定义为构建后可配置的构建后配置参数。
这将允许 ECU 中 BSW 组件的构建后时间配置以适应周围系统的变化。在将参数定义为构建后时间可配置时，必须考虑对整个系统的影响。
用例：FMC开发和售后方法在很大程度上取决于重新配置 CAN 和 LIN 通信后构建时间的可能性。主要的配置项是信号到帧的映射、帧优先级和帧时序。
小结：其实这部分在之前的文档阅读中理解下来，应该主要是标定类的功能支持。
在构建后时处理不同的配置变体
ECU 配置中应该有可能在构建后绑定的变化点。
这将允许在一个 ECU 中存在多个 ECU 配置变体。
用例：相同的 ECU 软件可用于共享相同应用程序（例如左门和右门模块）的多个 ECU，并且在运行时为每个 ECU 选择正确的配置。
支持配置BSW
ECU 配置应支持 BSW SWS 文档中定义的所有配置参数。 所有支持模块的列表可以在分层软件架构文档 [11] 中找到。
BSW 必须从 ECU 配置描述中进行配置。
用例：
• BSW SWS 定义配置参数列表。这些参数需要反映在 ECU 配置模板中。
• OS SWS 将从现有格式（例如 OIL）中识别配置参数并将它们放置在 SWS 中。 在那种情况下，ECUC 中仅使用 OIL 的内容，而不是实际格式本身。
配置多个 BSW 模块实例
如果适用，应该可以描述一个 ECU 上一种 BSW 模块类型的多个实例的配置。
一些 BSW 模块类型可以在一个 ECU 中多次出现，使用不同的实现，例如闪存、EEP 和看门狗驱动程序。
对于某些 BSW 模块，不可能有多个实例，例如 OS、NVRAM-Manager 等。
选择AUTOSAR软件组件和BSW模块实现
如果有多个软件模块可用，则允许选择特定的软件模块实现。
模块的多个实现（代码）可用于合并到系统配置中。可能需要进行特定选择。
用例：
•来自不同供应商的多个CAN驱动程序。
•单个供应商提供的多个驱动程序版本。
•AUTOSAR软件组件的不同实现。
软件段到内存的映射
软件部分（代码、数据）应能够映射到特定的存储区域。
每个软件都由几个部分组成，这些部分在开发/编译软件时定义。这些部分需要放在ECU的不同存储区域中。
用例：
•如果数据应为构建后可配置数据，则需要将其置于非易失性存储器中。数据放置的位置是工具以后能够更改数据所必需的。
•某些SW变量必须放置在NOINIT内存区域中，该区域在ECU启动期间不会初始化。
小结：感觉上，这段文档的描述有点与其他的部分重复。
支持RTE的配置
应支持RTE的生成和配置。
RTE必须根据ECUC的信息生成和配置。
支持在特定ECU上提供哪些AUTOSAR服务的配置
AUTOSAR定义了几个可集成到ECU中的服务。应能够定义特定ECU上存在哪些AUTOSAR服务。
可能存在不需要所有AUTOSAR服务的ECU，因此可以定义子集。
支持在特定ECU上提供哪些AUTOSAR服务的配置
AUTOSAR定义了几个可集成到ECU中的服务。应能够定义特定ECU上存在哪些AUTOSAR服务。
可能存在不需要所有AUTOSAR服务的ECU，因此可以定义子集。
用例：如果ECU不使用任何NvRam，则此ECU上不需要NvRam管理器。
这部分小结暂且到此，主要是客户端以及SWC部分的需求梳理。还有几个内容有点琐碎的需求分块，以后再找时间看。