システム開発
1８－F－５

センタレスプローブ情報システムの開発に関するフィージビリティスタディ
報

告書－ 要 旨 －

平成 1９年 3 月

財団法人

機械システム振興協会

委託先 財団法人日本自動車研究所

この事業は、競輪の補助金を受けて実施したものです。
URL : http://keirin.jp/

序

わが国経済の安定成長への推進にあたり、機械情報産業をめぐる経済的、社会的諸条件は急速な変化を見せており、社会生活における環境、都市、防災、住宅、福祉、教育等、直面する問題の解決を図るためには技術開発力の強化に加えて、多様化、高度化する社会的ニーズに適応する機械情報システムの研究開発が必要であります。
このような社会情勢の変化に対応するため、財団法人機械システム振興協会
では、日本自転車振興会から機械工業振興資金の交付を受けて、システム技術
開発調査研究事業、システム開発事業、新機械システム普及促進事業を実施しております。
こ のう ち 、 シス テ ム 技術 開 発 調査 研 究 事業 及 び シス テ ム 開発 事 業 につ い て は 、
当協会に総合システム調査開発委員会(委 員長：政策研究院 リサーチフェロー
藤正 巖氏）を設置し、同委員会のご指導のもとに推進しております。
本「センタレスプローブ情報システムの開発に関するフィージビリティスタ
ディ」は、上記事業の一環として、当協会が本スタディを財団法人日本自動車研究所に委託し、実施した成果をまとめたもので、関係諸分野の皆様方のお役に立てれば幸いであります。
平成１９年３月
財 団 法人 機械システム振興協会

は

じ

め

に

ITS（Intelligent Transport Systems）はこれまで約１０年間の個別システムの研究開発が中心であったファーストステージから、より目的志向で各種システムを融合したトータルな応用、普及を考えていくセカンドステージに移行しつつある。その効果については、安全、環境、利便のそれ
ぞれの分野でさらなる期待が持たれている。
このような中で、インターネットが与えてくれるオープンな情報通信基盤を使い、自動車が得られる情報を多数の車から収集、統計処理して交通情報や道路環境情報、気象情報など有益な価
値ある情報として生成し、情報の共有、提供を目指す「プローブ情報システム」が注目され、国内外で検討されてきた。これは車を「動くセンサー」と位置づけ、プローブ情報をネットワーク
社会の価値ある情報資源にしていこうというものである。
このプローブ情報システムについてはこれまで国内においても、プロトタイプの車載機によるフィールド実証実験が実施され、渋滞検出アルゴリズムの有効性を検証するなどの開発が行われてきている。これまで検討されてきたプローブ情報システムは、プローブカーから情報を収集させる情報センターを持ち、集約された情報を車に配信するというセンター型のプローブ情報シス
テムであった。しかし、例えば道路上の安全に関する情報など特定の地域でのみ必要性があり，かつ即時性が求められる情報については、ある事象の近辺で直接その情報が得られる何台かの車がプローブカーとなり、信頼できる情報をアドホックなネットワークにより生成して、それを車車間通信によってリレー式に情報を移動させることにより、必要とする別の場所にいる車に伝えていく「センタレスプローブ情報システム」という概念がより有効ではないかという考え方が生まれてきている。
本報告書はこの「センタレスプローブ情報システム」の考え方に注目し、財団法人機械システ
ム振興協会の平成１８年度委託事業として、情報収集、伝達アルゴリズムの開発、シミュレーシ
ョンとフィールド実車実験によるシステムの実現性、有効性を検証するフィージビリティスタデ
ィを行った結果を報告するものである。
本研究開発にあたっては、センタレスプローブ研究委員会（委員長赤羽弘和

千葉工業大学教授）を設置し、学識経験者、自動車メーカー、電気通信機器メーカー、関係事業者、シンクタ
ンクなどの協力を得て検討を行った。この場を借りて、多数の関係者のご指導とご協力に心より感謝申し上げる次第である。

平成１９年３月
財団法人 日本自動車研究所

センタレスプローブ情報システムの開発に関するフィージビリティスタディ
－ 要 旨 －
目 次
序
はじめに

1.

スタディの目的2.

スタディの実施体制

3.

スタディの内容--------------------------------------------------------------------

1--------------------------------------------------------------

2--------------------------------------------------------------------

7

3.1 センタレスプローブの活用----------------------------------------------------------

11

3.1.1 センタレスプローブの概要--------------------------------------------------

11

3.1.2 センタレスプローブの開発課題--------------------------------------------

11

3.1.3 センタレスプローブの活用--------------------------------------------------

12

3.2 センタレスプローブ処理アルゴリズムの開発-----------------------------------

15

3.2.1 センタレスプローブ処理アルゴリズムの概要--------------------------

15

3.2.2 渋滞情報生成アプリケーションの基本動作-----------------------------

16

3.2.3 渋滞情報生成アプリケーションの機能仕様-----------------------------

19

3.3 情報伝達アルゴリズムの開発-------------------------------------------------------

21

3.3.1 情報伝達アルゴリズムの概要-----------------------------------------------

21

3.3.2 アプローチ-----------------------------------------------------------------------

21

3.3.3 設計--------------------------------------------------------------------------------

24

3.4 シミュレーションによる評価-------------------------------------------------------

29

3.4.1 評価用シミュレーションプラットフォームの概要--------------------

29

3.4.2 評価用シミュレーションプラットフォームの機能仕様--------------

31

3.4.3 クラスコンポーネントの設計と実装--------------------------------------

32

3.4.4 評価用シミュレーションシナリオ-----------------------------------------

32

3.4.5 センタレスプローブ処理アルゴリズムのシミュレーションによる評価--------------------------------------------

33

3.4.6 情報伝達アルゴリズムのシミュレーションによる評価--------------

37

3.5 車載機の開発-----------------------------------------------------------------------------

43

3.5.1 車載機の概要--------------------------------------------------------------------

43

3.5.2 車載機ソフトウェアの設計--------------------------------------------------

43

3.5.3 車載機ソフトウェアの実装--------------------------------------------------

45

3.5.4 車載機の評価試験--------------------------------------------------------------

48

3.6 車載機によるフィールド実験評価-------------------------------------------------

51

3.6.1 フィールド実験の概要--------------------------------------------------------

51

4.

3.6.2 センタレスプローブ処理アルゴリズムの評価--------------------------

56

3.6.3 情報伝達アルゴリズムの評価-----------------------------------------------

56

スタディの今後の課題及び展開--------------------------------------------------------

61

１．スタディの目的(1)

背景、必要性

プローブ情報システムは、自動車の持つセンサ情報を、情報通信基盤を用いて収集し、統計処理等を施すことによって交通情報、環境情報、気象情報等、有益な価値ある情報を生成し、情報の共有、提供を行うシステムである。
これまで、自動車の持つセンサ情報をプローブデータとして情報センタに収集し、処理を施すことによりプローブ情報を生成するシステムの研究開発を行い、社会実験により有用性、技術的実現性を確認してきた。このようなシステムをセンタ型プローブ情報システ
ム(以下、「センタ型プローブ」)と呼ぶ。
センタ型プローブの普及、拡大のための問題点として、①通信コストが高いこと、②情報センタ負荷が大きいこと、③不感地帯(通信ができない領域)の存在、④業界間(ステークホルダ)の調整が複雑など、社会実験によりクローズアップしてきた。

(2)

目的

情報センタやインフラ設備を伴う情報通信基盤を用いることなく、車車間通信を利用して車両間で情報を流通させ、車載機だけでプローブデータの収集、プローブ情報の生成、提供を行うプローブ情報システムをセンタレス型プローブ情報システム(以下、「センタレスプローブ」)と呼ぶ。
センタレスプローブは車車間通信を利用するため①通信コストの問題は発生しなく、②
情報センタを活用しないため情報センタ負荷の心配もなくなる。又、将来的にセンタ型プ
ローブと連携を図り、センタレスプローブがエリア毎に稠密に収集した危険情報の提供など安全運転支援サービス拡充や、プローブデータの収集、プローブ情報の提供エリアの拡大が可能となる。
本スタディでは、プローブ情報システムに求められる情報の流通を、車車間通信(無線方式)で実現するためのコア技術である情報伝達アルゴリズムの開発を行い、生成したプロー
ブ情報の正確性や、必要な車両にプローブ情報が的確に提供されるかなど、センタレスプ
ローブの技術的実現性の評価を行い、センタレスプローブの実用化に資する。

２．スタディの実施体制
本スタディを進めるにあたり(財)機械システム振興協会内に「総合システム調査開発委員会」を、(財)日本自動車研究所においては、委員会組織として「センタレスプ
ローブ研究委員会」、作業班として「システム開発ワーキンググループ」を組織し、学識経験者の指導の下、産学連携の研究開発を実施した。

(財)機械システム振興協会

総合システム調査開発委員会

委託(財)日本自動車研究所

センタレスプローブ研究委員会

再委託
慶應義塾大学 SFC 研究所

システム開発ワーキンググループ・情報伝達アルゴリズムの開発(株)ｱｲ･ﾄﾗﾝｽﾎﾟｰﾄ･ﾗﾎﾞ
・センタレスプローブ情報処理アルゴリズムの開発
アイシン精機(株)・車載機プラットフォームの開発
NEC ソフト(株)・車載機ソフトの開発

総合システム調査開発委員会
委員名簿（順不同・敬称略）
委員長

政策研究院

藤

正

巖

太

田

公

廣

金

丸

正

剛

志

村

洋

文

中

島

一

郎

廣

田

藤

岡

健

彦

大

和

裕

幸

リサーチフェロー
委員

埼玉大学
地域共同研究センター
教授

委

員

独立行政法人産業技術総合研究所
エレクトロニクス研究部門
副研究部門長委

員

独立行政法人産業技術総合研究所
産学官連携部門
コーディネータ

委員

東北大学
未来科学技術共同研究センター
センター長

委

員

東京工業大学大学院

薫

総合理工学研究科
教授
委員

東京大学大学院
工学系研究科助教授

委員

東京大学大学院
新領域創成科学研究科教授

センタレスプローブ研究委員会
委員名簿
（敬称略）
委員長

赤羽 弘和

千葉工業大学

工学部建築都市環境学科

副委員長

砂原 秀樹

奈良先端科学技術大学院大学

委員

堀口 良太

株式会社アイ・トランスポート・ラボ

委員

小室 健一

アイシン精機株式会社

長谷川 光洋アルパイン株式会社

委員

時津 直樹

インターネットITS協議会

委員

村上 陽志

NECソフト株式会社

情報科学研究科教授

代表取締役

グループマネージャ

ITS技術部第1開発グループ委員

教授

新事業製品開発部
事務局長

第一官庁ソリューション事業部第二システム部
委員

植原 啓介

慶應義塾大学大学院

委員

佐藤 雅明

慶應義塾大学大学院

政策･メディア研究科

政策･メディア研究科
委員

石田 剛朗

助教授

特別研究助手慶應義塾大学
デジタルメディア・コンテンツ統合研究機構

委員

田中 修一

部長

助手

株式会社ケンウッド
戦略技術開発センタ先行技術開発部

主幹

委員

吉川 憲昭

株式会社サイバー創研

取締役

委員

渡邉 恭人

千葉商科大学委員

塚本 晃

株式会社デンソー

委員

秋山 由和

トヨタ自動車株式会社

IT・ITS企画部技術室

室長

委員

山村 秀弥

株式会社豊田自動織機

NE事業室技術第一部

課長

委員

伊藤 修朗

株式会社豊田中央研究所

政策情報学部

助教授

ITS開発部第2開発室

車両・安全・ITSセンターITS第1研究室
委員

佐藤 彰典

熊谷 正俊

室長

日本電気株式会社
ITS事業推進センター委員主幹

株式会社日立製作所

シニアマネージャー
日立研究所情報制御第二研究部

委員

野田 茂

富士通株式会社

次世代 IT･ITSﾌﾟﾛｼﾞｪｸﾄ室

委員

今池 正好

株式会社FEACインターナショナル

委員

高橋 弘行

マツダ株式会社委員

柏原 正信

三菱電機株式会社

代表取締役

技術研究所情報通信グループ

自動車機器開発センター開発企画部
委員

内田 吉陽

専任

ヤマハ発動機株式会社
MC事業本部技術統括部技術開発部

ｵﾌﾞｻﾞｰﾊﾞ

担当部長

主事

経済産業省

事務局

加瀬川 憲道財団法人 日本自動車研究所

事務局

和田 光示

財団法人 日本自動車研究所

ITSセンター

ITS センター企画・研究グループ

センター長

主席研究員

システム開発ワーキンググループ
メンバー名簿
（敬称略）
リーダ

植原 啓介

慶應義塾大学大学院
政策･メディア研究科

委員

佐藤 雅明

慶應義塾大学大学院
政策･メディア研究科

委員

石田 剛朗

助教授

特別研究助手慶應義塾大学
デジタルメディア･コンテンツ統合研究機構

委員

堀口 良太

株式会社アイ・トランスポート・ラボ

委員

小出 勝亮

株式会社アイ・トランスポート・ラボ

委員

小室 健一

アイシン精機株式会社
ITS技術部第1開発グループ

委員

清水 克正

春田 仁

代表取締役

グループマネージャ

アイシン精機株式会社
ITS技術部企画開発グループ

委員

助手

主担当

NECソフト株式会社
第一官庁ソリューション事業部第二システム部

委員

党 聡維

NECソフト株式会社
第一官庁ソリューション事業部第二システム部

委員

今池 正好

株式会社FEACインターナショナル
慶應義塾大学

事務局

和田 光示

代表取締役

研究員

財団法人日本自動車研究所
ITS センター企画･研究グループ

主席研究員

主任

３．スタディの内容
センタレスプローブは、センタレスプローブ対応車載機同士が周辺の車両とネットワー
クを形成し、車両間の自律的な連携によって情報を流通させ、プローブデータの収集、処理を行い、質や精度が高いプローブ情報を生成、提供するシステムである。
本スタディでは、これらを実現するアルゴリズム、車載機の開発を行い、シミュレーシ
ョン及び実証実験で評価し、センタレスプローブの有効性を確認する。
車載機に実装するシステムの概要を図 1 に示す。このシステムは、車車間通信機能、車車間通信を利用してプローブ情報を効果的に流通させるための情報流布機能、情報流布機
能によって交換されたプローブ情報に統計処理などを加え、より有用な情報に昇華させるためのセンタレスプローブ処理機能から構成される。

センタレスプローブ処理アルゴリズム

センタレスプローブ機能
メッセージプール

参照

消費

供給
メッセージ

情報流布機能情報伝達アルゴリズム

車車間通信
車車間通信
図 1 センタレスプローブのシステム概要
平成 18 年度は、情報流布機能とセンタレスプローブ処理機能を実現するアルゴリズムの開発と、その動作を確認するためシミュレーションによる評価を実施する。又、ここで開発したアルゴリズムの一部を実装した車載機を開発し、小規模なフィールド実験を実施する。以下に、スタディ内容を具体的に説明する。

(1)

センタレスプローブの活用

プローブ情報システムの一形態であるセンタレスプローブの有用性、用途、及び今後の活用について概括する。

(2)

センタレスプローブ処理アルゴリズムの開発

センタレスプローブ処理機能は、情報流布機能によって交換された情報を車載機で処理することによって、交通情報や環境情報、気象情報等に有益な価値ある情報を生成する機能である。本開発では、受け取った(未完成の)プローブ情報を処理し、適切な車載機に引き渡し処理を繰り返すことでプローブ情報として完成させるセンタレスプローブ処理アルゴリズムを開発する。
生成するプローブ情報の種類によって、センタレスプローブ処理アルゴリズムは異なる。
平成 18 年度の研究開発では、渋滞情報の生成、提供をテーマにアルゴリズムの開発を行う。
(3)

情報伝達アルゴリズムの開発

情報流布機能は、効率良く、速やかに適正な範囲に情報を伝達する機能である。このため、どの情報をどのようなタイミングでどこに向けて送信するかコントロールすることが鍵となる。本開発では、車車間通信による電波の輻輳を減らし、かつ的確な方向へ情報を流通させるため、車両の移動(方向、速度など)や位置などで構成される時空間メタ情報を活用した情報伝達アルゴリズムを開発する。
センタレスプローブでは、通信相手を明示的に指定してデータを送信する通常のインターネット通信と異なり、明示的に相手を指定することなく求められる時間内に適切な範囲に情報を伝達する必要がある。そこで、データや情報を含むメッセージに時空間メタ情報を付加し、これによって優先付けを行いながら情報を流通させる必要がある。そのため、メッセージ交換に必要な時空間メタ情報の検討、メッセージプールから次に送るべきメッ
セージを選択するためのアルゴリズム、通信のコリジョンを削減するためのプロトコルなどの開発を行う。

(4)

シミュレーションによる評価

上記(1)、(2)で開発したセンタレスプローブ処理アルゴリズムと情報伝達アルゴリズムが実用に耐えるレベルであることをシミュレーションで確認する。
センタレスプローブ処理アルゴリズムの評価では、現実に起きている渋滞状況をどれく
らい正確に表しているかという観点でアルゴリズムを評価する。具体的には、シミュレー
ションで設定したパラメータ(擬似的に作り出した渋滞状況)と、センタレスプローブ処理
アルゴリズムで生成した情報の乖離率などを検証する。
情報伝達アルゴリズムの評価では、渋滞情報の提供要件(例えば半径 1km の範囲に、渋滞を検出してから 5 分以内に配信など、プローブ情報が提供される範囲と配信に必要とする時間)を満たすことを検証する。
(5)

車載機の開発上記(1)、(2)で開発したアルゴリズムをフィールドで確認するため、一部機能を実装した
車載機の開発を行う。

(6)

車載機によるフィールド実験による評価

上記(5)で開発した車載機を使って、アルゴリズム検証のため限定的なフィールド実験を実施する。実験では、開発したアルゴリズムの動作を確認するとともに、実験で得られた
結果をシミュレーションにより評価したアルゴリズムに反映する。

3.1

センタレスプローブの活用

プローブ情報システムは、自動車の持つセンサ情報を、情報通信基盤を用いて収集し、統計処理等を施すことによって交通情報や環境情報、気象情報等、有益な価値ある情報を生成し、情報の共有、提供を行うシステムである。現状のプローブ情報システムは、セン
サ情報をプローブデータとして情報センタに集積し、加工、配信する。これに対して、情報センタを利用しないで、車載機だけでプローブデータを収集し、プローブ情報に加工、配信するプローブ情報システムを、(システムに情報センタが存在しないという意味で、)
センタレスプローブ情報システムと命名した。以下、センタレスプローブ情報システムをセンタレスプローブという。センタレスプローブについての概要、開発課題、その活用について述べる。

3.1.1

センタレスプローブの概要

プローブ情報サービスの普及促進を図るため、本スタディではインフラ設備を伴う通信基盤や情報センタを使わずに、(無線 LAN による)車車間通信を使用し、車載機だけでプローブデータの収集、プローブ情報の生成、提供を行うことができるプローブ情報システムを検討した。情報センタにプローブデータを集積し、処理、配信するプローブ情報システ
ムをセンタ型プローブ情報システムとすると、本スタディで検討するプローブ情報システ
ムは、センタレス型プローブ情報システム、略してセンタレスプローブと呼ぶこととした。
センタレスプローブを実現するために、車載機として車車間通信機能の他に、プローブ
データを処理しプローブ情報を生成する機能、プローブ情報を的確に流通させる機能を保有する車載機が必要となる。

3.1.2

センタレスプローブの開発課題

車両で発生したプローブデータを、すべて一つの情報センタに集めて処理する従来の方法に対して、センタレスプローブではそれらを車載機で行わなければならない。そのために、必要なプローブ情報は車載機間で的確に流通しなければならない。センタ型プローブの場合、広域の通信基盤を使用し、どのプローブカーでもアクセスポイントを経由して、いつでも情報センタにプローブデータを送信することができる。一方、センタレスプロー
ブの場合、通信手段として無線 LAN を使用するので、その通信エリア(見通しがよく、マルチパスなどの電波障害が発生しない場合は 1km 弱飛ぶことがあるかもしれないが、通常都市部では 100m 程度)内に、他の車両が存在するとき初めて通信が可能となる。しかも、センタ型のように情報センタのノードが定まっていない。このような状況を考えると、センタレスプローブ実現のための第一の課題は、無線 LAN による車車間通信を用いて、的確に情報を流通させることである。
センタレスプローブに求められる情報流通制御は二つに大別できる。一つはプローブ情報配信に係る情報流通制御であり、もう一つはプローブデータの収集に係る情報流通制御
である。プローブ情報を配信するとき、その配信先の車両が車車間通信のエリア内にいる場合は問題がない。例えば、路面凍結などで、車両がスリップした情報を後続の車両に知らせるケースで、車車間通信のエリア内に後続の車がいるときは、情報流通制御を必要としない。しかしながら、渋滞に遭遇したとき、車車間通信の狭いエリア内を走行する後続の車に、この先渋滞であることを伝えても余り意味がなく、渋滞を回避する選択肢を有する車両に伝えることが肝要である。例えば、図 3.1-1 に示す交差点の手前にいる車両に渋滞情報を提供して、初めてプローブ情報が有効に活用されたことになる。しかしながら、
車車間通信エリアはそれ程広くない。これを実現するためには車車間通信のエリアをまたいで、渋滞情報を配信しなければならない。これを実現するのが情報流通制御技術であり、本スタディでは情報伝達アルゴリズムと呼んでいる。

車々間通信のエリア

交差点の手前にいる後方
車両に「渋滞情報」を提供

渋滞だ!

ここで左折

この先
危ない

エリアの情報流通

スリップ！

車々間通信のエリアをまたぐ
プローブ情報の流通即時性が求められる情報の迅
速な共用

地域性の高い情報の流通

図 3.1-1

センタレスプローブで要求される情報流通の例(その 1)

他方のプローブデータの収集に係る情報流通制御は、プローブ情報生成に係るものである。1 台のプローブカーが走行していて、ある道路リンクを走行する速度が極端に低下した場合、渋滞に遭遇したと考えられる。一方で、コンビニに寄って、速度が低下したことも考えられる。それ故、1 台のプローブカーのデータだけで渋滞が発生したと判断すると、誤ったプローブ情報を配信する可能性がある。センタ型プローブの場合は、複数の車両から送られてくるプローブデータから判断して、渋滞かどうか確認することができる。センタレスプローブの場合、複数の車のデータに基づき判断するためには、1 台の車から渋滞を示唆する情報が送信された場合、渋滞が発生したと思われる近傍に渋滞情報を留めおき、ある時間内(例えば 15 分)に複数の車から同じ情報が重複して発信されたとき、渋滞情報として配信する仕組みが必要となる(図 3.1-2 参照)。そのためには、一定の期間、渋滞情報をその近辺に留めおくような情報流通制御が必要となる。
3.1.3

センタレスプローブの活用

センタ型プローブには二つの形態がある。路車間通信を活用するものと、広域の移動体
通信サービスを活用するものである。路車間通信を活用する代表的なシステムとして VICS

情報を渋滞が発生した近辺に
停滞させる
位置

Ｎ

Ｂ

Ａ
Ａ
Ｂ

Ｎ

Ａ

Ｂ
Ｎ
渋滞情報の生成時間

車載機は自車のプローブデータ(センサーデータ)を収集、渋滞情報に処理(加工)し、次の車両に送る。ｎ台の車載機で処理することにより、渋滞情報を生成する。

図 3.1-2

センタレスプローブで要求される情報流通の例(その 2)がある。又、広域の移動体通信サービスを活用するものとしては、2003 年に名古屋で行われたプローブの実験システムや、H カーメーカが提供しているインターナビ・プレミアム
クラブが挙げられる。
サービスエリアの広さ、情報配信の確実性、即時性、取り扱う情報量、収集と配信に発生する費用の項目毎に、プローブ情報システムを比較する。その結果を表 3.1-1 に示す。
表 3.1-1

センタ
型
プロー
ブ

センタ型プローブ情報システムとの比較

エリア

確実性

即時性

情報量

費用

サービスの特徴

路車間
通信
活用

路側機の
近辺でし
か収集、
提供でき
ない

情報の提
供はpush
型であり
確実性が
高い

情報提供
の即時性
が高い

提供され
るサービ
スは限定

路側機の
設置費用
が発生

幹線道路など交
通量が多い場所
で、確実な情報
収集、提供

移動体
通信
ｻｰﾋﾞｽ
活用

サービス
の提供を
受けるエ
リアは広
く、場所
に制限は
ない

情報の提
供はpull
型であり、
要求しな
いと情報
が提供さ
れない

広域に同
時情報提
供が可能

多様な
サービス
提供が可
能

情報の収
集、提供
毎に通信
費用が発
生

広域をカバーした情報の収集、提供、特に遠隔の情報収集、同時配信に優れる

車載機搭載 情報の提供
車両が近辺 はpush型でにいないと あるが、確機能しなく、実性は周囲収集、提供 の車両次第できるエリ で変わる
アに制限が
ある

センタ経由
でなく車両
間で情報を
交換するた
め即時性に
優れるが、
周辺の車両
次第

多様なサー
ビス、情報
量が豊富な
サービスが
可能

路側機の設
置、通信費
用は発生し
ない

車載機搭載車両数に依存
狭域の情報収集、提供は即時性、情報量が豊富センタレス
プローブ

道路ネットワークのタイプ別に、センタレスプローブの用途を表 3.1-2 にまとめた。
プローブ情報システムの形態として、センタレスプローブだけとは決して考えていない。
むしろ、センタレスプローブはセンタ型プローブでは補うことができなかったエリアの情表 3.1-2
道路ネットワーク

交通量

多い
全方向

都市部道路網センタレスプローブの用途
交通情報インフラ

期待されるセンタレスプローブの位置づけと情報アプリ

比較的密に配備（幹線道路中心）

他プローブとの通信機会が多ければ、インフラがカバーしていない非幹線道路も含めた交通情報を収集・統合し、地区内の車両間で共有できる。
→地区レベルの交通情報アプリ

郊外部道路網少ない
全方向

一部の幹線道路に配備されている

他プローブとの通信機会が少ないので、自車情報を交通情報インフラの位置まで届ける役割が相対的に大きくなる。多少の時間遅れは許容されるべき。
→工事・事故などによる突発的な渋滞の検出

都市間高速道路

多い
往復方向（時間
ピークは違う）

間隔が長い（IC間に1つのビーコン）

感知器が密に配備されていない大都市近郊
以外の路線では、IC間での渋滞状況を（渋滞していない）対向車線のプローブに伝達し、速やかに渋滞情報をビーコンに届ける。
→渋滞区間(先頭、末尾)検出アプリ

ほとんどない（道の駅など）インフラ整備の優先度が低い地域でも、観光地など、季節・曜日によるピーク変動が大きいところでは、交通情報へのニーズが高い。インフラへの依存度が小さい交通情報システムとして、期待される。
災害時のロバストな情報システムとしての位置づけも考えられる。
→突発渋滞・通行障害検出アプリ、etc。

地方部の路線状
幹線道路

少ない
往復方向（時間
ピークは違う）

報提供や、ローカルなコンテンツをカバーする手段として、有効に活用できると考える。
よって、真にセンタレスプローブが活用されるためには、センタ型プローブとの連携、役割分担が必要となっていくものと考える。連携のイメージを記したものを図 3.1-3 に示す。

周辺車両情報をまとめて処理し、送信
情報センタ

中継基地局から情報センタ
へ送信

センタ型車
載機から情
報センタへ
送信

鍵となる技術•車々間通信とIPv6の融合•安全な情報交換の為のセキュ
リティ・認証地域性の高い
詳細情報の流通即時性が求められる
情報のpush型提供

限定された地域で利用される地
図や渋滞情報図 3.1-3

センタレスプローブとセンタ型の連携

センタレスプローブ処理アルゴリズムの開発

3.2
3.2.1

センタレスプローブ処理アルゴリズムの概要「センタレスプローブ処理アルゴリズム」とは、図 3.2-1 のセンタレスプローブ情報（車載）システムにおいて、特定の目的を持つ「センタレスプローブ情報アプリケーション」
として実装されるものの総称である。

情報伝達管理モジュール（情報伝達アルゴリズム）
通信
モジュール

車両情報
モジュール

センタレスプローブ
情報システムセンタレスプローブ
処理アルゴリズムを実装したアプリ群

プローブ情報プローブ情報
…
アプリ#1
アプリ#n

車載器OS
車載器HW
GPS
図 3.2-1

各種センサ

センタレスプローブ情報車載システムにおける
センタレスプローブ処理の位置づけ

センタレスプローブ情報アプリケーションには、様々な目的・種類のものが考えられる。
従って、1 台のセンタレスプローブ情報（車載）システムには、センタレスプローブ処理
アルゴリズムを実装した複数のアプリケーションが同時に稼働する形態となる。
一般に、センタレスプローブ処理アルゴリズムは、以下の機能を有する。
① 自車の走行状態をモニタし、他車に伝達すべき情報を生成する。
② メッセージプールに格納されているセンタレスプローブ情報のうち、そのアプ リ
ケーション自身に関連する情報のみを選択的に取得する。
③ 自車情報、及び他車情報を統合し、より品質の高い情報として再構成する。
④ 自車情報、及び統合処理した情報をメッセージプールに格納する。
これらの機能は、図 3.2-2 の「センタレスプローブ処理モジュール」に実装される。

センサ

センタレスプローブカー

センサ情報（GPS緯度・経度,方向,速度）

車載機

車両情報収集

センタレスプローブ処理
プローブ情報アプリケーション
収集プローブ情報（参照）

生成過程プローブ情報（参照／供給）センタレスプローブ処理
アルゴリズムを実装

完成プローブ情報（供給）
メッセージプール

情報伝達

情報伝達管理情報伝達アルゴリズムを実装

情報滞留・配信判定
生成過程プローブ情報（完成度100％未満）
完成プローブ情報（完成度100%）

プローブ情報受信
プローブ情報近 隣センタレス
近隣センタレスプ
ローブカー
プローブカー

図 3.2-2

プローブ情報送信

車車間通信

生成過程プローブ情報
完成プローブ情報・情報伝達空間パターン
近隣センタレスプ
近 隣センタレス
・到達位置を満たす車両ローブカー
プローブカー

センタレスプローブ情報処理システムのモジュール構成

本年度は、後述のシミュレーション実験、及び実証実験で動作を検証する対象として、
以下に述べる「渋滞情報生成アプリケーション」を開発した。

3.2.2

渋滞情報生成アプリケーションの基本動作

本年度は、以下の特徴を持つ渋滞情報生成アプリケーションを検討の対象とする。
● 地図データに依存しない渋滞情報の空間コーディング¾

センタレスプローブの車載システムは、統一の仕様に限定されるものではな
く、多様な仕様の機器で構成されると想定している。

¾

このため、車両間で交通情報を共有する場合、その空間基礎情報（空間エンコーディング）として、唯一のデジタル道路地図データを用いることができないため、車載機の搭載地図有無や、地図のバージョンに依存しない空間エンコーディング規則を定める必要がある。

● 自車両で生成した渋滞情報と、他車両から受け取った渋滞情報を統合し、より「信頼性」の高い渋滞情報に加工し、拡散モードで配信する。
¾

1 台の車両で渋滞情報が生成されても、例えばその車両が特殊な動き方をした
ためにできた可能性も否定できず、そのまま広く流布するには信頼性の面で問題が残る。

¾

このため、一定数以上の車両で生成された渋滞情報が集まるまでは、品質が低いものとして、後述する情報伝達アルゴリズムの「収束モード」で、できるだけ渋滞箇所に近いエリアに限定して流布させる（図 3.2-3 参照）。
¾

一定時間内に、一定数以上の車両で生成された、即ち品質の高い渋滞情報が生成されれば、「拡散モード」で、情報を広く配信する（図 3.2-4 参照）。拡散
モードでの配信先は、渋滞情報の位置、向きに応じて、方向と範囲を決める。

渋滞区間

信頼性が高くなるまでは，この周辺で収束させる．

図 3.2-3

品質が低い渋滞情報は収束モードで伝達する信頼性が高くなった情報は，上流方向へ拡散させる．
図 3.2-4(1)

品質が高い渋滞情報は拡散モードで伝達する

渋滞情報の生成

図 3.2-5 は渋滞情報生成手順のイメージである。即ち、以下の渋滞情報の生成手順を示している。
z 1 秒毎に自車位置を確認し、あるセル（計測単位区間）から、隣接する別のセルに移った時点で、渋滞情報を生成する処理に移る。
z 直前セルを通過した際の旅行速度が、閾値を下回れば、品質 1 の渋滞情報を生成する。但し、直前セル内の走行距離が一定値よりも短ければ、情報は生成しない。
–

セルサイズは 100～300m 程度（パラメータで設定）–

旅行速度 10～20km/h 未満で渋滞情報生成

次のセルに移動した時点で，直前セルの通過所要時間と走行距離から旅行速度を求め，それが閾値以下の場合に，直前セルの渋滞情報を生成する．

渋滞区間

時の
生成
情報 向
方
進行

セル#0001

渋滞セル番号渋滞方向
渋滞生成位置
伝達方向

直前セルの番号（#0001）
現在の進行方向を（8方位）
現在の車両位置
現在の進行方向の正反対（その他，収束半径，伝達距離，見開き角度などは，指定パラメータどおり）

図 3.2-5

渋滞情報の生成タイミングと（拡散モード時の）伝達方向指定

z 生成した品質 1 の情報は、生成位置を中心として、収束モードで伝達されるように設定される。これは、なるべく伝達範囲を密にして、情報が統合される機会を増やす意味を持つ。
–

収束半径 1km 程度–

有効期間 15～30 分程度（リアルタイム性を担保するため）

z 又、品質が高くなった場合に、拡散モードで伝達する場合の伝達方向と伝達範囲も、この時点で決めておく。
–

伝達方向は、渋滞方向の 180 度反対向きとする–

伝達距離は 10km 程度–

伝達範囲見開き角度は 120 度

z 生成した渋滞情報をメッセージプールに格納する。
(2)

渋滞情報の統合

渋滞情報アプリケーションは、メッセージプールから渋滞情報を取得する際に、同一セ
ル・同一方向での渋滞情報が複数得られた場合、それらをより品質の高い一つの渋滞情報に統合する。統合処理は、以下の考え方に基づく（図 3.2-6 参照)。
z 統合された渋滞情報は、その素となっている品質 1 の渋滞情報（オリジナル渋滞情報）を保持しており、品質はオリジナル情報の数に等しい。
z 同じセル・方向、及び同じ時間帯の渋滞情報がメッセージプール内で検出された場
合、それらを 1 つの渋滞情報に統合する。
–

