JP2019197390A - 移動体異常時制御装置、移動体異常時制御システムおよびその方法 - Google Patents

Abstract

【課題】異常が発生した場合の分析を適切に行なう。【解決手段】ホスト装置（１００）との間でデータをやり取りする移動体異常時制御装置（６０）は、移動体（１０）の異常を検出する検出部（６１）により異常が検出された際の移動体の状況を検出し、前記検出した状況の少なくとも一部を記憶する。こうした異常が検出されたとき、該異常の内容を表わす異常情報をホスト装置に送信し、送信した異常情報に対してホスト装置が送信する異常分析プログラムを、移動体側で実施可能に記憶し、異常が検出された際に記憶された移動体の状況に対応した異常分析条件が満たされたときに、異常分析プログラムを実行する。【選択図】図２

Description

本発明は、移動体異常時の制御に関する。

車両などの移動体は、移動体を駆動する装置や、移動方向・移動速度などを制御する装置など、複雑な装置構成を備える。このため、走行などの移動中に、異常が発生したとき、どの部位にどのような異常が発生したかを、調べる必要が生じる。そこで、移動体には、何らかの異常が発生すると、これを記録し、いわゆるダイアグ情報として、出力するものが提案されている（例えば特許文献１）。

特開２００５−２８４８４７号公報

特許文献１のシステムでは、車両において何らか異常が検出されると、ダイアグ情報をセンター装置に送信し、センター装置から異常診断用のプログラムやそのプログラムを動作させるシナリオを受信し、これらに沿って車載機器に対する故障部位の特定や診断を行なう。

しかしながら、実際の車両では、こうした診断プログラムを受信したシナリオに沿って動作させても、故障部位の特定や故障内容の診断を十分に行なえないことがあった。何らかの異常が生じたことがダイアグ情報の送信などで検知できても、異常によっては、再現性の低いものがあり、どのような場合に生じる不具合であるかを特定することができないことがあった。特に、近年のように、車両等の移動体の制御が複雑化してくると、制御対象毎に制御用コンピュータ（以下、ＥＣＵという）が備えられていることも多く、一つのＥＣＵが異常を検出したからと言って、そのＥＣＵに診断プログラムを実行させても、故障部位の特定や原因などを行なえないということも少なくなかった。

本件は、以下の形態又は適用例として実現することが可能である。

一実施態様として、ホスト装置との間でデータをやり取りする移動体異常時制御装置が提供される。この移動体異常時制御装置（６０）は、移動体（１０）の異常を検出する検出部（６１）と；前記異常が検出された際の前記移動体の状況を検出し、前記検出した状況の少なくとも一部を記憶する記憶部と；前記異常が検出されたとき、当該異常の内容を表わす異常情報を前記ホスト装置に送信する異常情報送信部（６４，７０）と；前記送信した異常情報に対して前記ホスト装置が送信する異常分析プログラムを実施可能に記憶し、前記異常が検出された際に記憶された前記移動体の状況に対応した異常分析条件が満たされたときに、前記異常分析プログラムを実行する実行部（６１，６５）と；を備える。この移動体異常時制御装置は、異常が検出されると、必要な情報をホスト装置に送信し、これに対してホスト装置が送信する異常分析プログラムを実施可能に記憶し、異常が検出された際に、記憶された移動体の状況に対応した異常分析条件が満たされたときに、異常分析プログラムを実行する。従って、異常の分析を適切に行なうことできる。

第１実施形態の車両の概略構成図。 第１実施形態の車両の構成をダイアグＥＣＵを中心に示すブロック図。 各ＥＣＵが実行する運転処理ルーチンを示すフローチャートである。 異常時制御システムとして、車両側ダイアグ処理ルーチンと管理センター処理ルーチンとを対にして示すフローチャート。 トラップソフト実行処理ルーチンを示すフローチャート。 第２実施形態における異常時制御システムとして、車両側ダイアグ処理ルーチンと管理センター処理ルーチンとを対にして示すフローチャート。 複数車両トラップソフト実行処理ルーチンを示すフローチャート。

Ａ．第１実施形態：
Ａ１．第１実施形態のハードウェア構成：
第１実施形態の異常時制御装置および異常時制御システムについて説明する。第１実施形態において、車両１０は、車両各部の制御を行なう複数のＥＣＵ（電子回路装置）を備え、各ＥＣＵが図示しない車内ＬＡＮ（ＣＡＮ）を介して、データのやり取りを行なっている。車両１０には、エンジン２０とこれを制御するエンジンＥＣＵ２１、変速機３０とこれを制御する変速機ＥＣＵ３１、制動装置４０とこれを制御する制動ＥＣＵ４１、空調装置５０とこれを制御する空調ＥＣＵ５１、これらのＥＣＵが接続された異常時制御装置に相当するダイアグＥＣＵ６０、外部とのデータのやり取りを行なう通信装置７０などが搭載されている。

エンジン２０は車両１０の駆動力を発生する内燃機関であり、図示しない燃料供給系や点火系など、周知の構成を備える。エンジンＥＣＵ２１は、燃料供給系における燃料噴射弁の制御や、点火系における点火時期制御、などエンジン２０に関する制御を実施する。

変速機３０は、エンジン２０のクランク軸の回転数を変速するものであり、ＣＶＴなどいずれの形式であるかを問わない。変速ＥＣＵ３１は、車両１０の速度や必要トルクなどを検出し、必要な変速比を求めて、変速機３０の変速比を制御する。変速機３０の出力は、ディファレンシャルギア３２を介して、駆動輪である後輪３５，３６に伝達される。

