知財求人 - 知財ポータルサイト「IP Force」
特許7630150コントローラ領域ネットワーク侵入探知システムおよびその作動方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2025-02-06
(45)【発行日】2025-02-17
(54)【発明の名称】コントローラ領域ネットワーク侵入探知システムおよびその作動方法
(51)【国際特許分類】
H04L 43/04 20220101AFI20250207BHJP
G06F 21/55 20130101ALI20250207BHJP
【ＦＩ】
H04L43/04
G06F21/55 320
【請求項の数】
18
(21)【出願番号】P 2023195723
(22)【出願日】2023-11-17
【審査請求日】2023-11-17
(31)【優先権主張番号】10-2023-0135377
(32)【優先日】2023-10-11
(33)【優先権主張国・地域又は機関】KR
(73)【特許権者】
【識別番号】319016563
【氏名又は名称】アウトクリプト カンパニー リミテッド
(74)【代理人】
【識別番号】100121728
【弁理士】
【氏名又は名称】井関 勝守
(74)【代理人】
【識別番号】100165803
【弁理士】
【氏名又は名称】金子 修平
(74)【代理人】
【識別番号】100179648
【弁理士】
【氏名又は名称】田中 咲江
(74)【代理人】
【識別番号】100222885
【弁理士】
【氏名又は名称】早川 康
(74)【代理人】
【識別番号】100140338
【弁理士】
【氏名又は名称】竹内 直樹
(74)【代理人】
【識別番号】100227695
【弁理士】
【氏名又は名称】有川 智章
(74)【代理人】
【識別番号】100170896
【弁理士】
【氏名又は名称】寺薗 健一
(74)【代理人】
【識別番号】100219313
【弁理士】
【氏名又は名称】米口 麻子
(74)【代理人】
【識別番号】100161610
【弁理士】
【氏名又は名称】藤野 香子
(72)【発明者】
【氏名】金徳洙
(72)【発明者】
【氏名】金義錫
(72)【発明者】
【氏名】沈相奎
(72)【発明者】
【氏名】朱岐昊
(72)【発明者】
【氏名】李廷元
(72)【発明者】
【氏名】李鍾國
(72)【発明者】
【氏名】金政▲ウク▼
(72)【発明者】
【氏名】李相▲ソク▼
(72)【発明者】
【氏名】徐英莞
(72)【発明者】
【氏名】河施湖
(72)【発明者】
【氏名】李永大
【審査官】岩田 玲彦
(56)【参考文献】
【文献】米国特許出願公開第２０２１／０１７６２５９（ＵＳ，Ａ１）
【文献】中国特許出願公開第１１４９７８６３０（ＣＮ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｌ ４３／０４
Ｇ０６Ｆ ２１／５５
(57)【特許請求の範囲】
【請求項1】
ハードウェア上に搭載されるＥＣＵ（ｅｌｅｃｔｒｏｎｉｃ ｃｏｎｔｒｏｌ ｕｎｉｔ）階層またはＡＵＴＯＳＡＲ階層；前記ＡＵＴＯＳＡＲ階層の構成要素とアプリケーション（ａｐｐｌｉｃａｔｉｏｎ、Ａｐｐ）を連結するＲＴＥ（ｒｅａｌ ｔｉｍｅ ｅｎｖｉｒｏｎｍｅｎｔ）またはインターフェース（ｉｎｔｅｒｆａｃｅ）；および前記アプリケーション上に搭載されるＩＤＳコア階層（ＩＤＳ ｃｏｒｅ ｌａｙｅｒ）とＩＤＳ探知階層（ＩＤＳ ｄｅｔｅｃｔ ｌａｙｅｒ）を含むコントローラ領域ネットワーク（ｃｏｎｔｒｏｌｌｅｒ ａｒｅａ ｎｅｔｗｏｒｋ、ＣＡＮ）侵入探知システム（ｉｎｔｒｕｓｉｏｎ ｄｅｔｅｃｔｉｏｎ ｓｙｓｔｅｍ、ＩＤＳ）の作動方法であって、前記ＡＵＴＯＳＡＲ階層のＣＡＮパケットミラーリングシステム（ＣＡＮ ｐａｃｋｅｔ ｍｉｒｒｏｒｉｎｇ ｓｙｓｔｅｍ）により、前記ＡＵＴＯＳＡＲ階層のＡＵＴＯＳＡＲ Ｐｄｕルータ（ＰｄｕＲ）領域に存在するＣＡＮドライバからＣＡＮメッセージを受信する段階；
前記ＣＡＮパケットミラーリングシステムによって、受信したＣＡＮメッセージをメモリの複数の保存領域に保存する段階；
前記ＩＤＳコア階層のＩＤＳコアによって、前記ＣＡＮパケットミラーリングシステムでコピーされたデータを読み込んで前記ＩＤＳコアの探知エンジンベースに伝達する段階；および
前記ＩＤＳコア階層のＩＤＳコアによって、ＩＤＳの政策ルール（ｐｏｌｉｃｙ ｒｕｌｅ）の政策バイナリファイル（ｐｏｌｉｃｙ ｂｉｎａｒｙ ｆｉｌｅ）を保存する第１メモリ領域と前記ＣＡＮメッセージをバッファリングし保存するためのバッファリングテーブル（ｂｕｆｆｅｒｉｎｇ ｔａｂｌｅ）を保存する第２メモリ領域を分けて管理する段階；を含み、
前記ＣＡＮパケットミラーリングシステムによって、前記メモリの第１共有型メモリ領域に保存されているＣＡＮ標準メッセージデータを第１エンジンメモリ領域にコピーして保存し、前記メモリの第２共有型メモリ領域に保存されているＣＡＮ ＦＤ（ｆｌｅｘｉｂｌｅ ｄａｔａ）メッセージデータを第２エンジンメモリ領域にコピーして保存する段階をさらに含む、コントローラ領域ネットワーク侵入探知システムの作動方法。
【請求項2】
前記ＩＤＳコアによって、前記ＣＡＮパケットミラーリングシステムでコピーされたデータを前記探知エンジンベースに伝達する前に共有型メモリからデータをエンジンメモリにコピーして持ってくる段階をさらに含み、ここでエンジンメモリに持ってきたＣＡＮメッセージはバッファリングテーブルに保存される、請求項１に記載のコントローラ領域ネットワーク侵入探知システムの作動方法。
【請求項3】
前記ＩＤＳコアによって、前記ＣＡＮメッセージをバッファリングテーブルに保存するために、先だって持ってきたＣＡＮメッセージのバス（ｂｕｓ）情報とＣＡＮ ＩＤ（ＩＤ：ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）を通じて政策バイナリファイル（ｐｏｌｉｃｙ ｂｉｎａｒｙ ｆｉｌｅ）のルックアップテーブル（ｌｏｏｋｕｐ ｔａｂｌｅ）を検索する段階をさらに含む、請求項２に記載のコントローラ領域ネットワーク侵入探知システムの作動方法。
【請求項4】
前記ＩＤＳコアによって、先立って検索したＣＡＮメッセージのバッファリングテーブルタイプ（ｂｕｆｆｅｒｉｎｇ ｔａｂｌｅ ｔｙｐｅ）情報を通じて前記メモリの特定保存領域にＣＡＮメッセージを保存する段階をさらに含み、ここで前記バッファリングテーブルタイプ情報はバッファタイプ（ｂｕｆｆｅｒ ｔｙｐｅ）情報およびバッファインデックス（ｂｕｆｆｅｒ ｉｎｄｅｘ）情報を含む、請求項３に記載のコントローラ領域ネットワーク侵入探知システムの作動方法。
【請求項5】
前記ＩＤＳコアによって、前記ルックアップテーブルを検索して一致する情報がない場合、前記ＣＡＮメッセージに対してバッファリングが必要でない場合、そして、バッファリングされた場合に対する処理をしなければならない場合から選択される少なくともいずれか一つで前記ＣＡＮメッセージを処理する段階をさらに含む、請求項４に記載のコントローラ領域ネットワーク侵入探知システムの作動方法。
【請求項6】
前記ＩＤＳコアによって、エンジンメモリから持ってきたＣＡＮメッセージのバスとＣＡＮ ＩＤに基づいてバイナリ検索を通じてルックアップテーブル（ｌｏｏｋｕｐ ｔａｂｌｅ）で探知政策を検索する段階をさらに含む、請求項５に記載のコントローラ領域ネットワーク侵入探知システムの作動方法。
【請求項7】
前記ＩＤＳコアによって、前記ルックアップテーブルで一致する政策がない時、アンノウンメッセージバッファリングテーブル情報を通じてメモリのバッファリングテーブルのアンノウンメッセージバッファに前記ＣＡＮメッセージを保存する段階；前記ＩＤＳコアによって、保存されたメッセージのヘッド（ｈｅａｄ）値を一つ増加させる段階；および
前記ＩＤＳコアによって、現在コピーした項目のバッファリングテーブルのアドレス、探知政策ルールに対するアドレス、バッファタイプとバッファインデックスに対する情報をインターフェースを通じて前記探知エンジンベースに伝達する段階をさらに含む、請求項６に記載のコントローラ領域ネットワーク侵入探知システムの作動方法。
【請求項8】
前記ＩＤＳコアによって、前記ルックアップテーブルで一致する探知政策が検索されると、該当ＣＡＮメッセージのバッファリングテーブルタイプ情報を通じてメモリのバッファリングテーブルに該当ＣＡＮメッセージを保存する段階；前記ＩＤＳコアによって、保存されたメッセージのヘッド（ｈｅａｄ）値を一つ増加させる段階；および
前記ＩＤＳコアによって、現在コピーした項目のバッファリングテーブルのアドレス、探知政策ルールに対するアドレス、バッファタイプとバッファインデックスに対する情報をインターフェースを通じて前記探知エンジンベースに伝達する段階をさらに含む、請求項６に記載のコントローラ領域ネットワーク侵入探知システムの作動方法。
【請求項9】
前記ＩＤＳコアによって、前記ルックアップテーブルでＣＡＮメッセージと一致する探知政策が検索される時、該当ＣＡＮメッセージのバッファリングテーブルタイプ情報を通じてメモリ領域のバッファリングテーブルに該当ＣＡＮメッセージを保存する段階；前記ＩＤＳコアによって、前記バッファリングテーブルタイプ情報のバッファインデックスが０、ヌル（ｎｕｌｌ）、非活性あるいは重要でない（ｍｉｎｏｒ）であるかを判断する段階；および
前記ＩＤＳコアによって、該当ＣＡＮメッセージがバッファリングが必要でないメッセージであることを判断する段階をさらに含む、請求項６に記載のコントローラ領域ネットワーク侵入探知システムの作動方法。
【請求項10】
前記ＩＤＳコアによって、該当ＣＡＮメッセージをバッファリングテーブルに保存せず、現在コピーした項目のメッセージアドレス、探知政策ルールに対するアドレス情報をインターフェースを通じて前記探知エンジンベースに伝達する段階を含む、請求項９に記載のコントローラ領域ネットワーク侵入探知システムの作動方法。
【請求項11】
コントローラ領域ネットワーク（ｃｏｎｔｒｏｌｌｅｒ ａｒｅａ ｎｅｔｗｏｒｋ、ＣＡＮ）侵入探知システム（ｉｎｔｒｕｓｉｏｎ ｄｅｔｅｃｔｉｏｎ ｓｙｓｔｅｍ、ＩＤＳ）であって、ハードウェア上に搭載されるＥＣＵ（ｅｌｅｃｔｒｏｎｉｃ ｃｏｎｔｒｏｌ ｕｎｉｔ）階層またはＡＵＴＯＳＡＲ階層；
前記ＡＵＴＯＳＡＲ階層の構成要素とアプリケーション（ａｐｐｌｉｃａｔｉｏｎ、Ａｐｐ）を連結するＲＴＥ（ｒｅａｌ ｔｉｍｅ ｅｎｖｉｒｏｎｍｅｎｔ）またはインターフェース（ｉｎｔｅｒｆａｃｅ）；および
前記アプリケーション上に搭載されるＩＤＳコア階層（ＩＤＳ ｃｏｒｅ ｌａｙｅｒ）とＩＤＳ探知階層（ＩＤＳ ｄｅｔｅｃｔ ｌａｙｅｒ）を含み、
前記ＡＵＴＯＳＡＲ階層はＣＡＮパケットミラーリングシステム（ＣＡＮ ｐａｃｋｅｔ ｍｉｒｒｏｒｉｎｇ ｓｙｓｔｅｍ）を具備し、
前記ＣＡＮパケットミラーリングシステムは前記ＡＵＴＯＳＡＲ階層のＡＵＴＯＳＡＲ
Ｐｄｕルータ（ＰｄｕＲ）領域に存在するＣＡＮドライバからＣＡＮメッセージを受信し、受信したＣＡＮメッセージをメモリの複数の保存領域に保存し、前記複数の保存領域は共有型メモリ（ｓｈａｒｅｄ ｍｅｍｏｒｙ）として互いに分離されて管理され、
前記ＩＤＳコア階層のＩＤＳコアは前記ＣＡＮパケットミラーリングシステムでコピーされたデータを読み込んで前記ＩＤＳコアの探知エンジンベースに伝達し、ＩＤＳの政策ルール（ｐｏｌｉｃｙ ｒｕｌｅ）の政策バイナリファイル（ｐｏｌｉｃｙ ｂｉｎａｒｙ ｆｉｌｅ）を保存する第１メモリ領域と前記ＣＡＮメッセージをバッファリングし保存するためのバッファリングテーブル（ｂｕｆｆｅｒｉｎｇ ｔａｂｌｅ）を保存する第２メモリ領域を分けて管理し、
前記ＣＡＮパケットミラーリングシステムは、前記メモリの第１共有型メモリ領域に保存されているＣＡＮ標準メッセージデータを第１エンジンメモリ領域にコピーして保存し、前記メモリの第２共有型メモリ領域に保存されているＣＡＮ ＦＤ（ｆｌｅｘｉｂｌｅ ｄａｔａ）メッセージデータを第２エンジンメモリ領域にコピーして保存する、コントローラ領域ネットワーク侵入探知システム。
【請求項12】
前記ＩＤＳコアは前記ＣＡＮパケットミラーリングシステムでコピーされたデータを前記探知エンジンベースに伝達する前に共有型メモリからデータをエンジンメモリにコピーして持ってき、ここでエンジンメモリに持ってきたＣＡＮメッセージはバッファリングテーブルに保存される、請求項１１に記載のコントローラ領域ネットワーク侵入探知システム。
【請求項13】
前記ＩＤＳコアは、前記ＣＡＮメッセージをバッファリングテーブルに保存するために、持ってきたＣＡＮメッセージのバス（ｂｕｓ）情報とＣＡＮ ＩＤ（ＩＤ：ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）を通じて政策バイナリファイル（ｐｏｌｉｃｙ ｂｉｎａｒｙ ｆｉｌｅ）のルックアップテーブル（ｌｏｏｋｕｐ ｔａｂｌｅ）を検索する、請求項１２に記載のコントローラ領域ネットワーク侵入探知システム。
【請求項14】
前記ＩＤＳコアは、先立って検索したＣＡＮメッセージのバッファリングテーブルタイプ（ｂｕｆｆｅｒｉｎｇ ｔａｂｌｅ ｔｙｐｅ）情報を通じて前記メモリの特定保存領域にＣＡＮメッセージを保存し、ここで前記バッファリングテーブルタイプ情報はバッファタイプ（ｂｕｆｆｅｒ ｔｙｐｅ）情報およびバッファインデックス（ｂｕｆｆｅｒ ｉｎｄｅｘ）情報を含む、請求項１３に記載のコントローラ領域ネットワーク侵入探知システム。
【請求項15】
前記ＩＤＳコアは、前記ルックアップテーブルを検索して一致する情報がない場合、前記ＣＡＮメッセージに対してバッファリングが必要でない場合、そして、バッファリングされた場合に対する処理をしなければならない場合から選択される少なくともいずれか一つで前記ＣＡＮメッセージを処理する、請求項１４に記載のコントローラ領域ネットワーク侵入探知システム。
【請求項16】
前記ＩＤＳコアはエンジンメモリから持ってきたＣＡＮメッセージのバスとＣＡＮ ＩＤに基づいてバイナリ検索を通じてルックアップテーブル（ｌｏｏｋｕｐ ｔａｂｌｅ）で探知政策を検索し；前記ルックアップテーブルで一致する政策がない時、アンノウンメッセージバッファリングテーブル情報を通じてメモリのバッファリングテーブルのアンノウンメッセージバッファに前記ＣＡＮメッセージを保存し；保存されたメッセージのヘッド（ｈｅａｄ）値を一つ増加させ；現在コピーした項目のバッファリングテーブルのアドレス、探知政策ルールに対するアドレス、バッファタイプとバッファインデックスに対する情報をインターフェースを通じて前記探知エンジンベースに伝達する、請求項１５に記載のコントローラ領域ネットワーク侵入探知システム。
【請求項17】
前記ＩＤＳコアはエンジンメモリから持ってきたＣＡＮメッセージのバスとＣＡＮ ＩＤに基づいてバイナリ検索を通じてルックアップテーブル（ｌｏｏｋｕｐ ｔａｂｌｅ）で探知政策を検索し；前記ルックアップテーブルで一致する政策またはメッセージが検索されると、該当ＣＡＮメッセージのバッファリングテーブルタイプ情報を通じてメモリのバッファリングテーブルに該当ＣＡＮメッセージを保存し；保存されたメッセージのヘッド（ｈｅａｄ）値を一つ増加させ；現在コピーした項目のバッファリングテーブルのアドレス、探知政策ルールに対するアドレス、バッファタイプとバッファインデックスに対する情報をインターフェースを通じて前記探知エンジンベースに伝達する、請求項１５に記載のコントローラ領域ネットワーク侵入探知システム。
【請求項18】
前記ＩＤＳコアはエンジンメモリから持ってきたＣＡＮメッセージのバスとＣＡＮ ＩＤに基づいてルックアップテーブル（ｌｏｏｋｕｐ ｔａｂｌｅ）で２進検索を通じて探知政策を検索し；前記ルックアップテーブルでＣＡＮメッセージと一致する探知政策が検索されると、該当ＣＡＮメッセージのバッファリングテーブルタイプ情報を通じてメモリ領域のバッファリングテーブルに該当ＣＡＮメッセージを保存し；前記バッファリングテーブルタイプ情報のバッファインデックスが０、ヌル（ｎｕｌｌ）、非活性あるいは重要でない（ｍｉｎｏｒ）である場合、該当ＣＡＮメッセージがバッファリングが必要でないメッセージであることを判断し；該当ＣＡＮメッセージをバッファリングテーブルに保存せず、現在コピーした項目のメッセージアドレス、探知政策ルールに対するアドレス情報をインターフェースを通じて前記探知エンジンベースに伝達する、請求項１５に記載のコントローラ領域ネットワーク侵入探知システム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は侵入探知システム（ｉｎｔｒｕｓｉｏｎ ｄｅｔｅｃｔｉｏｎ ｓｙｓｔｅｍ、ＩＤＳ）に関し、より詳細には、コントローラ領域ネットワーク（ｃｏｎｔｒｏｌｌｅｒ ａｒｅａ ｎｅｔｗｏｒｋ、ＣＡＮ）の侵入を探知する侵入探知システムおよびその作動方法に関する。
【背景技術】
【0002】
車両用部品の電子化が急速に進行されるにつれて、車両に搭載される電子装置例えば、ＥＣＵ（ｅｌｅｃｔｒｏｎｉｃ ｃｏｎｔｒｏｌ ｕｎｉｔ）の種類と数が大きく増加している。電子装置は大きくパワートレイン（ｐｏｗｅｒ ｔｒａｉｎ）制御システム、ボディ（ｂｏｄｙ）制御システム、シャーシ（ｃｈａｓｓｉｓ）制御システム、車両ネットワーク（ｎｅｔｗｏｒｋ）、マルチメディア（ｍｕｌｔｉｍｅｄｉａ）システムなどに区分される。ここで、パワートレイン制御システムはエンジン制御システム、自動変速制御システムなどを含む。ボディ制御システムはボディ電装品制御システム、便宜装置制御システム、ランプ（ｌａｍｐ）制御システムなどを含む。シャーシ制御システムは操向装置制御システム、ブレーキ（ｂｒａｋｅ）制御システム、サスペンション（ｓｕｓｐｅｎｓｉｏｎ）制御システムなどを含む。
【0003】
車両ネットワークはＣＡＮ（ｃｏｎｔｒｏｌｌｅｒ ａｒｅａ ｎｅｔｗｏｒｋ）、フレックスレイ（ＦｌｅｘＲａｙ）基盤のネットワーク、ＭＯＳＴ（ｍｅｄｉａ ｏｒｉｅｎｔｅｄ ｓｙｓｔｅｍ ｔｒａｎｓｐｏｒｔ）基盤のネットワークなどを含む。マルチメディアシステムは航法装置システム、テレマティクス（ｔｅｌｅｍａｔｉｃｓ）システム、インフォテインメント（ｉｎｆｏｒｔａｉｎｍｅｎｔ）システムなどを含む。
【0004】
このようなシステムやシステムそれぞれに搭載された電子装置は車両ネットワークを通じて連結されており、電子装置それぞれの機能を支援するための車両ネットワークが要求されているのが実情である。ＣＡＮは最大１Ｍｂｐｓの伝送速度を支援することができ、衝突したフレームの自動再伝送、ＣＲＣ（ｃｙｃｌｅ ｒｅｄｕｎｄａｎｃｙ ｃｈｅｃｋ）基盤のエラー検出などを支援することができる。
【0005】
最近車両内ＣＡＮは自動車ハッキング技法に悪用される頻度が増加している。すなわち、攻撃者らは自動車内の部品を繋いてくれる通信網であるＣＡＮに連結されたいずれかのＥＣＵを操作して、車両を停止させたりドアや窓を開閉したり、ラジオを任意に操作したりしている。
【0006】
このように、ＣＡＮ基盤プラットフォーム、特に自動車に搭載されるＣＡＮ基盤プラットフォームで外部攻撃者の侵入を効果的に探知できる方案が要求されている。
【先行技術文献】
【特許文献】
【0007】
【文献】特許第７３１６６０９号公報
【発明の概要】
【発明が解決しようとする課題】
【0008】
本開示は前述した従来技術の要求に呼応ために導き出されたもので、本開示の目的は、車両用コントローラ領域ネットワーク（ｃｏｎｔｒｏｌｌｅｒ ａｒｅａ ｎｅｔｗｏｒｋ、ＣＡＮ）基盤プラットフォームでＣＡＮを通じての攻撃者の侵入を探知する侵入探知システムおよびその作動方法を提供するところにある。
【課題を解決するための手段】
【0009】
前記技術的課題を解決するための本開示の一側面に係るコントローラ領域ネットワーク（ｃｏｎｔｒｏｌｌｅｒ ａｒｅａ ｎｅｔｗｏｒｋ、ＣＡＮ）侵入探知システム（ｉｎｔｒｕｓｉｏｎ ｄｅｔｅｃｔｉｏｎ ｓｙｓｔｅｍ、ＩＤＳ）の作動方法は、ハードウェア上に搭載されるＥＣＵ（ｅｌｅｃｔｒｏｎｉｃ ｃｏｎｔｒｏｌ ｕｎｉｔ）階層またはＡＵＴＯＳＡＲ階層；前記ＡＵＴＯＳＡＲ階層の構成要素とアプリケーション（ａｐｐｌｉｃａｔｉｏｎ、Ａｐｐ）を連結するＲＴＥ（ｒｅａｌ ｔｉｍｅ ｅｎｖｉｒｏｎｍｅｎｔ）またはインターフェース（ｉｎｔｅｒｆａｃｅ）；および前記アプリケーション上に搭載されるＩＤＳコア階層（ＩＤＳ ｃｏｒｅ ｌａｙｅｒ）とＩＤＳ探知階層（ＩＤＳ ｄｅｔｅｃｔ ｌａｙｅｒ）を含むＣＡＮ ＩＤＳの作動方法であって、前記ＡＵＴＯＳＡＲ階層のＣＡＮパケットミラーリングシステム（ＣＡＮ ｐａｃｋｅｔ ｍｉｒｒｏｒｉｎｇ ｓｙｓｔｅｍ）により、前記ＡＵＴＯＳＡＲ階層のＡＵＴＯＳＡＲ Ｐｄｕルータ（ＰｄｕＲ）領域に存在するＣＡＮドライバからＣＡＮメッセージを受信する段階；前記ＣＡＮパケットミラーリングシステムによって、受信したＣＡＮメッセージをメモリの複数の保存領域に保存する段階；前記ＩＤＳコア階層のＩＤＳコアによって、前記ＣＡＮパケットミラーリングシステムでコピーされたデータを読み込んで前記ＩＤＳコアの探知エンジンベースに伝達する段階；および前記ＩＤＳコア階層のＩＤＳコアによって、ＩＤＳの政策規則（ｐｏｌｉｃｙ ｒｕｌｅ）の政策バイナリファイル（ｐｏｌｉｃｙ ｂｉｎａｒｙ ｆｉｌｅ）を保存する第１メモリ領域と前記ＣＡＮメッセージをバッファリングし保存するためのバッファリングテーブル（ｂｕｆｆｅｒｉｎｇ ｔａｂｌｅ）を保存する第２メモリ領域を分けて管理する段階を含む。
【0010】
前記作動方法は、前記ＣＡＮパケットミラーリングシステムによって、前記メモリの第１共有型メモリ領域に保存されているＣＡＮ標準メッセージデータを第１エンジンメモリ領域にコピーして保存し、前記メモリの第２共有型メモリ領域に保存されているＣＡＮ ＦＤ（ｆｌｅｘｉｂｌｅ ｄａｔａ）メッセージデータを第２エンジンメモリ領域にコピーして保存する段階をさらに含むことができる。
【0011】
前記作動方法は、前記ＩＤＳコアによって、前記ＣＡＮデータが前記探知エンジンベースに伝達される前に共有型メモリからデータをエンジンメモリにコピーして持ってくる段階をさらに含むことができる。ここで、エンジンメモリに持ってきたＣＡＮメッセージはバッファリングテーブルに保存され得る。
【0012】
前記作動方法は、前記ＩＤＳコアによって、前記ＣＡＮメッセージをバッファリングテーブルに保存するために、先だって持ってきたＣＡＮメッセージのバス（ｂｕｓ）情報とＣＡＮ ＩＤ（ＩＤ：ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）を通じて政策バイナリファイル（ｐｏｌｉｃｙ ｂｉｎａｒｙ ｆｉｌｅ）のルックアップテーブル（ｌｏｏｋｕｐ ｔａｂｌｅ）を検索する段階をさらに含むことができる。
【0013】
前記作動方法は、前記ＩＤＳコアによって、先立って検索したＣＡＮメッセージのバッファリングテーブルタイプ（ｂｕｆｆｅｒｉｎｇ ｔａｂｌｅ ｔｙｐｅ）情報を通じて前記メモリの特定保存領域にＣＡＮメッセージを保存する段階をさらに含むことができる。ここで、前記バッファリングテーブルタイプ情報はバッファタイプ（ｂｕｆｆｅｒ ｔｙｐｅ）情報およびバッファインデックス（ｂｕｆｆｅｒ ｉｎｄｅｘ）情報を含むことができる。
【0014】
前記作動方法は、前記ＩＤＳコアによって、前記ルックアップテーブルを検索して一致する情報がない場合、前記ＣＡＮメッセージに対してバッファリングが必要でない場合、そして、バッファリングされた場合に対する処理をしなければならない場合から選択される少なくともいずれか一つで前記ＣＡＮメッセージを処理する段階をさらに含むことができる。
【0015】
前記作動方法は、前記ＩＤＳコアによって、エンジンメモリから持ってきたＣＡＮメッセージのバスとＣＡＮ ＩＤに基づいてバイナリ検索を通じてルックアップテーブル（ｌｏｏｋｕｐ ｔａｂｌｅ）で探知政策を検索する段階をさらに含むことができる。
【0016】
前記作動方法は、前記ＩＤＳコアによって、前記ルックアップテーブルで一致する政策がない時、アンノウンメッセージバッファリングテーブル情報を通じてメモリのバッファリングテーブルのアンノウンメッセージバッファに前記ＣＡＮメッセージを保存する段階；前記ＩＤＳコアによって、保存されたメッセージのヘッド（ｈｅａｄ）値を一つ増加させる段階；および前記ＩＤＳコアによって、現在コピーした項目のバッファリングテーブルのアドレス、探知政策ルールに対するアドレス、バッファタイプとバッファインデックスに対する情報をインターフェースを通じて前記探知エンジンベースに伝達する段階をさらに含むことができる。
【0017】
前記作動方法は、前記ＩＤＳコアによって、前記ルックアップテーブルで一致する探知政策が検索されると、該当ＣＡＮメッセージのバッファリングテーブルタイプ情報を通じてメモリのバッファリングテーブルに該当ＣＡＮメッセージを保存する段階；前記ＩＤＳコアによって、保存されたメッセージのヘッド（ｈｅａｄ）値を一つ増加させる段階；および前記ＩＤＳコアによって、現在コピーした項目のバッファリングテーブルのアドレス、探知政策ルールに対するアドレス、バッファタイプとバッファインデックスに対する情報をインターフェースを通じて前記探知エンジンベースに伝達する段階をさらに含むことができる。
【0018】
前記作動方法は、前記ＩＤＳコアによって、前記ルックアップテーブルでＣＡＮメッセージと一致する探知政策が検索される時、該当ＣＡＮメッセージのバッファリングテーブルタイプ情報を通じてメモリ領域のバッファリングテーブルに該当ＣＡＮメッセージを保存する段階；前記ＩＤＳコアによって、前記バッファリングテーブルタイプ情報のバッファインデックスが０、ヌル（ｎｕｌｌ）、非活性あるいは重要でない（ｍｉｎｏｒ）であるかを判断する段階；および前記ＩＤＳコアによって、該当ＣＡＮメッセージがバッファリングが必要でないメッセージであることを判断する段階をさらに含むことができる。
【0019】
前記作動方法は、前記ＩＤＳコアによって、該当ＣＡＮメッセージをバッファリングテーブルに保存せず、現在コピーした項目のメッセージアドレス、探知政策ルールに対するアドレス情報をインターフェースを通じて前記探知エンジンベースに伝達する段階を含むことができる。
【0020】
前記技術的課題を解決するための本開示の一側面に係るコントローラ領域ネットワーク（ｃｏｎｔｒｏｌｌｅｒ ａｒｅａ ｎｅｔｗｏｒｋ、ＣＡＮ）侵入探知システム（ｉｎｔｒｕｓｉｏｎ ｄｅｔｅｃｔｉｏｎ ｓｙｓｔｅｍ、ＩＤＳ）は、ハードウェア上に搭載されるＥＣＵ（ｅｌｅｃｔｒｏｎｉｃ ｃｏｎｔｒｏｌ ｕｎｉｔ）階層またはＡＵＴＯＳＡＲ階層；前記ＡＵＴＯＳＡＲ階層の構成要素とアプリケーション（ａｐｐｌｉｃａｔｉｏｎ、Ａｐｐ）を連結するＲＴＥ（ｒｅａｌ ｔｉｍｅ ｅｎｖｉｒｏｎｍｅｎｔ）またはインターフェース（ｉｎｔｅｒｆａｃｅ）；および前記アプリケーション上に搭載されるＩＤＳコア階層（ＩＤＳ ｃｏｒｅ ｌａｙｅｒ）とＩＤＳ探知階層（ＩＤＳ ｄｅｔｅｃｔ ｌａｙｅｒ）を含む。前記ＡＵＴＯＳＡＲ階層はＣＡＮパケットミラーリングシステム（ＣＡＮ ｐａｃｋｅｔ ｍｉｒｒｏｒｉｎｇ ｓｙｓｔｅｍ）を具備する。前記ＣＡＮパケットミラーリングシステムは前記ＡＵＴＯＳＡＲ階層のＡＵＴＯＳＡＲ Ｐｄｕルータ（ＰｄｕＲ）領域に存在するＣＡＮドライバからＣＡＮメッセージを受信し、受信したＣＡＮメッセージをメモリの複数の保存領域に保存し、前記複数の保存領域を共有型メモリ（ｓｈａｒｅｄ ｍｅｍｏｒｙ）として分離して管理する。ここで、前記ＩＤＳコア階層のＩＤＳコアは前記ＣＡＮパケットミラーリングシステムでコピーされたデータを読み込んで前記ＩＤＳコアの探知エンジンベースに伝達し、ＩＤＳの政策ルール（ｐｏｌｉｃｙ ｒｕｌｅ）の政策バイナリファイル（ｐｏｌｉｃｙ ｂｉｎａｒｙ ｆｉｌｅ）を保存する第１メモリ領域と前記ＣＡＮメッセージをバッファリングし保存するためのバッファリングテーブル（ｂｕｆｆｅｒｉｎｇ ｔａｂｌｅ）を保存する第２メモリ領域を分けて管理する。
【0021】
前記ＣＡＮパケットミラーリングシステムは、前記メモリの第１共有型メモリ領域に保存されているＣＡＮ標準メッセージデータを第１エンジンメモリ領域にコピーして保存し、前記メモリの第２共有型メモリ領域に保存されているＣＡＮ ＦＤ（ｆｌｅｘｉｂｌｅ ｄａｔａ）メッセージデータを第２エンジンメモリ領域にコピーして保存することができる。
【0022】
前記ＩＤＳコアは前記ＣＡＮデータが前記探知エンジンベースに伝達される前に共有型メモリからデータをエンジンメモリにコピーして持ってくることができる。ここで、エンジンメモリに持ってきたＣＡＮメッセージはバッファリングテーブルに保存され得る。
【0023】
前記ＩＤＳコアは、前記ＣＡＮメッセージをバッファリングテーブルに保存するために、持ってきたＣＡＮメッセージのバス（ｂｕｓ）情報とＣＡＮ ＩＤ（ＩＤ：ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）を通じて政策バイナリファイル（ｐｏｌｉｃｙ ｂｉｎａｒｙ ｆｉｌｅ）のルックアップテーブル（ｌｏｏｋｕｐ ｔａｂｌｅ）を検索することができる。
【0024】
前記ＩＤＳコアは、先立って検索したＣＡＮメッセージのバッファリングテーブルタイプ（ｂｕｆｆｅｒｉｎｇ ｔａｂｌｅ ｔｙｐｅ）情報を通じて前記メモリの特定保存領域にＣＡＮメッセージを保存することができる。ここで、前記バッファリングテーブルタイプ情報はバッファタイプ（ｂｕｆｆｅｒ ｔｙｐｅ）情報およびバッファインデックス（ｂｕｆｆｅｒ ｉｎｄｅｘ）情報を含むことができる。
【0025】
前記ＩＤＳコアは、前記ルックアップテーブルを検索して一致する情報がない場合、前記ＣＡＮメッセージに対してバッファリングが必要でない場合、そして、バッファリングされた場合に対する処理をしなければならない場合から選択される少なくともいずれか一つで前記ＣＡＮメッセージを処理することができる。
【0026】
前記ＩＤＳコアは、エンジンメモリから持ってきたＣＡＮメッセージのバスとＣＡＮ ＩＤに基づいてバイナリ検索を通じてルックアップテーブル（ｌｏｏｋｕｐ ｔａｂｌｅ）で探知政策を検索し；前記ルックアップテーブルで一致する政策がない時、アンノウンメッセージバッファリングテーブル情報を通じてメモリのバッファリングテーブルのアンノウンメッセージバッファに前記ＣＡＮメッセージを保存し；保存されたメッセージのヘッド（ｈｅａｄ）値を一つ増加させ；現在コピーした項目のバッファリングテーブルのアドレス、探知政策ルールに対するアドレス、バッファタイプとバッファインデックスに対する情報をインターフェースを通じて前記探知エンジンベースに伝達することができる。
【0027】
前記ＩＤＳコアは、エンジンメモリから持ってきたＣＡＮメッセージのバスとＣＡＮ ＩＤに基づいてバイナリ検索を通じてルックアップテーブル（ｌｏｏｋｕｐ ｔａｂｌｅ）で探知政策を検索し；前記ルックアップテーブルで一致する政策またはメッセージが検索されると、該当ＣＡＮメッセージのバッファリングテーブルタイプ情報を通じてメモリのバッファリングテーブルに該当ＣＡＮメッセージを保存し；保存されたメッセージのヘッド（ｈｅａｄ）値を一つ増加させ；現在コピーした項目のバッファリングテーブルのアドレス、探知政策ルールに対するアドレス、バッファタイプとバッファインデックスに対する情報をインターフェースを通じて前記探知エンジンベースに伝達することができる。
【0028】
前記ＩＤＳコアはエンジンメモリから持ってきたＣＡＮメッセージのバスとＣＡＮ ＩＤに基づいてルックアップテーブル（ｌｏｏｋｕｐ ｔａｂｌｅ）で２進検索を通じて探知政策を検索し；前記ルックアップテーブルでＣＡＮメッセージと一致する探知政策が検索されると、該当ＣＡＮメッセージのバッファリングテーブルタイプ情報を通じてメモリ領域のバッファリングテーブルに該当ＣＡＮメッセージを保存し；前記バッファリングテーブルタイプ情報のバッファインデックスが０、ヌル（ｎｕｌｌ）、非活性あるいは重要でない（ｍｉｎｏｒ）である場合、該当ＣＡＮメッセージがバッファリングが必要でないメッセージであることを判断し；該当ＣＡＮメッセージをバッファリングテーブルに保存せず、現在コピーした項目のメッセージアドレス、探知政策ルールに対するアドレス情報をインターフェースを通じて前記探知エンジンベースに伝達することができる。
【発明の効果】
【0029】
本開示によると、車両用コントローラ領域ネットワーク（ｃｏｎｔｒｏｌｌｅｒ ａｒｅａ ｎｅｔｗｏｒｋ、ＣＡＮ）基盤プラットフォームでＣＡＮを通じての攻撃者の侵入を効果的に探知することができる。
【図面の簡単な説明】
【0030】
【図1】本開示の侵入探知システム（ｉｎｔｒｕｓｉｏｎ ｄｅｔｅｃｔｉｏｎ ｓｙｓｔｅｍ、ＩＤＳ）を適用できるコントローラ領域ネットワーク（ｃｏｎｔｒｏｌｌｅｒ ａｒｅａ ｎｅｔｗｏｒｋ、ＣＡＮ）の一形態を説明するための例示図である。
【図2】比較例に係るＣＡＮ ＩＤＳに対する構成図である。
【図3】本開示の一実施例に係るＣＡＮ ＩＤＳに対する構成図である。
【図20】本開示の他の実施例に係るＣＡＮ ＩＤＳに対する概略的な構成図である。
【発明を実施するための形態】
【0031】
本発明は多様な変更を加えることができ、多様な実施例を有することができるところ、特定実施例を図面に例示して詳細に説明しようとする。しかし、これは本発明を特定の実施形態に対して限定しようとするものではなく、本発明の思想および技術範囲に含まれるすべての変更、均等物乃至代替物を含むものと理解されるべきである。
【0032】
第１、第２等の用語は多様な構成要素の説明に使われ得るが、前記構成要素は前記用語によって限定されてはならない。前記用語は一つの構成要素を他の構成要素から区別する目的でのみ使われる。例えば、本発明の権利範囲を逸脱することなく第１構成要素は第２構成要素と命名され得、同様に第２構成要素も第１構成要素と命名され得る。および／またはという用語は複数の関連した記載された項目の組み合わせまたは複数の関連した記載された項目のいずれかの項目を含む。
【0033】
本出願の実施例で、「ＡおよびＢのうち少なくとも一つ」は「ＡまたはＢのうち少なくとも一つ」または「ＡおよびＢのうち一つ以上の組み合わせのうち少なくとも一つ」を意味し得る。また、本出願の実施例で、「ＡおよびＢのうち一つ以上」は「ＡまたはＢのうち一つ以上」または「ＡおよびＢのうち一つ以上の組み合わせのうち一つ以上」を意味し得る。
【0034】
或る構成要素が他の構成要素に「連結されて」いるとか「接続されて」いると言及された時には、その他の構成要素に直接的に連結されていたりまたは接続されていてもよいが、中間に他の構成要素が存在してもよいと理解されるべきである。反面、或る構成要素が他の構成要素に「直接連結されて」いるとか「直接接続されて」いると言及された時には、中間に他の構成要素が存在しないものと理解されるべきである。
【0035】
本出願で使った用語は単に特定の実施例を説明するために使われたもので、本発明を限定しようとする意図ではない。単数の表現は文脈上明白に異なって意味しない限り、複数の表現を含む。本出願で、「含む」または「有する」等の用語は、明細書上に記載された特徴、数字、段階、動作、構成要素、部品またはこれらを組み合わせたものが存在することを指定しようとするものであって、一つまたはそれ以上の他の特徴や数字、段階、動作、構成要素、部品またはこれらを組み合わせたものなどの存在または付加の可能性を予め排除しないものと理解されるべきである。
【0036】
別途に定義されない限り、技術的または科学的な用語を含んでここで使われるすべての用語は本発明が属する技術分野で通常の知識を有する者によって一般的に理解されるものと同じ意味を有している。一般的に使われる辞書に定義されているような用語は関連技術の文脈上有する意味と一致する意味を有すると解釈されるべきであり、本出願で明白に定義しない限り、理想的または過度に形式的な意味で解釈されない。
【0037】
以下、添付した図面を参照して、本発明の好ましい実施例をより詳細に説明しようとする。本発明を説明するにおいて、全体的な理解を容易にするために図面上の同じ構成要素に対しては同じ参照符号を使用し、同じ構成要素に対して重複した説明は省略する。
【0038】
図１は、本開示の侵入探知システム（ｉｎｔｒｕｓｉｏｎ ｄｅｔｅｃｔｉｏｎ ｓｙｓｔｅｍ、ＩＤＳ）を適用できるコントローラ領域ネットワーク（ｃｏｎｔｒｏｌｌｅｒ ａｒｅａ ｎｅｔｗｏｒｋ、ＣＡＮ）の一形態を説明するための例示図である。
【0039】
図１を参照すると、ＣＡＮは電気的ノイズ発生が多い車両環境で信頼性を確保するために開発された通信方式である。ＣＡＮは多数の制御器を並列に連結してデータをやりとりする構造を有する。通信ラインを共有するすべての制御器がマスターの役割をするので、いつでも互いに通信が可能である。すなわち、通信ライン上にデータを置いておけば、いずれの制御器であれ、必要な時ごとにデータを持ち込んで使う方式である。制御器内のＣＡＮ通信モジュールはマイクロコントローラ（ｍｉｃｒｏｃｏｎｔｒｏｌｌｅｒ、ＭＣＵ）とＣＡＮトランシーバ（ＣＡＮ ｔｒａｎｓｃｅｉｖｅｒ）で構成され、外部のＣＡＮバス（ｂｕｓ）を通じてＣＡＮハイ（ｈｉｇｈ）とＣＡＮロー（ｌｏｗ）信号をやりとりする。
【0040】
制御器はゲートウェイ（ｇａｔｅｗａｙ、１９０）およびスイッチ１９１、１９１ａ、１９１ｂ、１９２、１９３のうち少なくとも一つ以上を通じて連結される。各制御器はエンドノード３０１、３０２、３０３、３１１、３１２、３１３、３２１、３２２、３２３のうちいずれか一つに対応する。ゲートウェイ１９０や各スイッチはエンドノードに対応し得る。各スイッチはブリッジ（ｂｒｉｄｇｅ）と指称され得る。
【0041】
車両ネットワークを構成するゲートウェイ１９０は少なくとも一つのスイッチ１９１、１９１ａ、１９１ｂ、１９２、１９３と連結され得、互いに異なるネットワークを連結することができる。例えば、ゲートウェイ１９０はＣＡＮ（ｃｏｎｔｒｏｌｌｅｒ ａｒｅａ ｎｅｔｗｏｒｋ）、フレックスレイ（ＦｌｅｘＲａｙ）、ＭＯＳＴ（ｍｅｄｉａ ｏｒｉｅｎｔｅｄ ｓｙｓｔｅｍ ｔｒａｎｓｐｏｒｔ）、ＬＩＮ（ｌｏｃａｌ ｉｎｔｅｒｃｏｎｎｅｃｔ ｎｅｔｗｏｒｋ）等の通信プロトコルを支援するエンドノードとイーサネット（Ｅｔｈｅｒｎｅｔ）プロトコルを支援するスイッチ間を連結することができる。
【0042】
スイッチ１９１、１９１ａ、１９１ｂ、１９２、１９３それぞれは少なくとも一つのエンドノード３０１、３０２、３０３、３１１、３１２、３１３、３２１、３２２、３２３と連結され得る。スイッチそれぞれはエンドノードを相互に連結でき、自身と連結されたエンドノードを制御することができる。
【0043】
エンドノード３０１、３０２、３０３、３１１、３１２、３１３、３２１、３２２、３２３それぞれは車両に含まれた各種装置を制御するＥＣＵ（ｅｌｅｃｔｒｏｎｉｃ ｃｏｎｔｒｏｌ ｕｎｉｔ）を意味し得る。例えば、エンドノード３０１、３０２、３０３、３１１、３１２、３１３、３２１、３２２、３２３は車両のインフォテインメント（ｉｎｆｏｒｔａｉｎｍｅｎｔ）装置に含まれるディスプレイ（ｄｉｓｐｌａｙ）装置、ナビゲーション（ｎａｖｉｇａｔｉｏｎ）装置、アラウンドビューモニタリング（ａｒｏｕｎｄ ｖｉｅｗ ｍｏｎｉｔｏｒｉｎｇ）装置などの個別ＥＣＵを指称し得る。
【0044】
一方、車両ネットワークを構成するエンドノード、すなわち、ゲートウェイ１９０、各スイッチ、エンドノードなどはスター（ｓｔａｒ）トポロジー、バス（ｂｕｓ）トポロジー、リング（ｒｉｎｇ）トポロジー、ツリー（ｔｒｅｅ）トポロジー（図１参照）、メッシュ（ｍｅｓｈ）トポロジーなどに連結され得る。
【0045】
以下の本開示の実施例に係る装置や方法は前述されたネットワークトポロジーに適用され得るが、これに限定されず、既に広く知られている多様なネットワークトポロジーの中から選択される少なくとも一つに適用されるように構成され得る。
【0046】
図２は、比較例に係るＣＡＮ ＩＤＳに対する構成図である。
【0047】
図２を参照すると、比較例のＣＡＮ ＩＤＳ１００はＡＵＴＯＳＡＲ（ＡＵＴｏｍｏｔｉｖｅ Ｏｐｅｎ Ｓｙｓｔｅｍ ＡＲｃｈｉｔｅｃｔｕｒｅ）およびＥＣＵ（ｅｌｅｃｔｒｏｎｉｃ ｃｏｎｔｒｏｌ ｕｎｉｔ）階層１１０ａ、ＩＤＳコア階層（ＩＤＳ ｃｏｒｅ ｌａｙｅｒ、１３０ａ）、およびＩＤＳ探知階層（ＩＤＳ ｄｅｔｅｃｔ ｌａｙｅｒ、１５０ａ）を具備する。
【0048】
ここで、ＡＵＴＯＳＡＲおよびＥＣＵ階層１１０ａはＣＡＮドライバ（ＣＡＮ ｄｒｉｖｅｒ）とＣＡＮパケットミラーリングシステム（ＣＡＮ ｐａｃｋｅｔ ｍｉｒｒｏｒｉｎｇ ｓｙｓｔｅｍ）を具備する。ＩＤＳコア階層１３０はＩＤＳコア（ＩＤＳ－ｃｏｒｅ）を具備する。そして、ＩＤＳ探知階層（１５０ａ）は探知エンジンベース（ｄｅｔｅｃｔｉｏｎ ｅｎｇｉｎｅ ｂａｓｅ）、複数の政策規則（ｐｏｌｉｃｙ ｒｕｌｅｓ）およびロギングシステム（ｌｏｇｇｉｎｇ ｓｙｓｔｅｍ）を具備する。
【0049】
比較例のＣＡＮ ＩＤＳ１００は一般的なＥＣＵシステムに適用される。比較例のＣＡＮ ＩＤＳ１００は既存のＡＵＴＯＳＡＲを基盤とするシステム構成を有する。ここで、ＣＡＮパケットミラーリングシステムは基本ソフトウェア（ｂａｓｉｃ ｓｏｆｔｗａｒｅ、ＢＳＷ）の通信サービス階層のＰｄｕルータ（Ｐｄｕ ｒｏｕｔｅｒ、ＰｄｕＲ）に含まれたり、複合ドライバ（ｃｏｍｐｌｅｘ ｄｒｉｖｅｒｓ）に含まれる。
【0050】
図３は、本開示の一実施例に係るＣＡＮ ＩＤＳに対する構成図である。
【0051】
図３を参照すると、ＣＡＮ ＩＤＳは、ハードウェア（ｈａｒｄｗａｒｅ、１０２）上に搭載されるＥＣＵ（ｅｌｅｃｔｒｏｎｉｃ ｃｏｎｔｒｏｌ ｕｎｉｔ）階層またはＡＵＴＯＳＡＲ階層１１０；ＡＵＴＯＳＡＲ階層１１０の構成要素とアプリケーション（ａｐｐｌｉｃａｔｉｏｎ、Ａｐｐ、１６０）を仮想機能バス（ｖｉｒｔｕａｌ ｆｕｒｎｃｔｉｏｎａｌ ｂｕｓ）等を利用して連結するＲＴＥ（ｒｅａｌ ｔｉｍｅ ｅｎｖｉｒｏｎｍｅｎｔ）またはインターフェース（ｉｎｔｅｒｆａｃｅ、１２０）；およびアプリケーション１６０上に搭載されるＩＤＳコア階層（ＩＤＳ ｃｏｒｅ ｌａｙｅｒ、１３０）とＩＤＳ探知階層（ＩＤＳ ｄｅｔｅｃｔ ｌａｙｅｒ、１５０）を含むことができる。アプリケーション１６０はトランスコンパイラ（ｔｒａｎｓｐｉｌｅｒ）またはＳＷＣ（ｓｐｅｅｄｙ ｗｅｂ ｃｏｍｐｉｌｅｒ）等のコンパイラ（ｃｏｍｐｉｌｅｒ、１７０）上に搭載され得る。
【0052】
ここで、ハードウェア（ｈａｒｄｗａｒｅ、１０２）はマイクロコントローラ（ｍｉｃｒｏｃｏｎｔｒｏｌｌｅｒ、１０４）を含むことができる。そして、ＡＵＴＯＳＡＲ階層１１０はＭＣＡＬ（ｍｉｃｒｏｃｏｎｔｒｏｌｌｅｒ ａｂｓｔｒａｃｔｉｏｎ ｌａｙｅｒ）等のデバイスドライバのためのドライバ階層（ｄｒｉｖｅｒ ｌａｙｅｒ、１１１）、ＥＣＵなどのための抽象化階層（ａｂｓｔｒａｃｔｉｏｎ ｌａｙｅｒ、１１２）、サービス階層（ｓｅｒｖｉｃｅｓ ｌａｙｅｒ、１１３）、複合ドライバ（ｃｏｍｐｌｅｘ ｄｒｉｖｅｒｓ、１１６）およびＣＡＮパケットミラーリングシステム（ＣＡＮ ｐａｃｋｅｔ ｍｉｒｒｏｒｉｎｇ ｓｙｓｔｅｍ、１１７）を具備することができる。そして、サービス階層１１３は通信サービス階層（ｃｏｍｍｕｎｉｃａｔｉｏｎ ｓｅｒｖｉｃｅ ｌａｙｅｒ、１１４）とＰｄｕルータ（Ｐｄｕ ｒｏｕｔｅｒ、ＰｄｕＲ、１１５）を具備することができる。
【0053】
また、ＩＤＳコア階層１３０はＩＤＳコア（ＩＤＳ－Ｃｏｒｅ、１４０）を含むことができる。本実施例でＩＤＳコア１４０は微視的側面で探知エンジンと指称され得る。そして、ＩＤＳ探知階層１５０は探知エンジンベース（ｄｅｔｅｃｔｉｏｎ ｅｎｇｉｎｅ ｂａｓｅ、１５２）、政策規則（ｐｏｌｉｃｙ ｒｕｌｅ、１５４）およびロギングシステム（ｌｏｇｇｉｎｇ ｓｙｓｔｅｍ、１５６）を含むことができる。
【0054】
本実施例のＣＡＮ ＩＤＳは比較例と他の構造と機能を有したＩＤＳコア階層１３０とＩＤＳ探知階層１５０を具備する。ＩＤＳコア階層１３０とＩＤＳ探知階層１５０は新しい探知ルールによりＣＡＮメッセージを探知して処理するように構成される。
【0055】
ＣＡＮ ＩＤＳに備えられるＣＡＮドライバは物理的なＣＡＮ装置からメッセージを受信する。ＣＡＮドライバはＣＡＮ装置を初期化し、ＣＡＮバスからデータを受信する。ＣＡＮドライバはＡＵＴＯＳＡＲ階層１１０のサービス階層１１３の通信サービス階層１１４のＰｄｕＲ１１５領域と複合ドライバ１１６領域にかけて存在することができる。このようなＣＡＮドライバはＡＵＴＯＳＡＲ ＰｄｕＲ領域に存在するものと指称され得る。
【0056】
また、ＣＡＮ ＩＤＳに備えられるＣＡＮパケットミラーリングシステム１１７はＣＡＮドライバで受信したメッセージをメモリ領域にコピーし、該当メッセージが損失（ｌｏｓｓ）されないようにバッファリング管理を遂行する。ＣＡＮパケットミラーリングシステム１１７はＣＡＮメッセージと追加メタデータを生成して管理する機能を遂行することができる。そして、ＣＡＮパケットミラーリングシステム１１７は典型的な（ｃｌａｓｓｉｃ）ＡＵＴＯＳＡＲ階層がないシステムではＥＣＵ応用プログラムで動作するが、典型的なＡＵＴＯＳＡＲプラットフォーム基盤のシステムでは基本ソフトウェア（ｂａｓｉｃ ｓｏｆｔｗａｒｅ、ＢＳＷ）領域に存在することができる。
【0057】
【0058】
図４を参照すると、ＣＡＮパケットミラーリングシステム１１７はＡＵＴＯＳＡＲ ＰｄｕＲ領域に存在するＣＡＮドライバ１１５ａからＣＡＮメッセージを受信し（Ｓ４１）、受信したＣＡＮメッセージをメモリ（ｍｅｍｏｒｙ、１０６）のＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｏｍｏｒｙ）領域にコピーして保存することができる（Ｓ４３）。この時、ＣＡＮパケットミラーリングシステム１１７は共有型メモリ（ｓｈａｒｅｄ ｍｅｍｏｒｙ）という名前を有して互いに分離されて管理される複数の保存領域にメッセージデータを保存することができる。
【0059】
ＣＡＮ標準（ｓｔａｎｄａｒｄ）メッセージデータ（以下「第１メッセージデータ」ともいう）は第１保存領域１０４ａに保存されて管理され、ＣＡＮフレキシブルデータ（ｆｌｅｘｉｂｌｅ ｄａｔａ、ＦＤ）メッセージデータ（以下「第２メッセージデータ」ともいう）は第２保存領域１０４ｂに保存されて管理され得る。第１保存領域１０４ａおよび第２保存領域１０４ｂは第１共有型メモリ領域および第２共有型メモリ領域とそれぞれ指称され得る。
【0060】
メモリ１０６の空間すなわち、保存領域は円形キュー（ｃｉｒｃｕｌａｒ ｑｕｅｕｅ）構造で構成され得、各保存領域のバッファの大きさは柔軟にシステムごとに異なって設定され得る。例えば、メモリ１０６の保存領域を形成する共有型メモリバッファ構造（ｓｈａｒｅｄ ｍｏｍｏｒｙ ｂｕｆｆｅｒ ｓｔｒｕｃｔｕｒｅ）は第１バッファ（ｂｕｆｆｅｒ［０］）、第２バッファ（ｂｕｆｆｅｒ［１］）、第３バッファ（ｂｕｆｆｅｒ［２］）等を含み、それぞれＣＡＮデータを保存することができる。
【0061】
ＣＡＮデータの構造は［表１］の第１フォーマットによりバッファに保存されるか、［表２］の第２フォーマットによりバッファに保存され得る。第１フォーマットと第２フォーマットの差は受信されたメッセージのメッセージフィールド（ｍｅｓｓａｇｅ ｆｉｅｌｄ）のサイズ（ｓｉｚｅ）で異なり得る。例えば、ＣＡＮ標準にしたがう受信されたＣＡＮメッセージデータのためのメッセージフィールドのサイズは８バイト（ｂｙｔｅ）であり、受信されたＣＡＮ ＦＤメッセージデータのためのメッセージフィールドのサイズは６４バイトであり得る。
【0062】
【表1】
【0063】
【表2】
【0064】
再び図１を参照すると、ＩＤＳコア階層１３０のＩＤＳコア１４０はＣＡＮパケットミラーリングシステム１１７でコピーされたデータを読み込んで探知エンジンベース１５２に伝達する機能を遂行することができる。この時、ＩＤＳコア１４０はＩＤＳの政策ルール（ｐｏｌｉｃｙ ｒｕｌｅ、１５４）の政策バイナリファイル（ｐｏｌｉｃｙ ｂｉｎａｒｙ ｆｉｌｅ）を保存する第１メモリ領域とＣＡＮメッセージをバッファリングし保存するためのバッファリングテーブル（ｂｕｆｆｅｒｉｎｇ ｔａｂｌｅ）を保存する第２メモリ領域を分けて管理することができる。
【0065】
また、ＩＤＳコア１４０はＣＡＮパケットミラーリングシステム１１７によりメモリ１０６に保存されたＣＡＮデータを持ってくるための他のバッファを具備することができる。このようなバッファはエンジンメモリ（ｅｎｇｉｎｅ ｍｅｍｏｒｙ）と指称され得る。
【0066】
【0067】
図５を参照すると、ＣＡＮパケットミラーリングシステムは共有型メモリ（ｓｈａｒｅｄ ｍｅｍｏｒｙ）と呼ばれ、互いに分離されて管理される第１保存領域１０４ａおよび第２保存領域１０４ｂに保存されているメッセージデータをそれぞれコピーしてエンジンメモリと呼ばれる第３保存領域１０４ｃおよび第４保存領域１０４ｄにコピーして保存することができる。第３保存領域１０４ｃおよび第４保存領域１０４ｄは第１エンジンメモリ領域および第２エンジンメモリ領域とそれぞれ指称され得る。
【0068】
すなわち、ＣＡＮパケットミラーリングシステムは、第１共有型メモリ領域１０４ａに保存されているＣＡＮ標準メッセージデータを第１エンジンメモリ領域１０４ｃにコピーして保存し、第２共有型メモリ領域１０４ｂに保存されているＣＡＮ ＦＤメッセージデータを第２エンジンメモリ領域１０４ｄにコピーして保存することができる。
【0069】
各エンジンメモリは共有型メモリと同様に円形キュー（ｃｉｒｃｕｌａｒ ｑｕｅｕｅ）構造を具備することができ、共有型メモリと類似するか同じ構造でＣＡＮデータを保存することができる。
【0070】
ＩＤＳコア（図３の１４０参照）はＣＡＮデータが探知エンジンベースに伝達される前に共有型メモリからデータをエンジンメモリにコピーして持ってくることができる。エンジンメモリに持ってきたＣＡＮメッセージはバッファリングテーブルに保存され得る。この時、ＣＡＮメッセージをバッファリングテーブルに保存するために、ＩＤＳコアは持ってきたＣＡＮメッセージのバス（ｂｕｓ）情報とＣＡＮ ＩＤ（ＩＤ：ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）を通じて政策バイナリファイル（ｐｏｌｉｃｙ ｂｉｎａｒｙ ｆｉｌｅ）のルックアップテーブル（ｌｏｏｋｕｐ ｔａｂｌｅ）を検索することができる。ＣＡＮ ＩＤはルックアップキー（ｌｏｏｋｕｐ ｋｅｙ）を含むかルックアップキーに対応することができる。
【0071】
ＩＤＳコアは、先立って検索したＣＡＮメッセージのバッファリングテーブルタイプ（ｂｕｆｆｅｒｉｎｇ ｔａｂｌｅ ｔｙｐｅ）情報を通じてＲＡＭ１０６の特定保存領域にＣＡＮメッセージを保存することができる。バッファリングテーブルタイプ情報はバッファタイプ（ｂｕｆｆｅｒ ｔｙｐｅ）情報、バッファインデックス（ｂｕｆｆｅｒ ｉｎｄｅｘ）情報などを含むことができる。
【0072】
前述したＣＡＮメッセージのバッファリング（ｂｕｆｆｅｒｉｎｇ）は、ルックアップテーブルを検索して一致する情報がない場合、バッファリングが必要でない場合、そして、バッファリングされた場合に対する処理をしなければならない場合に対する三つの方法から選択される少なくともいずれか一つの方法で処理され得る。
【0073】
【0074】
図６を参照すると、ＣＡＮメッセージの三つのバッファリング過程のうち政策バイナリのルックアップテーブルのＣＡＮメッセージが一致しない場合が例示される。
【0075】
まず、ＩＤＳコアはエンジンメモリから持ってきたＣＡＮメッセージのバスとＣＡＮ ＩＤに基づいてバイナリ検索を通じてルックアップテーブル（ｌｏｏｋｕｐ ｔａｂｌｅ １８０）で探知政策を検索することができる（Ｓ６１）。ＣＡＮメッセージのバスは例えばＢＵＳ（０ｘＦＦ）で表示され、ＣＡＮ ＩＤはＣＡＮ ＩＤ（０ｘＦＦ）で表示され得る。
【0076】
ルックアップテーブル１８０は複数のルックアップキー（ｌｏｏｋｕｐ ｋｅｙｓ）、複数の政策ボディタイプ（ｐｏｌｉｃｙ ｂｏｄｙ ｔｙｐｅｓ）および複数のバッファリングテーブルタイプ（ｂｕｆｆｅｒｉｎｇ ｔａｂｌｅ ｔｙｐｅｓ）に対する情報を保存することができる。各ルックアップキーはバス（ｂｕｓ）に対する情報を保存するフィールドと調整（ａｒｂｉｔｒａｔｉｏｎ）ＩＤに対する情報を保存するフィールドを具備することができる。各政策ボディタイプは政策インデックス（ｐｏｌｉｃｙ ｉｎｃｅｘ）に対する情報を保存するフィールドを具備することができる。そして、各バッファリングテーブルタイプはバッファインデックス（ｂｕｆｆｅｒ ｉｎｄｅｘ）に対する情報を保存するフィールドと選択的にバッファタイプ（ｂｕｆｆｅｒ ｔｙｐｅ）を保存するフィールドを具備することができる。
【0077】
ルックアップテーブル１８０で検索されなかったメッセージは、ルックアップテーブル１８０の一番最初に保存されたアンノウンメッセージバッファリングテーブル（ｕｎｋｎｏｗｎ ｍｅｓｓａｇｅ ｂｕｆｆｅｒｉｎｇ ｔａｂｌｅ）情報を通じてＲＡＭ領域のバッファリングテーブル（ｂｕｆｆｅｒｉｎｇ ｔａｂｌｅ、１８２）に保存され得る（Ｓ６３、Ｓ６５）。すなわち、ルックアップテーブル１８０で一致する政策がない時、ＩＤＳコアはアンノウンメッセージバッファリングテーブル情報を通じてＲＡＭ領域のバッファリングテーブル１８２のアンノウンメッセージバッファ（ｕｎｋｎｏｗｎ ｍｅｓｓａｇｅ ｂｕｆｆｅｒ）にＣＡＮメッセージを保存することができる（Ｓ６３、Ｓ６５）。アンノウンメッセージバッファはヘッド（ｈｅａｄ）、テール（ｔａｉｌ）、および複数の保存領域（０～４参照）を具備することができる。
【0078】
メッセージが保存されると、ＩＤＳコアは保存されたメッセージのヘッド（ｈｅａｄ）値を一つ増加させることができる。そして、現在コピーした項目のバッファリングテーブル１８２のアドレス、探知政策ルールに対するアドレス、バッファタイプとバッファインデックス情報をＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ）等のインターフェース１０８を通じて探知エンジン１６０ａの探知エンジンベースに伝達することができる（Ｓ６７、Ｓ６９）。探知政策ルールに対するアドレスは簡略に探知政策アドレスと指称され得、バッファインデックス情報はバッファリングテーブル１８２のインデックス情報を含むことができる。このようにＩＤＳコアはバッファリングテーブル１８２に保存された情報を探知エンジン１６０ａに伝達することができる。探知エンジン１６０ａはアプリケーション（図３の１６０参照）の一種であり得る。
【0079】
【0080】
図７を参照すると、ＣＡＮメッセージの三つのバッファリング過程のうち政策バイナリのルックアップテーブルでＣＡＮメッセージが一致する場合が例示される。
【0081】
まず、ＩＤＳコアはエンジンメモリから持ってきたＣＡＮメッセージのバスとＣＡＮ ＩＤに基づいてバイナリ検索を通じてルックアップテーブル（ｌｏｏｋｕｐ ｔａｂｌｅ １８０）で探知政策を検索することができる（Ｓ７１）。例えばＣＡＮメッセージのバスはＢＵＳ（０ｘＦＦ）であり、ＣＡＮ ＩＤはＣＡＮ ＩＤ（０ｘ３ＦＤ）であり得る。
【0082】
ＣＡＮメッセージがルックアップテーブル１８０で検索されたメッセージである場合、ＩＤＳコアは該当メッセージのバッファリングテーブルタイプ情報を通じてＲＡＭ領域のバッファリングテーブル（ｂｕｆｆｅｒｉｎｇ ｔａｂｌｅ、１８２）に該当ＣＡＮメッセージを保存することができる（Ｓ７３、Ｓ７５）。バッファリングテーブル１８２は複数のアンノウンメッセージバッファ（ｕｎｋｎｏｗｎ ｍｅｓｓａｇｅ ｂｕｆｆｅｒｓ、ＵＭＢ）を含むことができる。例えば、９８番目のＵＭＢのアドレスはＯｘ２Ｃ１に、９９番目のＵＭＢのアドレスは０ｘ２ＤＣに、そして、１００番目のＵＭＢのアドレスは０ｘ３ＦＤにそれぞれ設定され得る。それぞれのアンノウンメッセージバッファはヘッド（ｈｅａｄ）、テール（ｔａｉｌ）、および複数の保存領域（０～４参照）を具備することができる。
【0083】
メッセージが保存されると、ＩＤＳコアは保存されたメッセージのヘッド（ｈｅａｄ）値を一つ増加させることができる。そして、現在コピーした項目のバッファリングテーブル１８２のアドレス、探知政策ルールに対するアドレス、バッファタイプとバッファインデックスに対する情報をＡＰＩなどのインターフェース１０８を通じて探知エンジン１６０ａの探知エンジンベースに伝達することができる（Ｓ７７、Ｓ７９）。このようにＩＤＳコアはバッファリングテーブル１８２に保存した情報を探知エンジン１６０ａに伝達することができる。
【0084】
【0085】
図８を参照すると、ＣＡＮメッセージの三つのバッファリング過程のうち政策バイナリのルックアップテーブルのＣＡＮメッセージと一致するがバッファリングが必要でない場合が例示される。
【0086】
まず、ＩＤＳコアはエンジンメモリから持ってきたＣＡＮメッセージのバスとＣＡＮ ＩＤまたはルックアップキー（ｌｏｏｋｕｐ ｋｅｙ）を通じてルックアップテーブル（ｌｏｏｋｕｐ ｔａｂｌｅ １８０）を検索することができる（Ｓ８１）。検索は２進検索を通じて探知政策を検索することを含むことができる。そして、ＣＡＮメッセージは例えばバスに対する情報としてＢＵＳ（０ｘ２）とＣＡＮ ＩＤに対する情報としてＣＡＮ ＩＤ（０ｘ１１０）を含むことができる。
【0087】
ＣＡＮメッセージがルックアップテーブル１８０で検索される場合、ＩＤＳコアは該当メッセージのバッファリングテーブルタイプ（ｂｕｆｆｅｒｉｎｇ ｔａｂｌｅ ｔｙｐｅ）情報を通じてＲＡＭ領域のバッファリングテーブル（ｂｕｆｆｅｒｉｎｇ ｔａｂｌｅ）に該当ＣＡＮメッセージを保存することができる（Ｓ８３）。
【0088】
この時、バッファリングテーブルタイプ情報のバッファインデックス（ｂｕｆｆｅｒ ｉｎｄｅｘ）情報が０である場合、ＩＤＳコアは該当ＣＡＮメッセージがバッファリングが必要でないメッセージであると判断または決定することができる。バッファリングが必要でないメッセージはバッファリングテーブルに保存せず、現在コピーした項目のメッセージアドレス、探知政策ルールに対するアドレス情報を含んだコピーしたメッセージをＡＰＩなどのインターフェース１０８を通じて探知エンジン１６０ａに伝達することができる（Ｓ８５）。
【0089】
探知エンジンベース（図３の１５２参照）はＩＤＳコアから伝達された情報を通じてバッファリングされたメッセージを探知したり削除することができる。探知エンジンベースを含む探知エンジンは伝達された情報を通じてルックアップテーブルを検索してメッセージを探知でき、また、削除することができる。
【0090】
【0091】
図９を参照すると、探知エンジン１６０ａは政策バイナリ（ｐｏｌｉｃｙ ｂｉｎａｒｙ）のルックアップテーブルのＣＡＮメッセージを探知することができる。
【0092】
具体的には、探知エンジン１６０ａはＩＤＳコアから伝達されたＣＡＮメッセージのバッファリングテーブル（ｂｕｆｆｅｒｉｎｇ ｔａｂｌｅ、１８２）の情報を通じてＣＡＮメッセージを探知することができる。バッファリングテーブル１８２は、バッファインデックス（ｂｕｆｆｅｒ ｉｎｄｅｘ）とバッファタイプ（ｂｕｆｆｅｒ ｔｙｐｅ）情報がＡＰＩを含んだインターフェース１０８に伝達されると、バッファリングテーブルのヘッド（ｈｅａｄ）、テール（ｔａｉｌ）情報に基づいて最新メッセージから一つずつ照会ことができる。
【0093】
例えば、バッファリングテーブル１８２は特定識別子（例えば、ｂｕｆ－５－ｒｅｃ－ｎｕｍ）を具備し、探知エンジン１６０ａからインターフェース１０８にバッファリングテーブルの情報例えば、バッファタイプ（例えば、００）とバッファインデックス（例えば、１００）が伝達されると（Ｓ９２）、バッファリングテーブル１８２のヘッドとテール情報を通じてバッファリングテーブル１８２の最新ＣＡＮメッセージが保存されたアドレスに移動することができる。
【0094】
ここで、最新ＣＡＮメッセージはアドレス０ｘ３ＦＤのバッファインデックス１００の保存領域アドレス（０、１、２）に順次保存されたＣＡＮメッセージであり得、その中で最も最新ＣＡＮメッセージは０ｘ３ＦＤ列のバッファインデックス１００のバッファアドレス（２）に保存されたＣＡＮメッセージであり得る。
【0095】
【0096】
図１０を参照すると、探知エンジン１６０ａは政策バイナリ（ｐｏｌｉｃｙ ｂｉｎａｒｙ）のルックアップテーブルのＣＡＮメッセージを削除することができる。
【0097】
具体的には、探知エンジン１６０ａはＩＤＳコアから伝達されたＣＡＮメッセージのバッファリングテーブル（ｂｕｆｆｅｒｉｎｇ ｔａｂｌｅ、１８２）の情報を通じてＣＡＮメッセージを削除することができる。探知エンジン１６０ａからＡＰＩを含んだインターフェース１０８を通じてバッファインデックス（ｂｕｆｆｅｒ ｉｎｄｅｘ）とバッファタイプ（ｂｕｆｆｅｒ ｔｙｐｅ）情報が伝達されると、バッファリングテーブル１８２はそのヘッド（ｈｅａｄ）情報とテール（ｔａｉｌ）情報に基づいてバッファリングテーブルの古くなったメッセージに移動して古くなったメッセージから一つずつ削除することができる。
【0098】
例えば、バッファリングテーブル１８２は、特定識別子（例えば、ｂｕｆ－５－ｒｅｃ－ｎｕｍ）を具備し、探知エンジン１６０ａでインターフェース１０８を通じてバッファリングテーブルの情報と削除する個数が伝達されると（Ｓ１０４）、バッファリングテーブル１８２のヘッドとテール情報を通じてバッファリングテーブル１８２の古くなったメッセージアドレスに移動して古くなったＣＡＮメッセージから一つずつ削除することができる。ここで、バッファリングテーブルの情報はバッファタイプ（例えば、００）とバッファインデックス（例えば、１００）を含み、削除する個数は２等のように数字で指定され得る。
【0099】
ここで、古くなったＣＡＮメッセージはアドレス０ｘ３ＦＤのバッファインデックス１００の保存領域アドレス（０、１、２）に順次保存されたＣＡＮメッセージであり得、その中で最も古くなったＣＡＮメッセージは０ｘ３ＦＤ列のバッファインデックス１００のバッファアドレス（０）に保存されたＣＡＮメッセージであり得る。
【0100】
【0101】
図１１を参照すると、探知エンジン１６０ａは政策バイナリ（ｐｏｌｉｃｙ ｂｉｎａｒｙ）のルックアップテーブルのすべてのＣＡＮメッセージを削除することができる。
【0102】
具体的には、探知エンジン１６０ａはＩＤＳコアから伝達されたＣＡＮメッセージのバッファリングテーブル（ｂｕｆｆｅｒｉｎｇ ｔａｂｌｅ）の情報を通じてバッファリングテーブルのすべてのＣＡＮメッセージを削除することができる。探知エンジン１６０ａからＡＰＩを含んだインターフェース１０８ですべてのメッセージ削除要請が伝達されると（Ｓ１１２）、バッファリングテーブル１８２ａ、１８２ｂは、インターフェース１０８を通じて伝達されるすべてのメッセージ削除要請によりバッファリングテーブル１８２ａ、１８２ｂの開始位置から全体メッセージを削除し、ヘッド（ｈｅａｄ）情報とテール（ｔａｉｌ）情報を初期化することができる（Ｓ１１４、Ｓ１１６）。
【0103】
前述した探知エンジンはバッファリングテーブルでＣＡＮメッセージを持ってき、ＩＤＳコアから伝達された政策インデックス情報を通じてフラッシュメモリなどのメモリに保存された政策バイナリの政策ボディーのメッセージ探知政策ルールに基づいてそれぞれのメッセージを探知することができる。ＣＡＮメッセージの探知政策はＢＵＳ探知、メッセージ（ｍｅｓｓａｇｅ）探知、シグナル（ｓｉｇｎａｌ）探知、メッセージ周期（ｉｎｔｅｒｖａｌ）探知（例えば１秒ごとに）を記載された順で処理される探知政策順序を含むことができる。このようなＣＡＮメッセージ別探知政策は独立的であり、探知政策の設定によって動作の有無が決定され得る。
【0104】
【0105】
図１２ａを参照すると、探知エンジンはＣＡＮメッセージ別探知政策により探知を開始する時、まず探知終了（ｄｅｔｅｃｔｉｏｎ ｅｎｄ、ＤＥ）を初期化することができる（Ｓ１２１）。ＤＥ初期化（ＤＥ ｉｎｉｔｉａｌｉｚｅ、Ｓ１２１）によると、バス（ｂｕｓ）、バス仲裁のための仲裁識別子（ａｒｂｉｔｒａｔｏｎ ｉｄ）、ローメッセージ（ｒａｗ ｍｅｓｓａｇｅ）、政策ヘッダー（ｐｏｌｉｃｙ ｈｅａｄｅｒ）、政策インデックス（ｐｏｌｉｃｙ ｉｎｄｅｘ）、バッファリングインデックス（ｂｕｆｆｅｒｉｎｇ ｉｎｄｅｘ）等に対するデフォルト（ｄｅｆａｕｌｔ）設定が初期化され得る。ＤＥ初期化（Ｓ１２１）が正常に遂行されず、事前で設定された手続きにより現在探知プロセスを終了することができる。
【0106】
次に、探知エンジンはバス検出フラグ（ｂｕｓ＿ｄｅｔｅｃｔ ｆｌａｇ）がオン（ｏｎ）であるかオフ（ｏｆｆ）であるかを判断することができる（Ｓ１２２）。バス検出フラグがオフ（ｏｆｆ）であれば、探知終了状態に進行することができる。
【0107】
バス検出フラグがオン（ｏｎ）であれば、探知エンジンはバスロード検出フラグ（ｂｕｓ＿ｌｏａｄ＿ｄｅｔｅｃｔ ｆｌａｇ）がオン（ｏｎ）であるかオフ（ｏｆｆ）であるかを判断することができる（Ｓ１２３）。
【0108】
バスロード検出フラグがオン（ｏｎ）であれば、探知エンジンは該当バスロード検出フラグが無効なバスロード（ｉｎｖａｌｉｄ ｂｕｓ ｌｏａｄ）であるかを判断することができる（Ｓ１２３ａ）。バスロード検出フラグが無効なバスロードあれば、探知エンジンは探知ログを生成（ｍａｋｅ ｄｅｔｅｃｔｉｏｎ ｌｏｇ）することができる（Ｓ１２３ｂ）。一方、バスロード検出フラグが無効なバスロードでなければ、バスロード検出フラグがオフ（ｏｆｆ）である段階に進行することができる。
【0109】
バスロード検出フラグがオフ（ｏｆｆ）であれば、探知エンジンはメッセージヘッダーが存在するかを判断することができる（Ｓ１２４）。メッセージヘッダーが存在しなければ、あるいはメッセージヘッダーがヌル（ｎｕｌｌ）であれば、探知エンジンは知られていないＣＡＮ ＩＤ検出フラグ（ｕｎｋｎｏｗｎ＿ｃａｎｉｄ＿ｄｅｔｅｃｔ ｆｌａｇ）がオン（ｏｎ）であるかオフ（ｏｆｆ）であるかを判断することができる（Ｓ１２４ａ）。知られていないＣＡＮ ＩＤ検出フラグがオン（ｏｎ）であれば、探知エンジンは探知ログを生成することができる（Ｓ１２４ｂ）。一方、探知エンジンは知られていないＣＡＮ ＩＤ検出フラグがオフ（ｏｆｆ）であるか探知ログが生成された後に探知プロセスの現在状態を探知終了段階に進行することができる。
【0110】
前述した段階（Ｓ１２３、Ｓ１２３ａ、Ｓ１２３ｂ、Ｓ１２４、Ｓ１２４ａ、Ｓ１２４ｂ）はバス（ｂｕｓ）探知手続きに該当し得る。
【0111】
一方、メッセージヘッダーが存在すれば（Ｓ１２４のＹｅｓ）、探知エンジンはデータ長さコード（ｄａｔａ ｌｅｎｇｔｈ ｃｏｄｅ、ＤＬＣ）が正しく定義されているかを判断することができる（Ｓ１２５）。ＤＬＣが正しくないと判断した場合、探知エンジンはＤＬＣ探知フラグ（ｄｌｃ＿ｄｅｔｅｃｔ ｆｌａｇ）がオン（ｏｎ）であるかオフ（ｏｆｆ）であるかを判断することができる（Ｓ１２５ａ）。ＤＬＣ探知フラグがオンであれば、探知エンジンは探知ログを生成し（Ｓ１２５ｂ）、現在探知プロセスを終了することができる。一方、ＤＬＣ探知フラグがオフ（ｏｆｆ）であれば、探知プロセスの現在状態はＤＬＣに関係なくＤＬＣが正しいと判断した段階に進行することができる。
【0112】
前述した段階（Ｓ１２５、Ｓ１２５ａ）はメッセージ（ｍｅｓｓａｇｅ）探知手続きに該当し得る。
【0113】
図１２ｂを参照すると、探知エンジンはＣＡＮバスに載せられたＣＡＮメッセージに対して制約条件利用可能であるか（ｃｏｎｓｔｒａｉｎｔ ｅｎａｂｌｅｄ、Ｓ１２６ａ）、循環重複検査（ｃｙｃｌｉｃ ｒｅｄｕｎｄａｎｃｙ ｃｈｅｃｋ、ＣＲＣ）利用可能であるか（ＣＲＣ ｅｎａｂｌｅｄ、Ｓ１２６ｂ）、チェックサム利用可能であるか（ｃｈｅｃｋｓｕｍ ｅｎａｂｌｅｄ、Ｓ１２６ｃ）、カウンター利用可能であるか（ｃｏｕｎｔｅｒ ｅｎａｂｌｅｄ、Ｓ１２６ｄ）、羅列（ｅｎｕｍｅｒａｔｅ、ｅｎｕｍ）利用可能であるか（ｅｎｕｍ ｅｎａｂｌｅｄ、Ｓ１２６ｅ）、オーバーフロー利用可能であるか（ｏｖｅｒｆｌｏｗ ｅｎａｂｌｅｄ、Ｓ１２６ｆ）、アンダーフロー利用可能であるか（ｕｎｄｅｒｆｌｏｗ ｅｎａｂｌｅｄ、Ｓ１２６ｇ）、そして、カスタムルール利用可能であるか（ｃｕｓｔｏｍ ｒｕｌｅ ｅｎａｂｌｅｄ、Ｓ１２６ｈ）を並列的にあるいは選択的に判断することができる。
【0114】
その次に、探知エンジンは、制約条件を利用できるのであれば、制約条件感知ロジック（ｃｏｎｓｔ ｄｅｔｅｃｔｉｏｎ ｌｏｇｉｃ）を実行したり（Ｓ１２７ａ）、ＣＲＣを利用できるのであれば、ＣＲＣ計算ロジック（ＣＲＣ ｃａｌｃｕｌａｔｅ ｌｏｇｉｃ）を実行したり（Ｓ１２７ｂ）、チェックサムを利用できるのであれば、チェックサム計算ロジック（ｃｈｅｃｋｓｕｍ ｃａｌｃｕｌａｔｅ ｌｏｇｉｃ）を実行したり（Ｓ１２７ｃ）、カウンターを利用できるのであれば、カウンターパターンを比較したり（ｃｏｍｐａｒｅ ｃｏｕｎｔｅｒ ｐａｔｔｅｒｎ、Ｓ１２７ｄ）、羅列を利用できるのであれば、羅列値を比較したり（ｃｏｍｐａｒｅ ｅｎｕｍ ｖａｌｕｅｓ、Ｓ１２７ｅ）、オーバーフローを利用できるのであれば、オーバーフロー値をテストしたり（ｔｅｓｔ ｏｖｅｒｆｌｏｗ ｖａｌｕｅ、Ｓ１２７ｆ）、アンダーフローを利用することができ、アンダーフロー値をテストしたり（ｔｅｓｔ ｕｎｄｅｒｆｌｏｗ ｖａｌｕｅ、Ｓ１２７ｇ）、そして、カスタムルールを利用できるのであれば、カスタム条件をテストしたり（ｔｅｓｔ ｃｏｓｔｏｍ ｃｏｎｄｉｔｉｏｎ、Ｓ１２７ｈ）することができる。
【0115】
その次に、図１２ｃに示した通り、探知エンジンはどのようなものが探知されたかを判断することができる（ｓｏｍｅｔｈｉｎｇ ｄｅｔｅｃｔｅｄ、Ｓ１２９）。何も探知されなかったと判断されると、探知エンジンはいま信号が感知されているかを判断し（ａｒｅ ｔｈｅｒｅ ｓｔｉｌｌ ｓｉｇｎａｌｓ ｔｏ ｂｅ ｄｅｔｅｃｔｅｄ、Ｓ１２９ａ）、まだまだ信号が探知中であれば、すべての信号に対して（ｆｏｒ ａｌｌ ｓｉｇｎａｌｓ）、前記の信号探知プロセスを繰り返し（ｒｅｐｅａｔ）遂行するように以前の段階（Ｓ１２６ａ～Ｓ１２６ｈ）に戻ることができる。
【0116】
一方、何らかのものが探知されたのであれば、探知エンジンは探知ログを生成することができる（Ｓ１３０）。そして、信号が探知中でなければ、探知エンジンは現在探知プロセスの状態を探知ログ生成（Ｓ１３０）後に進行することができる。
【0117】
前述した探知過程（Ｓ１２６ａ～Ｓ１２６ｈ、Ｓ１１２７ａ～Ｓ１２７ｈ、Ｓ１２９、Ｓ１２９ａ、Ｓ１３０）は信号（ｓｉｇｎａｌ）探知プロセスに対するものであり、探知エンジンによる信号探知結果はＣＡＮバスに載せられ得る。
【0118】
引き続き、図１２ｃを参照すると、探知エンジンは周期フラグ（ｉｎｔｅｒｖａｌ＿ｆｌａｇ）がオン（ｏｎ）であるかオフ（ｏｆｆ）であるかを判断することができる（Ｓ１３１）。周期フラグがオン（ｏｎ）であれば、探知エンジンは周期が正しいかを判断することができる（ｉｎｔｅｒｖａｌ ｃｏｒｒｅｃｔ、Ｓ１３１ａ）。周期が正しくなければ、探知エンジンは現在メッセージが無効であるかを判断することができる（Ｉｓ ｃｕｒｒｅｎｔ ｍｅｓｓａｇｅ ｉｓ ｉｎｖａｌｉｄ、Ｓ１３１ｂ）。現在メッセージが無効であれば、探知エンジンは探知ログを生成することができる（ｍａｋｅ ｄｅｔｅｃｔｉｏｎ ｌｏｇ、Ｓ１３１ｃ）。
【0119】
一方、周期フラグがオフ（ｏｎ）であるか、周期フラグの周期値が正しいか、現在メッセージが無効でないか、すなわち、過去メッセージが非正常的であるか（ｏｌｄ ｍｅｓｓａｇｅ ｉｓ ａｂｎｏｒｍａｌ）、現在メッセージが無効であるため探知ログを生成するそれぞれの場合に、探知エンジンは一つのメッセージ探知を完了したもの（ｄｅｔｅｃｔｉｏｎ ｏｆ ｏｎｅ ｍｅｓｓａｇｅ ｈａｓ ｂｅｅｎ ｃｏｍｐｌｅｔｅｄ）と作動することができる。
【0120】
前述した過程（Ｓ１３１、Ｓ１３１ａ、Ｓ１３１ｂおよびＳ１３１ｃ）はメッセージ周期（ｍｅｓｓａｇｅ ｉｎｔｅｒｖａｌ）探知または簡略に周期探知に該当し得る。
【0121】
【0122】
図１３を参照すると、ロギングシステムはＩＤＳコアや探知エンジン、政策規則から受信された探知ログを管理して記録する機能を担当することができる。また、ロギングシステムは記録されたログをクラウドサーバー（ｃｌｏｕｄ ｓｅｒｖｅｒ）等の外部システムに伝送することができる。
【0123】
ロギングシステムは外部システムにログメッセージを伝達するために、統合診断サービス（ｕｎｉｆｉｅｄ ｄｉａｇｎｏｓｔｉｃ ｓｅｒｖｉｃｅ、ＵＤＳ）プロトコルのデータ識別子（ｄａｔａ ｉｄｅｎｔｉｆｉｅｒ、ＤＩＤ）を利用して車両内のＣＡＮメッセージの探知ログ記録を伝送することができる。このために、ロギングシステムは第１ノード（Ｎｏｄｅ＃１）と第２ノード（Ｎｏｄｅ＃２）の間に約束されたメモリアドレスを共有するように具現され得る。
【0124】
ここで、メモリ１０６ａはＳＲＡＭ（ｓｔａｔｉｃ ｒａｍｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）等の半導体メモリを含むことができる。探知ログ（ｄｅｔｅｃｔｉｏｎ ｌｏｇ）記録は所定の大きさ、例えば１０４バイト（ｂｙｔｅ）大きさで保存され得る。メモリ１０６ａには読み取り位置（ｒｅａｄ ｐｏｓｉｔｉｏｎ、ｒｅａｄ ｐｏｓ）と書き込み位置（ｗｒｉｔｅ ｐｏｓ）および所定の大きさ（例えば、４８バイト）の状態ログ（ｓｔａｔｕｓ ｌｏｇ）が保存され得る。
【0125】
第１ノードはＩＤＳロギングフィーチャー（ＩＤＳ ｌｏｇｇｉｎｇ ｆｅａｔｕｒｅ、１０７）を開始し、異常探知（ａｎｏｍａｌｙ ｄｅｔｅｃｔｉｏｎ）時に読み取り位置をアップデートし（ｕｐｄａｔｅ ｒｅａｄ ｐｏｓ）、バッファがオーバーフローされると（ｉｆ ｂｕｆｆｅｒ ｉｓ ｏｖｅｒｆｌｏｗｅｄ）書き込み位置をアップデートすることができる（ｕｐｄａｔｅ ｗｒｉｔｅ ｐｏｓ）。アップデートされた記録はメモリ１０６ａの読み取り位置または書き込み位置に保存され得る。また、第１ノードは毎１分の周期で状態ログをメモリ１０６ａの状態ログ（ｓｔａｔｕｓ ｌｏｇ）に保存することができる。
【0126】
第２ノードはゲートウェイ（ｇａｔｅｗａｙ、ＧＷ）ＵＤＳフィーチャー１０９を開始し、１００ミリ秒の周期でメモリ１０６ａの読み取り位置と書き込み位置を読み取り（ｐｏｌｌｉｎｇ）、これを利用して４個の探知ログデータを獲得することができる。また、第２ノードは毎１０分の周期で状態ログを読み取って自身の状態を状態ログに保存することができる。
【0127】
前述したロギングシステムは第１ノードのＩＤＳロギングフィーチャー１０７に対応することができ、外部システムに探知ログ情報を入れたログメッセージを提供するために第２ノードのゲートウェイＧＷを利用するように構成され得る。
【0128】
前述したロギングシステムはＩＤＳすなわち、探知エンジンでＣＡＮバスで異常状況を探知した場合に動作する。発生されるログメッセージはゲートウェイのＵＤＳプロトコルを通じて外部システムに伝達され得る。ロギングシステムはＵＤＳプロトコルを利用したメッセージ伝送機能を通じて予め共有された共有メモリアドレスを有することができる。
【0129】
【0130】
図１４を参照すると、ロギングシステムに採用できるメッセージフォーマットはＵＤＳプロトコルを利用するメッセージフォーマットを含むことができる。
【0131】
メッセージフォーマットはバッファヘッダー（ｂｕｆｆｅｒ ｈｅａｄｅｒ、ｂｕｆ ｈｅａｄｅｒ）、探知ログ（ｄｅｔｅｃｔｉｏｎ ｌｏｇ）および状態ログ（ｓｔａｔｕｓ ｌｏｇ）で構成され得る。
【0132】
バッファヘッダーは１バイトの大きさを有し、ヘッド（ｈｅａｄ）とテール（ｔａｉｌ）を含むことができる。ヘッドとテールはそれぞれ４ビット（ｂｉｔ）の大きさを有することができるが、これに限定されはしない。すなわち、バッファヘッダーはヘッダー（ｈｅａｄ）に対応する書き込み位置（ｗｒｉｔｅ ｐｏｓｉｔｉｏｎ）とテール（ｔａｉｌ）に対応する読み取り位置（ｒｅａｄ ｐｏｓｉｔｉｏｎ）で構成され得る。読み取り位置は第２ノードが管理し、書き込み位置は第１ノードが管理することができる。
【0133】
探知ログは１０４０バイトの大きさを有し、１０４バイトの１０個のバッファ（ｂｕｆｆｅｒ［０］～ｂｕｆｆｅｒ［９］）を含むことができるが、これに限定されはしない。
【0134】
探知ログが発生すれば、バッファヘッダーの書き込み位置を読み込んで記録する探知ログ位置を求めた後、該当位置にメッセージを保存し、次の位置の探知ログ位置に読み取り位置をアップデートすることができる。状態ログは１分ごとにＩＤＳまたは探知エンジンの現在状態を記録することができる。状態ログは４８バイトの大きさを有し、ＩＤＳまたは探知エンジンの状態情報（ｓｔａｔｕｓ ｉｎｆｏｒｍａｔｉｏｎ、ｓｔａｔｕｓ ｉｎｆｏ）を記録することができる。
【0135】
前述した場合、第２ノードでは１００ｍｓごとに共有メモリのバッファヘッダーの書き込み位置または読み取り位置の差に伝送する探知ログが存在するかを確認することができる。伝送する探知ログがある場合、第２ノードは伝送する探知ログの個数を求め、ＵＤＳプロトコルを利用して該当探知ログを外部システムに伝送することができる。
【0136】
また、第２ノードはＵＤＳリクエスト（ｒｅｑｕｅｓｔ）イベント要請または毎１０分ごとに状態ログを読み込んでＵＤＳに伝送することができる。該当時間は顧客の要求事項により時間を修正することができ、ＩＤＳ攻撃の有無にかかわらずゲートウェイの状態値を伝送することができる。
【0137】
【0138】
図１５を参照すると、探知ログバッファのための探知ログのメッセージ構造は１バイトのログタイプ（ｌｏｇ ｔｙｐｅ）を含む。ログタイプは１ビット（ｂｉｔ）のタイプ（ｔｙｐｅ）と７ビットのログサイズで構成され、ここでタイプはログ類型を区分し、ログサイズはログタイプを含んだ全体の大きさを示す。探知ログのログ類型は例えば０で設定され得る。
【0139】
また、探知ログのメッセージ構造は異常探知されたＣＡＮバス番号を示す１バイトのＣＡＮバス番号（ｃａｎ ｂｕｓ ｎｕｍｂｅｒ）、１バイトの異常探知された規則の番号（ｖｉｏｌａｔｉｏｎ ｒｕｌｅ ｉｄ）、メッセージの信号開始位置を数字で表示する２バイトの信号開始ビット（ｓｉｇｎａｌ ｓｔａｒｔ ｂｉｔ）、ＣＡＮメッセージの信号の長さを数字で表示する２バイトの信号の長さ（ｓｉｇｎａｌ ｌｅｎｇｔｈ）、ＣＡＮメッセージの信号の長さを数字で表示する１バイトのローメッセージ長さ（ｒａｗ ｍｅｓｓａｇｅ ｌｅｎｇｔｈ）、４バイトのＣＡＮメッセージのＣＡＮ ＩＤ（ｍｅｓｓａｇｅ ｃａｎ ｉｄ）、異常探知された時間を年月日時分秒に変換できるベース数字で表示する４バイトの探知時間（ｄｅｔｅｃｔｉｏｎ ｔｉｍｅ）、異常探知された内容を数字で表示する８バイトの探知理由（ｄｅｔｅｃｔｉｏｎ ｒｅａｓｏｎ）、ログが重複する時に重複された回数を数字で表示する２バイトの重複回数（ｄｕｐｌｉｃａｔｉｏｎ ｎｕｍｂｅｒ）、デフォルトで０ｘ０に初期化され得、追加必要情報を入れるための予約空間を表示する１４バイトの予約（ｒｅｓｅｒｖｅｄ）、ＣＡＮメッセージの全体データを表示する６４バイトのローメッセージボディ（ｒａｗ ｍｅｓｓａｇｅ ｂｏｄｙ）で構成されるフィールドを含むことができる。
【0140】
【0141】
図１６を参照すると、ＣＡＮ ＩＤＳ１６０ｂで異常探知メッセージが発生すれば、探知エンジンはバッファヘッダーの書き込み値（ｗｒｉｔｅ ｖａｌｕｅ）を参照して該当メモリのバッファ領域の探知ログバッファに異常探知メッセージを記録する。
【0142】
具体的には、異常探知メッセージが発生すれば、ＣＡＮ ＩＤＳ１６０ｂはバッファヘッダーの読み取り位置に第１探知ログ（Ｄｅｔｅｃｔｉｏｎ ｌｏｇ ＃１）を記録することができる（Ｓ１６２）。読み取り位置がバッファ［０］であるとき、書き込み位置はバッファ［１］で設定され得る。
【0143】
次に、異常探知メッセージが発生すれば、ＣＡＮ ＩＤＳ１６０ｂはバッファヘッダーの読み取り位置に第２探知ログ（Ｄｅｔｅｃｔｉｏｎ ｌｏｇ ＃２）を記録することができる（Ｓ１６４）。この時、読み取り位置はバッファ［０］で維持され、書き込み位置は以前のメッセージが記録されたバッファ位置の次の位置であるバッファ［２］で設定され得る。
【0144】
次に、異常探知メッセージが発生すれば、ＣＡＮ ＩＤＳ１６０ｂはバッファヘッダーの読み取り位置に第３探知ログ（Ｄｅｔｅｃｔｉｏｎ ｌｏｇ ＃３）を記録することができる（Ｓ１６６）。この時、読み取り位置はバッファ［０］で維持され、書き込み位置は以前のメッセージが記録されたバッファ位置の次の位置であるバッファ［３］で設定され得る。
【0145】
一方、ゲートウェイ１９０はＤＩＤデータ伝送状態を記録しなければならず、すでに外部システムで読み込んだＤＩＤに対してもゲートウェイが重複で要請することができないので、ゲートウェイ１９０に合う適切なＤＩＤデータ伝送手続きが必要である。
【0146】
【0147】
図１７を参照すると、ゲートウェイ１９０はまず、バッファヘッダーの読み取り値と書き込み値を比較するか読み取り値と書き込み値を通じてバッファカウントをチェックすることができる（Ｓ１７１）。
【0148】
次に、ゲートウェイ１９０は読み取り値と書き込み値の差だけ計数されたバッファのアドレスをデータ抽出要請信号に含ませて外部システム２００に伝送することができる（Ｓ１７２）。例えば、計数されたバッファのアドレスが３であれば、ゲートウェイ１９０は伝送される３個のログデータに対する情報を外部システム２００に伝達することに該当し得る。本実施例にゲートウェイ１９０は最大４個のＤＩＤ番号でデータ抽出を要請するものとして例示するが、これに限定されるものではない。
【0149】
また、ゲートウェイ１９０はＯＴＡ（ｏｖｅｒ ｔｈｅ ａｉｒ）、ＤＩＡＧに対する例外処理を遂行し、３個のログデータのＤＩＤを読み込むように要請メッセージを生成することができる。そして、遠隔ＤＩＡＧのための例外処理関連メッセージを外部システム２００に伝送することができる（Ｓ１７３）。
【0150】
この時、外部システム２００はゲートウェイ１９０から伝達された要請に対してＵＤＳ ＤＩＤ読み取り要請メッセージをゲートウェイ１９０に伝達することができる（Ｓ１７４）。すなわち、ゲートウェイ１９０は外部システム２００から先立って伝達した要請に対応するＵＤＳ ＤＩＤ読み取り要請メッセージを受けることができる。
【0151】
次に、ＵＤＳ ＤＩＤ読み取り要請メッセージを受信すれば、ゲートウェイ１９０はバッファヘッダーの読み取り値を参照するバッファのデータを読み込み、読み込んだデータを外部システム２００に伝送することができる（Ｓ１７５）。例えば、ゲートウェイ１９０はＵＤＳ ＤＩＤ読み取り要請メッセージの受信によりバッファで第１ログデータ（０ ｌｏｇ ｄａｔａまたはｌｏｇ ｄａｔａ ＃０）を読み込み、ＵＤＳ ＤＩＤ読み取り要請メッセージの応答（ｒｅｓｐｏｎｓｅ）として第１ログデータを外部システム２００に提供することができる。
【0152】
ゲートウェイ１９０からメッセージを受信すれば、外部システム２００は成功メッセージをゲートウェイ１９０に伝送することができる（Ｓ１７６）。成功メッセージを受信したゲートウェイ１９０は読み取り値に１を足すことができる。すなわち、ゲートウェイ１９０は成功メッセージの受信によりバッファヘッダーの読み取り位置をアップデートすることができる（ｕｐｄａｔｅ ｒｅａｄ ｐｏｓｉｔｉｏｎ ｏｆ ｂｕｆｆｅｒ ｈｅａｄｅｒ）。
【0153】
一方、車両に配布されたＣＡＮ ＩＤＳのバージョン情報およびシステム資源使用情報などを含む状態ログ（ｓｔａｔｕｓ ｌｏｇ）は割り当てられたアドレス領域にデータを記録するように構成される。この時、ゲートウェイ１９０は状態ログバッファに１個のＤＩＤ保存空間を提供することができる。
【0154】
【0155】
図１８を参照すると、状態ログバッファのための状態ログのメッセージ構造は１個のＤＩＤ保存空間であり、多数のフィールドで構成され得る。まず、状態ログのメッセージ構造は１バイトのログタイプ（ｌｏｇ ｔｙｐｅ）を含むことができる。ログタイプは１ビット（ｂｉｔ）のタイプ（ｔｙｐｅ）と７ビットのログサイズで構成され、ここでタイプはログ類型を区分し、ログサイズはログタイプを含んだ全体の大きさを示すことができる。状態ログのログ類型は例えば０で設定され得る。
【0156】
また、状態ログのメッセージ構造は順次発生した状態メッセージの番号を表示する２バイトの順序番号（ｓｅｑｕｎｃｅ ｎｕｍｂｅｒ）を含むことができる。順序番号は状態メッセージを書き込む時に順次増加し、ゲートウェイが予め保存された順序番号を持っていくと初期化され得る。
【0157】
また、状態ログのメッセージ構造はＣＡＮ ＩＤＳが使用中のＲＡＭメモリを表示する４バイトのメモリ使用量（ｍｅｍｏｒｙ ｕｓａｇｅ）を含むことができる。メモリ使用量の単位はパーセント（％）であり得るが、これに限定されはしない。
【0158】
また、状態ログのメッセージ構造はＩＤＳが政策保存のために使用中であるフラッシュメモリを表示する４バイトのフラッシュ使用量（ｆｌａｓｈ ｕｓａｇｅ）を含むことができる。フラッシュ使用量の政策ファイルの大きさの単位はパーセント（％）であり得、政策バイナリファイルの上位４バイトを使うことができる。
【0159】
また、状態ログのメッセージ構造は政策バージョン情報を表示する６バイトの政策バージョン（ｐｏｌｉｃｙ ｖｅｒｓｉｏｎ）を含むことができる。政策バージョンは重要である（ｍａｊｏｒ）、重要でない（ｍｉｎｏｒ）、リリース（ｒｅｌｅａｓｅ）情報などを含むことができる。例えば、重要であるは１で表示し、重要でないは０で表示し、リリース情報は１次を示す１、２次を示す２などで表示され得る。
【0160】
また、状態ログのメッセージ構造はＩＤＳファームウェアバージョン情報を表示する６バイトのＩＤＳファームウェアバージョン（ＩＤＳ ｆｉｒｍｗａｒ ｖｅｒｓｉｏｎ）を含むことができる。ＩＤＳファームウェアバージョンは多数（ｍａｊｏｒ）、少数（ｍｉｎｏｒ）、リリース（ｒｅｌｅａｓｅ）情報などを含むことができる。例えば、多数は１で表示し、小数は０で表示し、リリース情報は１次を示す１、２次を示す２などで表示され得る。
【0161】
また、状態ログのメッセージ構造は基本であるいはデフォルトで０ｘ０で初期化され得、追加で必要な情報を入れるための予約空間を示す２５バイトの予約（ｒｅｓｅｒｖｅｄ）を含むことができる。
【0162】
前述した状態ログは１分ごとに状態ログバッファに上書き（ｏｖｅｒｗｒｉｔｅ）で記録され得る。
【0163】
【0164】
図１９を参照すると、ＣＡＮ ＩＤＳ１６０ｂまたはＣＡＮ ＩＤＳ１６０ｂの探知エンジンは状態情報バッファ（ｓｔａｔｕｓ ｉｎｆｏ ｂｕｆｆｅｒ、１９２）に状態ログ（ｓｔａｔｕｓ ｌｏｇ）を周期的に記録することができる。状態情報バッファ１９２の大きさは４８バイトであり得るが、これに限定されはしない。
【0165】
一例として、ＣＡＮ ＩＤＳ１６０ｂは第一状態ログ（ｓｔａｔｕｓ ｌｏｇ ＃０）を状態情報バッファ１９２に記録（ｗｒｉｔｅ）することができる（Ｓ１９０）。そして、１分（１ ｍｉｎｕｔｅ、１Ｍｉｎ）間隔で第２状態ログ（ｓｔａｔｕｓ ｌｏｇ ＃１）、第３状態ログ（ｓｔａｔｕｓ ｌｏｇ ＃２）、そして、第ｎ状態ログ（ｓｔａｔｕｓ ｌｏｇ ＃ｎ）を状態情報バッファ１９２に順次記録することができる（Ｓ１９１、Ｓ１９２、Ｓ１９ｎ）。ｎは４以上の任意の自然数であり得る。
【0166】
図２０は、本開示の他の実施例に係るＣＡＮ ＩＤＳに対する概略的な構成図である。
【0167】
図２０を参照すると、ＣＡＮ ＩＤＳ２０００は少なくとも一つのプロセッサ（ｐｒｏｃｅｓｓｏｒ、２０１０）、メモリ（ｍｅｍｏｒｙ、２０２０）、およびネットワークと連結されて通信を遂行する送受信装置（ｔｒａｎｓｃｅｉｖｅｒ、２０６０）を含むことができる。また、ＣＡＮ ＩＤＳ２０００は保存装置（ｓｔｏｒａｇｅ ｄｅｖｉｃｅ、２０３０）、入力インターフェース装置（ｉｎｐｕｔ ｉｎｔｅｒｆａｃｅ ｄｅｖｉｃｅ、２０４０）、出力インターフェース装置（ｏｕｔｐｕｔ ｉｎｔｅｒｆａｃｅ ｄｅｖｉｃｅ、２０５０）等をさらに含むことができる。ＣＡＮ ＩＤＳ２０００に含まれたそれぞれの構成要素はバスによって連結されて通信を遂行できる。
【0168】
プロセッサ２０１０は中央処理装置（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＣＰＵ）、グラフィック処理装置（ｇｒａｐｈｉｃｓ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＧＰＵ）、または本発明の実施例に係る方法が遂行される専用のプロセッサを意味し得る。
【0169】
メモリ２０２０および保存装置２０３０それぞれは揮発性保存媒体および不揮発性保存媒体のうち少なくとも一つで構成され得る。例えば、メモリ２０２０は読み取り専用メモリ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ、ＲＯＭ）およびランダムアクセスメモリ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ、ＲＡＭ）のうち少なくとも一つで構成され得る。
【0170】
また、プロセッサ２０１０はメモリ２０２０および保存装置２０３０のうち少なくとも一つに保存されたプログラム命令（ｐｒｏｇｒａｍ ｃｏｍｍａｎｄ）を実行することができる。プログラム命令は少なくとも一つの命令を含み、少なくとも一つの命令はソフトウェアモジュールやプログラムに含まれ得る。
【0171】
入力インターフェース装置２０４０はキーボード、マイク、タッチパッド、タッチスクリーンなどの入力手段から選択される少なくとも一つと少なくとも一つの入力手段を通じて入力される信号を予め保存された命令とマッピングしたり処理する入力信号処理部を含むことができる。
【0172】
出力インターフェース装置２０５０はプロセッサ２０１０の制御により出力される信号を予め保存された信号形態やレベルでマッピングしたり処理する出力信号処理部と、出力信号処理部の信号により振動、光などの形態で信号や情報を出力する少なくとも一つの出力手段を含むことができる。少なくとも一つの出力手段はスピーカー、ディスプレイ装置、プリンタ、光出力装置、振動出力装置などの出力手段から選択される少なくとも一つを含むことができる。
【0173】
送受信装置２０６０は近距離無線ネットワークやケーブル連結、衛星との通信、汎用基地局との有線または無線通信、モバイルエッジコアネットワークやコアネットワーク（ｃｏｒｅ ｎｅｔｗｏｒｋ）とのアイディアルバックホールリンク（ｉｄｅａｌ ｂａｃｋｈａｕｌ ｌｉｎｋ）またはノン（ｎｏｎ）－アイディアルバックホールリンクの連結などのための通信インターフェースやサブ通信システムを含むことができる。
【0174】
前述した本発明に係る方法は、多様なコンピュータ手段を通じて実行され得るプログラム命令形態で具現されてコンピュータ読み取り可能媒体に記録され得る。コンピュータ読み取り可能媒体はプログラム命令、データファイル、データ構造などを単独でまたは組み合わせて含むことができる。コンピュータ読み取り可能媒体に記録されるプログラム命令は本発明のために特別に設計されて構成されたものであるかコンピュータソフトウェア当業者に公知の使用可能なものであってもよい。
【0175】
コンピュータ読み取り可能媒体の例にはロム（ｒｏｍ）、ラム（ｒａｍ）、フラッシュメモリ（ｆｌａｓｈ ｍｅｍｏｒｙ）等のようにプログラム命令を保存し遂行するように特別に構成されたハードウェア装置が含まれる。プログラム命令の例にはコンパイラ（ｃｏｍｐｉｌｅｒ）により作られるような機械語コードだけでなくインタープリタ（ｉｎｔｅｒｐｒｅｔｅｒ）等を使ってコンピュータによって実行され得る高級言語コードを含む。前述したハードウェア装置は本発明の動作を遂行するために少なくとも一つのソフトウェアモジュールで作動するように構成され得、その逆も同様である。
【0176】
本発明の一部の側面は装置の文脈で説明されたが、それは相応する方法による説明も示すことができ、ここでブロックまたは装置は方法段階または方法段階の特徴に相応する。同様に、方法の文脈で説明された側面はまた、相応するブロックまたはアイテムまたは相応する装置の特徴で示すことができる。方法段階のいくつか又は全部は例えば、マイクロプロセッサ、プログラム可能なコンピュータまたは電子回路のようなハードウェア装置によって（または利用して）遂行され得る。いくつかの実施例で、最も重要な方法段階の少なくとも一つ以上はこのような装置によって遂行され得る。
【0177】
実施例で、プログラム可能なロジック装置例えば、フィールドプログラマブルゲートアレイがここで説明された方法の機能の一部又は全部を遂行するために使われ得る。実施例で、フィールドプログラマブルゲートアレイ（ｆｉｅｌｄ－ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）はここで説明された方法のうち一つを遂行するためのマイクロプロセッサ（ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ）とともに作動することができる。一般的に、方法は何らかのハードウェア装置によって遂行されることが好ましい。
【0178】
以上、実施例を参照して説明したが、該当技術分野の熟練した当業者は下記の特許請求の範囲に記載された本発明の思想および領域から逸脱しない範囲内で本発明を多様に修正および変更できることが理解できるであろう。
【要約】 （修正有）
【課題】コントローラ領域ネットワーク（ＣＡＮ）の侵入を探知する侵入探知システム（ＩＤＳ）及びその作動方法を提供する。
【解決手段】作動方法は、ＣＡＮパケットミラーリングシステムによって、ＡＵＴＯＳＡＲ階層のＡＵＴＯＳＡＲ Ｐｄｕルータ領域に存在するＣＡＮドライバからＣＡＮメッセージを受信する段階、受信したメッセージをメモリの複数の保存領域に保存する段階、ＩＤＳコアによって、ＣＡＮパケットミラーリングシステムでコピーされたデータを読み込んで探知エンジンベースに伝達する段階およびＩＤＳコア階層のＩＤＳコアによって、ＩＤＳの政策規則である政策バイナリファイルを保存する第１メモリ領域とＣＡＮメッセージをバッファリングし保存するためのバッファリングテーブルを保存する第２メモリ領域を分けて管理する段階を含む。
【選択図】図３
【解決手段】作動方法は、ＣＡＮパケットミラーリングシステムによって、ＡＵＴＯＳＡＲ階層のＡＵＴＯＳＡＲ Ｐｄｕルータ領域に存在するＣＡＮドライバからＣＡＮメッセージを受信する段階、受信したメッセージをメモリの複数の保存領域に保存する段階、ＩＤＳコアによって、ＣＡＮパケットミラーリングシステムでコピーされたデータを読み込んで探知エンジンベースに伝達する段階およびＩＤＳコア階層のＩＤＳコアによって、ＩＤＳの政策規則である政策バイナリファイルを保存する第１メモリ領域とＣＡＮメッセージをバッファリングし保存するためのバッファリングテーブルを保存する第２メモリ領域を分けて管理する段階を含む。
【選択図】図３
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12a】
【図12b】
【図12c】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
