各位小伙伴，本期我们继续聊聊 TSDB 的应用。本文也参考了杜志刚、储楠以及罗克在《工矿自动化》杂志所发表的《井下位置服务系统设计》一文，在此，感谢大家对行业发展所做出的贡献。

本文仅代表个人观点，如有偏颇之处，还请海涵～

🤠🤠🤠

TSDB 助力井下位置服务

位置信息对于井下安全生产意义重大，其是井下作业的重要安全屏障。井下巷道密如蛛网，但每一个角落都必须覆盖“生命的信号”。我们需要一套集人员实时定位、轨迹跟踪查询、安全警示报警监测、应急快速搜寻等功能于一体同时兼容车辆定位的系统。井下的位置信息确保了作业人员始终处在可视、可控、可追溯的状态，其让井下与井上世界不再割裂，让那些焦灼的等待平静下来。

目前问题

井下定位如此重要，其不仅为灾时救援人员的行动提供了有效手段，也提高了运输调度管理水平和生产效率，帮助了装备之间的协同作业。但目前中国的井下定位系统也还存在诸多问题：首先，高精度、快速移动的位置需求没有得到满足。目前大部分系统还是区域定位，其响应时间一般大于 1.5s，定位精度小于 3m。其次，定位系统耦合性强，可扩展性差。所有业务固化在一个复杂的单体应用中，而井位置服务系统目前需要开放服务架构。再次，业务处理能力受到数据库承载能力制约。以煤矿为例，其一般采用三八制或者四六制得工作方式，并且 24 小时不间断工作，所以其系统会产生大量得数据，比如年产 300 万吨得煤矿，按三八制计算，每班大概需要 500 人下井，每人来回大概经过 30 个基站，如果每经过一个基站产生一条记录得话，每天产生 3×500×30=45,000 条记录,每月产生 45,000×30=1,350,000 条记录，国家要求下井信息至少保持 6 个月，这就是 1,350,000×6=8,100,000 条记录，可见对数据库得优化至关重要。最后，定位系统不支持二维或三维空间的位置服务。而智能化的开采不仅会有水平方向运动，还有垂直方向等多自由度运动过程。因此我们也急需一种新的架构，力求为井下定位提供更精准和优质的服务。

系统架构

井下位置服务系统主要由位置服务基础设施、数据驱动模块、位置管控中间件、位置服务接口和数据库组成，如图 1 所示。

位置服务基础设施主要由定位标志卡、定位基站、接收器和网关等硬件设备组成。接收器与定位标志卡实时通信，通过 UWB 定位技术获得定位标志卡到锚节点的距离信息，定位结果经算法优化后，汇聚存储至定位基站，等待相关模块读取。

数据驱动模块是主要实现数据巡检、数据接入、数据优化和控制命令转发等功能，模块内部数据传输采用 AES 对称加密算法，保护系统数据安全和井下敏感数据。

位置管控中间件主要功能是对各功能模块的数据进行管理，包括坐标管理、基站管理、状态管理、位置信息管理、时钟同步管理和位置服务接口权限管理等。

位置服务接口分为数据接口和控制命令接口。数据接口主要提供基站/接收器位置信息查询、目标对象实时位置信息查询、目标轨迹查询、报警信息查询等接口；控制命令接口提供井下基站/标志卡报警下发、短信息下发、井下设备配置等接口。接口设计为 WebAPI 方式，可跨平台使用，通过 Post 请求，获取 JSON 或 XML 格式的数据信息，为各种应用提供实时位置服务信息。

数据库是此架构的核心部分，其采用 RDBMS+TSDB 的混合存储模式，系统基本配置数据、目标对象实时位置数据等存储于 RDBMS 中，基于时间的目标历史位置数据、设备历史状态数据等使用 TSDB 存储。

图 1：系统架构

TSDB 带来效率提升

井下位置服务系统中，移动目标的位置信息随着时间推移不断变化，根据时间确定的历史位置信息数据将不断累积，且定位于服务无人驾驶的井下位置服务系统要求实时位置信息更新频率更高。传统关系型数据库注重增删改查和事务功能，存储采用 B-tree 形式，对于随机数据读写操作，会在磁盘寻道上消耗大量时间，使得关系型数据库逐步制约着系统对海量历史数据的处理能力。因此，系统引入 TSDB 对数据进行分类存储，将系统基本配置数据、目标对象属性信息、实时位置信息等存储于 RDBMS，将历史轨迹信息等时序数据存储于 TSDB，混合存储模式既保证了系统对基本数据的维护需求，又利用了 TSDB 处理高频变化的海量历史数据的性能优势，极大提高了系统的数据处理能力。也正是基于 TSDB 得帮助新的系统定位精度达 0.3 m，人员接近到闭锁响应时间不大于 500 ms，在危险区域人员接近监测方面取得了很得好效果。

CnosDB 简介

CnosDB 是一款高性能、高易用性的开源分布式时序数据库，现已正式发布及全部开源。

欢迎关注我们的社区网站：https://www.cnosdb.com