JP2024047896A - モバイル端末、ソフトウェア配信システム - Google Patents

Abstract

【課題】車両に搭載されたシングルバンクタイプのコンピュータについても、ＯＴＡ技術による好適なソフトウェア更新を可能にする。【解決手段】モバイル端末が、記憶部と受信部と送信部とを備える。受信部は、車両に搭載されるシングルバンクタイプのコンピュータの更新前のソフトウェアを車両から受信するように構成される（Ｓ１５）。送信部は、受信した更新前のソフトウェアを記憶部に記憶（Ｓ１５）させた後に、サーバから取得した更新用ソフトウェアを車両へ送信するように構成される（Ｓ１７）。【選択図】図３

Description

本開示は、モバイル端末およびソフトウェア配信システムに関する。

特開２０１７－１４９３２３号公報（特許文献１）には、ＯＴＡ（Over The Air）により、車両に搭載されたＥＣＵ（Electronic Control Unit）のソフトウェアを更新する技術が開示されている。

特開２０１７－１４９３２３号公報

車両は、ＯＴＡセンタと無線通信を行うことにより、ＯＴＡセンタから車載ＥＣＵの新しいソフトウェアをダウンロードすることができる。そして、車両において、ターゲットＥＣＵ（ソフトウェア更新対象のＥＣＵ）がインストール、アクティベートを順に実行することで、ソフトウェアを更新することができる。

典型的な車載ＥＣＵは、１つ以上のマイクロコンピュータ（以下、「マイコン」とも称する）を備える。車載ＥＣＵ内の典型的なマイコンは、デュアルバンクマイコンとシングルバンクマイコンとに大別される。

デュアルバンクマイコンでは、２つのメモリによって２つのバンクが形成される。デュアルバンクマイコンでは、アクティベートに失敗した場合に元のバージョンのソフトウェアに戻すこと（ロールバック）ができる。具体的には、アクティブ面に元のバージョンのソフトウェアを残したまま、書込み面に新しいバージョンのソフトウェアが書き込まれる。そして、書込み面のアクティベートに失敗した場合には、アクティブ面に残した元のバージョンのソフトウェアによってロールバックが実行される。

シングルバンクマイコンでは、１つのメモリによって１つのバンクが形成される。そして、シングルバンクマイコンでは、１つのバンクにおいてソフトウェアの上書きが行われる。このため、元のバージョンのソフトウェアは残らない。シングルバンクマイコンでは、アクティベートに失敗した場合に元のバージョンのソフトウェアに戻すこと（ロールバック）ができないという課題が生じ得る。

そこで、シングルバンクマイコンをデュアルバンクマイコンに変更したり、シングルバンクマイコンのバンク内にロールバックのための記憶部を設けたり、シングルバンクマイコンにロールバックのための不揮発性メモリ（例えば、Ｆｌａｓｈメモリ）を外付けで設けたりすることも考えられるが、これらの設計変更は車載ＥＣＵの大きなコストアップを招く。

現時点で普及している車両は、多数のシングルバンクマイコンを備えており、シングルバンクマイコンのソフトウェア更新は販売店（ディーラ）で行われることが多い。しかし、シングルバンクマイコンについても、ＯＴＡ技術を利用して、車両ユーザの判断で手軽にソフトウェア更新を実行したいというニーズがある。

本開示は、上記課題を解決するためになされたものであり、その目的は、車両に搭載されたシングルバンクタイプのコンピュータについても、ＯＴＡ技術による好適なソフトウェア更新を可能にすることである。

本開示の第１の観点に係る形態に従うと、以下に示すモバイル端末が提供される。

（第１項）当該モバイル端末は、記憶部と受信部と送信部とを備える。受信部は、車両に搭載されるシングルバンクタイプのコンピュータの更新前のソフトウェアを車両から受信するように構成される。送信部は、受信した更新前のソフトウェアを記憶部に記憶させた後に、サーバから取得した更新用ソフトウェアを車両へ送信するように構成される。

上記サーバは、ソフトウェアを配信するＯＴＡ（Over The Air）センタとして機能し得る。上記モバイル端末は、車両とＯＴＡセンタとの通信を仲介することができる。これらサーバ、車両、およびモバイル端末を含むシステムでは、モバイル端末の記憶部を利用して、車両に搭載されたターゲットＥＣＵ（ソフトウェア更新対象のＥＣＵ）内のシングルバンクタイプのコンピュータを仮想的にデュアルバンクタイプのコンピュータとして機能させることができる。上記構成を有するモバイル端末によれば、上記車両が、シングルバンクタイプのコンピュータのソフトウェア更新（例えば、アクティベート）に失敗した場合に、モバイル端末の記憶部に保存された更新前のソフトウェアを用いてロールバックを行うことが可能になる。これにより、車両に搭載されたシングルバンクタイプのコンピュータについても、ＯＴＡ技術による好適なソフトウェア更新が可能になる。

なお、モバイル端末は、ユーザによって持ち運び可能な端末である。モバイル端末の例としては、タブレット端末、スマートフォン、ウェアラブルデバイスが挙げられる。

上記第１項に記載のモバイル端末は、以下に示す第２項～第５項のいずれか１項に記載の構成を有し得る。

（第２項）第１項に記載のモバイル端末が以下の特徴をさらに有する。当該モバイル端末は、更新前のソフトウェアのバージョン情報を取得する取得部と、シングルバンクタイプのコンピュータのソフトウェア更新において、更新前のソフトウェアを保存するための空き容量を記憶部が有するか否かを判断する判断部とをさらに備える。更新前のソフトウェアを保存するための空き容量を記憶部が有すると判断部が判断した場合には、受信部が更新前のソフトウェアを車両から受信し、送信部が、更新前のソフトウェアを記憶部に記憶させた後に、サーバから取得した更新用ソフトウェアを車両へ送信する。更新前のソフトウェアを保存するための空き容量を記憶部が有しないと判断部が判断した場合には、取得部が更新前のソフトウェアのバージョン情報を取得し、送信部が、バージョン情報を記憶部に記憶させた後に、サーバから取得した更新用ソフトウェアを車両へ送信する。

上記構成を有するモバイル端末によれば、記憶部の空き容量（すなわち、記憶部が記憶可能なデータ量）に応じて、ロールバックのためのデータ（詳しくは、更新前のソフトウェアまたはそのバージョン情報）を適切に保存することが可能になる。

（第３項）第１項に記載のモバイル端末が以下の特徴をさらに有する。当該モバイル端末は更新部をさらに備える。更新部は、シングルバンクタイプのコンピュータのソフトウェア更新において、更新前のソフトウェアを保存するための空き容量が記憶部に確保されるまで当該ソフトウェア更新を保留し、更新前のソフトウェアを保存するための空き容量が記憶部に確保された後、上記シングルバンクタイプのコンピュータのソフトウェア更新を許可するように構成される。

上記構成によれば、シングルバンクタイプのコンピュータのソフトウェア更新を適切に行いやすくなる。

（第４項）第１項～第３項のいずれか１項に記載のモバイル端末が以下の特徴をさらに有する。当該モバイル端末は報知部をさらに備える。報知部は、シングルバンクタイプのコンピュータのソフトウェア更新において、更新前のソフトウェアを保存するための記憶部の空き容量が不足している場合に所定の報知を行うように構成される。

上記構成によれば、ユーザが状況を把握しやすくなる。

（第５項）第１項～第４項のいずれか１項に記載のモバイル端末が以下の特徴をさらに有する。受信部は、無線通信によってサーバから更新用ソフトウェアを取得するように構成される。送信部は、無線通信によって車両へ送信するように構成される。

上記構成によれば、ユーザの利便性が向上する。

本開示の第２の観点に係る形態に従うと、以下に示すモバイル端末が提供される。

（第６項）当該モバイル端末は、記憶部と取得部と送信部とを備える。取得部は、車両に搭載されるシングルバンクタイプのコンピュータの更新前のソフトウェアのバージョン情報を取得するように構成される。送信部は、更新前のソフトウェアのバージョン情報を記憶部に記憶させた後に、サーバから取得した更新用ソフトウェアを車両へ送信するように構成される。

上記構成を有するモバイル端末によれば、上記車両がシングルバンクタイプのコンピュータのソフトウェア更新に失敗した場合に、モバイル端末は、記憶部に保存された更新前のソフトウェアのバージョン情報に基づいて、例えばサーバから更新前のソフトウェアを取得することが可能になる。そして、車両は、モバイル端末から更新前のソフトウェアを受信し、その更新前のソフトウェアを用いてシングルバンクタイプのコンピュータのロールバックを行うことが可能になる。

本開示の第３の観点に係る形態に従うと、以下に示すソフトウェア配信システムが提供される。

（第７項）当該ソフトウェア配信システムは、第１項～第６項のいずれか１項に記載のモバイル端末と、車両と、サーバとを備える。車両は、ソフトウェア更新のシーケンスを管理する制御装置を備える。制御装置は、モバイル端末から受け取った更新用ソフトウェアを用いて、シングルバンクタイプのコンピュータのソフトウェア更新を実行し、当該ソフトウェア更新に失敗した場合には、モバイル端末から更新前のソフトウェアを受け取り、更新前のソフトウェアを用いてロールバックを実行するように構成される。

上記のソフトウェア配信システムによれば、車両側でソフトウェア更新を管理しやすくなる。

（第８項）第７項に記載のソフトウェア配信システムが以下の特徴をさらに有する。上記シングルバンクタイプのコンピュータは、車両の走行制御を行うコンピュータである。

