JP2020500351A - 車内予測不具合検出のシステム及び方法 - Google Patents

Abstract

車両の不具合を診断トラブルコードに基づいて予測的に検出するシステム及び方法が提供される。一例では、車両の不具合の確率を１つまたは複数の診断トラブルコード（ＤＴＣ）に基づいて判定することと；確率が閾値を超えていることに応じて不具合の可能性があることを車両のオペレータに示すこととを含む方法が提供される。判定は、１つまたは複数のＤＴＣを１つまたは複数の学習済みモデルオブジェクトと比較することに基づき得る。【選択図】図２

Description

関連出願の相互参照
本出願は、参照によってその全内容があらゆる目的のために本明細書に援用される、２０１６年１０月１２日出願の「ＳＹＳＴＥＭＳ ＡＮＤ ＭＥＴＨＯＤＳ ＦＯＲ ＩＮ−ＶＥＨＩＣＬＥ ＰＲＥＤＩＣＴＩＶＥ ＦＡＩＬＵＲＥ ＤＥＴＥＣＴＩＯＮ」と題された米国仮出願第６２／４０７，３５９号の優先権を主張する。

本開示は、結果を予測するのに用いられる分析モデルの分野に関し、より詳細には、将来の自動車の不具合及び工場出荷時保証中の自動車の相手先ブランド名製造（ＯＥＭ）の製品（車両）の修理を予測することに関する。

自動車のＯＥＭは、より良い製品をつくり、車両の寿命中に要される修理回数を減らすように努力を続けている。消費者の信頼を高めるために、新しい車両ごとに保証書が提供される。しかしながら、保証が整っていても、品質認識は、実際のところはどうであれ、保証修理のために車両が戻される回数とともに下がっていく。

車両の形状及びモデルに関する予測分析モデルを用いることによって、ＯＥＭは、車両が修理に運び込まれる合計回数を減らし、大規模な修理が必要とされる前に製品を改良し、大規模リコールを潜在的に回避し得る。この点について、車両の不具合が起こる前にそれらを予測することが可能であるシステムを使用する場合があり、すなわち、車両の不具合を予測的に検出することによって、機能停止及び路上修理といった望ましくない結末を回避し得、それによって、車両品質の消費者の認識及び消費者信頼度を向上させる。さらに、予測分析によって、ＯＥＭは、不具合が起きるときの傾向を観察することが可能になり得、それによって、コストがかかりかつ不都合な大規模リコールを防ぐ。さらに他の利益は、以下の記載において明らかとなろう。

上記の目的は、この開示の１つまたは複数の態様による、車内予測不具合検出システムで達成され得る。この開示は、統計モデル、及び、既存の保証クレームと車両によって生成された診断トラブルコード（ＤＴＣ）の間に属性をならびにＤＴＣ自体の間に因果関係を確立する方法の両方を提供する。予測フレームワークに実装されると、これは、製品保証費用及び不測の問題を低減させることができる。この開示による予測モデルは、ＤＴＣのパターンの検出に基づいて、不具合の早期警告を提供し得る。

上記で指定された目的は、１つまたは複数の診断トラブルコード（ＤＴＣ）に基づいて、車両の不具合の確率を判定することと；確率が閾値を超えていることに応じて、不具合の可能性があることを車両のオペレータに示すこととを含む方法によって達成され得る。判定は、１つまたは複数のＤＴＣを１つまたは複数の学習済みモデルオブジェクトと比較することに基づき得る。学習済みモデルオブジェクトは、履歴ＤＴＣデータに関して行われた機械学習アルゴリズムを用いて生成され得る。判定することは、さらに、走行距離計の読み取り値及びバッテリ電圧を含む複数の運転条件に基づき得る。

いくつかの例では、示すことは、スクリーンを介してテキストメッセージを表示することを含み得、テキストメッセージは指示を含むものである。指示は、メカニックまたはサービスステーションを訪れるまでの推奨される日数を含み得る。推奨される日数は、確率に基づき得、確率が低いときは多い日数が推奨され、確率が高いときは少ない日数が推奨され、日数はさらに、ＤＴＣを生成する車両サブシステムに基づく。閾値は、ＤＴＣを生成する車両サブシステムに基づいて選択され得る。

他の例では、上記で指定された目的は、車両と；複数の車両サブシステムと；車両サブシステムから１つまたは複数の診断トラブルコード（ＤＴＣ）を受信し、１つまたは複数のＤＴＣを１つまたは複数の学習済みモデルオブジェクトと比較することによって車両の不具合の確率を生成し、確率が閾値を超える場合、不具合の可能性があることを車両のオペレータに示す、非一時的なメモリに格納された、機械可読指示を有するコントローラとを備えるシステムによって達成され得る。

追加としてまたは代替として、これらの目的は、診断トラブルコード（ＤＴＣ）及びエンジン運転パラメータを受信することと；ＤＴＣ及びエンジン運転パラメータを学習済みモデルオブジェクトと比較して車両の不具合の確率及び指示を生成することと；不具合の確率が閾値より高いことに応じて、車両のオペレータに対して指示をスクリーン上に表示することとを含む方法によって達成され得る。

開示は、添付された図面を参照して、非限定的な実施形態の以下の記載を閲読することによってより良く理解され得る。

本開示の１つまたは複数の実施形態による予測不具合検出システムの１つまたは複数の態様を具現化する例示的な電子デバイスの図である。 車内予測不具合検出の例示的な方法の図である。 車内予測不具合検出システム及び／または方法で用いる学習済みモデルオブジェクトを生成する例示的な方法の図である。 セッションタイプを不具合セッションと非不具合セッションに振り分ける方法を示す。 例示的なパターンマイニングのワークフロー図である。 ２０１５年７月から２０１５年１２月の間のベイズの定理を用いたパターンランキングによる上位５つの識別された症状パターンの不具合の傾向の図である。 ２０１６年１月から２０１６年６月の間のベイズの定理を用いたパターンランキングによる上位５つの識別された症状パターンの不具合の傾向の図である。 感度及び特異度の図である。 一例による例示的な感度及び特異度の曲線の図である。 所与の確率カットオフによるモデル性能メトリックの図である。 様々な確率カットオフ値での真陽性率におけるトレードオフの図である。 モデル検証のための例示的なデータ準備ワークフローの図である。 例示的なデータビニング決定木の図である。 様々なデータセットにおける不具合モード及び非不具合モードの分布の図である。 不具合セッションの最も頻度の高いＤＴＣの図である。 ＤＴＣの数による不具合セッション対非不具合セッションの頻度の図である。 セッションにおけるＤＴＣの数による不具合の割合の図である。 不具合セッション及び非不具合セッションにおけるバッテリ電圧分布の図である。 図１８Ａは、様々な入力パラメータを用いたモデル精度結果の図である。図１８Ｂは、様々な入力パラメータを用いたモデル精度結果の図である。 図１８Ｃは、様々な入力パラメータを用いたモデル精度結果の図である。図１８Ｄは、様々な入力パラメータを用いたモデル精度結果の図である。 ＤＴＣの年齢の分布の図である。 図２０Ａは、２０１６年５月のデータセットに対するモデル性能メトリックの図である。図２０Ｂは、２０１６年６月のデータセットに対するモデル性能メトリックの図である。 図２１Ａは、バッテリ電圧及び走行距離計の読み取り値を含めないでのモデル性能メトリックの図である。図２１Ｂは、バッテリ電圧及び走行距離計の読み取り値を含めてのモデル性能メトリックの図である。

上述のように、車内予測不具合検出システム及び方法が提供される。以下は、本明細書中で用いる用語の定義を含む表である。

図１は、本明細書中に開示される予測不具合検出システム及び方法の１つまたは複数の態様を含み得る例示的な電子デバイス１００のブロック図である。電子デバイス１００は、電子デバイス１００に、車両サブシステムによって発行された１つまたは複数のＤＴＣを受信する、複数の車両センサから１つまたは複数の運転条件を受信する、ＤＴＣ（複数可）及び／または運転条件（複数可）を１つまたは複数のルールまたは学習済みモデルオブジェクトと比較する、不具合の確率をＤＴＣ、運転条件及び学習済みモデルオブジェクトに基づいて生成する、オペレータに、不具合の確率に基づいてメッセージを発行するといった、開示された方法またはコンピュータに基づく機能の１つまたは複数を行わせるために実行することができる指示のセットを含み得る。電子デバイス１００は、スタンドアロンデバイスとして動作し得、または、ネットワークを用いるなどして他のコンピュータシステムまたは周辺デバイスに接続され得る。具体的には、電子デバイスは、車両に接続されたスタンドアロンデバイスであり得、または、ＥＣＵなどの既存の車両システムにおいてコンピュータ可読指示としてインスタンス作成され得る。

ネットワーク化された配置の例では、電子デバイス１００は、サーバ−クライアントユーザネットワーク環境においてサーバの容量で、もしくはクライアントユーザコンピュータとして、ピアツーピア（または分散）ネットワーク環境においてピアコンピュータシステムとして、または様々な他の方法で動作し得る。電子デバイス１００はまた、デスクトップ及びラップトップコンピュータ、スマートフォン及びタブレットコンピュータなどのハンドヘルドデバイス、記録、再生及びゲームデバイスなどのポータブルメディアデバイス、ヘッドユニット及びナビゲーションシステムなどの自動車エレクトロニクス、または、他の機械であって、その機械によってとられるアクションをもたらす指示のセット（シーケンシャルなまたはその他の）を実行可能な他の機械といった様々な電子デバイスとして実装することもでき、または、それらに組み込むこともできる。電子デバイス１００は、声、音声、ビデオ及び／またはデータ通信を提供する電子デバイスを用いて実装され得る。単一の電子デバイス１００が例示されるが、用語「デバイス」は、さらなる詳細が以下に述べられる、予測不具合検出システムの１つまたは複数の電子機能を行うための指示のセットまたは複数のセットを個々にまたは一緒に実行するデバイスまたはサブデバイスの集合を含み得る。

