人工智能在轨道交通安全相关应用中的思考

摘要：分析轨道交通人工智能/机器学习（ AI/ML）技术应用的安全问题，梳理其与传统安全软件相比存在的挑战。通过对标汽车行业以及通用AI/ML系列标准，结合轨道交通行业的特性，探讨一种分层安全架构，根据安全影响对轨道交通AI/ML应用方式进行分类，提出AI/ML在安全应用中的实现路径。研究给出了轨道交通AI/ML安全应用的一般原则，包括边界要加以限定，用确定性安全机制来约束模型的不确定性，在不降低系统安全水平的情况下实现智能化赋能。

关键词：轨道交通；人工智能；机器学习；功能安全；预期功能安全

中图分类号：TP18；U23

文献标识码：A

1 AI/ML引入轨道交通安全系统的基本问题

AI/ML技术具备从大量数据中学习复杂模式的能力，可以高效准确地完成复杂系统任务。对于轨道交通行业来说，存在着许多复杂的数据和场景，这些内容很难用少量的逻辑公式来说明它们所有的正常功能预期，而是要依靠即时输入、环境情况、前置指令等状况来进行自动化的运算以得到结论。由于人工控制下算力不足和传统的软件技术计算能力有限，不能实时输出，所以无法完成上述任务。将AI/ML技术在轨道交通系统中应用，是必然的技术发展趋势。

将AI/ML应用于轨道交通系统时，需要满足其功能安全的要求，使AI/ML技术达到对应功能所要求的SIL标准。按照标准《EN 50716：EN 50716：Railway Applications. Requirements for software development》（简称EN 50716）的规定传统软件的功能安全实现要经过系统需求、软件需求、软件架构、软件设计、组件实现、测试和验证等分层过程，并且要具有双向可追溯性。此外，还要求有测试验证、版本控制、独立确认及安全评价等系统保证手段。但是AI/ML技术没有软件源代码的准确追踪关系，也不能依靠封闭的流程来完成闭环式的管理，直接应用AI/ML技术，不能满足功能安全的基本条件。

当前国内外学界已围绕轨道交通AI/ML技术落地开展相关研究。国外研究多依托汽车行业AI/ML安全规范，重点研究感知模型验证、预期功能安全风险识别手段，提出基于统计置信度的模型安全论证思路，但缺少适配铁路应用的全生命周期安全架构。国内现有研究多聚焦故障诊断、客流控制等非安全应用算法优化和信息安全防护，少量文献讨论了铁路AI/ML数据治理，但也不涉及完整安全应用原则的设计。

为解决以上问题，使AI/ML技术可以满足安全要求，本文在EN 50716附录C.3的基础上，参照汽车行业的ISO标准，针对轨道交通与汽车行业的应用特点差异，结合轨道交通传统的故障安全机制，对轨道交通安全相关的AI/ML应用进行可行性分析。首先对AI/ML安全应用的概念进行定义，分析应用的安全难点。其次根据问题分析已有的研究现状，总结安全方案的研究重点。最后对已有研究的不足之处进行分析，提出AI/ML安全应用的技术框架方案。

2 EN 50716 视角下AI/ML的安全挑战

2.1 AI/ML在EN 50716中的概念基础

AI/ML技术是个范围广泛的学科，是应用和技术的集合。但是在EN 50716附录C.3中，机器学习是与轨道交通软件最相关的AI/ML领域。并不是所有的AI/ML技术都需要创建全新的标准，基于训练数据形成运行行为的机器学习模型，才是轨道交通安全软件技术面临的最大挑战。EN 50716并不认为“AI/ML相关软件天生就是不可控的”，而是允许某些AI/ML技术，在符合标准的情况下被当作普通的软件工程项目来开发，包括模型创建工具、训练算法、训练平台和运行平台软件等。当这些软件本身具有某种安全功能时，应当根据EN 50716相应的完整性等级来进行开发。但是，对于经过训练后的模型及其行为是否可以做到安全证明，标准并没有做出规定。

