スケジュールエンジンの性能向上

リソース スケジューリング エンジンは、計画済およびリリース済の製造オーダーのルートをスケジュールします。

ジョブ ショップのスケジューリングの問題は、意思決定変数の数によって、ソリューションの時間が指数関数的に増加する、非常に複雑な組み合わせの問題です。 多くの場合、お客様は、最新のハードウェアであっても、妥当な時間内に解決できないスケジュールの問題を作成する方法で、運用ルートと関連データを設定します。 この記事では、スケジュール エンジンと、特定のセットアップがパフォーマンスに与える影響について説明します。

エンジンが解決する問題の複雑さを減らすことで、スケジュールのパフォーマンスを向上させます。 パフォーマンスに影響を与える主な要因には、次のようなものがあります。

• 多数の工程を含む工順
• 並行行程での工順
• 複数のリソースを含む操作
• 適用可能な多くのリソースを使用する工程
• ハード リンクの使用
• 有限能力の使用
• 使用されている異なる予定表の数
• カレンダーの 1 日あたりの稼働時間スロット数
• 工順の合計期間
• 複数のスケジューリング エンジンの並列実行

基本的なスケジューリング フローの概要

特定のセットアップがパフォーマンスに与える影響を理解するには、プロセスがエンジン内およびそれを囲む X++ コードでどのように流れるかを知る必要があります。

注文のスケジューリングの基本プロセスは、次の 3 つの主要なステップで構成されています。

• データの読み込み – X++ データ モデルは、ジョブと制約としてエンジンの内部データ モデルに変換されます。
• スケジュール – エンジンは、指定されたモデルと制約を処理して結果を生成します。 必要に応じて、作業時間情報と既存の容量予約を X++ に要求します。
• データの保存 – X++ コードは、エンジンの結果をジョブ容量予約スロットの形式で処理して、容量予約を保存し、ジョブ、操作、または注文の開始時刻と終了時刻を更新します。

エンジンへのデータの読み込み

スケジュール エンジンは、複数のデータ ソースを処理する汎用エンジンであるため、サプライ チェーン管理 データベースよりも抽象的なデータ モデルを使用します。 ルート、セカンダリ操作、ランタイムの概念は、エンジンが公開する汎用ジョブおよび制約モデルに変換されます。 モデルを構築するためのロジックには重要なビジネス ロジックが含まれており、ソース データによって異なります。 責任ある X++ クラスは WrkCtrSchedulerです。これには、計画製造オーダー、リリースされた製造オーダー、プロジェクト予測の派生クラスが含まれます。

たとえば、次の表に示すルートと、比較的単純な画像を考えてみます。

このルートをエンジンに送信すると、次の図に示すように、ルートが 8 つのジョブに分割されます (画像を選択して拡大します)。

2 つのジョブ間の標準リンクは FinishStart。つまり、あるジョブの終了時刻が別のジョブの開始時刻より前に発生する必要があります。 セットアップは、後でプロセスを処理するのと同じリソースで行う必要があるため、それらの間に OnSameResource 制約があります。 10 のプライマリ操作とセカンダリ操作のジョブ間には、 StartStart リンクと FinishFinish リンクがあります。つまり、ジョブは同時に開始と終了の両方を行う必要があります。 さらに、 NotOnSameResource 制約があるため、プライマリ操作とセカンダリ操作の両方で同じリソースが使用されなくなります。

リソースの数量が 3 に設定されている操作 20 の場合、プロセス ジョブは 3 つの異なるジョブに分割され、すべてのジョブを同時に実行する必要があります。 この場合、ルート グループは、キューの容量を後で予約しないように設定されるため、キューのジョブは 1 つだけです。

スケジュール エンジンはジョブの概念のみを理解し、操作を認識しません。 この制限は、操作のスケジュール中に、システムが操作をジョブに分割することを意味しますが、これらのジョブはデータベースに保持されません。

