JP2021079854A - 車両診断装置、車両診断システム及び移動体診断装置 - Google Patents

Abstract

【課題】車両等のハッキングによる被害を抑制することができる車両診断装置等を提供する。【解決手段】車両診断装置１０は、自動運転する車両５０と通信する通信部１１と、通信部１１を介して車両５０がハッキングされているか否かを診断する診断部１６とを備える。診断部１６は、車両５０に対して行った質問に対する回答に基づいて、上記診断を行う。【選択図】図２

Description

本開示は、車両を診断する車両診断装置、車両診断システム、及び、移動体を診断する移動体診断装置に関する。

従来、車両を制御する車両制御装置が知られている。特許文献１には、車両の挙動に異常があると、車両の走行を、予め決められた固定制御パラメータによる走行に切り替える技術が開示されている。この技術によれば、ユーザが車両の制御パラメータを誤って設定したり、車両の安全関連部の制御パラメータに不備があった場合であっても、予め決められた固定制御パラメータに基づいて車両を安全に走行させることができる。

特許第５８５３２０５号公報

一方で、例えば車両が第三者にハッキング（不正外部操作）されると、ハッキングされた車両や他の車両に被害が生じるという問題がある。その問題に対し、例えば移動体である車両等がハッキングされているか否かを診断することができれば、車両等のハッキングによる被害を抑制できると考えられる。

そこで、本開示は、車両等がハッキングされているか否かを診断することができる車両診断装置等を提供することを目的とする。

上記目的を達成するために、本開示に係る車両診断装置の一態様は、自動運転する車両と通信する通信部と、前記通信部を介して前記車両がハッキングされているか否かを診断する診断部とを備え、前記診断部は、前記車両に対して行った質問に対する回答に基づいて、前記診断を行う。

また、上記課題を解決するために、本開示に係る車両診断システムの一態様は、上記車両診断装置と、前記車両診断装置と通信する情報端末とを備える。

また、上記課題を解決するために、本開示に係る車両診断システムの一態様は、自動運転する車両と通信する通信部、ならびに、前記車両、前記車両が走行する道路及び前記車両が駐車する駐車場の少なくとも一つに照明光を照射可能な照射部を有する照明装置と、前記通信部に通信接続され、前記通信部を介して前記車両がハッキングされているか否かを診断する診断部を有する車両診断装置とを備え、前記診断部は、前記車両に対して行った質問に対する回答に基づいて、前記診断を行う。

また、上記課題を解決するために、本開示に係る車両診断システムの一態様は、自動運転する車両、前記車両が走行する道路及び前記車両が駐車する駐車場の少なくとも一つに照明光を照射可能な照明装置と、前記照明装置及び前記車両と通信する通信部、ならびに、前記通信部を介して前記車両がハッキングされているか否かを診断する診断部を有する車両診断装置とを備え、前記診断部は、前記車両に対して行った質問に対する回答に基づいて、前記診断を行う。

また、上記課題を解決するために、本開示に係る移動体診断装置の一態様は、自動運転する移動体と通信する通信部と、前記通信部を介して前記移動体がハッキングされているか否かを診断する診断部とを備え、前記診断部は、前記移動体に対して行った質問に対する回答に基づいて、前記診断を行う。

本開示に係る車両診断装置等によれば、車両等がハッキングされているか否かを診断することができる。これにより、車両等のハッキングによる被害を抑制することができる。

実施の形態１に係る車両診断装置の設置例を示す図である。 実施の形態１に係る車両診断装置の構成を示すブロック図である。 実施の形態１に係る車両診断装置の診断部から車両に対して行う質問の一例を示す図である。 車両に乗車中のオーナーに表れる状態の一例を示す図である。 車両に乗車中のオーナーに表れる状態の他の一例を示す図である。 車両に乗車中のオーナーに表れる状態の他の一例を示す図である。 実施の形態１に係る車両診断装置から車両に対して行うソフトウェアの強靭性確認手段を示す図である。 実施の形態１に係る車両診断装置の診断部で取得する車両の運行ログの一例を示す図である。 実施の形態１に係る車両診断装置の照射部によって報知される報知情報の一例を示す図である。 実施の形態１に係る車両診断装置の動作を示すフローチャートである。 実施の形態１に係る車両診断装置の診断部の動作の一例を示すフローチャートである。 実施の形態１に係る車両診断装置の診断部の動作の他の例を示すフローチャートである。 実施の形態１に係る車両診断装置の診断部の動作の他の例を示すフローチャートである。 実施の形態１に係る車両診断装置の診断部の動作の他の例を示すフローチャートである。 実施の形態２に係る車両診断装置の使用例を示す図である。 実施の形態２に係る車両診断装置の構成を示すブロック図である。 実施の形態２に係る車両診断装置の照射部の点灯状態を示す図である。 実施の形態２に係る車両診断装置の動作を示すフローチャートである。 実施の形態３に係る車両診断システムを示す概略図である。 実施の形態３に係る車両診断システムを構成する車両診断装置及び複数の照明機器の通信接続関係を示す図である。 実施の形態３に係る車両診断システムの動作の一例を示すフローチャートである。 実施の形態３に係る車両診断システムの動作の他の例を示すフローチャートである。 実施の形態３の変形例１に係る車両診断システムを示す概略図である。 実施の形態３の変形例１に係る車両診断システムを構成する車両診断装置及び複数の電気機器の通信接続関係を示す図である。 実施の形態３の変形例２に係る車両診断システムを示す概略図である。 実施の形態３の変形例２に係る車両診断システムを構成する複数の電気機器、コントローラ及び車両診断装置の通信接続関係を示す図である。 実施の形態３の変形例２に係る車両診断システムの構成の一部を示すブロック図である。 実施の形態４に係る車両診断システムを示す概略図である。 実施の形態４に係る車両診断システムの構成を示すブロック図である。 実施の形態５に係る車両診断システムを示す概略図である。 実施の形態５に係る車両診断システムの構成を示すブロック図である。 実施の形態５に係る車両診断システムの車両診断装置の概略図である。 実施の形態５に係る車両診断システムの動作の一例を示すフローチャートである。 実施の形態６に係る車両診断システムを示す概略図である。 実施の形態６に係る車両診断システムの構成を示すブロック図である。 実施の形態６に係る車両診断システムの動作の一例を示す図である。 実施の形態７に係る移動体診断装置の設置例を示す図である。 実施の形態７に係る移動体診断装置の構成を示すブロック図である。 実施の形態８に係る移動体診断システムを示す概略図である。 実施の形態８に係る移動体診断システムの構成を示すブロック図である。

本実施の形態に係る車両診断装置は、自動運転する車両が第三者にハッキングされているか否かを診断する診断機能を備える。車両診断装置が上記診断機能を備えることで、車両のハッキングによる被害を抑制することが可能となる。なお本実施の形態において、ハッキングとは、他人のコンピュータに不正に侵入して予期しない動作をさせる、あるいは正常な動作をさせないことを意味する。

以下、実施の形態について、図面を参照しながら具体的に説明する。なお、以下で説明する実施の形態は、いずれも本開示の一具体例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本開示を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、本開示の一形態に係る実現形態を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。本開示の実現形態は、現行の独立請求項に限定されるものではなく、他の独立請求項によっても表現され得る。

なお、各図は模式図であり、必ずしも厳密に図示されたものではない。また、各図において、実質的に同一の構成に対しては同一の符号を付しており、重複する説明は省略又は簡略化される場合がある。

（実施の形態１）
［１−１．車両診断装置の構成］
実施の形態１に係る車両診断装置１０の構成について、図１〜図６を参照しながら説明する。

図１は、実施の形態１に係る車両診断装置１０の設置例を示す図である。

車両診断装置１０は、車両５０を駐車する駐車場９１に設置される。図１では、車両診断装置１０が建造物６０の一例である住宅の外壁に設置されているが、それに限られず、車両診断装置１０は、住宅の屋根、塀、支柱等に設置されてもよい。

車両５０は、自動運転が可能な車両であり、例えば、自動車、自動二輪車等である。自動運転とは、自律的に自動車を運転することであり、例えば、運転者を必要としないで運転することはもちろん、運転者のハンドル操作やブレーキ操作を支援しながら運転することも含む。車両５０は、手動運転のモードと自動運転のモードとを相互に切換えることができる車両であってもよい。車両５０には、車両診断装置１０と通信する通信アンテナ５１、及び、車両診断装置１０から照射される照明光を認識するカメラ５２が設けられている。車両５０は、ＡＩアシスタント機能（ソフトウェアエージェント）を有している。なお、車両５０は、後述する移動体の一例である。

図２は、車両診断装置１０の構成を示すブロック図である。なお、図２には、ネットワークを介して車両診断装置１０と通信接続されるコンピュータも示されている。

図２に示されるように、車両診断装置１０は、車両５０と通信する通信部１１と、照明光を照射可能な照射部１２と、車両５０を検出する検出部１３と、車両５０の自動運転プログラムがハッキングされているか否かについて車両５０を診断する診断部１６とを備えている。また、車両診断装置１０は、照射部１２の点灯、消灯、調光及び調色を制御する制御部１５を備えている。

照射部１２は、照明光を照射する光源であり、例えば、静止画又は動画を投影する液晶プロジェクタ、又は、赤色、緑色、青色の光及びこれらの色の光が合成された光を発するＬＥＤ（Ｌｉｇｈｔ Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ）発光モジュールである。照射部１２は、ＲＧＢ、電球色（２７００Ｋ）や昼白色（５０００Ｋ）等の単体のＳＭＤ（Ｓｕｒｆａｃｅ Ｍｏｕｎｔ Ｄｅｖｉｃｅ）、ＣＯＢ（Ｃｈｉｐ Ｏｎ Ｂｏａｒｄ）の組み合わせでもよい。照射部１２は、車両５０及び車両５０の周囲を照らすため、車両５０の車高よりも高い位置に設けられる。

検出部１３は、駐車場９１における車両５０の有無を検出するセンサであり、例えば、画像センサ、赤外線センサ又はレーザセンサである。検出部１３は、常時稼働することで、駐車場９１に車両５０が駐車されているか否かを検出する。本実施の形態では、検出部１３が車両５０を検出することで照射部１２が点灯し、また、照射部１２の点灯に伴って診断部１６が車両５０を診断可能な状態となる。

通信部１１は、車両５０と無線ｒ１で通信する通信モジュールである。無線ｒ１による通信方式としては、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）、９２０ＭＨｚ帯の周波数を利用した特定小電力無線、Ｚｉｇｂｅｅ（登録商標）、又は、ＷｉＦｉ（登録商標）などの通信方式が用いられる。

制御部１５は、マイクロプロセッサ、メモリ１５ａ及びメモリ１５ａに格納されたプログラムなどによって構成される。メモリ１５ａには、車両ナンバーなどの車両５０の識別情報が保存されている。また、メモリ１５ａには、後述する車両５０の運行ログ及び診断結果が記録される。制御部１５は、照射部１２の点灯等を制御するとともに、通信部１１、検出部１３及び診断部１６の作動を制御する。

制御部１５は、例えば、検出部１３が車両５０を検出すると、通信部１１を介して車両５０の識別情報を要求する要求信号を車両５０へ発信する。そして、制御部１５は、車両５０から送信された車両５０の識別情報が、予め登録された識別情報と一致する場合に、車両５０の診断を行うように診断部１６に診断指令を出す。

なお、制御部１５は、上記要求信号を発信する代わりに、照射部１２から車両５０への可視光通信をトリガとして車両５０と通信し、車両５０の識別情報を取得してもよい。その場合に車両５０は、可視光通信の信号受信部であるカメラ５２を介して可視光通信により送信された情報を解読し、車両診断装置１０に対して車両５０の識別情報を返信してもよい。また、制御部１５は、車両ナンバーを検出部１３で撮像することで、車両５０の識別情報を取得してもよい。また、制御部１５は、検出部１３を用いる代わりに通信部１１を介して定期的にビーコン信号を発信し、車両５０に対して識別情報の返信要求をすることで、車両５０の識別情報を取得してもよい。すなわち制御部１５は、通信部１１を用いて車両５０を検出し、その後、通信部１１を介して診断を行ってもよい。

診断部１６は、通信部１１を介して車両５０がハッキングされているか否かを診断する回路である。診断部１６は、例えば、照射部１２の点灯状態が変化した場合に、駐車場９１に駐車されている車両５０に対して診断を行う。具体的には、診断部１６は、照射部１２が消灯から点灯に変化し、かつ、制御部１５からの診断指令を受け付けている場合に、ハッキング有無の診断を行う。

なお、診断部１６は、照射部１２が消灯から点灯に変化した場合に限られず、照射部１２が点灯から消灯又は減光状態に変化した場合あるいは点灯色が変化した場合に、ハッキング有無の診断を行ってもよい。また、診断部１６は、照射部１２が点灯から消灯又は減光状態に変化した後あるいは点灯色が変化した後、再度点灯状態が変化した場合に、ハッキング有無の診断を終了してもよい。なお、減光状態とは所定の明るさ以下となるように調光制御されている状態、例えば、１００％の照度のうち３０％の照度で点灯制御されている状態である。点灯色が変化するとは、色温度が変化するように調色制御された状態である。

ここで、診断部１６による車両診断について、３つの診断例を挙げながら説明する。

１つ目の診断例は、車両診断装置１０から車両５０に対して行った質問に対する回答に基づいて、車両診断を行う例である。診断部１６は、車両５０に対して複数の質問を行い、質問に対する回答時間及び回答傾向の少なくとも一方に基づいて、車両５０がハッキングされているか否かを判断する。

