连接系统与软件：面向 SDV 分布式架构功能开发的统一方法

当功能跨越中央计算机、区域控制器和边缘设备，并在复杂的集成边界上融合面向服务的架构和基于信号的架构时，软件定义汽车 (SDV) 开发团队如何才能尽早做出正确的架构和软件决策，并持续验证这些决策？

SDV 正在重新定义汽车工程，而且不仅仅是通过增加代码量。SDV 正在重塑软件在哪里运行、功能如何组合，以及“集成”究竟意味着什么。随着功能跨越多个计算域、通信协议，甚至不同组织，团队需要能够从一开始就让架构意图与软件行为保持一致的方法。

然而，这种架构上的自由也有代价：接口更多、时序路径更多、失效模式更多，细小的不匹配也更有可能在后期才暴露出来，尤其是在车型、供应商和进度都已确定的情况下。在这种环境下，系统工程师和软件工程师必须尽早做出正确的决策，并借助模型和仿真持续验证这些决策。

为帮助企业应对这一挑战，KPIT 与 MathWorks 将成熟方法论的应用、深厚的汽车领域专业知识，以及将系统意图与可执行模型相连接的集成工具链结合在一起。由此形成了一个端到端、可追溯的工作流，既支持尽早做出架构和软件决策，也支持通过仿真进行持续验证，并将利益相关方意图（作为单一可信数据源）与架构选择、可部署软件和验证证据关联起来。

分布式 SDV 功能面临的主要挑战

SDV 功能开发很少因为某个团队写了“糟糕的代码”而失败。失败的原因在于：功能跨越 ECU 边界，混合了面向服务和基于信号的交互，并暴露出设计与实现之间的差距。这些差距往往直到后期集成时才会显现，因此以下挑战通常决定了一个项目能否快速、可靠地交付复杂功能：

• 大规模需求的模糊性：功能性需求和非功能性需求必须考虑分布式部署、时序、局部失效、功能安全和网络安全。
• 架构决策向下游传导：选择服务还是信号以及 ECU 分配，会决定接口、软件划分和验证工作量。
• 跨团队协同：多领域团队需要共享的可追溯模型，以避免后期返工。
• 工具链碎片化：互不连通的工具会妨碍可追溯性和“流程前置”验证；虚拟集成需要一致的架构模型和行为模型。

统一的基于模型的系统工程与基于模型的设计工作流

本文介绍一种功能驱动的工程方法，它将基于模型的系统工程（系统/功能意图、需求和架构）与基于模型的设计（可执行软件模型、仿真和代码生成）统一起来。该工作流采用系统化、自上而下的方法进行架构和需求开发，并在每个阶段应用恰当的抽象层级。它可用于开发跨越异构 ECU、混合面向服务和基于信号的交互的 SDV 功能。

该方法使用互连的 ECU 模型和软件组件模型，在仿真环境中集成和验证分布式功能，从而加快功能交付。它还提高了端到端可追溯性，便于开展影响分析和合规工作，从而减少在中央、区域和边缘 ECU 上部署时的后期返工。

在实践中，团队需要一种方法，让架构决策尽早变得可测试：该功能能否满足跨区域的时序要求、承受局部失效、满足功能安全/网络安全约束，同时仍能在 AUTOSAR^® Classic/Adaptive 目标上一致地实现？统一的基于模型的系统工程与基于模型的设计工作流能够在硬件和整车集成之前明确提出这些问题，并给出答案。

下面我们来了解功能驱动方法的主要工作流步骤：

1. 功能范围界定：收集利益相关方需求，定义功能边界、参与者和依赖关系。
2. 要求：定义用例和行为，推导出具有明确验收标准的系统需求（功能性和非功能性）。
3. 系统架构：创建并验证功能架构（功能和交互）、与平台无关的子系统识别和架构，以及与平台相关的系统架构（ECU/网络以及服务与信号的选择）。
4. 软件架构：针对每个 ECU（HPC/区域/边缘）推导软件需求和软件架构，使其符合 AUTOSAR Classic/Adaptive 或定制需求。
5. 详细软件设计：为算法和组件行为开发可执行模型，并尽可能复用既有资产。
6. 功能验证：在硬件就绪之前，运行模型在环/闭环仿真来验证行为。
7. 代码生成与集成：生成产品级 AUTOSAR Classic/Adaptive 代码或定制代码，并无缝集成到 CI 和验证工作流中。

