JP7512908B2 - センタ、管理方法および管理プログラム - Google Patents

Description

本開示は、ＥＣＵ（電子制御ユニット）のソフトウェアの更新を制御するためのセンタ、管理方法および管理プログラム等に関する。

車両には、車両の動作を制御するための複数のＥＣＵ（電子制御ユニット）が搭載されている。ＥＣＵは、プロセッサと、ＲＡＭのような一時的な記憶部と、フラッシュＲＯＭのような不揮発性の記憶部とを備え、プロセッサが不揮発性の記憶部に記憶されるソフトウェアを実行することによりＥＣＵの制御機能を実現する。各ＥＣＵが記憶するソフトウェアは書き換え可能であり、より新しいバージョンのソフトウェアに更新することにより、各ＥＣＵの機能を改善したり、新たな車両制御機能を追加したりすることができる。

ＥＣＵのソフトウェアを更新する技術として、車載ネットワークに接続された車載通信機器とインターネット等の通信ネットワークとを無線で接続し、無線通信を介してＯＴＡセンタ（単に「センタ」という場合がある）からソフトウェアをダウンロードし、ダウンロードしたソフトウェアをインストールすることによりＥＣＵのプログラム更新や追加を行うＯＴＡ（Ｏｖｅｒ Ｔｈｅ Ａｉｒ）技術が知られている（例えば、特許文献１参照）。

ＯＴＡによるソフトウェアの更新は、ソフトウェア更新を行うイベントであるキャンペーンがサーバに登録された後、車両がＯＴＡセンタに更新データの有無の確認を要求したことを契機として行われる。キャンペーンがある場合、車両は、更新データのダウンロード、更新データのインストール及び更新版のソフトウェアのアクティベートを順次行うことにより、更新対象のＥＣＵであるターゲットＥＣＵのソフトウェアを更新する。

特開２００４－３２６６８９号公報

車両のＥＣＵが交換（部品交換）された場合、交換後のＥＣＵに実装されているソフトウェアのバージョンが、交換前のＥＣＵに実装されているソフトウェアのバージョンと異なることがある。車両に搭載された複数のＥＣＵのソフトウェア間のバージョンの組み合わせには、車両が適切に動作しない可能性のある組み合わせ（不整合のバージョン組み合わせ）が存在する場合があり、ＥＣＵが交換されて不整合のバージョン組み合わせとなった場合には対処が必要となる。

それ故に、本開示は、上記した課題を解決するものであり、ＥＣＵの交換前後においてＥＣＵに実装されているソフトウェアのバージョンを同一にすることができるセンタ、管理方法および管理プログラム等を提供することを目的とする。

本開示に係るセンタは、車両に搭載された、複数の電子制御ユニットのソフトウェア更新を制御するＯＴＡマスタと、ネットワークを介して通信可能なセンタであって、ＯＴＡマスタから、複数の電子制御ユニットに実装されているソフトウェアのバージョンを示す識別情報を受信する通信部と、複数の電子制御ユニットについて、実装されているべきソフトウェアのバージョンである実装管理バージョンが実装されているか否かを判定可能とする適否判定情報を記憶する記憶部と、識別情報および適否判定情報に基づいて、複数の電子制御ユニットについて、実装管理バージョンのソフトウェアが実装されているか否かを判定する適否判定を行う判定部と、判定部により実装管理バージョンのソフトウェアが実装されていないと判定された電子制御ユニットについて、ＯＴＡマスタと通信を行うことにより、ソフトウェアのバージョンを実装管理バージョンに戻すための復元制御を行う制御部とを備える。

本開示に係る管理方法は、プロセッサと、メモリと、車両に搭載された、複数の電子制御ユニットのソフトウェア更新を制御するＯＴＡマスタとネットワークを介して通信可能な通信装置とを備えるコンピュータが実行する管理方法であって、ＯＴＡマスタから、複数の電子制御ユニットに実装されているソフトウェアのバージョンを示す識別情報を受信するステップと、複数の電子制御ユニットについて、実装されているべきソフトウェアのバージョンである実装管理バージョンが実装されているか否かを判定可能とする適否判定情報を記憶するステップと、識別情報および適否判定情報に基づいて、複数の電子制御ユニットについて、実装管理バージョンのソフトウェアが実装されているか否かを判定する適否判定を行うステップと、判定部により実装管理バージョンのソフトウェアが実装されていないと判定された電子制御ユニットについて、ＯＴＡマスタと通信を行うことにより、ソフトウェアのバージョンを実装管理バージョンに戻すための復元制御を行うステップとを備える。

本開示に係る管理プログラムは、プロセッサと、メモリと、車両に搭載された、複数の電子制御ユニットのソフトウェア更新を制御するＯＴＡマスタとネットワークを介して通信可能な通信装置とを備えるコンピュータが実行する管理プログラムであって、ＯＴＡマスタから、複数の電子制御ユニットに実装されているソフトウェアのバージョンを示す識別情報を受信するステップと、複数の電子制御ユニットについて、実装されているべきソフトウェアのバージョンである実装管理バージョンが実装されているか否かを判定可能とする適否判定情報を記憶するステップと、識別情報および適否判定情報に基づいて、複数の電子制御ユニットについて、実装管理バージョンのソフトウェアが実装されているか否かを判定する適否判定を行うステップと、判定部により実装管理バージョンのソフトウェアが実装されていないと判定された電子制御ユニットについて、ＯＴＡマスタと通信を行うことにより、ソフトウェアのバージョンを実装管理バージョンに戻すための復元制御を行うステップとを備える。

