【问题标题】:Vehicle Routing / Resource Scheduling Algorithm Design车辆路径/资源调度算法设计
【发布时间】:2009-12-18 00:00:11
【问题描述】:

我在这里的第一篇文章——希望你能帮助我设计一个我已经考虑了一段时间的算法——不知道要采取什么方法(VRPTW 或资源调度或完全其他的东西!?)

举个实际的例子,我们在少数几个地方(通常少于 5 个)有大量的花园垃圾。必须在给定的时间范围内将废物全部运送到其他地点。为了移动花园垃圾,我们有拖车,必须用汽车牵引。花园垃圾只能在特定时间(时间窗口)丢弃在垃圾场。在某些地点,我们可以将拖车放下,由那里的人来装满或清空,但在其他地点,汽车司机必须自己做,汽车必须留在那儿。可以计算所有时间(即装载/卸载时间、运输时间等)。汽车可以在没有拖车的情况下在站点之间移动,拖车可以拖空,但拖车不能在地点之间自行移动。

我们的目标是确保所有拖车装载的废物在运输的同时

  • 尽量减少使用中的拖车和汽车的数量
  • 满足所有丢弃废物的时间窗口
  • “平衡”拖车 - 即在一天结束时,我们在每个位置的拖车数量与一天开始时一样多

我曾想过将此作为一种资源调度算法,但我不确定如何处理预告片的“平衡”。

我考虑的另一种方法是首先考虑汽车。然后我可以选择最早的任务并在此之后构建所有可行任务的图表。如果我然后选择通过图表的最长路径将服务于最大数量的拖车负载。然后我可以从任务列表中删除这些任务并重复,直到所有任务都得到服务。然后我需要遍历这些拖车负载列表来计算所需的拖车数量。

任何关于方法的想法将不胜感激!

【问题讨论】:

  • 我认为“动态规划”是一种流行的约束解决方案。我已经有一段时间没有讨论日程安排问题了。

标签: algorithm resource-scheduling logistics


【解决方案1】:

我同意 Jiri 的观点……您需要一种启发式算法,该算法能够快速合理地接近可接受的解决方案,然后从那里进行改进。

我之前曾在有配送路由软件的公司工作过,他们采用的方法是使用遗传算法来解决非常相似但规模大得多的问题。如果您不熟悉该方法,请使用look here。从那个网站:

  1. [开始] 生成 n 条染色体的随机种群(问题的合适解决方案)
  2. [适应度] 评估种群中每个染色体 x 的适应度 f(x)
  3. [新建人口]通过重复以下步骤创建一个新人口,直到新人口完成

    【选择】根据适应度从种群中选择两条亲本染色体(适应度越好,被选中的机会越大)

    [Crossover] 以交叉概率与父母交叉,形成新的后代(子代)。如果没有进行交叉,后代就是父母的精确副本。

    [突变] 在每个基因座(染色体中的位置)以突变概率突变新的后代。

    [接受] 将新的后代放入新的种群中

  4. [替换] 使用新生成的种群进一步运行算法
  5. 【测试】如果满足结束条件,停止,返回当前种群中的最优解
  6. [循环] 转到第 2 步

实现这一点的诀窍是将您的约束编码为“染色体”并编写“适应度”函数。适应度函数必须输入一个潜在解决方案的结果,并给出一个解决方案有多好的分数,或者如果它违反任何约束则将其丢弃。

正如 Jiri 所提到的,此解决方案的优势在于它提供了一个可行的(虽然可能不是最好的)答案,但运行速度非常快,并且运行时间越长,解决方案就越好。

【讨论】:

  • 感谢大家的回复。我之前在其他一些任务中使用过一些简单的 GA,所以我熟悉这种方法。健身功能不应该太难 - 它是一个简单的成本方程。我将不得不考虑编码染色体,因为它需要捕获 - 汽车 - 拖车 - 开始时间 - 任务 ID - 任何“空运行”以平衡拖车
【解决方案2】:

我们肯定在这里讨论的是一个 NP 完全算法,除了一些汽车和拖车之外,这不会是一项任务,您可以从所有可能的解决方案中获得最佳解决方案,然后能够丢弃它并重新开始避免您建议的最长路径。如果您以这种方式设计算法,很可能有一天您会添加更多的汽车和拖车,而它永远无法完成计算解决方案。

您可能希望使用能够合理快速地生成足够好的问题解决方案的算法。确保您为解决方案的质量创建了一个度量标准,您获得了一种评估理想解决方案的度量值的好方法,然后为自己设置了一些百分比,您希望您的解决方案在该百分比范围内来自理想解决方案,并且简单地取第一个度量在范围内的解决方案。这样做的额外好处是,如果该算法的计算时间过长而您中止它,您仍然可以使用具有最低计算指标的解决方案,即使它不在您的预期范围内。

我不确定采取什么方法来解决问题本身。我建议在搜索acm portal 后阅读几篇文章。我认为 UPS 和 Fedex 可能有类似的问题,如果您将它们作为关键字添加到 google 搜索中,您可以获得一些更有用的结果。

