全部学习汇总： https:///GreyZhang/hack_autosar
继续《AUTOSAR_TR_Methodology》的梳理。
ECU时序建模
居然没有什么相关的文字描述，上来就是一个工作流程图。
ECU 时序模型取决于ECU 配置数据（BSW 和RTE），但ECU 时序模型的结果应有助于优化ECU 配置。 “Configure BSW and RTE”和“Model ECU Timing”之间的关系必须被视为一个迭代工作。
生成 BSW 模块、RTE 和 OS 源文件
ECU配置完成后，生成BSW模块、RTE和OS源文件。
生成是将定制的 ECU 配置值描述应用于软件模块的过程。 这可以以不同的方式执行，并且取决于为不同模块选择的配置类（见 2.7.9），以及实现者的选择。
对于每个 BSW 模块，生成器从 ECU 配置值描述中读取相关参数并创建实现指定配置的代码。
在这个生成步骤中，ECU 配置值描述的抽象参数被转换为硬件和特定于实现的数据结构，以适应相应软件模块的实现。 AUTOSAR 方法论规范没有详细指定生成器工具。
然而，假设生成器对生成所需的配置部分执行错误、一致性和完整性检查。
在生成配置数据时，有一些替代方法。 有关详细信息，参阅其他文档。
SWC存储映射、操作系统、本地数据、生成RTE、预编译数据、基础软件映射、编译器配置、配置代码等一起集合输入到配置生成RTE的阶段。
理想很丰满，现实很骨感。我现在的工作之中，肯定是凑起不了这样的输入的。
如何详细运行不同模块的配置有很多可能性（请参阅配置类的详细用例）。
这个整体用例显式地显示了 RTE、OS 和内存映射的生成，对于其他模块，它作为示例显示了模块链接时间配置所需的通用任务以及生成本地标定支持数据的通用任务。
构建 ECU 可执行文件
这些操作是所有应用程序、库等一起编译和链接以构建 ECU 可执行文件。 各种编译和链接选项的详细信息在其他章节进行了解释。
其实就是一个编译器工具使用的行为定义，这些对我来说倒是简单的。
描述如何从源代码（和交付的目标代码）开始构建一个可执行文件和相关工件（A2L 文件）。
配置类
我开始犹豫，这个究竟该是类还是等级？看了后面的内容后，我觉得应该是类。
BSW 模块的开发涉及以下开发周期：编译、链接和下载可执行文件到 ECU 内存。
参数的配置可以在以下任何一个过程步骤中完成：预编译阶段、链接阶段甚至是构建后阶段。
根据进行参数配置的流程步骤，配置类分为以下几类
• 预编译阶段
• 链接阶段
• 构建后阶段
不同流程步骤中的配置对 ECU 配置参数的处理有一定的影响 . 如果一个配置参数被定义为预编译阶段，那么编译后这个配置参数就不能再改变了。这么看来，宏定义应该是属于这一类的。
或者，如果在构建后时定义了配置参数，则必须将配置参数存储在已知内存位置。 此外，BSW 模块的交付格式决定了参数可更改的方式。 BSW 模块的源代码交付或目标代码交付在配置方面具有不同的自由度。
参数的配置类取决于它所属的 BSW 模块的所选实现变体。 然而，一旦模块被实现，每个参数的配置类是固定的。 为模块选择正确的实现变体取决于应用程序的类型和模块实现者采取的设计决策。
不同的配置类可以组合在一个模块中。 例如，对于构建后阶段可配置的 BSW 实现，只有一部分参数可能是构建后时间可配置的。 某些参数可能被配置为预编译阶段或链接阶段。
用于描述配置类的文件格式：
• .arxml（由 AUTOSAR 标准化的 xml 文件。）
• .exe（可以下载到 ECU 的可执行文件，不过这个可能不是很合适吧？）
• .hex（可以下载到 ECU 的二进制文件 ，但它不能自己执行。）
• .c（包含源代码或配置数据的 C 源文件。）
• .h（源代码或配置数据的头文件。）
• .obj（A 源代码或配置数据的目标文件。）
允许在 BSW 模块中混合具有不同配置类的参数
在 BSW 模块的实际实现中，所有配置参数很可能不在同一配置类中。 即它将是 BSW 模块中具有不同配置类的参数的混合。
这一次小结暂且到此，也是很有科普性的一个章节。后面，针对不同的配置阶段的实现方式，或许还需要进一步了解一下，这个涉及到我实质的软件实施。
