JP2017152762A - 車載システム、プログラムおよびコントローラ - Google Patents

Abstract

【課題】コントローラと、ゲートウェイと、前記ゲートウェイを介して前記コントローラと通信することが可能な電子装置とを備える車載システムにおいて、ゲートウェイの故障とセキュリティアタックを適切に区別し、それぞれの場合について適切に機能安全を担保する。【解決手段】車載システムにおいて、ゲートウェイは二重化され、対策テーブルを有する。対策テーブルには、通信において発生し得る不具合現象と、その不具合現象がゲートウェイの故障に起因するかゲートウェイへのセキュリティアタックに起因するかの原因の確認方法と、対応する対策方法とが、規定されている。車載システムは、前記ゲートウェイを介する通信において不具合現象が発生したことが検出された場合には、対策テーブルに規定される確認方法に基づいて、検出された不具合現象の原因を判断し、対応する対策方法に沿って対策する。【選択図】図９

Description

本発明は、車載システム、プログラムおよびコントローラに関し、特に自動走行制御機能が搭載された車両に好適に利用できるものである。

自動車において、エンジン、モーター、ブレーキ、ハンドルなどの制御を行う制御系の電子制御ユニット（ＥＣＵ：Electronic Control Unit）をコンポーネントとして、ネットワークが構成されている。ナビゲーションシステムを始め、車車間・路車間通信を行う車外サーバとの通信装置などの情報系ユニットもまた、ＣＡＮ（Controller Area Network）やイーサネット（登録商標；Ethernet、以下同じ）などの通信路を利用して、ネットワーク構成されている。さらに、自動車の自動走行を実現するためには、これらの制御系ネットワークと情報系ネットワークは、論理的には単一のネットワークに統合される。このようなネットワークを、悪意を持ったセキュリティアタッカから守るためには、暗号化技術を主体としたセキュリティ機能が必須である。その一方で自動車は、機能安全をキーワードとした要件を満たす必要がある。

特許文献１には、車両統合制御におけるフェイルセーフシステムが開示されている。車両統合制御される車両統合システムでは、ナビＥＣＵ、エアコンＥＣＵなどの複数の情報系ＥＣＵと、エンジンＥＣＵ、トランスミッションＥＣＵ、走行制御ＥＣＵなどの制御系ＥＣＵとが、単一の通信ラインに接続されている。システムを構成するいずれかのＥＣＵの故障が検出されると、予め設定された優先順位に従って、故障していない他のＥＣＵから、所定の性能を有するものを選定する。選定されたＥＣＵに、故障したＥＣＵの基本プログラムをダウンロードして動作させることにより、故障したＥＣＵの肩代わりをさせる。これにより、いずれかのＥＣＵが故障した場合でも、少なくとも車両が走行できるようにする。

特許文献２には、それぞれにＥＣＵが接続される２つの通信バスと、２つの通信バスの間をつなぐゲートウェイと第三のＥＣＵとで構成される車載通信システムが開示されており、ゲートウェイに異常が検出された場合に、上記第三のＥＣＵによって代行させる。第三のＥＣＵは、ゲートウェイの異常を検出する手段と、ゲートウェイの機能を代行する手段と、通信データの処理を停止または制限する処理制限手段とを備え、ゲートウェイに異常が発生したことを検出した場合には、処理制限手段は優先度の低い処理を中止または制限した上で、ゲートウェイの機能を代行する。

特開２００２−２２１０７５号公報 特開２００８−２５９１２４号公報

特許文献１及び２について本発明者が検討した結果、以下のような新たな課題があることがわかった。すなわち、いずれの先行技術においても、装置の故障や異常が検出された場合が想定されているに留まり、自動走行を行っているときにセキュリティアタックを受けるというような、車両内のセキュリティについては十分に対処することができない。

自動車のセキュリティに関しては、欧州において日本企業も参加したEVITA（E-Safety Vehicle Instruction Protected Application）プロジェクトにおいて検討された。本発明者は、このEVITAプロジェクトで想定されている車載ネットワークで自動走行を実現する場合に発生する問題について検討した。

図１は、自動走行を実現するための車載システムの構成例を模式的に示す説明図である。自動走行を実現するための車載システムは、自動走行コントローラ１がゲートウェイ２を介して、車両内の各種のコントローラを始め、車外の設備や装置とも通信することができるように構成されている。車両内では、カメラ１１、周辺物センサ１２、速度センサ１３などのセンサ類が接続されるセンサ系コントローラ４、ブレーキ、ハンドル系コントローラ５、エンジン、モーター系コントローラ６、ＭＯＤＥＭ７、ＧＰＳ８及びメンテナンスコネクタ３が、ゲートウェイ２を介して自動走行コントローラ１を含めて相互に通信することができるように構成されている。

周辺物センサ１２はカメラ１１とともに、車両の前方を含む周辺の物、例えば障害物、歩行者、車線や中央分離帯を示す白線、標識や信号などを感知するセンサであって、カメラ１１のように光学的な感知だけではなくレーダーなどによる感知も含まれる。センサ系コントローラ４はこれらのセンサから情報を収集して、自動走行コントローラ１等に伝送する。コントローラ５はブレーキやハンドルを制御するコントローラ、コントローラ６はエンジンやモーターを制御するコントローラである。メンテナンスコネクタ３は、例えばＯＤＢ２（On-Board Diagnostic System 2）に準拠し、メンテナンス端末１０と接続するためのコネクタである。ＧＰＳ８は、全地球測位システム（ＧＰＳ：Global positioning System）によって自身の位置を知るための通信装置である。ＭＯＤＥＭ（MOdulation DEModulation unit）９は、車外の広域ネットワーク（ＷＡＮ：Wide Area Network）に接続するための通信装置であって、例えば基地局２２との間で無線通信を行って、インターネット２１などのネットワークを介して外部の情報サーバ２０と接続するためのインターフェースとして機能する。以上のような車内の種々の機器は、現実には複数の車載ネットワークに分かれて接続されており、ゲートウェイ２を始めとする中継装置がその機器間の通信を中継する。

自動走行コントローラ１は、ＧＰＳ８から自車両の位置情報を取得し、ＭＯＤＥＭ９を介して車外の情報サーバ２０から供給される地図情報、渋滞や規制などの交通情報と、センサ系コントローラ４から得られる自車両及びその周辺物の情報を総合的に分析し、コントローラ５及び６を適切に制御することによって、速度を調整し、車の進行方法を指示する。

