对于下一代集中式电子电器架构而言，采用central+zonal 中央计算单元与区域控制器布局已经成为各主机厂或者tier1玩家的必争选项，关于中央计算单元的架构方式，有三种方式：分离SOC、硬件隔离、软件虚拟化。集中式中央计算单元将整合自动驾驶，智能座舱和车辆控制三大域的核心业务功能，标准化的区域控制器主要有三个职责：电力分配、数据服务、区域网关。因此，中央计算单元将会集成一个高吞吐量的以太网交换机。

随着整车集成化的程度越来越高,越来越多ECU的功能将会慢慢的被吸收到区域控制器当中。而平台化区域控制器则是采用相同的硬件设计、相同的IO接口看，可以更好的满足对于不同车型的扩展性要求。所以，区域控制还同时承担整车硬件抽象的重要职能。其两者之间都会采用高速以太网代替原始的Can通信进行相互连接。概括来讲，可拓展的电子架构就是要屏蔽车型之间的硬件差异。不管采用多少个区域控制器组成的通讯网络，其相互之间的通讯模式，都遵守同样的规则。同时区域控制器也承担其局域网内，ECU功能的抽象之责。

如上以中央计算平台为核心的集中式架构设置了统一的传感器及外设接口，能够支持芯片的升级，其最终目的就是要实现在车生命周期内的硬件可升级，从而延长汽车的智能化生命周期。而各区域控制器各自带有自己的操作系统中间件SOA Core Middleware，可以提供一个分布式计算和通信框架，对下屏蔽各类操作系统系统内核差异，对上提供统一的服务开发框架。涉及功能包括服务管理、网络管理、通信管理、升级、诊断、日志、状态等。

本文将重点重软硬件解耦的方向讲解如何对SOA进行软硬件部署。

01 SOA的软件架构设计原理

如下图表示了典型的SOA软件架构设计原理。这种以服务为目标的开发架构实际上是实现面向服务开发的SOA架构模型方案，让产品经理专注于服务的设计，而系统软件则深入到产品的开发过程中，这也是解决汽车软件危机的重大突破。整个SOA架构可以总结为由逻辑架构构建起的一个软硬解耦的系统和由服务架构完成的服务抽象与适配，最终建立了一个标准化的服务体系。 

其整体逻辑架构设计过程可概括为：

电子电气架构：设计可拓展的架构（也叫计算与通信架构）需要满足分层设计、分层测试、分层验证要求，避免在开发阶段软件更迭的连锁反应和集成测试中问题集中爆发，使得发现问题更加迅速，软件版本更迭更加快速。

硬件计算平台：可扩展的硬件平台包括SOA基础服务管理和SOA硬件I/O控制管理，可兼容自动驾驶系统的多个传感器和外部设备，支持多异构芯片和硬件升级。

操作系统内核/服务中间件：作为文件调度和驱动的核心，操作系统在支撑软硬件解耦和软件在硬件上的部署方面可以实现最好的支配能力。

通信架构：通信架构的可扩展性可以很好的确保平台化车型开发中快速适配，车型之间的差异可以减少到最少，开发下阶段车型秩序进行通信扩展借鉴当前这代产品，不用再进行很多额外的开发工作，这样可以大大减少后期产品线维护的压力。

为了满足车辆控制实时性的要求，核心网将会采用如TSN等的可靠通讯技术。在区域控制器下的局域网内，传统的CAN、Lin等通讯方式将会继续存在。局域网内可以以传统的信号的方式进行通信，在核心的以太网骨干网络中，将会以服务的方式进行数据之间的交互，就需要如DDS等通信中间件。

服务层/应用层：标准化的服务层及可编排的应用层包含SOA系统功能管理、单元域功能管理、整车功能控制管理、云端服务管理几个重要部分。

02 SOA中的设备抽象技术

在详细分析以中央域控为核心的软件架构部署核心技术之前，需要详细说明一下相关联的几个重要概念。Autosar中的传感器/执行器设计模式描述了在整体架构环境中ECU如何处理在环的传感器/执行器。

