夜雨聆风前面讲了 IEC 61508（通用标准）和 ISO 26262（汽车标准），但还有一个领域没提——轨道交通。地铁、高铁的信号控制系统，安全等级比汽车还高，用的是另一套标准。
这篇就来聊聊——
EN 50128 —— 轨道交通通信、信号和处理系统，软件标准。 |
一、EN 50128 是什么
全称：EN 50128 Railway applications — Communication, signalling and processing systems — Software for railway control and protection systems。
一句话翻译：轨道交通信号系统的软件功能安全标准。
它属于 EN 5012X 系列的一环：
| EN 50126 | ||
| EN 50129 | ||
| 软件级：安全相关软件 |
三个标准的关系：50126 管系统 → 50129 管硬件 → 50128 管软件。轨交安全项目三个都要过，但做软件的，核心就是 50128。
二、SIL 等级和软件的关系
EN 50128 沿用 IEC 61508 的 SIL 1~4 分级，但对软件侧的要求更具体：
SIL4 是软件侧最高的安全完整性等级。简单说：你的代码如果出了问题，可能直接导致人员伤亡——所以要求最严。
这不是"代码写好一点"就行的事，是整个开发方式都要按标准来。
三、V 模型：每个阶段要交什么
EN 50128 要求用 V 模型开发。左边是设计，右边是验证，左右一一对应。
看这个标准第一遍的时候，觉得就是画个 V 字然后对着填表格。后来发现不是——每个阶段都有必须交付的文档和记录，审计的时候一条条对，缺了就不通过。
注意一件事：左边设计的同时，右边验证的计划就要写好。不是写完代码再想怎么测，是设计阶段就把验收条件定了。这是 V 模型最核心的思路——设计和验证是同步的，不是先做后测。
审计的时候，会对照着看：你的单元测试用例是不是覆盖了详细设计的每一条需求？如果没有，缺了哪条？为什么缺？这些都要解释。
四、SIL4 比别的等级多出来的东西
EN 50128 对 SIL4 有一些其他等级不需要的东西，这些是 SIL4 项目中普遍能感受到的差异：
① 形式化方法 SIL1~3 可以用自然语言写设计文档，SIL4 要求用半形式化或形式化方法描述。 实际做法：状态机图、决策表、结构化文字——不一定要上数学证明，但必须有结构化的表达方式，不能用纯自然语言糊弄。 |
② 多样化编程（Diverse Programming） SIL4 要求关键软件有独立的二次实现，用不同的人、不同的方法，确保同一个需求不会以同样的方式出错。 实际做法：不是所有模块都要双写，而是安全功能模块要有多样化设计——可以是一个主程序+一个独立监控器，架构上做冗余。 |
③ 独立验证与评估（IV&V） SIL4 要求验证由独立于开发团队的人员执行。自己写的代码不能自己审。 实际做法：代码审查必须有非编写者的签名。单元测试可以开发自己跑，但集成测试和系统验证必须独立团队执行。 |
④ 100% 软件代码覆盖率 SIL1~3 对覆盖率有递增要求，SIL4 要求语句覆盖 + 分支覆盖 + MC/DC 全部 100%。 这个我在上一篇详细写过了，不重复。只想说一句：100% 不是目标，是底线——因为安全关键系统的每一行代码，都必须被证明是对的。 |
五、标准要求 vs 开发者每天做的事
标准写的是"要做什么"，翻译成"开发者每天做什么"：
这些不是选做的，是每条都要做、每条都要有记录。审计的时候，如果某条找不到记录，就是不符合项（Non-Conformity）。
六、SIL4 等级的常见踩坑
坑 1：改一行代码要走完整个变更流程 修一个拼写错误级别的问题，要走：问题单 → 代码修改 → 代码审查 → 回归测试 → 记录存档。 刚开始碰到的时候觉得这也太慢了。后来理解了——你不知道这"一行改动"会不会引发别的什么。流程不是走形式，是逼你想清楚。 |
坑 2：工具鉴定比写代码还烦 编译器、静态分析工具、测试框架——只要是用来生产安全相关软件的工具，都要做工具鉴定（Tool Qualification），证明这个工具本身不会引入错误。 常见做法：编译器用行业主流版本 + 厂商认证包 + 已知缺陷清单对照。不做鉴定的话，工具产出的一切结果审计都不认。 |
坑 3：审查记录比代码本身还长 标准要求"每条代码变更都要有审查记录"。实际执行下来，一个模块的审查记录页数可能比代码文件还长。 推荐做法：用 AI 先做一轮自动审查，把发现的问题和审查结论生成记录模板，人只需要在上面补充和签名。审查记录从 2 天缩短到半天。 |
七、EN 50128 和 ISO 26262 的关键区别
如果你同时了解 ISO 26262，这里标几个核心差异：
| 行业特点 | 长生命周期（30年）、修改极少、安全第一 |
最关键的区别在最后一行：轨交系统生命周期 30 年，代码写完可能十几年都不动，但一旦出事就是大事。所以标准对"过程可追溯"的要求比汽车更严——不是为了创新，是为了几十年后还能证明"当时的代码是对的"。
而汽车行业迭代快，ISO 26262 在流程上给了一些弹性。但 ASIL D 和 SIL4 的核心要求本质上是一致的：证明你的代码不会在安全场景下失效。
八、如果你想入行功能安全
碰到过 SIL4 项目的人回头看，几个建议：
EN 50128 这篇写得比较"实"，因为没有太多理论要讲——对着标准写代码、跑审查、做交付物，核心就是：标准不复杂，复杂的是每一条都做到位。
如果这篇让你对功能安全标准有了更具体的认识，点个在看。
我是会摸鱼的程序员，在一家做控制系统的公司写嵌入式 C，研究怎么用 AI 把重复工作干掉。 |