電子デバイス１００は、中央処理装置（ＣＰＵ）、グラフィック処理装置（ＧＰＵ）またはその両方といったプロセッサ１０２を含み得る。プロセッサ１０２は、様々なシステムにおけるコンポーネントであり得る。例えば、プロセッサ１０２は、車両におけるヘッドユニットまたはＥＣＵの一部であり得る。また、プロセッサ１０２は、１つまたは複数の汎用プロセッサ、デジタル信号プロセッサ、特定用途向け集積回路、フィールドプログラマブルゲートアレイ、サーバ、ネットワーク、デジタル回路、アナログ回路、それらの組み合わせ、またはデータを分析かつ処理するための他の現在知られているもしくは後に開発されるデバイスを含み得る。プロセッサ１０２は、手動で生成されたまたはプログラミングされたコードなどのソフトウェアプログラムを実装し得る。

電子デバイス１００は、バス１１０を介して通信することができるメモリ１０４などのメモリを含み得る。メモリ１０４は、メインメモリ、スタティックメモリまたはダイナミックメモリであり得るか、またはそれらを含み得る。メモリ１０４は、非一時的なメモリデバイスを含み得る。メモリ１０４はまた、ランダムアクセスメモリ、読み取り専用メモリ、プログラム可能な読み取り専用メモリ、電気的にプログラム可能な読み取り専用メモリ、電気的消去可能読み取り専用メモリ、フラッシュメモリ、磁気テープまたはディスク、光学媒体などを含む様々なタイプの揮発性及び不揮発性記憶媒体といったコンピュータ可読記憶媒体も含み得る。また、メモリは、ソフトウェアが格納されている非一時的な有形的表現媒体を含み得る。ソフトウェアは、画像としてまたは別の形式で（光学スキャンを通してなど）電子的に格納され得、次いでコンパイルされ得、または解釈もしくは他の方法で処理され得る。

一例では、メモリ１０４は、プロセッサ１０２に対するキャッシュまたはランダムアクセスメモリを含む。代替例では、プロセッサのキャッシュメモリ、システムメモリまたは他のメモリなどのメモリ１０４は、プロセッサ１０２と分離し得る。メモリ１０４は、データを格納する外部格納デバイスまたはデータベースであり得るか、またはそれを含み得る。例として、ハードドライブ、コンパクトディスク（「ＣＤ」）、デジタルビデオディスク（「ＤＶＤ」）、メモリカード、メモリスティック、フロッピー（登録商標）ディスク、ユニバーサルシリアルバス（「ＵＳＢ」）メモリデバイス、またはデータを格納するよう動作する他のデバイスが挙げられる。例えば、電子デバイス１００はまた、ディスクまたは光学ドライブユニットも含み得る。ドライブユニットは、指示１２４などのソフトウェアまたは指示の１つまたは複数のセットを埋め込むことができるコンピュータ可読媒体を含み得る。プロセッサ１０２及びメモリ１０４はまた、指示またはソフトウェアを有するコンピュータ可読媒体も含み得る。

メモリ１０４は、プロセッサ１０２によって実行可能な指示を格納するよう動作可能である。図に例示されたまたは記載された機能、動作またはタスクは、メモリ１０４に格納された指示を実行するプログラミングされたプロセッサ１０２によって実行され得る。機能、動作またはタスクは、特定のタイプの指示セット、記憶媒体、プロセッサまたは処理戦略に非依存であってもよく、単独でまたは組み合わされて動作するソフトウェア、ハードウェア、集積回路、ファームウェア、マイクロコードなどによって実行され得る。さらに、処理戦略は、マルチプロセッシング、マルチタスキング、並列処理などを含み得る。

指示１２４は、電子デバイス１００及び／または例示的な予測不具合検出システムの態様を含む、本明細書中に記載された方法または論理の１つまたは複数を具現化し得る。指示１２４は、電子デバイス１００によって実行中、メモリ１０４内にまたはプロセッサ１０２内に完全にまたは部分的に存在し得る。例えば、本明細書中に開示された予測不具合検出システムのソフトウェア態様は、電子デバイス１００によって実行中メモリ１０４内にまたはプロセッサ１０２内に完全にまたは部分的に存在し得る、以下にさらなる詳細を論じる学習済みモデルオブジェクトの例を含み得る。

さらに、電子デバイス１００は、指示１２４を含む、またはネットワーク１２６に接続されたデバイスが声、ビデオ、音声、画像または他のデータをネットワーク１２６経由で通信することができるように伝播信号に応答して指示１２４を受信かつ実行するコンピュータ可読媒体を含み得る。指示１２４は、ネットワーク１２６経由で通信ポートまたはインタフェース１２０を介してまたはバス１１０を用いて送信または受信され得る。通信ポートまたはインタフェース１２０は、プロセッサ１０２の一部であり得、または別のコンポーネントであり得る。通信ポートまたはインタフェース１２０は、ソフトウェアにおいて作成され得、または、ハードウェアにおいて物理接続し得る。通信ポートまたはインタフェース１２０は、ネットワーク１２６、外部媒体、１つもしくは複数の入力デバイス１３２、１つもしくは複数の出力デバイス１３４、１つもしくは複数の車両サブシステム１３６、または電子デバイス１００における他のコンポーネント、あるいはそれらの組み合わせと接続するように構成され得る。ネットワーク１２６との接続は、有線Ｅｔｈｅｒｎｅｔ（登録商標）接続などの物理接続であり得、または、無線で確立され得る。電子デバイス１００の他のコンポーネントとのさらなる接続は、物理接続であり得、または、無線で確立され得る。ネットワーク１２６は、代替として、バス１１０に直接接続され得る。

ネットワーク１２６は、有線ネットワーク、無線ネットワーク、Ｅｔｈｅｒｎｅｔ（登録商標） ＡＶＢネットワーク、ＣＡＮバス、ＭＯＳＴバスまたはそれらの組み合わせを含み得る。無線ネットワークは、携帯電話ネットワーク、８０２．１１、８０２．１６、８０２．２０、８０２．１ＱもしくはＷｉＭａｘネットワークであり得、またはそれらを含み得る。無線ネットワークはまた、ＷＩ−ＦＩまたはＢＬＵＥＴＯＯＴＨ（登録商標）技術を介して実装された無線ＬＡＮも含み得る。さらに、ネットワーク１２６は、インターネットなどのパブリックネットワーク、イントラネットなどのプライベートネットワークもしくはそれらの組み合わせであり得、またはそれらを含み得、ＴＣＰ／ＩＰベースのネットワーキングプロトコルを含む現在利用可能なまたは後に開発される様々なネットワーキングプロトコルを利用し得る。電子デバイス１００の１つまたは複数のコンポーネントは、ネットワーク１２６によってまたはネットワーク１２６を介して互いと通信し得る。

電子デバイス１００はまた、ユーザが電子デバイスのコンポーネントとインタラクトすることを可能にするように構成されている１つまたは複数の入力デバイス１３２も含み得る。１つまたは複数の入力デバイス１３２は、キーパッド、キーボード及び／もしくはマウスなどのカーソル制御デバイス、またはジョイスティックを含み得る。また、１つまたは複数の入力デバイス１３２は、リモートコントロール、タッチスクリーンディスプレイ、または、電子デバイスと１つもしくは複数のユーザ及び／もしくは他の電子デバイスとの間のインタフェースとして機能するよう動作するデバイスといった、電子デバイス１００とインタラクトするよう動作する他のデバイスを含み得る。

入力デバイス１３２はまた、１つまたは複数のセンサも含み得る。１つまたは複数のセンサは、１つまたは複数の近接センサ、モーションセンサまたはカメラ（モバイルデバイスにおいて発見されるような）を含み得る。機能上、１つまたは複数のセンサは、モーション、温度、磁場、重力、湿度、水分、振動、圧力、電場、音、または潜在的なユーザもしくはユーザ周囲の環境と関連する他の物理的な側面を検出または測定する１つまたは複数のセンサを含み得る。入力デバイス１３２は、画像をキャプチャかつ生成するように構成されている１つまたは複数のカメラも含み得る。１つまたは複数のカメラは、電子デバイス１００の環境のデジタル画像を生成するように構成されているデジタルカメラまたは電荷捕獲デバイス（ＣＣＤ）であり得る。１つまたは複数のカメラは、可視光に応答する光学カメラ、赤外線カメラ、紫外線カメラ、または用途に適切な他のカメラを備え得る。

