2. 概念阶段总览：它在哪儿？要做什么？
好，我们正式开始聊概念阶段。很多刚接触功能安全的朋友，一上来就盯着技术细节，比如怎么算FMEDA、怎么写Safety Case。我个人习惯是，先退一步，把地图看清楚。你想想看，如果连自己在整个开发流程的哪个位置都不清楚，后面的路很容易走偏。
概念阶段，说白了就是整个功能安全开发的“地基”。地基没打好，后面盖多高的楼都悬。我在项目中见过太多返工的案例，根源往往就是概念阶段没想清楚。
2.1 概念阶段在V模型中的位置
ISO26262 参考流程是经典的V模型。概念阶段就处在V模型左上角的最前端。它连接着最开始的“系统定义”和后续的“产品开发”。
我画了张图，帮你直观理解它的位置。
从图上能看出来，概念阶段是V字左侧的起点。它不关心具体的电路怎么画、代码怎么写，它只关心一件事：这个系统到底要干什么？可能会出什么危险？
2.2 概念阶段的主要目标
概念阶段的目标，可以归纳为三个核心问题。我建议你每次做项目前，都拿这三个问题问一遍自己。
- 定义“我的系统是什么？” —— 也就是项目定义和系统定义。你得把系统的边界、功能、接口说清楚。
- 识别“哪里会出问题？” —— 也就是HARA（危害分析与风险评估）。这是概念阶段的重头戏，也是我个人觉得最有意思的部分。
- 制定“怎么避免问题？” —— 也就是功能安全概念。基于HARA的结果，定义出安全目标和安全状态。
我的经验： 很多团队在概念阶段容易犯一个错——把系统定义写得太笼统。比如只写“本系统负责控制车辆转向”，这远远不够。你需要写清楚：它和驾驶员怎么交互？它依赖哪些外部信号？失效了会怎样？我曾经在一个项目中，因为系统边界没划清楚，导致后续HARA分析时，把隔壁系统的故障也算到自己头上，白白浪费了两周时间。
2.3 概念阶段的输入与输出
搞清楚了目标，我们再来看它的输入输出。这就像做菜，你得知道需要什么原料，最后要端出什么菜。
| 类别 | 具体内容 | 说明 |
|---|---|---|
| 输入 | 项目定义 | 描述项目范围、主要功能、系统边界 |
| 输入 | 系统定义 | 详细描述系统架构、接口、运行模式、法规要求 |
| 输入 | 已知的安全相关案例 | 来自类似项目的经验或已知的失效模式 |
| 输出 | 危害分析与风险评估报告 (HARA) | 识别出的危害事件、ASIL等级、安全目标 |
| 输出 | 功能安全概念 (FSC) | 为实现安全目标而定义的功能安全要求、安全状态、容错时间等 |
| 输出 | 安全计划 (Safety Plan) | 后续安全活动的计划，包括时间、资源、交付物 |
嗯，这里要注意。输入中的“项目定义”和“系统定义”往往不是功能安全工程师一个人能搞定的。你需要和系统工程师、项目经理甚至客户一起讨论。我建议你尽早介入这些讨论，别等文档都写好了才发现信息不全。
2.4 概念阶段的核心活动流程
概念阶段内部也有一个清晰的流程。它不是一蹴而就的，而是一个迭代细化的过程。
这个流程看起来是线性的，但实际上，迭代是常态。比如你做HARA时，可能会发现系统定义里有些功能没描述清楚，那就得回头去补充系统定义。别怕迭代，这是正常的。
我曾经踩过的坑： 有一次，我们团队在HARA分析中识别出一个ASIL D的危害事件，但对应的功能安全概念里只写了一句“系统应避免该危害”。这等于没写。功能安全概念必须具体到可执行的程度，比如“系统应在10ms内检测到故障X，并进入安全状态Y，同时通过Z信号通知驾驶员”。否则，后续的设计和测试人员根本没法干活。
2.5 概念阶段的关键交付物清单
最后，我帮你梳理一下概念阶段结束时，你手里应该有哪些东西。这可以作为你的自查清单。
- 项目定义文档 —— 确认项目范围、假设条件、依赖项。
- 系统定义文档 —— 包含系统架构图、功能列表、运行模式、接口定义。
- HARA报告 —— 包含危害事件列表、ASIL等级、安全目标。
- 功能安全概念文档 —— 包含安全状态定义、容错时间间隔、功能安全要求。
- 安全计划 —— 包含后续阶段的活动计划、里程碑、交付物。
记住，这些文档不是写出来就完事了。它们会贯穿整个开发周期，是后续所有安全活动的依据。所以，写得清楚、准确，比写得快更重要。