塔式起重机(简称塔机)在建筑施工领域得到了广泛的应用, 已经成为现代施工中必不可少的关键设备. 目前, 塔机一般是就地手动操控方式, 需要专业的操作人员在塔机上面的驾驶室内进行高空操作. 由此会带来一些问题: (1) 塔机操作人员每次登机工作时需要攀爬塔机, 既浪费时间, 又有严重的安全隐患, 时有坠落事故发生; (2) 操作人员需要长时间在高空工作, 不仅工作环境恶劣, 影响身心健康, 更严重的是当塔机发生倒塌等安全事故时, 操作人员的人身安全无法保障; (3) 操作人员在一个台班内只能操作一台塔机, 人员利用率低. 近年来, 塔机监控技术已经取得了一定的发展, 利用网络通讯和传感器采集, 塔机监控系统能够实现实时数据采集、运行状态报警等功能^[1-5]. 但并没有改变塔机操作人员只能在高空操作单台塔机的作业模式, 因此上述问题依然存在.

本文提出了一种塔机远程控制系统, 将通讯服务、媒流体服务、应用服务部署在边缘云服务器(MEC)上, 实现多台塔机、多个操作客户端的灵活接入和综合管控, 同时利用5G网络低时延、大带宽、高可靠性的特点有效支撑大范围的远程通讯. 通过远程控制, 操作人员在地面实现对塔机操控并完成吊装作业, 该操作方式可显著改善操作人员的工作环境, 提高人员利用率, 提升安全性能.

1 系统功能及配置

整个系统(图1)分为以下4个部分: (1) 集中管控平台: 部署在边缘云服务器上, 提供基本通讯功能、集中管理服务、流媒体服务及其他应用服务; (2) 操作客户端: 配置PC、IO控制器、操作平台及操作元器件, 一方面可实时监控所选择的塔机对应的视频/音频信号、传感器数据及电控系统状态, 另一方面通过输入正确的帐号、密码获取相应的控制权限, 利用集成的操作装置对所选择的塔机进行远程操控; (3)塔机侧监控系统: 包括电控系统和视频/音频监控系统, 电控系统控制执行机构的电源和动作并采集塔机各种传感器的状态, 视频/音频监控系统负责采集现场的视频、音频信号; (4) Web监视: 利用PC或手机上的Web浏览器通过公网可以监视所选塔机的传感器状态信号和视频信号.

操作客户端可以集中布置在操作中心, 能够实现多项目多塔机的集中作业和操作人员集中管理. 操作客户端也可分散配置在单独的操作室, 灵活开展吊装作业.

1.1 功能概述

集中管控平台可以接入多台塔机、多个操作客户端, 操作人员可在任意一个客户端登录. 客户端发送相关的登录信息给服务器, 服务器返回注册的塔机列表. 操作人员从列表中需要操控的塔机, 客户端将获取被选塔机的相关信息展示给操作人员, 同时将操控命令发送给所选塔机.

在服务器端实现以下功能: (1) 操作人员及权限管理; (2) 塔机侧状态数据接入; (3) 同客户端的历史数据交互; (4) 塔机侧和客户端状态、控制数据的实时转发; (5) 塔机侧媒流体数据接入; (6) 客户端的媒体流数据请求处理, 媒体流数据的实时转发; (7) 数据存储; (8) 塔机信息管理、设备信息管理; (9) 其他应用服务.

根据操作人员所选的塔机, 客户端能够展示实时数据和历史数据, 并把控制命令发送给塔机侧. (1) 展示的实时数据包括传感器数据、当前的报警信号、视频/音频数据, 以及集成的操作装置的状态. (2) 展示的历史数据包括传感器数据历史记录、历史报警, 记录视频/音频历史记录, 以及操作记录. (3) 控制命令主要包括塔机动作命令和传感器标定命令.

1.2 远程通讯配置

本系统采用基于5G MEC的5G网络实现远程通讯, 终端利用5G CPE接入5G网络.

MEC指的是在无线接入网中安装计算资源的分布式系统. 与传统的集中式服务器架构不同, MEC服务器由运营商在本地进行管理, 实现通讯服务的就近处理, 提供通讯数据本地分流、数据不出场的能力, 也就是说通讯数据从一个终端向另一个终端传输时, 在MEC服务器就能够进行中转, 不需要经过骨干网和互联网, 此外, 用户可以通过接口访问MEC服务器中的虚拟计算资源, 通过MEC服务器提供的本地虚拟机来为用户提供服务^[6-10]. 因此我们将应用服务和视频服务都部署在MEC服务器上.

