JP2024053278A - 車両の異常原因特定システム - Google Patents

Abstract

【課題】車両において発生した異常の原因の特定を効率的に行う異常原因特定システムを提供する。【解決手段】ハードウェア（Ｈ／Ｗ）に関する第１情報を出力するハードウェア層と、ハードウェア層が出力する第１情報と自層で取得する第２情報とに基づいて、Ｈ／Ｗの異常および信頼性に関する第１判定を行い、第１判定の結果を第１情報および第２情報と共に出力するプラットフォーム層と、プラットフォーム層が出力する第１情報および第２情報と自層で取得する第３情報とに基づいて、Ｈ／Ｗの異常および信頼性に関する第２判定を行い、第２判定の結果を第１情報、第２情報、および第３情報と共に出力するアプリケーションフレームワーク層と、アプリケーションフレームワーク層の出力に基づく故障コードを、第１情報、第２情報、および第３情報を紐付けてデータベースに記憶するアプリケーション層と、を備える階層構造を有する車両の異常原因特定システム。【選択図】図１

Description

本開示は、車両において発生した異常の原因を特定するシステムに関する。

特許文献１には、車両の異常を示す故障コードであるＤＴＣ（Diagnostic Trouble Code）を利用して車検などの検査を好適に行うことができる診断システムが、開示されている。この診断システムでは、診断部によって同じ検査対象に対して診断された異常について、ＯＢＤ（On-Board Diagnostics）法規に対応する異常と、道路運送車両法の保安基準によって規定される異常とを、別の故障コードで管理および記憶することによって、車検などの検査で所望の故障コードを得ることができるようにしている。

特開２０２０－０８３１３９号公報

上記特許文献１に記載された診断システムでは、車両において発生した異常について、異常結果を利用する場面（車検など）に応じた必要な情報が得られるように故障コードの切り分けは行われるが、その故障コードを記録することになった異常の原因を特定することは行っていない。このため、車検などにおけるトラブルシュートに時間が掛かるという課題がある。

本開示は、上記課題を鑑みてなされたものであり、車両において発生した異常の原因の特定を効率的に行うことができる、車両の異常原因特定システムを提供することを目的とする。

上記課題を解決するために、本開示技術の一態様は、階層構造を有する車両の異常原因特定システムであって、ハードウェアに関する第１情報を出力するハードウェア層と、ハードウェア層が出力する第１情報と自層で取得する第２情報とに基づいて、ハードウェアの異常および信頼性に関する第１判定を行い、第１判定の結果を第１情報および第２情報と共に出力するプラットフォーム層と、プラットフォーム層が出力する第１情報および第２情報と自層で取得する第３情報とに基づいて、ハードウェアの異常および信頼性に関する第２判定を行い、第２判定の結果を第１情報、第２情報、および第３情報と共に出力するアプリケーションフレームワーク層と、アプリケーションフレームワーク層の出力に基づく故障コードを、第１情報、第２情報、および第３情報を紐付けてデータベースに記憶するアプリケーション層と、を備える、車両の異常原因特定システムである。

本開示の車両の異常原因特定システムによれば、車両において発生した異常の原因を効率的に特定するので、トラブルシュート性が向上する。

本開示の一実施形態に係る車両の異常原因特定システムのソフトウェア的な機能ブロックを示す図

本開示による階層構造の車両の異常原因特定システムでは、ハードウェアが異常であると診断されるまでに各層において考慮や加味など判定に利用された全ての情報をＤＴＣと紐付けてデータベースに記憶する。これにより、紐付けられた情報を用いてＤＴＣから異常判定の要因を遡って特定することができる。
以下、本開示の一実施形態について、図面を参照しながら詳細に説明する。

＜実施形態＞
図１は、本開示の一実施形態に係る車両の異常原因特定システム１のソフトウェア的な機能ブロックを示す図である。図１に例示した車両の異常原因特定システム１のソフトウェア構成は、ハードウェア層１０、プラットフォーム層２０、アプリケーションフレームワーク層３０、およびアプリケーション層４０からなる階層構造を有している。アプリケーション層４０は、データの記憶が可能にデータベース５０に接続される。

（１）ハードウェア層（Ｈ／Ｗ層）
ハードウェア層１０は、車両に搭載される様々なアクチュエーターや装備などのハードウェア（Ｈ／Ｗ）を、制御、監視、管理などを行うための層である。このハードウェア層１０は、ハードウェアが提供するデータに基づいて、データを提供してきたハードウェアの故障や異常を診断することを行う。

