JP2019125838A - ネットワークシステム - Google Patents

Abstract

【課題】データの認証に失敗した際にもデータの認証を実行可能なネットワークシステムを提供する。【解決手段】ネットワークシステム１において、依頼元装置２Ｂが外部通信路からＣＧＷ（Ｃｅｎｔｒａｌ Ｇａｔｅｗａｙ）および第一ネットワーク１Ａ経由で受信した認証対象データの認証に失敗した場合、外部とは隔離された第二ネットワーク１Ｂで接続される依頼先装置２Ｃに認証の代行を依頼する。依頼先装置２Ｃは、依頼元装置２Ｂ宛の認証対象データを受信するたびに認証処理を実行し、認証に成功した場合には、認証に成功した認証対象データの内容を含む認証済みデータを依頼元装置２Ｂへ送信する。依頼元装置２Ｂは、認証の代行を依頼した後にも、認証対象データに対する認証処理を実行し、認証が成立すれば、依頼元装置２Ｂが認証処理を実行する状態に復帰する。【選択図】図１

Description

本開示は、ネットワークシステムに関する。

セキュリティ処理ＣＰＵが故障した場合でも、セキュリティ処理ＣＰＵに代わって、汎用処理ＣＰＵが、データの暗号化、復号、認証等を実行するように構成された情報処理装置が提案されている（例えば、特許文献１参照。）。

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

しかし、上記特許文献１に記載の情報処理装置では、暗号ハードウェアにおいてセキュリティ処理ＣＰＵ以外の箇所が故障した場合には、データの認証等を実行できなくなるおそれがある。一例を挙げれば、例えば上記特許文献１に記載の情報処理装置において、セキュア記憶装置が故障した場合には、汎用処理ＣＰＵからセキュア記憶装置へのアクセスでエラーが発生し、汎用処理ＣＰＵではデータの認証等を実行できなくなるおそれがある。

本開示の一局面においては、データの認証に失敗した際に上記従来技術とは別の手法でデータの認証を実行可能なネットワークシステムを提供することが望ましい。

本開示の一態様は、ネットワークシステムである。当該ネットワークシステムは、第一ネットワーク（１Ａ）のノードとして機能し、かつ、第一ネットワークとは独立に構築される第二ネットワーク（１Ｂ）のノードとしても機能するように構成された複数の電子装置（２Ａ，２Ｂ，２Ｃ，２Ｄ）を含む。複数の電子装置は、第一ネットワーク及び第二ネットワークの外部にある外部機器とは、第一ネットワーク経由で通信可能に構成される。

複数の電子装置のうちの少なくとも一つの電子装置は、依頼元装置（２Ｂ）として機能可能に構成される。また、複数の電子装置のうちの少なくとも一つの電子装置は、依頼先装置（２Ｃ）として機能可能に構成される。複数の電子装置のうちの一つの電子装置が依頼元装置として機能する際に、依頼元装置とは別の少なくとも一つの電子装置が依頼先装置として機能可能に構成される。

依頼元装置は、認証処理の対象とされる認証対象データが第一ネットワーク経由で依頼元装置宛に伝送された場合に、認証対象データを受信して、認証対象データに対する認証処理を実行する（Ｓ１２０，Ｓ２１０−Ｓ２５０）。依頼元装置において、認証に成功した場合には、当該認証成功以降の処理において認証対象データの内容を利用する（Ｓ１４０）。依頼元装置において、認証に失敗した場合には、依頼先装置に対して認証処理の代行を依頼するための代行依頼データを、第二ネットワーク経由で依頼先装置へと送信する（Ｓ１５０，Ｓ１６０）。

依頼先装置は、代行依頼データの受信後は、第一ネットワーク経由で依頼元装置宛に認証対象データが伝送されるたびに、認証対象データを受信して（Ｓ５１０，Ｓ５１４，Ｓ５２０）認証対象データに対する認証処理を実行する（Ｓ５４０）。依頼先装置において、認証に成功した場合には、認証に成功した認証対象データの内容を含む認証済みデータを第二ネットワーク経由で依頼元装置に対して送信する（Ｓ５５０，Ｓ５６０）。

依頼元装置は、認証済みデータを受信した場合に、認証済みデータに含まれる認証対象データの内容を利用する（Ｓ４５０）。また、依頼元装置は、代行依頼データの送信後は、認証対象データを受信した場合に、認証対象データに対する認証処理を実行し、依頼元装置において認証に失敗する状態が継続しているか否かを確認する確認処理を実行する（Ｓ１８２，Ｓ６１０−Ｓ６３０）。

このように構成されたネットワークシステムによれば、依頼元装置において認証対象データの認証に失敗した場合でも、依頼先装置において認証対象データの認証に成功すれば、依頼元装置は認証済みデータに含まれる認証対象データを利用することができる。したがって、例えば、依頼元装置において認証処理を実行するために必要となるハードウェア又はソフトウェアに故障等の問題が生じていたとしても、依頼元装置は認証済みの認証対象データを利用することができる。

また、依頼先装置は、代行依頼データの受信後は、第一ネットワーク経由で依頼元装置宛に認証対象データが伝送されるたびに、認証対象データを受信して認証対象データに対する認証処理を実行して、認証済みデータを依頼元装置へ送信する。したがって、依頼元装置では、認証対象データを受信するたびに依頼先装置に対して代行依頼データを送信しなくても、依頼先装置から認証済みデータを継続的に受信することができる。よって、依頼元装置が認証対象データを受信するたびに依頼先装置へ代行依頼データを送信するように構成されている場合に比べ、依頼元装置にかかる負荷を軽減することができる。また、代行依頼データの送信頻度が低下する分だけ、ネットワークにかかる負荷も低減することができる。

さらに、依頼元装置は、代行依頼データの送信後は、認証対象データを受信した場合に、認証対象データに対する認証処理を実行し、依頼元装置において認証に失敗する状態が継続しているか否かを確認する確認処理を実行する。したがって、依頼元装置は、確認処理の結果に応じて、より適切な処理を実行することができる。例えば、確認処理の結果、依頼元装置において認証に失敗する状態が継続していれば、依頼元装置による認証の代行を継続することができる。

また、確認処理の結果、依頼元装置において認証に失敗する状態が継続していなければ、依頼元装置による認証の代行を中止することができる。あるいは、依頼元装置による認証の代行を中止してもよい状態になった旨を報知することができる。さらに、依頼元装置による認証の代行を中止してもよい状態になった旨をダイアグ情報として保存することができる。

上述の認証対象データ、代行依頼データ及び認証済みデータは、各データともに一回の伝送単位で伝送されるデータであってもよいし、複数回の伝送単位に分割されて順次伝送されるデータであってもよい。複数回の伝送単位に分割されて順次伝送される場合は、送信側から受信側へ一単位分のデータは伝送されるたびに、受信側から送信側へデータの一単位分のデータ受信を完了した旨を示すデータが伝送されてもよい。すなわち、認証対象データ、代行依頼データ及び認証済みデータの送信開始から送信完了までの間に、他のデータの伝送が行われてもよい。

なお、この欄及び特許請求の範囲に記載した括弧内の符号は、後述する実施形態において一態様として例示する具体的な構成との対応関係を理解しやすくするために記載したものである。当該記載は、本開示の技術的範囲が後述する実施形態と同一な範囲に限定されることを意味する記載ではない。

ネットワークシステムを示す説明図である。 ＥＣＵを示す説明図である。 ネットワークにおいて伝送されるデータの構造を示す説明図である。 依頼元装置となるＥＣＵがグローバルバスからデータを受信した際に実行する処理のフローチャートである。 メッセージ認証処理のフローチャートである。 復帰確認処理のフローチャートである。 依頼先装置となるＥＣＵがローカルバスからデータを受信した際に実行する処理のフローチャートである。 依頼先装置となるＥＣＵがグローバルバスからデータを受信した際に実行する処理のフローチャートである。 依頼元装置となるＥＣＵがローカルバスからデータを受信した際に実行する処理のフローチャートである。

次に、上述のネットワークシステムについて、例示的な実施形態を挙げて説明する。
［ネットワークシステムの構成］
図１に示すネットワークシステム１は、例えば自動車に搭載される車載ネットワークシステムである。ネットワークシステム１は、複数のＥＣＵ２Ａ，２Ｂ，２Ｃ，２Ｄ，３Ａ，３Ｂ，３Ｃ，３Ｄ，３Ｅ，３Ｆ，３Ｇ，３Ｈ、ＣＧＷ４、複数のグローバルバス５Ａ，５Ｂ，５Ｃ及びローカルバス６等を有する。ＥＣＵは「Electronic Control Unit」の略称である。ＣＧＷは「Central Gateway」の略称である。

