1. 如何减少铁路基础设施安全自动化系统的鉴定时间

每天乘客运输量高达1000万人次的RATP，一直在投资交通现代化以应对交通的持续增长，响应乘客的需求，并优化经济和环境性能。作为巴黎地铁现代化项目的一部分，RATP选择开发一种名为OCTYS的新型地铁管理系统。利用基于通信的列车控制，交通运营商可以在完全安全的情况下减少两列火车之间的间隔时间，这样在高峰时段有更多列车可供乘客使用。这样的系统变得越来越复杂，也越来越难以集成和鉴定。本文将介绍用于减少现场测试的时间和成本的具体工具和方法。

2. 介绍

其中最大的困难在于安全系统（分布在网络上的电子控制单元）与原有的安全信号系统的连接和集成，这些系统响应时间和输入数据都不同。

图1 巴黎地铁，已有110多年历史

传统的测试通常在夜间交通关闭时进行。要完成现场测试，需要大量的时间（大约1000个晚上）和人力资源（测试工程师、司机和交通操作员）。RATP考虑可交换性，将其定位为通用OCTYS项目。该策略要求灵活性，确保系统支持多个供应商，考虑成本效率。

因此，可用于规范定义、验证和培训的基于新的“虚拟化”概念的方法和工具变得非常重要。

为了符合OCTYS系统的要求，RATP启动了“系统集成和鉴定测试平台”(BIQS)项目。该项目采用特定方法和工具，应用到OCTYS等复杂系统，使系统集成和鉴定阶段更加高效。

2.1 OCTYS硬件架构

关键问题是如何将OCTYS系统与现有的线路中的设备、本地控制站和中央控制连接起来。

图2 场景下的OCTYS

OCTYS是由多个计算机组成的分布式体系结构，通过通信系统（一个专用的现场网络和一个列车无线电网络）相互连接。

OCTYS由五个模块组成:

· PAE: 列车嵌入自动驾驶仪 (一个列车电子计算机单元),

· MES: 与线路设备有接口的远程I / O模块 (铁路、信号、开关),

· PAS: 地面自动驾驶仪 (每个管理物理线路上的一部分),

· FRONTAM: OCTYS和线路中央控制之间的接口,

· STD: 智能通信系统管理。

2.2 集成和鉴定需要

BIQS平台的主要目标是:

· 改善集成阶段工作, 在实验平台上使用测试管理搭建和验证新的线路,

· 在其生命周期内监控OCTYS系统（操作和维护活动），支持查找和协助诊断,

· 测试和验证系统的未来的改进和更改,

· 支持可交换性

系统鉴定平台的目标和任务:

· 考虑实时约束和典型行为，仿真整线的能力，

· 集成不同模型并执行联合仿真 (火车、线路、交通、信号、安全规则,自动驾驶仪…)的能力,

· 不需要繁重的重新配置工作，就能与实际目标机交换目标模型的能力,

· 模拟数据传输系统能力,

· 通过故障引入获得系统功能退化模式的能力,

· 在自动模式及交互模式下集成测试用例的能力,

· 配置线路具有灵活性和扩展性的能力,

· 提供HMIs便于分析的能力,

· 重放记录的事件的能力。

所有这些能力合在一起体现了RATP项目的一个重大创新。

由于OCTYS有很多制造商参与，每个制造商只看到了整个系统的一部分，而且接口不标准只支持其服务部分。基于现场的实际线路情况，系统部件的最终集成仍然是需要在现场测试阶段完成。

此外，实现这样的集成和鉴定平台需要汇集来自不同参与者的知识，这些参与者包括控制系统专家、仿真专家、能够处理复杂组织和系统的管理人员等。

因此,这测试台的主要需求分为三类:

· 支持集成和验证

· 支持系统维护

· 鉴定新供应商资格，符合OCTYS可交换性的要求

2.2.1 支持集成和确认

目的是通过离线验证系统，减少现场鉴定时间，避免操作中断。

2.2.2   支持系统维护

一个主要目的是维护系统的运行，并利用记录的数据(黑箱)来查找在开发过程中出现异常的根本原因。其目的是剥离事故，分析记录的事件，并使用友好的HMIs和工具来可视化/检查它们。此类服务可以自动创建场景(测试向量)，以便在测试台上回放实时情况。

2.2.3 鉴定新的供应商，符合OCTYS可交换需求