図３Ａは、車両診断装置１０の診断部１６から車両５０に対して行う質問の一例を示す図である。

例えば、診断部１６は、通信部１１を介して車両５０に一義的に回答が決まる質問を行い、質問に対する回答時間が予め決められた時間よりも遅い場合に、車両５０がハッキングされていると診断する。

一義的に回答が決まる質問とは、例えば、車両５０の乗車人数、車両５０の目的地、車両５０のオーナー（持ち主）席のシート位置、車内と車外との温度差、ブレーキ操作の有無に関する問いである。車両５０の乗車人数は、車両５０のカメラ５２によって取得できる。車両５０の目的地は、カーナビゲーションによって取得できる。車内と車外との温度差は、温度センサによって取得できる。オーナー席のシート位置は、オーナーが車両５０に事前に登録したシート位置によって取得できる。ブレーキ操作の有無は、車両５０のＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）によって取得できる。

上記の乗車人数、目的地、シート位置、温度差、ブレーキ操作の有無は、車両５０にとって瞬時に取得できるので、正常な車両５０であれば質問に対する回答を短時間で行うことができる。そこで診断部１６は、質問に対する回答時間が予め決められた時間よりも遅い場合に、車両５０がハッキングされていると判断し、回答時間が予め決められた時間内である場合に、車両５０がハッキングされていないと判断する。なお、一義的に回答が決まる質問及びその回答には、車両継続検査（車検）の検査内容であるハンドル操作指示、ブレーキ操作指示、及び、これらの操作指示に対する応答結果が含まれていてもよい。

また、例えば、診断部１６は、通信部１１を介して車両５０に一義的に回答が決まらない複数の質問を行い、複数の質問に対する回答のぶれ幅が予め決められたぶれ幅よりも小さい場合に、車両５０がハッキングされていると判断する。回答のぶれ幅とは、同類の複数の質問に対する複数の回答のばらつきの大きさである。

一義的に回答が決まらない質問とは、例えば、オーナーの気分・機嫌、運行ルートの決定基準、オーナーの車両５０に対する満足度、オーナーの幸福度、車両５０の周辺地域における気象状況などに関する問いである。オーナーの気分・機嫌は、オーナーの言動を車内のマイク及びカメラ５２で検出することで取得できる。運行ルートの決定基準は、予め登録されたオーナー好みの運行ルートから取得できる。オーナーの車両５０に対する満足度は、オーナーの車両５０に対する接し方、扱い方をマイク及びカメラ５２で検出することで取得できる。オーナーの幸福度は、オーナーの顔の表情をカメラ５２で検出することで取得できる。車両５０の周辺地域における気象状況は、カメラ５２、車両５０に設けられた気象センサにより取得できる。

例えば、オーナーの幸福度は、オーナーの無意識下における幸福度であり、オーナー自身も気づかない第三者の視点から見た幸福度である。この幸福度は、自動運転又は手動運転時における会話、独り言や言葉の語尾、声色を車両５０内のカメラ又はマイクで検出し、検出結果をＡＩ（Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ）を用いて処理することで導出できる。なお、オーナーの幸福度は、オーナーに対する直接の問いかけによって取得してもよいし、運転後の一言アンケート等で調査することによって取得してもよい。

上記のオーナーの気分・機嫌、運行ルートの決定基準、満足度、幸福度、気象状況は、天気、道路混雑状況、物価指数、仕事の進捗、対人関係などによって変わるものであり、正常な車両５０であれば、回答にぶれ幅が生じる。一方、車両５０が第三者にハッキングされている場合は、回答のぶれ幅が小さく、又は、決まりきった回答しか得られないことが多い。そこで診断部１６は、複数の質問に対する回答のぶれ幅が予め決められたぶれ幅以上である場合に、車両５０がハッキングされていないと診断し、回答のぶれ幅が予め決められたぶれ幅よりも小さい場合に、車両５０がハッキングされていると判断する。

このように、車両診断装置１０から車両５０に対して質疑応答を行うことで、車両５０がハッキングされているか否かを診断することができる。

ここで、車両５０がオーナーの幸福度を判断する場面について説明する。幸福度は、例えば平常状態、リラックス状態、緊張状態、疲労状態、ご機嫌状態など各種の状態となってオーナーに表れる。オーナーがどのような状態にあるかは、車両５０が、オーナーの言動、例えば声色、発言、声の大きさ、舌打ち又は鼻歌などを検出することで把握することができる。

図３Ｂは、車両５０に乗車中のオーナーに表れる状態の一例を示す図である。なお、図３Ｂ及び後述する図３Ｃ、図３Ｄにおける矢印は、上向きだと気持ちが高揚するなどしてポジティブな気分に変化すること、下向きだと気持ちが抑鬱するなどしてネガティブな気分に変化すること、真横向きだと気持ちに浮き沈みがないことを示している。

図３Ｂの（ａ）には、自宅の近くではオーナーが手動運転し、その後しばらくは車両５０が自動運転し、会社の近くになるとオーナーが再び手動運転する例が示されている。図３Ｂの（ｂ）には、会社の近くではオーナーが手動運転し、その後しばらくは車両５０が自動運転し、自宅の近くになるとオーナーが再び手動運転する例が示されている。

図３Ｂの（ａ）に示すように、出社するときのオーナーは、車両５０が自動運転になるとリラックス状態になり、会社に近づくにつれて緊張状態に変わる。一方、図３Ｂの（ｂ）に示すように、帰宅するときのオーナーは、最初は疲労状態にあるが、時間が経過するにつれて平常状態に戻り、その後、リラックス状態に変わる。上記はあくまでの一例であるが、例えば車両５０が、オーナーを日々定点観測し、オーナーに表れる状態をデータ化して蓄積することで、時と場所によって変化するオーナーの幸福度を判断することが可能となる。

図３Ｃは、車両５０に乗車中のオーナーに表れる状態の他の一例を示す図である。図３Ｃの上段には、休日に自動運転する例が示され、図３Ｃの下段には、休日に手動運転する例が示されている。

図３Ｃの上段に示すように、自動運転する車両５０に乗車するオーナーは、目的地に向かうときに家族等と会話をすることによってご機嫌状態となり、自宅に帰るときは、疲労もそれほど残らず平常状態を維持する。一方、図３Ｃの下段に示すように、手動運転する車両５０に乗車するオーナーは、運転に注力するため家族等と会話する時間が短くなり、また、自宅に帰るときは疲労状態となる。このように手動運転では、運転のために気力及び体力注ぐこととなるが、自動運転では自身の運転を鑑みる必要がなく、全力で家族サービスを行うことができる。上記はあくまでも一例であるが、例えば車両５０が、オーナーを日々定点観測し、オーナーに表れる状態をデータ化して蓄積することで、自動運転と手動運転によって変化するオーナーの幸福度を判断することが可能となる。

図３Ｄは、車両５０に乗車中のオーナーに表れる状態の他の一例を示す図である。図３Ｄに示すように、オーナーは、車両５０を購入したときや友人とドライブするときは、ご機嫌状態となる。一方、車両５０の車検時には費用が必要となるので不機嫌な状態となる。また一方で、車両５０を売却するときは、例えば自動運転可能な車両５０であると高価に売却することができ、ご機嫌状態になる。上記はあくまでの一例であるが、例えば車両５０が、オーナーを日々定点観測し、オーナーに表れる状態をデータ化して蓄積することで、車両５０の購入から売却に至るまでに変化するオーナーの幸福度を判断することが可能となる。

このように、車両５０がオーナーを日々定点観測することで、オーナーの幸福度を判断することができる。この幸福度は所定のぶれ幅があるので、車両診断装置１０は、車両５０に対して幸福度に関する質疑応答を行い、ぶれ幅の大小によって車両５０がハッキングされているか否かを診断することができる。

２つ目の診断例は、車両５０に搭載された走行システムを動かすソフトウェアの強靭性を確認することで車両診断を行う例である。診断部１６は、通信部１１を介して、車両５０のソフトウェアの強靭性を確認することで、上記診断を行う。そして、診断部１６は、ソフトウェアの強靭性のレベルが予め決められたレベルよりも低い場合に、車両５０がハッキングされていると診断する。なお、車両５０を診断する場合に、ソフトウェアの脆弱性を確認することは、ソフトウェアの強靭性を確認することと実質的に同じである。

図４は、車両診断装置１０から車両５０に対して行うソフトウェアの強靭性確認手段を示す図である。

例えば、診断部１６は、通信部１１を介して車両５０にＤｏＳ（Ｄｅｎｉａｌ ｏｆ Ｓｅｒｖｉｃｅ）攻撃及びバッファオーバーフロー攻撃の少なくとも一方の模擬攻撃を行うことで、ソフトウェアの強靭性を確認する。ＤｏＳ攻撃とは、パケットによって車両５０に大量のデータを送信したり、大量のリクエストを行ったりすることである。バッファオーバーフロー攻撃とは、車両５０のマイクロプロセッサに許容量以上のデータを送り、マイクロプロセッサの処理を遅らせることである。

車両５０がハッキングされていると、これらの模擬攻撃によって車両５０のソフトウェアの処理速度が極端に遅くなるなど、車両５０に変化が起きる。そこで診断部１６は、車両５０にこれらの模擬攻撃を行って、車両５０の強靭性のレベルが予め決められたレベルよりも低くならなかった場合に、車両５０がハッキングされていないと判断し、予め決められたレベルよりも低くなった場合に、車両５０がハッキングされていると判断する。ソフトウェアの強靭性のレベルは、表１に示すように、模擬攻撃及び後述するトラップデータの送信に対する耐性を示すレベルである。予め決められた強靭性のレベルは、例えば、レベル５又はレベル４に設定される。

例えば、診断部１６は、ＤｏＳ攻撃によってソフトウェアの強靭性のレベルが予め決められたレベルよりも低くなった場合に、車両５０のソフトウェアが機能しなくなるまでＤｏＳ攻撃を継続し、車両５０に搭載された走行システムをダウンさせてもよい。

また、診断部１６は、通信部１１を介して車両５０にトラップデータを送信することで、ソフトウェアの強靭性を確認する。トラップデータの送信は、ハッカーが作ったバックドアへの対処策である。トラップデータには、例えば、ログインＩＤ又は車検情報などの重要項目にハッカーがバックドアを介してアクセスしたか否かを確認する罠が仕込まれていたり、ソフトウェアのバージョンアップの時刻にハッカーがバックドアを介して侵入したか否かを確認する罠が仕込まれていたりする。そこで診断部１６は、車両５０にトラップデータを送信して、不正アクセス又は不正侵入などが発生しなかった場合に、車両５０がハッキングされていないと判断し、上記の不正アクセス又は不正侵入が発生した場合に、車両５０がハッキングされていると判断する。例えば、診断部１６は、トラップデータの送信によってソフトウェアにバックドアが形成されていることを見つけた場合に、ソフトウェアの強靭性のレベルが予め決められたレベルよりも低く、車両５０がハッキングされていると診断してもよい。

このように、車両診断装置１０から車両５０に対してソフトウェアの強靭性を確認することで、車両５０がハッキングされているか否かを診断することができる。

３つ目の診断例は、車両５０の運行ログを取得し、運行ログに基づいて車両診断を行う例である。診断部１６は、通信部１１を介して車両５０の運行ログを取得し、車両５０が予め決められた運行規則を守っていないことを確認した場合に、車両５０がハッキングされていたと診断する。

図５は、車両診断装置１０の診断部１６で取得する車両の運行ログの一例を示す図である。

運行ログは、例えば、日時、場所（緯度経度）、車両５０の速度、車両５０のハンドル角度などである。運行規則とは、例えば、車両５０の急停車、急発進、ハンドル回し角度及び車両の最高速度などに関する取り決めである。診断部１６は、車両５０がこれらの運行規則通りに運転されているか否かを判断する。診断部１６は、車両５０が予め決められた運行規則を守っていない場合に、車両５０がハッキングされていたと判断し、運行規則を守っている場合に、車両５０がハッキングされていなかったと判断する。

このように、診断部１６が車両５０の運行ログを取得し、運行ログに基づいて車両診断を行うことで、車両５０がハッキングされているか否かを診断することができる。

診断部１６によって車両５０がハッキングされていると診断された場合、制御部１５は、照射部１２の照明光を用いて車両５０がハッキングされていることを報知する。例えば、照射部１２が液晶プロジェクタである場合、制御部１５は、照射部１２から照射される静止画又は動画を車両５０又は駐車場９１に照射して、ハッキングに関する情報を報知する。

図６は、車両診断装置１０によって報知される報知情報の一例を示す図である。

図６の（ａ）には、車両５０のボンネットに「ハッキングされています」という報知情報が投光されている例が示され、図６の（ｂ）には、駐車場９１の地面に「ＷＡＲＮＩＮＧ」という文字からなる報知情報が投光されている例が示されている。照射部１２から投光される報知情報は、文字に限られず、図形、記号等を含むマークであってもよい。

これによれば、車両５０を使用するユーザが、車両５０がハッキングされているか否かを視覚的に知ることができる。これにより、ユーザはハッキングされた車両５０に対策を施すことができ、車両５０のハッキングによる被害を抑制することができる。

なお、車両診断装置１０は、診断結果を報知する他の例として、ネットワークを介して車両診断装置１０に通信接続されているコンピュータに診断結果を報知してもよい（図２参照）。例えば、車両診断装置１０は、車両５０のディーラーが所有するコンピュータである管理サーバーに診断結果を送信してもよい。また、車両診断装置１０は、オーナー又はディーラーが予め登録したメールアドレスに電子メールを送信することで、診断結果を報知してもよい。これにより、オーナー又はディーラーはハッキングされた車両５０に対策を施すことができ、車両５０のハッキングによる被害を抑制することができる。