ＥＣＵ３Ａ，３Ｂ，２Ａ，２Ｂは、グローバルバス５Ａに接続されている。ＥＣＵ２Ｃ，２Ｄ，３Ｃ，３Ｄは、グローバルバス５Ｂに接続されている。ＥＣＵ３Ｅ，３Ｆ，３Ｇ，３Ｈは、グローバルバス５Ｃに接続されている。各グローバルバス５Ａ〜５Ｃには、例えば、機能的に同系統に分類されるＥＣＵが接続されている。一例を挙げれば、例えば、グローバルバス５Ａにはボデー系ＥＣＵが接続される。グローバルバス５Ｂには制御系ＥＣＵが接続される。グローバルバス５Ｃには情報系ＥＣＵが接続される。

グローバルバス５Ａ〜５Ｃは、ＣＧＷ４を介して相互に接続されている。これらの構成により、ＥＣＵ２Ａ〜２Ｄ，ＥＣＵ３Ａ〜３Ｈ、ＣＧＷ４及びグローバルバス５Ａ〜５Ｃは、第一ネットワーク１Ａを構成している。ＥＣＵ２Ａ〜２Ｄは、ローカルバス６に接続されている。これにより、ＥＣＵ２Ａ〜２Ｄ及びローカルバス６は、第二ネットワーク１Ｂを構成している。すなわち、ＥＣＵ２Ａ〜２Ｄは、第一ネットワーク１Ａのノードとして機能するように構成され、かつ、第二ネットワーク１Ｂのノードとしても機能するように構成されている。このように構成されたＥＣＵ２Ａ〜２Ｄが、本開示でいう電子装置に相当する。

第一ネットワーク１Ａ及び第二ネットワーク１Ｂでは、各ネットワークを構成するノードに対してブロードキャスト通信によってデータが伝送される。ただし、第一ネットワーク１Ａと第二ネットワーク１Ｂは、互いに独立したネットワークである。そのため、例えば、第一ネットワーク１Ａにおいてデータが伝送された場合でも、そのデータが第二ネットワーク１Ｂへと伝送されることはない。同様に、第二ネットワーク１Ｂにおいてデータが伝送された場合でも、そのデータが第一ネットワーク１Ａへと伝送されることはない。

ＣＧＷ４は、グローバルバス５Ａ〜５Ｃの間に介在して、いずれか一つのグローバルバスから残りのグローバルバスへデータを中継する。また、ＣＧＷ４は、外部通信路７に接続可能に構成され、外部通信路７とグローバルバス５Ａ〜５Ｃとの間でデータを中継する。これにより、ＥＣＵ２Ａ〜２Ｄ及びＥＣＵ３Ａ〜３Ｈは、第一ネットワーク１Ａ経由で図示しない外部機器と通信可能となっている。第二ネットワーク１Ｂには、外部通信路に接続可能なノードが設けられていない。そのため、第二ネットワーク１Ｂのノードが第二ネットワーク１Ｂ経由で外部機器と通信することはできない。

外部通信路７は、無線通信路及び有線通信路のうちの少なくとも一方であればよい。また、外部通信路７は、単一の機器と接続可能な通信路及び複数の機器と接続可能な通信路のうちの少なくとも一方であればよい。複数の機器と接続可能な通信路としては、例えば複数の機器がノードとして含まれる外部ネットワークに接続可能な通信路であればよい。外部通信路７は、全部が専用線で構成されていてもよいし、一部が公衆回線で構成されていてもよい。

本実施形態では上記三つのグローバルバス５Ａ〜５Ｃを例示してあるが、グローバルバスの数は任意である。例えば、グローバルバスの数は、二つ以下又は四つ以上であってもよい。本実施形態では上記十二個のＥＣＵ２Ａ〜２Ｄ及びＥＣＵ３Ａ〜３Ｈを例示してあるが、ＥＣＵ数は任意である。例えば、ＥＣＵの数は、十一個以下又は十三個以上であってもよい。本実施形態では上記ＥＣＵ２Ａ〜２Ｄがローカルバス６に接続されている例を示したが、ＥＣＵ３Ａ〜３Ｈのうちの少なくとも一つがローカルバス６に接続されていてもよい。あるいは、ＥＣＵ３Ａ〜３Ｈのうちの少なくとも一つがローカルバス６とは別のローカルバスに接続されていてもよい。

［ＥＣＵの構成］
次に、ＥＣＵの内部構成について説明する。以下の説明では、図２に示すＥＣＵ２Ｂを例に挙げる。ただし、本実施形態において、ＥＣＵ２Ａ，２Ｃ，２Ｄは、ＥＣＵ２Ｂと同様に構成される。また、本実施形態において、ＥＣＵ３Ａ〜３Ｈは、第二ネットワーク１Ｂに接続されていない点で、ＥＣＵ２Ｂとは相違するが、その他の点はＥＣＵ２Ｂと同様に構成される。

ＥＣＵ２Ｂは、図２に示すように、ＣＰＵ１１、ＲＡＭ１２、フラッシュメモリ１３、第一通信部１６及び第二通信部１７等を有する。第一通信部１６は、グローバルバス５Ａに接続するためのネットワークインターフェースである。第二通信部１７は、ローカルバス６に接続するためのネットワークインターフェースである。ＥＣＵ２Ａ〜２Ｄの各種機能は、ＣＰＵ１１が非遷移的実体的記録媒体に格納されたプログラムに従って各種処理を実行することにより実現される。この例では、フラッシュメモリ１３が、非遷移的実体的記録媒体に該当する。

ＣＰＵ１１がプログラムに従って各種処理を実行する際には、フラッシュメモリ１３に格納されたプログラムをＲＡＭ１２によって構成されるメインメモリにロードするように構成されていてもよい。この場合、ＣＰＵ１１は、メインメモリに格納されたプログラムに従って各種処理を実行する。ＣＰＵ１１がプログラムに従って各種処理を実行することにより、プログラムに対応する方法が実行され、ＥＣＵ２Ａ〜２Ｄが備える各種機能が実現される。ただし、ＥＣＵ２Ａ〜２Ｄが備える各種機能を実現する手法はソフトウェアに限るものではなく、機能の一部又は全部を、ディジタル回路やアナログ回路等を組み合わせたハードウェアを用いて実現してもよい。

ＲＡＭ１２及びフラッシュメモリ１３には、各種記憶領域が確保される。本実施形態に関連する主要な記憶領域としては、ＲＡＭ１２には受信データバッファ１２Ａが確保される。フラッシュメモリ１３には、共通鍵記憶部１３Ａ、ＣＶＮ記憶部１３Ｂ及びダイアグ記憶部１３Ｃが確保される。受信データバッファ１２Ａは、第一ネットワーク１Ａ経由で受信したデータを一時的に蓄積するためのバッファである。

受信データバッファ１２Ａには受信したデータが順次格納され、格納領域が満杯になった場合には、最も古いデータが格納されている領域に新しいデータが上書きで格納される。受信データバッファ１２Ａのサイズは、第一ネットワーク１Ａ経由で受信するデータ量が最大となる状況を考慮して、少なくとも一定期間分（例えば２０ミリ秒分。）のデータについては確実に蓄積できる程度のサイズが確保される。

共通鍵記憶部１３Ａには、後述する処理の中で、受信データに対するメッセージ認証を実行する際に使用する共通鍵が記憶されている。ＣＶＮ記憶部１３Ｂには、後述する処理の中で、データの送信元が正当な依頼先装置か否かを確認する際に必要となるＣＶＮのリストが記憶されている。ＣＶＮは「Calibration Verification Numbers」の略称である。ＣＶＮは、ＥＣＵに実装されたソフトウェア等に基づいて生成される照合用コードである。

車両に搭載されるＥＣＵには、ＣＶＮの生成及び出力を行う機能を実装することが法令等によって義務づけられている。車両に搭載される複数のＥＣＵがＣＶＮを生成すると、ＥＣＵごとに異なるＣＶＮが生成される。本実施形態においては、ＥＣＵ２Ａ〜２Ｄにおいて生成、出力されるＣＶＮが、車両生産時に収集、リスト化されて、ＣＶＮ記憶部１３Ｂに記憶されている。

ＥＣＵに実装されたソフトウェアが更新された場合、あるいはＥＣＵに実装されたソフトウェアが改ざんされた場合には、ＥＣＵにおいて生成されるＣＶＮが変化する。したがって、車両生産時にＣＶＮ記憶部１３Ｂに記憶されたＣＶＮと、ＥＣＵから出力されたＣＶＮとを比較して、その比較結果が一致しなければ、ＣＶＮを出力したＥＣＵの換装ないしはソフトウェアの改ざん等があったのではないかと疑うことができる。ＥＣＵに実装されたソフトウェアが正当に更新される場合には、その更新後のＥＣＵから出力されるＣＶＮでＣＶＮ記憶部１３Ｂに記憶されているＣＶＮを更新すればよい。

ダイアグ記憶部１３Ｃには、ダイアグ情報が記憶される。ダイアグ情報としては、例えばＥＣＵ２Ｂにおいて故障等が検知された際に、その故障原因に対応するダイアグコードが記憶される。ダイアグ情報として、ダイアグコードに加えて、故障原因の特定を行う上で有用な各種情報が記憶されてもよい。どのような情報を記憶するかは、例えば、ダイアグコードに応じて取り決められた情報を記憶してもよいし、ダイアグコードとは無関係に取り決められた情報を記憶してもよい。

