继续梳理《AUTOSAR_TR_Methodology》。
准备ECU配置
描述
准备 ECU 配置活动
在准备 ECU 配置活动期间，通过实现软件组件和 BSW 模块所需的服务需求，并通过包括 BSW 模块预配置或 BSW 模块推荐中提供的初始配置，扩展了特定 ECU 的 ECU 提取中的可用信息配置。 此活动的输出是基本 ECU 配置。
此外，定义所有可能的配置参数及其结构的 BSW 模块供应商特定配置参数定义被合并到 ECU 配置中。 这是必要的，因为输出 ECU 配置具有灵活的结构，该结构不预先定义固定数量的配置参数。
应为 ECU 中存在的每个 BSW 模块选择 BSW 实现
对于应存在于 ECU 中的每个 BSW 模块，必须选择实现。 这是通过参考 BSW 模块随附的 BSW 模块描述（BSW 模块交付包）来完成的。
构建基本 ECU 配置值描述时必须遵循的规则可在第 4.2 章中找到。
这个图的解读有点疑惑啊，这里面的菱形箭头究竟是什么含义呢？难道，这个配置只是一个动作行为，在这个动作行为之后没有文件的输出？
准备ECU配置：创建初始 ECU 配置所需的初始操作。
配置 BSW 和 RTE 活动
一旦有了基本的 ECU 配置，就可以执行完整的配置。 这主要是对 ECU 配置的编辑工作，通常由编辑工具支持。 在实践中，这将需要迭代和/或并行工作来配置 RTE 和所有参与的 BSW 模块。
该方法没有规定这些配置步骤的特定顺序。 由一个活动产生的 ECU 配置描述（例如 ECU 配置值）可以被另一个活动读取（例如，Configure RTE 生成一个描述，Configure Com 读取它）。 通常，BSW 模块（例如 COM 和 OS）的配置活动读取和写入 ECU 配置。
这里有一个值得注意的地方，接口的信息输入其实是在RTE配置的，这样COM可以读取然后实现相关的配置。
配置 RTE 任务
配置 RTE 任务更加复杂，因为这还需要该 ECU 所需的所有原子软件组件实现。 每当这些变化时，例如：由于软件组件已移入或移出其他 ECU，或者只是选择了软件组件的另一个实现，因此也必须重复配置 RTE 任务。
看起来，这就是RTE比较费时间的一个因素。听闻已久，估计接下来还得有一场跟它正面交锋的战斗。
配置调试任务
最后可以完成配置调试任务。 由于此配置依赖于之前的配置结果，因此应该最后完成。
没想到，调试任务还是一个单独的过程。软件开发的过程中，这个阶段是可以跳过的吗？在我现在的工作条件下，估计这个阶段所需要的时间等很是问题。
工作流程相对来说简单，就是集中输入信息然后做配置。
表格中有一条需要注意：由于 DEM 的配置通常会影响要存储在 NvM 中的数据，因此假设配置诊断任务先于任务配置 NvM。
更新ECU配置
在 post-build 场景中，最后会生成两个可加载文件——一个包含应用软件、基础软件以及基础软件的预编译和链接时配置（简称 ECU Executable），另一个包含 一个仅包含基本软件的构建后时间配置（可加载到 ECU 内存的 BSW 模块配置数据）。 这两个可加载文件代表初始配置。 通过生成两个新的可加载文件，可以在构建后时间更新此初始配置。 在本次更新中，ECU Executable 没有被修改
其实，这个在一定程度上应该就是我现在接触到的标定或者DID的处理。
更新 ECU 配置活动
可加载到 ECU 内存的 BSW 模块配置数据的更新通常是通过将包含所需构建后更新的EcuExtract 导入已包含初始 ECU 配置的 ECU 配置工具来完成的。 基于 EcuExtract 中的这些更新以及来自初始 ECU 配置的所有其他内容，将创建更新的 ECU 配置（因此我们在 ECU 配置值和更新 ECU 配置活动之间具有输入和输出关系）。
更新ECU配置工作流程
这个表其实是可以作为一个提示，除了更新之外，初始的创建其实也在这个过程之中。
前面两部分算是本次学到内容较多的地方，最后这个配置更新，收获较少。算是这次梳理额外增加的一部分学习内容了。
