当前AutomaticStationPipelineHandlers属于“流水线调度器 业务回调”的设计。流水线负责调度具体业务通过委托注入。一、主要优点职责分离AutomaticStationPipeline不直接依赖 PLC、主控板、扫描器和数据文件只负责队列管理。Worker 调度。阶段流转。产品状态维护。取消和异常传播。具体业务由StationControlViewModel通过回调提供。复用现有业务回调内部可以继续调用LoadProductTransportProductPreTestTestUnLoadProduct不需要在流水线中重新实现设备协议减少重复代码。方便测试可以替换成模拟回调例如LoadAsync - 模拟扫码成功 TransferAsync - 模拟搬运成功 TestAsync - 模拟测试结果 PurgeAsync - 模拟吹扫完成 ManualUnloadAsync - 模拟人工取料这样可以在没有真实设备的情况下测试流水线。支持不同上料来源目前已经支持本机扫码上料。自动化SOTReq直接放料。EAP Host 放行后继续搬运。不同入口可以调用不同的入队方法但后续搬运、测试、吹扫和下料仍然复用同一套 Worker。天然支持阶段并行每个阶段有独立队列和 Worker第 1 颗测试 第 2 颗搬运 第 3 颗上料只要物理联锁允许就可以提高设备吞吐量。产品数据不容易串料AutomaticPipelineProduct保存每颗产品独立的SN。RFID。当前阶段。错误信息。测试取消状态。EAP 放行状态。相比直接使用 ViewModel 的ID1、ID2、ID3更适合连续多颗器件运行。扩展阶段比较方便可以增加新的委托例如预热。外观检测。视觉检测。二次测试。数据校验。特殊退料。核心调度器不一定需要大幅修改。二、当前设计的不足1.Handlers仍然强依赖 ViewModel当前回调主要由StationControlViewModel提供例如RunPipelineLoadAsync RunPipelineTransferAsync RunPipelineTestAsync RunPipelinePurgeAsync RunPipelineManualUnloadAsync这导致 ViewModel 同时负责页面绑定。按钮状态。批次管理。EAP。自动化。PLC 协调。测试流程。数据保存。虽然通过 partial 文件拆分了代码但职责仍然集中在一个类中。长期来看StationControlViewModel仍然会越来越复杂。2. 回调缺乏统一的业务上下文不同回调的参数形式不完全一致LoadAsync(Product, Token) TransferAsync(Product, Token) TestAsync(Product, Token) ManualUnloadAsync(Product, Passed, Token)后期增加操作员。批次号。工站配置。EAP 请求号。设备状态快照。追溯编号。时委托参数会不断增加容易出现参数膨胀。更合理的是统一使用一个PipelineExecutionContext所有阶段从上下文获取数据。3. 阶段转换隐含在 Worker 内部当前是LoadWorker 完成后写 TransferQueue TransferWorker 完成后写 TestQueue TestWorker 完成后写 PurgeQueue阶段关系分散在多个方法中。如果后期出现预测试失败后直接退料。正式测试失败后跳过某一步。复测流程。不同产品走不同工艺。代码会增加大量if/else流程关系不够直观。4. 回调异常处理不够统一目前每个 Worker 都有自己的try/catch不同阶段对异常的处理方式略有区别有的进入失败回调。有的继续吹扫。有的直接取消。有的生成 FAIL 数据。有的只记录日志。工业设备需要明确区分可恢复异常 不可恢复异常 安全异常 通讯异常 流程失败 操作员取消 设备急停否则后期容易出现“异常被当成测试 FAIL”或“测试失败没有退料”的问题。5. 取消语义比较复杂当前至少有三类取消整条流水线取消。单个待扫码请求取消。单颗产品测试取消。这比简单的CancellationToken更灵活但也带来维护成本。特别是队列中尚未消费的产品如何清理。当前阶段正在等待 PLC 时如何退出。取消后是否必须退料。取消后是否必须发送 EOT。取消后是否必须执行吹扫。都必须依赖阶段规则判断。6.StopAsync的队列回收还不够完整关闭 Channel 并取消 Worker 后已经在队列中但尚未消费的产品可能没有经过统一的Finish。可能产生产品状态没有更新为Cancelled。Completed回调没有触发。产品内部取消源没有释放。外部等待任务没有得到结果。这在复位、结批和程序退出时尤其需要重视。7.SOTRsp的确认级别存在不一致当前自动化 SOT 流程实际主要确认PLC 扫码握手成功 产品进入搬运队列而不是严格确认搬运命令已成功下发如果协议要求SOTRspOK表示设备已经接受并开始搬运就需要定义清晰的确认点入队成功 PLC 命令写入成功 机械动作开始 搬运完成不能只依赖注释描述必须明确协议语义。8. 不能单纯依赖 Channel 保证设备安全Channel 只能保证软件队列顺序不能保证测试位真的空闲。吹扫位真的空闲。下料位真的空闲。PLC 指令已经执行。机械动作已经完成。设备没有急停或安全门触发。这些仍然必须由设备状态、PLC 信号和硬件状态机确认。三、工业级设备常用的优秀方案方案一工站级状态机为每个工站建立明确状态Offline Initializing ReadyForBatch WaitingForLoad Loading WaitingForTransfer Transferring Testing Purging WaitingForUnload Fault Resetting Stopping所有外部命令都先经过状态机判断当前状态 输入事件 - 下一状态 动作例如Testing Stop - Stopping WaitingForUnload Reset - Resetting Fault Reset - Resetting BatchOpen StartLot - Reject优点是流程边界清晰避免多个布尔字段组合出矛盾状态。方案二工站 Actor/命令邮箱模型每个工站只有一个业务 Actor所有请求进入命令队列StartLot SOTReady SOT Stop Reset EndLot Unload PLCStateChangedActor 按顺序处理命令避免多个线程同时修改工站状态。设备耗时操作仍然使用异步等待但状态更新由工站 Actor 统一完成。适合解决EAP 请求和人工按钮同时到达。Reset 和 Stop 并发。SOTReq 重复发送。开批和结批同时触发。方案三调度器与业务服务彻底分离建议将当前结构拆成AutomaticStationPipeline 只负责队列和阶段调度 StationWorkflowService 负责工艺流程 PlcInterlockService 负责 PLC 条件判断 ElectricalTestService 负责预测试和正式测试 MaterialHandlingService 负责搬运、吹扫、下料 ResultPersistenceService 负责 CSV、数据库、备份 StationStateMachine 负责工站状态StationControlViewModel只负责界面绑定和发送命令不直接编排所有硬件流程。方案四使用明确的阶段结果类型每个阶段统一返回Success Failed Cancelled Timeout SafetyStopped CommunicationError NeedManualIntervention同时附带错误码 错误描述 是否需要退料 是否允许重试 是否需要复位 是否需要报警这样比单纯的Success ErrorMessage更适合工业场景。方案五设备资源锁和动作互斥应为关键资源建立明确的资源管理测试位锁 下料位锁 主控板通讯锁 PLC 写入锁 扫码器锁 RFID 锁 数据文件写入锁注意资源锁的粒度不能过大。例如测试位必须独占。不同工站的 PLC 可以并行。同一工站 PLC 写入必须按协议串行。数据库写入可以进入独立队列。方案六PLC 信号事件化当前主要通过轮询等待while (...) { ReadSignal(); Task.Delay(...); }工业现场更合理的方式是PLC采集服务 ↓ 信号变化事件 ↓ 工站状态机 ↓ 执行对应动作但不建议完全取消周期采集。更稳妥的方式是周期采集作为底层可靠来源 信号变化事件作为业务触发 超时轮询作为兜底保护这样既减少重复判断也能防止信号丢失。方案七命令幂等和请求编号所有外部命令应带有请求序号。工站号。批次号。DUTSN。时间戳。服务端记录最近处理过的请求相同请求重复到达 - 返回上一次结果 不同请求 - 执行新业务尤其适用于SOTReadyReqSOTReqResetEQPUnloadReqEndLotReq方案八动作日志和状态快照每个阶段都记录请求进入时间 阶段开始时间 PLC期望值 PLC实际值 动作结果 超时时间 取消原因 异常堆栈 阶段结束时间同时保留工站状态快照当前状态 当前产品 批次 PLC信号 当前命令 当前故障 当前流水线阶段现场出现问题时可以快速判断是没有收到命令。命令没有入队。队列等待。PLC 未响应。机械未动作。测试失败。下料未完成。四、最适合当前项目的推荐架构当前项目不建议立即完全推翻AutomaticStationPipelineHandlers。比较稳妥的演进顺序是第一步保留现有 Pipeline 第二步统一 PipelineExecutionContext 第三步统一 PipelineStageResult 第四步增加 StationStateMachine 第五步将 ViewModel 中的回调迁移到 StationWorkflowService 第六步增加工站 Actor/命令队列 第七步PLC 轮询与信号变化事件并存 第八步增加持久化操作日志和异常恢复机制最终结构可以是通信层 Automation / SECS-GEM 命令层 StationCommandRouter 工站控制层 StationActor StationStateMachine 流程层 StationWorkflowService AutomaticStationPipeline 设备服务层 PlcInterlockService MaterialHandlingService ElectricalTestService 数据层 CsvWriter DatabaseWriter BackupWriter 界面层 StationControlViewModel结论当前“业务回调集合”适合作为第一阶段的解耦方案优点是改造成本低、复用现有业务方便、支持多阶段并行。它还不算完整的工业级架构主要不足是工站状态、命令并发、异常分类、取消收尾和资源互斥仍然分散在 ViewModel 与 Worker 中。最值得优先优化的是统一阶段结果和异常分类。完善流水线停止时的队列清理。增加工站状态机。将业务回调逐步迁移到独立的StationWorkflowService。用工站命令队列统一处理人工、自动化和 EAP 请求。