上記構成によれば、走行制御に関するソフトウェアの更新に失敗した場合に、更新前のソフトウェアに戻せる（ロールバックできる）。更新前のソフトウェアによって、車両は以前と同様に走行できる。このため、ユーザは安心できる。

本開示によれば、車両に搭載されたシングルバンクタイプのコンピュータについても、ＯＴＡ技術による好適なソフトウェア更新が可能になる。

本開示の実施の形態に係るソフトウェア配信システムの概略構成を示す図である。 本開示の実施の形態に係るソフトウェア更新方法の概要について説明するための図である。 本開示の実施の形態に係るソフトウェア更新方法の処理手順を示す第１のフローチャートである。 本開示の実施の形態に係るソフトウェア更新方法の処理手順を示す第２のフローチャートである。 図４に示した処理のうち、ターゲットＥＣＵが備えるデュアルバンクマイコンのアクティベート（ロールバック）処理について説明するための図である。 図４に示した処理のうち、ターゲットＥＣＵが備えるシングルバンクマイコンのアクティベート（ロールバック）処理の第１例について説明するための図である。 図４に示した処理のうち、ターゲットＥＣＵが備えるシングルバンクマイコンのアクティベート（ロールバック）処理の第２例について説明するための図である。 図３に示した処理の第１変形例を示すフローチャートである。 図３に示した処理の第２変形例を示すフローチャートである。

本開示の実施の形態について、図面を参照しながら詳細に説明する。図中、同一または相当部分には同一符号を付してその説明は繰り返さない。

図１は、この実施の形態に係るソフトウェア配信システムの構成を示す図である。図１を参照して、このソフトウェア配信システムは、車両１００と、モバイル端末３００と、ＯＴＡセンタ５００とを含む。なお、「ＯＴＡ」は、「Over The Air」の略語である。

車両１００は、内燃機関を備えない電気自動車（ＢＥＶ）である。この実施の形態に係る車両１００は、ＯＴＡアクセス機能（ＯＴＡセンタ５００と直接無線通信する機能）を有しておらず、他の通信装置（すなわち、車両１００自身が備える通信装置ではない通信装置）を経由しなければＯＴＡセンタ５００と通信することができない。具体的には、車両１００は、モバイル端末３００を介して、ＯＴＡセンタ５００と無線通信を行う。ただし、車両１００は、以下に説明するソフトウェア配信システムが適用される車両の一例であり、他の車両にソフトウェア配信システムが適用されてもよい。

モバイル端末３００は、ユーザによって持ち運び可能に構成される。モバイル端末３００は、車両１００のユーザ（車両管理者）によって携帯されて操作される。この実施の形態では、モバイル端末３００として、タッチパネルディスプレイを具備するスマートフォンを採用する。スマートフォンは、コンピュータを内蔵し、スピーカ機能を有する。ただしこれに限られず、モバイル端末３００としては、車両１００のユーザが携帯可能な任意の端末を採用可能である。例えば、ラップトップ、タブレット端末、携帯型ゲーム機、ウェアラブルデバイス（スマートウォッチ、スマートグラス、スマートグローブなど）なども、モバイル端末３００として採用可能である。

モバイル端末３００は、プロセッサ３１０、メモリ３２０、および通信モジュール３３０を備える。プロセッサ３１０は、例えばＣＰＵ（Central Processing Unit）を含む。メモリ３２０は、例えばフラッシュメモリのような不揮発性メモリを含む。通信モジュール３３０は、ＯＴＡセンタ５００と直接的に無線通信を行うための通信Ｉ／Ｆ（インターフェース）を含む。また、通信モジュール３３０は、車両１００と直接的に無線通信を行うための通信Ｉ／Ｆも含む。モバイル端末３００は、車両１００とＯＴＡセンタ５００との通信を仲介する。例えば、モバイル端末３００が、車両１００からの要求に応じて、ＯＴＡセンタ５００のアドレスを指定して通信ネットワークＮＷにアクセスすることにより、車両１００（ＥＣＵ１１０）がモバイル端末３００（通信モジュール３３０）を介してＯＴＡセンタ５００と通信可能になる。これにより、車両１００とＯＴＡセンタ５００との間での無線通信が確立する。

モバイル端末３００には、ＯＴＡセンタ５００が提供するサービスを利用するためのアプリケーションソフトウェア（以下、「モバイルアプリ」と称する）がインストールされている。モバイルアプリにより、モバイル端末３００の識別情報（端末ＩＤ）が、車両１００の識別情報（車両ＩＤ）と紐付けられてＯＴＡセンタ５００に登録される。また、モバイル端末３００は、モバイルアプリを通じて、ＯＴＡセンタ５００と情報のやり取りを行うことができる。

ＯＴＡセンタ５００は、ＯＴＡ技術による車両ソフトウェア更新サービスを提供するサーバである。ＯＴＡセンタ５００は、当該センタから通信区画を経由して遠隔での車載ＥＣＵソフトウェア更新を実施するように構成される。ＯＴＡセンタ５００は、車載ＥＣＵのソフトウェアを配信する。なお、「ＥＣＵ」は、電子制御装置（Electronic Control Unit）を意味する。

ＯＴＡセンタ５００は、プロセッサ５１０、メモリ５２０、および通信モジュール５３０を備える。プロセッサ５１０は、例えばＣＰＵを含む。メモリ５２０は、例えばフラッシュメモリのような不揮発性メモリを含む。通信モジュール５３０は、有線で通信ネットワークＮＷと接続され、通信ネットワークＮＷを介して複数のモバイル端末（モバイル端末３００を含む）と通信する。通信ネットワークＮＷは、例えばインターネットと無線基地局とによって構築される広域ネットワークである。通信ネットワークＮＷは携帯電話網を含んでもよい。

ＯＴＡセンタ５００には、ＯＴＡセンタ５００から車両ソフトウェア更新サービスを受ける各車両（車両１００を含む）の識別情報（車両ＩＤ）が予め登録されている。ＯＴＡセンタ５００の記憶装置（例えば、メモリ５２０）は、各車両に関する情報（以下、「車両情報」とも称する）を、車両ＩＤで区別して記憶している。車両情報は、例えば、各車両の仕様と、各車両の通信アドレス（車両１００に関しては、モバイル端末３００の通信アドレス）とを含む。

車両１００は、複数のＥＣＵ（ＥＣＵ１１０，１２１，１２２を含む）を備える。車両１００が備えるＥＣＵの数は任意である。各車載ＥＣＵは、少なくとも１つのプロセッサと、少なくとも１つのメモリとを備えるコンピュータを内蔵する。各車載ＥＣＵは、メインマイコンおよびサブマイコンのような形態で、複数のマイコン（マイクロコンピュータ）を備えてもよい。車両１００においては、ＥＣＵ同士が、通信バスを介して接続されており、有線通信可能に構成される。なお、ＥＣＵ間の通信方式は、特に限定されないが、例えばＣＡＮ（Controller Area Network）またはＥｔｈｅｒｎｅｔ（登録商標）であってもよい。

ＥＣＵ１１０は、プロセッサ１１１およびメモリ１１２を備える。プロセッサ１１１は、例えばＣＰＵを含む。メモリ１１２は、例えばフラッシュメモリのような不揮発性メモリを含む。車両１００は通信装置１９０をさらに備える。ＥＣＵ１１０は通信装置１９０を通じて車両外部の装置と通信を行う。通信装置１９０は、モバイル端末３００と直接的に無線通信を行うための通信Ｉ／Ｆ（インターフェース）を含む。通信装置１９０とモバイル端末３００とは、無線ＬＡＮ（Local Area Network）、ＮＦＣ（Near Field Communication）、またはＢｌｕｅｔｏｏｔｈ（登録商標）のような近距離通信を行なってもよい。通信装置１９０は、車内または車両周辺の範囲内に存在するモバイル端末３００と直接通信してもよい。車両１００の停車中に車内または車外のモバイル端末３００とＥＣＵ１１０とが通信装置１９０を介して相互に情報のやり取りを行ってもよい。また、車両１００の走行中に車内のモバイル端末３００とＥＣＵ１１０とが通信装置１９０を介して相互に情報のやり取りを行ってもよい。ＥＣＵ１１０は、前述のようにＯＴＡセンタ５００との通信をモバイル端末３００に要求することで、モバイル端末３００を介してＯＴＡセンタ５００と通信することができる。

上記のように、車両１００のＥＣＵ１１０は、モバイル端末３００を介して、ＯＴＡセンタ５００と無線通信可能に構成される。車両１００は、停車中と走行中とのいずれにおいても、ＯＴＡセンタ５００と通信できる。ＥＣＵ１１０は、車両内情報を管理し、キャンペーンを受け取り、ソフトウェア更新シーケンスを管理する。

なお、車両１００とモバイル端末３００との通信方式は上記近距離通信に限られない。車両１００とモバイル端末３００とは互いに離れていても通信できるように構成されてもよい。また、通信装置１９０は、図示しないスキャンツール（有線ソフトウェア更新を行う専用ツール）と有線通信を行うための通信Ｉ／Ｆをさらに含んでもよい。ＥＣＵ１１０は、通信装置１９０を介して、図示しない車内のＤＬＣ（Data Link Connector）に接続されたスキャンツールと有線通信してもよい。

車両１００は、自動運転可能に構成される自動運転車両である。より詳しくは、車両１００は、有人走行と無人走行との両方を実行可能に構成される。車両１００は、無人で自律走行可能に構成されるが、ユーザによる手動運転で走行（有人走行）することもできる。また、車両１００は、有人走行中に自動運転（例えば、オートクルーズコントロール）を実行することも可能である。自動運転のレベルは、完全自動運転（レベル５）であってもよいし、条件付きの自動運転（例えば、レベル４）であってもよい。

