自动驾驶新型验证技术(三):基于仿真HARA方法

危害分析与风险评估（HARA）是ISO 26262 标准概念阶段的必要环节，该环节普遍存在客观性不足、可重复性差的问题。

为改善这些缺陷，本文提出一种基于整车级仿真器的全新方法。

HARA是确定产品在运行过程中可能面临的危害、评估其风险等级的关键步骤。如文章“第一部分”2.2.2节所述，针对每项危害，必须确定三个风险参数：严重度（S）、暴露度（E）、可控性（C）。确定这些参数后，需为每个安全目标分配汽车安全完整性等级（ASIL），并针对每个安全目标，考虑其失效可能导致人员面临的最严重危害。

搭载高级驾驶辅助系统（ADAS）的车辆，与自动驾驶、半自动驾驶车辆一样，可归为自主智能系统（A/IS），因此其测试难度远高于传统车辆。

一方面，需要测试感知系统是否能以足够的精度和环境感知能力准确感知外部世界。另一方面，负责安全相关决策的算法通常采用机器学习（ML）方法开发，这使其不具备完全确定性。例如基于计算机视觉的障碍物识别神经网络，其输出并非唯一正确值，而是一组略有差异但均合理的结果。这让单元测试（见文章“第一部分”2.11.4节）的执行变得困难，甚至无法实现。此时，测试通过的标准应是系统行为能保证车辆处于安全状态，否则判定为不通过。

仅满足 ISO 26262 标准的要求并不足够：该标准仅考虑功能安全，还需验证无故障标称行为对应的风险等级。为帮助安全工程师应对非确定性策略，见文章“第一部分”1.9节和1.10节已介绍，另外两项标准已发布：ISO/PAS 21448（预期功能安全，SOTIF）和UL 4600。

SOTIF 标准用于解决因系统在需求定义阶段未预见的场景、神经网络未训练的场景导致的非确定性输出引发的危险行为。其他失效来源还包括传感器老化、人机界面（HMI）设计不当或用户对系统过度信任。UL 4600 标准则更详细地描述了如何构建尽可能完整的安全案例。

ADAS系统复杂度的不断提升，让HARA的实施难度越来越大。这类系统需要高性能电子控制单元（ECU）和复杂软件实现功能。

为正常工作，ADAS需通过高速车载网络，以及各类传感器、执行器，与驾驶员、环境和其他车辆功能交互。因此，其实现的复杂行为在失效时的后果难以按功能安全标准的要求识别和分类。

本章提出的方法旨在：

· 结合风险参数分类表（当前提升HARA可靠性的主流方法）与仿真结果，提高风险评估过程的客观性；

· 借助整车级仿真器降低分析对安全工程师经验的依赖，提升整个HARA流程的可重复性。

为演示、验证并更清晰地阐述该方法，本文将其应用于一个经典工业案例，采用与道路测试中同类产品验证相同的测试方案进行仿真。下文将说明，该案例为高级紧急制动系统（AEBS）。

本部分剩余内容结构如下：4.1节介绍文章“第一部分”2.2.2节未覆盖的相关技术现状与本研究的创新点；4.3节讨论AEBS基准测试结果；4.4节展示仿真结果。

与基于仿真的FMEDA方法的结论一致，相关总结见本文最后一节的6.2节。

4.1 技术现状

在介绍本方法依托的相关文献前，有必要先给出通用ADAS设备模型。这类系统由以下部分组成：

· 感知系统（传感器）；

· 数据融合（DF）算法：将所有传感器的信息整合为统一、连贯的外部环境虚拟表征；

· 逻辑算法：基于外部环境虚拟表征做出合理响应；

· 执行器：将逻辑算法的响应物理作用于实际环境。

该典型结构如图4.1所示：

HARA 的核心问题在于有效性（可重复性）和可靠性（客观性）。

如文章“第一部分”2.2.2节所述，HARA分为五个阶段，如图4.2所示：

图4.1：ADAS设备的结构框图

图4.2：HARA的各个阶段，并指出了可以通过基于模拟的方法执行的阶段

1. 场景分析与危害识别（SA/HI）；

2. 危害分类（HC）；

3. ASIL等级确定；

4. 安全目标定义；

5. 评审。

4.1.1 研究贡献

文献已提出结构化方法，用于提升HARA分析的有效性（可重复性）和可靠性（客观性）。尽管两种方法思路不同，但目标一致：降低分析对安全工程师专业背景的依赖，提升HARA的可重复性与客观性。

整车级仿真器已在汽车行业用于软件验证。市面上有多种商用工具可辅助概念阶段开发，如IPG CarMaker™、AVL™车辆仿真器（VSM™）、FEV™VirtualDynamics™，以及用于自动驾驶研究的开源仿真器CARLA ，其支持Scenic语言建模并生成静态场景。

本文的创新点集中在如何通过仿真方法辅助前三个阶段（SA/HI、HC和ASIL等级确定）。

在SA/HI阶段，研究表明：由于只有执行器能直接作用于环境，获取系统适用危害清单的有效方法是分析执行器级的异常行为，无论中间环节是否引发故障。基于该假设，即便系统仅定义了行为级模型，也可开展仿真。文献提出了类似的基于系统高层描述的分析方法，感兴趣的读者可参考。

在HC阶段，上述所有文献均采用风险参数分类表。该表将仿真得到的关键物理量数值范围，与ISO 26262风险参数等级（严重度见文章“第一部分”表2.3、可控性见文章“第一部分”表2.4）对应，并针对具体应用特点调整分类规则。本文也采用该方法，将仿真结果与分类表的数值范围对比。

该方法已为后续研究提供参考：文献将本方法作为确定架构与设计需求的方案，确保系统在故障传播时保持安全状态，尤其适用于关键信号受错误值影响的场景。

此外，《基于机器学习系统的安全保障方法综述》将本方法列为通过整车级仿真器执行HARA的解决方案，用于验证初始规格；SAE技术论文则将其纳入自动驾驶车辆安全分析与验证框架，用于识别 SOTIF 触发事件（见文章“第一部分”图1.9）。

4.2 提出的方法

本方法源于文献提出的基于仿真的FMEDA方法。

这两种方法均通过仿真辅助FMEDA分析：前者在系统边界内仿真故障，后者描述如何将异常行为从系统输出端传播至整车。

