JP7475559B2 - 車両用制御装置 - 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）などが備えられている。記憶装置９１は、演算処理装置９０に内蔵されていてもよい。入力回路９２は、入力信号、センサ、スイッチが接続され、これら入力信号、センサ、スイッチの信号を演算処理装置９０に入力するＡ／Ｄ変換器などを備えている。出力回路９３は、スイッチング素子をオンオフ駆動するゲート駆動回路などの電気負荷が接続され、これら電気負荷に演算処理装置９０から制御信号を出力する駆動回路などを備えている。通信部９９は通信路９８を介して外部の制御装置などの外部装置とデータのやり取りを行うことができる。

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

＜各制御装置の接続＞
図３は、実施の形態１に係る車両用制御装置１の接続を示す構成図である。図１の概略構成図に対し、図２にて説明した各制御装置のハードウェア構成と、各制御装置間の接続について記載している。図３では、マスタ制御装置１００と、第一接続制御装置２００、第二接続制御装置３００、第三接続制御装置４００を通信バス１９８で接続した例を示している。

サーバ９００の記憶装置９９１には、サーバ９００の処理に使用するソフトウェアが書き込まれている。そして、記憶装置９９１にはその他に、車両用制御装置１において使用される、演算処理装置ごとに割り当てられた記憶装置に書き込まれているソフトウェアの最新ソフトウェア（更新ソフトウェアと称する）を保管している。サーバ９００の演算処理装置９９０は、必要と判断した時に、通信部９９９から更新ソフトウェアを送信する。サーバ９００は、広域通信網１９８ａを介して車両用制御装置１へデータを伝達し更新ソフトウェアの書き込みを指示する。

車両用制御装置１のマスタ制御装置１００は、通信部１９９ａを介してサーバ９００から送信された更新ソフトウェアに関する情報を受信する。マスタ制御装置１００の演算処理装置１９０は、更新ソフトウェアの対象が、マスタ制御装置１００であるか、第一接続制御装置２００などの他の制御装置であるかどうかを判断する。更新ソフトウェアの対象がマスタ制御装置１００の記憶装置１９１に保有するソフトウェアのためのものでない場合、車内通信部１９９を介して通信バス１９８にデータを転送する。

第一接続制御装置２００が、記憶装置２９１に、更新ソフトウェアの対象となるソフトウェアを保有する場合について説明する。第一接続制御装置２００は、サーバ９００から発信された更新ソフトウェアを、車内通信部２９９を介して受信する。第一接続制御装置２００の演算処理装置２９０は、更新ソフトウェアを記憶装置２９１に書き込む。第一接続制御装置２００は書き込み完了の情報を、車内通信部２９９から送信する。通信バス１９８を介して車内通信部１９９から、更新ソフトウェアの書き込み完了の情報を受信したマスタ制御装置１００は、通信部１９９ａからサーバ９００へこの情報を送信する。

＜マスタ制御装置の機能ブロック＞
図４は、実施の形態１に係る車両用制御装置１のマスタ制御装置１００の機能ブロック図である。各ブロックの機能について説明する。

通信部１９９ａは、広域通信網１９８ａを介しＯＴＡ技術を用いて車外のサーバ９００との通信を行う。通信部１９９ａは、受信部１９９ｂ、送信部１９９ｃを有する。マスタ制御装置１００は、受信部１９９ｂによって、サーバ９００から更新プログラムを受信する。マスタ制御装置１００は、ソフトウェアの更新結果、更新可否判断結果を送信部１９９ｃによってサーバ９００へ送信する。

通信部１９９ａは、サーバ９００から受信したデータが、マスタＥＣＵ１００で対応するべきものであるか、他の接続制御装置で対応するべきものであるかを判断する。他の接続制御装置で対応するべきものであれば、車内通信部１９９から車内の通信バス１９８を介して該当する接続制御装置へ受信データを転送する。受信データがマスタＥＣＵ１００で対応するべきものであれば、通信部１９９ａは、サーバ９００から受信したデータをデータ解析部１０２へ伝達する。

データ解析部１０２は、伝達されたデータが、優先度閾値データ更新用の情報か、更新ソフトウェアかを判別する（優先度閾値は、以後「閾値」と称する）。閾値データ更新用の情報の場合は、閾値変更部１０３にデータを伝達して、判断閾値データベース１０５を更新する。

データ解析部１０２は、伝達されたデータが、更新ソフトウェアである場合に更新対象ソフトウェア（もしくは更新対象ソフトウェアが含まれる機器）の識別を行い、更新可否判定部１０６へデータを伝達する。

