SDV分布式架构特征开发的统一方法

使用特性驱动的工作流连接需求、架构、仿真和部署。.

概括

• 您可以采用功能驱动的工作流程，将需求、架构决策和可部署软件连接起来，从而实现软件定义车辆的开发。.
• 将基于模型的系统工程与基于模型的设计相结合，有助于在整车集成之前，通过仿真尽早验证分布式功能。.
• 功能开发全过程（包括需求、架构、设计、实现和测试）的可追溯性有助于高效地管理变更。.
• 充电盖管理示例展示了工作流程如何在中央计算机、区域控制器和边缘 ECU 之间扩展。.

软件定义车辆 (SDV) 开发团队如何才能在早期做出正确的架构和软件决策，并不断验证这些决策？因为 SDV 的功能涵盖中央计算机、区域控制器和边缘设备，并将面向服务的架构和基于信号的架构融合在复杂的集成边界上。

SDV（软件定义车辆）正在重新定义汽车工程——而不仅仅是增加代码。它们正在重塑…… 在哪里 软件运行，, 如何 特征由……组成，并且 什么 “集成”的真正含义是什么？随着功能跨越计算领域、通信协议，甚至不同的组织，团队需要从一开始就确保架构意图和软件行为保持一致的方法。.

然而，这种架构上的自由也伴随着代价：接口更多、时序路径更多、故障模式更多，而且更容易出现细微的偏差，尤其是在车辆、供应商和进度安排已经确定的情况下。在这种情况下，系统和软件工程师必须尽早做出正确的决策，并通过模型和仿真不断验证这些决策。.

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

分布式软件定义视觉特性面临的关键挑战

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

• 大规模需求模糊性： 功能性和非功能性需求必须考虑分布、时间、部分故障、安全性和网络安全。.
• 架构决策会向下传递： 服务与信号选择和 ECU 分配驱动接口、软件分区和验证工作。.
• 跨团队协调： 多领域团队需要共享、可追溯的模型，以避免后期返工。.
• 工具链碎片化： 工具不独立会阻碍可追溯性和“左移”验证；虚拟集成需要一致的架构和行为模型。.

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

本文提出了一种特性驱动的工程方法，该方法将基于模型的系统工程（系统/特性意图、需求和架构）与基于模型的设计（可执行软件模型、仿真和代码生成）相结合。该工作流程遵循系统化的自顶向下架构和需求开发方法，并在每个阶段应用适当的抽象级别。它可用于开发跨越异构ECU并混合面向服务和基于信号的交互的SDV特性。.

这种方法通过使用互联的ECU和软件组件模型，在模拟环境中集成和验证分布式功能，从而加速功能交付。它还提高了影响分析和合规性的端到端可追溯性，减少了在中央、区域和边缘ECU上部署时的后期返工。.

在实践中，团队需要一种方法来尽早对架构决策进行测试：该功能能否满足跨区域的时序要求，能否在部分故障的情况下正常运行，能否满足安全/网络安全约束，并且能否在 AUTOSAR® Classic/Adaptive 目标平台上保持一致的实现？统一的基于模型的系统工程和基于模型的设计工作流程，能够在硬件和整车集成之前，明确并解答这些问题。.

让我们一起来看看特性驱动方法的主要工作流程步骤：

• 功能范围界定： 收集利益相关者的需求，定义功能边界、参与者和依赖关系。.
• 要求： 定义使用场景和行为，推导出系统需求（功能性和非功能性），并明确验收标准。.
• 系统架构： 创建并验证功能架构（功能和交互）、平台无关的子系统识别和架构，以及平台相关的系统架构（ECU/网络和服务与信号决策）。.
• 软件架构： 根据 AUTOSAR Classic/Adaptive 或自定义需求，推导出每个 ECU（HPC/区域/边缘）的软件需求和软件架构。.
• 详细软件设计： 开发算法和组件行为的可执行模型，并尽可能重用旧资产。.
• 功能验证： 在硬件可用之前，运行模型在环/闭环仿真来验证行为。.
• 代码生成与集成： 生成可用于生产的 AUTOSAR Classic/Adaptive 或自定义代码，并可无缝集成到 CI 和验证工作流程中。.

采用该方法可获得以下主要益处：

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

在本文的其余部分，我们将通过一个实际用例来展示该方法的实际应用。.

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

为了演示这一工作流程，我们将深入探讨一个涉及用户、硬件、网络和安全约束的实际功能：电动汽车的充电盖管理。该示例展示了如何以功能为驱动，从范围界定和需求分析，到架构分配、仿真和生产代码生成，全程保持可追溯性。.

挡板管理系统控制车辆的充电口挡板（图 1）。它持续协调物理环境（例如，位置传感、执行器状态和锁止/锁定反馈）与充电环境（例如，车辆状态、车载充电器状态和充电站信号），以决定挡板何时可以打开、必须关闭或应该锁定。然后，系统向驾驶员和其他车辆功能发布状态更新和警告。通过涵盖传感、执行和 ECU 协调，挡板管理系统为更广泛的 SDV 分布式功能开发提供了一个虽小但实用的模型。.