FMEDA在硬件设计阶段结束后执行，用于验证设计原理图是否满足可靠性要求，该要求由系统可能因随机硬件故障违反的安全目标中最严格的ASIL等级决定。

本方法的框图如图4.3所示，同时可与文章“第一部分”2.2.2节介绍的HARA阶段（图4.2）对应，对应关系叠加在框图中如图4.4所示。

图4.3：拟议方法的框图表示

图4.4：所提出方法的框图表示，其中HARA阶段映射到其块

4.2.1 场景分析与危害识别

第一阶段为场景分析与危害识别（SA/HI）。其中场景分析（SA）子阶段通过搭建适配仿真器的多种场景完成；通过行为级模型仿真系统在标称（无故障）状态下的车辆行为，结果存入仿真结果数据库。这些结果可辅助场景分析，帮助安全工程师设想并补充车辆生命周期中可能出现、但尚未考虑的新场景。

同时，这些信息可用于危害分类（HC）阶段，定义基于无故障与故障状态行为差异的分类规则。感兴趣的读者可参考文章“第二部分”3.9节，该节采用基于差异的规则加速FMEDA分析。

4.2.2 危害分类

需要强调的是，HARA在概念阶段完成，此时系统尚未设计完成。由于缺少原理图，无法准确获知（组件故障模式对应的）具体失效形式，也无法确定随机硬件故障发生时的实际行为。

借助系统的行为级模型和整车级仿真器，可评估部分失效（可描述系统失效行为的失效）对车辆的最坏影响，进而评估其严重度。失效由故障注入器根据故障描述指令注入。

同时，通过分析失效对车辆加速度和轨迹的影响，可评估普通驾驶员缓解失效后果的能力，辅助可控性评估。

文献提出了类似方法，以电动助力转向系统为基准案例，评估可控性。

危害分类通过将仿真结果与严重度、可控性风险参数分类表对比完成。如图4.3、4.4所示，这些分类表属于整车级分类规则。

4.2.3 ASIL等级确定

完成风险参数分类后，可初步为危害分配ASIL等级。随后人工将危害与安全目标失效关联，最终依据关联的最危险危害，为安全目标分配ASIL等级。

ASIL等级通过ASIL判定矩阵结合S、C、E三个风险参数确定，矩阵见文章“第一部分”图2.5。

4.2.4 安全目标定义

该阶段由人工完成，定义安全目标并与危害关联，对应图4.3、4.4中的危害/安全目标关联环节。

4.2.5 评审

评审阶段完全由人工完成。ISO 26262标准的确认措施（见文章“第一部分”2.1.3 节）要求，该阶段需由未参与HARA执行的其他安全工程师完成。

4.2.6 总结

本方法的核心要点如下：

· 依托整车级仿真器模拟不同驾驶场景与环境，基于仿真场景开展危害分析；

· 借助仿真结果 ** decouple安全工程师经验与最终评估结果**，提升结果客观性；

· 依托半形式化模型和仿真结果的确定性，获取数值指标，提升严重度、可控性评估的可重复性。

从实现角度，搭建适配本方法的环境需包含以下最小组件集（见图4.3）：

· 待评估系统（本文为ADAS）的行为级模型；

· 整车级仿真器；

· 被测车辆（VUT）模型；

· 实现ADAS模型与整车仿真器通信的软件层；

· 以仿真器兼容格式存储的半形式化场景集；

· 系统可能失效的半形式化行为描述；

· 整车级分类规则（本文以严重度、可控性分类表形式体现）。

4.3 基准案例

4.3.1 AEBS及其车辆集成

高级紧急制动系统（AEBS）用于降低碰撞风险，其功能基于传感器（通常为雷达）测量车辆与前方最近障碍物的距离。

AEBS可独立工作（通常适用于城市道路车速＜60km/h），也可与巡航控制系统结合，全车速范围辅助驾驶员保持安全车距。

独立工作时，AEBS先向驾驶员发出视觉、声音报警；若驾驶员无响应，则执行紧急制动。

普通巡航控制系统（CCS）可维持驾驶员设定的恒定车速，无需驾驶员操控油门；驾驶员踩下制动或离合踏板时，CCS暂停，不再输出扭矩请求。更复杂的**自适应巡航控制系统（ACCS）**可自动调整车速设定，保持与前车的安全距离。ACCS的制动要求定义在ISO 15622标准中。ACCS不负责安全保障，仅作为舒适功能，其唯一安全要求与解除功能相关，通常归类为ASIL C。

本文基准案例中，整车仿真器生成最近障碍物距离测量值，并接收ADAS模型请求的制动力；驾驶员行为包含在场景文件中，所有物理仿真由整车仿真器完成。

4.3.2 故障模型

执行故障注入需要故障模型。由于本文研究的系统仍处于概念阶段，无法描述详细故障模型，仅能提供行为级故障描述。本文中，系统异常行为定义为完全丧失制动功能且不向驾驶员发出任何报警。

4.3.3 提出的方法

场景分析与危害识别

方法第一阶段（对应SA/HI）搭建整车仿真器+ ACC/AEBS行为半形式化模型系统。

本文以AEBS标准测试为基础搭建场景：这类系统的道路测试方案来自欧洲新车安全评鉴协会（EuroNCAP）、美国国家公路交通安全管理局（NHTSA）和欧盟委员会，均提供典型驾驶场景（运行场景）描述。

同时，搭建可在仿真环境中实现功能的系统行为级模型，必要时可添加故障注入功能（类似文章“第二部分”3.6.1节的破坏模块）。本文仅考虑一种异常行为：系统完全丧失制动功能，通过强制制动力请求为0实现注入。

首先执行无故障状态的批量仿真，由整车仿真器与 ADAS 模型协同完成。若需通过与标称行为对比实现分类规则，该结果可用于危害分类阶段。本文基准案例未使用该分类规则。

危害分类

第二阶段为危害分类（HC），通过仿真得到的车辆行为，将仿真结果与分类表对比，评估严重度和可控性风险参数。分类表的准备为人工操作，车辆级分类规则的应用由分类器依据表4.1、4.2自动完成。

分类表：本文基于文献，针对ACC/AEBS系统调整分类规则，仅考虑同向行驶车辆的场景。

相对车速与严重度的对应关系总结于表4.1。

表4.1：严重性分类规则

可控性以 ** 碰撞时间（TTC）** 为分类参数，考虑驾驶员误用紧急制动功能的场景（过度依赖系统、未观察前车状态）。

