JP6693853B2 - ソフトウエア更新制御装置 - Google Patents

Description

本発明は、例えば車両に搭載される車載プログラムなどの、車両の電子制御装置用ソフトウエアの更新を制御するソフトウエア更新制御装置の技術分野に関する。

この種の装置として、車両に搭載され、電子制御装置毎に設定されている更新条件が成立する場合に、条件を満たす電子制御装置のプログラムの更新を行うように制御する装置が提案されている。この装置では、現在の車両負荷状態が高負荷の（即ち、更新条件が成立しない）場合、低負荷の（即ち、更新条件が成立する）状態に変更するための環境整備制御を実行できるとされている（特許文献１参照）。

他方、この種の装置に関連する技術として、ＥＣＵ（Engine Control Unit）毎にプログラム更新に必要な時間を演算する装置（特許文献２参照）や、プログラムの更新が正常に終了しない場合に、利用不可となる車両機能に関するリスク情報を用いて、ユーザに更新の実行可否を判断させる装置（特許文献３参照）が提案されている。

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

しかしながら、上述の装置（特許文献１等）によれば、更新される機能に拘わらず、装置毎の条件に基づいて、同一のフローで更新可否判断を行う。このため、例えばおもてなし機能等の簡単な或いは重要度の低い機能の更新であっても、車両を低負荷状態に変更するための環境整備制御によって、例えばエンジン停止やエアコン停止等となってしまうなど、車両における基本的な或いは重要な機能を制限しかねないという技術的問題点がある。

本発明は、上述した問題点に鑑みなされたものであり、簡単な或いは重要度の低い機能の更新の場合に、車両の機能に与える制限を軽減或いは抑制することを可能ならしめ、更新の機会を適切に増やすことを可能ならしめる、車両の電子制御装置用ソフトウエアの更新を制御するソフトウエア更新制御装置を提供することを課題とする。

本発明のソフトウエア更新制御装置は上記課題を解決するために、車両の電子制御装置用ソフトウエアの更新を制御するソフトウエア更新制御装置であって、前記電子制御装置用ソフトウエアの更新すべき内容を示す更新情報を取得する取得部と、該取得された更新情報に係る、更新の難易度をレベルで示す更新ランクを、前記内容、前記電子制御装置の状態及び前記車両の状態のうち少なくとも一つに基づいて判定する更新ランク判定部と、前記判定された更新ランクを更新する更新ランク更新部と、前記更新情報による更新の実施の容易度をレベルで示す実施可能ランクを判定する実施可能ランク判定部と、前記更新された更新ランクと前記判定された実施可能ランクとを比較して、前記電子制御装置用ソフトウエアの更新を実施するか否かを判定する更新可否判定部とを備え、前記更新ランク更新部は、前記更新ランクが高いために前記更新可否判定部により更新を実施しないと判定された場合であって前記更新ランクを下げられる場合に、前記更新ランクを下げる旨を当該車両のユーザに提案すると共に該ユーザによる該提案の承認を受けて前記更新ランクを更新する。

本発明に係るソフトウエア更新制御装置によれば、車両の走行中若しくは停車中又は駐車中に、ＣＰＵ等を備えてなる取得部によって、電子制御装置に対して車両外部又は内部から与えられる、電子制御装置用ソフトウエアの更新すべき内容を示す更新情報が取得される。電子制御装置用ソフトウエアは通常、一台の車両について複数或いは多数存在しており、このような更新情報は、機能毎に構築される各電子制御装置用ソフトウエアについて、一つずつ或いは纏めて取得される。

続いて、ＣＰＵ等を備えてなる更新ランク判定部によって、該取得された更新情報に係る、更新の難易度（若しくは容易度）をレベルで示す更新ランクが、更新情報の内容、電子制御装置の状態及び車両の状態のうち少なくとも一つに基づいて判定される。

続いて、ＣＰＵ等を備えてなる更新ランク更新部によって、前記判定された更新ランクは、例えば電子制御装置若しくは車両の状態の変化に応じて、時間経過に応じて、又は定期的に若しくは不定期に、適宜更新される。

このような更新動作と相前後して又は並行して、ＣＰＵ等を備えてなる実施可能ランク判定部によって、更新情報による更新の実施の容易度（若しくは実施可能な難易度）をレベルで示す実施可能ランクが、実際に更新を実施するのに先立って判定される。

すると、ＣＰＵ等を備えてなる更新可否判定部によって、これらの更新された更新ランクと判定された実施可能ランクとが比較され、各電子制御装置用ソフトウエアの更新を実際に実施するか否かが判定される。

この判定結果を受けて、実際に実施すべきと判定された電子制御装置用ソフトウエアの更新が、ソフトウエアの書き換え装置等により実施される。即ち、更新情報による更新は、無条件で行われる訳ではなく、機会毎に、状況に応じて適宜に或いは選択的に実施される。例えば、高負荷状態で、更新の実施可能ランクが低い場合に、負荷状態を小さくして車両の基本的な機能性を下げてしまうような実施を適宜に回避できる。言い換えれば、ユーザの利便性まで考慮しての実践的な意味での安全且つ確実に更新可能な機能から、更新可能されることになる。

以上のように、本発明のソフトウエア更新制御装置によれば、更新する機能毎に更新ランクを付与して、実施可能ランク以下の機能を実際に更新することで、例えばおもてなし機能等の重要度が相対的に低い機能を更新するために、走る・曲がる・停止する等の車両の基本機能（即ち、極めて重要度の高い機能）へ制限を加えることや、エンジン停止・エアコン停止等のやはり重要度が相対的に高い機能へ制限を加えることを適宜に回避しつつ、更新の機会を適切に増やすことが可能となる。ソフトウエア更新の頻度が上がっても適宜に対応可能となり、ユーザの利便性を損なう事態の発生を適切に未然防止し得る。更に、実施形態では特に、更新ランクが高い場合には、ユーザに該更新ランクを下げる機会を与える（即ち、ユーザに提案し、選択的に承認を得る）ので、該更新ランクを適宜に下げることで、より安全確実に更新を達成することも可能である。

