4、安全需求与概念阶段：HARA分析、安全目标、功能安全概念（FSC）在AUTOSAR中的实现
概念阶段是ISO 26262功能安全开发流程的起点，也是决定后续系统、硬件和软件安全设计方向的关键阶段。在AUTOSAR架构下，概念阶段的核心任务是将整车层面的危害识别与风险评估（HARA）转化为可落地的安全需求，并通过功能安全概念（FSC）在软件架构中实现。本章将系统梳理HARA分析的方法论、安全目标的定义与量化，以及FSC如何在AUTOSAR分层架构中映射为技术安全需求，并结合实际案例说明从危害到实现的完整链路。
4.1 HARA分析的核心原理与操作流程
HARA（Hazard Analysis and Risk Assessment）是ISO 26262第3部分定义的系统化方法，其目标是在系统定义的基础上，识别车辆在运行场景中可能出现的危害事件，并评估其风险等级，从而确定相应的安全目标和ASIL等级。HARA分析不是一次性的活动，而是需要随着系统设计迭代持续更新的动态过程。
HARA分析的核心步骤包括：场景定义（明确车辆运行的操作模式、环境条件、交通场景）、危害识别（分析系统功能失效或故障导致的潜在危害）、风险评级（对每个危害事件评估严重度S、暴露率E、可控性C）、ASIL确定（根据S/E/C组合查表得到ASIL等级）、安全目标定义（将危害事件转化为可验证的安全目标）。
| 参数 | 等级 | 说明 | 典型示例 |
|---|---|---|---|
| 严重度S | S0-S3 | 对乘员/其他交通参与者的伤害程度 | S3: 危及生命的伤害 |
| 暴露率E | E0-E4 | 车辆处于危害场景的概率 | E4: 每次行驶都发生 |
| 可控性C | C0-C3 | 驾驶员或其他人员避免伤害的能力 | C2: 一般可控 |
| ASIL | A/B/C/D | 安全完整性等级，D为最高 | S3+E4+C3 → ASIL D |
4.2 功能安全概念（FSC）的设计与分解
功能安全概念（Functional Safety Concept）是将安全目标转化为系统级安全需求的过程。FSC定义了系统如何通过安全机制实现安全目标，包括故障检测、故障响应、安全状态定义和容错时间间隔（FTTI）等关键参数。在AUTOSAR架构中，FSC的输出将直接映射到软件组件（SWC）和基础软件（BSW）的功能需求。
FSC设计的关键活动包括：安全机制选择（如传感器自检、执行器监控、信号合理性检查）、安全状态定义（如关闭系统、降级模式、跛行回家）、故障响应策略（如立即停止、延迟降级、警告提示）、FTTI分配（从故障发生到进入安全状态的最大允许时间）。
在AUTOSAR中，FSC的实现通常涉及以下映射关系：
- 安全监控SWC：负责采集安全相关信号，执行故障检测逻辑，触发安全状态。
- E2E保护：通过CRC和计数器保护安全相关通信，防止数据损坏或丢失。
- WdgM（看门狗管理器）：监控关键SWC的执行周期，检测软件卡死或时序异常。
- 错误处理（Error Handling）：通过RTE和BSW的错误传播机制，实现故障的集中管理和响应。
4.3 案例拆解：电动助力转向EPS的HARA与FSC实现
以电动助力转向系统（EPS）为例，展示从HARA到AUTOSAR实现的完整链路。EPS系统的核心功能是根据驾驶员转向输入提供助力，其安全目标涉及防止非预期转向、防止助力丢失等。
背景与约束：某中高端车型EPS系统，采用AUTOSAR 4.3架构，MCU为Infineon TC297，电机驱动为三相无刷直流电机。系统需要满足ISO 26262 ASIL D等级要求，整车FTTI要求不超过100ms。
HARA分析结果：
| 危害事件 | S | E | C | ASIL | 安全目标 |
|---|---|---|---|---|---|
| 高速行驶时非预期转向 | S3 | E3 | C3 | D | SG1: 防止非预期转向 |
| 低速时助力突然丢失 | S2 | E4 | C2 | B | SG2: 保证最小助力输出 |
| 转向过度助力 | S2 | E2 | C2 | B | SG3: 限制最大助力扭矩 |
FSC设计：针对SG1（ASIL D），设计以下安全机制：
- 扭矩传感器监控：双扭矩传感器信号交叉校验，偏差超过阈值则进入安全状态。
- 电机位置监控：通过旋变传感器和霍尔传感器冗余，检测电机转子位置异常。
- 助力扭矩限制：软件限制最大助力扭矩输出，防止过度助力。
- 安全状态定义：故障时切断助力电机驱动，同时保留机械转向能力。
AUTOSAR实现：
// SWC划分
- SafetyMonitor_SWC: 监控扭矩传感器、电机位置、电流信号
- MotorControl_SWC: 执行助力控制算法，接收SafetyMonitor指令
- E2E保护: 对SafetyMonitor到MotorControl的通信启用E2E Profile 4
- WdgM配置: 监控SafetyMonitor执行周期(10ms)，超时触发错误处理
- 安全状态: 通过RTE事件触发MotorControl进入安全模式，关闭PWM输出结果与复盘：通过上述实现，EPS系统成功通过ASIL D功能安全认证。关键经验包括：FTTI预算需要精确计算（传感器采样5ms + 软件处理10ms + 通信5ms + 执行器响应20ms = 40ms，留有60ms余量）；E2E保护需要覆盖所有安全相关通信路径；安全状态设计需要考虑机械备份能力，避免完全锁死转向。
4.4 安全需求在AUTOSAR中的追溯与验证
安全需求的追溯性是功能安全开发的核心要求。在AUTOSAR架构中，需要建立从安全目标（SG）→功能安全需求（FSR）→技术安全需求（TSR）→软件需求（SWR）→测试用例的完整追溯链。AUTOSAR的ARXML文件格式支持需求ID的标注，便于工具链自动追溯。
在实现层面，每个安全相关SWC都需要在ARXML中声明其ASIL等级，AUTOSAR的RTE和BSW会根据ASIL等级自动配置内存保护、通信保护和错误处理策略。例如，ASIL D的SWC将使用独立的内存分区，并通过E2E保护其通信接口。
验证策略包括：单元测试（验证SWC内部逻辑）、集成测试（验证SWC间通信和时序）、系统测试（验证安全机制在整车环境下的有效性）、故障注入测试（模拟传感器故障、通信中断、软件异常等场景）。在AUTOSAR环境中，可以使用工具如CANoe、vTESTstudio进行自动化测试，并通过Simulink/Stateflow进行模型在环测试。