登陆

SOA中的软件模块在硬件中的最优化部署方法论（一）

来源：焉知智能汽车，作者Aimee

2022-12-23

本章节开始，将整体介绍整个软件模块在硬件中的部署方法论，在此之前，我们需要了解关于软硬件分离，硬件设备抽象等概念。

首先是介绍软硬件抽象的概念。软硬件抽象包括设置顶层功能到设备的驱动模块以及底层控制ECU到执行端的整个过程。在整个SOA的架构布局中，从上至下，分别提供服务接口、管理变量、服务转化为数据、面向数据域、构建通信帧格式（CAN/LIN），打包至UDP包中，解包UDP信息并通过区域控制器及网关，ECU执行单元执行CAN/LIN帧。

对于整个SOA的软件模块最优化部署来说，需要解决Adaptive Application的抽象和部署问题。如下各个方面都需要单独进行描述：

1、首先是设备抽象和部署所采用虚拟机（Virtue Machine）及CPU核ID号；

2、其次是描述自适应应用的加载及通信端口、端口ID、通信方式等；

3、整个软件抽象环境的CP和AP之间的通信方式、端口及接口定义；

4、顶层设备抽象后的应用程序所表示的服务、身份识别、物理端口及接口定义（该接口可以用于对服务接口的详细描述）。同时，定义消息通知中所需要的Event ID、Data Type等；

5、应用软件程序归属的功能模块及分组要求，各消息通知类型调用形式等；

通常情况下，每个SOC上可以运行多个Virtual Machine（每个Virtual Machine映射的是用于描述CPU/内存/物理单元的一个硬件资源），而各Application可以运行在对应的Machine上。其中，FDD（Application Device Driver）为功能设备驱动，EDD（ECU Device Driver）为执行控制单元设备驱动。分别可以看成如上Adaptive Application单元底层基础服务和Virtual Machine单元底层基础服务。

本章节将重点对该两个软件模块进行详细介绍，就能很好的描述了设备抽象的本质。

01 功能设备驱动FDD模块

FDD功能设备驱动位于SOA架构分层的顶层封装层，主要是用于屏蔽对下层功能服务模块的调用封装，对于功能到设备FDD的驱动来说，这里需要了解几个要素。

首先，每个功能传感器和执行器（Sensor&Actuator，S&A）模块至少一个FDD，将 S&A 逻辑作为稳定的服务提供给应用程序，开发过程中S&A和DBC的变化，一定程度上可以保证SWC不变，SWC在不同芯片之间迁移时，可保持接口不变，同时减少SWC测试的工作。

其次，FDD可以为 S&A 在基于信号和基于服务之间进行转换；管理可变性，即信令改变，但应用程序的服务可以保持不变并且稳定。如果 S&A 发生变化，可能是传感器供应商对底层逻辑进行了更改，此时FDD会使用该更改后的设置参数，但对于上层来说仍然提供相同的服务，因此不必修改和重新测试应用程序，这就是FDD的核心优势所在。

此外，由相关的S&A 模块拥有，应用接口设计时，可以和硬件及总线形式无关，先设计接口，再根据部署设计相应的通.

02 执行控制单元驱动EDD模块

在FDD之下，到中间件之间通常还会有一个单独的执行设备驱动模块EDD。该EDD主要类似一种虚拟设备驱动控制单元，将顶层服务需要的设备驱动指令转化为执行端可解析的驱动代码，同时也将执行端的状态、执行结果等数据封装反馈给FDD服务端。因此，EDD的几个关键要素包括如下。

首先，需要了解关于通信打包数据模块的底层封装逻辑，知道哪个 UDP 端口与该特定 ECU 的 VIU 通信，其核心是数据传输和提供底层电压值到物理值的解析。这个过程实际是打包/解包 UDP 数据包和 CAN 帧，以便向 FDD 提供实际数据，其过程是实现16进制到物理值的转化。如果 FDD 提供的数据与信号不匹配，则按照帧中应有的方式构造信号。

其次，是EDD需要向 FDD 提供“数据更改”事件状态报告。例如，当有车门状态的周期性信号改变时，只有当它像事件信号一样更改值时才会被FDD所关注。如上EDD的虚拟设备驱动模块都由带有 ECU 的传感器和执行器单元所拥有。