［１−２．車両診断装置の動作］
次に、実施の形態１に係る車両診断装置１０の動作について、図７〜図１０を参照しながら説明する。

図７は、車両診断装置１０の動作を示すフローチャートである。

まず、車両５０が駐車場９１に駐車され、車両診断装置１０の検出部１３が車両５０を検出する（ステップＳ１１）。

本実施の形態では、検出部１３が車両５０を検出すると、照射部１２の点灯状態が変化する（ステップＳ１２）。具体的には、照射部１２が消灯から点灯に変化する。

照射部１２の点灯状態が変化する、又は検出部１３が車両５０を検出すると、車両診断装置１０の診断部１６は、車両５０の診断を実行し（ステップＳ１３）、車両５０がハッキングされているか否かを判断する（ステップＳ１４）。ここで車両５０がハッキングされていないと判断された場合、制御部１５は、車両５０がハッキングされていないという診断結果をメモリ１５ａに記録する（ステップＳ１５）。

一方、車両５０がハッキングされていると判断された場合、制御部１５は、異常を報知する（ステップＳ１６）。制御部１５は、例えば、照射部１２の照明光を車両５０又は駐車場９１に照射させることで、異常を報知する。そして制御部１５は、車両５０がハッキングされているという診断結果をメモリ１５ａに記録する（ステップＳ１７）。これにより、車両診断装置１０による車両５０のハッキング有無の診断を終了する。

ここでさらに、ステップＳ１３にて実行される診断部１６の動作の３つの例について、図８〜図１１を参照しながら説明する。

図８は、車両診断装置１０の診断部１６の動作の一例を示すフローチャートである。図８は、車両５０に対して行う質疑応答のうち、一義的に回答が決まる質問を行う例を示している。

まず、診断部１６は、車両５０に対して一義的に回答が決まる複数の質問を行う（ステップＳ１３１）。これらの複数の質問は、車両５０に対してランダムにかつタイミングを変えて行われる。

次に診断部１６は、予め決められた時間内に車両５０から回答があったか否かを判断する（ステップＳ１３２）。ここで予め決められた時間内に車両５０から回答があった場合（Ｓ１３２にてＹｅｓ）、診断部１６は、車両５０がハッキングされていないと判断する（ステップＳ１３３）。

一方、予め決められた時間内に車両５０から回答がなかった場合（Ｓ１３２にてＮｏ）、診断部１６は、車両５０がハッキングされていると判断する（ステップＳ１３４）。このように、一義的に回答が決まる質問を行うことで、車両５０のハッキング有無を診断することができる。

図９は、車両診断装置１０の診断部１６の動作の他の例を示すフローチャートである。図９は、車両５０に対して行う質疑応答のうち、一義的に回答が決まらない質問を行う例を示している。

まず、診断部１６は、車両５０に対して一義的に回答が決まらない複数の質問を行う（ステップＳ１３１Ａ）。これらの複数の質問は、車両５０に対してランダムにかつタイミングを変えて行われる。

次に診断部１６は、車両５０からの回答のぶれ幅が予め決められたぶれ幅以上であるか否かを判断する（ステップＳ１３２Ａ）。ここで回答のぶれ幅が予め決められたぶれ幅以上である場合（Ｓ１３２ＡにてＹｅｓ）、診断部１６は、車両５０がハッキングされていないと判断する（ステップＳ１３３Ａ）。

一方、回答のぶれ幅が予め決められたぶれ幅よりも小さい場合（Ｓ１３２ＡにてＮｏ）、診断部１６は、車両５０がハッキングされていると判断する（ステップＳ１３４Ａ）。このように、一義的に回答が決まらない質問を行うことで、車両５０のハッキング有無を診断することができる。

なお、上記では一義的に回答が決まる質問及び一義的に回答が決まらない質問のそれぞれ別々に説明したが、診断部１６は、一義的に回答が決まる質問及び一義的に回答が決まらない質問のうちの両方の質問をランダムにタイミングを変えて行い、ハッキング有無の診断を行ってもよい。

図１０は、車両診断装置１０の診断部１６の動作の他の例を示すフローチャートである。図１０は、車両５０に搭載された走行システムを動かすソフトウェアの強靭性を確認する例を示している。

まず、診断部１６は、車両５０に対してソフトウェアの強靭性を確認するためのデータを送信する（ステップＳ１３１Ｂ）。

次に診断部１６は、ソフトウェアの強靭性が予め決められたレベルよりも低いか否かを判断する（ステップＳ１３２Ｂ）。ここでソフトウェアの強靭性が予め決められたレベルよりも低くなかった場合、診断部１６は、車両５０がハッキングされていないと判断する（ステップＳ１３３Ｂ）。

一方、ソフトウェアの強靭性が予め決められたレベルよりも低い場合、診断部１６は、車両５０がハッキングされていると判断する（ステップＳ１３４Ｂ）。すると診断部１６は、ソフトウェアが機能しなくなるまで、模擬攻撃を継続し（ステップＳ１３５Ｂ）、車両５０に搭載された走行システムをダウンさせる。このように、ソフトウェアの強靭性を確認することで、車両５０のハッキング有無を診断することができる。

図１１は、車両診断装置１０の診断部１６の動作の他の例を示すフローチャートである。図１１は、車両５０の運行ログに基づいて車両５０のハッキング有無を判断する例を示している。

まず、診断部１６は、車両５０の運行ログを取得する（ステップＳ１３１Ｃ）。

次に診断部１６は、車両５０が予め決められた運行規則を守っていたか否かを判断する（ステップＳ１３２Ｃ）。ここで車両５０が運行規則を守っていた場合（Ｓ１３２ＣにてＹｅｓ）、診断部１６は、車両５０がハッキングされていないと判断する（ステップＳ１３３Ｃ）。

一方、車両５０が運行規則を守っていない場合（Ｓ１３２ＣにてＮｏ）、診断部１６は、車両５０がハッキングされていたと判断する（ステップＳ１３４Ｃ）。このように、運行ログに基づいて車両５０のハッキング有無を判断することができる。

このように車両診断装置１０は、図８〜図１１に示された動作によって、車両５０のハッキング有無を診断することができる。これにより、車両５０のハッキングによる被害を抑制することができる。

（実施の形態２）
［２−１．車両診断装置の構成］
実施の形態２に係る車両診断装置１０Ａの構成について、図１２〜図１４を参照しながら説明する。実施の形態２では、車両診断装置１０Ａがポータブル型の車両診断装置である例について説明する。

図１２は、実施の形態２に係る車両診断装置１０Ａの使用例を示す図である。図１３は、車両診断装置１０Ａの構成を示すブロック図である。

図１２に示されるように、車両診断装置１０Ａは、人が携帯可能な懐中電灯であり、円柱状及び円錐台状の形状を有している。図１３に示されるように、車両診断装置１０Ａは、車両５０と通信する通信部１１と、照明光を照射可能な照射部１２と、スイッチ１４と、車両５０の自動運転プログラムがハッキングされているか否かについて車両５０を診断する診断部１６と、出力部１７とを備えている。また、車両診断装置１０Ａは、照射部１２の点灯、消灯、調光及び調色を制御する制御部１５を備えている。

照射部１２は、照明光を照射する光源であり、例えば、赤色、緑色、青色の光及びこれらの色の光が合成された光を発するＬＥＤ発光モジュールである。照射部１２は、ＲＧＢ、電球色や昼白色等の単体のＳＭＤ、ＣＯＢの組み合わせでもよい。照射部１２は、車両５０を照らすため、車両診断装置１０Ａの端部に設けられている。

スイッチ１４は、車両診断装置１０Ａの点灯又は消灯の操作入力をする入力部である。本実施の形態では、スイッチ１４がＯＮされることで、照射部１２が点灯し、照射部１２の点灯に伴って診断部１６が車両５０を診断可能な状態となる。また、スイッチ１４がＯＦＦされることで、照射部１２が消灯し、照射部１２の消灯に伴って診断部１６が車両５０の診断を終了する。

通信部１１は、車両５０と無線ｒ１で通信する通信モジュールである。無線ｒ１による通信方式は、前述のとおりである。

出力部１７は、診断部１６による診断結果を外部に出力するための出力端子であり、例えばＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）端子である。

制御部１５は、マイクロプロセッサ、メモリ１５ａ及びメモリ１５ａに格納されたプログラムなどによって構成される。メモリ１５ａには、車両ナンバーなどの車両５０の識別情報が保存されている。また、メモリ１５ａには、後述する車両５０の運行ログ及び診断結果が記録される。制御部１５は、照射部１２の点灯等を制御するとともに、通信部１１、診断部１６及び出力部１７の作動を制御する。

制御部１５は、例えば、スイッチ１４のＯＮ操作を受け付けると、通信部１１を介して車両５０の識別情報を要求する要求信号を車両５０へ発信する。そして、制御部１５は、車両５０から送信された車両５０の識別情報が、予め登録された識別情報と一致する場合に、車両５０の診断を行うように診断部１６に診断指令を出す。なお、制御部１５は、上記要求信号を発信する代わりに、照射部１２から車両５０への可視光通信をトリガとして車両５０と通信し、車両５０の識別情報を取得してもよい。

診断部１６は、通信部１１を介して車両５０がハッキングされているか否かを診断する回路である。診断部１６は、例えば、照射部１２の点灯状態が変化した場合に、駐車場９１に駐車されている車両５０に対して診断を行う。具体的には、診断部１６は、照射部１２が消灯から点灯に変化し、かつ、制御部１５からの診断指令を受け付けている場合に、ハッキング有無の診断を行う。

診断部１６による車両診断については、前述したように３つの診断例がある。

１つ目の診断例は、車両診断装置１０Ａから車両５０に対して行った質問に対する回答に基づいて、車両診断を行う例である。診断部１６は、車両５０に対して複数の質問を行い、質問に対する回答時間及び回答傾向の少なくとも一方に基づいて、車両５０がハッキングされているか否かを判断する。

２つ目の診断例は、車両５０に搭載された走行システムを動かすソフトウェアの強靭性を確認することで車両診断を行う例である。診断部１６は、通信部１１を介して車両５０のソフトウェアの強靭性を確認し、強靭性のレベルが予め決められたレベルよりも低い場合に、車両５０がハッキングされていると診断する。

３つ目の診断例は、車両５０の運行ログを取得し、運行ログに基づいて車両診断を行う例である。診断部１６は、通信部１１を介して車両５０の運行ログを取得し、車両５０が予め決められた運行規則を守っていないことを確認した場合に、車両５０がハッキングされていたと診断する。

診断部１６によって車両５０がハッキングされていると診断された場合、制御部１５は、照射部１２の照明光を用いて車両５０がハッキングされていることを報知する。

図１４は、車両診断装置１０Ａの照射部１２の点灯状態を示す図である。

図１４に示されるように、車両診断装置１０Ａは、スイッチ１４がＯＮされて診断を開始すると１００％点灯し、車両５０と通信して診断している最中は点滅状態となる。そして診断結果が、ハッキングされていないという結果のときに青色点灯し、ハッキングされているという結果のときに赤色点灯する。

これによれば、車両５０を使用するユーザが、車両５０がハッキングされているか否かを視覚的に知ることができる。これにより、ユーザはハッキングされた車両５０に対策を施すことができ、車両５０のハッキングによる被害を抑制することができる。

［２−２．車両診断装置の動作］
次に、実施の形態２に係る車両診断装置１０Ａの動作について説明する。

図１５は、車両診断装置１０Ａの動作を示すフローチャートである。

まず、車両診断装置１０Ａは、ユーザによるスイッチ１４のＯＮ操作を受け付ける（ステップＳ２１）。これにより、照射部１２が点灯する（ステップＳ２２）。

次に、車両診断装置１０Ａの診断部１６は、車両５０の診断を実行し（ステップＳ２３）、車両５０がハッキングされているか否かを判断する（ステップＳ２４）。ここで車両５０がハッキングされていないと判断された場合、制御部１５は、照射部１２を用いて正常報知を行い（ステップＳ２５）、車両５０がハッキングされていないという診断結果をメモリ１５ａに記録する（ステップＳ２６）。

一方、車両５０がハッキングされていると判断された場合、制御部１５は、照射部１２を用いて異常報知を行い（ステップＳ２７）、車両５０がハッキングされているという診断結果をメモリ１５ａに記録する（ステップＳ２８）。そして、車両診断装置１０Ａは、スイッチ１４のＯＦＦ操作を受け付けると照射部１２を消灯し、車両５０のハッキング有無の診断を終了する。

このように、車両診断装置１０Ａは、ステップＳ２１〜Ｓ２８に示された動作によって、車両５０のハッキング有無を診断することができる。これにより、車両５０のハッキングによる被害を抑制することができる。

（実施の形態３）
［３−１．車両診断システムの構成］
実施の形態３に係る車両診断システム１の構成について、図１６及び図１７を参照しながら説明する。実施の形態３では、車両診断機能を有する車両診断装置１０が、ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）システムの一部を構成している例について説明する。

図１６は、実施の形態３に係る車両診断システム１を示す概略図である。

図１６に示されるように、車両診断システム１は、車両診断装置１０と、複数の照明機器とによって構成されている。車両診断装置１０は、建造物６０の外壁に設置されている。複数の照明機器のうちの玄関照明６１、リビング照明６２、階段照明６３、トイレ照明６４、寝室照明６５のそれぞれは、建造物６０の玄関、リビング、階段、トイレ、寝室のそれぞれに対応して設置されている。これらの照明機器のそれぞれは、無線通信機能を有している。

