JP2006127307A - 車両状態の通知システム及びその構成装置、通知方法 - Google Patents

Abstract

【課題】
簡易な構成でかつ安価に車両状態をユーザに通知することができる車両状態の通知システムを提供する。
【解決手段】
ユーザが携行する子機３００と、この子機３００との間で双方向の無線通信が可能な親機２００とで、通知システムを構成する。子機３００からの送出要求データの受信を契機に、親機２００は、各種センサで検出された自動車１００の状態の検出結果をもとに自動車１００の状態を表す通知データを生成し、この通知データを子機３００に微弱無線で送信する。親機２００は、通知データの送信タイミングを子機３００の受信動作間隔に同期させる。
【選択図】 図１

Description

本発明は、例えば、自動車、自動二輪車、電車、航空機のような車両の状態を、法律の規制を受けない微弱無線モジュールを用いて当該車両の外にいるユーザに簡易に伝達するための技術に関する。車両の状態とは、例えば、エンジンその他の動力源が動作しているかどうか、ドアがロックされているかどうか、計器類が正常に動作しているかどうか等をいう。

微弱無線モジュールを用いて情報の伝達を行うシステムとして、キーレスエントリーシステムがある。従来のこの種のキーレスエントリーシステムは、自動車に搭載される無線モジュール（親機）と、ユーザが携行する携帯型無線モジュール（子機）とから構成される。子機は、親機に向けてドアをロックさせる内容又はアンロックさせる内容の制御信号を親機に向けて送信する。親機には、ドアをロック又はアンロックさせるロック制御機構が接続されており、子機からの制御信号を受信したとき（検波により制御信号であることを特定したとき）に、ロック制御機構を通じて、ドアをロック又はアンロックさせる。これにより、ユーザは、例えば荷物をもった状態であっても、キーを自動車の鍵穴に差し込む作業を行うことなく、ドアをロックまたはアンロックすることができる。
この種のキーレスエントリーシステムの中には、ドアの開閉のみならず、リモートエンジンスタート等の機能が付加されている高機能のものもある。このような高機能のキーレスエントリーの場合、ユーザは、車内に入ることなく、車両のエンジンを起動することで、寒冷時においてエンジンを予めかけておく、いわゆる「暖気運転」を手軽に行うことができる等、利便性が一段と高まったものになっている。

上述した従来のキーレスエントリーシステムでは、データの伝達方向が子機から親機への単方向となっている。そのため、ユーザは自動車のドアをロック又はアンロックすることはできるものの、現在、自動車のドアがロックされているのかどうかという、現在の状態を把握することはできない。
また、ユーザが自動車の近くにいないときに、「車上荒らし」などによって自動車に異変が生じていても、従来のキーレスエントリーシステムでは、その状態をユーザに伝達することはできない。
上記のような自動車の異変に備えて、自動車にセンサと無線機とを備えておき、実際に異変が生じた場合に、例えば警備員等が配備されているセキュリティセンターに対して無線機から異変の発生を通知することで、警備員に自動車の状態を確認に向かわせ、その確認結果を、セキュリティセンターから電話等によってユーザに伝達するというセキュリティサービスを併用することが考えられる。しかし、このようなサービスを実現する場合には、自動車から遠方のセキュリティセンターに対して異変状態を表す情報の通報を行う必要がある。そのため、自動車に備える無線機の運用には電波法上の免許が必要となるうえに、無線機自体が高価なものとなる。セキュリティセンターの維持費や人件費もかさむため、サービス利用料金の低減化も困難であり、現実的ではない。

本発明は、簡易な構成で、かつ安価に、車両の状態をユーザに通知することができる、車両状態の通知の仕組を提供するものである。

本発明は、それぞれ、法律の規制を受けない微弱電力による双方向の間欠通信を行う無線通信手段を備えた通知装置及び携帯端末装置を含む通知システムを提供する。

［車両状態の通知装置］
通知装置は、車両に搭載されるもので、携帯端末装置との間で、法律の規制を受けない微弱電力による双方向の間欠通信を行う無線通信手段と、この無線通信手段を通じて前記携帯端末装置から監視の対象となる車両の現在の状態を表す情報の送出要求を受け付ける送出要求受付手段と、この送出要求受付手段で受け付けた送出要求に対応する車両の状態について所定のセンサが検知した検知結果を取得する車両状態検知手段と、この車両状態検知手段が取得した検知結果を表す所定のデータ構造の通知データを前記携帯端末装置が受信可能な間隔で間欠送信するように前記無線通信手段の動作を制御する制御手段と、を備えて成る装置である。

間欠通信の同期をとりやすくする観点からは、前記携帯端末装置より間欠的に受信した信号の間隔を計測するタイマをさらに備えた通知装置とする。この場合、前記制御手段は、前記タイマにより計測された間隔に基づいて前記携帯端末装置との間で行う間欠通信の同期を確立するように前記無線通信手段を制御するように動作する。

好ましくは、前記制御手段は、同期を確立した後の前記間隔を保持し、この保持されている間隔とその後の受信時に前記タイマにより計測された間隔との比較に基づいて前記同期が維持されているかどうかを判定するように構成する。

ユーザに対する迅速な通知を可能にするため、前記車両状態検知手段は、前記センサの検知結果を前記携帯通信端末との間欠通信の通信タイミングとは無関係なタイミングで収集して所定のメモリに蓄積しておき、前記送出要求があったときに当該送出要求に対応する車両の状態について蓄積されている検知結果を前記メモリより読み出すように構成されていることが望ましい。通信の効率化の観点からは、前記車両状態検知手段は、前記センサの検知結果を周期的に取得するとともに取得した各周期の検知結果を前記メモリに蓄積しておき、前周期で取得した検知結果と今周期で取得した検知結果とを比較することにより、車両状態の変化の有無を表す情報を生成するように構成する。この場合、前記制御手段は、前記間欠通信に際して、前記車両状態検知手段より前記変化の有無を表す情報を取得し、車両状態に変化が有るときは、その旨を表す前記通知データを、当該変化が生じた直後に通信可能となるタイミングで前記携帯端末装置へ送信するように前記無線通信手段を制御するように構成することが望ましい。

［携帯端末装置］
携帯端末装置は、要求に応じて車両状態を通知する通知装置との間で、法律の規制を受けない微弱電力による双方向の間欠通信を行う無線通信手段と、この無線通信手段を通じて前記通知装置に対して監視の対象となる車両の現在の状態を表す通知データの送出を要求するための送出要求データを生成する送出要求データ生成手段と、この送出要求データ生成手段で生成した送出要求データを予め自装置に割り当てられた間隔で前記通知装置に間欠送信するとともに、自装置宛の前記通知データを受信するように前記無線通信手段の動作を制御する制御手段と、を備えた装置である。

