図面 (/)

技術 車載装置及びコンピュータプログラム

出願人 大日本印刷株式会社
発明者 半田富己男矢野義博
出願日 2016年6月16日 (5年4ヶ月経過) 出願番号 2016-120188
公開日 2017年12月21日 (3年10ヶ月経過) 公開番号 2017-222299
状態 特許登録済
技術分野 車両用盗難防止 盗難警報装置
主要キーワード 車両内また 盗難防止状態 交信不可 フラグ列 遠隔操作器 自動車盗難防止装置 再開命令 レッカー車
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2017年12月21日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (15)

課題

車両の盗難を精度良く検出可能な車載装置等を提供すること。

解決手段

車載装置1は、車両が移動しているか否か判定する移動判定部と、予め登録された携帯通信機近距離無線通信により交信を行う交信部と、前記移動判定部が、前記車両が移動している判定した場合、前記交信部が前記予め登録された携帯通信機との交信に成功したか否かを判定する交信判定部と、前記交信判定部が交信に成功していないと判定した場合、警報を出力する出力部とを備える。

概要

背景

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

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

概要

車両の盗難を精度良く検出可能な車載装置等を提供すること。車載装置1は、車両が移動しているか否か判定する移動判定部と、予め登録された携帯通信機と近距離無線通信により交信を行う交信部と、前記移動判定部が、前記車両が移動している判定した場合、前記交信部が前記予め登録された携帯通信機との交信に成功したか否かを判定する交信判定部と、前記交信判定部が交信に成功していないと判定した場合、警報を出力する出力部とを備える。

目的

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

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

車両が移動しているか否か判定する移動判定部と、予め登録された携帯通信機近距離無線通信により交信を行う交信部と、前記移動判定部が、前記車両が移動している判定した場合、前記交信部が前記予め登録された携帯通信機との交信に成功したか否かを判定する交信判定部と、前記交信判定部が交信に成功していないと判定した場合、警報を出力する出力部とを備えたことを特徴とする車載装置

請求項2

前記予め登録された携帯通信機は複数であることを特徴とする請求項1に記載の車載装置。

請求項3

前記交信判定部は、前記交信部が前記予め登録された携帯通信機との交信に成功した場合、所定の条件が満たされるまで、前記交信部を動作させないことを特徴とする請求項1又は2に記載の車載装置。

請求項4

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

請求項5

遠隔操作器を用いて前記車両のドア解錠された旨を受信する受信部を備え、前記受信部が、前記遠隔操作器を用いて前記車両のドアが解錠された旨を受信した場合、前記交信判定部は、前記交信部を動作させないことを特徴とする請求項3に記載の車載装置。

請求項6

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

請求項7

車両の移動を検出し、移動を検出した場合、予め登録された携帯通信機と近距離無線通信による交信を試み、前記予め登録された携帯通信機との交信に成功しなかった場合、警報を出力する処理を車載装置に行わせることを特徴とするコンピュータプログラム

技術分野

0001

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

背景技術

0002

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

0003

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

先行技術

0004

特開2007−241980号公報
特開2004−66962号公報

発明が解決しようとする課題

0005

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

0006

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

課題を解決するための手段

0007

本発明に係る車載装置は、車両が移動しているか否か判定する移動判定部と、予め登録された携帯通信機と近距離無線通信により交信を行う交信部と、前記移動判定部が、前記車両が移動している判定した場合、前記交信部が前記予め登録された携帯通信機との交信に成功したか否かを判定する交信判定部と、前記交信判定部が交信に成功していないと判定した場合、警報を出力する出力部とを備えたことを特徴とする。

0008

本発明にあっては、車両が移動している判定した場合に、予め登録した携帯通信機との交信を試みるので、盗難を精度良く検出可能となる。

0009

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

0010

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

0011

本発明に係る車載装置は、前記交信判定部は、前記交信部が前記予め登録された携帯通信機との交信に成功した場合、所定の条件が満たされるまで、前記交信部を動作させない
ことを特徴とする。

0012

本発明にあっては、予め登録した携帯通信機と交信に成功した後、交信判定部は交信部を動作させない。それにより、車両が停止状態から移動状態遷移する毎に、交信部は動作しないので、電力などのリソースを節約することが可能となる。

0013

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

0014

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

0015

