JP6279727B2 - 自動車安全機能の検査 - Google Patents

Description

背景
本発明の実施形態は、自動車等の車両の安全機能を検査するためのシステム及び技術に関する。

近年の自動車、特に、乗用車には、多数の安全機能が設けられている。安全機能の例は、アンチロック・ブレーキシステム（ＡＢＳ）、横滑り防止装置（ＥＳＣ）、アダプティブクルーズコントロール（ＡＣＣ）等である。市販される車両にこれらの安全機能が組み込まれる前に、これらは試験又は検査される。これらの試験は、しばしば、公開前又は販売前の車両を、長期間又は多くのマイル数にわたって運転することを要求する。機能によって、このマイル数は、数十万マイルを超えることがある。多くの検査マイル数を要求する自動車安全機能又はシステムは、制動介入による前方追突の軽減である。特に、この制動介入が、車両のフルブレーキを含む場合には、検査マイル数が長くなる。検査マイル数が長くなる他の例は、完全自動制動による、後退走行時の衝突回避アシスタンス及び衝突軽減である。

概要
車両安全システム、特に、車両安全システム内のコントロール機能の開発及び検査は、膨大なデータを記録することを要求する。従って、コントロール機能に対する変更はデータを記録した後に可能になり、シミュレーション（例えば、安全機能起動時の車両特性のコンピューターシミュレーション）は、代表的な結果を提供する。このような機能及びシステムは、コンピュータによって制御され、ソフトウェア及び設計されたパラメータに依存し、車両が遭遇し得る多数の状況を明らかにするために選択される。コントロールソフトウェアは変更されることがあり、大量のデータを記録することによって、データ記録の時点で、変更されたコントロールソフトウェアが車両に組み込まれたかのように、シミュレーションが遅くなる。車両安全機能の開発及び検査の現在の方法は、検査のためにデータ全体又は総てのデータを記録することを含み、この機能を使用する実際の車両に対して、このデータが記録されなければならない（これは、システムを他の車両において開発する場合、又は、一般的な車両若しくはサンプル車両からのデータを使用し、このデータを特定の車両に応用することを試みる場合とは対照的である）。しかし、このような現在の方法は、次の欠点を有している。即ち、代表的な車両が、安全機能の開発の早期の段階で入手可能でなくてはならない、又は、データをさらに収集するために、多数の車両が、開発の後期の段階で入手可能でなければならない、という欠点である。一般的に、検査に必要な、多くのマイル数を運転するのには長い時間がかかり、且つ、カバーされる必要がある運転状況の種類は多い。これは例えば、多数の種々の都市、幹線道路、地方道路、丘、交差点及び道路や運転基盤における他の変化である。さらに、膨大な量のデータが格納されなければならず、機能を検査するために、特に、誤起動率が十分に低くなるように機能を調整するために、最新のソフトウェアによって収集されたデータをシミュレートするのには、十分な計算機能が使用可能でなければならない。

安全機能に対する誤起動率が許容可能なリスクを下回る必要があるので、膨大な量のデータが記録されなければならない。これによって、適切な自動車安全度水準（ＡＳＩＬ：Ａｕｔｏｍｏｔｉｖｅ Ｓａｆｅｔｙ Ｉｎｔｅｇｒｉｔｙ Ｌｅｖｅｌ）による、機能自体の評価が可能になる。生産されるソフトウェアがこの目的を果たすことを保証するためには、記録された総てのデータをシミュレーションし直すことが、最も効率的である。効率性で劣る方法は、リリース毎に、統計的な信頼性のために必要とされる距離を運転することであろう。

本発明の他の観点は、詳細な説明及び添付の図面を考慮することによって明らかになるであろう。

安全システム及びコントローラ（これはプロセッサ、メモリ及びＩ／Ｏデバイスを含み得る）を有する車両（例えば自動車）の概略図。 サーバと通信するデータロガー及び接続ユニット又はインタフェースと通信する車両システムの概略図。