オリジナルである品質 1 の渋滞情報が重複しないように統合する。

z 品質が一定値（今回は 3）以上になれば拡散モードに変更する。
–

閾値は初期設定ファイルで変更可能。

自車で生成・統合
他車で生成
渋滞情報(品質2)
ID=0004, 収束モード
Org=0001, 0002

渋滞情報(品質2)
ID=0005, 収束モード
Org=0002,0003

渋滞情報(品質1) 渋滞情報(品質1)
ID=0001
ID=0002
収束モード
収束モード
図 3.2-6
3.2.3

情報の統合

渋滞情報(品質3)
ID=0006, 拡散モード
Org=0001, 0002, 0003

渋滞情報(品質1)
ID=0003
収束モード

渋滞情報の統合処理

渋滞情報生成アプリケーションの機能仕様(1)動作環境
渋滞情報アプリケーションは、センタレスプローブ評価用プラットフォームで動作する
よう、Java 環境で開発されている。開発環境は J2SE JDK 5.0 以降 1 である。
(2)動作タイミング
渋滞情報アプリケーションは、プラットフォームがアプリケーション処理を起動する間隔（1 秒）で動作する。
(3)動作設定パラメータ
渋滞情報アプリケーションは、プログラム起動時に、プローブアプリケーション共通の初期化設定ファイル（probe.ini）から、表 3.2-1 の項目の値を読み込む。
(4)