本発明に係る車載装置は、遠隔操作器を用いて前記車両のドア解錠された旨を受信する受信部を備え、前記受信部が、前記遠隔操作器を用いて前記車両のドアが解錠された旨を受信した場合、前記交信判定部は、前記交信部を動作させないことを特徴とする。

0016

本発明にあっては、遠隔操作器を用いてドアが解除された場合には、交信部を動作させない。それにより、携帯通信機との通信を省略するので、電力などのリソースを節約することが可能となる。

0017

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

0018

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

0019

本発明に係るコンピュータプログラムは、車両の移動を検出し、移動を検出した場合、予め登録された携帯通信機と近距離無線通信による交信を試み、前記予め登録された携帯通信機との交信に成功しなかった場合、警報を出力する処理を車載装置に行わせることを特徴とする。

0020

本発明にあっては、車両が移動している判定した場合に、予め登録した携帯通信機との交信を試みるので、盗難を精度良く検出可能となる。

発明の効果

0021

本発明にあっては、盗難を精度良く検出可能となる。

図面の簡単な説明

0022

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

実施例

0023

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

0024

(実施の形態1)
図1は車両盗難通報システム10の構成を示す説明図である。車両盗難通報システム10は、車載装置1、車両制御装置2、携帯端末(携帯通信機)3を含む。

0025

車載装置1は、CPU(Central Processing Unit)11、ROM(Read Only Memory)12、RAM(Random Access Memory)13、近距離通信部14、大容量記憶装置15、計時部16、CAN通信部17、通信部18を含む。各構成はバスBで接続されている。

0026

CPU11はROM12に記憶された制御プログラム(コンピュータプログラム)1Pに従いハードウェア各部を制御する。RAM13は例えばSRAM(Static RAM)、DRAM(Dynamic RAM)、フラッシュメモリである。RAM13はCPU11による制御プログラム1Pの実行時に発生するデータを一時的に記憶する。

0027

