EPS产品如何按照ISO 26262功能安全V模型完成系统性开发

从Item定义、HARA、安全概念到系统/硬件/软件验证确认的端到端开发框架

说明：本文档将已生成的PPT页面图片插入到对应章节位置，并在每页图片下方补充工程解释、关键表格和参考来源，便于作为培训材料、方案评审材料或开发流程说明书使用。

一、执行摘要

EPS是车辆横向控制链路中的安全关键系统。按照ISO 26262开展功能安全开发，应首先从车辆级风险和Item边界出发，而不是从某个ECU或软件模块直接开始。项目需要用HARA确定ASIL和安全目标，用FSC/TSC把安全目标分解为系统、硬件和软件安全需求，再通过安全分析、故障注入、HIL、台架、整车确认和功能安全评估完成证据闭环。

二、PPT页面与对应开发说明

1. 总览：EPS功能安全V模型开发框架

图 1：PPT对应页面——EPS产品如何按照ISO 26262功能安全V模型完成系统性开发

本文件围绕电动助力转向系统（Electric Power Steering，EPS）说明如何按照ISO 26262功能安全V模型完成系统性开发。EPS直接影响车辆横向控制，因此开发目标不能停留在“功能可用”，而应形成从车辆级危害识别、安全目标设定、系统架构设计、硬件与软件实现、验证确认到量产运行监控的完整证据链。

在工程实践中，V模型的价值在于把左侧需求分解与右侧验证确认严格对应，使每一条安全需求都能够追踪到设计实现、分析结论、测试用例、执行结果、偏差处理和安全释放结论。

2. 开发目标：把EPS安全做成证据链

图 2：PPT对应页面——开发目标：把EPS安全做成证据链

EPS功能安全开发的核心目标，是把“风险可接受、需求可追踪、设计可证明、验证可闭环”转换为项目可以执行的工程体系。ISO 26262面向道路车辆E/E系统建立汽车安全生命周期，并通过ASIL决定安全活动的严谨度。

对于EPS而言，典型危害包括非预期助力、助力丢失、助力方向错误、转向响应延迟以及外部主动转向请求错误。项目应从这些车辆级危害出发，逐层建立安全目标、功能安全需求、技术安全需求、硬件/软件安全需求和验证证据。

3. Item定义：EPS系统边界决定安全责任

图 3：PPT对应页面——EPS Item边界决定安全责任

Item定义是功能安全开发的起点。它需要明确EPS的车辆级功能、系统边界、运行模式、外部接口、假设条件以及不在开发范围内的内容。边界不清会直接导致HARA场景遗漏、需求分解断点和供应链责任不清。

典型EPS Item包括驾驶员输入、扭矩/角度传感器、EPS ECU、功率驱动、助力电机、机械转向机构、供电、通信和诊断接口。对于带ADAS或自动泊车接口的EPS，还需明确外部转向请求、驾驶员覆盖优先级和故障降级策略。

4. ISO 26262安全生命周期与V模型

图 4：PPT对应页面——ISO 26262安全生命周期与V模型

ISO 26262将功能安全活动组织为覆盖概念、产品开发、生产、运行、服务和报废的生命周期。产品开发可映射为V模型：左侧完成需求和设计分解，底部完成实现与集成，右侧完成验证、确认和安全释放。

V模型的关键不是图形本身，而是每一层需求均具有对应的验证策略。EPS项目应在创建安全需求时同步定义验证方法、测试环境、通过准则和证据形式，避免在开发末端通过补测弥补前期需求不清。

5. 功能安全管理：V模型的组织底座

图 5：PPT对应页面——功能安全管理是V模型底座

功能安全管理不是开发后期补充文档，而是贯穿项目策划、角色职责、能力管理、确认措施和供应链协同的管理体系。EPS通常涉及OEM、Tier1、芯片、基础软件、标定和测试供应商，必须通过开发接口协议明确安全责任。

Safety Plan定义安全活动、里程碑、工作产品和确认措施；DIA明确各方职责和证据交付；配置与变更管理确保安全需求、模型、代码、标定和测试基线受控；独立审核和评估用于发现过程与技术盲点。

6. 概念阶段：HARA把风险转成ASIL

图 6：PPT对应页面——概念阶段：HARA把风险转成ASIL

HARA通过识别危险事件并评估严重度（S）、暴露率（E）和可控性（C）来确定ASIL。EPS危险事件需要结合车辆运行场景分析，例如高速直行时非预期转向、城市弯道中助力方向与驾驶员意图相反，或者ADAS错误请求导致车辆横向偏移。