更新可否判定部１０６は、更新対象ソフトウェアの優先度を優先度読出部１０４から読み出す。更新可否判定部１０６は、判断閾値データベース１０５から閾値を読み出す。更新可否判定部１０６は、更新対象ソフトウェアの優先度が閾値よりも大きければ、ソフトウェア更新部１０８に更新ソフトウェアの書き込みをさせる。例えばソフトウェアの優先度が１０段階の場合、更新対象ソフトウェアの優先度が閾値６以上の場合は更新を実行させるなどの判断を行う。ソフトウェア更新部１０８は、更新ソフトウェアの更新実行後、更新が完了した旨をサーバ９００へ送信すべく、通信部１９９ａにデータを伝達する。

更新可否判定部１０６は、更新対象ソフトウェアの優先度が閾値以下の場合は、ソフトウェアの更新を保留する。更新可否判定部１０６は、その旨をサーバ９００へ送信すべく、通信部１９９ａにデータを伝達する。

＜接続制御装置の機能ブロック＞
図５は、実施の形態１に係る車両用制御装置１の第一接続制御装置２００の機能ブロック図である。ここでは、第一接続制御装置２００について説明するが、サーバ９００から受信したデータがその他の接続制御装置で対応するべきものであっても、他の接続制御装置で同様に対応できる。その他の接続制御装置についての機能も同様なので、第一接続制御装置２００に代表させて説明する。

車内通信部２０１が、車内の通信バス１９８を介してマスタ制御装置１００から転送されたデータを受信する。車内通信部２０１は、受信したデータが、第一接続制御装置２００で対応するべきものであるか、他の接続制御装置で対応するべきものであるかを判断する。受信データが第一接続制御装置２００で対応するべきものであれば、車内通信部２０１は、受信したデータをデータ解析部２０２へ伝達する。

データ解析部２０２は、伝達されたデータが、閾値データ更新用の情報か、更新ソフトウェアかを判別する。閾値データ更新用の情報の場合は、閾値変更部２０３にデータを伝達して、判断閾値データベース２０５を更新する。

データ解析部２０２は、伝達されたデータが、更新ソフトウェアである場合に更新対象ソフトウェア（もしくは更新対象ソフトウェアが含まれる機器）の識別を行い、更新可否判定部２０６へデータを伝達する。

更新可否判定部２０６は、更新対象ソフトウェアの優先度を優先度読出部２０４から読み出す。更新可否判定部２０６は、判断閾値データベース２０５から閾値を読み出す。更新可否判定部２０６は、更新対象ソフトウェアの優先度が閾値よりも大きければ、ソフトウェア更新部２０８に更新ソフトウェアの書き込みをさせる。例えばソフトウェアの優先度が１０段階の場合、更新対象ソフトウェアの優先度が閾値６以上の場合は更新を実行させるなどの判断を行う。ソフトウェア更新部２０８は、更新ソフトウェアの更新実行後、更新が完了した旨をサーバ９００へ送信すべく、車内通信部２０１にデータを伝達する。伝達されたデータは、マスタ制御装置１００の通信部１９９ａからサーバ９００へ送信される。

更新可否判定部２０６は、更新対象ソフトウェアの優先度が閾値以下の場合は、ソフトウェアの更新を保留する。更新可否判定部２０６は、その旨をサーバ９００へ送信すべく、車内通信部２０１にデータを伝達する。伝達されたデータは、マスタ制御装置１００の通信部１９９ａからサーバ９００へ送信される。

＜更新ソフトウェアが操作するデータの参照＞
上記では、更新されるソフトウェアが有する優先度は閾値よりも大きい場合にのみ、ソフトウェアの更新を実施することについて説明した。ソフトウェア更新時に優先度の高いソフトウェアの更新が後回しとなって、車両用制御装置の挙動に影響を及ぼしてしまう可能性について、優先度の設定によってこれを回避することができる。

ここで、更新されるソフトウェアが操作するデータについて検討する。ソフトウェアが、他のソフトウェアとＯＳ、プログラムまたはデータを共有する場合がある。共有するデータには設定情報、コンテンツ（音声、画像、動画など）が含まれる。更新されるソフトウェアがこれらの共有ＯＳ、プログラムまたはデータを操作してデータを書き換えている場合には、これらを共有する他のソフトウェアに影響を及ぼすこととなる。

上記の状況は、更新される第一のソフトウェアが操作するデータを参照する第二のソフトウェア（参照ソフトウェアとも言う）がある場合、と言い換えることができる。この場合に、第一のソフトウェアの更新によって、第二のソフトウェアの挙動に影響を与える可能性がある。このとき、第二のソフトウェアの優先度が閾値より高い場合は、影響を鑑みてソフトウェアの更新を保留してもよい。そうすることによって、従来のソフトウェアのままで、車両の走行を継続できる。これによって、第二のソフトウェアの不測の動作による悪影響を防止することができる。

