JP7486698B2 - 車両ソフトウェア管理装置および車両ソフトウェア管理システム - Google Patents

Description

本願は、車両ソフトウェア管理装置および車両ソフトウェア管理システムに関するものである。

近年、自動車業界ではＯＴＡ(Over The Air)技術を利用した車両用制御装置のソフトウェア更新が採用され始めている。ＯＴＡ技術は、無線通信を利用してデータを送受信することを指す。特に、スマートフォンを代表とする無線通信端末において無線通信端末自身のＯＳ(Operating System)または設定されたアプリケーションソフトウェアの更新のためのデータ通信のことを指してＯＴＡと称する場合が多い。

車両用制御装置のソフトウェア更新を、ＯＴＡ技術を用いて安定的に実施する技術が提案されている。ソフトウェアの書き換えを実施する場合に各車両用制御装置が置かれた環境に応じてソフトウェアの書き換えの可否を判断する技術が開示されている（例えば特許文献１）。

特開２００６－２６８５５４号公報

特許文献１に記載の技術によれば、車両用制御装置のソフトウェアの更新に際して、車両用制御装置の置かれた環境を考慮している。例えば、車両用制御装置の温度、電圧、エンジンオフ後の経過時間などを考慮して、ソフトウェアの書き換えの可否を判断している。このようにすることで、安定した環境でＯＴＡ技術を用いたソフトウェアの更新を実行することができる。

しかし、特許文献１に記載の技術では、複数のソフトウェアが連携してサービスの提供を実現する場合の、ソフトウェアの管理について考慮されていない。また、各ソフトウェアが正常に動作できる組み合わせであるかどうかについて、保証されていない。そして、制御装置が異常となった場合のサービスの提供の維持についても考慮されていない。車両に搭載された制御装置の動作が異常を示した場合に、異常を示した制御装置によって実行されるソフトウェアに関連するサービスの提供が困難となる。

本願はかかる課題を解決するためになされたものである。制御装置の動作が異常を示した場合であっても、停止されたサービスの提供を続行できるソフトウェアのバージョンへのソフトウェアの更新が可能となる車両ソフトウェア管理装置および車両ソフトウェア管理システムを得ることを目的とする。

本願に係る車両ソフトウェア管理装置は、
車両に設けられた複数の制御装置の動作が正常か異常かを示す制御装置状態情報と、制御装置が実行するソフトウェアの機能とバージョンを示す機能バージョン情報と、ソフトウェアを用いて実施されるサービスとソフトウェアの関係を示すソフトウェアサービス情報と、を取得する情報取得部、
動作が異常な制御装置のために実施不可能となったサービスである停止サービスを検出する停止サービス検出部、
情報取得部によって取得された制御装置状態情報と、停止サービス検出部からの停止サービス情報を車外サーバへ伝達する通信部、および、
ソフトウェアの更新を制御装置に指示するソフトウェア更新部、を備え、
通信部は、停止サービス検出部によって停止サービスが検出された場合に、停止サービスを正常な制御装置によって実施するバージョンのソフトウェアを車外サーバから受信し
ソフトウェア更新部は、車外サーバから受信したソフトウェアへの更新を制御装置へ指示するものである。

本願に係る車両ソフトウェア管理システムは、
車両に設けられた制御装置が実行する複数の機能とバージョンのソフトウェアと、ソフトウェアを用いて実施されるサービスとソフトウェアとの関係を示すソフトウェアサービス情報とを記憶する記憶部、
車両ソフトウェア管理装置からの要求に応じてソフトウェアを送信するとともに、制御装置状態情報と停止サービス情報を車両ソフトウェア管理装置から受信する車外サーバ通信部、
車外サーバ通信部によって受信された停止サービス情報が停止サービスの存在を示す場合に、停止サービスを正常な制御装置によって実施するソフトウェアのバージョンを記憶部のソフトウェアサービス情報から検索するソフトウェア検索部、および、
ソフトウェア検索部によって検索されたバージョンのソフトウェアを記憶部から読み出し車外サーバ通信部から車両ソフトウェア管理装置へ送信させる対策ソフトウェア伝達部、を有した車外サーバと、
車両ソフトウェア管理装置と、を備えたものである。

本願に係る車両ソフトウェア管理装置および車両ソフトウェア管理システムでは、停止されたサービスを正常な制御装置によって実施するバージョンのソフトウェアを車両ソフトウェア管理装置が車外サーバから受信する。それにより、制御装置の動作が異常を示した場合であっても、サービスの提供を続行できるソフトウェアのバージョンへの更新が可能となる。これによって、必要なサービスの提供を続行することができ、利便性が向上する。

実施の形態１に係る車両ソフトウェア管理装置の構成図である。 実施の形態１に係る車両ソフトウェア管理装置のハードウェア構成図である。 実施の形態１に係るソフトウェアの機能バージョン情報を示す図である。 実施の形態１に係るソフトウェアサービス情報を示す第一の図である。 実施の形態１に係るソフトウェアサービス情報を示す第二の図である。 実施の形態１に係るソフトウェアサービス情報を示す第三の図である。 実施の形態１に係る制御装置状態情報を示す図である。 実施の形態１に係る停止サービス情報を示す図である。 実施の形態１に係る車両ソフトウェア管理装置のソフトウェア更新処理のフローチャートである。 実施の形態１に係る車両ソフトウェア管理装置の停止サービス対応処理のフローチャートである。 実施の形態２に係る車両ソフトウェア管理システムの構成図である。 実施の形態２に係る車外サーバの通信処理の第一のフローチャートである。 実施の形態２に係る車外サーバの通信処理の第二のフローチャートである。 実施の形態３に係る車外サーバの通信処理の第二のフローチャートである。 実施の形態３に係るソフトウェアサービス情報を示す図である。

