JP7495890B2 - 車載型コンピュータシステムおよび自動運転支援システム - Google Patents

Description

本発明は、車載型コンピュータシステムおよび自動運転支援システムに関する。

車載型コンピュータシステムにおいて、ＯＴＡ（Over The Air）技術等を用いて電子制御装置の更新またはアップグレードを行うことが可能である。

たとえば特許文献１には、車両用プログラム書換えシステムが記載されている。特許文献1に記載される構成では、センター装置は、複数の更新対象装置の更新データ、対象装置ＩＤ及び対象装置のプログラム格納メモリが１面か複数面かを示し、対象装置の更新及びロールバックの際に参照されるメモリ構成と更新データを読み出すためのアドレスとに基づき、対象装置に対するＩＤ、メモリ構成及びアドレスを予め定められた所定のデータ構造に合わせて生成された諸元データと更新データとを含む配信パッケージを記憶し、車両側システムからの通知に応じてそれを車両側システムへ配信する。車両側システムは、受信した配信パッケージを参照して車両の走行中にメモリへの書込みが可能か否か判断し、対象装置のプログラム更新を制御し、途中でキャンセルがあるとメモリ構成に基づきロールバックを制御する。

特開２０２０－０２７６６９号公報

しかしながら、従来の技術では、車載型コンピュータシステムのプログラム更新によって新たな機能を追加することが困難であるという課題があった。

特許文献１の構成では、車載の中央ユニットおよび分散ユニットが新たな機能を統合するようには設計されておらず、また、スマートインフラストラクチャに基づく自動運転（ＡＤ）または先進運転支援システム（ＡＤＡＳ）アプリケーションを統合するようにも設計されていない。特許文献１の構成は、ファームウェアまたはバージョン更新を扱うのみであり、機能を更新することはできない。このため、特許文献１の構成では、プログラム更新によって新たな機能を追加することができない。

本発明はこのような課題を解決するためになされたものであり、車載型コンピュータシステムのプログラム更新によって新たな機能を追加できる技術を提供することを目的とする。

本発明に係る車載型コンピュータシステムの一例は、
車外のコンピュータと通信可能な、車載型コンピュータシステムであって、
前記車載型コンピュータシステムは複数のＥＣＵを備え、各ＥＣＵは通信バスを介して少なくとも１つの他のＥＣＵと通信可能であり、
前記車載型コンピュータシステムは、
前記ＥＣＵについて、ＥＣＵ状態を測定する測定手段と、
前記ＥＣＵ状態と、前記通信バスの接続構成とに基づき、車両状態を推定する推定手段と、
更新プログラムと、前記更新プログラムの実行条件とを取得する、管理手段と、
を備え、
前記管理手段は、前記車両状態と、前記実行条件とに基づいて、前記更新プログラムを実行すべき第１ＥＣＵを選択し、
前記第１ＥＣＵは、前記更新プログラムを実行し、
前記管理手段は、前記更新プログラムの出力遅延制約が満たされているか否かを判定し、
前記管理手段は、前記更新プログラムに対して冗長な冗長プログラムの実行を終了させる。

本発明に係る自動運転支援システムの一例は、上述の車載型コンピュータシステムと、前記車外のコンピュータとを備える。

本発明に係る車載型コンピュータシステムおよび自動運転支援システムによれば、車載型コンピュータシステムのプログラム更新によって新たな機能を追加することができる。

本発明の実施例１に係る車載型コンピュータシステムを含む自動運転支援システムに配置される様々なモジュールの例。 実施例１に係る車載型コンピュータシステムを含む自動運転環境の例。 実施例１に係る車載型コンピュータシステムに新たな機能を追加する動作の概念図。 実施例１に係る車載型コンピュータシステムに用いられるセンサの例。 実施例１に係る車載型コンピュータシステムのアーキテクチャの例。 実施例１に係る車載型コンピュータシステムの機能ブロック構成の例。 実施例１に係る車載型コンピュータシステムにおいて、複数のＥＣＵに対するプログラムの配置例。 実施例１における車載型コンピュータシステムの動作例を示すフローチャートの一部。 実施例１における車載型コンピュータシステムの動作例を示すフローチャートの一部。 実施例１における車載型コンピュータシステムに新たな機能が追加される動作例。 実施例１における車載型コンピュータシステムにおいて用いられる情報の例。 実施例１における管理手段ＤＲＩＭと実行手段ＤＲＩＣとの関係の例。

以下、本発明の実施例を添付図面に基づいて説明する。以下は例示であり、本発明を限定するものではない。
実施例１．
図１は、本発明の実施例１に係る車載型コンピュータシステムを含む自動運転支援システムに配置される様々なモジュールの例を示す。実施例１は、車両の自律運転機能を拡張するための、スマートインフラストラクチャ、コネクテッドサービス、クラウドベース自律運転アプリケーションを、車載型ＡＤ／ＡＤＡＳプログラムに統合することができる。

ＡＤとはたとえば自動運転（Autonomous Driving）を意味し、ＡＤＡＳとはたとえば先進運転支援システム（Advanced Driver Assistance System）を意味する。本明細書において、プログラムとは、たとえばアプリケーションプログラムを意味するがこれに限らない。

車載の電気電子（ＥＥ）資源の最適な利用のために、および、安全な統合および車載型ＡＤ／ＡＤＡＳ拡張モード遷移のために、車両は車内のＥＥ資源およびネットワーク資源を実行または導出することができる。

同様に、車両は、環境条件、環境認識アルゴリズム、最適スループット要件、等の動的動作運転設計ドメインの知識ベースを有してもよい。