図２は、図１の車載システムにおいて自動走行を実現するための制御フローの構成例を示すフローチャートである。ドライバが自動走行機能を選択すると、まずカメラ／周辺物センサ／ＧＰＳの機能を有効化し、外部の情報サーバ２０との接続を確立する（Ｓ１）。次に、カメラ１１、周辺センサ１２、速度センサ１３等から収集したデータ、及び、外部の情報サーバ２０から供給される情報から、自車両の位置、速度、周辺物の検知を行う（Ｓ２）。自動走行コントローラ１は、それらの情報をもとに以下の制御を実行することによって、自動走行を実現する。すなわち、障害物の有無を判断し（Ｓ３）、障害物があると判断すると、車を減速させハンドル操作によって障害物を回避する、衝突回避制御（Ｓ４）を実行する。先行車両との距離を算出して、車間距離が十分か否かを判断し（Ｓ５）、十分でない場合には車を減速する車間距離確保制御（Ｓ６）を実行する。自車両の速度を求め、設定された速度範囲内か否かを判断し（Ｓ７）、設定速度範囲を外れていると判断した場合には、車を減速または加速させる速度制御（Ｓ８）を実行する。カメラ１１による自車両の周辺映像から、自車両が車線内を適切に走行しているか否かを判断し（Ｓ９）、車線から外れている或いは外れる恐れがあると判断した場合には、ハンドル操作による車線復帰制御（Ｓ１０）を実行する。

図３は、図１の車載システムにおいて自動走行を実現するための通信フローの例を示すフロー図である。自動走行を実現する上記の制御フローを実行するために、自動走行コントローラ１は各種装置との間で通信を行う。自動走行コントローラ１はゲートウェイ２を介して、カメラ／センサ／ＧＰＳ及び外部サーバに対して接続要求を送信する。ここで、カメラ／センサ／ＧＰＳ及び外部サーバとは、直接的には、図１に示されるセンサ系コントローラ４、ＧＰＳ８及びＭＯＤＥＭ７である。カメラ／センサ／ＧＰＳ及び外部サーバは、要求された接続を完了すると、接続完了通知を、ゲートウェイ２を介して自動走行コントローラ１に返信する。自動走行コントローラ１は、ブレーキ、ハンドル系コントローラ５とエンジン、モーター系コントローラ６に対して、それぞれ自動走行準備要求１と２を、ゲートウェイ２を介して送信し、それぞれ準備が完了すると、コントローラ５と６からゲートウェイ２を介して準備完了通知を受信する。この段階で自動走行のための準備が整う。そこで、自動走行コントローラ１はゲートウェイ２を介して、カメラ／センサ／ＧＰＳ及び外部サーバに対して情報送信要求を送信する。カメラ／センサ／ＧＰＳ及び外部サーバからは、それぞれ要求された情報が、ゲートウェイ２を介して送信される。自動走行コントローラ１は、受信した情報を総合的に分析し、上記の各種判断の結果に基づいて、ブレーキ、ハンドル系コントローラ５とエンジン、モーター系コントローラ６の両方または一方に対して、制御要求１及び／又は制御要求２を送信することによって、車両の走行を自動的に制御する。

図４は、図１の車載システムに不正なコントローラ９が接続された例を示す説明図である。図１と同じ構成であるが、不正なコントローラ９が接続されている。図４ではゲートウェイ２に直接接続されているが、実際には、例えばセンサ系コントローラ４とゲートウェイ２を繋ぐ載ネットワークに接続される。或いは、既に接続されているＥＣＵに対して、メンテナンスコネクタ３から不正なソフトウェアを送り込むなどの攻撃が考えられる。この例では、なりすましを想定している。

図５は、ＣＭＡＣによるなりすまし対策の車載システムへの適用例についての説明図である。ＣＭＡＣ（Cipher-based Message Authentication Code）とは、暗号に基づくメッセージ認証コードである。なりすましを想定するセキュリティアタックに対しては、一般に、ＣＭＡＣなどのセキュアＭＡＣアルゴリズムを適用することによって、対策することができる。図５には、ＣＭＡＣによるなりすまし対策を車載システムに適用した場合の動作が例示されている。送信側である自動走行コントローラ１と、受信側である、例えば走行制御系のコントローラ５や６との間で、同じ秘密鍵Secret Key 1が共有されている。自動走行コントローラ１と走行制御系コントローラは、ＣＡＮ（Controller Area Network）などの通信路で接続されているものとする。

送信側である自動走行コントローラ１は、送信する情報を含むData-1と秘密鍵Secret key 1からＣＭＡＣ生成機能によってメッセージ認証コードCMAC-1を生成し、Data-1にCMAC-1を伴ってＣＡＮなどの通信路を介して受信側である走行制御系のコントローラに送出する。これを受信した走行制御系コントローラは、受信したData-1と自身が持つ秘密鍵Secret key 1からＣＭＡＣ生成機能によってメッセージ認証コードCMAC-2を生成する。生成したCMAC-2と受信したCMAC-1を比較して、一致している場合にはData-1を真正なデータとして活用（例えばハンドル制御用のデータとして利用）し、不一致の場合には受信したパケットを破棄する。仮に、不正なコントローラ９が自動走行コントローラ１になりすまして不正な制御情報を送信したとしても、不正なコントローラ９は真正な秘密鍵Secret key 1を持っていないので、走行制御系コントローラで生成されるCMAC-2は受信したCMAC-1とは一致せず、不正なコントローラ９が送信したパケットは破棄されることとなる。これにより、なりすましが防止される。

図６は、車載システムにおいてなりすまし対策を行わない場合の通信フローの例を示すフロー図であり、図７は、ＣＭＡＣ等によるなりすまし対策を行った場合の通信フローの例を示すフロー図である。どちらの場合も図３に示したのと同様に、自動走行コントローラ１がゲートウェイ２を介して、カメラ／センサ／ＧＰＳ及び外部サーバに対して接続要求を送信して自動走行の準備が整える。その後、自動走行コントローラ１はゲートウェイ２を介して、カメラ／センサ／ＧＰＳ及び外部サーバに対して情報送信要求１を送信して情報送信１を受信し、それに基づいてコントローラ５と６に制御要求１−１と２−１をそれぞれ送信し、さらに情報送信要求２の送信に応じて受信した情報送信２に基づいて次の制御要求２−１と２−２を送信する。このように、カメラ／センサ／ＧＰＳ及び外部サーバからの情報の収集と、コントローラ５と６に対する制御を行うことによって自動走行制御を行っている。ここで、不正なコントローラ９がゲートウェイ２を介して自動走行コントローラ１に対して不正情報を送信したとする。これは、不正なコントローラ９がカメラ／センサ／ＧＰＳ及び外部サーバになりすました例である。

車載システムにおいてなりすまし対策を行わない場合には、図６に示すように、自動走行コントローラ１が受信した不正な情報に基づいて、不正な制御要求１と２をコントローラ５と６にそれぞれ送信してしまうこととなる。これに対して、ＣＭＡＣ等によるなりすまし対策を行った場合には、図７に示すように、自動走行コントローラ１は、受信した不正な情報についてＣＭＡＣによる認証を行うので、受信した不正なパケットを破棄することができ、コントローラ５と６に対して不正な制御は行われない。なお、ＣＭＡＣによる認証は、自動走行コントローラ１ではなく、ゲートウェイ２によって行われるように構成しても良い。

このように、暗号機能等を利用するセキュリティ機能をそのまま車載システムに適用した場合、不正なデータを判別して破棄することができるが、そのデータがブレーキ、アクセル、ハンドル等の制御情報など、自動車の走行制御に直接関連するデータであった場合には、破棄されたことによって走行制御に支障が生じる恐れがあることがわかった。例えば、車間距離が十分でない状況で車間距離を適切にとることができず、接触事故を起こす可能が発生する。このように、車載システムにおいては、特に自動走行制御を行う場合に、セキュリティ機能を単純に組み込むだけでは十分な機能安全が担保されないという課題があることわかった。