以下、本願の実施の形態に係る車両ソフトウェア管理装置について、図面を参照して説明する。

１．実施の形態１
＜車両ソフトウェア管理装置の構成＞
図１は、実施の形態１に係る車両ソフトウェア管理装置１００の構成図である。車両ソフトウェア管理装置１００は車両１に搭載されており、通信部１０３、情報取得部１０１、停止サービス検出部１０２、ソフトウェア更新部１０４を備えている。

車両ソフトウェア管理装置１００と車外サーバ９００は、モバイルネットワークなどの広域通信網を介して相互通信可能である。両者は具体的には、通信部１０３とサーバ通信部９０２を介して通信を行う。車外サーバ９００は車両ソフトウェア管理装置１００に対して車両機能向上のための更新ソフトウェアを送信することができる。図１では、車外サーバ９００はクラウド上に構成されている場合を示し、雲に乗った図でこの構成を表現している。車外サーバ９００は、ＯＴＡサーバと称されることもある。

車両１に搭載された車両ソフトウェア管理装置１００は、第一制御装置２００、第二制御装置３００、第三制御装置４００と接続している。第一制御装置２００は、バージョン２．１．０のソフトウェア２０１と、バージョン２．０．０のソフトウェア２０２を有しており、これらのソフトウェアを実行する（ソフトウェはＳＷ、バージョンはＶｅｒ．と表記している）。第二制御装置３００は、バージョン１．１．０のソフトウェア３０１を有しており、このソフトウェアを実行する。第三制御装置４００は、バージョン２．１．３のソフトウェア４０１を有しており、このソフトウェアを実行する。図１では第一制御装置２００、第二制御装置３００、第三制御装置４００が車両ソフトウェア管理装置１００に接続されている例を示したが、制御装置の数は、これに限られるものではない。

車両ソフトウェア管理装置１００は、通信部１０３を介して車外サーバ９００に最新バージョンの更新ソフトウェアを要求する。車外サーバ９００から通信部１０３を介して更新ソフトウェアを受信した車両ソフトウェア管理装置１００は、更新ソフトウェアを実行すべき制御装置に転送し、ソフトウェア更新部１０４が該当する制御装置に書き換えを指示する。

車両ソフトウェア管理装置１００の情報取得部１０１は、制御装置状態情報、機能バージョン情報およびソフトウェアサービス情報を取得する。制御装置状態情報は、各制御装置の動作が正常か異常かを示す情報である。機能バージョン情報は、各制御装置が実行するソフトウェアの機能とバージョンを示す情報である。ソフトウェアサービス情報は、ソフトウェアを用いて実施されるサービスとソフトウェアの関係を示す情報である。

＜車両ソフトウェア管理装置のハードウェア構成＞
図２は、実施の形態１に係る車両ソフトウェア管理装置１００のハードウェア構成図である。図２の構成図は、第一制御装置２００、第二制御装置３００、第三制御装置４００および車外サーバ９００にも適用できる。以下、代表として車両ソフトウェア管理装置１００について説明する。車両ソフトウェア管理装置１００の各機能は、車両ソフトウェア管理装置１００が備えた処理回路により実現される。具体的には、車両ソフトウェア管理装置１００は、図２に示すように、処理回路として、ＣＰＵ（Central Processing Unit）などの演算処理装置９０（コンピュータ）、演算処理装置９０とデータのやり取りする記憶装置９１、演算処理装置９０に外部の信号を入力する入力回路９２、演算処理装置９０から外部に信号を出力する出力回路９３、及び通信路９８を介してデータを送受信する通信部９９などのインターフェースを備えている。

演算処理装置９０として、ＡＳＩＣ（Application Specific Integrated Circuit）、ＩＣ（Integrated Circuit）、ＤＳＰ（Digital Signal Processor）、ＦＰＧＡ（Field Programmable Gate Array）、各種の論理回路、及び各種の信号処理回路などが備えられてもよい。演算処理装置９０にはＳｏＣ（System on a Chip）技術が適用されてもよい。また、演算処理装置９０として、同じ種類のものまたは異なる種類のものが複数備えられ、各処理が分担して実行されてもよい。車両ソフトウェア管理装置１００には、記憶装置９１として、演算処理装置９０からデータを読み出し及び書き込みが可能に構成されたＲＡＭ（Random Access Memory）、演算処理装置９０からデータを読み出し可能に構成されたＲＯＭ（Read Only Memory）などが備えられている。記憶装置９１は、演算処理装置９０に内蔵されていてもよい。入力回路９２は、入力信号、センサ、スイッチが接続され、これら入力信号、センサ、スイッチの信号を演算処理装置９０に入力するＡ／Ｄ変換器などを備えている。出力回路９３は、スイッチング素子をオンオフ駆動するゲート駆動回路などの電気負荷が接続され、これら電気負荷に演算処理装置９０から制御信号を出力する駆動回路などを備えている。通信部９９は通信路９８を介して外部の制御装置などの外部装置とデータのやり取りを行うことができる。

