JP2020164113A - 自動車用演算装置 - Google Patents

Abstract

【課題】駆動機構が動作していない場合の電力消費を最大限に抑制しつつ、必要なソフトウェアの更新に対応できるようにする。【解決手段】自動車用演算装置６は、外部のネットワーク９０からソフトウェア更新情報を受け付ける無線通信部２と、無線通信部２から受けたソフトウェア更新情報を記憶させる記憶部６３と、記憶部６３に記憶されたソフトウェア更新情報を基にしてソフトウェアを更新する更新制御部と、演算装置の各構成要素への供給電源を制御する電力制御部とを備える。そして、記憶部６３にソフトウェア更新情報があり、かつ、自動自動車１の駆動機構が動作していないときに、電力制御部６６が、記憶部６３、更新制御部６４及びソフトウェア更新情報で示された更新対象ソフトウェアを通電状態にし、更新制御部６４が、更新対象ソフトウェアを更新する。【選択図】図１

Description

ここに開示する技術は、例えば、自動車用演算装置に関する。

特許文献１には、ＥＣＵに記憶されているプログラム（ソフトウェア）を更新するためのプログラムやパラメータ等からなるリプログデータを対象機器に書込んで当該対象機器のソフトウェアを更新する車載通信機に関する技術が開示されている。

特許文献２には、車載装置を制御しているプログラムの機能拡張や機能修正が生じた場合に、ユーザーが車両のエンジンを停止し、車載装置を利用しなくなった時にプログラムのバージョンアップを行う技術が開示されている。

特開２０１３−８４１４３号公報 特開２００４−２４９９１４号公報

近年、車車間通信で得られた情報や、外部サーバ等とのネットワーク通信を介して得られた情報等を用いた安全運転支援技術や自動運転技術の導入が進められている。このような、安全運転支援技術や自動運転技術では、人工知能等の活用も進んでおり、プログラム量が飛躍的に増大し、その結果、相対的に規模が大きい演算装置が採用される場合がある。そうすると、それらのプログラムを一斉に更新すると、電力消費が非常に大きく、所要時間も非常に長くかかるという問題がある。特に、車載用の演算装置では、車載バッテリから電源供給を受けており、車載バッテリの電力は車両の起動時等にも用いられることから、使用できる電力量に限りがあるため、対策が必要である。

ここに開示された技術は、斯かる点に鑑みてなされたものであり、その目的とするところは、自動車用の演算装置において、駆動機構が動作していない場合の電力消費を最大限に抑制しつつ、必要なソフトウェアの更新には対応できるようにすることにある。

前記課題を解決するために、ここに開示された技術では、自動車に搭載される自動車用の演算装置を対象とし、外部のネットワークからソフトウェア更新情報を受け付ける無線通信部と、前記無線通信部から受けた前記ソフトウェア更新情報を記憶させる記憶部と、前記記憶部に記憶された前記ソフトウェア更新情報を基にして、前記演算装置のソフトウェアを更新する更新制御部と、前記演算装置の各構成要素への供給電源を制御する電力制御部とを備え、前記記憶部にソフトウェア更新情報があり、かつ、前記自動車の駆動機構が動作していないときに、前記電力制御部が、前記記憶部、前記更新制御部及び前記ソフトウェア更新情報で示された更新対象を通電状態にし、前記更新制御部が、前記更新対象のソフトウェアを更新する、という構成とした。

本態様では、駆動機構が動作していない場合において、記憶部にソフトウェア更新情報がある場合には、記憶部、更新制御部及び更新対象ソフトウェアを通電状態にし、更新制御部が、更新対象のソフトウェアを更新できるように構成されている。これにより、これにより、駆動機構が動作していない場合の電力消費を最大限に抑制しつつ、必要なソフトウェアの更新には対応できるようにすることができる。

前記演算装置において、前記駆動機構が動作しているときに、前記ソフトウェア更新情報を受けた場合、当該ソフトウェア更新情報を前記記憶部に一時保管し、前記駆動機構の動作が停止してから、前記更新制御部が、前記更新対象のソフトウェアを更新する、としてもよい。

これにより、駆動機構が動作しているときでもソフトウェア更新情報を受け取ることができ、また、適切なタイミングで更新対象のソフトウェアを更新することができる。また、停車地点の通信状況に影響を受けずに、ソフトウェアの更新をすることができる。

前記演算装置において、前記更新制御部は、ユーザーからの入力情報またはユーザーの使用習慣を基に、ユーザーが使用しない時間帯に、前記更新対象のソフトウェアを更新する、としてもよい。

これにより、ユーザーが使用できない時間を短縮し、または、なくすことができ、利便性を向上させることができる。

前記演算装置において、前記演算装置は、前記自動車のバッテリの状態情報を取得可能に構成され、前記更新制御部は、前記自動車のバッテリ及びメモリ容量の少なくとも一方の残量が少ない場合に、前記更新対象のソフトウェアの更新について、重要度の高い順に更新するか、または、更新自体を行わない。

これにより、メモリやバッテリの残量が少ない場合でも、重要度の高いソフトウェアの更新を実行することができる。また、更新自体を行わないという選択肢を設けることで、例えば、ソフトウェアの更新で自動車の走行に影響がでるような事態を避けることができる。

前記演算装置は、前記自動車のバッテリの状態情報を取得可能に構成され、前記更新制御部は、前記自動車のバッテリが充電状態の場合に、前記更新対象のソフトウェアの更新のうち、電力消費の高いものから順に更新する、としてもよい。

バッテリの充電中は、充電をしていない場合と異なり、ソフトウェアの更新に使用可能な電力に余裕があるため、まずは、電力消費の高いものから順に更新することで、ソフトウェアの更新によるバッテリへの影響を少なくすることができる。

前記演算装置は、前記演算装置は、前記自動車のバッテリの状態情報を取得可能に構成され、前記更新制御部は、前記自動車のバッテリが充電状態の場合に、当該充電の所要時間にあわせて、前記更新対象のソフトウェアの更新のうち、電力消費の高くかつ所要時間が長いものから順に更新する、としてもよい。

これにより、充電時間を有効に利用することができる。また、ユーザーが使用できない時間を短縮することができる。

以上説明したように、ここに開示された技術によると、自動車用の演算装置において、駆動機構が動作していない場合の電力消費を最大限に抑制しつつ、必要なソフトウェアの更新に対応できる。