制動装置４０は、車両１０を制動する制動力を調整する油圧装置である。制動装置４０は、後輪の車軸に設けられたホイールシリンダ４５，４７に送り込む油圧を制御する。図１では、後輪３５，３６側のブレーキのみを示しているが、実際には全車輪に、ホイールシリンダ４５，４７や、ブレーキディスク４６，４７等を備えたディスクブレーキ装置が設けられている。後輪側の車軸に設けられたブレーキディスク４６，４８は、ホイールシリンダ４５，４７に付設のディスクパッド（不図示）よって挟み込まれる構造となっており、ディスクパッドとブレーキディスクとの摩擦力により、制動力を発生する。ホイールシリング１９〜２２を駆動する油圧は、制動力ＥＣＵ４１により制御される。制動力ＥＣＵ４１は、図示しないブレーキペダルの踏込量等に基づく、各車輪に必要な制動力を算出し、各ホイールシリンダ４５，４７に送り込む油圧を、制動装置４０を用いて制御する。

空調装置５０は、図示しないラジエータやコンプレッサを駆動して、温風や冷風を車室内に吹き出し、車室内の空気調和を実現する装置である。空調ＥＣＵ５１は、車室内の温度などを検出し、空調装置５０の動作を制御する。

ダイアグＥＣＵ６０は、車両１０全体の動作状態の診断（ダイアグノーシス）を行なう。ダイアグＥＣＵ６０は、エンジンＥＣＵ２１，変速機ＥＣＵ３１，制動力ＥＣＵ４１，空調ＥＣＵ５１などに、車内ＬＡＮにより接続されており、各ＥＣＵから、各ＥＣＵが制御する各装置の状態、特に正常でないと判断された場合の情報を受け取る。また、ダイアグＥＣＵ６０は、通信装置７０に接続されており、通信装置７０を介して、後述する管理センターと通信し、様々な情報をやり取りする。車両１０のダイアグＥＣＵ６０と管理センターとの情報のやり取りに付いては、あとで詳しく説明する。

車両１０には、この他、操舵を行なうためのハンドル８０やハンドル８０の動きを左右の前輪８３，８４に伝達する操舵ギア８１等を備える。なお、図示の都合上、記載を省略したが、車両１０には、前輪８３，８４を制動するブレーキ装置が設けられている。また、その他、車両１０として必要な機器、例えばスタータモータやバッテリなども搭載されていることは勿論である。

次に、図２を用いて、車両１０における制御情報のやり取りを、ダイアグＥＣＵ６０を中心に説明する。図２に示したように、ダイアグＥＣＵ６０は、処理を行なうＣＰＵ６１、接続される他のＥＣＵやセンサ群とのデータのやり取りを司る入出力部６２、プログラムやデータを記憶する記憶部６３などを備える。

入出力部６２には、前述したエンジンＥＣＵ２１、変速ＥＣＵ３１、制動力ＥＣＵ４１、空調ＥＣＵ５１と共に、センサ群９０が接続されている。センサ群９０には、車両１０に搭載されている全てのセンサが含まれる。センサ群９０に含まれるセンサを例示すると以下の通りである。
・車両１０の位置を検出するＧＮＳＳセンサ９１、
・車速を検出する車速センサ９２、
・エンジン２０のシリンダに配置された燃焼圧を検出する燃焼圧センサ９３、
・車両１０の加速度を検出する加速度センサ９４、
・車両１０に生じるヨーレートを検出するヨーレートセンサ９５、
・制動装置４０における油圧を検出する油圧センサ９６、
・エンジン２０の冷却水温を検出する水温センサ９７、
・車室内の温度を検出する温度センサ９８。

以上のセンサは例示であり、他のセンサ、例えば車両のロールやピッチを検出するセンサや、スリップ率、制動力などを検出するセンサ、等を採用することも差し支えない。また、車両１０の制御に用いられる各種センサもセンサ群９０に含まれる。これらのセンサ群９０に含まれる各センサは、図２では、ダイアグＥＣＵ６０の入出力部６２に接続されているものとして描いたが、実際には、それぞれのセンサの情報を直接的に必要とするＥＣＵに接続されている。ダイアグＥＣＵ６０は、車内ＬＡＮを介して、各ＥＣＵから、センサ群９０に含まれるセンサの検出値を受け取るので、便宜的に図２のように記載した。もとより、車内ＬＡＮを利用してデータの共有を図ることができるので、いずれのＥＣＵに接続されているセンサの検出値であっても、ダイアグＥＣＵ６０を含む他のＥＣＵで、いつでも参照できるようにすることは容易である。

ダイアグＥＣＵ６０の記憶部６３には、ダイアグＥＣＵ６０の制御用のソフトウェアを記憶するダイアグソフト格納部６４、車両の異常を分析する異常分析プログラムであるトラップソフトウェアを記憶するトラップソフト格納部６５、車両１０の各部に生じた異常を記憶する異常記憶部６７、トラップソフトの実行条件を記憶する車両状況記憶部６８が備えられている。ダイアグＥＣＵ６０は、通常はダイアグソフト格納部６４に格納された処理プログラムを実行し、各ＥＣＵ２１，３１，４１，５１が送信する車両の状態を監視し、特に異常が生じた場合は、発生した異常を異常記憶部６７に記憶する。ここで「異常」とは、予め設定された状態から逸脱した状態であり、車両１０を直ちに停止すべき状態のみならず、車両１０のインスツルメントパネルなどに表示して運転者に警告すれば足りる状態や、異常記憶部６７に記憶し検査の際に外部の診断装置に出力すればよい状態など、種々のレベルの状態が含まれる。

ダイアグＥＣＵ６０は、何らかの異常が生じたと判断すると、通信装置７０を介して管理センター１００とやり取りする。管理センター１００は、各車両との通信を行なう通信装置１０１の他、図示を省略した処理コンピュータや大容量の記憶部などを備える。記憶部には、配下の多数の車両が走行している各地域の気象情報などの環境データ１０２や、異常の原因を分析する多数のトラップソフトウェア（以下、トラップソフトとも呼ぶ）を記憶したトラップソフトデータベース（以下、トラップソフトＤＢとも呼ぶ）１０５などを記憶している。