よって、更新される第一のソフトウェアが操作するデータを参照する第二のソフトウェアがある場合、第二のソフトウェアの優先度が閾値以下の場合にのみ、更新ソフトウェアを書き換えることとすればよい。優先度が小さいソフトウェアは、車両の挙動に与える影響度も小さいので、第一のソフトウェアの更新によって問題が発生する可能性が小さいからである。第一のソフトウェアの更新は、第一のソフトウェア単体の更新の場合と、第一のソフトウェアが操作するデータ（共有ＯＳ、プログラムを含む）とともに更新する場合の両方の場合に適用できる。

図６は、実施の形態１に係る車両用制御装置１の第一接続制御装置２００の第一のソフトウェア構成図の例である。ここでは、第一接続制御装置２００の記憶装置に書き込まれているソフトウェア（Ａ）２８１とソフトウェア（Ｂ）２８２の例について示す。ソフトウェア（Ａ）２８１とソフトウェア（Ｂ）２８２は、データ２８３を共有している。ソフトウェア（Ａ）２８１がデータ２８３を操作している場合、ソフトウェア（Ａ）２８１を更新した場合に、データ２８３に不連続な値が書き込まれることも考えられるので問題となる。

図７は、実施の形態１に係る車両用制御装置１の第一接続制御装置２００の第二のソフトウェア構成図である。ここで、ソフトウェア（Ａ）２８１は優先度８、ソフトウェア（Ｂ）２８２は優先度２を有している。この場合、ソフトウェアの更新対象としてソフトウェア（Ａ）２８１が選択された場合について考える。

閾値６が設定されている場合、更新される第一のソフトウェアとしてソフトウェア（Ａ）２８１が有する優先度８は、閾値６より大きい。また、第一のソフトウェアであるソフトウェア（Ａ）２８１が操作するデータ２８３を参照する第二のソフトウェアとしてのソフトウェア（Ｂ）２８２が有する優先度２は、閾値６以下である。よって、図７に示されたソフトウェア（Ａ）２８１の更新は可能と判断される。

図８は、実施の形態１に係る車両用制御装置１の第一接続制御装置２００の第三のソフトウェア構成図である。ここで、ソフトウェア（Ａ）２８１は優先度８、ソフトウェア（Ｂ）は優先度７を有している。この場合、ソフトウェアの更新対象としてソフトウェア（Ｂ）が選択された場合について考える。

閾値６が設定されている場合、更新される第一のソフトウェアとしてソフトウェア（Ｂ）２８２が有する優先度７は、閾値６より大きい。また、第一のソフトウェアであるソフトウェア（Ｂ）２８２が操作するデータ２８３を参照する第二のソフトウェアとしてのソフトウェア（Ａ）２８１が有する優先度８は、閾値６以下でない。よって、図８に示されたソフトウェア（Ｂ）２８２の更新は保留と判断される。

図６から図８では、第一接続制御装置２００のデータ２８３を共有するソフトウェア（Ａ）２８１、ソフトウェア（Ｂ）２８２の更新の場合の例について説明した。しかしこの説明例は、第一接続制御装置２００に限定するものではない。これらの例は、マスタ制御装置１００、他の接続制御装置のソフトウェアの更新の場合にも適用できる。

＜更新ソフトウェアと参照ソフトウェアの組合せ＞
図９は、実施の形態１に係るソフトウェア更新時の更新可否判定の組み合わせを説明する図である。更新の対象ソフトウェア、参照ソフトウェアの二つのソフトウェアが存在するとき、それぞれのソフトウェアの優先度が閾値より大きい場合を「ＹＥＳ」、閾値以下である場合を「ＮＯ」で示す。それぞれが、「ＹＥＳ」または「ＮＯ」である組合せはパターン１、パターン２、パターン３、パターン４の四通り考えられる。このうち、更新の対象ソフトウェアの更新が可能（ＹＥＳ）と判断されるのはパターン１の場合だけである。

パターン２、パターン３、パターン４の場合はいずれも対象ソフトウェアの更新が保留（ＮＯ）とされる。このため、ソフトウェア更新がされないまま継続する場合が考えられる。データを共有する優先度が高いソフトウェアが複数ある場合は、これらを同時に更新することによって、不測の事態を回避しつつ、最新のバージョンのソフトウェアを活用することができる。

