智慧运维系统中的全节点动态链路图的技术实现

刘伟东 杨俊康

（作者单位：紫金电视调频转播台）

广播电视是引导全社会树立正确价值观，弘扬社会主旋律、传播正能量、推动科学文化传播和社会发展的重要媒介[1]，也是党和政府传播意识形态、巩固党和人民共同思想基础的有效途径[2]。

在如今的数字化时代，媒体融合发展是传统广电创新转型的趋势，也是国家战略。要实现媒体融合，就需要在智慧广电建设的路径下去推动，媒体融合是方向，智慧广电是实践路径。国家广播电视总局也在2018年11月印发《关于促进智慧广电发展的指导意见》，为智慧广电的发展指明了要点，推动智慧广电建设[3]。

在智慧广电建设中，智慧运维又是重要环节。它通过数字化、网络化、智慧化的方式助力广播电视安全播出，是保障广电视听安全的重要举措[4]。

发射台智慧运维一般过程是数据采集、存储管理、处理分析、智能控制、可视化呈现、异态报警通知，涉及物联网、流媒体、数据存储、专用算法、万维网（World Wide Web, Web）、移动开发等技术。可实现节传设备、发射机、信源/节目、动力环境等的智能监管。但他们都是独立的业务模块，需要一个将分散业务整合起来的功能，这就需要提到本次介绍的全节点动态链路图。

1 全节点动态链路图的定义与意义

1.1 全节点动态链路图定义

链路图是一种图形化表示系统内组件间逻辑关系的展示方式。在链路图中，通常通过节点或符号来表示一个组件，以组件之间的连线或者箭头来表示组件间的逻辑关系。

发射台的全节点动态链路图（见图1）能够实现对众多节传设备、发射机实时工况监测、信源状态监测、节目播出情况监测。同时，展示频点发射链路中信号的流向，即从卫星、光纤、微波接收信号开始，到发射塔发射结束的全链路监控展示。

1.2 全节点动态链路图的意义

全节点动态链路图是发射台智慧运维系统的重要组成部分，它在全链路监测环节具有如下三点重要作用：

（1）直观展示广电传输网络的结构和连接关系，使信号传输过程的监测和管理变得更加方便。

（2）展示系统内各设备节点的实时工况、信源/节目情况，帮助值班人员更简单、清晰地了解整个系统的运行状态。

（3）当发生故障时，可以协助值班人员快速定位故障点，使故障能够得到及时处理。

总而言之，全节点动态链路图可以满足全链路集中监管需求，提高值班人员监管效率，助力整套发射系统稳定运行，在一定程度上降低了播出风险。

2 全节点动态链路图的实现

2.1 总体设计

系统总体为浏览器/服务器模式（Browser/Server,B/S）架构。其中，浏览器作为全节点动态链路图的用户显示前端，摆脱了固定在应用程序（Application,App）上使用的限制，打开手机、平板或是计算机中的浏览器，使用局域网，即可访问全节点动态链路图页面，随时随地进行监测监管。

全节点动态链路图整合了节传设备、发射机、信源节目等对象，每一个对象都拥有一个管理层，管理层获取对象的实时工况信息、判断报警，并与全节点动态链路图共享数据、实时联动。

2.2 节传设备接入

节传设备在通信网络中，一般充当服务器的角色。也就是说，通信另一方的客户端需要知道设备的网络IP地址，然后才能进行链接并通信。发射台里节传设备众多，如果是手动管理地址，那么需要逐个设置每个节传设备的IP地址，这是一件相当烦琐、重复性高，且容易出错的事情。

更加方便快捷，并且更不易出错的IP地址管理方式应该是启用动态主机配置协议（Dynamic Host Configuration Protocol, DHCP），让DHCP服务器动态分配IP地址给每个设备。但IP动态分配后，设备管理端又无法直接获取设备的IP地址，这时就需要通过设备发现来获取。

IP地址动态分配后，局域网内每台设备的IP地址就是变化的，设备就需要一种方式将自己的IP地址通知给管理端。传输控制协议（Transmission Control Protocol, TCP）只能在知道目标IP端口的情况下，点对点通信，所以选择用户数据报协议（User Datagram Protocol, UDP）下的广播或组播进行一对多通信。将自己的IP按一定协议封装后，“喊”给局域网内的所有通信对象“听”，客户端“听到”后按预先约定协议解析后便能得到对方的IP地址。

由于广播传播数据时，会把同一数据包复制给网络中的所有主机，浪费了一定的带宽，特定条件还可能造成广播风暴，引起网络瘫痪。反观组播，其数据只传递给加入该组的成员主机，传播过程中只有一份数据，在临近成员主机的组播路由器时才复制并分发数据给成员主机，节省了网络带宽。选择UDP组播方式传递IP地址给客户端是最佳方案。

但UDP不提供传输可靠性，消息存在丢失的可能，需要在通信协议上确保通信的可靠性。因此，需学习TCP协议底层通信机制，即通过确认应答来相互确认已收到对方发送的消息，同时联合超时重传机制，确保设备发现过程的可靠性。

最后，在数据通信时采用面向链接的、可靠传输的TCP协议，以便及时发现节传设备损坏、断电、断网等突然“下线”的情况，发现流程如下：

2.2.1 设备端发现流程

（1）设备接入网络并获取DHCP动态分配的网络IP地址。

（2）空闲时主动发送UDP组播消息，通告自己上线。

（3）利用定时器中断的触发时间，等待管理端回复上线确认。

（4）如果中断触发前仍未收到管理端上线确认消息，再次通告上线消息。

（5）否则，向管理端进行UDP点对点回复上线完成消息，并关闭该中断。

（6）开启TCP服务等待管理端链接。

