スケジュール エンジンのパフォーマンスの改善
リソースのスケジューリング エンジンは、計画およびリリース済製造オーダーの工順をスケジューリングする際に使用されます。 エンジンは最初、Dynamics AX 2012 の一部としてリリースされ、そのリリース以来、いくつかの改善がなされました。
ジョブ ショップのスケジューリングの問題は、意思決定変数の数によって、ソリューションの時間が指数関数的に増加する、非常に複雑な組み合わせの問題です。 多くの場合、顧客は、最新のハードウェア上であっても、適切な時間内に解決できないスケジューリングの問題が発生するような方法で、生産工順および関連するデータを設定します。 この記事では、スケジューリング エンジンと、特定の設定がパフォーマンスにどのように影響するかについて説明します。
スケジューリングのパフォーマンスを向上させるために、一般的なガイドラインでは、エンジンで解決する必要がある問題の複雑さを軽減することが勧められています。 パフォーマンスに影響を与える主な要因には、次のようなものがあります。
- 多数の工程を含む工順
- 並行行程での工順
- リソースの数量が 1 より高い工程
- 適用可能な多くのリソースを使用する工程
- ハード リンクの使用
- 有限能力の使用
- 使用される異なるカレンダーの数
- カレンダーの 1 日あたりの作業タイム スロット数
- 工順の合計期間
- 複数のスケジューリング エンジンの並列実行
基本的なスケジューリング フローの概要
特定の設定がどのようにパフォーマンスに影響するかを理解するには、プロセス フロー (エンジン内部と、それを取り囲む X++ コードの両方) を理解しておくことが重要です。
注文のスケジューリングの基本プロセスは、次の 3 つの主要なステップで構成されています。
- データの : ここでは、X++ データ モデルが、ジョブと制約の形式でエンジンの内部データ モデルに変換されます。
- スケジューリング : これは、指定されたモデルと制約を処理して結果を生成するスケジューリングの主要なソースです。 このプロセス中に、エンジンは、必要に応じて、作業時間の情報と、X++ の既存の確保済能力を要求します。
- [データの保存 /& : ジョブ能力予約の更新という形式のエンジン結果をX++ コードで処理して、能力の予約を節約し、ジョブ/工程/注文の開始時間と終了時間を更新します。
エンジンへのデータの読み込み
スケジューリング エンジンは、データのさまざまなソースを処理できる汎用エンジンとして構築されているため、Supply Chain Management データベースよりも抽象的なデータ モデルが含まれています。 工順、二次工程、および実行時間の概念を、エンジンが公開する汎用ジョブおよび制約モデルに「変換」する必要があります。 モデルを構築するためのロジックには、膨大な量のビジネス ロジックが含まれており、ソース データによって異なります。 担当の X++ クラスは、WrkCtrScheduler です。これは、計画製造オーダー、リリース済製造オーダー、およびプロジェクト予測の派生クラスを備えています。
例として、次の表と画像に示すように、比較的単純なルートについて検討します。
| 工程 No. | 優先順位 | 段取り時間 | 実行時間 | 作業後待ち時間 | リソースの数量 | 次 |
|---|---|---|---|---|---|---|
| 10 | 基本 | 1.00 | 2.00 | 1 | 20 | |
| 10 | 副次 1 | 1 | 20 | |||
| 20 | 基本 | 3.00 | 1.00 | 3 | 0 |
これをエンジンに送信すると、次の図に示すように 8 つのジョブに分割されます (画像を選択して拡大します)。
2 つのジョブ間の標準リンクは、FinishStart です。1 つのジョブの終了時刻を別のジョブの開始時刻よりも前にする必要があることを意味します。 この設定は、後でプロセスを実行する同じリソースによって実行される必要があるため、これらには OnSameResource 制約があります。 10 の基本工程と二次工程のジョブには、ジョブが両方同時に開始および終了する必要があることを意味する StartStart および FinishFinish リンクがあり、基本と二次で同じリソースを使用できないようにする NotOnSameResource 制約があります。
リソースの数量が 3 に設定されている工程 20 では、プロセス ジョブは 3 つの異なるジョブに分割され、すべてのジョブをまったく同時に実行する必要があります。 この場合、後のキューに対するジョブは 1 つだけのため、工順グループは後のキューのために能力を確保しないように設定されます。
スケジューリング エンジンはジョブの概念だけを理解し、工程の概念はありません。 つまり、工程のスケジューリングを実行する場合、工程はジョブに分割されますが、それらはデータベースには保持されません。
各ジョブについて、ジョブの能力要件 (必要な秒数) も定義します。 リソース要件の定義方法に応じて、各ジョブについて、ジョブを実行する可能性があるすべてのリソースの一覧と、特定のリソースに対して必要な容量を送信することもできます。 モデルの作成時に適用可能なリソースの一覧が送信されますが、エンジンでは、リソース割り当てがジョブ期間全体に対して実際に有効であることを確認する必要があります。
スケジューリング エンジンの内部
スケジューリング エンジンのインターフェイス
エンジンが内部でどのように機能するかを把握するために、外部に公開する機能について確認することをお勧めします。 X++ で、主なインターフェイスは、WrkCtrSchedulerEngineInterface です。 次のサブセクションで説明する方法があります。
一般的なエンジン
| メソッド | 目的 |
|---|---|
run |
読み込まれたジョブをすべてスケジュールし、エラー コードを返します。 |
getJobSchedulingSequenceResult |
スケジュールの結果と、特定のジョブによって識別されたシーケンスの最初のエラー ジョブを取得します。 |
validateJobCapacityReservations |
エンジンによって保存されているすべてのジョブの確保済能力を検証します。 |
setReservationsTimeStamp |
エンジンのキャッシュにあるスケジュールされたジョブについて、すべての新しい確保済能力に設定されたエンジンにタイムスタンプを送信します。 |
addPropertyToGroupAggregation |
能力の集計時に使用されるプロパティのセットに、プロパティの接頭語を追加します。 |
addResource |
スケジューリング エンジンのリソース プールにリソースを追加します。 |
addResourceGroup |
スケジューリング エンジンのリソース グループ プールにリソース グループを追加します。 |
addResourceGroupMembership |
リソース グループにリソースをメンバーとして追加します。 |
addOptimizationGoal |
スケジューリングの最適化目標 (期間または優先順位) を追加します。 |
個別のジョブ
| メソッド | 目的 |
|---|---|
addJobInfo |
スケジューリングする必要があるジョブについてエンジンに通知する、ジョブ情報レコードを追加します。 |
addConstraintJobEndsAt |
指定した日時にジョブを終了する制約を追加します。 |
addConstraintJobStartsAt |
指定した日時にジョブを開始する制約を追加します。 |
addConstraintMaxJobDays |
ジョブが指定された最大日数にまたがることができるように制約を定義します。 |
addConstraintResourceRequirement |
特定のリソースでジョブをスケジューリングする必要があるようにする制約を追加します。 |
addJobBindPriority |
(ジョブ、制約レベル) ペアのジョブ バインド優先順位を追加します。 優先順位の値が高いことは、ジョブ変数が先にバインドされることを意味します。 このジョブは、同じシーケンスの優先順位の値が低いジョブよりも先に処理されます。 |
addJobCapacity |
ジョブが実行されるリソースに依存しないジョブ (必要なジョブ ランタイムなど) の最大能力負荷の情報を追加します。 |
addJobResourceCapacity |
ジョブを実行するために使用される可能性がある一連のリソースにリソースを追加し、そのリソースでの実行時に必要な能力を規定します。 |
addJobGoal |
特定の制約レベルのジョブの目標情報 (最も早い終了時刻または最も遅い開始時刻) を追加します。 |
addJobResourcePriority |
リソースにジョブがスケジュールされている場合に使用する優先順位を追加します。 |
addJobResourceRuntime |
ジョブのスケジューリングが行われるリソースに依存するジョブ時間を指定します。 |
addJobRuntime |
ジョブのスケジューリングが行われるリソースに依存しないジョブ時間を指定します。 |
scheduleJobOnResourceGroup |
リソース グループ レベルのスケジューリングのジョブをマークします。 |
setJobResourcePreemptionAllowed |
リソースのジョブに対して強制排除を許可するかどうかを設定します (連続していない能力スロットのジョブのスケジュールをエンジンが許可されている場合)。 |
setRequiredNumberOfResources |
ジョブをスケジュールするために必要なリソースの数を設定します (工程のスケジューリングに対してのみ)。 |
ジョブ間の制約
| メソッド | 目的 |
|---|---|
addJobLink |
2 つのジョブ間にリンク (完了 > 開始など) を追加します。 |
addConstraintEndsDelayed |
別のジョブの終了に一定の遅延時間を加えたものより前に、ジョブが終了することができないようにする制約を定義します。 |
addConstraintJobListWorkingTimeIntersect |
ジョブに予約された能力スロットが、ジョブによって使用される 2 つのリソースの重なりあう作業時間にある必要があるようにする制約を追加します。 |
addConstraintJobOverlap |
最初のリソースが処理を終了しないうちに、2 つ目のリソースが処理を開始できるようにするため、特定の品目の数量が 2 つのリソース間で移動するときのジョブの順序付けを定義する制約を追加します。 |
addConstraintNotOnSameResource |
2 つのジョブを同じリソースに対してスケジュールできないようにする制約を追加します。 |
addConstraintOnSameResource |
2 つのジョブが必ず同じリソースを使用するようにする制約を追加します。 |
addJobSameReservations |
ジョブが、基本ジョブと同じタイム スロットに対して確保済能力を持つ必要があるようにする制約を追加します。 |
setPrimaryParallelJob |
一連の並列ジョブにおいて、どのジョブが基本ジョブであるかについての情報を追加します。 |
ソルバー
エンジン自体は、基本的に、カスタム ヒューリスティックを追加するための特殊な制約ソルバーです。 ソルバーは、変数と制約という 2 つの主要な要素に基づいています。
変数
変数は、使用可能な値のドメインを表します。 スケジューリング エンジンには 2 つのタイプの変数があります。
- DateTime変数 : すべての日付と時刻のドメインを持ち、変数の時間を上下に移動することでドメインを制限できます。
- リソース変数 : 該当するリソースのドメインを持ち、リストからリソースを削除することでそのドメインを制限できます。
制約
制約は、ドメインを制限することによって変数に対して機能しますが、変数によって異なり、変数が変更されたときに有効になります。 「制約の反映」のプロセスは、制約が主な機能を実行し、成功したときにレポートを主要なロジックに戻す場合に行われます。
変数は、それ以上制約を受けることができない場合、バインドされていると見なされます。これは、DateTime 変数の場合には上限と下限が同じであること、リソース変数の場合には適用可能なリソースが 1 つしかないことを意味します。 すべての変数がバインドされると、ソリューションが見つかります。
制約レベル
原材料の必要量の計画 (MRP) の補充フェーズの一部としてスケジューリングを実行すると、注文は要求日から逆算してスケジューリングされます。 ただし、当日以降に開始され、要求日よりも前に終了するスケジュールが見つからない場合は、スケジューリング指示が今日以降に変更されます。
この主要なビジネス ルールは、制約をレベルで体系化することによって処理されます。 最上位レベルでの制約の使用時にソリューションが見つからなかった場合、そのレベルの制約はすべて削除され、下位レベルのテストが試行されます。 実践においては、バックワード スケジューリングに対して、モデルには、最も遅い開始時刻のジョブの目標があり、最大の終了時刻制約 (要求日) が指定されたレベル 1 と、最も早い終了時刻のジョブの目標があり、当日の最小の開始時刻制約が指定されたレベル 0 が含まれます。
アルゴリズム
エンジン アルゴリズムの主要なステップは次のとおりです。
- 個別に解決できるシーケンス (ジョブ チェーン) を検索します。
- 制約レベルが最も高いシーケンスの最初のソリューションを見つけます。
- ジョブの目標と優先順位に基づいて、シーケンス内のジョブを並べ替えます。開始ジョブが見つかる可能性があります。
- 次のシーケンスでジョブをループします:
- 反映する必要があるすべての制約を検索し、反映を実行します。
- ジョブのすべての変数がバインドされている場合、そのジョブのソリューションは見つかります。
- 制約に違反せずにいずれかの変数をバインドできなかった場合、その変数のバインディングをロールバックし、ドメインの異なる値を試行して (リソース変数の場合)、制約の反映を再実行します。
- ソリューションが見つからなかった場合は、現在の制約レベルのすべての制約が削除され、制約レベルが引き下げられ (下位のレベルが利用可能な場合)、新しい一連の制約を使用してソリューションの検索が再試行されます。
- 実行可能なソリューションが見つかった場合は、最適化フェーズが開始され、最適化タイムアウトに達するまで、またはすべてのリソースの組み合わせが使い果たされるまで、より優れたソリューションの検索を試行します。
制約ソルバーは、スケジューリング アルゴリズムの詳細を認識しません。 これは、「マジック」が起こるさまざまな制約の定義および組み合わせに含まれています。
作業時間の決定
エンジンの (内部) 制約の大部分は、リソースの作業時間と能力を制御します。 基本的に、このタスクでは、特定の方向の特定のポイントからリソースの作業タイム スロットを移動して、ジョブの必要な能力 (時間) に合わせることができる十分な期間を見つけます。
これを行うために、エンジンはリソースの作業時間を把握している必要があります。 主要なモデル データとは反対に、作業時間は必要に応じて、遅延読み込みで、エンジンに読み込まれます。 この方法を使用するのは、非常に長い期間にわたるカレンダーの Supply Chain Management の作業時間が発生し、通常、多くのカレンダーが存在して、多くの場合、プリロードに対してデータが非常に大きくなるためです。
カレンダー情報は、チャンクでエンジンが WrkCtrSchedulingInteropDataProvider.getWorkingTimes X++ クラス メソッドを呼び出すことによって要求されます。 この要求は、特定の時間間隔における特定のカレンダー ID に対して行われます。 Supply Chain Management でのサーバー キャッシュの状態に応じて、(純粋な計算時間を基準として) 時間がかかる各要求がいくつかのデータベース呼び出しで終了することがあります。 また、カレンダーに、1 日あたりの多くの作業時間間隔を含む、非常に詳細な作業時間の定義が含まれている場合には、これが読み込み時間に加算されます。
スケジューリング エンジンに作業時間データが読み込まれると、データは、特定のカレンダーの内部キャッシュに保持されます。つまり、他のジョブまたはリソースが同じカレンダーを使用している場合、次のルックアップをメモリから迅速に実行できます。 カレンダーの内容が同じであっても、カレンダーごとにデータを要求する必要があるため、各リソースに個別のカレンダー ID が使用されて、パフォーマンスが低下する一般的な原因の 1 つとなる場合があります。
有限能力
有限能力を使用すると、カレンダーの作業タイム スロットが、既存の確保済能力に基づいて分割および削減されます。 これらの予約は、カレンダーと同じ WrkCtrSchedulingInteropDataProvider クラスによっても取得されますが、代わりにこの getCapacityReservations メソッドを使用します。 マスター プランのスケジューリング時に、特定のマスター プランの予約が考慮され、マスター プラン パラメーター ページで有効になると、確定した製造オーダーからの予約が含まれるようになります。 同様に、製造オーダーのスケジューリング時に、既存の計画オーダーからの予約を含めることもできますが、これは他の方法ほど一般的ではありません。
有限能力を使用すると、次のいくつかの理由によりスケジューリングに時間がかかります。
- データベースから能力情報を取得する場合は処理速度が低下し、通常、サーバー側のリソース間で共有されていないため、能力情報のキャッシュは通常の作業時間ほど良くありません。
- 分割によってスキャンする作業タイム スロットの数は増加しますが、通常、より長い期間のスロットを調査してからソリューションを見つける必要があります。
- スケジューリングが完了したら、競合する予約の確認を実行する必要があります (詳細については、「スケジューリング エンジンの並列実行」を参照してください)。
リソースの組み合わせの検証
ジョブ順序に標準 FinishStart リンクのみが含まれている場合、つまり分岐がない単純なチェーンを形成する場合は、最初のジョブに対して最適なソリューションを見つけてから、次のジョブに最適なソリューションを見つけるため、(注文間ではなく 1 つの注文から見た) 最適な結果を達成できます。 ジョブの最適なソリューションは、制約を遵守しながら、ジョブの目標に最も近いジョブの開始日と終了日を取得できるリソースを特定することです (フォワード スケジューリングでは、ジョブの終了日をできるだけ早く取得することを意味します)。
並列ジョブがある場合は、ソリューションを見つける際に、さまざまな組み合わせのリソースを調べる必要があります。 使用可能なリソースの組み合わせ数は、接続された並列ジョブに適用できるリソースの数によって設定されます。 特に、要求日から逆算して注文をスケジュールする場合、高性能な、または結果を出すさまざまなカレンダーを含むいくつかのリソースがある可能性があるため、今日の日付以前に並列ジョブを適合させるためにすべての組み合わせを確認する必要があり、ロジックが、問題のソリューションがないことを認識するのにかなり時間がかかる場合があります。 これは、タイムアウト制限が設定されていない場合、方向をフォワードに変更する前に長時間実行することを意味します。
また、この組み合わせロジックは、エンジンの実行速度を低下させる可能性のある適用可能なリソースをさらに追加することを意味します。 並列処理と無限の能力でのスケジューリングによってパフォーマンスの問題が発生した場合は、使用するリソースについての決定を工順設計者に依頼して、工程にリソースを直接割り当てることにより、問題の一部を解決することができます (ほとんどの場合、エンジンは常に同じリソースを選択するので、最終結果は同じになります)。
ハード リンク
2 つのジョブ間のリンク タイプをハードに設定すると、1 つのジョブの終了と次のジョブの開始との間に時間のギャップがなくなります。 この方法は、1 つのジョブで金属が加熱されて、次のジョブで処理される場合、その間に金属が冷却されることが望ましくないシナリオなどで役立ちます。
標準のソフト リンクとフォワード スケジューリングを使用すると、工順が分岐のない単純なチェーンを形成する場合、独自の制約を満たす最初のジョブに対するソリューションを見つけて、次のジョブに前のジョブの終了時刻を反映させることによって結果を実現できます。 現在のジョブで能力が不足している場合は、前のジョブによりジョブ間でギャップが作成される可能性が生じないように、開始時刻がさらに先に移動されます。 ただし、同じシナリオに対して (特に有限能力に関連して) ハード リンクを使用した場合、チェーン内の後の 1 つのジョブで能力が見つからないことは、それまでのすべてのスケジュール済ジョブを 1 つずつ「ドラッグ」して、その回数を再スケジューリングすることを意味します。 特に、複数のリソースに対する負荷が高いシナリオでは、ハード リンクによって、ジョブが相互に影響を与えるチェーンに対する反応が生じ、結果が実現可能なスケジュールで安定する前に多数の繰り返しを実行する必要がある場合があります。
スケジューリング エンジンの並列実行
ヘルパーが使用されているマスター プランの実行の一部としてスケジューリングを実行する場合、マスター プラン ヘルパーの各スレッドは、製造オーダーのスケジューリング タスクを選択することもできます。 これは、複数のスケジューリング エンジンを同時に実行できることを意味します。 一般的なマルチスレッド処理はパフォーマンス上非常に重要ですが、スケジューリングに関しては、いくつかの機能的な弱点があります。
MRP では、特定の部品表 (BOM) レベルのすべての製造オーダーは要求日シーケンスでスケジュールされます。つまり、要求日が最も早い注文は、最初にスケジュール設定する必要があります。その結果、利用可能なリソース能力を取得できる可能性が高くなります。 ただし、計画外の注文の一覧で複数のエンジンを選択した場合、シーケンスは保証されないため、他の注文よりも早く完了することがあります。
また、有限能力を使用してスケジューリングする場合や、複数のエンジン インスタンスが同じ時間間隔で同じリソースを使用する可能性のある注文をスケジュールしようとする場合、競合状態が発生する可能性があります。 このような競合状態の数は、マスター プランの履歴ページのスケジューリングの競合 フィールドに記録されます。 競合解決ロジックは次のとおりです。
- 注文をスケジュール (ロックを解除) し、確保済能力を取得します。
- ロックをかけます。
- 期間内にスケジュールされたリソースに新しい確保済能力が存在するかどうかを確認します。
- 存在しない場合は、能力を書き込み、ロックを解除します。
- 存在する場合はロックを解除し、注文を最初から再スケジューリングします。
したがって、複数のエンジン インスタンスを使用してスケジューリングする場合は、各スレッドの正確なタイミングによって異なるため、結果が完全に確定的になりません。
行程のスケジューリング パフォーマンス
行程のスケジューリングは、エンジンの視点から見たおおまかな能力計画とも呼ばれますが、実現性を決定するために必要なデータが増えるにつれて、有限能力が使用された場合に困難な問題が発生する可能性があります。
リソース グループの能力は、リソース グループのメンバーとなっているリソースとその数によって異なります。 リソース グループ自体にキャパシティはありません。そのグループのメンバーにキャパシティがある場合にのみ、キャパシティを持ちます。 リソース グループのメンバーシップは時間の経過と共に変化するため、1 日あたりの能力を評価する必要があります。
工程のスケジューリングでは、各工程の開始時刻と終了時刻を決定するために、リソース グループのカレンダーが使用されます。 つまり、リソース グループのカレンダーでは、1 つのリソース グループで 1 日に 1 回の行程に対してスケジュールできる行程の時間に制限があります。 特定のリソースのカレンダーとは異なり、カレンダーの効率データは、実際の能力ではなく単に始業時間を示しているため、リソース グループでは無視されます。
たとえば、ある特定の日付のリソース グループの作業時間が午前 8 時～午後 4 時である場合、リソース グループがその日に合計で利用できる能力に関係なく、1 つの工程で、8 時間に収まる以上の負荷をリソース グループにかけることはできません。 ただし、使用可能な能力は、負荷をさらに制限することができます。
特定の日のリソース グループに含まれるすべてのリソースのジョブ スケジューリングからの負荷は、同じ日のリソース グループの使用可能な能力が計算されるときに考慮されます。 各日付の計算方法は次のとおりです。
使用可能なリソース グループの能力 = カレンダーに基づくグループ内のリソースの能力 : ジョブスケジュール済グループのリソースに対する負荷がスケジュールされます。グループ内のリソースに対するスケジュール済のリソース負荷 – リソース グループに対してスケジュールされた運用負荷
工順工程のリソース要件タブでは、リソース要件は、特定のリソース (この場合、行程はそのリソースを使用してスケジュールされます)、リソース グループ、リソース タイプ、または、1つ以上の機能、スキル、コース、または証明書のいずれかを使用して指定できます。 これらのオプションをすべて使用することで、工順デザインに優れた柔軟性が得られますが、「プロパティ」 (機能やスキルなどのエンジンで使用される抽象名) ごとに能力を考慮する必要があるため、エンジンのスケジューリングが複雑になります。
機能のリソース グループの能力は、対象となる機能を持つリソース グループ内のすべてのリソースの能力の合計になります。 グループ内のリソースに機能がある場合は、必要な能力のレベルにかかわらず、そのリソースは考慮されます。
工程のスケジューリングでは、リソース グループの特定の機能の使用可能な能力は、対象の機能を必要とする行程で読み込まれると低下します。 工程に複数の機能が必要な場合は、必要なすべての機能について能力が低下します。
各日付の必要な計算方法は次のとおりです。
能力に使用可能な能力 = 能力 : リソース グループに含まれる、特定の能力を持つリソースに対するジョブスケジュール負荷 : リソース グループに含まれる、特定の機能を持つリソースに対する工程のスケジュール済の負荷 – 特定の機能を必要とするリソース グループ自体に対して工程のスケジュール済負荷。
つまり、特定のリソースに負荷が発生した場合、特定のリソースの負荷がその特定の機能に対するものであるかどうかに関係なく、特定のリソースの負荷がその機能に対するリソース グループの能力への貢献度を減らすため、負荷は機能ごとのリソース グループの使用可能な能力の計算で考慮されます。 リソース グループ レベルに負荷がある場合は、特定の機能を必要とする工程から負荷がかかる場合にのみ、機能ごとにリソース グループの使用可能な能力の計算で考慮されます。
上記のロジックは、「プロパティ」のタイプごとに同じであるため、有限能力を持つ工程のスケジューリングを使用すると、大量のデータをロードする必要があるので複雑になります。
MRP パフォーマンスの改善
次の技術会議ビデオで、非推奨のマスター プラン エンジンで MRP を使用している場合に、マスター プランのパフォーマンスを向上させる方法に関するヒントをいくつか紹介します: MRP の処理に時間がかかる!。
スケジューリング エンジンの入力と出力の表示
スケジューリング プロセスの入出力についての特定の詳細を取得するには、組織管理 >設定 >スケジューリング >スケジューリング トレース コックピットへ移動してログを有効にします。
このページでは、最初にアクション ウィンドウでログの有効化を選択します。 その後、製造オーダーのスケジューリングを実行します。 完了したら、スケジューリング トレース コックピット ページに戻り、アクション ウィンドウでログの無効化を選択します。 ページを更新すると、グリッドに新しい行が表示されます。 新しい行を選択して、アクション ウィンドウでダウンロードを選択します。 これにより、次のファイルを含む .zip 圧縮フォルダが得られます。
- Log.txt : エンジンの実行手順を説明するログ ファイルです。 これは非常に複雑で少し混乱する可能性がありますが、パフォーマンスの問題を解決するための工順の設定の実験の一部として使用する場合、最初に探すのは最初の行と最後の行の時間差です。これにより、スケジューラが費やした正確な時間がわかります。
- XmlModel.xml : X++ を組み込み、エンジンを操作するモデルが含まれている。 ファイルで使用される
JobIdは、ジョブ (ReqRouteJobまたはProdRouteJob) を含むソース テーブルのRecIdと関連しています。 このファイルでは、ConstraintJobStartsAtとConstraintJobEndsAtで指定された日付が予期したものであること、JobGoalプロパティが正確に設定されていること、および、ジョブがJobLink制約により相互に関連していることを確認するのが一般的です。 - XmlSlots.xml : エンジンから要求された作業時間と能力の予約が含まれる。 カレンダーの稼働時間と予約は、エンジンがジョブ (および追加のバッファ) を配置しようとする期間にのみ要求されるため、ファイルに非常に遠い将来の時間が含まれている場合は、設定に問題があることを示している可能性があります。
ResourcePropertyノードは、リソースごとに、どのリソース グループと機能がどの期間に関連付けられているかを示します。 - Result.xml - スケジューリングの実行の結果が示されます。
追跡機能はパフォーマンス オーバーヘッドを大幅に増加させる可能性があるため、制御された方法で特定の注文のスケジューリングを調査する場合にのみ使用してください。 マスター プランの実行中にオンになっていると、すぐにサイズ制限に達して停止します。
パフォーマンスのトラブルシューティング
前のすべてのセクションから理解できるように、スケジューリング エンジンの設定と使用に関しては、パフォーマンスの問題につながる可能性のあるいくつかの落とし穴があります。 このような問題のトラブルシューティングには、次のチェックリストを使用できます。 多くの場合、問題を引き起こすのは複数の要因の組み合わせであるため、すべてのポイントを確認することが重要です。
不要な場合に、MRP の一部としてスケジューリングを実行する
工順は原価やレポートなどの生産管理の目的で使用されますが、MRP の際には考慮する必要がない場合があります。 場合によっては、品目に対して標準生産リードタイムが指定されていれば、計画には十分なことがあります。 工順のスケジューリングを無効にするには、能力タイム フェンスをゼロに設定します。 スケジュールを作成する場合は、MRP の補充タイム フェンスのすべての範囲について、工順を考慮する必要がないことがあるため、能力タイム フェンスを慎重に設定する必要があります。
注文が MRP 期間中にスケジューリングされていない場合は、計画オーダーが確定されたときにスケジューリングする必要があることに注意してください。 つまり、確定プロセスに時間がかかるため、提案された計画オーダーの確定数によっては、MRP 中のパフォーマンスの向上が確定時に失われる可能性があります。
不要な行程での工順
工順を設計する際には、実際の生産におけるすべてのステップを正確にモデル化したくなります。 これは場合によっては便利ですが、エンジンが処理する必要のあるモデルが大きくなり (ジョブと制約の両方の観点から)、ジョブの挿入と更新および確保済能力のためにより多くの SQL ステートメントが実行されるため、パフォーマンスには良くありません。 また、最終的にジョブの進捗状況を報告する必要があるというダウンストリームの影響があります。これは、自動転記によって軽減できます。 データが何も使用されていない場合は、不要な負荷が生じます。
スケジューリング (通常はボトルネック リソース) や原価計算の目的で厳密に必要な行程のみを作成することをお勧めします。 または、多数の小さい別個の工程を 1 つの大きな工程にグループ化して、プロセスのより大きな部分を表すようにする必要があります。
工程に適用可能な多くのリソース
工程に適用可能なリソースの数は、関連行程に設定されているリソース要件によって決まります。 要件は、特定の (個別の) リソースに対してであることも、リソース グループまたは機能のリソースのメンバーシップに基づいていることもあります。
有限能力を使用してスケジューリングを行わず、すべての適用可能なリソースとの同じカレンダーと効率が同じである場合、スケジューリング エンジンは、適用可能なリソースをすべて試して、他のリソースよりも「より良い」リソースがあるかを確認した後で、工程に対して常に同じリソースを選択します。 この場合、工順デザイン時に、常に特定のリソースが工程に割り当てられるようにすることによって、スケジューリングの負荷を大幅に軽減できます。
並行行程での工順
並行行程 (主/副) は、特定のタスクを実行するために機械とオペレータの両方が必要である場合などのシナリオをモデル化するための強力なツールですが、多くのパフォーマンスの問題の原因でもあります。 特定の個別リソースの要件が基本工程と二次工程の両方に割り当てられている場合、通常は問題になりません。 ただし、各工程に対して多くの使用可能なリソースがある場合は、スケジューリングに非常に複雑な計算が必要になります。
並行行程を使用する代わりに、ペアを「仮想」リソースとしてモデル化することもできます (これにより、工程で常に実行されるチームを表すことができます)。または、ボトルネックを表していない場合は、いずれかの行程をモデル化しません。
リソースの数量が 1 より高い工順
行程に必要なリソースの数量が 1 より大きい場合、複数の並列ジョブがエンジンに送信されるため、基本行程/二次行程を使用する場合と実質的に同じ結果になります。 ただし、この場合、数量が 1 を超えると行程に複数のリソースが適用可能である必要があるため、特定のリソース割り当てを使用できません。
リソースの読み込み数量が 1 より大きい二次工程は、基本工程の各リソースに対して二次リソースの指定が必要であることを意味します。 たとえば、基本工程のリソースの数量が 2 に設定され、その二次工程のリソースの数量が 3 に設定されている場合、二次工程に対して合計 6 個のリソースが必要です。
有限能力の過度な使用
有限能力を使用するには、エンジンがデータベースから能力情報を読み込む必要があり、特にリソースが最大能力近くまで予約されている環境ではソリューションを見つけるのが難しいため、計算のオーバーヘッドが発生する可能性があります。 そのため、リソースが有限能力を使用する必要があるかどうか、または予約超過になる可能性があるかを慎重に評価することが重要です。 有限能力のリソース間では、予約超過しないことの重要性に違いがある可能性があるため、「ボトルネック リソースの能力タイム フェンス」のプランの個別の値と組み合わせて、リソースのボトルネック オプションを使用することをお勧めします。 ボトルネックの概念を使用することにより、一般的な有限能力タイム フェンスを低くすることができます。
ハード リンクの設定
工順の標準リンク タイプはソフトです。これは、1 つの工程の終了時刻と次の工程の開始時刻の間に期間のギャップを許可されることを意味します。 このようにした場合、いずれかの行程で材料または能力が非常に長い間利用できない場合、生産がかなり長い間アイドル状態になり、進行中の作業が増えるという残念な結果が生じる可能性があります。 完了と開始が完全に揃う必要があるため、これはハード リンクでは発生しません。 ただし、ハード リンクを設定すると、2 つの工程リソースに対して作業時間と能力の交差を計算する必要があるため、スケジューリングの問題がより困難になります。 さらに並行行程が関係している場合は、計算にかなり時間がかかることになります。 2 つの工程のリソースにまったく重複しないカレンダーがある場合、問題は解決しません。
絶対に必要な場合にのみハード リンクを使用し、工順の各工程に必要かどうかを慎重に検討することをお勧めします。
ハード リンクを適用せずに進行中の作業を減らすための秘訣は、2 回目のパスで逆方向に変更して注文を 2 回スケジュールすることです。 最初のスケジュールが配送日から逆方向に実行された場合、2 番目のスケジュールは開始予定日から前方向に実行する必要があります。 これにより、ジョブが可能な限り圧縮され、進行中の作業が最小化されます。
リソースごとの個別のカレンダー
スケジューリング エンジンのデータの主要なソースの 1 つにカレンダー情報があります。これは、データベースからの読み込みにコストがかかる場合があります。 カレンダーはテンプレートに基づいて生成されるため、リソースごとにカレンダーを生成し、リソースにダウンタイムやその他の問題がある場合に、このカレンダーの情報を調整したくなります。 しかし、これを行うと、リソースごとに新しいデータを要求する必要があり、パフォーマンスの問題の大きな原因となる可能性があるため、カレンダー データをキャッシュするエンジンの機能が大幅に制限されます。 代わりに、リソース間で可能な限りカレンダーを再利用し、一定期間に異なるカレンダー ID を割り当てることでダウンタイムの変更を制御することをお勧めします。
1 カレンダー日あたりの最大作業タイム スロット数
エンジンはタイム スロットを 1 つずつ調べて能力を確認することで動作するため、1 カレンダー日あたりのタイム スロットの数を最小限に抑えることが有益です。 たとえば、労働者が 1 時間ごとに 5 分の休憩をとることを結果のスケジュールに反映することが重要かどうかを検討することによって行うことができます。
大規模スケジューリング タイムアウト (または、なし)
スケジューリング エンジンのパフォーマンスは、スケジューリング パラメータ ページのパラメータを使用して最適化できます。 スケジューリング タイムアウトの有効化およびスケジューリングの最適化タイムアウトの有効化設定は、常にはいに設定されている必要があります。 いいえに設定すると、多数のオプションを含む実行不可能な工順が作成された場合、スケジューリングが無限に実行される可能性があります。
1 シーケンスあたりの最大スケジューリング タイムの値は、単一のシーケンスに対するソリューションを検索するために費やす最大秒数を制御します (ほとんどの場合、1 シーケンスは単一の注文に対応します)。 ここで使用する値は、工順の複雑さや有限能力などの設定に大きく異なりますが、最大約 30 秒が適切な出発点になります。
最適化の試行タイムアウトの値は、最初に検出されたものよりも優れたソリューションを見つけるために使用できる最大秒数を制御します。 これは、さまざまな組み合わせをテストする必要がある並行行程を使用している工順にのみ影響します。
メモ
タイムアウトに設定された値は、リリースされた製造オーダーと MRP の一部としての計画オーダーのスケジューリングの両方に適用されます。 その結果、非常に高い値を設定すると、計画製造オーダーが多数ある計画を実行するときに、MRP の実行時間が大幅に増加する可能性があります。