JPWO2016006150A1 - 車載ネットワークシステム、電子制御ユニット、受信方法及び送信方法 - Google Patents

Abstract

車載ネットワークシステムは、ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介して通信する複数の電子制御ユニットを備え、第１電子制御ユニットは、送信内容の正当性を示すメッセージ認証コード（ＭＡＣ）を算出するための計算に用いるデータに関する識別子（ＭＡＣ計算対象フィールド種別、開始フラグ等）を含む１又は複数のデータフレームをバスにより送信し、第２電子制御ユニットは、バス上で送信された１又は複数のデータフレームを受信し、受信したデータフレームの識別子に応じてメッセージ認証コードの検証処理を行う。

Description

本開示は、車載ネットワークにおいてメッセージを送受信する技術に関する。

近年、自動車の中のシステムには、電子制御ユニット（ＥＣＵ：Electronic Control Unit）と呼ばれる装置が多数配置されている。これらのＥＣＵをつなぐネットワークは車載ネットワークと呼ばれる。車載ネットワークには、多数の規格が存在する。その中でも最も主流な車載ネットワークの一つに、ＩＳＯ１１８９８−１で規定されているＣＡＮ（Controller Area Network）という規格が存在する（「非特許文献１」参照）。

ＣＡＮでは、通信路は２本のバスで構成され、バスに接続されているＥＣＵはノードと呼ばれる。バスに接続されている各ノードは、フレームと呼ばれるメッセージを送受信する。フレームを送信する送信ノードは、２本のバスに電圧をかけ、バス間で電位差を発生させることによって、レセシブと呼ばれる「１」の値と、ドミナントと呼ばれる「０」の値を送信する。複数の送信ノードが全く同一のタイミングで、レセシブとドミナントを送信した場合は、ドミナントが優先されて送信される。受信ノードは、受け取ったフレームのフォーマットに異常がある場合には、エラーフレームと呼ばれるフレームを送信する。エラーフレームとは、ドミナントを６ｂｉｔ連続して送信することで、送信ノードや他の受信ノードにフレームの異常を通知するものである。

またＣＡＮでは送信先や送信元を指す識別子は存在せず、送信ノードはフレーム毎にメッセージＩＤと呼ばれるＩＤを付けて送信し（つまりバスに信号を送出し）、各受信ノードは予め定められたメッセージＩＤのみを受信する（つまりバスから信号を読み取る）。また、ＣＳＭＡ／ＣＡ（Carrier Sense Multiple Access/Collision Avoidance）方式を採用しており、複数ノードの同時送信時にはメッセージＩＤによる調停が行われ、メッセージＩＤの値が小さいフレームが優先的に送信される。

ところで、車載ネットワークにおいて不正なノードがバスに接続され、不正なノードが不正にフレームを送信することで、車体を不正にコントロールしてしまう可能性がある。このような不正なフレームの送信によるコントロールを防止するために、一般にＣＡＮにおけるデータフィールドにメッセージ認証コード（ＭＡＣ：Message Authentication Code）を付加して送信する技術が知られている（「特許文献１」参照）。

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

ＣＡＮ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ２．０ Ｐａｒｔ Ａ、［ｏｎｌｉｎｅ］、ＣＡＮ ｉｎ Ａｕｔｏｍａｔｉｏｎ（ＣｉＡ）、［平成２６年１１月１４日検索］、インターネット（ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｃａｎ−ｃｉａ．ｏｒｇ／ｆｉｌｅａｄｍｉｎ／ｃｉａ／ｓｐｅｃｉｆｉｃａｔｉｏｎｓ／ＣＡＮ２０Ａ．ｐｄｆ） ＲＦＣ２１０４ ＨＭＡＣ： Ｋｅｙｅｄ−Ｈａｓｈｉｎｇ ｆｏｒ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ

ところで、ＣＡＮのフレームには、ＭＡＣを付加するフィールドが存在せず、ＣＡＮにおけるデータフィールドは８ｂｙｔｅｓと少ない。各フレームのデータフィールドにＭＡＣを格納すると、送信すべきデータがデータフィールドに収まらず複数フレームに分割して送信しなければならなくなる場合が生じ得る。この場合には、バスに流れるフレーム数が増加しバスのトラフィックの増加を招く。

そこで、本開示は、送受信するメッセージ（フレーム）のセキュリティを向上し、かつ、バスのトラフィックの増加を抑える車載ネットワークシステムを提供する。また、本開示は、その車載ネットワークシステムで用いられる、電子制御ユニット（ＥＣＵ）、受信方法及び送信方法を提供する。

上記課題を解決するために本開示の一態様に係る車載ネットワークシステムは、ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介して通信する複数の電子制御ユニットを備える車載ネットワークシステムであって、送信内容の正当性を示すメッセージ認証コードを算出するための計算に用いるデータに関する識別子を含む１又は複数のデータフレームを前記バスにより送信する第１電子制御ユニットと、前記バス上で送信された１又は複数のデータフレームを受信し、受信したデータフレームの前記識別子に応じてメッセージ認証コードの検証処理を行う第２電子制御ユニットとを備える車載ネットワークシステムである。

また、上記課題を解決するために本開示の一態様に係る受信方法は、ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介して通信する複数の電子制御ユニットを備える車載ネットワークシステムにおいて用いられる受信方法であって、前記バス上で送信された、送信内容の正当性を示すメッセージ認証コードを算出するための計算に用いるデータに関する識別子を含む１又は複数のデータフレームを受信する受信ステップと、前記受信ステップで１又は複数のデータフレームが受信された場合に、受信されたデータフレームの前記識別子に応じてメッセージ認証コードの検証処理を行う検証ステップとを含む受信方法である。

また、上記課題を解決するために本開示の一態様に係る送信方法は、ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介して通信する複数の電子制御ユニットを備える車載ネットワークシステムにおいて用いられる送信方法であって、１又は複数のデータフレーム内の１以上の領域に配置されるデータを用いた計算により、送信内容の正当性を示すためのメッセージ認証コードを算出する算出ステップと、前記算出ステップで算出されたメッセージ認証コードを前記１又は複数のデータフレームのうちの少なくとも１つのデータフレームに含ませ、当該メッセージ認証コードを算出するための計算に用いられたデータに関する識別子を含ませた当該１又は複数のデータフレームを送信する送信ステップとを含む送信方法である。

また、上記課題を解決するために本開示の一態様に係る電子制御ユニットは、ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介して通信する電子制御ユニットであって、前記バス上で送信された、送信内容の正当性を示すメッセージ認証コードを算出するための計算に用いるデータに関する識別子を含む１又は複数のデータフレームを受信する受信部と、前記受信部により１又は複数のデータフレームが受信された場合に、受信されたデータフレームの前記識別子に応じてメッセージ認証コードの検証処理を行う検証部とを備える電子制御ユニットである。

また、上記課題を解決するために本開示の一態様に係る電子制御ユニットは、ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介して通信する電子制御ユニットであって、１又は複数のデータフレーム内の１以上の領域に配置されるデータを用いた計算により、送信内容の正当性を示すためのメッセージ認証コードを算出する算出部と、前記算出部により算出されたメッセージ認証コードを前記１又は複数のデータフレームのうちの少なくとも１つのデータフレームに含ませ、当該メッセージ認証コードを算出するための計算に用いられたデータに関する識別子を含ませた当該１又は複数のデータフレームを送信する送信部とを備える電子制御ユニットである。

本開示によれば、送信内容の正当性を示すＭＡＣを利用することで送受信するメッセージのセキュリティを向上し、かつ、バスのトラフィックの増加を抑えることができる。

実施の形態１に係る車載ネットワークシステムの全体構成を示す図である。 ＣＡＮプロトコルで規定されるデータフレームのフォーマットを示す図である。 ＣＡＮプロトコルで規定されるエラーフレームのフォーマットを示す図である。 実施の形態１におけるデータフレームへのＭＡＣ付与に係るパターンの一例を示した図である。 実施の形態１に係るＥＣＵの構成図である。 受信ＩＤリストの一例を示す図である。 データフレームのデータフィールドフォーマットの一例を示す図である。 データフレームのデータフィールドフォーマットの一例を示す図である。 実施の形態１におけるデータフィールドヘッダーのデータ構成を示す図である。 ＭＡＣ計算対象フィールド種別の内容例を示す図である。 データフィールド構成種別の内容例を示す図である。 開始フラグの内容例を示す図である。 エンジンに接続されたＥＣＵから送信されるフレームにおけるＩＤ及びデータフィールドの一例を示す図である。 ＥＣＵにおけるデータフレーム送信処理を示すフローチャートである。 ＥＣＵにおけるデータフレーム受信処理を示すフローチャートである（図１６に続く）。 ＥＣＵにおけるデータフレーム受信処理を示すフローチャートである（図１５から続く）。 実施の形態２におけるデータフレームへのＭＡＣ付与に係るパターンの一例を示した図である。 実施の形態２に係るＥＣＵの構成図である。 実施の形態２におけるデータフィールドヘッダーのデータ構成を示す図である。 フレーム特性データのデータ構成を示す図である。 エンジンに接続されたＥＣＵから送信されるフレームにおけるＩＤ及びデータフィールドの一例を示す図である。 ＥＣＵにおける送信処理を示すフローチャートである。 ＥＣＵにおけるデータフレーム受信処理を示すフローチャートである（図２４に続く）。 ＥＣＵにおけるデータフレーム受信処理を示すフローチャートである（図２５に続く）。 ＥＣＵにおけるデータフレーム受信処理を示すフローチャートである（図２４から続く）。 実施の形態２の変形例１におけるデータフレームへのＭＡＣ付与に係るパターンの一例を示した図である。 実施の形態２の変形例２におけるデータフレームへのＭＡＣ付与に係るパターンの一例を示した図である。 実施の形態２の変形例３におけるデータフレームへのＭＡＣ付与に係るパターンの一例を示した図である。

本開示の一実施態様に係る車載ネットワークシステムは、ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介して通信する複数の電子制御ユニットを備える車載ネットワークシステムであって、送信内容の正当性を示すメッセージ認証コードを算出するための計算に用いるデータに関する識別子を含む１又は複数のデータフレームを前記バスにより送信する第１電子制御ユニットと、前記バス上で送信された１又は複数のデータフレームを受信し、受信したデータフレームの前記識別子に応じてメッセージ認証コードの検証処理を行う第２電子制御ユニットとを備える車載ネットワークシステムである。これにより、送信内容の正当性を示すメッセージ認証コード（ＭＡＣ）を利用することで送受信するメッセージのセキュリティが向上される。また、ＭＡＣを算出するための計算に用いるデータに関する識別子により、ＭＡＣの算出のために用いられる情報を送信側のＥＣＵから受信側のＥＣＵへと伝達し得るため、例えば、ＭＡＣの検証に必要なデータ値及びＭＡＣ等といったデータ構成の情報の伝達を行うことが可能となる。これにより、例えば、車載ネットワークシステムにおいてデータフィールドに格納するデータの構成を自由に定めることが可能となる。そして、ＥＣＵが、ＭＡＣの検証を必要とするデータと、ＭＡＣの検証を必要としないデータと、ＭＡＣとを自由にデータフィールドに設定して送信できると、バスのトラフィックの増加を抑えることが可能になる。

また、前記第１電子制御ユニットは、送信する前記１又は複数のデータフレーム内の１以上の領域に配置されるデータを用いた計算により算出したメッセージ認証コードを、当該１又は複数のデータフレームのうちの少なくとも１つのデータフレームに含ませて送信し、前記第１電子制御ユニットに送信される前記１又は複数のデータフレームに含まれる前記識別子は、前記メッセージ認証コードを算出するための計算に用いられた、当該１又は複数のデータフレーム内の１以上のデータの領域を、示す情報を含み、前記第２電子制御ユニットは、前記識別子により示される領域のデータを用いた計算により、前記検証処理を行うこととしても良い。これにより、例えば、ＭＡＣを算出するための計算に用いる領域を、データフレーム内の任意のフィールドにすること或いは特定のフィールド内の任意の位置にすること等を自由に設定することが可能になる。これにより、例えばバスのトラフィックの増加の抑制、或いは、セキュリティの強化等を図ることが可能となる。

また、前記第１電子制御ユニットは、前記メッセージ認証コードを、送信する複数のデータフレーム内の１以上の領域に配置されるデータを用いた計算により算出し、算出したメッセージ認証コードを当該複数のデータフレームのうちの少なくとも１つのデータフレームに含ませて送信し、前記第１電子制御ユニットに送信される前記複数のデータフレームに含まれる前記識別子は、当該複数のデータフレームの数を示す情報を含み、前記第２電子制御ユニットは、受信したいずれかのデータフレームに含まれる前記識別子により示される数のデータフレームを受信した場合において、受信された各データフレームにおける前記識別子により示される領域のデータを用いた計算により、前記検証処理を行うこととしても良い。これにより、データフレームを送信するＥＣＵが受信するＥＣＵにフレームの数を伝達できるため、ＭＡＣの検証に必要なデータを複数のデータフレームに分割して送信すること等が可能となり、データ構成或いはフレーム編成の自由度が高まる。フレーム編成として、例えば、ＭＡＣが単一のフレームに含まれている状態（つまりこのフレームを受信すると直ちにＭＡＣの検証が可能な状態）であるシングルフレームと、ＭＡＣが複数のフレームに分割されている状態であるマルチフレームとのいずれかを任意に選択可能となる。

また、本開示の一実施態様に係る受信方法は、ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介して通信する複数の電子制御ユニットを備える車載ネットワークシステムにおいて用いられる受信方法であって、前記バス上で送信された、送信内容の正当性を示すメッセージ認証コードを算出するための計算に用いるデータに関する識別子を含む１又は複数のデータフレームを受信する受信ステップと、前記受信ステップで１又は複数のデータフレームが受信された場合に、受信されたデータフレームの前記識別子に応じてメッセージ認証コードの検証処理を行う検証ステップとを含む受信方法である。これにより、データフレームに含まれる識別子により検証処理の内容（例えば検証のための計算に用いるデータを取得するデータフレーム内の位置等）を変化させることができ、データ構成に柔軟に対応した適切な検証処理が可能になる。

また、前記受信ステップで受信されるデータフレームにおける前記識別子は、当該データフレームのデータフィールドの内容の種別を示すこととしても良い。これにより、例えばデータフレームのデータフィールドに、ＭＡＣの計算対象となるデータが含まれているか、ＭＡＣの計算対象ではないデータが含まれているか、ＭＡＣが含まれているか等といった情報を種別としてデータフレームの受信側で受け取ることができるようになる。従って、この受信方法を前提としてデータフィールドに格納するデータの種別を自由に定めることができ、例えば車載ネットワークシステムにおいてＥＣＵが一律にＭＡＣを付加したデータしか送受信しない場合と比べてバスのトラフィックの増加を抑えることが可能になる。

また、前記受信ステップで受信される前記１又は複数のデータフレームのうちの少なくとも１つのデータフレームにはメッセージ認証コードが含まれ、前記受信ステップで受信されるデータフレームにおける前記識別子により示される、データフィールドの内容の前記種別は、当該データフィールドに、メッセージ認証コードを算出するための計算に用いられたデータの領域が含まれるか否かを表し、前記検証ステップでは、前記識別子により示されるデータフィールドの内容の前記種別が、メッセージ認証コードを算出するための計算に用いられたデータの領域が含まれることを表す場合に、当該データフィールドにおけるメッセージ認証コードを算出するための計算に用いられたデータの領域の値を用いた計算により、前記検証処理を行うこととしても良い。これにより、データフレームのデータフィールドにＭＡＣの計算対象となるデータが含まれているか否かを識別することにより、適切にＭＡＣの検証処理を行うことが可能となる。