操作性及び運用の有用性を高めるために、ユーザからの指示入力を受け付ける指示入力受付手段をさらに備え、前記送出要求データ生成手段は、前記指示入力受付手段が、ユーザが前記車両における複数の監視対象部位のいずれかの部位に対する前記要求を受け付けたときに、当該要求に応じた内容の送出要求データを生成するように構成しても良い。また、前記制御手段は、前記通知装置との同期確立後は第１間隔を維持して前記間欠送信を行い、ユーザからの指示入力を受け付けた緊急時には前記第２間隔よりも短い第２間隔で前記間欠送信を行うように前記無線通信手段を制御するようにしても良い。
あるいは、前記制御手段によりその動作が制御され、前記受信した通知データが表す車両の状態を視覚的にユーザに伝達する視覚化手段をさらに備えて携帯端末装置を構成しても良い。

［車両状態の通知方法］
上記のように構成される通知システムは、例えば、以下の複数の段階を経ることにより、ユーザに対して、車両の状態を通知することができる。
（１）携帯端末装置は、監視の対象となる車両の現在の状態を表す通知データの送出を要求するための送出要求データを、自装置に割り当てられた間隔で前記通知装置へ間欠送信する段階、
（２）通知装置が、前記送出要求データの受信を契機に当該携帯端末装置との間で間欠通信の同期を確立するとともに、前記車両の状態について所定のセンサが検知した検知結果を表す所定のデータ構造の通知データを、同期を確立した前記携帯端末装置が受信可能な間隔で間欠送信する段階、
（３）通知データを受信した前記携帯端末装置が、前記通知データにより特定される車両の状態を視覚的に表現してユーザに伝達する段階。

本発明によれば、簡易な構成で、かつ安価に、車両の状態をユーザに通知することができるシステムが得られる。

以下、図面を参照して本発明の一実施形態を説明する。
この実施形態では、車両として自動車を例にとって説明するが、自動車に限らず、自動二輪車、電車、船舶等の乗り物においても、本実施形態を同様に適用することができる。従って、本明細書における「車両」とは、その状態をユーザに通知することにより、そのユーザに便宜となる乗り物全般をいうものとする。なお、各図において、同一機能の構成部については同一の符号を付している。

図１は、本実施形態に係る通知システムの構成例を示す図である。この通知システムは、ユーザの所有する自動車１００に設けられた親機２００と、ユーザにより携帯される子機３００とを含んで構成される。親機２００と子機３００は、双方向通信が可能でかつ電波法による免許等も不要な微弱無線モジュールを主要構成品として含むものである。

まず、通知システムにおける動作の概略を説明する。
［自動車からユーザへ］
図１には、車上荒らしにより自動車１００に異常が発生し、親機２００からこのような異常が発生したことが子機３００に通知される例が示されている。
親機２００は、自動車１００の状態、例えばドアやウィンドウのロック状態や室内灯の点灯状態等を、通知データとして子機に送信することができる。図１において、車上荒らしによる自動車１００に対する破壊行為が発生した場合、親機２００は、荒らし行為による自動車の異常な振動等、荒らし行為に起因する蓋然性が高い現象を振動センサ等によって検出し、子機３００に対して、上述の通知データを通じて自動車１００に異常が発生したことを通知する。子機３００では、親機２００から送信された通知データにより異常が通知されると、例えば警報を発生させることにより、ユーザに対して、親機２００において異常が検出されたことを通知する。
このように、図１の例では、親機２００から子機３００への通信を可能にしているので、ユーザに対して、車上荒らしによって自己が保有している自動車１００に異常が発生したことを親機２００で検出されたことを通知することができる。

［ユーザから自動車へ］
図２は、ユーザが、自律的に、自動車１００に異常が発生しているかどうかを確認する場合の例が示されている。この場合、ユーザは、自己が携行する子機３００から、自動車１００の状態の通知を要求する信号、すなわち送出要求データを親機２００へ送信する。
親機２００は、子機３００から受信した送出要求データを受信すると、現在の自動車１００の状態を表す通知データを子機３００へ送信する。これにより、ユーザは、例えば自動車１００のトランクのドアが開いているか否か等、自動車がどのような状態におかれているかということを車外より把握することができる。

ここで、図１、図２に示したような自動車の状態通知を可能にするための親機２００及び子機３００の構成例を説明する。
［親機及びその周辺機器の構成］
親機２００は、自動車に設けられる周辺装置との連携によって動作する。図３に、自動車１００内部の周辺装置の例、及び、これらと親機２００との機能的な関連を示す。

本実施形態では、自動車１００に車載ＬＡＮ（ＬＡＮはローカル・エリア・ネットワークの略、以下同じ）１０１が設けられているものとして説明する。車載ＬＡＮ１０１には、制御ＩＣ（ＩＣは集積回路、以下同じ）１０２、制御ＩＣ１０３、制御ＩＣ１０４が接続されている。親機２００も、この車載ＬＡＮ１０１に接続される装置の一つである。

親機２００には、車載ＬＡＮ・Ｉ／Ｆドライバ部２１１、ＣＰＵ２１２、メモリ２１３、タイマ２１４、微弱無線部２１５が設けられている。親機２００は、車載ＬＡＮ・Ｉ／Ｆドライバ部２１１及び車載ＬＡＮ１０１を通じて、上記の制御ＩＣ１０２〜１０４に接続されるようになっている。ＣＰＵ２１２は、所定のプログラムを実行することにより、車両の状態を子機３００に通知するための各種制御処理を行う制御手段として動作する。本実施形態では、制御ＩＣ１０３，１０４より取得したデータに基づいて子機３００と送受信可能なフォーマットの通知データを生成し、これを微弱無線部２１５を通じて子機３００へ送信するための一連の制御処理を行う。制御処理の内容については、後で詳述する。

なお、ここでは、車載ＬＡＮ１０１、制御ＩＣ１０２等が、いずれも自動車１００側に予め組み込まれたものとし、親機２００を、車載ＬＡＮ１０１に、後付で組み込むものとした。しかし、これら車載ＬＡＮ１０１、制御ＩＣ１０１等の全部または一部が組み込まれていないタイプの、既存の自動車に対しては、制御ＩＣ１０２〜１０４と同等の機能を親機２００に予め組み込んでおくようにすれば良い。
タイマ２１４は、子機２００との間で間欠通信の同期をとるために、子機２００から送信される信号の受信間隔を計測するものである。

各制御ＩＣ１０２〜１０４は、例えば以下のように動作するものである。
制御ＩＣ１０２は、自動車１００に既に設けられている各種センサ、例えばドアスイッチ、ドアウィンドウスイッチ、社内灯スイッチ、ヘッドライトスイッチ及び図示しない振動センサのそれぞれに接続されており、これらのスイッチ等による検知結果を、車載ＬＡＮ１０１を通じて親機２００に伝達する。また、ドアスイッチ及びドアウィンドウスイッチからの入力を受け付けた場合には制御ＩＣ１０３へ、社内灯スイッチ及びヘッドライトスイッチからの入力を受け付けた場合には制御ＩＣ１０４へ、それぞれ入力内容に応じたデータを、車載ＬＡＮ１０１を通じて送信する。