可以将AI/ML的研发对象分为两种。第一类是按照传统的软件生命周期来开发和验证的软件，即训练程序、数据处理程序、运行平台和支持工具等。按照EN 50716规定可以将这类对象当作常规软件纳入系统的安全完整性水平的控制当中。第二类是训练结束后产生的模型及其参数化行为，不同于传统的软件，它的行为产生源头、验证手段、可阐释性都存在不确定性，这也是该文件所要研究的标准框架的重点难点。

2.2 AI/ML的不确定性来源与影响

AI/ML的不确定性，是与传统软件确定性错误的一种对应描述。传统的安全概念中，不管是软件逻辑的缺陷，还是由于随机硬件失效造成的运算错误，错误根源都可完整追溯。但是AI/ML的不确定性并不是简单的模型计算错误，而是可证明性缺失，这种缺失是由数据驱动的方式所决定的，贯穿于整个软件的生命周期中。在根据数据来生成模型的时候，训练样本不可能包含所有的运行情况，而且模型的黑盒特性使得决策过程不可理解，或者说无法用明确逻辑关系表达；当模型被使用时，在现场出现各种低频的极端工况，再加上对抗攻击、数据漂移等，都会使运算结果更加不确定。

不论是计算决策的途径还是由于输入数据所造成的不确定性，都会造成由AI/ML技术形成的软件，其需求追溯关系不是清晰的链条，结构黑盒，验证覆盖率不明朗，预期功能受影响。这就违背了EN 50716对于高完整性的软件要求，没有基本的系统性风险控制。

如果AI/ML安全论证只是按既有的标准要求，来证明软件开发过程是否符合标准，那么就无法解决上述问题。所以除了提供传统的风险控制措施之外，除了证明训练程序、运行平台或者模型文件是按照标准要求执行了相应的措施之外，还需要表明怎样识别不确定性，监控机制是什么样的，后续又会采取哪些限制措施和约束条件。

2.3 ML与传统高完整性软件生命周期不匹配

软件生命周期里的各类活动及其成果，是软件安全完整性的依据，可以证明软件各个阶段的活动都采用了恰当的方法，以此来证实软件需求是可追踪的且功能是明确的。

传统的高安全完整性软件，想要做到需求可追溯，就要按照系统的安全需求向软件的安全需求进行分配。然后依靠结构概要设计、模块详细设计以及接口设计这些步骤来形成设计规范，依照这个规范去做代码编写。之后经过静态分析、单元测试、集成测试和需求测试等测试验证活动去证实软件的功能是否符合需求。其关键之处就是“可以解释的工程分解”。

工程师一般不会逐条编写ML模型行为规则，并且没有从需求到设计的明确规则约束，而是靠数据分布、标签质量、训练策略、模型结构和优化结果来决定需求能否被满足。从测试角度看，因为测试没有具体的规则作参照，所以即使一个模型在测试集上的效果很好，也不能作为验证证据来证明每一个系统安全需求都被准确地映射到了模型内部结构中。传统的双向追溯链就被打断了。

在功能确定性上，传统的软件测试是有需求覆盖标准的，并且有各种各样的覆盖准则，例如需求覆盖、控制流覆盖、数据流覆盖、边界覆盖和修改条件判断覆盖（Modified Condition/Decision Coverage，MC/DC）等。这些覆盖度的数据能够完全证明需求最后实现是否满足要求。

但是对于AI/ML，输入空间是高维的，如图像、多传感器融合数据和运营状态数据等，组合状态几乎是不可穷尽的，不能统计出量化的覆盖率，训练数据与测试数据也无法覆盖所有的输入状态，同样难以达到100%覆盖率。而且由于数据源本身存在统计假设，对于没有被覆盖到的情况，在实际运行时“几乎不会发生”这一假设值得怀疑，使得覆盖率缺乏信任基础。所以AI/ML测试只能算是一种基于运行设计域、数据分布、场景库、统计置信度、异常检测及运行监视的综合证明活动，并不是传统的软件测试。

2.4 AI/ML应用中的核心问题

只有控制了需求追溯和功能确定性方面的风险之后，才有可能在轨道交通安全领域里使用AI/ML。产生这些风险的原因有4个。

一是数据短板，安全应用的AI/ML数据样本要包含常规场景、边界场景以及高危低频场景。如果用AI/ML实现更复杂的功能，那么需求无法通过传统的逻辑规则来描述，所以训练数据就要提出新的更高要求。

