煤矿人员定位系统数据不对称分析

2022-11-15 08:03邓颖松
能源与环境 2022年4期
关键词:预警系统时刻轨迹

邓颖松

(福建省华厦能源设计研究院有限公司 福建福州 350000)

1 概述

为抓好矿山安全,切实保护好煤矿员工的生命安全,国家矿山安全监察局(福建局)利用“福建煤矿安全风险监测预警系统”平台,在线远程监察执法。通过对各类异常报警数据分析并做出煤矿安全风险研判,落实隐患整改[1]。煤矿人员定位系统上传数据的准确性、有效性、实时性将对煤矿安全风险起着决定性的作用。

2 安全监测预警系统平台人员定位数据采集原理解析

数据层数据完全由本地人员系统厂家提取本地数据库数据生成,临时存放在本地D 盘“EXCHANG”目录下。平台在本地安装“GatherClient”采集服务,采集服务按文件生成的频率将暂存在“EXCHANG”目录下的文件取走。平台对数据层各模块数据制定准入规则,对采集数据进行关联分析判定,部分准入规则将在后文详细说明。符合规则的数据进入到数据管理层,否则将被取消采集,取消采集的文件存放在本地“XML”文件目录下。数据管理层的数据作为平台的基础数据,平台根据《煤矿安全规程》《煤矿安全监控系统及检测仪器使用管理规范》(AQ 1029—2019)、《煤矿安全监控系统通用技术要求》(AQ 6201—2019)等规范及要求对数据做出判定,最后在安全监测预警系统平台中显示出来。

3 本地人员定位系统数据采集原理与数据生成

3.1 数据采集原理

矿山人员随身携带的识别卡进入读卡器相应工作区域后,该人员编码经加密后即将信息发射出去;读卡器接收到识别卡发来的无线信号,经区域定位分站接收处理后,提取人员编码相关信息,经井下环网交换机传送至人员定位主机,完成矿井人员自动跟踪与定位管理。硬件信息将由获取环网相应设备IP 后自定义生成。该定位系统还具有人员超时、区域超员、人员求救、考勤管理等功能。本地系统配置SQL SERVER 2008R2 数据库,存储本地系统产生的各类数据。

3.2 数据生成

本地人员定位系统的数据展示全部基于本地SQL 数据库。由于安全监测预警系统平台数据无法直接调取本地数据库,所以系统厂家需按平台要求重新编写一个数据生成程序,从数据库中生成符合平台采集格式及规则的数据。

本地人员定位系统是基于系统自己的规则生成数据,并存储至SQL 数据库。安全监测预警系统平台的数据是基于本地生成且判定合格后的数据。从数据来源的角度来看,本地数据一定是大于平台归集的数据,本地系统产生的数据一旦被平台判定为不规范数据,那本地端与平台监管端数据不一致的问题便体现出来。煤矿人员定位系统采集数据生成文件及生成频率要求如表1。

表1 数据生成文件及频率

4 数据有效性解析

4.1 生成时间的有效性

同类相邻的2 个文件生成时刻必须是以上表格中生成频率的0.8 倍~1.5 倍之间。

4.2 生成格式的有效性

生成文件的文件格式必须是“.xml”的文件格式,时间格式必须是“yyyy-mm-dd hh∶mm∶ss”。

4.3 规则的有效性

(1)基站实时数据规则。基站实时数据内的基站数量必须与基站基本信息数据内基站的数量一致。

(2)井下作业人员实时数据规则。①人员进入下一基站时刻不应早于前一基站时刻;②人员入井时刻不应晚于数据文件生成时刻;③人员出井时刻不应晚于数据文件生成时刻;④人员出井时刻不应早于行进轨迹最后基站读取时刻。

(3)人员基本信息规则。“姓名”“身份证”“职位”“职务”“工种”这5 个字段为必填项。

(4)区域基本信息规则。严格按照国家对煤矿井下单班作业人员限员规定。目前福建煤矿分2 个生产能力判定:①30 万t/a<生产能力≤60 万t/a 的矿井,单班人数应≤100 人;②生产能力≤30 万t/a 的矿井,单班人数应≤80 人。

5 不对称案例分析

5.1 案例1:出入井记录不完整

2022 年3 月20 日—3 月22 日,池坪芦坑卡号为5409 人员本地系统均有2 次出入井记录,但预警系统平台中前一次显示未出井,后一次却没有出入井记录。数据处理流程如图1所示。