実施形態に係る自動車用演算装置の機能構成を示すブロック図である。 実施形態に係る演算装置のソフトウェアの構成例を示す図である。 演算装置によるソフトウェアの更新処理を示すフローチャートである。 実システムへの導入例の機能構成を示すブロック図である。 実システムへの導入例の機能構成を示すブロック図である。

以下、例示的な実施形態について、図面を参照しながら詳細に説明する。

＜実施形態＞
図１は、本実施形態に係る自動車１（例えば、四輪）の構成例を示すブロック図である。自動車１は、運転者によるアクセル等の操作に応じて走行するマニュアル運転と、運転者の操作をアシストして走行するアシスト運転と、運転者の操作なしに走行する自動運転とが可能な自動車である。尚、以下の説明では、本実施形態の自動車１を他の車両と区別するために、自車両１ということがある。

自動車１は、車外情報取得手段Ｍ１及び車内情報取得手段Ｍ２と、通信ユニット２と、セキュリティゲートウェイ装置４と、車両電源５と、演算装置６と、アクチュエータ７とを備えている。

車外情報取得手段Ｍ１は、演算システムＳＹに自動車１の車外環境の情報を出力するセンサ等で構成され、例えば、（１）自動車１のボディ等に設けられかつ車外環境を撮影する複数のカメラと、（２）自動車１のボディ等に設けられかつ車外の物標等を検知する複数のレーダと、（３）自動車１の絶対速度を検出する車速センサと、（４）自動車１のアクセルペダルの踏み込み量を検出するアクセル開度センサと、（５）自動車１のステアリングホイールの回転角度（操舵角）を検出する操舵角センサと、（６）自動車１のブレーキペダルの踏み込み量を検出するブレーキセンサと、（７）全地球測位システム（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ：ＧＰＳ）を利用して、自動車１の位置（車両位置情報）を検出する位置センサと、を含んでいる。

車内情報取得手段Ｍ２は、演算装置６に自動車１の車内環境の情報を出力するセンサ等で構成され、例えば（１）自動車１の車内ミラーやダッシュボード等に設けられかつ運転者の表情や姿勢、社内環境等を撮影する車内カメラと、（２）運転者の生体情報（体温、心拍数、呼吸等）を取得する車内センサと、を含んでいる。

演算装置６は、車外情報取得手段Ｍ１からの出力を受け、道路上であって障害物を回避する経路を生成し、その経路に沿って走行する際の自動車１の目標運動を決定するように構成されている。さらに、演算装置６は、決定した目標運動を実現するための制御信号を、駆動力と制動力と操舵角とを生成するアクチュエータ７に出力するように構成されている。本実施形態では、上記の目標運動の決定と、目標運動を実現するための制御信号の出力とが、１ユニット構成の演算装置で実現されている点に特徴がある。１ユニット構成の演算装置６とは、例えば、１つ又は複数のチップで構成されたマイクロプロセッサであって、ＣＰＵやメモリ等を有している。なお、演算装置６についての詳細は後述する。

アクチュエータ７は、演算装置６からの制御を受けて動作するように構成され、例えば、エンジン７１と、ブレーキ７２と、ステアリング７３と、トランスミッション７４とを含んでいる。また、アクチュエータ７には、エアバックやパワーウィンドウのような、いわゆるボディ系のアクチュエータ７５も含まれる（図１では、「ボディ系」と記載）。なお、本開示で「アクチュエータ」という場合、エンジン７１、ブレーキ７２、ステアリング７３、トランスミッション７４のように、駆動力と制動力と操舵角とを生成する各種アクチュエータを区別せずに、それらのアクチュエータの少なくともいずれか１つを指し示す場合と、上記アクチュエータ類を総称する意味で用いる場合とがある。なお、具体的な図示は省略するが、アクチュエータ７は、そのそれぞれにおいて、ＥＣＵを含んでいてもよいし、ＥＣＵを含まずに後述する自動運転機能部６０の制御を受けて動作するように構成されていてもよい。

エンジン７１は、動力駆動源であり、内燃機関（ガソリンエンジン、ディーゼルエンジン）を含む。演算装置６は、自動車１を加速又は減速させる必要がある場合に、エンジン７１に対してエンジン出力変更信号を出力する。エンジン７１は、マニュアル運転時には、運転者のアクセルペダルの操作量等により制御されるが、アシスト運転や自動運転時には、演算システムＳＹから出力された目標運動を示す目標運動信号（以下、単に目標運動信号という）に基づいて制御される。尚、図示は省略しているが、エンジン７１の回転軸には、エンジン７１の出力により発電する発電機が連結されている。エンジン７１は、駆動力を生成するアクチュエータの一例である。

ブレーキ７２は、制動力をここでは電動ブレーキである。演算システムＳＹは、自動車１を減速させる必要がある場合に、ブレーキ７２に対してブレーキ要求信号を出力する。ブレーキ要求信号を受けたブレーキ７２は、該ブレーキ要求信号に基づいてブレーキアクチュエータ（図示省略）を作動させて、自動車１を減速させる。ブレーキ７２は、マニュアル運転時には、運転者のブレーキペダルの操作量等により制御されるが、アシスト運転や自動運転時には、演算システムＳＹから出力された目標運動信号に基づいて制御される。ブレーキ７２は、制動力を生成するアクチュエータの一例である。

ステアリング７３は、ここではＥＰＳ（Ｅｌｅｃｔｒｉｃ Ｐｏｗｅｒ Ｓｔｅｅｒｉｎｇ）である。演算装置６は、自動車１の進行方向を変更する必要がある場合に、ステアリング７３に対して操舵方向変更信号を出力する。ステアリング７３は、マニュアル運転時には、運転者のステアリングホイール（所謂ハンドル）の操作量等により制御されるが、アシスト運転や自動運転時には、演算装置６から出力された目標運動信号に基づいて制御される。ステアリング７３は、操舵角を生成するアクチュエータの一例である。

トランスミッション７４は、有段式のトランスミッションである。演算装置６は、出力すべき駆動力に応じて、トランスミッション７４に対してギヤ段変更信号を出力する。トランスミッション７４は、マニュアル運転時には、運転者のシフトレバーの操作や運転者のアクセルペダルの操作量等により制御されるが、アシスト運転や自動運転時には、演算装置６により算出された目標運動に基づいて制御される。