環境データ１０２としては、気温や降雨量などの天候情報、大気圧や標高などの高度情報、交通渋滞などの交通状況などのデータを想定できる。また、トラップソフトＤＢ１０５が記憶しているトラップソフトは、車種毎、異常フラグの値（以下、異常コードという）ごとに用意されている。トラップソフトは、更に細かく、例えば、車種を年式毎に分けて、あるいは輸出先（仕様地）ごとに分けて、データベース化してもよい。

管理センター１００は、配下の多数の車両１０と通信装置１０１を介してやり取りし、異常が生じたことを通報してきた車両１０が走行している地域の環境データや、必要なトラップソフトを選択し、これらを車両１０に送信する。従って、車両１０のダイアグＥＣＵ６０と管理センター１００とは、異常時制御システムを構成する。

Ａ２．異常時制御：
以上説明したハードウェア構成の下で、各種ＥＣＵと管理センター１００とが実行する異常時制御について、図３以下を用いて説明する。図３は、各ＥＣＵが実行する運転処理ルーチンを示すフローチャートである。エンジンＥＣＵ２１などの各ＥＣＵは、制御対象であるエンジン２０などの装置の制御を行ないつつ、所定のインターバルで、図３に示したＥＣＵ運転処理ルーチンを実行する。

図３に示した処理を開始すると、各ＥＣＵは、まず自分が制御している対象の状態を示すセンサからの出力を読み取る処理を行なう（ステップＳ１０５）。センサの出力は、図２ではダイアグＥＣＵ６０を介して読み取るように示したが、既に説明したように、直接読み取る構成であっても良い。エンジンＥＣＵ２１を例にとれば、エンジンＥＣＵ２１はセンサ群９０の中から、車速センサ９２，燃焼圧センサ９３，加速度センサ９４，水温センサ９７などの出力を読み取る。もとより、図示を省略したアクセルの踏み込み量を検出するアクセルセンサ、クランク軸の角度を検出するクランク角度センサなど、他のセンサの出力を読み取っても差し支えない。

これらのセンサの出力を読み取った後、ＥＣＵは、整合性の確認を行なう（ステップＳ１１０）。整合性の確認とは、読み取ったセンサの値が、制御対象（例えばエンジン２０）の現在の状況に見合ったものであるかを確認することである。例えば、アクセルペダルの踏み込み量に基づいて、エンジンＥＣＵ２１は所定の燃料噴射量を指示するので、アクセルペダルの踏み込み量と、燃焼圧センサ９３が検出する燃焼圧とは、所定の関係を示す。従って、現在のアクセルペダルの踏み込み量と燃焼圧とが、想定の範囲に入っていれば、両者の整合性は取れていると判断する。他方、アクセルペダルが大きく踏み込まれているにもかかわらず、燃焼圧センサ９３が出力する燃焼圧が、それに見合った大きさになっていない場合などであれば、整合性がとれていないと判断する。

そこで、続いて、ステップＳ１１０での判断に基づき、異常が生じているか否かの判断を行なう（ステップＳ１２０）。整合性の確認は、多数の項目について行なわれるので、異常の判断はそれらを総合的に見て行なう。エンジンＥＣＵ２１を例に取れば、上記のアクセルペダルの踏み込み量と燃焼圧との整合性（第１整合性と呼ぶ）の他、例えばＧＮＳＳセンサ９１と加速度センサ９４と燃料噴射量との整合性（第２整合性と呼ぶ）を併せて確認し、総合的に異常が発生しているかを判断することが考えられる。第２整合性は、ＧＮＳＳセンサ９１から車両１０の現在の走行位置が上り坂でなく、燃料噴射量が十分に大きいにもかかわらず、加速度が所定値以下の場合に、整合性がとれていないと判断する。この結果、第１整合性と第２整合性が共にとれていなければ、エンジン２０は要求出力を出すための制御をしているにもかかわらず、出力が得られていないと判断し、何らかの異常が生じていると判断する。

この場合、ステップＳ１２０の判断は「ＹＥＳ」となり、ＥＣＵは異常発生を示す異常フラグをセットする処理を行ない（ステップＳ１３０）、同時に異常を検出した際の各センサの出力や演算した燃料噴射量などのデータをダイアグＥＣＵ６０に出力する（ステップＳ１４０）。ＥＣＵが出力するデータには、設定された異常フラグも含まれる。上記のステップＳ１４０の処理の後、あるいは、ステップＳ１２０で異常がなかったと判断された場合、「ＮＥＸＴ」に抜けて、本運転処理ルーチンを一旦終了する。

次に、車両のダイアグＥＣＵ６０と管理センター１００とが協働して行なう異常時制御について、図４を用いて説明する。図４の左欄は、車両１０が行なう車両側ダイアグ処理ルーチンを、右欄は管理センター１００が行なう処理ルーチンを、それぞれ示す。車両１０に搭載されたダイアグＥＣＵ６０は、所定のインターバルで図４左欄に示した車両側ダイアグ処理ルーチンを実行しており、本ルーチンを開始すると、まず異常フラグがセットされているか否かを判断する（ステップＳ２００）。異常フラグは、図３のＥＣＵ運転処理ルーチンを用いた説明したように、各ＥＣＵにおいて、何らかの整合性がとれていない状態が検出されたとき、各ＥＣＵがこれをセットし、ダイアグＥＣＵ６０に異常検出時のデータと共に出力する（図３、ステップＳ１４０）。ダイアグＥＣＵ６０は図示しない別の割込ルーチンにおいて、この異常フラグと異常時のデータとを受け取り、これを異常記憶部６７に記憶している。

異常フラグがセットされている場合には（ステップＳ２００：「ＹＥＳ」）、次に異常時送信データを準備する処理を行なう（ステップＳ２０５）。異常時送信データとは、各ＥＣＵから送信された異常フラグと異常時データとを含む。ダイアグＥＣＵ６０は、これらのデータを管理センター１００に送信する準備として、異常時送信データとしてのフォーマットに調える。なお、異常フラグがセットされていなければ（ステップＳ２００：「ＮＯ」）、何も行なわず、「ＮＥＸＴ」に抜けて本ルーチンを一旦終了する。