ジョブごとに、ジョブの容量要件 (必要な秒数) を定義します。 リソース要件の定義方法に応じて、ジョブごとに、ジョブが実行できる可能性のあるすべての適用可能なリソースの一覧と、その特定のリソースの容量要件の一覧を送信することもできます。 モデルの構築時に該当するリソースの一覧を送信しますが、エンジンはリソースの割り当てがジョブ期間全体で有効なままであることを確認します。

スケジューリング エンジンの内部

スケジューリング エンジンのインターフェイス

エンジンの内部的な動作を理解するには、外部で公開されている機能を確認します。 X++ で、主なインターフェイスは、WrkCtrSchedulerEngineInterface です。 次のサブセクションで説明する方法があります。

一般的なエンジン

個別のジョブ

ジョブ間の制約

ソルバー

エンジンは、カスタムヒューリスティックを持つ特殊な制約ソルバーです。 ソルバーは、変数と制約という 2 つの主要な要素に基づいています。

Variable

変数は、使用可能な値のドメインを表します。 スケジューリング エンジンには、次の 2 種類の変数があります。

• DateTime 変数 - すべての日付と時刻のドメインを持ちます。 変数の時間の下限と上限を互いに近づけることで、ドメインを制限できます。
• リソース変数 - 該当するリソースのドメインがあります。 一覧からリソースを削除することで、ドメインを制限できます。

制約

制約は、ドメインを制限することによって変数に作用します。 変数にも依存するため、変数が変更されるとアクティブになります。 「制約の反映」のプロセスは、制約が主な機能を実行し、成功したときにレポートを主要なロジックに戻す場合に行われます。

変数は、それ以上制限できない場合にバインドされていると見なされます。 DateTime 変数の場合、この条件は上限と下限が同じであることを意味します。 リソース変数の場合は、該当するリソースが 1 つだけであることを意味します。 すべての変数がバインドされると、ソリューションが見つかります。

制約レベル

スケジューリングが品目要件計画 (MRP) カバレッジ フェーズの一部である場合、システムは、要件日から逆に発注をスケジュールします。 ただし、今日以降に開始され、要件日より前に終了するスケジュールが見つからない場合は、今日から転送するようにスケジュールの方向が変更されます。

システムは、この主要なビジネス ルールを処理するレベルで制約を整理します。 最上位レベルの制約を使用するときにソリューションが見つからない場合は、そのレベルのすべての制約が削除され、下位レベルが試行されます。 実際には、このプロセスは、下位スケジュールの場合、モデルには、最大終了時間制約 (要件日) を指定した最新の開始時刻のジョブ目標を持つレベル 1 と、最も早い終了時刻のジョブ目標を持つレベル 0 と今日の最小開始時刻制約が含まれていることを意味します。

アルゴリズム

エンジン アルゴリズムの主要なステップは次のとおりです。

1. 個別に解決できるシーケンス (ジョブ チェーン) を検索します。
2. シーケンスの最初のソリューションを最も高い制約レベルで検索してみてください。
   1. システムが開始ジョブを見つけられるように、ジョブの目標と優先順位に基づいてシーケンス内のジョブを並べ替えます。
   2. 次の順番でジョブを順番に繰り返し処理します。
      1. 反映する必要があるすべての制約を検索し、反映を実行します。
      2. ジョブのすべての変数がバインドされている場合は、そのジョブのソリューションが見つかります。
      3. いずれかの変数を制約に違反せずにバインドできない場合は、変数バインドをロールバックし、ドメインで別の値を試して (リソース変数の場合)、制約の伝達を再実行します。
3. ソリューションが見つからない場合は、現在の制約レベルのすべての制約を削除し、制約レベルを下げて (使用できるレベルが低い場合)、新しい制約セットを使用してソリューション検索を再試行します。
4. 実行可能なソリューションが見つかった場合は、最適化フェーズを開始します。最適化のタイムアウトに達するか、すべてのリソースの組み合わせが使い果たされるまで、より適切なソリューションを見つけようとします。