本開示によれば、ＥＣＵの交換前後においてＥＣＵに実装されているソフトウェアのバージョンを同一にすることができるセンタ、管理方法および管理プログラム等を提供できる。

第１の実施形態に係るネットワークシステムの全体構成の一例を示すブロック図 図１に示したＯＴＡセンタの概略構成の一例を示すブロック図 図１に示したＯＴＡマスタの概略構成の一例を示すブロック図 図１に示したＥＣＵの概略構成の例を示すブロック図 図１に示したＯＴＡセンタの一例を示す機能ブロック図 図１に示したＯＴＡマスタの一例を示す機能ブロック図 第１の実施形態に係るＯＴＡマスタが実行する制御処理の一例を示すフローチャート 図５に示したＯＴＡセンタに予め記憶される整合構成情報の一例を説明するための図 図５に示したＯＴＡセンタに記憶される履歴情報の一例を説明するための図 図５に示したＯＴＡセンタに記憶される履歴情報の一例を説明するための図 図７に示したロールバック処理の一例を示すフローチャート 第２の実施形態に係るＯＴＡマスタが実行する制御処理の一例を示すフローチャート

（第１の実施形態）
図１は、第１の実施形態に係るネットワークシステムの全体構成の一例を示すブロック図である。図２は、図１に示したＯＴＡセンタの概略構成の一例を示すブロック図である。図３は、図１に示したＯＴＡマスタの概略構成の一例を示すブロック図である。図４は、図１に示したＥＣＵの概略構成の例を示すブロック図である。

図１に示すネットワークシステムは、車両に搭載されたＥＣＵ（Electronic Control Unit；電子制御ユニット）１３ａ～１３ｄのソフトウェアを更新するためのシステムであり、ＯＴＡセンタ（例えば、サーバ；単に「センタ」という場合がある）１と、車両に搭載される車載ネットワーク２とを備える。

ＯＴＡセンタ１は、インターネット等の通信ネットワーク５を介して車両に搭載されたＯＴＡマスタ１１と無線等で通信可能であり、車両に搭載されたＥＣＵ１３ａ～１３ｄのソフトウェア更新を管理する。

図２に示すように、ＯＴＡセンタ１は、ＣＰＵ２１と、ＲＡＭ２２と、記憶装置２３と、通信装置２４とを備える。記憶装置２３は、ハードディスクやＳＳＤ等の読み書き可能な記憶媒体を備え、ソフトウェアの更新管理を実行するためのプログラムや、更新管理に用いる情報、ＥＣＵの更新データを記憶する。ＣＰＵ２１は、記憶装置２３から読み出したプログラムを、ＲＡＭ２２を作業領域として用いて実行することにより、制御処理を実行する。通信装置２４は、通信ネットワーク５を介してＯＴＡマスタ１１と通信を行う。

図１に示すように、車載ネットワーク２は、ＯＴＡマスタ１１と、通信モジュール１２と、複数のＥＣＵ１３ａ～１３ｄと、ＨＭＩ（Human Machine Interface；例えば、入力操作が可能なカーナビゲーションシステムの表示装置）１４とを備える。ＯＴＡマスタ１１は、バス１５ａを介して通信モジュール１２と接続され、バス１５ｂを介してＥＣＵ１３ａ及び１３ｂと接続され、バス１５ｃを介してＥＣＵ１３ｃ及び１３ｄと接続され、バス１５ｄを介してＨＭＩ１４と接続されている。ＯＴＡマスタ１１は、通信モジュール１２を介してＯＴＡセンタ１と無線での通信が可能である。ＯＴＡマスタ１１は、ＯＴＡセンタ１から取得した更新データに基づいて、ＥＣＵ１３ａ～１３ｄのうちの更新対象のＥＣＵ（「ターゲットＥＣＵ」という場合がある）のソフトウェア更新を制御する。通信モジュール１２は、車載ネットワーク２とＯＴＡセンタ１とを接続する通信機器である。ＥＣＵ１３ａ～１３ｄは、車両の各部の動作を制御する。ＨＭＩ１４は、ＥＣＵ１３ａ～１３ｄのソフトウェアの更新処理の際に、更新データがあることの表示や、ユーザや管理者にソフトウェア更新に対する承諾を求めるための承諾要求画面の表示、更新結果の表示等の各種表示を行うために用いられる。なお、図１では、４つのＥＣＵ１３ａ～１３ｄを例示したが、ＥＣＵの数は限定されない。

図４に示すように、ＥＣＵ１３は、ＣＰＵ４１と、ＲＡＭ４２と、不揮発性メモリ４３と、通信装置４５とを備える。ＣＰＵ４１は、不揮発性メモリ４３（データ格納領域４４）から読み出したソフトウェア（プログラム）を、ＲＡＭ４２を作業領域として用いて実行し、又、通信装置４５を用いて必要に応じてバスを介して他の機器と通信することにより、ＥＣＵ１３の機能を実現する。