相关规则总结于表4.2。

表4.2：严重性分类规则

本文认为暴露度风险参数无法通过仿真方法评估，需人工为每个场景分配数值。

ASIL 等级确定

通过仿真结果与分类表数值对比完成所有风险参数评估后，可通过ASIL判定矩阵（文章“第二部分”图2.5）确定ASIL等级。

该ASIL等级随后人工关联至对应危害。

安全目标定义

本文案例仅考虑一个安全目标：ACC/AEBS 在车辆前方有障碍物时执行制动。与该安全目标关联的危害为：驾驶员过度依赖系统导致追尾前车。

本文未分析系统意外制动对应的安全目标。

4.4 仿真结果

本章数据的仿真系统组成如下：

· 整车仿真器（IPG Automotive Carmaker）；

· 中型轿车模型；

· ACC/AEBS半形式化模型（MathWorks Simulink），支持强制制动力请求为0；

· 分类器：从仿真日志提取碰撞时两车相对车速、碰撞时间（TTC），并依据表4.1、4.2的分类表，分配严重度（见文章“第一部分”表2.3）、可控性等级（见文章“第一部分”表2.4）。

MathWorks Simulink与IPG Automotive CarMaker的通信无需额外开发软件层，软件自带商用库支持。

本文AEBS测试的所有场景均可由图4.5表示：两车同向直行，被测车辆（VUT）搭载目标系统，目标车辆（TV）在前方作为障碍物。场景差异如下：

· 仿真起始时两车距离；

· 仿真起始时两车车速vvut、vtv；

· 目标车辆制动加速度函数atv(t)。

图4.5：所有场景中分析的情况的表示

严重度评估依据碰撞时两车相对车速；可控性依据测试描述的危险状态开始至碰撞的时间间隔（即碰撞时间 TTC）。

系统以半形式化行为模型表示，无故障模型可满足标准要求，故障模型完全丧失制动能力。

仿真中驾驶员不执行任何制动操作，仅AEBS可避免碰撞；驾驶员的速度、轨迹行为在测试用例中定义。所有场景下，无故障基准模型均可避免碰撞。

4.4.1 EuroNCAP AEBS 测试协议

2017年修订的EuroNCAP测试协议规定两种测试流程：

· 城市道路 AEBS（AEB City）：计入成年乘员保护评分；

· 城际道路 AEBS（AEB Inter-Urban）：计入安全辅助评分。

包含三种场景：

1. 前车静止（CCRs）被测车辆（VUT）与目标车辆（TV）间距120m，TV静止；VUT起始车速分别为 50km/h、80km/h。

2. 前车行驶（CCRm）VUT与TV车速均在50~80km/h范围，测试以50km/h起始，按5km/h步长递增至80km/h；本文仅仿真50km/h工况。

3. 前车制动（CCRb）VUT与TV初始车速均为50km/h，TV以2m/s²、6m/s²两种减速度制动，所有组合均执行仿真。TV以6m/s²减速度制动的两种工况下，相对距离随时间变化曲线如图4.6、4.7所示（除初始距离、碰撞时间外，所有案例行为相似）。

图4.6：CCRb场景（初始间距12 m，目标车减速度6 m/s²）下被测车辆（VUT）与目标车辆（TV）的相对距离随时间变化曲线。相对距离曲线与时间轴的交点代表碰撞时间（TTC）

图4.7：CCRb场景（初始间距40 m，目标车减速度6 m/s²）下被测车辆（VUT）与目标车辆（TV）的相对距离随时间变化曲线。相对距离曲线与时间轴的交点代表碰撞时间（TTC）

测试协议还规定了前向碰撞报警（FCW）功能的验证方法，本文不涉及该功能。

结果如表4.3所示。

表4.3：EuroNCAP情景下的模拟结果

4.4.2 NHTSA 测试

该测试发布于1999年，用于验证原型ACC系统，主要用于表征整套原型系统（传感器、数据融合、控制算法、车辆平台）。

测试包含以下场景：

· 测试1（车距控制模式）：长距离接近前车，VUT车速112.7km/h，TV车速96.5km/h；

· 测试2（超车中止）：近距离接近前车，VUT初始车速96.7km/h，TV全程保持96.7km/h；VUT与TV间距37.5m时，驾驶员加速至112.7km/h；间距减小至原1/3时，驾驶员松开油门，测试持续至系统恢复稳态。

结果如表4.4所示。

表4.4：NHTSA情景下的模拟结果

4.4.3 欧盟委员会347/2012法规测试

该三项测试来自欧盟委员会347/2012法规，为欧盟AEBS强制认证测试。

三项测试如下：

· 测试1：VUT以80±2km/h撞击静止目标车辆；

· 测试2：VUT以80±2km/h撞击以32±2km/h行驶的目标车辆；

· 测试3：VUT以80±2km/h撞击以12±2km/h行驶的目标车辆。

所有测试中，VUT与TV初始间距至少120m，本文统一设为120m。

结果如表4.5所示。

表4.5：NHTSA情景下的模拟结果

4.4.4 ASIL等级分配

获取仿真数据后，所有结果汇总于表4.6。

表4.6：各种测试的ASIL分类

从ASIL分配结果可见，大部分场景为ASIL B。

唯一分类不同的场景是EuroNCAP CCRb（VUT与TV初始间距12m、TV减速度6m/s²）。

该场景可视为系统被误用：驾驶员刻意踩油门，迫使车辆不保持安全车距。

典型AEBS仅辅助驾驶员，不负责驾驶安全（见文章“第一部分”1.2.2节），因此无法覆盖驾驶员决策。

为避免此类误用，可在人机界面（HMI）中增加策略，如驾驶员行为导致无法保持安全车距时发出声音报警，提醒驾驶员放弃危险操作。

基于上述前提，为安全目标ACC/AEBS在车辆前方有障碍物时执行制动分配ASIL B等级是合理的。

如方法所述，暴露度风险参数由人工评估。

若要将暴露度从E4降低，需提供统计证据证明该场景不常见；本文所有场景概率均较高，因此最合理的选择是分配E4等级，无需额外统计证据。

本章介绍的所有实时软件验证方法均基于**硬件在环（HIL）**技术。

HIL是一种软件集成验证技术，通过将实时仿真系统（运行物理模型）与控制器（目标设备）经收发器连接，生成与实际环境电气特性完全一致的信号，实现对目标设备嵌入式软件的测试，同时验证时序与设备驱动交互。文章“第一部分”2.11.5节已详细介绍HIL技术。

