对于下一代集中式电子电气架构，采用中央+区域中央计算单元和区域控制器布局已成为每个OEM或tier1的必备选择播放器，关于中央计算单元的架构，有独立SOC、硬件隔离、软件虚拟化三种方式。集中式中央计算单元将集成自动驾驶、智能座舱和车辆控制三大领域的核心业务功能。标准化的区域控制器具有三个主要职责：配电、数据服务和区域网关。因此，中央计算单元将集成一个高吞吐量的以太网交换机。随着整车集成度越来越高，越来越多的ECU功能将逐渐被吸纳到区域控制器中。平台区域控制器采用相同的硬件设计和相同的IO接口，可以更好地满足不同机型的扩展需求。因此，区域控制也承担了车辆硬件抽象的重要功能。两者将使用高速以太网代替原来的Can通讯进行互联。简而言之，可扩展的电子架构是为了屏蔽模型之间的硬件差异。无论通信网络中使用多少个区域控制器，它们之间的通信方式都遵循相同的规则。同时，区域控制器还负责其局域网内ECU功能的抽象。上述以中央计算平台为核心的集中式架构，设置了统一的传感器和外设接口，可以支持芯片的升级。最终目标是实现车辆生命周期内硬件的可升级，从而延长车辆的智能寿命。循环。并且每个区域控制器都有自己的操作系统中间件SOACoreMiddleware，可以提供分布式计算和通信框架，从底层屏蔽各种操作系统内核的差异，向上提供统一的服务开发框架。涉及的功能包括服务管理、网络管理、通信管理、升级、诊断、日志、状态等。本文将围绕软硬件解耦来讲解SOA如何部署软硬件。01SOA软件架构设计原则下图展示了一个典型的SOA软件架构设计原则。这种面向服务的开发架构，实际上是面向服务开发的SOA架构模型解决方案，让产品经理专注于服务设计，而系统软件则深入到产品开发过程中，这也是汽车软件危机的解决方案。重大突破。整个SOA架构可以概括为一个由逻辑架构构建的软硬件解耦系统，由服务架构完成的服务抽象和适配，最终建立标准化的服务体系。其整体逻辑架构设计流程可概括为：电子电气架构：设计可扩展的架构（也称计算和通信架构）需要满足分层设计、分层测试、分层验证的要求，避免软件变更链。开发阶段响应和集成测试中问题的集中爆发，更容易发现问题并更快地更改软件版本。硬件计算平台：可扩展的硬件平台包括SOA基础服务管理和SOA硬件I/O控制管理，兼容自动驾驶系统的多种传感器和外部设备，支持多异构芯片和硬件升级。操作系统内核/服务中间件：操作系统作为文件调度和驱动的核心，在支持软硬件解耦、软件部署在硬件上可以做到最好的主导。通信架构：通信架构的可扩展性可以保证在平台化模型开发中的快速适配，将模型之间的差异降到最低。下一阶段机型开发的通信扩展顺序以当前一代产品为基础，不需要再进行很多额外的开发工作，可以大大减轻后期产品线维护的压力。为满足车辆控制的实时性要求，核心网将采用TSN等可靠通信技术。在区域控制器下的局域网中，CAN、Lin等传统通信方式将继续存在。在局域网中，可以通过传统的信号形式进行通信。在核心以太网骨干网中，数据将以服务的形式进行交换，这就需要DDS等通信中间件。服务层/应用层：标准化服务层和可编程应用层包括SOA系统功能管理、单元域功能管理、车辆功能控制管理、云服务管理。02SOA中的设备抽象技术在分析以中央域控制为核心的软件架构部署的核心技术之前，有必要对几个重要概念进行详细说明。Autosar中的传感器/执行器设计模式描述了ECU如何在整体架构的上下文中处理循环中的传感器/执行器。BEG设备抽象位于RTE（在试运行环境之上），它是一组软件组件，从连接到特定ECU的传感器和执行器中抽象出来。它使用传感器或执行器软件组件，并且是唯一高于RTE的组件。允许访问ECU抽象接口的组件。设备抽象提取传感器和执行器的原始信号，如像素、点云、电压、PWM信号、数字信号/消息、频率，并为应用层软件（如像素、点云、压力、质量、温度等），其实就是设备抽象完成了电压值、数字信号、点云等到物理值的转换。设备抽象体现了应用层软件通过平台软件和底层驱动软件在其他不同硬件变体之间的互换性。表1平台软件与设备（传感器）抽象关系抽象分层动作工作原理工作细节平台软件输入原始采集值、输出电压值解耦软硬件连接提供物理特性原始接口机械特性、电气特性、功能特性和程序特性.电气设备驱动输入电压值，输出滤波电压值保证传感器测量值的可用性运行电气设备驱动软件电气诊断（如检测接地、电池短路、开路等）去噪滤波器电压补偿外接电源时的sensordevicedriver输入电压值，输出sensorcontainingvaluessuchaspixel,pointcloud,temperaturevalue解耦不同sensor差异项执行sensordevicedriver；控制传感器的物理行为；从原始信号（电信号）到物理值的转换；零点和偏移适配，测量值的漂移检测，诊断检查，物理值检查，过滤功能（包括下采样），虚拟设备驱动程序，输入传感器意义值，输出互补完整值，如亮度值解耦传感器信号补偿端传感器虚拟设备驱动程序抽象出软件程序的物理表示·信号质量评估·信号原值替换（如传感器信号质量不足时）·信号原值补偿·信号原值验证·功能测试诊断接口表2平台软件与设备抽象关系（执行器）抽象分层动作工作原理工作细节平台软件输入PWM、输出PWM值解耦软硬件连接提供物理特性原始接口机械特性、电气特性、功能特性i静态和程序特性。电子设备驱动输入电压值，输出滤波电压值，保证执行器执行过程的有效性运行电气设备驱动软件电气诊断（如检测接地、电池短路、开路等）噪声去除滤波器电压补偿当执行器外部供电时执行器装置驱动输入PWM，输出保护和相应的PWM值解耦驱动机械过程解耦执行器能力保护传感器装置驱动器代表执行器的物理行为叠加输出值以克服驱动器摩擦输出驱动信号值并保证有效执行限制输出值以防止过度损坏控制设定点（带传感器数据的闭环）提供限制和容量信息的接口虚拟设备驱动器输入执行器请求值输出PWM值，例如阀门开度解耦传感器执行溢出等处理虚拟设备执行程序抽象执行器的物理表示·控制端物理请求值的转换·非线性值到线性值的转换·用于功能测试的诊断测试仪接口·特殊模式处理启动执行器操作消除通过覆盖设定点或过滤协调执行器特定传感器和执行器的执行器抖动；不同传感器和执行器之间的代码可重用性；不同的代码共享合作模式（软件共享），支持不同的商业模式；将功能部署或重新分配到不同的ECU；设计模式也称为设备抽象；设备抽象解决了S&A层Module向上暴露功能和服务接口，向下连接平台软件的问题。目标是尽量暴露接口，实现软硬件解耦，避免S&A变更导致软件变更。03SOA中设备抽象的例子下面我们举一个例子来说明在SOA架构中如何进行设备抽象。该方法只需要知道传感器类别（如雷达、摄像头等）即可定义输入的原始数据Rawdata，不需要知道这些传感器的具体连接方式。对于最顶层的应用层，只需要应用最终的传感器数据。以传感器的设备抽象为例，可以表示为：首先，底层物理层的MCAL通过访问uC端口采集数据并提供原始数据，每隔一定周期（如10ms）检测一次。这里不需要了解设备的连接方式和对应的数据含义。例如，原始图像像素数据从底层激光雷达传感器收集并输入到微控制器MCU/SOC。其次，MCU/SOC根据一定的周期从对应的物理地址中取出对应的点云值，通过I/O设备发送给I/O硬件抽象模块，对被测的第一层进行检测数据测量点通过I/O硬件抽象点电器连接到路由，传感器根据路由信息和解释后的原始数据计算出的电压值经过过滤，过程不需要理解含义的测量数据。随后，硬件抽象模块中的电压值根据8bit驱动程序逐级处理，并被传感器电子设备驱动程序调用，生成基础原始值。该值通过传感器虚拟设备驱动虚拟设备驱动行人、路标等。最后，APAutosar中的应用软件通过实时运行环境RTE实时读取传感器感知到的目标级数据，用于后续应用软件的规划控制和决策控制。从上面的例子可以看出，设备抽象有以下优点。Sensor&Actuator的变更不会引起平台软件和应用软件的联合变更。归纳起来，改造造成的软硬件解耦大致有以下几种。对于不同类型感知传感器的更换，ECU的选择不再受ECU支持的信号分析模式类型的限制。如更换NTC和PTC型号，只需要修改位于DeviceDriver中的软件模块即可。相同类型的传感器和执行器模块可以共享一些相同的处理模块。例如，对于侧视摄像头的处理方式，其中一个侧视摄像头的处理算法可以直接应用到其他三个，只需要重新处理三个摄像头的摄像头参数即可校准。如果某些摄像头需要更换为更高分辨率的摄像头，则无需对底层驱动软件和平台软件进行较大改动。至少I/O接口格式和数据输入方式不需要改变，但是图像处理的算法模块需要重新调优。例如，原有的低分辨率处理算法可能无法满足高分辨率处理模块的实时性要求。这时候就需要研究神经网络加速模型的优化方法，但是整体的算法架构模型保持不变。04总结目前很多主机厂提倡的开发方式是进行平台化的产品开发，平台化强调软硬件解耦的核心思想。采用SOA架构模式，便于形成产品线和平台线的分工。产品线负责具体车型项目、平台线、搭建技术平台。在新平台的开发中，技术环节往往很长很复杂。分层的架构设计和软硬件解耦的方式，便于分层测试和验证，减轻集成测试的压力，更充分地发现问题，也可以提高版本发布的速度。
