JP2019213081A - 半導体装置及び情報処理方法 - Google Patents

Abstract

【課題】処理時間の増大を抑制しつつフィルタ処理を行うことが可能な半導体装置を提供する。【解決手段】半導体装置１は、マイクロコントローラ２で構成される。マイクロコントローラ２は、ＣＰＵ４と、メモリ６と、ＣＡＮコントローラ１０とを有する。メモリ６は、ソフトウェアを格納する。ＣＰＵ４は、メモリ６に格納されたソフトウェアを実行する。ＣＡＮコントローラ１０は、メッセージ情報にラベル情報を付加するように構成されている。メモリ６に格納されたＣＡＮルーティングソフトウェア１００は、ラベル情報を用いて、メッセージ情報をルーティングするか否かを判定するためのフィルタ処理を行うフィルタ処理機能を実現する。【選択図】図１

Description

本発明は、半導体装置及び情報処理方法に関する。

車載ネットワークに接続されたＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）等の車載機器間でデータが送受信される。この車載ネットワークの通信規格として、例えばＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）がある。また、車載機器のソフトウェア構造を規定する規格として、例えばＡＵＴＯＳＡＲ（ＡＵＴｏｍｏｔｉｖｅ Ｏｐｅｎ Ｓｙｓｔｅｍ ＡＲｃｈｉｔｅｃｔｕｒｅ）がある。この技術に関連し、特許文献１及び特許文献２は、ＡＵＴＯＳＡＲに準拠したソフトウェア構造を有する機器を開示している。

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

車載機器間でデータを送受信する際に、データを転送（ルーティング）するか否かを判断するフィルタ処理を行うことがある。このフィルタ機能がＡＵＴＯＳＡＲのような車載機器のソフトウェア構造を規定する規格に規定されていない場合、アプリケーション層に組み込まれたソフトウェア（アプリケーション）でフィルタ処理を実行する必要がある。しかしながら、このような構成では、フィルタ処理に要する処理時間が増大するおそれがある。

その他の課題と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

一実施の形態によれば、半導体装置は、ソフトウェアを格納する記憶回路と、前記ソフトウェアを実行する少なくとも１つの処理回路と、車載ネットワークから受信されたメッセージ情報に付加情報を付加するように構成されたコントローラとを有し、前記ソフトウェアは、前記付加情報を用いて、前記コントローラから出力された前記メッセージ情報をルーティングするか否かを判定するためのフィルタ処理を行うフィルタ処理機能を実現する半導体装置である。

また、一実施の形態によれば、半導体装置は、ソフトウェアを格納する記憶回路と、前記ソフトウェアを実行する少なくとも１つの処理回路と、車載ネットワークから受信されたメッセージ情報に付加情報を付加するように構成されたコントローラとを有し、前記ソフトウェアは、前記半導体装置を構成するマイクロコントローラに依存しない処理を実行するアプリケーションと、前記アプリケーションを前記マイクロコントローラに依存しないようにする基本ソフトウェアとを有し、前記基本ソフトウェアは、前記半導体装置のハードウェアを抽象化するレイヤに設けられた、前記車載ネットワークを規定するプロトコルを使用可能とするためのネットワークインタフェースにおいて、前記付加情報を用いて、前記コントローラから出力された前記メッセージ情報をルーティングするか否かを判定するためのフィルタ処理を行うフィルタ処理機能を実現する半導体装置である。

また、一実施の形態によれば、情報処理方法は、車載ネットワークから受信されたメッセージ情報に付加情報を付加し、前記付加情報を用いて、前記メッセージ情報をルーティングするか否かを判定するためのフィルタ処理を行う情報処理方法である。

前記一実施の形態によれば、処理時間の増大を抑制しつつフィルタ処理を行うことが可能な半導体装置及び情報処理方法を提供できる。

実施の形態１にかかる半導体装置のハードウェア構成を示す図である。 実施の形態１にかかるＣＡＮルーティングソフトウェアを示す図である。 実施の形態１にかかる半導体装置の構成を示す機能ブロック図である。 実施の形態１にかかる半導体装置によって行われるルーティング処理の概要を示す図である。 実施の形態１にかかる半導体装置のフィルタ処理機能の詳細を示すブロック図である。 実施の形態１にかかる受信ルールテーブルを例示する図である。 実施の形態１にかかるペイロードフィルタテーブルを例示する図である。 実施の形態１にかかる半導体装置によって行われる情報処理方法を示すフローチャートである。 実施の形態１にかかる半導体装置によって行われる情報処理方法を示すフローチャートである。 第１の比較例について説明するための図である。 第２の比較例について説明するための図である。 実施の形態２にかかる半導体装置の構成を示す図である。

以下、実施形態について、図面を参照しながら説明する。説明の明確化のため、以下の記載及び図面は、適宜、省略、及び簡略化がなされている。なお、各図面において、同一の要素には同一の符号が付されており、必要に応じて重複説明は省略されている。

以下の実施の形態においては便宜上その必要があるときは、複数のセクションまたは実施の形態に分割して説明するが、特に明示した場合を除き、それらはお互いに無関係なものではなく、一方は他方の一部または全部の変形例、応用例、詳細説明、補足説明等の関係にある。また、以下の実施の形態において、要素の数等（個数、数値、量、範囲等を含む）に言及する場合、特に明示した場合および原理的に明らかに特定の数に限定される場合等を除き、その特定の数に限定されるものではなく、特定の数以上でも以下でもよい。

さらに、以下の実施の形態において、その構成要素（動作ステップ等も含む）は、特に明示した場合および原理的に明らかに必須であると考えられる場合等を除き、必ずしも必須のものではない。同様に、以下の実施の形態において、構成要素等の形状、位置関係等に言及するときは、特に明示した場合および原理的に明らかにそうでないと考えられる場合等を除き、実質的にその形状等に近似または類似するもの等を含むものとする。このことは、上記数等（個数、数値、量、範囲等を含む）についても同様である。

また、様々な処理を行う機能ブロックとして図面に記載される各要素は、ハードウェア的には、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、メモリ、その他の回路で構成することができ、ソフトウェア的には、メモリにロードされたプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。

（実施の形態の概要）
車載ネットワークでは、ＣＡＮプロトコルを使用した通信が、制御系のデータ交換用途に主に使用されている。このＣＡＮ通信データを接続される各機器へ中継する役割を持つコンポーネントは、ゲートウェイと呼ばれている。自動運転等の新たな技術への対応により、このゲートウェイで取り扱うＣＡＮ通信のチャネル数の増加及び利用される通信量の増加の傾向があり、通信性能の要求が、より厳しくなっている。

一方、このＣＡＮ通信を制御するためのソフトウェア構造を決める規格として、ＡＵＴＯＳＡＲがあり、このＡＵＴＯＳＡＲの規格に沿った形でソフトウェアが実現されていることが多い。ここで、ＡＵＴＯＳＡＲで規格化されていない機能をゲートウェイ上の機能として実現しようとした場合、ＡＵＴＯＳＡＲソフトウェア（後述する基本ソフトウェアおよびＲＴＥ）よりも上位のアプリケーションとして、ソフトウェアを実装する必要がある。昨今のセキュリティに関する要求の高まり等により、このようなＡＵＴＯＳＡＲで規格化されていないフィルタ機能が、ゲートウェイの機能として要求されることも増えてきている。しかしながら、アプリケーションとして実装した場合、ＡＵＴＯＳＡＲソフトウェアを介した通信となるため、通信遅延が大きくなり、昨今の通信性能要求の厳しさに耐えられなくなってきている。このような状況の中で、より高速にＣＡＮのフィルタ処理を行う技術が求められている。

また、マイクロコントローラは、受信したＣＡＮメッセージの識別子（ＩＤ）をチェックして、適切なメッセージか否かに応じてメッセージを振り分けて、振り分けられたデータをソフトウェアへ渡すハードウェアルーティング機能を有している。そして、マイクロコントローラは、このメッセージの振り分けの際に、ソフトウェアに渡すデータにラベル（付加情報）を付加する機能を有する。しかしながら、ＡＵＴＯＳＡＲの規格では、ＰＤＵＲ（ＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ） Ｒｏｕｔｅｒ）（後述する図２を参照）よりも上位のレイヤでは、ＣＡＮプロトコルに準拠したメッセージデータを、メッセージ受信時のデータ構造とは異なる構造へ加工してしまう。そのため、マイクロコントローラのハードウェア機能でデータに付加された付加情報が、ＰＤＵＲよりも上位のコンポーネントで失われてしまう。そのため、ソフトウェア処理の効率化が難しかった。一方、本実施の形態においては、以下に説明するように、上記のマイクロコントローラの機能を利用して、高速にＣＡＮのフィルタ処理を行うように構成されている。

（実施の形態１）
次に、実施の形態１について説明する。
図１は、実施の形態１にかかる半導体装置１のハードウェア構成を示す図である。半導体装置１は、車両に搭載され、車両の制御のために使用されるＥＣＵである。半導体装置１は、複数の車載機器が接続された車載ネットワークに接続されている。車載ネットワークは、例えばＣＡＮに準拠しているが、これに限定されない。実施の形態１に示す例では、車載ネットワークがＣＡＮに準拠しているとしている。