詳細な説明
本発明の実施形態を詳細に説明する前に、本発明の適用は、以下の説明に記載されている、又は、以降の図面に示されている構造の細部及び部品の配置に制限されない、ということが理解されるべきである。本発明は、他の実施形態を受け入れる余地があり、且つ、種々の態様で実現又は実行され得る。

図１は、４つの車輪１２、１４、１６及び１８並びに対応するブレーキ２０、２２、２４及び２６を各車輪に有している車両１０を示している。図示された実施形態では、ブレーキは、コントローラ３０と通信し、且つ、コントローラ３０によってコントロールされる。この車両コントローラは、例えば、エレクトロニックコントロールユニット（ＥＣＵ）、マイクロプロセッサ、マイクロコントローラ又は類似のデバイスの形態であってよく、プロセッサを含み得る。このプロセッサは、コントローラのメモリ、例えばＲＯＭ、特にＥＥＰＲＯＭに格納されているソフトウェアを実行する。広義には、ブレーキがアクチュエータである。他の車両安全システムでは、アクチュエータは、ハンドルを回転させる部品及びシャシー部品を操作する部品（例えば、ばね定数又はアクティブサスペンションにおけるショックアブソーバの堅さの変更）を含み得る。ブレーキは、他のシステムの一部であり得る。これは例えば、アンチロック・ブレーキシステム及び／又は横滑り防止装置である。図示されている実施形態では、コントローラ３０は、レーダセンサ３５、並びに、前向きのセンサ３７（例えばカメラ、超音波センサ、又は、他のセンサ若しくはセンサアレイ）、及び、後ろ向きのセンサ３９（例えばカメラ、超音波センサ、又は、他のセンサ若しくはセンサアレイ）をコントロールし、且つ、これらに接続もされている。レーダセンサ３５、前向きのセンサ３７、ブレーキ及びＥＳＣ５０、及び／又は、他の部品は、制動による前方追突の軽減システムの一部であり得る。コントローラは１つしか示されていないが、車両１０が複数のコントローラを含んでいてもよく、これら複数のコントローラの各々が特定の車両システム又は安全機能をコントロールするように構成されていてよく、これら複数のコントローラの各々が、このようなコントロールを行う適当なソフトウェアを実行し、相互に通信し得る、ということを理解されたい。さらに、コントローラ３０は中心位置に示されているが、本発明の実施形態は、適当なセンサ及びアクチュエータ（例えば、センサ３５、３７及び３９並びにブレーキ２０、２２、２４及び２６）、並びに、システムに局所的に配置されたコントローラを使用してもよい。コントローラ３０とセンサ３５、３７及び３９並びにブレーキ２０、２２、２４及び２６との間の接続は、直接的なリンクとして示されている。しかし、この車両にバス又はネットワークが設けられていてもよい。これは例えば、コントローラエリアネットワーク（ＣＡＮ）である。さらに、コントローラ３０と他のコントローラ及びデバイスとの間の通信は、ＣＡＮを通じてメッセージを送信することによって実現されていてもよい。例えば、車両システムは、センサ及びステアリングシステム４５内のデバイスからデータを受信するステアリングコントロール４３を含み得る。

自動車安全システム又は機能では、自動車安全機能の最適な又は所望の有効起動対誤起動の比率を特定するのに著しい労力を要する。本発明の態様は、自動車安全機能が起動されるべきか否かを決定するための多数の技術又はプロセスを含んでいる。特定の実施形態では、異なる実装又はパラメータ調整を有しているこれらのプロセスが並行して実行される。最初に、これらのプロセス（例えば、ソフトウェアプログラム、ソフトウェアモジュール又はソフトウェアアルゴリズム）を実行することによってデータが収集される。ここで、アクチュエータ（例えばブレーキ、サスペンション又は操舵部品）に、応答するように命令を出すプロセスは実行されない。但し、アクチュエータの検査のために起動されることがある、最後に応答するプロセスは除外することがある。開発プロジェクトの後期の段階では、（他のプログラムと比較して）有効な警報の要件と誤った警報の要件とに最も適合するプロセス又はソフトウェアプログラムが選択され、選択されたこのソフトウェアの出力がアクチュエータをトリガするように、車両コントローラ又はＥＣＵ（例えばコントローラ３０）が構成される。