車両ソフトウェア管理装置１００が備える各機能は、演算処理装置９０が、ＲＯＭなどの記憶装置９１に記憶されたソフトウェア（プログラム）を実行し、記憶装置９１、入力回路９２、及び出力回路９３などの車両ソフトウェア管理装置１００の他のハードウェアと協働することにより実現される。なお、車両ソフトウェア管理装置１００が用いる閾値、判定値などの設定データは、ソフトウェア（プログラム）の一部として、ＲＯＭなどの記憶装置９１に記憶されている。車両ソフトウェア管理装置１００の有する各機能は、それぞれソフトウェアのモジュールで構成されるものであってもよいが、ソフトウェアとハードウェアの組み合わせによって構成されるものであってもよい。

＜機能バージョン情報＞
図３は、実施の形態１に係る車両１の全体のソフトウェアの機能バージョン情報を示す図である。図３の上段には制御装置の名称が記載されており、二段目には各制御装置に実装されるソフトウェアの名称が記載されている。そしてその下方には、機能バージョンに応じた各ソフトウェアのバージョンが記載されている。複数のソフトウェアが連携して動作する場合、機能バージョンが同一のソフトウェアのバージョン同士であれば、連携動作が保証される。

図３では、第一制御装置には、自動ブレーキ制御用ソフトウェア、急発進防止制御ソフトウェア、およびコーナセンサソフトウェアが実装されている。そして、機能バージョンが、００１の場合、自動ブレーキソフトウェアのバージョンは１．０．０、急発進防止制御ソフトウェアのバージョンは１．０．０、コーナセンサソフトウェアのバージョンは１．０．０である。

第二制御装置には、レーザレーダ制御ソフトウェアが実装されている。機能バージョンが、００１の場合、レーザレーダ制御ソフトウェアのバージョンは１．０．０である。

第三制御装置には、フロントカメラ制御ソフトウェアおよびリアカメラ制御ソフトウェアが実装されている。機能バージョンが、００１、００２の場合、フロントカメラ制御ソフトウェアおよびリアカメラ制御ソフトウェアは利用できない。

フロントカメラ制御ソフトウェアは、機能バージョンが００３以降で利用可能となる。機能バージョンが００３の場合、フロントカメラ制御ソフトウェアのバージョンは１．０．０である。リアカメラ制御ソフトウェアは、機能バージョンが００４以降で利用可能となる。機能バージョンが００４の場合、リアカメラ制御ソフトウェアのバージョンは１．０．０である。

第四制御装置、第五制御装置、第六制御装置についても実装されるソフトウェアが記載されている。ここではこれらのソフトウェアの説明を省略する。また、制御装置の数は６台に限定されるものではない。

＜ソフトウェアの更新とロールバック＞
図３のソフトウェアの機能バージョン情報では、機能バージョンとして００１から００４までバージョンアップしている例が示されている。例えば、機能バージョンが００３である場合に、車外サーバ９００の保有するソフトウェアが機能バージョン００４にバージョンアップされた場合を考える。

車両１に搭載された車両ソフトウェア管理装置１００は、現在保有しているソフトウェアの機能バージョンが００３であり、車外サーバ９００の保有するソフトウェアがアップデートされて機能バージョン００４の最新ソフトウェアが提供可能となったことを知る。このとき車両ソフトウェア管理装置１００は、車外サーバ９００に最新バージョンのソフトウェアの送信を要求する。そして、車外サーバ９００から最新バージョンのソフトウェアを受信して、各制御装置にソフトウェアの更新を指示する。

ソフトウェアの更新を実行する場合に、更新対象の制御装置のうち、ソフトウェアの更新を正しく実行できない制御装置が存在する場合は、全ての制御装置のソフトウェアを更新前の状態に戻す処理が行われる。この処理をロールバックと称する。ロールバックによって、ソフトウェア更新による問題の発生を防ぎ、安定した車両の動作を保つことができる。

ロールバックは、ソフトウェアの更新時以外にも実行される。通常のソフトウェアの実行中にも、制御装置に異常があることが判明した場合に、機能バージョンを一つ前に戻すことによって対処する。

＜ソフトウェアサービス情報＞
図４は実施の形態１に係るソフトウェアサービス情報を示す第一の図である。サービスとは車両１の運転者に対して提供できる機能的利便性のことである。サービスは、車両の性能、快適性、安定性、信頼性、故障耐性などを向上させる機能を指す。サービスは単一または複数のソフトウェアによって実現される。車両が提供するサービスの中には、ＡＤＡＳ（Advanced Driving Assistant System）機能、自動運転機能のように複数の制御装置、複数のソフトウェアの連携が必要な大規模なサービスが存在する。ソフトウェアサービス情報は、サービスとこれを実現するソフトウェアの関係に関する情報である。

図４では、サービスとして自動ブレーキサービスについて記載している。自動ブレーキサービスは、車両１の周囲の物体、人間を検知して自動的にブレーキをかけて衝突を防止するサービスである。

自動ブレーキサービスは機能バージョン００１、００２については、第一制御装置に実装された自動ブレーキ制御ソフトウェアとコーナセンサソフトウェア、および第二制御装置に実装されたレーザレーダ制御ソフトウェアとが連携して実現するサービスである。自動ブレーキサービスは機能バージョン００３以降については、第三制御装置に実装されたフロントカメラ制御ソフトウェアとの連携も加わることが示されている。

図５は、実施の形態１に係るソフトウェアサービス情報を示す第二の図である。ここでは、サービスとして急発進防止サービスについて記載している。急発進防止サービスは、車両１が停止状態または微速状態から急加速された場合に、周囲の状況を参考としつつ、ブレーキペダルとアクセルペダルの踏み間違いを考慮して変速機、エンジンを制御して急加速を抑止するサービスである。