スマートインフラストラクチャ、コネクテッドサービス、クラウドベース自律運転アプリケーションの資源要件および資源可用性に基づき、実施例１に係る車載型コンピュータシステムは、要求される資源を安全および最適スループットのために割り当てることができる。

また、アプリケーション要件に基づき、アプリケーションデータのリルーティングおよびスケジューリングも実行される。

自動運転車両は、車両制御システム（たとえばＡＤ／ＡＤＡＳシステム）を用いて制御される。車両制御システムは、ゾーンベースまたはドメインベースのＥＥアーキテクチャにおいて構成される、複数の環境認識センサ、車両センサ、ローカリゼーションセンサ、アクチュエータ（ブレーキ、ステアリング、スロットル、パワートレイン等）、等を含む。

車両制御システムは、互いに通信する複数のモジュールを含む。複数のモジュールを協働させることが有益である。また、各モジュールは、センサデータ、認識データ、計画データ、アプリケーション状態データ、等を要求する複数のプログラムを含む場合がある。モジュールまたはプログラムは、１つ以上の資源要件と、クリティカルな運転シナリオおよび車両制御システム状態における優先度とを有する場合がある。これらのタスクを協働させるには、利用可能な資源の状態に応じて、各タスク／サービスの優先度およびデッドラインを適応させることが有益である。

たとえば、スマートインフラストラクチャまたは路側機クラウドベースリモートサーバと通信可能な車両が、車両制御を支援または完全にテイクオーバできるスマートハイウェイを走行している場合には、車両の自動運転機能を拡張することができる。

クライアントアプリケーションの資源要件によっては、実施例１に係る機能ブロックは、安全なモード遷移のために、クライアントアプリケーションを車載型ＡＤ／ＡＤＡＳアプリケーションに統合することができる。

たとえば、スマートハイウェイが、ハンズフリースーパークルーズおよび車線変更機能を提供可能なハイウェイパイロットラインアプリケーションを提供する場合がある。そのようなシナリオでは、車載側のハンズオン／オフＡＣＣ（適応的クルーズ制御）（半自律運転車両）およびＬＫＡ（車線維持支援）は終了可能である。しかしながら、ＡＥＢ（自動緊急ブレーキ）衝突回避アプリケーション等の安全クリティカルなアプリケーションは、クライアントアプリケーションと協働する必要がある。

このクライアントアプリケーションと、車載型ＡＤ／ＡＤＡＳ安全アプリケーションとの組み合わせでは、リアルタイム／ソフトタイムの遅延制約が厳しくなる場合がある。そのようなシナリオでは、実施例１に係る車載型コンピュータシステムは、アプリケーションデータのスケジューリングおよびリルーティングも行うことができる。

別の例として、レーダー、ＬｉＤＡＲ、カメラ、等を用いる車両検出は、それぞれ異なるネットワーク帯域幅要件を有する。デッドラインに対してレーダーのネットワーク帯域幅が要求するデータサイズは、カメラの場合に比較してはるかに小さい場合がある。車載型ＡＤ／ＡＤＡＳアプリケーションにスマートインフラストラクチャのクライアントアプリケーションを追加する場合には、ＡＤ／ＡＤＡＳアプリケーションを最小資源要件モードで実行することができる。

同様に、自動駐車および最適な電力利用も可能である。フェールオペレーショナルな車両制御システムを装備した高度な自動運転車両では、実施例１に係る車載型コンピュータシステムは、スマートインフラストラクチャの自律運転能力を利用して、車内の電力消費を抑制することができる。

実施例１に係る車載型コンピュータシステムは、たとえば自動運転機能を有する自動車に搭載されるが、「車載型」とは移動可能な装置に搭載されることを意味し、とくに自動車に搭載されるものに限らない。他の例として、バス、トラック、建設機械、地上型ロボット、倉庫ロボット、飛行機、ヘリコプター、ボート、船舶、農場機械、サービスロボット、列車、ゴルフカート、等にも搭載可能である。

図１は、実施例１に係る車載型コンピュータシステムを含む自動運転支援システムに配置され得る様々なモジュールの例を示す。この自動運転支援システムは、車載型コンピュータシステムと、車外のコンピュータとを含んで構成される。自動運転車両は、自動モードに設定することができ、安全ドライバーからの支援を得て、または支援なしで、所定の運転シナリオに沿って自動的に車両を運転することができる。

車載型コンピュータシステムは、環境認識センサシステム１０１と、環境認識システム１０２（運転シナリオに関する情報を収集する）と、計画システム１０３と、無線通信システム１０４と、物理ネットワーク通信システム１０５と、作用システム１０６と、車体・シャーシ制御システム１０７と、インフォテインメントシステム１０８と、ヒューマンマシンインタフェースシステム１０９と、ドライバー監視システム１１０と、車両制御システム１１１と、Ｖ２Ｘシステム１１２と、ドライバーインテンション１１３と、車両診断および機能不全監視システム１１４と、パワートレインシステム１１５とを含む。

自動運転車両は、手動モード、全自動モード、半自動モードのいずれかで走行可能である。車両は、図１のモジュールをすべて備える必要はなく、一部のモジュールが省略されていてもよい。

自動運転車両は、さらに、エンジン、車輪、ハンドル（ステアリングホイール）、トランスミッション、等を備えてもよく、車両制御システムがこれらを制御してもよい。自動運転車両は、さらに、各モジュールが互いに通信することを可能にする物理ネットワーク（有線ネットワーク）または無線ネットワークを備えてもよい。ネットワークは冗長であってもよい。

