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