また、サーバ９００からの強制的な更新指示、動的なソフトウェアの優先度の変更、閾値の更新により対応してもよい。ソフトウェアのセキュリティパッチの適用、バグ修正を実行するためには、これらの対応が必要となる場合がある。

＜マスタ制御装置の処理のフローチャート＞
図１０は、実施の形態１に係る車両用制御装置１のマスタ制御装置１００の処理を示すフローチャートである。図１０のフローチャートは、図４で説明したマスタ制御装置１００の各機能ブロックが動作する流れについて説明する。

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

処理が開始され、ステップＳ１０１で、サーバから受信した受信データがあるかどうか判定する。受信データが無い場合（判定はＮＯ）は、処理を終了する。受信データが有る場合（判定はＹＥＳ）は、ステップＳ１０８へ進む。

ステップＳ１０８では、受信データがマスタ制御装置１００を対象としたデータであるかどうか判定する。以後、フローチャート中では、制御装置をＥＣＵ（Electronic Control Unit）と記載する。受信データが、マスタＥＣＵ１００を対象としたデータでなければ（判定はＮＯ）、ステップＳ１１０へ進む。

ステップＳ１０８で受信データが、マスタＥＣＵ１００を対象としたデータであれば（判定はＹＥＳ）、ステップＳ３００のデータ対応処理を実施する。ステップＳ３００では閾値データの更新の実施、またはソフトウェアの更新の可否を判定し可能な場合ソフトウェアの更新を実施する。その後処理を終了する。ステップＳ３００の内容は、図１２、図１３にて詳細を説明する。

ステップＳ１１０では、対象とする接続ＥＣＵへ車内通信部１９９から受信データを転送する。その後処理を終了する。

＜接続制御装置の処理のフローチャート＞
図１１は、実施の形態１に係る車両用制御装置１の接続制御装置の処理を示すフローチャートである。図１１のフローチャートは、図５で説明した第一接続制御装置２００に代表される接続制御装置の各機能ブロックが動作する流れについて説明する。

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

処理が開始され、ステップＳ２０１で、マスタ制御装置１００から送信され通信バス１９８を経由して受信した、当ＥＣＵ宛の受信データがあるかどうか判定する。受信データが無い場合（判定はＮＯ）は、処理を終了する。受信データが有る場合（判定はＹＥＳ）は、ステップＳ３００へ進む。ステップＳ３００ではデータ対応処理を実施する。ステップＳ３００では閾値データの更新の実施、またはソフトウェアの更新の可否を判定し可能な場合ソフトウェアの更新を実施する。その後処理を終了する。ステップＳ３００の内容は、図１２、図１３にて詳細を説明する。

＜データ対応処理のフローチャート＞
図１２は、実施の形態１に係る車両用制御装置１のデータ対応処理を示す第一のフローチャートである。図１３は、実施の形態１に係る車両用制御装置１のデータ対応処理を示す第二のフローチャートであり、図１２の続きの処理を示す。図１２、図１３に示すデータ対応処理は、図１０、図１１のステップＳ３００に示したデータ対応処理の詳細を示す。データ対応処理は、マスタ制御装置１００または第一接続制御装置２００を始めとする接続制御装置で実行される処理である。

データ対応処理が開始されると、ステップＳ３０３で、受信データが閾値データであるかどうか判定する。受信データが閾値データでない場合（判定はＮＯ）は、ステップＳ３０５へ進む。

ステップＳ３０３で、受信データが閾値データである場合（判定はＹＥＳ）は、ステップＳ３０４で、閾値を更新する。具体的には、データ解析部が更新する閾値を閾値変更部に伝達し、閾値変更部が閾値データベースを更新する。その後ステップＳ３０５へ進む。

ステップＳ３０５では、受信データがソフトウェア更新データであるかどうか判定する。ソフトウェア更新データでない場合（判定はＮＯ）は、処理を終了する。

ステップＳ３０５で、受信データがソフトウェア更新データである場合（判定はＹＥＳ）は、ステップＳ３０６へ進む。ステップＳ３０６では、対象ソフトウェアの優先度を優先度読出部から読み出し、ステップＳ３０７へ進む。

ステップＳ３０７で、判定閾値データベースから閾値を読み出す。その後、図１３のステップＳ３０８へ進む。

図１３のステップＳ３０８では、読み出した対象ソフトウェアの優先度が閾値より大きいかどうか判定する。優先度が閾値より大きくない場合（判定はＮＯ）は、ステップＳ３１４へ進む。