［認証処理の概要］
第一ネットワーク１Ａのノードは、外部通信路７経由で到来するデータを受信することができる。そのため、例えば外部通信路７に接続された不正な外部機器から悪意のある不正なデータが伝送され得ることも想定して、そのような不正なデータに対して適切な対処をすることが重要となる。また、ＥＣＵ２Ａ〜２Ｄ及びＥＣＵ３Ａ〜３Ｈにおいてプログラムの改ざんが行われた場合、あるいは不正なＥＣＵへの換装が行われた場合にも、そのような不正なＥＣＵから伝送される不正なデータに対し、適切な対処をすることが重要である。

そこで、本実施形態のネットワークシステム１において、ＥＣＵ２Ａ〜２Ｄ及びＥＣＵ３Ａ〜３Ｈは、第一ネットワーク１Ａ経由でデータを受信した際に認証処理を実行し、データの正当性を確認する。本実施形態において、ＥＣＵ２Ａ〜２Ｄ及びＥＣＵ３Ａ〜３Ｈは、メッセージ認証によってデータの正当性を確認する。図３に示すように、第一ネットワーク１Ａにおいて伝送されるデータＤ１には、ＩＤ、通常データ及び暗号データ等が含まれる。なお、データＤ１には、これら以外の制御コードやデータ等も含まれるが、本処理には関連しないので説明を省略する。

ＩＤは、データの種別を示す情報、データの内容を示す情報、送信元のノードを示す情報、送信先のノードを示す情報及び通信時の優先度を示す情報等、様々な情報を含み得る識別子である。送信元のノードからブロードキャスト通信によって第一ネットワーク１Ａへと送出されるデータＤ１は、第一ネットワーク１Ａにおける送信元ノード以外のノード全てにおいて受信される。データＤ１を受信したノードは、データＤ１中に含まれるＩＤに基づいて、処理対象とすべきデータか否かを判断することができる。

通常データは、送信元ノードが送信先ノードへ送信しようとしたデータの実体部分である。暗号データは、第一ネットワーク１Ａのノードが共通に使用する共通鍵を使って、所定の暗号化方式により通常データを暗号化したデータである。共通鍵は、上述の共通鍵記憶部１３Ａに記憶されている。データＤ１中に含まれる暗号データは、データＤ１を送信する送信元ノードにおいて、共通鍵を使って通常データを暗号化し、その暗号化済みのデータの一部を抽出したものである。暗号化済みのデータの一部を抽出するのはデータ量を削減するためである。データ量の削減が不要であれば、暗号化済みのデータの全部を暗号データとして利用してもよい。

以上のようなデータＤ１を受信したノードにおいて、メッセージ認証を実施する際には、データＤ１中に含まれる通常データを取り出し、取り出した通常データを送信元ノードと同様の手順で暗号化し、その暗号化済みのデータの一部を抽出する。このようにして受信側ノードで生成される暗号データは、送信元ノードと同じ共通鍵を使って生成されるので、通常は、データＤ１中に含まれる暗号データと一致する。

しかし、通常データが伝送途中で改ざんされた場合やデータ化けした場合には、受信側ノードで生成される暗号データとデータＤ１中に含まれる暗号データとが不一致となる。あるいは、共通鍵を知らない不正なノードがデータを送信した場合には、適正な暗号データを生成できないため、受信側ノードで生成される暗号データとデータＤ１中に含まれる暗号データとが不一致となる。したがって、受信側ノードでは、受信側ノードで生成される暗号データとデータＤ１中に含まれる暗号データが一致する場合には、認証が成立したと判断する。一方、受信側ノードで生成される暗号データとデータＤ１中に含まれる暗号データとが不一致となった場合には、認証に失敗したと判断する。

また、本実施形態のネットワークシステム１において、ＥＣＵ２Ａ〜２Ｄは、第二ネットワーク１Ｂ経由でデータを伝送することができる。ただし、第二ネットワーク１Ｂは、第一ネットワーク１Ａとは異なり、第二ネットワーク１Ｂの外部とは隔離されたネットワークとなっている。そのため、第一ネットワーク１Ａとは異なり、少なくとも第二ネットワーク１Ｂの外部から不正なデータが伝送されてくることはない。

そこで、ＥＣＵ２Ａ〜２Ｄは、第二ネットワーク１Ｂ経由でデータを受信した際には、第一ネットワーク１Ａの場合とは異なり、認証処理を実行しない。そのため、第二ネットワーク１Ｂにおいて伝送されるデータＤ２は、図３に示すように、ＩＤ及び通常データ等が含まれるものの、暗号データは含まれないデータとされている。

［認証代行の仕組み］
上述の認証処理において認証に成功した場合、ＥＣＵ２Ａ〜２Ｄ及びＥＣＵ３Ａ〜３Ｈは、当該認証成功以降の処理において上述のデータＤ１を利用する。具体例を挙げれば、例えば、データＤ１中から通常データが取り出され、その通常データを変数として用いた演算処理、通常データに基づく制御、通常データに応じて判断が分かれる分岐処理等が実行される。

一方、ＥＣＵ２Ａ〜２Ｄ及びＥＣＵ３Ａ〜３Ｈのうち、ＥＣＵ２Ａ〜２Ｄは、いずれかが上述の認証処理において認証に失敗した場合に、他のＥＣＵに認証の代行を依頼する。これは、データＤ１が不正なために認証に失敗したのではなく、認証処理を実行するＥＣＵの故障等が原因で認証に失敗した可能性もあるからである。認証に失敗したＥＣＵは、認証に失敗したことを契機として依頼元装置となる。

ここでは、ＥＣＵ２Ｂが認証処理において認証に失敗して依頼元装置となる場合を想定して説明を続ける。依頼元装置となったＥＣＵ２Ｂは、ＥＣＵ２Ａ，２Ｃ，２Ｄ（すなわち、依頼元装置以外のＥＣＵ。）の中から依頼先装置を選定する。ここでは、ＥＣＵ２ＢがＥＣＵ２Ｃを依頼先装置として選定した場合を想定して説明を続ける。依頼元装置となるＥＣＵ２Ｂは、依頼先装置として選定されたＥＣＵ２Ｃへ第二ネットワーク１Ｂ経由でデータを送信することにより、認証処理の代行を依頼する。

以下の説明においては、依頼元装置において第一ネットワーク１Ａ経由で受信して、認証処理の対象とされるデータＤ１のことを認証対象データと称する。また、認証処理の代行を依頼するため、依頼元装置から第二ネットワーク１Ｂ経由で依頼先装置へと伝送するデータのことを代行依頼データと称する。本実施形態の場合、代行依頼データであること、及びどのＥＣＵが依頼先装置として選定されたのかは、代行依頼データ中のＩＤによって示される。

具体的には、代行依頼データであることを示すＩＤとしては、依頼先装置として選定され得るＥＣＵ２Ａ〜２Ｄそれぞれに対応付けられた複数のＩＤが用意されている。ＥＣＵ２Ｃへ認証処理の代行を依頼する際には、ＥＣＵ２Ｃに対応するＩＤを選択し、そのＩＤを含む代行依頼データをブロードキャスト通信により第二ネットワーク１Ｂへと送出する。

ＥＣＵ２Ｃでは、代行依頼データを受信した際、そのデータ中に含まれるＩＤに基づいてＥＣＵ２Ｃが依頼先装置に選定されたことを認識し、それを契機にして依頼先装置としての処理を実行する。なお、ＥＣＵ２Ａ，２Ｄにおいても、ＥＣＵ２Ｂから送信された代行依頼データを受信する。ただし、そのデータ中に含まれるＩＤに基づいてＥＣＵ２Ａ，２Ｄでの対処が必要なデータではないと判断できるので、その判断以降の処理は実行しない。

依頼先装置となるＥＣＵ２Ｃでは、認証対象データに対してメッセージ認証による認証処理を実行する。本実施形態において、ＥＣＵ２Ｃは、上述のような受信データバッファ１２Ａを有し、第一ネットワーク１Ａ経由で受信したデータを一定期間分だけ受信データバッファ１２Ａに蓄積している。そのため、ＥＣＵ２Ｃが代行依頼データを受信した際、ＥＣＵ２Ｃは、代行依頼データ中に含まれる情報に基づいて、対象となる認証対象データを受信データバッファ１２Ａの中から探し出し、認証対象データに対する認証処理を実行する。なお、上述のような受信データバッファ１２Ａを使う代わりに、ＥＣＵ２ＢからＥＣＵ２Ｃへ認証対象データが提供されてもよい。