このような課題を解決するための手段を以下に説明するが、その他の課題と新規な特徴は、本明細書の記述及び添付図面から明らかになるであろう。

一実施の形態によれば、下記の通りである。

すなわち、電子装置と、ゲートウェイと、前記電子装置との間で前記ゲートウェイを介する通信が可能なコントローラとを備える車載システムにおいて、ゲートウェイは二重化され、前記車載システムは対策テーブルを有する。

対策テーブルには、コントローラと電子装置との間のゲートウェイを介する通信において発生し得る不具合現象と、その不具合現象がゲートウェイの故障に起因するかゲートウェイへのセキュリティアタックに起因するかの原因の確認方法と、対応する対策方法とが、規定されている。車載システムは、前記ゲートウェイを介する通信において不具合現象が発生したことが検出された場合には、対策テーブルに規定される確認方法に基づいて、検出された不具合現象の原因を判断し、対応する対策方法に沿って対策する。

不具合現象の原因がゲートウェイの故障と判断した場合には、前記ゲートウェイを他のゲートウェイによって代替させ、不具合現象の原因がゲートウェイへのセキュリティアタックと判断した場合には、前記ゲートウェイを他のゲートウェイによって代替させ、且つ、前記ゲートウェイをコントローラと電子装置との間の通信路から切り離す。

前記一実施の形態によって得られる効果を簡単に説明すれば下記のとおりである。

すなわち、ゲートウェイの故障とセキュリティアタックとが区別され、それぞれの場合について適切な対策方針を採用することができるので、機能安全が適切に担保される。

図１は、自動走行を実現するための車載システムの構成例を模式的に示す説明図である。 図２は、図１の車載システムにおいて自動走行を実現するための制御フローの構成例を示すフローチャートである。 図３は、図１の車載システムにおいて自動走行を実現するための通信フローの例を示すフロー図である。 図４は、図１の車載システムに不正なコントローラが接続された例を示す説明図である。 図５は、ＣＭＡＣによるなりすまし対策の車載システムへの適用例についての説明図である。 図６は、車載システムにおいてなりすまし対策を行わない場合の通信フローの例を示すフロー図である。 図７は、車載システムにおいてＣＭＡＣ等によるなりすまし対策を行った場合の通信フローの例を示すフロー図である。 図８は、実施形態１に係る車載システムの構成例を模式的に示す説明図である。 図９は、実施形態１の車載システムに搭載される対策テーブルの例を模式的に示す説明図である。 図１０は、第１ゲートウェイ２＿１での自己診断フローを示すフローチャートである。 図１１は、二重化されていないゲートウェイが搭載されている車載システムにおける課題を示すための説明図である。 図１２は、車載システムに搭載されているゲートウェイを二重化したことによる効果を示すための説明図である。 図１３は、図８の車載システムに不正なコントローラが接続された例を示す説明図である。 図１４は、車載システムにおいてセキュリティアタックを受けた場合の通信フローの例を示すフロー図である。 図１５は、車載システムにおいてゲートウェイ１に故障が発生した場合の通信フローの例を示すフロー図である。 図１６は、実施形態１に採用した、機能安全が担保されるセキュリティシステムの概念図である。 図１７は、セキュリティマネージャ機能と機能安全マネージャ機能が組み込まれた、自動走行のための制御フローの構成例を示すフローチャートである。 図１８は、図１７のフローにおける故障診断の構成例を示すフローチャートである。

実施の形態について詳述する。なお、発明を実施するための形態を説明するための全図において、同一の機能を有する要素には同一の符号を付して、その繰り返しの説明を省略する。

〔実施形態１〕
図８は、実施形態１に係る車載システムの構成例を模式的に示す説明図である。図１に示す車載システムと同様であるが、ゲートウェイ２が二重化されている点で相違する。図１に示した車載システムのゲートウェイ２に代えて、第１ゲートウェイ２＿１（図中のゲートウェイ１）と第２ゲートウェイ２＿２（図中のゲートウェイ２）とを備え、自動走行コントローラ１が第１ゲートウェイ２＿１または第２ゲートウェイ２＿２のうちのいづれか一方を介して、車両内の各種のコントローラを始め、車外の設備や装置とも通信することができるように構成されている。他の構成は図１に示した通りであるので、詳しい説明を省略する。ゲートウェイを二重化することにより、ゲートウェイに故障が発生し、または、ＤＯＳ（Denial of Service）攻撃などのセキュリティアタックを受けてゲートウェイが正しく動作しなくなくなった場合にも、ある一定時間は安全に走行動作を維持することができる。

図９は、本実施形態１の車載システムに搭載される対策テーブルの例を模式的に示す説明図である。対策テーブルは、車載システム内の装置、特に制限されないが例えば、自動走行コントローラ１に内蔵される電子計算機で実行されるプログラムから参照されるポリシーである。

対策テーブルには、自動走行コントローラ１と車載システム内の電子装置例えばセンサ系コントローラ４との間の第１ゲートウェイ２＿１（図中のゲートウェイ１）を介する通信において発生し得る不具合現象と、その不具合現象が第１ゲートウェイ２＿１の故障に起因するかセキュリティアタックに起因するか等の原因の確認方法と、対応する対策方法とが規定されている。

車載システムは、自動走行コントローラ１と前記電子装置（例えばセンサ系コントローラ４）との間での第１ゲートウェイ２＿１を介する通信において不具合現象が発生したことが検出された場合には、対策テーブルに規定される確認方法に基づいて、検出された不具合現象の原因を判断し、判断された原因に対応する対策方法に沿って対策する。不具合現象の原因が第１ゲートウェイ２＿１の故障と判断した場合には、第１ゲートウェイ２＿１を第２ゲートウェイ２＿２（図中のゲートウェイ２）によって代替させる。不具合現象の原因が第１ゲートウェイ２＿１へのセキュリティアタックと判断した場合には、第１ゲートウェイ２＿１を第２ゲートウェイ２＿２によって代替させ、且つ、第１ゲートウェイ２＿１を自動走行コントローラ１と前記電子装置との間の通信路から切り離す。ここで、通信路とは例えばＣＡＮ、イーサネット、ＦｌｅｘＲａｙ（登録商標）などの車載ネットワークである。

これにより、ゲートウェイの故障とセキュリティアタックとが区別され、それぞれの場合について適切な対策方法を採用することができるので、機能安全が適切に担保される。不具合現象の原因がセキュリティアタックであると判断した場合には、セキュリティアタックによってウィルスに感染した恐れがあるゲートウェイを車載システムから切り離すことにより、当該ゲートウェイから車載システム全体へ波及する事態を防ぐことができる。

図９にはより詳細な具体例が示されている。

対策テーブルには、３段階の確認方法が含まれ、第３の確認方法は、第１ゲートウェイ２＿１による自己診断である。車載システムは、発生した不具合現象に応じて、第１ゲートウェイ２＿１に自己診断を実行させ、その自己診断の結果に基づいて、当該不具合現象の原因が第１ゲートウェイ２＿１の故障かセキュリティアタックか、あるいは問題ないのかを判断し、その判断結果に基づいた対応方法を採用する。

