业务和功能介绍
本系统是一套面向离散制造车间的设备稼动率统计与运行监控系统，由我独立开发，核心目标是用自动采集的真实数据算出设备稼动率，而不是靠人工填报估算。
引入前的主要痛点是：管理者并不清楚设备一天到底运转了多少小时，稼动率只能靠班组长事后填写，数据失真且口径不一；设备大量时间处于待机、空转或故障停机状态却无人察觉，产能被白白浪费；想提升稼动率时，也说不清损失究竟来自待机、故障还是调试停机，改进无从下手。
系统围绕稼动率这一目标提供四块能力：
状态实时采集与看板：通过 MQTT 持续采集设备状态（运行/待机/故障/停机），按车间展示每台设备的当前状态与三色灯，并汇总各状态设备数量，让管理者随时掌握"此刻全厂有多少台在跑"；同时对超过 65 分钟未上报的设备判定为离线，防止通讯中断造成的"假运行在岗"拉高稼动率。
状态变化全量留痕：设备每次状态切换都会记录一条带精确时间戳的日志，据此可用相邻日志的时间差还原每台设备在各状态下的持续时长，进而统计任意时间段（当班、当日、当月）、任意维度（单台设备、单车间、全厂）的运行时间、待机时间、故障停机时间及稼动率。
日志查询与追溯：支持按车间、设备、状态筛选查询，既能作为稼动率数据的核对依据，也能直接定位某台设备何时发生故障、持续多久，找出拉低整体稼动率的瓶颈设备与主要损失原因。
异常报文记录与对外接口：无法解析的报文自动留存备查，保证采集不丢数、稼动率不失真；同时提供实时状态与日志探测 REST 接口，可对接车间大屏或 MES 等第三方系统取数。
由此带来的价值是：稼动率从"拍脑袋填报"转变为"系统自动统计"，口径统一、可追溯；管理者能清晰看到时间究竟损失在待机还是故障上，从而针对性压缩非运行时间；真实稼动数据也为排产排期、产能评估、班组绩效考核和后续设备投资提供了量化依据。
引入前的主要痛点是：管理者并不清楚设备一天到底运转了多少小时，稼动率只能靠班组长事后填写，数据失真且口径不一；设备大量时间处于待机、空转或故障停机状态却无人察觉，产能被白白浪费；想提升稼动率时，也说不清损失究竟来自待机、故障还是调试停机，改进无从下手。
系统围绕稼动率这一目标提供四块能力：
状态实时采集与看板：通过 MQTT 持续采集设备状态（运行/待机/故障/停机），按车间展示每台设备的当前状态与三色灯，并汇总各状态设备数量，让管理者随时掌握"此刻全厂有多少台在跑"；同时对超过 65 分钟未上报的设备判定为离线，防止通讯中断造成的"假运行在岗"拉高稼动率。
状态变化全量留痕：设备每次状态切换都会记录一条带精确时间戳的日志，据此可用相邻日志的时间差还原每台设备在各状态下的持续时长，进而统计任意时间段（当班、当日、当月）、任意维度（单台设备、单车间、全厂）的运行时间、待机时间、故障停机时间及稼动率。
日志查询与追溯：支持按车间、设备、状态筛选查询，既能作为稼动率数据的核对依据，也能直接定位某台设备何时发生故障、持续多久，找出拉低整体稼动率的瓶颈设备与主要损失原因。
异常报文记录与对外接口：无法解析的报文自动留存备查，保证采集不丢数、稼动率不失真；同时提供实时状态与日志探测 REST 接口，可对接车间大屏或 MES 等第三方系统取数。
由此带来的价值是：稼动率从"拍脑袋填报"转变为"系统自动统计"，口径统一、可追溯；管理者能清晰看到时间究竟损失在待机还是故障上，从而针对性压缩非运行时间；真实稼动数据也为排产排期、产能评估、班组绩效考核和后续设备投资提供了量化依据。
项目实现
项目采用 Django 6.0.4 + paho-mqtt 2.1.0 架构，数据库使用 SQLite，前端采用 Django 模板渲染，我独立负责了全部模块的设计与实现。整体分层为：模型层（Workshop、Device、DeviceStatusLog、IngestErrorLog）、服务层（parse_status_message、normalize_status 等解析归一逻辑）、视图层（dashboard、status_logs、API 接口）以及管理命令层（mqtt_consumer）。为了让不同厂商的网关都能顺利接入，状态解析既支持标准 JSON，也兼容 Python 字典字符串、松散对象格式和中文引号自动替换；状态码同时兼容现场实测码（RUN=57、IDLE=58、FAULT=60、OFF=56）与厂商码（62/61/59/63），统一映射后入库，从而支撑"统一接入标准"这一目标。为保障数据可用于追溯与统计，我通过 message_key/seq 字段与数据库唯一约束实现消息幂等去重，避免网关重发产生脏数据；并按 last_seen_at 与 65 分钟阈值判定离线，实现通讯失真识别。开发中的主要难点是 payload 格式不统一导致解析失败、同一状态存在多套码值需归一化、以及去重与过期消息处理，我通过多层解析兼容、统一映射表、事务内先查后写的方式逐一解决，最终实现了稳定运行的设备监控服务。
示例图片视频
相似推荐
B2C酒水O2O即时零售系统
负责B2C酒水即时零售电商0到1建设与3年迭代。核心业务为LBS定位、同城极速配送；功能包含多品类酒水商城、智能调度、促销裂变及会员管理，实现线上下单与线下极速履约。面向酒水消费的B2C即时零售平台，主打同城极速达。业务包括多品类酒水商城、LBS智能派单、营销活动及会员体系，实现线上下单、线下门店极速履约闭环，为用户提供29分钟送达的微醺体验。
股票量化分析系统
针对个人股票盯盘繁琐、行情分析片面、投资决策无数据支撑的问题，基于AI从零搭建轻量化股票智能分析系统，整合多源行情数据、智能分析、策略校验、消息提醒能力，辅助量化投资决策，每日定时输出分析到飞书。
绩效考核系统-绩效
1、统计分行行内各个团队、各个客户经理的每日业绩情况；
2、部门管理、员工管理、权限模块、业绩展示模块（存款、贷款、中间业务收入、经济资本成本、营业增加值、季度营业收入增加值）、数据台账模块（手工补息、业绩调整因素）、绩效分配模块（客户分配、账户分配、明细分配）、绩效参数模块、数据etl模块（总行BI、总行业务系统、总行ftp服务）等；
3、从总行BI报表系统、业务团队业务系统等数据源头利用rpa技术模拟人工获取相关数据录入到行内数据库中，根据业务相关指标规则及绩效分配规则，统计各个部门及各个客户经理每日、每月、每季度指标情况，指标包括存款、贷款、中收、经济资本成本、营收、营业增加值等；
ai量化智能交易客户端-mt5helper
ai智能交易软件，ai可以自己分析行情，可以记住用户需求，按照用户的交易习惯进行交易，有自进化能力，有向量化数据库作为知识库，有内置工具ai可调用，ai自我提升，用户行为分析，用户可以自我编写策略
股票交易与股东资金一体化Web-股票交易与股东资金一体化Web
GTMS 系统介绍
**GTMS**（Gupiao Trading Management Suite）是腾翼节能科技的股票交易与股东资金一体化 Web 平台，把对外门户、管理后台、股东客户端和审批中心放在同一套系统中。
## 解决什么问题
1. **股票**：自选股、行情、限价撮合、分红、扩股、交割单
2. **股东**：档案与持仓、开户/销户、组织架构、证件附件
3. **资金**：资金账户、银证转账（银行卡/支付宝/扫码）、费用单与收款单
4. **审批**：十余类单据统一待审/已审/驳回流转
5. **门户**：官网首页、关于我们、资讯与媒体配置
## 谁在用
| 角色 | 能力 |
|------|------|
| 公众 | 浏览门户首页、关于、新闻 |
| 管理端 | 全套管理（按职务与菜单权限裁剪） |
| 股东端 | 交易、交割单、转账等受限功能 |
| 高管 | 审批中心（部门总经理/总经理/董事长等） |
登录采用 JWT，区分管理员（`sys_user`）与股东（`mgmt_shareholder`）。
## 六大业务套件
- **股票管理**：列表与生命周期、行情下单、交割单、分红/扩股单
- **股东管理**：股东列表与详情、开户销户、架构、单据查询、合同配置
- **资金管理**：账户与流水、银证转账、费用/收款单、费率
- **审批中心**：费用、分红扩股、开户销户、银证/支付宝/扫码等单据
- **门户管理**：站点 CMS、权限、Logo/视频/公告等
- **系统管理**：账号、运行设置、主数据、数据备份与运维
## 典型流程（简述）
股票筹建→运行→股东限价委托→撮合成交→交割可查；分红/扩股、银证转账、开户等需审批的，通过后才落地资金与档案变更。
## 技术与部署
前端 `gtms-suite`（Vue 3 + Element Plus + Vite，开发默认 **5180**），后端 `gtms-api`（Spring Boot 2.7 + JWT，默认 **9042**），数据库 MySQL（库名 `gupiao`）。开发时前端代理 `/api`、`/media` 到后端；生产由 Nginx 同域反代。图片等附件走媒体存储（`/media`）。
更细的 API、表结构与包路径见 [SYSTEM.md](./SYSTEM.md)。
帮助文档
Copyright @ 2021-2024 程聚宝 | 浙ICP备2021014372号
人工客服