電子デバイスは、１つまたは複数の出力デバイス１３４を含み得る。出力デバイス１３４は、メッセージを表示する、音を再生する、ランプを照らす、または車両及び／もしくは電子デバイス１００の内部状態に関する情報をユーザに通信する目的のために他のアクションをとるように構成され得る。出力デバイスは、スクリーン、インジケータランプ、スピーカ、触覚フィードバックデバイスまたは他の適切なデバイスの１つまたは複数を含み得る。スクリーンは、一例において、車載インフォテインメントシステムの一部を形成するタッチスクリーンを備え得る。別の例では、スクリーンは、他の車載システムと別のコンポーネントであり得る。スクリーンは、テキストまたは視覚的なメッセージをユーザに対して生成するように構成され得る。スピーカは、１つまたは複数の音声チャネルを含むステレオシステムまたは音声サラウンドシステムの一部であり得る。具体的には、スピーカは、スピーカアレイを備え得る。スピーカは、ホーンドライバスピーカ、マグネットドライバウーファー及び／または圧電スピーカなどの電気機械式スピーカを備え得る。インジケータランプは、エンジン警告灯、またはダッシュボード、計器パネルもしくは他の場所に配置された他の適切なランプなどの、１つまたは複数の車両コンポーネントに組み込まれたＬＥＤまたは白熱灯を備え得る。触覚フィードバックデバイスは、ステアリングホイールなどの車両コンポーネントに容易に分かる信号を送って、メッセージをオペレータに通信するように構成されているデバイスを備え得る。出力デバイス１３４の１つまたは複数は、車両に組み込まれ得るか、または結合され得、他の例では、出力デバイス１３４の１つまたは複数は、電子デバイス１００に通信可能に結合されたスマートフォンまたは診断デバイスなどの別の機械システムの一部を形成し得る。例えば、出力デバイスは、ネットワーク接続１２６などの無線接続を介して、ＣＡＮバスを備え得るバス１１０に無線接続されているスマートフォンのタッチスクリーンを備え得る。さらに他の変形が可能である。

電子デバイス１００は、１つまたは複数の車両サブシステム１３６を含み得る。車両サブシステム１３６は、車両の一部を備え得、一例ではＣＡＮバスを備え得るバス１１０に通信可能に結合され得る。車両サブシステムは、車両の１つまたは複数の要素を含み得、例えばＯＢＤ−ＩＩ診断トラブルコード仕様によって提供される車両サブシステムカテゴリにしたがって、パワートレインサブシステム、シャーシサブシステム、車体サブシステム及びネットワークサブシステムを含み得る。他の例では、異なるサブシステムカテゴリ化スキームが用いられ得る。車両の要素は、機能的、構造的、かつ／または手続き上の考慮事項にしたがってグループ化され得る。一例では、車両サブシステムは、エンジンシステム、燃料供給システム、蒸発システム、点火システム、電気システム、ＨＶＡＣシステム、サスペンションシステムなどを含み得る。

車両サブシステム１３６は、１つまたは複数のＥＣＵ１３７及びセンサ１３８を含み得る。センサ１３８の非限定的な例として、ＭＡＰ／ＭＡＦセンサ、ＵＥＧＯ、ＨＥＧＯ、温度センサ、圧力センサ、湿度センサ、エンジン速度センサ、ホール効果センサ、ノックセンサなどが挙げられる。いくつかの例では、センサ１３８は、先に論じたように入力デバイス１３２の１つまたは複数を備え得る。センサは、エンジンシステム、吸気マニホルド、排気マニホルド、燃料タンク、車両タイヤ、冷却通路、ＥＧＲ通路、車室、車体及び他の適切な場所に配置され得る。ＥＣＵ１３７は、センサ１３８の１つまたは複数から信号を受信するように構成され得る。ＥＣＵ１３７は、当該信号をモニタリングかつ評価し得、１つまたは複数のＤＴＣを条件が保証するように出力するように構成され得る。ＤＴＣは、例えばＯＢＤ−ＩＩ規格にしたがって生成され得る。追加のまたは代替の標準または専用のＤＴＣ生成スキームが用いられ得る。

したがって電子デバイス１００は、車内予測不具合検出システム及び／または方法の１つまたは複数の態様を実装するように構成され得る。図２を参照すると、予測不具合検出方法の例が示される。

方法２００は、２１０において、プロセッサが、不具合を予測するための方法で用いられるテストルールを更新するリクエストがあるかないかを判定することで始まる。これらのルールは、以下に論じるように、方法３００で与えられるような機械学習技術によって生成された１つまたは複数の学習済みモデルオブジェクトを備え得る。ルールは、数学的かつ／または統計的関係のセット、決定木、データ構造、及び／または、不具合の確率を、ＤＴＣ、走行距離計の読み取り値またはバッテリ電圧などの１つもしくは複数の運転条件に基づいて判定するヒューリスティクスを備え得る。ルールは、運転条件に基づいてとられる指示または示唆アクションを指定し得る。一例では、方法２００は、予測不具合判定システムが初めて動作されるとテストルールが更新されるようリクエストし得る。他の例では、方法２００は、例えばネットワーク接続を通して遠隔で、テストルールを更新するリクエストを受信し得る。代替として、方法２００は、前回の更新から所定時間が経過した後、テストルールに対する更新をリクエストし得、すなわち、例えば、方法は、１か月に、他の所定間隔に、または車両が起動するごとに一度、ルール更新をリクエストし得る。更新がリクエストされると、処理は２１５に進む。更新がリクエストされないと、処理は２２０に進む。

２１５において、方法２００は、テストルールを更新することに進む。このことは、新しいルールに対するリクエストを送ること及び新しいルールを受信することを備え得る。リクエストは、ローカルもしくはリモートサーバ、ネットワークまたは他のデータソースに送られ得る。新しいルールは、同一のまたは異なるソースから受信され得る。一例では、データソースは、現在のテストルールのセットを置き換えるようにテストルールの完全なセットを送り得る。別の例では、データソースは、最後の更新リクエストよりも新しいまたは変更されているルールのみを送り得る。更新されたルールを受信すると、処理は２２０に進む。

２２０において、方法は、運転条件をモニタリングすることに進む。このことは、例えばセンサ１３８及び／または入力デバイス１３２などの１つまたは複数のセンサによって生成された信号をモニタリングすることを含む、電子デバイス１００が配置されている車両の運転条件をモニタリングすることを含み得る。このことは、走行距離計の読み取り値及び／またはバッテリ電圧信号をモニタリングすることを含み得る。以下の処理でモニタリングされかつ用いられ得る運転条件の他の非限定的な例として、エンジン速度、負荷、トルクリクエスト、排気温度、空気燃料比、冷媒温度、ＭＡＦ／ＭＡＰ、速度、湿度、ブレーキリクエスト、点火タイミング、バルブタイミングまたは他の適切な条件が挙げられる。次いで、処理は２３０に進む。

２３０において、方法は、診断トラブルコードをモニタリングする。ＤＴＣは、１つまたは複数のＥＣＵ１３６によって生成され得る。プロセッサはまた、生成されたＤＴＣの年齢もモニタリングし得る。このことは、全てのＤＴＣ、または、特定の車両サブシステムによって生成されたＤＴＣもしくは特定の年齢のＤＴＣなどのＤＴＣのサブセットのみをモニタリングすることを含み得る。例えば、ＤＴＣをモニタリングすることは、閾値年齢より少ないＤＴＣのみをモニタリングすることを含み得る。一例では、閾値年齢は、１日、３日、５日、または他の適切な数といった日数であり得る。この例では、方法は、閾値年齢より古い全てのＤＴＣを無視し得る。しかしながら、方法は、いくつかの例においてはいかなるＤＴＣも無視しなくてもよく、車両サブシステムによって生成された全てのＤＴＣを後続の処理ステップで用いてもよいことが理解されよう。次いで、処理は２４０に進む。

２４０において、方法は、ＤＴＣ及び運転条件を１つまたは複数のルールまたは学習済みモデルオブジェクトと比較することを含む。このことは、ＤＴＣ及び条件を、１つまたは複数の統計的もしくは数学的関係、決定木、データ構造または他のオブジェクトと比較することを含み得る。学習済みモデルオブジェクトの例は、観察されたＤＴＣのセットが｛Ｂ１１ＦＦ，Ｕ２１００｝を含む場合、不具合の確率がその後の５日間で８０％に示されることを特定するルールを含み得る。学習済みモデルオブジェクトは、さらなる関係を含み得る。前の例を続けると、学習済みモデルオブジェクトは、予測可能な方法で不具合の確率が総走行距離とともに上がることを特定するさらなるルールを含み得、８０％のベース確率は、観察された走行距離計の読み取り値が増加すると上がり、走行距離計の読み取り値が低くなると下がるように、走行距離計の読み取り値に基づいて修正されることを特定し得る。

他の例では、学習済みモデルオブジェクトは、車両の運転条件にしたがって変わり得る動的なルールを含み得る。例えば、ルールは、ＤＴＣ｛Ｐ２４５９，Ｕ０１２８｝が７４％の不具合の確率を示すが、不具合の確率はエンジン負荷にしたがって動的にさらに変わることを特定し得る。不具合の確率は、エンジン負荷が増大すると高くなり得、エンジン負荷が低くなると減少し得る。学習済みモデルオブジェクトはまた、ブロック２７０を参照して以下に論じられる、観察されたＤＴＣ及び／または１つもしくは複数の運転条件に基づいて指示または推奨を特定するルールも含み得る。ＤＴＣ及び運転条件が学習済みモデルオブジェクト及び／またはルールと比較されると、処理は２５０に進む。