二是模型验证不够充分，要保证模型验证的有效性。深度神经网络等模型参数很大，有复杂的映射关系，即使可以读取模型文件，但模型的安全行为无法被拆分出来进行分析，验证不够充分的模型将带来潜在安全隐患。

三是近似风险。AI/ML应用了统计近似的原理，机器学习以统计规律为基础来推广规则，不能保证百分之百地按照安全设计的初衷去工作，这就与高安全系统需要验证的要求背道而驰。

四是AI/ML技术无完整因果逻辑限制，抗攻击能力差。因为微小的输入变动就会导致输出出错，而且像数据投毒、模型篡改这种信息安全方面的危险会导致更大的问题，极易干扰系统正常运作。

3 汽车行业ISO标准与通用AI标准对比启示

3.1 ISO 26262、ISO 21448与ISO/PAS 8800研究简述

相对于轨道交通行业，由于汽车行业对于自动驾驶和车载辅助系统功能要求较高，所以比轨道交通早一步在安全系统上使用AI/ML技术，并且相关标准也更加完善。因此本文以汽车行业的AI/ML应用标准为研究对象。

在汽车行业标准体系中，标准《ISO 26262 : Road vehicles - Functional safety》（简称ISO 26262）是基础框架，面向车载电子电气系统，侧重传统功能安全领域，就硬件失效和软件缺陷可能导致的风险制定规范，并给出满足功能安全的全生命周期管控流程。标准《ISO 21448：Road vehicles - Safety of the intended functionality》（简称ISO 21448）也称SOTIF标准，主要关注预期功能安全，适用于输入和场景关系比较复杂、算法比较复杂的系统，如紧急干预系统、L1-L5级别自动驾驶系统。该标准的安全措施不是针对ISO 26262已经包含的故障，而是针对那些预期功能不符合规定、性能不够理想、可以预料到的错误使用所产生的不能接受的风险。标准《ISO/PAS 8800 : Road vehicles - Safety and artificial intelligence》（简称ISO/PAS 8800）适用范围是利用AI技术的道路车辆安全相关电子/电气系统，它侧重于由AI引起系统性错误和随机硬件故障造成的车辆功能危险侧失效。标准未规定具体的AI方法，仅提出了AI安全实现架构，明确模型验证的安全验证和应用部署流程的原则，并以此为基础建立“无不合理风险”安全保证的论据结构，完善了传统功能安全、预期功能安全技术在AI领域场景的适用支撑体系。这3个标准互相补充，共同形成了汽车行业AI/ML安全应用方案，三者的关系如图1所示。ISO 26262总体上按照传统的功能安全思路给出系统设计原则，ISO 21448主要是防止性能不足或者场景理解错误以及可以预见的误用带来的风险，ISO/PAS 8800是针对AI/ML应用引起的确定性缺失等AI特有的安全论证问题。

通用行业中，ISO/IEC JTC 1/SC 42也有部分的AI标准和技术文件，在处理EN 50716附录C.3提出的问题时，能够当作参照。这些标准并不是专门针对轨道交通的标准，但是因为它们涉及了安全应用的场景，所以起到一定的借鉴作用。其中比较重要的标准有《ISO/IEC TR 5469：Artificial intelligence - Functional safety and AI systems》（简称ISO/IEC TR 5469），给出了生命周期活动要求和安全原则，面向AI系统在安全相关系统中的应用。应用主要分为3种不同的场景，分别是AI直接实现安全相关功能，非AI功能保证AI设备安全，AI作为辅助工具来帮助安全相关功能开发。《ISO/IEC TR 24027：Information technology - Artificial intelligence (AI) - Bias in AI systems and AI aided decision making》（简称ISO/IEC TR 24027）主要是对AI系统以及AI辅助决策时产生的偏差所带来的风险进行研究，并根据不同类型的偏差源，规定在数据收集、训练、持续学习、设计、测试和使用等生命周期阶段应该采取的措施。《ISO/IEC TR 24028：Information technology - Artificial intelligence - Overview of trustworthiness in artificial intelligence》（简称ISO/IEC TR 24028）主要研究的是AI的可信性问题，列出了AI系统工程中的常见风险，并提供了建立可信性的建议措施。

