JP6747081B2 - 車載装置及びコンピュータプログラム - Google Patents

Description

本発明は、自動車等の車両に搭載される車載装置等に関する。

自動車等の車両の盗難を防止するシステムが提案されている。例えば、特許文献１には、自動車に搭載された車載無線機と、基地局無線機とが近距離無線通信を行い、車載無線機との通信が途切れた場合、又は自動車の移動を検出した場合、自動車が盗難されたと判定する盗難監視システムが記載されている。

特許文献２には、ドライバが携行する発信器が、車内に設けた受信器から遠ざかり、発信器の発信信号を受信器が受信できなくなった時点で、盗難防止状態となり、車両は、エンジンの駆動電源が遮断されて動かなくなる自動車盗難防止装置が記載されている。

特開２００７−２４１９８０号公報 特開２００４−６６９６２号公報

しかしながら、特許文献１に記載の盗難監視システムや、特許文献２に記載の自動車盗難防止装置では、通信が途切れたことのみで盗難を判定するので、誤報のおそれがある。

本発明は、このような事情に鑑みてなされたものであり、車両の盗難を精度良く検出可能な車載装置等を提供することを目的とする。

本発明に係る車載装置は、車両が移動しているか否か判定する移動判定部と、予め登録された携帯通信機と近距離無線通信により交信を行う交信部と、前記移動判定部が、前記車両が移動していると判定した場合、前記交信部が前記予め登録された携帯通信機との交信に成功したか否かを判定する交信判定部と、前記交信判定部が交信に成功していないと判定した場合、警報を出力する出力部と、遠隔操作器を用いて前記車両のドアが解錠された旨を受信する受信部とを備え、前記交信判定部は、前記受信部が、前記遠隔操作器を用いて前記車両のドアが解錠された旨を受信した後、前記交信部を動作させず、前記交信部が前記予め登録された携帯通信機との交信に成功した場合、所定の条件が満たされるまで、前記交信部を動作させないことを特徴とする。

本発明にあっては、車両が移動している判定した場合に、予め登録した携帯通信機との交信を試みるので、盗難を精度良く検出可能となる。
また、本発明にあっては、予め登録した携帯通信機と交信に成功した後、交信判定部は交信部を動作させない。それにより、車両が停止状態から移動状態に遷移する毎に、交信部は動作しないので、電力などのリソースを節約することが可能となる。
さらに、本発明にあっては、遠隔操作器を用いてドアが解除された後には、交信部を動作させない。それにより、携帯通信機との通信を省略するので、電力などのリソースを節約することが可能となる。

本発明に係る車載装置は、前記予め登録された携帯通信機は複数であることを特徴とする。

本発明にあっては、予め登録した携帯通信機を複数とすることにより、複数のドライバで共有する車両であっても、運用可能となる。

本発明に係る車載装置は、前記交信部を動作させていない継続時間を算出するタイマ部を備え、前記交信判定部は、前記継続時間が所定時間を超えた旨を前記タイマ部より通知された場合、前記交信部を動作させ、前記予め登録された携帯通信機との交信に成功したか否かを判定することを特徴とする。

本発明にあっては、交信部を動作させていない継続時間が、所定時間以上となったときは、交信部を動作させ、予め登録した携帯通信機と交信が可能か否かを判定する。それにより、車両が所定時間以上、運行している場合に、運行途中に盗難されても、それを検知することが可能となる。

本発明に係る車載装置は、前記交信判定部は、前記交信部が、前記予め登録された携帯通信機から停止命令を受信した場合は、前記予め登録された携帯通信機から再開命令を受信するまで、前記交信部を動作させないことを特徴とする。

本発明にあっては、予め登録した携帯通信機から停止命令を受信したときは、再開命令を受信するまでは、交信部を動作させない。それにより、ドライバ以外が車両を走行させなければならない場合に、不必要に警告が出力されることを抑制できる。

本発明に係るコンピュータプログラムは、車両の移動を検出し、移動を検出した場合、予め登録された携帯通信機と近距離無線通信による交信を試み、前記予め登録された携帯通信機との交信に成功しなかった場合、警報を出力する処理を車載装置に行わせるコンピュータプログラムであって、遠隔操作器を用いて前記車両のドアが解錠されたと判定した後、前記携帯通信機との交信を試みず、前記予め登録された携帯通信機との交信に成功した場合、所定の条件が満たされるまで、前記携帯通信機との交信を試みないことを特徴とする。

本発明にあっては、車両が移動している判定した場合に、予め登録した携帯通信機との交信を試みるので、盗難を精度良く検出可能となる。
また、本発明にあっては、予め登録した携帯通信機と交信に成功した後、交信判定部は交信部を動作させない。それにより、車両が停止状態から移動状態に遷移する毎に、交信部は動作しないので、電力などのリソースを節約することが可能となる。
さらに、本発明にあっては、遠隔操作器を用いてドアが解除された後には、交信部を動作させない。それにより、携帯通信機との通信を省略するので、電力などのリソースを節約することが可能となる。

本発明にあっては、盗難を精度良く検出可能であり、また、電力などのリソースを節約することが可能となる。

