次に、上述のネットワークシステムについて、例示的な実施形態を挙げて説明する。
(1)第一実施形態
[ネットワークシステムの構成]
図1に示すネットワークシステム1は、例えば自動車に搭載される車載ネットワークシステムである。ネットワークシステム1は、複数のECU2A,2B,2C,2D,3A,3B,3C,3D,3E,3F,3G,3H、CGW4、複数のグローバルバス5A,5B,5C及びローカルバス6等を有する。ECUは「Electronic Control Unit」の略称である。CGWは「Central Gateway」の略称である。
ECU3A,3B,2A,2Bは、グローバルバス5Aに接続されている。ECU2C,2D,3C,3Dは、グローバルバス5Bに接続されている。ECU3E,3F,3G,3Hは、グローバルバス5Cに接続されている。各グローバルバス5A〜5Cには、例えば、機能的に同系統に分類されるECUが接続されている。一例を挙げれば、例えば、グローバルバス5Aにはボデー系ECUが接続される。グローバルバス5Bには制御系ECUが接続される。グローバルバス5Cには情報系ECUが接続される。
グローバルバス5A〜5Cは、CGW4を介して相互に接続されている。これらの構成により、ECU2A〜2D,ECU3A〜3H、CGW4及びグローバルバス5A〜5Cは、第一ネットワーク1Aを構成している。ECU2A〜2Dは、ローカルバス6に接続されている。これにより、ECU2A〜2D及びローカルバス6は、第二ネットワーク1Bを構成している。すなわち、ECU2A〜2Dは、第一ネットワーク1Aのノードとして機能するように構成され、かつ、第二ネットワーク1Bのノードとしても機能するように構成されている。このように構成されたECU2A〜2Dが、本開示でいう電子装置に相当する。
第一ネットワーク1A及び第二ネットワーク1Bでは、各ネットワークを構成するノードに対してブロードキャスト通信によってデータが伝送される。ただし、第一ネットワーク1Aと第二ネットワーク1Bは、互いに独立したネットワークである。そのため、例えば、第一ネットワーク1Aにおいてデータが伝送された場合でも、そのデータが第二ネットワーク1Bへと伝送されることはない。同様に、第二ネットワーク1Bにおいてデータが伝送された場合でも、そのデータが第一ネットワーク1Aへと伝送されることはない。
CGW4は、グローバルバス5A〜5Cの間に介在して、いずれか一つのグローバルバスから残りのグローバルバスへデータを中継する。また、CGW4は、外部通信路7に接続可能に構成され、外部通信路7とグローバルバス5A〜5Cとの間でデータを中継する。これにより、ECU2A〜2D及びECU3A〜3Hは、第一ネットワーク1A経由で図示しない外部機器と通信可能となっている。第二ネットワーク1Bには、外部通信路に接続可能なノードが設けられていない。そのため、第二ネットワーク1Bのノードが第二ネットワーク1B経由で外部機器と通信することはできない。
外部通信路7は、無線通信路及び有線通信路のうちの少なくとも一方であればよい。また、外部通信路7は、単一の機器と接続可能な通信路及び複数の機器と接続可能な通信路のうちの少なくとも一方であればよい。複数の機器と接続可能な通信路としては、例えば複数の機器がノードとして含まれる外部ネットワークに接続可能な通信路であればよい。外部通信路7は、全部が専用線で構成されていてもよいし、一部が公衆回線で構成されていてもよい。
本実施形態では上記三つのグローバルバス5A〜5Cを例示してあるが、グローバルバスの数は任意である。例えば、グローバルバスの数は、二つ以下又は四つ以上であってもよい。本実施形態では上記十二個のECU2A〜2D及びECU3A〜3Hを例示してあるが、ECU数は任意である。例えば、ECUの数は、十一個以下又は十三個以上であってもよい。本実施形態では上記ECU2A〜2Dがローカルバス6に接続されている例を示したが、ECU3A〜3Hのうちの少なくとも一つがローカルバス6に接続されていてもよい。あるいは、ECU3A〜3Hのうちの少なくとも一つがローカルバス6とは別のローカルバスに接続されていてもよい。
[ECUの構成]
次に、ECUの内部構成について説明する。以下の説明では、図2に示すECU2Bを例に挙げる。ただし、本実施形態において、ECU2A,2C,2Dは、ECU2Bと同様に構成される。また、本実施形態において、ECU3A〜3Hは、第二ネットワーク1Bに接続されていない点で、ECU2Bとは相違するが、その他の点はECU2Bと同様に構成される。
ECU2Bは、図2に示すように、CPU11、RAM12、フラッシュメモリ13、第一通信部16及び第二通信部17等を有する。第一通信部16は、グローバルバス5Aに接続するためのネットワークインターフェースである。第二通信部17は、ローカルバス6に接続するためのネットワークインターフェースである。ECU2A〜2Dの各種機能は、CPU11が非遷移的実体的記録媒体に格納されたプログラムに従って各種処理を実行することにより実現される。この例では、フラッシュメモリ13が、非遷移的実体的記録媒体に該当する。
CPU11がプログラムに従って各種処理を実行する際には、フラッシュメモリ13に格納されたプログラムをRAM12によって構成されるメインメモリにロードするように構成されていてもよい。この場合、CPU11は、メインメモリに格納されたプログラムに従って各種処理を実行する。CPU11がプログラムに従って各種処理を実行することにより、プログラムに対応する方法が実行され、ECU2A〜2Dが備える各種機能が実現される。ただし、ECU2A〜2Dが備える各種機能を実現する手法はソフトウェアに限るものではなく、機能の一部又は全部を、ディジタル回路やアナログ回路等を組み合わせたハードウェアを用いて実現してもよい。
RAM12及びフラッシュメモリ13には、各種記憶領域が確保される。本実施形態に関連する主要な記憶領域としては、RAM12には受信データバッファ12Aが確保される。フラッシュメモリ13には、共通鍵記憶部13A、CVN記憶部13B及びダイアグ記憶部13Cが確保される。受信データバッファ12Aは、第一ネットワーク1A経由で受信したデータを一時的に蓄積するためのバッファである。
受信データバッファ12Aには受信したデータが順次格納され、格納領域が満杯になった場合には、最も古いデータが格納されている領域に新しいデータが上書きで格納される。受信データバッファ12Aのサイズは、第一ネットワーク1A経由で受信するデータ量が最大となる状況を考慮して、少なくとも一定期間分(例えば20ミリ秒分。)のデータについては確実に蓄積できる程度のサイズが確保される。
共通鍵記憶部13Aには、後述する処理の中で、受信データに対するメッセージ認証を実行する際に使用する共通鍵が記憶されている。CVN記憶部13Bには、後述する処理の中で、データの送信元が正当な依頼先装置か否かを確認する際に必要となるCVNのリストが記憶されている。CVNは「Calibration Verification Numbers」の略称である。CVNは、ECUに実装されたソフトウェア等に基づいて生成される照合用コードである。
車両に搭載されるECUには、CVNの生成及び出力を行う機能を実装することが法令等によって義務づけられている。車両に搭載される複数のECUがCVNを生成すると、ECUごとに異なるCVNが生成される。本実施形態においては、ECU2A〜2Dにおいて生成、出力されるCVNが、車両生産時に収集、リスト化されて、CVN記憶部13Bに記憶されている。
ECUに実装されたソフトウェアが更新された場合、あるいはECUに実装されたソフトウェアが改ざんされた場合には、ECUにおいて生成されるCVNが変化する。したがって、車両生産時にCVN記憶部13Bに記憶されたCVNと、ECUから出力されたCVNとを比較して、その比較結果が一致しなければ、CVNを出力したECUの換装ないしはソフトウェアの改ざん等があったのではないかと疑うことができる。ECUに実装されたソフトウェアが正当に更新される場合には、その更新後のECUから出力されるCVNでCVN記憶部13Bに記憶されているCVNを更新すればよい。
ダイアグ記憶部13Cには、ECU2Bにおいて故障等が検知された際に、その故障原因に対応するダイアグコードが記憶される。ダイアグ記憶部13Cには、ダイアグコードに加えて、故障原因の特定を行う上で有用な各種情報が記憶されてもよい。どのような情報を記憶するかは、例えば、ダイアグコードに応じて取り決められた情報を記憶してもよいし、ダイアグコードとは無関係に取り決められた情報を記憶してもよい。
[認証処理の概要]
第一ネットワーク1Aのノードは、外部通信路7経由で到来するデータを受信することができる。そのため、例えば外部通信路7に接続された不正な外部機器から悪意のある不正なデータが伝送され得ることも想定して、そのような不正なデータに対して適切な対処をすることが重要となる。また、ECU2A〜2D及びECU3A〜3Hにおいてプログラムの改ざんが行われた場合、あるいは不正なECUへの換装が行われた場合にも、そのような不正なECUから伝送される不正なデータに対し、適切な対処をすることが重要である。
そこで、本実施形態のネットワークシステム1において、ECU2A〜2D及びECU3A〜3Hは、第一ネットワーク1A経由でデータを受信した際に認証処理を実行し、データの正当性を確認する。本実施形態において、ECU2A〜2D及びECU3A〜3Hは、メッセージ認証によってデータの正当性を確認する。図3に示すように、第一ネットワーク1Aにおいて伝送されるデータD1には、ID、通常データ及び暗号データ等が含まれる。なお、データD1には、これら以外の制御コードやデータ等も含まれるが、本処理には関連しないので説明を省略する。
IDは、データの種別を示す情報、データの内容を示す情報、送信元のノードを示す情報、送信先のノードを示す情報及び通信時の優先度を示す情報等、様々な情報を含み得る識別子である。送信元のノードからブロードキャスト通信によって第一ネットワーク1Aへと送出されるデータD1は、第一ネットワーク1Aにおける送信元ノード以外のノード全てにおいて受信される。データD1を受信したノードは、データD1中に含まれるIDに基づいて、処理対象とすべきデータか否かを判断することができる。
通常データは、送信元ノードが送信先ノードへ送信しようとしたデータの実体部分である。暗号データは、第一ネットワーク1Aのノードが共通に使用する共通鍵を使って、所定の暗号化方式により通常データを暗号化したデータである。共通鍵は、上述の共通鍵記憶部13Aに記憶されている。データD1中に含まれる暗号データは、データD1を送信する送信元ノードにおいて、共通鍵を使って通常データを暗号化し、その暗号化済みのデータの一部を抽出したものである。暗号化済みのデータの一部を抽出するのはデータ量を削減するためである。データ量の削減が不要であれば、暗号化済みのデータの全部を暗号データとして利用してもよい。
以上のようなデータD1を受信したノードにおいて、メッセージ認証を実施する際には、データD1中に含まれる通常データを取り出し、取り出した通常データを送信元ノードと同様の手順で暗号化し、その暗号化済みのデータの一部を抽出する。このようにして受信側ノードで生成される暗号データは、送信元ノードと同じ共通鍵を使って生成されるので、通常は、データD1中に含まれる暗号データと一致する。
しかし、通常データが伝送途中で改ざんされた場合やデータ化けした場合には、受信側ノードで生成される暗号データとデータD1中に含まれる暗号データとが不一致となる。あるいは、共通鍵を知らない不正なノードがデータを送信した場合には、適正な暗号データを生成できないため、受信側ノードで生成される暗号データとデータD1中に含まれる暗号データとが不一致となる。したがって、受信側ノードでは、受信側ノードで生成される暗号データとデータD1中に含まれる暗号データが一致する場合には、認証が成立したと判断する。一方、受信側ノードで生成される暗号データとデータD1中に含まれる暗号データとが不一致となった場合には、認証に失敗したと判断する。
また、本実施形態のネットワークシステム1において、ECU2A〜2Dは、第二ネットワーク1B経由でデータを伝送することができる。ただし、第二ネットワーク1Bは、第一ネットワーク1Aとは異なり、第二ネットワーク1Bの外部とは隔離されたネットワークとなっている。そのため、第一ネットワーク1Aとは異なり、少なくとも第二ネットワーク1Bの外部から不正なデータが伝送されてくることはない。
そこで、ECU2A〜2Dは、第二ネットワーク1B経由でデータを受信した際には、第一ネットワーク1Aの場合とは異なり、認証処理を実行しない。そのため、第二ネットワーク1Bにおいて伝送されるデータD2は、図3に示すように、ID及び通常データ等が含まれるものの、暗号データは含まれないデータとされている。
[認証代行の仕組み]
上述の認証処理において認証に成功した場合、ECU2A〜2D及びECU3A〜3Hは、当該認証成功以降の処理において上述のデータD1を利用する。具体例を挙げれば、例えば、データD1中から通常データが取り出され、その通常データを変数として用いた演算処理、通常データに基づく制御、通常データに応じて判断が分かれる分岐処理等が実行される。
一方、ECU2A〜2D及びECU3A〜3Hのうち、ECU2A〜2Dは、いずれかが上述の認証処理において認証に失敗した場合に、他のECUに認証の代行を依頼する。これは、データD1が不正なために認証に失敗したのではなく、認証処理を実行するECUの故障等が原因で認証に失敗した可能性もあるからである。認証に失敗したECUは、認証に失敗したことを契機として依頼元装置となる。
ここでは、ECU2Bが認証処理において認証に失敗して依頼元装置となる場合を想定して説明を続ける。依頼元装置となったECU2Bは、ECU2A,2C,2D(すなわち、依頼元装置以外のECU。)の中から依頼先装置を選定する。ここでは、ECU2BがECU2Cを依頼先装置として選定した場合を想定して説明を続ける。依頼元装置となるECU2Bは、依頼先装置として選定されたECU2Cへ第二ネットワーク1B経由でデータを送信することにより、認証処理の代行を依頼する。
以下の説明においては、依頼元装置において第一ネットワーク1A経由で受信して、その認証に失敗したデータD1のことを第一データと称する。また、認証処理の代行を依頼するため、依頼元装置から第二ネットワーク1B経由で依頼先装置へと伝送するデータのことを第二データと称する。本実施形態の場合、第二データであること、及びどのECUが依頼先装置として選定されたのかは、第二データ中のIDによって示される。
具体的には、第二データであることを示すIDとしては、依頼先装置として選定され得るECU2A〜2Dそれぞれに対応付けられた複数のIDが用意されている。ECU2Cへ認証処理の代行を依頼する際には、ECU2Cに対応するIDを選択し、そのIDを含む第二データをブロードキャスト通信により第二ネットワーク1Bへと送出する。
ECU2Cでは、第二データを受信した際、そのデータ中に含まれるIDに基づいてECU2Cが依頼先装置に選定されたことを認識し、それを契機にして依頼先装置としての処理を実行する。なお、ECU2A,2Dにおいても、ECU2Bから送信された第二データを受信する。ただし、そのデータ中に含まれるIDに基づいてECU2A,2Dでの対処が必要なデータではないと判断できるので、その判断以降の処理は実行しない。
依頼先装置となるECU2Cでは、第一データに対してメッセージ認証による認証処理を実行する。本実施形態において、ECU2Cは、上述のような受信データバッファ12Aを有し、第一ネットワーク1A経由で受信したデータを一定期間分だけ受信データバッファ12Aに蓄積している。そのため、ECU2Cが第二データを受信した際、ECU2Cは、第二データ中に含まれる情報に基づいて、対象となる第一データを受信データバッファ12Aの中から探し出し、第一データに対する認証処理を実行する。なお、上述のような受信データバッファ12Aを使う代わりに、ECU2BからECU2Cへ第一データが提供されてもよい。
依頼先装置であるECU2Cにおいて第一データに対する認証に成功した場合、ECU2Cは、認証に成功した第一データの内容を含む第三データを第二ネットワーク1B経由でECU2Bに対して送信する。第三データであることは、第三データ中のIDによって示される。依頼元装置であるECU2Bでは、第三データを受信したことにより、依頼先装置での認証に成功したことを認識することができる。そこで、ECU2Bでは、第三データを受信した場合、ECU2Bは第三データに含まれる第一データを利用して、所期の処理を実行することができる。
したがって、このように構成されたネットワークシステム1によれば、ECU2Bにおいて第一データの認証に失敗した場合でも、ECU2Cにおいて第一データの認証に成功すれば、ECU2Bは第三データに含まれる第一データを利用することができる。よって、例えば、ECU2Bにおいて認証処理を実行するために必要となるハードウェア又はソフトウェアに故障等の問題が生じていたとしても、ECU2Bは認証済みの第一データを利用することができる。
[依頼元装置及び依頼先装置において実行される処理の詳細]
次に、上述の依頼元装置及び依頼先装置において実行される処理について、図4〜図8に示すフローチャートに基づいて説明する。上述の依頼元装置となるECUでは、図4,図5及び図8に示す処理が実行される。また、依頼先装置となるECUでは、図5,図6及び図7に示す処理が実行される。ここでは、先に挙げた例と同様に、ECU2Bが依頼元装置となり、ECU2Cが依頼先装置として選定される場合を想定して説明を続ける。
ECU2Bは、図4に示すように、S110において、グローバルバス5Aからデータを受信する。続いて、ECU2Bは、S112において、グローバルバス5Aから受信したデータが第一データか否かを判断する。第一データは、ECU2B,2C以外のECUがブロードキャスト通信によって第一ネットワーク1Aへと送信したデータである。ここでは、一例として、ECU3Hが第一データを送信したものとして、以降の説明を続ける。ECU3Hが第一データを送信した場合、第一データは第一ネットワーク1AにおいてECU3H以外のノード全てに届く。第一データを受信したノードは、第一データ中に含まれるIDに基づいて、処理対象とすべきデータか否か等を判断する。また、本実施形態の場合、少なくともECU2A〜2Dにおいては、第一データを受信したら、第一データを受信データバッファ12Aに格納する。
S110において受信したデータが第一データ以外のデータであった場合は、S112においてNOと判断され、S114へと進む。S114において、ECU2Bは、第一データ以外の受信データに対応する処理を実行する。S114において実行される処理としては、ECU2Bの機能に応じた様々な処理を考え得るが、当該処理そのものは本実施形態における要部ではないので、これ以上の説明は省略する。S114の実行後は図4に示す処理を終了する。
S110において受信したデータが第一データであった場合は、S112においてYESと判断され、S116へと進む。S116において、ECU2Bは、代行依頼済みフラグがオフか否かを判断する。代行依頼済みフラグは、初期値がオフにされていて、後述する処理の中でECU2Bが他のECUに対して認証の代行を依頼すると、後述するS170においてオンにされるフラグである。ここでは、代行依頼済みフラグが初期値(すなわち、オフ。)になっているものとして説明を続ける。
代行依頼済みフラグがオフとなっている場合は、S116においてYESと判断され、S120へと進む。S120において、ECU2Bは、メッセージ認証処理を実行する。このメッセージ認証処理の詳細を図5に示す。メッセージ認証処理を開始すると、ECU2Bは、図5に示すように、S210において、処理対象となるデータに含まれる通常データと暗号データを取り出す。ここでいう処理対象となるデータは、S110において受信した第一データである。
続いて、ECU2Bは、S220において、通常データを共通鍵で暗号化し、暗号データを生成する。ここで暗号化されるデータは、S210において処理対象となるデータから取り出された通常データである。続いて、ECU2Bは、S230において、受信した暗号データと生成したデータが一致するか否かを判断する。受信した暗号データと生成したデータが一致する場合は、S230においてYESと判断され、S240へと進む。
S240へ進んだ場合は、ECU2Bにおいて認証が成立したことになり、図5に示す処理を終了して、図4のS130へと進む。一方、受信した暗号データと生成したデータが一致しない場合は、S230においてNOと判断され、S250へと進む。S250へ進んだ場合は、ECU2Bにおいて認証に失敗したことになり、図5に示す処理を終了して、図4のS130へと進む。
ECU2Bは、S130において、認証が成立したか否かを判断する。上述のS240において認証が成立している場合は、S130においてYESと判断され、S140へと進む。ECU2Bは、S140において、第一データに含まれる通常データを取り出して、以降の処理で利用する。ここでいう「以降の処理」としては、ECU2Bの機能に応じた様々な処理を考え得るが、当該処理そのものは本実施形態における要部ではないので、これ以上の説明は省略する。S140の実行後は図4に示す処理を終了する。
一方、上述のS250において認証に失敗している場合には、S130においてNOと判断され、S150へと進む。ECU2Bは、S150において、第一データに含まれるIDを取り出して他の部分は破棄する。続いて、ECU2Bは、S160において、取り出したIDを含む第二データを作成し、一つの依頼先装置に対して認証代行依頼をするためのIDを第二データに設定し、第二データをローカルバス6へ送信する。
本実施形態においては、上述の通り、ECU2Cが依頼先装置として選定される場合を想定している。そのため、S160では、ECU2Cに対して認証代行依頼をするためのIDを第二データに設定する。認証代行依頼をするためのIDとしては、依頼先装置となり得るECUごとに異なる複数のIDがあらかじめ用意されている。S160を終えたら、続いて、ECU2Bは、S170において、代行依頼済みフラグをオンにする。代行依頼済みフラグは、S160においてECU2BがECU2Cに対して認証の代行を依頼した場合に、S170においてオンとなる。S170の実行後は図4に示す処理を終了する。
図4に示す処理は、ECU2Bがグローバルバス5Aからデータを受信するたびに、ECU2Bにおいて実行される。図4に示す処理が複数回にわたって実行される中で、ECU2Bが、S160においてECU2Cに対して認証の代行を依頼し、S170において代行依頼済みフラグがオンにされた場合、次に図4に示す処理が実行される際にはS116においてNOと判断される。この場合、ECU2Bは、S180において、受信データを破棄する。
詳しくは後述するが、ECU2Bが、S160においてECU2Cに対して認証の代行を依頼した場合、以降、ECU2Bは、ECU2Cから第一データの内容を含む第三データを受け取るようになる。そのため、代行依頼済みフラグがオン(すなわち、S116においてNO。)の場合、グローバルバス5Aから受信した第一データは、ECU2Bにとって不要なデータとなるので、S180では、受信した第一データを破棄する。S180を終えたら図4に示す処理を終了する。
ECU2Bにおいて上述のような処理が実行されている際、ECU2Cでは図6及び図7に示す処理が実行される。図6に示す処理は、ECU2Cがローカルバス6からデータを受信する際にECU2Cにおいて実行される処理である。図7に示す処理は、ECU2Cがグローバルバス5Bからデータを受信する際にECU2Cにおいて実行される処理である。まず、図6に示す処理について説明する。
ECU2Cは、図6に示すように、S310において、ローカルバス6からデータを受信する。続いて、ECU2Cは、S320において、上記S310で受信したデータがECU2C宛ての第二データか否かを判断する。ここで、第二データであること、及びECU2C宛てであることは、受信データ中に含まれるIDに基づいて判断することができる。ECU2Bにおいて上述のS160が実行された場合、第二データはブロードキャスト通信によって第二ネットワーク1Bへと送信される。そのため、第二データは第二ネットワーク1BにおいてECU2B以外のノード全てに届く。
ECU2CにおいてECU2C宛ての第二データを受信した場合、ECU2Cでは、S320においてYESと判断されて、S325へと進む。S325において、ECU2Cは、代行継続フラグをオンにする。続いて、ECU2Cは、S330において、処理対象となる第一データを受信データバッファ12Aから取得する。上述の通り、ECU2BがS160で第二データを作成する際には、第一データから取り出されたIDを含む第二データが作成される。そこで、S330では、ECU2Cは、第二データ中に含まれている「第一データから取り出されたID」と一致するIDを持つデータを、受信データバッファ12Aから探し出し、そのデータを処理対象となる第一データとして取得する。
続いて、ECU2Cは、S340において、受信データバッファ12Aから探し出された第一データに対し、メッセージ認証処理を実行する。このメッセージ認証処理は、図5に示した処理となる。ただし、図5に示した処理については既に詳細を説明したので、重ねての説明は省略する。S340においてメッセージ認証処理を実行する場合、図5のS210における「処理対象となるデータ」は、S330において受信データバッファ12Aから探し出された第一データである。
続いて、ECU2Cは、S350において、認証が成立したか否かを判断する。S340で認証が成立している場合は、S350においてYESと判断され、S360へと進む。ECU2Bは、S360において、第一データに含まれる通常データを取り出して、その通常データを含む第三データを作成し、第三データにCVNを付加して、ローカルバス6へ送信する。第三データであることは、第三データ中に含まれるIDによって示すことができる。
第三データに付加されるCVNは、ECU2Cにおいて生成されるCVNである。S360の実行後は図6に示す処理を終了する。一方、S340で認証に失敗している場合には、S350においてNOと判断され、S370へと進む。ECU2Bは、S370において、認証失敗を示す第四データをローカルバス6へ送信する。第四データであることは、第四データ中に含まれるIDによって示すことができる。S370の実行後は図6に示す処理を終了する。
ECU2Cにおいて上述のS360が実行された場合、第三データはブロードキャスト通信によって第二ネットワーク1Bへと送信される。そのため、ECU2Cから送信される第三データは、第二ネットワーク1BにおいてECU2C以外のノード全てに届く。ECU2Cにおいて上述のS370が実行された場合、第四データはブロードキャスト通信によって第二ネットワーク1Bへと送信される。そのため、ECU2Cから送信される第四データは、第二ネットワーク1BにおいてECU2C以外のノード全てに届く。
上述のS320において第二データではなかった場合は、S320においてNOと判断され、その場合、ECU2Cは、S380において、通常のローカルバスからのデータ受信に対応する処理を実行する。S380において実行される処理としては、ECU2Cの機能に応じた様々な処理を考え得るが、当該処理そのものは本実施形態における要部ではないので、これ以上の説明は省略する。S380の実行後は図6に示す処理を終了する。
次に、図7に示す処理について説明する。ECU2Cは、図7に示すように、S510において、グローバルバス5Bからデータを受信する。続いて、ECU2Cは、S512において、受信データを受信データバッファ12Aに保存する。S512が実行されることにより、既に説明した通り、受信データバッファ12Aには、最新の一定期間を対象にして第一ネットワーク1A経由で受信したデータが蓄積される。
続いて、ECU2Cは、S514において、受信データが他のECU宛てか否かを判断する。受信データが他のECU宛てであった場合は、S514においてYESと判断され、ECU2Cは、S516において、代行継続フラグがオンとなっているか否かを判断する。代行継続フラグがオンとなっている場合は、S516においてYESと判断され、ECU2Cは、S520において、処理対象となる第一データか否かを判断する。
ECU2Bが認証代行の依頼元装置、ECU2Cが認証代行の依頼先装置となる場合、グローバルバス5Bから受信するデータのうち、ECU2B宛てかつ認証が必要なデータが、S520でいう処理対象となる第一データに該当する。S510においてECU2Cによって受信されたデータがECU2B宛てのデータである場合、S514ではYESと判断される。
また、先に説明したS325において、代行継続フラグがオンとされた場合、S516ではYESと判断される。そして、S510においてECU2Cによって受信されたデータが、処理対象となる第一データである場合、S520ではYESと判断されて、S540へと進む。ECU2Cは、S540において、S510においてECU2Cによって受信された第一データに対し、メッセージ認証処理を実行する。
このメッセージ認証処理は、図5に示した処理となる。ただし、図5に示した処理については既に詳細を説明したので、重ねての説明は省略する。S540においてメッセージ認証処理を実行する場合、図5のS210における「処理対象となるデータ」は、S510においてECU2Cによって受信された第一データである。続いて、ECU2Cは、S550において、認証が成立したか否かを判断する。
S540で認証が成立している場合は、S550においてYESと判断され、S560へと進む。ECU2Bは、S560において、第一データに含まれる通常データを取り出して、その通常データを含む第三データを作成し、第三データにCVNを付加して、ローカルバス6へ送信する。第三データであることは、第三データ中に含まれるIDによって示すことができる。S560は、先に説明したS360と同様の処理ステップである。S560の実行後は図7に示す処理を終了する。
一方、S540で認証に失敗している場合には、S550においてNOと判断され、S570へと進む。ECU2Bは、S570において、認証失敗を示す第四データをローカルバス6へ送信する。S570は、先に説明したS370と同様の処理ステップである。S570の実行後は図7に示す処理を終了する。上述のS516において代行継続フラグがオンでない場合(すなわち、オフである場合。)は、S516においてNOと判断される。この場合は、他のECUから認証の代行を依頼されていない場合なので、S575において、受信データを破棄する。S575の実行後は図7に示す処理を終了する。
また、上述のS520において、処理対象となる第一データではなかった場合は、S520においてNOと判断される。この場合は、他のECUから認証の代行を依頼されている場合ではあるものの、処理対象となる第一データではないので、S575において、受信データを破棄する。S575の実行後は図7に示す処理を終了する。上述のS514において、受信データが他のECU宛てではない場合(すなわち、ECU2C宛てのデータである場合。)は、S514においてNOと判断され、その場合、ECU2Cは、S580において、受信データに対応する処理を実行する。S580において実行される処理としては、ECU2Cの機能に応じた様々な処理を考え得るが、当該処理そのものは本実施形態における要部ではないので、これ以上の説明は省略する。S580の実行後は図7に示す処理を終了する。
ECU2Cにおいて上述のような処理が実行されている際、ECU2Bでは図8に示す処理が実行される。ECU2Bは、図8に示すように、S410において、ローカルバス6からデータを受信する。続いて、ECU2Cは、S420において、上記S410で受信したデータが第三データか否かを判断する。ここで、第三データであることは、受信データ中に含まれるIDに基づいて判断することができる。ECU2Cにおいて上述のS360又はS560が実行された場合、第三データはブロードキャスト通信によって第二ネットワーク1Bへと送信される。そのため、第三データは第二ネットワーク1BにおいてECU2C以外のノード全てに届く。
上述のS420において第三データであった場合は、S420においてYESと判断される。その場合、ECU2Bは、S425において、なりすまし確認OKフラグがオフか否かを判断する。なりすまし確認OKフラグは、初期値がオフにされていて、後述するS430,S440においてなりすまし確認が適正に実行されると、後述するS445においてオンにされるフラグである。ここでは、なりすまし確認OKフラグが初期値(すなわち、オフ。)になっているものとして説明を続ける。
なりすまし確認OKフラグがオフになっている場合、S425においてYESと判断される。その場合、ECU2Bは、S430及びS440を実行することにより、第三データに対するなりすまし確認を実施する。具体的には、ECU2Bは、S430において、第三データに付加されたCVNを取り出す。そして、S440において、CVNが適正か否かを判断する。S440では、受信した第三データから取り出されたCVNと、CVN記憶部13Bに記憶されたCVNとを比較する。CVN記憶部13Bには、ECU2A〜2Dにおいて生成、出力されたCVNが記憶されているので、S440では、ECU2Cに対応するCVNが比較対象として選択される。
この比較の結果、両者が一致すれば、CVNは適正であり、S440においてYESと判断され、S445へと進む。S445へ進んだ場合、なりすまし確認が適正に実行されたことになり、ECU2Bは、なりすまし確認OKフラグをオンにする。そして、ECU2Bは、S450において、第三データに含まれる通常データを取り出して、以降の処理で利用する。ここでいう「以降の処理」としては、ECU2Bの機能に応じた様々な処理を考え得るが、当該処理そのものは本実施形態における要部ではないので、これ以上の説明は省略する。S450の実行後は図8に示す処理を終了する。
一方、上述のS440において、比較結果が一致しなければ、受信した第三データから取り出されたCVNが不適正である可能性が高い。この場合、ECU2C以外のノードがECU2Cになりすまして第三データを送信している可能性がある。あるいは、ECU2Cのソフトウェアが改ざんされている可能性や、ECU2Cが換装されている可能性もある。よって、このような状況下では、第三データを受信したとしても、第三データそのものの信頼性が低い。
そこで、上述のS440における比較結果が一致しなければ、CVNが不適正であり、S440においてNOと判断され、S460へと進む。S460において、ECU2Bは、受信した第三データを破棄して、フェイルセーフデータを以降の処理で利用する。フェイルセーフデータは、ECU2Bが受信する第一データや第三データに問題があって使用できない場合に、代替使用されるデータである。
このようなフェイルセーフデータは、例えばフラッシュメモリ13にあらかじめ記憶されていればよい。あるいは、第一データを過去に一定期間以上の長期にわたって受信できていた場合は、その平均値、最大値、あるいは最小値等を経時的に算出し、いつでもフェイルセーフデータとして利用できるように準備しておいてもよい。どのようなかたちでフェイルセーフデータを用意するかは、ECU2Bによる制御対象の挙動なども考慮して最適化されていればよい。S460の実行後は図8に示す処理を終了する。
図8に示す処理は、ECU2Bがローカルバス6からデータを受信するたびに、ECU2Bにおいて実行される。その際、S430−S445の処理ステップは、一回実行されていれば、以降は、毎回実行しなくても第三データは信頼できるものと考えられる。そこで、なりすまし確認OKフラグがオフではない場合(すなわち、オンである場合。)は、S425においてはNOと判断され、S430−S445を実行することなく、S450へと進む。これにより、S430−S445を実行しない分だけ、ECU2Bにかかる負荷を軽減することができる。
また、上述のS420において、上記S410で受信したデータが第三データではなかった場合は、S420においてNOと判断され、その場合、ECU2Bは、S470において、上記S410で受信したデータが第四データか否かを判断する。ここで、第四データであることは、受信データ中に含まれるIDに基づいて判断することができる。第四データであった場合は、S470においてYESと判断され、上述のS460へと進む。S460については既に説明したので、重ねての説明は省略する。S460の実行後は図8に示す処理を終了する。
上述のS470において第四データではなかった場合は、S470においてNOと判断され、その場合、ECU2Bは、S480において、第三データ及び第四データ以外の受信データに対応する処理を実行する。S480において実行される処理としては、ECU2Bの機能に応じた様々な処理を考え得るが、当該処理そのものは本実施形態における要部ではないので、これ以上の説明は省略する。S480の実行後は図8に示す処理を終了する。
[効果]
以上説明した通り、上記ネットワークシステム1によれば、ECU2Bにおいて第一データの認証に失敗した場合でも、依頼先装置となるECU2Cにおいて第一データの認証に成功すれば、依頼元装置となるECU2Bは第三データに含まれる第一データを利用することができる。したがって、例えば、ECU2Bにおいて認証処理を実行するために必要となるハードウェア又はソフトウェアに故障等の問題が生じていたとしても、ECU2Bは認証済みの第一データを利用することができる。
また、本実施形態の場合、ECU2Bは、第三データに含まれるCVNに基づいてECU2Cが信頼可能か否かを確認し、ECU2Cが信頼可能な場合に、第三データに含まれる第一データの内容に応じた処理を実行する。したがって、ECU2Cが信頼可能か否かを確認することなく、第三データに含まれる第一データの内容に応じた処理を実行する場合に比べ、システムの信頼性を向上させることができる。また、ECU2Cにおいて生成されるCVNを知らない装置が、ECU2Cになりすまして第三データを送信するのを防ぐことができる。
さらに、本実施形態の場合、依頼先装置であるECU2Cは、第二データの受信後は、第一ネットワーク1A経由で依頼元装置であるECU2B宛てに第一データが伝送されるたびに、S514−S560を実行し、第三データをECU2Bへ送信する。したがって、ECU2Bでは、第一データを受信するたびにECU2Cに対して第二データを送信しなくても、ECU2Cから第三データを継続的に受信することができる。よって、ECU2Bが第一データを受信するたびにECU2Cへ第二データを送信するように構成されている場合に比べ、ECU2Bにかかる負荷を軽減することができる。また、第二データの送信頻度が低下する分だけ、第二ネットワーク1Bにかかる負荷も低減することができる。
(2)第二実施形態
次に、第二実施形態について説明する。なお、第二実施形態は、第一実施形態で例示した構成の一部を変更しただけなので、第一実施形態との相違点を中心に詳述し、第一実施形態と同様な部分に関しては、その詳細な説明を省略する。また、第一実施形態と同等な構成に対しては、第一実施形態と同じ符号を付す。
上述の第一実施形態においては、依頼元装置となるECU2Bが、依頼先装置として一つのECU2Cを選定して、メッセージ認証の代行を依頼する例を示したが、第二実施形態においては、依頼元装置が複数の依頼先装置を選定する例について説明する。ここでは、ECU2Bが依頼元装置となり、ECU2BがECU2Aを第一依頼先装置として選定し、ECU2Cを第二依頼先装置として選定する場合を想定して説明を続ける。
ECU2Aは、ECU2Bと同じグローバルバス5Aに接続されている。ECU2Cは、ECU2Bとは異なるグローバルバス5Bに接続されている。ECU2A,2Cにおいて実行される処理は、上述の第一実施形態においてECU2Cが実行していた処理と同様の処理となる。よって、第二実施形態では、ECU2A,2Cにおいて実行される処理についての説明を省略する。以下、ECU2Bにおいて実行される処理について説明する。
[依頼元装置において実行される処理の詳細]
図9に示す処理は、ECU2Bがグローバルバス5Aからデータを受信する際にECU2Bにおいて実行される処理である。図9に示す処理は、第一実施形態では図4に示した処理と類似の処理である。ただし、図4に示す処理に含まれていたS160は、図9に示す処理ではS162に変更されている。また、図9に示す処理には、図4に示す処理には存在しないS190,S192が含まれている。
より詳しく説明すると、図4に示すS160では、一つの依頼先装置であるECU2Cに対して認証代行依頼をするためのIDを第二データに設定する。これに対し、図9に示すS162では複数の依頼先装置であるECU2A,2Cに対して認証代行依頼をするためのIDを第二データに設定する。ECU2A,2Cは、それぞれが図6に示す処理を実行する。その際、ECU2A,2Cは、それぞれがS310において第二データを受信し、S360において第三データを送信、又はS370において第四データを送信する。
また、図9のS170において代行依頼済みフラグがオンにされた場合、次に図9に示す処理が実行される際にはS116においてNOと判断される。この場合、ECU2Bは、S180において、受信データを破棄する。これは、詳しくは後述するが、ECU2Bが、S162においてECU2A,2Cに対して認証の代行を依頼した場合、以降、ECU2Bは、多くの場合、ECU2A又はECU2Cから第一データの内容を含む第三データを受け取るようになるからである。この点は第一実施形態と同様である。
ただし、第二実施形態の場合、これも詳しくは後述するが、後述するS747へと進んだ場合に限り、代行継続装置が該当無しとなり、この場合、ECU2Bは、ECU2A及びECU2Cのどちらからも第一データを受け取ることができない。そこで、この場合は、S190においてYESと判断され、ECU2Bは、S192において、フェイルセーフデータを以降の処理で利用する。フェイルセーフデータについては、第一実施形態のS460で説明したので、ここでの説明は省略する。また、ここでいう「以降の処理」としては、ECU2Bの機能に応じた様々な処理を考え得るが、当該処理そのものは本実施形態における要部ではないので、これ以上の説明は省略する。
ECU2Bでは、ローカルバス6からデータを受信する際に、図10に示す処理が実行される。ECU2Bは、図10に示すように、S610において、ローカルバス6からデータを受信する。S610では、ECU2A,2CがS360において送信した第三データ、ECU2A,2CがS370において送信した第四データ、又は第三データ及び第四データ以外のデータを受信し得る。
ECU2Bは、S620において、ローカルバス6から受信したデータが第三データ又は第四データであるか否かを判断する。第三データ又は第四データであることは、受信データ中に含まれるIDに基づいて判断することができる。S610において第三データ及び第四データ以外のデータを受信した場合、S620ではNOと判断され、ECU2Bは、S630において、第三データ及び第四データ以外の受信データに対応する処理を実行する。この場合に実行される処理としては、ECU2Bの機能に応じた様々な処理を考え得る。ただし、当該処理そのものは本実施形態における要部ではないので、図10には、第三データ又は第四データを受信する場合の処理だけを抜粋して図示する。
S610において第三データ又は第四データを受信した場合、S620ではYESと判断され、ECU2Bは、S640において、代行継続装置は未決定か否かを判断する。詳しくは後述するが、後述するS650が実行されると、代行継続装置は、ECU2A又はECU2Cのいずれかに決定される場合がある。ただし、図10に示す処理の初回実行時には、まだS650が実行されていないので、代行継続装置は未決定となっている。ここではS650が実行されていない場合を想定して、以降の説明を続ける。
代行継続装置が未決定の場合、S640ではYESと判断され、ECU2Bは、原因特定処理を実行する。原因特定処理は、詳しくは図11に示すような処理となる。図11に示す処理を開始すると、ECU2Cは、S703において、第一依頼先装置であるECU2Aにおいて認証が成立したか否かを判断する。S703では、ECU2Aから第三データを受信していれば認証成立と判断し、ECU2Aから第四データを受信していれば認証失敗と判断する。
ECU2Aにおいて認証が成立した場合、S703ではYESと判断され、ECU2Cは、S705において、第二依頼先装置であるECU2Cにおいて認証が成立したか否かを判断する。S705では、ECU2Cから第三データを受信していれば認証成立と判断し、ECU2Cから第四データを受信していれば認証失敗と判断する。ECU2Aにおいて認証に失敗した場合、S703ではNOと判断され、ECU2Cは、S707において、第二依頼先装置であるECU2Cにおいて認証が成立したか否かを判断する。S707では、ECU2Cから第三データを受信していれば認証成立と判断し、ECU2Cから第四データを受信していれば認証失敗と判断する。
S703において認証成立と判断され、かつS705において認証成立と判断された場合、ECU2B以外では障害が発生していないと考えられる。この場合、ECU2Bは、S711において、ECU2Bにおいて認証失敗となった原因は、依頼元装置であるECU2Bの鍵故障にあると推定する。すなわち、ECU2Bにおいて共通鍵記憶部13Aから適正な共通鍵を読み出すことができず、メッセージ認証処理を適正に実行することができない状況にあると推定する。
続いて、ECU2Bは、S713において、S711で推定した原因に対応するダイアグコードと故障原因の特定を行う上で有用な各種情報を、ダイアグ記憶部13Cに記憶する。続いて、ECU2Bは、S715において、第一依頼先装置であるECU2Aから受信した第三データに含まれる通常データを取り出して、以降の処理で利用する。ここでいう「以降の処理」の説明は、S192と同様の理由で省略する。
S715へ進む場合、ECU2A,2Cは、双方とも認証が成立している。よって、S715では、第二依頼先装置であるECU2Cから受信した第三データに含まれる通常データを取り出して、以降の処理で利用しても問題はない。続いて、ECU2Bは、S717において、代行継続装置を第一依頼先装置であるECU2Aに決定する。S717へ進む場合、ECU2A,2Cは、双方とも認証が成立しているので、代行継続装置を第二依頼先装置であるECU2Cに決定しても問題はない。S717の実行後は図11に示す処理を終了する。
S703において認証成立と判断され、かつS705において認証失敗と判断された場合、ECU2Bと同じグローバルバス5Aに接続されたECU2Aにおいて認証成立となったことになる。また、ECU2Bとは異なるグローバルバス5Bに接続されたECU2Cにおいて認証失敗となったことになる。この場合、ECU2Bは、S721において、グローバルバス5Aには問題がなく、ECU2Bにおいて認証失敗となった原因は、依頼元装置であるECU2Bの鍵故障にあると推定する。これに加えて、ECU2Bにおいて認証失敗となった原因は、グローバルバス5Bにおけるデータ改ざん又はデータ化けが発生している可能性があると推定する。
続いて、ECU2Bは、S723において、S721で推定した原因に対応するダイアグコードと故障原因の特定を行う上で有用な各種情報を、ダイアグ記憶部13Cに記憶する。続いて、ECU2Bは、S725において、第一依頼先装置であるECU2Aから受信した第三データに含まれる通常データを取り出して、以降の処理で利用する。ここでいう「以降の処理」の説明は、S192と同様の理由で省略する。続いて、ECU2Bは、S727において、代行継続装置を第一依頼先装置であるECU2Aに決定する。S727の実行後は図11に示す処理を終了する。
S703において認証失敗と判断され、かつS707において認証成立と判断された場合、同じグローバルバス5Aに接続されたECU2A,2Bにおいて同時に障害が発生していることになる。この場合、ECU2Bは、S731において、ECU2Bにおいて認証失敗となった原因は、グローバルバス5Aにおけるデータ改ざん又はデータ化けが発生している可能性があると推定する。
続いて、ECU2Bは、S733において、S731で推定した原因に対応するダイアグコードと故障原因の特定を行う上で有用な各種情報を、ダイアグ記憶部13Cに記憶する。続いて、ECU2Bは、S735において、第二依頼先装置であるECU2Cから受信した第三データに含まれる通常データを取り出して、以降の処理で利用する。ここでいう「以降の処理」の説明は、S192と同様の理由で省略する。続いて、ECU2Bは、S737において、代行継続装置を第二依頼先装置であるECU2Cに決定する。S737の実行後は図11に示す処理を終了する。
S703において認証失敗と判断され、かつS707において認証失敗と判断された場合、ECU2A,2B,2Cの全てにおいて認証に失敗していることになる。この場合、個々のECU2A,2B,2Cにおいて同時に障害が発生している可能性は低いので、ECU2Bは、S741において、ECU2Bにおいて認証失敗となった原因は、第一データの送信元装置であるECU3Hにおける鍵故障、又はECU3Hになりすました機器がデータ送信を行った可能性があると推定する。
続いて、ECU2Bは、S743において、S741で推定した原因に対応するダイアグコードと故障原因の特定を行う上で有用な各種情報を、ダイアグ記憶部13Cに記憶する。続いて、ECU2Bは、S745において、受信した第三データを破棄して、フェイルセーフデータを以降の処理で利用する。ここでいう「以降の処理」の説明は、S192と同様の理由で省略する。フェイルセーフデータは、ECU2Bが受信する第一データや第三データに問題があって使用できない場合に、代替使用されるデータである。
フェイルセーフデータは、例えばフラッシュメモリ13にあらかじめ記憶されていればよい。あるいは、第一データを過去に一定期間以上の長期にわたって受信できていた場合は、その平均値、最大値、あるいは最小値等を経時的に算出し、いつでもフェイルセーフデータとして利用できるように準備しておいてもよい。どのようなかたちでフェイルセーフデータを用意するかは、ECU2Bによる制御対象の挙動なども考慮して最適化されていればよい。続いて、ECU2Bは、S747において、代行継続装置を該当無しに決定する。S747の実行後は図11に示す処理を終了する。以上のようにして図11に示す処理を終了すると、図10におけるS650を終えたことになるので、ECU2Bは、図10に示す処理を終了する。
図10に示す処理は、ECU2Bがローカルバス6からデータを受信するたびに実行される。上述の通り、図10に示す処理の初回実行時には、S650が実行されていないが、図10に示す処理の2回目以降の実行時には、S650が実行され、代行継続装置は、ECU2A又はECU2Cのいずれかに決定されている場合がある。代行継続装置が決定されている場合、S640ではNOと判断され、ECU2Bは、S660において、代行継続装置からの受信データか否かを判断する。
ECU2A及びECU2Cは、図7に示す処理を実行し、S560で第三データを送信する。S660では、代行継続装置に決定されたECU2A又はECU2Cから送信された第三データである場合にYESと判断され、その場合、ECU2Bは、S670において、代行継続装置からの受信データに含まれる通常データを取り出して、以降の処理で利用する。ここでいう「以降の処理」の説明は、S192と同様の理由で省略する。S670の実行後は図10に示す処理を終了する。
一方、S660では、代行継続装置に決定されたECU2A又はECU2Cから送信された第三データではない場合にNOと判断され、その場合、ECU2Bは、S680において、受信データを破棄する。例えば、ECU2Aが代行継続装置に決定されている場合、ECU2Cは代行継続装置ではないので、ECU2Cから送信された第三データは、S680において破棄される。また、ECU2Cが代行継続装置に決定されている場合、ECU2Aは代行継続装置ではないので、ECU2Aから送信された第三データは、S680において破棄される。すなわち、S660−S680の処理ステップにより、代行継続装置からの受信データ以外はフィルタリングされる。S680の実行後は図10に示す処理を終了する。
[効果]
以上説明した通り、上記ネットワークシステム1によれば、ECU2Bにおいて第一データの認証に失敗した場合でも、第一依頼先装置又は第二依頼先装置となるECU2A,2Cのいずれかにおいて第一データの認証に成功すれば、依頼元装置となるECU2Bは第三データに含まれる第一データを利用することができる。したがって、例えば、ECU2Bにおいて認証処理を実行するために必要となるハードウェア又はソフトウェアに故障等の問題が生じていたとしても、ECU2Bは認証済みの第一データを利用することができる。
また、依頼元装置となるECU2Bにおいて第一データの認証に失敗した場合には、認証に失敗した原因が推定されて、その推定結果が故障情報として保存される。したがって、利用者は故障情報を参照して、容易に故障原因を特定でき、故障に対処することができる。
さらに、本実施形態の場合、依頼先装置であるECU2Cは、第二データの受信後は、第一ネットワーク1A経由で依頼元装置であるECU2B宛てに第一データが伝送されるたびに、S514−S560を実行し、第三データをECU2Bへ送信する。したがって、ECU2Bでは、第一データを受信するたびにECU2Cに対して第二データを送信しなくても、ECU2Cから第三データを継続的に受信することができる。よって、ECU2Bが第一データを受信するたびにECU2Cへ第二データを送信するように構成されている場合に比べ、ECU2Bにかかる負荷を軽減することができる。また、第二データの送信頻度が低下する分だけ、第二ネットワーク1Bにかかる負荷も低減することができる。
(3)他の実施形態
以上、ネットワークシステムについて、例示的な実施形態を挙げて説明したが、上述の実施形態は本開示の一態様として例示されるものにすぎない。すなわち、本開示は、上述の例示的な実施形態に限定されるものではなく、本開示の技術的思想を逸脱しない範囲内において、様々な形態で実施することができる。
例えば、上記第二実施形態では、ECU2Bが依頼元装置となり、ECU2Aが第一依頼先装置となり、ECU2Cが第二依頼先装置となる例を示したが、ECU2A〜2Dはいずれが依頼元装置となってもよい。また、ECU2A〜2Dのうち、依頼元装置以外のECUは、依頼元装置と同じグローバルバスに接続されたECUであれば、第一依頼先装置となり得る。また、依頼元装置と異なるグローバルバスに接続されたECUであれば、第二依頼先装置となり得る。さらに、ECU3A〜3Hがローカルバス6に接続されていてもよく、その場合は、ECU3A〜3Hが依頼元装置、第一依頼先装置又は第二依頼先装置となってもよい。
また、上記実施形態では、メッセージ認証による認証処理を実施する例を示したが、メッセージ認証以外の方式で認証を行ってもよいし、メッセージ認証とメッセージ認証以外の方式とを併用してもよい。例えば、上記実施形態では、通常データと暗号データとを伝送し、受信側において通常データを暗号化して、その暗号化されたデータと暗号データとを比較して認証成立か否かを判断していたが、他の認証手順を採用することもできる。一例を挙げれば、例えば、通常データと暗号データとを伝送し、受信側において暗号データを復号して、その復号されたデータと通常データとを比較して認証成立か否かを判断してもよい。
また、上記第一実施形態では、第三データを送信する際にCVNを送信することにより、受信側で第三データの送信元が適正なノードか否かを確認するようにしていたが、第三データの送信元が適正なノードか否かを確認できるような固有値を送信できれば、その固有値がCVNであるか否かは任意である。さらに、上記第一実施形態で例示した仕組み以外に、第三データの送信元が適正なノードか否かを確認可能な仕組みを別途備えている場合には、上記実施形態で例示した適正なノードか否かを確認する仕組みを省略してもよい。あるいは、第三データの送信元が適正なノードであると十分に信頼できる場合についても、上記実施形態で例示した適正なノードか否かを確認する仕組みを省略してもよい。
また、上記第一実施形態では、第三データの送信元が適正なノードか否かを一度確認したら、二回目以降は確認を省略する例を示したが、二回目以降も同様な確認を省略することなく実施してもよい。
また、上記第二実施形態では、S713,S723,S733,S743において、ダイアグコード等の故障情報をダイアグ記憶部13Cに記憶する例を示したが、このような不揮発性記憶領域に故障情報を保存する以外に、故障情報を所定の出力先へ出力してもよい。例えば、車両に搭載されたディスプレイや警告灯等の表示装置に故障情報を出力してもよい。
あるいは、車両に搭載された無線通信装置に故障情報を出力してもよい。この場合、無線通信装置は更に無線通信によって故障情報を送信し、その故障情報を受信する受信装置において故障情報の保存又は出力を行うことができる。このような受信装置は、車両の利用者が所持する無線通信端末(例えば、スマートフォンやパーソナルコンピュータ。)であってもよいし、顧客の車両の状態を自動車ディーラ等で管理している場合は、自動車ディーラ等に設置される管理装置として構成されたものであってもよい。このような管理装置を設ければ、顧客の車両において発生した故障に関する情報を容易に自動車ディーラ等で把握することができる。
また、上記第二実施形態では、複数の依頼先装置の中から一つの代行継続装置を決定して、以降は、一つの代行継続装置から第三データを受け取る例を示したが、複数の依頼先装置から並列に第三データが伝送されてくるのであれば、最も早く第三データを送信した依頼先装置から、当該第三データを受信するようにしてもよい。すなわち、一つの代行継続装置以外の依頼先装置についてもフィルタリングせず、複数の依頼先装置を適宜利用するように構成してもよい。
また、上記実施形態では、単一のCGW4によって複数のグローバルバス5A,5B,5Cを相互に接続していたが、複数のグローバルバス5A,5B,5Cを相互に接続可能に構成されていれば、複数のゲートウェイを採用してもよい。例えば、第一のゲートウェイでグローバルバス5Aとグローバルバス5Bとを接続し、第二のゲートウェイでグローバルバス5Bとグローバルバス5Cとを接続することにより、グローバルバス5Aとグローバルバス5Cは、二つのゲートウェイ及びグローバルバス5Bを介して通信可能に構成されていてもよい。
以上の他、上記各実施形態における一つの構成要素によって実現していた機能を、複数の構成要素によって実現するように構成してもよい。また、複数の構成要素によって実現していた機能を一つの構成要素によって実現するように構成してもよい。また、上記各実施形態の構成の一部を省略してもよい。また、上記各実施形態の構成の少なくとも一部を、他の上記実施形態の構成に対して付加、置換等してもよい。なお、特許請求の範囲に記載の文言から特定される技術思想に含まれる全ての態様が本開示の実施形態に該当する。
また、上述したネットワークシステムの他、本開示のネットワークシステムを構成可能な電子装置、本開示のネットワークシステムを備えた車両、本開示でいう電子装置としてコンピュータを機能させるためのプログラム、このプログラムを記録した記録媒体など、種々の形態で本開示を実現することもできる。
(4)補足
以上説明した例示的な実施形態から明らかなように、本開示のネットワークシステムは、更に以下に挙げるような構成を備えていてもよい。
まず、本開示のネットワークシステムにおいて、依頼元装置は、第三データを受信した場合に、第三データに含まれる情報に基づいて依頼先装置が信頼可能か否かを確認し(S430,S440)、依頼先装置が信頼可能な場合に、第三データに含まれる第一データを利用するように構成されていてもよい(S450)。
このように構成されたネットワークシステムによれば、依頼元装置は、依頼先装置が信頼可能な場合に、第三データに含まれる第一データの内容に応じた処理を実行する。したがって、依頼先装置が信頼可能か否かを確認することなく、第三データに含まれる第一データの内容に応じた処理を実行する場合に比べ、システムの信頼性を向上させることができる。
また、本開示のネットワークシステムにおいて、依頼元装置は、第三データに含まれる情報に基づいて依頼先装置が信頼可能であることを確認できたら、以降は、依頼先装置が信頼可能か否かの確認を行う処理ステップを省略するように構成されていてもよい(S425,S445)。
このように構成されたネットワークシステムによれば、依頼元装置は、依頼先装置が信頼可能であると確認できた場合、依頼先装置の信頼性を再確認することはない。したがって、依頼元装置が第三データを受信するたびに依頼先装置の信頼性を再確認するように構成されている場合に比べ、依頼元装置において実行される処理を簡素化し、依頼元装置にかかる負荷を軽減することができる。
また、本開示のネットワークシステムは、少なくとも一つの依頼先装置として、複数の依頼先装置(2A,2C)を含んでもよい。依頼元装置は、認証処理で認証に失敗した場合に、第二データを複数の依頼先装置へと送信するように構成されてもよい。複数の依頼先装置は、それぞれが認証処理で認証に成功した場合に、第三データを第二ネットワーク経由で依頼元装置に対して送信するように構成されてもよい。依頼元装置は、複数の依頼先装置のいずれかから第三データを受信した場合に、第三データに含まれる第一データを利用するように構成されていてもよい。
このように構成されたネットワークシステムによれば、依頼元装置は、複数の依頼先装置から第三データを受信することができる。したがって、依頼元装置が単一の依頼先装置から第三データを受信するように構成されている場合に比べ、依頼元装置が第三データを適切に受信できる可能性を高めることができ、システムの信頼性を向上させることができる。
また、本開示のネットワークシステムにおいて、複数の依頼先装置は、それぞれが認証処理で認証に失敗した場合に、認証に失敗したことを示す第四データを第二ネットワーク経由で依頼元装置に対して送信するように構成されてもよい(S370)。依頼元装置は、複数の依頼先装置それぞれから第三データ又は第四データを受信して、複数の依頼先装置それぞれが認証に成功したか否かを特定し、当該特定した結果に基づいて、代行継続装置を複数の依頼先装置のうちのいずれか一つに決定し(S650,S703−S747)、代行継続装置から第三データを受信した場合に、第三データに含まれる第一データを利用するように構成されていてもよい(S640,S660,S670)。
このように構成されたネットワークシステムによれば、依頼元装置は、複数の依頼先装置それぞれにおける認証結果も考慮して、より信頼性が高いと期待できる依頼先装置を代行継続装置として選定し、以降は、代行継続装置から第三データを受信する。したがって、複数の依頼先装置の中に認証に失敗する装置が含まれていたとしても、そのような装置を除外して第三データを受け取ることができ、システムの信頼性を向上させることができる。