２５０において、方法は、不具合の確率を判定する。一例では、このことは、１つのルールまたは学習済みモデルオブジェクトの単純な適用により達成され得る。前のステップで行われた比較に基づいて、ルールまたは学習済みモデルオブジェクトは、不具合の確率を与え得る。他の例では、１つより多いルールまたは学習済みモデルオブジェクトが用いられ得る。例えば、ＤＴＣ及び／または観察された他のパラメータのパターンが複数のルールによって網羅される場合、方法は、確率を適切に組み合わせることを含み得る。例えば、方法は、最も低い確率、最も高い確率または何らかの代数的結合を選択し得る。具体的には、不具合の複数の確率Ｐ_１．．．Ｐ_ｎを提供する複数のルールＲ_１．．．Ｒ_ｎの場合、方法は、不具合の全体的な確率Ｐを、
Ｐ＝１−（１−Ｐ_１）（１−Ｐ_２）・・・（１−Ｐ_ｎ）
にしたがって計算し得る。不具合の確率が判定された後、処理は２６０に進む。

２６０において、方法は、任意選択的に、あらかじめ生成された確率を閾値と比較することを含む。代替として、閾値比較は、方法３００を参照して以下に記載するモデル生成プロセスの一部として行われ得る。具体的には、ブロック３８０において、最適なカットオフ確率が規定され得る。ブロック３８０を参照して以下に論じる手続きは、代替として、方法２００の一部としてブロック２６０で行われ得る。したがって、２６０において、確率は、閾値と比較され得る。閾値は、所定かつ一定であり得、または、運転条件に基づいて判定され得る。例えば、方法は、高い速度かつ／または負荷の条件中は、低い確率閾値を選択し得、低い速度かつ／または負荷の条件中は、高い確率閾値を選択し得る。このことは、例えば様々な運転条件における不具合の増大したまたは減少した機会にしたがう方法の動的な制御を可能にし得る。別の例として、様々な確率閾値が、プロセッサによって受信されたＤＴＣにいずれの車両サブシステムが関わるかにしたがって、選択され得る。例えば、方法は、エンジンサブシステムを含むＤＴＣに対して低い確率閾値を選択し得、電気またはＨＶＡＣシステムを含むＤＴＣに対して高い確率閾値を選択し得る。さらなる他の変形が可能である。不具合の確率が閾値確率よりも低いと判定される場合、方法は２２０に戻り、運転条件及びＤＴＣのモニタリングを続ける。不具合の確率が閾値確率よりも大きいと判定される場合、方法は２７０に進む。

２７０において、方法は、ＤＴＣ、運転条件及び／または学習済みモデルオブジェクトに基づいて指示を生成する。生成された指示は、人間のオペレータに送られ理解されることを意図され得る。例示的な指示は、「エンジンをチェック」または「車両をすぐに点検修理」といった比較的簡単な指示を含み得る。他の例では、方法は、「車両をＸ日内に点検修理」といった、より具体的な指示を生成し得る。ここでＸは、ＤＴＣ、運転条件及び／または学習済みモデルオブジェクトに基づいて判定される。指示はまた、「車両を可能な限り早く点検修理」も含み得る。方法が、不具合が差し迫っていると判断した場合、生成された指示は「即座に停車」を含み得る。方法は、追加としてまたは代替として、不具合の可能性を最小にすることを意図した具体的な運転挙動に対する指示をオペレータに生成し得る。これらの種類の指示の非限定的な例は、「速度を低減」または「空調機の電源を切る」を含み得る。

具体的な指示は、ＤＴＣ、運転条件及び／または学習済みモデルオブジェクトに基づいて生成され得る。指示はまた、上記で判定された確率にも基づき得る。例えば、方法が「車両をＸ日内に点検修理」という指示を生成するとき、Ｘは、確率に基づいて判定され得る。日数は、確率と反比例関係にあり得、より高い不具合の確率は、より少ない日数に対応し、逆の場合も同じである。「車両を可能な限り早く点検修理」及び「即座に停車」といった指示は、ブロック２６０で用いられた確率閾値よりも高い第２の閾値よりも大きい不具合の確率といった非常に高い不具合の確率に基づいて生成され得る。いくつかの例では、具体的な指示は、学習済みモデルオブジェクトに含まれ得る。例えば、ＨＶＡＣシステムにおける不良をＨＶＡＣ ＥＣＵによって生成されたＤＴＣに基づいて診断する学習済みモデルオブジェクトは、不具合の確率が閾値より大きいときに「空調機の電源を切る」という指示を含み得る。方法は、指示の１つまたは複数のセットを、上記の考慮事項に基づいて生成し得る。指示が生成された後、処理は２８０に進む。

２８０において、方法は、指示をオペレータに表示することに進む。このことは、出力デバイス１３４の１つまたは複数を用いて行われ得る。指示は、エンジン警告灯を点灯させることによって、テキストメッセージをスクリーンに出力することによって、可聴メッセージをスピーカ経由で再生することによって、または別の適切な方法で表示され得る。指示がオペレータに表示された後、方法２００は戻る。

次に図３を参照すると、上述の車内予測不具合検出システムで用いる学習済みモデルオブジェクトまたはルールを生成する方法３００が示される。方法３００は、ルールまたは学習済みモデルオブジェクトを生成するために１つまたは複数のコンピュータ学習技術を用い得る。これらのルールまたは学習済みモデルオブジェクトは、不具合の確率を予測的に判定すること及び／またはオペレータ指示を生成することに用いる電子デバイス１００及び／または方法２００で採用され得るか、またはインスタンス作成され得る。高水準で、以下のステップが行われる。
１．データの理解、クリーニング及び処理
２．より速いモデル構築及びデータ抽出を容易にするためにＨａｄｏｏｐ Ｍａｐ−Ｒｅｄｕｃｅデータベースに最適な方法でデータを格納するデータ格納戦略
３．不具合の予測におけるＤＴＣ及び他の誘導変数の予測力
４．実際の不具合の前の事前通知をチェックするためのＤＴＣデータの持続時間解析
５．不具合を引き起こすＤＴＣパターンを検出するための相関ルールマイニング
６．不具合を引き起こす関連傾向によってＤＴＣパターンをランク付けするためのルールランキング方法
７．不具合を引き起こすＤＴＣパターンを学習用データから識別する予測モデル
８．混同行列を用いることによってサンプルデータから不具合を識別する際のモデル検証
以下で論じる方法及び実験に基づいて、下記の結果が得られた。
・非不具合よりも不具合の原因となることが多いＤＴＣを、実際の故障の前に、妥当な精度かつ十分な事前通知をもって発見することができる。
・実際の不具合の少なくとも１日前にデータを用いて６５％より高い精度で不具合を予測することを支援するＤＴＣパターンをデータから見つけることができる。すなわち、不具合を、６５％より高い精度で実際の故障の少なくとも１日前に予測することができる。
・走行距離計及び／またはバッテリ電圧のような、ＤＴＣパターンへのさらなるデータの追加により、故障の予測精度を７５％まで高めることができる。
・６５％より高い精度が達成される。

方法は、３１０において、適切なデータベースがまとめられることで始まる。データベースは、車両モデル、総走行距離（走行距離計の読み取り値）、バッテリ充電状態または例えばＤＴＣが設定されたときにもしくはセッションが開始されたときに測定された任意の他の運転条件といった他の情報と併せて、期間中に１つまたは複数の車両によって生成されたＤＴＣを含むデータからまとめられ得る。車両フィードバックデータベースは、データ抽出のために用いられ得る。加えて、セッションタイプフラットファイルは、セッションファイル名をセッションタイプにマッピングするのに用いられ得る。

いくつかのクエリが、データベースユーザガイドを参考にしてデータベース全体を理解するために実行し得る。加えて、データ辞書は、ＤＴＣデータの各フィールドを理解するのに用いられ得る。クエリは、以下の基準及び分析のための最終的なデータ抽出用のデータベース上の後処理をもって実行された。
・ＤＴＣ（スナップショットを有する）基準として：２０１４年６月〜２０１６年６月
・ウェブサイトからＨＴＴＰコールを用いて自動抽出
・２０１４年１０月開始のみ利用可能な症状データ

セッションタイプデータは、２０１４年６月〜２０１６年６月の全てのセッションにおいて利用可能であった。データベースをまとめることは、さらに、セッションデータを不具合セッションと非不具合セッションに振り分けることを含む。不具合セッションは、例えば、機能停止または路上支援セッションを含み得、一方、非不具合セッションは、例えば、ルーティン保守またはサービスを含み得る。不具合セッション及び非不具合セッションを区別するために、以下のルールが用いられ得る。
・不具合セッションは、特定の販売店からのセッションのみである
・他の全てのセッションは、非機能停止セッションである
・「サービス機能」タイプの非機能停止セッションは、非不具合セッションとして扱われる
このルールの例は、図４において図表４００によって示される。適切なデータベースがまとめられると、処理はステップ３２０に進む。

ステップ３２０において、方法は、データのクリーニング及び前処理を含む。重複及び無効データに関するいくつかの問題が、データベースから抽出された生データに存在し得る。インポートされたデータは、結果的な学習済みモデルオブジェクト及び車内予測不具合検出システムのロバストな操作を確保するために、クリーニングまたは前処理を必要とし得る。例えば、いくつかのセッションで、ＤＴＣの重複が発見され得る。重複するＤＴＣは、自動スクリプトを用いて削除され得、各ＤＴＣはセッションにおいて一度のみ出現するように、セッションにおいて最初に出現するＤＴＣのみが保持され得る。さらに、いくつかの路上支援セッションは、可能ではない「サービス機能」タイプとしてマークされる。これらのセッションは、分析から削除される。次いで、処理は３３０に進む。

