汽车电子功能安全标准ISO26262解析（二）——需求部分
1. 对需求的要求
When claiming compliance with ISO26262, each requirement shall be complied with.
当要求产品满足ISO26262标准时，每一条需求都应该满足。
The requirements for recommendations of each subclause shall be complied with for ASIL A, B, C and D, if not stated otherwise. These requirements and recommendations refer to the ASIL of the safety goal. If ASIL decomposition has been performed at an earlier stage of development, in accordance with ISO26262-9, the ASIL resulting from the decomposition shall be complied with.
(1) 依据ISO26262-9对需求进行分解；
(2) 根据分解的结果，确定每一条需求的ASIL等级要求。
1. 功能安全需求的来源
(1) 相关项定义（Item Definition）
明确系统的功能边界、接口、运行环境等，例如：
系统描述：如“电子助力转向系统（EPS）”。
功能范围：转向助力、故障检测、失效保护等。
环境条件：温度、电压、振动等。
(2) 危害分析与风险评估（HARA）
识别潜在危害并评估其严重性（S）、暴露概率（E）和可控性（C），最终确定ASIL等级（Automotive Safety Integrity Level）。
ASIL等级：A（最低）到 D（最高），QM（无需安全要求）。
示例：
危害事件 ASIL 安全目标 转向助力突然失效 ASIL D 系统需检测故障并进入安全状态 制动信号延迟 100ms ASIL C 确保制动响应时间 < 50ms
2. 功能安全需求（FSR, Functional Safety Requirements）
从安全目标（Safety Goals）细化而来，包括：
(1) 功能需求
故障检测与处理：如“EPS系统需在检测到电机故障后2ms内关闭助力”。
安全状态定义：如“系统失效时默认切换至机械转向模式”。
冗余设计：如“双路传感器校验，差异超阈值时报错”。
(2) 技术安全需求（TSR, Technical Safety Requirements）
将功能需求转化为具体技术方案，例如：
硬件需求：
“MCU需具备锁步核（Lockstep Core）检测CPU故障”（ASIL D）。
“电源模块需冗余供电，主备切换时间<1ms”。
软件需求：
“关键变量需进行ECC校验”。
“任务执行时间监控（Deadline Monitoring）”。
(3) 安全机制（Safety Mechanisms）
检测机制：如心跳包（Watchdog）、内存CRC校验。
容错机制：如降级运行、备份通道切换。
3. 需求验证与确认
(1) 需求完整性检查
是否符合安全目标？
是否覆盖所有故障模式（如单点故障、潜在故障）？
(2) 需求可行性分析
技术可实现性（如ASIL D需求可能需要硬件冗余）。
与系统其他需求（性能、成本）的兼容性。
(3) 需求追溯性
建立从安全目标→功能需求→技术需求的双向追溯矩阵，确保无遗漏。
4. 输出文档
安全计划（Safety Plan）：定义开发流程与责任。
HARA报告：危害分析与ASIL等级分配。
功能安全需求文档（FSR）：详细的安全需求描述。
技术安全需求文档（TSR）：硬件/软件实现方案。
5. 实际案例（EPS系统）
安全目标
“防止转向助力非预期失效”（ASIL D）。
功能安全需求
系统需实时监测电机电流，超限时触发故障处理。
故障发生后，应在5ms内切换至机械备份模式。
技术安全需求
硬件：采用双路电流传感器，差异>10%时报警。
软件：每1ms执行一次电机状态诊断。
关键点总结
ASIL驱动：需求严格程度取决于ASIL等级（如ASIL D需更高覆盖率）。
全生命周期覆盖：从概念到生产，需求需持续更新和验证。
协同设计：安全需求需与功能需求、系统架构同步开发。
通过ISO 26262需求阶段的规范定义，可系统性降低汽车电子系统的故障风险，确保功能安全。