これにより、不具合現象の原因がより正確に判断され、より適切に対策方針を決めることができ、より適切に機能安全が担保される。

図９の対策テーブルには、自動走行コントローラ１から第１ゲートウェイ２＿１を介して前記電子装置（例えばセンサ系コントローラ４）に送信したパケットに対して、前記電子装置から返送される受信完了通知が、自動走行コントローラ１で受信できない不具合現象と、大幅に遅れて受信される不具合現象とが例示されている。

受信完了通知が受信できない不具合現象の場合には、自動走行コントローラ１からパケットを再送させ、この再送に応答する受信完了通知が受信できた場合には、第１ゲートウェイ２＿１に自己診断を実施させ、この再送に対しても受信完了通知が受信できない場合には、第１ゲートウェイ２＿１の故障と判断する（確認方法１）。

これにより、受信完了通知が受信できなくても直ちに故障として対策するのではなく、ゲートウェイの自己診断によって、故障かセキュリティアタックかが区別されるので、より適切に機能安全を担保することができる。

さらに上記の例で、初めのパケットに応答する受信完了通知が受信できず、再送パケットに応答する受信完了通知が受信できた場合は、エラーとしてそのエラー回数（Nerror）をカウントし、エラー回数に応じて対策方針を変える。

エラー回数が所定回数（N1max）を超えないとき（Nerror≦N1max）には、自己診断の結果、第１ゲートウェイ２＿１に問題がないと診断されたときに、エラー回数（Nerror）をカウントアップして、第１ゲートウェイ２＿１の使用を継続する。自己診断の結果、第１ゲートウェイ２＿１に故障ありと診断されたときには、第１ゲートウェイ２＿１に代えて第２ゲートウェイ２＿２（図中のゲートウェイ２）によって代替させ、第２ゲートウェイ２＿２経由でパケットを送信する。自己診断の結果、セキュリティアタックありと診断されたときには、第１ゲートウェイ２＿１に代えて第２ゲートウェイ２＿２によって代替させ、さらに、第１ゲートウェイ２＿１を自動走行コントローラ１と前記電子装置との間の通信路から切り離す。

一方、エラー回数が所定回数（N1max）を超えているとき（Nerror＞N1max）には、自己診断の結果、第１ゲートウェイ２＿１に問題がないと診断された場合であっても、第１ゲートウェイ２＿１の故障と判断し、第１ゲートウェイ２＿１に代えて第２ゲートウェイ２＿２によって代替させる。自己診断の結果が、第１ゲートウェイ２＿１に故障あり、または、セキュリティアタックありの場合の対策方法は、上記エラー回数が所定回数（N1max）を超えないとき（Nerror≦N1max）と同様である。

これにより、受信完了通知が受信できないエラー回数が所定回数に達するまでは、自己診断の結果ゲートウェイに問題が発見されない限り、当該ゲートウェイの使用を継続することができる。

図９の対策テーブルには、前記電子装置から返送される受信完了通知が、自動走行コントローラ１で受信できない不具合現象の他に、大幅に遅れて受信される不具合現象が例示されている。より具体的には、自動走行コントローラ１から第１ゲートウェイ２＿１を介して前記電子装置（例えばセンサ系コントローラ４）に送信したパケットに対して、前記電子装置から第１ゲートウェイ２＿１を介して返送される受信完了通知が、第１の所定時間（不図示のT0max）よりも遅れて、自動走行コントローラ１で受信される不具合現象について規定されている。即ち、遅延時間（Tdelay）が第１の所定時間（T0max）より大きく第２の所定時間（Tmax）よりも小さい（T0max＜Tdelay≦Tmax）場合に、遅延回数（Ndelay）をカウントする。遅延回数（Ndelay）が所定回数（N2max）を超えない（Ndelay≦N2max）場合には、故障ではないと判断して遅延回数（Ndelay）をカウントアップ（Ndelay = Ndelay＋１）して第１ゲートウェイ２＿１の使用は継続する。一方、遅延回数（Ndelay）が所定回数（N2max）を超えた（Ndelay＞N2max）場合、または、遅延時間（Tdelay）が第２の所定時間（Tmax）よりも大きい（Tdelay＞Tmax）場合には、第１ゲートウェイ２＿１の故障と判断し、第１ゲートウェイ２＿１に代えて第２ゲートウェイ２＿２によって代替させる。

これにより、送信されたパケットに対する受信完了通知が大幅に遅れて受信された場合にも、直ちに故障として対策するのではなく、ゲートウェイの故障か通信エラーかが区別されるので、より適切に機能安全を担保することができる。

図９に例示した対策テーブルでは、パケット再送後に対応する受信完了通知が返って来ない場合、及び、大幅に遅れる場合に、第１ゲートウェイ２＿１の自己診断を行わない例を示したが、このような場合にもそれぞれ第１ゲートウェイ２＿１の自己診断を行うように変更しても良い。

図１０は、第１ゲートウェイ２＿１（ゲートウェイ１）での自己診断フローを示すフローチャートである。第１ゲートウェイ２＿１は、装置の起動時にセキュリティ自己診断（Ｓ３１）と機能安全（Safety）自己診断（Ｓ３２）とを実行する。自己診断の結果に問題があるかどうかを判断し（Ｓ３３）、問題がなければタイマーをスタートして（Ｓ３９）、自動走行コントローラ１からの自己診断要求を待つ（Ｓ４０〜Ｓ４２）。

一方、自己診断の結果に問題があれば自己診断結果を自動走行コントローラ１へ報告し（Ｓ３４）、自動走行コントローラ１から対策方針を受信する（Ｓ３５）。受信した対策方針に第１ゲートウェイ２＿１の停止が含まれているか否かを判断し（Ｓ３６）、含まれていればその対策方針に従って、第１ゲートウェイ２＿１の停止処理を実施する（Ｓ３７）。受信した対策方針に第１ゲートウェイ２＿１の停止が含まれていなければ、その対策方針に従った処理を実施した後に、タイマーをスタートして（Ｓ３９）、自動走行コントローラ１からの自己診断要求を待つ（Ｓ４０〜Ｓ４２）。

ここで、タイマーとは最後に自己診断を実施してからの経過時間を計測するタイマーであり、この自己診断フローでは、タイマーが規定値に到達するか（Ｓ４２）、自動走行コントローラ１からの自己診断要求がある（Ｓ４０）まで、通常機能処理（Ｓ４１）を継続する。即ち、タイマーが規定値に到達するか（Ｓ４２）、自動走行コントローラ１からの自己診断要求がある（Ｓ４０）と、セキュリティ自己診断（Ｓ３１）と機能安全（Safety）自己診断（Ｓ３２）とを実行する。これにより、通常は前記規定値に基づいてタイマーによって管理される一定の周期で自己診断が実施され、自動走行コントローラ１からの自己診断要求があるとその周期に達する前であっても直ちに自己診断が実行される。