車両１００は、運転装置１３０と、ＡＤＳ（Autonomous Driving System）１４０とをさらに備える。車両１００においては、ＥＣＵ１２１が運転装置１３０を制御するように構成される。

運転装置１３０は、アクセル装置、ブレーキ装置、および操舵装置を含む。アクセル装置は、例えば、車両の駆動輪を回転させるモータジェネレータ（以下、「ＭＧ」と表記する）と、ＭＧを駆動するＰＣＵ（Power Control Unit）と、ＭＧを駆動するための電力をＰＣＵに供給するバッテリとを含む。ＭＧは、車両の走行用モータとして機能する。ブレーキ装置は、例えば、車両の各車輪に設けられた制動装置と、制動装置を駆動するアクチュエータとを含む。操舵装置は、例えば、ＥＰＳ（Electric Power Steering）と、ＥＰＳを駆動するアクチュエータとを含む。

ＡＤＳ１４０は、車両の外部環境を認識する認識用センサ（例えば、カメラ、ミリ波レーダ、ライダーの少なくとも１つ）を含み、認識用センサによって逐次取得される情報に基づいて自動運転に係る処理を実行する。具体的には、ＡＤＳ１４０は、ＥＣＵ１２１と連携しながら、車両の外部環境に応じた走行計画（今後の車両の挙動を示す情報）を生成する。そして、ＡＤＳ１４０は、その走行計画に従って車両１００を走行させるように、運転装置１３０に含まれる各種アクチュエータの制御をＥＣＵ１２１に要求する。

なお、この実施の形態では、ＡＤＳが車両に内蔵される。しかしこれに限られず、ＡＤＳは、車両に対して着脱可能な自動運転キットであってもよい。自動運転キットのセンサユニット（認識用センサを含む）は、車両のルーフトップに取り付けられてもよい。

車両１００は、起動スイッチ１５０と、ＨＭＩ（Human Machine Interface）１７０とをさらに備える。

起動スイッチ１５０は、ユーザが車両システム（車両１００の制御システム）を起動させるためのスイッチであり、例えば車室内に設置される。一般に、起動スイッチは「パワースイッチ」または「イグニッションスイッチ」などと称される。ユーザが起動スイッチ１５０を操作することによって車両システム（車両に搭載された各ＥＣＵを含む）のオン（作動）／オフ（停止）が切り替わる。起動スイッチ１５０がオン操作されることによって停止状態の車両システムが起動し、車両システムは作動状態（以下、「ＩＧオン」とも称する）になる。また、車両システムが作動しているときに、起動スイッチ１５０がオフ操作されると、車両システムは停止状態（以下、「ＩＧオフ」とも称する）になる。

起動スイッチ１５０のオン操作は、車両の状態をＩＧオフからＩＧオンに切り替えるための操作である。ユーザが起動スイッチ１５０をオン操作すると、起動要求が各車載ＥＣＵに入力される。すなわち、各車載ＥＣＵは、ユーザからの起動要求を受け付ける。一方、起動スイッチ１５０のオフ操作は、車両の状態をＩＧオンからＩＧオフに切り替えるための操作である。ユーザが起動スイッチ１５０をオフ操作すると、シャットダウン要求が各車載ＥＣＵに入力され、車両１００はシャットダウン待機状態になる。このように、各車載ＥＣＵは、ユーザからのシャットダウン要求を受け付ける。ただし、走行中の車両においては、起動スイッチ１５０のオフ操作が禁止される。

ＨＭＩ１７０は入力装置および表示装置を含む。ＨＭＩ１７０は、入力装置および表示装置として機能するタッチパネルディスプレイを含んでもよい。ＨＭＩ１７０は、表示装置として、インフォメーションディスプレイまたはテンテールを含んでもよい。ＨＭＩ１７０は、入力装置として、ステアリングスイッチを含んでもよい。また、ＩＶＩ（In-Vehicle Infotainment）システムと、メータパネルと、ヘッドアップディスプレイとの少なくとも１つが、ＨＭＩ１７０として機能してもよい。ＨＭＩ１７０は、カーナビゲーションシステムの入力装置および表示装置を含んでもよい。

図２は、この実施の形態に係るソフトウェア更新方法の概要について説明するための図である。図１とともに図２を参照して、ソフトウェア更新（より詳しくは、ＯＴＡを利用した車両ソフトウェアの更新）に係る処理は、構成同期、キャンペーン通知と適用承諾、ダウンロード、インストール、アクティベート、ソフトウェア更新完了通知のような手順で行われる。以下に説明する処理は、ＯＴＡセンタ５００と、ＯＴＡセンタ５００からのソフトウェア配信を受ける各車両（車両１００を含む）とによって実行される。ＯＴＡセンタ５００からの配信を受ける車両の数は、５０台程度でもよいし、１００台以上１０００台未満でもよいし、１０００台以上でもよい。

ＩＧオン状態の車両１００は、予め設定された時間が経過するごとに繰り返し構成同期を実行する。また、ＩＧオン状態の車両１００は、ＯＴＡセンタ５００から構成同期の要求を受けた場合にも構成同期を実行する。車両１００（ＥＣＵ１１０）による構成同期処理は、車両構成情報をＯＴＡセンタ５００に送信することを含む。車両構成情報は、例えば、車両１００に含まれるＥＣＵごとのハードウェア情報（ハードウェアの品番、ＥＣＵの識別子などを示す情報）およびソフトウェア情報（ソフトウェアの品番などを示す情報）を含む。この実施の形態では、車両構成情報が、認可対象ごとのＲＸＳＷＩＮをさらに含む。ＲＸＳＷＩＮは、機能型式認可を構成するソフトウェアを特定可能な識別番号である。

ＯＴＡセンタ５００は、車両１００から上記車両構成情報を受信すると、現時点で発生しているキャンペーン（ソフトウェアの更新）を確認する。そして、車両１００に適用可能なキャンペーンが存在すれば、ＯＴＡセンタ５００は、そのキャンペーンに係る新しいソフトウェア（ソフトウェアの更新版）のダウンロードの承諾を車両１００のユーザに要求する承諾要求信号を送信する。承諾要求信号は、そのキャンペーンに関する情報（キャンペーン情報）を含む。キャンペーン情報は、例えば、キャンペーン属性情報（ソフトウェア更新の目的、および更新で影響の可能性がある車両１００の機能などを示す情報）と、キャンペーン対象車両のリストと、キャンペーン対象ＥＣＵに関する情報（例えば、更新前後のソフトウェア情報）と、更新前後のユーザへの通知に関する情報との少なくとも１つを含んでもよい。なお、通知されるキャンペーンは、新たに発生したキャンペーンかもしれないし、以前適用しなかったキャンペーンかもしれない。以下では、上記承諾要求信号の送信を、「キャンペーン通知」とも称する。

車両１００は、キャンペーン通知（承諾要求信号）を受けると、そのキャンペーンの適用を承諾するか否かの入力をユーザに求める。具体的には、車両１００は、例えば「新しいソフトウェアが見つかりました。この車に適用しますか？」のようなメッセージを車載ＨＭＩ（例えば、ＨＭＩ１７０）に表示させて、「承諾」と「拒否」とのいずれか一方を示す入力をユーザに要求する。そして、ユーザが車載ＨＭＩに対して「承諾」を示す入力を行うと、車両１００は、以下に説明するダウンロードに係る処理を実行する。他方、ユーザが車載ＨＭＩに対して「拒否」を示す入力を行うと、車両１００はダウンロードに係る処理を実行しない。この場合、ＯＴＡセンタ５００は、ソフトウェア更新に係る処理をダウンロードフェーズに進めることなく終了させる。

この実施の形態では、ＯＴＡセンタ５００と車両１００（ＥＣＵ１１０）とが、以下に説明する手順でダウンロードに係る処理を実行する。

車両１００のＥＣＵ１１０は、新しいソフトウェアを含む配信パッケージをモバイル端末３００に要求する。そして、ＥＣＵ１１０は、モバイル端末３００を介してＯＴＡセンタ５００と無線通信を行いながら、その配信パッケージのダウンロード（受信および保存）を実行する。配信パッケージは、新しいソフトウェア（例えば、キャンペーンの対象となるＥＣＵごとの更新データのセット）に加えて、パッケージ属性情報（更新区分、配信パッケージ中の更新データ数、各ＥＣＵのインストール順序などを示す情報）、および更新データ属性情報（ターゲットＥＣＵの識別子、更新データの正当性を検証するための検証用データなど）を含んでもよい。ターゲットＥＣＵは、ソフトウェア更新対象となるＥＣＵである。例えば、ターゲットＥＣＵがＥＣＵ１２１であり、更新されるソフトウェアが自動運転制御プログラムであってもよい。

上述したダウンロードに係る処理により、ＥＣＵ１１０が備える記憶装置（例えば、メモリ１１２）に上記配信パッケージが保存される。ダウンロード中は、車載ＨＭＩがユーザにダウンロードの進捗を報知する。ダウンロード完了後、ＥＣＵ１１０は、ダウンロードされた配信パッケージの真正性を検証する。そして、検証の結果が「正常」であれば、ＥＣＵ１１０はソフトウェア更新状態（ダウンロード完了）を、モバイル端末３００を介してＯＴＡセンタ５００に通知する。この通知が行われることは、ダウンロードが成功したことを意味する。

