diff --git a/docs/运转系统实现方案.md b/docs/运转系统实现方案.md
new file mode 100644
index 0000000..acda2c2
--- /dev/null
+++ b/docs/运转系统实现方案.md
@@ -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 建模设计》
+
+这份文档将直接决定后端模型和顺控引擎如何落地。