ステップＳ２０５において、送信データの準備が整うと、ダイアグＥＣＵ６０は、異常時送信データと、トラップソフトの要求とを、管理センター１００に送信する（ステップＳ２１０）。これらのデータおよび要求は、通信装置７０を介して管理センター１００に送信される。これらのデータおよび要求を送信した後、車両１０のダイアグＥＣＵ６０は、トラップソフト等が管理センター１００から送信されるまで待機する。

車両１０からのデータおよび要求の送信を受けると管理センター１００は、図４右欄に示した処理ルーチンを実行する。まず、管理センター１００は、通信装置１０１を用いてこのデータを受信する（ステップＳ３１０）。管理センター１００は受け取った異常フラグおよび異常時送信データの中身を解析し、これらの異常情報に応じたトラップソフトを選択する（ステップＳ３２０）。トラップソフトＤＢ１０５には、トラップソフトが車種別や異常コード別に格納されているので、その中から、異常時送信データを送ってきた車両１０が該当するトラップソフトを選択するのである。例えば、車両１０がエンジン２０の運転処理における異常を検出し、その異常に対応する異常フラグ（異常コード）を送ってきていれば、この異常コードに対応して、エンジン２０の異常を解析するトラップソフトであって、車両１０の車種に適合するトラップソフトを選択する。

管理センター１００は、更に選択したトラップソフトの実行条件をセットする（ステップＳ３３０）。実行条件は、管理センター１００が異常時送信データを解析し、異常が起きた状況を分析することで、セットされる条件である。異常が生じた結果だけでなく、どのような条件下で異常が生じたかを解析し、その条件を絞り込み、セットしている。例えば、エンジン２０の回転数の範囲や、車速の範囲、アクセルペダルの踏込量の範囲、水温の範囲など、異常が生じた際の状況を絞り込み、これをトラップソフトの実行条件としてセットするのである。

管理センター１００は、トラップソフトの選択（ステップＳ３２０）と実行条件のセット（ステップＳ３３０）とが完了すると、トラップソフトおよびその実行条件を、異常を報知してきた車両１０に、通信装置１０１を介して送信し（ステップＳ３４０）、この処理ルーチンを一旦終了する。

管理センター１００がトラップソフトと実行条件とを送信すると、車両１０のダイアグＥＣＵ６０は、これをトラップソフトの実行関連処理（ステップＳ２２０）において検出する。第１実施形態では、ダイアグＥＣＵ６０は、トラップソフトの実行関連処理（ステップＳ２２０）において、まずトラップソフトとその実行条件とを受信する（ステップＳ２２２）。トラップソフトとその実行条件を受信すると、次にトラップソフトをトラップソフト格納部６５に、実行条件を車両状況記憶部６８に、それぞれ記憶する。

その後、ダイアグＥＣＵ６０は、トラップソフト格納部６５に格納したトラップソフトをＣＰＵ６１の制御の下で実行する（ステップＳ２３０）。トラップソフトは、実際には、所定のインターバルで起動される割込処理ルーチンとして実行される。この処理については、図５を用いて説明する。

トラップソフト実行処理ルーチンが起動されると、ダイアグＥＣＵ６０は、その時点の運転環境条件を取得する処理を行なう（ステップＳ２３２）。運転環境条件とは、車両１０の状態、例えば車速、アクセルペダルの踏込量、冷却水の水温、などの各センサ群９０からの検出結果や、管理センター１００から取得できる車両現在地の天候や交通状況などが含まれる。

続いて、取得した運転環境条件を解析し、現在の車両１０の運転環境条件が、トラップソフト実行条件を満たすかを判断する（ステップＳ２３４）。トラップソフトの実行条件は、管理センター１００からトラップソフトと共に送信され、車両状況記憶部６８に記憶されているので、現在の運転環境条件が、実行条件として受け取った各種の範囲に入っているかを判断するのである。

車両１０は様々な状況で走行するから、車両は常に異常が生じた際の運転環境条件となる訳ではない。車両１０が、以前に異常が生じた際の運転条件や環境条件に似た運転環境条件になっておらず、トラップソフトの実行条件が満たされていないと判断すれば（ステップＳ２３４：「ＮＯ」）、トラップソフトの実行処理（ステップＳ２３０）が開始されてから、所定時間が経過したか否かの判断を行なう（ステップＳ２３８）。所定時間が経過していなければ、ステップＳ２３４の判断から処理を繰り返す。

判断を繰り返しているうちに、現在の車両１０の環境運転条件が、トラップソフトの実行条件に入っていると判断すると（ステップＳ２３４：「ＹＥＳ」）、トラップソフト格納部６５に記憶されたトラップソフトを呼び出してこれを実行する（ステップＳ２３６）。車両１０は、以前に異常が生じた際の運転条件や環境条件に似た運転環境条件になっているから、トラップソフトは、同じ異常が生じるか否か、異常の有無に関わらずその運転環境条件下でのセンサ群９０からの検出結果の詳細などを取得し、異常が発生する場合の（あるいは異常が発生しない場合の）車両１０の振る舞いを詳しく分析する。

車両の環境運転条件が、トラップソフトの実行条件を満たすことなく、ステップＳ２３４、Ｓ２３８の判断を繰り返しているうちに、所定時間が経過した場合には（ステップＳ２３８：「ＹＥＳ」）、上述したステップＳ２３６を実行する。車両の運転環境条件は整っていないものの、トラップソフトを実行しないよりは、一旦実行して分析することが望ましい場合があるからである。