制御ＩＣ１０３は、ドア及びドアウインドウの監視制御を行う。すなわち、ドアがアンロック状態のときにはドライバ１０３ａを通じてドアロック機構を制御することでドアのロックを可能にし、ドアがロック状態のときにはドライバ１０３ｂを通じてドアアンロック機構を制御することでドアのアンロックを可能にし、さらに、ドライバ１０３ｃを通じてドアウィンドウ開閉機構を制御することでドアの開閉を可能にする。

制御ＩＣ１０３は、また、車載ＬＡＮ１０１を通じて接続された他の機器に対して現在のドアのロック状態、ドアウィンドウの開閉状態、自動車に加えられた振動の有無を親機２００等に通知する。より具体的には、制御ＩＣ１０３は、ドアのロック状態及びドアウィンドウの開閉状態等の、監視制御対象部位となるドア及びドアウインドウの状態を表すデータを図示しないメモリに保存しておく。そして、制御ＩＣ１０２、親機２００あるいはその他の機器からの要求に応じて、メモリ内のデータを要求元に伝達する。また、この制御ＩＣ１０３には、振動センサが接続されており、自動車１００の振動の検出及びその状態を表すデータ及び検出の履歴の保存もできるようになっている。

制御ＩＣ１０４は、ドライバ１０４ｂを通じてヘッドライトの点灯や消灯等の各種制御を行う。また、制御ＩＣ１０４は、これも監視対象部位の一つとなるタイヤの空気圧を検出するＴＰＭＳ（Tire Pressure Monitoring System）１０４ｃにも接続されている。このように制御ＩＣ１０４は、制御ＩＣ１０２から送信されたデータに応じて室内灯やヘッドライトの点灯／消灯状態を含む自動車の各種状態を検出するとともに、ヘッドライト等の制御を行う。

制御ＩＣ１０４は、また、室内灯の点灯や消灯、ヘッドライトの点灯や消灯等の状態、およびタイヤ圧力等の情報を親機２００等へ通知することができる。より具体的には、制御ＩＣ１０４は、図示しないメモリに室内灯の状態、ヘッドライトの状態、及びタイヤの状態、本実施形態ではタイヤの空気圧を保存して、他の制御ＩＣや親機２００からの要求に応じてこれらの状態を通知するようになっている。

親機２００のＣＰＵ２１２が行う制御処理は、例えば以下のようなものである。
まず、車載ＬＡＮ・Ｉ／Ｆドライバ部２１１を通じて、自動車１００に設置された制御ＩＣ１０３，１０４から、ドアやドアウィンドウ、室内、及びヘッドライト等の状態を表すデータを取得する。その際、ＣＰＵ２１２は、タイマ２１４で計測した受信間隔に基づいて子機３００との間で間欠通信の同期をとり、例えば子機３００からの要求のタイミングに合わせて制御ＩＣ１０３，１０４から上記データを取得する。ＣＰＵ２１２は、また、取得したデータから、自動車１００の状態を表すことができ、かつ、子機３００と通信可能なデータ構造（フォーマット）の通知データを生成する。さらに、微弱無線部２１５を制御して、通知データを子機３００へ送信させる。ＣＰＵ２１２が上記の制御処理行う結果、メモリ２１３には、ＣＰＵ２１２が取得したドア等の状態を表すデータが記録される。

［子機の内部構成］
次に、子機３００の内部構成例を、図４を参照して説明する。
図４において、子機３００には、所定のプログラムによって動作するＣＰＵ３１２が設けられる。ＣＰＵ３１２は、微弱無線部３１５を通じて親機２００との間で双方向通信を行うとともに、微弱無線部３１５を通じて親機２００より取得したデータに関する種々の処理を行う。親機２００より取得したデータ並びにデータ処理の結果は、ＣＰＵ３１２に接続されたメモリ３１３に記録される。ＣＰＵ３１２には、タイマ３１４も接続されている。このタイマ３１４は、親機２００との間で通信の同期をとるために所定間隔となるように信号の出力タイミングを決定するものである。ＣＰＵ３１２は、このタイマ３１４から出力される信号を利用して、親機２００との間で間欠通信を行えるように微弱無線部３１５を制御する。ＣＰＵ３１２には、また、ユーザに対して自動車１００の状態を通知することができるように、ＬＣＤ３２１、ＬＥＤ３２２が所定のインタフェースを介して接続されている。

ＬＣＤ３２１、ＬＥＤ３２２は、視覚化手段の一つとなるもので、ドアやウィンドウの開閉状態、子機３００の電源のオン／オフ状態等の情報を表示するようになっている。ＣＰＵ３１２には、また、所定のインタフェースを介してブザー３２３が接続されており、例えば自動車１００が自動車上荒らしの被害を受けていることが検出されたとき等の異常発生時には、ブザー音を鳴らしてユーザに対して異常事態が発生していることを知らせることができる。ＣＰＵ３１２には、また、所定のインタフェースを介して、子機３００の起動等の、ユーザからの指示入力を受け付けるための入力部としての入力ボタン及びスイッチが接続されている。

以上のように構成される親機２００と子機３００とは、双方向の間欠通信が可能であり、ドアオープンやリモートエンジンスタートなどの、リモートキー等の機能を実行するための子機３００から親機２００への通信のみならず、例えば車上荒らしなどの異常事態による振動を検出した場合には、親機２００から自発的に子機３００ヘ通信を行って異常事態の発生を知らせることが可能となっている。

［通知システムの動作例］
以下、図３，図４に示した親機２００と子機３００との協働によりユーザに対して自動車１００の状態を通知するときの動作例を具体的に説明する。
親機２００と子機３００間では、所在確認などを目的として、間欠通信の同期確立と確立した同期の保持動作とを行う。本実施形態では、同期確立／保持動作を定期的に行うようにしている。例えば子機３００の位置が変わったことによって間欠通信の同期保持を維持できず、通信圏外の状態となった場合、子機３００側では、ＬＣＤ３２１又はＬＥＤ３２２を通じて通信圏外にあることをユーザに知らせる。

親機２００から子機３００へは、自動車１００の現在の状態を表す通知データが送信される。この通知データのフォーマット例を図５に示す。
図示されるように、親機２００から子機３００へと送信される通知データは、１６ビットのＩＤ情報と１６ビットの自動車状態情報とから構成される。ＩＤ情報は、親機２００より取得した通知データを子機３００側で一意に識別するためのものである。自動車状態情報は、本実施形態ではｂｉｔ０〜ｂｉｔ１５の１６ビットであるが、このビット数は、ユーザに通知しようとする情報の種類に応じて任意に設定し、それを事後的に変更することが可能である。各ビットには、それぞれイベントが割り当てられている。ビット値が論理１の時には当該イベントが発生していることが示され、ビット値が論理０のときには、当該イベントが発生していないことが示される。