03 EDD模块SWC部署原理

通常部署的基础软件模块是在标准的Autosar开源软件架构平台上，AUTOSAR是由三个主要层组成的标准软件：应用程序软件组件（ASWC），运行时环境（RTE）和底层软件（BSW）。每个层被模块化为各种软件组件SWC，并通过称为虚拟功能总线（VFB）的虚拟网络相互连接。对于整个高级自动驾驶的部署过程而言就是需要将各个不同的SWC分块部署到最优的硬件资源上，确保硬件资源利用率最大化，同时软件运行效率最优。

整体功能划分为不同的我们需要充分掌握其中软件模块分块过程、软件基础功能及软件模块部署原理，对于部署到Autosar的AP端还是CP端，需要了解其两者的不同特点。

AP端特点：高算力、大运算量、服务类通信、低安全级别、低实时性、功能多样化；

CP端特点：中低算力、多控制功能、高安全级别、高实时性、快速启动；

对于FDD到EDD信号交互过程需要充分掌握AP端的EDD部署问题和AP端的UDP包解析问题。如图所示，EDD到FDD的数据呈递是通过COM包进行交互的，且在CP Autosar中，可以直接通过COM进行数据交互。因此EDD集成到COM层中，独立存在没有意义。

对于AP Autosar端，针对常用的三种报文格式UDP、Someip、DDS，有不同的书记数据解析方式。

● SomeIp/DDS报文的EDD解析部署方案

如果数据包格式直接是Someip或者DDS格式，可以直接由ARA：：COM进行解析。因此，针对如上两种报文可以直接将EDD部署在AP端的ARA：：COM模块中。

● UDP报文的EDD解析部署方案

由于ARA：：COM无法直接解析UDP的数据包，对于UDP协议数据包有直接来自传感器和执行器的原始数据协议，根据AP上的SWC分配而定，借鉴设备抽象的方法概念，如果在相应的处理控制器将UDP协议报文直接封装SomeIP报头+PDU路由，则可以通过ARA：：COM解析数据。也就是说可以将解析模块EDD直接集成到ARA：：COM中，由UDP协议包打上Someip的报头，输入至ARA：：COM中，由EDD进行解析。

当然如果不考虑资源消耗，我们可以将EDD模块完整的从AP端ECU抽象层（ECU Abstraction Layer，EAL）中取出单独至于Autosar平台之外的Service Layer与EAL中间。这时可以将UDP数据包直接输入该EDD模块并直接与FDD进行信号交互。

当然从折衷的方案上讲，我们比较推荐将EDD并入ARA：：COM层，并由UDP打上报头的形式进行报文解析。

04 FDD应用场景部署原理方法论

FDD进行数据解析及分包后，输入至EDD进行设备驱动，EDD通过提供与FDD服务包需求对应的真实数据（这些物理真实数据包括原始Signal、物理值、解析偏移量、解析精度），将驱动软件接口与Autosar本来的Can网络管理应用关联模块Com接口进行对接，使得在该中间件Com模块中可以很好的处Net Management的Userdata数据，此外，通过选择管理类型，在PN下会使用Com相关的接口函数处理PN网络管理、通道管理，设置Gateway控制，根据channel关联到基础软件BSW和用户软件User中实现对状态的通知和接收来自BSW和User的控制。

对于FDD的部署过程来说，首先应该是对需要部署的芯片核中结构，核中哪些可以用于部署软件FDD组件，相应的核性能是否能够承载FDD对应的功能服务。

以视觉感知处理为例，FDD提供的服务组要承载其功能及性能的2类芯片：一颗是安全核（Safety Core）；另一个颗是性能核（Performance Core）。安全核一般由英飞凌TC297/397之类的MCU充当，承载控制任务（计算量通常面向较为简单的整型数据计算），因此需要较高的功能安全等级需求；性能核通常是具有更高性能算力的多核异构MPU，会承载大量的计算任务。FDD的SWC部署通常需要从整个ECU所包含的所有核间结构进行整体分析。

