知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2025-02-06
(45)【発行日】2025-02-17
(54)【発明の名称】車両用の分散診断アーキテクチャ
(51)【国際特許分類】
G01M 17/007 20060101AFI20250207BHJP
B60R 16/02 20060101ALI20250207BHJP
【ＦＩ】
G01M17/007 J
B60R16/02 650J
【請求項の数】
15
(21)【出願番号】P 2022513400
(86)(22)【出願日】2020-08-27
(65)【公表番号】
(43)【公表日】2022-11-02
(86)【国際出願番号】 EP2020073949
(87)【国際公開番号】W WO2021037965
(87)【国際公開日】2021-03-04
【審査請求日】2023-07-26
(31)【優先権主張番号】1912488.2
(32)【優先日】2019-08-30
(33)【優先権主張国・地域又は機関】GB
(31)【優先権主張番号】1912568.1
(32)【優先日】2019-09-02
(33)【優先権主張国・地域又は機関】GB
(73)【特許権者】
【識別番号】513208973
【氏名又は名称】ジャガー・ランド・ローバー・リミテッド
【氏名又は名称原語表記】ＪＡＧＵＡＲ ＬＡＮＤ ＲＯＶＥＲ ＬＩＭＩＴＥＤ
【住所又は居所原語表記】Ａｂｂｅｙ Ｒｏａｄ，Ｗｈｉｔｌｅｙ，Ｃｏｖｅｎｔｒｙ，Ｗａｒｗｉｃｋｓｈｉｒｅ ＣＶ３ ４ＬＦ ＧＢ
(74)【代理人】
【識別番号】110000523
【氏名又は名称】アクシス国際弁理士法人
(72)【発明者】
【氏名】ディブイェンドゥ・パライ
(72)【発明者】
【氏名】サチン・シンデ
【審査官】鴨志田 健太
(56)【参考文献】
【文献】特開２００５－２６５４５４（ＪＰ，Ａ）
【文献】特開２００４－２１７０１６（ＪＰ，Ａ）
【文献】特表２００３－５０９２５８（ＪＰ，Ａ）
【文献】特開２００５－０４８７７０（ＪＰ，Ａ）
【文献】米国特許出願公開第２００９／０２９５５５９（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１９／００６６３９９（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０１Ｍ １７／００７
Ｂ６０Ｒ １６／０２
(57)【特許請求の範囲】
【請求項1】
車両用の分散診断アーキテクチャであって、前記診断アーキテクチャは、車両の中央計算プラットフォーム（ＣＣＰ）でホストされる複数のアプリケーション機能と、
車両内の異なる場所に設置された複数のリモート入力／出力コンセントレータモジュール（ＲＩＯ）と、
車両診断マネージャー（ＶＤＭ）と
を含み、
各アプリケーション機能は、
前記車両の関連する機能を制御し、
前記関連する車両機能の故障として、戦略的故障に関する診断故障モニターを実行し、及び
合格／不合格データ、又は診断トラブルコード（ＤＴＣ）として、前記戦略的故障モニターの出力を前記ＶＤＭに定期的に送信する
ように構成され、
各ＲＩＯは、前記車両の１つ以上の関連するＩ／Ｏデバイスに接続され、かつ、
前記関連するＩ／Ｏデバイスの故障として、物理的故障に関する診断故障モニターを実行し、
合格／不合格データ、又は診断トラブルコード（ＤＴＣ）として、前記物理的故障モニターの出力を前記ＶＤＭに定期的に送信する
ように構成され、
前記ＶＤＭは、
受信した故障モニターの出力データを集約し、
受信した故障モニターの出力データに応じて、戦略的及び物理的故障を識別し、
戦略的及び物理的故障の中央故障記録を維持する
ように構成され、
前記ＶＤＭはさらに、検出された故障を、直接の修復アクションを必要とする原因故障、又は原因故障の結果として、直接の修復アクションを必要としない可能性のある結果故障のいずれかとして分類するために、検出された戦略的及び物理的故障をトリアージするように構成される、
分散診断アーキテクチャ。
【請求項2】
前記ＶＤＭは、受信した故障モニターの出力データに応じて、検出された戦略的及び物理的故障の診断トラブルコード（ＤＴＣ）を生成し、生成されたＤＴＣを前記中央故障記録に保存するように構成される、請求項１に記載の分散診断アーキテクチャ。
【請求項3】
検出された故障の前記トリアージは、検出された故障を原因故障又は結果故障のいずれかとして分類するために、前記アプリケーション機能及びＲＩＯから受信した故障モニターの出力データをトリアージすることを含む、請求項１に記載の分散診断アーキテクチャ。
【請求項4】
前記中央故障記録は、前記ＶＤＭに関連する中央故障メモリシステムで維持され、前記中央故障メモリシステムは、一次故障メモリとユーザー定義の二次故障メモリで構成され、前記ＶＤＭは、原因故障の記録を前記一次故障メモリに保存し、結果故障の記録を前記ユーザー定義の二次故障メモリに保存するように構成される、請求項１又は３に記載の分散診断アーキテクチャ。
【請求項5】
前記ＲＩＯ及びアプリケーション機能は、物理的及び戦略的故障を検出し、物理的又は戦略的故障の検出時に適切な故障反応を決定し、決定された前記故障反応を開始するように構成される、請求項１～４のいずれか１項に記載の分散診断アーキテクチャ。
【請求項6】
前記ＶＤＭは、前記ＲＩＯとのキープアライブインターフェイスを維持するように構成され、前記ＲＩＯは、前記キープアライブインターフェイスの中断を検出すると、物理的故障のローカル故障記録の維持を開始するように構成される、請求項１～５のいずれか１項に記載の分散診断アーキテクチャ。
【請求項7】
請求項１～６のいずれか１項に記載の分散診断アーキテクチャを含む車両。
【請求項8】
車両用の分散診断アーキテクチャであって、前記診断アーキテクチャは、車両の中央計算プラットフォーム（ＣＣＰ）でホストされる複数のアプリケーション機能と、
車両内の異なる場所に設置された複数のリモート入力／出力コンセントレータモジュール（ＲＩＯ）と、
車両診断マネージャー（ＶＤＭ）と
を含み、
各アプリケーション機能は、
前記車両の関連する機能を制御し、
診断故障モニターを実行し、前記関連する車両機能の故障として、戦略的故障を検出し、
検出された戦略的故障を前記ＶＤＭに報告する
ように構成され、
各ＲＩＯは、前記車両の１つ以上の関連するＩ／Ｏデバイスに接続され、かつ、
診断故障モニターを実行し、前記関連するＩ／Ｏデバイスの故障として、物理的故障を検出し、
検出された物理的故障を前記ＶＤＭに報告する
ように構成され、
前記ＶＤＭは、
受信した戦略的及び物理的故障の通知を集約し、
前記戦略的及び物理的故障の中央故障記録を維持する
ように構成され、
前記ＶＤＭはさらに、検出された故障を、直接の修復アクションを必要とする原因故障、又は原因故障の結果として、直接の修復アクションを必要としない可能性のある結果故障のいずれかとして分類するために、検出された戦略的及び物理的故障をトリアージするように構成される、
分散診断アーキテクチャ。
【請求項9】
前記アプリケーション機能及びＲＩＯは、検出された戦略的及び物理的故障の診断トラブルコード（ＤＴＣ）を生成し、生成されたＤＴＣを前記ＶＤＭに送信して、前記中央故障記録に保存するように構成される、請求項８に記載の分散診断アーキテクチャ。
【請求項10】
前記アプリケーション機能及びＲＩＯは、イベント駆動型通信インターフェイスを使用して、検出された故障を前記ＶＤＭに報告するように構成される、請求項８又は９に記載の分散診断アーキテクチャ。
【請求項11】
前記ＲＩＯは、物理的故障の故障記録を維持するように構成され、前記アプリケーション機能は、戦略的故障の故障記録を維持するように構成される、請求項８～１０のいずれか１項に記載の分散診断アーキテクチャ。
【請求項12】
前記物理的故障記録は前記ＲＩＯのユーザー定義の二次故障メモリに維持され、前記戦略的故障記録は前記アプリケーション機能に関連するユーザー定義の二次故障メモリに維持される、請求項１１に記載の分散診断アーキテクチャ。
【請求項13】
前記中央故障記録は、前記ＶＤＭに関連する中央故障メモリシステムで維持され、前記中央故障メモリシステムは、一次故障メモリとユーザー定義の二次故障メモリで構成され、前記ＶＤＭは、原因故障の記録を前記一次故障メモリに保存し、結果故障の記録を前記ユーザー定義の二次故障メモリに保存するように構成される、請求項８に記載の分散診断アーキテクチャ。
【請求項14】
前記ＲＩＯ及びアプリケーション機能は、物理的又は戦略的故障の検出時に適切な故障反応を決定し、決定された前記故障反応を開始するように構成される、請求項８～１３のいずれか１項に記載の分散診断アーキテクチャ。
【請求項15】
請求項８～１４のいずれか１項に記載の分散診断アーキテクチャを含む車両。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、車両用の分散型診断システム、特に、限定的ではないが、自動車などの車両用の分散型診断システムに関する。本発明の側面は、診断アーキテクチャ、及び診断アーキテクチャを含む車両に関する。
【背景技術】
【0002】
自動車などの最新の車両には、通常、車両の様々な機能を制御するための多数のアプリケーション機能が含まれている。例えば、車両のボディドメイン内で、車両のシートの動作を制御するためにシートアプリケーション機能が提供され得、車両のドアの動作を制御するためにドアアプリケーション機能が提供され得る。
【0003】
従来の電子アーキテクチャでは、車両の様々なアプリケーション機能は、車両全体に分散された多数の個別の電子制御ユニット（ｅｌｅｃｔｒｏｎｉｃ ｃｏｎｔｒｏｌ ｕｎｉｔ、ＥＣＵ）でホストされ、これらは車両全体に分散されており、各ＥＣＵは、特定のアプリケーション機能に関連する入力／出力（Ｉ／Ｏ）デバイスのドライバーもホストしている。例えば、ボディドメインの例を続けると、車両には、左前、右前、左後、右後のシートＥＣＵ（それぞれが、車両のシートのそれぞれのシートアプリケーション機能とＩ／Ｏドライバーをホストする）と、左前、右前、左後、右後のドアＥＣＵ（それぞれが、車両のドアのそれぞれのドアアプリケーション機能とＩ／Ｏドライバーをホストする）が含まれ得る。
【0004】
この従来の電気アーキテクチャを使用すると、車両全体に分散されたＥＣＵがアプリケーション機能と、それらのアプリケーション機能に関連するセンサーやアクチュエーターなどのＩ／Ｏデバイスのドライバーの両方をホストするため、故障の特定、トリアージ、及び記録が比較的簡単になる。したがって、ＥＣＵは、物理的又はコンポーネントレベルの故障（Ｉ／Ｏデバイス及び車両の通信チャネルに関連する故障）及び戦略的又はシステムレベルの故障（車両のアプリケーション機能の可用性、パフォーマンス、又は正常性に関連するより高いレベルの故障）の両方に関連する診断テスト又は故障モニターを実行できる。次に、この故障データを使用して、物理的及び戦略的故障を検出でき、これは、検出された故障を原因故障（すなわち、直接の修復アクションを必要とする根本原因の故障）又は結果の故障（すなわち、根本原因の故障の結果として引き起こされ又は検出され、直接の修復アクションを必要としない可能性のある故障）のいずれかとして分類するためにトリアージできる。
【0005】
上記の電気的アーキテクチャにより、車両には多数の個別のＥＣＵと、複雑なワイヤリングハーネスが必要になる。ＥＣＵの数と車両のワイヤーハーネスの複雑さを軽減するために、車両のアプリケーション機能の少なくともいくつかを専用のＥＣＵから、例えば、車両の様々なサブシステムの様々な異なる機能を制御できる中央機能ホスティングシステム又は中央計算プラットフォームに移動することが望ましい場合がある。車両のアプリケーション機能を専用のＥＣＵから遠ざけることは、機能分割と呼ばれる。この場合、Ｉ／Ｏデバイスのドライバーは引き続き車両全体に分散されている可能性がある。例えば、Ｉ／Ｏドライバーは、複数のリモート入力／出力コンセントレータモジュール又はＲＩＯでホストされ得、それぞれが、複数の異なるサブシステムのＩ／Ｏデバイスのドライバーをホストし、通信を容易にし得る。
【発明の概要】
【発明が解決しようとする課題】
【0006】
ただし、アプリケーション機能を、それらのアプリケーション機能に関連するＩ／ＯデバイスのドライバーがホストされているＥＣＵから移動すると、故障の特定、トリアージ、及び記録に課題が生じる。特に、アプリケーション機能はＩ／Ｏドライバーが配置されているハードウェアから分離されているため、原因と結果の故障を特定するために、アプリケーション機能もＲＩＯも、検出された故障を効果的にトリアージするために必要なすべての物理的及び戦略的故障データにアクセスできない。
【0007】
本発明は、上記の問題の少なくともいくつかを軽減又は克服するために考案された。
【課題を解決するための手段】
【0008】
本発明の一側面によれば、車両用の分散診断アーキテクチャが提供され、前記診断アーキテクチャは、車両の中央計算プラットフォーム（ｃｅｎｔｒａｌ ｃｏｍｐｕｔｅ ｐｌａｔｆｏｒｍ、ＣＣＰ）でホストされる複数のアプリケーション機能と、車両内の異なる場所に設置された複数のリモート入力／出力コンセントレータモジュール（ｒｅｍｏｔｅ ｉｎｐｕｔ／ｏｕｔｐｕｔ ｃｏｎｃｅｎｔｒａｔｏｒ ｍｏｄｕｌｅ、ＲＩＯ）と、車両診断マネージャー（ｖｅｈｉｃｌｅ ｄｉａｇｎｏｓｔｉｃｓ ｍａｎａｇｅｒ、ＶＤＭ）にホストされた、各アプリケーション機能は、前記車両の関連する機能を制御し、前記関連する車両機能の戦略的又はシステムレベルの故障に関する診断故障モニターを実行し、及び前記戦略的故障モニターの出力を前記ＶＤＭに定期的に送信するように構成され、各ＲＩＯは、前記車両の１つ以上の関連するＩ／Ｏデバイスに接続され、かつ、前記関連するＩ／Ｏデバイスの物理的又はコンポーネントレベルの故障に関する診断故障モニターを実行し、前記物理的故障モニターの出力を前記ＶＤＭに定期的に送信するように構成され、前記ＶＤＭは、受信した故障モニターの出力データを集約し、受信した故障モニターの出力データに応じて、戦略的及び物理的故障を検出し、戦略的及び物理的故障の中央故障記録を維持するように構成される。
【0009】
ＣＣＰは、様々な異なる車両サブシステムの動作を制御するためのソフトウェアアプリケーション又はアプリケーション機能をホストするために使用される、少なくとも１つのプロセッサモジュールと少なくとも１つのメモリモジュールで構成される中央コンピューティングシステムであると理解される。ＶＤＭ及び中央故障記録は、アプリケーション機能とともにＣＣＰでホストされる場合もある。ＲＩＯは、ＣＣＰでホストされるアプリケーション機能に関連するＩ／Ｏデバイスを含む、１つ又は複数の車両サブシステムのＩ／Ｏデバイスとの通信を容易にするように接続及び構成される制御モジュールであることも理解される。
【0010】
戦略的及び物理的故障モニターの出力は、例えば特定の故障状態が検出されたかどうかを示す合格／不合格データの形式の生の故障モニター出力データであり、これは、その後戦略的及び物理的故障モニターの出力に応じて生成され得る確認済みの診断トラブルコード（ＤＴＣ）とは対照的であることも理解される。
【0011】
戦略的及び物理的故障モニターの出力がアプリケーション機能及びＲＩＯからＶＤＭに送信される期間は、個々の故障モニターの周期性に基づくことができる。例えば、合格／不合格データは、生成時に、あるいは所定の数の故障監視サイクルの後に、アプリケーション機能及びＲＩＯからＶＤＭに送信され得る。
【0012】
車両の機能を制御し、戦略的故障データを生成するアプリケーション機能が、車両のＩ／Ｏデバイスとのインターフェイスを提供して物理的故障データを生成するＲＩＯから分離されるため、診断アーキテクチャが分散される。ただし、アプリケーション機能から戦略的故障データを受信し、ＲＩＯから物理的故障データを受信するようにＶＤＭを構成することにより、本発明の診断アーキテクチャは、ＶＤＭが物理的及び戦略的故障を検出及びトリアージするために必要なすべての故障データを集約し、車両全体の故障の記録を維持することを可能とする。
【0013】
さらに、戦略的及び物理的故障に関連するすべての合格／不合格データをＶＤＭに送信することにより、ＶＤＭで使用可能な故障データのレベルを最大化できる。したがって、ＶＤＭは、コンポーネントと車両機能の劣化した状態を検出し、特定の故障に対してＤＴＣが生成される前にその故障の発生を予測することもできる。ＶＤＭは、特定の原因の故障に関連するすべての故障に対してＤＴＣが生成される前に、故障のトリアージ、分類、及び記録を行うこともできる。
【0014】
このようにして、本発明の診断アーキテクチャは、少なくともいくつかのアプリケーション機能が中央計算プラットフォームでホストされる、車両の故障の効率的な検出及び記録を可能にする。
【0015】
ＶＤＭは、受信した故障モニターの出力データに応じて、検出された戦略的及び物理的故障のＤＴＣを生成し、生成されたＤＴＣを中央の故障記録に保存するように構成できる。ＶＤＭで確認済みＤＴＣを生成することにより、アプリケーション機能とＲＩＯから確認済みＤＴＣを生成するために必要な故障認定ロジックを省略でき、アプリケーション機能とＲＩＯの複雑さを軽減できる。
【0016】
ＶＤＭは、検出された故障を原因故障又は結果故障のいずれかとして分類するために、検出された戦略的及び物理的故障をトリアージするように構成できる。検出された故障を原因故障又は結果故障のいずれかとして識別することにより、独自の個別の修復アクションを必要としない結果故障の不必要な報告を回避することが可能であり、それにより、複数の故障の検出後の根本原因と適切な修復アクションを特定するプロセスが簡素化される。
【0017】
検出された故障のトリアージは、検出された故障を原因故障又は結果故障のいずれかとして分類するために、アプリケーション機能及びＲＩＯから受信した故障モニター出力データをトリアージすることを含み得る。受信した故障モニターの出力データに基づいて検出された故障をトリアージすることにより、特定の原因故障に関連するすべての故障に対してＤＴＣが生成される前に、ＶＤＭが故障をトリアージし、原因故障を特定することができる。さらに、アプリケーション機能及びＲＩＯから受信した故障モニターの出力データには、その後に生成されるＤＴＣよりも多くの情報が含まれているため、生の故障モニター出力データに基づく故障のトリアージにより、ＤＴＣのみに基づく場合よりも詳細で正確な故障のトリアージが可能になる。
【0018】
中央故障記録は、ＶＤＭに関連付けられた中央故障メモリシステムで維持できる。中央故障メモリシステムは、一次故障メモリ及びユーザー定義の二次故障メモリを含み得る。ＶＤＭは、原因故障の記録を一次故障メモリに保存し、結果故障の記録をユーザー定義の二次故障メモリに保存するように構成できる。一次故障メモリは、標準の診断プロトコルインターフェイス（例えば、ＩＳＯ（国際標準化機構）によって定義されたＵｎｉｆｉｅｄ Ｄｉａｇｎｏｓｔｉｃｓ Ｓｅｒｖｉｃｅｓ（ＵＤＳ）プロトコルインターフェイス）を使用して車両の診断システムに接続されている診断クライアント（例えば、オンボード又はオフボードテスター）がアクセスするように構成されるデジタルストレージであると理解される。対照的に、ユーザー定義の二次故障メモリは、メーカーが承認した診断クライアントのみがアクセスできるように、又は車両のメーカーが定義した特定の要求を受信したときにのみアクセスできるように構成されたデジタルストレージである。
【0019】
原因故障の記録を一次故障メモリに保存し、結果故障の記録をユーザー定義の二次故障メモリに保存することにより、検出されたすべての故障の完全な記録が維持される（及び車両のメーカーがアクセスできる）。一方、標準のＵＤＳプロトコルインターフェイスを使用して診断クライアントから診断データが要求された場合にのみ、原因故障が報告されることが保証される。
【0020】
中央故障メモリシステムは、アプリケーション機能及びＶＤＭとともにＣＣＰでホストすることもできる。
【0021】
ＲＩＯ及びアプリケーション機能は、物理的及び戦略的故障を検出し、物理的又は戦略的故障の検出時に適切な故障反応を決定し、決定された故障反応を開始するように構成できる。このようにして、ＲＩＯ及びアプリケーション機能は、検出された物理的及び戦略的故障に応じて、ＶＤＭとは無関係に、それらの故障に関連して確認済みＤＴＣが生成されるのを待たずに、適切な故障反応を開始できる。
【0022】
この場合、ＲＩＯ及びアプリケーション機能には、物理的及び戦略的故障を識別し、適切な故障反応を決定するための故障検出ロジックが提供され得る。ただし、ＶＤＭには確認済みＤＴＣを生成するために必要な故障認定ロジックが含まれており、戦略的及び物理的故障の中央故障記録を維持するように構成されるため、個々のＲＩＯ及びアプリケーション機能に、確認済みＤＴＣを生成するために必要なＤＴＣ認定ロジックを提供する必要はない。
【0023】
ＶＤＭは、ＲＩＯとのキープアライブインターフェイス（ｋｅｅｐ ａｌｉｖｅ ｉｎｔｅｒｆａｃｅ）を維持するように構成でき、ＲＩＯは、キープアライブインターフェイスの中断を検出すると、物理的故障のローカル故障記録の維持を開始するように構成できる。物理的故障データは通常、ＶＤＭによって維持される中央故障記録に記録されるため、キープアライブインターフェイスが有効に受信されている限り、ＲＩＯは物理的故障のローカル故障記録を維持しなくてもよい。ただし、キープアライブインターフェイスの中断に応答して、物理的故障のローカル故障記録の維持を開始することによって、例えば車両のワイヤーハーネスの故障が原因で、ＲＩＯとＶＤＭの間の通信が中断された場合でも、物理的故障の記録が維持されることが保証され得る。
【0024】
ローカル故障記録は、一次故障メモリではなく、個々のＲＩＯのユーザー定義の二次故障メモリに保持されることが好ましい。ＲＩＯには確認済みＤＴＣを生成するために必要なＤＴＣ認定ロジックがないため、ローカル故障記録には物理的故障モニターの出力が含まれ得る。
【0025】
本発明の別の側面によれば、車両用の分散診断アーキテクチャが提供され、前記診断アーキテクチャは、車両の中央計算プラットフォーム（ＣＣＰ）でホストされる複数のアプリケーション機能と、車両内の異なる場所に設置された複数のリモート入力／出力コンセントレータモジュール（ＲＩＯ）と、車両診断マネージャー（ＶＤＭ）にホストされた、各アプリケーション機能は、前記車両の関連する機能を制御し、診断故障モニターを実行し、前記関連する車両機能の戦略的又はシステムレベルの故障を検出し、検出された戦略的故障を前記ＶＤＭに報告するように構成され、各ＲＩＯは、前記車両の１つ以上の関連するＩ／Ｏデバイスに接続され、かつ、診断故障モニターを実行し、前記関連するＩ／Ｏデバイスの物理的又はコンポーネントレベルの故障を検出し、検出された物理的故障を前記ＶＤＭに報告するように構成され、前記ＶＤＭは、受信した戦略的及び物理的故障の通知を集約し、前記戦略的及び物理的故障の中央故障記録を維持するように構成される。
【0026】
ＶＤＭ及び中央故障記録は、アプリケーション機能とともにＣＣＰでホストされ得る。
【0027】
アプリケーション機能及びＲＩＯから検出された戦略的及び物理的故障の故障通知を受信するようにＶＤＭを構成することにより、本発明の診断アーキテクチャは、ＶＤＭが物理的及び戦略的故障をトリアージするために必要なすべての故障データを集約し、車両全体の故障の記録を維持することを可能とする。さらに、確認された故障の通知をアプリケーション機能とＲＩＯからＶＤＭに転送のみすることにより、車両の通信ネットワークを介した信号トラフィックを最小限に抑えることができる。このようにして、本発明の診断アーキテクチャは、少なくともいくつかのアプリケーション機能が中央計算プラットフォームでホストされる車両における故障の効率的な検出及び記録を可能にする。
【0028】
アプリケーション機能及びＲＩＯは、検出された戦略的及び物理的故障のＤＴＣを生成し、生成されたＤＴＣをＶＤＭに送信して、中央の故障記録に保存するように構成できる。アプリケーション機能とＲＩＯでＤＴＣを生成し、生成されたＤＴＣをＶＤＭに報告することにより、ＶＤＭは、個々の故障モニターの出力情報（これに基づいてＤＴＣが生成される）にアクセスする必要がないため、アプリケーション機能及びＲＩＯとＶＤＭとの間で必要な通信量を減らすことができる。
【0029】
アプリケーション機能及びＲＩＯは、イベント駆動型通信インターフェイスを使用して、検出された故障をＶＤＭに報告するように構成できる。故障は、確認時に、例えばＤＴＣステータスバイトの変更に応じて、ＶＤＭに報告され得る。
【0030】
ＲＩＯは、物理的故障の故障記録を維持するように構成でき、アプリケーション機能は、戦略的故障の故障記録を維持するように構成できる。誤解を避けるために、ＲＩＯは、ＶＤＭとの通信の中断に応答するだけでなく、物理的故障記録を継続的に維持できることが理解される。ＲＩＯ及びアプリケーション機能によって維持される物理的及び戦略的故障記録には、ＤＴＣ及び／又はＲＩＯ及びアプリケーション機能によって実行される個々の故障モニターからの故障モニター出力情報（例えば、合格／不合格情報）が含まれ得る。
【0031】
物理的故障の記録は、ＲＩＯのユーザー定義の二次故障メモリに保持され得、戦略的故障の記録は、アプリケーション機能に関連するユーザー定義の二次故障メモリに保持され得る。ＲＩＯ及びアプリケーションに関連するユーザー定義の二次故障メモリに物理的及び戦略的故障の記録を保存することは、遡及的な故障分析を容易にすることができる。
【0032】
ＶＤＭは、検出された故障を原因故障又は結果故障のいずれかとして分類するために、検出された戦略的及び物理的故障をトリアージするように構成できる。戦略的及び物理的故障のＤＴＣは、アプリケーション機能とＲＩＯによって生成され、ＶＤＭに送信されるため、検出された故障のトリアージには、アプリケーション機能及びＲＩＯから受信したＤＴＣのトリアージが含まれ得、この場合、ＶＤＭは、アプリケーション機能及びＲＩＯによって実行される故障モニターの生の出力へのアクセスを必要としない場合がある。
【0033】
中央故障記録は、ＶＤＭに関連する中央故障メモリシステムで維持できる。中央故障メモリシステムは、一次故障メモリ及びユーザー定義の二次故障メモリを含み得る。ＶＤＭは、原因故障の記録を一次故障メモリに保存し、結果故障の記録をユーザー定義の二次故障メモリに保存するように構成できる。
【0034】
ＲＩＯ及びアプリケーション機能は、物理的又は戦略的故障の検出時に適切な故障反応を決定し、決定された故障反応を開始するように構成できる。
【0035】
本発明のさらなる側面によれば、車両用の分散診断アーキテクチャが提供される。この診断アーキテクチャは、それぞれが車両機能を制御するように構成された複数のアプリケーション機能を含む。アプリケーション機能の少なくともいくつかは、車両の中央計算プラットフォーム（ＣＣＰ）でホストされ得る。代わりに、又は追加的に、少なくともいくつかのアプリケーション機能は、１つ又は複数のリモート入力／出力コンセントレータモジュール（ＲＩＯ）又は電子制御ユニット（ＥＣＵ）でホストされ得る。アプリケーション機能のＩ／Ｏドライバーは、ＲＩＯ又はＥＣＵでホストされ得る。
【0036】
アプリケーション機能は、関連する車両機能の戦略的又はシステムレベルの故障に関連する診断故障モニターを実行し、関連する車両機能に関連する戦略的故障データを車両診断マネージャー（ＶＤＭ）に送信するように構成できる。戦略的故障データは、合格／不合格データ、あるいは確認済みの診断トラブルコード（ＤＴＣ）の形式で送信され得る。戦略的故障データは、生成時、又はイベントドライバインターフェイスを使用して、継続的に送信され得る。
【0037】
ＲＩＯ又はＥＣＵは、関連するＩ／Ｏデバイスの物理レベル又はコンポーネントレベルの故障に関する診断故障モニターを実行し、関連するＩ／Ｏデバイスに関連する物理的故障データをＶＤＭに送信するように構成できる。物理的故障データは、合格／不合格データ、あるいは確認済みＤＴＣの形式で送信され得る。物理的故障データは、生成時、又はイベントドライバインターフェイスを使用して、継続的に送信され得る。
【0038】
ＶＤＭは、受信した戦略的及び物理的故障データを集約し、戦略的及び物理的故障の中央故障記録を維持するように構成できる。特に、ＶＤＭは、検出された故障をトリアージし、原因故障の記録と結果故障の記録を管理するように構成できる。
【0039】
本出願の範囲内において、前の段落、特許請求の範囲、及び／又は以下の説明及び図面に記載されている様々な側面、実施形態、例及び代替案、特にその個々の特徴は、独立して、又は任意の組み合わせで適用できることが明確に意図される。すなわち、任意の実施形態のすべての実施形態及び／又は特徴は、そのような特徴に互換性がない場合を除いて、任意の方法及び／又は組み合わせで組み合わせることができる。出願人は、最初に提出された請求項を変更し、又はそれに応じて新しい請求を提出する権利（当初の請求項になかったとしても、他の請求項に従属する、及び／又は他の請求項の特徴を組み込むために当初の請求項を補正する権利を含む）を留保する。
【0040】
ここで、本発明の１つ又は複数の実施形態を、例としてのみ、添付の図面を参照して説明する。
【図面の簡単な説明】
【0041】
【発明を実施するための形態】
【0042】
図１は、本発明の１つの可能な実施形態による分散型診断システム２を含む道路車両１を概略的に示す。現代の道路車両において一般的であるように、図１に示されている車両１は、様々な異なる車両機能を実装するように構成された多数のサブシステム３で構成されており、その一部を図２に示す。車両のサブシステム３は、例えば、（図２に示されていない他の多くのサブシステムの中でも）左前部シート３ａ、右前部シート３ｂ、左後部シート３ｃ、右後部シート３ｄ、左前部ドア３ｅ、右前部ドア３ｆ、左後部ドア３ｇ、右後部ドア３ｈ、フロントガラスワイパーシステム３ｉ、照明システム３ｊ、及び警報システム３ｋを含む。
【0043】
各サブシステム３は、車両機能を実装するために必要とされるセンサー及びアクチュエーターなどの様々なＩ／Ｏデバイス５を含み、それらのいくつかは、図３に示されている。例えば、各シートサブシステム３ａ、３ｂ、３ｃ、３ｄは、（図３に示されていない他のセンサー及びアクチュエーターの中でも）シートの高さを調整するように構成された高さ制御モーター５ａ、シートの高さを監視するように構成された高さ位置センサー５ｂ、ヘッドレストの位置を調整するように構成されたヘッドレスト制御モーター５ｃ、及びヘッドレストの位置を監視するように構成されるヘッドレスト位置センサー５ｄを含む。さらに、各ドアサブシステム３ｅ、３ｆ、３ｇ、３ｈは、（図３に示されていない他のセンサー及びアクチュエーターの中でも）窓制御モーター５ｅ及び窓位置センサー５ｆを含み、フロントドアサブシステム３ｅ、３ｆは、それぞれ、ミラー制御モーター５ｇ及びミラー位置センサー５ｈを含む。
【0044】
車両１は、車両１の機能を実装するために車両の様々なサブシステム３の動作を制御するように構成されたいくつかのソフトウェアアプリケーション又はアプリケーション機能１０を含み、そのいくつかは図３に示されている。例えば、車両１は、高さ制御モーターを使用して各シートの高さを制御するためのシート制御機能１０ａ、及びヘッドレスト制御モーターを使用して各シートのヘッドレスト位置を制御するためのシートコンフォート機能１０ｂを含むシートアプリケーション機能群を含む。さらに、車両１は、窓制御モーターを使用して各ドア窓の位置を制御するための窓制御機能１０ｃ、及びミラー制御モーターを使用して左前及び右前ドアミラーの位置を制御するためのミラー制御機能１０ｄを含むドアアプリケーション機能群を含む。車両１はまた、（図３に示されていない他の多くのアプリケーション機能の中でも）、フロントガラスワイパーシステム３ｉを制御するためのワイパー制御機能１０ｅ、照明システム３ｊを制御するための照明制御１０ｆ機能、及び警報システム３ｋを制御するための警報機能１０ｇを備える。
【0045】
従来の電気アーキテクチャでは、車両の各シートと各ドアには、シートの高さの調整や窓の開閉などの車両機能を制御するための１つ以上のローカルＥＣＵが必要であり、各ＥＣＵは、１つ以上の場所固有のアプリケーション機能と、ローカルでホストされているアプリケーション機能に関連するセンサー及びアクチュエーターのＩ／Ｏドライバーをホストしている。例えば、左前部シート３ａには、左前部シートのシート制御及びシートコンフォート機能とともに、左前部シートのセンサーとアクチュエーターのドライバーをホストする左前部シートＥＣＵが含まれ得る。残りのシートと各ドアにも同様のＥＣＵが必要になる。
【0046】
ただし、図３に示す電気アーキテクチャでは、シート３ａ～ｄ、ドア３ｅ～ｈ、ワイパーシステム３ｉ、照明システム３ｊ、及び警報システム３ｋに関連する車両機能を制御するためのアプリケーション機能１０は、ローカルＥＣＵから、中央機能ホスティングシステム又は中央計算プラットフォーム（ＣＣＰ）１５に移動され、これにより、車両１の各シート及び各ドアに別個のＥＣＵを提供する必要がなくなる。
【0047】
アプリケーション機能１０は、ＣＣＰ１５で集中的にホストされるので、各アプリケーション機能１０は、車両１の異なるゾーンに位置する複数のサブシステムに対してその特定の機能を制御することが可能であり、その結果、車両１で必要とされるアプリケーション機能１０の数を減らすことができる。例えば、ＣＣＰ１５でホストされる単一のシート制御機能１０ａは、車両１の各シート３ａ～ｄの高さを制御することができ、ＣＣＰ１５でホストされる単一の窓制御機能１０ｃは、車両１の各ドア３ｅ～ｈの窓位置を制御することができる。
【0048】
車両１は、図３に示されているものに加えて、他の多数のアプリケーション機能を含むことが理解される。これらの追加のアプリケーション機能の一部は、ＣＣＰ１５でホストされることもできる。ただし、他のアプリケーション機能は、例えば従来のＥＣＵやリモート入力／出力コンセントレータモジュール（ＲＩＯ）（以下で詳しく説明する）など、様々な場所でホストされ得る。
【0049】
図３に示すように、ＣＣＰ１５は、車両診断マネージャー（ＶＤＭ）２０もホストし、車両１に様々な車両診断監視サービスを提供する。特に、ＶＤＭ２０は、以下で詳しく説明するように、同じくＣＣＰ１５で配置された中央故障メモリシステム２１においても、検出された故障の中央の車両全体の記録を作成、保存、及び管理し、検出された故障をオンボード及びオフボードテスターなどの診断クライアントに報告するように構成される。以下で詳しく説明する。
【0050】
上記のように、シート及びドアに関連する車両機能を制御するためのアプリケーション機能１０ａ～ｄは、車両１のＣＣＰ１５で集中的にホストされる。ただし、これらの車両機能を実装するために必要なＩ／Ｏデバイス（すなわち、車両シート３ａ～ｄ及び車両ドア３ｅ～ｈに関連するセンサー及びアクチュエーター５ａ～ｈ）には、ＣＣＰ１５よりもＩ／Ｏデバイスに近いローカルコントローラーが必要である。このため、車両には、図３に示すように、車両の主要ゾーンごとに１つずつ、４つのリモート入力／出力コンセントレータデバイス（ＲＩＯ）３０が搭載されており、それぞれが、複数の異なるアプリケーション機能１０に関連するＩ／Ｏデバイス５のためのドライバー３１をホストし、通信を容易にする。
【0051】
特に、車両１は、左前部シート３ａ及び左前部ドア３ｅのセンサー及びアクチュエーターのドライバーをホストし、それらと通信する左前部ＲＩＯ３０ａと、右前部シート３ｂ及び右前部ドア３ｆのセンサー及びアクチュエーターのドライバーをホストし、それらと通信する右前部ＲＩＯ３０ｂと、左後部シート３ｃ及び左後部ドア３ｇのセンサー及びアクチュエーターのドライバーをホストし、それらと通信する左後部ＲＩＯ３０ｃと、右後部シート３ｄ及び右後部ドア３ｈのセンサー及びアクチュエーターのドライバーをホストし、それらと通信する右後部ＲＩＯ３０ｄを含む。ワイパーシステム３ｉ、照明システム３ｊ、及び警報システム３ｋのＩ／Ｏデバイス用のドライバーもまた、上記のＲＩＯ３０のうちの１つ又は複数でホストされ得る。
【0052】
車両１はまた、図３に示されている４つのＲＩＯに加えて、様々な他のＲＩＯ３０及び／又はローカルＥＣＵを含み得、これらは、図３に示されていない他のＩ／Ｏデバイスのドライバーをホストし、通信し得ることが理解される。
【0053】
ＲＩＯ３０は、ＣＡＮ又はＬＩＮリンクを介してそれぞれのＩ／Ｏデバイス５に接続される。ＲＩＯ３０はまた、車両のバックボーンリンク又はワイヤリングハーネス４０を介してＣＣＰ１５に接続される。バックボーンリンク又はワイヤリングハーネス４０は、例えば、ＲＩＯ３０とＣＣＰ１５との間にイーサネット又はＦｌｅｘＲａｙリンクを提供することができる。バックボーンリンク又はワイヤリングハーネス４０を介して、ＲＩＯ３０は、例えば、アプリケーション機能１０から命令信号を受信し、それらに関連するＩ／Ｏデバイス５からアプリケーション機能１０に出力データを送信するために、アプリケーション機能１０と通信することができる。
【0054】
図３に示されるように、Ｉ／Ｏ及びＣＯＭドライバー３１に加えて、各ＲＩＯ３０は、診断サーバー３２を含む。各ＲＩＯ３０の診断サーバー３２は、物理的故障に関する診断テスト又は故障モニターを実行するように構成され、物理的故障は、Ｉ／Ｏデバイス５及びそのＲＩＯ３０に関連する通信チャネルに関連する故障である。特に、ＲＩＯ３０の診断サーバー３２には、特定の物理的故障の合格／不合格データを生成するように構成されたデバイスドライバーレベルの故障デバウンスロジックが含まれる。物理的な合格／不合格データは、例えば、アクチュエーターの電流とセンサーの出力をデバイス固有のしきい値レベルと比較することによって生成できる。
【0055】
例えば、左前部ＲＩＯ３０ａの診断サーバー３２は、開回路故障状態をチェックするために、左前部シート３ａの高さ制御モーター５ａのモーター回路電流を低い閾値レベルと比較し、短絡故障状態をチェックするために高いしきい値レベルと比較するように構成され得る。モーター回路電流が低しきい値と高しきい値の間にある限り、開回路故障モニターと短絡故障モニターの両方が合格データを生成する。ただし、モーター回路の電流が下限しきい値を下回ると、開回路故障モニターが故障データを生成する。同様に、モーター回路電流が高しきい値を超えると、短絡故障モニターが故障データを生成する。
【0056】
さらに、ＲＩＯ３０は、例えば、事前定義された期間又は監視サイクル数にわたって特定の物理的故障モニターによって故障データが生成された場合に、物理的故障を検出するように構成された基本的な故障検出ロジックを含む。ＲＩＯ３０はまた、物理的故障の検出時に適切な故障反応を決定及び開始するように構成され、例えば、故障が修復されるまで、関連するドライバー３１を無効にする。ただし、ＲＩＯ３０は、関連するＩ／Ｏデバイス５及び通信チャネルの物理的故障に対して確認済みＤＴＣを生成する必要がないため、確認済み物理的ＤＴＣを生成するためのＤＴＣ認定ロジックを必要としない。
【0057】
ＲＩＯ３０は、物理的故障モニターによって生成されたすべての合格／不合格データを、車両のバックボーンリンク又はワイヤーハーネス４０を介してＶＤＭ２０に送信するように構成される。例えば、左前部シート３ａの高さ制御モーター５ａのモーター回路電流が低しきい値と高しきい値の間にある場合、合格データは、開回路故障モニターと短絡故障モニターの両方について、左前のＲＩＯ３０ａからＶＤＭに送信される。しかし、モーター回路の電流が下限しきい値を下回ると、故障データは開回路故障モニターのためにＶＤＭに送信され；モーター回路電流が高しきい値を超えると、故障データ短絡故障モニターのためにＶＤＭに送信される。
【0058】
図３にも示されているように、ＣＣＰ１５は診断サーバー２４も含む。ＣＣＰ１５でホストされるアプリケーション機能１０はそれぞれ、共通の診断サーバー２４を使用して、戦略的故障（アプリケーション機能の可用性、パフォーマンス、又は正常性に関連する高レベルの故障）に関する診断テスト又は故障モニターを実行するように構成される。他の実施形態では、アプリケーション機能１０又はアプリケーション機能群は、それぞれの戦略的故障モニターを実行するための独自の専用診断サーバーを有し得る。
【0059】
アプリケーション機能１０の１つ又は複数の診断サーバー又はサーバー２４は、特定の戦略的故障の合格／不合格データを生成するように構成されたアプリケーション機能レベルの故障デバウンスロジックを含む。戦略的な合否データは、例えば、ＲＩＯ３０及び／又は他のアプリケーション機能から受信された信号の可用性及び／又は信頼性に応じて生成され得る。例えば、診断サーバー２４は、左前部シート３ａの高さ制御モーター５ａ及び高さ位置センサー５ｂが正しく機能している間に、合格データを生成し、高さ制御モーター５ａ又は高さ位置センサー５ｂからのデータが利用できないか、信頼できない場合は、不合格データを生成するように構成された前左シート位置制御故障モニターを実行することができる。
【0060】
さらに、アプリケーション機能１０は、例えば、事前定義された期間又は監視サイクル数にわたって特定の戦略的故障モニターによって故障データが生成された場合に、戦略的故障を検出するように構成される基本的な故障検出ロジックを含む。
アプリケーション機能１０はまた、例えば特定の車両機能を無効にするなど、戦略的故障の検出時に適切な故障反応を決定及び開始するように構成される。しかし、アプリケーション機能１０は、関連する車両機能の戦略的故障について確認済みＤＴＣを生成する必要がないので、確認済み物理的ＤＴＣを生成するためのＤＴＣ認定ロジックを必要としない。
アプリケーション機能１０はまた、例えば特定の車両機能を無効にするなど、戦略的故障の検出時に適切な故障反応を決定及び開始するように構成される。しかし、アプリケーション機能１０は、関連する車両機能の戦略的故障について確認済みＤＴＣを生成する必要がないので、確認済み物理的ＤＴＣを生成するためのＤＴＣ認定ロジックを必要としない。
【0061】
アプリケーション機能１０はまた、戦略的故障モニターによって生成されたすべての合格／不合格データを、ＣＣＰ１５のサービスバス２５を介してＶＤＭ２０に送信するように構成される。
【0062】
ＶＤＭ２０への、ＲＩＯ３０からの物理的合格／不合格データ及びアプリケーション機能１０からの戦略的合格／不合格データの通信の頻度は、個々の故障モニターの周期性に基づく。例えば、ＲＩＯ３０及びアプリケーション機能１０はそれぞれ、合格／不合格データを生成時に送信するように構成され得る。場合によっては、合格／不合格データが１００ｍｓごとに送信され得るが、他の通信頻度も可能であり、異なる通信頻度が異なるＲＩＯ３０及びアプリケーション機能１０によって使用され得る。
【0063】
ＶＤＭ２０は、戦略的及び物理的故障を検出し、検出された故障を、原因故障（直接の修復アクションを必要とする根本原因故障）又は結果故障（根本原因故障の結果として引き起こされ又は検出され、直接修復アクションを必要としない可能性がある故障）のいずれかに分類するために、アプリケーション機能１０及びＲＩＯ３０から受信した戦略的及び物理的合格／不合格データを集約及びトリアージするように構成される。ＶＤＭ２０はさらに、中央故障メモリシステム２１の一次故障メモリ部２２（そこから標準ＵＤＳプロトコルインターフェイスを使用して車両の診断システム２に接続されている任意の診断クライアントが故障データを利用できる）に原因故障の記録を維持し、中央故障メモリシステム２１のユーザー定義の二次故障メモリ部２３（メーカー定義の要求の受信時にのみ利用可能である）に結果故障の記録を維持するように構成される。
【0064】
例えば、上記の左前部シート３ａの高さ制御モーター５ａが故障した場合、ＶＤＭ２０は、左前部シート３ａの高さ制御モーター５ａが故障したことを示す、左前部ＲＩＯ３０ａから物理的合格／不合格データとともに、左前部シート３ａでは高さ調整が利用できないことを示す、シート制御アプリケーション機能１０ａからの戦略的合格／不合格データを受信することができる。この場合、ＶＤＭ２０は、これら２つの検出された故障をトリアージし、複数の検出された故障の根本原因が左前部シート３ａの高さ制御モーター５ａの故障であることを確認できる可能性がある。この場合、高さ制御モーター５ａの故障は、中央故障メモリシステム２１の一次故障メモリ２２に記録され、一方、左前部シート３ａの高さ調整が利用できないことは、中央故障メモリシステム２１のユーザー定義の二次故障メモリ２３に記録される。
【0065】
上記の例は、単一の原因故障と単一の結果故障のみを含む非常に単純な例である。しかし、複数の根本原因故障及び／又は複数の関連する結果故障を含む関連する故障のより大きなグループも同様の方法でトリアージされ得ることが理解される。
【0066】
ＶＤＭ２０には、上記のトリアージプロセスと並行して、アプリケーション機能１０及びＲＩＯ３０から受信した戦略的及び物理的合格／不合格情報に依存して、検出された戦略的及び物理的故障のスナップショット及び拡張データ記録情報とともに確認済みＤＴＣを生成するように構成されたＤＴＣ認定ロジックも含まれる。ＶＤＭ２０はさらに、生成されたＤＴＣを、ＤＴＣの状態を確認するステータスバイトデータならびに関連するスナップショット及び拡張データ記録情報とともに、（上記のトリアージプロセスの結果に応じて）原因故障記録２２又は結果故障記録２３のいずれかに格納するように構成される。
【0067】
１つ又は複数のＤＴＣが中央故障メモリシステム２１に記録されると、ＶＤＭ２０は、記録されたＤＴＣをオンボード及びオフボードテスターなどの診断クライアントが利用できるようにすることができる。例えば、サードパーティのオフボードテスターあるいはオンボードテスター２６などの診断クライアントが、標準のＵＤＳプロトコルインターフェイスを使用して車両１の診断システム２に接続されている場合、ＶＤＭ２０は、すべての原因故障のＤＴＣを含む原因故障記録を診断クライアントに報告する。ただし、メーカーが定義した要求がＶＤＭ２０によって受信されない限り、結果の故障記録は報告されない。
【0068】
ＶＤＭ２０は、車両１の通常の動作中に戦略的及び物理的故障の両方の記録を維持することができるので、ＲＩＯ３０が物理的故障のローカル記録を維持することは一般に必要ではない。ただし、物理的故障の完全な記録を確実に維持するために、ＲＩＯ３０は、ＲＩＯ３０とＶＤＭ２０との間の通信が中断された場合（例えば、車両のワイヤリングハーネス４０の故障のため）に、物理的故障データを記録するように構成される。
【0069】
特に、ＶＤＭ２０は、車両のワイヤーハーネス４０を介してＲＩＯ３０とのキープアライブインターフェイスを維持するように構成される。キープアライブ情報がＲＩＯ３０によって有効に受信される限り、ＲＩＯ３０は、物理的故障のローカル記録を維持することなく、物理的故障モニターによって生成された合格／不合格データをＶＤＭ２０に送信するように構成される。しかしながら、ＲＩＯ３０は、キープアライブインターフェイスにおける中断を検出すると、個々のＲＩＯ３０に関連するユーザー定義の二次故障メモリ３３内のローカルの物理的故障記録の維持を開始するように構成される。ＲＩＯ３０には、確認済みＤＴＣを生成するために必要な故障認定ロジックがないため、ローカル故障記録は、物理的故障モニターの合格／不合格の結果のみを記録する場合がある。
【0070】
ＶＤＭ２０は、アプリケーション機能１０からの戦略的故障に関する故障データと、ＲＩＯ３０からの物理的故障に関する故障データを受信するように構成されるので、本発明の診断アーキテクチャは、ＶＤＭ２０が物理的及び戦略的故障を検出及びトリアージするために必要なすべての故障データを集約し、車両全体の故障の記録を維持することを可能とする。
【0071】
さらに、ＶＤＭ２０は、上記の実施形態における戦略的及び物理的故障モニターによって生成されたすべての合格／不合格データにアクセスできるので、ＶＤＭ２０は、コンポーネントと車両機能の劣化した状態を検出し、それらの故障に対してＤＴＣが生成される前に、特定の故障の発生を予測し、故障をトリアージすることができる。ただし、戦略的及び物理的故障モニターによって生成されたすべての合格／不合格データをＶＤＭ２０に送信すると、ＣＣＰのサービスバス２５と車両のワイヤーハーネス４０で高信号トラフィックが発生する。したがって、以下に説明される本発明の代替の実施形態では、故障データのＶＤＭ２０への通信の頻度が低減される。
【0072】
代替的実施形態は、上記で説明されるものと類似のシステムアーキテクチャを採用し、図２及び３に示される。特に、代替的診断システムは、様々なサブシステム３の動作を制御するように構成されたＣＣＰ１５でホストされるアプリケーション機能１０の類似の配置を含み、サブシステム３は、とりわけ、車両の左前部シート３ａ、右前部シート３ｂ、左後部シート３ｃ、右後部シート３ｄ、左前部ドア３ｅ、右前部ドア３ｆ、左後部ドア３ｇ、及び右後部ドア３ｈを含む。さらに、代替的診断システムは、上記サブシステム３に関連するＩ／Ｏデバイス５のためのドライバー３１をホストし、それらとの通信を容易にする、リモート入力／出力コンセントレータデバイス（ＲＩＯ）３０ａ、３０ｂ、３０ｃ、３０ｄの類似の配置も含む。さらに、代替的診断システムは、ＣＣＰ１５でホストされる類似の車両診断マネージャー（ＶＤＭ２０）（これは、同じくＣＣＰ上に配置された中央故障メモリシステム２１においても、検出された故障の中央の車両全体の記録を作成、保存、及び管理するように構成されている）も含む。
【0073】
説明された第１の実施形態のように、アプリケーション機能１０及びＲＩＯ３０は、それぞれ、関連する車両機能、Ｉ／Ｏデバイス、及び通信チャネルで戦略的及び物理的故障を検出するために、戦略的及び物理的故障モニターを実行し、ＶＤＭ２０とは独立して、適切な故障反応を判断して開始するように構成される。ただし、以下でより詳細に説明するように、故障データがアプリケーション機能１０及びＲＩＯ３０からＶＤＭ２０に通信される方法は異なる。
【0074】
特に、この代替的実施形態では、アプリケーション機能１０は、関連する車両機能の戦略的故障について確認済みＤＴＣを生成するための故障認定ロジックをそれぞれ備えている。アプリケーション機能１０はさらに、アプリケーション機能に関連するユーザー定義の二次故障メモリ内の戦略的故障の故障記録を維持するように構成される。同様に、ＲＩＯ３０は、それらの関連するＩ／Ｏデバイス及び通信チャネルの物理的故障について確認済みＤＴＣを生成するための故障認定ロジックをそれぞれ備えている。ＲＩＯ３０はさらに、それらの個々のユーザー定義の二次故障メモリ内の物理的故障の故障記録を継続的に維持するように構成される。これは、アプリケーション機能１０が戦略的故障の独自の記録を維持せず、ＲＩＯ３０がＶＤＭ２０との通信の検出された中断に応答してのみ物理的故障の独自の記録を維持する第１の実施形態とは対照的である。
【0075】
また、この代替の実施形態では、アプリケーション機能１０及びＲＩＯ３０は、ＤＴＣの確認時にのみ、例えば、ＤＴＣステータスバイトの変更に応じて、中央故障メモリシステムでのトリアージ及び記録のために、検出された戦略的及び物理的故障についてローカルで生成されたＤＴＣをＶＤＭ２０に送信するように構成される。これは、アプリケーション機能１０及びＲＩＯ３０がそれぞれ、戦略的及び物理的故障モニターによって生成された生の合格／不合格データをＶＤＭ２０に連続的に送信する第１の実施形態とは対照的である。
【0076】
説明された第１実施形態のように、ＶＤＭ２０は、検出された故障を原因故障又は結果故障のいずれかとして分類するために、検出された故障をトリアージするように構成される。ＶＤＭ２０はまた、中央故障メモリシステム２１の一次故障メモリ部２２に原因故障の記録を維持し、中央故障メモリシステム２１のユーザー定義の二次故障メモリ部分２３に結果故障の記録を維持するように構成される。しかし、ＶＤＭ２０は、生の合格／不合格データではなく、アプリケーション機能１０及びＲＩＯ３０から検出された戦略的及び物理的故障のＤＴＣを受信するように構成されているため、ＶＤＭ２０によって実行される故障トリアージプロセスは、（説明された第１の実施形態における生の合格／不合格データの代わりに）受信されたＤＴＣに基づく可能性がある。
【0077】
上記の説明は、本発明の２つの可能な実施形態に関する。しかしながら、添付の特許請求の範囲で定義される本発明の範囲から逸脱することなく、上記の実施例に対して多くの変更を行うことができることが理解される。
【図1】
【図2】
【図3】