制約ソルバーでは、スケジューリング アルゴリズムの詳細は考慮されません。 "マジック" は、さまざまな制約の定義と組み合わせで発生します。

作業時間の決定

エンジンの (内部) 制約の大部分は、リソースの作業時間と能力を制御します。 基本的に、タスクは、特定の方向の特定のポイントからリソースの稼働時間スロットを走査し、ジョブの必要な容量 (時間) が収まる十分な長い間隔を見つけることです。

これを行うために、エンジンはリソースの作業時間を把握している必要があります。 メイン モデル データとは異なり、稼働時間は 遅延読み込みされます。つまり、必要に応じてエンジンに読み込まれます。 このアプローチをとる理由は、サプライチェーン管理においてカレンダーの稼働時間が非常に長い期間に及ぶことが多く、通常、多くのカレンダーが存在するため、データをプリロードすることが難しいほど大規模になるからです。

エンジンは、 WrkCtrSchedulingInteropDataProvider.getWorkingTimes X++ クラス メソッドを呼び出すことによって、カレンダー情報をチャンク単位で要求します。 この要求は、特定の時間間隔における特定のカレンダー ID に対して行われます。 サプライ チェーン管理 でのサーバー キャッシュの状態に応じて、(純粋な計算時間を基準として) 時間がかかる各要求がいくつかのデータベース呼び出しで終了することがあります。 また、カレンダーに 1 日に多くの稼働時間を含む非常に複雑な稼働時間の定義が含まれている場合、この複雑さは読み込みにかかる時間に追加されます。

スケジュール エンジンは、稼働時間データを読み込むとき、このデータを特定のカレンダーの内部キャッシュに保持します。 この保持により、他のジョブやリソースが同じカレンダーを使用している場合、次回の参照がメモリから迅速に実行できることを意味します。 パフォーマンスが低下する一般的な原因の 1 つは、カレンダーの内容が同じであっても、各予定表に対してデータが要求されるため、リソースごとに個別の予定表 ID が使用される場合です。

有限能力

有限容量を使用すると、システムは、既存の容量予約に基づいてカレンダーの稼働時間スロットを分割して削減します。 同じ WrkCtrSchedulingInteropDataProvider クラスがカレンダーと一緒にこれらの予約を取得しますが、getCapacityReservations メソッドを使用します。 マスタ計画中にスケジュールを設定すると、特定のマスタープランの予約が考慮されます。 マスタ計画パラメータページで設定を有効にすると、確定製造オーダーの予約も含まれます。 同様に、製造オーダーをスケジュールする場合は、既存の計画手配の予約を含めることができますが、この順序は他の方法ほど一般的ではありません。

有限容量を使用する場合、スケジュール設定に時間がかかります。次のようないくつかの理由があります。

• データベースから容量情報をフェッチすると、操作が遅くなります。 容量情報のサーバー側キャッシュは、通常、カレンダーのようなリソース間で共有されないため、通常は稼働時間ほど適していません。
• 分割により、移動する稼働時間枠の数が増えます。 通常、システムは、ソリューションを見つける前に、スロットを長期間調査する必要があります。
• スケジュールが完了したら、システムは競合する予約を確認する必要があります (詳細については、「スケジュール エンジンの並列実行」セクションを参照してください)。

リソースの組み合わせの検証

ジョブ シーケンスに標準の FinishStart リンクのみが含まれている場合(つまり、分岐のない単純なチェーンを形成する)、システムは最初のジョブに最適なソリューションを見つけて次のジョブに最適なソリューションを見つけることで(注文間ではなく、単一の注文から見られる)最適な結果を得ることができます。 ジョブの最適な解決策は、ジョブの目的に最も近い開始日と終了日を取得できるリソースを見つけることです。このとき、制約を守りながら（前方スケジューリングでは、できるだけ早くジョブの終了日を取得することを意味します）。