演算装置６は、マニュアル運転時には、アクセル開度センサ等の出力に基づく制御信号をエンジン７１等に出力する。一方で、演算装置６は、アシスト運転時や自動運転時には、自動車１の走行経路を設定して、自動車１が該走行経路を走行するように、エンジン７１等に制御信号を出力する。

通信ユニット２（無線通信部に相当）は、ＲＦ部２１と、復調部２２とを備える。ＲＦ部２１は、外部のネットワーク９０から車載アンテナ（図示省略）を介して受信したＲＦ信号を処理する。復調部２２は、ＲＦ部２１に受けたＲＦ信号を復調して、セキュリティゲートウェイ装置４に出力する。ここで、外部のネットワーク９０とは、自車両１との間で相互通信が可能に構成された移動体通信網やインターネット等の通信網、通信ユニットが搭載された装置等で形成される通信環境・構成を広く含む概念として使用するものとする。通信ユニット２は、例えば、外部のネットワーク９０を介してクラウドサービスや管理サーバ等に接続されている。また、自動車１の搭乗者やディーラーの従業者により、車外から持ち込まれた端末装置９２と通信ユニット２とが、Ｂｌｕｅｔｏｏｔｈ（登録商標）やＷｉ−Ｆｉ（登録商標）、モバイルネットワーク等により互いに直接通信するように構成されていてもよく、この場合における通信も外部のネットワーク９０との通信に包含される。なお、本開示では、自動車１の運転者、搭乗者及びディーラーの従業者等を含む概念として、単に、ユーザーと表現する場合がある。また、通信ユニット２のＲＦ部２１及び復調部２２の回路構成は、従来から知られている一般的な回路を採用することができるので、ここでは、その説明を省略するものとする。

セキュリティゲートウェイ装置４は、通信ユニット２の復調部２２からの出力を受ける認証部４１と、復号部４２と、暗号化部４４とを備えている。本実施形態では、外部通信装置からのアクセスが、このセキュリティゲートウェイ装置４に集約され、このセキュリティゲートウェイ装置４での認証を経て演算装置６に入力される。

認証部４１は、外部のネットワーク９０を介して外部通信装置から演算装置６へのアクセスがあった場合に、予め設定された基準に基づいて、その外部通信装置からのアクセスの正当性を判断し、演算装置６へのアクセスを許可するか否かを決定する。「予め設定された基準」は、アクセスの正当性の判断ができる基準であれば、特に限定されるものではないが、例えば、認証局のデジタル署名を付与した公開鍵暗号方式に基づいて、外部通信装置の正当性を判断することができる。また、予め設定された基準として、自社が予め保有したり、ネットワーク９０を介して受領した、ホワイトリスト、ブラックリスト等のリスト情報を用いてもよい。認証部４１は、認証部４１で正当性が認証された外部通信装置からの受信信号を復号部４２に出力する。ここで、外部の通信装置からのアクセスには、例えば、外部の通信装置が演算装置６に対して、車内情報の読み出しや書き込みの要求をする、いわゆるアクセス要求と、演算装置６が外部の通信装置（外部の管理サーバーを含む）に対して情報等を要求し、外部の通信装置から演算装置６に情報を返送するためのアクセスとを含む概念である。

復号部４２では、認証部４１から受信したデータを復号する。換言すると、復号部４２は、認証部４１で正当性が認められた外部通信装置からの受信データを復号する。例えば、前述のような公開鍵暗号方式に基づく暗号データが受信された場合には、その復号処理を実行する。また、復号に際して、ハッシュ演算を用いた改ざん検出を行うようにしてもよい。

なお、認証部４１と復号部４２とは、連携して処理を行う場合があり、受信したデータの種類や属性によって、処理の順番が変わったり、それぞれで実施する処理の内容が変わったりすることがある。

認証部４１で認証され、復号部４２で復号されたデータは、暗号化部４４で暗号化され、演算装置６に出力される。すなわち、セキュリティゲートウェイ装置４と、演算装置６との間は、暗号化通信により接続される。なお、暗号化部４４を省いて、セキュリティゲートウェイ装置４から演算装置６に、認証部４１で認証され、復号部４２で復号されたデータをそのまま送信するようにしてもよい。暗号化部４４に用いる暗号方式は、特に限定されず、必要なセキュリティレベルに応じて使い分けすることができる。また、選択された暗号方式に対応する回路構成は、それぞれの暗号方式に応じて従来から知られているものを用いることができるので、ここではその詳細説明を省略する。

演算装置６は、自動運転機能部６０と、快適機能部６１と、通信制御部６２と、記憶部６３と、更新制御部６４と、電力制御部６６と、入力判定部６７と、駆動状態検出部６８と、を備えている。尚、図１においては、本実施形態で説明する機能を発揮するための構成を示しており、演算装置６が有する全ての機能を示しているわけではない。また、本実施形態では、説明の便宜上、演算装置６を、各ブロックに分割しているが、演算装置６にＣＰＵが搭載されている場合に、ＣＰＵがこれらの機能ブロックのうちの複数のブロックの機能を担うように構成されていてもよい。

通信制御部６２は、セキュリティゲートウェイ装置４と通信する機能を有する。通信制御部６２は、例えば、セキュリティゲートウェイ装置４の暗号化部４４の出力を復号し自動運転機能部６０に出力する復号部（図示省略）を備える。復号部の構成は、暗号化部４４で暗号化された信号を復号できるように構成されていればよく、従来から知られている構成を用いることができるので、ここではその詳細説明を省略する。

記憶部６３は、後述するＯＳ、ミドルウェア、アプリケーションを実行するためのソフトウェア（プログラムを含む）が格納されている。また、記憶部６３には、通信ユニット２経由して外部のネットワーク９０から受信されたデータが格納されるようになっていて、例えば、各ソフトウェアの更新情報（以下、ソフトウェア更新情報という）が記憶される。また、記憶部６３には、各種のソフトウェアの更新を行う際に、バックアップファイルが作成された場合には、そのバックアップファイルが一時保存されたり、更新情報の妥当性を検証するために一定期間ミラーリングをして処理をする場合のミラーリングされたソフトウェア等が格納される。

