1.第一条关键线硬件功能安全不能只看电路能不能工作硬件开发中很多企业习惯关注电路是否能正常工作器件选型是否满足性能EMC 是否通过温度、振动、老化是否满足要求供应链是否稳定。这些当然重要但在 ISO 26262 下还不够。功能安全视角下的硬件开发还要进一步关注硬件随机失效会不会导致安全目标失效关键元器件失效后系统是否能检测诊断覆盖率是否足够是否存在单点故障是否存在潜伏故障是否存在共因失效或相关失效安全机制失效后是否还能被发现比如一个电压采样通道失效BMS 是否能发现一个转角传感器输出异常转向系统是否能识别一个通信芯片卡死控制器是否能进入安全状态一个功率器件短路系统是否有保护机制硬件功能安全不是简单证明“硬件正常时能工作”而是证明“硬件异常时不会造成不可接受的风险”。企业在硬件开发中通常需要围绕硬件安全需求、硬件架构、安全分析、失效率评估、诊断机制、硬件集成验证等建立证据。对于芯片、传感器、控制器、执行器、域控制器供应商来说还需要向下游提供清晰的安全资料包括安全假设、使用限制、故障模式、诊断要求和集成注意事项。2.第二条关键线供应商不能只交产品还要交安全假设和安全证据汽车功能安全落地很难只靠主机厂一家完成。一辆车的 E/E 系统往往由多个供应商共同参与芯片供应商、传感器供应商、控制器供应商、执行器供应商、基础软件供应商、操作系统供应商、算法供应商、工具链供应商、测试服务供应商、云端或车联网平台供应商。如果供应链之间只交付硬件、软件和接口文档而不交付安全相关资料整车层面的功能安全很难闭环。常见问题包括供应商没有说明安全机制供应商没有说明失效假设供应商没有说明使用限制供应商没有说明 ASIL 适用范围供应商没有说明诊断覆盖能力供应商没有提供安全手册供应商交付的软件模块无法追溯需求主机厂不知道供应商组件能不能用于目标 ASIL系统集成后发现安全假设不成立。例如一个芯片供应商声明某个芯片可用于安全相关系统但前提可能是必须启用某些诊断功能、必须按特定时序初始化、必须定期执行自检、必须满足特定供电和时钟约束。如果主机厂或 Tier 1 没有理解这些安全假设就可能在集成时破坏原本的安全设计。因此功能安全供应链管理不能只看价格、性能和交期还要看安全能力和安全证据。企业在供应商管理中应重点关注供应商是否具备功能安全开发流程供应商交付件是否明确 ASIL 能力是否提供 Safety Manual是否提供 FMEDA、FMEA、FTA 等安全分析资料是否说明安全机制和诊断要求是否说明使用假设和限制条件是否支持安全相关问题追溯和变更管理是否能配合整车或系统级安全确认功能安全不是单点合规而是供应链协同合规。三、实战落地指南企业应该怎么做 ISO 26262ISO 26262 不是只提出原则它对应的是一整套工程落地活动。企业如果要真正建立功能安全能力可以按以下路径推进。建议一先建立功能安全管理体系怎么做明确公司级功能安全方针明确功能安全经理、安全工程师、项目经理、系统、硬件、软件、测试、质量等角色职责建立功能安全开发流程建立安全计划模板建立确认措施和独立评审机制建立功能安全问题管理和升级机制将功能安全活动嵌入产品开发流程。重点输出功能安全管理流程、项目安全计划、角色职责矩阵、确认措施计划、功能安全评审记录、安全问题跟踪记录、功能安全认可或释放记录企业建议不要把功能安全只放在质量部门或认证部门。功能安全必须进入研发体系否则很容易变成“项目后期补资料”。建议二做好 Item Definition 和 HARA怎么做定义分析对象的功能边界明确功能输入、输出、接口和依赖关系明确运行场景和使用条件识别可能的故障行为分析故障行为在不同场景下的危险事件根据严重度、暴露率、可控性确定 ASIL形成安全目标。重点输出Item Definition、功能边界说明、接口说明、运行场景说明、HARA 表ASIL 评估结果、Safety Goal 清单企业建议HARA 不要只由一个人闭门完成。建议系统、软件、硬件、测试、整车、功能安全、质量、供应商共同参与否则容易漏掉真实使用场景和系统接口风险。建议三建立从安全目标到安全需求的追溯链怎么做将安全目标分解成功能安全要求进一步形成技术安全要求分配到系统、硬件、软件和外部接口明确每条安全要求的验证方法在需求管理工具中建立追溯关系变更时进行影响分析。重点输出功能安全概念 FSC、技术安全概念 TSC、系统安全需求、硬件安全需求、软件安全需求、接口安全需求、需求追溯矩阵、变更影响分析记录企业建议追溯链不要等项目结束再补。安全目标、安全需求、设计、测试用例、测试报告、缺陷单之间应在开发过程中持续维护。建议四开展系统、硬件、软件安全分析怎么做对系统架构进行安全分析识别单点故障、潜伏故障、相关失效和共因失效开展 FMEA、FTA、DFA 等分析评估硬件随机失效风险识别需要增加的诊断机制、监控机制、冗余机制和降级策略将安全分析结果反向更新设计。重点输出系统 FMEA、硬件 FMEA、软件 FMEA、FTA、DFA、FMEDA、安全机制清单、故障处理策略、安全状态定义企业建议安全分析不是为了生成表格而是为了发现设计漏洞。每一项高风险失效都应该能看到对应的安全措施、验证方法和责任人。建议五围绕安全要求开展验证与确认怎么做根据安全需求设计测试用例开展软件单元测试开展软件集成测试开展硬件集成测试开展系统集成测试开展故障注入测试开展边界值、异常值、通信中断、超时、传感器失效等测试开展整车或台架安全确认形成测试报告和安全证据。重点输出测试计划、软件单元测试报告、软件集成测试报告、硬件测试报告、系统集成测试报告、故障注入测试报告、安全确认报告、测试覆盖率报告、问题关闭记录企业建议测试不能只覆盖正常功能路径。功能安全测试必须覆盖故障路径包括传感器异常、通信异常、执行器异常、供电异常、超时异常、数据越界、状态机异常等。建议六建立 Safety Case证明安全不是靠口头承诺怎么做整理功能安全开发过程中的关键证据说明安全目标如何得到满足说明安全要求如何分解和验证说明安全分析如何支撑设计说明测试结果如何证明安全机制有效说明已知限制、假设和残余风险形成完整的安全论证。重点输出Safety Case、安全论证结构、安全目标满足性说明、安全证据清单、残余风险说明评审结论、功能安全释放建议企业建议Safety Case 不是把所有文件打包在一起而是要形成一条清晰的安全论证逻辑为什么这个产品在定义范围内是可接受安全的。4. 测试怎么测功能安全测试不是只测“功能正常”ISO 26262 下的测试重点不是证明系统“正常时能用”而是证明系统“异常时可控”。企业可以围绕以下几类开展测试。4.1 故障注入测试测试目的验证系统在关键故障发生时是否能够检测、告警、降级或进入安全状态。测试对象传感器信号、控制器输入输出、通信总线、执行器反馈、电源电压时钟信号、存储器、软件状态机、关键算法输入、测试关注点故障是否能被检测检测时间是否满足要求系统是否进入预期安全状态是否触发告警是否避免危险输出故障恢复后系统是否按设计恢复测试示例断开传感器信号注入异常电压值模拟 CAN 报文丢失、延迟、错误模拟执行器无响应模拟软件任务超时模拟存储器校验失败模拟双通道信号不一致。4.2 安全机制验证测试目的验证设计中的安全机制是否真实有效。常见安全机制包括冗余设计、合理性检查、范围检查、超时监控、看门狗、CRC 校验、Alive Counter、E2E 保护、自检机制、故障诊断、降级控制、安全关断、驾驶员告警测试关注点安全机制是否按设计触发是否存在漏检是否存在误触发故障反应是否过慢降级策略是否清晰安全机制本身失效后是否能被发现4.3 软件安全测试测试目的验证软件安全需求是否被正确实现。测试内容软件单元测试软件集成测试边界值测试异常输入测试状态机测试接口测试数据有效性测试资源占用测试任务调度测试回归测试。测试关注点每条软件安全需求是否有测试用例关键分支是否覆盖异常输入是否被处理无效信号是否被拒绝或降级状态切换是否符合安全设计软件变更后是否重新测试4.4 系统级安全确认测试目的验证系统在真实或代表性场景下是否满足安全目标。测试方式台架测试、HIL 测试、SIL 测试、整车测试、封闭场地测试、道路场景回放、仿真测试、故障注入联合测试测试关注点安全目标是否被满足系统是否避免危险行为驾驶员是否能理解告警降级模式是否可控故障发生后车辆是否仍处于安全状态测试结果是否能支持 Safety Case企业建议系统级安全确认不能只依赖软件仿真。对于高 ASIL 相关功能通常需要结合仿真、台架、HIL、实车等多种方式形成证据链。5. 常见误区拿到证书不等于产品一定安全很多企业容易把 ISO 26262 理解成“通过认证”。但功能安全的本质不是一张证书而是一套持续运行的工程能力。常见误区包括误区一认为 ISO 26262 只是流程认证。实际上ISO 26262 要求流程和产品设计同时落地。流程不落到设计、代码、硬件和测试中就没有实际安全价值。误区二认为测试通过就代表功能安全。测试只能证明某些场景下满足要求不能替代前期 HARA、安全概念、安全架构和安全分析。误区三认为软件团队自己就能完成功能安全。功能安全涉及系统、硬件、软件、测试、质量、供应商和整车集成不是单一软件团队能独立完成的。误区四认为供应商说“支持 ASIL D”就可以直接使用。ASIL 能力必须结合具体使用场景、系统架构、安全假设和集成方式判断不能只看宣传口径。误区五认为功能安全只适用于智驾。实际上制动、转向、动力、高压、电池、底盘、车身、座舱、车联网等多个 E/E 系统都可能涉及功能安全。
1.第一条关键线硬件功能安全不能只看电路能不能工作硬件开发中很多企业习惯关注电路是否能正常工作器件选型是否满足性能EMC 是否通过温度、振动、老化是否满足要求供应链是否稳定。这些当然重要但在 ISO 26262 下还不够。功能安全视角下的硬件开发还要进一步关注硬件随机失效会不会导致安全目标失效关键元器件失效后系统是否能检测诊断覆盖率是否足够是否存在单点故障是否存在潜伏故障是否存在共因失效或相关失效安全机制失效后是否还能被发现比如一个电压采样通道失效BMS 是否能发现一个转角传感器输出异常转向系统是否能识别一个通信芯片卡死控制器是否能进入安全状态一个功率器件短路系统是否有保护机制硬件功能安全不是简单证明“硬件正常时能工作”而是证明“硬件异常时不会造成不可接受的风险”。企业在硬件开发中通常需要围绕硬件安全需求、硬件架构、安全分析、失效率评估、诊断机制、硬件集成验证等建立证据。对于芯片、传感器、控制器、执行器、域控制器供应商来说还需要向下游提供清晰的安全资料包括安全假设、使用限制、故障模式、诊断要求和集成注意事项。2.第二条关键线供应商不能只交产品还要交安全假设和安全证据汽车功能安全落地很难只靠主机厂一家完成。一辆车的 E/E 系统往往由多个供应商共同参与芯片供应商、传感器供应商、控制器供应商、执行器供应商、基础软件供应商、操作系统供应商、算法供应商、工具链供应商、测试服务供应商、云端或车联网平台供应商。如果供应链之间只交付硬件、软件和接口文档而不交付安全相关资料整车层面的功能安全很难闭环。常见问题包括供应商没有说明安全机制供应商没有说明失效假设供应商没有说明使用限制供应商没有说明 ASIL 适用范围供应商没有说明诊断覆盖能力供应商没有提供安全手册供应商交付的软件模块无法追溯需求主机厂不知道供应商组件能不能用于目标 ASIL系统集成后发现安全假设不成立。例如一个芯片供应商声明某个芯片可用于安全相关系统但前提可能是必须启用某些诊断功能、必须按特定时序初始化、必须定期执行自检、必须满足特定供电和时钟约束。如果主机厂或 Tier 1 没有理解这些安全假设就可能在集成时破坏原本的安全设计。因此功能安全供应链管理不能只看价格、性能和交期还要看安全能力和安全证据。企业在供应商管理中应重点关注供应商是否具备功能安全开发流程供应商交付件是否明确 ASIL 能力是否提供 Safety Manual是否提供 FMEDA、FMEA、FTA 等安全分析资料是否说明安全机制和诊断要求是否说明使用假设和限制条件是否支持安全相关问题追溯和变更管理是否能配合整车或系统级安全确认功能安全不是单点合规而是供应链协同合规。三、实战落地指南企业应该怎么做 ISO 26262ISO 26262 不是只提出原则它对应的是一整套工程落地活动。企业如果要真正建立功能安全能力可以按以下路径推进。建议一先建立功能安全管理体系怎么做明确公司级功能安全方针明确功能安全经理、安全工程师、项目经理、系统、硬件、软件、测试、质量等角色职责建立功能安全开发流程建立安全计划模板建立确认措施和独立评审机制建立功能安全问题管理和升级机制将功能安全活动嵌入产品开发流程。重点输出功能安全管理流程、项目安全计划、角色职责矩阵、确认措施计划、功能安全评审记录、安全问题跟踪记录、功能安全认可或释放记录企业建议不要把功能安全只放在质量部门或认证部门。功能安全必须进入研发体系否则很容易变成“项目后期补资料”。建议二做好 Item Definition 和 HARA怎么做定义分析对象的功能边界明确功能输入、输出、接口和依赖关系明确运行场景和使用条件识别可能的故障行为分析故障行为在不同场景下的危险事件根据严重度、暴露率、可控性确定 ASIL形成安全目标。重点输出Item Definition、功能边界说明、接口说明、运行场景说明、HARA 表ASIL 评估结果、Safety Goal 清单企业建议HARA 不要只由一个人闭门完成。建议系统、软件、硬件、测试、整车、功能安全、质量、供应商共同参与否则容易漏掉真实使用场景和系统接口风险。建议三建立从安全目标到安全需求的追溯链怎么做将安全目标分解成功能安全要求进一步形成技术安全要求分配到系统、硬件、软件和外部接口明确每条安全要求的验证方法在需求管理工具中建立追溯关系变更时进行影响分析。重点输出功能安全概念 FSC、技术安全概念 TSC、系统安全需求、硬件安全需求、软件安全需求、接口安全需求、需求追溯矩阵、变更影响分析记录企业建议追溯链不要等项目结束再补。安全目标、安全需求、设计、测试用例、测试报告、缺陷单之间应在开发过程中持续维护。建议四开展系统、硬件、软件安全分析怎么做对系统架构进行安全分析识别单点故障、潜伏故障、相关失效和共因失效开展 FMEA、FTA、DFA 等分析评估硬件随机失效风险识别需要增加的诊断机制、监控机制、冗余机制和降级策略将安全分析结果反向更新设计。重点输出系统 FMEA、硬件 FMEA、软件 FMEA、FTA、DFA、FMEDA、安全机制清单、故障处理策略、安全状态定义企业建议安全分析不是为了生成表格而是为了发现设计漏洞。每一项高风险失效都应该能看到对应的安全措施、验证方法和责任人。建议五围绕安全要求开展验证与确认怎么做根据安全需求设计测试用例开展软件单元测试开展软件集成测试开展硬件集成测试开展系统集成测试开展故障注入测试开展边界值、异常值、通信中断、超时、传感器失效等测试开展整车或台架安全确认形成测试报告和安全证据。重点输出测试计划、软件单元测试报告、软件集成测试报告、硬件测试报告、系统集成测试报告、故障注入测试报告、安全确认报告、测试覆盖率报告、问题关闭记录企业建议测试不能只覆盖正常功能路径。功能安全测试必须覆盖故障路径包括传感器异常、通信异常、执行器异常、供电异常、超时异常、数据越界、状态机异常等。建议六建立 Safety Case证明安全不是靠口头承诺怎么做整理功能安全开发过程中的关键证据说明安全目标如何得到满足说明安全要求如何分解和验证说明安全分析如何支撑设计说明测试结果如何证明安全机制有效说明已知限制、假设和残余风险形成完整的安全论证。重点输出Safety Case、安全论证结构、安全目标满足性说明、安全证据清单、残余风险说明评审结论、功能安全释放建议企业建议Safety Case 不是把所有文件打包在一起而是要形成一条清晰的安全论证逻辑为什么这个产品在定义范围内是可接受安全的。4. 测试怎么测功能安全测试不是只测“功能正常”ISO 26262 下的测试重点不是证明系统“正常时能用”而是证明系统“异常时可控”。企业可以围绕以下几类开展测试。4.1 故障注入测试测试目的验证系统在关键故障发生时是否能够检测、告警、降级或进入安全状态。测试对象传感器信号、控制器输入输出、通信总线、执行器反馈、电源电压时钟信号、存储器、软件状态机、关键算法输入、测试关注点故障是否能被检测检测时间是否满足要求系统是否进入预期安全状态是否触发告警是否避免危险输出故障恢复后系统是否按设计恢复测试示例断开传感器信号注入异常电压值模拟 CAN 报文丢失、延迟、错误模拟执行器无响应模拟软件任务超时模拟存储器校验失败模拟双通道信号不一致。4.2 安全机制验证测试目的验证设计中的安全机制是否真实有效。常见安全机制包括冗余设计、合理性检查、范围检查、超时监控、看门狗、CRC 校验、Alive Counter、E2E 保护、自检机制、故障诊断、降级控制、安全关断、驾驶员告警测试关注点安全机制是否按设计触发是否存在漏检是否存在误触发故障反应是否过慢降级策略是否清晰安全机制本身失效后是否能被发现4.3 软件安全测试测试目的验证软件安全需求是否被正确实现。测试内容软件单元测试软件集成测试边界值测试异常输入测试状态机测试接口测试数据有效性测试资源占用测试任务调度测试回归测试。测试关注点每条软件安全需求是否有测试用例关键分支是否覆盖异常输入是否被处理无效信号是否被拒绝或降级状态切换是否符合安全设计软件变更后是否重新测试4.4 系统级安全确认测试目的验证系统在真实或代表性场景下是否满足安全目标。测试方式台架测试、HIL 测试、SIL 测试、整车测试、封闭场地测试、道路场景回放、仿真测试、故障注入联合测试测试关注点安全目标是否被满足系统是否避免危险行为驾驶员是否能理解告警降级模式是否可控故障发生后车辆是否仍处于安全状态测试结果是否能支持 Safety Case企业建议系统级安全确认不能只依赖软件仿真。对于高 ASIL 相关功能通常需要结合仿真、台架、HIL、实车等多种方式形成证据链。5. 常见误区拿到证书不等于产品一定安全很多企业容易把 ISO 26262 理解成“通过认证”。但功能安全的本质不是一张证书而是一套持续运行的工程能力。常见误区包括误区一认为 ISO 26262 只是流程认证。实际上ISO 26262 要求流程和产品设计同时落地。流程不落到设计、代码、硬件和测试中就没有实际安全价值。误区二认为测试通过就代表功能安全。测试只能证明某些场景下满足要求不能替代前期 HARA、安全概念、安全架构和安全分析。误区三认为软件团队自己就能完成功能安全。功能安全涉及系统、硬件、软件、测试、质量、供应商和整车集成不是单一软件团队能独立完成的。误区四认为供应商说“支持 ASIL D”就可以直接使用。ASIL 能力必须结合具体使用场景、系统架构、安全假设和集成方式判断不能只看宣传口径。误区五认为功能安全只适用于智驾。实际上制动、转向、动力、高压、电池、底盘、车身、座舱、车联网等多个 E/E 系统都可能涉及功能安全。