３３０において、方法は、まとめられたデータベースに関してパターンマイニングを行うことを含む。系列及び非系列パターンベースのルールマイニングによって各不具合のタイプを予測する実行可能性をチェックするために、分析はまず、１か月のデータにわたるＤＴＣ及び症状に関して行われ得る。このプロセスを示す例示的なワークフロー５００が図５に見られ得る。

非系列パターンマイニングは、パターンマイニング３３０の一部として３３２において行われ得る。非系列パターンマイニングは、以下の手続きを含む。１か月間の症状データ及びスナップショットデータは、一定のフィルタ条件で２０１６年５月〜２０１６年６月に対してＨａｄｏｏｐから抽出された。この期間中に観察された症状の総数は１０９５であった。このデータを用いて、上位の不具合モードが区分される。異なるレベルを有する５つの症状にわたる不具合モードの頻度は系列マイニングを用いて推定され、上位の不具合モードはさらに識別される。レベル４をカットオフとする上位５つの症状パスは、以下の表に示すように、全故障のうち４０％を含む。

この表が示すように、４つのカテゴリ「電気系統−＞計器−＞情報及びメッセージセンター−＞メッセージ表示領域」で始まる不具合モードは、テスト期間中に観察された１０９５の症状パターンのうち５７の割合を占める。先の３つの症状パスと合わせると、組み合わされたこれらの４つのグループは、観察された全不具合モードの３４．５％を含む。次いで、これらの識別された不具合モードは、非系列パターンマイニングアルゴリズムでさらに処理される。

パターンマイニング３３０は、３３４において相関ルールマイニングも含み得る。相関ルールマイニングのために、上位５つの症状パスは、主な不具合モードとして識別され、この不具合モードに対応するセッションファイル名は、不具合モードの原因となるＤＴＣを識別するためにＤＴＣのスナップショットデータからマッピングされる。観察されたＤＴＣは、セッションファイル名に対してマッピングされ、高いサポート及び信頼度を有するパターン（ＤＴＣのセット）は、相関ルールマイニング（ＡＲＭ）を用いて推定される。不具合モード２は、Ｂ１１ＦＦ及びＵ２１００によって生じ、ここでは系列はキャプチャされない。この分析の結果を以下の表に示す。

系列パターンマイニング３３６もまた、パターンマイニング３３０の一部として行われ得る。系列パターンマイニングは、小さなデータセットに関して用いられて、ＤＴＣの系列が、判定されたルールの信頼度、サポートまたはリフトに違いをもたらしたかどうかを判定し得る。系列ルールマイニングでは、観察されたＤＴＣは、時系列として、セッションキーに対してマッピングされ、高いサポート及び信頼度を有するパターン（ＤＴＣのセット）は、系列マイニングアルゴリズムを用いて推定される。系列ルールマイニングの結果を以下の表に示す。
不具合モード１の場合、系列ルール及び非系列ルールの両方が、Ｐ０１３０を、不具合を引き起こすＤＴＣとして識別した。ＤＩＤに基づくさらなる分析が、このＤＴＣが生じたセッションに対して、不具合の任意の兆候があるかどうか―すなわちＤＩＤ値のいずれかが範囲外にあるかどうかを見つけるために行われた。しかしながら、全てのＤＩＤ値は高低範囲内にあったので、ＤＩＤ値単独に注目して結論を引き出すことはできなかった。

系列パターンマイニングは、ＤＴＣの順序または系列に依存する１つまたは複数のルールまたは学習済みモデルオブジェクトを生成し得る（以下を参照）。ルールは、ＤＴＣの順序に依存して異なり得る。すなわち、いくつかの例では、ＤＴＣのセットは、第１の順序で第１の不具合の確率を、第２の順序で第２の確率を生成し得、第２の確率は第１の確率とは異なるものである。例えば、２つの異なるＤＴＣを備えるＤＴＣのセットは、第１の順序で第１の確率を生成し得、ＤＴＣが第１の順序とは異なる第２の順序、例えば逆の順序で検出される場合、例えば第１の確率より大きい第２の確率を生成する異なる系列ルールが適用され得る。

他の例では、系列ルールは、ＤＴＣの順序に依存して、異なる指示をオペレータに提供し得る。一例では、第１の順序のＤＴＣのセットは、「車両を５日以内に点検修理」という指示を提供し得、一方、第２の異なる順序のＤＴＣの同一のセットは、「即座に停車」という指示を提供し得る。別の例では、ＤＴＣの第１の順序は、「空調機の電源を切る」などの指示を提供し得、一方、ＤＴＣの第２の異なる順序は、全く何の指示も提供しなくてもよい。さらに他の変形が可能である。

この分析を続け、サンプルサイズは６か月のデータを含むように拡大され、ＤＴＣの系列はこの調査において検討事項でなくてもよいので、非系列パターンマイニングのみが行われた。不具合タイプの原因となる非系列パターンを導出するために、上述のような大きなデータセット及び同様のパターンマイニング手法を用いることが行われた。症状データ及びスナップショットデータは、市場及び販売店に関するフィルタ条件をもって２０１６年１月１日から２０１６年６月２５日の間にＨａｄｏｏｐ ＤＢから抽出された。観察された症状の総数は、８３７６であった。

非系列パターンマイニングのためのデータ準備は、上位の不具合モードの分類をして進む。異なるレベルを有する５つの症状にわたる不具合モードの頻度は、系列マイニングを用いて推定され、上位の不具合モードはさらに識別される。レベル４の上位６つの症状パスが、カットオフとしてとられる。各セッションファイルは、複数回記録された同一の症状パターンを有している。これらの６つの症状パターンを含むセッションファイルの総数は、３０５７である。これらのパターンを以下の表に示す。

次いで、方法は、準備されたデータに関して非系列ＤＴＣパターンマイニングを行う。上位６つの症状パスは、主な不具合モードとして識別され、この不具合モードに対応するセッションファイル名は、不具合モードの原因となるＤＴＣを識別するために、ＤＴＣスナップショットデータからマッピングされる。上位６つの症状パターンからの３０５７のセッションファイルのうち、２８５０のみが観察される。なぜなら、他のセッションファイルは、ＤＴＣスナップショットデータに記録されていないからである。非不具合モードが生じたセッションの総数は、３８８９９である。生じたＤＴＣは、セッションファイル名に対してマッピングされ、高いサポート及び信頼度を有するパターン（ＤＴＣのセット）は、相関ルールマイニング（ＡＲＭ）を用いて推定される。不具合モード２、３及び４は、これらの不具合モードの原因となるＤＴＣのサポートが０．０５％未満であるので、観察されない。非系列パターンマイニングの結果を以下の表にまとめる。

上記の表は、ルールマイニングの結果を示す―特に、最終列は、不具合セッションならびに非不具合セッションを引き起こす同一のルールに対するサポートを比較する。これは、非不具合よりも不具合を引き起こす傾向が高いルールを識別するように、同一のルールが不具合ならびに非不具合セッション両方で生じ得るルールをランク付けする方法の導出を動機付ける。

この分析に基づいて、示唆される次のステップは、全ての不具合タイプを単一のモードにグループ化することと；ルールを比較し不具合を引き起こすルールの関連傾向にしたがってそれらルールをランク付けするために不具合及び非不具合モードを組み合せた単一の信頼度測定値を導出することと；フルＤＴＣ―すなわち、フルＤＴＣ＝モジュール−ＤＴＣ−型記述においてモジュール名を使用することであった。これらの点を考慮して、ベイズのルールが適用され得る。非系列パターンマイニングが完了した後、処理は３４０に進む。

３４０において、方法は、ベイズの定理を用いたパターンランキングを含む。不具合を引き起こすことにおいて関連する重要度（例えば、相対的な可能性）によって、非系列パターンマイニングから導出されたパターンをランク付けするために、ベイズの定理が用いられる。パターンは、パターンが以下で生じたと仮定して、不具合の条件付き確率によってランク付けされる。
この等式は、パターンＰ１がセッションで生じたと仮定して、不具合Ｆの確率を推定する―それは、Ｐ１の全サポートにおける、不具合を生じさせるＰ１のサポートの割合である。

この方法における各項は、以下のように解釈され導出される。
Ｐｒ（Ｆ）−母集団のうちの不具合の確率。これは、路上支援設備を有する（３年間の）車両の数を得るための２０１３年１月〜２０１６年６月の売上データ及び２０１６年１月〜２０１６年６月の期間中に観察された実際の不具合の数を用いて推定された。２０１６年１月〜２０１６年６月の期間における例：Ｐｒ（Ｆ）＝（不具合セッションの数）／（２０１３年１月〜２０１６年６月の総売上）
Ｐｒ（ＮＦ）−母集団のうちの非不具合の確率、Ｆ及びＮＦは相互に排他的であるので、１−Ｐｒ（Ｆ）となる
Ｐｒ（Ｐ１｜Ｆ）−不具合の原因となるパターンＰ１の条件付き確率：Ｐｒ（Ｐ１｜Ｆ）＝（パターンＰ１を含む不具合セッションの数）／（不具合セッションの総数）
Ｐｒ（Ｐ１｜ＮＦ）−非不具合の原因となるパターンＰ１の条件付き確率：Ｐｒ（Ｐ１｜ＮＦ）＝（パターンＰ１を含む非不具合セッションの数）／（非不具合セッションの総数）
図６Ａ及び６Ｂは、ベイズの定理を用いたパターンランキングの結果を示す。図６Ａは、２０１５年７月〜２０１５年１２月の間の不具合における上位５つのパターンの傾向のチャート６００ａを示す。図６Ｂは、２０１６年１月〜２０１６年６月の間の不具合における上位５つのパターンの傾向のチャート６００ｂを示す。