更新制御部６４は、記憶部６３に記憶されたソフトウェア更新情報を基にして、演算装置６のソフトウェアを更新する。更新制御部６４の具体的な動作は、後述する「演算装置の動作」で具体的に説明する。

電力制御部６６は、自動車に搭載された車両電源５（例えば、車載バッテリ）に接続され、車両電源５から演算装置６の各構成要素への供給電源を制御する。構成要素の単位は、特に限定されないが、例えば、各機能ブロックを構成要素としてもよいし、ハードウェア（例えば、回路）やソフトウェア（例えば、プログラム）の一部の領域を構成要素の単位としてもよい。さらに、電力制御部６６は、車両電源部が充電式のバッテリの場合に、充電中か否かを判定したり、バッテリの残量を検知する機能を有する。さらに、ソフトウェアの更新に必要な消費電力を計算して、ソフトウェアの更新をするか否かを判断する。また、電力制御部６６は、各構成要素を通電するか否かを制御したり、供給する電力量を調整したりする機能を有する。

ここで、安全運転支援技術や自動運転技術では、演算装置６の回路規模が大きくなるため、仮に、スリープ状態にしたとしても、一定の電力が消費され、それが車両電源（特に、車載バッテリ）の残量の低下や、短寿命化の原因となる場合がある。そこで、本実施形態では、電力制御部６６は、例えば、駆動機構が動作していない場合に、演算装置６の中で、その起動に最低限必要な構成以外の構成について、電源供給を停止させるように構成されている。さらに、本実施形態では、駆動機構が動作していない場合において、記憶部６３にソフトウェア更新情報がある場合には、記憶部６３、更新制御部６４及びソフトウェア更新情報で示された更新対象を通電状態にし、更新制御部６４が、更新対象のソフトウェアを更新できるように構成されている点に特徴がある。なお、更新対象とは、更新対象のソフトウェアを更新するために起動させておくことが必要な構成要素を指すものとする。

入力判定部６７は、ユーザーの操作を受けるスイッチボタンや、タッチディスプレー等の入力インターフェースに対してユーザーの操作があった場合に、その操作内容を検出する機能を有する。具体的には、従来から知られている方法を用いることができる。

駆動状態検出部６８は、車両の駆動機構の状態を検出する機能を有する。例えば、自動車１が、エンジン駆動式の自動車、または、ハイブリッド式の自動車の場合には、イグニッションのオン、オフの状態を検出するように構成されている。また、自動車１が、電気自動車の場合には、駆動モータのオン、オフの状態を検出するように構成されている。具体的には、従来から知られている方法を用いることができる。

自動運転機能部６０は、アシスト運転や自動運転をする場合に、車外情報取得手段Ｍ１からの出力に基づいて、または、車外情報取得手段Ｍ１および車内情報取得手段Ｍ２からの出力に基づいて、自動車１の目標運動を決定し、アクチュエータ７をその目標運動に沿って動作させるための制御信号を出力する。自動運転機能部６０の構成については、後述する「実システムへの導入例」で一例を挙げて説明するものとし、ここではその詳細説明を省略する。

快適機能部６１は、車室内において、運転者や搭乗者の快適さを向上させるために機能する構成の総称である。例えば、快適機能部６１には、車室内の温度や湿度等を快適な状態に保つためのエアコン等の空調設備及びその制御装置（制御ソフトウェアを含む）や、音楽再生のための音響機器及びその制御装置（制御ソフトウェアを含む）が含まれる。また、照明設備及びその制御装置等を含んでいてもよい。

図２は、自動運転機能部６０や快適機能部６１の構成例を、ソフトウェアの構成を中心に記載したものである。例えば、自動運転機能部６０及び快適機能部６１は、１つまたは複数のプラットフォーム上で動作するように構成されている。すなわち、演算装置６には、１つまたは複数のＯＳ（Operating System）がインストールされていて、自動運転機能部６０や快適機能部６１の各機能ブロックの処理が、ＯＳ上で動作するように構成されている。

図２の例では、自動運転機能部６０や快適機能部６１を動作させるために、演算装置６に、２つのＯＳ（便宜上、ＯＳ１，ＯＳ２という）がインストールされていて、ＯＳ１上でミドルウェアＡ，Ｂ及びアプリケーションＡ１，Ａ２，Ｂが動作し、ＯＳ２上でミドルウェアＣ，Ｄ及びアプリケーションＣ１，Ｃ２，Ｄが動作しているものとする。すなわち、ハードウェア上に、ＯＳレイヤ、ミドルウェアレイヤ、アプリケーションレイヤが構築されているものとする。尚、ＯＳの数や構成は、任意に設定することが可能であり、特に限定されるものではない。例えば、図２において、ＯＳ１で自動運転機能部６０の処理が実行され、ＯＳ１で快適機能部６１の処理が実行されるようにしてもよいし、例えば、快適機能部６１の一部の機能のみ、例えば、音楽再生に関する処理のみ、他の処理とは異なるＯＳを使用するようにしてもよい。

次に、演算装置６の動作について図２及び図３を参照しつつ具体的に説明する。なお、演算装置６の自動運転機能部６０を中心とした自動運転に関わる動作については、後述する「実システムへの導入例」で一例を挙げて説明するものとし、ここでは、外部のネットワークから受けたソフトウェアの更新処理について説明する。ここでは、図２の斜線で示した部分のソフトウェアの更新情報が記憶部６３に格納されているものとし、ＯＳレイヤが、更新時間が最も長く、消費電力が最も大きいものとし、ミドルウェアレイヤ、アプリケーションレイヤの順に、更新時間、消費電力が小さくなっていくものとする。また、アプリケーションＡ１の更新の重要度が最も高く、その次に、アプリケーションＢの更新の重要度が高いものとする。

ステップＳ１１では、駆動機構の動作状態、すなわち、オン／オフ状態が確認される。例えば、自動車１がエンジンで駆動されている場合には、駆動状態検出部６８の検出結果を基に、イグニッションのオン／オフが判断される。また、自動車１がモータで駆動されている場合には、モータのオン／オフが判断される。ステップＳ１２では、記憶部６３に、外部のネットワーク９０を介して受信されたソフトウェアの更新情報があるかどうかが判断される。そして、駆動機構が動作しておらず（ステップＳ１１でＯＦＦ判定）、かつ、記憶部６３にソフトウェア更新情報がある（ステップＳ１２でＹＥＳ判定）場合、フローはステップＳ１３に進む。尚、ステップＳ１１とステップＳ１２の処理順は、図３に限定されず、ステップＳ１１とステップＳ１２との処理順が逆でもよいし、ステップＳ１１とステップＳ１２とが並列に処理されてもよい。

