zcdsj
/
plc_control
5
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs(plan): add existing system implementation proposals

This commit is contained in:
caoqianming 2026-04-14 15:56:06 +08:00
parent 87450af171
commit c472360061
1 changed files with 887 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

887
docs/运转系统实现方案.md Normal file
View File

@ -0,0 +1,887 @@
# 运转系统独立软件实现方案
> 文档日期：2026-04-14
> 适用对象：运转系统独立软件立项、总体设计评审、实施拆解
> 参考来源：`运转系统逻辑说明.doc`、当前 `plc_control` 仓库实现
## 1. 背景与目标
根据《运转系统控制逻辑说明书》，目标系统需要覆盖整条运转链路的自动控制与联锁保护，包括：
- 回转线空车回送系统
- 前端码车道输送系统
- 码车机械臂配合系统
- 摆渡车转运系统
- 1 号干燥窑运转系统
- 1 号焙烧窑运转系统
- 2 号干燥窑运转系统
- 2 号焙烧窑运转系统
- 窑尾下摆渡车及卸砖线系统
- 卸砖机位及卸砖机配合系统
该说明书的核心控制原则不是“简单定时启停”，而是：
- 顺序控制
- 联锁保护
- 检测信号闭环确认
- 异常停机与人工恢复
- 双窑线并行与公共段协同
因此，本次实现不建议继续把需求压缩进当前仓库已有的投煤器/布料机控制模型，而应按一个独立软件来设计和交付。同时，当前仓库中已经成熟的一部分通用能力可以直接复用，避免重复建设。
本方案的目标是：
- 明确新软件的系统边界
- 盘点当前仓库中可复用的通用能力
- 设计适合运转系统的领域模型、控制引擎和前后端架构
- 给出实施路径，兼顾首版交付和后续公共能力沉淀
---
## 2. 结论先行
推荐方案是：
- 将运转系统作为独立软件建设
- 保留自己的数据库模型、控制引擎、前端页面和业务配置
- 复用当前 `plc_control` 仓库中已经验证过的通用基础能力
- 不直接沿用当前仓库以 `unit + run_time_sec + stop_time_sec + acc_time_sec + bl_time_sec` 为核心的控制业务模型
换句话说，处理原则不是“在当前项目里继续叠加一个特殊模块”，而是：
- 当前仓库作为技术参考和通用能力来源
- 新软件作为运转系统业务主线
- 通用能力先迁移复用，后续再视项目数量决定是否抽为共享模块
这是当前阶段风险最低、交付最稳、后续也最容易维护的路径。
---
## 3. 当前仓库能力盘点
### 3.1 已具备且适合复用的通用能力
结合 `README.md`、`API.md`、`src/main.rs` 以及当前代码结构，现仓库已经具备以下可复用能力。
#### 3.1.1 数据源与点位接入层
- OPC UA 数据源管理
- 数据源重连
- 节点浏览与保存
- 点位实时订阅
- 点位批量写入
- 实时值与质量状态缓存
对应模块主要包括：
- `src/connection.rs`
- `src/handler/source.rs`
- `src/handler/point.rs`
- `src/service/source.rs`
- `src/service/point.rs`
这些能力与具体业务无强绑定，适合作为新软件的接入底座。
#### 3.1.2 设备/点位基础建模
当前仓库已经有较成熟的基础对象：
- 数据源 `source`
- 设备 `equipment`
- 点位 `point`
- 标签 `tag`
- 页面 `page`
其中 `equipment` 与 `point` 作为“现场对象抽象”依然有复用价值，尤其适合承载：
- 门机
- 顶车机
- 拉引机
- 摆渡车
- 步进机
- 卸砖机
- 机械臂状态点
- 各工位检测点
#### 3.1.3 实时事件与前后端通讯
当前仓库已经具备：
- WebSocket 实时推送
- SSE 日志流
- 统一事件入口
- 事件落库与查询
对应模块包括：
- `src/event.rs`
- `src/websocket.rs`
- `src/handler/log.rs`
这些能力对运转系统同样成立，可用于：
- 动作执行结果推送
- 工位状态变化推送
- 联锁阻断告警推送
- 顺控步骤变化推送
- 操作日志与异常追踪
#### 3.1.4 基础 Web 与后端服务骨架
当前仓库已经具备：
- Axum 路由骨架
- PostgreSQL 持久化
- SQLx 服务层
- 中间件
- 前端静态页宿主
- 单实例运行与托盘集成
这些都是独立软件首版可直接借鉴或迁移的基础设施。
### 3.2 当前仓库不适合作为运转系统主模型的部分
当前控制模型围绕 `control unit` 展开，核心语义是：
- 定时停止
- 定时运行
- 累计运行触发下一设备
这套模型适用于投煤器/布料机这类节拍式设备联动，但不适用于运转系统说明书中的整线逻辑，原因如下：
- 无法表达“工位占用/空位”驱动的逐段流转
- 无法表达“开门 -> 门开确认 -> 主动作 -> 复位 -> 关门 -> 门关确认”的段内动作链
- 无法表达摆渡车定位、窑口交接、下摆渡车接车等空间位置过程
- 无法表达机械臂安全区互锁
- 无法表达动作完成必须由检测闭环确认的控制要求
- 无法清晰表达故障停留在当前步骤、禁止跳步恢复的原则
因此，当前 `unit` 运行态和引擎逻辑可以借鉴实现方法，但不应直接作为运转系统的业务核心模型。
---
## 4. 新软件的定位与边界
### 4.1 新软件定位
新软件定位为：
- 面向窑车运转系统的自动控制与监控平台
- 以“工位流转 + 执行机构动作 + 联锁条件 + 完成确认 + 异常恢复”为核心
- 支持双窑线并行与公共段共享
- 支持自动、远程手动、就地切换下的系统行为约束
### 4.2 与当前仓库的关系
推荐关系如下：
- 当前仓库不是运转系统的软件主体
- 当前仓库是通用能力来源和技术参考
- 首期开发可复制已有通用模块到新项目中使用
- 后续如果存在多个同类项目，再考虑把共性抽为共享库
### 4.3 本次不建议的做法
不建议：
- 在当前仓库里继续叠加大量运转系统特有表结构和控制逻辑
- 把运转系统说明书中的流程强行映射为现有 `unit` 状态机
- 一开始就为了“平台化”设计过度通用的规则解释器
首版目标应该是：既能落地当前项目需求，又不给后续维护制造过多历史包袱。
---
## 5. 推荐的总体架构
### 5.1 架构分层
建议将新软件分为四层：
#### 第一层：接入层
职责：
- 对接 OPC UA 或其他现场协议
- 订阅实时点位
- 写入控制命令
- 管理连接状态和信号质量
该层优先复用当前仓库的实现思路与模块结构。
#### 第二层：现场对象层
职责：
- 管理设备
- 管理点位
- 管理工位
- 管理运输段
- 管理信号映射
该层负责把现场对象标准化，形成“控制引擎可理解的对象模型”。
#### 第三层：顺控引擎层
职责：
- 执行每一段顺控逻辑
- 处理段内步骤推进
- 校验联锁
- 等待闭环确认
- 处理超时、故障和恢复
- 协调双窑线与公共段
这是新软件的核心，不适合直接沿用当前仓库的 `unit` 引擎，需要重新设计。
#### 第四层：操作与监控层
职责：
- 实时显示工位状态和设备状态
- 展示当前步骤和阻断原因
- 提供手动控制与自动启停入口
- 展示报警、事件、操作记录和日志
### 5.2 核心设计思想
运转系统的控制对象不是“单台设备”，而是“工艺段中的动作序列”。
因此核心对象应该从“设备”提升到“流程段”。
建议将整套系统拆成若干独立但可协同的流程段，例如：
- 回车线入口接车段
- 回车线前移段
- 前端码车位进车段
- 机械臂码坯协同段
- 码坯完成放车段
- 前端摆渡分配段
- 1 号干燥窑进口段
- 1 号干燥窑内前移段
- 1 号干燥窑出口段
- 1 号焙烧窑进口段
- 1 号焙烧窑内前移段
- 1 号焙烧窑出口段
- 2 号线对应各段
- 窑尾摆渡接车段
- 下摆渡车段
- 卸砖线步进段
- 卸砖机位协同段
每个段都遵循统一状态机模板，但参数、设备映射和检测点不同。
---
## 6. 领域模型设计
### 6.1 需要保留的基础对象
建议保留并延续以下基础对象概念：
- `source`：现场数据源
- `equipment`：执行机构或检测对象
- `point`：点位
但需要扩展出新的运转系统领域对象。
### 6.2 新增领域对象建议
#### 6.2.1 工位 `station`
表示产线上的一个位置或交接位，例如：
- 码车位
- 摆渡车前端接车位
- 1 号干燥窑进口位
- 1 号干燥窑某中间工位
- 焙烧窑出口位
- 窑尾摆渡接车位
- 卸砖线入口位
- 卸砖机位
- 回车线入口位
建议字段：
- `id`
- `code`
- `name`
- `line_code`
- `segment_code`
- `station_type`
- `enabled`
- `description`
#### 6.2.2 工位信号映射 `station_signal`
用于将工位和检测信号绑定起来，例如：
- 有车检测
- 空位判定
- 到位确认
- 允许接车
- 完成信号
#### 6.2.3 流程段 `process_segment`
表示一个可独立调度的控制段。
例如：
- `front_feed_to_load_station`
- `robot_palletize`
- `front_release_to_transfer_car`
- `kiln1_dry_infeed`
- `kiln1_dry_step`
- `kiln1_dry_outfeed`
- `tail_transfer_to_unload`
建议字段：
- `id`
- `code`
- `name`
- `segment_type`
- `line_code`
- `priority`
- `enabled`
- `mode`
#### 6.2.4 段步骤 `segment_step`
表示一个流程段内的顺控步骤。
建议字段：
- `id`
- `segment_id`
- `step_no`
- `step_code`
- `step_type`
- `action_kind`
- `timeout_ms`
- `next_step_on_success`
- `next_step_on_failure`
#### 6.2.5 联锁规则 `interlock_rule`
表示动作启动前或运行中的禁止条件、停机条件、允许条件。
规则类型可包括：
- 启动允许
- 启动禁止
- 运行中停机
- 完成判定
- 复位判定
#### 6.2.6 动作模板 `action_template`
用于描述典型动作，减少重复配置，例如：
- 开门
- 关门
- 顶车前进
- 顶车后退
- 拉引启动
- 拉引复位
- 摆渡车定位到某站
- 步进机执行一步
- 发放机械臂允许
#### 6.2.7 段运行态 `segment_runtime`
替代当前仓库的 `unit runtime`，记录：
- 当前状态
- 当前步骤
- 当前阻断原因
- 当前动作开始时间
- 最近一次成功完成时间
- 当前故障锁定状态
- 当前人工确认需求
### 6.3 参数化双窑线
说明书明确指出 1 号窑线与 2 号窑线控制原则一致，仅设备编号和工位编号不同。
因此建议设计成：
- 一套流程段模板
- 两套配置实例
不要写两套硬编码逻辑。参数化维度包括：
- 设备编号
- 站位编号
- 门机/顶车机/拉引机映射
- 进出口工位
- 信号点位绑定
---
## 7. 顺控引擎设计
### 7.1 总体原则
顺控引擎必须遵循说明书中的原则：
- 上一步未完成，不能进入下一步
- 动作完成不能只依赖时间，必须结合检测反馈
- 完全联锁、故障联锁、门位联锁、机械臂联锁优先于普通顺控
- 故障后保持当前步骤，不允许强行跳步恢复
### 7.2 段级状态机
建议每个 `process_segment` 使用统一状态机框架：
- `Idle`
- `Checking`
- `Executing`
- `Confirming`
- `Resetting`
- `Completed`
- `Blocked`
- `Faulted`
- `ManualInterventionRequired`
这与说明书建议的步骤结构一致，可映射为：
- Step 0：等待
- Step 1：条件检查
- Step 2：执行动作
- Step 3：到位确认
- Step 4：复位确认
- Step 5：本段完成
- Step 6：故障处理
### 7.3 统一段内执行模型
每个段的执行循环建议统一为：
1. 读取当前段配置
2. 读取当前步骤定义
3. 拉取关联设备和工位信号实时值
4. 校验启动允许与禁止条件
5. 发出动作命令
6. 等待执行反馈
7. 校验完成信号
8. 校验复位信号
9. 写入本段完成或转入异常状态
### 7.4 典型动作链模板
针对窑门相关段，建议内建标准动作模板：
1. 开门
2. 门开到位确认
3. 主动作执行
4. 主动作完成确认
5. 执行机构复位
6. 复位确认
7. 关门
8. 门关到位确认
9. 段完成
这样可以直接匹配说明书中的：
- 干燥窑进口段
- 干燥窑出口段
- 焙烧窑进口段
- 焙烧窑出口段
### 7.5 公共段与并行段调度
整套系统存在以下并发特征：
- 双窑线并行
- 前端码车系统是公共资源
- 窑尾摆渡和卸砖线是公共资源
- 回车线是公共资源
因此调度层必须支持：
- 段独立运行
- 公共资源互斥
- 基于优先级或空位状态的放行决策
- 上下游交接信号驱动
建议在引擎中增加“资源占用”概念，用于控制：
- 摆渡车一次只能服务一个目标位
- 卸砖机位忙碌时禁止上游送车
- 机械臂占用作业区时禁止码车道送车
---
## 8. 联锁与异常处理设计
### 8.1 联锁优先级
联锁优先级建议按以下顺序处理：
1. 安全联锁
2. 完全联锁
3. 故障联锁
4. 门位联锁
5. 机械臂联锁
6. 工艺允许条件
7. 普通顺控条件
高优先级联锁一旦不满足，低优先级不再继续判断。
### 8.2 通用允许条件
任何动作启动前至少检查：
- 目标工位空位
- 本工位有车或动作前提成立
- 执行机构原位
- 相关门位正确
- 设备无故障
- 安全联锁正常
- 信号质量正常
- 当前资源未被占用
### 8.3 通用禁止条件
出现以下任一情况，应禁止动作启动：
- 目标工位被占用
- 执行机构不在原位
- 门未开到位或门未关到位
- 摆渡车未定位
- 机械臂未退出安全区
- 卸砖位忙碌
- 信号冲突
- 就地模式或远程未就绪
### 8.4 通用停机条件
运行中出现以下任一情况，应立刻停止并报警：
- 设备故障
- 动作超时
- 门位异常
- 定位信号丢失
- 安全联锁动作
- 检测信号矛盾
### 8.5 故障恢复原则
故障处理必须遵循：
- 故障优先停止当前相关动作
- 停机后保留当前步骤
- 不允许自动跳到下一步骤
- 故障解除后仍需满足复位条件
- 对关键信号冲突场景，必须人工确认后恢复
建议引擎中明确区分：
- `fault_active`
- `fault_latched`
- `manual_ack_required`
- `blocked_reason`
---
## 9. 前后端功能设计
### 9.1 后端接口建议
除了基础 `source / equipment / point` 管理接口，新软件建议新增以下业务接口。
#### 9.1.1 工位与段配置接口
- `GET /api/station`
- `POST /api/station`
- `PUT /api/station/{id}`
- `DELETE /api/station/{id}`
- `GET /api/process-segment`
- `POST /api/process-segment`
- `PUT /api/process-segment/{id}`
- `GET /api/process-segment/{id}/detail`
#### 9.1.2 运行控制接口
- `POST /api/control/segment/{id}/start-auto`
- `POST /api/control/segment/{id}/stop-auto`
- `POST /api/control/segment/{id}/reset`
- `POST /api/control/segment/{id}/ack-fault`
- `POST /api/control/equipment/{id}/manual-action`
#### 9.1.3 运行态查询接口
- `GET /api/runtime/overview`
- `GET /api/runtime/segment/{id}`
- `GET /api/runtime/station/{id}`
- `GET /api/alarm`
- `GET /api/event`
### 9.2 WebSocket 推送建议
建议至少推送以下消息：
- 工位状态变化
- 段运行态变化
- 当前步骤变化
- 联锁阻断变化
- 报警创建与恢复
- 设备动作结果
### 9.3 前端页面建议
#### 9.3.1 总览页面
展示：
- 整体流程图
- 双窑线状态
- 公共段状态
- 关键堵点
- 当前报警数
#### 9.3.2 运转监控页面
展示：
- 各工位有车/空位状态
- 门位状态
- 顶车机/拉引机/摆渡车/步进机状态
- 当前正在执行的步骤
- 当前阻断原因
#### 9.3.3 自动控制页面
展示：
- 各流程段自动状态
- 步骤进度
- 手动启停
- 故障确认
- 复位操作
#### 9.3.4 配置页面
展示：
- 设备管理
- 点位管理
- 工位管理
- 段配置
- 联锁规则配置
- 日志与事件查看
---
## 10. 与当前仓库的复用策略
### 10.1 推荐策略
当前阶段推荐“先迁移复用，再视情况抽公共库”。
原因：
- 首版交付更快
- 现仓库已有能力已经过实际实现验证
- 现在立即抽共享库，容易因为运转系统领域模型尚未稳定而反复修改
### 10.2 复用方式
建议按三类处理。
#### 第一类：直接迁移复用
可直接迁移并少量改造：
- OPC UA 接入与重连
- 点位订阅与实时缓存
- 批量写点
- WebSocket 管理
- 事件总线
- 日志流
- 通用工具模块
#### 第二类：保留设计思路，重新实现
不建议直接复制，但可以借鉴结构：
- 控制引擎调度模型
- 运行态缓存
- 控制前置校验
- 事件落库方式
#### 第三类：不继承旧业务模型
建议不继承：
- 当前 `unit` 业务语义
- `run_time_sec / stop_time_sec / acc_time_sec / bl_time_sec` 这一套参数
- 当前围绕投煤器/布料机定义的设备类型约定
### 10.3 后续公共化路径
如果后续存在多个类似项目，可分阶段抽象：
第一阶段：
- 新软件独立交付
- 复用代码以复制迁移为主
第二阶段：
- 抽出 `plc_common` 之类的公共 Rust crate
- 抽出前端通用实时组件
- 统一数据源接入、事件总线、实时推送和写点命令封装
第三阶段：
- 再考虑更高层的流程引擎模板是否值得平台化
---
## 11. 实施阶段建议
### 阶段一：独立项目初始化
目标：
- 建立新仓库
- 迁移通用接入层和实时通讯层
- 跑通基础框架
工作内容：
- 初始化新项目结构
- 迁移 `source / equipment / point` 基础能力
- 跑通 OPC UA 数据源接入
- 建立事件、WebSocket、日志链路
### 阶段二：领域模型与配置能力
目标：
- 建立工位、流程段、联锁规则等核心模型
工作内容：
- 设计数据库表
- 建立后端模型与服务层
- 建立配置接口
- 搭建配置页面
### 阶段三：顺控引擎首版
目标：
- 跑通一条主流程
建议先实现：
- 前端码车位进车
- 机械臂码坯协同
- 码坯完成放车
- 摆渡车前端分配
- 2 号干燥窑进口段
先打通单条链路，验证段模型和联锁模型是否足够。
### 阶段四：双窑线与公共段扩展
目标：
- 完成双窑线、窑尾和回车线全流程
工作内容：
- 参数化复制 1 号线和 2 号线
- 接入窑尾摆渡、卸砖线、回车线
- 完善资源互斥与阻塞处理
### 阶段五：监控、报警与恢复完善
目标：
- 提升可运维性
工作内容：
- 完善报警分类
- 增加报警确认和恢复记录
- 增加动作追踪与步骤历史
- 增加现场调试辅助页面
---
## 12. 风险与注意事项
### 12.1 最大风险不是接入，而是流程建模
当前仓库已经证明接入和基础实时能力不是主要风险。真正的风险在于：
- 工位划分是否清晰
- 流程段切分是否合理
- 联锁规则是否完整
- 公共资源互斥是否严谨
因此实现前必须先完成工艺段拆分和信号清单整理。
### 12.2 不要过早追求全配置化
首版不要把所有逻辑都做成自由拼装规则引擎。更合理的做法是：
- 先定义少量固定动作模板
- 先定义少量固定规则类型
- 用“模板 + 参数”的方式覆盖当前项目
这样既能交付，也能控制复杂度。
### 12.3 需要形成明确的 I/O 对照表
说明书描述了大量逻辑关系，但软件落地前必须补足：
- 每个工位对应哪些检测点
- 每个执行机构对应哪些命令点和反馈点
- 每个完成条件由哪些信号组成
- 哪些联锁是硬联锁，哪些是软联锁
没有这份映射表，软件方案再完整也无法落地。
---
## 13. 最终建议
综合当前需求和现仓库现状，最终建议如下：
- 运转系统按独立软件建设
- 当前 `plc_control` 仓库只复用其通用基础能力
- 业务核心模型改为“工位 + 流程段 + 步骤 + 联锁 + 完成确认”
- 双窑线按模板参数化实现
- 首版采用“先迁移复用、后沉淀公共模块”的策略
这样做可以同时满足三件事：
- 不破坏当前仓库已经成型的业务语义
- 能完整承接运转系统说明书中的实际工艺需求
- 为后续形成公共能力保留演进空间
---
## 14. 后续建议产出物
在本方案基础上，建议下一步继续形成以下文档：
- 运转系统软件功能清单
- 工位与执行机构 I/O 对照表
- 流程段拆分表
- 联锁规则明细表
- 数据库表设计文档
- 顺控引擎详细设计
- 前端页面原型
如果继续推进实施，下一份最关键的文档应是：
- 《运转系统流程段与 I/O 建模设计》
这份文档将直接决定后端模型和顺控引擎如何落地。