1.3 管控平台的基本配置

管控平台部署在MEC上, 采用Ubuntu操作系统. 整个塔机管控系统以MEC服务器为中心, 所有数据都在此进行处理、存储和转发. 服务器采用模块化的设计, 服务器包含应用服务单元、媒体处理单元, 并通过信令处理单元来协调应用服务单元和媒体处理单元. 服务器的应用服务单元采用Node.js+Vue来进行开发, 媒体处理单元采用C++进行开发.

服务器使用的TCP/UDP端口如表1.

1.4 客户端的基本配置

客户端有两种类型, 一种具备远程操作塔机的功能, 采用.NET平台开发, 在PC上运行, 为了保证通讯的低延时, 客户端通过MEC的内网访问服务器; 另一种不具备远程操作功能, 利用浏览器进行远程监视, 可以通过公网访问MEC.

2 关键功能的实现 2.1 状态数据和控制数据的处理

对于状态数据和控制数据在服务器中的处理、存储、转发, 由应用服务处理单元完成, 具体包含以下一些服务.

设备发现服务: 对于新注册的塔机进行发现、协助注册.

状态同步服务: 接受已注册塔机的同步信号, 在数据库中存储塔机的状态数据.

指令转发服务: 客户端的操作指令经过该服务核对后转发至所选择的塔机设备, 同时塔机的状态数据经过该服务核对后转发至选择该塔机的客户端.

连接管理服务: 负责同客户端连接的建立、连接数据更新及连接优雅断开等.

连接维持服务: 连接的监控、异常发现、告警功能.

如图2所示, 是数据的处理流程, 下面以具备操作功能的操作客户端和服务器的交互为例, 对每个步骤的详细说明:

(1) 某项目的塔机准备接入MEC, 塔机侧的PLC内预存了该台塔机的编号(1001)、MEC服务器的IP地址以及相关服务的端口号, 首先会向服务器的设备发现服务发送注册申请.

{

“type”: “register”,

“sourceId”: 1001,

“targetId”: 0101,

… // 塔机自身参数及相关校验

}

(2) 服务器的设备发现服务接收到注册申请, 检查状态并校验合法之后, 在数据库中记录已发现塔机的设备编号, 则认为该设备已经注册. 同时注册申请结果会返回到申请塔机. 塔机相关信息见图3.

(3) 塔机注册通过后, 塔机侧PLC会和服务器建立TCP连接(如图2中11所示), 实时发送塔机状态到状态同步服务.

{

“type”: “status_sync”,

“sourceId”: 1001,

“targetId”: 0101,

… // 塔机实时状态及相关校验

}

(4) 状态同步服务收到塔机的报文后, 查找数据库中已注册塔机编号, 确认塔机编号是否已注册.

(5) 状态同步服务按一定周期在数据库中存储已注册塔机相关数据, 需要存储的数据可以在数据字典中进行选择.

(6) 通过PC客户端, 在塔机列表中选择需要操控的塔机, 获取相应的塔机编号. 同时向服务器的连接管理服务提出连接申请, 申请报文如下(该客户端编号为3001).

{

“type”: “login”,

“sourceId”: 3001,

“targetId”: 0101,

“requestDeviceId”: 1001,

… // 登录帐号、密码以及相关校验

}

(7) 连接管理服务查找申请连接的塔机是否处于正常状态, 确认和服务器的通讯是否正常.

(8) 连接管理服务查找已配对塔机设备与客户端, 确认目标塔机未被其他客户端连接.

(9) 当连接申请返回成功后, 客户端会和服务器建立TCP连接, 实时发送控制指令到服务器的指令转发服务.

{

“type”: “operation”,

“sourceId”: 3001,

“targetId”: 0101,

“remoteDeviceId”: 1001,

… // 操作指令及相关校验

}

(10) 指令转发服务收到控制指令报文校验后转发到对应塔机PLC中(利用状态数据发送的TCP连接), 以下为部分代码:

var bithp=new bitConverter(buff)

　var sourceId = bithp.getStr(0, 4)

　var remoteDeviceId = bithp.getStr(8, 4)

