索道状态检测系统

项目介绍

索道、缆车这类特种设备的运行安全高度依赖持续的状态监测——电机过热、缆绳张力异常、支架倾斜、风速超标都可能酿成事故。这个项目以若依 RuoYi-Vue 3.8.9（Spring Boot 2.5.15 + Vue 2 + Element UI）为底座，实现了一个面向索道运行场景的状态检测管理平台，覆盖”传感器数据采集 → 阈值判断自动报警 → 历史数据存储 → 维护排班与台账 → 视频监控”的完整闭环。

后端业务集中在 com.ruoyi 下的 state、history、information、rtsp 四个包：state 是核心，包含数据采集（StateGatherController）、数据存储（StateStorageController）、警报信息（StateAlarmController）、报警阈值配置（state_alarm_config）、维护管理（StateUpholdController）与任务（StateTaskController）；information 管理设备、员工、备件三类基础资料；history 记录维护历史台账；rtsp 负责视频流接入。SQL 初始化脚本 20250508-suodao.sql 在若依基础库之上新增了 state_gather、state_storage、state_alarm、state_alarm_config、state_uphold、state_task、state_threshold、history_upload 等业务表。

项目架构

项目是典型的前后端分离单体：后端为若依多模块 Maven 工程（rsd-admin、rsd-common 等），前端为 Vue 2 工程。安全与权限沿用若依标准实现——Spring Security + JWT + Redis，数据库用 MySQL + Druid 连接池，MyBatis 负责常规 CRUD，PageHelper 分页，代码生成器基于表结构一键生成前后端页面。

区别于普通若依项目的地方在于引入了两个组件：一是 rsd-common/pom.xml 中引入的 com.easy-query ORM 框架，在 application.yml 中开启 easy-query.enable，StateGatherController.async() 直接用 EasyEntityQuery 完成”清空 state_storage → 遍历 state_gather 组装 → 批量插入”的同步操作，代码里还通过 @EntityProxy 生成类型安全的代理查询对象；二是集成 FFmpeg 与 WebRTC 的视频链路——RtspController 用 ProcessBuilder 拉起 ffmpeg 进程，以 -rtsp_transport tcp -c:v libx264 -preset ultrafast -tune zerolatency -f hls -hls_time 2 -hls_list_size 3 -hls_flags delete_segments 参数将 RTSP 流转为 HLS 分片，前端首页配合 webrtcstreamer.js 实现低延迟播放。

数据模型上，系统刻意区分了实时采集表 state_gather 与历史存储表 state_storage：前者是监测数据的”入口”，新增记录时触发报警判断；后者是同步归档的”仓库”，避免实时写入与历史查询相互干扰。阈值配置 state_alarm_config 与 state_threshold 并存——前者用于采集时的即时报警比对，后者则以 threshold_key + 上下限 + 警告级别（1 一般 / 2 重要 / 3 严重）的通用形式沉淀了 13 项监测参数的出厂阈值（如电机温度 085℃、风速 015m/s、缆绳张力 1000~5000N）。

核心功能

• 16 项状态指标采集：StateGatherController.add() 在采集记录入库时生成驱动电机温度（2080℃）、电机转速（10003000r/min）、电压（220250V）、电流（1030A）、制动器状态、缆绳张力（10001500N）、缆绳振动频率、腐蚀程度、支架倾斜角度、吊具门状态、实时载重（50200kg）、吊具加速度、紧急停车记录、实时风速（0~20m/s）、环境温度、空气湿度等指标；前端采集页以 el-tag 带单位渲染各指标，制动器”启用/禁用”、吊具门”打开/关闭/异常”等枚举值用彩色标签区分，支持按采集时间范围检索和导出 Excel。
• 阈值自动报警：采集入库后立即与 state_alarm_config 阈值逐项比对，任一指标超限即生成 StateAlarm 报警记录——自动定位到具体索道（如”索道20”）、识别超限的传感器类型（温度传感器/转速传感器/电压传感器等）、记录异常数值、严重等级、相关设备”索道电机”、视频快照文件名与行动建议”请检查相关设备并进行维护”，状态初始为 0（未确认）；前端警报页以红色”未确认”、绿色”已解决”标签呈现，支持人工修改处理记录闭环。
• 实时/历史数据分离：采集页的”同步”按钮调用 /state/gather/async，服务端用 EasyEntityQuery 先清空 state_storage 再批量插入全部 state_gather 记录，实现一键归档；存储页同样支持检索与导出，为后续趋势分析保留数据底座。
• 维护排班与台账：维护管理页以”系统名称 × 星期一至星期日”的排班表格配置每日维护人员（数据落在 state_uphold，按日常/定期区分），维护人员来自员工资料下拉；维护历史页（history_upload）记录每次维护的时间、系统、维护人员、附件、维护状态（未完成/已完成/异常终止）、维护类型（日常/定期/专项）与系统状态（停用检修/运行中）；任务管理（state_task）覆盖任务名称、设备编号、负责人、计划/完成时间、任务状态与紧急程度。
• 基础资料管理：设备资料（information_device）为树形结构，支持设备描述、数量、状态；员工资料（information_employee）同样树形化，为排班提供人员来源；备件资料（information_spare）记录规格、类型、关键参数、兼容性、供应商、采购负责人、当前库存与最低库存、存放位置、建议更换频率，支撑维护物资管理。
• RTSP 视频监控：RtspController 提供 /rtsp/start 与 /rtsp/stop，输入 RTSP 地址后由 FFmpeg 实时转 HLS 并维护分片目录；首页”监控大屏”页面内置 WebRTC 播放器（webrtcstreamer.js + STUN 配置），输入地址即可开始/停止播放，与状态检测数据共同构成监测中心。

功能截图

暂无运行截图。

快速上手

项目为标准若依前后端分离工程，后端要求 JDK 1.8。部署时先执行根目录的 20250508-suodao.sql 初始化数据库（含若依基础表、Quartz 定时任务表与索道业务表、菜单权限），再按需调整 rsd-admin 下 application.yml、application-druid.yml 中的 MySQL、Redis 连接配置，启动 rsd-admin 模块；前端在 20250508-索道状态检测-web 目录执行 npm install && npm run dev 即可访问。RTSP 视频功能需在配置中指定 ffmpeg.bin.path 与 ffmpeg.output.path（默认 ./hls），并保证 ffmpeg 可执行文件就位；调试视频流可参考代码注释用 VLC 推流或 ffmpeg -re -stream_loop -1 命令模拟 RTSP 源。

总结

这个项目把”监测”和”运维”做进了一个系统：传感器数据采集、阈值自动报警、历史归档、维护排班、维护台账、备件库存到视频监控，职责清晰、链路完整。技术上以若依框架为底座快速搭建管理后台，用 easy-query 简化批量数据同步，用 FFmpeg + WebRTC 补齐视频能力，展示了在成熟框架上叠加行业业务模块的典型做法。当然项目也保留着原型阶段的痕迹——采集接口使用随机数模拟传感器数据、报警配置采用单例表、async 同步为全量覆盖式写入，这些都是后续接入真实传感器硬件、改为增量入库与定时采集时需要重点改造的方向。