灵活编组动车组网络实时显示系统设计

张广吉

（中车青岛四方车辆研究所有限公司，青岛 266031）

目前，我国铁路投入运营的动车组基本采用8辆或16辆的固定编组模式，旅客运输在春运、节假日、寒暑假等期间会出现短期客流高峰，而在淡季时出现客流大幅减少等现象，造成客流量的不平衡，采用固定编组模式，在动车组上座率较低的时候，造成资源的浪费[1]。因此设计维修简便、灵活编组、动态调整运力与客流需求相匹配、具备良好经营效益的动车组成为迫切需要，灵活编组的动车组对客流变化较大线路具有重要意义，既可以很好地满足旅客出行需求，又可节省运营成本[2]。

本文依托可变灵活编组CRH3X[3]动车组及CRH3X动车组的网络控制系统，设计网络显示屏实时显示系统。显示屏是在动车组上完成人机对话和系统信息显示及反馈的重要设备，它为司机正确操作和控制动车组、及时掌握动车组工作状况起到了至关重要的作用[4]。

1 总体方案

本文设计是基于Linux嵌入式操作系统，用Qt Creator开发工具开发，对实时显示系统的实现方法进行研究[5]。实时显示系统架构，如图1所示，显示系统主要实现与网络控制系统中央控制单元的通信，并根据中央控制单元发送的数据实时显示当前车辆的状态，另外可以通过显示系统发出控制指令，比如控制空调温度等。显示系统由电源模块、中央处理器（CPU ，Central Processing Unit）、通信板卡及人机接口（HMI，Human Machine Interface）显示屏组成[6]，电源模块实现DC110 V转DC5 V，为CPU、通信板卡、HMI显示屏供电；通信板卡通过多功能车辆总线（MVB，Multifunctional Vehicle Bus）实现与中央控制单元的通信；底层通信程序和应用程序运行在CPU上，将数据实时转换，通过串行通信端口（COM，Cluster Communication Port ）用户界面（UI，User Interface）；HMI显示屏负责 UI界面显示。UI结构树，如图2所示[7]。

图1 实时显示系统架构

图2 UI界面结构树

本文设计的灵活编组动车组实时显示系统，解决了显示屏软件不能实时显示多种编组形式的难题，避免编组形式变化后需要人工进行配置的问题。在显示屏软件开发过程中，因其编组数量的灵活性及不确定性，较于固定编组的动车组网络控制系统显示屏增加了开发难度，因此，实时显示系统通过设计大小端及拖车模式、界面重绘机制、动态关联变量、故障变量与网关账号绑定等创新措施，解决了获知实时编组数量、实时显示当前车辆状态、判断发生故障部件的物理位置等难题，最终完成了可灵活编组的动车组网络控制系统显示屏实时显示系统的开发[8]。

2 灵活编组模式

2.1 动车组显示屏位置

每个司机室内设有相互冗余的两台显示屏，其中，驾驶位置的左侧为主屏，右侧为从屏，正常情况下主屏和从屏都可以显示所有信息，但只有主屏可以发出操作命令，如果主屏发生故障时，从屏需要代替主屏，既可以显示所有信息，还能发出操作命令。另外在餐车还设有一个乘务员显示屏，该显示屏只有司机室显示屏的部分功能，本文不再介绍。

2.2 动车组编组模式

本文开发的实时显示系统满足最大车辆编组为10编组，最小车辆编组为1编组，即带司机室的动车可以单独运行，其动车分布在动车组的两端，定义物理车号较小的动车为小端，物理车号较大的动车为大端，拖车分布在小端动车与大端动车之间。大小端动车编组最多分别为3编组，拖车最大编组为4编组，图3为3-4-3编组形式，拖1车具有餐车功能。

图3 3-4-3编组形式

2.3 动车组灵活编组模式

为实现动车组的可灵活编组，在10编组时共需要6个网关（不考虑冗余情况），大端动1、小端动1各有一个网关，每辆拖车各有一个网关，所以在灵活编组时，动车组上的网关数量为小端、大端及拖车数量的总和，这样动2车、动3车及拖车的数量可以在不超过规定编组数量时自由组合，而不影响整车的通信，从而可实现灵活编组动车组的目的。当小端动1车司机室钥匙激活时，即小端动1车占用时，小端动1车、拖1、拖2、拖3、拖4和大端动1车的网关依次为网关1—6；当大端动1车占用时，大端动1车、拖4、拖3、拖2、拖1和小端动1车的网关依次为网关1—6，即占用端网关账号为1。

3 灵活编组与固定编组实时显示系统的区别

3.1 动车组编组数量的多变性

（1）固定编组实时显示系统因其编组数量的固定性，在显示屏启动时就完成了整个界面的初始化，只有涉及到连挂时才会出现编组数量的变化，显然固定编组实时显示系统的编组数量只有2种情况，连挂和非连挂，所以在实时显示系统中可以把2种界面都画进去，只根据连挂和非连挂切换不同的模式。

（2）灵活编组实时显示系统的编组情况不仅仅是简单的几种，不能使用枚举法把每种可能的编组方式都画出来，只能根据车辆编组方式的变化实时重绘显示屏界面的图标，并且需要在不进行网络复位的情况下实现，这无疑增加了实时显示系统的开发难度。