通过该方法，可在目标设备上测试嵌入式软件，兼顾时序要求与所需设备驱动的交互。

本章成果按主题分为三类：

1. 车身控制模块（BCM）测试：与企业合作开发新软件工具，简化具备CAN总线、大量低速I/O的系统的HIL测试；

2. 混合关键度实时应用测试：针对最低设计保障等级（DAL，对应DO-178B/C标准安全等级）应用中植入固有缺陷，或通过调试器注入故障（注入时暂停/恢复实时仿真，避免干扰实时仿真）的场景；该方法描述了混合关键度系统（MCS）的HIL验证方案，将HIL测试与故障注入结合，验证标称应用的安全性，以及软硬件实现的故障检测、隔离与恢复（FDIR）机制。

3. 多智能体机器人系统（MAS）测试：这类机器人的末端执行器由多个独立智能体驱动，智能体间无实时可靠通信，需仅依靠内部时钟保持同步。

5.0.1 研究贡献

本研究的创新点并非HIL方法本身，而在于应用场景。

多智能体机器人系统（MAS）看似与汽车行业传统范式无关，但网联车辆（与电动化、自动驾驶并列的三大行业挑战）的发展使其成为研究热点。在汽车应用中，其他智能体可为其他车辆、携带手机的行人（车车通信V2V）或交通信号灯等基础设施（车路通信V2I）。可实现多种协作等级：与行人手机通信仅辅助自动驾驶障碍物检测算法（突破长距雷达限制），与其他车辆通信可优化路口通行效率，或为应急车辆让行。

由于难以获取工业级应用案例，结合课题组研究方向（功能安全、实时系统开发与验证），本文选择将HIL应用于硬实时机器人应用的软件验证。该应用从功能安全需求角度，可类比车辆在路口的协同通行：保证低速安全通过、不停车，同时满足碰撞风险的安全要求。

5.1 车身控制模块

本文方法于2018年在IEEE第13 届纳米时代集成系统设计与技术国际会议上发表，为与TXT E-Solution公司合作的技术转化项目。

项目目标：

· 增加CAN总线通信的协议层与HMI支持；

· 从专用TXT XHIL硬件移植至NI PXI平台。

现代车辆由电子控制单元（ECU）管理，ECU运行数百万行代码，实现从乘员舒适（如空调）到安全（如ABS、ESP、ADAS）的各类功能。为保证汽车嵌入式软件质量，ISO 26262 标准定义了严格的开发与验证流程（见文章“第一部分”2.11 节），需按汽车行业最新实践完成所有环节。

ISO 26262标准的多个步骤中，软件测试是最成熟的环节之一，要求在产品交付整车厂前执行多项测试，发现与预期功能的偏差。

从输入/输出需求与功能数量看，**车身控制模块（BCM）**是最复杂的ECU之一。BCM 实现多种功能：读取离散输入（如转向灯、点火钥匙）、驱动离散输出（如车窗除雾、雨刮），并通过CAN、LIN、FlexRay等总线通信。典型BCM包含约100路I/O、2~3路CAN总线，软件实现超100项功能。一级供应商测试BCM的常规流程见文献。采购具备足够I/O的HIL硬件连接ECU后，首先搭建测试环境，配置HIL硬件配套软件，使其与被测 ECU（DUT/BCM）正常通信；随后依据系统规格开发测试用例。

该过程涉及两类专业人员：

· 工具工程师：精通HIL硬件配置与配套软件；

· 测试工程师：负责编写DUT测试用例、分析输出响应。

当前BCM测试的HIL方案分为两类：

1. 低端HIL方案（静态仿真器）：通过开关、旋钮、网络仿真器经转接盒连接BCM，输出接指示灯、表盘；测试人员手动按用例施加激励，手动观察、评估输出。该方案缺乏确定性：手动操作无法重复测试，且无法自动化；但目前仍有部分一级供应商使用。

2. 高端HIL方案：采用专用可重构硬件自动连接BCM、执行测试用例、采集输出。该方案支持自动化、具备确定性，但硬件复杂度高，需工具工程师与测试工程师配合。此外，常规HIL工具主要面向控制算法实时验证，而非BCM这类有限状态机（FMS）软件，提供大量非必要功能，增加测试用例开发难度。

5.1.1 提出的方法

本方法的核心目标是开发贴近BCM 测试人员技能与经验的软件测试工具（XHIL Studio），其操作逻辑与高端HIL工具差异显著。

就HIL而言，dSpace、NI、ETAS等供应商均提供商用可重构硬件平台与软件环境，主要用于快速控制原型与HIL测试，重点验证新开发嵌入式软件的实时性。这类硬件性能接近高端服务器，可实时运行复杂整车、发动机模型；配套软件主要支持验证测试用例开发，通常由控制软件开发者自行完成。

本文采用完全不同的思路：

· HIL硬件与配套软件作为可重构接口，连接运行测试软件的BCM（或简化ECU）；仅负责电气接口与网络连接，不运行复杂整车模型（可扩展支持）；实时运行BCM模型，抽象BCM硬件I/O，以逻辑通道形式暴露给配套软件；

· HIL 操作软件提供简化界面，实现逻辑I/O通道与测试人员友好对象（按钮、表盘、图表）的映射；测试人员通过对象搭建测试面板、编写测试序列（记录操作并自动回放）；测试序列部署至测试平台，采集响应并与预期（快照）对比，生成测试报告。

该方法的两大优势：

· 高灵活性：可重构HIL系统，轻松适配不同BCM；

· 高易用性：测试人员无需精通高端HIL操作，沿用低端方案的操作习惯。

本方法涉及测试人员与七层结构：

1. 测试人员：执行测试；

2. 工具HMI：供测试人员编写、运行测试用例，采集输出；

3. 硬件抽象层（HAL）：衔接HMI与配套软件，将HMI操作转换为HIL硬件指令并下发；

4. 配套软件：运行在主机PC，管理主机与HIL硬件的通信；

5. BCM模型：抽象ECU I/O结构，包含两部分：一是Microsoft Excel表格，记录HIL硬件I/O、电压电平与标识；二是Simulink模型，左侧为与表格同名的输入/输出端口，右侧连接测试平台。该设计兼容任意HIL软件环境，支持X在环（XIL）测试；

