http://www.InternetITS.org/

インターネットITSプロジェクト

2001年度 研究開発の成果

2002.5.31
インターネットITS共同研究グループ

成果の全体像

http://www.InternetITS.org/①コンセプトの明確化– インターネットITS基盤を利用したサービスを検討し、端的にインターネッ
トITSのコンセプトを伝えるための資料を作成した。

②共通基盤となる技術の開発– インターネットITS基盤の アーキテクチャを整理するとともに、基盤仕様(素案)を策定した他、共通サービス基盤の基本的な機能を検討･構築した。

③一部アプリケーションのフィールドでの実証– 実験システムを構築し、名古屋および首都圏における大規模実証実験、高機能実験車を用いた実験を実施し、システムの技術開発面、利用者から見たサービス面に係る知見を得た。

1

①コンセプトの明確化

http://www.InternetITS.org/【サービス体系の整理】• 53のインターネットITS基盤を利用したアプリケーションを提案し、これらを情報の利用者、提供者およびその流れという視点で整理をし、8つのサービス分野としてまとめた。
• 本資料は、インターネットITSのサービスをわかりやすく説明する材料として、また、アイデアの発想を促すための土台として活用可能なものとした。
サービス要素受信サービス内容車両へリアルタイムに情報（広告）配信する。
路側のカメラにより死角画像を提供する。

サービス利用者

サービス提供者

個人（車）、乗客、トラック

広告主等

個人（車）、トラック

メーカー

個人（車）、トラック

駐車場等の管理者

個人（家）、個人（車）、乗客、歩行者

バス、鉄道
事業者

車両の位置情報に応じて、周辺の駐車場を案内する。

個人（車）駐車場事業者

DSRC等を利用した位置限定の情報を提供する。

個人（車）メーカー、販売業者、広告主

駐車場等のカメラにより鳥瞰図画像を提供する。
リアルタイムに、バス停や駅などの発着時刻等を案内する。

IIｔｓ

情報の受信

−車内の情報（速度等）発信→旅行時間情報へ加工−車両の状態情報発信→安全運転支援IIｔｓ−車内機器の操作
IIｔｓ−車内からの外部機器操作

コントロール −遠隔メンテナンス!

!
IIｔｓ!
IIｔｓ

IIｔｓ

（緊急時、事故通報等）
IIｔｓ−車々間コミュニケーション等

コミュニケーション−課金システム
IIｔｓ¥ $交換（課金）−車両の動態管理、運行管理−車両の状態（バッテリー等）管理

IIｔｓ

IIｔｓ

IIｔｓ

−事業共同化、連携−コミュニティ創出

共有

情報の発信 −ドライバーの情報発信

IIｔｓ

アプリケーションの整理表−ナビゲーション等−他公共交通機関情報、駐車場情報−データのダウンロード−コンテンツ配信

IIｔｓ？

−盗難車追跡モニタリング−プローブ情報の加工−車両開発−マーケティング
−安全／健康／エコ運転支援

蓄積／分析

インターネットITSの８つのサービス要素2

②共通基盤となる技術の開発

http://www.InternetITS.org/【基盤仕様の策定】
今回の実証実験システムの構築作業と平行して、インターネットITSで扱う車両情報の種類や形式、車載機器をインターネットに接続する方法、車載機器のアプリケーションの実行環境の３種に関する研究開発を実施・評価し、有効性を確認した上で、基盤仕様書（素案）としてとりまとめた。

車内

車外
Application

Application

Application

Application

車両情報
入出力

VM
SNMP/HTTP
TCP/UDPIP
Datalink

共通サービス
基盤Internet•車両情報管理•無線LAN

•位置管理

•携帯電話

•プローブ情報•DSRCなどなど

IP
Datalink

Application
サービス

IP
Datalink

インターネットITSアーキテクチャ

TCP/UDPTCP/UDPIP
Datalink

IP
Datalink

3

②共通基盤となる技術の開発【基盤の開発】•2つのIP over DSRC技術•SLPによる店舗サーバ発見技術

センタ• Mobile IPv6の実運用•Mobile IPv6を使った例
を見ない実証実験• IPv6-IPv4混在環境の運用•各種IPv6-IPv4トランス
レータの運用•IPv6-IPv4 トランスレータを介した認証• 共通サービス基盤の開発
•車両情報
•位置情報
•個人情報
•マッチメーキングエンジン•音声IF機能店舗

http://www.InternetITS.org/

IPv6網

IPv4網

• IPv6モバイルネットワーク• 複数のメディアを駆使した連続通信環境• IPv4トンネリングの活用
インターネットITS基盤システムの各技術

4

③一部アプリケーションのフィールドでの実証

http://www.InternetITS.org/

z 開発した共通基盤およびアプリケーションの有効性を実証。
z 様々なアプリケーションを同一のプラットフォーム（共通基盤）において実現。

