JP6723829B2 - ゲートウェイ装置、ファームウェア更新方法及び制御プログラム - Google Patents

Description

本発明は、車載ネットワークで通信する電子制御ユニットのファームウェアを更新（アップデート）する技術に関する。

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

ＣＡＮでは、通信路は２本のバスで構成され、バスに接続されているＥＣＵはノードと呼ばれる。バスに接続されている各ノードは、フレームと呼ばれるメッセージを送受信する。またＣＡＮでは、送信先や送信元を指す識別子は存在せず、送信ノードはフレーム毎にメッセージＩＤと呼ばれるＩＤを付けて送信し（つまりバスに信号を送出し）、各受信ノードは予め定められたメッセージＩＤのみを受信する（つまりバスから信号を読み取る）。

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

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

しかしながら、特許文献１の技術は、ファームウェアの更新を適切（例えば安全）なタイミングで実行するものの、ファームウェアの更新後に自動車等の車両が正常に機能しないことを抑制するものではない。

そこで、本発明は、ファームウェアの更新後に車両が正常に機能しなくなる可能性を低減させるファームウェア更新方法を提供する。また、本発明は、ファームウェアの更新後に車両が正常に機能しなくなる可能性を低減させるようにファームウェアの更新のための制御を行うゲートウェイ装置、及び、そのゲートウェイ装置に用いられるファームウェアの更新のための制御プログラムを提供する。

上記課題を解決するために本発明の一態様に係るゲートウェイ装置は、車両に搭載された複数の電子制御ユニットが通信に用いるバスに接続されたゲートウェイ装置であって、前記車両外の外部装置から、前記複数の電子制御ユニットのうち１つの電子制御ユニットの更新用ファームウェアを含むファームウェア更新情報を受信する受信部と、前記バスに接続される前記複数の電子制御ユニット各々の種類を示すシステム構成情報を取得する取得部と、前記システム構成情報が示す各種類の電子制御ユニットを用いて前記更新用ファームウェアの動作検証がなされた後に当該更新用ファームウェアに基づく該当の電子制御ユニットのファームウェアの更新のための制御を行う更新処理部とを備えるゲートウェイ装置である。

また、上記課題を解決するために本発明の一態様に係るファームウェア更新方法は、電子制御ユニットのファームウェアを更新するためのファームウェア更新方法であって、車両に搭載された複数の電子制御ユニットが通信に用いるバスに接続されたゲートウェイ装置が、前記車両外の外部装置から、前記複数の電子制御ユニットのうち１つの電子制御ユニットの更新用ファームウェアを含むファームウェア更新情報を受信する受信ステップと、前記ゲートウェイ装置が、前記バスに接続される前記複数の電子制御ユニット各々の種類を示すシステム構成情報を取得する取得ステップと、前記ゲートウェイ装置が、前記システム構成情報が示す各種類の電子制御ユニットを用いて前記更新用ファームウェアの動作検証がなされた後に当該更新用ファームウェアに基づく該当の電子制御ユニットのファームウェアの更新のための制御を行う更新処理ステップとを含むファームウェア更新方法である。

また、上記課題を解決するために本発明の一態様に係る制御プログラムは、車両に搭載された複数の電子制御ユニットが通信に用いるバスに接続された、プロセッサを備えるゲートウェイ装置にファームウェア更新処理を実行させるための制御プログラムであって、前記ファームウェア更新処理は、前記車両外の外部装置から、前記複数の電子制御ユニットのうち１つの電子制御ユニットの更新用ファームウェアを含むファームウェア更新情報を受信する受信ステップと、前記バスに接続される前記複数の電子制御ユニット各々の種類を示すシステム構成情報を取得する取得ステップと、前記システム構成情報が示す各種類の電子制御ユニットを用いて前記更新用ファームウェアの動作検証がなされた後に当該更新用ファームウェアに基づく該当の電子制御ユニットのファームウェアの更新のための制御を行う更新処理ステップとを含む制御プログラムである。