車両盗難通報システムの構成を示す説明図である。 端末ＩＤテーブルのレコードレイアウトを示す説明図である。 車載装置が行うメイン処理の手順を示すフローチャートである。 交信処理の手順を示すフローチャートである。 車載装置の他の構成例を示すブロック図である。 交信済みフラグテーブルのレコードレイアウトを示す説明図である。 メイン処理の手順を示すフローチャートである。 交信済み判定処理の手順を示すフローチャートである。 車両盗難システムの他の構成を示す説明図である。 連携処理の手順を示すフローチャートである。 機能停止／再開処理の手順を示すフローチャートである。 交信済み処理の手順を示すフローチャートである。 交信済み処理の手順を示すフローチャートである。 車載装置の機能構成を示すブロック図である。

以下、図面を用いて、実施の形態を具体的に説明する。なお、以下の説明において、車両とはエンジン内蔵の自動車を想定しているが、それに限らない。電気自動車、ハイブリット車、バイク、原動機付自転車などにも適用可能である。

（実施の形態１）
図１は車両盗難通報システム１０の構成を示す説明図である。車両盗難通報システム１０は、車載装置１、車両制御装置２、携帯端末（携帯通信機）３を含む。

車載装置１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３、近距離通信部１４、大容量記憶装置１５、計時部１６、ＣＡＮ通信部１７、通信部１８を含む。各構成はバスＢで接続されている。

ＣＰＵ１１はＲＯＭ１２に記憶された制御プログラム（コンピュータプログラム）１Ｐに従いハードウェア各部を制御する。ＲＡＭ１３は例えばＳＲＡＭ（Ｓｔａｔｉｃ ＲＡＭ）、ＤＲＡＭ（Ｄｙｎａｍｉｃ ＲＡＭ）、フラッシュメモリである。ＲＡＭ１３はＣＰＵ１１による制御プログラム１Ｐの実行時に発生するデータを一時的に記憶する。

近距離通信部１４は、ＮＦＣ（Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）規格、ブルートゥース（Ｂｌｕｅｔｏｏｔｈ（登録商標））規格、赤外線通信（ＩｒＤＡ（Ｉｎｆｒａｒｅｄ Ｄａｔａ Ａｓｓｏｃｉａｔｉｏｎ）規格、ＷｉＦｉ（登録商標）規格などにしたがった通信を行う。

大容量記憶装置１５は、例えばハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などである。大容量記憶装置１５は、後述する端末ＩＤテーブル１５１を記憶する。大容量記憶装置１５は、ＲＡＭ１３と同様に、制御プログラム１Ｐの実行時に発生するデータなどを一時的に記憶する。また、制御プログラム１Ｐを大容量記憶装置１５に記憶しても良い。

計時部１６は、時刻又は車載装置１が起動してからの経過時間等の時間を計時しており、ＣＰＵ１１からの求めに応じて、計時結果をＣＰＵ１１に与える回路である。ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）通信部１７は、ＣＡＮの通信プロトコルに従って、ＣＡＮバスＣＢを介した他の装置との通信を行う。通信部１８はネットワークＮを介して、他のコンピュータと通信を行う。ＣＰＵ１１は、通信部１８を介して他のコンピュータから制御プログラム１Ｐをダウンロードし、大容量記憶装置１５に記憶しても良い。

車載装置１は監視対象となる車両に設置する。車載装置１は専用のハードウェアである。それ限らず、タブレットコンピュータ、ノートブック型ＰＣ等を用いて構成してもよい。

車両制御装置２は、車両の各部を制御する装置である。車両制御装置２はエンジンＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌｌｅｄ Ｕｎｉｔ：電子制御ユニット）２１、ボデーＥＣＵ２２、インパネＥＣＵ２３などを含む。各ＥＣＵはＣＡＮバスＣＢで接続されている。エンジンＥＣＵ２１は、エンジンパワートレインの各所に設置したセンサの情報から、エンジンの状態を判定する。エンジンＥＣＵ２１は、判定した状態に応じた最適な燃料噴射量や噴射時期、点火時期、アイドル回転数などを演算する。エンジンＥＣＵ２１は、演算結果に基づき、パワートレイン各部に制御指令を出す。

ボデーＥＣＵ２２は、パワーウインドウ、ドアロック装置、ワイパー、各種ライトを制御する。

インパネ（インストルメントパネル）ＥＣＵ２３は、インパネに設けてあるスピードメータ、タコメータ、フェールゲージ、水温計、警告表示を制御する。インパネＥＣＵ２３は、スピード（車速）信号、タコ（エンジン回転数）信号などを、エンジンＥＵＣ２１より取得する。

携帯端末３は、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、携帯電話機、スマートフォンなどで構成される。それに限らず、専用のハードウェアとしてもよい。携帯端末３は、ＣＰＵ３１、ＲＯＭ３２、ＲＡＭ３３、近距離通信部３４、入力部３５、表示部３６、通信部３７を含む。

ＣＰＵ３１はＲＯＭ３２に記憶された制御プログラム３Ｐに従いハードウェア各部を制御する。ＲＡＭ３３は例えばＳＲＡＭ、ＤＲＡＭ、フラッシュメモリである。ＲＡＭ３３はＣＰＵ３１による制御プログラム３Ｐの実行時に発生するデータを一時的に記憶する。

近距離通信部３４は、ＮＦＣ規格、ブルートゥース規格、赤外線通信規格などにしたがった通信を行う。

