JP7280412B2 - ゲートウェイ装置、車載ネットワークシステム及びファームウェア更新方法 - Google Patents

Description

本発明は、仮想マシンモニタ、ソフトウェア及びファームウェア更新方法に関する。

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

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

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

多数のＥＣＵがバスを介したメッセージの授受により連携して動作している場合に、あるＥＣＵがファームウェア（ＦＷ：Firmware）の更新を開始すると、その更新中はメッセージの授受ができない等によって自動車の走行に影響を与える可能性がある。この点に関して、自動車の状態を示す情報から、停車中等といったＥＣＵのファームウェアを更新できると判断できた場合にのみファームウェアを更新する技術が知られている（特許文献１参照）。

特開２０１０－２７３１８１号公報

しかしながら、特許文献１の技術は、ファームウェアの更新を適切（例えば安全）なタイミングで実行するものの、ＥＣＵがファームウェアの更新に必要な何らかの処理を行う機能を有さない場合において有用ではない。

そこで、本発明は、ファームウェアの更新に必要な処理を実行しないＥＣＵが適切にファームウェアの更新を行うことを可能にするための仮想マシンモニタ等を提供する。

上記課題を解決するために本発明の一態様に係るゲートウェイ装置は、車両に搭載された複数の電子制御ユニットが通信に用いるネットワークに接続されたゲートウェイ装置であって、前記複数の電子制御ユニットのうち１つの電子制御ユニットを適用対象とした更新用ファームウェアを含むファームウェア更新情報を取得する取得部と、前記更新用ファームウェアの適用対象の電子制御ユニットの所定情報に基づいて当該電子制御ユニットが所定条件を満たすか否かを判定し、所定条件を満たす場合には当該電子制御ユニットにファームウェアの更新に関連する所定処理を実行させ、所定条件を満たさない場合には前記所定処理が当該電子制御ユニット以外で実行されるように制御する制御部とを備え、前記所定情報は、前記更新用ファームウェアの適用対象の電子制御ユニットの処理能力を示し、前記制御部は、当該電子制御ユニットが処理能力を有し、当該電子制御ユニットのプロセッサの負荷が一定程度以下の場合、前記所定処理を当該電子制御ユニットで実行させ、当該電子制御ユニットが処理能力を有していない場合、または、当該電子制御ユニットが処理能力を有していても当該電子制御ユニットのプロセッサの負荷が一定程度より高い場合、前記所定処理を当該電子制御ユニット以外で実行させるように制御する、ゲートウェイ装置である。

また、本発明の一態様に係る車載ネットワークシステムは、１以上のネットワークを介して通信する複数の電子制御ユニットと前記ネットワークに接続されたゲートウェイ装置とを備える車載ネットワークシステムであって、前記ゲートウェイ装置は、前記複数の電子制御ユニットのうち１つの電子制御ユニットを適用対象とした更新用ファームウェアを含むファームウェア更新情報を取得する取得部と、前記更新用ファームウェアの適用対象の電子制御ユニットの所定情報に基づいて当該電子制御ユニットが所定条件を満たすか否かを判定し、所定条件を満たす場合には当該電子制御ユニットにファームウェアの更新に関連する所定処理を実行させ、所定条件を満たさない場合には前記所定処理が当該電子制御ユニット以外で実行されるように制御する制御部とを有し、前記所定情報は、前記更新用ファームウェアの適用対象の電子制御ユニットの処理能力を示し、前記制御部は、当該電子制御ユニットが処理能力を有し、当該電子制御ユニットのプロセッサの負荷が一定程度以下の場合、前記所定処理を当該電子制御ユニットで実行させ、当該電子制御ユニットが処理能力を有していない場合、または、当該電子制御ユニットが処理能力を有していても当該電子制御ユニットのプロセッサの負荷が一定程度より高い場合、前記所定処理を当該電子制御ユニット以外で実行させるように制御する、車載ネットワークシステムである。

また、本発明の一態様に係るファームウェア更新方法は、１以上のネットワークを介して通信する複数の電子制御ユニットを備える車載ネットワークシステムにおいて用いられるファームウェア更新方法であって、前記複数の電子制御ユニットのうち１つの電子制御ユニットを適用対象とした更新用ファームウェアを含むファームウェア更新情報を取得する取得ステップと、前記更新用ファームウェアの適用対象の電子制御ユニットの所定情報に基づいて当該電子制御ユニットが所定条件を満たすか否かを判定し、所定条件を満たす場合には当該電子制御ユニットにファームウェアの更新に関連する所定処理を実行させ、所定条件を満たさない場合には前記所定処理が当該電子制御ユニット以外で実行されるように制御する制御ステップとを含み、前記所定情報は、前記更新用ファームウェアの適用対象の電子制御ユニットの処理能力を示し、前記制御ステップは、当該電子制御ユニットが処理能力を有し、当該電子制御ユニットのプロセッサの負荷が一定程度以下の場合、前記所定処理を当該電子制御ユニットで実行させ、当該電子制御ユニットが処理能力を有していない場合、または、当該電子制御ユニットが処理能力を有していても当該電子制御ユニットのプロセッサの負荷が一定程度より高い場合、前記所定処理を当該電子制御ユニット以外で実行させるように制御する、ファームウェア更新方法である。

本発明によれば、ファームウェアの更新に必要な処理を実行しないＥＣＵの代わりに他の装置においてその処理を実行（代行）するので、そのＥＣＵにおいて適切にファームウェアの更新を行うことが可能となる。

実施の形態１に係る車載ネットワークシステムの全体構成を示す図である。 ＣＡＮプロトコルで規定されるデータフレームのフォーマットを示す図である。 実施の形態１に係るゲートウェイの構成図である。 受信ＩＤリストの一例を示す図である。 ゲートウェイが用いる転送ルールの一例を示す図である。 実施の形態１に係る所定情報（ＥＣＵ情報）のリストの一例を示す図である。 実施の形態１に係る署名検証機能及びファームウェア（ＦＷ）キャッシュ機能を有するＥＣＵの構成図である。 実施の形態１に係る署名検証機能を有するＥＣＵの構成図である。 実施の形態１に係るＦＷキャッシュ機能を有するＥＣＵの構成図である。 実施の形態１に係る署名検証機能及びＦＷキャッシュ機能を有さないＥＣＵの構成図である。 実施の形態１に係るサーバの構成図である。 サーバが保持する車両ＥＣＵ管理情報の一例を示す図である。 実施の形態１に係るファームウェア（ＦＷ）更新情報のフォーマットの一例を示す図である。 実施の形態１におけるＦＷ更新情報の配信に係る動作例を示すシーケンス図である。 実施の形態１に係るゲートウェイによるＦＷ更新制御処理の一例を示すフローチャートである。 実施の形態１に係る署名検証機能及びＦＷキャッシュ機能を有するＥＣＵによるＦＷ更新制御処理の一例を示すフローチャートである。 実施の形態１に係る署名検証機能を有するＥＣＵによるＦＷ更新制御処理の一例を示すフローチャートである。 実施の形態１に係るＦＷキャッシュ機能を有するＥＣＵによるＦＷ更新制御処理の一例を示すフローチャートである。 実施の形態１に係る署名検証機能及びＦＷキャッシュ機能を有さないＥＣＵによるＦＷ更新制御処理の一例を示すフローチャートである。 実施の形態１におけるＦＷ更新ＧＷ（ゲートウェイ）代行処理に係る動作例を示すシーケンス図である。 実施の形態２に係る車載ネットワークシステムの全体構成を示す図である。 実施の形態２に係るゲートウェイによるＦＷ更新制御処理の一例を示すフローチャートである。 実施の形態２に係るゲートウェイによる署名検証ＥＣＵ代行処理の一例を示すフローチャートである。 実施の形態２におけるＦＷ更新についてのＥＣＵ代行処理に係る動作例を示すシーケンス図である。 ＥＣＵの構成例としてのコンピュータで実現される仮想環境のソフトウェア構成の一例を示す図である。

本発明の一態様に係るゲートウェイ装置は、車両に搭載された複数の電子制御ユニットが通信に用いるバスに接続されたゲートウェイ装置であって、前記車両外の外部装置から、前記複数の電子制御ユニットのうち１つの電子制御ユニットを適用対象とした更新用ファームウェアを含むファームウェア更新情報を受信する受信部と、前記更新用ファームウェアの適用対象の電子制御ユニットの所定情報に基づいて当該電子制御ユニットが所定条件を満たすか否かを判定し、所定条件を満たす場合には当該電子制御ユニットにファームウェアの更新に関連する所定処理を実行させ、所定条件を満たさない場合には前記所定処理が当該電子制御ユニット以外で実行されるように制御する制御部とを備えるゲートウェイ装置である。これにより、ゲートウェイ装置は、バスに接続された電子制御ユニット（ＥＣＵ）のうちファームウェアの更新対象のＥＣＵが更新に関連する所定処理（例えば署名検証処理等）の実行のための機能を有していない場合、所定処理を実行できない状況にある場合等において、そのＥＣＵの代わりに他のＥＣＵ或いはそのゲートウェイ装置が所定処理を実行（つまり代行）するよう制御できる。このため、例えば、ファームウェアの更新を、セキュリティを確保して行うために必要な機能を持たないＥＣＵ等においても、適切にファームウェアの更新が実施され得る。

また、前記制御部は、前記更新用ファームウェアの適用対象の電子制御ユニットの処理能力を示す前記所定情報に基づいて前記判定を行うこととしても良い。これにより、更新用ファームウェアの適用対象（更新対象）のＥＣＵが処理能力の面で所定処理を行えない場合であっても、適切にファームウェアの更新が実施され得る。

また、前記処理能力を示す前記所定情報は、前記所定処理の実行機能を有するか否かを示し、前記制御部は、前記更新用ファームウェアの適用対象の電子制御ユニットが、前記所定処理の実行機能を有する場合に前記所定条件を満たし、前記所定処理の実行機能を有さない場合に前記所定条件を満たさないとして前記判定を行うこととしても良い。これにより、更新用ファームウェアの適用対象のＥＣＵが更新を適切に行う上で有用な所定処理を実行する機能を有さない場合であっても、その所定処理が代行されるので、適切にファームウェアの更新が実施され得る。

また、前記所定処理は、前記ファームウェア更新情報において前記更新用ファームウェアに付されている署名の検証処理であることとしても良い。これにより、更新用ファームウェアに付されている署名の検証処理を行う署名検証機能を有さないＥＣＵにおいても、署名検証が代行されることにより、セキュリティを確保して適切にファームウェアの更新が実施され得る。

また、前記所定処理は、前記更新用ファームウェアの適用対象の電子制御ユニットにおける更新前のファームウェアの保存処理であることとしても良い。これにより、ファームウェアの更新に際して、十分なメモリを有さない等により、更新前のファームウェアを保存することができないＥＣＵにおいても、更新前のファームウェアの保存処理が代行されることにより、ファームウェアの更新失敗時に、更新前のファームウェアへと復旧できるようになる。

また、前記制御部は、前記複数の電子制御ユニットのうち前記更新用ファームウェアの適用対象でない１つの電子制御ユニットを選定して、選定した当該電子制御ユニットに前記所定処理を実行させることとしても良い。これにより、所定処理を実行可能なＥＣＵを有効活用して、所定処理を行わないＥＣＵにおいて適切にファームウェアの更新が実施され得る。

また、前記制御部は、前記所定処理を前記ゲートウェイ装置において実行するように制御することとしても良い。これにより、ゲートウェイ装置による所定処理の代行によって、所定処理を行わないＥＣＵにおいて適切にファームウェアの更新が実施され得る。

また、前記所定処理は、前記ファームウェア更新情報において前記更新用ファームウェアに付されている署名の検証処理であり、前記制御部は、前記複数の電子制御ユニットのうち、前記更新用ファームウェアの適用対象でなく前記署名の検証用の鍵を有する１つの電子制御ユニットを選定して、選定した当該電子制御ユニットに前記所定処理を実行させることとしても良い。これにより、署名の検証用の鍵を有するＥＣＵを有効活用して、検証用の鍵を有さないＥＣＵにおいて適切にファームウェアの更新が実施され得る。

また、前記複数の電子制御ユニットは、Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＣＡＮ）プロトコルに従って前記バスを介して通信を行うこととしても良い。これにより、ＣＡＮに従う車載ネットワークにおけるＥＣＵのファームウェアの更新が適切に実施され得る。

