JP2015098312A

JP2015098312A - 車載ネットワークシステム

Info

Publication number: JP2015098312A
Application number: JP2013240226A
Authority: JP
Inventors: 康明森田; Yasuaki Morita
Original assignee: Toyota Motor Corp
Current assignee: Toyota Motor Corp
Priority date: 2013-11-20
Filing date: 2013-11-20
Publication date: 2015-05-28

Abstract

【課題】車両搭載前に認証のための情報を記憶させておくことなく、なりすましを検出可能な車載ネットワークシステムを提供すること。【解決手段】複数のＥＣＵ１００がネットワークを介して接続された車載ネットワークシステム５００において、各ＥＣＵは、工場出荷時の初回の起動時に、各ＥＣＵに一意の識別情報を有するメッセージを送信すると共に、他のＥＣＵから前記メッセージを受信して、該メッセージから抽出した前記識別情報が登録されたリスト１１を作成し、工場出荷後に起動した各ＥＣＵは、他のＥＣＵから受信した前記メッセージから抽出した前記識別情報が前記リストに登録されていない場合、異常検知処理を行う、ことを特徴とする。【選択図】図２

Description

本発明は、複数のＥＣＵがネットワークを介して接続された車載ネットワークシステムに関する。

車両には多くの電子制御装置（ＥＣＵ：Electronic Control Unit）が搭載されている。各電子制御装置は車載ＬＡＮに接続され、他の電子制御装置と通信しながら、車載装置を制御している。したがって、車載ＬＡＮに第三者の電子制御装置が接続され、元からある電子制御装置になりすまして（元からある電子制御装置と同じＩＤをデータに添付して送信する）データを送信する状況では、該データを受信した電子制御装置が正しい制御を行うことを保証できない。また、なりすました電子制御装置に他の電子制御装置がデータを送信しても所望の制御を行うことが困難になる。

このため、従来からなりすましを検出する技術が考案されている（例えば、特許文献１参照。）。特許文献１には、車両用認証システムに含まれる各ＥＣＵのメモリに外部装置の装置識別子を登録し、各ＥＣＵ１のＣＰＵが外部装置を認証する車両用認証システムが開示されている。したがって、悪意のある外部装置がＥＣＵと通信しようとしても認証が成立しないので、外部装置のなりすましを検出できる。

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

しかしながら、車載システムにおいては、特許文献１に記載されているように通信相手の装置の識別子を各電子制御装置が記憶することは困難であるという問題がある。

図１を用いて説明する。図１は、車載システム５００において各ＥＣＵ１００が他のＥＣＵ１００を認証する際の問題を説明する図の一例である。以下では、ＥＣＵ１００を区別するため、「ＥＣＵ_アルファベット」で記載する。ＥＣＵ_Ａ〜ＥＣＵ_Ｄは送信するメッセージに毎回、認証用のＩＤを付加する。受信側のＥＣＵ_Ａ〜ＥＣＵ_ＤはＩＤを取り出してＩＤが正当なＥＣＵから送信されたものかどうかを検証する。メッセージの送受信時に毎回、ＩＤの付加と抽出が必要なので、ＥＣＵ_Ａ〜ＥＣＵ_Ｄの処理負荷を圧迫してしまう。また、応答時間の制限が厳しい制御に用いられるメッセージの送受信では、処理負荷の増大を許容できない場合もある。

また、各メッセージに認証用のＩＤが付加されると、車載システム５００に流れるメッセージのデータ量が増大することでバス負荷が増大する。これにより、定期的なメッセージが遅延無く送信される設計上の許容範囲（元のバス負荷に対した数％〜数十％）を超えるおそれもある。

さらに、ＥＣＵの車両搭載前に認証対象のＥＣＵをメーカなどの担当者が全てリストアップすると膨大な数のＥＣＵのＩＤがあてはまる。これは、一般に、ＣＡＮバスにつながるＥＣＵを予め特定しておくことは困難なため、車載される可能性があるシステム、車両のグレード、仕向先、サプライヤ（電子制御装置のメーカ）の存在を考慮して搭載されうるＥＣＵを決定する必要があるためである。仮に認証対象の電子制御装置を全てリストアップした場合、その数は膨大になりリストを記憶しておくためのＲＯＭ（又はＲＡＭ）の容量を圧迫してしまうか、又は、容量の増大が必要になってしまう。