並列ジョブがある場合、ソリューションを見つけるには、さまざまなリソースの組み合わせを調べることが必要になる場合があります。 使用可能なリソースの組み合わせ数は、接続された並列ジョブに適用できるリソースの数によって設定されます。 特に、要求日から逆に注文をスケジュールする場合、並列ジョブが今日の日付より前に収まる問題の解決策がないことをロジックが認識するまでにかなりの時間がかかる場合があります。 効率が高いリソースや、結果が得られる可能性のある別のカレンダーがある可能性があるため、ロジックではすべての組み合わせを確認する必要があります。 この条件は、タイムアウト制限を設定しない場合、プロセスが長時間実行されてから、転送方向が変更されることを意味します。

この組み合わせロジックは、より多くの適用可能なリソースを追加すると、エンジンの実行速度が低下する可能性があることを意味します。 並列操作があり、無限の容量でスケジュールしているときにパフォーマンスの問題が発生した場合は、ルート デザイナーで使用するリソースを決定し、操作に直接リソースを割り当てることで、部分的に問題を解決できます (ほとんどの場合、エンジンは常に同じリソースを選択するため、 したがって、最終的な結果は同じです)。

ハード リンク

2 つのジョブ間のリンクの種類をハードに設定すると、1 つのジョブの終了と次のジョブの開始の間に時間差がないことを確認できます。 この状態は、あるジョブで金属が加熱され、次のジョブで処理され、ジョブ間の冷却が望ましくないシナリオで役立ちます。

標準のソフト リンクとフォワード スケジューリングを使用すると、ルートが分岐なしで単純なチェーンを形成する場合は、独自の制約を満たす最初のジョブのソリューションを見つけて、チェーンを経由して前のジョブから次のジョブに終了時刻を伝達することで、結果を得ることができます。 現在のジョブで容量が見つからない場合、システムは、前のジョブに影響を与えることなく、開始タイムアウトをさらに移動します。 このアクションにより、ジョブ間にギャップが生じる可能性があります。 ただし、同じシナリオにハード リンク (特に有限容量に関連) を使用すると、チェーン内の後の 1 つのジョブで容量が見つからないという事実は、以前にスケジュールされたすべてのジョブを 1 つずつ "ドラッグ" し、それによって複数回再スケジュールする必要があることを意味します。 特に、複数のリソースの負荷が高いシナリオでは、ハード リンクによって連鎖反応が発生する可能性があり、ジョブが互いに影響し合い、結果が実現可能なスケジュールに安定する前に複数のイテレーションを実行する必要があります。

スケジューリング エンジンの並列実行

ヘルパーを使用するマスター 計画実行の一部としてスケジューリングを実行する場合、各マスター 計画ヘルパー スレッドは、製造オーダー スケジューリング タスクを選択することもできます。 この方法は、複数のスケジューリング エンジンを同時に実行できることを意味します。 マルチスレッドはパフォーマンスに大きなメリットをもたらしますが、スケジュール設定の機能上の欠点もあります。

MRP では、特定の部品表 (BOM) レベルのすべての製造オーダーが要件の日付順序でスケジュールされます。 この順序は、システムが最初に最も早い要件日でこれらの注文をスケジュールするので、利用可能なリソース容量を取得する可能性が最も高いということです。 ただし、複数のエンジンがスケジュールされていない注文の一覧から選択した場合、一方のエンジンが他のエンジンよりも速く完了する可能性があるため、シーケンスは保証されません。

有限の容量と複数のエンジン インスタンスを使用してスケジュールすると、同じリソースを同時に使用する注文をスケジュールしようとすると、競合状態が発生する可能性があります。 マスター プラン履歴ページの [スケジューリングの競合] フィールドには、レースコンディションの数が記録されます。 競合解決ロジックは、次の手順に従います。