急発進防止サービスは機能バージョン００１、００２については、第一制御装置に実装された急発進防止制御ソフトウェアとコーナセンサソフトウェア、第四制御装置に実装されたエンジン制御ソフトウェア、および第五制御装置に実装された変速機制御ソフトウェアとが連携して実現するサービスである。急発進防止サービスは機能バージョン００３以降については、第三制御装置に実装されたフロントカメラ制御ソフトウェアとの連携も加わることが示されている。

図６は、実施の形態１に係るソフトウェアサービス情報を示す第三の図である。ここでは、サービスとしてアイドル速度制御サービスについて記載している。アイドル速度制御サービスは、アイドル状態のエンジン回転速度を調整して暖機、エアコン負荷、燃費、車室内騒音、振動などのバランスを最適化するサービスである。アイドル速度制御サービスは、第四制御装置に実装されたエンジン制御ソフトウェア、および第五制御装置に実装された変速機制御ソフトウェアが連携して実現するサービスである。

＜制御装置の異常とサービスの停止＞
車両１において、車両全体の機能バージョン００４のソフトウェアを実行中に、第三制御装置の動作に異常が検出された場合を考える。この場合、第三制御装置の異常が検出される。そして、第三制御装置の異常によって図４に示された自動ブレーキサービスと図５に示された急発進防止サービスが実行できなくなり、停止サービスとして検出される。

図７は、実施の形態１に係る制御装置状態情報を示す図である。図８は、実施の形態１に係る停止サービス情報を示す図である。図７に示すように、第三制御装置の異常が制御装置状態情報の中に示される。そして、図８に示すように自動ブレーキサービス、急発進防止サービスが停止サービス情報に示される。

この場合にロールバック処理を行った場合、機能バージョンは００３となる。車外サーバ９００に機能バージョン００３のソフトウェアの送信を要求して受信し、該当する制御装置にソフトウェアの更新を指示する。しかし、該当する制御装置のソフトウェアを機能バージョン００３に書き戻した場合であっても、図４に示す自動ブレーキサービス、図５に示す急発進防止サービスは実行できずサービス停止状態のままとなる。

このような場合、一つ前のバージョンへのロールバック処理は解決策とならない。よって、運転者はこれらのサービスの提供を受けることを諦めて運転を継続するか、修理工場で修理が完了するまで車両を使用できなくなる。

＜異常な制御装置を使用しないバージョンのソフトウェア＞
第三制御装置に異常が発生した場合であっても、第三制御装置を使用せずにサービスを続行できるソフトウェアのバージョンを探す。図４では、自動ブレーキサービスは機能バージョンが００２のバージョンであれば、第三制御装置なしで、サービスを続行することができる。図５では、急発進防止サービスは機能バージョンが００２のバージョンであれば、第三制御装置なしで、サービスを続行することができる。

そこで、全ての制御装置の機能バージョンを００２に更新するために、車外サーバ９００から機能バージョン００２のソフトウェアを受信する。そして、該当する制御装置に機能バージョン００２のソフトウェアを書き込ませる。

車両ソフトウェア管理装置１００は、停止されたサービスを正常な制御装置によって実施するバージョンのソフトウェアを車外サーバ９００から受信する。それにより、制御装置の動作が異常を示した場合であっても、サービスの提供を続行できるソフトウェアのバージョンへの更新が可能となる。これによって、必要なサービスの提供を続行することができ、利便性が向上する。

＜ソフトウェア更新処理＞
図９は、実施の形態１に係る車両ソフトウェア管理装置１００のソフトウェア更新処理のフローチャートである。車両ソフトウェア管理装置１００の記憶装置９１には、ソフトウェア更新処理に使用する処理内容が書き込まれている。車両ソフトウェア管理装置１００の演算処理装置９０はこの処理内容を実行する。

図９のフローチャートの処理は、所定時間ごとに実行される（例えば１０ｍｓごと）。図９のフローチャートの処理は、所定時間ごとではなく、車両が所定距離走行するごと、または車両ソフトウェア管理装置１００が車外サーバ９００からデータを受信するたび、といったイベントごとに実行されることとしてもよい。

処理が開始され、ステップＳ１０１で、停止サービス検出部１０２が検出した停止サービスがあるかどうかを判定する。停止サービスが有る場合（判定はＹＥＳ）は、処理を終了する。停止サービスが無い場合（判定はＮＯ）は、ステップＳ１０２へ進む。

ステップＳ１０２では、停止サービスバックアップフラグＳＳＢＫＵＰｆがセットされているかどうか判定する。停止サービスバックアップフラグＳＳＢＫＵＰｆは、停止サービスが検出されて、これに対処するための処理が実行中であることを示すフラグである。停止サービスバックアップフラグＳＳＢＫＵＰｆがセットされている場合は、各制御装置のソフトウェアの最新バージョンへの更新は行わない。

停止サービスバックアップフラグＳＳＢＫＵＰｆがセットされていれば（判定はＹＥＳ）処理を終了する。 停止サービスバックアップフラグＳＳＢＫＵＰｆがセットされていなければ（判定はＮＯ）ステップＳ１０３へ進む。

ステップＳ１０３では、車外サーバ９００が供給できる車両１用のソフトウェアの最新機能バージョンを、通信部１０３を介して車外サーバ９００へ照会する。ステップＳ１０４で、車外サーバ９００からソフトウェアの最新バージョンを通信部１０３が受信する。

ステップＳ１０５では、車両１の各制御装置が実行中のソフトウェアの機能バージョンが、車外サーバ９００から受信した最新バージョンと異なるかどうか判定する。バージョンが同じ場合（判定はＮＯ）は処理を終了する。バージョンが異なる場合（判定はＹＥＳ）はステップＳ１０６へ進む。