本発明は、上記課題に鑑み、車両搭載前に認証のための情報を記憶させておくことなく、なりすましを検出可能な電子制御装置を提供することを目的とする。

本発明は、上記課題に鑑み、複数のＥＣＵがネットワークを介して接続された車載ネットワークシステムにおいて、各ＥＣＵは、工場出荷時の初回の起動時に、各ＥＣＵに一意の識別情報を有するメッセージを送信すると共に、他のＥＣＵから前記メッセージを受信して、該メッセージから抽出した前記識別情報を登録したリストを作成し、工場出荷後に起動した各ＥＣＵは、他のＥＣＵから受信した前記メッセージから抽出した前記識別情報が前記リストに登録されていない場合、異常検知処理を行う、ことを特徴とする。

車両搭載前に認証のための情報を記憶させておくことなく、なりすましを検出可能な車載ネットワークシステムを提供することができる。

車載システムにおいて各ＥＣＵが他のＥＣＵを認証する際の問題を説明する図の一例である。本実施形態の車載システムがなりすましを検出する手順を示すシーケンス図の一例である。ポイント１〜３を説明する図の一例である。なりすましの検出を説明する図の一例である。＋Ｂ系ＥＣＵのＥＣＵリストの一例とＩＧ系ＥＣＵのＥＣＵリストの一例を示す図である。

以下、本発明を実施するための形態について図面を参照しながら説明する。
図２は、本実施形態の車載システムがなりすましを検出する手順を示すシーケンス図の一例である。各ＥＣＵ（Electronic Control Unit）は、ＣＡＮバス(車載ネットワーク)に接続されているＥＣＵがリストアップされたＥＣＵリストを作成する。ＥＣＵリストは初回バッテリ接続時又はＩＧ−ＯＮの時に作成され、以降は変更されない。このため、車載システム５００の動作手順としては大きく工場出荷時と工場出荷後に分けられる。なお、図２の車両２００はダイアグに対する処理を行う所定のＥＣＵである。

＜工場出荷時＞
工場出荷時、バッテリにＥＣＵ（以下、ＥＣＵ_Ａ〜ＥＣＵ_Ｃという）１００が接続される。ＥＣＵ_ＡとＥＣＵ_Ｂは＋Ｂ系のＥＣＵであるためこれにより起動する。また、ＥＣＵ_Ｃは初回のＩＧ（イグニッション）−ＯＮにより起動する。
・ポイント１：まず、ＥＣＵ_ＡとＥＣＵ_Ｂは動作を開始すると、特定のメッセージ（以下、特定メッセージという）を送信する。特定メッセージは識別子（後述するSource ID）を有するメッセージである。特定メッセージとその識別子はどちらも既存のものなので、バス負荷の増大を抑制できる。
・ポイント２：ＥＣＵ_ＢはＥＣＵ_Ａから特定メッセージを受信したことで、ＥＣＵリストにＥＣＵ_Ａの識別子を追加する。同様に、ＥＣＵ_Ａも、ＥＣＵ_Ｂから特定メッセージを受信したことで、ＥＣＵリストにＥＣＵ_Ｂの識別子を追加する。このように、実際に車載システムに存在するＥＣＵからメッセージを受信した場合にＥＣＵリストが作成されるので、ＲＯＭ容量を圧迫することを抑制できる。

なお、ＥＣＵ_Ｃは、ＩＧ-ＯＮにより電力が供給されるので、初回のＩＧ−ＯＮにより、同様にＥＣＵ_Ａ，ＥＣＵ_Ｂの識別子をＥＣＵリストに登録する。

＜工場出荷後＞
・ポイント３：ＥＣＵ_Ａ、ＥＣＵ_Ｂは２回目以降のバッテリ装着の直後、ＥＣＵ_Ｃは２回目以降のＩＧ−ＯＮの直後、特定メッセージを受信するとＥＣＵリストを参照して、ＥＣＵリストに存在しないＥＣＵから特定メッセージを受信したか否かを判断する。識別子は既存の特定メッセージに含まれているので、バス負荷が増大することもほとんどない。