前述のとおり、駆動機構が動作していない場合において、ソフトウェアの更新情報がある場合、電力制御部６６は、演算装置の中で、ソフトウェアの更新に必要な構成要素である、記憶部６３、更新制御部６４及びソフトウェアの更新対象を通電状態にし、それ以外の構成についての電力供給を停止する。

上記の通電状態にすること、及び、電力供給の停止に関し、電力制御部６６は、例えば、駆動機構がオフ制御された場合に、記憶部６３を確認して、ソフトウェアの更新対象を特定し、更新対象がある場合に、記憶部６３、更新制御部６４及びソフトウェアの更新対象構成の通電状態を維持するようにしてもよい。また、ソフトウェアの更新対象がない場合に、いったん演算装置６の起動に最低限必要な構成以外の構成をオフ制御し、その状態で、待機するようにしてもよい。そして、外部のネットワーク９０からソフトウェアの更新情報が送られてきた場合に、例えば、通信ユニット２が起動信号を演算装置６に送信し、その起動信号を基に、例えば、演算装置６の電力制御部６６を起動させ、電力制御部６６が記憶部６３、更新制御部６４及びソフトウェアの更新対象構成を通電状態にするように構成してもよい。

ステップＳ１３では、電力制御部６６において、バッテリが充電中であるかどうかが判断される。ステップＳ１３は、特に、自動車１が電気自動車の場合を想定した処理となる。したがって、自動車１がガソリン車の場合、ステップＳ１３を省略してもよい。

ステップＳ１３で、ＹＥＳ判定の場合には、充電中のため電力による制約が少ない。また、充電で開始されると、所定期間は、自動車１が走行する可能性が低い。したがって、更新制御部６４は、例えば、記憶部６３のソフトウェア更新情報を基に、消費電力が大きく、かつ、長時間かかるような更新から順に処理を実行する。図２の例では、ＯＳ２のソフトウェア更新から順に処理を開始する。このとき、ソフトウェアの更新対象としては、そのときに更新するソフトウェアのみを起動し、更新が終了したらその更新対象の通電をオフし、次の更新対象を起動して通電させる、というように、更新対象にあわせて順次、通電／非通電を切り替えるようにしてもよい。

尚、ＯＳ２の重要度がそれほど高くない場合に、充電をしている場所や時間帯に応じて、ＯＳ２の更新処理をするかどうかを判断するようにしてもよい。例えば、ユーザーの使用習慣に基づいて、判断することが可能であり、充電しているのが昼間の場合において、例えば、ユーザーの過去の履歴から充電時間が１時間程度としたときに、ＯＳ２の更新に１時間以上かかるような場合には、ＯＳ２の更新をやめて、他の更新を優先してもよい。また、例えば、アプリケーションＡ１の重要度が高い場合に、アプリケーションＡ１の更新をしてから、時間的にＯＳ２が更新できるようであれば、更新するというような順序で更新処理を行ってもよい。また、ユーザーにソフトウェアの更新情報の内容を提示し、ユーザーの選択した優先順位に基づいて更新処理を実行するようにしてもよい。後述するステップＳ１６，Ｓ１９についても同様である。

そして、ステップＳ１４では、ＯＳ２、ミドルウェアＡ及びアプリケーションＡ１，Ｂの順にソフトウェアが更新され、終了すると、ソフトウェア更新処理は終了となる。なお、各ブロックの更新が終わるたびに、ステップＳ１１の判定に戻るようにしてもよい。また、駆動機構の動作が開始された場合に、割込み処理で、ソフトウェアの更新を一時的に、または、全体として停止し、次の機会に再開または最初から開始するようにしてもよい。

一方で、ステップＳ１３でＮＯ判定の場合、フローはステップＳ１５に進み、車両電源５の残量が十分に残っているかどうかが判断される。ステップＳ１５では、例えば、更新するソフトウェアに応じて、あらかじめ設定された規定値以上の残量があるかどうかが判断される。なお、規定値は、１つに限定されず互いに異なる規定値（例えば、段階的な値）を定めるようにしてもよい。また、「バッテリの残量」と「ソフトウェア更新情報（更新ソフトウェア）の容量」というように、互いに異なる複数のパラメータを用いてもよい。具体的に、例えば、規定値として、更新ソフトウェアの容量が数百［Mbyte］の場合はバッテリ残量が８０％以上、更新ソフトウェアの容量が数十［Mbyte］の場合はバッテリ残量が６０％以上、更新ソフトウェアの容量が数［Mbyte］の場合はバッテリ残量が４０％以上、のように、いくつかのレベルの規定値を設けるようにしてもよい。

ステップＳ１５において、車両電源５の残量車両電源の残量が十分にある場合（ステップＳ１５でＹＥＳ）、更新制御部６４は、ソフトウェアの更新処理に必要な時間、重要度等を総合的に判断し、優先順位を決めて、使用できる電源の範囲内で、優先順にソフトウェアの更新処理を実行する。優先順位の判断方法は、特に限定されないが、例えば、各事象にスコアを付けて、そのスコアが高いものから順にとしてもよいし、特定の機能については、他の機能よりも優先してアップデートするというように決めておいてもよいし、管理サーバから順番を指定するようにしてもよい。また、ステップＳ１５において、車両電源５の残量車両電源の残量判定に加えてまたは代えて、メモリ容量の残量が十分に残っているかどうかを判断するようにしてもよい。その場合においても、上記の記載において、「残量車両電源の残量」の場合と同様に、「メモリ容量の残量」について、ステップＳ１５の判断を行うようにするとよい。

一方で、ステップＳ１５でＮＯ判定の場合、フローは次のＳ１７に進み、現在の車両電源５の残量で、一部のソフトウェアの更新は可能かどうかが判断される。

そして、ステップＳ１７において、車両電源５の残量が所定の規定値を下回る等、一部のソフトウェアでも更新が難しいと判断されると（ステップＳ１７でＮＯ）、更新制御部６４は、いずれのソフトウェアも更新せずに処理は終了となる（ステップＳ１８）。