図１０に示すフローは、Ｓ４０〜Ｓ４２によって構成されるループの中で、自動走行コントローラ１からの自己診断要求の有無を判定する（Ｓ４０）構成としたが、自動走行コントローラ１からの割り込み要求によって自己診断が実行されるように構成しても良い。

図１１及び図１２は、車載システムに搭載されているゲートウェイを二重化したことによる効果を示すための説明図である。図１１には二重化されていないゲートウェイを搭載する車載システムを示し、図１２にはゲートウェイが二重化された例を示す。

自動走行コントローラ１は、ゲートウェイ２及び走行制御系コントローラ４〜６が正しく受信動作している事を確認する為に、ＣＭＡＣを付加した通常パケット又は検査用のダミーパケットを、ゲートウェイ２を介して走行制御系コントローラ４〜６へ送る。ここで、走行制御系コントローラ４〜６は、図１に示したセンサ系コントローラ４、ブレーキ、ハンドル系コントローラ５、エンジン、モーター系コントローラ６など、自動走行コントローラ１との間で通信を行う何らかのコントローラを例示するものである。走行制御系コントローラ４〜６がＣＭＡＣを付加された通常パケット又は検査用のダミーパケットを正しく受信できている場合は、パケット受信完了通知をＣＭＡＣが付加された別のパケットを自動走行コントローラ１に返送することによって、受信完了の確認を行う。このパケット受信完了通知が返って来ない、又は遅延した場合には、通信経路上又は通信相手の走行制御系コントローラ４〜６に何らか問題があったものと、自動走行コントローラ１は認識することが出来る。

しかし、図１１に示すようにゲートウェイ２が単独の（二重化しない）場合は、セキュリティアタックや故障を検出することは出来ても、その後の走行制御系コントローラ４〜６との通信が途絶するので、走行動作を維持することが出来ない。一方、図１２に示すように、ゲートウェイを二重化した場合、もし第１ゲートウェイ２＿１に何らかの故障が発生し、又はセキュリティアタックを受けていても、通信経路を第２ゲートウェイ２＿２に切り替えて、走行制御系コントローラ４〜６との間の通信を続けることが出来るので、少なくともある一定の期間は、走行動作を継続することができる。

なお、図８、図１２には、ゲートウェイを二重化した例を示したが、さらに多重化しても良い。また、第１ゲートウェイを常用系、第２ゲートウェイを予備系とした場合に、予備系ゲートウェイについては必要最小限のデータ中継機能を有する代替中継装置、例えば単純なハブに代えても良い。代替中継装置の中継性能は、常用系ゲートウェイよりも劣り、自動走行制御を実現するには性能不足であっても、必要最低限の車両走行制御を実行可能な程度に抑えることもできる。低い性能の代替中継装置によって代替させるように構成することによって、二重化に伴うコストの上昇を抑えることができる一方、代替した場合においても必要最小限の車両走行機能を有するので、機能安全が担保される。

本実施形態１に示す、ゲートウェイが二重化された車載システムの動作について、さらに詳しく説明する。

図１３は、図８の車載システムに不正なコントローラ９が接続された例を示す説明図である。図８と同じ構成であるが、不正なコントローラ９が接続されている。図１３では第１ゲートウェイ２＿１（ゲートウェイ１）に直接接続されているが、実際には、例えばセンサ系コントローラ４と第１ゲートウェイ２＿１を繋ぐ車載ネットワークに接続される。或いは、既に接続されているＥＣＵに対して、メンテナンスコネクタ３から不正なソフトウェアを送り込むなどの攻撃が考えられる。この例では、図４と同様になりすましを想定している。

図１４は、車載システムにおいてセキュリティアタックを受けた場合の通信フローの例を示すフロー図である。セキュリティアタックを受ける以前には、自動走行コントローラ１は、パケット１を第１ゲートウェイ２＿１（ゲートウェイ１）を経由して走行制御系コントローラ４〜６に送信し、走行制御系コントローラ４〜６からパケット１の受信完了通知が第１ゲートウェイ２＿１を経由して自動走行コントローラ１に返送される。第１ゲートウェイ２＿１が不正なコントローラ９からのセキュリティアタックを受けて機能不全に陥ったとすると、自動走行コントローラ１が送信するパケット２は、第１ゲートウェイ２＿１から正規の宛先に送信されないので、受信完了通知が戻ってこない。その後、自動走行コントローラ１はパケット２を再送するが、それでも受信完了通知が戻ってこない。そこで、自動走行コントローラ１は第１ゲートウェイ２＿１に自己診断を実行するように要求する。第１ゲートウェイ２＿１が自己診断の結果、ウィルスを検知したことを報告すると、自動走行コントローラ１は、第１ゲートウェイ２＿１、第２ゲートウェイ２＿２及び第２ゲートウェイ２＿２を介した通信相手である走行制御系コントローラ４〜６に対して、第１ゲートウェイ２＿１の切断指示を送信して、第１ゲートウェイ２＿１をネットワークから切り離す。その後、自動走行コントローラ１は、第１ゲートウェイ２＿１を代替する第２ゲートウェイ２＿２を経由して、走行制御系コントローラ４〜６にパケット２を送信し、走行制御系コントローラ４〜６から第２ゲートウェイ２＿２を経由して受信完了通知が返送されることにより、走行制御が再開される。

一方、図１５は、車載システムにおいてゲートウェイ１に故障が発生した場合の通信フローの例を示すフロー図である。第１ゲートウェイ２＿１（ゲートウェイ１）に故障が発生するまでは、図１４と同様に、自動走行コントローラ１は、パケット１を第１ゲートウェイ２＿１を経由して走行制御系コントローラ４〜６に送信し、走行制御系コントローラ４〜６からパケット１の受信完了通知が第１ゲートウェイ２＿１を経由して自動走行コントローラ１に返送される。第１ゲートウェイ２＿１に故障が発生すると、自動走行コントローラ１が送信するパケット２は、第１ゲートウェイ２＿１から正規の宛先に送信されないので、受信完了通知が戻ってこない。その後、自動走行コントローラ１はパケット２を再送するが、それでも受信完了通知が戻ってこない。そこで、自動走行コントローラ１は第１ゲートウェイ２＿１に自己診断を実行するように要求する。第１ゲートウェイ２＿１が自己診断の結果、故障が発生したことを報告すると、自動走行コントローラ１は、第１ゲートウェイ２＿１を代替する第２ゲートウェイ２＿２を経由して、走行制御系コントローラ４〜６にパケット２を送信し、走行制御系コントローラ４〜６から第２ゲートウェイ２＿２を経由して受信完了通知が返送されることにより、走行制御が再開される。図１４に示したセキュリティアタックを受けた場合とは異なり、自動走行コントローラ１は、第１ゲートウェイ２＿１をネットワークから切り離す、切断指示を送信しない。

このように、本実施形態１では、セキュリティアタックの場合と故障の場合とが区別されて、それぞれに適する対策方針が規定され、それに沿った対策方法が実施される。

