在ISO 26262功能安全开发过程中，安全需求分析是连接危害分析、系统设计以及软件硬件开发的重要环节。通过安全需求分析，需要把安全目标进一步转化为可以实现和验证的技术要求，明确系统在故障情况下需要采取的措施。实际项目中，安全需求遗漏比较容易发生，例如某些异常场景没有覆盖、需求之间缺少关联、故障处理条件描述不完整等，都会影响后续开发和验证工作。因此，安全需求分析不仅需要定义需求内容，还需要建立完整的追踪和检查机制。

　　一、ISO 26262怎么进行安全需求分析

　　安全需求分析通常基于前期HARA和ASIL分配结果展开，需要将安全目标逐步分解到系统、硬件和软件层面。

　　1、确定安全目标输入

　　安全需求分析开始前，需要整理前阶段输出内容。

　　①、查看【Hazard Analysis and Risk Assessment】结果。

　　②、确认【Safety Goal】定义。

　　③、检查对应【ASIL等级】。

　　④、整理相关功能边界。

　　⑤、确认系统运行场景。

　　⑥、建立安全需求分析输入文件。

　　安全目标描述的是车辆层面的安全要求，而安全需求需要进一步说明系统需要具备哪些具体行为，例如检测故障、进入安全状态或者限制功能运行。

　　2、分解系统安全需求

　　系统安全需求需要描述系统如何满足安全目标。

　　①、分析安全目标实现方式。

　　②、确定需要监控的系统状态。

　　③、定义故障检测要求。

　　④、定义故障响应要求。

　　⑤、确定安全机制。

　　⑥、形成【System Safety Requirement】。

　　例如某个控制功能出现异常时，安全需求可能需要规定故障检测时间、响应方式以及系统进入的安全状态。

　　3、定义软件和硬件安全需求

　　系统需求确定后，需要继续向软件和硬件层分配。

　　①、分析系统安全需求。

　　②、确定软件实现部分。

　　③、确定硬件实现部分。

　　④、编写【Software Safety Requirement】。

　　⑤、编写【Hardware Safety Requirement】。

　　⑥、建立需求关联关系。

　　安全需求分配过程中，需要保证每个安全要求都有明确的责任对象，避免出现系统知道需要保护，但软件或硬件没有对应实现内容的情况。

　　4、明确安全机制要求

　　安全机制是实现功能安全的重要方式，需要在需求阶段描述清楚。

　　①、定义故障检测方法。

　　②、确定监控周期。

　　③、设置故障响应时间。

　　④、定义诊断覆盖要求。

　　⑤、描述恢复或降级方式。

　　⑥、记录安全机制需求。

　　安全机制不能只描述“检测异常”这类宽泛内容，需要明确检测对象、触发条件以及后续处理方式，方便后续设计和测试。

　　二、ISO 26262安全需求分析遗漏如何检查

　　安全需求遗漏通常不会直接表现为开发错误，而是在测试、评审或者系统集成阶段才暴露。因此需要通过需求追踪、场景检查和安全分析多个角度进行确认。

　　1、检查安全目标到需求的追踪关系

　　①、打开【Safety Requirement Traceability】。

　　②、查看【Safety Goal】对应需求。

　　③、确认每个安全目标都有下层需求。

　　④、检查是否存在未分配需求。

　　⑤、确认需求关系完整。

　　⑥、记录缺失项。

　　如果安全目标没有对应安全需求，说明分析过程中可能遗漏了实现要求。

　　2、检查故障场景覆盖情况

　　①、整理系统运行场景。

　　②、查看已有【Fault Analysis】结果。

　　③、检查异常输入情况。

　　④、检查通信异常场景。

　　⑤、检查传感器或执行器故障场景。

　　⑥、补充遗漏安全需求。

　　安全需求不仅针对正常工作状态，也需要覆盖故障状态下系统应该如何响应。

　　3、检查安全机制是否完整

　　①、查看当前安全机制列表。

　　②、确认每个故障是否存在检测方式。

　　③、检查故障处理逻辑。

　　④、确认是否定义安全状态。

　　⑤、检查恢复条件。

　　⑥、更新安全需求文档。

　　例如定义了故障检测，但没有说明检测后如何处理，后续软件设计阶段可能无法形成明确实现方案。

　　4、检查需求描述是否完整

　　①、查看【Safety Requirement Document】。

　　②、检查需求对象。

　　③、检查触发条件。

　　④、检查响应动作。

　　⑤、检查时间约束。

　　⑥、检查验证方法。

　　安全需求如果只描述目标，没有明确输入、输出和约束条件，后续测试阶段容易出现无法判断是否满足的问题。

　　5、通过FMEA或FTA结果反查需求

　　①、查看【FMEA分析报告】。

　　②、查看【FTA分析结果】。

　　③、确认分析中的故障是否有对应需求。

　　④、检查安全措施覆盖情况。

　　⑤、发现遗漏后补充需求。

　　⑥、重新进行评审。

　　故障分析工具可以帮助发现安全需求没有覆盖的区域，尤其适用于复杂系统。

　　三、ISO 26262安全需求分析完成后怎么确认

　　安全需求分析完成后，需要通过评审、验证和追踪确认结果能够支持后续开发。

　　1、进行安全需求评审

　　①、组织【Functional Safety Review】。

　　②、检查需求来源。

　　③、确认ASIL等级匹配。

　　④、检查需求完整性。

　　⑤、记录评审问题。

　　⑥、关闭遗留问题。

　　2、建立需求验证关系

　　①、为安全需求创建【Verification Method】。

　　②、定义测试方式。

　　③、关联测试用例。

　　④、检查验证覆盖范围。

　　⑤、确认每项需求可验证。

　　⑥、保存验证记录。

　　3、维护需求变更管理

　　①、记录安全需求版本。

　　②、检查功能变化影响。

　　③、重新评估相关安全需求。

　　④、更新追踪关系。

　　⑤、重新执行必要评审。

　　⑥、保存变更记录。

　　总结

　　ISO 26262安全需求分析的重点，是把安全目标转化为可以设计、实现和验证的具体要求。分析过程中不仅要关注功能正常运行，还需要覆盖故障状态、诊断机制以及安全响应。发现安全需求遗漏时，可以结合需求追踪、故障分析和评审流程进行检查。保持完整的需求关联关系，有助于后续软件、硬件开发以及安全验证工作的开展。