本発明によれば、ファームウェアの更新後に車両が正常に機能しなくなる可能性が低減される。

実施の形態１に係る車載ネットワークシステムの全体構成を示す図である。 ＣＡＮプロトコルで規定されるデータフレームのフォーマットを示す図である。 実施の形態１に係るゲートウェイの構成図である。 受信ＩＤリストの一例を示す図である。 ゲートウェイが用いる転送ルールの一例を示す図である。 実施の形態１に係るシステム構成情報（ＥＣＵ情報のリスト）の一例を示す図である。 実施の形態１に係るＥＣＵの構成図である。 実施の形態１に係るサーバの構成図である。 サーバが保持する車両ＥＣＵ管理情報の一例を示す図である。 実施の形態１に係るファームウェア（ＦＷ）更新情報のフォーマットの一例を示す図である。 実施の形態１におけるファームウェアの更新に係る動作例を示すシーケンス図である（図１２に続く）。 実施の形態１におけるファームウェアの更新に係る動作例を示すシーケンス図である（図１１から続く）。 実施の形態１に係るゲートウェイによるＦＷ更新制御処理の一例を示すフローチャートである。 実施の形態１に係るＥＣＵによるＦＷ更新制御処理の一例を示すフローチャートである。 実施の形態２に係るゲートウェイの構成図である。 実施の形態２に係るＦＷ更新情報のフォーマットの一例を示す図である。 実施の形態２に係るＥＣＵ構成情報のフォーマットの一例を示す図である。 実施の形態２に係るサーバの構成図である。 実施の形態２に係るＥＣＵ車両モデル管理テーブルの一例を示す図である。 実施の形態２に係る車両モデルＥＣＵ管理テーブルの一例を示す図である。 実施の形態２におけるサーバによる更新用ファームウェアの登録に係るＦＷ登録処理を示すフローチャートである。 実施の形態２に係るサーバによるＦＷ動作検証処理の一例を示すフローチャートである。 実施の形態２に係るサーバによる複数のファームウェアの検証に係るＦＷ動作検証処理の一例を示すフローチャートである。 実施の形態２におけるファームウェアの更新に係る動作例を示すシーケンス図である（図２５に続く）。 実施の形態２におけるファームウェアの更新に係る動作例を示すシーケンス図である（図２４から続く）。 実施の形態２におけるＦＷ動作検証処理に用いられるシミュレータによる仮想環境のソフトウェア構成の一例を示す図である。

本発明の一態様に係るゲートウェイ装置は、車両に搭載された複数の電子制御ユニットが通信に用いるバスに接続されたゲートウェイ装置であって、前記車両外の外部装置から、前記複数の電子制御ユニットのうち１つの電子制御ユニットの更新用ファームウェアを含むファームウェア更新情報を受信する受信部と、前記バスに接続される前記複数の電子制御ユニット各々の種類を示すシステム構成情報を取得する取得部と、前記システム構成情報が示す各種類の電子制御ユニットを用いて前記更新用ファームウェアの動作検証がなされた後に当該更新用ファームウェアに基づく該当の電子制御ユニットのファームウェアの更新のための制御を行う更新処理部とを備えるゲートウェイ装置である。これにより、ファームウェアの更新に際して複数の電子制御ユニットに対応した、更新用ファームウェアの動作検証の実施が確保された後に更新の制御が行われるので、動作検証が行われない場合と比べてファームウェアの更新後に車両が正常に機能しなくなる可能性が低減する。