詳細には、自動車状態情報におけるｂｉｔ０は「自動車の振動あり」、ｂｉｔ１は「ボンネット開閉中」、ｂｉｔ２は「運転席側ドア開閉中」、ｂｉｔ３は「助手席側ドア開閉中」、ｂｉｔ４は「後部座席運転席側ドア開閉中」、ｂｉｔ５は「後部座席助手席側ドア開閉中」、ｂｉｔ６は「トランク開閉中」、ｂｉｔ７は「エンジン始動中」、ｂｉｔ８は「タイヤ空気圧低下」、ｂｉｔ９は「運転席側ドアウィンドウ開閉中」、ｂｉｔ１０は「助手席側ドアウィンドウ開閉中」、ｂｉｔ１１は「後部座席運転席側ドアウィンドウ開閉中」、ｂｉｔ１２は「後部座席助手席側ドアウィンドウ開閉中」、ｂｉｔ１３は「ヘッドライト点灯中」、ｂｉｔ１４は「室内灯点灯中」、ｂｉｔ１５は「ドアロック解除中」という各イベントに対応している。 従って、ｂｉｔ０の値が１の場合には自動車１００に振動が発生していることになる。子機３００においては、親機２００から伝送された通知データのｂｉｔ０の値が１となっている場合、ＬＣＤ３２１やＬＥＤ３２２に所定の表示を行うか、あるいは、ブザー３２３で警報ブザーを鳴らす等の処理を行うことで、自動車１００に振動が発生しており、自動車１００が車上荒らし等にあっているおそれがあることことを伝えることができる。

図６は、子機３００から親機２００へ送信される送出要求データのフォーマット例を示している。図示されるように、子機３００から親機２００への送出要求データは、１６ビットのＩＤ情報と５ビットの要求内容とからなる。ＩＤ情報は、個々の子機３００から伝送されたデータを親機２００側で一意に識別するためのものである。要求内容は、ｂｉｔ０〜ｂｉｔ４の５ビットよりなるが、このビット数は、ユーザが通知を要求しようとする情報の種類に応じて任意に設定し、それを事後的に変更することが可能である（但し、変更する場合には、親機２００側との間で調整が必要となる）。各ビットにはイベントが割り当てられ、ビット値が１の時には当該イベントの発生を要求していることが示される。ビット値が０のときには、当該イベントの発生は要求されていないことが示される。

詳細には、要求内容におけるｂｉｔ０は「集中ドアロック要求」、ｂｉｔ１は「集中ドアロック解除（アンロック）要求」、ｂｉｔ２は「リモートエンジンスタート要求」、ｂｉｔ３は「リモートエンジン停止要求」、ｂｉｔ４は「自動車体状況確認要求」を示す。
自動車の状態通知においては、親機２００から子機３００への通信と、子機３００から親機２００への通信との双方が生じる。

親機２００から子機３００への通信においては、自動車に設置された親機２００が、自動車１００の状態の検出結果に応じて、ユーザが携帯する子機３００へ自発的に通知データを送信する。この場合、子機３００では、通知データを受信して、ＬＥＤ３２１やＬＣＤ３２２あるいはブザー３２３等を通じてユーザに対して自動車１００の状態を通知する。一方、子機３００から親機２００への通信においては、ユーザが携帯する子機３００から親機２００に対して送出要求データが送信され、これに応答して、親機２００では自動車１００のドアロックやウィンドウの開閉等の制御や、自動車１００の状態を子機３００に送信する等の処理を行う。
本実施形態では、これらいずれの場合においても親機２００と子機３００との間の通信は、間欠的に行われる。

図７は、親機２００と図６に示した送出要求データを送信する子機３００との間で行われる通信のタイミング説明図である。この図において、親機２００と子機３００との通信同期が確立されていない非同期の状態では、親機２００は、連続受信状態であり、子機３００からのデータ送信を待ち受ける状態（図中「Ｒ」で示される）となっている。Ｔ１で示される最初の送受信時においては、図７の一番左の下向きの矢印に示されるように、非同期状態で、子機３００が送信状態（図中Ｔで示される）となる。すなわち、自己のＩＤ情報及び図６に示される要求内容を所定のフォーマットに載せた送出要求データを親機２００へ送信する。待機状態となっている親機２００は、子機３００からの送出要求データを受信すると、それに含まれるＩＤ情報をもとに認証を行う。

子機３００は、送出要求データを送信した後は待機状態となる。一方、親機２００は、上記の認証が正常であることを条件として、子機３００からの送出要求データを受信すると通知データを子機３００へ送信する（送信状態）。すなわち、自己のＩＤ情報及び図６に示される自動車状態情報を所定のフォーマットに載せた通知データを送信し、その後は、間欠受信状態に移る。待機状態にある子機３００は、この検知データを受信すると、それに含まれるＩＤ情報の認証を行い、正常であることを条件として、自動車状態情報を得る。以降は、間欠送信状態に移行する。

間欠タイミングで行われる親機２００と子機３００の通信状態は、図８に示されるとおりである。すなわち、子機３００は、（図中のＴｘスロットで示される）送信状態において、送出要求データを親機２００へ送信する。親機２００は、（図中のＲｘスロットで示される）受信状態において、子機３００から送信された通知データを受信すると、自動車１００の状態を検出し、検出結果を自動車状態情報として、これにＩＤ情報を付加した通知データを生成し、この通知データを子機３００へ送信する（送信状態となる）。なお、受信状態の期間中、子機３００からの送出要求データを受信しなかった場合、親機２００は送信状態とはならず、そのまま待機状態を継続する。
以上のように、親機２００と子機３００との間で相互にＩＤ情報に基づく認証がなされ、それが正常であるときに両者の通信同期が確立され、以降は、それぞれ間欠送受信動作に移行する。

間欠送受信動作においても、所定の間欠タイミングによって、相互のＩＤ情報及び送出要求データ又は通知データの送受信を行うことにより、親機２００と子機３００は、相互に同期の保持を図る。そして、親機２００は、自動車状態の逐次通知を行う。
なお、自動車状態は、頻繁には変化しないのが一般的なので、消費電力を低減するために、間欠送受信の間隔（第１間隔）を例えば数秒〜数十秒程度に長くしても良い。
また、親機２００と子機３００における受信動作間隔を同じにしても良いが、そうすると、上記のように間欠送受信の間隔が長すぎたときにユーザの利便性が損なわれることも予想される。例えば、ユーザが任意の時点で自動車１００のドアのロック、アンロックを行うことができなくなるおそれがある。