文脈に別段の定めがない限り、本願で使用されている用語「起動」とは、あるソフトウェアプログラムが起動を報告することをいい、これは、もしこのソフトウェアプログラムの出力が使用されたのならば、幾つかのアクチュエータ又は部品が起動されたことを意味する（例えば、車両ブレーキを用いて）。この所望のソフトウェアプログラムが、選択され、起動するようにプログラミングされてはじめて、実際に起動が生じることになる。

本発明の特定の態様では、いつ起動が発生するかの反応性がソフトウェアプログラム毎に異なるように、種々のソフトウェアプログラムが設計される又は構築される。有利には（しかし必須ではなく）、多数の種々のソフトウェアプログラムが存在し、これらのソフトウェアプログラムは、様々な人によって開発され、実装される。他の方法は、ソフトウェアプログラムロジックを固定するが、種々の反応性に対して種々のパラメータをロードすることである（これは、開発コストを低減するのに有利であり得るが、同じ程度の多様性及びソフトウェア自体の変化を提供しない）。

各ソフトウェアプログラムは車両のコントローラにおいて実行され（その例は、図１に関して上述した）、結果が（例えば、（以下で説明する）データロガー１１０に）記録され、一旦、最終的なソフトウェアプログラムが選択されると、処理時間もフラッシュファイルも変更されない。各ソフトウェアプログラムが引き起こした起動の数は（メモリに）（この起動に関する付加的なデータとともに）記録される。特定の実施形態では、この起動に関するデータは、診断ツールを用いて読み出し可能であり、開発の間、有利には、このデータは容易にアクセス可能であり、例えばＣＡＮ等の車両ネットワークを通じて提供可能である。起動データを収集することによって、有効起動対誤起動の比率に関する統計が、各種々のソフトウェアプログラムに対して導出される。

ある機能起動は有効である又は所望されているものであり、他の機能起動は誤起動である。従って、特定の実施形態では、コントローラがこれら２つを区別することができるように、コントローラに選別器が実装される。誤起動を特定する１つの方法は、特定のＧＰＳ座標で、又は、座標近隣で、又は、オドメータの情報を用いて定められた所定の距離で発生する起動の数を計数する又は記録することである。従って、例えば、同じ起動の数が閾値（例えば５）を、所定の範囲（例えば２５フィート）において超えると、誤起動が発生したことが想定される。有利には、選別器は次のように構成されている。即ち、各ソフトウェアプログラムの各起動に対する運転手の反応を評価するために、事後評価として動作するように構成されている。制動による前方追突の軽減の例では、以下のうちの少なくとも１つが発生するので、有効起動のケースが誤起動のケースと区別される。即ち、（ａ）運転手が強くブレーキをかける、（ｂ）運転手が回避的な操作を実行する、（ｃ）衝突が発生する。特定の実施形態では（ａ）及び（ｂ）に対する閾値が開発され、このような操作が実行されたか否かが特定される。これは、ドライビングシミュレータを用いて、又は、現実世界の、事故に近い状況からのデータを用いて行われる。ターゲット車両が急にハンドルをきる、又は、運転手が誤起動と誤解して反応してしまう幾つかの有効起動のケースが存在する。このようなケースは、統計的に無視してよい程、僅かであることが想定される。また、（機能自体のように）選別が予測的に機能するのではなく、ソフトウェアプログラムが起動をトリガした後に、どのように運転手が反応したのかに関する事後分析として機能する、ということが想定される。そのため、見逃されるセンサエラー又は状況分析エラーの数が極めて少ないことが想定される。

