车载电子系统验证中预期功能安全SOTIF测试的关键流程探讨

ISO 21448标准定义的预期功能安全（SOTIF），是车载电子系统（尤其是ADAS、自动驾驶系统）安全验证的核心环节，聚焦“系统正常工作时因功能设计或性能局限导致的风险”——例如传感器感知盲区、算法对复杂场景的决策偏差，这些风险无法被传统功能安全（ISO 26262）覆盖，却可能引发严重事故。SOTIF测试的目标，是通过系统性流程验证这些风险是否可控，确保系统在真实使用场景中的安全性。本文将拆解从场景识别到跨域验证的关键流程，结合具体案例说明操作细节。

风险场景的系统性识别：从需求到具体场景的转化

风险场景是SOTIF测试的起点，需从系统需求、历史事故、用户场景中系统性提取。例如某款车型的自动紧急制动（AEB）系统，需求文档要求“识别行人并触发制动”，但需进一步拆解为“行人从路边停车位后方突然冲出”“逆光下行人穿深色衣物”“雨天路面湿滑导致制动距离延长”等具体场景——仅停留在需求层面无法指导测试。

常用方法包括HAZOP（危险与可操作性分析）和FMEA（失效模式与影响分析）：HAZOP通过“引导词+参数”组合（如“过量的”+“行人速度”）挖掘潜在风险；FMEA从“传感器失效”“算法误判”等失效模式反推场景。此外需参考NHTSA、Euro NCAP的事故数据，比如2022年Euro NCAP统计显示，“行人横穿马路”是AEB最常失效的场景，需纳入测试范围。

场景识别需覆盖“正常”与“异常”使用：正常场景是用户日常遇到的（如城市道路、高速公路），异常场景是用户可能误操作的（如未系安全带时启用AEB）。例如自适应巡航（ACC）系统，需考虑“驾驶员调整跟车距离后系统是否保持安全距离”的正常场景，以及“驾驶员突然接管方向盘时系统是否及时退出”的异常场景。

测试用例的精准设计：覆盖功能边界与场景变量

测试用例需基于风险场景拆解为可量化的变量组合。以AEB的“行人横穿”场景为例，需分解为环境变量（光照：夜间500lux以下、强光10000lux以上）、目标变量（行人速度：1.5~5m/s、衣物颜色：深/浅）、系统状态变量（传感器校准状态、算法版本）。

变量需覆盖“边界值”与“组合值”：边界值是极值（如行人速度5m/s），组合值是多变量叠加（如“夜间+深色衣物+行人快速横穿”）。例如自动泊车系统，需测试“狭窄车位（比车身宽0.5m）”的边界场景，以及“夜间+斜向车位+旁边有自行车”的组合场景——单一变量可能无风险，但组合后易引发误判。

用例需明确“输入-输出”判定标准：输入是场景变量（如“雨天+行人速度3m/s”），输出是系统响应（如“制动触发≤150ms、制动距离≤10m”）。例如AEB测试中，若输入是“雨天路面摩擦系数0.5+行人速度3m/s”，输出需满足“0.5秒内识别、1秒内制动、距离≤8m”，否则不通过。

需避免重复覆盖：例如“晴天+行人速度3m/s”与“阴天+行人速度3m/s”是不同环境变量，需分别设计；但“晴天+3m/s”与“晴天+3.1m/s”属于重复，可合并为“3m/s±0.1m/s”的范围用例，提升效率。

实车与仿真的协同：弥补单一测试的局限

实车测试真实但成本高、复现难——例如“高速前方变道+侧方来车”场景，实车需封闭高速，成本数十万元且难复现。仿真测试可快速调整变量（如改变车辆速度、道路曲率），但真实性不足（如仿真传感器数据难模拟真实噪声）。

协同策略是“仿真先行，实车验证”：先通过CarSim、PreScan等工具模拟极端场景（如“行人5m/s横穿+雨天”），验证决策逻辑；再在封闭场地用实车复现，验证传感器感知（如摄像头是否识别深色行人）和执行器响应（如制动减速度是否达标）。

数字孪生是协同关键：构建车辆的数字孪生（包含传感器、算法、执行器模型），将实车数据输入孪生模型，调整参数让仿真更真实。例如摄像头孪生模型，需输入实车的“夜间光照”“行人反射率”数据，调整曝光参数，确保仿真输出与实车一致。

