本页面使用了机器翻译。
请花 1 分钟时间完成一个翻译质量的调查。
使用基于模型的设计开发和测试车载操作系统的 SOA 应用程序
作者 : 魏旻，极氪智能科技控股有限公司
“我们正在基于 MATLAB、Simulink、System Composer 和 Embedded Coder 完善和扩展我们的工作流。该工作流通过加速开发并最大限度地减少手写代码固有的挑战，已经证明了其价值。”
随着车辆从传统机械系统演变为软件定义汽车 (SDVs)，汽车行业正在经历一场深刻的变革。这种转变需要新的软件开发方法，而面向服务的架构 (SOA) 正成为设计灵活、可扩展的汽车应用程序的首选范式。在极氪，我们通过建立一个基于基于模型的设计的全面工作流来迎接这一转型，用于开发运行在我们车载操作系统上的 SOA 应用程序。
使用基于模型的设计进行传统汽车软件开发主要集中在 AUTOSAR® Classic 平台的实现上，其中软件组件 (SW-Cs) 通过标准化的运行时环境 (RTE) 接口进行交互。然而，SOA 引入了新的通信模式，如客户端-服务器调用和基于消息的交互，这需要对既定的开发实践进行重大调整。挑战不仅在于对这些新的通信模式进行建模，还在于在非 AUTOSAR 标准化环境中管理日益复杂的软件架构。
我们在极氪的团队通过基于模型的设计工作流解决了 SOA 应用程序开发中的这些挑战。本文描述了该工作流的三个关键领域：
- 使用 Simulink® 的客户端-服务器接口功能对 SOA 行为进行建模
- 通过基于 System Composer™ 的定制工具维护复杂的软件架构
- 对 SOA 应用程序实施有效的验证和确认
我们的经验展示了工程师如何利用基于模型的设计，加速从传统嵌入式系统向现代 SDV 的 SOA 软件架构转型。
在 Simulink 中对面向服务的应用程序进行建模
SOA 引入了与传统嵌入式系统根本不同的新通信模式。经典的 AUTOSAR 应用程序通过简单的 RTE 接口进行通信，这些接口促进了软件组件之间紧耦合、静态定义的交互。相比之下，SOA 通信模式（如远程过程调用和基于消息的交互）更加灵活和复杂。它们还实现了硬件和软件的解耦，以及软件的分层设计。为了充分利用这些模式，我们遵循建立在基于模型的设计之上的开发工作流，其中包括在 Simulink 中对 SOA 应用程序进行建模，使用 Embedded Coder® 生成 C++ 代码，使用我们构建的包装器生成器创建中间件集成代码，并将应用程序代码和集成代码合并为可部署的应用程序包。这个自动化工作流不需要任何手写的 C++ 代码。自动生成的包装器代码将我们从 Simulink 模型生成的应用程序代码与运行时环境 - ZEEKR ARK OS - 连接起来。
在我们工作流中的典型 SOA 模型包括服务提供者和客户端，两者都在 Simulink 中建模（图 1）。这种结构捕捉了基本的 SOA 行为：解耦的服务调用、显式的消息交换以及通信与计算的清晰分离。它使我们能够在 Simulink 中清晰地表达 SOA 概念，并为在分布式、基于服务的环境中部署这些模型做好准备。
图 1. 在 Simulink 中建模的一个简单的客户端和服务器。客户端包括一个由控制信号（“Step”）周期性触发的接收器模块和一个发送器模块。
我们的部署场景涵盖了中央和分布式计算环境（图 2）。在 Simulink 中建模的面向服务的应用程序运行在高性能中央计算单元上。与此同时，经典的 AUTOSAR 组件（同样在 Simulink 中开发）在微控制器上执行，直接与车辆执行器接口。这种混合部署反映了向集中式域架构发展的更广泛趋势，即域控制器管理高级处理，而边缘节点处理低级控制。借助 Simulink，我们可以支持该架构的两个方面，使用统一的开发环境对异构汽车系统进行建模、仿真和生成代码。
图 2. 在 Simulink 中开发的现实世界空调应用程序，结合了部署到中央处理器节点的 SOA 软件和运行在微控制器上以驱动执行器的 AUTOSAR Classic SW-C。
使用 System Composer 管理复杂的软件架构
随着面向服务的应用程序在范围和复杂性上的增长，管理其结构成为一个关键挑战。随着多个服务在多个软件单元之间进行交互，仅仅隔离地处理每个模型已不再足够。相反，我们需要清晰的架构表示，说明软件组件如何相互关联，包括它们如何分组、如何通信以及部署在哪里。许多市售的汽车软件架构工具，包括 AUTOSAR 创作工具，通常假设基于 AUTOSAR 的环境，并不支持为自定义操作系统部署基于服务的通信模型的灵活性。为了满足我们 SOA 框架和车载操作系统的需求，我们构建了自己的架构建模环境。SOA Model Composer（简称 SOMOC）建立在 System Composer 的基于模型的系统工程能力和架构设计元素之上，同时也利用了 MATLAB® 的面向对象编程能力。为了便于使用，我们使用 MATLAB 和 App 设计工具创建了一个自定义用户界面（图 3）。
图 3. SOMOC 用户界面，包括架构树视图（左）和组件组合器界面（右）。
SOMOC 支持一种结构化的方法来定义和管理跨越四个关键层级的 SOA：系统架构、进程、软件组件和服务定义（图 4）。这种分层组织利用 System Composer 的参考组件功能，建立从顶层系统到单个服务的清晰可追溯性。
图 4. SOMOC 中的组件层级结构，显示了架构、进程、SW-C 和服务层级。
SOMOC 通过捕捉 SOA 特定元数据（如服务标识符、命名空间和版本信息）的自定义配置文件和构造型扩展了架构模型。极氪系统架构师使用 SOMOC 将功能需求（从系统设计期间生成的 ARXML 文件导入）转化为可部署的架构，通过定义进程边界、服务接口和软件组件来实现。通过这些架构模型，SOMOC 自动生成具有一致接口的框架 Simulink 模型，为开发人员实施内部行为或逻辑提供了可靠的起点（图 5）。这种自动化标准化了从架构到实现的流程，保持接口同步，并为我们的团队在整个开发过程中提供了一个共享的参考点。
图 5. 在 SOMOC 框架内设计和测试的不同层级。
SOA 应用程序的多级测试
在极氪，我们通过结合模型级和代码级测试来验证我们的面向服务的应用程序。我们从 Simulink 中的单元和模型测试开始，使用 Simulink Test™，利用测试框架隔离单个组件并验证服务交互（图 6）。对于每个模型，工程师可以模拟与对应组件（例如消费者模型的模拟提供者）的通信，并验证预期的响应和接口行为。这种早期验证有助于在代码生成之前识别逻辑错误或接口不匹配。
图 6. 测试序列编辑器中显示的测试框架的测试序列。
在生成应用程序代码并将其与我们的车载操作系统集成后，我们使用 Service Verification Toolkit (SVT) 进行运行时测试，这是 Visual Studio Code 中的一个轻量级插件（图 7）。SVT 使团队能够从 ARXML 文件导入服务接口定义，然后通过在应用程序级别模拟服务通信来测试方法和主题接口。它可以充当消费者或提供者：发送方法请求、处理响应、发布主题数据或订阅消息。SVT 显示跨服务接口交换的值，帮助工程师确认部署的应用程序在不同交互场景下行为正确。
图 7. Visual Studio Code 中的 SVT 插件。
展望未来
随着我们继续为车载部署开发新的面向服务的应用程序，我们也在基于 MATLAB、Simulink、System Composer 和 Embedded Coder 完善和扩展我们的基于模型的设计工作流。该工作流通过加速开发并最大限度地减少手写代码固有的挑战，已经证明了其价值。凭借在一个环境中执行面向服务和基于 AUTOSAR 的应用程序的架构建模、服务建模、仿真、代码生成和测试的能力，我们拥有了一个可扩展的软件基础，以支持 SDV 开发，因为它继续重塑汽车行业的格局。
2025 年发布