【讨论】:

    【解决方案3】:

    我倾向于同意罗伯特的观点。对我来说,这听起来像是他描述的遗传算法实现等进化优化技术的绝佳候选者。

    我在粒子群优化 (PSO) 的某些问题上也取得了很好的成功。基本上,您可以将每个基因组视为某个多维空间中的一个粒子。粒子的坐标是您计算的参数(适应度函数)。每个粒子以随机速度随机开始。对于模拟的每次迭代,您使用当前行进向量更新每个粒子的位置,然后添加其他向量的分量,例如:到目前最好的粒子的方向、到有史以来最好的粒子的方向、到局部组的方向最好的等等...

    一开始实现 GA 或 PSO 似乎相当令人生畏,但我向您保证,编写一个从您尝试优化的实际问题域中抽象出算法 (GA/PSO) 的小型框架很容易。您可以随时返回 Wikipedia 了解算法的详细信息。

    一旦我有了一个框架,我通常会从一个 2 参数问题开始(可能是您的问题的简化,或者图像上的 X 和 Y 位置),这样我就可以轻松地可视化和调整算法,以便我做得更好蜂拥而至的行为。然后我将其放大到更多维度。

    我喜欢这种方法,因为它使我能够轻松地针对实际问题陈述中包含相当复杂和复杂部分的问题进行优化(例如汽车和拖车)。

    此外,进化技术之所以有吸引力,是因为您可以将固定部分的时间用于模拟,并在您决定停止时采取迄今为止的最佳答案。

    根据我的经验,您在调整 GA 或 PSO 的参数(一旦实现)上花费的时间与编写硬编码启发式解决方案所花费的时间一样多,但这样做的好处是改变了查找策略该解决方案通常只需要更改参数或将定义明确的算法换成另一种实现,而不是编写完全不同的策略来从头开始以启发式方式解决问题。

    如果您需要有关为这两种算法中的任何一种设计通用框架的指导,请给我留言。我必须指出,您也可以获得几个不错的免费 3rd 方框架。我有时喜欢自己编写代码,因为那时我了解算法的各个方面,并且知道可以在哪里调整策略。

    【讨论】:

      【解决方案4】:

      一般方法:

      由于问题很小,我建议您添加汽车和拖车,直到找到可行的解决方案,而不是尽量减少汽车和拖车。

      解决:

      我在有约束的 GA 上取得的成功较少,在对整数变量(例如,一个位置的拖车数量)有约束的 GA 上,我的成功率更低。约束规划可能是一种更好的方法,因为您只想为给定数量的汽车和拖车生成可行的解决方案,而不是试图最小化行驶距离。

      观察:

      您正在解决网络上的问题,其中最后一步可能是重新定位空拖车。

      祝你好运!

      【讨论】:

        【解决方案5】:

        本地搜索是遗传算法的替代方案。在 2007 年国际时间表比赛中,本地搜索算法(例如禁忌搜索和模拟退火)明显击败了遗传算法条目(LS 排名第 1 至第 4,而 GA 在第 1 赛道中排名第 5,大约80 个竞争对手 IIRC)。

        另外,看看那里的一些库,例如OptaPlanner(禁忌搜索、模拟退火、延迟验收、开源、java)、JGap(遗传算法、开源、java)、OpenTS(禁忌搜索,...

        【讨论】:

        • 我认为您在这里误用了一些术语。遗传算法属于元启发式算法。进化算法(遗传、模因等)和基于局部搜索的算法(模拟退火、禁忌搜索等)是元启发式的子类别。超启发式不被视为元启发式。
        • @Jimbo 我完全同意和不同意我以前的自己:) 答案已调整。除了关于超启发式的部分可能不是元启发式。从使用的角度来看,它们的行为和感觉是相同的。这就像说人不是动物,因为他是一种特殊的动物。
        • 他们的感觉完全不同。超启发式包括一个额外的抽象层,它完全不知道问题的结构。较低级别的启发式层要么由简单的低级启发式算法组成,要么由高级算法选择的启发式算法段组成。超启发式算法也是更通用的算法。有一些超启发式算法的例子可以解决跨多个问题域的问题。例如,用于解决人员调度问题的相同算法可以解决车辆路线、TS 和背包问题。
        • 最大的定义区别在于,虽然元启发式算法在问题解决方案的搜索空间中运行,但超启发式算法在启发式算法的搜索空间中运行,或者在某些情况下是启发式算法的片段。在前一种情况下,启发式是从列表中选择的,而在后者中,启发式是从段列表中构建的。超启发式比元启发式更有效,并且表现出与定制算法相媲美的性能,同时保持高度的通用性。
        猜你喜欢
        • 2012-11-26
        • 2014-01-30
        • 2023-02-09
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2021-06-20
        • 2017-07-16
        • 1970-01-01
        相关资源
        最近更新 更多