图 1. 车辆充电入口挡板。.

功能范围界定

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

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

在此阶段，我们进行影响分析，并使用 System Composer™ 生成功能边界图，该图捕捉了受襟翼管理影响的功能以及这些功能之间交换的信息。边界视图清晰地展示了哪些车辆功能和外部参与者与襟翼管理功能交互，以及交换哪些信息（图 2）。.

图 2. 特征边界图。.

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

图 3. 用例图。.

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

图 4. 显示充电盖操作的活动图。.

基于之前的分析和图表，我们现在可以使用需求编辑器（Requirement Editor，隶属于 Requirements Toolbox™，如图 5 所示）创建系统级需求。我们有一些与操作相关的需求，例如打开和关闭挡板以及通知挡板状态。.

图 5. 需求编辑器中的系统级需求。.

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

• 系统功能： 共同实现该特性的技术功能单元
• 互动： 这些功能如何相互沟通和协作

根据系统需求分析，我们将充电翻盖功能分解为四个功能（图 6）：

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

图 6. 功能架构。.

作为功能架构定义的一部分，我们将每个系统需求分配给负责实现该需求的函数，并在相关情况下分配给承载所需信息的交互。这种分配确保每个需求都得到设计元素的覆盖，使需求间的差距/重叠尽早显现，并为下游逻辑/物理设计和验证提供从需求到函数的可追溯性。实际上，可以通过将需求拖放到系统配置器组件上来高效地完成此分配（图 7）。.

图 7. 系统需求到功能架构的分配。.

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

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

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

图 8. 平台无关架构的详细视图。.

平台相关系统架构

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

一旦我们确定了不同的组件，我们就可以在 System Composer 中创建系统架构图，该图突出显示组件边界以及组件必须交换的信息才能实现襟翼管理功能（图 9）。.

图 9. 系统架构图。.

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

基于系统需求和系统架构，我们推导出每个ECU的软件需求和架构（高性能计算、区域、边缘），并将其细化为可部署的软件组件。在高性能计算层面，功能被分解为服务和应用程序（例如，AUTOSAR Adaptive，如适用），而区域/边缘节点则承载时间关键型传感/执行功能（例如，AUTOSAR Classic或等效软件）。接口（服务、信号和数据类型）从物理架构一致地传递到软件端口和连接器，从而能够在目标硬件可用之前，实现早期一致性检查、可执行行为建模以及仿真钩子（用于军用/安全完整性等级测试和闭环运行）的集成。.

首先，我们创建 HPC、区域 ECU 和边缘 ECU 组合的顶层软件架构，这些架构与系统架构相连（图 10）。.

图 10. 顶层软件架构视图。.

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

图 11. HPC 软件组件视图。.

一旦我们完成了三个ECU上该功能的实现建模，就可以创建一个闭环仿真模型，将这些ECU连接到襟翼的系统模型（包括电流传感器、位置传感器和执行器的模型），从而能够在实际工况下快速验证其功能行为。例如，我们可以使用仿真来评估系统在不同车速下对用户打开襟翼请求的响应情况（图12）。.

图 12. 充电襟翼的闭环仿真。.

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

图 13. 拍动请求仲裁器软件的 C++ 生产代码生成。.

此外，当引入新需求时，可以在系统需求层面捕获该需求，并进行影响分析以识别受影响的元素。由此产生的变更将被可视化并传播到相关的系统和软件接口，之后工作流程将迭代以适应不断变化的需求。这一过程通过端到端的可追溯性来实现，利用可追溯性图（图 14）来管理整个软件开发版本 (SDV) 开发生命周期中的动态变更。.

图 14. 可追溯性图，突出显示不同层面的影响。.

遗留应用程序的迁移

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

结论

将基于模型的系统工程和基于模型的设计相结合，为软件定义验证 (SDV) 功能开发提供了一个实用且端到端的工作流程，从而能够更清晰地展现系统意图，更早地通过仿真进行验证，并生成可部署的软件制品。这种方法以功能为导向，并构建了可追溯性，确保所有设计阶段的工程决策从意图到部署保持一致。其优势显而易见：该工作流程能够加快迭代速度，减少后期集成过程中可能出现的意外情况，并在异构 ECU 和混合 SOA/信号架构中实现更一致的实现。.

随着业界探索人工智能驱动的开发方法（包括新兴的智能体人工智能方法），传统工程实践的作用也日益受到质疑。在这种新背景下，基于模型的系统工程和基于模型的设计方法的价值更加凸显：在人与人工智能日益协作的开发循环中，这些方法能够提供必要的严谨性，从而明确需求、阐明系统意图，并确保架构、行为和验证保持一致。这使得它们成为交付创新、可靠且易于维护的软件开发验证（SDV）软件的关键基础。.

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

使用的产品

• 系统组合器
• AUTOSAR 块集
• Simulink 要求
• 嵌入式编码员

 

作者