ＥＣＵ_Ａ〜ＥＣＵ_Ｃがなりすましを検出した場合、異常検出（ダイアグ）を車両（所定のＥＣＵ）２００に送信する。これにより、所定のＥＣＵはメータパネルに異常ランプやメッセージを出力するので、ユーザは異常を検出できる。または、ユーザがなりすましのＥＣＵを装着していることを想定して車両の機能を停止する（ＩＧ−ＯＦＦする）。

以下、ポイント１〜３について詳細に説明する。

〔ポイント１特定メッセージの送信〕
図３は、ポイント１〜３を説明する図の一例である。なお、図３のシーケンス図は図２と同じものである。本実施例では特定メッセージとして、ＮMメッセージ又はＮＳメッセージの少なくとも一方を使用する。NM（Network Management）メッセージは、ＯＳＥＫ／ＶＤＸ―ＮＭの規定に基づく通信を行うＮＭと呼ばれるモジュールが送信するメッセージである。ＯＳＥＫ−ＮＭでは、ＣＡＮバスに接続された各ＥＣＵが、自身のスリープ可否を判別して、そのスリープ可否を示すＮＭ（Network Management）メッセージを定期的にＣＡＮバスへ送信するように規定されている。したがって、ＮＭモジュールを搭載したＥＣＵであれば、特定メッセージとしてＮＭメッセージを定期的に送信するため、他のＥＣＵはＮＭメッセージを受信できる。なお、ＮＭメッセージはＣＡＮプロトコルで送信されるメッセージであり、フォーマットや送信手順はＣＡＮプロトコルに従う。

図示するように、ＣＡＮプロトコルではメッセージのフォーマット（各フィールドに格納される情報）が定められている
「ＩＤ、ＤＬＣ、Source ID、DATA、CRC」
このうちＩＤフィールドには、ＣＡＮバスにおいてＥＣＵが搭載するＣＡＮコントローラに一意の識別子が格納される。なお、１つのＣＡＮコントローラが複数のＩＤを有する場合がある。ＥＣＵはＩＤを付してＣＡＮバスにメッセージを送信する。他のＥＣＵはＣＡＮバスに流れるメッセージのＩＤを監視して、メッセージを受信するか否かを判断する。よって、このＩＤはメッセージを識別する識別子といえる（特許請求の範囲の第１識別情報の一例である）。

ユーザは、Data Link Connectorなどにツールを接続することで、ＩＤを抽出できるので、該ＩＤを設定したＣＡＮコントローラ（例えば、パソコン、専用装置などのなりすまし装置）をＣＡＮバスに接続することでなりすましを行うことが困難ではない。

ＤＬＣフィールドはＤＡＴＡフィールドに格納されるデータサイズである。ＤＡＴＡフィールドには送信対象のデータが格納される。そしてNMモジュールはＤＡＴＡフィールドの先頭にSource IDを格納する。Source IDは各ＥＣＵ毎に一意の値が割り当てられている。すなわち、ＥＣＵが起動しても（バッテリ装着やＩＧ−ＯＮされても）他のＥＣＵと重複することや、値が変わることがない。本実施形態では、このSource IDをＥＣＵの識別子としてＥＣＵリスト１１に追加する（特許請求の範囲の第２識別情報の一例である）。

なお、ユーザにとって、Source IDが他のＥＣＵを認証するための情報として使用されていることを把握するのは困難であるため、なりすますことは困難である。

ＣＲＣフィールドにはメッセージの巡回冗長検査のためのＣＲＣ値が格納される。

ＮＭメッセージについては上記のとおりだが、ＮＭモジュールは、ＮＭメッセージの他にＮＳ（Network Status）メッセージを送信する場合がある。ＮＳメッセージはＥＣＵの状態を通知するメッセージであるが、ＮＭメッセージと同様に取り扱うことができる。したがって、各ＥＣＵが、他のＥＣＵがＥＣＵリスト１１を作成するために送信するメッセージは、ＮＭメッセージ又はＮＳメッセージのいずれでもよい。また、従来から各ＥＣＵが送信するメッセージで、ＥＣＵに個別の識別子を含むメッセージであれば、ＥＣＵリスト１１を作成するための特定メッセージとして使用できる。

図３（又は図２）に示すように、ＥＣＵ_ＡとＥＣＵ_Ｂは、工場出荷時に＋Ｂ電源と接続されることで電力が供給され起動する（Ｓ１，Ｓ２）。起動したＥＣＵ_ＡとＥＣＵ_Ｂは定期的なＮＭメッセージの送信を開始する（Ｓ３、Ｓ６）。