図１６は、実施形態１に採用した、機能安全が担保されるセキュリティシステムの概念図である。図９に示したような対策テーブルに相当するものが、Ｓｅｃｕｒｉｔｙポリシー、Ｓａｆｅｔｙポリシーであり、それをセキュリティの面から判断するものがセキュリティマネージャ機能（図では「Security機能」）、機能安全の面から判断するものが、機能安全マネージャ機能（図では「Safety機能」）である。第１及び第２ゲートウェイ２＿１と２＿２（ゲートウェイ１とゲートウェイ２）及び走行系制御コントローラ４〜６には、セキュリティマネージャ機能（Security機能）と機能安全マネージャ機能（Safety機能）の両方が含まれているが、システムの上位にある自動走行コントローラ１は、機能安全マネージャ機能（Safety機能）のみである。

これにより、ゲートウェイの故障とセキュリティアタックとが区別され、それぞれの場合について適切な対策方法を採用することができるので、機能安全が適切に担保される。

セキュリティマネージャ機能と機能安全マネージャ機能は、それぞれの装置に内蔵される、例えばマイクロコントローラなどの電子計算機上で動作するプログラムとして提供され、例えば図９に示されるような対策テーブルの形で記憶装置に格納されているＳｅｃｕｒｉｔｙポリシーやＳａｆｅｔｙポリシーを参照して実現される。

本実施形態１では、上位の機能安全マネージャ機能を、自動走行コントローラ１に実装した実施の形態であるが、このような上位の機能安全マネージャ機能は、他の電子装置に実装されても良い。例えば、二重化されたゲートウェイ２＿１と２＿２の両方に実装し、一方から他方への代替に伴って、当該一方の機能安全マネージャ機能を停止し、当該他方のゲートウェイが有する上位の機能安全マネージャ機能に代替させるように構成しても良い。

また、本実施形態１では、自動走行コントローラ１は機能安全マネージャ機能のみを備える例を示したが、自動走行コントローラ１が下位のセキュリティマネージャ機能と機能安全マネージャ機能とを有し、さらに上位の機能安全マネージャ機能を備えるように構成しても良い。

〔実施形態２〕
自動走行コントローラ１における自動走行制御フローに、セキュリティマネージャ機能と機能安全マネージャ機能とを組み込むことができる。

図１７は、セキュリティマネージャ機能と機能安全マネージャ機能が組み込まれた、自動走行のための制御フローの構成例を示すフローチャートであり、図１８は、図１７のフローにおける故障診断の構成例を示すフローチャートである。

自動走行機能が選択されると、図２と同様に、自動走行コントローラ１はカメラ／周辺物センサ／ＧＰＳの機能を有効化し、外部の情報サーバ２０との接続を確立する（Ｓ１）。次に、カメラ１１、周辺センサ１２、速度センサ１３等から収集したデータ、及び、外部の情報サーバから供給される情報から、自車両の位置、速度、周辺物の検知を行う（Ｓ２）。自動走行コントローラ１は、それらの情報をもとに以下の制御を実行することによって、自動走行を実現する。すなわち、障害物の有無を判断し（Ｓ３）、障害物があると判断すると、車を減速させハンドル操作によって障害物を回避する、衝突回避制御（Ｓ４）を実行する。先行車両との距離を算出して、車間距離が十分か否かを判断し（Ｓ５）、十分でない場合には車を減速する車間距離確保制御（Ｓ６）を実行する。自車両の速度を求め、設定された速度範囲内か否かを判断し（Ｓ７）、設定速度範囲を外れていると判断した場合には、車を減速または加速させる速度制御（Ｓ８）を実行する。カメラ１１による自車両の周辺映像から、自車両が車線内を適切に走行しているか否かを判断し（Ｓ９）、車線から外れている或いは外れる恐れがあると判断した場合には、ハンドル操作による車線復帰制御（Ｓ１０）を実行する。

図２の場合と異なるのは、衝突回避制御（Ｓ４）、車間距離確保制御（Ｓ６）、速度制御（Ｓ８）及び車線復帰制御（Ｓ１０）のそれぞれの制御が正常に実行することができない場合を想定している点である。

衝突回避制御（Ｓ４）を行ったにも関わらず、回避不能であると判断（Ｓ１１）した場合には、急ブレーキをかけてエンジンを停止する急停車制御（Ｓ１２）を行う。回避不能であると判断（Ｓ１１）しても直ちに急停車制御（Ｓ１２）に移るのではなく、何回かの衝突回避制御（Ｓ４）のリトライを経た後にもなお回避不能であるときに限って急停車制御（Ｓ１２）に移るように構成しても良い。Ｓ１１において回避が可能か否かの判断が不明である場合にも同様に、何回かの衝突回避制御（Ｓ４）のリトライを経た後にもなお回避不能であるときに限って急停車制御（Ｓ１２）に移るように構成することができる。

車間距離確保制御（Ｓ６）を行ったにも関わらず、減速不能であると判断（Ｓ１３）した場合には、故障診断（Ｓ２０）を行う。これも減速不能の判断後直ちに故障診断（Ｓ２０）を開始しても良いし、何回かのリトライの後になおも減速不能の場合に限って故障診断（Ｓ２０）に移行するように構成しても良い。また、減速してはいるが十分でない場合にも、何回かのリトライの後になおも減速が十分でない場合に限って故障診断（Ｓ２０）に移行するように構成しても良い。

速度制御（Ｓ８）を行ったにも関わらず、設定速度の範囲外であると判断（Ｓ１４）した場合にも、故障診断（Ｓ２０）を行う。これも設定速度範囲外の判断後直ちに故障診断（Ｓ２０）を開始しても良いし、何回かのリトライの後になおも設定速度範囲外の場合に限って故障診断（Ｓ２０）に移行するように構成しても良い。また、速度制御（Ｓ８）によって加速または減速してはいるが変動速度比率が十分でない場合にも、何回かのリトライの後になおも設定速度範囲外である場合に限って故障診断（Ｓ２０）に移行するように構成しても良い。

車線復帰制御（Ｓ１０）を行ったにも関わらず、走行すべき車線内でないと判断（Ｓ１５）した場合にも、故障診断（Ｓ２０）を行う。これも車線外の判断後直ちに故障診断（Ｓ２０）を開始しても良いし、何回かのリトライの後になおも車線外の場合に限って故障診断（Ｓ２０）に移行するように構成しても良い。また、車線復帰制御（Ｓ１０）によって走行すべき車線に復帰する方向に制御されてはいるが、車線を外れている程度を示す評価値（車線範囲外値）に改善が認められない場合には直ちに故障診断（Ｓ２０）に移行し、十分ではないが改善が認める場合には、何回かのリトライの後になおも車線外である場合に限って故障診断（Ｓ２０）に移行するように構成しても良い。

さらに、その他の故障が疑われる場合（Ｓ１６）にも故障診断（Ｓ２０）を実行する。その他の故障が疑われる場合（Ｓ１６）とは、自動走行制御を行っていない場合と同様の簡易的な故障診断によって、故障が疑われる場合である。車載システムに搭載されている装置、例えばセンサ系コントローラ４、ブレーキ、ハンドル系コントローラ５、エンジン、モーター系コントローラ６は、それぞれ簡易的な自己診断機能を備えている。このような簡易的な自己診断機能は、各コントローラに搭載されている半導体チップ、例えばマイクロコントローラ、半導体メモリなどによって実現される。Ｓ１６ではこれら簡易的な自己診断の結果の他、各コントローラからの機能不能報告や電源制御ＩＣ（Integrated Circuit）や温度センサを含めたオフチップセンサによる診断結果の状態も考慮して、故障診断（Ｓ２０）へ移行するか否かを判断する。