半導体装置１は、例えばＣＡＮを用いた通信で送受信されるＣＡＮ通信データを他の車載機器に転送（中継）するゲートウェイであるが、半導体装置１は、ゲートウェイに限定されない。半導体装置１は、マイクロコントローラ２で構成される。マイクロコントローラ２は、処理回路である少なくとも１つのＣＰＵ４と、記憶回路であるメモリ６と、チャネルインタフェース８と、ＣＡＮコントローラ１０とを有する。メモリ６は、ソフトウェアを格納する。ＣＰＵ４は、メモリ６に格納されたソフトウェアを実行する。チャネルインタフェース８は、ＣＡＮの複数のチャネルとのインタフェースを実現する。

ＣＡＮコントローラ１０は、ＣＡＮプロトコルに準拠したＣＡＮ通信データを他の車載機器に転送（中継）するためのルーティング処理を実行する、ハードウェアコンポーネントである。ＣＡＮコントローラ１０は、ハードウェアによるルーティング機能（ハードウェアルーティング機能）を実現する。具体的には、ＣＡＮコントローラ１０は、予め定められた受信ルールに従って、ＣＡＮから受信されたメッセージ情報を振り分ける。ここで、メッセージ情報は、ＣＡＮ通信データである。そして、ＣＡＮコントローラ１０は、メッセージ情報の識別子（ＩＤ）を用いて、メッセージ情報を転送（ルーティング）するためのフィルタ処理を行う。さらに、ＣＡＮコントローラ１０は、メッセージ情報に付加情報であるラベル情報を付加するように構成されている。詳しくは後述する。

メモリ６は、ＣＡＮルーティングソフトウェア１００を格納している。実施の形態１の例においては、ＣＡＮルーティングソフトウェア１００は、ＡＵＴＯＳＡＲ規格に準拠するように、階層化されたソフトウェア構造を有している。なお、ＣＡＮルーティングソフトウェア１００は、ＡＵＴＯＳＡＲに準拠していることに限定されない。ＣＡＮルーティングソフトウェア１００は、ＣＡＮコントローラ１０から出力されたＣＡＮ通信データ（メッセージ情報）を他の車載機器に転送（中継）するためのルーティング処理を実行するソフトウェアである。ここで、ＣＡＮルーティングソフトウェア１００は、ラベル情報（付加情報）を用いて、メッセージ情報をルーティングするか否かを判定するためのフィルタ処理を行うフィルタ処理機能を実現する。詳しくは後述する。

図２は、実施の形態１にかかるＣＡＮルーティングソフトウェア１００を示す図である。ＣＡＮルーティングソフトウェア１００は、マイクロコントローラ抽象化層１０１と、ＥＣＵ抽象化層１０２と、サービス層１０３と、ＲＴＥ（Ｒｕｎｔｉｍｅ Ｅｎｖｉｒｏｎｍｅｎｔ；ランタイム環境）１０４と、アプリケーション層１０５とで構成されている。ここで、少なくともマイクロコントローラ抽象化層１０１と、ＥＣＵ抽象化層１０２と、サービス層１０３とによって、基本ソフトウェア１１０が構成されている。

アプリケーション層（Ａｐｐｌｉｃａｔｉｏｎ Ｌａｙｅｒ）１０５は、マイクロコントローラ２に依存しない処理を実行するアプリケーション１１５を有する。基本ソフトウェア（Ｂａｓｉｃ Ｓｏｆｔｗａｒｅ；ＢＳＷ）１１０は、アプリケーション１１５をマイクロコントローラ２に依存しないようにするための処理を行う。

マイクロコントローラ抽象化層（Ｍｉｃｒｏｃｏｎｔｒｏｌｌｅｒ Ａｂｓｔｒａｃｔｉｏｎ Ｌａｙｅｒ；ＭＣＡＬ）１０１は、マイクロコントローラ２の上位レイヤである。マイクロコントローラ抽象化層１０１は、マイクロコントローラ２を抽象化する。つまり、マイクロコントローラ抽象化層１０１は、マイクロコントローラ２に依存しているが、その上位レイヤをマイクロコントローラ２に依存させないようにする。マイクロコントローラ抽象化層１０１は、マイクロコントローラ２に内蔵された周辺機器又はメモリ６にマッピングされた外部デバイスへ直接アクセスするソフトウェアモジュールである。ここで、マイクロコントローラ抽象化層１０１は、ＣＡＮドライバ１１１を有する。ＣＡＮドライバ１１１は、ＣＡＮプロトコルを扱うコンポーネントである。

ＥＣＵ抽象化層（ＥＣＵ Ａｂｓｔｒａｃｔｉｏｎ Ｌａｙｅｒ）１０２は、マイクロコントローラ抽象化層１０１の上位レイヤである。ＥＣＵ抽象化層１０２は、半導体装置１のハードウェアコンポーネントを抽象化する。つまり、ＥＣＵ抽象化層１０２は、半導体装置１のハードウェアに依存しているが、その上位レイヤを半導体装置１のハードウェアに依存させないようにする。ＥＣＵ抽象化層１０２は、マイクロコントローラ抽象化層１０１とのインタフェースを実現する。ここで、ＥＣＵ抽象化層１０２は、ＣＡＮインタフェース１１２（ＣＡＮ ＩＦ）を有する。ＣＡＮインタフェース１１２は、ＣＡＮプロトコルを使用するためのインタフェースを上位レイヤに提供するネットワークインタフェースとなるコンポーネントである。つまり、ＣＡＮインタフェース１１２は、ＣＡＮを規定するプロトコルを使用可能とするためのコンポーネントである。ここで、実施の形態１においては、後述するように、ＣＡＮインタフェース１１２が、フィルタ処理を行う機能を有する。

サービス層（Ｓｅｒｖｉｃｅｓ Ｌａｙｅｒ）１０３は、ＥＣＵ抽象化層１０２の上位レイヤである。サービス層１０３は、オペレーティングシステム機能を含む。サービス層１０３は、アプリケーション１１５のための基本的なサービス及び基本ソフトウェアモジュールを提供する。ここで、サービス層１０３は、ＰＤＵルータ１１３（ＰＤＵＲ）及びコミュニケーション部１１４（ＣＯＭ部）を有する。ＰＤＵルータ１１３は、ＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）をルーティングする機能を有する。コミュニケーション部１１４は、他の車載機器とのデータ通信機能をＲＴＥ１０４へ提供する機能を有する。

ＲＴＥ（Ｒｕｎｔｉｍｅ Ｅｎｖｉｒｏｎｍｅｎｔ）１０４は、上述した各層からなる基本ソフトウェア１１０の上位レイヤである。ＲＴＥ１０４は、アプリケーション１１５を半導体装置１に依存させないようにする。ＲＴＥ１０４は、アプリケーション１１５のための通信を提供する。

図３は、実施の形態１にかかる半導体装置１の構成を示す機能ブロック図である。図３に示すように、半導体装置１は、マイクロコントローラ２と、ＣＡＮルーティングソフトウェア１００とから構成されている。なお、図３では、便宜上、マイクロコントローラ２とＣＡＮルーティングソフトウェア１００とが別個に示されている。しかしながら、実際には、上述したように、ＣＡＮルーティングソフトウェア１００は、マイクロコントローラ２に設けられたメモリ６に格納され、ＣＰＵ４によって実行される。

上述したように、ＣＡＮルーティングソフトウェア１００は、ＣＡＮドライバ１１１と、ＣＡＮインタフェース１１２と、ＰＤＵルータ１１３とを有する。ＣＡＮインタフェース１１２は、フィルタ処理部１２０を有する。フィルタ処理部１２０は、ＣＡＮコントローラ１０による機能を利用して、メッセージ情報をルーティングするためのフィルタ処理を行う。具体的には、フィルタ処理部１２０は、ＣＡＮコントローラ１０によって付加されたラベル情報（付加情報）を用いて、ＣＡＮコントローラ１０から出力されたメッセージ情報をルーティングするか否かを判定するためのフィルタ処理を行うフィルタ処理機能を実現する。つまり、実施の形態１においては、ＣＡＮインタフェース１１２に、フィルタ処理機能が実装されている。

フィルタ処理部１２０は、インタフェース部１２２と、解析部１３０とを有する。インタフェース部１２２は、ＣＡＮコントローラ１０によるハードウェアルーティング機能と、ＣＡＮルーティングソフトウェア１００とを連携する機能を有する。具体的には、インタフェース部１２２は、ＣＡＮコントローラ１０から受信したメッセージ情報から、ＣＡＮコントローラ１０によって付加されたラベル情報を抽出する。解析部１３０は、インタフェース部１２２から受け付けたメッセージ情報及びラベル情報を解析する。そして、解析部１３０は、メッセージ情報をルーティングするか否かを判定するためのフィルタ処理を行う。詳しくは後述する。