6. HIL硬件：运行车辆模型（本文BCM不涉及车辆动力学），按测试人员指令施加激励，通过HMI返回响应；

7. 转接盒：实现HIL与BCM硬件的物理接线；

8. 被测设备（DUT）：运行测试软件的ECU。

5.1.2 基准验证平台

本节介绍本方法的验证实现。

测试人员通过TXT XHIL Studio操作HMI，该界面专为BCM软件集成测试的用例开发、执行设计，操作友好。

XHIL Studio提供编辑器供测试人员开发测试用例，编辑器如图5.2所示，包含：

· 仿真面板列表：管理多组测试用例；

· 工具箱面板：包含可搭建测试用例的控件（widget），支持离散 I/O 信号与网络消息；

· 仿真面板编辑器：测试人员拖拽控件搭建面板；

· ECU 输入/输出列表、属性、网络（CAN）消息库。

图5.1：ECU Simulink™模型，描述了从HMI到可重构硬件逻辑资源的映射。在三个灰色区域的顶部，报告了输入/输出标签的来源

图5.2:TXT XHIL Studio模拟编辑器

测试人员完成仿真面板设计后，可通过仿真播放器操作（见图5.3）。

图5.3:TXT XHIL Studio模拟播放器

测试人员通过播放器定义DUT激励（操作控件）、预期正确响应（截取满足需求的状态快照）；操作序列可记录并回放，实现自动测试。记录的测试序列部署至测试平台，采集响应并与预期（快照）对比。

最终生成测试报告，标注实际输出与预期输出的偏差。

HMI通过HAL与测试平台通信，本文实现中HAL管理NI硬件与配套软件（NI VeriStand）的通信；通过VeriStand API提供两项服务：执行API控制HIL硬件，实时序列定义API实现激励生成自动化。硬件驱动通过 VeriStand 网关实现，经LAN连接主机与HIL硬件。XHIL Studio与NI VeriStand API的交互如图5.4所示。

图5.4:TXT XHIL Studio和NI VeriStand API之间的交互

基准DUT采用意大利一级供应商提供的商用BCM：72路模拟输入、80路模拟输出、4路数字输出、2路CAN总线，实现超120项功能，包含约1200个C函数、30万行C代码。

出于知识产权保护，公开展示时采用简化ECU：基于NXP S32K144开发板实现转向灯控制软件，支持CAN通信。该平台于2017年11月在米兰 NI 技术日展示，如图5.5所示。

图5.5:在恩智浦S32K144参考板上实施转向灯控制软件的简化ECU上进行了拟议方法的基准测试

HIL硬件采用NI PXI，运行VeriStand引擎实时执行ECU模型；PXI搭载Intel Core i7多核CPU，基于PXI总线的模块化架构可轻松匹配ECU的I/O需求。离散信号经转接盒连接BCM，CAN总线采用NI XNET线缆。

5.2 混合关键度系统

现代飞行器由电子控制单元（ECU）管理多个进程。无人机（UAV）设计面临特殊挑战：出于周边人员安全与机体成本考虑，厂商必须保证航电 ECU 的可靠性。

为保证ECU软件满足硬实时性能要求，学界提出多种计算进程最坏执行时间（WCET）的方法。但飞行器中并非所有软件组件对任务安全或成功的关键程度相同，该差异在DO-178B/C标准中通过 ** 设计保障等级（DAL）** 体现，与ISO 26262的ASIL等级（见文章“第一部分”2.2.2节）类似。

过去，认证机构要求同一硬件上运行的所有应用均按最高DAL开发。为避免按最高DAL（A级）开发的成本，航电原始设备制造商采用分布式架构（联邦架构），近年逐步过渡至综合模块化航电（IMA）。

为减小这类架构的体积、重量与功耗（SWaP），混合关键度应用是可行方案。但混合关键度应用开发需解决不同DAL软件共享处理单元的问题，必须采取特殊措施，避免低DAL应用失效干扰高DAL应用，引发灾难性后果。

学界已提出多种混合关键度系统（MCS）实现方案，部分聚焦系统架构，部分聚焦核心的调度问题 。但无论采用何种方案，开发者均需验证方案的安全性，这对MCS尤为重要：低DAL软件组件可能存在缺陷，激活后干扰高DAL组件的执行。

学界针对该问题提出多种方案，按干扰类型分为两类：

· 时间干扰：一个软件组件改变其他组件的执行时间，可能导致实时安全关键任务错过截止时间；

· 空间干扰：一个软件组件修改内存、外设等资源，影响其他组件正常运行。

已有多种避免干扰的方案，称为分区方法。文献将分区定义为“恢复强故障隔离的软硬件机制”。当前主流趋势是采用系统调度理论解决该问题。

问题进一步复杂化：非高DAL开发的软件组件无法通过形式化验证证明无缺陷，因此必须采用功能测试，选择最可能的场景子集在目标平台测试分区效果。航电应用的特性与 WCET 对硬件架构的强依赖，决定了只有在目标平台实时运行软件时，才能获得可靠结果。

执行此类集成测试的核心技术是硬件在环（HIL），已在文章“第一部分”2.11.5 节介绍。本方法应用于基准MCS，通过实验验证HIL可检测故障（本文为安全关键任务错过截止时间）或证明容错性：验证分区机制可防止低DAL任务或随机硬件瞬时故障干扰关键高DAL任务，分析其对无人机控制指令的影响。

5.2.1 提出的方法

本方法要求基准系统具备以下能力：

· 实时模拟物理系统；

· 生成与物理系统电气特性一致的激励，输入至DUT；

· 记录物理系统模型生成的激励与DUT响应，保证测试可重复；

· 检查DUT控制软件是否满足功能需求，验证实现正确性；

· 触发低DAL任务的固有缺陷，或向DUT执行故障注入；

· 故障注入时暂停物理系统仿真，注入完成后安全恢复；

· 处理测试数据，生成可读测试报告。

实现所有需求需以下组件：

1. DUT控制器：负责控制物理系统的安全关键模块；

2. DUT非关键任务：可能干扰关键任务的低DAL软件组件；

3. 物理系统固定步长模型：运行在实时仿真器；

4. 实时计算机：运行物理模型；

5. 输入/输出调理模块：生成与实际设备电气等效的DUT激励（输出）、采集DUT响应（输入）；

6. 软件架构：管理工作站与实时计算机的仿真环境，记录激励/响应、生成报告；

