ホーム > 特許ランキング > 株式会社ＳＵＢＡＲＵ
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024063623
(43)【公開日】2024-05-13
(54)【発明の名称】車両のソフトウェア更新装置
(51)【国際特許分類】
G06F 8/65 20180101AFI20240502BHJP
B60R 16/02 20060101ALI20240502BHJP
【ＦＩ】
G06F8/65
B60R16/02 660U
【審査請求】未請求
【請求項の数】7
【出願形態】ＯＬ
(21)【出願番号】P 2022171717
(22)【出願日】2022-10-26
(71)【出願人】
【識別番号】000005348
【氏名又は名称】株式会社ＳＵＢＡＲＵ
(74)【代理人】
【識別番号】100099793
【弁理士】
【氏名又は名称】川北 喜十郎
(74)【代理人】
【識別番号】100154586
【弁理士】
【氏名又は名称】藤田 正広
(74)【代理人】
【識別番号】100182051
【弁理士】
【氏名又は名称】松川 直宏
(74)【代理人】
【識別番号】100179280
【弁理士】
【氏名又は名称】河村 育郎
(74)【代理人】
【識別番号】100180747
【弁理士】
【氏名又は名称】小森 剛彦
(72)【発明者】
【氏名】加藤 英明
【テーマコード（参考）】
5B376
【Ｆターム（参考）】
5B376CA44
5B376GA03
5B376GA07
(57)【要約】
【課題】車両のソフトウェアの更新について、車両の管理者がその更新を適切に管理できるようにする。
【解決手段】車両４のソフトウェア更新装置としての制御系２０は、更新制御装置２７、出力デバイス３８，４０を制御する入出力制御装置２４、および、管理者端末（１２）と通信可能な通信制御装置２５、を有する。更新制御装置２７は、ソフトウェアの更新処理を実行する前に、車両４に管理者が乗車しているか否かを判断する乗車判断処理、を実行する。管理者が乗車している場合、更新制御装置２７は、入出力制御装置２４を通じて、車両１に設けられる出力デバイス３８（，４０）から、更新処理の案内通知を出力する。管理者が乗車していない場合、更新制御装置２７は、通信制御装置２５を通じて、管理者端末（１２）から、更新処理の案内通知を出力する。更新制御装置２７は、更新処理の案内通知を出力した後に、ソフトウェアを更新するための処理を実行する。
【選択図】図７
【解決手段】車両４のソフトウェア更新装置としての制御系２０は、更新制御装置２７、出力デバイス３８，４０を制御する入出力制御装置２４、および、管理者端末（１２）と通信可能な通信制御装置２５、を有する。更新制御装置２７は、ソフトウェアの更新処理を実行する前に、車両４に管理者が乗車しているか否かを判断する乗車判断処理、を実行する。管理者が乗車している場合、更新制御装置２７は、入出力制御装置２４を通じて、車両１に設けられる出力デバイス３８（，４０）から、更新処理の案内通知を出力する。管理者が乗車していない場合、更新制御装置２７は、通信制御装置２５を通じて、管理者端末（１２）から、更新処理の案内通知を出力する。更新制御装置２７は、更新処理の案内通知を出力した後に、ソフトウェアを更新するための処理を実行する。
【選択図】図７
【特許請求の範囲】
【請求項1】
車両で用いられるソフトウェアを更新するために前記車両に設けられる、車両のソフトウェア更新装置であって、
前記車両のソフトウェアを更新する処理を実行する更新制御装置、前記車両に設けられる出力デバイスを制御する入出力制御装置、および、前記車両の管理者の端末デバイスと通信可能な通信制御装置、を有し、
前記更新制御装置は、
前記車両のソフトウェアを更新するための処理を実行する前に、
前記車両に前記管理者が乗車しているか否かを判断する乗車判断処理、を実行し、
前記乗車判断処理において管理者が乗車していると判断する場合には、前記入出力制御装置を通じて、前記車両に設けられる前記出力デバイスから、前記車両のソフトウェアの更新処理の案内通知を出力し、
前記乗車判断処理において管理者が乗車していないと判断する場合には、前記通信制御装置を通じて、前記車両の管理者の端末デバイスから、前記車両のソフトウェアの更新処理の案内通知を出力し、
前記車両のソフトウェアの更新処理の案内通知を出力した後に、前記車両のソフトウェアを更新するための処理を実行する、
車両のソフトウェア更新装置。
前記車両のソフトウェアを更新する処理を実行する更新制御装置、前記車両に設けられる出力デバイスを制御する入出力制御装置、および、前記車両の管理者の端末デバイスと通信可能な通信制御装置、を有し、
前記更新制御装置は、
前記車両のソフトウェアを更新するための処理を実行する前に、
前記車両に前記管理者が乗車しているか否かを判断する乗車判断処理、を実行し、
前記乗車判断処理において管理者が乗車していると判断する場合には、前記入出力制御装置を通じて、前記車両に設けられる前記出力デバイスから、前記車両のソフトウェアの更新処理の案内通知を出力し、
前記乗車判断処理において管理者が乗車していないと判断する場合には、前記通信制御装置を通じて、前記車両の管理者の端末デバイスから、前記車両のソフトウェアの更新処理の案内通知を出力し、
前記車両のソフトウェアの更新処理の案内通知を出力した後に、前記車両のソフトウェアを更新するための処理を実行する、
車両のソフトウェア更新装置。
【請求項2】
前記更新制御装置は、
前記乗車判断処理において前記車両に乗車していると判断する管理者の体調の良否を判断する体調判断処理、を実行し、
前記体調判断処理において前記車両の管理者の体調が良であると判断する場合には、前記入出力制御装置を通じて、前記車両に設けられる前記出力デバイスから、前記車両のソフトウェアの更新処理の案内通知を出力し、
前記体調判断処理において前記車両の管理者の体調が良でないと判断する場合には、前記車両のソフトウェアの更新処理の案内通知出力を止めて、前記車両のソフトウェアを更新するための処理を中断する、
請求項１記載の、車両のソフトウェア更新装置。
前記乗車判断処理において前記車両に乗車していると判断する管理者の体調の良否を判断する体調判断処理、を実行し、
前記体調判断処理において前記車両の管理者の体調が良であると判断する場合には、前記入出力制御装置を通じて、前記車両に設けられる前記出力デバイスから、前記車両のソフトウェアの更新処理の案内通知を出力し、
前記体調判断処理において前記車両の管理者の体調が良でないと判断する場合には、前記車両のソフトウェアの更新処理の案内通知出力を止めて、前記車両のソフトウェアを更新するための処理を中断する、
請求項１記載の、車両のソフトウェア更新装置。
【請求項3】
前記車両に設けられる前記入出力制御装置は、前記車両に設けられる出力デバイスとともに入力デバイスを制御するものであり、
前記更新制御装置は、
前記入出力制御装置を通じて前記車両のソフトウェアの更新処理の案内通知を出力し始めるとともに、前記車両に乗車している管理者による案内通知の表示についての認知の有無を判断する視認判断処理を繰り返し実行し、
案内通知の出力中に繰り返される前記視認判断処理において管理者が通知を視認していると判断する場合には、案内通知が出力し終える前でも、前記入力デバイスからの管理者の承諾入力を可能とし、
前記入力デバイスから管理者の承諾が入力されると、前記車両のソフトウェアを更新するための処理を実行する、
請求項１または２記載の、車両のソフトウェア更新装置。
前記更新制御装置は、
前記入出力制御装置を通じて前記車両のソフトウェアの更新処理の案内通知を出力し始めるとともに、前記車両に乗車している管理者による案内通知の表示についての認知の有無を判断する視認判断処理を繰り返し実行し、
案内通知の出力中に繰り返される前記視認判断処理において管理者が通知を視認していると判断する場合には、案内通知が出力し終える前でも、前記入力デバイスからの管理者の承諾入力を可能とし、
前記入力デバイスから管理者の承諾が入力されると、前記車両のソフトウェアを更新するための処理を実行する、
請求項１または２記載の、車両のソフトウェア更新装置。
【請求項4】
前記出力デバイスは、表示により通知を出力可能な表示デバイスであり、
前記更新制御装置は、
前記車両のソフトウェアの更新処理の案内通知を前記表示デバイスから出力し始めた後の前記視認判断処理において、前記表示デバイスに表示している案内通知についての前記車両の乗員による視認期間に基づいて、前記車両の乗員が案内通知を視認していることを判断する、
請求項３記載の、車両のソフトウェア更新装置。
前記更新制御装置は、
前記車両のソフトウェアの更新処理の案内通知を前記表示デバイスから出力し始めた後の前記視認判断処理において、前記表示デバイスに表示している案内通知についての前記車両の乗員による視認期間に基づいて、前記車両の乗員が案内通知を視認していることを判断する、
請求項３記載の、車両のソフトウェア更新装置。
【請求項5】
前記更新制御装置は、
前記車両に前記管理者が乗車しているか否かを再度判断する乗車再判断処理を実行し、
前記乗車再判断処理において管理者が乗車していると判断する場合には、管理者による承諾入力を許可し、
前記乗車再判断処理において管理者が乗車していると判断しない場合には、前記車両のソフトウェアの更新処理の案内通知出力を止めて、前記車両のソフトウェアを更新するための処理を中断する、
請求項４記載の、車両のソフトウェア更新装置。
前記車両に前記管理者が乗車しているか否かを再度判断する乗車再判断処理を実行し、
前記乗車再判断処理において管理者が乗車していると判断する場合には、管理者による承諾入力を許可し、
前記乗車再判断処理において管理者が乗車していると判断しない場合には、前記車両のソフトウェアの更新処理の案内通知出力を止めて、前記車両のソフトウェアを更新するための処理を中断する、
請求項４記載の、車両のソフトウェア更新装置。
【請求項6】
前記更新制御装置は、
管理者から承諾の入力がある場合には、前記車両のソフトウェアを更新するための処理を実行し、
管理者から承諾の入力がない場合には、前記車両のソフトウェアを更新するための処理を中断する、
請求項５記載の、車両のソフトウェア更新装置。
管理者から承諾の入力がある場合には、前記車両のソフトウェアを更新するための処理を実行し、
管理者から承諾の入力がない場合には、前記車両のソフトウェアを更新するための処理を中断する、
請求項５記載の、車両のソフトウェア更新装置。
【請求項7】
前記更新制御装置は、前記車両のソフトウェアを更新するための処理を、
前記車両において更新のためのソフトウェアを取得する処理を実行する場合、
前記車両に取得しているソフトウェアを前記車両に展開する処理、および、
前記車両に展開したソフトウェアの実行へ切り替える処理、の複数の段階に分けて、各段階の実行の前に、前記車両のソフトウェアの更新処理の案内通知を出力する、
請求項６記載の、車両のソフトウェア更新装置。
前記車両において更新のためのソフトウェアを取得する処理を実行する場合、
前記車両に取得しているソフトウェアを前記車両に展開する処理、および、
前記車両に展開したソフトウェアの実行へ切り替える処理、の複数の段階に分けて、各段階の実行の前に、前記車両のソフトウェアの更新処理の案内通知を出力する、
請求項６記載の、車両のソフトウェア更新装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、車両のソフトウェア更新装置に関する。
【背景技術】
【0002】
特許文献１～３は、このように車両で用いられるソフトウェアを更新する際に、自動車の乗員に対してそれを通知することを開示する。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開 ２０２１－１２８３６２号公報
【特許文献2】特開２０１８－８６８９４号公報
【特許文献3】特開２０１７－９７６２０号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
ところで、特許文献１～３では、車両の走行停止などの走行状態を判断し、たとえば駐停車中においてソフトウェアの更新を通知している。
これにより、車両で用いるソフトウェアは、製造後の車両においても更新することができる。車両で用いるソフトウェアは、改善したり、機能追加したり、できるようになる。
これにより、車両で用いるソフトウェアは、製造後の車両においても更新することができる。車両で用いるソフトウェアは、改善したり、機能追加したり、できるようになる。
【0005】
ただし、特許文献１～３のような通知の仕方では、車両の駐停車中に、車両に乗車している乗員に対して、ソフトウェアの更新処理についての通知がなされることになる。
その一方で、車両は、一般的に、その車両を購入などした人のみが使用するものではない。たとえば、会社が購入した車両を従業員が使用する場合、家長が購入した車両を扶養家族が使用する場合などの例が挙げられる。
そして、上述した特許文献１～３では、これらの車両の管理者以外の人が乗車している場合でも、車両の駐停車中においてソフトウェアの更新を通知してしまう。
この際、通知を受けた管理者以外の乗員が、ソフトウェアの更新についての承認操作をしてしまうと、車両のソフトウェアが更新されてしまうことになる。
車両の管理者以外の人が車両のソフトウェアを更新してしまうと、車両の管理者は、車両を管理し難しくなる可能性がある。車両の管理者は、ソフトウェアが更新された車両と、ソフトウェアが更新されていない車両とを、特段の確認作業をすることなしに判別することは難しい。したがって、車両の管理者は、車両のソフトウェアが更新されたことについて気づきにくい。
その一方で、車両は、一般的に、その車両を購入などした人のみが使用するものではない。たとえば、会社が購入した車両を従業員が使用する場合、家長が購入した車両を扶養家族が使用する場合などの例が挙げられる。
そして、上述した特許文献１～３では、これらの車両の管理者以外の人が乗車している場合でも、車両の駐停車中においてソフトウェアの更新を通知してしまう。
この際、通知を受けた管理者以外の乗員が、ソフトウェアの更新についての承認操作をしてしまうと、車両のソフトウェアが更新されてしまうことになる。
車両の管理者以外の人が車両のソフトウェアを更新してしまうと、車両の管理者は、車両を管理し難しくなる可能性がある。車両の管理者は、ソフトウェアが更新された車両と、ソフトウェアが更新されていない車両とを、特段の確認作業をすることなしに判別することは難しい。したがって、車両の管理者は、車両のソフトウェアが更新されたことについて気づきにくい。
【0006】
このように車両のソフトウェアの更新では、車両の管理者がその更新を適切に管理できるようにすることが望まれる。
【課題を解決するための手段】
【0007】
本発明の一形態に係る車両のソフトウェア更新装置は、車両で用いられるソフトウェアを更新するために前記車両に設けられる、車両のソフトウェア更新装置であって、前記車両のソフトウェアを更新する処理を実行する更新制御装置、前記車両に設けられる出力デバイスを制御する入出力制御装置、および、前記車両の管理者の端末デバイスと通信可能な通信制御装置、を有し、前記更新制御装置は、前記車両のソフトウェアを更新するための処理を実行する前に、前記車両に前記管理者が乗車しているか否かを判断する乗車判断処理、を実行し、前記乗車判断処理において管理者が乗車していると判断する場合には、前記入出力制御装置を通じて、前記車両に設けられる前記出力デバイスから、前記車両のソフトウェアの更新処理の案内通知を出力し、前記乗車判断処理において管理者が乗車していないと判断する場合には、前記通信制御装置を通じて、前記車両の管理者の端末デバイスから、前記車両のソフトウェアの更新処理の案内通知を出力し、前記車両のソフトウェアの更新処理の案内通知を出力した後に、前記車両のソフトウェアを更新するための処理を実行する、ものである。
【発明の効果】
【0008】
本発明では、車両で用いられるソフトウェアを更新するために車両に設けられる、車両のソフトウェア更新装置は、車両のソフトウェアを更新する処理を実行する更新制御装置、車両に設けられる出力デバイスを制御する入出力制御装置、および、車両の管理者の端末デバイスと通信可能な通信制御装置、を有する。そして、更新制御装置は、車両のソフトウェアを更新するための処理を実行する前に、車両に管理者が乗車しているか否かを判断する乗車判断処理、を実行する。
また、更新制御装置は、乗車判断処理において管理者が乗車していると判断する場合には、入出力制御装置を通じて、車両に設けられる出力デバイスから、車両のソフトウェアの更新処理の案内通知を出力する。これに対し、乗車判断処理において管理者が乗車していないと判断する場合には、更新制御装置は、通信制御装置を通じて、車両の管理者の端末デバイスから、車両のソフトウェアの更新処理の案内通知を出力する。これらの車両のソフトウェアの更新処理の案内通知を出力した後に、更新制御装置は、車両のソフトウェアを更新するための処理を実行する。
これにより、たとえば車両に管理者以外の乗員が乗車している場合には、その車両において、車両のソフトウェアの更新処理の案内通知を出力しないようにできる。車両の管理者以外の乗員は、車両のソフトウェアを更新しないようにできる。しかも、本発明では、車両に管理者以外の乗員が乗車している場合には、その更新通知を止めるのではなく、車両の管理者の端末デバイスに、車両のソフトウェアの更新処理の案内通知を出力する。したがって、車両のソフトウェアを更新可能な場合には、車両の管理者は、その車両を使用していなくても、その更新の通知を受けて、車両のソフトウェアを即時的に更新することが可能である。
その結果、車両の管理者は、たとえば、それ以外の人が車両のソフトウェアを更新してしまうことがなくなり、車両を容易に管理することができる。また、車両の管理者は、自らに通知がされることにより、車両のソフトウェアが更新されたことを把握できる。車両の管理者は、ソフトウェアが更新された車両と、ソフトウェアが更新されていない車両とを、特段の作業をすることなしに容易に判別することができる。車両の管理者は、車両のソフトウェアの更新を適切に管理することができる。
このように、本発明では、車両のソフトウェアの更新について、車両の管理者がその更新を適切に管理できるように改善することができる。
また、更新制御装置は、乗車判断処理において管理者が乗車していると判断する場合には、入出力制御装置を通じて、車両に設けられる出力デバイスから、車両のソフトウェアの更新処理の案内通知を出力する。これに対し、乗車判断処理において管理者が乗車していないと判断する場合には、更新制御装置は、通信制御装置を通じて、車両の管理者の端末デバイスから、車両のソフトウェアの更新処理の案内通知を出力する。これらの車両のソフトウェアの更新処理の案内通知を出力した後に、更新制御装置は、車両のソフトウェアを更新するための処理を実行する。
これにより、たとえば車両に管理者以外の乗員が乗車している場合には、その車両において、車両のソフトウェアの更新処理の案内通知を出力しないようにできる。車両の管理者以外の乗員は、車両のソフトウェアを更新しないようにできる。しかも、本発明では、車両に管理者以外の乗員が乗車している場合には、その更新通知を止めるのではなく、車両の管理者の端末デバイスに、車両のソフトウェアの更新処理の案内通知を出力する。したがって、車両のソフトウェアを更新可能な場合には、車両の管理者は、その車両を使用していなくても、その更新の通知を受けて、車両のソフトウェアを即時的に更新することが可能である。
その結果、車両の管理者は、たとえば、それ以外の人が車両のソフトウェアを更新してしまうことがなくなり、車両を容易に管理することができる。また、車両の管理者は、自らに通知がされることにより、車両のソフトウェアが更新されたことを把握できる。車両の管理者は、ソフトウェアが更新された車両と、ソフトウェアが更新されていない車両とを、特段の作業をすることなしに容易に判別することができる。車両の管理者は、車両のソフトウェアの更新を適切に管理することができる。
このように、本発明では、車両のソフトウェアの更新について、車両の管理者がその更新を適切に管理できるように改善することができる。
【図面の簡単な説明】
【0009】
【発明を実施するための形態】
【0010】
以下、本発明の実施形態について、図面に基づいて説明する。
【0011】
図１は、本発明の実施形態に係るソフトウェア更新装置が適用可能な自動車のソフトウェア更新システム１の一例の模式的な説明図である。
図１において、ソフトウェア更新システム１は、サーバ装置２、自動車４、を有する。サーバ装置２には、データベース３が接続されている。データベース３には、自動車に適用する更新用のソフトウェアなどが記録されてよい。
図１において、ソフトウェア更新システム１は、サーバ装置２、自動車４、を有する。サーバ装置２には、データベース３が接続されている。データベース３には、自動車に適用する更新用のソフトウェアなどが記録されてよい。
【0012】
サーバ装置２は、通信網５、中継装置７を通じて、複数の基地局８と接続されている。複数の基地局８は、道路９に沿って並べて設けられている。基地局８や中継装置７は、５Ｇ通信用のものでも、ＡＤＡＳ（Ａｄｖａｎｃｅｄ Ｄｒｉｖｅｒ－Ａｓｓｉｓｔａｎｃｅ Ｓｙｓｔｅｍｓ）やＩＴＳ（Ｉｎｔｅｌｌｉｇｅｎｔ Ｔｒａｎｓｐｏｒｔ Ｓｙｓｔｅｍｓ）のためのものでも、よい。通信網５は、キャリア通信網や、所謂インターネットにより、構成されてよい。
【0013】
自動車４は、所有者の自宅敷地１０の駐車場に駐車している。自動車４は、車両の一例である。車両には、この他にもたとえば、バス、トラック、モータサイクル、パーソナルモビリティ、などがある。
自動車４には、所有者などの乗員が乗車し、乗員の目的地まで走行する。図１に破線で示すように、自動車４は、自宅敷地１０の駐車場から道路９へ出て、道路９の車線を走行する。
自動車４には、所有者などの乗員が乗車し、乗員の目的地まで走行する。図１に破線で示すように、自動車４は、自宅敷地１０の駐車場から道路９へ出て、道路９の車線を走行する。
【0014】
また、図１には、道路９の傍に、端末デバイス１２を所持する歩行者１１がいる。端末デバイス１２には、たとえば、携帯端末、タブレット端末、ウェアラブル端末、などがある。また、歩行者１１が自動車４の所有者などの管理者である場合、端末デバイス１２は、自動車４キーであってもよい。以下において、管理者が所持する端末デバイス１２を、管理者端末（１２）という。端末デバイス１２や自動車４は、道路９に沿って設けられる基地局８との間で無線通信路を確立して、サーバ装置２などとの間で双方向の通信を実行することが可能である。
【0015】
図２は、図１の自動車４の制御系２０の一例の説明図である。
図２の自動車４の制御系２０は、車ネットワーク２８と、それに接続される複数の制御装置と、を有する。図２には、複数の制御装置として、検出制御装置２１、走行制御装置２２、空調制御装置２３、入出力制御装置２４、通信制御装置２５、操作制御装置２６、更新制御装置２７、が例示されている。
図２の自動車４の制御系２０は、車ネットワーク２８と、それに接続される複数の制御装置と、を有する。図２には、複数の制御装置として、検出制御装置２１、走行制御装置２２、空調制御装置２３、入出力制御装置２４、通信制御装置２５、操作制御装置２６、更新制御装置２７、が例示されている。
【0016】
ここで、車ネットワーク２８は、自動車４で採用される例えばＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）やＬＩＮ（Ｌｏｃａｌ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｎｅｔｗｏｒｋ）、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＦｌｅｘＲａｙ、ＣＸＰＩ（Ｃｌｏｃｋ Ｅｘｔｅｎｓｉｏｎ Ｐｅｒｉｐｈｅｒａｌ Ｉｎｔｅｒｆａｃｅ）といったものでよい。複数の制御装置は、車ネットワーク２８を通じて相互にメッセージを送受できる。これにより、複数の制御装置は、協働して自動車４を制御することができる。
【0017】
入出力制御装置２４は、自動車４のユーザインタフェースデバイスが接続される。自動車４のユーザインタフェースデバイスには、たとえば不図示のダッシュボードに設けられる表示デバイス３８、スイッチ、スピーカ４０、マイクロホン４１、などがある。表示デバイス３８は、画像を表示する出力デバイスである。表示デバイス３８は、その表示面にタッチパネルが重ねられてもよい。タッチパネルやスイッチは、乗員により操作される操作デバイス（入力デバイス）３９である。スピーカ４０は、乗員に対して音声などの音を出力する音出力デバイスである。マイクロホン４１は、乗員の発声を検出する音入力デバイスである。
また、ユーザインタフェースデバイスには、不図示のＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）コネクタなどが併設されてもよい。ＵＳＢコネクタには、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）や不揮発性の半導体メモリを用いたＵＳＢメモリを接続することができる。ＵＳＢメモリには、自動車４で使用するプログラム、データなどを記録することができる。
そして、入出力制御装置２４は、接続されているユーザインタフェースデバイスの動作を制御し、乗員に対して画像や音声などを出力し、乗員の入力操作や発声を検出する。入出力制御装置２４は、自動車４に設けられる出力デバイスおよび入力デバイスを制御することができる。
入出力制御装置２４、表示デバイス３８、および操作デバイス３９は、乗員に対して情報を表示するとともに表示に対する操作を受け付けるヘッドユニット７４として機能してよい。
また、ユーザインタフェースデバイスには、不図示のＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）コネクタなどが併設されてもよい。ＵＳＢコネクタには、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）や不揮発性の半導体メモリを用いたＵＳＢメモリを接続することができる。ＵＳＢメモリには、自動車４で使用するプログラム、データなどを記録することができる。
そして、入出力制御装置２４は、接続されているユーザインタフェースデバイスの動作を制御し、乗員に対して画像や音声などを出力し、乗員の入力操作や発声を検出する。入出力制御装置２４は、自動車４に設けられる出力デバイスおよび入力デバイスを制御することができる。
入出力制御装置２４、表示デバイス３８、および操作デバイス３９は、乗員に対して情報を表示するとともに表示に対する操作を受け付けるヘッドユニット７４として機能してよい。
【0018】
検出制御装置２１には、自動車４に設けられる各種のセンサが接続される。図では、複数のセンサとして、車内カメラ３０、車内Ｌｉｄａｒ３１、車内赤外線センサ３２、着座センサ３３、シート位置センサ３４、温度センサ３５、ＧＮＳＳ（Ｇｌｏｂａｌ Ｎａｖｉｇａｔｉｏｎ Ｓａｔｅｌｌｉｔｅ Ｓｙｓｔｅｍ）受信機３６、加速度センサ３７、が例示されている。
車内カメラ３０は、自動車４の車室内を撮像するカメラである。車内カメラ３０の撮像画像には、自動車４に乗車している乗員の画像成分が含まれ得る。撮像画像には、乗員の頭部、顔、目などについての成分が含まれ得る。
車内Ｌｉｄａｒ３１は、自動車４の車室内をレーザ走査する。車内Ｌｉｄａｒ３１の操作の結果として得られる車内の空間情報には、自動車４に乗車している乗員による成分が含まれ得る。車内の空間情報には、乗員の頭部、顔、目などについての成分が含まれ得る。
車内赤外線センサ３２は、自動車４の車室内を赤外線で検出する。車内赤外線センサ３２による検出情報には、自動車４に乗車している乗員による成分が含まれ得る。
着座センサ３３は、自動車４の車室に設けられる不図示のドライバ用シートなどに乗員が着座しているか否かを検出できる。シート位置センサ３４は、ドライバ用シートなどのシート位置を検出できる。着座センサ３３やシート位置センサ３４の検出値は、ドライバ用シートに着座している乗員の体格に応じて異なり得る。
温度センサ３５は、自動車４の車室にいる乗員の体温などを検出できる。
ＧＮＳＳ受信機３６は、図１に示すＧＮＳＳ衛星１０１からの電波を受信し、自動車４の現在位置および現在時刻の情報を生成する。
加速度センサ３７は、たとえば三軸のものでよい。三軸の加速度センサ３７は、自動車４のピッチ、ロール、ヨーの各方向での加速度を検出できる。
車輪速センサ４７は、自動車４の不図示の車輪の速度を検出する。自動車４が駐停車により停止している場合、車輪速センサ４７の検出値は、速度「０」となる。
そして、検出制御装置２１は、各センサの動作を制御し、各センサから検出値などの検出情報を取得する。また、検出制御装置２１は、他の制御装置から、たとえば後述する操作制御装置からシフトセンサ４４の検出値を取得してもよい。検出制御装置２１は、検出情報から、他の情報を生成してもよい。
たとえば、検出制御装置２１は、車内カメラ３０による車内の撮像画像、車内Ｌｉｄａｒ３１による車内の空間情報、車内赤外線センサ３２の車内の検出情報、などに基づいて、自動車４のドライバ用シートなどに着座している乗員についての識別処理を実行してよい。また、検出制御装置２１は、車内カメラ３０による車内の撮像画像などに基づいて、識別した乗員の顔や目の画像成分に基づいて、乗員の視線方向や目の開き具合についての判定処理を実行してよい。これらの識別や判定には、乗員について既に登録されている画像などを用いてよい。このような処理を実行する検出制御装置２１は、ＤＭＳ（Ｄｒｉｖｅｒ Ｍｏｎｉｔｏｒｉｎｇ Ｓｙｓｔｅｍ）７３として機能することができる。
なお、車内カメラ３０、車内Ｌｉｄａｒ３１、赤外線センサなどは、表示デバイス３８の近くに配置されてよい。この場合、たとえば車内カメラ３０は、表示デバイス３８へ向いている乗員の顔を、略正面から撮像することができる。乗員の視線が表示デバイス３８へ向いている場合に、それを確からしく撮像することができる。
車内カメラ３０は、自動車４の車室内を撮像するカメラである。車内カメラ３０の撮像画像には、自動車４に乗車している乗員の画像成分が含まれ得る。撮像画像には、乗員の頭部、顔、目などについての成分が含まれ得る。
車内Ｌｉｄａｒ３１は、自動車４の車室内をレーザ走査する。車内Ｌｉｄａｒ３１の操作の結果として得られる車内の空間情報には、自動車４に乗車している乗員による成分が含まれ得る。車内の空間情報には、乗員の頭部、顔、目などについての成分が含まれ得る。
車内赤外線センサ３２は、自動車４の車室内を赤外線で検出する。車内赤外線センサ３２による検出情報には、自動車４に乗車している乗員による成分が含まれ得る。
着座センサ３３は、自動車４の車室に設けられる不図示のドライバ用シートなどに乗員が着座しているか否かを検出できる。シート位置センサ３４は、ドライバ用シートなどのシート位置を検出できる。着座センサ３３やシート位置センサ３４の検出値は、ドライバ用シートに着座している乗員の体格に応じて異なり得る。
温度センサ３５は、自動車４の車室にいる乗員の体温などを検出できる。
ＧＮＳＳ受信機３６は、図１に示すＧＮＳＳ衛星１０１からの電波を受信し、自動車４の現在位置および現在時刻の情報を生成する。
加速度センサ３７は、たとえば三軸のものでよい。三軸の加速度センサ３７は、自動車４のピッチ、ロール、ヨーの各方向での加速度を検出できる。
車輪速センサ４７は、自動車４の不図示の車輪の速度を検出する。自動車４が駐停車により停止している場合、車輪速センサ４７の検出値は、速度「０」となる。
そして、検出制御装置２１は、各センサの動作を制御し、各センサから検出値などの検出情報を取得する。また、検出制御装置２１は、他の制御装置から、たとえば後述する操作制御装置からシフトセンサ４４の検出値を取得してもよい。検出制御装置２１は、検出情報から、他の情報を生成してもよい。
たとえば、検出制御装置２１は、車内カメラ３０による車内の撮像画像、車内Ｌｉｄａｒ３１による車内の空間情報、車内赤外線センサ３２の車内の検出情報、などに基づいて、自動車４のドライバ用シートなどに着座している乗員についての識別処理を実行してよい。また、検出制御装置２１は、車内カメラ３０による車内の撮像画像などに基づいて、識別した乗員の顔や目の画像成分に基づいて、乗員の視線方向や目の開き具合についての判定処理を実行してよい。これらの識別や判定には、乗員について既に登録されている画像などを用いてよい。このような処理を実行する検出制御装置２１は、ＤＭＳ（Ｄｒｉｖｅｒ Ｍｏｎｉｔｏｒｉｎｇ Ｓｙｓｔｅｍ）７３として機能することができる。
なお、車内カメラ３０、車内Ｌｉｄａｒ３１、赤外線センサなどは、表示デバイス３８の近くに配置されてよい。この場合、たとえば車内カメラ３０は、表示デバイス３８へ向いている乗員の顔を、略正面から撮像することができる。乗員の視線が表示デバイス３８へ向いている場合に、それを確からしく撮像することができる。
【0019】
通信制御装置２５には、通信デバイス４６が接続される。
通信デバイス４６は、車外のたとえば基地局８との間で無線通信路を確立し、確立している無線通信路を通じてサーバ装置２や管理者端末（１２）を含む端末デバイス１２などとの間で情報を送受する。通信デバイス４６は、５Ｇ通信用のものでも、ＡＤＡＳやＩＴＳのためのものでも、よい。また、通信デバイス４６は、近距離の無線通信が可能なものであってもよい。
そして、通信制御装置２５は、通信デバイス４６の動作を制御し、サーバ装置２や管理者端末（１２）を含む端末デバイス１２などとの間での情報の送受を実行する。このような通信制御装置２５は、自動車４の管理者の管理者端末（１２）と通信可能である。
通信デバイス４６は、車外のたとえば基地局８との間で無線通信路を確立し、確立している無線通信路を通じてサーバ装置２や管理者端末（１２）を含む端末デバイス１２などとの間で情報を送受する。通信デバイス４６は、５Ｇ通信用のものでも、ＡＤＡＳやＩＴＳのためのものでも、よい。また、通信デバイス４６は、近距離の無線通信が可能なものであってもよい。
そして、通信制御装置２５は、通信デバイス４６の動作を制御し、サーバ装置２や管理者端末（１２）を含む端末デバイス１２などとの間での情報の送受を実行する。このような通信制御装置２５は、自動車４の管理者の管理者端末（１２）と通信可能である。
【0020】
走行制御装置２２は、自動車４の走行を制御する。走行制御装置２２は、ドライバ用シートに着座している乗員による操作にしたがって自動車４の走行を制御しても、ドライバによらないで自動的に自動車４の走行を制御しても、よい。また、走行制御装置２２は、ドライバによる操作を支援して、自動車４の走行を制御してもよい。
【0021】
空調制御装置２３は、乗員の設定などに基づいて、自動車４において乗員が乗る車室の温度や湿度を制御する。
【0022】
操作制御装置２６には、自動車４の走行を操作するための不図示のステアリング、ペダル、シフトレバー、パーキングブレーキ、などの操作部材が接続される。また、操作制御装置２６には、シフトレバーの位置を検出するシフトセンサ４４、パーキングブレーキの位置を検出するパーキングブレーキセンサ４５が接続されてよい。
そして、操作制御装置２６は、操作部材に対する乗員の操作を検出する。
たとえば、操作制御装置２６は、シフトセンサ４４からシフトレバーが操作されている位置を検出したり、パーキングブレーキセンサ４５からパーキングブレーキが操作されている位置を検出したりしてよい。
そして、操作制御装置２６は、操作部材に対する乗員の操作を検出する。
たとえば、操作制御装置２６は、シフトセンサ４４からシフトレバーが操作されている位置を検出したり、パーキングブレーキセンサ４５からパーキングブレーキが操作されている位置を検出したりしてよい。
【0023】
更新制御装置２７は、自動車４で用いられるソフトウェアを更新するために自動車４に設けられる装置である。
【0024】
このように自動車４の制御系２０は、更新制御装置２７、入出力制御装置２４、通信制御装置２５などを有し、自動車４のソフトウェア更新装置として機能し得る。
【0025】
図３は、自動車の制御系に用いられる制御装置５０の基本的な構成の説明図である。
図２に示す各種の制御装置５０は、基本的に図３の構造を備えてよい。
図３の制御装置５０は、内通信部５１、タイマ５２、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）５３、メモリ５４、およびこれらが接続される内部バス５５、を有する。
図２に示す各種の制御装置５０は、基本的に図３の構造を備えてよい。
図３の制御装置５０は、内通信部５１、タイマ５２、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）５３、メモリ５４、およびこれらが接続される内部バス５５、を有する。
【0026】
内通信部５１は、車ネットワーク２８に接続される。内通信部５１は、車ネットワーク２８に接続されている他の制御装置との間で情報を送受する。
タイマ５２は、時間および時刻を計測する。タイマ５２の時刻は、ＧＮＳＳ受信機３６が生成する時刻により校正されてよい。
ＣＰＵ５３は、メモリ５４に記録されているプログラムを読み込んで実行する。これにより、ＣＰＵ５３は、制御装置５０の制御部として機能する。
メモリ５４は、ＨＤＤ、不揮発性半導体メモリ、ＲＡＭなどで構成されてよい。メモリ５４は、ＣＰＵ５３が実行するプログラム５６、およびＣＰＵ５３がプログラム５６を実行するために使用する設定値５７、パラメータ５８、テーブル５９などの各種のデータを記録する。メモリ５４には、ＣＰＵ５３がプログラム５６実行に用いるワークエリアが割り当てられてよい。
ここで、ソフトウェアは、プログラム５６だけでなく、ＣＰＵ５３がプログラム５６を実行するために使用する設定値５７、パラメータ５８、テーブル５９などの各種のデータを含んでよい。
このように、自動車４の制御系２０に設けられる各種の制御装置５０は、メモリ５４に記録されているプログラム５６をＣＰＵ５３が実行することにより、各々の制御を実現している。
タイマ５２は、時間および時刻を計測する。タイマ５２の時刻は、ＧＮＳＳ受信機３６が生成する時刻により校正されてよい。
ＣＰＵ５３は、メモリ５４に記録されているプログラムを読み込んで実行する。これにより、ＣＰＵ５３は、制御装置５０の制御部として機能する。
メモリ５４は、ＨＤＤ、不揮発性半導体メモリ、ＲＡＭなどで構成されてよい。メモリ５４は、ＣＰＵ５３が実行するプログラム５６、およびＣＰＵ５３がプログラム５６を実行するために使用する設定値５７、パラメータ５８、テーブル５９などの各種のデータを記録する。メモリ５４には、ＣＰＵ５３がプログラム５６実行に用いるワークエリアが割り当てられてよい。
ここで、ソフトウェアは、プログラム５６だけでなく、ＣＰＵ５３がプログラム５６を実行するために使用する設定値５７、パラメータ５８、テーブル５９などの各種のデータを含んでよい。
このように、自動車４の制御系２０に設けられる各種の制御装置５０は、メモリ５４に記録されているプログラム５６をＣＰＵ５３が実行することにより、各々の制御を実現している。
【0027】
ところで、自動車４で用いるプログラム５６といったソフトウェアは、基本的には自動車４の製造時において自動車４に固定化されているものであるが、その後に更新できるようにすることで、改善したり、機能追加したり、することが可能になる。
【0028】
図４は、図１のサーバ装置２と自動車４の制御系２０との連携により自動車４のソフトウェアを更新する制御の一例のタイミングチャートである。
図４には、自動車４の制御系２０に設けられる更新制御装置２７、サーバ装置２、および、サーバ装置２に接続されるデータベース３、が記載されている。データベース３には、自動車４で用いることができる更新用のソフトウェアが記録されている。更新用のソフトウェアは、自動車４の制御系２０に設けられる１つの制御装置の制御についてのものであっても、複数の制御装置の制御についてのものであっても、よい。
そして、図４において、時間は、上から下へ流れる。
図４には、自動車４の制御系２０に設けられる更新制御装置２７、サーバ装置２、および、サーバ装置２に接続されるデータベース３、が記載されている。データベース３には、自動車４で用いることができる更新用のソフトウェアが記録されている。更新用のソフトウェアは、自動車４の制御系２０に設けられる１つの制御装置の制御についてのものであっても、複数の制御装置の制御についてのものであっても、よい。
そして、図４において、時間は、上から下へ流れる。
【0029】
ステップＳＴ１において、自動車４の制御系２０に設けられる更新制御装置２７は、通信制御装置２５および通信デバイス４６を用いて、サーバ装置２との通信を開始する。たとえば、更新制御装置２７は、それが設けられる自動車４についての未適用の新たな更新用のソフトウェアが、データベース３に記録されているか否かを、サーバ装置２に問い合わせる。サーバ装置２は、データベース３を探索し、探索結果を更新制御装置２７へ返信する。探索結果には、未適用の更新用のソフトウェアの有無、未適用の更新用のソフトウェアについての情報などが含まれてよい。
【0030】
未適用の更新用のソフトウェアがある場合、更新制御装置２７は、ステップＳＴ２において、未適用の更新用のソフトウェアをダウンロードにより取得する。たとえば、更新制御装置２７は、更新用のソフトウェアのダウンロード要求を、サーバ装置２へ送信する。サーバ装置２は、要求に係る更新用のソフトウェアを、データベース３から取得し、更新制御装置２７へ送信する。これにより、更新制御装置２７は、自車に未適用の更新用のソフトウェアを取得できる。
【0031】
ステップＳＴ３において、更新制御装置２７は、ダウンロードにより取得した更新用のソフトウェアを、メモリ５４に記録する。ここでのメモリ５４は、更新制御装置２７のものでも、更新用のソフトウェアを適用する他の制御装置のものでもよい。
【0032】
ステップＳＴ４において、更新制御装置２７は、メモリ５４に記録した更新用のソフトウェアを、それが適用される制御装置５０のメモリ５４に展開する。これにより、更新用のソフトウェアは、それが適用される制御装置５０において実行可能な状態になる。
【0033】
ステップＳＴ５において、更新制御装置２７は、制御装置５０のメモリ５４に展開したソフトウェアについてのアクティベーションを実行する。これにより、更新用のソフトウェアが適用される制御装置５０のＣＰＵ５３は、そのメモリ５４に展開されているソフトウェアを用いた制御を開始する。
【0034】
これにより、自動車４で用いるソフトウェアは、更新される。
ただし、自動車４のソフトウェアの更新は、基本的に自動車４の走行中に実行しないことが望まれる。自動車４の走行中に、ＣＰＵ５３が実行するプログラム５６や、プログラム５６の実行に使用する設定値５７、パラメータ５８が変更されてしまうことは、望ましいことではない。
ただし、自動車４のソフトウェアの更新は、基本的に自動車４の走行中に実行しないことが望まれる。自動車４の走行中に、ＣＰＵ５３が実行するプログラム５６や、プログラム５６の実行に使用する設定値５７、パラメータ５８が変更されてしまうことは、望ましいことではない。
【0035】
また、自動車４のソフトウェアの更新が自動車４の駐停車中に乗員に通知されて、その乗員が承諾することによりなされてしまうと、自動車４の管理などの面において管理者にとって望ましくない状況が生じ得る。たとえば、自動車４は、一般的に、その自動車４を購入などした人のみが使用するものではない。たとえば、会社が購入した自動車４を従業員が使用する場合、家長が購入した自動車４を扶養家族が使用する場合などの例が挙げられる。通知を受けた管理者以外の乗員が、ソフトウェアの更新についての承諾操作をしてしまうと、自動車４のソフトウェアは更新される。自動車４の管理者以外の人が自動車４のソフトウェアを更新してしまうと、自動車４の管理者は、自動車４を管理し難しくなる可能性がある。自動車４の管理者は、ソフトウェアが更新された自動車４と、ソフトウェアが更新されていない自動車４とを、特段の確認作業をすることなしに判別することは難しい。したがって、自動車４の管理者は、自動車４のソフトウェアが更新されたことについて気づきにくい。このように自動車４のソフトウェアの更新では、自動車４の管理者がその更新を適切に管理できるようにすることが望まれる。
【0036】
このように自動車４で用いるソフトウェアの更新には、改善が望まれる。
【0037】
次に、本実施形態での、自動車４で用いるソフトウェアの更新方法について説明する。
本実施形態では、更新制御装置２７が、サーバ装置２からソフトウェアを取得して、自動車４で用いるソフトウェアを更新する場合について説明する。
なお、自動車４で用いるソフトウェアの更新制御は、自動車４の制御系２０に設けられる他の制御装置により実行することも可能である。また、自動車４の制御系２０に設けられる複数の制御装置が協働して、ソフトウェアの更新制御を実行してもよい。
また、更新に用いるソフトウェアは、ＵＳＢメモリなどの記録媒体に記録されてもよい。
本実施形態では、更新制御装置２７が、サーバ装置２からソフトウェアを取得して、自動車４で用いるソフトウェアを更新する場合について説明する。
なお、自動車４で用いるソフトウェアの更新制御は、自動車４の制御系２０に設けられる他の制御装置により実行することも可能である。また、自動車４の制御系２０に設けられる複数の制御装置が協働して、ソフトウェアの更新制御を実行してもよい。
また、更新に用いるソフトウェアは、ＵＳＢメモリなどの記録媒体に記録されてもよい。
【0038】
図３に示すように、自動車４で用いるソフトウェアの更新制御を実行する更新制御装置２７のメモリ５４には、たとえばソフトウェアを更新する際に使用するデータとして、管理者情報６０、音出力設定値６１、端末送信情報６２、更新案内情報６３、予告案内情報６４、などが記録されてよい。
【0039】
ここで、管理者情報６０とは、自動車４の管理者についての情報である。管理者情報６０には、たとえば、管理者の顔画像、年齢、眼鏡の有無、視力の値、声の録音データ、声紋などが含まれてよい。
音出力設定値６１は、自動車４の管理者などにより設定された音出力の要否の設定値５７である。
端末送信情報６２は、管理者端末（１２）へ送信する情報である。端末送信情報６２には、管理者端末（１２）で実行されるプログラム５６が含まれてよい。ただし、管理者端末（１２）に自動車４を管理するためのプログラム５６がインストールされている場合には、端末送信情報６２は、それを起動するためのトリガ情報としてよい。
更新案内情報６３、予告案内情報６４、および、承諾通知情報は、自動車４で用いられるソフトウェアを更新する際に管理者の承諾を得るために自動車４にいる管理者へ向けて出力する情報である。
更新案内情報６３は、ソフトウェアの更新処理の内容を通知する画面の情報および音声の情報を含んでよい。ソフトウェアの更新処理の内容を通知する画面には、管理者が承諾または不承諾を選択する操作ボダンの情報が含まれてよい。
予告案内情報６４は、ソフトウェアの更新処理を予告する画面の情報を含んでよい。
音出力設定値６１は、自動車４の管理者などにより設定された音出力の要否の設定値５７である。
端末送信情報６２は、管理者端末（１２）へ送信する情報である。端末送信情報６２には、管理者端末（１２）で実行されるプログラム５６が含まれてよい。ただし、管理者端末（１２）に自動車４を管理するためのプログラム５６がインストールされている場合には、端末送信情報６２は、それを起動するためのトリガ情報としてよい。
更新案内情報６３、予告案内情報６４、および、承諾通知情報は、自動車４で用いられるソフトウェアを更新する際に管理者の承諾を得るために自動車４にいる管理者へ向けて出力する情報である。
更新案内情報６３は、ソフトウェアの更新処理の内容を通知する画面の情報および音声の情報を含んでよい。ソフトウェアの更新処理の内容を通知する画面には、管理者が承諾または不承諾を選択する操作ボダンの情報が含まれてよい。
予告案内情報６４は、ソフトウェアの更新処理を予告する画面の情報を含んでよい。
【0040】
図５は、本実施形態において図２の更新制御装置２７が実行する自動車４のソフトウェア更新制御のフローチャートである。
更新制御装置２７のＣＰＵ５３は、図５のソフトウェア更新制御を、繰り返し実行する。ＣＰＵ５３は、たとえば自動車４に乗員が乗車している場合や、自動車４が不図示のイグニションボタンを操作されて走行可能な状態にある場合に、図５のソフトウェア更新制御を、繰り返し実行してよい。
図５のステップＳＴ１からステップＳＴ５は、図４と同じである。
更新制御装置２７のＣＰＵ５３は、図５のソフトウェア更新制御を、繰り返し実行する。ＣＰＵ５３は、たとえば自動車４に乗員が乗車している場合や、自動車４が不図示のイグニションボタンを操作されて走行可能な状態にある場合に、図５のソフトウェア更新制御を、繰り返し実行してよい。
図５のステップＳＴ１からステップＳＴ５は、図４と同じである。
【0041】
更新制御装置２７のＣＰＵ５３は、ステップＳＴ１においてサーバ装置２との通信を開始した後、ステップＳＴ１１において未適用の更新用のソフトウェアがあるか否かを判断する。未適用の更新用のソフトウェアがない場合、ＣＰＵ５３は、本制御を終了する。未適用の更新用のソフトウェアがある場合、ＣＰＵ５３は、処理をステップＳＴ１２へ進める。
ステップＳＴ１２において、ＣＰＵ５３は、未適用の更新用のソフトウェアがあることを記録するために、更新フラグを「１」に更新する。更新フラグの初期値は、未適用の更新用のソフトウェアがない場合と同様の「０」でよい。更新フラグは、更新制御装置２７のメモリ５４に記録されてよい。なお、更新フラグは、後述する図６のステップＳＴ３４において「０」に更新される。
ステップＳＴ１３において、ＣＰＵ５３は、承諾フラグが「１」に更新されているか否かを判断する。承諾フラグは、更新用のソフトウェアの更新についての管理者の承諾の有無を示すものである。管理者が承諾している場合、承諾フラグは「１」に更新される。管理者が承諾していない場合、承諾フラグは「０」に更新される。承諾フラグの初期値は「０」でよい。承諾フラグは、更新制御装置２７のメモリ５４に記録されてよい。
そして、承諾フラグが「１」に更新されていない場合、ＣＰＵ５３は、ステップＳＴ１３の判断処理を繰り返す。承諾フラグが「１」に更新されると、ＣＰＵ５３は、処理をステップＳＴ２へ進める。
ステップＳＴ１２において、ＣＰＵ５３は、未適用の更新用のソフトウェアがあることを記録するために、更新フラグを「１」に更新する。更新フラグの初期値は、未適用の更新用のソフトウェアがない場合と同様の「０」でよい。更新フラグは、更新制御装置２７のメモリ５４に記録されてよい。なお、更新フラグは、後述する図６のステップＳＴ３４において「０」に更新される。
ステップＳＴ１３において、ＣＰＵ５３は、承諾フラグが「１」に更新されているか否かを判断する。承諾フラグは、更新用のソフトウェアの更新についての管理者の承諾の有無を示すものである。管理者が承諾している場合、承諾フラグは「１」に更新される。管理者が承諾していない場合、承諾フラグは「０」に更新される。承諾フラグの初期値は「０」でよい。承諾フラグは、更新制御装置２７のメモリ５４に記録されてよい。
そして、承諾フラグが「１」に更新されていない場合、ＣＰＵ５３は、ステップＳＴ１３の判断処理を繰り返す。承諾フラグが「１」に更新されると、ＣＰＵ５３は、処理をステップＳＴ２へ進める。
【0042】
ステップＳＴ２において未適用の更新用のソフトウェアをサーバ装置２からダウンロードして取得し、さらにステップＳＴ３においてそれをメモリ５４に記録した後、ＣＰＵ５３は、ステップＳＴ１４において承諾フラグを「０」に更新し、更新フラグを「１」に更新する。
ステップＳＴ１５において、ＣＰＵ５３は、承諾フラグが「１」に更新されているか否かを判断する。そして、承諾フラグが「１」に更新されていない場合、ＣＰＵ５３は、ステップＳＴ１５の判断処理を繰り返す。承諾フラグが「１」に更新されると、ＣＰＵ５３は、処理をステップＳＴ４へ進める。
ステップＳＴ１５において、ＣＰＵ５３は、承諾フラグが「１」に更新されているか否かを判断する。そして、承諾フラグが「１」に更新されていない場合、ＣＰＵ５３は、ステップＳＴ１５の判断処理を繰り返す。承諾フラグが「１」に更新されると、ＣＰＵ５３は、処理をステップＳＴ４へ進める。
【0043】
ステップＳＴ４においてメモリ５４に記録している更新用のソフトウェアを展開した後、ＣＰＵ５３は、ステップＳＴ１６において承諾フラグを「０」に更新し、更新フラグを「１」に更新する。
ステップＳＴ１７において、ＣＰＵ５３は、承諾フラグが「１」に更新されているか否かを判断する。そして、承諾フラグが「１」に更新されていない場合、ＣＰＵ５３は、ステップＳＴ１７の判断処理を繰り返す。承諾フラグが「１」に更新されると、ＣＰＵ５３は、処理をステップＳＴ５へ進める。
ステップＳＴ５において、ＣＰＵ５３は、展開している更新用のソフトウェアのアクティベーション処理を実行する。これにより、更新用のソフトウェアは、それが適用される制御装置５０のＣＰＵ５３により実行され、制御に使用される。
その後、ＣＰＵ５３は、本制御を終了する。
ステップＳＴ１７において、ＣＰＵ５３は、承諾フラグが「１」に更新されているか否かを判断する。そして、承諾フラグが「１」に更新されていない場合、ＣＰＵ５３は、ステップＳＴ１７の判断処理を繰り返す。承諾フラグが「１」に更新されると、ＣＰＵ５３は、処理をステップＳＴ５へ進める。
ステップＳＴ５において、ＣＰＵ５３は、展開している更新用のソフトウェアのアクティベーション処理を実行する。これにより、更新用のソフトウェアは、それが適用される制御装置５０のＣＰＵ５３により実行され、制御に使用される。
その後、ＣＰＵ５３は、本制御を終了する。
【0044】
このように更新制御装置２７のＣＰＵ５３は、自動車４のソフトウェアを更新するための処理を、自動車４において更新のためのソフトウェアを取得する処理を実行する場合と、自動車４に取得しているソフトウェアを自動車４に展開する処理と、自動車４に展開したソフトウェアの実行へ切り替える処理、との複数の段階に分ける。そして、ＣＰＵ５３は、各段階のソフトウェアの更新処理を実行する前に、自動車４のソフトウェアの更新処理についての承諾を得る。
【0045】
図６は、図２の更新制御装置２７による、ソフトウェア更新のための承諾制御のフローチャートである。
更新制御装置２７のＣＰＵ５３は、ＣＰＵ５３は、各段階のソフトウェアの更新処理を実行する前に、自動車４のソフトウェアの更新処理についての承諾を得るために、図６の承諾制御を、繰り返し実行する。
更新制御装置２７のＣＰＵ５３は、ＣＰＵ５３は、各段階のソフトウェアの更新処理を実行する前に、自動車４のソフトウェアの更新処理についての承諾を得るために、図６の承諾制御を、繰り返し実行する。
【0046】
ステップＳＴ２１において、ＣＰＵ５３は、更新フラグが「１」であるか否かを判断する。更新フラグは、図５に示す各段階での自動車４のソフトウェアの更新処理がある場合に、ステップＳＴ１２、ステップＳＴ１４、およびステップＳＴ１６の処理により「１」に更新される。
【0047】
ステップＳＴ２２において、ＣＰＵ５３は、事前確認処理を実行する。事前確認処理の詳細は、図７において説明する。
【0048】
ステップＳＴ２３において、ＣＰＵ５３は、メモリ５４に記録されている管理者の音出力設定値６１に基づいて、音出力の要否を判断する。これにより、ＣＰＵ５３は、設定判断処理として、視認能力判断処理の前に、自動車４において取得可能な乗員についての音出力の設定情報を取得して、音による案内通知の出力の要否を判断する処理を実行することができる。音を出力する設定値５７である場合、ＣＰＵ５３は、処理をステップＳＴ２７へ進める。音を出力しない設定値５７である場合、ＣＰＵ５３は、処理をステップＳＴ２４へ進める。
【0049】
ステップＳＴ２４において、ＣＰＵ５３は、自動車４に乗車している管理者による、自動車４のソフトウェアの更新処理の案内表示についての視認能力を判断する視認能力判断処理、を実行する。
ＣＰＵ５３は、たとえば、メモリ５４に記録されている管理者情報６０に基づいて、管理者の視認能力を判断してよい。この場合、ＣＰＵ５３は、乗員の年齢が所定の年齢、たとえば６０歳以上であるか否かに基づいて、管理者の視認能力を判断してよい。
また、ＣＰＵ５３は、車内カメラ３０の撮像画像に基づいて、管理者の視認能力を判断してよい。この場合、ＣＰＵ５３は、管理者が表示デバイス３８を視認する際に目を細める挙動をしているか否かに基づいて、管理者の視認能力を判断してよい。
ＣＰＵ５３は、たとえば、メモリ５４に記録されている管理者情報６０に基づいて、管理者の視認能力を判断してよい。この場合、ＣＰＵ５３は、乗員の年齢が所定の年齢、たとえば６０歳以上であるか否かに基づいて、管理者の視認能力を判断してよい。
また、ＣＰＵ５３は、車内カメラ３０の撮像画像に基づいて、管理者の視認能力を判断してよい。この場合、ＣＰＵ５３は、管理者が表示デバイス３８を視認する際に目を細める挙動をしているか否かに基づいて、管理者の視認能力を判断してよい。
【0050】
ステップＳＴ２５において、ＣＰＵ５３は、ステップＳＴ２４で判断した管理者の視認能力について、その有無を判断する。
ＣＰＵ５３は、たとえば、乗員の年齢が所定の年齢以上である場合、または、目を細める挙動をしている場合、視認能力が十分ではないと判断し、処理をステップＳＴ２７へ進める。ＣＰＵ５３は、音出力設定値６１に関わらず、処理をステップＳＴ２７へ進める。
ＣＰＵ５３は、これらのいずれの場合でもない場合、視認能力が十分であると判断し、処理をステップＳＴ２６へ進める。
ＣＰＵ５３は、たとえば、乗員の年齢が所定の年齢以上である場合、または、目を細める挙動をしている場合、視認能力が十分ではないと判断し、処理をステップＳＴ２７へ進める。ＣＰＵ５３は、音出力設定値６１に関わらず、処理をステップＳＴ２７へ進める。
ＣＰＵ５３は、これらのいずれの場合でもない場合、視認能力が十分であると判断し、処理をステップＳＴ２６へ進める。
【0051】
ステップＳＴ２６において、ＣＰＵ５３は、入出力制御装置２４を通じて、表示デバイス３８に、自動車４のソフトウェアの更新処理の案内通知を表示する。表示デバイス３８は、自動車４のソフトウェアの更新処理の案内通知を表示する。ここで表示デバイス３８に表示される案内表示は、上述した視認能力判断処理の判断基準において容易に視認可能な文字のサイズで、通常表示されてよい。
また、案内表示には、管理者等の乗員が承諾または不承諾を選択するための複数の操作ボタンの画像が、入力操作不能な状態で表示されてよい。
このように、ＣＰＵ５３は、設定判断処理において音による案内通知の出力が不要であると判断する場合には、視認能力判断処理の判断に基づいて、自動車４のソフトウェアの更新処理の案内通知を通常表示で出力する。
その後、ＣＰＵ５３は、処理をステップＳＴ３０へ進める。
また、案内表示には、管理者等の乗員が承諾または不承諾を選択するための複数の操作ボタンの画像が、入力操作不能な状態で表示されてよい。
このように、ＣＰＵ５３は、設定判断処理において音による案内通知の出力が不要であると判断する場合には、視認能力判断処理の判断に基づいて、自動車４のソフトウェアの更新処理の案内通知を通常表示で出力する。
その後、ＣＰＵ５３は、処理をステップＳＴ３０へ進める。
【0052】
ステップＳＴ２７において、ＣＰＵ５３は、表示デバイス３８が、たとえばナビゲーション設定などのために使用中であるか否かを判断する。表示デバイス３８が使用中である場合、ＣＰＵ５３は、本処理を繰り返し実行する。表示デバイス３８が使用中でない場合、または使用中でなくなる場合、ＣＰＵ５３は、処理をステップＳＴ２８へ進める。
【0053】
ステップＳＴ２８において、ＣＰＵ５３は、入出力制御装置２４を通じて、表示デバイス３８に、自動車４のソフトウェアの更新処理の案内通知を表示する。ＣＰＵ５３は、入出力制御装置２４を通じて、表示デバイス３８に、自動車４のソフトウェアの更新処理の案内通知を表示する際に、自動車４の乗員が表示デバイス３８を使用している場合には、表示デバイス３８の使用が終わってから、表示デバイス３８に、自動車４のソフトウェアの更新処理の案内通知を表示する。
表示デバイス３８は、自動車４のソフトウェアの更新処理の案内通知を表示する。ここで表示デバイス３８に表示される案内表示は、上述したステップＳＴ２６の通常表示より文字のサイズを大きくしたものでよい。また、文字数を削減してよい。
また、案内表示には、管理者等の乗員が承諾または不承諾を選択するための複数の操作ボタンの画像が、入力操作不能な状態で表示されてよい。
このようにＣＰＵ５３は、視認能力判断処理において乗員が案内表示を視認できる能力があると判断できない場合には、表示デバイス３８に、ステップＳＴ２６の第一の案内通知の表示と比べて視認性が高められている第二の案内通知を表示する。
表示デバイス３８は、自動車４のソフトウェアの更新処理の案内通知を表示する。ここで表示デバイス３８に表示される案内表示は、上述したステップＳＴ２６の通常表示より文字のサイズを大きくしたものでよい。また、文字数を削減してよい。
また、案内表示には、管理者等の乗員が承諾または不承諾を選択するための複数の操作ボタンの画像が、入力操作不能な状態で表示されてよい。
このようにＣＰＵ５３は、視認能力判断処理において乗員が案内表示を視認できる能力があると判断できない場合には、表示デバイス３８に、ステップＳＴ２６の第一の案内通知の表示と比べて視認性が高められている第二の案内通知を表示する。
【0054】
ステップＳＴ２９において、ＣＰＵ５３は、入出力制御装置２４を通じて、音出力デバイスから、音による案内通知を出力する。
このように、ＣＰＵ５３は、設定判断処理において音による案内通知の出力が必要であると判断する場合には、自動車４のソフトウェアの更新処理の案内通知を音により出力する。
また、ＣＰＵ５３は、視認能力判断処理の判断に基づいて、音による案内通知の出力が必要であると判断する場合には、自動車４のソフトウェアの更新処理の案内通知を音により出力する。
その後、ＣＰＵ５３は、処理をステップＳＴ３０へ進める。
このように、ＣＰＵ５３は、設定判断処理において音による案内通知の出力が必要であると判断する場合には、自動車４のソフトウェアの更新処理の案内通知を音により出力する。
また、ＣＰＵ５３は、視認能力判断処理の判断に基づいて、音による案内通知の出力が必要であると判断する場合には、自動車４のソフトウェアの更新処理の案内通知を音により出力する。
その後、ＣＰＵ５３は、処理をステップＳＴ３０へ進める。
【0055】
ステップＳＴ３０において、ＣＰＵ５３は、管理者に対する案内を終了するか否かを判断する。管理者に対する案内を終了すると判断しない場合、ＣＰＵ５３は、本処理を繰り返す。ＣＰＵ５３は、基本的に、表示デバイス３８に案内通知を表示し、音による案内通知の出力を終えると、管理者に対する案内を終了すると判断してよい。この場合、ＣＰＵ５３は、処理をステップＳＴ３１へ進める。
【0056】
ステップＳＴ３１において、ＣＰＵ５３は、管理者による自動車４のソフトウェアの更新処理についての承諾入力を可能にする。ＣＰＵ５３は、表示デバイス３８の案内表示に表示している複数の操作ボタンについて、入力操作可能な状態としてよい。これにより、管理者は、タッチパネルを操作して、自動車４のソフトウェアの更新処理についての承諾または不承諾を入力操作することができる。
【0057】
ステップＳＴ３２において、ＣＰＵ５３は、ステップＳＴ３１において管理者が入力操作したものが、自動車４のソフトウェアの更新処理についての承諾であるか否かを判断する。管理者が承諾を入力している場合、ＣＰＵ５３は、処理をステップＳＴ３３へ進める。管理者が不承諾を入力している場合、ＣＰＵ５３は、本制御を終了する。この場合、ＣＰＵ５３は、更新フラグを「１」にしたまま、かつ、承諾フラグを「０」にしたまま、本制御を終了することになる。自動車４のソフトウェアの更新処理は、実行されない。
【0058】
ステップＳＴ３３において、ＣＰＵ５３は、承諾フラグを「１」に更新する。これにより、承諾を求めていた自動車４のソフトウェアの更新処理は、実行される。
【0059】
ステップＳＴ３４において、ＣＰＵ５３は、更新フラグを「０」に更新する。その後、ＣＰＵ５３は、本制御を終了する。
【0060】
このように、ＣＰＵ５３は、図５および図６の制御により、管理者から承諾の入力を取得するために自動車４のソフトウェアの更新処理の案内通知を出力し、管理者から承諾の入力がある場合には、自動車４のソフトウェアを更新するための処理を実行する。
これに対し、管理者から承諾の入力がない場合には、ＣＰＵ５３は、今回の承諾制御においては、自動車４のソフトウェアを更新するための処理を中断することになる。
また、ＣＰＵ５３は、管理者から承諾の入力を取得する前に、管理者の視認能力を判断する。そして、視認能力が十分である場合には、ＣＰＵ５３は、音による案内通知を実行しない。ＣＰＵ５３は、視認能力が不足している場合においてのみ、音による案内通知を実行する。ＣＰＵ５３は、視認能力が十分にあるたとえば年齢が若い管理者に対して、音による案内通知を過剰に実行しないようにできる。
これに対し、管理者から承諾の入力がない場合には、ＣＰＵ５３は、今回の承諾制御においては、自動車４のソフトウェアを更新するための処理を中断することになる。
また、ＣＰＵ５３は、管理者から承諾の入力を取得する前に、管理者の視認能力を判断する。そして、視認能力が十分である場合には、ＣＰＵ５３は、音による案内通知を実行しない。ＣＰＵ５３は、視認能力が不足している場合においてのみ、音による案内通知を実行する。ＣＰＵ５３は、視認能力が十分にあるたとえば年齢が若い管理者に対して、音による案内通知を過剰に実行しないようにできる。
【0061】
図７は、図６のステップＳＴ２２の事前確認処理において図２の更新制御装置２７が実行する事前確認制御のフローチャートである。
ＣＰＵ５３は、自動車４のソフトウェアを更新するための管理者から承諾の入力を取得する前に、図７の事前確認制御を実行する。
ＣＰＵ５３は、自動車４のソフトウェアを更新するための管理者から承諾の入力を取得する前に、図７の事前確認制御を実行する。
【0062】
ステップＳＴ４１において、ＣＰＵ５３は、今回のソフトウェアの更新処理が、図５のステップＳＴ５のアクティベーションであるか否かを判断する。今回のソフトウェアの更新処理がアクティベーションである場合、ＣＰＵ５３は、処理をステップＳＴ４２へ進める。今回のソフトウェアの更新処理がアクティベーション以外である場合、ＣＰＵ５３は、処理をステップＳＴ４４へ進める。アクティベーション以外のソフトウェアの更新処理には、たとえば、図５のステップＳＴ２のソフトウェアのダウンロード処理、ステップＳＴ４のソフトウェアの展開処理、がある。
【0063】
ステップＳＴ４２において、ＣＰＵ５３は、自動車４の現在位置が、予めメモリ５４に登録されている地点であるか否かを判断する。自動車４の現在位置には、たとえばＧＮＳＳ受信機３６が生成する位置を用いてよい。
管理者は、たとえば図１のような自宅敷地１０などの位置を、予めメモリ５４に登録してよい。自動車４の現在位置が登録地点でない場合、ＣＰＵ５３は、本処理を繰り返す。自動車４の現在位置が登録地点になると、ＣＰＵ５３は、処理をステップＳＴ４３へ進める。
管理者は、たとえば図１のような自宅敷地１０などの位置を、予めメモリ５４に登録してよい。自動車４の現在位置が登録地点でない場合、ＣＰＵ５３は、本処理を繰り返す。自動車４の現在位置が登録地点になると、ＣＰＵ５３は、処理をステップＳＴ４３へ進める。
【0064】
ステップＳＴ４３において、ＣＰＵ５３は、自動車４の現在時刻が、予めメモリ５４に登録されている時間帯であるか否かを判断する。管理者は、たとえば自動車４を使用する頻度が低い時間帯、たとえば夜間の時間帯を、予めメモリ５４に登録してよい。自動車４の現在時刻が登録時間帯でない場合、ＣＰＵ５３は、処理をステップＳＴ４２へ戻す。自動車４の現在時刻が登録時間帯になると、ＣＰＵ５３は、処理をステップＳＴ４４へ進める。この場合、自動車４は、登録時間帯において登録地点にいることになる。
【0065】
ステップＳＴ４４において、ＣＰＵ５３は、乗車判断処理として、自動車４にその管理者が乗車しているか否かを判断する。ＣＰＵ５３は、たとえば車内カメラ３０の撮像画像について乗員の抽出処理を実行し、抽出した乗員の特徴と予めメモリ５４に記録されている管理者情報６０とを照合し、それらの合致度を判定してよい。そして、管理者情報６０との合致度が閾値以上となる乗員が、撮像画像に撮像されている場合、ＣＰＵ５３は、自動車４に管理者が乗車していると判断してよい。この場合、ＣＰＵ５３は、処理をステップＳＴ４６へ進める。これに対し、管理者情報６０との合致度が閾値以上とならない乗員が、撮像画像に撮像されている場合、ＣＰＵ５３は、自動車４に管理者が乗車していないと判断してよい。この場合、ＣＰＵ５３は、処理をステップＳＴ４５へ進める。また、車内カメラ３０の撮像画像において乗員を抽出できない場合、ＣＰＵ５３は、自動車４に管理者が乗車していないと判断してよい。この場合、ＣＰＵ５３は、処理をステップＳＴ４５へ進めてよい。
【0066】
ステップＳＴ４５において、ＣＰＵ５３は、管理者端末（１２）を用いた管理者の承諾処理を実行する。ＣＰＵ５３は、たとえばソフトウェアの更新処理についての案内画面を管理者端末（１２）へ送信して表示し、それに対する管理者端末（１２）への管理者の承諾入力の情報を取得してよい。なお、管理者端末（１２）に予め自動車４を管理するためのアプリケーションプログラムがインストールされている場合、ＣＰＵ５３は、そのアプリケーションプログラムの実行指示を、管理者端末（１２）へ送信してよい。その後、ＣＰＵ５３は、処理を図５のステップＳＴ３２へ進める。ＣＰＵ５３は、管理者端末（１２）から取得した承諾に関する情報が、承諾であるか否かを判断し、承諾である場合には承諾フラグを「１」に更新する。また、ＣＰＵ５３は、ソフトウェアの更新処理を実行することができる。
【0067】
ステップＳＴ４６において、ＣＰＵ５３は、体調判断処理として、乗車判断処理において自動車４に乗車していると判断する管理者の体調を判定する。
ＣＰＵ５３は、たとえば車内カメラ３０の撮像画像について抽出している管理者の画像成分に基づいて、管理者の体調を判定してよい。管理者の体調が良い場合、管理者は、たとえばドライバ用シートに正しく着座することができる。これに対し、管理者の体調が良くない場合、管理者は、たとえばドライバ用シートに傾いて着座することがある。ＣＰＵ５３は、ドライバ用シートにおける管理者の着座姿勢に基づいて、管理者の体調を判定してよい。
ＣＰＵ５３は、車内赤外線センサ３２による管理者の検出情報に基づいて、管理者の体調を判定してよい。赤外線により管理者等の乗員を検出する場合、その検出情報には、乗員の脈拍などの体調に関する情報が含まれ得る。ＣＰＵ５３は、脈拍が正常値の範囲内であるか否かに基づいて、乗員の体調を判定してよい。
ＣＰＵ５３は、たとえば車内カメラ３０の撮像画像について抽出している管理者の画像成分に基づいて、管理者の体調を判定してよい。管理者の体調が良い場合、管理者は、たとえばドライバ用シートに正しく着座することができる。これに対し、管理者の体調が良くない場合、管理者は、たとえばドライバ用シートに傾いて着座することがある。ＣＰＵ５３は、ドライバ用シートにおける管理者の着座姿勢に基づいて、管理者の体調を判定してよい。
ＣＰＵ５３は、車内赤外線センサ３２による管理者の検出情報に基づいて、管理者の体調を判定してよい。赤外線により管理者等の乗員を検出する場合、その検出情報には、乗員の脈拍などの体調に関する情報が含まれ得る。ＣＰＵ５３は、脈拍が正常値の範囲内であるか否かに基づいて、乗員の体調を判定してよい。
【0068】
ステップＳＴ４７において、ＣＰＵ５３は、管理者の体調の良否を判断する。管理者の体調が良好である場合、ＣＰＵ５３は、処理をステップＳＴ４８へ進める。管理者の体調が良好でない場合、ＣＰＵ５３は、処理を図６へ戻す。ＣＰＵ５３は、承諾フラグを「１」に更新することなく、図６の承認処理を終了する。この場合、ＣＰＵ５３は、管理者の体調が良好とはいえない場合には、ソフトウェアの更新処理についての案内を、管理者へ通知しない。
【0069】
ステップＳＴ４８において、ＣＰＵ５３は、自動車４が走行中であるか否かを判断する。
ＣＰＵ５３は、車輪速を検出する車輪速センサ４７の検出値や、シフトレバーのシフト状態を検出するシフトセンサ４４の検出値に基づいて、自動車４が走行中であるか否かを判断してもよい。
この他にもたとえば、ＣＰＵ５３は、加速度センサ３７の検出値が「０」であるか否かに基づいて、自動車４が走行中であるか否かを判断してよい。
そして、自動車４が走行中である場合、ＣＰＵ５３は、処理をステップＳＴ４９へ進める。自動車４が走行中でない場合、ＣＰＵ５３は、処理をステップＳＴ５０へ進める。
ＣＰＵ５３は、車輪速を検出する車輪速センサ４７の検出値や、シフトレバーのシフト状態を検出するシフトセンサ４４の検出値に基づいて、自動車４が走行中であるか否かを判断してもよい。
この他にもたとえば、ＣＰＵ５３は、加速度センサ３７の検出値が「０」であるか否かに基づいて、自動車４が走行中であるか否かを判断してよい。
そして、自動車４が走行中である場合、ＣＰＵ５３は、処理をステップＳＴ４９へ進める。自動車４が走行中でない場合、ＣＰＵ５３は、処理をステップＳＴ５０へ進める。
【0070】
ステップＳＴ４９において、ＣＰＵ５３は、入出力制御装置２４を通じて、表示デバイス３８に、自動車４のソフトウェアの更新処理の予告案内通知を表示する。これにより、ＣＰＵ５３は、自動車４が走行中である場合には、自動車４のソフトウェアの更新処理の案内通知ではなく、その予告を通知表示することができる。
【0071】
ステップＳＴ５０において、ＣＰＵ５３は、自動車４が停車中であるか否かを判断する。
ＣＰＵ５３は、車輪速を検出する車輪速センサ４７の検出値や、シフトレバーのシフト状態を検出するシフトセンサ４４の検出値に基づいて、自動車４が停車中であるか否かを判断してよい。
この他にもたとえば、ＣＰＵ５３は、加速度センサ３７の検出値が「０」であるか否かに基づいて、自動車４が停車中であるか否かを判断してよい。
そして、自動車４が停車中でない場合、ＣＰＵ５３は、本処理を繰り返す。
自動車４が停車中になると、ＣＰＵ５３は、図７の事前確認制御を終了し、処理を図６のステップＳＴ２３へ進める。
ＣＰＵ５３は、車輪速を検出する車輪速センサ４７の検出値や、シフトレバーのシフト状態を検出するシフトセンサ４４の検出値に基づいて、自動車４が停車中であるか否かを判断してよい。
この他にもたとえば、ＣＰＵ５３は、加速度センサ３７の検出値が「０」であるか否かに基づいて、自動車４が停車中であるか否かを判断してよい。
そして、自動車４が停車中でない場合、ＣＰＵ５３は、本処理を繰り返す。
自動車４が停車中になると、ＣＰＵ５３は、図７の事前確認制御を終了し、処理を図６のステップＳＴ２３へ進める。
【0072】
このようにＣＰＵ５３は、図６および図７の制御により、予告案内を通知した後に自動車４が走行中でなくなった場合に、設定判断処理および視認能力判断処理を実行して、自動車４のソフトウェアの更新処理の案内通知を出力する、ことができる。
【0073】
また、ＣＰＵ５３は、乗車判断処理において管理者が乗車していると判断する場合には、自動車４が走行中ではない停車中のタイミングにおいて、入出力制御装置２４を通じて、自動車４に設けられる出力デバイスから、自動車４のソフトウェアの更新処理の案内通知を出力することができる。これに対し、自動車４に管理者が乗車していないと判断する場合には、ＣＰＵ５３は、通信制御装置２５を通じて、管理者端末（１２）から、自動車４のソフトウェアの更新処理の案内通知を出力することができる。そして、これらのソフトウェアの更新処理の案内通知を出力した後に、ＣＰＵ５３は、自動車４のソフトウェアを更新するための処理を実行することができる。
【0074】
また、ＣＰＵ５３は、体調判断処理において自動車４の管理者の体調が良であると判断する場合には、入出力制御装置２４を通じて、自動車４に設けられる出力デバイスから、自動車４のソフトウェアの更新処理の案内通知を出力する。これに対し、自動車４の管理者の体調が良でないと判断する場合には、ＣＰＵ５３は、自動車４のソフトウェアの更新処理の案内通知出力を止めて、今回の自動車４のソフトウェアの更新処理を中断する、ことができる。
【0075】
図８は、図６のステップＳＴ３０の案内終了判断処理において図２の更新制御装置２７が実行する案内終了判断制御のフローチャートである。
ＣＰＵ５３は、自動車４において入出力制御装置２４を通じて自動車４のソフトウェアの更新処理の案内通知を管理者へ向けて出力し始めた後、管理者から承諾入力を許可する前に、図８の案内終了判断制御を実行する。
ＣＰＵ５３は、自動車４において入出力制御装置２４を通じて自動車４のソフトウェアの更新処理の案内通知を管理者へ向けて出力し始めた後、管理者から承諾入力を許可する前に、図８の案内終了判断制御を実行する。
【0076】
ステップＳＴ６１において、ＣＰＵ５３は、音声による通知が終了しているか否かを判断する。管理者に視認能力がある場合、ＣＰＵ５３は、音声による通知を出力していない。また、管理者に視認能力がない場合、ＣＰＵ５３は、音声による通知を出力している。音声による通知は、所定の時間で出力し終える。このように音声による通知を出力していない場合、または、音声による通知が終了している場合、ＣＰＵ５３は、音声による通知が終了していると判断し、処理をステップＳＴ６４へ進める。これに対し、音声による通知の出力中である場合、ＣＰＵ５３は、音声による通知が終了していないと判断し、処理をステップＳＴ６２へ進める。
【0077】
ステップＳＴ６２において、ＣＰＵ５３は、視認判断処理として、自動車４に乗車している管理者による案内通知の表示についての視認状態を判定する。
ＣＰＵ５３は、たとえば、車内カメラ３０の撮像画像に基づいて、管理者の視線方向を判定することができる。管理者の視線方向が表示デバイス３８の方向である場合、ＣＰＵ５３は、案内通知の表示を視認していると判定してよい。
ＣＰＵ５３は、たとえば、車内カメラ３０の撮像画像に基づいて、管理者の視線方向を判定することができる。管理者の視線方向が表示デバイス３８の方向である場合、ＣＰＵ５３は、案内通知の表示を視認していると判定してよい。
【0078】
ステップＳＴ６３において、ＣＰＵ５３は、自動車４に乗車している管理者による案内通知の表示について視認しているか否かを判断する。
ＣＰＵ５３は、たとえば、案内通知の表示を連続的に視認している視認期間が閾値以上である場合、管理者が案内通知を認知していると判断してよい。この場合、ＣＰＵ５３は、処理をステップＳＴ６４へ進める。ＣＰＵ５３は、案内通知の出力中に繰り返される視認判断処理において管理者が通知を視認していると判断する場合には、音声による案内通知を出力し終える前でも、処理をステップＳＴ６４へ進める。
これに対し、視認期間が閾値以上となっていない場合、ＣＰＵ５３は、管理者が案内通知を認知していると判断しない。この場合、ＣＰＵ５３は、処理をステップＳＴ６１へ戻す。ＣＰＵ５３は、管理者が案内通知を認知していると判断できるようになるまで、ステップＳＴ６１からステップＳＴ６３の処理を繰り返しに実行する。
ＣＰＵ５３は、たとえば、案内通知の表示を連続的に視認している視認期間が閾値以上である場合、管理者が案内通知を認知していると判断してよい。この場合、ＣＰＵ５３は、処理をステップＳＴ６４へ進める。ＣＰＵ５３は、案内通知の出力中に繰り返される視認判断処理において管理者が通知を視認していると判断する場合には、音声による案内通知を出力し終える前でも、処理をステップＳＴ６４へ進める。
これに対し、視認期間が閾値以上となっていない場合、ＣＰＵ５３は、管理者が案内通知を認知していると判断しない。この場合、ＣＰＵ５３は、処理をステップＳＴ６１へ戻す。ＣＰＵ５３は、管理者が案内通知を認知していると判断できるようになるまで、ステップＳＴ６１からステップＳＴ６３の処理を繰り返しに実行する。
【0079】
ステップＳＴ６４において、ＣＰＵ５３は、乗車再判断処理として、自動車４に管理者が乗車しているか否かを再度判断する。
自動車４に管理者が乗車している場合、ＣＰＵ５３は、図８の案内終了判断制御を終了し、処理を図６のステップＳＴ３１へ進める。すなわち、ＣＰＵ５３は、管理者が案内通知をしている現時点においても乗車していると判断する場合には、ステップＳＴ３１において管理者による承諾入力を許可する。
これに対し、自動車４に管理者が乗車していない場合、ＣＰＵ５３は、図８の案内終了判断制御を終了し、さらに図６の制御を終了する。この場合、ＣＰＵ５３は、自動車４のソフトウェアの更新処理の案内通知の出力を止めて、今回の自動車４のソフトウェアを更新するための処理を中断する、ことになる。
自動車４に管理者が乗車している場合、ＣＰＵ５３は、図８の案内終了判断制御を終了し、処理を図６のステップＳＴ３１へ進める。すなわち、ＣＰＵ５３は、管理者が案内通知をしている現時点においても乗車していると判断する場合には、ステップＳＴ３１において管理者による承諾入力を許可する。
これに対し、自動車４に管理者が乗車していない場合、ＣＰＵ５３は、図８の案内終了判断制御を終了し、さらに図６の制御を終了する。この場合、ＣＰＵ５３は、自動車４のソフトウェアの更新処理の案内通知の出力を止めて、今回の自動車４のソフトウェアを更新するための処理を中断する、ことになる。
【0080】
このようにＣＰＵ５３は、案内通知の前後において自動車４に対するその管理者の乗車の有無を判断する。これにより、案内通知の前で管理者の乗車を判断したタイミングから時間が経過している場合でも、管理者に対して更新案内を通知することができる。
【0081】
次に、上述したソフトウェアの更新制御において表示デバイス３８に表示される各種の画面について説明する。
【0082】
【0083】
図１０は、図６のステップＳＴ２６において表示デバイス３８に表示される通常の更新案内画面８２の一例である。
通常の更新案内画面８２には、ソフトウェアの更新処理を実行すること通知するメッセージとともに、その更新処理の承諾ボタン８３と、不承諾ボタン８４と、が表示される。この時点では、承諾ボタン８３と、不承諾ボタン８４とは、破線で示すように、乗員が操作することができない選択不能な状態で表示されている。
通常の更新案内画面８２には、ソフトウェアの更新処理を実行すること通知するメッセージとともに、その更新処理の承諾ボタン８３と、不承諾ボタン８４と、が表示される。この時点では、承諾ボタン８３と、不承諾ボタン８４とは、破線で示すように、乗員が操作することができない選択不能な状態で表示されている。
【0084】
図１１は、図６のステップＳＴ３１において承諾入力を許可している状態での、通常の更新案内画面８２の一例である。
図１１において、承諾ボタン８３と、不承諾ボタン８４とは、実線で示されており、乗員が操作することができる選択可能な状態で表示されている。
図１１において、承諾ボタン８３と、不承諾ボタン８４とは、実線で示されており、乗員が操作することができる選択可能な状態で表示されている。
【0085】
図１２は、図６のステップＳＴ２８において表示デバイス３８に表示される、視認性を向上させた更新案内画面８５の一例である。
視認性を向上させた更新案内画面８５には、ソフトウェアの更新処理を実行すること通知するメッセージとともに、その更新処理の承諾ボタン８６と、不承諾ボタン８７と、が表示される。この時点では、承諾ボタン８６と、不承諾ボタン８７とは、破線で示すように、乗員が操作することができない選択不能な状態で表示されている。また、メッセージの文字やボタンの文字は、図１０の通常の更新案内画面８２のものより、拡大されている。また、メッセージの文字数やボタンの文字数は、図１０の通常の更新案内画面８２のものより、削減されている。これにより、高齢の管理者であっても、表示デバイス３８を一瞥するだけで、ソフトウェアの更新処理が実行されようとしていることを容易に理解することができる。
視認性を向上させた更新案内画面８５には、ソフトウェアの更新処理を実行すること通知するメッセージとともに、その更新処理の承諾ボタン８６と、不承諾ボタン８７と、が表示される。この時点では、承諾ボタン８６と、不承諾ボタン８７とは、破線で示すように、乗員が操作することができない選択不能な状態で表示されている。また、メッセージの文字やボタンの文字は、図１０の通常の更新案内画面８２のものより、拡大されている。また、メッセージの文字数やボタンの文字数は、図１０の通常の更新案内画面８２のものより、削減されている。これにより、高齢の管理者であっても、表示デバイス３８を一瞥するだけで、ソフトウェアの更新処理が実行されようとしていることを容易に理解することができる。
【0086】
図１３は、図６のステップＳＴ３１において承諾入力を許可している状態での、視認性を向上させた予告案内画面８５の一例である。
図１３において、承諾ボタン８６と、不承諾ボタン８７とは、実線で示されており、乗員が操作することができる選択可能な状態で表示されている。
図１３において、承諾ボタン８６と、不承諾ボタン８７とは、実線で示されており、乗員が操作することができる選択可能な状態で表示されている。
【0087】
図１４は、上述した本実施形態の制御を、ＯＴＡ（Ｏｖｅｒ ｔｈｅ Ａｉｒ）センタ７１とＯＴＡマスタ７２との連携に適用する場合の説明図である。
図１４において、サーバ装置２は、ＯＴＡセンタ７１と、バックエンド７５と、を有する。
また、自動車４は、ＯＴＡマスタ７２と、ＤＭＳ７３と、ヘッドユニット７４と、を有する。
図１４において、サーバ装置２は、ＯＴＡセンタ７１と、バックエンド７５と、を有する。
また、自動車４は、ＯＴＡマスタ７２と、ＤＭＳ７３と、ヘッドユニット７４と、を有する。
【0088】
ＯＴＡセンタ７１とＯＴＡマスタ７２とは、それらが連携して、サーバ装置２に接続されているデータベース３の更新用のソフトフェアを、サーバ装置２から自動車４へダウンロードするための制御を実行するものである。
この場合、自動車４のＯＴＡマスタ７２は、図５のソフトウェア更新制御などを実行して、サーバ装置２から更新用のソフトフェアをダウンロードし、展開し、アクティベートする制御を実行してよい。
この場合、自動車４のＯＴＡマスタ７２は、図５のソフトウェア更新制御などを実行して、サーバ装置２から更新用のソフトフェアをダウンロードし、展開し、アクティベートする制御を実行してよい。
【0089】
そして、このようにＯＴＡセンタ７１とＯＴＡマスタ７２とを用いて、本実施形態の詳述した一連の制御を実行する場合、自動車４のＯＴＡマスタ７２は、図６から図８の承認制御を実行することになる。
また、ＯＴＡマスタ７２は、図５のステップＳＴ１において、サーバ装置２のＯＴＡセンタ７１との間で通信して、未適用の更新用のソフトフェアの有無を確認してよい。
また、ＯＴＡマスタ７２は、たとえば図７のステップＳＴ４４、ステップＳＴ４６、図６のステップＳＴ２５、図８のステップＳＴ６２、ステップＳＴ６４などの処理を、ＤＭＳ７３による乗員の撮像画像を用いて実行すればよい。
また、ＯＴＡマスタ７２は、たとえば図７のステップＳＴ４９の予告案内、図６のステップＳＴ２６またはステップＳＴ２８の更新案内などを、ヘッドユニット７４に表示してよい。
また、ＯＴＡマスタ７２は、図５のステップＳＴ１において、サーバ装置２のＯＴＡセンタ７１との間で通信して、未適用の更新用のソフトフェアの有無を確認してよい。
また、ＯＴＡマスタ７２は、たとえば図７のステップＳＴ４４、ステップＳＴ４６、図６のステップＳＴ２５、図８のステップＳＴ６２、ステップＳＴ６４などの処理を、ＤＭＳ７３による乗員の撮像画像を用いて実行すればよい。
また、ＯＴＡマスタ７２は、たとえば図７のステップＳＴ４９の予告案内、図６のステップＳＴ２６またはステップＳＴ２８の更新案内などを、ヘッドユニット７４に表示してよい。
【0090】
以上のように、本実施形態では、自動車４で用いられるソフトウェアを更新するために自動車４に設けられる、自動車４のソフトウェア更新装置としての制御系２０は、自動車４のソフトウェアを更新する処理を実行する更新制御装置２７、自動車４に設けられる出力デバイスを制御する入出力制御装置２４、および、自動車４の管理者の管理者端末（１２）と通信可能な通信制御装置２５、を有する。そして、更新制御装置２７のＣＰＵ５３は、自動車４のソフトウェアを更新するための処理を実行する前に、自動車４にその管理者が乗車しているか否かを判断する乗車判断処理、を実行する。
また、ＣＰＵ５３は、乗車判断処理において管理者が乗車していると判断する場合には、自動車４が走行中ではないタイミングにおいて、入出力制御装置２４を通じて、自動車４に設けられる出力デバイスから、自動車４のソフトウェアの更新処理の案内通知を出力する。これに対し、乗車判断処理において管理者が乗車していないと判断する場合には、ＣＰＵ５３は、通信制御装置２５を通じて、自動車４の管理者の管理者端末（１２）から、自動車４のソフトウェアの更新処理の案内通知を出力する。これらの自動車４のソフトウェアの更新処理の案内通知を出力した後に、ＣＰＵ５３は、自動車４のソフトウェアを更新するための処理を実行する。
これにより、たとえば自動車４に管理者以外の乗員が乗車している場合には、その自動車４において、自動車４のソフトウェアの更新処理の案内通知を出力しないようにできる。自動車４の管理者以外の乗員は、自動車４のソフトウェアを更新しないようにできる。しかも、本実施形態では、自動車４に管理者以外の乗員が乗車している場合には、その更新通知を止めるのではなく、自動車４の管理者の管理者端末（１２）に、自動車４のソフトウェアの更新処理の案内通知を出力する。したがって、自動車４のソフトウェアを更新可能な場合には、自動車４の管理者は、その自動車４を使用していなくても、その更新の通知を受けて、自動車４のソフトウェアを即時的に更新することが可能である。
また、ＣＰＵ５３は、管理者から承諾の入力がある場合には、自動車４のソフトウェアを更新するための処理を実行し、管理者から承諾の入力がない場合には、今回の自動車４のソフトウェアを更新するための処理を中断する。
その結果、自動車４の管理者は、たとえば、それ以外の人が自動車４のソフトウェアを更新してしまうことがなくなり、自動車４を容易に管理することができる。また、自動車４の管理者は、自らに通知がされることにより、自動車４のソフトウェアが更新されたことを把握できる。自動車４の管理者は、ソフトウェアが更新された自動車４と、ソフトウェアが更新されていない自動車４とを、特段の作業をすることなしに容易に判別することができる。自動車４の管理者は、自動車４のソフトウェアの更新を適切に管理することができる。
特に、本実施形態では、ソフトウェアの更新を、基本的に、自動車４において更新のためのソフトウェアを取得する処理と、取得しているソフトウェアを自動車４に展開する処理と、自動車４に展開したソフトウェアの実行へ切り替える処理との、複数の段階に分けて、各段階の実行の前に、自動車４のソフトウェアの更新処理の案内通知を出力する。これにより、これらの処理を１回の承諾で連続的に実施する必要がなくなる。各承諾の下でのソフトウェアの更新処理の時間は、短くなる。管理者は、一連のすべての更新処理を一度に待つことなく、短い待ち時間の後に、自動車４の走行を開始することができる。本実施形態のＣＰＵ５３は、自動車４のソフトウェアの更新処理の案内を通知するために、自動車４の利用を阻害し難くなる。
また、ＣＰＵ５３は、乗車判断処理において管理者が乗車していると判断する場合には、自動車４が走行中ではないタイミングにおいて、入出力制御装置２４を通じて、自動車４に設けられる出力デバイスから、自動車４のソフトウェアの更新処理の案内通知を出力する。これに対し、乗車判断処理において管理者が乗車していないと判断する場合には、ＣＰＵ５３は、通信制御装置２５を通じて、自動車４の管理者の管理者端末（１２）から、自動車４のソフトウェアの更新処理の案内通知を出力する。これらの自動車４のソフトウェアの更新処理の案内通知を出力した後に、ＣＰＵ５３は、自動車４のソフトウェアを更新するための処理を実行する。
これにより、たとえば自動車４に管理者以外の乗員が乗車している場合には、その自動車４において、自動車４のソフトウェアの更新処理の案内通知を出力しないようにできる。自動車４の管理者以外の乗員は、自動車４のソフトウェアを更新しないようにできる。しかも、本実施形態では、自動車４に管理者以外の乗員が乗車している場合には、その更新通知を止めるのではなく、自動車４の管理者の管理者端末（１２）に、自動車４のソフトウェアの更新処理の案内通知を出力する。したがって、自動車４のソフトウェアを更新可能な場合には、自動車４の管理者は、その自動車４を使用していなくても、その更新の通知を受けて、自動車４のソフトウェアを即時的に更新することが可能である。
また、ＣＰＵ５３は、管理者から承諾の入力がある場合には、自動車４のソフトウェアを更新するための処理を実行し、管理者から承諾の入力がない場合には、今回の自動車４のソフトウェアを更新するための処理を中断する。
その結果、自動車４の管理者は、たとえば、それ以外の人が自動車４のソフトウェアを更新してしまうことがなくなり、自動車４を容易に管理することができる。また、自動車４の管理者は、自らに通知がされることにより、自動車４のソフトウェアが更新されたことを把握できる。自動車４の管理者は、ソフトウェアが更新された自動車４と、ソフトウェアが更新されていない自動車４とを、特段の作業をすることなしに容易に判別することができる。自動車４の管理者は、自動車４のソフトウェアの更新を適切に管理することができる。
特に、本実施形態では、ソフトウェアの更新を、基本的に、自動車４において更新のためのソフトウェアを取得する処理と、取得しているソフトウェアを自動車４に展開する処理と、自動車４に展開したソフトウェアの実行へ切り替える処理との、複数の段階に分けて、各段階の実行の前に、自動車４のソフトウェアの更新処理の案内通知を出力する。これにより、これらの処理を１回の承諾で連続的に実施する必要がなくなる。各承諾の下でのソフトウェアの更新処理の時間は、短くなる。管理者は、一連のすべての更新処理を一度に待つことなく、短い待ち時間の後に、自動車４の走行を開始することができる。本実施形態のＣＰＵ５３は、自動車４のソフトウェアの更新処理の案内を通知するために、自動車４の利用を阻害し難くなる。
【0091】
本実施形態では、乗車判断処理において自動車４に乗車していると判断する場合、ＣＰＵ５３は、さらに、管理者の体調の良否を判断する体調判断処理、を実行する。そして、体調判断処理において自動車４の管理者の体調が良であると判断する場合には、ＣＰＵ５３は、入出力制御装置２４を通じて、自動車４に設けられる出力デバイスから、自動車４のソフトウェアの更新処理の案内通知を出力する。これに対し、体調判断処理において自動車４の管理者の体調が良でないと判断する場合には、ＣＰＵ５３は、自動車４のソフトウェアの更新処理の案内通知出力を止めて、今回の自動車４のソフトウェアを更新するための処理を中断する。この場合、ＣＰＵ５３は、次回のタイミングにおいて、自動車４のソフトウェアの更新処理の案内通知を出力することになる。
これにより、ＣＰＵ５３は、たとえば自動車４の管理者の体調が優れない場合に、その優れない体調の管理者に対して自動車４のソフトウェアの更新処理の案内を通知しないようできる。優れない体調の管理者に対する負担を軽減できる。管理者は、体調が良い状態で、自動車４のソフトウェアの更新処理の案内通知を受けて、自動車４のソフトウェアの更新状態を確実に把握することができる。
このように本実施形態では、自動車４の管理者が、自動車４のソフトウェアの更新について適切に管理することが可能になる。
これにより、ＣＰＵ５３は、たとえば自動車４の管理者の体調が優れない場合に、その優れない体調の管理者に対して自動車４のソフトウェアの更新処理の案内を通知しないようできる。優れない体調の管理者に対する負担を軽減できる。管理者は、体調が良い状態で、自動車４のソフトウェアの更新処理の案内通知を受けて、自動車４のソフトウェアの更新状態を確実に把握することができる。
このように本実施形態では、自動車４の管理者が、自動車４のソフトウェアの更新について適切に管理することが可能になる。
【0092】
本実施形態において、自動車４に設けられる入出力制御装置２４は、自動車４に設けられる出力デバイスとともに入力デバイスを制御する。そして、ＣＰＵ５３は、入出力制御装置２４を通じて自動車４のソフトウェアの更新処理の案内通知を出力し始めるとともに、自動車４に乗車している管理者による案内通知の表示についての視認の有無を判断する視認判断処理を繰り返し実行する。また、案内通知の出力中に繰り返される視認判断処理において管理者が通知を視認していると判断する場合には、ＣＰＵ５３は、案内通知が出力し終える前でも、入力デバイスからの管理者の承諾入力を可能にする。また、入力デバイスから管理者の承諾が入力されると、自動車４のソフトウェアを更新するための処理を実行する。
これにより、管理者は、自動車４のソフトウェアの更新処理の案内通知を視認すれば、その案内通知の終了を待つことなく、入力デバイスから承諾を入力することができる。また、入出力制御装置２４は、入力デバイスから管理者の承諾が入力されると、自動車４のソフトウェアを更新するための処理を実行することができる。管理者は、たとえば案内通知が終了することを常に待つことなく、承諾入力をして、自動車４の走行を開始することができる。本実施形態のＣＰＵ５３は、自動車４のソフトウェアの更新処理の案内を通知するために、自動車４の利用を阻害し難くなる。
これにより、管理者は、自動車４のソフトウェアの更新処理の案内通知を視認すれば、その案内通知の終了を待つことなく、入力デバイスから承諾を入力することができる。また、入出力制御装置２４は、入力デバイスから管理者の承諾が入力されると、自動車４のソフトウェアを更新するための処理を実行することができる。管理者は、たとえば案内通知が終了することを常に待つことなく、承諾入力をして、自動車４の走行を開始することができる。本実施形態のＣＰＵ５３は、自動車４のソフトウェアの更新処理の案内を通知するために、自動車４の利用を阻害し難くなる。
【0093】
本実施形態において、出力デバイスは、表示により通知を出力可能な表示デバイス３８である。ＣＰＵ５３は、自動車４のソフトウェアの更新処理の案内通知を表示デバイス３８から出力し始めた後の視認判断処理において、表示デバイス３８に表示している案内通知についての自動車４の乗員による視認期間に基づいて、自動車４の乗員が案内通知を視認していることを判断する。
さらに、ＣＰＵ５３は、自動車４に管理者が案内通知をしている現時点においても乗車しているか否かを再度判断する乗車再判断処理を実行する。そして、ＣＰＵ５３は、乗車再判断処理において管理者が案内通知をしている現時点においても乗車していると判断しない場合には、自動車４のソフトウェアの更新処理の案内通知出力を止めて、今回の自動車４のソフトウェアを更新するための処理を中断する。承諾入力を許可しない。
自動車４のソフトウェアの更新処理は、基本的に、自動車４が走行していない状態において実行することが望ましいと考えられている。したがって、案内通知前に自動車４にその管理者が乗車しているか否かを最初に判断したタイミングから、案内通知後に承諾入力を許可するタイミングまでに、一定の時間が経過している可能性がある。この間に、自動車４の乗員が交代してしまっている可能性がある。このような交代があった場合、仮にたとえば単に自動車４の乗員が案内通知を視認していることのみに基づいて管理者による承諾入力を許可してしまうと、承諾を入力する時点での自動車４の乗員が管理者ではなくなる。管理者以外の乗員が、自動車４のソフトウェアの更新処理を承諾できるようになってしまう。本実施形態では、このような時間経過があったとしても、管理者による承諾を受け付けるようにすることができる。
さらに、ＣＰＵ５３は、自動車４に管理者が案内通知をしている現時点においても乗車しているか否かを再度判断する乗車再判断処理を実行する。そして、ＣＰＵ５３は、乗車再判断処理において管理者が案内通知をしている現時点においても乗車していると判断しない場合には、自動車４のソフトウェアの更新処理の案内通知出力を止めて、今回の自動車４のソフトウェアを更新するための処理を中断する。承諾入力を許可しない。
自動車４のソフトウェアの更新処理は、基本的に、自動車４が走行していない状態において実行することが望ましいと考えられている。したがって、案内通知前に自動車４にその管理者が乗車しているか否かを最初に判断したタイミングから、案内通知後に承諾入力を許可するタイミングまでに、一定の時間が経過している可能性がある。この間に、自動車４の乗員が交代してしまっている可能性がある。このような交代があった場合、仮にたとえば単に自動車４の乗員が案内通知を視認していることのみに基づいて管理者による承諾入力を許可してしまうと、承諾を入力する時点での自動車４の乗員が管理者ではなくなる。管理者以外の乗員が、自動車４のソフトウェアの更新処理を承諾できるようになってしまう。本実施形態では、このような時間経過があったとしても、管理者による承諾を受け付けるようにすることができる。
【0094】
以上の実施形態は、本発明の好適な実施形態の例であるが、本発明は、これに限定されるものではなく、発明の要旨を逸脱しない範囲において種々の変形または変更が可能である。
【符号の説明】
【0095】
１…ソフトウェア更新システム、２…サーバ装置、４…自動車（車両）、５…通信網、７…中継装置、８…基地局、９…道路、１０…自宅敷地、１１…歩行者（管理者）、１２…端末デバイス（管理者端末）、２０…制御系（ソフトウェア更新装置）、２１…検出制御装置、２２…走行制御装置、２３…空調制御装置、２４…入出力制御装置、２５…通信制御装置、２６…操作制御装置、２７…更新制御装置、２８…車ネットワーク、３０…車内カメラ、３１…車内Ｌｉｄａｒ、３２…車内赤外線センサ、３３…着座センサ、３４…シート位置センサ、３５…温度センサ、３６…ＧＮＳＳ受信機、３７…加速度センサ、３８…表示デバイス（出力デバイス）、３９…操作デバイス（入力デバイス）、４０…スピーカ（音出力デバイス）、４１…マイクロホン（音入力デバイス）、４４…シフトセンサ、４５…パーキングブレーキセンサ、４６…通信デバイス、４７…車輪速センサ、５０…制御装置、５１…内通信部、５２…タイマ、５３…ＣＰＵ、５４…メモリ、５５…内部バス、５６…プログラム、５７…設定値、５８…パラメータ、５９…テーブル、６０…管理者情報、６１…音出力設定値、６２…端末送信情報、６３…更新案内情報、６４…予告案内情報、７１…ＯＴＡセンタ、７２…ＯＴＡマスタ、７３…ＤＭＳ、７４…ヘッドユニット、７５…バックエンド、８１…予告案内画面、８２…通常の更新案内画面、８３…承諾ボタン、８４…不承諾ボタン、８５…視認性を向上させた更新案内画面、８６…承諾ボタン、８７…不承諾ボタン、１０１…ＧＮＳＳ衛星
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】