整个FDD的软件主要部署在Service Layer与应用软件组件服务之间，部署的数量、位置都主要针对不同的应用软件服务需要实现的功能有所不同。

对于整个FDD所实现的应用服务而言，需要充分考虑如下一些要素进行软件部署和资源利用。

a) 功能是否对其响应的实时性要求很高。高实施性功能通常需要直接部署在其实现该FDD服务功能的硬件ECU中；

b) 功能是否需要有很多的模拟量输入和输出。模拟量的输入输出就意味着抗噪能力相对较差，其传输的链路应该保证尽可能短且稳定，以确保信号尽量不失真；

c) I/O和计算分离后业务逻辑的变化是否有特殊需求；业务逻辑变化主要指顶层计算服务需要的执行层能力在发生变化时，底层执行层是否能应时变化并自适应；

d) 计算时的输入参数是否需要通过虚拟总线VFB传递；如果参数需要总线传递参数可能会造成处理延迟，从而影响应用层软件的处理能力；

e) 部署在Autosar的不同应用端软件组件，还需要充分考虑不同软件组件SWC模块在顶层应用和底层基础软件之间需要调用的数据读写次数尽量少。同时，AP端和CP端通过虚拟总线VFB交互的数据带宽和数据量尽量不要太大，以免造成传输延迟或总线负载过大等不利结果。

f) 此外，OEM或供应商是否有把某个功能做I/O,计算分离的技术能力，是否对优化成本有优势，每个功能对硬件能力是否会有不同的需求，整合后在新的硬件平台上是否同样满足需求，整合后的ECU开发难度等等。

05 FDD与EDD之间的交互逻辑

如下以逻辑架构图和时序图说明FDD和EDD的交互方式逻辑。

从下图中不难看出，对于以中央控制器+区域控制器的控制逻辑来说，整个FDD与EDD的交互过程可以分解为从上到下三种分层模式。顶层为中央控制器单元Central ECU，中间为区域控制单元Zone Controller，底层为传感器&执行器ECU，最下层为物理I/O接口输入输出。从上至下，首先是应用软件通过FDD模块提供固定服务接口给实际应用单元。其中包括重新封装接口、提供物理值、匹配精度、矫正偏移，建立网络管理与应用层的交互。其次，是通过设计网络管理Net Management报文中的Userdata内容提供打包和服务转化，使得应用层可以参与到底层驱动控制和相应的网络管理逻辑控制中，同时，当传感器或执行器更改时可以对应用保持接口尽量不变。

如下图，以SWC表示的软件组件传递方式，FDD的软件组件模块首先将传感器&执行器端的信号接收后通过信号组合、提供服务/内部接口等形式，打包成对应的应用层服务包，比如A1只对应着底层S1信号，A2对应着底层的S2、S3打包组合信号服务内容，A3服务则对应着S4、S5打包定义的服务内容。

对于FDD的服务打包而言，如果FDD的两种应用级服务软件组件SWC分别位于不同的MCU或SOC芯片调用时，则该两种服务调用的方式是定义的外部接口方式进行调用，如果两种应用级服务软件组件SWC位于同一种MCU或SOC芯片调用时，则采用内部接口进行信号交互。这里需要注意的是，接口类型分为S/R接口或C/S接口，根据接口数据方向和业务方向可以决定接口类型，和SWC部署无关，通常应用端使用的都是FDD的接口类型。

06 小结

本文从整个设备抽象的角度宏观分析了如何建立从顶层功能服务需求到底层硬件驱动的软件组件部署过程。其中提出了两个比较重要的概念，功能设备抽象服务FDD与执行设备抽象服务EDD，两者并不属于严格意义上的Autosar的某个核组件，而是在上层与下层传递数据过程中起到了数据转化，使得目标层能够很好的解析原子服务。对于FDD和EDD如何最优的部署到我们常用的芯片核上，本文也给出了重点讲述，下节我们讲以实例分析常用的几个功能服务的部署问题，同时给出典型的部署过程中常出现的问题进行具体分析。

上一篇：聊聊被智能驾驶影响的那些汽车基础功能如何实现（一）下一篇：SOA中的软件模块在硬件中的最优化部署方法论(二)：SOA的软件组件部署实例分析