车载网络测试工程师的博客

这是进行系统层面 E2E 测试的最常用、最有效方法。HIL 台架可以：精确模拟 IDCU 的 CAN 消报文发送。精确注入各种类型的 CAN 通信故障 (超时模拟、错误数据/CRC/计数器注入、总线负载控制)。实时监控 CCU 的输出 (如通过示波器、高精度记录设备或 HIL 板卡自身 IO 直接测量FHTI。模拟真实的 ECU 电气环境和部分车辆网络。

a) 确定集成步骤，整合系统要素，直到系统完全集成；b) 验证根据系统架构层面的安全分析所确定的安全措施是否已经实施；c) 根据系统架构设计，提供集成的系统要素满足其安全要求的证据。总之，ISO 26262 中描述的。

任何事物都存在或多或少的缺陷，比如人（理想很丰满，现实很残酷），再比如物（任何事物都存在老化等）。系统、软件以及硬件开发都遵循各自V模型，都从需求到架构再到设计实现，最后验证及其系统确认（确认只有在系统层面）。随着智能化发展，其必要性已从“合规要求”升级为“技术竞争力核心”，既降低企业长期风险，更是对生命的敬畏。通过设定安全机制和安全状态，当系统出现故障时，在故障容错时间内系统进入安全状态，保证人身、财产安全。：现代汽车电子化程度高（ECU超100个，代码量超1亿行），任何软件/硬件失效都可能引发事故。

相关项是指被实施功能安全要求的系统或系统组合。它是一个功能单元（可能包括硬件、软件、机械部件和操作者），其功能失效可能导致危险事件。相关项=结构+功能描述+对象属性特征）概念阶段的相关项定义需要：划定相关项的范围（内部组成）和接口（与外部系统或环境的交互）。清晰说明相关项预期提供的所有功能（包括正常操作、降级操作模式）。初步识别构成相关项的要素（硬件模块、软件组件、传感器、执行器等）。描述相关项运行的场景（环境、驾驶工况、驾驶员状态等）。明确定义输入输出信号、通讯接口、能量源、机械连接等。

定义功能安全方案 (FSC):FSRs。设计一个功能性的架构概念，明确定义：实现每个 FSR 需要哪些功能块功能块之间的职责划分(哪个块负责检测、哪个负责决策、哪个负责执行)。功能块之间的交互逻辑和信息流（接口规范）。用于实现 FSR 的安全机制(例如：输入信号范围检查、合理性检查、数据校验、冗余比较、软件程序流监控、硬件看门狗)。故障处理策略和状态机（正常模式、降级模式、安全状态之间的转换条件）。fill:#333;color:#333;color:#333;fill:none。

通过上文介绍，咱们了解了功能安全需求（FSR）和方案（FSC），但是FSR本质上属于功能层面的逻辑安全需求，属于“需要做什么”的层级，无法具体实施，所以需要将FSR进一步细化为技术层面的安全需求（TSR），即“怎么做”，为后续的软件和硬件的开发奠定技术需求基础。是从功能安全需求（FSR）细化出的具体技术实施方案，用于指导系统/软硬件设计。可测试性：必须能被验证（e.g., 通过测试或审查）技术具体化：明确硬件/软件实现方式（e.g., 传感器类型、算法逻辑）覆盖完整性：需覆盖所有FSR要求和安全机制。

HARA定义顶层目标和风险等级；FTA和FMEA互为补充，分别从顶向下和自底向上识别设计中的故障弱点，并指导安全机制的设置和验证；DFA则专门应对安全机制本身可靠性的关键问题（独立性）。它们共同确保系统设计能满足安全目标。

想象一下汽车的软件是由成千上万个小小的“智能部件”（软件单元）组成的。核心规矩：关键部件，严上加严！如果一个智能部件（软件单元）负责安全大事（比如管刹车、防碰撞、控安全气囊），那么检查它的时候必须用最严格、最全面的“安检流程”（ISO 26262-6子章条的要求）！为啥？因为这些部件要是出点毛病，车就可能失控、撞车，要人命！马虎不得！啥算“关键部件”（安全相关）？这个部件本身干的活就是保障安全的。例：刹车压力控制器：它直接决定踩刹车时有多大劲儿能停下来。气囊触发器。

表7 软件单元验证方法:表7（续）1. 走查（Walkthrough）⦿专业解释非正式评审过程，由开发者讲解代码逻辑，参与者自由提问，目标是发现明显错误或逻辑缺陷。▲通俗解释代码作者像导游一样带大家读代码，其他人随时举手问“这里为什么这样写？🚗汽车示例：ECU的油门控制算法开发中，工程师向团队逐行解释PID控制代码，团队质疑积分项防饱和逻辑是否完整。2. 结对编程（Pair Programming）⦿专业解释：两名开发者共用一台设备实时协作编程。