また、本発明の一態様に係る車載ネットワークシステムは、１以上のバスを介して通信する複数の電子制御ユニットと前記バスに接続されたゲートウェイ装置とを備える車載ネットワークシステムであって、前記ゲートウェイ装置は、当該ゲートウェイ装置が搭載された車両外の外部装置から、前記複数の電子制御ユニットのうち１つの電子制御ユニットを適用対象とした更新用ファームウェアを含むファームウェア更新情報を受信する受信部と、前記更新用ファームウェアの適用対象の電子制御ユニットの所定情報に基づいて当該電子制御ユニットが所定条件を満たすか否かを判定し、所定条件を満たす場合には当該電子制御ユニットにファームウェアの更新に関連する所定処理を実行させ、所定条件を満たさない場合には前記所定処理が当該電子制御ユニット以外で実行されるように制御する制御部とを有する車載ネットワークシステムである。これにより、例えば、ファームウェアの更新を、セキュリティを確保して行うために必要な機能を持たないＥＣＵ等においても、適切にファームウェアの更新が実施され得る。

また、本発明の一態様に係るファームウェア更新方法は、１以上のバスを介して通信する複数の電子制御ユニットを備える車載ネットワークシステムにおいて用いられるファームウェア更新方法であって、前記複数の電子制御ユニットが搭載された車両外の外部装置から、前記複数の電子制御ユニットのうち１つの電子制御ユニットを適用対象とした更新用ファームウェアを含むファームウェア更新情報を受信する受信ステップと、前記更新用ファームウェアの適用対象の電子制御ユニットの所定情報に基づいて当該電子制御ユニットが所定条件を満たすか否かを判定し、所定条件を満たす場合には当該電子制御ユニットにファームウェアの更新に関連する所定処理を実行させ、所定条件を満たさない場合には前記所定処理が当該電子制御ユニット以外で実行されるように制御する制御ステップとを含むファームウェア更新方法である。これにより、適切にファームウェアの更新が実施され得る。

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

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

（実施の形態１）
以下、本発明の実施の形態として、ゲートウェイ装置を含む複数の電子制御ユニット（ＥＣＵ）がバスを介して通信する車載ネットワークシステム１０において用いられるファームウェア更新方法について、図面を用いて説明する。ファームウェア更新方法は、車両に搭載された各ＥＣＵに実装されたファームウェア（ＦＷ：Firmware）を、車両の外部に所在するサーバから配信される新たな更新用ファームウェアで更新する（つまり更新用ファームウェアに置き換える）ための方法である。車載ネットワークシステム１０ではＥＣＵがファームウェアの更新を行う上で、ゲートウェイ装置が、安全で適切なファームウェアの更新のために必要な処理（例えば署名検証処理等）を実行できないＥＣＵの代わりにその処理を代行するファームウェア更新方法が用いられる。これにより、ファームウェアの更新のために必要な処理を実行する機能等を有さないＥＣＵ、或いはその機能を実行できない状態にあるＥＣＵにおいても、適切なファームウェアの更新が可能となる。

［１．１ 車載ネットワークシステム１０の全体構成］
図１は、実施の形態１に係る車載ネットワークシステム１０の全体構成を示す図である。

車載ネットワークシステム１０は、ＣＡＮプロトコルに従って通信するネットワーク通信システムの一例であり、制御装置、センサ、アクチュエータ、ユーザインタフェース装置等の各種機器が搭載された車両におけるネットワーク通信システムである。車載ネットワークシステム１０は、バスを介してフレームに係る通信を行う複数の装置を備え、ファームウェア更新方法を用いる。具体的には図１に示すように車載ネットワークシステム１０は、車両に搭載され各種機器に接続されたＥＣＵ１００ａ～１００ｄ、バス２００ａ、２００ｂ、ゲートウェイ３００と、車両外のネットワーク４００とサーバ５００とを含んで構成される。なお、車載ネットワークシステム１０には、ゲートウェイ３００、ＥＣＵ１００ａ～１００ｄ以外にもいくつものＥＣＵが含まれ得るが、ここでは、便宜上ゲートウェイ３００及びＥＣＵ１００ａ～１００ｄに注目して説明を行う。ＥＣＵは、例えば、プロセッサ（マイクロプロセッサ）、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置である。メモリは、ＲＯＭ、ＲＡＭ等であり、プロセッサにより実行される制御プログラム（ソフトウェアとしてのコンピュータプログラム）を記憶することができる。ファームウェアはこの制御プログラムの全部又は一部であり、例えばＥＥＰＲＯＭ（Electrically Erasable Programmable Read Only Memory）等の不揮発性メモリ（起動ＲＯＭと称する）に記憶される。例えばプロセッサが、制御プログラム（コンピュータプログラム）に従って動作することにより、ＥＣＵは各種機能を実現することになる。なお、コンピュータプログラムは、所定の機能を達成するために、プロセッサに対する指令を示す命令コードが複数個組み合わされて構成されたものである。なお、ファームウェアは、プロセッサ内において命令解釈を行うためのマイクロコードの全部又は一部を含むものであっても良い。

ＥＣＵ１００ａ～１００ｄは、それぞれエンジン１０１、ブレーキ１０２、ドア開閉センサ１０３、窓（ウィンドウ）開閉センサ１０４といった機器に接続されており、その機器の状態を取得し、周期的に状態を表すフレーム（データフレーム）を、バス２００ａ、バス２００ｂ等で構成される車載ネットワークに送信している。

ゲートウェイ３００は、ＥＣＵ１００ａとＥＣＵ１００ｂとが接続されたバス２００ａ、及び、ＥＣＵ１００ｃとＥＣＵ１００ｄとが接続されたバス２００ｂと接続されたゲートウェイ装置としての一種のＥＣＵである。ゲートウェイ３００は一方のバスから受信したフレームを他方のバスに転送する機能を有し、また、ネットワーク４００を介してサーバ５００と通信する機能を有する。

車両外部に所在する外部装置としてのサーバ５００は、ネットワーク４００を介して、ＥＣＵ１００ａ～１００ｄのファームウェアを更新するためのデータであるＦＷ更新情報を配信する機能を有するコンピュータである。ネットワーク４００における通信には、無線通信、或いは、有線通信のいかなる通信プロトコルを適用しても良い。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

［１．３ ゲートウェイ３００の構成］
図３は、ゲートウェイ３００の構成図である。ゲートウェイ３００は、バス間でのフレーム転送、外部のサーバ５００との通信（ＥＣＵ１００ａ～１００ｄ等のファームウェアの更新のためのＦＷ更新情報の受信等）等の機能を実行する。このためゲートウェイ３００は、図３に示すように、フレーム送受信部３１０と、フレーム解釈部３２０と、受信ＩＤ判断部３３０と、受信ＩＤリスト保持部３４０と、フレーム処理部３５０と、転送ルール保持部３６０と、ＦＷ更新処理部３７０と、ファームウェア（ＦＷ）キャッシュ保持部３７１と、ＥＣＵ情報保持部３７２と、署名検証部３７３と、鍵保持部３７４と、外部通信部３７５と、フレーム生成部３８０とを含んで構成される。これらの各構成要素は、ゲートウェイ３００における通信回路、メモリに格納された制御プログラムを実行するプロセッサ、メモリ或いはデジタル回路等により実現される。

フレーム送受信部３１０は、バス２００ａ及びバス２００ｂのそれぞれに対して、ＣＡＮプロトコルに従ったフレームを送受信する。バス２００ａ又はバス２００ｂからフレームを受信し、フレーム解釈部３２０に転送する。また、フレーム送受信部３１０は、フレーム生成部３８０より通知を受けた転送先のバスを示すバス情報及びフレームに基づいて、そのフレームの内容をバス２００ａ又はバス２００ｂに送信する。

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

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

受信ＩＤリスト保持部３４０は、ゲートウェイ３００が受信するＩＤ（メッセージＩＤ）のリストである受信ＩＤリストを保持する。図４は、受信ＩＤリストの一例を示す図である。

フレーム処理部３５０は、転送ルール保持部３６０が保持する転送ルールに従って、受信したフレームのＩＤに応じて、転送するバスを決定し、転送するバスのバス情報と、フレーム解釈部３２０より通知されたメッセージＩＤと、データとをフレーム生成部３８０へ通知する。また、フレーム処理部３５０は、フレーム解釈部３２０より通知されたファームウェアの更新に係る更新結果のデータを、ＦＷ更新処理部３７０へ通知する。なお、フレーム処理部３５０は、ファームウェアの更新に係る更新結果のデータを、転送の対象としない。

転送ルール保持部３６０は、バス毎のフレームの転送についてのルールを表す情報である転送ルールを保持する。図５は、転送ルールの一例を示す図である。

ＦＷ更新処理部３７０は、外部通信部３７５から通知された更新用ファームウェア等のＦＷデータを含むＦＷ更新情報の署名検証を署名検証部３７３へ依頼し、署名検証の結果（成功か否か）を受け取る。ＦＷ更新処理部３７０は、ＥＣＵ情報保持部３７２が保持するＥＣＵ情報のリストに基づいて車載ネットワーク（バス２００ａ、２００ｂ）に接続された各ＥＣＵのうちファームウェアの更新対象となるＥＣＵが、ファームウェアの更新のために必要な処理を実行する機能を有するか否かを区別する。ファームウェアの更新対象となるＥＣＵが、ファームウェアの更新のために必要な処理を実行する機能を有さない場合には、ＦＷ更新処理部３７０は、その機能の代行をゲートウェイ３００で行うように制御する。ファームウェアの更新のために必要な処理を実行する機能の１つは、ＦＷ更新情報において個々のＥＣＵ用のファームウェア（ＦＷ）に係るＦＷデータに付された署名を検証する機能（署名検証機能）である。ファームウェアの更新のために必要な処理を実行する機能の他の１つは、ＥＣＵがファームウェアを更新する際に、更新前のファームウェアをメモリ等の記憶媒体に格納（保存）しておき更新に失敗した場合にその保存しておいたファームウェアを復元する機能（ＦＷキャッシュ機能）である。即ち、ＦＷキャッシュ機能は、更新前のファームウェアの保存処理を行う機能を含む。ＦＷ更新処理部３７０は、ＦＷキャッシュ機能を代行する場合においては、ファームウェアの更新対象のＥＣＵから更新前のファームウェアを受信してＦＷキャッシュ保持部３７１に格納（保存）し、必要に応じてＦＷキャッシュ保持部３７１から保存しておいたファームウェアを取り出してファームウェアの更新対象のＥＣＵが受信できるように送信するよう制御する。ＦＷ更新処理部３７０は、署名検証機能を代行する場合においては、ファームウェアの更新対象のＥＣＵに対応するＦＷデータに付された署名の検証を署名検証部３７３に依頼する。また、ＦＷ更新処理部３７０は、更新用ファームウェアに係るＦＷデータと、更新対象となるＥＣＵが接続されたバスのバス情報とを、フレーム生成部３８０に通知する。また、ＦＷ更新処理部３７０は、フレーム処理部３５０から通知された、ＥＣＵによる通知（更新結果等）を外部通信部３７５に通知する。また、ＦＷ更新処理部３７０は、ファームウェアの更新に際してＥＣＵ１００ａ～１００ｄとの通信に必要となるデータをフレーム生成部３８０へ通知する。なお、ＦＷ更新処理部３７０は、更新用ファームウェアの適用対象（更新対象）のＥＣＵの情報に基づいてそのＥＣＵが所定条件（署名検証機能を有すること、ＦＷキャッシュ機能を有すること等といった条件）を満たすか否かを判定し、所定条件を満たす場合にはそのＥＣＵにファームウェアの更新に関連する所定処理（署名検証の処理、ＦＷキャッシュ機能に係る処理等）を実行させ、所定条件を満たさない場合にはその所定処理がそのＥＣＵ以外（ここではゲートウェイ３００）で実行されるように制御する制御部として機能する。

ＦＷキャッシュ保持部３７１は、例えばゲートウェイ３００における不揮発性メモリ等の記憶領域で実現され、ファームウェアの更新に際して更新対象のＥＣＵであってＦＷキャッシュ機能を有さないＥＣＵ１００ｂ、１００ｄから受信した既存のファームウェアを格納（保存）する等のために用いられる。

ＥＣＵ情報保持部３７２は、バス２００ａ、バス２００ｂに繋がる全てのＥＣＵ（ＥＣＵ１００ａ～１００ｄ）それぞれに関する所定情報であるＥＣＵ情報のリストを保持する。このＥＣＵ情報のリストの一例を図６に示す。

署名検証部３７３は、ＦＷ更新処理部３７０から、ＦＷ更新情報に係る署名検証対象となるデータを受信し、鍵保持部３７４より取得した署名検証用の鍵を用いて署名検証を行ってその検証結果をＦＷ更新処理部３７０へ通知する。