動作確認用ログ出力機能

渋滞情報アプリケーションは、複数のアプリケーションに共通するログファイル（prbveh_YYYYMMDDhhmmss.txt）に、次の 3 種類のレコードを出力している。
① 渋滞情報生成処理時のログ② 渋滞情報統合処理時のログ③ 渋滞情報破棄処理時のログ

1

Java Developers Kit の略。<http://java.sun.com>からダウンロードできる。

表 3.2-1

渋滞情報アプリケーションの動作設定パラメータ一覧1

パラメータ名TTInfoApp.scanInterval

単位
秒

意味
交通渋滞情報の統合処理を実施する間隔(秒)。交通渋滞情報の生成処理は、これに関係なく、アプリケーションの最小スキャン時間(1 秒)ごとに実施される。

2

TTInfoApp.cellResolution

セルの解像度（2 次メッシュの n 等分、
n は最大で 1000 まで）。

3

TTInfoApp.headingResolution

方位の解像度4

TTInfoApp.thresholdSpeed

km/hr

5

TTInfoApp.thresholdDistancem

渋滞判定距離の閾値 [m]6TTInfoApp.accumDistancem

情報の集積範囲半径。単位は m。

7

TTInfoApp.castAngleRangedeg

8

TTInfoApp.castDistancem

情報の伝達範囲角度。伝達方向を中心にした見開き角度で、0～360 度。
情報の伝達距離。単位は m。

9TTInfoApp.t0 ～ t3

秒

10

TTInfoApp.thresholdAppQuality

11

TTInfoApp.maxSampleNum

渋滞判定速度の閾値 [km/hr]

情報伝達のターゲット時刻パラメータt0, t1, t2, t3(秒)。とくに、t3 は渋滞情報の有効期限を与える。
拡散モードに切り替える際の品質閾値
（これ以上で切り替える。）
最大有効サンプル数（渋滞情報の統合時に有効サンプル数がこれ以上になる場合
は、古いサンプルを捨てて、この範囲に収まるようにする。）

ログの各行は、テキスト形式で、次の項目がカンマ区切りで並んだ構成になっている。
① ログ記録日時② ログ出力レベル③ 車両 ID④ アクション
⑤ 情報アイテム 1（タグ＝値、又はタグ＝（値、値、…）の形式）⑥ 情報アイテム 2

3.3

情報伝達アルゴリズムの開発

センタレスプローブ情報システムにおいて、情報を流布するための情報伝達アルゴリズ
ムの開発について述べる。

3.3.1

情報伝達アルゴリズムの概要(1)

情報伝達アルゴリズムの位置づけ

センタレスプローブ情報システムは、車載機の計算能力と車車間通信を用いることにより車載機のみでデータを分散処理して有益な情報を得るシステムである。センタレスプローブ情報システムにおいて「情報伝達アルゴリズム」は情報伝達管理の部分に実装される。
情報伝達管理部は他の部分とは独立して動作する。情報伝達管理部は、メッセージプー
ルにある情報を優先付けし、優先度の高いものから順にプローブ情報送信部を介して近隣
センタレスプローブカーに送信する。又、近隣センタレスプローブカーからの情報はプローブ情報受信部を介して情報伝達管理部に届けられ、メッセージプールに存在していない
新しい情報であれば、メッセージプールに格納される。

(2)

情報伝達アルゴリズム開発の目的

センタレスプローブ情報システムでは、車載機のみで情報を生成・提供するため、車車間における通信の役割は大きく二つに分類される。一つ目は統計処理などを施すために情報を収集する役割、二つ目は完成された情報を必要とする車両に伝達する役割である。二つの機能を下記に説明する。
(a)

情報の収集