图1 数据处理流程图

分析数据生成记录文件:调取2022 年3 月20 日本地生成程序数据查看,有一条完整的出入井记录对应时刻为2022-03-20 11∶51∶33—2022-03-20 12∶18∶40。同样调取平台数据查看却只有一条入井记录对应时刻为2022-03-20 11∶51∶33--。由流程图可知本地系统数据没有过多的限制规则判定,输出的记录完整。平台添加了判定规则后,该数据通过了“基本信息判定”“入井时刻判定”,但没有通过“出井时刻判定”。

根据判定规则对该出井数据分析:发现轨迹的生成逻辑产生了错乱,多生成一条轨迹。正常逻辑是最后进入的读卡器编号应为001R01,时刻也应为2022-03-20 12∶18∶40,而这个数据最后多生成了一条进入读卡器编号为006R02 的轨迹,该轨迹的时刻对应为2022-03-20 12∶11∶47,这违反了规则有效性“人员进入下一基站时刻不应早于前一基站时刻”的这条规则。所以该条出井数据被取消采集,所以该人员在预警系统平台没有出井记录。

3 月22 日卡号5409 本地明明有出入井记录,预警系统平台却没有记录。调取本地生成数据查看,未发现卡号5409 的数据,但本地SQL SERVER 2008R2 数据库中有出入井数据,基于本地数据库,所以本地系统有记录。由于生成程序未将卡号5409 人员信息生成出来,因此该人员信息不存在,所以该人员当天没有出入井记录。

进一步分析生成程序漏生成记录问题,从本地系统数据可以看出,入井时刻为17∶03∶27,出井时刻为17∶06∶44,时刻间隔3 min 17 s。查看生成程序发现,该程序设置的生成频率规则也是5 min,但生成程序只生成在这个周期内有入井时刻,未出井人员数据,在一个生成周期内出入井人员数据被生成程序自动忽略,所以造成了该人员在这个周期内的数据丢失。

该案例是生成程序逻辑产生了问题。建议修改生成程序逻辑,第一种情况将出井读卡器读取时刻作为人员轨迹最后时刻,不应将前一个读卡器读取时刻添加到最后轨迹时刻。第二种情况需将一个采集周期内的出入井数据应从本地数据库中提取成出来,而不是忽略该数据。

5.2 案例2:出现一人多卡问题

2021 年12 月29 日,东井田煤矿当天有10 人同一时刻同时出井,国家矿山安全局(福建局)通过预警系统平台远程监察,质疑存在一人多卡问题,需矿方书面说明情况。

分析数据生成记录文件:分别调取2021 年12 月29 日平台数据和本地数据查看,对应不同人员的入井时刻,均有生成完整的出入井记录,说明这些人员信息均通过了平台判定规则。通过判定的数据作为基础数据,平台将对这些数据分析研判。一人多卡判定流程如图2 所示。

图2 一人多卡判定流程图

依据判定流程,分析到这10 个人出井时刻均为2021-12-29 12∶11∶15,平台判定疑似一人多卡。但从本地的查询数据中发现,出井时刻并非一致,但为什么会生成一致的时刻呢?经数据分析比对及查看生成程序发现,该组数据均为1 个采集周期(5 min)内产生的数据,各个人出井的时刻不同且相差在5 min 以内,数据文件生成时刻为2021-12-29 12∶11∶20。程序开发人员为了满足“人员出井时刻不应晚于数据文件生成时刻”这个规则,将该时刻周期内最后一个出井人员的出井时刻赋予了所有这周期内出井的人员。为了满足规则而赋予一个与实际不符的时刻,造成了预警系统平台的误判。

该案例是生成程序直接赋值出井时刻造成的。建议不可随意修改原始数据,在数据生成上多增加几条相应的判断语句。

5.3 案例3:人员轨迹缺失

国家矿山安全监察局(福建局)通过“福建煤矿安全生产风险监测预警系统”平台,远程监察中发现部分矿井人员轨迹存在缺失,其表现形式为人员在井下突然消失,无法获取到人员实时信息。若轨迹缺失人员为带班领导,则该时间段平台显示“空岗”。存在人员轨迹缺失的可能性如下3 点。