本発明のこのような作用及び他の利得は、これ以降に説明する実施形態により明らかにされる。

実施形態に係るソフトウエア更新制御装置を含む、車両に搭載される電子制御系の全体構成を示すブロック図である。 図１に示した更新ランク監視ＥＣＵの構成を示すブロック図である。 実施形態に係る処理全体の流れを示すフローチャートである。 図３に示した各種処理のうち、更新ランクを判定する処理（ステップＳ１０）の詳細な流れを示すフローチャートである。 実施形態における走行中の判定例を示す表である。 実施形態における直ぐに更新する場合の更新ランクの判定例を示す表である。 実施形態における直ぐに更新しない場合の更新ランクの判定例を示す表である。 図３に示した各種処理のうち、更新は実施可能であるか否かを判定する処理（ステップＳ２０）の詳細な流れを示すフローチャートである。 実施形態における、ＥＣＵへの書き込みの中断及び再開を示す概念図（その１）である。 実施形態における、ＥＣＵへの書き込みの中断及び再開を示す概念図（その２）である。 実施形態における、ＥＣＵへの書き込みの中断及び再開を示す概念図（その３）である。 実施形態における実施可能な更新ランク（即ち「実施可能ランク」）の判定例を示す表である。

先ず図１を参照しながら、本発明のソフトウエア更新制御装置の実施形態の構成について説明する。

図１において、車両に搭載される電子制御系１００は、更新ランク監視ＥＣＵ（Engine Control Unit）１、車両状態管理ＥＣＵ２、車両用途管理ＥＣＵ３、周辺環境管理ＥＣＵ４、ソフトウエア選択用ＵＩ（ユーザインターフェース用ＥＣＵを含むユーザインターフェース）５、車外通信ＥＣＵ６、表示ＥＣＵ７、並びに、当該電子制御系１００内で用いられる各種プログラムを夫々書き換えるための書き換えＥＣＵ８〜１１を備える。電子制御系１００に含まれるこれらのＥＣＵは、１台の車両に搭載されており、有線或いは無線の車内ネットワーク５０で相互に接続されている。車内ネットワーク５０は、一つの車内ネットワーク網で構成されてもよいし、複数の車内ネットワーク網であるＥＣＵとあるＥＣＵが間接的に接続されていてもよい。更に、電子制御系１００は、少なくとも部分的に無線電波或いは電気信号を用いた通信網１５０により、遠隔地にあるサーバ２００に接続され、サーバ２００や図示しない他の車両や設備と車外通信可能に構成されている。通信網１５０は、その一部または全部が、無線網であってもよいし或いは有線網であってもよい。

更新ランク監視ＥＣＵ１は、更新ランクを監視するＥＣＵであり、その詳細構成については、図２を参照して後述する。

車両状態管理ＥＣＵ２は、車両状態を把握するＥＣＵ、より具体的には車両状態に係る情報を車内外から収集したり、管理したりするＥＣＵである。車両用途管理ＥＣＵ３は、車両用途を把握するＥＣＵ、より具体的には車両用途に係る情報を車内外から収集したり、管理したりするＥＣＵである。周辺環境管理ＥＣＵ４は、周辺環境を把握するＥＣＵ、より具体的には周辺環境に係る情報を車内外から収集したり、管理したりするＥＣＵである。但し、状況によっては、車両状態管理ＥＣＵ２、車両用途管理ＥＣＵ３及び周辺環境管理ＥＣＵ４については、専ら情報収集し、収集された情報の管理については、サーバ２００で一元的に管理するように構成してもよい。その場合、サーバ２００は、更新する日時や内容を管理する。

ソフトウエア選択用ＵＩ５は、運転手或いはユーザ等により、後に詳述する如く各種ソフトウエアを選択するための各種情報が入力される、ＧＵＩ（Graphical User Interfae）等のＵＩである。ソフトウエア選択用ＵＩ５は、車載されたカーナビの入力装置（即ち、タッチパネル、操作ボタン等）を含んで構成されてもよいし、車内外に置かれ、運転手或いはユーザ等により操作されるスマートフォンやＰＣ等の入力装置を含んで構成されてもよい。

車外通信ＥＣＵ６は、電子制御系１００とサーバ装置２００とを通信網１５０を介して相互接続し、或いは更に、電子制御系１００と通信網１５０に収容されている他の車両や設備等とを相互接続し、双方向の車外通信或いはネットワーク通信を可能ならしめるＥＣＵである。

表示ＥＣＵ７は、車両内で各種表示を行い、各種画像情報を、運転手或いはユーザ等に対して提供するためのＥＣＵである。表示ＥＣＵ７は、車載されたカーナビの表示装置を含んで構成されてもよいし、車内外に置かれ、運転手或いはユーザ等により操作されるスマートフォンやＰＣ等の表示装置を含んで構成されてもよい。表示ＥＣＵ７は、ＧＵＩ用のＥＣＵの機能を兼ね、ソフトウエア選択用ＵＩと一体的に構成されてもよい。

書き換えＥＣＵ８〜１１は夫々、車外通信ＥＣＵ６から或いは他のＥＣＵからダウンロードされ、当該電子制御系１００内で用いられる、電子制御用各種ソフトウエア或いは各種プログラムを書き換えるためのＥＣＵである。これらのＥＣＵ８〜１１は、車外通信ＥＣＵ６から通信網１５０に更にはサーバ２００等に直接繋がっていてもよいし、他のＥＣＵを介して車外通信ＥＣＵ６等に繋がっていてもよい。

図１では、複数のＥＣＵは、別々のＥＣＵとして構築或いは図示されているが、これらは、状況に応じて全て同一の或いは部分的に同一のＥＣＵから構成されていてもよい。加えて、上述の如く複数或いは多数設けられた各種ＥＣＵの構え（特性）を管理するＥＣＵを更に設けて、車内ネットワーク５０に接続してもよいし、或いは、このような各種ＥＣＵの構え（特性）の管理を、サーバ２００で行うように構成してもよい。