図１７は、車両診断システム１を構成する車両診断装置１０及び複数の照明機器の通信接続関係を示す図である。

図１７に示されるように、車両診断装置１０、玄関照明６１、リビング照明６２、階段照明６３、トイレ照明６４及び寝室照明６５は、メッシュネットワークを構成し、相互に通信可能となっている。ここでいうメッシュネットワークの例としては、ＢＬＥ（Ｂｌｕｅｔｏｏｔｈ（登録商標） Ｌｏｗ Ｅｎｅｒｇｙ）のアドホックネットワークが挙げられる。

本実施の形態の車両診断システム１では、車両診断装置１０の診断部１６が、建造物６０内に設けられた照明機器の点灯状態に応じて診断を開始したり、診断を終了したりする。以下、上記構成を有する車両診断システム１の動作について説明する。

［３−２．車両診断システムの動作］
実施の形態３に係る車両診断システム１の動作について、図１８及び図１９を参照しながら説明する。

図１８は、車両診断システム１の動作の一例を示すフローチャートである。

まず、車両５０のオーナーが帰宅すると、その帰宅に伴って車両診断装置１０の照射部１２及び玄関照明６１が点灯する（ステップＳ３１）。そして、オーナーが住宅内に入り、屋内の各照明を点灯させる（ステップＳ３２）。

例えば、時刻２４時（０時）の就寝時間になると、オーナーは寝室に入って寝室照明６５を消灯する（ステップＳ３３）。就寝する際、車両診断システム１に含まれる複数の照明機器は、リビング照明６２、階段照明６３、寝室照明６５の順で寝室に向かって順に消灯するので、車両診断システム１は、オーナーが寝床に就くことを認識できる。そこで、車両診断システム１は、寝室の遠くから寝室の近くに向けて照明機器が順に消灯されたとき、オーナーが寝床に就いて車両５０が長時間にわたり駆動しない状態になるので、この時間を利用して車両診断を開始する（ステップＳ３４）。

時刻６：００の起床時間になると、オーナーは寝室照明６５を点灯する（ステップＳ３５）。この点灯により、車両診断システム１は、オーナーが車両５０を使用して数十分後に出勤することを認識できる。そこで、車両診断システム１は、この起床時間帯において寝室照明６５が点灯されると、車両診断を終了する（ステップＳ３６）。車両診断システム１は、車両診断を終了する際、診断結果を車両診断装置１０のメモリ１５ａに記録させる。

この車両診断システム１によれば、日常生活における照明機器の点灯及び消灯等を利用して、車両５０のハッキング有無を診断することができる。これにより、車両５０のハッキングによる被害を抑制することができる。

図１９は、車両診断システム１の動作の他の例を示すフローチャートである。ステップＳ３１〜Ｓ３４は、図１８と同様であるので説明を省略する。

図１９では、時刻２：００の深夜に、何らかの理由で外出する必要が生じた場合について説明する。オーナーは深夜に起床すると、寝室照明６５などの屋内の各照明機器を点灯する（ステップＳ３５Ａ）。例えばオーナーは出勤する際に、寝室照明６５、リビング照明６２、玄関照明６１の順で照明機器を点灯させて駐車場９１に向かう。車両診断システム１は、照明機器が寝室照明６５、リビング照明６２、玄関照明６１の順で点灯することで、オーナーが車両５０を使用してすぐに外出することを認識できる。そこで、車両診断システム１は、この深夜の時間において、照明機器が玄関に向かって順に点灯されると、車両診断を終了する（ステップＳ３６Ａ）。車両診断システム１は、車両診断を終了する際に、車両診断が途中である場合は、診断途中の結果をメモリ１５ａに記録させる。これにより、車両診断の強制終了によるシステム負荷及びシステムへの悪影響を未然防止することができる。

この車両診断システム１によれば、日常生活における照明機器の点灯及び消灯等を利用して、車両５０のハッキング有無を診断することができる。これにより、車両５０のハッキングによる被害を抑制することができる。

なお、上記では複数の照明機器がＩｏＴシステムを構成している例を示したが、それに限られず、スマートフォン、スマートスピーカ又は目覚まし時計をＩｏＴシステムと連動させてもよい。その場合、車両診断システム１は、例えばスマートフォンに記録されたスケジュール帳、スマートスピーカで読み取ったオーナーの言動、目覚まし時計に設定された起床時間等に基づいて、車両診断の開始時刻及び終了時刻を決定してもよい。

［３−３．実施の形態３の変形例１］
次に、実施の形態３の変形例１に係る車両診断システム１Ａの構成について、図２０及び図２１を参照しながら説明する。実施の形態３の変形例１でも、車両診断機能を有する車両診断装置１０が、ＩｏＴシステムの一部を構成している例について説明する。

図２０は、実施の形態３の変形例１に係る車両診断システム１Ａを示す概略図である。

図２０に示されるように、車両診断システム１Ａは、車両診断装置１０と、複数の電気機器とによって構成されている。車両診断装置１０は、建造物６０の外壁に設置されている。複数の電気機器のうち、玄関照明６１、リビング照明６２、階段照明６３、トイレ照明６４、寝室照明６５のそれぞれは、建造物６０の玄関、リビング、階段、トイレ、寝室のそれぞれに対応して設置されている。また本変形例では、建造物６０内において、人感センサ６６及び寝室スイッチ６７が寝室に設置され、照明コントローラ６９がリビングに設置されている。

図２１は、車両診断システム１Ａを構成する車両診断装置１０及び複数の電気機器の通信接続関係を示す図である。

図２１に示されるように、玄関照明６１、リビング照明６２、階段照明６３、トイレ照明６４、寝室照明６５、人感センサ６６、寝室スイッチ６７のそれぞれは、ネットワークを介して照明コントローラ６９に通信接続されている。複数の照明機器、人感センサ６６及び寝室スイッチ６７を含むそれぞれの電気機器は、照明コントローラ６９によって作動制御される。

例えば照明コントローラ６９は、寝室の人感センサ６６が人を検知した状態で、かつ、寝室スイッチ６７がＯＦＦされた場合に、寝室照明６５を消灯し、車両診断装置１０による車両５０の診断を開始する。変形例の車両診断システム１Ａでは、複数の電気機器のうち少なくとも一つの電気機器の作動状態が変化した場合に、車両５０に対して診断を行う。具体的には、車両診断装置１０の診断部１６が、建造物６０内に設けられた他の電気機器の点灯状態及び作動状態に応じて診断を開始したり、診断を終了したりする。この変形例においても、日常生活における照明機器の点灯及び消灯等を利用して、車両５０のハッキング有無を診断することができる。これにより、車両５０のハッキングによる被害を抑制することができる。

［３−４．実施の形態３の変形例２］
次に、実施の形態３の変形例２に係る車両診断システム１Ｂの構成について、図２２及び図２３を参照しながら説明する。実施の形態３の変形例２では、車両診断システム１Ｂの車両診断装置１０Ｂが、車両５０以外の機器との通信を断ち切った状態で、車両５０の診断を行う例について説明する。

図２２は、実施の形態３の変形例２に係る車両診断システム１Ｂを示す概略図である。

図２２に示されるように、車両診断システム１Ｂは、複数の電気機器と、コントローラ６９Ｂと、車両診断装置１０Ｂとによって構成されている。車両診断装置１０Ｂは、建造物６０の外壁に設置されている。複数の電気機器のうち、玄関照明６１、リビング照明６２、階段照明６３、トイレ照明６４、寝室照明６５のそれぞれは、建造物６０の玄関、リビング、階段、トイレ、寝室のそれぞれに対応して設置されている。また、人感センサ６６及び寝室スイッチ６７は、寝室に設置され、ドアスイッチ６８は玄関のドアに設置され、コントローラ６９Ｂはリビングに設置されている。

図２３は、車両診断システム１Ｂを構成する複数の電気機器、コントローラ６９Ｂ及び車両診断装置１０Ｂの通信接続関係を示す図である。図２４は、車両診断システム１Ｂの構成の一部を示すブロック図である。

図２３に示されるように、車両診断装置１０Ｂ、玄関照明６１、リビング照明６２、階段照明６３、トイレ照明６４、寝室照明６５、人感センサ６６、ドアスイッチ６８、寝室スイッチ６７のそれぞれは、コントローラ６９Ｂに通信接続されている。

図２４に示されるように、車両診断装置１０Ｂは、車両５０と通信する通信部３１と、ネットワークを介して複数の電気機器と通信する通信部３２と、車両５０の自動運転プログラムがハッキングされているか否かについて車両５０を診断する診断部３６と、通信部３１、通信部３２及び診断部３６の作動を制御する制御部３５とを備えている。

車両診断装置１０Ｂの制御部３５は、複数の電気機器のうち少なくとも一つの電気機器の作動状態が変化した場合に、車両５０に対して診断を行うように診断部３６を制御する。例えば、電気機器の作動状態が変化した場合とは、電気機器である照明機器の点灯状態が変化した場合であり、電気機器である人感センサ６６がオーナーを検知した場合であり、電気機器である寝室スイッチ６７がオフされた場合であり、又は、電気機器であるドアスイッチ６８がオンした場合である。

変形例２の車両診断装置１０Ｂは、診断部３６が通信部３１を介して上記診断を行う際に、ネットワーク及び通信部３２を介して通信する複数の電気機器との通信を遮断した状態で診断を行うように診断部３６を制御する。そして上記診断が終了した後、通信部３２を用いて複数の電気機器との通信を回復する。このように、車両５０のハッキングの診断を行う際に複数の電気機器との通信を遮断することで、例えば、ハッキングされた車両５０が複数の電気機器に対して悪影響を及ぼすことを抑制できる。

なお、変形例２の車両診断システム１Ｂでは、車両診断装置１０Ｂが複数の電気機器との通信を遮断して車両５０の診断を行う例について示したが、それに限られない。例えば、車両診断装置１０Ｂが、複数の電気機器との通信を遮断した後、車両５０と通信して車両５０の運行ログをダウンロードし、その後、車両５０との通信を遮断した状態で運行ログを用いて車両５０を診断してもよい。

（実施の形態４）
実施の形態４の車両診断システム１Ｃの構成について、図２５及び図２６を参照しながら説明する。実施の形態４では、車両診断システム１Ｃが、照明装置ＬＣと車両診断装置１０Ｃとによって構成されている例について説明する。

図２５は、実施の形態４に係る車両診断システム１Ｃを示す概略図である。

車両診断システム１Ｃの照明装置ＬＣ及び車両診断装置１０Ｃは、車両５０が駐車する駐車場９１に設置されている。図２５では、照明装置ＬＣが駐車場９１の壁に設置されているが、それに限られず、照明装置ＬＣは、駐車場９１の天井、支柱等に設置されてもよい。

図２６は、車両診断システム１Ｃの構成を示すブロック図である。なお、図２６には、ネットワークを介して車両診断システム１Ｃと通信接続されるコンピュータも示されている。

図２６に示されるように、車両診断システム１Ｃは、照明装置ＬＣと車両診断装置１０Ｃとによって構成されている。照明装置ＬＣは、照明光を照射可能な照射部１２と、車両５０を検出する検出部１３と、照射部１２及び検出部１３の作動を制御する制御部１５とを備えている。車両診断装置１０Ｃは、車両５０と通信する通信部３１と、車両５０の自動運転プログラムがハッキングされているか否かについて車両５０を診断する診断部３６と、通信部３１及び診断部３６の作動を制御する制御部３５とを備えている。

照明装置ＬＣの照射部１２は、照明光を照射する光源であり、例えば、静止画又は動画を投影する液晶プロジェクタ、又は、赤色、緑色、青色の光及びこれらの色の光が合成された光を発するＬＥＤ発光モジュールである。照射部１２は、ＲＧＢ、電球色や昼白色等の単体のＳＭＤ、ＣＯＢの組み合わせでもよい。照射部１２は、車両５０及び車両５０の周囲を照らすため、車両５０の車高よりも高い位置に設けられる。

照明装置ＬＣの検出部１３は、駐車場９１における車両５０の有無を検出するセンサであり、例えば、画像センサ、赤外線センサ又はレーザセンサである。検出部１３は、常時稼働することで、駐車場９１に車両５０が駐車されているか否かを検出する。本実施の形態では、検出部１３が車両５０を検出することで照射部１２が点灯し、また、照射部１２の点灯に伴って車両診断装置１０Ｃが車両５０を診断可能な状態となる。

車両診断装置１０Ｃの通信部３１は、車両５０と無線ｒ１で通信する通信モジュールである。無線ｒ１による通信方式は、前述のとおりである。

車両診断装置１０Ｃの制御部３５は、マイクロプロセッサ、メモリ３５ａ及びメモリ３５ａに格納されたプログラムなどによって構成される。メモリ３５ａには、車両ナンバーなどの車両５０の識別情報が保存されている。また、メモリ３５ａには、車両５０の運行ログ及び診断結果が記録される。

制御部３５は、例えば、検出部１３が車両５０を検出し、検出した情報を照明装置ＬＣから取得すると、通信部３１を介して車両５０の識別情報を要求する要求信号を車両５０へ発信する。そして、制御部３５は、車両５０から送信された車両５０の識別情報が、予め登録された識別情報と一致する場合に、車両５０の診断を行うように診断部３６に診断指令を出す。