一方で、ステップＳ１７でＹＥＳ判定の場合、更新制御部６４は、車両電源５の残量の範囲内で重要度の高い更新から順に実行し、その更新処理が終わると処理は終了となる。

以上のように、本実施形態によると、記憶部６３にソフトウェア更新情報があり、かつ、自動車１の駆動機構が動作していないときに、電力制御部６６が、記憶部６３、更新制御部６４及びソフトウェア更新情報で示された更新対象を通電状態にし、更新制御部６４が、前記更新対象ソフトウェアを更新するようにしている。これにより、駆動機構が動作していない場合の電力消費を最大限に抑制しつつ、必要なソフトウェアの更新には対応できるようにすることができる。

（その他の実施形態）
また、上記に開示された技術は、上記実施形態に限られるものではなく、請求の範囲の主旨を逸脱しない範囲で代用が可能である。

なお、アクチュエータ７(７１〜７５)側にマイクロコントローラといったような制御チップが搭載されている場合に、マイクロコントローラ側に更新対象のメモリを実装するようにしてもよい。その場合には、例えば、マイクロコントローラ側のソフトウェア更新情報が、通信ユニット２経由して受信された後に記憶部６３に記憶され、更新制御部６４が、記憶部６３に格納されたソフトウェア更新情報を使って、マイクロコントローラ側の更新対象を更新するようにしてもよい。

また、更新対象のソフトウェアの更新に関し、自動車１の車両電源５が充電状態の場合において、更新制御部６４が、充電の所要時間にあわせて、更新対象のソフトウェアの更新のうち、電力消費が高くかつ所要時間が長いものから順に更新するようにしてもよい。例えば、充電のおおよその所要時間がわかっている場合に、充電の所要時間の範囲内で、電力消費が高くかつ所要時間が長いものから順に更新するようにしてもよい。

これにより、充電時間を有効に利用することができる。また、ユーザーが使用できない時間を短縮することができる。

（実システムへの導入例）
図４Ａ及び図４Ｂを参照しながら、実システムへの導入例について説明する。なお、以下の説明では、図４Ａ及び図４Ｂをまとめて、単に図４と呼ぶものとする。

−１．概要−
まず、本開示に係る自動車用演算装置６（以下、単に演算装置６という）は、機能的には、（１）車外環境、車内環境（運転者の状態を含む）を認知するための構成（以下、認知系ブロックＢ１ともいう）と、（２）認知系ブロックＢ１での認知結果に基づいて各種状態・状況等を判断し、自動車１の動作を決定するための構成（以下、判断系ブロックＢ２ともいう）と、（３）判断系ブロックＢ２での決定を基に、具体的にアクチュエータ類に伝達する信号・データ等を生成するための構成（以下、操作系ブロックＢ３ともいう）、とに分かれている。本開示の技術は、認知系ブロックＢ１、判断系ブロックＢ２及び操作系ブロックＢ３が、１つのユニットに集約されて、実現されている点に特徴を有する。演算装置６では、認知系ブロックＢ１、判断系ブロックＢ２及び操作系ブロックＢ３により、前述の自動運転機能部６０としての機能を実現している。

また、本演算装置６は、（１）通常運転時における自動運転を実現するための認知系ブロックＢ１、判断系ブロックＢ２及び操作系ブロックＢ３とで構成された主演算部６１０と、（２）主に主演算部６１０の認知系ブロックＢ１及び判断系ブロックＢ２を補完する機能を有するセーフティ機能部６３０と、（３）主演算部６１０やセーフティ機能部６３０の機能が失陥した場合等の異常事態が発生した際に、自動車１を安全な位置まで移動させるバックアップセーフティ機能部６５０とを備えている。

本演算装置６において、主演算部６１０の認知系ブロックＢ１および判断系ブロックＢ２では、ニューラルネットワークを利用した深層学習により構築された各種モデルを利用して処理を実行する。このようなモデルを使用した処理を行うことで、車両状態、車外環境、運転者の状態等の総合的な判断に基づく運転制御、すなわち、大量の入力情報をリアルタイムで協調させて制御することができるようになる。深層学習を利用した車外環境の認定及び経路の算出は、未だ発展途上の状態であり、ＡＳＩＬ−Ｂ程度に留まるとされている。なお、図４では、参考情報として、各ブロックのＡＳＩＬ情報を記載しているが、本記載に限定されるものではなく、各ブロックが図４とは異なる機能安全レベルを有していてもよい。

セーフティ機能部６３０は、（１）従来より自動車等に採用されている物標等の認定方法に基づいて、車外にある物体（本開示では、対象物と呼んでいる）を認識する、（２）従来より自動車等に採用されている方法で、車両が安全に通過できる安全領域を設定し、その安全領域を通過するような経路を自動車が通過すべき走行経路として設定する、ように構成されている。このような、いわゆるルールベースの判断や処理を行うことにより、ＡＳＩＬ−Ｄ相当の機能安全レベルを実現することができる。

そして、本演算システムＳＹは、主演算部６１０とセーフティ機能部６３０とが、同一の入力情報（車外情報取得手段Ｍ１や車内情報取得手段Ｍ２で取得された情報を含む）に基づいて、同一の目的の処理（例えば、経路生成）を、並列に進めるようにしている点に特徴がある。これにより、主演算部６１０から逸脱処理が導き出されることを監視することができるとともに、必要に応じて、セーフティ機能部６３０による判断や処理の方を採用したり、主演算部６１０に再演算をさせたりすることができるようになっている。

主演算部６１０とセーフティ機能部６３０とは、両機能をあわせて（以下、両機能をあわせたものを車両制御機能ともいう）、それを１つ又は複数のチップで構成するようにしてもよいし、主演算部６１０とセーフティ機能部６３０のそれぞれを独立したチップで構成するようにしてもよい。

また、本演算装置６では、主演算部６１０及びセーフティ機能部６３０の両方が故障するような事態にも対処できるように、バックアップセーフティ機能部６５０を設けている。バックアップセーフティ機能部６５０は、車外情報に基づいてルールベースで経路を生成し、安全な位置に停車させるまでの車両制御を実行する機能を、主演算部６１０及びセセーフティ機能部６３０とは別構成として用意したものである。したがって、主演算部６１０及びセーフティ機能部６３０とは、別々の装置（チップ）で構成されるのが好ましい。

