FSR的确认

在汽车电子功能安全开发中，功能安全需求（Functional Safety Requirements, FSR）的制定需要车厂（OEM）和供应商共同商讨定义。以下是具体分析：

---

1. 为何需要双方协商？

• 技术可行性：
  供应商掌握组件/子系统的技术细节，可评估FSR是否可实现（如硬件资源、诊断机制、性能限制等）。例如，车厂可能要求某控制器实现“单点故障度量（SPFM）≥99%”，但供应商需确认硬件设计能否满足。

• 需求可分解性：
  FSR需分解为技术安全需求（TSR）并分配给硬件（HSR）和软件（SSR）。若供应商未参与定义，可能导致需求模糊或无法落地。

• 接口与责任界定：
  FSR涉及跨系统交互（如传感器→ECU→执行器），双方需明确接口协议（如信号频率、容错机制、故障传递路径）。

• 避免后期冲突：
  早期协商可减少需求误解导致的开发返工（例如，车厂要求的诊断覆盖率可能与供应商的测试能力不匹配）。

---

2. 协商的核心内容

1. FSR的完整性与合理性：

   • 车厂提供初步FSR（基于HARA和ASIL等级），供应商评估技术可行性并提出修改建议。
   • 例如，车厂要求“在检测到通信故障后2ms内进入安全状态”，供应商需确认硬件响应时间和软件逻辑能否实现。

2. 安全机制的分工：

   • 确定哪些安全机制由车厂负责（如整车级冗余），哪些由供应商实现（如芯片级看门狗、软件自检）。

3. 验证与测试的协同：

   • 商定FSR的验证方法（如仿真测试、硬件在环测试），并明确测试数据的共享责任。

4. 变更管理：

   • 建立FSR变更流程（如需求变更时双方如何同步更新文档和设计）。

---

3. ISO 26262的要求

• Part 4: 系统级产品开发
  明确要求OEM与供应商在接口协议中定义责任边界，包括FSR的分配和验收标准（ISO 26262-4:2018, Clause 6.4.7）。

• Part 8: 支持过程
  强调供应商需参与安全需求的可追溯性分析，确保FSR→TSR→HSR/SSR的完整链路（ISO 26262-8:2018, Clause 12）。

---

4. 典型争议与解决方案

• 争议点：
  车厂可能提出高ASIL等级需求，但供应商技术能力不足（如无法满足硬件失效率要求）。

• 解决方案：

  • 双方协商降低ASIL等级（如通过架构改进或冗余设计分散风险）。
  • 调整安全目标（如放宽故障响应时间）。
  • 引入第三方技术支持或更换供应商。

---

5. 协作输出文档

1. 联合评审记录：
   记录双方对FSR的讨论结果及修改决议。
2. 接口协议（Interface Agreement）：
   明确FSR分配、验收标准、验证责任等。
3. 需求跟踪矩阵（RTM）：
   确保FSR与TSR、HSR/SSR的可追溯性。

---

结论

功能安全需求（FSR）必须由车厂和供应商共同商讨定义。车厂主导安全目标的提出，供应商提供技术可行性反馈，双方通过协商确保FSR合理、可实施，并在接口协议中固化责任分工。这一协作是ISO 26262合规性的核心要求，也是避免开发后期风险的关键。