车载PIS服务器的设计与实现

2015-01-01康进赟

铁道通信信号 2015年10期

康进赟

乘客信息系统（PIS）是融合了多媒体网络和计算机信息技术，通过地面站台和车载媒体终端向乘客提供媒体信息服务的系统。目前，北京、上海、广州、深圳、香港和天津地铁都已开通了乘客信息系统，且在北京、广州和深圳等已开通车载实时传输乘客信息服务系统。国内地铁PIS系统普遍采用 “中心－地面－车辆”的媒体信息管理方式。车载PIS的终端直接面向乘客，对其播放的实时性和连续性有较高的用户体验要求。车载PIS服务器是车载PIS系统的媒体来源，通过转发车站子系统下发的媒体信息，向车载子系统的播放终端提供媒体资源和消息服务，为车－地媒体的统一管理提供了有效的途径。本文提出一种车载PIS服务器的设计方案，根据地面PIS系统提供的接口协议，设计服务器软件的整体架构。

1 服务器功能需求分析

PIS系统从网络结构上可分为3个子系统：控制中心子系统、地面车站子系统和车载子系统。地面PIS系统通过车载子系统向地铁车辆内提供媒体服务，实现车－地信息统一发布管理。车载PIS服务器接收和管理地面PIS下发的媒体信息，通过车载交换机组传给车载媒体终端在LCD显示屏上播放，向乘客提供信息服务。地面PIS子系统通过车－地无线网络向车载PIS子系统传输媒体信息，包括直播流媒体、垫播计划、垫播媒体文件、滚动消息和紧急消息等。由车载PIS服务器负责接收并进行数据缓存和转发。车载PIS的列车视频监控（CCTV）上载也通过同一路径传输至地面PIS子系统，地面CCTV在控制中心进行解码播放。车－地PIS系统通信如图1所示。

图1 车－地PIS系统通信示意图

车载PIS服务器需要实现以下功能。

1．直播模式。列车运行中，车载设备要实时接收来自地面运营中心的节目，包括媒体新闻、赛事直播和广告等实时动态的多媒体信息，并在列车车厢的车载媒体终端上播出。地面PIS通过TS流下发直播流媒体，车载PIS服务器接收地面PIS下发的视频流，以组播的方式实时转发给车辆PIS系统。

2．垫播模式。根据系统提出的播放冗余控制需求，为防止客室显示屏出现黑屏，需要在直播的基础上加入垫播模式。若视频源或车－地无线网络出现故障，导致车载PIS系统接收不到直播视频，车载PIS服务器将服务器硬盘中存储的垫播视频文件下发到列车以太网中，供客室服务器进行播放。

3．消息转发。正常情况下，地面PIS系统向车辆提供乘车须知、服务时间、列车到发时间、列车时刻表、管理者公告、政府公告等滚动消息；在火灾、阻塞及恐怖袭击等非正常情况下，提供动态紧急消息提示。车载PIS服务器周期轮询地面PIS的发送滚动消息和紧急消息，并将消息通过组播方式转发到车辆PIS系统中。

4．列车视频监控（CCTV）上传。视频流通过列车以太网络发送至车载PIS服务器；车载PIS服务器接收到录像视频流通过车载CCTV处理模块将录像视频存储到本地硬盘中，经转发模块将录像视频通过车－地无线网络转发至地面控制中心。

2 软件整体框架设计

由于车载服务器各功能之间相对独立，因此参考地面PIS系统提供的接口通信协议，按照功能分块的模式，建立多个执行线程，完成数据转发和文件存储的任务。以下主要对直播模块、垫播模块和消息转发模块的设计进行介绍。软件整体设计架构如图2所示。

地面PIS系统向车载PIS系统以UDP组播的方式发送实时TS流，并通过补包机制尽量保证视频流稳定可靠到达车载PIS服务器。当车辆系统由于网络不稳定造成直播流数据丢包时，车载PIS服务器通过单播方式向地面PIS系统进行单播补包请求。确保数据包无误后，车载PIS服务器再通过UDP组播方式下发视频流到客室内的车载播放控制器。