図２は、実施例１に係る車載型コンピュータシステムを含む自動運転環境の例を示す。この例はスマートハイウェイに関連する。スマートハイウェイは、路側機２０１および２０８と、スマートインフラストラクチャ２０３および２０６とを備え、運転シナリオを監視することができる。

スマートインフラストラクチャ２０３および２０６は、クラウドサーバ２０７と通信することができる。スマートインフラストラクチャ２０３および２０６は、認識センサにより取得された運転シナリオ情報を処理することができる。クラウドサーバ２０７は、スマートハイウェイ運転シナリオを処理して、車両２０２、２０４、２０５および２０９の安全なナビゲーションに必要な運転挙動を導出する。

スマートインフラストラクチャ２０３および２０６は、各車両およびクラウドサーバ２０７と、直接的に、または路側機を介して、通信可能である。各車両は、全自動または半自動運転が可能であり、また、路側機、スマートインフラストラクチャおよび他の車両との通信が可能である。各車両は、安全な走行のために、運転シナリオ認識および運転挙動情報を用いることができる。自動運転環境は、さらに、路面２１１（厳密には路面に関して配置されるコンピュータであり、道路に埋め込まれていてもよい。以下「路面」について同じ）および人工衛星２１２を含む。

実施例１に係る車載型コンピュータシステムは、たとえばこれらの車両２０２、２０４、２０５および２０９に搭載することができる。車載型コンピュータシステムは、車外のコンピュータと通信可能である。車外のコンピュータの例として、路側機２０１および２０８、スマートインフラストラクチャ２０３および２０６、クラウドサーバ２０７、路面２１１、人工衛星２１２、等が挙げられる。

図３は、実施例１に係るＡＤ／ＡＤＡＳ対応車両に新たな機能を追加する動作の概念図である。車両３０７～３０９に、実施例１に係る車載型コンピュータシステムが搭載されている。車両３０７～３０９は、ＳＡＥ規格Ｌ１～Ｌ２＋に適合し、自律運転機能を有する低コストエントリ車両またはミッドレンジ車両である。

車両３０７～３０９は、スマートハイウェイを安全にナビゲートするのに必要な運転挙動を提供できるスマートハイウェイを走行している。この場合には、車外のコンピュータ（たとえば路側機３０１、スマートインフラストラクチャ３０２および３０３、路面３０４、クラウドサーバ３０５、人工衛星３０６、等）と通信することにより、車両３０７～３０９をＳＡＥ規格Ｌ２＋～Ｌ５に拡張することができる。

このような動作は、アプリケーションインテグレータ３１０によって実現することができる。アプリケーションインテグレータ３１０は、車載型コンピュータシステム上で動作することができ、スマートハイウェイによって提供される自律運転アプリケーションを、車載型コンピュータシステムに統合して、車載型コンピュータシステムの能力を拡張することができる。

図４は、実施例１に係る車載型コンピュータシステムに用いられるセンサの例を示す。車載型コンピュータシステムは、様々なセンサ４０３～４０８を備えることができる。各センサは、車載型コンピュータシステムの、規格Ｌ１（４０１）および規格Ｌ２（４０２）様々な機能に必要な情報を提供する。なお、各規格の略語の説明は４０９に示す。

自律運転能力を拡張すると、ＡＤ／ＡＤＡＳアプリケーションの資源コストは増大する。実施例１によれば、スマートインフラストラクチャ、クラウドサーバ、コネクテッドサービス、等を用いて、ＳＡＥ規格Ｌ１の能力を拡張することができる。

図５は、実施例１に係る車載型コンピュータシステムのアーキテクチャの例を示す。自動運転レベルが規格Ｌ１およびＬ２の場合には、安全性は「フェールセーフ」であり、アーキテクチャは規格１ｏｏ１Ｄである。自動運転レベルが規格Ｌ３～Ｌ５の場合には、安全性は「フェールオペレーショナル」であり、アーキテクチャは規格１ｏｏ２Ｄである。

自動運転のレベルが向上すると、計算コストは増大する。実施例１に係る車載型コンピュータシステムは、ＳＡＥ規格のＡＤ／ＡＤＡＳレベルをすべてカバー可能である。車載型コンピュータシステムは、スマートインフラストラクチャ、クラウドサーバ、自律運転アプリケーション、等を利用して、車両の自律運転能力拡張のために、運転シナリオ認識および運転挙動能力を利用することができる。

図６は、実施例１に係る車載型コンピュータシステムの機能ブロック構成の例である。車両６０２は、クラウドサーバ６０１および路側機６０３等と通信可能である。車両６０２に搭載される車載型コンピュータシステム６０４は、オンボード装置６０５と、環境センサ６０６（カメラ、レーダー、ＬｉＤＡＲ、ソナー等）と、車両センサ６０７（ＧＮＳＳ、ＩＭＵ、オドメトリ等）と、ＡＤ／ＡＤＡＳアプリケーション６０８と、監視手段６０９と、パワートレインアプリケーション６１０と、車体制御アプリケーション６１１と、シャーシ制御アプリケーション６１２と、アクチュエータ６１３（ブレーキ、スロットル、操舵、等）と、インフォテインメント手段６１４と、地図手段６１５（環境位置手段等）とを備える。

車載型コンピュータシステム６０４は、様々な車内ＥＥ環境において構成可能である。たとえば、統合ドメインアーキテクチャ、ハイブリッドゾーン・ドメインアーキテクチャ、ゾーンアーキテクチャ、等が可能である。