図２に示すように、更新ランク監視ＥＣＵ１は、取得部１０２、更新ランク判定部１０３、更新ランク更新部１０４、実施可能ランク判定部１０５及び更新可否判定部１０６を備えて構成されている。

図２において、取得部１０２は、車内ネットワーク５０を介して更新情報Ｉ１を取得する。更新ランク判定部１０３は、車内ネットワーク５０を介して得られる車両状態、車両用途、周辺環境を示す情報Ｉ２に基づいて、このように取得された更新情報に対して、更新の難易度をレベルで示す更新ランクを判定する。ここに「更新の難易度」とは、当該車両に係る安全性、快適性、経済性、利用度等の各種観点から、各々のソフトウエアを更新する際の難しさの度合いを意味する。例えば、更新を失敗した場合に車両が動かなくなるなどは、更新が難しい（更新の難易度が高い）に相当し、更新が失敗した場合でも然したる不都合は生じずユーザも気付かない程度の状態は、更新が容易（更新の難易度が低い）に相当する。このような更新ランクとしては、複数の更新に対して、それらの難易度が相互に同一であるため、同レベル（即ち同一の更新ランク）が与えられる場合も排除されない。

更新ランク更新部１０４は、このように判定された更新ランクを更新する。他方で、実施可能ランク判定部１０５は、車内ネットワーク５０を介して得られる車両状態、車両用途、周辺環境を示す情報Ｉ２に基づいて、更新の実施の容易度をレベルで示す実施可能ランクを判定する。ここに「更新の実施の容易度」とは、当該車両が置かれた各種状況下或いは各種環境下で或いは特定のユーザに対して、各々の更新に伴う不都合や不利不便を抑制する観点での、各々のソフトウエアの更新の実施のし易さを意味する。例えば、更新を実施するため、或いは更新が失敗した場合に車両が長時間使えなくなるなどは、更新の実施が容易でない（更新の実施の容易度が低い）に相当し、ユーザが車を使わないうちに更新を実施できるや、或いは更新に失敗してもすぐに車両を復帰できるなどは、更新の実施が容易である（更新の実施の容易度が高い）に相当する。なお、このような実施可能ランクとしては、複数の更新に対して、それらの実施の容易度が相互に同一であるため、同レベル（即ち同一の実施可能ランク）が与えられる場合も排除されない。

更新可否判定部１０６は、更新ランク更新部１０４により更新された更新ランクと、実施可能ランク判定部１０５により判定された実施可能ランクとを相互比較することで、実際に更新を実施するか否かを判定し、その結果を更新制御情報Ｃ１として車内ネットワーク５０を介して、書き換えＥＣＵ８〜１１（図１参照）等へ出力するように構成されている。

次に図３から図１２を参照しながら、以上のように構成された本実施形態で実行される各種処理を、本実施形態の更なる詳細構成と共に説明する。ここに図３は、実施形態に係る処理全体の流れを示し、図４は、そのうち更新ランクの判定処理（ステップＳ１０）の流れを示し、図８は、そのうち更新が実施可能であるか否かの判定処理（ステップＳ２０）の流れを示す。

図３において先ず、本実施形態に係るソフトウエア更新制御装置における、更新ランク監視ＥＣＵ１に対して、車内ネットワーク５０経由で、更新ランク判定を実行するべき旨の要求が、トリガされる（ステップＳ１）。ここでのトリガは、例えば、ソフトウエアの更新予約、更新するソフトウエアを選択した段階で、サーバ２００或いは他のＥＣＵ（即ち、ＥＣＵ２〜１１）からのトリガであってもよい。例えば、ソフトウエア更新予約時間の所定分前に、サーバ２００からのトリガで更新ランク判定の実行が要求されるのでもよい。メーカが確実に書き換えを実施したい場合には、サーバ２００からのトリガで、更新ランク判定の実行が要求されてもよい。複数の更新予約の候補が溜まった段階で、サーバ２００からのトリガで、更新ランク判定の実行が要求されてもよい。或いは、定期的にサーバ２００からのトリガで、更新判定が要求されてもよい。このように取得部１０２で、トリガとなる更新情報が取得される。

このような要求に応じて、更新ランク監視ＥＣＵ１は、図４に詳細処理を示した如く、更新ランクを判定する（ステップＳ１０）。即ち図２に示した更新ランク判定部１０３は、取得された更新情報Ｉ１並びに車両状態情報、車両用途情報及び周辺環境情報等を含む情報Ｉ２等に基づいて、更新ランクを、例えば図４のフローチャート及び図５〜図７の表を参照して以下に説明する如くに判定する。更に、図２に示した更新ランク更新部１０４は、更新ランク判定部１０３により判定或いは推測された更新ランクを時間の経過、状況の変化等に応じて或いは定期不定期に更新し、同じく図２に示した更新可否判定部１０６は、更新ランク更新部１０４により更新された更新ランクと実施可能ランク判定部１０５による判定結果とに基づいて、各機能の更新が実際に実行可能であるか否かを判定し、その結果として更新可否を示す情報或いは更新する旨のコマンドである更新制御情報Ｃ１を出力する。

より詳細には図４に示すように、先ず、更新ランク監視ＥＣＵ１では、サーバ２００により更新が直ぐに行われるか否かを判定する（ステップＳ１１）。更新が何時行われるかについては、例えば、ユーザ側からの要求に応じた更新（即ち“ユーザニーズ”の更新）であれば、更新するアプリを選択時に日時が指定される。また例えば、メーカ側からの要求に応じた更新（即ち“メーカニーズ”の更新）であれば、所定日以降最短で更新が実施されるか、或いは、ユーザに通知を行い、ユーザの更新承諾時で日時が選択される。これらの場合において、例えば、現在時刻から“２時間以内”に更新が行われる場合であれば、“直ぐに更新を行う”旨として判定される（ステップＳ１１：Ｙｅｓ）。或いは、２時間以内に更新が行われない場合であれば、“直ぐに更新を行わない”旨として判定される（ステップＳ１１：Ｎｏ）。この“２時間以内”として例示される閾値は、実状に応じてメーカ側或いはユーザ側で任意に設定されればよい。

