20 KiB

Raw Permalink Blame History

运转系统独立软件实现方案

文档日期：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 统一段内执行模型

每个段的执行循环建议统一为：

读取当前段配置
读取当前步骤定义
拉取关联设备和工位信号实时值
校验启动允许与禁止条件
发出动作命令
等待执行反馈
校验完成信号
校验复位信号
写入本段完成或转入异常状态

7.4 典型动作链模板

针对窑门相关段，建议内建标准动作模板：

开门
门开到位确认
主动作执行
主动作完成确认
执行机构复位
复位确认
关门
门关到位确认
段完成

这样可以直接匹配说明书中的：

干燥窑进口段
干燥窑出口段
焙烧窑进口段
焙烧窑出口段

7.5 公共段与并行段调度

整套系统存在以下并发特征：

双窑线并行
前端码车系统是公共资源
窑尾摆渡和卸砖线是公共资源
回车线是公共资源

因此调度层必须支持：

段独立运行
公共资源互斥
基于优先级或空位状态的放行决策
上下游交接信号驱动

建议在引擎中增加“资源占用”概念，用于控制：

摆渡车一次只能服务一个目标位
卸砖机位忙碌时禁止上游送车
机械臂占用作业区时禁止码车道送车

8. 联锁与异常处理设计

8.1 联锁优先级

联锁优先级建议按以下顺序处理：

安全联锁
完全联锁
故障联锁
门位联锁
机械臂联锁
工艺允许条件
普通顺控条件

高优先级联锁一旦不满足，低优先级不再继续判断。

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 建模设计》

这份文档将直接决定后端模型和顺控引擎如何落地。

20 KiB Raw Permalink Blame History Unescape Escape

运转系统独立软件实现方案

1. 背景与目标

2. 结论先行

3. 当前仓库能力盘点

3.1 已具备且适合复用的通用能力

3.1.1 数据源与点位接入层

3.1.2 设备/点位基础建模

3.1.3 实时事件与前后端通讯

3.1.4 基础 Web 与后端服务骨架

3.2 当前仓库不适合作为运转系统主模型的部分

4. 新软件的定位与边界

4.1 新软件定位

4.2 与当前仓库的关系

4.3 本次不建议的做法

5. 推荐的总体架构

5.1 架构分层

第一层：接入层

第二层：现场对象层

第三层：顺控引擎层

第四层：操作与监控层

5.2 核心设计思想

6. 领域模型设计

6.1 需要保留的基础对象

6.2 新增领域对象建议

6.2.1 工位 station

6.2.2 工位信号映射 station_signal

6.2.3 流程段 process_segment

6.2.4 段步骤 segment_step

6.2.5 联锁规则 interlock_rule

6.2.6 动作模板 action_template

6.2.7 段运行态 segment_runtime

6.3 参数化双窑线

7. 顺控引擎设计

7.1 总体原则

7.2 段级状态机

7.3 统一段内执行模型

7.4 典型动作链模板

7.5 公共段与并行段调度

8. 联锁与异常处理设计

8.1 联锁优先级

8.2 通用允许条件

8.3 通用禁止条件

8.4 通用停机条件

8.5 故障恢复原则

9. 前后端功能设计

9.1 后端接口建议

9.1.1 工位与段配置接口

9.1.2 运行控制接口

9.1.3 运行态查询接口

9.2 WebSocket 推送建议

9.3 前端页面建议

9.3.1 总览页面

9.3.2 运转监控页面

9.3.3 自动控制页面

9.3.4 配置页面

10. 与当前仓库的复用策略

10.1 推荐策略

10.2 复用方式

第一类：直接迁移复用

第二类：保留设计思路，重新实现

第三类：不继承旧业务模型

10.3 后续公共化路径

11. 实施阶段建议

阶段一：独立项目初始化

阶段二：领域模型与配置能力

阶段三：顺控引擎首版

阶段四：双窑线与公共段扩展

阶段五：监控、报警与恢复完善

12. 风险与注意事项

12.1 最大风险不是接入，而是流程建模

12.2 不要过早追求全配置化

12.3 需要形成明确的 I/O 对照表

13. 最终建议

14. 后续建议产出物

20 KiB

Raw Permalink Blame History

6.2.1 工位 `station`

6.2.2 工位信号映射 `station_signal`

6.2.3 流程段 `process_segment`

6.2.4 段步骤 `segment_step`

6.2.5 联锁规则 `interlock_rule`

6.2.6 动作模板 `action_template`

6.2.7 段运行态 `segment_runtime`