ハードウェアが提供するデータは、ハードウェア要因の故障や異常を把握するために使用される情報である。このハードウェアが提供するデータは、ハードウェアごとにそれぞれ提供される。

そして、ハードウェア層１０は、各ハードウェアが提供するデータと、各ハードウェアが提供するデータに基づいて行った診断に関する情報とを、ハードウェアごとにハードウェアに関するＨ／Ｗ情報および診断情報（第１情報）として、上位層のプラットフォーム層２０に出力する。

（２）プラットフォーム層（ＰＦ層）
プラットフォーム層２０は、ハードウェア層１０と（アプリケーションフレームワーク層３０を介して）アプリケーション層４０とを繋ぐ入出力インターフェイス処理を行うための層である。このプラットフォーム層２０は、ハードウェア層１０から提供されるハードウェアごとのＨ／Ｗ情報および診断情報（第１情報）を入力する。また、プラットフォーム層２０は、自らが車両に搭載された各種機器から所定の情報（第２情報）を取得および記憶することができる。プラットフォーム層２０が取得および記憶する所定の情報については、予め定義されている。

このプラットフォーム層２０は、ハードウェア層１０から出力される各ハードウェアの複数のＨ／Ｗ情報および診断情報（第１情報）と、プラットフォーム層２０が自ら車両に搭載された各種機器から取得した所定の情報（第２情報）とに基づいて、各ハードウェアの異常判定および信頼性判定の処理（第１判定）をそれぞれ実施する。このプラットフォーム層２０で実施される処理は、入力に基づいた単純な異常判定および信頼性判定の処理である。

そして、プラットフォーム層２０は、異常判定処理によってハードウェアが「異常」であると判定した場合、ハードウェア層１０から提供されるＨ／Ｗ情報および診断情報に加えて、プラットフォーム層２０が自ら車両に搭載された各種機器から取得した所定の情報のうち異常判定結果に至るまでに考慮や加味などによって判定に利用した情報を、異常判定要因の情報として異常判定結果に紐付けることを行う。また、プラットフォーム層２０は、ハードウェアを異常判定とする結果の信頼性（誤診断か否か）に関する情報を、信頼性情報として異常判定結果にさらに紐付けることを行う。

異常判定要因の情報には、一例として、ＤＴＣ判断に使用した信号の元信号の情報、故障／異常の箇所／要因を特定する情報、および要因特定の詳細情報が、含まれる。ＤＴＣ判断に使用した信号の元信号は、どの信号によってＤＴＣ記憶に至ったかを把握するために使用され、「ＤＴＣ判断に使用した信号」の判断に用いたプラットフォーム層２０で使用した信号のうち、異常だったものを特定する情報である。故障／異常の箇所／要因を特定する情報は、どこでどのような故障／異常が起きたかを判断するために使用され、検出できる故障の最小粒度の情報である。要因特定の詳細情報は、検出できる故障の最小粒度であっても、複数の要因がある場合が考えられ、このときに要因を切り分けるために使用される情報である。この要因特定の詳細情報は、例えば、何が高負荷であったかなど、より具体的な要因特定に繋がる情報である。

信頼性情報には、一例として、電子制御ユニット（ＥＣＵ）ごとの信頼性情報として負荷状況、電源電圧、および起動状態が含まれ、機能ごとの信頼性情報としてその他状態が、含まれる。負荷状況は、高負荷な状態になり処理遅延などによってＤＴＣを記憶した可能性があるか否かを判断するために使用され、ＣＰＵ負荷（％）や定常負荷からの乖離および特定の関数の演算時間増加などの情報である。電源電圧は、ハードウェアの故障ではなく一時的な電圧低下などによってＤＴＣを記憶した可能性があるか否かを判断するために使用され、対象電源（外部電源、内部電源）の電圧値や状態（保証範囲内外）などの情報である。起動状態は、起動処理中の動作タイミングのズレなどによってＤＴＣを記憶した可能性があるか否かを判断するために使用され、ハードウェアの起動／通常／終了のいずれの状態および起動からの経過時間などの情報である。その他状態は、何らかの特別な状態にあるためＤＴＣを記憶した可能性があるか否かを判断するために使用され、各種の状態、工場モードや特定の状態などの解析に必要な情報である。