判定の結果、直ぐに更新を行う場合（ステップＳ１１：Ｙｅｓ）、更新ランク判定部１０２（図２参照）は、更新する機能のリスクランクを判定する（ステップＳ１２ａ）。ここに「リスクランク」とは、更新する機能の危険度を順位付或いはランク付したものであり、更新しない場合における危険度が高い程、高いランクが付けられる。

ここで更新する機能のリスクランクを具体的に例示すれば、リスクランクが高い順から機能失陥時に事故につながる可能性がある機能が“リスクランク４”とされ、機能失陥時に車両が走行負荷になる可能性がある機能が“リスクランク３”とされ、機能失陥時に多数のユーザが不満を感じる機能が“リスクランク２”とされ、機能失陥時に少数のユーザが不満を感じる機能が“リスクランク１”とされ、機能失陥時でも影響を殆ど又は実践上全く無視できる機能が“リスクランク０”とされる。ここでは一例として５段階にリスクランクを層別したが、実況に応じてメーカ側で任意に設定されれば良い。

続いて、更新ランク監視ＥＣＵ１は、更新に掛かる時間を算出する（ステップＳ１３ａ）。ここでは、例えば「数分以内」、「３０分以内」、「それ以上」など、算出された更新に掛かる時間が、何段階かに層別される。或いは、更新に掛かる時間が、これらの段階の何れに属するかが算定される。ここでは一例として３段階に時間を層別したが、実況に応じてメーカ側で任意に設定されれば良い。

続いて、更新ランク監視ＥＣＵ１は、車両状態を判定する（ステップＳ１４）。具体的には例えば、車両状態として、走行状態が予め設定された複数範疇の内の何れの状態にあるかを判定したり、又は、これに加えて若しくは代えて異常の有無を判定する。

該“走行状態”は、例えば、図５の表に示した複数の範疇に分類される。ここに図５の表は、縦軸に各種状態（即ち、電源状態、乗員、シフトポジション、車速及び充電）を取り、横軸に各種走行状態（即ち、充電中、駐車、停車１、停車２、アイドリング、走行中）を取ることで、縦軸の状態に応じて走行状態を判定している。車両状態は、図５の表のマトリクスのうちの、対応する一マスに含まれる車両状態であるとして判定される。ここで例えば、乗員やドライバーが周辺に居る又は居ないことを確認する方法としては、車両のキーが近くに存在しないことを確認すること、或いは、車両に乗員所有の特定のスマートフォンを認識させた上でスマートフォン位置を確認することで実施する。他方、車両が“異常”とは、バッテリ電圧が低下していること、ダイアグが発生していること、バスの負荷率が所定閾値より高いことなどを該当させる。ステップＳ１４の判定処理により、更新実施時の車両状態についての判定或いは推測結果が得られる。

再び図４において、続いて、更新するＥＣＵの使用状況を判定する（ステップＳ１５）。ここでは例えば、車両内における電源状態を参照し、各ＥＣＵに電源が入っていたら、使用との判定をする。或いは、車内ネットワーク５０に係るバス負荷率を参照し、バス負荷率が所定閾値より高ければ、使用との判定をする。或いは、アクチュエータを有するＥＣＵであれば、アクチュエータが動いているときのみ使用との判定をする。具体的には例えば、ワイパ駆動用のＥＣＵであれば、ワイパが動いているときのみ使用と判定或いは推測する。ステップＳ１５の判定処理により、更新対象となるＥＣＵの使用状況についての判定或いは推測結果が得られる。

他方、図４において、ステップＳ１１の判定の結果として直ぐに更新を行わないのであれば（ステップＳ１１：Ｎｏ）、更新ランク判定部１０２（図２参照）は、更新する機能のリスクランクを判定し（ステップＳ１２ｂ）、更新に掛かる時間を算出する（ステップＳ１３ｂ）。これらの処理は夫々、前述のステップＳ１２ａ及び１３ａと同様に行われるが、直ぐに更新を行う場合でないため、判定結果及び算出結果は、ステップＳ１２ａ及び１３ａのそれらとは相異なり得る。

更に、更新ランク監視ＥＣＵ１は、更新実施における車両状態を判定或いは推測する（ステップＳ１６）。ここでは、走行状態と異常の有無を確認する。“車両状態”については、前出のステップＳ１４の場合におけると同様に、走行状態と異常の有無とが確認される。

例えば、ここでの車両の走行状態については、ユーザ或いは運転手に、車載カーナビ又はそれに代わるスマートフォン若しくはＰＣを介して、車両使用スケジュールを入力してもらい、車両状態管理ＥＣＵ２、車両用途管理ＥＣＵ３及び周辺環境管理ＥＣＵ４（図２参照）で管理された該車両使用スケジュール情報に基づいて、走行状態を判定したり、普段の当該車両の使用状況をモニタリングすることで、走行状態を判定或いは推測する。

より具体的には例えば、『平日通勤で当該車両を使用し、休日には当該車両を利用しないユーザ』に対しては、更新を平日に実施しようというのであれば、走行であると判定或いは推測し、更新を休日に実施しようとするのであれば、駐車であると判定或いは推測する。例えば『深夜配送で使用するユーザ』に対しては、昼間に更新を実施しようとするのであれば、駐車であると判定或いは推測し、夜間に更新を実施しようとするのであれば、走行と判定或いは推測する。

但し、前述したステップＳ１４の処理（図５の表参照）とは異なり、このステップＳ１６の判定では、「充電中」、「駐車中」、「走行中」など、大きく層別する。他方で、異常の有無については、ステップＳ１４の判定とステップＳ１６の判定とでは、同じく現状の異常から判定を行う。ステップＳ１６の判定処理により、更新実施時の車両状態についての判定或いは推測結果が得られる。