入力部３５は、各種データや命令を入力するのに用いられる。表示部３６は、ドライバへのメッセージなどを表示する。通信部３７はネットワークＮを介して、他のコンピュータと通信を行う。

次に、大容量記憶装置１５が記憶する端末ＩＤテーブル１５１について、説明する。図２は、端末ＩＤテーブル１５１のレコードレイアウトを示す説明図である。端末ＩＤテーブル１５１は固有ＩＤ列、電子メール列、電話番号列を含む。固有ＩＤ列は、車両の所有者など車両の使用が許可された人が持つ携帯端末３固有のＩＤ（固有ＩＤ）を記憶する。電子メール列は連絡用の電子メールアドレスを記憶する。電話番号列は連絡用電話番号を記憶する。電子メールアドレス、電話番号は、携帯端末３に割り当てられているものでも、その他のものでもよい。端末ＩＤテーブル１５１は、車両の使用者の数、使用者が携帯する携帯端末３の数に応じて、複数の固有ＩＤを記憶する。固有ＩＤはハードウェアに割り当てられる固有のＩＤである。固有ＩＤは、車載装置１と携帯端末３との間で行う近距離通信で採用する規格に則したもの記憶する。例えば、Ｆｅｌｉｃａ（登録商標）のＩＤｍや、Ｍｉｆａｒｅ（登録商標）のＵＩＤである。

続いて、車載装置１が行う処理について説明する。図３は、車載装置１が行うメイン処理の手順を示すフローチャートである。車載装置１のＣＰＵ１１は、車両が移動中であるか否かを判定する（ステップＳ１）。ＣＰＵ１１は、車両が移動中でないと判定した場合（ステップＳ１でＮＯ）、処理を終了する。ＣＰＵ１１は、車両が移動中であると判定した場合（ステップＳ１でＹＥＳ）、携帯端末３との交信処理を行う（ステップＳ２）。

図４は交信処理の手順を示すフローチャートである。ＣＰＵ１１は通信可能な携帯端末３のサーチを行う（ステップＳ１１）。例えば、ＣＰＵ１１は近距離通信部１４からポーリング信号を送信する。ＣＰＵ１１は携帯端末３から応答があったか否かを判定する（ステップＳ１２）。ＣＰＵ１１は応答があったと判定した場合（ステップＳ１２でＹＥＳ）、携帯端末３に対して、固有ＩＤを要求する（ステップＳ１３）。ＣＰＵ１１は携帯端末３より、固有ＩＤを受信する（ステップＳ１４）。ＣＰＵ１１は受信した固有ＩＤを、端末ＩＤテーブル１５１と照合する（ステップＳ１５）。ＣＰＵ１１は照合に成功したか否かを判定する（ステップＳ１６）。ＣＰＵ１１は、受信した固有ＩＤが端末ＩＤテーブル１５１に記憶されている固有ＩＤのいずれかと一致すれば、照合に成功と判定する。ＣＰＵ１１は、受信した固有ＩＤが端末ＩＤテーブル１５１に記憶されている固有ＩＤのいずれとも一致しなければ、照合に失敗と判定する。ＣＰＵ１１は照合に成功した判定した場合（ステップＳ１６でＹＥＳ）、処理結果を交信成功とし（ステップＳ１７）、処理を呼び出し元に戻す。ＣＰＵ１１は携帯端末３からの応答がなかったと判定した場合（ステップＳ１２でＮＯ）又は、照合に失敗した判定した場合（ステップＳ１６でＮＯ）、処理結果を交信失敗とし（ステップＳ１８）、処理を呼び出し元に戻す。なお、ステップＳ１２で複数の携帯端末３から応答があった場合には、順に、携帯端末３から固有ＩＤを受信し、照合を行う。照合に成功したときは、その時点で交信成功として、交信処理を終了する。または、応答した携帯端末３の全てから固有ＩＤを受信し、受信した固有ＩＤについて、順に照合をしてもよい。一方、応答した全ての携帯端末３の固有ＩＤが端末ＩＤテーブル１５１に記憶されていない場合、交信失敗として交信処理を終了する。

図３に戻り、ＣＰＵ１１は交信に成功した否かを判定する（ステップＳ３）。ＣＰＵ１１は交信に成功したと判定した場合（ステップＳ３でＹＥＳ）、処理を終了する。ＣＰＵ１１は交信に失敗したと判定した場合（ステップＳ３でＮＯ）、発報処理を行い（ステップＳ４）、処理を終了する。なお、図３に示すメイン処理は、インターバルタイマによる割り込みなどにより、繰り返し実行される。

メイン処理、交信処理について、以下に補足する。車両が移動中か否かの判定は、例えば、以下のように行う。エンジンＥＵＣ２１より車速信号を取得し、車両の速度を求める。求めた速度が所定の閾値以上であれば、移動中と判定する。求めた速度が所定の閾値未満であれば、移動中ではないと判定する。また、エンジンＥＣＵ２１からエンジン回転数信号を取得し、エンジン回転数を求める。求めたエンジンの回転数が所定の閾値以上であれば、移動中と判定する。車両速度、エンジン回転数は、インパネＥＣＵ２３が保持しているので、インパネＥＣＵ２３から取得してもよい。また、車両速度及びエンジン回転数を用いて、移動中の判定をしても良い。また、車両に搭載されたカーナビゲーション装置から車両位置の変化を検出して、移動中か否かを判定してもよい。さらにまた、車両に搭載されているジャイロセンサや加速度センサなどのセンサ出力を取得し、その変化により、車両の移動を検出してもよい。

