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