また、前記受信ステップで受信されるデータフレームにおける前記識別子は、当該データフレームのデータフィールドにおける一の種別のデータの領域を示すこととしても良い。これにより、例えばデータフレームのデータフィールドにおける、ＭＡＣの計算対象となるデータ、ＭＡＣの計算対象ではないデータ或いはＭＡＣが配置されている位置（範囲）の情報をデータフレームの受信側で受け取ることができるようになる。従って、この受信方法を前提として、データフィールドに格納するデータの配置を自由に定めることができるようになる。

また、前記受信ステップで受信される前記１又は複数のデータフレームのうちの少なくとも１つのデータフレームにはメッセージ認証コードが含まれ、前記受信ステップで受信されるデータフレームにおける前記識別子により示される前記一の種別のデータの領域は、メッセージ認証コードを算出するための計算に用いられたデータの領域であり、前記検証ステップでは、前記識別子により示される領域のデータを用いた計算により、前記検証処理を行うこととしても良い。これにより、データフレームのデータフィールドにおけるＭＡＣの計算対象となるデータが含まれている位置（範囲）を確認することで、適切に計算対象となるデータを収集でき、適切にＭＡＣの検証処理を行うことが可能となる。

また、前記受信ステップで受信されるデータフレームにおける前記識別子は当該データフレームのデータフィールドに配置されており、前記検証ステップでは、受信されたデータフレームのデータフィールド内の前記識別子に応じて前記検証処理を行うこととしても良い。これにより、ＣＡＮプロトコルに則り車載ネットワークシステムで仕様を定めることのできるデータフィールドを参照して識別子を確認することで、適切にＭＡＣの検証処理を行うことが可能となる。

また、前記１又は複数のデータフレームに含まれる前記識別子は、当該１又は複数のデータフレーム内の１以上のデータの領域を、示す情報を含み、前記検証ステップでは、前記受信ステップで受信されたデータフレームにおける前記識別子に応じた領域のデータを用いた計算により、前記検証処理を行うこととしても良い。これにより、識別子に応じてＭＡＣの検証のための計算に用いるデータが格納されているフィールド、位置等を特定でき、適切にＭＡＣの検証処理を行うことが可能となる。

また、本開示の一実施態様に係る送信方法は、ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介して通信する複数の電子制御ユニットを備える車載ネットワークシステムにおいて用いられる送信方法であって、１又は複数のデータフレーム内の１以上の領域に配置されるデータを用いた計算により、送信内容の正当性を示すためのメッセージ認証コードを算出する算出ステップと、前記算出ステップで算出されたメッセージ認証コードを前記１又は複数のデータフレームのうちの少なくとも１つのデータフレームに含ませ、当該メッセージ認証コードを算出するための計算に用いられたデータに関する識別子を含ませた当該１又は複数のデータフレームを送信する送信ステップとを含む送信方法である。これにより、データフレームに含ませる識別子により、例えばＭＡＣの算出のための計算に用いたデータのデータフレーム中の位置等を、データフレームの送信側のＥＣＵが受信側のＥＣＵに伝達でき、このためデータフレーム内のデータ構成を自由に設定し得る。

また、前記送信ステップで送信するデータフレームにおける前記識別子は、当該データフレームのデータフィールドの内容の種別を示すこととしても良い。これにより、例えばデータフレームのデータフィールドに、ＭＡＣの計算対象となるデータが含まれているか、ＭＡＣの計算対象ではないデータが含まれているか、ＭＡＣが含まれているか等といった情報を種別としてデータフレームの送信側のＥＣＵが受信側のＥＣＵに伝達できるようになる。従って、データフィールドに格納するデータの種別を自由に定めることができるため、例えば車載ネットワークシステムにおいてＥＣＵが一律にＭＡＣを付加したデータしか送受信されない場合と比べてバスのトラフィックの増加を抑えることが可能になる。

また、前記送信ステップで送信するデータフレームにおける前記識別子により示される、データフィールドの内容の前記種別は、当該データフィールドに、前記算出ステップで前記メッセージ認証コードを算出するための計算に用いられたデータの領域が含まれるか否かを表すこととしても良い。これにより、データフレームのデータフィールドにＭＡＣの計算対象となるデータを含めるか否かを選択でき、データ構成を自由に定めることができるようになる。

また、前記送信ステップで送信するデータフレームにおける前記識別子は、当該データフレームのデータフィールドにおける一の種別のデータの領域を示すこととしても良い。これにより、例えばデータフレームのデータフィールドにおける、ＭＡＣの計算対象となるデータ、ＭＡＣの計算対象ではないデータ或いはＭＡＣが配置されている位置（範囲）の情報をデータフレームの送信側のＥＣＵが受信側のＥＣＵに伝達できるようになる。従って、データフィールドに格納するデータの配置を自由に定めることができるようになる。

また、前記送信ステップで送信するデータフレームにおける前記識別子により示される前記一の種別のデータの領域は、前記算出ステップで前記メッセージ認証コードを算出するための計算に用いられたデータの領域であることとしても良い。これにより、データフレームのデータフィールドにおけるＭＡＣの計算対象となるデータが含まれている位置（範囲）をデータフレームの送信側のＥＣＵが受信側のＥＣＵに伝達でき、ＭＡＣの計算対象となるデータを任意の位置に配置できるようになる。

また、前記送信ステップでは、前記識別子を、送信するデータフレームのデータフィールドに配置することとしても良い。これにより、ＣＡＮプロトコルに則り車載ネットワークシステムで仕様を定めることのできるデータフィールドを活用してＭＡＣを算出するための計算に用いるデータに関する情報を伝達できる。このため、ＣＡＮプロトコルに準拠したＥＣＵにおいてこの送信方法を容易に実現し得る。

また、前記送信ステップで送信する前記１又は複数のデータフレームに含まれる前記識別子は、前記メッセージ認証コードを算出するための計算に用いられた、当該１又は複数のデータフレーム内の１以上のデータの領域を、示す情報を含むこととしても良い。これにより、ＭＡＣの検証のための計算に用いるデータが格納されているフィールド、位置等を適切に伝達することが可能になり、データ構成等の自由度が高まる。

また、本開示の一実施態様に係る電子制御ユニット（ＥＣＵ）は、ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介して通信する電子制御ユニットであって、前記バス上で送信された、送信内容の正当性を示すメッセージ認証コードを算出するための計算に用いるデータに関する識別子を含む１又は複数のデータフレームを受信する受信部と、前記受信部により１又は複数のデータフレームが受信された場合に、受信されたデータフレームの前記識別子に応じてメッセージ認証コードの検証処理を行う検証部とを備える電子制御ユニットである。これにより、データフレームに含まれる識別子により検証処理の内容を変化させることができ、データ構成に柔軟に対応した適切な検証処理が可能になる。例えば、このＥＣＵを含んで構築される車載ネットワークシステムにおいては、データフィールドに格納するデータの構成を自由に定めて、ＭＡＣの検証が必要か否かの情報或いはＭＡＣの検証に用いるデータの領域の情報等を識別子としてデータフレームに含めて送受信できる。これにより、例えばバスのトラフィックの増加を抑えるようにデータフレームの送受信を行うことが可能となる。

また、本開示の一実施態様に係る電子制御ユニット（ＥＣＵ）は、ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介して通信する電子制御ユニットであって、１又は複数のデータフレーム内の１以上の領域に配置されるデータを用いた計算により、送信内容の正当性を示すためのメッセージ認証コードを算出する算出部と、前記算出部により算出されたメッセージ認証コードを前記１又は複数のデータフレームのうちの少なくとも１つのデータフレームに含ませ、当該メッセージ認証コードを算出するための計算に用いられたデータに関する識別子を含ませた当該１又は複数のデータフレームを送信する送信部とを備える電子制御ユニットである。これにより、データフレームに含ませる識別子により、例えばＭＡＣの算出のための計算に用いたデータのデータフレームにおける位置等を、データフレームの送信側のＥＣＵが受信側のＥＣＵに伝達でき、データフレーム内のデータ構成を自由に設定し得る。

なお、これらの全般的又は具体的な態様は、システム、方法、集積回路、コンピュータプログラム又はコンピュータで読み取り可能なＣＤ−ＲＯＭ等の記録媒体で実現されても良く、システム、方法、集積回路、コンピュータプログラム又は記録媒体の任意な組み合わせで実現されても良い。

以下、実施の形態に係る車載ネットワークシステムについて、図面を参照しながら説明する。ここで示す実施の形態は、いずれも本開示の一具体例を示すものである。従って、以下の実施の形態で示される数値、構成要素、構成要素の配置及び接続形態、並びに、ステップ（工程）及びステップの順序等は、一例であって本開示を限定するものではない。以下の実施の形態における構成要素のうち、独立請求項に記載されていない構成要素については、任意に付加可能な構成要素である。また、各図は、模式図であり、必ずしも厳密に図示されたものではない。

（実施の形態１）
以下、本開示の実施の形態として、ＭＡＣを用いたデータの検証を可能にし、かつ、データの効率的な送受信を可能にするための送信方法或いは受信方法を実現するＥＣＵを含む車載ネットワークシステム１０について、図面を参照しながら説明する。

［１．１ 車載ネットワークシステム１０の全体構成］
図１は、実施の形態１に係る車載ネットワークシステム１０の全体構成を示す図である。車載ネットワークシステム１０は、ＣＡＮプロトコルに従って通信するネットワーク通信システムの一例であり、制御装置、センサ等の各種機器が搭載された自動車におけるネットワーク通信システムである。車載ネットワークシステム１０は、バス２００と、各種機器に接続されたＥＣＵ１００ａ〜１００ｄといったバス２００に接続された各ノードとを含んで構成される。なお、図１では省略しているものの、車載ネットワークシステム１０にはＥＣＵ１００ａ〜１００ｄ以外にもいくつものＥＣＵが含まれ得るが、ここでは、便宜上ＥＣＵ１００ａ〜１００ｄに注目して説明を行う。ＥＣＵは、例えば、プロセッサ（マイクロプロセッサ）、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置である。メモリは、ＲＯＭ、ＲＡＭ等であり、プロセッサにより実行される制御プログラム（コンピュータプログラム）を記憶することができる。例えばプロセッサが、制御プログラム（コンピュータプログラム）に従って動作することにより、ＥＣＵは各種機能を実現することになる。なお、コンピュータプログラムは、所定の機能を達成するために、プロセッサに対する指令を示す命令コードが複数個組み合わされて構成されたものである。

ＥＣＵ１００ａ〜１００ｄは、それぞれエンジン３１０、ブレーキ３２０、ドア開閉センサ３３０、窓開閉センサ３４０に接続されている。ＥＣＵ１００ａ〜１００ｄのそれぞれは、接続されている機器（エンジン３１０等）の状態を取得し、定期的に状態を表すフレーム（後述するデータフレーム）等をネットワーク（つまりバス）に送信している。ＥＣＵ１００ａ〜１００ｄは、このデータフレームの送信のためのデータフレーム送信処理（後述）を実行し、またデータフレームを受信するためのデータフレーム受信処理（後述）を実行する。

この車載ネットワークシステム１０においてはＣＡＮプロトコルに従って各ＥＣＵがフレームの授受を行う。ＣＡＮプロトコルにおけるフレームには、データフレーム、リモートフレーム、オーバーロードフレーム及びエラーフレームがある。説明の便宜上、データフレーム及びエラーフレームを中心に説明する。

［１．２ データフレームフォーマット］
以下、ＣＡＮプロトコルに従ったネットワークで用いられるフレームの１つであるデータフレームについて説明する。

図２は、ＣＡＮプロトコルで規定されるデータフレームのフォーマットを示す図である。同図には、ＣＡＮプロトコルで規定される標準ＩＤフォーマットにおけるデータフレームを示している。データフレームは、ＳＯＦ（Start Of Frame）、ＩＤフィールド、ＲＴＲ（Remote Transmission Request）、ＩＤＥ（Identifier Extension）、予約ビット「ｒ」、ＤＬＣ（Data Length Code）、データフィールド、ＣＲＣ（Cyclic Redundancy Check）シーケンス、ＣＲＣデリミタ「ＤＥＬ」、ＡＣＫ（Acknowledgement）スロット、ＡＣＫデリミタ「ＤＥＬ」、及び、ＥＯＦ（End Of Frame）の各フィールドで構成される。

ＳＯＦは、１ｂｉｔのドミナントで構成される。バスがアイドルの状態はレセシブになっており、ＳＯＦによりドミナントへ変更することでフレームの送信開始を通知する。

ＩＤフィールドは、１１ｂｉｔで構成される、データの種類を示す値であるＩＤ（メッセージＩＤ）を格納するフィールドである。複数のノードが同時に送信を開始した場合、このＩＤフィールドで通信調停を行うために、ＩＤが小さい値を持つフレームが高い優先度となるよう設計されている。

ＲＴＲは、データフレームとリモートフレームとを識別するための値であり、データフレームにおいてはドミナント１ｂｉｔで構成される。

ＩＤＥと「ｒ」とは、両方ドミナント１ｂｉｔで構成される。

ＤＬＣは、４ｂｉｔで構成され、データフィールドの長さを示す値である。なお、ＩＤＥ、「ｒ」及びＤＬＣを合わせてコントロールフィールドと称する。

データフィールドは、最大６４ｂｉｔで構成される送信するデータの内容を示す値である。８ｂｉｔ毎に長さを調整できる。送られるデータの仕様については、ＣＡＮプロトコルで規定されておらず、車載ネットワークシステム１０において定められる。従って、車種、製造者（製造メーカ）等に依存した仕様となる。

ＣＲＣシーケンスは、１５ｂｉｔで構成される。ＳＯＦ、ＩＤフィールド、コントロールフィールド及びデータフィールドの送信値より算出される。

ＣＲＣデリミタは、１ｂｉｔのレセシブで構成されるＣＲＣシーケンスの終了を表す区切り記号である。なお、ＣＲＣシーケンス及びＣＲＣデリミタを合わせてＣＲＣフィールドと称する。

ＡＣＫスロットは、１ｂｉｔで構成される。送信ノードはＡＣＫスロットをレセシブにして送信を行う。受信ノードはＣＲＣシーケンスまで正常に受信ができていればＡＣＫスロットをドミナントとして送信する。レセシブよりドミナントが優先されるため、送信後にＡＣＫスロットがドミナントであれば、送信ノードは、いずれかの受信ノードが受信に成功していることを確認できる。

ＡＣＫデリミタは、１ｂｉｔのレセシブで構成されるＡＣＫの終了を表す区切り記号である。

ＥＯＦは、７ｂｉｔのレセシブで構成されており、データフレームの終了を示す。

［１．３ エラーフレームフォーマット］
図３は、ＣＡＮプロトコルで規定されるエラーフレームのフォーマットを示す図である。エラーフレームは、エラーフラグ（プライマリ）と、エラーフラグ（セカンダリ）と、エラーデリミタとから構成される。

エラーフラグ（プライマリ）は、エラーの発生を他のノードに知らせるために使用される。エラーを検知したノードはエラーの発生を他のノードに知らせるために６ｂｉｔのドミナントを連続で送信する。この送信は、ＣＡＮプロトコルにおけるビットスタッフィングルール（連続して同じ値を６ｂｉｔ以上送信しない）に違反し、他のノードからのエラーフレーム（セカンダリ）の送信を引き起こす。

エラーフラグ（セカンダリ）は、エラーの発生を他のノードに知らせるために使用される連続した６ビットのドミナントで構成される。エラーフラグ（プライマリ）を受信してビットスタッフィングルール違反を検知した全てのノードがエラーフラグ（セカンダリ）を送信することになる。