図７は、実施例１に係る車載型コンピュータシステムにおいて、複数のＥＣＵに対するプログラムの配置例である。車載型コンピュータシステムは、ＥＣＵ１～ＥＣＵ５（７０１～７０５）を備える。各ＥＣＵは、通信バス７０６～７１０を介して、少なくとも１つの他のＥＣＵと通信可能である。

とくに図示しないが、各ＥＣＵはプロセッサおよび記憶手段を備える。プロセッサは演算手段として機能し、プログラムを実行することができる。記憶手段はプログラムを記憶してもよい。プロセッサがこのプログラムを実行することにより、ＥＣＵは以下に説明する様々な手段として機能し、これによって、車載型コンピュータシステムは本実施例において説明される機能を実現する。

車載型コンピュータシステムは、ＥＣＵについてＥＣＵ状態を測定する測定手段ＶＬＡＳＥ（Vehicle Local Area State Estimator）を備える。測定手段ＶＬＡＳＥは、たとえばＥＣＵが所定のＶＬＡＳＥプログラムを実行することによって実現される。図７の例では、測定手段ＶＬＡＳＥはＥＣＵ１、ＥＣＵ２、ＥＣＵ４、ＥＣＵ５に配置されている。

ＥＣＵ状態は、当該ＥＣＵにおいて実行中のプログラムを示す情報を含む。たとえば、ＥＣＵ１は認識プログラムを実行し、ＥＣＵ２は計画プログラムを実行し、ＥＣＵ３はマスターＥＣＵであり、ＥＣＵ４はアクチュエータ制御プログラムを実行し、ＥＣＵ５は表示プログラムを実行する。

また、ＥＣＵ状態は、当該ＥＣＵにおけるプロセッサ負荷、メモリ使用量、および通信バス使用量を含んでもよい。

車載型コンピュータシステムは、車両状態を推定する推定手段ＶＡＳＥＭを備える。図７の例では、推定手段ＶＡＳＥＭはＥＣＵ３（７０４）に配置されている。

推定手段ＶＡＳＥＭ（Vehicle Architecture State Estimator Master）は、ＥＣＵ状態と、通信バスの接続構成とに基づき、車両状態を推定する。車両状態は、たとえばＥＣＵ状態および通信バスの接続構成を組み合わせた情報である。図７の例では、推定手段ＶＡＳＥＭはＥＣＵ４に配置されている。

なお、ＥＣＵ３（７０４）にも測定手段ＶＬＡＳＥが配置されてもよい。または、推定手段ＶＡＳＥＭが測定手段ＶＬＡＳＥの機能を備えてもよい。

通信バスの接続構成は、各通信バスがどのＥＣＵとどのＥＣＵとを接続しているかを示す情報を含む。たとえば、ＥＣＵ１とＥＣＵ２とは通信バス１（７０８）を介して接続されている。ＥＣＵ２とＥＣＵ３とは通信バス３（７１０）を介して接続されている。ＥＣＵ１とＥＣＵ３とは通信バス２（７０７）を介して接続されている。ＥＣＵ２とＥＣＵ４とは通信バス４（７０９）を介して接続されている。ＥＣＵ３とＥＣＵ５とは通信バス５（７０６）を介して接続されている。

また、たとえば、ＥＣＵ１とＥＣＵ４とは直接的に通信バスによっては接続されておらず、通信バス１、ＥＣＵ２、通信バス４を介する必要がある。このような通信バスの接続構成を表す情報は、推定手段ＶＡＳＥＭが測定等により能動的に生成してもよいし、事前に各ＥＣＵの記憶手段に記憶されていてもよい。

車載型コンピュータシステムは、管理手段ＤＲＩＭ（Dynamic Reconfiguration Indicator Master）を備える。図７の例では、管理手段ＤＲＩＭはＥＣＵ３（７０４）に配置されている。管理手段ＤＲＩＭは、更新プログラムと、更新プログラムの実行条件とを取得する。実行条件の具体例は、図１０に関連して後述する。

車載型コンピュータシステムは、実行手段ＤＲＩＣ（Dynamic Reconfiguration Indicator Client）を備える。図７の例では、実行手段ＤＲＩＣはＥＣＵ１、ＥＣＵ２、ＥＣＵ４、ＥＣＵ５に配置されている。実行手段ＤＲＩＣは、ＥＣＵに特定のプログラムを実行させ、または終了させる。たとえばＥＣＵ２の実行手段ＤＲＩＣは、ＥＣＵ２に計画プログラムを実行させる。実行手段ＤＲＩＣは、プログラムのインストールと呼ばれる処理を行うものであってもよい。

なお、ＥＣＵ３（７０４）にも実行手段ＤＲＩＣが配置されていてもよい。または、管理手段ＤＲＩＭが実行手段ＤＲＩＣの機能を備えていてもよい。

図８Ａおよび図８Ｂは、実施例１における車載型コンピュータシステムの動作例を示すフローチャートである。まず管理手段ＤＲＩＭは、更新プログラムおよびその実行条件を取得する（ステップ８０１）。更新プログラムおよびその実行条件は、任意の経路で取得することができるが、たとえば事前にいずれかのＥＣＵの記憶手段に記憶しておいてもよいし、車外のコンピュータから取得してもよい。

次に、測定手段ＶＬＡＳＥが、各ＥＣＵについてＥＣＵ状態を測定する（ステップ８０２）。測定手段ＶＬＡＳＥは、測定したＥＣＵ状態を、推定手段ＶＡＳＥＭに送信する。上述のように、ＥＣＵ状態は、当該ＥＣＵにおいて実行中のプログラムを示す情報を含むことができ、また、当該ＥＣＵにおけるプロセッサ負荷、メモリ使用量、および通信バス使用量、等を含むことができる。