鍵保持部３７４は、サーバ５００から受信するＦＷ更新情報のデータについての署名検証用の鍵を保持する。

外部通信部３７５は、サーバ５００から更新用ファームウェアに係るＦＷデータを含むＦＷ更新情報を受信する受信部としての機能を有し、受信したＦＷ更新情報をＦＷ更新処理部３７０へ通知する。また、外部通信部３７５は、ＦＷ更新処理部３７０から通知された更新結果を、サーバ５００へ送信する。外部通信部３７５は、例えば、ネットワーク４００を介してサーバ５００にアクセスするために必要なサーバ５００のアドレス情報等を予め保持している。なお、ゲートウェイ３００では、サーバ５００から受信したＦＷデータ等を、ＣＡＮプロトコルに則ったフレームに含ませるように必要に応じてフォーマットを変換して、ＥＣＵ１００ａ～１００ｄへ送信し得る。

フレーム生成部３８０は、フレーム解釈部３２０から通知されたエラーフレーム送信の要求に従い、エラーフレームを、フレーム送受信部３１０へ通知して送信させる。また、フレーム生成部３８０は、フレーム処理部３５０から通知されたメッセージＩＤと、データとを用いてフレームを構成し、バス情報とともにフレーム送受信部３１０へ通知する。また、フレーム生成部３８０は、ＦＷ更新処理部３７０から通知された更新用ファームウェアに係るＦＷデータを用いてフレームを構成し、バス情報とともにフレーム送受信部３１０へ通知する。

［１．４ 受信ＩＤリスト例］
図４は、ゲートウェイ３００の受信ＩＤリスト保持部３４０に保持される受信ＩＤリストの一例を示す図である。

図４に例示する受信ＩＤリストは、ＩＤ（メッセージＩＤ）の値が「１」、「２」、「３」及び「４」のいずれかであるメッセージＩＤを含むフレームを選択的に受信して処理するために用いられる。これは一例に過ぎないが、受信ＩＤリストには、ゲートウェイ３００が受信すると定められているフレームのメッセージＩＤが列挙されている。

［１．５ 転送ルール例］
図５は、ゲートウェイ３００の転送ルール保持部３６０が保持する転送ルールの一例を示す。

この転送ルールは、転送元のバスと転送先のバスと転送対象のＩＤ（メッセージＩＤ）
とを対応付けている。図５中の「＊」はメッセージＩＤにかかわらずフレームの転送がなされることを表している。図５の例は、バス２００ａから受信するフレームはメッセージＩＤにかかわらず、バス２００ｂに転送するように設定されていることを示している。また、バス２００ｂから受信するフレームのうちメッセージＩＤが「３」であるフレームのみがバス２００ａに転送されるように設定されていることを示している。

［１．６ ＥＣＵ情報のリスト例］
図６は、ゲートウェイ３００のＥＣＵ情報保持部３７２が保持するＥＣＵ情報のリストの一例を示す。

図６に示すリストは、ＥＣＵ毎のＥＣＵ情報から構成される。ＥＣＵ情報は、例えば、ＥＣＵ－ＩＤと、ＥＣＵの機能種別を示すＥＣＵ種別と、ＥＣＵの製造会社と、ＥＣＵが署名検証機能を有するか否か（つまり署名検証機能の有無）を示す情報と、ＥＣＵがＦＷキャッシュ機能を実現するための記憶媒体の領域としてのＦＷキャッシュを有するか否か（つまりＦＷキャッシュ機能の有無）を示す情報とを含んで構成される。ＥＣＵ－ＩＤは、例えば各ＥＣＵの識別情報であり、例えばシリアル番号等の識別子である。ＥＣＵ情報保持部３７２が保持するＥＣＵ情報のリストは、例えば、ＥＣＵ毎にＥＣＵの処理能力（例えば署名検証機能、ＦＷキャッシュ機能の有無等）を示す情報であると言える。

図６の例は、エンジン１０１に接続されたＥＣＵ１００ａについてのＥＣＵ－ＩＤが「０００１」であり、ＥＣＵ種別が「エンジン」で識別されるエンジン制御用という種別であり、製造会社が「Ａ社」であり、署名検証機能を有しており、ＦＷキャッシュ機能を有していることを示している。また、ブレーキ１０２に接続されたＥＣＵ１００ｂについてのＥＣＵ－ＩＤが「０００２」であり、ＥＣＵ種別が「ブレーキ」で識別されるブレーキ制御用という種別であり、製造会社が「Ｂ社」であり、署名検証機能を有しており、ＦＷキャッシュ機能を有していないことを示している。また、ドア開閉センサ１０３に接続されたＥＣＵ１００ｃについてのＥＣＵ－ＩＤが「０００３」であり、ＥＣＵ種別が「ドア」で識別されるドア開閉制御用という種別であり、製造会社が「Ｃ社」であり、署名検証機能を有しておらず、ＦＷキャッシュ機能を有していることを示している。また、窓（ウィンドウ）開閉センサ１０４に接続されたＥＣＵ１００ａについてのＥＣＵ－ＩＤが「０００４」であり、ＥＣＵ種別が「ウィンドウ」で識別される窓開閉制御用という種別であり、製造会社が「Ｄ社」であり、署名検証機能を有しておらず、ＦＷキャッシュ機能を有していないことを示している。

ＥＣＵ情報保持部３７２が保持するＥＣＵ情報は、製造時に設定されたものであっても良いし、例えばゲートウェイ３００に電力の供給が開始された際に、サーバ５００等の外部装置からゲートウェイ３００が取得したものであっても良い。また、バス２００ａ、２００ｂに接続されたＥＣＵの交換或いはファームウェアの更新等で状態が変化した場合や、車両に新たにＥＣＵが導入されてバス２００ａ又はバス２００ｂに接続された場合等において、ゲートウェイ３００は、新たなＥＣＵ情報を収集してＥＣＵ情報保持部３７２が保持するＥＣＵ情報のリストを更新するようにしても良い。

［１．７ ＥＣＵ１００ａの構成］
図７は、ＥＣＵ１００ａの構成図である。ＥＣＵ１００ａは、署名検証機能及びＦＷキャッシュ機能を有しており、フレーム送受信部１１０と、フレーム解釈部１２０と、受信ＩＤ判断部１３０と、受信ＩＤリスト保持部１４０と、フレーム処理部１５０と、ＦＷ更新処理部１６０と、ＦＷキャッシュ保持部１６１と、署名検証部１６３と、鍵保持部１６４と、データ取得部１７０と、フレーム生成部１８０とを含んで構成される。これらの各構成要素は、ＥＣＵ１００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ、メモリ或いはデジタル回路等により実現される。

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

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

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

受信ＩＤリスト保持部１４０は、ＥＣＵ１００ａが受信するメッセージＩＤのリストである受信ＩＤリストを保持する。この受信ＩＤリストは、例えば上述の図４の例と同様である。

フレーム処理部１５０は、受信したフレームのデータに応じてＥＣＵ毎に異なる処理を行う。例えば、エンジン１０１に接続されたＥＣＵ１００ａは、時速が３０ｋｍを超えた状態でドアが開いている状態だと、アラーム音を鳴らす機能を備える。そして、ＥＣＵ１００ａのフレーム処理部１５０は、他のＥＣＵから受信したデータ（例えばドアの状態を示す情報）を管理し、エンジン１０１から取得された時速に基づいて一定条件下でアラーム音を鳴らす処理等を行う。フレーム処理部１５０はＥＣＵ１００ｂ～ＥＣＵ１００ｄにおいても備えられ、ＥＣＵ１００ｃでは、ブレーキがかかっていない状況でドアが開くとアラーム音を鳴らす機能を備える。ＥＣＵ１００ｂ、１００ｄでは特に何もしない。なお、ＥＣＵ１００ａ～１００ｄは上記以外の機能を備えていても良い。また、フレーム処理部１５０は、ファームウェアの更新用のＦＷデータを取得した場合には、ＦＷ更新処理部１６０へ通知する。

ＦＷ更新処理部１６０は、ゲートウェイ３００から受信してフレーム処理部１５０から通知されたＦＷデータの署名検証を署名検証部１６３へ依頼し、署名検証に成功した場合にＦＷデータに基づいて、ＥＣＵ１００ａの起動ＲＯＭ内のファームウェアを更新する（書き換える）。起動ＲＯＭは、例えばＥＣＵ１００ａのプロセッサでリセット後に実行されるファームウェアの格納先として設定された不揮発性メモリである。起動ＲＯＭ内のファームウェアの更新の際には、ＦＷ更新処理部１６０は、更新失敗時に更新前の状態へと復元可能にするために、例えばＦＷキャッシュ保持部１６１に既存のファームウェアを格納（保存）する。また、ＦＷ更新処理部１６０は、ＦＷデータの署名検証の結果（成否を示す情報）を示すフレーム、及び、ＦＷデータに基づくファームウェアの更新結果を示すフレームを生成して送信するようにフレーム生成部１８０へ通知する。

ＦＷキャッシュ保持部１６１は、例えばＥＣＵ１００ａにおける不揮発性メモリ等の記憶領域で実現され、起動ＲＯＭ内のファームウェアの更新に際して既存のファームウェアを格納（保存）する等のために用いられる。

署名検証部１６３は、ＦＷ更新処理部１６０から、署名検証対象となるＦＷデータを受信し、鍵保持部１６４より取得した署名検証用の鍵を用いて署名検証を行ってその検証結果をＦＷ更新処理部１６０へ通知する。

鍵保持部１６４は、ファームウェアの更新用のＦＷデータの署名検証用の鍵を保持する。

データ取得部１７０は、ＥＣＵにつながっている機器、センサ等の状態を示すデータを取得し、フレーム生成部１８０に通知する。

フレーム生成部１８０は、フレーム解釈部１２０から通知されたエラーフレーム送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部１１０へ通知して送信させる。また、フレーム生成部１８０は、データ取得部１７０より通知されたデータの値に対して、予め定められたメッセージＩＤをつけてフレームを構成し、フレーム送受信部１１０へ通知する。また、フレーム生成部１８０は、ＦＷ更新処理部１６０によるファームウェアの署名検証の結果のフレーム又はファームウェアの更新結果のフレームの生成の指示に応じて、それぞれ予め定められたメッセージＩＤを付したフレームを構成して、フレーム送受信部１１０へ通知する。

［１．８ ＥＣＵ１００ｂの構成］
図８は、ＥＣＵ１００ｂの構成図である。ＥＣＵ１００ｂは、署名検証機能を有するがＦＷキャッシュ機能を有さず、フレーム送受信部１１０と、フレーム解釈部１２０と、受信ＩＤ判断部１３０と、受信ＩＤリスト保持部１４０と、フレーム処理部１５０と、ＦＷ更新処理部１６５と、署名検証部１６３と、鍵保持部１６４と、データ取得部１７０と、フレーム生成部１８０とを含んで構成される。これらの各構成要素は、ＥＣＵ１００ｂにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ、メモリ或いはデジタル回路等により実現される。なお、ＥＣＵ１００ｂの構成要素のうちＥＣＵ１００ａと同様の構成要素については、図８において図７と同一の符号を付しており、ここでは説明を省略する。

ＦＷ更新処理部１６５は、ゲートウェイ３００から受信してフレーム処理部１５０から通知されたＦＷデータの署名検証を署名検証部１６３へ依頼し、そのＦＷデータの署名検証の結果（成否を示す情報）を示すフレームを生成して送信するようにフレーム生成部１８０へ通知する。また、ＦＷ更新処理部１６５は、ゲートウェイ３００からの起動ＲＯＭ内のデータ（ファームウェア）の要求を受信したことをフレーム処理部１５０から通知されると、起動ＲＯＭ内の既存のファームウェアをデータとして含むフレームを生成して送信するようにフレーム生成部１８０へ通知する。この起動ＲＯＭは、例えばＥＣＵ１００ｂのプロセッサでリセット後に実行されるファームウェアの格納先として設定された不揮発性メモリである。また、ＦＷ更新処理部１６５は、ゲートウェイ３００から受信したフレーム処理部１５０から通知された更新ＲＯＭデータ（更新後のファームウェア）により、ＥＣＵ１００ｂの起動ＲＯＭの内容を更新する（書き換える）。また、ＦＷ更新処理部１６５は、ファームウェアの更新結果を示すフレームを生成して送信するようにフレーム生成部１８０へ通知する。