エラーデリミタ「ＤＥＬ」は、８ｂｉｔの連続したレセシブであり、エラーフレームの終了を示す。

［１．４ ＭＡＣ付与パターン例］
図４は、データフレームへのＭＡＣ付与に係るパターンの一例を示した図である。例えば、同図の左側から右側への順に各データフレームがバス２００上に順次送信される。ＭＡＣは送信内容の正当性を示すためにデータフレーム（メッセージ）に付与される。ここで、ＭＡＣ付与に係るパターンは、ＭＡＣを付与するか否か或いはＭＡＣの計算対象がどのフィールドであるかについて各種のバリエーションを有する。

図４での３つのデータフレームの例のうち、左側のデータフレーム４０１及び右側のデータフレーム４０３の例は、１フレームにＭＡＣと、ＭＡＣの計算対象となるデータ（つまりＭＡＣを算出するための計算に用いられるデータ）とを含んでいる。また中央のデータフレーム４０２の例は、ＭＡＣを含んでいない。ここでは、バスのトラフィック量の増加を抑えるため、或いは、計算量の削減のために、フレーム毎にＭＡＣを付与するか否か、ＭＡＣの計算対象となるデータは、データフィールドのみか、ＤＬＣフィールドを含むのかを切り替えている例を示しているが、これら以外のバリエーションもあり得る。例えば、全てのフレームにＭＡＣを付与しても良いし、ＩＤフィールドとＤＬＣフィールドとデータフィールドとの全てをＭＡＣの計算対象としても良いし、ＩＤフィールドとＤＬＣフィールドとデータフィールドとのうち、いずれかのフィールドを単独でＭＡＣの計算対象としても良く、それぞれの組み合わせを計算対象としても良く、これらのフィールドとその他のフィールドとの組み合わせを計算対象としても良い。

［１．５ ＥＣＵ１００ａの構成］
図５は、ＥＣＵ１００ａの構成図である。ＥＣＵ１００ａは、フレーム送受信部１０１と、フレーム解釈部１０２と、受信ＩＤ判断部１０３と、受信ＩＤリスト保持部１０４と、フレーム処理部１０５と、ＭＡＣ処理部１０６と、ＭＡＣ鍵保持部１０７と、カウンタ保持部１０８と、フレーム生成部１０９と、データ取得部１１０とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ＥＣＵ１００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。

フレーム送受信部１０１は、バス２００に対して、ＣＡＮのプロトコルに従ったフレームを送受信する。バス２００からフレームを１ｂｉｔずつ受信し、フレーム解釈部１０２に転送する。また、フレーム生成部１０９より通知を受けたフレームの内容をバス２００に送信する。

フレーム解釈部１０２は、フレーム送受信部１０１よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。ＩＤフィールドと判断した値は受信ＩＤ判断部１０３へ転送する。フレーム解釈部１０２は、受信ＩＤ判断部１０３から通知される判定結果に応じて、ＩＤフィールドの値と、ＩＤフィールド以降に現れるＤＬＣ、データフィールド等とを、フレーム処理部１０５へ転送するか、その判定結果を受けた以降においてフレームの受信を中止する（つまりそのフレームとしての解釈を中止する）かを決定する。また、フレーム解釈部１０２は、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部１０９へ通知する。また、フレーム解釈部１０２は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。

受信ＩＤ判断部１０３は、フレーム解釈部１０２から通知されるＩＤフィールドの値を受け取り、受信ＩＤリスト保持部１０４が保持しているメッセージＩＤのリストに従い、そのＩＤフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ＩＤ判断部１０３は、フレーム解釈部１０２へ通知する。

受信ＩＤリスト保持部１０４は、ＥＣＵ１００ａが受信するＩＤ（メッセージＩＤ）のリストである受信ＩＤリストを保持する。図６は、受信ＩＤリストの一例を示した図である。

フレーム処理部１０５は、フレーム解釈部１０２よりデータフィールドの値を受け取り、データフィールドに含まれる各種フラグ（後述するデータフィールドヘッダー、開始フラグ等といった、ＭＡＣを算出するための計算に用いるデータに関する識別子として機能し得るフラグ）に応じた処理を行う。この処理のうちには、ＭＡＣが付与されているデータについてのＭＡＣに係るデータの検証（つまりＭＡＣの検証処理）等が含まれ、また、データに応じた機能に係る処理も含まれ得る。即ち、フレーム処理部１０５は、フレーム送受信部１０１により１又は複数のデータフレームが受信された場合に、受信されたデータフレームの各種フラグ（識別子）に応じてＭＡＣの検証処理を行う検証部としての機能を有する。また、上述した機能に係る処理の一例を挙げると、エンジン３１０に接続されたＥＣＵ１００ａは、時速が３０ｋｍを超えた状態でドアが開いている状態だとアラーム音を鳴らす機能を有し、フレーム処理部１０５が、他のＥＣＵから受信したデータ（例えばドアの状態を示す情報）を管理し、エンジン３１０から取得された時速に基づいて一定条件下でアラーム音を鳴らす処理等を行う。なお、フレ―ムの送受信処理（データフレーム送信処理及びデータフレーム受信処理）に関する具体的な内容（処理フロー）については図１４、図１５及び図１６を用いて、後に説明する。なお、ここでは、データフレームのデータフィールドに各種フラグが含まれることとしているが、各種フラグは、拡張ＩＤフィールド等といった他のフィールドに含まれることとしても良い。

ＭＡＣ処理部１０６は、フレーム生成部１０９より通知される、ＭＡＣを計算するための値（これはＭＡＣの計算対象となるデータとしてフレームに含めて送信する値であり、例えばメッセージＩＤとＤＬＣの値とデータフィールド用のデータの値）と、カウンタ保持部１０８で保持する送信カウンタ値とを結合した値（結合値）に対し、ＭＡＣ鍵保持部１０７で保持するＭＡＣ鍵を用いて、ＭＡＣ値を算出（計算により導出）して、この算出した結果であるＭＡＣをフレーム生成部１０９へと通知する。即ち、ＭＡＣ処理部１０６は、１又は複数のフレーム内の１以上の領域に配置されるデータ（ＭＡＣの計算対象となるデータ）を用いた計算によりＭＡＣを算出する算出部として機能する。また、フレーム処理部１０５より通知される、受信したフレームに含まれる、ＭＡＣの計算対象となるデータと、カウンタ保持部１０８で保持する受信カウンタ値とを結合した値（結合値）に対して、ＭＡＣ鍵保持部１０７で保持する鍵を用いて、ＭＡＣ値を算出し、この算出した結果であるＭＡＣをフレーム処理部１０５へと通知する。ここではＭＡＣの計算方法として、ＨＭＡＣ（Hash-based Message Authentication Code)（非特許文献２参照）を採用し、上述した結合値に対し、所定のブロック分（例えば４ｂｙｔｅｓ）までパディングした値でＭＡＣ鍵を使って計算し、出てきた計算結果の先頭４ｂｙｔｅｓをＭＡＣとする。ここで、ＭＡＣを算出するために用いる結合値として、メッセージＩＤと、ＤＬＣの値と、データの値と、カウンタ保持部１０８で保持する送信カウンタ値、或いは、受信カウンタ値とを全て使用する例を記述したが、これらの値のいずれか１つ又は２つ以上の組み合わせを用いてＭＡＣが算出され得る。即ち、ＥＣＵ１００ａは、フレームの送信に際して、図４に例示したようなＭＡＣ付与に係るパターンを特定する、予め定められたアルゴリズムに基づいて、これらの値のいずれか１つ又は２つ以上の組み合わせを用いて、送信するフレームに含ませるためのＭＡＣを算出する。またＥＣＵ１００ａは、フレームの受信に際して、予め定められたアルゴリズムに基づいて、或いは、必要に応じてデータフィールドに含まれる各種フラグを参照して、検証に用いるＭＡＣの算出に必要となる値を特定することにより、ＭＡＣを算出する。

ＭＡＣ鍵保持部１０７は、ＭＡＣを計算するため必要となるＭＡＣ鍵を保持する。

カウンタ保持部１０８は、ＭＡＣを計算するために必要となるカウンタ値を保持する。なお、このカウンタ値は、例えばメッセージＩＤ毎に保持され、フレームを正常に送信した場合にインクリメントする送信カウンタ値と、正常に受信した場合にインクリメントする受信カウンタ値との２種類のカウンタ値がある。

フレーム生成部１０９は、フレーム解釈部１０２から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部１０１へ通知して送信させる。また、フレーム生成部１０９は、ＥＣＵ１００ａがＭＡＣを付与してデータの送信を行う際には、データ取得部１１０より通知されたデータの値と予め定められたメッセージＩＤとをＭＡＣ処理部１０６へ通知し、算出されたＭＡＣを受け取る。フレーム生成部１０９は、ＥＣＵ１００ａがＭＡＣを付与したデータの送信を行う際には、予め定められたメッセージＩＤとデータ取得部１１０より通知されたデータの値とＭＡＣ処理部１０６から受け取ったＭＡＣとを含むようにデータフレームをメモリ（送信バッファ）に構成し、フレーム送受信部１０１へ通知する。この送信のとき、フレーム送受信部１０１は、ＭＡＣを１又は複数のデータフレームのうちの少なくとも１つのデータフレームに含ませ、そのＭＡＣを算出するための計算に用いられたデータに関する各種フラグ（識別子等）を含ませたその１又は複数のデータフレームを送信する送信部として機能する。なお、フレーム生成部１０９が生成するデータフレームのデータフィールドの構成については、図７及び図８を用いて後に説明する。

データ取得部１１０は、ＥＣＵに接続されている機器、センサ等の状態を示すデータを取得し、フレーム生成部１０９に通知する。

なお、ＥＣＵ１００ｂ〜１００ｄも、上述したＥＣＵ１００ａと基本的に同様の構成を備える。但し、フレーム処理部１０５によるデータに応じた機能に係る処理の内容は、ＥＣＵ毎に異なる。また、例えば、ＥＣＵ１００ａのフレーム送受信部１０１が各種フラグを含ませたデータフレームを送信する送信部として機能するとき、ＥＣＵ１００ａと同じバス２００に接続されたＥＣＵ１００ｂ等のフレーム送受信部１０１は、送信された各種フラグを含む１又は複数のデータフレームを受信する受信部として機能する。

［１．６ 受信ＩＤリスト例］
図６は、ＥＣＵ１００ａ、ＥＣＵ１００ｂ、ＥＣＵ１００ｃ及びＥＣＵ１００ｄのそれぞれにおいて保持される受信ＩＤリストの一例を示す図である。同図に例示する受信ＩＤリストは、ＩＤ（メッセージＩＤ）の値が「１」、「２」、「３」及び「４」のいずれかであるメッセージＩＤを含むフレームを選択的に受信して処理するために用いられる。

［１．７ データフィールドフォーマット例１］
図７は、図４のＭＡＣ付与に係るパターンにより送信されるデータフレームのデータフィールドフォーマットの一例を示す。この例では、ＭＡＣを付与しないデータを内容とするデータフィールドの例を示している。このデータフィールドは、データフィールドヘッダー３０１と、開始フラグ３０２と、データサイズ３０３と、一般データ３０４とによって構成される。

データフィールドヘッダー３０１は、データフレームに含まれるデータの種別、ＭＡＣの計算対象となるデータの領域（フィールド種別）等を示す情報を含む。データフィールドヘッダー３０１のデータ構成については後に図９を用いて説明する。

開始フラグ３０２は、この開始フラグ以降のデータ（つまり開始フラグ以降に受信されることとなるデータ）の種別を識別するフラグである。開始フラグ３０２の内容例については図１２を用いて、後に説明する。

データサイズ３０３は、開始フラグ３０２により識別されるデータのサイズを示す。データサイズ３０３のデータ長は６ｂｉｔである。

一般データ３０４は、ＭＡＣの計算対象とならないデータ（つまりデータフィールドに格納されるデータのうちＭＡＣの計算対象となるデータでなくＭＡＣでもないデータ）の領域を示す。

［１．８ データフィールドフォーマット例２］
図８は、図４のＭＡＣ付与に係るパターンにより送信されるデータフレームのデータフィールドフォーマットの一例を示す。この例では、ＭＡＣの計算対象となるデータ及びＭＡＣを含んだデータフィールドの例を示している。このデータフィールドは、データフィールドヘッダー３０１と、開始フラグ３０２と、データサイズ３０３と、ＭＡＣ計算用データ３０５と、ＭＡＣ３０６とによって構成される。なお、図７と同一の要素には、同じ符号を付しており、ここでの説明を省略する。

ＭＡＣ計算用データ３０５は、ＭＡＣの計算対象となるデータの領域を示す。

ＭＡＣ３０６は、ＭＡＣの計算対象となるデータ等を用いた計算により算出されたＭＡＣが配置された領域を示す。

［１．９ データフィールドヘッダー３０１のデータ構成例］
図９は、データフィールドヘッダー３０１のデータ構成を示す。データフィールドヘッダー３０１は、フレーム生成部１０９によりデータフレームを送信する際にデータフィールドの先頭に設定される。

データフィールドヘッダー３０１は、予約ｂｉｔ３１１（２ｂｉｔ）と、ＭＡＣ計算対象フィールド種別３１２（３ｂｉｔ）と、データフィールド構成種別３１３（３ｂｉｔ）とによって構成され、全体で８ｂｉｔとなる。

予約ｂｉｔ３１１は、「００」の値で固定値である。

ＭＡＣ計算対象フィールド種別３１２と、データフィールド構成種別３１３に入る具体的なデータについては、以下、図１０、図１１を用いて説明する。

［１．１０ ＭＡＣ計算対象フィールド種別３１２］
図１０は、データフィールドヘッダー３０１に含まれる、ＭＡＣ計算対象フィールド種別３１２の内容例を示す。なお、同図で値は、３ｂｉｔ値（２進数）で表現している。

３ｂｉｔのＭＡＣ計算対象フィールド種別３１２の最上位ｂｉｔは、ＭＡＣの計算対象となるデータが配置されるフィールドとして、ＩＤフィールド（図２参照）が含まれるか否かを示し、ＩＤフィールドがＭＡＣの計算対象となる場合には「１」、ＩＤフィールドがＭＡＣの計算対象とならない場合には「０」となる。ＭＡＣ計算対象フィールド種別３１２の中位ｂｉｔは、ＭＡＣの計算対象となるデータが配置されるフィールドとして、ＤＬＣが含まれるか否かを示し、ＤＬＣがＭＡＣの計算対象となる場合には「１」、ＤＬＣがＭＡＣの計算対象とならない場合には「０」となる。また、ＭＡＣ計算対象フィールド種別３１２の最下位ｂｉｔは、ＭＡＣの計算対象となるデータが配置されるフィールドとして、データフィールドが含まれるか否かを示し、データフィールド内にＭＡＣの計算対象となるデータが含まれる場合には「１」、データフィールド内にＭＡＣの計算対象となるデータが含まれない場合には「０」となる。

［１．１１ データフィールド構成種別３１３］
図１１は、データフィールドヘッダー３０１に含まれる、データフィールド構成種別３１３の内容例を示す。なお、同図で値は、３ｂｉｔ値（２進数）で表現している。