プローブデータから有益な情報を生成するためには、統計処理などの処理が適切に行えるだけのプローブデータを収集する必要がある。このため、情報伝達アルゴリズムは、効率的に任意の目的に合致する情報を収集できなければならない。
本研究では、主に交通情報を対象とするため、同一リンクに関する別車両が生成した情報を効率よく 1 台の車両に収集し、統計処理をしやすくすることが重要となる。
(b)

情報の配布

センタレスプローブ情報システムにおいて生成された情報は、車車間通信を通じて他の車両に提供される。このため、生成された情報を欲している車両に効率的に情報が伝達される仕組みが必要となる。
本研究が主対象としている交通情報では、多くの場合渋滞地点の後方にその情報を必要としている車両が存在する。このため、渋滞地点の後方に効率的に情報を配布するためのアルゴリズムを開発する。

3.3.2

アプローチ

情報伝達アルゴリズムの要件に基づいて、本研究で実装評価する情報伝達アルゴリズムについて検討する。

(1)

地理的位置における情報伝達パターンの検討

情報伝達パターンの情報の広がり方として図 3.3-1 のパターン A～パターン D の 4 つが考えられるが、実際の環境ではアプリケーションはそのどれかのパターンのみでしか実現できないというわけではない。例えば、高速道路で後方の自動車に渋滞情報を伝えるような場合でも、必ずしもパターン C でなければならないということはなく、パターン A でも
アプリケーションを実現することができる。そもそも、高速道路は直線ではないため、パターン C で確実に高速道路をトレースして情報を配信することはできない。又、パターン
C では高速道路上の自動車のみを伝って情報を流通させなければならないのに対して、パ
ターン A を使った場合には情報の流通経路として一般道を走る車も使うため、情報伝達経路の冗長度が増し、自動車が少ないような場合には、むしろパターン A の方がより効率的に情報が伝達される可能性すらある。

Ａ

r

r

r θ
事象の
発生場所

Ｂ
図 3.3-1

Ｃr

Ｄ

情報の広がり方の分類

情報伝達範囲

データ収集時

情報配信時

図 3.3-2

情報配信モードの切り替え

以上のようなことを鑑み、今回はパターン A のみを実現することとした。パターン B は情報を伝えたい場所だけに着目すれば、パターン D と同等とみなすことができる。又、パターン C はパターン A における分布範囲の扇形の中心角が限りなく 0 に近いものとして扱うことができる。更にパターン D は、パターン A の扇形の中心角が 360 度であると捉えることが可能である。よって、パターン A のみを実現することにより、すべてのパターンに応用可能であると考える。但し、扇形を採用した場合、基点となる扇の要に当たる部分が非常に細くなり、情報伝達がうまくいかないことが想定される。このため、扇形に円を重ねたような伝達範囲を採用するものとする。
又、情報伝達パターンとして、基準点を中心に情報を集めるのか、それとも情報を拡散させるのかといった情報の流れを考える必要がある。しかし、センタレスプローブ情報シ
ステムは、情報を送信し、それを他の車両が再送信することによって成立しており、それぞれの車両が外部に対して変化させることができるパラメータは情報の送信頻度のみである。このため情報を集中させたり拡散させたりすることは難しく、今回はある範囲(情報の広がり方のパターン A で規定された範囲)での情報送信頻度のみに着目するものとした。
この場合でも、情報の内容によって情報伝達パターンの広がり方のパラメータを変化させることによって、情報が伝達される範囲を制御することが可能である。例えば渋滞情報ア
プリケーションでは、始めは統計処理が行えるだけの渋滞データを収集し、統計処理などにより有用な情報が得られた後はそれを後続車両に伝達する。このような場合、図 3.3-2に示すように、データ収集時は渋滞区間を中心に情報を頻繁に交換し、信頼に足りる渋滞
情報が完成した後は車両後方に広がった扇形の範囲で情報を流通させる。

(2)

時間軸における情報伝達パターンの検討

センタレスプローブ情報システムでは、時刻によって情報の重要度が変化する。採用したパターンを図 3.3-3 に示す。図に示されるように採用した情報配信パターンは、情報が配信され始める時刻 t0、情報の送信頻度が最大に達する時刻 t1、情報の送信頻度が減少し始める時刻 t2、情報が配信されなくなる時刻 t3 の 4 つのパラメータで表される。

t0 t1
図 3.3-3
(3)

t2

t3

t

時間軸における統合型情報伝達パターン

帯域制限の検討

実際のシステムでは、情報伝達管理部が送信キューにデータを送る際には、使用している無線通信デバイスの種類や周辺の車両の情報送信状況に応じて送信する情報の量を制御する必要がある。ここでは、帯域制限の手法について検討する。
メッセージプールから送信キューにデータを送る場合、当然のことながら無線 LAN の通信帯域より少ない送信量でなければならない。しかし、実際にはコリジョンなどにより
無線 LAN の実通信帯域を知ることは難しい。そこで今回はユーザが無線 LAN の帯域より十分に小さい通信帯域を指定することとする。
又、センタレスプローブ情報システムにおいては、近隣の車両も同様に情報を送信する。
そのため、通信帯域すべてを一つのノードで使い切ることはできない。そこで、周辺に車両がどのくらい存在するかを鑑みて、送信帯域を決定する必要がある。今回は、すべての車両が同じアルゴリズムで情報を配信していることを利用し、受信したデータの帯域に応じて送信頻度を変更するアルゴリズムを採用する。

3.3.3(1)

設計
情報伝達管理部の動作概要

図 3.3-4 に情報伝達管理部の動作概要を示す。情報伝達管理モジュールには通信帯域制
限が外部から与えられる。又、システムが起動されると情報伝達管理モジュールの初期化が行われる。初期化では、メッセージプール、送信キュー、受信キューの設定が行われる。
又、外部より、定期的に実際の動作部分が呼び出される。実際の動作部分では、初めにメッセージプールを調査し、タイムアウトしたメッセージを削除する処理を行う。その後、メッセージプール内のメッセージに対してアルゴリズムに従って優先付けが行われる。優
先付けの後、実際に送信キューにメッセージをコピーする。又、受信キューからメッセー
ジを取り出し、メッセージプールに存在していないメッセージを受信している場合には、メッセージをメッセージプールに挿入する。
情報伝達アルゴリズムは、「メッセージの優先付けアルゴリズム」として表現される。
メッセージの優先付けアルゴリズムは、実際にはモジュールとして実装される。
「メッセー
ジ優先付け」はメッセージプールを引数として、「メッセージの優先付けアルゴリズム」を呼び出す。
「メッセージ優先付けアルゴリズム」では、現在の時刻、受信キューの長さなどのシミュレーション内部で動的に変化するパラメータと、帯域制限などの設定によって静的に与えられるパラメータを使って、メッセージプール内のメッセージを優先順位の高い順に並べかえる。
• メッセージプール• 送信キュー
• 受信キュー

初期化

Start

メッセージプールからタイムアウト
したメッセージを削除する• 現在時刻• 現在時刻• 自車両の位置• 受信キューの長さ• 速度• 進行方向メッセージの優先付
けアルゴリズム• ランダム• 位置依存• 配信モード依存パラメータ• 帯域制限メッセージの優先付けメッセージプール

送信キューへメッ
セージをコピー

メッセージ

送信キュー
受信キューから
同一メッセージを削除しながらメッセージプールに
移動

メッセージ

受信キュー

End

図 3.3-4

情報伝達管理部の動作概要

(2)メッセージの構成とメッセージヘッダ

情報伝達アルゴリズムでは、空間を表現するパラメータとして扇形を定義するための数
値、時間を表現するパラメータとして 4 つの時刻が必要となる。具体的には下記のパラメータとなる。
z y (緯度)z x (経度)
z l 0 (基点を中心とした円の半径)z θ 0 (北を 0 度とした扇形の中心が向いている方向)z θ 1 (扇形の角度)
z l 1 (拡散モードの時)
z t 0 (情報が配信され始める時刻)
z t 1 (情報の送信頻度が最大に達する時刻)
z t 2 (情報の送信頻度が減少し始める時刻)
z t 3 (情報が配信されなくなる時刻)
上記のパラメータを使って記述した情報伝達範囲を図 3.3-5 に示す。(x, y)で示した位置を中真に描いた円と、(x, y)を要とした扇形を重ねたような形となる。

l0(x, y)
θ1
θ0l1

図 3.3-5(3)

情報伝達範囲のイメージ

メッセージプールにおけるメッセージの管理

メッセージプールの管理には、大きく二つの役割がある。タイムアウトしたメッセージの削除と、重複した受信メッセージの検出である。

(4)

優先付けアルゴリズムに必要なパラメータ

今回の優先付けアルゴリズムでは、いくつかの外部パラメータを用いて、メッセージの優先付けを行う。下記に今回使用したパラメータを示す。
z 自車位置z 時刻
z 受信キューの長さ

又、上記のような、外部パラメータ以外に、同じメッセージを必要以上に繰り返し送らないための、メッセージ毎に保存される情報として、下記の情報がある。
z メッセージを受信或は生成した時刻
z 最後にメッセージを送信/受信した時刻(5)

優先順位付けアルゴリズム 1: ランダム型

今回の研究では、比較対象の優先順位付けのアルゴリズムとして、メッセージプールからランダムにメッセージを取り出して送信するアルゴリズムを実装する。このアルゴリズ
ムではすべてのメッセージが同確率で選択されるため、車両の存在位置やメッセージの基点位置とは無関係にメッセージが送信され、ヘッダに設定されている位置に関連するすべてのパラメータが無視される。

(6)

優先順位付けアルゴリズム 2: 配信モード付

配信モード付き情報伝達アルゴリズムでは、メッセージの配信モードに応じてメッセー
ジの送信優先度を変化させる。基本的には、自車の位置とメッセージに設定されている基点の相対的位置関係によってメッセージ送信頻度が変化する。
すべての情報には必ず基点を設定する。各車両は自身の位置と各情報の基点との距離に応じて各情報の送信頻度を再設定する。目的地との距離が開くほど発信頻度は下がるものlとする。今回の実装では、確率 p を次の式で算出する。ここで、 0 及び l1 は到達限界距離を、 l は目的地から自車位置までの距離を、 Δt は同一のメッセージを受信又は送信してかθ

らの経過時間を、 k は経過時間による重み係数を、 0 は配布方向中心を、θ1 は配布範囲を、tθ は目的地からみた自車位置の存在方向を示す。ここで、 l0 、 l1 、 θ 0 、 θ1 はメッセージヘt

ッダに含まれているものを利用する。一方、 k は設定ファイルで値を設定するものとする。
但し、メッセージヘッダの配信モードが収束モードのときは、メッセージヘッダに含まれている l1 、

θ 0 、 θ1 を無視し、 θ1 = 0 とした動作（位置依存型と同等な動作）をするものとする。

p = 1−

l Δt⋅
l0 t kp = 1−

l Δt⋅
l1 t k

p=0

θ1

θ1

l ≤ l0 、 θ < θ 0 − 2 , θ < θ 0 + 2l ≤ l1 、θθθ0 − 1 < θ < θ0 + 1

otherwise22

確率 p のイメージを図 3.3-6 に示す。

l0(x, y)
θ1
θ0l1

図 3.3-6(7)

配信モード依存型伝達アルゴリズムの送信確率イメージ

帯域制限

前節で述べたとおり、今回は受信したデータの帯域に応じて送信頻度を変更するアルゴ
リズムを採用する。そこで、各車両から送信するデータの帯域を次式のように定めた。

B=

Bmax − Brecv
2

上式において、B はこの車両が送信可能な帯域、Bmax はユーザが設定した利用可能な通信帯域の上限、Brecv は受信キューより算出した近隣車両が送信したデータの帯域である。式の右辺の分母は、車両近隣における無線 LAN の余剰帯域となり、その半分が送信可能帯域として使われることとなる。

シミュレーションによる評価

3.4
3.4.1
(1)

評価用シミュレーションプラットフォームの概要
プラットフォーム開発の目的

センタレスプローブ情報システムの情報処理性能を評価するには、どのような品質・精度の交通情報が生成され、それがどのくらいの範囲に伝達されうるか、その程度を定量的に把握することが求められる。本年度においては、仮想世界でセンタレスプローブ情報シ
ステムの性能評価を実施できるシミュレーションプラットフォームを開発することを目的とした。プラットフォームを用いることで、次の視点での評価が、ある程度のシステム規模、即ちセンタレスプローブ車両数で実施することができる。
z

現実的な交通状況での、センタレスプローブ情報アプリケーションの交通情報
生成、及び統合情報生成の動作を確認する。

z

センタレスプローブ車両の混入率と情報伝達性能の関係を評価する。

z

情報伝達アルゴリズムに関連する伝達パラメータの情報伝達性能への影響を評
価する。

z
(2)

車車間通信性能の情報伝達性能への影響を評価する。

シミュレータ構成