図４は、実施の形態１にかかる半導体装置１によって行われるルーティング処理の概要を示す図である。ＣＡＮコントローラ１０は、チャネルインタフェース８の複数のポート８ａ〜８ｈのうちのポート８ｃに接続されたＣＡＮバス４０を介して、メッセージ情報５０を受信する（ステップＳ１２）。なお、図４に示した例では、チャネルインタフェース８は、８個のポート８ａ〜８ｈを有しているとしたが、ポートの数は８個に限定されない。

ＣＡＮコントローラ１０は、予め定められた受信ルールに従って、メッセージ情報５０を、転送するか否かに応じて振り分ける。そして、ＣＡＮコントローラ１０は、メッセージ情報５０にラベル情報５２を付加する（ステップＳ１４）。なお、ＣＡＮコントローラ１０によって行われるフィルタ処理は、例えばメッセージ情報５０の識別子（ＩＤ）を用いたＩＤフィルタ処理である。

ＣＡＮコントローラ１０は、ラベル情報５２が付加されたメッセージ情報５０を、ＣＡＮルーティングソフトウェア１００のＣＡＮドライバ１１１に出力する（ステップＳ１６）。ＣＡＮドライバ１１１は、ＣＡＮコントローラ１０から受信したメッセージ情報５０を、ＣＡＮインタフェース１１２のインタフェース部１２２に出力する（ステップＳ１８）。インタフェース部１２２は、メッセージ情報５０から、ラベル情報５２を抽出する（ステップＳ２０）。解析部１３０は、ラベル情報５２及びメッセージ情報５０を解析して、フィルタ処理を行う（ステップＳ２２）。なお、解析部１３０によって行われるフィルタ処理は、例えば、メッセージ情報５０のペイロードを用いたペイロードフィルタ処理である。

解析部１３０は、フィルタ処理によって転送すると判定されたメッセージ情報５０を、ＰＤＵルータ１１３に出力する。ＰＤＵルータ１１３は、転送すると判定されたメッセージ情報５０に対してルーティング処理を行う（ステップＳ２４）。具体的には、ＰＤＵルータ１１３は、ＣＡＮインタフェース１１２、ＣＡＮドライバ１１１及びマイクロコントローラ２、及びポート８ｈを介して、メッセージ情報５０をＣＡＮバス４０に送信する。なお、ポート８ｈに接続されたＣＡＮバス４０は、ポート８ｃに接続されたＣＡＮバス４０とは異なっていてもよい。

通常、ＡＵＴＯＳＡＲに規定されていない機能を実装する場合、その機能は、アプリケーション層１０５にアプリケーション１１５として実装される。アプリケーション１１５を用いて処理を行う場合、図２の実線の矢印で示すように、処理対象のデータが、マイクロコントローラ２からアプリケーション層１０５の間の各レイヤを通過することとなる。したがって、ＡＵＴＯＳＡＲに規定されていない方法でルーティングのためのフィルタ処理を行う場合、アプリケーション１１５を用いることによって、処理時間が増大するおそれがある。

一方、実施の形態１においては、ＰＤＵルータ１１３よりも下位のコンポーネントであるＣＡＮインタフェース１１２において、ルーティングのためのフィルタ処理が行われる。したがって、図２の破線の矢印で示すように、ＰＤＵルータ１１３において、ルーティングを行うことが可能となる。したがって、アプリケーション１１５でルーティング（フィルタ処理）を行う場合と比較して、データが通過するレイヤが少ないので、高速でルーティングを行うことが可能となる。詳しくは後述する。

また、上述したように、ＡＵＴＯＳＡＲの規格では、ＰＤＵルータ１１３よりも上位のレイヤでは、ＣＡＮプロトコルに準拠したメッセージ情報を加工してしまう。したがって、この場合にアプリケーション１１５でルーティング（フィルタ処理）を行うと、マイクロコントローラ２のＣＡＮコントローラ１０によってメッセージ情報５０に付加されたラベル情報５２（付加情報）を用いることができない。

一方、実施の形態１では、ＰＤＵルータ１１３よりも下位のコンポーネントであるＣＡＮインタフェース１１２に、フィルタ処理部１２０が実装されている。したがって、フィルタ処理部１２０は、ＰＤＵルータ１１３よりも上位のレイヤで加工される前のメッセージ情報５０を扱うことができる。したがって、上述したように、フィルタ処理部１２０は、ラベル情報５２を用いてフィルタ処理を行うことができる。したがって、フィルタ処理部１２０は、アプリケーション１１５でルーティング（フィルタ処理）を行う場合と比較して、処理を簡略化することができるので、高速でルーティングを行うことが可能となる。詳しくは後述する。

また、実施の形態１にかかる半導体装置１は、ＣＡＮコントローラ１０によって振り分けられたメッセージ情報５０に対して、フィルタ処理を行う。したがって、ＣＡＮコントローラ１０によって行われるフィルタ処理についてはＣＡＮルーティングソフトウェア１００で行う必要がない。したがって、フィルタ処理を全てソフトウェアで行う場合と比較して、高速でルーティングを行うことが可能となる。詳しくは後述する。

また、実施の形態１にかかる半導体装置１は、本実施の形態にかかるＣＡＮルーティングソフトウェア１００によるフィルタ処理以外の処理を行う場合、図２の実線の矢印で示すように、アプリケーション１１５を用いてその処理を行うことができる。したがって、実施の形態１にかかる半導体装置１は、ＡＵＴＯＳＡＲの規格に準拠したまま、フィルタ処理の高速化を図ることが可能となる。

図５は、実施の形態１にかかる半導体装置１のフィルタ処理機能の詳細を示すブロック図である。半導体装置１は、ハードウェアであるマイクロコントローラ２と、ソフトウェアであるＣＡＮインタフェース１１２及びその上位レイヤ１１６（ＰＤＵルータ１１３等）とから構成される。また、ＣＡＮドライバ１１１は、ハードウェアとデータの送受信を行う。

ＣＡＮコントローラ１０は、メッセージ情報５０を受信すると、ＣＰＵ４に対して、受信割り込みを出力（発行）する。これにより、ＣＡＮルーティングソフトウェア１００が起動する。ＣＡＮコントローラ１０は、受信ルールテーブル１２と、識別子フィルタ処理部１４と、ラベル付加部１６と、送受信バッファ１８と、受信バッファ２０とを有する。受信ルールテーブル１２は、予め定められた受信ルールを示す。受信ルールテーブル１２については、図６を用いて後述する。

識別子フィルタ処理部１４は、受信ルールテーブル１２を用いて、メッセージ情報５０の識別子（ＩＤ）に対してフィルタ処理を行う。具体的には、識別子フィルタ処理部１４は、受信ルールテーブル１２を用いて、メッセージ情報５０の識別子（メッセージＩＤ）が適切であるか否かを判定する。ラベル付加部１６は、メッセージ情報５０にラベル情報５２（付加情報）を付加する。このとき、ラベル付加部１６は、受信ルールテーブル１２を用いて、ラベル情報５２をメッセージ情報５０に付加する。ラベル付加部１６は、受信ルールテーブル１２を用いることによって、容易にラベル情報５２を付加することができる。

送受信バッファ１８及び受信バッファ２０は、例えばＦＩＦＯ（Ｆｉｒｓｔ−Ｉｎ Ｆｉｒｓｔ Ｏｕｔ）バッファである。送受信バッファ１８（第１のバッファ）は、データの送受信が可能なバッファである。受信バッファ２０（第２のバッファ）は、データの受信のみが可能なバッファである。なお、送受信バッファ１８（第１のバッファ）は、少なくともデータの送信が可能なバッファであってもよい。

識別子フィルタ処理部１４は、受信ルールテーブル１２を用いて、メッセージ情報５０を振り分ける。具体的には、識別子フィルタ処理部１４は、受信ルールテーブル１２を用いて、メッセージ情報５０を、送受信バッファ１８又は受信バッファ２０に格納する。さらに具体的には、識別子フィルタ処理部１４は、適切なメッセージＩＤを有するメッセージ情報５０を、送受信バッファ１８に格納する。一方、識別子フィルタ処理部１４は、適切でないメッセージＩＤを有するメッセージ情報５０を、受信バッファ２０に格納する。

ＣＡＮインタフェース１１２（フィルタ処理部１２０）の解析部１３０は、ペイロードフィルタテーブル１３２と、ペイロードフィルタ処理部１３４と、エラーメッセージ送信部１３６と、メッセージ転送部１３８とを有する。ペイロードフィルタテーブル１３２は、ペイロードフィルタ処理部１３４によるペイロードフィルタ処理に使用される。ペイロードフィルタテーブル１３２については、図７を用いて後述する。その他の構成要素の機能については後述する。

図６は、実施の形態１にかかる受信ルールテーブル１２を例示する図である。受信ルールテーブル１２は、メッセージＩＤと、ＩＤマスクと、受信ルールラベル（ラベル情報５２）と、格納先バッファ情報とを対応付けている。受信ルールテーブル１２の各行を、受信ルール情報と称する。つまり、受信ルール情報は、あるメッセージＩＤに対応するＩＤマスク、受信ルールラベル及び格納先バッファ情報を含む。そして、受信ルールテーブル１２は、ＣＡＮのチャネル（ＣＡＮチャネル）ごとに、複数の受信ルール情報を含んでいる。識別子フィルタ処理部１４は、後述する方法により、受信ルールテーブル１２を使用する。