名古屋実験:
輸送事業者、利用者を主なユーザーと想定したサービス
32社のタクシー1570台を用いた実証実験•タクシー業務用サービス•乗客向け情報提供サービス•プローブ情報提供サービス

首都圏実験 :
一般ドライバーを主なユーザーと想定したサー
ビス
一般車両70台を用いた実証実施•ガソリンスタンドにおけるサービスガイダン
ス、コンテンツ配信•駐車場における決済、コンテンツ配信等•走行中の情報提供

高機能実験車実験：
インターネットITSの将来像の一部を具現化
1台の高機能実験車を用いた実験を実施•ＩＰｖ６による車内ネットワーク化、メディアフリーの通信ルータ機能•運転者安全運転支援、乗員別健康管理、グループメディアコミュニ
ケーション等

インターネットITS共通基盤
実験システムの全体構成イメージ5実証実験結果総括

http://www.InternetITS.org/【結果総括】
z 1つの基盤システム上に、複数の開発者がアプリケーションを構築。これまでのモノリシックなシステムから基盤とアプリケーションを分離。
⇒新たなテレマティクス端末の可能性の提示z インターネットITS基盤コアシステムを構築。
⇒今後の本分野における活動基盤として利用
z 32社のタクシー1,570台、一般車両70台、高機能実験車1台を利用し、1億5900レコード分(29GByteに相当)のプローブ情報等のデータを取得。
⇒交通、環境等の学術利用
z パイロットアプリケーションによる社会的需要性の検証。
⇒タクシー事業者、気象事業者、自動車会社、大学からの協力要請
z パイロットアプリケーションによる研究要素の洗い出し。
⇒操作性、レスポンス、ビジネスモデルにおける問題点の認識
6

【名古屋地区実証実験】

http://www.InternetITS.org/

雨量データとプローブ降雨情報••気象協会超短時間降雨予測初期値（１０分間雨量データ）よりもプローブ情報（５分間気象協会超短時間降雨予測初期値（１０分間雨量データ）よりもプローブ情報（５分間に収集されるワイパONデータの割合）の方が雨の降り始めを細かく検出できた。また、に収集されるワイパONデータの割合）の方が雨の降り始めを細かく検出できた。また、レーダで検出できないごく少量の降雨を検出することも可能。
レーダで検出できないごく少量の降雨を検出することも可能。
••プローブ情報システムは、降雨情報の精度向上に有用であることがわかった。
プローブ情報システムは、降雨情報の精度向上に有用であることがわかった。

100

1.080

0.8600.6400.4200.2

雨量(mm/10min)

・ごく少量の降雨を検出

ワイパ動作率(%)

10分間雨量データとワイパ動作率推移の比較

ワイパー動作率
10分間雨量・0:25に降雨を検出
0.0

0
0:00

0:10

0:20

0:30

0:40

0:50

(気象協会超短時間降雨予測初期値では0:30)

時刻

図 １０分間雨量データとワイパ動作率推移の比較
7

【名古屋地区実証実験】

http://www.InternetITS.org/

降雨情報のカバー率••中心部においては、概ね９０％の地域で5分ごとに情報を収集・更新できた。
中心部においては、概ね９０％の地域で5分ごとに情報を収集・更新できた。
••一方、タクシー走行量の少ない郊外部では、5分ごとに情報を収集・更新できた地域の割
一方、タクシー走行量の少ない郊外部では、5分ごとに情報を収集・更新できた地域の割合は30%程度に留まった。
合は30%程度に留まった。
※２次メッシュを構成する全３次メッシュに占めるデータ送信が行われたメッシュの割合※２次メッシュを構成する全３次メッシュに占めるデータ送信が行われたメッシュの割合

メッシュカバー率（2月11日 12:00 〜 2月12日 12:00）

カバー率

100%
80%
地域E
地域G

60%
40%
20%
0%
0:00 3:00 6:00 9:00 12:00 15:00 18:00 21:00

時刻
8

【名古屋地区実証実験】

http://www.InternetITS.org/

アンケート調査結果概要(一部抜粋)
気象事業者•• レーダーによって観測できない低い雨雲や、雨量計でも検地レーダーによって観測できない低い雨雲や、雨量計でも検地できない0.5mm以下の降雨を観測することができる。
できない0.5mm以下の降雨を観測することができる。
•• レーダーによる雨域をキャリブレーションできる。
レーダーによる雨域をキャリブレーションできる。
•• 新たなサービスとして、路面温度を観測することによる凍結新たなサービスとして、路面温度を観測することによる凍結情報、ヒートアイランドなどの都市化の影響の観測、大気質情報、ヒートアイランドなどの都市化の影響の観測、大気質の観測、花粉飛散の観測などが期待できる。の観測、花粉飛散の観測などが期待できる。
大学関係者•• 道路交通マネージメントの基礎データとして有用。
道路交通マネージメントの基礎データとして有用。
•• 交通センサスの低コスト化などに期待ができる。
交通センサスの低コスト化などに期待ができる。
9【名古屋地区実証実験】

