传统架构分析

先分析一下传统架构痛点，以及对比之下 SOA 架构如何解决这些痛点？

✦✦

传统架构的痛点

传统的分布式架构：汽车内部有上百个独立的 ECU，每个 ECU 控制独立的功能模块，优点是功能原理比较简单、稳定可靠，但是算力相对较低，很难去实现复杂的功能。

汽车功能增加也导致 ECU 的数量的一个急剧增加，首先就体现在了线束的一个长度和重量的增加，让线束基本位于发动机之后全车第二重的部件。

功能的增加不仅带来了线束长度和材料成本的迅猛提升，更多的是带来企业难以承受的一个协调和测试的成本。

因为不同的 ECU 它来自不同的供应商，底层软件和代码各不相同，主机厂没有权限对各个模块的 ECU 去进行维护和升级。所以让不同系统相互兼容，并且保持一定共同节奏就比较困难，一辆车大部分的开发时间都放在了协调不同供应商的产品更新和测试上。

此外通信带宽也是传统架构中的瓶颈，面向信号的通信也带来了一部分不必要的总线负载，低速的总线通信没有办法去满足不断进化的娱乐和自驾的相关需求。

传统的汽车通常不具备高度智能化的能力和功能扩展性，所以它主要的角色是在于提供代步功能的一个交通工具。

✦✦

SOA 如何解决传统架构的痛点

为了适应智能化、网联化的需求，解决传统架构开发的一个痛点，SOA 就被引荐进来了，汽车电子架构逐渐向域控制器、域融合以及中央集成不断发展，将分布式的功能逐渐上移至域控制器及中央电脑。

ECU 的数量逐步减少的同时，车内的算力也在大幅提升。

SOA 架构定义的中心思想就是实现软硬分离，通过定义标准的接口，在不同的操作系统和中间件上去实现软件的不断复用，以后的开发人员将会有更多的精力放在软件开发的分工上。同时 OTA 的实现也让软件的快速迭代变成可能。

面向服务的以太网中间件协议提供了大数据、低延时、确定性的时延的通信，开发设计人员可以根据不同的应用需求去选择合适的以太网协议。

所以在新架构下，在多种软硬件技术的支撑下，现在的汽车可以为用户去持续创造出更多的一个新价值。以上是老生常谈的一些宏观性的概念，那么具体该怎么去进行落地？

SOA 落地传统架构思路

接下来我们看一下从 SOA 设计的角度落地到传统架构，在实际应用中需要去考虑哪些关键的因素？

✦✦

域控拓扑

主机厂首先去尝试落地 SOA，通常情况下不会大刀阔斧的在一个全新的车型上开一个全新的架构，更大的可能是选择一个传统架构的车型为一个基版，保持大部分传统的以 CAN、LIN 总线为主的 ECU 不变。

然后在这一版的基础上选择几个域控制器作为切入点，将一部分功能上移到域控制器，然后功能不变的部分，由域控制器将传统 ECU 的功能以代理服务的形式对外发布。

✦✦

休眠唤醒

在休眠唤醒机制上，从硬件的角度去考虑作为域控的智能 ECU 是否需要去加以太网的一个激活线？然后是否由域控制器作为主唤醒源，从软件的角度要去考虑每个智能 ECU 是否需要上基于 AUTOSAR 以太网网络管理。如下图所示：

上述是一种采用比较保守的策略，我们首次采用域控架构，智能 ECU 没有立即取消基于 CAN 的一个总线通信，并且相关 CAN 总线上的休眠唤醒策略，是由网关最后来做统筹管理。

在这种拓扑下，智能 ECU 通过 CAN 的激活线唤醒 MCU，通过 MCU 唤醒 MPU，同样的，MPU 通过监控 MCU 是否休眠而决定自身的一个休眠时间。

在这种架构下，采用传统的 OSEK 网络管理，或者是基于 CAN 的 AUTOSAR 的网络管理，不立即去上以太网网络管理，也是可以勉强去实现整车的一个休眠唤醒的。

如果说发展到下图的架构，比如说像 ECU 它是独立的，就是取消了 CAN ，或者说它没有跟网关是一起协同进入睡眠的这种情况下，是需要去上以太网的网络管理。

✦✦

服务代理

前文也提到域控制器将部分的功能上移，部分功能由 ECU 自身去实现，部分的功能逻辑和信号报文保持不变，去定义相关的功能接口部署到智能 ECU 上。

