生产计划排程实战：从建模到Python排程引擎的避坑指南

简介：生产计划排程1.1.rar 是一套基于 VB6.0 开发的生产计划与排程桌面应用源码，面向希望学习数据库操作与工业排程逻辑的开发者及制造业信息化人员。系统围绕产能分析、计划导入与生产计划控制三大模块展开，通过 Access 等数据库存储产能信息、物料清单与历史记录，并借助 SQL 脚本完成建库与初始化，适合作为 VB6.0 与数据库集成的实践案例。压缩包共 68 个文件，约 2.37MB，包含 8 个 frm 窗体、8 个 xls 数据表、2 个 sql 脚本、2 个 bas 模块及 27 个 ico 图标等，覆盖界面、数据与脚本资源。目前已有 535 人学习下载。读者可从中获取完整的窗体与模块结构、数据库建表脚本、产能分析表格及排程控制逻辑，用于理解生产计划系统的数据流与调度思路，也可作为课程设计或二次开发的参考素材。

1. 生产计划排程1.1：从压缩包名到可落地的排程引擎

车间里最常听到的一句话是“计划赶不上变化”，而生产计划排程要解决的，恰恰是把这句话从抱怨变成可计算的约束。看到“生产计划排程1.1.rar”这个标题，我第一反应不是去找压缩包，而是判断它背后大概率是一套 APS（Advanced Planning and Scheduling，高级计划与排程）的早期版本：输入订单、工艺路线、设备产能，输出工序级的开工完工时间。它适合两类人——被 Excel 手工排产折磨的制造从业者，以及想用代码把排程逻辑跑通的技术人。这一章先把概念立住：排程不是把订单按交期排序，而是在有限产能、换型时间、物料齐套三重约束下求一个可行解。下面从建模到跑通，一步步拆。

2. 排程问题怎么建模：把车间翻译成数据结构

排程之所以难，是因为它同时是组合优化问题和工程落地问题。建模错了，后面算法再花哨也是白搭。我一般先把车间抽象成三张表：订单表、工艺路线表、资源表，再补一张换型矩阵。这四张表决定了排程引擎能算多细。

2.1 三张核心表与字段设计

订单表记录需求，工艺路线表记录“谁在什么设备上做多久”，资源表记录设备可用时间。字段设计直接决定排程粒度，粒度太粗算不准，太细算不动。

标准工时单位统一用分钟，日历用“每天可用班次”表示，避免后面时间换算翻车。优先级不要用 1/2/3 这种模糊值，直接用权重数值，方便目标函数加权。

2.2 目标函数与约束的取舍

排程目标常见有三种：最小化最大完工时间（makespan）、最小化总延期、最大化设备利用率。三者往往互相冲突，1.1 版本通常只选一个主目标加一个软约束。我一般把总延期作为主目标，设备利用率作为软约束，因为交期是硬指标。

约束里最容易被忽略的是物料齐套。很多排程结果看着漂亮，一执行就卡在缺料上。建模时给每道工序加一个 earliest_start，由物料到货时间决定，能挡掉大量不可行解。

# 简化的排程数据模型，用 dataclass 表达 from dataclasses import dataclass, field from datetime import datetime, timedelta @dataclass class Operation: order_id: str op_seq: int resource_id: str std_time: int # 标准工时，分钟 setup_time: int = 0 # 换型时间，分钟 earliest_start: datetime = None # 物料齐套时间 @dataclass class Resource: resource_id: str daily_minutes: int = 480 # 每天可用分钟，单班 8 小时 calendar: list = field(default_factory=list) # 可用日期列表 def build_operations(orders, routings): ops = [] for o in orders: for r in routings.get(o["product_id"], []): ops.append(Operation( order_id=o["order_id"], op_seq=r["op_seq"], resource_id=r["resource_id"], std_time=r["std_time"] * o["qty"], # 总工时 = 单件工时 × 数量 setup_time=r.get("setup_time", 0), earliest_start=o.get("material_ready") )) return ops

这段代码把订单和工艺路线展开成工序列表，关键点是std_time * qty，很多新手直接拿单件工时排程，结果数量一多就完全失真。earliest_start留空表示无物料约束，实际项目里建议必填。参数上，daily_minutes要按实际班次改，两班制就是 960，三班制 1440，别照抄 480。

2.3 离散时间与连续时间的选型

排程有两种时间表示：离散时间槽（把时间切成固定长度格子）和连续时间（事件驱动）。离散时间实现简单，适合工序时长固定的场景；连续时间更贴近实际，但实现复杂。1.1 这种早期版本，我建议先用离散时间跑通，时间槽取 10 分钟或 30 分钟。