こうしてトラップソフトによる詳細な分析を行なうことで、トラップソフト実行関連処理（ステップＳ２２０）を終え、分析結果処理を実行する（ステップＳ２４０）。分析結果処理は、分析結果に基づいて行なわれる各種処理である。例えば、トラップソフトで解析したところ、前回異常が生じた場合と近似の運転環境条件で、同じ異常が発生した場合には、これを管理センター１００に通知すると共に、異常に再現性があることから、インスツルメントパネルに表示を行ない、運転者に車両１０の修理・保守等を依頼または指示する。あるいは、前回異常が生じた場合と近似の運転環境条件では無い状態でトラップソフトが動作し、異常は生じなかったもののセンサ群９０から取得した検出結果の整合性に異常とまでは言えないものの標準的な値から逸脱する傾向が見い出された場合には、これを管理センター１００に通知して更なる指示を求めたり、異常が再現する可能性があるとして、インスツルメントパネルに表示を行ない、運転者に、機会を見て、車両１０をディーラーやサービスセンターに持ち込むことを依頼または指示する。もとより、何らの異常や整合性からの逸脱などが見い出されなければ、前回の異常は単発的な異常であったとして、管理センター１００にその旨通知し、車両１０としては特に修理等の指示を行なわない、といった対応とをとる。

これらの対応は、予め異常の内容や、トラップソフト処理結果に応じて詳細に定めておけばよい。例えば、エンジン２０や変速機３０あるいは制動装置４０のように車両の運転に直接関わる装置の異常に関しては、分析結果処理をより安全サイドなものとして規定し、空調装置５０のように、運転自体に支障とならない装置の異常に関しては、分析結果処理を、運転者の判断に任せる対応として規定してもよい。

以上説明した第１実施形態によれば、車両１０に搭載されたセンサ群９０からの検出結果の整合性がとれず、異常が生じたと判断した場合、その異常に対応したトラップソフトとトラップソフトの実行条件とを、管理センター１００から受け取り、トラップソフトを車両１０において実行する。トラップソフトは、車両１０の運転環境条件が、トラップソフトの実行条件を満たした場合に実行されるので、トラップソフトの実行と分析とを、異常が再現しやすい条件で実行できる。このため、異常の再現性を含む異常の分析を一層詳しく行なうことができる。

また、本実施形態では、車両１０の運転環境条件が、トラップソフトの実行条件を満たすまでトラップソフトの実行を待つものの、所定の時間が経過すれば、条件を満たしていなくてもトラップソフトを実行する。従って、条件が満たされないままトラップソフトを実行せずに、時間を徒過してしまうということがない。

Ｂ．第２実施形態：
次に第２実施形態について説明する。第２実施形態において、車両１０は第１実施形態と同様の構成を備える。第２実施形態では、ダイアグＥＣＵ６０が実行する車両側ダイアグ処理ルーチンおよび管理センター１００が実行する管理センター処理ルーチンが、第１実施形態とは異なる。図６に、第２実施形態における各処理ルーチンを示した。図６において、図３に示した両処理と同一の処理については、同じステップ番号を付し、詳しい説明は省略する。

第１実施形態との差異について簡単に説明すると、第２実施形態では車両側で最初に検出された整合性の不一致は、「異常」ではなく「仮異常」として扱われる。そしてこの仮異常に関する通知を受けた管理センター１００は、トラップソフトとその実行条件を、仮異常を検出した車両だけでなく、所定の車両に送信する。送信を受けた各車両でのトラップソフト実行とその結果の分析を、更に管理センター１００は受け取り、仮異常が本異常であるかを判断し、更にその結果を車両に返している。このように、異常を「仮異常」と「本異常」とに分け、異常が発生したのでない車両でもトラップソフトを実行させる点で、第２実施形態は第１実施形態と相違する。

図６に従って、ダイアグＥＣＵ６０および管理センター１００の処理について説明する。車両１０に搭載されたダイアグＥＣＵ６０は、本ルーチンを開始すると、まず仮異常フラグがセットされているか否かを判断する（ステップＳ２０１）。仮異常フラグは、図３のＥＣＵ運転処理ルーチンを用いて説明したように、各ＥＣＵにおいて、何らかの整合性がとれていない状態が検出されたとき、各ＥＣＵがこれをセットし、出力する異常フラグと同じものである。

仮異常フラグがセットされている場合には（ステップＳ２０１）、次に仮異常時送信データを準備する処理を行なう（ステップＳ２０６）。仮異常時送信データとは、各ＥＣＵから送信された仮異常フラグと仮異常時データとを含む。ダイアグＥＣＵ６０は、これらのデータを管理センター１００に送信する準備として、仮異常時送信データとしてのフォーマットに調える。

送信データの準備が整うと、ダイアグＥＣＵ６０は、仮異常時送信データと、トラップソフトの要求とを、管理センター１００に送信する（ステップＳ２１１）。これらのデータおよび要求は、通信装置７０を介して管理センター１００に送信される点などは、第１実施形態と同様である。

車両１０からのデータおよび要求の送信を受けると管理センター１００は、図６右欄に示した処理ルーチンを実行する。まず、管理センター１００は、通信装置１０１を用いてこのデータを受信する（ステップＳ３１０）。管理センター１００は受け取った仮異常フラグおよび仮異常時送信データの中身を解析し、これらの仮異常情報に応じたトラップソフトを選択する（ステップＳ３２１）。トラップソフトＤＢ１０５には、トラップソフトが車種別や異常コード別に格納されているので、その中から、仮異常時送信データを送ってきた車両１０が該当するトラップソフトを選択するのである。例えば、車両１０がエンジン２０の運転処理における異常を検出し、その異常に対応する仮異常フラグ（仮異常コード）を送ってきていれば、この仮異常コードに対応して、エンジン２０の異常を解析するトラップソフトであって、車両１０の車種に適合するトラップソフトを選択する。

管理センター１００は、選択したトラップソフトの実行条件をセットする（ステップＳ３３０）。実行条件は、管理センター１００が仮異常時送信データを解析し、仮異常が起きた状況を分析することで、セットされる条件である。仮異常が生じた結果だけでなく、どのような条件下で異常が生じたかを解析し、その条件を絞り込み、セットしている。例えば、エンジン２０の回転数の範囲や、車速の範囲、アクセルペダルの踏込量の範囲、水温の範囲など、仮異常が生じた際の状況を絞り込み、これをトラップソフトの実行条件としてセットするのである。