然后由智能 ECU 向其他域控去发布该域下所能提供的信息和功能，这就涉及到了信号到服务的转化。

兼容传统已有功能方案

如何去定义代理服务呢？对于一个架构工程师来说很重要的一点，服务、服务接口、数据类型、属性、参数等定义，必须能够完全兼容传统架构。

所以需要服务设计的工程师完完全全去了解整个已有功能的方案，否则可能会导致软件开发和测试验证的过程中反反复复地迭代。

定义服务启动/失效/故障恢复的条件

另外对于域控制器来说，需要去定义代理服务启动条件的同时，也需要去监控对应CAN 总线上，比如说传统 ECU 节点是否有丢失，总线是否有 Bus Off，并在监控到上述情况之后，立即停止对外提供发布相关的代理服务，以及有一些故障恢复后的次恢复的一个处理。

不同车型服务配置识别/管理

不同车型会有高低配之分，对于代理服务的域控制器来说，这个智能 ECU 它需要去识别在不同的高中低配的车型上相关的功能是否是存在？通过去识别功能是否存在，才去决定是否去对外发布该服务。

从策略上，可以有比较多的一些策略方式，比如可以在整车上电的时候，智能 ECU通过诊断命令向各个传统 ECU 去获取诊断配置字。

但缺点是车辆上电的时间会过长，并且可能会存在总线不稳定、读取不到的现象，也可以在车辆首次下线时，直接将相关的配置信息通过售后诊断仪器写入控制器，但是后面配置字发生变更的时候，域控也需要去支持同步识别。

比如说识别 FOTA 升级或者是识别到售后诊断仪的一个恶意操作，可以通过云端下发配置去进行。对于域控制器来说，配置功能的开发实现也是一种挑战。

服务接口配置管理/通知/处理策略

前文提到不同的车型配置会导致域控，需要去识别服务上在该车型上是否存在，对于服务 Owner 去定义服务的时候，它们其实会最大化地去定义服务的服务接口，在该车型上消费方该如何去识别服务接口的高低配呢？

比如像智能网关去代理提供座椅服务，那座椅服务可能包含座椅按摩、座椅记忆、座椅调节等一系列的功能，一个最大化的服务会包含了所有子功能的服务接口。

但是对于中低配车型来说，如果说座椅按摩的功能是不存在的，那服务的提供方该如何去做识别？服务提供方该如何去通知服务的消费方？

如果服务消费方在已知服务接口不支持的情况下，仍然不按要求去进行发送请求，服务提供方该如何去做处理。

同样的，如果一个服务接口做预留，前期项目可能用不到，但后期项目需要增加，那对于开发和测试人员来说，很难直接去识别服务接口是否是实现的，需要去维护一张专门的服务接口配置的表项。

其中的类型可能会包含服务接口是否是完全预留的？服务接口是否按项目去做区分？服务接口是否按项目的高中低配去进行区分？这些表项谁来维护都需要去考虑清楚。

各时间参数约束

还有像一些时间参数的定义，比如在同步执行、或者是异步执行的情况下，请求响应的超时时间该如何去做定义？

如果最初的时候拿捏不准，比如说对于服务反馈执行结果的请求，响应的时间可以做成一个标定的数据，方便开发人员去进行时间参数的配置和调试。

✦✦

域间通信

域控制器的出现，将原有的分布式的低算力的计算资源去进行了一个集中，实现了软硬分离，实现了高算力和高带宽。

域控设计的策略上，对于已有的方案梳理并识别可以 SOA 化的功能，取消去相关的原有 CAN 总线的一个信号通信，从一定程度上是可以降低 CAN 总线的一个负载。

比如说泊车的功能，可能里面我们有一个子项需要去做车位信息的识别，比方说它需要去识别 0-12 个车位信息，每一个车位信息包含车位的标识，各个角度的坐标，是否可停的属性等信息。

如果采用传统 CAN 总线去做传输的话，需要去预留多个报文不停地去周期发送整整12 个车位信息的相关属性，哪怕没有这 12 个可用的车位，这样是非常占用负载和占资源的。

但如果说改用基于以太网 SOA 的设计的话，数据类型上就可以直接去定义一个范围是 0-12 的变长数组，根据实际的数据发送负载。

