Question

我们正在与optaplanner和流口水一起安排工作车间。
我们正在尝试管理类似于Microsoft项目管理中项目级别的时间表。尤其是，鉴于可以过度分配更多资源，有必要确定要对哪些资源进行操作或给出优先级的有序列表。 Microsoft Project使用灵活性裕度。因此，首先移动利润率较高的活动。

我们需要从optaplanner获得Microsoft项目管理的相同结果，尤其是在时间性能方面。在我们的日程安排中，问题在于工作中心与项目管理相比存在更多的空白，并且延期。

我们注意到，与100 jobs相比，调度程序的效果要好于项目管理，并且预计最后一次处理将在5天之内完成，而从600 jobs开始，情况更糟，我们不知道这是否是应有的某些不精确或自定义移动的拖曳规则。

从创建自定义动作开始，即使为硬性约束节省了大量时间，按顺序分组的流程也总是彼此“附加”在一起的，这本身并没有错，但这可能会限制optaplanner实际上，项目管理可以带来更多的联合对于我们来说，计划必须快速，而快速的性能是我们的首要目标之一。

在70 machines和4000 jobs的集合中，我们需要能够在几分钟内优化调度。

域模型
类和计划实体是：

工作中心（id，名称，日历参考）
日历（id，班次）
轮班（工作日数，开始/结束时间）
流程（标识，名称，持续时间，开始日期，顺序）
顺序（id，名称，开始/结束）
工作分配（编号，工作参考，工作中心，开始和结束日期）
安排时间（每个上一个分数+得分的列表）

约束

-   hard
   production sequences:   
    a process cannot start before its previous one ends
   valid calendar:
    a process must be assigned in the working shifts of the machine in which it is processed
   overload:
    example: if on Monday the machine works 8 hours. I can't put two “5-hour” jobs on it

-   soft
   makespan
   do not leave holes of inactivity when using the center

对于软约束，我们仅考虑尝试将订单延迟最小化。不考虑任何其他逻辑关键路径。我们的问题事实是小数部分很大，整个部分代表日期，小数部分表示小时和分钟

工作分配类是我们的计划实体，其中开始日期是我们的真实变量，结束日期是我们的影子变量（取决于持续时间）

我们还实现了自定义移动，该移动将移动调度程序选择和移动的工作的后续工作。这是因为解决硬性约束花费的时间太长（甚至半小时），而不是通过此自定义移动，只需不到30秒的时间。

为了获得更快的结果，我们使用contablevaluerange作为有问题的事实，这是一种自定义移动并将转换后的对象从日历转换为日历。示例：

之前

   object1 17 July from 8 to 14;
   object2: 17 July from 15 to 19;
   object3 18 July from 8 to 14, 
   etc etc

之后
现在它们只是一个用于控制约束的日历，而且还使用了迭代器来生成随机移动（在使用列表之前）

现在，我们将optaplanner的结果与Microsoft项目的结果进行比较。与Microsoft项目（具有700个工作的相同问题数据集）相比，我们的计划程序有一个月的延迟，我们可以更好地解释：

   project management  
     starts the first processing on 17 July 2019 and the last on 7 May 2020
   optaplanner
     starts the first processing on 17 July 2019 and the last on half of June 2020.

optaplanner定义日期所花费的时间为三分钟。

一种提高我的optaplanner作业车间调度项目的性能速度/质量的方法

0 个答案: