▶ 株式会社東芝の特許一覧 ▶ 東芝エネルギーシステムズ株式会社の特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-05-12
(45)【発行日】2023-05-22
(54)【発明の名称】車載装置、車車間通信システム、およびプログラム
(51)【国際特許分類】
G08G 1/09 20060101AFI20230515BHJP
G08G 1/16 20060101ALI20230515BHJP
G10L 15/00 20130101ALI20230515BHJP
G10L 13/00 20060101ALI20230515BHJP
H04R 3/00 20060101ALI20230515BHJP
【ＦＩ】
G08G1/09 H
G08G1/16 A
G10L15/00 200Q
G10L13/00 100H
H04R3/00 310
【請求項の数】
18
(21)【出願番号】P 2021573679
(86)(22)【出願日】2020-01-29
(86)【国際出願番号】 JP2020003070
(87)【国際公開番号】W WO2021152713
(87)【国際公開日】2021-08-05
【審査請求日】2021-11-30
(73)【特許権者】
【識別番号】000003078
【氏名又は名称】株式会社東芝
(73)【特許権者】
【識別番号】317015294
【氏名又は名称】東芝エネルギーシステムズ株式会社
(74)【代理人】
【識別番号】110003708
【氏名又は名称】弁理士法人鈴榮特許綜合事務所
(72)【発明者】
【氏名】山口 智子
(72)【発明者】
【氏名】久保 喜義
(72)【発明者】
【氏名】青柳 和則
(72)【発明者】
【氏名】荻田 能弘
【審査官】稲垣 彰彦
(56)【参考文献】
【文献】特開２０１４－１３４８９７（ＪＰ，Ａ）
【文献】特開２００２－１８３８８９（ＪＰ，Ａ）
【文献】特開２０１０－２７２０８３（ＪＰ，Ａ）
【文献】特開２０１９－４０３０５（ＪＰ，Ａ）
【文献】特開２０１７－１８２７７６（ＪＰ，Ａ）
【文献】特開２０１７－６８７４１（ＪＰ，Ａ）
【文献】特開２０１５－１９４８２８（ＪＰ，Ａ）
【文献】特開２０１５－９１０５８（ＪＰ，Ａ）
【文献】特開２０１４－３５５８２（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０８Ｇ １／００－９９／００
(57)【特許請求の範囲】
【請求項1】
他車の運転手の意思に対応するコマンドコード、および、当該他車の位置情報を少なくとも含むメッセージデータを前記他車から受信する受信部と、前記メッセージデータに含まれる位置情報と自車の位置情報とに基づいて、前記メッセージデータの宛先が前記自車であると判定された場合に、前記メッセージデータに含まれるコマンドコードから音声メッセージを合成する音声合成部と、
前記受信したメッセージデータを１ホップだけ転送する転送部と、
前記受信したメッセージデータを、自車の運転手の意思に応じてさらに転送するリツイート部とを具備する、車載装置。
【請求項2】
他車の運転手の意思に対応するコマンドコード、および、当該他車の位置情報と当該他車から見たときの通信相手を識別するコード情報を少なくとも含むメッセージデータを前記他車から受信する受信部と、
前記メッセージデータに含まれる位置情報および前記コード情報ならびに自車の位置情報に基づいて、前記メッセージデータの宛先が前記自車であると判定された場合に、前記メッセージデータに含まれるコマンドコードから音声メッセージを合成する音声合成部と、
を具備する、車載装置。
【請求項3】
前記メッセージデータに含まれる位置情報と自車の位置情報とに基づいて、当該メッセージデータを送信した通信相手の自車に対する相対位置を算出する相対位置算出部をさらに具備する、請求項１または２に記載の車載装置。
【請求項4】
前記音声合成部は、算出された前記相対位置に基づいて、前記メッセージデータの宛先が前記自車であるか否かを判定する、請求項３に記載の車載装置。
【請求項5】
自車が複数のスピーカを備える場合に、前記音声合成部は、算出された前記通信相手の相対位置を反映する位置に音像を定位させて前記音声メッセージを拡声出力する、請求項３に記載の車載装置。
【請求項6】
前記相対位置算出部は、前記メッセージデータに含まれる位置情報と自車の位置情報とに基づいて、前記通信相手の自車に対する相対速度、および相対的な移動方向を算出し、
前記音声合成部は、算出された前記通信相手の相対速度および相対的な移動方向を反映すべく前記音像の位置およびピッチを変化させる、請求項５に記載の車載装置。
【請求項7】
前記音声合成部は、前記通信相手の車種に応じて擬人化した音声メッセージを出力する、請求項５に記載の車載装置。
【請求項8】
前記音声合成部は、前記通信相手の車両の運転手の属性に応じて擬人化した音声メッセージを出力する、請求項５に記載の車載装置。
【請求項9】
前記自車の運転手の意思に対応するコマンドコード、および、当該自車の位置情報を少なくとも含むメッセージデータを送信する送信部をさらに具備する、請求項１または２に記載の車載装置。
【請求項10】
自車の運転手の発した音声を認識する音声認識部をさらに具備し、
前記送信部は、前記認識の結果に基づく前記コマンドコードを前記メッセージデータに含めて送信する、請求項９に記載の車載装置。
【請求項11】
自車の位置情報を取得して当該自車の走行情報を算出する走行情報算出部をさらに具備し、
前記送信部は、前記走行情報を前記メッセージデータに含めて送信する、請求項９に記載の車載装置。
【請求項12】
前記走行情報算出部は、前記自車の位置情報、移動方角、および、移動速度をタイムスタンプとともに当該自車の識別情報に対応付けた履歴データを含む自車の走行履歴情報を算出し、
前記送信部は、前記自車の走行履歴情報を前記メッセージデータに含めて送信する、請求項１１に記載の車載装置。
【請求項13】
前記送信部は、さらに、他車から受信した当該他車の走行履歴情報を前記メッセージデータに含めて送信する、請求項１２に記載の車載装置。
【請求項14】
前記自車の走行履歴情報と、受信したメッセージデータに含まれる前記他車の走行履歴情報とに基づいて算出される自車の後の車列数が規定数を超えた場合に、前記音声合成部は、警告メッセージを生成する、請求項１３に記載の車載装置。
【請求項15】
前記受信部および前記送信部は、特定小電力無線通信インフラ基盤を利用して前記メッセージデータを授受する、請求項９に記載の車載装置。
【請求項16】
請求項１５に記載の車載装置と、車両間の前記メッセージデータの授受を仲介する特定小電力無線通信インフラ基盤とを具備する、車車間通信システム。
【請求項17】
プロセッサとメモリを備える車載装置の前記メモリに書き込み可能なプログラムであって、前記プロセッサに、他車の運転手の意思に対応するコマンドコード、および、当該他車の位置情報を少なくとも含むメッセージデータを前記他車から受信させるための命令と、
前記プロセッサに、前記メッセージデータに含まれる位置情報と自車の位置情報とに基づいて、前記メッセージデータの宛先が前記自車であると判定された場合に、前記メッセージデータに含まれるコマンドコードから音声メッセージを合成させるための命令と、
前記プロセッサに、前記受信したメッセージデータを１ホップだけ転送させるための命令と、
前記プロセッサに、前記受信したメッセージデータを、自車の運転手の意思に応じてさらに転送させるための命令とを含む、プログラム。
【請求項18】
プロセッサとメモリを備える車載装置の前記メモリに書き込み可能なプログラムであって、
前記プロセッサに、他車の運転手の意思に対応するコマンドコード、および、当該他車の位置情報と当該他車から見たときの通信相手を識別するコード情報を少なくとも含むメッセージデータを前記他車から受信させるための命令と、
前記プロセッサに、前記メッセージデータに含まれる位置情報および前記コード情報ならびに自車の位置情報に基づいて、前記メッセージデータの宛先が前記自車であると判定された場合に、前記メッセージデータに含まれるコマンドコードから音声メッセージを合成させるための命令とを含む、プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明の実施形態は、車載装置、車車間通信システム、およびプログラムに関する。
【背景技術】
【0002】
車車間通信は、長期にわたって継続的に検討されている。検討では、例えば７００ＭＨｚ帯の利用などが提案された。しかしながら現実的な普及の度合いは、現在に至っても十分とは言えない。それには、主に以下のような事情が考えられる。
（１） 普及が或る程度進まなければ利用者が利益を享受できないので、初期の普及が進まないというジレンマがあること。つまり、普及数が一定数を超えるまでの＜普及の壁＞があること。
（２） 車買い替え周期が伸びてきており、新たな技術が浸透するのに時間がかかるようになったこと。
（３） 全国規模での標準化、或いは国際的な基準化が難しく、標準化作業に時間がかかるとともに、標準の普及自体が進んでいないこと。
（４） 車車間通信の明確なメリットが社会に浸透していないこと。
（５） 車載レーダ／カメラを用いた安全サポート機能の実用性が広く社会に認知され、車車間通信の価値が相対的に低下したこと。
（１） 普及が或る程度進まなければ利用者が利益を享受できないので、初期の普及が進まないというジレンマがあること。つまり、普及数が一定数を超えるまでの＜普及の壁＞があること。
（２） 車買い替え周期が伸びてきており、新たな技術が浸透するのに時間がかかるようになったこと。
（３） 全国規模での標準化、或いは国際的な基準化が難しく、標準化作業に時間がかかるとともに、標準の普及自体が進んでいないこと。
（４） 車車間通信の明確なメリットが社会に浸透していないこと。
（５） 車載レーダ／カメラを用いた安全サポート機能の実用性が広く社会に認知され、車車間通信の価値が相対的に低下したこと。
【先行技術文献】
【特許文献】
【0003】
【文献】日本国特許第４０４０４４１号明細書
【文献】日本国特許第６４４７７４９号明細書
【非特許文献】
【0004】
【文献】“RECAIUS（登録商標） 音声クリエータ／音声合成サービス”，[online]，［令和1年11月8日検索］,インターネット，<URL:https://www.toshiba-sol.co.jp/pro/recaius/lineup/creator.html>
【文献】“coestation（登録商標）”，[online]，［令和1年11月8日検索］,インターネット，<URL:https://coestation.jp/>
【発明の概要】
【発明が解決しようとする課題】
【0005】
車車間通信で送信すべき情報を効率よく取捨選択する技術等が知られているが、車車間通信の方法や、実用的なアプリケーションは未だ検討段階にある。Ｓｏｃｉｅｔｙ５．０ともいわれる、来るべき社会のため、車車間通信に係わる装置や各種のインフラを普及させることが望まれている。
そこで、目的は、車車間通信システムの普及を促進することにある。
そこで、目的は、車車間通信システムの普及を促進することにある。
【課題を解決するための手段】
【0006】
実施形態によれば、車載装置は、受信部と、音声合成部とを具備する。受信部は、他車の運転手の意思に対応するコマンドコード、および、当該他車の位置情報を少なくとも含むメッセージデータを他車から受信する。音声合成部は、メッセージデータに含まれる位置情報と自車の位置情報とに基づいて、メッセージデータの宛先が自車であると判定された場合に、メッセージデータに含まれるコマンドコードから音声メッセージを合成する。
【図面の簡単な説明】
【0007】
【発明を実施するための形態】
【0008】
＜構成＞
図１は、実施形態に係わる車載システムの一例を示す機能ブロック図である。車車間通信システムは、車載装置をはじめとするハードウェア、および、当該ハードウェアにおいて実行される機能を実装するプログラム等の、各種のインフラを含んでよい。
車載システムは、車両に搭載される車載装置２を中核として形成される。車載装置２は、カーナビゲーションシステム３を備える車両に搭載されることができる。車載装置２に、カーナビゲーションシステム３用のＧＰＳ（Global Positioning System）アンテナ１と、運転手６の音声データを取得するためのマイク５が接続される。カーナビゲーションシステム３には、車両の複数のスピーカ４，７，８，９が接続される。スピーカ４，７，８，９は、それぞれ運転手６の左前方（前Ｌ）、右前方（前Ｒ）、左後方（後Ｌ）、右後方（後Ｒ）に設置される。
図１は、実施形態に係わる車載システムの一例を示す機能ブロック図である。車車間通信システムは、車載装置をはじめとするハードウェア、および、当該ハードウェアにおいて実行される機能を実装するプログラム等の、各種のインフラを含んでよい。
車載システムは、車両に搭載される車載装置２を中核として形成される。車載装置２は、カーナビゲーションシステム３を備える車両に搭載されることができる。車載装置２に、カーナビゲーションシステム３用のＧＰＳ（Global Positioning System）アンテナ１と、運転手６の音声データを取得するためのマイク５が接続される。カーナビゲーションシステム３には、車両の複数のスピーカ４，７，８，９が接続される。スピーカ４，７，８，９は、それぞれ運転手６の左前方（前Ｌ）、右前方（前Ｒ）、左後方（後Ｌ）、右後方（後Ｒ）に設置される。
【0009】
すなわち実施形態では、いわゆる４チャンネル・スピーカを備えるオーディオ設備を持つ車両を想定する。スピーカ４，７，８，９により、オーディオ設備は、車内空間の任意の位置に音像を定位させることができる。
【0010】
車載装置２は、ＣＰＵ（Central Processing Unit）２４およびメモリ２５を備える、いわゆる組み込み型のコンピュータである。車載装置２は、さらに、ＧＰＳモジュール２１、内蔵アンテナ２２、および無線モジュール２３を備える。ＧＰＳモジュール２１は、ＧＰＳアンテナ１からの信号を取り込み、内部で分岐してカーナビゲーションシステム３へと出力する。一方、内蔵アンテナ２２は無線モジュール２３が他車の車載装置と通信するために用いられる。
【0011】
図２は、車載装置２の使用環境の一例を示す図である。図２に示されるように、車載装置２は、例えばダッシュボードに取り付けられる。いわゆるポン付けである。好ましくは、バックミラーの下方の、運転手の視野の妨げにならない位置に取り付けるとよい。車載装置２を搭載する複数の車両が互いに通信し合うことで、実施形態の車車間通信システムが形成される。
実施形態では、各車両の車載装置２が互いに既定のフォーマットのメッセージデータを授受し合うことを想定する。複数の車載装置２は、例えば、既設の特定小電力無線通信インフラ基盤を利用して互いにメッセージデータを授受し合うことができる。この種のインフラ基盤として代表的なものは、日本においては、スマートメータ通信インフラを挙げることができる。周知のように、日本におけるスマートメータ通信インフラは、９００ＭＨｚ帯を利用して装置間のデータの授受を仲介する。
実施形態では、各車両の車載装置２が互いに既定のフォーマットのメッセージデータを授受し合うことを想定する。複数の車載装置２は、例えば、既設の特定小電力無線通信インフラ基盤を利用して互いにメッセージデータを授受し合うことができる。この種のインフラ基盤として代表的なものは、日本においては、スマートメータ通信インフラを挙げることができる。周知のように、日本におけるスマートメータ通信インフラは、９００ＭＨｚ帯を利用して装置間のデータの授受を仲介する。
【0012】
車両の運転手は、車載装置２に音声で例えば「平均車速を教えて！」と命令する（音声コマンド）。そうすると車載装置２は、「平均車速は、左車線が時速〇ｋｍ、右車線が時速〇ｋｍです」と自動で応答する（自動応答）。これを受けて運転手は、車線変更の要否について、例えば「１分しか違わないならこのまま行こう」という判断を下すことができる。
【0013】
図３は、車載装置２の一例を示す機能ブロック図である。車載装置２は、音声認識部２４ａ、送信部２４ｂ、リツイート部２４ｃ、転送部２４ｄ、音声合成部２４ｅ、相対位置算出部２４ｆ、受信部２４ｇ、スピーカ接続部２４ｈ、走行情報算出部２４ｉ、および、ＧＰＳ受信部２４ｊを備える。これらの機能ブロックは、ＣＰＵ２４の処理機能として実現される。なお、音声合成部２４ｅは、スピーカ接続部２４ｈを介してスピーカ４，７，８，９に接続される。
【0014】
また、車載装置２は、キーワード保存部２５ａ、方言データ保存部２５ｂ、車種毎声質定義データ保存部２５ｃ、運転手属性毎声質定義データ保存部２５ｄ、コマンド定義データ保存部２５ｅ、自車走行情報記憶部２５ｆ、他車走行情報記憶部２５ｇ、自車設定情報保存部２５ｈ、および、運転手設定情報保存部２５ｉを備える。これらは、メモリ２５に設けられる記憶領域として理解され得る。また、メモリ２５は、ＣＰＵ２４の各機能を実現するための命令を含むプログラムも、記憶する。
【0015】
受信部２４ｇは、他車から送信されたメッセージデータを受信する。メッセージデータは、他車の運転手の意思に対応するコマンドコード、および、当該他車の位置情報を少なくとも含む。
【0016】
図４は、実施形態に係わる車車間通信で用いられるメッセージデータのフォーマットの一例を示す図である。コマンドコードは、メッセージデータの例えば１０番目のフィールドに記載される。他車の位置情報は、複数（例えば（１）～（Ｎ））の他車走行履歴情報にそれぞれ記載される。
【0017】
他車走行履歴情報は、他車の識別情報（例えば、製造番号）に、当該他車の複数の履歴データ（１）～（ｍ）を対応付けた構造のデータである。履歴データのそれぞれは、緯度・経度で表される位置情報、移動方角、および移動速度にタイムスタンプを対応付けた構造を持つ情報である。この情報を走行情報と称する。走行情報は受信部２４ｇによりメッセージデータから抽出されて、他車走行情報記憶部２５ｇに記憶される。
メッセージデータは、このほか、リツイートフラグ、発信者の識別情報、発信者の緯度・経度、発信時タイムスタンプ、通信相手コード、、、等のフィールドを含む。
メッセージデータは、このほか、リツイートフラグ、発信者の識別情報、発信者の緯度・経度、発信時タイムスタンプ、通信相手コード、、、等のフィールドを含む。
【0018】
８番目のフィールドの発信車種別は、メッセージデータを送信した車両の属性を示す。車両の属性とは、例えば車種、色、年式、タイプなどがある。車種としては大型トラック、中型トラック、…、普通車、軽自動車などがある。色は、例えば赤系、青系、…、等に分類される。これらの情報は、例えば車載装置２の初期設定の際に、自車設定情報保存部２５ｈに予め記憶される。
【0019】
９番目のフィールドの発信車の運転手属性は、メッセージデータを送信した車両の運転手の属性（運転手属性）を示す。運転手属性とは、例えば男性、女性、年齢、ベテラン、初心者などの、運転手の特徴を示す情報である。これらの情報は、例えば車載装置２の初期設定の際に、運転手設定情報保存部２５ｉに予め記憶される。
【0020】
なお、図４に示されるメッセージデータの構成は一例であり、実際の通信における具体的な通信メッセージの内容を示すとは限らず、番号と各フィールドの対応も一例に過ぎない。現実の通信においては、効率等の観点から、例えばデータ圧縮処理等が適宜、施される。
【0021】
音声合成部２４ｅは、受信したメッセージデータに含まれる送信元他車の位置情報と、ＧＰＳ受信部２４ｊから取得された自車の位置情報とに基づいて、メッセージデータの宛先が自車であるか否かを判定する。そして、メッセージデータの宛先が自車であると判定された場合に、音声合成部２４ｅは、受信したメッセージデータのコマンドコードから音声メッセージを合成する。合成された音声メッセージは、スピーカ４，７，８，９から拡声出力される。
【0022】
送信部２４ｂは、メッセージデータを他車に宛てて送信する。図４に示されるように、メッセージデータは、自車（発信者）の運転手の意思に対応するコマンドコードと、自車の位置情報（緯度・経度）を少なくとも含む。もちろん、発信車の識別情報や発信時タイムスタンプなども、メッセージデータに含まれる。
【0023】
ここで、送信部２４ｂおよび受信部２４ｇは、スマートメータ通信基盤１００を利用して、自車と他車との間でメッセージデータを授受する。日本国内の各電力会社がスマートメータの導入を進めており、２０２０年度から２０２３年度にかけて、ほぼ国内全世帯への導入が完了する。その通信手段の大多数は９２０ＭＨｚ帯の特定小電力無線を用いたものであり、適用範囲は３，０００万世帯～５，０００万世帯にも上ると見込まれる。よって、スマートメータ通信基盤１００として、信頼性が高く、安価なものを利用することが可能である。
【0024】
９２０ＭＨｚ帯の特定小電力無線は、さらに以下の特徴を有する。
（１）出力２０ｍＷまでは無線局免許が不要であること。
（２）携帯電話でいうところのいわゆるプラチナバンドに相当する周波数帯であり、建物への回り込み特性が比較的良いこと。
（３）電波が遠くに飛びすぎないので、車車間通信のような比較的近距離間通信に適すること。
これらの特徴から、スマートメータ通信基盤１００は車車間通信の適用にも適している。このような特徴を活用し、高信頼で安価な通信機能を利用することにより＜普及の壁＞を打破することが期待される。
（１）出力２０ｍＷまでは無線局免許が不要であること。
（２）携帯電話でいうところのいわゆるプラチナバンドに相当する周波数帯であり、建物への回り込み特性が比較的良いこと。
（３）電波が遠くに飛びすぎないので、車車間通信のような比較的近距離間通信に適すること。
これらの特徴から、スマートメータ通信基盤１００は車車間通信の適用にも適している。このような特徴を活用し、高信頼で安価な通信機能を利用することにより＜普及の壁＞を打破することが期待される。
【0025】
音声認識部２４ａは、自車の運転手の発した音声を認識する。認識の結果は送信部に送られる。送信部は、音声認識の結果に基づくコマンドコードをメッセージデータに格納し、他車に宛てて送信する。
【0026】
走行情報算出部２４ｉは、ＧＰＳ受信部２４ｊから自車の位置情報を取得し、自車の位置情報、移動方角、および移動速度にタイムスタンプを対応付けた、自車の走行情報を算出する。自車走行情報は、自車走行情報記憶部２５ｆに記憶されるとともに、送信部２４ｂにより、メッセージデータに格納されて送信される。
【0027】
転送部２４ｄは、他車から受信したメッセージデータを、別の他車にさらに１ホップ（ＨＯＰ）だけ転送する。
リツイート部２４ｃは、他車から受信したメッセージデータを、自車の運転手の意思に応じて、別の他車にさらに転送する。
リツイート部２４ｃは、他車から受信したメッセージデータを、自車の運転手の意思に応じて、別の他車にさらに転送する。
【0028】
相対位置算出部２４ｆは、他車から受信したメッセージデータに含まれる位置情報と自車の位置情報とに基づいて、このメッセージデータを送信した通信相手（送信元）の、自車に対する相対位置を算出する。相対位置が算出されると、音声合成部２４ｅは、この相対位置に基づいて、送信元から送信されたメッセージデータの宛先が自車であるか否かを判定する。
【0029】
＜作用＞
次に、上記構成における作用を説明する。以下の説明において、機能の主体である車載装置２を搭載する車両を［自車］と称する。また、自車以外の車両を［他車］と称する。先ず、走行情報算出部２４ｉについて説明する。
次に、上記構成における作用を説明する。以下の説明において、機能の主体である車載装置２を搭載する車両を［自車］と称する。また、自車以外の車両を［他車］と称する。先ず、走行情報算出部２４ｉについて説明する。
【0030】
＜走行情報算出部２４ｉについて＞
図５は、走行情報算出部２４ｉの機能を説明するためのフローチャートである。走行情報算出部２４ｉは、ＧＰＳ受信部２４ｊから自車の位置情報を定期的に取得し（ステップＳ９１）、タイムスタンプを付与する（ステップＳ９２）。次に走行情報算出部２４ｉは、自車位置情報の前回の値を自車走行情報記憶部２５ｆから読み出し（ステップＳ９３）、今回取得した位置情報と比較する。そして、位置情報の時間に対する変化に基づいて、自車の速度と移動方向とを算出する（ステップＳ９４）。次に走行情報算出部２４ｉは、得られた結果にタイムスタンプを付与し、［自車走行情報］として、自車走行情報記憶部２５ｆにサイクリックに保存する（ステップＳ９５）。つまり、古い情報を消去して、新しい情報を保存することにより、新しい情報から順に一定数の情報を保存する。以上の手順は、処理ループ（ＬＯＯＰ）内で繰り返される。
図５は、走行情報算出部２４ｉの機能を説明するためのフローチャートである。走行情報算出部２４ｉは、ＧＰＳ受信部２４ｊから自車の位置情報を定期的に取得し（ステップＳ９１）、タイムスタンプを付与する（ステップＳ９２）。次に走行情報算出部２４ｉは、自車位置情報の前回の値を自車走行情報記憶部２５ｆから読み出し（ステップＳ９３）、今回取得した位置情報と比較する。そして、位置情報の時間に対する変化に基づいて、自車の速度と移動方向とを算出する（ステップＳ９４）。次に走行情報算出部２４ｉは、得られた結果にタイムスタンプを付与し、［自車走行情報］として、自車走行情報記憶部２５ｆにサイクリックに保存する（ステップＳ９５）。つまり、古い情報を消去して、新しい情報を保存することにより、新しい情報から順に一定数の情報を保存する。以上の手順は、処理ループ（ＬＯＯＰ）内で繰り返される。
【0031】
サイクリックに保存した［自車走行情報］の履歴情報は、図４に示されるメッセージデータに挿入され、車車間で相互に情報交換される。自車の走行情報は、他車により受信され、受信先の車両では［他車走行情報］としてサイクリックに記録され、［他車走行情報］の履歴情報となる。当然、自車においても、他車から受信する情報には全て情報発信車の［自車走行情報］が付与されているので、様々な車からの［他車走行情報］を集め、記憶することができる。
【0032】
こうした走行情報の集合体は付近の交通の状況を示す情報となり得る。例えば、以下のような付加価値情報を取り出し提供すことが可能である。しかも、これらの情報は自律分散的に収集・提供することが可能であり、交通管制センターシステムのような全体を管理するシステムを必要としないという、大きな利点になる。
【0033】
（１）道路毎・車線毎・時間帯毎の平均走行速度と速度の分散
（２）自車を中心とする前方向の車列の長さ、後ろ方向の車列の長さ
（３）付近の渋滞状況
（４）事故発生時の付近の車の動きの証拠データ
（５）不合理な交通違反摘発時の反論データ
（６）適切な制限速度見直しのための基礎データ提供
こうした付加価値情報は＜普及の壁＞を超えるための強力な推進力となり得る。
（２）自車を中心とする前方向の車列の長さ、後ろ方向の車列の長さ
（３）付近の渋滞状況
（４）事故発生時の付近の車の動きの証拠データ
（５）不合理な交通違反摘発時の反論データ
（６）適切な制限速度見直しのための基礎データ提供
こうした付加価値情報は＜普及の壁＞を超えるための強力な推進力となり得る。
【0034】
＜受信部２４ｇについて＞
図６は、受信部２４ｇの機能を説明するためのフローチャートである。受信部２４ｇは、車車間通信で授受されるメッセージデータを取得し、必要な情報を記憶するとともに、必要なアクションを実行する。
図６は、受信部２４ｇの機能を説明するためのフローチャートである。受信部２４ｇは、車車間通信で授受されるメッセージデータを取得し、必要な情報を記憶するとともに、必要なアクションを実行する。
【0035】
図６の処理ループの中で、受信部２４ｇは、他車からの受信データ（メッセージデータ）の到来を待ち受ける（ステップＳ１）。メッセージデータが到来すると（ＹＥＳ）、受信部２４ｇは、受信したメッセージデータから、図４に示される［自車走行情報］、［他車走行情報］、［通信相手コード］、［コマンドコード］、あるいは［リツイートフラグ］等の各種の情報を抽出する。
【0036】
次に、［自車走行情報］の抽出に成功すれば、つまりメッセージデータに［自車走行情報］が有れば（ステップＳ２：ＹＥＳ）、受信部２４ｇは、他車走行情報記憶部２５ｇにその内容を記録する（ステップＳ３）。また、メッセージデータに［他車走行情報］が有れば（ステップＳ４：ＹＥＳ）、受信部２４ｇは、その内容を他車走行情報記憶部２５ｇに記録する（ステップＳ５）。つまり自車にとっては、［他車の自車走行情報］、および［他車の他車走行情報］のいずれも他車走行情報である。
【0037】
次に受信部２４ｇは、メッセージデータの［リツイートフラグ］が０ホップ目を示す値（０）であるか否かを判定し（ステップＳ６）、ＹＥＳであれば、受信したメッセージデータを転送部２４ｄに送って１ホップだけ転送させる（ステップＳ７）。転送されるメッセージデータの［リツイートフラグ］には、１ホップ目を示す値が記載される。
【0038】
ステップＳ６でＮＯならば、受信部２４ｇは、受信したメッセージデータに記載されたコマンドがリツイート対象であるか否かを判定する（ステップＳ８）。ＮＯならば、受信部２４ｇは、メッセージデータを相対位置算出部２４ｆに送り、送信元他車の相対位置を算出させる（ステップＳ１１）。ステップＳ８でＹＥＳならば、受信部２４ｇは、［リツイートフラグ］に（リツイート済み）を示す値（２）が記載されているか否かを判定する（ステップＳ９）。ＮＯであれば、受信部２４ｇは、メッセージデータをリツイート部２４ｃに送り、さらに１ホップだけ転送（リツイート）させる（ステップＳ１０）。ステップＳ９でＹＥＳならば、受信部２４ｇは、メッセージデータを相対位置算出部２４ｆに送り、送信元他車の相対位置を算出させる（ステップＳ１１）。以上の手順は、処理ループ（ＬＯＯＰ）内で繰り返される。
【0039】
＜転送部２４ｄについて＞
図７は、転送部２４ｄの機能を説明するためのフローチャートである。図７の処理ループの中で、転送部２４ｄは、メッセージデータの到来を待ち受け（ステップＳ２１）、メッセージデータが到来すると（ＹＥＳ）、転送部２４ｄは、受信したメッセージデータの［リツイートフラグ］に１ホップ目を示す値（１）をセットする。そのうえで転送部２４ｄは、メッセージデータを送信部２４ｂに送り（ステップＳ２３）、他車に向けて１ホップだけ送信させる。以上の手順は、処理ループ（ＬＯＯＰ）内で繰り返される。
図７は、転送部２４ｄの機能を説明するためのフローチャートである。図７の処理ループの中で、転送部２４ｄは、メッセージデータの到来を待ち受け（ステップＳ２１）、メッセージデータが到来すると（ＹＥＳ）、転送部２４ｄは、受信したメッセージデータの［リツイートフラグ］に１ホップ目を示す値（１）をセットする。そのうえで転送部２４ｄは、メッセージデータを送信部２４ｂに送り（ステップＳ２３）、他車に向けて１ホップだけ送信させる。以上の手順は、処理ループ（ＬＯＯＰ）内で繰り返される。
【0040】
転送を１ホップだけに限定することにより以下の効果を得られる。つまり、２ホップ以上の多数の転送を繰り返したときに生じる以下のような不具合を、回避することができる。
（ａ）転送を複数回にわたって繰り返すと、転送の無限ループが発生する。このような状況下では転送データが爆発的に増加してしまい、いわゆるブロードキャストストームが生じて実用的な通信が行えなくなる。
（ｂ）転送の無限ループを生じないケースであっても、転送に参加する通信ノード（車）が指数関数的に増大するケースがあり、それらの通信ノード（車）の極一部しか転送情報を必要としないケースを生じうる。つまり、本来必要としない情報の転送にＣＰＵ資源や無線の電波資源を浪費してしまうケースを生じる。
（ｃ）現時点で、日本国内のスマートメータ間のマルチホップ通信方式は統一されていない。このため、全国規模での車車間通信に、そのまま適用することができない。
（ａ）転送を複数回にわたって繰り返すと、転送の無限ループが発生する。このような状況下では転送データが爆発的に増加してしまい、いわゆるブロードキャストストームが生じて実用的な通信が行えなくなる。
（ｂ）転送の無限ループを生じないケースであっても、転送に参加する通信ノード（車）が指数関数的に増大するケースがあり、それらの通信ノード（車）の極一部しか転送情報を必要としないケースを生じうる。つまり、本来必要としない情報の転送にＣＰＵ資源や無線の電波資源を浪費してしまうケースを生じる。
（ｃ）現時点で、日本国内のスマートメータ間のマルチホップ通信方式は統一されていない。このため、全国規模での車車間通信に、そのまま適用することができない。
【0041】
（ａ）～（ｃ）のような不具合に対し、転送ホップ数を１ホップだけに限ることで、極めて容易かつシンプルにシステムを実装できる。いわゆる「ポン付け」が可能な、シンプルで安価な車載装置を容易に実現でき、＜普及の壁＞を超えることへの後押しになる。
【0042】
なお、２ホップだけの転送としても上記のコンセプトは大きくは変わらない。１ホップよりも２ホップのほうが広範囲の通信が可能となるが、１ホップだけの場合と比較すると、上記（ａ）、（ｂ）の可能性が高まるというトレードオフの関係がある。しかし、１ホップだけの転送では、データの到達可能距離が限定されてしまい、広域に渡る通信を実現することはできない。そこで実施形態では、リツイート部２４ｃを設けることで、広域に渡る通信を実現する。つまり実施形態ではシンプルさを優先し、１ホップだけの転送を採用するとともに、運転手の意思に応じて情報を拡散できるようにするために、”リツイート”という処理を適用する。
【0043】
＜リツイート部２４ｃについて＞
図８は、リツイート部２４ｃの機能を説明するためのフローチャートである。リツイート部２４ｃは、受信部２４ｇからメッセージデータが送られると（ステップＳ３１：ＹＥＳ）、バッファメモリ（図示せず）などにメッセージデータを一時的に記憶し（ステップＳ３２）、音声合成部２４ｅにメッセージデータを送った（ステップＳ３３）のちにステップＳ３４の手順を実行する。なお受信データが無ければ（ステップＳ３１：ＮＯ）、そのままステップＳ３４に至る。
図８は、リツイート部２４ｃの機能を説明するためのフローチャートである。リツイート部２４ｃは、受信部２４ｇからメッセージデータが送られると（ステップＳ３１：ＹＥＳ）、バッファメモリ（図示せず）などにメッセージデータを一時的に記憶し（ステップＳ３２）、音声合成部２４ｅにメッセージデータを送った（ステップＳ３３）のちにステップＳ３４の手順を実行する。なお受信データが無ければ（ステップＳ３１：ＮＯ）、そのままステップＳ３４に至る。
【0044】
ステップＳ３４において、リツイート部２４ｃは、音声認識部２４ａの認識結果を取得し、認識結果が”リツイート”であるか否かを判定する（ステップＳ３４）。このステップを設けることで、自車の運転手の意思に応じて、メッセージデータを他車に転送する（つまりリツイートする）か否かが決定される。
【0045】
ステップＳ３４でＹＥＳであれば、リツイート部２４ｃは、ステップＳ３２でバッファされたメッセージデータを送信部２４ｂに送り、不特定多数の他車（無線ゾーン内の車両）に向けて送信する（ステップＳ３５）。すなわち、運転手からのリツイートの意思表示があると、リツイート部２４ｃは、他車から受け渡されたメッセージデータを送信部２４ｂに渡して、さらに別の車両へと送信させる。以上の手順は、処理ループ（ＬＯＯＰ）内で繰り返される。
【0046】
このような処理手順により、運転手にとって真に必要な情報を、広範囲に迅速に拡散することが可能である。また、ＳＮＳ（Social Networking Service）の文化を取り入れることができ、特に若年層の強力な牽引力に期待できるとともに、＜普及の壁＞を超えることへの後押しにもなる。
【0047】
＜送信部２４ｂについて＞
図９は、送信部２４ｂの機能を説明するためのフローチャートである。送信部２４ｂは、転送部２４ｄ、音声認識部２４ａ、または、リツイート部２４ｃからのデータ送信要求を受けるとメッセージデータを作成し、他車に送信する。
図９に示されるように、送信部２４ｂの処理手順は、ループの中に３つの判断ブロック（ステップＳ４１、Ｓ４３、Ｓ４８）を備える。ステップＳ４１において、送信部２４ｂは、転送部２４ｄからの送信要求を待ち受ける。また、ステップＳ４３において、送信部２４ｂは、音声認識部２４ａからの送信要求を待ち受ける。また、ステップＳ４８において、送信部２４ｂは、リツイート部２４ｃからの送信要求を待ち受ける。いずれかのステップで送信要求がキャッチされると、プロセスは、各ステップに応じた処理へとジャンプする。
図９は、送信部２４ｂの機能を説明するためのフローチャートである。送信部２４ｂは、転送部２４ｄ、音声認識部２４ａ、または、リツイート部２４ｃからのデータ送信要求を受けるとメッセージデータを作成し、他車に送信する。
図９に示されるように、送信部２４ｂの処理手順は、ループの中に３つの判断ブロック（ステップＳ４１、Ｓ４３、Ｓ４８）を備える。ステップＳ４１において、送信部２４ｂは、転送部２４ｄからの送信要求を待ち受ける。また、ステップＳ４３において、送信部２４ｂは、音声認識部２４ａからの送信要求を待ち受ける。また、ステップＳ４８において、送信部２４ｂは、リツイート部２４ｃからの送信要求を待ち受ける。いずれかのステップで送信要求がキャッチされると、プロセスは、各ステップに応じた処理へとジャンプする。
【0048】
ステップＳ４１で転送部２４ｄからの送信要求があれば（ＹＥＳ）、送信部２４ｂは、スマートメータ通信基盤１００にデータの送信を要求する（ステップＳ４２）。
ステップＳ４３で音声認識部２４ａからの送信要求があれば（ＹＥＳ）、送信部２４ｂは、自車走行情報記憶部２５ｆから自車走行情報を読み出し（ステップＳ４４）、他車走行情報記憶部２５ｇから他車走行情報を読み出して（ステップＳ４５）、送信すべきメッセージデータを作成する（ステップＳ４６）。そして、送信部２４ｂは、このメッセージデータの送信をスマートメータ通信基盤１００に要求する（ステップＳ４７）。
ステップＳ４３で音声認識部２４ａからの送信要求があれば（ＹＥＳ）、送信部２４ｂは、自車走行情報記憶部２５ｆから自車走行情報を読み出し（ステップＳ４４）、他車走行情報記憶部２５ｇから他車走行情報を読み出して（ステップＳ４５）、送信すべきメッセージデータを作成する（ステップＳ４６）。そして、送信部２４ｂは、このメッセージデータの送信をスマートメータ通信基盤１００に要求する（ステップＳ４７）。
【0049】
ステップＳ４８でリツイート部２４ｃからの送信要求があれば（ＹＥＳ）、送信部２４ｂは、リツイートフラグをセットした（つまり、１にした）メッセージデータを作成し（ステップＳ４９）、このメッセージデータの送信をスマートメータ通信基盤１００に要求する（ステップＳ５０）。
【0050】
＜相対位置算出部２４ｆについて＞
図１０は、相対位置算出部２４ｆの機能を説明するためのフローチャートである。処理ループの中で、相対位置算出部２４ｆは、他車からのメッセージデータの到来を待ち受ける（ステップＳ６１）。メッセージデータが到来すると（ＹＥＳ）、相対位置算出部２４ｆは、受信したメッセージデータから、図４に示される［自車走行情報］を読み出し、発信車の位置、速度、および向きを取得する（ステップＳ６２）。
図１０は、相対位置算出部２４ｆの機能を説明するためのフローチャートである。処理ループの中で、相対位置算出部２４ｆは、他車からのメッセージデータの到来を待ち受ける（ステップＳ６１）。メッセージデータが到来すると（ＹＥＳ）、相対位置算出部２４ｆは、受信したメッセージデータから、図４に示される［自車走行情報］を読み出し、発信車の位置、速度、および向きを取得する（ステップＳ６２）。
【0051】
次に相対位置算出部２４ｆは、自車走行情報記憶部２５ｆから自車の位置、速度、および向きを取得する（ステップＳ６３）。ここまでで自車および他車の、位置、速度、および方向が取得されると、相対位置算出部２４ｆはこれらの情報から、自車と、メッセージデータを送信した通信相手の車両との相対的な位置関係、相対速度、および、相対的な移動方向を算出する（ステップＳ６４）。
【0052】
次に、相対位置算出部２４ｆは、受信したメッセージデータの通信相手コード（図４：５番目のフィールド）に記載された発信者の位置と、上記算出された相対的な位置関係とが合致しているか否かを判定する（ステップＳ６５）。両者が合致していれば（ＹＥＳ）、相対位置算出部２４ｆは、このメッセージデータが自車向けに送信されたデータであると判定する。そして相対位置算出部２４ｆは、メッセージデータと、このメッセージデータから取得された各種情報を音声合成部２４ｅに送る（ステップＳ６６）。以上の手順は、処理ループ（ＬＯＯＰ）内で繰り返される。
【0053】
図１１は、通信相手コードと、相対的な位置関係との対応の一例を示す図である。メッセージデータの送信者から見た受信者との位置関係が、例えば［全て］、［前方の全て］、［後方の全て］、…、［左後ろ］、［左後方］というように詳細に区別され、各位置ごとに、通信相手コードが予め対応付けられる。相対位置算出部２４ｆから送られた情報に基づき、音声合成部２４ｅは、自車を中心とする相対位置とメッセージデータのコマンド内容を音声で表現し、自車の運転手に伝える。
【0054】
＜音声認識部２４ａについて＞
図１２は、音声認識部２４ａの機能を説明するためのフローチャートである。音声認識部２４ａは、自車の運転手が発した音声データをマイク５（図１）から取得し、音声認識を行う。音声認識については非特許文献１，２に示されるような、既存の技術を適用することができる。
図１２は、音声認識部２４ａの機能を説明するためのフローチャートである。音声認識部２４ａは、自車の運転手が発した音声データをマイク５（図１）から取得し、音声認識を行う。音声認識については非特許文献１，２に示されるような、既存の技術を適用することができる。
【0055】
図１２のループにおいて、音声認識部２４ａは、マイク５から取得された音声に、通信相手を指定するためのキーワードが或るか否かを判定する（ステップＳ８１）。ここで、実施形態では、キーワードを確実に識別できるようにするため、音声コマンドの形式を予め固定化して取り扱うようにする。
【0056】
図１３は、音声コマンドのフォーマットの一例を示す図である。音声コマンドは、『会話相手を指定するキーワード』、および『コマンド』の２つのフィールドを含む。音声コマンドのフォーマットを定型化しておくことで、様々な音声や雑音が飛び交う社内の音データの中から、適切な通信相手と適切なコマンドを抜き出すことが可能になる。
【0057】
図１４は、会話相手を指定するためのキーワードと符号化列の一例を示す図である。例えば、自車から見て『すべて』、『ぜんぽうのすべて』、『こうほうのすべて』、…、等のキーワードに、各キーワードを識別するための符号『０』、『１』、『２』、…、が対応付けられる。この情報は、キーワード保存部２５ａ（図３）に予め記憶される。
【0058】
図１５は、音声コマンドと符号化列の一例を示す図である。コマンドは、例えば『謝意』、『返答』、『促し』、『方向』、…などの複数のカテゴリごとに、共通の符号『１』、『２』、『１１』、『１２』…が対応付けられた情報である。この情報は、コマンド定義データ保存部２５ｅ（図３）に予め記憶される。
【0059】
例えば『謝意』のカテゴリには「ありがとう」、「どうも」、「さんきゅー」、…等の、いずれも謝意を表す言葉が対応付けられていて、これらのうちいずれかのコマンドが認識された場合には、共通のコード『１』にコード化される。このコマンドコード『１』を受けた側では、謝意を表す音声が合成出力される。
【0060】
図１２に戻って説明を続ける。音声の中に通信相手を指定するキーワードを見つけると（ステップＳ８１：ＹＥＳ）、音声認識部２４ａは、当該キーワードに対応する、通信相手を識別するコード（通信相手コード）をキーワード保存部２５ａから読み出す（ステップＳ８２）。次に音声認識部２４ａは、通信相手識別コードに続く音声がコマンドであるか否かを判定し（ステップＳ８３）、ＹＥＳであれば、コマンドの識別コード（コマンドコード）をコマンド定義データ保存部２５ｅから読み出す。
【0061】
そして、音声認識部２４ａは、読み出した通信相手コードとコマンドコードとを送信部２４ｂに通知し、両コードを含むデータメッセージの送信を要求する（ステップＳ８５）。通信相手コードおよびコマンドコードは、図４に示されるフォーマットの各フィールドに格納される。以上の手順は、処理ループ（ＬＯＯＰ）内で繰り返される。
【0062】
例えば、自車の運転手が、直後を走行中の車に向けて「先に行ってください」というメッセージを送信したくなったとする。この場合には、運転手は「こうぞくしゃ さきにいってください」と２つのフレーズからなる音声を発すれば、音声認識部２４ａにより、通信の相手先が［後続車］であること、および、伝えたいメッセージが「先に行ってください」であることが識別される。このようにして、運転手の意思を反映したメッセージデータが自車から送信されることになる。
【0063】
＜音声合成部２４ｅについて＞
次に、音声合成部２４ｅについて説明する。実施形態において、音声合成部２４ｅは、大きく３つの機能を有する。すなわち、受信したコマンドの意味を自車の運転手に伝える機能と、メッセージの送出元である相手位置を自車の運転手に伝える機能と、擬人化された音声を合成する機能とである。音声合成部２４ｅにより合成出力される音声は、例えば図１６に示されるように、大きく２つのパートを含む。
次に、音声合成部２４ｅについて説明する。実施形態において、音声合成部２４ｅは、大きく３つの機能を有する。すなわち、受信したコマンドの意味を自車の運転手に伝える機能と、メッセージの送出元である相手位置を自車の運転手に伝える機能と、擬人化された音声を合成する機能とである。音声合成部２４ｅにより合成出力される音声は、例えば図１６に示されるように、大きく２つのパートを含む。
【0064】
図１６は、音声合成部２４ｅにより合成出力される音声を示す概念図である。自車内で拡声出力される音声メッセージは、受信相手を指定するための［キーワード部］と、音声コマンドの意味を表現するための［フレーズ部］とを有する。
【0065】
図１７は、音声合成部２４ｅの機能を説明するためのフローチャートである。図１７の処理ループにおいて、音声合成部２４ｅは他車から受信されたメッセージデータの有無を判定し（ステップＳ７１）、メッセージデータがあれば（ＹＥＳ）、音声合成部２４ｅは、当該受信されたメッセージデータに含まれるコマンドコードを取り出す（ステップＳ７２）。
【0066】
次に音声合成部２４ｅは、取得したコマンドコードに対応する音声フレーズ発生用文字列を、コマンド定義データ保存部２５ｅから取得する（ステップＳ７３）。ステップＳ７２で例えばコマンドコード『１』が抽出されていれば、そのメッセージは『謝意』を表しているので、対応する『ありがとう』といった文字列が取得される。
【0067】
図１８は、音声フレーズ発生用文字列とコマンドコードとの対応の一例を示す図である。この情報はコマンド定義データ保存部２５ｅに予め保存される。図１８に示されるように、各コマンドコードに対して、予め決められたパターンの文字列が割り当てられる。つまり発信車でどのような音声が発せられたとしても、その受け手である受信車では特定のパターンの音声しか発生されない。このようにすることで、誹謗中傷的なメッセージや煽りを助長するようなメッセージ交換を防止することができる。また、受信したコマンドの意味を自車の運転手に伝える機能が実現される
図１７において、次に音声合成部２４ｅは、受信したメッセージデータから発信車種別を読み出す（ステップＳ７４）。発信車種別を示す情報は、図４に示されるようにメッセージデータの８番目のフィールドに記載されている。次に音声合成部２４ｅは、発信車種別に対応する声質定義データを、車種毎声質定義データ保存部２５ｃから読み出す（ステップＳ７５）。
図１７において、次に音声合成部２４ｅは、受信したメッセージデータから発信車種別を読み出す（ステップＳ７４）。発信車種別を示す情報は、図４に示されるようにメッセージデータの８番目のフィールドに記載されている。次に音声合成部２４ｅは、発信車種別に対応する声質定義データを、車種毎声質定義データ保存部２５ｃから読み出す（ステップＳ７５）。
【0068】
図１９は、車種毎に定義された声質データの一例を示す図である。例えば大型トラックに対しては、［高さ］が（低い）、［かすれ］が（大）、［高調波］が（小）、…、というような情報が予め定義される。
【0069】
図２０は、車両の色毎に定義された声質データの一例を示す図である。例えば赤系の色には、［高さ］が（高い）、［かすれ］が（なし）、［高調波］が（小）、…、というような、若者をイメージさせる情報が予め定義される。
【0070】
車両の運転手は走行中、相手の車の車種と色によって、運転手のおおまかなイメージを判断している。例えば、黒の大型トラックを見れば、大柄で太い声をした男性の運転手をイメージするであろうし、ピンクの軽自動車を見れば、細い声をした小柄な女性の運転手をイメージするであろう。
【0071】
そこで、車載装置２に自車の車種と外形色を登録しておき、これらの情報を車車間通信の発信車属性情報として送信する。これを受けた受信側では、車種と外形色に応じた印象の音声を音声合成することにより、通信の発信車を特定することをサポートできるようになる。
【0072】
例えば、自車の周りにピンクの軽自動車が１台だけ走行している最中に、細い女性の声質でメッセージが流れれば、運転手は、その軽自動車からのメッセージであることを容易に認識することができる。
【0073】
図１７に戻って説明を続ける。次に音声合成部２４ｅは、受信したメッセージデータの９番目のフィールド（図４）から運転手属性を読み出す（ステップＳ７６）。次に音声合成部２４ｅは、運転手属性に対応する声質定義データを、運転手属性毎声質定義データ保存部２５ｄから読み出す（ステップＳ７７）。
【0074】
図２１は、運転歴に対して定義された声質データの一例を示す図である。例えばベテランの運転手については、［高さ］が（中）、［かすれ］が（なし）、［高調波］が（小）、…、というような、落ち着きを感じさせる情報が予め定義される。
【0075】
最後に音声合成部２４ｅは、音声発生用文字列を、読み出された声質定義データの組み合わせに従って音声合成することで（ステップＳ７８）、発信車をいわば＜擬人化＞する。以上の手順は、処理ループ（ＬＯＯＰ）内で繰り返される。
【0076】
＜受信相手位置を伝える機能について＞
受信相手位置を伝える機能について説明する。音声合成部２４ｅは、相対位置算出部２４ｆから送られた、自車と受信相手車の相対的な位置情報から受信相手を指定するキーワード（図１４）を合成出力する。これにより自車の運転手に、相手車の相対的な位置を的確に伝えることができる。
受信相手位置を伝える機能について説明する。音声合成部２４ｅは、相対位置算出部２４ｆから送られた、自車と受信相手車の相対的な位置情報から受信相手を指定するキーワード（図１４）を合成出力する。これにより自車の運転手に、相手車の相対的な位置を的確に伝えることができる。
【0077】
図２２は、自車と相手車との相対位置を表現するキーワードの一例を示す図である。例えば自車との相対位置が直前、または前方の車両に対し、『前のくるま』といった、相手を指定するキーワードが対応付けられる。なお、キーワードは図２２に示される用語に限定されるものではない。音声として聞いた場合に、自車と相手車の位置関係が連想できるようなキーワードであればどのような用語でも良い。
【0078】
さらに、音声合成部２４ｅは、自車の乗車空間に、３次元的な音場を形成する。すなわち、音声合成部２４ｅは、通信相手と自車との相対位置関係に基づいて、運転手から見た通信相手の位置に対応した位置に３次元的な音像を合成する。これにより、運転手が通信相手を特定することをサポートすることができる。
【0079】
例えば、後方を走行中の車から受信したメッセージについては、運転手の後方に音像を定位させることによって、後方の車両からのメッセージであることを、運転手に容易に認識させることが可能になる。前方や側方も同様である。
【0080】
さらに、通信相手の速度と移動方向に基づいて、３次元的な音像を合成する際に、通信相手の動きに応じて時間的な音像位置の変化とドップラー効果を持たせるようにしても良い。つまり通信相手の相対速度および相対的な移動方向を反映すべく、音像の位置およびピッチを変化させるようにしてもよい。このようにすることで、運転手にとっては、通信相手を特定することがさらに容易になる。
【0081】
例えば、対向車線を走行中の車からのメッセージは、右前方から右後方へドップラー効果を伴いながら移動する音像として音声合成することによって、対向車からのメッセージであることを容易に運転手に認識させることが可能である。
【0082】
＜擬人化された音声を合成する機能について＞
擬人化は、例えば音声合成のための音質をパラメータ化し、調整可能とする機能を音声合成部２４ｅに実装することで、実現可能である。擬人化により、運転手が通信相手を特定することを、別の側面からサポートすることができる。
擬人化は、例えば音声合成のための音質をパラメータ化し、調整可能とする機能を音声合成部２４ｅに実装することで、実現可能である。擬人化により、運転手が通信相手を特定することを、別の側面からサポートすることができる。
【0083】
なお、実施形態における擬人化とは、音声合成に用いる声質を制御することで、音声に仮想的な人格を持たせることを意味する。非特許文献１に示されるように、近年の音声合成の技術の進展により幅広い年代・性別の話者を選んで音声データを作成したり、喜・怒・哀・楽の感情の組合せ、声の抑揚や速さなどを調整することで、表現力豊かな音声を合成することが可能になってきている。あるいは非特許文献２に記載のように、特定の人の声データを元に音声を合成することも可能になっている。擬人化を用いたコミュケーションを反復的に実施することで、運転手には音声の音質だけから通信相手を特定することが可能となり、「いつものあの人だな」と認識することが可能となる。
【0084】
＜運転手属性による擬人化＞
運転手属性による擬人化について詳しく説明する。例えば以下の３つの運転手属性を考える。
（１）運転経歴
（２）性別・年代
（３）出身県
＜運転経歴に応じた擬人化＞
運転手は走行中、相手の運転手の運転経験に応じて意識を変えながら運転している。例えば、初心者や高齢者が走行中の場合、車間距離を採ったり、スムーズな車線移動を意識したりしている。
そこで、車載装置２を初期設定する際、自車の運転手の運転歴を登録しておき、運転歴を運転手属性情報として車両間で授受し合う。メッセージデータを受信した車両では、通信相手の運転手の運転歴に応じた印象の音色で音声を合成することにより、通信の発信車の運転歴を特定することをサポートすることができる。例えば、ベテラン運転手はしっとりとした落ち着いた音声、初心者はおどおどしたうわずった印象の音声で音声合成することで、発信車の運転歴を表現することができる。図２１の定義データはこのような属性を反映している。なお、例えば１か月の走行距離に応じて、初心者、中級者、上級者と運転レベル分けし、それに応じた声質を用いることも考えられる。
運転手属性による擬人化について詳しく説明する。例えば以下の３つの運転手属性を考える。
（１）運転経歴
（２）性別・年代
（３）出身県
＜運転経歴に応じた擬人化＞
運転手は走行中、相手の運転手の運転経験に応じて意識を変えながら運転している。例えば、初心者や高齢者が走行中の場合、車間距離を採ったり、スムーズな車線移動を意識したりしている。
そこで、車載装置２を初期設定する際、自車の運転手の運転歴を登録しておき、運転歴を運転手属性情報として車両間で授受し合う。メッセージデータを受信した車両では、通信相手の運転手の運転歴に応じた印象の音色で音声を合成することにより、通信の発信車の運転歴を特定することをサポートすることができる。例えば、ベテラン運転手はしっとりとした落ち着いた音声、初心者はおどおどしたうわずった印象の音声で音声合成することで、発信車の運転歴を表現することができる。図２１の定義データはこのような属性を反映している。なお、例えば１か月の走行距離に応じて、初心者、中級者、上級者と運転レベル分けし、それに応じた声質を用いることも考えられる。
【0085】
実際の運転シーンの例では、自車の周りに初心者マークを張った車が１台だけ走行している最中に、おどおどしたうわずった印象の音声でメッセージが流れれば、運転手は、その初心者の車からのメッセージであることを容易に認識することが可能である。
【0086】
＜性別・年代に応じた擬人化＞
運転手は走行中、相手の運転手の性別や年代に応じて意識を変えながら運転している。例えば、女性の中高年の運転手が周囲の流れよりも著しく遅い速度で走行していても、「仕方ないな・・・」と思って運転している。あるいは、若い男性がスポーツ車両で周囲の流れよりも早い速度で走行していても、「仕方ないな、近寄らないようにしよう・・・」と思って運転したりする。このような情報は運転のイライラを防止するために効果的な情報となり得るもので、交通事故発生のリスクを低減させる効果をもたらす。
運転手は走行中、相手の運転手の性別や年代に応じて意識を変えながら運転している。例えば、女性の中高年の運転手が周囲の流れよりも著しく遅い速度で走行していても、「仕方ないな・・・」と思って運転している。あるいは、若い男性がスポーツ車両で周囲の流れよりも早い速度で走行していても、「仕方ないな、近寄らないようにしよう・・・」と思って運転したりする。このような情報は運転のイライラを防止するために効果的な情報となり得るもので、交通事故発生のリスクを低減させる効果をもたらす。
【0087】
そこで、車載装置２を初期設定する際、自車の運転手の性別と年代を登録しておき、車車間通信の運転手属性情報として、その情報を送信する。これを受信した車両では、通信相手の運転手の性別と年代に応じた印象の音色で音声合成することにより、運転相手に応じた運転をサポートすることができる。例えば、若い女性の運転手は細い高い声質、初老の男性は、落ちついたダンディーな印象の声質で音声合成することにより、発信車の性別と世代を表現することができる。
【0088】
＜出身県に応じた擬人化＞
運転手は走行中、相手の車のナンバーから判る出身県に応じて意識を変えながら運転していることがある。例えば、県外ナンバーの車は予測不能な不規則な動きをする可能性がある、あるいは、経験則に基づいて、特定県の運転手は運転が荒い、などである。
運転手は走行中、相手の車のナンバーから判る出身県に応じて意識を変えながら運転していることがある。例えば、県外ナンバーの車は予測不能な不規則な動きをする可能性がある、あるいは、経験則に基づいて、特定県の運転手は運転が荒い、などである。
【0089】
そこで、車載装置２を初期設定する際、自車の登録県を登録しておき、車車間通信の運転手属性情報として、その情報を送信する。メッセージデータを受信した車両では、通信相手の登録県に応じた（有名な）方言を用いた音色で音声合成することにより、運転相手に応じた運転を行う事をサポートすることができる。また、そうした通信を反復して繰り返すことにより、運転手同士に「いつものあの人だな」と判らせることが可能となる。
【0090】
方言の切り替えは、コマンドに対応した音声合成用のメッセージデータを県ごとに準備しておくことにより、容易に切り替えることが可能である。
【0091】
図２３は、広島県の方言用音声メッセージデータの一例を示す図である。図１８に示される標準語の音声フレーズ発生用文字列に対して、広島弁の特徴が浮き出た表現となっている。
図２４は、大阪府の方言用音声メッセージデータの一例を示す図である。関西弁の特徴がよくわかる表現になっている。なお、方言を適用すべき地方の情報は、車両のナンバープレートからも或る程度推測できる。
図２４は、大阪府の方言用音声メッセージデータの一例を示す図である。関西弁の特徴がよくわかる表現になっている。なお、方言を適用すべき地方の情報は、車両のナンバープレートからも或る程度推測できる。
【0092】
擬人化により、例えば以下のような効果を得ることができる。
【0093】
（１）運転手に通信相手を識別することを容易にさせる。
（２）運転手間の相互認識が向上し、相互の思いやりにより事故低減につながる。
（３）運転手間の相互理解が深まるので、イライラ低減により事故低減につながる。
（４）親しみが得られるので＜普及の壁＞を超える助けとなる。
このように、擬人化により運転手間の意思の疎通をサポートすることができる。
（２）運転手間の相互認識が向上し、相互の思いやりにより事故低減につながる。
（３）運転手間の相互理解が深まるので、イライラ低減により事故低減につながる。
（４）親しみが得られるので＜普及の壁＞を超える助けとなる。
このように、擬人化により運転手間の意思の疎通をサポートすることができる。
【0094】
＜効果＞
以上述べたように実施形態によれば、車車間通信でメッセージデータを授受し合うことにより、車車間通信システムの普及を、多様な側面から促進することが可能になる。しかもセンター装置を特に必要とせず、複数の車両間での自律分散的な処理により、車両間の情報共有を促すことができる。
以上述べたように実施形態によれば、車車間通信でメッセージデータを授受し合うことにより、車車間通信システムの普及を、多様な側面から促進することが可能になる。しかもセンター装置を特に必要とせず、複数の車両間での自律分散的な処理により、車両間の情報共有を促すことができる。
【0095】
また、転送のホップ数を１ホップに留めているので、ブロードキャストストームのような通信の輻そうのおそれがない。これに加えて、リツイートという処理を設けることで、重要な情報については１ホップでなく、２ホップ、３ホップ、…というように拡散させることができ、情報伝達に際して運転手の意思を反映させることができる。
【0096】
１ホップ転送、リツイート機能のいずれも、ソフトウェアによるアプリケーションレイヤとして実装することで、車載装置２の装置規模を縮小していわゆる「ポン付け」タイプの車載装置として実現することができる。スマートメータ通信基盤１００を利用することで、通信機能をさらに簡略化でき、小型軽量化をさらに促進できる。
【0097】
さらに、４チャンネルのスピーカを用いて立体的な音像を形成し、音像の定位する位置を制御したり、自在に動かしたりすることで、通信相手の車両を把握することが容易になる。
【0098】
このほか実施形態によれば、［自車走行情報］、［他車走行情報］として各車両の位置情報、移動速度、移動方向等の情報が授受されるので、交通情報を局所的に共有できる環境を形成することができる。
【0099】
さらに、［自車走行情報］、［他車走行情報］を利用し、その履歴を管理することで、例えば走行車線の走行速度の平均値や分散等の、統計的な情報を求めることも可能になる。このような情報に基づき、例えば自車の前後の車列数を算出して、自車の速度と走行中車線の平均速度の差が規定値を下回っている、且つ、自車の後ろに規定数の車列がある、且つ、自動車が先頭を走っているという条件が成立した場合に、運転手に渋滞警告のアラームを通知する、などのアプリケーションも考えらえる。
【0100】
このほか、車線毎の平均車速情報、自車の前後の車列数、交通事故発生時の目撃車データを収集するための手段、あるいは、交通事故発生時の周辺車の動きを含めた俯瞰データを提供するための手段としても、車載装置２は応用することができる。つまり、ドライブレコーダの補完としても車載装置２は利用できる。
【0101】
本発明のいくつかの実施形態を説明したが、これらの実施形態は例として提示するものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】