依頼先装置であるＥＣＵ２Ｃにおいて認証対象データに対する認証に成功した場合、ＥＣＵ２Ｃは、認証に成功した認証対象データの内容を含む認証済みデータを第二ネットワーク１Ｂ経由でＥＣＵ２Ｂに対して送信する。認証済みデータであることは、認証済みデータ中のＩＤによって示される。依頼元装置であるＥＣＵ２Ｂでは、認証済みデータを受信したことにより、依頼先装置での認証に成功したことを認識することができる。そこで、ＥＣＵ２Ｂでは、認証済みデータを受信した場合、ＥＣＵ２Ｂは認証済みデータに含まれる認証対象データを利用して、所期の処理を実行することができる。

したがって、このように構成されたネットワークシステム１によれば、ＥＣＵ２Ｂにおいて認証対象データの認証に失敗した場合でも、ＥＣＵ２Ｃにおいて認証対象データの認証に成功すれば、ＥＣＵ２Ｂは認証済みデータに含まれる認証対象データを利用することができる。よって、例えば、ＥＣＵ２Ｂにおいて認証処理を実行するために必要となるハードウェア又はソフトウェアに故障等の問題が生じていたとしても、ＥＣＵ２Ｂは認証済みの認証対象データを利用することができる。

［依頼元装置及び依頼先装置において実行される処理の詳細］
次に、上述の依頼元装置及び依頼先装置において実行される処理について、図４〜図９に示すフローチャートに基づいて説明する。上述の依頼元装置となるＥＣＵでは、図４，図５，図６及び図９に示す処理が実行される。また、依頼先装置となるＥＣＵでは、図５，図７及び図８に示す処理が実行される。ここでは、先に挙げた例と同様に、ＥＣＵ２Ｂが依頼元装置となり、ＥＣＵ２Ｃが依頼先装置として選定される場合を想定して説明を続ける。

ＥＣＵ２Ｂは、図４に示すように、Ｓ１１０において、グローバルバス５Ａからデータを受信する。続いて、ＥＣＵ２Ｂは、Ｓ１１２において、グローバルバス５Ａから受信したデータが認証対象データか否かを判断する。認証対象データは、ＥＣＵ２Ｂ，２Ｃ以外のＥＣＵがブロードキャスト通信によって第一ネットワーク１Ａへと送信したデータである。ここでは、一例として、ＥＣＵ３Ｈが認証対象データを送信したものとして、以降の説明を続ける。ＥＣＵ３Ｈが認証対象データを送信した場合、認証対象データは第一ネットワーク１ＡにおいてＥＣＵ３Ｈ以外のノード全てに届く。認証対象データを受信したノードは、認証対象データ中に含まれるＩＤに基づいて、処理対象とすべきデータか否か等を判断する。また、本実施形態の場合、少なくともＥＣＵ２Ａ〜２Ｄにおいては、認証対象データを受信したら、認証対象データを受信データバッファ１２Ａに格納する。

Ｓ１１０において受信したデータが認証対象データ以外のデータであった場合は、Ｓ１１２においてＮＯと判断され、Ｓ１１４へと進む。Ｓ１１４において、ＥＣＵ２Ｂは、認証対象データ以外の受信データに対応する処理を実行する。Ｓ１１４において実行される処理としては、ＥＣＵ２Ｂの機能に応じた様々な処理を考え得るが、当該処理そのものは本実施形態における要部ではないので、これ以上の説明は省略する。Ｓ１１４の実行後は図４に示す処理を終了する。

Ｓ１１０において受信したデータが認証対象データであった場合は、Ｓ１１２においてＹＥＳと判断され、Ｓ１１６へと進む。Ｓ１１６において、ＥＣＵ２Ｂは、代行依頼済みフラグがオフか否かを判断する。代行依頼済みフラグは、初期値がオフにされていて、後述する処理の中でＥＣＵ２Ｂが他のＥＣＵに対して認証の代行を依頼すると、後述するＳ１７０においてオンにされるフラグである。ここでは、代行依頼済みフラグが初期値（すなわち、オフ。）になっているものとして説明を続ける。

代行依頼済みフラグがオフとなっている場合は、Ｓ１１６においてＹＥＳと判断され、Ｓ１２０へと進む。Ｓ１２０において、ＥＣＵ２Ｂは、メッセージ認証処理を実行する。このメッセージ認証処理の詳細を図５に示す。メッセージ認証処理を開始すると、ＥＣＵ２Ｂは、図５に示すように、Ｓ２１０において、処理対象となるデータに含まれる通常データと暗号データを取り出す。ここでいう処理対象となるデータは、Ｓ１１０において受信した認証対象データである。

続いて、ＥＣＵ２Ｂは、Ｓ２２０において、通常データを共通鍵で暗号化し、暗号データを生成する。ここで暗号化されるデータは、Ｓ２１０において処理対象となるデータから取り出された通常データである。続いて、ＥＣＵ２Ｂは、Ｓ２３０において、受信した暗号データと生成したデータが一致するか否かを判断する。受信した暗号データと生成したデータが一致する場合は、Ｓ２３０においてＹＥＳと判断され、Ｓ２４０へと進む。

Ｓ２４０へ進んだ場合は、ＥＣＵ２Ｂにおいて認証が成立したことになり、図５に示す処理を終了して、図４のＳ１３０へと進む。一方、受信した暗号データと生成したデータが一致しない場合は、Ｓ２３０においてＮＯと判断され、Ｓ２５０へと進む。Ｓ２５０へ進んだ場合は、ＥＣＵ２Ｂにおいて認証に失敗したことになり、図５に示す処理を終了して、図４のＳ１３０へと進む。

ＥＣＵ２Ｂは、Ｓ１３０において、認証が成立したか否かを判断する。上述のＳ２４０において認証が成立している場合は、Ｓ１３０においてＹＥＳと判断され、Ｓ１４０へと進む。ＥＣＵ２Ｂは、Ｓ１４０において、認証対象データに含まれる通常データを取り出して、以降の処理で利用する。ここでいう「以降の処理」としては、ＥＣＵ２Ｂの機能に応じた様々な処理を考え得るが、当該処理そのものは本実施形態における要部ではないので、これ以上の説明は省略する。Ｓ１４０の実行後は図４に示す処理を終了する。

一方、上述のＳ２５０において認証に失敗している場合には、Ｓ１３０においてＮＯと判断され、Ｓ１５０へと進む。ＥＣＵ２Ｂは、Ｓ１５０において、認証対象データに含まれるＩＤを取り出して他の部分は破棄する。続いて、ＥＣＵ２Ｂは、Ｓ１６０において、取り出したＩＤを含む代行依頼データを作成し、一つの依頼先装置に対して認証代行依頼をするためのＩＤを代行依頼データに設定し、代行依頼データをローカルバス６へ送信する。

本実施形態においては、上述の通り、ＥＣＵ２Ｃが依頼先装置として選定される場合を想定している。そのため、Ｓ１６０では、ＥＣＵ２Ｃに対して認証代行依頼をするためのＩＤを代行依頼データに設定する。認証代行依頼をするためのＩＤとしては、依頼先装置となり得るＥＣＵごとに異なる複数のＩＤがあらかじめ用意されている。詳しくは後述するが、ＥＣＵ２Ｂが、Ｓ１６０においてＥＣＵ２Ｃに対して認証の代行を依頼した場合、以降、ＥＣＵ２Ｂは、ＥＣＵ２Ｃから認証済みデータを受け取るようになる。

Ｓ１６０を終えたら、続いて、ＥＣＵ２Ｂは、Ｓ１７０において、代行依頼済みフラグをオンにする。代行依頼済みフラグは、Ｓ１６０においてＥＣＵ２ＢがＥＣＵ２Ｃに対して認証の代行を依頼した場合に、Ｓ１７０においてオンとなる。続いて、ＥＣＵ２Ｂは、Ｓ１７２において、ダイアグ記憶処理を実行し、ダイアグ情報をダイアグ記憶部１３Ｃに記憶する。Ｓ１７２では、ＥＣＵ２Ｂにおいて認証に失敗した旨を示すダイアグコードや、認証失敗となった原因を特定する上で有用と考えられる各種周辺情報等がダイアグ記憶部１３Ｃに記憶される。Ｓ１７２の実行後は図４に示す処理を終了する。

図４に示す処理は、ＥＣＵ２Ｂがグローバルバス５Ａからデータを受信するたびに、ＥＣＵ２Ｂにおいて実行される。図４に示す処理が複数回にわたって実行される中で、ＥＣＵ２Ｂが、Ｓ１６０においてＥＣＵ２Ｃに対して認証の代行を依頼し、Ｓ１７０において代行依頼済みフラグがオンにされた場合、次に図４に示す処理が実行される際にはＳ１１６においてＮＯと判断される。この場合、ＥＣＵ２Ｂは、Ｓ１８２において、復帰確認処理を実行する。

Ｓ１８２の復帰確認処理は、詳しくは図６に示すような処理となる。図６に示す処理を開始すると、ＥＣＵ２Ｂは、Ｓ６１０において、復帰を確認するタイミングか否かを判断する。より詳しくは、Ｓ６１０では、ＥＣＵ２ＢがＥＣＵ２Ｃに認証の代行を依頼している状態から、ＥＣＵ２Ｂが自ら認証処理を実行する状態に復帰するか否かを確認するタイミングに至ったか否かを判断する。