車載装置１は、携帯端末３との交信の際、ポーリングを行う。そのため、携帯端末３は、ポーリングに応答可能な状態である必要がある。近距離通信部１４の通信規格として、ＷｉＦｉ、Ｂｌｕｅｔｏｏｔｈ、赤外線通信を採用する場合、携帯端末３はポーリングに応答できるように、待受状態である必要がある。

車載装置１は、端末ＩＤテーブル１５１に固有ＩＤが記憶されている携帯端末３との交信に成功したことにより、検知した車両の移動が盗難行為によるものではないと判定する。したがって、車載装置１と携帯端末３との交信が成功するのは、携帯端末３を所持した車両の正当な使用者が、車両内または車両近傍に居た場合でなければならない。よって、車載装置１と携帯端末３とは、近距離無線通信により、交信を行う。近距離無線通信として求められる性質は、次のようなものである。決められた通信エリア（例えば、車両から３ｍ）の範囲内に携帯端末３がある場合は、交信に成功し、通信エリア外に携帯端末３がある場合は、交信に失敗するという性質である。また、車載装置１と携帯端末３との間に障害物があったとしても、携帯端末３が通信エリア内にあれば、交信に成功するのが望ましい。そのため、近距離無線通信は、赤外線や超音波よりも、電波を用いるものが望ましい。

発報処理は、例えば、以下の処理である。端末ＩＤテーブル１５１のメールアドレス列に記憶されているメールアドレスに電子メールを送信する。また、端末ＩＤテーブル１５１の電話番号列に記憶されている携帯電話番号にＳＭＳ（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ）によるメッセージを送信する。さらにまた、携帯端末３で動作するアプリケーションソフトウェアにプッシュ通知により、メッセージを送信してもよい。警察に１１０番通報や、契約した警備会社に通報してもよい。また、車両に搭載されたカーオーディオ装置を用いて、運転者に警告音、警告音声を出力したり、表示部を備える装置を用いて、警告メッセージを表示したりしても良い。警備会社の管制センターと通話可能にして、管制員からの威嚇音声を出力してもよい。また、カーナビゲーション装置により、位置情報が取得可能である場合は、電子メール等に車両の位置情報を付加しても良い。なお、端末ＩＤテーブル１５１に複数の固有ＩＤが記憶されている場合は、すべての固有ＩＤに対応した電子メールアドレス宛に電子メール送信してもよい。また、すべての固有ＩＤに対応した電話番号宛にＳＭＳよるメッセージを送信してもよい。

さらにまた、盗難行為を中止させるために、エンジンＥＣＵ２１を制御して、車両を減速させた後に停止させ、エンジンを停止させても良い。車両に衝突回避支援システムや自動運転システムが搭載されていれば、それらの機能を用いることにより、より安全に車両を停止させることが可能である。

実施の形態１の車載装置１は、次のような効果を奏する。車両の移動を検出した後に、近距離通信部１４は携帯端末３との通信を試みるので、盗難を精度良く検出可能となる。また、車載装置１は、車両が停止状態にある場合、待機状態であれば良いので、消費電力を低減することが可能となる。それにより、長期間車両が運行されない場合であっても、車両の電力を過度に消費してしまうことを抑制可能である。

（実施の形態２）
本実施の形態は、車載装置１が位置情報取得機能を備える形態に関する。図５は、車載装置１の他の構成例を示すブロック図である。車載装置１は、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、近距離通信部１４、大容量記憶装置１５、計時部１６、ＣＡＮ通信部１７、通信部１８、位置情報取得部１９を含む。各構成はバスＢで接続されている。ＣＰＵ１１から通信部１８は、実施の形態１と同様であるから、説明を省略する。

位置情報取得部１９は、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）受信機などで構成される。位置情報取得部１９は、ＧＰＳ衛星からの電波を受信する。位置情報取得部１９は、受信した衛星電波を元に、自らの位置を求める。位置情報取得部１９は、自らの位置の変化により、車両が移動中か否かを判定する。

本実施の形態において、ＣＰＵ１１が行うメイン処理、交信処理は実施の形態１と同様であるから、説明を省略する。なお、本実施の形態において、メイン処理はタイマ割り込みにより繰り返し実行するのではなく、位置情報取得部１９が車両の移動を検知した場合にのみ、メイン処理を実行してもよい。なお、車載装置１に加速度センサ、ジャイロセンサを内蔵し、これらのセンサの出力値を監視することにより、車両の移動を検知してもよい。

本実施の形態は、車載装置１が位置情報取得部１９を備えることが特徴である。それにより、実施の形態１が奏する効果に加えて、以下の効果を奏する。車載装置１が位置情報取得部１９を備えることにより、エンジンを起動させないで車両が移動された場合にも、盗難を検知可能となる。例えば、車両をレッカー車により牽引したり、車両をカーキャリア（車載車）に積載して運搬したりする場合にも、盗難を検知可能となる。

（実施の形態３）
本実施の形態は、交信処理を間引くことにより、リソースを節約可能とする形態に関する。本実施の形態においては、車載装置１が携帯端末３との交信に成功した場合、その後の所定時間は、携帯端末３との交信処理を省略する。