ステップＳ３０８で、優先度が閾値より大きい場合（判定はＹＥＳ）は、ステップＳ３０９へ進む。ステップＳ３０９では、更新ソフトウェアに参照ソフトウェアが存在するかどうか判定する。すなわち、更新する対象のソフトウェアが操作するデータを、他のソフトウェアが参照しているかどうか判定する。更新ソフトウェアに参照ソフトウェアが存在しない場合（判定はＮＯ）は、ステップＳ３１２へ進む。

ステップＳ３０９で、更新ソフトウェアに参照ソフトウェアが存在する場合（判定はＹＥＳ）は、ステップＳ３１０へ進む。ステップＳ３１０で、参照ソフトウェアの優先度を優先度読み出し部から読み出す。

次に、ステップＳ３１１で、参照ソフトウェアの優先度が閾値より大きいかどうか判定する。参照ソフトウェアの優先度が閾値より大きい（閾値以下の値でない）場合（判定はＹＥＳ）は、ステップＳ３１４へ進む。

ステップＳ３１４では、ソフトウェア更新を保留する旨、サーバ９００へ通知する。その後、処理を終了する。

ステップＳ３１１で、参照ソフトウェアの優先度が閾値より大きくない（閾値以下の値である）場合（判定はＮＯ）は、ステップＳ３１２へ進む。ステップＳ３１２では、更新ソフトウェアを、記憶装置に書き込む。そして、ステップＳ３１３で、ソフトウェア更新を完了した旨、サーバ９００へ通知する。その後、処理を終了する。

上記のように、更新ソフトウェアの優先度が閾値以上の時のみ、ソフトウェアの更新を実行するので、更新が必要なソフトウェアを優先的に更新できる。また、更新するソフトウェアが操作するデータを参照するソフトウェアがある場合は、参照ソフトウェアの優先度が閾値以下の場合にのみ、ソフトウェア更新を実行する。これによって、共有データを参照するソフトウェアの不測の動作による悪影響を回避しつつ、最新のバージョンのソフトウェアを活用することができる。

また、サーバ９００から、閾値を変更する指示を受けた場合は、閾値を更新することができる。これにより、最適な閾値に変更しつつ、車両用制御装置１のソフトウェア更新を継続することができる。

＜参照ソフトウェア、重要度のデータ＞
図１４は、実施の形態１に係るソフトウェア更新時の共通データと参照ソフトウェアの関係を説明する図である。図１４は、共通データに対して、当該データを参照している参照ソフトウェアの一覧の例を示す。これらの共通データを操作するソフトウェアを更新する場合は、これらの共通データを参照するソフトウェアの優先度を確認し、閾値以下であることを判定する必要がある。

図１５は、実施の形態１に係るソフトウェア更新時の優先度管理を説明する図である。図１５は、制御装置内のソフトウェアそれぞれについて優先度が規定されていることを示す。

図１４、図１５に示したデータを、制御装置の記憶装置に保有している。そして、これらのデータを用いて、ソフトウェア更新時における、ソフトウェアごとの優先度の読み出し、参照ソフトウェアの優先度の読み出し、および閾値との比較を実施する。

２．実施の形態２
＜マスタ制御装置の機能ブロック＞
図１６は、実施の形態２に係る車両用制御装置１ａのマスタ制御装置１００ａの機能ブロック図である（車両用制御装置１ａは不図示）。実施の形態２に係る図１６に示したマスタ制御装置１００ａにおいて、優先度変更部１０９が追加された点が、実施の形態１に係る図４に示したマスタ制御装置１００と異なる。図２に示した制御装置のハードウェア構成は、マスタ制御装置１００ａにも適用できる。

実施の形態２に係るマスタ制御装置１００ａは、サーバ９００からの受信データによって、優先度を変更可能とした。サーバ９００からの受信データが、マスタ制御装置１００ａを対象とするデータである場合に、通信部１９９ａは、データ解析部１０２に受信データを伝達する、データ解析部１０２は、受信データが優先度を更新するデータである場合は、優先度変更部１０９に優先度のデータを渡して、優先度読出部１０４の優先度を更新させる。

＜接続制御装置の機能ブロック＞
図１７は、実施の形態２に係る車両用制御装置１ａの第一接続制御装置２００ａの機能ブロック図である。実施の形態２に係る図１７に示した第一接続制御装置２００ａにおいて、優先度変更部２０９が追加された点が、実施の形態１に係る図５に示した第一接続制御装置２００と異なる。図２に示した制御装置のハードウェア構成は、第一接続制御装置２００ａにも適用できる。