次に、推定手段ＶＡＳＥＭは、車両状態を推定し（ステップ８０３）、管理手段ＤＲＩＭに車両状態を通知する。

次に、管理手段ＤＲＩＭは、更新プログラムに割り当てる資源を決定する（ステップ８０４）。資源は、たとえばプロセッサ負荷、メモリ使用量および通信バス使用量を含む。割り当てる資源の決定方法は、当業者が適宜設計可能である。たとえば更新プログラムに関連付けて必要な資源の量を示す情報を取得してもよい。また、車載型コンピュータシステムにおいて利用可能な資源に応じて、割り当てる資源の量を変化させてもよい。

次に、管理手段ＤＲＩＭは、更新プログラムの実行開始（またはインストール）と、冗長プログラムの実行終了とに必要な時間を決定する（ステップ８０５）。冗長プログラムとは、更新プログラムに対して冗長なプログラムを意味する。たとえば、ある更新プログラムが、計画プログラムの機能をすべて含んでいる場合には、計画プログラムは、その更新プログラムに対する冗長プログラムとなる。

ある更新プログラムについて、どのプログラムが冗長プログラムとなるかの決定方法は、当業者が適宜設計可能である。たとえば各プログラムにＩＤを付与しておき、あらかじめ更新プログラムに冗長プログラムのＩＤを関連付けておいてもよい。その場合には、ステップ８０１において更新プログラムとともに冗長プログラムのＩＤを取得することによって、冗長プログラムを特定することができる。または、車載型コンピュータシステムは、更新プログラムと同一種類のデータ（たとえば同一の表示装置に対するデータ）を出力するプログラムを、冗長プログラムであると決定してもよい。

また、実行開始および実行終了に必要な時間の決定方法は、当業者が適宜設計可能である。たとえば各プログラムのサイズに応じて決定してもよいし、各プログラムに当該時間を関連付けて事前に記憶手段に記憶しておいてもよい。さらに、他に様々な情報に基づいて計算または修正されてもよい。

次に、管理手段ＤＲＩＭは、更新プログラムの実行開始および冗長プログラムの実行終了に必要な時間が、所定の安全基準を満たすか否かを判定する（ステップ８０６）。たとえば、所定の基準時間以内に完了するか否かを判定する。更新プログラムの実行開始処理中および冗長プログラムの実行終了処理中には、各プログラムの機能が発揮されない期間が存在するため、この期間が車両の安全な制御に影響を及ぼすか否かを判断することが有益である。

ステップ８０６の安全基準は、固定であってもよいし、各プログラムに関連付けられた基準であってもよいし、他の条件に応じて変化する基準であってもよい。たとえばその時点の車速に応じて基準が変化してもよい。たとえば、停車中または低速走行時（駐車動作の実行中等）には、各プログラムの機能が発揮されない期間が多少長くとも安全に影響を及ぼさないと考えられるので、基準時間を初期値より長くすることができるが、高速走行時（高速道路の走行中等）には各プログラムの機能が発揮されない期間が長くなると安全に影響するため、短時間で処理を完了する必要があり、したがって基準時間は初期値より短くなる。

ステップ８０６において、必要な時間が安全基準を満たす場合には、車載型コンピュータシステムはプログラムの更新を行う（ステップ８０７）。たとえば、管理手段ＤＲＩＭが、車両状態と、更新プログラムの実行条件とに基づいて、更新プログラムを実行すべきＥＣＵ（第１ＥＣＵ。以下、「ターゲットＥＣＵ」という）を選択する。そして、選択されたターゲットＥＣＵに、更新プログラムおよび更新要求を送信する。これらを受信したターゲットＥＣＵは、実行手段ＤＲＩＣの機能により更新プログラムの実行を開始する。

また、管理手段ＤＲＩＭは、冗長プログラムの実行を終了させる。すなわち、冗長プログラムを実行しているＥＣＵ（ターゲットＥＣＵまたは他のＥＣＵ）に、当該冗長プログラムの終了要求を送信する。終了要求を受信したＥＣＵは、実行手段ＤＲＩＣの機能により冗長プログラムの実行を終了する。これによって、不要な資源の消費が抑制される。ここで、実行手段ＤＲＩＣは、当該冗長プログラムの実行を後に再開させるために必要な情報（プログラムＩＤまたはプログラムコード等）を記憶してもよい。

次に、測定手段ＶＬＡＳＥは、ステップ８０７における実行手段ＤＲＩＣの処理後のＥＣＵ状態を測定し、推定手段ＶＡＳＥＭに送信する（ステップ８０８）。

次に、推定手段ＶＡＳＥＭは、更新されたＥＣＵ状態等に基づいて車両状態を推定し、管理手段ＤＲＩＭに車両状態を通知する（ステップ８０９）。

次に、管理手段ＤＲＩＭは、更新プログラムの出力遅延制約が満たされているか否かを判定する（ステップ８１０）。出力遅延制約および判定処理の具体例は、図１０に関連して後述する。

ステップ８１０において、更新プログラムの出力遅延制約が満たされている場合には、ターゲットＥＣＵは更新プログラムの実行を継続し、これによって、車載型コンピュータシステムは新たなＡＤＡＳモードで動作する（ステップ８１１）。

