複雑な作業スケジュールのモデリング


9

私が表現して自動化しようとしている現実の問題があります。私はそれを次のように簡略化して抽象化しました:

  • nの作業場所があります(P1、P2、...、Pn)。
  • 各場所、Pnにはキー、Knがあります。
  • ワーカーがm人います(W1、W2、...、Wm)。
  • Pnで働くためには、労働者はKnを持たなければなりません。
  • 各キーは、労働者が保持するか、取引所Eに残しておくことができます。
  • ワーカーはいつでもExchangeにアクセスして、要求されていないキーを取得したり、他のユーザーが使用できるようにいくつかのキーをドロップしたりできます。

  • 現在、厳格な順序で完了する必要がある外因性の作業スケジュールがあります。例えば:

    • 2016-04-21 W1はP6で働く必要があります
    • 2016-04-21 W2はP3で働く必要があります
    • **鍵の交換が必要です**
    • 2016-04-22 W3はP3で働く必要があります
    • 2016-04-22 W2はP6で働く必要があります
  • 同じ日に決してではないが、スケジュールのある時点でPnで働く必要のある労働者はいくつもいる可能性がある

私たちは知っています:

  • すべてのキーの開始場所(労働者またはEのいずれか)
  • 各ワーカーが満たす必要がある将来の作業指示

それで、私はこの全体の状況をモデル化するのに苦労しています。データ構造とアルゴリズムを提案して、それを把握し、各ワーカーのエクスチェンジへのトリップの最適化を開始するために検討する必要がありますか?

私が最小限にしたいのは、Eへの旅行の総数です。2番目の目標は、労働者が不釣り合いな数の旅行をしないようにすることです。

前もって感謝します!!


2
従業員あたりのEへの平均トリップ数= "総トリップ数" / m。したがって、mが定数の場合、2つの目標は同じ目標です。もっと興味深い:私は各労働者が同時に複数のキーを運ぶことができると思いますか?
Doc Brown

はい、労働者は任意の数のキーを運ぶことができます。「普通」については、自分のことをうまく表現できなかったと思います。私は公平性についてもっと考えていました。労働者が不釣り合いな数のトリップを完了する必要がないため、分散が小さいことです。(一致するように編集された質問)
Gareth Lloyd

ワーカーは明らかにキーに信頼されており、交換を必要としない限り、必要な限り夜通しキーを保持する可能性があるため、永続的に保持する各ワーカーのキーのセットを作成してみませんか?または、特定の期間、たとえば1週間、彼らが行くすべての場所について、各労働者のキーのセットを作成します。キーは必要に応じて複製され、すべてのワーカーに1週間を設定します。すべての労働者は週に1回鍵を交換します。
–radarbob

交換に行くのに費用(お金または時間)はありますか?
Dan Pichelman

はい、交換へのより多くの旅行は悪い結果です。
Gareth Lloyd

回答:


1

問題は、1つの重要な点について少しあいまいです。どの要素を解決しようとしているのかです。リソースが委任される順序の最適化を検討していますか?交換への旅行を最小限に抑えますか?作業指示のスループットを最大化しますか?

そのことを念頭に置いて、これらのことを任意に混合して、かなり高いレベルで答えを保つことができると想定します。

最初に頭に浮かぶのは、これが解決しようとする相互に関連する問題は、主に依存関係の管理に集中しているということです。ワーカー、キー、場所は、作業ジョブを完了するために解決する必要がある依存関係と考えることができます。

これを次のレベルに引き上げて、トポロジカルソートの適応について見ていきます(https://en.wikipedia.org/wiki/Topological_sorting)。問題空間を大きなグラフとしてモデル化し(最新のグラフデータベースもこの分析の一部にとって適切な媒体となる場合があります)、さまざまなトポロジカルソートを使用して問題空間のさまざまな側面を解決します。

少し正接すると、これは本当に楽しいプロジェクトのように聞こえます。今日、私はあなたがうらやましいです。



着色アルゴリズムはこの状況で役立ちますか?en.m.wikipedia.org/wiki/Graph_coloring
linuxunil 16
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.