ステップＳ１０６では、車外サーバ９００へ最新バージョンのソフトウェアの送信を通信部１０３から要求する。この場合、機能バージョンが変わっても、各ソフトウェアのバージョンは変更されていない場合も存在する。その場合は、ソフトウェアの送受信と更新の処理は不要なので、ソフトウェアごとに省略してもよい。ステップＳ１０７では、最新の機能バージョンのソフトウェアを車外サーバ９００から通信部１０３が受信する。

ステップＳ１０８では、車両ソフトウェア管理装置１００のソフトウェア更新部１０４は、該当する制御装置へソフトウェアの更新を指示する。ステップＳ１０９では、ソフトウェアの更新が成功したかどうかを判定する。すべてのソフトウェアの更新が問題なく完了した場合は更新が成功した（判定はＹＥＳ）として処理を終了する。ソフトウェアの更新に問題が生じた場合（判定はＮＯ）はステップＳ１１０でコールバック処理を実行する。すべてのソフトウェアを元のバージョンに戻して、車両の制御を安定させる。

＜停止サービス対応処理＞
図１０は、実施の形態１に係る車両ソフトウェア管理装置１００の停止サービス対応処理のフローチャートである。車両ソフトウェア管理装置１００の記憶装置９１には、停止サービス対応処理に使用する処理内容が書き込まれている。車両ソフトウェア管理装置１００の演算処理装置９０はこの処理内容を実行する。

図１０のフローチャートの処理は、所定時間ごとに実行される（例えば１０ｍｓごと）。図１０のフローチャートの処理は、所定時間ごとではなく、車両が所定距離走行するごと、または車両ソフトウェア管理装置１００が車外サーバ９００からデータを受信するたび、といったイベントごとに実行されることとしてもよい。また、図１０のフローチャートは、図９のフローチャートと連動して実行することとしてもよい。

処理が開始され、ステップＳ２０１で、情報取得部１０１によって情報取得を実行する。具体的には制御装置状態情報、機能バージョン情報、ソフトウェアサービス情報を取得する。そして、停止サービス検出部１０２によって停止サービスを検出し停止サービス情報を得る。

ステップＳ２０２では、停止サービス検出部１０２が検出した停止サービスがあるかどうかを判定する。停止サービスが無い場合（判定はＮＯ）は、処理を終了する。停止サービスが有る場合（判定はＹＥＳ）は、ステップＳ２０３へ進む。

ステップＳ２０３では、制御装置状態情報、停止サービス情報を通信部１０３から車外サーバへ伝達する。ステップＳ２０４では、車外サーバから通信部１０３が応答を受信する。

ステップＳ２０５では、車外サーバから応答として受信した内容が、停止サービスに対応する対策ソフトウェアであるかどうか判定する。対策ソフトウェアで無ければ（判定はＮＯ）、ステップＳ２０８で停止サービスバックアップフラグＳＳＢＫＵＰｆをクリアして処理を終了する。

ステップＳ２０５で、車外サーバから応答として受信した内容が、停止サービスに対応する対策ソフトウェアである場合（判定はＹＥＳ）は、ステップＳ２０６で、該当する制御装置にソフトウェア更新部１０４がソフトウェア更新の指示を出し、ソフトウェア更新を実施する。その後、ステップＳ２０７で、停止サービスバックアップフラグＳＳＢＫＵＰｆをセットして処理を終了する。

２．実施の形態２
＜車外サーバの構成＞
図１１は、実施の形態２に係る車両ソフトウェア管理装置１００と車外サーバ９００から構成される車両ソフトウェア管理システムの構成図である。図１１は、車外サーバ９００の構成について記載した点が、図１と異なる。実施の形態２では、車外サーバ９００の細部について規定した点が異なるのみであり、符号は実施の形態１と同じである。

車外サーバ９００は、サーバ通信部９０２に加えて、記憶部９０１、ソフトウェア検索部９０３、対策ソフトウェア伝達部９０４を備える。車外サーバ９００は、車両１をはじめとする車両のための全てのバージョンのソフトウェアを記憶部９０１に保管している。また、ソフトウェアの機能とバージョンを示す機能バージョン情報、サービスとソフトウェアとの関係を示すソフトウェアサービス情報を記憶部９０１に保管している。

そして、ソフトウェアの最新バージョンが公開されるごとに、新たなバージョンのソフトウェアを記憶部９０１に蓄積し、各車両に提供を開始する。車外サーバ９００は、車両ソフトウェア管理装置１００からの要求に応える。要求に応じて、ソフトウェアの最新の機能バージョンを伝達し、最新のバージョンのソフトウェアを送信する。車外サーバ９００は各車両のソフトウェアの更新状況を把握しており、各車両のソフトウェアの状態を一元管理する。

車外サーバ９００は、車両ソフトウェア管理装置１００から停止サービス情報を受信する。停止サービスが存在する場合に、車両１の正常な制御装置によって停止サービスを実施するソフトウェアバージョンを、ソフトウェア検索部９０３が記憶部９０１から検索する。正常な制御装置によって停止サービスを実施するソフトウェアバージョンが存在する場合、この機能バージョンのソフトウェアを対策ソフトウェア伝達部９０４が車両ソフトウェア管理装置１００に伝達する。この場合、サーバ通信部９０２から対策ソフトウェアとして送信する。