需关注“虚实一致性”：若仿真中AEB制动距离8m，实车是10m，需分析原因——可能是仿真路面摩擦系数设为0.6，而实车实际是0.5，需调整仿真参数，确保虚实一致。

边缘案例的深度验证：突破常规风险边界

边缘案例是概率低但后果严重的场景，易被常规测试忽略。例如“高速突然出现鹿”“隧道入口强光导致摄像头过曝”“积雪覆盖车道线导致车道保持失效”——这些场景虽少见，但一旦发生可能引发严重事故。

边缘案例挖掘需参考事故数据与用户反馈：例如NHTSA 2023年数据显示，“隧道入口强光”是ADAS感知失效的常见原因；某车型用户投诉“积雪天车道保持误判”，需将其纳入测试。

验证需聚焦“系统极限”：例如测试隧道入口场景，需用实车在隧道入口处反复行驶，记录摄像头的曝光调整时间——若调整需200ms，而系统决策需100ms，总延迟300ms可能导致事故，需优化摄像头算法。

边缘案例需“重复测试”：例如“高速出现鹿”的场景，需在仿真中模拟100次，统计系统识别率；再在实车中用假鹿复现10次，验证执行器响应——确保低概率场景下系统仍能安全工作。

性能边界的量化测试：定义安全工作范围

SOTIF要求明确系统性能边界，即“系统能安全工作的条件”。例如毫米波雷达在雨天的有效探测距离从150m降到80m，自动泊车系统的最小车位宽度是比车身宽0.8m——这些边界需通过量化测试确定。

量化测试需用工具采集数据：例如用假人、假车测试传感器探测率（如在不同距离、速度下，摄像头识别行人的准确率）；用数据采集系统记录响应时间（如AEB从识别到制动的总延迟）。

边界需写入安全手册：例如某款ACC系统的边界是“车速0~120km/h、跟车距离≥2s”，需明确告知用户“超过120km/h时系统可能失效”“跟车距离小于2s时需手动接管”。

需验证“边界外的系统行为”：例如ACC系统在车速130km/h时，需测试系统是否自动退出并提醒用户——若系统未退出仍保持工作，可能引发风险，需优化退出逻辑。

跨域协同验证：解决多系统交互风险

车载电子系统是跨域的（感知域：摄像头、雷达；决策域：ECU；执行域：制动、转向），SOTIF测试需验证域间交互安全。例如AEB系统，需验证“摄像头识别行人→ECU发制动指令→制动系统响应”的全流程。

跨域测试需用硬件在环（HIL）台架：将感知域的传感器数据输入决策域ECU，连接执行域的制动模型，模拟全系统交互。例如测试AEB的交互延迟：摄像头识别需50ms，ECU决策30ms，制动响应70ms，总延迟150ms——若要求≤200ms，则符合安全要求。

需关注“接口兼容性”：例如感知域输出的“行人位置”数据格式是“x=10m,y=2m”，决策域ECU需能正确解析该格式；若格式不兼容，会导致ECU无法识别行人，引发事故。

跨域验证需覆盖“异常交互”：例如感知域传感器突然离线，决策域ECU需及时发出“系统失效”提醒，并让执行域保持手动控制——若ECU未提醒，用户可能误以为系统仍在工作，引发风险。

数据驱动的迭代优化：从测试到改进的闭环

测试不是终点，而是迭代起点。例如测试发现“夜间行人识别率70%”，需分析原因：是摄像头感光度不足？还是算法特征提取不够？若为感光度问题，需更换更高感光度的摄像头；若为算法问题，需优化特征提取模块。

优化后需重新测试：更换摄像头后，夜间识别率提升到95%，需再次用实车验证“夜间+深色行人”场景，确保识别率稳定——直到风险降到可接受水平（如ISO 21448要求的“剩余风险As Low As Reasonably Practicable”）。

数据管理是迭代关键：建立测试数据库，存储用例变量、结果、问题描述——例如“2023-10-01，夜间+行人速度3m/s，识别率70%，原因：摄像头感光度不足”，方便后续追溯与分析。

需关注“用户反馈的迭代”：例如用户投诉“雨天自动泊车失败”，需提取该场景的测试数据，发现是“雨天摄像头积水导致车位线识别失效”，需优化摄像头的防水设计，再测试验证——形成“测试-优化-再测试”的闭环。