そこで、本実施形態では、親機２００の受信動作間隔は１フレーム０．５秒とし、０．５秒間隔（第２間隔）でデータを受信できるようにした。他方、子機３００の受信動作間隔は、親機２００との通信同期を確立した後、通常時は４フレーム毎、すなわち２秒間隔とし、例えばユーザから任意の時点で指示入力があった臨時動作時には０．５秒間隔となるようにした。この場合、子機は、親機２００に送出要求データを送信してから、親機２００からこの送出要求データに応答した通知データが送信されてくるまでは、０．５秒間隔で動作する。これにより、通常動作時には消費電力を低減しつつ、任意の時点でユーザからの指示入力（例えば、自動車１００のドアのロック、アンロックの指示）にも柔軟に対応できるようになる。
図８には、親機２００が受信状態のときに子機３００からデータが送信され、それが親機２００において受信されると、親機２００は、それに直ちに呼応して子機３００へ通知データが送信されることが示されている。

図９には、子機３００に対してユーザから指示入力があったときの子機３００の動作状態を示している。子機３００は、ユーザからの指示入力後の最初のフレームで送出要求データを送信する。子機３００からの送出要求データを受信した親機２００は、この送出要求データに応答して、必要に応じて自動車１００のドアのロック／アンロックを行う等の車内制御を行ない、必要であれば、通知データを子機３００へと送信することで、ドアウインドウやライトの状態を子機３００に通知する。親機２００では、車内制御後の最初のフレームで子機３００へと通知データを送信する。本実施形態では、図９に示されるように、１フレーム以内に車内制御を完了し、子機３００から送出要求データを受信した次のフレーム（０．５秒後）に通知データを送出している。このような動作を可能にする構成とすることで、子機３００は、通常動作時は２秒間隔で親機２００と送受信を行なう一方で、ユーザからの指示入力による臨時動作時には０．５秒以内に親機２００と送受信を行うことができる。

また、本実施形態では、子機３００からの送出要求データを受信してから親機２００が、自動車１００の状態を速やかに子機３００に通知できるようにするために、親機２００で定期的に自動車１００の状態を表すデータ（以下、「ステータス」という）を取得したうえで、子機３００との間の通信時に、自動車１００の最新の状態を表す通知データを子機２００へ送信することができる。この場合は、親機２００と子機３００との間でデータの受け渡しが行われていないときに、親機２００（ＣＰＵ２１２）が、制御ＩＣ１０３、１０４に対してドアや室内灯等のステータスを要求して、各ステータスを予め検出して保存しておくことが好ましい。

親機２００では、子機３００から送信される送出要求データに呼応した動作を行う他に、定期的に自動車１００の状態を検出する。また、自動車１００の状態に変化があった場合には、状態確認後の最初のフレームで、子機３００に対して当該変化を送信する。
図１０は、親機２００における状態確認動作のタイミングの説明図である。図示のように、親機２００では、子機３００に対する、あるフレームと次のフレームとの間に、ＣＰＵ２１２から車載ＬＡＮ・Ｉ／Ｆドライバ部２１１および車載ＬＡＮ１０１を介して制御ＩＣ１０２〜１０４とデータの受け渡しを行う。すなわち、ＣＰＵ２１２は、図５のｂｉｔ０〜ｂｉｔ１５で示されるイベント毎に、順次対応する制御ＩＣにリクエストを出し、その制御ＩＣからステータスを受け取る。

例えば、ＣＰＵ２１２は、通知データのｂｉｔ０の「振動有り」というイベントのステータスを知るために、車載ＬＡＮ１０１を通じて制御ＩＣ１０３にステータスを送出するようにリクエストを出し、制御ＩＣ１０３から振動に関するステータスを受け取る。同様に、ｂｉｔ１の「ボンネット開閉中」というイベントに関しても、制御ＩＣ１０３にリクエストを出し、ステータスを受け取る。
このようにして、通知データのｂｉｔ０〜ｂｉｔ１５のそれぞれに対応するイベントのステータスを、順次制御ＩＣ１０３又は制御ＩＣ１０４より受け取る。このようにして受け取ったステータスをもとに通知データを生成し、次回の子機３００との通信時にこの通知データを子機３００に送信することで、自動車１００のステータスが子機３００に伝達される。

図１１に、状態確認動作中に、親機２００のＣＰＵ２１２と制御ＩＣ１０３、１０４との間で受け渡されるデータ（内部通信データ）のフォーマット例を示す。内部通信データは、データ先頭部から、順次、スタートビット、送信元デバイス識別ＩＤ、送信先デバイス識別ＩＤ、Ｒ／Ｗビット、ＡＣＫビット、対象部識別ＩＤ、Ｒ／Ｗデータ、ストップビットとなっている。

スタートビットは、受け渡しの対象となるデータの開始部分がどれかを識別するためのものである。送信元デバイス識別ＩＤ、送信先デバイス識別ＩＤは、それぞれ、ＣＰＵ２１２や制御ＩＣ１０２のようなデバイス毎に割り当てられるＩＤであり、これにより、送信元デバイスと送信先デバイスとをそれぞれ識別することが可能となっている。この例では送信元デバイスはＣＰＵ２１２、送信先デバイスは制御ＩＣ１０３、１０４が対応し、例えばＣＰＵ２１２には値「００００」、制御ＩＣ１０３には「０００１」、制御ＩＣ１０４には「０００２」が割り当てられている。

Ｒ／Ｗビットは、ステータス確認／制御要求のための識別ビットである。本実施形態では、ステータスを確認する場合にはこのビットの値を「０」、ドアのロック／アンロックのように、対象の制御を要求する場合には、このビットの値を「１」とする。
ＡＣＫビットは、前回のデータを正常に受信できたかどうかを表す確認用のビットである。例えばデータを正常に受信したときは「１」、受信できなかったときは「０」とする。

対象部識別ＩＤは、一つの制御ＩＣ内に複数の対象部品がある場合に、これらの対象部品を個々に識別するためのＩＤである。本実施形態においては、制御ＩＣ１０４において室内灯とヘッドライトとを制御しているので、室内灯、ヘッドライトのそれぞれに識別ＩＤを付している。
Ｒ／Ｗデータは、上述したＲ／Ｗビットが「１」の場合は、制御対象の制御要求データを表す。この制御対象要求データは、ＣＰＵ２１２から制御ＩＣ１０３又は制御ＩＣ１０４に対して送信されるものであり、また、この実施形態では、Ｒ／Ｗデータを５ビットのデータとした。例えば、ＣＰＵ２１２がドアロック機構にドアロックを行うことを要求する場合には、Ｒ／Ｗデータの値は０００１となる。また、ドアのロック状態を変更せずに現在の状態を維持する場合には、Ｒ／Ｗデータの値は「０００１」となる。一方、Ｒ／Ｗビットが「０」の場合、Ｒ／Ｗデータは、制御ＩＣ１０３、１０４からＣＰＵ２１２にステータスを回答する場合におけるステータス回答データを表す。例えば、自動車１００の室内灯が点灯している場合には、Ｒ／Ｗデータの値は「００００」、消灯している場合にはＲ／Ｗデータの値は「０００１」となる。
ストップビットは、受け渡しの対象となるデータの終了部分がどれかを識別するためのものである。

