888 lines
20 KiB
Markdown
888 lines
20 KiB
Markdown
# 运转系统独立软件实现方案
|
||
|
||
> 文档日期：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 建模设计》
|
||
|
||
这份文档将直接决定后端模型和顺控引擎如何落地。
|