在将其添加到兼容的OCTYS设备的参考列表之前，BIQS 平台帮助鉴定新制造商目标产品。经过标准测试集测试，最终和预期结果都应相互匹配: 对新目标产品应用标准测试过程，测试结果自动与预期结果进行比较。

2.2.3.1 BIQS硬件架构

为了满足集成和验证的需要，BIQS 平台鉴定系统需要模拟完整的OCTYS系统环境，以容纳整个系统的电子控制单元，并允许运行测试用例。

这个完整的环境，包括信号、线路和火车，以及所有的OCTYS安全和控制功能，这些都是用ControlBuild进行建模和仿真。在线路模型上添加了自动测试脚本(交通和故障模式)，提供了快速、全面的分析结果。

BIQS平台的独特之处在于，支持半实物仿真，为满足OCTYS系统而开发的真实ECUs可以任意连接到试验台上，进行联合仿真。此外，通过仿真模型，供应商a提供的设备可以替换为供应商B制造的另一个ECU。

图3 系统集成和鉴定测试台

2.2.3.2 软件架构

RATP在巴黎的第8地铁线上的 “Porte de Charenton” 车站设一测试基地。第一个实现的目标是创建一个虚拟的线路模型，从电子设备的角度来看，它的行为将与真实的线完全相同。

图4 “Porte de Charention”车站测试线路图

鉴定平台由仿真模型（线路的物理环境、机车(火车)和虚拟控制器）、测试场景和所有设备之间的通信(I/Os接口配置和网络通信)组成。

2.3 仿真模型

模型不仅取代了真实环境，也取代了被测试的目标本身 （因为这些目标在测试平台中并不总是可用的）。所有这些模型:

· 可以连接到I / O或数据网络与其他模型通信的接口,

· 代表模型行为或其参数 (运动时间,平台长度,开门时间,需要速度…)的状态变量,

· 依赖预期行为的简单或复杂的传输函数,

· 用来修改模型正常行为 (机械,电气或通信故障) 的特定参数。

BIQS平台集成了不同类型的模型:

· 环境 (线路、信号、车辆和本地控制板模型)

· 电子设备模型 (自动驾驶)

2.3.1 环境模型

支持自动驾驶的环境模型是经验证过的。它们描述并模拟了线路、信号、电力分配、现场或中央控制室和列车(车厢、牵引、车门、本地化传感器以及虚拟司机)的行为。

线路模型: 线路模型中包含了引导列车运动的所有对象。线模型包括轨道、开关、信号和检测器、站台、隧道……）。每个对象都参考一个行为模型。每个对象都有一个图形动画，并设置为3轴维度。线路模型可以从ControlBuild下的库里模型自动构建出来，只需要填写模型里的地理位置参数。

图5 带交通状态的实际线路

信号模型:目前巴黎地铁的信号系统主要是通过电气硬件实现安全控制。所以这个系统需要与新的电子控制系统共存。因此，鉴定平台需要开发信号硬件的模型。

图 6 信号原理图

原始的电气原理图印在纸上, 通过半手动方式将其捕获翻译到ControlBuild中。在代码评审验证阶段，将原始图与模型进行比较。最后的验收阶段由安全工程师通过仿真和测试来验证模型。

本地站控制模型:当线路与中央控制系统断开连接时，RATP就有一个本地的交通控制来管理车站内的列车。本地站控制由一个显示信号、开关位置和占用轨道的面板组成。一个面板允许管理站点设备以建立预期的线路。在ControlBuild里开发“Charenton Porte de Charenton”车站控制模型，并将其集成到鉴定平台中。

图7 车站可视化面板

图8 车站控制面板

机车车辆模型: 根据我们的需要，列车模型包含了司机室、简化的车辆 (门、铁路线、配电…受电弓) 和牵引设备等模型。牵引模型的动态特性与实际列车的动态特性非常接近，从而可获得整线的特性。

简化列车模型是为了提供必要的接口，由一“执行者”驱动列车模型。该驾驶面板已被通用模型化，无论何种类型的车辆，都可以用同一驾驶模型。

图9驾驶舱面板

列车和线路之间的交互: ControlBuild有一个功能，可以不需要编程在三维坐标空间中移动列车。因此，列车可以沿着铁轨行驶，检测开关岔道的位置，对传感器做出响应，捕获带受电弓接触网功率……该模块与牵引模型交互，根据要求的加速情况计算列车的速度。

2.3.2 自动驾驶模型

