(57)【要約】【課題】データの認証に失敗した際に従来技術とは別の手法でデータの認証を実行可能なネットワークシステムを提供すること。【解決手段】ネットワークシステム（１）において、依頼元装置（２Ｂ）が認証対象データの認証に失敗した場合、依頼先装置（２Ｃ）に認証の代行を依頼する。依頼先装置は、依頼元装置宛の認証対象データを受信するたびに認証処理を実行し、認証に成功した場合には、認証に成功した認証対象データの内容を含む認証済みデータを依頼元装置へ送信する。依頼元装置は、外部機器から代行中止要求データが送信された際に、依頼状態から非依頼状態に復帰する。依頼先装置は、外部機器から代行中止要求データが送信された際に、代行状態から非代行状態に復帰する。【選択図】図１
2019161259.tif 000002
【特許請求の範囲】
【請求項１】
第一ネットワーク（１Ａ）のノードとして機能し、かつ、前記第一ネットワークとは独立に構築される第二ネットワーク（１Ｂ）のノードとしても機能するように構成された複数の電子装置（２Ａ，２Ｂ，２Ｃ，２Ｄ）を含み、
前記複数の電子装置は、前記第一ネットワーク及び前記第二ネットワークの外部にある外部機器とは、前記第一ネットワーク経由で通信可能に構成され、
前記複数の電子装置のうちの少なくとも一つの電子装置は、依頼元装置（２Ｂ）として機能可能に構成され、
前記複数の電子装置のうちの少なくとも一つの電子装置は、依頼先装置（２Ｃ）として機能可能に構成され、
前記複数の電子装置のうちの一つの電子装置が前記依頼元装置として機能する際に、前記依頼元装置とは別の少なくとも一つの電子装置が前記依頼先装置として機能可能に構成され、
前記依頼元装置は、認証処理の対象とされる認証対象データが前記第一ネットワーク経由で前記依頼元装置宛に伝送された場合に、前記認証対象データを受信して、前記認証対象データに対する認証処理を実行し（Ｓ１２４，Ｓ１４２−Ｓ１５０）、認証に成功した場合には、当該認証成功以降の処理において前記認証対象データの内容を利用し（Ｓ１２８）、認証に失敗した場合には、前記依頼先装置に対して認証処理の代行を依頼するための代行依頼データを、前記第二ネットワーク経由で前記依頼先装置へと送信して、非依頼状態から依頼状態に移行するように構成され（Ｓ１３０−Ｓ１３４）、
前記依頼先装置は、前記代行依頼データの受信後は、非代行状態から代行状態に移行して（Ｓ２０４−Ｓ２０６，Ｓ２２２）、前記第一ネットワーク経由で前記依頼元装置宛に前記認証対象データが伝送されるたびに、前記認証対象データを受信して（Ｓ３０２，Ｓ３０６，Ｓ３０８，Ｓ３２２，Ｓ３２４）前記認証対象データに対する認証処理を実行し（Ｓ３２６）、認証に成功した場合には、認証に成功した前記認証対象データの内容を含む認証済みデータを前記第二ネットワーク経由で前記依頼元装置に対して送信するように構成され（Ｓ３２８，Ｓ３３０）、
前記依頼元装置は、前記依頼状態へ移行した際には、前記認証済みデータを受信して（Ｓ４０２）、前記認証済みデータに含まれる前記認証対象データの内容を利用するように構成され（Ｓ４０６，Ｓ４３０）、
前記依頼元装置は、前記外部機器から代行中止要求データが送信された際に（Ｓ１０８）、前記依頼状態にある場合には、前記依頼状態から前記非依頼状態に復帰するように構成され（Ｓ１１０，Ｓ１６６，Ｓ１７２，Ｓ４１２，Ｓ４１４，Ｓ４４２，Ｓ４４６，Ｓ４４８）、
前記依頼先装置は、前記外部機器から代行中止要求データが送信された際に（Ｓ２０８）、前記代行状態にある場合には、前記代行状態から前記非代行状態に復帰するように構成されている（Ｓ２１０，Ｓ２４２−Ｓ２４８）
ネットワークシステム。
【請求項２】
請求項１に記載のネットワークシステムであって、
前記依頼元装置は、前記外部機器から送信された前記代行中止要求データを受信した際に（Ｓ１１０，Ｓ１０８）、前記代行中止要求データに対する認証処理を実行するように構成されている（Ｓ１１０，Ｓ１６２）
ネットワークシステム。
【請求項３】
請求項２に記載のネットワークシステムであって、
前記依頼元装置は、前記代行中止要求データに対する認証処理の結果を、前記依頼先装置へ送信するように構成されている（Ｓ１７２）
ネットワークシステム。
【請求項４】
請求項３に記載のネットワークシステムであって、
前記依頼先装置は、前記代行中止要求データに対する認証処理の結果を前記依頼元装置から受信した場合に（Ｓ２０２，Ｓ２０８）、前記代行状態から前記非代行状態に復帰するように構成されている（Ｓ２１０，Ｓ２４２−Ｓ２４８）
ネットワークシステム。
【請求項５】
請求項１から請求項４までのいずれか一項に記載のネットワークシステムであって、
前記依頼先装置は、前記外部機器から前記代行中止要求データが送信された際に、前記第一ネットワーク経由で前記代行中止要求データを受信した場合に（Ｓ３０２，Ｓ３４２）、前記代行状態から前記非代行状態に復帰するように構成されている（Ｓ３４４，Ｓ３５２−Ｓ３５８）
ネットワークシステム。
【請求項６】
請求項１から請求項５までのいずれか一項に記載のネットワークシステムであって、
前記依頼元装置は、前記外部機器から前記代行中止要求データが送信された後、前記依頼状態にあるのか前記非依頼状態にあるのかを前記外部機器に対して通知するように構成されている（Ｓ４４４）
ネットワークシステム。
【請求項７】
請求項１から請求項６までのいずれか一項に記載のネットワークシステムであって、
前記依頼先装置は、前記外部機器から前記代行中止要求データが送信された後、前記代行状態にあるのか前記非代行状態にあるのかを前記外部機器に対して通知するように構成されている（Ｓ２５４）
ネットワークシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、ネットワークシステムに関する。
【背景技術】
【０００２】
セキュリティ処理ＣＰＵが故障した場合でも、セキュリティ処理ＣＰＵに代わって、汎用処理ＣＰＵが、データの暗号化、復号、認証等を実行するように構成された情報処理装置が提案されている（例えば、特許文献１参照。）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１５−１１９３５７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、上記特許文献１に記載の情報処理装置では、暗号ハードウェアにおいてセキュリティ処理ＣＰＵ以外の箇所が故障した場合には、データの認証等を実行できなくなるおそれがある。一例を挙げれば、例えば上記特許文献１に記載の情報処理装置において、セキュア記憶装置が故障した場合には、汎用処理ＣＰＵからセキュア記憶装置へのアクセスでエラーが発生し、汎用処理ＣＰＵではデータの認証等を実行できなくなるおそれがある。
【０００５】
本開示の一局面においては、データの認証に失敗した際に上記従来技術とは別の手法でデータの認証を実行可能なネットワークシステムを提供することが望ましい。
【課題を解決するための手段】
【０００６】
本開示の一態様は、ネットワークシステムである。当該ネットワークシステムは、複数の電子装置（２Ａ，２Ｂ，２Ｃ，２Ｄ）を含む。複数の電子装置は、第一ネットワーク（１Ａ）のノードとして機能し、かつ、第一ネットワークとは独立に構築される第二ネットワーク（１Ｂ）のノードとしても機能するように構成される。複数の電子装置は、第一ネットワーク及び第二ネットワークの外部にある外部機器とは、第一ネットワーク経由で通信可能に構成される。
【０００７】
複数の電子装置のうちの少なくとも一つの電子装置は、依頼元装置（２Ｂ）として機能可能に構成される。複数の電子装置のうちの少なくとも一つの電子装置は、依頼先装置（２Ｃ）として機能可能に構成される。複数の電子装置のうちの一つの電子装置が依頼元装置として機能する際に、依頼元装置とは別の少なくとも一つの電子装置が依頼先装置として機能可能に構成される。
【０００８】
依頼元装置は、認証処理の対象とされる認証対象データが第一ネットワーク経由で依頼元装置宛に伝送された場合に、認証対象データを受信して、認証対象データに対する認証処理を実行する（Ｓ１２４，Ｓ１４２−Ｓ１５０）。依頼元装置は、認証に成功した場合には、当該認証成功以降の処理において認証対象データの内容を利用する（Ｓ１２８）。依頼元装置は、認証に失敗した場合には、依頼先装置に対して認証処理の代行を依頼するための代行依頼データを、第二ネットワーク経由で依頼先装置へと送信して、非依頼状態から依頼状態に移行するように構成される（Ｓ１３０−Ｓ１３４）。
【０００９】
依頼先装置は、代行依頼データの受信後は、非代行状態から代行状態に移行して（Ｓ２０４−Ｓ２０６，Ｓ２２２）、第一ネットワーク経由で依頼元装置宛に認証対象データが伝送されるたびに、認証対象データを受信して（Ｓ３０２，Ｓ３０６，Ｓ３０８，Ｓ３２２，Ｓ３２４）認証対象データに対する認証処理を実行する（Ｓ３２６）。依頼先装置は、認証に成功した場合には、認証に成功した認証対象データの内容を含む認証済みデータを第二ネットワーク経由で依頼元装置に対して送信するように構成される（Ｓ３２８，Ｓ３３０）。依頼元装置は、依頼状態へ移行した際には、認証済みデータを受信して（Ｓ４０２）、認証済みデータに含まれる認証対象データの内容を利用するように構成される（Ｓ４０６，Ｓ４３０）。
【００１０】
依頼元装置は、外部機器から代行中止要求データが送信された際に（Ｓ１０８）、依頼状態にある場合には、依頼状態から非依頼状態に復帰するように構成される（Ｓ１１０，Ｓ１６６，Ｓ１７２，Ｓ４１２，Ｓ４１４，Ｓ４４２，Ｓ４４６，Ｓ４４８）。依頼先装置は、外部機器から代行中止要求データが送信された際に（Ｓ２０８）、代行状態にある場合には、代行状態から非代行状態に復帰するように構成されている（Ｓ２１０，Ｓ２４２−Ｓ２４８）。
【００１１】
このように構成されたネットワークシステムによれば、依頼元装置において認証対象データの認証に失敗した場合でも、依頼先装置において認証対象データの認証に成功すれば、依頼元装置は認証済みデータに含まれる認証対象データを利用することができる。したがって、例えば、依頼元装置において認証処理を実行するために必要となるハードウェア又はソフトウェアに故障等の問題が生じていたとしても、依頼元装置は認証済みの認証対象データを利用することができる。
【００１２】
また、依頼先装置は、代行依頼データの受信後は、第一ネットワーク経由で依頼元装置宛に認証対象データが伝送されるたびに、認証対象データを受信して認証対象データに対する認証処理を実行して、認証済みデータを依頼元装置へ送信する。したがって、依頼元装置では、認証対象データを受信するたびに依頼先装置に対して代行依頼データを送信しなくても、依頼先装置から認証済みデータを継続的に受信することができる。よって、依頼元装置が認証対象データを受信するたびに依頼先装置へ代行依頼データを送信するように構成されている場合に比べ、依頼元装置にかかる負荷を軽減することができる。また、代行依頼データの送信頻度が低下する分だけ、ネットワークにかかる負荷も低減することができる。
【００１３】
さらに、依頼元装置は、外部機器から代行中止要求データが送信された際に、依頼状態にある場合には、依頼状態から非依頼状態に復帰する。依頼先装置は、外部機器から代行中止要求データが送信された際に、代行状態にある場合には、代行状態から非代行状態に復帰する。したがって、認証処理の代行が必要となっていた原因が修理等によって解消された際には、外部機器から代行中止要求データを送信することにより、依頼元装置及び依頼先装置を容易に通常の状態に戻すことができる。これにより、電子装置には、認証処理の代行に起因する負荷がかからなくなり、システムにかかる負荷を軽減することができる。
【００１４】
上述の認証対象データ、代行依頼データ、認証済みデータ及び代行中止要求データは、各データともに一回の伝送単位で伝送されるデータであってもよいし、複数回の伝送単位に分割されて順次伝送されるデータであってもよい。複数回の伝送単位に分割されて順次伝送される場合は、送信側から受信側へ一単位分のデータは伝送されるたびに、受信側から送信側へデータの一単位分のデータ受信を完了した旨を示すデータが伝送されてもよい。すなわち、認証対象データ、代行依頼データ及び認証済みデータの送信開始から送信完了までの間に、他のデータの伝送が行われてもよい。
【００１５】
なお、この欄及び特許請求の範囲に記載した括弧内の符号は、後述する実施形態において一態様として例示する具体的な構成との対応関係を理解しやすくするために記載したものである。当該記載は、本開示の技術的範囲が後述する実施形態と同一な範囲に限定されることを意味する記載ではない。
【図面の簡単な説明】
【００１６】
【図１】図１はネットワークシステムを示す説明図である。
【図２】図２はＥＣＵを示す説明図である。
【図３】図３はネットワークにおいて伝送されるデータの構造を示す説明図である。
【図４】図４は依頼元装置となるＥＣＵがグローバルバスからデータを受信した際に実行する処理のフローチャートである。
【図５】図５は認証対象データに対応する処理のフローチャートである。
【図６】図６はメッセージ認証処理のフローチャートである。
【図７】図７は代行中止要求に対応する処理のフローチャートである。
【図８】図８は依頼先装置となるＥＣＵがローカルバスからデータを受信した際に実行する処理のフローチャートである。
【図９】図９は代行依頼データに対応する処理のフローチャートである。
【図１０】図１０は第一実施形態における認証成立通知に対応する処理のフローチャートである。
【図１１】図１１は第一実施形態における依頼先装置となるＥＣＵがグローバルバスからデータを受信した際に実行する処理のフローチャートである。
【図１２】図１２は他ＥＣＵ宛のデータに対応する処理のフローチャートである。
【図１３】図１３は依頼元装置となるＥＣＵがローカルバスからデータを受信した際に実行する処理のフローチャートである。
【図１４】図１４は認証済みデータに対応する処理のフローチャートである。
【図１５】図１５は代行実行中ＩＤの通知に対応する処理のフローチャートである。
【図１６】図１６は第二実施形態における認証成立通知に対応する処理のフローチャートである。
【図１７】図１７は第二実施形態における依頼先装置となるＥＣＵがグローバルバスからデータを受信した際に実行する処理のフローチャートである。
【図１８】図１８は代行中止要求に対応する処理のフローチャートである。
【発明を実施するための形態】
【００１７】
次に、上述のネットワークシステムについて、例示的な実施形態を挙げて説明する。
（１）第一実施形態
［ネットワークシステムの構成］
図１に示すネットワークシステム１は、例えば自動車に搭載される車載ネットワークシステムである。ネットワークシステム１は、複数のＥＣＵ２Ａ，２Ｂ，２Ｃ，２Ｄ，３Ａ，３Ｂ，３Ｃ，３Ｄ，３Ｅ，３Ｆ，３Ｇ，３Ｈ、ＣＧＷ４、複数のグローバルバス５Ａ，５Ｂ，５Ｃ及びローカルバス６等を有する。ＥＣＵは「Electronic Control Unit」の略称である。ＣＧＷは「Central Gateway」の略称である。
【００１８】
ＥＣＵ３Ａ，３Ｂ，２Ａ，２Ｂは、グローバルバス５Ａに接続されている。ＥＣＵ２Ｃ，２Ｄ，３Ｃ，３Ｄは、グローバルバス５Ｂに接続されている。ＥＣＵ３Ｅ，３Ｆ，３Ｇ，３Ｈは、グローバルバス５Ｃに接続されている。各グローバルバス５Ａ〜５Ｃには、例えば、機能的に同系統に分類されるＥＣＵが接続されている。一例を挙げれば、例えば、グローバルバス５Ａにはボデー系ＥＣＵが接続される。グローバルバス５Ｂには制御系ＥＣＵが接続される。グローバルバス５Ｃには情報系ＥＣＵが接続される。
【００１９】
グローバルバス５Ａ〜５Ｃは、ＣＧＷ４を介して相互に接続されている。これらの構成により、ＥＣＵ２Ａ〜２Ｄ，ＥＣＵ３Ａ〜３Ｈ、ＣＧＷ４及びグローバルバス５Ａ〜５Ｃは、第一ネットワーク１Ａを構成している。ＥＣＵ２Ａ〜２Ｄは、ローカルバス６に接続されている。これにより、ＥＣＵ２Ａ〜２Ｄ及びローカルバス６は、第二ネットワーク１Ｂを構成している。すなわち、ＥＣＵ２Ａ〜２Ｄは、第一ネットワーク１Ａのノードとして機能するように構成され、かつ、第二ネットワーク１Ｂのノードとしても機能するように構成されている。このように構成されたＥＣＵ２Ａ〜２Ｄが、本開示でいう電子装置に相当する。
【００２０】
第一ネットワーク１Ａ及び第二ネットワーク１Ｂでは、各ネットワークを構成するノードに対してブロードキャスト通信によってデータが伝送される。ただし、第一ネットワーク１Ａと第二ネットワーク１Ｂは、互いに独立したネットワークである。そのため、例えば、第一ネットワーク１Ａにおいてデータが伝送された場合でも、そのデータが第二ネットワーク１Ｂへと伝送されることはない。同様に、第二ネットワーク１Ｂにおいてデータが伝送された場合でも、そのデータが第一ネットワーク１Ａへと伝送されることはない。
【００２１】
ＣＧＷ４は、グローバルバス５Ａ〜５Ｃの間に介在して、いずれか一つのグローバルバスから残りのグローバルバスへデータを中継する。また、ＣＧＷ４は、外部通信路７に接続可能に構成され、外部通信路７とグローバルバス５Ａ〜５Ｃとの間でデータを中継する。これにより、ＥＣＵ２Ａ〜２Ｄ及びＥＣＵ３Ａ〜３Ｈは、第一ネットワーク１Ａ経由で外部機器（例えば、図１中に例示する外部ツール９。）と通信可能となっている。外部ツール９は、自動車ディーラ等において車両の故障診断等を実施する際に使用される装置である。本実施形態においては、後述する処理の中でＥＣＵ２Ａ〜２Ｄ等に対してコマンドを送信する装置として使用される。第二ネットワーク１Ｂには、外部通信路に接続可能なノードが設けられていない。そのため、第二ネットワーク１Ｂのノードが第二ネットワーク１Ｂ経由で外部機器と通信することはできない。
【００２２】
外部通信路７は、無線通信路及び有線通信路のうちの少なくとも一方であればよい。また、外部通信路７は、単一の機器と接続可能な通信路及び複数の機器と接続可能な通信路のうちの少なくとも一方であればよい。複数の機器と接続可能な通信路としては、例えば複数の機器がノードとして含まれる外部ネットワークに接続可能な通信路であればよい。外部通信路７は、全部が専用線で構成されていてもよいし、一部が公衆回線で構成されていてもよい。
【００２３】
本実施形態では上記三つのグローバルバス５Ａ〜５Ｃを例示してあるが、グローバルバスの数は任意である。例えば、グローバルバスの数は、二つ以下又は四つ以上であってもよい。本実施形態では上記十二個のＥＣＵ２Ａ〜２Ｄ及びＥＣＵ３Ａ〜３Ｈを例示してあるが、ＥＣＵ数は任意である。例えば、ＥＣＵの数は、十一個以下又は十三個以上であってもよい。本実施形態では上記ＥＣＵ２Ａ〜２Ｄがローカルバス６に接続されている例を示したが、ＥＣＵ３Ａ〜３Ｈのうちの少なくとも一つがローカルバス６に接続されていてもよい。あるいは、ＥＣＵ３Ａ〜３Ｈのうちの少なくとも一つがローカルバス６とは別のローカルバスに接続されていてもよい。
【００２４】
［ＥＣＵの構成］
次に、ＥＣＵの内部構成について説明する。以下の説明では、図２に示すＥＣＵ２Ｂを例に挙げる。ただし、本実施形態において、ＥＣＵ２Ａ，２Ｃ，２Ｄは、ＥＣＵ２Ｂと同様に構成される。また、本実施形態において、ＥＣＵ３Ａ〜３Ｈは、第二ネットワーク１Ｂに接続されていない点で、ＥＣＵ２Ｂとは相違するが、その他の点はＥＣＵ２Ｂと同様に構成される。
【００２５】
ＥＣＵ２Ｂは、図２に示すように、ＣＰＵ１１、ＲＡＭ１２、フラッシュメモリ１３、第一通信部１６及び第二通信部１７等を有する。第一通信部１６は、グローバルバス５Ａに接続するためのネットワークインターフェースである。第二通信部１７は、ローカルバス６に接続するためのネットワークインターフェースである。ＥＣＵ２Ａ〜２Ｄの各種機能は、ＣＰＵ１１が非遷移的実体的記録媒体に格納されたプログラムに従って各種処理を実行することにより実現される。この例では、フラッシュメモリ１３が、非遷移的実体的記録媒体に該当する。
【００２６】
ＣＰＵ１１がプログラムに従って各種処理を実行する際には、フラッシュメモリ１３に格納されたプログラムをＲＡＭ１２によって構成されるメインメモリにロードするように構成されていてもよい。この場合、ＣＰＵ１１は、メインメモリに格納されたプログラムに従って各種処理を実行する。ＣＰＵ１１がプログラムに従って各種処理を実行することにより、プログラムに対応する方法が実行され、ＥＣＵ２Ａ〜２Ｄが備える各種機能が実現される。ただし、ＥＣＵ２Ａ〜２Ｄが備える各種機能を実現する手法はソフトウェアに限るものではなく、機能の一部又は全部を、ディジタル回路やアナログ回路等を組み合わせたハードウェアを用いて実現してもよい。
【００２７】
ＲＡＭ１２及びフラッシュメモリ１３には、各種記憶領域が確保される。本実施形態に関連する主要な記憶領域としては、ＲＡＭ１２には受信データバッファ１２Ａが確保される。フラッシュメモリ１３には、共通鍵記憶部１３Ａ及びＣＶＮ記憶部１３Ｂが確保される。受信データバッファ１２Ａは、第一ネットワーク１Ａ経由で受信したデータを一時的に蓄積するためのバッファである。
【００２８】
受信データバッファ１２Ａには受信したデータが順次格納され、格納領域が満杯になった場合には、最も古いデータが格納されている領域に新しいデータが上書きで格納される。受信データバッファ１２Ａのサイズは、第一ネットワーク１Ａ経由で受信するデータ量が最大となる状況を考慮して、少なくとも一定期間分（例えば２０ミリ秒分。）のデータについては確実に蓄積できる程度のサイズが確保される。
【００２９】
共通鍵記憶部１３Ａには、後述する処理の中で、受信データに対するメッセージ認証を実行する際に使用する共通鍵が記憶されている。ＣＶＮ記憶部１３Ｂには、後述する処理の中で、データの送信元が正当な依頼先装置か否かを確認する際に必要となるＣＶＮのリストが記憶されている。ＣＶＮは「Calibration Verification Numbers」の略称である。ＣＶＮは、ＥＣＵに実装されたソフトウェア等に基づいて生成される照合用コードである。
【００３０】
車両に搭載されるＥＣＵには、ＣＶＮの生成及び出力を行う機能を実装することが法令等によって義務づけられている。車両に搭載される複数のＥＣＵがＣＶＮを生成すると、ＥＣＵごとに異なるＣＶＮが生成される。本実施形態においては、ＥＣＵ２Ａ〜２Ｄにおいて生成、出力されるＣＶＮが、車両生産時に収集、リスト化されて、ＣＶＮ記憶部１３Ｂに記憶されている。
【００３１】
ＥＣＵに実装されたソフトウェアが更新された場合、あるいはＥＣＵに実装されたソフトウェアが改ざんされた場合には、ＥＣＵにおいて生成されるＣＶＮが変化する。したがって、車両生産時にＣＶＮ記憶部１３Ｂに記憶されたＣＶＮと、ＥＣＵから出力されたＣＶＮとを比較して、その比較結果が一致しなければ、ＣＶＮを出力したＥＣＵの換装ないしはソフトウェアの改ざん等があったのではないかと疑うことができる。ＥＣＵに実装されたソフトウェアが正当に更新される場合には、その更新後のＥＣＵから出力されるＣＶＮでＣＶＮ記憶部１３Ｂに記憶されているＣＶＮを更新すればよい。
【００３２】
［認証処理の概要］
第一ネットワーク１Ａのノードは、外部通信路７経由で到来するデータを受信することができる。そのため、例えば外部通信路７に接続された不正な外部機器から悪意のある不正なデータが伝送され得ることも想定して、そのような不正なデータに対して適切な対処をすることが重要となる。また、ＥＣＵ２Ａ〜２Ｄ及びＥＣＵ３Ａ〜３Ｈにおいてプログラムの改ざんが行われた場合、あるいは不正なＥＣＵへの換装が行われた場合にも、そのような不正なＥＣＵから伝送される不正なデータに対し、適切な対処をすることが重要である。
【００３３】
そこで、本実施形態のネットワークシステム１において、ＥＣＵ２Ａ〜２Ｄ及びＥＣＵ３Ａ〜３Ｈは、第一ネットワーク１Ａ経由でデータを受信した際に認証処理を実行し、データの正当性を確認する。本実施形態において、ＥＣＵ２Ａ〜２Ｄ及びＥＣＵ３Ａ〜３Ｈは、メッセージ認証によってデータの正当性を確認する。図３に示すように、第一ネットワーク１Ａにおいて伝送されるデータＤ１には、ＩＤ、通常データ及び暗号データ等が含まれる。なお、データＤ１には、これら以外の制御コードやデータ等も含まれるが、本処理には関連しないので説明を省略する。
【００３４】
ＩＤは、データの種別を示す情報、データの内容を示す情報、送信元のノードを示す情報、送信先のノードを示す情報及び通信時の優先度を示す情報等、様々な情報を含み得る識別子である。送信元のノードからブロードキャスト通信によって第一ネットワーク１Ａへと送出されるデータＤ１は、第一ネットワーク１Ａにおける送信元ノード以外のノード全てにおいて受信される。データＤ１を受信したノードは、データＤ１中に含まれるＩＤに基づいて、処理対象とすべきデータか否かを判断することができる。
【００３５】
通常データは、送信元ノードが送信先ノードへ送信しようとしたデータの実体部分である。暗号データは、第一ネットワーク１Ａのノードが共通に使用する共通鍵を使って、所定の暗号化方式により通常データを暗号化したデータである。共通鍵は、上述の共通鍵記憶部１３Ａに記憶されている。データＤ１中に含まれる暗号データは、データＤ１を送信する送信元ノードにおいて、共通鍵を使って通常データを暗号化し、その暗号化済みのデータの一部を抽出したものである。暗号化済みのデータの一部を抽出するのはデータ量を削減するためである。データ量の削減が不要であれば、暗号化済みのデータの全部を暗号データとして利用してもよい。
【００３６】
以上のようなデータＤ１を受信したノードにおいて、メッセージ認証を実施する際には、データＤ１中に含まれる通常データを取り出し、取り出した通常データを送信元ノードと同様の手順で暗号化し、その暗号化済みのデータの一部を抽出する。このようにして受信側ノードで生成される暗号データは、送信元ノードと同じ共通鍵を使って生成されるので、通常は、データＤ１中に含まれる暗号データと一致する。
【００３７】
しかし、通常データが伝送途中で改ざんされた場合やデータ化けした場合には、受信側ノードで生成される暗号データとデータＤ１中に含まれる暗号データとが不一致となる。あるいは、共通鍵を知らない不正なノードがデータを送信した場合には、適正な暗号データを生成できないため、受信側ノードで生成される暗号データとデータＤ１中に含まれる暗号データとが不一致となる。したがって、受信側ノードでは、受信側ノードで生成される暗号データとデータＤ１中に含まれる暗号データが一致する場合には、認証が成立したと判断する。一方、受信側ノードで生成される暗号データとデータＤ１中に含まれる暗号データとが不一致となった場合には、認証に失敗したと判断する。
【００３８】
また、本実施形態のネットワークシステム１において、ＥＣＵ２Ａ〜２Ｄは、第二ネットワーク１Ｂ経由でデータを伝送することができる。ただし、第二ネットワーク１Ｂは、第一ネットワーク１Ａとは異なり、第二ネットワーク１Ｂの外部とは隔離されたネットワークとなっている。そのため、第一ネットワーク１Ａとは異なり、少なくとも第二ネットワーク１Ｂの外部から不正なデータが伝送されてくることはない。
【００３９】
そこで、ＥＣＵ２Ａ〜２Ｄは、第二ネットワーク１Ｂ経由でデータを受信した際には、第一ネットワーク１Ａの場合とは異なり、認証処理を実行しない。そのため、第二ネットワーク１Ｂにおいて伝送されるデータＤ２は、図３に示すように、ＩＤ及び通常データ等が含まれるものの、暗号データは含まれないデータとされている。
【００４０】
［認証代行の仕組み］
上述の認証処理において認証に成功した場合、ＥＣＵ２Ａ〜２Ｄ及びＥＣＵ３Ａ〜３Ｈは、当該認証成功以降の処理において上述のデータＤ１を利用する。具体例を挙げれば、例えば、データＤ１中から通常データが取り出され、その通常データを変数として用いた演算処理、通常データに基づく制御、通常データに応じて判断が分かれる分岐処理等が実行される。
【００４１】
一方、ＥＣＵ２Ａ〜２Ｄ及びＥＣＵ３Ａ〜３Ｈのうち、ＥＣＵ２Ａ〜２Ｄは、いずれかが上述の認証処理において認証に失敗した場合に、他のＥＣＵに認証の代行を依頼する。これは、データＤ１が不正なために認証に失敗したのではなく、認証処理を実行するＥＣＵの故障等が原因で認証に失敗した可能性もあるからである。認証に失敗したＥＣＵは、認証に失敗したことを契機として依頼元装置となる。
【００４２】
ここでは、ＥＣＵ２Ｂが認証処理において認証に失敗して依頼元装置となる場合を想定して説明を続ける。依頼元装置となったＥＣＵ２Ｂは、ＥＣＵ２Ａ，２Ｃ，２Ｄ（すなわち、依頼元装置以外のＥＣＵ。）の中から依頼先装置を選定する。ここでは、ＥＣＵ２ＢがＥＣＵ２Ｃを依頼先装置として選定した場合を想定して説明を続ける。依頼元装置となるＥＣＵ２Ｂは、依頼先装置として選定されたＥＣＵ２Ｃへ第二ネットワーク１Ｂ経由でデータを送信することにより、認証処理の代行を依頼する。
【００４３】
以下の説明においては、依頼元装置において第一ネットワーク１Ａ経由で受信して、認証処理の対象とされるデータＤ１のことを認証対象データと称する。また、認証処理の代行を依頼するため、依頼元装置から第二ネットワーク１Ｂ経由で依頼先装置へと伝送するデータのことを代行依頼データと称する。本実施形態の場合、代行依頼データであること、及びどのＥＣＵが依頼先装置として選定されたのかは、代行依頼データ中のＩＤによって示される。
【００４４】
具体的には、代行依頼データであることを示すＩＤとしては、依頼先装置として選定され得るＥＣＵ２Ａ〜２Ｄそれぞれに対応付けられた複数のＩＤが用意されている。ＥＣＵ２Ｃへ認証処理の代行を依頼する際には、ＥＣＵ２Ｃに対応するＩＤを選択し、そのＩＤを含む代行依頼データをブロードキャスト通信により第二ネットワーク１Ｂへと送出する。
【００４５】
ＥＣＵ２Ｃでは、代行依頼データを受信した際、そのデータ中に含まれるＩＤに基づいてＥＣＵ２Ｃが依頼先装置に選定されたことを認識し、それを契機にして依頼先装置としての処理を実行する。なお、ＥＣＵ２Ａ，２Ｄにおいても、ＥＣＵ２Ｂから送信された代行依頼データを受信する。ただし、そのデータ中に含まれるＩＤに基づいてＥＣＵ２Ａ，２Ｄでの対処が必要なデータではないと判断できるので、その判断以降の処理は実行しない。
【００４６】
依頼先装置となるＥＣＵ２Ｃでは、認証対象データに対してメッセージ認証による認証処理を実行する。本実施形態において、ＥＣＵ２Ｃは、上述のような受信データバッファ１２Ａを有し、第一ネットワーク１Ａ経由で受信したデータを一定期間分だけ受信データバッファ１２Ａに蓄積している。そのため、ＥＣＵ２Ｃが代行依頼データを受信した際、ＥＣＵ２Ｃは、代行依頼データ中に含まれる情報に基づいて、対象となる認証対象データを受信データバッファ１２Ａの中から探し出し、認証対象データに対する認証処理を実行する。なお、上述のような受信データバッファ１２Ａを使う代わりに、ＥＣＵ２ＢからＥＣＵ２Ｃへ認証対象データが提供されてもよい。
【００４７】
依頼先装置であるＥＣＵ２Ｃにおいて認証対象データに対する認証に成功した場合、ＥＣＵ２Ｃは、認証に成功した認証対象データの内容を含む認証済みデータを第二ネットワーク１Ｂ経由でＥＣＵ２Ｂに対して送信する。認証済みデータであることは、認証済みデータ中のＩＤによって示される。依頼元装置であるＥＣＵ２Ｂでは、認証済みデータを受信したことにより、依頼先装置での認証に成功したことを認識することができる。そこで、ＥＣＵ２Ｂでは、認証済みデータを受信した場合、ＥＣＵ２Ｂは認証済みデータに含まれる認証対象データを利用して、所期の処理を実行することができる。
【００４８】
したがって、このように構成されたネットワークシステム１によれば、ＥＣＵ２Ｂにおいて認証対象データの認証に失敗した場合でも、ＥＣＵ２Ｃにおいて認証対象データの認証に成功すれば、ＥＣＵ２Ｂは認証済みデータに含まれる認証対象データを利用することができる。よって、例えば、ＥＣＵ２Ｂにおいて認証処理を実行するために必要となるハードウェア又はソフトウェアに故障等の問題が生じていたとしても、ＥＣＵ２Ｂは認証済みの認証対象データを利用することができる。
【００４９】
［依頼元装置及び依頼先装置において実行される処理の詳細］
次に、上述の依頼元装置及び依頼先装置において実行される処理について、図４〜図１５に示すフローチャートに基づいて説明する。ここでは、先に挙げた例と同様に、ＥＣＵ２Ｂが依頼元装置となり、ＥＣＵ２Ｃが依頼先装置として選定される場合を想定して説明を続ける。まず、図４〜図７に示す処理について説明する。図４〜図７に示す処理は、ＥＣＵ２Ｂにおいてグローバルバス５Ａからデータを受信する際に実行される処理である。
【００５０】
ＥＣＵ２Ｂは、図４に示すように、Ｓ１０２において、グローバルバス５Ａからデータを受信する。続いて、ＥＣＵ２Ｂは、Ｓ１０４において、グローバルバス５Ａから受信したデータが認証対象データか否かを判断する。認証対象データは、ＥＣＵ２Ｂ，２Ｃ以外のＥＣＵがブロードキャスト通信によって第一ネットワーク１Ａへと送信したデータである。ここでは、一例として、ＥＣＵ３Ｈが認証対象データを送信したものとして、以降の説明を続ける。ＥＣＵ３Ｈが認証対象データを送信した場合、認証対象データは第一ネットワーク１ＡにおいてＥＣＵ３Ｈ以外のノード全てに届く。認証対象データを受信したノードは、認証対象データ中に含まれるＩＤに基づいて、処理対象とすべきデータか否か等を判断する。また、本実施形態の場合、少なくともＥＣＵ２Ａ〜２Ｄにおいては、認証対象データを受信したら、認証対象データを受信データバッファ１２Ａに格納する。
【００５１】
Ｓ１０４において、認証対象データであった場合はＹＥＳと判断され、Ｓ１０６へと進む。Ｓ１０６において、ＥＣＵ２Ｂは、認証対象データに対応する処理を実行する。Ｓ１０６の詳細を図５に示す。図５に示す処理を開始すると、Ｓ１２２において、ＥＣＵ２Ｂは、代行依頼済みフラグがオフか否かを判断する。代行依頼済みフラグは、初期値がオフにされていて、後述する処理の中でＥＣＵ２Ｂが他のＥＣＵに対して認証の代行を依頼すると、後述するＳ１３４においてオンにされるフラグである。ここでは、代行依頼済みフラグが初期値（すなわち、オフ。）になっているものとして説明を続ける。
【００５２】
代行依頼済みフラグがオフとなっている場合は、Ｓ１２２においてＹＥＳと判断され、Ｓ１２４へと進む。Ｓ１２４において、ＥＣＵ２Ｂは、メッセージ認証処理を実行する。このメッセージ認証処理の詳細を図６に示す。メッセージ認証処理を開始すると、ＥＣＵ２Ｂは、図６に示すように、Ｓ１４２において、処理対象となるデータに含まれる通常データと暗号データを取り出す。ここでいう処理対象となるデータは、Ｓ１０２において受信した認証対象データである。
【００５３】
続いて、ＥＣＵ２Ｂは、Ｓ１４４において、通常データを共通鍵で暗号化し、暗号データを生成する。ここで暗号化されるデータは、Ｓ１４２において処理対象となるデータから取り出された通常データである。続いて、ＥＣＵ２Ｂは、Ｓ１４６において、受信した暗号データと生成したデータが一致するか否かを判断する。受信した暗号データと生成したデータが一致する場合は、Ｓ１４６においてＹＥＳと判断され、Ｓ１４８へと進む。
【００５４】
Ｓ１４８へ進んだ場合は、ＥＣＵ２Ｂにおいて認証が成立したことになり、図６に示す処理を終了して、図５のＳ１２６へと進む。一方、受信した暗号データと生成したデータが一致しない場合は、Ｓ１４６においてＮＯと判断され、Ｓ１５０へと進む。Ｓ１５０へ進んだ場合は、ＥＣＵ２Ｂにおいて認証に失敗したことになり、図６に示す処理を終了して、図５のＳ１２６へと進む。
【００５５】
ＥＣＵ２Ｂは、Ｓ１２６において、認証が成立したか否かを判断する。上述のＳ１４８において認証が成立している場合は、Ｓ１２６においてＹＥＳと判断され、Ｓ１２８へと進む。ＥＣＵ２Ｂは、Ｓ１２８において、認証対象データに含まれる通常データを取り出して、以降の処理で利用する。ここでいう「以降の処理」としては、ＥＣＵ２Ｂの機能に応じた様々な処理を考え得るが、当該処理そのものは本実施形態における要部ではないので、これ以上の説明は省略する。Ｓ１２８の実行後は図５に示す処理を終了する。これにより、図４のＳ１０６を終了し、図４に示す処理を終了する。
【００５６】
一方、上述のＳ１５０において認証に失敗している場合には、Ｓ１２６においてＮＯと判断され、Ｓ１３０へと進む。ＥＣＵ２Ｂは、Ｓ１３０において、認証対象データに含まれるＩＤを取り出して他の部分は破棄する。続いて、ＥＣＵ２Ｂは、Ｓ１３２において、取り出したＩＤを含む代行依頼データを作成し、一つの依頼先装置に対して認証代行依頼をするためのＩＤを代行依頼データに設定し、代行依頼データをローカルバス６へ送信する。
【００５７】
本実施形態においては、上述の通り、ＥＣＵ２Ｃが依頼先装置として選定される場合を想定している。そのため、Ｓ１３２では、ＥＣＵ２Ｃに対して認証代行依頼をするためのＩＤを代行依頼データに設定する。認証代行依頼をするためのＩＤとしては、依頼先装置となり得るＥＣＵごとに異なる複数のＩＤがあらかじめ用意されている。詳しくは後述するが、ＥＣＵ２Ｂが、Ｓ１３２においてＥＣＵ２Ｃに対して認証の代行を依頼した場合、以降、ＥＣＵ２Ｂは、ＥＣＵ２Ｃから認証済みデータを受け取るようになる。
【００５８】
Ｓ１３２を終えたら、続いて、ＥＣＵ２Ｂは、Ｓ１３４において、代行依頼済みフラグをオンにする。代行依頼済みフラグは、Ｓ１３２においてＥＣＵ２ＢがＥＣＵ２Ｃに対して認証の代行を依頼した場合に、Ｓ１３４においてオンとなる。Ｓ１３４の実行後は図５に示す処理を終了する。これにより、図４のＳ１０６を終了し、図４に示す処理を終了する。
【００５９】
図４に示す処理は、ＥＣＵ２Ｂがグローバルバス５Ａからデータを受信するたびに、ＥＣＵ２Ｂにおいて実行される。図４に示す処理が複数回にわたって実行される中で、複数回にわたって認証対象データを受信する場合、Ｓ１３４において代行依頼済みフラグがオンにされると、次に図４に示す処理が実行される際にはＳ１２２においてＮＯと判断される。この場合、ＥＣＵ２Ｂは、Ｓ１３６において、受信データを破棄する。Ｓ１３６を終えたら図５に示す処理を終了する。これにより、図４のＳ１０６を終了し、図４に示す処理を終了する。
【００６０】
Ｓ１０４において、認証対象データではない場合はＮＯと判断され、Ｓ１０８へと進む。ただし、Ｓ１０８及びＳ１１０については、他箇所の説明をした後の方が理解しやすいので、ここでの説明は保留し、後で詳述することにする。Ｓ１０８においてＮＯと判断された場合は、Ｓ１１２へと進む。Ｓ１１２において、ＥＣＵ２Ｂは、他の受信データに対応する処理を実行する。Ｓ１１２において実行される処理としては、ＥＣＵ２Ｂの機能に応じた様々な処理を考え得るが、当該処理そのものは本実施形態における要部ではないので、これ以上の説明は省略する。Ｓ１１２の実行後は図４に示す処理を終了する。
【００６１】
次に、図８〜図１０に示す処理について説明する。図８〜図１０に示す処理は、ＥＣＵ２Ｃにおいてローカルバス６からデータを受信する際に実行される処理である。ＥＣＵ２Ｃは、図８に示すように、Ｓ２０２において、ローカルバス６からデータを受信する。続いて、ＥＣＵ２Ｃは、Ｓ２０４において、上記Ｓ２０２で受信したデータがＥＣＵ２Ｃ宛の代行依頼データか否かを判断する。ここで、代行依頼データであること、及びＥＣＵ２Ｃ宛であることは、受信データ中に含まれるＩＤに基づいて判断することができる。ＥＣＵ２Ｂにおいて上述のＳ１３２が実行された場合、代行依頼データはブロードキャスト通信によって第二ネットワーク１Ｂへと送信される。そのため、代行依頼データは第二ネットワーク１ＢにおいてＥＣＵ２Ｂ以外のノード全てに届く。
【００６２】
ＥＣＵ２ＣにおいてＥＣＵ２Ｃ宛の代行依頼データを受信した場合、ＥＣＵ２Ｃでは、Ｓ２０４においてＹＥＳと判断されて、Ｓ２０６へと進む。Ｓ２０６において、ＥＣＵ２Ｃは、代行依頼データに対応する処理を実行する。Ｓ２０６の詳細を図９に示す。図９に示す処理を開始すると、Ｓ２２２において、ＥＣＵ２Ｃは、代行継続フラグをオンにする。続いて、ＥＣＵ２Ｃは、Ｓ２２４において、処理対象となる認証対象データを受信データバッファ１２Ａから取得する。上述の通り、ＥＣＵ２ＢがＳ１３２で代行依頼データを作成する際には、認証対象データから取り出されたＩＤを含む代行依頼データが作成される。そこで、Ｓ２２４では、ＥＣＵ２Ｃは、代行依頼データ中に含まれている「認証対象データから取り出されたＩＤ」と一致するＩＤを持つデータを、受信データバッファ１２Ａから探し出し、そのデータを処理対象となる認証対象データとして取得する。
【００６３】
続いて、ＥＣＵ２Ｃは、Ｓ２２６において、受信データバッファ１２Ａから探し出された認証対象データに対し、メッセージ認証処理を実行する。このメッセージ認証処理は、図６に示した処理となる。ただし、図６に示した処理については既に詳細を説明したので、重ねての説明は省略する。Ｓ２２６においてメッセージ認証処理を実行する場合、図６のＳ１４２における「処理対象となるデータ」は、Ｓ２２４において受信データバッファ１２Ａから探し出された認証対象データである。
【００６４】
続いて、ＥＣＵ２Ｃは、Ｓ２２８において、認証が成立したか否かを判断する。Ｓ２２６で認証が成立している場合は、Ｓ２２８においてＹＥＳと判断され、Ｓ２３０へと進む。ＥＣＵ２Ｃは、Ｓ２３０において、認証対象データに含まれる通常データを取り出して、その通常データを含む認証済みデータを作成し、認証済みデータにＣＶＮを付加して、ローカルバス６へ送信する。認証済みデータであることは、認証済みデータ中に含まれるＩＤによって示すことができる。
【００６５】
認証済みデータに付加されるＣＶＮは、ＥＣＵ２Ｃにおいて生成されるＣＶＮである。Ｓ２３０の実行後は図９に示す処理を終了する。これにより、図８のＳ２０６を終了し、図８に示す処理を終了する。一方、Ｓ２２６で認証に失敗している場合には、Ｓ２２８においてＮＯと判断され、Ｓ２３２へと進む。ＥＣＵ２Ｃは、Ｓ２３２において、認証失敗を示す失敗通知データをローカルバス６へ送信する。失敗通知データであることは、失敗通知データ中に含まれるＩＤによって示すことができる。Ｓ２３２の実行後は図９に示す処理を終了する。これにより、図８のＳ２０６を終了し、図８に示す処理を終了する。
【００６６】
ＥＣＵ２Ｃにおいて上述のＳ２３０が実行された場合、認証済みデータはブロードキャスト通信によって第二ネットワーク１Ｂへと送信される。そのため、ＥＣＵ２Ｃから送信される認証済みデータは、第二ネットワーク１ＢにおいてＥＣＵ２Ｃ以外のノード全てに届く。ＥＣＵ２Ｃにおいて上述のＳ２３２が実行された場合、失敗通知データはブロードキャスト通信によって第二ネットワーク１Ｂへと送信される。そのため、ＥＣＵ２Ｃから送信される失敗通知データは、第二ネットワーク１ＢにおいてＥＣＵ２Ｃ以外のノード全てに届く。
【００６７】
上述のＳ２０４において代行依頼データではなかった場合は、Ｓ２０４においてＮＯと判断され、Ｓ２０８へと進む。ただし、Ｓ２０８及びＳ２１０については、他箇所の説明をした後の方が理解しやすいので、ここでの説明は保留し、後で詳述することにする。Ｓ２０８においてＮＯと判断された場合は、Ｓ２１２へと進む。Ｓ２１２において、ＥＣＵ２Ｃは、他の受信データに対応する処理を実行する。Ｓ２１２において実行される処理としては、ＥＣＵ２Ｃの機能に応じた様々な処理を考え得るが、当該処理そのものは本実施形態における要部ではないので、これ以上の説明は省略する。Ｓ２１２の実行後は図８に示す処理を終了する。
【００６８】
次に、図１１及び図１２に示す処理について説明する。図１１及び図１２に示す処理は、ＥＣＵ２Ｃにおいてグローバルバス５Ｂからデータを受信する際に実行される処理である。ＥＣＵ２Ｃは、図１１に示すように、Ｓ３０２において、グローバルバス５Ｂからデータを受信する。続いて、ＥＣＵ２Ｃは、Ｓ３０４において、受信データを受信データバッファ１２Ａに保存する。Ｓ３０４が実行されることにより、既に説明した通り、受信データバッファ１２Ａには、最新の一定期間を対象にして第一ネットワーク１Ａ経由で受信したデータが蓄積される。
【００６９】
続いて、ＥＣＵ２Ｃは、Ｓ３０６において、受信データが他のＥＣＵ宛か否かを判断する。受信データが他のＥＣＵ宛であった場合は、Ｓ３０６においてＹＥＳと判断されて、Ｓ３０８へと進む。Ｓ３０８において、ＥＣＵ２Ｃは、他のＥＣＵ宛のデータに対応する処理を実行する。Ｓ３０８の詳細を図１２に示す。図１２に示す処理を開始すると、ＥＣＵ２Ｃは、Ｓ３２２において、代行継続フラグがオンとなっているか否かを判断する。代行継続フラグがオンとなっている場合は、Ｓ３２２においてＹＥＳと判断され、ＥＣＵ２Ｃは、Ｓ３２４において、処理対象となる認証対象データか否かを判断する。
【００７０】
ＥＣＵ２Ｂが認証代行の依頼元装置、ＥＣＵ２Ｃが認証代行の依頼先装置となる場合、グローバルバス５Ｂから受信するデータのうち、ＥＣＵ２Ｂ宛かつ認証が必要なデータが、Ｓ３２４でいう処理対象となる認証対象データに該当する。Ｓ３０２においてＥＣＵ２Ｃによって受信されたデータがＥＣＵ２Ｂ宛のデータである場合、Ｓ３０６ではＹＥＳと判断される。また、先に説明したＳ２２２において、代行継続フラグがオンとされた場合、Ｓ３２２ではＹＥＳと判断される。そして、Ｓ３０２においてＥＣＵ２Ｃによって受信されたデータが、処理対象となる認証対象データである場合、Ｓ３２４ではＹＥＳと判断されて、Ｓ３２６へと進む。
【００７１】
ＥＣＵ２Ｃは、Ｓ３２６において、Ｓ３０２においてＥＣＵ２Ｃによって受信された認証対象データに対し、メッセージ認証処理を実行する。このメッセージ認証処理は、図６に示した処理となる。ただし、図６に示した処理については既に詳細を説明したので、重ねての説明は省略する。Ｓ３２６においてメッセージ認証処理を実行する場合、図６のＳ１４２における「処理対象となるデータ」は、Ｓ３０２においてＥＣＵ２Ｃによって受信された認証対象データである。続いて、ＥＣＵ２Ｃは、Ｓ３２８において、認証が成立したか否かを判断する。
【００７２】
Ｓ３２６で認証が成立している場合は、Ｓ３２８においてＹＥＳと判断され、Ｓ３３０へと進む。ＥＣＵ２Ｃは、Ｓ３３０において、認証対象データに含まれる通常データを取り出して、その通常データを含む認証済みデータを作成し、認証済みデータにＣＶＮを付加して、ローカルバス６へ送信する。認証済みデータであることは、認証済みデータ中に含まれるＩＤによって示すことができる。Ｓ３３０は、先に説明したＳ２３０と同様の処理ステップである。Ｓ３３０の実行後は図１２に示す処理を終了する。これにより、図１１のＳ３０８を終了し、図１１に示す処理を終了する。
【００７３】
一方、図１２のＳ３２６で認証に失敗している場合には、Ｓ３２８においてＮＯと判断され、Ｓ３３２へと進む。ＥＣＵ２Ｃは、Ｓ３３２において、認証失敗を示す失敗通知データをローカルバス６へ送信する。Ｓ３３２は、先に説明したＳ２３２と同様の処理ステップである。Ｓ３３２の実行後は図１２に示す処理を終了する。これにより、図１１のＳ３０８を終了し、図１１に示す処理を終了する。
【００７４】
図１２に示す処理中、上述のＳ３２２において代行継続フラグがオンでない場合（すなわち、オフである場合。）は、Ｓ３２２においてＮＯと判断される。この場合は、他のＥＣＵから認証の代行を依頼されていない場合なので、Ｓ３３４において、受信データを破棄する。Ｓ３３４の実行後は図１２に示す処理を終了する。これにより、図１１のＳ３０８を終了し、図１１に示す処理を終了する。
【００７５】
また、上述のＳ３２４において、処理対象となる認証対象データではなかった場合は、Ｓ３２４においてＮＯと判断される。この場合は、他のＥＣＵから認証の代行を依頼されている場合ではあるものの、処理対象となる認証対象データではないので、Ｓ３３４において、受信データを破棄する。Ｓ３３４の実行後は図１２に示す処理を終了する。これにより、図１１のＳ３０８を終了し、図１１に示す処理を終了する。
【００７６】
図１１のＳ３０６において、受信データが他のＥＣＵ宛ではない場合（すなわち、ＥＣＵ２Ｃ宛のデータである場合。）は、Ｓ３０６においてＮＯと判断され、その場合、ＥＣＵ２Ｃは、Ｓ３１０において、他の受信データに対応する処理を実行する。Ｓ３１０において実行される処理としては、ＥＣＵ２Ｃの機能に応じた様々な処理を考え得るが、当該処理そのものは本実施形態における要部ではないので、これ以上の説明は省略する。Ｓ３１０の実行後は図１１に示す処理を終了する。
【００７７】
次に、図１３〜図１５に示す処理について説明する。図１３〜図１５に示す処理は、ＥＣＵ２Ｂにおいてローカルバス６からデータを受信する際に実行される処理である。ＥＣＵ２Ｂは、図１３に示すように、Ｓ４０２において、ローカルバス６からデータを受信する。続いて、ＥＣＵ２Ｂは、Ｓ４０４において、上記Ｓ４０２で受信したデータが認証済みデータか否かを判断する。ここで、認証済みデータであることは、受信データ中に含まれるＩＤに基づいて判断することができる。ＥＣＵ２Ｃにおいて上述のＳ２３０又はＳ３３０が実行された場合、認証済みデータはブロードキャスト通信によって第二ネットワーク１Ｂへと送信される。そのため、認証済みデータは第二ネットワーク１ＢにおいてＥＣＵ２Ｃ以外のノード全てに届く。
【００７８】
上述のＳ４０４において認証済みデータであった場合は、Ｓ４０４においてＹＥＳと判断され、Ｓ４０６へと進む。Ｓ４０６において、ＥＣＵ２Ｂは、認証済みデータに対応する処理を実行する。Ｓ４０６の詳細を図１４に示す。図１４に示す処理を開始すると、ＥＣＵ２Ｂは、Ｓ４２２において、なりすまし確認ＯＫフラグがオフか否かを判断する。なりすまし確認ＯＫフラグは、初期値がオフにされていて、後述するＳ４２４，Ｓ４２６においてなりすまし確認が適正に実行されると、後述するＳ４２８においてオンにされるフラグである。ここでは、なりすまし確認ＯＫフラグが初期値（すなわち、オフ。）になっているものとして説明を続ける。
【００７９】
なりすまし確認ＯＫフラグがオフになっている場合、Ｓ４２２においてＹＥＳと判断される。その場合、ＥＣＵ２Ｂは、Ｓ４２４及びＳ４２６を実行することにより、認証済みデータに対するなりすまし確認を実施する。具体的には、ＥＣＵ２Ｂは、Ｓ４２４において、認証済みデータに付加されたＣＶＮを取り出す。そして、Ｓ４２６において、ＣＶＮが適正か否かを判断する。Ｓ４２６では、受信した認証済みデータから取り出されたＣＶＮと、ＣＶＮ記憶部１３Ｂに記憶されたＣＶＮとを比較する。ＣＶＮ記憶部１３Ｂには、ＥＣＵ２Ａ〜２Ｄにおいて生成、出力されたＣＶＮが記憶されているので、Ｓ４２６では、ＥＣＵ２Ｃに対応するＣＶＮが比較対象として選択される。
【００８０】
この比較の結果、両者が一致すれば、ＣＶＮは適正であり、Ｓ４２６においてＹＥＳと判断され、Ｓ４２８へと進む。Ｓ４２８へ進んだ場合、なりすまし確認が適正に実行されたことになり、ＥＣＵ２Ｂは、なりすまし確認ＯＫフラグをオンにする。そして、ＥＣＵ２Ｂは、Ｓ４３０において、認証済みデータに含まれる通常データを取り出して、以降の処理で利用する。ここでいう「以降の処理」としては、ＥＣＵ２Ｂの機能に応じた様々な処理を考え得るが、当該処理そのものは本実施形態における要部ではないので、これ以上の説明は省略する。Ｓ４３０の実行後は図１４に示す処理を終了する。これにより、図１３のＳ４０６を終了し、図１３に示す処理を終了する。
【００８１】
一方、上述のＳ４２６において、比較結果が一致しなければ、受信した認証済みデータから取り出されたＣＶＮが不適正である可能性が高い。この場合、ＥＣＵ２Ｃ以外のノードがＥＣＵ２Ｃになりすまして認証済みデータを送信している可能性がある。あるいは、ＥＣＵ２Ｃのソフトウェアが改ざんされている可能性や、ＥＣＵ２Ｃが換装されている可能性もある。よって、このような状況下では、認証済みデータを受信したとしても、認証済みデータそのものの信頼性が低い。
【００８２】
そこで、上述のＳ４２６における比較結果が一致しなければ、ＣＶＮが不適正であり、Ｓ４２６においてＮＯと判断され、Ｓ４３２へと進む。Ｓ４３２において、ＥＣＵ２Ｂは、受信した認証済みデータを破棄して、フェイルセーフデータを以降の処理で利用する。フェイルセーフデータは、ＥＣＵ２Ｂが受信する認証対象データや認証済みデータに問題があって使用できない場合に、代替使用されるデータである。
【００８３】
このようなフェイルセーフデータは、例えばフラッシュメモリ１３にあらかじめ記憶されていればよい。あるいは、認証対象データを過去に一定期間以上の長期にわたって受信できていた場合は、その平均値、最大値、あるいは最小値等を経時的に算出し、いつでもフェイルセーフデータとして利用できるように準備しておいてもよい。どのようなかたちでフェイルセーフデータを用意するかは、ＥＣＵ２Ｂによる制御対象の挙動なども考慮して最適化されていればよい。Ｓ４３２の実行後は図１４に示す処理を終了する。これにより、図１３のＳ４０６を終了し、図１３に示す処理を終了する。
【００８４】
図１３に示す処理は、ＥＣＵ２Ｂがローカルバス６からデータを受信するたびに、ＥＣＵ２Ｂにおいて実行される。その際、再びＳ４０６へと進んだとしても、Ｓ４２４−Ｓ４２８の処理ステップは、一回実行されていれば、以降は、毎回実行しなくても認証済みデータは信頼できるものと考えられる。そこで、なりすまし確認ＯＫフラグがオフではない場合（すなわち、オンである場合。）は、Ｓ４２２においてはＮＯと判断され、Ｓ４２４−Ｓ４２８を実行することなく、Ｓ４３０へと進む。これにより、Ｓ４２４−Ｓ４２８を実行しない分だけ、ＥＣＵ２Ｂにかかる負荷を軽減することができる。
【００８５】
また、上述のＳ４０４において、上記Ｓ４０２で受信したデータが認証済みデータではなかった場合は、Ｓ４０４においてＮＯと判断され、その場合、ＥＣＵ２Ｂは、Ｓ４０８において、上記Ｓ４０２で受信したデータが失敗通知データか否かを判断する。ここで、失敗通知データであることは、受信データ中に含まれるＩＤに基づいて判断することができる。失敗通知データであった場合は、Ｓ４０８においてＹＥＳと判断され、Ｓ４１０へと進む。Ｓ４１０において、ＥＣＵ２Ｂは、受信した認証済みデータを破棄して、フェイルセーフデータを以降の処理で利用する。Ｓ４１０は、上述のＳ４３２と同様の処理である。Ｓ４１０の実行後は図１３に示す処理を終了する。
【００８６】
上述のＳ４０８において失敗通知データではなかった場合は、Ｓ４０８においてＮＯと判断され、Ｓ４１２へと進む。ただし、Ｓ４１２及びＳＳ４１４については、他箇所の説明をした後の方が理解しやすいので、ここでの説明は保留し、後で詳述することにする。Ｓ４１２においてＮＯと判断された場合は、Ｓ４１６へと進む。Ｓ４１６において、ＥＣＵ２Ｂは、他の受信データに対応する処理を実行する。Ｓ４１６において実行される処理としては、ＥＣＵ２Ｂの機能に応じた様々な処理を考え得るが、当該処理そのものは本実施形態における要部ではないので、これ以上の説明は省略する。Ｓ４１６の実行後は図１３に示す処理を終了する。
【００８７】
次に、上述した説明の中で、説明を保留した箇所について説明する。既に説明した通り、上述のネットワークシステム１では、ＥＣＵ２Ｂが依頼元装置となり、ＥＣＵ２Ｃが依頼先装置となって、ＥＣＵ２ＣがＥＣＵ２Ｂに代わって認証処理を実行する。ただし、自動車ディーラ等において修理等が実施されて、ＥＣＵ２Ｂが自ら認証処理を実行できる環境が整った場合には、ＥＣＵ２Ｂ，ＥＣＵ２Ｃともに、本来の稼働状態に復帰することが好ましい。
【００８８】
そこで、本実施形態のネットワークシステム１は、外部ツール９からネットワークシステム１のノードに対してメッセージを送信することにより、ＥＣＵ２Ｂ，ＥＣＵ２Ｃを本来の稼働状態に復帰させることができるように構成されている。具体的には、外部ツール９は、ネットワークシステム１のノードに対し、第一ネットワーク１Ａ経由で代行中止要求を送信する。
【００８９】
このとき、ＥＣＵ２Ｂは、既に説明した図４のＳ１０２において、グローバルバス５Ａから代行中止要求を受信する。この場合、Ｓ１０８においてＹＥＳと判断され、Ｓ１１０へと進む。Ｓ１１０において、ＥＣＵ２Ｂは、代行中止要求に対応する処理を実行する。Ｓ１１０の詳細を図７に示す。図７に示す処理を開始すると、Ｓ１６２において、ＥＣＵ２Ｂは、メッセージ認証処理を実行する。このメッセージ認証処理は、図６に示した処理となる。ただし、図６に示した処理については既に詳細を説明したので、重ねての説明は省略する。Ｓ１６２においてメッセージ認証処理を実行する場合、図６のＳ１４２における「処理対象となるデータ」は、外部ツール９から受信した代行中止要求である。
【００９０】
続いて、ＥＣＵ２Ｂは、Ｓ１６４において、認証が成立したか否かを判断する。Ｓ１６２で認証が成立している場合は、Ｓ１６４においてＹＥＳと判断され、Ｓ１６６へと進む。ＥＣＵ２Ｂは、Ｓ１６６において、ＥＣＵ２Ｂにおける処理の状態が、「通常処理中」、「フェールセーフ処理中」及び「代行依頼中」のいずれであるのかを判断する。Ｓ１６６において「通常処理中」であった場合、ＥＣＵ２Ｂは、Ｓ１６８において、「認証成立通知」及び「代行実行中ＩＤの通知依頼」をローカルバス６へ送信する。
【００９１】
「認証成立通知」は、外部ツール９から受信した代行中止要求に対する認証が成立したことを、他のノードに対して通知するためのデータである。「代行実行中ＩＤの通知依頼」は、ＥＣＵ２Ｂが他のノードに対して過去に代行を依頼したＩＤをＥＣＵ２Ｂに対して知らせてほしい旨を他のノードに対して依頼するためのデータである。Ｓ１６８を終えたら、図７に示す処理を終了する。これにより、図４のＳ１１０を終了し、図４に示す処理を終了する。
【００９２】
Ｓ１６６において「フェイルセーフ処理中」であった場合、ＥＣＵ２Ｂは、Ｓ１７０において、ＥＣＵ２Ｂにおける処理の状態を「フェイルセーフ処理中」から「通常処理中」へ変更する。Ｓ１７０を終えたら、図７に示す処理を終了する。これにより、図４のＳ１１０を終了し、図４に示す処理を終了する。Ｓ１６６において「代行依頼中」であった場合、ＥＣＵ２Ｂは、Ｓ１７２において、「認証成立通知」及び「代行実行中ＩＤの通知依頼」をローカルバス６へ送信する。Ｓ１７２は、Ｓ１６８と同様の処理ステップなので、ここでの説明は省略する。続いて、ＥＣＵ２Ｂは、Ｓ１７４において、ＥＣＵ２Ｂにおける処理の状態を「代行依頼中」のままにして、図７に示す処理を終了する。これにより、図４のＳ１１０を終了し、図４に示す処理を終了する。なお、上述Ｓ１６２で認証に失敗している場合は、Ｓ１６４においてＮＯと判断される。この場合、ＥＣＵ２Ｂは、図７に示す処理を終了する。これにより、図４のＳ１１０を終了し、図４に示す処理を終了する。
【００９３】
Ｓ１６８又はＳ１７２において認証成立通知が送信された場合、ＥＣＵ２Ｃは、認証成立通知を図８のＳ２０２で受信し、その場合、Ｓ２０８においてＹＥＳと判断されて、Ｓ２１０へと進む。Ｓ２１０において、ＥＣＵ２Ｃは、認証成立通知に対応する処理を実行する。Ｓ２１０の詳細を図１０に示す。図１０に示す処理を開始すると、ＥＣＵ２Ｃは、Ｓ２４２において、ＥＣＵ２Ｃにおける処理の状態が、「通常処理中」及び「代行実行中」のいずれであるのかを判断する。Ｓ２４２において「通常処理中」であった場合、図１０に示す処理を終了する。これにより、図８のＳ２１０を終了し、図８に示す処理を終了する。
【００９４】
Ｓ２４２において「代行実行中」であった場合、ＥＣＵ２Ｃは、Ｓ２４４において、「代行実行中ＩＤの通知」をローカルバス６へ送信する。代行実行中ＩＤは、ＥＣＵ２Ｂから認証代行を依頼されていたＩＤである。続いて、ＥＣＵ２Ｃは、Ｓ２４６において、代行継続フラグをオフにする。そして、ＥＣＵ２Ｃは、Ｓ２４８において、ＥＣＵ２Ｃにおける処理の状態を「代行実行中」から「通常処理中」へ変更する。Ｓ２４８を終えたら、図１０に示す処理を終了する。これにより、図８のＳ２１０を終了し、図８に示す処理を終了する。なお、第一実施形態においては、図８に示す処理を終了した時点で、ＥＣＵ２Ｃは、認証代行処理を終了し、通常の状態に復帰することになる。
【００９５】
Ｓ２４４において「代行実行中ＩＤの通知」が送信された場合、ＥＣＵ２Ｂは、「代行実行中ＩＤの通知」を図１３のＳ４０２で受信し、その場合、Ｓ４１２でＹＥＳと判断されて、Ｓ４１４へと進む。Ｓ４１４において、ＥＣＵ２Ｂは、「代行実行中ＩＤの通知」に対応する処理を実行する。Ｓ４１４の詳細を図１５に示す。図１５に示す処理を開始すると、ＥＣＵ２Ｂは、Ｓ４４２において、ＥＣＵ２Ｂにおける処理の状態が、「通常処理中」及び「代行依頼中」のいずれであるのかを判断する。
【００９６】
Ｓ４４２において「通常処理中」であった場合、ＥＣＵ２Ｂは、Ｓ４４４において、グローバルバス５Ａ経由で外部ツール９へＥＣＵ２Ｂの状態を通知する。これにより、外部ツール９では、ＥＣＵ２Ｂが通常処理中であったことを把握することができる。なお、外部ツール９では、ＥＣＵ２Ｂが通常処理中であった旨の表示を行ったり、ＥＣＵ２Ｂが通常処理中であった旨のログを記録したりすることができる。Ｓ４４４を終えたら、図１５に示す処理を終了する。これにより、図１３のＳ４１４を終了し、図１３に示す処理を終了する。
【００９７】
Ｓ４４２において「代行依頼中」であった場合、ＥＣＵ２Ｂは、Ｓ４４６において、代行依頼済みフラグをオフにする。続いて、ＥＣＵ２Ｂは、Ｓ４４８において、ＥＣＵ２Ｂにおける処理の状態を「代行依頼中」から「通常処理中」へ変更する。Ｓ４４８を終えたら、Ｓ４４４へ進み、グローバルバス５Ａ経由で外部ツール９へＥＣＵ２Ｂの状態を通知する。これにより、外部ツール９では、ＥＣＵ２Ｂが代行依頼中から通常処理中へ変更されたことを把握することができる。なお、外部ツール９では、ＥＣＵ２Ｂが代行依頼中から通常処理中へ変更された旨の表示を行ったり、ＥＣＵ２Ｂが代行依頼中から通常処理中へ変更された旨のログを記録したりすることができる。Ｓ４４４を終えたら、図１５に示す処理を終了する。これにより、図１３のＳ４１４を終了し、図１３に示す処理を終了する。
【００９８】
［効果］
以上説明した通り、上記ネットワークシステム１によれば、ＥＣＵ２Ｂにおいて認証対象データの認証に失敗した場合でも、依頼先装置となるＥＣＵ２Ｃにおいて認証対象データの認証に成功すれば、依頼元装置となるＥＣＵ２Ｂは認証済みデータに含まれる認証対象データの内容を利用することができる。したがって、例えば、ＥＣＵ２Ｂにおいて認証処理を実行するために必要となるハードウェア又はソフトウェアに故障等の問題が生じていたとしても、ＥＣＵ２ＢはＥＣＵ２Ｃにおいて認証された認証対象データの内容を利用して、所期の処理を実行することができる。
【００９９】
また、本実施形態の場合、依頼先装置であるＥＣＵ２Ｃは、代行依頼データの受信後は、Ｓ２２２において代行継続フラグをオンにする。これ以降、ＥＣＵ２Ｃは、第一ネットワーク１Ａ経由で依頼元装置であるＥＣＵ２Ｂ宛に認証対象データが伝送されるたびに、Ｓ３０６−Ｓ３３０を実行し、認証済みデータをＥＣＵ２Ｂへ送信する。したがって、ＥＣＵ２Ｂでは、認証対象データを受信するたびにＥＣＵ２Ｃに対して代行依頼データを送信しなくても、ＥＣＵ２Ｃから認証済みデータを継続的に受信することができる。よって、ＥＣＵ２Ｂが認証対象データを受信するたびにＥＣＵ２Ｃへ代行依頼データを送信するように構成されている場合に比べ、ＥＣＵ２Ｂにかかる負荷を軽減することができる。また、代行依頼データの送信頻度が低下する分だけ、第二ネットワーク１Ｂにかかる負荷も低減することができる。
【０１００】
また、本実施形態の場合、ＥＣＵ２Ｂは、外部ツールから代行中止要求が送信された際に、依頼状態にある場合には、依頼状態から非依頼状態に復帰する。ＥＣＵ２Ｃは、外部ツール９から代行中止要求が送信された際に、代行状態にある場合には、代行状態から非代行状態に復帰する。したがって、認証処理の代行が必要となっていた原因が修理等によって解消された際には、外部ツール９から代行中止要求を送信することにより、ＥＣＵ２Ｂ及びＥＣＵ２Ｃを容易に通常の状態に戻すことができる。これにより、ＥＣＵ２Ｂ及びＥＣＵ２Ｃには、認証処理の代行に起因する負荷がかからなくなり、ネットワークシステム１にかかる負荷を軽減することができる。
【０１０１】
また、本実施形態の場合、修理が実施された後、外部ツール９による代行中止要求の送信を契機として、ＥＣＵ２Ｂにおいて認証処理を実行することにより、ＥＣＵ２Ｂでの認証処理が実行できるようになったかどうかを判定することができる。
【０１０２】
また、本実施形態の場合、ＥＣＵ２Ｂは、代行中止要求に対する認証処理の結果を、ＥＣＵ２Ｃへ送信する。したがって、ＥＣＵ２Ｂでの認証が成立する状態にあるのか否かをＥＣＵ２Ｃへ伝達することができる。
【０１０３】
また、本実施形態の場合、ＥＣＵ２Ｃは、代行中止要求に対する認証処理の結果をＥＣＵ２Ｂから受信した場合に、ＥＣＵ２Ｃが代行状態から非代行状態に復帰する。したがって、ＥＣＵ２ＣでＥＣＵ２Ｂでの認証が成立しているか否かを把握しないまま、ＥＣＵ２Ｃ側だけの判断で代行を中止する場合に比べ、システム全体としての信頼性が向上する。
【０１０４】
また、本実施形態の場合、ＥＣＵ２Ｂは、外部ツール９から代行中止要求が送信された後、依頼状態にあるのか非依頼状態にあるのかを外部ツール９に対して通知する。したがって、外部ツール９において、ＥＣＵ２Ｂが依頼状態にあるのか非依頼状態にあるのかを把握することができる。したがって、例えば、外部ツール９においてＥＣＵ２Ｂの状態を表示することが可能となり、作業者はＥＣＵ２Ｂの状態を容易に知ることができるようになる。
【０１０５】
（２）第二実施形態
次に、第二実施形態について説明する。なお、第二実施形態は、第一実施形態で例示した構成の一部を変更した実施形態に相当する。そこで、以下の説明では、第一実施形態との相違点を中心に詳述し、第一実施形態と同様な部分に関しては、その詳細な説明を省略する。
【０１０６】
［依頼元装置及び依頼先装置において実行される処理の詳細］
第二実施形態のＥＣＵ２Ｃは、第一実施形態で図１０に例示した処理の代わりに、図１６に示す処理を実行する。図１６に示す処理では、図１０に示す処理に対してＳ２４３，Ｓ２４７，Ｓ２５２及びＳ２５４の各処理ステップが追加されている。図１６に示す処理を開始すると、ＥＣＵ２Ｃは、Ｓ２４２において、ＥＣＵ２Ｃにおける処理の状態が、「通常処理中」及び「代行実行中」のいずれであるのかを判断する。Ｓ２４２において「代行実行中」であった場合、ＥＣＵ２Ｃは、Ｓ２４３において、代行中止要求フラグがオンか否かを判断する。代行中止要求フラグがオンであった場合は、Ｓ２４３においてＹＥＳと判断され、ＥＣＵ２Ｃは、Ｓ２４４において、「代行実行中ＩＤの通知」をローカルバス６へ送信する。代行実行中ＩＤは、ＥＣＵ２Ｂから認証代行を依頼されていたＩＤである。
【０１０７】
続いて、ＥＣＵ２Ｃは、Ｓ２４６において、代行継続フラグをオフにする。続いて、ＥＣＵ２Ｃは、Ｓ２４７において、代行中止要求フラグをオフにする。そして、ＥＣＵ２Ｃは、Ｓ２４８において、ＥＣＵ２Ｃにおける処理の状態を「代行実行中」から「通常処理中」へ変更する。Ｓ２４８を終えたら、Ｓ２５４へ進み、ＥＣＵ２Ｃは、グローバルバス５Ｂ経由で外部ツール９へＥＣＵ２Ｃの状態を通知する。これにより、外部ツール９では、ＥＣＵ２Ｃの状態が代行実行中から通常処理中へ変更されたことを把握することができる。なお、外部ツール９では、ＥＣＵ２Ｃの状態が代行実行中から通常処理中へ変更された旨の表示を行ったり、ＥＣＵ２Ｃの状態が代行依頼中から通常処理中へ変更された旨のログを記録したりすることができる。Ｓ２５４を終えたら、図１６に示す処理を終了する。
【０１０８】
Ｓ２４３において代行中止要求フラグがオフであった場合はＮＯと判断され、ＥＣＵ２Ｃは、Ｓ２５２において、ＥＣＵ２Ｃにおける処理の状態を「代行実行中」のままとする。Ｓ２５２を終えたら、Ｓ２５４へ進み、ＥＣＵ２Ｃは、グローバルバス５Ｂ経由で外部ツール９へＥＣＵ２Ｃの状態を通知する。これにより、外部ツール９では、ＥＣＵ２Ｃの状態が代行実行中のままとされたことを把握することができる。Ｓ２５４を終えたら、図１６に示す処理を終了する。Ｓ２４２において「通常処理中」であった場合、Ｓ２５４へ進み、ＥＣＵ２Ｃは、グローバルバス５Ｂ経由で外部ツール９へＥＣＵ２Ｃの状態を通知する。これにより、外部ツール９では、ＥＣＵ２Ｃの状態が通常処理中であることを把握することができる。Ｓ２５４を終えたら、図１６に示す処理を終了する。
【０１０９】
第二実施形態のＥＣＵ２Ｃは、第一実施形態で図１１に例示した処理の代わりに、図１７に示す処理を実行する。図１７に示す処理では、図１１に示す処理に対してＳ３４２及びＳ３４４の各処理ステップが追加されている。図１７に示す処理を開始すると、ＥＣＵ２Ｃは、Ｓ３０２からＳ３０６までの各処理ステップを実行する。Ｓ３０２からＳ３０６までの各処理ステップは、第一実施形態と同様なので、第二実施形態での説明は省略する。Ｓ３０６において受信データが他のＥＣＵ宛ではない場合（すなわち、ＥＣＵ２Ｃ宛のデータである場合。）は、Ｓ３０６においてＮＯと判断され、その場合、ＥＣＵ２Ｃは、Ｓ３４２において、外部ツール９から送信される代行中止要求か否かを判断する。
【０１１０】
代行中止要求である場合は、Ｓ３４２においてＹＥＳと判断され、その場合、ＥＣＵ２Ｃは、Ｓ３４４において、代行中止要求に対応する処理を実行する。Ｓ３４４の詳細を図１８に示す。図１８に示す処理を開始すると、Ｓ３５２において、ＥＣＵ２Ｃは、メッセージ認証処理を実行する。このメッセージ認証処理は、図６に示した処理となる。ただし、図６に示した処理については既に詳細を説明したので、重ねての説明は省略する。Ｓ３５２においてメッセージ認証処理を実行する場合、図６のＳ１４２における「処理対象となるデータ」は、外部ツール９から受信した代行中止要求である。
【０１１１】
続いて、ＥＣＵ２Ｃは、Ｓ３５４において、認証が成立したか否かを判断する。Ｓ３５２で認証が成立している場合は、Ｓ３５４においてＹＥＳと判断され、Ｓ３５６へと進む。ＥＣＵ２Ｃは、Ｓ３５６において、ＥＣＵ２Ｃにおける処理の状態が、「通常処理中」及び「代行実行中」のいずれであるのかを判断する。Ｓ３５６において「通常処理中」であった場合、図１８に示す処理を終了する。これにより、図１７に示すＳ３４４を終了し、図１７に示す処理を終了する。
【０１１２】
一方、Ｓ３５６において、ＥＣＵ２Ｃにおける処理の状態が「代行実行中」であった場合、ＥＣＵ２Ｃは、Ｓ３５８において代行中止要求フラグをオンにして、図１８に示す処理を終了する。これにより、図１７に示すＳ３４４を終了し、図１７に示す処理を終了する。なお、Ｓ３５２で認証に失敗している場合は、Ｓ３５４においてＮＯと判断され、図１８に示す処理を終了する。これにより、図１７に示すＳ３４４を終了し、図１７に示す処理を終了する。
【０１１３】
［効果］
以上説明した第二実施形態のネットワークシステム１でも、第一実施形態と同様の作用、効果を奏する。したがって、例えば、ＥＣＵ２Ｂにおいて認証処理を実行するために必要となるハードウェア又はソフトウェアに故障等の問題が生じていたとしても、ＥＣＵ２ＢはＥＣＵ２Ｃにおいて認証された認証対象データの内容を利用して、所期の処理を実行することができる。
【０１１４】
また、第一実施形態同様、ＥＣＵ２Ｂでは、認証対象データを受信するたびにＥＣＵ２Ｃに対して代行依頼データを送信しなくても、ＥＣＵ２Ｃから認証済みデータを継続的に受信することができる。
【０１１５】
また、第一実施形態同様、ＥＣＵ２Ｂは、外部ツールから代行中止要求が送信された際に、依頼状態にある場合には、依頼状態から非依頼状態に復帰する。ＥＣＵ２Ｃは、外部ツール９から代行中止要求が送信された際に、代行状態にある場合には、代行状態から非代行状態に復帰する。したがって、認証処理の代行が必要となっていた原因が修理等によって解消された際には、外部ツール９から代行中止要求を送信することにより、ＥＣＵ２Ｂ及びＥＣＵ２Ｃを容易に通常の状態に戻すことができる。これにより、ＥＣＵ２Ｂ及びＥＣＵ２Ｃには、認証処理の代行に起因する負荷がかからなくなり、ネットワークシステム１にかかる負荷を軽減することができる。
【０１１６】
さらに、第二実施形態の場合、ＥＣＵ２Ｃは、外部ツール９から代行中止要求が送信された際に、第一ネットワーク１Ａ経由で代行中止要求を受信し、代行状態から非代行状態に復帰する。したがって、ＥＣＵ２Ｃでの認証代行を中止する際に、ＥＣＵ２Ｂに頼ることなく非代行状態に復帰することが可能となる。あるいは、ＥＣＵ２Ｃでの認証代行を中止する際に、自ら代行中止要求を受信するとともに、ＥＣＵ２Ｂから代行中止に関する情報を受け取ることもでき、この場合は、二重の確認をすることにより、システムの信頼性を向上させることができる。これらいずれの構成を採用するかは、システムにかかる負荷の軽減を重視するかシステムの信頼性向上を重視するかに応じて、所望の構成を採用すればよい。
【０１１７】
また、第二実施形態の場合、ＥＣＵ２Ｃが外部ツール９へＥＣＵ２Ｃの状態を通知するので、外部ツール９において、ＥＣＵ２Ｃが代行状態にあるのか非代行状態にあるのかを把握することができる。したがって、例えば、外部ツール９においてＥＣＵ２Ｃの状態を表示することが可能となり、作業者はＥＣＵ２Ｃの状態を容易に知ることができるようになる。
【０１１８】
（３）他の実施形態
以上、ネットワークシステムについて、例示的な実施形態を挙げて説明したが、上述の実施形態は本開示の一態様として例示されるものにすぎない。すなわち、本開示は、上述の例示的な実施形態に限定されるものではなく、本開示の技術的思想を逸脱しない範囲内において、様々な形態で実施することができる。
【０１１９】
例えば、上記実施形態では、ＥＣＵ２Ｂが依頼元装置となり、ＥＣＵ２Ｃが依頼先装置となる例を示したが、ＥＣＵ２Ａ〜２Ｄはいずれが依頼元装置となってもよい。また、ＥＣＵ２Ａ〜２Ｄのうち、依頼元装置以外のＥＣＵは、いずれが依頼先装置となってもよい。さらに、ＥＣＵ３Ａ〜３Ｈがローカルバス６に接続されていてもよく、その場合は、ＥＣＵ３Ａ〜３Ｈが依頼元装置又は依頼先装置となってもよい。
【０１２０】
また、上記実施形態では、メッセージ認証による認証処理を実施する例を示したが、メッセージ認証以外の方式で認証を行ってもよいし、メッセージ認証とメッセージ認証以外の方式とを併用してもよい。例えば、上記実施形態では、通常データと暗号データとを伝送し、受信側において通常データを暗号化して、その暗号化されたデータと暗号データとを比較して認証成立か否かを判断していたが、他の認証手順を採用することもできる。一例を挙げれば、例えば、通常データと暗号データとを伝送し、受信側において暗号データを復号して、その復号されたデータと通常データとを比較して認証成立か否かを判断してもよい。
【０１２１】
また、上記実施形態では、認証済みデータを送信する際にＣＶＮを送信することにより、受信側で認証済みデータの送信元が適正なノードか否かを確認するようにしていたが、認証済みデータの送信元が適正なノードか否かを確認できるような固有値を送信できれば、その固有値がＣＶＮであるか否かは任意である。さらに、上記実施形態で例示した仕組み以外に、認証済みデータの送信元が適正なノードか否かを確認可能な仕組みを別途備えている場合には、上記実施形態で例示した適正なノードか否かを確認する仕組みを省略してもよい。あるいは、認証済みデータの送信元が適正なノードであると十分に信頼できる場合についても、上記実施形態で例示した適正なノードか否かを確認する仕組みを省略してもよい。
【０１２２】
また、上記実施形態では、認証済みデータの送信元が適正なノードか否かを一度確認したら、二回目以降は確認を省略する例を示したが、二回目以降も同様な確認を省略することなく実施してもよい。
【０１２３】
また、上記実施形態では、単一のＣＧＷ４によって複数のグローバルバス５Ａ，５Ｂ，５Ｃを相互に接続していたが、複数のグローバルバス５Ａ，５Ｂ，５Ｃを相互に接続可能に構成されていれば、複数のゲートウェイを採用してもよい。例えば、第一のゲートウェイでグローバルバス５Ａとグローバルバス５Ｂとを接続し、第二のゲートウェイでグローバルバス５Ｂとグローバルバス５Ｃとを接続することにより、グローバルバス５Ａとグローバルバス５Ｃは、二つのゲートウェイ及びグローバルバス５Ｂを介して通信可能に構成されていてもよい。
【０１２４】
以上の他、上記各実施形態における一つの構成要素によって実現していた機能を、複数の構成要素によって実現するように構成してもよい。また、複数の構成要素によって実現していた機能を一つの構成要素によって実現するように構成してもよい。また、上記各実施形態の構成の一部を省略してもよい。また、上記各実施形態の構成の少なくとも一部を、他の上記実施形態の構成に対して付加、置換等してもよい。なお、特許請求の範囲に記載の文言から特定される技術思想に含まれる全ての態様が本開示の実施形態に該当する。
【０１２５】
また、上述したネットワークシステムの他、本開示のネットワークシステムを構成可能な電子装置、本開示のネットワークシステムを備えた車両、本開示でいう電子装置としてコンピュータを機能させるためのプログラム、このプログラムを記録した記録媒体など、種々の形態で本開示を実現することもできる。
【０１２６】
（４）補足
なお、以上説明した例示的な実施形態から明らかなように、本開示のネットワークシステムは、更に以下に挙げるような構成を備えていてもよい。
【０１２７】
まず、本開示のネットワークシステムにおいて、依頼元装置は、外部機器から送信された代行中止要求データを受信した際に（Ｓ１１０，Ｓ１０８）、代行中止要求データに対する認証処理を実行するように構成されていてもよい（Ｓ１１０，Ｓ１６２）。
【０１２８】
このように構成されたネットワークシステムによれば、電子装置や通信路に対する修理が実施された後、外部機器による代行中止要求データの送信を契機として、依頼元装置において認証処理を実行することにより、依頼元装置での認証処理が実行できるようになったかどうかを判定することができる。
【０１２９】
また、本開示のネットワークシステムにおいて、依頼元装置は、代行中止要求データに対する認証処理の結果を、依頼先装置へ送信するように構成されていてもよい（Ｓ１７２）。
【０１３０】
このように構成されたネットワークシステムによれば、依頼元装置での認証が成立する状態にあるのか否かを依頼先装置へ伝達することができる。
また、本開示のネットワークシステムにおいて、依頼先装置は、代行中止要求データに対する認証処理の結果を依頼元装置から受信した場合に（Ｓ２０２，Ｓ２０８）、代行状態から非代行状態に復帰するように構成されていてもよい（Ｓ２１０，Ｓ２４２−Ｓ２４８）。
【０１３１】
このように構成されたネットワークシステムによれば、依頼元装置での認証が成立する状態にある場合に、依頼先装置が代行状態から非代行状態に復帰する。したがって、依頼先装置で依頼元装置での認証が成立しているか否かを把握しないまま、依頼先装置側だけの判断で代行を中止する場合に比べ、システム全体としての信頼性が向上する。
【０１３２】
また、本開示のネットワークシステムにおいて、依頼先装置は、外部機器から代行中止要求データが送信された際に、第一ネットワーク経由で代行中止要求データを受信した場合に（Ｓ３０２，Ｓ３４２）、代行状態から非代行状態に復帰するように構成されていてもよい（Ｓ３４４，Ｓ３５２−Ｓ３５８）。
【０１３３】
このように構成されたネットワークシステムによれば、依頼先装置は、外部機器から代行中止要求データを受信すれば、代行状態から非代行状態に復帰する。したがって、依頼先装置での認証代行を中止する際に、依頼元装置には余計な負荷をかけなくても済む。
【０１３４】
また、本開示のネットワークシステムにおいて、依頼元装置は、外部機器から代行中止要求データが送信された後、依頼状態にあるのか非依頼状態にあるのかを外部機器に対して通知するように構成されていてもよい（Ｓ４４４）。
【０１３５】
このように構成されたネットワークシステムによれば、外部機器において、依頼元装置が依頼状態にあるのか非依頼状態にあるのかを把握することができる。したがって、例えば、外部機器において依頼元装置の状態を表示することが可能となり、作業者は依頼元装置の状態を容易に知ることができるようになる。
【０１３６】
また、本開示のネットワークシステムにおいて、依頼先装置は、外部機器から代行中止要求データが送信された後、代行状態にあるのか非代行状態にあるのかを外部機器に対して通知するように構成されていてもよい（Ｓ２５４）。
【０１３７】
このように構成されたネットワークシステムによれば、外部機器において、依頼先装置が代行状態にあるのか非代行状態にあるのかを把握することができる。したがって、例えば、外部機器において依頼先装置の状態を表示することが可能となり、作業者は依頼先装置の状態を容易に知ることができるようになる。
【符号の説明】
【０１３８】
１…ネットワークシステム、１Ａ…第一ネットワーク、１Ｂ…第二ネットワーク、２Ａ，２Ｂ，２Ｃ，２Ｄ，３Ａ，３Ｂ，３Ｃ，３Ｄ，３Ｅ，３Ｆ，３Ｇ，３Ｈ…ＥＣＵ、５Ａ，５Ｂ，５Ｃ…グローバルバス、６…ローカルバス、７…外部通信路、１１…ＣＰＵ、１２…ＲＡＭ、１２Ａ…受信データバッファ、１３…フラッシュメモリ、１３Ａ…共通鍵記憶部、１３Ｂ…ＣＶＮ記憶部、１６…第一通信部、１７…第二通信部。
【図１】
2019161259.tif 000003
【図２】
2019161259.tif 000004
【図３】
2019161259.tif 000005
【図４】
2019161259.tif 000006
【図５】
2019161259.tif 000007
【図６】
2019161259.tif 000008
【図７】
2019161259.tif 000009
【図８】
2019161259.tif 000010
【図９】
2019161259.tif 000011
【図１０】
2019161259.tif 000012
【図１１】
2019161259.tif 000013
【図１２】
2019161259.tif 000014
【図１３】
2019161259.tif 000015
【図１４】
2019161259.tif 000016
【図１５】
2019161259.tif 000017
【図１６】
2019161259.tif 000018
【図１７】
2019161259.tif 000019
【図１８】
2019161259.tif 000020