走行台車システム
【課題】
多数の走行台車に高速で指令を送信できるようにして、指令の送信遅れに伴う制御遅れを小さくする。
【構成】
システムサーバとアクセスポイントとを地上ＬＡＮを介して接続し、前記アクセスポイントから複数台の走行台車へ制御周期毎に指令を無線で送信し、複数台の走行台車からアクセスポイントへ前記制御周期毎に報告を無線で送信する。アクセスポイントは、アクセスポイント用時間帯に、送信権を確認するための信号を走行台車との間で交換せずに、指令を送信する。走行台車は、台車用時間帯に、送信権を確認するための信号を他の走行台車との間で交換した上で報告を送信する。
多数の走行台車に高速で指令を送信できるようにして、指令の送信遅れに伴う制御遅れを小さくする。
【構成】
システムサーバとアクセスポイントとを地上ＬＡＮを介して接続し、前記アクセスポイントから複数台の走行台車へ制御周期毎に指令を無線で送信し、複数台の走行台車からアクセスポイントへ前記制御周期毎に報告を無線で送信する。アクセスポイントは、アクセスポイント用時間帯に、送信権を確認するための信号を走行台車との間で交換せずに、指令を送信する。走行台車は、台車用時間帯に、送信権を確認するための信号を他の走行台車との間で交換した上で報告を送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は走行台車システムに関し、特に多数の走行台車が無線ＬＡＮを介してシステムサーバにより制御されるシステムに関する。
【背景技術】
【０００２】
出願人は、天井走行車等の多数の走行台車を、地上側のシステムサーバにより制御するシステムを提案した（特許文献１：JP2008-150135A）。このシステムでは、0.1s等の制御周期毎に、システムサーバが走行台車に目標位置等を指令し、走行台車に実行させる。走行台車とシステムサーバとが通信するには、無線ＬＡＮが適している。このシステムでは、無線ＬＡＮのために、システムサーバから走行台車への指令が遅れず、かつ走行台車からシステムサーバへの報告が遅れないことが重要である。指令あるいは報告が遅れると、システムサーバは走行台車をリアルタイムに制御できなくなるため、走行台車の速度等を小さくする必要がある。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】JP2008-150135A
【発明の概要】
【発明が解決しようとする課題】
【０００４】
この発明の課題は、多数の走行台車に高速で指令を送信できるようにして、指令の送信遅れに伴う制御遅れを小さくすることにある。
この発明の追加の課題は、多数の走行台車が短時間で報告できるようにして、報告の遅れに伴う制御遅れを短くすることにある。
この発明の追加の課題は、同じタイムスロット内に送信しようとする走行台車が複数有っても、送信が失敗しないようにすることにある。
【課題を解決するための手段】
【０００５】
この発明の走行台車システムは、
システムサーバとアクセスポイントとを地上ＬＡＮを介して接続し、前記アクセスポイントから複数台の走行台車へ制御周期毎に指令を無線で送信し、複数台の走行台車からアクセスポイントへ前記制御周期毎に報告を無線で送信するシステムであって、
前記制御周期中に、アクセスポイントからの送信専用で、走行台車からの報告を認めないアクセスポイント用時間帯と、走行台車からアクセスポイントへ報告するための台車用時間帯とを設け、
アクセスポイントは、アクセスポイント用時間帯に、送信権を確認するための信号を走行台車との間で交換せずに、指令を送信するための手段を備え、
走行台車は、台車用時間帯に、送信権を確認するための信号を他の走行台車との間で交換した上で、前記報告を送信するための送信手段を備えていることを特徴とする。
【０００６】
この発明では、アクセスポイントからの指令と走行台車からの報告とが衝突すること、即ち複数のパケットが同時に送信されて受信不能になること、がない。またアクセスポイントは、専用の時間帯に指令を送信するので、RTS（送信する旨のメッセージ）あるいはCTS（受信準備が完了した旨のメッセージ）等の、送信権を確認するための信号を交換する必要がない。従って多数の走行台車に高速で指令を送信でき、指令の送信遅れに伴う制御遅れを小さくできる。
【０００７】
好ましくは、台車用時間帯を複数のタイムスロットに分割すると共に、走行台車は複数のタイムスロットから１個をランダムに選択するための選択手段を備え、前記送信手段により選択したタイムスロット中に報告を送信する。このようにすると、１個のタイムスロット内で複数の走行台車からの報告が衝突する確率を小さくできる。またバックオフアルゴリズムのように、待時間の間継続して他の端末からのキャリアを検出しないことを条件とするのではないので、どの走行台車も送信しない時間が長くならない。従って多数の走行台車が短時間で報告でき、報告の遅れに伴う制御遅れを短くできる。
【０００８】
特に好ましくは、走行台車は、選択したタイムスロットが到来した後、さらに待機する待時間をランダムに定めるための手段を備えて、前記待時間経過後に前記送信手段により報告を送信する。即ち、１個のタイムスロット内に送信しようとする走行台車の数は僅かなので、僅かな数の走行台車間の競合を解消すればよい。そのためには既存のバックオフアルゴリズム等で十分対応できる。
【０００９】
なおバックオフアルゴリズムを用いず、例えば台車用時間帯を1024タイムスロットなどの、台車数に比べて充分多いスロットに分割しても良い。そして10ビットのタイムスロットデータの下位８ビットを有効とし、有効なタイムスロットが到来し、かつその時点でキャリアを検出していなければ、送信するようにしても良い。タイムスロットの数は充分多いので、同じタイムスロットに送信しようとする走行台車の数は僅かで、パケットの衝突は少ない。ここで、タイムスロットが到来した時点でキャリアを検出している場合、キャリアを検出しなくなるまで待って送信を開始するようにしたとする。するとキャリアを検出しなくなるまでの間に、複数の台車のタイムスロットが到来し、同時に送信を開始する可能性がある。そこでタイムスロットが到来した時点でキャリアを検出していると、次の自己のタイムスロットが到来するまで待機することが好ましい。１０ビット中下位８ビットを有効とすると、送信のチャンスは４回である。ただしこの手法では、同じ台車用時間帯内に全ての走行台車が送信できる確率は、複数のタイムスロットとバックオフアルゴリズムの組み合わせよりもやや低い。
【図面の簡単な説明】
【００１０】
【図１】実施例の走行台車システムのレイアウトを示す平面図
【図２】実施例でのアクセスポイントの配置と通信チャネルとを示す平面図
【図３】実施例での、走行台車、アクセスポイント、モーションコントローラ、及びシステムサーバの関係を示すブロック図
【図４】システムサーバでの処理を示すフローチャート
【図５】走行台車での処理を示すフローチャート
【図６】走行台車でのローミングに関する処理を示すフローチャート
【図７】走行台車がシステムサーバからの指令を受信できなかった際の、フェイルセーフ機構を示すフローチャート
【図８】システムサーバが走行台車からの報告を受信できなかった際の、フェイルセーフ機構を示すフローチャート
【図９】走行台車／システムサーバ間の通信のタイミングと、処理のタイミングとを示す図
【図１０】システムサーバ／走行台車間の通信のタイミングを示す図で、1)はシステムサーバでの処理を示し、2)はモーションコントローラでの処理を、3),5)はアクセスポイントでの処理を、4),6)は走行台車群での処理を示し、7)は無線ＬＡＮの割り当てを示す。
【図１１】アクセスポイントから走行台車への通信を示す図
【図１２】走行台車からアクセスポイントへの通信を示す図
【図１３】走行台車からアクセスポイントへの送信アルゴリズムを示すフローチャート
【図１４】台車からの送信が輻輳することを防止するための機構を示す図
【発明を実施するための形態】
【００１１】
以下に本発明を実施するための最適実施例を示す。この発明の範囲は、特許請求の範囲の記載に基づき、明細書の記載とこの分野での周知技術とを参酌し、当業者の理解に従って定められるべきである。
【実施例】
【００１２】
図１〜図１４に、実施例の走行台車システム２を示す。図１はシステム２のレイアウトを示し、４はインターベイルートで、複数のイントラベイルート６間を接続し、これらのルート４，６の全体を１０〜５０個程度のエリア１０に分割し、エリア１０毎にアクセスポイント８を設ける。エリア１０はアクセスポイント８の通信能力に比べて狭くし、具体的にはルート４，６の任意の地点で、走行台車１２が少なくとも２個のアクセスポイント８と通信できるようにする。なお退避区間、メンテナンス区間などの、物品を搬送する通常の走行ルートから外れた区間では、１個のアクセスポイント８とのみ通信できるようにしても良い。
【００１３】
１２は走行台車で、ここでは天井走行車とするが、地上を有軌道で走行する有軌道台車、あるいは地上を無軌道で走行する無人搬送車などでもよい。１４は地上ＬＡＮで、アクセスポイント８とモーションコントローラ１６並びにシステムサーバ１８を接続し、システムサーバ１８は、他のＬＡＮもしくは地上ＬＡＮ１４により、上位サーバ２０に接続されている。上位サーバ２０はシステムサーバ１８に対して搬送などの要求を行い、システムサーバ１８は複数の走行台車１２の位置、分岐方向、速度などの状態を記憶し、少なくとも位置を記憶する。システムサーバ１８は、例えば0.1sの制御周期、より一般的には0.01s〜0.3sの制御周期毎に、モーションコントローラ１６とアクセスポイント８とを介し、走行台車１２に指令を送信する。指令の内容は、次の制御周期での目標位置と分岐の方向、移載に関する指令などであり、これ以外に走行台車１２の目標速度も指令しても良い。
【００１４】
図２は、走行台車システム２でのエリア１０とアクセスポイント８との配置を示す。前記のように、走行ルート上の全地点で、走行台車は複数のアクセスポイント８と通信可能である。なお物品を搬送する区間である通常走行ルート上でのみ、複数のアクセスポイント８と通信可能にしても良い。すると１個のアクセスポイント８がブレイクダウンしても、走行台車は走行を続行できる。実施例ではエリア１０は例えば１辺あるいは直径が30ｍ程度で、走行台車の台数は例えば上限が500台程度で、アクセスポイント８の個数は20程度である。アクセスポイント８当たりの走行台車１２の台数は、上限が60台程度である。モーションコントローラ１６は走行台車システム２の全体に対して１台設けるが、システムの規模が大きい場合、モーションコントローラ１６を複数台設けても良い。
【００１５】
エリア１０毎に走行台車との通信チャネル、即ち使用する周波数帯等を変化させ、例えば４種類のチャネルｆa〜ｆdを設ける。このようにすると、隣接するエリアの間で必ずチャネルが変化するように、エリア１０を配置できる。そしてエリア１０の境界位置と各エリアでのチャネルを、走行台車が記憶するマップに記載し、走行台車は絶対位置センサなどの適宜のセンサで現在位置を確認しながら走行する。従って走行台車１２は、どのエリア１０を走行しているかと、用いるべきチャネルの種類とを知ることができる。またエリアの境界に接近してきたことと、次のエリアのチャネルをマップから求めることができる。
【００１６】
図３に走行台車１２から上位サーバ２０までの構成を示す。システムサーバ１８は時計２２を備え、この時計を走行台車システムの共通の基本時計とする。台車状態記憶部２４は走行台車１２の現在位置、速度、分岐の方向、移載に関するデータ、割付済みの指令などの台車の状態を記憶し、指令作成部２６は走行台車毎に次の制御周期の終わりでの目標位置と分岐方向、移載に関するデータなどの指令を作成する。
【００１７】
アクセスポイント８は通信可能範囲内の走行台車１２と通信し、通信は100ms(100m秒)から成る制御周期単位で行い、制御周期の例えば最初にビーコンを送出して、アクセスポイント８が使用するチャネルなどを通知する。制御周期の最初の30ms間にアクセスポイント８から走行台車１２への指令を送信し、次の40ms間に走行台車１２からの報告などを受信し、最後の30msは予備とする。モーションコントローラ１６は例えば２０台のアクセスポイント８へ、システムサーバ１８からの指令を送信し、アクセスポイント８からの報告をまとめてシステムサーバ１８へ送信する。
【００１８】
走行台車１２は、アンテナ２８と通信部３０により、アクセスポイント８と通信し、指令を主制御部３２へ引き渡し、主制御部３２からシステムサーバ１８への報告（送信データ）を受け取って送信する。また主制御部３２は走行ルートのマップを記憶し、新たなエリアとの境界に接近すると、次のエリアのアクセスポイントからのビーコンを検出すること及びビーコン検出に用いるチャネルを通信部３０へ入力する。
【００１９】
主制御部３２は走行系３４と移載系３５，並びにセンサ群３６を制御する。走行系３４では、図示しない走行モータをサーボ制御し、システムサーバ１８から受信した目標位置に従って走行し、分岐する場合、システムサーバ１８から指定された分岐方向に分岐する。移載系３５は、昇降台を昇降させる昇降モータと、昇降台等を横移動させる横送りモータ、並びにこれらを鉛直軸回りに回動させて物品の向きを整える回動モータなどを備えている。そして主制御部３２はシステムサーバ１８から受信した移載の指令に従って、移載系３５を駆動する。センサ群３６は走行台車の絶対位置を検出する絶対位置センサ、先行台車を検出する距離センサ、バッファあるいはロードポートなどでの先入品の有無を検出する先入品センサ、さらに物品に取り付けたRFIDなどを読み取るRFIDリーダなどから成る。主制御部３２はセンサ群３６により周囲の状態を検出し、必要に応じてそれらのデータをシステムサーバ１８へ送信する。
【００２０】
通信部３０は電波強度検出部４０を備え、アクセスポイント８からの電波強度を求める。ローミング部４１は、新たなアクセスポイント８へのローミングを制御する。送信制御部４２はアクセスポイント８への送信を制御し、乱数発生部を備えて、送信のための自己の割り当て時刻を乱数（例えば0〜39の40段階で、好ましくは8〜64段階）で発生させ、バックオフ時間を乱数（0〜15の例えば16段階）で発生させる。時計４３は、システムサーバ１８の時計２２に合わせた時計で、時刻は例えば１ms単位で、図示しないクロックにより時刻をカウントする。時計校正部４４は、システムサーバ１８からのタイムスタンプに従い、時計４３の時刻データを校正する。
【００２１】
図４にシステムサーバ１８での処理を示す。システム全体で時計を合わせるため、タイムスタンプをシステムサーバが作成し、モーションコントローラとアクセスポイントを介して、制御周期の最初の30msの間に、指令と共に走行台車に送信することを考える。するとシステムサーバからアクセスポイントまでの送信時間を無視しても、タイムスタンプの作成から走行台車への送信までに、最大30msの誤差が生じる。このため数100台の走行台車に対し、制御周期毎に意味のあるタイムスタンプを送信することは困難である。そこでシステムサーバは最大500台程度の走行台車のうち制御周期毎に10台程度、例えば5〜50台を選択し、制御周期毎に選択した走行台車のみに対して、時計を校正する。制御周期を0.1s、走行台車を500台とすると、制御周期毎に１０台ずつ選択することにより、例えば5s毎に正確なタイムスタンプを送信できる。具体的には、選択した走行台車への指令のパケットに時刻データ（タイムスタンプ）を書き込み、他の走行台車に対しては時刻データを無効としておく。そして選択した走行台車への指令のパケットが、制御周期の最初に走行台車へ送信されるように、モーションコントローラへのパケットの送信順序を制御する。
【００２２】
システムサーバは管理下の走行台車の状態を記憶し、制御周期毎に走行台車の位置などの台車の状態報告を受信し、報告に従って台車の状態データを更新する。なお台車の状態の受信に失敗した場合、該当台車に関して状態データを更新しない。台車への指令プロセスでは、台車の状態データと上位サーバからの搬送の要求に従い、台車への指令を作成する。作成した指令をモーションコントローラとアクセスポイントを介して制御周期毎に走行台車へ送信する。
【００２３】
図５，図６に走行台車側のプロセスを示す。時計プロセスでは走行台車は自己のクロックを用いて１ms毎に時計を進める。そしてアクセスポイントからの指令中にタイムスタンプが付加されている場合、受信した時刻データ（タイムスタンプ）と、自己の時計での時刻データとの重み付き平均で時計を校正する。自己の時計の重みとシステムサーバの時計の重みの比を、例えば1:1〜5:1とする。このようにすると５s毎にタイムスタンプを受信するものとして、10s〜40s程度の時定数で走行台車の時計が校正される。走行台車の時計を１回のタイムスタンプでは部分的にしか校正しないのは、アクセスポイントから走行台車へのタイムスタンプの送信遅れなどによる影響を小さくするためである。制御周期のどの時点でアクセスポイントが送信データが送信するかは毎回変動するが、走行台車の時計を少しずつ書き換えると、アクセスポイントからの送信遅れの影響などを小さくできる。
【００２４】
指令の受信プロセスでは、アクセスポイントから指令を受信すると、受信確認パケットを返信し、指令に従って次の制御周期での目標位置を更新する。なお指令及び報告の再送は例えば２回までとし、１制御周期で最初の送信を含めて３回までの送信を認める。そして仮に３回とも指令の受信に失敗した場合、目標位置等を更新しないので、走行台車は減速する。
【００２５】
走行台車からの送信プロセスは、制御周期の開始から30ms間待機し、この時点でシステムサーバへの状態報告パケットを作成する。全ての走行台車はシステムサーバの時計に合わせた時計を持っているので、制御周期の開始から同じ時間だけ経過した時点で一斉に状態報告パケットを作成する。走行台車はアクセスポイントへの送信に割り当てられた40msを例えば40分割し、このうち１msを自己の割り当て時間として、乱数により割り当て時間を選ぶ。そして割り当て時間が到来するまで待機し、割り当て時間に達すると、バックオフアルゴリズムでパケットの衝突を防止しながら、状態報告パケットを送信する。
【００２６】
図６に走行台車でのローミングの処理を示す。走行台車はマップ上の自己の位置を知っており、次に進入するエリアでのチャネルも知っている。そしてエリアの境界が近づく、もしくは通信中のアクセスポイントからの電波が弱くなると、ローミングを開始する。ローミングではマップから次に進入するエリアのチャネルを求め、そのチャネルでビーコンを検出する。なおビーコンは例えば制御周期の最初に送信される。そしてビーコンの電波強度が充分であればローミングし、強度が不足する場合、残る２チャンネルに対するローミングを試みる。システムが用いるチャネルが４種類に制限され、どのチャネルでローミングを試みるべきかがマップから分かるので、簡単にローミングできる。
【００２７】
走行ルートの各地点で２種類以上のチャネルで通信可能なので、アクセスポイントにトラブルが発生しても、他のアクセスポイントとの通信を維持できる。ローミングは例えば走行台車からアクセスポイントへの送信に割り当てられた時間帯に、プローブ要求をアクセスポイントへ送信し、アクセスポイントからプローブ許可を受信することにより完了する。なお状態報告パケットにプローブ要求を追加して送信しても良い。またプローブ要求を行わずに、走行台車から台車のID、目的地、搬送指令のID、現在位置、速度、分岐方向などの報告を送信し、アクセスポイントが新たな台車から報告を受けたことを確認することにより、ローミングを完了しても良い。
【００２８】
図７に、走行台車がシステムサーバからの指令の受信に失敗した際の、フェイルセーフ機構を示す。アクセスポイントが指令を送信しても走行台車からの確認が得られない場合、２回まで再送する。従って走行台車が指令の受信に失敗する確率は元々極めて小さい。それでも指令を受信できなかった場合、台車は前回の制御周期での目標位置に従って走行する。従って多くの場合、台車はオーバーランして減速する。制御周期は０.１s程度なので、走行台車の最大走行速度を４m/sとしても、走行台車がオーバーランする距離は最大で40cm程度である。なおシステムサーバは、この程度のオーバーランでは台車間の干渉が生じないように、車間距離を定めて目標位置を指令している。そして次の制御周期で指令の受信に成功すると、走行台車はサーバの制御下に戻ることができる。
【００２９】
図８に、システムサーバ側が走行台車からの報告を受信できなかった際のフェイルセーフ機構を示す。報告がアクセスポイントにより受信できなかった場合、台車は合計３回まで報告する。３回とも失敗した場合、サーバは前の制御周期での台車の位置などの状態を更新せずに記憶する。この結果、システムサーバのデータ上で、後行の走行台車との車間距離が縮まり、サーバは、後行の走行台車に対し干渉を回避するように目的位置を指令する。そして次の制御周期で台車の位置等を受信することができれば、台車をサーバによるフィードバック制御下に戻すことができる。
【００３０】
図９に、走行台車からシステムサーバへの報告と、システムサーバからの指令並びに走行台車による実行のタイミングを示す。制御周期は100msで、図の下部に時刻を示す。複数台の走行台車は一斉に、例えば30msの時点で、システムサーバへの報告を作成し、30ms〜70ms等の間に分散して指令を報告する。報告はアクセスポイントからモーションコントローラを介してシステムサーバへ送られ、システムサーバは次の制御周期（図の制御周期Ｎ）での指令を作成し、モーションコントローラからアクセスポイントへ指令を送信する。報告の転送からアクセスポイントへの指令の送信を70msから100msまでに処理する。アクセスポイントは次の制御周期Ｎの例えば最初の30ms間に走行台車に指令を送信し、走行台車は制御周期Ｎ＋１でその指令を実行する。なお制御周期の始まりと終わりを、走行台車が報告パケットを作成する時点から次の報告を作成する時点までとし、指令を受信すると直ちに指令の実行を開始してもよい。
【００３１】
図１０に、システムサーバと走行台車との通信のタイミングなどを示し、例えば１制御周期は100msで、このうち30msをアクセスポイントから走行台車への送信に、次の40msを走行台車からアクセスポイントへの通信に、残る30msを予備とする。そしてアクセスポイントは周期の最初の30msの間に最大60台程度の走行台車に指令を送信し、走行台車は40msの割り当て時間を40分割し、送信を開始する自己の割り当て時間を、例えば１msずつランダムに選択する。そしてこの１msの範囲で、バックオフアルゴリズムにより、走行台車間の送信パケットの衝突を防止する。
【００３２】
図１１にアクセスポイントから走行台車への送信の例を示し、最初にビーコンを送出し、続いて走行台車毎のデータを送信する。ビーコンの発生後、例えば30ms程度の時間はアクセスポイントからの送信に割り当てられた時間である。この間、RTS（送信を開始する旨のメッセージ），CTS（受信の準備ができた旨のメッセージ）などによる、パケットの衝突の防止制御は不要である。そして走行台車側は指令を受信すると、その都度ACK（受信確認のメッセージ）を送出する。図１１のD10,D20,D30などは、個別の走行台車毎の指令である。
【００３３】
図１２に、走行台車からアクセスポイントへの送信に割り当てた40msのうちの１タイムスロット（１ms）での処理を示す。なおこのタイムスロットを割り当て時間と呼ぶ。アクセスポイント当たりの走行台車の台数は最大で60台程度で、送信時間を40スロットに分割するので、１タイムスロット当たりの走行台車の台数は最大で平均約１.５で、考慮する必要があるのは１つのタイムスロットに５台程度の走行台車が通信する場合までである。例えば５台の台車が１つのタイムスロットを用いる確率は、平均値を1.5台として、１台の場合の約1／24である。１タイムスロット内で複数の走行台車が送信する場合、バックオフアルゴリズムで送信の順序を規制する。即ちタイムスロットが到来すると、各走行台車は0〜15の範囲で乱数を発生させ、キャリアが無い時間がDIFS（IEEE802.11で規定された待時間）とさらにバックオフ時間だけ続くと、RTS信号を送出する。バックオフアルゴリズムで用いる乱数を16通りとすると、２台の台車が同じバックオフ時間を持つ確率は僅かである。そしてRTSに対して、アクセスポイントからのCTSを受信できると、データの送信を開始し、アクセスポイントはデータを受信できると確認信号ACKを送出する。
【００３４】
図１３に走行台車からアクセスポイントへの送信制御を示す。送信に割り当てられた時間は40msで、自己の割り当て時間をランダムに１ms幅で選択する。そして自己の割り当て時間が到来するまで待機し、到来するとバックオフ時間をランダムに設定する。バックオフ時間の間継続してキャリアを検出しないとRTSを送信し、CTSを受信するとデータを送信する。続いて確認信号ACKを受信できると送信が終わる。ACKの受信まで進めない場合、バックオフ時間をランダムに再設定して再度トライする。なおパケットの衝突などがない場合、DIFSからACKまでの時間は、走行台車１台分の報告に対し、例えば400μs程度である。従って１タイムスロット当たり３台以上の走行台車が存在すると、１msの間に送信が終わらないことがある。この場合、未送信の走行台車は次のタイムスロットでも送信を続行する。そして次のタイムスロットを用いる予定の走行台車は、この間バックオフアルゴリズムにより送信を待機する。
【００３５】
図１４に実施例の送信アルゴリズムと、単なるバックオフアルゴリズムとの比較を示す。ここでは、１アクセスポイント当たり60台の走行台車が存在するとの状況で検討する。通常のバックオフアルゴリズムでは、送信までの待機時間は例えば0〜15の16区分で、16区分に60台の台車を収容すると、大部分の送信パケットが衝突し、再送回数が増す。再送回数を少なくするため、バックオフ時間の範囲を拡大すると、平均のバックオフ時間が増し、通信効率が低下する。
【００３６】
これに対して実施例では、40msの時間を１msずつに分割するので、１つの割り当て時間当たりの送信は平均して1.5回である。1.5回分の送信を衝突無しに制御すれば良いので、バックオフ時間を短くできる。また仮に１msの割り当て時間内に通信が完了しない場合でも、次の割り当て時間を引き続いて使うことができる。これらの結果、通信の成功率が増す。１つの割り当て時間内では、送信の衝突をバックオフアルゴリズムで回避するので、衝突とこれに伴う再送とを少なくできる。
【符号の説明】
【００３７】
２ 走行台車システム
４ インターベイルート
６ イントラベイルート
８ アクセスポイント
１０ エリア
１２ 走行台車
１４ 地上ＬＡＮ
１６ モーションコントローラ
１８ システムサーバ
２０ 上位サーバ
２２ 時計
２４ 台車状態記憶部
２６ 指令作成部
２８ アンテナ
３０ 通信部
３２ 主制御部
３４ 走行系
３５ 移載系
３６ センサ群
４０ 電波強度検出部
４１ ローミング部
４２ 送信制御部
４３ 時計
４４ 時計校正部
ｆa〜ｆd チャネル
【技術分野】
【０００１】
この発明は走行台車システムに関し、特に多数の走行台車が無線ＬＡＮを介してシステムサーバにより制御されるシステムに関する。
【背景技術】
【０００２】
出願人は、天井走行車等の多数の走行台車を、地上側のシステムサーバにより制御するシステムを提案した（特許文献１：JP2008-150135A）。このシステムでは、0.1s等の制御周期毎に、システムサーバが走行台車に目標位置等を指令し、走行台車に実行させる。走行台車とシステムサーバとが通信するには、無線ＬＡＮが適している。このシステムでは、無線ＬＡＮのために、システムサーバから走行台車への指令が遅れず、かつ走行台車からシステムサーバへの報告が遅れないことが重要である。指令あるいは報告が遅れると、システムサーバは走行台車をリアルタイムに制御できなくなるため、走行台車の速度等を小さくする必要がある。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】JP2008-150135A
【発明の概要】
【発明が解決しようとする課題】
【０００４】
この発明の課題は、多数の走行台車に高速で指令を送信できるようにして、指令の送信遅れに伴う制御遅れを小さくすることにある。
この発明の追加の課題は、多数の走行台車が短時間で報告できるようにして、報告の遅れに伴う制御遅れを短くすることにある。
この発明の追加の課題は、同じタイムスロット内に送信しようとする走行台車が複数有っても、送信が失敗しないようにすることにある。
【課題を解決するための手段】
【０００５】
この発明の走行台車システムは、
システムサーバとアクセスポイントとを地上ＬＡＮを介して接続し、前記アクセスポイントから複数台の走行台車へ制御周期毎に指令を無線で送信し、複数台の走行台車からアクセスポイントへ前記制御周期毎に報告を無線で送信するシステムであって、
前記制御周期中に、アクセスポイントからの送信専用で、走行台車からの報告を認めないアクセスポイント用時間帯と、走行台車からアクセスポイントへ報告するための台車用時間帯とを設け、
アクセスポイントは、アクセスポイント用時間帯に、送信権を確認するための信号を走行台車との間で交換せずに、指令を送信するための手段を備え、
走行台車は、台車用時間帯に、送信権を確認するための信号を他の走行台車との間で交換した上で、前記報告を送信するための送信手段を備えていることを特徴とする。
【０００６】
この発明では、アクセスポイントからの指令と走行台車からの報告とが衝突すること、即ち複数のパケットが同時に送信されて受信不能になること、がない。またアクセスポイントは、専用の時間帯に指令を送信するので、RTS（送信する旨のメッセージ）あるいはCTS（受信準備が完了した旨のメッセージ）等の、送信権を確認するための信号を交換する必要がない。従って多数の走行台車に高速で指令を送信でき、指令の送信遅れに伴う制御遅れを小さくできる。
【０００７】
好ましくは、台車用時間帯を複数のタイムスロットに分割すると共に、走行台車は複数のタイムスロットから１個をランダムに選択するための選択手段を備え、前記送信手段により選択したタイムスロット中に報告を送信する。このようにすると、１個のタイムスロット内で複数の走行台車からの報告が衝突する確率を小さくできる。またバックオフアルゴリズムのように、待時間の間継続して他の端末からのキャリアを検出しないことを条件とするのではないので、どの走行台車も送信しない時間が長くならない。従って多数の走行台車が短時間で報告でき、報告の遅れに伴う制御遅れを短くできる。
【０００８】
特に好ましくは、走行台車は、選択したタイムスロットが到来した後、さらに待機する待時間をランダムに定めるための手段を備えて、前記待時間経過後に前記送信手段により報告を送信する。即ち、１個のタイムスロット内に送信しようとする走行台車の数は僅かなので、僅かな数の走行台車間の競合を解消すればよい。そのためには既存のバックオフアルゴリズム等で十分対応できる。
【０００９】
なおバックオフアルゴリズムを用いず、例えば台車用時間帯を1024タイムスロットなどの、台車数に比べて充分多いスロットに分割しても良い。そして10ビットのタイムスロットデータの下位８ビットを有効とし、有効なタイムスロットが到来し、かつその時点でキャリアを検出していなければ、送信するようにしても良い。タイムスロットの数は充分多いので、同じタイムスロットに送信しようとする走行台車の数は僅かで、パケットの衝突は少ない。ここで、タイムスロットが到来した時点でキャリアを検出している場合、キャリアを検出しなくなるまで待って送信を開始するようにしたとする。するとキャリアを検出しなくなるまでの間に、複数の台車のタイムスロットが到来し、同時に送信を開始する可能性がある。そこでタイムスロットが到来した時点でキャリアを検出していると、次の自己のタイムスロットが到来するまで待機することが好ましい。１０ビット中下位８ビットを有効とすると、送信のチャンスは４回である。ただしこの手法では、同じ台車用時間帯内に全ての走行台車が送信できる確率は、複数のタイムスロットとバックオフアルゴリズムの組み合わせよりもやや低い。
【図面の簡単な説明】
【００１０】
【図１】実施例の走行台車システムのレイアウトを示す平面図
【図２】実施例でのアクセスポイントの配置と通信チャネルとを示す平面図
【図３】実施例での、走行台車、アクセスポイント、モーションコントローラ、及びシステムサーバの関係を示すブロック図
【図４】システムサーバでの処理を示すフローチャート
【図５】走行台車での処理を示すフローチャート
【図６】走行台車でのローミングに関する処理を示すフローチャート
【図７】走行台車がシステムサーバからの指令を受信できなかった際の、フェイルセーフ機構を示すフローチャート
【図８】システムサーバが走行台車からの報告を受信できなかった際の、フェイルセーフ機構を示すフローチャート
【図９】走行台車／システムサーバ間の通信のタイミングと、処理のタイミングとを示す図
【図１０】システムサーバ／走行台車間の通信のタイミングを示す図で、1)はシステムサーバでの処理を示し、2)はモーションコントローラでの処理を、3),5)はアクセスポイントでの処理を、4),6)は走行台車群での処理を示し、7)は無線ＬＡＮの割り当てを示す。
【図１１】アクセスポイントから走行台車への通信を示す図
【図１２】走行台車からアクセスポイントへの通信を示す図
【図１３】走行台車からアクセスポイントへの送信アルゴリズムを示すフローチャート
【図１４】台車からの送信が輻輳することを防止するための機構を示す図
【発明を実施するための形態】
【００１１】
以下に本発明を実施するための最適実施例を示す。この発明の範囲は、特許請求の範囲の記載に基づき、明細書の記載とこの分野での周知技術とを参酌し、当業者の理解に従って定められるべきである。
【実施例】
【００１２】
図１〜図１４に、実施例の走行台車システム２を示す。図１はシステム２のレイアウトを示し、４はインターベイルートで、複数のイントラベイルート６間を接続し、これらのルート４，６の全体を１０〜５０個程度のエリア１０に分割し、エリア１０毎にアクセスポイント８を設ける。エリア１０はアクセスポイント８の通信能力に比べて狭くし、具体的にはルート４，６の任意の地点で、走行台車１２が少なくとも２個のアクセスポイント８と通信できるようにする。なお退避区間、メンテナンス区間などの、物品を搬送する通常の走行ルートから外れた区間では、１個のアクセスポイント８とのみ通信できるようにしても良い。
【００１３】
１２は走行台車で、ここでは天井走行車とするが、地上を有軌道で走行する有軌道台車、あるいは地上を無軌道で走行する無人搬送車などでもよい。１４は地上ＬＡＮで、アクセスポイント８とモーションコントローラ１６並びにシステムサーバ１８を接続し、システムサーバ１８は、他のＬＡＮもしくは地上ＬＡＮ１４により、上位サーバ２０に接続されている。上位サーバ２０はシステムサーバ１８に対して搬送などの要求を行い、システムサーバ１８は複数の走行台車１２の位置、分岐方向、速度などの状態を記憶し、少なくとも位置を記憶する。システムサーバ１８は、例えば0.1sの制御周期、より一般的には0.01s〜0.3sの制御周期毎に、モーションコントローラ１６とアクセスポイント８とを介し、走行台車１２に指令を送信する。指令の内容は、次の制御周期での目標位置と分岐の方向、移載に関する指令などであり、これ以外に走行台車１２の目標速度も指令しても良い。
【００１４】
図２は、走行台車システム２でのエリア１０とアクセスポイント８との配置を示す。前記のように、走行ルート上の全地点で、走行台車は複数のアクセスポイント８と通信可能である。なお物品を搬送する区間である通常走行ルート上でのみ、複数のアクセスポイント８と通信可能にしても良い。すると１個のアクセスポイント８がブレイクダウンしても、走行台車は走行を続行できる。実施例ではエリア１０は例えば１辺あるいは直径が30ｍ程度で、走行台車の台数は例えば上限が500台程度で、アクセスポイント８の個数は20程度である。アクセスポイント８当たりの走行台車１２の台数は、上限が60台程度である。モーションコントローラ１６は走行台車システム２の全体に対して１台設けるが、システムの規模が大きい場合、モーションコントローラ１６を複数台設けても良い。
【００１５】
エリア１０毎に走行台車との通信チャネル、即ち使用する周波数帯等を変化させ、例えば４種類のチャネルｆa〜ｆdを設ける。このようにすると、隣接するエリアの間で必ずチャネルが変化するように、エリア１０を配置できる。そしてエリア１０の境界位置と各エリアでのチャネルを、走行台車が記憶するマップに記載し、走行台車は絶対位置センサなどの適宜のセンサで現在位置を確認しながら走行する。従って走行台車１２は、どのエリア１０を走行しているかと、用いるべきチャネルの種類とを知ることができる。またエリアの境界に接近してきたことと、次のエリアのチャネルをマップから求めることができる。
【００１６】
図３に走行台車１２から上位サーバ２０までの構成を示す。システムサーバ１８は時計２２を備え、この時計を走行台車システムの共通の基本時計とする。台車状態記憶部２４は走行台車１２の現在位置、速度、分岐の方向、移載に関するデータ、割付済みの指令などの台車の状態を記憶し、指令作成部２６は走行台車毎に次の制御周期の終わりでの目標位置と分岐方向、移載に関するデータなどの指令を作成する。
【００１７】
アクセスポイント８は通信可能範囲内の走行台車１２と通信し、通信は100ms(100m秒)から成る制御周期単位で行い、制御周期の例えば最初にビーコンを送出して、アクセスポイント８が使用するチャネルなどを通知する。制御周期の最初の30ms間にアクセスポイント８から走行台車１２への指令を送信し、次の40ms間に走行台車１２からの報告などを受信し、最後の30msは予備とする。モーションコントローラ１６は例えば２０台のアクセスポイント８へ、システムサーバ１８からの指令を送信し、アクセスポイント８からの報告をまとめてシステムサーバ１８へ送信する。
【００１８】
走行台車１２は、アンテナ２８と通信部３０により、アクセスポイント８と通信し、指令を主制御部３２へ引き渡し、主制御部３２からシステムサーバ１８への報告（送信データ）を受け取って送信する。また主制御部３２は走行ルートのマップを記憶し、新たなエリアとの境界に接近すると、次のエリアのアクセスポイントからのビーコンを検出すること及びビーコン検出に用いるチャネルを通信部３０へ入力する。
【００１９】
主制御部３２は走行系３４と移載系３５，並びにセンサ群３６を制御する。走行系３４では、図示しない走行モータをサーボ制御し、システムサーバ１８から受信した目標位置に従って走行し、分岐する場合、システムサーバ１８から指定された分岐方向に分岐する。移載系３５は、昇降台を昇降させる昇降モータと、昇降台等を横移動させる横送りモータ、並びにこれらを鉛直軸回りに回動させて物品の向きを整える回動モータなどを備えている。そして主制御部３２はシステムサーバ１８から受信した移載の指令に従って、移載系３５を駆動する。センサ群３６は走行台車の絶対位置を検出する絶対位置センサ、先行台車を検出する距離センサ、バッファあるいはロードポートなどでの先入品の有無を検出する先入品センサ、さらに物品に取り付けたRFIDなどを読み取るRFIDリーダなどから成る。主制御部３２はセンサ群３６により周囲の状態を検出し、必要に応じてそれらのデータをシステムサーバ１８へ送信する。
【００２０】
通信部３０は電波強度検出部４０を備え、アクセスポイント８からの電波強度を求める。ローミング部４１は、新たなアクセスポイント８へのローミングを制御する。送信制御部４２はアクセスポイント８への送信を制御し、乱数発生部を備えて、送信のための自己の割り当て時刻を乱数（例えば0〜39の40段階で、好ましくは8〜64段階）で発生させ、バックオフ時間を乱数（0〜15の例えば16段階）で発生させる。時計４３は、システムサーバ１８の時計２２に合わせた時計で、時刻は例えば１ms単位で、図示しないクロックにより時刻をカウントする。時計校正部４４は、システムサーバ１８からのタイムスタンプに従い、時計４３の時刻データを校正する。
【００２１】
図４にシステムサーバ１８での処理を示す。システム全体で時計を合わせるため、タイムスタンプをシステムサーバが作成し、モーションコントローラとアクセスポイントを介して、制御周期の最初の30msの間に、指令と共に走行台車に送信することを考える。するとシステムサーバからアクセスポイントまでの送信時間を無視しても、タイムスタンプの作成から走行台車への送信までに、最大30msの誤差が生じる。このため数100台の走行台車に対し、制御周期毎に意味のあるタイムスタンプを送信することは困難である。そこでシステムサーバは最大500台程度の走行台車のうち制御周期毎に10台程度、例えば5〜50台を選択し、制御周期毎に選択した走行台車のみに対して、時計を校正する。制御周期を0.1s、走行台車を500台とすると、制御周期毎に１０台ずつ選択することにより、例えば5s毎に正確なタイムスタンプを送信できる。具体的には、選択した走行台車への指令のパケットに時刻データ（タイムスタンプ）を書き込み、他の走行台車に対しては時刻データを無効としておく。そして選択した走行台車への指令のパケットが、制御周期の最初に走行台車へ送信されるように、モーションコントローラへのパケットの送信順序を制御する。
【００２２】
システムサーバは管理下の走行台車の状態を記憶し、制御周期毎に走行台車の位置などの台車の状態報告を受信し、報告に従って台車の状態データを更新する。なお台車の状態の受信に失敗した場合、該当台車に関して状態データを更新しない。台車への指令プロセスでは、台車の状態データと上位サーバからの搬送の要求に従い、台車への指令を作成する。作成した指令をモーションコントローラとアクセスポイントを介して制御周期毎に走行台車へ送信する。
【００２３】
図５，図６に走行台車側のプロセスを示す。時計プロセスでは走行台車は自己のクロックを用いて１ms毎に時計を進める。そしてアクセスポイントからの指令中にタイムスタンプが付加されている場合、受信した時刻データ（タイムスタンプ）と、自己の時計での時刻データとの重み付き平均で時計を校正する。自己の時計の重みとシステムサーバの時計の重みの比を、例えば1:1〜5:1とする。このようにすると５s毎にタイムスタンプを受信するものとして、10s〜40s程度の時定数で走行台車の時計が校正される。走行台車の時計を１回のタイムスタンプでは部分的にしか校正しないのは、アクセスポイントから走行台車へのタイムスタンプの送信遅れなどによる影響を小さくするためである。制御周期のどの時点でアクセスポイントが送信データが送信するかは毎回変動するが、走行台車の時計を少しずつ書き換えると、アクセスポイントからの送信遅れの影響などを小さくできる。
【００２４】
指令の受信プロセスでは、アクセスポイントから指令を受信すると、受信確認パケットを返信し、指令に従って次の制御周期での目標位置を更新する。なお指令及び報告の再送は例えば２回までとし、１制御周期で最初の送信を含めて３回までの送信を認める。そして仮に３回とも指令の受信に失敗した場合、目標位置等を更新しないので、走行台車は減速する。
【００２５】
走行台車からの送信プロセスは、制御周期の開始から30ms間待機し、この時点でシステムサーバへの状態報告パケットを作成する。全ての走行台車はシステムサーバの時計に合わせた時計を持っているので、制御周期の開始から同じ時間だけ経過した時点で一斉に状態報告パケットを作成する。走行台車はアクセスポイントへの送信に割り当てられた40msを例えば40分割し、このうち１msを自己の割り当て時間として、乱数により割り当て時間を選ぶ。そして割り当て時間が到来するまで待機し、割り当て時間に達すると、バックオフアルゴリズムでパケットの衝突を防止しながら、状態報告パケットを送信する。
【００２６】
図６に走行台車でのローミングの処理を示す。走行台車はマップ上の自己の位置を知っており、次に進入するエリアでのチャネルも知っている。そしてエリアの境界が近づく、もしくは通信中のアクセスポイントからの電波が弱くなると、ローミングを開始する。ローミングではマップから次に進入するエリアのチャネルを求め、そのチャネルでビーコンを検出する。なおビーコンは例えば制御周期の最初に送信される。そしてビーコンの電波強度が充分であればローミングし、強度が不足する場合、残る２チャンネルに対するローミングを試みる。システムが用いるチャネルが４種類に制限され、どのチャネルでローミングを試みるべきかがマップから分かるので、簡単にローミングできる。
【００２７】
走行ルートの各地点で２種類以上のチャネルで通信可能なので、アクセスポイントにトラブルが発生しても、他のアクセスポイントとの通信を維持できる。ローミングは例えば走行台車からアクセスポイントへの送信に割り当てられた時間帯に、プローブ要求をアクセスポイントへ送信し、アクセスポイントからプローブ許可を受信することにより完了する。なお状態報告パケットにプローブ要求を追加して送信しても良い。またプローブ要求を行わずに、走行台車から台車のID、目的地、搬送指令のID、現在位置、速度、分岐方向などの報告を送信し、アクセスポイントが新たな台車から報告を受けたことを確認することにより、ローミングを完了しても良い。
【００２８】
図７に、走行台車がシステムサーバからの指令の受信に失敗した際の、フェイルセーフ機構を示す。アクセスポイントが指令を送信しても走行台車からの確認が得られない場合、２回まで再送する。従って走行台車が指令の受信に失敗する確率は元々極めて小さい。それでも指令を受信できなかった場合、台車は前回の制御周期での目標位置に従って走行する。従って多くの場合、台車はオーバーランして減速する。制御周期は０.１s程度なので、走行台車の最大走行速度を４m/sとしても、走行台車がオーバーランする距離は最大で40cm程度である。なおシステムサーバは、この程度のオーバーランでは台車間の干渉が生じないように、車間距離を定めて目標位置を指令している。そして次の制御周期で指令の受信に成功すると、走行台車はサーバの制御下に戻ることができる。
【００２９】
図８に、システムサーバ側が走行台車からの報告を受信できなかった際のフェイルセーフ機構を示す。報告がアクセスポイントにより受信できなかった場合、台車は合計３回まで報告する。３回とも失敗した場合、サーバは前の制御周期での台車の位置などの状態を更新せずに記憶する。この結果、システムサーバのデータ上で、後行の走行台車との車間距離が縮まり、サーバは、後行の走行台車に対し干渉を回避するように目的位置を指令する。そして次の制御周期で台車の位置等を受信することができれば、台車をサーバによるフィードバック制御下に戻すことができる。
【００３０】
図９に、走行台車からシステムサーバへの報告と、システムサーバからの指令並びに走行台車による実行のタイミングを示す。制御周期は100msで、図の下部に時刻を示す。複数台の走行台車は一斉に、例えば30msの時点で、システムサーバへの報告を作成し、30ms〜70ms等の間に分散して指令を報告する。報告はアクセスポイントからモーションコントローラを介してシステムサーバへ送られ、システムサーバは次の制御周期（図の制御周期Ｎ）での指令を作成し、モーションコントローラからアクセスポイントへ指令を送信する。報告の転送からアクセスポイントへの指令の送信を70msから100msまでに処理する。アクセスポイントは次の制御周期Ｎの例えば最初の30ms間に走行台車に指令を送信し、走行台車は制御周期Ｎ＋１でその指令を実行する。なお制御周期の始まりと終わりを、走行台車が報告パケットを作成する時点から次の報告を作成する時点までとし、指令を受信すると直ちに指令の実行を開始してもよい。
【００３１】
図１０に、システムサーバと走行台車との通信のタイミングなどを示し、例えば１制御周期は100msで、このうち30msをアクセスポイントから走行台車への送信に、次の40msを走行台車からアクセスポイントへの通信に、残る30msを予備とする。そしてアクセスポイントは周期の最初の30msの間に最大60台程度の走行台車に指令を送信し、走行台車は40msの割り当て時間を40分割し、送信を開始する自己の割り当て時間を、例えば１msずつランダムに選択する。そしてこの１msの範囲で、バックオフアルゴリズムにより、走行台車間の送信パケットの衝突を防止する。
【００３２】
図１１にアクセスポイントから走行台車への送信の例を示し、最初にビーコンを送出し、続いて走行台車毎のデータを送信する。ビーコンの発生後、例えば30ms程度の時間はアクセスポイントからの送信に割り当てられた時間である。この間、RTS（送信を開始する旨のメッセージ），CTS（受信の準備ができた旨のメッセージ）などによる、パケットの衝突の防止制御は不要である。そして走行台車側は指令を受信すると、その都度ACK（受信確認のメッセージ）を送出する。図１１のD10,D20,D30などは、個別の走行台車毎の指令である。
【００３３】
図１２に、走行台車からアクセスポイントへの送信に割り当てた40msのうちの１タイムスロット（１ms）での処理を示す。なおこのタイムスロットを割り当て時間と呼ぶ。アクセスポイント当たりの走行台車の台数は最大で60台程度で、送信時間を40スロットに分割するので、１タイムスロット当たりの走行台車の台数は最大で平均約１.５で、考慮する必要があるのは１つのタイムスロットに５台程度の走行台車が通信する場合までである。例えば５台の台車が１つのタイムスロットを用いる確率は、平均値を1.5台として、１台の場合の約1／24である。１タイムスロット内で複数の走行台車が送信する場合、バックオフアルゴリズムで送信の順序を規制する。即ちタイムスロットが到来すると、各走行台車は0〜15の範囲で乱数を発生させ、キャリアが無い時間がDIFS（IEEE802.11で規定された待時間）とさらにバックオフ時間だけ続くと、RTS信号を送出する。バックオフアルゴリズムで用いる乱数を16通りとすると、２台の台車が同じバックオフ時間を持つ確率は僅かである。そしてRTSに対して、アクセスポイントからのCTSを受信できると、データの送信を開始し、アクセスポイントはデータを受信できると確認信号ACKを送出する。
【００３４】
図１３に走行台車からアクセスポイントへの送信制御を示す。送信に割り当てられた時間は40msで、自己の割り当て時間をランダムに１ms幅で選択する。そして自己の割り当て時間が到来するまで待機し、到来するとバックオフ時間をランダムに設定する。バックオフ時間の間継続してキャリアを検出しないとRTSを送信し、CTSを受信するとデータを送信する。続いて確認信号ACKを受信できると送信が終わる。ACKの受信まで進めない場合、バックオフ時間をランダムに再設定して再度トライする。なおパケットの衝突などがない場合、DIFSからACKまでの時間は、走行台車１台分の報告に対し、例えば400μs程度である。従って１タイムスロット当たり３台以上の走行台車が存在すると、１msの間に送信が終わらないことがある。この場合、未送信の走行台車は次のタイムスロットでも送信を続行する。そして次のタイムスロットを用いる予定の走行台車は、この間バックオフアルゴリズムにより送信を待機する。
【００３５】
図１４に実施例の送信アルゴリズムと、単なるバックオフアルゴリズムとの比較を示す。ここでは、１アクセスポイント当たり60台の走行台車が存在するとの状況で検討する。通常のバックオフアルゴリズムでは、送信までの待機時間は例えば0〜15の16区分で、16区分に60台の台車を収容すると、大部分の送信パケットが衝突し、再送回数が増す。再送回数を少なくするため、バックオフ時間の範囲を拡大すると、平均のバックオフ時間が増し、通信効率が低下する。
【００３６】
これに対して実施例では、40msの時間を１msずつに分割するので、１つの割り当て時間当たりの送信は平均して1.5回である。1.5回分の送信を衝突無しに制御すれば良いので、バックオフ時間を短くできる。また仮に１msの割り当て時間内に通信が完了しない場合でも、次の割り当て時間を引き続いて使うことができる。これらの結果、通信の成功率が増す。１つの割り当て時間内では、送信の衝突をバックオフアルゴリズムで回避するので、衝突とこれに伴う再送とを少なくできる。
【符号の説明】
【００３７】
２ 走行台車システム
４ インターベイルート
６ イントラベイルート
８ アクセスポイント
１０ エリア
１２ 走行台車
１４ 地上ＬＡＮ
１６ モーションコントローラ
１８ システムサーバ
２０ 上位サーバ
２２ 時計
２４ 台車状態記憶部
２６ 指令作成部
２８ アンテナ
３０ 通信部
３２ 主制御部
３４ 走行系
３５ 移載系
３６ センサ群
４０ 電波強度検出部
４１ ローミング部
４２ 送信制御部
４３ 時計
４４ 時計校正部
ｆa〜ｆd チャネル
【特許請求の範囲】
【請求項１】
システムサーバとアクセスポイントとを地上ＬＡＮを介して接続し、前記アクセスポイントから複数台の走行台車へ制御周期毎に指令を無線で送信し、複数台の走行台車からアクセスポイントへ前記制御周期毎に報告を無線で送信するシステムであって、
前記制御周期中に、アクセスポイントからの送信専用で、走行台車からの報告を認めないアクセスポイント用時間帯と、走行台車からアクセスポイントへ報告するための台車用時間帯とを設け、
アクセスポイントは、アクセスポイント用時間帯に、送信権を確認するための信号を走行台車との間で交換せずに、指令を送信するための手段を備え、
走行台車は、台車用時間帯に、送信権を確認するための信号を他の走行台車との間で交換した上で、前記報告を送信するための送信手段を備えていることを特徴とする、走行台車システム。
【請求項２】
台車用時間帯を複数のタイムスロットに分割すると共に、走行台車は複数のタイムスロットから１個をランダムに選択するための選択手段を備え、前記送信手段により選択したタイムスロット中に報告を送信するように構成したことを特徴とする、請求項１の走行台車システム。
【請求項３】
走行台車は、選択したタイムスロットが到来した後、さらに待機する待時間をランダムに定めるための手段を備えて、前記待時間経過後に前記送信手段により報告を送信するように構成したことを特徴とする、請求項２の走行台車システム。
【請求項１】
システムサーバとアクセスポイントとを地上ＬＡＮを介して接続し、前記アクセスポイントから複数台の走行台車へ制御周期毎に指令を無線で送信し、複数台の走行台車からアクセスポイントへ前記制御周期毎に報告を無線で送信するシステムであって、
前記制御周期中に、アクセスポイントからの送信専用で、走行台車からの報告を認めないアクセスポイント用時間帯と、走行台車からアクセスポイントへ報告するための台車用時間帯とを設け、
アクセスポイントは、アクセスポイント用時間帯に、送信権を確認するための信号を走行台車との間で交換せずに、指令を送信するための手段を備え、
走行台車は、台車用時間帯に、送信権を確認するための信号を他の走行台車との間で交換した上で、前記報告を送信するための送信手段を備えていることを特徴とする、走行台車システム。
【請求項２】
台車用時間帯を複数のタイムスロットに分割すると共に、走行台車は複数のタイムスロットから１個をランダムに選択するための選択手段を備え、前記送信手段により選択したタイムスロット中に報告を送信するように構成したことを特徴とする、請求項１の走行台車システム。
【請求項３】
走行台車は、選択したタイムスロットが到来した後、さらに待機する待時間をランダムに定めるための手段を備えて、前記待時間経過後に前記送信手段により報告を送信するように構成したことを特徴とする、請求項２の走行台車システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２０１１−１６２３４３（Ｐ２０１１−１６２３４３Ａ）
【公開日】平成２３年８月２５日（２０１１．８．２５）
【国際特許分類】
【出願番号】特願２０１０−３０１６６（Ｐ２０１０−３０１６６）
【出願日】平成２２年２月１５日（２０１０．２．１５）
【出願人】（０００００６２９７）村田機械株式会社 (4,916)
【Ｆターム（参考）】
【公開日】平成２３年８月２５日（２０１１．８．２５）
【国際特許分類】
【出願日】平成２２年２月１５日（２０１０．２．１５）
【出願人】（０００００６２９７）村田機械株式会社 (4,916)
【Ｆターム（参考）】
[ Back to top ]