ステップ８１１の後、実行手段ＤＲＩＣ（ターゲットＥＣＵに限らない）は、管理手段ＤＲＩＭを監視し、管理手段ＤＲＩＭの障害を検出した場合に、冗長プログラム（すなわち、管理手段ＤＲＩＭがステップ８０７において実行を終了させたプログラム）を再度実行させる（ステップ８１３）。このようにすると、障害となった管理手段ＤＲＩＭが不正に終了させた冗長プログラムの実行を再開することができる。なお、冗長プログラムを実行するＥＣＵの選択方法は、当業者が適宜設計可能であるが、たとえば当該冗長プログラムを最後に実行していたＥＣＵとすることができる。

一方、ステップ８１０において、更新プログラムの出力遅延制約が満たされていない場合には、車載型コンピュータシステムは所定の安全処理を実行する。本実施例では、安全ＡＤＡＳモードで動作する（ステップ８１２）。安全ＡＤＡＳモードの具体的内容は、当業者が適宜設計可能である。たとえば、自動運転中の車速の最大値を、通常時の最大値よりも小さい値に制限し、これによって、出力遅延制約が満たされない場合でも安全な運転ができるように車両を制御する。

ステップ８１３において冗長プログラムが再度実行開始された後、または、ステップ８１２の後には、車載型コンピュータシステムは以前の状態に復帰する（ステップ８１４）。ここで、復帰すべき状態（バックアップまたはチェックポイント）の決定方法および復帰のための具体的処理は、当業者が適宜設計することができる。たとえば、冗長プログラムおよび他のアプリケーションプログラムを回復または再インストールし、システムの再起動を行うことができる。

上述のステップ８０６（図８Ａ）において、更新プログラムの実行開始および冗長プログラムの実行終了に必要な時間が、所定の安全基準を満たさない場合には、車載型コンピュータシステムは、車両を安全に停車させることが可能か否かを判定する（ステップ８１５）。この判定の具体的な内容は、公知の自動運転技術等に基づき、当業者が適宜設計可能である。たとえば、車両が走行している道路、周囲の状況、車速、等に基づいて判定することができる。

車両を安全に停車させることが可能な場合には、車載型コンピュータシステムは、車両を安全に停車させた後に、図８Ｂのステップ８０７～８１４の処理を実行する。一方、車両を安全に停車させることが可能でない場合には、車載型コンピュータシステムは安全ＡＤＡＳモードで動作するか、または、その時点のＡＤ／ＡＤＡＳモードで継続的に動作する（ステップ８１６）。この場合には、更新プログラムは実行されない。

図９および図１０を用いて、更新プログラムおよび冗長プログラムに関する判定処理の例を説明する。図９は、実施例１における車載型コンピュータシステムに新たな機能が追加される動作例である。図１０は、実施例１における車載型コンピュータシステムにおいて用いられる情報の例を示す。

図９に示すように、ＥＣＵ２（９０３）が計画プログラムを実行している。ここで、計画プログラムの機能を含む、より高度なクライアントアプリケーションが車載型コンピュータシステムに入力された場合を想定する。このクライアントアプリケーションは更新プログラムであり、計画プログラムはクライアントアプリケーションに対する冗長プログラムとなる。すなわち、図示のように、クライアントアプリケーションをＯＮとし、計画プログラムがＯＦＦとすることを試みる。

図１０に示すように、クライアントアプリケーションに関する入出力制約１００１が予め定義されている。入出力制約１００１は、実行条件の少なくとも一部を表し、入力遅延制約および出力遅延制約を含む。入力遅延制約は、たとえばデータサイズおよび最大許容遅延を含む。図１０の例では、入力遅延制約は、１Ｍバイトのサイズの画像（たとえばカメラからの生画像）が、生成後（たとえばカメラからの出力後）、５０ｍｓ以内に、クライアントアプリケーションに入力されなければならない、というものである。

出力遅延制約は、たとえばデータサイズおよび最大許容出力周期を含む。図１０の例では、出力遅延制約は、２種類の制御情報（制御情報ＡおよびＢ）について、それぞれ１０バイトのサイズのデータが、クライアントアプリケーションから５０ｍｓ以内の周期で出力されなければならない、というものである。

ステップ８０７におけるターゲットＥＣＵの選択処理の具体例を、以下に説明する。本例において、ステップ８０７では、更新プログラムの実行条件および通信バスの接続構成を用いてターゲットＥＣＵを選択する。更新プログラムの実行条件は、たとえば入力遅延制約を含む（さらに出力遅延制約を含んでもよい）。

通信バスの接続構成は、たとえば入力遅延表１００２によって表される。入力遅延表１００２において、最上行は、カメラ画像（ＥＣＵ１において生成される）に関する入力遅延を表す。各列は、ＥＣＵ１から各ＥＣＵまでの入力遅延を表す。

ＥＣＵ１からＥＣＵ１までの入力遅延は、同一ＥＣＵであるため０である。これは５０ｍｓ以内であるため、ＥＣＵ１でクライアントアプリケーションを実行すると入力遅延制約が満たされる。このため、ＥＣＵ１はターゲットＥＣＵとすることができる。

ＥＣＵ１からＥＣＵ２までの入力遅延は、通信バス１（ＣＡＮ）を経由する場合には１０ｓである。これは５０ｍｓを超えるため、ＥＣＵ２でクライアントアプリケーションを実行する場合に、通信バス１経由で通信を行うと入力遅延制約が満たされない。一方、ＥＣＵ１からＥＣＵ２までの入力遅延は、通信バス２（イーサネット（登録商標））および通信バス３（イーサネット）を経由する場合には２０ｍｓである。これは５０ｍｓ以内であるため、ＥＣＵ２でクライアントアプリケーションを実行する場合に、通信バス２および３経由で通信を行うと入力遅延制約が満たされる。このため、ＥＣＵ２は、特定の通信ルートを用いる場合に限り、ターゲットＥＣＵとすることができる。