Ｓ６１０でいう確認を行うタイミングの具体例は種々考え得る。例えば、所定時間（例えば１時間。）が経過するたびに確認を行ってもよいし、車両が所定距離を走行するたびに確認を行ってもよい。あるいは、ＥＣＵ２Ｂがグローバルバス５Ａからデータを受信した回数が所定回数となるたびに確認を行ってもよい。認証対象データの受信周期が想定できるのであれば、その受信周期の所定数倍の周期で確認を行ってもよい。

復帰を確認するタイミングであった場合、Ｓ６１０ではＹＥＳと判断され、ＥＣＵ２Ｂは、Ｓ６２０において、メッセージ認証処理を実行する。このメッセージ認証処理は、図５に示した処理となる。ただし、図５に示した処理については既に詳細を説明したので、重ねての説明は省略する。続いて、ＥＣＵ２Ｃは、Ｓ６３０において、認証が成立したか否かを判断する。

Ｓ６３０で認証が成立している場合は、Ｓ６３０においてＹＥＳと判断され、Ｓ６４０へと進む。ＥＣＵ２Ｂは、Ｓ６４０において、認証対象データに含まれる通常データを取り出して、以降の処理で利用する。ここでいう「以降の処理」としては、ＥＣＵ２Ｂの機能に応じた様々な処理を考え得るが、当該処理そのものは本実施形態における要部ではないので、これ以上の説明は省略する。

続いて、ＥＣＵ２Ｂは、Ｓ６５０において、代行処理の継続中止を要求するための中止要求データを、ローカルバス６へ送信する。中止要求データであることは、中止要求データ中に含まれるＩＤによって示すことができる。詳しくは後述するが、ＥＣＵ２Ｂが、Ｓ６５０においてＥＣＵ２Ｃに対して代行処理の継続中止を要求した場合、以降、ＥＣＵ２Ｃは、ＥＣＵ２Ｂに対する認証済みデータの送信を中止する。

次に、ＥＣＵ２Ｂは、Ｓ６６０において、代行依頼済みフラグをオフにする。続いて、ＥＣＵ２Ｂは、Ｓ６７０において、ダイアグ記憶処理を実行し、ダイアグ情報をダイアグ記憶部１３Ｃに記憶する。Ｓ６７０では、ＥＣＵ２Ｂにおいて認証処理を実行可能な状態に復帰した旨を示すダイアグコードがダイアグ記憶部１３Ｃに記憶される。Ｓ６７０の実行後は図６に示す処理を終了する。

上述のＳ６１０において、復帰を確認するタイミングではなかった場合、Ｓ６１０ではＮＯと判断され、Ｓ６８０へと進む。また、上述のＳ６３０において、認証に失敗した場合は、Ｓ６３０ではＮＯと判断され、Ｓ６８０へと進む。Ｓ６１０又はＳ６３０からＳ６８０へと進んだ場合、ＥＣＵ２Ｂは、グローバルバス５Ａから受信した受信データを破棄する。

詳しくは後述するが、ＥＣＵ２Ｂが、図４のＳ１６０においてＥＣＵ２Ｃに対して認証の代行を依頼した場合、以降、ＥＣＵ２Ｂは、ＥＣＵ２Ｃから認証済みデータを受け取るようになる。そのため、代行依頼済みフラグがオン（すなわち、図４のＳ１１６においてＮＯ。）の場合、グローバルバス５Ａから受信した認証対象データは、ＥＣＵ２Ｂにとって不要なデータとなる。よって、図６のＳ６１０において、復帰を確認するタイミングではないと判断された場合は、直ちにＳ６８０へと進み、受信した認証対象データを破棄して、図６に示す処理を終了する。

一方、図６のＳ６１０において、復帰を確認するタイミングであると判断された場合は、Ｓ６２０以降の処理ステップを実行する。ただし、認証に失敗する状態が継続していれば、Ｓ６３０においてＮＯと判断される。この場合、ＥＣＵ２Ｂは、引き続きＥＣＵ２Ｃから認証済みデータを受け取るので、グローバルバス５Ａから受信した認証対象データは、ＥＣＵ２Ｂにとって不要なデータとなる。よって、図６のＳ６３０において、認証が成立しないと判断された場合は、Ｓ６８０へと進み、受信した認証対象データを破棄して、図６に示す処理を終了する。

ＥＣＵ２Ｂにおいて上述のような処理が実行されている際、ＥＣＵ２Ｃでは図７及び図８に示す処理が実行される。図７に示す処理は、ＥＣＵ２Ｃがローカルバス６からデータを受信する際にＥＣＵ２Ｃにおいて実行される処理である。図８に示す処理は、ＥＣＵ２Ｃがグローバルバス５Ｂからデータを受信する際にＥＣＵ２Ｃにおいて実行される処理である。まず、図７に示す処理について説明する。

ＥＣＵ２Ｃは、図７に示すように、Ｓ３１０において、ローカルバス６からデータを受信する。続いて、ＥＣＵ２Ｃは、Ｓ３２０において、上記Ｓ３１０で受信したデータがＥＣＵ２Ｃ宛の代行依頼データか否かを判断する。ここで、代行依頼データであること、及びＥＣＵ２Ｃ宛てであることは、受信データ中に含まれるＩＤに基づいて判断することができる。ＥＣＵ２Ｂにおいて上述のＳ１６０が実行された場合、代行依頼データはブロードキャスト通信によって第二ネットワーク１Ｂへと送信される。そのため、代行依頼データは第二ネットワーク１ＢにおいてＥＣＵ２Ｂ以外のノード全てに届く。

ＥＣＵ２ＣにおいてＥＣＵ２Ｃ宛の代行依頼データを受信した場合、ＥＣＵ２Ｃでは、Ｓ３２０においてＹＥＳと判断されて、Ｓ３２５へと進む。Ｓ３２５において、ＥＣＵ２Ｃは、代行継続フラグをオンにする。続いて、ＥＣＵ２Ｃは、Ｓ３３０において、処理対象となる認証対象データを受信データバッファ１２Ａから取得する。上述の通り、ＥＣＵ２ＢがＳ１６０で代行依頼データを作成する際には、認証対象データから取り出されたＩＤを含む代行依頼データが作成される。そこで、Ｓ３３０では、ＥＣＵ２Ｃは、代行依頼データ中に含まれている「認証対象データから取り出されたＩＤ」と一致するＩＤを持つデータを、受信データバッファ１２Ａから探し出し、そのデータを処理対象となる認証対象データとして取得する。

続いて、ＥＣＵ２Ｃは、Ｓ３４０において、受信データバッファ１２Ａから探し出された認証対象データに対し、メッセージ認証処理を実行する。このメッセージ認証処理は、図５に示した処理となる。ただし、図５に示した処理については既に詳細を説明したので、重ねての説明は省略する。Ｓ３４０においてメッセージ認証処理を実行する場合、図５のＳ２１０における「処理対象となるデータ」は、Ｓ３３０において受信データバッファ１２Ａから探し出された認証対象データである。

続いて、ＥＣＵ２Ｃは、Ｓ３５０において、認証が成立したか否かを判断する。Ｓ３４０で認証が成立している場合は、Ｓ３５０においてＹＥＳと判断され、Ｓ３６０へと進む。ＥＣＵ２Ｂは、Ｓ３６０において、認証対象データに含まれる通常データを取り出して、その通常データを含む認証済みデータを作成し、認証済みデータにＣＶＮを付加して、ローカルバス６へ送信する。認証済みデータであることは、認証済みデータ中に含まれるＩＤによって示すことができる。

認証済みデータに付加されるＣＶＮは、ＥＣＵ２Ｃにおいて生成されるＣＶＮである。Ｓ３６０の実行後は図７に示す処理を終了する。一方、Ｓ３４０で認証に失敗している場合には、Ｓ３５０においてＮＯと判断され、Ｓ３７０へと進む。ＥＣＵ２Ｂは、Ｓ３７０において、認証失敗を示す失敗通知データをローカルバス６へ送信する。失敗通知データであることは、失敗通知データ中に含まれるＩＤによって示すことができる。Ｓ３７０の実行後は図７に示す処理を終了する。

ＥＣＵ２Ｃにおいて上述のＳ３６０が実行された場合、認証済みデータはブロードキャスト通信によって第二ネットワーク１Ｂへと送信される。そのため、ＥＣＵ２Ｃから送信される認証済みデータは、第二ネットワーク１ＢにおいてＥＣＵ２Ｃ以外のノード全てに届く。ＥＣＵ２Ｃにおいて上述のＳ３７０が実行された場合、失敗通知データはブロードキャスト通信によって第二ネットワーク１Ｂへと送信される。そのため、ＥＣＵ２Ｃから送信される失敗通知データは、第二ネットワーク１ＢにおいてＥＣＵ２Ｃ以外のノード全てに届く。