为确保软件单元测试的测试案例规范符合9.4.2要求，应通过表8所列方法开发测试用例。表8 软件单元测试用例的得出方法：备注：a 等价类可以根据输入和输出的划分来确定，这样就可以为每个类选择一个有代表性的测试值。b 该方法用于接口、接近边界的值、与边界交叉的值及超出范围的值。c 错误猜测测试可以根据通过“经验教训”过程和专家判断收集的数据进行。1. 需求分析专业解释：这是软件单元测试用例生成的根本来源和起点。它系统地审查分配给软件单元的功能性安全需求和非功能性需求（例如性能、资源约束）。测试用例

通过这种结构化、分层级并明确定义了依赖关系的集成方法，旨在早期发现和修复软件单元在集成过程中产生的接口错误、时序问题、资源冲突、逻辑交互缺陷等，确保最终生成的嵌入式软件在功能、性能和安全方面满足要求，为后续顺利的软硬件集成和系统验证打下坚实基础。示例：可靠性（没有不可访问的软件），鲁棒性（防止错误输入），可信赖性（有效的错误检测和处理）。软件要素的集成和测试的步骤直接对应着软件的分层架构。注：原文定义：对于基于模型的开发，软件集成可以替换为模型级别的集成以及随后来自集成模型的代码自动生成（参见附件B）。

表10 软件集成验证方法备注：基于需求的测试 (Requirement-based Testing)接口测试 (Interface Testing)故障注入测试 (Fault Injection Testing)资源使用测试 (Resource Usage Testing)在模型和代码之间背对背对比测试 (Back-to-Back Test between Model and Code)控制流和数据流的验证 (Control Flow and Data Flow Verification)静态代码分析

特性基于需求的测试故障注入测试核心目标验证功能正确性 & 实现符合需求验证安全机制在故障下的鲁棒性、检测能力和容错效果测试方向正向测试(验证需求要求的“应该发生”)负向测试(验证在“不应该发生”的故障下系统的反应)输入来源直接从需求规范导出测试用例从FMEA/FTA等分析得出的关键故障模式、失效场景导出测试用例测试条件正常输入条件、预期的操作序列人为注入异常/错误/故障状态(篡改数据、状态、输入信号、模拟硬件错误)主要关注点功能行为、接口、时间约束是否正确实现安全机制的覆盖率故障检测率。

ISO 26262标准中，**验证（Verification）和确认（Validation）** 是功能安全生命周期中的两个关键活动。验证确保每个开发步骤（如硬件/软件设计）符合其输入需求（如安全需求），确认确保最终产品在所有预期环境中均满足安全目标（如避免非预期加速等危害）。通常先完成各阶段的验证，最后进行确认（但可能有迭代）。通过区分这两者，ISO 26262确保从微观到宏观层面均覆盖功能安全要求。定义验证是通过客观证据证明开发阶段的输出是否满足该阶段规定的需求。

在汽车电子系统中，功能安全（Functional Safety）是确保系统在发生故障时仍能安全运行的关键。AUTOSAR（AUTomotive Open System ARchitecture）为汽车电子系统提供了一个标准化的软件架构，其中E2E（End-to-End）保护机制是确保数据在传输过程中完整性和安全性的重要组成部分。

ISO26262定义了测试方法和用例导出方法，共同保证产品的开发质量。但在刚开始学习ISO26262的时候，又不是非常清晰地理解它俩的区别和联系。本文主要对它俩的定义、作用以及相关方法进行了介绍。

在进行车载测试用例编写时，会遇到多个条件导致用例排列组合爆炸的情况，但是为了产品测试质量，我们又不得不保证用例设计的需求覆盖度，这样又会使得测试周期非常长。我们如何平衡效率和测试质量？本文进行了一些思考。

前文介绍了车载外灯模块的常见模块的功能、控制原理实现以及需求，本文主要以位置灯为例，详细讲述针对此类需求如何从需求导出用例，并保证用例对需求的覆盖度。针对手动控制位置灯的典型需求进行测试用例设计，通过对用例导出方法的合理使用以及优先级的合理划分，使用例覆盖度符合要求，并且更有利于合理地开展测试工作。可以在有限的测试资源下，对重点需求点进行最大化的验证，这种方法是汽车电子领域平衡效率与安全的行业最佳实践。