ダウンロードが成功すると、車両１００はインストールを実行する。具体的には、ＥＣＵ１１０は、ターゲットＥＣＵ（例えば、ＥＣＵ１２１）に、当該ターゲットＥＣＵの状態およびＤＴＣ（Diagnostic Trouble Code）の出力を要求する。ＥＣＵ１１０は、ターゲットＥＣＵの状態およびＤＴＣに基づいて、ターゲットＥＣＵごとにインストール実行可否を判断する。そして、ＥＣＵ１１０は、インストール実行可能なターゲットＥＣＵに新しいソフトウェア（更新データ）を転送する。更新データを受信したターゲットＥＣＵは、その更新データのインストール（不揮発性メモリへの書込み）を実行する。インストール中は、車載ＨＭＩがユーザにインストールの進捗を報知する。

ＥＣＵ１１０からターゲットＥＣＵへの上記更新データの転送が完了すると、ターゲットＥＣＵは、転送完了通知をＥＣＵ１１０に送信する。そして、転送完了通知を受けたＥＣＵ１１０は、ターゲットＥＣＵに完全性検証を要求する。この要求を受けたターゲットＥＣＵは、完全性検証データ（検証用データ）を用いて検証を行い、その検証結果をＥＣＵ１１０へ送信する。ＥＣＵ１１０は、ターゲットＥＣＵごとの検証結果（インストールの完了／失敗／中止）を保存する。全てのターゲットＥＣＵの完全性検証が完了し、全ての検証結果が「正常」であれば、ＥＣＵ１１０は、ソフトウェア更新状態（インストール完了）を、モバイル端末３００を介してＯＴＡセンタ５００に通知する。この通知が行われることは、インストールが成功したことを意味する。

ダウンロードに続けてインストールにも成功すると、車両１００はアクティベート待ち状態になる。その後、車両１００の起動スイッチ１５０にオフ操作が行われると、ＥＣＵ１１０が、車載ＨＭＩにアクティベート承諾画面を表示させて、「承諾」と「拒否」とのいずれか一方を示す入力をユーザに要求する。アクティベート承諾画面は、車両１００の制限事項（例えば、一定時間車両を使用できないこと、または過大電流デバイスの動作が制限されること）を表示してもよい。アクティベート承諾画面は、アクティベートが完了するまで車両１００を非走行状態（例えば、シャットダウン待機状態、パーキングレンジ固定、または電動パーキングブレーキ作動）に維持することをユーザに要求してもよい。アクティベート承諾画面は、車両１００の状態の確認をユーザに促すメッセージを表示してもよい。

そして、ユーザがアクティベート承諾画面に対して「承諾」を示す入力を行うと、ＥＣＵ１１０が各ターゲットＥＣＵにアクティベート（インストールされたソフトウェアの有効化）を要求する。他方、ユーザがアクティベート承諾画面に対して「拒否」を示す入力を行うと、ＥＣＵ１１０はアクティベートを実行することなくソフトウェア更新に係る処理を中止し、車両システムがシャットダウンされる。

ターゲットＥＣＵは、ＥＣＵ１１０からの要求に応じてアクティベートを実行する。複数のマイコン（例えば、メインマイコン及びサブマイコン）を備えるターゲットＥＣＵでは、ターゲットＥＣＵ内のサブマイコンが、ターゲットＥＣＵ内のメインマイコンが持つＦｌａｓｈ書換え機能によって書換えを行ってもよい。あるいは、ターゲットＥＣＵ内の各マイコンが、ＥＣＵ１１０と直接通信して書換えを行ってもよい。

各ターゲットＥＣＵは、アクティベートの結果（成功／失敗）をＥＣＵ１１０に通知する。詳細は後述するが、ターゲットＥＣＵにおいてアクティベートが失敗した場合には、ソフトウェアのロールバックが実行される。他方、ターゲットＥＣＵにおいてアクティベートが成功すると、例えば、ターゲットＥＣＵ内の全てのマイコン（更新対象）の書換えが完了した時点でそれらのマイコンが同期してリセット起動（自己リセット）し、更新後のソフトウェアを起動する。ターゲットＥＣＵは、自己リセット完了後、ＥＣＵ１１０からのシャットダウン要求を待っている状態になる。こうした状態のターゲットＥＣＵは、ＥＣＵ１１０とのダイアグノーシス通信を継続できる。

ＥＣＵ１１０は、ターゲットＥＣＵからアクティベート成功の通知を受けると、更新後のソフトウェアの識別情報（ECU Software ID）をターゲットＥＣＵに要求する。そして、ＥＣＵ１１０は、ターゲットＥＣＵから受け取った識別情報と、キャンペーン情報に含まれる更新後のソフトウェアの識別情報とが、互いに一致するか否かを確認する（構成の確認）。構成の確認が成功したら（すなわち、ソフトウェアの識別情報が一致したら）、ＥＣＵ１１０はＲＸＳＷＩＮを更新する。ＲＸＳＷＩＮが更新されたことは、アクティベートが成功したことを意味する。

全てのターゲットＥＣＵについてアクティベートが成功すると、ＥＣＵ１１０は、ソフトウェア更新状態（ソフトウェア更新完了）を、モバイル端末３００を介してＯＴＡセンタ５００に通知する。この通知が行われることは、ＯＴＡソフトウェア更新が成功したことを意味する。また、ＥＣＵ１１０は、ソフトウェア更新の結果を車載ＨＭＩに表示させてもよい。車載ＨＭＩは、例えば更新の成功を示すソフトウェア更新完了画面を表示する。上記ソフトウェア更新完了の通知が行われると、ＥＣＵ１１０が各ターゲットＥＣＵにシャットダウン要求を行い、車両１００の制御システムがシャットダウンされる。これにより、車両１００はＩＧオフになる。その後、車両１００の起動スイッチ１５０にオン操作が行われると、車両システムがＩＧオンになる。これにより、ターゲットＥＣＵで更新プログラム（新しいバージョンのソフトウェア）が起動する。なお、更新されるソフトウェアは、上述の自動運転制御プログラムのような運転支援系の制御プログラムに限られず任意である。例えば、ＯＴＡセンタ５００は、エンターテイメントに関するソフトウェアを配信してもよい。

ところで、車載ＥＣＵ内の典型的なマイコン（マイクロコンピュータ）は、デュアルバンクマイコン（デュアルバンクタイプのマイクロコンピュータ）とシングルバンクマイコン（シングルバンクタイプのマイクロコンピュータ）とに大別される。デュアルバンクマイコンでは、アクティブ面に旧ソフトウェア（元のバージョンのソフトウェア）を残したまま、書込み面に新ソフトウェア（新しいバージョンのソフトウェア）が書き込まれるため、アクティベートに失敗した場合には、アクティブ面に残した旧ソフトウェアによって、書込み面を旧ソフトウェアに戻すこと（ロールバック）ができる。これに対し、シングルバンクマイコンでは、１つのバンクにおいてソフトウェアの上書きが行われる。このため、旧ソフトウェアは残らない。シングルバンクマイコンでは、アクティベートに失敗した場合に旧ソフトウェアに戻すこと（ロールバック）ができないという課題が生じ得る。

そこで、この実施の形態に係るソフトウェア配信システムは、以下に説明する図３および図４に示す処理を実行することにより、車両に搭載されたシングルバンクタイプのコンピュータについても、ＯＴＡ技術による好適なソフトウェア更新を可能にしている。

この実施の形態に係るソフトウェア配信システムにおいて、ソフトウェア更新の対象（以下、単に「更新対象」と称する）となるマイコンは、ターゲットＥＣＵが備えるシングルバンクマイコンとデュアルバンクマイコンとの少なくとも一方である。詳細は後述するが、車両１００においては、ＥＣＵ１２１がシングルバンクマイコンを内蔵し、ＥＣＵ１２２がデュアルバンクマイコンを内蔵する。ターゲットＥＣＵにおいて更新対象のアクティベートが失敗した場合には、更新対象のロールバックが実行される。特に、互いに連携して制御を実行する複数のマイコンについては、ソフトウェアのバージョンを揃えることが要求される。これらのマイコンでは、ソフトウェアのバージョンアップ（ソフトウェア更新）が同時に実行され、それらマイコンのいずれかでアクティベートが失敗した場合には、全てのマイコンについて、旧ソフトウェアに戻す処理（ロールバック処理）が実行される。

図３は、この実施の形態に係るソフトウェア更新方法の処理手順を示す第１のフローチャートである。このフローチャートに示される一連の処理は、前述の構成同期の実行タイミングになると（例えば、構成同期の実行条件が成立すると）、モバイル端末３００および車両１００によって実行される。この実施の形態では、図１に示したプロセッサ３１０が、本開示に係る「受信部」、「送信部」、「取得部」、および「判断部」の一例として機能し、図１に示したメモリ３２０が、本開示に係る「記憶部」の一例として機能する。フローチャート中の「Ｓ」は、ステップを意味する。１以上のプロセッサが１以上のメモリに記憶されたプログラムを読み込んで実行することにより下記のフローチャートが実現される。

図１，図２とともに図３を参照して、Ｓ１１～Ｓ１７の一連の処理は、モバイル端末３００によって実行される。Ｓ３１～Ｓ３６の一連の処理は、車両１００によって実行される。Ｓ３１では、ＥＣＵ１１０が、モバイル端末３００を介して、構成同期（図２）を実行する。モバイル端末３００は、Ｓ１１において車両１００とＯＴＡセンタ５００との間での構成同期を仲介する。車両１００に適用可能なキャンペーンが存在する場合には、ＥＣＵ１１０は、Ｓ３２において、ＯＴＡセンタ５００からモバイル端末３００を経由してキャンペーン通知（図２）を受ける。モバイル端末３００は、Ｓ１２においてＯＴＡセンタ５００から車両１００へのキャンペーン通知を仲介する。そして、キャンペーンの適用についてユーザが車載ＨＭＩに対して「承諾」を示す入力を行うと、処理がＳ１３，Ｓ３３に進む。なお、車両１００に適用可能なキャンペーンが存在しない場合と、キャンペーンの適用についてユーザが「拒否」を示す入力を行った場合との各々においては、図３に示す一連の処理が終了する。その後、構成同期の実行タイミングになると、再び図３に示す一連の処理が開始される。

