(57)【特許請求の範囲】
【請求項１】
ブロードキャスト送信すべきデータを生成する第１生成部と、
前記第１生成部において生成したデータを少なくとも対象としたメッセージ認証コードを生成すべきか否か判定するメッセージ認証コード生成タイミング決定部と、
前記メッセージ認証コード生成タイミング決定部の判定結果に応じて、前記メッセージ認証コードを生成する第２生成部と、
前記第１生成部において生成したデータおよび前記第２生成部において生成したメッセージ認証コードのうち少なくともいずれか一方をブロードキャスト送信する送信部と、
を備え、
前記メッセージ認証コード生成タイミング決定部は、前記送信部が前回送信したデータを保持し、前記保持したデータと前記第１生成部において生成された今回送信されるデータとを比較し、前記第１生成部において生成したデータが変化した場合、前記第２生成部にメッセージ認証コードを生成させ、それ以外の場合にメッセージ認証コードの生成を省略することを特徴とする送信装置。
【請求項２】
ブロードキャスト送信すべきデータを生成する第１生成部と、
前記第１生成部において生成したデータを少なくとも対象としたメッセージ認証コードを生成すべきか否か判定するメッセージ認証コード生成タイミング決定部と、
前記メッセージ認証コード生成タイミング決定部の判定結果に応じて、前記メッセージ認証コードを生成する第２生成部と、
前記第１生成部において生成したデータおよび前記第２生成部において生成したメッセージ認証コードのうち少なくともいずれか一方をブロードキャスト送信する送信部と、
を備え、
前記メッセージ認証コード生成タイミング決定部は、前記第１生成部において生成されメッセージ認証コードを生成する対象となったデータであって前記送信部が前回送信したデータを保持し、前記保持したデータに対する前記第１生成部において生成された今回送信されるデータの変化量が閾値を超える場合、前記第２生成部にメッセージ認証コードを生成させ、それ以外の場合にメッセージ認証コードの生成を省略することを特徴とする送信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、バスで接続された通信システムにおける送信装置、受信装置、送信方法、及び受信方法に関する。
【背景技術】
【０００２】
車載ネットワークとしてＣＡＮ（Controller Area Network）が普及している。ＣＡＮはバス型ネットワークを採用したシリアル通信プロトコルである。バスに接続される各ノードからのメッセージは、バスに接続される全てのノードにブロードキャストされる。当該メッセージには送信元ノード及び宛先ノードの識別情報が含まれない。従って受信ノードにおいて、正しい通信相手から来たメッセージであるか否かを単純に判断することはできない。
【０００３】
メッセージの完全性を保証したり、ＣＡＮに接続された不正機器からのリプレイ攻撃を防御するため、メッセージ認証コード（Message Authentication Code;ＭＡＣ）を用いる方法が提案されている。例えば、通常のメッセージを生成・送信する度に、そのメッセージに対するＭＡＣを生成し、ＭＡＣを含むメッセージを送信する方法が提案されている（例えば特許文献１参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１３−９８７１９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
通常のメッセージを生成・送信する度に、ＭＡＣを生成するとノードの負荷が大きくなり消費電力も増大する。またメッセージの数が増えるため、バスの占有率も増大する。
【０００６】
本発明はこうした状況に鑑みなされたものであり、その目的は、ネットワークの資源の負荷増大を抑制しつつ、セキュリティを向上させる技術を提供することにある。
【課題を解決するための手段】
【０００７】
本発明のある態様の送信装置は、ブロードキャスト送信すべきデータを生成する第１生成部と、第１生成部において生成したデータを少なくとも対象としたメッセージ認証コードを生成する第２生成部と、第１生成部において生成したデータと、第２生成部において生成したメッセージ認証コードをブロードキャスト送信する送信部と、を備える。第２生成部は、第１生成部において生成される複数のデータの内、一部のデータに対するメッセージ認証コードの生成を省略する。
【０００８】
なお、以上の構成要素の任意の組み合わせ、本発明の表現を方法、装置、システム、コンピュータプログラム、コンピュータプログラムを記録した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【０００９】
本発明によれば、ネットワークの資源の負荷増大を抑制しつつ、セキュリティを向上させることができる。
【図面の簡単な説明】
【００１０】
【図１】ＣＡＮで使用されるデータフレームのフォーマットの一例を示す図である。
【図２】本発明の実施の形態に係るＣＡＮシステムの構成の一例を示す図である。
【図３】本発明の実施の形態に係るＥＣＵの構成例を示す図である。
【図４】ＭＡＣを別メッセージで送信する方式にて、メッセージ処理部の送信に必要な機能を示すブロック図である。
【図５】図４のメッセージ処理部によるメッセージ送信処理を示すフローチャートである。
【図６】ＭＡＣを別メッセージで送信する方式にて、メッセージ処理部の受信に必要な機能を示すブロック図である。
【図７】図６のメッセージ処理部によるメッセージ受信処理を示すフローチャートである。
【図８】ＭＡＣを別メッセージで送信する方式にて、異常ケースを想定したメッセージ処理部の受信に必要な機能を示すブロック図である。
【図９】図８のメッセージ処理部によるメインメッセージ受信処理を示すフローチャートである。
【図１０】図８のメッセージ処理部によるＭＡＣメッセージ受信処理を示すフローチャートである。
【図１１】図１１（ａ）−（ｅ）は、正規のメインメッセージと正規のＭＡＣメッセージの間に、不正のメッセージを挿入する攻撃の例を示す図である。
【図１２】ＭＡＣを同一メッセージで送信する方式にて、メッセージ処理部の送信に必要な機能を示すブロック図である。
【図１３】図１２のメッセージ処理部によるメッセージ送信処理を示すフローチャートである。
【図１４】ＭＡＣを同一メッセージで送信する方式にて、メッセージ処理部の受信に必要な機能を示すブロック図である。
【図１５】図１４のメッセージ処理部によるメッセージ受信処理を示すフローチャートである。
【図１６】ＭＡＣの生成・送信タイミングの複数の具体例をまとめた一覧表を示す図である。
【図１７】状態を表すデータが変化したときＭＡＣを生成・送信する方式にて、メッセージ処理部のＭＡＣ生成タイミング決定部に必要な機能を示すブロック図である。
【図１８】図１７のＭＡＣ生成タイミング決定部によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。
【図１９】状態を表すデータが変化したときＭＡＣを生成・送信する方式の具体例を示す図である。
【図２０】状態を表すデータが変化したときＭＡＣを生成・送信する方式において、送信側ＥＣＵから受信側ＥＣＵに送信されるメッセージの一例を示す図である。
【図２１】変化量が閾値を超えたときＭＡＣを生成・送信する方式にて、メッセージ処理部のＭＡＣ生成タイミング決定部に必要な機能を示すブロック図である。
【図２２】図２１のＭＡＣ生成タイミング決定部によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。
【図２３】変化量が閾値を超えたときＭＡＣを生成・送信する方式の具体例を示す図である。
【図２４】値が閾値を超えたときＭＡＣを生成・送信する方式における、ＭＡＣ生成タイミング決定部によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。
【図２５】値の変化が規定した方向への変化のときＭＡＣを生成・送信する方式における、ＭＡＣ生成タイミング決定部によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。
【図２６】値がデフォルト値と異なるときＭＡＣを生成・送信する方式における、ＭＡＣ生成タイミング決定部によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。
【図２７】間引き周期でＭＡＣを生成・送信する方式にて、メッセージ処理部のＭＡＣ生成タイミング決定部に必要な機能を示すブロック図である。
【図２８】図２７のＭＡＣ生成タイミング決定部によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。
【図２９】間引き周期でＭＡＣを生成・送信する方式の具体例を示す図である。
【図３０】周期変化に応じてＭＡＣを生成・送信する方式にて、メッセージ処理部のＭＡＣ生成タイミング決定部に必要な機能を示すブロック図である。
【図３１】図３０のＭＡＣ生成タイミング決定部によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。
【図３２】イベント発生に応じてＭＡＣを生成・送信する方式における、ＭＡＣの生成タイミングを決定する処理を示すフローチャートである。
【図３３】オンデマンドに応じてＭＡＣを生成・送信する方式における、ＭＡＣ生成タイミング決定部によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。
【図３４】バス占有率に応じてＭＡＣを生成・送信する方式にて、メッセージ処理部のＭＡＣ生成タイミング決定部に必要な機能を示すブロック図である。
【図３５】図３４のＭＡＣ生成タイミング決定部によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。
【図３６】ランダムにＭＡＣを生成・送信する方式にて、メッセージ処理部のＭＡＣ生成タイミング決定部に必要な機能を示すブロック図である。
【図３７】図３６のＭＡＣ生成タイミング決定部によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。
【図３８】車両状態に応じてＭＡＣを生成・送信する方式における、ＭＡＣ生成タイミング決定部によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。
【図３９】ＭＡＣの検証に失敗した不正メッセージの数をカウントする機能を有するメッセージ処理部の構成を示すブロック図である。
【発明を実施するための形態】
【００１１】
本発明の実施の形態は、車両内に搭載される複数のＥＣＵ（Electronic Control Unit)がノードとして接続された車載ネットワークであって、メッセージＩＤとデータとＭＡＣが含まれるメッセージがブロードキャストされるものに関する。以下、このようなネットワークとしてのＣＡＮシステムを例示して本発明の実施の形態を説明する。上述のように、ＣＡＮはバス型ネットワークを採用しており、バスに接続される各ＥＣＵからのメッセージは、バスに接続される全てのＥＣＵにブロードキャストされる。近年、車両の電装化が進み一台の車両に搭載されるＥＣＵの数やＥＣＵが扱うデータ量が増えており、ＣＡＮバスのトラフィック量が増えている。またＥＣＵの増加および高度化に伴い、バッテリの消費電力が増えている。
【００１２】
図１は、ＣＡＮで使用されるデータフレームのフォーマットの一例を示す図である。図１のデータフレームは、ＳＯＦ、ＩＤフィールド、ＲＴＲ、ＩＤＥ、ｒ０、ＤＬＣ、データフィールド、ＣＲＣデリミタ、Ａｃｋ、Ａｃｋデリミタ、及びＥＯＦを含む。各ボックス内の数字はビット数を示す。またボックスの上が開放されている項目は常に「０」をとる項目であり、ボックスの下が開放されている項目は常に「１」をとる項目である。上下が開放されていない項目は「０」と「１」の両方をとりうる項目である。
【００１３】
本実施の形態では主に、ＩＤフィールドＦ１とデータフィールドＦ２に注目する。ＩＤフィールドＦ１に格納されるＩＤ（以下適宜、ＣＡＮＩＤともいう）は、メッセージの種類および優先度を表す識別情報である。本明細書では、送信可能な状態のデータフレームをメッセージと呼ぶ。ＣＡＮにおけるメッセージは、車両内の特定の機能に関するメッセージである。当該機能には、特定の監視対象を監視する監視機能および特定の制御対象を制御する制御機能が含まれる。例えば車両内の特定の機能に関するメッセージとして、速度情報を含むメッセージ、ドアの開閉を指示するメッセージ等がある。
【００１４】
ＣＡＮＩＤは、送信されるメッセージに含まれる情報に関連づけられており、メッセージを受信したＥＣＵでは、そのＣＡＮＩＤに基づいてメッセージに含まれる情報を判断する。データフィールドＦ２には最大６４ビットのデータを格納できる。
【００１５】
図１に示すようにＣＡＮのデータフレームには、送信先ＩＤおよび受信先ＩＤが含まれない。従って受信側ＥＣＵは、正しい通信相手から来たメッセージであるか否か判断できない。例えば、エンジン回転数を含むメッセージはエンジンＥＣＵから送信される。当該メッセージに付与されるＣＡＮＩＤと同じＣＡＮＩＤが付与されたメッセージが、不正ＥＣＵから送信されると、受信側ＥＣＵは正当なエンジンＥＣＵからのメッセージか不正ＥＣＵからのメッセージであるか判別できない。
【００１６】
このようにＣＡＮプロトコルでは、なりすましが容易である。またメッセージがＣＡＮバスに対してブロードキャスト送信されるため、ユニキャスト送信よりも盗聴が容易である。
【００１７】
これらの脅威に対して本実施の形態では、ＭＡＣを用いることでＣＡＮメッセージを認証する。ＭＡＣは、認証対象のデータと共通鍵とに所定のＭＡＣアルゴリズムを適用して生成される。共通鍵は、ＣＡＮに接続されたＥＣＵ間で事前に共有される秘密の鍵である。ＭＡＣ生成アルゴリズムには、ハッシュ関数を使う方式（ＨＭＡＣ）や、ブロック暗号アルゴリズムを使う方式（ＯＭＡＣ／ＣＭＡＣ、ＣＢＣ−ＭＡＣ、ＰＭＡＣ）などがある。受信側ＥＣＵでは、メッセージに含まれる認証対象のデータと自己が保持する共通鍵に、送信側ＥＣＵで使用されたＭＡＣアルゴリズムを適用してＭＡＣを算出する。この算出したＭＡＣと受信したＭＡＣが一致していれば認証が成功したと判定し、不一致であれば認証が失敗したと判定する。
【００１８】
従って共通鍵が漏洩しなければ不正なＥＣＵや悪意がある発信元などからのメッセージは、認証されないことになる。正当なメッセージとＭＡＣを受信した不正なＥＣＵなどからの再送攻撃に対しては、認証対象のデータに、カウント値などを含めることにより対処できる。本実施の形態では、送信側ＥＣＵで生成されるＭＡＣのデータ長を６４ビット以下とする。６４ビットを超えるＭＡＣが算出される場合、その任意の６４ビット又はそれ以下のビットを抽出して使用する。
【００１９】
以下本明細書ではデータフィールドに、特定の機能に関する情報（以下適宜、通常データという）を含みＭＡＣを含まないメッセージをメインメッセージという。メインメッセージは通常の制御を行うために送信されるメッセージである。通常データは、特定の機能の制御値などが該当する。データフィールドに、通常データを含まずＭＡＣを含むメッセージをＭＡＣメッセージという。データフィールドに、通常データとＭＡＣの両方を含むメッセージをＭＡＣ付きメインメッセージという。
【００２０】
上記では、ＣＡＮＩＤはメッセージに含まれる情報に関連づけられると説明した。この場合、そのメッセージがメインメッセージであるか、ＭＡＣメッセージであるか、ＭＡＣ付きメインメッセージであるかにより、それぞれに別のＩＤが付されてもよく、同一のＩＤが付されてもよい。
【００２１】
各ＥＣＵにおいてメインメッセージが送信される度に、ＭＡＣを生成する処理が行われ、ＭＡＣメッセージがＣＡＮに送信されると、ＥＣＵの処理負荷および消費電流が増大し、バスの占有率も増加する。ＭＡＣを生成する処理は暗号化処理を含むため、ＥＣＵの処理負荷が増大する。車両内のＥＣＵには処理能力が非力なものも存在するため、処理負荷が低く抑えられることが望ましい。また車両において、ＥＣＵの消費電流が増大するとバッテリの消費が早くなり、バッテリ上がりが発生しやすくなりバッテリの寿命も短くなる。従ってＥＣＵの消費電流は低いことが望ましい。またＣＡＮにおいて、バス占有率の増加による通信障害を回避するため、一般的にはバス占有率がある一定値以下になるように設定されている。メインメッセージが送信される度にＭＡＣメッセージが送信されると、単純に従来の２倍のメッセージ数になる。
【００２２】
以上に鑑み、以下に説明する実施の形態では、メインメッセージの送信の度にＭＡＣを毎回送信するのではなく、ＭＡＣを送信するタイミングを工夫することで、送信頻度を減らしながらも効率的にセキュリティを確保する方法を提供する。即ち、送信すべき複数の通常データの内、一部の通常データに対するＭＡＣの生成・送信を省略することにより、ＥＣＵの処理負荷および消費電流の増大を抑え、バス占有率の増加も抑制する。なお、以下の説明において「生成・送信」なる表現は、「生成かつ送信」および「送信のみ」のいずれか一方を意味する。
【００２３】
図２は、本発明の実施の形態に係るＣＡＮシステム５００の構成の一例を示す図である。当該ＣＡＮシステム５００では、ＣＡＮバス２００に複数のＥＣＵ１００（図２ではＥＣＵ１（１００ａ）、ＥＣＵ２（１００ｂ）、ＥＣＵ３（１００ｃ）及びＥＣＵ４（１００ｄ））が接続されている。ＣＡＮでは、ＣＳＭＡ／ＣＡ(Carrier Sense Multiple Access with Collision Avoidance)と呼ばれるアクセス制御方式が採用されており、ＣＡＮバス２００に対して最初に送信を開始したＥＣＵ１００が送信権を取得する。なお同時に複数のＥＣＵ１００が送信した場合は、通信調停（bus arbitration）が行われる。ＣＡＮではＣＡＮＩＤの値が小さいほうが優先される。
【００２４】
図３は、本発明の実施の形態に係るＥＣＵ１００の構成例を示す図である。ＥＣＵ１００は、アプリケーション処理部１０、メッセージ処理部３０及び送受信部５０を備える。これらの構成は、ハードウエア的には、任意のプロセッサ、メモリ、及びその他のＬＳＩで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【００２５】
アプリケーション処理部１０は例えば、プロセッサ、メモリ、及びメモリにロードされたアプリケーションプログラムによって実現される。メッセージ処理部３０は例えば、プロセッサ、メモリ、メモリにロードされたメッセージ処理プログラム、及びＣＡＮコントローラによって実現される。なおＣＡＮコントローラに全ての機能を実装する構成も可能である。送受信部５０は例えば、トランシーバにより実現可能される。
【００２６】
アプリケーション処理部１０は、各ＥＣＵ１００の制御対象または監視対象（例えばエンジン、ステアリング、ブレーキ、又はその他の各種補機）と接続し、それらの対象からステータス情報または指示情報を取得する。アプリケーション処理部１０は当該対象から取得した情報をもとに、ＣＡＮにおいてブロードキャスト送信すべきデータを生成し、メッセージ処理部３０に渡す。またアプリケーション処理部１０は、ＣＡＮバス２００から（他のＥＣＵからＣＡＮバス２００を通じて）受信されたメインメッセージに含まれるデータをメッセージ処理部３０から受け取り、当該データに応じて当該対象を制御する。
【００２７】
メッセージ処理部３０は、メッセージ送信時にメッセージを生成するとともに、メッセージ受信時にメッセージを解析する。メッセージ処理部３０の具体的な構成は後述する。
【００２８】
送受信部５０は、メッセージ処理部３０により生成されたメッセージをＣＡＮバス２００に対してブロードキャスト送信する。上述のようにメッセージには、メインメッセージ、ＭＡＣメッセージ、及びＭＡＣ付きメインメッセージがある。メッセージ処理部３０は、アプリケーション処理部１０により生成された通常データを少なくとも対象としたＭＡＣを生成する。当該ＭＡＣは、当該通常データを含むメインメッセージに含めて送信されてもよいし、別のメッセージで送信されてもよい。前者の場合はＭＡＣ付きメインメッセージが送信され、後者の場合はメインメッセージとＭＡＣメッセージが別に送信される。いずれも場合も、当該通常データと当該通常データに対するＭＡＣが、ＣＡＮバス２００に対してブロードキャスト送信されることに変わりはない。
【００２９】
送受信部５０は、他のＥＣＵ１００で生成され、ＣＡＮバス２００に対してブロードキャスト送信されたメッセージをＣＡＮバス２００から受信する。送受信部５０は、受信したメッセージをメッセージ処理部３０に渡す。
【００３０】
図４は、ＭＡＣを別メッセージで送信する方式にて、メッセージ処理部３０の送信に必要な機能を示すブロック図である。図４では受信に関する機能は省略して描いている。図４のメッセージ処理部３０は、メインメッセージ生成部３１、ＣＡＮＩＤ抽出部３２、データフィールド抽出部３３、ＭＡＣ生成タイミング決定部３４、ＭＡＣ生成部３５及びＭＡＣメッセージ生成部３６を有する。
【００３１】
図５は、図４のメッセージ処理部３０によるメッセージ送信処理を示すフローチャートである。メインメッセージ生成部３１は、送信すべきデータをアプリケーション処理部１０から取得し、当該データをＣＡＮメッセージのデータフィールドに格納する。また当該データに対応するＣＡＮＩＤをＩＤフィールドに格納する。当該ＣＡＮＩＤはアプリケーション処理部１０から取得してもよいし、予め保持していてもよい。メインメッセージ生成部３１は、ＣＡＮメッセージのその他の項目の値を確定してメインメッセージを完成させる。メインメッセージ生成部３１は、生成したメインメッセージを送受信部５０に渡し、送受信部５０は当該メインメッセージをブロードキャスト送信する。
【００３２】
ＣＡＮＩＤ抽出部３２は、メインメッセージ生成部３１により生成されたメインメッセージのＩＤフィールドからＣＡＮＩＤを抽出する（図５のＳ１０）。ＣＡＮＩＤ抽出部３２は、抽出したＣＡＮＩＤをＭＡＣ生成タイミング決定部３４及びＭＡＣ生成部３５に渡す。データフィールド抽出部３３は、メインメッセージ生成部３１により生成されたメインメッセージのデータフィールドに格納されたデータを抽出する（Ｓ１１）。データフィールド抽出部３３は、抽出したデータをＭＡＣ生成タイミング決定部３４及びＭＡＣ生成部３５に渡す。
【００３３】
ＭＡＣ生成タイミング決定部３４は、抽出されたＣＡＮＩＤ及びデータから、ＭＡＣを生成すべきタイミングであるか否か判断する（Ｓ１２）。なお、判断方法の具体例は後述する。ＭＡＣ生成が必要なタイミングである場合（Ｓ１３のＹ）、ＭＡＣ生成タイミング決定部３４はＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ１４）。具体的には、少なくともＣＡＮＩＤ及びデータを含む認証対象に、保持する共通鍵３５ａを使用して所定のＭＡＣアルゴリズムを適用して、当該認証対象に対するＭＡＣを生成する。ＭＡＣ生成部３５は、生成したＭＡＣをＭＡＣメッセージ生成部３６に渡す。
【００３４】
ＭＡＣメッセージ生成部３６は、ＭＡＣ生成部３５から取得したＭＡＣをＣＡＮメッセージのデータフィールドに格納する。また上記データに対するＭＡＣを含むメッセージであることを示すＣＡＮＩＤをＩＤフィールドに格納する。例えば上記データそのものを含むメッセージであることを示すＣＡＮＩＤの値から所定の固定値を減算した値が使用されてもよい。ＭＡＣメッセージ生成部３６は、ＣＡＮメッセージのその他の項目の値を確定してＭＡＣメッセージを完成させる。ＭＡＣメッセージ生成部３６は、生成したＭＡＣメッセージを送受信部５０に渡し、送受信部５０は当該ＭＡＣメッセージをブロードキャスト送信する（Ｓ１５）。ステップＳ１３にて、ＭＡＣの生成が必要なタイミングでない場合（Ｓ１３のＮ）、ステップＳ１４及びステップＳ１５におけるＭＡＣ生成・送信処理はスキップされる。
【００３５】
図６は、ＭＡＣを別メッセージで送信する方式にて、メッセージ処理部３０の受信に必要な機能を示すブロック図である。図６では送信に関する機能は省略して描いている。図６のメッセージ処理部３０は、メッセージ解析部４１、ＣＡＮＩＤ抽出部４２、データフィールド抽出部４３、ＭＡＣ検証タイミング決定部４４、ＭＡＣ生成部４５、ＭＡＣ比較部４６及びデータ受渡部４７を有する。
【００３６】
図７は、図６のメッセージ処理部３０によるメッセージ受信処理を示すフローチャートである。送受信部５０はＣＡＮバス２００からメインメッセージを受信し、メッセージ解析部４１に渡す。ＣＡＮＩＤ抽出部４２は、メッセージ解析部４１により受信されたメインメッセージのＩＤフィールドからＣＡＮＩＤを抽出する（図７のＳ２０）。ＣＡＮＩＤ抽出部４２は、抽出したＣＡＮＩＤをＭＡＣ検証タイミング決定部４４及びＭＡＣ生成部４５に渡す。データフィールド抽出部４３は、メッセージ解析部４１により受信されたメインメッセージのデータフィールドに格納されたデータを抽出する（Ｓ２１）。データフィールド抽出部４３は、抽出したデータをＭＡＣ検証タイミング決定部４４、ＭＡＣ生成部４５及びデータ受渡部４７に渡す。
【００３７】
ＭＡＣ検証タイミング決定部４４は、抽出されたＣＡＮＩＤ及びデータから、ＭＡＣを検証すべきタイミングであるか否か判断する（Ｓ２２）。なお、判断方法の具体例は後述するが、送信側のＭＡＣ生成タイミング決定部３４と同じ判断方法が用いられる。ＭＡＣの検証が必要なタイミングである場合（Ｓ２３のＹ）、ＭＡＣ検証タイミング決定部４４はＭＡＣ生成部４５にＭＡＣの生成を指示する。ＭＡＣ生成部４５は、抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ２４）。生成方法は送信側のＭＡＣ生成部３５の生成方法と同じである。受信側のＭＡＣ生成部４５は、送信側のＭＡＣ生成部３５が保持する共通鍵３５ａと同じ共通鍵４５ａを保持している。ＭＡＣ生成部４５は、生成したＭＡＣをＭＡＣ比較部４６に渡す。
【００３８】
ＥＣＵ１００は当該メインメッセージに対するＭＡＣメッセージの到着を待ち（Ｓ２５のＮ）、ＭＡＣメッセージが受信された場合（Ｓ２５のＹ）、送受信部５０はＣＡＮバス２００からＭＡＣメッセージを受信し、メッセージ解析部４１に渡す。データフィールド抽出部４３は、メッセージ解析部４１により受信されたＭＡＣメッセージのデータフィールドに格納されたＭＡＣを抽出する（Ｓ２６）。データフィールド抽出部４３は、抽出したＭＡＣをＭＡＣ比較部４６に渡す。
【００３９】
ＭＡＣ比較部４６は、ＭＡＣ生成部４５により生成されたＭＡＣとデータフィールド抽出部４３により抽出されたＭＡＣとを比較する（Ｓ２７）。両者のＭＡＣが一致した場合（Ｓ２８のＹ）、ＭＡＣ比較部４６はＭＡＣの検証が成功したと判定し、データ受渡部４７に検証が成功した旨を通知する。データ受渡部４７はデータフィールド抽出部４３から取得し、保留していたデータをアプリケーション処理部１０に渡す（Ｓ２９）。アプリケーション処理部１０は、取得したデータに応じて制御対象を制御、または監視対象を監視する。
【００４０】
ステップＳ２８にて、両者のＭＡＣが一致しない場合（Ｓ２８のＮ）、ＭＡＣ比較部４６はＭＡＣの検証が失敗したと判定し、データ受渡部４７に検証が失敗した旨を通知する。データ受渡部４７は、データフィールド抽出部４３から取得し、保留していたデータをアプリケーション処理部１０に渡さない。ステップＳ２３にて、ＭＡＣ検証が必要なタイミングでない場合（Ｓ２３のＮ）、ステップＳ２４〜ステップＳ２８の処理がスキップされる。データ受渡部４７は、データフィールド抽出部４３から取得したデータを無条件にアプリケーション処理部１０に渡す（Ｓ２９）。
【００４１】
図５及び図６に示すように、ＭＡＣを別メッセージで送信する場合、メインメッセージとＭＡＣメッセージの間に攻撃者が不正メッセージを挿入する攻撃が考えられる。以下、このような異常ケースを想定したメッセージ受信時の処理を説明する。
【００４２】
図８は、ＭＡＣを別メッセージで送信する方式にて、異常ケースを想定したメッセージ処理部３０の受信に必要な機能を示すブロック図である。図８では送信に関する機能は省略して描いている。図８のメッセージ処理部３０は、図６の異常ケースを想定しないメッセージ処理部３０の構成要素に、メインメッセージ一時保持部４８が追加された構成である。メインメッセージ一時保存部４８は、一般的なメモリ素子などによって実現される。
【００４３】
図９は、図８のメッセージ処理部３０によるメインメッセージ受信処理を示すフローチャートである。制御の方針としては、メインメッセージを最大ｎ個（３つ程度）まで保持し、ＭＡＣメッセージと保持しているメインメッセージとでＭＡＣを検証する。検証の結果、Ｒｉｊｅｃｔされた（検証が失敗した）場合は、保持しているメッセージを破棄する処理を行う。メッセージ解析部４１は、送受信部５０を介してＣＡＮバス２００からメインメッセージを受信すると、メインメッセージ一時保持部４８にメインメッセージが保持されているか否か判断する（図９のＳ３０）。保持されている場合（Ｓ３０のＹ）、メインメッセージ一時保持部４８に保持されているメインメッセージの数がｎ個以上であるか否か判断する（Ｓ３１）。ｎはメインメッセージ一時保持部４８に保持されるメインメッセージの上限数を規定したパラメータである。例えばｎ＝３に設定される。
【００４４】
メインメッセージの数がｎ個以上、保持されている場合（Ｓ３１のＹ）、メッセージ解析部４１は、メインメッセージ一時保持部４８に保持されている複数のメインメッセージの内、最も古いメインメッセージを破棄する（Ｓ３２）。メッセージ解析部４１は、受信した新しいメインメッセージをメインメッセージ一時保持部４８に格納する（Ｓ３３）。即ち、メインメッセージ一時保持部４８はＦＩＦＯで管理される。メインメッセージ一時保持部４８に格納されたメインメッセージに対する処理は、メッセージ解析部４１から指示があるまで保留される。
【００４５】
ステップＳ３１にて、メインメッセージ一時保持部４８に保持されているメインメッセージの数がｎ個未満である場合（Ｓ３１のＮ）、ステップＳ３２をスキップして、メッセージ解析部４１は、受信した新しいメインメッセージをメインメッセージ一時保持部４８に格納する（Ｓ３３）。
【００４６】
ステップＳ３０にて、メインメッセージ一時保持部４８にメインメッセージが保持されていない場合（Ｓ３０のＮ）、ＭＡＣ検証タイミング決定部４４は、そのメインメッセージに対するＭＡＣの検証が必要であるか否か判断する（Ｓ３４）。この判断方法の具体例は後述する。ＭＡＣの検証が必要である場合（Ｓ３４のＹ）、ＭＡＣ検証タイミング決定部４４は、その旨をメッセージ解析部４１に通知し、メッセージ解析部４１は、受信した新しいメインメッセージをメインメッセージ一時保持部４８に格納する（Ｓ３３）。
【００４７】
ステップＳ３４にて、ＭＡＣの検証が必要でない場合（Ｓ３４のＮ）、データ受渡部４７は、データフィールド抽出部４３から取得したデータをアプリケーション処理部１０に渡す（Ｓ３５）。アプリケーション処理部１０は、取得したデータに応じて制御対象を制御する、または監視対象を監視する。
【００４８】
図１０は、図８のメッセージ処理部３０によるＭＡＣメッセージ受信処理を示すフローチャートである。メッセージ解析部４１は、送受信部５０を介してＣＡＮバス２００からＭＡＣメッセージを受信すると、メインメッセージ一時保持部４８に検証の必要なメインメッセージが保持されているか否か判断する（図１０のＳ４０）。保持されている場合（Ｓ４０のＹ）、メインメッセージからＭＡＣを生成する（Ｓ４１）。具体的には当該メインメッセージのＣＡＮＩＤ及びデータからＭＡＣを生成する。
【００４９】
ＭＡＣ比較部４６は、上記メインメッセージから生成されたＭＡＣと、受信されたＭＡＣメッセージから抽出されたＭＡＣを比較する（Ｓ４２）。両者のＭＡＣが一致した場合（Ｓ４２のＹ）、データ受渡部４７は、データフィールド抽出部４３から取得したデータをアプリケーション処理部１０に渡す（Ｓ４３）。アプリケーション処理部１０は、取得したデータに応じて取得したデータに応じて制御対象を制御する、または監視対象を監視する。
【００５０】
ＭＡＣ比較部４６による検証が成功した場合にて、メインメッセージ一時保持部４８にその他のメインメッセージが保持されている場合（Ｓ４４のＹ）、保持されているその他のメインメッセージは破棄される（Ｓ４５）。保持されていない場合（Ｓ４４のＮ）、ステップＳ４５の処理はスキップされる。
【００５１】
ステップＳ４２にて、ＭＡＣが一致しない場合（Ｓ４２のＮ）、ステップＳ４０に遷移し、検証の必要なメインメッセージが保持されているか否かの判断が繰り返される。
【００５２】
ステップＳ４０にて、メインメッセージ一時保持部４８に検証の必要なメインメッセージが保持されていない場合（Ｓ４０のＮ）、メッセージ解析部４１は、受信したＭＡＣメッセージを破棄する（Ｓ４６）。
【００５３】
図１１（ａ）−（ｅ）は、正規のメインメッセージと正規のＭＡＣメッセージの間に、不正のメッセージを挿入する攻撃の例を示す図である。図１１（ａ）−（ｅ）では、車速センサに接続されたＥＣＵから、制御値として車速情報をデータフィールドに含むメインメッセージを送信する例を描いている。また前回送信したメインメッセージに含まれる車速と異なる車速を含むメインメッセージを送信する際に、ＭＡＣメッセージが生成・送信される制御を前提とする。即ち、前回送信したメインメッセージに含まれる車速と、今回送信するメインメッセージに含まれる車速が同じ場合、ＭＡＣメッセージは生成・送信されない。また図１１（ａ）−（ｅ）のそれぞれの、先頭のメインメッセージの直前のメッセージは、制御値として車速＝３０ｋｍ／ｈを含むメインメッセージであるとする。またメインメッセージ一時保持部４８に保持されるメインメッセージの上限数ｎは３とする。また図１１（ａ）−（ｅ）において、不正なメッセージは太枠で囲んでいる。
【００５４】
図１１（ａ）は、正常なケースを示す例である。このケースでは不正なメッセージは挿入されていない。前回のメインメッセージに含まれる車速と異なる車速を含む、２番目のメインメッセージと３番目のメインメッセージに、それぞれＭＡＣメッセージが付加される。先頭のメインメッセージは、前回のメインメッセージに含まれる車速と同じ車速（＝３０ｋｍ／ｈ）を含むメッセージであるため、ＭＡＣメッセージが付加されない。
【００５５】
図１１（ｂ）は、攻撃パターン１を示す例である。先頭のメインメッセージは不正なメインメッセージである。このメインメッセージ（不正）に含まれる車速（＝４０ｋｍ／ｈ）は、前回のメインメッセージ（正規）に含まれる車速（＝３０ｋｍ／ｈ）と異なる。従って図９のステップＳ３４のＭＡＣ検証が必要なメインメッセージに該当する。従って図９のステップＳ３４のＭＡＣの検証が必要なメインメッセージに該当するため、このメインメッセージは、メインメッセージ一時保持部４８に格納される。２番目及び３番目のメインメッセージ（正規）は、図９のステップＳ３０のメインメッセージ一時保持部４８に既にメインメッセージを保持しているという条件を満たすため、メインメッセージ一時保持部４８に格納される。
【００５６】
４番目のメインメッセージ（正規）の受信時点で、メインメッセージ一時保持部４８に既に３個のメインメッセージが保持されている。従って図９のステップＳ３２により最も古い先頭のメインメッセージ（不正）が破棄される。
【００５７】
図１１（ｃ）は、攻撃パターン２を示す例である。先頭のメインメッセージ（正規）は、図９のステップＳ３４の条件を満たすため、メインメッセージ一時保持部４８に格納される。２番目及び３番目のメインメッセージ（不正）も、図９のステップＳ３０の条件を満たすため、メインメッセージ一時保持部４８に格納される。３番目のメインメッセージ（正規）の次にＭＡＣメッセージ（正規）が受信される。メインメッセージ一時保持部４８に保持される３個のメインメッセージの内、図１０のステップＳ４０の検証が必要なメインメッセージは、先頭のメインメッセージ（正規）と３番目のメインメッセージ（不正）である。２番目のメインメッセージ（不正）に含まれる車速（＝４０ｋｍ／ｈ）は、前回のメインメッセージ（正規）に含まれる車速（＝３０ｋｍ／ｈ）と異なるため、２番目のメインメッセージ（不正）は検証が必要なメインメッセージに該当しない。
【００５８】
メインメッセージ一時保持部４８に検証が必要なメインメッセージが複数保持される場合、新しいメインメッセージから検証される。この例では３番目のメインメッセージ（不正）から検証される。３番目のメインメッセージ（不正）から生成されるＭＡＣと、受信したＭＡＣメッセージ（正規）に含まれるＭＡＣは一致しない。次に先頭のメインメッセージ（正規）が検証される。先頭のメインメッセージ（正規）から生成されるＭＡＣと、受信したＭＡＣメッセージ（正規）に含まれるＭＡＣは一致する。従って先頭のメインメッセージ（正規）がアプリケーション処理部１０に渡される。図１０のステップＳ４５により、２番目のメインメッセージ（不正）と３番目のメインメッセージ（不正）は破棄される。
【００５９】
なおＭＡＣメッセージが受信される前に、メインメッセージのＭＡＣを生成することも考えられる。しかしながら不正なメインメッセージが多量に送信された場合、メインメッセージのＭＡＣを生成することによるＥＣＵ１００の負荷が増大する。本実施の形態ではＭＡＣメッセージが受信された後に、新しいメインメッセージから順番にＭＡＣを生成して検証し、検証が成功したメインメッセージが見つかった時点で、残りのメインメッセージを破棄する。これによりＥＣＵ１００の負荷の増大を抑制できる。
【００６０】
図１１（ｄ）は、攻撃パターン３を示す例である。先頭のメインメッセージ（正規）は、図９のステップＳ３４の条件を満たすため、メインメッセージ一時保持部４８に格納される。２番目のメインメッセージ（不正）も、図９のステップＳ３０の条件を満たすため、メインメッセージ一時保持部４８に格納される。その次にＭＡＣメッセージ（不正）が受信される。
【００６１】
メインメッセージ一時保持部４８に保持される２個のメインメッセージの内、図１０のステップＳ４０の検証が必要なメインメッセージは、先頭のメインメッセージ（正規）である。２番目のメインメッセージ（不正）は検証が必要なメインメッセージに該当しない。先頭のメインメッセージ（正規）から生成されるＭＡＣと、受信したＭＡＣメッセージ（不正）に含まれるＭＡＣは一致しない。これによりメインメッセージ一時保持部４８に、検証が必要なメインメッセージが存在しなくなるため、図１０のステップＳ４６により当該ＭＡＣメッセージ（不正）が破棄される。このように２番目のメインメッセージ（不正）と当該ＭＡＣメッセージ（不正）との検証は行われずに、当該ＭＡＣメッセージ（不正）が破棄される。
【００６２】
次にＭＡＣメッセージ（正規）がさらに受信される。先頭のメインメッセージ（正規）から生成されるＭＡＣと、今回受信したＭＡＣメッセージ（正規）に含まれるＭＡＣは一致する。従って先頭のメインメッセージ（正規）がアプリケーション処理部１０に渡される。図１０のステップＳ４５により、メインメッセージ一時保持部４８内の２番目のメインメッセージ（不正）は破棄される。
【００６３】
図１１（ｅ）は、攻撃パターン４を示す例である。先頭のメインメッセージ（不正）は、図９のステップＳ３４の条件を満たすため、メインメッセージ一時保持部４８に格納される。２番目のメインメッセージ（正規）も、図９のステップＳ３０の条件を満たすため、メインメッセージ一時保持部４８に格納される。その次にＭＡＣメッセージ（不正）が受信される。
【００６４】
メインメッセージ一時保持部４８に保持される２個のメインメッセージの内、図１０のステップＳ４０の検証が必要なメインメッセージは、先頭のメインメッセージ（不正）である。２番目のメインメッセージ（正規）は検証が必要なメインメッセージに該当しない。先頭のメインメッセージ（不正）から生成されるＭＡＣと、受信したＭＡＣメッセージ（不正）に含まれるＭＡＣは一致しない。これによりメインメッセージ一時保持部４８に、検証が必要なメインメッセージが存在しなくなるため、図１０のステップＳ４６により当該ＭＡＣメッセージ（不正）が破棄される。
【００６５】
正規のメインメッセージと正規のＭＡＣメッセージの間に、不正のメッセージを挿入する攻撃に対しては、ＭＡＣメッセージの優先度をメインメッセージの優先度より高く設定することが有効である。これは、ＭＡＣメッセージのＣＡＮＩＤが、メインメッセージのＣＡＮＩＤより常に小さくなるように各メッセージのＣＡＮＩＤを設定すれば実現できる。上述のようにＣＡＮでは、同時に複数のメッセージが送信された場合、通信調停によりＣＡＮＩＤの値が小さいほうが優先されるためである。ＭＡＣメッセージの優先度をメインメッセージの優先度より高く設定することにより、正規のメインメッセージと正規のＭＡＣメッセージとの間に、多量の不正のメッセージが挿入される確率を下げることができる。
【００６６】
これまで、ＭＡＣの検証が必要なメインメッセージを受信した場合、そのメインメッセージに対応するＭＡＣメッセージが受信されるまで、メインメッセージに含まれるデータをデータ受渡部４７に保留する方式を説明した。ＭＡＣの検証が必要なメインメッセージを受信した場合でも、データ受渡部４７が、メインメッセージに含まれるデータを即座にアプリケーション処理部１０に渡す方式を採用することもできる。この方式では、ＭＡＣの検証が必要なメインメッセージを受信してから、所定の設定時間内に当該メインメッセージに対応するＭＡＣメッセージを受信できない場合、データ受渡部４７はアプリケーション処理部１０に、当該メインメッセージに含まれるデータを渡す前の制御状態に戻すよう指示する。この方式は、車両の安全性に比較的影響しない制御に適用されるのが望ましい。
【００６７】
なおデータ受渡部４７はアプリケーション処理部１０に、当該メインメッセージに含まれるデータを渡す前の制御状態に戻すよう指示する代わりに、フェイルセーフモードに移行するよう指示してもよい。
【００６８】
図１２は、ＭＡＣを同一メッセージで送信する方式にて、メッセージ処理部３０の送信に必要な機能を示すブロック図である。図１２では受信に関する機能は省略して描いている。図１２のメッセージ処理部３０の構成は、図４のメッセージ処理部３０の構成からＭＡＣメッセージ生成部３６を省略した構成である。
【００６９】
図１３は、図１２のメッセージ処理部３０によるメッセージ送信処理を示すフローチャートである。図１３のステップＳ１０〜ステップＳ１４までの処理は、図５のステップＳ１０〜ステップＳ１４までの処理と同じである。メインメッセージ生成部３１は、ＭＡＣ生成部３５から取得したＭＡＣを、メインメッセージのデータフィールドに、既に格納されているデータと重複しないように格納する。また上記データ及び当該データに対するＭＡＣを含むＭＡＣ付きメインメッセージであることを示すＣＡＮＩＤをＩＤフィールドに格納する。メインメッセージ生成部３１は、生成したＭＡＣ付きメインメッセージを送受信部５０に渡し、送受信部５０は当該ＭＡＣ付きメインメッセージをブロードキャスト送信する（Ｓ１５ａ）。
【００７０】
図１４は、ＭＡＣを同一メッセージで送信する方式にて、メッセージ処理部３０の受信に必要な機能を示すブロック図である。図１４では送信に関する機能は省略して描いている。図１４のメッセージ処理部３０は、図６のメッセージ処理部３０の構成と比較し、データフィールド抽出部４３が分離部４３ａを含む構成である。その他の構成は同じである。
【００７１】
図１５は、図１４のメッセージ処理部３０によるメッセージ受信処理を示すフローチャートである。送受信部５０はＣＡＮバス２００からＭＡＣ付きメインメッセージを受信し、メッセージ解析部４１に渡す。ＣＡＮＩＤ抽出部４２は、メッセージ解析部４１により受信されたＭＡＣ付きメインメッセージのＩＤフィールドからＣＡＮＩＤを抽出する（図１５のＳ２０ａ）。データフィールド抽出部４３は、メッセージ解析部４１により受信されたＭＡＣ付きメインメッセージのデータフィールド内のデータ及びＭＡＣを抽出する（Ｓ２１ｂ）。データフィールド抽出部４３は、抽出したデータフィールド内のデータとＭＡＣとを分離する（Ｓ２２）。
【００７２】
ＭＡＣ検証タイミング決定部４４は、抽出されたＣＡＮＩＤ及びデータから、ＭＡＣを検証すべきタイミングであるか否か判断する（Ｓ２３）。ＭＡＣの検証が必要なタイミングである場合（Ｓ２３のＹ）、ＭＡＣ生成部４５は、抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ２４）。ＭＡＣ比較部４６は、ＭＡＣ生成部４５により生成されたＭＡＣと、データフィールド抽出部４３により抽出および分離されたＭＡＣを比較する（Ｓ２７ａ）。両者のＭＡＣが一致した場合（Ｓ２８のＹ）、ＭＡＣ比較部４６はＭＡＣの検証が成功したと判定し、データ受渡部４７に検証が成功した旨を通知する。データ受渡部４７はデータフィールド抽出部４３から取得し、保留していたデータをアプリケーション処理部１０に渡す（Ｓ２９）。アプリケーション処理部１０は、取得したデータに応じて制御対象を制御する、または監視対象を監視する。
【００７３】
ステップＳ２８にて、両者のＭＡＣが一致しない場合（Ｓ２８のＮ）、ＭＡＣ比較部４６はＭＡＣの検証が失敗したと判定し、データ受渡部４７に検証が失敗した旨を通知する。データ受渡部４７は、データフィールド抽出部４３から取得し、保留していたデータをアプリケーション処理部１０に渡さない。ステップＳ２３にて、ＭＡＣの検証が必要なタイミングでない場合（Ｓ２３のＮ）、ステップＳ２４、ステップＳ２７ａ及びステップＳ２８の処理がスキップされ、データ受渡部４７は、データフィールド抽出部４３から取得したデータを無条件にアプリケーション処理部１０に渡す（Ｓ２９）。
【００７４】
以上に説明したＭＡＣを同一メッセージで送信する方式は、送信すべき通常データの量が少ない場合に有効である。ＭＡＣを同一メッセージで送信する方式はＭＡＣを別メッセージで送信する方式と比較し、基本的にメッセージ数を減らす効果がある。しかしながら、通常データの量が多い場合、６４ビットのデータフィールドに通常データとＭＡＣを併存させるのが難しくなる。その場合、両者の少なくとも一方を複数に分割する必要があり、メッセージの数が増える。またＭＡＣを別メッセージで送信する方式のほうが通常、メッセージ処理部３０の処理を単純化できる。従って必ずしも、ＭＡＣを同一メッセージで送信する方式が、ＭＡＣを別のメッセージで送信する方式より有利というわけではない。したがって、通常データの量などが考慮されたうえで、両者が使い分けられて設定されるのが好ましい。
【００７５】
以下、ＭＡＣメッセージの生成・送信タイミングについて説明する。各ＥＣＵ１００は、通常データを含むメッセージを受信し、その通常データが示す値によって特定の制御を実行している。上述のように受信側ＥＣＵ１００でも送信側ＥＣＵ１００と同様に、ＭＡＣが付加されるべきタイミングを判断している。受信側ＥＣＵ１００では正規のＭＡＣが到着して検証が成功しない限り当該制御を保留している。これにより攻撃者からの不正制御を防御している。
【００７６】
車両内のＣＡＮで送信される通常データには様々な種類があるが、送信する値が変化しなくても周期的に送信される通常データも多い。例えば車速センサのＥＣＵ１００からは周期的に車速情報が送信される。
【００７７】
以上の状況に鑑み、送信する値が変化するときのみＭＡＣを生成・送信する制御方式が考えられる。この場合、セキュリティを確保しつつＥＣＵ１００及びＣＡＮバス２００の負荷を下げることができる。以下、送信すべき通常データ固有の特徴もしくは性質、または送信すべき通常データの重要度などに応じてＭＡＣの生成・送信タイミングを決定する方法を説明する。
【００７８】
図１６は、ＭＡＣの生成・送信タイミングの複数の具体例をまとめた一覧表を示す図である。まず大分類として、データ変化に起因してタイミングを決定するグループ、送信周期性に起因してタイミングを決定するグループ、及びその他のグループに分類した。
【００７９】
まず、データ変化に起因してタイミングを決定するグループの第１の例として、制御対象または監視対象の状態を表すデータが変化したときＭＡＣを生成・送信する方式を説明する。例えば、ドアロックのＯＮ／ＯＦＦが変化したときにＭＡＣを生成・送信する。またギアポジション（Ｐ，Ｎ，Ｄ，Ｒ）が変化したときにＭＡＣを生成・送信する。このように、制御対象または監視対象の状態は２値で表される場合もあれば、多値で表される場合もある。またエンジン回転数のように、さらに細かな値で表される場合もある。前回のデータと同じ値のデータは重要度が低いデータといえる。仮に当該データが不正なデータであっても、制御に与える影響が小さい。従って負荷軽減を優先して当該データに対するＭＡＣの生成・送信を省略する。
【００８０】
図１７は、状態を表すデータが変化したときＭＡＣを生成・送信する方式にて、メッセージ処理部３０のＭＡＣ生成タイミング決定部３４に必要な機能を示すブロック図である。図１７のＭＡＣ生成タイミング決定部３４は、前回データ保持部３４１及び比較部３４３を含む。
【００８１】
図１８は、図１７のＭＡＣ生成タイミング決定部３４によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。前回データ保持部３４１には、前回のメインメッセージで送信したデータが保持される。比較部３４３は、前回データ保持部３４１に保持されるデータと、データフィールド抽出部３３から渡される今回送信すべきデータを比較する（Ｓ５０）。両者のデータが異なる場合（Ｓ５１のＹ）、比較部３４３はＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、ＣＡＮＩＤ抽出部３２及びデータフィールド抽出部３３により抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ５２）。前回データ保持部３４１内の保持データは、今回送信されたデータに更新される（Ｓ５３）。ステップＳ５１にて、両者のデータが一致する場合（Ｓ５１のＮ）、ステップＳ５２及びステップＳ５３の処理はスキップされる。
【００８２】
図１９は、状態を表すデータが変化したときＭＡＣを生成・送信する方式の具体例を示す図である。図１９では２値（ＯＮ／ＯＦＦ）の状態を表すデータを送信する例を示している。２番目のメインメッセージＭ２に含まれるデータの値（ＯＮ）は、先頭のメインメッセージＭ１に含まれるデータの値（ＯＮ）に対して変化していないため、２番目のメインメッセージＭ２に対するＭＡＣは生成されない。３番目のメインメッセージＭ３に含まれるデータの値（ＯＦＦ）は、２番目のメインメッセージＭ２に含まれるデータの値（ＯＮ）に対して変化しているため、３番目のメインメッセージＭ３に対するＭＡＣが生成・送信される。同様に４番目のメインメッセージＭ４に対するＭＡＣは生成されず、５番目のメインメッセージＭ５に対するＭＡＣが生成・送信される。
【００８３】
図２０は、状態を表すデータが変化したときＭＡＣを生成・送信する方式において、送信側ＥＣＵ１００から受信側ＥＣＵ１００に送信されるメッセージの一例を示す図である。送信すべきデータの値が変化しない第１フェーズＰ１、第２フェーズＰ２及び第４フェーズＰ４では、送信側ＥＣＵ１００でメインメッセージのみが生成され、受信側ＥＣＵ１００に送信される。
【００８４】
送信すべきデータの値が変化する第３フェーズＰ３及び第５フェーズＰ５では、送信側ＥＣＵ１００でメインメッセージと、当該メインメッセージに対するＭＡＣメッセージが生成される。送信側ＥＣＵ１００から当該メインメッセージと当該ＭＡＣメッセージの両方が受信側ＥＣＵ１００に送信される。
【００８５】
次に、データ変化に起因してタイミングを決定するグループの第２の例として、データによって示される値の変化量が閾値を超えたときＭＡＣを生成・送信する方式を説明する。例えば、最後にＭＡＣを生成・送信したときのエンジン回転数の値から、１００ｒｐｍを超えて変化したときにＭＡＣを生成・送信する。データによって示される値の変化量が小さいデータは重要度が低いデータといえる。仮に当該データが不正なデータであっても、制御に与える影響が小さい。従って負荷軽減を優先して当該データに対するＭＡＣの生成・送信を省略する。
【００８６】
図２１は、変化量が閾値を超えたときＭＡＣを生成・送信する方式にて、メッセージ処理部３０のＭＡＣ生成タイミング決定部３４に必要な機能を示すブロック図である。図２１のＭＡＣ生成タイミング決定部３４は、前回データ保持部３４１、減算部３４２及び比較部３４３を含む。
【００８７】
図２２は、図２１のＭＡＣ生成タイミング決定部３４によるＭＡＣの生成をタイミング決定する処理を示すフローチャートである。前回データ保持部３４１には前回、ＭＡＣメッセージが生成されたメインメッセージで送信されたデータの値が保持される。減算部３４２は、前回データ保持部３４１に保持されるデータの値と、データフィールド抽出部３３から渡される今回送信すべきデータの値との差分値を算出する（Ｓ５０ａ）。この例では当該差分値は絶対値で算出される。比較部３４３は算出された差分値と閾値を比較し、当該差分値が当該閾値を超える場合（Ｓ５１ａのＹ）、比較部３４３はＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、ＣＡＮＩＤ抽出部３２及びデータフィールド抽出部３３により抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ５２）。前回データ保持部３４１内の保持データは、今回送信されたデータに更新される（Ｓ５３）。ステップＳ５１ａにて、当該差分値が当該閾値以下の場合（Ｓ５１ａのＮ）、ステップＳ５２及びステップＳ５３の処理はスキップされる。
【００８８】
図２３は、変化量が閾値を超えたときＭＡＣを生成・送信する方式の具体例を示す図である。図２３ではエンジンの回転数を表すデータを送信する例を示している。この例では、先頭のメインメッセージＭ１の直前に送信されたメインメッセージ（不図示）に含まれるエンジン回転数が９９９ｒｐｍであり、当該メインメッセージに対するＭＡＣメッセージが生成・送信されたことを前提とする。また上記の閾値は１００ｒｐｍとする。
【００８９】
前回ＭＡＣメッセージが生成されたメインメッセージで送信されたエンジン回転数（９９９ｒｐｍ）と、先頭のメインメッセージＭ１に含まれるエンジン回転数（１０００ｒｐｍ）との差分の絶対値は１００ｒｐｍ以下である。同様に２番目のメインメッセージＭ２に含まれるエンジン回転数（１００２ｒｐｍ）との差分の絶対値も１００ｒｐｍ以下である。同様に３番目のメインメッセージＭ３に含まれるエンジン回転数（１００５ｒｐｍ）との差分の絶対値も１００ｒｐｍ以下である。従って先頭のメインメッセージＭ１、２番目のメインメッセージＭ２、及び３番目のメインメッセージに対するＭＡＣメッセージは生成・送信されない。
【００９０】
前回ＭＡＣメッセージが生成されたメインメッセージで送信されたエンジン回転数（９９９ｒｐｍ）と、４番目のメインメッセージＭ４に含まれるエンジン回転数（１１００ｒｐｍ）との差分の絶対値は１００ｒｐｍを超える。従って４番目のメインメッセージＭ４に対するＭＡＣメッセージが生成・送信される。これにより、前回ＭＡＣメッセージが生成されたメインメッセージで送信されたエンジン回転数は１１００ｒｐｍに更新される。
【００９１】
前回ＭＡＣメッセージが生成された４番目のメインメッセージＭ４で送信されたエンジン回転数（１１００ｒｐｍ）と、５番目のメインメッセージＭ５に含まれるエンジン回転数（１１０３ｒｐｍ）との差分の絶対値は１００ｒｐｍ以下である。従って５番目のメインメッセージＭ５に対するＭＡＣメッセージは生成・送信されない。
【００９２】
図２１〜図２３に示した例では、前回送信されたデータの値として、前回ＭＡＣメッセージが生成されたメインメッセージで送信されたデータの値を使用したが、ＭＡＣメッセージの生成の有無を問わず、前回送信されたメインメッセージに含まれるデータの値を使用してもよい。
【００９３】
次に、データ変化に起因してタイミングを決定するグループの第３の例として、データによって示される値が閾値を超えたとき、または下回ったときにＭＡＣを生成・送信する方式を説明する。例えば、車速が１０ｋｍ／ｈを超えている場合、常にＭＡＣを生成・送信する。または例えば、バッテリの電源電圧が所定の値を下回った場合、常にＭＡＣを生成・送信する。閾値を超える、または下回る値を持つデータは重要度が高いデータといえる。従ってセキュリティの確保を優先して当該データに対するＭＡＣを生成・送信する。
【００９４】
値が閾値を超えたとき、または下回ったときにＭＡＣを生成・送信する方式にて、メッセージ処理部３０のＭＡＣ生成タイミング決定部３４に必要な機能は、図２１のＭＡＣ生成タイミング決定部３４の比較部３４３があれば足りる。この方式では、過去に送信したデータの値は不要であるため、前回データ保持部３４１及び減算部３４２は設ける必要がない。
【００９５】
図２４は、値が閾値を超えたとき、または下回ったときにＭＡＣを生成・送信する方式における、ＭＡＣ生成タイミング決定部３４によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。比較部３４３は、データフィールド抽出部３３から渡される今回送信すべきデータの値と閾値を比較する（Ｓ６０）。閾値を超えるときにＭＡＣを生成・送信する設定の場合（Ｓ６１１のＹ）、ステップＳ６１２に遷移する。閾値を下回るときにＭＡＣを生成・送信する設定の場合（Ｓ６１１のＮ）、ステップＳ６１３に遷移する。
【００９６】
ステップＳ６１２にて、今回送信すべきデータの値が当該閾値を超える場合（Ｓ６１２のＹ）、比較部３４３はＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、ＣＡＮＩＤ抽出部３２及びデータフィールド抽出部３３により抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ６２）。ステップＳ６１２にて、今回送信すべきデータの値が当該閾値以下の場合（Ｓ６１２のＮ）、ステップＳ６２の処理はスキップされる。
【００９７】
ステップＳ６１３にて、今回送信すべきデータの値が当該閾値を下回る場合（Ｓ６１３のＹ）、比較部３４３はＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、ＣＡＮＩＤ抽出部３２及びデータフィールド抽出部３３により抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ６２）。ステップＳ６１にて、今回送信すべきデータの値が当該閾値以上の場合（Ｓ６１３のＮ）、ステップＳ６２の処理はスキップされる。
【００９８】
次に、データ変化に起因してタイミングを決定するグループの第４の例として、データによって示される値の変化が規定した方向への変化のときＭＡＣを生成・送信する方式を説明する。例えば、データの値が減少する場合はＭＡＣを生成・送信せず、増加する場合にＭＡＣを生成・送信する。この例は、データの値が減少する方向への変化が安全サイドへの変化であり、データの値が増加する方向への変化がリスクサイドへの変化である例である。リスクサイドの方向に値が変化するデータに対してのみＭＡＣを生成・送信することにより、セキュリティの確保と負荷軽減のバランスを図ることができる。
【００９９】
値の変化が規定した方向への変化のときＭＡＣを生成・送信する方式にて、メッセージ処理部３０のＭＡＣ生成タイミング決定部３４に必要な機能は、図１７のＭＡＣ生成タイミング決定部３４の機能と同じである。
【０１００】
図２５は、値の変化が規定した方向への変化のときＭＡＣを生成・送信する方式における、ＭＡＣ生成タイミング決定部３４によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。前回データ保持部３４１には、前回のメインメッセージで送信されたデータの値が保持される。比較部３４３は、前回データ保持部３４１に保持されるデータの値と、データフィールド抽出部３３から渡される今回送信すべきデータの値を比較する（Ｓ５０）。値の変化が増加方向への変化のときＭＡＣを生成・送信する設定の場合（Ｓ５１１のＹ）、ステップＳ５１２に遷移する。値の変化が減少方向への変化のときＭＡＣを生成・送信する設定の場合（Ｓ５１１のＮ）、ステップＳ５１３に遷移する。
【０１０１】
ステップＳ５１２にて、保持されるデータの値が今回送信すべきデータの値を超える場合（Ｓ５１２のＹ）、比較部３４３はＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、ＣＡＮＩＤ抽出部３２及びデータフィールド抽出部３３により抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ５２）。前回データ保持部３４１内の保持データは、今回送信されたデータに更新される（Ｓ５３）。ステップＳ５１２にて、保持されるデータの値が今回送信すべきデータの値以下の場合（Ｓ５１２のＮ）、ステップＳ５２及びステップＳ５３の処理はスキップされる。
【０１０２】
ステップＳ５１３にて、保持されるデータの値が今回送信すべきデータの値以下の場合（Ｓ５１３のＹ）、比較部３４３はＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、ＣＡＮＩＤ抽出部３２及びデータフィールド抽出部３３により抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ５２）。前回データ保持部３４１内の保持データは、今回送信されたデータに更新される（Ｓ５３）。ステップＳ５１３にて、保持されるデータの値が今回送信すべきデータの値を超える場合（Ｓ５１３のＮ）、ステップＳ５２及びステップＳ５３の処理はスキップされる。
【０１０３】
次に、データ変化に起因してタイミングを決定するグループの第５の例として、データによって示される値がデフォルト値と異なるときＭＡＣを生成・送信する方式を説明する。例えば、データの値がデフォルト値以外をとる場合、常にＭＡＣを生成・送信する。通常、デフォルト値は最も安全サイドの値に設定されている。従ってデータの値がデフォルト値をとる場合、負荷軽減を優先して当該データに対するＭＡＣの生成・送信を省略する。
【０１０４】
値がデフォルト値と異なるときＭＡＣを生成・送信する方式にて、メッセージ処理部３０のＭＡＣ生成タイミング決定部３４に必要な機能は、図２１のＭＡＣ生成タイミング決定部３４の比較部３４３があれば足りる。この方式では、過去に送信したデータの値は不要であるため、前回データ保持部３４１及び減算部３４２は設ける必要がない。なお比較部３４３には閾値ではなく、デフォルト値が入力される。
【０１０５】
図２６は、値がデフォルト値と異なるときＭＡＣを生成・送信する方式における、ＭＡＣ生成タイミング決定部３４によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。比較部３４３は、データフィールド抽出部３３から渡される今回送信すべきデータの値とデフォルト値を比較する（Ｓ６０ａ）。今回送信すべきデータの値と当該デフォルト値が異なる場合（Ｓ６１ａのＹ）、比較部３４３はＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、ＣＡＮＩＤ抽出部３２及びデータフィールド抽出部３３により抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ６２）。ステップＳ６１ａにて、今回送信すべきデータの値が当該デフォルト値と同じ場合（Ｓ６１ａのＮ）、ステップＳ６２の処理はスキップされる。
【０１０６】
次に、送信周期性に起因してタイミングを決定するグループの第１の例として、間引き周期でＭＡＣを生成・送信する方式を説明する。例えば、メインメッセージの送信周期よりも長い周期でＭＡＣを生成・送信する。ＭＡＣを生成・送信する回数を単純に減らすことができる。
【０１０７】
図２７は、間引き周期でＭＡＣを生成・送信する方式にて、メッセージ処理部３０のＭＡＣ生成タイミング決定部３４に必要な機能を示すブロック図である。図２７のＭＡＣ生成タイミング決定部３４は、ＭＡＣ送信時刻保持部３４４、時計部３４５、経過時間算出部３４６及び比較部３４７を含む。
【０１０８】
図２８は、図２７のＭＡＣ生成タイミング決定部３４によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。ＭＡＣ送信時刻保持部３４４には、前回のＭＡＣメッセージの送信時刻が保持される。経過時間算出部３４６は、ＭＡＣ送信時刻保持部３４４に保持される前回のＭＡＣメッセージの送信時刻と、時計部３４５から供給される現在の時刻をもとに、前回のＭＡＣメッセージの送信時刻からの経過時間を算出する（Ｓ７０）。比較部３４７は、算出された経過時間と設定周期を比較し（Ｓ７１）、算出された経過時間が当該設定周期を超える場合（Ｓ７１のＹ）、ＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、ＣＡＮＩＤ抽出部３２及びデータフィールド抽出部３３により抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ７２）。ＭＡＣ生成部３５は、生成したＭＡＣをＭＡＣメッセージ生成部３６に渡す。ＭＡＣメッセージ生成部３６は、ＭＡＣ生成部３５から取得したＭＡＣをＣＡＮメッセージのデータフィールドに格納してＭＡＣメッセージを生成する。ＭＡＣメッセージ生成部３６は、生成したＭＡＣメッセージを送受信部５０に渡し、送受信部５０は当該ＭＡＣメッセージをブロードキャスト送信する（Ｓ７３）。ＭＡＣ送信時刻保持部３４４内に保持されるＭＡＣの送信時刻は、今回送信されたＭＡＣメッセージのＭＡＣの送信時刻に更新される（Ｓ７４）。
【０１０９】
ステップＳ７１にて、算出された経過時間が設定周期を超えない場合（Ｓ７１のＮ）、ステップＳ７２、ステップＳ７３及びステップＳ７４の処理はスキップされる。上記の設定周期は、メインメッセージの送信周期より長い周期に設定される。例えば、メインメッセージの送信周期の整数倍の値に設定される。
【０１１０】
図２９は、間引き周期でＭＡＣを生成・送信する方式の具体例を示す図である。図２９ではメインメッセージの送信周期が２０ｍｓ、上記の設定周期が２００ｍｓに設定された例を示している。先頭のメインメッセージＭ１に対するＭＡＣメッセージが送信された時刻から２００ｍｓが経過した時点のメインメッセージＭｎに対して、ＭＡＣメッセージが生成・送信される。先頭のメインメッセージＭ１に対するＭＡＣメッセージが送信された時刻から２００ｍｓが経過する前に生成されるメインメッセージＭ２、メインメッセージＭ３、・・・、メインメッセージＭ（ｎ−１）に対するＭＡＣメッセージの生成・送信は間引かれる。
【０１１１】
次に、送信周期に起因してタイミングを決定するグループの第２の例として、メッセージの送信周期の変化に応じてＭＡＣを生成・送信する方式を説明する。ＥＣＵによっては、メッセージの送信周期が切り替わるものがある。これは、短周期または長周期といった現在の送信周期の情報をＥＣＵの内部で管理している。送信周期の情報は、アプリケーション処理部１０から現在の送信周期の情報を送信周期情報として取得する。このように、送信周期が変化するというメッセージ（データ）の性質に基づいて、次のように制御する。例えば、周期が変化するメインメッセージの現在の周期に応じて、ＭＡＣの生成・送信頻度を変化させる。例えば、メインメッセージの現在の周期が短周期の場合、ＭＡＣの生成・送信を間引く。一方、メインメッセージの現在の周期が長周期の場合、ＭＡＣの生成・送信を間引かない。メインメッセージの周期が短周期の場合、全てのメインメッセージに対してＭＡＣを生成・送信する必要性が低下するため、負荷軽減を優先してＭＡＣの生成・送信を間引く。
【０１１２】
図３０は、周期変化に応じてＭＡＣを生成・送信する方式にて、メッセージ処理部３０のＭＡＣ生成タイミング決定部３４に必要な機能を示すブロック図である。図３０のＭＡＣ生成タイミング決定部３４は、図２７のＭＡＣ生成タイミング決定部３４の構成に、メインメッセージ送信周期判定部３４８が追加された構成である。
【０１１３】
図３１は、図３０のＭＡＣ生成タイミング決定部３４によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。ＭＡＣ送信時刻保持部３４４には、前回のＭＡＣメッセージの送信時刻が保持される。メインメッセージ送信周期判定部３４８は、アプリケーション処理部１０から渡されるメインメッセージの送信周期情報をもとに、メインメッセージの現在の送信周期が短周期であるか長周期であるか判定する（Ｓ６９９）。メインメッセージの送信周期が２種類である場合、短いほうが短周期、長いほうが長周期とされる。
【０１１４】
ステップＳ６９９にて、メインメッセージの現在の送信周期が短周期である場合（Ｓ６９９のＹ）、その後の処理は、図２８のステップＳ７０〜ステップＳ７４までの処理と同じ処理となる。即ち、間引き周期でＭＡＣメッセージが生成・送信される制御となる。
【０１１５】
ステップＳ６９９にて、メインメッセージの現在の送信周期が長周期である場合（Ｓ６９９のＮ）、その後の処理は、図２８のステップＳ７２〜ステップＳ７４までの処理と同じ処理となる。即ち、全てのメインメッセージに対してＭＡＣメッセージが生成・送信される制御となる。
【０１１６】
次に、送信周期性に起因してタイミングを決定するグループの第３の例として、イベント発生に応じてＭＡＣを生成・送信する方式を説明する。このように、イベントが発生した際に送信されるというメッセージ（データ）の性質に基づいて、次のように制御する。例えば、イベント発生に応じてメインメッセージが送信される場合、常にＭＡＣを生成・送信する。具体的には、ドライバーがヘッドライトをＯＮした場合などが該当する。イベント発生により送信されるデータは重要度が高いデータといえる。従ってセキュリティの確保を優先して当該データに対するＭＡＣを常に生成・送信する。
【０１１７】
イベント発生に応じてＭＡＣを生成・送信する方式にて、メッセージ処理部３０のＭＡＣ生成タイミング決定部３４に必要な機能は、メインメッセージ生成部３１により生成されるメインメッセージに含まれるデータがイベント送信型のデータであるか否かを判定する機能があれば足りる。
【０１１８】
図３２は、イベント発生に応じてＭＡＣを生成・送信する方式における、ＭＡＣ生成タイミング決定部３４によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。ＭＡＣ生成タイミング決定部３４は、ＣＡＮＩＤ抽出部３２により抽出されたＣＡＮＩＤ及び／又はデータフィールド抽出部３３から抽出されたデータから、今回送信すべきメインメッセージの種別を判定する（Ｓ８０）。今回送信すべきメインメッセージの種別がイベント送信型の場合（Ｓ８１のＹ）、ＭＡＣ生成タイミング決定部３４はＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、ＣＡＮＩＤ抽出部３２及びデータフィールド抽出部３３により抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ８２）。ステップＳ８１にて、今回送信すべきメインメッセージの種別がイベント送信型でない場合（Ｓ８１のＮ）、ステップＳ８２の処理はスキップされる。
【０１１９】
次に、送信周期性に起因してタイミングを決定するグループの第４の例として、要求メッセージに応じてＭＡＣを生成・送信する方式を説明する。ここで、要求メッセージとは、あるＥＣＵから他のＥＣＵに対して何らかの情報を要求するためのメッセージである。要求メッセージを受信したＥＣＵはそれに対応するメインメッセージをＣＡＮバス２００へ送信する。このように、要求メッセージの応答として送信されるというメッセージ（データ）の性質に基づいて、次のように制御する。例えば、要求メッセージに応じてメインメッセージが送信される場合、常にＭＡＣを生成・送信する。具体的には、他のＥＣＵ１００から、自己のＥＣＵ１００で監視している計器の数値の取得要求があった場合などが該当する。要求メッセージに応じて送信されるデータは重要度が高いデータといえる。従ってセキュリティの確保を優先して当該データに対するＭＡＣを常に生成・送信する。
【０１２０】
要求メッセージに応じてＭＡＣを生成・送信する方式にて、メッセージ処理部３０のＭＡＣ生成タイミング決定部３４に必要な機能は、メインメッセージ生成部３１により生成されるメインメッセージに含まれるデータがオンデマンド送信型のデータであるか否かを判定する機能があれば足りる。
【０１２１】
図３３は、要求メッセージに応じてＭＡＣを生成・送信する方式における、ＭＡＣ生成タイミング決定部３４によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。ＭＡＣ生成タイミング決定部３４は、ＣＡＮＩＤ抽出部３２により抽出されたＣＡＮＩＤ及び／又はデータフィールド抽出部３３から抽出されたデータから、今回送信すべきメインメッセージの種別を判定する（Ｓ８０）。今回送信すべきメインメッセージの種別がオンデマンド送信型の場合（Ｓ８１ａのＹ）、ＭＡＣ生成タイミング決定部３４はＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、ＣＡＮＩＤ抽出部３２及びデータフィールド抽出部３３により抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ８２）。ステップＳ８１ａにて、今回送信すべきメインメッセージの種別がオンデマンド送信型でない場合（Ｓ８１ａのＮ）、ステップＳ８２の処理はスキップされる。
【０１２２】
図１６に示したその他のグループの第１の例として、バス占有率に応じてＭＡＣを生成・送信する方式を説明する。例えば、バスの占有率を監視し、ＭＡＣの送信頻度を調整する。具体的には、自己のＥＣＵ１００から送信されるメッセージによるバスの占有率が閾値を超える場合、ＭＡＣを生成・送信しない。この方式では、バスのトラフィック量を的確に調整できる。
【０１２３】
図３４は、バス占有率に応じてＭＡＣを生成・送信する方式にて、メッセージ処理部３０のＭＡＣ生成タイミング決定部３４に必要な機能を示すブロック図である。図３４のＭＡＣ生成タイミング決定部３４は、時計部３４５、バス占有率算出部３４９及び比較部３５０を含む。バス占有率はＣＡＮバス２００を流れるすべてのメッセージの送信頻度から計算する必要があるため、時計部３４５から得られる時間の情報とＣＡＮバス２００におけるメッセージの送信回数から、ある単位時間あたりの占有率を算出する。
【０１２４】
図３５は、図３４のＭＡＣ生成タイミング決定部３４によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。バス占有率算出部３４９は送受信部５０から、ＣＡＮバス２００よりメッセージ（メインメッセージとＭＡＣメッセージを含む）が受信される度に受信情報を取得する。バス占有率算出部３４９は、取得したメッセージの受信情報からＣＡＮバス２００におけるメッセージの送信頻度を算出し、当該送信頻度と時計部３４５から供給される時間情報（時刻情報）、ＣＡＮバス２００の帯域をもとにバス占有率を算出する（Ｓ９０）。
【０１２５】
比較部３５０は、算出されたバス占有率と閾値を比較し（Ｓ９１）、バス占有率が閾値を超える場合（Ｓ９１のＹ）、比較部３５０はＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、ＣＡＮＩＤ抽出部３２及びデータフィールド抽出部３３により抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ９２）。ステップＳ９１にて、バス占有率が閾値以下の場合（Ｓ９１のＮ）、ステップＳ９２の処理はスキップされる。
【０１２６】
図１６に示したその他のグループの第２の例として、ランダムにＭＡＣを生成・送信する方式を説明する。例えば、ランダムなタイミングでＭＡＣを生成・送信する。なお送信側と受信側でタイミングの共有が必要となる。ランダムなタイミングでＭＡＣを生成・送信する場合、攻撃者からの不正な攻撃がされにくくなる効果がある。
【０１２７】
図３６は、ランダムにＭＡＣを生成・送信する方式にて、メッセージ処理部３０のＭＡＣ生成タイミング決定部３４に必要な機能を示すブロック図である。図３６のＭＡＣ生成タイミング決定部３４は、カウント部３５１、乱数発生部３５２、次回ＭＡＣ送信カウント値保持部３５３及び比較部３５４を含む。カウント部３５１は、メインメッセージに対するＭＡＣの生成・送信時から、リセットされるまでカウントアップしていくカウンタを含む。乱数発生部３５２は、擬似乱数を発生させ次回ＭＡＣ送信カウント値保持部３５３に供給する。次回ＭＡＣ送信カウント値保持部３５３は、乱数発生部３５２から供給される擬似乱数値を、次回のＭＡＣの送信までのカウント値として保持する。
【０１２８】
図３７は、図３６のＭＡＣ生成タイミング決定部３４によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。比較部３５４は、カウント部３５１の現在のカウント値と、次回ＭＡＣ送信カウント値保持部３５３に保持される次回のＭＡＣ送信までのカウント値とを比較する（Ｓ１００）。カウント部３５１の現在のカウント値が次回のＭＡＣ送信までのカウント値に到達した場合（Ｓ１０１のＹ）、比較部３５４はＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、ＣＡＮＩＤ抽出部３２及びデータフィールド抽出部３３により抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ１０２）。
【０１２９】
乱数発生部３５２は、ＭＡＣ生成部３５からＭＡＣの生成が完了した旨の通知を受けると、新たに擬似乱数を発生させ、次回ＭＡＣ送信カウント値保持部３５３に供給する。これにより次回ＭＡＣ送信カウント値保持部３５３に保持される次回のＭＡＣの送信までのカウント値が更新される（Ｓ１０３）。またカウント部３５１は、ＭＡＣ生成部３５からＭＡＣの生成が完了した旨の通知を受けると、カウント値をリセットする（Ｓ１０４）。
【０１３０】
ステップＳ１０１にて、カウント部３５１の現在のカウント値が次回のＭＡＣ送信までのカウント値に到達していない場合（Ｓ１０１のＮ）、カウント部３５１はカウント値をインクリメントする（Ｓ１０５）。なおステップＳ１０３にて発生させた擬似乱数値は、例えばＭＡＣメッセージのデータフィールドに含められて、ＣＡＮバス２００に接続された他のＥＣＵ１００に送信される。なおＭＡＣメッセージではなく、独立の制御メッセージに含められて送信されてもよい。
【０１３１】
図１６に示したその他のグループの第３の例として、車両状態に応じてＭＡＣを生成・送信する方式を説明する。例えば高速走行中や、リプログラミング用のツールが接続されている最中は常にＭＡＣを生成・送信する。リスクが高い状態で生成されるデータは重要度が高いデータといえる。従ってセキュリティの確保を優先して当該データに対するＭＡＣを常に生成・送信する。
【０１３２】
車両状態に応じてＭＡＣを生成・送信する方式にて、メッセージ処理部３０のＭＡＣ生成タイミング決定部３４に必要な機能は、車両情報を取得する機能があれば足りる。
【０１３３】
図３８は、車両状態に応じてＭＡＣを生成・送信する方式における、ＭＡＣ生成タイミング決定部３４によるＭＡＣの生成タイミングを決定する処理を示すフローチャートである。ＭＡＣ生成タイミング決定部３４は、アプリケーション処理部１０から渡されるデータ、又はメインメッセージ生成部３１により受信されデータフィールド抽出部３３により抽出されたデータにより、例えば速度情報などの車両状態を取得する（Ｓ１１０）。
【０１３４】
ＭＡＣ生成タイミング決定部３４は、取得した車両状態が、予め設定されたＭＡＣ送信が必要な車両状態であるか否か判定する（Ｓ１１１）。例えば、取得した速度が６０ｋｍ／ｈを超える場合、高速走行中であるとしてＭＡＣ送信が必要な車両状態と判定する。取得した車両状態が、当該ＭＡＣ送信が必要な車両状態である場合（Ｓ１１１のＹ）、ＭＡＣ生成タイミング決定部３４はＭＡＣ生成部３５にＭＡＣの生成を指示する。ＭＡＣ生成部３５は、ＣＡＮＩＤ抽出部３２及びデータフィールド抽出部３３により抽出されたＣＡＮＩＤ及びデータをもとにＭＡＣを生成する（Ｓ１１２）。ステップＳ１１１にて、取得した車両状態が、当該ＭＡＣ送信が必要な車両状態でない場合（Ｓ１１１のＮ）、ステップＳ１１２の処理はスキップされる。
【０１３５】
以上説明したように本実施の形態によれば、ＭＡＣを生成・送信するタイミングを制御することにより、バス占有率の増加を抑制し、各ＥＣＵの処理負荷および消費電流を低減できる。送信すべきデータの特質（性質、重要度）に応じてＭＡＣを生成・送信するタイミングを決定することにより、バス及びＥＣＵの負荷増大を抑制しつつ、セキュリティを向上させることができる。
【０１３６】
以上、本発明を実施の形態をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【０１３７】
例えば受信側ＥＣＵ１００において、ＭＡＣの検証に失敗した回数をカウントすることにより、あまりに多くの不正メッセージが送信されていた場合に、車両が正常に制御できる状態ではないと判断する機能を追加してもよい。
【０１３８】
図３９は、ＭＡＣの検証に失敗した不正メッセージの数をカウントする機能を有するメッセージ処理部３０の構成を示すブロック図である。図３９のメッセージ処理部３０は、図６のメッセージ処理部３０の構成に、検証失敗回数保持部４９ａ及び異常判定部４９ｂが追加された構成である。
【０１３９】
検証失敗回数保持部４９ａは、ＭＡＣ比較部４６によるＭＡＣの検証の累積失敗回数を保持する。具体的にはＭＡＣ比較部４６によるＭＡＣの検証が失敗する度にカウントアップしていく。異常判定部４９ｂは、検証失敗回数保持部４９ａに保持される失敗回数が設定値（例えば、１２８回）を超えたとき車両異常と判定する。車両異常と判定すると異常判定部４９ｂは、車両全体をフェイルセーフモードに移行させるためのデータを生成させるための指示信号をアプリケーション処理部１０に出力する。さらに運転者に異常を通知するためのデータを生成させるための指示信号をアプリケーション処理部１０に出力してもよい。
【０１４０】
以上、本発明の実施の形態の説明において、送信すべき複数の通常データの内、一部の通常データに対するＭＡＣの生成および送信を省略することとして説明したが、他の形態として、送信すべき複数の通常データのすべてに対してＭＡＣの生成を行い、かつ、生成したデータの特質に基づいて一部のＭＡＣの送信を省略する形態としてもよい。
【０１４１】
本発明の一態様の概要は、次の通りである。本発明のある態様の送信装置は、ブロードキャスト送信すべきデータを生成する第１生成部と、前記第１生成部において生成したデータを少なくとも対象としたメッセージ認証コードを生成する第２生成部と、前記第１生成部において生成したデータと、前記第２生成部において生成したメッセージ認証コードをブロードキャスト送信する送信部と、を備える。前記第２生成部は、前記第１生成部において生成される複数のデータの内、一部のデータに対するメッセージ認証コードの生成を省略する。「第１生成部」は図３のアプリケーション処理部１０であってもよい。「第２生成部」は図４のＭＡＣ生成部３５であってもよい。「送信部」は図３の送受信部５０であってもよい。
【０１４２】
この態様によると、一部のデータに対するメッセージ認証コードの生成を省略することにより、一定レベルのセキュリティを確保しつつ、ＣＡＮ及びＣＡＮに接続された装置の負荷を軽減できる。
【０１４３】
前記第２生成部は、前記第１生成部において生成したデータの特質（性質および重要度の少なくともいずれか一方）に基づき、前記メッセージ認証コードを生成するか否か決定してもよい。これによれば、重要度の高いデータに対するメッセージ認証コードを生成し、重要度の低いデータに対するメッセージ認証コードの生成を省略することができる。あるいは、データの性質に対応して適切にメッセージ認証コードの生成を省略することができる。従ってセキュリティの確保と負荷軽減を効率よく実現できる。
【０１４４】
前記第２生成部は、前記第１生成部において生成したデータが変化した場合にメッセージ認証コードを生成し、それ以外の場合にメッセージ認証コードの生成を省略してもよい。データが変化した場合、そのデータは重要度が高いデータといえる。従って重要度の高いデータに対するメッセージ認証コードを生成し、重要度の低いデータに対するメッセージ認証コードの生成を省略することになり、セキュリティの確保と負荷軽減を効率よく実現できる。
【０１４５】
前記第２生成部は、前記第１生成部において生成したデータによって示される値の変化量が閾値を超えている場合にメッセージ認証コードを生成し、それ以外の場合にメッセージ認証コードの生成を省略してもよい。データによって示される値の変化が閾値を超えいている場合、そのデータは重要度が高いデータといえる。従って重要度の高いデータに対するメッセージ認証コードを生成し、重要度の低いデータに対するメッセージ認証コードの生成を省略することになり、セキュリティの確保と負荷軽減を効率よく実現できる。なお当該閾値は、設計者により実験、シミュレーション、又は経験則などに基づき導かれた値に設定される。
【０１４６】
前記第２生成部は、前記第１生成部において生成したデータによって示される値が閾値を超える場合にメッセージ認証コードを生成し、それ以外の場合にメッセージ認証コードの生成を省略してもよい。データによって示される値が閾値を超えている場合、そのデータは重要度が高いデータといえる。従って重要度の高いデータに対するメッセージ認証コードを生成し、重要度の低いデータに対するメッセージ認証コードの生成を省略することになり、セキュリティの確保と負荷軽減を効率よく実現できる。なお当該閾値は、設計者により実験、シミュレーション、又は経験則などに基づき導かれた値に設定される。
【０１４７】
本発明の別の態様は、受信装置である。この装置は、送信装置がブロードキャスト送信した、データ及び前記データを少なくとも対象としたメッセージ認証コードを受信する受信部と、前記受信部において受信したデータ及びメッセージ認証コードを処理する処理部と、を備える。前記受信部において受信される複数のデータの内、一部のデータに対するメッセージ認証コードの生成が、前記送信装置において省略されている。「受信部」は図３の送受信部５０であってもよい。「処理部」は図３のアプリケーション処理部１０及びメッセージ処理部３０であってもよい。
【０１４８】
この態様によると、一部のデータに対するメッセージ認証コードの検証を省略することができ、一定レベルのセキュリティを確保しつつ、ＣＡＮ及びＣＡＮに接続された装置の負荷を軽減できる。
【０１４９】
本発明のさらに別の態様は、送信方法である。この方法は、ブロードキャスト送信すべきデータを生成する第１ステップと、前記第１ステップにおいて生成したデータを少なくとも対象としたメッセージ認証コードを生成する第２ステップと、前記第１ステップにおいて生成したデータと、前記第２ステップにおいて生成したメッセージ認証コードをブロードキャスト送信する第３ステップと、を備える。前記第２ステップは、前記第１ステップにおいて生成される複数のデータの内、一部のデータに対するメッセージ認証コードの生成を省略する。
【０１５０】
この態様によると、一部のデータに対するメッセージ認証コードの生成を省略することにより、一定レベルのセキュリティを確保しつつ、ＣＡＮ及びＣＡＮに接続された装置の負荷を軽減できる。
【０１５１】
本発明のさらに別の態様は、受信方法である。この方法は、送信装置がブロードキャスト送信した、データ及び前記データを少なくとも対象としたメッセージ認証コードを受信する第１ステップと、前記第１ステップにおいて受信したデータ及びメッセージ認証コードを処理する第２ステップと、を備える。前記第１ステップにおいて受信される複数のデータの内、一部のデータに対するメッセージ認証コードの生成が、前記送信装置において省略されている。
【０１５２】
この態様によると、一部のデータに対するメッセージ認証コードの検証を省略することができ、一定レベルのセキュリティを確保しつつ、ＣＡＮ及びＣＡＮに接続された装置の負荷を軽減できる。
【符号の説明】
【０１５３】
５００  ＣＡＮシステム、  １００  ＥＣＵ、  ２００  ＣＡＮバス、  １０  アプリケーション処理部、  ３０  メッセージ処理部、  ３１  メインメッセージ生成部、  ３２  ＣＡＮＩＤ抽出部、  ３３  データフィールド抽出部、  ３４  ＭＡＣ生成タイミング決定部、  ３４１  前回データ保持部、  ３４２  減算部、  ３４３  比較部、  ３４４  ＭＡＣ送信時刻保持部、  ３４５  時計部、  ３４６  経過時間算出部、  ３４７  比較部、  ３４８  メインメッセージ送信周期判定部、  ３４９  バス占有率算出部、  ３５０  比較部、  ３５１  カウント部、  ３５２  乱数発生部、  ３５３  次回ＭＡＣ送信カウント値保持部、  ３５４  比較部、  ３５  ＭＡＣ生成部、  ３５ａ  共通鍵、  ３６  ＭＡＣメッセージ生成部、  ４１  メッセージ解析部、  ４２  ＣＡＮＩＤ抽出部、  ４３  データフィールド抽出部、  ４３ａ  分離部、  ４４  ＭＡＣ検証タイミング決定部、  ４５  ＭＡＣ生成部、  ４５ａ  共通鍵、  ４６  ＭＡＣ比較部、  ４７  データ受渡部、  ４８  メインメッセージ一時保持部、  ４９ａ  検証失敗回数保持部、  ４９ｂ  異常判定部、  ５０  送受信部。
【産業上の利用可能性】
【０１５４】
本発明は、ＣＡＮに利用可能である。
【図１】
0005880898.tif 000002
【図２】
0005880898.tif 000003
【図３】
0005880898.tif 000004
【図４】
0005880898.tif 000005
【図５】
0005880898.tif 000006
【図６】
0005880898.tif 000007
【図７】
0005880898.tif 000008
【図８】
0005880898.tif 000009
【図９】
0005880898.tif 000010
【図１０】
0005880898.tif 000011
【図１１】
0005880898.tif 000012
【図１２】
0005880898.tif 000013
【図１３】
0005880898.tif 000014
【図１４】
0005880898.tif 000015
【図１５】
0005880898.tif 000016
【図１６】
0005880898.tif 000017
【図１７】
0005880898.tif 000018
【図１８】
0005880898.tif 000019
【図１９】
0005880898.tif 000020
【図２０】
0005880898.tif 000021
【図２１】
0005880898.tif 000022
【図２２】
0005880898.tif 000023
【図２３】
0005880898.tif 000024
【図２４】
0005880898.tif 000025
【図２５】
0005880898.tif 000026
【図２６】
0005880898.tif 000027
【図２７】
0005880898.tif 000028
【図２８】
0005880898.tif 000029
【図２９】
0005880898.tif 000030
【図３０】
0005880898.tif 000031
【図３１】
0005880898.tif 000032
【図３２】
0005880898.tif 000033
【図３３】
0005880898.tif 000034
【図３４】
0005880898.tif 000035
【図３５】
0005880898.tif 000036
【図３６】
0005880898.tif 000037
【図３７】
0005880898.tif 000038
【図３８】
0005880898.tif 000039
【図３９】
0005880898.tif 000040