ここで、ＥＣＵ１３には、ソフトウェアを格納するための１つのデータ格納領域（バンク）４４ａを有するタイプのシングルバンクメモリＥＣＵ（図４（１））と、ソフトウェアを格納するための２つのデータ格納領域（バンク）４４ｂ及び４４ｃを有するタイプのダブルバンクメモリＥＣＵ（図４（２））とがある。ＥＣＵ１３のデータ格納領域４４には、ＥＣＵの機能を実現するためのソフトウェアの他に、バージョン情報やパラメータデータ、起動用のブートプログラム、ソフトウェア更新用のプログラム等が格納される場合がある。シングルバンクメモリＥＣＵにおいては、データ格納領域４４ａに更新データをインストールしてアクティベート（有効化）することにより、ＥＣＵのソフトウェアに影響が生じる。一方、ダブルバンクメモリＥＣＵにおいては、２つのデータ格納領域（４４ｂ、４４ｃ）のうち、いずれか一方を読み出し対象の格納領域（運用面）とし、読み出し対象の格納領域に格納されるソフトウェアを実行する。読み出し対象でない他方の格納領域（非運用面）には、読み出し対象の格納領域（運用面）のプログラムの実行中に、バックグラウンドで更新データを書き込み可能である。ソフトウェア更新処理におけるアクティベート時には、ＣＰＵ４１によるプログラムの読み出し対象の格納領域を切り替えることにより、更新版のソフトウェアをアクティベート（有効化）することができる。シングルバンクメモリＥＣＵ及びダブルバンクメモリＥＣＵにおいて、ソフトウェアのアクティベートが完了してこのソフトウェアでＥＣＵが動作できる状態は、このソフトウェアがＥＣＵに実装された状態と言える。

なお、本開示において、ダブルバンクメモリＥＣＵには、不揮発性メモリが有する１面のデータ格納領域を擬似的に２面に区画し、一方の面のプログラムを実行中に他方の面にプログラムを書き込み可能にした「１面サスペンドメモリ」と呼ばれる構成のメモリを備えたＥＣＵと、１面のデータ格納領域を有する不揮発性メモリに加え、１面のデータ格納領域を有する拡張不揮発性メモリを備え、これら２つの不揮発性メモリを運用面及び非運用面として使用可能なＥＣＵも含まれる。

図３に示すように、ＯＴＡマスタ１１は、ＣＰＵ３１と、ＲＡＭ３２と、ＲＯＭ３３と、記憶装置３４とを備えるマイクロコンピュータ３５と、通信装置３６とを備える。ＣＰＵ３１は、ＲＯＭ３３から読み出したプログラムを、ＲＡＭ３２を作業領域として用いて実行することにより、制御処理を実行する。通信装置３６は、図１に示したバス１５ａ～１５ｄを介して、通信モジュール１２、ＥＣＵ１３ａ～１３ｄ、ＨＭＩ１４と通信を行う。

ここで、ソフトウェアの更新処理は、ＯＴＡセンタ１から更新データをダウンロードするフェーズと、ダウンロードした更新データを更新対象であるターゲットＥＣＵに転送し、ターゲットＥＣＵの記憶領域に更新データをインストールするフェーズと、ターゲットＥＣＵにおいてインストールした更新版のソフトウェアを有効化するアクティベートのフェーズとからなる。

ダウンロードは、ＯＴＡセンタ１から送信された、ＥＣＵのソフトウェアを更新するための更新データを受信して、記憶装置３４に記憶する処理である。ダウンロードのフェーズは、更新データの受信だけでなく、ダウンロードの実行可否判断、更新データの検証等、ダウンロードに関する一連の処理の制御を含む。インストールは、ダウンロードした更新データに基づいて、更新対象であるターゲットＥＣＵの不揮発性メモリに更新版のプログラム（更新ソフトウェア）を書き込む処理である。インストールのフェーズは、インストールの実行だけでなく、インストールの実行可否判断、更新データの転送および更新版のプログラムの検証等、インストールに関する一連の処理の制御を含む。アクティベートは、インストールした更新版のプログラムをアクティベート（有効化）する処理である。アクティベートのフェーズは、アクティベートの実行だけでなく、アクティベートの実行可否判断、実行結果の検証等、アクティベートに関する一連の制御を含む。

ＯＴＡセンタ１からＯＴＡマスタ１１に送信される更新データは、ＥＣＵの更新ソフトウェア、更新ソフトウェアを圧縮した圧縮データ、更新ソフトウェアまたは圧縮データを分割した分割データのいずれを含んでいても良い。また、更新データは、更新対象であるターゲットＥＣＵを識別する識別子（ＥＣＵ ＩＤ）と、更新前のソフトウェアを識別する識別子（ＥＣＵ ソフトウェア ＩＤ）を含んでいても良い。更新データは、配信パッケージとしてダウンロードされるが、配信パッケージには、単一または複数のＥＣＵの更新データが含まれる。

更新データが更新ソフトウェアそのものを含む場合は、インストールのフェーズにおいて、ＯＴＡマスタ１１が更新データ（つまり、更新ソフトウェア）をターゲットＥＣＵに転送する。また、更新データが更新ソフトウェアの圧縮データ、差分データあるいは分割データを含む場合、ＯＴＡマスタ１１がターゲットＥＣＵに更新データを転送し、ターゲットＥＣＵが更新データから更新ソフトウェアを生成しても良いし、ＯＴＡマスタ１１が更新データから更新ソフトウェアを生成してから、更新ソフトウェアをターゲットＥＣＵに転送しても良い。ここで、更新ソフトウェアの生成は、圧縮データの解凍、差分データまたは分割データの組み付けにより行うことができる。

更新ソフトウェアのインストールは、ＯＴＡマスタ１１からのインストール要求に基づき、ターゲットＥＣＵが行うことができる。または、更新データを受信したターゲットＥＣＵが、ＯＴＡマスタ１１からの明示の指示を受けることなく、自律的にインストールを行っても良い。

更新ソフトウェアのアクティベートは、ＯＴＡマスタ１１からのアクティベート要求に基づき、ターゲットＥＣＵが行うことができる。または、更新データを受信したターゲットＥＣＵが、ＯＴＡマスタ１１からの明示の指示を受けることなく、自律的にアクティベートを行っても良い。