上述のＳ３２０において代行依頼データではなかった場合は、Ｓ３２０においてＮＯと判断され、その場合、ＥＣＵ２Ｃは、Ｓ３７２において、中止要求データか否かを判断する。中止要求データは、ＥＣＵ２Ｂが上述のＳ６５０を実行した際に送信するデータである。中止要求データであることは、受信データ中に含まれるＩＤに基づいて判断することができる。ＥＣＵ２Ｃが中止要求データを受信した場合、Ｓ３７２ではＹＥＳと判断され、ＥＣＵ２Ｃは、Ｓ３７４において、代行継続フラグをオフにする。Ｓ３７４の実行後は図７に示す処理を終了する。

上述のＳ３７２において中止要求データではなかった場合は、Ｓ３７２においてＮＯと判断され、その場合、ＥＣＵ２Ｃは、Ｓ３８０において、代行依頼データ及び中止要求データ以外の受信データに対応する処理を実行する。Ｓ３８０において実行される処理としては、ＥＣＵ２Ｃの機能に応じた様々な処理を考え得るが、当該処理そのものは本実施形態における要部ではないので、これ以上の説明は省略する。Ｓ３８０の実行後は図７に示す処理を終了する。

次に、図８に示す処理について説明する。ＥＣＵ２Ｃは、図８に示すように、Ｓ５１０において、グローバルバス５Ｂからデータを受信する。続いて、ＥＣＵ２Ｃは、Ｓ５１２において、受信データを受信データバッファ１２Ａに保存する。Ｓ５１２が実行されることにより、既に説明した通り、受信データバッファ１２Ａには、最新の一定期間を対象にして第一ネットワーク１Ａ経由で受信したデータが蓄積される。

続いて、ＥＣＵ２Ｃは、Ｓ５１４において、受信データが他のＥＣＵ宛か否かを判断する。受信データが他のＥＣＵ宛であった場合は、Ｓ５１４においてＹＥＳと判断され、ＥＣＵ２Ｃは、Ｓ５１６において、代行継続フラグがオンとなっているか否かを判断する。代行継続フラグがオンとなっている場合は、Ｓ５１６においてＹＥＳと判断され、ＥＣＵ２Ｃは、Ｓ５２０において、処理対象となる認証対象データか否かを判断する。

ＥＣＵ２Ｂが認証代行の依頼元装置、ＥＣＵ２Ｃが認証代行の依頼先装置となる場合、グローバルバス５Ｂから受信するデータのうち、ＥＣＵ２Ｂ宛てかつ認証が必要なデータが、Ｓ５２０でいう処理対象となる認証対象データに該当する。Ｓ５１０においてＥＣＵ２Ｃによって受信されたデータがＥＣＵ２Ｂ宛のデータである場合、Ｓ５１４ではＹＥＳと判断される。

また、先に説明したＳ３２５において、代行継続フラグがオンとされた場合、Ｓ５１６ではＹＥＳと判断される。そして、Ｓ５１０においてＥＣＵ２Ｃによって受信されたデータが、処理対象となる認証対象データである場合、Ｓ５２０ではＹＥＳと判断されて、Ｓ５４０へと進む。ＥＣＵ２Ｃは、Ｓ５４０において、Ｓ５１０においてＥＣＵ２Ｃによって受信された認証対象データに対し、メッセージ認証処理を実行する。

このメッセージ認証処理は、図５に示した処理となる。ただし、図５に示した処理については既に詳細を説明したので、重ねての説明は省略する。Ｓ５４０においてメッセージ認証処理を実行する場合、図５のＳ２１０における「処理対象となるデータ」は、Ｓ５１０においてＥＣＵ２Ｃによって受信された認証対象データである。続いて、ＥＣＵ２Ｃは、Ｓ５５０において、認証が成立したか否かを判断する。

Ｓ５４０で認証が成立している場合は、Ｓ５５０においてＹＥＳと判断され、Ｓ５６０へと進む。ＥＣＵ２Ｂは、Ｓ５６０において、認証対象データに含まれる通常データを取り出して、その通常データを含む認証済みデータを作成し、認証済みデータにＣＶＮを付加して、ローカルバス６へ送信する。認証済みデータであることは、認証済みデータ中に含まれるＩＤによって示すことができる。Ｓ５６０は、先に説明したＳ３６０と同様の処理ステップである。Ｓ５６０の実行後は図８に示す処理を終了する。

一方、Ｓ５４０で認証に失敗している場合には、Ｓ５５０においてＮＯと判断され、Ｓ５７０へと進む。ＥＣＵ２Ｂは、Ｓ５７０において、認証失敗を示す失敗通知データをローカルバス６へ送信する。Ｓ５７０は、先に説明したＳ３７０と同様の処理ステップである。Ｓ５７０の実行後は図８に示す処理を終了する。上述のＳ５１６において代行継続フラグがオンでない場合（すなわち、オフである場合。）は、Ｓ５１６においてＮＯと判断される。この場合は、他のＥＣＵから認証の代行を依頼されていない場合なので、Ｓ５７５において、受信データを破棄する。Ｓ５７５の実行後は図８に示す処理を終了する。

また、上述のＳ５２０において、処理対象となる認証対象データではなかった場合は、Ｓ５２０においてＮＯと判断される。この場合は、他のＥＣＵから認証の代行を依頼されている場合ではあるものの、処理対象となる認証対象データではないので、Ｓ５７５において、受信データを破棄する。Ｓ５７５の実行後は図８に示す処理を終了する。上述のＳ５１４において、受信データが他のＥＣＵ宛ではない場合（すなわち、ＥＣＵ２Ｃ宛のデータである場合。）は、Ｓ５１４においてＮＯと判断され、その場合、ＥＣＵ２Ｃは、Ｓ５８０において、受信データに対応する処理を実行する。Ｓ５８０において実行される処理としては、ＥＣＵ２Ｃの機能に応じた様々な処理を考え得るが、当該処理そのものは本実施形態における要部ではないので、これ以上の説明は省略する。Ｓ５８０の実行後は図８に示す処理を終了する。

ＥＣＵ２Ｃにおいて上述のような処理が実行されている際、ＥＣＵ２Ｂでは図９に示す処理が実行される。ＥＣＵ２Ｂは、図９に示すように、Ｓ４１０において、ローカルバス６からデータを受信する。続いて、ＥＣＵ２Ｃは、Ｓ４２０において、上記Ｓ４１０で受信したデータが認証済みデータか否かを判断する。ここで、認証済みデータであることは、受信データ中に含まれるＩＤに基づいて判断することができる。ＥＣＵ２Ｃにおいて上述のＳ３６０又はＳ５６０が実行された場合、認証済みデータはブロードキャスト通信によって第二ネットワーク１Ｂへと送信される。そのため、認証済みデータは第二ネットワーク１ＢにおいてＥＣＵ２Ｃ以外のノード全てに届く。

上述のＳ４２０において認証済みデータであった場合は、Ｓ４２０においてＹＥＳと判断される。その場合、ＥＣＵ２Ｂは、Ｓ４２５において、なりすまし確認ＯＫフラグがオフか否かを判断する。なりすまし確認ＯＫフラグは、初期値がオフにされていて、後述するＳ４３０，Ｓ４４０においてなりすまし確認が適正に実行されると、後述するＳ４４５においてオンにされるフラグである。ここでは、なりすまし確認ＯＫフラグが初期値（すなわち、オフ。）になっているものとして説明を続ける。

なりすまし確認ＯＫフラグがオフになっている場合、Ｓ４２５においてＹＥＳと判断される。その場合、ＥＣＵ２Ｂは、Ｓ４３０及びＳ４４０を実行することにより、認証済みデータに対するなりすまし確認を実施する。具体的には、ＥＣＵ２Ｂは、Ｓ４３０において、認証済みデータに付加されたＣＶＮを取り出す。そして、Ｓ４４０において、ＣＶＮが適正か否かを判断する。Ｓ４４０では、受信した認証済みデータから取り出されたＣＶＮと、ＣＶＮ記憶部１３Ｂに記憶されたＣＶＮとを比較する。ＣＶＮ記憶部１３Ｂには、ＥＣＵ２Ａ〜２Ｄにおいて生成、出力されたＣＶＮが記憶されているので、Ｓ４４０では、ＥＣＵ２Ｃに対応するＣＶＮが比較対象として選択される。

この比較の結果、両者が一致すれば、ＣＶＮは適正であり、Ｓ４４０においてＹＥＳと判断され、Ｓ４４５へと進む。Ｓ４４５へ進んだ場合、なりすまし確認が適正に実行されたことになり、ＥＣＵ２Ｂは、なりすまし確認ＯＫフラグをオンにする。そして、ＥＣＵ２Ｂは、Ｓ４５０において、認証済みデータに含まれる通常データを取り出して、以降の処理で利用する。ここでいう「以降の処理」としては、ＥＣＵ２Ｂの機能に応じた様々な処理を考え得るが、当該処理そのものは本実施形態における要部ではないので、これ以上の説明は省略する。Ｓ４５０の実行後は図９に示す処理を終了する。