図６は、交信済みフラグテーブル１５２のレコードレイアウトを示す説明図である。交信済みフラグテーブル１５２は、大容量記憶装置１５に記憶する。交信済みフラグテーブル１５２は、フラグ列、事由列、固有ＩＤ列、時刻列を含む。フラグ列は、交信済みフラクがＯＮであるか、ＯＦＦであるかを記憶する。事由列は、直前に交信済みフラグが変化した事由を記憶する。固有ＩＤ列は、携帯端末３との交信により、交信済みフラグが変化した場合に、当該携帯端末３の固有ＩＤを記憶する。時刻列は、交信済みフラグが変化した時刻を記憶する。図６に示す例では、交信済みフラグテーブル１５２は一レコードのみを記憶する。交信済みフラグがＯＮとは交信済みフラグが立っている状態を意味する。交信済みフラグがＯＦＦとは交信済みフラグが立っていない状態（クリアされている状態）を意味する。なお、以下の説明においては、交信済みフラグを単にフラグとも言う。

図６Ａは、フラグが初期化された後の交信済みフラグテーブル１５２の状態を示す。車載装置１は、自らが動作を開始した直後や、車両が駐車されたことを検知した場合に、交信済みフラグの初期化を行う。駐車されたことは、例えば、エンジンが停止され、電装への電源供給が停止されていることにより、検知可能である。図６Ｂは、携帯端末３との交信が成功した後の交信済みフラグテーブル１５２の状態を示す。

次に、本実施の形態におけるメイン処理について説明する。図７は、メイン処理の手順を示すフローチャートである。車載装置１のＣＰＵ１１は、車両が移動中であるか否かを判定する（ステップＳ２１）。ＣＰＵ１１は、車両が移動中でないと判定した場合（ステップＳ２１でＮＯ）、処理を終了する。ＣＰＵ１１は、車両が移動中であると判定した場合（ステップＳ２１でＹＥＳ）、交信済み判定を行う（ステップＳ２２）。

図８は、交信済み判定処理の手順を示すフローチャートである。ＣＰＵ１１は、交信済みフラグテーブル１５２を参照し、フラグがＯＮであるか否かを判定する（ステップＳ３１）。ＣＰＵ１１は、フラグがＯＮであると判定した場合（ステップＳ３１でＹＥＳ）、タイムアウトしているか否かを判定する（ステップＳ３２）。ＣＰＵ１１は、フラグがＯＮでないと判定した場合（ステップＳ３１でＮＯ）、処理をステップＳ３４に移す。ここで、タイムアウトしているとは、フラグがＯＮになってから、所定時間以上経過したことを言う。所定時間（タイムアウト時間）は、予め設定されている。タイムアウト時間は、大容量記憶装置１５などに記憶する。ＣＰＵ１１は交信済みフラグテーブル１５２の時刻列の時刻と、計時部１６から取得した現在時刻とから、経過時間を算出する。ＣＰＵ１１は、経過時間がタイムアウト時間より大きい場合、タイムアウトしていると判定する。ＣＰＵ１１は、経過時間がタイムアウト時間未満の場合、タイムアウトしていないと判定する。タイムアウトの意義については、後述する。

ＣＰＵ１１は、タイムアウトしていると判定した場合（ステップＳ３２でＹＥＳ）、フラグをＯＦＦに設定する（ステップＳ３３）。ＣＰＵ１１は処理結果を未交信とし（ステップＳ３４）、処理を呼び出し元に戻す。ＣＰＵ１１は、タイムアウトしていない判定した場合（ステップＳ３２でＮＯ）、処理結果を交信済とし（ステップＳ３５）、処理を呼び出し元に戻す。

図７に戻り、ＣＰＵ１１は交信済であるか否かを判定する（ステップＳ２３）。ＣＰＵ１１は交信済であると判定した場合（ステップＳ２３でＹＥＳ）、処理を終了する。ＣＰＵ１１は交信済でないと判定した場合（ステップＳ２３でＮＯ）、携帯端末３との交信処理を行う（ステップＳ２４）。交信処理は、実施の形態１と同様であるから、説明を省略する。ＣＰＵ１１は交信に成功した否かを判定する（ステップＳ２５）。ＣＰＵ１１は交信に成功したと判定した場合（ステップＳ２５でＹＥＳ）、フラグをＯＮとする（ステップＳ２７）。ＣＰＵ１１は処理を終了する。ＣＰＵ１１は交信に失敗したと判定した場合（ステップＳ２５でＮＯ）、発報処理を行い（ステップＳ２６）、処理を終了する。