ここで、受信ルールテーブル１２の各項目の値の右下の「Ｈ」は、その値が１６進数であることを示している。また、図６の例において、メッセージＩＤ及びＩＤマスクは、１１ビットのデータである。したがって、「７ＦＦ_Ｈ」では、１１個のビット列の全てのビットが「１」である。さらに、メッセージ情報５０のＩＤも１１ビットのデータである。メッセージＩＤは、対応するメッセージ情報５０がどのような情報に関するものであるかを示す。例えば、「１００_Ｈ」は、車両の速度を示すメッセージ情報５０のＩＤであり、「２００_Ｈ」は、車両の燃料の残量を示すメッセージ情報５０のＩＤであってもよい。また、「３００_Ｈ」は、ブレーキが踏まれたことを示すメッセージ情報５０のＩＤであってもよい。なお、最終行の「０００_Ｈ」は、適切でないＩＤ（不正ＩＤ）を示す。

また、図６のＣＡＮチャネル＃１の例では、「１００_Ｈ」、「２００_Ｈ」及び「３００_Ｈ」以外の識別子は、後述するマスク処理によって、「０００_Ｈ」となる。図６のＣＡＮチャネル＃１の例において、例えばメッセージＩＤ「１００_Ｈ」は、ＩＤマスク「７ＦＦ_Ｈ」、受信ルールラベル「０１００_Ｈ」及び「送受信バッファ」と対応付けられている。また、図６のＣＡＮチャネル＃１の例において、メッセージＩＤ「０００_Ｈ」は、ＩＤマスク「０００_Ｈ」、受信ルールラベル「０１ＦＦ_Ｈ」及び「受信バッファ」と対応付けられている。

また、受信ルールラベルの上位８ビットは、対応するメッセージＩＤのメッセージ情報５０が受信されたＣＡＮチャネルを示している。つまり、受信ルールラベルの上位８ビットが「０１_Ｈ」である場合、対応するメッセージＩＤのメッセージ情報５０が、ＣＡＮチャネル＃１から受信されたことを示す。また、受信ルールラベルの上位８ビットが「０２_Ｈ」である場合、対応するメッセージＩＤのメッセージ情報５０が、ＣＡＮチャネル＃２から受信されたことを示す。

図７は、実施の形態１にかかるペイロードフィルタテーブル１３２を例示する図である。ペイロードフィルタテーブル１３２は、「開始オフセット」と、「サイズ」と、「期待値」と、「マスク」とを対応付けている。解析部１３０は、複数のペイロードフィルタテーブル１３２を格納している。好ましくは、解析部１３０は、複数のＣＡＮチャネルにそれぞれ対応する複数のペイロードフィルタテーブル１３２を格納している。各ペイロードフィルタテーブル１３２は、受信ルールラベルの少なくとも一部と対応付けられている。つまり、受信ルールラベルの上位８ビットがＣＡＮチャネルを示していることから、各ペイロードフィルタテーブル１３２は、受信ルールラベルの上位８ビットと対応付けられている。

ここで、ペイロードフィルタテーブル１３２の各行を、ペイロードフィルタ情報と称する。また、ペイロードフィルタ情報は、受信ルールラベルの少なくとも一部と対応付けられている。つまり、ペイロードフィルタ情報は、メッセージ情報５０に付加されたある受信ルールラベルの少なくとも一部に対応する、「開始オフセット」、「サイズ」、「期待値」及び「マスク」を含む。

例えば、ペイロードフィルタ情報１３２ａは、受信ルールラベルの下位８ビット「００_Ｈ」に対応する。また、ペイロードフィルタ情報１３２ｂは、受信ルールラベルの下位８ビット「０１_Ｈ」に対応する。ペイロードフィルタ処理部１３４は、後述する方法により、ペイロードフィルタテーブル１３２を使用する。

図８及び図９は、実施の形態１にかかる半導体装置１によって行われる情報処理方法を示すフローチャートである。言い換えると、図８及び図９は、メッセージ情報５０をルーティングするためのフィルタ処理方法（転送処理方法）を示す。まず、ＣＡＮコントローラ１０は、メッセージ情報５０を受信する（ステップＳ１０２）。

次に、ＣＡＮコントローラ１０の識別子フィルタ処理部１４は、受信したメッセージ情報５０に対して、ハードウェアを用いたＩＤフィルタ処理を行う（ステップＳ１０４）。具体的には、識別子フィルタ処理部１４は、受信ルールテーブル１２を用いて、メッセージ情報５０の識別子に対してフィルタ処理を行う。そして、識別子フィルタ処理部１４は、受信されたメッセージ情報５０の識別子が受信ルールに合致するか否かを判定する（ステップＳ１０６）。言い換えると、識別子フィルタ処理部１４は、受信されたメッセージ情報５０が、受信ルールテーブル１２の最終行（メッセージＩＤ「０００_Ｈ」）に対応しないか否かを判定する。

識別子が受信ルールに合致する場合（Ｓ１０６のＹＥＳ）、ＣＡＮコントローラ１０は、受信されたメッセージ情報５０の識別子が適切なものであると判定する。このとき、ＣＡＮコントローラ１０のラベル付加部１６は、受信ルールテーブル１２において対応する受信ルールラベル（ラベル情報５２）をメッセージ情報５０に付加する（ステップＳ１０８）。そして、ＣＡＮコントローラ１０は、受信ルールラベルが付加されたメッセージ情報５０を、送受信バッファ１８に格納する（ステップＳ１１０）。ＣＡＮコントローラ１０は、メッセージ情報５０を送受信バッファ１８に格納すると、ＣＰＵ４に対して、メッセージ情報５０の受信完了を通知する受信割り込みを出力する（ステップＳ１１１）。

一方、識別子が受信ルールに合致しない場合（Ｓ１０６のＮＯ）、ＣＡＮコントローラ１０は、受信されたメッセージ情報５０のＩＤが不適切なものであると判定する。このとき、ラベル付加部１６は、受信ルールテーブル１２において対応する受信ルールラベル（ラベル情報５２）をメッセージ情報５０に付加する（ステップＳ１１２）。そして、ＣＡＮコントローラ１０は、受信ルールラベルが付加されたメッセージ情報５０を、受信バッファ２０に格納する（ステップＳ１１４）。このようにして、ＣＡＮコントローラ１０は、適切なＩＤのメッセージ情報５０を送受信バッファ１８に振り分け、不適切なＩＤのメッセージ情報５０を受信バッファ２０に振り分ける。ＣＡＮコントローラ１０は、メッセージ情報５０を受信バッファ２０に格納すると、ＣＰＵ４に対して、メッセージ情報５０の受信完了を通知する受信割り込みを出力する（ステップＳ１１５）。

以下、図６に示した例において、ＣＡＮチャネル＃１からメッセージ情報５０が受信された場合について説明する。識別子「１００_Ｈ」のメッセージ情報５０が受信された場合、識別子フィルタ処理部１４は、受信ルールテーブル１２から、ＩＤマスク「７ＦＦ_Ｈ」を抽出する。そして、識別子フィルタ処理部１４は、ＩＤマスク「７ＦＦ_Ｈ」を用いて識別子「１００_Ｈ」に対してマスク処理を行う。ここで、本実施の形態において、「マスク処理」は、マスク対象のビット列において、ＩＤマスクの「０」のビット位置に対応する位置のビットを「０」にし、ＩＤマスクの「１」のビット位置に対応する位置のビットを元のままとする処理である。

したがって、ＩＤマスク「７ＦＦ_Ｈ」を用いて識別子「１００_Ｈ」に対してマスク処理を行った結果は「１００_Ｈ」となる。したがって、識別子フィルタ処理部１４は、ＩＤマスク「７ＦＦ_Ｈ」を用いてマスク処理が施された識別子「１００_Ｈ」が受信ルールテーブル１２において定義されたメッセージＩＤ「１００_Ｈ」と一致すると判定する。したがって、Ｓ１０６の処理において、識別子フィルタ処理部１４は、受信されたメッセージ情報５０のＩＤが、受信ルールに合致すると判定する。この場合、Ｓ１０８の処理において、ラベル付加部１６は、受信ルールテーブル１２においてメッセージＩＤ「１００_Ｈ」に対応する受信ルールラベル「０１００_Ｈ」を、メッセージ情報５０に付加する。そして、Ｓ１１０の処理において、ＣＡＮコントローラ１０は、この受信ルールラベル「０１００_Ｈ」が付加されたメッセージ情報５０を、送受信バッファ１８に格納する。

