MASS风险评估实战:一艘DOA 3货船,从危险识别到验船师审批报告
转载。
写在前面:为什么选DOA 3货船?
MASS Code定义了4个自主等级:
| 等级 | 定义 | 船上有人吗 |
|---|---|---|
| DOA 1 | 自动化决策支持 | 有 |
| DOA 2 | 远程控制,船员在船 | 有 |
| DOA 3 | 远程控制,无船员在船 | 无 |
| DOA 4 | 完全自主(AI决策) | 无 |
先说清楚一个问题:MASS Code只适用于货船。 IMO在MSC 111(2026.5.22)通过的MASS Code官方文本明确写了"The Code applies to cargo ships covered under SOLAS Chapter 1"——500总吨以上、SOLAS第I章覆盖的货船。客船不在此列。所以我这篇文章用货船做案例。
我选DOA 3货船,原因有三:
1. 它是当前最现实的商业落地场景。 挪威的Reach Remote 1已经在北海实现了DOA 3商业运营(2025年10月获NMA贸易许可),那是一艘63吨的无人货船。中国的《智能航运2030行动计划》明确提出沿海南北航线试点,舟山-洋山港的集装箱支线、渤海湾的短途货船航线,都是DOA 3货船的天然应用场景。
2. DOA 3的目前风险评估复杂度最高。 DOA 1基本是传统ISM体系的延伸;DOA 2还有船员兜底;DOA 4目前没有商业案例。DOA 3是"船上没人但还不是完全AI自主"的那个临界点——既有远程控制的通信依赖风险,又有传统航行安全的全部问题,还叠加了"船上无人应急处置"的全新挑战。
3. 它是验船师最容易遇到的新检验类型。 100艘智能船舶的目标里,短途货船和港口服务船最可能先落地。你被派去验的第一艘MASS船,大概率就是DOA 3货船——因为它直接适用MASS Code。
一、场景设定:舟山"智运1号"
我虚构一个场景,但所有技术参数基于真实项目数据和行业趋势。
1.1 船舶参数
| 项目 | 参数 | 说明 |
|---|---|---|
| 船名 | 智运1号 | 虚构 |
| 船型 | 沿海集装箱支线船(多用途货船) | 参考渤海湾"智飞"系列及中国内贸支线船型 |
| 总长 | 82m | 沿海支线货船典型尺度 |
| 型宽 | 13m | 单体船型 |
| 总吨 | 2200 GT | 远超MASS Code 500 GT适用门槛 |
| 载箱量 | 120 TEU | 甲板+舱内 |
| 载重量 | 1500吨 | 含集装箱和压载水 |
| 电池容量 | 5000 kWh | 磷酸铁锂电池 |
| 续航里程 | 80海里 | 单次充电 |
| 推进方式 | 双电机全电力推进 | 船舶主推进+艏侧推 |
| 自主等级 | DOA 3 | 远程控制,无船员在船 |
| 附加标志 | CCS i-Ship(R)(M)(I)(E) | 远程控制+智能机舱+智能集成+智能能效 |
1.2 航线参数
| 项目 | 参数 |
|---|---|
| 航线 | 舟山港 ↔ 上海洋山深水港 |
| 单程距离 | 约50海里 |
| 航行时间 | 约5小时 |
| 航速 | 巡航10节 |
| 通航环境 | 沿海航线,渔船密集,长江口商船交通流密集,能见度有时<500m |
| 每日航次 | 1个往返(2航次) |
| ROC位置 | 舟山本岛远程控制中心 |
1.3 为什么选这条航线?
舟山-洋山港是中国最繁忙的内贸集装箱支线航线之一。传统支线船运营成本高(船员6-8人工资+柴油消耗)、班次有限。DOA 3纯电支线船能解决三个痛点:零排放(满足沿海ECA排放控制区要求)、降本(无船员编制、电费低于柴油)、增班次(24小时可运营,夜间也能跑)。
但这条航线的通航环境并不简单——渔船多、雾天多、长江口交通流密集、航道窄。如果这条航线的MASS风险评估能过审,其他沿海支线航线的框架就能复用。
二、MASS风险评估的整体框架
在进入具体分析之前,先说清楚一份完整的MASS风险评估报告包含什么。
MASS Code第3章要求,所有MASS船舶必须完成系统性的风险评估,作为船旗国审批的前提条件。结合CCS《智能船舶规范》2026版和IMO FSA(综合安全评估)指南,一份能过审的风险评估报告应包含以下结构:
| 章节 | 内容 | 方法论 |
|---|---|---|
| 第1章 | 船舶与运营场景描述(ConOps) | 船舶运营场景和系统定义 |
| 第2章 | 危险识别(HAZID) | 头脑风暴+检查表 |
| 第3章 | 系统级HAZOP分析 | HAZOP方法论 |
| 第4章 | 关键场景Bow-tie分析 | Bow-tie模型 |
| 第5章 | FMEA分析(系统级) | FMEA方法论 |
| 第6章 | 风险矩阵与ALARP评估 | 风险矩阵+ALARP |
| 第7章 | 结论与建议措施清单 | 总结 |
验船师审报告时,不是逐字读,而是按检查清单逐项核验——后面我会给出那张清单。
下面逐章演示。
三、Step 1:危险识别(HAZID)
3.1 HAZID怎么做?
HAZID(Hazard Identification)是风险评估的第一步——先找出"可能出什么事"。
方法很简单但需要团队参与。典型团队组成:
| 角色 | 人员 | 在本场景中的职责 |
|---|---|---|
| 组长 | 风险评估工程师(第三方) | 主持讨论、控制节奏 |
| 船东代表 | 航运公司技术总监 | 提供运营场景和约束条件 |
| 设计方 | 船舶设计院电气/自动化专业 | 提供系统架构和设计依据 |
| ROC运营商 | 远程控制中心技术负责人 | 提供ROC操作流程 |
| 验船师 | CCS验船师(观察员) | 了解评估范围,确保覆盖检验要求 |
| 独立专家 | 通航安全/航海技术专家 | 提供第三方视角 |
3.2 HAZID结果:识别出的主要危险源
对于"智运1号"这条DOA 3货船,HAZID会议识别出以下12类危险源:
| 编号 | 危险源 | 类别 | 初步风险等级 |
|---|---|---|---|
| H-01 | 通信链路中断(船岸数据传输丢失) | 通信 | 高 |
| H-02 | 感知系统失效(雷达/激光雷达/相机故障) | 感知 | 高 |
| H-03 | 自主航行决策异常(AI避碰决策错误) | AI系统/导航软件 | 高 |
| H-04 | 电池热失控(锂电池起火) | 动力 | 高 |
| H-05 | 与渔船碰撞(渔船不遵守避碰规则) | 通航 | 高 |
| H-06 | 能见度不良(雾天航行) | 环境 | 中 |
| H-07 | ROC操作员疲劳/误操作 | 人因 | 中 |
| H-08 | 网络安全事件(黑客入侵控制系统) | 网络 | 高 |
| H-09 | 靠泊系统失效(自动靠泊失败) | 操作 | 中 |
| H-10 | 货物移位/危险品泄漏(无人监控) | 货物 | 中 |
| H-11 | 推进系统单侧失效(不对称推进) | 机械 | 中 |
| H-12 | GPS/北斗信号丢失或欺骗 | 导航 | 中 |
验船师审HAZID报告时的第一句话通常是:"这个清单是凭什么来的?"
如果回答是"大家坐一起想出来的"——不合格。HAZID必须基于:
- 历史事故数据(中国海事局事故报告、IMO事故统计数据库)
- 类似项目经验(Yara Birkeland、Reach Remote 1运营经验)
- 法规检查表(SOLAS货船要求+MASS Code新增要求+IMDG危险品规则)
- FSA指导词(IMO MSC-MEPC.2/Circ.12/Rev.2 附录中的危险检查表)
验船师检查清单第1项:HAZID是否有可追溯的输入依据?
3.3 初步风险筛选
12类危险源中,标记为"高"的6项需要进入HAZOP和Bow-tie详细分析;"中"的6项进入FMEA分析即可。这是风险分层的思路——不是所有风险都要用最重的分析方法,但要给出分层理由。
四、Step 2:HAZOP分析
4.1 HAZOP的基本逻辑(需分析单点故障及系统性风险)
HAZOP(Hazard and Operability Study)的核心公式:
偏差 = 引导词 × 参数
- 参数:流量、压力、温度、液位……在船舶系统里,还需要扩展为:通信延迟、传感器精度、系统响应时间等
- 引导词:No/None、More、Less、As Well As、Reverse、Other Than、Early、Late
对每个"节点"(Node)——即系统中一个可独立分析的功能单元——逐一应用引导词×参数,找出有意义的偏差,然后分析原因、后果、现有保护措施、建议措施。
4.2 节点划分
对于"智运1号",我将MASS相关系统划分为8个分析节点:
| 节点编号 | 节点名称 | 系统边界 |
|---|---|---|
| N1 | 船岸通信系统 | 卫星终端→船上网络→ROC |
| N2 | 环境感知系统 | 雷达+激光雷达+光学相机+融合处理器 |
| N3 | 自主航行决策系统 | 路径规划+避碰决策+航迹控制 |
| N4 | 电池动力系统 | 电池组+BMS+变流器+推进电机 |
| N5 | 自动靠离泊系统 | 定位+对接+系泊自动化 |
| N6 | ROC远程操控系统 | 操作台+态势显示+应急接管 |
| N7 | 货物状态监控系统 | 货物固定监测+温湿度+危险品气体检测 |
| N8 | 网络安全系统 | 防火墙+入侵检测+身份认证 |
4.3 HAZOP分析示例(节点N1:船岸通信系统)
这是验船师审报告时最关注的部分——因为通信是DOA 3的命脉。船上没人,一旦通信断了,船就是一艘失控的漂浮物。
节点定义: 船岸通信系统,从船上多链路通信终端(卫星+4G/5G+VDES)经船载网络交换机到ROC远程控制中心的端到端数据通道。
设计意图: 在航线全程(50海里,5小时航行时间)提供≥99.99%可用性的双向数据传输,包括:实时视频流(4路×1080p)、雷达数据、遥测数据(位置/航向/航速/设备状态)、ROC控制指令。
| 引导词 | 参数 | 偏差 | 可能原因 | 后果 | 现有保护措施 | 建议措施 |
|---|---|---|---|---|---|---|
| No | 通信链路 | 通信完全中断 | 卫星终端故障+4G/5G基站覆盖盲区重叠 | ROC失去对船舶的监控和控制;船舶进入失控状态 | ①三链路冗余(卫星+5G+VDES)②通信中断后自主执行"安全模式"(保向减速锚泊等待) | ①增加航线沿途5G基站覆盖热力图,标注盲区位置和持续时间②安全模式触发后自动发送VHF DSC报警③通信中断>5分钟自动启动应急锚泊程序 |
| Less | 通信带宽 | 带宽不足 | 5G基站拥塞;卫星带宽降级 | 视频流卡顿/丢帧;ROC操作员态势感知降级 | ①带宽自适应降级策略(优先保雷达数据,降视频分辨率)②ROC操作台数据缓存机制 | ①定义最低态势感知带宽阈值(如雷达数据≤500ms延迟)②带宽低于阈值时触发告警并限制航速③仿真测试拥塞场景下的降级表现 |
| More | 通信延迟 | 延迟增大 | 卫星链路切换;网络路由跳数增加 | ROC操作员控制指令延迟>2秒;避碰决策时效性不足 | ①主备链路自动切换(<3秒)②控制指令优先级QoS | ①定义不同航段的延迟容忍阈值(开阔水域≤3秒,靠泊≤500ms)②靠泊阶段强制切换到5G低延迟链路③在ROC操作台显示实时延迟值 |
| Other Than | 数据内容 | 数据被篡改/注入 | 网络攻击;中间人攻击 | ROC收到虚假船舶位置/视频;发出错误控制指令 | ①端到端加密(TLS 1.3)②控制指令数字签名验证 | ①增加数据完整性校验和异常检测算法②定期渗透测试③入侵检测系统(IDS)实时告警 |
| Reverse | 数据流向 | 异常数据回流 | 网络配置错误;交换机故障 | 网络风暴;系统不可用 | ①网络分段隔离②交换机端口限速 | ①增加异常流量检测规则②定期网络配置审计 |
| As Well As | 通信链路 | 干扰信号叠加 | 电磁干扰;同频段设备干扰 | 数据误码率上升;通信质量降级 | ①频率规划避免冲突②天线分集接收 | ①航线电磁环境调研②抗干扰能力测试报告 |
验船师审HAZOP时的关键检查点:
- 节点划分是否合理? 是否遗漏了关键功能单元?(比如很多报告会漏掉"货物状态监控"这个节点——船上没人巡检,货物移位或危险品泄漏怎么发现?)
- 引导词是否完整? 至少覆盖了No、Less、More、Other Than四个核心引导词
- 后果分析是否考虑了连锁效应?通信中断→ROC失控→船舶失控→碰撞/搁浅,这条链是否完整?
- 保护措施的独立性? "三链路冗余"听起来很好,但如果三条链路共用同一个船上交换机——交换机一坏,三链路同时失效。独立性必须验证。
- 建议措施是否可执行? "增加5G基站覆盖热力图"——谁来做?什么时候完成?验收标准是什么?
4.4 其他节点HAZOP要点
受篇幅限制,其他7个节点的完整HAZOP表格不全部展开,但列出验船师最关注的偏差:
| 节点 | 最关键偏差 | 为什么关键 |
|---|---|---|
| N2 感知 | No(感知全部失效) | 船上没人瞭望,感知全失效=瞎船 |
| N3 决策 | Other Than(AI做出非预期决策) | AI避碰决策和人类船长不一致时怎么办? |
| N4 动力 | More(电池温度过高) | 热失控前兆,DOA 3船上无人灭火 |
| N5 靠泊 | Late(靠泊动作延迟) | 靠泊是最危险的操作阶段,延迟=撞码头 |
| N6 ROC | No(操作员无法接管) | ROC是DOA 3的"虚拟船长",接管不了=无人驾驶 |
| N7 货物 | No(货物监控失效) | 船上无人巡检,监控失效=货物移位/泄漏不知情 |
| N8 网络 | Other Than(系统被入侵) | 被黑客控制=最严重的安全事件 |
五、Step 3:Bow-tie风险控制
HAZOP解决的是"系统级偏差",Bow-tie解决的是"重大事故场景的屏障完整性"。
5.1 Bow-tie的基本结构
Bow-tie(领结图)是一张可视化的风险地图:
威胁因素 → [预防屏障] → 【顶上事件】 → [恢复屏障] → 后果 ↑ 危险源
- 危险源(Hazard):具有造成伤害潜力的物质或状态
- 顶上事件(Top Event):对危险源失去控制的那一刻——这是Bow-tie的核心
- 威胁(Threats):可能导致顶上事件发生的原因
- 预防屏障(Preventive Barriers):阻止威胁导致顶上事件的措施
- 后果(Consequences):顶上事件发生后可能导致的最终结果
- 恢复屏障(Recovery/Mitigation Barriers):减轻后果严重性的措施
- 升级因素(Escalation Factors):可能使屏障失效的条件
5.2 Bow-tie分析示例:H-01 通信链路中断
这是"智运1号"最高风险场景之一。我把它做成一张完整的Bow-tie。
危险源: 船岸数据通信链路(维持DOA 3远程控制的必要条件)
顶上事件: ROC完全失去对船舶的监控和控制能力
左侧:威胁因素与预防屏障
| 威胁 | 预防屏障1 | 预防屏障2 | 预防屏障3 |
|---|---|---|---|
| T1:卫星终端硬件故障 | 双卫星终端冗余(主备自动切换<3s) | 终端健康状态实时监控+预测性维护 | — |
| T2:5G基站覆盖盲区 | 航线5G覆盖热力图+航速优化通过盲区 | VDES作为第三备用链路 | 盲区段降速航行SOP |
| T3:船上交换机故障 | 冗余交换机(主备热切换) | 网络分段隔离(单点故障不扩散) | — |
| T4:网络攻击导致通信中断 | 端到端加密(TLS 1.3) | 入侵检测系统(IDS)实时阻断 | 网络分段隔离 |
| T5:电磁干扰 | 频率规划+天线分集 | 抗干扰调制方案 | — |
验船师审查要点: 每个威胁至少要有2层独立预防屏障。"独立"的意思是:一个屏障失效不影响另一个。 比如T1的双卫星终端冗余——如果两台终端共用一个电源,电源一坏,两台同时失效。独立性要验证到硬件级。
右侧:后果与恢复屏障
| 后果 | 恢复屏障1 | 恢复屏障2 | 恢复屏障3 |
|---|---|---|---|
| C1:船舶碰撞 | 自动安全模式(保向+减速+锚泊) | VHF DSC自动报警+周围船舶预警 | AIS应急信息广播 |
| C2:船舶搁浅 | 电子海图搁浅报警+自动改向 | 应急锚泊系统自动投放 | ROC恢复控制后紧急拖航 |
| C3:货物损坏/环境污染 | 货物状态监控系统自动告警+ROC确认 | 应急隔断措施(如关闭货舱通风) | 到港后紧急货物处置 |
| C4:船舶漂流 | 自动锚泊系统 | 低位漂移模式(舵角固定+最小推进) | 救援船应急响应(2小时内到达) |
验船师审查要点: 恢复屏障的时效性。C1碰撞的后果是"秒级"的,恢复屏障1(自动安全模式)必须在通信中断后3秒内触发——这个时间要写在设计文件里,并在测试中验证。
升级因素
| 屏障 | 升级因素 | 升级因素控制 |
|---|---|---|
| 双卫星终端冗余 | 共用电源 → 同时失效 | 独立电源回路+UPS |
| 5G覆盖热力图 | 基站离线/维护未更新 | 定期(每周)覆盖图刷新+告警 |
| IDS入侵检测 | 规则库过时 | 每月更新威胁特征库 |
| 自动安全模式 | 电池电量不足无法执行 | 安全模式触发电量阈值≥20% SOC |
| 救援船2小时到达 | 恶劣海况无法出港 | 定义气象操作限制(风速>8级停航)+沿途可应急靠泊点规划 |
升级因素是Bow-tie最容易被忽视的部分——也是验船师最容易抓问题的部分。 很多设计方画了漂亮的Bow-tie图,但升级因素一栏空白。验船师会直接退回。
5.3 Bow-tie分析示例:H-08 网络安全事件
第二个Bow-tie场景——网络攻击。这是DOA 3特有的风险,传统船舶检验中几乎没有涉及。
危险源: MASS远程控制系统的网络接口(船岸通信链路、ROC内部网络、船载控制网络)
顶上事件: 攻击者获取船舶控制系统的控制权
| 威胁 | 预防屏障 |
|---|---|
| 外部网络攻击(互联网→ROC→船舶) | 防火墙+DMZ隔离 |
| 供应链攻击(第三方软件后门) | 软件供应链安全审查+代码签名验证 |
| 内部人员威胁(ROC操作员权限滥用) | 最小权限原则+操作审计日志 |
| 物理接入攻击(码头登船直连控制网络) | 物理安全+端口锁定 |
| 后果 | 恢复屏障 |
|---|---|
| 船舶被恶意操控 | 控制权强制夺回机制(物理密钥复位) |
| 数据泄露/篡改 | 数据备份+完整性校验 |
| 系统瘫痪 | 控制系统离线备份+手动应急模式 |
这个Bow-tie的核心审查点: "控制权强制夺回机制"——如果攻击者已经获取了系统控制权,你怎么夺回来?必须有不依赖网络的物理手段(如船上本地控制面板的物理钥匙复位,触发后切断远程控制链路,船舶进入安全模式)。
六、Step 4:FMEA分析
FMEA(Failure Mode and Effects Analysis)是对HAZOP和Bow-tie的补充——它从单设备/单功能的角度分析失效模式。
6.1 FMEA与HAZOP的区别
| 维度 | HAZOP | FMEA |
|---|---|---|
| 分析对象 | 系统级功能节点 | 设备/组件级 |
| 分析方向 | 偏差→原因→后果 | 失效模式→影响→严重度 |
| 适用场景 | 新系统设计阶段 | 已有设计的详细评审 |
| 输出 | 偏差清单+建议措施 | RPN排序+改进优先级 |
6.2 FMEA示例(节选:感知系统关键设备)
| 设备 | 失效模式 | 失效影响 | 严重度(S) | 发生度(O) | 探测度(D) | RPN | 建议 |
|---|---|---|---|---|---|---|---|
| 毫米波雷达 | 信号处理板故障 | 避碰感知能力降级50% | 8 | 2 | 3 | 48 | 增加第二台雷达异构冗余 |
| 激光雷达 | 光学窗口污染 | 近距离探测精度下降 | 6 | 4 | 5 | 120 | 增加自清洁装置+污染检测告警 |
| 光学相机 | 雾天能见度不足 | 视觉感知完全失效 | 7 | 5 | 2 | 70 | 增加红外热像仪补偿 |
| GPS接收机 | 信号欺骗 | 位置数据错误 | 9 | 2 | 7 | 126 | 增加北斗多频接收机交叉校验 |
| 惯性导航 | 漂移超差 | 短时定位精度下降 | 5 | 3 | 4 | 60 | 定期校准+GPS融合修正 |
RPN(Risk Priority Number)= S × O × D,范围1-1000。RPN>100的项目必须有改进措施。
验船师审FMEA时的关注点:
- RPN排序前10项是否都有措施?
- 严重度S=9或10的项目(即"可能导致人员死亡"的失效),不论RPN多少,都必须有措施——这是ALARP原则的硬性要求。
- 探测度D——很多FMEA报告的D值偏低(偏乐观),因为设计方认为自己"肯定能发现"。验船师要追问:你怎么发现的?有什么传感器或告警?MTTR(平均修复时间)多长?
七、Step 5:风险矩阵与ALARP评估
7.1 风险矩阵
把所有识别出的风险放到一张风险矩阵上:
后果严重度 ↑ │ │ C4 │ C3 │ C2 │ C1 │ 可忽略 │ 低 │ 中 │ 高 │ 高 │ 轻微 │ 低 │ 中 │ 中 │ 高 │ 严重 │ 中 │ 中 │ 高 │ 不可接受 │ 灾难性 │ 中 │ 高 │ 不可 │ 不可接受 │ │ │ │ 接受 │ └────────────────────────────────→ 发生可能性 极低 低 中等 高
对于货船,风险评估的重点在于"失控后对其他船舶和环境的威胁"。 虽然没有乘客生命安全的直接风险,但一艘失控的2200GT货船在长江口这种密集交通流中,碰撞后果同样可能是灾难性的——对方船可能有人员伤亡。
7.2 ALARP原则
ALARP(As Low As Reasonably Practicable)——"合理可行最低风险水平"。
风险分为三个区域:
- 不可接受区域:必须消除或降低,否则不批准
- ALARP区域:需要证明进一步降低风险的成本与收益严重不成比例(即花巨资只能降一点点风险),才可以接受
- 广泛可接受区域:风险足够低,无需进一步措施
验船师审批时的判断逻辑:
| 风险区域 | 验船师动作 |
|---|---|
| 不可接受 | 退回。 要求设计方增加屏障或改变设计方案 |
| ALARP | 审查ALARP论证文件——设计方必须证明已评估了所有可行的降低风险措施,并给出放弃某些措施的成本效益分析 |
| 广泛可接受 | 通过,但要求在运营阶段持续监控 |
验船师不会说"这个风险可以接受"——他只会说"基于你提交的ALARP论证,当前风险水平在合理可行范围内"。 这两个说法有本质区别:前者是验船师替你背书,后者是设计方自己背书、验船师确认论证过程合规。
八、Step 6:形成风险评估报告
8.1 报告结构
经过以上5个步骤,最终形成的风险评估报告应包含:
| 章节 | 内容 | 页数(参考) |
|---|---|---|
| 1 | 船舶与运营场景描述 | 5-8页 |
| 2 | HAZID危险识别记录 | 8-10页 |
| 3 | HAZOP分析报告(8个节点完整表格) | 30-40页 |
| 4 | Bow-tie分析图与说明(至少3个顶上事件) | 10-15页 |
| 5 | FMEA分析报告 | 15-20页 |
| 6 | 风险矩阵与ALARP评估 | 5-8页 |
| 7 | 结论与建议措施清单 | 3-5页 |
| 附录A | 团队成员资质与参与记录 | 2-3页 |
| 附录B | 参考资料与输入依据清单 | 2-3页 |
| 附录C | 建议措施跟踪表(责任人/截止日期/关闭状态) | 持续更新 |
总页数通常在80-120页。 这不是一份可以临时凑的报告——它是MASS船舶审批的核心文件,也是PSC检查官和船旗国验船师在运营阶段会反复调阅的文件。
8.2 验船师审批检查清单
以下是我作为验船师审MASS风险评估报告时用的检查清单,也是你将来如果参与MASS检验时可以直接用的工具:
A. 通用检查项
| 序号 | 检查项 | 合格标准 | 审查结果 |
|---|---|---|---|
| A1 | 报告是否有版本号和日期 | 有,且与送审图纸版本一致 | ☐ |
| A2 | 评估团队是否包含独立第三方 | 至少1名非船东/非设计方成员 | ☐ |
| A3 | 团队成员资质是否附证明 | 附录A包含资质证书复印件 | ☐ |
| A4 | 输入依据是否可追溯 | 每个危险源标注来源(事故数据/法规/经验) | ☐ |
B. HAZID检查项
| 序号 | 检查项 | 合格标准 | 审查结果 |
|---|---|---|---|
| B1 | 危险源清单是否覆盖所有MASS新增风险 | 对照MASS Code第3章附录逐项核对 | ☐ |
| B2 | 是否包含DOA 3特有风险 | 无船员应急处置、货物无人监控、ROC人因 | ☐ |
| B3 | 是否包含网络安全风险 | 至少覆盖外部攻击/供应链/内部威胁 | ☐ |
| B4 | 初步风险筛选是否有分层理由 | 每个危险源标注进入哪级分析及理由 | ☐ |
C. HAZOP检查项
| 序号 | 检查项 | 合格标准 | 审查结果 |
|---|---|---|---|
| C1 | 节点划分是否完整 | 覆盖通信/感知/决策/动力/靠泊/ROC/货物/网络 | ☐ |
| C2 | 引导词是否至少覆盖No/Less/More/Other Than | 4个核心引导词必有 | ☐ |
| C3 | 后果分析是否包含连锁效应 | 不止于"设备失效",追溯至"船舶级后果" | ☐ |
| C4 | 保护措施是否验证独立性 | 共因失效分析 | ☐ |
| C5 | 建议措施是否SMART | 有内容/责任人/截止日期/验收标准 | ☐ |
D. Bow-tie检查项
| 序号 | 检查项 | 合格标准 | 审查结果 |
|---|---|---|---|
| D1 | 顶上事件选择是否覆盖最高风险 | 至少3个Bow-tie,覆盖通信中断+网络安全+碰撞 | ☐ |
| D2 | 每个威胁是否至少2层独立预防屏障 | 验证到硬件级独立性 | ☐ |
| D3 | 恢复屏障是否有时效性要求 | 明确触发时间(如3秒内) | ☐ |
| D4 | 升级因素是否识别并控制 | 不能空白 | ☐ |
E. FMEA检查项
| 序号 | 检查项 | 合格标准 | 审查结果 |
|---|---|---|---|
| E1 | RPN>100项是否都有措施 | 逐项核对 | ☐ |
| E2 | S≥9项是否有措施 | 不论RPN | ☐ |
| E3 | 探测度D是否有传感器/告警支撑 | 不能凭主观判断 | ☐ |
F. ALARP检查项
| 序号 | 检查项 | 合格标准 | 审查结果 |
|---|---|---|---|
| F1 | 不可接受区域风险是否已消除/降低 | 矩阵图中无"不可接受"项残留 | ☐ |
| F2 | ALARP区域是否有成本效益分析 | 有定量或半定量论证 | ☐ |
| F3 | 建议措施是否有跟踪表 | 附录C持续更新 | ☐ |
G. 与CCS规范对接
| 序号 | 检查项 | 合格标准 | 审查结果 |
|---|---|---|---|
| G1 | 是否对照CCS《智能船舶规范》2026第8章远程控制要求 | 逐条核对 | ☐ |
| G2 | 是否覆盖智能靠离泊功能检验要求 | 第10.8节 | ☐ |
| G3 | ROC认证是否与风险评估关联 | ROC风险来自船舶风险评估的传递 | ☐ |
九、验船师视角:审报告时最容易出问题的5个地方
写了这么多方法论,最后说几句实话——哪些地方是设计方最容易"翻车"的。
问题1:HAZOP保护措施的"伪独立性"
最常见的问题。 报告里写"三链路冗余",但三条链路共用一个船上交换机、一个电源回路、一根天线馈线。验船师一追问"如果交换机坏了怎么办",设计方就卡住了。
验船师的标准: 独立性验证要到硬件级——不同的设备、不同的电源、不同的物理路径。如果做不到完全独立,就要标注"共因失效点"并在Bow-tie的升级因素中处理。
问题2:后果分析只到"设备级"不到"船舶级"
很多HAZOP报告的后果栏写的是"传感器失效""通信中断"——这是失效模式,不是后果。
后果要追到船舶层面:传感器失效→避碰能力降级→碰撞风险增加→可能多人伤亡。验船师要的是最后那个"多人伤亡"级别的后果评估。
问题3:ALARP论证变成"走过场"
很多报告的ALARP部分就是一句话:"经评估,所有风险均在ALARP范围内。"——这不是论证,这是结论。
ALARP论证需要: 列出所有可行的进一步降低风险的措施,逐一评估成本和风险降低效果,给出"放弃该措施"的理由。如果连一个被放弃的措施都列不出来,说明评估不够充分。
问题4:忘了船上还有货物
DOA 3货船最容易被忽视的风险是——船上没人巡检,但货物还在。 传统货船的安全体系建立在"船员定期巡舱、检查货物状态"的基础上。DOA 3把这个基础抽掉了。
很多报告的风险评估止步于"船舶操控"层面,完全没覆盖货物安全管理:
- 货物移位怎么办?(横倾→稳性丧失→倾覆?)
- 危险品集装箱泄漏怎么发现?(气体检测?温度异常?)
- 货物火灾怎么处置?(无人灭火=全损?)
- 货物状态监控系统和船舶控制系统是独立的两套系统还是耦合的?(耦合=单点失效扩散)
这些问题在HAZID阶段就必须识别为危险源,在Bow-tie中必须有对应的恢复屏障。 尤其是危险品运输——如果这艘DOA 3货船载运IMDG危险品集装箱,货物风险等级直接跳升。
问题5:测试验证计划缺失
风险评估报告不只是"纸面分析"——每一条保护措施、每一个恢复屏障,都必须有测试验证计划证明它在实际运营中有效。
很多报告在附录里完全没提测试验证。验船师会要求:
- 通信中断后安全模式的触发时间——实测过吗?
- IDS入侵检测的告警延迟——测试过吗?
- 电池热失控预警的响应时间——有型式试验报告吗?
没有测试验证的风险评估=没有完成的风险评估。
十、一些实话
1. 这篇文章里的所有表格、清单、方法论,都不是"理论上应该这么做"——它们是验船师实际审批MASS风险评估报告时会用的工具。 我把检查清单写出来了,你拿着这个去对照任何一份MASS风险评估报告,都能看出问题。
2. MASS风险评估最大的难点不是方法论——HAZOP、Bow-tie、FMEA都是成熟工具。 难点在于:MASS引入的全新风险场景(AI决策异常、网络安全、无人应急处置)缺乏历史数据和工程经验。这意味着评估团队必须真正理解MASS技术架构,而不能套用传统船舶风险评估的模板。
3. 中国的MASS风险评估能力正在快速建设。 CCS在2026版规范中已经增加了MASS相关检验要求,但验船师的实操能力培养还需要时间。目前能独立完成MASS风险评估报告审查的验船师,全国不超过50人——这个数字我在上一篇说了,现在仍然成立。
4. 如果你是船东或设计方,正在准备MASS船舶项目——请在设计初期就启动风险评估,不要等到送审前才做。 风险评估的结果会反推设计修改(比如增加冗余、修改系统架构),如果到送审阶段才发现问题,修改成本会指数级增加。
5. 如果你是验船师——这份检查清单就是你的起点。 把它打印出来,贴在办公桌上。你的第一个MASS项目可能不会很快来,但当它来的时候,你是那个能审得了报告的人。