図 3.4-1 に評価用シミュレーションプラットフォームの構成を示す。プラットフォーム
は、大きく分けて三つのシミュレータで構成される。
① 交通流シミュレータ（TS）② 通信シミュレータ（CS）③ 車両シミュレータ（VS）
交通流シミュレータは、道路ネットワーク上の車両を逐次計算で移動させ、交通状況を再現するとともに、評価用仮想世界の時間を管理し、通信シミュレータと車両シミュレー
タを同じ時間軸上で動作させる役割を持つ。
通信シミュレータは、交通流シミュレータが管理している道路上の車両の内、センタレ
スプローブ車両だけを取り出し、近接する車両間での車車間通信機能をエミュレートする。
車車間通信の性能に関するパラメータは、通信シミュレータで設定する。
車両シミュレータは、センタレスプローブ情報システムの車載機能をエミュレートする
もので、車両一台毎に、センタレスプローブ情報処理アルゴリズムを実装したアプリケー
ションと、情報伝達アルゴリズムを実装した情報伝達管理モジュールを実行する機能を持つ。
特に車両シミュレータは、車両情報の取得機能やメッセージ送受信機能などを、実機の動作環境と合わせて API を設計しており、シミュレーションプラットフォーム上で動作す
るセンタレスプローブ情報アプリケーションと情報伝達管理モジュールが、そのまま実機でも動作できるよう、互換性を持たせていることが特徴である。

交通流シミュレータ（TS）

通信シミュレータ（CS）

道路ネットワーク上の交通状況を再現する．

近接車両間での車車間通信機能を模擬する．

プローブ車両の位置

車両シミュレータ（VS）

センタレスプローブ
車両を模擬する．

位置，速度，
進行方向，etc.

センサー

車載機

センタレスプローブ処理アルゴリズム

供給

消費

参照

情報伝達アルゴリズム
プローブ情報プローブ情報

位置情報

送信ﾎﾟｰﾄ

受信ﾎﾟｰﾄ車々間通信

図 3.4-1(3)

評価用シミュレーションプラットフォームの基本構成

車両シミュレータの機能モジュール構成

図 3.4-2 は、車両シミュレータを構成する機能モジュールを中心とした機能関係図である。

車両シミュレータ
車載機内部
情報伝達モジュール（共通）

車両情報モジュール（シミュレーション）

受信
キュー
（共通）

プローブアプリケーション
（共通）

送信
キュー
（共通）

センタレスプローブ
車両（シミュレーション）

交通流シミュレータ
（シミュレーション）

図 3.4-2

メッセージプール（共通）

通信モジュール
（実機）

無線LAN
（実機）

車両情報モジュール
（実機）

センサー
（実機）

通信シミュレータ（シミュレーション）

プラットフォームを構成する機能モジュール関連図

3.4.2

評価用シミュレーションプラットフォームの機能仕様

評価用シミュレーションプラットフォームを、次の要求事項を考慮して設計した。
① 現実的な交通状況下でのセンタレスプローブ車両の走行を交通流シミュレータ で再現できること。
② 現実的な車車間通信環境を通信シミュレータで再現できること。
③ 評価するセンタレスプローブ情報アプリケーションや、情報伝達管理モジュー ルが、実機でも動作するよう互換性のある API（Application Program Interface）を備えること。
交通流シミュレータには、様々な適用実績がある市販のソフトウェア 1 を流用しており、適切なパラメータ（道路容量など）が設定されれば、現実的な精度で実際の交通状況を模擬することができる。表 3.4-1 は、通常の交通流シミュレータの仕様の他に、今回追加で必要となる機能仕様を記したものである。
表 3.4-2 に通信シミュレータの機能仕様を示す。通信シミュレータの計算処理は、交通流シミュレータから呼び出され、その瞬間での車車間通信を模擬する。
表 3.4-3 に車両シミュレータの機能仕様を示す。車両シミュレータの計算処理は、交通流シミュレータから呼び出され、その都度アプリケーションの計算処理と、情報伝達管理
モジュールの計算処理を実行する。
表 3.4-1
計算間隔（スキャン時間）

センタレスプローブ車両の指定
センタレスプローブ車両の混入率
センタレスプローブ車両の取得

1 秒単位で車両移動の計算を行う。
（但し、通信シミュレータの時間解像度に合わせるため、0.1 秒毎の車両位置を補間して求めている。）
一般車と車種を変えて設定する。
車種毎に OD 交通量を指定するので、センタレスプローブ車両の割合が指定した混入率になるように、発生台数を一般車とで案分してデータを作成する。
通信シミュレータから、道路上を走行中のセンタレスプロー
ブ車両を随時取得できるよう、常にリストで管理し、そのリストへのアクセス API を用意する。

表 3.4-2
計算間隔（スキャン時間）
車車間通信性能

1

交通流シミュレータの機能仕様

通信シミュレータの機能仕様

0.1 秒、0.2 秒、0.5 秒、1 秒単位。（初期設定ファイルで変更
可能）
車両間の距離に応じたパケット到達率を関数形式で指定する。又、通信可能な範囲にいるセンタレスプローブ車両の台数に応じて、利用できる帯域が変わる機能を備える。

広域都市道路網交通流シミュレーションモデル SOUND/4U（製品情報<http://www.i-transportlab.jp/products/sound>）表 3.4-3

車両シミュレータの機能仕様

計算間隔

1 秒毎とする。

メッセージプールのサイズ

10MB とする（初期設定ファイルで変更可能）。

送受信キューのサイズ

1MB とする（初期設定ファイルで変更可能）。

実行するプローブ情報アプ
リケーション

初期設定ファイルに起動するアプリケーションを指定する（複数指定可能）。

3.4.3

クラスコンポーネントの設計と実装

プラットフォームは、Java 言語を用いて、オブジェクト指向プログラミングで実装されている。図 3.4-3 は、シミュレーションプラットフォーム関連クラスの関係図である。
LegendInterface
CSSamleAbstractCommunication
Simulator

MessageCasterCommunicationSimulator

AbstractMessage
Caster

Abstract class

SampleMessageCaster

Concrete classimplements
inherits

TrafficSimulator

sound.Sounddelegates

ProbeApplication

relatessound.
VehiclePacket

ProbeVehicle

AbstractApplication

ProbeType

MessagePool

VehicleDataEquipment

SendQueue

BasicMessagePool

ReceiveQueue

ProbeMessage

図 3.4-3
3.4.4

TTInfoApplication

AbstractProbe
Message

TTInfoMessage

評価用シミュレーションプラットフォーム関連クラス関係図

評価用シミュレーションシナリオ

本年度のシミュレーションでは、都市部面的ネットワーク（東京都西部地区ネットワー
ク）を用いたシナリオを用意した。このシナリオは、混雑した都市部の現実的な交通状況
下で、どのくらいの品質の渋滞情報が生成され、どのくらいの範囲にその渋滞情報が伝達されるかを、総合的に評価するためのものである。
東西約 10km×南北約 20km の範囲にわたる東京都西部地区の道路ネットワークを用意した。道路は、このエリア内の幅 5.3m 以上のものがすべて含まれている。又、約 350 箇所の主要な交差点に、信号制御データを設定した。
シミュレーションに入力する OD 交通量は、平成 11 年度道路交通センサスでの自動車起終点調査結果を基に、このエリアに関係する部分を抽出し、時間帯別の交通量に変換したものを用いている。シミュレーション対象時間は、朝 6 時～9 時の 3 時間とし、この間に次のような交通需要を発生させている。
z 3 時間の総車両発生台数

274,362 台z プローブ混入率

5%

z 瞬間の走行プローブ台数

約 1000 台

z 距離 100m 未満の近接ペア数

約 700 ペア

3.4.5

センタレスプローブ処理アルゴリズムのシミュレーションによる評価

ここでは、総合評価に用いた東京都西部地区ネットワークでのシナリオ評価の結果を用いて、渋滞情報生成アプリケーションの動作検証を行った結果について述べる。

(1)

渋滞情報生成アプリケーションの動作検証(a)

渋滞情報の生成概況

図 3.4-4 は、東京都西部地区ネットワークのシナリオにおいて、センタレスプローブ車両が生成した渋滞情報メッセージの数を、速度域毎に頻度分布にして示したもので、3 時間のシミュレーションで、合計約 35,000 個のメッセージが生成されたことを確認した。このときの渋滞情報生成アプリケーションでは、セルサイズを 100m×100m に、速度閾値を10km/h 未満に設定している。表 3.4-4 に設定パラメータ一覧を示す。
生成された渋滞情報の速度分布
6000
5000

頻度

4000
3000
2000
1000
0
0.0

1.0

2.0

3.0

4.0

5.0

6.0

7.0

8.0

9.0

10.0 10以上

渋滞情報の速度 [km/h]

図 3.4-4

東京都西部地区ネットワークでの渋滞情報メッセージ生成数（閾値 10km/h）

表 3.4-4

渋滞情報生成アプリケーションのパラメータ設定

パラメータ

設定値

備考

セルサイズ

約 100m 四方

2 次メッシュの 100×
100 等分

渋滞判定閾値

10km/h 未満

渋滞情報生成最小距離

50m 以上走行

拡散モード切替判定

品質 3 以上

渋滞情報の有効期限

15 分

次に、これらの渋滞情報が、実際に渋滞が発生している箇所で生成されているかどうかを確認した。図 3.4-5 は交通流シミュレーションの出力結果として得られる、リンクの平均旅行速度をネットワーク上で色分けして示したものである。赤く示される区間ほど、速度が低く、渋滞状況にあることを示している。
これに対して、図 3.4-6 は、センタレスプローブ車両で生成された渋滞情報メッセージの発生地点に対応するリンク毎に、メッセージ数の多寡を線の太さで示したものである。
明らかに図 3.4-5 で渋滞している区間で、多くの渋滞メッセージが生成されており、渋滞
情報生成アプリケーションが、意図した動作で適切に渋滞を検出していることが分かる。

青梅街道

環八

国道20号

6時～9時のリンク平
均旅行速度(km/h)
60 - 80
40 - 60
30 - 40
20 - 30
10 - 20
0 - 10

図 3.4-5

国道246号

東京都西部地区ネットワークでの渋滞発生状況（リンク速度で色分け）

リンク上の渋滞情報生成数
200 - 1,000 (11)100 - 200 (42)50 - 100 (135)
10 - 50 (656)
1 - 10 (761)

図 3.4-6(b)

センタレスプローブ車両が生成した渋滞情報数の地点分布

地点別の渋滞情報生成状況の確認

図 3.4-7 は、特に渋滞が顕著な「環八内回り・上高井戸交差点」付近と「国道 20 号下り・調布駅前」付近を取り上げ、時間帯別の渋滞情報生成状況を確認したものである。いずれの地点でも、速度が低下する 6:30～6:45 で生成される渋滞情報数が増加しており、アプリ
ケーションが時間変化する渋滞を検出していることが分かる。

環八内回り・上高井戸１

50
45
40
35
30
25
20
15
10
5
0

40
30
20
10
0
6:00 6:15 6:30

6:45 7:00 7:15

7:30 7:45 8:00

533944_01456_533944_01438

環八内回り・上高井戸１50

平均速度 [km/hr]

生成情報数［個/15分］

リンク上での渋滞情報生成状況

8:15 8:30 8:45

リンク速度

リンク上での渋滞情報生成状況

国道20号下り・調布駅前

50

20

40

15

30

10

20

5

10

0

0
6:00 6:15 6:30 6:45

7:00 7:15 7:30 7:45

-533934_00336_533934_00824

図 3.4-7

8:00 8:15 8:30 8:45
リンク速度

地点別・時間帯別に見た渋滞情報の生成状況

平均速度 [km/hr]

国道20号下り・調布駅前

生成情報数［個/15分］

25

(c)

渋滞情報生成の閾値と生成される渋滞情報数との関係

図 3.4-8 は、アプリケーションでの渋滞判定の閾値を、ひとまず 40km/h と高い水準に設定して、生成された渋滞情報の速度域別の個数を集計したものである。横軸では、交通流シミュレーション結果から分かる、リンクの平均旅行速度を 5km/h 毎に区分している。図3.4-9 は、これを各区分での構成比率にしたものである。閾値を 10km/h とした場合は、「渋
滞情報 0～4km/h（赤）」と「4～10km/h（ピンク）」をあわせた数の渋滞情報が生成されることになるが、その数を見るとリンク平均旅行速度が一般道での「渋滞」あるいは「混雑」と 見 なさ れ る 10～15km 以 下 で 急 に 割 合が 増 加 し てい る こ と が分 か る 。 従っ て 、 閾 値 を10km/h に設定することで、適切に一般道で渋滞を検出できるといえる。

速度帯別渋滞情報生成数
60000

渋滞情報生成の判定値（10km/h）

生成された渋滞情報数

50000
40000

渋滞が激しいと，交通量が小さくなり，プローブの通過台数も少なくなる．

30000
20000
10000

渋滞情報0-4km/h
渋滞情報15-20km/h

図 3.4-8

渋滞情報4-10km/h
渋滞情報20-25km/h

リンク速度40-km/h

リンク速度35-40km/h

リンク速度30-35km/h

リンク速度25-30km/h

リンク速度20-25km/h

リンク速度15-20km/h

リンク速度10-15km/h

リンク速度5-10km/h

リンク速度
0-5km/h0

渋滞情報10-15km/h
渋滞情報30-40km/h

リンク速度域別の渋滞情報個数（品質 1 のみ）

速度帯別渋滞情報生成比率

閾値の10km/hを下回ると，低速の渋滞情報の比率が増える．

80%

60%

40%

20%

渋滞情報0-4km/h
渋滞情報15-20km/h

図 3.4-9

渋滞情報4-10km/h
渋滞情報20-25km/h

リンク速度40-km/h

リンク速度35-40km/h

リンク速度30-35km/h