选 30 分钟槽的话，一道 45 分钟的工序会占两个槽，产生 15 分钟误差。误差可接受就用，不可接受就缩到 10 分钟，但计算量会涨。这是典型的精度和性能权衡，没有标准答案，看你的交期容忍度。

3. 用 Python 跑通最小排程引擎

建模讲完，落到能跑的代码。这一章用一个贪心加局部调整的引擎，不追求最优，追求可行且快。生产现场很多时候要的是“十分钟内给个能执行的计划”，而不是“跑一晚上给个理论最优”。

3.1 环境准备与依赖

依赖尽量少，pandas读数据，datetime处理时间，heapq做优先队列。不引入重型求解器，是为了让这套逻辑能塞进任何现有系统。

pip install pandas openpyxl

数据从 Excel 读，字段名和上一章的表对齐。如果现场数据在 MES 或 ERP 里，导出 CSV 即可，不用改代码逻辑。

3.2 贪心排程主循环

核心思路：按工序优先级排序，每道工序找最早可用的设备时间窗，插入。设备时间用有序列表维护已占用区间，插入时找第一个能放下的空档。

import heapq from datetime import datetime, timedelta def schedule(operations, resources, slot_minutes=30): # 设备已占用区间：{resource_id: [(start, end), ...]} occupied = {r: [] for r in resources} # 按 earliest_start 和 op_seq 排序，物料没到的排后面 operations.sort(key=lambda x: (x.earliest_start or datetime.min, x.op_seq)) result = [] for op in operations: res = resources[op.resource_id] duration = op.std_time + op.setup_time # 从最早开始时间起找空档 cursor = op.earliest_start or datetime.now().replace(hour=8, minute=0, second=0, microsecond=0) placed = False while not placed: # 跳过非工作日，简化处理：只按天推进 if cursor.weekday() >= 5: # 周六日跳过 cursor += timedelta(days=1) cursor = cursor.replace(hour=8, minute=0) continue # 检查当前 cursor 起 duration 分钟内是否与已占用冲突 end = cursor + timedelta(minutes=duration) conflict = False for (s, e) in occupied[op.resource_id]: if not (end <= s or cursor >= e): conflict = True cursor = e # 跳到冲突区间之后 break if not conflict: occupied[op.resource_id].append((cursor, end)) occupied[op.resource_id].sort() result.append({ "order_id": op.order_id, "op_seq": op.op_seq, "resource_id": op.resource_id, "start": cursor, "end": end }) placed = True return result

逻辑说明：occupied维护每台设备的占用区间，插入时线性扫描找空档。cursor遇到冲突就跳到冲突区间结束，这是最朴素的“首次适应”。参数slot_minutes在这版没直接用，因为连续时间插入不需要对齐槽，但保留它方便后面改成离散模式。weekday() >= 5跳过周末是硬编码，实际要读设备日历。

3.3 结果校验与甘特图输出

排完必须校验，否则计划看着对、执行全乱。校验三件事：工序顺序是否满足工艺路线、设备是否重叠、交期是否满足。

def validate(result, routings): # 1. 工序顺序校验 by_order = {} for r in result: by_order.setdefault(r["order_id"], []).append(r) for oid, ops in by_order.items(): ops.sort(key=lambda x: x["op_seq"]) for i in range(1, len(ops)): if ops[i]["start"] < ops[i-1]["end"]: print(f"顺序冲突: {oid} 工序 {ops[i]['op_seq']}") # 2. 设备重叠校验 by_res = {} for r in result: by_res.setdefault(r["resource_id"], []).append(r) for rid, ops in by_res.items(): ops.sort(key=lambda x: x["start"]) for i in range(1, len(ops)): if ops[i]["start"] < ops[i-1]["end"]: print(f"设备冲突: {rid} 在 {ops[i]['start']}") # 3. 交期校验 for oid, ops in by_order.items(): last_end = max(o["end"] for o in ops) print(f"订单 {oid} 完工: {last_end}")

校验函数不返回布尔值，直接打印问题，因为现场排查时看日志比看返回值快。甘特图可以用matplotlib画，横轴时间、纵轴设备、色块表示工序，这里不展开，重点是先把数据算对。

4. 排程引擎避坑：五个血泪教训

排程代码跑通和排程结果能用，中间隔着一条河。下面五条是我踩过的坑，每条按现象、原因、解决写。

4.1 换型时间被忽略导致计划不可执行

现象：排程结果显示设备无缝衔接，实际执行时每次换产品要停 40 分钟，计划全乱。原因：建模时setup_time填了 0 或只填了首件。解决：换型时间必须按“前产品到后产品”的矩阵算，同一设备连续加工不同产品时累加。如果矩阵数据缺失，至少给一个保守的默认值，宁可排松不排紧。

4.2 物料齐套时间没进约束