＜車外サーバの通信処理＞
図１２は、実施の形態２に係る車外サーバ９００の通信処理の第一のフローチャートである。図１３は、通信処理の第二のフローチャートである。図１３は、図１２のフローチャートの続きを示す。

図１２のフローチャートの処理は、車外サーバ９００が車両ソフトウェア管理装置１００からデータを受信するたびに実行される。図１２のフローチャートの処理は、受信の都度ではなく、所定時間ごとに実行される（例えば１０ｍｓごと）こととしてもよい。

処理が開始され、ステップＳ３０１で、車両ソフトウェア管理装置１００からの受信データが、車両のソフトウェアの最新機能バージョンの照会であるかどうかを判定する。車両のソフトウェアの最新機能バージョンの照会である場合（判定はＹＥＳ）は、ステップＳ３０２へ進んで車両のソフトウェアの最新機能バージョンを返信して処理を終了する。

ステップＳ３０１で、受信データがソフトウェアの最新機能バージョンの照会でない場合（判定はＮＯ）は、ステップＳ３０３へ進む。そして、受信データが、最新バージョンのソフトウェアの送信要求であるかどうかを判定する。受信データが、最新バージョンのソフトウェアの送信要求である場合（判定はＹＥＳ）は、ステップＳ３０４で最新の機能バージョンのソフトウェアを送信して処理を終了する。

ステップＳ３０３において、受信データが、最新バージョンのソフトウェアの送信要求でない場合（判定はＮＯ）は、図１３のステップＳ３０５へ進む。ステップＳ３０５では、車両ソフトウェア管理装置１００からの受信データが、制御装置状態情報と停止サービス情報であるかどうか判定する。受信データが、制御装置状態情報と停止サービス情報でない場合（判定はＮＯ）は、処理を終了する。受信データが、制御装置状態情報と停止サービス情報である場合（判定はＹＥＳ）は、ステップＳ３０６へ進む。

ステップＳ３０６では、第二停止サービスバックアップフラグＳＳＢＫＵＰｆ２がセットされているかどうか判定する。第二停止サービスバックアップフラグＳＳＢＫＵＰｆ２がセットされている場合（判定はＹＥＳ）は、処理を終了する。第二停止サービスバックアップフラグＳＳＢＫＵＰｆ２は、停止サービスが検出されて、これに対処するための対策ソフトウェアを送信済みであることを示すフラグである。第二停止サービスバックアップフラグＳＳＢＫＵＰｆ２がセットされている場合は、新たに対策ソフトウェアの送信は行わない。

ステップＳ３０６において、第二停止サービスバックアップフラグＳＳＢＫＵＰｆ２がセットされていない場合（判定はＮＯ）は、ステップＳ３０７へ進む。ステップＳ３０７では、異常制御装置が存在するかどうか判定する。異常制御装置が無ければ（判定はＮＯ）ステップＳ３１３へ進み、第二停止サービスバックアップフラグＳＳＢＫＵＰｆ２をクリアして処理を終了する。制御装置に異常が発生した場合に備えるためである。

ステップＳ３０７では、異常制御装置が存在する場合（判定はＹＥＳ）は、ステップＳ３０８へ進む。ステップＳ３０８では、停止サービスがあるかどうか判定する。停止サービスが無ければ（判定はＮＯ）処理を終了する。停止サービスが有れば（判定はＹＥＳ）ステップＳ３０９へ進む。