Ｓ１３では、モバイル端末３００が、更新対象（ソフトウェア更新の対象となるコンピュータ）がシングルバンクマイコンであるか否かを判断する。更新対象は、ターゲットＥＣＵに含まれるマイクロコンピュータである。モバイル端末３００は、車両１００（ＥＣＵ１１０）から、更新対象の情報を取得してもよい。あるいは、モバイル端末３００は、キャンペーン情報（Ｓ１２）から更新対象の情報を抽出してもよい。更新対象がシングルバンクマイコンである場合には（Ｓ１３にてＹＥＳ）、モバイル端末３００が、Ｓ１４において、メモリ３２０の空き容量を確認し、更新対象の旧ソフトウェア（すなわち、更新対象のアクティブ面に記憶されている更新前のソフトウェア）を保存するための空き容量がメモリ３２０に存在するか否かを判断する。モバイル端末３００は、車両１００（ＥＣＵ１１０）から、更新対象の旧ソフトウェア（本体）のデータサイズを取得してもよい。あるいは、モバイル端末３００は、キャンペーン情報（Ｓ１２）から更新前のソフトウェアの情報を抽出してもよい。

更新対象の旧ソフトウェアを保存するための空き容量をメモリ３２０が有する場合には（Ｓ１４にてＹＥＳ）、モバイル端末３００が、Ｓ１５において、更新対象の旧ソフトウェア（本体）を車両１００に要求する。以下、この要求（Ｓ１５）を、「第１要求」とも称する。

車両１００（ＥＣＵ１１０）は、ユーザから前述の「承諾」を示す入力を受けた後、Ｓ３３において、モバイル端末３００からの上記第１要求を待つ。具体的には、ＥＣＵ１１０は、Ｓ３３において、ユーザが「承諾」を示す入力を行ってから所定時間以内に、モバイル端末３００から第１要求を受けたか否かを判断する。Ｓ１４においてＹＥＳと判断される場合には、上記所定時間が経過する前にモバイル端末３００が車両１００に対して第１要求を実行し、Ｓ３３においてＹＥＳと判断される。この場合、ＥＣＵ１１０は、続くＳ３４において、更新対象の旧ソフトウェア（本体）をモバイル端末３００へ送信する。そして、モバイル端末３００は、車両１００から受信した旧ソフトウェア（本体）をメモリ３２０に保存する。その後、処理がＳ１７，Ｓ３５に進む。他方、Ｓ１４においてＮＯと判断される場合には、車両１００が第１要求を受けることなく上記所定時間が経過し、Ｓ３３においてＮＯと判断される。この場合、Ｓ３４の処理が実行されることなく、処理がＳ３５に進む。

更新対象の旧ソフトウェアを保存するための空き容量をメモリ３２０が有しない場合には（Ｓ１４にてＮＯ）、モバイル端末３００は、Ｓ１６において、更新対象の旧ソフトウェアのバージョン情報をメモリ３２０に保存する。旧ソフトウェアのバージョン情報のデータサイズは、旧ソフトウェア本体のデータサイズと比べて非常に小さい。モバイル端末３００は、車両１００（ＥＣＵ１１０）から、更新対象の旧ソフトウェアのバージョン情報を取得してもよい。あるいは、モバイル端末３００は、キャンペーン情報（Ｓ１２）から更新対象の旧ソフトウェアのバージョン情報を抽出してもよい。

Ｓ１５またはＳ１６において更新対象の旧ソフトウェア本体または旧ソフトウェアバージョン情報がメモリ３２０に保存されると、処理がＳ１７に進む。Ｓ１７では、モバイル端末３００が、無線通信によってＯＴＡセンタ５００から更新対象の新ソフトウェア（新しいバージョンのソフトウェア本体）を受信しつつ、受信した新ソフトウェアを無線通信によって車両１００へ送信する。

Ｓ３５では、車両１００（ＥＣＵ１１０）が、モバイル端末３００から上記新ソフトウェア（Ｓ１７）を受信したか否かを判断する。そして、車両１００がモバイル端末３００から新ソフトウェアを受信すると（Ｓ３５にてＹＥＳ）、ＥＣＵ１１０は、Ｓ３６において新ソフトウェアのダウンロードおよびインストール（図２）を実行する。具体的には、ＥＣＵ１１０は、モバイル端末３００を介して、更新対象の新ソフトウェアのダウンロード（図２）を実行する。モバイル端末３００は、Ｓ１７においてＯＴＡセンタ５００から車両１００へのダウンロードを仲介する。そして、ダウンロードが成功すると、新ソフトウェアが更新対象に書き込まれる（インストール）。

更新対象が複数のマイコン（コンピュータ）を含む場合には、更新対象ごとにＳ１３～Ｓ１７およびＳ３３～Ｓ３６の処理が実行される。更新対象がシングルバンクマイコンである場合には（Ｓ１３にてＹＥＳ）、モバイル端末３００が、上述のようにＳ１５またはＳ１６において更新対象の旧ソフトウェアまたはそのバージョン情報をメモリ３２０に記憶させた後、Ｓ１７において、ＯＴＡセンタ５００から取得した新ソフトウェア（更新用ソフトウェア）を車両１００へ送信する。他方、更新対象がデュアルバンクマイコンである場合には（Ｓ１３にてＮＯ）、Ｓ１４～Ｓ１６の処理が行われることなく、Ｓ１７の処理が実行される。そして、Ｓ１５の処理が行われないため、Ｓ３３においてＮＯと判断される。

全ての更新対象について新ソフトウェアのダウンロードおよびインストールが完了した後に所定のアクティベート開始条件が成立すると、処理は図４のＳ２１，Ｓ４１に進む。例えば、アクティベート開始条件が成立すると、ＥＣＵ１１０が各ターゲットＥＣＵにアクティベートを要求する。そして、以下に説明する図４に示す一連の処理が開始される。図４は、この実施の形態に係るソフトウェア更新方法の処理手順を示す第２のフローチャートである。

図１，図２とともに図４を参照して、Ｓ４１では、車両１００のターゲットＥＣＵが、ＥＣＵ１１０からの要求に応じて更新対象のアクティベート（図２）を実行する。ＥＣＵ１１０は、例えば、車両１００がアクティベート可能な状態であるか否かを判断し、車両１００がアクティベート可能な状態（例えば、シャットダウン待機状態）であると判断した場合に、更新対象のアクティベートをターゲットＥＣＵに要求する。

続くＳ４２では、更新対象のアクティベートが成功したか否かを、ターゲットＥＣＵが判断する。更新対象のアクティベートが失敗した場合には（Ｓ４２にてＮＯ）、ターゲットＥＣＵが、アクティベート失敗をＥＣＵ１１０に通知する。通知を受けたＥＣＵ１１０は、ターゲットＥＣＵに更新対象のロールバックを要求する。さらに、ＥＣＵ１１０は、当該更新対象と連携するマイコン（すなわち、当該更新対象と同じバージョンのソフトウェアで動作するマイコン）を備えるＥＣＵに、そのマイコンのロールバックを要求する。その後、処理はＳ４４に進む。

更新対象のアクティベートが成功した場合には（Ｓ４２にてＹＥＳ）、ターゲットＥＣＵが、Ｓ４３において、当該更新対象と連携するマイコンがアクティベートに失敗したか否かをさらに判断する。ターゲットＥＣＵは、ＥＣＵ１１０からの上記ロールバック要求の有無に基づいて、当該更新対象と連携するマイコンがアクティベートに失敗したか否かを判断してもよい。当該更新対象と連携するいずれかのマイコンがアクティベートに失敗した場合には（Ｓ４３にてＹＥＳ）、処理はＳ４４に進む。

Ｓ４４では、更新対象がシングルバンクマイコンであるか否かを、ターゲットＥＣＵが判断する。更新対象がシングルバンクマイコンである場合には（Ｓ４４にてＹＥＳ）、車両１００（ターゲットＥＣＵ）が、Ｓ４５において、更新対象の旧ソフトウェア（本体）をモバイル端末３００に要求する。以下、この要求（Ｓ４５）を、「第２要求」とも称する。

モバイル端末３００は、前述のダウンロード完了後、Ｓ２１において、車両１００からの上記第２要求を待つ。具体的には、モバイル端末３００は、Ｓ２１において、ダウンロードが完了してから所定時間以内に、車両１００から第２要求を受けたか否かを判断する。Ｓ４４においてＹＥＳと判断される場合には、上記所定時間が経過する前に車両１００がモバイル端末３００に対して第２要求を実行する。これにより、Ｓ２１においてＹＥＳと判断され、処理がＳ２２に進む。他方、Ｓ４４においてＮＯと判断される場合には、モバイル端末３００が第２要求を受けることなく上記所定時間が経過し、Ｓ２１においてＮＯと判断される。この場合、Ｓ２２～Ｓ２４の処理が実行されることなく、処理がＳ２５に進む。