传输的类型上，在不满足条件下可以不发送，比如说低于 15 千米每小时后再周期性地发送。

所以说，对于原有的已经成熟的一个方案，可以根据实际的分析去判断是否去进行SOA 化。对于全新的方案新建的话，首选 SOA 通信。

未来如果有实时性、安全性比较高的情况下，局部通信可以去搭配，去使用行业的一些新技术，比如说 AVB 和 TSN。

✦✦

核间通信

域控制器的硬件大多数都是多芯片、多核的，所以 SOA 架构设计的方案也需要去考虑域控下的核间通信的问题。

首先，一部分的域控它可能会涉及 CAN 到以太网的一个转化，必然就会存在 MCU和 MPU 之间的核间通信。

对于代理服务的信号到服务的转化，以及服务到信号的转化，过程中间一定会涉及时间的延时，就项目的不同应用来说，对时延的长短必须是要有要求的。

如果说一个请求从以太网的总线发出，再通过 MPU 转到 MCU，再转到 CAN，传统 ECU 去做处理之后，发生 CAN 信号变化之后，再通过 MCU，再转到 MPU，再发送到消费方。中间的时延如果说来个几秒或者是十几秒，肯定是不能被接受的。

另外传统 ECU 去定义 CAN 信号的内容的时候，可能会存在很多枚举值的定义，由于传统的 ECU 会比较多，且相对独立，涉及到的需求方也势必会很多，提出的需求可能会有千姿百态。

比如说一个开关的枚举值，在空调功能上，可能 1 代表 ON 开，2 代表 OFF 关，然后换到车窗功能上，就有可能是 2 代表 ON 开，3 代表 OFF 关。同一个枚举描述在不同信号下去定义的值不一样。

但在 SOA 架构中，如果说从应用平台化的角度，可能更希望我们去建立一个数据字典，一个枚举定义只有一个值，这种方式对于后续 MPU 到 MCU 核间协议转化可能会节省较多的一个开发量，也更易于平台化。

但是对于 MCU 侧，可能需要去做一个中转，也加重了 MCU 侧的一个负担。所以方案如何抉择，可能需要基于项目应用需求去进行抉择。

另外在以太网的网络规划方案当中，会按照一定的规则，比如说基于业务流，然后对于每个智能 ECU 去进行网络参数的一个规划。

比方说 IP 地址、MAC 地址、VLAN，然后每个智能 ECU 的规划通常是基于全平台规划的，也就是说新增项目新车型，每个智能 ECU 的 IP 地址等网络参数是维持不变的。

那么一个 ECU 内，如果说有多核，服务基于不同的项目去部署到不同的核上。如果说我们在没有完全地实现一个完成的动态发布订阅，或者说服务的即插即用之前，网络架构仍然需要去维护服务的部署。

为了保证架构方案的统一，举证数据的统一，测试方案的统一，可以要求一个 ECU对外的一个以太网的接口只有一个，通信矩阵的设计、ARXML 数据库、测试环境搭建不随 ECU 内部的变化而变化。

比方说 A 车型，同一个 ECU 里面是两个核，然后到 B 车型它就变成三个核，如下图所示。但是服务的部署它可能基于不同的的车型，它服务 1 可能部署到 A 核，后面的车型有可能服务 1 它就部署到 B 核。这种情况，我们是建议对外的接口只保证一个。

从外部的角度来说，我们就可以不需要去随着 ECU 内部的变化而去改变我们当前的方案。核间服务的通信，就可以通过核间的服务代理来实现。

✦✦

车云通道

关于车云通道的规划上，在 SOA 架构应用之前就已经存在车云交互，比如说远程控制、数据上传等等，其原理是网关将 CAN 信号做协议转化，通过 HTTP 或者是自定义的 OTA 协议上下去进行传送。

那么车端 SOA 架构应用之后，为了保持车端云端统一的一个开放环境，SOA 可以从汽车域互调扩展到车云互调。

建议创建一个统一的车云服务及服务接口，包括车端服务可以通过映射或者是封装，有条件的向云端去进行开放。

✦✦

功能安全 & 信息安全

最后架构的设计，还是要去满足一定的功能安全和信息安全的一个需求。

对于功能安全，比如可以在以太网数据库中加入E2E。

对于信息安全，可以从以下方面进行考虑：

设备授权接入

黑白名单

数据认证及加密

