Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO 26262-4:2018 — 汽车功能安全系统级产品开发
深入解析技术安全概念、系统集成测试与安全验证
ISO 26262-4:2018 系统级开发概述
ISO 26262-4:2018是ISO 26262道路车辆功能安全系列标准的第四部分，专注于系统级产品开发。它在概念阶段（ISO 26262-3）和详细的硬件、软件开发阶段（ISO 26262-5和ISO 26262-6）之间架起了关键桥梁。该标准将功能安全需求转化为具体的技术安全概念，定义系统架构设计，并建立集成和验证框架，确保最终车辆系统满足其安全目标。
ISO 26262-4定义的系统级视角涵盖整个项（item）——即在车辆层面实现某一功能的一个或多个系统的组合。它涵盖了从技术安全需求规格说明到车辆集成测试和安全验证的全过程。从事电子转向、制动、ADAS或任何汽车安全关键系统的工程师都将发现本标准对于构建开发流程至关重要。
在启动系统级开发时，务必从回顾ISO 26262-3的功能安全概念开始。您构建的技术安全概念必须直接追溯至此前定义的每个安全目标。
技术安全概念与系统架构设计
ISO 26262-4第6章定义了技术安全概念（TSC）的创建——这是整个功能安全生命周期中最重要的工件之一。TSC规定了功能安全需求如何在系统层面实现，包括将需求分配给硬件和软件元素、定义安全机制以及规定硬件-软件接口（HSI）。
该章节的关键活动包括：
- 技术安全需求规格说明——将功能安全需求细化为具有ASIL属性的详细技术需求
- 安全机制定义——实现故障检测、故障处理和驾驶员警告机制
- 系统架构设计——定义系统结构、元素及其交互关系
- 安全分析——在系统层面执行FMEA、FTA或相依失效分析（DFA）
- 硬件-软件接口（HSI）规格说明——记录HW和SW之间的所有交互
HSI规格说明常常被低估，但对于ASIL分解至关重要。如果硬件和软件元素由不同团队开发，HSI必须精确定义时序、内存映射、中断分配和诊断接口，以防止集成问题。
系统与项集成测试策略
第7章规定了一个按照V模型方法组织的四级集成与测试策略：
| 集成级别 | 说明 | 关键测试活动 |
|---|---|---|
| 硬件-软件集成 | 在目标ECU上测试硬件与软件的交互 | 硬件特定软件测试、寄存器测试、中断测试、内存测试 |
| 系统集成 | 将所有HW和SW元素集成到完整系统中 | 功能测试、故障注入测试、时序测试、资源消耗测试 |
| 车辆集成 | 将系统安装到车辆中并在整车层面进行测试 | 整车级功能测试、EMI测试、环境测试 |
| 安全验证 | 确认在整车层面实现了安全目标 | 整车级安全目标验证、危险事件规避演示 |
集成和测试策略必须为每个集成级别指定测试目标、测试方法、测试环境（MIL、SIL、HIL、实车）以及通过/失败标准。测试覆盖范围取决于ASIL等级，更高的ASIL需要更严格的方法，例如故障注入和扩展的环境范围。
安全验证与工程设计洞见
第8章涉及安全验证——最终确认项（item）安装到车辆后不存在不合理的风险。这与验证（检查需求是否正确实现）不同。安全验证问的是：实施的安全措施是否真的能在真实驾驶场景中防止危险事件？
给实践工程师的关键洞见：
- 验证环境必须具有足够的代表性。标准建议使用实际车辆，或者如果不可行，则使用经过验证的车辆仿真或硬件在环（HIL）系统。
- 验证规格必须涵盖正常驾驶场景、可预见的误用和系统故障模式——全部源自ISO 26262-3中执行的危害分析和风险评估（HARA）。
- ASIL依赖的严谨性：对于ASIL D，安全验证通常需要在多种环境条件（温度、湿度、路面等）下进行广泛的整车级测试。
- 文档记录：安全验证报告必须清晰记录所有验证活动、结果以及与预期行为的任何偏差。
结构良好的安全验证活动不仅满足ISO 26262的要求，还能建立整个组织的信心。许多工程团队发现安全验证揭示了单元测试或子系统测试完全未能发现的集成问题。
切勿因成本或进度原因跳过或简化安全验证。最危险的系统性故障是集成系统的涌现特性，任何数量的组件级测试都无法检测到。
常见问题解答
问：技术安全需求（ISO 26262-4）与功能安全需求（ISO 26262-3）有何区别？
答：功能安全需求（来自ISO 26262-3）在车辆级别定义，规定了系统必须做什么来实现每个安全目标（例如”制动系统应在检测到故障后200ms内接合”）。技术安全需求（ISO 26262-4）将这些需求细化为分配给硬件和软件的具体实现需求（例如”制动踏板位置传感器应以10ms间隔读取并带CRC校验”）。
答：功能安全需求（来自ISO 26262-3）在车辆级别定义，规定了系统必须做什么来实现每个安全目标（例如”制动系统应在检测到故障后200ms内接合”）。技术安全需求（ISO 26262-4）将这些需求细化为分配给硬件和软件的具体实现需求（例如”制动踏板位置传感器应以10ms间隔读取并带CRC校验”）。
问：没有完整的车辆原型能否执行系统集成测试？
答：可以。标准允许在代表性环境中进行测试，包括硬件在环（HIL）测试台、软件在环（SIL）仿真和经过验证的车辆模型。但是，必须证明验证环境对于正在评估的特定安全目标具有足够的代表性。
答：可以。标准允许在代表性环境中进行测试，包括硬件在环（HIL）测试台、软件在环（SIL）仿真和经过验证的车辆模型。但是，必须证明验证环境对于正在评估的特定安全目标具有足够的代表性。
问：ASIL分解如何影响技术安全概念？
答：ASIL分解（ISO 26262-9第5章）允许将安全需求分配到冗余元素上。例如，ASIL D需求可以分解为ASIL C(D) + ASIL A(D)需求。TSC必须清晰记录分解策略，证明分解元素之间的独立性，并表明组合的残余风险满足原始的ASIL D目标。
答：ASIL分解（ISO 26262-9第5章）允许将安全需求分配到冗余元素上。例如，ASIL D需求可以分解为ASIL C(D) + ASIL A(D)需求。TSC必须清晰记录分解策略，证明分解元素之间的独立性，并表明组合的残余风险满足原始的ASIL D目标。
问：什么是硬件-软件接口（HSI）规格说明，为什么它很重要？
答：HSI规格说明记录了硬件和软件之间的所有交互，包括寄存器映射、中断分配、内存映射、时序要求和诊断接口。它对于协调HW和SW开发团队、支持ASIL分解论证以及使HW和SW能够按照各自的ASIL独立开发至关重要。
答：HSI规格说明记录了硬件和软件之间的所有交互，包括寄存器映射、中断分配、内存映射、时序要求和诊断接口。它对于协调HW和SW开发团队、支持ASIL分解论证以及使HW和SW能够按照各自的ASIL独立开发至关重要。
