摘要
未来，车辆制造商希望在网络通信领域提供更高的灵活性，例如在开发过程中以及生产后提供简化的更新和升级功能。为实现这一目标，当前车辆内部架构领域正经历一场范式转变 ------ 多年来，车辆内部架构一直基于面向信号的通信设计。面向服务通信的引入解除了集成电子控制单元（ECU）之间的静态分配关系。然而，在这些面向服务网络的开发过程中，新的挑战已然出现。本文提出了一种搭建此类网络仿真与测试平台的方法，并阐述了相关挑战，同时探讨了该平台可支持的潜在用例。其中，信息安全是一个关键方面，在开发这些架构之初就必须予以考虑。在未来的工作中，我们计划通过集成新的安全措施等方式为网络增加更多服务，以便在仿真环境中对其进行测试。
一、引言
受电气化、自动驾驶和车联网等趋势的影响，汽车行业目前正经历一场变革。此外，未来还应提升在用车的更新和升级能力，并简化开发过程中的功能适配。在以往的车辆中，仅采用面向信号的网络技术（例如控制器局域网（CAN）协议）。因此，发送方和接收方之间的网络消息静态分配在开发阶段就已确定。待传输的信号信息（如车速）被静态分配到有效载荷内的消息中。例如，若要在实际应用中添加一项需要或提供特定信号的新功能，就必须对网络配置进行全面修改。为应对这些挑战，面向服务架构（SOA）范式正被引入当前的车辆中。这使得基于动态通信模式的面向服务通信成为可能。因此，服务提供者可以为消费者提供特定服务，且服务在运行时可随时调用。SOA 范式应用于汽车以太网技术，与 CAN 标准相比，该技术除了支持高速传输速率外，还能实现点对点连接。然而，这种变革也对现有的开发流程及所使用的工具产生了影响。CANoe是汽车制造商和供应商广泛使用的一款成熟工具，适用于仿真、测量和软件测试。基于 CAN 协议创建网络仿真时，可构建一个包含所有消息、信号及相关属性（如周期时间）的整体数据库。但基于汽车以太网构建 SOA 仿真则需要新的流程。
SOA 等新型通信范式要求在以太网网络的开发和测试中采用新方法。通过使用 CANoe 等仿真工具，可在网络或服务部署到实际硬件之前对其进行开发和测试。本文提出了一种汽车 SOA 仿真方法，并介绍了应用场景。
二、背景
（一）汽车以太网
2015 年，IEEE 802.3bw 标准对汽车以太网技术进行了规范。该标准（也称为 100Base-T1）基于 ISO/OSI 第一层，通过非屏蔽双绞线电缆提供 100 兆比特 / 秒的数据传输速率。对于带宽需求较低且需低成本实现的应用，10Base-T1 标准定义了 10 兆比特 / 秒的数据传输速率。在 OSI 较高层级（2、3、4 层），汽车以太网融合了传统信息技术（IT）中的多种不同协议。对于 SOA，以太网与传输控制协议（TCP）/ 互联网协议（IP）或用户数据报协议（UDP）/IP 结合使用。与采用载波监听多路访问 / 冲突避免（CSMA/CA）访问方法的 CAN 协议不同，汽车以太网无需此类方法，因为其通信被指定为全双工传输。这使得两个网络节点能够同时发送和接收消息，从而避免冲突。由于其物理结构为星形拓扑，每条线路仅连接两个网络参与者，因此不会发生冲突。
（二）面向服务架构
在车辆架构中集成 SOA 范式旨在为原始设备制造商（OEM）和第三方供应商提供更高的灵活性，使其能够在开发过程中或实际运行时更便捷地进行更改。为此，功能被划分为尽可能小的服务，这些服务可通过编排来执行更复杂的任务。此外，硬件和软件之间的解耦程度进一步提高，使得功能设计与底层架构不存在静态依赖关系。例如，功能开发人员无需知道某个传感器信号在哪个消息中传输，或所需功能集成在哪个 ECU 上，而只需了解车辆中可用的服务概况。在汽车领域，目前用于车载 SOA 通信的协议包括基于 IP 的可扩展面向服务中间件（SOME/IP）和数据分发服务（DDS）。中间件充当服务提供者和消费者之间的协调者，并基于 SOME/IP 支持以下功能：
· 序列化：实现数据在 OSI 低层与高层之间的相互转换。
· 远程过程调用（RPC）：包括简单的 "即发即弃"（Fire&Forget）模式（客户端调用服务提供者提供的方法且无需返回值）和 "请求 / 响应"（Request/Response）模式（带有返回值的方法调用，返回值通过额外消息传输）。
· 服务发现（SD）：涵盖三个核心方面：一是传输现有服务的状态信息（是否可用）；二是支持消费者定位所需服务；三是通过 SD 实现发布 / 订阅机制。
· 发布 / 订阅：服务提供者可提供事件通知（Event Notification）或字段通知（Field Notification），消费者可进行订阅。一旦事件或字段中的信号发生变化（如座椅占用状态），相关信息将通过事件帧发送给所有订阅者。这使得仅在发生变化时才传输帧，从而最大限度地减少网络负载。与事件不同，字段包含历史参考（先前的值）。
· UDP 消息分段：该功能允许通过 UDP 帧传输大型 SOME/IP 数据，且无需分片。
此外，由于电气和电子架构（E/E 架构）中未采用信号到消息的静态映射，该概念允许在开发完成后仍能添加新功能。新功能可作为升级项添加，且所需服务可轻松订阅。
（三）AUTOSAR
汽车开放系统架构（AUTOSAR）标准的核心目标是将软件功能与所用硬件解耦，以简化汽车软件的可复用性。这意味着 AUTOSAR 不仅包括操作系统本身，还包含分层软件架构，即基础软件层（BSW）、运行时环境层（RTE）和应用层。基础软件层（也称为 AUTOSAR 协议栈）包含多个模块和子模块，负责处理通信、诊断或安全等特定任务。实际应用程序下方所需的模块（如用于建立车辆通信的模块）被称为 AUTOSAR 通信栈。
目前，AUTOSAR 有两种不同的平台变体（经典 AUTOSAR 和自适应 AUTOSAR），未来车辆将以混合方式集成这两种变体。经典变体主要针对传统 ECU 的面向信号通信概念。较新的自适应变体于 2017 年首次发布，旨在支持基于可移植操作系统接口（POSIX）操作系统和面向对象编程的 SOA 范式。为确保两个平台的兼容性，经典变体提供有限的面向服务通信能力。
开发新车辆时，OEM 将所有所需功能定义为软件组件（SWC），并以可扩展标记语言（XML）文件的形式提供相关接口描述。然后，将软件组件分配给规划中的控制单元，这些控制单元通过网络技术（如 CAN 或以太网）连接。相关信息以系统描述的形式存储在 AUTOSAR XML（ARXML）文件中。为便于交换这些描述，会生成系统描述摘要，供相关供应商在开发过程中导入使用。
图1、SOA原则由服务代理、消费者和提供者组成
（四）CANoe
CANoe 软件在开发早期阶段及后续测试活动中就支持车辆网络及相关 ECU 的开发。除了对所有组件进行完整仿真外，还可仅仿真网络的一部分，并将实际 ECU 集成到仿真中。仿真 ECU 上的功能实现可通过 Vector 专用编程语言通信访问编程语言（CAPL）或微软.NET 框架完成。为仿真 SOA，可导入不同的描述格式（如.ARXML），这些格式包含已定义的 ECU、服务和接口的相关信息。
三、搭建原型网络
本节的目标是搭建一个支持与实际节点通信的示例网络，以阐释 SOA 原理并提供开发和测试平台。为此，我们对不同的搭建方案进行了可行性评估（见表 1），具体如下所述。
表 1、SOA 网络三种不同搭建方案的评估
（一）原型实现方案
-
方案 1：第一种方案是建模三个节点，分别代表媒体播放器、导航系统和显示器。此外，开发一个可连接到 CANoe 仿真并输出相应数据的实际节点，通过以太网硬件接口实现与 CANoe 的连接。但该方案存在一些挑战：首先，新创建的 CANoe 示例尚未包含 SOME/IP 实现；其次，媒体文件采用 Windows 标准格式，数据通过 Windows 标准工具显示；此外，实例化实际 SOME/IP 节点需要完整的自适应 AUTOSAR 协议栈实现。
-
方案 2：Vector 已开发一款计算器示例，该示例已应用于多个 CANoe 软件版本，且包含 SOA 实现。服务提供者将各种基本算术运算作为服务提供，消费者可通过 RPC 访问这些服务。该实现已提供 SOME/IP 描述，支持将仿真（服务提供者）与实际网络节点（消费者）耦合。但挑战在于，为使用 SOME/IP 功能，需在实际节点上实现 AUTOSAR 协议栈，这需要扎实的 AUTOSAR 知识和工具支持。相比之下，可通过实际汽车以太网连接进行数据传输，以便进一步分析。
-
方案 3：另一种方案是使用另一台运行 CANoe 的电脑替代实际节点。这将简化实现过程，因为无需进行 AUTOSAR 协议栈实现，但需要额外支付 CANoe 许可费用。
为确定最合适的方案，我们进行了效用值分析（见表 1）。基于该分析，方案 3 最为合适，因为其已具备 SOME/IP 实现和数据序列化功能，且可将配置数据存储在以太网硬件接口上，从而简化了可重复性。尽管购买多个硬件接口及由此产生的成本带来了负面影响，但方案 3 在时间投入方面具有优势，其加权总评分为 83%。
（二）实现过程
该实现基于图 2 所示的结构，包含两个 CANoe（12 版本）实例和两个 USB - 以太网硬件接口。CANoe 中已有的计算器功能用作 SOME/IP RPC，同时实现了两个 SOME/IP 事件服务（回声（Echo）、三角波（Triangle））。此外，通过现有的 ARXML 文件将服务描述导入 CANoe。
图2、原型汽车以太网的结构
所实现服务的 SOME/IP SD 通信原理如图 3 所示。SOME/IP 节点 2 提供服务接口（SIF）为 11 的三角波（Triangle）服务，该服务代表由该节点生成的三角波信号。节点 1 通过订阅事件组（SIF 11）消息订阅该服务，服务提供者则通过确认消息响应。一旦信号值发生变化，消费者（节点 1）将收到新的 SOME/IP 消息。
此外，节点 1 提供回声（Echo）服务，该服务对所订阅的三角波服务进行反转处理。在这种情况下，节点 2 作为消费者，订阅服务接口（SIF）为 10 的回声服务。由于三角波服务的值定期变化，回声服务也将以相同的周期时间发送。
第二种服务类型为 RPC，支持四种不同的方法（加、减、乘、除）。可通过图形界面在仿真中修改方法参数，同时也可在图形面板中可视化服务提供者的返回值。这些服务通过 CAPL 实现，并存储在仿真节点上。面板的图形元素允许与 CAPL 实现建立链接，例如读取或修改变量。
除 SOME/IP 配置外，还需为每个节点分配相应的 IP 地址、媒体访问控制（MAC）地址以及交互层（IL）。交互层负责将仿真 SOME/IP 节点与实际网络硬件连接起来。
图 3、两种不同服务类型（RPC、事件）的通信原理
四、SOME/IP的安全性
由于 SOA 服务分布在不同的实例上，且需通过上述机制（如发布 / 订阅）进行请求，因此 SOME/IP 协议的安全性问题应运而生。特别是通信参与者的真实性至关重要，因为攻击者可能伪装成服务提供者，提供被篡改或恶意的服务。此外，近年来发生的车辆攻击事件往往导致车辆内部通信的真实性遭到破坏。近年来，车辆安全受到了媒体、车辆制造商、供应商及研究界的广泛关注。因此，相关标准（如 ISO 21434标准和联合国欧洲经济委员会（UNECE）WP.29法规）正在制定中，这些标准和法规明确了车辆生命周期内安全保障所需满足的要求。对于面向服务架构而言，这意味着所使用的协议必须具备抗攻击能力。为此，本节将探讨 SOME/IP 协议的安全性相关方面。我们参考了文献，该文献基于 "通过修复漏洞增强软件安全性和安全性（HEAVENS）"方法对 SOME/IP 协议进行了威胁和风险分析，研究了服务发现、远程过程调用和发布 / 订阅等通信机制。威胁分析识别出了数据修改、读取、删除或服务操纵等威胁。在后续的风险评估中，这些威胁被评为中高风险，因为 SOME/IP 协议几乎未提供任何防范攻击的安全机制。因此，应通过测试验证已发现威胁的实际可行性，而安全机制的集成可作为进一步的研究方向。下一节将介绍本文提出的方法可支持的用例。
五、用例
所搭建的网络可用于多种用例。一方面，它适用于实验室课程，为学生提供面向应用的环境；另一方面，可用于研究并扩展，以探索汽车功能的新方法。此外，可通过网关与面向信号的网络技术（如 CAN 总线）耦合，构建混合 E/E 架构，进而用于研究传输延迟。特别是服务与面向信号消息之间的相互适配（或反之）带来了新的挑战。
另一个新兴的研究领域是 SOA 网络的信息安全。基于威胁和风险分析，可推导安全机制并将其集成到 SOA 仿真中。前文所述的研究已提出了部分可能的安全机制，例如可在 CANoe 仿真中部分实现这些机制以测试其有效性。因此，CANoe 可用于搭建测试平台，支持基于上述 SOA 架构的安全测试。这使得验证已识别威胁的可行性成为可能，此外，还可通过在集成安全机制前后对架构进行攻击测试，来验证安全机制的有效性。
六、结论
SOA 范式正被引入当前的车辆架构中。与传统的面向信号通信相比，这种通信方式和网络开发发生了根本性变化，为功能的更新和升级提供了更高的灵活性。然而，搭建这些网络也面临新的挑战。本文阐述了如何实现基于 SOME/IP 的原型通信，该通信包含仿真（CANoe）和用于传输汽车以太网数据包的实际硬件。但其中一个挑战是 SOA 通信的描述 ------ 需通过网络描述文件定义，这需要额外的工具支持和扎实的 AUTOSAR 知识。此外，由于 SOME/IP 协议缺乏安全功能，本文还强调了安全在 SOA 中的重要性，未来应改进这一问题。可利用 CANoe 等工具搭建测试环境，开展 SOA 安全措施研究，以支持安全测试的执行。
七、未来工作
在未来的工作中，我们将通过添加更多网络节点和服务来扩展 SOME/IP 结构，但需要创建新的 AUTOSAR 网络描述文件并将其集成到仿真中。此外，将开发和实现处理环境信息（如摄像头和雷达数据）的自动驾驶功能，并测试模拟服务提供者故障的场景。受影响的客户端应能够在运行时订阅其他可用的服务提供者。此外，可通过集成安全测试来扩展仿真，构建测试框架。通过这种方式，可通过模拟对系统的攻击来验证安全措施，从而助力构建 SOA 中的安全通信场景。