［１．９ ＥＣＵ１００ｃの構成］
図９は、ＥＣＵ１００ｃの構成図である。ＥＣＵ１００ｃは、署名検証機能を有さないがＦＷキャッシュ機能を有しており、フレーム送受信部１１０と、フレーム解釈部１２０と、受信ＩＤ判断部１３０と、受信ＩＤリスト保持部１４０と、フレーム処理部１５０と、ＦＷ更新処理部１６６と、ＦＷキャッシュ保持部１６１と、データ取得部１７０と、フレーム生成部１８０とを含んで構成される。これらの各構成要素は、ＥＣＵ１００ｃにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ、メモリ或いはデジタル回路等により実現される。なお、ＥＣＵ１００ｃの構成要素のうちＥＣＵ１００ａと同様の構成要素については、図９において図７と同一の符号を付しており、ここでは説明を省略する。

ＦＷ更新処理部１６６は、ゲートウェイ３００から受信してフレーム処理部１５０から通知されたＦＷデータに基づいて、ＥＣＵ１００ｃの起動ＲＯＭ内のファームウェアを更新する（書き換える）。起動ＲＯＭは、例えばＥＣＵ１００ｃのプロセッサでリセット後に実行されるファームウェアの格納先として設定された不揮発性メモリである。起動ＲＯＭ内のファームウェアの更新の際には、ＦＷ更新処理部１６６は、更新失敗時に更新前の状態へと復元可能にするために、例えばＦＷキャッシュ保持部１６１に既存のファームウェアを格納（保存）する。また、ＦＷ更新処理部１６６は、ＦＷデータに基づくファームウェアの更新結果を示すフレームを生成して送信するようにフレーム生成部１８０へ通知する。

［１．１０ ＥＣＵ１００ｄの構成］
図１０は、ＥＣＵ１００ｄの構成図である。ＥＣＵ１００ｄは、署名検証機能及びＦＷキャッシュ機能を有しておらず、フレーム送受信部１１０と、フレーム解釈部１２０と、受信ＩＤ判断部１３０と、受信ＩＤリスト保持部１４０と、フレーム処理部１５０と、ＦＷ更新処理部１６７と、データ取得部１７０と、フレーム生成部１８０とを含んで構成される。これらの各構成要素は、ＥＣＵ１００ｄにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ、メモリ或いはデジタル回路等により実現される。なお、ＥＣＵ１００ｄの構成要素のうちＥＣＵ１００ａと同様の構成要素については、図１０において図７と同一の符号を付しており、ここでは説明を省略する。

ＦＷ更新処理部１６７は、ゲートウェイ３００からの起動ＲＯＭ内のデータ（ファームウェア）の要求を受信したことをフレーム処理部１５０から通知されると、起動ＲＯＭ内の既存のファームウェアをデータとして含むフレームを生成して送信するようにフレーム生成部１８０へ通知する。この起動ＲＯＭは、例えばＥＣＵ１００ｄのプロセッサでリセット後に実行されるファームウェアの格納先として設定された不揮発性メモリである。また、ＦＷ更新処理部１６７は、ゲートウェイ３００から受信したフレーム処理部１５０から通知された更新ＲＯＭデータ（更新後のファームウェア）により、ＥＣＵ１００ｄの起動ＲＯＭの内容を更新する（書き換える）。また、ＦＷ更新処理部１６５は、ファームウェアの更新結果を示すフレームを生成して送信するようにフレーム生成部１８０へ通知する。

［１．１１ サーバ５００の構成］
サーバ５００は、車載ネットワークシステム１０が搭載される車両の外部に所在するコンピュータであり、メモリ、ハードディスク等の記憶媒体、プロセッサ、通信回路等を含む。サーバ５００は、ユーザインタフェースとしての入力装置（キーボード等）、ディスプレイ等を備えていても良い。複数の車両それぞれに車載ネットワークに係る複数のＥＣＵが搭載されていることを前提として、サーバ５００は、各種ＥＣＵの製造会社等から提供されたファームウェアを管理し、各車両に更新用ファームウェアを含むＦＷ更新情報を配信する機能を有する。

図１１は、サーバ５００の構成図である。サーバ５００は、同図に示すように、データ送受信部５１０と、配信データ生成部５７０と、ＦＷ保持部５７１と、ＥＣＵ管理情報保持部５７２と、署名生成部５９０と、鍵保持部５９１とを含んで構成される。これらの各構成要素は、サーバ５００における通信回路、メモリに格納された制御プログラムを実行するプロセッサ等により実現される。

データ送受信部５１０は、ゲートウェイ３００と通信し、データを送受信する。データ送受信部５１０は、ゲートウェイ３００に対して、配信データ生成部５７０から通知されたデータ（更新すべきファームウェアを含むＦＷ更新情報）を配信する。また、データ送受信部５１０は、ゲートウェイ３００より、ファームウェアの更新結果を受信した場合には、ＥＣＵ管理情報保持部５７２が保持する車両ＥＣＵ管理情報を更新する。

配信データ生成部５７０は、ゲートウェイ３００に配信するための更新用ファームウェアのパッケージとしてのＦＷ更新情報（配信データ）を生成し、署名生成部５９０に依頼してＦＷ更新情報に対する署名を生成させる。配信データ生成部５７０は、ＦＷ更新情報の生成のために、ＦＷ保持部５７１から各ＥＣＵの最新のファームウェア（ＦＷ）を取得し、ＥＣＵ管理情報保持部５７２から、更新対象となるＥＣＵについての情報を取得する。ＦＷ更新情報（配信データ）のフォーマットについては後述する（図１３参照）。

ＦＷ保持部５７１は、各種ＥＣＵ用のファームウェア（ＦＷ）を保持する。

ＥＣＵ管理情報保持部５７２は、各車両の車載ネットワークにおける各ＥＣＵに関する情報である車両ＥＣＵ管理情報を保持する。車両ＥＣＵ管理情報については後述する（図１２参照）。

署名生成部５９０は、配信データ生成部５７０の依頼を受けて、鍵保持部５９１に保持されている署名用の鍵を用いて、ＦＷ更新情報に対する署名を生成して配信データ生成部５７０に通知する。署名生成部５９０は、例えば、ＦＷ更新情報における各ＦＷデータに対する署名及びＦＷ更新情報全体に対する署名を行い得る。

鍵保持部５９１は、署名生成部５９０がＦＷ更新情報に署名するために用いる鍵を保持する。

［１．１２ 車両ＥＣＵ管理情報］
図１２は、サーバ５００のＥＣＵ管理情報保持部５７２が保持する車両ＥＣＵ管理情報（車両別のＥＣＵ情報のリスト）の一例を示す。

この例の車両ＥＣＵ管理情報は、サーバ５００の管理対象となる車両毎について車両情報とその車両に搭載される各ＥＣＵについてのＥＣＵ情報とを含んで構成される。車両情報は、車両を識別するための識別子（車両ＩＤ）である。車両ＥＣＵ管理情報において車両情報と対応付けたＥＣＵ情報は、ＥＣＵ－ＩＤと、ＥＣＵの機能種別を示すＥＣＵ種別と、ＥＣＵの製造会社と、署名検証機能の有無と、ＦＷキャッシュ機能の有無と、ＥＣＵに実装されたファームウェアのバージョン番号等であるＦＷバージョンと、そのＥＣＵに対応する最新のファームウェアのバージョン番号等である最新ＦＷバージョンとを含んで構成される。車両ＥＣＵ管理情報における、ある車両についての各ＥＣＵ情報は、例えば、その車両のゲートウェイ３００から受信した情報（ファームウェアの更新結果等）と、各種ＥＣＵの製造会社からサーバ５００にアップロードされてＦＷ保持部５７１に保持されたファームウェアについてのＦＷバージョンとに基づいて設定されている。なお、図１２では、一台の車両Ａに関する情報のみを例示しているが、車両ＥＣＵ管理情報は、他の車両についての情報も含み得る。

［１．１３ ＦＷ更新情報のフォーマット例］
図１３は、サーバ５００が配信する配信データとしてのＦＷ更新情報のフォーマットの一例を示す。

ＦＷ更新情報は、ＦＷデータの個数を示すＦＷ数Ｆ１と、１個以上のＦＷデータ（図１３の例では２つの個別ＦＷデータＦ１０、Ｆ２０）と、ＦＷ更新情報（配信データ）全体に対する署名であるＦＷ更新情報署名Ｆ３０とを含む。ＦＷデータＦ１０、Ｆ２０はそれぞれ、更新用のファームウェア（ＦＷ）Ｆ１３、Ｆ２３と、対象となるＥＣＵを識別するＥＣＵ－ＩＤＦ１１、Ｆ２１と、ファームウェアのバージョン番号等を示すＦＷバージョンＦ１２、Ｆ２２と、これらのデータに対する署名であるＦＷデータ署名Ｆ１４、Ｆ２４を含む。ファームウェアＦ１３、Ｆ２３は、ファームウェア自体つまりバイナリデータである。

［１．１４ ＦＷ更新情報の配信及びファームウェアの更新に係る動作例］
以下、車載ネットワークシステム１０におけるＦＷ更新情報の配信及びＥＣＵのファームウェアの更新に係る動作について説明する。

図１４は、サーバ５００が配信データ（ＦＷ更新情報）をゲートウェイ３００に配信してゲートウェイ３００の制御下でファームウェアの更新を行う動作例を示すシーケンス図である。ここでの各シーケンスは、各装置における各処理手順（ステップ）を意味する。このシーケンスは、例えば、新しいファームウェアがサーバ５００にアップロードされて登録されたタイミングで開始され、或いは、配信先の車両のゲートウェイ３００からの配信要求に従って開始され得る。

サーバ５００は、ＥＣＵ管理情報保持部５７２が保持する車両ＥＣＵ管理情報等に基づいて、ゲートウェイ３００に配信する更新用の１つ以上のファームウェアを決定する（ステップＳ１１０１）。この決定により更新用のファームウェアの個数も決定される。

次にサーバ５００は、配信データ生成部５７０でＦＷ更新情報（図１３参照）の生成を行う。即ち、配信データ生成部５７０は、更新用のファームウェアの個数であるＦＷ数分だけ（ステップＳ１１０２）、ＦＷ保持部５７１が保持するファームウェア等のＦＷデータの取得（ステップＳ１１０３）、及び、ＦＷデータに対する署名生成部５９０で生成したＦＷデータ署名の付加（ステップＳ１１０４）を、繰り返す。また、配信データ生成部５７０は、署名生成部５９０によりＦＷ更新情報に対する署名（ＦＷ更新情報署名）を生成させて（ステップＳ１１０５）、その署名を付加したＦＷ更新情報を生成する。

サーバ５００では、ＦＷ更新情報が生成されると、ＦＷ更新情報（配信データ）をデータ送受信部５１０に送信させる（ステップＳ１１０６ａ）。これにより、サーバ５００から、ゲートウェイ３００へとＦＷ更新情報が送信され、ゲートウェイ３００はそのＦＷ更新情報を受信する（ステップＳ１１０６ｂ）。

ゲートウェイ３００は、ＦＷ更新情報を受信すると、署名検証部３７３により、ＦＷ更新情報の署名（ＦＷ更新情報署名）を検証する（ステップＳ１１０７）。そして、ゲートウェイ３００のＦＷ更新処理部３７０は、署名の検証に成功したか否かを判定し（ステップＳ１１０８）、検証に成功しなかった場合には、ＦＷ更新情報を破棄し（ステップＳ１１１０）、この場合にはＦＷ更新情報に基づくファームウェアの更新が行われない。検証に成功した場合には、ゲートウェイ３００は、主としてＦＷ更新処理部３７０により、更新対象に該当するＥＣＵと連携して、ＦＷ更新制御処理を行う（ステップＳ１１０９）。ＦＷ更新制御処理の内容については後述する。

ゲートウェイ３００は、ステップＳ１１０９でのＦＷ更新制御処理を終えた後、或いは、ステップＳ１１１０でのＦＷ更新情報の破棄の後において、ファームウェアの更新結果をサーバ５００に送信する（ステップＳ１１１１ａ）。ファームウェアの更新結果は、例えば更新に成功したか否かを示す情報であり、その情報は例えば更新後におけるファームウェアに係るＦＷバージョンを含んでも良い。これにより、サーバ５００は更新結果を受信する（ステップＳ１１１１ｂ）。なお、サーバ５００は、ファームウェアの更新結果を受信した場合に、そのファームウェアの更新後の状態を表すように、ＥＣＵ管理情報保持部５７２が保持する車両ＥＣＵ管理情報を更新し得る。