1. 注文をスケジュール (ロックを解除) し、確保済能力を取得します。
2. ロックをかけます。
3. 期間にスケジュールされたリソースに新しい容量予約が存在するかどうかを確認します。
   • 存在しない場合は、能力を書き込み、ロックを解除します。
   • 存在する場合はロックを解除し、注文を最初から再スケジューリングします。

複数のエンジン インスタンスを使用してスケジュールを設定する場合、結果は各スレッドの正確なタイミングに依存するため、完全には確定的ではありません。

行程のスケジューリング パフォーマンス

大まかな容量計画とも呼ばれる操作スケジューリングは、実現可能性を判断するためにより多くのデータが必要であるため、有限容量を使用する場合、エンジンの観点から解決するのが難しい場合があります。

リソース グループの能力は、リソース グループのメンバーとなっているリソースとその数によって異なります。 リソース グループ自体には容量がありません。リソースがグループのメンバーである場合にのみ、容量を持ちます。 リソース グループのメンバーシップは時間の経過と共に変化するため、1 日あたりの能力を評価する必要があります。

工程のスケジューリングでは、各工程の開始時刻と終了時刻を決定するために、リソース グループのカレンダーが使用されます。 このカレンダーでは、1 つのリソース グループで 1 日に 1 回の操作に対して操作をスケジュールできる時間に制限が設定されます。 特定のリソースのカレンダーとは異なり、リソース グループのカレンダーの効率データは無視されます。これは、実際の容量ではなく、営業時間のみを示しているためです。

たとえば、ある特定の日付のリソース グループの稼働時間が 8:00 から 16:00 の場合、リソース グループがその日に合計で使用できる容量に関係なく、1 つの操作でリソース グループに 8 時間に収まる量よりも多くの負荷を割り当てることはできません。 ただし、使用可能な容量によって負荷がさらに制限される可能性があります。

特定の日のリソース グループ内のすべてのリソースに対するジョブ スケジュールの負荷は、その日の使用可能な容量を計算するときに考慮されます。 各日付の計算方法は次のとおりです。

使用可能なリソース グループの容量 = 予定表に基づくグループ内のリソースの容量 - グループ内のリソースに対するジョブのスケジュールされた負荷 - グループ内のリソースに対するスケジュールされた負荷の操作 - リソース グループに対するスケジュールされた負荷の操作

ルート操作の [ リソース要件 ] タブでは、特定のリソース (その場合は、そのリソースを使用して操作がスケジュールされます)、リソース グループ、リソースの種類、または 1 つ以上の機能、スキル、コース、または証明書を使用して、リソース要件を指定できます。 これらのオプションをすべて使用すると、ルート設計の柔軟性が得られますが、"プロパティ" ごとに容量を考慮する必要があるため、エンジンのスケジュール設定が複雑になります (機能やスキルなどのためにエンジンで使用される抽象名)。

リソース グループの機能の容量は、対象の機能を持つリソース グループ内のすべてのリソースの容量の合計です。 グループ内のリソースに機能がある場合、エンジンは、必要な容量のレベルに関係なく、それを考慮します。

運用スケジュールでは、リソース グループに対して特定の機能に使用できる容量は、該当する機能を必要とする操作と共に読み込まれると減ります。 操作に複数の機能が必要な場合、必要なすべての機能に対して容量が削減されます。

各日付の必要な計算方法は次のとおりです。

機能の使用可能な容量 = 機能の容量 - リソース グループに含まれる特定の機能を持つリソースに対するジョブ のスケジュールされた負荷 - リソース グループに含まれる特定の機能を持つリソースに対するスケジュールされた負荷の操作 - 特定の機能を必要とするリソース グループ自体に対するスケジュールされた負荷の操作