BEG设备抽象位于RTE（是试运行环境之上），它是从连接到特定ECU的传感器和执行器中抽象出来的一组软件组件，他使用了传感器或执行器软件组件，是RTE之上唯一允许访问ECU抽象接口的组件。设备抽象提取传感器和执行器的原始信号，如像素点、点云、电压、PWM信号、数字信号/消息、频率，并为应用层软件提供物理接口（例如像素点、点云、压力、质量、温度等），实际说来，设备抽象完成了电压值、数字信号、点云等到物理值的转换。

设备抽象体现了应用层软件通过平台软件及底层驱动软件在其他不同硬件变体之间的可互换性。

表1平台软件与设备抽象关系（传感器）

表2 平台软件与设备抽象关系（执行器）

 总结来讲，BEG设备抽象概念和设计可概括如下：

应用软件独立于连接到特定ECU的具体传感器和执行器；

不同传感器和执行器之间代码可复用；

不同的代码共享合作模式（软件共享），从而支持不同的商业模式；

将功能部署或重新分配到不同的ECU；该设计模式也被称为设备抽象；

设备抽象解决了S&A层Module向上暴露功能及服务接口，向下连接平台软件，目标是尽可能地暴露接口，实现软硬件解耦，避免因S&A变化导致地软件变更。

03 SOA中的设备抽象示例

这里我们列举一个实例说明在SOA架构中如何进行设备抽象。这种方式只需要了解传感器类别（如雷达、摄像头等）来定义输入的原始数据Rawdata，无需了解这些传感器的具体连接方式，对于顶层应用层则是只需要应用最终的传感数据。

以传感器的设备抽象为例，可以表示如下： 

首先是在底层物理层MCAL通过访问uC端口的方式进行数据采集并提供原始数据，每隔一定周期（如10ms）检测一次，这里不需要了解器电器连接方式以及相应的数据含义。比如从底层激光雷达传感器采集到原始图像像素点数据，并输入给微控制器MCU/SOC。 

其次，MCU/SOC从对应物理地址中按照一定周期取出对应的点云值，通过I/O设备给I/O硬件抽象模块，并通过I/O硬件抽象点检测所测数据测量点的一级电器连接路由，传感器基于路由信息和解读后的原始数据计算的电压值并进行滤波处理，该过程不需要了解所测数据的含义。

随后，将硬件抽象模块中的电压值按照8bit驱动进行分阶处理，并由传感器电子设备驱动调用生成基础原始值。该值通过传感器虚拟设备驱动Virtual Device Dri 行人、路标等。

最终，AP Autosar中的应用软件通过实时运行环境RTE对传感器感知目标级数据进行实时的读取，用于后续的应用软件的规划控制和决策控制。

从如上示例可看出，设备抽象具备如下优势，Sensor&Actuator的变化不会引起平台软件和应用软件的连带更改，总结起来大致有如下几种变换导致的软硬件解耦类型。 

对于替换不同型号的感知传感器，ECU的选型不再受限制于ECU支持的信号分析模式的型号。如NTC和PTC型号的替换，只需要修改位于Device Driver中软件模块即可。

同一类型的传感器和执行器模块可共用某些相同的处理模块，比如对于侧视摄像头的处理模式，可以直接将对其中一个侧视摄像头的处理算法直接应用于其余三个，而只需要重新对该三个摄像头的相机参数进行标定即可，如果有部分摄像头需要更新换代为更高分辨率摄像头，对于底层驱动软件和平台软件来讲也是无需做很大变动的，至少I/O接口形式和数据输入模式都不用在动，只是在处理图像的算法模块需要重新进行调优，比如原来采用的低分辨率处理算法可能无法达到高分辨率处理模块对其实时性的要求，这时需要研究神经网络加速模型的优化方式，但是整体的算法架构模型是仍旧不变的。

04 总结

当前众多主机厂比较倡导的开发方式是进行平台化产品开发，而平台化讲求的就是软硬件解耦的核心思想，采用SOA架构模式则是便于形成产品线和平台线的分工，产品线负责具体车型项目，平台线，负责构建技术中台。新平台的开发，技术链路往往非常长且复杂，分层的架构设计和软硬件解耦的方式，可很好的便于进行分层测试与验证，减少集成测试的压力，问题发现的更充分，也能够提高版本发布的速度。​