图2 车载服务器软件架构示意图

垫播模块的工作机制是根据地面PIS系统下发的垫播播放计划文件，通过FTP网络协议从地面PIS服务器下载计划文件中包含的垫播媒体文件。为了达到媒体文件周期更新的效果，每N分钟从地面PIS服务器获取新的计划文件。计划文件采用XML格式编码，在本地服务器经过解析版本号等有效信息之后，比较本地新旧计划文件，判断是否需要更新计划。若计划更新，则从地面服务器下载新的媒体文件。

直播模块实现了客室媒体播放的实时性和稳定性，采用补包机制确保了视频流播放的连续性。垫播模块是在直播服务中断或车－地网络故障的情况下提供的冗余服务，由客室媒体播放器自行切换，避免了在终端媒体播放器出现黑屏的情况，优化乘客的媒体信息服务体验。

地面PIS系统提供数据访问Web服务，车载PIS服务器通过http协议，以GET方式获取地面PIS下发的滚动消息和紧急消息。对消息简单解析和数据包分片操作之后，以组播的形式发送至各客室的播放控制服务器。

3 转发过程关键接口技术的实现

3．1 UDP组播技术

在车－地PIS系统通信的过程中，地面TS流的下发和车载PIS服务器发往客室的实时消息都是通过UDP组播方式完成的。UDP组播采用的是无连接、数据报的连接方式，相比TCP协议，UDP是不可靠的连接，数据到达接收端的顺序都不能保证。但是，在UDP传输过程中，所有数据的传送速度很快，保证了在局域网条件下视频和消息传输的实时性。

车载PIS服务器位于车辆司机控制室，采用双网卡的物理结构，实现车载网络与地面网络隔离，避免网络风暴等故障发生。外网网卡通过无线AP接入车－地无线网络；内网网卡与车载交换机相连，接入车载PIS局域网。故在创建UDP连接后，需绑定要接收或发送数据的网卡。具体流程如下。

1．创建数据报式（SOCK＿DGRAM）套接字，提供UDP服务。

2．通过setsockopt（）函数的SO＿BINDTO－DEVICE选项绑定网卡。

3．加入协议规定的UDP组播地址。

4．通过sendto或recvfrom进行数据的收发。

5．关闭套接字。

3．2 直播过程中的补包技术

地面PIS系统与车辆PIS之间通过WLAN网络连接。PIS系统向车辆系统以UDP组播方式发送实时H．264／TS流。数据以分包的方式传输到车载PIS服务器，到达的数据包需要根据其序号检测该段数据的完整性。当车载PIS系统由于网络不稳定造成直播流数据丢包时，通过单播方式向地面PIS系统进行单播补包请求，地面PIS系统将H．264／TS流以UDP单播方式对车载PIS系统进行数据包重传。

地面PIS系统向车载PIS系统发送的报文格式如图3所示。一个报文分为包头部分和数据部分。包头部分包括序号、时间戳和数据校验三个字段。

图3 地面PIS发往车载PIS的报文结构

用8字节整数标识报文序号，车载PIS系统可根据该序号检测是否丢包。用4字节整数标识地面PIS服务器从启动至发送该报文的毫秒数。包头的校验部分采用CRC16CCITT方式对 “数据”域做CRC校验。数据部分即为符合H．264／TS标准的流数据。

补包过程中，车载PIS系统向地面PIS系统发送UDP单播指令报文，请求需要重传的数据包。发送的报文格式如图4所示，它分为命令字段、最小包序号字段和最大包序号字段。

4 车载PIS向地面PIS发送的指令报文结构

报文首个字节标识车载PIS系统向地面PIS系统发送的命令请求。最小包序号表示申请重传的最小包序号，最大包序号表示申请重传的最大包序号。命令字段取值说明如表1所示。

表1 请求命令取值说明

结合各项请求命令，简要分析在补包过程中的通信规则。地面PIS系统与车载PIS系统之间的补包通信过程如图5所示。

