4. 闭环工程总体架构设计

物料叫料与拉动配送要真正形成闭环，不能只靠“工人按按钮、叉车去送货”这一条动作链。它需要把现场需求、任务编排、运力执行、消耗确认和异常处理串成一个可观测、可追溯、可纠偏的系统。本节给出五层总体架构，并明确每层的职责、输入输出与系统边界，为后续各章的接口设计、参数配置和异常策略提供统一骨架。

五层架构的职责划分

五层架构自下而上分别是：叫料触发层、任务调度层、配送执行层、消耗反馈层、异常闭环层。它们不是简单的串行关系，而是“触发—调度—执行—反馈”构成主闭环，异常闭环层横向监控并介入其余四层。

• 叫料触发层：负责产生“需要补料”的信号。触发源包括工位按钮/Andon、电子看板、线边库存低于安全水位、MES 工单齐套检查、AGV 呼叫盒等。输出是一条标准叫料请求，字段至少包含：物料编码、需求工位、需求数量、需求时间窗、优先级、触发来源。
• 任务调度层：把叫料请求转换为可执行的配送任务。核心动作是合并同方向需求、按优先级排序、分配运力（AGV/牵引车/人工）、计算取料点与卸料点路径、生成任务号并下发。它决定“谁在什么时候把什么送到哪里”。
• 配送执行层：由 AGV、牵引车、配送员或输送线执行任务。执行层需要上报任务状态：已接单、取料完成、在途、到达、卸料完成、返程。状态是闭环能否被观测的关键。
• 消耗反馈层：确认物料是否真正被消耗。数据来源包括扫码消耗、工位确认、线边库存扣减、MES 报工倒冲。反馈结果用于修正库存、触发下一次叫料、评估配送及时率。
• 异常闭环层：监控缺料、超时、错料、运力故障、任务失败等异常，按规则升级、重派、人工介入，并记录根因与处理结果，形成可复盘的数据。

系统边界定义：谁负责什么

架构清晰的前提是边界清晰。很多项目失败并非算法不好，而是把“谁该负责”搞混了。建议按以下边界划分：

边界定义要落到接口字段上。例如叫料触发层向任务调度层传递的请求，至少应包含 request_id、material_code、from_location、to_station、qty、need_time、priority、source 八个字段。缺少 need_time，调度层就无法做时间窗排序；缺少 source，异常复盘时就无法判断是按钮误触还是库存真实不足。

主闭环与异常闭环的协同

主闭环是“叫料触发 → 任务调度 → 配送执行 → 消耗反馈 → 再叫料”。异常闭环层不直接参与正常配送，而是监听每一层的状态与超时。典型规则示例：

• 叫料请求超过 5 分钟未被调度接单，标记为“调度超时”，升级到调度主管。
• 配送任务超过计划到达时间 10 分钟仍未“到达”，标记为“配送超时”，触发重派或人工补送。
• 消耗反馈数量与配送数量差异超过 5%，标记为“数量异常”，要求工位复核。
• 同一物料连续 3 次触发叫料但消耗反馈为 0，标记为“虚假叫料”，检查按钮或水位设置。

落地时的关键设计决策

在具体项目中，五层架构需要回答几个关键问题。第一，叫料触发是“人触发”还是“系统自动触发”？建议以系统自动触发为主、人工按钮为辅，避免工人凭感觉叫料导致库存波动。第二，任务调度是集中式还是分布式？中小场景可用集中式调度器，多车间可考虑按区域分片。第三，消耗反馈以扫码为准还是以报工倒冲为准？两者应互为校验，扫码用于实时扣减，报工用于财务级对账。第四，异常闭环是独立系统还是嵌入现有 Andon？若已有 Andon，建议复用其升级通道，避免多套报警并行。

架构设计完成后，应输出一份“层—接口—字段—责任方”对照表，作为后续开发、测试和验收的依据。只有边界清楚、字段明确、异常有归属，叫料与拉动配送才不是一条脆弱的动作链，而是一个可持续运行的闭环工程。