企业官网建设流程全解析

个人主页：云纳星辰怀自在

座右铭：“所谓坚持，就是觉得还有希望！”

前言

案例：某BMS项目在功能安全审核时被退回，审核员指出：“Item Definition中没有描述与其他Item的接口依赖关系，HARA分析中未识别‘电池过充’这一危害场景。”项目因此延期两个月重新补充概念阶段文档。工程师无奈：“我们直接从安全目标开始写的，以为概念阶段只是走个过场。”

在ISO 26262功能安全开发中，概念阶段（Concept Phase）是整个V模型开发流程的起点，位于V模型左侧的最顶层。它的核心使命是：在相对抽象的逻辑功能层面，通过安全分析提出功能安全开发最初的安全需求。概念阶段的质量，决定了所有后续活动的方向和严格程度——概念阶段的缺陷，会像滚雪球一样被后续阶段放大。

本文将从工程实战角度彻底讲透概念阶段的四大工作包：

• 工作包1：Item Definition（相关项定义）——界定研究对象，为HARA提供唯一输入

• 工作包2：Initiation of Safety Lifecycle（安全生命周期启动）——判定开发类别，合理裁剪流程

• 工作包3：HARA（危害分析与风险评估）——识别危害事件，量化ASIL等级，导出安全目标

• 工作包4：FSC（功能安全概念）——从安全目标推导功能安全需求（FSR）

• 完整流程图与交付物清单——可直接作为项目SOP使用

适用读者：功能安全工程师、系统架构师、项目经理、审核准备人员
适用标准：ISO 26262-2018 Part 3
适用场景：新项目功能安全启动、HARA分析、概念阶段审核准备
更新时间：2026年8月

一、先说结论：概念阶段决定整个功能安全项目的成败

总结：概念阶段是功能安全开发的地基——地基不牢，后续所有工作都可能需要返工。Item Definition决定分析范围，HARA决定安全目标等级，FSC决定安全需求方向。任何一个环节的缺陷，都会在后续阶段被指数级放大。

二、概念阶段的定位与总览

2.1 概念阶段在V模型中的位置

┌──────────────────┐ │ ★ 概念阶段 │ ← V模型最顶层（左侧起点） │ Item Definition │ ← 整车级功能需求 │ HARA → SG │ ← 顶层安全目标 │ FSC → FSR │ ← 系统级安全需求 └────────┬─────────┘ │ ↓ ┌──────────────────┐ │ 系统阶段 │ ← TSR、系统架构设计 └────────┬─────────┘ │ ┌────────────┴────────────┐ ↓ ↓ ┌───────────────┐ ┌───────────────┐ │ 硬件阶段 │ │ 软件阶段 │ └───────────────┘ └───────────────┘

2.2 概念阶段包含的四大工作包

2.3 概念阶段与后续阶段的关系

概念阶段输出 → 后续阶段输入 ───────────────────────────────────────────────── Item Definition → 系统架构设计、HSI定义 安全目标（SG） → 功能安全需求（FSR）的源头 功能安全需求（FSR） → 技术安全需求（TSR）的源头 ASIL等级 → 硬件/软件的安全等级分配 安全状态/FTTI → 系统响应时间预算、硬件/软件时序设计

三、工作包1：Item Definition（相关项定义，3-5）

3.1 什么是Item？

Item（相关项）是在整车层面实现一个功能的系统或系统组合，是ISO 26262应用的最顶层对象（如ACC、AEB、VCU、BMS）。

术语层级关系：

Item（相关项）＞System（系统）＞Element（要素）

• Item= 整车级功能（如ACC），范围最大

• System= 传感器+控制器+执行器的完整链路（如ACC前向雷达系统）

• Element= 任意组成部分，范围可大可小（如一个MCU、一个软件单元）

3.2 Item Definition的五大核心内容

⚠️关键原则：Item Definition应包含HARA分析所需的所有信息（"The item definition includes all information, which is needed for the following assessment of possible hazards!"）

3.3 常见错误与正确做法

四、工作包2：Initiation of Safety Lifecycle（安全生命周期启动，3-6）

4.1 目的与核心任务

目的：根据开发类别确定后续开发路径，对生命周期进行合理裁剪，避免过度工程。

4.2 三类开发场景的判定与处理

4.3 裁剪（Tailoring）的实操要点

4.4 HARA结果作为“分水岭”

HARA分析结果 │ ├── 至少一个 ASIL ≥ B 的安全目标 │ └── ✅ 触发ISO 26262完整功能安全流程 │ → 需要：系统阶段、硬件阶段、软件阶段的完整安全活动 │ → 需要：功能安全审核、评估 │ └── 全部为 QM（ASIL A/B/C/D均无） └── ✅ 仅需标准质量管理体系（IATF 16949）开发 → 无需功能安全专项活动

五、工作包3：HARA（危害分析与风险评估，3-7）

5.1 目的

识别危害事件，量化风险等级（ASIL），导出顶层安全目标（Safety Goal）。

5.2 HARA的完整四步法

Step 1：危害分析 → 方法：HAZOP引导词 → 输出：整车级危害列表 Step 2：场景识别 → 三维度：运行模式+操作场景+环境条件 → 输出：运行场景集 Step 3：风险评估 → S（严重度）+ E（暴露率）+ C（可控性）→ ASIL Step 4：分析整理 → 危害事件 → 安全目标（SG）+ ASIL分配

5.3 Step 1：危害分析（HAZOP）

HAZOP引导词（SAE J2980）：

关键原则：

5.4 Step 2：场景识别