次に、タイムアウトの意義について説明する。本実施の形態においては、交信済みフラグがＯＮの場合は、携帯端末３との交信処理を省略する。その理由は、携帯端末３の処理負担の軽減である。車両が運行されている場合、信号待ちなどの理由で頻繁に停車、発進が繰り返される。その度ごとに、携帯端末３との交信を行っていると、携帯端末３の処理負担が大きくなる。また、車載装置１や携帯端末３の消費電力も増大する。そこで、車載装置１が一度、携帯端末３との交信に成功した後は、携帯端末３との交信処理を省略するようにした。しかしながら、車両の運行が終わるまで、交信処理を省略したのでは、盗難のリスクが高まる。例えば、ドライバがエンジンを掛けたまま、車両から離れた隙に盗難された場合は、検知できなくなるからである。そのため、タイムアウトを設けている。タイムアウト時間は、ドライバが車両の運行に合わせて設定する。例えば、通勤に使用するのが主であれば、通勤時間や通勤時間の１／２のタイムアウト時間にすれば良い。また、デジタルタコグラフ、車両運行管理システム等の運行時間を記録する装置が搭載されている車両であれば、運行状況を解析し、それを元にタイムアウト時間を設定するようにしてもよい。さらにまた、交信済みフラグテーブル１５２において、フラグの変化をすべて履歴して残し、履歴を元に運行状況を解析し、タイムアウト時間を設定してもよい。

本実施の形態は、上述の実施の形態が奏する効果に加えて、以下の効果を奏する。車載装置１が携帯端末３との交信に成功した場合、その後の所定時間は、携帯端末３との交信処理を省略する。それにより、車載装置１、携帯端末３の処理負担が軽減される。さらに、処理負担の軽減に伴い、車載装置１、携帯端末３の消費電力が低減される。

（実施の形態４）
本実施の形態は、無線で車両ドアの解錠を行うシステム、いわゆるキーレスエントリーシステム、スマートエントリーシステムと連携する形態に関する。キーレスエントリーシステムでは、ドライバが携帯するリモートコントローラ（以下、「リモコン」と略記する）（遠隔操作器）４と通信することにより、ドアを解錠するシステムである。ドアが無線端末で解錠されたことにより、正当なドライバが車両を運行することは明らかであるから、車載装置１は携帯端末３と交信が成功したものとみなす。

図９は車両盗難システムの他の構成を示す説明図である。本実施の形態では、実施の形態１の構成に、リモコン４が加わっている。本実施の形態において、車両盗難システムの構成は、実施の形態３と同様であるので、以下の説明においては、異なる点を主として説明する。リモコン４は、遠隔で車両のドアを解錠又は施錠することが可能な無線機である。リモコン４はボデーＥＣＵ２２と微弱電波で通信を行う。リモコン４はＩＤを内部に記憶している。ボデーＥＣＵ２２は対応するリモコン４のＩＤを予め記憶している。リモコン４は、自らが記憶するＩＤをボデーＥＣＵ２２に送信する。ボデーＥＣＵ２２は、リモコン４から受信したＩＤが、予め記憶したＩＤと一致しているか否かを判定する。ボデーＥＣＵ２２は、ＩＤが一致していると判定した場合、車両のドアを解錠又は施錠する。

図１０は連携処理の手順を示すフローチャートである。連携処理はドアの解錠を契機に実行される処理である。例えば、ボデーＥＣＵ２２からの割り込み信号により、開始する。ＣＰＵ１１は、リモコン４によりドアが解錠されたか否かを判定する（ステップＳ４１）。例えば、ドアの解錠を行ったボデーＥＣＵ２２へ問い合わせを行い、ドライバが携帯するリモコン４により、ドアを解錠したか否かの回答を得る。ＣＰＵ１１はその回答に基づき、リモコン４によりドアが解錠されたか否かを判定する。ＣＰＵ１１は、交信済みフラグテーブル１５２のフラグ列をＯＮに書き換える（ステップＳ４２）。ＣＰＵ１１は処理を終了する。その他の処理、メイン処理、交信処理、交信済み判定処理は、実施の形態３と同様である。

本実施の形態においては、上述の実施の形態が奏する効果に加えて、次の効果を奏する。キーレスエントリーシステム等と連携することにより、運行開始直後の交信処理が省略可能となる。それにより、車載装置１、携帯端末３の処理負担が軽減される。さらに、処理負担の軽減に伴い、車載装置１、携帯端末３の消費電力が低減される。

なお、キーレスエントリー等で用いるリモコン４として、携帯端末３を使用してもよい。この場合、携帯端末３は、近距離通信部１４を介してボデーＥＣＵ２２と通信し、ドアの解錠又は施錠を行う。また、携帯端末３は、車載装置１を介して、ボデーＥＣＵ２２と通信し、ドアの解錠又は施錠を行ってもよい。一方、リモコン４に車載装置１との通信機能を持たせ、携帯端末３の代わりに車載装置１と交信する構成としてもよい。それにより、車両運行時に必要となる所持品を減らすことが可能となる。

（実施の形態５）
本実施の形態は、ドライバの明示的な指示により、車載装置１の機能を停止する形態に関する。車載装置１は車両の盗難を検知するための装置であるから、常時機能を発揮する状態であることが前提である。しかしながら、ドライバの都合により、車載装置１の機能を停止する必要とすることがある。例えば、車両を車検に出す場面、車両の駐車場への入庫又は駐車場からの出庫を他人に委ねる場面などである。本実施の形態は、そのような場面に対応する。本実施の形態において、車載装置１の構成は、実施の形態３と同様であるので、以下の説明においては、異なる点を主として説明する。