7. 外部调试器（eDB）；

8. 故障注入系统（故障列表生成器+注入器）；

9. 实时计算机与eDB的可靠同步方法。

物理模型在高端商用实时计算机上实现，该计算机专为HIL与快速控制原型设计，配备大量模块化调理模块。本文物理系统为无人机纵向（俯仰角）模型。为实现高效测试环境，无人机模型需兼顾精度与仿真速度。

完善的HIL系统除验证分区与故障检测、隔离、恢复（FDIR）机制外，还可执行DUT功能验证与非功能需求验证。本文的核心问题是验证 DUT 的时序行为：测试工程师需验证DUT的实时需求，评估系统时域性能特征（图5.7）。因此需验证无故障状态下关键、非关键子系统均满足指标。验证方法因应用而异，但图5.6的架构适用于所有实时应用。

图5.6：文献中所提方法的框图

仅在文献方法中存在的、与外部调试器及故障注入路径相关的模块，以红色边框标出。在文献中，仅存在一个由硬件在环（HIL）仿真器管理的信号，用于触发影响低设计保障等级（DAL）任务的已知不可修复缺陷。

图5.7：控制理论文献中二阶系统的时域性能特征

基准架构实现时间、空间分区与FDIR机制，方案来自文献。

文献将分区分为两类，对应上述两种干扰：空间分区解决空间干扰，时间分区解决时间干扰。

测试过程中，时域性能分析器（图5.6）在不同场景下表征物理系统阶跃响应。

· 上升时间：阶跃激励施加至系统达到预期响应的时间；

· 超调量：预期输出与响应最大值的比值；

· 稳定时间：系统响应进入预期值5%误差范围并保持稳定的时间。

实际操作中，测试工程师需按以下步骤搭建HIL测试：

1. 获取物理系统模型与合适控制器：本文物理系统为无人机纵向（俯仰）模型，可采用Simulink等模型化语言或C语言实现，优先选择模型化语言，简化后续步骤。本文目的是验证分区与FDIR机制，而非控制软件，因此模型需采用固定步长求解器以支持实时运行。

2. 定义实时仿真器与DUT的接口：接口依据应用规格确定，采用无人机实际接口，考虑设备驱动对实时性能、时序需求的影响（如并行同步采集信号）。实际操作中，该步骤决定实时计算机所需的模拟调理模块型号。

3. 准备并测试物理连接：搭建实时仿真器模拟调理模块与DUT的线束，通过传输已知周期信号测试连接正确性。

4. 集成测试：HIL核心环节，测试DUT与实时计算机的通信，验证安全关键模块在DUT的正确实现。为保证结果有效，DUT需运行标称混合关键度任务；此阶段采集DUT对激励的响应。

5. 时域性能分析：可由HIL仿真器在线执行，或由工作站离线执行（本文采用在线方式），验证DUT运行标称任务时的实时行为。本文被控对象为二阶系统，通过阶跃响应执行时域分析。

系统集成验证完成后，可集成故障注入（FI）系统，除验证关键/非关键任务分区外，还可评估 FDIR 系统应对处理单元内存或瞬时硬件故障的能力。

文献的故障注入系统基于文献模型实现，映射关系如下：

· 故障注入管理器、故障列表生成器、故障分类模块：运行在主机工作站，通过专用接口连接外部调试器（eDB）；

· 故障注入器、数据采集器：由eDB实现，管理软件运行在工作站；

· 任务生成器：运行在实时仿真器，管理软件运行在工作站。

eDB通过测试访问端口（TAP）连接DUT，另一接口连接DUT与HIL平台，提供子系统间同步信号。该同步可让HIL平台在故障注入期间暂停模型仿真，冻结测试状态，对本文场景的故障注入实验至关重要：若物理模型在故障注入时不暂停，引入的延迟可能影响控制系统实时性能，导致测试无效。该同步接口通过eDB直接管理的低有效信号实现，故障注入开始时拉低，注入结束后释放，保证模型仿真在DUT处理器暂停期间停止，实现同步。

所有接口实现并测试后，测试环境可执行任意测试。两种方法的核心目标是验证FDIR机制应对低DAL任务缺陷或瞬时随机硬件失效的能力，需设计测试激励激活这些机制。故障列表生成器可生成指定数量的故障列表，输入为内存映射配置寄存器的故障注入位置（地址、位宽）或CPU内部寄存器名称、位宽。

故障注入管理器从生成的故障列表中逐个读取故障，发送至故障注入模块，执行以下操作：

1. 停止DUT嵌入式软件执行；

2. 拉低至HIL仿真器的同步信号；

3. 注入故障；

4. 释放同步信号；

5. 恢复DUT软件执行。

暂停/恢复有限状态机（FSM）如图5.9所示，表示HIL系统的可能状态。

任务执行完成后（本文为模拟飞行员发出大俯仰角变化指令），数据采集模块读取DUT输出，与一组标志位一同发送至故障分类模块，标志位用于判断FDIR机制是否因故障触发。

图5.8：拟议HIL系统的框图

图5.9：暂停/恢复有限状态机（FSM）

故障分类模块将故障分为以下类别：

· 无影响（NE）：故障对系统无影响；

· 失效（F）：故障未被任何FDIR机制检测，但导致DUT输出错误；

· 超时（TO）：故障被看门狗（WDT）检测，通常不可恢复，需切换至热备份计算机避免错过截止时间；

· 已纠正（C）：故障被除看门狗外的FDIR机制检测并纠正。

该分类报告与HIL平台测试报告对比，检查除看门狗外的FDIR机制激活时间是否导致DUT时域性能显著变化，最终生成报告，说明FDIR机制对DUT时域行为的影响。DUT至调试器的数据通路用于分类不影响系统实时行为的故障。

HIL 测试是多行业的常规实践，市面上有多种商用HIL平台，本文采用商用平台，包含以下组件：

1. 基于64位Intel® x86处理器的实时计算机；

2. 基于Xilinx® Kintex-7™的互联系统；

3. 多个管理数字、模拟信号的I/O模块。

本文实验模型采用MathWorks® Simulink实现，这是模型基软件设计（MBSD）的常规流程：先将控制器与被控对象建模仿真，验证设计后，转换为底层语言。本文通过Matlab Embedded Coder完成转换，得到的控制器软件模块集成至文献的混合关键度系统。