3.2 轨道交通AI安全论证的启示

根据汽车行业已经取得的经验和教训，可以从中得到一些有关安全体系的启示。

第一，EN 50716已经指出过，AI/ML安全应用的困难，并不是如何让过程满足安全要求，而是如何证明通过训练得到的模型是否正确。因此AI/ML不能被当作一项单纯的软件技术，直接套用传统安全软件生命周期的各项流程要求。可以借鉴汽车行业ISO/PAS 8800，既要保持传统功能安全标准的要求，又要对AI/ML的特点采取一些有针对性的安全措施，形成一种AI技术安全应用的技术框架。

第二，传统的轨道交通安全分析是基于失效与故障来分析安全影响，并提出相应的风险缓解措施。但采用AI/ML之后，即使没有软件缺陷、硬件故障或者通信错误，也可能出现错误输出，例如由于雨雪、逆光、遮挡和站场复杂背景引起的感知模型识别障碍物错误，以及由于罕见运行场景引起的调度辅助模型推荐决策错误等。对于这种风险，可参照ISO 21448对于预期功能不足的措施和ISO/PAS 8800中对于AI/ML输出不足的措施。

第三，在轨道交通的高安全完整度系统功能上，直接证明AI/ML模型在所有场景中正确几乎是不可能的。可以借鉴汽车行业的方式，将模型正确的证明转换为系统的安全证明，也就是从证明“模型高置信度”到证明“系统级的危害避免”。不需要AI/ML独自承担安全功能，只需要加上一些安全措施，让AI/ML的不确定性被隔绝在安全层之外即可。比如，设置AI/ML外部应用限制，设置独立于AI/ML的输出监视器与规则检验器，AI/ML安全隔离层的设计是当系统出现异常时，采取降级策略等，都能保证系统层的安全风险可控。

3.3 轨道交通与汽车行业的差异

轨道交通和汽车行业虽然在功能安全方面有很多相同的地方，但也有一些不同之处。汽车行业AI/ML的应用主要是自动驾驶的功能，其风险包括道路是开放的、交通参与者种类多且有交互、环境随机性强等。但是就轨道交通而言，上述风险是可以被控制的，轨道交通线路是固定的，运行规则是确定的，运行区域是受控的，路线网络拓扑结构是明确的，还有成熟列控防护逻辑可参考。轨道交通虽然不能完全避免AI/ML的不确定性，但相对于汽车行业来说，更容易建立一个安全边界。可全面利用既有线路约束条件、列控规则、速度限制、移动授权、防护曲线以及站场拓扑，结合安全降级机制，来创建一套比汽车工业更为明晰的运行规则、AI/ML安全隔绝体系与独立的安全监督原则。

另外，AI/ML要依靠网络运行，因此在功能安全之外，还有信息安全的风险。汽车行业有《ISO/SAE 21434：Road vehicles - Cybersecurity engineering》（简称ISO/SAE 21434），它是道路车辆电子电气系统网络安全需求。对于轨道交通，也不能只把对抗性攻击当作模型鲁棒性的问题来对待，要对功能安全和网络安全分别建模、协同控制，充分考虑到对抗样本、数据投毒、模型被改动、运行时的输入攻击等信息安全方面的问题。

对比两行业异同的标准如表1所示。对于轨道交通的AI/ML安全应用标准，可以在上述分析的基础上，有目的地设计。

4 轨道交通安全相关AI的系统架构与应用边界

4.1 AI不作为唯一安全依据

轨道交通安全应用中对于AI/ML的使用要符合如下原则，即AI/ML参与感知、识别、辅助判断、提供命令参考，都必须有传统功能安全系统来保证边界和安全指令的执行。对列车安全相关的功能如速度控制、移动授权计算、进路控制等，人工智能的输出只能视为参考数据。

轨道交通安全应用中用AI/ML的一种安全架构如图2所示。在该架构中，AI/ML被用来做感知识别、规划建议或者控制请求一类的以数据为主导的任务。AI/ML智能计算出来的结果会被传输给符合已有功能安全标准的功能，用作安全决策的参照。轨道交通安全应用的安全功能，都是依靠该传统安全标准的设备来完成的。

4.2 故障安全包络层与安全监视决策层