３ｂｉｔのデータフィールド構成種別３１３の最上位ｂｉｔ（以下「ＭＡＣｂｉｔ」と称する）は、データフィールドがＭＡＣを含むか否かを示し、ＭＡＣを含む場合には「１」、ＭＡＣを含まない場合には「０」となる。データフィールド構成種別３１３の中位ｂｉｔ（以下「ＭＡＣ計算用データｂｉｔ」と称する）は、データフィールドがＭＡＣの計算対象となるデータを含むか否か（つまり図８に示したようなＭＡＣ計算用データ３０５を含むか否か）を示し、ＭＡＣの計算対象となるデータを含む場合には「１」、ＭＡＣの計算対象となるデータを含まない場合には「０」となる。送信されたデータフレームにおいてＭＡＣ計算用データｂｉｔは、そのデータフレーム内のデータフィールドに、ＭＡＣを算出するための計算に用いられたデータの領域が含まれるか否かを表すことになる。また、データフィールド構成種別３１３の最下位ｂｉｔ（以下「一般データｂｉｔ」と称する。）は、データフィールドがＭＡＣの計算対象とならない一般データを含むか否か（つまり図７に示したような一般データ３０４を含むか否か）を示し、一般データを含む場合には「１」、一般データを含まない場合には「０」となる。なお、図１１では、便宜上、このようなＭＡＣｂｉｔ、ＭＡＣ計算用データｂｉｔ及び一般データｂｉｔを組み合わせた３ｂｉｔの値で表現され得る全てのパターンの内容例を示している。このため、図１１の内容例の一部の値（「ＭＡＣ計算用データのみ」及び「一般データ＋ＭＡＣ計算用データ」）は後述する実施の形態２では用いられ得るが、実施の形態１では用いられない。

［１．１２ 開始フラグ３０２］
図１２は、データフィールドに含まれるデータの開始位置と種別を示す、開始フラグ３０２の内容例を示す。開始フラグ３０２は、フレーム生成部１０９によりデータフレームを送信する際にデータフィールド内に設定される。開始フラグ３０２が設定される位置は、例えば、データフィールドヘッダー３０１に後続する位置、或いは、データフィールド内に配置されたデータ（一般データ、ＭＡＣの計算対象となるデータ或いはＭＡＣ）に後続する位置である（図７及び図８参照）。

開始フラグ３０２は、２ｂｉｔで構成され、この開始フラグ３０２に後続するデータサイズ３０３（図７及び図８参照）に続くデータの種別を示す。

開始フラグ３０２に後続するデータサイズ３０３に続くデータが、ＭＡＣの計算対象とならないデータである一般データの場合には開始フラグ３０２の値として「００」（２ｂｉｔ値）が設定される。開始フラグ３０２に後続するデータサイズ３０３に続くデータが、ＭＡＣの計算対象となるデータ（ＭＡＣ計算用データ）の場合には開始フラグ３０２の値として「０１」（２ｂｉｔ値）が設定される。送信されたデータフレームにおいて、「０１」（２ｂｉｔ値）の開始フラグ３０２及び後続するデータサイズ３０３により、ＭＡＣを算出するための計算に用いられたデータの領域が表されることになる。開始フラグ３０２に後続するデータサイズ３０３に続くデータが、ＭＡＣの場合には開始フラグ３０２の値として「１０」（２ｂｉｔ値）が設定される。

［１．１３ エンジンに係るＥＣＵ１００ａの送信フレーム例］
図１３は、エンジン３１０に接続されたＥＣＵ１００ａから送信されるデータフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールドの内容（データ）の一例を示す図である。ＥＣＵ１００ａが送信するフレームのメッセージＩＤは「１」である。データフィールドの内容（データ）は、同図において１ｂｙｔｅ毎に空白で区分して１６進数で表している。図１３の例で各行の先頭の１ｂｙｔｅはデータフィールドヘッダー３０１であり、次（２番目）の１ｂｙｔｅは開始フラグ３０２及びデータサイズ３０３であり、次（３番目）の１ｂｙｔｅは時速（ｋｍ／時）を表したＭＡＣ計算用データ３０５（２行目のみ一般データ３０４）であり、図１３の例の１行目及び３行目での次（４番目）の１ｂｙｔｅは開始フラグ３０２及びデータサイズ３０３であり、その次の４ｂｙｔｅｓがＭＡＣ３０６である。時速（ｋｍ／時）は、最低０（ｋｍ／時）〜最高１８０（ｋｍ／時）までの範囲の値を取る。図１３の上行から下行へと、図４で例示したＭＡＣ付与に係るパターンに従って、ＥＣＵ１００ａから逐次送信される各フレームに対応する各メッセージＩＤ及びデータフィールドの内容（データ）を例示しており、時速が０ｋｍ／時から１ｋｍ／時ずつ加速されている様子を表している。

［１．１４ データフレーム送信処理］
図１４は、ＥＣＵ１００ａにより実行されるデータフレーム送信処理を示すフローチャートである。以下、同図に即して、ＥＣＵ１００ａにおけるデータフレーム送信処理について説明する。なお、ＥＣＵ１００ｂ〜１００ｄも、送信するデータフレームの内容はそれぞれ異なるものの、ＥＣＵ１００ａと同様のデータフレーム送信処理を行う。ＥＣＵ１００ａにおいて、データフレーム送信処理は定期的に行われる。

ＥＣＵ１００ａは、エンジン３１０の状態を取得し、その状態を表すデータ（送信すべきデータ）を特定すると、フレーム生成部１０９にデータフレーム生成処理を開始させる（ステップＳ１００１）。逐次取得される送信すべきデータが、どのようなデータ構成のデータフレームによるどのようなフレーム編成で逐次送信されるかについては、車載ネットワークシステム１０として予め定められた所定アルゴリズムに従って決定される。フレーム編成及びデータ構成を定める所定アルゴリズムの例としては、上述した図４の例のように、例えば３回分の送信を１セットとして１回目に送信するデータフレーム４０１のデータフィールド内に、時速を表したＭＡＣ計算用データ３０５と、ＭＡＣ計算用データ３０５を用いた計算により算出されたＭＡＣとを含ませ、２回目に送信するデータフレーム４０２のデータフィールド内に、時速を表した一般データ３０４を含ませ、３回目に、送信するデータフレーム４０３のデータフィールド内に時速を表したＭＡＣ計算用データ３０５と、ＤＬＣ及びＭＡＣ計算用データ３０５を用いた計算により算出されたＭＡＣとを含ませて送信するアルゴリズム等がある。

データフレーム生成処理として、フレーム生成部１０９は、メモリ（送信バッファ）内に定めたデータフレームにおけるデータフィールドのデータフィールドヘッダー３０１内のＭＡＣ計算対象フィールド種別３１２の該当箇所に、所定アルゴリズムに基づいて決定された送信すべきデータの構成を表す値を設定する（ステップＳ１００２）。例えば、上述の３回分の送信の１セット（図４参照）における３回目に送信されるデータフレーム４０３においては、ＭＡＣ計算対象フィールド種別３１２（３ｂｉｔ）は、ＤＬＣとデータフィールドとに対応するｂｉｔがそれぞれ「１」に設定される。

ＥＣＵ１００ａのフレーム生成部１０９は、送信すべきデータを含む送信すべきデータフレームが、一般データ３０４（つまりＭＡＣの計算対象とならないデータ）を含むフレームか否かを判断する（ステップＳ１００３）。一般データ３０４を含まない場合は、一般データ関連の処理（ステップＳ１００４〜Ｓ１００７）をスキップする。

ステップＳ１００３において送信すべきデータフレームが一般データ３０４を含むと判断した場合には、フレーム生成部１０９は、送信バッファ内に定めたデータフレームにおけるデータフィールドヘッダー３０１内のデータフィールド構成種別３１３の一般データｂｉｔに「１」を設定する（ステップＳ１００４）。

続いてフレーム生成部１０９は、送信バッファ内に定めたデータフレームにおけるデータフィールド内に、開始フラグ３０２として、一般データを示す「００」（２ｂｉｔ値）を設定し（ステップＳ１００５）、データサイズ３０３として一般データ３０４のサイズに応じた値を設定し（ステップＳ１００６）、一般データ３０４を設定する（ステップＳ１００７）。

また、フレーム生成部１０９は、送信すべきデータを含む送信すべきデータフレームが、ＭＡＣ計算用データ３０５（つまりＭＡＣの計算対象となるデータ）を含むフレームか否かを判断する（ステップＳ１００８）。ＭＡＣ計算用データ３０５を含まない場合は、ＭＡＣ計算用データ関連の処理（ステップＳ１００９〜Ｓ１０１２）をスキップする。

ステップＳ１００８において送信すべきデータフレームがＭＡＣ計算用データ３０５を含むと判断した場合には、フレーム生成部１０９は、送信バッファ内に定めたデータフレームにおけるデータフィールドヘッダー３０１内のデータフィールド構成種別３１３のＭＡＣ計算用データｂｉｔに「１」を設定する（ステップＳ１００９）。

続いてフレーム生成部１０９は、送信バッファ内に定めたデータフレームにおけるデータフィールド内に、開始フラグ３０２として、ＭＡＣ計算用データを示す「０１」（２ｂｉｔ値）を設定し（ステップＳ１０１０）、データサイズ３０３としてＭＡＣ計算用データ３０５のサイズに応じた値を設定し（ステップＳ１０１１）、ＭＡＣ計算用データ３０５を設定する（ステップＳ１０１２）。

また、フレーム生成部１０９は、送信すべきデータを含む送信すべきデータフレームが、ＭＡＣ３０６を含むフレームか否かを判断する（ステップＳ１０１３）。ＭＡＣ３０６を含まない場合は、ＭＡＣ関連の処理（ステップＳ１０１４〜Ｓ１０１８）をスキップする。

ステップＳ１０１３において送信すべきデータフレームがＭＡＣ３０６を含むと判断した場合には、フレーム生成部１０９は、送信バッファ内に定めたデータフレームにおけるデータフィールドヘッダー３０１内のデータフィールド構成種別３１３のＭＡＣｂｉｔに「１」を設定する（ステップＳ１０１４）。

続いてフレーム生成部１０９は、ＭＡＣの計算対象となるデータとして所定アルゴリズムに基づいて定められたデータ（つまりＭＡＣ計算対象フィールド種別３１２に設定した値に基づくデータ）をＭＡＣ処理部１０６に伝え、ＭＡＣ処理部１０６はＭＡＣを算出する（ステップＳ１０１５）。ＭＡＣ処理部１０６は、フレーム生成部１０９に伝えられたＭＡＣの計算対象となるデータと、カウンタ保持部１０８で保持する送信カウンタ値とを結合した値に対し、ＭＡＣ鍵保持部１０７で保持するＭＡＣ鍵を用いて計算を行うことにより、送信すべきデータフレームにＭＡＣ３０６として設定されるＭＡＣ値を算出する。

続いてフレーム生成部１０９は、送信バッファ内に定めたデータフレームにおけるデータフィールド内に、開始フラグ３０２として、ＭＡＣを示す「１０」（２ｂｉｔ値）を設定し（ステップＳ１０１６）、データサイズ３０３としてＭＡＣ３０６のサイズに応じた値を設定し（ステップＳ１０１７）、ＭＡＣ３０６を設定する（ステップＳ１０１８）。

ステップＳ１０１８での処理が終了する、或いは、ＭＡＣ関連の処理がスキップされた場合に、フレーム生成部１０９は、送信すべきデータフレームを生成するためのデータフレーム生成処理を終えることとなり、フレーム送受信部１０１へ通知する（ステップＳ１０１９）。

フレーム送受信部１０１は、フレーム生成部１０９により送信バッファに生成されたデータフレームを、バス２００に送信する（ステップＳ１０２０）。フレームが正常に送信された場合に、送信カウンタ値がインクリメント（１増加）される（ステップＳ１０２１）。

［１．１５ データフレーム受信処理］
図１５及び図１６は、ＥＣＵ１００ｂにより実行されるデータフレーム受信処理を示すフローチャートである。以下、同図に即して、ＥＣＵ１００ｂにおけるデータフレーム受信処理について説明する。なお、ＥＣＵ１００ａ、１００ｃ、１００ｄも、ＥＣＵ１００ｂと同様のデータフレーム受信処理を行う。

バス２００上にフレームが送信された場合に、ＥＣＵ１００ｂにおいてデータフレーム受信処理が開始される。

ＥＣＵ１００ｂは、ＣＡＮプロトコルに従って、バス２００から１ｂｉｔずつ受信し、データフレームにおけるＩＤ等を受信して処理した後にデータフィールドを受信することになる。このとき、フレーム解釈部１０２は、ＩＤ、ＤＬＣ、データフィールド等をフレーム処理部１０５へ転送し、フレーム処理部１０５は、データフィールドに関連するデータ処理を開始する（ステップＳ１１０１）。

ＥＣＵ１００ｂのフレーム処理部１０５は、受信されたデータフレームのデータフィールドにおけるデータフィールドヘッダー３０１を取得し、作業用のメモリ領域としてのバッファに保存する（ステップＳ１１０２）。また、データフィールドにおける開始フラグ３０２を取得し、バッファに格納する（ステップＳ１１０３）。

続いて、フレーム処理部１０５は、取得した開始フラグ３０２の値が、一般データ３０４を表す「００」（２ｂｉｔ）か、ＭＡＣ計算用データ３０５を表す「０１」（２ｂｉｔ）かそれ以外（ＭＡＣを表すもの）かを判定する（ステップＳ１１０４、Ｓ１１０５）。

次に、フレーム処理部１０５は、開始フラグ３０２に後続するデータサイズ３０３を取得し、サイズに応じてバッファを確保する（ステップＳ１１０６ａ、Ｓ１１０６ｂ或いはＳ１１０６ｃ）。続いて、開始フラグ３０２が、一般データ３０４を表していた場合には、一般データ３０４を取得して、確保したバッファに格納し（ステップＳ１１０７）、ＭＡＣ計算用データ３０５を表していた場合には、ＭＡＣ計算用データ３０５を取得して、確保したバッファに格納（ステップＳ１１０８）、その他の場合には、ＭＡＣ３０６を取得して、確保したバッファに格納する（ステップＳ１１０９）。

フレーム処理部１０５は、ＤＬＣ及びデータフィールドに基づいて、受信したデータフィールドの全てのデータを取得し終えたかどうかを判定して、上述したステップＳ１１０３〜Ｓ１１０９の処理を、データフィールドの全てのデータを取得し終えるまで繰り返す（ステップＳ１１１０）。

データフィールドのデータを全て取得し終えた場合には、フレーム処理部１０５は、データフィールドヘッダー３０１に含まれるデータフィールド構成種別３１３に基づき、受信されたデータフレームの構成を確認する（ステップＳ１１１１）。一般データ３０４のみを含むフレーム（つまりデータフィールド構成種別３１３の一般データｂｉｔが「１」であり他の２ｂｉｔが「０」であるデータフレーム）であると判断した場合には（ステップＳ１１１２）、フレーム処理部１０５は、受信したデータの内容に応じて、予め定められた処理（データに応じた機能に係る処理）を行う（ステップＳ１１１３）。

受信されたデータフレームが一般データ３０４のみを含むフレームではない場合においては、フレーム処理部１０５は、データフィールドヘッダー３０１に含まれる、ＭＡＣ計算対象フィールド種別３１２を確認する（ステップＳ１１１４）。続いてフレーム処理部１０５は、確認されたＭＡＣ計算対象フィールド種別３１２に応じてＭＡＣの計算対象となるデータを格納した各フィールドの値を取得することで、ＭＡＣの検証に必要なデータを収集する（ステップＳ１１１５）。

