作者|艾米
出品| 颜智
志全| 进入“计算平台群”请添加微信yanzhi-6soa软件，备注计算
在本章的开头，我们将整体介绍一下整个软件模块在硬件上的部署方法。 在此之前，我们需要了解软硬件分离、硬件设备抽象等概念。
首先是介绍软件和硬件抽象的概念。 软硬件抽象包括将顶层功能设置到设备的驱动模块以及从底层控制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）是执行控制单元设备驱动程序。 可以将它们视为上述自适应应用单元的底层基础服务和虚拟机单元的底层基础服务。
本章将重点对这两个软件模块进行详细介绍，可以很好地描述设备抽象的本质。
功能设备驱动FDD模块
FDD功能设备驱动位于SOA架构层的最顶层封装层。 主要用于屏蔽下层功能服务模块的调用封装。 对于功能到设备的 FDD 驱动程序，这里有几个元素需要理解。
首先，每个功能传感器和执行器（Sensor&Actuator，S&A）模块都至少有一个FDD来为应用程序提供S&A逻辑作为稳定的服务。 开发过程中S&A和DBC的变化可以保证SWC在一定程度上保持不变。 在不同芯片之间移植时，可以保持接口不变，同时减少SWC测试的工作。
其次，FDD可以在基于信号的S&A和基于服务的S&A之间进行转换； 管理可变性soa软件，即信号变化，但应用程序的服务可以保持不变和稳定。 如果 S&A 发生变化，则可能是传感器供应商对底层逻辑进行了更改。 此时FDD将使用更改后的设置参数，但仍向上层提供相同的服务，因此无需修改和重新测试应用程序。 这就是FDD的核心优势。
此外，它归相关的 S&A 模块所有。 在设计应用接口时，可以独立于硬件和总线形式。 先设计接口，然后根据部署设计相应的通信。
执行控制单元驱动EDD模块
FDD下，中间件与中间件之间通常有一个独立的执行设备驱动模块EDD。 EDD主要类似于虚拟设备驱动控制单元，它将顶层服务所需的设备驱动指令转换为执行端可以解析的驱动代码。 它还封装执行端的状态、执行结果等数据并反馈给FDD服务器。 因此，EDD 的几个关键要素包括以下内容。
首先需要了解通信封装数据模块的底层封装逻辑，知道是哪个UDP端口与这个具体ECU的VIU通信。 核心是数据传输以及提供底层电压值到物理值的分析。 这个过程实际上是对UDP数据包和CAN帧进行打包/解包，以便向FDD提供实际数据。 该过程是将十六进制值转换为物理值。 如果 FDD 提供的数据与信号不匹配，则按帧中应有的方式构造信号。
其次，EDD需要向FDD提供“数据改变”事件状态报告。 例如，当有一个周期性信号改变门状态时，只有当它像事件信号一样改变值时，才会被FDD注意到。 上述EDD的虚拟设备驱动模块由具有ECU的传感器和执行器单元拥有。
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格式，可以直接用ARA::COM解析。 因此，对于上述两类消息，EDD可以直接部署在AP侧的ARA::COM模块中。
由于ARA::COM无法直接解析UDP数据包，对于UDP协议数据包，有直接来自传感器和执行器的原始数据协议，取决于AP上的SWC分配，借鉴设备抽象方法的概念，如果在相应的处理控制器直接用SomeIP头+PDU路由封装UDP协议消息，然后可以通过ARA::COM解析数据。 也就是说，解析模块EDD可以直接集成到ARA::COM中，UDP协议包打上Someip的头部，输入到ARA::COM中，由EDD解析。
当然，如果不考虑资源消耗，我们完全可以将AP侧ECU抽象层（EAL）中的EDD模块去掉，放在Autosar平台之外的Service Layer和EAL之间。 此时，UDP数据包可以直接输入到EDD模块中，直接与FDD信号进行交互。
当然，作为折衷方案，我们建议将EDD合并到ARA::COM层，并使用UDP添加报头进行消息解析。
FDD应用场景部署原理和方法
FDD进行数据分析和分包后，输入到EDD进行设备驱动。 EDD提供与FDD业务包要求相对应的真实数据（这些物理真实数据包括原始信号、物理值、解析偏移量和解析精度）。 驱动软件接口与Autosar独创的Can网管应用相关模块Com接口连接，使得Net Management的Userdata数据能够在中间件Com模块中得到很好的处理。 另外，通过选择管理类型，Com 将在 PN 下使用。 相关接口函数处理PN网络管理、信道管理，设置Gateway控制，并根据信道关联到基础软件BSW和用户软件User，实现状态通知和接收BSW和User的控制。
对于FDD部署流程，第一步应该是确定需要部署的芯片核心的结构，哪些核心可以用来部署软件FDD组件，以及对应的核心性能是否可以承载FDD对应的功能服务。
以视觉感知处理为例，FDD提供的服务群需要两类芯片来承载其功能和性能：一是安全核心（Safety Core）；二是安全核心（Safety Core）。 另一个是性能核心（Performance Core）。 安全核心一般由英飞凌TC297/397等MCU担当，承载控制任务（计算量通常面向比较简单的整数数据计算），因此对功能安全等级要求较高； 性能核心通常具有较高的性能，具有高性能计算能力的多核异构MPU将承载大量的计算任务。 FDD的SWC部署通常需要对整个ECU所包含的所有核间结构进行整体分析。
整个FDD软件主要部署在ServiceLayer和应用软件组件服务之间。 部署的数量和位置主要根据不同应用软件服务需要实现的功能而定。
对于整个FDD实现的应用服务来说，软件部署和资源利用需要充分考虑以下因素。
a) 该功能对其响应的实时性是否有较高要求。 可实现性高的功能通常需要直接部署在实现FDD服务功能的硬件ECU中；
b) 该功能是否需要大量模拟输入和输出。 模拟输入输出意味着抗噪能力相对较差，传输链路要尽可能短且稳定，尽可能保证信号不失真；
c) I/O与计算分离后业务逻辑变化是否有特殊要求； 业务逻辑的变化主要是指当顶层计算服务所需的执行层能力发生变化时，底层执行层能否做出相应的改变和适应；
d) 计算时的输入参数是否需要通过虚拟总线VFB传输； 如果需要通过总线传输参数，可能会造成处理延迟，从而影响应用层软件的处理能力；
e) 对于Autosar中部署的不同应用端软件组件，还需要充分考虑不同软件组件的SWC模块需要在顶层应用程序和底层基础软件之间调用尽可能少的数据读写。 同时，AP侧和CP侧通过虚拟总线VFB交换的数据带宽和数据量不宜太大，以免造成传输延迟或总线负载过大等不良后果。
f) 另外，OEM或供应商是否具备将某个功能的I/O和计算分离的技术能力？ 是否有利于优化成本？ 每个功能对硬件能力的要求是否不同？ 集成后，在新的硬件平台上是否也满足要求，开发集成ECU的难度如何等。
FDD与EDD交互逻辑
下面用逻辑架构图和时序图来说明FDD和EDD的交互逻辑。
从下图不难看出，对于中央控制器+区域控制器的控制逻辑来说，FDD和EDD的整个交互过程可以从上到下分解为三种层次模式。 顶层是中央控制器单元Central ECU，中间层是区域控制单元Zone Controller，底层是传感器&执行器ECU，底层是物理I/O接口输入输出。 从上到下，首先是应用软件，通过FDD模块向实际应用单元提供固定的服务接口。 其中包括重新封装接口、提供物理值、匹配精度、纠正偏移以及建立网络管理层和应用层之间的交互。 其次，Network Management 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接口类型。
概括
本文从整个设备抽象的角度宏观分析了如何建立从顶层功能服务需求到底层硬件驱动的软件组件部署流程。 提出了两个重要的概念，功能设备抽象服务FDD和执行设备抽象服务EDD。 它们严格来说并不是Autosar的核心组件，而是在上层和下层之间传输数据的过程中发挥作用。 数据转换使得目标层能够很好地解析原子服务。 本文还重点介绍了如何在我们常用的芯片内核上优化部署FDD和EDD。 下一节我们将通过示例来分析几个常用功能服务的部署问题，并给出典型部署过程中的常见步骤。 出现的问题将进行详细分析。
