上汽零束SOA电子电器架构

文章来源：质海无涯@知乎、智能汽车开发者平台发布时间：2022-02-10

分享到

整理了上汽零束的SOA架构，以下是零束银河全栈3.0的模块化开发全览，分为轻应用开发环境、图形化开发环境、集成IDE开发环境、软件开发组件、应用商城、场景商场、数字汽车。

其中基于数字汽车的SOA架构走在行业领先的位置，基于区域控制器的开发思路，将运算逻辑上移，底层完成信号的采集和IO输入，Zone控制完成路由, 最终由控制中央计算系统完成逻辑运算和云端交互。其中HPC1&HPC2为两个主要的计算大脑，HPC1同步负责与云端通讯，同时完成OTA的功能。Zone1～4负责传感器信号采集和路由。

以下内容基于公众号的内容进行梳理，供大家学习参考。从几个方面进行介绍：

1.SOA架构的定义基于

2.传统EE架构的开发流

3.SOA架构的开发流

4.SOA驾构的开发趋势

5.域控制为核心的架构

6.区域控制为核心的SOA架构

7.以服务为核心的SOA开发思路

8.SOA的软件架构

9.以EBS为通讯的连接方式

SOA架构的定义

SOA (Service Oriented Architecture) ，即面向服务的架构。SOA将车端不同功能及硬件能力划分为服务，并按照整车的原子能力将对应服务拆分为颗粒度更小的接口。各服务组件的接口进行标准化封装，可通过既定协议互相访问、扩展组合；其核心要素包括松耦合、标准化定义、软件复用等。SOA使应用层功能能够在不同车型上复用，且能够基于标准化接口快速响应用户新的功能需求。此外，通过SOA平台能够充分调用整车各域的传感器、执行器的硬件能力。

如果说SOA是软件定义汽车实现的软件基础，那整车集中电子电气（EE）架构是SOA架构能够得以发挥的硬件基础。

传统EE架构的开发流

(1)用户需求整理

由市场部经过调研后，站在用户角度描述了本车型项目所具备的性能，配置要求等，比如具备电动车门，座椅加热等。

(2)功能需求和功能逻辑架构分析

基于上述功能清单，电子电气架构团队将对各个功能的逻辑架构进行分析。将基于用户角度描述的功能，转变为基于技术角度的方案。比如电动车门的工作条件，工作逻辑，故障判断等。在这个过程中，复杂功能会被分解成多个逻辑块。这些逻辑块可以属于不同系统，被分配到不同的硬件上。比如电动车门，需要判断车速条件，车速模块位于底盘系统，而车门控制属于车身系统。因此一个功能往往涉及到多个系统之间的交互。跨系统的交互则引出了网络通信的需求。

(3)系统架构分析

接下来对系统进行进一步细分及需求整合。不同功能可能对同一个子系统都有需求。因此在系统架构分析这一步，需要综合所有需求，针对每个子系统，输出相关需求文档，包含场景需求，输入输出接口，性能需求，HMI需求等。通常在这一步也会完成功能分配，即子系统是由哪个硬件承接完成的。根据功能分配，子系统接口又被分为网络接口和硬线接口。

(4)零部件开发规范

上步完成的功能分配，确定了每个硬件需要实现哪些子系统。零部件开发规范整合所有的子系统需求，完成零部件级别的开发需求，比如硬件接口，系统原理图，收发的网络信号等。

传统的架构开发流程基本上到此结束，最重要的工作在于子系统架构分析，在这一步功能完成了从用户语言到技术语言的转变。然而这种开发流程存在以下几个问题：

(1)系统方案依赖供应商。 虽然功能分配在子系统分析之后，但实际上子系统由哪个硬件实现，已经由供应商决定。甚至某些子系统之间的交互接口，也是通过供应商提供的信号清单定义的。

(2)软件架构是黑盒。 在整个架构开发过程中，整车厂不参与软件实现方案，只提功能需求。

这样导致的后果是，更换功能变得很被动。因为受限于供应商的方案和ECU软件平台的不同，任何的更新都需要牵扯多方联动，效率低下。

而这又与“软件定义汽车”的理念相违背。软件定义汽车，是希望能够为用户在整车生命周期内都提供持续的应用更新。

SOA架构的开发流

服务架构设计和软件架构设计位于逻辑架构设计和系统架构设计之间。服务架构设计的目的是：

(1)将逻辑块转变为服务参与方（participant），服务参与方之间的交互接口为服务接口（service interface）。每一个服务代表一个独立的功能，具有统一标准的接口。

(2)通过对整车逻辑的分析，将重复的功能整合为一个服务，减少相同的逻辑块，节省成本。