また、前記ファームウェア更新情報は、前記更新用ファームウェアの動作検証に用いられた複数の電子制御ユニット各々の種類を示す検証済構成情報を含み、前記更新処理部は、前記システム構成情報が示す、前記車両に搭載された複数の電子制御ユニット各々の種類と、前記受信部に受信された前記検証済構成情報が示す、前記動作検証に用いられた複数の電子制御ユニット各々の種類とを比較し、比較結果が一定条件を満たした場合に前記更新用ファームウェアに基づく前記更新を行わせるように前記制御を行うこととしても良い。これにより、ゲートウェイ装置が搭載された車両における車載ネットワークの構成（電子制御ユニット群の編成）に対応して有効な動作検証が実行されたか否か等を確認し得るので、適切な動作検証の実施の確保が可能となり得る。

また、前記システム構成情報が示す、前記バスに接続される前記複数の電子制御ユニット各々の前記種類は、当該電子制御ユニットが実装しているファームウェアのバージョンを識別し、前記検証済構成情報が示す、前記更新用ファームウェアの動作検証に用いられた複数の電子制御ユニット各々の前記種類は、当該電子制御ユニットが実装しているファームウェアのバージョンを識別することとしても良い。これにより、車載ネットワークに接続された各電子制御ユニットのファームウェアと同じバージョンのファームウェアを実装した動作環境で動作検証がなされたか否か等を確認し得るので、適切な動作検証の実施の確保が可能となり得る。

また、前記更新処理部は、前記システム構成情報が示す全ての種類と同じ種類が前記受信部に受信された前記検証済構成情報に示されていることを確認した場合に、前記比較結果が前記一定条件を満たしたとして前記制御を行うこととしても良い。これにより、ファームウェアの更新に際して、ゲートウェイ装置が搭載された車両における車載ネットワークに接続された各電子制御ユニットと同じ種類の電子制御ユニットを用いた更新用ファームウェアの動作検証の実施の確保が可能となり得る。

また、前記ゲートウェイ装置は更に、前記システム構成情報を前記外部装置に送信する送信部を備え、前記更新処理部は、前記送信部が前記システム構成情報を前記外部装置に送信した後に、前記外部装置が当該システム構成情報を参照して複数の電子制御ユニットを用いて前記更新用ファームウェアの動作検証を行った後に送信した前記ファームウェア更新情報を、前記受信部により受信した場合に、当該ファームウェア更新情報の前記更新用ファームウェアに基づく前記更新を行わせるように前記制御を行うこととしても良い。これにより、ゲートウェイ装置が搭載された車両における車載ネットワークに接続された各電子制御ユニットと同じ種類の電子制御ユニットを用いた更新用ファームウェアの動作検証を外部装置に行わせてからファームウェアの更新を行うので、ファームウェアの更新後に車両が正常に機能しなくなる可能性が低減する。

また、前記システム構成情報は、前記バスに接続される前記複数の電子制御ユニット各々について、前記種類を特定するための、当該電子制御ユニットについての識別情報及び当該電子制御ユニットが実装しているファームウェアのバージョンの識別情報を含むこととしても良い。これにより、外部装置では、車載ネットワークに接続された各電子制御ユニットのファームウェアと同じバージョンのファームウェアを実装した動作環境で動作検証を行うことが可能となり、この結果として、ファームウェアの更新後に車両が正常に機能しなくなる可能性が低減する。

また、前記ゲートウェイ装置は、前記システム構成情報を前記外部装置に送信する機能を有する送信部を備え、前記ファームウェア更新情報は、前記更新用ファームウェアの動作検証に用いられた複数の電子制御ユニット各々の種類を示す検証済構成情報を含み、前記更新処理部は、前記システム構成情報が示す全ての種類と同じ種類が前記受信部に受信された前記検証済構成情報に示されていないことを確認した場合に、前記更新用ファームウェアに基づく前記更新を抑止して前記送信部に前記システム構成情報を前記外部装置に送信させるよう制御することとしても良い。これにより、ゲートウェイ装置が搭載された車両における車載ネットワークの構成に対応した適切な、更新用ファームウェアの動作検証が行われていない場合に、適切な動作検証を行わせるために有用な情報を送信するので、更新用ファームウェアの適切な動作検証の実施が確保される可能性が高まる。