また、ＥＣＵ_Ｃは、工場出荷時の最初のＩＧ−ＯＮによりバッテリから電力が供給され起動する（Ｓ１１）。また、ＩＧ−ＯＮであることはＥＣＵ_Ａ、ＥＣＵ_ＢのＩＧＳＷ端子に入力され、ＥＣＵ_Ａ、ＥＣＵ_Ｂが検知する（Ｓ９，１０）。起動したＥＣＵ_Ｃは定期的なＮＭメッセージの送信を開始する（Ｓ１２）。

〔ポイント２ＥＣＵリストの作成〕
Source IDは各ＥＣＵに固有なので、各ＥＣＵは受信したＮＭメッセージから抽出したSource IDをそのままＥＣＵリスト１１に追加すること又は登録することができる。

また、ＥＣＵリスト１１には、Source IDだけでなく電源種類を登録することが好ましい。これにより、車両が＋Ｂ電源の状態の場合（ＩＧ−ＯＦＦの状態）では、ＩＧ系のＥＣＵはＮＭメッセージを送信しないため、＋Ｂ電源のＥＣＵが、ＩＧ系のＥＣＵに通信故障が生じたと誤判定することを防止することができる。なお、電源種類は、ＩＧ−ＯＦＦの場合にＮＭメッセージを受信したら送信元のＥＣＵが＋Ｂ電源であることがわかり、ＥＣＵリスト１１に登録されていないＥＣＵがＩＧ−ＯＮの場合にＮＭメッセージを送信した場合、該ＥＣＵはＩＧ電源であることがわかる。

したがって、各ＥＣＵは図示するようにSource IDと電源種別を対応づけてＥＣＵリスト１１に登録する。ＥＣＵリスト１１は不揮発性のメモリ（フラッシュメモリ、ＭＲＡＭ（Magnetoresistive Random Access Memory）、ReRAM（Resistive Random Access Memory）、FeRAM（Ferroelectric Random Access Memory））に記憶される。これにより、＋Ｂ電源のＥＣＵにおいてバッテリが外された場合、及び、ＩＧ系のＥＣＵにおいて車両がＩＧ−ＯＦＦ状態になった場合、ＥＣＵリスト１１が保持されなくなることを防止できる。

ＥＣＵリスト１１を作成するタイミングは、＋Ｂ電源のＥＣＵでは、工場出荷時の初回の＋Ｂ電源のＯＮ（バッテリ装着時）の直後から、遅くとも最初にバッテリが外されるまでの間である。ＩＧ系のＥＣＵでは、工場出荷時の初回のＩＧ−ＯＮ状態（遅くとも最初にＩＧ−ＯＦＦ状態になるまでに）である。こうすることで、工場出荷後に、ユーザなどがSource IDを含むＮＭメッセージを送信するなりすまし装置をＣＡＮバスに接続したとしても、ＥＣＵリスト１１に登録されないので、他のＥＣＵは、なりすまし装置が接続されたことを検出できる。

＋Ｂ電源のＥＣＵは、例えば、工場出荷時にはＯＮで初回の＋Ｂ電源のＯＦＦでＯＦＦとなるフラグを有しており、該フラグを参照することで、工場出荷時の初回の＋Ｂ電源のＯＮか否かを判断する。ＩＧ電源のＥＣＵも同様に、例えば、工場出荷時にはＯＮで初回のＩＧ-ＯＦＦでＯＦＦとなるフラグを有しており、該フラグを参照することで、工場出荷時の初回のＩＧ−ＯＮか否かを判断する。

また、このように初回起動時にしかＥＣＵリスト１１が作成されないことは、ＥＣＵリスト１１が１回しか作成されないことになるので、ＥＣＵリスト１１が作成済みか否かを判断してもよい。

工場出荷時のメーカの担当者は、各ＥＣＵがＥＣＵリスト１１を作成する十分な時間が経過すると、ＩＧ-ＯＦＦしさらにバッテリを外す。これにより、次回のバッテリ装着、及び、ＩＧ−ＯＮにより、各ＥＣＵはなりすましを検出する処理を行うことができる。