リンク速度25-30km/h

リンク速度20-25km/h

リンク速度15-20km/h

リンク速度10-15km/h

リンク速度5-10km/h0%
リンク速度
0-5km/h生成された渋滞情報の速度帯別の比率

100%

渋滞情報生成の判定値（10km/h）

渋滞情報10-15km/h
渋滞情報30-40km/h

リンク速度域別の渋滞情報構成比率（品質 1 のみ）

渋滞情報統合処理の検証(d)

図 3.4-10 は、最初に品質 1 で生成された、あるセルの渋滞情報が、時間が経過するにつれて他の車両で生成された渋滞情報と統合され、より品質の高い情報になったことを示している。即ち、品質が 3 になって、拡散モードになった統合情報の数を、それが示しているセル毎に集計して、情報の多寡で色分けした図である。赤で示されるセルほど、統合処理によって生成された渋滞情報数が多いことを意味し、図中に地点名を記した実際のボト
ルネック渋滞発生地点の付近で、統合処理された品質の高い渋滞情報ができていることが
分かる。

谷原交差点

北原交差点

環八五日市交差点
東八道路

調布駅前付近渋滞情報生成数（ランダム・品質３）
1,000 - 4,000
500 - 1,000
300 - 500
200 - 300
100 - 200
0 - 100

図 3.4-10

瀬田交差点

東京都西部地区ネットワークで一定品質の渋滞情報が生成された箇所を情報数で色分け（全体)3.4.6

情報伝達アルゴリズムのシミュレーションによる評価

シミュレーションによる情報伝達アルゴリズムの評価について述べる。情報伝達アルゴ
リズムの目的は、情報の収集と情報の配布の二つがある。本節ではこれらの二つの目的にそって、評価を行う。

(1)

情報の収集に関する評価

まず、情報の収集について評価を行う。シミュレーションは、東京西地区のシミュレー
ション設定を用いて行った。又、シミュレーションでは、ランダム配信アルゴリズムとモード付き配信アルゴリズムの二つを用い、両者を比較することによって、今回開発したモード付き配信アルゴリズムの優位性を評価した。
図 3.4-11 に調布駅周辺の渋滞に関する品質 3 の情報が生成された場所のプロットを示す。
図において、中心の赤い矢印が渋滞したセルの場所と方向を示している。又、青い点がランダム配信アルゴリズムを用いた場合、赤い点がモード付き配信アルゴリズムを用いた場
合の品質 3 の情報が生成された場所である。図から、ランダム配信アルゴリズムを用いた
場合には、主に渋滞情報が国道 20 号線において生成されているのに対し、モード付き配信
アルゴリズムでは、渋滞セルの近傍で渋滞情報が生成されていることが分かる。
又、この二つのアルゴリズムで生成された品質 3 以上の渋滞情報は、ランダム配信アルゴリズムを用いた場合で 813 種、モード付き配信アルゴリズムを用いた場合で 26 種であった。一方で、異なる渋滞データを元としている品質 3 以上の渋滞情報は双方ともに実際には 6 種類しかない。このことから、ランダム配信アルゴリズムを用いた場合には、メッセージが多くの場所で交換されるため、既に生成されたことのある情報が別の車両で生成されるという現象が起こっていると考えられる。このことは、同じ情報がばらばらの場所で何度も生成されるという意味で、非効率的な情報生成であるということができる。

国道
20号
線（
甲
旧甲
州街
州街
道）
道
品
川
通り

川
鶴

図 3.4-11

道街●： ランダム●： モード付←： 渋滞方向

調布駅周辺の渋滞に関する品質 3 の情報が生成された場所

東八道路におけるランダム配信アルゴリズムとモード付き配信アルゴリズムを用いた場
合の渋滞データの広がり方を、それぞれ図 3.4-12 と図 3.4-13 に示す。レーダーチャートの各軸は、セルにおける渋滞方向を示している。二つの図を比較すると、モード付き配信ア
ルゴリズムを用いた場合に比べて、ランダム配信アルゴリズムを用いた場合には、広がりが大きいことが読み取れる。これは、調布駅周辺の例と同様に、ランダム配信アルゴリズ
ムに比べて、モード付き配信アルゴリズムを使った場合は、渋滞データの広がりを抑えることが可能であることを示している。

Tokyo_D_5339441347_6(n<3)
0
10000
7

8000

1

6000
4000
2000
6

0

2

5

3分未満
3～6分
6～9分
9～12分
12～15分

34

図 3.4-12

東八道路周辺におけるモード付き配信アルゴリズムを用いた場合の渋滞データの広がり方

Tokyo_R_5339441347_6(n<3)
0
10000
7

8000

1

6000
4000
2000
0

6

2

5

3分未満
3～6分
6～9分
9～12分
12～15分

34

図 3.4-13

東八道路周辺におけるランダム配信アルゴリズムを用いた場合の渋滞データの広がり方

又、渋滞データが生成されてから、品質 3 の渋滞情報が生成されるまでの時間を測定した。調布駅前の渋滞箇所では、ランダム配信アルゴリズムを用いた場合の品質 3 の渋滞が生成されるまでの時間は平均 7 分 3 秒だったのに対して、モード付き配信アルゴリズムを用いた場合には 1 分 12 秒であった。又、東八道路の場合はそれぞれ、5 分 42 秒と 44 秒であった。このことから、モード付き配信アルゴリズムを用いた場合には、ランダム配信ア
ルゴリズムを用いた場合に比べて、明らかに短い時間で渋滞情報を生成することができていることが分かる。
以上のことより、下記の結論が導き出される。
z モード付き配信アルゴリズムでは、渋滞箇所の近辺で渋滞情報が生成されており、渋滞データが生成されてから統合処理されて渋滞情報が生成されるまでの時間が短い。

z モード付き配信アルゴリズムでは、早期に渋滞情報が完成するため、狭い範囲で効率的に情報を生成でき、無駄な統合処理を抑制することができた。

(2)

情報の配布に関する評価

次に情報の配布性能の評価について述べる。
図 3.4-14 と図 3.4-15 それぞれモード付き配信アルゴリズム、ランダム配信アルゴリズムを使ったときの、品質 3 以上の渋滞情報が受信された場所のプロットを示す。図において中心の矢印が渋滞方向を、赤い扇形が確実に配信したいエリアを示す。

図 3.4-14

調布駅周辺の品質 3 以上の渋滞情報が受信された場所(モード付き)

図 3.4-15

調布駅周辺の品質 3 以上の渋滞情報が受信された場所(ランダム)二つの図を見る限り、有意な差は見られない。これらの結果より、二つのことが言える。
一つは、情報伝達の範囲に有意な差がないこと、もう一つは車両の走行速度と情報伝達速
度がほぼ等しいことである。それぞれの結果について考察を加える。
●

情報伝達の範囲に有意な差がない
今回のシミュレーションでは、無線 LAN の通信帯域を 1Mbps に設定した。この条件下

では、1 秒間に 125kByte のメッセージを送信することが可能である。又、一方で、今回開発したプローブ情報アプリケーションを使った場合、1 メッセージあたりメッセージの大
きさは約 900Byte であった。よって、1 秒間に約 140 個のメッセージを送出可能であることが分かる。
一方で、今回のシミュレーションでは、メッセージプール内に、ランダム配信アルゴリ
ズムで約 500 個、モード付き配信アルゴリズムで約 400 個のメッセージが格納されていた。
今回開発したモード付き配信アルゴリズムでは、一度送信したメッセージを何度も続けて送信しないように、一度送信したメッセージの優先順位を下げる仕組みが組み込まれている。このため、約 3 秒間でメッセージプールに存在するメッセージを全て送出する計算となる。
実際には、輻輳制御の仕組みが働くため、上記のように 3 秒ですべてのメッセージを送信することはないと考えられるが、いずれにしろ短い時間で全てのメッセージを送信している可能性が高く、このことが原因で優位な差がみられなかったと考えられる。
しかし、メッセージを配信したい方向にメッセージは十分伝わっており、より多くのメッセージがメッセージプールに入るような場合には、本アルゴリズムが有効に働くものと考えられる。
●

車両の走行速度と情報伝達速度がほぼ等しい
今回のシミュレーションでは、プローブ車両の混入率を 5%とした。このため、期待値

として、20 台に 1 台がプローブ車両となる。一般的な車両の長さは約 5m、渋滞時の車間を 2m とすると、渋滞時に 20 台の自動車が並ぶと、140m となる。今回の、無線 LAN の通信モデルでは車間 140m のときのパケット到達率は、1-(140/145) 2 となり、パケットの到達率は約 7%となる。実際には、対向車線を走る自動車の存在や、2 車線道路などがあるため、パケットの到達率はもう少し高いと考えられるが、今回のパラメータ設定では、パケットが到達する可能性は低いことが分かる。このため、混入率 5%程度では、車両の走行速度を越えてパケットを伝達することは非常に難しいことが分かる。
今後、ヒアリングなどにより必要とされる情報伝達速度の検討を行い、上記の結果が渋滞アプリケーションの情報伝達に十分であるかどうかを検証する必要がある。また、プローブ車両の混入率を変化させたときの配信パターンの調査、マルチアプリケーション化あるいはメッセージ数を増やした状態での配信パターンの評価を行うことにより、配信アル
ゴリズムの パラメータ 依存性を確 認すること ができると 考えられる 。更に、セ ンタレスセンタ間連携、あるいは路側機協調を導入することにより、情報伝達速度の向上などが見込めると考えられる。

車載機の開発

3.5
3.5.1

車載機の概要センタレスプローブ情報車載システムの構成を図 3.5-1 に示す。

ｾﾝﾀﾚｽﾌﾟﾛｰﾌﾞ処理ｱﾙｺﾞﾘｽﾞﾑ
情報伝達ｱﾙｺﾞﾘｽﾞﾑ
JAVA VM
車載機（本年度はノートPC）
イーサ
GPSユニットシリアル

図 3.5-1

車車間通信機（無線LAN）

センタレスプローブ情報車載システムの構成

車載機には、センタレスプローブ処理アルゴリズム、及び情報伝達アルゴリズムを実現するソフトウェアと、車車間通信機、GPS ユニットを接続ためのインターフェースを実装する。これらのソフトウェアを実装する車載機は、ノートパソコンを活用した。
GPS ユニットとはシリアルケーブルで車載機と接続した。
車車間通信機は、802.11b ad-hoc mode の無線 LAN 方式とした。車車間通信機は、イーサケーブルで車載機（ノートパソコン）と接続した。
車載機が保有するは以下の機能である。
z センタレスプローブ情報処理機能¾ 自車両情報収集機能¾ センタレスプローブ情報アプリケーション機能（渋滞情報作成）
z 情報伝達管理機能
z 車車間通信機能¾ プローブ情報受信機能¾ プローブ情報送信機能
3.5.2

車載機ソフトウェアの設計

車両情報収集機能、プローブ情報受信機能、プローブ情報送信機能の開発について述べ
る。

(1)

機能概要

(a)

車両情報収集機能

自車両センサ情報である緯度・経度、方位、速度データの取得及び、センタレスプロー
ブ情報アプリケーションや情報伝達管理機能への車両情報提供インタフェースを提供する。

(b)プローブ情報受信機能

車車間通信装置により他のセンタレスプローブカーからセンタレスプローブ情報アプリ
ケーションのメッセージを受信し、受信キューに挿入する。なお、連送により既に受信済
みのメッセージは破棄する。

(c)

プローブ情報送信機能

送信キューからセンタレスプローブ情報アプリケーションのメッセージを取り出し、車車間通信装置で他のセンタレスプローブカーへ送信する。このとき、データ送信の信頼性向上のため、同一データを複数回送出可能とする。この機能を連送(連続送信)という。

(2)

処理内容

(a)

ソフトウェア構成

車載機ソフトウェアの構成を図 3.5-2 に示す。

センタレスプローブ情報
アプリケーション

情報伝達管理モジュール

受信キュー

送信キュー

メッセージプール
車両情報収集

プローブ情報受信

プローブ情報送信

THREADTHREADTHREAD

GPS ユニット

無線 LAN

図 3.5-2(b)①

ソフトウェア構成

車両情報収集処理
処理概要
z GPS ユニットの緯度・経度、方位、速度データを解析する。
z 車両情報収集インタフェースを提供する。

②

基本動作
z 通信制御パラメータを設定する。
z GPS ユニットから収集したデータを解析する。
z 収集した速度データが異常な場合は、処理対象としなく破棄する。

z 情報伝達管理モジュール、センタレスプローブ情報アプリケーションの要求に従い、車両情報を提供する。

(c)①

プローブ情報受信処理
処理概要
z 車車間通信機が他車両から受信したメッセージを、受信キューへ挿入する。

②

基本動作
z 一つのパケットに結合されて届いたメッセージを分割する。
z 複数のバケットに分割されて届いたメッセージを再構成する。
z 重複して受信したメッセージを破棄する。

(d)①

プローブ情報送信処理
処理概要
z 送信キューからメッセージを取り出し、他のセンタレスプローブカーへ送信するために、車車間通信機に引き渡す。

②

基本動作
z サイズが小さい複数のメッセージは一つのパケット結合し、送信する。
z サイズが大きいメッセージは分割し、送信する。
z メッセージの送信漏れを防止するため、1 件のメッセージを繰り返して車車間通信機に引き渡す。

3.5.3
(1)