一方、上述のＳ４４０において、比較結果が一致しなければ、受信した認証済みデータから取り出されたＣＶＮが不適正である可能性が高い。この場合、ＥＣＵ２Ｃ以外のノードがＥＣＵ２Ｃになりすまして認証済みデータを送信している可能性がある。あるいは、ＥＣＵ２Ｃのソフトウェアが改ざんされている可能性や、ＥＣＵ２Ｃが換装されている可能性もある。よって、このような状況下では、認証済みデータを受信したとしても、認証済みデータそのものの信頼性が低い。

そこで、上述のＳ４４０における比較結果が一致しなければ、ＣＶＮが不適正であり、Ｓ４４０においてＮＯと判断され、Ｓ４６０へと進む。Ｓ４６０において、ＥＣＵ２Ｂは、受信した認証済みデータを破棄して、フェイルセーフデータを以降の処理で利用する。フェイルセーフデータは、ＥＣＵ２Ｂが受信する認証対象データや認証済みデータに問題があって使用できない場合に、代替使用されるデータである。

このようなフェイルセーフデータは、例えばフラッシュメモリ１３にあらかじめ記憶されていればよい。あるいは、認証対象データを過去に一定期間以上の長期にわたって受信できていた場合は、その平均値、最大値、あるいは最小値等を経時的に算出し、いつでもフェイルセーフデータとして利用できるように準備しておいてもよい。どのようなかたちでフェイルセーフデータを用意するかは、ＥＣＵ２Ｂによる制御対象の挙動なども考慮して最適化されていればよい。Ｓ４６０の実行後は図９に示す処理を終了する。

図９に示す処理は、ＥＣＵ２Ｂがローカルバス６からデータを受信するたびに、ＥＣＵ２Ｂにおいて実行される。その際、Ｓ４３０−Ｓ４４５の処理ステップは、一回実行されていれば、以降は、毎回実行しなくても認証済みデータは信頼できるものと考えられる。そこで、なりすまし確認ＯＫフラグがオフではない場合（すなわち、オンである場合。）は、Ｓ４２５においてはＮＯと判断され、Ｓ４３０−Ｓ４４５を実行することなく、Ｓ４５０へと進む。これにより、Ｓ４３０−Ｓ４４５を実行しない分だけ、ＥＣＵ２Ｂにかかる負荷を軽減することができる。

また、上述のＳ４２０において、上記Ｓ４１０で受信したデータが認証済みデータではなかった場合は、Ｓ４２０においてＮＯと判断され、その場合、ＥＣＵ２Ｃは、Ｓ４７０において、上記Ｓ４１０で受信したデータが失敗通知データか否かを判断する。ここで、失敗通知データであることは、受信データ中に含まれるＩＤに基づいて判断することができる。失敗通知データであった場合は、Ｓ４７０においてＹＥＳと判断され、上述のＳ４６０へと進む。Ｓ４６０については既に説明したので、重ねての説明は省略する。Ｓ４６０の実行後は図９に示す処理を終了する。

上述のＳ４７０において失敗通知データではなかった場合は、Ｓ４７０においてＮＯと判断され、その場合、ＥＣＵ２Ｂは、Ｓ４８０において、認証済みデータ及び失敗通知データ以外の受信データに対応する処理を実行する。Ｓ４８０において実行される処理としては、ＥＣＵ２Ｂの機能に応じた様々な処理を考え得るが、当該処理そのものは本実施形態における要部ではないので、これ以上の説明は省略する。Ｓ４８０の実行後は図９に示す処理を終了する。

［効果］
以上説明した通り、上記ネットワークシステム１によれば、ＥＣＵ２Ｂにおいて認証対象データの認証に失敗した場合でも、依頼先装置となるＥＣＵ２Ｃにおいて認証対象データの認証に成功すれば、依頼元装置となるＥＣＵ２Ｂは認証済みデータに含まれる認証対象データの内容を利用することができる。したがって、例えば、ＥＣＵ２Ｂにおいて認証処理を実行するために必要となるハードウェア又はソフトウェアに故障等の問題が生じていたとしても、ＥＣＵ２ＢはＥＣＵ２Ｃにおいて認証された認証対象データの内容を利用して、所期の処理を実行することができる。

また、本実施形態の場合、依頼先装置であるＥＣＵ２Ｃは、代行依頼データの受信後は、Ｓ３２５において代行継続フラグをオンにする。これ以降、ＥＣＵ２Ｃは、第一ネットワーク１Ａ経由で依頼元装置であるＥＣＵ２Ｂ宛に認証対象データが伝送されるたびに、Ｓ５１４−Ｓ５６０を実行し、認証済みデータをＥＣＵ２Ｂへ送信する。したがって、ＥＣＵ２Ｂでは、認証対象データを受信するたびにＥＣＵ２Ｃに対して代行依頼データを送信しなくても、ＥＣＵ２Ｃから認証済みデータを継続的に受信することができる。よって、ＥＣＵ２Ｂが認証対象データを受信するたびにＥＣＵ２Ｃへ代行依頼データを送信するように構成されている場合に比べ、ＥＣＵ２Ｂにかかる負荷を軽減することができる。また、代行依頼データの送信頻度が低下する分だけ、第二ネットワーク１Ｂにかかる負荷も低減することができる。

また、本実施形態の場合、ＥＣＵ２Ｂは、代行依頼データの送信後は、認証対象データを受信した場合に、Ｓ６２０において認証対象データに対する認証処理を実行し、ＥＣＵ２Ｂにおいて認証に失敗する状態が継続しているか否かを確認する確認処理（すなわち、Ｓ６１０−Ｓ６３０。）を実行する。したがって、ＥＣＵ２Ｂは、確認処理の結果に応じて、より適切な処理を実行することができる。

具体的には、上述の通り、ＥＣＵ２Ｂにおいて認証に失敗する状態が継続していれば、Ｓ６３０においてＮＯとなり、ＥＣＵ２Ｃによる認証の代行を継続することができる。また、ＥＣＵ２Ｂにおいて認証に失敗する状態が継続していなければ、Ｓ６３０においてＹＥＳとなり、Ｓ６５０を実行して、ＥＣＵ２Ｃによる認証の代行を中止することができる。

あるいは、ＥＣＵ２Ｃによる認証の代行を中止してもよい状態になった旨を、Ｓ６７０により、ダイアグ情報として保存することができる。本実施形態の場合、ＥＣＵ２Ｂが代行依頼を開始する際にも、Ｓ１７２により、ダイアグ情報を保存する。したがって、ＥＣＵ２Ｂが、いつ代行依頼を開始し、その後、いつ代行依頼を中止して通常の状態に復帰したのかを、ダイアグ情報に基づいて事後的に知ることができる。

［他の実施形態］
以上、ネットワークシステムについて、例示的な実施形態を挙げて説明したが、上述の実施形態は本開示の一態様として例示されるものにすぎない。すなわち、本開示は、上述の例示的な実施形態に限定されるものではなく、本開示の技術的思想を逸脱しない範囲内において、様々な形態で実施することができる。

例えば、上記実施形態では、ＥＣＵ２Ｂが依頼元装置となり、ＥＣＵ２Ｃが依頼先装置となる例を示したが、ＥＣＵ２Ａ〜２Ｄはいずれが依頼元装置となってもよい。また、ＥＣＵ２Ａ〜２Ｄのうち、依頼元装置以外のＥＣＵは、いずれが依頼先装置となってもよい。さらに、ＥＣＵ３Ａ〜３Ｈがローカルバス６に接続されていてもよく、その場合は、ＥＣＵ３Ａ〜３Ｈが依頼元装置又は依頼先装置となってもよい。

また、上記実施形態では、メッセージ認証による認証処理を実施する例を示したが、メッセージ認証以外の方式で認証を行ってもよいし、メッセージ認証とメッセージ認証以外の方式とを併用してもよい。例えば、上記実施形態では、通常データと暗号データとを伝送し、受信側において通常データを暗号化して、その暗号化されたデータと暗号データとを比較して認証成立か否かを判断していたが、他の認証手順を採用することもできる。一例を挙げれば、例えば、通常データと暗号データとを伝送し、受信側において暗号データを復号して、その復号されたデータと通常データとを比較して認証成立か否かを判断してもよい。

また、上記実施形態では、認証済みデータを送信する際にＣＶＮを送信することにより、受信側で認証済みデータの送信元が適正なノードか否かを確認するようにしていたが、認証済みデータの送信元が適正なノードか否かを確認できるような固有値を送信できれば、その固有値がＣＶＮであるか否かは任意である。さらに、上記実施形態で例示した仕組み以外に、認証済みデータの送信元が適正なノードか否かを確認可能な仕組みを別途備えている場合には、上記実施形態で例示した適正なノードか否かを確認する仕組みを省略してもよい。あるいは、認証済みデータの送信元が適正なノードであると十分に信頼できる場合についても、上記実施形態で例示した適正なノードか否かを確認する仕組みを省略してもよい。