続いて、更新ランク監視ＥＣＵ１は、更新するＥＣＵの使用状況を判定或いは推測する（ステップＳ１７）。ここでは例えば、ユーザに車両使用スケジュールを入力してもらい、更新のタイミングと被っていれば、使用と判定或いは推測する。或いは、普段の使用状況をモニタリングし、更新のタイミングと被る確率から使用と判定或いは推測する。より具体的には例えば、『平日通勤で当該車両を使用し、休日には当該車両を利用しないユーザ』に対しては、更新を平日に実施しようとするのであれば、「使用」と判定或いは推測し、更新を休日に実施しようとするのであれば、「不使用」と判定或いは推測する。『深夜配送で使用するユーザ』に対しては、昼間に更新を実施しようとするのであれば、「不使用」と判定或いは推測し、夜間に更新を実施しようとするのであれば、「使用」と判定或いは推測する。

また例えば、周辺環境管理ＥＣＵ４（図２参照）等から取得される更新時における車外状況（例えば、天候、気温等）と、車両状態管理ＥＣＵ２（図２参照）等から取得される車両位置（例えば、駐車場、交差点近く、上り坂等）との情報から、使用中であるか否かを判定或いは推測する。具体的には例えば、上り坂で駐車されていれば、ブレーキＥＣＵは「使用」と判定或いは推測する。気温が高ければ、エアコンＥＣＵは「使用」と判定或いは推測し、雨予報であれば、ワイパＥＣＵは「使用」と判定或いは推測する。ステップＳ１７の判定処理により、更新対象となるＥＣＵの使用状況についての判定或いは推測結果が得られる。

続いて、上述したステップＳ１２ａ〜Ｓ１５の処理を経て（ステップＳ１１でＹｅｓの判定の場合）、最終的に更新ランク監視ＥＣＵ１によって、更新ランクを判定する（ステップＳ１８ａ）。又は、上述したステップＳ１２ｂ〜Ｓ１７の処理を経て（ステップＳ１１でＮｏの判定の場合）、最終的に、更新ランク監視ＥＣＵ１によって、更新ランクを判定する（ステップＳ１８ｂ）。ステップＳ１８ａで判定される結果の一具体例を図６に示し、ステップＳ１８ｂで判定される結果の一具体例を図７に示す。

図６の表において、左から第１列目のコラムには、ステップＳ１２ａで得られた『機能のリスクランク』が代入される。ここでは『機能のリスクランク』については、『０』〜『４』の５段階の一つとして判定されたものである。

左から第２列目のコラムには、ステップＳ１３ａで得られた『機能更新に掛かる時間』が代入される。ここでは『機能更新に掛かる時間』については、『数分以内』〜『３０分以上』といった複数分類の一つとして判定されたものである。

左から第３列目及び第４列目のコラムには、ステップＳ１４で得られた、左からこの順に『走行状態』及び『異常の有無』が代入される。ここでは『走行状態』については、『充電中』、『駐車』、『停車１』、…、『走行中』といった複数分類の一つとして判定されたものである。『異常の有無』については、『有』又は『無』として判定されたものである。なお、『停車１』とは、『停車』を、単一分類に括るのではなく、電源状態、停車時間、停車場所、停車状況等に応じて細分類したものである。

左から第５列目のコラムには、ステップＳ１５で得られた『ＥＣＵの使用状況』が代入される。ここでは『ＥＣＵの使用状況』については、『有』又は『無』として判定されたものである。

このように図６の表の左から第１列目〜第５列目のコラムに、上述の如き判定或いは推測結果等を夫々代入することで、左から第６列目（即ち右端）のコラムにある番号（ここでは、２０段階の序列或いはレベルを表す番号）として、『更新ランク』が、判定或いは推測されることになる（ステップＳ１８ｂ）。なお本具体例では、２０段階の更新ランクとしたが、状況によって（具体的には、左側の第１列目〜第５列目のコラムの分類数等に応じて）、任意の段階に分けることが可能である。

因みに、図６に示した具体例の場合、『機能のリスクランク』が大きい程、更新ランクが大きくなり、『機能更新に掛かる時間』は、時間が長い程、更新ランクが大きくなり、『異常の有無』は、『有』の方が『無』よりも更新ランクが大きくなり、『ＥＣＵの使用状況』は、『有』の方が『無』よりも更新ランクが大きくなるように、更新ランクの判定アルゴリズムが構築されている。なお『更新ランクが大きい』とは、更新の難易度が高く更新を実施しにくいという趣旨であり、『更新ランクが小さい』とは、更新の難易度が低く更新を実施しやすいという趣旨である。例えば、更新ランクが“１”ということは、一番更新が容易であることを表しており、いつでも更新を実施できるという意味であり、更新ランクが“２０”ということは、一番更新が難しいことを表しており、限られた条件下でのみ更新を実施できるという意味である。

図７の表において、左から第１列目のコラムには、ステップＳ１２ｂで得られた『機能のリスクランク』が代入される。左から第２列目のコラムには、ステップＳ１３ｂで得られた『機能更新に掛かる時間』が代入される。

左から第３列目及び第４列目のコラムには、ステップＳ１６で得られた左からこの順に『走行状態』及び『異常の有無』が代入される。ここでは『走行状態』については、『充電中』、『駐車』、…、『走行中』といった、相対的に（即ち図６の『走行状態』と比べて）大まかな複数分類の一つとして判定されたものであり、『異常の有無』については『有』又は『無』として判定されたものである。左から第５列目のコラムには、ステップＳ１７で得られた『ＥＣＵの使用状況』が代入される。

このように図７の表の左から第１列目〜第５列目のコラムに、上述の如き判定或いは推測結果等を夫々代入することで、左から第６列目（即ち右端）のコラムにある番号（ここでは、２０段階の序列或いはレベルを表す番号）として、『更新ランク』が、判定或いは推測されることになる（ステップＳ１８ｂ）。図７の表（即ちステップＳ１１でＮｏの場合）で得られる更新ランクと、図６の表（即ちステップＳ１１でＹｅｓの場合）で得られる更新ランクとでは、直ぐに更新を行うか否かという前提条件が相異なるのに起因して、相異なっている。