車載機ソフトウェアの実装
処理フロー

車載機ソフトウェアの処理フローを図 3.5-3 に示す。
①

初期パラメータ設定（A1）
設定データ情報（ClsProbe.properties、probe.ini）から各初期値を読み込む。又、ログ出力の各パラメータを設定する。エラーが発生した場合はエラーメッセージをデフォル
ト場所で出力し、処理を終了する。
②

車載機状態更新タスク起動（A2）
車載機状態更新タスクを起動して、定期的に車載機から車両走行情報を読み取る。

車載機データの入力元は以下の 3 種類の入力モードで定義する。

③•

GPS：車載機実機のデータ•

FILE：車載機出力フォーマットで作成されたテキストファイル•

RANDOM：ランダムで作成された車両走行情報

車載機初期化設定（A3）
車載機時刻の取得元、車載機状態の出力ログの各パラメータを設定する。車載機時刻の取得元については、以下の 2 種類で定義する。
•

TIME_FROM_SYSTEM：システム時刻•④

TIME_FROM_GPSDATA：車載機から取得した時刻

車両情報取得判定（A4）
車両情報の取得ができているかをチェックする。

z YES の場合、A5 以後の処理を行う。
z NO の場合、2000[msec]ごとに車両情報が取得できるかを繰り返しチェックする。
⑤

プローブメッセージ送受信キュー初期化（A5）
送信キューの最大サイズ、送信最大可能件数を設定する。

⑥

メッセージプール初期化（A6）
メッセージプールの最大サイズを設定する。

⑦

プローブアプリケーションタスク起動（A7）車両走行情報からメッセージを作成し、メッセージプールに保存する。

⑧

プローブ情報伝達タスク起動（A8）z

メッセージプール内のメッセージをアルゴリズムで整理して、送信キューにコピーする。

z

受信キューからメッセージを取り出し、メッセージプールに存在しないメッセー
ジを挿入する。

z

情報伝達モードを取得して、対応する情報伝達モジュールを利用する。
なお、情報伝達には以下の 3 種類のモードがある。

⑨•

RANDOM：ランダム型情報伝達管理モジュール•

DELIVERY_MODE_DEPEND：配信モード依存型情報伝達管理モジュール•

POSITION_DEPEND：位置依存型情報伝達管理モジュール

送信タスク起動（A9）
定期的に送信キューからメッセージを取得して、送信する。

⑩

受信タスクを起動（A10）
定期的に他車からのメッセージを受信して、受信キューに保存する。

⑪

システムの運行状態を定期的に出力（A11）z

出力の時間間隔は ClsProbe.properties の SYSTEM_STATE_REFRESH_INTERVAL で指定z

出力内容は車両走行情報、メッセージプール、送受信キューのメッセージサイズ、
件数、送受信のメッセージ、パケットの件数⑫ 終了（A12）
Ctrl + C が押されたら、処理を中止する。

START

初期化パラメーター設定：A1
パラメータ
入 力 モード
関連情報

車載機状態更新タスク起動：A2

車載機初期化設定：A3

車両情報取得判
定：A4

NO

YES
プローブメッセージ送受信キュー初期
化：A5
メッセージプール初期化：A6

プローブアプリケーションタスク起動：A7
パラメータ
・伝 達 モード

メッセージプール
プローブ情報伝達タスクを起動：A8

送信タスク起動：A9
送信キュー

受信キュー
受信タスク起動：A10

システム運行状態出力：A11

終了入力（Ctrl + C）：A12

END

図 3.5-3

処理フロー図(2)動作環境

車載機ソフトウェアを実装する車載機であるノートパソコンの動作環境を以下に示す。

3.5.4

z OS

：WindowsXPSP２z CPU：CoreSole T1300 1.66GHz（機種：レノボ Think Pad X60）

z メモリ

：512MB

z HDD

：40GB

z ソフトウェア：Java SE 5.0／javacomm20-win32（Java Communications API）

車載機の評価試験

フィールド試験(2006 年 12 月 11 日から 13 日に、JARI 城里テストセンタ（茨城県東茨城郡城里町）で実施)の前に、以下の試験をフィールド試験に近い環境で確認するため、実車を利用した評価試験を実施した。
z 車載機ソフトウェアの単体試験、結合試験
z 車載機、車車間通信機、GPS ユニットなどで構成するセンタレスプローブ情報車
載システムの動作試験(1)

評価試験内容以下の項目について、評価試験を実施した。表 3.5-1 に試験内容を示す。
表 3.5-1

評価試験項目と内容

No

評価試験項目

試験内容

1

車車間通信機接続試験

2

GPS ユニット接続
試験

試験用 GPS 履歴データをシステムに入力してプローブ情報を生成し、これら情報が車車間通信機で送受信されることを確認する。
GPS ユニットから GPS データが入力されることを確認する。

3

4

センタレスプロー
ブ情報アプリケー
ション動作試験
メッセージ送受信試験(2)

評価試験結果(a)

車車間通信機接続試験

走行車両の GPS 実データを利用してセンタレ
スプローブ情報アプリケーションがメッセージを作成することを確認する。
走行車両の GPS 実データに基づき作成したメッセージが車載機間で送受信（無線通信）されることを確認する。

車載機（ノートパソコン）に接続している車車間通信機の動作確認を行い、GPS 履歴データから生成されたメッセージが送受信されていることをそれぞれの車載機（ノートパソコン）のログで確認した。

(b)GPS ユニット接続試験

車載機（ノートパソコン）に接続している GPS ユニットの動作確認を行い、車載機（ノートパソコン）に GPS データ入力されていることをログで確認した。
(c)

センタレスプローブ情報アプリケーション動作試験

上記 2 項目確認後、車両を走行させ、2 台の車載機それぞれが GPS 実データからメッセージを生成していることをログで確認した。

(d)

メッセージ送受信試験 4

GPS 実データから生成されたメッセージが車車間通信機により送受信されることをログで確認した。以下は車載機 1 の情報伝達アルゴリズムのログである。14:22:09 以降、車載機 2 で生成された情報（ID=8589934592）を受信していることを確認した。
2006-11-30T14:22:07, 35.38608333333333, 139.43078333333332, 1, 0, 4294967296
2006-11-30T14:22:08, 35.38605, 139.43088333333333, 1, 0, 4294967296
2006-11-30T14:22:09, 35.385999999999996, 139.43098333333333, 1, 1, 4294967296,
8589934592
2006-11-30T14:22:10, 35.38596666666667, 139.43106666666665, 2, 2, 4294967296,
8589934592
2006-11-30T14:22:11, 35.38591666666667, 139.43116666666668, 2, 0, 4294967296,
8589934592

3.6

車載機によるフィールド実験評価

3.6.1
(1)

フィールド実験の概要
フィールド実験の目的

フィールド実験の目的は、開発したアルゴリズムを車載機にインストールし、車載機を搭載した車でフィールドを走行し、アルゴリズムを評価することである。評価した項目は、次のとおり。
z 渋滞情報を生成・統合するセンタレスプローブ情報処理アルゴリズムの評価
z 情報を意図とおりに収束、拡散させるための、情報伝達アルゴリズムの評価
z その他、車車間通信（無線 LAN）によるデータ交換に係る評価(2)

フィールド実験システム

車載機のノートパソコンに JAVA VM の搭載して、情報伝達アルゴリズム、センタレス
プローブ処理アルゴリズムをインストールした。メッセージプール内のデータが少ないと、送信するメッセージの優先付けができないため、情報伝達アルゴリズムの動作確認が行えない。そのため、ダミーデータを生成するアプリケーションを追加した。

車載機（PC）
アンテナ（GPS、通信）

インバータ、通信機、車両センサ（車両から、車速パルスを取得）

図 3.6-1

フィールド実験で使用したシステムの搭載状況

フィールド実験で使用したシステムの搭載状況を図 3.6-1 に示す。センサ情報は、GPSによる緯度・経度のほか、車速パルスを車両から取得し車速演算を行い、ジャイロにより進行方位を演算している。
走行後の車載機から取得した下記ログを分析し、評価を行った。例えば、データの送受信を行った位置を GIS ツールによって分析するなどである。
[収集したログデータ]
z 時刻、車両位置、車速、進行方向

z メッセージプールに供給、消費、参照されたデータ
z メッセージプール内に蓄積されているデータ(3)

フィールド実験を行ったロケーション

フィールド実験は、一般の交通に支障を与えず安定的に繰り返し実験走行が行え、交通安全上の配慮、無線電波の飛来による妨害がないことを勘案し、ロケーションを選定した。
その結果、JARI 城里テストセンタ（茨城県東茨城郡城里町）外周路にて、フィールド実験を実施することにした。
JARI 城里テストセンタの外周路は、周長 5,722m、幅 7m（片側１車線の上下線）のアス
ファルト舗装路であり、アップダウン（勾配：最大 5.9%）やカーブ（最小半径：60m）もあり、一般道路を模擬した評価仕様となっている。
(4)

評価内容

(a)

センタレスプローブ情報処理アルゴリズムの評価

センタレスプローブ情報処理アルゴリズムに関して、下記 2 項目を評価した。
①

渋滞情報の生成については、次のアルゴリズムを検証した。
•

1 秒毎に自車両位置を確認し、あるセル(計測単位区間)から、隣接する別のセルに移った時点で、渋滞情報を生成する。

•

直前セルを通過した際の旅行速度が、閾値を下回れば、品質レベル 1 の渋滞情報を生成する。但し、直前セル内の走行距離が一定値よりも短ければ、渋滞情報は生成しない。

•②

本フィールド実験で設定したパラメータは次のとおり。
・セルサイズ300m

・渋滞情報の生成

旅行速度が 20km/h 未満のとき

渋滞情報の統合については、次のアルゴリズムを検証した。
•

統合された渋滞情報は、その素となっている品質レベル 1 の渋滞情報（オリジナル渋滞情報）を保持しており、品質レベルはオリジナル情報の数に等しい。

•

同じセル、同じ方向、及び同じ時間帯の渋滞情報がメッセージプール内で検出された場合、それらを一つの渋滞情報に統合する。但し、オリジナルである品質レ
ベル 1 の渋滞情報が重複しないように統合する。

•

品質レベルが一定値以上になれば拡散モードに変更する。

•

本フィールド実験で設定したパラメータは次のとおり。
・拡散モードに変更する品質レベル(b)3

情報伝達アルゴリズムの評価

情報伝達アルゴリズムに関するフィールド実験に関して、下記 2 項目を評価した。
①

収束モードについては、次のアルゴリズムを検証した。
•

すべての情報には必ず目的地を設定する。収束モードの場合、渋滞情報が発生した位置を目的地とする。本フィールド実験では、渋滞情報が発生したセルの中心

とした。
•

各ノードは自身の位置と各情報の目的地との距離に応じて、各情報の再発信頻度を再設定する。到達限界距離を設定し、その範囲内で発信するが、目的地との距離が開くほど発信頻度は下がる。

•

図 3.6-2 に示される円の範囲内で、当該渋滞情報が発信されることを検証した。

•

本フィールド実験で設定したパラメータは次のとおり。
・到達限界距離(L 0 )

500m

渋滞情報発生地点

渋滞走行区間
渋滞情報を留めたいエリアでは，情報発信確率が高い

エリア外では情報発信確率が低い

図 3.6-2②

収集モードで渋滞情報を発信する範囲

拡散モードについては、次のアルゴリズムを検証した。
•

拡散モードの場合、情報発信起点と、拡散(配信)する方向(θ 0 )、配信範囲(θ 1 )、到達限界距離(L 1 )を設定する。本フィールド実験の情報発信起点は、渋滞情報が発生した場所とした。

•

各ノードは、拡散(配信)する方向(θ 0 )、配信範囲(θ 1 )、到達限界距離(L 1 )で定める配信エリア内で、自身の位置と、各情報の情報発信起点との距離に応じて、各情報の再発信頻度を再設定する。情報発信起点との距離が開くほど発信頻度は下がるものとする。

•

図 3.6-3 に示される扇型の範囲内で、当該渋滞情報が発信されることを、検証した。
•

本フィールド実験で設定したパラメータは次のとおり。
・拡散(配信)する方向(θ0)

180 度(進行と逆方向)

・配信範囲(θ1)

見開き 60 度

・到達限界距離(L 1 )10,000m

渋滞情報発生地点
エリア外では，情報発信確率が低い
渋滞走行区間情報を発信したいエリアでは，情報発信確率が高い

図 3.6-3(5)

車両走行パターン(a)

渋滞区間の設定

拡散モードで渋滞情報を発信する範囲

一周 5,722m の外周路に、渋滞区間を設けた。渋滞区間は各々600m で、渋滞区間では走行速度を 15km/h とした。渋滞区間以外は 60km/h で走行した。
(b)

車両走行パターンの設定

実験車両の走行バターンを設定した。
●

実験 1
5 台の車両を同一方向に、15 秒間隔でスタートさせた。通常走行時は車両間隔が 250m

開き、情報が送受信できないが、渋滞区間では 63m となり、送受信が可能となる。又、5台の車両を走行させることにより、品質レベル 3 の渋滞情報生成が可能となる。
このような状況を設定して、渋滞情報の生成、統合処理の確認、渋滞情報が情報伝達ア
ルゴリズムに従って送信されることを確認した。
●

