(57)【要約】  異常を検出するシステムが、第1のハードウェアシステムと第1のランタイム環境とを含む。第1のハードウェアシステムは、出力を生成する。第1のランタイム環境は、統合開発環境への双方向リンクを有する。第1のランタイム環境は、第1の制御システムと、第1の診断エージェントと、第2の診断エージェントとを含む。第1の制御システムは、ハードウェアシステムへの制御入力により、ハードウェアシステムを制御する。第1の診断エージェントは、ハードウェアシステム内の異常を検出する。第2の診断エージェントは、制御システム内の異常を検出する。【特許請求の範囲】
【請求項１】
異常を検出するシステムであって、
出力を生成する第1のハードウェアシステムと、
統合開発環境への双方向リンクを有する第1のランタイム環境とを備え、前記第1のランタイム環境が、
前記ハードウェアシステムへの制御入力により、前記ハードウェアシステムを制御する第1の制御システムと、
前記ハードウェアシステム内の異常を検出する第1の診断エージェントと、
前記制御システム内の異常を検出する第2の診断エージェントとを含み、
前記第1および第2の診断エージェントが、前記第1のランタイム環境において現在の動作の挙動と正常動作の挙動とを比較して前記システムの性能の漸進的劣化を検出し、前記双方向リンクを通じて前記統合開発環境までさかのぼって前記異常を追跡することにより、異常を検出することが可能であることを特徴とするシステム。
【請求項２】
前記統合開発環境が、前記第1および第2の診断エージェントを前記ランタイム環境に配備することを可能にする、前記統合開発環境内で動作するソフトウェア開発ツールおよびハードウェア開発ツールの集合を含むことを特徴とする請求項1に記載のシステム。
【請求項３】
出力を生成する第2のハードウェアシステムと、
前記統合開発環境への双方向リンクを有する第2のランタイム環境とをさらに備え、前記第2のランタイム環境が、
前記ハードウェアシステムへの制御入力により、前記ハードウェアシステムを制御する第2の制御システムと、
前記ハードウェアシステム内の異常を検出する第3の診断エージェントと、
前記制御システム内の異常を検出する第4の診断エージェントとを含み、
前記第3および第4の診断エージェントが、前記第2のランタイム環境において現在の動作の挙動と正常動作の挙動とを比較して前記システムの性能の漸進的劣化を検出し、前記双方向リンクを通じて前記統合開発環境までさかのぼって前記異常を追跡することにより、異常を検出することが可能であることを特徴とする請求項1に記載のシステム。
【請求項４】
前記双方向リンクが、前記統合開発環境で生成された構成データを収容することと、前記第1および第2の診断エージェントを第1のランタイム環境に配備するために、前記構成データを前記第1のランタイム環境に渡すこととのために、データベースおよびメッセージ渡しの組み合わせに関連付けられた開発ランタイム開発リンクを含むことを特徴とする請求項1に記載のシステム。
【請求項５】
前記双方向リンクが、前記第1のランタイム環境から前記異常を受け取り、前記異常を前記統合開発環境に渡すことを特徴とする請求項4に記載のシステム。
【請求項６】
前記第1の診断エージェントが複数の第1の診断エージェントを含み、前記第2の診断エージェントが複数の第2の診断エージェントを含むことを特徴とする請求項1に記載のシステム。
【請求項７】
前記第1のランタイム環境が複数のランタイム環境を含むことを特徴とする請求項1に記載のシステム。
【請求項８】
リンクによって双方向にリンクされた統合開発環境およびランタイム環境を含むシステムにおける異常を検出する方法であって、
前記ランタイム環境を1つ以上の動作可能領域に分割する段階と、
前記動作可能領域内での正常動作の挙動を学習する段階と、
前記システムの動作時に、前記動作可能領域内での現在の動作の挙動を監視する段階と、
前記現在の動作の挙動を前記正常動作の挙動と比較する段階と、
前記現在の動作の挙動と前記正常動作の挙動との間にずれが存在する場合に異常を検出する段階と、
前記リンクを通じて前記統合開発環境までさかのぼって前記異常を追跡する段階と、
前記異常の前記追跡に基づいて、前記統合開発環境内の前記異常を識別する段階と
を含むことを特徴とする方法。
【請求項９】
前記システムを分割する段階が、自己組織化マップを用いて前記システムを1つ以上の動作可能領域に分割する段階を含むことを特徴とする請求項8に記載の方法。
【請求項１０】
前記システムを分割する段階が、自己組織化マップを用いて前記システムを1つ以上の動作可能領域に自動的に分割する段階を含むことを特徴とする請求項9に記載の方法。
【請求項１１】
前記異常を検出する段階が、時間-周波数解析を用いて異常を検出する段階を含むことを特徴とする請求項8に記載の方法。
【請求項１２】
前記異常を検出する段階が、前記正常動作の挙動からの統計的ずれを認識する時間-周波数解析への拡張を用いて、高い統計的精度で異常を検出する段階を含むことを特徴とする請求項11に記載の方法。
【請求項１３】
前記システムを分割する段階が、領域化と呼ばれる、前記システムを1つ以上の動作可能領域に分割する段階を含むことを特徴とする請求項8に記載の方法。
【請求項１４】
前記正常動作の挙動を学習する段階が、トレーニングと呼ばれる、前記動作可能領域内での正常動作の挙動を学習する段階を含むことを特徴とする請求項8に記載の方法。
【請求項１５】
前記統合開発環境内の前記動作可能領域を認識する段階をさらに含むことを特徴とする請求項8に記載の方法。
【請求項１６】
前記システムを分割する段階が、前記システムを、単一の異常検出器による観察が可能な1つ以上の動作可能領域に分割する段階を含むことを特徴とする請求項8に記載の方法。
【請求項１７】
前記異常の前記追跡に基づいて前記統合開発環境内の前記異常を識別する段階が、前記異常の前記追跡に基づいて前記統合開発環境内の前記異常の根本原因を識別する段階を含むことを特徴とする請求項8に記載の方法。
【請求項１８】
リンクによって双方向にリンクされた統合開発環境およびランタイム環境を含むシステムにおける異常を検出するシステムであって、
前記ランタイム環境を1つ以上の動作可能領域に分割する分割モジュールと、
前記動作可能領域内での正常動作の挙動を学習する学習モジュールと、
前記システムの動作時に、前記動作可能領域内での現在の動作の挙動を監視する監視モジュールと、
前記現在の動作の挙動を前記正常動作の挙動と比較する比較モジュールと、
前記現在の動作の挙動と前記正常動作の挙動との間にずれが存在する場合に異常を検出する検出モジュールと、
前記リンクを通じて前記統合開発環境までさかのぼって前記異常を追跡する追跡モジュールと、
前記異常の前記追跡に基づいて、前記統合開発環境内の前記異常を識別する識別モジュールと
を備えることを特徴とするシステム。
【請求項１９】
前記分割モジュールが自己組織化マップを用いることを特徴とする請求項18に記載のシステム。
【請求項２０】
前記検出モジュールが時間-周波数解析を用いることを特徴とする請求項18に記載のシステム。
【請求項２１】
前記分割モジュールが、前記システムを、単一の異常検出器による観察が可能な1つ以上の動作可能領域に分割することを特徴とする請求項18に記載のシステム。
【請求項２２】
コンピューティングシステム可読であり、リンクによって双方向にリンクされた統合開発環境およびランタイム環境を含むシステムにおけるモデルエラーを診断する命令をエンコードするコンピュータプログラム製品であって、前記コンピュータプロセスが、
前記ランタイム環境を1つ以上の動作可能領域に分割する段階と、
前記動作可能領域内での正常動作の挙動を学習する段階と、
前記システムの動作時に、前記動作可能領域内での現在の動作の挙動を監視する段階と、
前記現在の動作の挙動を前記正常動作の挙動と比較する段階と、
前記現在の動作の挙動と前記正常動作の挙動との間にずれが存在する場合に異常を検出する段階と、
前記リンクを通じて前記統合開発環境までさかのぼって前記異常を追跡する段階と、
前記異常の前記追跡に基づいて、前記統合開発環境内の前記異常を識別する段階とを含むことを特徴とするコンピュータプログラム製品。
【請求項２３】
前記システムを分割する段階が、自己組織化マップを用いて前記システムを1つ以上の動作可能領域に分割する段階を含むことを特徴とする請求項22に記載のコンピュータプログラム製品。
【請求項２４】
前記システムを分割する段階が、自己組織化マップを用いて前記システムを1つ以上の動作可能領域に自動的に分割する段階を含むことを特徴とする請求項23に記載のコンピュータプログラム製品。
【請求項２５】
前記異常を検出する段階が、時間-周波数解析を用いて異常を検出する段階を含むことを特徴とする請求項22に記載のコンピュータプログラム製品。
【請求項２６】
前記異常を検出する段階が、前記正常動作の挙動からの統計的ずれを認識する時間-周波数解析への拡張を用いて、高い統計的精度で異常を検出する段階を含むことを特徴とする請求項25に記載のコンピュータプログラム製品。
【請求項２７】
前記システムを分割する段階が、領域化と呼ばれる、前記システムを1つ以上の動作可能領域に分割する段階を含むことを特徴とする請求項22に記載のコンピュータプログラム製品。
【請求項２８】
前記正常動作の挙動を学習する段階が、トレーニングと呼ばれる、前記動作可能領域内での正常動作の挙動を学習する段階を含むことを特徴とする請求項22に記載のコンピュータプログラム製品。
【請求項２９】
前記統合開発環境内の前記動作可能領域を認識する段階をさらに含むことを特徴とする請求項22に記載のコンピュータプログラム製品。
【請求項３０】
前記システムを分割する段階が、前記システムを、単一の異常検出器による観察が可能な1つ以上の動作可能領域に分割する段階を含むことを特徴とする請求項22に記載のコンピュータプログラム製品。
【請求項３１】
前記異常の前記追跡に基づいて前記統合開発環境内の前記異常を識別する段階が、前記異常の前記追跡に基づいて前記統合開発環境内の前記異常の根本原因を識別する段階を含むことを特徴とする請求項22に記載のコンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェアおよびシステムに関し、特に、ランタイム環境における異常検出器に関する。
【背景技術】
【０００２】
製品開発の今日のパラダイムでは、製品の品質、製造、およびサービスは、主として開発時に設計、テスト、および実装が行われる。製品、その製造、またはそのサービスにおけるエラーは、開発中に識別され、修正される。いったん製品が発売されれば、残存する品質問題を見つけるのは困難である。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
自動車産業においては、保証修理は高額であり、会社の利益を食いつぶしかねない。保証修理コストのうちの50%を超える分の根本的原因が、エンジニアリングである。自動車内部で動作しているソフトウェアが、エンジニアリングの問題の核となる部分である。エンジニアリングが問題の根本的原因であることが多いので、修理時に部品を交換することは、問題の解決にはならない。そこで、改善が望まれる。
【課題を解決するための手段】
【０００４】
本発明によれば、前述および他の問題は、以下によって解決される。
【０００５】
本発明の一態様では、異常を検出するシステムが、第1のハードウェアシステムと第1のランタイム環境とを含む。第1のハードウェアシステムは、出力を生成する。第1のランタイム環境は、統合開発環境への双方向リンクを有する。第1のランタイム環境は、第1の制御システムと、第1の診断エージェントと、第2の診断エージェントとを含む。第1の制御システムは、ハードウェアシステムへの制御入力により、ハードウェアシステムを制御する。第1の診断エージェントは、ハードウェアシステム内の異常を検出する。第2の診断エージェントは、制御システム内の異常を検出する。
【０００６】
本発明の別の態様では、リンクによって双方向にリンクされた統合開発環境およびランタイム環境を含むシステムにおける異常を検出する方法が開示される。この方法は、ランタイム環境を1つ以上の動作可能領域に分割する段階と、その動作可能領域内での正常動作の挙動を学習する段階と、システムの動作時に、その動作可能領域内での現在の動作の挙動を監視する段階と、現在の動作の挙動を正常動作の挙動と比較する段階と、現在の動作の挙動と正常動作の挙動との間にずれが存在する場合に異常を検出する段階と、統合開発環境までさかのぼってその異常を追跡する段階と、異常の追跡に基づいて、統合開発環境内の異常を識別する段階とを含む。
【０００７】
本発明の別の態様では、コンピュータシステム可読であって、リンクによって双方向にリンクされた統合開発環境およびランタイム環境を含むシステムにおける異常を検出するコンピュータ処理のための命令をエンコードするコンピュータプログラム製品が開示される。このコンピュータプログラム製品は、ランタイム環境を1つ以上の動作可能領域に分割する段階と、その動作可能領域内での正常動作の挙動を学習する段階と、システムの動作時に、その動作可能領域内での現在の動作の挙動を監視する段階と、現在の動作の挙動を正常動作の挙動と比較する段階と、現在の動作の挙動と正常動作の挙動との間にずれが存在する場合に異常を検出する段階と、統合開発環境までさかのぼってその異常を追跡する段階と、異常の追跡に基づいて、統合開発環境内の異常を識別する段階とを含む。
【０００８】
本発明のさらに別の態様では、リンクによって双方向にリンクされた統合開発環境およびランタイム環境を含むシステムにおける異常を検出するシステムが開示される。このシステムは、分割モジュールと、学習モジュールと、監視モジュールと、比較モジュールと、検出モジュールと、追跡モジュールと、識別モジュールとを含む。分割モジュールは、ランタイム環境を1つ以上の動作可能領域に分割する。学習モジュールは、その動作可能領域内での正常動作の挙動を学習する。監視モジュールは、システムの動作時に、その動作可能領域内での現在の動作の挙動を監視する。比較モジュールは、現在の動作の挙動を正常動作の挙動と比較する。検出モジュールは、現在の動作の挙動と正常動作の挙動との間にずれが存在する場合に異常を検出する。追跡モジュールは、統合開発環境までさかのぼってその異常を追跡する。識別モジュールは、異常の追跡に基づいて、統合開発環境内の異常を識別する。
【０００９】
本発明は、コンピュータ処理として、または分散可能なコンピューティングシステムとして、またはコンピュータプログラム製品のような製造物として実現可能である。コンピュータプログラム製品は、コンピュータシステム可読であって、コンピュータ処理を実行するための命令のコンピュータプログラムをエンコードするコンピュータ記憶媒体であることが可能である。コンピュータプログラム製品はまた、コンピュータシステム可読であって、コンピュータ処理を実行するための命令のコンピュータプログラムをエンコードする、搬送波によって伝搬される信号であることも可能である。
【００１０】
本発明のさらに詳細な応用、ならびに本発明の範囲については、後で簡単に説明される添付図面、以下の、現時点で好ましい、本発明の実施形態の詳細説明、ならびに添付の特許請求項によって示される。
【００１１】
添付図面において、同様な参照符号は、全図面を通じて対応する要素を表す。
【発明を実施するための最良の形態】
【００１２】
以下の、本発明の好ましい実施形態の説明では、本明細書の一部をなす添付図面を参照する。添付図面では、本発明を実施することが可能な、具体的な実施形態を例示として示している。本発明の範囲から逸脱することなく、他の実施形態も利用してよいこと、ならびに変更を加えてよいことを理解されたい。
【００１３】
本開示は、学習モデルベースライフサイクルソフトウェアおよびシステムのための方法およびシステムを説明する。より具体的には、このソフトウェアおよびシステムは、自己診断用であって、典型的には、埋め込み診断エージェントを含む。これらの診断エージェントとして、異常検出エージェントや知識ベースエージェントなどがある。
【００１４】
システムは、互いにリンクされた統合開発環境(IDE)およびランタイム環境(RTE)を含むことが可能である。IDEは、IDE内でリンクされた、およびRTEとリンクされた一連の開発ツールを含む。RTEは、RTE内でリンクされた、およびIDEとリンクされた多数の診断エージェントを含む。その結果、開発ツールおよび診断エージェントは互いに通信し合う。
【００１５】
図1は、学習モデルベースライフサイクルシステム100の例の概略図である。IDE 105は、IDE 105内でリンクされた一連のソフトウェアツール(エージェント)を含む。RTE 110は、RTE 110内でリンクされた、別の一連のソフトウェアエージェントを含む。IDE 105とRTE 110とは、リンク115を介してリンクされる。
【００１６】
図2および以下の記述は、本発明の実装に好適なコンピューティング環境を簡単かつ全般的に説明するものである。必須ではないが、本発明は、プログラムモジュールのような、コンピューティングシステムによって実行される、コンピュータで実行可能な命令の一般的な文脈で説明される。一般にプログラムモジュールとしては、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造体などがあり、これらは、個々のタスクを実行したり、個々の抽象データ型を実装したりする。
【００１７】
当業者であれば、本発明が他のコンピュータシステム構成(たとえば、手持ち式装置、手のひらサイズの装置、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラム可能である家庭用電子機器、ネットワーク用パーソナルコンピュータ、ミニコンピュータ、メインフレームコンピュータなど)でも実施可能であることを理解されよう。本発明はまた、通信ネットワークを介してリンクされたリモート処理装置によってタスクが実行される分散コンピューティング環境でも実施可能である。分散コンピューティング環境では、ローカルメモリ記憶装置およびリモートメモリ記憶装置の両方にプログラムモジュールを配置することが可能である。
【００１８】
図2に示した、本発明の実施形態を実装する例示的環境は、少なくとも1つのプロセシングシステム202を含むコンピューティングシステム200の形の汎用コンピューティング装置を含む。様々なプロセシングユニットが、様々なメーカー(たとえば、Intel（登録商標）やAdvanced Micro Devices（登録商標）)から入手可能である。コンピューティングシステム200はさらに、システムメモリ204と、システムメモリ204を含む様々なシステムコンポーネントをプロセシングユニット202に接続するシステムバス206とを含む。システムバス206は、様々な種類があるバス構造のいずれであってもよく、たとえば、メモリバス(メモリコントローラ)、ペリフェラルバス、または様々なバスアーキテクチャを任意に用いるローカルバスであってもよい。
【００１９】
システムメモリ204は、読み出し専用メモリ(ROM)208およびランダムアクセスメモリ(RAM)210を含むことが好ましい。起動時などにコンピュータシステム200内の要素間の情報転送を支援する基本ルーチンを含む基本入出力システム212(BIOS)が、通常はROM 208に格納される。
【００２０】
コンピューティングシステム200はさらに、ハードディスク(図示せず)の読み書きを行うハードディスクドライブ213、および/またはコンパクトフラッシュ（登録商標）カード214などの二次記憶装置を含むことが好ましい。
【００２１】
ハードディスクドライブ213およびコンパクトフラッシュ（登録商標）カード214は、それぞれ、ハードディスクドライブインターフェース220およびコンパクトフラッシュ（登録商標）カードインターフェース222によって、システムバス206に接続される。これらのドライブおよびカードと、これらに対応するコンピュータ可読媒体とは、コンピュータ可読命令、データ構造体、プログラムモジュール、および他のコンピューティングシステム200用データの不揮発性記憶装置を提供する。
【００２２】
ここに記載した例示的環境は、ハードディスクドライブ213およびコンパクトフラッシュ（登録商標）カード214を採用しているが、当業者であれば、データ記憶が可能な他のタイプのコンピュータ可読媒体もこの例示的システムに使用できることが理解されよう。そのような他のタイプのコンピュータ可読媒体として、たとえば、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイカートリッジ、CD-ROM、DVD-ROM、ランダムアクセスメモリ(RAM)、読み出し専用メモリ(ROM)などがある。
【００２３】
ハードディスク213、コンパクトフラッシュ（登録商標）カード214、ROM 208、またはRAM 210には、オペレーティングシステム226、1つまたは複数のアプリケーションプログラム228、他のプログラムモジュール230、プログラムデータ232などを含む多数のプログラムモジュールを記憶させることが可能である。ユーザは、入力装置234からコンピューティングシステム200にコマンドおよび情報を入力することが可能である。入力装置としては、たとえば、キーボード、マウス、マイク、ジョイスティック、ゲームパッド、パラボラアンテナ、スキャナ、デジタルカメラ、タッチスクリーン、電話などがある。これらおよび他の入力装置は、多くの場合、システムバス206に接続されたインターフェース240を介してプロセシングユニット202に接続される。これらの入力装置はまた、任意の数のインターフェース(パラレルポート、シリアルポート、ゲームポート、またはユニバーサルシリアルバス(USB)など)によって接続されることも可能である。モニタまたはタッチスクリーンLCDパネルなどの表示装置242も、ビデオアダプタ244などのインターフェースを介してシステムバス206に接続される。表示装置242は、内蔵であっても外付けであってもよい。一般にコンピューティングシステムは、表示装置242のほかに、スピーカ、プリンタ、手のひらサイズの装置など、他のペリフェラル装置(図示せず)を含むのが普通である。
【００２４】
コンピューティングシステム200は、LANネットワーキング環境で使用される場合には、ネットワークインターフェースまたはアダプタ252を介してローカルネットワークに接続される。インターネットのようなWANネットワーキング環境で使用される場合には、コンピューティングシステム200は、一般に、ワイドエリアネットワーク経由の通信を確立するために、モデム254または他の手段(直接接続など)を含む。モデム254は、内蔵でも外付けでもよく、インターフェース240を介してシステムバス206に接続される。ネットワーク環境では、コンピューティングシステム200に関連して図示されているプログラムモジュールまたはその一部は、リモートメモリ記憶装置に記憶されてもよい。図示されたネットワーク接続は例示的であって、コンピューティングシステム間の通信リンクを確立する他の手段も使用可能であることを理解されたい。
【００２５】
コンピューティングシステム200は、メモリ204に接続された録音機260を含むことも可能である。録音機260は、音声入力を受け取るマイクを含み、音声入力をバファリングおよび格納するメモリ204と通信している。録音機260はまた、マイクを有効にし、音声入力をメモリ204に伝送する録音ボタン261を含むことが好ましい。
【００２６】
コンピューティングシステム200のようなコンピューティング装置は、一般に、少なくとも何らかの形のコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピューティングシステム200からのアクセスが可能な任意の媒体でよい。コンピュータ可読媒体としては、たとえば、コンピュータ記憶媒体と通信媒体とがあるが、これらに限定されない。
【００２７】
コンピュータ記憶媒体には、コンピュータ可読命令、データ構造体、プログラムモジュール、または他のデータのような情報を記憶するために、任意の方法または技術で実装された、揮発性および不揮発性、リムーバブルおよび非リムーバブルの媒体が含まれる。コンピュータ記憶媒体としては、RAM、ROM、EEPROM、フラッシュメモリ、または他のメモリ技術、CD-ROM、デジタル多用途ディスク(DVD)、または他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、または他の磁気記憶装置、または所望の情報を記憶するために用いることが可能であってコンピューティングシステム200からのアクセスが可能な他の任意の媒体があるが、これらに限定されない。
【００２８】
通信媒体は、一般に、コンピュータ可読命令、データ構造体、プログラムモジュール、または他のデータを、搬送波などの変調データ信号、または他の伝送メカニズムの形で具体化すると共に、任意の情報配信媒体を含む。「変調データ信号」という用語は、信号の特性の1つまたは複数が、信号が情報にコード化されるように、設定または変更された信号を意味する。通信媒体としては、たとえば、有線ネットワークまたは直接有線接続のような有線媒体や、音響、RF、赤外線、その他の無線媒体などの無線媒体があるが、これらに限定されない。以上のものの任意の組み合わせも、コンピュータ可読媒体の範囲に含まれる。コンピュータ可読媒体は、コンピュータプログラム製品と呼ばれる場合もある。
【００２９】
図3は、ソフトウェアツールおよび開発ツールを含むことが可能な開発システム300を示すブロック図である。開発システム300は、製品(たとえば、自動車)の開発における3つの基本タイプのコンポーネントを含む。ブロック310は、要件コンポーネントである。製品およびシステムの開発の第1ステップでは、要件コンポーネントを使用する。要件コンポーネントは、製品およびシステムに含める内容を定義する。ブロック320は、設計コンポーネントである。製品およびシステムの要件を決定した後、それらの要件を満たすように、製品およびシステムの設計を行う。ブロック330は、実装コンポーネントである。製品およびシステムを設計した後、その設計コンポーネントに従って製品およびシステムを製造し、サービスに投入する。システムはまた、サプライ/サービスチェーン統合のためのエンタープライズアプリケーションを含むことも可能である。さらにシステムは、通信およびオペレーションのインフラストラクチャと自動車とを含むランタイムアプリケーションサービスを含むことも可能である。
【００３０】
自動車を例にとると、自動車メーカーは、学習モデルベースライフサイクル診断のシステムによって、新型のXカーを作ることを決定する。ブロック310で、Xカーおよびシステムの要件を決定する。たとえば、Xカーは、特定の積載量、加速性能を有するセダンであって、$20,000を超えてはならないと決定する。システムは、保証修理コストを低減し、顧客満足度を向上させなければならない。
【００３１】
ブロック320で、それらの要件に従って、Xカーおよびシステムを設計する。Xカーのフレームおよびサスペンションは、要求積載量を運搬できるように設計され、パワートレーンは、車両の全体重量と加速性能要件とに基づいて設計または選択され、Xカーの残りの部分は、$20,000を超えないように設計される。たとえば、エンジニアは、Xカーが$20,000を超えてはならないことを認識して、加速性能要件をかろうじて満たすエンジンを選択し、その加速性能を大きく超えるエンジンを選択しようとしない。システムは、自動車内に埋め込まれたサーバ、テレマティックス、および電子回路からなる3層アーキテクチャ上で動作するように、埋め込みWebプラットフォームによるWebサービスを用いて設計されることが可能である。システムは、サプライ/サービスチェーンの全体にわたってサーバを配置することを可能にするために、分散データベースを有することが可能である。システムは、開発ツール、製造ツール、およびサービスツールを含むことが可能である。
【００３２】
ブロック330で、Xカーおよびシステムを実装する。すなわち、設計に従って、製造し、サービスに投入する。実装では、サプライ/サービスチェーンの3層アーキテクチャの全体にわたってソフトウェアおよびハードウェアを配備する。
【００３３】
一般には、製品およびシステムの開発、製造、およびサービスを含む、製品およびシステムのライフサイクルの各ステップで、ソフトウェアが利用される。自動車およびシステムの要件管理(RM)プロセスでは、サプライ/サービスチェーン内の人々の間のコラボレーションを容易にするツールが必要である。現時点では、要件管理(RM)ソフトウェアは、人々が作成および収集した情報に基づく、モデルドリブンのオブジェクト指向(OO)ツールを用いる。RMは、それに入力された情報に依存するので、限界がある。したがって、このような典型的なRMツールは、柔軟性に欠け、人間の介入なしで自律的にエラーを認識することができない。RMツールの中には、エラーを学習および認識する能力をRMツールに与える知識エージェントをベースとするものもある。そのようなRMツールでも、柔軟性には欠ける。
【００３４】
要件ステップでは、分析対象の製品およびシステムのタイプを決定し、次いで、開発、製造、およびサービスに必要なツールおよびプロセスを決定する、2つのクラスの知識問題がある。これら2つのクラスの問題は、「従順型(tame)」問題と「厄介型(wicked)」問題とを含む。ほとんどの問題は、従順型であって、ステージゲートの線形プロセスと情報ベースのツールとによって解決可能である。システムが厄介型問題を扱う場合の要件を開発するには、スパイラルプロセスと知識ベースのツールが必要である。
【００３５】
厄介型問題は、いくつかのイシューおよび制約がリンクされたセットで構成され、問題自体の明示的なステートメントを有しない。この問題(および、したがって、解決策を設計するための要件)は、解決策の候補を表現する反復プロトタイプが開発されるまで、適切に理解することができない。一次の全体開発プロセス(これは線形プロセス)の中に、反復プロトタイプのための二次のスパイラルプロセスが必要である。スパイラルプロセスは、ソフトウェアの一部分を、別の部分が開発されている間に、一度に「ロールアウトする」ことを伴う。ソフトウェアエンジニアリングの世界では、迅速かつ効果的な開発にはスパイラルプロセスが不可欠であることが認識されている。
【００３６】
自動車と、その自動車の診断の設計は、厄介型問題の一例である。「厄介型(wicked)」という用語は、1970年にHorst Rittelによって導入された。Rittelは、この新しいクラスの問題の解決を支援するために、イシューベース情報システム(IBIS)と呼ばれる技術を発明した。厄介型問題は、構造があいまいな問題と非常によく似ているように見えるが、その問題に対する意見が異なる可能性のある多くのステークホルダを有する。厄介型問題は、スパイラル反復プロセスを用いて分析されなければならず、問題に関連する要件などのアイデアを、図4に示す新しいパラダイム400とリンクする必要がある。
【００３７】
図4に示すように、重要な3つのIBISエンティティとして、(1)イシュー402、403、404(質問)、(2)イシューの可能な解決策または説明を提供するポジション405、406、408(アイデア)、および(3)アーギュメント410、412(賛否両論)がある。これら3つのエンティティはすべて、supports、objects-to、is - suggested - by、responds to、generalizes、specializes、replaces、その他のような関係(relationship)によってリンクされることが可能である。IBISは、グラフまたはネットワークの形で可視化される。IBISは、設計と議論とをつなぐ橋、あるいは、知識管理のコアを形成するアイデアが表現された対話を構築する。
【００３８】
IBISは、文法、すなわち、アーギュメントマッピングの形式を有する、グラフィカルな言語である。IBISを適用するためには、実験計画法(design of experiments)(DOE)と同様にスキルが必要である。Jeffrey Conklin(http://cognexus.org/idl7.htm)は、グラフィカルIBIS(gIBIS)を導入することにより、グラフィカルハイパーテキストビューのIBIS構造への応用を開拓した。Conklinによれば、IBISの強みは、次の3つの特性に由来する。(1)IBISは、複雑な考えを、分析的な構造化図にマッピングする。(2)IBISは、知識の基盤を形成する質問をエクスポーズする。(3)IBIS図は、他の形式の情報より、はるかに理解しやすい。
【００３９】
Compsim LLCは、いくつかの点でIBISを拡張したものである。そのIBISツールアーキテクチャにおいては、アイデアを、テキストアウトラインの形でも、ノードのツリー構造の形でも明示することが可能である。所与のレベルのアイデアに、アイデアの表示順序を変更するための優先度および重みを持たせることが可能である。優先度は、様々なグラフィカルな方法で容易に編集できる。ユニークな意志決定メカニズムが、賛否の議論に応じた相対的な加算および減算によって、人間の思考を模倣する。IBIS論理は、XML定義としてキャプチャされ、知識ベースエージェントネットワークがリンクされたネットワークを構築するために用いられる。Compsimは、このエージェント構造を知識エンハンスト電子論理(knowledge enhanced electronic logic)(KEEL)と呼んでいる。エージェントは、IBIS論理の拡張形式を実行する。
【００４０】
IBISが含まれる現在の分野は、コンピュータ支援アーギュメント可視化(computer-supported argument visualization)(CSAV)と呼ばれる。CSAVを適用する関連分野は、インターネットの誕生を支援した、コンピュータ支援共同作業(computer-supported cooperative work)(CSCW)およびコンピュータ媒介コミュニケーション(computer-mediated communication)(CMC)である。CMCツールには、Microsoft（登録商標）のNetMeeting(商標)製品が含まれる。
【００４１】
知識管理(KM)のサブセットである要件管理において見られる複雑な関係を定義するための重要な技術が、アーギュメント可視化である。KMの原理の1つが、構成的学習理論(constructivist learning theory)において見られ、これは、共同的対話(collaborative dialog)を介しての交渉による知識の構築を必要とする。交渉は、アイデアの比較試験を伴う。アイデアの可視化による通信対話では、情報に直接リンクした、知識の明示的部分とは対照的な、知識の大部分を占める暗黙の知識が作成される。暗黙の知識は、共通の理解に不可欠である。
【００４２】
IBISは、知識ベースの技術である。Compenium(商標)やQuestMap(商標)(GDSS, Inc.の商標)のような、要件管理用のIBISツールは、TelelogicsのDoors(商標)やIBMのRequisite-Pro(商標)のような、RM用のオブジェクト指向(OO)フレームワークツールとは明らかに異なる。厄介型問題は、解決すべき問題またはイシューに対して、すべてのステークホルダが同意するような定義を行うことが容易ではない。RMツールを用いるOOフレームワークには、表現しにくいトレードオフがある。IBISでは、2項の状況シナリオを用いて要件を定義することが可能である。また、IBISでは、要件のシミュレーションを行うことが可能である。IBISは、それらの状況を検知して、どの要件セットが適切か、あるいは、その要件が状況に一様に十分に当てはまるかどうかを決定することが可能である。
【００４３】
つまり、現在のRMツールには限界がある。OO RMツールは、開発時においては、要件、設計、および実装の間の追跡可能性が有効であるが、製造またはサービス配備のフェーズにおいては有効ではない。OO RMツールは、知識ベースではないため、議論の賛否両論として表現される複数のステークホルダの意見が、それらの意見の優先順位が様々であることから対立する、構造があいまいな厄介型問題を扱うことが容易ではない。IBIS RMツールは、それらの限界のほとんどを克服するが、システム設計に対する追跡可能要件を開発しない。
【００４４】
OO RMツールおよびIBIS RMツールはともに、関連付けられた階層によるアウトラインのような補助的構造を持たない、テキストだけで表現されたアイデア間関係が明確ではないことを認識している。ハイパーテキスト技術によって可能になったようなネットワーク構造は、Vannevar Bush、ならびに彼の1945年の記事「As We May Think」までさかのぼることができる。1962年、Douglas Englebartは、Stanford Research Institute, Augmenting Human Intellect: A Conceptual Frameworkにおける報告で、ツールを用いる認知強化用フレームワークを定義した。Englebartの研究開発作業の成果は、近代的なウィンドウ、アイコン、マウス、ポインタ(WIMPT)によるグラフィカルユーザインターフェース(GUI)の開発、ならびにハイパーテキストベースのツールの初期実装の開発であった。
【００４５】
OOのラウンドトリップエンジニアリング(モデルドリブンのソフトウェア開発)は、設計および要件の要素までさかのぼることが可能な実装用ソースコードである。ラウンドトリップは、要件、設計、およびソースコードである実装の間で行われてから、設計および要件に戻る。現在のラウンドトリップエンジニアリングは、開発時にのみ、そしてIDEの特定のセグメントの中でのみ行われるため、開発後にRTE内で発生したモデルエラーについては、要件、設計、または実装における根本原因までさかのぼることができない。セグメント化されたIDEは、4つの象限からなる。これらの象限は、(1)システム内のエンタープライズアプリケーション、(2)自動車用埋め込みソフトウェア、(3)自動車用テレマティックス、および(4)自動車用サービスシステムのための方法およびツールを含む。
【００４６】
OOモデルは、しばしば、統一モデリング言語(UML)を用いて定義される。UMLは、第3世代のOOグラフィカルモデリング言語である。システムモデルは、ユースケースにおいて定義されるように、アクタと呼ばれる外部ユーザと相互作用を行う構造的側面、挙動的側面、および機能的側面を有する。ユースケースは、システムの名前付き機能である。システム要件は、一般に、2つのカテゴリ、すなわち、機能的要件と非機能的要件(またはサービス品質(QoS)要件)とに分類される。
【００４７】
「機能的」は、システムが何を行うかを意味する。QoSは、どのようにうまく行うか、すなわち、機能の性能属性を意味する。一般的な使い方では、「機能的」は、機能と性能の両方の意味を含むことが可能である。構造的側面は、オブジェクトと、ランタイムに存在しうるオブジェクト関係とを定義する。サブシステム、パッケージ、およびコンポーネントも、オプションの構造的側面を定義する。挙動的側面は、ランタイムシステムにおいて構造的要素がどのように動作するかを定義する。UMLは、アクションおよび可能なシーケンスを指定するために、状態チャート(有限状態機械の正式表現)およびアクティビティ図を提供する。アクティビティチャートの一般的な用途は、計算アルゴリズムを指定することである。構造的要素の集合は、相互作用と一体で長期にわたって機能する。相互作用は、シーケンス図またはコラボレーション図の形で定義される。
【００４８】
機能的側面およびQoS側面からなるシステム要件は、一般に、次の2つの形のいずれかまたは両方としてキャプチャされる。(1)状態チャートおよび相互作用図で定義される詳細要件を有するユースケースであるモデル。(2)システム挙動のありうるすべてのシナリオを定義しようとする、テキストによる仕様(シーケンス図のような正式図はあってもなくてもよい)。
【００４９】
ラウンドトリップエンジニアリングでは、OO設計から、ソフトウェア用OOソースコードを含むOO実装まで、OO要件を追跡する。このラウンドトリップは、IDEの特定のセグメント(すなわち、OO IDEセグメント)においてのみ、そして開発時にのみ行われる。現在では、開発時、製造時、およびサービス時のRTEとIDEとの間にラウンドトリップ追跡可能性がない。ラウンドトリップエンジニアリングは、目障りなソースコードマーカを必要とせずにメタモデルを用いるよう拡張されているが、拡張されたラウンドトリップエンジニアリングもやはり、開発時にIDEの特定セグメントでのみ行われる。
【００５０】
モデルベース診断は、最先端の欠陥隔離方法であって、自動車およびシステムの実装モデルの一部として指定された動作パラメータに従う動作特性ではない、自動車およびシステムの1つまたは複数の欠陥コンポーネントを識別するプロセスである。モデルベース診断は、モデルにエラーがなく、システムのすべての動作シナリオをモデルが正確に表現することを前提としている点で限界がある。システムの動作シナリオには、予想されるすべての欠陥が含まれる。
【００５１】
ランタイムにおいて十分な量の目に見える情報が自動車から得られるのであれば、モデルベース診断により、正常モードおよび故障モードを含む拡張モデルによって予測される既知の故障モードおよび想定される故障モードについては、根本原因を決定することが可能である。この拡張モデルを使用して、可能性があるすべての単一コンポーネント故障、したがって複数のコンポーネント故障の組み合わせの結果である挙動をシミュレートして記録する。故障挙動が観察された場合は、所定の実験のシーケンスを実施して、根本原因を決定することが可能である。
【００５２】
自動車およびシステムの要件または設計モデルおよび実装モデルにおける欠陥は、主に開発後に、ユーザが苦情を言い、その苦情をサービス技術者が分析し、場合によってはエンジニアが分析することによって検出される。苦情につながる状況は、多くの場合、識別されにくく、再現しにくい。一般に、欠陥隔離または根本原因決定のプロセスでは、まず、異常なシステム挙動を検出し、欠陥があって動作が正常でない1つまたは複数のコンポーネントを識別することを試みる。これらのコンポーネントは、システムの機能の何らかの集合を実施する。各コンポーネントは、ソフトウェアを含むことが可能である、現場交換可能なハードウェアユニットとして設計されることが多い。しかしながら、現在の実用で前提にされている故障モデルは、交換可能コンポーネントの機能的故障モードを想定しており、1つまたは複数のコンポーネント内部の故障がハードウェアの故障なのかソフトウェアの故障なのかを決定しない。故障がソフトウェア内の故障であれば、その故障は、要件、設計、または実装のレベルのモデル故障である。ハードウェア1つまたは複数のコンポーネントを交換しても、問題は修復されない。
【００５３】
一例示的実施形態では、ハードウェア故障、あるいは、要件、設計、または実装におけるモデルエラーによって引き起こされる、自動車の機能的サブシステムにおけるライフサイクル故障を検出し、その故障をモデル内の根本原因までさかのぼって追跡する、改良された方法およびシステムを企図する。追跡に関しては、この方法は、自動車の機能および対応する診断の開発および保守を管理するために、RTE内の診断エージェントとIDE内の2項モデルとをリンクする、ライフサイクルラウンドトリップエンジニアリングの新しい機能を用いる。IDE内の2項モデルは、スパイラル開発「V」プロセス(後で詳述する)の各レベル(すなわち、要件、設計、および実装)において機能および対応する診断を開発する、リンクされた2項ツールによって管理される。IDEとRTEとをリンクする、このライフサイクル診断方法は、自動車RTEの開発時、製造時、およびサービス時に適用可能である。
【００５４】
図5および6に、学習モデルベースライフサイクル診断システム499を示す。システム499は、DRDリンク599によってリンクされたIDE 500およびRTE 600を含むことが好ましい。図5は、IDE 500における自動車の機能および対応する診断の開発と、自動車をサービスするRTE 600における診断の配備とに対する、一例示的実施形態によるライフサイクル診断方法のシステム図である。この図は、ライフサイクル法が、IDE 500内の開発ツール同士をどのようにリンクするかをリンケージで示している。ライフサイクル法におけるIDE 500は、自動車の機能と、RTE 600に配備するための統合およびリンクされた一連の診断エージェントからなる、自動車の機能と対応する診断アプリケーションとを開発する開発ツールおよびプロセスを含む。IDE 500とRTE 600とは、DRDリンク599および対応するプロセスを介してリンクされる。DRD 599は、分散データベースであってよいデータベースを含むことが可能である。
【００５５】
図6は、IDE 500における診断の開発と、自動車をサービスするRTE 600における診断の配備とに対する、一例示的実施形態によるライフサイクル診断方法のシステム図である。この図は、ライフサイクル法が、RTE 600内の診断エージェント同士をどのようにリンクするかをリンケージで示している。ライフサイクル法におけるRTE 600は、サーバ上で動作する診断エージェント、TCU (自動車にプラグインされる等価モジュール)、およびECUからなる3レベルシステムとして配備される診断アプリケーションを含み、動作させる。製造サービスツールは、自動車とインターフェースされ、RTE 600の一部をなす。RTE 600は、DRDリンク599および対応するプロセスを介してIDE 500とリンクされる。
【００５６】
図7に示すように、Compsim KEELツールキットのようなIDEツールは、設計モデルをシミュレートおよびテストし、故障モードを分析するために、DRDリンク499(図5)で返されるデータによって駆動されることが可能である。次に示すデータは、IDE 500(図5)によってXMLで定義された入力スキーマの一例であり、このスキーマはDRDリンク599に格納される。
【００５７】
【表１】
2008517386.tif 000002
【００５８】
DRD リンク599により、RTEエージェント600は、IDE 500内のツールと通信する方法を知らなくてもよい。システム499は、DRDリンク599内の情報だけを用いて、IDE 500とRTE 600との間の適正なリンケージを作成する。RTE 600からIDE 500に返るデータの一例を次に示す。
【００５９】
【表２】
2008517386.tif 000003
【００６０】
図5に戻ると、好ましくは、IDE 500には、システム499のユーザのための3レベルの開発アクティビティと、対応するツールおよびプロセスとがある。これら3つのレベルは、要件管理、設計、および実装である。システム499は、IDE 500の各レベルにおける機能および診断のための、リンクされた2項ツールペアを作成する。
【００６１】
図5の最上位は、要件管理と呼ばれるアクティビティである。要件管理(RM)のための代表的なモデルドリブンのオブジェクト指向(OO)開発ツールは、IBM/Rational Requisite Pro(商標)およびTelelogic DOORS(商標)である。ライフサイクル法は、Compsim Management Tool(商標)(CMT)のようなイシューベース情報(IBIS)ツールによって既存のOO RMツールを強化することにより、RM向けの新しい2項機能を作成する。
【００６２】
IDE 500は、第1のRM 502と、第2のRM 504と、第1の設計ツール506と、第2の設計ツール508と、第3の設計ツール510と、第1の配備ツール512と、第2の配備ツール514と、第3の配備ツール516とを含む。第1のRM 502はOO RMツールとして実装され、第2のRM 504はIBIS RMツールとして実装されることが好ましい。第1の設計ツール506は、IBM/Rational Rose(商標)、iLogix's Rhapsody(商標)、MathWorksのSimulink(商標)、またはETASのASCET/SD(商標)のような、OOモデルドリブン機能設計ツールとして実装される。
【００６３】
第2の設計ツール508は、知識ベース診断設計ツールとして実装される。第3の設計ツール510は、モデルベース診断設計ツールとして実装される。第2の設計ツール508および第3の設計ツール510は、知識ベース診断設計ツールおよびモデルベース診断設計ツールの両方を含む診断ビルダツールスイートを含む。これらのツールは、システム499のユーザが、対応して設計された自動車機能に対するランタイム診断エージェントを開発することを可能にする。診断エージェントは、RTE 600(図6)の3つのレベルで動作することを意図されたものである。診断ビルダスイートは、各診断エージェントごとの、RTE 600のターゲットレベルを指定し、図6に示された、RTE 600内のエージェント間のリンクを構築する。知識ベースエージェントの開発ツールの一例は、CompsimのKEEL(商標)である。モデルベースエージェントの開発ツールの一例は、R.O.S.E.のRodon(商標)である。
【００６４】
第1の配備ツール512は、ASCET/SD(商標)のような、ソフトウェア機能コードの生成ツール、管理ツール、および配備ツールとして実装される。第2の配備ツール514は、ソフトウェア診断コードの生成ツール、管理ツール、および配備ツールとして実装される。そして、第3の配備ツール516は、ソフトウェア診断コードの生成ツール、管理ツール、および配備ツールとして実装される。
【００６５】
第1のRM 502は、リンク518を介して、第2のRM 504とリンクされる。リンク518は、当該技術分野で既知の任意の標準的な通信リンクである。リンク518は、第1のRM 502にキャプチャされた要件の背後の知識、仮定、および決定論理をキャプチャすることを可能にする、双方向の統合リンクである。好ましくは、システム499は、第1のRM 502内のオブジェクトに関する一意のXML機能識別記述子(FID-RM)を第2のRM 504に渡すことと、XML診断識別記述子(DID-RM)を用いてデータ関係を構築することとによって、リンク518を実装する。リンク518のための2項関係は、DRDリンク599に格納される。システム499は、第2のRM 504を第1のRM 502のグラフィカルユーザインターフェース内のウィンドウにすることにより、ユーザが、第1のRM 502内のオブジェクト(ユースケースなど)としてキャプチャされた要件の背後の決定論理を定義することを可能にする。第1のRM 502内のオブジェクトに対応する、第2のRM 504内の論理は、一意のXML診断識別記述子(DID)として定義される。
【００６６】
第1の設計ツール506は、リンク520を介して、第2および第3の設計ツール508、510にリンクされる。リンク520は、XMLで定義された一意の設計用(-D)機能識別記述子および設計用(-D)診断識別記述子を双方向でやりとりし、別々のツールのグラフィカルユーザインターフェースを設計レベルで統合する。
【００６７】
第1の配備ツール512(機能モジュール)は、リンク522を介して、第2および第3の配備ツール514、516(診断エージェント)とリンクされる。リンク522は、XMLで定義された一意の実装用(-I)機能識別記述子および実装用(-I)診断識別記述子を双方向でやりとりし、実装ツールのグラフィカルユーザインターフェースを統合する。リンク522は、自動車モジュールに対応する情報のECUメモリロケーションおよびデータ型を定義することによって実装される。そのようなリンクの一例が、XMLを用いるASAM MCD(商標)である。リンク522を実装するために、ETASのASCET/SD(商標)およびINCA(商標)のようなツールを用いることが可能である。
【００６８】
第1のRM 502はさらに、リンク524を介して、第1の設計ツール506にリンクされる。第1の設計ツール506はさらに、実装のために、リンク526を介して、第1の配備ツール512にリンクされる。リンク524、526は、開発環境における、機能のいわゆるラウンドトリップエンジニアリングを可能にする。要件に対応するオブジェクトは、設計から実装のソースコードまで、ならびに設計および要件までさかのぼって追跡されることが可能である。
【００６９】
同様に、第2のRMツール504は、第2および第3の設計ツール508、510に、それぞれリンク528、530を介してリンクされる。第2および第3の設計ツール508、510は、第2および第3の配備ツール514、516に、それぞれリンク532、534を介してリンクされる。リンク532、534は、開発環境における、診断のラウンドトリップエンジニアリングを可能にする。XMLで定義された、診断用の設計オブジェクトは、診断用のソースコードにリンクされる。
【００７０】
システム499は、RTE 600(図6)に実装する、リアルタイムオペレーティングシステムで実行可能なコードを生成するために、ソースコードを生成するモデルベース診断設計ツール(R.O.S.EのRodon(商標)など)を、ASCET/SD(商標)などのツールと統合する。
【００７１】
図6に示すように、RTE 600は、3つのレベルのソフトウェアおよびハードウェアを有する。システム499は、IDE 500内のツール、DRDリンク599、およびプロセスを用いて、診断アプリケーションを、その3つのレベルで動作する、リンクされた診断エージェントの集合として構築することを可能にする。いくつかのエージェントは、OSGi(商標)を用いてレベル2にダウンロードすることが可能である。
【００７２】
RTE 600は、第1のデータベース602と、サーバアプリケーション604と、第2のデータベース606と、ブローカ608と、電子制御ユニット(ECU)610と、学習エージェント612と、エージェント614とを含む。第1のデータベース602は、当該技術分野において知られている埋め込み分散データベースであることが好ましい。サーバアプリケーション604は、サーバ診断ソフトウェアアプリケーションと、KBDモジュールのメッシュネットワークである。第2のデータベース606は、埋め込み分散データベースである。ブローカ608は、診断エージェントおよびデータのKBDバンドルを管理する。ECU 610は、ソフトウェアと、ECUに接続された他のハードウェアとを含む。学習エージェント612は、ソフトウェアの学習モデルベース診断エージェントとECU内のデータとを含む。エージェント614は、ソフトウェアのモデルベース診断(MBD)エージェントとECU内のデータとを含む。
【００７３】
第1のデータベース602は、リンク616を介して、サーバアプリケーション604にリンクされる。第2のデータベース606は、リンク618を介して、ブローカ608にリンクされる。ECU 610は、リンク620を介して、学習エージェント612およびエージェント614にリンクされる。サーバアプリケーション604はさらに、リンク622を介して、ブローカ608にリンクされる。ブローカ608は、リンク624を介して、学習エージェント612およびエージェント614にリンクされる。
【００７４】
IDE 500とRTE 600とは、リンク599を介してリンクされる。リンク599は、開発(Development)、ランタイム(Run-time)、開発(Development)(DRD)リンクである。DRDリンク599は、通信およびオペレーションのインフラストラクチャ(TOI)を用いて実装されるのが好ましく、TOIは、分散データベースとソフトウェアプロセス間通信(IPC)メカニズムとの組み合わせを含む。DRDリンク599では、データベースまたはIPCメカニズムを通して送られる情報が、XMLスキーマによって定義され、IDE 500データとRTE 600データの両方を含む。XMLスキーマは、メッセージの形で送られることが可能であり、オプションで、分散データベースを構成するために用いられることが可能である。
【００７５】
開発時には、要件、設計、および実装の各レベルにおいて、機能識別記述子(FID)によって一意識別される機能と、対応する、診断識別記述子(DID)によって一意識別される診断との間にIDEモデルリンケージ(後で詳述する)を構築するために、IDE 500の新しい診断ツールにより、ユーザが、スパイラル「V」プロセスを「V」の「ダウン」方向または「アップ」方向にたどるように誘導される。FIDおよびDIDによるIDE 2項(機能-診断)モデルリンケージは、DRDリンク599データベースに格納される。
【００７６】
本方法が開発時に反復プロトタイピングサイクルにわたってスパイラル「V」プロセスをたどる結果として、IDE 500とDRDリンクデータベース599とに新しい2項システムモデルが構築される。RTE 600は、自動車に対しても構築される。RTE 600は、3層レベルの診断エージェントを含み、これらのエージェントは、互いにリンクされて統合診断アプリケーションアーキテクチャ(DAA)を構成し、また、対応する較正パラメータがECUにあるソフトウェアを含む自動車機能にもリンクされる。
【００７７】
3層のRTE 600は、自動車のTCU または自動車サービスモジュール(VSM)にエージェントをダウンロードするなど、エージェント612、614を自動車に動的に配備するために、サーバ604上にマネージャを含み、TCU 上にブローカ608を含む。
【００７８】
RTE 600では、ソフトウェアオブジェクト間のランタイムリンケージまたはランタイムバインディングが、エージェントマネージャおよびブローカによって、IDEで定義されたXMLスキーマ、ならびにDRDリンク599に含まれるFIDやDIDなどのデータを用いて実行される。これにより、エージェント同士をリンクすること、ならびにエージェントと機能とをリンクすることが可能になる。
【００７９】
このリンクすることの一例は、診断エージェントを、エンジンのECUにある較正パラメータに接続することである。UMLを用いるIDE 500では、これらの接続がさらにポートおよびプロトコルを含む場合がある。Association for Standardization of Automation and Measurement (ASAM)に準拠するIDE 500およびRTE 600では、自動車内のECUに関連する測定、較正、および診断(MCD)のための追加アクセス方法が定義される。これらのアクセス方法も、DRDリンク599に含まれ、埋め込みデータを有するXMLスキーマとして表現される。
【００８０】
図8を参照すると、ライフサイクル診断方法が、分散システム880において自動車を管理する。この分散システムは、データベース881と、サーバ882と、自動車884と、開発、製造、およびサービスのための各ツール886、888、890と、自動車内部のモジュール(TCU 892およびECU 894など)を含む。この方法がシステムを定義するために用いるアーキテクチャは、ISOの開放型システム間相互接続(OSI)7層参照モデルであることが好ましい。これらの層は、アプリケーション層、プレゼンテーション層、セッション層、トランスポート層、ネットワーク層、データリンク層、および物理層である。DAAは、ノードの7層「スタック」の上位3層を含み、TOIは、スタックの下位4層を含む。
【００８１】
根本原因の追跡は、自動車RTE 600(図6)で検出された故障を図5のIDE 500にあるモデルの要素とリンクするライフサイクルラウンドトリップエンジニアリングによって行われる。このリンケージは、データベースに格納されたIDE 500リンケージを用いることによって実装される。IDE 500内のツールにより構築されたリンケージを追跡することにより、要件、設計、および実装にある根本原因の候補を決定することが可能である。
【００８２】
自動車RTE 600(図6)にある、協調すると共に自律的な診断エージェントによる、故障の可能性検出によって、スパイラルライフサイクルプロセスがトリガされる。これらのエージェントは、いくつかのカテゴリ(モデルベース診断(MBD)、学習モデルベース診断(LMBD)、または知識ベース診断(KBD))に分類され得る、一連のアルゴリズムおよび技術を適用する。現在あるOBD診断エージェントは、受容可能なタイプ1およびタイプ2統計的エラープロファイルを設計するために、指数平滑移動平均(一次カルマンフィルタ)をしばしば適用するMBDを使用する。
【００８３】
トリガは、自動車RTE 600(図6)に接続されたサービスツールによって支援されることが可能である。このトリガは、メッセージまたは分散データベースを通して、情報を、1つまたは複数のサーバで動作している、自動車の診断アプリケーションに送る。自動車からサーバへのメッセージまたはデータベースのトランザクションは、ECUで動作しているMBDおよびLMBDエージェントの組み合わせと、TCU で動作しているMBD、LMBD、およびKBDエージェントの組み合わせとから情報が供給された後に、自動車のTCU によって作成される。
【００８４】
LMBDエージェントは、信号を故障としてフィルタリングおよび検出する場合に(エラーがある)モデルを用いることを避けるために、時間-周波数ベースの性能評価技術を適用することが可能である。時間-周波数解析(TFA)は、システムの正常な挙動を表す信号または信号セットの、時間と周波数を組み合わせた表現を管理する方法を提供する。挙動は、時間および周波数に対して変化する可能性がある。TFAは、ゆっくりの劣化と突然の故障の両方を検出する方法である。新しく開発されたTFA方法は、時系列解析やスペクトル解析では困難または不可能な形でシステムのシグネチャの挙動を識別することが可能である。TFAのための最適な設計方法は、干渉分布低減(Reduced Interference Distribution)(RID)を含む。高分解能の時間-周波数表現を提供するという目標は、RID最適化によって達成される。RID TFA技術によって構築された学習MBDエージェントは、モデルを用いずに、最小処理量と、検出の工学的統計的信頼度とによって故障を非常に素早く識別するなど、所望の特性の多くを示す。
【００８５】
図5および6に戻ると、好ましくは、学習モデルベースライフサイクル診断システム499が、IDE 500と、IDE内のIDEツール間のリンケージと、RTE 600と、RTE 600内でのリンケージと、DRDリンク599とを含む。これらのリンケージは、RTE 600内のエージェントおよびツール、ならびにIDE 500内のツールとともに動作して、システムが、RTE内で検出された故障(異常)を、IDE内のモデルエラーとして、根本原因までさかのぼって追跡することを可能にする。
【００８６】
モデル故障をRTE 600からIDE 500までさかのぼって追跡するために、この方法は、RTE 600内の診断エージェントと、IDE 500内の対応する自動車機能にリンクされた診断との間でラウンドトリップエンジニアリングを実施する。機能は、オブジェクトを有するモデルとして表現される。エージェント、プロセス、ツール、およびリンケージは、自動車のライフサイクルにわたるモデルエラーを学習するために、スパイラルプロセスにおいて一緒に動作するので、この方法は、ライフサイクル学習モデルベース診断と呼ばれる。
【００８７】
IDE 500は、自動車上のソフトウェア、ならびに自動車の製造およびサービスをサポートするソフトウェアにとって、RTE 600とともにライフサイクル法の不可欠な部分である。自動車のサービスは、ディーラーにおけるサービスオペレーションと、OnStar(商標)のようなテレマティックサービスとを含む。好ましくは、RTE 600は、保有車両と、電子制御ユニット(ECU)と、ネットワークと、センサと、アクチュエータと、個々の自動車のダッシュボードにある速度計のようなユーザインターフェース装置と、通信およびオペレーションのインフラストラクチャ(TOI)とを含み、TOIは、分散サーバのようなコンピュータと、セルラおよび無線LAN(WIFIなど)のような通信ネットワークと、OEM販売代理店や独立系アフターマーケット(IAM)の修理店に一般的に置いてある診断スキャンツールのようなツールとを含む。
【００８８】
好ましくはIDE 500は、パワートレーン用電子装置(ECU、センサ、エンジンおよびトランスミッション用アクチュエータなど)、ボディ用電子装置(ECU、センサ、照明システム用アクチュエータなど)、およびシャーシ用電子装置(ECU、センサ、およびアンチロックブレーキングシステム(ABS)用アクチュエータなど)のような、自動車の諸機能を開発およびメンテナンスするための開発ツールの集合を有する、コンピュータを使用する研究室および実験運転環境である。自動車の機能は、パワートレーンのようなシステムと、対応するサブシステム(エンジン冷却など)との形で実装される。これらのシステムおよびサブシステムは、ハードウェアとソフトウェアの両方を含む。IDE 500はまた、自動車の製造およびサービスのオペレーションをサポートするエンタープライズアプリケーションソフトウェア(情報技術(IT)ソフトウェアとも呼ばれる)の開発にも用いられる。
【００８９】
自動車の機能を実装するソフトウェアは、一般に、自動車内に存在する電子制御ユニット(ECU)およびオプションのテレマティック制御ユニット(TCU )において動作する。アプリケーションソフトウェアは、サーバやPCのようなコンピュータ上で、診断スキャンツールのようなサービスツールに対して動作する。サービスオペレーション向けの自動車診断ソフトウェアの開発は、一般に、オーサリングと呼ばれる。自動車内の診断ソフトウェアは、オンボード診断(OBD)と呼ばれる。
【００９０】
IDE 500(図5)の方法で用いられるプロセスを、図9〜18に示す。これらのプロセスがたどられるにつれ、IDE 500内のリンクされたツールが、RTE 600内の診断アプリケーションおよびエージェントをIDE 500にリンクするための情報をDRD 599内に構築する。それらのエージェントは、DRD 599を読み出して、DIDとリンクされたFIDを見つける。
【００９１】
図9は、本開示の例示的実施形態による、自動車製品の開発ライフサイクル900を示すプロセス図である。自動車のライフサイクルにおける自動車の個々のモデル年度の製品開発プロセスは、概念的に、開発フェーズ902、製造フェーズ904、およびサービスフェーズ906を含む3つのフェーズに分割される。開発、製造、およびサービスの各アクティビティは、大量のソフトウェアの管理を必要とする。ソフトウェアは、自動車機能の大部分を作成し、自動車のライフサイクルをサポートするビジネス情報システムの大部分を作成する。
【００９２】
製造およびサービスのためのツールを含む、製造およびサービスの能力の開発は、開発フェーズ902の間に行われる。能力は、知識、ツール、技術、およびプロセスを有する人員として定義される。ビジネス情報システムを含む、ツールおよび技術によって表される能力の構造を表す関連アーキテクチャがある。ビジネスシステム内には大量のソフトウェアがある。関連アーキテクチャはさらに、オンボード情報システムを含む自動車(およびそのサブシステム)の構造を含む。自動車にはさらに、オンボード診断(OBD)システムがある。このOBDシステムは、大量のソフトウェアを含む。OBDシステムの一部は、自動車の排気ガス制御システムの動作を監視することによって自動車の排気ガスを間接的に監視する政府規制により必要である。一般に、自動車のパワートレーンECUには、制御ソフトウェアとほぼ同じ量の診断ソフトウェアがある。
【００９３】
自動車内の情報システムは、一般に、多くの電子制御ユニット(ECU)を含む。自動車は、一般に、50個を超えるECUを有する。これらのECUは、大量のソフトウェアを含む。自動車のアーキテクチャ、ならびにその製造およびサービスのシステムは、すべてが開発時に規定される。開発フェーズ902は、一般に、アーキテクチャの大部分が、開発フェーズ902に先行する研究開発(R&D)フェーズ(図示せず)であらかじめ決定されているところから始まる。自動車モデルのアーキテクチャモデルは、一般に、パワートレーン、シャーシボディ、および他のサブシステムコンポーネントを含むプラットフォームモデルから導出される。
【００９４】
製品開発プロセスは、自動車および製品としてのビジネスシステムの両方の開発、製造、およびサービスを可能にする。プロセスは、開発時、製造時、およびサービス時に自動車をサポートする、対応するビジネスシステムとともに動作する。
【００９５】
製品およびビジネスシステムは、組織能力の一部であるプロセスによってサポートされる。この能力は、関連アーキテクチャを有する。このアーキテクチャは、自動車とビジネスシステムの両方に関連する。能力は、人員ならびに人員の知識、アプリケーション、ツール、プラットフォーム、コンポーネント、および技術による内部サービスおよび外部(外部委託される)サービスを含む。能力は、製品としての自動車と、サプライ/サービスチェーンにおけるビジネスシステムとをサポートする。これらのチェーンは、相手先ブランド製造メーカー(OEM)および製品としての自動車をライフサイクルにわたってサポートする。
【００９６】
自動車のライフサイクルは、一般に、10年以上におよぶ。開発フェーズ902は約2〜3年であり、その後の数年が、いくつかのモデル年度のための製造フェーズ904である。製造フェーズ904の後に、何年ものサービスフェーズ906が続く。特定の自動車のサービスフェーズ906の初期は、一般に、3年以上の純正部品(OES)保証期間を含み、その後に、独立系アフターマーケット(IAM)を含むサービス期間が続く。
【００９７】
これらの開発、製造、およびサービスのフェーズ902、904、906は、時間の経過とともに順番に続くように図示されているが、この後の図面に示されるように、オーバーラップがある。製造フェーズ904は、製造開始(SOP)によって始まる。サービスフェーズ906は、自動車の最初の正式出荷(FCS)によって始まる。1つのモデル年度に対して多数の自動車が製造されるので、製造フェーズ904とサービスフェーズ906とはオーバーラップする。
【００９８】
プロセスの各フェーズ902、904、906に、RTEとIDEがある。RTEは、フェーズごとに固有である。D-RTE 908は、開発-RTEを表し、P-RTE 910は、製造RTEを表し、S-RTE 912は、サービスRTEを表す。製造ツールを有する製造工場は、P-RTE 910に含まれる。サービスツールを有する、OEMディーラーのサービス部門は、S-RTE 912に含まれる。開発ツールを有する単一のIDE 914は、すべてのフェーズに共通であって、個々のRTE 908、910、912のそれぞれにリンクされる。IDE 914は、一般に、サプライ/サービスチェーンにおいて適用され、OEMとそのビジネスパートナーにおいて適用される。個々のRTE 908、910、912は、DRDリンク916を介して、IDE 914に接続される。
【００９９】
図10は、本開示の例示的実施形態による、ライフサイクルの開発フェーズ902(図9)の間に、プロトタイプサイクルを製造するために用いられる、スパイラルライフサイクルプロセス1000を示すプロセス図である。
【０１００】
製品開発プロセスの開発フェーズ902(図9)は、スパイラルサブプロセス1000によりプロトタイプを開発するために用いられる。サブプロセス800は、開発フェーズ902の中に収まる。開発される、自動車モデルおよびそれをサポートするビジネスシステムは、要件、設計、および実装のカテゴリのコンポーネントで構成される。一般に、開発では、まず、自動車およびそれをサポートするビジネスシステムの要件モデルのいくつかの部分を決定および規定するアクティビティがあり、続いて、自動車およびそれをサポートするビジネスシステムの設計モデルのいくつかの部分を決定および規定する(これらの部分には、その開発、製造、およびサービスの各ツールを有するRTEが含まれる)。
【０１０１】
開発ツールは、一般に、設計モデルのシミュレーションをサポートする。このシミュレーションにより、自動車およびサポートシステムが完全には実装されない状態でテストを行うことが可能になる。完成車両が使用可能になる前のサブシステムの追加の開発を可能にするために、ハードウェアインザループ(HIL)またはソフトウェアインザループ(SIL)のようなシミュレーションおよびテストの機能を有する開発ツールが用いられる。開発が進むにつれ、実装モデルのいくつかの部分を決定および規定することが可能になる。スパイラルプロセスは、要件、設計、および実装の部分を追加的に完成させるために用いられる。スパイラルプロセスは、設計の後の実装の決定および規定のようなフォワードシーケンス、あるいは、設計または実装の後の要件開発のようなリバースシーケンスを繰り返すことを可能にする。現代的なソフトウェアエンジニアリングおよび対応するツールは、開発のスピードを上げ、品質を向上させ、開発コストを減らすために、開発時にスパイラルプロセスを用いることを促進する。
【０１０２】
図11は、本開示の例示的実施形態による、開発オペレーションとサービスオペレーションとが同時進行する期間を有するスパイラルライフサイクルプロセス1100を示すプロセス図である。
【０１０３】
ライフサイクルスパイラルプロセス1100が必要なのは、自動車のライフサイクルのサービスフェーズの間に欠陥や異常が見つかるためである。欠陥は、既に分析されている故障であり、故障モードモデルから予測される。根本原因を決定する手続きは、おそらく周知であり、効果的に適用されることが可能である。欠陥は、一般に、部品の交換を含む修理作業によって現場で修正されることが可能である。
【０１０４】
異常は、まだ分析されていない故障であり、故障モードモデルから予測されない。異常のほとんどは、ソフトウェアのバグのようなモデルエラーに根本原因がある。モデルエラーは、自動車および/またはそれをサポートするビジネスシステムの実装において見つかる。これらのエラーの修正は、開発フェーズに戻って行われなければならない。この開発フェーズは、図示したように、サービスオペレーションと同時に進行する。
【０１０５】
図12は、本開示の例示的実施形態による、「V」サイクルの概念で示されるプロトタイプサイクル1200を含む自動車開発フェーズを示すプロセス図である。
【０１０６】
開発フェーズ902(図9)は、「V」字形をたどるプロトタイプサイクル1200を含む。「V」は、要件として自動車モデルおよびビジネスシステムのいくつかの部分を開発することから始まり、オプションで設計モデルの部分の開発に進み、その後、オプションで実装モデルの部分の開発に進む。「V」の底では、その後、開発アクティビティの焦点が、モデルの開発済みの部分の統合、テスト、較正、および(妥当性の)確認にシフトする。
【０１０７】
「ダウンサイクル」は図の左側にあり、「アップサイクル」は図の右側にある。「V」の水平方向は、統合、テスト、較正、または確認が行われるモデルの対応部分である。要件のコンポーネントは、部分的に開発された後に、シミュレーションのような方法で統合、テスト、および確認が行われることが可能である。初期のプロトタイプ「V」サイクルは、要件の開発およびテストだけを含むことになる。設計モデルまたは実装モデルのいくつかの部分が開発された後、自動車およびビジネスシステムに関して、モデルのその部分を、モデルのそれまでの部分と統合し、テストおよび確認を行うことが可能である。各プロトタイプサイクルでは、要件、設計、および実装を含むコンポーネントを用いて、モデルのより多くの部分の開発、統合、テスト、および確認を行う。
【０１０８】
図13は、本開示の例示的実施形態による、ライフサイクル法がスパイラルプロセスを用いて要件、設計、および実装を通って進行する様子を示すプロセス図である。
【０１０９】
開発フェーズ902(図9)は、プロトタイピングサイクル1302、1304、1306を通って進行する。各サイクルは、最初に、要件の属性の観点のモデル開発を含む、「V」サイクルの「ダウンサイクル」に動き、その後、設計の属性の観点、最後に実装の属性の観点で動く。初期の「ダウンサイクル」では、「アップサイクル」に入って要件のテストおよび確認を開始する前に、要件を開発することだけが必要である。開発フェーズにおけるほとんどのプロトタイピングサイクルが、「ダウンサイクル」における要件、設計、および実装の属性の観点のモデル開発を含む。
【０１１０】
図14は、本開示の例示的実施形態による、ライフサイクル法がスパイラルサブプロセスを適用する様子を示すプロセス図である。
【０１１１】
開発フェーズ902(図9)は、プロトタイプサイクル1400を含む。サイクル1400は、スパイラルプロセスを用いて、最初は図に示すように、「V」の「ダウンサイクル」に動く。スパイラルプロセスでは、プロトタイプモデルの要件属性の部分が開発およびテストされ、その後に設計属性の部分が開発およびテストされ、その後に実装属性の部分が開発およびテストされる。
【０１１２】
図15は、本開示の例示的実施形態による、ライフサイクル法が、リンクされたIDEおよびRTEとともに適用される様子を示すプロセス図である。
【０１１３】
開発フェーズ902(図9)は、プロトタイプサイクル1500を有し、スパイラルプロセスを用いて「V」内を動く。モデルの部分の開発では、IDE 1502が必要である。実装モデルの部分のテスト、較正、および確認では、RTE 1504が必要である。スパイラルプロセスに沿って効果的に動くためには、IDE 1502およびRTE 1504が、DRDリンク1506を介してリンクされていなければならない。IDE 1502は、主に「V」の上位および中位に適用され、RTE 1504は「V」の下位に適用される。「V」内を動くスパイラルプロセスは、リンクされたIDE 1502およびRTE 1504によって有効になる。リンケージは、「ダウンサイクル」時および「アップサイクル」時に必要である。「ダウンサイクル」では、情報は主にIDE 1502からRTE 1504に流れるが、これは、RTE 1504としての実装で終わることに焦点がおかれているためである。
【０１１４】
図16は、本開示の例示的実施形態による、ライフサイクル法が進行する様子を示すプロセス図である。
【０１１５】
開発フェーズ902(図9)は、プロトタイピングサイクル1602、1604、1606を通って進行する。各サイクルは、最終的には、実装、次に設計、最後に要件の属性の観点の、モデルの統合、テスト、較正、および確認を含む、「V」の「アップサイクル」内を動く。初期の「アップサイクル」は、要件だけを伴う。後の方の「アップサイクル」は、要件と設計とを伴う。開発フェーズにおけるほとんどのプロトタイピングサイクルは、「ダウンサイクル」において、要件、設計、および実装の属性の観点のモデル開発を含み、その後に、「アップサイクル」において、実装、設計、および要件の統合、テスト、較正、および確認を含む。
【０１１６】
図17は、本開示の例示的実施形態による、ライフサイクル法がスパイラルサブプロセスを適用する様子を示すプロセス図である。
【０１１７】
開発フェーズ902(図9)は、プロトタイプサイクルを含む。このサイクルは、スパイラルプロセス1700を用いて、図に示すように、「V」内を、最初は「ダウンサイクル」において、次に「アップサイクル」において動く。スパイラルプロセスでは、プロトタイプモデルの実装属性の部分が統合およびテストされ、その後に設計の部分が開発およびテストされ、その後に要件属性の部分がテストおよび確認される。
【０１１８】
図18は、本開示の例示的実施形態による、ライフサイクル法がスパイラルサブプロセス内で適用される様子を示すプロセス図である。
【０１１９】
開発フェーズ902(図9)は、プロトタイプサイクルを有し、スパイラルプロセス1800を用いて「V」内を動く。モデルの部分の開発では、IDE 1802が必要である。実装モデルの部分のテスト、較正、および確認では、RTE 1804が必要である。スパイラルプロセスに沿って効果的に動くためには、IDE 1802およびRTE 1804が、DRDリンク1806を介してリンクされていなければならない。IDE 1802は、主に「V」の上位および中位に適用され、RTE 1804は「V」の下位に適用される。「V」内を動くスパイラルプロセス1800は、リンクされたIDE 1802およびRTE 1804によって有効になる。リンケージは、「ダウンサイクル」時および「アップサイクル」時に必要である。「アップサイクル」では、情報は主にRTE 1804からIDE 1802に流れるが、これは、IDE内の一連の要件および設計によって確認されたモデルで終わることに焦点がおかれているためである。
【０１２０】
図19に示すように、診断エージェントは、それが内部データとして読み出す特定のDID-Iによって構築され、RTE 600内の対応する機能のモジュール内で故障を検出することが可能である。次にエージェントは、DRD 599にアクセスしてFID-Iリンケージを見つけ、DRD 599に情報を書き込む。この情報は、IDE 500内の任意のツールによって、またはRTE 600内の補助エージェントによって読み出すことが可能である。エージェントがECU内にあって、そのECUがDRD 599に直接アクセスできない場合、エージェントは、TCU 内の、DRD 599にアクセスできるエージェントにメッセージを送る。
【０１２１】
いったんIDE 500にリンクされると、RTE 600によってDRD 599内に作成された情報によってガイドされる、IDE 500内部のリンケージを用いて、機能に対する診断のラウンドトリップエンジニアリングが可能になる。
【０１２２】
図20に示すように、システム499は、第1および第2のエージェント2012、2014を用いて、故障、欠陥、または異常を検出する。第2のエージェント2014は、モデルおよび反復手順を用いて、既知の故障モードの根本原因を決定することが可能な、モデルベース診断(MBD)エージェントである。そのようなエージェントの例として、R.O.S.E. Rodon(商標)のようなツールを用いて構築されるMBDエージェントがある。これらのMBDエージェントは、モデル内で予想されていない新しい故障には効果的でない。その検出機能のギャップを埋めるために、システム499は、時間-周波数解析(TFA)のような、動作中の自動車を観察することによってモデルを学習する埋め込みデータマイニングアルゴリズムを用いて、第1のエージェント2012(学習モデルベース診断(LMBD)エージェント)を作成および適用する。これらのアルゴリズムは、一定の正常動作時間の間にトレーニングおよび較正されてから、自動車RTE 600におけるランタイムの監視モードに設定される。
【０１２３】
システム499では、LMBDエージェント2012は、MBDエージェント2014によって検出された故障のスーパセットを検出する。LMBD故障は、(1)現場での修正が可能な、既に予想されている故障、または(2)モデルエラーか、別の新しいタイプのハードウェア故障である可能性がある新しい故障のいずれかに分類される。この分類は、MBDエージェント2014の出力とLMBDエージェント2012の出力とを比較することにより、行われる。MBDエージェント2014が、ある統計的信頼度を有する故障モードを以前に見つけている場合、その故障は、おそらく、モデルエラーではない。MBDエージェント2014が、まだ見つかっていない新しい故障モードを示す低い信頼度を有する場合は、モデルエラーとして調査される必要があり、サービス技術者は現場で部品を交換しないよう指示される。
【０１２４】
調査が行われるのは、RTEエージェントが情報をDRDリンク599(図6)に書き込み、これによって、IDE 500(図5)が、実装、設計、および要件のレベルで表現されるモデルのレベルまでさかのぼって故障を追跡することが可能になったときである。システム499は、どの機能が故障にリンクしているかを識別する。故障モードを複製するために、IDE 500(図5)内でシミュレーションを実行することが可能である。シミュレーションは、根本原因の決定を支援する。このようにして、LMBDエージェント2012は、異常を検出することが可能である。
【０１２５】
図21は、学習モデルベース診断システム2100の論理動作を表すフローチャートである。学習モデルベース診断システム2100の動作フローの入口は、フロー接続2102である。検出動作2104が故障を検出する。本明細書に既に記載したような診断エージェントは、自動車の機能を連続的に監視することに注意されたい。そのようなエージェントは、一般に、RTE 600(図6)のような、自動車内で動作するRTEの中に配置される。発見モジュール2106が、故障が見つかったかどうかを判断する。発見モジュール2106が、故障は見つかっていないと判断した場合、動作フローは、「いいえ」に分岐して検出動作2104に戻る。このようにして、自動車は連続的に監視される。
【０１２６】
発見モジュール2106が、故障が見つかったと判断した場合、動作フローは、「はい」に分岐して既知モジュール2108に進む。既知モジュール2108は、その故障が既知の故障かどうかを判断する。既知モジュール2108が、その故障が既知の故障であると判断した場合、動作フローは、「はい」に分岐して識別動作2110に進む。識別動作2110は、既知の故障の対応策を識別する。動作フローは、終了点2112で終了する。
【０１２７】
既知モジュール2108が、その故障が既知の故障ではないと判断した場合、動作フローは、「いいえ」に分岐して書き込み動作2114に進む。書き込み動作2114は、故障情報を、DRDリンク599(図6)のようなリンクに書き込む。読み出し動作2116が、故障情報をリンクから読み出す。その故障が、IDE 500(図5)のようなIDEに読み出される。モデル動作2118がモデルエラーを識別する。モデルエラーは、IDEの要件、設計、または実装のレベルのエラーである可能性がある。動作フローは、終点2112で終了する。
【０１２８】
図22は、診断層2200を示すブロック図である。診断層2200は、ソフトウェア診断エージェント2202およびハードウェア診断エージェント2204(たとえば、図20のLMBDエージェント2012)を含む。診断層2200は、RTE(たとえば、図20のRTE 600)内で動作することが可能である。診断層2200は、自動車システム2210を監視する。自動車システム2210は、制御システム2212およびハードウェアシステム2214を含む。制御システム2212は、運転者入力2216を受け取り、制御入力2218をハードウェアシステム2214に与える。ハードウェアシステム2214は、自動車出力2220を与えて自動車を動作させる。
【０１２９】
ソフトウェア診断エージェント2202は、制御システム2212を監視する。同様に、ハードウェア診断エージェント2204は、ハードウェアシステム2214を監視する。診断エージェント2202、2204は、自己組織化マップおよび時間-周波数解析を用いる領域化に基づく異常検出スキームに従って異常を検出することが好ましい。もちろん、他の好適な方法を用いてもよい。
【０１３０】
自己組織化マップ(SOM)は、ベクトル量子化問題のクラスに対するノンパラメトリック回帰解を定義する。このノンパラメトリック回帰法は、多数の順序付けされた離散参照ベクトルを、入力ベクトルサンプルの確率分布にフィッティングすることを含む。SOMは、ベクトル量子化(VQ)手法に類似している。VQ手法は、古典的なデータ圧縮方法であって、通常は、有限個数のコードベクトルまたはコードワードmi∈Rn,i=1,2,...kを用いて、確率的ベクトルx∈Rnの確率密度関数p(x)に対する近似を形成する。各コードワードmiに対するボロノイ集合を次のように定義できる。
【０１３１】
Vi={x∈Rn|d(x,mi)≦d(x,mj),∀j≠i}
【０１３２】
これは、対応するコードベクトルmiに最近接しているすべてのベクトルを含む。d(・,・)は、線形ベクトル空間Rnに定義された距離尺度であり、たとえば、よく知られたユークリッド距離であってよい。すべてのボロノイ集合が、全ベクトル空間Rnの分割を構築する。したがって、何らかの最適化基準に従ってコードブックがいったん決定されれば、任意の入力ベクトルxに対して、スカラ数へのエンコードが可能である。このスカラ数は、それに関連付けられたコードベクトルが、距離尺度d(・,・)が次式で示される最小値になるという意味でxに最も近い、インデックスcである。
【０１３３】
【数１】
2008517386.tif 000004
【０１３４】
コードワードmi∈Rn,i=1,2,...,kを最適に選択すると、次式で示される平均期待量子化エラー関数が最小になる。
【０１３５】
E=∫f(d(x,mc))p(x)dx
【０１３６】
ここで、f(・)は、距離尺度d(・,・)の何らかの単調増加関数である。インデックスcは、入力ベクトルxおよびすべてのコードベクトルmi∈Rn,i=1,2,...,kの関数であることに注意されたい。cが不連続に変化しうることは容易に観察される。結果として、期待量子化エラーEのmi∈Rn,i=1,2,...,kに対する勾配は、連続微分可能ではない。一般に、mi∈Rn,i=1,2,...,kに対して最小にする閉形式解は得られないので、最適解を反復近似しなければならない。特殊なケースとして、f(d(x,mc))=||x-mc||2の場合には、反復ステップtで、-∇mjE|t=2・δcj・(x(t)-mj(t))の方向に最急降下が得られることが示されている。ここで、δcjはクロネッカーデルタ関数である。勾配∇mjE|t=-2・δcj・(x(t)-mj(t))からの定数-2を含む学習レート係数α(t)によってステップサイズを定義すると、次の更新式に到達する。
【０１３７】
mi(t+1)=mi(t)+α(t)・δci・(x(t)-mi(t))
【０１３８】
これにより、平均期待量子化エラーEを最小にするベクトルの集合mi∈Rn,i=1,2,...,kが得られ、これは、入力ベクトルの空間を有限個数のコードブック参照ベクトルの集合にマッピングすることが可能である。しかしながら、それらの参照ベクトルのインデックスは、任意の方法で並べられることが可能である。すなわち、このマッピングは依然として非順序的である。これは、デルタ関数δcjが使用されていることにより、任意の入力ベクトルxが、そのベクトルに最も近いコードベクトルにしか影響しえないためである。
【０１３９】
VQ手法と異なり、SOMは、オリジナルのデータ要素の最も重要なトポロジ関係およびメトリック関係を維持しながら、高次元のデータを、はるかに低い次元のグリッドにマッピングすることが可能である。近接する参照ベクトルの、この種の規則性は、それらの局所的な相互作用に由来する。すなわち、一定の幾何学的距離までの、低次元グリッド内の隣接ノードの参照ベクトルは、互いに活性化しあって、同じ入力ベクトルx∈Rnから何かを学習する。この結果、同じ近傍にあるノードの参照ベクトルに局所的な平滑作用がもたらされ、これが全体順序付けにつながる。この順序づけ特性により、マップは、入力ベクトル空間およびそれらの関係に固有の自然な集団を明らかにする傾向がある。
【０１４０】
SOMは、高次元サンプルベクトル空間から、自己組織化されたノードの集合によって表されるほぼ1次元または2次元の配列への非線形投影として解釈されることが可能である。各ノードは、入力ベクトルと同じ次元を有する参照ベクトルに関連付けられる。この報告で使用される距離尺度は、よく知られたユークリッド距離である。任意の入力ベクトルx∈Rnに対するBest Matching Unit(BMU)は、次式で定義される。
【０１４１】
【数２】
2008517386.tif 000005
【０１４２】
簡単に言えば、BMUに関連付けられた参照ベクトルは、入力ベクトルxに対して最小ユークリッド距離を生成する。学習プロセスの間にSOMの全体順序付けが確実に行われるようにするために、BMUの参照ベクトルを更新するだけの代わりに、入力ベクトルの影響領域を広げなければならない。1つの代替は、デルタ関数δcjを、時間tと、2次元グリッド上の2つのノードcおよびiの間の距離とに依存する、新しい近傍関数hci(t)に置き換えることである。これにより、参照ベクトルに関して次式が得られる。
【０１４３】
mi(t+1)=mi(t)+hci(||rc-ri||,t)・(x(t)-mi(t))
【０１４４】
ここで、t=0,1,...は、離散時間インデックスであり、rc,ri∈R2は、ノードcおよびiのグリッド内のロケーションである。
【０１４５】
ネットワークが収束するためには、t→∞に対してhci(||rc-ri||,t)→0となることが必要である。さらに、ネットワークの「弾力性」の度合いは、近傍関数hci(||rc-ri||,t)の平均の幅または鋭さに関連する(ここで、||rc-ri||の増加に対してhci→0である)。hci(t)の最も単純にして効果的な選択は次式である。
【０１４６】
【数３】
2008517386.tif 000006
【０１４７】
ここで、Nc(t)は、2次元グリッド内のノードcの、指定の半径の周囲にある近傍集合であり、α(t)は、0と1の間の小さなスカラ数である。α(t)と、Nc(t)の半径とは、時間に対する単調減少関数である。近傍関数hci(t)の、別のよくある選択は次式である。
【０１４８】
【数４】
2008517386.tif 000007
【０１４９】
ここで、α(t)は学習レート係数であり、σ(t)は、hci(t)の幅を規定する。これらはいずれも、時間に対する単調減少関数である。
【０１５０】
SOMのサイズが小さい場合(たとえば、ノード数が数百の場合)、それらのパラメータの選択は重要ではない。一方、SOMが非常に大きい場合は、参照ベクトルの収束および全体順序付けが確実に行われるように、それらのパラメータを慎重に選択しなければならない。このアルゴリズムの計算ステップは、次のようにまとめることができる。
1.マップのサイズおよびトポロジを選択し、参照ベクトルmi∈Rn,i=1,2,...,kの集合を初期化する(たとえば、それらをランダムに設定するか、たとえば、最初のトレーニングベクトルxの初めのk個のコピーを選択することにより初期化する)。
2.入力ベクトルx(t)に対するBMUを見つけ、BMUおよびその近傍ユニットの参照ベクトルを調整する。
3.参照ベクトルの変化が顕著でなくなるまでステップ2を繰り返す。
【０１５１】
学習開始時にすべてのトレーニングサンプルが入手可能であるという前提があれば、SOMのバッチ計算アルゴリズム(バッチマップ)を使用することも可能である。バッチマップは、特に、近傍Nc(t)がBMUのみを含む集合にシュリンクする、学習プロセスの最後のフェーズにおいて、VQのK-meansアルゴリズムと似ている。このバッチマップアルゴリズムは、学習レート係数を含まないので、収束の問題がなく、参照ベクトルmi∈Rn,i=1,2,...,kのより安定した値を生成する。
【０１５２】
学習プロセスパラメータ、参照ベクトルmi(0)∈Rn,i=1,2,...,kの初期化、およびトレーニングベクトルx(t)のシーケンスが異なれば、結果として得られるマップも異なる可能性がある。最適性の基準に応じて(たとえば、平均量子化エラー)、異なるSOMが最適と見なされる可能性がある。||x-mc||の平均である平均量子化エラーは、マップがトレーニングサンプルのセットにいかによくフィットしているかを測定できる、有意義な性能指数である。SOMに関する詳細については、以下の文献を参照されたい。これらの文献は、そのすべてが参照により本明細書に組み込まれている。
Kohonen, T.、Oja, E.、Simula, O.、Visa, A.、Kangas, J.(1996)、「Engineering applications of the self-organizing map」、Proceedings of the IEEE、v 84, n 10、1358〜1384頁
Kohonen, T.(1995)、「Self-Organizing Maps」、Springer、Berlin、Heidelberg
【０１５３】
ますます複雑になり洗練される制御ソフトウェア、一体型センサ、アクチュエータ、および超小型電子技術は、より高い信頼性、安全性、および保守性を顧客に提供する。その一方で、これらは、自動車を診断し、システム異常を検出および隔離するために、かつてないほどの難題を今日のエンジニアに課す。自動車内の制御ソフトウェアの増えている部分は、制御ソフトウェアをよりいっそう難解にする。これは、コストを下げるためにほとんどのメーカーが好む解決策が、魅力的な特徴を提供するために、ハードウェアを追加する代わりに、より洗練された制御ソフトウェアを設計することだからである。自動車内で動作するソフトウェアの量は、将来にわたって増加が止まりそうにない。
【０１５４】
自動車内で使用される制御ソフトウェアおよび様々なハードウェアコンポーネントは、非線形挙動を示すのが普通である。これは特に、制御ソフトウェアについて当てはまる。したがって、いったん、これらのソフトウェアおよびハードウェアコンポーネントが自動車に組み込まれて、互いに通信するようになると、これらは多数の動作可能領域を作成する。それらの相互作用は、複雑すぎて、経験を積んだエンジニアでも理解できない場合がある。さらに、運転者入力および外部環境条件は、大きく変化し、自動車が動作する条件の無限のパターンを形成する。運転者入力および外部の影響が異なれば、システム挙動を表すシグネチャはまったく異なる。挙動パターンが無限に多くあれば、挙動シグネチャをしかるべき挙動レジームと比較しなければならないので、異常の検出および場所を突き止めることが複雑になる。異常を見つける最良の方法は、同じ挙動レジームの中のシグネチャを比較することである。現在のシグネチャの、正常なシグネチャからのずれが、異常の深刻度を示す。
【０１５５】
システムの動的な挙動を、異なる動作領域に分割すること(すなわち、領域化)のためには、まず、領域化を実施するための、しかるべきベースを見つけなければならない。次の形の通常の微分方程式により、様々な物理システム(たとえば、機械式、電気式、電気機械式、熱式、または油圧式システム)をモデル化することが可能である。
【０１５６】
【数５】
2008517386.tif 000008
【０１５７】
ここで、
【０１５８】
【数６】
2008517386.tif 000009
【０１５９】
は、システム出力の1次、2次からn次までの導関数であり、
【０１６０】
【数７】
2008517386.tif 000010
【０１６１】
は、入力と、それらのm次までの導関数である。入力が、時間の区分的微分可能関数u=μ(t)として指定されていれば(u=[u1,u2,...,up])、u=μ(t)を差し引いてuを除去することが可能であり、その導関数は次式を生成する。
【０１６２】
F(t,y,y',y",...,y(n))=0
【０１６３】
y(n)は、明示的に、y(n)=γ(t,y,y',y",...,y(n-1))と表すことができる。状態変数をx1=y,x2=y',...,xn=y(n-1)のように選択すると、次のように、式を状態空間式の集合として書くことができる。
【０１６４】
【数８】
2008517386.tif 000011
【０１６５】
これは、次のように、1個のn次元1次ベクトル微分方程式である、n個の1次微分方程式の集合として書き直すことが可能である。
【０１６６】
【数９】
2008517386.tif 000012
【０１６７】
これは、f(t,x)がtの区分連続であって、次のLipschitz条件を満足する場合には、参照によって本明細書に組み込まれている、Khalil, H.(2002)、「Nonlinear Systems, 3rd edition」、Prentice-Hall、NJにおいて実証されている。
【０１６８】
||f(t,x)-f(t,y)||≦L||x-y||
【０１６９】
∀x,y∈Rn、∀t∈[t0,t1]であり、Lは有限の正の数なので、初期条件x(t0)=x0を有する状態方程式
【０１７０】
【数１０】
2008517386.tif 000013
【０１７１】
は、[t0,t1]の範囲で一意解を有する。これは、大域的存在と一意性の理論と呼ばれる。これは、複数入力および複数出力のシステムに容易に一般化することが可能である。
【０１７２】
一定の条件が満たされれば、(n-1)次の導関数までの出力yの初期条件と、時間間隔[t0,t0+τ]の間の入力シーケンスにより、同じ時間間隔におけるシステム出力yが一意に決定される。これにより、領域化が、出力および入力のシーケンスの初期条件に基づくことが可能であることが示される。
【０１７３】
システム挙動のパターンが極端に多い場合、異常の検出および場所を突き止めること(領域化)は非常に困難である。従来のモデルベース欠陥診断手法は、多くの場合、基礎となる物理システムに関する詳細な知識が得られないために不適当である。システムは、ブラックボックスとしてしか見ることができない。ブラックボックス問題を扱うことが可能な、使用可能な手法のいくつか(非線形自動回帰移動平均モデリングやニューラルネットワークなど)は、厳密なパラメータ仮定を有するか、リアルタイム実現可能性を欠く。したがって、システムの入力および出力に関連するモデルを近似的に構築できる方法を見つける必要がある。システムは、入力シーケンスと出力の初期条件とに基づいて、異なる領域に分割されることが好ましい。
【０１７４】
【数１１】
2008517386.tif 000014
【０１７５】
を含む出力の初期条件と、一定の時間間隔[t0,t1]の間の入力シーケンスu(t)とを連結して、次式のような大きなベクトルを形成するとする。
【０１７６】
【数１２】
2008517386.tif 000015
【０１７７】
ここで、
【０１７８】
【数１３】
2008517386.tif 000016
【０１７９】
(以降も同様)である。このベクトルは、システム出力を決定するために必要な情報をすべて含む。しかしながら、実際の応用では、このベクトルの次元は、非常に高くなるのが普通である。したがって、SOMは、高次元データの可視化にすぐれていることから、それらのベクトルによって広がる空間を領域化するために用いられる。ボロノイ集合は、トレーニングされたSOMのすべての参照ベクトルを用いて、ベクトルによって広がる全体空間の分割を形成する。ボロノイ集合は、システム「動作可能領域」と呼ばれる。
【０１８０】
各領域は入力および初期条件が同様なので、同じ動作可能領域の出力シーケンスは、同様のパターンを有する。これらの出力パターンに基づき、各動作可能領域の、正常なシステム挙動を表す統計的プロファイルを作成することが可能である。領域化後、入力パターンと出力の初期条件とに基づき、BMUを見つけることによって信号を適切な領域に割り当て、各領域内で現在の出力シーケンスと正常プロファイルとを比較することが可能である。現在の出力シーケンスと正常プロファイルとの間の統計的相違度は、システム挙動が正常挙動または期待挙動からどれだけずれているかを示す性能指数として用いられることが可能である。これは、時間-周波数解析ベースの性能評価によって実現可能である。
【０１８１】
時間-周波数解析(TFA)は、以前から強力な非信号処理方法として認識され、レーダ技術、海洋生物学、生体医用工学など、様々な分野で広く応用されている。よく知られた高速フーリエ変換(FFT)は、信号を周波数成分に分解できるだけであって、時間-位置に関連する情報を表現しないが、TFAは、信号を時間と周波数の両方に同時に分解することが可能である。この点により、TFAは、信号の周波数コンテンツが時間とともに変化する信号の分析に適した方法である。たとえば、制御システム内の時間遅延を検出することは、FFTを用いた場合には非常に困難であるが、TFAを用いれば、より容易である。TFAは、非定常信号を扱うことができるので、制御システムからの信号の処理に非常に好適である。
【０１８２】
特性関数が次式で与えられる2次元分布pX,Y(x,y)を考える。
【０１８３】
φ(η,ξ)=E[ejXη+jYξ]=∫∫ejXη+jYξpX,Y(x,y)dxdy
【０１８４】
これは、参照によって本明細書に組み込まれている、Cohen, L.(1994)、「Time-Frequency Analysis」、Prentice Hallに記載されているように、テイラー級数によって近似されることが可能であり、特性関数は次のように表すことができる。
【０１８５】
【数１４】
2008517386.tif 000017
【０１８６】
時間-周波数分布はその特性関数によって一意に決定できるので、モーメント系列E(XpYq)を用いて分布pX,Y(x,y)を表すことが可能である。
【０１８７】
しかしながら、モーメント系列は無限に長いため、特徴として直接用いることができない。さらに、異なる次数のモーメントは互いに強い相関がある。それにもかかわらず、低次のモーメントだけが時間-周波数分布の全般的な特性を表すので、モーメントシーケンスを切り詰めて、時間-周波数分布を近似的に表すことが可能である。したがって、モーメントベクトルの次元の数を減らすために、さらなる処理が必要である。これは、参照によって本明細書に組み込まれている、Richard, O.、Duta, P.、David G. (2000)、「Pattern Classification」、Wiley、2nd editionに記載されているように、主成分分析(PCA)によって達成可能である。それは、参照によって本明細書に組み込まれている、Zalubas, E.J.、O'Neill, J.C.、Williams, W.J.、Hero, A.O.、「Shift and Scale Invariant Detection,」、Proc. IEEE Int. Conf Acoustic, Speech, and Signal Processing、vol.5、1996、3637〜3640頁に記載されているように、時間-周波数モーメントを漸近的ガウス分布と見なすことができるからである。
【０１８８】
主成分のガウス分布および独立を仮定すると、特徴ベクトル間のマハラノビス距離は、自由度rのχ2分布に漸近的に従う。ここで、rは、抽出された主成分の数である。したがって、正常分布を表すトレーニングセットからの信号のずれは、マハラノビス距離が一定の範囲内にある確率によって見積もることが可能である。この確率は、信頼値(CV)と呼ばれ、正常状態からのずれの度合いを示す。詳細については、参照によって本明細書に組み込まれている、Djurdjanovic, D.、Widmalm, S. E.、Willians, W. J.、Koh, C. K.H.、Yang, K. P. (2000)、「Computerized Classification of Temporomandibular Joint Sounds」、IEEE transaction on biomedical engineering、vol. 47、No.8を参照されたい。
【０１８９】
図23は、例示的実施形態による、性能を評価することが可能な診断システム2300を示す。システム2301は、入力2302と、初期条件2304と、出力2306とを含む。入力2302および初期条件2304に基づき、SOM 2308を用いて、領域化を達成することが可能である。現在の出力シーケンスに基づき、動作可能領域2310内で、TFAベースの性能評価手法を直接適用することが可能である。システム2301のモデルまたは構造に関する知識は得られないものとする。ただし、システム2301が正常動作していれば、入力2302および出力2306が得られるものとする。
【０１９０】
システム2301は、自動車2320であることが好ましいが、システム2320は任意の好適なシステムであってよい。図24は、自動車2320をより詳細に示す。自動車2320は、エンジン2422、ドライブトレーン2424、他のコンポーネント2426、および自動車動力学2428を含む。運転者2430は、システム2301(図23)に入力2302を与えることが可能である。環境2432も、システム2301(図23)に入力2302(たとえば、温度、風速、路面勾配、大気圧など)を与えることが可能である。
【０１９１】
本明細書に記載の異常検出手法を自動車2320に適用するためには、自動車2320が第1のサブシステム2500(図25)内に領域化されなければならない。例示的実施形態では、第1のサブシステム2500(領域化されたシステム)は、スロットルプレートサブシステム2502である。スロットルプレートサブシステム2502は、スロットルプレートコントローラ2504と、スロットルプレート2506と、コントローラ2508と、プラント2510とを含む。
【０１９２】
スロットルプレートサブシステム2502への入力(たとえば、図23の入力2302)は、スロットルプレートコントローラ2504からの制御信号2511であり、制御信号2511は、スロットルプレート2506内のスロットルプレート角度2516を調節する。実際のスロットル角度は、センサによって測定され、統合システム2500にフィードバックされる。自動車2320が動作しているときのスロットルプレートコントローラ2504への入力は2つある。アクセルの相対位置2512とエンジン速度2514である。これら2つの入力2512、2514に基づき、スロットルプレートコントローラ2504は、制御信号2511を計算してスロットルプレート2506に送り、スロットルプレート2506は、スロットルの絶対角度2516を設定する。
【０１９３】
異常検出システム2550が、システム2502が動作しているときに、プラント(スロットル機構)2510またはコントローラ2508のいずれかの漸進的パラメータ劣化を検出する。さらに、異常検出システム2550は、異常の発生場所がコントローラ2508であってもプラント2510であっても、あらゆる異常を見つけることができなければならない。異常検出システム2550は、第1の異常検出器2552と、第2の異常検出器2554とを含むことが好ましい。第1の異常検出器2552は、制御側の異常を検出し、第2の異常検出器2554は、プラント側の異常を検出する。
【０１９４】
相対アクセル信号(Accelerator)2512、エンジン速度(n _Engine)2514、制御信号(al _ThrottleECU)2511、および絶対スロットル角度(al _Throttle)2516が頻繁に(好ましくは、約200Hzのサンプリングレートに対応する5ミリ秒ごとに)サンプリングされる。次に、これらの信号が、サンプリングレートを100Hzに下げるために、半分にダウンサンプリングされることが好ましい。
【０１９５】
相対アクセル信号(Accelerator)2512、エンジン速度(n _Engine)2514、制御信号(al_ThrottleECU )2511、および絶対スロットル角度(al_Throttle)2516は、まず、自動車2320が正常条件下で動作しているときに収集されるか、IDE(たとえば、図5のIDE 500)で決定されたように収集される。
【０１９６】
次の表は、トレーニングデータセットおよびテストデータセットを示す。
【０１９７】
【表３】
2008517386.tif 000018
【０１９８】
次の図は、自動車2320内の機械的スロットルプレート2506を示す。
【０１９９】
【表４】
2008517386.tif 000019
【０２００】
サブシステム2500への入力は、al_ThrottleECU 2511とラベル付けされており、これは、スロットルプレートコントローラ2504から来る制御信号2511であって、通常は0から1の範囲である。al_ThrottleECU信号2511を変化させることにより、al_Throttle 2516とラベル付けされた、スロットルプレート2506の出力を調節することが可能である。al_Throttle 2516は、上図に示すように、ストップに対する絶対スロットル角度である。2つのパラメータal_ThrottleMinおよびal_ThrottleDeltaは、スロットルプレート2506が開くことが可能な範囲を規定する。スロットルプレート2506の動力学は、3つのパラメータ(質量M、粘性減衰係数C、および剛性K)を有する2次の力学系としてモデル化される。このスロットルプレート2506のパラメータの公称値は、M =1、C=10、K=40、al_ThrottleDelta=80、およびal_ThrottleMin=8である。
【０２０１】
次の図は、スロットルプレート2506のすべてのパラメータが公称値に設定された場合に収集される信号を示す。
【０２０２】
【表５】
2008517386.tif 000020
【０２０３】
【数１５】
2008517386.tif 000021
【０２０４】
前述のように、システムの力学的挙動は、異なる複数の動作可能領域に分割され、各領域において、出力シーケンスを用いて統計的正常プロファイルを確立するためにトレーニングが必要である。このトレーニング情報は、DRDリンク599を介してIDE(たとえば、図5のIDE 500)から学習された情報であってよい。このスロットルプレートサブシステム2500の領域化は、出力の初期条件(すなわち、絶対スロットル角度(al_Throttle)2516)および入力シーケンス(すなわち、スロットルプレートコントローラ2504からの制御信号2511(al_ThrottleECU 2511))に基づいている。
【０２０５】
al_ThrottleECUをuで表し、al_Throttleをyで表す。出力および入力の初期条件に関するすべての情報を含めるために、それらを連結して
【０２０６】
【数１６】
2008517386.tif 000022
【０２０７】
という大きな特徴ベクトルにする。ここで、
【０２０８】
【数１７】
2008517386.tif 000023
【０２０９】
は、システム出力の初期値、1次導関数、2次導関数、・・・である。u(t0),...,u(t0+τ)は、時間間隔[t0,t0+τ]の間の入力シーケンスである。対応する出力シーケンスは、[y(t0),..., y(t0+τ)]Tである。同様に、前に示したように、長さτのウィンドウを別の開始点t1にシフトして、別の大きな特徴ベクトル
【０２１０】
【数１８】
2008517386.tif 000024
【０２１１】
と、その対応する出力シーケンス[y(t1),..., y(t1+τ)]Tとを与えることが可能である。このようにして、ベクトルの2つの集合が収集される。1つは、入力シーケンスと連結された出力の初期条件のすべての情報を含み、もう1つは、同じ時間間隔の出力シーケンスからなる。さらに、これら2つの特徴ベクトルの集合の間には、1対1の対応がある。
【０２１２】
高度に動的な入力を有する信号だけがトレーニングに用いられ、後でテストに用いられる。比較的静的な入力は、システムの動的モードをシミュレートしないため、動的システムパラメータのドリフトに起因する欠陥を明らかにすることができない。したがって、システムの利得変化ならびに動的変化を検出するために、急速に変化する信号のみのトレーニングセットを用いる。1つの可能な方法は、入力シーケンスの分散にしきい値を設定することである。あらかじめ規定されたしきい値より分散が大きい入力シーケンスだけを、トレーニングセットとして選択する。これは最適な方法ではないかもしれないが、実装は容易である。
【０２１３】
すべての特徴ベクトルを収集した後、入力シーケンスと出力の初期条件とからなるベクトルに基づき、SOMを用いて領域化を行うことが可能である。スロットルプレートサブシステム2502についての、この例示的実施形態では、データシーケンス長が0.6秒に選択されている。これは、オリジナルデータが前述のように半分にダウンサンプリングされた後の60ポイントに相当する。出力の初期条件については、初期値と1次および2次の導関数だけが含まれている。スロットルプレートサブシステム2502への入力は、0から1までの数字なので、入力シーケンスに関しては正規化は不要である。初期値と1次および2次の導関数を含む、出力の初期条件は、次式によって正規化されている。
【０２１４】
【数１９】
2008517386.tif 000025
【０２１５】
ここで、E(X)およびσXは、変数Xの平均および偏差である。このステップは、特徴ベクトル要素間の違いが非常に大きい状況を除去するために必要である。これは、程度の大きな特徴が、結果のSOMに支配的な影響を及ぼすためである。使用可能なソフトウェアパッケージの一例が、WWWを介してfttp://www.cis.hutfi/somtoolbox/から入手可能なSOM Toolboxである(Alhoniemi, E.、Himberg, J.、Kiviluoto, K.、Parviainen, J.、Vesanto, J.(1997)、「SOM toolbox for Matlab」)。
【０２１６】
SOMのサイズは、使用可能なトレーニングベクトルのサイズに基づき、ソフトウェア内部に埋め込まれたヒューリスティック公式によって決定される。SOMの、一般化の度合いと、量子化精度との間にはトレードオフがある。小さなSOMは、トレーニング特徴ベクトルのよい一般化であるが、量子化精度が低い。大きなSOMは、高い量子化精度が可能であるが、トレーニング特徴ベクトルが十分に一般化されず、計算能力の消費が大きくなる。入力と、出力の初期条件との連結された特徴ベクトルから得られるSOMを、一括距離行列(unified distance Matrix)(U-matrix)とともに次に示す。
【０２１７】
【表６】
2008517386.tif 000026
【０２１８】
作成されたSOMは、システムの入力と、出力の初期条件と、一括距離行列とを連結して得られた特徴ベクトルに基づいている。
【０２１９】
正常データを用いてSOMトレーニングがいったん完了すると、その正常トレーニング出力シーケンスを、関連するプロトタイプ特徴ベクトルが、対応する、入力および初期条件の連結された特徴ベクトルに最も近い領域に割り当てることが可能である。次に、その各領域において、正常トレーニング出力シーケンスにTFAを適用して、モーメントシーケンスを抽出する。
【０２２０】
時間-周波数分布に基づき、モーメントは、最大15次まで計算される(すなわち、p+q≦15)。これにより、次元135のモーメントシーケンスが得られる。得られたモーメントシーケンスの次元の数を減らすために、各領域において、これらのモーメントシーケンスにPCAを適用して、高次元のモーメントシーケンスをさらに圧縮する。最後に、オリジナルのモーメントシーケンスの全分散の99%が、それらの対応する分散とともに投影される、2〜3の主要方向だけを、後のテストのためのパラメータとして保持する。トレーニングが十分であることを保証し、高い検出精度を維持するために、トレーニング中に頻繁に活性化されている領域だけを選択し、その各領域において、前述の手順に基づいてトレーニングを実施する。
【０２２１】
図26は、異常検出器2600の論理フロー図である。動作フローは、開始点2602から始まる。出力動作2604は、現在の出力シーケンスと、それに対応する入力および初期条件とを動作可能領域に割り当てる。そのコードワードベクトルは、現在の入力シーケンスおよび初期条件の連結された特徴ベクトルに基づいて、着信する任意の新しい信号に対し、その連結された特徴ベクトルに最も近くなる。計算動作2606は、量子化エラーを計算する。
【０２２２】
エラーモジュール2608は、量子化エラーがあらかじめ設計されたしきい値より小さいかどうかを判定する。このしきい値は、トレーニング中の量子化エラーの中央値である。エラーモジュール2608が、量子化エラーのほうが小さいと判定すると、動作フローが「はい」に分岐し、出力動作2604に戻る。エラーモジュール2608が、量子化エラーのほうが小さくないと判定すると、動作フローが「いいえ」に分岐し、異常検出動作2610に進み、異常検出器がトリガされる。異常検出器は、指定領域のトレーニングされたパラメータを自動的に取得し、χ2分布に従って現在の出力シーケンスから計算されたモーメントシーケンスによって指定されるマハラノビス距離の累積確率を計算する。出力動作2612は、システム挙動の正常挙動からの偏差を見積もる、0から1の範囲の信頼値を有する性能指数を出力する。動作フローは、終了点2614で終了する。
【０２２３】
次の図は、スロットルプレートサブシステム2502の異常検出器のいくつかの結果例を示す。
【０２２４】
【表７】
2008517386.tif 000027
【０２２５】
この図は、システムパラメータが、x軸に示されているような指定値に設定されている場合の信頼値の平均を表している。さらに、3-σ限界も、短い実線で描かれた間隔として示されている。本明細書において既に説明したように、粘性減衰係数Cおよび剛性Kの公称値は、それぞれ10および40である。パラメータが劣化して公称値から離れるにつれ、信頼値が低下していくのがわかる。これは、システム性能が正常挙動からずれていくことを示している。他の2つのパラメータ、質量MおよびThrottleDeltaについても、同様の傾向が見られる。これは、異常検出器が、様々な種類の異常、およびシステムパラメータの漸進的劣化を、それらの欠陥を特徴づけるシグネチャが異常検出器に対してアプリオリに提示されていなくても、検出できることを示している。
【０２２６】
入力が1つしかないスロットルプレート2506(図25)と異なり、スロットルプレートコントローラ2504は2つの入力(Accelerator 2512およびn_Engine 2514)を有する。非線形スロットルプレートコントローラ2504内のテーブルの1つを変倍するためのパラメータを、スロットルプレートコントローラ2504に導入することが可能である。この利得係数の公称値は1であり、次の図は、利得係数がその公称値に設定されたときに収集されたサンプル信号を示す。
【０２２７】
【表８】
2008517386.tif 000028
【０２２８】
プラントの異常検出と同様に、ここでも同様の手順を適用することが可能である。データ長を0.8秒とする。これは80データポイントに相当する。領域化のベースになるベクトルは、連結された、Accelerator 2512およびn_Engine 2514からの2つの入力シーケンスからなるベクトルと、出力al_ThrottleECU 2511の初期条件とである。この特徴ベクトルを適正に正規化した後、システムの動力学挙動を領域化するために、トレーニングデータに基づいてSOMを作成する。次に、TFAおよびPCAを利用して、各領域の統計的正常プロファイルを確立する。
【０２２９】
トレーニングが完了した後、テストデータに対してコントローラ検出器をテストする。次の図は、コントローラに関連付けられた異常検出器から得られた結果を示す。
【０２３０】
【表９】
2008517386.tif 000029
【０２３１】
コントローラの利得係数がその公称値である1から0.65に減少するにつれ、信頼値が小さくなり、一方で分散が大きくなることがわかる。
【０２３２】
個々の異常検出器は、システムパラメータの漸進的劣化をセンスすることが可能である。異なる複数の異常検出器からの結果を組み合わせることにより、異常の場所を特定することも可能である。この機能を示すために、2つのシナリオを説明する。第1のシナリオでは、プラントのパラメータである剛性Kが、約700秒の間に、公称値40から24に漸進的に減少するようにした。コントローラおよびプラントのパラメータを含む他のパラメータは、それぞれの公称値のままである。第2のシナリオでは、コントローラのパラメータである利得係数に外乱を導入し、やはり約700秒の間に外乱が公称値の1から0.6に指数的に減少するようにした。次の図は、2つのシナリオにおいて時間変動するパラメータを示す。
【０２３３】
【表１０】
2008517386.tif 000030
【０２３４】
次に、既に説明した2つの異常検出器を、トレーニングには用いられていない、標準的な運転プロファイルについてテストする。第1のシナリオは、第1の運転プロファイルECE2についてテストし、第2のシナリオは、第2の運転プロファイルFTP75についてテストする。これら2つの具体的な運転プロファイルは、ETASの製品であるLABCAR(登録商標)の中の運転プロファイルに対応する。次の図は、異常検出の結果を示す。
【０２３５】
【表１１】
2008517386.tif 000031
【０２３６】
【表１２】
2008517386.tif 000032
【０２３７】
ノイズをフィルタリングして除去するために、指数重み付き移動平均(EWMA)演算子を信頼値に適用する。ウィンドウを横切る直線は、トレーニングデータセットについて観察された信頼値の統計に基づいて計算された下方制御限界である。
【０２３８】
第1のシナリオの場合は、コントローラからの信頼値は常に高いが、プラントの異常検出器からの信頼値は、漸進的に減少し、最後には制御限界の外に出ることがわかる。これは、プラント内では異常が発生したが、コントローラは正常に動作し続けることを示している。第2のシナリオの場合は、コントローラパラメータに外乱を導入したため、コントローラの異常検出器からの信頼値が減少して制御限界の外に出たのに対し、プラントの異常検出器からの信頼値は制御限界内にとどまっている。したがって、コントローラ内、プラント内、またはその両方における異常の場所を容易に決定することが可能である。以上に示したようにプラントとコントローラの異常を分離できることは、異常の場所を見つける上で重要である。
【０２３９】
図27は、異常検出システム2700の例示的フロー図である。動作フローは、開始点2702から始まる。分割動作2704は、ランタイム環境を1つ以上の動作可能領域に分割する。この分割は、領域化とも呼ばれる。学習動作2706は、その動作可能領域内での正常挙動の動作を学習する。この学習は、トレーニングとも呼ばれる。監視動作2708は、現在の挙動を監視する。比較動作2710は、正常挙動と現在の動作の挙動とを比較する。検出動作2712は、現在の動作の挙動と正常動作の挙動との間にずれが存在する場合に異常を検出する。追跡動作2714は、リンクを通じて統合開発環境までさかのぼって異常を追跡する。識別動作2716は、異常の追跡に基づいて、統合開発環境内の異常を識別する。
【０２４０】
本明細書で説明したように、被制御システムの性能の漸進的劣化を検出することと、異常の場所を突き止めることとが可能な、新規な異常検出スキームを開示した。従来のモデルベースの欠陥診断と異なり、提案の方法は、システムの動力学の詳細な知識を必要としない。正常な入力信号および出力信号が存在することだけが、提案の方法の前提である。
【０２４１】
この方法は、システムのタイプ、あるいは線形か非線型かに関係なく、SOMベースの領域化と、正常な入出力信号を用いるTFAベースの性能評価とにより、入力と出力との関係を統計的に構築することが可能である。モデル構築プロセスは、非常に効率的である。これは、診断システムの開発時間を大幅に短縮する。
【０２４２】
開示された方法は、ガソリンエンジン自動車モデルのサブシステムについてデモンストレーションが行われている。本異常検出器は、システムの様々な種類のパラメータドリフトを検出できることが示されている。さらに、2つの異常検出器は、プラントの異常と、コントローラの異常とを分離することが可能である。異常検出器のもたらす結果に基づいて、プラント内、コントローラ内、またはその両方における異常の場所を突き止めることが可能である。
【０２４３】
当業者であれば、本明細書に記載のシステムを、任意の数のソフトウェア構成、ネットワーク構成、ハードウェア構成、その他を用いて実装できることを理解されよう。
【０２４４】
本明細書で示された様々な実施形態の論理動作は、(1)コンピュータで実施される一連のステップ、またはコンピュータシステムで動作する一連のプログラムモジュールとして、かつ/または、(2)コンピュータシステム内で相互接続された論理回路または論理回路モジュールとして実装される。実装は、本発明を実装するコンピューティングシステムの性能要件に依存する、選択できる問題である。したがって、本明細書に記載の、本発明の実施形態を構成する論理動作は、操作、ステップ、エンジン、またはモジュールなど、様々な形で表される。
【０２４５】
先述の各種実施形態は、例示として提示されたものに過ぎず、本発明を限定するものと解釈されてはならない。本明細書に図示および記載された例示的実施形態および応用をたどらなくても、添付の特許請求項で説明される、本発明の真の趣旨および範囲から逸脱することなく、本発明に様々な修正および変更を施すことが可能であることを、当業者であれば容易に理解されよう。
【図面の簡単な説明】
【０２４６】
【図１】本開示の例示的実施形態による、学習モデルベースライフサイクル診断の方法およびシステムの概略図である。
【図２】本開示の態様を実装するために用いることが可能なコンピューティングシステムの概略図である。
【図３】本開示の例示的実施形態による、製品の開発のブロック図である。
【図４】本開示の例示的実施形態による、厄介型問題に対応する要件の概略図である。
【図５】本開示の例示的実施形態による、学習モデルベースライフサイクル診断の方法およびシステムの概略図である。
【図６】本開示の例示的実施形態による、学習モデルベースライフサイクル診断の方法およびシステムの概略図である。
【図７】本開示の例示的実施形態による、グラフィックユーザインターフェースの例を示す図である。
【図８】本開示の例示的実施形態による、分散システムの概略図である。
【図９】本開示の例示的実施形態による、自動車製品の開発を示すプロセス図である。
【図１０】本開示の例示的実施形態による、スパイラルライフサイクルプロセスを示すプロセス図である。
【図１１】本開示の例示的実施形態による、スパイラルライフサイクルプロセスを示すプロセス図である。
【図１２】本開示の例示的実施形態による、自動車開発フェーズを示すプロセス図である。
【図１３】本開示の例示的実施形態による、ライフサイクル法が要件内を進行する様子を示すプロセス図である。
【図１４】本開示の例示的実施形態による、ライフサイクル法がスパイラルサブプロセスを適用する様子を示すプロセス図である。
【図１５】本開示の例示的実施形態による、ライフサイクル法が適用される様子を示すプロセス図である。
【図１６】本開示の例示的実施形態による、ライフサイクル法が進行する様子を示すプロセス図である。
【図１７】本開示の例示的実施形態による、ライフサイクル法がスパイラルサブプロセスを適用する様子を示すプロセス図である。
【図１８】本開示の例示的実施形態による、ライフサイクル法がスパイラルサブプロセス内で適用される様子を示すプロセス図である。
【図１９】本開示の例示的実施形態によるシステム図である。
【図２０】本開示の例示的実施形態による、ライフサイクル法がレベル同士をリンクする様子を示す図である。
【図２１】本開示の例示的実施形態による、異常検出システムを示すプロセス図である。
【図２２】本開示の例示的実施形態による、異常検出システムの概略図である。
【図２３】本開示の例示的実施形態による、ガソリンエンジンモデルシステムの概略図である。
【図２４】本開示の例示的実施形態による、統合制御システム、ガソリンエンジン自動車モデルシステム、および異常検出器の概略図である。
【図２５】本開示の例示的実施形態による、異常検出システムの概略図である。
【図２６】本開示の例示的実施形態による、異常検出システムのプロセスフロー図である。
【図２７】本開示の例示的実施形態による、異常検出システムのプロセスフロー図である。
【符号の説明】
【０２４７】
100  学習モデルベースライフサイクルシステム
105  IDE
110  RTE
115  リンク
200  コンピューティングシステム
202  プロセシングユニット
204  システムメモリ
206  システムバス
208  読み出し専用メモリ(ROM)
210  ランダムアクセスメモリ(RAM)
212  基本入出力システム(BIOS)
213  ハードディスクドライブ
214  コンパクトフラッシュ（登録商標）カード
220  ハードディスクドライブインターフェース
222  コンパクトフラッシュ（登録商標）カードインターフェース
226  オペレーティングシステム
228  アプリケーションプログラム
230  他のプログラムモジュール
232  プログラムデータ
234  入力装置
240  インターフェース
242  表示装置
244  ビデオアダプタ
252  ネットワークインターフェースまたはアダプタ
254  モデム
260  録音機
261  録音ボタン
300  開発システム
310  要件コンポーネント
320  設計コンポーネント
330  実装コンポーネント
400  パラダイム
402、403、404  イシュー
405、406、408  ポジション
410  賛成アーギュメント
412  反対アーギュメント
499  学習モデルベースライフサイクル診断システム
500  IDE
502、504  RM  
506、508、510  設計ツール
512、514、516  配備ツール
518、520、522、524、526、528、530、532、534  リンク
599  DRDリンク
600  RTE
602、606  埋め込み分散データベース
604  サーバアプリケーション
608  ブローカ
610  電子制御ユニット(ECU)
612  学習エージェント
614  エージェント
616、618、620、622、624  リンク
880  分散システム
881  データベース
882  サーバ
884  自動車
886、888、890  ツール
892  TCU  
894  ECU
900  自動車製品の開発ライフサイクル
902  開発フェーズ
904  製造フェーズ
906  サービスフェーズ
908  D-RTE(開発RTE)
910  P-RTE(製造RTE)
912  S-RTE(サービスRTE)
914  IDE
1000、1100  スパイラルライフサイクルプロセス
1302、1304、1306、1602、1604、1606  プロトタイピングサイクル
1400、1500  プロトタイプサイクル
1502、1802  IDE
1504、1804  RTE
1506、1806  DRDリンク
1700、1800  スパイラルプロセス
2012、2014  エージェント
2100  学習モデルベース診断システム
2200  診断層
2202  ソフトウェア診断エージェント
2204  ハードウェア診断エージェント
2210  自動車システム
2212  制御システム
2214  ハードウェアシステム
2216  運転者コメント
2218  制御入力
2220  自動車出力
2300  診断システム
2301  システム
2302  入力
2304  初期条件
2306  出力
2308  SOM
2310  動作可能領域
2320  自動車
2422  エンジン
2424  ドライブトレーン
2426  他のコンポーネント
2428  自動車動力学
2430  運転者
2432  環境
2500  第1のサブシステム
2502  スロットルプレートサブシステム
2504  スロットルプレートコントローラ
2506  スロットルプレート
2508  コントローラ
2510  プラント
2511  制御信号
2512  アクセルの相対位置
2514  エンジン速度
2516  スロットルプレート角度
2550  異常検出システム
2552、2554、2600  異常検出器
2700  異常検出システム
【図１】
2008517386.tif 000033
【図２】
2008517386.tif 000034
【図３】
2008517386.tif 000035
【図４】
2008517386.tif 000036
【図５】
2008517386.tif 000037
【図６】
2008517386.tif 000038
【図７】
2008517386.tif 000039
【図８】
2008517386.tif 000040
【図９】
2008517386.tif 000041
【図１０】
2008517386.tif 000042
【図１１】
2008517386.tif 000043
【図１２】
2008517386.tif 000044
【図１３】
2008517386.tif 000045
【図１４】
2008517386.tif 000046
【図１５】
2008517386.tif 000047
【図１６】
2008517386.tif 000048
【図１７】
2008517386.tif 000049
【図１８】
2008517386.tif 000050
【図１９】
2008517386.tif 000051
【図２０】
2008517386.tif 000052
【図２１】
2008517386.tif 000053
【図２２】
2008517386.tif 000054
【図２３】
2008517386.tif 000055
【図２４】
2008517386.tif 000056
【図２５】
2008517386.tif 000057
【図２６】
2008517386.tif 000058
【図２７】
2008517386.tif 000059