なお、制御部３５は、上記要求信号を発信する代わりに、照射部１２から車両５０への可視光通信をトリガとして車両５０と通信し、車両５０の識別情報を取得してもよい。また、制御部３５は、車両ナンバーを検出部１３で撮像することで、車両５０の識別情報を取得してもよい。また、制御部３５は、検出部１３を用いる代わりに通信部３１を介して定期的にビーコン信号を発信し、車両５０に対して識別情報の返信要求をすることで、車両５０の識別情報を取得してもよい。すなわち制御部３５は、通信部３１を用いて車両５０を検出し、その後、通信部３１を介して診断を行ってもよい。

診断部３６は、通信部３１を介して車両５０がハッキングされているか否かを診断する回路である。診断部３６は、例えば、照射部１２の点灯状態が変化した場合に、駐車場９１に駐車されている車両５０に対して診断を行う。具体的には、診断部３６は、照射部１２が消灯から点灯に変化し、かつ、制御部３５からの診断指令を受け付けている場合に、ハッキング有無の診断を行う。

なお、診断部３６は、照射部１２が消灯から点灯に変化した場合に限られず、照射部１２が点灯から消灯又は減光状態に変化した場合あるいは点灯色が変化した場合に、診断を行ってもよい。また、診断部３６は、照射部１２が点灯から消灯又減光状態に変化した後あるいは点灯色が変化した後、再度点灯状態が変化した場合に、ハッキング有無の診断を終了してもよい。

診断部３６による車両診断については、３つの診断例がある。

１つ目の診断例は、車両診断装置１０Ｃから車両５０に対して行った質問に対する回答に基づいて、車両診断を行う例である。診断部３６は、車両５０に対して複数の質問を行い、質問に対する回答時間及び回答傾向の少なくとも一方に基づいて、車両５０がハッキングされているか否かを判断する。

２つ目の診断例は、車両５０に搭載された走行システムを動かすソフトウェアの強靭性を確認することで車両診断を行う例である。診断部３６は、通信部３１を介して車両５０のソフトウェアの強靭性を確認し、強靭性のレベルが予め決められたレベルよりも低い場合に、車両５０がハッキングされていると診断する。

３つ目の診断例は、車両５０の運行ログを取得し、運行ログに基づいて車両診断を行う例である。診断部３６は、通信部３１を介して車両５０の運行ログを取得し、車両５０が予め決められた運行規則を守っていないことを確認した場合に、車両５０がハッキングされていたと診断する。

診断部３６によって車両５０がハッキングされていると診断された場合、制御部３５は、照射部１２の照明光を用いて車両５０がハッキングされていることを報知する。例えば、照射部１２が液晶プロジェクタである場合、制御部３５は、照射部１２から照射される静止画又は動画を車両５０又は駐車場９１に照射して、ハッキングに関する情報を報知する。

これによれば、車両５０を使用するユーザが、車両５０がハッキングされているか否かを知ることができる。これにより、ユーザはハッキングされた車両５０に対策を施すことができ、車両５０のハッキングによる被害を抑制することができる。

なお、車両診断システム１Ｃは、診断結果を報知する他の例として、ネットワークを介して車両診断システム１Ｃに通信接続されているコンピュータに診断結果を報知してもよい（図２６参照）。例えば、車両診断システム１Ｃは、車両５０のディーラーが所有するコンピュータである管理サーバーに診断結果を送信してもよい。また、車両診断システム１Ｃは、オーナー又はディーラーが予め登録したメールアドレスに電子メールを送信することで、診断結果を報知してもよい。これにより、オーナー又はディーラーはハッキングされた車両５０に対策を施すことができ、車両５０のハッキングによる被害を抑制することができる。

（実施の形態５）
［５−１．車両診断システムの構成］
実施の形態５に係る車両診断システム１Ｄの構成について、図２７〜図２９を参照しながら説明する。実施の形態５では、車両診断装置１０Ｄが、一般公共用の駐車場９１に駐車された車両５０の診断を行う例について説明する。

図２７は、実施の形態５に係る車両診断システム１Ｄを示す概略図である。

図２７に示されるように、車両診断システム１Ｄは、駐車場９１の脇に設けられた車両診断装置１０Ｄと、車両診断装置１０Ｄと通信する情報端末７０とを備えている。情報端末７０は、車両５０のオーナーが所持する携帯端末である。図２７には、１つの車両診断装置１０Ｄが示されているが、車両診断システム１Ｄは複数の車両診断装置１０Ｄを備えていてもよい。

車両診断装置１０Ｄは、駐車場９１に照明光を照射する機能も備えている。車両診断装置１０Ｄは、例えば、屋外の街路灯、防犯灯などであってもよい。車両診断装置１０Ｄは、公園、集合住宅の敷地内又は工場の敷地内等の駐車場に設置されていてもよい。

車両診断装置１０Ｄは、駐車場９１の脇に設置される支柱体２３と、支柱体２３に設けられる灯体２２とを備える。支柱体２３は、柱状の部材であり、例えば、配電線が設けられた電柱、街路灯の柱、防犯カメラ取付用の柱である。支柱体２３は、Ｌ字状又はＴ字状の形状を有していてもよい。

図２８は、車両診断システム１Ｄの構成を示すブロック図である。図２９は、車両診断システム１Ｄの車両診断装置１０Ｄの概略図である。なお、図２８には、ネットワークを介して車両診断システム１Ｄと通信接続されるコンピュータも示されている。

図２８に示されるように、車両診断装置１０Ｄは、通信部１１と、照射部１２と、検出部１３と、制御部１５と、診断部１６とを備えている。

通信部１１は、無線ｒ１によって車両５０と通信し、無線ｒ２によって情報端末７０と通信する通信モジュールである。無線ｒ２による通信方式としては、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｚｉｇｂｅｅ（登録商標）、又は、ＷｉＦｉ（登録商標）などの通信方式が用いられる。なお、通信部１１は、図示しないインターネット等のネットワークを介して、情報端末７０と通信可能であってもよい。通信部１１は、例えば、診断部１６で得られた診断結果を、無線ｒ２を用いて情報端末７０に送信する。

図２９に示されるように、車両診断装置１０Ｄは、収容ケースである筐体２９を有している。通信部１１、照射部１２、検出部１３、制御部１５及び診断部１６は、筐体２９の内部又は筐体２９の外表面に設けられる。筐体２９は、例えば、リング状部材及び締結部材等によって支柱体２３に固定される。なお、通信部１１、照射部１２、検出部１３、制御部１５及び診断部１６は、筐体２９でなく、支柱体２３内に収納されていてもよいし、支柱体２３に形成された切り欠き又は穴に設けられていてもよい。

筐体２９は、支柱体２３の上側の位置、例えば、駐車場９１の路面から４．５ｍ以上１５ｍ以下の位置に設けられる。筐体２９は、例えば直方体状の形状であり、金属又は樹脂等の材料により形成されている。

照射部１２は、車両５０及び駐車場９１に照明光を照射する。照射部１２は、静止画又は動画を投影する液晶プロジェクタ、又は、白色光を発するＬＥＤ発光モジュールである。照射部１２は、ＲＧＢ、電球色や昼白色等の単体のＳＭＤ、ＣＯＢの組み合わせでもよい。照射部１２が液晶プロジェクタである場合、車両診断装置１０Ｄは、静止画又は動画を利用して車両５０に対してハッキングに関する情報を報知することができる。

検出部１３は、駐車場９１上の車両５０を検出するセンサである。検出部１３は、例えば、画像センサ、赤外線センサ又はレーザセンサである。検出部１３は、常時稼働することで、駐車場９１の所定区域における車両５０の有無を常時検出する。検出部１３で検出された情報は、制御部１５に出力される。

制御部１５は、通信部１１、照射部１２、検出部１３及び診断部１６の作動を制御する回路である。制御部１５は、マイクロプロセッサ、メモリ１５ａ及びメモリ１５ａに格納されたプログラムなどによって構成される。メモリ１５ａには、情報端末７０の識別情報が記憶されている。

制御部１５は、自動運転する車両５０を検出部１３が検出すると、診断部１６に対して、車両５０の診断を開始するように診断指令を出す。

なお、制御部１５は、検出部１３にて車両５０の自動運転の有無を検出する代わりに、照射部１２から車両５０への可視光通信をトリガとして車両５０と通信し、車両５０の自動運転の有無を判別する情報を取得してもよい。また制御部１５は、検出部１３にて車両５０の自動運転の有無を検出する代わりに、通信部１１を介して定期的にビーコン信号を発信し、駐車している車両５０に対して自動運転の有無を判別する情報を要求することで、車両５０の自動運転の有無を見分けてもよい。

診断部１６は、通信部１１を介して車両５０がハッキングされているか否かを診断する回路である。診断部１６は、例えば、照射部１２が消灯又は点灯状態であり、かつ、制御部１５からの診断指令を受け付けている場合に、ハッキング有無の診断を行う。

診断部１６による車両診断については、３つの診断例がある。

１つ目の診断例は、車両診断装置１０Ｄから車両５０に対して行った質問に対する回答に基づいて、車両診断を行う例である。診断部１６は、車両５０に対して複数の質問を行い、質問に対する回答時間及び回答傾向の少なくとも一方に基づいて、車両５０がハッキングされているか否かを判断する。

２つ目の診断例は、車両５０に搭載された走行システムを動かすソフトウェアの強靭性を確認することで車両診断を行う例である。診断部１６は、通信部１１を介して車両５０のソフトウェアの強靭性を確認し、強靭性のレベルが予め決められたレベルよりも低い場合に、車両５０がハッキングされていると診断する。

３つ目の診断例は、車両５０の運行ログを取得し、運行ログに基づいて車両診断を行う例である。診断部１６は、通信部１１を介して車両５０の運行ログを取得し、車両５０が予め決められた運行規則を守っていないことを確認した場合に、車両５０がハッキングされていたと診断する。

診断部１６によって車両５０がハッキングされていると診断された場合、制御部１５は、情報端末７０に対して車両５０がハッキングされていることを報知する。

情報端末７０は、例えば、スマートフォン、タブレット端末、ＰＣ（パーソナルコンピュータ）等の端末である。情報端末７０には、車両５０の診断結果に関する情報を閲覧するためのアプリケーションソフトがインストールされている。情報端末７０は、車両診断装置１０Ｄから無線ｒ２を使って診断結果に関する情報を取得し、この情報を画面に表示する。

情報端末７０から診断結果に関する情報を得たオーナーは、ハッキングされた車両５０に対してすみやかに対策を講じることができる。これにより、車両５０のハッキングによる被害を抑制することができる。

なお、車両診断システム１Ｄは、診断結果を報知する他の例として、ネットワークを介して車両診断システム１Ｄに通信接続されているコンピュータに診断結果を報知してもよい（図２８参照）。例えば、車両診断システム１Ｄは、車両５０のディーラーが所有するコンピュータである管理サーバーに診断結果を送信してもよい。また、車両診断システム１Ｄは、オーナー又はディーラーが予め登録したメールアドレスに電子メールを送信することで、診断結果を報知してもよい。これにより、オーナー又はディーラーはハッキングされた車両５０に対策を施すことができ、車両５０のハッキングによる被害を抑制することができる。

［５−２．車両診断システムの動作］
次に、実施の形態５に係る車両診断システム１Ｄの動作について説明する。

図３０は、車両診断システム１Ｄの動作の一例を示すフローチャートである。

まず、車両５０のオーナーが駐車場９１に車両５０を駐車する（ステップＳ４１）。

車両５０が駐車場９１に駐車された後、情報端末７０を所持するオーナーが、駐車場９１から所定の距離を超えて離れると（ステップＳ４２）、車両診断システム１Ｄは、車両５０の診断を開始する（ステップＳ４３）。所定の距離は、駐車場９１の出入口から駐車場９１とは異なる場所又は通路までの距離であり、例えば５ｍ以上または１０ｍ以上である。なお、オーナーが駐車場９１から所定の距離を超えて離れたか否かの情報は、車両診断システム１Ｄが、情報端末７０の位置情報を読み込むことで取得できる。

そして、オーナーが車両５０の駐車を終えようとして、駐車場９１に所定の距離以内近づくと（ステップＳ４４）、車両診断システム１Ｄは、車両５０の診断を終了する（ステップＳ４５）。車両診断を終了する際、車両診断システム１Ｄは、診断結果をメモリ１５ａに記録させる。この車両診断システム１Ｄによれば、駐車場９１にて駐車している機会に車両５０のハッキング有無を診断することができる。これにより、車両５０のハッキングによる被害を抑制することができる。

（実施の形態６）
実施の形態６に係る車両診断システム１Ｅの構成について、図３１及び図３２を参照しながら説明する。実施の形態６では、走行中、停車中又は駐車中の車両５０の診断を行う例について説明する。

図３１に示されるように、車両診断システム１Ｅは、道路９２及び駐車場９１の脇に設けられた複数の照明装置ＬＥと、インターネット等のネットワークＮを介して複数の照明装置ＬＥに通信接続される車両診断装置１０Ｅとを備えている。なお、図３１には、ネットワークＮを介して車両診断装置１０Ｅに通信接続される情報端末７０も示されている。

照明装置ＬＥは、道路９２及び駐車場９１に照明光を照射する装置であり、例えば、街路灯、防犯灯などの屋外の照明装置である。

照明装置ＬＥは、道路９２及び駐車場９１の脇に設置される支柱体２３と、支柱体２３に設けられる灯体２２とを備える。

支柱体２３は、柱状の部材であり、例えば、配電線が設けられた電柱、街路灯の柱、防犯カメラ取付用の柱である。支柱体２３は、Ｌ字状又はＴ字状の形状を有していてもよい。支柱体２３は、道路９２の端に沿って所定の間隔、例えば２０ｍ以上５０ｍ以下の間隔で複数配置されており、灯体２２も上記と同じ所定の間隔で複数配置されている。