実験 2
4 台の車両を同一方向に、60 秒間隔でスタートさせ、その後、1 台を逆方向にスタートさせた。逆方向に走行する車両は、渋滞区間が終わった位置で待機する。渋滞区間でも 250m

の車両間隔となり、同一方向で走行する車両間では渋滞情報を送受信できないが、逆方向に走行する車には、すれ違い時に渋滞情報を送信することができる。逆方向に走行する車は、4 台の車両から渋滞情報を受信し、品質レベル 3 の渋滞情報が生成される。
このような状況を設定して、渋滞情報の生成、統合処理の確認、渋滞情報が情報伝達ア
ルゴリズムに従って送信されることを確認した。
●

実験 3
2 台の車両を、速度 60km/h と 100km/h で対面走行させ、情報伝達可能距離、及び連送効

果の有無を確認した。
検証、確認内容と車両走行パターンを表 3.6-1 に示す。
表 3.6-1
実験

検証、確認内容と車両走行パターン

検証、確認内容

車両走行パターン車両間隔

渋滞走行中に送受信を行う。

車 両 は 15 秒 間 隔№
1

5 台の車両が隊列走行
z 渋滞情報の生成、統合処でス タ ート 、車 両

理の確認

間隔は

z 渋滞情報が情報伝達アルz 渋滞時： 63m

ゴリズムに従って送信さz 通常時：250m

れることの確認
2

4 台の車両が隊列走行、1 台

すれ違い時に送受信を行う。

車 両 は 60 秒 間 隔

は逆方向に走行でス タ ート 、車 両

z 渋滞情報の生成、統合処

間隔はz 渋滞時：250m

理の確認
z 渋滞情報が伝達アルゴリ

z 通常時：1,000m

ズムに従って送信される
ことの確認
3

2 台の車両が対面走行、すれ違い時に送受信を行う。

車両間隔 800m か

速度 60km/h と、100km/h のらスタート

2 種類の走行を行う。

すれ 違 い後 、車 両

z 情報伝達可能距離の確認

間隔が 800m 開い

z 連送効果の有無確認て時点で停止フィールド実験で用いたセンターレスプローブ情報処理アルゴリズム、及び情報伝達ア
ルゴリズムで設定したパラメータを表 3.6-2 に示す。

表 3.6-2

アルゴリズムに関するパラメータの設定値
アルゴリズムに関する

設定値

パラメータ
300m

センタレス

セルサイズ

プローブ情報処理

渋滞判定速度V0

20km/hアルゴリズム

生存時間

T0

15 分

情報伝達アルゴリズム

到達限界距離L0500m

情報伝達アルゴリズム

到達限界距離L1

10,000m

拡散モード

配信する方向

θ0

180 度

配信範囲

θ1

60 度

収束モード

3.6.2
(1)

センタレスプローブ処理アルゴリズムの評価
渋滞情報の生成実験 1 の実験車両 1 号車のログデータから、次のことを検証した。
z 渋滞区間を走行する 1 号車が、隣接するセルに移ったときに、渋滞情報を生成した。
(2)

渋滞情報の統合処理

実験 1 の実験車両 1 号車、2 号車のログデータから、次のことを検証した。
z 渋 滞 区 間 を 走 行 す る 実 験 車 両 1 号 車 (YEHIID=111) が 、 時 刻 (MODETIME)
2006/12/13/ 9:45:06 に 、 セ ル 番 号 (CELLCODE)5440522321 を 平 均 旅 行 速 度(TRAVSPEED) 4、進行方位コード(DIRECTION) 7 で走行し、渋滞情報メッセー
ジ ID 476741370108 を生成した。
z 同じく、実験車両 2 号車(YEHIID=112)が、時刻(MODETIME) 2006/12/13/ 9:45:21に、セル番号(CELLCODE)5440522321 を平均旅行速度(TRAVSPEED) 3、進行方
位コード(DIRECTION) 7 で走行し、渋滞情報メッセージ ID 481036337434 を生成した。
z 2 号車が、前方の 1 号車に、渋滞情報メッセージ ID 481036337434 を送信し、受信 し た 1 号 車 で 、 二 つ の 渋 滞 情 報 を 統 合 し 、 品 質 レ ベ ル (統 合 メ ッ セ ー ジ 数 :SAMPLENUM) 2 の渋滞情報メッセージ ID 476741370177 を、時刻(MODETIME)
2006/12/13/ 9:45:21 に、生成した。
3.6.3
(1)

情報伝達アルゴリズムの評価
収束モードの評価

図 3.6-4 は、実験 1-1 で、実験車両 1 号車から 5 号車が生成した品質レベル 1 の渋滞情報を送信(発信)したときの車両の位置を、外周路上に示したものである。
図 3.6-4 は、左上に 1 号車から 5 号車が、品質レベル 1 の渋滞情報を送信した位置を重ね合わせたものである。又、サークルは渋滞情報発生位置を中心に、収束モードのときの到達限界距離 L 0 (=500m)を示している。これから、次のことを確認した。
z 実験 1、実験 2 で、収束モードが規定する到達限界距離 L 0 内で、渋滞情報が送信されており、情報伝達アルゴリズムが設計どおりに作動している。
z 到達限界距離 L 0 外でも、一部渋滞情報を送信しているのを確認した。これは、ダミーデータを追加したにもかかわらず、通信帯域に対して、送信するメッセージが少なく、本来エリア外として送信しない情報まで送信しているものと考える。
(2)

拡散モードの評価

図 3.6-5 は、実験 1-2 で、実験車両 1 号車から 5 号車が生成した品質レベル 3 以上の渋滞情報を送信した位置を、外周路上に示したものである。
拡散モードの場合、品質レベル 3 以上の渋滞情報を、情報伝達アルゴリズムが規定するエリアで送信することを確認しなければならない。メッセージプールに、通信帯域に対して十分なメッセージ(品質レベル 3 以上の渋滞情報)がない場合、当該渋滞情報の優先順位
をいくら低くしても他に送信するものがないので、情報伝達アルゴリズムが規定するエリ
ア外で、メッセージを送信してしまう。そのため、本フィールド実験では、1 秒当たり 2
件のダミーデータを発生させて、通信帯域に対して十分なメッセージ(情報)が、メッセー
ジプールに蓄えられるようにした。
反対に、ダミーデータがないとき、即ちメッセージプールに十分なメッセージがない場
合、優先順位が低いにもかかわらず、通信帯域外で品質レベル 3 以上の渋滞情報を送信してしまうことを確認するため、実験 1-3 と 2-3 を実施した。この場合は、渋滞情報が外周路全域に送信することが確認できるはず、との前提でフィールド実験を行った。その実験結果を示すものが、図 3.6-6 である。
以上の結果から、次のことを確認した。
z 本フィールド実験で、拡散モードで規定する品質レベル 3 以上の渋滞情報を送信するエリアは、拡散(配信)する方向(θ 0 )は 180 度(進行と逆方向)、配信範囲(θ 1 )は見開き 60 度、到達限界距離(L 1 )は 10,000m である。実験 1-2、実験 2-2 の結果から、外周路の二箇所の渋滞区間で生成された品質レベル 3 以上の渋滞情報が、当該送信エリア内で、送信していることを確認できた。
z 一方、実験 1-3、実験 2-3 の場合、全周で品質レベル 3 以上の渋滞情報が送信していることを確認できた。

１～５号車

1 号車
500m

２号車

500m

３号車
500m

５号車

４号車
500m

図 3.6-4

500m

500m

実験 1-1 で 1 号車から 5 号車が品質レベル 1 の渋滞情報を送信した位置

１号車

１～５号車

60°

２号車

３号車

４号車

５号車

図 3.6-5

実験 1-2 で 1 号車から 5 号車が品質レベル 3 以上の渋滞情報を送信した位置

１～５号車

１号車

60°

２号車

４号車

図 3.6-6

３号車

５号車

実験 1-3 で 1 号車から 5 号車が品質レベル 3 以上の渋滞情報を送信した位置

４．スタディの今後の課題及び展開
今後の課題としては、以下が挙げられる。

(1)

情報伝達アルゴリズムのシミュレーションによる評価方法の改善

シミュレーションでは、同時に約 1,000 台のプローブカーが走行し、0.1 秒毎に車車間通信でデータのやり取りを行う。そのため、そのログの量は数十ギガに及び、一つのシミュ
レーションが完了するのに数十時間を費やした。マルチスレッドで処理すればシミュレー
ション時間は短縮できるが、メッセージのやり取りが時系列的に行われるため、シングル
スレッドで処理する方法を選択した。そのため、処理時間を要した。センタレスプローブのアルゴリズムの開発に、シミュレーションによる評価は欠かせなく、シミュレーション
による評価方法を改善していく必要がある。例えば、車両の走行とメッセージ処理を分離する方法が考えられる。

(2)

メッセージ配信伝達に関するフィールドでの評価方法の確立

フィールド実験による評価結果と、シミュレーションの評価結果が一致している場合
は、シミュレーションによる評価が有効であるが、その保証がなくシミュレーションだけに依存するのは本来の姿ではない。一方、センタレスプローブの情報伝達アルゴリズムをフィールド実験で評価しようとすると、数百台の車両を必要とすると考えられる。シミュ
レーションによる評価をアルゴリズムの開発に効果的に活用するために、フィールド実験で十数台程度の現実的な車両台数で、情報伝達アルゴリズムを評価する方法を開発する必
要がある。

(3)

メッセージ配信要件の明確化

周辺の車両にメッセージを配信すればよいアプリケーションがあれば、ある程度離れた場所に配信することが求められるアプリケーションもあり、アプリケーションによってメ
ッセージ配信要件は異なることが分かってきた。更に同じアプリケーションであっても、地域によってメッセージ配信要件が違う。例えば都市部道路網、郊外部道路網、都市間高速道路、地方部の幹線道路(観光地を含む)では、情報配信要件は一律には扱えない。又、本年度のシミュレーション結果を見ると、幹線道路の上下方向には配信速度が早いが、幹線道路と交差する道への配信は遅いことから、メッセージの配信速度は道路のコンフィギュレーションによっても左右される。アプリケーションや地域性を踏まえたメッセージ配
信要件を明確にし、その要件を満たす情報伝達アルゴリズムを開発していかなければなら
ない。

(4)

情報伝達アルゴリズムの改善

現状の情報伝達アルゴリズムは、車両が保有するメッセージが少ないと優先度が低いメ
ッセージまで送信するため、フィールド実験ではダミーデータを発生させることにより、優先度が低いメッセージは送信しないようにして、情報伝達アルゴリズムの送信条件が満たされているかどうかを確認した。しかしながら、ダミーデータによって予想外の状況が発生するなど、情報伝達アルゴリズムの評価を煩雑なものにした。
帯域が空いているときは優先度が低いメッセージでも送信するアルゴリズムは、輻輳の原因になること、今回のフィールド実験は一つのアプリケーションに関して評価したが、今後複数のアプリケーションを同時に扱ったとき、そのアプリケーション間での優先順位
付けが複雑になることなどを考慮すると、不要なメッセージは送信しないなどの改善が必要と思われる。
センタレスプローブの社会実験を平成 20 年度に実施し、センタレスプローブの有効性を広く認知してもらうことを、本スタディの目標としている。そのために、以上の課題を踏まえ、今後の展開としては次のように考えている。
第一に、センタレスプローブの実用化を考慮した取り組みに傾注していかなければならない。第二に、センタレスプローブに必要な革新的な情報伝達アルゴリズムを開発するた
めに、メッセージ配信要件の明確化、フィールドにおけるセンタレスプローブのアルゴリ
ズムを評価する方法を確立する必要があると考える。
前者については、伊豆地域 ITS 推進委員会と連携を図り、センタレスプローブの活用を試みながら、開発を進めることを計画している。伊豆地域 ITS 推進委員会は、伊豆地方の地元有識者が、公共交通の代表、行政代表と一緒になって組織し、ITS を活用した伊豆地方の活性化を企図している。伊豆地方は年間を通じてイベントが多い。一方で、伊豆の幹線道路は限られており、観光客が集中し渋滞が発生する。そこで、ITS を活用して渋滞を緩和し、観光客を増加させることを目指している。又、台風など洪水のよる土砂崩れが多発するが、VICS センサ等が設置されておらず、警告が発せられるまでに時間がかかっている。センタレスプローブは、道路交通などのインフラに頼ることなく、道路交通情報を生成、配信することが可能で、伊豆地方のように道路交通インフラが整備されていない地
域でも、道路交通情報を提供することができる。本スタディによって、センタレスプロー
ブの技術概要は固まっており、伊豆地域 ITS 推進委員会と連携し、活用テーマを明確にした開発は、フィールドでの検証でしか明らかにならない課題の抽出など、実用化を促進するためには貴重な機会と考える。
後者については、伊豆地域 ITS 推進委員会との連携を通じて構築したシステムをテストベットとして、長期間にわたりデータの集積、機器の検証を繰り返すことによって、評価方法を確立することが可能と考える。

―禁無断転載―システム開発1８-Ｆ-５

センタレスプローブ情報システムの開発に関するフィージビリティスタディ
報告書
（要旨）

平成 19 年 3 月

作成財団法人 機械システム振興協会
東京都港区三田一丁目 4 番 28 号
TEL 03－3454－1311

委託先名
住
所

財団法人 日本自動車研究所
東京都港区芝大門一丁目 1 番 30 号
TEL 03－5733－7924