識別子「２００_Ｈ」又は「３００_Ｈ」のメッセージ情報５０が受信された場合についても同様に、識別子フィルタ処理部１４は、ＩＤマスク「７ＦＦ_Ｈ」を用いて識別子「２００_Ｈ」又は「３００_Ｈ」に対してマスク処理を行う。このとき、マスク処理された結果は、「２００_Ｈ」又は「３００_Ｈ」となる。したがって、識別子フィルタ処理部１４は、ＩＤマスク「７ＦＦ_Ｈ」を用いてマスク処理が施された識別子が受信ルールテーブル１２において定義されたメッセージＩＤと一致すると判定する。したがって、Ｓ１０６の処理において、識別子フィルタ処理部１４は、受信されたメッセージ情報５０のＩＤが、受信ルールに合致すると判定する。この場合、Ｓ１０８の処理において、ラベル付加部１６は、識別子「２００_Ｈ」のメッセージ情報５０に受信ルールラベル「０１０１_Ｈ」を付加する。また、ラベル付加部１６は、識別子「３００_Ｈ」のメッセージ情報５０に受信ルールラベル「０１ＦＦ_Ｈ」を付加する。そして、Ｓ１１０の処理において、ＣＡＮコントローラ１０は、受信ルールラベルが付加されたメッセージ情報５０を、送受信バッファ１８に格納する。

一方、「１００_Ｈ」、「２００_Ｈ」及び「３００_Ｈ」以外の識別子（例えば「１１０_Ｈ」）を有するメッセージ情報５０が受信された場合、識別子フィルタ処理部１４は、受信ルールテーブル１２から、ＩＤマスク「０００_Ｈ」を抽出する。受信ルールテーブル１２で定義されたメッセージＩＤは、受信ルールテーブル１２における先頭から順に処理される。したがって、受信されたメッセージ情報５０のＩＤが「１００_Ｈ」、「２００_Ｈ」及び「３００_Ｈ」のいずれにも一致しなかった場合、末尾の受信ルールに必ず一致する。

そして、識別子フィルタ処理部１４は、ＩＤマスク「０００_Ｈ」を用いて、受信されたメッセージ情報５０の識別子に対してマスク処理を行う。このとき、マスク処理された結果は「０００_Ｈ」となる。したがって、識別子フィルタ処理部１４は、ＩＤマスク「０００_Ｈ」を用いてマスク処理が施された識別子が受信ルールテーブル１２において定義されたメッセージＩＤ「０００_Ｈ」と一致すると判定する。したがって、Ｓ１０６の処理において、識別子フィルタ処理部１４は、受信されたメッセージ情報５０のＩＤが、受信ルールに合致しないと判定する。この場合、Ｓ１１２の処理において、ラベル付加部１６は、受信ルールテーブル１２においてメッセージＩＤ「０００_Ｈ」に対応する受信ルールラベル「０１ＦＦ_Ｈ」を、メッセージ情報５０に付加する。そして、Ｓ１１４の処理において、ＣＡＮコントローラ１０は、この受信ルールラベル「０１ＦＦ_Ｈ」が付加されたメッセージ情報５０を、受信バッファ２０に格納する。

このように、実施の形態１にかかるＣＡＮコントローラ１０は、予め格納された受信ルールテーブル１２を用いて、メッセージ情報５０の振り分けを行っている。したがって、高速に、ＩＤフィルタ処理を行うことが可能となる。さらに、実施の形態１にかかるＣＡＮコントローラ１０は、受信ルールテーブル１２を用いて、受信ルールラベルをメッセージ情報５０に付加している。したがって、容易に受信ルールラベルを付加することが可能となる。

送受信バッファ１８へメッセージ情報５０が格納されたことにより受信割り込みが発生した場合、ＣＡＮルーティングソフトウェア１００は、送受信バッファ１８から、メッセージ情報５０を取得する（ステップＳ１２２）。具体的には、インタフェース部１２２は、ＣＡＮドライバ１１１を介して、送受信バッファ１８からメッセージ情報５０を取得する。そして、インタフェース部１２２は、メッセージ情報５０に付加された受信ルールラベルを抽出する（ステップＳ１２４）。インタフェース部１２２は、抽出された受信ルールラベルとメッセージ情報５０とを、解析部１３０に出力する。

解析部１３０は、受信ルールラベルを用いて、ソフトウェアによるフィルタ処理を行う（Ｓ１２６〜Ｓ１３４）。解析部１３０のペイロードフィルタ処理部１３４は、受信ルールラベルの少なくとも一部が予め定められたデータと一致するか否かを判定する（ステップＳ１２８）。具体的には、ペイロードフィルタ処理部１３４は、受信ルールラベルの下位８ビットが「ＦＦ_Ｈ」に一致するか否かを判定する。

受信ルールラベルの下位８ビットが「ＦＦ_Ｈ」に一致しない場合（Ｓ１２６のＮＯ）、ペイロードフィルタ処理部１３４は、受信ルールラベルの少なくとも一部である上位８ビットに対応するペイロードフィルタテーブル１３２を取得する（ステップＳ１２８）。さらに、ペイロードフィルタ処理部１３４は、Ｓ１２８の処理で取得されたペイロードフィルタテーブル１３２から、受信ルールラベルの少なくとも一部である下位８ビットに対応するペイロードフィルタ情報を取得する（ステップＳ１３０）。

ペイロードフィルタ処理部１３４は、Ｓ１３０の処理で取得されたペイロードフィルタ情報を用いてペイロードフィルタ処理を行う（ステップＳ１３２）。そして、ペイロードフィルタ処理部１３４は、ペイロードに問題がないか否かを判定する（ステップＳ１３４）。具体的には、ペイロードフィルタ処理部１３４は、ペイロードの開始位置から「開始オフセット」で示されるデータ数だけオフセットされた位置から「サイズ」で示されるデータ数のデータ列を、「マスク」で示されるデータでマスク処理する。そして、ペイロードフィルタ処理部１３４は、マスク処理されたデータ値が「期待値」となる場合に、ペイロードに問題がないと判定する。なお、ペイロードのうち、期待値と比較する箇所のデータは、ペイロードの正当性を判定する指標となる箇所である。

ペイロードに問題がない、つまりメッセージ情報５０が正常である場合（Ｓ１３４のＹＥＳ）、メッセージ転送部１３８は、上位レイヤ１１６にメッセージ情報５０を出力する。これにより、上位レイヤ１１６（ＰＤＵルータ１１３）によって、転送処理が行われる（ステップＳ１３６）。一方、ペイロードに問題がある、つまりメッセージ情報５０に異常がある場合（Ｓ１３４のＮＯ）、エラーメッセージ送信部１３６は、エラーメッセージを送信する（ステップＳ１３８）。

例えば、図６及び図７の例において、ＣＡＮチャネル＃１においてＩＤ「１００_Ｈ」を有するメッセージ情報５０が受信されたとする。この場合、このメッセージ情報５０に、受信ルールラベル「０１００_Ｈ」が付加される。このとき、Ｓ１２８の処理において、ペイロードフィルタ処理部１３４は、受信ルールラベル「０１００_Ｈ」の上位８ビット「０１_Ｈ」に対応するペイロードフィルタテーブル１３２（例えば図７のＣＡＮチャネル＃１のテーブル）を取得する。また、Ｓ１３０の処理において、ペイロードフィルタ処理部１３４は、受信ルールラベル「０１００_Ｈ」の下位８ビット「００_Ｈ」に対応するペイロードフィルタ情報１３２ａを取得する。ペイロードフィルタ情報１３２ａにおいて、「開始オフセット」は２バイトであり、「サイズ」は３バイトである。また、「期待値」は「ＥＥ００２２」であり、「マスク」は「ＦＦ００ＦＦ」である。

また、上記の場合において、メッセージ情報５０のペイロードが「００１１ＥＥ３３２２５５６６７７」であるとする。このとき、Ｓ１３２の処理において、ペイロードフィルタ処理部１３４は、ペイロードの開始位置から開始オフセット「２バイト」だけオフセットした位置から３バイト分のデータ「ＥＥ３３２２」を、「ＦＦ００ＦＦ」でマスク処理する。このとき、「ＥＥ３３２２」を「ＦＦ００ＦＦ」でマスク処理した結果は、「ＥＥ００２２」となり、期待値と一致する。したがって、Ｓ１３４において、ペイロードフィルタ処理部１３４は、ペイロードが正常であると判定する。この場合、Ｓ１３６の処理において、メッセージ転送部１３８（ＰＤＵルータ１１３）は、メッセージ情報５０の転送処理を行う。

また、メッセージ情報５０のペイロードが「００１１ＥＤ３３２２５５６６７７」であるとする。このとき、Ｓ１３２の処理において、ペイロードフィルタ処理部１３４は、ペイロードの開始位置から開始オフセット「２バイト」だけオフセットした位置から３バイト分のデータ「ＥＤ３３２２」を、「ＦＦ００ＦＦ」でマスク処理する。このとき、「ＥＤ３３２２」を「ＦＦ００ＦＦ」でマスク処理した結果は、「ＥＤ００２２」となり、期待値と一致しない。したがって、Ｓ１３４において、ペイロードフィルタ処理部１３４は、ペイロードが正常でないと判定する。この場合、Ｓ１３８の処理において、エラーメッセージ送信部１３６は、エラーメッセージを作成して、他のＥＣＵ等に送信する。