功能安全相关的应用对于系统的不确定性有着非常严格的要求。此时AI/ML模型本身所具有的统计特性、黑盒模式、训练数据限制和结果的不可解释性就成了制约AI使用的最大障碍。为了使AI/ML的不确定性不影响到核心的安全功能，设置了一个独立的故障安全包络层以及一个安全监视与决策单元。故障安全包络层采用规则驱动方式，完成确定性的状态机转换过程。其功能是在功能安全的标准框架里限定系统的动作范围。安全监视与决策单元的功能就是通过故障安全包络层的行为边界数据去监督AI/ML，保证系统输出的确定性。

当AI/ML输出的数据与故障安全包络层相同或者满足故障安全包络层的要求时，安全监视与决策单元就用这些数据作为控制指令；如果不满足，一旦AI/ML的输出数据超出安全界限或者与故障安全包络层存在差异，那么安全监视与决策单元就丢弃这部分数据，用故障安全包络层命令取代。

该架构的主要应用原则就是用AI/ML增强系统能力、传统功能安全来确定系统边界，保证系统安全相关指令的执行。

4.3 轨道交通AI应用的场景

根据轨道交通系统的特点以及汽车ISO标准的分层方式，按照轨道交通应用的功能安全相关性，将应用划分为4种类型，如表2所示。

上述分级依据的是SIL分级，是根据功能失效的影响程度进行分类的。对功能失效影响进行分级的意义在于，不再讨论能不能用AI/ML，而是从失效结果出发讨论采用AI/ML如何满足安全要求。从安全无关应用对AI/ML没有限制，到安全至关重要应用的架构、使用限制，给出了如何将AI用于轨道交通领域的方法。

4.4 AI应用于低SIL的系统

对安全完整性等级低的系统来说，不能把AI/ML看成一个能完全接纳它的东西。SIL1代表安全功能失效带来的后果小。和高安全等级系统相比，对它们的开发、论证进行了简化，而不是完全取消安全的要求。AI/ML本身存在的问题同样会存在于SIL1系统当中。

因此，在使用AI/ML的时候，首先要判断AI/ML在系统中要执行的功能。如果AI/ML只是做非安全相关应用，不需要对AI/ML使用做出任何限制；如果AI/ML被用作低SIL应用或者它的失效不会直接影响到系统的安全状态，在这种情况下，在边界明确的前提下，进行安全论证。此时，安全论证要证明AI/ML错误输出不能直接导致不可接受的危险后果，不能违反系统的安全指标。

即使目标的安全完整性等级较低，如果AI/ML的错误会造成风险，那么就应该对AI/ML的使用保持谨慎的态度。人工智能在上述应用中还存在EN50716附录C.3所列举出来的需求追溯性差、训练数据少、训练后验证难、近似功能难以证明等缺陷。除非可以利用系统结构或者其他技术手段使AI/ML的作用变成可以被验证、被监视、被否决的；否则不应仅仅依靠AI/ML来完成安全功能的主要实现工作。

低SIL可以允许对AI/ML开发、验证和安全论证活动做裁剪，但是应与风险的严重度相符，不能缺少安全过程。针对轨道交通应用，一个合理的原则是SIL越低，AI/ML可接受的应用范围就越大，但是只要AI/ML输出进入了安全相关的决策链中，就需要保证它的不确定性被充分限制住，而且系统级危害仍然处在可以容忍的范畴内。

由此可知SIL与AI/ML在系统中并不一定相关联，除了安全相关的应用之外，在合理范围内的SIL都应考虑对于AI/ML使用的分析。根据其失效/错误的影响分析来确定如何使用技术以确保满足SIL。

5 应用路径与结论

5.1 面向轨道交通AI应用路径

结合行业标准和工程实际，在轨道交通场景下对AI/ML的使用提出6条具体的实施路径。

