“软件定义汽车” 时代下的SOA架构设计

文 赵玉龙

“软件定义汽车”，这可能是在当今智能网联的“风口”下，被“炒”得最火的一个概念了。

一、从“软件定义汽车”到SOA

“软件定义汽车”，这可能是在当今智能网联的“风口”下，被“炒”得最火的一个概念了。

为什么这么火？

我个人觉得无外乎以下几个原因：

首先，在以内燃机为核心的传统汽车被新能源智能汽车颠覆的趋势下，软件在产业价值链和商业模式中的重要性越来越大。以前车厂卖车，商业模式是“一锤子买卖”，从硬件到软件，成本和利润全部都“打包”在车价里。车辆被消费者购买之后，车辆就不再为整车厂创造新的利润。

而现在呢？拥有智能网联功能的汽车被卖给最终客户以后，整车厂仍然可以通过OTA（Over-the-Air，空中下载）技术的形式对车内软件和固件进行更新、升级，甚至添加新的应用。这样一来，只要汽车没有报废，消费者就可以通过OTA源源不断地获得更多新的“功能体验”，比如ADAS系统从L2升级到L2.5后获得更加成熟的自动驾驶体验，电源管理系统（BMS）升级后获得大幅提升的续航里程等等。

但是，天下没有免费的午餐！所有新的驾驶体验、功能体验和性能升级都是需要消费者额外购买订阅的！这种全新的商业模式最早由特斯拉推出，如今已经越来越多地被其他整车厂效仿和采用。

至此，整车厂的盈利模式就由以前的“一锤子买卖”变成了现在的“摇钱树”模式，照此发展下去，传统的4S店都有可能被慢慢取代。以前一些必须送修的故障或者返厂升级的服务（Service）工作，现在通过OTA就可以轻松解决了。

或许会有朋友不同意以上的说法，但是单单从进化趋势来讲，我认为：未来的智能网联汽车，本质上，或许真的就只是一台装着4个轮子的高性能计算机。

其次，随着车联网、信息娱乐系统以及ADAS系统的不断发展壮大，车内控制器的复杂程度将越来越高，其所属的软件代码的行数将呈指数级增长。相对应的软件研发费用在整车研发费用中的比例也将大幅增加。

三十年河东，三十年河西，各大车企以及供应商的硬件研发团队或将面临严峻挑战，随之而来的是软件团队的不断发展扩大。所有跟车内软件开发相关的职位（嵌入式软件开发，Linux内核开发，功能算法开发等等）的薪资都将水涨船高，人才市场上的竞争不可谓不激烈。在未来高收入程序员的队伍中或将多出一类新人——汽车软件工程师！

从技术层面来分析，倘若我们把智能汽车内的系统复杂程度的提高看作“因”，那么“软件定义汽车”就是自然而然会产生的“果”。这个因果关系明了了，对我们这些开发人员来说，总的“指导思想”就算树立好了！

现在新的问题来了：“软件定义汽车”和SOA（Service Oriented Architecture，面向服务架构）有何必然联系？

对此，AUTOSAR（Automotive Open System Architecture，汽车开放系统架构）标准给出的解释是这样的：

“为了支持复杂的应用程序，同时在处理分布和计算资源分配方面提供最大的灵活性和可扩展性，AP（Adaptive Platform，自适应平台） 应遵循面向服务的体系结构 （SOA）。

SOA基于这样一个概念：系统由一组服务组成，其中一个服务可以依次使用另一个服务，以及根据需要使用一个或多个服务的应用程序。SOA 通常表现出系统间系统的特性，AP 也具有这种特性。例如，一个服务可能驻留在一个应用程序运行的本地 ECU （Electronic Control Unit，电子控制单元，又称“行车电脑”）上，或者驻留在一个远程 ECU 上，该 ECU 也在运行另一个 AP 实例。两种情况下的应用程序代码是相同的——通信基础设施将处理提供透明通信产生的差异。看待这种架构的另一种方式是分布式计算，通过某种形式的消息传递进行通信。总的来说，所有这些都代表相同的概念。这种基于消息传递、基于通信的架构也可以从快速和高带宽通信（例如以太网）的兴起中受益。”

这段话强调了SOA架构的灵活性和可扩展性，而这个恰恰与“软件定义汽车”的思路不谋而合。通过采用SOA架构，虽然可以更好地支持车控软件的分布式部署与更新迭代，但是这在基于信号的通信架构（Signal-oriented Communication Architecture）下是不太可能实现的，至少是十分困难的。