図１１は機能停止／再開処理の手順を示すフローチャートである。ＣＰＵ１１は携帯端末３から接続要求を受信する（ステップＳ５１）。ＣＰＵ１１は携帯端末３に対して、固有ＩＤを要求する（ステップＳ５２）。ＣＰＵ１１は携帯端末３より、固有ＩＤを受信する（ステップＳ５３）。ＣＰＵ１１は受信した固有ＩＤを、端末ＩＤテーブル１５１と照合する（ステップＳ５４）。ＣＰＵ１１は照合に成功したか否かを判定する（ステップＳ５５）。照合判定の具体的な方法は、上述したとおりである。ＣＰＵ１１は照合に失敗したと判定した場合（ステップＳ５５でＮＯ）、処理を終了する。ＣＰＵ１１は照合に成功したと判定した場合（ステップＳ５５でＹＥＳ）、携帯端末３からのコマンドを受信する（ステップＳ５６）。ＣＰＵ１１は受信したコマンドが停止命令か否かを判定する（ステップＳ５７）。ＣＰＵ１１は受信したコマンドが停止命令であると判定した場合（ステップＳ５７でＹＥＳ）、停止フラグをＯＮにする（ステップＳ５８）。ＣＰＵ１１は処理を終了する。ＣＰＵ１１は受信したコマンドが停止命令でないと判定した場合（ステップＳ５７でＮＯ）、受信したコマンドが再開命令であるか否かを判定する（ステップＳ５９）。ＣＰＵ１１は受信したコマンドが再開命令であると判定した場合（ステップＳ５９でＹＥＳ）、停止フラグをＯＦＦにする（ステップＳ６０）。ＣＰＵ１１は処理を終了する。ＣＰＵ１１は受信したコマンドが再開命令でないと判定した場合（ステップＳ５９でＮＯ）、処理を終了する。停止フラグは、大容量記憶装置１５やＲＡＭ１３に記憶する。

図１２は交信済み処理の手順を示すフローチャートである。ＣＰＵ１１は機能停止中か否かを判定する（ステップＳ６１）。ＣＰＵ１１は機能停止中であると判定した場合（ステップＳ６１でＹＥＳ）、処理結果を交信済みとし（ステップＳ６６）、処理を呼び出し元に戻す。ＣＰＵ１１は機能停止中でないと判定した場合（ステップＳ６１でＮＯ）、フラグ（交信済みフラグ）がＯＮであるか否かを判定する（ステップＳ６２）。ＣＰＵ１１はフラグがＯＮでないと判定した場合（ステップＳ６２でＮＯ）、処理をステップＳ６５に移す。ＣＰＵ１１はフラグがＯＮであると判定した場合（ステップＳ６２でＹＥＳ）、タイムアウトしているか否かを判定する（ステップＳ６３）。ＣＰＵ１１はタイムアウトしていると判定した場合（ステップＳ６３でＹＥＳ）、フラグをＯＦＦにする（ステップＳ６４）。ＣＰＵ１１は処理結果を未交信とし（ステップＳ６５）、処理を呼び出し元に戻す。ＣＰＵ１１はタイムアウトしていないと判定した場合（ステップＳ６３でＮＯ）、処理結果を交信済とし（ステップＳ６６）、処理を呼び出し元に戻す。

本実施の形態は、上述した実施の形態が奏する効果に加えて、以下の効果を奏する。ドライバの明示的な指示により、車載装置１の機能を停止するので、ドライバが立ち会わない状況で車両の運行が必要な場合において、発報してしまう不具合を回避することが可能となる。

（実施の形態６）
本実施の形態は、ドライバの明示的な指示により、車載装置１の機能が停止された場合において、所定の停止期間が経過したときには、機能を再開する形態に関する。本実施の形態において、車載装置１の構成は、実施の形態５と同様であるので、以下の説明においては、異なる点を主として説明する。

本実施の形態において、停止フラグは、交信済みフラグテーブル１５２と同様なテーブルに記憶されているものとする。図１３は交信済み処理の手順を示すフローチャートである。図１３において、図１２に示した処理と同様な処理については、同一の符号を付し、説明を省略する。ＣＰＵ１１は機能停止中と判定した場合（ステップＳ６１でＹＥＳ）、停止期間が経過した否かを判定する（ステップＳ６７）。停止フラグは交信済みフラグと同様に変化した日時と対応付けて大容量記憶装置１５に記憶されている。また、停止期間については、その長さ（例えば、２時間、２日間など）が予め大容量記憶装置１５に記憶されているものとする。ＣＰＵ１１は停止フラグと対応付けられた日時を取得する。ＣＰＵ１１は計時部１６より現在日時を取得する。ＣＰＵ１１は停止フラグが変化した日時、すなわち停止フラクがＯＮとなった日時と、現在日時から、停止フラクがＯＮとなっている時間を算出する。ＣＰＵ１１は求めた時間と、予め記憶されている停止期間とを比較する。ＣＰＵ１１は求めた時間が、停止期間より大きい場合、停止期間が経過したと判定する。ＣＰＵ１１は求めた時間が、停止期間以下の場合、停止期間は経過していないと判定する。ＣＰＵ１１は停止期間が経過したと判定した場合（ステップＳ６７でＹＥＳ）、処理をステップＳ６５に移す。ＣＰＵ１１は停止期間が経過していないと判定した場合（ステップＳ６７でＮＯ）、処理をステップＳ６６へ移す。