図１８に示す故障診断処理では、まず故障診断（Ｓ２１）を行う。具体的には例えば、ＢＩＳＴ（Built In Self-Test）等を含む詳細診断を行い、不具合箇所の特定を行う。さらに、ウィルスチェッカなどにより、各コントローラ内で実施を行い、プログラムのセキュアブート機能、メモリに格納されている不審なデータの有無を定期的にチェックする。

故障診断（Ｓ２１）の結果、自動走行を継続することができない程度の問題がないと判断（Ｓ２２）した場合には、自動走行制御を継続し（Ｓ２５）、問題があると判断した場合には、運転者に自動走行機能の解除を要求する（Ｓ２３）。その後、所定の解除待ち時間を待って、自動走行機能が解除されたか否かを判断し（Ｓ２４）、解除されていれば通常走行に復帰し（Ｓ２６）、解除されていなければ車両を緊急停させる（Ｓ２７）。緊急停止とは例えば、急ブレーキで路肩に停車させ、エンジンを停止するような制御である。

なお、その他の故障の有無の判断（Ｓ１６）では、さらに、車載システム内のＣＡＮなどの通信路におけるトラフィック即ちパケット数を、例えばバックグラウンドで監視し、パケットの数が想定される範囲を外れた場合にも、故障診断（Ｓ２０）へ移行するように構成しても良い。また、故障診断（Ｓ２１）においては、不正プログラムの駆除とその結果の判定を行い、正常状態に復帰できない場合に、次の運転者への自動走行機能の解除要求（Ｓ２３）に進むように構成しても良い。

以上本発明者によってなされた発明を実施形態に基づいて具体的に説明したが、本発明はそれに限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは言うまでもない。

１ 自動走行コントローラ
２、２＿１、２＿２ ゲートウェイ
３ メンテナンスコネクタ
４ センサ系コントローラ
５ ブレーキ、ハンドル系コントローラ
６ エンジン、モーター系コントローラ
７ ＭＯＤＥＭ（MOdulation DEModulation unit）
８ ＧＰＳ（Global Positioning System）
９ 不正なコントローラ
１０ メンテナンス端末
１１ カメラ
１２ 周辺物センサ
１３ 速度センサ
２０ 外部情報サーバ
２１ ネットワーク
２２ 基地局

Claims (19)

1. 電子装置と、ゲートウェイと、前記電子装置との間で前記ゲートウェイを介する通信が可能なコントローラとを備える、車載システムにおいて、
   前記車載システムは、対策テーブルを有し、
   前記対策テーブルには、前記コントローラと前記電子装置との間の前記ゲートウェイを介する通信において発生し得る不具合現象と、前記不具合現象が前記ゲートウェイの故障に起因するか前記ゲートウェイへのセキュリティアタックに起因するかの原因の確認方法と、前記原因に対応する対策方法とが、規定され、
   前記車載システムは、他のゲートウェイをさらに備え、前記コントローラと前記電子装置との間での前記ゲートウェイを介する通信において不具合現象が発生したことが検出された場合には、前記対策テーブルに規定される確認方法に基づいて、検出された不具合現象の原因を判断し、判断された原因に対応する対策方法に沿って対策し、
   前記不具合現象の原因が前記ゲートウェイの故障と判断した場合には、前記ゲートウェイを前記他のゲートウェイによって代替させ、
   前記不具合現象の原因が前記ゲートウェイへのセキュリティアタックと判断した場合には、前記ゲートウェイを前記他のゲートウェイによって代替させ、且つ、前記ゲートウェイを前記コントローラと前記電子装置との間の通信路から切り離す、
   車載システム。
2. 請求項１において、
   前記対策テーブルには、
   発生した不具合現象に応じて、前記ゲートウェイに自己診断を実行させ、前記自己診断の結果に基づいて、当該不具合現象の原因がゲートウェイの故障かゲートウェイへのセキュリティアタックかを判断する、第１の確認方法が含まれる、
   車載システム。
3. 請求項２において、
   前記第１の確認方法には、
   前記コントローラから前記ゲートウェイを介して前記電子装置に送信したパケットに対して、前記電子装置から前記ゲートウェイを介して返送される受信完了通知が、前記コントローラで受信できない不具合現象について、
   前記コントローラから前記パケットを再送させ、前記受信完了通知が受信できた第１の場合に、前記ゲートウェイに自己診断を実施させ、前記受信完了通知が受信できない第２の場合に、前記ゲートウェイの故障と判断する確認方法が含まれる、
   車載システム。
4. 請求項３において、
   前記第１の確認方法には、前記第１の場合が発生したエラー回数をカウントし、
   前記エラー回数が所定回数を超えないときには、前記自己診断の結果前記ゲートウェイに問題がないと診断されたときに、前記ゲートウェイの使用を継続し、
   前記エラー回数が所定回数を超えないときには、前記自己診断の結果前記ゲートウェイに問題がないと診断されたときであっても、前記ゲートウェイの故障と判断する確認方法が含まれる、
   車載システム。
5. 請求項３において、
   前記対策テーブルには、第２の確認方法がさらに含まれ、
   前記第２の確認方法には、
   前記コントローラから前記ゲートウェイを介して前記電子装置に送信したパケットに対して、前記電子装置から前記ゲートウェイを介して返送される受信完了通知が、第１の所定時間の後に前記コントローラで受信される不具合現象について、
   前記不具合現象が発生した遅延回数をカウントし、
   前記遅延回数が所定回数を超えた場合、または、前記受信完了通知が前記第１の所定時間よりも後の第２の所定時間を超えて受信された場合に、前記ゲートウェイの故障と判断する、確認方法が含まれる、
   車載システム。
6. 請求項１から請求項５までのいずれか１項において、
   前記コントローラは、前記車載システムが搭載される車両を自動走行させるための制御を行うコントローラであり、前記電子装置は、前記車両に搭載される各種センサの制御を行う他のコントローラ、または、前記車両の走行を制御するさらに他のコントローラである、
   車載システム。
7. 電子装置と、第１及び第２ゲートウェイと、前記電子装置との間で前記第１または第２ゲートウェイを介する通信が可能なコントローラとを備える、車載システムにおいて、前記電子装置または前記第１または第２ゲートウェイまたは前記コントローラ或いは前記車載システムに含まれる他の装置に内蔵される電子計算機上で動作可能なプログラムであって、
   前記プログラムは、前記コントローラと前記電子装置との間の前記第１ゲートウェイを介する通信において発生し得る不具合現象と、前記不具合現象が前記第１ゲートウェイの故障に起因するか前記第１ゲートウェイへのセキュリティアタックに起因するかの原因の確認方法と、前記原因に対応する対策方法とが、規定される、対策テーブルを有し、
   前記プログラムは、前記コントローラと前記電子装置との間での前記第１ゲートウェイを介する通信において不具合現象が発生したことが検出された場合には、前記対策テーブルに規定される確認方法に基づいて、検出された不具合現象の原因を判断し、判断された原因に対応する対策方法に沿って対策し、
   前記不具合現象の原因が前記第１ゲートウェイの故障と判断した場合には、前記第１ゲートウェイを前記第２ゲートウェイによって代替させ、
   前記不具合現象の原因が前記第１ゲートウェイへのセキュリティアタックと判断した場合には、前記第１ゲートウェイを前記第２ゲートウェイによって代替させ、且つ、前記第１ゲートウェイを前記コントローラと前記電子装置との間の通信路から切り離す、
   プログラム。