このようなフォーマットの内部通信データを親機２００のＣＰＵ２１２と、制御ＩＣ１０３、制御ＩＣ１０４と、の間で受け渡しすることで、ＣＰＵ２１２が自動車１００のドアや室内灯のステータスを求めるためのリクエストを制御ＩＣ１０３、１０４に出し、また、制御ＩＣ１０３、１０４からＣＰＵ２１２に対してステータスを回答することができる。

次に、親機２００のＣＰＵ２１２及び子機３００のＣＰＵ３１２における制御処理動作を説明する。
図１２は、ＣＰＵ２１２の動作手順図である。
ＣＰＵ２１２は、親機２００の電源がオンの状態になったことを検知すると（Ｓ１０１）、子機３００と同期が確立されているかどうかを判定する（Ｓ１０２）。同期が確立されていない場合（Ｓ１０２；Ｎ）、ＣＰＵ２１２は、子機２００との同期をとるために、同期捕捉処理を行う（Ｓ１０３）。この同期捕捉処理では、ＣＰＵ２１２は、先に図７に示したように待機状態となり、子機３００から送出要求データが送信されたことを契機に子機３００との同期をとる（捕捉する）。同期捕捉処理を終えた後は、Ｓ１０２に戻り、再度同期中か否かを判定する。
Ｓ１０２において同期中であると判定された場合（Ｓ１０２；Ｙ）、ＣＰＵ２１２は、子機３００からの送出要求データが送信されたか否かを判定する（Ｓ１０４）。送出要求データが送信されていない場合は（Ｓ１０４；Ｎ）、イベントが発生したか否かを判定する（Ｓ１０５）。この判定処理において、ＣＰＵ２１２は、図１０に示した自動車１００の状態確認動作のための処理を行ない、その処理結果を前回の状態確認動作のための処理結果と比較する。比較の結果、状態に変化があった場合（Ｓ１０５；Ｙ）には、イベント（自動車の状態が変化した事実）が発生したと判定し、変化した状態の内容をイベント事項として子機３００へ送信し（Ｓ１０６）、Ｓ１０２に戻る。
状態に変化がない場合（Ｓ１０５；Ｎ）は、そのまま同期を保持し（Ｓ１０７）、Ｓ１０２に戻る。

ＣＰＵ２１２において上記の処理を行うことで、自動車１００が車上荒らし等の異常事態にあって、自動車１００に異常な振動が生じたり、ユーザが閉めたはずのドアが開けられたりした場合、状態変化が生じる。この場合は上記のＳ１０５での判定結果は「Ｙ」となり、変化した状態の内容が子機３００へ通知される。
子機３００では、自動車１００の状態に変化が生じたことを、画面表示、警告ランプ、警告音、あるいは子機３００自体を振動させる等、任意の手法でユーザに伝える。このようにして、親機２００は、自動車１００の状態を子機３００に通知してユーザに伝えることができる。

一方、Ｓ１０４において、子機３００から送出要求データが送信されている場合、ＣＰＵ２１２は、当該送出要求データの図６に示されるフォーマットにおける各ｂｉｔ０〜４の値を検出し、子機３００に対し返信が必要とされているか否かを検出する（Ｓ１１０）。本実施形態では、子機３００に対して返信が必要となるのは、ｂｉｔ４の値が「１」であるときだけである。従って、ＣＰＵ２１２は、送出要求データの要求情報におけるｂｉｔ４の値が「１」か「０」かを検出し、この値が「０」である場合には、返信は必要ないと判定し（Ｓ１０８；Ｎ）、ｂｉｔ０〜３の値に応じて要求情報に従った制御を自動車１００に対して行い（Ｓ１０９）、Ｓ１０２に戻る。
子機３００への返信が必要であった場合（Ｓ１０８Ｙ）、ＣＰＵ２１２は、要求情報に従った制御を行うとともに、制御ＩＣ１０３、制御ＩＣ１０４から、ドアロック等のステータスを受け取り（Ｓ１１０）、子機３００に通知データを送信した上で（Ｓ１１１）、Ｓ１０２に戻る。

図１３は、子機３００のＣＰＵ３１２の動作手順図である。
ＣＰＵ３１２は、子機３００の電源がオンの状態になったことを検知すると（Ｓ２０１）、親機２００と通信の同期が確立されているかどうかを判定する（Ｓ２０２）。同期が確立されていない場合は（Ｓ２０２；Ｎ）、親機２００との間で通信の同期をとるために、同期捕捉処理を行う（Ｓ２０３）。この同期捕捉処理では、子機２００は、先に図７に示したように親機２００に送出要求データを送信し、親機２００から通知データが返信送信されたことを契機に親機２００との同期を捕捉する。同期捕捉処理を終えた後は、Ｓ２０２に戻り、再度、同期中か否かを判定する。
Ｓ２０２において同期中であると判定された場合（Ｓ２０２；Ｙ）、ＣＰＵ３１２は、親機２００から通知データが送信されたか否かを判定する（Ｓ２０４）。通知データが送信されていない場合（Ｓ２０４；Ｎ）、ユーザからの指示入力があったかどうか、つまり送出要求データの送信を要求されたか否かを判定する（Ｓ２０５）。要求されていない場合（Ｓ２０５；Ｎ）、ＣＰＵ３１２は、そのまま同期を保持する。
ユーザからの指示入力があった場合は、送出要求データを親機２００へ送信する（Ｓ２０７）。一方、親機２００から通知データが送信されている場合（Ｓ２０４；Ｙ）、その内容を子機３００のディスプレイやＬＥＤに表示するか、あるいは警報ブザーをならす等の処理を行ない、ユーザに対して、親機２００から得られた自動車１００の車内状況を伝えるための処理を行ってＳ２０２に戻る。

このように、本実施形態の通知システムでは、親機２００は、自動車１００の状態を検出し、状態に変化があった場合には、子機３００を通じてユーザに対してその変化を通知することができるので、親機２００と子機３００との協働により、自動車１００のセキュリティを高めることができる。通知データには、自動車１００の振動、エンジンの始動、ドアの開閉等を表すデータが含まれる。これらは、通常はユーザが自動車１００から離れているときには起こりえないものであり、これらが生じたということは、車上荒らし等により自動車１００が何らかの異常事態や危険にさらされている可能性が高いことになる。