何らかのソフトウェアプログラムが機能を起動する度に収集されるデータは、例えば、以下のものであり得る。
ａ）この起動を引き起こしたソフトウェアプログラム
ｂ）運転手がブレーキをかけたのか、衝突を回避したのか、衝突が発生したのか、又は、反応しなかったのかの事後評価結果
ｃ）基盤の検査を可能にするＧＰＳ情報又は座標（利用可能である場合）
ｄ）反応のオドメータ値
ｅ）ホスト車両状態、即ち、速度、ヨーレート、対地加速度、加速度センサ等。理想的にはこの情報は、起動地点から、起動から幾らかの間隔（例えば２００ミリセカンド毎）を空けた、幾つかの（例えば２つの）第２地点まで、得られるべきである。
ｆ）ターゲット車両状態、即ち、速度、水平方向及び縦方向の距離等。有利にはこの情報は、起動地点から、起動から幾らかの間隔（例えば２００ミリセカンド毎）を空けた、幾つかの（例えば２つの）第２地点まで、得られるべきである。
ｇ）運転手反応状況、即ち、ブレーキペダル位置及びアクセルペダル位置。有利にはこの情報は、起動地点から、起動から幾らかの間隔（例えば２００ミリセカンド毎）を空けた、幾つかの（例えば２つの）第２地点まで、得られるべきである。
ｈ）閾値を計算するのに使用されたあらゆるデータ。これは事後に確定され、車両製造プラントにおいて、安全システムのメモリ（例えばＥＰＲＯＭ）内に（ソフトウェアプログラムの選択とともに）書き込まれる。有利には、起動の少し前から、起動後のいずれかの時点までの各計算サイクルが格納される。これは、安全機能又は機構の後調整時に、他の計算サイクルが起動を生じさせたであろうか否かを確実にするのを補助するために必要である。

本発明の特定の態様では、起動データが直ちにメモリに書き込まれるように、診断プログラムが設定される、又は、構築される。その理由は、例えば、衝突が生じ、車両にダメージが与えられ、衝突発生後の特定の時間、データを書き込むことができない場合（例えば、ＥＣＵに対する電力低下）に、センサ内に起動の記録が存在するからである。

一般的に、車両製造者（例えばＯＥＭ）は、量産開始（ＳＯＰ）の約２ヶ月前に、量産を代表する車両を入手する。これらの車両は、最終的な仕様又は最終的な仕様に近い仕様に従って構築されており、且つ、最終的なプラントプロセス又は最終的なプラントプロセスに近いプラントプロセスに従って構築されている。その後、これらの車両には、通常、僅かなマイナーチェンジしか加えられない。この段階で入手可能な車両の数は、通常、数百台の規模であり、一般的にこれらの車両は、多数の異なる運転手によって公道上で運転される。さらに、この車両のあらゆる変形又はモデルが、この段階で構築される。これらの車両からのデータは、（プロトタイプ又は一般的な車両からのデータと比べると）理想的である。なぜなら、これらの車両によって幅広い状況がカバーされ、データが収集されるだけでよいからである（製品車両の特定の特徴を明らかにするために修正される必要はない）。一般的に、自動車安全機能は、データ収集に影響を与えることがないように、この段階でオフされなければならない。又は、最も基本的な、最後に反応するソフトウェアが起動されるべきである。

幾つかの車両が、自動車安全機能に対する試験、横滑り防止装置（ＥＳＣ）に対する試験及び同様の試験を実行するために、テストコース上で用いられる。このようなテストコース上での試験によって起動が生じることがあり、一般的にこれらは、有効起動のケースとしてクラス分けされる。現実世界で発生する有効起動ケース数と違いが無いようにするために、テストコース検出は、（ａ）ＧＰＳ座標を評価すること、又は、（ｂ）ＧＰＳ座標が利用可能でない場合に、長い距離を走っていないにも拘わらず起動数が著しく多いときには、これがテストコース状況である可能性が高いと評価され得る、ことによって行われる。

