「软件定义汽车」时代下的SOA架构设计 — Step by Step！

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

为什么这么火？

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

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

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

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

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

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

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

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

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

现在新的问题来了：「软件定义汽车」和「SOA」（Service Oriented Architecture）有何必然联系？

对此，AUTOSAR标准给出的解释是这样的：

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

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

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

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

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

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

结合SOA的各种特性回到本段最初的问题「软件定义汽车」的过程和「SOA」（Service Oriented Architecture）有何必然联系？

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

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

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

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

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

那么到底什么是服务（Service）呢？

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

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

• 代表功能单元（Represents functional unit）

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

• 是无状态的 （stateless）

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

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

• 可重用性（reusability）

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

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

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

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

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

有了上面的软件架构，接下来我们需要来定义具体的服务接口（Service Interface），具体定义见图 2‑4

服务接口可分为以下三种类型：

• 方法（Method）：

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

• 属性（Property）：

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

• 事件（Event）：

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

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

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

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

➡  映射到Machine上的AP SWC

➡  映射到ECU上的CP SWC

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

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

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

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

而右边则是到CP SWC接口的映射，因为CP SWC不提供服务接口。为此需要使用CP中现有的接口对服务接口的三种类型（图 2‑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接口

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

当然，整个的设计过程当中会有很多细节需要更深入的研究，另外怎么保证实际的运行效果能够达到预期值（性能，资源消耗），或者说怎么对设计进行验证（比如服务相关性的测试），都是工程师们所要面对的实际问题。

如果你也对此类的内容的专业探讨感兴趣，欢迎留言或者添加作者微信做进一步讨论。

[1] AUTOSAR, “Explanation of Adaptive Platform Design AUTOSAR AP R20-11,” 2020.

[2] AUTOSAR, “Methodology for Adaptive Platform AUTOSAR AP R20-11,” 2020.

[3] Vector Informatik , “Service Oriented Architecture and Ethernet design,” 2019.

[4] Vector Informatik, “AUTOSAR Adaptive: Modeling of Service-Oriented Architectures,” 2020.

[5] AUTOSAR, “Specification of Manifest AUTOSAR AP R19-11,” 2019.

⚠️ 本文仅在「几何四驱」平台独家首发，未经「作者本人」或「几何四驱」授权，不得进行商业性转载。