MASS的软件怎么认证？AIML算法怎么验证？

转载。

如果你觉得MASS认证中，FMEA、FTA、SIL分配已经够复杂了——
那只是"热身"。
真正的深水区，是软件的认证，以及AI/ML算法的验证。
这篇文章，我来说清楚：为什么这是全球性难题，以及我们现在有什么可用的方法和标准。

一、先搞清楚：为什么软件认证比硬件认证难得多？
硬件认证的逻辑：一个阀门、一个传感器、一台柴油机，它的失效模式是有限的。你用FMEA可以穷举每一个组件怎么坏、坏了有什么后果。
但软件不一样。
软件不会"磨损"。软件的失效是"设计时就埋下的bug"。
一个硬件的失效频率某种程度上是可以统计的——你知道这个型号的传感器平均无故障时间是10万小时。所以你可以做概率计算（这正是SIL定量分析的基础）。
但软件故障的概率是什么？
软件Bug不是随机事件。是程序员在某个特定条件下写错了一行代码。如果条件不触发，它永远不显现。一旦触发，它100%会出错。
所以：传统的基于概率的安全分析方法，对软件来说是失效的。

二、传统软件认证：可以借鉴什么？
虽说软件认证难，但不是从零开始。其他高安全标准要求行业已经走了几十年。
2.1 DO-178C：航空软件的"圣经"
DO-178C是航空业机载软件适航认证的核心标准。
它把软件按危害严重度分为五个等级：

每个等级要求不同的开发过程严格度：

航运业可以借鉴DO-178C的地方：

• 按安全关键度分级认证的逻辑
• 需求可追溯性的要求
• 独立验证的概念

但不能照搬的地方：

• 航空软件是封闭系统，船舶是开放系统（环境复杂得多场景也更多）
• 航空软件几乎不涉及AI/ML，而MASS的核心功能很可能依赖AI
• 航空的认证成本极高（DAL A认证费用可达软件本身开发成本的3-5倍），航运业承担不起

2.2 IEC 61508-3：功能安全的软件要求
IEC 61508-3是IEC 61508标准的软件部分，专门针对安全相关系统的软件开发。
它同样按SIL等级分级（SIL 1-4），推荐不同的技术和措施：

这里有一个航运业的"撞墙点"：
看一下SIL 3和SIL 4的推荐技术——形式化方法。
什么是形式化方法？就是用数学来证明：无论在任何输入条件下，软件的行为都符合规范。
这在理论上可行，但在实践中——

• 对几千行代码的系统可以做
• 对几十万行代码的船舶自主导航系统几乎不可能
• 对包含神经网络的AI系统……数学上至今无法证明

这就是问题的核心。
2.3 ISO 26262：汽车功能安全的启发
ISO 26262是汽车行业的功能安全标准，它的软件部分（Part 6）对汽车控制器软件的开发有非常详细的规定。
和航运业最相关的一个概念：ASIL分解。
汽车行业允许你把一个ASIL D（最高安全等级）的要求分解为两个ASIL B(D)组件分别独立实现，降低每个组件的开发成本。
这对MASS的意义： 我们可能不需要整个自主导航系统都达到SIL 3。我们可以通过冗余设计——两个独立的、不同的算法并行运行——把SIL要求分解到更可管理的水平。

三、航运业自己的框架：IACS UR E26 & E27
3.1 UR E26：船舶网络韧性
UR E26（Cyber Resilience of Ships）是IACS在2022年发布、2024年1月1日起对新造船强制实施的要求。
它的核心理念是：船舶作为一个整体，必须具备网络韧性。
五个关键要求：

3.2 UR E27：系统和组件的网络安全认证
UR E27是对UR E26的"落地"——它规定了船上的关键系统和组件如何做网络安全认证。
核心要求：被UR E26识别为"关键系统"的设备和软件，必须通过产品认证（Product Certification）。
认证分三级：

E26/E27解决了软件认证的"一半问题"——网络安全。但没有解决"另一半问题"——功能安全。
也就是说：

• ✅ 你的软件是否防得住网络攻击？→ E26/E27可以审
• ❌ 你的AI算法做出的决策是否安全？→ E26/E27管不了

这才是真正的大难题。

四、AI/ML验证：全球性难题的五个维度
4.1 为什么AI/ML特别难验证？
传统软件的逻辑是确定的：
if (obstacle_distance < safe_distance) { execute_avoidance(); }
你可以测试：给1000组输入，看输出是否符合预期。
但AI/ML（尤其是深度学习）的逻辑是概率的、黑箱的：
输入：雷达图像 + AIS数据 + GPS ↓ 神经网络（几百万个参数，没人知道每一层具体在做什么） ↓ 输出：左舵15度，减速到8节
你不能简单地"测试"—因为：

1. 输入空间无限大：海上的光照、天气、海浪、船舶类型组合是天文数字
2. 输出不能穷举：AI可能在任何未见过的场景中产生不可预测的行为
3. 不可解释：你不知道它"为什么"做出了某个决策