采用本文提出的方法可带来以下主要优势：

• 尽早发现缺陷：可执行模型和仿真能够在硬件和整车集成之前暴露集成和时序问题。
• 更快的迭代：虚拟集成测试可减少返工循环，加快功能交付。
• 可追溯的工程：各工件之间的一致链接支持在需求变更时进行覆盖率检查和高效的影响分析。
• 可复用的架构资产：逻辑架构为跨车型项目复用的系统提供了与平台无关的参考。
• 可直接部署的输出：软件架构和代码生成符合 AUTOSAR Classic/Adaptive 以及 SOA/信号混合通信的要求。

接下来，我们将通过一个真实用例展示该方法的实际应用。

示例：开发充电口盖管理功能

为演示该工作流，我们将逐步介绍一个涉及用户、硬件、网络和安全约束的真实功能：电动汽车的充电口盖管理。该示例展示了功能驱动的流程如何从范围界定和需求，推进到架构分配、仿真和产品级代码生成，并且在整个过程中始终保持可追溯性。

口盖管理系统控制车辆的充电口盖（图 1）。它持续协调物理世界（例如位置感知、执行器状态以及闩锁/锁止反馈）与充电上下文（例如车辆状态、车载充电机状态），以决定口盖何时可以打开、何时必须关闭或何时应当锁止。随后，系统向驾驶员和其他车辆功能发布状态更新和警告。口盖管理系统涵盖感知、执行和 ECU 协同，虽然规模不大，却能真实地代表更广泛的 SDV 分布式功能开发。

功能范围界定

我们定义功能边界（参与者、输入/输出和依赖关系），以建立共同的范围，并为需求获取和分析提供输入。

在本示例中，我们假设车辆采用现有的电子电气 (E/E) 区域架构，该架构由一个高性能中央计算机 (HPC)、一个兼作网关的区域 ECU，以及负责实时感知和执行的多个边缘 ECU 组成。

在此阶段，我们执行影响分析，并使用 System Composer™ 推导出功能边界图，以捕获受口盖管理影响的功能以及这些功能之间交换的信息。边界视图明确了哪些车辆功能和外部参与者与口盖管理功能交互，以及交换哪些信息（图 2）。

功能层级

我们通过用例图捕获主要用例并推导功能行为，然后将这些行为转化为明确的系统级需求。我们确定了两个用例：“开始充电会话”和“停止充电会话”（图 3）。

确定这两个用例后，下一步是定义该功能在每个用例中执行的各项活动。这有助于描述该功能的行为，并为口盖管理捕获一组初始系统级需求。然后，我们使用 System Composer 创建活动图（图 4）。

基于前面的分析和图表，我们现在可以使用 Requirements Toolbox™ 中的需求编辑器创建系统级需求（图 5）。这些需求与各项操作相关，例如打开和关闭口盖以及通知口盖状态。

接下来，我们创建功能架构，并将需求分配给各项系统功能，以保持可追溯性。这包括定义：

• 系统功能：协同实现整个功能的各个技术功能单元
• 交互：这些系统功能之间如何通信和协同工作

基于对系统需求的分析，我们将充电口盖功能分解为四项系统功能（图 6）：

• 测量充电插座电流
• 获取口盖状态并通知用户
• 关闭口盖
• 打开口盖

在定义功能架构的过程中，我们将每条系统需求分配给负责满足该需求的一项或多项系统功能，并在适用时分配给传递所需信息的交互。这种分配可确保每条需求都由设计元素覆盖，使遗漏/重叠尽早显现，并为下游的逻辑/物理设计和验证提供从需求到系统功能的可追溯性。在实际操作中，只需将需求拖放到 System Composer 组件上，即可高效完成这种分配（图 7）。

与平台无关的子系统识别和架构

我们将系统功能分配给逻辑子系统，并定义子系统之间的逻辑接口，从而创建一个可复用、与平台无关的架构视图（图 8）：

• 充电接口子系统，负责打开和关闭口盖以及通知口盖状态
• 充电控制子系统，负责编排来自通信接口的请求并管理所有充电操作
• 充电通信子系统，负责管理与用户及系统其余部分的通信

与平台相关的系统架构

现在，我们将逻辑子系统分配到目标 E/E 架构（例如边缘 ECU、区域控制器和中央计算机/HPC），并定义主要接口，包括哪些交互以服务实现、哪些以信号实现。