3.2 关联变量

（1）由于固定编组动车组（以8编组为例）单列时只有2个网关（不考虑冗余），把列车分为2个半列，每半列4节车，分别为1、2、3、4车，固定编组实时显示系统的每个变量都带有网关号信息，可以根据网关号的不同区分位于哪一个半列，再根据1、2、3、4车信息就可以判断其对应的实际的物理车号，进而正确地与显示屏界面的控件相关联。

（2）灵活编组实时显示系统由于网关及动车数量的不确定性，无法在程序中预先把每个控件与变量相关联，只能根据实际编组中网关及动车数量确定后，再动态地关联变量，这也增加了实时显示系统的开发难度。

3.3 故障显示的车辆号信息

（1）固定编组动车组的故障信息中给出的车辆号是逻辑的车号，只需要根据当前占用情况，就可以得到实际的物理车号，以8编组为例，当物理1车占用时，逻辑1—8车即为物理1—8车，当物理8车占用时，逻辑1—8车即为物理8—1车。

（2）灵活编组动车组的编组数量是变化的，根据不同的编组组合选择不同的故障库也是不现实的，因此灵活编组动车组的故障信息给不出对应的逻辑车号，从而无法直接得到真实的物理车号，所以只能根据实际的情况再进一步计算得到故障的实际物理车号。

4 解决方法

实时显示系统可以实时得到车辆编组大小端动车数量和拖车数量，可以根据得到的当前编组情况实时地重绘显示屏界面，具体的解决方法如下。

4.1 实现图标重绘

需要实时监测车辆编组大小端动车数量、拖车数量的变化，一旦发现编组信息发生变化和编组数量相关的显示屏界面就执行初始化程序，对其进行重绘，使显示屏界面与实际的编组情况相符合。在界面开发中，定义各种类型的图标，例如车辆图标，观察发现，其涉及4种不同类型的车辆：占用端头车，非占用端头车，非头车动车及拖车，4种类型车辆图标，如图4所示。

图4 占用端头车、非占用端头车、非头车动车及拖车图标

当显示屏得到动车组大小端及拖车编组数量时，初始化显示屏界面，确定所需要的图标；再根据大小端占用情况确定各个图标的位置，标注当前车辆代表的物理车号。当车辆编组大小端编组都为3，拖车编组为4，小端占用时的车辆排列，如图3所示；当小端编组为2，大端编组数为3，拖车编组为3，小端占用时的车辆排列，如图5所示。其他图标可以通过同样的方法进行重绘。

图5 2-3-3编组形式

4.2 实现变量关联

在关联变量时，因为动车组编组数量及网关数量的不确定性，无法确定非占用端动车的网关号，无法直接关联变量。首先应该确保动车组无论采取何种编组时，都可以收到每辆车的变量信息，研究发现，动车组网关帐号最大为6，一个网关下最多有3辆车，所以可以在显示屏程序中定义一个6行3列二维数组ac[6][3]，如公式1所示，行表示网关帐号，表示最多6个网关，列表示此网关下车辆号，表示一个网关下最多有3辆车，这样不论编组形式如何变化，均可以在定义的二维数组中找到对应的变量。以表1所示的空调状态变量为例，当编组形式为3-4-3且物理1车占用时，acD1G1、acD2G1、acD3G1、acD1G2、 acD1G3、 acD1G4、 acD1G5、 acD1G6、acD2G6、acD3G6分别表示小端动1车、小端动2车、小端动3车、拖1车、拖2车、拖3车、拖4车、大端动1车、大端动2车、大端动3车空调状态变量，如表1所示，即物理1车、2车、3车、4车、5车、6车、7车、10车、9车、8车的空调状态变量。

表1 空调状态变量

4.3 实现故障车号计算

对于灵活编组动车组的故障信息，直接可以得到的只有故障变量名，之后通过遍历故障库得到其他的故障信息，比如故障名称、故障等级、故障描述和操作指南等。但对于故障车辆的物理车号，因为灵活编组动车组编组数量及网关数量的不确定性，对于同一个故障变量，无法得到固定的物理车号。基于以上原因，在故障库中加入了该故障变量所对应网关帐号及该网关下第几辆车的信息，这样就可以在得知其编组模式和占用情况后，推算出其对应的物理车号，比如在2-3-3编组模式，小端占用时，得知网关5，动车2发生某一故障，可以计算得出该故障发生在物理的7车。

5 网络节点故障工况下的显示设计方法

在动车组编组或运营期间不可避免地会发生故障，当发生故障时如何快速有效地解决故障，将影响降低到最低，是动车组设计的重要因素，因此本文设计了网络节点故障工况下的显示方法，如图6所示。

图6 网络节点故障时处理机制流程

6 结束语

本文讨论了研制可灵活编组动车组的必要性及网络控制系统显示屏的重要性，分析了开发灵活编组相对于固定编组实时显示系统存在的不同和难点，针对这些问题提出了合理的解决方案，最后分析了网络节点故障工况下的显示方法，在此基础上顺利完成了灵活编组动车组网络显示屏实时显示系统的开发。