サンプルデータからのデータに関してモデルを学習することから導出されたルールを用いてモデルを検証する新しいメソッドは、ベイズのルールに基づくパターンランキングメカニズムを拡張することによって開発され得る。
Ｐｒ（Ｆ｜ＤＴＣ）ｖ＝パターンが検出されたと仮定される検証セッションの車両の不具合の確率、ＤＴＣ
Ｐｒ（Ｆ）＝車両不具合の確率
Ｐｒ（ＮＦ）＝１−Ｐｒ（Ｆ）＝故障していない、すなわち機能停止していない車両の確率
Ｐｒ（ＤＴＣ｜Ｆ）ｔ＝不具合学習用データにおいて車両が故障したと仮定してパターンＤＴＣを知覚する確率
Ｐｒ（ＤＴＣ｜ＮＦ）ｔ＝非不具合学習用データにおいて車両が故障していないと仮定してパターンＤＴＣを知覚する確率
上記の計算を用いて、学習用セットから推定された先験確率から検証セット（サンプル外）における不具合の条件付き確率を推定し得る。ベイズの定理を用いたパターンランキングが完了した後で、方法は、３５０に進む。

３５０において、方法は、カットオフ確率を選択することに進む。カットオフ確率は、閾値確率値であり得、不具合の判定された確率が閾値を上回る場合、潜在的な不具合がオペレータに示され、一方、不具合の判定された確率が閾値を下回る場合、潜在的な不具合はオペレータに示されなくてもよい。追加としてまたは代替として、このことは、方法２００の一部として、例えばブロック２６０〜２８０において起こり得る。このことは、確率を車内予測不具合検出システムにおいてローカルにまたは非ローカルに選択することを含み得、複数の異なる閾値を含み得、かつ／または、不具合の確率の関数に基づいてまたは不具合の確率の関数としてオペレータに指示を発行することを含み得る。これらの機能は、先に論じたように、例えば方法２００のブロック２６０に含まれ得る。しかしながら、他の例では、適切な確率カットオフ閾値の選択は、方法３００の一部として３５０において行われ得る。

セッションを不具合または非不具合として識別するのに、カットオフ確率は、不具合セッション及び非不具合セッションの両方のＤＴＣパターン確率を用いることによって導出される。このプロセスは、｛ＤＴＣｉ｝（ｉ＝１．．ｎ）を含む学習用セットにおけるセッションごとに、ＤＴＣの全ての可能なパターン（すなわち｛ＤＴＣｉ｝のべき集合）を作成することを含む。そして、Ｐにおけるｙごとに、Ｐｒ（Ｆ｜ｙ）が、先に論じたように、ベイズの定理を用いて推定される。次いで、最も高いＰｙ＝Ｐｒ（Ｆ｜ｙ）を有するパターンｙは、不具合を実際に引き起こすパターンとして識別される。異なるセッションからのＰ_ｙごとの感度及び特異度曲線が、次いで推定される。感度及び特異度の例示７００について図７を参照されたい。不具合カットオフ確率は、これらの２つの曲線（感度及び特異度曲線）の交点となり、この交点は、不具合ならびに非不具合セッションに対する最も高い全体区分を与えるであろう。

区分のためカットオフ確率を用いるために（以下に論じる検証中に）、以下のルールが観察される。すなわち、検証セットにおけるセッションごとに、Ｐ_ｙは、先に論じたように推定される。Ｐ_ｙがカットオフ確率以上である場合、セッションは不具合として区分され、それ以外の場合は非不具合として区分される。

この手続きの例として、１つのセッションファイルが検討される。すなわち、セッションファイルに対して観察されたＤＴＣは、ＡＢＳ−Ｕ３００６−１６、ＰＣＭ−Ｐ０５０４−６２、ＰＣＭ−Ｐ２２６３−２２、ＰＣＭ−Ｐ２５３Ｆ−００である。セッションにおいて観察されたＤＴＣ内のパターンの異なる組み合わせの不具合の確率は、Ｐ（Ｆ）＝０．００２８５４９８９、Ｐ（ＮＦ）＝１−Ｐ（Ｆ）＝０．９９７１４５０１１をプラグインすることにより計算され減少順でソートされる。観察された最大確率は、１００％の確率を除きセッションが不具合であるか非不具合であるかを予測するために検討される。したがって、ここで、｛ＡＢＳ−Ｕ３００６−１６，ＰＣＭ−Ｐ２２６３−２２｝における最も高い確率＝２．７１％は、不具合セッションのために学習するのに用いられるであろう。同様の手続きは、学習用データセットにおけるセッションごとに繰り返される。図８は、この例から描画される感度及び特異度曲線のグラフ８００を示す。

図８では、２つの曲線は、ｘ値０．０１２１６３５で交差し、これは、用いられる最適なカットオフである。セッションは、Ｐ（Ｆ｜ＤＴＣ）がカットオフ確率より大きい場合は不具合として、それ以外の場合は非不具合として区分される。０．０１２１６３５のカットオフに基づいて、検証結果は、図９のチャート９００に示されるように、６４．４７％という全体精度をもたらす。様々なカットオフ値での真陽性率におけるトレードオフは、図１０のチャート１０００に示される。カットオフ確率が選択された後で、方法は３６０に進む。

３６０において、モデル検証が行われる。モデル検証は、ブロック３６２のように、バッテリ電圧及び走行距離計の読み取り値などのさらなる条件の、不具合の可能性への寄与を評価することを含み得る。１つの車両モデルに対して全てのセッションを用いると、１２の異なるモデルが、以下による組み合わせにおいて構築された。
・３つのＤＴＣパターン−｛フルＤＴＣ，フルＤＴＣ＋走行距離計＋＃ＤＴＣ，フルＤＴＣ＋走行距離計＋＃ＤＴＣ＋バッテリ電圧｝
・不具合の４つの時間−｛最後のＤＴＣ，最後のＤＴＣから１日，最後のＤＴＣから３日，最後のＤＴＣから５日｝
モデル検証のためのデータ準備及びワークフローは、図１１の図表１１００に示される。

データセットにおける欠測値は、適切な手続きにしたがって対処され得る。ＤＴＣの約２５％は、バッテリ電圧が埋められていない。これらは、別の「ＮＡ」カテゴリと見なされる。セッションごとに記録された総距離は、そのセッションにおける走行距離計の読み取り値と見なされる。総距離が「ゼロ」である場合、そのセッションにおけるそのパラメータの最大値は、欠測値の対処として、走行距離計の読み取り値と見なされる。

バッテリ電圧、走行距離計及び＃ＤＴＣなどの連続変数は、以下の処理で用いるためにビニングされる。図１２に示す例示的な木１２００などの決定木は、データビニングに用いられ得る。最後に、セッションにおける各ＤＴＣは、モデリング段階における入力として、モジュール名−ＤＴＣ−ＴｙｐｅＤｅｓｃ−走行距離計 Ｂｉｎ−バッテリ電圧 Ｂｉｎ−ＤＴＣの数 Ｂｉｎに変換される。

モデル検証の結果を、以下の図に示す。学習（２０１４年１０月〜２０１６年４月）、テスト（２０１６年５月）及び検証（２０１６年６月）データ１３００における不具合対非不具合セッションの分散が、図１３に示される。不具合セッションにおける上位ＤＴＣの頻度数は、図１４のチャート１４００に示される。セッションにおける＃ＤＴＣによるセッションの頻度数は、図１５のグラフ１５００に示される。図１６のグラフ１６００に示すように、セッションにおける＃ＤＴＣが増加するにつれて、セッションが不具合セッションである確率は高まる。

不具合セッション及び非不具合セッションの割合の比率は、バッテリ電圧と逆相関する―比率は、バッテリ電圧が低いと高くなり、これは、低いバッテリ電圧では、非不具合セッションより不具合セッションを見つける機会が多いことを示す。このことは、図１７のチャート１７００に示される。

モデル検証中、不具合と入力変数の組み合わせの間の相関ルールは、以下に対して導出された。
・フルＤＴＣ−モジュール＋ＤＴＣ＋型記述
・走行距離計の読み取り値
・ＤＴＣの数
・バッテリ電圧
ブロック３６４のように、異なる日のカットオフの効果もまた調べられた―すなわち、最後のＤＴＣ、最後のＤＴＣが生じるより１日前、３日前、５日前までのデータを用いて。このことを以下の表に示す。

最後のＤＴＣ、１日、３日及び５日のカットオフを用いたモデル検証結果は、カットオフ期間が増加するにつれてデータの利用可能性は減るので、カットオフが増加するにつれて全体精度が低くなることを示す。このことは、図１８Ａのチャート１８００ａに示される。

フルＤＴＣ、走行距離計の読み取り値及びＤＴＣの数の組み合わせを、モデルに対する入力として用いるとき、精度の、類似しているがより一貫した減少が見られる。これらの結果は、図１８Ｂのチャート１８００ｂでまとめられる。

特徴の組み合わせ、フルＤＴＣ、走行距離計の読み取り値、ＤＴＣの数及びバッテリ電圧を用いるとき、バッテリ電圧を含むことは、利用不能なバッテリ電圧セッションからの偏った精度により、全体精度を実際に減少させたことがわかった。このことは、図１８Ｃのチャート１８００ｃに示される。