三维度综合识别：

关键原则：

5.5 Step 3：风险评估（S/E/C → ASIL）

Severity（S）严重度：

关键原则：评估对人的伤害，非物体损坏；保守按最坏情况评分。

Exposure（E）暴露率：

⚠️ 关键区分——暴露率评价方式的选择：

⚠️选错评价方式，ASIL等级可能直接偏差一个级别！

Controllability（C）可控性：

关键原则：

• 含驾驶员+周围人员的控制能力

• C2/C3需基于用户测试数据，而非主观判断

ASIL等级判定（简易计算法）：

5.6 Step 4：分析整理

5.7 HARA的输出物

后两项强调了HARA不是个人分析，而是需要系统化验证和独立评估的正式工程活动。

5.8 HARA示例（VCU驱动扭矩控制）

六、工作包4：FSC（功能安全概念，3-8）

6.1 目的

基于安全目标，推导功能安全需求（FSR），系统化形成功能安全方案。

6.2 FSC的核心活动

6.3 HARA到FSC的完整链路

HARA输出： 危害事件：高速巡航时非预期加速导致碰撞 ASIL等级：ASIL C 安全目标：防止非预期加速 ↓ FSC推导： FSR-1：系统应检测加速踏板传感器信号是否合理（ASIL C） FSR-2：当检测到非预期加速时，应在50ms内关闭驱动扭矩输出（ASIL C） 安全状态：驱动扭矩归零，车辆进入滑行模式 FTTI：≤ 100ms 架构分配：FSR-1→VCU信号处理模块；FSR-2→VCU执行器控制模块

6.4 FSC的输出物

七、概念阶段完整流程图与V模型映射

7.1 概念阶段完整流程图

┌─────────────────────────────────────────────────────────────────────────┐ │ 概念阶段完整工作流程 │ ├─────────────────────────────────────────────────────────────────────────┤ │ │ │ ┌───────────────────────────────────────────────────────────────────┐ │ │ │ 3-5 Item Definition（相关项定义） │ │ │ │ ├─ 整车级功能描述 │ │ │ │ ├─ 功能框图 + 接口/依赖关系 │ │ │ │ ├─ 环境与使用条件 │ │ │ │ ├─ 法规要求 │ │ │ │ └─ 外部风险降低措施 │ │ │ └───────────────────────────┬───────────────────────────────────────┘ │ │ ↓ │ │ ┌───────────────────────────────────────────────────────────────────┐ │ │ │ 3-6 Initiation of Safety Lifecycle（安全生命周期启动） │ │ │ │ ├─ 判定开发类别：全新 / 修改 / 复用 │ │ │ │ ├─ 修改/复用 → 影响分析 → 裁剪生命周期 │ │ │ │ └─ 裁剪理由记录于安全计划（Safety Plan） │ │ │ └───────────────────────────┬───────────────────────────────────────┘ │ │ ↓ │ │ ┌───────────────────────────────────────────────────────────────────┐ │ │ │ 3-7 HARA（危害分析与风险评估） │ │ │ │ ├─ Step 1：危害分析（HAZOP引导词） │ │ │ │ ├─ Step 2：场景识别（运行模式+操作场景+环境条件） │ │ │ │ ├─ Step 3：风险评估（S/E/C → ASIL） │ │ │ │ └─ Step 4：分析整理 → 安全目标（SG） │ │ │ │ 输出：HARA报告 + 安全目标 + 验证评审 + 独立评估 │ │ │ └───────────────────────────┬───────────────────────────────────────┘ │ │ ↓ │ │ ┌───────────────────────────────────────────────────────────────────┐ │ │ │ 3-8 FSC（功能安全概念） │ │ │ │ ├─ 安全目标 → 功能安全需求（FSR） │ │ │ │ ├─ 定义安全状态 │ │ │ │ ├─ 定义FTTI（容错时间间隔） │ │ │ │ ├─ 定义紧急运行时间 │ │ │ │ └─ FSR分配至系统架构要素 │ │ │ └───────────────────────────────────────────────────────────────────┘ │ │ │ │ ↓ 进入系统阶段（技术安全需求 TSR / 硬件安全需求 HSR / 软件安全需求 SSR）│ └─────────────────────────────────────────────────────────────────────────┘

7.2 概念阶段输出与后续阶段的衔接

概念阶段输出 → 后续阶段输入 ───────────────────────────────────────────────── Item Definition → 系统架构设计（系统边界定义） 安全目标（SG） → 系统阶段的技术安全需求（TSR） 功能安全需求（FSR） → 硬件安全需求（HSR）和软件安全需求（SSR） ASIL等级 → 硬件/软件的ASIL等级分配 安全状态/FTTI → 系统响应时间预算、硬件/软件时序设计

八、核心原则汇总与交付物清单

8.1 核心原则汇总

8.2 概念阶段各工作包交付物汇总

8.3 概念阶段评审检查清单

九、总结与面试高频考点

9.1 核心结论表

9.2 面试高频考点

十、参考资料

1. ISO 26262-2018. Road vehicles — Functional safety. Part 3: Concept phase.

2. SAE J2980. Considerations for ISO 26262 ASIL Hazard Classification.

3. VDA 702. Typical scenarios for HARA.

4. AUTOSAR. Functional Safety Concept Template Specification.

参考文章

• ISO26262系列: FSR到TSR转化
• ISO26262系列: MISRA C与汽车软件的安全工程学
• ISO26262系列: 故障注入：硬件注入与软件注入完整对比
• ISO26262功能安全系列: 技术安全需求（TSR）编写

​