如果采用服务级接口进行传输，则需要在相应的驱动控制器端（如PDC端）进行服务打包封装，且对于其需求端的区域控制器（如VDC、HPC）其对于该使用信号内容（如车速、扭矩等）服务调用接口（即该接口形式为Someip接口）应该是唯一的。当然，这种情况下的服务信号转化效果相对较差，因为转化过程中，受到对应封装端区域控制器（如一般的PDC功能安全等级仅为ASIL B）本身功能安全和实时性影响，可能原始状态下的高功能安全等级信号通过转化后，其功能安全等级会对着本身部署的区域控制器功能安全等级而相应的降低，其时延性会相对加长。

如前文所述，对于Autosar的AP端和CP端各自有不同的特点。其中，AP端软件能力为高算力、大运算量、服务类通信、低安全级别、低实时性、功能多样化；CP端软件能力为中低算力、多控制功能、高安全级别、高实时性、快速启动。因此对于功能安全要求高的场景，我们将采用如下的部署方法：

FDD单独各自部署到计算平台CP端，用于CP端中的自身业务服务和控制器AP端业务，CP端集成服务协议簇，可以直接对外暴露对应的服务接口。一般情况下，AP端自身的APP也需要暴露服务，同时也需要集成服务用协议簇，但是，AP端业务实时性要求并不高，因此这种功能不适用于实时性高的场合，AP端部署仅为可选项，并不被推荐。这里可直接使用CP端来部署FDD提供对应的业务；但是如果在CP端部署过多的FDD，将会导致资源消耗的增加，且使用效率较低。

部分区域控制器部署的原子级服务，仅仅限于该区域控制器内部的SWC使用，一般不对外开放。

对应的服务部署到使用端。确保服务其时延性最小，且不降低原始信号的功能安全等级。

常用的方法是需要直接通过UDP裸包传输到各需求控制器（如高性能计算控制器HPC）中，且对于HPC中的各个软件模块，如AVP视频/感知、ADS感知、ADS规控、VMC几个方面将根据其需求，各自选择对应的FDD接口单独提取相应的服务转化信号。

需要将FDD直接部署到对应的区域控制器使用端。这里举个例子，对于像车速Vehicle Speed这种实时性要求比较高的原子服务，通常源自于ESP，对于该信号的要求通常是采用

部署场景举例2
自动换道功能提示及灯光控制

a)功能场景描述：

自动驾驶车辆在适当的时机自动控制车辆换道至目标车道，同时，提前开启换道提示（仪表界面显示或座椅震动提示）和转向灯控制

b)功能特点：

实时性不高、功能安全低的原子服务部署

c)部署分析：

比如车灯状态和车灯控制服务，这种对于实时性要求不高、功能安全要求也不高的原子服务，我们可以考虑直接将FDD部署到主要对车灯控制的区域控制器（如PDC）中，通常在该区域控制器的CP端进行封装即可，封装后的车窗服务，可以直接对外暴露对应的服务接口。如HPC或VDC想要调用该车窗服务时，可以直接通过PDC暴露的接口定义进行调用，且不必过分关注延迟性和功能安全。而调用的计算单元控制器HPC、VDC内部可以直接通过中间件RTE读写单元进行信息读写。

这里整体的部署说明可表示如下：

○ 场景部署到对应区域控制器，需要根据服务接口进行整体考虑，如AP端自身应用服务也需要暴露服务接口，因此需要集成对应的服务用协议簇；

○ 对应部署该应用（如车灯控制）的服务用协议簇，可直接对外暴露服务；

○ 传感数据直接使用服务，应尽量避免经过车辆控制层来间接调用，而是可以直接调用FDD服务，而执行器则需要通过车辆控制层的SWC来调用FDD服务。

部署场景举例3
智能主动悬架控制功能

a)功能场景描述：

对于高阶自动驾驶系统而言，需要保证以最好的车身姿态才能确保其车身传感器的探测能力达到最优，最终其功能控制达到最优。

b)功能特点：

区域控制器直接连接IO原子服务。

c)部署分析：

IO原子服务如果采用区域控制器进行直接连接，可以很好的提供原子级服务，因为，区域控制其集成了服务协议簇，便于使用和暴露服务，考虑全车应用的实时性要求，可考虑直接将IO原子级服务的解析单元FDD直接部署到对应底层区域控制器中。这里，部分应用软件SWC可以直接通过调用封装到该区域控制器PDC的FDD调用对应的IO原子服务，同时在顶层应用端进行状态转化和模式控制后，输出给对应的区域控制器PDC进行底层驱动控制。这里的PDC数据封装及服务拆解都是原子级的，参考使用的协议簇都是布置到其中的FDD协议簇。

