FSR的确认

最新推荐文章于 2025-07-07 21:34:18 发布

原创最新推荐文章于 2025-07-07 21:34:18 发布 · 514 阅读

CC 4.0 BY-SA版权

文章标签：

5 篇文章

订阅专栏

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

技术可行性：
供应商掌握组件/子系统的技术细节，可评估FSR是否可实现（如硬件资源、诊断机制、性能限制等）。例如，车厂可能要求某控制器实现“单点故障度量（SPFM）≥99%”，但供应商需确认硬件设计能否满足。
需求可分解性：
FSR需分解为技术安全需求（TSR）并分配给硬件（HSR）和软件（SSR）。若供应商未参与定义，可能导致需求模糊或无法落地。
接口与责任界定：
FSR涉及跨系统交互（如传感器→ECU→执行器），双方需明确接口协议（如信号频率、容错机制、故障传递路径）。
避免后期冲突：
早期协商可减少需求误解导致的开发返工（例如，车厂要求的诊断覆盖率可能与供应商的测试能力不匹配）。

FSR的完整性与合理性：
- 车厂提供初步FSR（基于HARA和ASIL等级），供应商评估技术可行性并提出修改建议。
- 例如，车厂要求“在检测到通信故障后2ms内进入安全状态”，供应商需确认硬件响应时间和软件逻辑能否实现。
安全机制的分工：
- 确定哪些安全机制由车厂负责（如整车级冗余），哪些由供应商实现（如芯片级看门狗、软件自检）。
验证与测试的协同：
- 商定FSR的验证方法（如仿真测试、硬件在环测试），并明确测试数据的共享责任。
变更管理：
- 建立FSR变更流程（如需求变更时双方如何同步更新文档和设计）。

Part 4: 系统级产品开发
明确要求OEM与供应商在接口协议中定义责任边界，包括FSR的分配和验收标准（ISO 26262-4:2018, Clause 6.4.7）。
Part 8: 支持过程
强调供应商需参与安全需求的可追溯性分析，确保FSR→TSR→HSR/SSR的完整链路（ISO 26262-8:2018, Clause 12）。