本実施形態で作成されるＥＣＵリスト１１では、登録されるＥＣＵの最大数が予め明らかになっている。すなわち、ＣＡＮバスに接続可能な数よりも多いＥＣＵは接続できないので、ＥＣＵリスト１１に登録されるＥＣＵの最大数は、ＣＡＮバスに接続可能なＥＣＵの数である（例えば、数十個）。したがって、「１つのレコード（Source IDと電源種類）のバイト数×最大数」だけＲＯＭの領域を確保しておけばよく、ＲＯＭの容量を圧迫することはほとんど無い。

図３（又は図２）に示すように、ＥＣＵ_ＡとＥＣＵ_Ｂは、工場出荷時に起動した直後、ＥＣＵリスト１１を作成する。具体的には、ＥＣＵ_Ａは、自身が送信したＮＭメッセージをＣＡＮコントローラが受信する仕組みを利用して、又は、送信したＮＭメッセージからSource IDを抽出して、自身のＥＣＵリスト１１に追加する（Ｓ４）。また、ＥＣＵ_Ａは、ＥＣＵ_Ｂが送信したＮＭメッセージを受信してＥＣＵ_Ｂを自身のＥＣＵリスト１１に追加する（Ｓ８）。

そして、ＥＣＵ_Ａは、ＥＣＵ_ＣがＩＧ−ＯＮで起動して、ＥＣＵ_ＣがＮＭメッセージの送信を開始すると、ＮＭメッセージを受信して、ＥＣＵ_Ｃを自身のＥＣＵリスト１１に追加する（Ｓ１５）。

同様に、ＥＣＵ_Ｂは、ＥＣＵ_Ａが送信したＮＭメッセージを受信してＥＣＵ_Ａを自身のＥＣＵリスト１１に追加する（Ｓ５）。また、ＥＣＵ_Ｂは、自身が送信したＮＭメッセージをＣＡＮコントローラが受信する仕組みを利用して、又は、送信したＮＭメッセージからSource IDを抽出して、自身のＥＣＵリスト１１に追加する（Ｓ７）。

また、ＥＣＵ_Ｂは、ＥＣＵ_ＣがＩＧ−ＯＮで起動して、ＥＣＵ_ＣがＮＭメッセージの送信を開始すると、ＮＭメッセージを受信して、ＥＣＵ_Ｃを自身のＥＣＵリスト１１に追加する（Ｓ１４）。

ＥＣＵ_Ｃは、工場出荷時のＩＧ−ＯＮで起動した直後、ＥＣＵリスト１１を作成する。具体的には、ＥＣＵ_Ｃは、自身が送信したＮＭメッセージをＣＡＮコントローラが受信する仕組みを利用して、又は、送信したＮＭメッセージからSource IDを抽出して、自身のＥＣＵリスト１１に追加する（Ｓ１３）。また、ＥＣＵ_Ａ及びＥＣＵ_Ｂが送信したＮＭメッセージを受信して、ＥＣＵ_ＡとＥＣＵ_Ｂを自身のＥＣＵリスト１１に追加する（Ｓ１６）。

〔ポイント３なりすましの検出〕
ユーザなどが、工場出荷後に２回目以降のバッテリ装着を行うか、又は、ＩＧ−ＯＮ状態に操作すると、ＥＣＵ_Ａ〜ＥＣＵ_Ｃが起動する（Ｓ１７〜Ｓ１９）。ＥＣＵ_Ａ〜ＥＣＵ_Ｃは、フラグなどを確認して最初の＋Ｂ電源ＯＮでないと判定するか、又は、最初のＩＧ−ＯＮでないと判定すると、ＮＭメッセージを受信する毎に、ＥＣＵリスト１１を参照してなりすまし装置が存在しないかを判断する（Ｓ２０）。この判断については後に詳細に説明する。

ＥＣＵリスト１１に登録されていないＥＣＵが存在した場合、ＥＣＵ_Ａ〜ＥＣＵ_Ｃはダイアグを車両の所定のＥＣＵに送信する（Ｓ２１）。

これにより、車両２００は、ユーザへの通知、ＩＧ−ＯＦＦやメインシステムを停止するなどの異常検知処理を行うことができる（Ｓ２２）。