図５は、図１に示したＯＴＡセンタ１の機能ブロック図の一例である。図５に示すように、ＯＴＡセンタ１は、記憶部２６と、通信部２７と、判定部２８と、制御部２９とを備える。通信部２７、判定部２８及び制御部２９は、図２に示したＣＰＵ２１がＲＡＭ２２を用いて記憶装置２３に記憶されるプログラムを実行することにより実現される。記憶部２６は、図２に示した記憶装置２３により実現される。

図６は、図１に示したＯＴＡマスタ１１の機能ブロック図の一例である。図６に示すように、ＯＴＡマスタ１１は、記憶部３７と、通信部３８と、制御部３９とを備える。通信部３８及び制御部３９は、図３に示したＣＰＵ３１がＲＡＭ３２を用いてＲＯＭ３３に記憶されるプログラムを実行することにより実現される。記憶部３７は、図３に示した記憶装置３４によって実現される。

図７は、本実施形態に係るＯＴＡセンタ１が実行する制御処理の一例を示すフローチャートである。以下では、図７に示すフローチャートに沿って、本実施形態に係る制御処理について説明する。

図７に示す処理は、ＯＴＡマスタ１１から送信された車両構成情報を通信部２７が受信することで開始される。

ここで、車両に搭載されたＯＴＡマスタ１１は、所定の条件が成立（典型的には、車両のイグニッションがＯＮにされたことを検出）すると、車両の全てのＥＣＵから、それぞれ、ＥＣＵの種別を識別可能とするＥＣＵ ＩＤと、ソフトウェア（「ＳＷ」という場合がある）の種別及びバージョンを識別可能とするＥＣＵソフトウェアＩＤと取得する。そして、ＯＴＡマスタ１１は、取得したＥＣＵ ＩＤ及びＥＣＵソフトウェアＩＤと、車両を識別可能とするＶＩＮ（Vehicle identification Number；車両識別番号）とを含んだ車両構成情報を作成して、ＯＴＡセンタ１に送信する。この処理によって、例えばイグニッションがＯＮにされる度に、ＯＴＡマスタ１１によって車両構成情報が作成されてＯＴＡセンタ１に送信されるので、ＯＴＡセンタ１は、各車両のＥＣＵについてハードウェア構成およびソフトウェア構成を把握することができる。

図７のステップＳ１において、制御部２９は、通信部２７により受信された車両構成情報からＶＩＮ及びＥＣＵソフトウェアＩＤ（識別情報）を取得する。その後、処理はステップＳ２に移る。

ステップＳ２において、判定部２８は、ステップＳ１で取得したＶＩＮが示す車両に搭載されたＥＣＵについて、ソフトウェアのバージョンが不適正に変化したか否かを判定する。以下、具体的に説明する。

記憶部２６には、各車両について、ＯＴＡセンタ１がＥＣＵに実装されているものとして管理しているソフトウェアのバージョン（以下「実装管理バージョン」という場合がある）を示す実装管理バージョン情報（適否判定情報）が記憶されている。言い換えると、実装管理バージョン情報は、ＥＣＵに実装されているべきソフトウェアのバージョン（実装管理バージョン）を示す情報である。実装管理バージョン情報は、図９を用いて具体的に後述するが、例えば、ＶＩＮが１００１の車両（ＥＣＵ１～４が搭載された車両）において、ＥＣＵ１にはＥＣＵ１用のソフトウェアであってバージョン２．２のソフトウェアが実装されており、ＥＣＵ２にはＥＣＵ２用のソフトウェアであってバージョン２．４のソフトウェアが実装されており、ＥＣＵ３にはＥＣＵ３用のソフトウェアであってバージョン２．２のソフトウェアが実装されており、ＥＣＵ４にはＥＣＵ４用のソフトウェアであってバージョン２．５のソフトウェアが実装されていることを示す情報である。また、実装管理バージョン情報は、適宜更新される。例えば、ＯＴＡセンタ１から送信されたソフトウェアの更新データに基づいてＯＴＡマスタ１１が更新制御を行ってＥＣＵのソフトウェアが更新されて（バージョンアップして）、更新完了の通知がＯＴＡマスタ１１からＯＴＡセンタ１に行われた場合、更新後のソフトウェアのバージョンで実装管理バージョン情報が更新される。

ステップＳ２において、判定部２８は、ステップＳ１で取得したＶＩＮが示す車両に搭載されたＥＣＵについて、それぞれ、ステップＳ１で取得したＥＣＵソフトウェアＩＤ（識別情報）が示すソフトウェアのバージョンと、記憶部２６に記憶されている実装管理バージョン情報が示す実装管理バージョンとを比較する。そして、判定部２８は、ＥＣＵソフトウェアＩＤが示すソフトウェアのバージョンと実装管理バージョン情報が示す実装管理バージョンとが一致しない場合、ソフトウェアのバージョンが不適正に変化したと判定する。ここで、車両に搭載されたＥＣＵが交換（部品交換）された場合、上記のようにＥＣＵソフトウェアＩＤが示すソフトウェアのバージョンと実装管理バージョン情報が示す実装管理バージョンとが一致しなくなる場合が多く、その場合、判定部２８は、ソフトウェアのバージョンが不適正に変化したと判定する。その後、処理はステップＳ３に移る。

ステップＳ３において、制御部２９は、ステップＳ２においてソフトウェアのバージョンが不適正に変化した（ソフトウェアのバージョンの不適正変化があった）と判定された場合は、処理をステップ４に進め、そうでない場合は図７の処理を終了する。