安全目标应描述要避免的车辆级不安全状态，而不是直接规定某个具体设计方案。示例目标可以是：EPS不得产生导致车辆不可控横向偏移的非预期转向力矩；故障发生后应在规定时间内进入可控降级或安全状态。

7. FSC与TSC：从安全目标落到系统架构

图 7：PPT对应页面——FSC与TSC把安全目标落到架构

功能安全概念（FSC）回答“需要哪些功能级安全策略才能满足安全目标”，包括故障检测、输出限制、故障反应、驾驶员告警和降级策略。技术安全概念（TSC）进一步回答“这些策略由哪些系统元素实现，并需要怎样的独立性和诊断覆盖”。

以防止非预期转向力矩为例，FSC可要求传感器合理性检查、输出限扭、通信超时处理和驾驶员告警；TSC则将这些要求分配给主MCU、监控MCU或锁步核、外部看门狗、功率驱动关断路径和通信接口保护。

8. EPS安全架构：防止单点失效直达危险输出

图 8：PPT对应页面——EPS安全架构要防单点失效

高ASIL EPS架构的核心判据是：任何单一故障不得未经检测、限制或关断而直接形成危险助力。典型安全机制包括传感器冗余、合理性校验、双核/双MCU监控、外部看门狗、程序流监控、存储器ECC/CRC、电机电流监控、通信E2E保护和独立关断。

架构审查应重点关注主控制路径、独立监控路径和硬件关断路径是否可能被同一单点故障同时破坏；同时要检查电源、时钟、复位、通信和标定等共因失效来源。

9. 硬件与软件开发：分别控制随机失效和系统性失效

图 9：PPT对应页面——硬件与软件开发分别控制两类失效

硬件开发侧重控制随机硬件失效，需要从硬件安全需求出发，完成电路架构设计、FMEDA、FTA、DFA、硬件集成验证、环境试验和EMC验证。SPFM、LFM和PMHF等指标用于证明随机硬件失效导致安全目标违反的风险可接受。

软件开发侧重预防系统性失效，应围绕软件安全需求、软件架构、单元设计、编码规范、静态分析、单元测试、集成测试和嵌入式软件验证形成闭环。EPS软件尤其需要关注限扭、诊断、降级、通信保护、状态机和标定保护。

10. 安全分析与验证：贯穿每一层设计

图 10：PPT对应页面——安全分析与验证要贯穿每一层

安全分析与验证不应在项目末端集中开展，而应在需求定义、架构设计和实现过程中持续进行。EPS可在概念阶段使用HAZOP、FFMEA和STPA识别功能偏差和复杂交互风险，在系统和硬件层使用FMEA、FTA、FMEDA和DFA分析失效路径与独立性，在软件层使用接口分析和故障注入验证异常处理。

验证策略必须与需求一一对应。对于安全相关需求，应明确验证层级、测试环境、故障注入方式、通过准则、日志证据和偏差闭环规则，并在整车层面验证驾驶员可控性、故障告警有效性和安全目标满足情况。

11. 生产运行阶段：持续保持安全基线

图 11：PPT对应页面——生产运行阶段保持安全基线

ISO 26262生命周期延伸到生产、运行、服务和报废。EPS量产后仍需确保安全机制、诊断覆盖、标定参数、软件版本和维修替换不偏离已确认的安全基线。

生产端应通过EOL测试、刷写校验、版本追溯、标定签名和故障灯检查证明制造一致性；运行端应通过DTC、冻结帧和现场问题监控识别潜在风险；服务和软件升级必须触发变更影响分析和必要回归验证。

12. 落地路线图：用V模型完成系统开发

图 12：PPT对应页面——落地路线图：用V模型完成系统开发

EPS功能安全落地的最终形态，是将ISO 26262生命周期转化为阶段清晰、交付物完整、需求可追踪、证据可审计的工程路线。项目从Item定义和HARA开始，经FSC/TSC、安全架构、硬件软件实现、安全分析验证，最终进入安全释放和量产后反馈闭环。

成功的关键在于从车辆风险开始定义安全目标，坚持“一条需求一条证据”，优先保证监控与关断路径的架构独立性，并让安全分析发现的风险进入验证计划。量产后，EOL、DTC、服务工具、软件升级和现场问题仍属于安全基线管理。

三、建议的EPS功能安全工作产品清单

以下清单可作为项目策划、里程碑评审和供应链协同的基础模板。实际项目应根据Item范围、ASIL等级、组织接口和开发模式进行裁剪，但裁剪理由应被记录并经功能安全负责人确认。