AGVのトラブルシューティング

このトピックでは、一般的なAGV問題のトラブルシューティングに関する提案を示します。

AGVルーティングアクセシビリティの表示

ナビゲーションエラーが発生した場合は、AGVシステム内のコントロールポイントに関するルーティングアクセシビリティ情報を表示できます。これにより、ナビゲーションエラーのトラブルシューティングが容易になります。そのためには、次の手順を実行します。

  1. タスク実行者がパスを見つけられない目的地コントロールポイントを探します。上のスクリーンショットの例では、Source1に接続されたコントロールポイントです。
  2. そのコントロールポイントを右クリックして、［AGVﾙｰﾃｨﾝｸﾞｱｸｾｼﾋﾞﾘﾃｨを表示］を選択します。

さまざまなパス転送が青色で強調表示されます。これらは、目標コントロールポイントに到達可能なネットワーク上のポイントです。

タスク実行者がコントロールポイントに到達できない場合は、周囲のパス転送が青色になりません。その場合は、そのタスク実行者から目的地までの想定されるパスをたどることができます。転送が黒色から青色に変化するポイントは、タスク実行者が目的地に到達できないようなパスリンクが切れているポイントです。

ルーティングテーブル情報の取得

さまざまなコントロールポイントやパス転送の上にカーソルを移動することもできます。これにより、カーソルが置かれたポイントから目的のコントロールポイントまでの移動に関するルートコスト情報が表示されます。

表示されたテキストの各行は、ルーティングテーブル内の1つのエントリを表します。状況に応じて異なるルートが必要になるため、AGVシステムは、これらの複数のルーティングテーブルを計算する必要があります。たとえば、ロードされた場合と空の場合では、AGVの速度プロファイルが異なります。その結果、最短のルートではなく最速のルートを探すようにAGVネットワークを構成した場合は、AGVが空の場合とロードされた場合で異なるルートを辿る可能性があります。一意のルートのそれぞれを個別に計算して格納する必要があります。

AGVシステムは、シミュレーションの実行で必要とされるルートを動的に計算してキャッシュします。これは、パスポイントの上にカーソルを移動したときに表示されるルートコストエントリの数がシミュレーションの進行に伴って増加する可能性があることを意味します。

各ルーティングテーブルのエントリには、そのテーブル用、目的地まで移動するための計算されたコスト用、および「次のルール」用のタプルキーが表示されます。ここで、次のルールとは、目的地に辿り着くために今のポイントの次に移動する場所を定義するルールです。

パス転送の上にカーソルを移動すると、エントリごとに、ルーティングテーブルのエントリが関連付けられているパスも表示されます。パス転送は実際には2つの「側面」があるため、ルーティングテーブル内に2つのエントリがあります。1つは、AGVが1つのパスを移動して辿り着く場所を決定し、もう1つは、AGVがもう1つのパスを移動して辿り着く場所を決定します。このことは、ルール情報を調べるときに最も重要です。nextルールは、特定のパス上にいるときに、AGVは、目的地に辿り着くためにそのパス上にい続けなければならないことを意味します。ルールがtnextの場合は、AGVがもう1つのパスを移動して目的地に辿り着く必要があることを意味します。

パスリンクの更新

モデルの構築過程で、AGVパスの近接へのリンクが失われたり、正しく作成されなかったりします。これが、前述したナビゲーションエラーにつながる可能性があります。これらのリンクは、パスの右クリックメニューを通して手動で更新できます。ナビゲーションがブロックされているポイントを発見したら、パスを右クリックして、そのパスリンクを更新できます。

これにより、ネットワークでそのパスと他のパス（もしあれば）のジオメトリが再分析され、そのパスとその近接パスが再リンクされるため、AGVシステムがAGVを目的地に正しくルーティングすることができます。

AGV集積動作のトラブルシューティング

多くのユーザーは、この集積オプションを自らの課題の完璧な解決策と考えるかもしれません。確かに、集積によって多くのシミュレーションシナリオが容易になるものの、その一方で、新たな複雑さや潜在的な問題が生まれるのも事実です。これは、集積を使用すべきではない、という意味ではありません。発生する大半の問題は、適切なノウハウで簡単に解消できます。むしろ、集積を使用するかどうかを判断する前に、集積の仕組みを十分に理解すべきです。

