基于云的轨道交通广播系统全范围可配置录音方案

张辉 王晓东

（北京城建智控科技有限公司 北京市 100028）

1 背景

随着我国国民经济的快速发展，城市规模的不断扩大，城市轨道交通以其快捷、高效、环保等优点成为市民出行的首选，因此巨大的客流压力与运力不足之间的矛盾也逐渐凸现出来，我国城市轨道交通处在快速发展阶段，到2020年，54 个城市将新建约200 条线路。运营里程将达到6019 公里。广播系统在城市轨道交通运输服务中起着重要的作用。

广播系统作为城市轨道交通行车组织的必要手段，是保证安全运营的重要系统之一。主要作用体现在两个方面：一方面对乘客进行广播，通知列车到站、离站、线路换乘、首末班时间表、列车延误、站内情况、广告宣传等信息，或播放音乐改善候车环境；另一方面事处于安全考虑，在突发或紧急情况时，作为事故抢险，组织智慧的防灾广播，对乘客进行及时有限的疏导和指引，提高应急响应能力。作为最直接地面对公众，被公众所关注的系统，其安全性，可靠性要求也随着技术发展越来越高。广播录音审计是最为简单，有效的复核方式。

2 广播录音需求

当前国内轨道交通广播录音领域，广播系统录音大致分为两种方案：借助外部录音设备通过音频线进行模拟信号传输或者网线进行数字信号传输（通常是利用专用电话系统进行外接录音），或者对于播放语音信息在输入设备端进行留存并发送到指定位置存储。这两种方案只对部分设备进行短时间的录音存储，因此对于目前的轨道交通运营管理是远远不够的。如果发生站内紧急情况，并引发次生危害，在分析事故原因和处置过程中，增加对于车站各个区域引导广播和指令广播信息分析，对于优化应急处置流程和档案的建立是非常重要的；此外，随着信息技术的不断发展，黑客技术影响力也在不断增强，通过劫持或替换预录制语音等方式，实现频道入侵，播放反动，制造恐慌等不和谐广播内容危害公共安全，及时核对预计播放信息与实际播出信息一致性也十分重要。

为加强运营管理，增强事后分析能力，做到每一次广播的语音和数据信息都要完整记录并能够检索回放，从而提出扩大广播录音能力，实现全范围录音。

需求如下：

（1）录音对象范围：包括的地铁广播系统所有完成播放的声音，不区分输入设备，包括广播话筒，广播控制盒，无线手持台，以及预录制音频等，录音范围可根据需要和存储能力配置；

（2）录音存储时间：90 天，可根据实际存储能力进行配置；

（3）录音调取条件：按时间、按位置，按输出设备，广播类型，播放文件名称等进行检索查找；

图1

（4）权限管理：应该能够分级分权限管理，做到数据的安全管理。以免一些重要内容被人为的删除。

（5）自动集中存储：可以将录制好的音频自动传输到指定位置进行存储，便于管理，并可对于传输工作时间进行配置，避免造成网络拥堵。

3 基于云的轨道交通广播系统全范围可配置录音方案设计

3.1 设计思路

需求要求验证实际播放音频要与预播放信息一致，因此不能采用在输入设备端进行信息抓取的传统方案，而是将信息采集定位到广播系统末端输出设备上，以确保抓取的音频信息为实际播放出去的音频。

当前广播系统中大多采用数字功放配合模拟扬声器的结构，而非数字功放配数字扬声器的纯数字广播，原因如下：

（1）目前数字扬声器成本是模拟扬声器成本的几倍甚至十几倍；

（2）数字扬声器施工要求和成本远高于模拟扬声器：模拟扬声器采用一根2*1.5 音频线提供音频及供电，成本较低；而数字扬声器需采用网络传输，并每隔百米加入中继设备（中继设备也需考虑供电），且再需一根线缆为扬声器供电；

（3）音效方面：模拟扬声器采用低瓦数高密度方案，声音均匀度清晰效果良好；而数字扬声器不能采用低瓦数高密度方案，因为声音同步性不如模拟扬声器效果好。由于交换机发送音频机制会使相邻数字扬声器产生50nm 以上的间隔，人耳会感觉到重音。如采用高瓦数低密度方案，声音均匀度清晰度无法保证；另外高密度方案也会导致成本大幅增加。