−２．構成−
以下において、図４を参照しつつ、本演算システムＳＹの具体的構成について、説明する。なお、実施形態と共通の構成については、共通の符号を使用して説明する場合がある。また、共通の構成についての詳細説明を省略する場合がある。

演算装置６には、自動車１の車外環境の情報を取得する車外情報取得手段Ｍ１、及び、車内環境の情報を取得する車内情報取得手段Ｍ２のそれぞれで取得されたデータが入力信号として与えられる。また、演算装置６への入力信号として、車外ネットワーク（例えば、インターネット等）に接続されたシステムやサービスからの情報がセキュリティゲートウェイ装置４を介して入力されるようにしてもよい。

車外情報取得手段Ｍ１として、例えば、（１）複数のカメラ５０、（２）複数のレーダ５１、（３）車速センサ等のメカセンサー５２０、（４）アクセル開度センサ、操舵角センサ、ブレーキセンサ等のドライバ入力部５３０、（５）ＧＰＳ等の測位システムを含む位置センサ５６等が例示される。

車内情報取得手段Ｍ２として、例えば、車内カメラ、車内センサ等が例示される。車内センサには、例えば、アクセルペダル、ブレーキペダル、ステアリング、各種スイッチ等の各種操作対象物への運転者の操作を検出するセンサを含む。車内情報取得手段Ｍ２の出力結果の一部は、入力判定部６７に入力される。なお、図４では、車内情報取得手段Ｍ２の図示を省略している。

−２−１．主演算部−
ここでは、主演算部６１０の構成例及び主演算部６１０による深層学習を用いた経路生成について説明する。

図４に示すように、主演算部６１０は、カメラ５０及び／またはレーダ５１の入力に基づいて、車外の物体（対象物）を認識する物体認識部６１１を有する。物体認識部６１１は、カメラ５０で撮像された社外の画像（映像を含む）や、レーダ５１を用いた反射波のピークリストにより、車外の物体を認識する機能を有する。また、主演算部６１０は、実施形態に示したとおり、深層学習を利用して、認識された物体が何かを判別する機能を有する。物体認識部６１１には、従来から知られている画像や電波に基づく物体認識技術を適用することができる。

物体認識部６１１で認識された結果は、マップ生成部６１２に送られる。マップ生成部６１２では、自車両の周囲を複数の領域（例えば、前方、左右方向、後方）に分け、各領域ごとにマップ作成処理を行う。マップ作成処理では、それぞれの領域に対して、カメラ５０で認識された物体情報と、レーダ５１で認識された物体情報とを統合し、マップに反映させる。

マップ生成部６１２で生成されたマップ、セキュリティゲートウェイ装置４から入力されて通信制御部６２で復号されたデータの一部（例えば、マップ情報）は、車外環境推定部６１３において、深層学習を用いた画像認識処理により車外環境の推定に使用される。具体的に、車外環境推定部６１３では、深層学習を利用して構築された環境モデル６１４に基づく画像認識処理により車外環境を表す３Ｄマップを作成する。深層学習では、多層ニューラルネットワーク（ＤＮＮ：Ｄｅｅｐ Ｎｅｕｒａｌ Ｎｅｔｗｏｒｋ）が用いられる。多層ニューラルネットワークとして、例えば、ＣＮＮ（Ｃｏｎｖｏｌｕｔｉｏｎａｌ Ｎｅｕｒａｌ Ｎｅｔｗｏｒｋ）がある。より具体的に、車外環境推定部６１３では、（１）各領域ごとのマップが結合され、自車両１の周囲を表した統合マップが生成され、（２）その統合マップ内の動体物に対し、自車両１との距離、方向、相対速度の変位が予測され、（３）その結果が、車外環境モデル６１４に組み込まれる。さらに、車外環境推定部６１３では、（４）車内または車外から取り込んだ高精度地図情報、ＧＰＳ等で取得された位置情報・車速情報・６軸情報の組み合わせによって統合マップ上での自車両１の位置を推定するとともに、（５）前述の経路コストの計算を行い、（６）その結果が、各種センサで取得された自車両１の運動情報とともに車外環境モデル６１４に組み込まれる。これらの処理により、車外環境推定部６１３では、随時、車外環境モデル６１４が更新され、経路生成部６２１による経路生成に使用される。上記の物体認識部６１１、マップ生成部６１２、車外環境推定部６１３での処理結果や、車外環境モデル６１４は、前述のセキュリティゲートウェイ装置４の認証部４１での処理に利用される。

ＧＰＳ等の測位システムの信号、車外ネットワークから送信される例えばカーナビゲーション用のデータは、セキュリティゲートウェイ装置４を介して入力され、通信制御部６２で復号されて、経路探索部６２２に送られる。経路探索部６２２は、ＧＰＳ等の測位システムの信号、車外ネットワークから送信される例えばナビゲーション用のデータを用いて、車両の広域経路を探索する。

経路生成部６２１では、車外環境モデル６１４と、経路探索部６２２の出力とを基にして、車両の走行経路を生成する。

−２−２．セーフティ機能部−
ここでは、セーフティ機能部６３０の構成及びセーフティ機能部６３０によるルールベースの経路生成について説明する。

図４に示すように、セーフティ機能部６３０は、主演算部６１０と同じ、カメラ５０及び／またはレーダ５１の入力に基づいて、車外の物体（対象物）を認識する物体認識部６３１を有する。セーフティ機能部６３０では、主演算部６１０と同様の手法により車外の物体を認識した後に、深層学習を利用せずに、従来から知られているルールベースの手法により認識された物体が何かを判別するようにしている。例えば、従来から知られており、ＡＳＩＬ−Ｄ相当の機能安全レベルを実現している識別機を通して、認識された物体が何かを判別する。