http://www.InternetITS.org/

プッシュ型コンテンツ配信の応答性••車載機の位置情報送信から車載機へのコンテンツ情報表示までの時間は平均４０秒
車載機の位置情報送信から車載機へのコンテンツ情報表示までの時間は平均４０秒であり、走行距離に換算すると約450m。
であり、走行距離に換算すると約450m。
••コンテンツ配信を行う場合は、これらの情報送受信時間を考慮した位置情報管理が必コンテンツ配信を行う場合は、これらの情報送受信時間を考慮した位置情報管理が必
要である。
要である。

454035302520151050詳
細ン
テンツ表 コンテンツ受信までに車両が走行する距離
走行速度
１０km/h
２０km/h
４０km/h
８０km/h受信するまでに走行する距離
１１１ｍ
２２２ｍ
４４４ｍ
８８８ｍ

コ

アップ
ポッ

表示

プ
選択

信
バ
送
信
AP
サー

H配

測定間所要時間
所要時間累計

PU
S

地理

位
置情報
サ位
置

情報

ー
バ
受

信

送
信

測定点間所要時間（秒）

20
18
16
14121086
420

所要時間累計（秒）車両位置情報送信→ＰＵＳＨ型コンテンツ表示までの時間

図 コンテンツ詳細表示までの所要時間10【首都圏実証実験】

http://www.InternetITS.org/

アンケート調査結果••SS実験、駐車場実験
SS実験、駐車場実験
協力事業者からのコメント：
協力事業者からのコメント：•店舗情報サービスは、独自サービス展開および顧客サービス向上の点で有効と•店舗情報サービスは、独自サービス展開および顧客サービス向上の点で有効と判断できる。
判断できる。
•他店舗との連携や、異業種との情報流通によるコンテンツ魅力向上が期待できる。
•他店舗との連携や、異業種との情報流通によるコンテンツ魅力向上が期待できる。
•実用化に向けては、応答速度や操作性の改善が必要。
•実用化に向けては、応答速度や操作性の改善が必要。
•昨年度行わなかったサービスも含めて、今後も積極的に参加したい。
•昨年度行わなかったサービスも含めて、今後も積極的に参加したい。
入庫／出庫ゲート自動開閉のアンケート結果

自動決済のアンケート結果

121086420

な
い

な
いはで
く便
利
全

利
でり便
あまど
ちらとも

言

え

はな
い

利
便ややは利
で
く便
全便
利

な
いな
いで
利り便

あまど
ちらとも

言
え

はな
い

利や便や便

利

987654321011

【高機能実験車による実験】

http://www.InternetITS.org/

車両情報の動的取得••車両の持つ情報や運転者の挙動情報などを、車両データ辞書として単位や精度など車両の持つ情報や運転者の挙動情報などを、車両データ辞書として単位や精度などのばらつきを正規化して保持し、SNMPによって動的に取得することを実現し、15秒ほのばらつきを正規化して保持し、SNMPによって動的に取得することを実現し、15秒ほどの遅れがあることを測定した。
どの遅れがあることを測定した。

車載ルータ••Mobile
Mobile Subnet機構により、常に同一のIPv6アドレスによって車内外と通信できる環境を、Subnet機構により、常に同一のIPv6アドレスによって車内外と通信できる環境を、車内の複数の座席や端末に提供することに成功した。
車内の複数の座席や端末に提供することに成功した。
••上記機能は通信メディアで利用されている通信プロトコル(IPv6、IPv4)に関わらず機能
上記機能は通信メディアで利用されている通信プロトコル(IPv6、IPv4)に関わらず機能できることを確認した。
できることを確認した。

通信インタフェースの自動切り替え••走行中に、設定した優先順位で複数インタフェース
走行中に、設定した優先順位で複数インタフェース※※の自動切り替えを行いながら通信の自動切り替えを行いながら通信を継続することに成功した。
を継続することに成功した。
••インタフェースの状態を検知して即座に通知する機構を実装し、インタフェース切り替インタフェースの状態を検知して即座に通知する機構を実装し、インタフェース切り替え速度を向上し、安定した通信を実現した。切り替えにかかる時間は、切り替える前とえ速度を向上し、安定した通信を実現した。切り替えにかかる時間は、切り替える前と後のメディアによって、1秒未満から数秒の間で実現できた。
後のメディアによって、1秒未満から数秒の間で実現できた。
※IEEE802.11b(無線LAN)、PIAFS、AirH”、DoPa等※IEEE802.11b(無線LAN)、PIAFS、AirH”、DoPa等
12