一方、受信ルールラベルの少なくとも一部が予め定められたデータと一致する場合、つまり受信ルールラベルの下位８ビットが「ＦＦ_Ｈ」に一致する場合（Ｓ１２６のＮＯ）、メッセージ転送部１３８は、上位レイヤ１１６にメッセージ情報５０を出力する。これにより、上位レイヤ１１６（ＰＤＵルータ１１３）によって、転送処理が行われる（ステップＳ１４０）。つまり、この場合、ペイロードフィルタテーブル１３２を用いたペイロードフィルタ処理は、行われない。

例えば、図６の例において、ＣＡＮチャネル＃１においてＩＤ「３００_Ｈ」を有するメッセージ情報５０が受信されたとする。この場合、このメッセージ情報５０に、受信ルールラベル「０１ＦＦ_Ｈ」が付加される。このとき、Ｓ１２６の処理において、ペイロードフィルタ処理部１３４は、受信ルールラベルの下位８ビットが「ＦＦ_Ｈ」であるので、ペイロードフィルタテーブル１３２を用いたフィルタ処理（Ｓ１３２）を行わない。そして、メッセージ転送部１３８（ＰＤＵルータ１１３）によって、転送処理が行われる（Ｓ１４０）。なお、ペイロードフィルタテーブル１３２を用いたフィルタ処理を行わなくてよい理由は、ペイロードの中身をチェックする必要のないメッセージ情報５０のＩＤに、下位８ビットが「ＦＦ_Ｈ」である受信ルールラベルを付加するようにしたからである。例えば「ブレーキが踏まれた」といったイベントは、そのイベントが発生したことが示されればよく、ペイロードの中身については、車両の制御において問われない。

上述したように、実施の形態１にかかる解析部１３０は、受信ルールラベルの上位８ビットをインデックスとしてペイロードフィルタテーブル１３２を取得する（Ｓ１２８）。さらに、実施の形態１にかかる解析部１３０は、受信ルールラベルの下位８ビットをインデックスとしてペイロードフィルタ情報を取得する（Ｓ１３０）。これにより、受信ルールラベルを用いない場合と比較して、ペイロードフィルタ情報の検索処理に要する時間を大幅に削減することができる。したがって、実施の形態１においては、処理時間の増大を抑制しつつ、フィルタ処理を行うことが可能となる。

また、上述したように、実施の形態１にかかるＣＡＮルーティングソフトウェア１００は、受信ルールラベルの下位８ビットが「ＦＦ_Ｈ」に一致する場合、ペイロードフィルタテーブル１３２を用いたペイロードフィルタ処理を行わないで、メッセージ情報５０の転送処理を行う。これにより、処理時間を削減することが可能となる。

一方、受信バッファ２０へメッセージ情報５０が格納されたことにより受信割り込みが発生した場合、ＣＡＮルーティングソフトウェア１００は、受信バッファ２０から、メッセージ情報５０を取得する（ステップＳ１５２）。この場合、解析部１３０のエラーメッセージ送信部１３６は、直ちに、エラーメッセージを作成して、他のＥＣＵに送信するための処理を行う（ステップＳ１５４）。

このように、不正なメッセージ情報５０を受信バッファ２０に格納することによって、ＣＡＮルーティングソフトウェア１００は、直ちに、そのメッセージ情報５０をエラーであると判定することができる。したがって、ＣＡＮルーティングソフトウェア１００において、不正なＩＤを有するメッセージ情報５０の判定を行うことが不要となる。したがって、ＣＰＵ４のリソースを消費することが抑制されるので、高速でフィルタ処理を行うことが可能となる。また、ＣＡＮルーティングソフトウェア１００は、送受信バッファ１８に格納されたメッセージ情報５０に対してのみ、フィルタ処理を行うように構成されているので、処理が簡略化される。

（比較例）
次に、実施の形態１に対する比較例について説明する。
図１０は、第１の比較例について説明するための図である。図１０に示すように、第１の比較例では、アプリケーション層１０５のアプリケーション１１５に、フィルタ処理部１９０が設けられている。フィルタ処理部１９０は、メッセージ情報５０に対して、上述したようなフィルタ処理を行い得る。この場合、上述したように、メッセージ情報５０が、ＣＡＮドライバ１１１、ＣＡＮインタフェース１１２、ＰＤＵルータ１１３、コミュニケーション部１１４、及びＲＴＥ１０４を通過する。したがって、第１の比較例にかかるフィルタ処理では、実施の形態１と比較して、メッセージ情報５０が通過するレイヤ（コンポーネント）の数が多い。したがって、比較例にかかるフィルタ処理に要する処理時間は、実施の形態１と比較して増大する可能性がある。

一方、実施の形態１においては、ＰＤＵルータ１１３よりも下位のコンポーネントであるＣＡＮインタフェース１１２において、ルーティングのためのフィルタ処理が行われる。したがって、第１の比較例のアプリケーション１１５のフィルタ処理部１９０でルーティング（フィルタ処理）を行う場合と比較して、データが通過するレイヤが少ない。したがって、実施の形態１においては、高速でルーティングを行うことが可能となる。

また、上述したように、第１の比較例では、ＰＤＵルータ１１３よりも上位のレイヤで、マイクロコントローラ２で付加された付加情報（受信ルールラベル）が削除されてしまう。したがって、フィルタ処理部１９０は、受信ルールラベルを用いたフィルタ処理を行うことができない。

一方、実施の形態１では、上述したように、ＰＤＵルータ１１３よりも下位のコンポーネントであるＣＡＮインタフェース１１２に、フィルタ処理部１２０が実装されている。したがって、フィルタ処理部１２０は、ラベル情報５２（受信ルールラベルを）を用いてフィルタ処理を行うことができる。したがって、実施の形態１にかかるフィルタ処理部１２０は、アプリケーション１１５のフィルタ処理部１９０でルーティング（フィルタ処理）を行う場合と比較して、処理を簡略化することができる。したがって、実施の形態１にかかる方法では、高速でルーティングを行うことが可能となる。

図１１は、第２の比較例について説明するための図である。図１１は、第２の比較例にかかる情報処理方法（転送処理方法）を示すフローチャートを示している。第２の比較例は、メッセージ情報５０のＩＤによるフィルタ処理及びペイロードフィルタ処理等の全ての処理を、ＣＡＮコントローラ１０を用いないで、ソフトウェアのみで実行する場合の例である。

マイクロコントローラ２がメッセージ情報５０を受信すると（ステップＳ２０２）、ＣＡＮコントローラ１０は、ＣＰＵ４に受信割り込みを出力する。このとき、ＣＡＮルーティングソフトウェア１００は、ソフトウェアによるＩＤフィルタ処理を行う（ステップＳ２０４）。この場合、ＣＡＮルーティングソフトウェア１００は、どのメッセージＩＤが適切でどのメッセージＩＤが不適切であるかを示すテーブルを記憶している。したがって、ＣＡＮルーティングソフトウェア１００は、このテーブルを検索することにより、メッセージ情報５０のＩＤが受信ルールに合致するか否かを判定する（ステップＳ２０６）。ＩＤが受信ルールに合致しない場合（Ｓ２０６のＮＯ）、ＣＡＮルーティングソフトウェア１００は、エラーメッセージを送信する（ステップＳ２０８）。

一方、ＩＤが受信ルールに合致する場合（Ｓ２０６のＹＥＳ）、ＣＡＮルーティングソフトウェア１００は、ペイロードフィルタ処理を行う。ここで、ＣＡＮルーティングソフトウェア１００は、図７に相当するペイロードフィルタテーブルを記憶している。ここで、第２の比較例においては、受信ルールラベルがメッセージ情報５０に付加されていない。したがって、ＣＡＮルーティングソフトウェア１００は、図９のＳ１２８に対応する処理として、メッセージ情報５０のＩＤに対応するペイロードフィルタテーブルを検索する（ステップＳ２１０）。

ペイロードフィルタテーブルが存在しない場合（ステップＳ２１２のＮＯ）、ＣＡＮルーティングソフトウェア１００は、エラーメッセージを送信する（Ｓ２０８）。一方、ペイロードフィルタテーブルが存在する場合（Ｓ２１２のＹＥＳ）、ＣＡＮルーティングソフトウェア１００は、図９のＳ１２６に対応する処理として、ペイロードフィルタテーブルを用いたフィルタ処理が必要か否かを判定する（ステップＳ２１４）。ペイロードフィルタテーブルを用いたフィルタ処理が必要でない場合（Ｓ２１４のＮＯ）、ＣＡＮルーティングソフトウェア１００は、Ｓ１４０の処理と同様に、メッセージ情報５０の転送処理を行う（ステップＳ２３０）。