借助MBSD方法，HIL平台可运行与DUT完全相同的控制器，简化系统验证。需要强调的是，MBSD并非本方法的必选项，还有其他方法可完成所需的时域分析与验证。

模型按以下步骤实现与验证：

1. 从闭环系统模型生成底层代码，将被控对象与控制器均部署至HIL平台；

2. 将生成的测试任务与Simulink仿真对比，满足安全标准的工具验证要求；

3. 验证HIL平台可实时运行被控对象与控制器模型，用于DUT实时验证；若不通过，需修改模型提升执行速度。此配置下，HIL运行正式测试的所有模块：DUT与HIL的通信协议、暂停/恢复有限状态机（FSM）、对比DUT输出与黄金控制器的时域分析器、存储结果并转发至工作站的日志服务。

完成以上检查后，HIL平台可执行正式测试。控制器模型重新编译并部署至DUT，DUT与HIL平台的通信协议允许DUT控制器向无人机模型发送指令，接收模型生成的传感器数据。

DUT系统基于文献方案实现：空间分区通过Type-1虚拟机管理程序实现，时间分区采用基于性能分析的统计方法。DUT基于Xilinx® Zynq-7020 APSoC实现，搭载双核ARM® Cortex-A9处理器；每个核运行一个任务，核0运行控制器任务，核 1 运行非关键任务，实现混合关键度负载。

5.2.2 低关键度软件组件触发固有已知缺陷的实验结果

时域性能分析器记录生成的激励（图5.6），可表征系统时域阶跃响应特征（图5.7）。统计数据来自500次阶跃响应过渡过程，模拟飞行员要求无人机执行大俯仰角变化。

表5.1对比了Simulink模型在环（MIL，见文章“第一部分”2.11.4节）、软件在环（SIL，见文章“第一部分”2.11.4节）的响应。SIL测试中，被控对象与控制器均在实时计算机运行，也可在工作站运行；本文选择实时计算机，验证 HIL 仿真器可无截止时间错过地实时运行物理模型。

表5.1：MIL和SIL中获得的结果之间的平均时域性能比较

表5.2对比SIL实现与HIL实现（DUT运行控制软件、实时计算机运行被控对象模型）的性能，该对比对验证标称无故障状态下控制器的正常运行至关重要，属于MBSD数字控制系统实现的常规流程。表5.3对比DUT运行无故障/带故障任务的HIL仿真性能。

表5.2：实时计算机中的完整软件实现与无故障条件下DUT上闭环的平均时域性能比较

表5.3：无故障和受故障影响情况下DUT闭环的时域性能比较

后两张表的结果为HIL实现，信号通过DUT与HIL仿真器的物理接线传输，测试工程师需考虑物理干扰对模拟信号的影响，因此报告平均值与500次重复的方差。为模拟系统故障状态，使用故障注入系统激活非关键应用的缺陷。

缺陷激活后，非关键应用出现异常行为，分离机制检测到该行为并执行正确恢复操作。为避免单次事务中缺陷被多次激活的低概率情况，每个事务仅激活一次缺陷。结果表明，即便DUT不同核并行运行的非关键任务出现异常，控制器仍可正常工作，数据证明无性能下降，所有三个控制器性能参数在两种场景下差异可忽略，方差均较低且接近，微小差异完全归因于白噪声与随机测量误差。

5.2.3 故障注入、暂停信号与外部调试器的实验结果

文献的作者均通过故障注入（FI）仿真实验验证方案。

本测试系统的核心组件是外部调试器（eDB），其关键需求已明确，多款商用嵌入式调试工具可满足。本文选择其中一款，设计通过专用协议经USB电缆与工作站通信，工作站运行硬件调试系统的配套软件，实现故障注入管理器。

HIL平台与eDB的同步通过专用接口实现，本文通过DUT未使用的通用输入/输出（GPIO）接口实现，由eDB配置寄存器，不修改DUT嵌入式软件，经可用I/O模块连接HIL平台。为停止HIL平台模型执行，eDB停止DUT执行并将MPSoC置于调试模式，通过MPSoC调试模式提供的功能，eDB将GPIO引脚置为冻结信号，HIL平台采样冻结信号并停止模型仿真。故障注入结束后，eDB必须在释放 MPSoC前，将GPIO引脚恢复原值，以释放物理模型仿真。

故障注入系统与DUT的同步通过断点实现。多款MPSoC提供系统调试功能，硬件断点可让eDB要求软件在取指定地址指令前停止。断点触发时，MPSoC自动进入调试模式，允许eDB控制并执行必要操作。设置两个同步断点：一个在执行周期起始，一个在执行周期结束。第一个断点作为故障注入的参考点，故障注入相对于该参考点随机时间执行；第二个断点作为数据采集点。

性能分析结果（表5.4）以MIL为基准，用于后续实验的时域对比。

表5.4：无故障条件下的时域性能特征

测试工程师执行四次故障注入，每次注入不同类型故障：

1. CPU寄存器文件（CPU RF）故障：目标为DUT每个核的架构寄存器文件；

2. MPSoC 配置寄存器（Cfg. Regs.）故障。

两类故障的分类按前文描述执行，结果如表5.5所示。

表5.5：硬件故障注入分类

表5.6：软件故障注入分类

表5.7：干扰检测

5.3 多智能体机器人系统（MAS）开发

本文内容发表于2019年IEEE新兴技术与工厂自动化国际会议（ETFA）。

多智能体系统（MAS）是由多个自主、异构、协作的智能体组成的分布式系统，通过局部信息交互与协同完成全局任务。这类系统广泛应用于工业自动化、智能交通、无人机编队、服务机器人等领域。

在工业场景中，MAS常用于高精度、高负载、高冗余的执行机构，例如：

· 多电机协同驱动的Delta机器人；

· 多轴联动的装配机械手；

· 分布式物料搬运系统。

这类系统的核心挑战是：多个智能体必须严格同步，否则末端执行器会出现位置偏差、速度抖动、轨迹畸变，甚至导致机械损坏、生产事故。

传统验证方法（模型仿真、离线测试）难以覆盖：

· 时钟漂移导致的同步误差；

· 通信延迟/丢包对协同的影响；

· 单个智能体故障对全局系统的连锁反应。

因此，需要一套基于HIL的实时验证方法，在硬件层面复现真实时序、通信、故障，验证协同控制软件的安全性与鲁棒性。

5.3.1 提出的方法

