汽车电子ISO 26262功能安全系列（第29期）：软件集成测试与嵌入式软件验证——把“零件”拼成“整机”

ISO 26262-6的第10章软件集成与验证就是专门解决这个问题的——把各个软件单元“拼”成一个完整的嵌入式软件验证它们组合在一起后是否仍然安全。集成测试是什么跟单元测试有什么区别集成测试的“终极目标”软件集成测试的目标有两个集成软件元素——把各个软件单元按架构设计组装成完整的软件组件证明架构设计被正确实现——验证软件体系结构设计确实被嵌入式软件实现了简单说单元测试证明“每块砖是好的”集成测试证明“砌成的墙是稳的”。单元测试 vs 集成测试一张表看懂区别对比维度单元测试集成测试测试对象单个函数/模块最小可测试单元多个单元组合成的软件组件或整个软件核心目标验证每个单元的设计规范是否正确实现验证架构设计和高层需求是否被正确实现关注重点单元内部逻辑、接口功能模块之间的接口交互、数据传递和整体功能行为测试环境开发环境PC或仿真器开发环境 → 逐步过渡到目标硬件覆盖率要求语句/分支/MC/DC覆盖架构覆盖、接口覆盖、功能覆盖核心区别单元测试关心“每个零件好不好”集成测试关心“零件之间配合得好不好”。两种集成策略自底向上 vs 自顶向下ISO 26262没有强制规定集成策略但行业里主要有两种方式。策略一自底向上Bottom-Up——“先搭底座再盖高楼”怎么做先从最底层的单元开始测试逐步移除桩模块Stub把多个单元组合成更高层的功能模块。优点底层单元测试充分发现问题早缺点高层功能验证较晚整体“长相”出来得慢策略二自顶向下Top-Down——“先搭框架再填细节”怎么做先从高层模块或子系统开始测试再逐步加入低层模块。优点系统整体架构验证早缺点需要大量的桩模块Stub来模拟底层功能ACC控制器推荐策略混合式在实战中大多数项目采用混合策略——关键底层模块用自底向上确保基础牢固核心功能链路用自顶向下确保整体正确。ACC控制器作为ASIL-D的安全关键系统建议以自底向上为主——先把雷达数据采集、跟车距离计算等基础单元测扎实再逐层向上集成到完整控制链路。集成测试的“官方菜单”ISO 26262推荐的方法ISO 26262-6:2018的Table 3列出了集成测试用例的导出方法。等级越高需要组合的方法越多。方法ASIL AASIL BASIL CASIL D大白话需求分析“架构设计说啥就测啥”接口分析“模块之间怎么通信的”等价类分析“同类问题测一个代表”边界值分析“边界最容易出问题”错误猜测“凭经验猜哪里容易翻车”功能依赖分析“A功能依赖B功能B挂了A会怎样”共因分析“多个模块会不会被同一个故障干掉”环境与操作场景分析“不同环境条件下怎么表现”现场经验分析“从实际数据里找测试点”ASIL-D要用上几乎全部方法——这不是“选做”是“必做”。实战ACC控制器集成测试用例设计以ACC控制器的“雷达数据采集 → 跟车距离计算 → 安全状态管理”这条链路为例用例ID测试方法测试内容预期结果TC-INT-001需求分析雷达数据正确传递给跟车距离计算模块数据传递无丢失、无延迟TC-INT-002接口分析两个模块之间的数据接口格式是否正确数据类型、范围、单位一致TC-INT-003边界值雷达传来极远距离250m和极近距离0m系统正确处理边界值TC-INT-004错误猜测雷达模块发送数据格式错误接收模块检测到错误不崩溃TC-INT-005功能依赖雷达数据丢失时跟车距离计算如何响应触发超时报警进入安全状态TC-INT-006共因分析电源波动同时影响雷达和控制器两个模块是否同时失效是否有隔离TC-INT-007环境分析模拟高温环境下模块间通信通信是否稳定嵌入式软件测试为什么必须“上真家伙”集成测试在开发环境PC上完成之后还有最后一道关卡——嵌入式软件测试Testing of the Embedded Software。嵌入式软件测试 把软件烧录到真实的ECU硬件上在目标环境中验证它是否真的能跑。为什么不能在PC上“凑合”问题PC环境真实ECU环境⏱️时序跑得飞快时序宽松时钟频率受限时序严格内存内存充足RAM/Flash有限外设模拟的真实的传感器、执行器、总线⚡电气稳定电源可能存在电压波动、EMC干扰️环境室温-40℃~85℃PC上跑得好好的代码烧到ECU上可能因为时序不同而出问题——这就是嵌入式软件测试不可替代的原因。嵌入式软件测试的三大战场根据ISO 26262-6:2018嵌入式软件测试主要包含以下活动战场一软硬件集成测试把软件烧录到目标ECU上验证软硬件接口HSI是否正常工作——SPI通信对不对、CAN报文能不能发、中断响应及不及时。战场二硬件在环HIL测试把ECU接入HIL台架模拟真实车辆的各种工况——前车急刹、传感器失效、总线通信中断等。战场三系统级测试把ECU装到实车上在封闭场地或转毂台架上验证整车功能。HIL测试对功能安全尤其重要——可以在实验室里安全地模拟“雷达信号丢失”“前车突然急刹”等危险场景不用真上路冒险。实战ACC控制器从单元测试到嵌入式测试全链路把以上所有内容整合起来ACC控制器软件验证的完整路径是这样的Step 1单元测试PC环境测试对象每个独立的函数测试内容get_radar_distance()、calc_safe_distance()、check_following()等覆盖率目标语句100%、分支100%、MC/DC 100%工具TessyPC仿真环境Step 2集成测试PC环境 部分目标环境测试对象多个单元组合成的软件组件测试内容雷达数据采集模块 → 跟车距离计算模块 的数据传递跟车距离计算模块 → 安全状态管理模块 的接口整个ACC控制算法的端到端行为覆盖率目标架构覆盖、接口覆盖工具TessyPC 开始部分在目标板上运行Step 3嵌入式软件测试目标ECU环境测试对象完整的嵌入式软件烧录到ECU测试内容软硬件接口HSI验证——SPI、CAN、GPIO是否正常工作时序验证——任务是否在规定的截止时间内完成内存验证——RAM/Flash使用是否在限制范围内工具目标ECU开发板 调试器Step 4HIL测试ECU HIL台架测试对象ECU 仿真被控对象测试内容模拟前车急刹 → ACC能否及时响应模拟雷达信号丢失 → 系统能否在100ms内进入安全状态模拟CAN通信故障 → 通信监控是否触发报警工具HIL台架dSPACE/NI PXIStep 5实车测试真实车辆测试对象完整车辆测试内容安全确认Safety Validation——上一期已经讲过集成测试中容易踩的“坑”坑1单元测试过了就直接跳到实车测试❌ “单元测试都过了直接上车试试”✅ 必须逐级验证——单元测试→集成测试→嵌入式测试→HIL测试→实车测试跳过任何一级都可能遗漏问题坑2集成测试还在用单元测试的用例❌ 把单元测试的用例原封不动搬到集成测试✅ 集成测试要关注模块之间的交互——接口、数据传递、时序、资源竞争坑3忘了测“资源使用”❌ 只测功能对不对不管内存和CPU✅ ISO 26262要求资源使用评价——确认在最坏情况下CPU时间、ROM、RAM是否充足坑4嵌入式测试只在PC上做❌ 所有的测试都在PC上跑完就完事了✅嵌入式软件测试必须在目标硬件上执行——PC仿真代替不了真实ECU