软件架构设计，是关联服务和软件模块，使服务实例化。实例化意味着服务的实现有了载体，相同的服务可以由不同的载体实现，在系统中有不同的实例。比如camera服务，可以被实例化多次，表示整车不同位置的摄像头。

因此，基于服务的架构开发，实际上是以服务的方式对整车的功能进行拆解，将黑盒子的ECU白盒化，为未来扩展和功能更新，提供了良好的基础。软件架构白盒化之后，功能的更新和重新部署都更为透明，快速和便捷。所谓软件定义汽车，只有当我们把硬件的边界打破，软件之间能够互相“看得到”对方，彼此之间用同一种语言交流，才能形成更大的生态系统。

SOA架构的开发趋势

传统汽车使用由上百个ECU组成的分布式EE架构，OEM定义对各ECU的功能需求，由不同供应商负责最终功能实现。这种架构导致大量功能控制逻辑在子节点ECU内部完成，传感器、执行器信号被掩埋在分布网络下，仅通过在局部网络的ECU部署基于服务的通讯，无法实现对整车硬件能力的充分暴露。且考虑到基于SOA软件平台，未来SOP后的车型也需具备硬件冗余能力以应对OTA软件升级，上百个ECU的冗余设计将极大增加成本支出，也导致跨域功能OTA的实现将涉及数量众多的ECU。

随着车载芯片算力的提升和高带宽、低时延车载以太网通讯技术的落地，EE架构已从分布式演进至域集中 (Domain Centralized)，并向整车集中＋区域 (Vehicle Computer & Zonal)、整车集中 (Vehicle Centralized)不断进化。在高集成度的EE架构下，域控制器将承担整车主要逻辑，而执行器、传感器将成为纯粹的执行机构，执行控制命令或是提供环境感知数据。

基于整车集中EE架构的“硬地基”， SOA在域控制器上的部署才能够实现整车能力的资源获取，并将其封装为标准的服务和接口向应用层开放。

域控制为核心的架构

电子电气架构的概念从总线引入汽车开始就不断更新和演化，如今一套完整的整车数字架构所考虑的内容除了传统的拓扑、网络、线束与电气分配、逻辑功能分配，还需结合整车的功能/信息安全架构、数据架构、计算架构，以及实现通讯架构与软件架构的协同，功能架构与服务架构的协同，车内服务与云端服务的协同。

如图所示：域集中架构在连接上由功能域控制器，分别通过子网与各功能域内ECU相连接，而域控制器之间则修建通讯“高速公路”，通过高带宽的骨干网络相连。拓扑结构只是架构的表象，而表象背后的核心特征是功能逻辑被抽象上移至功能域控制器中。每个域控制器有对应的集成的（Signal to Services）, 在域控制器中进行功能的分配、功能的集成。而某个域控制器作为云端链接的桥梁，将平行的几个域控制器的逻辑运算功能输入到云端。功能逻辑运算服务的重心在域控制器中。

区域控制为核心的SOA架构

如图所示：整车集中和区域架构在连接上是通过分布在车内各物理区域的区域网关/控制器将车内物理I/O分别就近连接和控制，形成整车数字系统的“手”和“脚”，然后通过骨干网络与系统中的“大脑”控制单元进行连接。连接关系同样只是表象，而核心价值在于将车内软件（运算）和硬件解耦，彻底实现软件独立“生长”（或者说算力架构可以迭代，共享算力变成了可能），而硬件同样可以独立“生长”（跨车型平台，或者在车辆生命周期内为用户提供升级服务，而这些在传统架构中实现的成本是不可控的）。

以服务为核心的SOA开发思路

虽然电子电气架构开发从理论上是正向开发，但实际上一款车型的开发并不是完全从零开始的，很多功能方案会沿用老款车型。这样的后果是，系统和软件模块已经固定，即无法通过正向设计的思路拆解逻辑，设计服务。考虑这种情况，服务设计可以分为以下两种方法。

(1)自下而上的方法：

适用于现有平台上已实现的功能或系统。此种方法的基础是，功能的网络分配，通信，ECU软件架构，功能规范和使用场景等都已经有明确定义。我们可以利用现有的这些输入，完成将原有功能对SOA的转换。

适用功能和系统：

车身舒适的大部分功能，如车门，车窗，座椅，空调等，功能逻辑没有太大争议，就可以通过现有子系统规范和网络信号清单，进行服务接口设计。
动力和底盘系统 。这是整车中对安全要求最高的两个系统，因此一般来说，我们在设计第一代SOA架构时。这两个系统更适合自下而上的方法，通过对已有功能的提取，转换为服务接口，接入整车服务系统。
传感器和执行器资源 。汽车上的每个元件都代表了一种基础能力。基于整车传感器和执行器清单，能够快速形成一份基础服务清单。由此出发，再通过功能梳理，层层往上，可以形成更加丰富多层次的服务列表。