第一，创建AI/ML的安全论证体系。在功能安全标准要求的安全例证的基础上增加有关AI/ML的相关章节。参考ISO/IEC TR 5469对AI/ML与功能安全的关系分为3种情况：AI/ML是实现安全相关功能、AI/ML是安全功能的输入和AI/ML受其他安全机制所约束。安全例证包含以下内容：错误与失效，AI/ML错误输出或者失效时系统的反应和措施；AI/ML模型，AI/ML模型训练数据覆盖率、模型适用范围、训练场景覆盖、模型鲁棒性、输出结果可解释性、模型可控性、外部可检测性、对抗防护和AI/ML运行监测。安全论据的目的不是证明模型的准确率和正确性，而是证明AI/ML模型不会产生新的系统级危害，也不会改变系统危害的已有控制效果。

第二，将数据纳入配置管理中，并作安全评估。AI/ML所用到的训练数据、验证数据、测试数据、标注规则、数据处理脚本、模型参数、训练配置和评估成果等，都应当被当作受控配置项进行管理。按照ISO/IEC TR 24027标准，在对安全相关的AI/ML进行管控时，数据管控不能只看数据总量和来源，还要看数据偏移、分布差异、覆盖率范围及合适范围等。在安全应用状况下，AI/ML数据修改同软件修改一样看待，进行变更影响分析并做必要验证活动。需要给出数据覆盖性的有效证明，数据数量多并不能保证覆盖范围足够。

第三，用AI/ML加安全包络系统的结构设计。AI/ML具有传统技术不能实现的功能，但是安全边界还要由传统的安全来控制。速度监控、移动授权计算、制动曲线生成、列车完整性检查、进路控制等不应该由AI/ML模型独自作出决定。

第四，创建场景化验证体系。除了传统的测试用例外，还要建立AI/ML场景测试体系，测试目的就是检验危险漏检率、错误置信度、失效可检测性和系统安全后果。

第五，跟踪使用AI/ML的状态。AI/ML安全性在开发过程中不能完全得到证明。结合ISO/IEC TR 24028中有关AI/ML验证的想法，主要从AI/ML透明度、可解释性、可控性、可靠性和安全性等几个方面出发，制定出运行期间AI/ML的数据监控要求，还要有性能漂移评定、异常输入反馈、模型版本追踪情况和模型安全机制等内容。轨道交通这种长时间使用的体系，对于监督的要求就更高。

第六，禁止线上学习。对于轨道交通系统来说，在运行时模型在线学习会破坏已有的基础，之前的分析验证都会受到影响。除此之外，安全相关的模型不能在线学习。

5.2 结论

EN 50716对AI/ML的判断在轨道交通领域有顶层指导意义：AI/ML可以用于轨道交通领域，但是AI/ML参与的安全相关应用不能简单地使用传统安全相关软件的方法。AI/ML问题在于需求不能追溯到模型内部结构，训练数据不可能穷尽真实世界，训练后的模型无法被形式化验证，基于概率形成的近似功能不具备安全证明条件，存在对抗性攻击和因果缺失的风险等。

汽车行业相关标准采取分层的方式，提出除了传统的功能安全之外还要对AI/ML安全增加单独的安全论据。通用AI/ML标准给出了AI/ML安全论据应该包含AI/ML与功能安全的关系、可信度属性和运行期的可控性。轨道交通领域同样要采用分层的思想，在保持EN 50716、EN 50126、EN 50129、IEC 62425等传统功能安全要求的基础上，还需加上对于AI/ML数据管理、场景验证、运行监控、系统级安全论据等方面的考虑。

对于轨道交通的应用来说，由于其特殊的使用场景，在AI/ML现实的应用路径上，并不是替代传统的功能安全系统，而是限定边界后，在感知、辅助诊断、候选输入或者运行优化等方面充当一种工具角色，并且依靠传统的安全机制来限定它的边界并约束其输出。也就是说要借助AI/ML的强大功能来提升整个系统的综合能力，但是又不能影响到系统的安全性；可以接受统计智能的存在，但是必须被确定性的安全机制所限定；可以逐渐引入AI/ML，但是必须保证不会降低系统的安全水平。

本文完成了AI/ML在安全应用中的分层式故障安全防护架构的设计，给出了实现要点，但相关技术方案仍存在细化与拓展空间。后续可针对AI/ML技术的验证方法开展更深入研究，建立兼顾覆盖率与效率的验证指标体系。还可以结合具体应用场景，研究如何建立能够覆盖不同边界的数据库，进一步提升数据全面性，降低AI/ML带来的不确定性风险。