再び図３に戻り、以上詳細に説明したステップＳ１０の処理が終わると、続いて、更新ランク監視ＥＣＵ１は、図８に詳細処理を示した如く、更新は実行可能か否かの判定を実行する（ステップＳ２０）。即ち図２において、実施可能ランク判定部１０５は、取得された更新情報Ｉ１並びに車両状態情報、車両用途情報及び周辺環境情報等を含む情報Ｉ２等に基づいて、更新は可能であるかの判定を、例えば図８のフローチャート及び図９〜図１２の図表を参照して以下に説明する如くに判定する。更に、図２に示した更新可否判定部１０６は、更新ランク更新部１０４により更新された更新ランクと実施可能ランク判定部１０５による判定結果とに基づいて、各機能の更新が実際に実行可能であるか否かを判定する。

図８に示すように、先ず、更新ランク監視ＥＣＵ１では、安全上の構えを判定する（ステップＳ２１）。ここに『安全上の構え』とは、例えば、車両盗難防止等の観点から、車両からユーザへの通知ができるか否か、イモビライザが装備されているか否か、車外から遠隔で車両制御ができないか否か、更新中の電源管理ができるか否か、ダイアグのマスクや消去を自動で行えるか否か、ドアロックやウインドウクローズができるか否かに対して、項目毎にポイントを与えることで得られる定量的な指針である。

例えば、所定項目の全てについて『安全上の構え』が出来ている場合を１００％として、８０％以上構えがある場合には「安全上の構えが“十分ある”」、５０％以上構えがある場合には「安全上の構えが“ある”」、５０％未満では「安全上の構えが“ない”」と夫々判定される。加えて、本例では、複数の構えを備えた割合で判定しているが、構えの個数で判定してもよいし、項目毎に重み付けをした合計点数で判定してもよい。或いは、構えを、必須項目と好ましい項目とに層別し、両方を備えていれば「安全上の構えは“十分ある”」と判定し、必須項目を備えていれば「安全上の構えは“ある”」と判定し、必須項目を備えていなければ（好ましい項目が備えられていようがいまいが一律に）「安全上の構えは“ない”」と判定するのでもよい。ここでは一例として３段階に安全上の構えを層別したが、実況に応じてメーカ側で任意に設定されれば良い。

続いて、更新ランク監視ＥＣＵ１では、書き込み先のＥＣＵに書き込み中断機能があるか否かを確認する（ステップＳ２２）。ここで『中断機能』について、図９から図１０を参照して以下に説明を加える。

図９に概念的に示すように『中断機能』の第１例では、或るＥＣＵが書き込み終わった段階で中断でき、更新するＥＣＵが変わるタイミングで中断又は続行の判断が可能である（但し、ＥＣＵの更新途中で中断した場合には、再度最初から書き換えが必要である）。より具体的には、本第１例では、左側のＥＣＵ５０１の書き込み領域について今回書き込み完了後に中断されると、次回は、右側のＥＣＵ５０２の書き込み領域について左上（即ち最初）から書き換えを再開できる。

図１０に概念的に示すように『中断機能』の第２例では、ＥＣＵの書き込中に中断を行い、同じところから再度書き込むことができる。より具合的には、本第２例では、ＥＣＵ５０３の書き込み領域の途中で中断した後、次回は、その中断した箇所から書き換えを再開できる。

図１１に概念的に示すように『中断機能』の第３例では、ＥＣＵが二つ或いは複数の面（即ち図中「１面」及び「２面」）の書き込み領域を有しており、一つの面についての書き込みが完了した段階で中断を行い、他の面を更新可能なタイミングが来た場合に書き込んだ面と切り替えを実施する。より具体的には、本第３例では、ＥＣＵ５０４の機能は一つの面（即ち“１面”）で全て作動される。このため、他方の面（“２面”）を更新している最中でも、一つの面でＥＣＵ５０４は作動可能となる。２面の更新が完了した段階で一度中断を行い、作動していた１面が停止された段階で、１面と２面を切り替え、２面を作動する面とすることで更新したプログラムを実行することが可能となる。そのため、更新タイミングや中断によって、当該ＥＣＵ５０４の機能が損なわれることはない。

上述の中断機能の第１〜第３例について言えば、『第１例の中断機能＜第２例の中断機能＜第３例の中断機能』の順で、安全性が高くなる（即ち、第３例の安全性が最も高い）。言い換えれば、この順で、ユーザへの影響或いは悪影響が小さい（即ち、第３例の影響が最も小さい）。但し、第２例の中断機能は、どこまで更新が実行されたか確認できる機能を追加する必要がある。他方、第３例の中断機能は、同じ容量のメモリを（“１面”及び“２面”を構築するように）二つ或いはそれ以上用意する必要があり、ＥＣＵの変更規模やコストアップの規模も大きくなる。このため、全てに第３例の中断機能を準備することは実践上困難である。因みに、第２例の中断機能については、既に差分リプロ等の機能として実現されている。またここでは一例として３手法の中断機能を示したが、新たな中断機能が実現された場合には、中断機能の判定に追記を実施する。

再び図８において、このように中断機能の確認（ステップＳ２２）が終わると、更新ランク監視ＥＣＵ１では、上述のステップＳ２１で判定或いは推測された『安全上の構え』及び上述のステップＳ２２で確認された『中断機能』（図９から図１１参照）に基づいて、実施可能な更新ランクを判定する（ステップＳ２３）。ステップＳ２３で判定される結果の一具体例を図１２に示す。

図１２の表において、左から第１列目のコラムには、ステップＳ２１で得られた『安全上の構えが』が代入される。ここでは『安全上の構えがあるか』については、『ない』、『ある』及び『十分ある』の３通りのうちの一つとされている。左から第２列目のコラムには、ステップＳ２２で得られた『中断機能』が代入される。ここでは『中断機能があるか』については、『中断機能なし』、『中断機能１（図９に例示した第１例の機能あり）』、『中断機能２（図１０に例示した第２例の機能あり）』、『中断機能３（図１１に例示した第３例の機能あり）』といった４通りのうちの一つとされている。

