前言
易排平台发布之初，完全基于OptaPlanner 官方的一些示例进行开发。官网发布的众多示例呈现了各行各业各种场景下，通过OptaPlanner作为规划引擎的运筹优化场景。社区项目团队除了对引擎程序进行了完整且严格的测试外，还对所提供的示例程序进行了稳妥的测试。因此，这些示例是我们学习的重要资料。
在构思易排平台时，我基于当时参与过的若干行业的APS项目经历，拟出一个同时兼容流程制造与离散制造场景下的排程需求清单，并选择其中较为常见、典型的几个需求作为平台的内置需求。目标是构建一个具有APS最小功能子集的基础平台，以便最大程度提高各个行业、场景的兼容性。而一些行业相关性较大、特异性较强的需求，则计划在具体项目实施过程中，以特殊功能的形式提供。以防平台因特异性功能过多而降低了兼容性和适用范围。
而在与客户的具体项目合作过程中，确确实实出现了一些我之前未遇到过的需求，有涉及业务规则的，有优化目标相关的，更有对引擎核心模型产生具大挑战，甚至可以说对原来的规划模型产生颠覆的需求。甚至一度让我怀疑OptaPlanner能否实现这些，从业务角度看上去再也正常不过的需求。此过程中各种模型修改，反复建立、推翻、再建立修改新方案的过程，令我这个设计者、开发者心情，用跌宕起伏来形容并不为过。尽管如此，在这段时间的反复构思、实验过程中，对OptaPlanner有更深一层的认识。
目前易排平台的规划核心已有一个较大更新，无论在性能与兼容性，适用范围上均有了质的飞跃，一些以往无法实现的需求和特性，也已提供完善的解决方案。本文作为本次平台规划核心升级的一个纪念，以平台其一个需求的设计方案作为案例，分享一下该规划模型的设计。
注意：本文介绍到的方案是上一版本引擎核心中的一个模式与设计方案。本次升级过程中，这个方案已经进行了更有效的升级，基于技术保密，暂时未能公开最新设计方案。该方案虽然仍有一定的不足，但对于一些复杂度不高，特异性需求不多的场景，还是具有较高参考价值的。平台核心的设计，遵循更新一版、公开前一版的原则进行技术分享。若下一次引擎核心有重大升级，将会公布当前的设计方案，敬请期待。下面进入正题内容。
需求案例
在我们设计APS程序时，以下需求是无法逃避的。
-
设备的时间维度，有工作时间、休息时间与维保时间之分；在常见的APS系统中，设备会定义为资源，通过资源日历来定义上述时间。
-
当一个任务分配到一个设备时，需要自动垮过这些休息时间与维保时间。
-
有些任务有可能存在后处理时间，即一个工序完成后，需要静置一定的时间后，后工序才能开始，但这个静置时间并不占用资源。例如喷漆工序完成后，需要静置一段时间待干燥，这个等待时间我们称为静置时间。
例如，有以下时间和任务加工场景，如以下 图1
图1
时间轴
对于工作时间，假设如上图1展示了一个月的时间轴，一个月的3号到25号为工作日，其它时间为非工作时间，例如公众假期、设备维保计划时间等。在工作时间中，有3个周末并不工作，分别是6、7号，13、14号，以及20、21号。
工单与任务
一个工单包含4个任务，其长度与静置时间分别如下：
-
任务1：时长3天，静置时长1天；
-
任务2：时长6天，静置时长1天；
-
任务3：时长2天，静置时长0天（无需静置）；
-
任务4：时长4天，静置时长3天。
那么，若我们把这4个任务分配到这个时间段内，那么，它们的分布时间应该如下：
-
任务1：从3号开始，5号完成加工，6号为静置时间(静置时间不占用资源，因此周末也可以静置)；
-
任务2：从8号开始，跨越一个周末(13、14号)，15号完成加工，16号为静置时间；
-
任务3：从17号开始，虽然任务2在16号已完成加工，但需要静置1天，作为后置工序的任务3才能开始，因此需要17号才能开始，于18号完成，不需静置；
-
任务4：19号开始，跨越一个周末(20、21号)，24号完成加工，静置3天，并在27号完成，虽然26、27号是非工作时间（机台维保，或其它原因停工），但不影响静置处理。
上述计划安排，从专业排产师的角度看，并不复杂。但若通过项目任务调试模型(PJS模型)来实现，则会面临非常多的细节问题需要解决。上述问题是对实际场景的一个抽象概念；实际过程中，同一工单中的各个工序所衍生出来的任务，需要使用不同的资源来执行，使用不同的资源(例如：设备、工位)又会遇到更多复杂的问题待解决，例如：
-
资源效率差异 - 同一任务使用不同的资源加工时，其效率不同，造成加工时长不同；
-
资源工作时间差异 - 不同资源的工作时间不同，例如：不同机台有不同的维保计划，不同的班次安排等；
-
存在多个可选资源 - 同一任务可以从多个可用资源中选择其中一个进行加工(根据优化策略进行择优分配)。
-
......
当考虑了上述实际场景中的复杂性时，即便再专业、经验再丰富的排产师，需要排出一个合理、高效的生产计划，也是一项目极具挑战性的工作。此时，一个好的APS引擎即可体现价值。
设计方案
需求
其实该需求被简化后，变成了“任务如何跨越资源的休息时间”的问题。上述需求中，其中一个重点是：当一个任务分配到一个资源后(此时该任务的时长已确定)，如何实现任务的加工周期内忽略休息时段？即任务跨越该休息时段，将加工时间延长分配到休息时段后的工作时间上去。在该方案的的设计思路中，我着眼于对时间段的简化。因此，方案如下：
第一：构建一个新的时间索引序列，在新的时间索引中，将各资源公共的休息时间（如周末、午休）等时间忽略。即剔除出资源索引序列 (如下图2)
图2 - 用工作时间创建新的时间索引序列
第二：找出所有资源中最小的连续工作时间长度，假设该长度为A，将加工时长大于A的任务进行分割，形成多个子任务，各个子任务形成前后工序关系；令所有任务(包括不分割的原始任务及分割后的子任务)的时长均小于等于A（如下下图3）
图3 - 分割过长任务
第三：添加一个硬约束，确保从第二步中分割出来的各个子任务分配到同一资源上（如下图4）。
图4 - 通过约束或选择过滤器，确保同一个任务的子任务分配到同一资源上
第四：引擎完成规划并输出结果后，将所获结果，按照第二步分割任务的映射关系，将子任务合并回原始任务。将时间索引重新映射回时间戳，从而得到各个任务的具体加工时间.
该方案的优缺点
优点：
-
将时间轴上的公共休息时间过滤掉，从而实现引擎在推导任务时，无需考虑不连续时间段之间的接续问题，从时间索引上看，是一个简单的、连续的时间轴，起到简化时间轴作用。
-
将时间戳重新映射成以0为基准的时间索引序列，在调试过程中，可以极大地简化时间推导运算，从而令程序更容易调试。
-
实现了统一简化的时间索引后，引擎在运算过程中，关于时间的运算量大幅度减少，提高了运算性能。
缺点
-
该过程需要对任务及资源的处理步骤过多，需要使大量用映射表来记录资源的时间戳与时间索引关系、原始任务与子任务等众多关系，操作过于繁复。
-
对于分割出来的子任务需要额外添加约束来确保分配到相同资源，使用引擎多了一道非业务相关的约束，加大引擎运算负担。此外，要实现此约束也需大费周章。
-
将任务分割成子任务后，实际上导入到引擎进行规划运算的任务数量增多，令问题规模增大，导致性能下降。
-
对于有静置时间需求的任务，该方案在部分情况下处理并不合理（这里留一个问题给大家思考，哪些情况下静置时间的处理会出现不合理？）
新的方案
目前我们的平台上的模型核心已使用新的模型方案，能有效解决上述问题，目前仍有部分需求的逻辑，需要与新的方案整合；新模型核心的测试环境将在近日发布。欢迎大家试用，并提出宝贵意见！我们将不断对规划核心进行优化，当出现较大模型核心变更时，我们会将上一代的方案分享出来，供各位研究、开发APS的达人学习讨论。在优化引擎核心的过程中，深深感受到OptaPlanner作者 Geoffrey De Smet 在社区讨论中，关于上述问题的回复意见中提到 - the devil is in the details （魔鬼在细节中）
祝大家战胜魔鬼，开发出优秀的模型！
同时也邀请大家使用我们的【易排通用智能规划平台】，它基于OptaPlanner对APS的一些常用规划逻辑进行封装，大家只需要管理、维护好自己系统(使用MES、MOM、ERP中的计划模块)中的工单数据，即可快速地实现一个APS模块。后续我们还会添加【VRP - 车辆路径规划】和【在线调度】模块，敬请期待。可以通过以下链接查看更多该平台的使用方法。
易排(EasyPlan)通用智能规划平台 Q&A