そして、プラットフォーム層２０は、ハードウェアの判定結果が正常である場合、ハードウェアの正常判定結果（第１判定の結果）を上位層のアプリケーションフレームワーク層３０に出力する。一方、プラットフォーム層２０は、ハードウェアの判定結果が異常である場合、ハードウェアの異常判定結果（第１判定の結果）にその異常判定要因の情報および信頼性情報（第２情報）とハードウェア層１０から提供されるハードウェアのＨ／Ｗ情報および診断情報（第１情報）とを紐付けて、上位層のアプリケーションフレームワーク層３０に出力する。

（３）アプリケーションフレームワーク層（ＡＦＷ層）
アプリケーションフレームワーク層３０は、アプリケーション層４０に実装されるアプリケーションの下請け処理を行うための層である。このアプリケーションフレームワーク層３０は、プラットフォーム層２０が出力する第１判定の結果、ハードウェアごとのＨ／Ｗ情報および診断情報（第１情報）、およびハードウェアごとの異常判定結果である異常判定要因の情報および信頼性情報（第２情報）をそれぞれ入力する。また、アプリケーションフレームワーク層３０は、自らが車両に搭載された各種機器から所定の情報（第３情報）を取得および記憶することができる。アプリケーションフレームワーク層３０が取得および記憶する所定の情報については、予め定義されている。

このアプリケーションフレームワーク層３０は、プラットフォーム層２０から出力される各ハードウェアの判定結果（第１判定の結果）および判定結果に紐付けられた異常判定要因の情報および信頼性情報（第１情報、第２情報）と、アプリケーションフレームワーク層３０が自ら車両に搭載された各種機器から取得した所定の情報（第３情報）とに基づいて、各種の情報を加味した複合的な異常判定および信頼性判定の処理（第２判定）を実施する。

アプリケーションフレームワーク層３０は、プラットフォーム層２０で判定されたハードウェアごとの診断結果をＯＲ合成することによって、特定機器に対する複合的な異常判定を行う。例えば、特定機器に関連するハードウェアとして第１のハードウェア、第２のハードウェア、および第３のハードウェアが存在し、プラットフォーム層２０によるそれぞれの判定結果が第１のハードウェア「正常」、第２のハードウェア「正常」、および第３のハードウェア「異常」である場合を考える。この場合、アプリケーションフレームワーク層３０は、「正常」「正常」「異常」の論理和（ＯＲ）である「異常」を、特定機器の最終的な判定結果として決定する。

本実施形態において、アプリケーションフレームワーク層３０は、上述した論理和（ＯＲ）による正常／異常の最終的な判定結果に、この論理和（ＯＲ）の判定結果に至るまでに考慮や加味などによって判定に利用した情報を、異常判定要因の情報として論理和（ＯＲ）による診断結果に紐付けることを行う。また、本実施形態において、アプリケーションフレームワーク層３０は、ハードウェアを最終的に異常判定とする結果の信頼性（誤診断か否か）に関する情報を、信頼性情報として論理和（ＯＲ）による診断結果にさらに紐付けることを行う。

この論理和（ＯＲ）に紐付ける異常判定要因の情報および信頼性情報は、プラットフォーム層２０が自ら車両に搭載された各種機器から取得および記憶した所定の情報とハードウェア層１０による診断情報とのみでもよいし、これらの情報に加えて、アプリケーションフレームワーク層３０が自ら車両に搭載された各種機器から取得および記憶した所定の情報が含まれてもよい。後者の場合、アプリケーションフレームワーク層３０が取得および記憶する所定の情報を、プラットフォーム層２０が取得および記憶する所定の情報と異ならせることで、異常判定に至った要因の特定や絞り込みの容易化および信頼性の向上が期待できる。

そして、アプリケーションフレームワーク層３０は、論理和（ＯＲ）に基づく特定機器の判定（第２判定）が異常である場合、この特定機器を異常と判定するに至った異常判定要因の情報および信頼性情報（第１情報、第２情報、第３情報）を特定機器の異常判定結果（第２判定の結果）に紐付けて、上位層のアプリケーション層４０に出力する。