フレーム処理部１０５は、収集したＭＡＣの検証に必要なデータをＭＡＣ処理部１０６に通知して得られるＭＡＣ値によりＭＡＣの検証処理を行い、検証に成功した場合には（ステップＳ１１１６）、受信したデータの内容に応じて、予め定められた処理（データに応じた機能に係る処理）を行う（ステップＳ１１１７）。なお、ＭＡＣ処理部１０６は、フレーム処理部１０５から取得したデータ（ＭＡＣの計算対象となるデータ）と、カウンタ保持部１０８で保持する受信カウンタ値とを結合した値に対して、ＭＡＣ鍵保持部１０７で保持する鍵を用いて計算を行うことによりＭＡＣ値を算出し、この算出した結果であるＭＡＣをフレーム処理部１０５へと通知する。そして、フレーム処理部１０５では、受信したデータフレームのデータフィールドにおけるＭＡＣ３０６の値が、ＭＡＣ処理部１０６により算出されたＭＡＣと一致するか否かを判定することによりＭＡＣの検証を行う。一致すれば、検証に成功し、一致しなければ検証に失敗することになる。

ステップＳ１１１６において、検証に成功しなかった場合には、フレーム処理部１０５は、受信したデータフレームのデータフィールドのデータに応じた機能に係る処理（ステップＳ１１１７）をスキップする。

ステップＳ１１１７での処理が終了した場合、或いは、スキップされた場合に、フレーム処理部１０５は、バッファを全てクリアし（ステップＳ１１１８）、受信カウンタ値をインクリメント（１増加）する（ステップＳ１１１９）。

［１．１６ 実施の形態１の効果］
実施の形態１で示した車載ネットワークシステム１０では、複数のＥＣＵ間で送受信するデータフレームのデータフィールド内に、ＭＡＣを算出するための計算に用いるデータに関する識別子として機能し得るデータフィールドヘッダー３０１、開始フラグ３０２等を含ませることにより、データフィールドに格納するデータの構成を自由に定めることを可能にした。これにより、例えばＭＡＣをデータフィールドに格納するデータフレーム及びＭＡＣをデータフィールドに格納しないデータフレームを混在させて送信すること等も可能になり、一律にＭＡＣをデータフレームに格納する場合と比べればバスのトラフィック量の増加を抑制することが可能になる。なお、ＭＡＣ３０６を付加したＭＡＣ計算用データ３０５を含むデータフレームと、ＭＡＣを付ける必要がない一般データ３０４を含むデータフレームとが同一のＩＤ（メッセージＩＤ）のフレームとして送信される場合においても、データフィールドヘッダー３０１、開始フラグ３０２等により、ＭＡＣ計算用データ３０５と一般データ３０４とを確実に識別できるため、誤って一般データ３０４等に対するＭＡＣの検証処理を行うこと等が防止される。

（実施の形態２）
以下、本開示の実施の形態として、ＭＡＣを用いたデータの検証を可能にし、かつ、データの効率的な送受信を可能にするための送信方法或いは受信方法を実現するＥＣＵを含む車載ネットワークシステム（以下、「車載ネットワークシステム１１」と称する）について、図面を参照しながら説明する。

車載ネットワークシステム１１は、実施の形態１で説明した車載ネットワークシステム１０を一部変形したものであり、ここで特に説明しない点は車載ネットワークシステム１０と同様である。車載ネットワークシステム１０においては、ＭＡＣを含むデータフレームにおいてそのＭＡＣは、そのデータフレーム内のいずれかのフィールドのデータを用いた計算により算出されたものであり、そのデータを用いて検証されるものであることとした。これに対し、実施の形態２で示す車載ネットワークシステム１１では、ＭＡＣの計算対象となるデータ（つまりＭＡＣを算出するための計算に用いられるデータ）がそのＭＡＣとは別のデータフレームに含まれ得るように、データフレームのデータ構成及びデータフレームの編成についての自由度を拡大している。

［２．１ 車載ネットワークシステム１１の全体構成］
車載ネットワークシステム１１の全体構成は、基本的に実施の形態１に係る車載ネットワークシステム１０の全体構成と同じ（図１参照）であり、バス２００と、各種機器に接続されたＥＣＵ２１００ａ〜２１００ｄといったバス２００に接続された各ノードとを含んで構成される。なお、ＥＣＵ２１００ａ〜２１００ｄは、それぞれ実施の形態１で示したＥＣＵ１００ａ〜１００ｄのそれぞれ（図１参照）を一部変形したＥＣＵのことを言う。ＥＣＵ２１００ａ〜２１００ｄは、それぞれ、エンジン３１０、ブレーキ３２０、ドア開閉センサ３３０、窓開閉センサ３４０と接続されている。ＥＣＵ２１００ａ〜２１００ｄは、複数のフレームに亘って、データフィールドに格納されて送信される、ＭＡＣの検証が必要なデータと、ＭＡＣの検証が不要なデータと、ＭＡＣと、ＭＡＣの計算対象となるデータを特定するための識別子とに応じて、実行するフレームの処理内容を変更し得る。

この車載ネットワークシステム１１においてもＣＡＮプロトコルに従って各ＥＣＵがフレームの授受を行う。

［２．２ ＭＡＣ付与パターン例］
図１７は、データフレームへのＭＡＣ付与に係るパターンの一例を示した図である。例えば、同図の左側から右側への順に各データフレームがバス２００上に順次送信される。ここで、ＭＡＣ付与に係るパターンは、ＭＡＣを付与するか否か或いはＭＡＣの計算対象がどのフレームのどのフィールドであるかについて各種のバリエーションを有する。図１７での３つのデータフレームの例のうち、中央のデータフレーム５０２の例はＭＡＣを含んでいない。また、図１７の例では、２つ以上のフレームに含まれるデータフィールドの値からＭＡＣを計算し、分割し、分割したＭＡＣそれぞれを計算対象となったデータのいずれかと同じフレームに格納して送信する例を示している。即ち、左側のデータフレーム５０１のデータフィールドと、右側のデータフレーム５０３のＤＬＣ及びデータフィールドとに基づいてＭＡＣを計算し、そのＭＡＣの一部を左側のデータフレーム５０１に格納して送信し、そのＭＡＣの他の一部を右側のデータフレーム５０３に格納して送信する例を示している。

ここでは、バスのトラフィック量の増加を抑えるため、或いは、計算量の削減のために、フレーム毎にＭＡＣを付与するか否か、ＭＡＣの計算対象となるデータは、データフィールドのみか、ＤＬＣフィールドを含むのかを切り替えている例を示しているが、これら以外のバリエーションもあり得る。例えば、全てのフレームにＭＡＣを付与しても良いし、ＩＤフィールドとＤＬＣフィールドとデータフィールドとの全てをＭＡＣの計算対象としても良いし、ＩＤフィールドとＤＬＣフィールドとデータフィールドとのうち、いずれかのフィールドを単独でＭＡＣの計算対象としても良く、それぞれの組み合わせを計算対象としても良く、これらのフィールドとその他のフィールドとの組み合わせを計算対象としても良い。

［２．３ ＥＣＵ２１００ａの構成］
図１８は、ＥＣＵ２１００ａの構成図である。ＥＣＵ２１００ａは、フレーム送受信部１０１と、フレーム解釈部１０２と、受信ＩＤ判断部１０３と、受信ＩＤリスト保持部１０４と、フレーム処理部２１０５と、ＭＡＣ処理部１０６と、ＭＡＣ鍵保持部１０７と、カウンタ保持部１０８と、フレーム生成部２１０９と、データ取得部１１０とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ＥＣＵ２１００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。なお、ＥＣＵ２１００ｂ〜２１００ｄも同様の構成である。また、実施の形態１（図５参照）で示したものと同一の構成要素については、同じ符号を付しており、説明を省略する。

フレーム処理部２１０５は、フレーム処理部１０５の一部を変形したものであり、フレーム解釈部１０２よりデータフィールドの値を受け取り、データフィールドに含まれる各種フラグ（データフィールドヘッダー、開始フラグ等といったＭＡＣを算出するための計算に用いるデータに関する識別子として機能し得るフラグ）に応じた処理を行う。この処理のうちには、ＭＡＣが付与されているデータについてのＭＡＣに係るデータの検証（つまりＭＡＣの検証処理）等が含まれ、また、実施の形態１で示した、データに応じた機能に係る処理も含まれ得る。なお、フレ―ムの送受信処理（データフレーム送信処理及びデータフレーム受信処理）に関する具体的な内容（処理フロー）については図２２〜図２５を用いて、後に説明する。なお、ここでは、データフレームのデータフィールドに各種フラグが含まれることとしているが、各種フラグは、拡張ＩＤフィールド等といった他のフィールドに含まれることとしても良い。

フレーム生成部２１０９は、フレーム生成部１０９の一部を変形したものであり、フレーム解釈部１０２から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部１０１へ通知して送信させる。また、フレーム生成部２１０９は、ＥＣＵ２１００ａがＭＡＣを付与してデータの送信を行う際には、データ取得部１１０より通知されたデータの値と予め定められたメッセージＩＤとをＭＡＣ処理部１０６へ通知し、算出されたＭＡＣを受け取る。フレーム生成部２１０９は、ＥＣＵ２１００ａがＭＡＣを付与したデータの送信を行う際には、予め定められたメッセージＩＤとデータ取得部１１０より通知されたデータの値とＭＡＣ処理部１０６から受け取ったＭＡＣとを含むようにデータフレームをメモリ（送信バッファ）に構成し、フレーム送受信部１０１へ通知する。フレーム生成部２１０９が生成するデータフレームのデータフィールドの構成については、図１９及び図２０を用いて後に説明する。

［２．４ データフィールドフォーマット］
車載ネットワークシステム１１においてＥＣＵに送信されるデータフレームのデータフィールドフォーマットは、基本的に実施の形態１で示した車載ネットワークシステム１０で用いられるものと同様である（図７及び図８参照）。但し、データフィールドヘッダー３０１を、データフィールドヘッダー２３０１へと置き換えている。

［２．５ データフィールドヘッダー２３０１のデータ構成例］
図１９は、データフィールドヘッダー２３０１のデータ構成を示す。データフィールドヘッダー２３０１は、フレーム生成部２１０９によりデータフレームを送信する際にデータフィールドの先頭に設定される。

データフィールドヘッダー２３０１は、フレーム特性データ２３１１（１８ｂｉｔ）と、ＭＡＣ計算対象フィールド種別３１２（３ｂｉｔ）と、データフィールド構成種別３１３（３ｂｉｔ）とによって構成され、全体で２４ｂｉｔとなる。

ＭＡＣ計算対象フィールド種別３１２と、データフィールド構成種別３１３とについては、実施の形態１と同様であるため、ここでは説明を省略する（図１０及び図１１参照）。

［２．６ フレーム特性データ２３１１のデータ構成例］
図２０は、データフィールドヘッダー２３０１に含まれる、フレーム特性データ２３１１のデータ構成を示す。

フレーム特性データ２３１１は、フレーム番号（フレームＮｏ．）２３２１と、総フレーム数２３２２と、ＭＡＣ計算用データを含むフレーム数２３２３と、ＭＡＣを含むフレーム数２３２４とによって構成され、全体で１８ｂｉｔとなる。

フレームＮｏ．２３２１は、送信すべきデータが複数のデータフレームに分割されて送信されるときのその一連のデータフレームのグループを他のグループと識別するための値であり、６ｂｉｔで表現する。フレームＮｏ．２３２１は、送信すべきデータが分割されて形成された一連のデータフレームのグループに属する各データフレームは、同じ値となり、別のグループに属するデータフレームではまた別の値となるようにデータフレームを送信するＥＣＵにより付与される。フレームＮｏ．の値の定め方は、例えば連番にして、１グループのデータフレーム群を送信する毎に値をカウントアップすることとしても良いし、１グループのデータフレームを送信すべきときにランダムに値を生成することとしても良い。なお、ＭＡＣ計算用データを含まずＭＡＣも含まず一般データのみを含むデータフレームにおいては、フレームＮｏ．をゼロ等として、例外的に扱うこととしても良い。以下、一般データのみを含むデータフレームにおいてはフレームＮｏ．をゼロにした例を適宜用いて説明する。

総フレーム数２３２２は、複数に分割されて形成された一連のデータフレームのグループにおけるデータフレームの数を示す値であり、４ｂｉｔで表現する。ＭＡＣ計算用データを含むフレーム数２３２３は、その一連のデータフレームのグループにおけるＭＡＣ計算用データが含まれるフレーム数を示す値であり、４ｂｉｔで表現する。また、ＭＡＣを含むフレーム数２３２４は、総フレーム数内でＭＡＣが含まれるフレーム数を示す値であり、４ｂｉｔで表現する。

［２．７ エンジンに係るＥＣＵ２１００ａの送信フレーム例］
図２１は、エンジン３１０に接続されたＥＣＵ２１００ａから送信されるデータフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールドの内容（データ）の一例を示す図である。ＥＣＵ２１００ａが送信するフレームのメッセージＩＤは「１」である。データフィールドの内容（データ）は、同図において１ｂｙｔｅ毎に空白で区分して１６進数で表している。図２１の例で各行の先頭の３ｂｙｔｅｓはデータフィールドヘッダー２３０１であり、次（４ｂｙｔｅ目）の１ｂｙｔｅは開始フラグ３０２及びデータサイズ３０３であり、次（５ｂｙｔｅ目）の１ｂｙｔｅは時速（ｋｍ／時）を表したＭＡＣ計算用データ３０５（２行目のみ一般データ３０４）であり、図２１の例の１行目及び３行目での次の１ｂｙｔｅ（６ｂｙｔｅ目）は開始フラグ３０２及びデータサイズ３０３であり、その次（７ｂｙｔｅ目）の２ｂｙｔｅｓがＭＡＣ３０６である。時速（ｋｍ／時）は、最低０（ｋｍ／時）〜最高１８０（ｋｍ／時）までの範囲の値を取る。図２１の上行から下行へと、図１７で例示したＭＡＣ付与に係るパターンに従って、ＥＣＵ２１００ａから逐次送信される各フレームに対応する各メッセージＩＤ及びデータフィールドの内容（データ）を例示しており、時速が０ｋｍ／時から１ｋｍ／時ずつ加速されている様子を表している。

［２．８ データフレーム送信処理］
図２２は、ＥＣＵ２１００ａにより実行されるデータフレーム送信処理を示すフローチャートである。以下、同図に即して、ＥＣＵ２１００ａにおけるデータフレーム送信処理について説明する。なお、実施の形態１に係るＥＣＵ１００ａによるデータフレーム送信処理（図１４）と同様な処理手順（ステップ）には、図２２で同じ符号を付しており、これらについては説明を適宜簡略化する。また、ＥＣＵ２１００ｂ〜２１００ｄも、送信するデータフレームの内容はそれぞれ異なるものの、ＥＣＵ２１００ａと同様のデータフレーム送信処理を行う。ＥＣＵ２１００ａにおいて、データフレーム送信処理は定期的に行われる。

ＥＣＵ２１００ａは、送信すべきデータを特定して、フレーム生成部１０９にデータフレーム生成処理を開始させる（ステップＳ１００１）。逐次取得される送信すべきデータが、どのようなデータ構成のデータフレームによるどのようなフレーム編成で逐次送信されるかについては、車載ネットワークシステム１１として予め定められた所定アルゴリズムに従って決定される。フレーム編成及びデータ構成を定める所定アルゴリズムの例としては、上述した図１７の例のように、例えば３回分の送信を１セットとして、そのうち１回目に送信するデータフレーム５０１と３回目に送信するデータフレーム５０３とを同じグループとし、１回目に送信するデータフレーム５０１のデータフィールド内に、時速を表したＭＡＣ計算用データ３０５と、このデータフレーム５０１及び他のデータフレーム５０３のＭＡＣ計算用データ３０５並びに他のデータフレーム５０３のＤＬＣを用いた計算により、算出されたＭＡＣの一部（例えば前半２ｂｙｔｅｓ）とを含ませ、２回目に送信するデータフレーム５０２のデータフィールド内に、時速を表した一般データ３０４を含ませ、３回目に、送信するデータフレーム５０３のデータフィールド内に時速を表したＭＡＣ計算用データ３０５と、上述のＭＡＣの残りの一部（例えば後半２ｂｙｔｅｓ）とを含ませて送信するアルゴリズム等がある。