集積の使用に伴う主な複雑さは、新しい割り当て方式にあります。この方式は、コントロールポイントとコントロールエリアに使用される標準の割り当てロジックとは異なりますが、標準の割り当てロジックとともに使用されます。そのため、状況によっては、これら2つの割り当て方式が互いに「競合」し、システムのデッドロックを引き起こすことがあります。この問題は特に、交点が接近したエリアで発生する確率が高く、こうしたエリアでは、コントロールエリアを使用して相互にトラフィックが排除されます。

問題となる状況の例を次の図に示します。

この状況では、AGV_7はコントロールエリアの後の交点を割り当てたものの、コントロールエリア自体はまだ割り当てていません。この場合、画面下中央のAGV、AGV_9が先にコントロールエリアを割り当てるため、深刻な問題が発生します。AGV_7はAGV_9が所有しているコントロールエリアを割り当てることができず、AGV_9はAGV_7が所有している交点を割り当てることができないため、2台のAGV間でデッドロックが発生します。

前述のように、この状況は、コントロールエリアの割り当てと集積パスの交点の割り当てという2つの異なる割り当て方式が共存するために発生します。AGVは、コントロールエリアの割り当てを、前のコントロールポイントに到着した時点で行います。割り当てはオールオアナッシング方式です。つまり、AGVは、最も近いコントロールポイントまで進んだ後、パス上の次のコントロールポイントだけでなく、そこに至るまでのコントロールエリアもすべて割り当てます。そのため、AGVがコントロールエリアを割り当てるタイミングは、そこに至るまでに存在するコントロールポイントの位置に基づきます。

一方、集積パスの交点の割り当ては、交点の位置と、［AGVﾈｯﾄﾜｰｸﾌﾟﾛﾊﾟﾃｨ］の［集積ﾀｲﾌﾟ］の設定に基づいて決まります。［ｵﾝﾊﾟｽﾛﾝｸﾞ］設定にデフォルトを使用する場合、上記の状況のAGV_7は、交点を割り当てることができなければ、交点から少なくとも1メートル手前で前縁部を停止できなければなりません。これにより、AGVが交点の割り当てを試みる地点が決まります。

この状況例でAGV_7が先に交点を割り当てるのは、コントロールポイントがコントロールエリアの極めて近くにあることが原因です。AGV_7が交点を割り当てなければならない地点は、コントロールエリアを割り当てなければならない地点より手前に存在します。一方、AGV_9のコントロールポイントは、コントロールエリアから少し離れた位置にあるため、交点の割り当てより前にコントロールエリアを割り当てます。そのため、デッドロックが発生します。

解決策

このような問題に遭遇した場合、主に2つの解決策を試すことができます。第1の解決策は、交点が接近したエリアに特化した集積タイプを作成することです。この集積タイプでは、コントロールエリアを常に交点より手前に割り当てます。まず、［AGVﾈｯﾄﾜｰｸﾌﾟﾛﾊﾟﾃｨ］で新しい集積タイプを作成します。次に、［交差点の停止地点］の基準をAGVの中央に置き、［距離］を0に設定します。これは、交点を割り当てることができないAGVが、交点の手前0メートルの地点で中心部を停止しなければならないことを意味します。この設定を行えば、この狭いエリアでは、すべてのパスがこの集積タイプを使用します。

第2の解決策は、こうした接近したエリアで集積を使用しないことです。交点を通る各パスに対して、集積設定を［集積なし］にするだけです。これにより、コントロールエリアが、エリア内で相互排除を行う唯一の要素となります。正しい割り当て順序を気にする必要はありません。ここで、コントロールエリアの割り当て解除が早すぎないようにしたいと仮定します。コントロールエリアの割り当て解除を行う前に、前方にある集積パスの少なくとも最初の交点は割り当てておきたいものです。これは、それほど難しくありません。まだ実行していなければ、コントロールエリアの割り当て解除タイプの割り当て解除距離を長くします。あるいは、コントロールポイントを次の集積パスの開始地点に配置し、コントロールエリアの割り当て解除タイプを［次のｺﾝﾄﾛｰﾙﾎﾟｲﾝﾄで割り当て解除］に設定します。

一般的な経験則では、集積は、比較的交点が少なく、セクションの長いパスを持つモデルエリアで正しく機能します。一方、多くの交点が接近しているエリアでは、集積をオフにし、コントロールポイントでエリアを取り囲み、コントロールエリアで内部のトラフィックを制限する方が、簡単で、問題も少なくなります。