また、上記実施形態では、認証済みデータの送信元が適正なノードか否かを一度確認したら、二回目以降は確認を省略する例を示したが、二回目以降も同様な確認を省略することなく実施してもよい。

また、上記実施形態では、Ｓ１７２，Ｓ６７０において、ダイアグ情報をダイアグ記憶部１３Ｃに記憶する例を示したが、このような不揮発性記憶領域にダイアグ情報を保存する以外に、ダイアグ情報を所定の出力先へ出力してもよい。例えば、車両に搭載されたディスプレイや警告灯等の表示装置にダイアグ情報を出力してもよい。

あるいは、車両に搭載された無線通信装置にダイアグ情報を出力してもよい。この場合、無線通信装置は更に無線通信によってダイアグ情報を送信し、そのダイアグ情報を受信する受信装置においてダイアグ情報の保存又は出力を行うことができる。このような受信装置は、車両の利用者が所持する無線通信端末（例えば、スマートフォンやパーソナルコンピュータ。）であってもよいし、顧客の車両の状態を自動車ディーラ等で管理している場合は、自動車ディーラ等に設置される管理装置として構成されたものであってもよい。このような管理装置を設ければ、顧客の車両において発生した事象を容易に自動車ディーラ等で把握することができる。

また、上記実施形態では、単一のＣＧＷ４によって複数のグローバルバス５Ａ，５Ｂ，５Ｃを相互に接続していたが、複数のグローバルバス５Ａ，５Ｂ，５Ｃを相互に接続可能に構成されていれば、複数のゲートウェイを採用してもよい。例えば、第一のゲートウェイでグローバルバス５Ａとグローバルバス５Ｂとを接続し、第二のゲートウェイでグローバルバス５Ｂとグローバルバス５Ｃとを接続することにより、グローバルバス５Ａとグローバルバス５Ｃは、二つのゲートウェイ及びグローバルバス５Ｂを介して通信可能に構成されていてもよい。

以上の他、上記各実施形態における一つの構成要素によって実現していた機能を、複数の構成要素によって実現するように構成してもよい。また、複数の構成要素によって実現していた機能を一つの構成要素によって実現するように構成してもよい。また、上記各実施形態の構成の一部を省略してもよい。また、上記各実施形態の構成の少なくとも一部を、他の上記実施形態の構成に対して付加、置換等してもよい。なお、特許請求の範囲に記載の文言から特定される技術思想に含まれる全ての態様が本開示の実施形態に該当する。

また、上述したネットワークシステムの他、本開示のネットワークシステムを構成可能な電子装置、本開示のネットワークシステムを備えた車両、本開示でいう電子装置としてコンピュータを機能させるためのプログラム、このプログラムを記録した記録媒体など、種々の形態で本開示を実現することもできる。

［補足］
以上説明した例示的な実施形態から明らかなように、本開示のネットワークシステムは、更に以下に挙げるような構成を備えていてもよい。

本開示の一態様では、依頼元装置は、代行依頼データの送信後は、認証対象データを受信する頻度よりも低い頻度で、認証処理及び確認処理を実行するように構成されていてもよい（Ｓ６１０−Ｓ６３０）。

本開示の一態様では、依頼元装置は、認証処理において認証に失敗した場合に、認証に失敗したことを示す情報を保存又は出力するように構成されていてもよい（Ｓ１７２）。
本開示の一態様では、依頼元装置は、確認処理により、依頼元装置において認証に失敗する状態が継続していないことを確認できたら、依頼先装置に対して認証処理の代行中止を要求するための中止要求データを、第二ネットワーク経由で依頼先装置へと送信するように構成されてもよい（Ｓ６５０）。依頼元装置は、中止要求データの送信後は、認証対象データを受信した場合に、認証処理を実行する状態に復帰するように構成されていてもよい（Ｓ６６０）。

本開示の一態様では、依頼元装置は、認証処理を実行する状態に復帰した場合に、復帰したことを示す情報を保存又は出力するように構成されていてもよい（Ｓ６７０）。

１…ネットワークシステム、１Ａ…第一ネットワーク、１Ｂ…第二ネットワーク、２Ａ，２Ｂ，２Ｃ，２Ｄ，３Ａ，３Ｂ，３Ｃ，３Ｄ，３Ｅ，３Ｆ，３Ｇ，３Ｈ…ＥＣＵ、５Ａ，５Ｂ，５Ｃ…グローバルバス、６…ローカルバス、７…外部通信路、１１…ＣＰＵ、１２…ＲＡＭ、１２Ａ…受信データバッファ、１３…フラッシュメモリ、１３Ａ…共通鍵記憶部、１３Ｂ…ＣＶＮ記憶部、１３Ｃ…ダイアグ記憶部、１６…第一通信部、１７…第二通信部。

Claims (5)

1. 第一ネットワーク（１Ａ）のノードとして機能し、かつ、前記第一ネットワークとは独立に構築される第二ネットワーク（１Ｂ）のノードとしても機能するように構成された複数の電子装置（２Ａ，２Ｂ，２Ｃ，２Ｄ）を含み、
   前記複数の電子装置は、前記第一ネットワーク及び前記第二ネットワークの外部にある外部機器とは、前記第一ネットワーク経由で通信可能に構成され、
   前記複数の電子装置のうちの少なくとも一つの電子装置は、依頼元装置（２Ｂ）として機能可能に構成され、
   前記複数の電子装置のうちの少なくとも一つの電子装置は、依頼先装置（２Ｃ）として機能可能に構成され、
   前記複数の電子装置のうちの一つの電子装置が前記依頼元装置として機能する際に、前記依頼元装置とは別の少なくとも一つの電子装置が前記依頼先装置として機能可能に構成され、
   前記依頼元装置は、認証処理の対象とされる認証対象データが前記第一ネットワーク経由で前記依頼元装置宛に伝送された場合に、前記認証対象データを受信して、前記認証対象データに対する認証処理を実行し（Ｓ１２０，Ｓ２１０−Ｓ２５０）、認証に成功した場合には、当該認証成功以降の処理において前記認証対象データの内容を利用し（Ｓ１４０）、認証に失敗した場合には、前記依頼先装置に対して認証処理の代行を依頼するための代行依頼データを、前記第二ネットワーク経由で前記依頼先装置へと送信するように構成され（Ｓ１５０，Ｓ１６０）、
   前記依頼先装置は、前記代行依頼データの受信後は、前記第一ネットワーク経由で前記依頼元装置宛に前記認証対象データが伝送されるたびに、前記認証対象データを受信して（Ｓ５１０，Ｓ５１４，Ｓ５２０）前記認証対象データに対する認証処理を実行し（Ｓ５４０）、認証に成功した場合には、認証に成功した前記認証対象データの内容を含む認証済みデータを前記第二ネットワーク経由で前記依頼元装置に対して送信するように構成され（Ｓ５５０，Ｓ５６０）、
   前記依頼元装置は、前記認証済みデータを受信した場合に、前記認証済みデータに含まれる前記認証対象データの内容を利用するように構成され（Ｓ４５０）、
   前記依頼元装置は、前記代行依頼データの送信後は、前記認証対象データを受信した場合に、前記認証対象データに対する認証処理を実行し、前記依頼元装置において認証に失敗する状態が継続しているか否かを確認する確認処理を実行するように構成されている（Ｓ１８２，Ｓ６１０−Ｓ６３０）
   ネットワークシステム。
2. 請求項１に記載のネットワークシステムであって、
   前記依頼元装置は、前記代行依頼データの送信後は、前記認証対象データを受信する頻度よりも低い頻度で、前記認証処理及び前記確認処理を実行するように構成されている（Ｓ６１０）
   ネットワークシステム。
3. 請求項１又は請求項２に記載のネットワークシステムであって、
   前記依頼元装置は、前記認証処理において認証に失敗した場合に、認証に失敗したことを示す情報を保存又は出力するように構成されている（Ｓ１７２）
   ネットワークシステム。
4. 請求項１から請求項３までのいずれか一項に記載のネットワークシステムであって、
   前記依頼元装置は、前記確認処理により、前記依頼元装置において認証に失敗する状態が継続していないことを確認できたら、前記依頼先装置に対して認証処理の代行中止を要求するための中止要求データを、前記第二ネットワーク経由で前記依頼先装置へと送信するように構成され（Ｓ６５０）、
   前記依頼元装置は、前記中止要求データの送信後は、前記認証対象データを受信した場合に、前記認証処理を実行する状態に復帰するように構成されている（Ｓ６６０）
   ネットワークシステム。
5. 請求項４に記載のネットワークシステムであって、
   前記依頼元装置は、前記認証処理を実行する状態に復帰した場合に、復帰したことを示す情報を保存又は出力するように構成されている（Ｓ６７０）
   ネットワークシステム。

Images