本実施の形態に係る車両診断装置は、自動運転する車両が第三者にハッキングされているか否かを診断する診断機能を備える。車両診断装置が上記診断機能を備えることで、車両のハッキングによる被害を抑制することが可能となる。なお本実施の形態において、ハッキングとは、他人のコンピュータに不正に侵入して予期しない動作をさせる、あるいは正常な動作をさせないことを意味する。
以下、実施の形態について、図面を参照しながら具体的に説明する。なお、以下で説明する実施の形態は、いずれも本開示の一具体例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本開示を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、本開示の一形態に係る実現形態を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。本開示の実現形態は、現行の独立請求項に限定されるものではなく、他の独立請求項によっても表現され得る。
なお、各図は模式図であり、必ずしも厳密に図示されたものではない。また、各図において、実質的に同一の構成に対しては同一の符号を付しており、重複する説明は省略又は簡略化される場合がある。
(実施の形態1)
[1-1.車両診断装置の構成]
実施の形態1に係る車両診断装置10の構成について、図1~図6を参照しながら説明する。
図1は、実施の形態1に係る車両診断装置10の設置例を示す図である。
車両診断装置10は、車両50を駐車する駐車場91に設置される。図1では、車両診断装置10が建造物60の一例である住宅の外壁に設置されているが、それに限られず、車両診断装置10は、住宅の屋根、塀、支柱等に設置されてもよい。
車両50は、自動運転が可能な車両であり、例えば、自動車、自動二輪車等である。自動運転とは、自律的に自動車を運転することであり、例えば、運転者を必要としないで運転することはもちろん、運転者のハンドル操作やブレーキ操作を支援しながら運転することも含む。車両50は、手動運転のモードと自動運転のモードとを相互に切換えることができる車両であってもよい。車両50には、車両診断装置10と通信する通信アンテナ51、及び、車両診断装置10から照射される照明光を認識するカメラ52が設けられている。車両50は、AIアシスタント機能(ソフトウェアエージェント)を有している。なお、車両50は、後述する移動体の一例である。
図2は、車両診断装置10の構成を示すブロック図である。なお、図2には、ネットワークを介して車両診断装置10と通信接続されるコンピュータも示されている。
図2に示されるように、車両診断装置10は、車両50と通信する通信部11と、照明光を照射可能な照射部12と、車両50を検出する検出部13と、車両50の自動運転プログラムがハッキングされているか否かについて車両50を診断する診断部16とを備えている。また、車両診断装置10は、照射部12の点灯、消灯、調光及び調色を制御する制御部15を備えている。
照射部12は、照明光を照射する光源であり、例えば、静止画又は動画を投影する液晶プロジェクタ、又は、赤色、緑色、青色の光及びこれらの色の光が合成された光を発するLED(Light Emitting Diode)発光モジュールである。照射部12は、RGB、電球色(2700K)や昼白色(5000K)等の単体のSMD(Surface Mount Device)、COB(Chip On Board)の組み合わせでもよい。照射部12は、車両50及び車両50の周囲を照らすため、車両50の車高よりも高い位置に設けられる。
検出部13は、駐車場91における車両50の有無を検出するセンサであり、例えば、画像センサ、赤外線センサ又はレーザセンサである。検出部13は、常時稼働することで、駐車場91に車両50が駐車されているか否かを検出する。本実施の形態では、検出部13が車両50を検出することで照射部12が点灯し、また、照射部12の点灯に伴って診断部16が車両50を診断可能な状態となる。
通信部11は、車両50と無線r1で通信する通信モジュールである。無線r1による通信方式としては、例えば、Bluetooth(登録商標)、920MHz帯の周波数を利用した特定小電力無線、Zigbee(登録商標)、又は、WiFi(登録商標)などの通信方式が用いられる。
制御部15は、マイクロプロセッサ、メモリ15a及びメモリ15aに格納されたプログラムなどによって構成される。メモリ15aには、車両ナンバーなどの車両50の識別情報が保存されている。また、メモリ15aには、後述する車両50の運行ログ及び診断結果が記録される。制御部15は、照射部12の点灯等を制御するとともに、通信部11、検出部13及び診断部16の作動を制御する。
制御部15は、例えば、検出部13が車両50を検出すると、通信部11を介して車両50の識別情報を要求する要求信号を車両50へ発信する。そして、制御部15は、車両50から送信された車両50の識別情報が、予め登録された識別情報と一致する場合に、車両50の診断を行うように診断部16に診断指令を出す。
なお、制御部15は、上記要求信号を発信する代わりに、照射部12から車両50への可視光通信をトリガとして車両50と通信し、車両50の識別情報を取得してもよい。その場合に車両50は、可視光通信の信号受信部であるカメラ52を介して可視光通信により送信された情報を解読し、車両診断装置10に対して車両50の識別情報を返信してもよい。また、制御部15は、車両ナンバーを検出部13で撮像することで、車両50の識別情報を取得してもよい。また、制御部15は、検出部13を用いる代わりに通信部11を介して定期的にビーコン信号を発信し、車両50に対して識別情報の返信要求をすることで、車両50の識別情報を取得してもよい。すなわち制御部15は、通信部11を用いて車両50を検出し、その後、通信部11を介して診断を行ってもよい。
診断部16は、通信部11を介して車両50がハッキングされているか否かを診断する回路である。診断部16は、例えば、照射部12の点灯状態が変化した場合に、駐車場91に駐車されている車両50に対して診断を行う。具体的には、診断部16は、照射部12が消灯から点灯に変化し、かつ、制御部15からの診断指令を受け付けている場合に、ハッキング有無の診断を行う。
なお、診断部16は、照射部12が消灯から点灯に変化した場合に限られず、照射部12が点灯から消灯又は減光状態に変化した場合あるいは点灯色が変化した場合に、ハッキング有無の診断を行ってもよい。また、診断部16は、照射部12が点灯から消灯又は減光状態に変化した後あるいは点灯色が変化した後、再度点灯状態が変化した場合に、ハッキング有無の診断を終了してもよい。なお、減光状態とは所定の明るさ以下となるように調光制御されている状態、例えば、100%の照度のうち30%の照度で点灯制御されている状態である。点灯色が変化するとは、色温度が変化するように調色制御された状態である。
ここで、診断部16による車両診断について、3つの診断例を挙げながら説明する。
1つ目の診断例は、車両診断装置10から車両50に対して行った質問に対する回答に基づいて、車両診断を行う例である。診断部16は、車両50に対して複数の質問を行い、質問に対する回答時間及び回答傾向の少なくとも一方に基づいて、車両50がハッキングされているか否かを判断する。
図3Aは、車両診断装置10の診断部16から車両50に対して行う質問の一例を示す図である。
例えば、診断部16は、通信部11を介して車両50に一義的に回答が決まる質問を行い、質問に対する回答時間が予め決められた時間よりも遅い場合に、車両50がハッキングされていると診断する。
一義的に回答が決まる質問とは、例えば、車両50の乗車人数、車両50の目的地、車両50のオーナー(持ち主)席のシート位置、車内と車外との温度差、ブレーキ操作の有無に関する問いである。車両50の乗車人数は、車両50のカメラ52によって取得できる。車両50の目的地は、カーナビゲーションによって取得できる。車内と車外との温度差は、温度センサによって取得できる。オーナー席のシート位置は、オーナーが車両50に事前に登録したシート位置によって取得できる。ブレーキ操作の有無は、車両50のECU(Electronic Control Unit)によって取得できる。
上記の乗車人数、目的地、シート位置、温度差、ブレーキ操作の有無は、車両50にとって瞬時に取得できるので、正常な車両50であれば質問に対する回答を短時間で行うことができる。そこで診断部16は、質問に対する回答時間が予め決められた時間よりも遅い場合に、車両50がハッキングされていると判断し、回答時間が予め決められた時間内である場合に、車両50がハッキングされていないと判断する。なお、一義的に回答が決まる質問及びその回答には、車両継続検査(車検)の検査内容であるハンドル操作指示、ブレーキ操作指示、及び、これらの操作指示に対する応答結果が含まれていてもよい。
また、例えば、診断部16は、通信部11を介して車両50に一義的に回答が決まらない複数の質問を行い、複数の質問に対する回答のぶれ幅が予め決められたぶれ幅よりも小さい場合に、車両50がハッキングされていると判断する。回答のぶれ幅とは、同類の複数の質問に対する複数の回答のばらつきの大きさである。
一義的に回答が決まらない質問とは、例えば、オーナーの気分・機嫌、運行ルートの決定基準、オーナーの車両50に対する満足度、オーナーの幸福度、車両50の周辺地域における気象状況などに関する問いである。オーナーの気分・機嫌は、オーナーの言動を車内のマイク及びカメラ52で検出することで取得できる。運行ルートの決定基準は、予め登録されたオーナー好みの運行ルートから取得できる。オーナーの車両50に対する満足度は、オーナーの車両50に対する接し方、扱い方をマイク及びカメラ52で検出することで取得できる。オーナーの幸福度は、オーナーの顔の表情をカメラ52で検出することで取得できる。車両50の周辺地域における気象状況は、カメラ52、車両50に設けられた気象センサにより取得できる。
例えば、オーナーの幸福度は、オーナーの無意識下における幸福度であり、オーナー自身も気づかない第三者の視点から見た幸福度である。この幸福度は、自動運転又は手動運転時における会話、独り言や言葉の語尾、声色を車両50内のカメラ又はマイクで検出し、検出結果をAI(Artificial Intelligence)を用いて処理することで導出できる。なお、オーナーの幸福度は、オーナーに対する直接の問いかけによって取得してもよいし、運転後の一言アンケート等で調査することによって取得してもよい。
上記のオーナーの気分・機嫌、運行ルートの決定基準、満足度、幸福度、気象状況は、天気、道路混雑状況、物価指数、仕事の進捗、対人関係などによって変わるものであり、正常な車両50であれば、回答にぶれ幅が生じる。一方、車両50が第三者にハッキングされている場合は、回答のぶれ幅が小さく、又は、決まりきった回答しか得られないことが多い。そこで診断部16は、複数の質問に対する回答のぶれ幅が予め決められたぶれ幅以上である場合に、車両50がハッキングされていないと診断し、回答のぶれ幅が予め決められたぶれ幅よりも小さい場合に、車両50がハッキングされていると判断する。
このように、車両診断装置10から車両50に対して質疑応答を行うことで、車両50がハッキングされているか否かを診断することができる。
ここで、車両50がオーナーの幸福度を判断する場面について説明する。幸福度は、例えば平常状態、リラックス状態、緊張状態、疲労状態、ご機嫌状態など各種の状態となってオーナーに表れる。オーナーがどのような状態にあるかは、車両50が、オーナーの言動、例えば声色、発言、声の大きさ、舌打ち又は鼻歌などを検出することで把握することができる。
図3Bは、車両50に乗車中のオーナーに表れる状態の一例を示す図である。なお、図3B及び後述する図3C、図3Dにおける矢印は、上向きだと気持ちが高揚するなどしてポジティブな気分に変化すること、下向きだと気持ちが抑鬱するなどしてネガティブな気分に変化すること、真横向きだと気持ちに浮き沈みがないことを示している。
図3Bの(a)には、自宅の近くではオーナーが手動運転し、その後しばらくは車両50が自動運転し、会社の近くになるとオーナーが再び手動運転する例が示されている。図3Bの(b)には、会社の近くではオーナーが手動運転し、その後しばらくは車両50が自動運転し、自宅の近くになるとオーナーが再び手動運転する例が示されている。
図3Bの(a)に示すように、出社するときのオーナーは、車両50が自動運転になるとリラックス状態になり、会社に近づくにつれて緊張状態に変わる。一方、図3Bの(b)に示すように、帰宅するときのオーナーは、最初は疲労状態にあるが、時間が経過するにつれて平常状態に戻り、その後、リラックス状態に変わる。上記はあくまでの一例であるが、例えば車両50が、オーナーを日々定点観測し、オーナーに表れる状態をデータ化して蓄積することで、時と場所によって変化するオーナーの幸福度を判断することが可能となる。
図3Cは、車両50に乗車中のオーナーに表れる状態の他の一例を示す図である。図3Cの上段には、休日に自動運転する例が示され、図3Cの下段には、休日に手動運転する例が示されている。
図3Cの上段に示すように、自動運転する車両50に乗車するオーナーは、目的地に向かうときに家族等と会話をすることによってご機嫌状態となり、自宅に帰るときは、疲労もそれほど残らず平常状態を維持する。一方、図3Cの下段に示すように、手動運転する車両50に乗車するオーナーは、運転に注力するため家族等と会話する時間が短くなり、また、自宅に帰るときは疲労状態となる。このように手動運転では、運転のために気力及び体力注ぐこととなるが、自動運転では自身の運転を鑑みる必要がなく、全力で家族サービスを行うことができる。上記はあくまでも一例であるが、例えば車両50が、オーナーを日々定点観測し、オーナーに表れる状態をデータ化して蓄積することで、自動運転と手動運転によって変化するオーナーの幸福度を判断することが可能となる。
図3Dは、車両50に乗車中のオーナーに表れる状態の他の一例を示す図である。図3Dに示すように、オーナーは、車両50を購入したときや友人とドライブするときは、ご機嫌状態となる。一方、車両50の車検時には費用が必要となるので不機嫌な状態となる。また一方で、車両50を売却するときは、例えば自動運転可能な車両50であると高価に売却することができ、ご機嫌状態になる。上記はあくまでの一例であるが、例えば車両50が、オーナーを日々定点観測し、オーナーに表れる状態をデータ化して蓄積することで、車両50の購入から売却に至るまでに変化するオーナーの幸福度を判断することが可能となる。
このように、車両50がオーナーを日々定点観測することで、オーナーの幸福度を判断することができる。この幸福度は所定のぶれ幅があるので、車両診断装置10は、車両50に対して幸福度に関する質疑応答を行い、ぶれ幅の大小によって車両50がハッキングされているか否かを診断することができる。
2つ目の診断例は、車両50に搭載された走行システムを動かすソフトウェアの強靭性を確認することで車両診断を行う例である。診断部16は、通信部11を介して、車両50のソフトウェアの強靭性を確認することで、上記診断を行う。そして、診断部16は、ソフトウェアの強靭性のレベルが予め決められたレベルよりも低い場合に、車両50がハッキングされていると診断する。なお、車両50を診断する場合に、ソフトウェアの脆弱性を確認することは、ソフトウェアの強靭性を確認することと実質的に同じである。
図4は、車両診断装置10から車両50に対して行うソフトウェアの強靭性確認手段を示す図である。
例えば、診断部16は、通信部11を介して車両50にDoS(Denial of Service)攻撃及びバッファオーバーフロー攻撃の少なくとも一方の模擬攻撃を行うことで、ソフトウェアの強靭性を確認する。DoS攻撃とは、パケットによって車両50に大量のデータを送信したり、大量のリクエストを行ったりすることである。バッファオーバーフロー攻撃とは、車両50のマイクロプロセッサに許容量以上のデータを送り、マイクロプロセッサの処理を遅らせることである。
車両50がハッキングされていると、これらの模擬攻撃によって車両50のソフトウェアの処理速度が極端に遅くなるなど、車両50に変化が起きる。そこで診断部16は、車両50にこれらの模擬攻撃を行って、車両50の強靭性のレベルが予め決められたレベルよりも低くならなかった場合に、車両50がハッキングされていないと判断し、予め決められたレベルよりも低くなった場合に、車両50がハッキングされていると判断する。ソフトウェアの強靭性のレベルは、表1に示すように、模擬攻撃及び後述するトラップデータの送信に対する耐性を示すレベルである。予め決められた強靭性のレベルは、例えば、レベル5又はレベル4に設定される。
例えば、診断部16は、DoS攻撃によってソフトウェアの強靭性のレベルが予め決められたレベルよりも低くなった場合に、車両50のソフトウェアが機能しなくなるまでDoS攻撃を継続し、車両50に搭載された走行システムをダウンさせてもよい。
また、診断部16は、通信部11を介して車両50にトラップデータを送信することで、ソフトウェアの強靭性を確認する。トラップデータの送信は、ハッカーが作ったバックドアへの対処策である。トラップデータには、例えば、ログインID又は車検情報などの重要項目にハッカーがバックドアを介してアクセスしたか否かを確認する罠が仕込まれていたり、ソフトウェアのバージョンアップの時刻にハッカーがバックドアを介して侵入したか否かを確認する罠が仕込まれていたりする。そこで診断部16は、車両50にトラップデータを送信して、不正アクセス又は不正侵入などが発生しなかった場合に、車両50がハッキングされていないと判断し、上記の不正アクセス又は不正侵入が発生した場合に、車両50がハッキングされていると判断する。例えば、診断部16は、トラップデータの送信によってソフトウェアにバックドアが形成されていることを見つけた場合に、ソフトウェアの強靭性のレベルが予め決められたレベルよりも低く、車両50がハッキングされていると診断してもよい。
このように、車両診断装置10から車両50に対してソフトウェアの強靭性を確認することで、車両50がハッキングされているか否かを診断することができる。
3つ目の診断例は、車両50の運行ログを取得し、運行ログに基づいて車両診断を行う例である。診断部16は、通信部11を介して車両50の運行ログを取得し、車両50が予め決められた運行規則を守っていないことを確認した場合に、車両50がハッキングされていたと診断する。
図5は、車両診断装置10の診断部16で取得する車両の運行ログの一例を示す図である。
運行ログは、例えば、日時、場所(緯度経度)、車両50の速度、車両50のハンドル角度などである。運行規則とは、例えば、車両50の急停車、急発進、ハンドル回し角度及び車両の最高速度などに関する取り決めである。診断部16は、車両50がこれらの運行規則通りに運転されているか否かを判断する。診断部16は、車両50が予め決められた運行規則を守っていない場合に、車両50がハッキングされていたと判断し、運行規則を守っている場合に、車両50がハッキングされていなかったと判断する。
このように、診断部16が車両50の運行ログを取得し、運行ログに基づいて車両診断を行うことで、車両50がハッキングされているか否かを診断することができる。
診断部16によって車両50がハッキングされていると診断された場合、制御部15は、照射部12の照明光を用いて車両50がハッキングされていることを報知する。例えば、照射部12が液晶プロジェクタである場合、制御部15は、照射部12から照射される静止画又は動画を車両50又は駐車場91に照射して、ハッキングに関する情報を報知する。
図6は、車両診断装置10によって報知される報知情報の一例を示す図である。
図6の(a)には、車両50のボンネットに「ハッキングされています」という報知情報が投光されている例が示され、図6の(b)には、駐車場91の地面に「WARNING」という文字からなる報知情報が投光されている例が示されている。照射部12から投光される報知情報は、文字に限られず、図形、記号等を含むマークであってもよい。
これによれば、車両50を使用するユーザが、車両50がハッキングされているか否かを視覚的に知ることができる。これにより、ユーザはハッキングされた車両50に対策を施すことができ、車両50のハッキングによる被害を抑制することができる。
なお、車両診断装置10は、診断結果を報知する他の例として、ネットワークを介して車両診断装置10に通信接続されているコンピュータに診断結果を報知してもよい(図2参照)。例えば、車両診断装置10は、車両50のディーラーが所有するコンピュータである管理サーバーに診断結果を送信してもよい。また、車両診断装置10は、オーナー又はディーラーが予め登録したメールアドレスに電子メールを送信することで、診断結果を報知してもよい。これにより、オーナー又はディーラーはハッキングされた車両50に対策を施すことができ、車両50のハッキングによる被害を抑制することができる。
[1-2.車両診断装置の動作]
次に、実施の形態1に係る車両診断装置10の動作について、図7~図10を参照しながら説明する。
図7は、車両診断装置10の動作を示すフローチャートである。
まず、車両50が駐車場91に駐車され、車両診断装置10の検出部13が車両50を検出する(ステップS11)。
本実施の形態では、検出部13が車両50を検出すると、照射部12の点灯状態が変化する(ステップS12)。具体的には、照射部12が消灯から点灯に変化する。
照射部12の点灯状態が変化する、又は検出部13が車両50を検出すると、車両診断装置10の診断部16は、車両50の診断を実行し(ステップS13)、車両50がハッキングされているか否かを判断する(ステップS14)。ここで車両50がハッキングされていないと判断された場合、制御部15は、車両50がハッキングされていないという診断結果をメモリ15aに記録する(ステップS15)。
一方、車両50がハッキングされていると判断された場合、制御部15は、異常を報知する(ステップS16)。制御部15は、例えば、照射部12の照明光を車両50又は駐車場91に照射させることで、異常を報知する。そして制御部15は、車両50がハッキングされているという診断結果をメモリ15aに記録する(ステップS17)。これにより、車両診断装置10による車両50のハッキング有無の診断を終了する。
ここでさらに、ステップS13にて実行される診断部16の動作の3つの例について、図8~図11を参照しながら説明する。
図8は、車両診断装置10の診断部16の動作の一例を示すフローチャートである。図8は、車両50に対して行う質疑応答のうち、一義的に回答が決まる質問を行う例を示している。
まず、診断部16は、車両50に対して一義的に回答が決まる複数の質問を行う(ステップS131)。これらの複数の質問は、車両50に対してランダムにかつタイミングを変えて行われる。
次に診断部16は、予め決められた時間内に車両50から回答があったか否かを判断する(ステップS132)。ここで予め決められた時間内に車両50から回答があった場合(S132にてYes)、診断部16は、車両50がハッキングされていないと判断する(ステップS133)。
一方、予め決められた時間内に車両50から回答がなかった場合(S132にてNo)、診断部16は、車両50がハッキングされていると判断する(ステップS134)。このように、一義的に回答が決まる質問を行うことで、車両50のハッキング有無を診断することができる。
図9は、車両診断装置10の診断部16の動作の他の例を示すフローチャートである。図9は、車両50に対して行う質疑応答のうち、一義的に回答が決まらない質問を行う例を示している。
まず、診断部16は、車両50に対して一義的に回答が決まらない複数の質問を行う(ステップS131A)。これらの複数の質問は、車両50に対してランダムにかつタイミングを変えて行われる。
次に診断部16は、車両50からの回答のぶれ幅が予め決められたぶれ幅以上であるか否かを判断する(ステップS132A)。ここで回答のぶれ幅が予め決められたぶれ幅以上である場合(S132AにてYes)、診断部16は、車両50がハッキングされていないと判断する(ステップS133A)。
一方、回答のぶれ幅が予め決められたぶれ幅よりも小さい場合(S132AにてNo)、診断部16は、車両50がハッキングされていると判断する(ステップS134A)。このように、一義的に回答が決まらない質問を行うことで、車両50のハッキング有無を診断することができる。
なお、上記では一義的に回答が決まる質問及び一義的に回答が決まらない質問のそれぞれ別々に説明したが、診断部16は、一義的に回答が決まる質問及び一義的に回答が決まらない質問のうちの両方の質問をランダムにタイミングを変えて行い、ハッキング有無の診断を行ってもよい。
図10は、車両診断装置10の診断部16の動作の他の例を示すフローチャートである。図10は、車両50に搭載された走行システムを動かすソフトウェアの強靭性を確認する例を示している。
まず、診断部16は、車両50に対してソフトウェアの強靭性を確認するためのデータを送信する(ステップS131B)。
次に診断部16は、ソフトウェアの強靭性が予め決められたレベルよりも低いか否かを判断する(ステップS132B)。ここでソフトウェアの強靭性が予め決められたレベルよりも低くなかった場合、診断部16は、車両50がハッキングされていないと判断する(ステップS133B)。
一方、ソフトウェアの強靭性が予め決められたレベルよりも低い場合、診断部16は、車両50がハッキングされていると判断する(ステップS134B)。すると診断部16は、ソフトウェアが機能しなくなるまで、模擬攻撃を継続し(ステップS135B)、車両50に搭載された走行システムをダウンさせる。このように、ソフトウェアの強靭性を確認することで、車両50のハッキング有無を診断することができる。
図11は、車両診断装置10の診断部16の動作の他の例を示すフローチャートである。図11は、車両50の運行ログに基づいて車両50のハッキング有無を判断する例を示している。
まず、診断部16は、車両50の運行ログを取得する(ステップS131C)。
次に診断部16は、車両50が予め決められた運行規則を守っていたか否かを判断する(ステップS132C)。ここで車両50が運行規則を守っていた場合(S132CにてYes)、診断部16は、車両50がハッキングされていないと判断する(ステップS133C)。
一方、車両50が運行規則を守っていない場合(S132CにてNo)、診断部16は、車両50がハッキングされていたと判断する(ステップS134C)。このように、運行ログに基づいて車両50のハッキング有無を判断することができる。
このように車両診断装置10は、図8~図11に示された動作によって、車両50のハッキング有無を診断することができる。これにより、車両50のハッキングによる被害を抑制することができる。
(実施の形態2)
[2-1.車両診断装置の構成]
実施の形態2に係る車両診断装置10Aの構成について、図12~図14を参照しながら説明する。実施の形態2では、車両診断装置10Aがポータブル型の車両診断装置である例について説明する。
図12は、実施の形態2に係る車両診断装置10Aの使用例を示す図である。図13は、車両診断装置10Aの構成を示すブロック図である。
図12に示されるように、車両診断装置10Aは、人が携帯可能な懐中電灯であり、円柱状及び円錐台状の形状を有している。図13に示されるように、車両診断装置10Aは、車両50と通信する通信部11と、照明光を照射可能な照射部12と、スイッチ14と、車両50の自動運転プログラムがハッキングされているか否かについて車両50を診断する診断部16と、出力部17とを備えている。また、車両診断装置10Aは、照射部12の点灯、消灯、調光及び調色を制御する制御部15を備えている。
照射部12は、照明光を照射する光源であり、例えば、赤色、緑色、青色の光及びこれらの色の光が合成された光を発するLED発光モジュールである。照射部12は、RGB、電球色や昼白色等の単体のSMD、COBの組み合わせでもよい。照射部12は、車両50を照らすため、車両診断装置10Aの端部に設けられている。
スイッチ14は、車両診断装置10Aの点灯又は消灯の操作入力をする入力部である。本実施の形態では、スイッチ14がONされることで、照射部12が点灯し、照射部12の点灯に伴って診断部16が車両50を診断可能な状態となる。また、スイッチ14がOFFされることで、照射部12が消灯し、照射部12の消灯に伴って診断部16が車両50の診断を終了する。
通信部11は、車両50と無線r1で通信する通信モジュールである。無線r1による通信方式は、前述のとおりである。
出力部17は、診断部16による診断結果を外部に出力するための出力端子であり、例えばUSB(Universal Serial Bus)端子である。
制御部15は、マイクロプロセッサ、メモリ15a及びメモリ15aに格納されたプログラムなどによって構成される。メモリ15aには、車両ナンバーなどの車両50の識別情報が保存されている。また、メモリ15aには、後述する車両50の運行ログ及び診断結果が記録される。制御部15は、照射部12の点灯等を制御するとともに、通信部11、診断部16及び出力部17の作動を制御する。
制御部15は、例えば、スイッチ14のON操作を受け付けると、通信部11を介して車両50の識別情報を要求する要求信号を車両50へ発信する。そして、制御部15は、車両50から送信された車両50の識別情報が、予め登録された識別情報と一致する場合に、車両50の診断を行うように診断部16に診断指令を出す。なお、制御部15は、上記要求信号を発信する代わりに、照射部12から車両50への可視光通信をトリガとして車両50と通信し、車両50の識別情報を取得してもよい。
診断部16は、通信部11を介して車両50がハッキングされているか否かを診断する回路である。診断部16は、例えば、照射部12の点灯状態が変化した場合に、駐車場91に駐車されている車両50に対して診断を行う。具体的には、診断部16は、照射部12が消灯から点灯に変化し、かつ、制御部15からの診断指令を受け付けている場合に、ハッキング有無の診断を行う。
診断部16による車両診断については、前述したように3つの診断例がある。
1つ目の診断例は、車両診断装置10Aから車両50に対して行った質問に対する回答に基づいて、車両診断を行う例である。診断部16は、車両50に対して複数の質問を行い、質問に対する回答時間及び回答傾向の少なくとも一方に基づいて、車両50がハッキングされているか否かを判断する。
2つ目の診断例は、車両50に搭載された走行システムを動かすソフトウェアの強靭性を確認することで車両診断を行う例である。診断部16は、通信部11を介して車両50のソフトウェアの強靭性を確認し、強靭性のレベルが予め決められたレベルよりも低い場合に、車両50がハッキングされていると診断する。
3つ目の診断例は、車両50の運行ログを取得し、運行ログに基づいて車両診断を行う例である。診断部16は、通信部11を介して車両50の運行ログを取得し、車両50が予め決められた運行規則を守っていないことを確認した場合に、車両50がハッキングされていたと診断する。
診断部16によって車両50がハッキングされていると診断された場合、制御部15は、照射部12の照明光を用いて車両50がハッキングされていることを報知する。
図14は、車両診断装置10Aの照射部12の点灯状態を示す図である。
図14に示されるように、車両診断装置10Aは、スイッチ14がONされて診断を開始すると100%点灯し、車両50と通信して診断している最中は点滅状態となる。そして診断結果が、ハッキングされていないという結果のときに青色点灯し、ハッキングされているという結果のときに赤色点灯する。
これによれば、車両50を使用するユーザが、車両50がハッキングされているか否かを視覚的に知ることができる。これにより、ユーザはハッキングされた車両50に対策を施すことができ、車両50のハッキングによる被害を抑制することができる。
[2-2.車両診断装置の動作]
次に、実施の形態2に係る車両診断装置10Aの動作について説明する。
図15は、車両診断装置10Aの動作を示すフローチャートである。
まず、車両診断装置10Aは、ユーザによるスイッチ14のON操作を受け付ける(ステップS21)。これにより、照射部12が点灯する(ステップS22)。
次に、車両診断装置10Aの診断部16は、車両50の診断を実行し(ステップS23)、車両50がハッキングされているか否かを判断する(ステップS24)。ここで車両50がハッキングされていないと判断された場合、制御部15は、照射部12を用いて正常報知を行い(ステップS25)、車両50がハッキングされていないという診断結果をメモリ15aに記録する(ステップS26)。
一方、車両50がハッキングされていると判断された場合、制御部15は、照射部12を用いて異常報知を行い(ステップS27)、車両50がハッキングされているという診断結果をメモリ15aに記録する(ステップS28)。そして、車両診断装置10Aは、スイッチ14のOFF操作を受け付けると照射部12を消灯し、車両50のハッキング有無の診断を終了する。
このように、車両診断装置10Aは、ステップS21~S28に示された動作によって、車両50のハッキング有無を診断することができる。これにより、車両50のハッキングによる被害を抑制することができる。
(実施の形態3)
[3-1.車両診断システムの構成]
実施の形態3に係る車両診断システム1の構成について、図16及び図17を参照しながら説明する。実施の形態3では、車両診断機能を有する車両診断装置10が、IoT(Internet of Things)システムの一部を構成している例について説明する。
図16は、実施の形態3に係る車両診断システム1を示す概略図である。
図16に示されるように、車両診断システム1は、車両診断装置10と、複数の照明機器とによって構成されている。車両診断装置10は、建造物60の外壁に設置されている。複数の照明機器のうちの玄関照明61、リビング照明62、階段照明63、トイレ照明64、寝室照明65のそれぞれは、建造物60の玄関、リビング、階段、トイレ、寝室のそれぞれに対応して設置されている。これらの照明機器のそれぞれは、無線通信機能を有している。
図17は、車両診断システム1を構成する車両診断装置10及び複数の照明機器の通信接続関係を示す図である。
図17に示されるように、車両診断装置10、玄関照明61、リビング照明62、階段照明63、トイレ照明64及び寝室照明65は、メッシュネットワークを構成し、相互に通信可能となっている。ここでいうメッシュネットワークの例としては、BLE(Bluetooth(登録商標) Low Energy)のアドホックネットワークが挙げられる。
本実施の形態の車両診断システム1では、車両診断装置10の診断部16が、建造物60内に設けられた照明機器の点灯状態に応じて診断を開始したり、診断を終了したりする。以下、上記構成を有する車両診断システム1の動作について説明する。
[3-2.車両診断システムの動作]
実施の形態3に係る車両診断システム1の動作について、図18及び図19を参照しながら説明する。
図18は、車両診断システム1の動作の一例を示すフローチャートである。
まず、車両50のオーナーが帰宅すると、その帰宅に伴って車両診断装置10の照射部12及び玄関照明61が点灯する(ステップS31)。そして、オーナーが住宅内に入り、屋内の各照明を点灯させる(ステップS32)。
例えば、時刻24時(0時)の就寝時間になると、オーナーは寝室に入って寝室照明65を消灯する(ステップS33)。就寝する際、車両診断システム1に含まれる複数の照明機器は、リビング照明62、階段照明63、寝室照明65の順で寝室に向かって順に消灯するので、車両診断システム1は、オーナーが寝床に就くことを認識できる。そこで、車両診断システム1は、寝室の遠くから寝室の近くに向けて照明機器が順に消灯されたとき、オーナーが寝床に就いて車両50が長時間にわたり駆動しない状態になるので、この時間を利用して車両診断を開始する(ステップS34)。
時刻6:00の起床時間になると、オーナーは寝室照明65を点灯する(ステップS35)。この点灯により、車両診断システム1は、オーナーが車両50を使用して数十分後に出勤することを認識できる。そこで、車両診断システム1は、この起床時間帯において寝室照明65が点灯されると、車両診断を終了する(ステップS36)。車両診断システム1は、車両診断を終了する際、診断結果を車両診断装置10のメモリ15aに記録させる。
この車両診断システム1によれば、日常生活における照明機器の点灯及び消灯等を利用して、車両50のハッキング有無を診断することができる。これにより、車両50のハッキングによる被害を抑制することができる。
図19は、車両診断システム1の動作の他の例を示すフローチャートである。ステップS31~S34は、図18と同様であるので説明を省略する。
図19では、時刻2:00の深夜に、何らかの理由で外出する必要が生じた場合について説明する。オーナーは深夜に起床すると、寝室照明65などの屋内の各照明機器を点灯する(ステップS35A)。例えばオーナーは出勤する際に、寝室照明65、リビング照明62、玄関照明61の順で照明機器を点灯させて駐車場91に向かう。車両診断システム1は、照明機器が寝室照明65、リビング照明62、玄関照明61の順で点灯することで、オーナーが車両50を使用してすぐに外出することを認識できる。そこで、車両診断システム1は、この深夜の時間において、照明機器が玄関に向かって順に点灯されると、車両診断を終了する(ステップS36A)。車両診断システム1は、車両診断を終了する際に、車両診断が途中である場合は、診断途中の結果をメモリ15aに記録させる。これにより、車両診断の強制終了によるシステム負荷及びシステムへの悪影響を未然防止することができる。
この車両診断システム1によれば、日常生活における照明機器の点灯及び消灯等を利用して、車両50のハッキング有無を診断することができる。これにより、車両50のハッキングによる被害を抑制することができる。
なお、上記では複数の照明機器がIoTシステムを構成している例を示したが、それに限られず、スマートフォン、スマートスピーカ又は目覚まし時計をIoTシステムと連動させてもよい。その場合、車両診断システム1は、例えばスマートフォンに記録されたスケジュール帳、スマートスピーカで読み取ったオーナーの言動、目覚まし時計に設定された起床時間等に基づいて、車両診断の開始時刻及び終了時刻を決定してもよい。
[3-3.実施の形態3の変形例1]
次に、実施の形態3の変形例1に係る車両診断システム1Aの構成について、図20及び図21を参照しながら説明する。実施の形態3の変形例1でも、車両診断機能を有する車両診断装置10が、IoTシステムの一部を構成している例について説明する。
図20は、実施の形態3の変形例1に係る車両診断システム1Aを示す概略図である。
図20に示されるように、車両診断システム1Aは、車両診断装置10と、複数の電気機器とによって構成されている。車両診断装置10は、建造物60の外壁に設置されている。複数の電気機器のうち、玄関照明61、リビング照明62、階段照明63、トイレ照明64、寝室照明65のそれぞれは、建造物60の玄関、リビング、階段、トイレ、寝室のそれぞれに対応して設置されている。また本変形例では、建造物60内において、人感センサ66及び寝室スイッチ67が寝室に設置され、照明コントローラ69がリビングに設置されている。
図21は、車両診断システム1Aを構成する車両診断装置10及び複数の電気機器の通信接続関係を示す図である。
図21に示されるように、玄関照明61、リビング照明62、階段照明63、トイレ照明64、寝室照明65、人感センサ66、寝室スイッチ67のそれぞれは、ネットワークを介して照明コントローラ69に通信接続されている。複数の照明機器、人感センサ66及び寝室スイッチ67を含むそれぞれの電気機器は、照明コントローラ69によって作動制御される。
例えば照明コントローラ69は、寝室の人感センサ66が人を検知した状態で、かつ、寝室スイッチ67がOFFされた場合に、寝室照明65を消灯し、車両診断装置10による車両50の診断を開始する。変形例の車両診断システム1Aでは、複数の電気機器のうち少なくとも一つの電気機器の作動状態が変化した場合に、車両50に対して診断を行う。具体的には、車両診断装置10の診断部16が、建造物60内に設けられた他の電気機器の点灯状態及び作動状態に応じて診断を開始したり、診断を終了したりする。この変形例においても、日常生活における照明機器の点灯及び消灯等を利用して、車両50のハッキング有無を診断することができる。これにより、車両50のハッキングによる被害を抑制することができる。
[3-4.実施の形態3の変形例2]
次に、実施の形態3の変形例2に係る車両診断システム1Bの構成について、図22及び図23を参照しながら説明する。実施の形態3の変形例2では、車両診断システム1Bの車両診断装置10Bが、車両50以外の機器との通信を断ち切った状態で、車両50の診断を行う例について説明する。
図22は、実施の形態3の変形例2に係る車両診断システム1Bを示す概略図である。
図22に示されるように、車両診断システム1Bは、複数の電気機器と、コントローラ69Bと、車両診断装置10Bとによって構成されている。車両診断装置10Bは、建造物60の外壁に設置されている。複数の電気機器のうち、玄関照明61、リビング照明62、階段照明63、トイレ照明64、寝室照明65のそれぞれは、建造物60の玄関、リビング、階段、トイレ、寝室のそれぞれに対応して設置されている。また、人感センサ66及び寝室スイッチ67は、寝室に設置され、ドアスイッチ68は玄関のドアに設置され、コントローラ69Bはリビングに設置されている。
図23は、車両診断システム1Bを構成する複数の電気機器、コントローラ69B及び車両診断装置10Bの通信接続関係を示す図である。図24は、車両診断システム1Bの構成の一部を示すブロック図である。
図23に示されるように、車両診断装置10B、玄関照明61、リビング照明62、階段照明63、トイレ照明64、寝室照明65、人感センサ66、ドアスイッチ68、寝室スイッチ67のそれぞれは、コントローラ69Bに通信接続されている。
図24に示されるように、車両診断装置10Bは、車両50と通信する通信部31と、ネットワークを介して複数の電気機器と通信する通信部32と、車両50の自動運転プログラムがハッキングされているか否かについて車両50を診断する診断部36と、通信部31、通信部32及び診断部36の作動を制御する制御部35とを備えている。
車両診断装置10Bの制御部35は、複数の電気機器のうち少なくとも一つの電気機器の作動状態が変化した場合に、車両50に対して診断を行うように診断部36を制御する。例えば、電気機器の作動状態が変化した場合とは、電気機器である照明機器の点灯状態が変化した場合であり、電気機器である人感センサ66がオーナーを検知した場合であり、電気機器である寝室スイッチ67がオフされた場合であり、又は、電気機器であるドアスイッチ68がオンした場合である。
変形例2の車両診断装置10Bは、診断部36が通信部31を介して上記診断を行う際に、ネットワーク及び通信部32を介して通信する複数の電気機器との通信を遮断した状態で診断を行うように診断部36を制御する。そして上記診断が終了した後、通信部32を用いて複数の電気機器との通信を回復する。このように、車両50のハッキングの診断を行う際に複数の電気機器との通信を遮断することで、例えば、ハッキングされた車両50が複数の電気機器に対して悪影響を及ぼすことを抑制できる。
なお、変形例2の車両診断システム1Bでは、車両診断装置10Bが複数の電気機器との通信を遮断して車両50の診断を行う例について示したが、それに限られない。例えば、車両診断装置10Bが、複数の電気機器との通信を遮断した後、車両50と通信して車両50の運行ログをダウンロードし、その後、車両50との通信を遮断した状態で運行ログを用いて車両50を診断してもよい。
(実施の形態4)
実施の形態4の車両診断システム1Cの構成について、図25及び図26を参照しながら説明する。実施の形態4では、車両診断システム1Cが、照明装置LCと車両診断装置10Cとによって構成されている例について説明する。
図25は、実施の形態4に係る車両診断システム1Cを示す概略図である。
車両診断システム1Cの照明装置LC及び車両診断装置10Cは、車両50が駐車する駐車場91に設置されている。図25では、照明装置LCが駐車場91の壁に設置されているが、それに限られず、照明装置LCは、駐車場91の天井、支柱等に設置されてもよい。
図26は、車両診断システム1Cの構成を示すブロック図である。なお、図26には、ネットワークを介して車両診断システム1Cと通信接続されるコンピュータも示されている。
図26に示されるように、車両診断システム1Cは、照明装置LCと車両診断装置10Cとによって構成されている。照明装置LCは、照明光を照射可能な照射部12と、車両50を検出する検出部13と、照射部12及び検出部13の作動を制御する制御部15とを備えている。車両診断装置10Cは、車両50と通信する通信部31と、車両50の自動運転プログラムがハッキングされているか否かについて車両50を診断する診断部36と、通信部31及び診断部36の作動を制御する制御部35とを備えている。
照明装置LCの照射部12は、照明光を照射する光源であり、例えば、静止画又は動画を投影する液晶プロジェクタ、又は、赤色、緑色、青色の光及びこれらの色の光が合成された光を発するLED発光モジュールである。照射部12は、RGB、電球色や昼白色等の単体のSMD、COBの組み合わせでもよい。照射部12は、車両50及び車両50の周囲を照らすため、車両50の車高よりも高い位置に設けられる。
照明装置LCの検出部13は、駐車場91における車両50の有無を検出するセンサであり、例えば、画像センサ、赤外線センサ又はレーザセンサである。検出部13は、常時稼働することで、駐車場91に車両50が駐車されているか否かを検出する。本実施の形態では、検出部13が車両50を検出することで照射部12が点灯し、また、照射部12の点灯に伴って車両診断装置10Cが車両50を診断可能な状態となる。
車両診断装置10Cの通信部31は、車両50と無線r1で通信する通信モジュールである。無線r1による通信方式は、前述のとおりである。
車両診断装置10Cの制御部35は、マイクロプロセッサ、メモリ35a及びメモリ35aに格納されたプログラムなどによって構成される。メモリ35aには、車両ナンバーなどの車両50の識別情報が保存されている。また、メモリ35aには、車両50の運行ログ及び診断結果が記録される。
制御部35は、例えば、検出部13が車両50を検出し、検出した情報を照明装置LCから取得すると、通信部31を介して車両50の識別情報を要求する要求信号を車両50へ発信する。そして、制御部35は、車両50から送信された車両50の識別情報が、予め登録された識別情報と一致する場合に、車両50の診断を行うように診断部36に診断指令を出す。
なお、制御部35は、上記要求信号を発信する代わりに、照射部12から車両50への可視光通信をトリガとして車両50と通信し、車両50の識別情報を取得してもよい。また、制御部35は、車両ナンバーを検出部13で撮像することで、車両50の識別情報を取得してもよい。また、制御部35は、検出部13を用いる代わりに通信部31を介して定期的にビーコン信号を発信し、車両50に対して識別情報の返信要求をすることで、車両50の識別情報を取得してもよい。すなわち制御部35は、通信部31を用いて車両50を検出し、その後、通信部31を介して診断を行ってもよい。
診断部36は、通信部31を介して車両50がハッキングされているか否かを診断する回路である。診断部36は、例えば、照射部12の点灯状態が変化した場合に、駐車場91に駐車されている車両50に対して診断を行う。具体的には、診断部36は、照射部12が消灯から点灯に変化し、かつ、制御部35からの診断指令を受け付けている場合に、ハッキング有無の診断を行う。
なお、診断部36は、照射部12が消灯から点灯に変化した場合に限られず、照射部12が点灯から消灯又は減光状態に変化した場合あるいは点灯色が変化した場合に、診断を行ってもよい。また、診断部36は、照射部12が点灯から消灯又減光状態に変化した後あるいは点灯色が変化した後、再度点灯状態が変化した場合に、ハッキング有無の診断を終了してもよい。
診断部36による車両診断については、3つの診断例がある。
1つ目の診断例は、車両診断装置10Cから車両50に対して行った質問に対する回答に基づいて、車両診断を行う例である。診断部36は、車両50に対して複数の質問を行い、質問に対する回答時間及び回答傾向の少なくとも一方に基づいて、車両50がハッキングされているか否かを判断する。
2つ目の診断例は、車両50に搭載された走行システムを動かすソフトウェアの強靭性を確認することで車両診断を行う例である。診断部36は、通信部31を介して車両50のソフトウェアの強靭性を確認し、強靭性のレベルが予め決められたレベルよりも低い場合に、車両50がハッキングされていると診断する。
3つ目の診断例は、車両50の運行ログを取得し、運行ログに基づいて車両診断を行う例である。診断部36は、通信部31を介して車両50の運行ログを取得し、車両50が予め決められた運行規則を守っていないことを確認した場合に、車両50がハッキングされていたと診断する。
診断部36によって車両50がハッキングされていると診断された場合、制御部35は、照射部12の照明光を用いて車両50がハッキングされていることを報知する。例えば、照射部12が液晶プロジェクタである場合、制御部35は、照射部12から照射される静止画又は動画を車両50又は駐車場91に照射して、ハッキングに関する情報を報知する。
これによれば、車両50を使用するユーザが、車両50がハッキングされているか否かを知ることができる。これにより、ユーザはハッキングされた車両50に対策を施すことができ、車両50のハッキングによる被害を抑制することができる。
なお、車両診断システム1Cは、診断結果を報知する他の例として、ネットワークを介して車両診断システム1Cに通信接続されているコンピュータに診断結果を報知してもよい(図26参照)。例えば、車両診断システム1Cは、車両50のディーラーが所有するコンピュータである管理サーバーに診断結果を送信してもよい。また、車両診断システム1Cは、オーナー又はディーラーが予め登録したメールアドレスに電子メールを送信することで、診断結果を報知してもよい。これにより、オーナー又はディーラーはハッキングされた車両50に対策を施すことができ、車両50のハッキングによる被害を抑制することができる。
(実施の形態5)
[5-1.車両診断システムの構成]
実施の形態5に係る車両診断システム1Dの構成について、図27~図29を参照しながら説明する。実施の形態5では、車両診断装置10Dが、一般公共用の駐車場91に駐車された車両50の診断を行う例について説明する。
図27は、実施の形態5に係る車両診断システム1Dを示す概略図である。
図27に示されるように、車両診断システム1Dは、駐車場91の脇に設けられた車両診断装置10Dと、車両診断装置10Dと通信する情報端末70とを備えている。情報端末70は、車両50のオーナーが所持する携帯端末である。図27には、1つの車両診断装置10Dが示されているが、車両診断システム1Dは複数の車両診断装置10Dを備えていてもよい。
車両診断装置10Dは、駐車場91に照明光を照射する機能も備えている。車両診断装置10Dは、例えば、屋外の街路灯、防犯灯などであってもよい。車両診断装置10Dは、公園、集合住宅の敷地内又は工場の敷地内等の駐車場に設置されていてもよい。
車両診断装置10Dは、駐車場91の脇に設置される支柱体23と、支柱体23に設けられる灯体22とを備える。支柱体23は、柱状の部材であり、例えば、配電線が設けられた電柱、街路灯の柱、防犯カメラ取付用の柱である。支柱体23は、L字状又はT字状の形状を有していてもよい。
図28は、車両診断システム1Dの構成を示すブロック図である。図29は、車両診断システム1Dの車両診断装置10Dの概略図である。なお、図28には、ネットワークを介して車両診断システム1Dと通信接続されるコンピュータも示されている。
図28に示されるように、車両診断装置10Dは、通信部11と、照射部12と、検出部13と、制御部15と、診断部16とを備えている。
通信部11は、無線r1によって車両50と通信し、無線r2によって情報端末70と通信する通信モジュールである。無線r2による通信方式としては、例えば、Bluetooth(登録商標)、Zigbee(登録商標)、又は、WiFi(登録商標)などの通信方式が用いられる。なお、通信部11は、図示しないインターネット等のネットワークを介して、情報端末70と通信可能であってもよい。通信部11は、例えば、診断部16で得られた診断結果を、無線r2を用いて情報端末70に送信する。
図29に示されるように、車両診断装置10Dは、収容ケースである筐体29を有している。通信部11、照射部12、検出部13、制御部15及び診断部16は、筐体29の内部又は筐体29の外表面に設けられる。筐体29は、例えば、リング状部材及び締結部材等によって支柱体23に固定される。なお、通信部11、照射部12、検出部13、制御部15及び診断部16は、筐体29でなく、支柱体23内に収納されていてもよいし、支柱体23に形成された切り欠き又は穴に設けられていてもよい。
筐体29は、支柱体23の上側の位置、例えば、駐車場91の路面から4.5m以上15m以下の位置に設けられる。筐体29は、例えば直方体状の形状であり、金属又は樹脂等の材料により形成されている。
照射部12は、車両50及び駐車場91に照明光を照射する。照射部12は、静止画又は動画を投影する液晶プロジェクタ、又は、白色光を発するLED発光モジュールである。照射部12は、RGB、電球色や昼白色等の単体のSMD、COBの組み合わせでもよい。照射部12が液晶プロジェクタである場合、車両診断装置10Dは、静止画又は動画を利用して車両50に対してハッキングに関する情報を報知することができる。
検出部13は、駐車場91上の車両50を検出するセンサである。検出部13は、例えば、画像センサ、赤外線センサ又はレーザセンサである。検出部13は、常時稼働することで、駐車場91の所定区域における車両50の有無を常時検出する。検出部13で検出された情報は、制御部15に出力される。
制御部15は、通信部11、照射部12、検出部13及び診断部16の作動を制御する回路である。制御部15は、マイクロプロセッサ、メモリ15a及びメモリ15aに格納されたプログラムなどによって構成される。メモリ15aには、情報端末70の識別情報が記憶されている。
制御部15は、自動運転する車両50を検出部13が検出すると、診断部16に対して、車両50の診断を開始するように診断指令を出す。
なお、制御部15は、検出部13にて車両50の自動運転の有無を検出する代わりに、照射部12から車両50への可視光通信をトリガとして車両50と通信し、車両50の自動運転の有無を判別する情報を取得してもよい。また制御部15は、検出部13にて車両50の自動運転の有無を検出する代わりに、通信部11を介して定期的にビーコン信号を発信し、駐車している車両50に対して自動運転の有無を判別する情報を要求することで、車両50の自動運転の有無を見分けてもよい。
診断部16は、通信部11を介して車両50がハッキングされているか否かを診断する回路である。診断部16は、例えば、照射部12が消灯又は点灯状態であり、かつ、制御部15からの診断指令を受け付けている場合に、ハッキング有無の診断を行う。
診断部16による車両診断については、3つの診断例がある。
1つ目の診断例は、車両診断装置10Dから車両50に対して行った質問に対する回答に基づいて、車両診断を行う例である。診断部16は、車両50に対して複数の質問を行い、質問に対する回答時間及び回答傾向の少なくとも一方に基づいて、車両50がハッキングされているか否かを判断する。
2つ目の診断例は、車両50に搭載された走行システムを動かすソフトウェアの強靭性を確認することで車両診断を行う例である。診断部16は、通信部11を介して車両50のソフトウェアの強靭性を確認し、強靭性のレベルが予め決められたレベルよりも低い場合に、車両50がハッキングされていると診断する。
3つ目の診断例は、車両50の運行ログを取得し、運行ログに基づいて車両診断を行う例である。診断部16は、通信部11を介して車両50の運行ログを取得し、車両50が予め決められた運行規則を守っていないことを確認した場合に、車両50がハッキングされていたと診断する。
診断部16によって車両50がハッキングされていると診断された場合、制御部15は、情報端末70に対して車両50がハッキングされていることを報知する。
情報端末70は、例えば、スマートフォン、タブレット端末、PC(パーソナルコンピュータ)等の端末である。情報端末70には、車両50の診断結果に関する情報を閲覧するためのアプリケーションソフトがインストールされている。情報端末70は、車両診断装置10Dから無線r2を使って診断結果に関する情報を取得し、この情報を画面に表示する。
情報端末70から診断結果に関する情報を得たオーナーは、ハッキングされた車両50に対してすみやかに対策を講じることができる。これにより、車両50のハッキングによる被害を抑制することができる。
なお、車両診断システム1Dは、診断結果を報知する他の例として、ネットワークを介して車両診断システム1Dに通信接続されているコンピュータに診断結果を報知してもよい(図28参照)。例えば、車両診断システム1Dは、車両50のディーラーが所有するコンピュータである管理サーバーに診断結果を送信してもよい。また、車両診断システム1Dは、オーナー又はディーラーが予め登録したメールアドレスに電子メールを送信することで、診断結果を報知してもよい。これにより、オーナー又はディーラーはハッキングされた車両50に対策を施すことができ、車両50のハッキングによる被害を抑制することができる。
[5-2.車両診断システムの動作]
次に、実施の形態5に係る車両診断システム1Dの動作について説明する。
図30は、車両診断システム1Dの動作の一例を示すフローチャートである。
まず、車両50のオーナーが駐車場91に車両50を駐車する(ステップS41)。
車両50が駐車場91に駐車された後、情報端末70を所持するオーナーが、駐車場91から所定の距離を超えて離れると(ステップS42)、車両診断システム1Dは、車両50の診断を開始する(ステップS43)。所定の距離は、駐車場91の出入口から駐車場91とは異なる場所又は通路までの距離であり、例えば5m以上または10m以上である。なお、オーナーが駐車場91から所定の距離を超えて離れたか否かの情報は、車両診断システム1Dが、情報端末70の位置情報を読み込むことで取得できる。
そして、オーナーが車両50の駐車を終えようとして、駐車場91に所定の距離以内近づくと(ステップS44)、車両診断システム1Dは、車両50の診断を終了する(ステップS45)。車両診断を終了する際、車両診断システム1Dは、診断結果をメモリ15aに記録させる。この車両診断システム1Dによれば、駐車場91にて駐車している機会に車両50のハッキング有無を診断することができる。これにより、車両50のハッキングによる被害を抑制することができる。
(実施の形態6)
実施の形態6に係る車両診断システム1Eの構成について、図31及び図32を参照しながら説明する。実施の形態6では、走行中、停車中又は駐車中の車両50の診断を行う例について説明する。
図31に示されるように、車両診断システム1Eは、道路92及び駐車場91の脇に設けられた複数の照明装置LEと、インターネット等のネットワークNを介して複数の照明装置LEに通信接続される車両診断装置10Eとを備えている。なお、図31には、ネットワークNを介して車両診断装置10Eに通信接続される情報端末70も示されている。
照明装置LEは、道路92及び駐車場91に照明光を照射する装置であり、例えば、街路灯、防犯灯などの屋外の照明装置である。
照明装置LEは、道路92及び駐車場91の脇に設置される支柱体23と、支柱体23に設けられる灯体22とを備える。
支柱体23は、柱状の部材であり、例えば、配電線が設けられた電柱、街路灯の柱、防犯カメラ取付用の柱である。支柱体23は、L字状又はT字状の形状を有していてもよい。支柱体23は、道路92の端に沿って所定の間隔、例えば20m以上50m以下の間隔で複数配置されており、灯体22も上記と同じ所定の間隔で複数配置されている。
図32は、車両診断システム1Eの構成を示すブロック図である。なお、図32には、ネットワークを介して車両診断システム1Eと通信接続されるコンピュータも示されている。
図32に示されるように、照明装置LEは、通信部11と、照射部12と、検出部13と、制御部15とを備えている。車両診断装置10Eは、制御部35と診断部36とを備えている。
通信部11は、無線r1によって車両50と通信し、有線によって車両診断装置10Eと通信する通信モジュールである。通信部11は、例えば、検出部13で検出した情報を、ネットワークNを介して車両診断装置10Eに送信する。
灯体22は、収容ケースである筐体29を有している。通信部11、照射部12、検出部13、制御部15は、筐体29の内部又は筐体29の外表面に設けられる。筐体29は、例えば、リング状部材及び締結部材等によって支柱体23に固定される。なお、通信部11、照射部12、検出部13及び制御部15は、筐体29でなく、支柱体23内に収納されていてもよいし、支柱体23に形成された切り欠き又は穴に設けられていてもよい。
筐体29は、支柱体23の上側の位置、例えば、道路92の路面から4.5m以上15m以下の位置に設けられる。筐体29は、例えば直方体状の形状であり、支柱体23から道路92の中央側に突出するように、支柱体23に設けられる。筐体29は、金属又は樹脂等の材料により形成されている。
照射部12は、道路92、駐車場91及び車両50に照明光を照射する。照射部12は、静止画又は動画を投影する液晶プロジェクタ、又は、白色光を発するLED発光モジュールである。照射部12は、RGB、電球色や昼白色等の単体のSMD、COBの組み合わせでもよい。照射部12が液晶プロジェクタである場合、照明装置LEは、静止画又は動画を利用して車両50に対してハッキングに関する情報を報知することができる。
検出部13は、道路92及び駐車場91の車両50を検出するセンサである。検出部13は、図31に示されるように、道路92に沿って設置された複数の支柱体23及び駐車場91に設置された支柱体23のそれぞれに対応して設けられる。検出部13は、例えば、画像センサ、赤外線センサ又はレーザセンサである。検出部13は、常時稼働することで、道路92及び駐車場91の所定区域における車両50の有無を常時検出する。検出部13で検出された情報は、制御部15及び通信部11を介して車両診断装置10Eに出力される。
照明装置LEの制御部15は、通信部11、照射部12、検出部13の作動を制御する回路である。また、制御部15は、マイクロプロセッサ、メモリ15a及びメモリ15aに格納されたプログラムなどによって構成される。
車両診断装置10Eの制御部35は、マイクロプロセッサ、メモリ35a及びメモリ35aに格納されたプログラムなどによって構成される。メモリ35aには、車両ナンバーなどの車両50の識別情報が保存されている。また、メモリ35aには、車両50の運行ログ及び診断結果が記録される。
制御部35は、検出部13が自動運転する車両50を検出し、検出した情報をネットワークNを介して受信すると、診断部36に対して、車両50の診断を開始するように診断指令を出す。
制御部35は、検出部13を用いて、車両50が走行中であるか、停車中であるか又は駐車中であるかを判断してもよい。また、制御部35は、車両50に設けられた加速度センサ等を用いて、車両50が走行中であるか、停車中であるか又は駐車中であるかを判断してもよい。
なお、制御部35は、検出部13にて車両50の自動運転の有無を検出する代わりに、照射部12から車両50への可視光通信をトリガとして車両50と通信し、車両50から自動運転の有無を判別する情報を取得してもよい。また制御部35は、検出部13にて車両50の自動運転の有無を検出する代わりに、通信部11を介して定期的にビーコン信号を発信させ、走行及び駐車している車両50に対して自動運転の有無を判別する情報を要求することで、車両50の自動運転の有無を見分けてもよい。
診断部36は、ネットワークN及び通信部11を介して車両50がハッキングされているか否かを診断する回路である。診断部36は、例えば、制御部35からの診断指令を受け付けている場合に、ネットワークN及び通信部11を介して車両50とデータの送受信を行い、送受信したデータに基づいてハッキング有無の診断を行う。診断部36は、走行中の車両50のハッキング有無を診断する際に、複数の照明装置LEのうち車両50と通信可能である照明装置LEを順次切り替えて車両50と通信し、上記診断を行ってもよい。
診断部36による車両診断については、3つの診断例がある。
1つ目の診断例は、照明装置LEから車両50に対して行った質問に対する回答に基づいて、車両診断を行う例である。診断部36は、照明装置LEを介して車両50に対して複数の質問を行い、質問に対する回答時間及び回答傾向の少なくとも一方に基づいて、車両50がハッキングされているか否かを判断する。
2つ目の診断例は、車両50に搭載された走行システムを動かすソフトウェアの強靭性を確認することで車両診断を行う例である。診断部36は、照明装置LEの通信部11を介して車両50のソフトウェアの強靭性を確認し、強靭性のレベルが予め決められたレベルよりも低い場合に、車両50がハッキングされていると診断する。
3つ目の診断例は、車両50の運行ログを取得し、運行ログに基づいて車両診断を行う例である。診断部36は、照明装置LEの通信部11を介して車両50の運行ログを取得し、車両50が予め決められた運行規則を守っていないことを確認した場合に、車両50がハッキングされていたと診断する。
診断部36によって車両50がハッキングされていると診断された場合、制御部35は、情報端末70に対して車両50がハッキングされていることを報知する。
情報端末70は、例えば、スマートフォン、タブレット端末、PC等の端末である。情報端末70には、車両50の診断結果に関する情報を閲覧するためのアプリケーションソフトがインストールされている。情報端末70は、ネットワークNを介して診断結果に関する情報を取得し、この情報を画面に表示する。
情報端末70から診断結果に関する情報を得たオーナーは、ハッキングされた車両50に対してすみやかに対策を講じることができる。これにより、車両50のハッキングによる被害を抑制することができる。
なお、車両診断システム1Eは、診断結果を報知する他の例として、ネットワークNを介して車両診断システム1Eに通信接続されているコンピュータに診断結果を報知してもよい(図32参照)。例えば、車両診断システム1Eは、車両50のディーラーが所有するコンピュータである管理サーバーに診断結果を送信してもよい。また、車両診断システム1Eは、オーナー又はディーラーが予め登録したメールアドレスに電子メールを送信することで、診断結果を報知してもよい。これにより、オーナー又はディーラーはハッキングされた車両50に対策を施すことができ、車両50のハッキングによる被害を抑制することができる。
図33は、車両診断システム1Eの動作の一例を示す図である。図33には、駐車中、停車中、走行中のそれぞれによって、車両50と通信する際のデータ量及び通信タイミングを異ならせることが示されている。すなわち、車両診断システム1Eの診断部36は、車両50の駐車中と停車中と走行中とで、診断の時間及び診断の量の少なくとも一方を異ならせて、診断を行う。
例えば、診断部36は、車両50が駐車中であると判断した場合に、車両50が走行中又は停車中であるときよりも診断の時間及び診断の量の少なくとも一方を増やして、診断を行ってもよい。また、診断部36は、車両50が停車中であると判断した場合に、車両50が走行中であるときよりも診断の時間及び診断の量の少なくとも一方を増やして、かつ、車両50が駐車中であるときよりも診断の時間及び診断の量の少なくとも一方を減らして、診断を行ってもよい。また、診断部36は、車両50が走行中であると判断した場合に、車両50が停車中又は駐車中であるときよりも診断の時間及び診断の量の少なくとも一方を減らして、診断を行ってもよい。
例えば、車両50が駐車中であるときは、診断の時間及び診断の量を多く確保することができるので、前述した3つの診断例のうち、車両に対する質疑応答、強靭性の確認及び運行ログによる診断が行われる。車両50が停車中であるときは、駐車中に比べて診断の時間及び診断の量を減らさなければならないので、車両50に対する質疑応答及び強靭性の確認のみによる診断が行われ、運行ログによる診断は行われない。車両50が走行中であるときは、停車中に比べて診断の時間及び診断の量を減らさなければならないので、車両に対する質疑応答及び強靭性を確認するためのデータの送受信量又は送受信回数が、停車中に比べて減らされている。車両50が駐車中であるときは、運行ログによる診断は行われない。
これによれば、車両50の駐車中、停車中及び走行中のそれぞれにおいて、車両50に対して適切な診断を行うことができる。
(実施の形態7)
実施の形態7に係る移動体診断装置10Fの構成について、図34及び図35を参照しながら説明する。実施の形態7では、車両50に限られず、無人航空機などの移動体80を診断する例について説明する。
図34は、実施の形態7に係る移動体診断装置10Fの設置例を示す図である。
移動体診断装置10Fは、移動体80を待機させる待機所96に設置され、移動体80及び待機所96に照明光を照射する。図34では、移動体診断装置10Fが建造物60の一例である離発着場の外壁に設置されているが、それに限られず、移動体診断装置10Fは、離発着場の屋根、塀、支柱等に設置されてもよい。
移動体80は、自動運転が可能な無人航空機であり、例えばドローンなどの飛行体である。自動運転とは、自律的に移動体を運転することであり、例えば、運転者を必要としないで運転することはもちろん、運転者の操作を支援しながら運転することも含む。移動体80は、手動運転のモードと自動運転のモードとを相互に切換えることができる飛行体であってもよい。移動体80には、移動体診断装置10Fと通信する通信アンテナ81、及び、移動体診断装置10Fの照明光を認識するカメラ82が設けられている。移動体80は、AIアシスタント機能を有している。
図35は、移動体診断装置10Fの構成を示すブロック図である。なお、図35には、ネットワークを介して移動体診断装置10Fと通信接続されるコンピュータも示されている。
図35に示されるように、移動体診断装置10Fは、移動体80と通信する通信部11と、照明光を照射可能な照射部12と、移動体80を検出する検出部13と、移動体80の自動運転プログラムがハッキングされているか否かについて移動体80を診断する診断部16とを備えている。また、移動体診断装置10Fは、照射部12の点灯、消灯、調光及び調色を制御する制御部15を備えている。
照射部12は、照明光を照射する光源であり、例えば、静止画又は動画を投影する液晶プロジェクタ、又は、赤色、緑色、青色の光及びこれらの色の光が合成された光を発するLED発光モジュールである。照射部12は、RGB、電球色や昼白色等の単体のSMD、COBの組み合わせでもよい。照射部12は、移動体80及び移動体80の周囲を照らすため、移動体80が着陸している待機時の高さよりも高い位置に設けられる。
検出部13は、待機所96における移動体80の有無を検出するセンサであり、例えば、画像センサ、赤外線センサ又はレーザセンサである。検出部13は、常時稼働することで、待機所96に移動体80が待機しているか否かを検出する。本実施の形態では、検出部13が移動体80を検出することで照射部12が点灯し、また、照射部12の点灯に伴って診断部16が移動体80を診断可能な状態となる。
通信部11は、移動体80と無線r1で通信する通信モジュールである。無線r1による通信方式としては、例えば、Bluetooth(登録商標)、920MHz帯の周波数を利用した特定小電力無線、Zigbee(登録商標)、又は、WiFi(登録商標)などの通信方式が用いられる。
制御部15は、マイクロプロセッサ、メモリ15a及びメモリ15aに格納されたプログラムなどによって構成される。メモリ15aには、移動体ナンバーなどの移動体80の識別情報が保存されている。また、メモリ15aには、後述する移動体80の運行ログ及び診断結果が記録される。制御部15は、照射部12の点灯等を制御するとともに、通信部11、検出部13及び診断部16の作動を制御する。
制御部15は、例えば、検出部13が移動体80を検出すると、通信部11を介して移動体80の識別情報を要求する要求信号を移動体80へ発信する。そして、制御部15は、移動体80から送信された移動体80の識別情報が、予め登録された識別情報と一致する場合に、移動体80の診断を行うように診断部16に診断指令を出す。
なお、制御部15は、上記要求信号を発信する代わりに、照射部12から移動体80への可視光通信をトリガとして移動体80と通信し、移動体80の識別情報を取得してもよい。また、制御部15は、移動体ナンバーを検出部13で撮像することで、移動体80の識別情報を取得してもよい。また、制御部15は、検出部13を用いる代わりに通信部11を介して定期的にビーコン信号を発信し、移動体80に対して識別情報の返信要求をすることで、移動体80の識別情報を取得してもよい。すなわち制御部15は、通信部11を用いて移動体80を検出し、その後、通信部11を介して診断を行ってもよい。
診断部16は、通信部11を介して移動体80がハッキングされているか否かを診断する回路である。診断部16は、例えば、照射部12の点灯状態が変化した場合に、待機所96に待機している移動体80に対して診断を行う。具体的には、診断部16は、照射部12が消灯から点灯に変化し、かつ、制御部15からの診断指令を受け付けている場合に、ハッキング有無の診断を行う。
なお、診断部16は、照射部12が消灯から点灯に変化した場合に限られず、照射部12が点灯から消灯又は減光状態に変化した場合あるいは点灯色が変化した場合に、ハッキング有無の診断を行ってもよい。また、診断部16は、照射部12が点灯から消灯又は減光状態に変化した後あるいは点灯色が変化した後、再度点灯状態が変化した場合に、ハッキング有無の診断を終了してもよい。なお、減光状態とは所定の明るさ以下となるように調光制御されている状態、例えば、100%の照度のうち30%の照度で点灯制御されている状態である。点灯色が変化するとは、色温度が変化するように調色制御された状態である。
診断部16による移動体80の診断については、前述した3つの診断例がある。
1つ目の診断例は、移動体診断装置10Fから移動体80に対して行った質問に対する回答に基づいて、移動体80の診断を行う例である。診断部16は、移動体80に対して複数の質問を行い、質問に対する回答時間及び回答傾向の少なくとも一方に基づいて、移動体80がハッキングされているか否かを判断する。
2つ目の診断例は、移動体80に搭載された移動システム(飛行システム)を動かすソフトウェアの強靭性を確認することで移動体80の診断を行う例である。診断部16は、通信部11を介して移動体80のソフトウェアの強靭性を確認し、強靭性のレベルが予め決められたレベルよりも低い場合に、移動体80がハッキングされていると診断する。
3つ目の診断例は、移動体80の運行ログ(飛行記録)を取得し、運行ログに基づいて移動体80の診断を行う例である。診断部16は、通信部11を介して移動体80の運行ログを取得し、移動体80が予め決められた運行規則を守っていないことを確認した場合に、移動体80がハッキングされていたと診断する。
診断部16によって移動体80がハッキングされていると診断された場合、制御部15は、照射部12の照明光を用いて移動体80がハッキングされていることを報知する。例えば、照射部12が液晶プロジェクタである場合、制御部15は、照射部12から照射される静止画又は動画を移動体80又は待機所96に照射して、ハッキングに関する情報を報知する。
これによれば、移動体80を使用するユーザが、移動体80がハッキングされているか否かを視覚的に知ることができる。これにより、ユーザはハッキングされた移動体80に対策を施すことができ、移動体80のハッキングによる被害を抑制することができる。
なお、移動体診断装置10Fは、診断結果を報知する他の例として、ネットワークを介して移動体診断装置10Fに通信接続されているコンピュータに診断結果を報知してもよい(図35参照)。例えば、移動体診断装置10Fは、移動体80の取り扱い業者が所有するコンピュータである管理サーバーに診断結果を送信してもよい。また、移動体診断装置10Fは、オーナー又は取り扱い業者が予め登録したメールアドレスに電子メールを送信することで、診断結果を報知してもよい。これにより、オーナー又は取り扱い業者は、ハッキングされた移動体80に対策を施すことができ、移動体80のハッキングによる被害を抑制することができる。
(実施の形態8)
実施の形態8に係る移動体診断システム1Gの構成について、図36及び図37を参照しながら説明する。実施の形態8では、移動中、停止中又は待機中における移動体80の診断を行う例について説明する。
図36は、実施の形態8に係る移動体診断システム1Gを示す概略図である。図36には、複数の移動体80が、道路の上空を移動路97として飛行している様子、及び、道路の外側に設けられた待機所96に着陸している様子が示されている。
実施の形態8の移動体診断システム1Gは、複数の照明装置LGと、インターネット等のネットワークNを介して複数の照明装置LGに通信接続される移動体診断装置10Gとを備えている。なお、図36には、ネットワークNを介して移動体診断装置10Gに通信接続される情報端末70も示されている。
照明装置LGは、移動体80が移動する移動路97に並行する道路92及び移動体80が待機する待機所96に照明光を照射する装置であり、例えば、街路灯、防犯灯などの屋外の照明装置である。
照明装置LGは、移動路97から見下ろした道路92及び待機所96の脇に設置される支柱体23と、支柱体23に設けられる灯体22とを備える。
支柱体23は、柱状の部材であり、例えば、配電線が設けられた電柱、街路灯の柱、防犯カメラ取付用の柱である。支柱体23は、L字状又はT字状の形状を有していてもよい。支柱体23は、道路92の端に沿って所定の間隔、例えば20m以上50m以下の間隔で複数配置されており、灯体22も上記と同じ所定の間隔で複数配置されている。移動体80は、複数の灯体22から発せられる光を目印に、移動路97を選択してもよい。
図37は、移動体診断システム1Gの構成を示すブロック図である。なお、図37には、ネットワークを介して移動体診断システム1Gと通信接続されるコンピュータも示されている。
図37に示されるように、照明装置LGは、通信部11と、照射部12と、検出部13と、制御部15とを備えている。移動体診断装置10Gは、制御部35と診断部36とを備えている。
通信部11は、無線r1によって移動体80と通信し、有線によって移動体診断装置10Gと通信する通信モジュールである。通信部11は、例えば、検出部13で検出した情報を、ネットワークNを介して移動体診断装置10Gに送信する。
灯体22は、収容ケースである筐体29を有している。通信部11、照射部12、検出部13、制御部15は、筐体29の内部又は筐体29の外表面に設けられる。筐体29は、例えば、リング状部材及び締結部材等によって支柱体23に固定される。なお、通信部11、照射部12、検出部13及び制御部15は、筐体29でなく、支柱体23内に収納されていてもよいし、支柱体23に形成された切り欠き又は穴に設けられていてもよい。
筐体29は、支柱体23の上側の位置であって、かつ、移動体80の移動路97よりも下側の位置に設けられる。筐体29は、例えば直方体状の形状であり、支柱体23から移動路97の中央側に突出するように、支柱体23に設けられる。筐体29は、金属又は樹脂等の材料により形成されている。
照射部12は、移動路97に並行する道路92、待機所96及び移動体80に照明光を照射する。照射部12は、静止画又は動画を投影する液晶プロジェクタ、又は、白色光を発するLED発光モジュールである。照射部12は、RGB、電球色や昼白色等の単体のSMD、COBの組み合わせでもよい。照射部12が液晶プロジェクタである場合、照明装置LGは、静止画又は動画を利用して移動体80に対してハッキングに関する情報を報知することができる。
検出部13は、移動路97及び待機所96の移動体80を検出するセンサである。検出部13は、図36に示されるように、移動路97又は道路92に沿って設置された複数の支柱体23及び待機所96に設置された支柱体23のそれぞれに対応して設けられる。検出部13は、例えば、画像センサ、赤外線センサ又はレーザセンサである。検出部13は、常時稼働することで、移動路97及び待機所96の所定区域における移動体80の有無を常時検出する。検出部13で検出された情報は、制御部15及び通信部11を介して移動体診断装置10Gに出力される。
照明装置LGの制御部15は、通信部11、照射部12、検出部13の作動を制御する回路である。また、制御部15は、マイクロプロセッサ、メモリ15a及びメモリ15aに格納されたプログラムなどによって構成される。
移動体診断装置10Gの制御部35は、マイクロプロセッサ、メモリ35a及びメモリ35aに格納されたプログラムなどによって構成される。メモリ35aには、移動体ナンバーなどの移動体80の識別情報が保存されている。また、メモリ35aには、移動体80の運行ログ及び診断結果が記録される。
制御部35は、検出部13が自動運転する移動体80を検出し、検出した情報をネットワークNを介して受信すると、診断部36に対して、移動体80の診断を開始するように診断指令を出す。
制御部35は、検出部13を用いて、移動体80が移動中であるか、停止中であるか又は待機中であるかを判断してもよい。また、制御部35は、移動体80に設けられた加速度センサ等を用いて、移動体80が移動中であるか、停止中であるか又は待機中であるかを判断してもよい。
なお、制御部35は、検出部13にて移動体80の自動運転の有無を検出する代わりに、照射部12から移動体80への可視光通信をトリガとして移動体80と通信し、移動体80から自動運転の有無を判別する情報を取得してもよい。また制御部35は、検出部13にて移動体80の自動運転の有無を検出する代わりに、通信部11を介して定期的にビーコン信号を発信させ、移動及び待機している移動体80に対して自動運転の有無を判別する情報を要求することで、移動体80の自動運転の有無を見分けてもよい。
診断部36は、ネットワークN及び通信部11を介して移動体80がハッキングされているか否かを診断する回路である。診断部36は、例えば、制御部35からの診断指令を受け付けている場合に、ネットワークN及び通信部11を介して移動体80とデータの送受信を行い、送受信したデータに基づいてハッキング有無の診断を行う。診断部36は、移動中の移動体80のハッキング有無を診断する際に、複数の照明装置LGのうち移動体80と通信可能である照明装置LGを順次切り替えて移動体80と通信し、上記診断を行ってもよい。
診断部36による移動体80の診断については、前述した3つの診断例がある。
1つ目の診断例は、照明装置LGから移動体80に対して行った質問に対する回答に基づいて、移動体80の診断を行う例である。診断部36は、照明装置LGを介して移動体80に対して複数の質問を行い、質問に対する回答時間及び回答傾向の少なくとも一方に基づいて、移動体80がハッキングされているか否かを判断する。
2つ目の診断例は、移動体80に搭載された移動システムを動かすソフトウェアの強靭性を確認することで移動体80の診断を行う例である。診断部36は、照明装置LGの通信部11を介して移動体80のソフトウェアの強靭性を確認し、強靭性のレベルが予め決められたレベルよりも低い場合に、移動体80がハッキングされていると診断する。
3つ目の診断例は、移動体80の運行ログ(飛行記録)を取得し、運行ログに基づいて移動体80の診断を行う例である。診断部36は、照明装置LGの通信部11を介して移動体80の運行ログを取得し、移動体80が予め決められた運行規則を守っていないことを確認した場合に、移動体80がハッキングされていたと診断する。
診断部36によって移動体80がハッキングされていると診断された場合、制御部35は、情報端末70に対して移動体80がハッキングされていることを報知する。
情報端末70は、例えば、スマートフォン、タブレット端末、PC等の端末である。情報端末70には、移動体80の診断結果に関する情報を閲覧するためのアプリケーションソフトがインストールされている。情報端末70は、ネットワークNを介して診断結果に関する情報を取得し、この情報を画面に表示する。
情報端末70から診断結果に関する情報を得たオーナーは、ハッキングされた移動体80に対してすみやかに対策を講じることができる。これにより、移動体80のハッキングによる被害を抑制することができる。
なお、移動体診断システム1Gは、診断結果を報知する他の例として、ネットワークNを介して移動体診断システム1Gに通信接続されているコンピュータに診断結果を報知してもよい(37参照)。例えば、移動体診断システム1Gは、移動体80の取り扱い業者が所有するコンピュータである管理サーバーに診断結果を送信してもよい。また、移動体診断システム1Gは、オーナー又は取り扱い業者が予め登録したメールアドレスに電子メールを送信することで、診断結果を報知してもよい。これにより、オーナー又は取り扱い業者は、ハッキングされた移動体80に対策を施すことができ、移動体80のハッキングによる被害を抑制することができる。
(まとめ)
上述したように、本実施の形態に係る車両診断装置10は、自動運転する車両50と通信する通信部11と、通信部11を介して車両50がハッキングされているか否かを診断する診断部16とを備える。診断部16は、車両50に対して行った質問に対する回答に基づいて、上記診断を行う。
これによれば、診断部16が、上記回答に基づいて、車両50がハッキングされているか否かを診断することができる。これにより、車両50のハッキングによる被害を抑制することができる。
また、診断部16は、複数の質問に対する回答時間及び回答傾向の少なくとも一方に基づいて、上記診断を行ってもよい。
これによれば、車両50がハッキングされているか否かを的確に診断することができる。これにより、車両50のハッキングによる被害を抑制することができる。
また、診断部16は、通信部11を介して、車両50に一義的に回答が決まる質問を行い、質問に対する回答時間が予め決められた時間よりも遅い場合に、車両50がハッキングされていると診断してもよい。
これによれば、車両50がハッキングされているか否かを簡易に診断することができる。これにより、車両50のハッキングによる被害を抑制することができる。
また、 診断部16は、通信部11を介して、車両50に一義的に回答が決まらない複数の質問を行い、複数の質問に対する回答のぶれ幅が予め決められたぶれ幅よりも小さい場合に、車両50がハッキングされていると診断してもよい。
これによれば、車両50がハッキングされているか否かを高度な視点で診断することができる。これにより、車両50のハッキングによる被害を抑制することができる。
また、診断部16は、さらに、通信部11を介して車両50の運行ログを取得し、運行ログに基づいて、上記診断を行ってもよい。
これによれば、運行ログを用いて十分な診断を行うことができる。これにより、車両50のハッキングによる被害を抑制することができる。
また、診断部16は、運行ログに基づいて、車両50が予め決められた運行規則を守っていないことを確認した場合に、車両50がハッキングされていたと診断してもよい。
このように、運行規則を守っていないことを確認することで、十分な診断を行うことができる。これにより、車両50のハッキングによる被害を抑制することができる。
また、診断部16は、車両50の駐車中と停車中と走行中とで、診断の時間及び診断の量の少なくとも一方を異ならせて、上記診断を行ってもよい。
これによれば、駐車、停車、走行などの車両50がおかれている状態に合わせた適切な診断を行うことができる。これにより、車両50のハッキングによる被害を抑制することができる。
また、診断部16は、車両50が駐車中であると判断した場合に、車両50が走行中又は停車中であるときよりも診断の時間及び診断の量の少なくとも一方を増やして、上記診断を行ってもよい。
これによれば、駐車中である車両50に対して十分な診断を行うことができる。これにより、車両50のハッキングによる被害を抑制することができる。
また、診断部16は、車両50が停車中であると判断した場合に、車両50が走行中であるときよりも診断の時間及び診断の量の少なくとも一方を増やして、かつ、車両50が駐車中であるときよりも診断の時間及び診断の量の少なくとも一方を減らして、上記診断を行ってもよい。
これによれば、停車中である車両50に対して適切な診断を行うことができる。これにより、車両50のハッキングによる被害を抑制することができる。
また、診断部16は、車両50が走行中であると判断した場合に、車両50が停車中又は駐車中であるときよりも診断の時間及び診断の量の少なくとも一方を減らして、上記診断を行ってもよい。
これによれば、車両50が走行中であってもそれに合わせた適切な診断を行うことができる。これにより、車両50のハッキングによる被害を抑制することができる。
本実施の形態に係る車両診断システム1Dは、上記車両診断装置と、車両診断装置と通信する情報端末70とを備える。
これによれば、車両50がハッキングされているか否かの情報を情報端末70に送信することができる。これにより、上記情報を得たユーザは、ハッキングされた車両50に対してすみやかに対策を講じることができる。これにより、車両50のハッキングによる被害を抑制することができる。
本実施の形態に係る車両診断システム1Eは、自動運転する車両50と通信する通信部11、ならびに、車両50、車両50が走行する道路92及び車両50が駐車する駐車場91の少なくとも一つに照明光を照射する照射部12を有する照明装置LEと、通信部11に通信接続され、通信部11を介して車両50がハッキングされているか否かを診断する診断部36を有する車両診断装置10Eとを備える。診断部36は、車両50に対して行った質問に対する回答に基づいて、上記診断を行う。
これによれば、車両50が道路92を走行中であっても、また、駐車場91に駐車中であっても、車両50がハッキングされているか否かの診断を行うことができる。これにより、車両50のハッキングによる被害を抑制することができる。
本実施の形態に係る車両診断システム1Cは、自動運転する車両50、車両50が走行する道路92及び車両50が駐車する駐車場91の少なくとも一つに照明光を照射する照明装置LCと、照明装置LC及び車両50と通信する通信部31、ならびに、通信部31を介して車両50がハッキングされているか否かを診断する診断部36を有する車両診断装置10Cとを備える。診断部36は、車両50に対して行った質問に対する回答に基づいて、上記診断を行う。
この車両診断システム1Cにおいても、車両50がハッキングされているか否かの診断を適切に行うことができる。これにより、車両50のハッキングによる被害を抑制することができる。
本実施の形態に係る移動体診断装置10Fは、自動運転する移動体80と通信する通信部11と、通信部11を介して移動体80がハッキングされているか否かを診断する診断部16とを備える。診断部16は、移動体80に対して行った質問に対する回答に基づいて、上記診断を行う。
この移動体診断装置10Fによれば、移動体80がハッキングされているか否かを診断することができるので、移動体80のハッキングによる被害を抑制することができる。
また、移動体80は無人航空機であってもよい。
これによれば、無人航空機がハッキングされているか否かを診断することができるので、無人航空機のハッキングによる被害を抑制することができる。
また、診断部16は、通信部11を介して、移動体80の移動システムを動かすソフトウェアの脆弱性を確認することで、上記診断を行ってもよい。また、診断部16は、通信部11を介して移動体80の運行ログを取得し、運行ログに基づいて、上記診断を行ってもよい。
また、本実施の形態に係る移動体診断システム1Gは、自動運転する移動体80と通信する通信部11、ならびに、移動体80、移動体80が移動する移動路97及び移動体80が待機する待機所96の少なくとも一つに照明光を照射する照射部12を有する照明装置LGと、通信部11に通信接続され、通信部11を介して移動体80がハッキングされているか否かを診断する移動体診断装置10Gとを備える。
これによれば、移動体80が移動路97を移動中であっても、また、待機所96に待機中であっても、移動体80がハッキングされているか否かの診断を行うことができる。これにより、移動体80のハッキングによる被害を抑制することができる。
(その他の実施の形態)
以上、本開示について、実施の形態1~8に基づいて説明したが、本開示は、上記の車両診断装置及び移動体診断装置に限定されるものではない。
上記実施の形態1~8では、照射部12の点灯に変化があった場合に、診断部16、36が車両50等を診断しているが、それに限られない。例えば、診断部16、36は、照射部12の点灯に変化がなくても検出部13が車両50等を検出した場合に、診断を行ってもよい。
上記実施の形態1~8の診断部16、36は、一義的に回答が決まる質問を行って車両50等の診断を行う場合に、図3に示された質問の回答として、回答の間違い、つづりの違い、言語の違い等があるときに、車両50等がハッキングされていると診断してもよい。
また、上記の実施の形態では、車両50等がハッキングされているか否かを診断する診断部16を備える車両診断装置について説明したが、上記実施の形態は、車両50等に対する他の診断にも適用することができる。
例えば、車両診断装置は、自動運転する車両50と通信する通信部11と、通信部11を介して車両50がゾンビ化しているか否かを診断する診断部16と、車両50、車両50が走行する道路92及び車両50が駐車する駐車場91の少なくとも一つに照明光を照射可能な照射部12とを備えていてもよい。ここで、車両50がゾンビ化しているとは、車両50がハッキングされている状態、及び、車両50がコンピュータウィルスに感染している状態の少なくとも一方の状態を含む意味である。車両50がコンピュータウィルスに感染しているか否かは、例えば、車両50を走行させるためのコンピュータプログラムが正常に動いているか否かを検出することで診断できる。
上記実施の形態1~8に係る車両診断装置及び移動体診断装置の動作は、メモリ15aに記憶されたプログラムによって実現されてもよい。すなわちプログラムとして、車両50に照明光を照射する照射部12の点灯状態を変化させるステップと、上記ステップの後に、通信部11を用いて車両50と通信し、車両50がハッキングされているか否かを診断するステップと、を含むプログラムがメモリ15aに記憶され、車両診断装置及び移動体診断装置の動作は、このメモリ15aに記憶されたプログラムによって実現されてもよい。
また、上記実施の形態1~8に係る各制御部は、典型的に集積回路であるLSIとして実現される。これらは個別に1チップ化されてもよいし、一部又は全てを含むように1チップ化されてもよい。
また、集積回路化はLSIに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。LSI製造後にプログラムすることが可能なFPGA(Field Programmable Gate Array)、又はLSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
なお、上記各実施の形態1~8において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、CPU又はプロセッサなどのプログラム実行部が、ハードディスク又は半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。
また、上記で用いた数字は、全て本開示を具体的に説明するために例示するものであり、本開示の実施の形態は例示された数字に制限されない。
また、ブロック図における機能ブロックの分割は一例であり、複数の機能ブロックを一つの機能ブロックとして実現したり、一つの機能ブロックを複数に分割したり、一部の機能を他の機能ブロックに移してもよい。また、類似する機能を有する複数の機能ブロックの機能を単一のハードウェア又はソフトウェアが並列又は時分割に処理してもよい。
また、フローチャートにおける各ステップが実行される順序は、本開示を具体的に説明するために例示するためであり、上記以外の順序であってもよい。また、上記ステップの一部が、他のステップと同時(並列)に実行されてもよい。
その他、実施の形態1~8に対して当業者が思いつく各種変形を施して得られる形態、本開示の趣旨を逸脱しない範囲で実施の形態1~8における構成要素及び機能を任意に組み合わせることで実現される形態も本開示に含まれる。