［１．１５ ゲートウェイ３００によるＦＷ更新制御処理例］
図１５は、ゲートウェイ３００によるＦＷ更新制御処理の一例を示すフローチャートである。

以下、上述のステップＳ１１０９においてゲートウェイ３００により実行されるＦＷ更新制御処理について、図１５に即して説明する。

ゲートウェイ３００は、ＦＷ更新処理部３７０により、ＦＷ更新情報（図１３参照）におけるＦＷ数を取得し（ステップＳ１２０１）、ステップＳ１２０３～ステップＳ１２１３での処理を、ＦＷ数分繰り返す（ステップＳ１２０２）。

ＦＷ更新処理部３７０は、ＦＷ更新情報のＦＷデータにおけるＥＣＵ－ＩＤを取得し、ファームウェアの更新対象のＥＣＵを特定する（ステップＳ１２０３）。

続いてゲートウェイ３００では、ＦＷ更新処理部３７０が、ＥＣＵ情報保持部３７２が保持するＥＣＵ情報のリスト（図６参照）を参照して、更新対象のＥＣＵ（ステップＳ１２０３で取得したＥＣＵ－ＩＤで識別されるＥＣＵ）が署名検証能力を有するか（署名検証機能を有するか）否かを判定する（ステップＳ１２０４）。

ステップＳ１２０４で更新対象のＥＣＵが署名検証機能を有すると判定した場合には、ＦＷ更新処理部３７０は、そのＥＣＵに送信するためにＦＷデータを含むフレームをフレーム生成部３８０に生成させ、そのフレームをフレーム送受信部３１０がそのＥＣＵが接続されたバスを介してＥＣＵに送信する（ステップＳ１２０５）。そして、ゲートウェイ３００は、そのファームウェアの更新対象のＥＣＵによるＦＷデータに対する署名（ＦＷデータ署名）の検証結果を受信する（ステップＳ１２０６）。

ステップＳ１２０４で更新対象のＥＣＵが署名検証機能を有さないと判定した場合には、ＦＷ更新処理部３７０は、署名検証部３７３によりＦＷデータに対する署名（ＦＷデータ署名）を検証させる（ステップＳ１２０７）。即ち、ファームウェアの更新対象のＥＣＵにおけるＦＷデータ署名についての検証をゲートウェイ３００が代行する。

ステップＳ１２０６又はステップＳ１２０７の後に、ゲートウェイ３００では、ＦＷデータ署名の検証結果を判定し（ステップＳ１２０８）、検証に失敗していればＦＷデータを破棄する（ステップＳ１２０９）。また、検証に成功していれば、ＦＷ更新処理部３７０が、ＥＣＵ情報保持部３７２が保持するＥＣＵ情報のリスト（図６参照）を参照して、更新対象のＥＣＵがＦＷキャッシュを有するか（ＦＷキャッシュ機能を有するか）否かを判定する（ステップＳ１２１０）。

ステップＳ１２１０で更新対象のＥＣＵがＦＷキャッシュ機能を有すると判定した場合には、ＦＷ更新処理部３７０は、そのＥＣＵに未だＦＷデータを送信していなければ、ＦＷデータを含むフレームをフレーム生成部３８０に生成させ、そのフレームをフレーム送受信部３１０がそのＥＣＵが接続されたバスを介してＥＣＵに送信する（ステップＳ１２１１）。これにより、そのファームウェアの更新対象のＥＣＵがそのＦＷデータを受信してファームウェアの更新のための処理を行ってその更新結果をゲートウェイ３００に送信する。そして、ゲートウェイ３００は、そのＥＣＵから送信される更新結果を受信する（ステップＳ１２１２）。

ステップＳ１２１０で更新対象のＥＣＵがＦＷキャッシュ機能を有さないと判定された場合に、ゲートウェイ３００は、更新対象のＥＣＵと連携してＦＷ更新ＧＷ代行処理を行う（ステップＳ１２１３）。このＦＷ更新ＧＷ代行処理については後に説明する。

［１．１６ ＥＣＵ１００ａにおけるファームウェアの更新の動作例］
図１６は、署名検証機能及びＦＷキャッシュ機能を有するＥＣＵ１００ａによるＦＷ更新制御処理の一例を示すフローチャートである。以下、ＥＣＵ１００ａが行うＦＷ更新制御処理について、図１６に即して説明する。

ＥＣＵ１００ａでは、フレーム送受信部１１０が、ゲートウェイ３００から上述のステップＳ１２０５で送信されたＦＷデータを含むフレームを受信する（ステップＳ１３０１）。

ＥＣＵ１００ａのＦＷ更新処理部１６０は、フレーム解釈部１２０及びフレーム処理部１５０を介して、ステップＳ１３０１で受信されたフレームに係るＦＷデータを取得し、署名検証部１６３にＦＷデータにおけるＦＷデータ署名を検証させる（ステップＳ１３０２）。そして、ＥＣＵ１００ａは、そのＦＷデータ署名の検証結果を示すフレームをフレーム送受信部１１０によりバス２００ａに送信する（ステップＳ１３０３）。これにより、ＦＷデータ署名の検証結果がゲートウェイ３００へ通知される。

ＦＷ更新処理部１６０は、ＦＷデータ署名の検証に成功したか否かを区別して（ステップＳ１３０４）、成功しなかった場合にはＦＷデータを破棄して（ステップＳ１３０５）、ファームウェアの更新をしない。

ＦＷデータ署名の検証に成功した場合には、ＦＷ更新処理部１６０は、ＥＣＵ１００ａにおける起動ＲＯＭの内容であるファームウェアを、ＦＷキャッシュ保持部１６１にコピーすることで保存する（ステップＳ１３０６）。

次にＦＷ更新処理部１６０は、ＦＷデータにおけるファームウェア（ＦＷ）により起動ＲＯＭ内のファームウェアの更新を行い（ステップＳ１３０７）、ＥＣＵ１００ａのプロセッサを、リセットすることで再起動する（ステップＳ１３０８）。

ＥＣＵ１００ａでは、起動ＲＯＭからの起動に成功しない場合には、ＦＷキャッシュ保持部１６１の内容による起動がなされるように予め設定されており、ステップＳ１３０８での再起動が成功しない場合に（ステップＳ１３０９）、ＦＷキャッシュ保持部１６１に保存されている更新前のファームウェアが起動される（ステップＳ１３１０）。そして、その更新前のファームウェアの制御下で、ＦＷキャッシュ保持部１６１に保存されている更新前のファームウェアを起動ＲＯＭへコピーすることで起動ＲＯＭの内容を更新前の状態に戻す（ステップＳ１３１１）。

ＥＣＵ１００ａは、ステップＳ１３０８での再起動に成功した場合にはファームウェアの更新に成功した旨を示す更新結果を含むフレームをバス２００ａへ送信し、ステップＳ１３０８での再起動に成功しなかった場合にはステップＳ１３１１の後に、ファームウェアの更新に失敗した旨を示す更新結果を含むフレームをバス２００ａへ送信する（ステップＳ１３１２）。これにより、ファームウェアの更新結果がゲートウェイ３００へ通知される。

［１．１７ ＥＣＵ１００ｂにおけるファームウェアの更新の動作例］
図１７は、署名検証機能を有するがＦＷキャッシュ機能を有さないＥＣＵ１００ｂによるＦＷ更新制御処理の一例を示すフローチャートである。同図において、既述のステップと同様のステップには同じ符号を付している。以下、ＥＣＵ１００ｂが行うＦＷ更新制御処理について、図１７に即して説明する。

ＥＣＵ１００ｂでは、フレーム送受信部１１０が、ゲートウェイ３００から上述のステップＳ１２０５で送信されたＦＷデータを含むフレームを受信する（ステップＳ１３０１）。

ＥＣＵ１００ｂのＦＷ更新処理部１６５は、フレーム解釈部１２０及びフレーム処理部１５０を介して、ステップＳ１３０１で受信されたフレームに係るＦＷデータを取得し、署名検証部１６３にＦＷデータにおけるＦＷデータ署名を検証させる（ステップＳ１３０２）。そして、ＥＣＵ１００ｂは、そのＦＷデータ署名の検証結果を示すフレームをフレーム送受信部１１０によりバス２００ａに送信する（ステップＳ１３０３）。これにより、ＦＷデータ署名の検証結果がゲートウェイ３００へ通知される。

ＦＷ更新処理部１６５は、ＦＷデータ署名の検証に成功したか否かを区別して（ステップＳ１３０４）、成功しなかった場合にはＦＷデータを破棄して（ステップＳ１３０５）、ファームウェアの更新をしない。

ＦＷデータ署名の検証に成功した場合には、ＥＣＵ１００ｂは、ゲートウェイ３００と連携して、後述するＦＷ更新ＧＷ代行処理を行う（ステップＳ１２１３）。ＥＣＵ１００ｂは、ＦＷ更新ＧＷ代行処理によるファームウェアの更新結果を含むフレームをバス２００ａへ送信する（ステップＳ１３１２）。これにより、ファームウェアの更新結果がゲートウェイ３００へ通知される。

［１．１８ ＥＣＵ１００ｃにおけるファームウェアの更新の動作例］
図１８は、署名検証機能を有さないがＦＷキャッシュ機能を有するＥＣＵ１００ｃによるＦＷ更新制御処理の一例を示すフローチャートである。同図において、既述のステップと同様のステップには同じ符号を付している。以下、ＥＣＵ１００ｃが行うＦＷ更新制御処理について、図１８に即して説明する。

ＥＣＵ１００ｃでは、フレーム送受信部１１０が、ゲートウェイ３００から上述のステップＳ１２１１で送信されたＦＷデータを含むフレームを受信する（ステップＳ１３０１）。

ＥＣＵ１００ｃのＦＷ更新処理部１６６は、フレーム解釈部１２０及びフレーム処理部１５０を介して、ステップＳ１３０１で受信されたフレームに係るＦＷデータを取得し、ＥＣＵ１００ｃにおける起動ＲＯＭの内容であるファームウェアを、ＦＷキャッシュ保持部１６１にコピーすることで保存する（ステップＳ１３０６）。

次にＦＷ更新処理部１６６は、ＦＷデータにおけるファームウェア（ＦＷ）により起動ＲＯＭ内のファームウェアの更新を行い（ステップＳ１３０７）、ＥＣＵ１００ｃのプロセッサを、リセットすることで再起動する（ステップＳ１３０８）。

ＥＣＵ１００ｃでは、起動ＲＯＭからの起動に成功しない場合には、ＦＷキャッシュ保持部１６１の内容による起動がなされるように予め設定されており、ステップＳ１３０８での再起動が成功しない場合に（ステップＳ１３０９）、ＦＷキャッシュ保持部１６１に保存されている更新前のファームウェアが起動される（ステップＳ１３１０）。そして、その更新前のファームウェアの制御下で、ＦＷキャッシュ保持部１６１に保存されている更新前のファームウェアを起動ＲＯＭへコピーすることで起動ＲＯＭの内容を更新前の状態に戻す（ステップＳ１３１１）。

ＥＣＵ１００ｃは、ステップＳ１３０８での再起動に成功した場合にはファームウェアの更新に成功した旨を示す更新結果を含むフレームをバス２００ｂへ送信し、ステップＳ１３０８での再起動に成功しなかった場合にはステップＳ１３１１の後に、ファームウェアの更新に失敗した旨を示す更新結果を含むフレームをバス２００ｂへ送信する（ステップＳ１３１２）。これにより、ファームウェアの更新結果がゲートウェイ３００へ通知される。

［１．１９ ＥＣＵ１００ｄにおけるファームウェアの更新の動作例］
図１９は、署名検証機能及びＦＷキャッシュ機能を有さないＥＣＵ１００ｄによるＦＷ更新制御処理の一例を示すフローチャートである。同図において、既述のステップと同様のステップには同じ符号を付している。

ＥＣＵ１００ｄは、ゲートウェイ３００と連携して、後述するＦＷ更新ＧＷ代行処理を行う（ステップＳ１２１３）。ＥＣＵ１００ｄは、ＦＷ更新ＧＷ代行処理によるファームウェアの更新結果を含むフレームをバス２００ｂへ送信する（ステップＳ１３１２）。これにより、ファームウェアの更新結果がゲートウェイ３００へ通知される。

［１．２０ ゲートウェイ３００及びＥＣＵにおけるＦＷ更新ＧＷ代行処理］
以下、ＦＷ更新ＧＷ代行処理について図２０に即して説明する。図２０は、ＥＣＵ（ＥＣＵ１００ｂ、１００ｄ）におけるファームウェアの更新に際して、ゲートウェイ３００が処理の一部を代行するＦＷ更新ＧＷ代行処理の一例を示すシーケンス図である。