図３２は、車両診断システム１Ｅの構成を示すブロック図である。なお、図３２には、ネットワークを介して車両診断システム１Ｅと通信接続されるコンピュータも示されている。

図３２に示されるように、照明装置ＬＥは、通信部１１と、照射部１２と、検出部１３と、制御部１５とを備えている。車両診断装置１０Ｅは、制御部３５と診断部３６とを備えている。

通信部１１は、無線ｒ１によって車両５０と通信し、有線によって車両診断装置１０Ｅと通信する通信モジュールである。通信部１１は、例えば、検出部１３で検出した情報を、ネットワークＮを介して車両診断装置１０Ｅに送信する。

灯体２２は、収容ケースである筐体２９を有している。通信部１１、照射部１２、検出部１３、制御部１５は、筐体２９の内部又は筐体２９の外表面に設けられる。筐体２９は、例えば、リング状部材及び締結部材等によって支柱体２３に固定される。なお、通信部１１、照射部１２、検出部１３及び制御部１５は、筐体２９でなく、支柱体２３内に収納されていてもよいし、支柱体２３に形成された切り欠き又は穴に設けられていてもよい。

筐体２９は、支柱体２３の上側の位置、例えば、道路９２の路面から４．５ｍ以上１５ｍ以下の位置に設けられる。筐体２９は、例えば直方体状の形状であり、支柱体２３から道路９２の中央側に突出するように、支柱体２３に設けられる。筐体２９は、金属又は樹脂等の材料により形成されている。

照射部１２は、道路９２、駐車場９１及び車両５０に照明光を照射する。照射部１２は、静止画又は動画を投影する液晶プロジェクタ、又は、白色光を発するＬＥＤ発光モジュールである。照射部１２は、ＲＧＢ、電球色や昼白色等の単体のＳＭＤ、ＣＯＢの組み合わせでもよい。照射部１２が液晶プロジェクタである場合、照明装置ＬＥは、静止画又は動画を利用して車両５０に対してハッキングに関する情報を報知することができる。

検出部１３は、道路９２及び駐車場９１の車両５０を検出するセンサである。検出部１３は、図３１に示されるように、道路９２に沿って設置された複数の支柱体２３及び駐車場９１に設置された支柱体２３のそれぞれに対応して設けられる。検出部１３は、例えば、画像センサ、赤外線センサ又はレーザセンサである。検出部１３は、常時稼働することで、道路９２及び駐車場９１の所定区域における車両５０の有無を常時検出する。検出部１３で検出された情報は、制御部１５及び通信部１１を介して車両診断装置１０Ｅに出力される。

照明装置ＬＥの制御部１５は、通信部１１、照射部１２、検出部１３の作動を制御する回路である。また、制御部１５は、マイクロプロセッサ、メモリ１５ａ及びメモリ１５ａに格納されたプログラムなどによって構成される。

車両診断装置１０Ｅの制御部３５は、マイクロプロセッサ、メモリ３５ａ及びメモリ３５ａに格納されたプログラムなどによって構成される。メモリ３５ａには、車両ナンバーなどの車両５０の識別情報が保存されている。また、メモリ３５ａには、車両５０の運行ログ及び診断結果が記録される。

制御部３５は、検出部１３が自動運転する車両５０を検出し、検出した情報をネットワークＮを介して受信すると、診断部３６に対して、車両５０の診断を開始するように診断指令を出す。

制御部３５は、検出部１３を用いて、車両５０が走行中であるか、停車中であるか又は駐車中であるかを判断してもよい。また、制御部３５は、車両５０に設けられた加速度センサ等を用いて、車両５０が走行中であるか、停車中であるか又は駐車中であるかを判断してもよい。

なお、制御部３５は、検出部１３にて車両５０の自動運転の有無を検出する代わりに、照射部１２から車両５０への可視光通信をトリガとして車両５０と通信し、車両５０から自動運転の有無を判別する情報を取得してもよい。また制御部３５は、検出部１３にて車両５０の自動運転の有無を検出する代わりに、通信部１１を介して定期的にビーコン信号を発信させ、走行及び駐車している車両５０に対して自動運転の有無を判別する情報を要求することで、車両５０の自動運転の有無を見分けてもよい。

診断部３６は、ネットワークＮ及び通信部１１を介して車両５０がハッキングされているか否かを診断する回路である。診断部３６は、例えば、制御部３５からの診断指令を受け付けている場合に、ネットワークＮ及び通信部１１を介して車両５０とデータの送受信を行い、送受信したデータに基づいてハッキング有無の診断を行う。診断部３６は、走行中の車両５０のハッキング有無を診断する際に、複数の照明装置ＬＥのうち車両５０と通信可能である照明装置ＬＥを順次切り替えて車両５０と通信し、上記診断を行ってもよい。

診断部３６による車両診断については、３つの診断例がある。

１つ目の診断例は、照明装置ＬＥから車両５０に対して行った質問に対する回答に基づいて、車両診断を行う例である。診断部３６は、照明装置ＬＥを介して車両５０に対して複数の質問を行い、質問に対する回答時間及び回答傾向の少なくとも一方に基づいて、車両５０がハッキングされているか否かを判断する。

２つ目の診断例は、車両５０に搭載された走行システムを動かすソフトウェアの強靭性を確認することで車両診断を行う例である。診断部３６は、照明装置ＬＥの通信部１１を介して車両５０のソフトウェアの強靭性を確認し、強靭性のレベルが予め決められたレベルよりも低い場合に、車両５０がハッキングされていると診断する。

３つ目の診断例は、車両５０の運行ログを取得し、運行ログに基づいて車両診断を行う例である。診断部３６は、照明装置ＬＥの通信部１１を介して車両５０の運行ログを取得し、車両５０が予め決められた運行規則を守っていないことを確認した場合に、車両５０がハッキングされていたと診断する。

診断部３６によって車両５０がハッキングされていると診断された場合、制御部３５は、情報端末７０に対して車両５０がハッキングされていることを報知する。

情報端末７０は、例えば、スマートフォン、タブレット端末、ＰＣ等の端末である。情報端末７０には、車両５０の診断結果に関する情報を閲覧するためのアプリケーションソフトがインストールされている。情報端末７０は、ネットワークＮを介して診断結果に関する情報を取得し、この情報を画面に表示する。

情報端末７０から診断結果に関する情報を得たオーナーは、ハッキングされた車両５０に対してすみやかに対策を講じることができる。これにより、車両５０のハッキングによる被害を抑制することができる。

なお、車両診断システム１Ｅは、診断結果を報知する他の例として、ネットワークＮを介して車両診断システム１Ｅに通信接続されているコンピュータに診断結果を報知してもよい（図３２参照）。例えば、車両診断システム１Ｅは、車両５０のディーラーが所有するコンピュータである管理サーバーに診断結果を送信してもよい。また、車両診断システム１Ｅは、オーナー又はディーラーが予め登録したメールアドレスに電子メールを送信することで、診断結果を報知してもよい。これにより、オーナー又はディーラーはハッキングされた車両５０に対策を施すことができ、車両５０のハッキングによる被害を抑制することができる。

図３３は、車両診断システム１Ｅの動作の一例を示す図である。図３３には、駐車中、停車中、走行中のそれぞれによって、車両５０と通信する際のデータ量及び通信タイミングを異ならせることが示されている。すなわち、車両診断システム１Ｅの診断部３６は、車両５０の駐車中と停車中と走行中とで、診断の時間及び診断の量の少なくとも一方を異ならせて、診断を行う。

例えば、診断部３６は、車両５０が駐車中であると判断した場合に、車両５０が走行中又は停車中であるときよりも診断の時間及び診断の量の少なくとも一方を増やして、診断を行ってもよい。また、診断部３６は、車両５０が停車中であると判断した場合に、車両５０が走行中であるときよりも診断の時間及び診断の量の少なくとも一方を増やして、かつ、車両５０が駐車中であるときよりも診断の時間及び診断の量の少なくとも一方を減らして、診断を行ってもよい。また、診断部３６は、車両５０が走行中であると判断した場合に、車両５０が停車中又は駐車中であるときよりも診断の時間及び診断の量の少なくとも一方を減らして、診断を行ってもよい。

例えば、車両５０が駐車中であるときは、診断の時間及び診断の量を多く確保することができるので、前述した３つの診断例のうち、車両に対する質疑応答、強靭性の確認及び運行ログによる診断が行われる。車両５０が停車中であるときは、駐車中に比べて診断の時間及び診断の量を減らさなければならないので、車両５０に対する質疑応答及び強靭性の確認のみによる診断が行われ、運行ログによる診断は行われない。車両５０が走行中であるときは、停車中に比べて診断の時間及び診断の量を減らさなければならないので、車両に対する質疑応答及び強靭性を確認するためのデータの送受信量又は送受信回数が、停車中に比べて減らされている。車両５０が駐車中であるときは、運行ログによる診断は行われない。

これによれば、車両５０の駐車中、停車中及び走行中のそれぞれにおいて、車両５０に対して適切な診断を行うことができる。

（実施の形態７）
実施の形態７に係る移動体診断装置１０Ｆの構成について、図３４及び図３５を参照しながら説明する。実施の形態７では、車両５０に限られず、無人航空機などの移動体８０を診断する例について説明する。

図３４は、実施の形態７に係る移動体診断装置１０Ｆの設置例を示す図である。

移動体診断装置１０Ｆは、移動体８０を待機させる待機所９６に設置され、移動体８０及び待機所９６に照明光を照射する。図３４では、移動体診断装置１０Ｆが建造物６０の一例である離発着場の外壁に設置されているが、それに限られず、移動体診断装置１０Ｆは、離発着場の屋根、塀、支柱等に設置されてもよい。

移動体８０は、自動運転が可能な無人航空機であり、例えばドローンなどの飛行体である。自動運転とは、自律的に移動体を運転することであり、例えば、運転者を必要としないで運転することはもちろん、運転者の操作を支援しながら運転することも含む。移動体８０は、手動運転のモードと自動運転のモードとを相互に切換えることができる飛行体であってもよい。移動体８０には、移動体診断装置１０Ｆと通信する通信アンテナ８１、及び、移動体診断装置１０Ｆの照明光を認識するカメラ８２が設けられている。移動体８０は、ＡＩアシスタント機能を有している。

図３５は、移動体診断装置１０Ｆの構成を示すブロック図である。なお、図３５には、ネットワークを介して移動体診断装置１０Ｆと通信接続されるコンピュータも示されている。

図３５に示されるように、移動体診断装置１０Ｆは、移動体８０と通信する通信部１１と、照明光を照射可能な照射部１２と、移動体８０を検出する検出部１３と、移動体８０の自動運転プログラムがハッキングされているか否かについて移動体８０を診断する診断部１６とを備えている。また、移動体診断装置１０Ｆは、照射部１２の点灯、消灯、調光及び調色を制御する制御部１５を備えている。

照射部１２は、照明光を照射する光源であり、例えば、静止画又は動画を投影する液晶プロジェクタ、又は、赤色、緑色、青色の光及びこれらの色の光が合成された光を発するＬＥＤ発光モジュールである。照射部１２は、ＲＧＢ、電球色や昼白色等の単体のＳＭＤ、ＣＯＢの組み合わせでもよい。照射部１２は、移動体８０及び移動体８０の周囲を照らすため、移動体８０が着陸している待機時の高さよりも高い位置に設けられる。

検出部１３は、待機所９６における移動体８０の有無を検出するセンサであり、例えば、画像センサ、赤外線センサ又はレーザセンサである。検出部１３は、常時稼働することで、待機所９６に移動体８０が待機しているか否かを検出する。本実施の形態では、検出部１３が移動体８０を検出することで照射部１２が点灯し、また、照射部１２の点灯に伴って診断部１６が移動体８０を診断可能な状態となる。

通信部１１は、移動体８０と無線ｒ１で通信する通信モジュールである。無線ｒ１による通信方式としては、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）、９２０ＭＨｚ帯の周波数を利用した特定小電力無線、Ｚｉｇｂｅｅ（登録商標）、又は、ＷｉＦｉ（登録商標）などの通信方式が用いられる。

制御部１５は、マイクロプロセッサ、メモリ１５ａ及びメモリ１５ａに格納されたプログラムなどによって構成される。メモリ１５ａには、移動体ナンバーなどの移動体８０の識別情報が保存されている。また、メモリ１５ａには、後述する移動体８０の運行ログ及び診断結果が記録される。制御部１５は、照射部１２の点灯等を制御するとともに、通信部１１、検出部１３及び診断部１６の作動を制御する。

制御部１５は、例えば、検出部１３が移動体８０を検出すると、通信部１１を介して移動体８０の識別情報を要求する要求信号を移動体８０へ発信する。そして、制御部１５は、移動体８０から送信された移動体８０の識別情報が、予め登録された識別情報と一致する場合に、移動体８０の診断を行うように診断部１６に診断指令を出す。

なお、制御部１５は、上記要求信号を発信する代わりに、照射部１２から移動体８０への可視光通信をトリガとして移動体８０と通信し、移動体８０の識別情報を取得してもよい。また、制御部１５は、移動体ナンバーを検出部１３で撮像することで、移動体８０の識別情報を取得してもよい。また、制御部１５は、検出部１３を用いる代わりに通信部１１を介して定期的にビーコン信号を発信し、移動体８０に対して識別情報の返信要求をすることで、移動体８０の識別情報を取得してもよい。すなわち制御部１５は、通信部１１を用いて移動体８０を検出し、その後、通信部１１を介して診断を行ってもよい。