现象：计划排到明天上午，仓库说料后天到。原因：earliest_start没填或填了订单创建时间。解决：物料齐套时间从采购到货或前道工序完工时间取，必须进约束。没有这个字段，排程就是空中楼阁。

4.3 优先级权重设成 1/2/3 导致目标函数失效

现象：紧急订单还是排在后面。原因：优先级用序数值，加权时量纲不对。解决：优先级用实际权重，比如交期紧迫度 = 1 / 剩余天数，这样目标函数才有区分度。序数值只适合排序，不适合加权求和。

4.4 时间槽太粗导致工序跨槽误差累积

现象：单道工序误差 15 分钟，一百道工序后偏差几小时。原因：离散时间槽取太大。解决：要么缩小槽宽，要么改连续时间。我的经验是，交期精度要求到小时级，槽宽不超过 15 分钟；到天级，30 分钟够用。

4.5 设备日历硬编码周末

现象：有的工厂周六上班，计划却跳过周六。原因：weekday() >= 5写死。解决：设备日历从资源表读，每台设备独立配置可用日期和班次。硬编码是原型阶段的权宜之计，上线前必须替换。

5. 从可行解到好计划：局部调整与滚动排程

贪心排程给的是可行解，不是好解。最后一章讲两个进阶技巧：局部调整和滚动排程。局部调整是在可行解基础上做交换和插入，降低总延期；滚动排程是每隔一段时间用实际执行数据重排，应对现场波动。

5.1 局部调整：交换相邻工序降延期

思路很简单：找出延期订单，看它和同设备上相邻工序能否交换，交换后总延期下降就保留。这是模拟退火或禁忌搜索的简化版，不追求全局最优，只求局部改善。

def local_improve(result, due_dates, max_iter=100): improved = True it = 0 while improved and it < max_iter: improved = False it += 1 # 按设备分组，尝试交换相邻工序 by_res = {} for r in result: by_res.setdefault(r["resource_id"], []).append(r) for rid, ops in by_res.items(): ops.sort(key=lambda x: x["start"]) for i in range(len(ops) - 1): a, b = ops[i], ops[i+1] # 只交换不同订单的工序 if a["order_id"] == b["order_id"]: continue # 计算交换前后延期变化 before = calc_tardiness(result, due_dates) # 交换时间 a_dur = (a["end"] - a["start"]).total_seconds() / 60 b_dur = (b["end"] - b["start"]).total_seconds() / 60 a["start"], b["start"] = b["start"], b["start"] + timedelta(minutes=b_dur) a["end"] = a["start"] + timedelta(minutes=a_dur) b["end"] = b["start"] + timedelta(minutes=b_dur) after = calc_tardiness(result, due_dates) if after < before: improved = True else: # 回滚 a["start"], b["start"] = b["start"] - timedelta(minutes=b_dur), a["start"] a["end"] = a["start"] + timedelta(minutes=a_dur) b["end"] = b["start"] + timedelta(minutes=b_dur) return result def calc_tardiness(result, due_dates): total = 0 by_order = {} for r in result: by_order.setdefault(r["order_id"], []).append(r) for oid, ops in by_order.items(): end = max(o["end"] for o in ops) due = due_dates.get(oid) if due and end > due: total += (end - due).total_seconds() / 60 return total

这段代码的交换逻辑有个隐患：交换后可能破坏工序顺序约束。实际用的时候，交换前要检查两道工序是否属于同一订单的前后道，是就不能换。max_iter控制迭代次数，现场跑 100 次通常几秒内完成，再大就上禁忌搜索。

5.2 滚动排程：用实际进度重排

滚动排程的核心是“冻结窗口 + 重排窗口”。已经开工的工序冻结，未开工的按最新进度重排。触发时机可以是每班次结束，也可以是关键设备完工后。

滚动排程的难点在数据回写。MES 报工有延迟，排程引擎要能处理“工序已开工但系统没记录”的情况。我的做法是给每道工序加一个actual_start字段，报工后更新，重排时以actual_start为准。

5.3 一个具体技巧：用瓶颈设备倒排

如果车间有明显瓶颈设备，正排（从前往后排）容易让瓶颈设备排队过长。改用倒排：从交期往前推，瓶颈设备优先占用，非瓶颈设备让路。倒排的实现是把贪心循环的方向反过来，从交期减工序时长往前找空档。这个技巧在瓶颈明显的车间效果立竿见影，瓶颈设备利用率能提 10% 以上。

我自己的习惯是，任何排程引擎上线前，先用历史数据回测一周，看计划达成率和设备利用率两个指标。回测不通过，不上线。排程这事，玄学成分有，但更多是数据质量和约束完整度的比拼。希望帮到你。

本文还有配套的精品资源，点击获取