ナビゲーション装置及びプログラム
【課題】 防犯効果を向上させたセキュリティ機能を有するナビゲーション装置を提供する。
【解決手段】 Ｌ車両４６０は、送信元車両であるＫ車両４５０からの情報受信を繰り返す。これにより、Ｋ車両４５０に発生する異常を監視する。また、Ｌ車両４６０は、Ｋ車両４５０からの情報受信と並行して、送信先車両であるＩ車両４３０への情報送信を繰り返す。これにより、Ｌ車両４６０に発生する異常は、Ｉ車両４３０によって監視されることになる。つまり、各車両は、送信元車両に発生する異常を監視すると共に、送信先車両によって、自車両に発生する異常を監視してもらうのである。そして、Ｌ車両４６０は、Ｋ車両４５０からの情報受信が途絶えると、Ｋ車両４５０に異常があったものとして、異常時処理を実行する。
【解決手段】 Ｌ車両４６０は、送信元車両であるＫ車両４５０からの情報受信を繰り返す。これにより、Ｋ車両４５０に発生する異常を監視する。また、Ｌ車両４６０は、Ｋ車両４５０からの情報受信と並行して、送信先車両であるＩ車両４３０への情報送信を繰り返す。これにより、Ｌ車両４６０に発生する異常は、Ｉ車両４３０によって監視されることになる。つまり、各車両は、送信元車両に発生する異常を監視すると共に、送信先車両によって、自車両に発生する異常を監視してもらうのである。そして、Ｌ車両４６０は、Ｋ車両４５０からの情報受信が途絶えると、Ｋ車両４５０に異常があったものとして、異常時処理を実行する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ナビゲーション装置に関する。
【背景技術】
【０００２】
従来、盗難防止機能を有する車両が知られている。例えば、所有者でない者が不正な手段で車両を移動させようとした場合に、車両の窃取行為を判断してクラクションなどの警報音を発するセキュリティ装置がある。ところが、窃取行為が行われる場合、事前にセキュリティ装置の機能を停止させられることがあり、実際にはセキュリティ装置が機能しないことも往々にして起こり得る。
【０００３】
このような問題を解決するための手段として、携帯電話機などの車両の所有者の携帯端末装置を用いて車両の異常を検知するようにしたシステムが提案されている（例えば、特許文献１参照）。このシステムでは、車両から携帯端末装置への信号を送信し、この信号が途切れた場合に、車両に異常があったことを判断することが開示されている。
【０００４】
【特許文献１】特開２００６−３５９９０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記特許文献１に開示されるシステムでは、車両の所有者の携帯端末と通信を行うことで異常を検出しているが、携帯端末は移動してしまうため常に安定して通信が出来るとは限らず、安定して通信が出来ない場合には、車両に異常があったことを正確に判断することができなかった。例えば、携帯端末の所有者が電波の状況が悪い場所（例えば、地下など）に移動した場合には通信を行うことが出来ず、車両から送信される信号を受信することが不可能となるため、車両の異常と判断してしまう虞がある。
【０００６】
本発明は、上述した問題に鑑みてなされたものであり、その目的は、防犯効果を向上させたセキュリティ機能を有するナビゲーション装置を提供することにある。
【課題を解決するための手段】
【０００７】
本発明のナビゲーション装置は、自車両の防犯機能の開始要求を検出した場合に、駐車中の車両と通信を行うナビゲーション装置であって、通信を行う駐車中の車両として、送信先車両、及び送信元車両を特定する車両特定手段と、設定された第一の所定時間間隔で送信先車両へ自車両確認伝聞情報を送信する送信手段と、送信元車両から送信元車両確認伝聞情報を受信する受信手段と、受信手段にて第一の所定時間に基づく第二の所定時間が経過しても送信元車両確認伝聞情報が受信されない場合、異常時に対応する異常時処理を実行する異常時処理実行手段と、を備えていることを特徴とする。
【０００８】
本発明によれば、自車両から情報を送信する車両である「送信先車両」、及び、自車両へ情報を送信してくる「送信元車両」が特定される。そして、送信元車両から送信されてくるはずの送信元車両確認伝聞情報が途切れた場合、送信元車両に異常が発生したものとされ、異常時に対応する異常時処理が実行される。この異常時処理には、例えば、クラクションの鳴動などによる警報音の発生などが含まれる。
【０００９】
つまり、駐車中の車両同士、即ち移動しない車両同士でグループを形成して常に安定した通信を行い、通信が途切れた場合に他車両（送信元車両）の異常を自車両が検出する。なお、送信元車両と送信先車両とが同一車両となっても差し支えない。このようにすれば、正確に他車両の異常を検出することができ、防犯効果の向上が図られる。
【００１０】
このようなナビゲーション装置を各車両が備えることで、いずれの車両も送信元車両の異常を検出することができ、グループ内において各車両の異常を確実に検出可能となる。
【００１１】
また、送信手段は、異常時処理の実行後にあっては、自車両発報伝聞情報を送信するよう構成されており、受信手段にて送信元車両発報伝聞情報が受信された場合、異常時処理を実行する発報処理実行手段を備えていることとしてもよい。
【００１２】
送信元車両に異常が発生したと判断した場合に異常時処理が実行されることは既に述べたが、この異常時処理の実行後にあっては、自車両発報伝聞情報が送信先車両へ送信される。一方、送信元車両から送信元車両発報伝聞情報が受信された場合、発報処理実行手段によって、異常時処理が実行される。このようなナビゲーション装置を各車両が備えることで、グループを形成する車両の異常を検知した車両以外の複数の車両が、異常時処理を実行することになり、防犯効果の一層の向上が図られる。
【００１３】
以上は、ナビゲーション装置の発明として説明してきたが、このようなナビゲーション装置の機能はコンピュータシステムにて実現されるため、プログラムの発明として実現することもできる。
すなわち、自車両の防犯機能の開始要求を検出した場合に、駐車中の車両と通信を行うためのプログラムであって、通信を行う駐車中の車両として、送信先車両、及び送信元車両を特定する車両特定処理と、設定された第一の所定時間間隔で送信先車両へ自車両確認伝聞情報を送信する送信処理と、送信元車両から送信元車両確認伝聞情報を受信する受信処理と、受信処理にて第一の所定時間に基づく第二の所定時間が経過しても送信元車両確認伝聞情報が受信されない場合に実行される異常時に対応する異常時処理とを含むことを特徴とするプログラムである。このようなプログラムを実行することで、上述のナビゲーション装置と同様の効果が奏される。
【発明を実施するための最良の形態】
【００１４】
以下、本発明の実施形態を図面に基づいて説明する。
図１は、本実施形態のナビゲーション装置１の全体構成を示す概略ブロック図である。本実施形態のナビゲーション装置１は、後述するように車両に搭載されて用いられ、車車間通信により車両同士で防犯機能を実現する。
ナビゲーション装置１は、電子制御装置（以下「ＥＣＵ」という）１０を中心に構成されている。ＥＣＵ１０には、ＧＰＳ（Global Positining System）受信機２０、地図データ記憶部３０、通信部４０、及び、セキュリティ部５０が電気的に接続されている。
【００１５】
ＥＣＵ１０は、いわゆるコンピュータシステムとして構成されており、内部にはＣＰＵ、ＲＯＭ、ＲＡＭ、及び、Ｉ／Ｏなどを備えている。なお、ＣＰＵはフリーランカウンタを有しており、このフリーランカウンタの値を取得することで計時可能となっている。
ＧＰＳ受信機２０は、衛星からの電波を受信する。この電波に基づく測位によって、自車位置を検出することが可能となっている。もちろん、図示しない地磁気センサ、ジャイロスコープ、距離センサなどと、相互に補完しながら自車位置を検出しても良いし、ＧＰＳ受信機２０を用いずに自車位置を検出してもよい。
【００１６】
地図データ記憶部３０は、例えばハードディスク装置（ＨＤＤ）として実現される記憶装置である。なお、他の記憶媒体を用いても差し支えない。この地図データ記憶部３０は、位置検出の精度向上のためのいわゆるマップマッチング用データおよび経路を探索するための地図データを記憶している。地図データには、各種データが含まれるが、その一つとして施設に関する施設情報が含まれる。施設情報は、具体的には、施設を特定するＩＤと関連づけて記憶されているＰＯＩ（Point Of Interest ）情報である。ＰＯＩ情報には、施設ＩＤ、住所、種別（ジャンル）、領域データ（領域の外周座標、中心座標等）、などが含まれる。例えば、駐車場の情報も施設情報として記憶されている。
【００１７】
通信部４０は、無線通信を行うための構成である。本実施形態のナビゲーション装置１は、複数台の車両に搭載されて用いられる。このとき各車両同士の間で車車間通信を可能とするのが、この通信部４０である。
セキュリティ部５０は、防犯のための構成である。具体的には、防犯機能の開始及び終了を指示するための操作ボタン５１、及び、警報音を発生する警報音発生部５２を具備してなる。
【００１８】
このように構成されたナビゲーション装置１が複数台の車両に搭載されることは、既に述べた。本実施形態では、当該複数台の車両がグループを形成し、このグループ内で通信を行うことを特徴とする。そこで次に、グループの形成について説明する。
【００１９】
図２は、グループの形成を示す説明図である。図２に示すように、駐車場Ｃには、複数台（ここでは７台）の車両４００、４１０、４２０、４３０、４４０、４５０、４６０が駐車されている。以下、車両４００〜４６０を区別するため、図２中の記号を用い、Ｆ車両４００、Ｇ車両４１０、Ｈ車両４２０、Ｉ車両４３０、Ｊ車両４４０、Ｋ車両４５０、Ｌ車両４６０と記述する。
【００２０】
図２では、Ｆ〜Ｌの車両４００〜４６０が２つのグループＤ、Ｅを形成している。より詳しくは、Ｆ〜Ｈの３台の車両４００〜４２０がグループＤを形成し、Ｉ〜Ｌの４台の車両４３０〜４６０がグループＥを形成している。本実施形態では、このようなグループを形成することにより、グループ単位で通信処理を行う。例えば、グループＥについて見ると、図３に示すように、Ｉ車両４３０からＪ車両４４０への情報送信が行われ、Ｊ車両４４０からＫ車両４５０への情報送信が行われ、Ｋ車両４５０からＬ車両４６０への情報送信が行われ、Ｌ車両４６０からＩ車両４３０への情報送信が行われるという具合である。
【００２１】
なお、以下では、ある車両から見て、情報の送信先となる車両を「送信先車両」、情報の送信元となる車両を「送信元車両」というものとする。図３において一例を挙げると、Ｌ車両４６０から見て、Ｉ車両４３０が「送信先車両」であり、Ｋ車両４５０が「送信元車両」である。
【００２２】
このようなグループが形成された後、Ｉ〜Ｌの各車両４３０〜４６０のナビゲーション装置１では、メイン処理が繰り返し実行されることになる。そこで次に、このメイン処理について説明する。
【００２３】
図４は、メイン処理を示すフローチャートである。
メイン処理は、ステップ（以下「ステップ」を単に記号Ｓで示す）１０の送信フラグ管理処理、Ｓ２０の送信処理、Ｓ３０の受信処理、及び、Ｓ４０の異常処理からなる。これらの処理を順に説明していく。
【００２４】
図５に示すように、送信フラグ管理処理では、最初のＳ１１において、前回の送信から第一の所定時間（例えば、３分）が経過したか否かを判断する。前回の送信から第一の所定時間の経過はＥＣＵ１０のＣＰＵが有するフリーランカウンタの値に基づき判断することが例示される。ここで第一の所定時間が経過したと判断された場合（Ｓ１１：ＹＥＳ）、Ｓ１２にて送信フラグをＯＮにし、その後、本送信フラグ管理処理を終了する。一方、第一の所定時間が経過していないと判断された場合（Ｓ１１：ＮＯ）、Ｓ１２の処理を実行せず、本送信フラグ管理処理を終了する。
【００２５】
また、図６に示すように、送信処理では、最初のＳ２１において、送信フラグがＯＮであるか否かを判断する。上述したように、送信フラグは、第一の所定時間が経過したときにＯＮとなる（図５中のＳ１１：ＹＥＳ、Ｓ１２）。ここで送信フラグがＯＮであると判断された場合（Ｓ２１：ＹＥＳ）、Ｓ２２へ移行する。一方、送信フラグがＯＮでないと判断された場合（Ｓ２１：ＮＯ）、すなわち送信フラグがＯＦＦの場合には、以降の処理を実行せず、本送信処理を終了する。
【００２６】
Ｓ２２では、発報フラグがＯＮであるか否かを判断する。この発報フラグについては後述する。ここで発報フラグがＯＮであると判断された場合（Ｓ２２：ＹＥＳ）、Ｓ２４にて発報伝聞情報を送信先車両へ送信し、その後、本送信処理を終了する。一方、発報フラグがＯＮでないと判断された場合（Ｓ２２：ＮＯ）、すなわち発報フラグがＯＦＦである場合には、Ｓ２３にて確認伝聞情報を送信先車両へ送信すると共に送信フラグをＯＦＦとし、その後、本送信処理を終了する。
【００２７】
これらの情報の送信は、図１に示した通信部４０を介して行われる。発報伝聞情報には、「発報伝聞ＩＤ」及び送信先車両のＩＤである「宛先車両ＩＤ」が含まれる。同様に、確認伝聞情報には、「確認伝聞ＩＤ」及び送信先車両のＩＤである「宛先車両ＩＤ」が含まれる。
【００２８】
このように、本実施形態では、送信フラグ管理処理及び送信処理を繰り返し実行することにより、第一の所定時間間隔で、送信先車両へ情報を送信する。この意味で、ＥＣＵ１０が「送信手段」を構成し、送信フラグ管理処理及び送信処理が「送信手段」の機能としての「送信処理」に相当する。
【００２９】
図７に示すように、受信処理では、最初のＳ３１において、通信部４０を介し情報を受信したか否かを判断する。この処理は、図１に示した通信部４０を介した情報の受信があったか否かを判断するものである。ここで情報を受信したと判断された場合（Ｓ３１：ＹＥＳ）、Ｓ３２へ移行する。一方、情報を受信していないと判断された場合（Ｓ３１：ＮＯ）、以降の処理を実行せず、本受信処理を終了する。
【００３０】
Ｓ３２では、受信した情報が自車両宛か否かを判断する。これは、送信された情報に含まれる「宛先車両ＩＤ」が自車両のＩＤと一致しているか否かで判断される。ここで自車両宛であると判断された場合（Ｓ３２：ＹＥＳ）、Ｓ３３にて受信フラグをＯＮにし、本受信処理を終了する。一方、自車両宛でないと判断された場合（Ｓ３２：ＮＯ）、Ｓ３３の処理を実行せず、本受信処理を終了する。
【００３１】
また、図８に示すように、異常処理では、最初のＳ４１において、受信フラグがＯＮであるか否かを判断する。上述したように、受信フラグは、自車両宛の情報を受信したときにＯＮとなる（図７中のＳ３１：ＹＥＳ、Ｓ３２：ＹＥＳ、Ｓ３３）。ここで受信フラグがＯＮであると判断された場合（Ｓ４１：ＹＥＳ）、Ｓ４５へ移行する。一方、受信フラグがＯＮでないと判断された場合（Ｓ４１：ＮＯ）、すなわち自車両宛の情報が受信されないうちは、Ｓ４２へ移行する。
【００３２】
Ｓ４２では、第二の所定時間が経過したか否かを判断する。この第二の所定時間は、上述した第一の所定時間に基づくものであり、具体的には、第一の所定時間と同一か、あるいは、第一の所定時間よりも長い時間として設定される。また、第一の所定時間の経過と同様、第二の所定時間の経過はＥＣＵ１０のＣＰＵが有するフリーランカウンタの値に基づき判断することが例示される。ここで第二の所定時間が経過したと判断された場合（Ｓ４２：ＹＥＳ）、Ｓ４３へ移行する。一方、第二の所定時間が経過していないと判断された場合（Ｓ４２：ＮＯ）、以降の処理を実行せず、本異常処理を終了する。
【００３３】
第二の所定時間が経過した場合に移行するＳ４３では、送信フラグ及び発報フラグを共にＯＮにする。続くＳ４４では異常時処理を実行し、その後、本異常処理を終了する。Ｓ４４における異常時処理では、セキュリティ部５０の警報音発生部５２を介し、警報音を発生させる。なお、本実施形態では、警報音発生部５２を備える構成としたが、例えば、クラクションを鳴動させるようにしてもよい。
【００３４】
受信フラグがＯＮであると判断された場合に移行するＳ４５では、受信フラグをＯＦＦにする。
続くＳ４６では、受信した情報が発報伝聞情報であるか否かを判断する。この発報伝聞情報には、「発報伝聞ＩＤ」が含まれる。したがって、ここでは受信情報に「発報伝聞ＩＤ」があるか否かを判断する。発報伝聞情報であると判断された場合（Ｓ４６：ＹＥＳ）、第二の所定時間が経過した場合と同様、Ｓ４３にて送信フラグ及び発報フラグを共にＯＮとし、Ｓ４４にて異常時処理を実行して、本異常処理を終了する。一方、発報伝聞情報でないと判断された場合（Ｓ４６：ＮＯ）、すなわち確認伝聞情報である場合には、本異常処理を終了する。
【００３５】
このように本実施形態では、繰り返し自車両宛の情報受信を行い（図７中のＳ３１、Ｓ３２）、情報が受信されないまま第二の所定時間が経過すると（図８中のＳ４１：ＮＯ、Ｓ４２：ＹＥＳ）、異常時処理が実行されるようになっている（Ｓ４４）。この意味で、ＥＣＵ１０が「受信手段」、「異常時処理実行手段」及び「発報処理実行手段」を構成し、図７に示した受信処理が「受信手段」の機能としての「受信処理」に相当し、図８に示した異常処理のＳ４４が「異常時処理実行手段」及び「発報処理実行手段」の機能としての「異常時処理」に相当する。
【００３６】
ところで、Ｓ４４の異常時処理が実行されるときには、必ずＳ４３にて、送信フラグ及び発報フラグがＯＮとなる。これによって、異常時処理が一度実行されると、図６中のＳ２２にて肯定判断されることになり、発報伝聞情報が送信先車両へ送信されることになる（Ｓ２４）。また、このときは、送信フラグもＯＮとなっているため、第一の所定時間の経過を待たずに、発報伝聞情報が送信されることになる。
【００３７】
一方、発報伝聞情報を受信する送信先車両では、図８に示した異常処理のＳ４６にて肯定判断され、送信フラグ及び発報フラグが共にＯＮとなり（Ｓ４３）、異常時処理が実行される（Ｓ４４）。これにより、順次、発報伝聞情報がグループを形成する各車両へ送信されることになる。
【００３８】
この点、図３を用いて具体的に説明する。なお、実際には各車両４３０〜４６０に搭載されるナビゲーション装置１のＥＣＵ１０が処理実行の主体となるが、煩雑になることを避ける意味で、ここでは、Ｉ〜Ｌの各車両４３０〜４６０を主体とした記載とする。
【００３９】
例えばＬ車両４６０は、送信元車両であるＫ車両４５０からの情報受信を繰り返す（図７参照）。これにより、Ｋ車両４５０に発生する異常を監視する。また、Ｌ車両４６０は、Ｋ車両４５０からの情報受信と並行して、送信先車両であるＩ車両４３０への情報送信を繰り返す（図６参照）。これにより、Ｌ車両４６０に発生する異常は、Ｉ車両４３０によって監視されることになる。つまり、各車両は、送信元車両に発生する異常を監視すると共に、送信先車両によって、自車両に発生する異常を監視してもらうのである。
【００４０】
ここで例えば、Ｌ車両４６０について見ると、Ｋ車両４５０からの情報受信が途絶えると（図８中のＳ４２：ＹＥＳ）、Ｌ車両４６０は、Ｋ車両４５０に異常があったものとして、異常時処理を実行する（Ｓ４４）。このときＬ車両４６０は、送信フラグ及び発報フラグを共にＯＮとし（Ｓ４３）、即座に、発報伝聞情報を送信先車両であるＩ車両４３０へ送信する（図６中のＳ２１：ＹＥＳ、Ｓ２２：ＹＥＳ、Ｓ２４）。
【００４１】
その結果、Ｉ車両４３０は、Ｌ車両４６０と同様、異常時処理を実行し（図８中のＳ４４）、このとき、送信フラグ及び発報フラグを共にＯＮとし（Ｓ４３）、即座に、発報伝聞情報を送信先車両であるＪ車両４４０へ送信する（図６中のＳ２１：ＹＥＳ、Ｓ２２：ＹＥＳ、Ｓ２４）。Ｊ車両４４０も同様に異常時処理を実行する（Ｓ４４）。
【００４２】
以上、グループが形成されている状態での通信処理について説明した。次に、グループを形成するための通信処理について説明する。
ここでは最初にグループへの車両の追加について、図９〜図１３を用い説明する。次に、グループからの車両の削除について、図１４〜図１７を用い説明する。
【００４３】
図９は、追加要求処理を示すフローチャートである。この処理は、形成されたグループへの追加を要求する新規車両にて実行されるものであり、駐車後に繰り返し実行される。
最初のＳ５１では、利用者からの追加指示があったか否かを判断する。この処理は、セキュリティ部５０の操作ボタン５１の操作を判断するものであり、グループへの追加指示があったか否かを判断するものである。ここで追加指示があったと判断された場合（Ｓ５１：ＹＥＳ）、Ｓ５２へ移行する。一方、追加指示がないと判断された場合（Ｓ５１：ＮＯ）、以降の処理を実行せず、本追加要求処理を終了する。
【００４４】
Ｓ５２では、グループへの追加要求を送信する。この処理は、車両を特定せずに行われる。この追加要求には、「追加要求ＩＤ」及び「新規車両（自車両）のＩＤ」が送信される。
【００４５】
続くＳ５３では、局設定要求があったか否かを判断する。局設定要求には、「局設定要求ＩＤ」、「末端車両のＩＤ」、「末端車両の位置」及び当該末端車両の送信先車両としての「先頭車両のＩＤ」が含まれる。この局設定要求は、後述するように、グループを形成している車両のうち末端車両から送信されるものである。本実施形態において、末端車両は、最後にグループに追加された車両である。したがって、さらに自車両が追加されれば、次は、自車両が末端車両となる。ここで局設定要求がないと判断された場合（Ｓ５３：ＮＯ）、Ｓ５４へ移行する。一方、局設定要求があったと判断された場合（Ｓ５３：ＹＥＳ）、Ｓ５５へ移行する。
【００４６】
Ｓ５４では、第三の所定時間が経過したか否かを判断する。この判断は、ＥＣＵ１０のＣＰＵが有するフリーランカウンタの値を参照することで行うことが例示される。ここで所定時間が経過したと判断された場合（Ｓ５４：ＹＥＳ）、本追加要求処理を終了する。一方、所定時間が経過していないと判断された場合（Ｓ５４：ＮＯ）、Ｓ５３の判断処理を繰り返す。つまり、Ｓ５３及びＳ５４によって、末端車両から局設定要求があったか否かの判断が、所定時間繰り返されることになる。
【００４７】
Ｓ５５では、新規車両に最も近い末端車両を選択する。複数のグループが存在する場合、複数台の末端車両が存在する。したがって、ここではＧＰＳ受信機２４にて取得される新規車両（自車両）の位置、局設定要求として送信される「末端車両の位置」及び地図データ記憶部３０の地図データに基づき、新規車両に最も近い末端車両を選択する。
【００４８】
次のＳ５６では、局設定応答を送信する。ここでは、「局設定応答ＩＤ」、情報送信の宛先となる「宛先車両ＩＤ」、及び「自車両ＩＤ」が送信される。宛先車両は、末端車両及び先頭車両である。したがって、「宛先車両ＩＤ」は、末端車両ＩＤ及び先頭車両ＩＤとなる。
続くＳ５７では末端フラグをＯＮとする。これにより、自車両が次の末端車両となる。Ｓ５８の処理終了後、本追加要求処理を終了する。
【００４９】
次に、図９の追加要求処理に対応する追加処理を、図１０を参照して説明する。この追加処理は、イグニッションキーがオフされている間、繰り返し実行されるものである。
最初のＳ６１において、他車両からの情報受信があったか否かを判断するものである。ここで受信があったと判断された場合（Ｓ６１：ＹＥＳ）、Ｓ６２へ移行する。一方、受信がないと判断された場合（Ｓ６１：ＮＯ）、以降の処理を実行せず、本追加処理を終了する。
【００５０】
Ｓ６２では、受信した情報が追加要求であるか否かを判断する。この処理は、図９中のＳ５２の追加要求の送信に対応するものである。したがって、ここでは、受信された情報に「追加要求ＩＤ」が含まれているか否かを判断する。ここで追加要求であると判断された場合（Ｓ６２：ＹＥＳ）、Ｓ６３へ移行する。一方、追加要求でないと判断された場合（Ｓ６２：ＮＯ）、Ｓ６３及びＳ６４の処理を実行せず、Ｓ６５へ移行する。
【００５１】
Ｓ６３では、末端フラグがＯＮであるか否かを判断する。この処理は、自車両が末端車両であるか否かを判断するものである。ここで末端フラグがＯＮであると判断された場合（Ｓ６３：ＹＥＳ）、Ｓ６４へ移行する。一方、末端フラグがＯＮでないと判断された場合（Ｓ６３：ＮＯ）、Ｓ６４の処理を実行せず、Ｓ６５へ移行する。
【００５２】
Ｓ６４では、局設定要求を送信する。この局設定要求には、「局設定要求ＩＤ」、「自車両ＩＤ」、「自車両の位置」及び自車両の送信先車両である「先頭車両ＩＤ」が含まれる。これを新規車両側から見ると、上述したように「局設定要求ＩＤ」、「末端車両ＩＤ」、「末端車両の位置」及び「先頭車両ＩＤ」が送信されてくることになる。
【００５３】
Ｓ６５では、受信した情報が局設定応答であるか否かを判断する。この処理は、図９中のＳ５７の局設定応答送信に対応するものである。したがって、ここでは、受信された情報に「局設定応答ＩＤ」が含まれているか否かで判断する。ここで局設定応答であると判断された場合（Ｓ６５：ＹＥＳ）、Ｓ６６へ移行する。一方、局設定応答でないと判断された場合（Ｓ６５：ＮＯ）、Ｓ６６及びＳ６７の処理を実行せず、本追加処理を終了する。
【００５４】
Ｓ６６では、自車両宛か否かを判断する。図９中のＳ５７では、末端車両及び先頭車両へ向けて、局設定応答が送信される。具体的には、末端車両ＩＤ及び先頭車両ＩＤが「宛先車両ＩＤ」として送信される。したがって、ここでは、宛先車両ＩＤが自車両ＩＤに一致するか否かを判断する。ここで自車両宛であると判断された場合（Ｓ６６：ＹＥＳ）、Ｓ６７にて局設定処理を実行し、その後、本追加処理を終了する。Ｓ６７では、末端車両及び先頭車両において、局設定処理が実行されることになる。一方、自車両宛でないと判断された場合（Ｓ６６：ＮＯ）、Ｓ６７の処理を実行せず、本追加処理を終了する。
【００５５】
続けて、図１０中のＳ６７で実行される局設定処理の詳細を、図１１のフローチャートに基づいて説明する。
【００５６】
最初のＳ６７１では、末端フラグがＯＮであるか否かを判断する。これは、自車両が末端車両であるか否かを判断するものである。ここで末端フラグがＯＮであると判断された場合（Ｓ６７１：ＹＥＳ）、すなわち自車両が末端車両である場合には、Ｓ６７２にて末端フラグをＯＦＦとし、Ｓ６７３で送信先車両を新規車両に変更して、その後、局設定処理を終了する。一方、末端フラグがＯＮでないと判断された場合（Ｓ６７１：ＮＯ）、すなわち、自車両が先頭車両である場合には、Ｓ６７４にて送信元車両を新規車両に変更し、その後、局設定処理を終了する。
【００５７】
なお、本実施形態におけるＥＣＵ１０が「車両特定手段」を構成し、図９および図１０に示す追加要求処理、追加処理が「車両特定手段」の機能としての「車両特定処理」に相当する。
【００５８】
ここで、図９〜図１１を用いて説明した追加要求処理及び追加処理に対する理解を容易にするため、図１２及び図１３を用いて具体的な説明を加える。
【００５９】
図１２（ａ）に示すように、Ｉ〜Ｌの４台の車両４３０〜４６０がグループを形成しているものとする。このとき、末端車両はＬ車両４６０であり、先頭車両はＩ車両４３０であるものとして以下説明を続ける。なお、実際には各車両４３０〜４６０に搭載されるナビゲーション装置１のＥＣＵ１０が処理実行の主体となるが、煩雑になることを避ける意味で、ここでは、Ｉ〜Ｌの各車両４３０〜４６０を主体とした記載とする。
【００６０】
新規車両としてのＭ車両４７０は、その駐車後、利用者によってグループへの追加指示がなされると（図９中のＳ５１：ＹＥＳ）、追加要求を送信する（Ｓ５２、図１３中のＴ１）。このとき、末端車両の場合には図１０中のＳ６３にて肯定判断されるため、末端車両であるＬ車両４６０は、追加要求に応じて、局設定要求を送信する（Ｓ６４、図１３中のＴ２）。これに対し、新規車両であるＭ車両４７０は、複数台の末端車両がある場合、末端車両のうちで最も近い車両を選択し（図９中のＳ５５）、局設定応答を送信する（Ｓ５６、図１３中のＴ３、Ｔ４）。
【００６１】
これにより、末端車両であるＬ車両４６０及び先頭車両であるＩ車両４３０は、局設定処理を実行する（図１０中のＳ６７、図１１参照）。具体的に、末端車両であるＬ車両４６０は、末端フラグをＯＦＦとし（図１１中のＳ６７２）、送信先車両を新規車両であるＭ車両４７０へ変更する。一方、先頭車両であるＩ車両４３０は、送信元車両を新規車両であるＭ車両４７０へ変更する。これにより、図１２（ｂ）に示す如く、Ｍ車両４７０が末端車両として追加されることになる。
【００６２】
図１４は、削除要求処理を示すフローチャートである。この処理は、形成されたグループからの削除を要求する離脱車両にて実行されるものであり、エンジンの始動時に実行される。
最初のＳ７１では、利用者からの削除指示があったか否かを判断する。この処理は、セキュリティ部５０の操作ボタン５１の操作を判断するものであり、グループからの削除指示があったか否かを判断するものである。ここで削除指示があったと判断された場合（Ｓ７１：ＹＥＳ）、Ｓ７２へ移行する。一方、削除指示がないと判断された場合（Ｓ７１：ＮＯ）、以降の処理を実行せず、本削除要求処理を終了する。
【００６３】
Ｓ７２では、末端フラグがＯＮであるか否かを判断する。この処理は、離脱車両がグループの末端車両であったか否かを判断するものである。ここで末端フラグがＯＮである場合（Ｓ７２：ＹＥＳ）、Ｓ７３にて第一の削除要求を送信する。この第一の削除要求には、末端復帰要求が含まれる。具体的には、「宛先車両ＩＤ」、「削除要求ＩＤ」、自車両のＩＤである「離脱車両のＩＤ」及び「末端復帰要求を示す情報」が含まれる。一方、末端フラグがＯＮでない場合（Ｓ７２：ＮＯ）、Ｓ７４にて第二の削除要求を送信する。この第二の削除要求は、末端復帰要求を含まない。具体的には、「宛先車両ＩＤ」、「削除要求ＩＤ」及び「離脱車両ＩＤ」が含まれる。ここで「宛先車両ＩＤ」は、離脱車両の送信元車両ＩＤ及び送信先車両ＩＤである。
【００６４】
次に、図１４の削除要求処理に対応する削除処理を、図１５を参照して説明する。この削除処理は、イグニッションキーがオフされている間、繰り返し実行されるものである。
最初のＳ８１において、受信があったか否かを判断する。この処理は、他車両からの情報受信があったか否かを判断するものである。ここで受信があったと判断された場合（Ｓ８１：ＹＥＳ）、Ｓ８２へ移行する。一方、受信がないと判断された場合（Ｓ８１：ＮＯ）、以降の処理を実行せず、本削除処理を終了する。
【００６５】
Ｓ８２では、受信した情報が削除要求であるか否かを判断する。この処理は、図１４中のＳ７３又はＳ７４の削除要求の送信に対応するものである。したがって、ここでは、受信された情報に「削除要求ＩＤ」が含まれているか否かを判断する。ここで削除要求であると判断された場合（Ｓ８２：ＹＥＳ）、Ｓ８３へ移行する。一方、削除要求でないと判断された場合（Ｓ８２：ＮＯ）、以降の処理を実行せず、本削除処理を終了する。
【００６６】
Ｓ８３では、自車両宛か否かを判断する。図１４中のＳ７３又はＳ７４では、離脱車両の送信元車両及び送信先車両へ向けて、削除要求が送信される。具体的には、「宛先車両ＩＤ」として、離脱車両の送信元車両ＩＤ及び送信先車両ＩＤが送信される。したがって、ここでは、宛先車両ＩＤが自車両のＩＤに一致するか否かを判断する。ここで自車両宛であると判断された場合（Ｓ８３：ＹＥＳ）、Ｓ８４へ移行する。一方、自車両宛でないと判断された場合（Ｓ８３：ＮＯ）、以降の処理を実行せずに、本削除処理を終了する。
【００６７】
Ｓ８４では、離脱車両から見て自車両が送信元車両であるか否かを判断する。ここで離脱車両から見て自車両が送信元車両でない場合（Ｓ８４：ＮＯ）、Ｓ８５にて自車両の送信元車両を離脱車両の送信元車両に変更し、本削除処理を終了する。一方、離脱車両から見て自車両が送信元車両である場合（Ｓ８４：ＹＥＳ）、Ｓ８６へ移行する。
【００６８】
Ｓ８６では、末端復帰要求があるか否かを判断する。図１４中のＳ７３にて削除要求が送信されるときは、上述したように「末端復帰要求を示す情報」が含まれる。ここで末端復帰要求があると判断された場合（Ｓ８６：ＹＥＳ）、Ｓ８７にて末端フラグをＯＮにし、Ｓ８８へ移行する。一方、末端復帰要求がないと判断された場合（Ｓ８６：ＮＯ）、Ｓ８７の処理を実行せず、Ｓ８８へ移行する。Ｓ８８では、自車両の送信先車両を離脱車両の送信先車両に変更し、その後、本削除処理を終了する。
【００６９】
ここで、図１４及び図１５を用いて説明した削除要求処理及び削除処理に対する理解を容易にするため、図１６及び図１７を用いて具体的な説明を加える。
【００７０】
なお、実際には各車両４３０〜４７０に搭載されるナビゲーション装置１のＥＣＵ１０が処理実行の主体となるが、煩雑になることを避ける意味で、ここでは、Ｉ〜Ｍの各車両４３０〜４７０を主体とした記載とする。図１６に示すように、Ｉ〜Ｍの５台の車両４３０〜４７０がグループを形成しているものとする。このとき末端車両はＭ車両４７０であるものとして以下説明を続ける。
【００７１】
最初に、図１６（ａ）に示すように、Ｋ車両４５０が離脱車両である場合を説明する。Ｋ車両４５０は、エンジン始動後、利用者によってグループからの削除指示がなされると（図１４中のＳ７１：ＹＥＳ）、削除要求を送信する（Ｓ７４、図１７中のＵ１、Ｕ２）。このとき、Ｋ車両４５０は末端車両でないため、図１４中のＳ７２にて否定判断されて、末端復帰要求のない第二の削除要求が送信される。削除要求は、送信元車両であるＪ車両４４０と、送信先車両であるＬ車両４６０とへ送信される。
【００７２】
これに対し、Ｊ車両４４０及びＬ車両４６０は、受信情報が自車両宛であると判断した後（図１５中のＳ８３：ＹＥＳ）、自車両が送信元車両であるか否かを判断する（Ｓ８４）。このとき、離脱車両であるＫ車両４５０から見ると、Ｊ車両４４０が送信元車両であるため、Ｊ車両４４０においては、Ｓ８４で肯定判断されることになる。
【００７３】
このとき末端復帰要求はないため（Ｓ８６：ＮＯ）、Ｊ車両４４０は、その送信先車両を離脱車両の送信先車両であるＬ車両４６０へ変更する（Ｓ８８）。一方、Ｌ車両４６０は、その送信元車両を離脱車両の送信元車両であるＫ車両４４０へ変更する（Ｓ８５）。
【００７４】
次に、図１６（ｂ）に示すように、Ｍ車両４７０が離脱車両である場合を説明する。Ｍ車両４７０は、エンジン始動後、利用者によってグループからの削除指示がなされると（図１４中のＳ７１：ＹＥＳ）、削除要求を送信する（Ｓ７３、図１７中のＵ１、Ｕ２）。このとき、Ｍ車両４７０は末端車両であるため、図１４中のＳ７２にて肯定判断され、末端復帰要求のある第一の削除要求が送信される。削除要求は、送信元車両であるＬ車両４６０と、送信先車両であるＩ車両４３０とへ送信される。
【００７５】
これに対し、Ｌ車両４６０及びＩ車両４３０は、受信情報が自車両宛であると判断した後（図１５中のＳ８３：ＹＥＳ）、自車両が送信元車両であるか否かを判断する（Ｓ８４）。このとき、離脱車両であるＭ車両４７０から見ると、Ｌ車両４６０が送信元車両であるため、Ｌ車両４６０においては、Ｓ８４で肯定判断されることになる。
【００７６】
このとき末端復帰要求があるため（Ｓ８６：ＹＥＳ、図１７中のＵ３）、Ｌ車両４６０は、末端復帰フラグをＯＮとし（Ｓ８７）、その後、送信先車両を離脱車両の送信先車両であるＩ車両４３０へ変更する（Ｓ８８）。一方、Ｉ車両４３０は、その送信元車両を離脱車両の送信元車両であるＬ車両４６０へ変更する（Ｓ８５）。
【００７７】
次に、本実施形態のナビゲーション装置１が奏する効果について説明する。
本実施形態では、図３に示したように、Ｌ車両４６０は、送信元車両であるＫ車両４５０からの情報受信を繰り返す（図７参照）。これにより、Ｋ車両４５０に発生する異常を監視する。また、Ｌ車両４６０は、Ｋ車両４５０からの情報受信と並行して、送信先車両であるＩ車両４３０への情報送信を繰り返す（図６参照）。これにより、Ｌ車両４６０に発生する異常は、Ｉ車両４３０によって監視されることになる。つまり、各車両は、送信元車両に発生する異常を監視すると共に、送信先車両によって、自車両に発生する異常を監視してもらうのである。そして、Ｌ車両４６０は、Ｋ車両４５０からの情報受信が途絶えると（図８中のＳ４２：ＹＥＳ）、Ｋ車両４５０に異常があったものとして、異常時処理を実行する（Ｓ４４）。なお、異常時処理では、セキュリティ部５０の警報音発生部５２から警報音が発生させられる。
【００７８】
このように、駐車中の車両同士、つまり移動しない車両同士でグループを形成するため、常に安定した通信を行うことができ、正確に他車両の異常を検出することができる。また、グループ内のいずれの車両も送信元車両の異常を検出することができ、グループ内において各車両の異常を確実に検出可能となる。
【００７９】
また、本実施形態では、異常時処理を行うＬ車両４６０は、送信フラグ及び発報フラグを共にＯＮとし（図８中のＳ４３）、即座に、発報伝聞情報を送信先車両であるＩ車両４３０へ送信する（図６中のＳ２１：ＹＥＳ、Ｓ２２：ＹＥＳ、Ｓ２４）。その結果、Ｉ車両４３０は、Ｌ車両４６０と同様、異常時処理を実行し（図８中のＳ４４）、このとき、送信フラグ及び発報フラグを共にＯＮとし（Ｓ４３）、即座に、発報伝聞情報を送信先車両であるＪ車両４４０へ送信する（図６中のＳ２１：ＹＥＳ、Ｓ２２：ＹＥＳ、Ｓ２４）。Ｊ車両４４０も同様に異常時処理を実行する（図８中のＳ４４）。これにより、グループを形成する車両の異常を検知した車両以外の複数の車両が、異常時処理を実行することになり、防犯効果の一層の向上が図られる。
【００８０】
しかも、ここでは送信フラグがＯＮにされることで、発報伝聞情報が即座に送信先車両へ送信される。この意味で『前記送信手段は、前記異常時処理の実行後にあっては、前記発報伝聞情報を前記送信先車両へ即座に送信すること』としてもよい。この点でも、防犯効果の向上に寄与する。
【００８１】
さらにまた、本実施形態では、上述したように、各車両が、送信元車両に発生する異常を監視すると共に、送信先車両によって自車両に発生する異常を監視してもらうように構成されている。しかも、車両毎に送信先車両及び送信先車両を異なるものとしている（図３参照）。この意味で『複数台（Ｎ台）の車両のうち自車両が第ｎ台目の車両である場合、前記送信元車両は第（ｎ−１）台目の車両であり、前記送信先車両は第（ｎ＋１）台目の車両であること（ｎ＝２、３、４、・・・、Ｎ−１）』としてもよい。これにより、特定の車両のみの処理負荷が大きくなることを低減できる。
【００８２】
また、本実施形態では、図９及び図１０に示した追加要求処理及び追加処理により、また、図１４及び図１５に示した削除要求処理及び削除処理により、車両のグループを動的に構成できるため、当該システムの実効性を向上させることができる。
【００８３】
以上本発明は、上述した実施形態に何等限定されるものではなく、本発明の趣旨を逸脱しない範囲において、種々なる形態で実施できることは言うまでもない。
【００８４】
（イ）上記実施形態では、グループへの追加要求処理（図９参照）において、新規車両側で、最も近い末端車両を選択していた（Ｓ５５）。これに対し、新規車両が追加要求を送信する際（Ｓ５２）、自車両の位置を送信する構成とし、グループ側で通信を行い、最も近い末端車両のみが局設定要求を送信する構成としてもよい。
また、例えば、末端車両の位置を基に、地図データ記憶部３０に記憶された地図データを用い、新規車両と末端車両とが同一施設（例えば、同一駐車場）に存在するか否かを判断するようにしてもよい。このように、同一施設に駐車されている車両同士でグループを形成することにより、グループ内の車両に異常が検出された場合、同一施設に駐車されているグループ内の他の車両により異常時処理を行うことが可能となり、防犯効果の一層の向上が図られる。
【００８５】
（ロ）上記実施形態では、異常を検知した車両は発報伝聞情報を送信先車両へ送信するようにしており、発報伝聞情報を受信した車両がさらに、その車両の送信先車両へ送信するように構成していた。これに対し、追加要求の送信時に返信があった車両全てと定期的に通信を行うシステムとして、異常を検知した自車両が、定期的な通信を行う車両すべてに対し、発報伝聞情報を送信する構成としてもよい。この意味で『前記送信手段は、前記異常時処理の実行後にあっては、前記情報としての発報伝聞情報を全車両に対し送信すること』としてもよい。このようにすれば、全車両が即座に警報音を発生するという点で有利である。
【００８６】
（ハ）上記実施形態において、各車両が測る第一の所定時間を、車両が駐車された地域の特性に基づいて設定する構成としてもよい。例えば、繁華街など車両の盗難事件が多発する区画に車両が駐車されたことを地図データ記憶部３０の地図データに基づいて判断し、第一の所定時間を相対的に短くするようにしてもよい（例えば、２分）。この意味で『送信手段は、予め記憶されている地図情報に基づいて、前記第一の所定時間を動的に設定可能であること』としてもよい。このようにすれば、地域に応じた適切な防犯効果が得られることになる。
【００８７】
（ニ）上記実施形態ではセキュリティ部５０の警報音発生部５２を介して警報音を発生させているが、例えば車両周辺の写真撮影などを行う構成としても、防犯効果を向上させることができる。盗難現場における写真撮影であるため、窃取状況や窃取行為を行う人物を撮影できる可能性が高いためである。
【図面の簡単な説明】
【００８８】
【図１】実施形態のナビゲーション装置の概略構成を示すブロック図である。
【図２】グループの形成を示す説明図である。
【図３】形成されたグループにおける車車間通信を示す説明図である。
【図４】グループが形成されたことを前提に実行されるメイン処理を示すフローチャートである。
【図５】メイン処理における送信フラグ管理処理を示すフローチャートである。
【図６】メイン処理における送信処理を示すフローチャートである。
【図７】メイン処理における受信処理を示すフローチャートである。
【図８】メイン処理における異常処理を示すフローチャートである。
【図９】グループへの新規車両の追加に際し実行される追加要求処理を示すフローチャートである。
【図１０】グループへの新規車両の追加に際し追加要求処理に対応して実行される追加処理を示すフローチャートである。
【図１１】追加処理における局設定処理を示すフローチャートである。
【図１２】新規車両の追加を示す説明図である。
【図１３】追加要求処理と追加処理との対応を示す説明図である。
【図１４】グループからの離脱車両の削除に際し実行される削除要求処理を示すフローチャートである。
【図１５】グループからの離脱車両の削除に際し削除要求処理に対応して実行される削除処理を示すフローチャートである。
【図１６】離脱車両の削除を示す説明図である。
【図１７】削除要求処理と削除処理との対応を示す説明図である。
【符号の説明】
【００８９】
１…ナビゲーション装置、１０…ＥＣＵ（車両特定手段、送信手段、受信手段、異常時処理実行手段、発報処理実行手段）、２０…ＧＰＳ受信機、３０…地図データ記憶部、４０…通信部、５０…セキュリティ部、５１…操作ボタン、５２…警報音発生部、４００〜４７０…車両
【技術分野】
【０００１】
本発明は、ナビゲーション装置に関する。
【背景技術】
【０００２】
従来、盗難防止機能を有する車両が知られている。例えば、所有者でない者が不正な手段で車両を移動させようとした場合に、車両の窃取行為を判断してクラクションなどの警報音を発するセキュリティ装置がある。ところが、窃取行為が行われる場合、事前にセキュリティ装置の機能を停止させられることがあり、実際にはセキュリティ装置が機能しないことも往々にして起こり得る。
【０００３】
このような問題を解決するための手段として、携帯電話機などの車両の所有者の携帯端末装置を用いて車両の異常を検知するようにしたシステムが提案されている（例えば、特許文献１参照）。このシステムでは、車両から携帯端末装置への信号を送信し、この信号が途切れた場合に、車両に異常があったことを判断することが開示されている。
【０００４】
【特許文献１】特開２００６−３５９９０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記特許文献１に開示されるシステムでは、車両の所有者の携帯端末と通信を行うことで異常を検出しているが、携帯端末は移動してしまうため常に安定して通信が出来るとは限らず、安定して通信が出来ない場合には、車両に異常があったことを正確に判断することができなかった。例えば、携帯端末の所有者が電波の状況が悪い場所（例えば、地下など）に移動した場合には通信を行うことが出来ず、車両から送信される信号を受信することが不可能となるため、車両の異常と判断してしまう虞がある。
【０００６】
本発明は、上述した問題に鑑みてなされたものであり、その目的は、防犯効果を向上させたセキュリティ機能を有するナビゲーション装置を提供することにある。
【課題を解決するための手段】
【０００７】
本発明のナビゲーション装置は、自車両の防犯機能の開始要求を検出した場合に、駐車中の車両と通信を行うナビゲーション装置であって、通信を行う駐車中の車両として、送信先車両、及び送信元車両を特定する車両特定手段と、設定された第一の所定時間間隔で送信先車両へ自車両確認伝聞情報を送信する送信手段と、送信元車両から送信元車両確認伝聞情報を受信する受信手段と、受信手段にて第一の所定時間に基づく第二の所定時間が経過しても送信元車両確認伝聞情報が受信されない場合、異常時に対応する異常時処理を実行する異常時処理実行手段と、を備えていることを特徴とする。
【０００８】
本発明によれば、自車両から情報を送信する車両である「送信先車両」、及び、自車両へ情報を送信してくる「送信元車両」が特定される。そして、送信元車両から送信されてくるはずの送信元車両確認伝聞情報が途切れた場合、送信元車両に異常が発生したものとされ、異常時に対応する異常時処理が実行される。この異常時処理には、例えば、クラクションの鳴動などによる警報音の発生などが含まれる。
【０００９】
つまり、駐車中の車両同士、即ち移動しない車両同士でグループを形成して常に安定した通信を行い、通信が途切れた場合に他車両（送信元車両）の異常を自車両が検出する。なお、送信元車両と送信先車両とが同一車両となっても差し支えない。このようにすれば、正確に他車両の異常を検出することができ、防犯効果の向上が図られる。
【００１０】
このようなナビゲーション装置を各車両が備えることで、いずれの車両も送信元車両の異常を検出することができ、グループ内において各車両の異常を確実に検出可能となる。
【００１１】
また、送信手段は、異常時処理の実行後にあっては、自車両発報伝聞情報を送信するよう構成されており、受信手段にて送信元車両発報伝聞情報が受信された場合、異常時処理を実行する発報処理実行手段を備えていることとしてもよい。
【００１２】
送信元車両に異常が発生したと判断した場合に異常時処理が実行されることは既に述べたが、この異常時処理の実行後にあっては、自車両発報伝聞情報が送信先車両へ送信される。一方、送信元車両から送信元車両発報伝聞情報が受信された場合、発報処理実行手段によって、異常時処理が実行される。このようなナビゲーション装置を各車両が備えることで、グループを形成する車両の異常を検知した車両以外の複数の車両が、異常時処理を実行することになり、防犯効果の一層の向上が図られる。
【００１３】
以上は、ナビゲーション装置の発明として説明してきたが、このようなナビゲーション装置の機能はコンピュータシステムにて実現されるため、プログラムの発明として実現することもできる。
すなわち、自車両の防犯機能の開始要求を検出した場合に、駐車中の車両と通信を行うためのプログラムであって、通信を行う駐車中の車両として、送信先車両、及び送信元車両を特定する車両特定処理と、設定された第一の所定時間間隔で送信先車両へ自車両確認伝聞情報を送信する送信処理と、送信元車両から送信元車両確認伝聞情報を受信する受信処理と、受信処理にて第一の所定時間に基づく第二の所定時間が経過しても送信元車両確認伝聞情報が受信されない場合に実行される異常時に対応する異常時処理とを含むことを特徴とするプログラムである。このようなプログラムを実行することで、上述のナビゲーション装置と同様の効果が奏される。
【発明を実施するための最良の形態】
【００１４】
以下、本発明の実施形態を図面に基づいて説明する。
図１は、本実施形態のナビゲーション装置１の全体構成を示す概略ブロック図である。本実施形態のナビゲーション装置１は、後述するように車両に搭載されて用いられ、車車間通信により車両同士で防犯機能を実現する。
ナビゲーション装置１は、電子制御装置（以下「ＥＣＵ」という）１０を中心に構成されている。ＥＣＵ１０には、ＧＰＳ（Global Positining System）受信機２０、地図データ記憶部３０、通信部４０、及び、セキュリティ部５０が電気的に接続されている。
【００１５】
ＥＣＵ１０は、いわゆるコンピュータシステムとして構成されており、内部にはＣＰＵ、ＲＯＭ、ＲＡＭ、及び、Ｉ／Ｏなどを備えている。なお、ＣＰＵはフリーランカウンタを有しており、このフリーランカウンタの値を取得することで計時可能となっている。
ＧＰＳ受信機２０は、衛星からの電波を受信する。この電波に基づく測位によって、自車位置を検出することが可能となっている。もちろん、図示しない地磁気センサ、ジャイロスコープ、距離センサなどと、相互に補完しながら自車位置を検出しても良いし、ＧＰＳ受信機２０を用いずに自車位置を検出してもよい。
【００１６】
地図データ記憶部３０は、例えばハードディスク装置（ＨＤＤ）として実現される記憶装置である。なお、他の記憶媒体を用いても差し支えない。この地図データ記憶部３０は、位置検出の精度向上のためのいわゆるマップマッチング用データおよび経路を探索するための地図データを記憶している。地図データには、各種データが含まれるが、その一つとして施設に関する施設情報が含まれる。施設情報は、具体的には、施設を特定するＩＤと関連づけて記憶されているＰＯＩ（Point Of Interest ）情報である。ＰＯＩ情報には、施設ＩＤ、住所、種別（ジャンル）、領域データ（領域の外周座標、中心座標等）、などが含まれる。例えば、駐車場の情報も施設情報として記憶されている。
【００１７】
通信部４０は、無線通信を行うための構成である。本実施形態のナビゲーション装置１は、複数台の車両に搭載されて用いられる。このとき各車両同士の間で車車間通信を可能とするのが、この通信部４０である。
セキュリティ部５０は、防犯のための構成である。具体的には、防犯機能の開始及び終了を指示するための操作ボタン５１、及び、警報音を発生する警報音発生部５２を具備してなる。
【００１８】
このように構成されたナビゲーション装置１が複数台の車両に搭載されることは、既に述べた。本実施形態では、当該複数台の車両がグループを形成し、このグループ内で通信を行うことを特徴とする。そこで次に、グループの形成について説明する。
【００１９】
図２は、グループの形成を示す説明図である。図２に示すように、駐車場Ｃには、複数台（ここでは７台）の車両４００、４１０、４２０、４３０、４４０、４５０、４６０が駐車されている。以下、車両４００〜４６０を区別するため、図２中の記号を用い、Ｆ車両４００、Ｇ車両４１０、Ｈ車両４２０、Ｉ車両４３０、Ｊ車両４４０、Ｋ車両４５０、Ｌ車両４６０と記述する。
【００２０】
図２では、Ｆ〜Ｌの車両４００〜４６０が２つのグループＤ、Ｅを形成している。より詳しくは、Ｆ〜Ｈの３台の車両４００〜４２０がグループＤを形成し、Ｉ〜Ｌの４台の車両４３０〜４６０がグループＥを形成している。本実施形態では、このようなグループを形成することにより、グループ単位で通信処理を行う。例えば、グループＥについて見ると、図３に示すように、Ｉ車両４３０からＪ車両４４０への情報送信が行われ、Ｊ車両４４０からＫ車両４５０への情報送信が行われ、Ｋ車両４５０からＬ車両４６０への情報送信が行われ、Ｌ車両４６０からＩ車両４３０への情報送信が行われるという具合である。
【００２１】
なお、以下では、ある車両から見て、情報の送信先となる車両を「送信先車両」、情報の送信元となる車両を「送信元車両」というものとする。図３において一例を挙げると、Ｌ車両４６０から見て、Ｉ車両４３０が「送信先車両」であり、Ｋ車両４５０が「送信元車両」である。
【００２２】
このようなグループが形成された後、Ｉ〜Ｌの各車両４３０〜４６０のナビゲーション装置１では、メイン処理が繰り返し実行されることになる。そこで次に、このメイン処理について説明する。
【００２３】
図４は、メイン処理を示すフローチャートである。
メイン処理は、ステップ（以下「ステップ」を単に記号Ｓで示す）１０の送信フラグ管理処理、Ｓ２０の送信処理、Ｓ３０の受信処理、及び、Ｓ４０の異常処理からなる。これらの処理を順に説明していく。
【００２４】
図５に示すように、送信フラグ管理処理では、最初のＳ１１において、前回の送信から第一の所定時間（例えば、３分）が経過したか否かを判断する。前回の送信から第一の所定時間の経過はＥＣＵ１０のＣＰＵが有するフリーランカウンタの値に基づき判断することが例示される。ここで第一の所定時間が経過したと判断された場合（Ｓ１１：ＹＥＳ）、Ｓ１２にて送信フラグをＯＮにし、その後、本送信フラグ管理処理を終了する。一方、第一の所定時間が経過していないと判断された場合（Ｓ１１：ＮＯ）、Ｓ１２の処理を実行せず、本送信フラグ管理処理を終了する。
【００２５】
また、図６に示すように、送信処理では、最初のＳ２１において、送信フラグがＯＮであるか否かを判断する。上述したように、送信フラグは、第一の所定時間が経過したときにＯＮとなる（図５中のＳ１１：ＹＥＳ、Ｓ１２）。ここで送信フラグがＯＮであると判断された場合（Ｓ２１：ＹＥＳ）、Ｓ２２へ移行する。一方、送信フラグがＯＮでないと判断された場合（Ｓ２１：ＮＯ）、すなわち送信フラグがＯＦＦの場合には、以降の処理を実行せず、本送信処理を終了する。
【００２６】
Ｓ２２では、発報フラグがＯＮであるか否かを判断する。この発報フラグについては後述する。ここで発報フラグがＯＮであると判断された場合（Ｓ２２：ＹＥＳ）、Ｓ２４にて発報伝聞情報を送信先車両へ送信し、その後、本送信処理を終了する。一方、発報フラグがＯＮでないと判断された場合（Ｓ２２：ＮＯ）、すなわち発報フラグがＯＦＦである場合には、Ｓ２３にて確認伝聞情報を送信先車両へ送信すると共に送信フラグをＯＦＦとし、その後、本送信処理を終了する。
【００２７】
これらの情報の送信は、図１に示した通信部４０を介して行われる。発報伝聞情報には、「発報伝聞ＩＤ」及び送信先車両のＩＤである「宛先車両ＩＤ」が含まれる。同様に、確認伝聞情報には、「確認伝聞ＩＤ」及び送信先車両のＩＤである「宛先車両ＩＤ」が含まれる。
【００２８】
このように、本実施形態では、送信フラグ管理処理及び送信処理を繰り返し実行することにより、第一の所定時間間隔で、送信先車両へ情報を送信する。この意味で、ＥＣＵ１０が「送信手段」を構成し、送信フラグ管理処理及び送信処理が「送信手段」の機能としての「送信処理」に相当する。
【００２９】
図７に示すように、受信処理では、最初のＳ３１において、通信部４０を介し情報を受信したか否かを判断する。この処理は、図１に示した通信部４０を介した情報の受信があったか否かを判断するものである。ここで情報を受信したと判断された場合（Ｓ３１：ＹＥＳ）、Ｓ３２へ移行する。一方、情報を受信していないと判断された場合（Ｓ３１：ＮＯ）、以降の処理を実行せず、本受信処理を終了する。
【００３０】
Ｓ３２では、受信した情報が自車両宛か否かを判断する。これは、送信された情報に含まれる「宛先車両ＩＤ」が自車両のＩＤと一致しているか否かで判断される。ここで自車両宛であると判断された場合（Ｓ３２：ＹＥＳ）、Ｓ３３にて受信フラグをＯＮにし、本受信処理を終了する。一方、自車両宛でないと判断された場合（Ｓ３２：ＮＯ）、Ｓ３３の処理を実行せず、本受信処理を終了する。
【００３１】
また、図８に示すように、異常処理では、最初のＳ４１において、受信フラグがＯＮであるか否かを判断する。上述したように、受信フラグは、自車両宛の情報を受信したときにＯＮとなる（図７中のＳ３１：ＹＥＳ、Ｓ３２：ＹＥＳ、Ｓ３３）。ここで受信フラグがＯＮであると判断された場合（Ｓ４１：ＹＥＳ）、Ｓ４５へ移行する。一方、受信フラグがＯＮでないと判断された場合（Ｓ４１：ＮＯ）、すなわち自車両宛の情報が受信されないうちは、Ｓ４２へ移行する。
【００３２】
Ｓ４２では、第二の所定時間が経過したか否かを判断する。この第二の所定時間は、上述した第一の所定時間に基づくものであり、具体的には、第一の所定時間と同一か、あるいは、第一の所定時間よりも長い時間として設定される。また、第一の所定時間の経過と同様、第二の所定時間の経過はＥＣＵ１０のＣＰＵが有するフリーランカウンタの値に基づき判断することが例示される。ここで第二の所定時間が経過したと判断された場合（Ｓ４２：ＹＥＳ）、Ｓ４３へ移行する。一方、第二の所定時間が経過していないと判断された場合（Ｓ４２：ＮＯ）、以降の処理を実行せず、本異常処理を終了する。
【００３３】
第二の所定時間が経過した場合に移行するＳ４３では、送信フラグ及び発報フラグを共にＯＮにする。続くＳ４４では異常時処理を実行し、その後、本異常処理を終了する。Ｓ４４における異常時処理では、セキュリティ部５０の警報音発生部５２を介し、警報音を発生させる。なお、本実施形態では、警報音発生部５２を備える構成としたが、例えば、クラクションを鳴動させるようにしてもよい。
【００３４】
受信フラグがＯＮであると判断された場合に移行するＳ４５では、受信フラグをＯＦＦにする。
続くＳ４６では、受信した情報が発報伝聞情報であるか否かを判断する。この発報伝聞情報には、「発報伝聞ＩＤ」が含まれる。したがって、ここでは受信情報に「発報伝聞ＩＤ」があるか否かを判断する。発報伝聞情報であると判断された場合（Ｓ４６：ＹＥＳ）、第二の所定時間が経過した場合と同様、Ｓ４３にて送信フラグ及び発報フラグを共にＯＮとし、Ｓ４４にて異常時処理を実行して、本異常処理を終了する。一方、発報伝聞情報でないと判断された場合（Ｓ４６：ＮＯ）、すなわち確認伝聞情報である場合には、本異常処理を終了する。
【００３５】
このように本実施形態では、繰り返し自車両宛の情報受信を行い（図７中のＳ３１、Ｓ３２）、情報が受信されないまま第二の所定時間が経過すると（図８中のＳ４１：ＮＯ、Ｓ４２：ＹＥＳ）、異常時処理が実行されるようになっている（Ｓ４４）。この意味で、ＥＣＵ１０が「受信手段」、「異常時処理実行手段」及び「発報処理実行手段」を構成し、図７に示した受信処理が「受信手段」の機能としての「受信処理」に相当し、図８に示した異常処理のＳ４４が「異常時処理実行手段」及び「発報処理実行手段」の機能としての「異常時処理」に相当する。
【００３６】
ところで、Ｓ４４の異常時処理が実行されるときには、必ずＳ４３にて、送信フラグ及び発報フラグがＯＮとなる。これによって、異常時処理が一度実行されると、図６中のＳ２２にて肯定判断されることになり、発報伝聞情報が送信先車両へ送信されることになる（Ｓ２４）。また、このときは、送信フラグもＯＮとなっているため、第一の所定時間の経過を待たずに、発報伝聞情報が送信されることになる。
【００３７】
一方、発報伝聞情報を受信する送信先車両では、図８に示した異常処理のＳ４６にて肯定判断され、送信フラグ及び発報フラグが共にＯＮとなり（Ｓ４３）、異常時処理が実行される（Ｓ４４）。これにより、順次、発報伝聞情報がグループを形成する各車両へ送信されることになる。
【００３８】
この点、図３を用いて具体的に説明する。なお、実際には各車両４３０〜４６０に搭載されるナビゲーション装置１のＥＣＵ１０が処理実行の主体となるが、煩雑になることを避ける意味で、ここでは、Ｉ〜Ｌの各車両４３０〜４６０を主体とした記載とする。
【００３９】
例えばＬ車両４６０は、送信元車両であるＫ車両４５０からの情報受信を繰り返す（図７参照）。これにより、Ｋ車両４５０に発生する異常を監視する。また、Ｌ車両４６０は、Ｋ車両４５０からの情報受信と並行して、送信先車両であるＩ車両４３０への情報送信を繰り返す（図６参照）。これにより、Ｌ車両４６０に発生する異常は、Ｉ車両４３０によって監視されることになる。つまり、各車両は、送信元車両に発生する異常を監視すると共に、送信先車両によって、自車両に発生する異常を監視してもらうのである。
【００４０】
ここで例えば、Ｌ車両４６０について見ると、Ｋ車両４５０からの情報受信が途絶えると（図８中のＳ４２：ＹＥＳ）、Ｌ車両４６０は、Ｋ車両４５０に異常があったものとして、異常時処理を実行する（Ｓ４４）。このときＬ車両４６０は、送信フラグ及び発報フラグを共にＯＮとし（Ｓ４３）、即座に、発報伝聞情報を送信先車両であるＩ車両４３０へ送信する（図６中のＳ２１：ＹＥＳ、Ｓ２２：ＹＥＳ、Ｓ２４）。
【００４１】
その結果、Ｉ車両４３０は、Ｌ車両４６０と同様、異常時処理を実行し（図８中のＳ４４）、このとき、送信フラグ及び発報フラグを共にＯＮとし（Ｓ４３）、即座に、発報伝聞情報を送信先車両であるＪ車両４４０へ送信する（図６中のＳ２１：ＹＥＳ、Ｓ２２：ＹＥＳ、Ｓ２４）。Ｊ車両４４０も同様に異常時処理を実行する（Ｓ４４）。
【００４２】
以上、グループが形成されている状態での通信処理について説明した。次に、グループを形成するための通信処理について説明する。
ここでは最初にグループへの車両の追加について、図９〜図１３を用い説明する。次に、グループからの車両の削除について、図１４〜図１７を用い説明する。
【００４３】
図９は、追加要求処理を示すフローチャートである。この処理は、形成されたグループへの追加を要求する新規車両にて実行されるものであり、駐車後に繰り返し実行される。
最初のＳ５１では、利用者からの追加指示があったか否かを判断する。この処理は、セキュリティ部５０の操作ボタン５１の操作を判断するものであり、グループへの追加指示があったか否かを判断するものである。ここで追加指示があったと判断された場合（Ｓ５１：ＹＥＳ）、Ｓ５２へ移行する。一方、追加指示がないと判断された場合（Ｓ５１：ＮＯ）、以降の処理を実行せず、本追加要求処理を終了する。
【００４４】
Ｓ５２では、グループへの追加要求を送信する。この処理は、車両を特定せずに行われる。この追加要求には、「追加要求ＩＤ」及び「新規車両（自車両）のＩＤ」が送信される。
【００４５】
続くＳ５３では、局設定要求があったか否かを判断する。局設定要求には、「局設定要求ＩＤ」、「末端車両のＩＤ」、「末端車両の位置」及び当該末端車両の送信先車両としての「先頭車両のＩＤ」が含まれる。この局設定要求は、後述するように、グループを形成している車両のうち末端車両から送信されるものである。本実施形態において、末端車両は、最後にグループに追加された車両である。したがって、さらに自車両が追加されれば、次は、自車両が末端車両となる。ここで局設定要求がないと判断された場合（Ｓ５３：ＮＯ）、Ｓ５４へ移行する。一方、局設定要求があったと判断された場合（Ｓ５３：ＹＥＳ）、Ｓ５５へ移行する。
【００４６】
Ｓ５４では、第三の所定時間が経過したか否かを判断する。この判断は、ＥＣＵ１０のＣＰＵが有するフリーランカウンタの値を参照することで行うことが例示される。ここで所定時間が経過したと判断された場合（Ｓ５４：ＹＥＳ）、本追加要求処理を終了する。一方、所定時間が経過していないと判断された場合（Ｓ５４：ＮＯ）、Ｓ５３の判断処理を繰り返す。つまり、Ｓ５３及びＳ５４によって、末端車両から局設定要求があったか否かの判断が、所定時間繰り返されることになる。
【００４７】
Ｓ５５では、新規車両に最も近い末端車両を選択する。複数のグループが存在する場合、複数台の末端車両が存在する。したがって、ここではＧＰＳ受信機２４にて取得される新規車両（自車両）の位置、局設定要求として送信される「末端車両の位置」及び地図データ記憶部３０の地図データに基づき、新規車両に最も近い末端車両を選択する。
【００４８】
次のＳ５６では、局設定応答を送信する。ここでは、「局設定応答ＩＤ」、情報送信の宛先となる「宛先車両ＩＤ」、及び「自車両ＩＤ」が送信される。宛先車両は、末端車両及び先頭車両である。したがって、「宛先車両ＩＤ」は、末端車両ＩＤ及び先頭車両ＩＤとなる。
続くＳ５７では末端フラグをＯＮとする。これにより、自車両が次の末端車両となる。Ｓ５８の処理終了後、本追加要求処理を終了する。
【００４９】
次に、図９の追加要求処理に対応する追加処理を、図１０を参照して説明する。この追加処理は、イグニッションキーがオフされている間、繰り返し実行されるものである。
最初のＳ６１において、他車両からの情報受信があったか否かを判断するものである。ここで受信があったと判断された場合（Ｓ６１：ＹＥＳ）、Ｓ６２へ移行する。一方、受信がないと判断された場合（Ｓ６１：ＮＯ）、以降の処理を実行せず、本追加処理を終了する。
【００５０】
Ｓ６２では、受信した情報が追加要求であるか否かを判断する。この処理は、図９中のＳ５２の追加要求の送信に対応するものである。したがって、ここでは、受信された情報に「追加要求ＩＤ」が含まれているか否かを判断する。ここで追加要求であると判断された場合（Ｓ６２：ＹＥＳ）、Ｓ６３へ移行する。一方、追加要求でないと判断された場合（Ｓ６２：ＮＯ）、Ｓ６３及びＳ６４の処理を実行せず、Ｓ６５へ移行する。
【００５１】
Ｓ６３では、末端フラグがＯＮであるか否かを判断する。この処理は、自車両が末端車両であるか否かを判断するものである。ここで末端フラグがＯＮであると判断された場合（Ｓ６３：ＹＥＳ）、Ｓ６４へ移行する。一方、末端フラグがＯＮでないと判断された場合（Ｓ６３：ＮＯ）、Ｓ６４の処理を実行せず、Ｓ６５へ移行する。
【００５２】
Ｓ６４では、局設定要求を送信する。この局設定要求には、「局設定要求ＩＤ」、「自車両ＩＤ」、「自車両の位置」及び自車両の送信先車両である「先頭車両ＩＤ」が含まれる。これを新規車両側から見ると、上述したように「局設定要求ＩＤ」、「末端車両ＩＤ」、「末端車両の位置」及び「先頭車両ＩＤ」が送信されてくることになる。
【００５３】
Ｓ６５では、受信した情報が局設定応答であるか否かを判断する。この処理は、図９中のＳ５７の局設定応答送信に対応するものである。したがって、ここでは、受信された情報に「局設定応答ＩＤ」が含まれているか否かで判断する。ここで局設定応答であると判断された場合（Ｓ６５：ＹＥＳ）、Ｓ６６へ移行する。一方、局設定応答でないと判断された場合（Ｓ６５：ＮＯ）、Ｓ６６及びＳ６７の処理を実行せず、本追加処理を終了する。
【００５４】
Ｓ６６では、自車両宛か否かを判断する。図９中のＳ５７では、末端車両及び先頭車両へ向けて、局設定応答が送信される。具体的には、末端車両ＩＤ及び先頭車両ＩＤが「宛先車両ＩＤ」として送信される。したがって、ここでは、宛先車両ＩＤが自車両ＩＤに一致するか否かを判断する。ここで自車両宛であると判断された場合（Ｓ６６：ＹＥＳ）、Ｓ６７にて局設定処理を実行し、その後、本追加処理を終了する。Ｓ６７では、末端車両及び先頭車両において、局設定処理が実行されることになる。一方、自車両宛でないと判断された場合（Ｓ６６：ＮＯ）、Ｓ６７の処理を実行せず、本追加処理を終了する。
【００５５】
続けて、図１０中のＳ６７で実行される局設定処理の詳細を、図１１のフローチャートに基づいて説明する。
【００５６】
最初のＳ６７１では、末端フラグがＯＮであるか否かを判断する。これは、自車両が末端車両であるか否かを判断するものである。ここで末端フラグがＯＮであると判断された場合（Ｓ６７１：ＹＥＳ）、すなわち自車両が末端車両である場合には、Ｓ６７２にて末端フラグをＯＦＦとし、Ｓ６７３で送信先車両を新規車両に変更して、その後、局設定処理を終了する。一方、末端フラグがＯＮでないと判断された場合（Ｓ６７１：ＮＯ）、すなわち、自車両が先頭車両である場合には、Ｓ６７４にて送信元車両を新規車両に変更し、その後、局設定処理を終了する。
【００５７】
なお、本実施形態におけるＥＣＵ１０が「車両特定手段」を構成し、図９および図１０に示す追加要求処理、追加処理が「車両特定手段」の機能としての「車両特定処理」に相当する。
【００５８】
ここで、図９〜図１１を用いて説明した追加要求処理及び追加処理に対する理解を容易にするため、図１２及び図１３を用いて具体的な説明を加える。
【００５９】
図１２（ａ）に示すように、Ｉ〜Ｌの４台の車両４３０〜４６０がグループを形成しているものとする。このとき、末端車両はＬ車両４６０であり、先頭車両はＩ車両４３０であるものとして以下説明を続ける。なお、実際には各車両４３０〜４６０に搭載されるナビゲーション装置１のＥＣＵ１０が処理実行の主体となるが、煩雑になることを避ける意味で、ここでは、Ｉ〜Ｌの各車両４３０〜４６０を主体とした記載とする。
【００６０】
新規車両としてのＭ車両４７０は、その駐車後、利用者によってグループへの追加指示がなされると（図９中のＳ５１：ＹＥＳ）、追加要求を送信する（Ｓ５２、図１３中のＴ１）。このとき、末端車両の場合には図１０中のＳ６３にて肯定判断されるため、末端車両であるＬ車両４６０は、追加要求に応じて、局設定要求を送信する（Ｓ６４、図１３中のＴ２）。これに対し、新規車両であるＭ車両４７０は、複数台の末端車両がある場合、末端車両のうちで最も近い車両を選択し（図９中のＳ５５）、局設定応答を送信する（Ｓ５６、図１３中のＴ３、Ｔ４）。
【００６１】
これにより、末端車両であるＬ車両４６０及び先頭車両であるＩ車両４３０は、局設定処理を実行する（図１０中のＳ６７、図１１参照）。具体的に、末端車両であるＬ車両４６０は、末端フラグをＯＦＦとし（図１１中のＳ６７２）、送信先車両を新規車両であるＭ車両４７０へ変更する。一方、先頭車両であるＩ車両４３０は、送信元車両を新規車両であるＭ車両４７０へ変更する。これにより、図１２（ｂ）に示す如く、Ｍ車両４７０が末端車両として追加されることになる。
【００６２】
図１４は、削除要求処理を示すフローチャートである。この処理は、形成されたグループからの削除を要求する離脱車両にて実行されるものであり、エンジンの始動時に実行される。
最初のＳ７１では、利用者からの削除指示があったか否かを判断する。この処理は、セキュリティ部５０の操作ボタン５１の操作を判断するものであり、グループからの削除指示があったか否かを判断するものである。ここで削除指示があったと判断された場合（Ｓ７１：ＹＥＳ）、Ｓ７２へ移行する。一方、削除指示がないと判断された場合（Ｓ７１：ＮＯ）、以降の処理を実行せず、本削除要求処理を終了する。
【００６３】
Ｓ７２では、末端フラグがＯＮであるか否かを判断する。この処理は、離脱車両がグループの末端車両であったか否かを判断するものである。ここで末端フラグがＯＮである場合（Ｓ７２：ＹＥＳ）、Ｓ７３にて第一の削除要求を送信する。この第一の削除要求には、末端復帰要求が含まれる。具体的には、「宛先車両ＩＤ」、「削除要求ＩＤ」、自車両のＩＤである「離脱車両のＩＤ」及び「末端復帰要求を示す情報」が含まれる。一方、末端フラグがＯＮでない場合（Ｓ７２：ＮＯ）、Ｓ７４にて第二の削除要求を送信する。この第二の削除要求は、末端復帰要求を含まない。具体的には、「宛先車両ＩＤ」、「削除要求ＩＤ」及び「離脱車両ＩＤ」が含まれる。ここで「宛先車両ＩＤ」は、離脱車両の送信元車両ＩＤ及び送信先車両ＩＤである。
【００６４】
次に、図１４の削除要求処理に対応する削除処理を、図１５を参照して説明する。この削除処理は、イグニッションキーがオフされている間、繰り返し実行されるものである。
最初のＳ８１において、受信があったか否かを判断する。この処理は、他車両からの情報受信があったか否かを判断するものである。ここで受信があったと判断された場合（Ｓ８１：ＹＥＳ）、Ｓ８２へ移行する。一方、受信がないと判断された場合（Ｓ８１：ＮＯ）、以降の処理を実行せず、本削除処理を終了する。
【００６５】
Ｓ８２では、受信した情報が削除要求であるか否かを判断する。この処理は、図１４中のＳ７３又はＳ７４の削除要求の送信に対応するものである。したがって、ここでは、受信された情報に「削除要求ＩＤ」が含まれているか否かを判断する。ここで削除要求であると判断された場合（Ｓ８２：ＹＥＳ）、Ｓ８３へ移行する。一方、削除要求でないと判断された場合（Ｓ８２：ＮＯ）、以降の処理を実行せず、本削除処理を終了する。
【００６６】
Ｓ８３では、自車両宛か否かを判断する。図１４中のＳ７３又はＳ７４では、離脱車両の送信元車両及び送信先車両へ向けて、削除要求が送信される。具体的には、「宛先車両ＩＤ」として、離脱車両の送信元車両ＩＤ及び送信先車両ＩＤが送信される。したがって、ここでは、宛先車両ＩＤが自車両のＩＤに一致するか否かを判断する。ここで自車両宛であると判断された場合（Ｓ８３：ＹＥＳ）、Ｓ８４へ移行する。一方、自車両宛でないと判断された場合（Ｓ８３：ＮＯ）、以降の処理を実行せずに、本削除処理を終了する。
【００６７】
Ｓ８４では、離脱車両から見て自車両が送信元車両であるか否かを判断する。ここで離脱車両から見て自車両が送信元車両でない場合（Ｓ８４：ＮＯ）、Ｓ８５にて自車両の送信元車両を離脱車両の送信元車両に変更し、本削除処理を終了する。一方、離脱車両から見て自車両が送信元車両である場合（Ｓ８４：ＹＥＳ）、Ｓ８６へ移行する。
【００６８】
Ｓ８６では、末端復帰要求があるか否かを判断する。図１４中のＳ７３にて削除要求が送信されるときは、上述したように「末端復帰要求を示す情報」が含まれる。ここで末端復帰要求があると判断された場合（Ｓ８６：ＹＥＳ）、Ｓ８７にて末端フラグをＯＮにし、Ｓ８８へ移行する。一方、末端復帰要求がないと判断された場合（Ｓ８６：ＮＯ）、Ｓ８７の処理を実行せず、Ｓ８８へ移行する。Ｓ８８では、自車両の送信先車両を離脱車両の送信先車両に変更し、その後、本削除処理を終了する。
【００６９】
ここで、図１４及び図１５を用いて説明した削除要求処理及び削除処理に対する理解を容易にするため、図１６及び図１７を用いて具体的な説明を加える。
【００７０】
なお、実際には各車両４３０〜４７０に搭載されるナビゲーション装置１のＥＣＵ１０が処理実行の主体となるが、煩雑になることを避ける意味で、ここでは、Ｉ〜Ｍの各車両４３０〜４７０を主体とした記載とする。図１６に示すように、Ｉ〜Ｍの５台の車両４３０〜４７０がグループを形成しているものとする。このとき末端車両はＭ車両４７０であるものとして以下説明を続ける。
【００７１】
最初に、図１６（ａ）に示すように、Ｋ車両４５０が離脱車両である場合を説明する。Ｋ車両４５０は、エンジン始動後、利用者によってグループからの削除指示がなされると（図１４中のＳ７１：ＹＥＳ）、削除要求を送信する（Ｓ７４、図１７中のＵ１、Ｕ２）。このとき、Ｋ車両４５０は末端車両でないため、図１４中のＳ７２にて否定判断されて、末端復帰要求のない第二の削除要求が送信される。削除要求は、送信元車両であるＪ車両４４０と、送信先車両であるＬ車両４６０とへ送信される。
【００７２】
これに対し、Ｊ車両４４０及びＬ車両４６０は、受信情報が自車両宛であると判断した後（図１５中のＳ８３：ＹＥＳ）、自車両が送信元車両であるか否かを判断する（Ｓ８４）。このとき、離脱車両であるＫ車両４５０から見ると、Ｊ車両４４０が送信元車両であるため、Ｊ車両４４０においては、Ｓ８４で肯定判断されることになる。
【００７３】
このとき末端復帰要求はないため（Ｓ８６：ＮＯ）、Ｊ車両４４０は、その送信先車両を離脱車両の送信先車両であるＬ車両４６０へ変更する（Ｓ８８）。一方、Ｌ車両４６０は、その送信元車両を離脱車両の送信元車両であるＫ車両４４０へ変更する（Ｓ８５）。
【００７４】
次に、図１６（ｂ）に示すように、Ｍ車両４７０が離脱車両である場合を説明する。Ｍ車両４７０は、エンジン始動後、利用者によってグループからの削除指示がなされると（図１４中のＳ７１：ＹＥＳ）、削除要求を送信する（Ｓ７３、図１７中のＵ１、Ｕ２）。このとき、Ｍ車両４７０は末端車両であるため、図１４中のＳ７２にて肯定判断され、末端復帰要求のある第一の削除要求が送信される。削除要求は、送信元車両であるＬ車両４６０と、送信先車両であるＩ車両４３０とへ送信される。
【００７５】
これに対し、Ｌ車両４６０及びＩ車両４３０は、受信情報が自車両宛であると判断した後（図１５中のＳ８３：ＹＥＳ）、自車両が送信元車両であるか否かを判断する（Ｓ８４）。このとき、離脱車両であるＭ車両４７０から見ると、Ｌ車両４６０が送信元車両であるため、Ｌ車両４６０においては、Ｓ８４で肯定判断されることになる。
【００７６】
このとき末端復帰要求があるため（Ｓ８６：ＹＥＳ、図１７中のＵ３）、Ｌ車両４６０は、末端復帰フラグをＯＮとし（Ｓ８７）、その後、送信先車両を離脱車両の送信先車両であるＩ車両４３０へ変更する（Ｓ８８）。一方、Ｉ車両４３０は、その送信元車両を離脱車両の送信元車両であるＬ車両４６０へ変更する（Ｓ８５）。
【００７７】
次に、本実施形態のナビゲーション装置１が奏する効果について説明する。
本実施形態では、図３に示したように、Ｌ車両４６０は、送信元車両であるＫ車両４５０からの情報受信を繰り返す（図７参照）。これにより、Ｋ車両４５０に発生する異常を監視する。また、Ｌ車両４６０は、Ｋ車両４５０からの情報受信と並行して、送信先車両であるＩ車両４３０への情報送信を繰り返す（図６参照）。これにより、Ｌ車両４６０に発生する異常は、Ｉ車両４３０によって監視されることになる。つまり、各車両は、送信元車両に発生する異常を監視すると共に、送信先車両によって、自車両に発生する異常を監視してもらうのである。そして、Ｌ車両４６０は、Ｋ車両４５０からの情報受信が途絶えると（図８中のＳ４２：ＹＥＳ）、Ｋ車両４５０に異常があったものとして、異常時処理を実行する（Ｓ４４）。なお、異常時処理では、セキュリティ部５０の警報音発生部５２から警報音が発生させられる。
【００７８】
このように、駐車中の車両同士、つまり移動しない車両同士でグループを形成するため、常に安定した通信を行うことができ、正確に他車両の異常を検出することができる。また、グループ内のいずれの車両も送信元車両の異常を検出することができ、グループ内において各車両の異常を確実に検出可能となる。
【００７９】
また、本実施形態では、異常時処理を行うＬ車両４６０は、送信フラグ及び発報フラグを共にＯＮとし（図８中のＳ４３）、即座に、発報伝聞情報を送信先車両であるＩ車両４３０へ送信する（図６中のＳ２１：ＹＥＳ、Ｓ２２：ＹＥＳ、Ｓ２４）。その結果、Ｉ車両４３０は、Ｌ車両４６０と同様、異常時処理を実行し（図８中のＳ４４）、このとき、送信フラグ及び発報フラグを共にＯＮとし（Ｓ４３）、即座に、発報伝聞情報を送信先車両であるＪ車両４４０へ送信する（図６中のＳ２１：ＹＥＳ、Ｓ２２：ＹＥＳ、Ｓ２４）。Ｊ車両４４０も同様に異常時処理を実行する（図８中のＳ４４）。これにより、グループを形成する車両の異常を検知した車両以外の複数の車両が、異常時処理を実行することになり、防犯効果の一層の向上が図られる。
【００８０】
しかも、ここでは送信フラグがＯＮにされることで、発報伝聞情報が即座に送信先車両へ送信される。この意味で『前記送信手段は、前記異常時処理の実行後にあっては、前記発報伝聞情報を前記送信先車両へ即座に送信すること』としてもよい。この点でも、防犯効果の向上に寄与する。
【００８１】
さらにまた、本実施形態では、上述したように、各車両が、送信元車両に発生する異常を監視すると共に、送信先車両によって自車両に発生する異常を監視してもらうように構成されている。しかも、車両毎に送信先車両及び送信先車両を異なるものとしている（図３参照）。この意味で『複数台（Ｎ台）の車両のうち自車両が第ｎ台目の車両である場合、前記送信元車両は第（ｎ−１）台目の車両であり、前記送信先車両は第（ｎ＋１）台目の車両であること（ｎ＝２、３、４、・・・、Ｎ−１）』としてもよい。これにより、特定の車両のみの処理負荷が大きくなることを低減できる。
【００８２】
また、本実施形態では、図９及び図１０に示した追加要求処理及び追加処理により、また、図１４及び図１５に示した削除要求処理及び削除処理により、車両のグループを動的に構成できるため、当該システムの実効性を向上させることができる。
【００８３】
以上本発明は、上述した実施形態に何等限定されるものではなく、本発明の趣旨を逸脱しない範囲において、種々なる形態で実施できることは言うまでもない。
【００８４】
（イ）上記実施形態では、グループへの追加要求処理（図９参照）において、新規車両側で、最も近い末端車両を選択していた（Ｓ５５）。これに対し、新規車両が追加要求を送信する際（Ｓ５２）、自車両の位置を送信する構成とし、グループ側で通信を行い、最も近い末端車両のみが局設定要求を送信する構成としてもよい。
また、例えば、末端車両の位置を基に、地図データ記憶部３０に記憶された地図データを用い、新規車両と末端車両とが同一施設（例えば、同一駐車場）に存在するか否かを判断するようにしてもよい。このように、同一施設に駐車されている車両同士でグループを形成することにより、グループ内の車両に異常が検出された場合、同一施設に駐車されているグループ内の他の車両により異常時処理を行うことが可能となり、防犯効果の一層の向上が図られる。
【００８５】
（ロ）上記実施形態では、異常を検知した車両は発報伝聞情報を送信先車両へ送信するようにしており、発報伝聞情報を受信した車両がさらに、その車両の送信先車両へ送信するように構成していた。これに対し、追加要求の送信時に返信があった車両全てと定期的に通信を行うシステムとして、異常を検知した自車両が、定期的な通信を行う車両すべてに対し、発報伝聞情報を送信する構成としてもよい。この意味で『前記送信手段は、前記異常時処理の実行後にあっては、前記情報としての発報伝聞情報を全車両に対し送信すること』としてもよい。このようにすれば、全車両が即座に警報音を発生するという点で有利である。
【００８６】
（ハ）上記実施形態において、各車両が測る第一の所定時間を、車両が駐車された地域の特性に基づいて設定する構成としてもよい。例えば、繁華街など車両の盗難事件が多発する区画に車両が駐車されたことを地図データ記憶部３０の地図データに基づいて判断し、第一の所定時間を相対的に短くするようにしてもよい（例えば、２分）。この意味で『送信手段は、予め記憶されている地図情報に基づいて、前記第一の所定時間を動的に設定可能であること』としてもよい。このようにすれば、地域に応じた適切な防犯効果が得られることになる。
【００８７】
（ニ）上記実施形態ではセキュリティ部５０の警報音発生部５２を介して警報音を発生させているが、例えば車両周辺の写真撮影などを行う構成としても、防犯効果を向上させることができる。盗難現場における写真撮影であるため、窃取状況や窃取行為を行う人物を撮影できる可能性が高いためである。
【図面の簡単な説明】
【００８８】
【図１】実施形態のナビゲーション装置の概略構成を示すブロック図である。
【図２】グループの形成を示す説明図である。
【図３】形成されたグループにおける車車間通信を示す説明図である。
【図４】グループが形成されたことを前提に実行されるメイン処理を示すフローチャートである。
【図５】メイン処理における送信フラグ管理処理を示すフローチャートである。
【図６】メイン処理における送信処理を示すフローチャートである。
【図７】メイン処理における受信処理を示すフローチャートである。
【図８】メイン処理における異常処理を示すフローチャートである。
【図９】グループへの新規車両の追加に際し実行される追加要求処理を示すフローチャートである。
【図１０】グループへの新規車両の追加に際し追加要求処理に対応して実行される追加処理を示すフローチャートである。
【図１１】追加処理における局設定処理を示すフローチャートである。
【図１２】新規車両の追加を示す説明図である。
【図１３】追加要求処理と追加処理との対応を示す説明図である。
【図１４】グループからの離脱車両の削除に際し実行される削除要求処理を示すフローチャートである。
【図１５】グループからの離脱車両の削除に際し削除要求処理に対応して実行される削除処理を示すフローチャートである。
【図１６】離脱車両の削除を示す説明図である。
【図１７】削除要求処理と削除処理との対応を示す説明図である。
【符号の説明】
【００８９】
１…ナビゲーション装置、１０…ＥＣＵ（車両特定手段、送信手段、受信手段、異常時処理実行手段、発報処理実行手段）、２０…ＧＰＳ受信機、３０…地図データ記憶部、４０…通信部、５０…セキュリティ部、５１…操作ボタン、５２…警報音発生部、４００〜４７０…車両
【特許請求の範囲】
【請求項１】
自車両の防犯機能の開始要求を検出した場合に、駐車中の車両と通信を行うナビゲーション装置であって、
通信を行う駐車中の車両として、送信先車両、及び送信元車両を特定する車両特定手段と、
設定された第一の所定時間間隔で前記送信先車両へ自車両確認伝聞情報を送信する送信手段と、
前記送信元車両から送信元車両確認伝聞情報を受信する受信手段と、
前記受信手段にて前記送信元車両からの前記送信元車両確認伝聞情報を受信した後、前記第一の所定時間に基づく第二の所定時間が経過しても前記送信元車両確認伝聞情報が受信されない場合、異常時に対応する異常時処理を実行する異常時処理実行手段と、
を備えていることを特徴とするナビゲーション装置。
【請求項２】
請求項１に記載のナビゲーション装置において、
前記送信手段は、前記異常時処理の実行後にあっては、自車両発報伝聞情報を前記送信先車両へ送信するよう構成されており、
前記受信手段にて送信元車両発報伝聞情報が受信された場合、前記異常時処理を実行する発報処理実行手段を備えていること
を特徴とするナビゲーション装置。
【請求項３】
自車両の防犯機能の開始要求を検出した場合に、駐車中の車両と通信を行うためのプログラムであって、
通信を行う駐車中の車両として、送信先車両、及び送信元車両を特定する車両特定処理と、
設定された第１の所定時間間隔で前記送信先車両へ自車両確認伝聞情報を送信する送信処理と、
前記送信元車両から送信元車両確認伝聞情報を受信する受信処理と、
前記受信処理にて前記送信元車両からの前記送信元車両確認伝聞情報を受信した後、前記第一の所定時間に基づく第二の所定時間が経過しても前記送信元車両確認伝聞情報が受信されない場合に実行される異常時に対応する異常時処理とを含むことを特徴とするプログラム。
【請求項１】
自車両の防犯機能の開始要求を検出した場合に、駐車中の車両と通信を行うナビゲーション装置であって、
通信を行う駐車中の車両として、送信先車両、及び送信元車両を特定する車両特定手段と、
設定された第一の所定時間間隔で前記送信先車両へ自車両確認伝聞情報を送信する送信手段と、
前記送信元車両から送信元車両確認伝聞情報を受信する受信手段と、
前記受信手段にて前記送信元車両からの前記送信元車両確認伝聞情報を受信した後、前記第一の所定時間に基づく第二の所定時間が経過しても前記送信元車両確認伝聞情報が受信されない場合、異常時に対応する異常時処理を実行する異常時処理実行手段と、
を備えていることを特徴とするナビゲーション装置。
【請求項２】
請求項１に記載のナビゲーション装置において、
前記送信手段は、前記異常時処理の実行後にあっては、自車両発報伝聞情報を前記送信先車両へ送信するよう構成されており、
前記受信手段にて送信元車両発報伝聞情報が受信された場合、前記異常時処理を実行する発報処理実行手段を備えていること
を特徴とするナビゲーション装置。
【請求項３】
自車両の防犯機能の開始要求を検出した場合に、駐車中の車両と通信を行うためのプログラムであって、
通信を行う駐車中の車両として、送信先車両、及び送信元車両を特定する車両特定処理と、
設定された第１の所定時間間隔で前記送信先車両へ自車両確認伝聞情報を送信する送信処理と、
前記送信元車両から送信元車両確認伝聞情報を受信する受信処理と、
前記受信処理にて前記送信元車両からの前記送信元車両確認伝聞情報を受信した後、前記第一の所定時間に基づく第二の所定時間が経過しても前記送信元車両確認伝聞情報が受信されない場合に実行される異常時に対応する異常時処理とを含むことを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【公開番号】特開２０１０−１１７９２６（Ｐ２０１０−１１７９２６Ａ）
【公開日】平成２２年５月２７日（２０１０．５．２７）
【国際特許分類】
【出願番号】特願２００８−２９１１９９（Ｐ２００８−２９１１９９）
【出願日】平成２０年１１月１３日（２００８．１１．１３）
【出願人】（０００１００７６８）アイシン・エィ・ダブリュ株式会社 (3,717)
【Ｆターム（参考）】
【公開日】平成２２年５月２７日（２０１０．５．２７）
【国際特許分類】
【出願日】平成２０年１１月１３日（２００８．１１．１３）
【出願人】（０００１００７６８）アイシン・エィ・ダブリュ株式会社 (3,717)
【Ｆターム（参考）】
[ Back to top ]