管理センター１００は、トラップソフトの選択（ステップＳ３２０）と実行条件のセット（ステップＳ３３０）とが完了すると、次に、トラップソフトとその実行条件を送信する対象車両を選定する処理を行なう（ステップＳ３５０）。この処理は、仮異常が生じた車両と同じ車種や年式の車両では、同じ異常が生じる可能性があるため、仮異常が生じた車両１０だけでなく、同じ異常が生じ得る可能性の高い車両を選定するのである。例えば、トラップソフトおよびその実行条件を送信する対象車両として、同じ車種、同じ年式の車両であって、現在管理センター１００から通信可能な範囲に存在する車両を選定する。

その後、現在管理センター１００は、異常を報知してきた車両１０を含む複数の車両においてトラップソフトを実行させる処理である複数車両トラップソフト実行処理（ステップＳ３６０）を実行する。この処理は、複数の車両でトラップソフトが実行されるのと同期して行なわれるので、後でまとめて説明する。

管理センター１００がトラップソフトとその実行条件とを、ステップＳ３５０で選定した複数の車両に送信すると、各車両１０のダイアグＥＣＵ６０は、これをトラップソフトの実行関連処理（ステップＳ２２０）においてこれを検出し、トラップソフトの実行関連処理を実施する。図６では、仮異常を検出してこれを管理センター１００に出力した車両が、複数車両の一台として、トラップソフトを実行することを記載したが、他の車両でも同じように、トラップソフト実行関連処理（ステップＳ２２０）が行なわれる。この処理の内容は、図４および図５に示した通りなので、その説明は省略する。

こうしてトラップソフト実行関連処理（ステップＳ２２０）を終えると、ダイアグＥＣＵ６０は、分析結果処理を行ない、その結果を送信する処理を実行する（ステップＳ２４１）。この処理は、第１実施形態のステップＳ２４０に対応する処理である。分析の結果は、第１実施形態と同様に、管理センター１００に送信されるが、本実施形態では、複数の車両１０が、それぞれ分析結果を送信する点で、第１実施形態と相違する。この分析結果の送信は、各車両１０から行なわれ、管理センター１００は複数車両トラップソフト実行処理（ステップＳ３６０）において、この複数の車両１０の各々からの分析結果の送信を受ける。

複数車両トラップソフト実行処理（ステップＳ３６０）を図７に拠って説明する。既に説明した様に、管理センター１００は、トラップソフトとその実行条件を送信する車両の選定を終えると、複数車両トラップソフト実行処理を開始し、まず各車両に、トラップソフトとその実行条件とを送信する処理を実行する。その後、各車両からの分析結果の送信を待ち、順次分析結果を受信する（ステップＳ３６６）。各車両１０は、仮異常が生じたのと同様の運転環境条件が整ったときにトラップソフトを実行し、その結果を分析して管理センター１００に送信するが、その内容は、車輌毎に異なる。そこで、次に、仮異常と同じ異常が発生した車両の割合を計算する処理を行なう（ステップＳ３６８）。以上が、複数車両トラップソフト実行処理（ステップＳ３６０）の内容である。

複数車両トラップソフト実行処理（ステップＳ３６０）が終了すると、次に管理センター１００は、計算した割合、つまり仮異常と同じ異常が発生した車両の割合が、予め定めた閾値以下か否かの判断を行ない（ステップＳ３７０）、閾値以下であれば、仮異常として扱ってきた異常は、最初に仮異常の発生を通知してきた車両独自の異常、つまり本異常であると判断し、本異常判定を該当車両に送信する（ステップＳ３８０）。他方、仮異常と同じ異常が発生した車両の割合が閾値より大きいと判定された場合（ステップＳ３７０：「ＮＯ」）には、本異常判定を当該車両に送信する処理（ステップＳ３８０）は行なわず、ステップＳ３９０に移行する。多くの車両で仮異常と同じ状況が発生しているのであれば、特定の車種に固有の現象やあるいは走行環境に依存した現象の可能性があるため、当該車両に本異常判定の通知を行なわない（保留する）のである。前者の例としては、例えば仮異常の判定用閾値が特定の車種で不適切な値になっているようなケースが想定できる。後者の走行環境としては、例えば、真夏の高温、真冬の極低温、梅雨時などの高湿度、冬場の低湿度、台風などの通過による気圧の低下・暴風などにより、仮異常が発生しやすい条件が考えられる。また、仮異常を検出した車両が、高度の高い場所や舗装されていない悪路等を走行していて仮異常を検出した場合、その車両の近くの車両が同様の現象を検出するといったケースも、走行環境に依存した現象の可能性があると想定される。

ステップＳ３９０では、異常判定の結果を管理センター１００における管理者に通知する（ステップＳ３９０）。管理者とは、管理センター１００の管理者であってもよいが、車両の安全な運行に責任を持つ管理者であることが望ましい。管理者は、異常の発生の判定結果を得て、対応を検討することができる。例えば、該当車両（同じ車種、年式など）に対して共通の要因が疑われる場合には、要因を更に分析し、必要があれば、該当する車種に対してメンテナンスを促すといった対応を検討する。ステップＳ３９０の処理後、「ＮＥＸＴ」に抜けて、本処理ルーチンを一旦終了する。

他方、管理センター１００におけるステップＳ３８０の処理により、本異常判定が送信されると、車両１０のダイアグＥＣＵ６０は、これを受信し（ステップＳ２８０）、運転者に警告を行なう（ステップＳ２９０）。仮異常を検出した車両で起きた現象が同様の車種で生じる割合が小さかったために、当該車両固有の異常と判断されたのであり、早急な修理や保守が求められるからである。なお、本異常の通知は、仮異常を検出した車両１０だけであってもよいし、トラップソフトの実行関連処理（ステップＳ２２０）において、同様の異常を発生した他の車両を含んでもよい。あるいは、仮異常に対して選定された全車両であってもよい。これらの処理を終了した後、「ＮＥＸＴ」に抜けて、車両側ダイアグ処理ルーチン地を一旦終了する。