〔なりすましの検出の詳細〕
図４は、なりすましの検出を説明する図の一例である。
S100：図４（ａ）に示すように、２回目以降に起動したＥＣＵ_Ａ〜ＥＣＵ_ＤはそれぞれＮＭメッセージを送信する。
S200：ＥＣＵ_Ａ〜ＥＣＵ_ＤのSource IDは、各ＥＣＵのＥＣＵリスト１１に登録されているため、なりすまし装置は無いと判断される。
S300：しかし、ＥＣＵ_ＥがＮＭメッセージを送信した場合、図４（ｂ）に示すように、ＥＣＵ_ＥのSource IDはＥＣＵ_Ａ〜ＥＣＵ_ＤのＥＣＵリスト１１に登録されていないので、ＥＣＵ_Ａ〜ＥＣＵ_Ｄはダイアグを検知することができる。

続いて、ＥＣＵリスト１１の検索について説明する。図５（ａ）は＋Ｂ系のＥＣＵのＥＣＵリスト１１の一例を、図５（ｂ）はＩＧ系のＥＣＵのＥＣＵリスト１１の一例を、それぞれ示す。なお、図５では電源種類を省略した。

ＮＭモジュールを有するＥＣＵは、ＮＭモジュールの機能により、定期的なタイミングとして自分の前にＮＭメッセージを送信するＥＣＵと自分の後に送信するＥＣＵを把握している。この順番は、Source IDの小さい順である。したがって、ＥＣＵリスト１１を昇順にソートしておけば、自分が送信した後にＮＭメッセージを送信するＥＣＵのSource IDを推定できる。例えば、自ノードのSource IDが「081h」の場合、自分が送信した後にＮＭメッセージを送信するＥＣＵのSource IDは「0A0h」であるので、すぐに検索に適合するか否かを判断できる。

自ノードの次の次にＮＭメッセージを送信するＥＣＵのSource IDは「0A6h」であるので、自分のSource IDの２つ下のSource IDを検索する。したがって、自分がNMメッセージを送信した後、受信したＮＭメッセージの数を測定しておくことで、最低１回の検索で適合するか否かを判断できる。

なお、必ずしもSource IDの順番に送信しないＥＣＵやウェイクアップ処理のリトライなどで検索に適合しない場合があるので、その場合は各ＥＣＵはクイックソートでＥＣＵリスト１１を検索する。

また、ＩＧ系のＥＣＵの場合、ＮＭメッセージの送信順序は定められていないので、例えばクイックソートで検索する。

以上説明したように、本実施形態のＥＣＵ（電子制御装置）は、各ＥＣＵが、特定メッセージが予め有している識別子を工場出荷時にＥＣＵリストに追加するため、ＥＣＵリストが記憶されるＲＯＭ容量が圧迫されることを抑制できる。ＣＡＮバスに送信されるメッセージのサイズが大きくなることがないので、ＣＡＮバスの処理負荷を増大させることがない。また、特定メッセージにおけるSource IDは、従来から追加及び抽出されているので各ＥＣＵの処理負荷が増大することがほとんどない。

また、本発明を実施するための最良の形態について実施例を用いて説明したが、本発明はこうした実施例に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。

例えば、本実施形態ではＣＡＮプロトコルで通信する場合を説明したが、ＮＭメッセージ／ＮＳメッセージ又はこれと同等の機能（定期送信されSource IDを有している）を有するメッセージを送信可能なプロトコルに適用できる。例えば、イーサネット（登録商標）、ＭＯＳＴ（Media Oriented Systems Transport）、ＦｌｅｘＲａｙ等の適切な通信プロトコルにおいても適用可能である。

また、本実施形態では、工場出荷時の最初の起動時に車両内のＥＣＵをＥＣＵリストに登録したが、車外のサーバなどをＥＣＵリストに登録してもよい。この場合、サーバが例えばＮＭメッセージを送信すればよい。

１００ＥＣＵ
２００車両
５００車載システム

Claims

複数のＥＣＵがネットワークを介して接続された車載ネットワークシステムにおいて、
各ＥＣＵは、工場出荷時の初回の起動時に、各ＥＣＵに一意の識別情報を有するメッセージを送信すると共に、他のＥＣＵから前記メッセージを受信して、該メッセージから抽出した前記識別情報を登録したリストを作成し、
工場出荷後に起動した各ＥＣＵは、他のＥＣＵから受信した前記メッセージから抽出した前記識別情報が前記リストに登録されていない場合、異常検知処理を行う、
ことを特徴とする車載ネットワークシステム。