ステップＳ４において、判定部２８は、ステップＳ１で取得したＶＩＮが示す車両に搭載されている複数のＥＣＵについて、ソフトウェアのバージョン間の整合性（バージョンの組み合わせの適正性）を判定する。以下、具体的に説明する。

図８は、車両に搭載された複数のＥＣＵに実装されるソフトウェアの整合する（適切な）全てのバージョン組み合わせを定義した整合構成情報を説明するための図である。図８に示すように、例えばＶＩＮが１００１の車両（ＥＣＵ１～４が搭載された車両）に係る整合構成情報には、ＥＣＵ１～４に実装されるソフトウェアの整合する（適切な）全てのバージョン組み合わせが定義されている。言い換えると、整合構成情報に無いソフトウェアのバージョン組み合わせは、不整合のバージョン組み合わせであり、不適切なバージョン組み合わせと言える。不整合のバージョン組み合わせである場合、ＥＣＵが適切に動作しない可能性があり、車両が適切に動作しない可能性がある。

ステップＳ４において、判定部２８は、ステップＳ１で取得したＶＩＮが示す車両に搭載された複数のＥＣＵについて、ステップＳ１で取得したＥＣＵソフトウェアＩＤが示すソフトウェアのバージョンの組み合わせが、記憶部２６に予め記憶されている整合管理情報が示すソフトウェアのバージョン組み合わせのうちの何れかと一致するか否かを判定する。そして、判定部２８は、何れかと一致すると判定した場合はソフトウェアのバージョン間の整合性があると判定し、何れとも一致しないと判定した場合はソフトウェアのバージョン間の整合性が無いと判定する（つまり、不整合と判定する）。その後、処理はステップＳ５に移る。

ステップＳ５において、制御部２９は、ステップＳ１で取得したＥＣＵソフトウェアＩＤが示すソフトウェアのバージョンの履歴を、記憶部２６に記憶されたソフトウェアバージョン履歴情報（以下、単に「履歴情報」という場合がある）に書き込む。以下、具体的に説明する。

図９は、ソフトウェアバージョン履歴情報を説明するための図である。図９に示すように、例えばＶＩＮが１００１の車両（ＥＣＵ１～４が搭載された車両）に係る履歴情報には、ＥＣＵ１～４に実装されたソフトウェアのバージョン履歴が書き込まれている。

ステップＳ５において、制御部２９は、例えば図９示す履歴情報の履歴ＮＯ．１２として、ステップＳ１で取得したＥＣＵソフトウェアＩＤが示すソフトウェアのバージョン（ＥＣＵ１のＳＷバージョン２．２、ＥＣＵ２のＳＷバージョン２．５、ＥＣＵ３のＳＷバージョン１．５、及びＥＣＵ４のＳＷバージョン２．５）を書き込む。

また、ステップＳ５において、制御部２９は、ステップＳ４でソフトウェアのバージョン間の整合性が無いと判定された場合は、履歴情報が示す履歴に整合性が無いこと（不整合であること）を示す情報（例えばフラグによる情報）を付加する。図９の例では、履歴ＮＯ．１２のソフトウェアのバージョン組み合わせが図８の整合構成情報に存在せず不整合であるため、履歴ＮＯ．１２の「整合判定」の列に、不整合であることを示す情報（×印）が付加されている。また、ステップＳ５において、制御部２９は、ステップＳ４でソフトウェアのバージョン間の整合性が有ると判定された場合は、履歴情報が示す履歴に整合性が有ることを示す情報を付加する。図９の例では、履歴ＮＯ．１～１１のソフトウェアのバージョン組み合わせが図８の整合構成情報に存在し整合するものであるため、履歴ＮＯ．１～１１の「整合判定」の列に、整合するものであることを示す情報（〇印）が付加されている。

図１０は、図９の履歴情報に対して、履歴ＮＯ．１２のＥＣＵ３のソフトウェアバージョンが「２．３」である場合を示している。図１０の場合には、履歴ＮＯ．１２のソフトウェアのバージョン組み合わせは、図８に示す整合構成情報のＮＯ．３６が示すソフトウェアのバージョン組み合わせと一致するので、整合するバージョン組み合わせである。このため、図１０の例では、履歴ＮＯ．１２の「整合判定」の列に、整合するバージョン組み合わせ（適切なバージョン組み合わせ）であることを示す情報（〇印）が付加されている。

なお、本実施形態では、制御部２９は、ＥＣＵに実装されているものとして管理しているソフトウェアのバージョン（実装管理バージョン）を示す実装管理バージョン情報を履歴情報に付加し（含ませ）、又、実装管理バージョン情報を適宜更新する。図９及び図１０の例では、履歴ＮＯ．１１のソフトウェアのバージョン組み合わせ（各ＥＣＵのソフトウェアのバージョン）に、実装管理バージョンであることを示す情報（〇印）を付加することで、実装管理バージョン情報が履歴情報に付加されている。このようにすることで、ステップＳ２のＳＷバージョン不適正変化判定の処理で使用される実装管理バージョン情報が記憶部２６に記憶されることとなる。