（４）アプリケーション層（Ａｐｐ層）
アプリケーション層４０は、車両の様々な機能を実現するための各種のアプリケーションを実装する層である。本実施形態では、ダイアグを実行するアプリケーション（Ａｐｐ）がアプリケーション層４０に実装されている。このアプリケーション層４０は、アプリケーションフレームワーク層３０が出力する特定機器の異常判定結果（第２判定の結果）およびその結果に紐付けられた異常判定要因の情報および信頼性情報（第１情報、第２情報、第３情報）を入力する。そして、アプリケーション層４０は、この異常判定結果に基づく故障コードであるＤＴＣを特定し、この特定したＤＴＣをそれに紐付く異常判定要因の情報および信頼性情報（第１情報、第２情報、第３情報）と共にデータベース５０に記憶する。

なお、ダイアグを実行するアプリケーション以外のアプリケーションを実装する他のアプリケーション層をさらに有していてもよい。この場合、他のアプリケーション層は、アプリケーションフレームワーク層３０を介さずにプラットフォーム層２０と直接接続されてもよい。

（５）データベース
データベース５０は、車両において発生した異常に関するＤＴＣ、このＤＴＣに紐付いた異常判定要因の情報および信頼性情報（第１情報、第２情報、第３情報）、フリーズフレームデータでダイアグ記憶時に残すデータであるＦＦＤ、およびデータの識別情報であるＤＩＤなどを、記憶する記憶装置である。

＜作用・効果＞
以上のように、本開示の一実施形態に係る車両の異常原因特定システムによれば、各層における異常判定の責務分担が予め定義された階層構造を用いて、各層において取得および記憶する情報として定義された、ＤＴＣを記憶するまでに至った異常判定に利用される異常判定要因の情報を、ＤＴＣと紐付けてデータベースに記憶する。つまり、本実施形態に係る車両の異常原因特定システムは、アプリケーション層より下の異常判定を行う下位層での診断結果を含めて、ＤＴＣ記憶に至る各層での判断結果と判断の元情報の全てをＤＴＣと共に記憶する。

これにより、ＤＴＣ記憶情報と異常判定要因との乖離が原因で生じていた「ＤＴＣから個別の要因情報を遡って特定することができず、解析に時間を要する」という問題を改善することが可能となる。

また、本開示の一実施形態に係る車両の異常原因特定システムによれば、各層において取得および記憶する情報として、ＤＴＣ記憶が信頼できるかどうか示す信頼性情報を予め定義しておき、各層でそれぞれ取得および記憶した信頼性情報をＤＴＣとさらに紐付けてデータベースに記憶する。

これにより、ＤＴＣ記憶情報と異常判定要因との乖離が原因で生じていた「誤診断を識別することができない」という問題を改善することが可能となる。

本開示は、車両において発生した異常の原因を特定するシステムなどとして利用可能である。

１ 異常原因特定システム
１０ ハードウェア層
２０ プラットフォーム層
３０ アプリケーションフレームワーク層
４０ アプリケーション層
５０ データベース

Claims (4)

1. 階層構造を有する車両の異常原因特定システムであって、
   ハードウェアに関する第１情報を出力するハードウェア層と、
   前記ハードウェア層が出力する前記第１情報と自層で取得する第２情報とに基づいて、前記ハードウェアの異常および信頼性に関する第１判定を行い、前記第１判定の結果を前記第１情報および前記第２情報と共に出力するプラットフォーム層と、
   前記プラットフォーム層が出力する前記第１情報および前記第２情報と自層で取得する第３情報とに基づいて、前記ハードウェアの異常および信頼性に関する第２判定を行い、前記第２判定の結果を前記第１情報、前記第２情報、および前記第３情報と共に出力するアプリケーションフレームワーク層と、
   前記アプリケーションフレームワーク層の出力に基づく故障コードを、前記第１情報、前記第２情報、および前記第３情報を紐付けてデータベースに記憶するアプリケーション層と、を備える、車両の異常原因特定システム。
2. 前記第１情報は、前記ハードウェアを要因とする異常の把握に用いられるハードウェアに関する情報および診断情報である、請求項１に記載の車両の異常原因特定システム。
3. 前記第２情報は、前記第１判定のために前記プラットフォーム層が前記車両に搭載された各種機器から取得する情報である、請求項１に記載の車両の異常原因特定システム。
4. 前記第３情報は、前記第２判定のために前記アプリケーションフレームワーク層が前記車両に搭載された各種機器から取得する情報である、請求項１に記載の車両の異常原因特定システム。

Images