Recommended
Recommended
More Related Content
Recently uploaded
Recently uploaded (11)
Featured
Featured (20)
情報処理学会 第80回ITS研究会 細野航平
- 1. 車両走行車線区間に基づくダイナミックマップ システムのエッジサーバ割当方式 Edge Server Arrangement Method of Dynamic Map System Based on Lane Section 第80回高度交通システムとスマートコミュニティ研究発表会 細野航平，槇晶彦，高田広章，渡辺陽介，佐藤健哉
- 2. 目次 1.はじめに 2.提案システム ダイナミックマップシステム 車両走行車線区間によるエッジサーバ割当 3.評価 4.考察 5.まとめ 2
- 3. はじめに
- 4. はじめに 自動運転の実現 車載センサでの制御には限界が 車両はインフラと情報を共有 クラウドにデータ管理機能を集中 処理負荷の集中や通信遅延 スケーラビリティが懸念 4 ダイナミックマップ 戦略的イノベーション想像プログラム（SIP）・自動走行システム 内閣府 http://www.sip-adus.go.jp/file/201_s.pdf 他車両 自車両 信号 道路地図 道路標識 ランドマーク 渋滞情報 路面情報 歩行者
- 5. はじめに 携帯電話基地局などにエッジサーバを配置 処理分散と通信遅延軽減 5 エッジコンピューティング Multi-access Edge Computing (MEC) ETSI https://www.etsi.org/technologies/multi-access-edge-computing
- 7. ダイナミックマップシステム クラウド・エッジサーバ・車両の三層構造ネットワーク 車両から送信される膨大なデータを低遅延で処理 車両 → エッジサーバ エニキャスト通信 エッジサーバ → 車両 マルチキャスト通信 7 D. Johnson：Request for Comments 2526：Reserved IPv6 Subnet Anycast Addresses：IFTF，https://tools.ietf.org/html/rfc2526（1999）． R. Hinden：Request for Comments 2375：IPv6 Multicast Address Assignments：IFTF，https://tools.ietf.org/html/rfc2375（1998）．
- 10. 車両走行車線区間 道路を区間に分けそれぞれ固有のIDを割当て エッジサーバは車両からのプローブデータ内の車線区間から管轄エッジサーバを判別 10 エッジA エッジB エッジC エッジD
- 11. 車両走行車線区間ごとのID割当て 道路を区間に分けそれぞれ固有のIDを割当て エッジサーバは車両からのプローブデータ内の車線区間から管轄エッジサーバを判別 11 エッジA エッジB エッジC エッジD 54321 6 7 8 9 10 1514131211 16 17 18 19 20 2524232221 26 27 28 29 30 3534333231 36 37 38 39 40 41424344 45464748
- 12. 車両走行車線区間ごとの受信エリア 道路を区間に分けそれぞれ固有のIDを割当て エッジサーバは車両からのプローブデータ内の車線区間から管轄エッジサーバを判別 12 エッジA エッジB エッジC エッジD 54321 6 7 8 9 10 1514131211 16 17 18 19 20 2524232221 26 27 28 29 30 3534333231 36 37 38 39 40 41424344 45464748
- 13. 車両走行車線区間によるアプリケーション実行 管轄エッジサーバ ≠ 受信エッジサーバ の場合も... 車両走行車線区間情報から転送 13 エッジA エッジB エッジC エッジD 54321 6 7 8 9 10 1514131211 16 17 18 19 20 2524232221 26 27 28 29 30 3534333231 36 37 38 39 40 41424344 エッジDの 受信エリア 45464748 エッジBの 受信エリア エッジAの 受信エリア エッジCの 受信エリア
- 14. 車両走行車線区間によるアプリケーション実行 管轄エッジサーバ ≠ 受信エッジサーバ の場合も... 車両走行車線区間情報から転送 14 エッジA エッジB エッジC エッジD 54321 6 7 8 9 10 1514131211 16 17 18 19 20 2524232221 26 27 28 29 30 3534333231 36 37 38 39 40 41424344 45464748 エッジAの 受信エリア エッジDの 受信エリア エッジBの 受信エリア エッジCの 受信エリア 交差点 エッジBに管轄され調停をおこなう エッジBの管轄エリアに 車両を発見！ 調停しよう！ エッジBの管轄エリアに 車両を発見！ 調停しよう！ 車両が優先道路を走行！ 車両は待機せよ！ 車両が通過！ 車両は発進せよ！
- 15. 車両走行車線区間転送 管轄エッジサーバ ≠ 受信エッジサーバ の場合も... 車両走行車線区間情報から転送 15 エッジA エッジB エッジC エッジD 54321 6 7 8 9 10 1514131211 16 17 18 19 20 2524232221 26 27 28 29 30 3534333231 36 37 38 39 40 41424344 45464748 エッジAの 受信エリア エッジDの 受信エリア エッジBの 受信エリア エッジCの 受信エリア 交差点 エッジBに管轄され調停をおこなう
- 16. 車両走行車線区間転送 管轄エッジサーバ ≠ 受信エッジサーバ の場合も... 車両走行車線区間情報から転送 16 エッジA エッジB エッジC エッジD 54321 6 7 8 9 10 1514131211 16 17 18 19 20 2524232221 26 27 28 29 30 3534333231 36 37 38 39 40 41424344 45464748 エッジBの 受信エリア エッジAの 受信エリ ア エッジDの 受信エリア エッジCの 受信エリア
- 17. エッジA エッジB エッジC エッジD 54321 6 7 8 9 10 1514131211 16 17 18 19 20 2524232221 26 27 28 29 30 3534333231 36 37 38 39 40 41424344 45464748 エッジBの 受信エリア エッジAの 受信エリ ア エッジDの 受信エリア エッジCの 受信エリア 車両走行車線区間転送 管轄エッジサーバ ≠ 受信エッジサーバ の場合も... 車両走行車線区間情報から転送 17 交差点 エッジBに管轄され調停をおこなう エッジBの管轄エリアに 車両を発見！ 交差点周辺に車両なし！ 発進せよ！
- 18. エッジA エッジB エッジC エッジD 54321 6 7 8 9 10 1514131211 16 17 18 19 20 2524232221 26 27 28 29 30 3534333231 36 37 38 39 40 41424344 45464748 エッジBの 受信エリア エッジAの 受信エリ ア エッジDの 受信エリア エッジCの 受信エリア 車両走行車線区間によるデータ転送 管轄エッジサーバ ≠ 受信エッジサーバ の場合も... 車両走行車線区間情報から転送 18 交差点 エッジBに管轄され調停をおこなう エッジBの管轄エリアに 車両を発見！ 調停しよう！ エッジBの管轄エリアに 車両を発見！ 調停しよう！ 車両が優先道路を走行！ 車両は待機せよ！ 車両が通過！ 車両は発進せよ！ ここからはエッジBの 管轄エリアだから転送！ ここからはエッジBの 管轄エリアだから転送！
- 19. エッジA エッジB エッジC エッジD 54321 6 7 8 9 10 1514131211 16 17 18 19 20 2524232221 26 27 28 29 30 3534333231 36 37 38 39 40 41424344 45464748 エッジBの 受信エリア エッジAの 受信エリ ア エッジDの 受信エリア エッジCの 受信エリア 車両走行車線区間によるデータ転送 管轄エッジサーバ ≠ 受信エッジサーバ の場合も... 車両走行車線区間情報から転送 19 交差点 エッジBに管轄され調停をおこなう
- 21. 定量的評価
- 23. 定量的評価 23 クラウド・エッジサーバ CPU 8コア16スレッド （3.60GHz） メモリ 16GB SSD 256GB 通信方式 有線LAN （最大1Gbps） 車両 CPU 4コア8スレッド （1.90GHz） メモリ 16GB SSD 256GB 通信方式 有線LAN （最大1Gbps） 送信データパラメータ 再送 なし 同時送信 なし 送信間隔 1000ms 計測間隔 1000ms 送信時間 150s 負荷車両 CPU 8コア16スレッド （3.60GHz） メモリ 16GB SSD 256GB 通信方式 有線LAN （最大1Gbps） 送信データパラメータ 再送 なし 同時送信 なし 送信間隔 100ms 計測間隔 - 送信時間 100s 環境・パラメータ
- 28. 考察 クラウドのみのダイナミックマップシステムでは車両台数1600台程度が限界 エッジサーバを利用したダイナミックマップシステムでは3200台程度を低遅延で処理可能 車両走行車線区間を用いることで電波状況などに影響されずエッジサーバで管轄可能 膨大なデータ量を扱うダイナミックマップシステムにおけるスケーラビリティの向上に有効 28
- 29. まとめ
- 31. ご清聴ありがとうございました
Editor's Notes
- 目次は以下の通りとなっております．
- はじめに，研究背景についてです．
- 近年自動運転の実現に向けて研究開発が注目されておりますが，車載センサだけでは限界があり，協調型ITSの研究開発が盛んに行われています． 合流調停や信号情報取得など，複数のアプリケーションをそれぞれ実現するのは非効率で，ぞれぞれの情報を統合的に管理する，共通の情報通信プラットフォームである「ダイナミックマップ」が注目されています． ダイナミックマップの動的情報として，一般に100ミリ秒周期で車両からのデータは送信され，それらをもとにアプリケーションが動作するため，低遅延での情報処理が求められます． しかしダイナミックマップをクラウドに構築すると，処理負荷の集中や通信遅延の原因となり，スケーラビリティが懸念されます．
- そのため，携帯電話の基地局などにエッジサーバを配置した，エッジコンピューティングを用いたダイナミックマップシステムが有効ではないかと考えられています． これにより処理負荷の分散や通信遅延の軽減が期待されます． しかし，エッジサーバを配置してダイナミックマップシステムを構築すると，エッジサーバと車両との接続方法や車両の管理方法が問題となります． そこで本研究では，車両走行車線区間を割当てることによって効率的にエッジサーバを配置したダイナミックマップシステムを構築しました．
- 本研究で構築しましたダイナミックマップシステムについて説明します．
- 本研究で構築したダイナミックマップシステムは，クラウド，エッジサーバ，車両の三層構造からなります． ここでは，クラウド，エッジサーバ，車両をノードと呼び，各ノードはOS，通信部，DBシステム，アプリケーションの4層からなります． 各ノードは通信部を通じて通信を行い，各ノードのアプリケーションで処理が行われます． また，エッジサーバを配置したダイナミックマップシステムにおいて，大量の移動する車両とエッジサーバの通信を実現するため， 車両からエッジサーバへの通信にはエニキャストアドレス，エッジサーバから車両への通信にはマルチキャストを利用し構築しました．
- クラウドのみを利用するダイナミックマップシステムでは，車両からクラウドにデータを送信する場合は，車両のIPアドレスを送信元として，クラウドのIPアドレスを宛先とします． しかし，本システムではクラウドは車両からのデータを直接受信しませんので，車両へデータを送信する際に宛先が不明となります． そこで，エッジサーバは受信エリアに車両が侵入してきた時に一度だけクラウドに通知します． そうすることで，クラウドはどのエッジサーバがどの車両のデータを受信したのかを判別でき，エッジサーバを通じて通信が可能となります．
- 次に，車両走行車線区間によるエッジサーバの割り当てについて説明します． まず車両走行車線区間について説明致します．
- 本研究において，車両がエッジサーバへデータを送信する際に，GPSなどで測位した車両位置情報を地図データと照合し，当該車両が走行する車両走行車線区間に照らし合わせて，その情報をデータに付加してエッジサーバに送信します． この車両走行車線区間とは，車両が走行する道路の車線を特定の長さの区間に分け，それぞれの区間に固有のIDを割当てたものです． [Enter] 例としまして，図のような道路があった場合に，区間ごとに固有のIDを割当てたものとなります．
- 例としまして，図のような道路があった場合に，区間ごとに固有のIDを割当てたものとなります． この分割された地理エリアの情報を管理するエッジサーバを割当てます．
- エッジサーバの色ごとに車両走行車線区間を色づけており，車両走行車線区間ごとに情報を管理するエッジサーバを割当てています． これにより，エッジサーバは車両から送信されたデータ内の車両走行車線区間情報から，その車両の情報を管轄するエッジサーバを判別することが可能となります．
- このとき，図のように，各車両走行車線区間の管轄エッジと，それぞれの車両走行車線区間におけるデータの受信エリアが一致していた場合がこのような状況です．
- このような状況の時，エッジサーバBに交差点における調停アプリケーションが実装されていたとします． T字路の下と右に車両がいます． それぞれ車両が進んできて，青色の車両がエッジサーバCの管轄エリアからエッジサーバBの管轄エリアに移動すると，エッジサーバBは交差点調停開始します．[Enter] 優先道路を走る黄色の車両もエッジサーバDの管轄エリアからエッジサーバBの管轄エリアに移動してきました．[Enter] すると，エッジサーバBは非優先道路を走る青色の車両が交差点に侵入すると危険なため，停止するよう指示を出します．[Enter] その後，黄色の車両が通過したことを確認してからエッジサーバBは青色車両に発進可能指示を出し，調停を行います．[Enter]
- 流れとしてはこのような形になります．
- しかし，実際の電波状況などからエッジサーバの受信エリアと管轄エリアが一致するとは限りません． このような場合，単一のエッジサーバで動作するアプリケーションでは処理ができなくなる可能性があります． また，合流調停のように交差点周辺の車両から情報を受信して，車両の走行状況を判断しなければならないアプリケーションがエッジサーバに実装されている場合，そのエリアのすべての車両の情報をエッジサーバに集める必要があります．
- このような状況のときに，エッジサーバBに交差点における調停アプリケーションが実装されていたとします． 先程と同じく，T字路の下と右から車両が来ています．[Enter] この時，車両走行車線区間による管理をしていない場合，青色の車両がエッジサーバBの管轄エリアに侵入してもそこがエッジサーバCの受信エリアであればエッジサーバBの調停アプリケーションでは車両が存在していないと認識されてしまいます． すると，黄色車両の侵入も認識されず，優先道路の走行車両なしと判断され，青色車両に発進許可がされてしまいます．[Enter] 事故の原因となりかねません．
- そこで，本システムでは車両走行車線区間を用いてエッジサーバ間でデータ転送を行います． 車両はGPSなどから測位した位置情報から得た車両走行車線区間をデータに載せてエッジサーバに送信します．[Enter] すると，青色車両はエッジサーバCの受信エリアにいながら，エッジサーバBの管轄エリアに侵入すると，エッジサーバCが受信したデータをエッジサーバBに転送します．[Enter] また，黄色車両に関しても，エッジサーバDの受信エリアにいながら，エッジサーバBの管轄エリアに侵入すると，エッジサーバDが受信したデータをエッジサーバBに転送します．[Enter] この機能によって，エッジサーバBは優先道路を走行する黄色車両の存在を認識でき，青色車両に一時停止するように調停を行うことができます．[Enter] [Enter] 車両走行車線区間転送を用いることで，このように調停範囲の車両のデータをエッジサーバが直接受信できなくても，電波状況などに影響されることなく車両から管轄エッジサーバにデータを送信することが可能となります．
- 流れとしてはこのような形になります．
- 車両走行車線区間転送機能について実証実験を行いましたので，動画を御覧ください． まず，道路を3つのレーン，車両走行車線区間にわけ，それぞれの車両走行車線区間を管轄するエッジサーバを割当てます． 今回の実験では車両走行車線区間転送機能について実験しましたので，エッジサーバの受信エリアと管轄エリアがズレるように車両走行車線区間を割当てました． 4つの図の内，左側2つが地図上の車両位置，右側2つがエッジサーバ503が見えている車両位置になります． 上の転送機能なしでは，管轄エリアと受信エリアがズレている場所に関しては車両の位置を把握することができません． しかし，下の転送機能ありでは，車両データを転送し，エッジサーバ503からエッジサーバ502の受信エリアにいる車両を見ることができています．
- 評価としまして，提案システムのスケーラビリティを評価するために，2つのシステムで負荷実験の評価を行いました． 1つ目がクラウドによるダイナミックマップシステムです． 2つ目がエッジサーバを配置した三層構造ネットワークによるダイナミックマップシステムです．
- 構築しましたシステムの環境とパラメータはこのようになっております． エッジサーバを用いた三層構造ネットワークではエッジサーバを2台用意しました． 左下の写真の上にあるPCが車両，ルータが数台あり，真ん中の4台が負荷用のPC，下の3台がクラウド・エッジサーバPCです． 計測対象の車両は1秒間隔ごとに150秒間データを送信し続け，計測を行います． その間に負荷車両台数を変化させて100ミリ秒間隔ごとに100秒間データを送信し，負荷評価を行いました．
- まずはクラウドによるダイナミックマップシステムの評価です． これはデータの流れですが，車両はセンサ情報などを車両のアプリケーションにて取得し，通信部を通じてクラウドへと送信します． データはクラウドのキューに一時格納され，転送対象でなければ再度別のキューへと格納されますが，クラウドによるダイナミックマップシステムでは転送などは行われません． その後，上位アプリケーションへと送信され処理が行われます． この際の，クラウドがデータを受信した時刻（t1）からアプリケーションにて処理が完了した時刻（t2）までを遅延時間として測定します． またその際にクラウドの通信部にあるキューにデータがどれだけ溜まっているかというキューサイズについても測定しました．
- 評価結果ですが，横軸が経過時間，縦軸が処理遅延時間とキューサイズ値になっております． また，2本の緑の縦線で挟まれた範囲，これが負荷車両からデータを送信した100秒間の範囲になります． グラフは青色が処理遅延時間，オレンジと灰色がキューサイズ値を表しています． クラウドによるダイナミックマップシステムにおいて，負荷車両台数を変化させて評価しました． 左上の負荷車両台数1000台や右上の1600台では大きくキューサイズが溜まったり，処理遅延が発生したりということはありませんでした． しかし車両台数1700台を超えるとキューサイズが大きく増加し，車両台数1700台では処理遅延時間が最大1800ミリ秒程度，車両台数2000台では20000ミリ秒程度発生しました． ＊全体を説明 縦軸，横軸，4つは車両台数，それ以外は同じ条件，結果が変わる境目 1700と2000で縦軸が違うことを説明 横軸はシミュレーション時刻 緑の線は結果ではないことを説明 背景の色を変えるのもアリだが論文と合わせる 銭の説明はポインタを利用 実証実験はNTTを利用，定量的評価は自分たちで構築
- 次にエッジサーバを用いた三層構造ネットワークによるダイナミックマップシステムの評価です． データの流れですが，負荷車両は2台のエッジサーバにそれぞれデータを送信します． また計測車両は，管轄エッジサーバが受信エッジサーバと異なるものとし，転送対象である管轄エッジサーバに転送します． この際の，受信エッジサーバがデータを受信した時刻（t1）から管轄エッジサーバのアプリケーションにて処理が完了した時刻（t2）までを遅延時間として測定します． またその際に受信エッジサーバのキューサイズについても測定しました．
- 評価結果ですが，左上の負荷車両台数2000台や右上の3200台では大きな処理遅延は発生しませんでした． しかし，車両台数が3400台を超えるとキューサイズが大きく増加し，車両台数3400台では処理遅延時間が最大1800ミリ秒程度，車両台数4000台では20000ミリ秒程度発生しました．
- 考察ですが，単一のクラウドにデータ管理機能を集中させたダイナミックマップシステムでは車両台数1600台程度までしか処理ができませんでしたが， 提案システムであるエッジサーバを用いた三層構造ネットワークによるダイナミックマップシステムでは，エッジサーバを2台用意することでクラウドによるダイナミックマップシステムの2倍の3200台程度まで低遅延で処理が可能となりました． 本研究では，エッジサーバと車両の関係を結びつけるために車両走行車線区間を用いましたが，計測車両においてエッジサーバ間で転送を行うことでダイナミックマップシステムの有効性を示せております． 評価結果より，電波状況などに影響されることなく遅滞の少ないダイナミックマップシステムが構築でき，提案システムが膨大なデータ量を扱うダイナミックマップシステムにおけるスケーラビリティの向上に有効であると考えられます．