　chanel.code= sourceId

remoteSockeLis = remoteSockeLis.filter

(t=>t.code!=sourceId)

　　remoteSockeLis.push(chanel)

　　if(!remoteDeviceId||remoteDeviceId[0]!=“1”)

　　return

var localItem =localSocketList.filter

(t=>t.code==remoteDeviceId)

　　if(localItem&&localItem.length>0)

　　localItem[0].write(buff)

(11) 客户端选择塔机后, 在退出前会持续地向服务器发送报文, 报文中除了包含目标设备的编号和控制命令的状态, 还包含生命计数值和校验码: 生命计数值每发送一次增加1, 校验码则是对报文的有效数据按照校验算法计算其校验码.

塔机PLC接收到服务器转发的控制指令报文后, 会按照图4方法判断收到的数据是否有效.

当100 ms内没有接收到有效的新报文, 塔机侧PLC会认为出现问题禁止塔机执行机构动作, 等待通讯恢复.

(12) 塔机接收到控制指令后, 会在返回的TCP报文中增加客户端的编号.

{

“type”: “undercontrol”,

“sourceId”: 1001,

“targetId”: 0101,

“remoteDeviceId”: 3001,

…//塔机实时状态、操作指令结果及相关校验

}

(13) 服务器收到报文后, 一方面状态同步服务会按要求更新数据库, 另一方面指令转发服务会根据客户端的编号将状态数据转发到客户端(利用控制指令发送的TCP连接).

(14) 连接维持服务以一定周期查找已注册塔机设备列表, 获取其登录时间、更新时间等信息, 实时监控塔机设备是否掉线或者出现其他问题.

(15) 连接维持服务以一定周期查找已配对塔机设备与客户端, 检查连接状态, 当连接异常断开、连接超时、系统安全异常等状态出现时, 及时通知其他各服务、塔机设备及客户端, 同时采取措施优雅断开连接.

2.2 媒体流数据的处理

媒体流数据的处理流程参见图5, 主要包含以下几个过程.

2.2.1 服务器信令处理单元和媒体处理单元的交互

媒体处理单元主要负责现场视频/音频设备的注册、媒体流数据接入、媒体流转发.

媒体处理单元和信令处理单元之间的信息交互采用JSON格式, 包括以下一些信息.

(1)媒体处理单元发送给信令处理单元的事件消息, 包括:

1)设备注册成功消息

{

“notify”:

{

“type”:“sipRegist”,

“seq”:1,

“timestamp”:11111,

“sipid”:"001”,

“rtspURL”:"rtsp://xx.xx.xx.xx/live/34020000001110000001@34020000001320000003”, “webrtcURL”:“webrtc://xx.xx.xx.xx/live/34020000001110000001@34020000001320000003”

}

}

消息体包含有: type (消息类型)、sep (序列号)、timestamp (时间戳)、sipid (设备ID)、rtspURL (设备的rtsp点播地址)、webrtcURL (设备的webrtc点播地址).

2)断流检测信息

{

“notify”:

{

“type”:“StreamOffLoad”,

“seq”:1,

“timestamp”:11111,

“sipid”:“001”

}

}

3)设备断线

{

“notify”:

{

“type”:“sipRegistOffline",

“seq”:1,

“timestamp":11111,

“sipid":"001”

}

}

4)硬盘录像机存储故障

{

“notify”:

{

“type”:“storeOfBreak”,

“seq”:1,

“timestamp”:11111,

“sipid”:“NVR”

}

}

(2)信令处理单元发送给媒体处理单元的查询消息

{

“request”:

{

“type”:“requestURL”,

“seq”:1,

“timestamp”:11111,

“sipid":"001”

}

}

根据sipid (设备ID)查询对应的点播地址URL.

(3)媒体处理单元发送给信令处理单元的响应消息

{

“response”:

{

“type”:“requestURL”,

“seq”:1,

“timestamp":11111,

“sipid":“001”,

“rtspURL":“rtsp://xx.xx.xx.xx/live/34020000001110000001@34020000001320000003”,

“webrtcURL":“webrtc://xx.xx.xx.xx/live/34020000001110000001@34020000001320000003”

}

}

对信令处理单元的查询消息进行回复, 返回sipid(设备ID)对应的点播地址URL.