物理电子处理单元(自动飞行员)在测试台上可有也可用虚拟模型替代。根据实际设备的存在情况，开发的虚拟模型可以被动态地启用或禁用。

图10 显示自动驾驶接口状态

使用虚拟电子设备开发了“Porte de Charenton”站，自动驾驶仪功能需要基于该虚拟车站执行一系列测试:

· 重新配置禁用区域

· CBTC激活

· 弥补错误的轨道电路

· 帮助自动取消路线

· 帮助紧急取消路线

· 安全方法锁定

· 发现和释放超限锁定

· 遵守信号指示

· 设置方向

· 设置列车保护

· 检测轨道电路故障

· 处理乘客保护

· 线路控制安全

· 制动时授权重新发电（再生能源）

· 禁止驾驶模式

· 授权进入车站

· 操作支持监督

2.4 测试脚本

鉴定平台可支持手动操作或自动操作模式。在手动模式下，仿真模型的用户图形界面GUI (线路、信号舱、机车……)支持测试人员沿着线路 (路线开发) 驾驶列车，验证真实(和仿真)设备的正确操作，并模拟故障以验证安全功能和故障模式。

ControlBuild允许测试工程师搭建测试脚本, 以触发正常操作模式相关的动作 (如定位一列列车, 启动列车, 改变驾驶模式, 加速或制动) 或产生异常情况 (例如, 强制系统或设备的一部分产生故障) 。测试用例是提供输入事件和输出测量的操作序列。这些测试脚本也可以在测试台上自动执行。

图11 测试脚本编辑器和生成的测试报告

主测试脚本加载当前测试的初始条件 (模拟设备和环境的固定状态)，然后顺序执行所有代码指令。与此同时，其他场景可能会模拟故障、触发事件(不管预期与否)并强制某些设备模型的状态。

测试脚本为测试台和实际硬件ECUs之间的输入/输出和通信接口的配置提供代码指令。这些指令允许测试工程师在所有接口和通信上引入故障。

2.5 测试台物理接口

测试台的目标是在硬件目标集成到站点(或列车内部)之前对其进行验证鉴定。为此，有必要将目标机连接到工作台; BIQS测试平台提供输入/输出和通信子系统。

2.5.1 子系统输入/输出

该采集子系统用于仿真物理目标的输入，测量设备的输出值，并为实际目标提供功率。对于每个信号，子系统保证了电路的适应性、模拟传感器电平的数字化和事件的时间戳。BIQS测试台硬件子系统还能够支持标准或特定的通信网络。

配置编辑器允许在测试平台上输入/输出卡和通信协议进行配置。

图12 I/O和网络配置

2.5.2  通讯子系统

在OCTYS系统中，通信是基于UDP的。所有的交互所都由一个叫做STD(数据传输系统)的电子设备管理。它的主要功能是在OCTYS系统的设备(物理目标或模拟目标)之间路由消息。

该通信设备的行为模型是在ControlBuild下搭建的。它有特定的模块来存储交换的帧，并实时地中断通信数据。

图13 监视，数据登录及通讯监控

通过对通信系统故障的模拟，测试和安全工程师可以验证真实设备的能力，检测故障行为，并做出正确的决策(继续、停止、保护、警报……)。

3. 总结

这个系统集成和鉴定平台项目展示了使用已验证的仿真技术处理安全自动化问题的关键优势。成功的关键因素在于所使用的仿真工具的通用性，例如，ControlBuild，特别适合于运输部门，以及所使用的方法和过程的灵活性(从模型到HIL)。

这个解决方案减少了现场测试时的故障停机和对实际设备操作成本。

“一天的模拟测试可以抵10个晚上的现场测试!”

这种基于模型的测试技术在系统开发之前验证规范很有帮助。

ControlBuild提供的高级语言允许设计人员轻松地描述线路的不同环境模型(信号、功率分配)、重用车辆模型和原型新的自动化需求(不管是否安全控制)。这些用例可以由不同的项目利益相关方(工程、安全部门、交通操作工程师…)验证。

由于该模型代表系统，因此一旦系统投入使用，集成和验证工作台可支持进一步验证测试仿真分析。在实际操作中检测到的所有事件都可以引入到测试台中进行分析。

模型也可以用于培训当与中央控制室断开通信时，RATP工人如何管理车站交通。可以创建正常和非正常状况、事件和事故:目标是让办公室人员增加可能发生的事件了解,使他们能够在紧张的情况下做出正确的决定。

文章来源：默识沙龙