ステップＳ６において、制御部２９は、ステップＳ４でソフトウェアのバージョン間の整合性が無い（つまり、不整合）と判定された場合は処理をステップＳ７に進め、ステップＳ４で整合性があると判定された場合は図７の処理を終了する。なお、ステップＳ４で整合性があると判定されて図７の処理を終了する場合、制御部２９は、整合性があると判定されたソフトウェアのバージョン組み合わせを実装管理バージョンに設定して実装管理バージョン情報を更新する。図１０の例では、履歴ＮＯ．１１のソフトウェアのバージョン組み合わせに付加されている実装管理バージョンであることを示す情報（〇印）が削除されて、この情報（〇印）が履歴ＮＯ．１２のソフトウェアのバージョン組み合わせに付加された状態に更新される。

ステップＳ７において、制御部２９は、履歴情報を用いて直近のソフトウェアのバージョン整合構成を特定する。図９の例では、制御部２９は、履歴ＮＯ．１１のソフトウェアのバージョン組み合わせを、直近のソフトウェアのバージョン整合構成として特定することとなる。その後、処理はステップＳ８に移る。

ステップＳ８において、制御部２９は、ＥＣＵに実装されているソフトウェアのバージョン組み合わせが、ステップＳ７で特定した直近のソフトウェアのバージョン整合構成に戻るように、ソフトウェアのバージョンを戻すロールバック処理（復元処理）の実行対象となるソフトウェアを特定する。図９の例では、制御部２９は、ＥＣＵ２及びＥＣＵ３のソフトウェアを、ロールバック処理（復元処理）の実行対象となるソフトウェアとして特定することとなる。その後、処理はステップＳ９に移る。

ステップＳ９において、制御部２９は、ＥＣＵに実装されているソフトウェアのバージョンを、以前のバージョンに戻すロールバック処理を行う。

図１１は、ステップＳ９のロールバック処理の一例を示すフローチャートである。図１１のステップＳ１１において、制御部２９は、ステップＳ７で特定した直近のソフトウェアのバージョン整合構成に戻るように、ステップＳ８で特定したロールバック処理の実行対象のソフトウェアのうちの１つに対して、バージョンをロールバックさせるためのデータ（ロールバックデータ）及びロールバック指示を決定する。その後、処理はステップＳ１２に移る。

ステップＳ１２において、制御部２９は、ステップＳ８で特定した全てのロールバック対象のソフトウェアについてステップＳ１１の決定を行ったか否かを判定する。ステップＳ１２での判定がＹＥＳの場合、処理はステップＳ１３に移り、この判定がＮＯの場合、処理はステップＳ１１に戻る。このことによって、ステップＳ８で特定した全てのロールバック対象のソフトウェアのバージョンがロールバック（復元）されることとなる。

ステップＳ１３において、制御部２９は、ステップＳ１１で決定したロールバックデータ及びロールバック指示を、通信部２７によりＯＴＡマスタ１１に送信する。その後、図１１のロールバック処理は終了し、図７の処理も終了する。

なお、図７のステップＳ９のロールバック処理が終了してロールバック対象のソフトウェアのバージョンのロールバックが完了すると、ＯＴＡマスタ１１は、ロールバック完了通知をＯＴＡセンタ１に送信する。ＯＴＡセンタ１（制御部２９）は、ロールバック完了通知を受信すると、ステップＳ７で特定した直近のソフトウェアのバージョン整合構成（つまり、ロールバック後のソフトウェアのバージョン組み合わせ）を、最新の履歴として履歴情報に書き込む。その際に、ＯＴＡセンタ１（制御部２９）は、書き込んだ最新の履歴に、バージョンの整合性が有ることを示す情報を付加する。また、ＯＴＡセンタ１（制御部２９）は、書き込んだ最新の履歴が示すソフトウェアのバージョン組み合わせが実装管理バージョンとなるように、実装管理バージョン情報を更新する。図９の例では、履歴ＮＯ．１１と同じ内容の情報が最新の履歴ＮＯ．１３として履歴情報に書き込まれ、履歴ＮＯ．１１の「実装管理バージョン」の列の〇印が削除されることとなる。

（第２の実施形態）
図１２は、第２の実施形態に係るＯＴＡセンタ１が実行する制御処理の一例を示すフローチャートである。図１２のフローチャートは、第１の実施形態に係る図７のフローチャートに対して、ステップＳ７及びＳ８の処理をステップＳ７１の処理に置き換えたものである。第２の実施形態では、ソフトウェアのバージョンが不整合となった場合（ステップＳ６でＹＥＳの場合）において、第１の実施形態のように直近のソフトウェアのバージョン整合構成を特定してそのバージョン構成に戻す処理を行うのではなく、実装管理バージョン情報が示す実装管理バージョン（ＥＣＵに実装されているものとしてＯＴＡセンタ１が管理しているソフトウェアのバージョン）に戻す処理を行う。なお、以下では、主に第１の実施形態の処理と異なる部分について説明する。

図１２のステップＳ６でＹＥＳと判定された場合、ステップＳ７１において、制御部２９は、ステップＳ１で取得したＶＩＮが示す車両に搭載されたＥＣＵについて、不適正変化前のソフトウェアのバージョンにロールバックすることを決定する。具体的には、制御部２９は、記憶部２６に記憶されている実装管理バージョン情報が示す実装管理バージョンを参照して、ステップＳ１で取得したＶＩＮが示す車両に搭載されたＥＣＵについて、ソフトウェアのバージョンを実装管理バージョンにロールバック（復元）することを決定する。図９の例では、制御部２９は、実装管理バージョンである履歴ＮＯ．１１のソフトウェアのバージョン組み合わせにロールバックすることを決定する。その後、処置はステップＳ９に移りロールバック対象のソフトウェアのバージョンがロールバック（復元）されて、実装管理バージョンである履歴ＮＯ．１１のソフトウェアのバージョン組み合わせにロールバックされることとなる。

