自动驾驶和半自动驾驶汽车的验证和确认相关的工程挑战和机遇

这是一系列文章中的第五部分，也是最后一部分，这些文章讨论了与自动驾驶和半自动驾驶汽车的验证和确认相关的工程挑战和机遇。

第 V 部分：设计感知型 V&V

到目前为止，本系列已经讨论了跨工作流程的测试重用、XIL 测试台中可扩展保真度的价值，以及与车辆电气/电子 （E/E） 系统开发相关的关键验证和确认 （V&V） 任务的生成式模型驱动开发 （MDD） 工作流程解决方案。有趣的是，这些挑战的解决方案提出了另一组全新的挑战，这反过来又需要额外的解决方案。

本文 讨论 的 每 个 V&V 解决 方案 的 核心 是 建模 概念， 它 将 抽象 级别 提升 到 E/ E 系统 领域， 从而 允许 工具 从 设计 输入 基础 生成 最佳 产品 实现。然而，提高抽象级别意味着工具生成实现的专家设计对车辆功能开发人员来说或多或少是陌生的。这给V&V带来了挑战，因为验证工具非常擅长在技术实现层面提取信息并支持激励，但不适用于E/E系统的设计级别，也不是验证工程师理解系统的级别。这类似于现代C++编译器如何生成非常安全、高性能的代码，但试图使用反汇编器调试和分析系统的C++程序员将不可避免地面临挑战。

幸运的是，出于与自动生成MDD工作流程相同的原因，支持设计级别调试和分析的MDD验证环境也是可能的。解决方案在于设计输入模型符合并以其他方式描述的元模型。生成工具使用正式的设计模型描述，以及其元模型中体现的形式语义的知识，以便将设计模型转换为映射的实现模型。这种映射是对称的，因为它也可用于将实现模型中的信息（及其执行跟踪中的信息）交叉关联回设计模型中的相应信息。

这种引用用于创建“设计感知”的V&V工具。设计意识的概念是通用的，可以应用于设计的不同领域概念，例如架构、测试和/或语言;它也可以或多或少地更深入地应用于实现的配置中，例如在 MDDRTOS（内核）、平台服务中，甚至在软件界面中。

例如，“AUTOSAR-aware”V&V工具允许开发人员在描述ECU中嵌入式软件内容的AUTOSAR架构模型环境中调试和分析E/E系统。对于调试，验证工程师可以在AUTOSAR元素（如软件组件或端口接口）上设置“断点”，然后当这些元素的上下文中发生活动时，系统将停止，从而允许验证工程师检查端口内的数据和组件的内部。为了进行分析，AUTOSAR 感知代理可以在 AUTOSAR 模型和基本软件 （BSW） 配置元素（如任务和网络信号）的上下文中呈现在执行数字孪生期间收集的系统跟踪。

总之，在汽车市场快速发展趋势的推动下，可扩展保真度、测试重用、生成式工作流程和设计感知型V&V工具解决方案相结合，帮助验证工程师有效地验证和验证车辆E/E系统。有效 V&V 的主要 商业 价值 是：

问题可以在汽车设计开发过程的早期发现，此时修复成本最低

增加 V&V 覆盖范围 可 提高 安全性、 增强 安全性 以及 在 将 问题 部署 到 现场 之前 发现 问题

测试 包括 混合 保真 测试 台， 可 支持 多 ECU 系统 所需 的 大量 V&V 周期

测试用例在整个开发过程中重复使用

OEM 和供应商高效交换测试用例和测试台

降低培训成本

验证工程师可以在最好的测试自动化软件和最好的测试台之间切换

在工具中捕获的实施领域专业知识可提高质量并减少未来问题

可以消除手动或其他重复性工作，以加快上市时间

验证和设计工程师可以在设计它们的领域级别生成产品实现

审核编辑：郭婷