4.2 五个维度的验证思路
尽管困难，但行业界已经在五个方向上推进：
维度一：基于场景的测试（Scenario-Based Testing）
不是随机测试，而是系统性地构造"安全关键场景"。

• 最危险场景（worst-case）：夜间、大雾、多船交叉相遇
• 边界场景（edge-case）：一艘小渔船在雷达盲区中突然出现
• 对抗场景（adversarial）：输入被人为操控的情况

目标：在这些有代表性的场景下，AI的行为是可接受的。
维度二：形式化验证（Formal Verification）——对AI"部分可用"
对于AI中的非学习部分（比如传统控制算法、规则引擎、安全包络约束），可以用形式化方法验证。
对于神经网络部分，形式化验证目前只能做有限的属性检验：

• "输出始终在安全范围内" → 在某些简单网络上可以证明
• "输入微小的扰动不会导致输出剧烈变化" → 鲁棒性验证有进展
• "决策过程符合避碰规则第X条" → 目前做不到

维度三：运行时监控（Runtime Monitoring）
既然无法在开发阶段完全验证AI，那就在运行中持续监控。
AI输出控制指令 ↓ 安全包络检查器 ├── 检查：指令是否会导致碰撞？ ├── 检查：是否符合COLREG？ └── 检查：是否超出船舶操作包络？ ↓ 如果任何检查失败 → 拒绝执行指令 → 降级到安全状态
这是目前最可行、也最被行业接受的方法。 本质上是用一个"确定性的安全监管器"来约束"不确定性的AI"。

维度四：虚拟仿真验证（Virtual Validation）
使用高保真仿真系统，大规模运行AI——不是几百个场景，而是几百万个。
关键是：基于真实数据的场景生成。

• 不是人工设计场景，而是从真实AIS/雷达数据中提取
• 用对抗生成方法（GAN）生成极端但不脱离物理规律的场景
• 统计AI在这些场景中的"安全覆盖率"

维度五：可解释AI（Explainable AI, XAI）
让AI"说出"它做决策的原因。
在MASS中，可解释性不只是"技术好玩"——在发生事故时，如果没有解释能力，你无法确定是设计缺陷、操作失误还是系统故障。
目前进展：

• ✅ 注意力可视化：AI在做决策时"看了"雷达图像中的哪个区域（类似热力图）
• ✅ 显著性图：哪些输入参数对决策影响最大
• ⚠️ 自然语言解释："我选择右转是因为左前方有一艘船"——仍处于研究阶段
• ❌ 法律级别的可追责解释：能经得起海事调查的标准——目前不存在

五、正在演进的技术标准和法规框架
5.1 海事领域

5.2 跨行业可参考的AI安全标准

5.3 SOTIF（ISO 21448）为什么特别重要？
传统功能安全（IEC 61508 / ISO 26262）只处理系统故障导致的风险。
SOTIF处理的是另一个维度：即使系统没有故障，功能本身的不足也可能导致危险。
举一个MASS的例子：
场景：AI视觉系统识别海上目标 传统功能安全的视角： 传感器硬件没有故障 ✅ 软件没有Bug ✅ → 所以系统是"安全"的？？ SOTIF的视角： 传感器在"硬件正常"的情况下，对小型渔船在逆光条件下的识别率只有60% ❌ → 即使没有"故障"，这个功能也是不安全的 → 需要改进算法、添加互补传感器、或限制在这种条件下使用自主功能
MASS验证如果只做"功能安全"而不做"SOTIF"，等于只验了一半。

六、行业界如何合力突破？
这不是一家船级社、一个船厂、一个技术公司能解决的问题。需要跨行业合作。
6.1 当前的关键行动
1. 建立MASS AI验证的"标准场景库"
就像航空业的"标准大气条件"一样。必须有一套全球接受的MASS验证场景：

• 代表真实海上航行挑战
• 足够覆盖安全关键场景
• 标准化、可重复

2. 推进"安全论证"（Safety Case）方法
UL 4600和RBAT的核心理念：不是罗列"我们做了哪些测试"，而是构建一个完整的逻辑链条：
"我们认为这个系统是安全的，因为[这些前提条件成立] + [这些分析支撑] + [这些测试验证] + [这些运行监控保证]。如果任何前提条件发生变化，我们将[回溯+修改]。"
3. 建立分级认证框架
不是所有AI都要按最高标准认证。按AI在船舶安全中的角色分级：

4. 国际合作机制

• IMO正在推进MASS Code强制化（2032年）
• IACS各成员船级社正在开发统一的MASS审图指南
• EU的EMSA RBAT框架已经提供了方法论基础
• 中国CCS的智能船舶规范也在持续迭代

关键：各国、各船级社的方法论要协调统一，不能各搞一套。 否则对一个全球性的航运业来说，是灾难。

七、总结：你现在该做什么？

最后一句实话：
AI/ML在船舶上的应用不会等你准备好了再上路。
技术已经在跑了。行业必须追上。
而"追上"的方式不是制定更多规则——规则永远是滞后的。
真正有效的方式是：把方法学建好，让每一个引入AI的系统都经受住体系化的安全论证。