診断部１６は、通信部１１を介して移動体８０がハッキングされているか否かを診断する回路である。診断部１６は、例えば、照射部１２の点灯状態が変化した場合に、待機所９６に待機している移動体８０に対して診断を行う。具体的には、診断部１６は、照射部１２が消灯から点灯に変化し、かつ、制御部１５からの診断指令を受け付けている場合に、ハッキング有無の診断を行う。

なお、診断部１６は、照射部１２が消灯から点灯に変化した場合に限られず、照射部１２が点灯から消灯又は減光状態に変化した場合あるいは点灯色が変化した場合に、ハッキング有無の診断を行ってもよい。また、診断部１６は、照射部１２が点灯から消灯又は減光状態に変化した後あるいは点灯色が変化した後、再度点灯状態が変化した場合に、ハッキング有無の診断を終了してもよい。なお、減光状態とは所定の明るさ以下となるように調光制御されている状態、例えば、１００％の照度のうち３０％の照度で点灯制御されている状態である。点灯色が変化するとは、色温度が変化するように調色制御された状態である。

診断部１６による移動体８０の診断については、前述した３つの診断例がある。

１つ目の診断例は、移動体診断装置１０Ｆから移動体８０に対して行った質問に対する回答に基づいて、移動体８０の診断を行う例である。診断部１６は、移動体８０に対して複数の質問を行い、質問に対する回答時間及び回答傾向の少なくとも一方に基づいて、移動体８０がハッキングされているか否かを判断する。

２つ目の診断例は、移動体８０に搭載された移動システム（飛行システム）を動かすソフトウェアの強靭性を確認することで移動体８０の診断を行う例である。診断部１６は、通信部１１を介して移動体８０のソフトウェアの強靭性を確認し、強靭性のレベルが予め決められたレベルよりも低い場合に、移動体８０がハッキングされていると診断する。

３つ目の診断例は、移動体８０の運行ログ（飛行記録）を取得し、運行ログに基づいて移動体８０の診断を行う例である。診断部１６は、通信部１１を介して移動体８０の運行ログを取得し、移動体８０が予め決められた運行規則を守っていないことを確認した場合に、移動体８０がハッキングされていたと診断する。

診断部１６によって移動体８０がハッキングされていると診断された場合、制御部１５は、照射部１２の照明光を用いて移動体８０がハッキングされていることを報知する。例えば、照射部１２が液晶プロジェクタである場合、制御部１５は、照射部１２から照射される静止画又は動画を移動体８０又は待機所９６に照射して、ハッキングに関する情報を報知する。

これによれば、移動体８０を使用するユーザが、移動体８０がハッキングされているか否かを視覚的に知ることができる。これにより、ユーザはハッキングされた移動体８０に対策を施すことができ、移動体８０のハッキングによる被害を抑制することができる。

なお、移動体診断装置１０Ｆは、診断結果を報知する他の例として、ネットワークを介して移動体診断装置１０Ｆに通信接続されているコンピュータに診断結果を報知してもよい（図３５参照）。例えば、移動体診断装置１０Ｆは、移動体８０の取り扱い業者が所有するコンピュータである管理サーバーに診断結果を送信してもよい。また、移動体診断装置１０Ｆは、オーナー又は取り扱い業者が予め登録したメールアドレスに電子メールを送信することで、診断結果を報知してもよい。これにより、オーナー又は取り扱い業者は、ハッキングされた移動体８０に対策を施すことができ、移動体８０のハッキングによる被害を抑制することができる。

（実施の形態８）
実施の形態８に係る移動体診断システム１Ｇの構成について、図３６及び図３７を参照しながら説明する。実施の形態８では、移動中、停止中又は待機中における移動体８０の診断を行う例について説明する。

図３６は、実施の形態８に係る移動体診断システム１Ｇを示す概略図である。図３６には、複数の移動体８０が、道路の上空を移動路９７として飛行している様子、及び、道路の外側に設けられた待機所９６に着陸している様子が示されている。

実施の形態８の移動体診断システム１Ｇは、複数の照明装置ＬＧと、インターネット等のネットワークＮを介して複数の照明装置ＬＧに通信接続される移動体診断装置１０Ｇとを備えている。なお、図３６には、ネットワークＮを介して移動体診断装置１０Ｇに通信接続される情報端末７０も示されている。

照明装置ＬＧは、移動体８０が移動する移動路９７に並行する道路９２及び移動体８０が待機する待機所９６に照明光を照射する装置であり、例えば、街路灯、防犯灯などの屋外の照明装置である。

照明装置ＬＧは、移動路９７から見下ろした道路９２及び待機所９６の脇に設置される支柱体２３と、支柱体２３に設けられる灯体２２とを備える。

支柱体２３は、柱状の部材であり、例えば、配電線が設けられた電柱、街路灯の柱、防犯カメラ取付用の柱である。支柱体２３は、Ｌ字状又はＴ字状の形状を有していてもよい。支柱体２３は、道路９２の端に沿って所定の間隔、例えば２０ｍ以上５０ｍ以下の間隔で複数配置されており、灯体２２も上記と同じ所定の間隔で複数配置されている。移動体８０は、複数の灯体２２から発せられる光を目印に、移動路９７を選択してもよい。

図３７は、移動体診断システム１Ｇの構成を示すブロック図である。なお、図３７には、ネットワークを介して移動体診断システム１Ｇと通信接続されるコンピュータも示されている。

図３７に示されるように、照明装置ＬＧは、通信部１１と、照射部１２と、検出部１３と、制御部１５とを備えている。移動体診断装置１０Ｇは、制御部３５と診断部３６とを備えている。

通信部１１は、無線ｒ１によって移動体８０と通信し、有線によって移動体診断装置１０Ｇと通信する通信モジュールである。通信部１１は、例えば、検出部１３で検出した情報を、ネットワークＮを介して移動体診断装置１０Ｇに送信する。

灯体２２は、収容ケースである筐体２９を有している。通信部１１、照射部１２、検出部１３、制御部１５は、筐体２９の内部又は筐体２９の外表面に設けられる。筐体２９は、例えば、リング状部材及び締結部材等によって支柱体２３に固定される。なお、通信部１１、照射部１２、検出部１３及び制御部１５は、筐体２９でなく、支柱体２３内に収納されていてもよいし、支柱体２３に形成された切り欠き又は穴に設けられていてもよい。

筐体２９は、支柱体２３の上側の位置であって、かつ、移動体８０の移動路９７よりも下側の位置に設けられる。筐体２９は、例えば直方体状の形状であり、支柱体２３から移動路９７の中央側に突出するように、支柱体２３に設けられる。筐体２９は、金属又は樹脂等の材料により形成されている。

照射部１２は、移動路９７に並行する道路９２、待機所９６及び移動体８０に照明光を照射する。照射部１２は、静止画又は動画を投影する液晶プロジェクタ、又は、白色光を発するＬＥＤ発光モジュールである。照射部１２は、ＲＧＢ、電球色や昼白色等の単体のＳＭＤ、ＣＯＢの組み合わせでもよい。照射部１２が液晶プロジェクタである場合、照明装置ＬＧは、静止画又は動画を利用して移動体８０に対してハッキングに関する情報を報知することができる。

検出部１３は、移動路９７及び待機所９６の移動体８０を検出するセンサである。検出部１３は、図３６に示されるように、移動路９７又は道路９２に沿って設置された複数の支柱体２３及び待機所９６に設置された支柱体２３のそれぞれに対応して設けられる。検出部１３は、例えば、画像センサ、赤外線センサ又はレーザセンサである。検出部１３は、常時稼働することで、移動路９７及び待機所９６の所定区域における移動体８０の有無を常時検出する。検出部１３で検出された情報は、制御部１５及び通信部１１を介して移動体診断装置１０Ｇに出力される。

照明装置ＬＧの制御部１５は、通信部１１、照射部１２、検出部１３の作動を制御する回路である。また、制御部１５は、マイクロプロセッサ、メモリ１５ａ及びメモリ１５ａに格納されたプログラムなどによって構成される。

移動体診断装置１０Ｇの制御部３５は、マイクロプロセッサ、メモリ３５ａ及びメモリ３５ａに格納されたプログラムなどによって構成される。メモリ３５ａには、移動体ナンバーなどの移動体８０の識別情報が保存されている。また、メモリ３５ａには、移動体８０の運行ログ及び診断結果が記録される。

制御部３５は、検出部１３が自動運転する移動体８０を検出し、検出した情報をネットワークＮを介して受信すると、診断部３６に対して、移動体８０の診断を開始するように診断指令を出す。

制御部３５は、検出部１３を用いて、移動体８０が移動中であるか、停止中であるか又は待機中であるかを判断してもよい。また、制御部３５は、移動体８０に設けられた加速度センサ等を用いて、移動体８０が移動中であるか、停止中であるか又は待機中であるかを判断してもよい。

なお、制御部３５は、検出部１３にて移動体８０の自動運転の有無を検出する代わりに、照射部１２から移動体８０への可視光通信をトリガとして移動体８０と通信し、移動体８０から自動運転の有無を判別する情報を取得してもよい。また制御部３５は、検出部１３にて移動体８０の自動運転の有無を検出する代わりに、通信部１１を介して定期的にビーコン信号を発信させ、移動及び待機している移動体８０に対して自動運転の有無を判別する情報を要求することで、移動体８０の自動運転の有無を見分けてもよい。

診断部３６は、ネットワークＮ及び通信部１１を介して移動体８０がハッキングされているか否かを診断する回路である。診断部３６は、例えば、制御部３５からの診断指令を受け付けている場合に、ネットワークＮ及び通信部１１を介して移動体８０とデータの送受信を行い、送受信したデータに基づいてハッキング有無の診断を行う。診断部３６は、移動中の移動体８０のハッキング有無を診断する際に、複数の照明装置ＬＧのうち移動体８０と通信可能である照明装置ＬＧを順次切り替えて移動体８０と通信し、上記診断を行ってもよい。

診断部３６による移動体８０の診断については、前述した３つの診断例がある。

１つ目の診断例は、照明装置ＬＧから移動体８０に対して行った質問に対する回答に基づいて、移動体８０の診断を行う例である。診断部３６は、照明装置ＬＧを介して移動体８０に対して複数の質問を行い、質問に対する回答時間及び回答傾向の少なくとも一方に基づいて、移動体８０がハッキングされているか否かを判断する。

２つ目の診断例は、移動体８０に搭載された移動システムを動かすソフトウェアの強靭性を確認することで移動体８０の診断を行う例である。診断部３６は、照明装置ＬＧの通信部１１を介して移動体８０のソフトウェアの強靭性を確認し、強靭性のレベルが予め決められたレベルよりも低い場合に、移動体８０がハッキングされていると診断する。

３つ目の診断例は、移動体８０の運行ログ（飛行記録）を取得し、運行ログに基づいて移動体８０の診断を行う例である。診断部３６は、照明装置ＬＧの通信部１１を介して移動体８０の運行ログを取得し、移動体８０が予め決められた運行規則を守っていないことを確認した場合に、移動体８０がハッキングされていたと診断する。

診断部３６によって移動体８０がハッキングされていると診断された場合、制御部３５は、情報端末７０に対して移動体８０がハッキングされていることを報知する。

情報端末７０は、例えば、スマートフォン、タブレット端末、ＰＣ等の端末である。情報端末７０には、移動体８０の診断結果に関する情報を閲覧するためのアプリケーションソフトがインストールされている。情報端末７０は、ネットワークＮを介して診断結果に関する情報を取得し、この情報を画面に表示する。

情報端末７０から診断結果に関する情報を得たオーナーは、ハッキングされた移動体８０に対してすみやかに対策を講じることができる。これにより、移動体８０のハッキングによる被害を抑制することができる。

なお、移動体診断システム１Ｇは、診断結果を報知する他の例として、ネットワークＮを介して移動体診断システム１Ｇに通信接続されているコンピュータに診断結果を報知してもよい（３７参照）。例えば、移動体診断システム１Ｇは、移動体８０の取り扱い業者が所有するコンピュータである管理サーバーに診断結果を送信してもよい。また、移動体診断システム１Ｇは、オーナー又は取り扱い業者が予め登録したメールアドレスに電子メールを送信することで、診断結果を報知してもよい。これにより、オーナー又は取り扱い業者は、ハッキングされた移動体８０に対策を施すことができ、移動体８０のハッキングによる被害を抑制することができる。

（まとめ）
上述したように、本実施の形態に係る車両診断装置１０は、自動運転する車両５０と通信する通信部１１と、通信部１１を介して車両５０がハッキングされているか否かを診断する診断部１６とを備える。診断部１６は、車両５０に対して行った質問に対する回答に基づいて、上記診断を行う。

これによれば、診断部１６が、上記回答に基づいて、車両５０がハッキングされているか否かを診断することができる。これにより、車両５０のハッキングによる被害を抑制することができる。

また、診断部１６は、複数の質問に対する回答時間及び回答傾向の少なくとも一方に基づいて、上記診断を行ってもよい。

これによれば、車両５０がハッキングされているか否かを的確に診断することができる。これにより、車両５０のハッキングによる被害を抑制することができる。

また、診断部１６は、通信部１１を介して、車両５０に一義的に回答が決まる質問を行い、質問に対する回答時間が予め決められた時間よりも遅い場合に、車両５０がハッキングされていると診断してもよい。

これによれば、車両５０がハッキングされているか否かを簡易に診断することができる。これにより、車両５０のハッキングによる被害を抑制することができる。

また、 診断部１６は、通信部１１を介して、車両５０に一義的に回答が決まらない複数の質問を行い、複数の質問に対する回答のぶれ幅が予め決められたぶれ幅よりも小さい場合に、車両５０がハッキングされていると診断してもよい。