［子機の外観構成］
子機３００は、種々の形態の容器に収容して実施することができる。子機３００の容器の外観構成例を図１４に示す。図１４に例示される子機３００の容器には、アンテナ３４０、ディスプレイ３５０、集中ドアロックボタン３６０、集中ドアアンロックボタン３６１、リモートエンジンスタートボタン３６２、リモートエンジンストップボタン３６３、車体状況確認ボタン３６４、スピーカ３７０が設けられている。

アンテナ３４０は、図４に示した子機３００の微弱無線部３１５に接続されており、アンテナ３４０を通じて親機２００との間で微弱無線による双方向通信が可能となっている。ディスプレイ３５０には、アイコンＩ１、Ｉ２、Ｉ３、Ｉ４が表示されている。アイコンＩ１、Ｉ２、Ｉ３、Ｉ４は、それぞれ通信電波強度、室内灯のオン／オフ、ドアのロック状態、温度を表している。また、ディスプレイ３５０には、自動車１００の概観が線図で表示されており、自動車１００において、トランクや助手席側ドアの開閉等があった場合、その開閉箇所がこの線図で強調表示されるようになっている。例えば、図５に示した状態通知データにおいて「運転席側ドアウィンドウ開閉中」に対応したｂｉｔ９が「１」となっていた場合には、この自動車の概観を示す線図における運転席側ドアウィンドウの部分を強調表示する。このような表示処理自体は、公知の技術を用いることができる。

集中ドアロックボタン３６０、集中ドアアンロックボタン３６１、リモートエンジンスタートボタン３６２、リモートエンジンストップボタン３６３、車体状況確認ボタン３６４は、それぞれ、ユーザがそれらを押すことにより、該当する指示入力をＣＰＵ３１５に伝達するためのものである。すなわち、リモートエンジンスタート／ストップボタン３６２，３６３は、自動車１００のエンジンのスタート／ストップの制御を車外より親機２００に行わせるものであり、車体状況確認ボタン３６４は、親機２００に対して自動車１００の現在の状態を通知させるためものである。

スピーカ３７０は、自動車１００の状態に変化が生じたことを音で伝えるためのものであり、例えばブザーや警告音声等によって、状態の変化をユーザに伝える。
なお、子機３００における消費電力を小さく抑えるために、子機３００の外観を図１５に示されるようなものとしても良い。この例においては、上述した集中ドアロック／アンロックボタン３６０，３６１を一つのボタン３６５で兼用し、一回押すとドアロック、二回押すとアンロックとなるようにしている。同様に、上述したエンジンスタート／ストップボタン３６２，３６３も一つのボタン３６６で兼用している。更に、ディスプレイ３５０を省き、これに代えてＬＥＤ３９０〜３９８を配置している。

ＬＥＤ３９０は、緊急状態を示すものであり、例えば親機２００からの通知データによって、「振動有り」、「トランク開閉中」等の複数のイベントが生じていて自動車１００が車上荒らしにあっている可能性が高いと判断される場合に、ＬＥＤ３９０が例えば赤く点灯するとともにブザー音がスピーカ３７０から発せされる。このように緊急状態を検出する場合、図４に示される子機３００のＣＰＵ３１２では、親機２００から送信された通知データの各ｂｉｔの値を検出し、自動車１００が車上荒らしにあっていると判定するための所定の条件を満たす場合に緊急状態と判定する。この条件としては、「自動車１００で検出されるステータスのうち所定数以上、例えば２つ以上のステータスが変化していた場合」、あるいは「特定のステータス、例えば空気圧低下（図４のｂｉｔ８に対応）が生じていた場合」等、任意に設定することができる。

ＬＥＤ３９１は、電波圏内／圏外を示すものであり、圏内にある場合には例えば緑に発光し、圏外では消灯状態となる。ＬＥＤ３９２，３９３はエンジンの状態を示すものであり、エンジンが停止中であればＬＥＤ３９２が緑に発光し、始動中であればＬＥＤ３９３が赤に発光する。ＬＥＤ３９４、３９５はドア状態を示すものであり、ドアが閉じていればＬＥＤ３９４が緑に、ドアが開閉中であればＬＥＤ３９５が赤に発光する。ＬＥＤ３９６，３９７は、ヘッドライトの状態を示し、ヘッドライトが消灯していればＬＥＤ３９６が緑に、点灯していればＬＥＤ３９７が赤に発光する。

子機３００の容器を以上のように構成することで、子機３００では、親機２００から送信された通知データより得られた自動車１００の状態を、ユーザに対して視覚的に伝えることができる。また、ユーザは、各種ボタン３６０〜３６６を通じて、自動車１００に対する所望の監視制御を車外より親機２００に行わせることができる。

＜第１変形例＞
以下、実施形態の変形例を示す。上述した実施形態では、親機２００と子機３００とが間欠タイミングで送受信を行う際に、図５，６に示されるように、ＩＤ情報だけでなく通知情報、要求内容をも同時に送受信していた。送受信されるデータ量が大きくなると、送受信に要する時間が長くなり、消費電力が増大することで電池寿命が短くなるおそれがある。そこで、通常動作時には、図１６に示されるように、通知データ及び送出要求データではＩＤ情報のみが送受信され、自動車１００が振動していることやトランクの開閉中であることが検出されて自動車１００の車内状況に変化が生じるというイベントが発生した場合のみ、通知データ又は送出要求データがＩＤ情報と共に送受信されるようにしても良い。
このようなイベントが発生した場合、親機２００のＣＰＵ２１２は、イベントが発生した後の最初のデータ送信時に、イベント発生を表す情報が親機２００から子機３００へ送信されるようにする。従って、自動車１００が車上荒らし等にあって車内状況が変化した場合には、親機２００から子機３００へと、ＩＤ情報に加えて通知データが送信される。子機３００では、この状況の変化に応じて画面表示を変化させたり、警報ブザーをならしたりすることで、ユーザに対して車内状況の変化を通知することができる。
なお、子機３００に対してユーザから指示入力があったときの子機３００、親機２００の動作タイミングは、上記実施形態と同様であり、図９に示した動作タイミングと同様のものとなる。

以上の説明から明らかなように、本発明では、親機２００と子機３００との間で双方向の通信を行うことで、ドアのロック／アンロックやリモートエンジンスタート／ストップといった片方向の機能だけでなく、離れた場所からの自動車１００の状態確認や緊急時のリアルタイム通知などの機能を実現することができ、ユーザから見た場合の使い勝手を大幅に向上させることができる。

また、本実施形態では、親機２００は、車載ＬＡＮ１０１に接続する形態を採用しており、車載ＬＡＮ１０１はそのＩ／Ｆコネクタが自動車内に常設されているため、比較的その取り付けが容易であり、導入時の煩わしさも無い。
親機２００と子機３００の通信は、微弱無線を用い、特別の免許を必要としない周波数帯を用いているので、普及への煩わしさを回避し、微弱な消費電力により電池の持ちを大幅にアップさせることも可能となる。このため、使用する電池の大きさをより小さくすることで子機３００の小型化も実現可能となる。
また、大きな電力を必要としないため、回路構成の簡略化が可能となり、システム全体のコストダウンを実現することが可能となる。