8. 請求項７において、前記プログラムが動作する電子計算機は、前記コントローラに内蔵される、
   プログラム。
9. 請求項８において、
   前記対策テーブルには、
   発生した不具合現象に応じて、前記ゲートウェイに自己診断を実行させ、前記自己診断の結果に基づいて、当該不具合現象の原因がゲートウェイの故障かゲートウェイへのセキュリティアタックかを判断する、第１の確認方法が含まれる、
   プログラム。
10. 請求項９において、
    前記第１の確認方法には、
    前記コントローラから前記ゲートウェイを介して前記電子装置に送信したパケットに対して、前記電子装置から前記ゲートウェイを介して返送される受信完了通知が、前記コントローラで受信できない不具合現象について、
    前記コントローラから前記パケットを再送させ、前記受信完了通知が受信できた第１の場合に、前記ゲートウェイに自己診断を実施させ、前記受信完了通知が受信できない第２の場合に、前記ゲートウェイの故障と判断する確認方法が含まれる、
    プログラム。
11. 請求項４において、
    前記第１の確認方法には、前記第１の場合が発生したエラー回数をカウントし、
    前記エラー回数が所定回数を超えないときには、前記自己診断の結果前記ゲートウェイに問題がないと診断されたときに、前記ゲートウェイの使用を継続し、
    前記エラー回数が所定回数を超えないときには、前記自己診断の結果前記ゲートウェイに問題がないと診断されたときであっても、前記ゲートウェイの故障と判断する確認方法が含まれる、
    プログラム。
12. 請求項１０において、
    前記対策テーブルには、第２の確認方法がさらに含まれ、
    前記第２の確認方法には、
    前記コントローラから前記ゲートウェイを介して前記電子装置に送信したパケットに対して、前記電子装置から前記ゲートウェイを介して返送される受信完了通知が、第１の所定時間の後に前記コントローラで受信される不具合現象について、
    前記不具合現象が発生した遅延回数をカウントし、
    前記遅延回数が所定回数を超えた場合、または、前記受信完了通知が前記第１の所定時間よりも後の第２の所定時間を超えて受信された場合に、前記ゲートウェイの故障と判断する、確認方法が含まれる、
    プログラム。
13. 請求項８から請求項１２までのいずれか１項において、
    前記コントローラは、前記車載システムが搭載される車両を自動走行させるための制御を行うコントローラであり、前記電子装置は、前記車両に搭載される各種センサの制御を行う他のコントローラ、または、前記車両の走行を制御するさらに他のコントローラであり、
    前記プログラムはさらに、前記コントローラに内蔵される前記電子計算機上で実行されることにより、前記車両を自動走行させるための前記制御を行う、
    プログラム。
14. 車載システムに搭載可能であり、前記車載システムにおいて電子装置との間でゲートウェイまたは前記ゲートウェイを代替可能な代替中継装置を介する通信が可能なコントローラであって、
    前記コントローラは、対策テーブルを有し、
    前記対策テーブルには、前記コントローラと前記電子装置との間の前記ゲートウェイを介する通信において発生し得る不具合現象と、前記不具合現象が前記ゲートウェイの故障に起因するか前記ゲートウェイへのセキュリティアタックに起因するかの原因の確認方法と、前記原因に対応する対策方法とが、規定され、
    前記コントローラは、前記コントローラと前記電子装置との間での前記ゲートウェイを介する通信において不具合現象が発生したことが検出された場合には、前記対策テーブルに規定される確認方法に基づいて、検出された不具合現象の原因を判断し、判断された原因に対応する対策方法に沿って対策し、
    前記コントローラは、前記不具合現象の原因が前記ゲートウェイの故障と判断した場合には、前記ゲートウェイを前記代替中継装置によって代替させ、
    前記コントローラは、前記不具合現象の原因が前記ゲートウェイへのセキュリティアタックと判断した場合には、前記ゲートウェイを前記代替中継装置によって代替させ、且つ、前記ゲートウェイを前記コントローラと前記電子装置との間の通信路から切り離す、
    コントローラ。
15. 請求項１４において、
    前記対策テーブルには、
    発生した不具合現象に応じて、前記ゲートウェイに自己診断を実行させ、前記自己診断の結果に基づいて、当該不具合現象の原因がゲートウェイの故障かゲートウェイへのセキュリティアタックかを判断する、第１の確認方法が含まれる、
    コントローラ。
16. 請求項１５において、
    前記第１の確認方法には、
    前記コントローラから前記ゲートウェイを介して前記電子装置に送信したパケットに対して、前記電子装置から前記ゲートウェイを介して返送される受信完了通知を、前記コントローラが受信できない不具合現象について、
    前記コントローラは、前記パケットを再送した後、前記受信完了通知が受信できた第１の場合に、前記ゲートウェイに自己診断を実施させ、前記受信完了通知が受信できない第２の場合に、前記ゲートウェイの故障と判断する、確認方法が含まれる、
    コントローラ。
17. 請求項１６において、
    前記第１の確認方法には、前記第１の場合が発生したエラー回数をカウントし、
    前記エラー回数が所定回数を超えないときには、前記自己診断の結果前記ゲートウェイに問題がないと診断されたときに、前記ゲートウェイの使用を継続し、
    前記エラー回数が所定回数を超えないときには、前記自己診断の結果前記ゲートウェイに問題がないと診断されたときであっても、前記ゲートウェイの故障と判断する確認方法が含まれる、
    コントローラ。
18. 請求項１６において、
    前記対策テーブルには、第２の確認方法がさらに含まれ、
    前記第２の確認方法には、
    前記コントローラから前記ゲートウェイを介して前記電子装置に送信したパケットに対して、前記電子装置から前記ゲートウェイを介して返送される受信完了通知が、第１の所定時間を経過した後に前記コントローラで受信される不具合現象について、
    前記不具合現象が発生した遅延回数をカウントし、
    前記遅延回数が所定回数を超えた場合、または、前記受信完了通知が前記第１の所定時間よりも後の第２の所定時間を超えて受信された場合に、前記ゲートウェイの故障と判断する、確認方法が含まれる、
    コントローラ。
19. 請求項１４から請求項１８までのいずれか１項において、
    前記コントローラは、前記車載システムが搭載される車両を自動走行させるための制御を行うコントローラであり、前記電子装置は、前記車両に搭載される各種センサの制御を行う他のコントローラ、または、前記車両の走行を制御するさらに他のコントローラである、
    コントローラ。

Images