ステップＳ３０９では、停止サービス対策ソフトウェアを検索する。すなわち、正常な制御装置によって停止サービスを実施するソフトウェアバージョンを、ソフトウェア検索部９０３が記憶部９０１から検索する。ステップＳ３１０では、検索の結果、停止サービス対策ソフトウェアが見つかったかどうか判定する。停止サービス対策ソフトウェアがない場合(判定はＮＯ）は、ステップＳ３１４で、第二停止サービスバックアップフラグＳＳＢＫＵＰｆ２をクリアして処理を終了する。

ステップＳ３１０で、停止サービス対策ソフトウェアが有る場合(判定はＹＥＳ）は、ステップＳ３１１で、対策ソフトウェアを車両ソフトウェア管理装置１００へ送信する。その後、ステップＳ３１２で、第二停止サービスバックアップフラグＳＳＢＫＵＰｆ２をセットして処理を終了する。

以上のように車外サーバ９００を構成することで、車両１の制御装置に異常が発生してソフトウェアによるサービスが継続できなくなった場合に、正常な制御装置によりサービスを継続できるソフトウェアのバージョンを検索して送信することができる。これにより車両ソフトウェア管理装置１００は、受信したソフトウェアを該当する制御装置に更新指示することができ、サービスを継続できる。よって、車両ソフトウェア管理装置１００と車外サーバ９００から構成される車両ソフトウェア管理システムによって、必要なサービスの提供を続行することができ、利便性が向上する。

３．実施の形態３
＜異常制御装置対策ソフトウェア＞
実施の形態１、２では、制御装置に異常が発生した場合、当該制御装置を使用せずサービスを継続することができるソフトウェアのバージョンを車外サーバ９００が検索して発見し、車両ソフトウェア管理装置１００へ伝達する例について説明した。しかし、当該制御装置を使用せずサービスを継続することができるソフトウェアのバージョンが存在しない場合も考えられる。そのような場合に、異常が発生した制御装置によって実施されるソフトウェア数が最小となるソフトウェアのバージョンを検索し、車両ソフトウェア管理装置１００へ伝達する場合について説明する。

各種のサービスの中で、一部のセンサ、一部のアクチュエータ、一部の制御装置が異常を示した場合、サービスを継続できる場合がある。一部機能を縮退してサービスを継続しても、大きな問題が無い場合も存在する。また、問題はあっても、縮退運転によって自宅、修理工場、避難場所までたどり着くことを優先したリンプホーム運転も存在する。そこで、制御装置に異常が発生した場合に、異常が発生した制御装置によって実施されるソフトウェア数が最小となるソフトウェアのバージョンへのソフトウェア更新をする場合について説明する。

実施の形態３に係る、車両ソフトウェア管理装置１００、車外サーバ９００は、実施の形態２の説明に使用した構成をそのまま流用できる。車外サーバ９００のソフトウェアの変更のみで実施の形態３の車外サーバ９００を構成できるので、符号は実施の形態１、２と同一とする。

図１４は、実施の形態３に係る車外サーバ９００の通信処理の第二のフローチャートである。実施の形態３に係る車外サーバ９００の通信処理の第一のフローチャートは、図１２をそのまま流用することとする。図１４は、図１３のステップＳ３１４をステップＳ３１５に差し換えて、ステップＳ３１５の処理の後、ステップＳ３１１へ進むこととした部分のみが異なる。以下では、異なる部分について説明する。

図１５は、実施の形態３に係るソフトウェアサービス情報を示す図である。図１５は、レーンキーピングサービスに関する連携したソフトウェアを示している。レーンキーピングサービスは、車両が走行中のレーンの中央付近の位置をキープして走行するよう、運転者を補助するサービスである。運転者の疲労、居眠り、注意散漫などにより、車両が走行中に進路不安定となり走行がふらつくのを防止することができる。

実施の形態１、２では、第三制御装置に異常が発生した場合に、第三制御装置を使用せずに、サービスを継続して提供できるソフトウェアのバージョンを検索して見つけた。しかしながら、図１５のようなサービスに対して、第三制御装置を使用せずに実行するソフトウェアのバージョンは存在しない。

このような場合であっても、車外サーバによる最適なソフトウェアの提供をあきらめず、異常が発生した制御装置によって実施されるソフトウェア数が最小となるソフトウェアのバージョンを検索し、ソフトウェアを車両ソフトウェア管理装置１００へ伝達することを考える。

図１４の車外サーバの通信処理の第二のフローチャートにおいて、ステップＳ３１０において、検索の結果、停止サービス対策ソフトウェアが見つかったかどうか判定する。停止サービス対策ソフトウェアがない場合(判定はＮＯ）は、ステップＳ３１５へ進む。

停止サービス対策ソフトウェアが存在しない場合には、ステップＳ３１５にて、車外サーバ９００のソフトウェア検索部９０３は異常制御装置対策ソフトウェアを検索する。異常制御装置対策ソフトウェアとは、異常が発生した制御装置によって実施されるソフトウェア数が最小となるソフトウェアのバージョンのことを指す。

このようなソフトウェアを検索して抽出し、ソフトウェアを車両ソフトウェア管理装置１００へ伝達する。これによって、該当する制御装置のソフトウェアの更新を実施し、異常の発生した制御装置による影響を最小限に抑えることができる。

異常が発生した制御装置では、ソフトウェアの実行が不可能となる。しかし、当該ソフトウェアが実行されない場合、これに伴い停止するサービスの数を最小限とすることができる。また、サービスによっては連携するソフトウェアの一部が実行不能となっても、機能を縮退してサービスを続行できるものも存在する。

車両ソフトウェア管理装置１００と車外サーバ９００から構成される車両ソフトウェア管理システムによって、車両の制御装置のサービスの継続と、縮退運転の縮退程度を最小限に抑制しながら、車両の走行を支援することができる。よって、車両ソフトウェア管理システムによって、利便性が向上する。

本願は、様々な例示的な実施の形態及び実施例が記載されているが、１つ、または複数の実施の形態に記載された様々な特徴、態様、及び機能は特定の実施の形態の適用に限られるのではなく、単独で、または様々な組み合わせで実施の形態に適用可能である。従って、例示されていない無数の変形例が、本願明細書に開示される技術の範囲内において想定される。例えば、少なくとも１つの構成要素を変形する場合、追加する場合または省略する場合、さらには、少なくとも１つの構成要素を抽出し、他の実施の形態の構成要素と組み合わせる場合が含まれるものとする。

１ 車両、１００ 車両ソフトウェア管理装置、１０１ 情報取得部、１０２ 停止サービス検出部、１０３ 通信部、１０４ ソフトウェア更新部、２００ 第一制御装置、２０１、２０２、３０１、４０１ ソフトウェア、３００ 第二制御装置、４００ 第三制御装置、９００ 車外サーバ、９０１ 記憶部、９０２ サーバ通信部、９０３ ソフトウェア検索部、９０４ 対策ソフトウェア伝達部

Claims (7)

1. 車両に設けられた複数の制御装置の動作が正常か異常かを示す制御装置状態情報と、前記制御装置が実行するソフトウェアの機能とバージョンを示す機能バージョン情報と、前記ソフトウェアを用いて実施されるサービスと前記ソフトウェアの関係を示すソフトウェアサービス情報と、を取得する情報取得部、
   動作が異常な前記制御装置のために実施不可能となった前記サービスである停止サービスを検出する停止サービス検出部、
   前記情報取得部によって取得された前記制御装置状態情報と、前記停止サービス検出部からの停止サービス情報を車外サーバへ伝達する通信部、および、
   前記ソフトウェアの更新を前記制御装置に指示するソフトウェア更新部、を備え、
   前記通信部は、前記停止サービス検出部によって前記停止サービスが検出された場合に、前記停止サービスを正常な制御装置によって実施するバージョンの前記ソフトウェアを前記車外サーバから受信し
   前記ソフトウェア更新部は、車外サーバから受信した前記ソフトウェアへの更新を前記制御装置へ指示する車両ソフトウェア管理装置。
2. 前記通信部は、前記制御装置の動作が正常な場合に前記車外サーバに最新バージョンのソフトウェアを要求して受信し、
   前記ソフトウェア更新部は、前記通信部によって受信された前記ソフトウェアへの更新を前記制御装置へ指示する請求項１に記載の車両ソフトウェア管理装置。
3. 前記通信部は、動作が異常となった前記制御装置がある場合に、前記異常となった制御装置が実行するソフトウェア数が最小となるバージョンの前記ソフトウェアを前記車外サーバから受信し、
   前記ソフトウェア更新部は、前記車外サーバから受信した前記ソフトウェアへの更新を前記制御装置へ指示する請求項１または２に記載の車両ソフトウェア管理装置。
4. 前記通信部は、前記停止サービス検出部によって前記停止サービスが検出された場合に、前記停止サービスを正常な前記制御装置によって実施するバージョンの前記ソフトウェアが存在する場合は前記ソフトウェアを前記車外サーバから受信し、前記停止サービスを正常な前記制御装置によって実施するバージョンの前記ソフトウェアが存在しない場合は異常となった前記制御装置が実行するソフトウェア数が最小となるバージョンの前記ソフトウェアを前記車外サーバから受信し、
   前記ソフトウェア更新部は、前記車外サーバから受信した前記ソフトウェアへの更新を前記制御装置へ指示する請求項１または２に記載の車両ソフトウェア管理装置。
5. 前記車両に設けられた制御装置が実行する複数の機能とバージョンの前記ソフトウェアと、前記ソフトウェアを用いて実施される前記サービスと前記ソフトウェアとの関係を示すソフトウェアサービス情報とを記憶する記憶部、
   前記車両ソフトウェア管理装置からの要求に応じて前記ソフトウェアを送信するとともに、前記制御装置状態情報と前記停止サービス情報を前記車両ソフトウェア管理装置から受信する車外サーバ通信部、
   前記車外サーバ通信部によって受信された前記停止サービス情報が停止サービスの存在を示す場合に、前記停止サービスを正常な前記制御装置によって実施する前記ソフトウェアのバージョンを前記記憶部の前記ソフトウェアサービス情報から検索するソフトウェア検索部、および、
   前記ソフトウェア検索部によって検索されたバージョンの前記ソフトウェアを前記記憶部から読み出し前記車外サーバ通信部から前記車両ソフトウェア管理装置へ送信させる対策ソフトウェア伝達部、を有した前記車外サーバと、
   請求項１または２に記載の車両ソフトウェア管理装置と、を備えた車両ソフトウェア管理システム。
6. 前記車両に設けられた制御装置が実行する複数の機能とバージョンの前記ソフトウェアと、前記ソフトウェアを用いて実施される前記サービスと前記ソフトウェアとの関係を示すソフトウェアサービス情報とを記憶する記憶部、
   前記車両ソフトウェア管理装置からの要求に応じて前記ソフトウェアを送信するとともに、前記制御装置状態情報と前記停止サービス情報を前記車両ソフトウェア管理装置から受信する車外サーバ通信部、
   前記車外サーバ通信部によって受信された前記制御装置状態情報が動作の異常な前記制御装置の存在を示す場合に、動作の異常な前記制御装置が実行するソフトウェア数が最小となるバージョンの前記ソフトウェアのバージョンを前記記憶部の前記ソフトウェアサービス情報から検索するソフトウェア検索部、および、
   前記ソフトウェア検索部によって検索されたバージョンの前記ソフトウェアを前記記憶部から読み出し前記車外サーバ通信部から前記車両ソフトウェア管理装置へ送信させる対策ソフトウェア伝達部、を有した前記車外サーバと、
   請求項３に記載の車両ソフトウェア管理装置と、を備えた車両ソフトウェア管理システム。
7. 前記車両に設けられた制御装置が実行する複数の機能とバージョンの前記ソフトウェアと、前記ソフトウェアを用いて実施される前記サービスと前記ソフトウェアとの関係を示すソフトウェアサービス情報とを記憶する記憶部、
   前記車両ソフトウェア管理装置からの要求に応じて前記ソフトウェアを送信するとともに、前記制御装置状態情報と前記停止サービス情報を前記車両ソフトウェア管理装置から受信する車外サーバ通信部、
   前記車外サーバ通信部によって受信された前記停止サービス情報が停止サービスの存在を示す場合に、前記停止サービスを正常な前記制御装置によって実施する前記ソフトウェアのバージョンを前記記憶部の前記ソフトウェアサービス情報から検索し、前記停止サービスを正常な前記制御装置によって実施する前記ソフトウェアが存在しない場合は動作が異常な前記制御装置が実行するソフトウェア数が最小となるバージョンの前記ソフトウェアのバージョンを前記記憶部の前記ソフトウェアサービス情報から検索するソフトウェア検索部、および、
   前記ソフトウェア検索部によって検索されたバージョンの前記ソフトウェアを前記記憶部から読み出し前記車外サーバ通信部から前記車両ソフトウェア管理装置へ送信させる対策ソフトウェア伝達部、を有した前記車外サーバと、
   請求項４に記載の車両ソフトウェア管理装置と、を備えた車両ソフトウェア管理システム。

Images