まず、ゲートウェイ３００は、ＦＷキャッシュ機能を有さない、ファームウェアの更新対象のＥＣＵに対して、起動ＲＯＭデータ（起動ＲＯＭ内の更新前のファームウェア）を送信するよう要求する（ステップＳ１４０１ａ）。

ＥＣＵはゲートウェイ３００からの要求を受信し（ステップＳ１４０１ｂ）、そのＥＣＵの起動ＲＯＭデータ（起動ＲＯＭ内のファームウェア）を送信する（ステップＳ１４０２ａ）。

ゲートウェイ３００は、ＥＣＵからの起動ＲＯＭデータを、受信して（ステップＳ１４０２ｂ）、ＦＷキャッシュ保持部３７１へコピーを格納し（ステップＳ１４０３）、更新ＲＯＭデータ（例えば更新前のファームウェアに更新用のＦＷデータのファームウェアを適用して更新したデータ）を作成する（ステップＳ１４０４）。

次に、ゲートウェイ３００は、作成した更新ＲＯＭデータを送信し（ステップＳ１４０５ａ）、この更新ＲＯＭデータを、ファームウェアの更新対象のＥＣＵが受信する（ステップＳ１４０５ｂ）。

更新ＲＯＭデータを受信したＥＣＵは、更新ＲＯＭデータにより起動ＲＯＭ内のデータの更新を行い（ステップＳ１４０６）、そのＥＣＵのプロセッサを、リセットすることで再起動する（ステップＳ１４０７）。なお、再起動に際してＥＣＵでは、起動ＲＯＭからの起動に成功しない場合に起動ＲＯＭデータの再送を要求するようには予め設定しておき、ステップＳ１４０７での再起動が成功しない場合に（ステップＳ１４０８）、起動ＲＯＭデータの再送を要求する（ステップＳ１４０９ａ）。これに対応してゲートウェイ３００では起動ＲＯＭデータの再送要求を受信すると（ステップＳ１４０９ｂ）、ＦＷキャッシュ保持部３７１に格納していた起動ＲＯＭデータを送信する（ステップＳ１４１０ａ）。これにより、ＥＣＵは起動ＲＯＭデータを受信して（ステップＳ１４１０ｂ）、その起動ＲＯＭデータで起動ＲＯＭ内のデータの更新を行い（ステップＳ１４０６）、元のファームウェアに戻して再起動する（ステップＳ１４０７）。ステップＳ１４０８で再起動に成功した場合にはＥＣＵはファームウェアの更新の処理を終える。

［１．２１ 実施の形態１の効果］
実施の形態１に係る車載ネットワークシステム１０では、ゲートウェイ３００が、車載ネットワーク（バス２００ａ、２００ｂ）に接続されたＥＣＵのうちファームウェアの更新対象のＥＣＵが更新のための機能（署名検証機能、ＦＷキャッシュ機能）を有していないＥＣＵの代わりにその機能に係る処理を行う（代行する）。これにより、セキュアなファームウェアの更新に必要な機能を持たないＥＣＵでも、安全にファームウェアの更新が可能になる。

（実施の形態２）
以下、実施の形態１で示した車載ネットワークシステム１０の一部を変形した車載ネットワークシステム２０について説明する。

本実施の形態に係る車載ネットワークシステム２０では、ＥＣＵがファームウェアの更新を行う上で、安全で適切なファームウェアの更新のために必要な処理（例えば署名検証処理等）を実行できないＥＣＵの代わりに、ゲートウェイ装置及び他のＥＣＵによりその処理を代行するファームウェア更新方法が用いられる。これにより、ファームウェアの更新のために必要な処理を実行する機能等を有さないＥＣＵ、或いはその機能を実行できない状態にあるＥＣＵにおいても、適切なファームウェアの更新が可能となる。本実施の形態で特に説明しない点については、車載ネットワークシステム２０は、車載ネットワークシステム１０と同様である。

［２．１ 車載ネットワークシステム２０の全体構成］
図２１は、実施の形態２に係る車載ネットワークシステム２０の全体構成を示す図である。

図２１に示すように車載ネットワークシステム２０は、車両に搭載され各種機器に接続されたＥＣＵ１１００ａ～１１００ｄ、バス２００ａ、２００ｂ、ゲートウェイ１３００と、車両外のネットワーク４００とサーバ５００とを含んで構成される。なお、車載ネットワークシステム２０には、ゲートウェイ１３００、ＥＣＵ１１００ａ～１１００ｄ以外にもいくつものＥＣＵが含まれ得るが、ここでは、便宜上ゲートウェイ１３００及びＥＣＵ１１００ａ～１１００ｄに注目して説明を行う。図２１において、実施の形態１で示した車載ネットワークシステム１０と同様の構成要素には、図１と同じ符号を付しており、ここでは説明を省略する。

ＥＣＵ１１００ａ～１１００ｄは、それぞれエンジン１０１、ブレーキ１０２、ドア開閉センサ１０３、窓開閉センサ１０４といった機器に接続されており、その機器の状態を取得し、周期的に状態を表すフレーム（データフレーム）を、バス２００ａ、バス２００ｂ等で構成される車載ネットワークに送信している。なお、ＥＣＵ１１００ａ～１１００ｄに関するＥＣＵ情報は、例えば図６に示すものと同様である。

ゲートウェイ１３００は、ＥＣＵ１１００ａとＥＣＵ１１００ｂとが接続されたバス２００ａ、及び、ＥＣＵ１１００ｃとＥＣＵ１１００ｄとが接続されたバス２００ｂと接続されたゲートウェイ装置としての一種のＥＣＵである。ゲートウェイ１３００は、実施の形態１で示したゲートウェイ３００を部分的に変形したものであり、あるＥＣＵのファームウェアの更新のための処理を、そのＥＣＵ以外のＥＣＵと連携して代行する機能を有する。ゲートウェイ１３００の機能構成は、図３に示したゲートウェイ３００の構成と同様である。なお、ゲートウェイ１３００におけるＦＷ更新処理部３７０は、更新用のファームウェアの適用対象（更新対象）のＥＣＵの情報に基づいてそのＥＣＵが所定条件（署名検証機能を有すること、ＦＷキャッシュ機能を有すること等といった条件）を満たすか否かを判定し、所定条件を満たす場合にはそのＥＣＵにファームウェアの更新に関連する所定処理（署名検証の処理、ＦＷキャッシュ機能に係る処理等）を実行させ、所定条件を満たさない場合にはその所定処理がそのＥＣＵ以外（つまり選定した代行ＥＣＵ）で実行されるように制御する制御部として機能する。また、ゲートウェイ１３００は、ゲートウェイ３００と同様に、一方のバスから受信したフレームを他方のバスに転送する機能を有し、また、ネットワーク４００を介してサーバ５００と通信する機能を有する。サーバ５００は、ＥＣＵ１１００ａ～１１００ｄのファームウェアを更新するためのデータであるＦＷ更新情報を配信する機能を有する。

［２．２ ゲートウェイ１３００によるＦＷ更新制御処理例］
車載ネットワークシステム２０においても、車載ネットワークシステム１０と同様に、サーバ５００からＦＷ更新情報が配信されゲートウェイ１３００の制御下でＥＣＵがファームウェアの更新を行う（図１４参照）。

図２２は、ゲートウェイ１３００によるＦＷ更新制御処理の一例を示すフローチャートである。このＦＷ更新制御処理は、サーバ５００から配信されたＦＷ更新情報を受信したゲートウェイ１３００で実行される図１４のステップＳ１１０９に相当する処理である。なお、実施の形態１のＦＷ更新制御処理（図１５参照）と同様のステップについては、図２２において図１５と同じ符号を付しており、ここでは説明を適宜省略する。

ゲートウェイ１３００は、ＦＷ更新処理部３７０により、ＦＷ更新情報（図１３参照）におけるＦＷ数を取得し（ステップＳ１２０１）、ステップＳ１２０３～ステップＳ１２１２、Ｓ２２０７、Ｓ２２１３等についての処理を、ＦＷ数分繰り返す（ステップＳ１２０２）。

ゲートウェイ１３００は、ステップＳ１２０３でＦＷ更新情報のＦＷデータのＥＣＵ－ＩＤによりファームウェアの更新対象のＥＣＵを特定し、ＥＣＵ情報保持部３７２が保持するＥＣＵ情報のリスト（図６参照）を参照して、更新対象のＥＣＵ署名検証機能を有するか否かを判定する（ステップＳ１２０４）。

ステップＳ１２０４で更新対象のＥＣＵが署名検証機能を有さないと判定した場合には、ゲートウェイ１３００、後述する署名検証ＥＣＵ代行処理を行う（ステップＳ２２０７）。この署名検証ＥＣＵ代行処理によりゲートウェイ１３００は、ファームウェアの更新対象のＥＣＵにおけるＦＷデータ署名についての検証を他のＥＣＵに代行させる。

ステップＳ１２０６又はステップＳ２２０７の後に、ゲートウェイ１３００では、ＦＷデータ署名の検証結果を判定し（ステップＳ１２０８）、検証に失敗していればＦＷデータを破棄する（ステップＳ１２０９）。また、検証に成功していれば、ＥＣＵ情報のリスト（図６参照）を参照して、更新対象のＥＣＵがＦＷキャッシュを有するか（ＦＷキャッシュ機能を有するか）否かを判定する（ステップＳ１２１０）。

ステップＳ１２１０で更新対象のＥＣＵがＦＷキャッシュ機能を有さないと判定された場合に、ゲートウェイ１３００は、後述するＦＷ更新ＥＣＵ代行処理を行う（ステップＳ２２１３）。

［２．３ 署名検証ＥＣＵ代行処理例］
図２３は、ゲートウェイ１３００による署名検証ＥＣＵ代行処理の一例を示すフローチャートである。

ゲートウェイ１３００は、ＥＣＵ情報保持部３７２が保持するＥＣＵ情報のリスト（図６参照）に基づいて、ファームウェアの更新対象のＥＣＵとは別の、ファームウェア更新に伴う処理の実行機能を有するＥＣＵを、その処理を代行するＥＣＵ（代行ＥＣＵ）として選定する（ステップＳ２２００）。具体的には、署名検証ＥＣＵ代行処理においては、署名検証機能を有するＥＣＵ（例えば署名の検証用の鍵を有するＥＣＵ）を、署名検証機能に係る処理を代行する代行ＥＣＵとして選定する。

ゲートウェイ１３００では、ステップＳ２２００で選定した代行ＥＣＵに対して、ＦＷ更新処理部３７０が、その代行ＥＣＵに送信するためにＦＷデータを含むフレームをフレーム生成部３８０に生成させ、そのフレームをフレーム送受信部３１０がその代行ＥＣＵが接続されたバスを介して代行ＥＣＵに送信する（ステップＳ１２０５）。そして、ゲートウェイ１３００は、その代行ＥＣＵによるＦＷデータに対する署名（ＦＷデータ署名）の検証結果を受信する（ステップＳ１２０６）。

［２．４ ゲートウェイ１３００及びＥＣＵにおけるＦＷ更新ＥＣＵ代行処理例］
図２４は、ゲートウェイ１３００及びＥＣＵ（ＥＣＵ１１００ａ、１１００ｄ）によるＦＷ更新ＥＣＵ代行処理の一例を示すシーケンス図である。同図の例は、ＦＷキャッシュ機能を有さないＥＣＵ１１００ｄの代わりに、ＦＷキャッシュ機能をＥＣＵ１１００ａが代行する例を示す。なお、実施の形態１において図２１で示したステップと同様のステップについては、図２４でも同じ符号を付しており、ここでは説明を適宜省略する。

ゲートウェイ１３００は、ＥＣＵ情報保持部３７２が保持するＥＣＵ情報のリスト（図６参照）に基づいて、ファームウェアの更新対象のＥＣＵとは別の、ファームウェア更新に伴う処理の実行機能を有するＥＣＵを、その処理を代行するＥＣＵ（代行ＥＣＵ）として選定する（ステップＳ２２００）。具体的には、ＦＷ更新ＥＣＵ代行処理においては、ＦＷキャッシュ機能を有するＥＣＵ１１００ａを、ＦＷキャッシュ機能に係る処理を代行する代行ＥＣＵとして選定する。