データフレーム生成処理として、フレーム生成部２１０９は、送信バッファ内に定めたデータフレームにおけるデータフィールドのデータフィールドヘッダー２３０１内のＭＡＣ計算対象フィールド種別３１２の該当箇所に、所定アルゴリズムに基づいて決定された送信すべきデータの構成を表す値を設定する（ステップＳ１００２）。

続いてＥＣＵ２１００ａは、送信すべきデータを、複数のデータフレームに分けて送信するために所定アルゴリズムに従って定められるフレーム数（Ｎ）に分割する（ステップＳ２００１）。即ち、送信すべきデータの分割位置を特定する。

次にＥＣＵ２１００ａは、所定アルゴリズムに従って送信すべきデータに応じて、Ｎフレーム分、各データフレームに順次着目して、データフレームについてのデータの設定（ステップＳ１００３〜Ｓ１０１８）を、繰り返し行う（ステップＳ２００２）。

即ち、ＥＣＵ２１００ａのフレーム生成部２１０９は、送信すべきデータを含む送信すべきデータフレーム（着目したデータフレーム）が、一般データ３０４を含むフレームか否かを判断する（ステップＳ１００３）。一般データ３０４を含まない場合は、一般データ関連の処理（ステップＳ１００４〜Ｓ１００７）をスキップする。ステップＳ１００３において送信すべきデータフレームが一般データ３０４を含むと判断した場合には、フレーム生成部２１０９は、送信バッファ内に定めたデータフレームにおけるデータフィールドヘッダー２３０１内のデータフィールド構成種別３１３の一般データｂｉｔに「１」を設定する（ステップＳ１００４）。続いてフレーム生成部２１０９は、送信バッファ内に定めたデータフレームにおけるデータフィールド内に、開始フラグ３０２として一般データを示す値を設定し（ステップＳ１００５）、データサイズ３０３として一般データ３０４のサイズに応じた値を設定し（ステップＳ１００６）、一般データ３０４を設定する（ステップＳ１００７）。

また、フレーム生成部２１０９は、送信すべきデータを含む送信すべきデータフレーム（着目したデータフレーム）が、ＭＡＣ計算用データ３０５を含むフレームか否かを判断する（ステップＳ１００８）。ＭＡＣ計算用データ３０５を含まない場合は、ＭＡＣ計算用データ関連の処理（ステップＳ１００９〜Ｓ１０１２）をスキップする。ステップＳ１００８において送信すべきデータフレームがＭＡＣ計算用データ３０５を含むと判断した場合には、フレーム生成部２１０９は、送信バッファ内に定めたデータフレームにおけるデータフィールドヘッダー２３０１内のデータフィールド構成種別３１３のＭＡＣ計算用データｂｉｔに「１」を設定する（ステップＳ１００９）。続いてフレーム生成部２１０９は、送信バッファ内に定めたデータフレームにおけるデータフィールド内に、開始フラグ３０２として、ＭＡＣ計算用データを示す値を設定し（ステップＳ１０１０）、データサイズ３０３としてＭＡＣ計算用データ３０５のサイズに応じた値を設定し（ステップＳ１０１１）、ＭＡＣ計算用データ３０５を設定する（ステップＳ１０１２）。

また、フレーム生成部２１０９は、送信すべきデータを含む送信すべきデータフレーム（着目したデータフレーム）が、ＭＡＣ３０６を含むフレームか否かを判断する（ステップＳ１０１３）。ＭＡＣ３０６を含まない場合は、ＭＡＣ関連の処理（ステップＳ１０１４〜Ｓ１０１８）をスキップする。ステップＳ１０１３において送信すべきデータフレームがＭＡＣ３０６を含むと判断した場合には、フレーム生成部２１０９は、送信バッファ内に定めたデータフレームにおけるデータフィールドヘッダー２３０１内のデータフィールド構成種別３１３のＭＡＣｂｉｔに「１」を設定する（ステップＳ１０１４）。

続いてフレーム生成部２１０９は、ＭＡＣの計算対象となるデータとして所定アルゴリズムに基づいて定められたデータ（つまりＭＡＣ計算対象フィールド種別３１２に設定した値に基づくデータ）をＭＡＣ処理部１０６に伝え、ＭＡＣ処理部１０６はＭＡＣを算出する（ステップＳ１０１５）。ＭＡＣ処理部１０６は、フレーム生成部２１０９に伝えられたＭＡＣの計算対象となるデータと、カウンタ保持部１０８で保持する送信カウンタ値とを結合した値に対し、ＭＡＣ鍵保持部１０７で保持するＭＡＣ鍵を用いて計算を行うことにより、送信すべきデータフレームにＭＡＣ３０６として設定されるＭＡＣ値を算出する。続いてフレーム生成部２１０９は、送信バッファ内に定めたデータフレームにおけるデータフィールド内に、開始フラグ３０２として、ＭＡＣを示す値を設定し（ステップＳ１０１６）、データサイズ３０３としてＭＡＣ３０６のサイズに応じた値を設定し（ステップＳ１０１７）、ＭＡＣ３０６を設定する（ステップＳ１０１８）。所定アルゴリズムが、ＭＡＣを分割して送信することを定めている場合には、このステップＳ１０１８でフレーム生成部２１０９は、ＭＡＣ処理部１０６に算出されたＭＡＣ値を分割して、分割された複数のＭＡＣ３０６としてそれぞれ別のデータフレームのデータフィールドに設定する。

ステップＳ１０１８での処理が終了する、或いは、ＭＡＣ関連の処理がスキップされた場合に、フレーム生成部２１０９は、１フレーム目からＮフレーム目までのＮフレーム分のデータフレームの生成が完了したかを判定し（ステップＳ２００２）、完了していなければＮフレーム分のうち未だ着目していないデータフレームに着目してステップＳ１００３〜Ｓ１０１８の処理を繰り返す。

ステップＳ２００２で、Ｎフレーム分のデータフレームの生成が完了したと判定した場合には、フレーム生成部２１０９は、生成したデータフレームの内容に応じて、各データフレームのデータフィールドヘッダー２３０１内のフレーム特性データ２３１１を設定する（ステップＳ２００３）。これにより、フレーム生成部２１０９は、送信すべきＮフレーム分のデータフレームを生成するためのデータフレーム生成処理を終えることとなり、フレーム送受信部１０１へ通知する（ステップＳ１０１９）。

フレーム送受信部１０１は、フレーム生成部２１０９により送信バッファに生成されたデータフレームを、バス２００に送信する（ステップＳ１０２０）。フレームが正常に送信された場合に、送信カウンタ値がインクリメントされる（ステップＳ１０２１）。

［２．９ データフレーム受信処理］
図２３〜図２５は、ＥＣＵ２１００ｂにより実行されるデータフレーム受信処理を示すフローチャートである。以下、同図に即して、ＥＣＵ２１００ｂにおけるデータフレーム受信処理について説明する。なお、実施の形態１に係るＥＣＵ１００ｂによるデータフレーム受信処理（図１５及び図１６）と同様な処理手順（ステップ）には、図２３〜図２５で同じ符号を付しており、これらについては説明を適宜簡略化する。なお、ＥＣＵ２１００ａ、２１００ｃ、２１００ｄも、ＥＣＵ２１００ｂと同様のデータフレーム受信処理を行う。

バス２００上にフレームが送信された場合に、ＥＣＵ２１００ｂにおいてデータフレーム受信処理が開始される。

ＥＣＵ２１００ｂは、ＣＡＮプロトコルに従って、バス２００から１ｂｉｔずつ受信し、データフレームにおけるＩＤ等を受信して処理した後にデータフィールドを受信することになる。このとき、フレーム解釈部１０２は、ＩＤ、ＤＬＣ、データフィールド等をフレーム処理部２１０５へ転送し、フレーム処理部２１０５は、データフィールドに関連するデータ処理を開始する（ステップＳ１１０１）。なお、フレーム処理部２１０５では、ＩＤによりフレームを区別し、同一ＩＤの複数のフレームは、１つのグループとして送信される場合があり得るものとして処理する。

ＥＣＵ２１００ｂのフレーム処理部２１０５は、受信されたデータフレームのデータフィールドにおけるデータフィールドヘッダー２３０１を取得し、作業用のメモリ領域としてのバッファに保存する（ステップＳ１１０２）。

フレーム処理部２１０５は、データフィールドヘッダー２３０１に含まれるフレーム特性データ２３１１を確認し（ステップＳ２１０１）、フレーム特性データ２３１１のフレームＮｏ．２３２１の値が、先に保存されているフレームＮｏ．の値と一致するかを判定する（ステップＳ２１０２）。これにより、今回受信されたデータフィールドを含むフレームが、先行して受信されたデータフレームと同じグループとして送信されたものであるか否かを判定している。一致しなければ、その保存されているフレームＮｏ．を受信したフレームＮｏ．で上書きし、つまり、受信されたフレームＮｏ．を保存し（ステップＳ２１０３）、データフレーム受信処理で用いる変数値である受信フレーム数をゼロクリアする（ステップＳ２１０４）。

ステップＳ２１０２で一致すると判断した場合及びステップＳ２１０４を実行した場合に、フレーム処理部２１０５は、受信フレーム数をインクリメント（１増加）する（ステップＳ２１０５）。これにより、同じグループとして送信された複数のデータフレームのうち今回受信されたデータフレームが何番目のものであるかを、受信フレーム数が指し示すようになる。なお、例外的にフレームＮｏ．がゼロの場合についてはステップＳ２１０２〜ステップＳ２１０５の処理をスキップすることとしても良い。また、複数のグループのフレーム群が混在して送信されることを許容する必要がある場合等において、フレームＮｏ．毎に別々に受信フレーム数を管理することとしても良い。

次にフレーム処理部２１０５は、受信されたデータフレームのデータフィールドにおける開始フラグ３０２を取得し、バッファに格納する（ステップＳ１１０３）。

続いて、フレーム処理部２１０５は、取得した開始フラグ３０２の値が、一般データ３０４を表すか、ＭＡＣ計算用データ３０５を表すかそれ以外（ＭＡＣを表すもの）かを判定する（ステップＳ１１０４、Ｓ１１０５）。

次に、フレーム処理部２１０５は、開始フラグ３０２に後続するデータサイズ３０３を取得し、サイズに応じてバッファを確保する（ステップＳ１１０６ａ、Ｓ１１０６ｂ或いはＳ１１０６ｃ）。続いて、開始フラグ３０２が、一般データ３０４を表していた場合には、一般データ３０４を取得してバッファに格納し（ステップＳ１１０７）、ＭＡＣ計算用データ３０５を表していた場合には、ＭＡＣ計算用データ３０５を取得してバッファに格納（ステップＳ１１０８）、その他の場合には、ＭＡＣ３０６を取得してバッファに格納する（ステップＳ１１０９）。

フレーム処理部２１０５は、ＤＬＣ及びデータフィールドに基づいて、受信したデータフィールドの全てのデータを取得し終えたかどうかを判定して、上述したステップＳ１１０３〜Ｓ１１０９の処理を、データフィールドの全てのデータを取得し終えるまで繰り返す（ステップＳ１１１０）。

データフィールドのデータを全て取得し終えた場合には、フレーム処理部２１０５は、データフィールドヘッダー２３０１に含まれるデータフィールド構成種別３１３に基づき、受信されたデータフレームの構成を確認して一般データ３０４のみを含むフレームであるか否かを判定する（ステップＳ１１１２）。一般データ３０４のみを含むフレームであると判定した場合にはフレーム処理部２１０５は、受信したデータの内容に応じて、予め定められた機能に係る処理を行う（ステップＳ１１１３）。ステップＳ１１１３に続いて、フレーム処理部２１０５は、一般データを保持しているバッファをクリアし（ステップＳ２１０６）、受信カウンタ値をインクリメントして（ステップＳ１１１９）、これによりデータフレーム受信処理が終了する。

また、ステップＳ１１１２で一般データ３０４のみを含むフレームではないと判定した場合にはフレーム処理部２１０５は、フレーム特性データ２３１１の総フレーム数２３２２が示す数分の同じグループのデータフレームを受信したか否かを、受信フレーム数に基づいて判定する（ステップＳ２１０７）。まだ総フレーム数２３２２が示す数分の同じグループのデータフレームを受信していないと判定した場合には、フレーム処理部２１０５は、受信カウンタ値をインクリメントする（ステップＳ１１１９）。

また、ステップＳ２１０７で、総フレーム数２３２２が示す数分の同じグループのデータフレームを受信したと判定した場合には、フレーム処理部２１０５は、データフィールドヘッダー２３０１に含まれる、ＭＡＣ計算対象フィールド種別３１２を確認する（ステップＳ１１１４）。続いてフレーム処理部２１０５は、確認されたＭＡＣ計算対象フィールド種別３１２に応じてＭＡＣの計算対象となるデータを格納した各フィールドの値を取得（つまり既に受信した各データフレームの必要なフィールドの値をバッファから取得）することで、ＭＡＣの検証に必要なデータを収集する（ステップＳ１１１５）。

フレーム処理部２１０５は、収集したＭＡＣの検証に必要なデータをＭＡＣ処理部１０６に通知して得られるＭＡＣ値によりＭＡＣの検証処理を行い、検証に成功した場合には（ステップＳ１１１６）、受信したデータの内容に応じて、予め定められた処理（データに応じた機能に係る処理）を行う（ステップＳ１１１７）。ステップＳ１１１５及びステップＳ１１１６においては、ＭＡＣを算出するための計算に用いるデータに関する識別子として機能する各種フラグにより示されるデータフィールドの内容の種別が、ＭＡＣを算出するための計算に用いられたデータの領域が含まれることを表す場合に、そのデータフィールドにおけるＭＡＣを算出するための計算に用いられたデータの領域（その各種フラグに応じた領域）の値を用いた計算により、検証処理を行う。

ステップＳ１１１６において、検証に成功しなかった場合には、フレーム処理部２１０５は、受信したデータフレームのデータフィールドのデータに応じた機能に係る処理（ステップＳ１１１７）をスキップする。

ステップＳ１１１７での処理が、終了した場合、或いは、スキップされた場合に、フレーム処理部２１０５は、バッファを全てクリアし（ステップＳ１１１８）、受信カウンタ値をインクリメントする（ステップＳ１１１９）。

［２．１０ 実施の形態２の効果］
実施の形態２で示した車載ネットワークシステム１１では、複数のＥＣＵ間で送受信するデータフレームのデータフィールド内に、ＭＡＣを算出するための計算に用いるデータに関する識別子として機能し得るデータフィールドヘッダー２３０１、開始フラグ３０２等を含ませることにより、データフィールドに格納するデータの構成を自由に定めることを可能にした。これにより、例えばＭＡＣ計算用データ３０５とＭＡＣ３０６とを、同じフレームＮｏ．を付与して、複数フレームのデータフィールド内に自由に分割して配置して送信すること等が可能になり、柔軟なデータ設計が可能となり、またバスのトラフィック量の増加を抑制することが可能になる。なお、ＭＡＣ３０６を付加したＭＡＣ計算用データ３０５を含むデータフレームと、ＭＡＣを付ける必要がない一般データ３０４を含むデータフレームとが同一のＩＤ（メッセージＩＤ）のフレームとして送信される場合においても、データフィールドヘッダー２３０１、開始フラグ３０２等により、ＭＡＣ計算用データ３０５と一般データ３０４とを確実に識別できるため、誤って一般データ３０４等に対するＭＡＣの検証処理を行うこと等が防止される。

