近年来，汽车“新四化”（智能化、网联化、电动化、共享化）的快速推进，给汽车行业带来了新的技术变革，汽车的功能变得越来越复杂，尤其是智能座舱、智能驾驶、智能底盘的出现，促使汽车电子电气架构也相应地发生变革。
随着汽车智能化发展、汽车功能的增加，汽车上的电子控制单元（Electronic Control Unit，ECU）也越来越多，每个ECU的信号都必须在设计时进行静态规划和路由，为了应对这种增长带来的挑战，汽车行业正在采用1种新的架构，即面向服务的体系架构（Service-Oriented Architecture,SOA）。
SOA简介
SOA是从遵循服务导向原则的可重用服务中构建复杂软件系统的方法。SOA也是1个组件模型，它将应用程序的不同功能单元（称为服务），通过这些服务之间定义良好的接口和契约联系起来。接口采用中立的方式进行定义，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务以1种统一和通用的方式进行交互。
SOA可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中因软件代理交互而产生的人为依赖性。
SOA的特点是松耦合性、路径透明、可复用性、一定的标准化，不涉及底层编程接口和通讯模型。
SOA在IT行业中已经使用了多年，旨在描述和构建分布式系统。同时，面向服务的设计在汽车工业中也变得极为重要。
传统汽车通讯是基于信号的通讯方式，即信息发送者不关心谁接收而只负责将信号发送出去，接收者也不关心是谁发送的，而只负责接收信号，这种方式适用于有限大小控制数据的应用场景。
SOA代码灵活性强，支持请求/响应模式，支持复杂的数据模型，可扩展性强，能够满足自动驾驶等应用场景下，大量数据的动态交互，可以对系统进行部分更新，如图1所示。
图1 面向信号与面向服务对比
汽车领域采用SOA的优势是能加快车辆与互联网的互联互通。比如，能够将各种新功能灵活地与互联网集成；能够实现更高效的车载自动诊断系统OBD（On Board Diagnostics，OBD）及空中下载技术（Over-The-Air Technology，OTA）软件升级，有助于实现各种远程诊断、预诊断功能；能够大幅提升影音娱乐功能的用户体验，能够实现不同平台间的各种App共享功能；更便于实现平台架构升级；同时各个服务可以由不同团队独立开发，可以缩短车辆开发的时间。
SOA主要模块及功能
Wonseon和Seung设计了端到端的SOA，如图2。
图2 端到端面向服务的架构
在传统的车载网络中：
（1）许多ECU是基于CAN等旧式IVN进行工作。
（2）大量的车辆信息和功能也来自旧式IVN。
（3）基于以太网的ECU上的新应用程序应可以访问这些信息/功能。
在本架构中，主要的功能模块有SOA适配器（SOA Adaptor），SOA网关（G/W），SD代理（SD Proxy）和服务路由（Service Router）。下面将介绍各个模块的功能。
SOA适配器
（1）将信息/功能从旧式IVN转换为“服务”，任何基于以太网的ECU上的应用程序都可以轻松访问。
（2）在以太网方面，服务是在SOME/IP协议之上提供的。
（3）可以在旧版IVN和基于以太网的IVN之间的“桥接ECU”上实现，例如域控制单元，区域控制器等。也可以仅在具有以太网接口的非桥接ECU上实现。
（4）SOA适配器提供的服务可以动态更改。
（1）处理与外部设备/网络互通相关的问题。
（2）必要时转换协议并翻译。
（3）缓存外部信息以处理外部网络的可用性和成本问题。
（4）应用策略并执行服务级别的访问控制。
（5）应该在具有外部连接的ECU上实施。
（1）可以使用SD代理实现集中式SD。通过1个称为“SD代理”的中央模块交换服务发现消息。SOME/IP-SD消息也可用于ECU与SD代理之间的通信。
（2）分布式SD方法的安全和流量问题可以由集中式SD处理。每个服务只能由允许的ECU查找和订阅。可以有效地监视服务可用性和搜索/订阅尝试。
可以使用服务路由器来处理来自SOA分布式性质的问题。服务只能通过服务路由器来使用。服务路由可以应用于选定的服务。SD代理可用于高效的服务路由实施，安全和资源问题可以得到有效处理，可以基于域、ECU、服务甚至方法来控制服务访问，策略也可以动态应用。
SOA是汽车以太网和IP带来的汽车系统/软件体系架构的创新，其概念可以扩展到从传统ECU到外部设备的端到端范围。SOA适配器和SOA网关可以分别用于旧设备和外部设备。通过使用其他SOA实体可以有效地管理SOA。端到端SOA支持快速高效地部署各种互联汽车服务。
刘佳熙等在面向服务架构汽车软件开发方法和实践中，提出SOA汽车软件的分成模型，如图3示。
图3 SOA汽车分层模型
该模型主要包括3个层级：元服务、基础服务和应用服务，通过不同的服务层级来分别对应不同层级的汽车业务逻辑。
元服务是最小单元。包括汽车的传感器和执行器等的基本接口。基础服务是中间层服务，在利用元服务的基础上，可自定义汽车业务模块，比如利用自车状态服务和雷达传感器等服务，组合出环境信息融合的服务。应用服务是最顶层的服务，可以访问和调用基础服务以帮助其解决业务问题。
在设计中，上层服务调用下层服务，下层服务不调用上层服务，这一原则有助于构建清晰简单的SOA汽车软件架构。宝马公司在新一代的E/E架构中引入了SOA的方法，如图4所示。SOA为整个系统提供大量的抽象服务。严格的封装和层次结构允许针对接口和使用敏捷方法进行测试，并且它们降低了系统复杂性。在各代汽车之间重用软件组件将变得更加简单。
图4 BMW下一代E/E架构
大众MEB平台车载应用服务架构（In-Car Appli⁃cation-Server,ICAS），采用了1种可升级的新方法，如图5所示。采用集中式功能与应用程序软件和I/O功能分离的架构，来降低整体系统复杂性和应用程序之间的依赖性，同时可以高效快速地开发客户功能，提供一些客户职能所需的基本服务，并且利用面向服务的通信。
图5 大众MEB平台车载应用服务架构升级方法示例
在该架构中还强调，SOA是数字化的关键，如图6所示，该架构的优点如下：
图6 面向服务通信架构
（1）采用面向服务的通信；
（2）使用服务发现和发布/订阅进行动态绑定；
（3）数据表示主要基于REST（表述性状态传递）过渡到统一接口、无状态、关注点分离；
（4）接口的向前和向后兼容性。
最后，通过提高可更新性、可升级性、重用能力和便携性，使大众汽车可以实现各种功能。
在AUTOSAR自适应平台（Adaptive Platform，AP）设计中，为了支持复杂的应用程序，同时在处理分布和计算资源分配方面允许最大的灵活性和可扩展性，AP遵循了面向服务的体系结构理念。
SOA通常具有AP所具有的系统间特性。例如，服务可以驻留在应用程序运行的本地ECU上，也可以位于远程ECU上，该远程ECU也在运行另一个AP例。
上汽组建“零束”软件子公司，聚焦基于SOA技术的智能驾驶系统工程，同时推出“Z-ONE”的SOA开放平台，致力于打造上汽SOA的软件生态。该平台是以SOA理念打造整车功能，将汽车各个功能模块化。同时可以让第3方开发者甚至是普通用户参与到软件功能的打造。
威马汽车在2021年4月交付的威马W6汽车，率先推出了车辆自定义场景编程功能，实现25种能力、自定义场景超100个、手机端与车机端的同步，未来将携手用户及开发者，打开“千人千面”的全新格局。
Andreas等开发面向服务的车用应用程序，并使用空中软件更新部署它。主要流程如图7所示。
图7 汽车的SOA开发流程
研究背景如下：在巴塞罗那举行的2019年世界移动通信大会上，梅赛德斯·奔驰展示了1款经过改装的车辆，可与开源SuperTuxKart游戏一起用作沉浸式游戏系统。游戏是使用真实的方向盘控制游戏中的车辆，空调模拟虚拟赛车的气流、温度效果。
Andreas假设车辆类型的制造商现在想要开发这样的游戏系统并将其部署到车辆上，可作为车主购买的可选更新，其开发流程如下。
首先，进行需求分析，具体过程如下：
（1）主机将显示1个赛车视频游戏。声音应来自车载音响系统。
（2）游戏中的效果应由实车反映，例如：空调应根据游戏中的场景（即驶过火山）和虚拟车的速度调节气流和温度。游戏中的撞车事故应通过可逆安全带拉紧器告知用户。电动座椅调节器和按摩器可产生更多的触觉效果。在虚拟比赛开始时，车内的环境照明应用作交通信号灯。
（3）虚拟车辆的水平动力学应根据当前方向盘角度得出。
（4）虚拟车辆的速度应从油门踏板和制动踏板得出。
（5）中指定的效果体验应与视频游戏中显示的情况相匹配。
（6）游戏的最小帧速率应为30 fps。
（7）效果的延迟应等于或小于1帧持续时间（最小帧频）。
还存在一些非功能性需求：
（1）此功能应部署在现有汽车上，无需对硬件进行任何修改。
（2）该功能不得损害机动车的安全。
（3）只有在车辆周围环境允许安全操作时，该功能才有效。
起草软件和系统架构
根据起草软件和系统架构，构建面向服务的部分。
在“SuperTuxKart”应用程序的需求定义完成后，起草它的软件和系统架构。本样例中关注需求第2～4步，为此一共设计了3个步骤。
分解
实现“SuperTuxKart”应用程序的必要组件在某种程度上遵循面向服务、面向信号的方法。
面向服务的部分：在这部分中，“Super-TuxKart”应用程序被描述为1个服务消费者组件（客户端）。消费的服务是喷油嘴服务（Nozzle）和转向/踏板状态服务（Steering/Pedal status）。其中，转向/踏板状态服务接口目的是定期接收踏板和转向角的状态，为“Super⁃TuxKart”应用程序提供施加的踏板压力和转向角；喷油嘴服务接口目的是实现对油泵执行器的控制，“Su⁃perTuxKart”应用程序根据游戏中的场景和虚拟车辆的速度以所需的喷嘴效果强度刺激界面。如图8所示。
图8 面向服务部分的架构
面向信号的部分：软件架构的某些部分不会由服务接口实现，而是由经典的面向信号的方法。通常考虑与传感器和执行器密切相关的软件功能。对于该应用，必要的传感器是踏板和转向装置。执行器则是由喷油嘴表示。为了将3个组件集成到我们的软件架构草案中，引入了图9中的信号接口。传感器踏板和转向装置为转向/踏板状态服务提供接口；执行器喷油嘴为喷油嘴服务提供接口（图9）。
图9 信号接口
部署
接下来，用适合的网络技术部署软件架构。考虑3个通信网络，包括：以太网，底盘/动力总成网络，LIN网络。
（1）第1个网络是以太网拓扑。3个ECU通过1个中央以太网交换机互连。ECU 1是中央计算平台。在ECU 1上，部署“SuperTuxKart”应用程序。对于踏板/转向服务，底盘/传动系统域的域控制器ECU2作为部署目标给出。以类似的方式，车身域的域控制器ECU3作为部署喷油嘴服务的目标。
（2）第2个底盘/传动系统网络：该网络描述两种基于CAN和FlexRay协议的系统总线拓扑结构连接到底盘/传动系统域的域控制器。。
（3）第3个网络描述了基于LIN协议的系统总线拓扑。在此网络中，专注于油泵执行器，该执行器部署在专用的LIN组件上，并由喷油嘴服务控制。混合通信如图10所示。
图10 网络混合通信
网络通信
“Super-TuxKart”应用程序所需的网络通信是以太网拓扑中面向服务的通信与CAN、FlexRay和LIN系统总线拓扑中的经典面向信号的通信相结合。
应用程序的开发阶段主要有3部分。
构建基础组件
SOA中的主要基础组件是API存储库，它是1个中央数据库，包含详细的有关服务及其功能和接口的信息。可以部署到车辆内计算平台的应用程序可以使用这些服务为客户提供额外的功能。
现有服务的使用
一旦应用程序确定了它的需求，它将通过API存储库并尝试找到可以满足所有要求的服务。理想情况下，存储库中的服务可以满足所有要求。在这种情况下，应用程序可以使用API存储库提供的接口描述来设计软件。由于面向服务架构的解耦性质，不需要对域控制器或它们背后的ECU进行修改。在“SuperTuxKart”示例中，应用程序设计将根据需求调整空调的气流，并在API中寻找合适的服务存储库。他们会找到喷油嘴服务并集成此服务接口到应用程序中。
创建新服务
当API存储库中的服务不能满足应用程序的需求时，需要联系API的创建者来进行更新API存储库，以满足开放的要求。由于这个扩展过程大大减慢了新应用程序的设计，因此API存储库设计时应提供尽可能多的功能。
要通过空中更新汽车嵌入式系统的软件，需要2部分：一部分由汽车制造商维护服务器，用于管理更新程序包；另一个负责接收，验证和分发更新程序的客户端，将文件更新到相应的ECU。
更新客户端功能通常在车辆的中央网关平台上实现，该平台可直接访问主机并代表通信总线之间的中央通信点。下载的更新包括1个或多个交叉编译的二进制文件，准备在相应的ECU中进行刷新。中央网关的更新功能（或服务）负责检查更新包，并将二进制文件分发到目标ECU。
该研究表明，使用现有服务可以较少的协调并提高开发速度。如果任何应用程序始终都可以使用现有服务，则可能会带来安全方面的挑战（即访问行驶中的车辆的主动悬架系统）。因此，有必要对汽车SOA的访问控制管理进行研究。
“分析和设计面向服务的架构”，“实现和部署面向服务的软件”是有效开发SOA汽车软件的关键环节。
为了实现汽车智能驾驶，通用高性能计算平台是未来新型E/E架构的硬件基础，而SOA则是“软件定义汽车”的软件基础。通过SOA平台，实现软硬件解耦、终端用户、汽车厂家及第3方开发者携手共建跨品牌、跨平台、跨车型的软件开发能力，打造以用户体验为核心，各方开发者共同参与、合作共赢的智能汽车生态。
在此生态里，汽车企业将不只是生产制造汽车，还将成为移动出行的服务供应商，能够面向用户提供多种多样的软件服务。SOA软件平台上多方的协同合作，将为软件汽车的不断进化和用户体验的不断提升提供源源不绝的动力。
未来，车主可以根据乘员数量、道路情况、目的地甚至自己心情等不同条件，在车机及移动端APP上下载配置不同的功能，满足个性化需求。在SOA软件平台的帮助下，通过数据、算法、软件的不断积累和迭代升级，最终汽车将由执行指令的冰冷机械，进化为能够实时交流、洞察需求、主动服务的“有生命的出行伙伴”。