这时候有人可能会有疑问：“特斯拉就没有使用SOA，不照样可以通过OTA进行迭代升级？”

其实，实现OTA，并不需要SOA。

别说特斯拉用的是基于Linux的操作系统了，就是在跑CP（Classic Platform，经典平台）的MCU（MicroController Unit，微控制单元）上也可以实现OTA，只是具体方法有所不同。

在SOA架构下，OTA的实现更加方便灵活，最主要的一个优势是可以实现软硬解耦，服务实体可以部署在任意的域控制器上，而且可以在出厂后进行部署策略的调整。

这个优势衍生出SOA在汽车功能安全方面的另外一个先天优势——冗余。例如，对于安全性要求比较高的功能可以进行冗余部署，比如刹车控制服务、转向控制服务可以被同时部署在两个域控制器上，如果一个域控制器失效，那么另外一个域控制器上的备用服务实例立刻启动，重新与服务使用者建立连接，以保证正常功能的运转，借此实现冗余机制。

当然，怎么在实时运行环境下保证这一套动作的快速完成（两次Service Discovery的完成，一次在开机初始化阶段，一次在默认服务实例失效时），需要在具体实现的过程中做更深入的研究。

结合SOA的各种特性回到本段最初的问题“软件定义汽车”的过程和SOA有何必然联系？

我的答案是：“不一定，但是SOA肯定是可行的解决方案之一”。

说了这么多，下面咱们模拟做一个SOA架构设计，来看看从头至尾都需要完成哪些具体的工作。

二、SOA的设计流程

AUTOSAR标准中定义了AP的开发流程示范，其中也包含SOA相关的开发步骤。（见图1）

图1 AP的开发流程示范图

大体上，AP的开发是一个“从上至下”的流程，其中跟SOA设计相关的有以下几个重要步骤：

（一）服务定义（Define Services）

从整车层面按照功能需求定义并划分服务。

那么到底什么是服务呢？

IEEE对服务的定义如下：服务是一个独立的功能单元，可以远程访问和独立更改或更新。

服务一般应具有如下特性：

●代表功能单元（represents functional unit）

●是自我包含的（self-contained）

●是无状态的 （stateless）

●使用标准接口进行通讯（uses standardized interfaces to communicate）

●对外是一个黑盒子（black box for consumers）

●可重用性（reusability）

●可以由下层服务组成（can consist of underlying services）

此步骤实际上就是搭建了一个系统功能架构。

（二）服务接口描述（Service Interface Description）

本质上就是想办法从功能架构过渡到软件技术架构并对服务接口进行定义。如果是同时包含CP和AP的架构，还需要定义从CP SWC（CP Software Component）接口到服务接口的映射。

如图2所示：不论是从哪种视角，软件模块之间的相互关系都需要表示出来。对于SOA来说，需要定义清楚服务之间的相互关系，也称为服务编排（Service Orchestration）。下面我们来具体举例说明。

图2 定义软件技术架构

图3为我们展示了一个简单的关于获取天气信息的例子：Test作为服务消费者（Service Consumer）想获取当前位置的天气，只需要申请使用服务提供者（Service Provider）WheatherControlService提供的服务。这个例子依存于两个基础的服务，一个是MapService，另一个是WeatherService。它需要通过服务接口申请使用这两个服务。

图3 获取天气信息的服务编排

有了上面的软件架构，接下来我们需要定义具体的服务接口（Service Interface），具体定义见图4。服务接口可分为以下三种类型：

图4 服务接口定义

方法（Method）

在服务消费者要求下的一个由服务提供者执行的函数。

属性（Property）

由服务提供者管理的数据，对消费者可见，可以通过get/set方法操作，并且可以在有变动的情况下收到通知。

事件（Event）

表示一块数据的更新。服务提供者决定何时发送此更新给一个或多个服务消费者。

可以看出，这里对服务接口的定义是完全抽象的，跟通信协议无关，任何两个服务之间都可以使用此接口进行通信。而使用合适的工具链可以生成基于特定协议的接口，比如web service，AA（Adaptive Application）接口或者CP SWC接口。

有了服务及其接口的定义，接下来就可以交给软件开发人员进行开发了。通过软件集成生成软件包（Software Package），它包含可执行文件（Executable File），执行清单（Execution Manifest）和服务实例清单（Service Instance Manifest）。最后这个服务实例清单是通过定义与配置服务实例生成，也是我们下面要重点说明的一个步骤。

（三）定义与配置服务实例（Define and Configure Service Instances）