一方、ペイロードフィルタテーブルを用いたフィルタ処理が必要である場合（Ｓ２１４のＹＥＳ）、ＣＡＮルーティングソフトウェア１００は、Ｓ１３０の処理に対応する処理として、ペイロードフィルタテーブルからペイロードフィルタ情報を検索する（ステップＳ２１６）。そして、ＣＡＮルーティングソフトウェア１００は、検索されたペイロードフィルタ情報を用いて、Ｓ１３２の処理と同様にして、ペイロードフィルタ処理を行う（ステップＳ２１８）。ペイロードに問題がない場合（ステップＳ２２０のＹＥＳ）、ＣＡＮルーティングソフトウェア１００は、メッセージ情報５０の転送処理を行う（ステップＳ２２２）。一方、ペイロードに問題がある場合（Ｓ２２０のＮＯ）、ＣＡＮルーティングソフトウェア１００は、エラーメッセージを送信する（ステップＳ２２４）。

ここで、第２の比較例においては、Ｓ２１０、Ｓ２１４及びＳ２１６の処理で、検索処理を行う必要がある。検索処理は、検索するデータの数が多くなればなるほど、処理負荷及び処理速度ともに大きくなる傾向がある。したがって、車載ネットワークが複雑になって検索するデータの数が増大すると、第２の比較例にかかる検索処理に膨大な時間を要することとなる。

一方、上述した実施の形態１においては、ハードウェアであるＣＡＮコントローラ１０が、受信ルールラベルをメッセージ情報５０に付加するように構成されている。したがって、この受信ルールラベルをインデックスとして、即座に、ペイロードフィルタ情報を取得することが可能となる。つまり、実施の形態１においては、Ｓ２１０、Ｓ２１４及びＳ２１６のような検索処理を行うことが不要となる。したがって、実施の形態１においては、処理時間の増大を抑制しつつフィルタ処理を行うことが可能となる。特に、車載ネットワークが複雑化するほど、実施の形態１にかかる効果が大きくなり得る。

（実施の形態２）
次に、実施の形態２について説明する。実施の形態２においては、半導体装置１（ＥＣＵ）がＣＡＮ以外の車載ネットワークに接続されている点で、実施の形態１と異なる。実施の形態２のこれ以外の構成については、実施の形態１と実質的に同様である。

図１２は、実施の形態２にかかる半導体装置１の構成を示す図である。図１２に例示した半導体装置１は、ＣＡＮの他に、ＬＩＮ（Ｌｏｃａｌ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｎｅｔｗｏｒｋ）及びイーサネット（Ｅｔｈｅｒｎｅｔ）（登録商標）に接続されている。実施の形態２にかかる半導体装置１は、マイクロコントローラ２及びルーティングソフトウェア２００を有する。マイクロコントローラ２は、ＣＡＮコントローラ１０の他に、ＬＩＮコントローラ２０２及びイーサネットコントローラ２０４を有する。

ＬＩＮコントローラ２０２は、ＬＩＮに接続されている。ＬＩＮコントローラ２０２は、ＬＩＮに関する動作について、ＣＡＮコントローラ１０と実質的に同様の機能を有する。イーサネットコントローラ２０４は、イーサネットに接続されている。イーサネットコントローラ２０４は、イーサネットに関する動作について、ＣＡＮコントローラ１０と実質的に同様の機能を有する。

実施の形態２にかかるルーティングソフトウェア２００は、ＣＡＮルーティングソフトウェア１００と同様に、ＣＡＮドライバ１１１、ＣＡＮインタフェース１１２、及びＰＤＵルータ１１３を有する、実施の形態２にかかるルーティングソフトウェア２００は、さらに、ＬＩＮドライバ２１１、ＬＩＮインタフェース２１２（ＬＩＮ ＩＦ）、イーサネットドライバ２２１、及びイーサネットインタフェース２２２（イーサネットＩＦ）を有する。ＰＤＵルータ１１３は、ＣＡＮインタフェース１１２、ＬＩＮインタフェース２１２及びイーサネットインタフェース２２２の処理により、メッセージ情報５０の中身だけの情報を扱い得る。つまり、ＣＡＮインタフェース１１２、ＬＩＮインタフェース２１２及びイーサネットインタフェース２２２は、それぞれ、ＣＡＮ、ＬＩＮ及びイーサネットのプロトコルに準拠したメッセージ情報を扱うが、ＰＤＵルータ１１３は、これらのプロトコルよらないデータを扱い得る。

ＬＩＮドライバ２１１及びイーサネットドライバ２２１は、それぞれ、ＬＩＮ及びイーサネットに関する動作について、ＣＡＮドライバ１１１と実質的に同様の機能を有する。ＬＩＮインタフェース２１２及びイーサネットインタフェース２２２は、それぞれ、ＬＩＮ及びイーサネットに関する動作について、ＣＡＮインタフェース１１２と実質的に同様の機能を有する。

また、ＣＡＮインタフェース１１２は、実施の形態１にかかるフィルタ処理部１２０と実質的に同様の構成を有する、ＣＡＮフィルタ処理部２０６を有する。ＬＩＮインタフェース２１２は、ＬＩＮフィルタ処理部２１６を有する。イーサネットインタフェース２２２は、イーサネットフィルタ処理部２２６を有する。ＬＩＮフィルタ処理部２１６は、ＣＡＮフィルタ処理部２０６（フィルタ処理部１２０）と同様にインタフェース部及び解析部を有し、ＬＩＮに関する処理について、ＣＡＮフィルタ処理部２０６と実質的に同様の処理を行う。これと同じように、イーサネットフィルタ処理部２２６は、ＣＡＮフィルタ処理部２０６（フィルタ処理部１２０）と同様にインタフェース部及び解析部を有し、イーサネットに関する処理について、ＣＡＮフィルタ処理部２０６と実質的に同様の処理を行う。

ＬＩＮコントローラ２０２及びイーサネットコントローラ２０４は、ＣＡＮコントローラ１０と同様に、ハードウェアルーティング機能を実現する。つまり、ＬＩＮコントローラ２０２及びイーサネットコントローラ２０４は、受信ルールテーブルを用いて、メッセージ情報５０の振り分けを行う。さらに、ＬＩＮコントローラ２０２及びイーサネットコントローラ２０４は、メッセージ情報５０に受信ルールラベルを付加する。

ＬＩＮフィルタ処理部２１６及びイーサネットフィルタ処理部２２６は、ＣＡＮフィルタ処理部２０６（フィルタ処理部１２０）と同様に、ソフトウェアによるフィルタ処理を行う。具体的には、ＬＩＮフィルタ処理部２１６は、ＬＩＮドライバ２１１を介して受信ルールラベルが付加されたメッセージ情報５０を受け付ける。また、ＬＩＮフィルタ処理部２１６のインタフェース部が、受信ルールラベルを抽出する。そして、ＬＩＮフィルタ処理部２１６の解析部が、ペイロードフィルタテーブル及び受信ルールラベルを用いて、フィルタ処理を行う。これにより、ＬＩＮからのメッセージ情報５０を転送するか否かが決定される。イーサネットフィルタ処理部２２６についても同様の処理を行い、イーサネットからのメッセージ情報５０を転送するか否かが決定される。このようにして、実施の形態２にかかる半導体装置１は、ＣＡＮだけでなく、ＬＩＮ及びイーサネットについても、上述した実施の形態１とほぼ同様の効果を実現可能である。

また、実施の形態２にかかる半導体装置１は、ＣＡＮからＬＩＮ、ＬＩＮからイーサネットといったように、異なるネットワーク間を跨ぐルーティングを行うことも可能である。ＣＡＮからＬＩＮにルーティングが行われるとき、ＣＡＮコントローラ１０及びＣＡＮフィルタ処理部２０６が、上述したフィルタ処理を行う。また、ＬＩＮからＣＡＮにルーティングが行われるとき、ＬＩＮコントローラ２０２及びＬＩＮフィルタ処理部２１６が、上述したフィルタ処理を行う。

なお、各ネットワークについて、転送できるメッセージ長の最大値が規定されていることがある。したがって、転送先のネットワークで転送可能なメッセージの最大長が、転送元のネットワークで転送可能なメッセージの最大長よりも小さい場合、転送元のネットワークに関するフィルタ処理部が、転送先のネットワークにおけるメッセージの最大長に合わせて、メッセージを分割して送信し得る。例えば、イーサネットでは、最大値が１０００バイトであるのに対し、ＣＡＮでは、最大値が６４バイトと規定され得る。この場合、イーサネットからＣＡＮにメッセージ情報が転送される場合、イーサネットフィルタ処理部２２６は、データ長が最大６４バイトとなるように、メッセージを分割する。

上述したように、実施の形態２にかかる半導体装置１は、ＣＡＮだけでなく、ＬＩＮ及びイーサネットについても、上述した実施の形態１とほぼ同様の効果を実現可能である。さらに、実施の形態２にかかる半導体装置１は、異なるネットワーク間でメッセージ情報を転送する場合であっても、実施の形態１と同様に、アプリケーション層１０５でフィルタ処理を行う必要がない。したがって、実施の形態２において、異なるネットワーク間でメッセージ情報を転送する場合であっても、高速でルーティングを行うことが可能となる。言い換えると、異なるネットワーク間でメッセージ情報を転送する場合であっても、処理時間の増大を抑制しつつフィルタ処理を行うことが可能となる。