本実施の形態は、上述した実施の形態が奏する効果に加えて、以下の効果を奏する。ドライバの明示的な指示により、車載装置１の機能を停止するが、所定期間を経過した場合は、機能を再開する。それにより、想定した期間よりも長く、車両がドライバ手元に戻らない場合に、車載装置１の機能を再開することが可能となる。

なお、本実施の形態において、車載装置１は近距離通信部１４を介して通信する以外に、一般公衆網を介して、携帯端末３と通信可能としてもよい。その場合、一般公衆網を介しての通信により、携帯端末３から機能停止の開始、停止期間の変更を可能としてもよい。それにより、車両がドライバの手元にない期間が、予定よりも長くなった場合において、遠隔で停止期間を延長することが可能となる。それにより、車載装置１が不要に発報してしまうことを防ぐことが可能となる。

図１４は車載装置１の機能構成を示すブロック図である。車載装置１は移動判定部１１ａ、交信部１１ｂ、交信判定部１１ｃ、出力部１１ｄ、受信部１１ｅ、タイマ部１１ｆを含む。ＣＰＵ１１が制御プログラム１Ｐ等を実行することにより、車載装置１の各機能部が実現される。

移動判定部１１ａは、車両が移動しているか否か判定する。交信部１１ｂは、予め登録された携帯端末３と交信を行う。交信判定部１１ｃは、移動判定部１１ａが、車両が移動していると判定した場合、交信部１１ｂが予め登録された携帯端末３と交信可能か否かを判定する。出力部１１ｄは、交信判定部１１ｃが交信不可能と判定したときは、警報を出力する。受信部１１ｅは、携帯端末３を用いて車両のドアが解錠された旨を受信した場合、交信済みフラグをオンとする。タイマ部１１ｆは、交信済みフラグが所定時間以上、オンであると判定したときは、交信済みフラグをオフとする。

なお、車載装置１はバッテリを内蔵してもよい。この場合、車載装置１は、通常、車両バッテリから電源の供給を受ける。また、車載装置１は車両バッテリから供給を受けた電源により、内臓のバッテリを充電する。車載装置１は車両バッテリから電源が供給されなくなった場合には、内臓のバッテリを用いて動作する。それにより、車両のバッテリが上がった場合や、車載装置１の存在に気付いた盗賊により、車両バッテリからの電源供給が絶たれたとしても、動作可能となる。

各実施の形態で記載されている技術的特徴（構成要件）はお互いに組み合わせ可能であり、組み合わせすることにより、新しい技術的特徴を形成することができる。
今回開示された実施の形態はすべての点で例示であって、制限的なものでは無いと考えられるべきである。本発明の範囲は、上記した意味では無く、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。

１ 車載装置
１１ ＣＰＵ
１１ａ 移動判定部
１１ｂ 交信部
１１ｃ 交信判定部
１１ｄ 出力部
１１ｅ 受信部
１１ｆ タイマ部
１２ ＲＯＭ
１３ ＲＡＭ
１４ 近距離通信部
１５ 大容量記憶装置
１５１ 端末ＩＤテーブル
１５２ フラグテーブル
１６ 計時部
１７ ＣＡＮ通信部
１８ 通信部
１９ 位置情報取得部
１Ｐ 制御プログラム

Claims (5)

1. 車両が移動しているか否か判定する移動判定部と、
   予め登録された携帯通信機と近距離無線通信により交信を行う交信部と、
   前記移動判定部が、前記車両が移動していると判定した場合、前記交信部が前記予め登録された携帯通信機との交信に成功したか否かを判定する交信判定部と、
   前記交信判定部が交信に成功していないと判定した場合、警報を出力する出力部と、
   遠隔操作器を用いて前記車両のドアが解錠された旨を受信する受信部と
   を備え、
   前記交信判定部は、前記受信部が、前記遠隔操作器を用いて前記車両のドアが解錠された旨を受信した後、前記交信部を動作させず、前記交信部が前記予め登録された携帯通信機との交信に成功した場合、所定の条件が満たされるまで、前記交信部を動作させない
   ことを特徴とする車載装置。
2. 前記予め登録された携帯通信機は複数である
   ことを特徴とする請求項１に記載の車載装置。
3. 前記交信部を動作させていない継続時間を算出するタイマ部を備え、
   前記交信判定部は、前記継続時間が所定時間を超えた旨を前記タイマ部より通知された場合、前記交信部を動作させ、前記予め登録された携帯通信機との交信に成功したか否かを判定する
   ことを特徴とする請求項１又は２に記載の車載装置。
4. 前記交信判定部は、前記交信部が、前記予め登録された携帯通信機から停止命令を受信した場合は、前記予め登録された携帯通信機から再開命令を受信するまで、前記交信部を動作させない
   ことを特徴とする請求項１から３のいずれか一項に記載の車載装置。
5. 車両の移動を検出し、
   移動を検出した場合、予め登録された携帯通信機と近距離無線通信による交信を試み、
   前記予め登録された携帯通信機との交信に成功しなかった場合、警報を出力する
   処理を車載装置に行わせる
   コンピュータプログラムであって、
   遠隔操作器を用いて前記車両のドアが解錠されたと判定した後、前記携帯通信機との交信を試みず、前記予め登録された携帯通信機との交信に成功した場合、所定の条件が満たされるまで、前記携帯通信機との交信を試みない
   ことを特徴とするコンピュータプログラム。

Images