649_AUTOSAR_EXP_VFB文档阅读6

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

         继续看《AUTOSAR_EXP_VFB》，浏览了一下文档，这次看两部分内容吧！一部分是组件的分类，另一部分是组件以及Runnable资源。

         首先看组件，直奔主题了。先看应用软件组件，应用程序软件组件是实现应用程序（部分）的原子软件组件。 它可以使用所有 AUTOSAR 通信机制和服务。 应用软件组件通过传感器-执行器软件组件与传感器或执行器交互。

         这里介绍自己的同时，还引入了另一个组件的概念。

         这就是上面引入的传感器-执行器组件。

         传感器执行器软件组件是一个原子软件组件，用于处理传感器和/或执行器的细节。 它直接与 ECU抽象层交互（这用称为“IO”的端口说明），通过这样的方式与硬件的交互。

         那么，这个应该是放在什么层呢？我觉得肯定是RTE以下，不然的话，无法直接与ECU的抽象层进行交互。那么，应用软件与此的交互还是通过RTE？

         参数软件组件提供参数值。 这些可以是固定数据、常量或变量。该软件组件允许对固定数据或校准数据进行数据访问。

         我好奇，是不是在这样的软件架构中，标定量会全都被设计成这种模式呢？

         软件组件的组合件封装了软件组件的协作，从而隐藏细节并允许创建更高的抽象级别。

通过委托连接器，软件组件的组合明确指定内部组件的哪些端口从外部可见。组合软件组件是一种特殊类型的软件组件，例如 它们可以成为进一步的组合软件组件的一部分。

         服务代理软件组件。

服务代理软件组件负责在整个系统中分配模式。 部署后，每个 ECU 都应该拥有此软件组件类型的每个实例的副本。 然而，在 VFB 级别只需要一个。

         服务软件组件。这个与上面的代理有啥关系呢？

服务软件组件通过标准化接口提供标准化服务。 为了提供这些服务，该组件可以直接与某些其他基础软件模块交互（这由双箭头表示）。 从这个描述上看，其实这个相比于上面的代理其实是更加底层一些的。

         ECU抽象软件组件。这个实现的应该就是一堆ECU IO。

ECU 抽象软件组件提供对 ECU 特定 IO 功能的访问。这些服务通常通过客户端-服务器 PPort 提供，并由传感器执行器软件组件使用。 ECU 抽象可以直接与某些其他基本软件模块交互（这由双箭头表示）。通过这种方式与硬件的交互。

从设计以及存在的存在感上，这个其实是像极了传感器-执行器组件。

         复杂驱动软件组件。

         复杂驱动程序软件组件概括了“ECU 抽象组件”。 它可以定义端口以特定方式与其他组件交互，也可以直接与其他基础软件模块交互。

         关于这个定义说明，其实我多少是有一些糊涂的。ECU的抽象应该是有明确的设计的软件架构归属的，为什么复杂驱动成了这个的概括呢？

         NVBlock软件组件。

         NVBlock软件组件允许 SWC-S 访问非易失性数据。 具体来说，该模块允许在 VFB 级别对 NV 数据进行建模。 NVBlock负责将各个 NV 数据元素映射到 NVBlock并与 BSW 中的 NV 管理器进行交互。 该组件的行为将根据 RTE 中的端口服务生成。

         看起来，这个描述也是非常清晰的。现在我工作中用到的方法，虽然看似巧妙，但是还是不满足这样的架构设计的。

         这一小节的内容比我想象中多了不少，这一次小结暂且到此结束了。关于组件以及Runnable资源的小结，得重新做一次梳理了。