IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社日立製作所の特許一覧

(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022177631
(43)【公開日】2022-12-01
(54)【発明の名称】制御システム
(51)【国際特許分類】
   H04W 4/40 20180101AFI20221124BHJP
【FI】
H04W4/40
【審査請求】未請求
【請求項の数】12
【出願形態】OL
(21)【出願番号】P 2021084036
(22)【出願日】2021-05-18
(71)【出願人】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
(74)【代理人】
【識別番号】110001829
【氏名又は名称】弁理士法人開知
(72)【発明者】
【氏名】石郷岡 祐
【テーマコード(参考)】
5K067
【Fターム(参考)】
5K067AA35
5K067BB21
5K067DD27
5K067DD30
5K067EE02
5K067EE16
5K067FF23
5K067FF25
5K067FF28
5K067GG06
(57)【要約】
【課題】インフラセンサのセンシング時刻と、無線通信時間と、制御対象の反応時間とから余裕時間を算出し、アプリケーションと通信の実行順を制御し、リアルタイム性を向上可能な制御システムを提供する。
【解決手段】制御システム1は移動体の情報を送信する移動体検出部11、12、移動体の情報を受信し移動体の情報に基づき移動体の制御処理部152に制御情報を送信する管制システム13を備える。管制システム1は移動体の反応時間及び通信制御推定必要時間に基づき第1余裕時間を算出する余裕時間算出部135、制御情報の実行順序を決定する処理管理部136、移動体の情報と処理管理部136が決定した実行順序とに基づき制御情報を算出するアプリケーション部137、移動体の反応時間及び通信制御実必要時間に基づき第2余裕時間を算出し第2余裕時間に応じて制御情報を制御処理部152に送信する送信制御部138を備える。
【選択図】図2
【特許請求の範囲】
【請求項1】
移動体を検出し、前記移動体の情報を送信する移動体検出部と、
前記移動体検出部が送信した前記移動体の前記情報を受信し、受信した前記移動体の前記情報に基づいて、前記移動体の制御処理部に制御情報を送信する管制システムと、
を備え、
前記管制システムは、
前記移動体の反応時間及び通信制御推定必要時間に基づいて、第1余裕時間を算出する余裕時間算出部と、
前記第1余裕時間に基づいて、前記制御情報の実行順序を決定する処理管理部と、
前記移動体の前記情報と、前記処理管理部が決定した前記実行順序とに基づいて前記制御情報を算出するアプリケーション部と、
前記移動体の反応時間及び通信制御実必要時間に基づいて、第2余裕時間を算出し、前記第2余裕時間に応じて前記制御情報を前記制御処理部に送信する送信制御部と、
を備えることを特徴とする制御システム。
【請求項2】
請求項1に記載の制御システムにおいて、
前記第1余裕時間は、前記移動体検出部が前記移動体の前記情報を受信した時点から前記移動体が移動してから移動を終了するまでの時間である全体レイテンシに対して、前記移動体の反応時間及び通信制御推定必要時間を減算して算出され、
前記第2余裕時間は、前記全体レイテンシに対して、前記移動体の反応時間及び通信制御実必要時間を減算して算出されることを特徴とする制御システム。
【請求項3】
請求項2に記載の制御システムにおいて、
前記通信制御推定必要時間は、前記管制システムと前記制御処理部との推定通信時間と、前記移動体の反応時間と、前記アプリケーション部の推定アプリケーション実行時間と、前記移動体検出部が前記移動体を検知する時間と、前記移動体を検知する検知信号のアップリンク時間と、を加算した値であり、
前記通信制御推定実要時間は、前記管制システムと前記制御処理部との推定通信時間と、前記移動体の反応時間と、前記アプリケーション部の実際のアプリケーション実行時間と、前記移動体検出部が前記移動体を検知する時間と、前記移動体を検知する検知信号のアップリンク時間と、を加算した値であることを特徴とする制御システム。
【請求項4】
請求項3に記載の制御システムにおいて、
前記管制システムは、前記推定通信時間と前記移動体の前記反応時間を推定する制御時間推定部を、さらに備えることを特徴とする制御システム。
【請求項5】
請求項3に記載の制御システムにおいて、
前記処理管理部は、前記第1余裕時間が短い順に前記アプリケーション部が前記制御情報を算出するように前記実行順序を決定することを特徴とする制御システム。
【請求項6】
請求項3に記載の制御システムにおいて、
前記送信制御部は、前記第2余裕時間が短い順に前記制御情報を前記制御処理部に送信することを特徴とする制御システム。
【請求項7】
請求項3に記載の制御システムにおいて、
前記第1余裕時間または前記第2余裕時間がマイナスとなる場合には、前記アプリケーション部の前記制御情報の算出を中止することを特徴とする制御システム。
【請求項8】
請求項3に記載の制御システムにおいて、
前記移動体には、歩行者を含み、前記制御処理部は前記歩行者が所持する無線通信機器であることを特徴とする制御システム。
【請求項9】
請求項3に記載の制御システムにおいて、
前記処理管理部は、前記第1余裕時間が長い前記制御情報の算出を停止させ、前記第1余裕時間が短い前記制御情報をアプリケーション部に算出させることを特徴とする制御システム。
【請求項10】
請求項3に記載の制御システムにおいて、
前記送信制御部は、前記第2余裕時間が長い前記制御情報の送信を停止させ、慚愧第2余裕時間が短い前記制御情報の送信を実行することを特徴とする制御システム。
【請求項11】
請求項4に記載の制御システムにおいて、
前記移動体には、歩行者を含み、前記制御処理部は前記歩行者が所持する無線通信機器であり、前記制御時間推定部は、前記歩行者の反応時間を、前記無線通信機器を見ているか否か、あるいは前記移動体の方向を向いているか、あるいは前記歩行者の年齢の情報に基づいて推定することを特徴とする制御システム。
【請求項12】
請求項1記載の制御システムにおいて、
前記移動体の前記制御処理部に送信する前記制御情報は、車両の停止あるいは操舵制御、あるいは、人に指示や警告を与える画像・音・振動に関する情報であることを特徴とする制御システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、無線通信を含む制御システムのリアルタイム性向上技術に関する。
【背景技術】
【0002】
限定領域向けの移動サービスや搬送作業サービスを提供するために制御システムの自律化が進行している。例えば、車両による工場敷地内搬送システムや、自動フォークリフトやAGV(Automated Guided Vehicle)やロボットアーム付きAGVによる倉庫管理システム、特定地区向けロボットタクシーや自動運転バス、鉱山における自動運転トラックなどがあげられる。
【0003】
これらのサービスが行われるフィールドでは、自律的に認知・判断・制御を行う移動体(自律移動体)と、人が操作する移動体(有人移動体)と、歩行者や作業員など人が共存して各々の作業を行っている。
【0004】
移動体のセンシング範囲は限られているために、路上や施設内に設置されたセンサ(インフラセンサ)で移動体の死角を監視し、無線通信で接続された移動体と人(が有するデバイス)に認識情報を通知、または移動体や人に行動を指示する技術が求められている。
【0005】
特許文献1には、インフラセンサが移動体の死角に潜む他移動体や人を認識し、該当する移動体に情報共有や通知する技術が記載されている。
【先行技術文献】
【特許文献】
【0006】
【特許文献1】特開2019-215785号公報
【発明の概要】
【発明が解決しようとする課題】
【0007】
特許文献1に記載の技術によると、移動体や人に対する安全性の向上が期待できる。
【0008】
しかしながら、建物や車両の影などの場所によって無線通信の電波状況が異なるため、移動体や人の場所によって通信時間が変化する。そのため、複数の移動体や人に対して、認識情報共有や行動指示を行う際には、電波状況が良くない移動体や人との通信に時間を要し、他の移動体や人に対しての認識情報共有や行動指示が遅れてしまう可能性がある。
【0009】
さらに、特許文献1に記載の技術では、フィールドに異種の移動体や、移動体と人が混在する状況を考慮していない。認識情報共有や制御指示を受けた後に反応し、行動を終了するまでの時間(制御反応時間)は、移動体や人に依存する。
【0010】
例えば、人と人とは異なる移動体に停止指示を送信し、制動距離に要する制御反応時間を考慮すると、移動体が人よりも長い制御反応時間を要する場合、同タイミングで両方に衝突の警告を発行すると、人の方が警告に気づく時間は移動体よりも長いが、停止完了までの行動終了時間が短いために最終的な制御反応時間が短くなる。
【0011】
つまり、死角がある場所において、通信状態が悪い人と通信状態が良い移動体の間で衝突リスクがある場合、移動体、人の順に情報を共有すると、逆の場合よりも衝突リスクが高くなるという課題がある。
【0012】
このように、制御システムの稼働環境が複雑である場合には、事前に処理や通信の実行順に優先度を設定することが困難である。
【0013】
本発明は、上記のような課題を解決するためになされたものであり、インフラセンサのセンシング時刻と、無線通信時間と、制御対象の反応時間と、から余裕時間を算出し、それに基づいて、アプリケーションと通信の実行順を制御し、リアルタイム性を向上可能な制御システムを提供することを目的とする。
【課題を解決するための手段】
【0014】
上記課題を解決するための本発明の制御システムは、次のように構成される。
【0015】
制御システムにおいて、移動体を検出し、前記移動体の情報を送信する移動体検出部と、前記移動体検出部が送信した前記移動体の前記情報を受信し、受信した前記移動体の前記情報に基づいて、前記移動体の制御処理部に制御情報を送信する管制システムと、を備える。前記管制システムは、前記移動体の反応時間及び通信制御推定必要時間に基づいて、第1余裕時間を算出する余裕時間算出部と、前記第1余裕時間に基づいて、前記制御情報の実行順序を決定する処理管理部と、前記移動体の前記情報と、前記処理管理部が決定した前記実行順序とに基づいて前記制御情報を算出するアプリケーション部と、前記移動体の反応時間及び通信制御実必要時間に基づいて、第2余裕時間を算出し、前記第2余裕時間に応じて前記制御情報を前記制御処理部に送信する送信制御部と、を備える。
【発明の効果】
【0016】
本発明に係る制御システムによれば、インフラセンサのセンシング時刻と、無線通信時間と、制御対象の反応時間と、から余裕時間を算出し、それに基づいて、アプリケーションと通信の実行順を制御し、リアルタイム性を向上可能な制御システムを提供することができる。
【図面の簡単な説明】
【0017】
図1】実施例1に係る制御システムの全体概略構成図である。
図2】実施例1に係る管制システムの内部構成図である。
図3】実施例1に係る認識処理部の処理フローである。
図4】実施例1に係る受信部の処理フローである。
図5】実施例1に係る入力経過時間算出部の処理フローである。
図6】実施例1に係る通信性能測定サーバ処理部の処理フローである。
図7】実施例1に係る制御時間推定部の処理フローである。
図8】実施例1に係る余裕時間算出部の処理フローである。
図9】実施例1に係る余裕時間の算出説明図である。
図10】実施例1に係る処理管理部の処理フローである。
図11】実施例1に係るアプリケーション部の処理フローである。
図12】実施例1に係る送信制御部の処理フローである。
図13】実施例1に係る通信性能測定クライアント処理部の処理フローである。
図14】実施例1に係る制御処理部の処理フローである。
図15】実施例1に係るスレッドの優先度の例を示す図である。
図16】実施例1に係る物体情報の例を示す図である。
図17】実施例1に係る制御対象情報テーブルの例を示す図である。
図18】実施例1とは異なる例であり、制御システムの実行タイミング(FIFO)の例の説明図である。
図19】実施例1に係る制御システムの実行タイミングの例の説明図である。
図20】実施例1とは異なる例であり、制御システムの実行タイミング(FIFO)の他の例の説明図である。
図21】実施例1に係る制御システムの実行タイミングの他の例の説明図である。
図22】実施例2に係る制御システムの管制システムの内部構成図である。
図23】実施例2に係る制御時間推定部の処理フローである。
図24】実施例2に係るアプリケーション部の処理フローである。
図25】実施例2に係る物体情報の例を示す図である。
図26】実施例2に係る物体情報の他の例を示す図である。
図27】実施例2に係る制御対象情報テーブルの例を示す図である。
【発明を実施するための形態】
【0018】
本発明に係る制御システムは、移動体検出部のセンシング時刻と無線通信時間と制御対象の反応時間から余裕時間を算出し、それに基づいて、アプリケーションと通信の実行順を制御することで、リアルタイムに制御対象に認識情報を提供、あるいは行動指示を通知する。
【0019】
以下、図面を用いて本発明の実施形態について説明する。
【0020】
なお、実施例では、移動体検出部の一例として、インフラセンサを記載したが、インフラセンサに限らず、移動体を検出する検出装置等であれば、適用可能である。
【実施例0021】
(実施例1)
図1は、本発明の実施例1に係る制御システムの全体概略構成図である。
【0022】
図1において、制御システム1は、インフラセンサ11、インフラセンサ12、管制システム13、無線機器14、自動車15、バス16、無線通信機器17TRを所持した歩行者17、歩行者18、信号機19を管制するシステムである。
【0023】
なお、図1には、歩行者17、歩行者18、信号機19、自動車15及びバス16が、それぞれ互いに異なる余裕時間を有することを示す説明部分1Aが示されている。
【0024】
インフラセンサ11とインフラセンサ12との間は有線通信あるいは無線通信で通信される。無線機器14は、自動車15、バス16、歩行者17及び信号機19と無線で通信する。歩行者18が通信機器を所持している場合は、無線機器14は、歩行者18が無線通信機器と無線で通信する。
【0025】
図2は、実施例1に係る管制システム13の内部構成図であり、各部の処理フローを示す図である。
【0026】
図2において、インフラセンサ11、12の認識処理部111は、センシング内容を分析し、検知した物体情報13Aを管制システム13の受信部131に送信する。管制システム13とインフラセンサ11、12の時刻は、管制システム13の時刻同期部112Aとインフラセンサ11、12の時刻同期部112Bで合わせられる。
【0027】
受信部131は、物体情報13Aを、入力経過時間算出部132、制御時間推定部134、アプリケーション部137に送信する。通信性能測定サーバ処理部133は、時刻情報を通信性能測定クライアント処理部151に送信し、通信性能測定クライアント処理部151は、前記時刻情報を受信した際には、通信性能測定サーバ処理部133に返信する。通信性能測定サーバ処理部133は、受信した時刻情報に基づいて推定通信時間を算出し、制御時間推定部134に送信する。
【0028】
入力経過時間算出部132は、物体情報13Aに内包された時刻情報からセンシング経過時間を算出し、余裕時間算出部135に送信する。制御時間推定部134は、物体情報13Aと推定通信時間から推定制御時間を算出し、余裕時間算出部135に送信する。
【0029】
余裕時間算出部135は、センシング経過時間と推定制御時間から余裕時間を算出し、処理管理部136に送信する。
【0030】
処理管理部136は、余裕時間に基づいてアプリケーション部137を起動する。アプリケーション部137は、制御対象情報、送信データ及び余裕時間を送信制御部138に通知する。送信制御部138は、余裕時間に応じて送信データを、制御対象情報に応じて制御対象15、16、17、19の制御処理部152に送信する。
【0031】
以降より、実施例1に係る動作フローの詳細を説明する。
【0032】
図3は認識処理部111の処理フローである。以下、図3の各ステップについて説明する。
【0033】
図3:ステップ1111)
認識処理部111は、インフラセンサ11、12のセンシング情報から物体を識別し、タイムスタンプを付与して管制システム13に送信する。
【0034】
図4は受信部131の処理フローである。以下、図4の各ステップについて説明する。
【0035】
図4:ステップ1311)
受信部131は、インフラセンサ11、12からの情報を取得し、アプリケーション部137、入力経過時間算出部132及び制御時間推定部134に送信する。
図5は、入力経過時間算出部132の処理フローである。以下、図5の各ステップについて説明する。
【0036】
図5:ステップ1321)
入力経過時間算出部132は、受信情報に付与されたタイムスタンプ情報と管制システム13の基準時刻を比較し、センシング経過時間(TIS+TUL)を算出する。その結果を余裕時間算出部135に送る。
【0037】
図6は通信性能測定サーバ処理部133の処理フローである。以下、図6の各ステップについて説明する。
【0038】
図6:ステップ1331)
通信性能測定サーバ処理部133は、時刻情報を制御対象15、16、17及び19のそれぞれに送信する。
【0039】
図6:ステップ1332)
通信性能測定サーバ処理部133は、制御対象15、16、17及び19から送られてくる時刻情報を受信するまで待つ。
【0040】
図6:ステップ1333)
通信性能測定サーバ処理部133は、制御対象15、16、17及び19から受信した時刻情報と現在時刻から制御対象との通信時間を推定し、制御対象情報テーブル13Bの推定通信時間を更新する。
【0041】
図7は、制御時間推定部134の処理フローである。以下、図7の各ステップについて説明する。
【0042】
図7:ステップ1341)
制御時間推定部134は、物体情報の物体IDに基づいて、制御対象情報テーブル13Bを参照して、制御対象の反応時間と推定通信時間を取得し、推定制御時間を算出する。算出結果を余裕時間算出部135に送信する。
【0043】
制御対象の反応時間は制御対象情報テーブル13Bを参照しなくても良い。例えば、物体情報から制御対象が、デバイスを見ているか否か、あるいは移動体の方向を向いているか、あるいは人の年齢の情報に基づいて推定してもよい。
【0044】
つまり、移動体には、歩行者を含み、制御処理部152は歩行者17が所持する無線通信機器17TRであり、制御時間推定部134は、歩行者17の反応時間を、無線通信機器17TRを見ているか否か、あるいは移動体である自動車15やバス16の方向を向いているか、あるいは歩行者17の年齢の情報に基づいて推定することも可能である。
【0045】
図8は、余裕時間算出部135の処理フローである。以下、図8の各ステップについて説明する。
【0046】
図8:ステップ1351)
余裕時間算出部135は、センシング経過時間と推定制御時間から余裕時間T1Laxityを算出し、処理管理部136に送信する。実施例1では全体レイテンシ(TE2EL)、ESAは固定時間として扱う。
【0047】
次式(1)は、余裕時間T1Laxityの算出式であり、次式(2)は、余裕時間T2Laxityの算出式である。
T1Laxity=TE2EL-(TIS+TUL+ESA+EDL+EVA) ・・・(1)
T2Laxity=TE2EL-(TIS+TUL+TSA+EDL+EVA) ・・・(2)
【0048】
上記式(1)において、余裕時間(T1Laxity)は全体レイテンシ(TE2EL)からインフラセンサ11、12のセンシング経過時間(TIS+TUL)と推定アプリケーション実行時間(ESA)と推定通信時間(EDL)と制御対象反応時間(EVA)の差分から算出できる。
【0049】
上記式(2)において、余裕時間(T2Laxity)は全体レイテンシ(TE2EL)からインフラセンサ11、12のセンシング経過時間(TIS+TUL)と実アプリケーション実行時間(TSA)と推定通信時間(EDL)と制御対象反応時間(EVA)の差分から算出できる。
【0050】
全体レイテンシ(TE2EL)は、移動体や人に対して制御指示をして完了するまでのセンシングから行動終了するまでの時間(移動体検出部が移動体の情報を受信した時点から移動体が行動を終了するまでの時間)である。また、全体レイテンシは、移動体15、16、17、19が停止するまでの時間、あるいは、人18に指示や警告を画像・音・振動で通知し、行動を起こし、終了するまでの反応時間を考慮した時間である。
【0051】
例えば、移動体が遠隔操作(操舵制御)によって停止するまでの全体時間や、人が所持するデバイスへの表示、音の発生、振動させることで人を停止させるまでの全体時間の情報である。
【0052】
つまり、移動体の制御処理部152に送信する制御情報は、車両の停止あるいは操舵制御、あるいは、人に指示や警告を与える画像・音・振動に関する情報である。
【0053】
図9は、上記式(1)及び式(2)の説明図である。
【0054】
図9において、TISはインフラセンサ11、12の制御対象15、16、17、19を検知するセンシング時間(検知時間)であり、TULはインフラセンサ11、12からのセンサ信号(検知信号)のアップリンク時間である。ESAはアプリケーション部137の推定アプリケーション実行時間、EDLは管制システム13と制御対象の制御処理部152との推定通信時間、EVAは制御対象反応時間である。推定通信時間EDLと制御対象反応時間EVAとを加算した値が推定制御時間となる。
【0055】
また、推定制御時間(推定通信時間EDL+制御対象反応時間EVA)と、推定アプリケーション実行時間ESAと、センシング時間TISと、アップリンク時間TULと、を加算した値が通信制御推定必要時間である。
【0056】
また、推定制御時間(推定通信時間EDL+制御対象反応時間EVA)と、アプリケーション部137の実際の実行時間である実アプリケーション実行時間TSAと、センシング時間TISと、アップリンクする時間TULと、を加算した値が通信制御実必要時間である。
【0057】
実アプリケーション実行時間TSAはアプリケーションが実行開始されてから終了するまでの時間である。推定アプリケーション実行時間ESAは実アプリケーション実行時間TSAより長い時間が設定されている。第1余裕時間T1Laxityは、センサ信号がアップリンクされてから、アプリケーションが実行されるまでの時間であり、第2余裕時間T2Laxityはアプリケーションが終了してから通信が開始されるまでの時間である。
【0058】
図10は、処理管理部136の処理フローである。以下、図10の各ステップについて説明する。
【0059】
図10:ステップ1361)
処理管理部136は余裕時間T1Laxityに基づいてアプリケーション部137の実行順を決定する(制御情報の処理実行順序を決定する)。例えば、余裕時間T1Laxityが短い順に制御情報の算出を実行するようにアプリケーション部137の実行順を決定する。余裕時間T1Laxityがマイナスとなる場合には、処理を実行しないでもよい。マイナスとなる場合には処理結果に意味をなさないことが多く、処理を中止し、他の処理を優先的に実行することで制御システム全体としての安定性が向上する。
【0060】
図11はアプリケーション部137の処理フローである。以下、図11の各ステップについて説明する。
【0061】
図11:ステップ1371)
アプリケーション部137は物体情報に基づいて制御アプリケーションを実行する。
【0062】
図11:ステップ1372)
アプリケーション部137は制御対象と送信データと余裕時間T1Laxityを送信制御部138に送信する。
【0063】
図12は送信制御部138の処理フローである。以下、図12の各ステップについて説明する。
【0064】
図12:ステップ1381)
送信制御部138はセンシング経過時間と推定制御時間と実アプリケーション実行時間から余裕時間T2Laxityを算出する。
【0065】
図12:ステップ1382)
送信制御部138は余裕時間T2Laxityに応じて送信データの送信順番を決定する。送信制御部138は、余裕時間T2Laxityの短い順に制御情報を制御処理部152に送信する。余裕時間T2Laxityがマイナスとなる場合には、送信データを破棄してもよい。マイナスとなる場合には送信データに意味をなさないことが多く、送信データを中止し、他の送信データを優先的に実行することで制御システム全体としての安定性が向上できる。
【0066】
あるいは、通信時間を短くする対策手段を実施しても良い。例えば、ACKによる再送型の通信ではなく、予め同じ送信パケットを連続で送信する方法や、別の通信経路を利用する方法を用いてもよい。
【0067】
図12:ステップ1383)
送信制御部138は優先度が高いデータを送信する。例えば、余裕時間T2Laxityが短い送信データを送信する。
【0068】
図13は、通信性能測定クライアント処理部151の処理フローである。以下、図13の各ステップについて説明する。
【0069】
図13:ステップ1511)
通信性能測定クライアント処理部151は、管制システム13から時刻情報を受信した場合には、その時刻情報を変更せずに管制システム13の通信性能測定クライアント処理部133に返信する。
【0070】
図14は、制御処理部152の処理フローである。以下、図14の各ステップについて説明する。
【0071】
図14:ステップ1521)
制御処理部152は、送信処理部138からの送信データに基づいて、制御処理を実行する。例えば、制御対象が自動車15やバス16の場合には走行停止処理を実行する。制御対象が歩行者17の場合には所持しているデバイスを振動・警報させ、画面に停止指示することで行動を間接的に制御する。
【0072】
制御対象が信号機19の場合には、信号の色を任意の色(例えば赤)に変更する。
【0073】
図15は、管制システム13のスレッド優先度の例を示す図である。
【0074】
図15において、通信性能測定スレッド1330は通信性能測定サーバ処理部133を実行する。
【0075】
受信処理スレッド1310は受信部131を実行する。
【0076】
余裕時間計算スレッド1350は、入力経過時間算出部132、制御時間推定部134、余裕時間算出部135、処理管理部136を実行する。
【0077】
アプリケーションスレッド1370は、アプリケーション部137を実行する。
【0078】
送信処理スレッド1380は送信制御部138を実行する。
【0079】
図16は、物体情報13Aの例を示す図である。
【0080】
図16において、物体情報13Aは、物体種別、物体ID、インフラセンサ11、12が付与したタイムスタンプで構成される。図16には、物体種別としてセンシングした情報が、車両Aである例を示す。また、物体IDが1の例を示し、タイムスタンプが12時34分000ミリ秒の例を示す。
【0081】
図17は、制御対象情報テーブル13Bの例を示す図である。
【0082】
図17において、制御対象情報テーブル13Bは、物体ID、項目、反応時間、IPアドレス、推定通信時間で構成される。
【0083】
図18は、実施例1とは異なり、余裕時間を用いずに一般的によく用いられるFIFO(First In First Out)に基づいてアプリケーション部137の実行順を決定したときの制御システムの実行タイミングの例を示す図であり、横方向に時間経過を示す。
【0084】
図18に示した例は、第1のCPU及び第2のCPUの2つのCPUを使用する例である。
【0085】
図18において、第1のCPUで、2つの物体情報の受信順に、受信処理スレッド1310及び余裕時間算出スレッド1350が実行され、第2のCPUで、アプリケーションスレッドA13701(余裕時間長)及びアプリケーションスレッドB13702(余裕時間短)が実行される。第1のCPUで、2つの物体情報の受信順に、送信処理スレッド1380が実行される。
【0086】
そして、先に受信した物体情報について、送信データ13D1(余裕時間長)が送信され、制御処理スレッド1421(車両A)が実行される。また、後に受信した物体情報について、送信データ13D2(余裕時間短)が送信され、制御処理スレッド1422(歩行者B)が実行される。
【0087】
図18に示した例においては、管制システム13が受信した順にアプリケーション部137を実行するため、車両Aへの指示が先行し、通信時間と反応時間が長い歩行者Bの指示が遅れる。
【0088】
図19に示した例は、本発明の実施例1の場合の例であり、余裕時間に基づいて実行された制御システムの実行タイミングの例を示す図である。
【0089】
図19に示した例も、図18に示した例と同様に、第1のCPU及び第2のCPUの2つのCPUを使用する例である。
【0090】
図19において、第1のCPUで、2つの物体情報の受信順に、受信処理スレッド1310及び余裕時間算出スレッド1350が実行され、第2のCPUで、アプリケーションスレッドA13701(余裕時間長)及びアプリケーションスレッドB13702(余裕時間短)が実行される。
【0091】
アプリケーションスレッドA13701(余裕時間長)及びアプリケーションスレッドB13702(余裕時間短)の実行においては、先に受信した物体情報の処理より、後に受信した物体情報ついての処理が先行するように調整される。
【0092】
送信処理スレッド1380では、第1のCPUで、2つの物体情報のうち、余裕時間が短い物体情報が先に処理され、余裕時間が長い物体情報が後に処理される。
【0093】
そして、余裕時間が長い物体情報について、送信データ13D1(余裕時間長)が送信され、制御処理スレッド1421(車両A)が実行される。また、余裕時間が短い物体情報について、送信データ13D2(余裕時間短)が送信され、制御処理スレッド1421(車両A)より先に、制御処理スレッド1422(歩行者B)が実行される。
【0094】
図19に示した本発明の実施例1においては、管制システム13は余裕時間が短いアプリケーションスレッドB13702を優先的に実行させる。これによって、歩行者Bの制御処理スレッド1422を、車両Aの制御処理スレッド1421(車両A)より早く実行することが可能となる。
【0095】
図20は、実施例1とは異なり、余裕時間を用いずに一般的によく用いられるFIFO(First In First Out)に基づいてアプリケーション部137の実行順を決定したときの制御システムの実行タイミングの他の例を示す図であり、横方向に時間経過を示す。
【0096】
図20に示した例は、図18に示した例と同様に、第1のCPU及び第2のCPUの2つのCPUを使用する例である。
【0097】
図20において、第1のCPUで、2つの物体情報の受信順に、受信処理スレッド1310及び余裕時間算出スレッド1350が実行され、第2のCPUで、アプリケーションスレッドA13701(余裕時間長)及びアプリケーションスレッドB13702(余裕時間短)が実行される。第1のCPUで、2つの物体情報の受信順に、送信処理スレッド1380が実行される。
【0098】
そして、先に受信した物体情報について、送信データ13D1(余裕時間長)が送信され、制御処理スレッド1421(車両A)が実行される。また、後に受信した物体情報について、送信データ13D2(余裕時間短)が送信され、制御処理スレッド1422(歩行者B)が実行される。
【0099】
図20に示した例においては、管制システム13が受信した順にアプリケーション部137を実行するため、車両Aへの指示が先行し、通信時間と反応時間が長い歩行者Bの指示が遅れる。
【0100】
図21に示した例は、本発明の実施例1の場合の他の例であり、余裕時間に基づいて実行された制御システムの実行タイミングの例を示す図である。
【0101】
図21に示した例も、図19に示した例と同様に、第1のCPU及び第2のCPUの2つのCPUを使用する例である。
【0102】
図21において、第1のCPUで、2つの物体情報の受信順に、受信処理スレッド1310及び余裕時間算出スレッド1350が実行され、第2のCPUで、アプリケーションスレッドA13701(余裕時間長)及びアプリケーションスレッドB13702(余裕時間短)が実行される。
【0103】
送信処理スレッド1380では、第1のCPUで、2つの物体情報の受信順に処理される。
【0104】
そして、先に受信した余裕時間が長い物体情報について、送信データ13D1(余裕時間長)を遅延させて、後に受信した余裕時間が短い物体情報について、送信データ13D2(余裕時間短)が、送信データ13D1(余裕時間長)より先に送信される。これによって、制御処理スレッド1422(歩行者B)が制御処理スレッド1421(車両A)より先に実行される。
【0105】
図21に示した本発明の実施例1においては、管制システム13は余裕時間が短いアプリケーションスレッドB13702を優先的に実行させる。これによって、歩行者Bの制御処理スレッド1422を、車両Aの制御処理スレッド1421(車両A)より早く実行することが可能となる。
【0106】
以上のように、本発明の実施例1によると、特定の制御対象との無線通信時間や制御対象の反応時間を考慮した余裕時間に基づいてアプリケーションと送信データの順番を決定するため、移動体や人との無線通信時間が変動しても、動的に更新することができるため、リアルタイム性を向上することができる。
【0107】
つまり、インフラセンサのセンシング時刻と、無線通信時間と、制御対象の反応時間と、から余裕時間を算出し、それに基づいて、アプリケーションと通信の実行順を制御し、リアルタイム性を向上可能な制御システムを提供することができる。
【0108】
本発明の実施例1により、フィールドにおいて、自律移動体、有人移動体、人における情報共有、制御指示のリアルタイム性を向上することができる。
【0109】
なお、本実施例1には反応時間を固定としたが、これに限らない。例えば、歩行者がデバイスの画面を見ている場合には反応時間を短くするなど、状況に応じて変更してもよい。
【0110】
さらに、変更が生じる状況として、制御対象の移動速度やインフラセンサのセンシング距離によって変化ことが考えられる。例えば、アプリケーションが遠隔緊急停止制御である場合には、移動速度が速いほど、停止までの制動距離が延びるため、それを見越した反応時間が長くなる。
【0111】
また、本実施例1においては、全体レイテンシを固定値としたがこれに限らない。例えば、制御対象の移動速度やセンシング距離によって変化することが考えられる。具体的には移動速度が速い、センシング距離が短くなるほど全体レイテンシが短くなる可能性がある。
【0112】
本実施例1によれば、短い余裕時間のアプリケーション処理を優先して実行するため、状況によって優先度が変わるような異なる種類のアプリケーションにおいても適用可能となる。
【0113】
また、本実施例1によれば、短い余裕時間の送信データの送信処理を優先して実行するため、状況によって優先度が変わるような異なる種類のデータ通信においても適用可能となる。
【0114】
また、本実施例1によれば、制御対象との無線通信時間を推定することで、特定の制御対象が通信不良となる状況に対しても柔軟に対応可能となる。
【0115】
また、本実施例1によれば、移動体および人の反応時間に基づいて処理することで、制御対象が多様な状況においても柔軟に制御可能となる。
【0116】
また、本実施例1によれば、余裕時間がマイナスとなる場合には、アプリケーション処理の中止や、送信パケットの棄却をすることで制御システムの安定性を向上できる。
【0117】
本実施例1においては、余裕時間がマイナスとなる場合には、通信時間を短くする対策手段を実施しても良い。例えば、ACKによる再送型の通信ではなく、予め同じ送信パケットを連続で送信する方法や、別の通信経路を利用する方法を用いることで、リアルタイム性を向上することができる。
【0118】
(実施例2)
次に、本発明の実施例2について説明する。
【0119】
実施例1と異なる点を中心に実施例2について、図面を用いて説明する。
【0120】
図22は、実施例2に係る管制システム13の内部構成であり、各部の処理フローを示す図である。
【0121】
実施例2では、インフラセンサ11、12から物体情報13Cや物体情報13Dが受信部131に送信される。アプリケーション部139は、入力された物体情報13Cや物体情報13Dに基づいて制御対象15、16、17、19の有無を判定し、入力経過時間算出部132と制御時間推定部130に送信する。制御時間推定部130は、物体情報13Cや物体情報13Dに基づいて、制御対象情報テーブル13Eに格納された反応時間と推定行動終了時間を更新する。
【0122】
以降より、実施例2に係る動作フローの詳細を説明する。
【0123】
図23は、制御時間推定部130の処理フローを示す図である。以下、図23の各ステップについて説明する。
【0124】
図23:ステップ1301)
制御時間推定部130は、物体情報13Cや物体情報13Dが所持している制御対象の情報(速度や状態)に基づいて、制御対象情報テーブル13Eに格納された反応時間や推定行動終了時間を更新する。例えば、制御対象の移動速度が速くなるほど、推定行動終了時間が長くなる。
【0125】
例えば、制御対象の状態が情報端末を見ていない状態から見ている状態に変化したときには、反応時間時間が短くなる。また、これらに限らない。例えば、制御対象の人の体の向きが移動体の方向を向いているといった移動体に注視している場合には反応時間を短くしてよい。さらに、年齢に基づいて反応時間を変更してもよい。
【0126】
図23:ステップ1302)
制御時間推定部130は、物体情報13Cや物体情報13Dの物体IDに基づいて、制御対象情報テーブル13Eを参照して、制御対象の反応時間と推定通信時間を取得し、推定制御時間を算出する。制御時間推定部130は、算出結果を余裕時間算出部135に送信する。
【0127】
図24はアプリケーション部139の処理フローを示す図である。以下、図24の各ステップについて説明する。
【0128】
図24:ステップ1391)
アプリケーション部139は、物体情報13C、13Dに基づいて、制御の必要性を判断し、必要である場合にはどの物体に対して制御を実施するかを判定する。
【0129】
図24:ステップ1392)
ステップ1392において、制御が必要な場合はステップ1393に進み、制御が必要ではない場合は、処理を終了する。
【0130】
図24:ステップ1393)
アプリケーション部139は、制御が必要と判定した制御対象に対する制御対象情報と、送信データと、余裕時間とを送信制御部138に送信する。
【0131】
図25は、物体情報13Cの例を示す図である。
【0132】
図25において、物体情報13Cは、物体種別、物体ID、速度、インフラセンサ11、12が付与したタイムスタンプで構成される。実施例1における物体情報13A(図16)と比較して、物体情報13Cには、速度の情報が追加されている。
【0133】
図26は、物体情報13Dの例を示す図である。
【0134】
図26において、物体情報13Dは、物体種別、物体ID、状態、インフラセンサ11、12が付与したタイムスタンプで構成される。実施例1における物体情報13A(図16)と比較して、物体情報13Dには、状態の情報が追加されている。
【0135】
図27は、制御対象情報テーブル13Eの例を示す図である。
【0136】
図27において、制御対象情報テーブル13Eは、物体ID、項目、反応時間、推定行動終了時間、IPアドレス、推定通信時間で構成される。実施例1における制御情報テーブル13B(図17)と比較して、制御対象情報テーブル13Eには、推定行動終了時間が追加されている。
【0137】
本実施例2によれば、実施例1と同様な効果を得ることができる他、推定行動終了時間を制御対象の移動速度に応じて変更することで、多様な状況に対応可能な制御システムを提供することができる。
【0138】
本実施例2によれば、物体の状態によって制御対象の反応時間を変更することで、正確な制御が可能となる。
【符号の説明】
【0139】
1・・・制御システム、11、12・・・インフラセンサ、13・・・管制システム、13A、13C、13D・・・物体情報、13B、13E・・・制御対象情報テーブル、14・・・無線機器、15・・・自動車、16・・・バス、17、18・・・歩行者、17TR・・・無線通信機器、19・・・信号機、111・・・認識処理部、112A、112B・・・時刻同期部、130、134・・・制御時間推定部、131・・・受信部、132・・・入力経過時間算出部、133・・・通信性能測定サーバ処理部、135・・・余裕時間算出部、136・・・処理管理部、137、139・・・アプリケーション部、138・・・送信制御部、151・・・通信性能測定クライアント処理部、152・・・制御処理部
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23
図24
図25
図26
図27