Ｓ２２では、モバイル端末３００が更新対象の旧ソフトウェア（本体）を保有するか否かを、モバイル端末３００が判断する。図３のＳ１５の処理が実行された場合には、Ｓ２２においてＹＥＳと判断され、処理がＳ２４に進む。この場合、モバイル端末３００は、続くＳ２４において、メモリ３２０に記憶された更新対象の旧ソフトウェア（本体）を車両１００（ターゲットＥＣＵ）へ送信する。その後、処理がＳ２５に進む。

図３のＳ１５の処理が実行されなかった場合（すなわち、図３のＳ１６の処理が実行された場合）には、Ｓ２２においてＮＯと判断され、処理がＳ２３に進む。Ｓ２３では、モバイル端末３００が、メモリ３２０に記憶された更新対象の旧ソフトウェアのバージョン情報（図３のＳ１６）に基づいて、更新対象の旧ソフトウェア（本体）をＯＴＡセンタ５００から取得する。この場合、モバイル端末３００は、続くＳ２４において、ＯＴＡセンタ５００から取得した更新対象の旧ソフトウェア（本体）を車両１００（ターゲットＥＣＵ）へ送信する。その後、処理がＳ２５に進む。

更新対象がシングルバンクマイコンである場合には（Ｓ４４にてＹＥＳ）、車両１００が上記更新対象の旧ソフトウェア（Ｓ２４）を受信する。これにより、車両１００のターゲットＥＣＵが、Ｓ４６において、モバイル端末３００から受信した上記更新対象の旧ソフトウェア（本体）を用いて更新対象のロールバック処理（旧ソフトウェアに戻す処理）を実行する。ターゲットＥＣＵは、モバイル端末３００から更新対象の旧ソフトウェア（本体）を受信しつつ、受信した旧ソフトウェア（本体）で更新対象のバンク（シングルバンク）を更新前の状態に戻す。

更新対象がデュアルバンクマイコンである場合には（Ｓ４４にてＮＯ）、車両１００がモバイル端末３００から上記更新対象の旧ソフトウェア（Ｓ２４）を受信することなく、車両１００のターゲットＥＣＵが、Ｓ４６において、更新対象のロールバック処理を実行する。

図５は、ＥＣＵ１２２が備えるデュアルバンクマイコンのアクティベート（ロールバック）処理について説明するための図である。以下では、ＥＣＵ１２２がターゲットＥＣＵであり、かつ、デュアルバンクマイコンＭＣ２が更新対象である例について説明する。

図５を参照して、ＥＣＵ１２２は、２つのバンク（第１バンクおよび第２バンク）を有するデュアルバンクマイコンＭＣ２を備える。具体的には、デュアルバンクマイコンＭＣ２は、２つのメモリ（例えば、Ｆｌａｓｈメモリ）を備え、各メモリがマイコン内にバンクを形成している。例えば、第１バンクがアクティブ面である場合には、第２バンクが書込み面になる。アクティブ面（第１バンク）には、旧ソフトウェアが記憶されている。書込み面（第２バンク）には、前述のダウンロード処理およびインストール処理（図３のＳ３６）により新ソフトウェアが書き込まれる。その後、ＥＣＵ１２２（ターゲットＥＣＵ）は、図４のＳ４１においてデュアルバンクマイコンＭＣ２の書込み面をアクティブ面に切り替える（アクティベート）。ＥＣＵ１２２がデュアルバンクマイコンＭＣ２のアクティベートに成功し、かつ、ＥＣＵ１２２がＥＣＵ１１０からロールバック要求を受けなかった場合には、ＥＣＵ１２２は、自己リセットを行った後、ＥＣＵ１１０からのシャットダウン要求を待つ状態になる。この場合、旧ソフトウェアを記憶する第１バンクが書込み面になり、新ソフトウェアが書き込まれた第２バンクがアクティブ面になる。すなわち、デュアルバンクマイコンＭＣ２は、新ソフトウェア（更新後のプログラム）で起動する。他方、ＥＣＵ１２２がＥＣＵ１１０からロールバック要求を受けた場合には、ＥＣＵ１２２は、デュアルバンクマイコンＭＣ２のロールバック処理を実行する（図４のＳ４６）。この場合、旧ソフトウェアを記憶する第１バンクがアクティブ面に戻り、第２バンクが書込み面になる。また、書込み面には旧ソフトウェアが書き込まれる。その後、デュアルバンクマイコンＭＣ２は、旧ソフトウェア（更新前のプログラム）で起動する。

図６は、ＥＣＵ１２１が備えるシングルバンクマイコンのアクティベート（ロールバック）処理の第１例について説明するための図である。以下では、ＥＣＵ１２１がターゲットＥＣＵであり、かつ、シングルバンクマイコンＭＣ１が更新対象である例について説明する。しかも、この例では、ダウンロード時においてシングルバンクマイコンＭＣ１の更新前のソフトウェア（本体）を保存するための空き容量をメモリ３２０が有する。

図６を参照して、ＥＣＵ１２１は、１つのバンク（シングルバンク）を有するシングルバンクマイコンＭＣ１を備える。具体的には、シングルバンクマイコンＭＣ１は、１つのメモリ（例えば、Ｆｌａｓｈメモリ）を備え、そのメモリがマイコン内にバンクを形成している。シングルバンクマイコンＭＣ１は、車両１００の走行制御を行うコンピュータに相当する。例えば、通常動作時においてはバンクがアクティブ面になっている。ソフトウェア更新前においては、バンクに旧ソフトウェアが記憶されている。ソフトウェア更新時にはバンクが書込み面になる。そして、前述のダウンロード処理およびインストール処理（図３のＳ３６）によりバンクに新ソフトウェアが書き込まれる。ただし、書込み前に、旧ソフトウェア（更新前のソフトウェア）がモバイル端末３００のメモリ３２０に保存される（図３のＳ１５）。

その後、ＥＣＵ１２１（ターゲットＥＣＵ）は、図４のＳ４１においてシングルバンクマイコンＭＣ１の書込み面をアクティブ面に切り替える（アクティベート）。ＥＣＵ１２１がシングルバンクマイコンＭＣ１のアクティベートに成功し、かつ、ＥＣＵ１２１がＥＣＵ１１０からロールバック要求を受けなかった場合には、ＥＣＵ１２１は、自己リセットを行った後、ＥＣＵ１１０からのシャットダウン要求を待つ状態になる。この場合、新ソフトウェアが書き込まれたバンクがアクティブ面になる。すなわち、シングルバンクマイコンＭＣ１は、新ソフトウェア（更新後のプログラム）で起動する。他方、ＥＣＵ１２１がＥＣＵ１１０からロールバック要求を受けた場合には、ＥＣＵ１２１は、シングルバンクマイコンＭＣ１のロールバック処理を実行する（図４のＳ４４～Ｓ４６）。具体的には、ＥＣＵ１２１は、モバイル端末３００（メモリ３２０）から旧ソフトウェア（本体）を受信して、シングルバンクマイコンＭＣ１のバンクに旧ソフトウェアを書き込む。その後、旧ソフトウェアが書き込まれたバンクがアクティブ面になる。この場合、シングルバンクマイコンＭＣ１は、旧ソフトウェア（更新前のプログラム）で起動する。

図７は、ＥＣＵ１２１が備えるシングルバンクマイコンのアクティベート（ロールバック）処理の第２例について説明するための図である。以下では、ＥＣＵ１２１がターゲットＥＣＵであり、かつ、シングルバンクマイコンＭＣ１が更新対象である例について説明する。ただし、この例では、ダウンロード時においてシングルバンクマイコンＭＣ１の更新前のソフトウェア（本体）を保存するための空き容量をメモリ３２０が有しない。

図７を参照して、この例でも、ソフトウェア更新時にシングルバンクマイコンＭＣ１のバンクが書込み面になり、前述のダウンロード処理およびインストール処理（図３のＳ３６）により、そのバンクに新ソフトウェアが書き込まれる。ただし、この例では、書込み前に、旧ソフトウェア本体ではなく旧ソフトウェアのバージョン情報がモバイル端末３００のメモリ３２０に保存される（図３のＳ１６）。

その後、ＥＣＵ１２１（ターゲットＥＣＵ）は、図４のＳ４１においてシングルバンクマイコンＭＣ１の書込み面をアクティブ面に切り替える（アクティベート）。ＥＣＵ１２１がシングルバンクマイコンＭＣ１のアクティベートに成功し、かつ、ＥＣＵ１２１がＥＣＵ１１０からロールバック要求を受けなかった場合には、ＥＣＵ１２１は、自己リセットを行った後、ＥＣＵ１１０からのシャットダウン要求を待つ状態になる。この場合、新ソフトウェアが書き込まれたバンクがアクティブ面になる。すなわち、シングルバンクマイコンＭＣ１は、新ソフトウェア（更新後のプログラム）で起動する。他方、ＥＣＵ１２１がＥＣＵ１１０からロールバック要求を受けた場合には、ＥＣＵ１２１は、シングルバンクマイコンＭＣ１のロールバック処理を実行する（図４のＳ４４～Ｓ４６）。具体的には、ＥＣＵ１２１がモバイル端末３００に旧ソフトウェアを要求する（図４のＳ４５）。そして、モバイル端末３００は、ＥＣＵ１２１からの要求に応じて、メモリ３２０に記憶された上記バージョン情報が示すバージョンのソフトウェア（本体）をＯＴＡセンタ５００から取得し、取得したソフトウェア（本体）を車両１００（ＥＣＵ１２１）へ送信する。ＥＣＵ１２１は、モバイル端末３００から旧ソフトウェア（本体）を受信して、シングルバンクマイコンＭＣ１のバンクに旧ソフトウェアを書き込む。その後、旧ソフトウェアが書き込まれたバンクがアクティブ面になる。この場合、シングルバンクマイコンＭＣ１は、旧ソフトウェア（更新前のプログラム）で起動する。