2.2.2 管理端发现流程

（1）管理端接入网络并获取分配的网络IP地址。

（2）加入同一组播地址，接收设备上线通知。

（3）收到设备上线消息后，针对该设备进行UDP点对点回复上线确认消息。

（4）利用定时器，等待设备上线完成消息。

（5）如果超时前收到上线完成消息，以TCP客户端身份链接设备端。

（6）否则，再次进行UDP点对点回复上线确认。

2.3 发射机接入

发射机厂家繁多，同一厂家的发射机协议版本也多，需要想办法封装发射机协议细节，解耦通信上下游的协议依赖，将添加或改变协议的影响控制在最小范围。

最终选择在管理层与发射机之间添加嵌入式层来封装协议细节，嵌入式层对接发射机，将各种各样的发射机协议转换为统一的协议后发送给管理层。

嵌入式层与管理端序列化协议设计如下：

（1）报头/报尾：确定协议的开始/结束。

（2）消息ID：表示消息号，是单调递增的数字，具有唯一性、有序性的特点，让消息具有幂等性。

（3）模块类型/模块地址：用来区分功能模块，将采集、控制、设置、空中下载（Over-the-Air,OTA）等划分为独立模块，并通过模块地址寻址。

（4）命令代码：表示操作指令，用来区分协议类型。

（5）数据长度：描述数据段的长度（字节）。

（6）数据段区域承载通信的内容。

（7）检验和：保证通信内容的完整性、准确性，通信的两端均以消息相同部分作为计算参数，使用相同的算法进行计算，如果接收端计算的结果与校验和不同，则表明传输过程出现了差错[5]。

数据段为参数列表，其为封装发射机协议细节的关键。

一个参数由参数代码、参数长度、参数内容组成，参数列表表示多个参数的集合。

（1）参数代码：描述参数值的类型。

（2）参数长度：描述参数值占用字节数。

（3）参数值：表示参数的内容。

通过列表化发射机属性后，管理层以及后续层级看不到各式各样发射机协议上发射机属性的差异，只需统一以列表的方式识别参数，通过参数代码判断参数类型，随后进行相应逻辑处理即可。也就达成了封装发射机协议细节，解耦通信上下游的协议依赖的目的。

对比参数列表方案与常用方案，通过结构体方式描述协议（在数据段填“普通旧数据”类型结构体）。假设发射机生产厂家数为M，每个厂家有N种发射机，通信链路有K层：

（1）结构体方案：K层通信链路，序列化反序列化次数之和为2（K-1），接入全部N×M种协议。因为每种协议发射机属性不同，所以数据段承载的结构体也必然不同，而每种结构体都需要独立的序列化与反序列化代码。最终，序列化与反序列化代码一共需要增加（N×M）×2（K-1）处。

（2）参数列表方案：K层通信链路，序列化反序列化次数之和为2（K-1），接入全部N×M种协议。由于以同样的结构传递N×M协议，所以反序列化处代码可通用，仅需增加1处即可；序列化处需要将N×M种协议转换为参数列表，需要增加（N×M）处代码。最终，序列化与反序列化代码一共需增加N×M+1处代码。

参数列表化方案比常用方案减少了（N×M）×2（K-1）-N×M+1处代码，提高了编码效率，也减少了产生程序错误的可能。

2.4 节目接入

节目来自组播信源流，一个信源流内包含多套节目。为了达到实时播放的目的，需要实现流媒体服务器推送视频/音频流，网页前端播放器在下载的同时进行播放。

国内主流的直播流媒体协议有动态码率自适应技术（HTTP Live Streaming, HLS）、实时消息传输协议（Real Time Messaging Protocol, RTMP）、HTTP-FLV（即将音视频数据封装成FLV，然后通过HTTP协议传输给客户端）。

HLS通过超文本传输协议（Hypertext Transfer Protocol, HTTP）传输，优点是能够避免防火墙拦截，自带动态码率自适应，支持平台多。其缺点是播放时会不停获取视频切片，延迟较高。

RTMP通过TCP传输，延迟低，长时间播放稳定，计算机平台普遍可播放，但不支持HTML5（构建Web内容的一种语言描述方式），也存在被防火墙拦截的可能。

HTTP-FLV通过HTTP传输，能够避免防火墙拦截，播放时没有复杂交互，延迟较低，支持HTML5。

对比之后，最终选择HTTP-FLV方式实现流媒体服务器的推流。

流媒体服务器运行流程如图2所示：

图2 流媒体服务器运行流程

2.5 链路图整合

由于发射台性质的差异，各台站的节传设备种类、节目类型、信号传输拓扑结构均有所差异，为了适应这种差异化，真实布局台站的实际传输链路，全节点动态链路图需要做到可编辑。

编辑主要涉及两点：一是管理链路与节点基本属性，同时负责管理链路与节点间的归属关系、节点与具体节传设备/发射机/节目的对应关系；二是可拖拽式布局，主要负责节点在链路中的布局，反映链路节点的上下游关系。经过编辑后，真实链路布局便以逻辑关系的形式映射在链路图中。

在全节点动态链路图中的每个设备节点、发射机节点、节目节点均有全局唯一的ID，数据在节传设备、发射机管理层、流媒体服务器与全节点动态链路图Web服务器间流转时，通过ID来将每个节点进行区分。每当节点对应设备工况发生变化或报警发生时，网页前端根据唯一ID精准显示。

3 结语

全节点动态链路图接入并联动了节传设备、发射机、信源节目，将智慧运维系统分散、独立的业务模块整合起来，直观、实时地展示链路内各节点设备的工况信息，实现全链路的集中监管，使智慧运维系统更加完善，定位排障更加容易，监管更加高效，系统更加稳定。