実施の形態２に係る第一接続制御装置２００ａは、サーバ９００からの受信データによって、優先度を変更可能とした。サーバ９００からの受信データが、第一接続制御装置２００ａを対象とするデータである場合に、マスタ制御装置１００ａから受信データを転送された車内通信部２０１は、データ解析部２０２に受信データを伝達する、データ解析部２０２は、受信データが優先度を更新するデータである場合は、優先度変更部２０９に優先度のデータを渡して、優先度読出部２０４の優先度を更新させる。

＜データ対応処理のフローチャート＞
図１８は、実施の形態２に係る車両用制御装置１ａのデータ対応処理を示す第一のフローチャートである。実施の形態２に係る車両用制御装置１ａの処理のフローチャートは、実施の形態１に係る処理のフローチャートである図１０、１１、１３を適用することができる。実施の形態１に係るフローチャートである図１２を、実施の形態２では図１８に置き換えた部分が異なる。図１８は実施の形態２に係るデータ対応処理の前半部分を示す。データ対応処理の後半部分は図１３を適用することができる。

図１８のデータ対応処理を示す第一のフローチャートでは、図１２のステップＳ３０３の前にステップＳ３０１、ステップＳ３０２を追加した点のみが異なる。異なる部分について説明し、同じ部分については説明を省略する。

図１８のフローチャートでは、データ対応処理が開始されると、ステップＳ３０１で、受信データが優先度データであるかどうか判定する。受信データが優先度データでない場合（判定はＮＯ）は、ステップＳ３０３へ進む。

ステップＳ３０１で、受信データが優先度データである場合（判定はＹＥＳ）は、ステップＳ３０２で、優先度データを更新する。具体的には、データ解析部が更新する優先度データを優先度変更部に伝達し、優先度変更部が優先度読出部の優先度データを更新する。その後ステップＳ３０３へ進む。

このようにして、実施の形態２では、優先度データをサーバ９００の指示によって更新できるので、必要に応じて更新するソフトウェアを変更し、適切なソフトウェアの更新を実施することが可能となる。また参照ソフトウェアの優先度を変更することで適切なソフトウェアの更新を実施することが可能となる。

３．実施の形態３
＜マスタ制御装置の機能ブロック＞
図１９は、実施の形態３に係る車両用制御装置１ｂのマスタ制御装置１００ｂの機能ブロック図である（車両用制御装置１ｂは不図示）。実施の形態３に係る図１９に示したマスタ制御装置１００ｂにおいて、運転状況判定部１１０が追加された点が、実施の形態２に係る図１６に示したマスタ制御装置１００ａと異なる。図２に示した制御装置のハードウェア構成は、マスタ制御装置１００ｂにも適用できる。

実施の形態３に係るマスタ制御装置１００ｂは、車両の運転状況を判定して、優先度を変更可能とした。運転状況信号を運転状況信号線１１１から受けて、運転状況判定部１１０は車両の運転状況を判定する。運転状況としては、車両が位置している場所、車両の存在する時間、日月年、天候、イグニッションスイッチのオン、オフ状態、車速、エンジン回転数、バッテリの残容量、車両用制御装置のハードウェア構成、ソフトウェア構成の状況などを挙げることができる。これらの状況に応じて、ソフトウェアの優先度をそれぞれ変化させることができる。

夜の時間帯など、周囲が暗い場合、照明の制御に係るソフトウェアの更新が重要になる。このような場合に、照明の制御に係るソフトウェアの更新優先度を上げてもよい。車両の存在する位置（地域）と月日に関する情報から、積雪が多い地区の冬季は、横滑り防止装置、アンチロックブレーキ制御装置の更新優先度を向上させてもよい。ナビゲーション装置のデータを含むソフトウェアについて、車両の存在する地点の近隣の地区のデータ更新の優先度を向上させてもよい。

また、車両が停車中、またはイグニッションスイッチがオフの期間のみ、特定のソフトウェアの優先度を上げてその状態でのソフトウェア更新を促すこともできる。バッテリ残容量が大きい状態でのみ特定のソフトウェアの優先度を上げて、更新を促してもよい。

制御装置のハードウェア構成およびソフトウェア構成において、ソフトウェア更新時に記憶装置を二重化する場合がある。このような状況ではソフトウェア更新中に問題が発生しても、何時でも前バージョンのソフトウェアの実行状態に復帰できる。このため、ハードウェア構成およびソフトウェア構成の余裕度を指標として、ソフトウェアごとの優先度を変更してもよい。ソフトウェア更新時に記憶装置を二重化している状況では、構成の余裕度が高いとして当該ソフトウェアの優先度を上げることとしてもよい。そうすることで、より当該ソフトウェアの更新の機会を増やすことができる。