再び図１，図２とともに図４を参照して、Ｓ４６では、ターゲットＥＣＵが、上述のように更新対象のロールバック処理を実行する。アクティベート中に何らかの障害が生じて更新対象のアクティベートが失敗したときには、ターゲットＥＣＵは、更新前のジャーナルファイル（ログ情報を書き込むファイル）を用いて更新対象を正常な状態に戻してもよい。ターゲットＥＣＵは、要求されたロールバックが完了すると、ＥＣＵ１１０に対してロールバック完了を通知する。ＥＣＵ１１０は、ロールバック完了の通知を受けると、更新前のソフトウェアの識別情報（ECU Software ID）をターゲットＥＣＵに要求する。そして、ＥＣＵ１１０は、ターゲットＥＣＵから受け取った識別情報と、キャンペーン情報に含まれる更新前のソフトウェアの識別情報とが、互いに一致するか否かを確認する（構成の確認）。ここでの構成の確認が成功すること（すなわち、ソフトウェアの識別情報が一致すること）は、ロールバックが成功したことを意味する。ソフトウェアの識別情報が一致しない場合には、ＥＣＵ１１０がターゲットＥＣＵにロールバックのやり直しを要求してもよい。

ロールバックが成功した場合には、処理がＳ４７に進む。また、更新対象のアクティベートが成功し（Ｓ４２にてＹＥＳ）、かつ、更新対象と連携するいずれのマイコンもアクティベートに失敗していない場合にも（Ｓ４３にてＮＯ）、処理はＳ４７に進む。更新対象が複数のマイコン（コンピュータ）を含む場合には、更新対象ごとにＳ４１～Ｓ４６およびＳ２１～Ｓ２４の処理が実行される。そして、全ての更新対象についてアクティベートまたはロールバックが成功すると、車両１００（ＥＣＵ１１０）が、Ｓ４７において、モバイル端末３００に対して終了通知を行う。そして、Ｓ４７の処理が実行されると、車両１００によるＳ３１～Ｓ４７の一連の処理が終了する。

モバイル端末３００は、Ｓ２５において、車両１００からの上記終了通知（Ｓ４７）を受信したか否かを判断する。モバイル端末３００が上記終了通知を受信していない場合には（Ｓ２５にてＮＯ）、処理がＳ２１に戻る。そして、モバイル端末３００が上記終了通知を受信すると（Ｓ２５にてＹＥＳ）、モバイル端末３００によるＳ１１～Ｓ２５の一連の処理が終了する。

以上説明したように、この実施の形態に係るソフトウェア配信システムは、モバイル端末３００と、車両１００と、ＯＴＡセンタ５００（サーバ）とを備える。また、モバイル端末３００が、プロセッサ３１０と、メモリ３２０（記憶部）とを備える。そして、プロセッサ３１０は、車両１００に搭載されるシングルバンクタイプのコンピュータの更新前のソフトウェアを車両１００から受信すること（図３のＳ１５）と、受信した更新前のソフトウェアをメモリ３２０に記憶（図３のＳ１５）させた後に、ＯＴＡセンタ５００から取得した更新用ソフトウェアを車両１００へ送信すること（図３のＳ１７）とを実行可能に構成される。

上記構成を有するモバイル端末３００によれば、車両１００が、シングルバンクタイプのコンピュータ（例えば、図６に示したシングルバンクマイコンＭＣ１）のソフトウェア更新（例えば、アクティベート）に失敗した場合に、モバイル端末３００のメモリ３２０に保存された更新前のソフトウェアを用いてロールバックを行うことが可能になる。これにより、車両１００に搭載されたデュアルバンクタイプのコンピュータだけでなく、シングルバンクタイプのコンピュータについても、ＯＴＡ技術による好適なソフトウェア更新が可能になる。

また、モバイル端末３００のプロセッサ３１０は、更新前のソフトウェアのバージョン情報を取得すること（図３のＳ１６）と、シングルバンクタイプのコンピュータのソフトウェア更新において、更新前のソフトウェアを保存するための空き容量をメモリ３２０（記憶部）が有するか否かを判断すること（図３のＳ１４）とを実行可能に構成される。そして、プロセッサ３１０は、更新前のソフトウェアを保存するための空き容量をメモリ３２０が有すると判断した場合には（図３のＳ１４にてＹＥＳ）、更新前のソフトウェアを車両１００から受信し（図３のＳ１５）、その更新前のソフトウェアをメモリ３２０に記憶（図３のＳ１５）させた後に、ＯＴＡセンタ５００から取得した更新用ソフトウェアを車両１００へ送信する（図３のＳ１７）。また、プロセッサ３１０は、更新前のソフトウェアを保存するための空き容量をメモリ３２０が有しないと判断した場合には（図３のＳ１４にてＮＯ）、更新前のソフトウェアのバージョン情報を取得し（図３のＳ１６）、そのバージョン情報をメモリ３２０に記憶（図３のＳ１６）させた後に、ＯＴＡセンタ５００から取得した更新用ソフトウェアを車両１００へ送信する（図３のＳ１７）。

上記構成を有するモバイル端末３００によれば、メモリ３２０の空き容量に応じて、ロールバックのためのデータ（詳しくは、更新前のソフトウェアまたはそのバージョン情報）を適切に保存することができる。メモリ３２０の空き容量が十分大きい場合には、更新前のソフトウェア自体が予めメモリ３２０に保存されることで、早期にロールバックを実行することが可能になる。

この実施の形態に係る車両１００は、ソフトウェア更新のシーケンスを管理するＥＣＵ１１０（制御装置）を備える。ＥＣＵ１１０は、モバイル端末３００から受け取った更新用ソフトウェアを用いて、シングルバンクタイプのコンピュータのソフトウェア更新を実行し（図３のＳ３６および図４のＳ４１）、当該ソフトウェア更新に失敗した場合には、モバイル端末３００から更新前のソフトウェアを受け取り、更新前のソフトウェアを用いてロールバックを実行するように構成される（図４のＳ４４～Ｓ４６）。こうした構成を有する車両１００によれば、車両側でソフトウェア更新を管理しやすくなる。

上記図３および図４に示した処理は適宜変更可能である。例えば、上記実施の形態では、Ｓ１３（図３），Ｓ４４（図４）で、更新対象がシングルバンクマイコンであるか否かを判断している。しかし、車両によっては、ロールバックのための記憶部を有するシングルバンクマイコンを内蔵するＥＣＵが搭載されることがある。こうした車両にソフトウェアを配信するシステムでは、更新対象が、ロールバックのための記憶部を有しないシングルバンクマイコンであるか否かを、Ｓ１３（図３），Ｓ４４（図４）で判断するようにしてもよい。すなわち、更新対象がシングルバンクマイコンであっても、更新対象がロールバックのための記憶部が有する場合には、Ｓ１３（図３），Ｓ４４（図４）の各々でＮＯと判断されるようにしてもよい。ロールバックのための記憶部を有するシングルバンクマイコンの例としては、バンク内にロールバックのための記憶部が設けられたシングルバンクマイコン、ロールバックのための記憶部（不揮発性メモリ）が外付けで設けられたシングルバンクマイコンが挙げられる。こうしたシングルバンクマイコンは、デュアルバンクマイコンに準ずる態様でロールバックを行うことができる。

図８は、図３に示した処理の第１変形例を示すフローチャートである。この変形例では、図１に示したプロセッサ３１０が、本開示に係る「受信部」、「送信部」、「更新部」、および「報知部」の一例として機能し、図１に示したメモリ３２０が、本開示に係る「記憶部」の一例として機能する。

図１，図２とともに図８を参照して、この変形例では、Ｓ３３でＮＯと判断された場合には処理が進まず、Ｓ３３でＮＯと判断されている間は、Ｓ３３の判断が繰り返される。また、Ｓ１６（図３）の代わりにＳ１６Ａが採用されている。更新対象の旧ソフトウェア（本体）を保存するための空き容量をメモリ３２０が有しない場合には（Ｓ１４にてＮＯ）、モバイル端末３００が、Ｓ１６Ａにおいて所定の報知を行う。具体的には、モバイル端末３００は、例えば画面Ｓｃ１を表示する。画面Ｓｃ１は、メモリ３２０の空き容量を増やすことをユーザに促すメッセージを表示する。ユーザは、モバイル端末３００を操作して、モバイル端末３００で起動している不要なアプリケーションを停止したり、メモリ３２０に記憶されている不要なデータを削除したりすることで、メモリ３２０の空き容量を増やすことができる。旧ソフトウェア（本体）を保存するためのメモリ３２０の空き容量が不足している間は（Ｓ１４にてＮＯ）、Ｓ１４およびＳ１６Ａが繰り返され、モバイル端末３００が画面Ｓｃ１（Ｓ１６Ａ）を表示し続ける。そして、ユーザが、画面Ｓｃ１による要求に応じて、メモリ３２０の空き容量が十分になるまで空き容量を増やすと（Ｓ１４にてＹＥＳ）、モバイル端末３００は、Ｓ１５において、更新対象の旧ソフトウェア（本体）を車両１００に要求する（第１要求）。これにより、Ｓ３３においてＹＥＳと判断され、車両１００（ＥＣＵ１１０）が、Ｓ３４において、更新対象の旧ソフトウェア（本体）をモバイル端末３００へ送信する。