(1)矿井区域设置异常。根据福建省矿山特点,人员定位系统设定以下区域:重点区域、限制区域、井口区域等,若这几个区域的关键词无法被识别,生成程序会自动归集为其他区域。由于本地设置是几个不同区域,但程序生成仅有1 个区域有2 种情况:①生成程序会把各区域限员人数累加,造成区域人员超限设置,违反了本文中区域基本信息规则,平台按规则判定为无效数据、取消采集;②人员实际轨迹在区域间切换,生成数据产生错乱,进入新区域后由于无法正确识别该区域而丢失数据。

(2)读卡器关联区域异常。每个区域应安装相应的分站和读卡器,在本地系统设置完区域后,相应的读卡器要关联上,否则该读卡器读到的数据无法写入数据库,造成人员轨迹消失。

(3)井下分站时刻未同步。正常井下分站时间需要与地面定位主机的时间同步,若未同步会违反本文中井下作业人员实时数据的规则,该数据将被取消采集。

该案例问题的关键是本地系统基础数据不规范造成的,建议按规范设置本地系统,按规则生成相关文件。

5.4 案例4:出现带班空岗问题

多次出入井部分数据丢失造成人员未出井带班空岗:2022 年5 月16 日,平台显示卡号尾数为5431 的人员未出井,卡号尾数为2589 的矿领导空岗34 min 43 s。带班空岗判定流程如图3 所示。

图3 带班空岗判定流程图

分析数据生成记录文件:卡号尾数为5431 的人员单天多次出入井,平台显示其中3 条出入井记录分别为:19∶08∶27—19∶43∶09;19∶48∶02—20∶14∶38—20∶51∶03。该数据稍作分析可以发现未出井数据存在明显的问题,若19∶48∶02 入井尚未出井,那20∶14∶38 这条出入井记录是如何产生的呢?进一步对19∶48∶02 这条入井记录前两组数据比较分析,平台端前一条出入井数据显示19∶08∶27—19∶43∶09,本地端前一条出入井数据显示19∶08∶27—20∶00∶42。为什么同一个入井记录出现2 个不同的出井记录?查看本地数据库文件,并没有19∶43∶09 的出井时刻,也没有19∶48∶02 的入井时刻。

很明显,又是生成程序出现了问题,程序为了解决多次出入井轨迹连续性问题,强制给19∶08∶27 这条入井数据补充了一条19∶43∶09 的出井数据和下一条19∶48∶02 的入井数据,生成程序实际也有对应19∶48∶02 的入井数据,生成了一条19∶58∶13的出井数据,巧的是该条数据违反了本文中区域基本信息的规则被取消采集,导致平台只收到入井时刻,没有出井时刻。

该矿山为一天两班制,正常中班领导带班出井后井下将没有工人再作业。当日卡号为2589 的中班带班领导于23∶25∶16出井,卡号尾数为5431 的人员由于其中一条数据出井时刻未被采集,所以当日在井下停留时刻至23∶59∶59。依据空岗流程对出井时刻比较:23∶59∶59>23∶25∶15,所以判定为“空岗”时刻差为34 min 43 s。

该案例中除了多生成不规范数据外,空岗问题明显是受卡号5431 数据关联产生的。建议生成程序对关联数据充分考虑,不应满足个别需求而忽略了数据的统一性和真实性,修改程序算法,按规则生成相应数据,使平台与本地数据一致。

6 结语

矿山人员定位系统采集了各工种人员的出入井信息、区域信息、轨迹信息、超时信息、求救信息等,这些数据的有效性和真实性对安全生产和应急救援起到至关重要的作用。“福建煤矿安全风险监测预警系统” 平台的建设基于矿山这些数据的归集,使得监察工作又多了一种方式。做好本地数据与平台数据的比对与分析,及时协助程序开发人员修改相应程序,保持数据的一致性,为矿山企业的安全生产,以及监管部门的远程监察及风险防控起到积极的作用。

猜你喜欢
预警系统时刻轨迹
冬“傲”时刻
捕猎时刻
民用飞机机载跑道入侵预警系统仿真验证
轨迹
轨迹
一种基于CNN迁移学习的井下烟、火智能感知预警系统
基于ZigBee与GPRS的输电杆塔倾斜监测预警系统
轨迹
进化的轨迹(一)——进化,无尽的适应
桥、隧安全防范声光预警系统