确定各个组件后，我们可以在 System Composer 中创建系统架构图，突出显示组件边界以及组件之间为实现口盖管理功能而必须交换的信息（图 9）。

软件架构、仿真和代码生成

我们根据系统需求和系统架构，推导出每个 ECU（HPC、区域、边缘）的软件需求和架构，并将其细化为可部署的软件组件。在 HPC 上，该功能被分解为服务和应用程序（例如，在适用时采用 AUTOSAR Adaptive），而区域/边缘节点则承载时间关键型感知/执行功能（例如 AUTOSAR Classic 或同类平台）。接口（服务、信号和数据类型）从物理架构一致地延续到软件端口和连接器中，从而能够在目标硬件就绪之前进行早期一致性检查、可执行行为建模，并集成仿真钩子（用于 MIL/SIL 和闭环运行）。

首先，我们为 HPC、区域 ECU 和边缘 ECU 组合创建顶层软件架构，并将其链接到系统架构（图 10）。

我们在 System Composer 的架构建模画布中，为每个架构组合定义了软件组件并进行建模。HPC 组合包含三个 AUTOSAR Adaptive 服务组件，这些组件采用 SOA 范式在 Simulink^® 中实现（图 11）。

完成该功能在三个 ECU 上的实现建模后，我们可以创建一个闭环仿真模型，将这些 ECU 连接到口盖的被控对象模型（包括电流传感器、位置传感器和执行器模型），从而在真实条件下快速验证功能行为。例如，我们可以通过仿真评估系统在不同车速下如何响应用户打开口盖的请求（图 12）。

验证完成后，工作流的下一步是使用 Embedded Coder® 生成产品级代码，用于集成和部署（图 13）。Simulink 提供开箱即用的支持，可生成符合 AUTOSAR Classic 和 AUTOSAR Adaptive 标准的代码，便于进一步集成和部署。

此外，引入新需求时，可以在系统需求层级捕获该需求，并对其进行影响分析，以识别受影响的元素。由此产生的变更会以可视化方式呈现，并传播到相关的系统接口和软件接口，随后再迭代工作流，以适应不断变化的需求。这一过程依托端到端可追溯性来实现：使用可追溯性图（图 14）管理 SDV 开发生命周期中的动态变更。

既有应用程序的迁移

除全新功能开发外，同一集成工作流还支持将基于信号的既有功能系统化地迁移到面向服务的分布式软件架构。在实践中，对于最初以紧耦合可运行实体链实现、通过 CAN 信号或 ECU 本地数据交换信息的现有功能，可以在功能层级和逻辑层级进行分析，分解为更清晰的职责，并重构为具有明确定义的接口、事件和数据契约的服务提供方、服务使用方和编排逻辑。这样，既能保留已验证的功能行为，又能在 HPC、区域控制器和边缘 ECU 之间重新分配职责。此外，还能评估通信变更对时序、安全和集成的影响。由于需求、架构元素、软件组件和验证工件之间始终保持可追溯的关联，团队可以逐步对既有实现进行现代化改造，在复用测试用例和合规证据的同时，保持迁移后的服务与原始设计意图一致。

结束语

将基于模型的系统工程与基于模型的设计相集成，可为 SDV 功能开发提供实用的端到端工作流，从而明确系统意图、通过仿真更早地开展验证，并产出可部署的软件工件。该方法明确以功能为驱动，其结构旨在充分利用贯穿所有设计阶段的可追溯性，使工程决策从意图到部署始终保持一致。其收益显而易见：该工作流可实现更快的迭代，减少后期集成中的意外问题，并使异构 ECU 和 SOA/信号混合架构上的实现更加一致。

随着业界不断探索 AI 驱动的开发方法（包括新兴的智能体 AI 方法），人们开始思考成熟工程实践所扮演的角色。在这一新背景下，基于模型的系统工程和基于模型的设计方法的价值变得更加清晰：在人与 AI 日益紧密协作的开发闭环中，这些方法提供了必要的严谨性，可以锚定需求、明确系统意图，并使架构、行为和验证保持一致。因此，这些方法是交付 SDV 软件的关键基础，确保软件不仅具有创新性，而且值得信赖、易于维护。

本文提出的框架依托 KPIT 的汽车专业知识和 MathWorks 提供的工具链连续性，加强了架构师、软件开发人员和集成工程师之间的协作，提高了从需求到架构的可追溯性，并在不牺牲可行性的前提下支持日益复杂的系统定义。

了解更多