また、前記ゲートウェイ装置は更に、複数の電子制御ユニットをシミュレートするシミュレーション部を備え、前記ファームウェア更新情報は、前記更新用ファームウェアの動作検証に用いられた複数の電子制御ユニット各々の種類を示す検証済構成情報を含み、前記更新処理部は、前記システム構成情報が示す全ての種類と同じ種類が前記受信部に受信された前記検証済構成情報に示されていないことを確認した場合に、前記システム構成情報が示す全ての種類と同じ種類の各電子制御ユニットを用いた前記更新用ファームウェアの動作のシミュレーションを、前記シミュレーション部に行わせ、当該シミュレーションによる動作検証がなされた後に前記更新用ファームウェアに基づく前記更新を行わせるように前記制御を行うこととしても良い。これにより、車載ネットワークにおける各電子制御ユニットに対応した動作検証が行われていない場合に、シミュレーションにより更新用ファームウェアの動作検証を行った後にファームウェアの更新を行うので、ファームウェアの更新後に車両が正常に機能しなくなる可能性が低減する。なお、例えば、標準的な電子制御ユニットの構成に対応した動作検証がなされて送信されたファームウェアに対して、車両に搭載された電子制御ユニットを交換した或いは追加した後の状態においては、その動作検証では適切でないために、新たに適切な動作検証を行うことは有用である。

また、前記ゲートウェイ装置は更に、複数の電子制御ユニットをシミュレートするシミュレーション部を備え、前記更新処理部は、前記システム構成情報が示す全ての種類と同じ種類の各電子制御ユニットを用いた前記更新用ファームウェアの動作のシミュレーションを、前記シミュレーション部に行わせ、当該シミュレーションによる動作検証がなされた後に前記更新用ファームウェアに基づく前記更新を行わせるように前記制御を行うこととしても良い。これにより、シミュレーションにより更新用ファームウェアの動作検証を行った後にファームウェアの更新を行うので、ファームウェアの更新後に車両が正常に機能しなくなる可能性が低減する。

また、前記バスに接続された前記複数の電子制御ユニットは、Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＣＡＮ）プロトコルに従って前記バスを介して通信を行い、前記更新処理部は、前記更新用ファームウェアに基づく該当の電子制御ユニットのファームウェアの更新のための前記制御として、前記バスを介して前記該当の電子制御ユニットへの前記更新用ファームウェアの送信を行うこととしても良い。これにより、更新用ファームウェアの動作検証の実施が確保された後に、ＣＡＮに従う車載ネットワークにおける電子制御ユニットへ更新用ファームウェアを送信してファームウェアを更新させるので、ファームウェアの更新後に車両が正常に機能しなくなる可能性が低減する。

また、本発明の一態様に係るファームウェア更新方法は、電子制御ユニットのファームウェアを更新するためのファームウェア更新方法であって、車両に搭載された複数の電子制御ユニットが通信に用いるバスに接続されたゲートウェイ装置が、前記車両外の外部装置から、前記複数の電子制御ユニットのうち１つの電子制御ユニットの更新用ファームウェアを含むファームウェア更新情報を受信する受信ステップと、前記ゲートウェイ装置が、前記バスに接続される前記複数の電子制御ユニット各々の種類を示すシステム構成情報を取得する取得ステップと、前記ゲートウェイ装置が、前記システム構成情報が示す各種類の電子制御ユニットを用いて前記更新用ファームウェアの動作検証がなされた後に当該更新用ファームウェアに基づく該当の電子制御ユニットのファームウェアの更新のための制御を行う更新処理ステップとを含むファームウェア更新方法である。これにより、ファームウェアの更新に際して複数の電子制御ユニットに対応した、更新用ファームウェアの動作検証の実施が確保された後に更新の制御が行われるので、動作検証が行われない場合と比べてファームウェアの更新後に車両が正常に機能しなくなる可能性が低減する。