除了以上部署场景分析外，还有一种比较典型的部署场景分析，就是仅AP端接收信号及使用原子服务，该应用类型一般适用于只有其中一种区域控制器使用该原子服务的场景，比如毫米波雷达提供的原子服务，则可以连接到AP端直接暴露出来即可。

部署评价原则

如前所述，整个功能控制模块服务FDD、执行转化模块服务EDD在部署过程中不仅需要多方考虑其实现的实际功能子项性能指标如何，更要确保部署完成后能够最大限度的满足要求同时节省硬件资源。

我们知道CP Autosar端由于其成熟性，相应的应用比较多，导致其负荷增加，且FDD集中部署，导致其负荷集中增加。且为了减少架构途中Port数量，可以考虑将FDD对外暴露接口和对内爆率的接口定义相同的类型，甚至名称。且部署过程中尽量随应用而定，分散部署。因此，考虑在功能部署时，哪些必要的功能部署放在CP端（比如微控制驱动、内存驱动、通讯驱动、IO驱动等），而其他内容则放在AP端，如传感器时间同步、身份管理，加密、AI驱动等。

总体说来可通过如下的评价指标项对部署是否合理进行总体概括。

FDD和EDD在实际开发中的问题分析

1、区域控制器之间传输延迟问题

区域控制器的数据传输过程中，通常存在CAN协议到以太网协议UDP的转化过程中，比CAN转CAN仅仅多了PDU-Router部分的时延，端对端延迟会比CAN之间的协议转化更为严重，且以太网本身带宽理论上延迟是很小的，与CAN-CAN之间的传输相当。

而当UDP打包太多时（有时甚至上千个包），通常是按照Message条目单独打包，没有合包，这可能导致延迟性不可估量，且这种延迟不是传输导致的延迟，而是在区域控制器之间打包和拆包过程中存在一定的性能差异导致的。且这种服务转化的操作通常会在功能安全较高的专业区域控制器（如VDC中）的内核及资源中进行，这可能导致实时核算力不足，其最终结果可能导致无法满足实时性要求高的功能性能要求。

为了解决如上问题，我们有多种解决方案可供参考，从表象上看，可以使用CAN转CAN-FD接入计算平台（50ms以下周期的数据采用该方案），但是这种方式实际是治标不治本的。而考虑多个UDP包可能导致的带宽和对控制器的处理延迟，可以将UDP进行打包时综合考虑参照一定性能指标同时合并数据包。且如果针对实时性要求不高的数据包协议整合转化FDD，则尽可能地部署在功能安全较低的区域控制器（如PDC、CSC）上。

2、数据通过RTE读写多，导致整体系统负荷增加（主要是BSW负荷增加）

在CP Autosar端的RTE上通常不会全方位布局FDD和EDD，其他应用调用传感器和执行器的数据时，都要经过车身控制层Vehicle Ctrl，导致一个普通的应用需要的数据，需要增加多次RTE数据读写，并且RTE的读写随着传感器数据使用场景呈现直线上升。这种多次读写往往会增加系统的计算负担，因此，通常采用分块布局的方式

这种问题的解决方案也比较简单，因为FDD相互之间没有调用关系，其颗粒度大小不会影响RTE读写次数，可以将传感器信号不通过车辆控制Vehicle Ctrl层，而执行器才经过车辆控制层Vehicle Ctrl，而EDD则布局到Autosar中的COM层替代其相应的功能进行ECU功能解析。

总结

本文从实例分析出发总结了相应的软硬件解耦的模块布局。整个功能服务部署的核心就是信号到服务的转化，同时保持相对固定的接口到应用，屏蔽传感器和执行器的变化，基于功能需求、过颗粒度问题。FDD可以按需实现信号组合，提供服务/内部接口给应用，FDD的对内和对外提供的是一个接口，通RTE识别和匹配实现，传感器和执行器对应的数据，总线上有两种数据形式，信号接口和FDD接口，可提供SWC使用，使用FDD接口可实现软硬件解耦。

上一篇：国外线控制动技术现状及趋势综述下一篇：自动驾驶科普文之一：场景来源、场景泛化及提取