683_AUTOSAR_TR_Methodology_文档阅读9_APP开发以及特殊软件组件使用案例

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

         继续梳理《AUTOSAR_TR_Methodology》，这一次看看APP的开发。

         开发APP软件的目的

         本活动提供了创建一个或多个应用程序软件组件的粗略概述。

         刚开始看到这个标题的时候还在想，这个APP跟SWC到底是有啥不同，这里一下子给说透了，其实APP是SWC的集合。

         开发应用软件活动

         本活动根据 AUTOSAR 方法描述了开发一个或多个应用程序软件组件的工作流程和必要活动。 工作流程应允许软件组件核心功能的或多或少的独立开发。 必须为每个应用软件组件执行这些活动。

         工作流程

         详细的工作流程可以从通用活动“开发原子软件组件”派生出来。而工作流程也算是简单了，就是从VFB的设计承接到输出一系列的原子SWC。

         上次的小结猜测再次被验证了，其实这个表格就是对前文的一个总结。这个前文有点简单，表格内容其实是跟前面一致了。

更专业的软件组件的用例

目的

这些活动提供了创建更专业的组件和软件组件的 ECU 特定优化的粗略概述。

描述

这些活动根据 AUTOSAR 方法描述了工作流程和必要活动，以开发更专业的组件，这些组件可能部分依赖于硬件或 ECU。

         工作流

这些工作流大部分源自通用活动“开发原子软件组件”。 图表显示了所需的扩展。

         需要注意，服务组件的开发不属于此类用例，因为它大部分是在集成期间生成的。

有关 VFB 参数组件的开发，需要参考校准标定用例 2.9。

         开发一个传感器或者执行器的软件组件，流程既简单粗暴十分有效的路数。

         开发一个ECU抽象层组件

         开发一个复杂驱动的软件组件

         开发一个NvBlock的软件组件

         开发 NvBlock 软件组件的活动。 NvBlockSoftwareComponentType（设计为活动组件模型开发的一部分）允许应用软件通过端口以方便的方式访问非易失性数据。 NvBlock 软件组件负责块内数据的管理和缓冲，包括与底层基础软件 (NvM) 的数据交换。 可选地，它实现特殊的写入策略（例如循环写入）。 开发活动类似于通用活动“开发原子软件组件”，但有以下区别：

? NvBlockSoftwareComponentType 中的 NvBlockNeeds 的描述是根据应用软件作为其自身 NvBlockNeeds 的一部分给出的要求而完成的。 这些是其软件组件内部行为的一部分，这意味着当最终设计 NvBlockSoftwareComponentType 时，该级别必须可用。

? 在 NvBlockSoftwareComponentType 中创建软件组件内部行为是可选的。 仅当 RTE 必须实施特殊的写入策略或应用程序软件需要直接访问（通过客户端-服务器端口）到 NvM 时，才需要此工件。

? NvBlockSoftwareComponentType 的源代码将在集成期间作为工件 RTE 源代码的一部分生成。 因此，在此活动期间不需要创建源代码和原子软件组件实现。

需要注意，如果应用程序软件通过 NvBlockSoftwareComponentType 访问非易失性数据，则不需要为此用例定义 ServiceComponentType。

         在实践中，应用软件组件的集成必须考虑一些优化以满足性能或资源需求。 如果生成的组件 API 特别适合具体的 ECU 配置，例如，组件 API 可能会更有效率。 通过使用宏定义而不是某些 RTE 交互的函数调用。 事实上，这不应该改变组件实现（即 C 源代码）。

这意味着现在我们有一组不同的组件头文件，其中包括特定于 ECU 配置的优化。

注意：此用例显示了使用优化的头文件进行重新编译之前所需的典型步骤。 它没有显示 ECU 构建所需的所有其他步骤。

         这部分的信息总结相对来说有一点平淡，但是也算是有一些常识性的信息补充。这一份文档的信息的确是多，但是也能够明显看得出这是有一点大纲性质的，如果慢慢看完的话，对于了解整个架构肯定会有很大的帮助。