［２．１１ 実施の形態２の変形例１］
実施の形態２で図１７により示したデータフレームへのＭＡＣ付与に係るパターンは、図２６に示す例のように変形することができる。例えば、図２６の左側から右側への順に各データフレームがバス２００上に順次送信される。

図２６で示す５つのデータフレームの例のうち、データフレーム６０２の例はＭＡＣ及びＭＡＣ計算用データを含んでいない。図２６の例では、２つ以上のフレームに含まれるデータフィールドの値からＭＡＣを計算して算出し、分割し、分割したＭＡＣそれぞれを計算対象となったデータのいずれとも別個のフレームに格納して送信する例を示している。即ち、データフレーム６０１のＤＬＣ及びデータフィールドと、データフレーム６０３のＤＬＣ及びデータフィールドとに基づいてＭＡＣを計算して算出し、そのＭＡＣの一部をデータフレーム６０４に格納して送信し、そのＭＡＣの他の一部をデータフレーム６０５に格納して送信する例を示している。

図２６の例に対応して車載ネットワークシステムで用いる、フレーム編成及びデータ構成を定める所定アルゴリズムは、例えば、５回分の送信を１セットとして、そのうち１、３〜５回目に送信するデータフレーム６０１、６０３〜６０５を同じグループとし、データフレーム６０１、６０３のデータフィールド内に時速等の送信すべき値を表したＭＡＣ計算用データ３０５を含ませ、データフレーム６０２のデータフィールド内に時速等の送信すべき値を表した一般データ３０４を含ませ、データフレーム６０４のデータフィールド内に、データフレーム６０１及びデータフレーム６０３のＭＡＣ計算用データ３０５及びＤＬＣを用いた計算により算出されたＭＡＣの一部（例えば前半２ｂｙｔｅｓ）を含ませ、データフレーム６０５のデータフィールド内に、上述のＭＡＣの残りの一部（例えば後半２ｂｙｔｅｓ）を含ませて送信する等といったアルゴリズムである。この所定アルゴリズムについては種々の変形が可能である。また、各データフレームに分けて含ませた、送信すべき値は、必ずしも時間的に別々に生成或いは取得されたものでなくても良く、一体として生成或いは取得されたものであっても良いし、同時期に個別に生成或いは取得されたものであっても良い。また、各データフレームは必ずしも定期的に（つまり時間的に一定間隔で）送信される必要はない。

なお、図２６のＭＡＣ付与に係るパターンの例に対応するように、フレーム編成及びデータ構成を定める所定アルゴリズムの内容を変更した以外の点においては、変形例１における車載ネットワークシステムの各ＥＣＵの構成及び動作は、上述したＥＣＵ２１００ａ〜２１００ｄと同様である。但し、図２６の例に対応するように、フレーム編成及びデータ構成を定める所定アルゴリズムとして、先行するデータフレーム内のデータフィールド以外（ＩＤフィールド或いはＤＬＣ）を用いて後続するデータフレーム内のＭＡＣの算出を可能にする場合には、次のようにデータフレーム受信処理を変形しても良い。即ち、データフレーム受信処理のステップＳ２１０７（図２５）で、総フレーム数２３２２が示す数分の同じグループのデータフレームを受信していないと判定した場合において、フレーム処理部２１０５は、後に受信するフレームでのＭＡＣの算出のための計算にＩＤフィールド或いはＤＬＣが用いられ得るために、ＩＤフィールド及びＤＬＣの内容をバッファに格納しておくこととしても良い。

［２．１２ 実施の形態２の変形例１の効果］
変形例１に係る車載ネットワークシステムでは、ＭＡＣ計算用データ３０５を含ませたフレームと、そのＭＡＣ計算用データ３０５から計算したＭＡＣ３０６を含ませたフレームとを別々に分離して送信することが可能となり、これにより、送信側、受信側それぞれのＥＣＵにおいて単位時間あたりのフレームの処理負荷が軽減（分散）される効果が生じ得る。

［２．１３ 実施の形態２の変形例２］
実施の形態２で図１７により示したデータフレームへのＭＡＣ付与に係るパターンは、図２７に示す例のように変形することもできる。

図２７で示す５つのデータフレームの例のうち、データフレーム６１２の例はＭＡＣ及びＭＡＣ計算用データを含んでいない。図２７の例では、２つ以上のフレームに含まれるデータフィールドの値からＭＡＣを計算して算出し、分割し、分割したＭＡＣそれぞれを計算対象となったデータのいずれとも別個のフレームに、一般データとともに格納して送信する例を示している。即ち、データフレーム６１１のデータフィールドと、データフレーム６１３のデータフィールドとに基づいてＭＡＣを計算して算出し、そのＭＡＣの一部を一般データ（つまりＭＡＣの算出のための計算に用いられないデータ）とともにデータフレーム６１４に格納して送信し、そのＭＡＣの他の一部を一般データとともにデータフレーム６１５に格納して送信する例を示している。

図２７の例に対応して車載ネットワークシステムで用いる、フレーム編成及びデータ構成を定める所定アルゴリズムは、例えば、５回分の送信を１セットとして、そのうち１、３〜５回目に送信するデータフレーム６１１、６１３〜６１５を同じグループとし、データフレーム６１１、６１３のデータフィールド内に時速等の送信すべき値を表したＭＡＣ計算用データ３０５を含ませ、データフレーム６１２のデータフィールド内に時速等の送信すべき値を表した一般データ３０４を含ませ、データフレーム６１４のデータフィールド内に、一般データ３０４と、データフレーム６１１及びデータフレーム６１３のＭＡＣ計算用データ３０５を用いた計算により算出されたＭＡＣの一部（例えば前半２ｂｙｔｅｓ）とを含ませ、データフレーム６１５のデータフィールド内に、一般データ３０４と上述のＭＡＣの残りの一部（例えば後半２ｂｙｔｅｓ）とを含ませて送信する等といったアルゴリズムである。この所定アルゴリズムについては種々の変形が可能である。また、各データフレームに分けて含ませた、送信すべき値は、必ずしも時間的に別々に生成或いは取得されたものでなくても良く、一体として生成或いは取得されたものであっても良いし、同時期に個別に生成或いは取得されたものであっても良い。また、各データフレームは必ずしも定期的に（つまり時間的に一定間隔で）送信される必要はない。

なお、図２７のＭＡＣ付与に係るパターンの例に対応するように、フレーム編成及びデータ構成を定める所定アルゴリズムの内容を変更した以外の点においては、変形例２における車載ネットワークシステムの各ＥＣＵの構成及び動作は、上述したＥＣＵ２１００ａ〜２１００ｄと同様である。

［２．１４ 実施の形態２の変形例２の効果］
変形例２に係る車載ネットワークシステムでは、ＭＡＣ計算用データ３０５を含ませたフレームと、そのＭＡＣ計算用データ３０５から計算したＭＡＣ３０６を含ませたフレームとを時間的にずらして送受信することが可能となり、また、例えばＭＡＣ３０６を送る時点で送信可能となった一般データをＭＡＣとともに送信することが可能になる。これにより、全体としてフレーム送受信の完了を早めることが可能となる。

［２．１５ 実施の形態２の変形例３］
実施の形態２で図１７により示したデータフレームへのＭＡＣ付与に係るパターンは、図２８に示す例のように変形することもできる。

図２８で示す４つのデータフレームの例のうち、データフレーム６２４の例はＭＡＣ及びＭＡＣ計算用データを含んでいない。図２８の例では、２つ以上のフレームに含まれるデータフィールドの値からＭＡＣを計算して算出し、ＭＡＣを計算対象となったデータのいずれとも別個のフレームに、一般データとともに格納して送信する例を示している。即ち、データフレーム６２１のデータフィールドと、データフレーム６２３のデータフィールドとに基づいてＭＡＣを計算して算出し、そのＭＡＣを一般データ（つまりＭＡＣの算出のための計算に用いられないデータ）とともにデータフレーム６２２に格納して送信し、最後のデータフレーム６２４では一般データのみをデータフィールドに格納して送信する例を示している。

図２８の例に対応して車載ネットワークシステムで用いる、フレーム編成及びデータ構成を定める所定アルゴリズムは、例えば、４回分の送信を１セットとして、その全てのデータフレーム６２１〜６２４を同じグループとし、データフレーム６２１、６２３のデータフィールド内に時速等の送信すべき値を表したＭＡＣ計算用データ３０５を含ませ、データフレーム６２２のデータフィールド内に、一般データ３０４と、データフレーム６２１及びデータフレーム６２３のＭＡＣ計算用データ３０５を用いた計算により算出されたＭＡＣを含ませ、データフレーム６２４のデータフィールド内に時速等の送信すべき値を表した一般データ３０４を含ませて送信する等といったアルゴリズムである。この所定アルゴリズムについては種々の変形が可能である。また、各データフレームに分けて含ませた、送信すべき値は、必ずしも時間的に別々に生成或いは取得されたものでなくても良く、一体として生成或いは取得されたものであっても良いし、同時期に個別に生成或いは取得されたものであっても良い。また、各データフレームは必ずしも定期的に（つまり時間的に一定間隔で）送信される必要はない。

なお、図２８のＭＡＣ付与に係るパターンの例に対応するように、フレーム編成及びデータ構成を定める所定アルゴリズムの内容を変更した以外の点においては、変形例３における車載ネットワークシステムの各ＥＣＵの構成及び動作は、上述したＥＣＵ２１００ａ〜２１００ｄと同様である。但し、上述の実施の形態２ではデータフレーム受信処理のステップＳ２１０７（図２５）で、総フレーム数２３２２を用いて、受信したデータフレームの数の判定を行っているが、変形例３においては、ＭＡＣ計算用データを含むフレーム数２３２３及びＭＡＣデータを含むフレーム数２３２４（図２０）を用いてＭＡＣの検証処理を開始できるタイミングを判定することとする。これにより、受信したフレーム数が総フレーム数２３２２に達するより前に、ＭＡＣの検証処理を開始することができる。このために、例えばＭＡＣの計算対象となるデータ以外のデータを、ＭＡＣを含むデータフレームより後に送信するデータフレームに配置するように、フレーム編成を定めることが有用となる。なお、ＭＡＣ計算用データを含むフレーム数２３２３及びＭＡＣデータを含むフレーム数２３２４の代わりにフレーム特性データ２３１１に、１つのグループに属する複数のデータフレーム（つまり同じフレームＮｏ．を付したデータフレーム）のうち、何番目のデータフレームまで受信したらＭＡＣの検証処理を開始できるかを示す情報を含ませることとして、これに基づいてＥＣＵがＭＡＣの検証処理を開始するタイミングを判定するようにしても良い。

［２．１６ 実施の形態２の変形例３の効果］
変形例３に係る車載ネットワークシステムでは、受信したフレーム数が総フレーム数２３２２に達する前にＥＣＵがＭＡＣの検証処理を開始し得るので、フレーム送受信の完了を早めることが可能となる。

［２．１７ 補足］
以上、各種のＭＡＣ付与に係るパターンについて説明したが、これらは例示に過ぎず多様なパターンを任意のタイミングで用いることができる。なお、ＭＡＣが単一のフレームに含まれている状態（つまりこのフレームを受信すると直ちにＭＡＣの検証が可能な状態）をシングルフレームと呼ぶ。また、ＭＡＣが複数のフレームに分割されている状態をマルチフレームと呼ぶ。

ＥＣＵでは、送信されるデータについてのフレーム編成及びデータ構成を定める所定アルゴリズムとして、データを、シングルフレームで送信するか、マルチフレームで送信するかを、任意に決定し、任意のタイミングで切り替える様々なアルゴリズムを用いることができる。

（他の実施の形態）
以上のように、本開示に係る技術の例示として実施の形態１、２及び変形例１〜３を説明した。しかしながら、本開示に係る技術は、これに限定されず、適宜、変更、置き換え、付加、省略等を行った実施の形態にも適用可能である。例えば、以下のような変形例も本開示の一実施態様に含まれる。

（１）上記実施の形態で示したＭＡＣの付与に係るパターンは、フレームのＩＤ毎に別個のパターンであっても良い。また、フレームのＩＤが同じであっても、ＭＡＣの付与に係るパターンは、１パターンに限られず、随時変更することとしても良い。例えば、ＭＡＣの付与に係るパターンを実現すべく予め定められた、フレーム編成及びデータ構成を定める所定アルゴリズムを複数用いて、逐次その所定アルゴリズムを切り替えることで、ＭＡＣの付与に係るパターンを変更しても良い。この変更タイミングは、定期的でもランダムでも良い。また、バス占有率の状況に応じて、ＭＡＣの付与に係るパターンを変更しても良い。

（２）上記実施の形態では、ＭＡＣの付与に係るパターンとして、ＥＣＵが送信するフレームにＭＡＣを付与する回数、或いは、送信するフレームにＭＡＣ計算用データを含ませる回数を減らした例（間引いた例）を示したが、この他に、フレームを受信側のＥＣＵにおいて、ＭＡＣの検証処理を行う回数を間引くようにしても良い。また、受信側のＥＣＵにおける処理の変更を指示するためのデータを送信側のＥＣＵがフレームに含めて送信することとしても良い。

（３）上記実施の形態では、ＩＤ、ＤＬＣ、データフィールドのデータ値及びカウンタ値をＭＡＣの計算に用いることができる旨を示したが、データフレームに含まれる他のフィールドの値を用いて計算しても良く、これらのいずれか１つの値或いは複数の値の組み合わせからＭＡＣの計算を行っても良い。また、フレームに含まれるＭＡＣのサイズは、特定のサイズに制限されるものではなく、送信毎に異なるサイズであっても良いし、メッセージＩＤ毎に異なるサイズであっても良い。また、同様に時速等のデータ値のサイズ及びカウンタ値のサイズも特定のサイズに制限されるものではない。

（４）上記実施の形態では、カウンタ値を送受信毎にインクリメントする例を示したが、カウンタ値が時刻に応じて自動的にインクリメントされる値であっても良い。また、時刻そのものの値をカウンタ値の代わりに使用しても良い。即ち、データフレームが送信される度に変化する変数（カウンタ値、時刻等）に基づいてＭＡＣが生成されるようにすると、ＭＡＣの不正な解読を困難化することが可能となる。また、送信カウンタ値は、ＭＡＣデータを生成する度にインクリメントされることとしても良いし、受信カウンタ値は、ＭＡＣを検証する度にインクリメントされることとしても良い。

（５）上記実施の形態では、ＣＡＮプロトコルにおけるデータフレームを標準ＩＤフォーマットで記述しているが、拡張ＩＤフォーマットで合っても良い。

（６）上記実施の形態では、各種フラグをＣＡＮプロトコルにおけるデータフレームのデータフィールドに含めて記述しているが、拡張ＩＤフィールドに格納するとしても良い。また、その他のフィールドに含めても良い。