＜マスタ制御装置の処理のフローチャート＞
図２０は、実施の形態３に係る車両用制御装置１ｂのマスタ制御装置１００ｂの処理を示すフローチャートである。実施の形態３に係る車両用制御装置１ｂの処理のフローチャートは、実施の形態２に適用される処理のフローチャートである図１１、１８、１３を適用することができる。実施の形態３に係る処理のフローチャートは、実施の形態２に適用されるフローチャートである図１０を、図２０に置き換えた部分が異なる。

実施の形態３に係るマスタ制御装置１００ｂの処理のフローチャートである図２０は、実施の形態１、実施の形態２に共通するマスタ制御装置の処理のフローチャートである図１０のステップＳ１０１の前にステップＳ１１１からステップＳ１１４を追加した点が異なる。異なる部分について説明し、同じ部分については説明を省略する。

図２０のフローチャートではマスタ制御装置１００ｂの処理が開始された後、ステップＳ１１１で運転状況信号線１１１から運転状況信号を受けて、運転状況判定部１１０が車両の運転状況を判定する。そして、ステップＳ１１２で運転状況を優先度に反映する。

ステップＳ１１３では運転状況を優先度に反映した結果、優先度データに変更があったかどうかを判定する。優先度データに変更が無い場合（判定はＮＯ）は、ステップＳ１０１へ進み、従来の処理に移行する。

ステップＳ１１３で優先度データに変更が有る場合（判定はＹＥＳ）は、ステップＳ１１４へ進み、優先度データをマスタＥＣＵまたは接続ＥＣＵで処理する。更新された優先度データが、マスタＥＣＵ対象のデータであれば、優先度変更部に優先度データが送られて、マスタＥＣＵの優先度データが更新される。マスタＥＣＵ対象のデータでなければ、該当する接続ＥＣＵの優先度変更部に優先度データが送られる。そして、該当する接続ＥＣＵの優先度データが更新される。

このようにして、実施の形態３では、運転状況判定部によって検出した運転状況を優先度データに反映させて更新することができる。このため、ソフトウェアごとの優先度を動的に変更し、適切なソフトウェアの更新を実施することが可能となる。

４．実施の形態４
＜マスタ制御装置の機能ブロック＞
図２１は、実施の形態４に係る車両用制御装置１ｃのマスタ制御装置１００ｃの機能ブロック図である。（車両用制御装置１ｃは不図示）。実施の形態４に係る図２１に示したマスタ制御装置１００ｃにおいて、運転状況判定部１１０がユーザ入力部１１２に置換された点が、実施の形態３に係る図１９に示したマスタ制御装置１００ｂと異なる。図２に示した制御装置のハードウェア構成は、マスタ制御装置１００ｃにも適用できる。

実施の形態４に係るマスタ制御装置１００ｃは、ユーザ（運転者）の入力によって車両用制御装置１ｃのソフトウェアごとの優先度を変更可能とした。ユーザによる入力信号をユーザインターフェース信号線１１３から受けて、ユーザ入力部１１２はソフトウェアの優先順位を更新する。

ユーザの有する運転技量、要望、趣味、嗜好によって必要とするアプリケーション、機能が異なる場合がある。「自動運転アプリケーションは常に最新版としておきたい」、「エンターテインメント系アプリケーションは殆ど使わないので、最新化の必要性は低い」といったユーザの意思によってソフトウェアの優先度を変更してもよい。

ナビゲーション装置などのＨＭＩ（Human-Machine-Interface）を有する装置からの入力信号に基づいて、ユーザ入力部１１２に信号を入力する。ユーザが入力する優先度変更の指示は、ソフトウェアごとに行ってもよい。しかし、車両用制御装置が提供するソフトウェアのサービスをカテゴリに分けて、カテゴリごとに優先度を指示することとしてもよい。

ユーザ入力部１１２によって、ソフトウェアの優先度をユーザ（運転者）の指示によって変更することが可能となる。これによって、より顧客満足度の高いソフトウェアの更新を実行することが可能となる。ユーザが直接ソフトウェアの優先度を変更することで、ユーザにとって最適なソフトウェアの更新を行うことができる。

＜マスタ制御装置の処理のフローチャート＞
図２２は、実施の形態４に係る車両用制御装置１ｃのマスタ制御装置１００ｃの処理を示すフローチャートである。実施の形態４に係る車両用制御装置１ｃの処理のフローチャートは、実施の形態３に適用される処理のフローチャートである図１１、１８、１３を適用することができる。実施の形態４に係る処理のフローチャートは、実施の形態３に適用されるフローチャートである図２０を、図２２に置き換えた部分が異なる。