また、前記ファームウェア更新方法は更に、前記外部装置が、複数の電子制御ユニットを用いて前記更新用ファームウェアの動作検証を行う動作検証ステップと、前記外部装置が、前記動作検証ステップで動作検証に用いた複数の電子制御ユニット各々の種類を示す検証済構成情報を、前記ファームウェア更新情報に含めて送信するファームウェア更新情報送信ステップとを含み、前記更新処理ステップは、前記システム構成情報が示す、前記車両に搭載された複数の電子制御ユニット各々の種類と、前記受信ステップで受信された前記検証済構成情報が示す、前記動作検証に用いられた複数の電子制御ユニット各々の種類とを比較し、比較結果が一定条件を満たした場合に前記更新用ファームウェアに基づく前記更新を行わせるように前記制御を行うこととしても良い。これにより、ゲートウェイ装置が搭載された車両における車載ネットワークの構成（電子制御ユニット群の編成）に対応して有効な動作検証が実行されたか否か等を確認し得るので、適切な動作検証の実施の確保が可能となり得る。

また、前記ファームウェア更新方法は更に、前記ゲートウェイ装置が、前記取得ステップで取得した前記システム構成情報を前記外部装置に送信する動作検証要求送信ステップと、前記外部装置が、前記動作検証要求送信ステップで送信された前記システム構成情報を受信して、当該システム構成情報が示す全ての種類と同じ種類の、複数の電子制御ユニットを用いて前記更新用ファームウェアの動作検証を行う動作検証ステップと、前記外部装置が、前記動作検証ステップで動作検証が行われた後に前記ファームウェア更新情報を送信するファームウェア更新情報送信ステップとを含み、前記更新処理ステップは、前記動作検証要求送信ステップでの前記システム構成情報の送信の後に前記受信ステップで前記ファームウェア更新情報が受信された場合に前記更新用ファームウェアに基づく前記更新を行わせるように前記制御を行うこととしても良い。これにより、ゲートウェイ装置が搭載された車両における車載ネットワークに接続された各電子制御ユニットと同じ種類の電子制御ユニットを用いた更新用ファームウェアの動作検証が外部装置により行われてからファームウェアの更新を行うので、ファームウェアの更新後に車両が正常に機能しなくなる可能性が低減する。

また、本発明の一態様に係る制御プログラムは、車両に搭載された複数の電子制御ユニットが通信に用いるバスに接続された、プロセッサを備えるゲートウェイ装置にファームウェア更新処理を実行させるための制御プログラムであって、前記ファームウェア更新処理は、前記車両外の外部装置から、前記複数の電子制御ユニットのうち１つの電子制御ユニットの更新用ファームウェアを含むファームウェア更新情報を受信する受信ステップと、前記バスに接続される前記複数の電子制御ユニット各々の種類を示すシステム構成情報を取得する取得ステップと、前記システム構成情報が示す各種類の電子制御ユニットを用いて前記更新用ファームウェアの動作検証がなされた後に当該更新用ファームウェアに基づく該当の電子制御ユニットのファームウェアの更新のための制御を行う更新処理ステップとを含む制御プログラムである。この制御プログラムがプロセッサを有する車両内の装置（例えばゲートウェイ装置）にインストールされ実行されることで、ファームウェアの更新に際して複数の電子制御ユニットに対応した、更新用ファームウェアの動作検証の実施が確保された後に更新の制御が行われるようになる。このため、ファームウェアの更新後に車両が正常に機能しなくなる可能性が低減する。

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

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

（実施の形態１）
以下、本発明の実施の形態として、ゲートウェイ装置を含む複数の電子制御ユニット（ＥＣＵ）がバスを介して通信する車載ネットワークシステム１０において用いられるファームウェア更新方法について、図面を用いて説明する。

ファームウェア更新方法は、車両に搭載された各ＥＣＵに実装されたファームウェア（ＦＷ：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