以上に図７及び図１２等を用いて説明したように、第１及び第２の実施形態に係るＯＴＡセンタ１は、ＥＣＵの交換（部品交換）によりＥＣＵのソフトウェアのバージョンが不適正に切り替わった場合、不適正に切り替わったＥＣＵのソフトウェアを実装管理バージョンに復元することができる。これにより、ＥＣＵ交換（部品交換）の前後においてソフトウェアのバージョンを同一に保つことができ、ＥＣＵ交換後において適正なソフトウェアのバージョンに戻すことができる。

ここで、部品交換後のＥＣＵが図４（２）を用いて説明したダブルバンクメモリＥＣＵである場合には、ソフトウェアの読み出し対象ではないデータ格納領域（非運用面）にどのようなソフトウェア（ソフトウェアのバージョン）が格納されているのかが不明である（又、非運用面にソフトウェアが格納されていない場合もある）。このため、部品交換後のＥＣＵがダブルバンクメモリＥＣＵである場合であっても、同様に、上記したようにＯＴＡセンタ１の制御によって実装管理バージョンに復元する必要がある。

また、以上に図７及び図１２等を用いて説明したように、第１及び第２の実施形態に係るＯＴＡセンタ１は、ＯＴＡマスタ１１からＥＣＵソフトウェアＩＤを取得してＥＣＵのソフトウェアのバージョン履歴情報を作成して管理し、その履歴情報を用いて不適正に切り替わったＥＣＵのソフトウェアバージョンを実装管理バージョンに復元することができる。これにより、履歴情報を用いてソフトウェアバージョンを復元することができ、又、履歴にあるソフトウェアバージョン（基本的にユーザが承諾したソフトウェアバージョン）に復元することができる。

また、以上に図７等を用いて説明したように、第１の実施形態に係るＯＴＡセンタ１は、ＥＣＵのソフトウェアバージョンが不適正に切り替わった場合において、車両に搭載された複数のＥＣＵに実装されたソフトウェアのバージョンが不整合（適正な組み合わせではない）と判定された場合には、履歴情報を用いて直近のソフトウェアバージョンの整合構成に復元することができる。これにより、ソフトウェアバージョンの整合構成に確実に復元することができ、又、整合構成のうち最新のものに復元できるので合理的である。一方、第１の実施形態に係るＯＴＡセンタ１は、ＥＣＵのソフトウェアのバージョンが不適正に切り替わった場合において、車両に搭載された複数のＥＣＵに実装されたソフトウェアのバージョンが整合する（適正な組み合わせである）と判定された場合には、ソフトウェアのバージョン不整合による問題は発生しないので、ソフトウェアバージョンを復元する処理は行わない。これにより、処理負荷を軽減できる。なお、このように複数のＥＣＵに実装されたソフトウェアのバージョンが整合する（適正な組み合わせである）と判定された場合においても、履歴情報を用いて直近のソフトウェアバージョンの整合構成に復元する制御構成としても良い。このように制御することで、履歴にあるソフトウェアバージョン（ユーザが承諾したソフトウェアバージョン）に復元することができる。

また、以上に図１２を用いて説明したように、第２の実施形態に係るＯＴＡセンタ１は、ＥＣＵのソフトウェアのバージョンが不適正に切り替わった場合において、ＥＣＵのソフトウェアのバージョンを、実装管理バージョン情報が示す実装管理バージョンに直接的に復元することができる。これにより、簡潔な処理でソフトウェアバージョンを整合構成に復元することができる。

なお、上記した第２の実施形態において（図１２参照）、ソフトウェアバージョンの整合性判定を行う処理（ステップＳ４及びＳ６）を実行しない制御構成としても良い。つまり、ソフトウェアバージョン不適正変化を検知した場合には（図９及び図１０の太枠部分参照）、ソフトウェアバージョンの整合性の有無を考慮することなく、ソフトウェアバージョンを実装管理バージョンに復元する処理としても良い。ここで、実装管理バージョンは、通常、ソフトウェアバージョンの整合性が有るので、このような簡潔な処理とすることで処理負荷を軽減できる。

また、上記した第１及び第２の実施形態において、実装管理バージョンを示す実装管理バージョン情報が履歴情報に含められて（付加されて）記憶されている例を挙げた（図９及び図１０参照）。しかし、実装管理バージョン情報は、履歴情報とは別個に記憶されても良い。

また、上記の実施形態で例示したＯＴＡセンタ１の機能は、プロセッサ（ＣＰＵ）とメモリと通信装置とを備えるコンピュータが実行する管理方法、あるいは、当該コンピュータに実行させる管理プログラム、管理プログラムを記憶したコンピュータ読み取り可能な非一時的記憶媒体として実現することも可能である。同様に、上記の実施形態として例示したＯＴＡマスタ１１の機能は、プロセッサ（ＣＰＵ）とメモリと通信装置とを備える、車載されたコンピュータが実行する制御方法、あるいは、当該車載されたコンピュータに実行させる制御プログラム、制御プログラムを記憶したコンピュータ読み取り可能な非一時的記憶媒体として実現することも可能である。

本開示技術は、ＥＣＵ（電子制御ユニット）のプログラムを更新するためのネットワークシステムに利用できる。

１ ＯＴＡセンタ
２ 車載ネットワーク
５ 通信ネットワーク
１１ ＯＴＡマスタ
１２ 通信モジュール
１３ａ～１３ｄ ＥＣＵ
１４ ＨＭＩ
１５ａ～１５ｄ バス
２６、３７ 記憶部
２７、３８ 通信部
２８ 判定部
２９、３９ 制御部