特定のリソースに負荷がある場合、負荷がその特定の機能に対して行われるかどうかに関係なく、負荷によってグループの容量への貢献度が低下するため、エンジンはリソース グループの機能ごとの使用可能な容量を計算するときにそれを考慮します。 リソース グループ レベルに負荷がある場合、エンジンは、特定の機能を必要とする操作からの負荷である場合にのみ、リソース グループの機能ごとの使用可能な容量の計算でそれを考慮します。

このロジックはプロパティの種類ごとに適用されるため、有限の容量で操作スケジュールを使用するには、大量のデータを読み込む必要があります。

MRP パフォーマンスの改善

次の技術会議ビデオでは、非推奨のマスター プランニング エンジンで MRP を使用する場合にマスター プランニングのパフォーマンスを向上させるためのヒントを提供します。 ヘルプ!MRP が遅い!

スケジューリング エンジンの入力と出力の表示

スケジューリング プロセスの入力と出力に関する具体的な詳細を取得するには、 組織の管理>Setup>Scheduling>Scheduling トレース コックピットに移動してログ記録を有効にします。

このページで、[アクション ウィンドウで ログ記録を有効にする ] を選択し、製造オーダーのスケジュールを実行します。 完了したら、スケジューリング トレース コックピット ページに戻り、アクション ウィンドウでログの無効化を選択します。 ページを更新すると、グリッドに新しい行が表示されます。 新しい行を選択し、[アクション ウィンドウ] で [ダウンロード ] を選択します。 このアクションにより、次のファイルを含む .zip 圧縮フォルダーが提供されます。

• Log.txt – このログ ファイルには、エンジンが実行する手順が記述されています。 詳細であって圧倒されることがありますが、パフォーマンスの問題を解決するためにルートの設定を試す際には、最初と最後の行の間の時間差を確認してください。 この違いは、スケジューラが費やした正確な時間を示しています。
• XmlModel.xml – このファイルには、X++ に組み込まれており、エンジンが動作するモデルが含まれています。 ファイルで使用される JobId は、ジョブ (RecId または ReqRouteJob) を含むソース テーブルの ProdRouteJob と関連しています。 このファイルで、 ConstraintJobStartsAt と ConstraintJobEndsAt の日付が想定どおりに設定されていること、 JobGoal プロパティが正しく設定されていること、およびジョブが JobLink 制約を介して関連付けられていることを確認します。
• XmlSlots.xml – このファイルには、エンジンが要求するすべての稼働時間と容量予約が含まれます。 カレンダーの稼働時間と予約は、ジョブ (および余分なバッファー) を配置しようとする期間だけエンジンによって要求されるため、ファイルに将来非常に遠い時間が含まれている場合は、セットアップに問題があることを示している可能性があります。 ResourceProperty ノードには、各リソースに関連付けられているリソース グループと機能と、関連する期間が表示されます。
• Result.xml – このファイルには、スケジュール実行の結果が含まれます。

トレース機能を使用すると、パフォーマンスのオーバーヘッドが大幅に増加するため、特定の注文のスケジュールを制御された方法で調査する場合にのみ使用します。 マスター プランの実行中に有効にすると、すぐにサイズ制限に達し、停止します。

パフォーマンスのトラブルシューティング

前のセクションからわかるように、スケジュール エンジンのセットアップと使用に関するいくつかの落とし穴が、パフォーマンスの問題につながる可能性があります。 次のチェックリストは、これらの問題のトラブルシューティングに役立ちます。 多くの場合、問題につながる複数の要因の組み合わせであるため、すべての点を見てください。

必要ない場合に MRP の一部としてスケジュールを実行する

工順は、原価やレポートなどの生産管理の目的で使用されますが、MRP 中に考慮する必要がない場合があります。 場合によっては、品目に対して標準生産リードタイムが指定されていれば、計画には十分なことがあります。 ルートスケジューリングをオフにするには、キャパシティタイムフェンスを 0 に設定します。 スケジュールが必要な場合は、MRP のカバレッジ タイム フェンスの全範囲についてルートを考慮する必要がない可能性があるため、容量タイム フェンスを慎重に設定します。