信令处理单元获取现场视频/音频的设备ID、点播地址URL及相关的故障信息后, 将把这些信息和塔机信息关联起来, 如图6所示.

2.2.2 现场视频/音频的注册及数据接入

每台塔机配置一个硬盘录像机, 现场的摄像头和音频采集设备以通道的形式绑定硬盘录像机. 硬盘录像机和服务器的交互采用GB28181协议.

硬盘录像机为每一个设备分配sipid, 同时向服务器的媒体处理单元发送注册请求. 媒体处理单元收到注册信息, 保存注册信息, 保持与其会话, 同时向硬盘录像机请求摄像机设备列表信息. 媒体处理单元根据硬盘录像机回复的消息更新现场设备的状态信息(包括sipid和上线状态).

媒体处理单元向硬盘录像机设备列表发送对应的invite请求从而获取媒体流信息. 同时为每个设备建立webrtcURL和rtsp转发地址. 图7是媒体流数据的接入处理.

2.2.3 客户端获取媒体流过程及服务器媒体流转发

针对两种不同的客户端, 媒体流传输采用不同的方式: 对于具备操作功能的.NET客户端, 采用rtsp协议; 对于只有监视功能的Web客户端, 采用webrtc技术.

客户端完成登录并在列表中选择塔机后, 服务器会将该塔机对应的视频/音频设备的点播地址返回给客户端. 对于.NET客户端, 根据rtsp地址向服务器请求流媒体数据; 对于Web客户端, 根据webrtc地址向服务器请求流媒体数据.

服务器的流媒体处理单元收到请求后, 转发现场设备的流媒体数据给相应的客户端.

具体处理流程参见图8和图9.

3 应用效果 3.1 远程操作

操作人员利用具备操作功能的PC客户端, 登录MEC服务器后, 则可以通过集成的操作装置远程操控已注册的塔机. 操作人员登录过程如图10所示.

目前操作客户端集成的操作装置有两种形式, 一种是多功能操作台(图11), 一种是体感座椅, 均配备了多台显示器, 全方位地展示塔机的状态数据和视频监控.

在塔机侧安装惯导、倾角仪等检测元件, 通过状态数据发送给客户端. 利用这些状态数据控制体感座椅动作还原驾驶舱前俯后仰、左倾右倾等晃动状态, 带来沉浸式体验, 如图12所示.

本系统支持多台塔机、多个操作客户端的灵活接入. 操作客户端可以在网络条件满足要求的任意位置接入系统, 同时可以操控已经注册的任何一台塔机.

由于采用了基于MEC的5G远程通讯, 对状态数据、控制数据及媒体流数据的转发控制采用了有针对性的控制策略和通讯协议, 保证了远程数据传输的低时延. 塔机侧PLC和客户端PC之间, 控制数据和状态数据传输的平均时延低于25 ms, 媒体流数据传输的平均时延低于60 ms, 满足实际吊装作业的需求.

3.2 远程监视

使用普通的PC或手机, 在接入互联网的条件下, 就能使用浏览器远程监视现场已注册塔机的运行情况, 如图13所示.

通过互联网访问, 网络通讯情况不稳定, 在客户端显示视频数据时容易出现花屏、马赛克及卡顿等问题. 由于只是起监视作用, 对通讯时延的要求低. 通过在webrtc服务端适当增加媒体流数据缓存, 保证媒体流数据在服务器上使用webrtc方式转发之前的顺序性, 从而保证在客户上视频展示的流畅性.

4 结论与展望

为改变塔机原有的操作方式, 本文提出基于5G的塔机远程控制系统. 通过配置集中管控平台, 能够实现多台塔机、多个操作客户端的灵活接入. 对于远程控制, 保证现场设备和操作端之间数据传输的低时延至关重要. 首先, 管控平台对状态控制数据、媒体流数据的处理采用模块化的处理服务. 同时, 对于具备操作功能的操作客户端, 一方面针对需要实时传输的状态数据和控制数据, 服务器采用单独的TCP连接直接进行转发; 另一方面针对媒流体数据的传输, 服务器采用RTSP传输协议向客户端转发数据, 从而保证了实时数据传输的低时延. 而对于只具有监视功能的客户端, 则采用了基于网页的形式, 增加了访问的便捷性.

在后续工作中, 可以建立区域级的塔机集中操控中心, 同时利用一人能够分时操作多台塔机的特点, 提高操作人员利用率.