他のＥＣＵに係る入力遅延についても同様であるため説明を省略するが、ＥＣＵ３およびＥＣＵ５は、特定の通信ルートを用いる場合に限りターゲットＥＣＵとすることができ、ＥＣＵ４はいずれの通信ルートでも入力遅延制約が満たされないためターゲットＥＣＵとすることができない。このような判定処理により、適切なターゲットＥＣＵおよび通信ルートの選択が可能になる。

なお、通信ルートを限定する場合の具体的処理は、当業者が適宜設計することができる。たとえば、管理手段ＤＲＩＭは各ＥＣＵに対してクライアントアプリケーションの情報の伝送ルートを通知し、各ＥＣＵはこれに従って情報の送受信を行う。

この例のように、複数のＥＣＵをターゲットＥＣＵとすることができる場合には、どのＥＣＵをターゲットとして選択するかの判定基準として、ＥＣＵ状態を用いてもよい。たとえば、各ＥＣＵについて、プロセッサ負荷、メモリ使用量、および通信バス使用量に基づいて総合負荷を算出し、この総合負荷が最も低いＥＣＵをターゲットＥＣＵとして選択してもよい。総合負荷を算出する方法（関数等）は、当業者が適宜設計可能である。たとえばプロセッサ負荷、メモリ使用量、および通信バス使用量にそれぞれ重みを乗算したものの総和を総合負荷としてもよい。このような判定処理により、適切なターゲットＥＣＵの選択が可能になる。

入力遅延表１００２は、たとえば通信時間表１００３に基づいて生成することができる。通信時間表は、データサイズごとに、各通信バスを介する通信処理に要する時間を表す。または、入力遅延表１００２は、事前に作成され記憶されていてもよい。または、入力遅延表１００２は、更新プログラムに関連付けて取得されてもよい。

制御設計１００４は、クライアントアプリケーションの入出力の概要を示す。認識プログラムがカメラ画像を生成し、カメラ画像がクライアントアプリケーションに入力され、クライアントアプリケーションはカメラ画像に基づいて出力情報を生成し、この出力情報が操作プログラムおよび表示プログラムに入力される。

出力判定例１００５は、ＥＣＵ２をターゲットＥＣＵとした場合の出力遅延制約の達成状況（ステップ８０１において、管理手段ＤＲＩＭによって測定される）を示す。この例では、制御情報ＡおよびＢ双方がＥＣＵ２から５０ｍｓの周期で出力されている。周期がいずれも５０ｍｓ以内であるため、出力遅延制約は満たされていると判定される。

なお、出力判定例１００６は、ＥＣＵ２をターゲットＥＣＵとした場合の、ＥＣＵ３における出力遅延の状況を示す。ＥＣＵ３では操作プログラムが実行されており、制御情報Ａは不要であり、制御情報Ｂの出力周期は１００ｍｓである。

同様に、出力判定例１００７は、ＥＣＵ２をターゲットＥＣＵとした場合の、ＥＣＵ５における出力遅延の状況を示す。ＥＣＵ３では表示プログラムが実行されており、制御情報Ａの出力周期は１０．２ｓであり、制御情報Ａは不要である。

図１１は、実施例１における管理手段ＤＲＩＭと実行手段ＤＲＩＣとの関係の例を示す。管理手段ＤＲＩＭは、更新プログラムをＲＡＭ（ランダムアクセスメモリ）に記憶する。また、管理手段ＤＲＩＭは、所定の周期で、ハートビート信号を各実行手段ＤＲＩＣ（より具体的には、各実行手段ＤＲＩＣを実現している各ＥＣＵ）に送信する。

各実行手段ＤＲＩＣは、ハートビート信号の欠如に基づき、管理手段ＤＲＩＭの障害を検出する。ここで「ハートビート信号の欠如」とは、たとえばハートビート信号が所定のタイミングで受信されないこと、または、あるハートビート信号を受信してから次のハートビート信号を受信するまでの時間が所定の閾値を超えたことを意味する。

各実行手段ＤＲＩＣは、管理手段ＤＲＩＭの障害を検出した場合に、検出以降に管理手段ＤＲＩＭから受信した信号を無視する。また、各実行手段ＤＲＩＣは、管理手段ＤＲＩＭの障害を検知した場合に、他の実行手段ＤＲＩＣに障害情報を送信する。各実行手段ＤＲＩＣは、障害情報を受信した場合に、受信以降に管理手段ＤＲＩＭから受信した信号を無視する。このようにすると、管理手段ＤＲＩＭに障害が発生した場合に、それ以降に送信される誤った制御情報による車載型コンピュータシステムの誤動作が抑制される。

なお、図１０の例において、出力遅延制約は出力周期を表すが、変形例として、許容遅延を表してもよい。たとえば、図１０の例では、出力遅延制約は、２種類の制御情報（制御情報ＡおよびＢ）について、それぞれ１０バイトのサイズのデータが、クライアントアプリケーションから５０ｍｓ以内に出力されなければならない、というものであってもよい。

以上説明するように、実施例１に係る車載型コンピュータシステム、および、これを含む自動運転支援システムによれば、車載型コンピュータシステムのプログラム更新によって新たな機能を追加することができる。

上記は例であり、当業者は添付の特許請求の範囲から逸脱することなく適切な変形を加えることができる。