（７）上記実施の形態では、ＭＡＣ算出のアルゴリズムをＨＭＡＣとしているが、これはＣＢＣ−ＭＡＣ（Cipher Block Chaining Message Authentication Code）、ＣＭＡＣ（Cipher-based MAC）であっても良い。また、ＭＡＣ計算に用いられるパディングについては、ゼロパディング、ＩＳＯ１０１２６、ＰＫＣＳ＃１、ＰＫＣＳ＃５、ＰＫＣＳ＃７、その他、ブロックのデータサイズが計算に必要となるパディングの方式であれば何でも良い。また４ｂｙｔｅｓ等のブロックへのサイズの変更方法についても、先頭、最後尾、中間のいずれの部分にパディングを行っても良い。また、ＭＡＣ算出に用いるデータは、連続しているデータ（例えば４ｂｙｔｅｓ分の連続データ）でなくても、特定のルールに従って１ｂｉｔずつ収集して結合したものでも良い。

（８）上記実施の形態では、ＭＡＣ鍵をメッセージＩＤ毎に１つ保持しているが、ＥＣＵ毎（つまり１以上のメッセージＩＤ群毎）に１つであっても良い。また、全てのＥＣＵが同じＭＡＣ鍵を保持している必要はない。また、同一のバスに接続された各ＥＣＵは、共通のＭＡＣ鍵を保持していても良い。但し、同じメッセージＩＤのフレームを送信するＥＣＵとそのフレームを受信して検証するＥＣＵとでは同じＭＡＣ鍵を保持する必要がある。また、上記実施の形態では、カウンタ値（送信カウンタ値、受信カウンタ値）をメッセージＩＤ毎に１つ保持しているが、ＥＣＵ毎（つまり１以上のメッセージＩＤ群毎）に１つであっても良い。また、同一のバス上を流れる全てのフレームに対して共通のカウンタ値を使用しても良い。

（９）上記実施の形態では、送信カウンタ値はＭＡＣの算出のために使用しているが、ＥＣＵは、その送信カウンタ値の全部又は一部をデータフィールドに含めて送信しても良い。

（１０）上記実施の形態では、ＥＣＵ間で送受信されるデータフレームに対して、受信したＥＣＵがＭＡＣの検証を行っているが、車載ネットワークシステムにおいて、全てのデータフレームに付与されたＭＡＣについて検証を行うＭＡＣ検証用ＥＣＵを含んでいても良い。このＭＡＣ検証用ＥＣＵは、例えば、全てのメッセージＩＤに対応するＭＡＣ鍵と、カウンタ値とを保持する。ＭＡＣ検証用ＥＣＵは、ＭＡＣ検証の結果、エラーと判定（つまり検証失敗と判定）した場合に、他のＥＣＵでの受信を防止するため、エラーフレームを送信することとしても良い。

（１１）上記実施の形態で示したデータフィールドヘッダー３０１、２３０１、開始フラグ３０２等の各種フラグ（ＭＡＣを算出するための計算に用いるデータに関する識別子として機能し得るフラグ）の配置、表現形式等は一例にすぎない。このため、例えば、データフィールドヘッダー３０１、２３０１をデータフィールドの先頭以外の所定位置に定めても良いし、その各種フラグと同内容を異なる表現形式で定めても良い。なお、この各種フラグは、ＭＡＣを算出するための計算に用いるデータに関する識別子としては、例えば、ＭＡＣの検証が必要か否かの識別情報、或いは、ＭＡＣの計算対象となるデータの領域の情報（例えばデータフィールドの内容の種別、各種別のデータの領域の位置、データサイズ等の情報）等の検証を行うために必要な情報を特定する機能を有する。

（１２）上記実施の形態で示した、フレーム編成及びデータ構成を定める所定アルゴリズムは、例えばＥＣＵで制御プログラムを実行するプロセッサにより実現される。この所定アルゴリズムに係る制御プログラムを格納した記憶媒体（メモリ等）がＥＣＵに搭載されていても良いし、ＥＣＵが外部からその制御プログラムを取得して記憶媒体に格納して利用しても良い。

（１３）上記実施の形態では、各ＥＣＵはデータフレームを送信することとしたが、車載ネットワークシステムは、データフレームを受信するのみでデータフレームを送信しないＥＣＵを含んでいても良い。また逆に、車載ネットワークシステムは、データフレームを送信するのみで、データフレームを受信しないＥＣＵを含んでいても良い。

（１４）上記実施の形態で示したＣＡＮプロトコルは、ＴＴＣＡＮ（Time-Triggered CAN)、ＣＡＮＦＤ（CAN with Flexible Data Rate）等の派生的なプロトコルをも包含する広義の意味を有するものであっても良い。

（１５）上記実施の形態におけるＭＡＣ鍵保持部及びカウンタ保持部は、ＣＡＮコントローラと呼ばれるハードウェアのレジスタ、または、ＣＡＮコントローラと接続して動作するマイコン上で動作するファームウェアに格納されていても良い。

（１６）上記実施の形態における各ＥＣＵは、例えば、プロセッサ、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置であることとしたが、ハードディスク装置、ディスプレイ、キーボード、マウス等の他のハードウェア構成要素を含んでいても良い。また、メモリに記憶された制御プログラムがプロセッサにより実行されてソフトウェア的に機能を実現する代わりに、専用のハードウェア（デジタル回路等）によりその機能を実現することとしても良い。

（１７）上記実施の形態における各装置（ＥＣＵ等）を構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Large Scale Integration：大規模集積回路）から構成されているとしても良い。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ等を含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムに従って動作することにより、システムＬＳＩは、その機能を達成する。また、上記各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部又はすべてを含むように１チップ化されても良い。また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現しても良い。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行っても良い。バイオ技術の適用等が可能性としてあり得る。

（１８）上記各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしても良い。前記ＩＣカードまたは前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭ等から構成されるコンピュータシステムである。前記ＩＣカードまたは前記モジュールは、上記の超多機能ＬＳＩを含むとしても良い。マイクロプロセッサが、コンピュータプログラムに従って動作することにより、前記ＩＣカードまたは前記モジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしても良い。

（１９）本開示の一態様としては、上記に示す送信方法或いは受信方法であるとしても良い。また、この方法をコンピュータにより実現するコンピュータプログラムであるとしても良いし、前記コンピュータプログラムからなるデジタル信号であるとしても良い。また、本開示の一態様としては、前記コンピュータプログラムまたは前記デジタル信号をコンピュータで読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＢＤ（Blu-ray（登録商標）Disc）、半導体メモリ等に記録したものとしても良い。また、これらの記録媒体に記録されている前記デジタル信号であるとしても良い。また、本開示の一態様としては、前記コンピュータプログラムまたは前記デジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしても良い。また、本開示の一態様としては、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、前記マイクロプロセッサは、前記コンピュータプログラムに従って動作するとしても良い。また、前記プログラムまたは前記デジタル信号を前記記録媒体に記録して移送することにより、または前記プログラムまたは前記デジタル信号を前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしても良い。

（２０）上記実施の形態及び上記変形例で示した各構成要素及び機能を任意に組み合わせることで実現される形態も本開示の範囲に含まれる。

本開示は、車載ネットワークシステムにおいて送受信するメッセージのセキュリティを確保するために利用可能である。

１０ 車載ネットワークシステム
１００ａ〜１００ｄ，２１００ａ 電子制御ユニット（ＥＣＵ）
１０１ フレーム送受信部
１０２ フレーム解釈部
１０３ 受信ＩＤ判断部
１０４ 受信ＩＤリスト保持部
１０５，２１０５ フレーム処理部
１０６ ＭＡＣ処理部
１０７ ＭＡＣ鍵保持部
１０８ カウンタ保持部
１０９，２１０９ フレーム生成部
１１０ データ取得部
２００ バス
３１０ エンジン
３２０ ブレーキ
３３０ ドア開閉センサ
３４０ 窓開閉センサ
３０１，２３０１ データフィールドヘッダー
３０２ 開始フラグ
３０３ データサイズ
３０４ 一般データ
３０５ ＭＡＣ計算用データ
３０６ ＭＡＣデータ
３１１ 予約ｂｉｔ
３１２ ＭＡＣ計算対象フィールド種別
３１３ データフィールド構成種別
２３１１ フレーム特性データ
２３２１ フレーム番号（フレームＮｏ．）
２３２２ 総フレーム数
２３２３ ＭＡＣ計算用データを含むフレーム数
２３２４ ＭＡＣを含むフレーム数

Claims (19)

1. ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介して通信する複数の電子制御ユニットを備える車載ネットワークシステムであって、送信内容の正当性を示すメッセージ認証コードを算出するための計算に用いるデータに関する識別子を含む１又は複数のデータフレームを前記バスにより送信する第１電子制御ユニットと、
   前記バス上で送信された１又は複数のデータフレームを受信し、受信したデータフレームの前記識別子に応じてメッセージ認証コードの検証処理を行う第２電子制御ユニットとを備える車載ネットワークシステム。
2. 前記第１電子制御ユニットは、送信する前記１又は複数のデータフレーム内の１以上の領域に配置されるデータを用いた計算により算出したメッセージ認証コードを、当該１又は複数のデータフレームのうちの少なくとも１つのデータフレームに含ませて送信し、
   前記第１電子制御ユニットに送信される前記１又は複数のデータフレームに含まれる前記識別子は、前記メッセージ認証コードを算出するための計算に用いられた、当該１又は複数のデータフレーム内の１以上のデータの領域を、示す情報を含み、
   前記第２電子制御ユニットは、前記識別子により示される領域のデータを用いた計算により、前記検証処理を行う
   請求項１記載の車載ネットワークシステム。
3. 前記第１電子制御ユニットは、前記メッセージ認証コードを、送信する複数のデータフレーム内の１以上の領域に配置されるデータを用いた計算により算出し、算出したメッセージ認証コードを当該複数のデータフレームのうちの少なくとも１つのデータフレームに含ませて送信し、
   前記第１電子制御ユニットに送信される前記複数のデータフレームに含まれる前記識別子は、当該複数のデータフレームの数を示す情報を含み、
   前記第２電子制御ユニットは、受信したいずれかのデータフレームに含まれる前記識別子により示される数のデータフレームを受信した場合において、受信された各データフレームにおける前記識別子により示される領域のデータを用いた計算により、前記検証処理を行う
   請求項２記載の車載ネットワークシステム。
4. ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介して通信する複数の電子制御ユニットを備える車載ネットワークシステムにおいて用いられる受信方法であって、
   前記バス上で送信された、送信内容の正当性を示すメッセージ認証コードを算出するための計算に用いるデータに関する識別子を含む１又は複数のデータフレームを受信する受信ステップと、
   前記受信ステップで１又は複数のデータフレームが受信された場合に、受信されたデータフレームの前記識別子に応じてメッセージ認証コードの検証処理を行う検証ステップとを含む
   受信方法。
5. 前記受信ステップで受信されるデータフレームにおける前記識別子は、当該データフレームのデータフィールドの内容の種別を示す
   請求項４記載の受信方法。
6. 前記受信ステップで受信される前記１又は複数のデータフレームのうちの少なくとも１つのデータフレームにはメッセージ認証コードが含まれ、
   前記受信ステップで受信されるデータフレームにおける前記識別子により示される、データフィールドの内容の前記種別は、当該データフィールドに、メッセージ認証コードを算出するための計算に用いられたデータの領域が含まれるか否かを表し、
   前記検証ステップでは、前記識別子により示されるデータフィールドの内容の前記種別が、メッセージ認証コードを算出するための計算に用いられたデータの領域が含まれることを表す場合に、当該データフィールドにおけるメッセージ認証コードを算出するための計算に用いられたデータの領域の値を用いた計算により、前記検証処理を行う
   請求項５記載の受信方法。
7. 前記受信ステップで受信されるデータフレームにおける前記識別子は、当該データフレームのデータフィールドにおける一の種別のデータの領域を示す
   請求項４記載の受信方法。
8. 前記受信ステップで受信される前記１又は複数のデータフレームのうちの少なくとも１つのデータフレームにはメッセージ認証コードが含まれ、
   前記受信ステップで受信されるデータフレームにおける前記識別子により示される前記一の種別のデータの領域は、メッセージ認証コードを算出するための計算に用いられたデータの領域であり、
   前記検証ステップでは、前記識別子により示される領域のデータを用いた計算により、前記検証処理を行う
   請求項７記載の受信方法。
9. 前記受信ステップで受信されるデータフレームにおける前記識別子は当該データフレームのデータフィールドに配置されており、
   前記検証ステップでは、受信されたデータフレームのデータフィールド内の前記識別子に応じて前記検証処理を行う
   請求項４記載の受信方法。
10. 前記１又は複数のデータフレームに含まれる前記識別子は、当該１又は複数のデータフレーム内の１以上のデータの領域を、示す情報を含み、
    前記検証ステップでは、前記受信ステップで受信されたデータフレームにおける前記識別子に応じた領域のデータを用いた計算により、前記検証処理を行う
    請求項４記載の受信方法。
11. ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介して通信する複数の電子制御ユニットを備える車載ネットワークシステムにおいて用いられる送信方法であって、
    １又は複数のデータフレーム内の１以上の領域に配置されるデータを用いた計算により、送信内容の正当性を示すためのメッセージ認証コードを算出する算出ステップと、
    前記算出ステップで算出されたメッセージ認証コードを前記１又は複数のデータフレームのうちの少なくとも１つのデータフレームに含ませ、当該メッセージ認証コードを算出するための計算に用いられたデータに関する識別子を含ませた当該１又は複数のデータフレームを送信する送信ステップとを含む
    送信方法。
12. 前記送信ステップで送信するデータフレームにおける前記識別子は、当該データフレームのデータフィールドの内容の種別を示す
    請求項１１記載の送信方法。
13. 前記送信ステップで送信するデータフレームにおける前記識別子により示される、データフィールドの内容の前記種別は、当該データフィールドに、前記算出ステップで前記メッセージ認証コードを算出するための計算に用いられたデータの領域が含まれるか否かを表す
    請求項１２記載の送信方法。
14. 前記送信ステップで送信するデータフレームにおける前記識別子は、当該データフレームのデータフィールドにおける一の種別のデータの領域を示す
    請求項１１記載の送信方法。
15. 前記送信ステップで送信するデータフレームにおける前記識別子により示される前記一の種別のデータの領域は、前記算出ステップで前記メッセージ認証コードを算出するための計算に用いられたデータの領域である
    請求項１４記載の送信方法。
16. 前記送信ステップでは、前記識別子を、送信するデータフレームのデータフィールドに配置する
    請求項１１記載の送信方法。
17. 前記送信ステップで送信する前記１又は複数のデータフレームに含まれる前記識別子は、前記メッセージ認証コードを算出するための計算に用いられた、当該１又は複数のデータフレーム内の１以上のデータの領域を、示す情報を含む
    請求項１１記載の送信方法。
18. ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介して通信する電子制御ユニットであって、
    前記バス上で送信された、送信内容の正当性を示すメッセージ認証コードを算出するための計算に用いるデータに関する識別子を含む１又は複数のデータフレームを受信する受信部と、
    前記受信部により１又は複数のデータフレームが受信された場合に、受信されたデータフレームの前記識別子に応じてメッセージ認証コードの検証処理を行う検証部とを備える
    電子制御ユニット。
19. ＣＡＮ（Controller Area Network）プロトコルに従ってバスを介して通信する電子制御ユニットであって、
    １又は複数のデータフレーム内の１以上の領域に配置されるデータを用いた計算により、送信内容の正当性を示すためのメッセージ認証コードを算出する算出部と、
    前記算出部により算出されたメッセージ認証コードを前記１又は複数のデータフレームのうちの少なくとも１つのデータフレームに含ませ、当該メッセージ認証コードを算出するための計算に用いられたデータに関する識別子を含ませた当該１又は複数のデータフレームを送信する送信部とを備える
    電子制御ユニット。

Images