(57)【要約】【課題】車両の故障の修理に必要な時間及びユーザのスケジュール情報に応じて考慮された出発時刻を通知することを可能とし、利便性が高い通知システムを提供する。【解決手段】通知システムは、ユーザのスケジュール情報を備えるスケジューラと、車両の故障状態を判定する故障診断部と、少なくとも車両の故障状態及びユーザのスケジュール情報を考慮した出発時刻を算出する出発時刻算出部と、前記故障診断部と、前記出発時刻算出部と、スケジューラとを制御する制御部を備え、ユーザに対して前記出発時刻を通知する。【選択図】図１
2019168927.tif 000002
【特許請求の範囲】
【請求項１】
ユーザのスケジュール情報を備えるスケジューラと、
車両の故障状態を判定する故障診断部と、
少なくとも車両の故障状態及びユーザのスケジュール情報を考慮した出発時刻を算出する出発時刻算出部と、
前記故障診断部と、前記出発時刻算出部と、前記スケジューラとを制御する制御部と、を備え、
ユーザに対して前記出発時刻を通知する通知システム。
【請求項２】
前記故障診断部は、車両の故障状態に応じて車両が修理を必要とするか否かを判定し、修理が必要な場合には、出発時刻算出部は、少なくとも修理に必要な時間及びユーザのスケジュール情報を考慮した出発時刻を算出する請求項１に記載の通知システム。
【請求項３】
前記故障診断部は、車両の故障状態に応じて車両が修理を必要とするか否かを判定し、修理が必要な場合であって、修理をすることが不可能な場合には、前記制御部は車両による移動の代替移動手段を提示する請求項１に記載の通知システム。
【請求項４】
前記代替移動手段には、ユーザが使用可能な他の車両、電車、タクシー、バス、飛行機、船、徒歩、その他の移動手段を含む請求項１から３の何れか一項に記載の通知システム。
【請求項５】
前記故障診断部、前記スケジューラ、前記出発時刻算出部、及び前記制御部は、車両及び情報端末と通信網を介して接続可能に構成されたセンタに備えられている請求項１から４の何れか一項に記載の通知システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通知システムに関する。
【背景技術】
【０００２】
自動車で目的地に向かう場合に、移動時間や交通渋滞を考慮して出発時刻を通知するシステムがある。しかし、様々な事情により予定通りに目的地に到達できない場合がある。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０００−３０４５５６号公報
【特許文献２】特開２０１０−９６５３６号公報
【特許文献３】特開２０１２−２４２３０１号公報
【特許文献４】特開２００６−２１４８７４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
例えば、自分の車両に故障があり、予定時刻に出発したのでは途中で止まってしまうため予定時刻に目的地に到着することが困難もしくは不可能な場合がある。このような場合に、渋滞情報を考慮して出発時刻を変更して通知したとしても、車両の修理を行うことが考慮されていないため、目的地に予定時刻に到着することができない。また、すぐに車両の修理を行うことができない場合もある。
【０００５】
本発明は、上記課題に鑑みてなされたものであり、移動時間や交通渋滞だけでなく、車両の故障状態及びユーザのスケジュール情報を考慮した出発時刻を通知したり、代替移動手段を通知したりすることを可能とし、これによって利便性が高い通知システムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
請求項１に記載した発明によれば、通知システムは、ユーザのスケジュール情報を備えるスケジューラと、車両の故障状態を判定する故障診断部と、少なくとも車両の故障状態及びユーザのスケジュール情報を考慮した出発時刻を算出する出発時刻算出部と、前記故障診断部と、前記出発時刻算出部と、スケジューラとを制御する制御部を備え、ユーザに対して前記出発時刻を通知する。
【０００７】
この構成によれば、車両の故障の修理に必要な時間及びユーザのスケジュール情報に応じて考慮された出発時刻を通知したり、代替移動手段を通知したりすることが可能となるため、利便性が高い通知システムを提供することができる。
【図面の簡単な説明】
【０００８】
【図１】実施形態に係る通知システムの概略構成を示すブロック図
【図２】シーケンス図
【図３】フロー図
【発明を実施するための形態】
【０００９】
以下、実施形態について図面を参照して説明する。
図１に示すように、実施形態に係る通知システム１は、センタ１０、車両２０、情報端末３０を備えている。センタ１０、車両２０、及び情報端末３０は、通信網４０を介して相互に接続され、通知システム１を構成している。
【００１０】
なお、以下の説明において、「修理」は、破損等が生じた場合の車両の修繕修理だけでなく、部品の交換、タイヤ内への空気補充、ガソリン等の燃料の補給、バッテリ上がり時のジャンプスタートやバッテリの交換、パンク時のタイヤ交換等のメンテナンス処置も含む概念である。また、以下の説明において、「故障」は、車両において目的地までの移動を不可能とする車両状態を意味し、車両の破損、損傷等だけでなく、タイヤ空気圧の不足、ガソリン等の燃料の不足、バッテリ上がりなども含む概念である。
【００１１】
センタ１０は、故障診断部１１、出発時刻算出部１２、スケジューラ１３、ユーザ情報処理部１４、経路検索部１５、送受信部１６、及び制御部１７を備えている。センタ１０は、車両２０、及び情報端末３０から取得した情報や、通信網４０を介して取得した渋滞情報、地図情報、気象情報等の種々の情報を集約し、所定の処理を実行するデータセンタである。センタ１０は、スケジュール情報記憶部１３ａ、使用端末情報記憶部１４ａ、車両特定情報記憶部１４ｂ、地図情報記憶部１５ａ、交通情報記憶部１５ｂ等、様々な情報のデータベースを記憶したり、各種処理を実行したりするためのサーバ等を備えている。センタ１０にすべての機能が集約される必要はなく、例えば機能別に分散するように構成されていてもよい。
【００１２】
センタ１０は通知システム１全体を統括して制御する制御部でもある。センタ１０は、ＣＰＵ、ＲＯＭ、ＲＡＭ、ストレージ機器、バス、Ｉ／Ｏなどを備えるコンピュータ組織を主体に構成されており、故障診断部１１、出発時刻算出部１２、スケジューラ１３、ユーザ情報処理部１４、経路検索部１５、送受信部１６、及び制御部１７等の各機能は、例えばＲＯＭ又はストレージ機器に格納されたプログラムをＣＰＵにおいて実行させることにより実現される。
【００１３】
故障診断部１１は車両の状態すなわち車両の故障状態を把握し、修理が必要か否かを判定する。故障診断部１１はあらかじめ車両情報記憶部１１ａに記憶されている車両情報と、故障リファレンスデータ記憶部１１ｂ内に格納されている車両の故障状態情報とを比較照合することにより当該車両の故障状態を判定する。車両情報には、後述するセンサ２４等により測定されたセンサデータが含まれている。故障リファレンスデータは、車両が故障状態であるか否かを判定するためのデータ情報が含まれている。例えば、タイヤがパンクしているか否かを判定するためのタイヤの空気圧下限値等のデータ情報が含まれている。
【００１４】
修理時間ＤＢ１１ｃには車両−車両の故障状態−修理時間が対応づけられて格納されており、故障診断部１１は修理時間ＤＢ１１ｃに故障状態に対応した修理時間ＤＢを照会することにより故障を修理するのに必要な時間を算出する。例えば、修理時間ＤＢ１１ｃでは、パンク修理の場合は修理時間３０分、ガソリンの給油の場合には１５分、というように故障に対する修理作業時間が対応して記憶されており、これに、例えば、経路検索部１５で算出した修理施設への移動時間を加えることにより修理を行うのに必要な時間が算出される。
【００１５】
出発時刻算出部１２は、故障診断部１１、スケジューラ１３、ユーザ情報処理部１４、及び経路検索部１５からの情報を取得して、出発時刻を算出する機能を有する。
【００１６】
スケジューラ１３はスケジュール情報を備えるスケジュール情報記憶部１３ａからスケジュール情報を取得し、スケジュール管理を行う機能を有する。スケジュール情報には、ユーザの予定情報、すなわち、日時及び場所（目的地）の情報が含まれている。
【００１７】
ユーザ情報処理部１４は、使用端末情報記憶部１４ａからユーザの使用する情報端末３０の情報を取得する。また、ユーザ情報処理部１４は、車両特定情報記憶部１４ｂからユーザが使用可能な車両の特定情報を取得する。
【００１８】
ここで、ユーザが使用可能な車両には、当該車両が使用可能か否かを判定するため、実施形態に係る通知システム１が導入されているものとする。ユーザが使用可能な車両としては、例えば個人又は家族で複数台の車両を所有している場合などが想定される。実施形態では車両Ａ、Ｂの２台を所有しており、車両Ａを優先して使用する場合を例示して説明する。
【００１９】
経路検索部１５は地図情報記憶部１５ａに記憶されている地図情報、交通情報記憶部１５ｂに格納されている交通情報、及び位置情報に基づいて経路検索を行い、走行ルートを決定する機能を有する。交通情報記憶部１５ｂは交通情報として、例えば渋滞情報、通行止め情報、あるいは気象情報等を備えており、これは通信網４０やＦＭ放送等を通じて取得される。目的地、及び到着時刻はスケジューラ１３から取得される。また、経路検索部１５は図示しない位置検出部を備えており、例えば、ＧＰＳ等の衛星からの電波を使って車両２０の位置を特定する機能を備えている。位置検出は、ＷｉＦｉ（登録商標）や自律センサで行うようにしてもよい。
【００２０】
センタ１０、車両２０、及び情報端末３０は、それぞれに送受信部１６、２５、３０ａ、及び、通信網４０を介して接続することにより相互に情報の送受信を行う。通信網４０は例えばインターネット通信網であり、送受信部１６、２５、３０ａと有線接続又は無線接続可能に構成されている。制御部１７は、センタ１０の各機能を統合して制御する制御部であり、ＣＰＵ、ＲＯＭ、ＲＡＭ、Ｉ／Ｏ等を備えたコンピュータを主体として構成される電子制御装置である。
【００２１】
センタ１０には通知システム１の主要な機能が備えられており、通知システム１を実行するに際して、車両２０及び情報端末３０のリソースを使用しないように構築されている。従って、車両２０のイグニッションオフ（以下、ＩＧ−ＯＦＦと称する）時に車両２０の電力を使用することがないので、車両２０に負担をかけることがなく、車両２０のバッテリ上がり等を回避できる。
【００２２】
車両２０は情報処理部２２、ＥＣＵ２３、センサ２４、送受信部２５及びナビゲーション部２１を備え、これらは車内ＬＡＮである通信ネットワーク２６によって接続されている。ナビゲーション２１は図示しないナビゲーションＥＣＵを備え、車両２０の走行経路を検索して案内する機能を備えている。情報処理部２２は複数のＥＣＵ２３、及び複数のセンサ２４を備えている。センサ２４はＥＣＵ２３に接続されており、ＥＣＵ２３は情報処理部２２に接続されている。センサ２４で測定されたセンサデータはＥＣＵ２３で所定の処理がされ、情報処理部２２に送信される。
【００２３】
ＥＣＵ（Electronic Control Unit）２３は、ＣＰＵ、ＲＯＭ、ＲＡＭ、Ｉ／Ｏ等を備えるコンピュータを主体として構成される電子制御装置である。ＥＣＵ２３としては、例えばエンジンＥＣＵ、アクセルＥＣＵ、ブレーキＥＣＵ、ステアリングＥＣＵなどが含まれる。図２では、一つのＥＣＵ２３に一つのセンサ２４が接続されている構成を例示しているが、これは例示であって、この構成に限定する意図はない。
【００２４】
センサ２４としては、例えば、タイヤ空気圧センサ、ガソリン量計、エンジンオイル量計、ブレーキオイル量計、パワーステアリングオイル量計、バッテリ電圧計等の各種センサなどが含まれる。ここで、タイヤの空気圧センサは、例えば、ＴＰＭＳ（Tire Pressure Monitoring System；タイヤ空気圧監視システム）によりモニターされている。ＴＰＭＳでは、タイヤ空気圧センサは近距離無線接続によりＥＣＵ２３に無線接続され、各センサ２４により検出された空気圧データを取得する。
【００２５】
各空気圧センサは、それぞれの空気圧センサを識別可能なＩＤが付与されているため、各空気圧センサが装着されたそれぞれのタイヤ及び装着場所を識別し、それぞれのタイヤの空気圧を個別にモニター可能である。また、夏用タイヤと、冬用タイヤのそれぞれに空気圧センサを設けることにより、例えば、夏用タイヤを装着しているか、又は冬用タイヤを装着しているかの判定も可能となる。
【００２６】
ＥＣＵ２３は各センサ２４から種々のセンサデータを受信し、情報処理部２２に送信する。センサデータを取得した情報処理部２２は、センサデータに所定の処理を実施し、車両情報を生成する。その後、生成された車両情報は、送受信部２５及び通信網４０を介して送受信部１６に送信され、車両情報記憶部１１ａに記憶される。車両情報には、タイヤ空気圧、ガソリン量、エンジンオイル量、ブレーキオイル量、パワーステアリングオイル量、バッテリ電圧などの、センサデータが含まれる。
【００２７】
なお、車両２０に故障診断部を設け、センサデータに基づいて車両２０の故障診断を車両２０において実施するようにしてもよい。この場合、故障診断結果は、車両２０からセンタ１０に送信され、車両２０は受信した故障診断結果に応じて通知内容を決定することになるが、車両２０のバッテリ電源を用いて処理を行うため、ＩＧ−ＯＦＦ時にはバッテリ上がりを招くおそれがある。このため、実施形態では、故障診断部１１はセンタ１０に設けることとしている。
【００２８】
情報端末３０は、送受信部３０ａ、位置検出部３０ｂ、及び入出力部３０ｃを備えている。送受信部３０ａは通信網４０を介してセンタ１０、車両２０と無線接続するための通信機であり、位置検出部３０ｂは、情報端末３０のＧＰＳ等の衛星からの電波を使って情報端末３０の位置を特定する機能を有する。特定された情報端末３０の位置情報は、情報端末３０の送受信部３０ａと、センタ１０の受信部１６を介して経路検索部１５に送信される。これにより、経路検索部１５は情報端末３０の位置を特定することができる。
【００２９】
入出力部３０ｃは例えば液晶ディスプレイや有機ＥＬディスプレイ等の表示装置と、タッチした指位置を検知するタッチ位置検出装置を備え、この表示装置とタッチ入力部とが重ねて配置されて構成されたタッチパネルである。これにより、入出力部３０ｃにソフト的に表示させたキーボードやボタン等に対する手指による押下位置を検知することができる。これにより、例えばユーザはスケジュール情報を入力することができる。
【００３０】
図２に示すように、通知システム１において、以下のように処理が実行される。ここでは、ユーザが使用可能な車両として、車両Ａ及び車両Ｂの２台が存在する場合について例示して説明する。さらに３台目、４台目の車両が存在する場合は、車両Ｃ、車両Ｄとして、車両Ｂの取り扱いに準じて処理すればよい。また、図２中の矢印は情報の移動方向を示している。
【００３１】
また、ここでは、車両Ａを優先して使用するものとして説明する。車両Ａ、Ｂの使用優先順位はユーザがあらかじめセンタ１０の車両特定情報記憶部１４ｂに登録しておいてもよいし、センタ１０が車両Ａ、Ｂの使用状況を分析して使用頻度が高い車両を選択するように設定しておいてもよい。また、目的地等に応じて車両を決定してもよい。例えば長距離の場合はミニバン、短距離の場合はコンパクトカー、山岳地帯に行く場合は４輪駆動車、降雪情報がある場合は冬用タイヤを装着した車両を選択する、というようにしてもよい。
【００３２】
まず、事前準備として、ユーザは、情報端末３０を用いてスケジュールを登録し（Ｓ１）、情報端末３０にスケジュール情報が格納される（Ｓ２）。センタ１０は適宜、情報端末３０と通信し、情報端末３０に格納されたスケジュール情報を取得し、取得したスケジュール情報は、センタ１０のスケジュール情報記憶部１３ａに格納される（Ｓ３）。また、スケジュール情報を、例えば、図示しない他のサーバに記憶させてもよく、その場合は、センタ１０は、当該他のサーバからスケジュール情報を取得するようにしてもよい。
【００３３】
また、センタ１０は、車両２０ここでは車両Ａ及び車両Ｂの車両情報を取得し（Ｓ４）、車両情報記憶部１１ａに記憶する。車両情報の取得はいつ行ってもよいが、例えば前回運転中、又は、前回運転終了時の車両システムシャットダウン時に車両情報の取得処理を実行するように設定することができる。車両２０からの車両情報取得は、車両２０のバッテリ上がり防止を考慮すれば、車両２０の走行時、あるいは、ハイブリッド車であれば充電時又は走行時に行うようにすればよい。
【００３４】
また、センタ１０は、通信網４０を介して交通情報を取得し（Ｓ５）、交通情報記憶部１５ｂに記憶する。この交通情報は所定時間ごとに更新されており、最新の交通情報が交通情報記憶部１５ｂに記憶されている。交通情報記憶部１５ｂで取得される情報には、天気予報、警報、注意報などの気象情報が含まれていてもよい。交通情報には例えば独自の交通渋滞予測などのデータが含まれていても良い。
【００３５】
次に、センタ１０において、通知内容決定処理が実行される（Ｓ６）。通知内容決定処理については、図３を用いて後述する。通知内容決定処理により、通知内容が決定される。通知内容には、出発時刻、使用すべき車両２０（車両Ａ又は車両Ｂ）、例えば修理施設を経由する目的地までの経路、代替移動手段及びその経路等を含む。
【００３６】
センタ１０は、情報端末３０に上記通知内容を含む通知情報を送信し（Ｓ７）、情報端末３０は送信された通知内容を表示する（Ｓ８）。ユーザは情報端末３０に表示された通知内容を閲覧する（Ｓ９）。これにより、ユーザは、出発すべき時刻、使用すべき車両２０、目的地までの経路情報、あるいは代替移動手段及びその経路を認識することができる。なお、センタ１０が情報端末３０に通知情報を送信するタイミングとしては、ユーザが出発するまでに必要な準備時間等を考慮し、前倒して通知するようにしても良い。
【００３７】
また、センタ１０は、修理が必要であると判定した場合であっても、車両２０を用いて移動可能と判定した場合は、使用すべき車両Ａ又は車両Ｂの情報、及び、例えば修理施設経由の経路情報を送信する（Ｓ１０）。車両２０には修理施設経由の経路が送信されているため、この経路情報を備えたナビゲーション２１によるルート案内に従い、修理施設経由で目的地に向かえばよい。
【００３８】
次に、図３を参照して、通知内容決定処理の内容について説明する。図３に示すように、通知内容決定処理が開始されると、センタ１０の故障診断部１１は車両Ａについて修理が必要かどうかを判定する（Ｓ２１）。修理の要否は、車両情報記憶部１１ａに記憶されている車両情報と故障リファレンスデータ記憶部１１ｂに記憶されている故障リファレンスデータとを照合することにより判定される。
【００３９】
ここでは、「故障」は修理が必要であると判定される場合であり、車両の走行継続に対して支障を生じる車両状態を意味する。この場合、走行不能か、走行を開始してもすぐに走行不能に陥る可能性が高い場合が「故障」に該当すると判定され、従って修理が必要であると判定される（Ｓ２１：ＹＥＳ）。例えば、バッテリ上がりである場合、ガソリンタンクに貯留されるガソリン量が目的地に到達するには不足である場合、タイヤの空気圧が著しく低下しており車両の安全走行に支障がある場合、エンジンオイル量が著しく低下しており、走行を開始すればエンジンの破壊を来すことが予想される場合、等である。エンジンオイル量が許容範囲内で低下している程度であれば、ここでの故障に該当しない。
【００４０】
故障診断部１１が、修理が不要であると判断した場合は（Ｓ２１：ＮＯ）、経路検索部１５が経路を検索し、経路情報を出発時刻算出部１２に送信する（Ｓ２２）。出発時刻算出部１２は、経路検索部１５から経路検索結果を、スケジューラ１３から到着時刻を、ユーザ情報処理部１４から使用車両２０（ここでは車両Ａ）の情報を取得する。これらの情報に基づき、出発時刻算出部１２はユーザが出発すべき出発時刻を算出する（Ｓ２３）。
【００４１】
制御部１７は、修理要否結果、出発時刻などを含む通知内容を決定し、これら通知内容を含む通知情報を生成する（Ｓ２４）。その後、通知システム１は、通知情報をユーザに通知する（図２のＳ７）。また、経路情報を車両２０のナビゲーション部２１に送信する（図２のＳ１０）。
【００４２】
故障診断部１１が、修理が必要であると判定した場合は（Ｓ２１：ＹＥＳ）、故障診断部１１は、修理の内容、修理に必要な時間、及び修理施設情報を確認する（Ｓ２５）。これら情報は故障リファレンスデータ記憶部１１ｂに記憶しておいてもよいし、通信網４０を介してインターネット情報を検索することにより最新の情報を取得するようにしてもよい。修理施設情報とは、例えば現在地から半径５ｋｍ以内に位置する修理施設の営業日、営業時間、修理可能事項、等である。修理施設には、自動車ディーラ、自動車修理工場、ガソリンスタンド等が含まれる。当該車両に特有な専門的な修理項目であれば自動車ディーラ等の修理施設で修理を行う必要があるが、例えばパンク修理、タイヤ交換（サイズ等が合致するタイヤを保有している場合）であればガソリンスタンドでも修理可能である。このように、修理内容に応じて修理施設を選択するようにする。
【００４３】
故障診断部１１は、図２のＳ３からＳ５に示すように、目的地情報や到着予定時刻などを含むスケジュール情報、交通情報等は既に取得して保持している。故障診断部１１は、スケジュール情報、交通情報、及び、修理の内容、修理に必要な時間、修理施設情報等を考慮して、修理が可能であるか否かを判定する（Ｓ２６）。ここで「修理不可能」とは、スケジュール情報による到着時刻に目的地に到達不可能とする故障状態を意味し、修理することが可能ではあっても、修理をしていたのではスケジュール情報による到着時刻に目的地に到達できない場合は「修理不可能」に該当する。なお、例えばタイヤのパンクやバッテリ上がり等、ロードサービスを利用して修理可能な場合（例えば、テンパータイヤへの交換、ジャンピングスタート）は、修理が可能であるとの判定を行い（Ｓ２６：ＹＥＳ）、当該車両は自走できないがロードサービスを利用して修理が可能なこと、及び、使用可能なロードサービスの連絡先等を含むようにして通知内容を決定し（２４）、これを含む通知情報の送信を行う（Ｓ７）。また、ロードサービスでは修理できないが修理施設で修理可能な場合は、修理可能であるとの判定を行い（Ｓ２６：ＹＥＳ）、当該車両は自走できないのでロードサービスを利用して修理施設に移動すべきこと、及び、使用可能なロードサービスの連絡先等を含むようにして通知内容を決定し（２４）、これを含む通知情報の送信を行う（Ｓ７）。この場合、ロードサービスの手配、修理作業等に必要な時間を考慮して、送信時刻を前倒しして通知情報を送信する（Ｓ７）。
【００４４】
例えば、想定される出発時刻が修理施設の営業時間外であり、開店時刻を待っていたのでは到着時刻に間に合わない場合は、修理不可能と判定される。また、修理施設の営業時間内であっても、修理時間が長時間必要であり、目的地到着予定時刻に間に合わない場合も同様にも修理不可能と判定される。故障診断部１１が、修理可能であると判定した場合は（Ｓ２６：ＹＥＳ）、制御部１７は修理施設での修理を経由した経路を検索する（Ｓ２７）。
【００４５】
検索した経路情報は出発時刻算出部１２に送信され、Ｓ２３及びＳ２４の処理が実行される。ここで、Ｓ２４で生成される通知内容情報において、例えば、修理に１時間を要する場合は、出発時刻を１時間前倒しして設定された変更後の新たな出発時刻を含んでいる。また、修理の内容、修理施設の情報、修理施設経由の経路情報が含まれていてもよい。
【００４６】
次に、Ｓ２６において、修理不可能と判定された場合（Ｓ２６：ＮＯ）、ユーザが使用可能な他車両があるか否かを判定する（Ｓ２８）。ユーザが使用可能な他の車両が存在する場合（Ｓ２８：ＹＥＳ）、当該使用可能な当該車両、ここでは車両Ｂについて、通知内容決定処理を実施する（Ｓ２９）。車両Ｂが使用可能な場合、すなわち車両Ｂが修理不要である場合は車両Ｂの保管場所からの経路を検索し（Ｓ３０）、修理が必要で修理可能である場合は修理経由の経路を検索し（Ｓ３０）、続いてＳ２３、及びＳ２４の処理を実行する。車両Ｂが例えば普段からユーザの家族により使用されている車両である場合には、普段の使用状況を分析して特定した使用傾向や、車両Ｂを普段使用している家族のスケジュール情報を把握しておき、これにより当日の使用可否を判定するようにしてもよい。Ｓ２４では、車両Ａについて修理が必要であるが修理が不可能であること、使用可能な他車両ここでは車両Ｂがあること、及び、検索した経路情報、出発時刻などを含む通知内容を決定し、これら通知内容を含む通知情報を生成する。
【００４７】
車両Ｂについて修理不可能な場合は使用可能な他車両なしと判断し（Ｓ２８：ＮＯ）、代替移動手段を検索し（Ｓ３１）、その代替移動手段での経路を検索する（Ｓ３２）。その後、Ｓ２３及びＳ２４の処理を実施する。ここで、Ｓ２４で生成される通知情報には、変更された出発時刻、車両Ｂについての修理の要否、修理情報、新たな経路、代替移動手段及びその経路などの情報が含まれる。
【００４８】
ユーザが使用可能な他車両がない場合、例えば、ユーザが車両Ａしか所有していない場合、及び、前述の車両Ｂについて修理不可能な場合は、ユーザが使用可能な他車両がないものと判定され（Ｓ２８：ＮＯ）、制御部１７は代替移動手段を検索し（Ｓ３１）、この代替移動手段で経路検索を実施する（Ｓ３２）。代替移動手段には、電車、タクシー、バス、飛行機、船、徒歩、その他の移動手段、又はこれらの組み合わせが含まれる。その後、Ｓ２３及びＳ２４の処理を実施する。ここで、Ｓ２４で生成される通知情報には、変更された出発時刻、代替移動手段及びその経路の情報などが含まれる。なお、この場合の通知内容表示の閲覧画面（Ｓ８）で、通知内容による移動手段を不採用とし、さらなる代替移動手段を再検索することを指示するボタン等を表示させるようにしても良い。
【００４９】
通知システム１は、上記処理を、例えばスケジューラ１３のスケジュール情報に記載された出発時刻の、例えば２時間前に実行し通知する、というように制御してもよいし、判定に必要な情報が取得された都度実行し通知する、というように制御してもよい。また、ユーザが通知内容による移動手段とは別の移動手段を選択しても余裕を持って移動可能な時間まで前倒して送信することとしても良い。なお、上述のユーザへの通知は、少なくとも変更された出発時刻よりも前の時刻に実施される。例えば変更された出発時刻の１時間前、当該予定日の前日、もしくは、数日前に通知を実施するように制御してもよい。上記に説明した種々の処理は主としてセンタ１０で実施される。
【００５０】
上記に説明した通知システム１によれば、以下の効果を得る。
実施形態に係る通知システム１によれば、ユーザが使用する車両において、スケジュールに登録された予定時刻に目的地に到達できない故障が発生している場合は、通知システム１は、当該故障を修理するための時間を考慮した出発時刻、修理経由での経路をユーザに通知する。これにより、車両に予定時刻に目的地まで到達不可能となる故障が発生した場合に、ユーザは、修理が必要な故障が発生したこと、及び、修理する時間が考慮され、前倒しに変更された出発時刻を通知される。このため、ユーザは予定時刻に遅れることなく目的地に到着することができる。以上の構成により、通知システム１は、車両２０の故障状態、修理に必要な時間、及びユーザのスケジュール情報を考慮した出発時刻を算出し、ユーザに通知する。これにより、ユーザの利便性を向上させた通知システム１を提供することができる。
【００５１】
また、ユーザが使用する車両において修理不可能である場合は、通知システム１はユーザに、修理不可能な故障が発生したこと、代替移動手段、及び、この代替移動手段による場合の出発時刻を通知する。代替移動手段には、ユーザが使用可能な他の車両、電車、タクシー、バス、飛行機、船、徒歩、その他の移動手段が含まれる。これによれば、通知システム１は車両の故障状態及びユーザのスケジュール情報を考慮した代替移動手段を提示することができ、この代替移動手段を用いた場合の出発時刻をユーザに通知することができるため、ユーザは予定時刻に遅れることなく目的地に到着することができる。これにより、ユーザの利便性を向上させた通知システム１を提供することができる。
【００５２】
また、故障診断部１１、スケジューラ１３、出発時刻算出部１２、及び制御部１７は、車両及び情報端末と通信網を介して接続可能に構成されたセンタに備えられている。これらの制御及び処理はセンタ１０を主体として実行されるため、車両２０がＩＧ−ＯＦＦ時においても車両２０に負担をかけることがなく、車両２０のバッテリ上がりのおそれがない。
【００５３】
本開示は、実施例に準拠して記述されたが、本開示は当該実施例や構造に限定されるものではないと理解される。本開示は、様々な変形例や均等範囲内の変形をも包含する。加えて、様々な組み合わせや形態、さらには、それらに一要素のみ、それ以上、あるいはそれ以下、を含む他の組み合わせや形態をも、本開示の範疇や思想範囲に入るものである。
【００５４】
実施形態に係る通知システム１について、車両２０に適用した例を例示して説明したが、車両２０はいわゆる自家用車に限定されるものではない。例えば、トラック、タクシーなどの業務用車両に適用してもよいし、消防車、救急車、軍用車などの特殊装備車に適用してもよい。また、４輪自動車だけでなく２輪自動車に適用してもよい。また考慮すべき車両の故障状態についても、車両の「故障」だけでなく、例えば必要な装備品の不備等を考慮した通知システム１を構築することができる。
【符号の説明】
【００５５】
１…通知システム、１０…センタ（制御部）、１１…故障診断部、１２…出発時刻算出部、１３…スケジューラ、１４…ユーザ情報処理部、１５…経路検索部、１７…制御部、２０…車両、２１…故障診断部、２３…ＥＣＵ、２４…センサ、３０…送受信部、４０…通信網
【図１】
2019168927.tif 000003
【図２】
2019168927.tif 000004
【図３】
2019168927.tif 000005