１０１…環境認識センサシステム
１０２…環境認識システム
１０３…計画システム
１０４…無線通信システム
１０５…物理ネットワーク通信システム
１０６…作用システム
１０７…車体・シャーシ制御システム
１０８…インフォテインメントシステム
１０９…ヒューマンマシンインタフェースシステム
１１０…ドライバー監視システム
１１１…車両制御システム
１１２…Ｖ２Ｘシステム
１１３…ドライバーインテンション
１１４…機能不全監視システム
１１５…パワートレインシステム
２０１，２０８…路側機（車外のコンピュータ）
２０２，２０４，２０５，２０９…車両
２０３，２０６…スマートインフラストラクチャ（車外のコンピュータ）
２０７…クラウドサーバ（車外のコンピュータ）
２１１…路面（車外のコンピュータ）
２１２…人工衛星（車外のコンピュータ）
３０１…路側機（車外のコンピュータ）
３０２，３０３…スマートインフラストラクチャ（車外のコンピュータ）
３０４…路面（車外のコンピュータ）
３０５…クラウドサーバ（車外のコンピュータ）
３０６…人工衛星（車外のコンピュータ）
３０７～３０９…車両
３１０…アプリケーションインテグレータ
４０１…規格Ｌ１
４０２…規格Ｌ２
４０３～４０８…センサ
４０９…略語
６０１…クラウドサーバ
６０２…車両
６０３…路側機
６０４…車載型コンピュータシステム
６０５…オンボード装置
６０６…環境センサ
６０７…車両センサ
６０８…ＡＤ／ＡＤＡＳアプリケーション
６０９…監視手段
６１０…パワートレインアプリケーション
６１１…車体制御アプリケーション
６１２…シャーシ制御アプリケーション
６１３…アクチュエータ
６１４…インフォテインメント手段
６１５…地図手段
７０１～７０５ ＥＣＵ
７０６～７１０…通信バス
９０１，９０３，９０４，９０９，９１１ ＥＣＵ
９０５～９０８，９１０…通信バス
１００１…入出力制約（入力遅延制約および出力遅延制約）
１００２…入力遅延表
１００３…通信時間表
１００４…制御設計
１００５～１００７…出力判定例
ＤＲＩＣ…実行手段
ＤＲＩＭ…管理手段
ＶＡＳＥＭ…推定手段
ＶＬＡＳＥ…測定手段

Claims (10)

1. 車外のコンピュータと通信可能な、車載型コンピュータシステムであって、
   前記車載型コンピュータシステムは複数のＥＣＵを備え、各ＥＣＵは通信バスを介して少なくとも１つの他のＥＣＵと通信可能であり、
   前記車載型コンピュータシステムは、
   前記ＥＣＵについて、ＥＣＵ状態を測定する測定手段と、
   前記ＥＣＵ状態と、前記通信バスの接続構成とに基づき、車両状態を推定する推定手段と、
   更新プログラムと、前記更新プログラムの実行条件とを取得する、管理手段と、
   を備え、
   前記管理手段は、前記車両状態と、前記実行条件とに基づいて、前記更新プログラムを実行すべき第１ＥＣＵを選択し、
   前記第１ＥＣＵは、前記更新プログラムを実行し、
   前記管理手段は、前記更新プログラムの出力遅延制約が満たされているか否かを判定し、
   前記管理手段は、前記更新プログラムに対して冗長な冗長プログラムの実行を終了させる、
   車載型コンピュータシステム。
2. 前記ＥＣＵは、前記管理手段の障害を検出した場合に、前記管理手段が実行を終了させた前記冗長プログラムを実行させる、請求項１に記載の車載型コンピュータシステム。
3. 前記管理手段は、前記更新プログラムをＲＡＭに記憶し、ハートビート信号を各前記ＥＣＵに送信し、
   各前記ＥＣＵは、前記ハートビート信号の欠如に基づき、前記管理手段の障害を検出し、
   各前記ＥＣＵは、前記障害を検出した場合に、検出以降に前記管理手段から受信した信号を無視し、
   各前記ＥＣＵは、前記障害を検知した場合に、他の前記ＥＣＵに障害情報を送信し、
   各前記ＥＣＵは、前記障害情報を受信した場合に、受信以降に前記管理手段から受信した信号を無視する、
   請求項１に記載の車載型コンピュータシステム。
4. 前記ＥＣＵ状態は、当該ＥＣＵにおいて実行中のプログラムを示す情報を含む、請求項１に記載の車載型コンピュータシステム。
5. 前記ＥＣＵ状態は、当該ＥＣＵにおけるプロセッサ負荷、メモリ使用量、および通信バス使用量を含む、請求項１に記載の車載型コンピュータシステム。
6. 前記更新プログラムの前記実行条件は、前記更新プログラムの入力遅延制約を含む、請求項１に記載の車載型コンピュータシステム。
7. 前記更新プログラムの前記出力遅延制約が満たされていない場合に、前記車載型コンピュータシステムは所定の安全処理を実行する、請求項１に記載の車載型コンピュータシステム。
8. 前記管理手段は、前記更新プログラムの実行開始および前記冗長プログラムの実行終了に必要な時間が、所定の安全基準を満たすか否かを判定する、請求項１に記載の車載型コンピュータシステム。
9. 前記安全基準は車速に応じて変化する、請求項８に記載の車載型コンピュータシステム。
10. 請求項１に記載の車載型コンピュータシステムと、前記車外のコンピュータとを備える、自動運転支援システム。

Images