バッテリ電圧を用いることは、真陰性ケースへ大きく偏っているが真陽性ケースに関して不十分に機能する結果を与えるだけである―すなわち、非不具合ケースは正確に予測するが、実際の不具合を予測するにおいて非常に低精度である。このことは、図１８Ｄのチャート１８００ｄに示される。（注：この結果のために、セッションの最小バッテリ電圧が、不具合を予測するための従属変数として用いられた）

結果の全ての組み合わせから、フルＤＴＣ＋走行距離計＋＃ＤＴＣ及び１日のカットオフを用いたモデル結果が、最後のＤＴＣモデルと比較して、精度に関してほとんど妥協することなく、不具合に対する十分な事前通告をもって最適であるように見える。

記述的分析及び予備的なモデル結果に基づいて、以下の結論を引き出すことができる。
・非不具合よりも不具合の原因となることが多いＤＴＣを、実際の機能停止の前に、妥当な精度かつ十分な事前通知をもって発見することができる。図１９のチャート１９００は、ＤＴＣの日齢の分布を示す。
・ベイズのルールを用いたパターンランキングは、主に不具合そして非不具合の両方を引き起こすＤＴＣパターンを識別するにおいて効果的な方法であり、異なる期間にわたって６５％より大きい一貫した結果を与える。図２０Ａ及び２０Ｂは、チャート２０００ａ及び２０００ｂにおいて、２０１６年５月及び２０１６年６月のデータに対するモデル性能メトリックを示し、当該一貫性を示している。
・最後のＤＴＣの発生より前のデータから導出されたパターン及びパターンランキングベースの予測を用いて、実際の機能停止の少なくとも１日前に、６０％より高い精度で不具合を予測することができる。最後のＤＴＣの発生に基づくモデル性能メトリックは、図２１Ａのチャート２１００ａに示される。
・走行距離計、バッテリ電圧などの、ＤＴＣパターンへの更なるデータの追加により、実際の不具合予測の少なくとも１日前において、機能停止の予測精度を８％高めることができる。走行距離計の読み取り値及びバッテリ電圧を含むさらなるパラメータを有するモデル性能メトリックは、図２１Ｂのチャート２１００ｂに示される。
モデル検証後、処理は３７０に進む。

３７０において、方法は、先行のプロセスステップに基づいて１つまたは複数の学習済みモデルオブジェクトを生成することを含む。学習済みモデルオブジェクトは、ＤＴＣパターンと、運転条件と、上記プロセスブロック３１０〜３６０で学習された不具合の確率との間の１つまたは複数の統計的または数学的関係を含み得る。学習済みモデルオブジェクトは、データ構造として、決定木として、または他の適切な形式で格納され得る。学習済みモデルオブジェクトは、例えば電子デバイス１００によって受信され、読み取られ、使用され、かつ方法２００でステップ２４０〜２７０において実装されるのに適しているコンピュータ可読指示としてインスタンス作成され得る。学習済みモデルオブジェクトはまた、１つまたは複数の指示のセットも備え得る。これらは、一定の条件が満たされた場合に車両のオペレータに表示される指示であってもよい。学習済みモデルオブジェクトのプロパティは、ブロック２４０〜２７０を参照して上記により深く論じられる。学習済みモデルオブジェクトが生成されると、方法３００は戻る。

開示は、早期の不良発見を支援するために診断トラブルコード（ＤＴＣ）を検査するシステム及び方法を提供する。例えば、車両またはコンポーネントの不具合は、ＤＴＣのみを用いて、かつ／または、不良条件の早期検出を提供する他の要素なしのＤＴＣを用いて検出され得る。リードタイム（例えば、ＤＴＣの受信／検出と、関連する不良が示される間の時間）は、ＤＴＣ／不良の関連ごとに判定されて、いずれのＤＴＣが、それぞれの関連する不良予測に対して最大のリードタイムを提供するかを判定し得る。精度（例えば、不具合の正確な予測と不具合の偽陽性の予測の比率）もまた、ＤＴＣ／不良の関連ごとに判定されて、いずれのＤＴＣが、最も正確な不良予測を提供するかを判定し得る。上記データを用いて、システムは、ＤＴＣのサブセットを選択して所与の不良をモニタリングし得、かつ／または、潜在的な不良の表示に関してＤＴＣステータスを上記データに基づいて重み付けし得る。ＤＴＣの選択及び／または重み付けの技術的効果は、コンピューティングリソースがセーブされ得（最も正確な／早期の警告ＤＴＣのみの低減されたモニタリングにより）、コンポーネントの不具合が低減され得る（不具合が生じるまたは他のシステムに影響を与える前の不具合の早期検出により）ことである。

上述のようにＤＴＣ分析を用いるために、車内コンピューティングフレームワークは、ＤＴＣを含む信号を受けてもよく、車両の標準的なＤＴＣ通知機構を用いる任意の車両にシステムが組み込まれることを可能にする。ＤＴＣに基づいて、開示されたシステム及び方法は、車両に対する現在のデータ、車両に対する事前記録されたデータ、他の車両に対する事前記録されたデータ（例えば、母集団全体のまたは１つもしくは複数のプロパティを車両と共有する他の車両向けであってもよい傾向）、相手先ブランド名製造（ＯＥＭ）からの情報、リコール情報、及び／または他のデータを用いて、カスタムレポートを生成し得る。いくつかの例では、レポートは、外部サービスに（例えば異なるＯＥＭに）送られ得かつ／またはそれ以外の方法で、ＤＴＣの将来の分析で用いられ得る。ＤＴＣは、車両のコンポーネントの不具合または劣化を予測する１つまたは複数のモデルを構築するために、車両から集約及び分析するための集中型のクラウドサービスに送信され得る。いくつかの例では、車両は、データ（例えばローカルに生成されたＤＴＣ）を処理のためのクラウドサービスに送信し、潜在的な不具合の表示を受信し得る。他の例では、モデルは、車両上にローカルに格納され、ＤＴＣが車両で発行されるとき潜在的な不具合の表示を生成するのに用いられ得る。車両は、いくつかのモデルをローカルに格納し、データを、車両の外部で他の（例えば異なる）モデルを構築／更新するのに用いるためにクラウドサービスに送信し得る。クラウドサービス及び／または他の遠隔デバイスと通信するとき、通信中のデバイス（例えば、車両もしくはクラウドサービス及び／または他の遠隔デバイス）は、データ及び／またはモデルの双方向検証に関与し得る（例えば、データ通信に用いられる通信プロトコルに組み込まれたセキュリティプロトコルを用いて、かつ／または、ＤＴＣベースのモデルと関連するセキュリティプロトコルを用いて）。

開示はまた、車両の不具合の確率を１つまたは複数の診断トラブルコード（ＤＴＣ）に基づいて判定することと；確率が閾値を超えていることに応じて、車両のオペレータに不具合の可能性があることを示すこととを含む方法も提供する。方法の第１の例では、判定することは、追加としてまたは代替として、１つまたは複数のＤＴＣを１つまたは複数の学習済みモデルオブジェクトと比較することに基づき得る。方法の第２の例は、任意選択的に、第１の例を含み、学習済みモデルオブジェクトが履歴ＤＴＣデータに関して行われた機械学習アルゴリズムを用いて生成される方法をさらに含む。方法の第３の例は、任意選択的に、第１の例及び第２の例の１つまたは両方を含み、判定することが、さらに走行距離計の読み取り値及びバッテリ電圧を備える複数の運転条件に基づく方法をさらに含む。方法の第４の例は、任意選択的に、第１から第３の例の１つまたは複数を含み、示すことが、指示を含むテキストメッセージをスクリーンを介して表示することを含む方法をさらに含む。方法の第５の例は、任意選択的に、第１から第４の例の１つまたは複数を含み、指示が、サービスステーションを訪れるまでの推奨される日数を含む方法をさらに含む。第６の例は、任意選択的に、第１から第５の例の１つまたは複数を含み、推奨される日数が確率に基づき、確率が低いときは多い日数が推奨され、確率が高いときは少ない日数が推奨され；日数がさらに、ＤＴＣを生成する車両サブシステムに基づく方法をさらに含む。第７の例は、任意選択的に、第１から第６の例の１つまたは複数を含み、１つまたは複数のＤＴＣが複数のＤＴＣを備え、第１の順序にあるＤＴＣに応じて、確率を第１の値であると判定し、第１の順序と異なる第２の順序にあるＤＴＣに応じて、確率を、第１の値よりも低い第２の値であると判定する方法をさらに含む。