（4）故障率及稳定性：模拟扬声器采用线圈等成熟方案，可稳定使用15年以上，而数字扬声器内含控制电路、网络通信等组件，稳定性有待考察。

因此将数字功放定义为广播系统的末端输出设备，实现录音功能。

软件方面，广播录音功能作为广播系统子功能模块之一，基于云平台的广播主机进行开发，采用微服务架构。基于轨道交通弱电系统统一的软件平台建立标准统一的资源池，建立标准化接口，实现资源共享，数据共用，易扩展等目标。

广播系统全范围录音功能必须基于云平台实现，最主要的原因是其存储资源的可扩展性，对于一个标准地铁站来说并非同一时刻只有一段广播进行播放，理论上站厅，站台，设备用房等区域有多少个广播分区，就可以有多少个不同的音频在同时播放。且考虑到后续智慧车站，智慧客服的需求，类似于电梯提示广播，辅助设备的语音播放，以及高峰期每个站台门间的广播信息均可以区分管理，独立播放不同的语音信息，其存储量弹性变化差距非常大，而云平台的资源扩展性正好可以满足其动态伸缩要求。

3.2 系统结构

广播系统由中心云广播主机，车站广播主机，数字功放设备，以及前置话筒，广播控制盒，无线手持设备等音频输入设备构成。此外，还包括共用的广播控制终端电脑主要实现语音音频的编辑及上传及广播控制指令下发，信息配置等工作。

结构图如图1所示。

3.3 录音方案设计

首先，由数字功放设备对于设备内声卡进行监听，当接收到广播主机的播放控制指令后，核对本地录音配置文件，确定本次播放信息需要录音后建立录音程序流程，对声卡传出的声音进行采集，并将音音频流转存为mp3 文件，使用FTP 协议回传到站级广播主机，同时回传本次录音的标签信息，包括功放ID，音频流广播类型，时间信息等。如果在回传过程中数字功放与站级广播主机链接出现异常断开，则对于已回收的音频流进行缓存，待链接恢复后继续回传。

站级广播主机在完成数字功放设备的录音文件接收后，根据数字功放ID，确定广播分区信息，按照时间序列连同音频文件标签信息一起暂存在站级广播主机中。根据定义的自动集中存储数据回传策略，待网络闲时将数据批量上传到中心进行存储。站级广播主机支持最近7 天文件的存储（可根据硬件资源调整配置），因此即便车站与中心在一定时间内网络断开仍然可以保持数据完整性。当车站与中心网络故障超过7 天仍未恢复，那么自动删除最早的文件，保留最新文件。在删除老文件的同时产生日志信息记录相关自动操作。

中心广播主机存储全线所有分区的录音信息，与站级广播主机存储策略一致，当文件超出存储限制后删除最旧的文件，保存最新的文件，在删除文件的同时产生日志信息进行记录。

人机界面按照系统统一的多级用户权限进行管理，对于具备权限角色开放录音审计功能，支持查看和回放全部存储的录音文件。并配合大数据平台综合日志，设备状态开展统计，展示统计结果。人机界面不提供录音删除功能，避免了有意或者无意造成录音记录文件丢失的安全事故，实现数据安全管理。

同时，具备权限的人员可以通过网管系统定义录音配置信息，明确需要录音的范围和音频级别，口播命令为一级，其中包含车站人员口播，中心人员口播，无线手持台人员口播，应急预录制音频为二级，到离站等其他预录制音频为三级，背景音乐及广告音频为四级，支持对于每个数字功放的分区进行个性化配置，实现差异化存储管理。支持对于录音文件频率的配置，以实现压缩存储空间的目的。

4 结束语

基于云的轨道交通广播系统全范围可配置录音方案，实现了广播系统全范围输出音频录音功能，确保了历史广播信息完整真实的重现，为规范操作、约束不良工作习惯、安全事故的事后追责、分析等提供了有效数据证据。当前功能还只是用于事后分析、验证，后续可结合大数据对于分析结果建立专家库，变被动为主动，预防不规范操作语音广播、被替换的预录制语音播放以及被劫持的无线广播播放。