对服务进行部署，也就是建立服务实例到机器（AP）或者ECU（CP）的映射（软件/硬件之间的映射），此步骤会生成服务实例清单。

图5为我们展示了映射服务接口的两种类型：

图5 服务实例的映射

●映射到Machine上的AP SWC

●映射到ECU上的CP SWC

其中，一个SWC对应服务编排中的一个服务提供者或者服务消费者。

需要注意的是，AP和CP支持的软件接口是不一样：AP支持服务接口，所以之前定义的服务接口可以1比1地拿过来用。而CP不支持服务接口，所以这里需要一个接口之间的映射。

图6展示的是从抽象的接口定义到具体的软件层面接口的映射。

图6 软件接口之间的映射

左边是1比1的到AP SWC接口的映射（或者说实例化），因为AP SWC本来就支持服务接口。

而右边是到CP SWC接口的映射，因为CP SWC不提供服务接口。为此需要使用CP中现有的接口对服务接口的三种类型（图4）分别进行描述：

方法（Method）

●对于带参数的Method可以使用Client-Server接口

●对于带自变量的Fire&Forget Method可以使用Sender-Receiver接口

●对于无参数的Fire&Forget Method可以使用Trigger接口

属性（Property）

●对于Get/Set操作（对property的读写）可以使用Client-Server接口

●对于notifier（由于property改变而触发的事件）可以使用Sender-Receiver接口

事件（Event）

触发事件，可以使用Sender-Receiver接口

至此我们完成了从抽象的服务定义到软件层面的推导。接下来是通信协议层面的设计。

图7展示了AP下SOA架构的整个设计流程。从服务定义到服务实例化，我们在前面都解释过了。最后一步就是红框标出的部分，以太网通信设计。

图7 通信设计

以太网通信设计主要是对服务实例进行相关的通信协议层面的配置，包括VLAN，Switch，Socket，SOME/IP，SD等。配置完成之后可以生成Arxml文件。

这一步的输出是服务实例清单，也是前面提到的软件包的一部分。

三、混合系统的SOA设计

前面我们着重向大家讲解了纯AP以及纯CP系统的SOA设计流程，但是实际工作中，还有一种更常见的，是AP与CP共存的混合系统，这里我觉得有必要为大家简单说明一下此类情况下的SOA设计要点。

在图8中我们可以看到：在这个拓扑结构中，有两个AP Machine（绿色）和三个CP ECU（淡蓝色）节点。而在ServerMachine上又同时存在AP，CP还有android系统。

图8 混合系统示例

整个网络拓扑可以分成上下两个Cluster：上面的Cluster使用基于信号的传输协议，下面的Cluster使用面向服务的传输协议。

这导致我们需要在中间这个ServerMachine上实现一个从信号到服务的转换（signal to service translation）。

在图9中，AP上的黑色模块就是用来实现此转换的。

图9 信号到服务的转换

转换完成以后得到的服务实例就可以被AA（Adaptive Application）通过ara ::com API直接使用了。

图10描述的混合系统的设计流程与前面的AP的设计流程大同小异。除了需要同时完成AP和CP的几个类似的步骤之外，最主要的区别是多了中间Software Connection环节。

图10 混合系统的设计流程

Software Connection实现了AP服务接口与CP SWC接口的映射。

图11中按照服务接口的不同类型使用CP现有的各种接口进行一个转换。Vector的工具链中直接提供了一个接口转换器（Port Adapter）来实现AP与CP SWC的互联。

图11 AP与CP的软件连接

接下来的工作和前面一样，我们需要把软件模块映射到硬件上：CP SWC到ECU上，AP SWC到Machine上。

流程设计的最后步骤，就是对通信协议层面的配置，根据通信方式的不同，生成基于信号的通信路径或者面向服务的通信路径。

四、结语

以上就是我所理解的SOA架构设计的大概流程。

总体来讲，SOA设计是一个从上至下的过程，可以说是比较直接（straightforward）。

从需求分析出发，导出服务定义，然后进行服务编排，定义服务接口，最后是软件到硬件的映射以及对通信协议的配置。

当然，整个设计过程当中有很多细节需要更深入的研究。另外，怎么保证实际的运行效果能够达到预期值（性能，资源消耗），或者说怎么对设计进行验证（比如服务相关性的测试），都是工程师们所要面对的实际问题。（作者系“几何四驱”专栏作者。国内智能汽车增量部件供应商解决方案架构师、曾在ADAS、中央网关、车载计算平台等多个业内前沿的研发项目中负责软件架构设计。）