这里整体的部署说明可表示如下：
○ 场景部署到对应区域控制器，需要根据服务接口进行整体考虑，如AP端自身应用服务也需要暴露服务接口，因此需要集成对应的服务用协议簇；
○ 对应部署该应用（如车灯控制）的服务用协议簇，可直接对外暴露服务；
○ 传感数据直接使用服务，应尽量避免经过车辆控制层来间接调用，而是可以直接调用FDD服务，而执行器则需要通过车辆控制层的SWC来调用FDD服务。
对于高阶自动驾驶系统而言，需要保证以最好的车身姿态才能确保其车身传感器的探测能力达到最优，最终其功能控制达到最优。IO原子服务如果采用区域控制器进行直接连接，可以很好的提供原子级服务，因为，区域控制其集成了服务协议簇，便于使用和暴露服务，考虑全车应用的实时性要求，可考虑直接将IO原子级服务的解析单元FDD直接部署到对应底层区域控制器中。这里，部分应用软件SWC可以直接通过调用封装到该区域控制器PDC的FDD调用对应的IO原子服务，同时在顶层应用端进行状态转化和模式控制后，输出给对应的区域控制器PDC进行底层驱动控制。这里的PDC数据封装及服务拆解都是原子级的，参考使用的协议簇都是布置到其中的FDD协议簇。
除了以上部署场景分析外，还有一种比较典型的部署场景分析，就是仅AP端接收信号及使用原子服务，该应用类型一般适用于只有其中一种区域控制器使用该原子服务的场景，比如毫米波雷达提供的原子服务，则可以连接到AP端直接暴露出来即可。
如前所述，整个功能控制模块服务FDD、执行转化模块服务EDD在部署过程中不仅需要多方考虑其实现的实际功能子项性能指标如何，更要确保部署完成后能够最大限度的满足要求同时节省硬件资源。我们知道CP Autosar端由于其成熟性，相应的应用比较多，导致其负荷增加，且FDD集中部署，导致其负荷集中增加。且为了减少架构途中Port数量，可以考虑将FDD对外暴露接口和对内爆率的接口定义相同的类型，甚至名称。且部署过程中尽量随应用而定，分散部署。因此，考虑在功能部署时，哪些必要的功能部署放在CP端（比如微控制驱动、内存驱动、通讯驱动、IO驱动等），而其他内容则放在AP端，如传感器时间同步、身份管理，加密、AI驱动等。总体说来可通过如下的评价指标项对部署是否合理进行总体概括。
区域控制器的数据传输过程中，通常存在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接口可实现软硬件解耦。