兼容传统架构的 SOA 案例分享

✦✦

代理服务设计

下面我们选两个项目中总结的例子进行分享。

前文提到了代理服务的设计很大情况下可能会受限于传统的总线，下图举了车窗控制的一个例子，

上图中，从以太网总线左边有服务的消费方，它需要去发送车窗的一个控制，那它可能希望自己同时去调用左前左后，右前右后的一个请求。

然后发到域控制器之后，通过协议转换，转换到 CAN，通过 CAN 报文发送到车身的域控制器，车身控制器再通过 LIN 去转换，发送到车窗模块。

但是我们一次性发送前后左右的接口，发现再到 LIN 网段之后，LIN 有一个标志位，其中一个标志位它是代表前或者是后；另外一个标志位代表的是左或者是右，这就意味着在同一个 LIN 的周期内，我们要么选择前或者是后，要么选择左或者是右。

就相当于我们可能只有左前左后，右前右后，只能去执行一个接口的定义，这个可能是对于传统总线来说，那它原来几年前它就已经定好了策略，是没有办法去适应我们现在当前的一个服务接口的定义的。

而这种定义在传统的总线上的例子会非常得多，比如说像座椅的功能，那我们原先去定义座椅的一个控制传到 CAN 上，CAN 总线的定义有可能是我们位置的定义是一个 CAN 信号。

另外一个 CAN 信号，它通过枚举去定义我们是去进行腿托的还是腰托的，还是头枕的定义。所以就只能决定了我们当前同一个情况下，只能够去对同一个行为进行操作，不能够同时去执行多个行为。

从方案设计的角度，不能够通过像结构体的这种形式把同一个报文去发送到网关，然后去做一个 CAN 的转换，它没办法去同时执行多个操作。

从根源的角度，我们肯定是需要去改 CAN 或者是改 LIN，但是如果我们没办法去改动传统的 CAN、LIN 的一个总线的设计，就只能够从设计的角度去做一些规避。

✦✦

核间通信时延要求

第二个例子就是前文提到的关于核间通信延时的一个要求。

从以太网报文发出请求，再到处理之后的状态通知，中间的时延可能已经差到了毫秒级别，这可能是由于 MCU 和 MPU 之间的一个通信策略并不是一个实时通信的。举例如下图所示：

上图中，MPU 到 MCU 之间可能是通过 50 毫秒的周期去做一个同步，然后MCU 到 MPU 这边，是通过 1000 毫秒的周期去进行同步。

在 MCU 侧的这个数据，它并不是实时发送的，那可能就会出现一个问题，比方说我们去做氛围灯，它是 200 毫秒的一个状态反馈，那我们的请求是以200 毫秒的时间间隔去进行灯颜色的一个控制。

但是 MCU 这边去到 MPU 同步的时候是 1000 毫秒的周期同步，那我们 200 毫秒的周期去发送控制请求，但它是做状态反馈的时候，我们是没办法以 200 毫秒的周期去做状态的一个反馈。

原先的红、橙、黄、绿、蓝的控制，实际上最多可能只到了红和蓝这两种颜色，那作为人眼的一个肉眼识别差，可能在 600 毫秒之外，我们就会识别到有一个延迟和顿挫。

所以通过去调整 MCU 和 MPU 的一个同步时间，可能会去优化我们当前时间延时的一个要求。但是这个时间怎么去定义？如何定义会比较合理？如果时间太长，那延时要求肯定是不满足项目要求的。

但如果说时间太短的话，对于 MCU 侧它的要求和负载也会比较高，也有可能会造成一定程度的丢包，或者是负载过高会导致 MCU 的一些异常。所以整个时间的要求还需要通过项目不断地验证，去得到最优的一个时间。

新架构SOA如何规划

前文我们主要是探讨初步落地 SOA 我们应该如何去着手？但是 SOA 架构的发展，从域控制器到域融合到中央架构加域控加云计算这样一个超级计算架构，未来摸索的路还很长。

SOA 未来的架构会日趋成熟，从架构发展的趋势可以看出，众多主机厂在推行HPC+ZONE 的架构方式，未来的架构重点也是在于高算力、高带宽、软硬解耦和复用，如下图所示：

所以未来行业局势格局的竞争不再是硬件分化和迭代，而在于软件的集中化、软件的分工协作以及软件的自主掌控上。