次にゲートウェイ１３００は、ファームウェアの更新対象のＥＣＵ１１００ｄに対するＦＷキャッシュ機能を代行する代行ＥＣＵであるＥＣＵ１１００ａに対して、バス２００ａを介してＦＷデータを送信する（ステップＳ２４００ａ）。ＥＣＵ１１００ａは、そのＦＷデータを受信し（ステップＳ２４００ｂ）、ＦＷキャッシュ機能に係る代行ＥＣＵとして機能すべきことを認識して、起動ＲＯＭデータの受信を待つ。

続いて、ゲートウェイ１３００は、ＦＷキャッシュ機能を有さない、ファームウェアの更新対象のＥＣＵ１１００ｄに対して、起動ＲＯＭデータ（起動ＲＯＭ内の更新前のファームウェア）を送信するよう要求する（ステップＳ２４０１ａ）。更新対象のＥＣＵ１１００ｄはゲートウェイ１３００からの要求を受信し（ステップＳ２４０１ｂ）、ＥＣＵ１１００ｄの起動ＲＯＭデータ（起動ＲＯＭ内のファームウェア）を送信する（ステップＳ２４０２ａ）。ＥＣＵ１１００ｄからバス２００ｂへ送信された起動ＲＯＭデータ（起動ＲＯＭ内のファームウェア）はゲートウェイ１３００により転送されてバス２００ａを介してＥＣＵ１１００ａに受信される（ステップＳ２４０２ｂ）。なお、図２４では、ゲートウェイ１３００によるバス間でのフレームの転送の処理を、省略しており、以下、バス間でのフレームの転送については説明を省略する。

ＥＣＵ１１００ａは、ＥＣＵ１１００ｄからの起動ＲＯＭデータを、受信して（ステップＳ２４０２ｂ）、ＦＷキャッシュ保持部３７１へコピーを格納し（ステップＳ１４０３）、起動ＲＯＭデータ及びＦＷデータに基づいて更新ＲＯＭデータを作成する（ステップＳ１４０４）。

次に、ＥＣＵ１１００ａは、作成した更新ＲＯＭデータを送信し（ステップＳ２４０５ａ）、この更新ＲＯＭデータを、ＥＣＵ１１００ｄが受信する（ステップＳ２４０５ｂ）。

更新ＲＯＭデータを受信したＥＣＵ１１００ｄは、更新ＲＯＭデータにより起動ＲＯＭ内のデータの更新を行い（ステップＳ１４０６）、ＥＣＵ１１００ｄのプロセッサを、リセットすることで再起動する（ステップＳ１４０７）。なお、再起動に際してＥＣＵ１１００ｄでは、起動ＲＯＭからの起動に成功しない場合に起動ＲＯＭデータの再送を要求するようには予め設定しておき、ステップＳ１４０７での再起動が成功しない場合に（ステップＳ１４０８）、起動ＲＯＭデータの再送を要求する（ステップＳ２４０９ａ）。これに対応してＥＣＵ１１００ａでは、起動ＲＯＭデータの再送要求を受信すると（ステップＳ２４０９ｂ）、ＦＷキャッシュ保持部３７１に格納していた起動ＲＯＭデータを送信する（ステップＳ２４１０ａ）。これにより、ＥＣＵ１１００ｄは、起動ＲＯＭデータを受信して（ステップＳ２４１０ｂ）、その起動ＲＯＭデータで起動ＲＯＭ内のデータの更新を行い（ステップＳ１４０６）、元のファームウェアに戻して再起動する（ステップＳ１４０７）。ステップＳ１４０８で再起動に成功した場合にはＥＣＵ１１００ｄはファームウェアの更新の処理を終える。

［２．５ 実施の形態２の効果］
実施の形態２に係る車載ネットワークシステム２０では、ゲートウェイ１３００が、車載ネットワーク（バス２００ａ、２００ｂ）に接続されたＥＣＵのうちファームウェアの更新対象のＥＣＵが更新のための機能（署名検証機能、ＦＷキャッシュ機能）を有していないＥＣＵの代わりにその機能に係る処理を代行可能な他のＥＣＵを選定して代行させるように制御する。これにより、ＥＣＵのリソースを有効活用し、セキュアなファームウェアの更新に必要な機能を持たないＥＣＵでも、安全にファームウェアの更新が可能になる。そして、ゲートウェイ１３００が代行能力を保持する必要がなくなり、これはコスト削減の面で有用である。

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

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

また、ＥＣＵ１００ａ～１００ｄ、１１００ａ～１１００ｄ等のＥＣＵのうち、複数のＥＣＵが、１つの物理的な装置（コンピュータ）等により構築される仮想環境により、実現されていても良い。図２５は、ＥＣＵの構成例としてのコンピュータ８００で実現される仮想環境のソフトウェア構成の一例を示す図である。

コンピュータ８００において動作するソフトウェアは、同図に示すように、仮想マシンモニタ８０１と、仮想マシン８０２、８０３、８０４、８０５と、仮想ハードウェア８１０、８２０、８３０、８４０と、汎用ＯＳ（オペレーティングシステム）８１１、８２１と、ＲＴＯＳ（リアルタイムオペレーティングシステム）８３１と、ファームウェア８４１と、アプリ（アプリケーションプログラム）Ａ８１２と、アプリＢ８１３と、アプリＣ８１４と、アプリＤ８２２と、アプリＥ８３２とを含む。

コンピュータ８００は、コンピュータであり、プロセッサ上でソフトウェア（仮想マシンモニタ８０１等）を実行する。仮想マシンモニタ８０１は、その上で互いに独立して動作するように仮想マシン８０２～８０５を制御する仮想マシン制御機能、その仮想マシンに対してメモリやＣＰＵ等のハードウェアリソースを割り当てて管理するリソース管理機能、仮想マシンからの要求に従ってデバイスへアクセスするデバイスアクセス機能、仮想マシンをスケジューリングするスケジューリング機能等を有する。仮想マシン８０２～８０５はそれぞれ、仮想ハードウェア、ＯＳ、アプリ、或いは、ファームウェアを含んで構成され、仮想マシンモニタ８０１によりそれぞれ独立に実行される。仮想ハードウェア８１０、８２０、８３０、８４０は、それぞれの仮想マシンに仮想的にハードウェアの機能を提供し、また、ＩＰＬ（Initial Program Loader）、ＢＩＯＳ（Basic Input/Output System）を含み得る。汎用ＯＳ８１１は、アプリ（アプリＡ８１２、アプリＢ８１３、アプリＣ８１４）をメモリ上にロードして実行する、或いは、その各アプリをメモリ上から削除（アンロード）する機能を有し、各アプリに対して、ＣＡＮプロトコルによるネットワーク通信機能を提供する。汎用ＯＳ８２１も同様である。ＲＴＯＳ８３１は、リアルタイム性を重視するアプリを動作させるためのＯＳである。アプリＡ８１２、アプリＢ８１３、アプリＣ８１４、アプリＤ８２２、アプリＥ８３２は、カーナビゲーション機能、運転支援機能、ステアリング制御機能、エンジン制御機能、ブレーキ制御機能、センサ情報（トルク、角度、速度、回転数等）の取得機能等といった各種の自動車用の機能を有する。これらの自動車用の機能群のそれぞれは、１つのアプリにより実行されても良いし、複数のアプリで実行されていても良い。ファームウェア８４１は、ＯＳを必要としない機能を動作させるソフトウェア等である。なお、ファームウェア８４１は、ＯＳを含んでいても良く、他のアプリの動作環境となって他のアプリの実行を制御する機能を有するものであっても良い。なお、図２５で示した汎用ＯＳ８１１、８２１或いはＲＴＯＳ８３１上で動作するアプリの数は、一例に過ぎず、より多くのアプリが動作しても良い。また、汎用ＯＳが動作する仮想マシンが２つと、ＲＴＯＳが動作する仮想マシンが１つ、ファームウェアが動作する仮想マシンが１つの場合を図示しているが、これは一例に過ぎない。仮想環境を、例えば、ファームウェアが動作する仮想マシンだけで構成しても良いし、ファームウェアが動作する仮想マシンとＲＴＯＳが動作する仮想マシンとだけで構成しても良い。

コンピュータ８００では、ＥＣＵ１００ａ～１００ｄ、１１００ａ～１１００ｄ等のうち全部又は一部の複数のＥＣＵのそれぞれを、上述の仮想マシン８０２～８０５等といった１つの仮想マシンで実現する。例えば、仮想マシンモニタ８０１上で仮想マシン８０５を複数（動作環境を構成するＥＣＵの数分）生成して動作させ、それぞれの仮想マシン８０５の仮想ハードウェア８４０で１つのＥＣＵのハードウェア面の動作を実現し、例えば、ファームウェア８４１はそのＥＣＵに実装されているファームウェアと同一の内容とする。例えば、仮想マシンモニタ８０１は、その上で動作する複数の仮想ハードウェア間で、ＥＣＵ間でのバスを介した通信を実現するように構成される。

（２）上記実施の形態では、外部通信部３７５（外部通信機能）を有するゲートウェイ３００、１３００が、車両外のネットワーク４００を介してサーバ５００と通信したが、これは一例に過ぎない。例えば、ゲートウェイ３００、１３００は、外部との通信機能を持つ別のＥＣＵ（例えばヘッドユニット等）を介して、サーバ５００と通信することとしても良い。ヘッドユニットは、比較的高性能なプロセッサを備えるＥＣＵの一種であり、自動車のインパネ（インストルメントパネル）等に設けられた液晶ディスプレイ等の表示装置を含み、車両の運転者への報知等を行い得る装置である。なお、車載ネットワークには、ＯＢＤ２（On-Board Diagnostics２）等と呼ばれる、診断ツール等の外部装置と通信するインタフェースである診断ポートが存在し、ＥＣＵの診断に利用される。そこで、ゲートウェイ３００、１３００は、例えば、サーバ５００と通信可能でありかつ診断ポートと接続する外部装置と通信することで間接的にサーバ５００と通信することとしても良い。これらの場合において、ゲートウェイ３００、１３００は必ずしも車両外部と通信するための外部通信機能を有さなくても良く、他のＥＣＵ或いは外部装置を介してゲートウェイ３００、１３００とサーバ５００との間では、ＦＷ更新情報等の授受が可能となる。また、ゲートウェイ３００、１３００は、自装置或いは他のＥＣＵに接続された外部の記憶媒体（不揮発性メモリ等）に記憶されたＦＷ更新情報を取得しても良い。

（３）上記実施の形態では、ＣＡＮプロトコルに従って通信するネットワーク通信システムの例として車載ネットワークを示した。本発明に係る技術は、車載ネットワークに限定されるものではなく、ロボット、産業機器等のネットワークその他、車載ネットワーク以外のＣＡＮプロトコルに従って通信するネットワーク通信システムにも適用可能である。また、ＣＡＮプロトコルは、オートメーションシステム内の組み込みシステム等に用いられるＣＡＮＯｐｅｎ、或いは、ＴＴＣＡＮ（Time-Triggered CAN）、ＣＡＮＦＤ（CAN with Flexible Data Rate）等の派生的なプロトコルも包含する広義の意味のものと扱われるべきである。また、上記実施の形態では、ＣＡＮプロトコルに基づいてバスでファームウェアに関するデータ（フレーム）を送受信する例を示したが、別のプロトコルを適用しても良く、ファームウェアに係るデータを通信するための通信路及び通信方式として任意のものを利用可能である。

（４）上記実施の形態では、データ（ＦＷデータ、ＦＷ更新情報等）の完全性を担保するために、データに対して署名を付した構成を用いたが、更に、秘匿性を担保するためにデータの暗号化を行っても良い。署名用の鍵と暗号化用の鍵とを別個の鍵としても良い。

（５）上記実施の形態では、ＦＷ更新情報に対する署名の生成とＦＷデータに対する署名の生成とに際して、同じ鍵を使用したが、それぞれ別の鍵を用いても良い。例えば、配信データとしてのＦＷ更新情報の全体に対する署名（ＦＷ更新情報署名）は、自動車メーカが持つ鍵を用いて生成し、個別のＦＷデータに対する署名（ＦＷデータ署名）は、そのＦＷデータに係るファームウェアを実装するＥＣＵの製造会社（或いはそのファームウェアの製造会社）が持つ鍵を用いて生成されることとしても良い。これに対応して、ＥＣＵの署名の検証をゲートウェイ３００で代行するために、ゲートウェイ３００は必要な鍵を予め保持するように構成される。また、サーバ５００においてＦＷデータ署名について署名に用いた鍵がファームウェアを実装するＥＣＵの製造会社毎に定まる鍵であることとした場合には、ゲートウェイ１３００は、ＥＣＵ情報のリスト（図６参照）に基づいて、ファームウェアの更新対象のＥＣＵと同じ製造会社のＥＣＵ（その製造会社の署名検証に必要な鍵を保持しているＥＣＵ）を代行ＥＣＵとして選定することとしても良い。また、ＥＣＵ情報として、ＥＣＵが署名検証機能を代行する機能を有するか否か（自装置以外のファームウェアについて署名検証を代行するための鍵を有しているか否か）の情報を含ませておき、ゲートウェイ１３００はその情報に基づいて代行ＥＣＵを選定しても良い。

