(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-04-15
(45)【発行日】2022-04-25
(54)【発明の名称】通信装置、プログラム、通信方法
(51)【国際特許分類】
H04M 1/00 20060101AFI20220418BHJP
【FI】
H04M1/00 U
(21)【出願番号】P 2018217599
(22)【出願日】2018-11-20
【審査請求日】2021-03-22
(73)【特許権者】
【識別番号】000101732
【氏名又は名称】アルパイン株式会社
(74)【代理人】
【識別番号】100107766
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【氏名又は名称】伊東 忠彦
(72)【発明者】
【氏名】田口 智貴
【審査官】吉村 伊佐雄
(56)【参考文献】
【文献】特開2014-103504(JP,A)
【文献】特開2013-048330(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F13/00
H04B7/24-7/26
H04L12/28
12/44-12/46
H04M1/00
1/24-1/82
99/00
H04W4/00-99/00
(57)【特許請求の範囲】
【請求項1】
アプリケーション部と、
ネットワークに接続できる携帯端末と通信をするための第1の通信プロトコル部と、
ネットワークに接続するための第2の通信プロトコル部と、
前記第1の通信プロトコル部と前記第2の通信プロトコル部の間の通信を中継する中継部と、
前記第2の通信プロトコル部が前記ネットワークと接続するための識別情報記憶カードが装着されていることを検出する検出部と、を有し、
前記検出部により前記識別情報記憶カードが装着されていることが検出されない場合、
前記アプリケーション部は、自機を宛先に指定して前記第2の通信プロトコル部を用いた通信を行うことで、前記中継部にデータを送信し、
前記中継部は前記第1の通信プロトコル部を介して、前記アプリケーション部から受け取った前記データを前記携帯端末へ送信し、
前記検出部により前記識別情報記憶カードが装着されていることが検出された場合、
前記アプリケーション部は、ネットワーク上の情報処理装置を宛先に指定して前記第2の通信プロトコル部を用いた通信を行うことで、前記中継部を介さずに、前記ネットワークにデータを送信することを特徴とする通信装置。
【請求項2】
自機を宛先に指定して前記第2の通信プロトコル部を用いた通信を行う場合、前記アプリケーション部は、自機を宛先に指定して送信する前記データにネットワーク上の情報処理装置の宛先を付加し、
前記中継部は、前記データの宛先を自機からネットワーク上の情報処理装置に変更し、前記第1の通信プロトコル部に前記データを送信することを特徴とする
請求項1に記載の通信装置。
【請求項3】
前記第1の通信プロトコル部は、前記携帯端末と前記通信装置が通信するための独自プロトコルであり、
前記第2の通信プロトコル部は、TCP/IPに関する処理を行うことを特徴とする
請求項2に記載の通信装置。
【請求項4】
前記アプリケーション部は、自機を宛先に指定して前記第2の通信プロトコル部を用いた通信を行う場合、前記中継部のポート番号を指定し、
前記中継部は、前記ポート番号で指定されるRAWソケットから前記データを取得し、
IPヘッダとTCPヘッダが付いている前記データを前記第1の通信プロトコル部に渡すことを特徴とする
請求項3に記載の通信装置。
【請求項5】
前記中継部は、IPヘッダとTCPヘッダが付いている前記データを前記第1の通信プロトコル部から受け取り、IPヘッダとTCPヘッダが付いている前記データを前記RAWソケットに書き込み、
前記第2の通信プロトコル部が前記RAWソケットから取得した前記データからIPヘッダとTCPヘッダを除去して前記データをアプリケーション部に渡すことを特徴とする
請求項4に記載の通信装置。
【請求項6】
情報処理装置を、
アプリケーション部と、
ネットワークに接続できる携帯端末と通信をするための第1の通信プロトコル部と、
ネットワークに接続するための第2の通信プロトコル部と、
前記第1の通信プロトコル部と前記第2の通信プロトコル部の間の通信を中継する中継部と、
前記第2の通信プロトコル部が前記ネットワークと接続するための識別情報記憶カードが装着されていることを検出する検出部、として機能させ、
前記検出部により前記識別情報記憶カードが装着されていることが検出されない場合、
前記アプリケーション部は、自機を宛先に指定して前記第2の通信プロトコル部を用いた通信を行うことで、前記中継部にデータを送信し、
前記中継部は前記第1の通信プロトコル部を介して、前記アプリケーション部から受け取った前記データを前記携帯端末へ送信し、
前記検出部により前記識別情報記憶カードが装着されていることが検出された場合、
前記アプリケーション部は、ネットワーク上の情報処理装置を宛先に指定して前記第2の通信プロトコル部を用いた通信を行うことで、前記中継部を介さずに、前記ネットワークにデータを送信することを特徴とするプログラム。
【請求項7】
ネットワークに接続できる携帯端末と通信をするための第1の通信プロトコル部、又は、ネットワークに接続するための第2の通信プロトコル部を用いて通信装置で動作するアプリケーション部がネットワークを介してデータを送信する通信方法であって、
前記第2の通信プロトコル部が前記ネットワークと接続するための識別情報記憶カードが装着されていることを検出するステップと、
前記識別情報記憶カードが装着されていることが検出されない場合、
前記アプリケーション部は、自機を宛先に指定して前記第2の通信プロトコル部を用いた通信を行うことで、前記第1の通信プロトコル部と前記第2の通信プロトコル部の間の通信を中継する中継部にデータを送信するステップと、
前記識別情報記憶カードが装着されていることが検出された場合、
前記アプリケーション部は、ネットワーク上の情報処理装置を宛先に指定して前記第2の通信プロトコル部を用いた通信を行うことで、前記中継部を介さずに、前記ネットワーク
にデータを送信するステップと、を有することを特徴とする通信方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、通信装置、プログラム、及び、通信方法に関する。
【背景技術】
【0002】
インターネットなどのネットワークに接続する通信機能を有する車両や、通信機能を利用して車両の情報を送信したりネットワーク上の情報を取得したりする車両が増えている。一定の定義はないが通信機能を利用して種々のサービスを実現する車両をコネクテッドカーという。
【0003】
ネットワークへの接続を実現する通信方法としては、車両に搭載された通信装置又は車載装置がネットワークへ接続する通信方法(以下、第1の通信方法)と、車載装置に通信機能を有するスマートフォンなどを接続する通信方法(以下、第2の通信方法)がある(例えば、特許文献1参照。)。特許文献1には中継サーバに車両データを送信する通信システムが開示されている。
【0004】
第1の通信方法では車両に搭載されている通信装置にSIMカード(Subscriber Identity Module Card)が装着される。また、車載装置にSIMカードを装着可能にすることも実用化されつつあるか、又は、少なくとも検討されている。第2の通信方法ではスマートフォンにSIMカードが装着されている。
【0005】
第1の通信方法では、ユーザが車載装置にスマートフォンなどを接続する作業が不要であるため、ユーザの操作性という点では有利だが、通信費を車載装置のメーカが負担しなければならない(場合によってはユーザがスマートフォンとは別に通信費を負担する)。第2の通信方法では、少なくともメーカが通信費を負担する必要はないが、車載装置にスマートフォンなどを接続する作業が必要となる。このように、車載装置が第1の通信方法と第2の通信方法のどちらで通信する方が有利であるか現状では断定できず、車載装置としては第1の通信方法と第2の通信方法の両方に対応することが求められる可能性がある。
【先行技術文献】
【特許文献】
【0006】
【発明の概要】
【発明が解決しようとする課題】
【0007】
しかしながら、従来の技術では車載装置が異なる通信方法に対応することがコスト増になるという問題があった。まず、第1の通信方法では車載装置がネットワークに接続するが、第2の通信方法では車載装置がスマートフォンと接続するため、車載装置としては処理が異なりそれぞれに対応した処理が必要になる。
図1を用いて説明する。
【0008】
図1は、車載装置が第1の通信方法と第2の通信方法でそれぞれ通信する場合のインタフェース設計を模式的に示す図である。
図1(a)は第1の通信方法において車載装置が通信する通信インタフェースを示す。
図1(b)は第2の通信方法において車載装置が通信する通信インタフェースを示す。第1の通信方法では車載装置がネットワークを介してサーバと通信するが、TCP/IPプロトコル101など汎用的な通信プロトコルが使用される場合が多い。このため、
図1(a)では一例としてTCP/IPプロトコル101を示した。車載装置で動作するアプリケーションソフト11はTCP/IPプロトコル101のソケットに相当するTCP/IPインタフェース102を介してTCP/IPプロトコル101による通信制御でサーバと通信する。
【0009】
第2の通信方法では、車載装置がスマートフォンと通信する。車載装置がスマートフォンを介してネットワークに接続する場合、テザリングという通信方法を利用できる場合があるが、テザリングの利用が困難なスマートフォンも存在する。このようなスマートフォンでは、車載装置がスマートフォンと通信するために、スマートフォンに独自の独自プロトコル21が車載装置にインストールされていることが要請される。独自プロトコル21の使用を回避して車載装置がスマートフォンと通信することも不可能ではないが、スマートフォンのメーカからの認証が得られず、車載装置がこのスマートフォンに対応している旨を公表できなくなる。
【0010】
車載装置に独自プロトコル21がインストールされている場合、車載装置のアプリケーションソフト11は、独自プロトコル21が提供する独自インタフェース103を介して独自プロトコル21を呼び出す。独自インタフェース103はいわゆるAPI(Application Interface)である。独自プロトコル21がスマートフォンと通信するので、アプリケーションソフト11はスマートフォンを介してネットワーク(サーバ)に接続することができる。
【0011】
したがって、車載装置のメーカが、第1の通信方法に対応していた車載装置を第2の通信方法に対応させる場合、又は、この逆に第2の通信方法に対応していた車載装置10を第1の通信方法に対応させる場合、アプリケーションソフト11のインタフェース設計を変更する必要があり、開発コストの増大を生じさせてしまう。
【0012】
本発明は、上記課題に鑑み、低コストで異なる通信方法に対応することができる車載装置を提供することを目的とする。
【課題を解決するための手段】
【0013】
上記課題に鑑み、本発明は、アプリケーション部と、ネットワークに接続できる携帯端末と通信をするための第1の通信プロトコル部と、ネットワークに接続するための第2の通信プロトコル部と、前記第1の通信プロトコル部と前記第2の通信プロトコル部の間の通信を中継する中継部と、前記第2の通信プロトコル部が前記ネットワークと接続するための識別情報記憶カードが装着されていることを検出する検出部と、を有し、前記検出部により前記識別情報記憶カードが装着されていることが検出されない場合、前記アプリケーション部は、自機を宛先に指定して前記第2の通信プロトコル部を用いた通信を行うことで、前記中継部にデータを送信し、前記中継部は前記第1の通信プロトコル部を介して、前記アプリケーション部から受け取った前記データを前記携帯端末へ送信し、前記検出部により前記識別情報記憶カードが装着されていることが検出された場合、前記アプリケーション部は、ネットワーク上の情報処理装置を宛先に指定して前記第2の通信プロトコル部を用いた通信を行うことで、前記中継部を介さずに、前記ネットワークにデータを送信することを特徴とする通信装置を提供する。
【発明の効果】
【0014】
低コストで異なる通信方法に対応することができる車載装置を提供することができる。
【図面の簡単な説明】
【0015】
【
図1】車載装置が第1の通信方法と第2の通信方法でそれぞれ通信する場合のインタフェース設計を模式的に示す図である。
【
図3】本実施形態の車載装置のソフトウェア構成と通信経路を説明する図である。
【
図4】サーバと車載装置が通信する通信システムの一例の構成図である。
【
図5】車載装置が有する機能をブロック状に示す機能ブロック図の一例である。
【
図6】OSI参照モデル(TCP/IP)モデルを説明する図の一例である。
【
図7】サーバのURL及びHTTPリクエストの一例を説明する図である。
【
図8】経路CでミドルウェアがHTTPリクエストを送信する一例の手順を示すフローチャート図である。
【
図10】車載装置のソフトウェア構成と受信時の通信経路の一例を説明する図である。
【
図11】HTTPレスポンスの受信時におけるミドルウェアの処理を説明する一例のフローチャート図である。
【
図12】アプリケーションソフトがSIMカードの装着を検出した場合に経路を切り替える一例の手順を示すフローチャート図である。
【発明を実施するための形態】
【0016】
以下、本発明を実施するための形態について図面を参照しながら説明する。
【0017】
<通信方法の概略>
まず、本実施形態の通信方法を説明するにあたって従来のソフトウェア構成を説明する。
図2は、従来のソフトウェア構成例を示す図である。
図2(a)は第1の通信方法で通信する場合のソフトウェア構成例である。上位層から、アプリケーションソフト11、HTTPクライアント12、TCPソフト13、IPソフト14、及び、ドライバソフト15の階層構造を有している。アプリケーションソフト11はHTTPクライアント12を呼び出して、HTTPクライアント12はTCPソフト13を呼び出し、TCPソフト13はIPソフト14を呼び出し、IPソフト14はドライバソフト15を呼び出して、サーバ30と通信する。
【0018】
図2(b)は第2の通信方法で通信する場合のソフトウェア構成例である。上位層から、アプリケーションソフト11、スマートフォン50に独自の独自プロトコル21、及び、ドライバソフト22の階層構造を有している。アプリケーションソフト11は独自プロトコル21を呼び出して、独自プロトコル21はドライバソフト22を呼び出してスマートフォン50と通信する。スマートフォン50はサーバ30と通信する。
【0019】
なお、
図2(a)のソフトウェア構成ではHTTPクライアント12がある分だけ
図1(a)と異なっているが、これは
図1(a)ではHTTPクライアント12が省略されているか、又は、アプリケーションソフト11がHTTPクライアント12の機能を有しているためである。
図2(a)(b)においても、第1の通信方法と第2の通信方法を切り替えるためには、車載装置10のメーカ等が、アプリケーションソフト11とHTTPクライアント12の通信インタフェースを、アプリケーションソフト11と独自プロトコル21の通信インタフェースに変更する作業が必要である。したがって、開発コストの増大を生じさせてしまう点では同じである。
【0020】
そこで、本実施形態では、
図3に示すようなソフトウェア構成を採用することで、
図1、
図2で説明した課題を解決する。
図3は、本実施形態の車載装置10のソフトウェア構成と通信経路を説明する図である。
【0021】
(1)まず、車載装置10が自機に装着されたSIMカードを使って、又は、車両に搭載されたSIMカード内蔵の通信装置を使って、サーバ30と通信する場合を説明する。この通信経路を経路Aとする。この場合、アプリケーションソフト11は従来(
図2(a))と同様に、HTTPクライアント12、TCPソフト13、IPソフト14、及び、ドライバソフト15を経由してサーバ30と通信する。
【0022】
(2)次に、車載装置10がスマートフォン50を介してサーバ30と通信する場合を説明する。この通信経路を経路Bとする。アプリケーションソフト11は、ループバックアドレスを宛先のIPアドレスに指定する。ループバックアドレスはローカルホストとも呼ばれるが、自分自身を示すIPアドレスである。したがって、アプリケーションソフト11から送信され、HTTPクライアント12、TCPソフト13、及び、IPソフト14を経由したHTTPリクエストは、IPソフト14により自分(車載装置10)宛であると判断され、予め決まっているミドルウェア20のTCPのポート番号に対応したソケットに書き込まれる。本実施形態ではミドルウェア20がRAWソケット210を使用する。したがって、IPヘッダとTCPヘッダでカプセル化されたままである。
【0023】
ミドルウェア20がスマートフォン50と通信する通信経路を経路Cとする。ミドルウェア20はHTTPリクエストの宛先のIPアドレスを、サーバ30のIPアドレスに変更し、更に、スマートフォン50の独自プロトコル21に対応した独自インタフェース103を介して独自プロトコル21を呼び出す。独自プロトコル21はドライバソフト22を介してHTTPリクエストをスマートフォン50に送信する。スマートフォン50はサーバ30のIPアドレスを宛先とするHTTPリクエストをサーバ30に送信する。
【0024】
図3のような構成によれば、アプリケーションソフト11は経路Aを使用するか又は経路Bを使用するかを、宛先のIPアドレスを切り替えることで選択できるようになる。したがって、経路Aを使用する場合と経路Bを使用する場合とで、アプリケーションソフト11の変更は生じないか又は殆ど生じない。生じるとしても宛先のIPアドレスをサーバ30とするか又はローカルホストとするかという最小限の変更でよい。また、ユーザによるSIMカードの装着を検出して、宛先のIPアドレスを変更する機能をアプリケーションソフト11が有していれば、アプリケーションソフト11の変更は生じない。したがって、低コストで異なる通信方法に対応することができる車載装置10を提供することができる。
【0025】
<用語について>
SIMカードとは「Subscriber Identity Module Card」と英語で表記され、日本語では「加入者識別モジュールカード」という。SIMカードには、どの携帯電話会社を使っているかといった契約情報、携帯電話会社が提供する通信システムの加入者を特定する固有番号などが記録されている。SIMカードは識別情報記憶カードの一例である。
【0026】
アプリケーション部は、種々のアプリケーションソフトであり、本実施形態ではアプリケーションソフト11という用語で説明する。
【0027】
第1の通信プロトコル部は、車載装置10がスマートフォン50と通信をするための通信プロトコルであり、本実施形態では独自プロトコル21という用語で説明する。
【0028】
第2の通信プロトコル部は、車載装置10がネットワークに接続するための通信プロトコルであり、本実施形態ではTCPソフト13、IPソフト14という用語で説明する。TCPソフト13はUDPソフトでもよい。
【0029】
<システム構成例>
図4はサーバ30と車載装置10が通信する通信システム100の一例の構成図を示す。車載装置10は車両に搭載された装置である。本実施形態の車載装置10はサーバ30と通信する機能を有していればよく、通信装置と称してもよい。ただし、ナビゲーション機能、及び、AV(Audio Visual)の再生機能の少なくとも一方の機能を有していてもよい。ナビゲーション機能は、出発地から目的地までの経路を検索して道路地図に設定し、ディスプレイに表示された電子地図に経路と現在地を表示したり、経路に基づいて進路変更の手前で音声案内や電子地図上のアニメーションなどで適切な進路を案内したりする機能である。AV機能とは、ラジオ・テレビで放送されたコンテンツ又はDVDなどの記憶媒体に記憶されたコンテンツを再生したり、カメラで撮像した周囲の映像を表示したりする機能である。
【0030】
これらの機能を有する車載装置10は、ナビゲーション装置、チューナー、カーオーディオなどと呼ばれる場合がある。なお、ナビゲーション機能を有さずに、主にAV機能と通信機能を有する装置をディスプレイオーディオという。ディスプレイオーディオは、スマートフォン50などの端末装置との通信によりナビゲーションの機能を提供する。この場合、スマートフォン50に搭載されるアプリがナビ画面等を生成し、このアプリが生成するナビ画面をディスプレイオーディオが通信で取得して表示する。スマートフォン50で動作するこのようなアプリとしてCarPlay(登録商標)やAndroid Auto(登録商標)等が知られている。
【0031】
また、車載装置10の機能のうち経路の検索を
図4のサーバ30が行い、サーバ30が経路及び地図データを車載装置10に提供する形態も存在する。
【0032】
車載装置10は、車載された状態と携帯可能な状態の切り替えが可能であってよい。つまり、車載装置10は、車両8に対し脱着可能であってよい。
【0033】
本実施形態のサーバ30は、車載装置10と通信しうる情報処理装置である。通信する対象であれば具体的に提供する機能はどのようなものでもよい。例えば、経路検索や地図データを送信するサーバ30、ユーザの音声データを認識して音声の認識結果を提供するサーバ30、ユーザが検索した情報を返すサーバ30、及び、各種のWebサーバが含まれる。
【0034】
車両8にはスマートフォン50が搭載されている場合と搭載されない場合がある。スマートフォン50が搭載される場合、スマートフォン50は基地局9に接続する機能を有する携帯端末であればよく、スマートフォン50には限らない。例えば、SIMカードの装着が可能な、タブレット端末、ノートPC、モバイルルータ、PDA(Personal Digital Assistant)などでもよい。
【0035】
<機能について>
図5を用いて、車載装置10の機能について説明する。
図5は、車載装置10が有する機能をブロック状に示す機能ブロック図の一例である。車載装置10は、アプリケーションソフト11、HTTPクライアント12、TCPソフト13、IPソフト14、ドライバソフト15、ミドルウェア20、独自プロトコル21、ドライバソフト22、遠距離通信部16、近距離通信部23、及び、SIMカード装着検出部17を有している。
【0036】
なお、車載装置10が一般に有している可能性がある、GPS受信機、自律航法用センサ、タッチパネル付きのディスプレイ、スピーカ、マイク、チューナー、及び、HUD(Head Up Display)等については省略されている。また、車載装置10はCPUやRAMなど一般的な情報処理装置の機能を有しているものとする。
【0037】
まず、アプリケーションソフト11は、何らかの通信を必要とするソフトウェアであればよい。例えば、ブラウザアプリ、ニュースアプリ、天気アプリ、動画再生アプリ、など様々なソフトウェアが考えられる。また、アプリケーションソフト11は1つであるとは限らず複数ある場合が多い。
【0038】
HTTPクライアント12はHTTPリクエストを生成し、HTTPレスポンスを取得するソフトウェアである。現在のアプリケーションソフト11はHTTPクライアント12の機能を含む場合があり、アプリケーションソフト11にHTTPクライアント12が含まれる構成でもよい。
【0039】
TCPソフト13はTCPという通信プロトコルに関する処理を行うソフトウェアであり、IPソフト14はIPという通信プロトコルに関する処理を行うソフトウェアである。TCPソフト13は主に通信相手との間にTCPコネクションを作る。そして、エラーチェック、応答確認に基づく再送制御、シーケンス番号に基づくデータの整列等を行う。ただし、経路Bが使用される場合、通信相手のTCPが存在しないのでこれらの制御は必要ない。
【0040】
IPソフト14は、IPアドレスに基づいて適切なルーターに向けてパケットを送信するルーティングを行う。また、通信対象のデータを所定のパケットに分割して送信する。また受信時にはネットワークから自分宛のパケットを取り出して、パケットを再構築してTCPソフト13に渡す。
【0041】
ドライバソフト15は、遠距離通信部16を実現する通信方式に応じたデバイスドライバである。遠距離通信部16を実現する通信方式として3G、4G、5G、LTEなどが使用される場合、ドライバソフト15はこれらに対応したデバイスドライバである。遠距離通信部16は、3G、4G、5G、LTEなどの通信方式によりデータ通信を行い、サーバ30とデータの送受信を行う。
【0042】
ミドルウェア20は、ループバックアドレスを宛先のIPアドレスとするHTTPリクエストを受信し、宛先のIPアドレスをサーバ30のIPアドレスに変更するソフトウェアである。ミドルウェア20はRAWソケット210を使用して、IPヘッダとTCPヘッダでカプセル化されたままのHTTPリクエストを取り扱う。
【0043】
データの受信時には、独自プロトコルから取得したHTTPレスポンス(IPヘッダとTCPヘッダでカプセル化された)をRAWソケット210に書き込めばよい。ミドルウェア20はこのようにデータを中継する中継部の機能を有する。
【0044】
独自プロトコル21は、スマートフォン50に独自の通信処理を行うソフトウェアである。独自プロトコル21はスマートフォン50のメーカから提供される。処理内容はスマートフォン50によって様々でよいが、本実施形態ではTCP/IPと同等の処理を行うものとして説明する。
【0045】
ドライバソフト22は近距離通信部23を実現する通信方式に応じたデバイスドライバである。近距離通信部23を実現する通信方式としてBluetooth(登録商標)、USB、又は、Wi-Fiなどが使用される場合、ドライバソフト22はこれらに対応したデバイスドライバである。
【0046】
近距離通信部23は、Bluetooth(登録商標)、USB、又は、Wi-Fiなどの通信方式によりデータ通信を行い、スマートフォン50とデータの送受信を行う。
【0047】
SIMカード装着検出部17は車載装置10のSIMカードスロットにSIMカードが装着されていることを検出する。SIMカードが装着されているか否かをアプリケーションソフト11に通知することができる。
【0048】
<OSI参照モデル(TCP/IP)モデル>
OSI参照モデルはISO(国際標準化機構)が定めた、ネットワーク機器のメーカが異なっても相互通信するための統一規格をいう。OSI参照モデルは、コンピュータなどのネットワーク機器の通信機能を階層構造で分割したネットワークモデルで、通信プロトコルを7つの階層に分けて定義している。一般には、7つの階層の一部を統合して扱う「TCP/IPモデル」がデファクトスタンダードとなっている。
【0049】
図6(a)は「TCP/IPモデル」を模式的に示す。上位層からアプリケーション層、トランスポート層、インターネット層、及び、ネットワークインタフェース層の4つの階層を有している。また、各階層には代表的な通信プロトコルが対応付けられている。ネットワークモデルをこのような階層構造とすることで、各階層の通信プロトコルは上位又は下位で使用される通信プロトコルの影響を受けずに通信できる。
【0050】
ネットワークインタフェース層では直接接続されたノード間の通信について規定され、また、ビット列を電気信号に変換する変換方法について規定されている。インターネット層は、IPアドレスに基づいてネットワークとネットワークを相互通信するための規定を定めている。トランスポート層はノード間のデータ転送の信頼性を確保するための規定を定めている。アプリケーション層は、通信プログラム間の論理的な経路の制御、及び、文字コードなどのデータの表現形式の規定を定めている。
【0051】
図6(b)はデータのカプセル化と非カプセル化を説明する図である。各階層の通信プロトコルは各階層の規定に従ったデータを送信するために、第4層から第1層の順で送り主や宛先などの情報(ヘッダ)を梱包していく。ヘッダを付すことをカプセル化といい、受信時にヘッダを除去することを非カプセル化という。ただし、RAWソケット210が使用された場合は、カプセル化と非カプセルは行われない。
【0052】
図6(b)の例では、送信時にアプリケーションソフト11が作成したデータに、アプリケーション層(HTTPクライアント12)がHTTPヘッダを付し、トランスポート層(TCPソフト13)がTCPヘッダを付し、インターネット層(IPソフト14)がIPヘッダを付し、ネットワークインタフェース層(ドライバソフト15)が物理ヘッダを付す。なお、物理ヘッダは実際の通信経路によって様々であり、例えば無線LANのイーサネットフレーム(登録商標)のヘッダ、Bluetooth(登録商標)のヘッダなどである。受信時には第1層から第4層の順に各階層の通信プロトコルがヘッダを除去する。
【0053】
<送信時の通信>
続いて、
図3を参照して、車載装置10がデータをサーバ30に送信する際の通信方法について補足する。この通信方法は車載装置10が有する
図3のプログラム階層の全体又は一部のプログラムにより実現される。
【0054】
(1)経路Aの場合は、ネットワークを介した通常の通信と同様である。HTTPクライアント12とTCPソフト13はソケット通信によりサーバ30と通信する。ソケット通信とは、アプリケーションソフト11とTCP/IPを結ぶインタフェースとしてソケット(Socket)を使用する通信方法であり、TCP/IP通信では一般的な通信方法である。HTTPクライアント12はソケット生成、ソケット接続要求、データの受信/送信、及び、ソケットの切断を行う。HTTPクライアント12は相手との接続に関知せず、ソケットを通信インタフェースとする。サーバ30との接続はTCPソフト13が確立する。アプリケーションソフト11はソケット生成時にサーバ30のIPアドレスとポート番号を指定する。したがって、ソケットはサーバ30のIPアドレス及びポート番号と対応付けられている。車載装置10のIPアドレスとアプリケーションソフト11のポート番号はTCPソフト13が自動で付与する。
【0055】
HTTPクライアント12は
図7で説明するようなHTTPリクエストを、作成したソケットに書き込む。TCPソフト13は例えばスリーウェイハンドシェイクのような接続手順でサーバ30のTCPソフトとコネクションを確立する。そして、TCPヘッダを付与したHTTPリクエストをIPソフト14に渡す。IPソフト14はHTTPリクエストをパケットに分割し、更にIPヘッダを付与してドライバソフト15に渡す。ドライバソフト15は更に物理ヘッダを付与して伝送経路からデータを送信する。
【0056】
(2)経路Bの場合、少なくともTCPソフト13までの処理は経路Aと同様である。しかし、HTTPクライアント12が指定する宛先のIPアドレスはローカルホスト(ループバックアドレス)であり、ポート番号はミドルウェア20を指定するポート番号である。また、HTTPクライアント12はHTTPリクエストの一部にサーバ30のIPアドレス(URL)及びポート番号を付加する。付加する方法としては次述するクエストリングやHTTPメッセージのボディ部に書き込む方法がある。
【0057】
なお、
図3ではHTTPリクエストがIPソフト14まで到達してからミドルウェア20に届いているが、HTTPリクエストは少なくともTCPソフト13まで到達すればよい。
【0058】
HTTPリクエストは、TCPソフト13及びIPソフト14で順次カプセル化されるが、HTTPクライアント12はループバックアドレスを宛先のIPアドレスに指定しミドルウェアのポート番号を指定しているので、TCPソフト13はミドルウェア20が作成したRAWソケット210にHTTPリクエストを書き込む。RAWソケット210であるため、IPソフト14及びTCPソフト13は非カプセル化を行わない。なお、HTTPリクエストを受信するという意味で、ミドルウェア20は最小限のWebサーバの機能を有している。
【0059】
ミドルウェア20はRAWソケット210からHTTPリクエストを取得し、HTTPリクエストの宛先のIPアドレスをローカルホストからサーバ30のIPアドレスに変更し、宛先のポート番号をミドルウェア20のポート番号からサーバ30のIPアドレスに変更する。ミドルウェア20は、スマートフォン50の独自プロトコル21に対応した独自インタフェース103を介して独自プロトコル21を呼び出して、HTTPリクエストを独自プロトコル21に渡す。ここでもTCPヘッダとIPヘッダがついたまま、HTTPリクエストが独自プロトコル21に渡される。独自プロトコル21はドライバソフト22にHTTPリクエストを送信する。
【0060】
なお、独自プロトコル21がどのような処理を行うかは独自プロトコル21に依存するものとする。
【0061】
<HTTPリクエストの一例>
図7を用いて、HTTPリクエストについて説明する。
図7はサーバ30のURL及びHTTPリクエストの一例である。例えば、ユーザが任意のサーバ30にアクセスする場合、サーバ30のURLをアプリケーションソフト11に指示する。
図7(a)はユーザが指示するURLの一例である。
http://www.server.com:80/index.html
「http」はスキームといい、HTTPという通信プロトコルを使用していることを示している。「www」をホスト名といい、「server.com」をドメイン名という。ドメイン名により任意のサーバ30を一意に指定できる。「80」はサーバ30のポート番号であり、通常、Webサーバのポート番号は80なので省略される場合もある。「index.html」はパスといい、要求するHTMLファイルがどこにあるかをパス(path)とファイル名で示す。
【0062】
図7(b)は、経路Aにおいて
図7(a)のURLが指示された場合に、HTTPクライアント12が作成するHTTPリクエストの一例である。なお、説明の便宜上、HTTPリクエストの一部を省略している。
GET /index.html HTTP1.1
Host: www.server.com:80
「GET」はHTTPのメソッドの1つであり、ファイルを取得するメソッドである。「/index.html」は
図7(a)のパスであり、「HTTP1.1」はHTTPのバージョンである。「Host: www.server.com:80」はサーバ30のドメインとポート番号である。なお、「www.server.com」はDNSサーバによりIPアドレスに変換される。
【0063】
TCPソフト13はHTTPクライアント12が作成してソケットに書き込んだ
図7(b)のHTTPリクエストを、ソケットから受け取りサーバ30とコネクションを確立する。
【0064】
続いて、経路Bを使用する場合を説明する。経路Bを使用する場合もユーザが指示するURLは
図7(a)と同様でよい。しかし、アプリケーションソフト11は、経路Bが使用されることを検出しているか又はそのように設定されているため、URLを変更する。
【0065】
図7(c)は、経路Bが使用される場合にアプリケーションソフト11が設定を変更したURLを示す。
http://localhost:8080/middleware.jsp?=www.server.com:80/index.html
「localhost」はループバックアドレスを意味する。具体的には「127.0.0.1」であるためこの値に変更してもよい。「8080」はミドルウェア20のポート番号であり、ミドルウェア20が待ち受けるRAWソケット210を意味する。「middleware.jsp」はミドルウェア20を指定する情報である。「middleware.jsp」ミドルウェア20を意味するソフトウェアのファイル名であり、「middleware.jsp」の指定によりミドルウェア20が実行される。「?」以降をクエストリングといい、サーバ30にパラメータを渡したい場合に任意の情報が設定できるようになっている。本実施形態では、ドメイン名が「localhost」に変更されているので、クエストリングによりサーバ30のURLである「www.server.com:80/index.html」がクエストリングによりミドルウェア20に通知されている。なお、このようにクエストリングによりサーバ30のURLを通知するのでなく、HTTPリクエストのボディ部にサーバ30のURLを付加してもよい。
【0066】
図7(d)は経路Bにおいて、
図7(c)のURLが指示された場合に、HTTPクライアント12が作成するHTTPリクエストの一例である。
GET /middleware.jsp?=www.server.com:80/index.html HTTP/1.1
Host: localhost:8080
TCPソフト13、IPソフト14は
図7(d)のHTTPリクエストをHTTPクライアント12から受け取ると、それぞれヘッダでカプセル化する。一方、「Host: localhost」でループバックアドレスが指定されていることを検出し、また、「8080」でmiddleware.jspが待ち受けているRAWソケット210のポート番号が分かるので、RAWソケット210に、
「GET /middleware.jsp?=www.server.com:80/index.html HTTP/1.1」
を書き込む。ミドルウェア20は、RAWソケット210を監視しているのでHTTPリクエストを検出することができる。
【0067】
<ミドルウェアの処理>
続いて、
図8を用いてミドルウェア20の処理を説明する。
図8は、経路Cでミドルウェア20がHTTPリクエストを送信する一例の手順を示すフローチャート図である。
【0068】
ミドルウェア20は監視しているポート番号(8080)のRAWソケット210から
図7(d)で説明したHTTPリクエストを読み取る(S1)。
【0069】
次に、ミドルウェア20は、HTTPリクエストを解析してサーバ30のURL、及び、HTTPメソッドを取り出す(S2)。HTTPメソッドはHTTPリクエストの先頭に記述されている。サーバ30のURLは「?」以降に記述されている。このようにHTTPリクエストを解析することをパースといい、一般的なWebサーバで行われている。
【0070】
次に、ミドルウェア20は、サーバ30のURLを宛先とするHTTPリクエストを作成する(S3)。HTTPリクエストは例えば以下のようになる。
GET /index.html HTTP/1.1
Host: www.server.com:80
「GET」はHTTPメソッドをそのまま使用すればよい。「/index.html」はサーバ30のURLのパスである。HTTP/1.1はそのまま使用できる。「www.server.com:80」はクエストリングに含まれるホスト名、ドメイン名、及び、ポート番号である。
【0071】
次に、ミドルウェア20は、独自プロトコル21の独自インタフェース103を呼び出し、HTTPリクエストを独自プロトコル21に出力する(S4)。
【0072】
<HTTPレスポンス>
図9は、HTTPレスポンスの一例を示す。HTTPレスポンスはHTTPリクエストに対する応答としてサーバ30から送信される。サーバ30のWebアプリ等が送信するHTTPレスポンスは、レスポンス行201、ヘッダ202、及び、メッセージボディ203から構成されている。レスポンス行201は、通信が成功したか、失敗したかをステータスで示す。
図9では「200」が通信の成功を示す。ヘッダ202は
図6(b)のHTTPヘッダである。メッセージボディ203は例えばHTMLデータなど、アプリケーションソフト11が要求した情報である。
【0073】
なお、サーバ30からスマートフォン50に送信されるデータには
図6に示したように各階層のヘッダが付加されている。
【0074】
<受信時の通信>
続いて、
図10を用いて車載装置10がHTTPレスポンスを受信する場合の通信について説明する。
図10は、本実施形態の車載装置10のソフトウェア構成と受信時の通信経路を説明する図である。
【0075】
(1)車載装置10が経路Aで通信する場合、サーバ30から送信されたHTTPレスポンスを、ドライバソフト15、IPソフト14、及びTCPソフト13が順に非カプセル化し、TCPソフト13はサーバ30が宛先として設定したポート番号(送信時にTCPソフト13が付与したアプリケーションソフト11のポート番号)のソケットにHTTPレスポンスを書き込む。HTTPクライアント12は作成したソケットにHTTPレスポンスが書き込まれたことを検出するとHTTPレスポンスをソケットから読み取り、アプリケーションソフト11に渡す。このように、アプリケーションソフト11が送信したHTTPリクエストに対するHTTPレスポンスがソケットで対応付けられ、アプリケーションソフト11がHTTPレスポンスを受信できる。
【0076】
(2)経路Cで通信する場合、サーバ30から送信されたHTTPレスポンスを、スマートフォン50が車載装置10に転送する。独自プロトコル21はドライバソフト22から物理ヘッダが除去されたHTTPレスポンスを受信する。また、独自プロトコル21は、IPソフト14及びTCPソフト13のヘッダについては非カプセル化せず、独自インタフェース103を介してミドルウェア20にHTTPレスポンスを渡す。
【0077】
ミドルウェア20はRAWソケット210にIPヘッダとTCPヘッダついたままのHTTPレスポンスを書き込む。TCPソフト13とIPソフト14はHTTPレスポンスを送信しようとするが、RAWソケット210のHTTPレスポンスにはIPヘッダとTCPヘッダを付けない。一方、TCPヘッダの宛先のIPアドレスは車載装置であり、宛先のポート番号はアプリケーションソフト11である。このため、IPソフト14とTCPソフト13は受信のプロセスとして非カプセル化を行って、IPアドレスとポート番号で特定されるソケット(送信時と同じソケット)にHTTPレスポンスを書き込む。
【0078】
HTTPクライアント12は作成したソケットにHTTPレスポンスが書き込まれたことを検出するとHTTPレスポンスをソケットから読み取り、アプリケーションソフト11に渡す。したがって、経路Aと同様に、アプリケーションソフト11がHTTPリクエストを受信できる。
【0079】
<受信時のミドルウェアの機能>
図11は、HTTPレスポンスの受信時におけるミドルウェア20の処理を説明する一例のフローチャート図である。
【0080】
まず、ミドルウェア20は独自プロトコル21から、IPヘッダとTCPヘッダが付いたままのHTTPリクエストを受け取る(S11)。どのように受け取るかはミドルウェア20と独自プロトコル21の独自インタフェース103に依存するが、ミドルウェア20は独自プロトコル21にポーリングしてもよいし、独自プロトコル21から通知を受けてもよい。
【0081】
次に、ミドルウェア20はRAWソケット210にIPヘッダとTCPヘッダが付いたままのHTTPリクエストを書き込む(S12)。これにより、通常の通信と同様に、HTTPクライアント12がHTTPレスポンスを受信できる。
【0082】
<SIMカードの装着を検出した場合の経路の切り替え>
車載装置10にSIMカードが装着された場合に、ユーザなどが車載装置10にインストールされているアプリケーションソフト11を更新(インストール)してもよいが、アプリケーションソフト11が内部的に経路を切り替える機能を有しているとアプリケーションソフト11の更新が不要になる。
【0083】
図12は、アプリケーションソフト11がSIMカードの装着を検出した場合に経路を切り替える一例の手順を示すフローチャート図である。
図12の処理は例えば、アプリケーションソフト11の起動時又はHTTPリクエストの送信時に行われる。
【0084】
アプリケーションソフト11は、SIMカードが装着されているか否かを判断する(S21)。すなわち、SIMカード装着検出部17にSIMカードの装着の有無を問い合わせてSIMカードが装着されているか否かを判断する。
【0085】
ステップS21の判断がYesの場合、アプリケーションソフト11は経路Aを設定する(S22)。すなわち、以下のように宛先のIPアドレス、ポート番号を設定する。
【0086】
宛先のIPアドレス:サーバ30のIPアドレス
宛先のポート番号:サーバ30のポート番号
車載装置10のIPアドレス:携帯電話会社などから配布されたIPアドレス
アプリケーションソフト11のポート番号:任意
ステップS22の判断がNoの場合、アプリケーションソフト11は経路Bを設定する(S23)。すなわち、以下のように宛先のIPアドレス、ポート番号を設定する。
【0087】
宛先のIPアドレス:ローカルホスト
宛先のポート番号:ミドルウェア20のポート番号
車載装置10のIPアドレス:携帯電話会社などから配布されたIPアドレス
アプリケーションソフト11のポート番号:任意
クエストリング又はボディ部:サーバ30のIPアドレス及びポート番号
このように、アプリケーションソフト11が自動的に経路を選択することで、車載装置10の出荷後のアプリケーションソフト11の更新の必要性を低減できる。
【0088】
<まとめ>
以上説明したように、本実施形態の車載装置10では、経路Aを使用する場合と経路Bを使用する場合とで、アプリケーションソフト11の変更は生じないか又は殆ど生じないので、低コストで異なる通信方法に対応することができる。
【0089】
<その他の適用例>
以上、本発明を実施するための最良の形態について実施例を用いて説明したが、本発明はこうした実施例に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。
【0090】
例えば、本実施形態では、アプリケーション層の通信プロトコルをHTTPとして説明したが、アプリケーション層の通信プロトコルはTCP又はUDP上で動作するものであればよい。例えば、SMTP、POP3、FTP、SNMP、Telnetなどでもよい。
【0091】
また、
図5などの構成例は、車載装置10による処理の理解を容易にするために、主な機能に応じて分割したものである。処理単位の分割の仕方や名称によって本願発明が制限されることはない。車載装置10の処理は、処理内容に応じて更に多くの処理単位に分割することもできる。また、1つの処理単位が更に多くの処理を含むように分割することもできる。
【符号の説明】
【0092】
10 車載装置
20 ミドルウェア
30 サーバ
50 スマートフォン
100 通信システム