汽车 芯片 sop（上汽零束SOA电子电器架构知识汇总）

整理了上汽零束的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架构时。这两个系统更适合自下而上的方法，通过对已有功能的提取，转换为服务接口，接入整车服务系统。
• 传感器和执行器资源。汽车上的每个元件都代表了一种基础能力。基于整车传感器和执行器清单，能够快速形成一份基础服务清单。由此出发，再通过功能梳理，层层往上，可以形成更加丰富多层次的服务列表。

(2)自上而下的方法：

自上而下的方法即为正向设计方法。在基于SOA的电子电气架构开发中，对于复杂功能，或者引入到平台中的新功能和新系统，必须遵循这种方法完成服务设计。基于上述所介绍的开发流程，从需求出发，进行逻辑拆解，服务拆解，软件架构搭建，系统设计等。这个方法所依赖的输入一般是功能需求表和用户场景。

不管使用哪种方法，通常服务的设计是在单个功能或系统级别定义的，最后需要架构师综合考虑整车系统，将高度复用性的服务归类为平台级通用服务。通用服务池子是“生态共创”的基础。

服务的分类

(1)硬件抽象服务

根据ECU的功能和硬件外围设备（传感器和执行器），定义硬件抽象服务。这些服务同时属于平台级核心服务。

示例：Camera interface，Rain sensor interface

(2)平台级核心服务

在应用程序集群和域之间通用的所有服务。

示例：Power mode，Vehicle speed，Key status

(3)域级核心服务

在域内的应用程序集群内不同应用程序之间通用的服务。

示例：Front vehicle distance calculate，Front obstacles

(4)应用服务

为每个特定的应用程序或系统功能服务的服务。

示例：Enable ACC，AEB system status

服务设计的输入要求

(1)应用级别的服务

• 功能和系统描述，用户场景描述
• 功能和系统需求
• 功能和系统逻辑架构

(2)平台级别的服务

• 跨域的系统设计文档
• 跨域的功能清单
• 网络拓扑
• 传感器和执行器列表（用于提取硬件抽象服务）

因此，服务设计的输出主要为

(1)服务的定义

(2)服务接口的定义

(3)服务提供方和消费方信息

(4)软件模块信息

对应的输出文档可以分为

(1)服务定义矩阵

(2)服务详细设计文档（包含软件实现信息）

(3)服务数据库ARXML（涵盖通讯、服务、软件部署等信息）

SOA的软件架构

SOA服务分为基础服务、扩展服务、应用服务。SOA软件架构还有另外一些特性：高内聚、低耦合、服务平台无关化、服务动态部署/动态发现。所以，将基于SOA架构的操作系统分成如下层级，已实现完整意义上的SOA软件架构。

1）OS AL层：屏蔽操作系统对SOA架构的影响

2）SOA Framework层：提供基于SOA架构的服务设计所需的所有基础组件

3）SOA Platform层：提供通用化的SOA服务，提高功能的复用率，共包含2个子块：a）基础服务层：可独立运行，无外部依赖的服务；b）扩展服务层：使用基础服务，进行横向组合扩展，实现复杂功能逻辑的服务

4）外部服务层：根据项目需求，使用其他域控制器或云端提供的服务接口，实现“云管端一体化SOA软件平台”

5）应用服务层：基于SOA Framework和SOA Platform提供的能力支撑，根据需求定制的逻辑业务功能。

6）应用层适配接口层：将SOA服务与应用层隔离开，转化SOA服务接口为不同系统的native开发语言，加速应用层开发效率，使应用层与SOA服务层隔离。

7）Cloud Service层：基于SOA软件架构，通过车云一体化软件组件实现车端—云端服务对等且位置无关化。

以ESB为通讯的连接方式

SOA软件架构有个显著的特征，即服务中心化思想。服务之间的所有连接，均需通过ESB总线通讯。ESB总线名称上是通讯总线，但我们认为，应该把ESB称之为SOA服务中间件更恰当，ESB总线实现了以下几个特征：

a）所有服务间禁止任何形式的直接连接，唯一许可的通信方式，就是通过网络调用服务接口。

b）网络调用的具体实现方式不做强制要求，可根据不同系统的特性选择最优解决方案，目前支持Http、Binder、ZMQ、VIWI等，但均需支持以下能力：同步请求、异步请求、订阅、发布。

c）服务接口设计以可公开作为设计导向，即，所有的服务接口，必须是可以对外部人员开发的，没有例外。

d）车云一体化软件组件

e）实现车端—云端服务对等且位置无关化

f）并针对不同车型配置，实现个性化配置管理及相应的服务管理

,