実施の形態４に係るマスタ制御装置１００ｂの処理のフローチャートである図２２は、実施の形態３に係るマスタ制御装置の処理のフローチャートである図２０のステップＳ１１１からステップＳ１１４を、ステップＳ１１５からステップＳ１１７に置換した点が異なる。異なる部分について説明し、同じ部分については説明を省略する。

図２２のフローチャートではマスタ制御装置１００ｃの処理が開始された後、ステップＳ１１５ではユーザ入力部１１２にユーザから指示を示す信号入力があったかどうかを判定する。ユーザからの指示が無い場合（判定はＮＯ）は、ステップＳ１０１へ進み、従来の処理に移行する。

ステップＳ１１５でユーザからの指示が有る場合（判定はＹＥＳ）は、ステップＳ１１６へ進み、優先度データを変更したデータを生成する。そして、ステップＳ１１７へ進み、優先度データをマスタＥＣＵまたは接続ＥＣＵで処理する。変更された優先度データが、マスタＥＣＵ対象のデータであれば、優先度変更部に優先度データが送られて、マスタＥＣＵの優先度データが更新される。マスタＥＣＵ対象のデータでなければ、該当する接続ＥＣＵの優先度変更部に優先度データが送られる。そして、該当する接続ＥＣＵの優先度データが更新される。

このようにして、実施の形態４では、ユーザからの指示によって優先度データを変更することができる。その結果、ユーザにとって最適なソフトウェアの更新を行うことができる。

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

１ 車両用制御装置、９０、１９０、２９０ 演算処理装置、９１、１９１、２９１ 記憶装置、１０４、２０４ 優先度読出部、１０６、２０６ 更新可否判定部、１０８、２０８ ソフトウェア更新部、１１０ 運転状況判定部、１１２ ユーザ入力部、１９９ｂ 受信部

Claims (7)

1. 演算処理装置、
   前記演算処理装置によって実行されるソフトウェアが書き込まれた記憶装置、
   前記演算処理装置によって実行されるソフトウェアの優先度を読み出す優先度読出部、
   前記演算処理装置によって実行されるソフトウェアを更新する更新ソフトウェアを受信する受信部、
   前記受信部によって受信された前記更新ソフトウェアによって更新するソフトウェアに対する優先度を前記優先度読出部から読み出し、前記優先度に基づいて前記ソフトウェアが更新可能かどうか判定する更新可否判定部、
   前記更新可否判定部によって更新可能と判定された場合前記更新ソフトウェアを前記記憶装置に転送するソフトウェア更新部、を備えた車両用制御装置において、
   前記記憶装置は、複数のソフトウェアが記憶され、
   前記優先度読出部は、ソフトウェアごとに定められた優先度を読み出し、
   前記受信部は、前記演算処理装置によって実行される第一のソフトウェアを更新する第一の更新ソフトウェアを受信し、
   前記更新可否判定部は、前記第一のソフトウェアが操作するデータを参照する第二のソフトウェアがある場合は、前記優先度読出部から読み出した前記第一のソフトウェアの優先度が予め定められた優先度閾値よりも大きく、かつ前記優先度読出部から読み出した前記第二のソフトウェアの優先度が前記優先度閾値以下である場合に前記第一のソフトウェアは更新可能と判定し、
   前記ソフトウェア更新部は、前記更新可否判定部によって前記第一のソフトウェアが更新可能と判定された場合前記第一の更新ソフトウェアを前記記憶装置に転送する車両用制御装置。
2. 前記更新可否判定部は、前記第一のソフトウェアが操作するデータを参照する第二のソフトウェアがない場合は、前記優先度読出部から読み出した前記第一のソフトウェアの優先度が前記優先度閾値よりも大きい場合に、前記第一のソフトウェアは更新可能と判定する請求項１に記載の車両用制御装置。
3. 前記更新可否判定部は、前記受信部によって受信された前記優先度閾値を記憶する請求項１または２に記載の車両用制御装置。
4. 前記優先度読出部は、前記受信部によって受信された前記ソフトウェアの優先度を記憶する請求項１から３のいずれか一項に記載の車両用制御装置。
5. 前記優先度読出部は、前記ソフトウェアの優先度を車両の運転状況に応じて変更する請求項１から４のいずれか一項に記載の車両用制御装置。
6. 前記優先度読出部は、前記ソフトウェアの優先度を運転者の指示に応じて変更する請求項１から５のいずれか一項に記載の車両用制御装置。
7. 複数の演算装置、
   前記演算装置それぞれに設けられ、前記演算装置によって実行されるソフトウェアが記憶された記憶装置、を備えた請求項１から６のいずれか一項に記載の車両用制御装置。

Images