2. 安全生命周期模型：概念阶段、系统定义阶段、风险分析阶段、系统需求阶段
各位同学，咱们今天聊聊安全生命周期模型的前四个阶段。
说实话，我见过不少项目，一上来就急着写代码、画板子。结果呢？做到一半发现需求没对齐，风险没识别，推倒重来。嗯，这就是典型的「跳过安全生命周期」的后果。
我个人习惯，拿到一个ATO项目，第一件事不是看技术方案，而是先问：我们现在处在哪个阶段？
2.1 概念阶段：搞清楚「我们要做什么」
概念阶段，说白了就是回答三个问题：
- 这个ATO系统要解决什么问题？
- 用在什么线路上？
- 和谁一起工作？
你想想看，如果连「自动驾驶到什么程度」都没说清楚，后面的安全分析就是空中楼阁。
核心产出：初步安全概念文档
里面要写清楚：系统边界、主要功能、运行环境、初步的安全目标。
我记得有一次，客户说「我们要做GoA4级别的ATO」。结果一聊，他们连站台屏蔽门联动的逻辑都没想好。这就是概念阶段没做扎实。
2.2 系统定义阶段：把「概念」变成「框架」
概念阶段是「想」，系统定义阶段是「画」。
这个阶段，我们要把系统拆开来看：
- 有哪些子系统？（比如：车载ATO、地面ATP、联锁、DCS）
- 子系统之间怎么通信？
- 人机接口在哪里？
我建议，这个阶段一定要画一张系统架构图。别小看这张图，它后面所有安全分析的起点。
避坑指南：我曾经见过一个项目，系统定义阶段把「紧急制动」功能划给了两个子系统。结果后面做风险分析时，两边都以为对方负责，差点酿成大错。所以，接口定义一定要清晰，谁负责什么，白纸黑字写下来。
系统定义阶段的输出，是一份系统定义文档。里面要包含：
- 系统功能列表
- 子系统划分
- 接口定义
- 运行模式说明
2.3 风险分析阶段：找出「会出什么事」
这个阶段，是我个人觉得最有意思，也最考验功力的阶段。
风险分析，说白了就是「找茬」。我们要找出所有可能导致危险的情况。
常用的方法有：
- PHA（初步危险分析）：从顶层往下找危险
- FMEA（失效模式与影响分析）：从部件往上找失效
- HAZOP（危险与可操作性分析）：用引导词找偏差
举个例子，ATO系统在站台区域自动驾驶时，如果速度传感器突然失效，会发生什么？
这就是一个典型的危险场景。我们要分析：
- 失效后果：可能超速、可能冲撞站台
- 严重程度：SIL4级别
- 发生概率：需要定量评估
注意：风险分析不是一次性的。随着设计深入，你会发现新的危险。所以，安全生命周期是迭代的，不是线性的。
我曾经在一个项目中，做PHA时漏掉了「无线通信中断」这个危险。结果后来现场测试时，列车在隧道里突然丢信号，紧急制动了一整列。嗯，从那以后，我每次做风险分析都会专门列一个「通信异常」的检查清单。
2.4 系统需求阶段：把「风险」变成「要求」
风险分析完了，我们知道了「会出什么事」。接下来，就要告诉设计人员：你要怎么做才能避免这些事？
系统需求阶段，就是把每个危险场景，转化成一条条具体的安全需求。
比如：
| 危险场景 | 安全需求 |
|---|---|
| 速度传感器失效导致超速 | 系统应具备双通道速度采集，任一通道失效时触发紧急制动 |
| 无线通信中断导致位置丢失 | 通信中断超过2秒，系统应进入安全降级模式 |
| 车门未关好就发车 | 车门状态信号必须通过安全继电器采集，且与牵引互锁 |
你想想看，如果没有风险分析，这些需求从哪来？拍脑袋吗？
关键点：每条安全需求都要可验证、可测试。不能写「系统应足够安全」这种废话。
我个人习惯，在系统需求阶段，会同时写一份安全需求追溯矩阵。把每条需求对应到具体的危险场景。这样后面做验证时，可以一条条核对，确保没有遗漏。
好了，这四个阶段讲完了。总结一下：
- 概念阶段：想清楚做什么
- 系统定义阶段：画清楚架构
- 风险分析阶段：找清楚危险
- 系统需求阶段：写清楚要求
这四个阶段走完，你手里就有了三份核心文档：安全概念、系统定义、安全需求。后面的设计、实现、验证，全都要靠它们。
嗯，下一章咱们聊聊「安全需求分配与系统设计阶段」，到时候我会讲讲怎么把需求分给硬件和软件。