图5 补包通信过程

1．数据发送。地面PIS系统以UDP组播方式向网络中不停地发送实时H．264／TS流。

2．开始接收（START）。当某列车的车载PIS系统设备开始接收实时视频流时，应向地面PIS系统发送START命令。

3．保活（KEEP＿LIVE）。每列车的车载PIS系统设备固定时间间隔向地面PIS系统发送KEEP＿LIVE命令，告知地面PIS系统，车载设备处于在线状态。

4．重传（RESEND）。当某列车的车载PIS系统设备检测到丢包时，向地面PIS系统发送RESEND命令，地面PIS系统将向该车以UDP单播的方式重新发送最小包序号（含该包）至最大包序号（含该包）之间的所有包。如果列车的车载PIS系统设备在1s内没有收到中心重传的包，则重发RESEND命令。

5．停止接收（STOP）。当某列车的车载PIS系统设备停止接收实时视频流时，应向PIS系统发送STOP命令。

3．3 基于XML格式的计划解析

为了统一播放计划的数据结构，采用XML格式编码播放计划文件。服务器软件采用QT类库中的QDomDocument类，实现XML解析功能。QDomDocument类代表整个的XML文件，是文档树的根节点，并提供了文档数据的基本访问方法。

计划文件解析过程如图6所示。首先通过QFile打开文档，新建QDomDocument对象，使用setContent方法设置文档的全部内容，该函数解析传入的XML文档字符串并创建代表文档的DOM树。根节点可以使用documentElement（）得到，方法childNodes将根节点下一级的所有子节点初始化为一个NodeList，即节点数组。通过遍历所有子节点，同时判断节点标签是否符合约定的XML标签名称。

若合法的节点没有有效的子节点，则通过QDomNode将其实例化后，调用nodeName方法获取其标签内容，存入对应的共享变量中。若节点下仍存在需要解析的子节点，则再进行同上所述的解析操作，直到整个文档有效内容提取结束为止。

图6 计划文件解析过程

4 程序运行流程分析

车载PIS服务器搭建于基于ARM架构的嵌入式主板上，操作系统采用嵌入式Linux。考虑到嵌入式主板资源有限，开发任务在PC平台完成。通过交叉编译后将执行文件部署至服务器。

程序功能主要由QT实现，QT是具有跨平台特性的C＋＋开发框架。在嵌入式环境下运行程序，需配置相应的QT依赖库运行环境。

官方提供的开源运行库是面向各个平台的，需将源代码包通过编译后得到arm－linux平台下的QtEmbedded版本库。将编译好的lib目录拷贝至目标机，即 ARM 主板的／opt／local／Trolltech／QtEmbedded－4．x．x／目录下，即可运行 PC工程目录下交叉编译好的执行文件。

程序运行流程如图7所示。在程序启动之后，依次启动直播服务线程、消息服务线程和垫播服务线程。

图7 程序运行流程

直播线程开启之后，初始化UDP套接字，绑定接入车－地网络的网卡、本地IP和端口，然后加入UDP组播地址，开始接收来自地面PIS系统的TS流数据包。检查数据包及补包过程在此不再赘述。将数据包存入缓存区后，检测向下组播的套接字是否打开，若未开启，则创建套接字，绑定到连接车载PIS网络的网卡，加入组播地址后，向下发送直播数据包。

消息线程通过访问地面数据Web服务，从地面服务器获取消息。分析获取之后的数据判断类型，滚动和紧急消息经过分片处理后通过UDP组播的方式下发到客室服务器。若收到消息为空则为异常，丢弃该数据不作处理，重新获取消息。

垫播线程是通过FTP定期下载播放计划的方式更新本地媒体文件。程序初始化后开始定时，当更新定时到达时，执行FTP下载任务。下载的计划文件经过XML解析后，与本地的原有计划进行对比，若计划没有发生变化，则重新定时，等待下次更新计划。若新的计划发生变化，根据计划解析出媒体列表下载新的媒体文件。