以上説明した第２実施形態によれば、第１実施形態と同様の効果を奏する上、更に、車種などが同じ車両でのトラップソフトの実行結果を参照して、異常に対する対応を決定することができる。従って、仮異常を生じた車両にとっては、自車のみならず、他車での判定結果も参考に、対応を決めることができる。例えば、仮異常を検出した車両固有の異常かを判定して、早期の対応を取ることが可能となる。また、仮異常が生じた車両と同じ車種や年式等の車両は、これまで検出していなかった異常の存在を早期に検出できる。なお、第２実施形態では、同じ車種、同じ年式の車両を送信対象車両として選定したが（図６、ステップＳ３５０）、更に細かい条件で選定してもよい。例えば、搭乗している人の数や累積走行距離が同様の車両に限定するなどしてもよい。また、同じ車種に限らず、同じ排気量の車種など、選定の範囲を拡げることも差し支えない。

Ｃ．その他の実施形態：
上記実施形態では、トラップソフトは、何らかの異常が生じたときに、管理センター１００から実行条件と共に送信を受けたが、管理センター１００から送信を受けるのであれば、そのタイミングは、異常又は仮異常の検出時に限る必要はない。例えば、車両１０が管理センター１００と通信可能な範囲に入ったときに、各装置用のトラップソフトをまとめて受信し、トラップソフト格納部６５に記憶しておいてもよい。また、運転者への警告（図６、ステップＳ２９０）等は、視覚的なものに限る必要はなく、音声などで通知してもよい。また、警告などの報知は、車両１０のインスツルメントパネルに限る必要はなく、運転者の持つ携帯電話（スマートホン等）に通知するようにしてもよい。

管理センター１００からトラップソフトと共に送信される実行条件は、車速等、車両側の運転条件に限る必要はなく、雨が降っている状態で、など、環境条件を含んでいることも差し支えない。実行条件は、異常または仮異常を検出した車両が検出した運転環境条件と同じものである必要はなく、等価または対応関係があると考えられる他の条件で代替してもよい。例えば、車速は、加速度の積分値に置き換えても良い。降雨という条件は、制動装置４０の異常に関する場合は、降雪で置き換えてもよい。

上記実施形態では、移動体として４輪の自動車を取り上げたが、移動体としては２輪車など４輪未満の車両、あるいは５輪以上の車両であっても差し支えない。また船舶やドローンなどであっても適用可能である。

異常を検出する装置は、移動体に搭載された全ての装置である必要はなく、その一部であってもよい。また、移動体異常時制御装置としての構成に留まらず、異常時制御装置とホスト装置（管理センター）からなる異常時制御システムとして構成しても良い。更には、異常時制御方法として実施することも差し支えない。

ホスト装置との間でデータをやり取りする移動体異常時制御装置は、以下の形態を採用することが可能である。即ち、前記移動体の異常を検出する検出部と；前記異常が検出された際の前記移動体の状況を検出し、前記検出した状況の少なくとも一部を記憶する記憶部と；前記異常が検出されたとき、当該異常の内容を表わす異常情報を前記ホスト装置に送信する異常情報送信部と；前記送信した異常情報に対して前記ホスト装置が送信する異常分析プログラムを実施可能に記憶し、前記異常が検出された際に記憶された前記移動体の状況に対応した異常分析条件が満たされたときに、前記異常分析プログラムを実行する実行部とを備える移動体異常時制御装置として実施できる。

こうした移動体異常時制御装置において、前記異常が検出された際の前記移動体の状況は、前記移動体の使用環境であり；前記実行部は、前記異常分析条件を、前記異常情報および前記使用環境から定めるものとしてもよい。こうすれば、例えば天候や交通状況と言った使用環境も含めて、異常の発生の再現性を検証できる。

こうした移動体異常時制御装置において、前記移動体は車両であり；前記車両は、動力を発生する動力発生装置、前記発生した動力を車輪に伝達する動力伝達装置、前記車両を制動する制動装置、および前記車両の車室内の空気調和を行なう空調装置のうちの少なくとも２つの装置を搭載しており；前記異常情報は、異常が生じた装置が、前記搭載している装置のいずれであるかの情報を含むものとしてもよい。こうすれば、車両において、動力発生装置、動力伝達装置、制動装置および空調装置などの主要な装置について異常分析プログラムを実行して異常の分析を行なうことができる。

上記の移動体異常時制御装置において、前記実行部は、前記異常が検出された際の前記移動体の状況に対応した異常分析条件が満たされない状態が所定期間以上継続した場合には、前記異常分析プログラムを実行するものとしてもよい。こうすれば、異常分析条件が所定時間に亘って満たされない場合でも、異常分析プログラムを実施できる。

この他、移動体の制御を行なう制御装置と、この制御装置とデータをやり取り可能なホスト装置とを備えた移動体異常時制御システムとして、実施することも可能である。この場合、単に移動体の異常時制御装置と同様の作用効果が得られるだけでなく、異常時制御システムとして、異常分析プログラムを異常が発生した車両以外の車両にも実行させるものとしてもよい。こうすれば、異常が発生する可能性が高い車両で、異常分析プログラムを実行させて、異常状態を推定するとができ、異常の分析の確度を高めることができる。

こうした移動体異常時制御システムにおいて、異常状態の推定は、前記異常分析プログラムを実行した他の移動体のうち、前記異常状態が発現した移動体の割合により行なうものとしてもよい。異常状態が発現する移動体の割合が高ければ、異常として対応すべき優先度の高い異常として判断できる。

本開示は、上述の実施形態に限られるものではなく、その趣旨を逸脱しない範囲において種々の構成で実現できる。例えば、発明の概要の欄に記載した各形態中の技術的特徴に対応する実施形態の技術的特徴は、上述の課題の一部又は全部を解決するために、あるいは、上述の効果の一部又は全部を達成するために、適宜、差し替えや、組み合わせを行うことが可能である。また、その技術的特徴が本明細書中に必須なものとして説明されていなければ、適宜、削除することが可能である。例えば、上記実施形態においてハードウェアにより実現した構成の一部は、ソフトウェアにより実現できる。また、ソフトウェアにより実現している構成の少なくとも一部は、ディスクリートな回路構成により実現することも可能である。