物体認識部６３１で認識された結果は、動体と静止物とに分類される。図４では、６３２の符号を付して「動体・静止物分類」と記載した回路ブロックで実行される。具体的に、ここでは、（１）自車両の周囲が複数の領域（例えば、前方、左右方向、後方）に分けられ、（２）各領域で、カメラ５０で認識された物体情報と、レーダ５１で認識された物体情報とが統合され、（３）各領域に対する導体及び静止物との分類情報が生成される。そして、（４）各領域ごとの分類結果が統合され、（５）自車両周辺の導体及び静止物との分類情報として、例えば、グリッドマップ上で管理される。また、動体物に対しては、（６）自車両との距離、方向、相対速度が予測され、その結果が動体物の付属情報として組み込まれるとともに、（７）車内または車外から取り込んだ高精度地図情報、ＧＰＳ等で取得された位置情報・車速情報・６軸情報の組み合わせによって、動体・静止物に対する自車両の位置が推定される。また、セーフティ機能部６３０では、車速情報・６軸情報に基づく車両状態を検出し、自車両１の付属情報として経路生成に使用する。セーフティ機能部６３０では、ここで推定された動体・静止物に対する自車両の位置と、安全領域の探索結果に基づいて、経路が生成される。

主演算部６１０及びセーフティ機能部６３０で生成された経路は、目標運動決定部７１０に送られ、両経路の比較結果等に応じて最適な目標運動が決定される。例えば、主演算部６１０で生成した経路が、セーフティ機能部６３０で探索された安全領域から外れる時には、セーフティ機能部６３０で生成された経路が採用される。

目標運動決定部６２３は、自動車１の目標運動を決定する。

車両運動エネルギー操作部６２４及びエネルギーマネジメント部６２５は、目標運動決定部６２３で決定された目標運動を達成する上で、最もエネルギー効率がよくなるようにアクチュエータ７の制御量を算出する。具体的に例示すると、例えば、エネルギーマネジメント部は、目標運動決定部６２３で決定されたエンジントルクを達成する上で、最も燃費が向上するような、吸排気バルブ（図示省略）の開閉タイミングやインジェクタ（図示省略）の燃料噴射タイミング等を算出する。

−２−３．バックアップセーフティ機能部−
ここでは、バックアップセーフティ機能部６５０の構成及びバックアップセーフティ機能部６５０によるルールベースの経路生成について説明する。バックアップセーフティ機能部６５０は、ルールベースで最低限の安全停車位置への移動動作、停車動作ができるようにするために必要な構成を備えたものとなっている。大枠の構成は、セーフティ機能部６３０を同じような機能で実現することができる。

図４に示すように、バックアップセーフティ機能部６５０では、物体認識部６３１で認識された結果を基に、動体と静止物とが分類される。図４では、６５３の符号を付して「動体・静止物分類」と記載した回路ブロックで実行される。物体認識部６３１は、図５に示すように、セーフティ機能部６３０と共通のものを使用してもよいし、個別に、バックアップセーフティ機能部６５０に設けられていてもよい。さらに、バックアップセーフティ機能部６５０は、車両状態を計測する車両状態計測部６５１と、運転者の操作状態を把握するドライバ操作認知部６５２とを備えている。車両状態計測部６５１は、自車両１の付属情報として経路生成に使用するために、車速情報・６軸情報に基づく車両状態を取得する。

尚、前述のとおり、更新対象ソフトウェアの区分け、すなわち、１つの更新対象ソフトウェアに含める範囲は、任意に設定することができる。例えば、図４の構成において、認知系ブロックＢ１の全体が、ソフトウェアの更新対象としてもよいし、認知系ブロックＢ１の一部の構成をソフトウェアの更新対象としてもよい。また、必要な更新内容に応じて、更新対象ソフトウェアの範囲を定義するようにしてもよい。例えば、判断系ブロックＢ２、操作系ブロックＢ３についても同様である。また、認知系ブロックＢ１、判断系ブロックＢ２、操作系ブロックＢ３が、共通のＯＳ上で動作するように構成されていてもよいし、それぞれが、異なるＯＳ上で動作するように構成されていてもよい。

ここに開示された技術は、自動車に搭載される自動車用演算システムとして有用である。

１ 自動車
２ 通信ユニット（無線通信部）
６３ 記憶部
６４ 更新制御部
６６ 電力制御部

Claims (6)

1. 自動車に搭載される自動車用の演算装置であって、
   外部のネットワークからソフトウェア更新情報を受け付ける無線通信部と、
   前記無線通信部から受けた前記ソフトウェア更新情報を記憶させる記憶部と、
   前記記憶部に記憶された前記ソフトウェア更新情報を基にして、前記演算装置のソフトウェアを更新する更新制御部と、
   前記演算装置の各構成要素への供給電源を制御する電力制御部とを備え、
   前記記憶部にソフトウェア更新情報があり、かつ、前記自動車の駆動機構が動作していないときに、前記電力制御部が、前記記憶部、前記更新制御部及び前記ソフトウェア更新情報で示された更新対象を通電状態にし、前記更新制御部が、前記更新対象のソフトウェアを更新する
   ことを特徴とする自動車用演算装置。
2. 前記駆動機構が動作しているときに、前記ソフトウェア更新情報を受けた場合、当該ソフトウェア更新情報を前記記憶部に一時保管し、前記駆動機構の動作が停止してから、前記更新制御部が、前記更新対象のソフトウェアを更新する、ことを特徴とする請求項１に記載の自動車用演算装置。
3. 前記更新制御部は、ユーザーからの入力情報またはユーザーの使用習慣を基に、ユーザーが使用しない時間帯に、前記更新対象のソフトウェアを更新する、ことを特徴とする請求項１に記載の自動車用演算装置。
4. 前記演算装置は、前記自動車のバッテリの状態情報を取得可能に構成され、
   前記更新制御部は、前記自動車のバッテリ及びメモリ容量の少なくとも一方の残量が少ない場合に、前記更新対象のソフトウェアの更新について、重要度の高い順に更新するか、または、更新自体を行わない、ことを特徴とする請求項１に記載の自動車用演算装置。
5. 前記演算装置は、前記自動車のバッテリの状態情報を取得可能に構成され、
   前記更新制御部は、前記自動車のバッテリが充電状態の場合に、前記更新対象のソフトウェアの更新のうち、電力消費の高いものから順に更新する、ことを特徴とする請求項１に記載の自動車用演算装置。
6. 前記演算装置は、前記自動車のバッテリの状態情報を取得可能に構成され、
   前記更新制御部は、前記自動車のバッテリが充電状態の場合に、当該充電の所要時間にあわせて、前記更新対象のソフトウェアの更新のうち、電力消費が高くかつ所要時間が長いものから順に更新する、ことを特徴とする請求項１に記載の自動車用演算装置。

Images