開示はまた、車両と；複数の車両サブシステムと；車両サブシステムから１つまたは複数の診断トラブルコード（ＤＴＣ）を受信し、１つまたは複数のＤＴＣを１つまたは複数の学習済みモデルオブジェクトと比較することによって車両の不具合の確率を生成し、確率が閾値を超えている場合、不具合の可能性があることを車両のオペレータに示す、非一時的なメモリに格納されている、機械可読指示を有するコントローラとを備えるシステムも提供する。システムの第１の例では、閾値は、追加としてまたは代替として、ＤＴＣを生成する車両サブシステムに基づき得る。システムの第２の例は、任意選択的に、第１の例を含み、閾値が、ＤＴＣがパワートレインサブシステムから受信されるとき低く、ＤＴＣがシャーシサブシステムから受信されるとき高いシステムをさらに含む。システムの第３の例は、任意選択的に、第１の例及び第２の例の１つまたは両方を含み、示すことが、メッセージをオペレータに表示することを備え、メッセージは１つまたは複数の指示を含むものであり；指示が、ＤＴＣの学習済みモデルオブジェクトとの比較に基づくシステムをさらに含む。システムの第４の例は、任意選択的に、第１から第３の例の１つまたは複数を含み、指示が、ＤＴＣを生成する車両サブシステムに基づき；空調機の電源を切るという指示が、ＤＴＣがＨＶＡＣシステムによって生成されていることに応じて生成され；エンジン負荷を低減させるという指示が、ＤＴＣがエンジンシステムによって生成されていることに応じて生成されるシステムをさらに含む。システムの第５の例は、任意選択的に、第１から第４の例の１つまたは複数を含み、指示が確率にさらに基づき、指示はサービスステーションを訪れるまでの推奨時間を含むものであり、推奨時間は確率に逆相関するものであるシステムをさらに含む。システムの第６の例は、任意選択的に、第１から第５の例の１つまたは複数を含み、コントローラが、閾値年齢より大きな年齢を有するＤＴＣを無視するように構成され；学習済みモデルオブジェクトが、履歴ＤＴＣデータに関する機械学習アルゴリズムを介して遠隔サーバで生成され；学習済みモデルオブジェクトが、更新リクエストに応じて遠隔サーバから車両で受信されるシステムをさらに含む。

開示はまた、診断トラブルコード（ＤＴＣ）及びエンジン運転パラメータを受信することと；ＤＴＣ及びエンジン運転パラメータを学習済みモデルオブジェクトと比較して車両の不具合の確率及び指示を生成することと；不具合の確率が閾値より大きいことに応じて、指示を車両のオペレータに対してスクリーン上で表示することとを含む方法も提供する。方法の第１の例では、学習済みモデルオブジェクトは、追加としてまたは代替として、ＤＴＣと、エンジン運転パラメータと、不具合の確率との間に１つまたは複数の関係を指定し得る。方法の第２の例は、任意選択的に、第１の例を含み、更新リクエストに応じて遠隔サーバから学習済みモデルオブジェクトを受信することをさらに含む方法をさらに含む。方法の第３の例は、任意選択的に、第１の例及び第２の例の１つまたは両方を含み、学習済みモデルオブジェクトが、１つまたは複数のコンピュータ学習技術を用いて生成され；コンピュータ学習技術が、非系列パターンマイニング、関連ルールマイニング及びベイズの定理を用いたパターンランキングを含む方法をさらに含む。方法の第４の例は、任意選択的に、第１から第３の例の１つまたは複数を含み、コンピュータ学習技術が、車両モデル、走行距離計の読み取り値、バッテリ電圧の読み取り値、ＤＴＣパターン及び不具合状態を備える履歴データに適用される方法をさらに含む。

実施形態の記載が、例示及び説明の目的で提示されてきた。実施形態への適切な変更及び変形は、上記説明を鑑みて行われ得、または、方法の実施により取得され得る。例えば、特に記載がない限り、記載された方法の１つまたは複数は、図１を参照して記載された電子デバイス１００などの適切なデバイス及び／またはデバイスの組み合わせによって行われ得る。方法は、ストレージデバイス、メモリ、ハードウェアネットワークインタフェース／アンテナ、スイッチ、アクチュエータ、クロック回路などといった１つまたは複数の追加のハードウェア要素と組み合わせて１つまたは複数の論理デバイス（例えばプロセッサ）で、格納された指示を実行することによって行われ得る。記載された方法及び関連するアクションはまた、この出願に記載された順序に加えて様々な順序で、並行してかつ／または同時に行われ得る。記載されたシステムは、本質的に例示的なものであり、追加の要素を含み得るかつ／または要素を省略し得る。本開示の主題は、開示された様々なシステム及び構成、ならびに他の特徴、機能、及び／または性質の全ての新規のかつ非自明の組み合わせ及びサブ組み合わせを含む。

この明細書で用いられる単数形でかつ単語「ａ」または「ａｎ」を前に付けて記載された要素またはステップは、排除が記載されない限り、複数形の当該要素またはステップを除外しないとして理解されるべきである。さらに、本開示の「一実施形態」または「一例」への言及は、記載された特徴をやはり含むさらなる実施形態の存在を除外するとして解釈されることを意図しない。「第１の」、「第２の」及び「第３の」などの用語は、単なるラベルとして用いられており、関連する対象に数的な要件または特定の位置順序を課すことを意図するものではない。以下の特許請求の範囲は、特に、新規かつ非自明とされている上記開示から主題を指摘する。

Claims (20)

1. 車両の不具合の確率を１つまたは複数の診断トラブルコード（ＤＴＣ）に基づいて判定することと；
   前記確率が閾値を超えていることに応じて不具合の可能性があることを前記車両のオペレータに示すこととを含む方法。
2. 前記判定することが、前記１つまたは複数のＤＴＣと１つまたは複数の学習済みモデルオブジェクトの比較に基づく、請求項１に記載の方法。
3. 前記学習済みモデルオブジェクトが、履歴ＤＴＣデータに関して行われた機械学習アルゴリズムを用いて生成される、請求項２に記載の方法。
4. 前記判定することが、さらに、走行距離計の読み取り値及びバッテリ電圧を備える複数の運転条件に基づく、請求項２に記載の方法。
5. 前記示すことが、スクリーンを介してテキストメッセージを表示することを含み、前記テキストメッセージは指示を含む、請求項１に記載の方法。
6. 前記指示が、サービスステーションを訪れるまでの推奨される日数を含む、請求項５に記載の方法。
7. 前記推奨される日数が前記確率に基づき、低い確率に対して多い日数が推奨され、高い確率に対して少ない日数が推奨され；前記日数が、さらに、前記ＤＴＣを生成する車両サブシステムに基づく、請求項６に記載の方法。
8. 前記１つまたは複数のＤＴＣが、複数のＤＴＣを備え、
   第１の順序の前記ＤＴＣに応じて、
   前記確率を第１の値として判定し、
   前記第１の順序とは異なる第２の順序の前記ＤＴＣに応じて、
   前記確率を、前記第１の値より低い第２の値として判定する、請求項１に記載の方法。
9. 車両と；
   複数の車両サブシステムと；
   前記車両サブシステムから１つまたは複数の診断トラブルコード（ＤＴＣ）を受信し、
   前記１つまたは複数のＤＴＣを１つまたは複数の学習済みモデルオブジェクトと比較することによって、前記車両の不具合の確率を生成し、
   前記確率が閾値を超えている場合、不具合の可能性があることを前記車両のオペレータに示す、非一時的なメモリに格納されている、機械可読指示を有するコントローラとを備えるシステム。
10. 前記閾値が、前記ＤＴＣを生成する前記車両サブシステムに基づく、請求項９に記載のシステム。
11. 前記閾値が、前記ＤＴＣがパワートレインサブシステムから受信されると低く、前記ＤＣＴがシャーシサブシステムから受信されると高い、請求項１０に記載のシステム。
12. 前記示すことが、メッセージを前記オペレータに表示することを備え、前記メッセージは、１つまたは複数の指示を含み；前記指示が、前記ＤＴＣの前記学習済みモデルオブジェクトとの前記比較に基づく、請求項９に記載のシステム。
13. 前記指示が、前記ＤＴＣを生成する車両サブシステムに基づき；空調機の電源を切るという指示は、前記ＤＴＣがＨＶＡＣシステムによって生成されていることに応じて生成され；エンジン負荷を低減するという指示は、前記ＤＴＣがエンジンシステムによって生成されていることに応じて生成される、請求項１２に記載のシステム。
14. 前記指示が、さらに、前記確率に基づき、前記指示はサービスステーションを訪れるまでの推奨される時間を含み、前記推奨される時間は前記確率と逆相関する、請求項１２に記載のシステム。
15. 前記コントローラが、閾値年齢より大きい年齢を有するＤＴＣを無視するように構成され；前記学習済みモデルオブジェクトが、履歴ＤＴＣデータに関する機械学習アルゴリズムを介して遠隔サーバで生成され；前記学習済みモデルオブジェクトが、更新リクエストに応じて前記遠隔サーバから前記車両で受信される、請求項９に記載のシステム。
16. 診断トラブルコード（ＤＴＣ）及びエンジン運転パラメータを受信することと；
    前記ＤＴＣ及びエンジン運転パラメータを、学習済みモデルオブジェクトと比較して車両の不具合の確率及び指示を生成することと；
    不具合の前記確率が閾値より大きいことに応じて、前記指示を前記車両のオペレータに対してスクリーン上で表示することとを含む方法。
17. 前記学習済みモデルオブジェクトが、ＤＴＣと、エンジン運転パラメータと、不具合の前記確率との間の１つまたは複数の関係を指定する、請求項１６に記載の方法。
18. 更新リクエストに応じて遠隔サーバから前記学習済みモデルオブジェクトを受信することをさらに含む、請求項１６に記載の方法。
19. 前記学習済みモデルオブジェクトが、１つまたは複数のコンピュータ学習技術を用いて生成され；前記コンピュータ学習技術は、非系列パターンマイニング、相関ルールマイニング及びベイズの定理を用いたパターンランキングを含む、請求項１６に記載の方法。
20. 前記コンピュータ学習技術が、車両モデル、走行距離計の読み取り値、バッテリ電圧の読み取り値、ＤＴＣパターン及び不具合状態を備える履歴データに適用される、請求項１９に記載の方法。