データが一旦、収集され、評価されると、誤起動目標を達成しながらも、（他のプログラムと比べて）最も高い有効性を有するソフトウェアプログラムが選択される。おそらく、自動車センサは、この時点では製作途中であるので、所望のソフトウェアプログラムが診断コマンドを用いて選択可能であるべきである。どの機能が使用されるべきであるかをセンサに示す診断コマンドを、プラントで（例えば、センサがプラントモードから取り出される又はあらゆる他の診断が行われるのと同じ場所で）、各センサに設けることができる。異なったソフトウェアプログラムを起動するといった誤用を阻止するために、特定の実施形態では、診断コマンドは起動コードを有している。この起動コードは、定期点検時の、又は、必要な場合には他の用途での部品交換のために、組み立てプラントにだけ与えられる。

安全システム開発の後期の段階で閾値パラメータを設定することが可能であるように、及び、これらのパラメータをメモリ（例えばＥＥＰＲＯＭ）内に格納するために（最終的な組み立てプラントにおいて）診断プログラムを介してこれを伝達することが可能であるように、ソフトウェアプログラムを構築することも可能である。その結果、事後設定可能なオプションの数を増やすことはできるが、これは、ソフトウェアをより複雑にしてしまうことがある。閾値が事後調整可能にメモリ内にある場合、各パラメータの値は、各機能起動とともにデータ内に格納される。各機能起動とともに格納されたこのデータは、計算サイクル毎に現れないかもしれず、また、このデータが格納されているスペースを節約するために切り捨てられ得るので、このような閾値を正確に決定するように注意が払われる。これらの値は、組み立てプラントにおいても設定されなければならないので、このデータは、データ改ざんを阻止するために暗号化されてよく、１つの実施形態では、完全なデータセットが、センサのメモリに書き込まれたことを確実にするために、チェックサム特徴が利用される。

１つの実施形態では、前述したように、例えば、９つの異なるプログラムが開発される、又は、定められる。先行する段落に記載したように、多くのパラメータの閾値は、起動に対する水平方向のオフセットの場合は１．４ｍ、存在確率の閾値の場合には８５％、運転手操舵の場合には、ハンドルにおける２０度毎秒未満、といったように設定される。これらの閾値は総て、個々に、診断コマンドを介してコントローラに伝達され、最終的なプログラムのパラメータを設定するためにセンサに格納される。

本願に記載された技術及び実施形態は、全コントローラデータ又はＥＣＵデータを記録することなく、自動車安全機能を検査する方法を示しているが、依然として、何らかの新たな機能を開発するために（又はいずれかのソフトウェアプログラムにおける変更のために）、また、事後分析及び診断プログラムを介して収集されたデータが正確であることを検証するために、全コントローラデータの一部を記録することが望ましい。現実世界では有効起動ケースが存在するが、テストコース上では最も高い有効性を有するケースが検査され、有効起動率を比較するために、総ての異なるソフトウェアプログラムに対して評価が実行されることが見込まれる。

本発明の実施形態及び態様は、自動車安全機能を検査するために収集される必要がある全データのマイル数を低減するために役立つ。さらに、態様及び実施形態は、たとえ似ていなくても、他の車両で安全機能を開発することを可能にする（その理由は、ターゲット車両が早期の段階で入手可能でないかもしれず、特に、開発時間を短縮する傾向があるからである）。従って、多くの点でコスト削減が実現され得る。これは以下のものを含み得る。
１）検査マイルの収集を行うのに必要なプロトタイプ車両の数が減少する。
２）収集される必要がある「完全内部コントローラデータ又はＥＣＵデータ」が減少する。
３）他の、無関係な車両からの引き継ぎが基本的に可能になる。この態様は、生産量の少ない車両に対して有用である、又は、代表的なプロトタイプが極めて遅い段階で得られるプロジェクトにおいて有用である。
４）実際に必要とされるよりも多くの検査マイルが走行され、より信頼性の高い統計が得られる。運転状況の総てのタイプをより良好にカバーすることができる。
５）車両販売後に、質的な問題が発見された場合には、（オン／オフ切り替え以外、及び、コントローラ又はＥＣＵのメモリの再フラッシュ以外の）さらなる開発を行うことなく、販売代理店において自動車安全機能の調整が迅速に再構築される。
６）例えば、ハードウェアの変更、ソフトウェアのバグ又は安全システムのセンサに影響を与え得る他の部品（例えば超音波センサが組み込まれている計器盤）が原因で、再検査が必要とされる場合、この検査を、迅速に、且つ、低いコストで行うことができる。
７）パートナーコントローラ若しくはＥＣＵが変更された場合、又は、車両の量産開始の直前にしか代表的な部品が得られない場合でも、本発明を実行することによって、検査を行うことが可能である。特に、部品は、一般的に、車両の量産開始の６週間乃至１０週間前に製造されるので、製造された総てのユニットの再フラッシュは、量産開始まで遅延させられることがある。