（変形例）
なお、本実施の形態は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。例えば、上述した実施の形態にかかるフローチャートにおいて、各処理の順序は、適宜、変更可能である。例えば、図９において、Ｓ１２６の処理は、Ｓ１２８の処理の後で行われてもよいし、Ｓ１３０の処理の後で行われてもよい。

また、上述した実施の形態で説明された構成要素が行う処理の一部を、別の構成要素が行ってもよい。例えば、図９のＳ１２８の処理は、解析部１３０ではなくインタフェース部１２２によって行われてもよい。また、エラーメッセージ送信部１３６及びメッセージ転送部１３８の処理は、ペイロードフィルタ処理部１３４によって行われてもよい。

さらに、図８に示した処理が、ＣＡＮコントローラ１０ではなくＣＡＮルーティングソフトウェア１００によって行われてもよい。しかしながら、図１１を用いて上述したように、図８に示した処理がハードウェアであるＣＡＮコントローラ１０によって行われることによって、処理時間の増大をより抑制してフィルタ処理を行うことが可能となる。

また、上述したプログラムは、様々なタイプの非一時的なコンピュータ可読媒体を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ ＰＲＯＭ）、フラッシュＲＯＭ、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
（付記１）
車載ネットワークから受信されたメッセージ情報に付加された付加情報を抽出するステップと、
前記付加情報を用いて、前記メッセージ情報をルーティングするか否かを判定するためのフィルタ処理を行うステップと
をコンピュータに実行させるプログラム。
（付記２）
前記フィルタ処理を行うステップは、前記付加情報を用いて取得されたペイロードフィルタ情報を用いて、前記メッセージ情報のペイロードに対してフィルタ処理を行う
付記１に記載のプログラム。
（付記３）
前記フィルタ処理を行うステップは、前記付加情報の少なくとも一部と対応付けられたペイロードフィルタテーブルを用いて、前記ペイロードに対してフィルタ処理を行う
付記２に記載のプログラム。
（付記４）
前記フィルタ処理を行うステップは、前記ペイロードフィルタテーブルのうち、前記付加情報の少なくとも一部と対応付けられたペイロードフィルタ情報を用いて、前記ペイロードに対してフィルタ処理を行う
付記３に記載のプログラム。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は既に述べた実施の形態に限定されるものではなく、その要旨を逸脱しない範囲において種々の変更が可能であることはいうまでもない。

１ 半導体装置
２ マイクロコントローラ
４ ＣＰＵ
６ メモリ
１０ ＣＡＮコントローラ
１２ 受信ルールテーブル
１４ 識別子フィルタ処理部
１６ ラベル付加部
１８ 送受信バッファ
２０ 受信バッファ
５０ メッセージ情報
５２ ラベル情報
１００ ＣＡＮルーティングソフトウェア
１０１ マイクロコントローラ抽象化層
１０２ ＥＣＵ抽象化層
１０３ サービス層
１０４ ＲＴＥ
１０５ アプリケーション層
１１０ 基本ソフトウェア
１１１ ＣＡＮドライバ
１１２ ＣＡＮインタフェース
１１３ ＰＤＵルータ
１２０ フィルタ処理部
１２２ インタフェース部
１３０ 解析部
１３２ ペイロードフィルタテーブル
１３２ａ，１３２ｂ ペイロードフィルタ情報
１３４ ペイロードフィルタ処理部
１３６ エラーメッセージ送信部
１３８ メッセージ転送部
２００ ルーティングソフトウェア
２０２ ＬＩＮコントローラ
２０４ イーサネットコントローラ
２０６ ＣＡＮフィルタ処理部
２１１ ＬＩＮドライバ
２１２ ＬＩＮインタフェース
２１６ ＬＩＮフィルタ処理部
２２１ イーサネットドライバ
２２２ イーサネットインタフェース
２２６ イーサネットフィルタ処理部

Claims (19)

1. ソフトウェアを格納する記憶回路と、
   前記ソフトウェアを実行する少なくとも１つの処理回路と、
   車載ネットワークから受信されたメッセージ情報に付加情報を付加するように構成されたコントローラと
   を有し、
   前記ソフトウェアは、前記付加情報を用いて、前記コントローラから出力された前記メッセージ情報をルーティングするか否かを判定するためのフィルタ処理を行うフィルタ処理機能を実現する
   半導体装置。
2. 前記ソフトウェアの前記フィルタ処理機能は、前記付加情報を用いて取得されたペイロードフィルタ情報を用いて、前記メッセージ情報のペイロードに対してフィルタ処理を行う
   請求項１に記載の半導体装置。
3. 前記ソフトウェアの前記フィルタ処理機能は、前記付加情報の少なくとも一部と対応付けられたペイロードフィルタテーブルを用いて、前記ペイロードに対してフィルタ処理を行う
   請求項２に記載の半導体装置。
4. 前記ソフトウェアの前記フィルタ処理機能は、前記ペイロードフィルタテーブルのうち、前記付加情報の少なくとも一部と対応付けられたペイロードフィルタ情報を用いて、前記ペイロードに対してフィルタ処理を行う
   請求項３に記載の半導体装置。
5. 前記ソフトウェアの前記フィルタ処理機能は、前記付加情報の少なくとも一部が予め定められたデータと一致する場合に、前記ペイロードフィルタ情報を用いたフィルタ処理を行わないで、前記メッセージ情報の転送処理を行う
   請求項３に記載の半導体装置。
6. 前記コントローラは、予め定められた受信ルールに従って、前記メッセージ情報を振り分ける
   請求項１に記載の半導体装置。
7. 前記コントローラは、前記受信ルールを示す受信ルールテーブルを用いて、前記メッセージ情報の識別子に対してフィルタ処理を行う
   請求項６に記載の半導体装置。
8. 前記コントローラは、前記受信ルールテーブルを用いて、前記付加情報を付加する
   請求項７に記載の半導体装置。
9. 前記コントローラは、前記受信ルールに合致する前記メッセージ情報を、少なくともデータの送信が可能な第１のバッファに格納し、
   前記ソフトウェアの前記フィルタ処理機能は、前記第１のバッファに格納された前記メッセージ情報のペイロードに対してフィルタ処理を行う
   請求項６に記載の半導体装置。
10. 前記コントローラは、前記受信ルールに合致しない前記メッセージ情報を、データの受信のみが可能な第２のバッファに格納し、
    前記ソフトウェアの前記フィルタ処理機能は、前記第２のバッファに格納された前記メッセージ情報について、前記ソフトウェアによるフィルタ処理を行うことなく、エラーメッセージを送信する
    請求項６に記載の半導体装置。
11. 前記フィルタ処理機能は、前記半導体装置のハードウェアコンポーネントを抽象化するレイヤにおいて、フィルタ処理を行う
    請求項１に記載の半導体装置。
12. 半導体装置であって、
    ソフトウェアを格納する記憶回路と、
    前記ソフトウェアを実行する少なくとも１つの処理回路と、
    車載ネットワークから受信されたメッセージ情報に付加情報を付加するように構成されたコントローラと
    を有し、
    前記ソフトウェアは、
    前記半導体装置を構成するマイクロコントローラに依存しない処理を実行するアプリケーションと、
    前記アプリケーションを前記マイクロコントローラに依存しないようにする基本ソフトウェアと
    を有し、
    前記基本ソフトウェアは、前記半導体装置のハードウェアを抽象化するレイヤに設けられた、前記車載ネットワークを規定するプロトコルを使用可能とするためのネットワークインタフェースにおいて、前記付加情報を用いて、前記コントローラから出力された前記メッセージ情報をルーティングするか否かを判定するためのフィルタ処理を行うフィルタ処理機能を実現する
    半導体装置。
13. 車載ネットワークから受信されたメッセージ情報に付加情報を付加し、
    前記付加情報を用いて、前記メッセージ情報をルーティングするか否かを判定するためのフィルタ処理を行う
    情報処理方法。
14. 前記付加情報を用いて取得されたペイロードフィルタ情報を用いて、前記メッセージ情報のペイロードに対してフィルタ処理を行う
    請求項１３に記載の情報処理方法。
15. 前記付加情報の少なくとも一部と対応付けられたペイロードフィルタテーブルを用いて、前記ペイロードに対してフィルタ処理を行う
    請求項１４に記載の情報処理方法。
16. 前記ペイロードフィルタテーブルのうち、前記付加情報の少なくとも一部と対応付けられたペイロードフィルタ情報を用いて、前記ペイロードに対してフィルタ処理を行う
    請求項１５に記載の情報処理方法。
17. 予め定められた受信ルールに従って、前記メッセージ情報を振り分ける
    請求項１３に記載の情報処理方法。
18. 前記受信ルールを示す受信ルールテーブルを用いて、前記メッセージ情報の識別子に対してフィルタ処理を行う
    請求項１７に記載の情報処理方法。
19. 前記付加情報の付加、及び、前記メッセージ情報を振り分けは、ハードウェアによって実現され、
    前記付加情報を用いたフィルタ処理は、ソフトウェアによって実現される
    請求項１７に記載の情報処理方法。

Images