Claims (8)

1. 車両に搭載された、複数の電子制御ユニットのソフトウェア更新を制御するＯＴＡマスタと、ネットワークを介して通信可能なセンタであって、
   前記ＯＴＡマスタから、前記複数の電子制御ユニットに実装されているソフトウェアのバージョンを示す識別情報を受信する通信部と、
   前記複数の電子制御ユニットについて、実装されているものとして管理しているソフトウェアのバージョンである実装管理バージョンが実装されているか否かを判定可能とする適否判定情報を記憶する記憶部と、
   前記識別情報および前記適否判定情報に基づいて、前記複数の電子制御ユニットについて、前記実装管理バージョンのソフトウェアが実装されているか否かを判定する適否判定を行う判定部と、
   前記判定部により前記実装管理バージョンのソフトウェアが実装されていないと判定された電子制御ユニットについて、前記ＯＴＡマスタと通信を行うことにより、ソフトウェアのバージョンを前記実装管理バージョンに戻すための復元制御を行う制御部とを備える、センタ。
2. 前記制御部は、前記識別情報に基づいて、前記複数の電子制御ユニットについて、実装されたソフトウェアのバージョンの履歴を示す履歴情報を作成し、
   前記記憶部は、前記履歴情報を記憶し、
   前記判定部は、前記履歴情報を前記適否判定情報として用いて前記適否判定を行い、
   前記制御部は、前記判定部により前記実装管理バージョンのソフトウェアが実装されていないと判定された電子制御ユニットについて、前記履歴情報を用いて前記復元制御を行う、請求項１に記載のセンタ。
3. 前記記憶部は、前記複数の電子制御ユニットに実装されるソフトウェアのバージョンの適正な組み合わせを定義した整合構成情報を予め記憶し、
   前記判定部は、前記整合構成情報および前記履歴情報を用いて、前記履歴情報が示すソフトウェアのバージョンの最新の組み合わせが適正か否かを判定し、
   前記制御部は、
   前記判定部により前記最新の組み合わせが適正でないと判定された場合、前記判定部により前記実装管理バージョンのソフトウェアが実装されていないと判定された電子制御ユニットについて、前記復元制御を行い、
   前記判定部により前記最新の組み合わせが適正であると判定された場合、前記判定部により前記実装管理バージョンのソフトウェアが実装されていないと判定された電子制御ユニットについて、前記復元制御を行わない、請求項２に記載のセンタ。
4. 前記制御部は、
   前記判定部により前記最新の組み合わせが適正でないと判定された場合、前記履歴情報が示す前記履歴から、ソフトウェアのバージョンの直近の適正な組み合わせを特定し、
   前記複数の電子制御ユニットのソフトウェアのバージョンの組み合わせを、前記直近の適正な組み合わせに戻すための制御を行うことにより、前記復元制御を行う、請求項３に記載のセンタ。
5. 前記適否判定情報は、前記実装管理バージョンを示す情報であり、
   前記制御部は、前記判定部により前記実装管理バージョンのソフトウェアが実装されていないと判定された電子制御ユニットについて、前記適否判定情報を用いて前記復元制御を行う、請求項１に記載のセンタ。
6. 前記識別情報には、部品交換により前記車両に搭載された電子制御ユニットに実装され
   ているソフトウェアのバージョンを示す識別情報が含まれる、請求項１～５の何れかに記載のセンタ。
7. プロセッサと、メモリと、車両に搭載された、複数の電子制御ユニットのソフトウェア更新を制御するＯＴＡマスタとネットワークを介して通信可能な通信装置とを備えるコンピュータが実行する管理方法であって、
   前記ＯＴＡマスタから、前記複数の電子制御ユニットに実装されているソフトウェアのバージョンを示す識別情報を受信するステップと、
   前記複数の電子制御ユニットについて、実装されているものとして管理しているソフトウェアのバージョンである実装管理バージョンが実装されているか否かを判定可能とする適否判定情報を記憶するステップと、
   前記識別情報および前記適否判定情報に基づいて、前記複数の電子制御ユニットについて、前記実装管理バージョンのソフトウェアが実装されているか否かを判定する適否判定を行うステップと、
   前記適否判定により前記実装管理バージョンのソフトウェアが実装されていないと判定された電子制御ユニットについて、前記ＯＴＡマスタと通信を行うことにより、ソフトウェアのバージョンを前記実装管理バージョンに戻すための復元制御を行うステップとを備える、管理方法。
8. プロセッサと、メモリと、車両に搭載された、複数の電子制御ユニットのソフトウェア更新を制御するＯＴＡマスタとネットワークを介して通信可能な通信装置とを備えるコンピュータに、
   前記ＯＴＡマスタから、前記複数の電子制御ユニットに実装されているソフトウェアのバージョンを示す識別情報を受信するステップと、
   前記複数の電子制御ユニットについて、実装されているものとして管理しているソフトウェアのバージョンである実装管理バージョンが実装されているか否かを判定可能とする適否判定情報を記憶するステップと、
   前記識別情報および前記適否判定情報に基づいて、前記複数の電子制御ユニットについて、前記実装管理バージョンのソフトウェアが実装されているか否かを判定する適否判定を行うステップと、
   前記適否判定により前記実装管理バージョンのソフトウェアが実装されていないと判定された電子制御ユニットについて、前記ＯＴＡマスタと通信を行うことにより、ソフトウェアのバージョンを前記実装管理バージョンに戻すための復元制御を行うステップとを実行させる、管理プログラム。

Images