図１２の表の左から第１列目及び第２列目のコラムに、上述の如き判定或いは推測結果等を夫々代入することで、左から第３列目（即ち右端）のコラムにある“ランクＮまで実施可能（但しＮは更新ランクの最大値を取る）』として、『実施可能な更新ランク』が、判定或いは推測されることになる（ステップＳ２３）。本具体例では、安全上の構えが『ない＜ある＜十分ある』の順で、実施可能な更新ランクが大きくされており、中断機能については、『中断機能無＜中断機能１＜中断機能２＜中断機能３』の順で、実施可能な更新ランクが大きくされている。なお、図１２の実施可能な更新ランクとして「どのランクでも実施可能」とあるのは、図６及び図７で例示した２０段階に分けられたランクであれば、「ランク２０まで実施可能」という意味と同じである。より一般には、ここで判定される『実施可能な更新ランク』が大きい程、更新される機会や頻度が増加することになり、ここで判定される『実施可能な更新ランク』が小さい程、更新される機会や頻度が減少することになる。

再び図８において、以上詳細に説明したステップＳ２３の処理が終わると、更新ランク監視ＥＣＵ１は、更新ランクは、実施可能な更新ランク以下か否かを判定する（ステップＳ２４）。より具体的には、図６及び図７各々の表の右端コラムに例示された更新ランクが、図１２の表の右端コラムに例示された実施可能ランク以下であれば（ステップＳ２４：Ｙｅｓ）、更新可と判定する（ステップＳ２５）。これに対して、更新ランクが実施可能な更新ランク以下であれば（ステップＳ２４：Ｎｏ）、更新不可と判定する（ステップＳ２６）。

再び図３に戻り、上記図８の処理により更新可（即ち、更新は実施可能）と判定されれば（ステップＳ２０：Ｙｅｓ）、更新ランク監視ＥＣＵ１は、更新ランクを下げられるか否か、即ち更新ランクを少しでも下げる方法或いは手段があるか否かを判定する（ステップＳ３０）。ここでの更新ランクを少しでも下げる方法或いは手段としては、車両用途管理ＥＣＵ３（図１参照）で管理される情報を参照し、週末に使用頻度が低いユーザであれば、ユーザに曜日を代えてもらう方法が挙げられる。車両状態管理ＥＣＵで管理される情報を参照し、走行中であれば、ユーザに停車をしてもらう方法が挙げられる。或いは、充電が可能であれば、充電をしてもらう方法や、車両にスマートフォンを登録していなければ、登録してもらう方法が挙げられる。

なお、ここでは更新ランクを下げることを主として説明したが、逆に、ステップＳ２１（図８参照）における車両に係る安全上の構えや、ステップＳ２２（図８参照）におけるＥＣＵに係る中断機能を充実させることで、ステップＳ２３（図８参照）における実施可能な更新ランクを上げさせることで、結果的に、ステップＳ３０における更新ランクを下げるようにしても構わない。

他方、図３において、前述の図８の処理により更新不可（即ち、更新は実施可能でない）と判定されれば（ステップＳ２０：Ｎｏ）、更新ランク監視ＥＣＵ１は、ステップＳ２３（図８参照）で判定した実施可能な更新ランクまで、更新ランクを下げられるか否か、即ち、そこまで更新ランクを下げる方法或いは手段があるか否かを判定する（ステップＳ４０）。ここでの更新ランクを下げる方法としては、前述のステップＳ３０の場合と概ね同様に、車両用途管理ＥＣＵ３（図１参照）で管理される情報を参照し、週末に使用頻度が低いユーザであれば、ユーザに曜日を代えてもらうことで、更新ランクを実施可能な更新ランクまで下げる方法が挙げられる。車両状態管理ＥＣＵで管理される情報を参照し、走行中であれば、ユーザに停車をしてもらうことで、更新ランクを実施可能な更新ランクまで下げる方法が挙げられる。或いは、充電が可能であれば、充電をしてもらうことや、車両にスマートフォンを登録していなければ、登録してもらうことで、更新ランクを実施可能な更新ランクまで下げる方法が挙げられる。

なお、ここでは更新ランクを下げることを主としているが、これも前述のステップＳ３０の場合と概ね同様に、実施可能な更新ランクを上げさせることで、結果的に、ステップＳ４０における更新ランクを、実施可能な更新ランクまで下げるようにしても構わない。

続いて、図３において、ステップＳ３０で更新ランクを下げられると判定された場合（ステップＳ３０：Ｙｅｓ）、更新ランク監視ＥＣＵ１は、ステップＳ３０で得られた更新ランクを下げる方法或いは手段を、ユーザに通知或いは提案する（ステップＳ５０ａ）。ここでは例えば、ユーザが乗車中であれば、ナビに提案内容を表示する。或いは、ユーザが降車中であれば、スマートフォンに提案内容を表示する。

更に、更新ランク監視ＥＣＵ１は、そのように通知された提案をユーザが承認したか否かを判定する（ステップＳ６０ａ）。ここでは例えば、ナビに提案内容が表示されていれば、ナビ画面上でユーザから回答を貰うようにする。或いは、スマートフォンに提案内容が表示されていれば、スマートフォン画面上でユーザから回答を貰うようにする。

提案をユーザが承認した場合（ステップＳ６０ａ：Ｙｅｓ）、更新ランク監視ＥＣＵ１は、ユーザが承認した提案内容が実現されたことを確認し、更新ランクを更新し（ステップＳ７０ａ）、最終的に更新可とする（ステップＳ８０）。具体的には、更新ランク監視ＥＣＵ１は、ステップ３０で得られた更新ランクを、ステップＳ１８ａ又は１８ｂ（図４参照）で取得した更新ランクに上書きする。

他方、図３において、ステップＳ４０で更新ランクを実施可能な更新ランクまで下げられると判定された場合（ステップＳ４０：Ｙｅｓ）、更新ランク監視ＥＣＵ１は、ステップＳ４０で得られた実施可能な更新ランクまで更新ランクを下げる方法或いは手段を、前述のステップＳ５０ａの場合と同様に、ユーザに提案する（ステップＳ５０ｂ）。更に、前述のステップＳ６０ａの場合と同様に、更新ランク監視ＥＣＵ１は、そのように通知された提案をユーザが承認したか否かを判定する（ステップＳ６０ｂ）。ここで、提案をユーザが承認した場合（ステップＳ６０ｂ：Ｙｅｓ）、前述のステップＳ７０ａの場合と同様に、更新ランク監視ＥＣＵ１は、ユーザが承認した提案内容が実現されたことを確認し、更新ランクを更新し（ステップＳ７０ｂ）、最終的に更新可とする（ステップＳ８０）。

