本文详解如何在 or-tools cp-sat 求解器中，确保被拆分的同一工单工序（如15件批量任务拆为16个子任务）严格连续执行、不被其他工单任务插入，并原生支持多班制与周末停机约束。
本文详解如何在 or-tools cp-sat 求解器中，确保被拆分的同一工单工序（如15件批量任务拆为16个子任务）严格连续执行、不被其他工单任务插入，并原生支持多班制与周末停机约束。
在实际制造调度场景中，一个典型挑战是：某道关键工序加工时长远超单班次（如8小时），需跨2–3班甚至覆盖周末。若简单将其拆分为多个独立子任务（如“Setup + 15×Part”），仅靠 OnlyEnforceIf 等软性逻辑约束，极易出现任务碎片化——即其他工单的任务“插入”到该工序的子任务间隙中，导致换模频繁、设备空载、批次中断，严重违背工艺连续性要求。
你当前采用的 OnlyEnforceIf 方式本质是条件性排他约束：它要求“其他任务必须全部早于首子任务 或 全部晚于末子任务”，但该逻辑存在两个根本缺陷：
- 非强一致性：当调度空间紧张时，求解器可能选择满足 z.Not() 分支（即允许部分任务在末子任务后、部分在首子任务前），从而绕过连续性；
- 未建模时间依赖：未显式表达“子任务之间必须紧邻、零间隔”的物理约束，仅靠目标函数 Minimize(end - start) 无法保证中间无空隙。
✅ 正确解法不是“围堵插入”，而是重构建模范式——采用 OR-Tools 官方推荐的 IntervalVar 动态长度 + 日历感知调度（Calendar-Aware Scheduling），从根本上消除“拆分—再拼接”的脆弱设计。
✅ 推荐方案：用 NewOptionalIntervalVar + 日历驱动的动态区间
核心思想：不拆分长任务，而为其创建一个可跨越非工作时段的“弹性区间”，并让求解器自动计算其在有效工作时间内的实际占用长度。
from ortools.sat.python import cp_model
# 假设 machine_id = 0 的设备采用两班制：早班 6:00–14:00，晚班 22:00–6:00，周末全休
# 将日历预定义为 [(start_sec, end_sec), ...] 格式（单位：秒）
calendar_intervals = [
(6*3600, 14*3600), # 早班
(22*3600, 30*3600), # 晚班（次日6点=30h）
]
# 创建机器日历约束（关键！）
machine_calendar = model.NewCalendar()
for start, end in calendar_intervals:
model.AddCalendarWindow(machine_calendar, start, end)
# 对于一个需加工15小时的长工序（不拆分！）
processing_time_sec = 15 * 3600
# 创建可选区间：start, size, end —— size 由求解器根据日历自动推导
start_var = model.NewIntVar(0, horizon_sec, 'long_task_start')
end_var = model.NewIntVar(0, horizon_sec, 'long_task_end')
interval = model.NewOptionalIntervalVar(
start=start_var,
size=processing_time_sec, # 固定加工时长（纯工作时间）
end=end_var,
is_present=model.NewBoolVar('long_task_present'),
name='long_task_interval'
)
# 关键：绑定日历，强制该区间只能在有效班次内执行
model.AddIntervalToCalendar(interval, machine_calendar)? 为什么这能解决你的问题？
- AddIntervalToCalendar 告诉求解器：“此任务的 size 是纯加工耗时，但它的 start→end 必须完全落在日历窗口内，且中间自动跳过非工作时段”。
- 求解器将自动计算出最小 end - start（即含等待的总跨度），并确保所有子步骤在物理上连续——因为根本不存在“子任务”概念，只有一个逻辑原子任务。
- 同一工单下的多道工序，仍可通过标准 precedence constraints（model.Add(task2.start >= task1.end)）保证工艺顺序，无需额外“防插入”逻辑。
⚠️ 注意事项与最佳实践
- 避免手动拆分：除非有明确工艺要求（如必须中途质检），否则永远优先使用 NewOptionalIntervalVar + Calendar 替代人工拆分。拆分会指数级增加变量数，显著拖慢求解。
- 日历精度：建议统一使用秒级时间戳（int），避免浮点误差；周末可用 [(0, 0)] 表示全天不可用。
- 维修时段处理：设备定期维护可作为额外 CalendarWindow 加入 machine_calendar，与班次同权管理。
- 目标函数优化：若需最小化最大完工时间（makespan），直接 model.Minimize(max_end_var) 即可，无需 split_minimize 列表。
✅ 总结
| 方法 | 是否保证连续 | 是否支持班次/周末 | 可扩展性 | 推荐度 |
|---|---|---|---|---|
| OnlyEnforceIf + 拆分任务 | ❌（弱约束） | ⚠️（需手动建模） | 差（变量爆炸） | ⚠️ 不推荐 |
| NewOptionalIntervalVar + AddIntervalToCalendar | ✅（强约束） | ✅（原生支持） | 优（变量线性增长） | ✅ 强烈推荐 |
通过拥抱 OR-Tools 的日历感知调度能力，你不仅能彻底杜绝任务插入问题，还能自然兼容轮班调整、设备维保、节假日计划等真实产线约束——这才是工业级智能排程的正确打开方式。
