ee架构开发流程SOA中的软件架构设计及软硬件解耦方法论

导读以下文章来源于焉知智能汽车，作者Jessie侵删对于下一代集中式电子电器架构而言，采用centralzonal中央计算单元与区域控制器布局已经成为各主机厂或....

以下文章来源于焉知智能汽车 ，作者Jessie 侵删

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

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

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

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

SOA的软件架构设计原理

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

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

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

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

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

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

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

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

SOA中的设备抽象技术

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

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

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

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