１０ 車両、１９ ホイールシリング、２０ エンジン、２１ エンジンＥＣＵ、３０ 変速機、３１ 変速機ＥＣＵ、３２ ディファレンシャルギア、３５，３６ 後輪、４０ 制動装置、４１ 制動力ＥＣＵ、４５，４７ ホイールシリンダ、４６，４８ ブレーキディスク、５０ 空調装置、５１ 空調ＥＣＵ、６０ ダイアグＥＣＵ、６１ ＣＰＵ、６２ 入出力部、６３ 記憶部、６４ ダイアグソフト格納部、６５ トラップソフト格納部、６７ 異常記憶部、６８ 車両状況記憶部、７０ 通信装置、８０ ハンドル、８１ 操舵ギア、８３，８４ 前輪、９０ センサ群、９１ ＧＮＳＳセンサ、９２ 車速センサ、９３ 燃焼圧センサ、９４ 加速度センサ、９５ ヨーレートセンサ、９６ 油圧センサ、９７ 水温センサ、９８ 温度センサ、１００ 管理センター、１０１ 通信装置、１０２ 環境データ、１０５ トラップソフトデータベース（ＤＢ）

Claims (8)

1. ホスト装置（１００）との間でデータをやり取りする移動体異常時制御装置（６０）であって、
   移動体（１０）の異常を検出する検出部（６１）と、
   前記異常が検出された際の前記移動体の状況を検出し、前記検出した状況の少なくとも一部を記憶する記憶部（６７）と、
   前記異常が検出されたとき、当該異常の内容を表わす異常情報を前記ホスト装置に送信する異常情報送信部（６４、７０）と、
   前記送信した異常情報に対して前記ホスト装置が送信する異常分析プログラムを実施可能に記憶し、前記異常が検出された際に記憶された前記移動体の状況に対応した異常分析条件が満たされたときに、前記異常分析プログラムを実行する実行部（６１，６５）と
   を備える移動体異常時制御装置。
2. 請求項１記載の移動体異常時制御装置であって、
   前記異常が検出された際の前記移動体の状況は、前記移動体の使用環境であり、
   前記実行部は、前記異常分析条件を、前記異常情報および前記使用環境から定める
   移動体異常時制御装置。
3. 請求項１または請求項２記載の移動体異常時制御装置であって、
   前記移動体は車両であり、
   前記車両は、動力を発生する動力発生装置（２０）、前記発生した動力を車輪に伝達する動力伝達装置（３０）、前記車両を制動する制動装置（４０）、および前記車両の車室内の空気調和を行なう空調装置（５０）のうちの少なくとも２つの装置を搭載しており、
   前記異常情報は、異常が生じた装置が、前記搭載している装置のいずれであるかの情報を含む
   移動体異常時制御装置。
4. 請求項１から請求項３のいずれか一項に記載の移動体異常時制御装置であって、
   前記実行部は、
   前記異常が検出された際の前記移動体の状況に対応した異常分析条件が満たされない状態が所定期間以上継続した場合には、前記異常分析プログラムを実行する
   移動体異常時制御装置。
5. 移動体の制御を行なう制御装置（２１，３１，４１，５１，６０）と、前記制御装置とデータをやり取り可能なホスト装置（１００）とを備えた移動体異常時制御システム（１０）であって、
   前記制御装置は、
   前記移動体の異常を検出する検出部（６１）と、
   前記異常が検出された際の前記移動体の状況を検出し、前記検出した状況の少なくとも一部を記憶する記憶部（６７）と、
   前記異常が検出されたとき、当該異常の内容を表わす異常情報を前記ホスト装置に送信する異常情報送信部（６４，７０）と、
   前記送信した異常情報に対して前記ホスト装置が送信する異常分析プログラムを実施可能に記憶し、前記異常が検出された際に記憶された前記移動体の状況に対応した異常分析条件が満たされたときに、前記異常分析プログラムを実行する実行部（６１，６５）と
   を備え、
   前記ホスト装置は、前記異常情報を前記移動体の前記制御装置から受信したとき、前記異常分析プログラムを前記移動体に送信するプログラム送信部（１０１，１０５）を備える
   移動体異常時制御システム。
6. 請求項５記載の移動体異常時制御システムであって、
   前記ホスト装置とデータをやり取り可能な他の移動体を含み、
   前記ホスト装置は、
   前記異常を検出した移動体から受け取った異常情報に基づいて、前記他の移動体のうち、前記異常分析プログラムを実行すべき移動体を選定し、
   前記選定した移動体に前記異常分析プログラムを送信して実行させ、その実行結果を解析して、異常状態の推定を行なう
   移動体異常時制御システム。
7. 前記異常状態の推定は、前記異常分析プログラムを実行した他の移動体のうち、前記異常状態が発現した移動体の割合により行なう請求項６記載の移動体異常時制御システム。
8. 移動体の異常時に実行される制御方法であって、
   前記移動体の異常を検出し（Ｓ１３０，Ｓ２００）、
   前記異常が検出された際の前記移動体の状況を検出し、前記検出した状況の少なくとも一部を記憶し（１４０）、
   前記異常が検出されたとき、当該異常の内容を表わす異常情報を、前記移動体の外部に存在するホスト装置に送信し（Ｓ２１０）、
   前記ホスト装置は、前記異常情報を前記移動体から受信したとき、異常分析プログラムを前記移動体に送信し（Ｓ３４０）、
   前記ホスト装置が送信した異常分析プログラムを実施可能に記憶し（Ｓ２２４）、
   前記異常が検出された際に記憶された前記移動体の状況に対応した異常分析条件が満たされたときに、前記異常分析プログラムを実行する（Ｓ２３０，Ｓ２３４、Ｓ２３６）
   移動体異常時制御方法。

Images