（６）上記実施の形態で、ゲートウェイ３００、１３００がファームウェアの更新対象のＥＣＵの処理をそのＥＣＵ以外のＥＣＵ或いはゲートウェイで代行させるよう制御するか更新対象のＥＣＵに実行させるか（つまり代行が必要か否か）を、ＥＣＵ情報保持部３７２が保持するＥＣＵ情報のリストに基づいて判定することを示した。この代行が必要か否かの判定（更新対象のＥＣＵが所定条件を満たすか否かの判定）は、例えば、ＥＣＵ毎にＥＣＵの処理能力（例えば所定処理の実行機能を有するか否か）を示す情報に基づいてなされ得る。所定条件を満たさない場合に代行が必要になる。所定処理の実行機能を有するか否かは、例えば、署名検証機能、ＦＷキャッシュ機能の有無等である。ゲートウェイ３００、１３００のＦＷ更新処理部３７０（制御部）は、更新用ファームウェアの適用対象（つまり更新対象）のＥＣＵが、所定処理の実行機能を有する場合に所定条件を満たし、所定処理の実行機能を有さない場合に所定条件を満たさないとして判定を行い得る。このＥＣＵの処理能力を示す情報は、署名検証機能、ＦＷキャッシュ機能の有無の他に、ＥＣＵのメモリ容量、処理性能等の情報であっても良い。また、この判定を、ゲートウェイ３００、１３００は、車載ネットワークにおける通信負荷の状況、ＥＣＵのプロセッサの負荷状況等に基づいて行っても良く、例えば、処理能力があってもプロセッサの負荷が一定程度より高い状況では、代行が必要であると判定しても良い。

（７）上記実施の形態で示した更新用のファームウェア（バイナリデータ）は、ＥＣＵに実装されるファームウェアの全体であってもその一部であっても良い。更新用のファームウェアがＥＣＵに実装されるファームウェアの一部である場合において、ＥＣＵ内の既存のファームウェアの一部に上書きされる。この場合には、更新用のファームウェアは、差分データ（バイナリデータ）と、どの部分に適用されるかを示す情報（例えばアドレス情報等）とを含んで構成され得る。この場合において、ゲートウェイ３００、更新対象に該当するＥＣＵ、或いは、代行ＥＣＵにおいて、差分データと既存のファームウェアとをマージしてから、ＥＣＵの起動ＲＯＭにおけるファームウェアの置き換えを行っても良い。

（８）上記実施の形態で示した各種処理の手順（例えば図１４～図２０、図２２～図２４に示した手順等）の実行順序は、必ずしも、上述した通りの順序に制限されるものではなく、発明の要旨を逸脱しない範囲で、実行順序を入れ替えたり、複数の手順を並列に行ったり、その手順の一部を省略したりすることができる。

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

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

（１１）本発明の一態様としては、例えば図１４～図２０、図２２～図２４等に示す処理手順の全部又は一部を含むファームウェア更新方法であるとしても良い。ファームウェア更新方法は、例えば、ステップＳ１１０６ｂ等の、車両外の外部装置から、更新用ファームウェアを含むＦＷ更新情報を受信する受信ステップを含む。またファームウェア更新方法は、例えば、ステップＳ１２０４～Ｓ１２０７或いはステップＳ１２１０～Ｓ１２１３等の、ファームウェアの更新対象のＥＣＵが所定条件を満たすか否かを判定し、所定条件を満たす場合にはそのＥＣＵにファームウェアの更新に関連する所定処理を実行させ、所定条件を満たさない場合には所定処理がそのＥＣＵ以外で実行されるように制御する制御ステップを含む。また、この方法をコンピュータにより実現するコンピュータプログラム（制御プログラム）であるとしても良いし、前記コンピュータプログラムからなるデジタル信号であるとしても良い。例えば、ファームウェア更新方法における受信ステップ、制御ステップを含むファームウェア更新処理を実行するための制御プログラムであることとしても良い。また、本発明の一態様としては、前記コンピュータプログラム又は前記デジタル信号をコンピュータで読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＢＤ（Blu-ray（登録商標） Disc）、半導体メモリ等に記録したものとしても良い。また、これらの記録媒体に記録されている前記デジタル信号であるとしても良い。また、本発明の一態様としては、前記コンピュータプログラム又は前記デジタル信号を、電気通信回線、無線又は有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしても良い。また、本発明の一態様としては、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、前記マイクロプロセッサは、前記コンピュータプログラムに従って動作するとしても良い。また、前記プログラム若しくは前記デジタル信号を前記記録媒体に記録して移送することにより、又は、前記プログラム若しくは前記デジタル信号を、前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしても良い。

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

本発明は、車載ネットワークに接続されたＥＣＵのファームウェアの更新を適切に行うために利用可能である。

１０、２０ 車載ネットワークシステム
１００ａ～１００ｄ、１１００ａ～１１００ｄ 電子制御ユニット（ＥＣＵ）
１０１ エンジン
１０２ ブレーキ
１０３ ドア開閉センサ
１０４ 窓（ウィンドウ）開閉センサ
１１０、３１０ フレーム送受信部
１２０、３２０ フレーム解釈部
１３０、３３０ 受信ＩＤ判断部
１４０、３４０ 受信ＩＤリスト保持部
１５０、３５０ フレーム処理部
１６０、１６５～１６７、３７０ ＦＷ更新処理部
１６１、３７１ ＦＷキャッシュ保持部
１６３、３７３ 署名検証部
１６４、３７４、５９１ 鍵保持部
１７０ データ取得部
１８０、３８０ フレーム生成部
２００ａ、２００ｂ バス
３００、１３００ ゲートウェイ
３６０ 転送ルール保持部
３７２ ＥＣＵ情報保持部
３７５ 外部通信部
４００ ネットワーク
５００ サーバ
５１０ データ送受信部
５７０ 配信データ生成部
５７１ ＦＷ保持部
５７２ ＥＣＵ管理情報保持部
５９０ 署名生成部
８００ コンピュータ
８０１ 仮想マシンモニタ
８０２～８０５ 仮想マシン
８１０、８２０、８３０、８４０ 仮想ハードウェア
８４１ ファームウェア

Claims (6)

1. 車両に搭載された複数の電子制御ユニットが通信に用いるネットワークに接続されたゲートウェイ装置であって、
   前記複数の電子制御ユニットのうち１つの電子制御ユニットを適用対象とした更新用ファームウェアを含むファームウェア更新情報を取得する取得部と、
   前記更新用ファームウェアの適用対象の電子制御ユニットの所定情報に基づいて前記電子制御ユニットが所定条件を満たすか否かを判定し、所定条件を満たす場合には前記電子制御ユニットにファームウェアの更新に関連する所定処理を実行させ、所定条件を満たさない場合には前記所定処理が前記電子制御ユニット以外で実行されるように制御する制御部とを備え、
   前記所定情報は、前記更新用ファームウェアの適用対象の電子制御ユニットの処理能力を示し、
   前記所定処理は、前記ファームウェア更新情報において前記更新用ファームウェアに付されている署名の検証処理であり、
   前記制御部は、
   前記電子制御ユニットが処理能力を有し、前記電子制御ユニットのプロセッサの負荷が一定程度以下の場合、前記所定処理を前記電子制御ユニットで実行させ、
   前記電子制御ユニットが処理能力を有していない場合、または、前記電子制御ユニットが処理能力を有していても前記電子制御ユニットのプロセッサの負荷が一定程度より高い場合、前記複数の電子制御ユニットのうち、前記更新用ファームウェアの適用対象でなく前記署名の検証用の鍵を有する１つの電子制御ユニットを選定して、選定した前記電子制御ユニットに前記所定処理を実行させるように制御する、
   ゲートウェイ装置。
2. 前記所定情報は、前記更新用ファームウェアの適用対象の電子制御ユニットの前記所定処理の実行機能を有するか否かを示し、
   前記制御部は、前記更新用ファームウェアの適用対象の電子制御ユニットが、前記所定処理の実行機能を有し、前記電子制御ユニットのプロセッサの負荷が一定程度以下の場合に前記所定処理を前記電子制御ユニットで実行させ、前記所定処理の実行機能を有さない場合、または、前記電子制御ユニットが前記所定処理の実行機能を有していても前記電子制御ユニットのプロセッサの負荷が一定程度より高い場合、前記所定処理を前記電子制御ユニット以外で実行させるように制御する、
   請求項１記載のゲートウェイ装置。
3. 前記所定処理を前記電子制御ユニット以外で実行させるように制御することは、前記所定処理を前記ゲートウェイ装置において実行するように制御することである
   請求項１又は２に記載のゲートウェイ装置。
4. 前記複数の電子制御ユニットは、Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＣＡＮ）プロトコルに従って前記ネットワークを介して通信を行う
   請求項１～３のいずれか一項に記載のゲートウェイ装置。
5. １以上のネットワークを介して通信する複数の電子制御ユニットと前記ネットワークに接続されたゲートウェイ装置とを備える車載ネットワークシステムであって、
   前記ゲートウェイ装置は、
   前記複数の電子制御ユニットのうち１つの電子制御ユニットを適用対象とした更新用ファームウェアを含むファームウェア更新情報を取得する取得部と、
   前記更新用ファームウェアの適用対象の電子制御ユニットの所定情報に基づいて前記電子制御ユニットが所定条件を満たすか否かを判定し、所定条件を満たす場合には前記電子制御ユニットにファームウェアの更新に関連する所定処理を実行させ、所定条件を満たさない場合には前記所定処理が前記電子制御ユニット以外で実行されるように制御する制御部とを有し、
   前記所定情報は、前記更新用ファームウェアの適用対象の電子制御ユニットの処理能力を示し、
   前記所定処理は、前記ファームウェア更新情報において前記更新用ファームウェアに付されている署名の検証処理であり、
   前記制御部は、
   前記電子制御ユニットが処理能力を有し、前記電子制御ユニットのプロセッサの負荷が一定程度以下の場合、前記所定処理を前記電子制御ユニットで実行させ、
   前記電子制御ユニットが処理能力を有していない場合、または、前記電子制御ユニットが処理能力を有していても前記電子制御ユニットのプロセッサの負荷が一定程度より高い場合、前記複数の電子制御ユニットのうち、前記更新用ファームウェアの適用対象でなく前記署名の検証用の鍵を有する１つの電子制御ユニットを選定して、選定した前記電子制御ユニットに前記所定処理を実行させるように制御する、
   車載ネットワークシステム。
6. １以上のネットワークを介して通信する複数の電子制御ユニットを備える車載ネットワークシステムにおいて用いられるファームウェア更新方法であって、
   前記複数の電子制御ユニットのうち１つの電子制御ユニットを適用対象とした更新用ファームウェアを含むファームウェア更新情報を取得する取得ステップと、
   前記更新用ファームウェアの適用対象の電子制御ユニットの所定情報に基づいて前記電子制御ユニットが所定条件を満たすか否かを判定し、所定条件を満たす場合には前記電子制御ユニットにファームウェアの更新に関連する所定処理を実行させ、所定条件を満たさない場合には前記所定処理が前記電子制御ユニット以外で実行されるように制御する制御ステップとを含み、
   前記所定情報は、前記更新用ファームウェアの適用対象の電子制御ユニットの処理能力を示し、
   前記所定処理は、前記ファームウェア更新情報において前記更新用ファームウェアに付されている署名の検証処理であり、
   前記制御ステップは、
   前記電子制御ユニットが処理能力を有し、前記電子制御ユニットのプロセッサの負荷が一定程度以下の場合、前記所定処理を前記電子制御ユニットで実行させ、
   前記電子制御ユニットが処理能力を有していない場合、または、前記電子制御ユニットが処理能力を有していても前記電子制御ユニットのプロセッサの負荷が一定程度より高い場合、前記複数の電子制御ユニットのうち、前記更新用ファームウェアの適用対象でなく前記署名の検証用の鍵を有する１つの電子制御ユニットを選定して、選定した前記電子制御ユニットに前記所定処理を実行させるように制御する、
   ファームウェア更新方法。

Images