MRP 中に注文がスケジュールされていない場合は、計画オーダーが確定されたときにスケジュールする必要があります。 つまり、確定プロセスに時間がかかるため、提案された計画オーダーの確定数によっては、MRP 中のパフォーマンスの向上が確定時に失われる可能性があります。

不要な行程での工順

ルートを設計するときは、実稼働プロセスで実行されるすべての手順を使用して、現実の世界を正確にモデル化しようとしないでください。 この方法は場合によっては役に立ちますが、エンジンのモデルが大きくなり (ジョブと制約の観点から)、ジョブと容量予約を挿入および更新するために実行される SQL ステートメントが増えるため、パフォーマンスには適していません。 また、最終的にジョブの進行状況を報告する必要があるというダウンストリームの影響があり、自動投稿によって軽減される可能性があります。 データが何にも使用されない場合は、不必要な負荷が生じます。

スケジュール設定 (通常はボトルネックのリソース) またはコスト計算の目的で厳密に必要な操作のみを作成します。 代わりに、多数の小さな個別の操作を、プロセスの大きな部分を表す 1 つの大きな操作にグループ化します。

工程に適用可能な多くのリソース

操作関係に設定されたリソース要件によって、操作に適用できるリソースの数が決まります。 要件は、特定のリソースに対するものです。または、リソース グループまたは機能のリソースのメンバーシップに基づく場合があります。

スケジュールに有限の容量を使用せず、該当するすべてのリソースが同じカレンダーと効率を持つ場合、スケジュール エンジンは常に操作に対して同じリソースを選択しますが、該当するすべてのリソースを試して、他のリソースよりも優れているリソースがあるかどうかを確認します。 この場合、ルート設計時に常に特定のリソースを操作に割り当てることで、スケジュールの負荷を大幅に削減できます。

並行行程での工順

並列操作 (プライマリ/セカンダリ) は、マシンとオペレーターの両方が特定のタスクを実行するために必要なシナリオをモデル化するための強力なツールですが、多くのパフォーマンスの問題の原因でもあります。 特定の個々のリソースの要件をプライマリ操作とセカンダリ操作の両方に割り当てる場合、通常は問題になりません。 ただし、各工程に対して多くの使用可能なリソースがある場合は、スケジューリングに非常に複雑な計算が必要になります。

並列操作を使用する代わりに、ペアを "仮想" リソースとしてモデル化するか (その後、操作のために常に連携するチームを表します)、ボトルネックを表さない場合は単にいずれかの操作をモデル化しない方法があります。

リソース数が 1 より多いルート

操作に必要なリソースの量が 1 より多い場合、複数の並列ジョブがエンジンに送信されるため、結果は実質的にプライマリ/セカンダリ操作の使用と同じです。 ただし、この場合、数量が 1 つを超える場合、操作に複数のリソースを適用する必要があるため、特定のリソース割り当てを使用することはできません。

リソースの読み込み数量が 1 より大きい二次工程は、基本工程の各リソースに対して二次リソースの指定が必要であることを意味します。 たとえば、基本工程のリソースの数量が 2 に設定され、その二次工程のリソースの数量が 3 に設定されている場合、二次工程に対して合計 6 個のリソースが必要です。

有限能力の過度な使用

有限容量を使用するには、エンジンがデータベースから容量情報を読み込む必要があります。これは、特にリソースが最大容量に近い場所に予約されている環境で、計算オーバーヘッドを追加する可能性があります。 その結果、リソースが実際に有限の容量を使用する必要があるかどうか、または過剰予約が可能かどうかを慎重に評価することが重要です。 有限の容量リソースの間で、オーバーブックを行わない重要度に違いがある可能性があるため、リソースのボトルネックオプションを、計画の別の値と組み合わせて使用します 。"ボトルネック リソースの容量タイム フェンス"ボトルネックの概念を使用すると、一般的な有限容量タイム フェンスを下げることが可能になります。