本発明に係る自動車の状態通知システムの概略説明図。 本発明に係る自動車の状態通知システムの概略説明図。 親機の概略的な機能ブロック図。 子機の概略的な機能ブロック図。 通知データのフォーマット説明図。 送出要求データのフォーマット説明図。 親機と子機との間欠送受信タイミング説明図。 親機と子機との間欠送受信タイミング説明図。 子機から親機への送信タイミング説明図。 車内状況確認動作のタイミング説明図。 内部通信データのフォーマット説明図。 親機の処理動作のフローチャート。 子機の処理動作のフローチャート。 子機の外観図。 子機の変形例を示す外観図。 他の実施形態における親機と子機との間欠送受信の説明図。

符号の説明

１００ 自動車
１０１ 車載ＬＡＮ
１０２〜１０４ ＩＣ
１０３ａ、１０３ｂ、１０３ｃ、１０４ｂ ドライバ
２００ 親機
２１１ ドライバ部
２１２ ＣＰＵ
２１３ メモリ
２１４ タイマ
２１５ 微弱無線部
３００ 子機
３１２ ＣＰＵ
３１３ メモリ
３１４ タイマ
３１５ 微弱無線部
３２１ ＬＣＤ
３２２ ＬＥＤ
３２３ ブザー
３４０ アンテナ
３５０ ディスプレイ
３６０ アンロックボタン
３６０ 集中ドアロックボタン
３６０〜３６６ 各種ボタン
３６１ 集中ドアアンロックボタン
３６２ ストップボタン
３６２ リモートエンジンスタートボタン
３６３ リモートエンジンストップボタン
３６４ 車体状況確認ボタン
３７０ スピーカ
３９０〜３９８ ＬＥＤ

Claims (12)

1. 携帯端末装置との間で、法律の規制を受けない微弱電力による双方向の間欠通信を行う無線通信手段と、
   この無線通信手段を通じて前記携帯端末装置から監視の対象となる車両の現在の状態を表す情報の送出要求を受け付ける送出要求受付手段と、
   この送出要求受付手段で受け付けた送出要求に対応する車両の状態について所定のセンサが検知した検知結果を取得する車両状態検知手段と、
   この車両状態検知手段が取得した検知結果を表す所定のデータ構造の通知データを前記携帯端末装置が受信可能な間隔で間欠送信するように前記無線通信手段の動作を制御する制御手段と、を備えて成る、
   車両状態の通知装置。
2. 前記携帯端末装置より間欠的に受信した信号の間隔を計測するタイマをさらに備えており、前記制御手段は、前記タイマにより計測された間隔に基づいて前記携帯端末装置との間で行う間欠通信の同期を確立するように前記無線通信手段を制御する、
   請求項１記載の通知装置。
3. 前記制御手段は、同期を確立した後の前記間隔を保持しており、この保持されている間隔とその後の受信時に前記タイマにより計測された間隔との比較に基づいて前記同期が維持されているかどうかを判定する、
   請求項２記載の通知装置。
4. 前記車両状態検知手段は、前記センサの検知結果を前記携帯通信端末との間欠通信の通信タイミングとは無関係なタイミングで収集して所定のメモリに蓄積しておき、前記送出要求があったときに当該送出要求に対応する車両の状態について蓄積されている検知結果を前記メモリより読み出すように構成されている、
   請求項１記載の通知装置。
5. 前記車両状態検知手段は、前記センサの検知結果を周期的に取得するとともに取得した各周期の検知結果を前記メモリに蓄積しておき、前周期で取得した検知結果と今周期で取得した検知結果とを比較することにより、車両状態の変化の有無を表す情報を生成するように構成されている、
   請求項４記載の通知装置。
6. 前記制御手段は、前記間欠通信に際して、前記車両状態検知手段より前記変化の有無を表す情報を取得し、車両状態に変化が有るときは、その旨を表す前記通知データを、当該変化が生じた直後に通信可能となるタイミングで前記携帯端末装置へ送信するように前記無線通信手段を制御する、
   請求項５記載の通知装置。
7. 要求に応じて車両状態を通知する通知装置との間で、法律の規制を受けない微弱電力による双方向の間欠通信を行う無線通信手段と、
   この無線通信手段を通じて前記通知装置に対して監視の対象となる車両の現在の状態を表す通知データの送出を要求するための送出要求データを生成する送出要求データ生成手段と、
   この送出要求データ生成手段で生成した送出要求データを予め自装置に割り当てられた間隔で前記通知装置に間欠送信するとともに、自装置宛の前記通知データを受信するように前記無線通信手段の動作を制御する制御手段と、を備えて成る、
   携帯端末装置。
8. ユーザからの指示入力を受け付ける指示入力受付手段をさらに備えており、
   前記送出要求データ生成手段は、前記指示入力受付手段が、ユーザが前記車両における複数の監視対象部位のいずれかの部位に対する前記要求を受け付けたときに、当該要求に応じた内容の送出要求データを生成する、
   請求項７記載の携帯端末装置。
9. 前記制御手段は、前記通知装置との同期確立後は第１間隔を維持して前記間欠送信を行い、ユーザからの指示入力を受け付けた緊急時には前記第２間隔よりも短い第２間隔で前記間欠送信を行うように前記無線通信手段を制御する、
   請求項８記載の携帯端末装置。
10. 前記制御手段によりその動作が制御され、前記受信した通知データが表す車両の状態を視覚的にユーザに伝達する視覚化手段をさらに備えて成る、
    請求項７、８又は９記載の携帯端末装置。
11. 請求項１乃至６のいずれかの項記載の通知装置と、請求項７乃至１０のいずれかの項記載の携帯端末装置とを含む、
    車両状態の通知システム。
12. それぞれ、法律の規制を受けない微弱電力による双方向の間欠通信を行う無線通信手段を備えた通知装置及び携帯端末装置が実行する方法であって、
    前記携帯端末装置が、監視の対象となる車両の現在の状態を表す通知データの送出を要求するための送出要求データを、自装置に割り当てられた間隔で前記通知装置へ間欠送信する段階と、
    前記通知装置が、前記送出要求データの受信を契機に当該携帯端末装置との間で間欠通信の同期を確立するとともに、前記車両の状態について所定のセンサが検知した検知結果を表す所定のデータ構造の通知データを、同期を確立した前記携帯端末装置が受信可能な間隔で間欠送信する段階と、
    前記通知データを受信した前記携帯端末装置が、前記通知データにより特定される車両の状態を視覚的に表現してユーザに伝達する段階とを有する、
    微弱無線による車両状態の通知方法。

Images