これによれば、車両５０がハッキングされているか否かを高度な視点で診断することができる。これにより、車両５０のハッキングによる被害を抑制することができる。

また、診断部１６は、さらに、通信部１１を介して車両５０の運行ログを取得し、運行ログに基づいて、上記診断を行ってもよい。

これによれば、運行ログを用いて十分な診断を行うことができる。これにより、車両５０のハッキングによる被害を抑制することができる。

また、診断部１６は、運行ログに基づいて、車両５０が予め決められた運行規則を守っていないことを確認した場合に、車両５０がハッキングされていたと診断してもよい。

このように、運行規則を守っていないことを確認することで、十分な診断を行うことができる。これにより、車両５０のハッキングによる被害を抑制することができる。

また、診断部１６は、車両５０の駐車中と停車中と走行中とで、診断の時間及び診断の量の少なくとも一方を異ならせて、上記診断を行ってもよい。

これによれば、駐車、停車、走行などの車両５０がおかれている状態に合わせた適切な診断を行うことができる。これにより、車両５０のハッキングによる被害を抑制することができる。

また、診断部１６は、車両５０が駐車中であると判断した場合に、車両５０が走行中又は停車中であるときよりも診断の時間及び診断の量の少なくとも一方を増やして、上記診断を行ってもよい。

これによれば、駐車中である車両５０に対して十分な診断を行うことができる。これにより、車両５０のハッキングによる被害を抑制することができる。

また、診断部１６は、車両５０が停車中であると判断した場合に、車両５０が走行中であるときよりも診断の時間及び診断の量の少なくとも一方を増やして、かつ、車両５０が駐車中であるときよりも診断の時間及び診断の量の少なくとも一方を減らして、上記診断を行ってもよい。

これによれば、停車中である車両５０に対して適切な診断を行うことができる。これにより、車両５０のハッキングによる被害を抑制することができる。

また、診断部１６は、車両５０が走行中であると判断した場合に、車両５０が停車中又は駐車中であるときよりも診断の時間及び診断の量の少なくとも一方を減らして、上記診断を行ってもよい。

これによれば、車両５０が走行中であってもそれに合わせた適切な診断を行うことができる。これにより、車両５０のハッキングによる被害を抑制することができる。

本実施の形態に係る車両診断システム１Ｄは、上記車両診断装置と、車両診断装置と通信する情報端末７０とを備える。

これによれば、車両５０がハッキングされているか否かの情報を情報端末７０に送信することができる。これにより、上記情報を得たユーザは、ハッキングされた車両５０に対してすみやかに対策を講じることができる。これにより、車両５０のハッキングによる被害を抑制することができる。

本実施の形態に係る車両診断システム１Ｅは、自動運転する車両５０と通信する通信部１１、ならびに、車両５０、車両５０が走行する道路９２及び車両５０が駐車する駐車場９１の少なくとも一つに照明光を照射する照射部１２を有する照明装置ＬＥと、通信部１１に通信接続され、通信部１１を介して車両５０がハッキングされているか否かを診断する診断部３６を有する車両診断装置１０Ｅとを備える。診断部３６は、車両５０に対して行った質問に対する回答に基づいて、上記診断を行う。

これによれば、車両５０が道路９２を走行中であっても、また、駐車場９１に駐車中であっても、車両５０がハッキングされているか否かの診断を行うことができる。これにより、車両５０のハッキングによる被害を抑制することができる。

本実施の形態に係る車両診断システム１Ｃは、自動運転する車両５０、車両５０が走行する道路９２及び車両５０が駐車する駐車場９１の少なくとも一つに照明光を照射する照明装置ＬＣと、照明装置ＬＣ及び車両５０と通信する通信部３１、ならびに、通信部３１を介して車両５０がハッキングされているか否かを診断する診断部３６を有する車両診断装置１０Ｃとを備える。診断部３６は、車両５０に対して行った質問に対する回答に基づいて、上記診断を行う。

この車両診断システム１Ｃにおいても、車両５０がハッキングされているか否かの診断を適切に行うことができる。これにより、車両５０のハッキングによる被害を抑制することができる。

本実施の形態に係る移動体診断装置１０Ｆは、自動運転する移動体８０と通信する通信部１１と、通信部１１を介して移動体８０がハッキングされているか否かを診断する診断部１６とを備える。診断部１６は、移動体８０に対して行った質問に対する回答に基づいて、上記診断を行う。

この移動体診断装置１０Ｆによれば、移動体８０がハッキングされているか否かを診断することができるので、移動体８０のハッキングによる被害を抑制することができる。

また、移動体８０は無人航空機であってもよい。

これによれば、無人航空機がハッキングされているか否かを診断することができるので、無人航空機のハッキングによる被害を抑制することができる。

また、診断部１６は、通信部１１を介して、移動体８０の移動システムを動かすソフトウェアの脆弱性を確認することで、上記診断を行ってもよい。また、診断部１６は、通信部１１を介して移動体８０の運行ログを取得し、運行ログに基づいて、上記診断を行ってもよい。

また、本実施の形態に係る移動体診断システム１Ｇは、自動運転する移動体８０と通信する通信部１１、ならびに、移動体８０、移動体８０が移動する移動路９７及び移動体８０が待機する待機所９６の少なくとも一つに照明光を照射する照射部１２を有する照明装置ＬＧと、通信部１１に通信接続され、通信部１１を介して移動体８０がハッキングされているか否かを診断する移動体診断装置１０Ｇとを備える。

これによれば、移動体８０が移動路９７を移動中であっても、また、待機所９６に待機中であっても、移動体８０がハッキングされているか否かの診断を行うことができる。これにより、移動体８０のハッキングによる被害を抑制することができる。

（その他の実施の形態）
以上、本開示について、実施の形態１〜８に基づいて説明したが、本開示は、上記の車両診断装置及び移動体診断装置に限定されるものではない。

上記実施の形態１〜８では、照射部１２の点灯に変化があった場合に、診断部１６、３６が車両５０等を診断しているが、それに限られない。例えば、診断部１６、３６は、照射部１２の点灯に変化がなくても検出部１３が車両５０等を検出した場合に、診断を行ってもよい。

上記実施の形態１〜８の診断部１６、３６は、一義的に回答が決まる質問を行って車両５０等の診断を行う場合に、図３に示された質問の回答として、回答の間違い、つづりの違い、言語の違い等があるときに、車両５０等がハッキングされていると診断してもよい。

また、上記の実施の形態では、車両５０等がハッキングされているか否かを診断する診断部１６を備える車両診断装置について説明したが、上記実施の形態は、車両５０等に対する他の診断にも適用することができる。

例えば、車両診断装置は、自動運転する車両５０と通信する通信部１１と、通信部１１を介して車両５０がゾンビ化しているか否かを診断する診断部１６と、車両５０、車両５０が走行する道路９２及び車両５０が駐車する駐車場９１の少なくとも一つに照明光を照射可能な照射部１２とを備えていてもよい。ここで、車両５０がゾンビ化しているとは、車両５０がハッキングされている状態、及び、車両５０がコンピュータウィルスに感染している状態の少なくとも一方の状態を含む意味である。車両５０がコンピュータウィルスに感染しているか否かは、例えば、車両５０を走行させるためのコンピュータプログラムが正常に動いているか否かを検出することで診断できる。

上記実施の形態１〜８に係る車両診断装置及び移動体診断装置の動作は、メモリ１５ａに記憶されたプログラムによって実現されてもよい。すなわちプログラムとして、車両５０に照明光を照射する照射部１２の点灯状態を変化させるステップと、上記ステップの後に、通信部１１を用いて車両５０と通信し、車両５０がハッキングされているか否かを診断するステップと、を含むプログラムがメモリ１５ａに記憶され、車両診断装置及び移動体診断装置の動作は、このメモリ１５ａに記憶されたプログラムによって実現されてもよい。

また、上記実施の形態１〜８に係る各制御部は、典型的に集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又は全てを含むように１チップ化されてもよい。

また、集積回路化はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後にプログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）、又はＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。

なお、上記各実施の形態１〜８において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵ又はプロセッサなどのプログラム実行部が、ハードディスク又は半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。

また、上記で用いた数字は、全て本開示を具体的に説明するために例示するものであり、本開示の実施の形態は例示された数字に制限されない。

また、ブロック図における機能ブロックの分割は一例であり、複数の機能ブロックを一つの機能ブロックとして実現したり、一つの機能ブロックを複数に分割したり、一部の機能を他の機能ブロックに移してもよい。また、類似する機能を有する複数の機能ブロックの機能を単一のハードウェア又はソフトウェアが並列又は時分割に処理してもよい。

また、フローチャートにおける各ステップが実行される順序は、本開示を具体的に説明するために例示するためであり、上記以外の順序であってもよい。また、上記ステップの一部が、他のステップと同時（並列）に実行されてもよい。

その他、実施の形態１〜８に対して当業者が思いつく各種変形を施して得られる形態、本開示の趣旨を逸脱しない範囲で実施の形態１〜８における構成要素及び機能を任意に組み合わせることで実現される形態も本開示に含まれる。

１、１Ａ、１Ｂ、１Ｃ、１Ｄ、１Ｅ 車両診断システム
１Ｇ 移動体診断システム
１０、１０Ａ、１０Ｂ、１０Ｃ、１０Ｄ、１０Ｅ 車両診断装置
１０Ｆ、１０Ｇ 移動体診断装置
１１、３１、３２ 通信部
１２ 照射部
１３ 検出部
１６、３６ 診断部
５０ 車両
７０ 情報端末
８０ 移動体
９１ 駐車場
９２ 道路
９６ 待機所
９７ 移動路
ＬＣ、ＬＥ、ＬＧ 照明装置

Claims (15)

1. 自動運転する車両と通信する通信部と、
   前記通信部を介して前記車両がハッキングされているか否かを診断する診断部と
   を備え、
   前記診断部は、前記車両に対して行った質問に対する回答に基づいて、前記診断を行う
   車両診断装置。
2. 前記診断部は、複数の前記質問に対する回答時間及び回答傾向の少なくとも一方に基づいて、前記診断を行う
   請求項１に記載の車両診断装置。
3. 前記診断部は、前記通信部を介して、前記車両に一義的に回答が決まる前記質問を行い、前記質問に対する回答時間が予め決められた時間よりも遅い場合に、前記車両がハッキングされていると診断する
   請求項２に記載の車両診断装置。
4. 前記診断部は、前記通信部を介して前記車両に一義的に回答が決まらない複数の前記質問を行い、複数の前記質問に対する回答のぶれ幅が予め決められたぶれ幅よりも小さい場合に、前記車両がハッキングされていると診断する
   請求項２又は３に記載の車両診断装置。
5. 前記診断部は、さらに、前記通信部を介して前記車両の運行ログを取得し、前記運行ログに基づいて、前記診断を行う
   請求項１〜４のいずれか１項に記載の車両診断装置。
6. 前記診断部は、前記運行ログに基づいて、前記車両が予め決められた運行規則を守っていないことを確認した場合に、前記車両がハッキングされていたと診断する
   請求項５に記載の車両診断装置。
7. 前記診断部は、前記車両の駐車中と停車中と走行中とで、診断の時間及び診断の量の少なくとも一方を異ならせて、前記診断を行う
   請求項１〜６のいずれか１項に記載の車両診断装置。
8. 前記診断部は、前記車両が駐車中であると判断した場合に、前記車両が走行中又は停車中であるときよりも前記診断の時間及び前記診断の量の少なくとも一方を増やして、前記診断を行う
   請求項７に記載の車両診断装置。
9. 前記診断部は、前記車両が停車中であると判断した場合に、前記車両が走行中であるときよりも前記診断の時間及び前記診断の量の少なくとも一方を増やして、かつ、前記車両が駐車中であるときよりも前記診断の時間及び前記診断の量の少なくとも一方を減らして、前記診断を行う
   請求項７に記載の車両診断装置。
10. 前記診断部は、前記車両が走行中であると判断した場合に、前記車両が停車中又は駐車中であるときよりも前記診断の時間及び前記診断の量の少なくとも一方を減らして、前記診断を行う
    請求項７に記載の車両診断装置。
11. 請求項１〜１０のいずれか１項に記載の車両診断装置と、
    前記車両診断装置と通信する情報端末と
    を備える車両診断システム。
12. 自動運転する車両と通信する通信部、ならびに、前記車両、前記車両が走行する道路及び前記車両が駐車する駐車場の少なくとも一つに照明光を照射可能な照射部を有する照明装置と、
    前記通信部に通信接続され、前記通信部を介して前記車両がハッキングされているか否かを診断する診断部を有する車両診断装置と
    を備え、
    前記診断部は、前記車両に対して行った質問に対する回答に基づいて、前記診断を行う
    車両診断システム。
13. 自動運転する車両、前記車両が走行する道路及び前記車両が駐車する駐車場の少なくとも一つに照明光を照射可能な照明装置と、
    前記照明装置及び前記車両と通信する通信部、ならびに、前記通信部を介して前記車両がハッキングされているか否かを診断する診断部を有する車両診断装置と
    を備え、
    前記診断部は、前記車両に対して行った質問に対する回答に基づいて、前記診断を行う
    車両診断システム。
14. 自動運転する移動体と通信する通信部と、
    前記通信部を介して前記移動体がハッキングされているか否かを診断する診断部と
    を備え、
    前記診断部は、前記移動体に対して行った質問に対する回答に基づいて、前記診断を行う
    移動体診断装置。
15. 前記移動体は、無人航空機である
    請求項１４に記載の移動体診断装置。

Images