ハード リンクの設定

ルートの標準リンクの種類は ソフトであり、ある操作の終了時間と次の操作の開始時間の間の時間差を許容します。 このギャップを許可すると、いずれかの操作で材料または容量が使用できない場合、生産がアイドル状態になる可能性があります。 この状況は、進行中の作業の増加につながる可能性があります。 この問題はハード リンクでは発生しません。これは、仕上げと開始が完全に一致している必要があるためです。 ただし、ハード リンクを設定すると、運用の 2 つのリソースの稼働時間と容量の交差を計算する必要があるため、スケジュール設定の問題がより困難になります。 スケジュールに並列操作も含まれる場合、この要件により計算時間が大幅に増加します。 2 つの工程のリソースにまったく重複しないカレンダーがある場合、問題は解決しません。

ハード リンクは、厳密に必要な場合にのみ使用し、ルートの各操作に必要かどうかを慎重に検討してください。

ハード リンクを適用せずに進行中の作業を減らすには、2 回のスケジュールを設定し、2 回目のパスでは順序を逆方向に変更します。 最初のスケジュールが納品日から逆算して行われた場合、次のスケジュールは予定開始日から順に進める必要があります。 この方法では、ジョブをできるだけ圧縮して、進行中の作業を最小限に抑えます。

リソースごとの個別のカレンダー

スケジューリング エンジンのデータの主要なソースの 1 つにカレンダー情報があります。これは、データベースからの読み込みにコストがかかる場合があります。 カレンダーはテンプレートに基づいて生成されるため、リソースごとにカレンダーを生成し、リソースにダウンタイムやその他の問題がある場合に、このカレンダーの情報を調整したくなる可能性があります。 ただし、この方法では、リソースごとに新しいデータを要求する必要があるため、カレンダー データをキャッシュするエンジンの機能が大幅に制限されます。 この方法では、パフォーマンスの問題が発生する可能性があります。 リソース間で可能な限り予定表を再利用し、一定期間別の予定表 ID を割り当てることでダウンタイムの変更を制御します。

1 カレンダー日あたりの最大作業タイム スロット数

エンジンは容量についてタイム スロットを 1 つずつ調べることで機能するため、カレンダー日あたりのタイム スロットの数を最小限に抑えるのが有益です。 たとえば、作業者が 1 時間ごとに 5 分間の休憩を取ることを、結果のスケジュールに反映することが重要かどうかを検討します。

大規模スケジューリング タイムアウト (または、なし)

[スケジュール パラメーター] ページにあるパラメーターを使用して、スケジュール エンジン のパフォーマンスを 最適化できます。 [ スケジュール タイムアウトが有効] と [ スケジュールの最適化タイムアウトが有効] の設定は常に [はい] に設定します。 [ いいえ] に設定すると、多くのオプションを持つ実現不可能なルートが作成された場合、スケジュール設定が無限に実行される可能性があります。

1 シーケンスあたりの最大スケジューリング タイムの値は、単一のシーケンスに対するソリューションを検索するために費やす最大秒数を制御します (ほとんどの場合、1 シーケンスは単一の注文に対応します)。 ここで使用する値は、ルートの複雑さと有限容量などの設定によって大きく異なりますが、最大約 30 秒が適切な開始点です。

最適化の試行タイムアウトの値は、最初に検出されたものよりも優れたソリューションを見つけるために使用できる最大秒数を制御します。 この値は、並列操作を使用するルートにのみ影響します。これらの操作では、さまざまな組み合わせをテストする必要があるためです。

ジョブスケジューリングの一般的なエラー

次の表に、既知のジョブ スケジュール エラーと、それらを解決するのに役立つ情報へのリンクを示します。

関連情報

• カレンダーおよびマスター プラン
• 発注書の出荷予定日を計算する
• 計画の最適化で使用される日付と時刻のパラメーター
• 安全マージン