他方、更新ランク監視ＥＣＵ１は、前述のステップＳ３０で更新ランクを下げられないと判定した場合（ステップＳ３０：Ｎｏ）、更新ランクを更新することなく、そのまま更新可として（ステップＳ８０）、一連の処理を終了する。或いは、更新ランク監視ＥＣＵ１は、前述のステップＳ４０で更新ランクを実施可能な更新ランクまで下げられないと判定した場合（ステップＳ４０：Ｎｏ）、更新ランクを更新することなく、そのまま更新不可として（ステップＳ９０）、一連の処理を終える。

他方、更新ランク監視ＥＣＵ１は、前述のステップＳ６０ａで提案をユーザが承認しない場合（ステップＳ６０ａ：Ｎｏ）、更新ランクを更新することなく、そのまま更新可として（ステップＳ８０）、一連の処理を終了する。或いは、更新ランク監視ＥＣＵ１は、前述のステップＳ６０ｂで提案をユーザが承認しない場合（ステップＳ６０ｂ：Ｎｏ）、更新ランクを更新することなく、そのまま更新不可として（ステップＳ９０）、一連の処理を終える。

以上のように、本実施形態では、更新ランク監視ＥＣＵ１等により、各種状況に応じて適宜に、更新ランクの制御が実施され、ユーザに不利不便をなるべく掛けないように配慮しつつ、更新の頻度を高められ、更新の機会を増やせる。本実施形態によれば、現在ディーラにてバージョンアップ、リコール等の一環として専門スタッフにより行われている車載ＥＣＵのリプログラミング作業は、専門スタッフが存在しない状況でも実施可能となる。この際、書き換えを失敗するリスクも格段に低められる。特に、書き換え失敗は、書き換え対象となるＥＣＵや車両の不具合に繋がりかねないので、本実施形態の如く、書き換えを安全確実に実施可能であることは大変有意義である。しかも、本実施形態の如く、リプログラミングの状態或いは状況に応じて、書き換えに関してランク分けをすることで、安全に十分注意しながらもリプログラミング達成の確率を向上させることも可能となる。よって、リプログラミングによる中断の機会を、効率的に低減でき、商品力のある機能をタイムリーに導入することが容易となり、実践上極めて有利である。

加えて、本実施形態によれば、ソフトウエア選択用ＵＩ５、表示ＥＣＵ７等によって、ソフトウエアを更新すべきか否かの情報がユーザに事前に伝えられる。これにより、実際の更新の直前或いは更新時にだけユーザに通知されるが故にユーザが更新することを失念した結果、いざというとき（即ち、車両の使用が強く望まれている際に）車両が使えなくなってしまうという可能性を格段に低減できる。更に、実施形態では特に、更新ランクが高い場合には、ソフトウエア選択用ＵＩ５等の採用により（図１等参照）、ユーザに該更新ランクを下げる機会を与える（即ち、ユーザに提案し、選択的に承認を得る）ので、該更新ランクを適宜に下げることで、より安全確実に更新を達成することも可能である。

因みに現在、車両のソフトウエア更新頻度は、実践的な意味ではそう多くないため、更新作業による多少の利便性の低下であれば余り影響がなく、ソフトウエアの機能追加による利益の方が勝ると考えられる。しかしながら、近未来的には、ＩｏＴ（Internet of Things）の普及、自動運転の普及等に伴って、車両内外間でデータのやり取りの機会及びやり取りされるデータ量が増え、今まで以上に或いは飛躍的に、ソフトウエアの更新頻度が上がることが推測される。或いは、スマートフォンやパソコンのように車両に機能を逐次追加更新することが容易に考えられ、ソフトウエアの更新頻度が更に高まると推測される。従って、上述の如く本実施形態により、更新の都度にユーザに不利不便を掛ける或いはユーザに不快な思いをさせる（即ち、機能制限を強いられる）頻度を、効率的に低減することは、近未来的に極めて有利となって行くものと考えられる。本実施形態によれば、ソフトウエア更新の頻度が上がっても実践上十分に対応可能となる。

なお、本発明は、請求の範囲及び明細書全体から読み取るこのできる発明の要旨又は思想に反しない範囲で適宜変更可能であり、そのような変更を伴うソフトウエア更新制御装置もまた本発明の技術思想に含まれる。

１ 更新ランク監視ＥＣＵ
５ ソフトウエア選択用ＩＵ
８〜１１ 書き換えＥＣＵ
５０ 車内ネットワーク
１０２ 取得部
１０３ 更新ランク判定部
１０４ 更新ランク更新部
１０５ 実施可能ランク判定部
１０６ 更新可否判定部
１５０ 通信網
２００ サーバ

Claims (1)

1. 車両の電子制御装置用ソフトウエアの更新を制御するソフトウエア更新制御装置であって、
   前記電子制御装置用ソフトウエアの更新すべき内容を示す更新情報を取得する取得部と、
   該取得された更新情報に係る、更新の難易度をレベルで示す更新ランクを、前記内容、前記電子制御装置の状態及び前記車両の状態のうち少なくとも一つに基づいて判定する更新ランク判定部と、
   前記判定された更新ランクを更新する更新ランク更新部と、
   前記更新情報による更新の実施の容易度をレベルで示す実施可能ランクを判定する実施可能ランク判定部と、
   前記更新された更新ランクと前記判定された実施可能ランクとを比較して、前記電子制御装置用ソフトウエアの更新を実施するか否かを判定する更新可否判定部と
   を備え、
   前記更新ランク更新部は、前記更新ランクが高いために前記更新可否判定部により更新を実施しないと判定された場合であって前記更新ランクを下げられる場合に、前記更新ランクを下げる旨を当該車両のユーザに提案すると共に該ユーザによる該提案の承認を受けて前記更新ランクを更新することを特徴とするソフトウエア更新制御装置。