図２は、システム１００を示している。このシステムにおいて、及び、このシステムによって、本発明の態様が実行され得る。システム１００は、サーバ１０５の形態のコンピュータを含む。これは、車両部品、例えば、センサ３５、３７及び３９、ブレーキ並びに他のシステム、例えば横滑り防止装置５０、ステアリングシステムコントロール４３及びコントローラ３０と通信する。車両部品は、例えば車両ＣＡＮに接続されているデータロガー１１０と通信する。このデータロガーはデータを記録し、上述したようにイベントを起動する。接続性ユニット又は通信インタフェース１１５は、データロガー１１０とサーバ１０５との間の通信リンクを提供する。サーバ１０５は、コントローラ３０によって及び／又は車両システムによって実行されるプログラムを格納する（例えば、横滑り防止装置５０、制動よる前方追突の軽減等）。段落１３、１５、１９及び２０等に記載されている上述した診断プロセスを実行するために、診断ツール１２０が、通信インタフェース１１５に接続され得る。

本発明のさらなる特徴及び利点は、以下のクレームに記載されている。

Claims (5)

1. コンピュータにより実現される少なくとも１つの安全機能と、車両コントローラと、１つ又は複数の車両アクチュエータとを有する車両の車両安全システムの車両安全機能を検査する方法であって、
   コンピュータにより実行可能な複数の車両安全機能ソフトウェアプログラムを開発し、
   前記コンピュータにより実行可能な複数の車両安全機能ソフトウェアプログラムのうちの第１のソフトウェアプログラムを車両コントローラのメモリ内にインストールし、
   前記コンピュータにより実行可能な複数の車両安全機能ソフトウェアプログラムのうちの前記第１のソフトウェアプログラムを実行した結果として生じた、前記車両コントローラの少なくとも１つの車両アクチュエータ出力を搬送することなく、前記コンピュータにより実行可能な複数の車両安全機能ソフトウェアプログラムのうちの前記第１のソフトウェアプログラムを前記車両コントローラにおいて実行し、
   前記車両コントローラの前記少なくとも１つの車両アクチュエータ出力が前記１つ又は複数の車両アクチュエータに搬送されていたとすると、どこで、前記コンピュータによりコントロールされる少なくとも１つの安全機能が車両アクチュエータを起動したかをデータロガー内に記録し、
   前記インストール、前記実行及び前記記録のステップを、前記コンピュータにより実行可能な複数の車両安全機能ソフトウェアプログラムのうちの第２のソフトウェアプログラムにより繰り返す、
   ことを含むことを特徴とする、車両の車両安全システムの車両安全機能を検査する方法。
2. 前記コンピュータにより実行可能な複数の車両安全機能ソフトウェアプログラムの各々は、調整可能なパラメータを含み、
   当該方法はさらに、診断ツールからの診断コマンドを用いて、前記調整可能なパラメータを設定することを含む、請求項１記載の方法。
3. さらに、前記診断コマンドを暗号化することを含む、請求項２記載の方法。
4. さらに、前記コンピュータにより実行可能な複数の車両安全機能ソフトウェアプログラムの前記第１のソフトウェアプログラムと前記第２のソフトウェアプログラムとのどちらを前記車両安全システムにおいて使用するのかを選択することを含む、請求項１記載の方法。
5. さらに、センサで使用される、コンピュータにより実行可能な車両安全機能ソフトウェアプログラムを選択するために診断コマンドを使用することを含む、請求項４記載の方法。

Images