近距離通信部14は、NFC(Near Field Communication)規格ブルートゥース(Bluetooth(登録商標))規格、赤外線通信(IrDA(Infrared Data Association)規格、WiFi(登録商標)規格などにしたがった通信を行う。

0028

大容量記憶装置15は、例えばハードディスクSSD(Solid State Drive)などである。大容量記憶装置15は、後述する端末IDテーブル151を記憶する。大容量記憶装置15は、RAM13と同様に、制御プログラム1Pの実行時に発生するデータなどを一時的に記憶する。また、制御プログラム1Pを大容量記憶装置15に記憶しても良い。

0029

計時部16は、時刻又は車載装置1が起動してからの経過時間等の時間を計時しており、CPU11からの求めに応じて、計時結果をCPU11に与える回路である。CAN(Controller Area Network)通信部17は、CANの通信プロトコルに従って、CANバスCBを介した他の装置との通信を行う。通信部18はネットワークNを介して、他のコンピュータと通信を行う。CPU11は、通信部18を介して他のコンピュータから制御プログラム1Pをダウンロードし、大容量記憶装置15に記憶しても良い。

0030

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

0031

車両制御装置2は、車両の各部を制御する装置である。車両制御装置2はエンジンECU(Electronic Controlled Unit:電子制御ユニット)21、ボデーECU22、インパネECU23などを含む。各ECUはCANバスCBで接続されている。エンジンECU21は、エンジンパワートレインの各所に設置したセンサの情報から、エンジンの状態を判定する。エンジンECU21は、判定した状態に応じた最適な燃料噴射量や噴射時期点火時期アイドル回転数などを演算する。エンジンECU21は、演算結果に基づき、パワートレイン各部に制御指令を出す。

0032

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

0033

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

0034

携帯端末3は、PDA(Personal Digital Assistant)、携帯電話機スマートフォンなどで構成される。それに限らず、専用のハードウェアとしてもよい。携帯端末3は、CPU31、ROM32、RAM33、近距離通信部34、入力部35、表示部36、通信部37を含む。

0035

CPU31はROM32に記憶された制御プログラム3Pに従いハードウェア各部を制御する。RAM33は例えばSRAM、DRAM、フラッシュメモリである。RAM33はCPU31による制御プログラム3Pの実行時に発生するデータを一時的に記憶する。

0036

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

0037

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

0038

次に、大容量記憶装置15が記憶する端末IDテーブル151について、説明する。図2は、端末IDテーブル151のレコードレイアウトを示す説明図である。端末IDテーブル151は固有ID列電子メール列、電話番号列を含む。固有ID列は、車両の所有者など車両の使用が許可された人が持つ携帯端末3固有のID(固有ID)を記憶する。電子メール列は連絡用の電子メールアドレスを記憶する。電話番号列は連絡用電話番号を記憶する。電子メールアドレス、電話番号は、携帯端末3に割り当てられているものでも、その他のものでもよい。端末IDテーブル151は、車両の使用者の数、使用者が携帯する携帯端末3の数に応じて、複数の固有IDを記憶する。固有IDはハードウェアに割り当てられる固有のIDである。固有IDは、車載装置1と携帯端末3との間で行う近距離通信で採用する規格に則したもの記憶する。例えば、Felica(登録商標)のIDmや、Mifare(登録商標)のUIDである。

0039

続いて、車載装置1が行う処理について説明する。図3は、車載装置1が行うメイン処理の手順を示すフローチャートである。車載装置1のCPU11は、車両が移動中であるか否かを判定する(ステップS1)。CPU11は、車両が移動中でないと判定した場合(ステップS1でNO)、処理を終了する。CPU11は、車両が移動中であると判定した場合(ステップS1でYES)、携帯端末3との交信処理を行う(ステップS2)。

0040

図4は交信処理の手順を示すフローチャートである。CPU11は通信可能な携帯端末3のサーチを行う(ステップS11)。例えば、CPU11は近距離通信部14からポーリング信号を送信する。CPU11は携帯端末3から応答があったか否かを判定する(ステップS12)。CPU11は応答があったと判定した場合(ステップS12でYES)、携帯端末3に対して、固有IDを要求する(ステップS13)。CPU11は携帯端末3より、固有IDを受信する(ステップS14)。CPU11は受信した固有IDを、端末IDテーブル151と照合する(ステップS15)。CPU11は照合に成功したか否かを判定する(ステップS16)。CPU11は、受信した固有IDが端末IDテーブル151に記憶されている固有IDのいずれかと一致すれば、照合に成功と判定する。CPU11は、受信した固有IDが端末IDテーブル151に記憶されている固有IDのいずれとも一致しなければ、照合に失敗と判定する。CPU11は照合に成功した判定した場合(ステップS16でYES)、処理結果を交信成功とし(ステップS17)、処理を呼び出し元に戻す。CPU11は携帯端末3からの応答がなかったと判定した場合(ステップS12でNO)又は、照合に失敗した判定した場合(ステップS16でNO)、処理結果を交信失敗とし(ステップS18)、処理を呼び出し元に戻す。なお、ステップS12で複数の携帯端末3から応答があった場合には、順に、携帯端末3から固有IDを受信し、照合を行う。照合に成功したときは、その時点で交信成功として、交信処理を終了する。または、応答した携帯端末3の全てから固有IDを受信し、受信した固有IDについて、順に照合をしてもよい。一方、応答した全ての携帯端末3の固有IDが端末IDテーブル151に記憶されていない場合、交信失敗として交信処理を終了する。

0041

図3戻り、CPU11は交信に成功した否かを判定する(ステップS3)。CPU11は交信に成功したと判定した場合(ステップS3でYES)、処理を終了する。CPU11は交信に失敗したと判定した場合(ステップS3でNO)、発報処理を行い(ステップS4)、処理を終了する。なお、図3に示すメイン処理は、インターバルタイマによる割り込みなどにより、繰り返し実行される。

0042

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

0043

車載装置1は、携帯端末3との交信の際、ポーリングを行う。そのため、携帯端末3は、ポーリングに応答可能な状態である必要がある。近距離通信部14の通信規格として、WiFi、Bluetooth、赤外線通信を採用する場合、携帯端末3はポーリングに応答できるように、待受状態である必要がある。

0044

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

0045

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

0046

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

0047

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

0048

(実施の形態2)
本実施の形態は、車載装置1が位置情報取得機能を備える形態に関する。図5は、車載装置1の他の構成例を示すブロック図である。車載装置1は、CPU11、ROM12、RAM13、近距離通信部14、大容量記憶装置15、計時部16、CAN通信部17、通信部18、位置情報取得部19を含む。各構成はバスBで接続されている。CPU11から通信部18は、実施の形態1と同様であるから、説明を省略する。

0049

位置情報取得部19は、GPS(Global Positioning System)受信機などで構成される。位置情報取得部19は、GPS衛星からの電波を受信する。位置情報取得部19は、受信した衛星電波を元に、自らの位置を求める。位置情報取得部19は、自らの位置の変化により、車両が移動中か否かを判定する。

0050

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

0051

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

0052

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

0053

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

0054

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

0055

次に、本実施の形態におけるメイン処理について説明する。図7は、メイン処理の手順を示すフローチャートである。車載装置1のCPU11は、車両が移動中であるか否かを判定する(ステップS21)。CPU11は、車両が移動中でないと判定した場合(ステップS21でNO)、処理を終了する。CPU11は、車両が移動中であると判定した場合(ステップS21でYES)、交信済み判定を行う(ステップS22)。

0056

図8は、交信済み判定処理の手順を示すフローチャートである。CPU11は、交信済みフラグテーブル152を参照し、フラグがONであるか否かを判定する(ステップS31)。CPU11は、フラグがONであると判定した場合(ステップS31でYES)、タイムアウトしているか否かを判定する(ステップS32)。CPU11は、フラグがONでないと判定した場合(ステップS31でNO)、処理をステップS34に移す。ここで、タイムアウトしているとは、フラグがONになってから、所定時間以上経過したことを言う。所定時間(タイムアウト時間)は、予め設定されている。タイムアウト時間は、大容量記憶装置15などに記憶する。CPU11は交信済みフラグテーブル152の時刻列の時刻と、計時部16から取得した現在時刻とから、経過時間を算出する。CPU11は、経過時間がタイムアウト時間より大きい場合、タイムアウトしていると判定する。CPU11は、経過時間がタイムアウト時間未満の場合、タイムアウトしていないと判定する。タイムアウトの意義については、後述する。

0057

CPU11は、タイムアウトしていると判定した場合(ステップS32でYES)、フラグをOFFに設定する(ステップS33)。CPU11は処理結果を未交信とし(ステップS34)、処理を呼び出し元に戻す。CPU11は、タイムアウトしていない判定した場合(ステップS32でNO)、処理結果を交信済とし(ステップS35)、処理を呼び出し元に戻す。

0058

図7に戻り、CPU11は交信済であるか否かを判定する(ステップS23)。CPU11は交信済であると判定した場合(ステップS23でYES)、処理を終了する。CPU11は交信済でないと判定した場合(ステップS23でNO)、携帯端末3との交信処理を行う(ステップS24)。交信処理は、実施の形態1と同様であるから、説明を省略する。CPU11は交信に成功した否かを判定する(ステップS25)。CPU11は交信に成功したと判定した場合(ステップS25でYES)、フラグをONとする(ステップS27)。CPU11は処理を終了する。CPU11は交信に失敗したと判定した場合(ステップS25でNO)、発報処理を行い(ステップS26)、処理を終了する。

0059

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

0060

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

0061

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

0062

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

0063

図10は連携処理の手順を示すフローチャートである。連携処理はドアの解錠を契機に実行される処理である。例えば、ボデーECU22からの割り込み信号により、開始する。CPU11は、リモコン4によりドアが解錠されたか否かを判定する(ステップS41)。例えば、ドアの解錠を行ったボデーECU22へ問い合わせを行い、ドライバが携帯するリモコン4により、ドアを解錠したか否かの回答を得る。CPU11はその回答に基づき、リモコン4によりドアが解錠されたか否かを判定する。CPU11は、交信済みフラグテーブル152のフラグ列をONに書き換える(ステップS42)。CPU11は処理を終了する。その他の処理、メイン処理、交信処理、交信済み判定処理は、実施の形態3と同様である。

0064

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

0065

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

0066

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

0067

図11は機能停止/再開処理の手順を示すフローチャートである。CPU11は携帯端末3から接続要求を受信する(ステップS51)。CPU11は携帯端末3に対して、固有IDを要求する(ステップS52)。CPU11は携帯端末3より、固有IDを受信する(ステップS53)。CPU11は受信した固有IDを、端末IDテーブル151と照合する(ステップS54)。CPU11は照合に成功したか否かを判定する(ステップS55)。照合判定の具体的な方法は、上述したとおりである。CPU11は照合に失敗したと判定した場合(ステップS55でNO)、処理を終了する。CPU11は照合に成功したと判定した場合(ステップS55でYES)、携帯端末3からのコマンドを受信する(ステップS56)。CPU11は受信したコマンドが停止命令か否かを判定する(ステップS57)。CPU11は受信したコマンドが停止命令であると判定した場合(ステップS57でYES)、停止フラグをONにする(ステップS58)。CPU11は処理を終了する。CPU11は受信したコマンドが停止命令でないと判定した場合(ステップS57でNO)、受信したコマンドが再開命令であるか否かを判定する(ステップS59)。CPU11は受信したコマンドが再開命令であると判定した場合(ステップS59でYES)、停止フラグをOFFにする(ステップS60)。CPU11は処理を終了する。CPU11は受信したコマンドが再開命令でないと判定した場合(ステップS59でNO)、処理を終了する。停止フラグは、大容量記憶装置15やRAM13に記憶する。

0068

図12は交信済み処理の手順を示すフローチャートである。CPU11は機能停止中か否かを判定する(ステップS61)。CPU11は機能停止中であると判定した場合(ステップS61でYES)、処理結果を交信済みとし(ステップS66)、処理を呼び出し元に戻す。CPU11は機能停止中でないと判定した場合(ステップS61でNO)、フラグ(交信済みフラグ)がONであるか否かを判定する(ステップS62)。CPU11はフラグがONでないと判定した場合(ステップS62でNO)、処理をステップS65に移す。CPU11はフラグがONであると判定した場合(ステップS62でYES)、タイムアウトしているか否かを判定する(ステップS63)。CPU11はタイムアウトしていると判定した場合(ステップS63でYES)、フラグをOFFにする(ステップS64)。CPU11は処理結果を未交信とし(ステップS65)、処理を呼び出し元に戻す。CPU11はタイムアウトしていないと判定した場合(ステップS63でNO)、処理結果を交信済とし(ステップS66)、処理を呼び出し元に戻す。

0069

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

0070

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

0071

本実施の形態において、停止フラグは、交信済みフラグテーブル152と同様なテーブルに記憶されているものとする。図13は交信済み処理の手順を示すフローチャートである。図13において、図12に示した処理と同様な処理については、同一の符号を付し、説明を省略する。CPU11は機能停止中と判定した場合(ステップS61でYES)、停止期間が経過した否かを判定する(ステップS67)。停止フラグは交信済みフラグと同様に変化した日時と対応付けて大容量記憶装置15に記憶されている。また、停止期間については、その長さ(例えば、2時間、2日間など)が予め大容量記憶装置15に記憶されているものとする。CPU11は停止フラグと対応付けられた日時を取得する。CPU11は計時部16より現在日時を取得する。CPU11は停止フラグが変化した日時、すなわち停止フラクがONとなった日時と、現在日時から、停止フラクがONとなっている時間を算出する。CPU11は求めた時間と、予め記憶されている停止期間とを比較する。CPU11は求めた時間が、停止期間より大きい場合、停止期間が経過したと判定する。CPU11は求めた時間が、停止期間以下の場合、停止期間は経過していないと判定する。CPU11は停止期間が経過したと判定した場合(ステップS67でYES)、処理をステップS65に移す。CPU11は停止期間が経過していないと判定した場合(ステップS67でNO)、処理をステップS66へ移す。

0072

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

0073

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

0074

図14は車載装置1の機能構成を示すブロック図である。車載装置1は移動判定部11a、交信部11b、交信判定部11c、出力部11d、受信部11e、タイマ部11fを含む。CPU11が制御プログラム1P等を実行することにより、車載装置1の各機能部が実現される。

0075

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

0076

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

0077

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

0078

1車載装置
11 CPU
11a移動判定部
11b交信部
11c 交信判定部
11d 出力部
11e 受信部
11fタイマ部
12 ROM
13 RAM
14近距離通信部
15大容量記憶装置
151端末IDテーブル
152フラグテーブル
16 計時部
17CAN通信部
18通信部
19位置情報取得部
1P 制御プログラム

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

該当するデータがありません

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