上述した第１変形例では、モバイル端末３００のプロセッサ３１０が、シングルバンクタイプのコンピュータのソフトウェア更新において、更新前のソフトウェアを保存するための空き容量がメモリ３２０（記憶部）に確保されるまで（Ｓ１４にてＮＯ）、モバイル端末３００は、Ｓ１４，Ｓ１６Ａの処理を繰り返す。これにより、車両１００側では、Ｓ３３が繰り返される。このため、当該ソフトウェア更新は保留される。そして、更新前のソフトウェアを保存するための空き容量がメモリ３２０に確保された後（Ｓ１４にてＹＥＳ）、モバイル端末３００は、第１要求（Ｓ１５）により、シングルバンクタイプのコンピュータのソフトウェア更新を許可する。これにより、車両１００側の処理がＳ３４に進み、シングルバンクタイプのコンピュータのソフトウェア更新が実行される。上記のような処理により、ロールバックできない状況でソフトウェア更新が進行することが抑制される。また、プロセッサ３１０は、シングルバンクタイプのコンピュータのソフトウェア更新において、更新前のソフトウェアを保存するためのメモリ３２０（記憶部）の空き容量が不足している場合に（Ｓ１４にてＮＯ）、所定の報知（Ｓ１６Ａ）を行うように構成される。こうした報知処理により、ユーザが状況を把握しやすくなる。

なお、上記の第１変形例では、図４のＳ２２において常にＹＥＳと判断されるため、図４のＳ２２およびＳ２３を省いて、Ｓ２１においてＹＥＳと判断された場合に、処理がＳ２４に進むようにしてもよい。

図９は、図３に示した処理の第２変形例を示すフローチャートである。この変形例では、図１に示したプロセッサ３１０が、本開示に係る「送信部」および「取得部」の一例として機能し、図１に示したメモリ３２０が、本開示に係る「記憶部」の一例として機能する。

図１，図２とともに図９を参照して、この変形例では、Ｓ１４，Ｓ１５，Ｓ３３，Ｓ３４（図３）が無い。Ｓ１３においてＹＥＳと判断されると、モバイル端末３００は、Ｓ１６において、更新対象の旧ソフトウェアのバージョン情報のみをメモリ３２０に保存する。モバイル端末３００は、車両１００から、更新対象の旧ソフトウェアのバージョン情報を取得してもよい。あるいは、モバイル端末３００は、キャンペーン情報（Ｓ１２）から更新対象の旧ソフトウェアのバージョン情報を抽出してもよい。上記Ｓ１６の処理により、更新対象の旧ソフトウェアのバージョン情報がメモリ３２０に保存されると、処理はＳ１７に進む。

上述した第２変形例に係るソフトウェア配信システムでは、モバイル端末３００が、プロセッサ３１０と、メモリ３２０（記憶部）とを備える。そして、プロセッサ３１０が、車両１００に搭載されるシングルバンクタイプのコンピュータの更新前のソフトウェアのバージョン情報を取得すること（Ｓ１６）と、そのバージョン情報をメモリ３２０に記憶（Ｓ１６）させた後に、ＯＴＡセンタ５００（サーバ）から取得した更新用ソフトウェアを車両１００へ送信すること（Ｓ１７）とを実行可能に構成される。

上記構成を有するモバイル端末３００によれば、車両１００がシングルバンクタイプのコンピュータのソフトウェア更新に失敗した場合に、モバイル端末３００は、予めメモリ３２０に保存された更新前のソフトウェアのバージョン情報に基づいて、ＯＴＡセンタ５００から更新前のソフトウェアを取得することが可能になる。そして、車両１００は、モバイル端末３００から更新前のソフトウェアを受信し、その更新前のソフトウェアを用いてシングルバンクタイプのコンピュータのロールバックを行うことが可能になる。なお、上記の第２変形例では、図４のＳ２２において常にＮＯと判断されるため、図４のＳ２２を省いて、Ｓ２１においてＹＥＳと判断された場合に、処理がＳ２３に進むようにしてもよい。

モバイル端末３００の受信部、送信部、取得部、判断部、更新部、および報知部は、ソフトウェアではなく、専用のハードウェア（電子回路）によって具現化されてもよい。また、上記実施の形態では、ＯＴＡセンタ５００としてオンプレミスサーバが採用されている（図１参照）。しかしこれに限られず、クラウドコンピューティングによってクラウド上にＯＴＡセンタ５００の機能（例えば、ソフトウェア配信に係る機能）が実装されてもよい。すなわち、ＯＴＡセンタ５００はクラウドサーバであってもよい。

車両は、ＯＴＡアクセス機能を有するＯＴＡマスタを備えてもよい。車両は、ＯＴＡセンタとの無線通信を行うＴＣＵ（Telematics Control Unit）および／またはＤＣＭ（Data Communication Module）を含んでもよい。車両が自動運転可能に構成されることは必須ではない。車両は、ＢＥＶ以外のｘＥＶ（電動車）であってもよい。車両は、内燃機関（例えば、ガソリンエンジン、バイオ燃料エンジン、または水素エンジン）を備えてもよい。車両は、４輪の乗用車に限られず、バスまたはトラックであってもよいし、３輪のｘＥＶであってもよい。車両は飛行機能を備えてもよい。車両は、ＭａａＳ（Mobility as a Service）で利用される車両であってもよい。車両は、ユーザの使用目的に応じてカスタマイズされる多目的車両であってもよい。車両は、移動店舗車両、ロボタクシー、無人搬送車（ＡＧＶ）、または農業機械であってもよい。車両は、無人または１人乗りの小型ＢＥＶ（例えば、ラストワンマイル用のＢＥＶ、電動車椅子、または電動スケータ）であってもよい。

上記の各種変形例は任意に組み合わせて実施されてもよい。

今回開示された実施の形態は、すべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した実施の形態の説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

１００ 車両、１１０，１２１，１２２ ＥＣＵ、１１１，３１０，５１０ プロセッサ、１１２，３２０，５２０ メモリ、１３０ 運転装置、１４０ ＡＤＳ、１５０ 起動スイッチ、１７０ ＨＭＩ、１９０ 通信装置、３００ モバイル端末、３３０ 通信モジュール、５００ ＯＴＡセンタ、５３０ 通信モジュール、ＭＣ１ シングルバンクマイコン、ＭＣ２ デュアルバンクマイコン。

Claims (8)

1. 記憶部と、
   車両に搭載されるシングルバンクタイプのコンピュータの更新前のソフトウェアを前記車両から受信する受信部と、
   受信した前記更新前のソフトウェアを前記記憶部に記憶させた後に、サーバから取得した更新用ソフトウェアを前記車両へ送信する送信部と、
   を備える、モバイル端末。
2. 当該モバイル端末は、
   前記更新前のソフトウェアのバージョン情報を取得する取得部と、
   前記シングルバンクタイプのコンピュータのソフトウェア更新において、前記更新前のソフトウェアを保存するための空き容量を前記記憶部が有するか否かを判断する判断部と、
   をさらに備え、
   前記更新前のソフトウェアを保存するための空き容量を前記記憶部が有すると前記判断部が判断した場合には、前記受信部が前記更新前のソフトウェアを前記車両から受信し、前記送信部が、前記更新前のソフトウェアを前記記憶部に記憶させた後に、前記サーバから取得した前記更新用ソフトウェアを前記車両へ送信し、
   前記更新前のソフトウェアを保存するための空き容量を前記記憶部が有しないと前記判断部が判断した場合には、前記取得部が前記更新前のソフトウェアの前記バージョン情報を取得し、前記送信部が、前記バージョン情報を前記記憶部に記憶させた後に、前記サーバから取得した前記更新用ソフトウェアを前記車両へ送信する、請求項１に記載のモバイル端末。
3. 前記シングルバンクタイプのコンピュータのソフトウェア更新において、前記更新前のソフトウェアを保存するための空き容量が前記記憶部に確保されるまで当該ソフトウェア更新を保留し、前記更新前のソフトウェアを保存するための空き容量が前記記憶部に確保された後、前記シングルバンクタイプのコンピュータのソフトウェア更新を許可する更新部をさらに備える、請求項１に記載のモバイル端末。
4. 前記シングルバンクタイプのコンピュータのソフトウェア更新において、前記更新前のソフトウェアを保存するための前記記憶部の空き容量が不足している場合に所定の報知を行う報知部をさらに備える、請求項３に記載のモバイル端末。
5. 前記受信部は、無線通信によって前記サーバから前記更新用ソフトウェアを取得するように構成され、
   前記送信部は、無線通信によって前記車両へ送信するように構成される、請求項１に記載のモバイル端末。
6. 記憶部と、
   車両に搭載されるシングルバンクタイプのコンピュータの更新前のソフトウェアのバージョン情報を取得する取得部と、
   前記更新前のソフトウェアの前記バージョン情報を前記記憶部に記憶させた後に、サーバから取得した更新用ソフトウェアを前記車両へ送信する送信部と、
   を備える、モバイル端末。
7. 請求項１～６のいずれか１項に記載のモバイル端末と、
   前記車両と、
   前記サーバと、
   を備え、
   前記車両は、ソフトウェア更新のシーケンスを管理する制御装置を備え、
   前記制御装置は、前記モバイル端末から受け取った前記更新用ソフトウェアを用いて、前記シングルバンクタイプのコンピュータのソフトウェア更新を実行し、当該ソフトウェア更新に失敗した場合には、前記モバイル端末から前記更新前のソフトウェアを受け取り、前記更新前のソフトウェアを用いてロールバックを実行する、ソフトウェア配信システム。
8. 前記シングルバンクタイプのコンピュータは、前記車両の走行制御を行うコンピュータである、請求項７に記載のソフトウェア配信システム。

Images