本文提出一套多智能体协同控制HIL验证流程，目标是验证：

1. 多智能体之间的位置/速度同步精度；

2. 通信中断、时钟漂移、单智能体故障下的降级策略；

3. 实时控制软件是否满足硬实时截止时间。

图5.10：通用MAS的框图

图5.11：拟议方法的流程图

方法流程如图5.11所示：

1. 系统建模：建立机械结构、动力学、传感器/执行器、通信模型；

2. HIL 平台搭建：实时仿真器运行多体动力学模型，每个智能体对应一个真实控制器；

3. 同步策略部署：将协同控制算法部署到各控制器；

4. 标称测试：无故障下验证轨迹跟踪精度、同步误差；

5. 故障注入测试：注入通信延迟、丢包、单节点失效、时钟漂移；

6. 结果评估：同步误差、轨迹误差、实时性指标、故障恢复时间。

系统整体架构如图5.10所示：

· 多个控制器（智能体）独立运行；

· 实时仿真器运行机械耦合模型；

· 控制器与仿真器通过实时总线交互；

· 上位机监控、记录、分析数据。

5.3.2 基准应用

本文选用Delta机器人作为基准应用：

· 末端执行器由两台电机协同驱动；

· 两台电机无机械连接，完全依靠软件同步；

· 任意不同步都会直接导致末端位置偏差、机械应力过大。

机械结构如图5.12所示。

图5.12：基准MAS的机械结构

控制需求：

· 末端执行器沿预定轨迹运动；

· 两电机位置、速度必须严格同步；

· 出现同步偏差时必须在限定时间内校正；

· 单个电机故障时系统可安全停机/降级。

5.3.3 控制软件与模型

控制软件采用分层架构（图5.13）：

1. 轨迹层：生成期望位置/速度序列；

2. 协同层：同步补偿、偏差校正、故障诊断；

1. 驱动层：电流环、速度环、位置环闭环控制。

图5.13：控制软件框图

图5.14:MIL/SIL估计路径

图5.15:HIL测试所采用的软件架构框图

模型分为：

· 多体动力学模型：在实时仿真器运行；

· 电机/传感器模型：包含噪声、延迟、饱和特性；

· 通信模型：可配置延迟、丢包率、中断概率。

5.3.4 实验结果

实验分为三组：

1. 标称工况：无故障，验证基础同步精度；

2. 通信干扰：延迟、丢包，验证鲁棒性；

3. 单节点故障：电机/传感器失效，验证安全策略。

关键指标：

· 同步误差：两电机位置差；

· 轨迹跟踪误差：末端实际位置与期望位置差；

· 实时性：控制周期抖动、最坏执行时间（WCET）；

· 故障恢复时间：从故障发生到稳定的时间。

典型结果：

· 标称工况下同步误差< 0.01mm，满足精度要求；

· 通信延迟< 10ms时系统可稳定校正；

· 单节点故障可在50ms内进入安全状态，无机械冲击。

实验装置如图5.16所示，仿真与实测对比如图 5.17、5.18 所示。

图5.16：本提案中描述的实验装置的照片

图5.17:HIL最坏情况估计路径

图5.18:65次HIL模拟的结果

6.1 基于仿真的FMEDA贡献

6.1.1 优势

1. 自动化与高效性相比人工FMEDA，仿真方法可自动遍历故障模式、批量仿真、自动分类，大幅缩短分析时间。

2. 客观性与可重复性不依赖工程师经验，仿真条件可复现，结果一致。

3. 覆盖闭环系统可直接评估软件+硬件+被控对象联合失效行为，适合电机控制、动力系统等闭环应用。

4. 支持早期设计决策在原理图定稿前即可评估可靠性，避免后期返工。

5. 支持系统级影响分析可将故障传播到整车/整机，评估驾驶性、安全性、任务影响。

6.1.2 局限

1. 依赖模型精度模型不准确会导致分类错误。

2. 故障模型简化难以覆盖所有微观硬件失效机理。

3. 仿真时间成本复杂系统、多故障组合仿真耗时较长。

4. 知识产权限制商用芯片/模块难以获得详细SPICE模型。

5. 多故障组合爆炸无法穷举所有多故障组合。

6.1.3 未来发展

1. AI辅助故障筛选与关键故障识别；

2. 数字孪生集成：在线实时FMEDA；

3. 多物理场联合仿真；

4. 自动化报告生成与ISO 26262认证直接对接；

5. 与HIL联合实现 “仿真+实测” 混合FMEDA。

6.2 基于仿真的 HARA 贡献

6.2.1 优势

1. 提升客观性用仿真数据替代主观判断，严重度、可控性更可信。

2. 提升可重复性场景、模型、工况可复现。

3. 支持早期概念阶段分析无需硬件、无需详细设计即可开展HARA。

4. 支持ADAS /自动驾驶场景天然适合复杂交通场景、紧急工况、极限场景。

5. 可对接SOTIF/UL 4600可扩展分析标称功能不足、场景缺失问题。

6.2.2 局限

1. 无法评估暴露度（E）仍需人工/统计数据。

2. 依赖场景完整性场景不足会导致危害遗漏。

3. 驾驶员模型简化真实驾驶员行为具有随机性。

4. 不支持系统性设计缺陷分析。

6.2.3 未来发展

1. 基于场景库的自动HARA；

2. 与自动驾驶仿真平台（Prescan/CARLA）深度集成；

3. AI生成危险场景；

4. HARA+SOTIF联合分析框架。

6.3 实时软件验证贡献

6.3.1 车身控制模块（BCM）

· 提出面向BCM的轻量化HIL工具链，降低使用门槛；

· 支持大量I/O、CAN/LIN总线、状态机测试；

· 适合产线、实验室批量自动化测试。

6.3.2 混合关键度航空电子系统

· 提出HIL+调试器+故障注入联合验证架构；

· 支持暂停-注入-恢复机制，不破坏实时性；

· 可验证分区、隔离、FDIR机制对截止时间的保障能力。

6.3.3 多智能体机器人系统

· 提出多控制器协同HIL验证方法；

· 可验证同步精度、实时性、故障降级；

适用于分布式驱动、车路协同、编队行驶等场景。

免责声明：文中观点仅供分享交流，文章版权及解释权归原作者及发布单位所有，如涉及版权等问题，请您联系TechApe@yeah.net告知，我们会在第一时间做出处理。