私の上司は、現在の状態のログは顧客に受け入れられないと言いました。障害がある場合、デバイスのさまざまなモジュールが自身のエラーを報告し、すべてがログに記録されます。障害の元の理由はリストの真ん中に埋もれているかもしれませんし、リストに表示されないかもしれません（報告するためにモジュールが壊れているかもしれません）。とにかく、ログを適切に解釈して実際に何が起きたかを考え出すことができるシステム開発者以外の人はほとんどいません。一連のイベント分析と推論
私の現在の仕事は、顧客フレンドリーなフォルトレポートを行うモジュールを作成することです。つまり、最後の〜3秒間に報告されたすべてのイベント（障害の発生元と最後に発生した後のエフェクトの最大間隔）を収集し、このデータの魔法の処理を行い、 1つの明確でフレンドリーな線。何が壊れていて、修正する必要があるか。
問題は魔法の部分です：いくつかのフォルトレポートがあれば、どのようにして元のフォールトの原因が出てくるのでしょうか。因果関係リストの簡単なリストはありません。特定の規則性を示すイベントの連鎖だけが存在します。
例：
- 短絡が制限動作モードで得られた、検出、制限された動作が障害を除去しないので、緊急状態がエスカレートされ、総出力電力が切断します。
- セーフティラインが接続されました。それが関与してから3年以内にそれを関与すると報告されたモジュールはないため、「不明な情報源または干渉」がシステム停止の原因となっています。
- ほとんどの出力モジュールは出力電圧を報告しません。約1秒後、電源監視モジュールは電源が切れていると報告しますが、これが元の理由です。
- 出力モジュールは、すべての出力ラインに出力電圧を報告しません。電源モジュールからの報告はありません。その理由は、モジュールから切り離された電源ラインです。
- 出力モジュールは出力ラインの1つに出力電圧を報告しません。その他の障害は報告されていない。理由は燃えたヒューズです。
- 出力モジュールは受信状態を適用して戻って報告しませんでした。直後に、制御モジュールは不正な状態または出力ラインを報告します（出力モジュールが実際に状態を適時に更新しないことに起因します）。原因は制御モジュールではなく出力モジュールです障害が検出されたことに起因するシステム）。
- 入力モジュールの障害により、デバイスがバックアップフェールセーフモードに切り替わります。現在使用されていない出力モジュールが故障しており、このモードでは故障モードがエスカレートしてクリティカルになります。元の理由は入力ではなく、障害に関する偽陽性を報告することができますが、操作を中断したバックアップ出力が壊れています。
- 最後の2秒間は、出力モジュールからのアクティビティはありません。これは故障していることを意味し、故障モードに入る必要があります。
何が原因なのかに関する包括的なリストはありません。新しい種類の障害が「野生で」発生し、診断され、修正されると、ルールが追加されます。これらのエラーのうちのいくつかはヒューリスティックスです。このエラーがこれらのエラーに付随している場合、そのエラーは最も可能性が高いです。いくつかの障害は解決されません - モジュールレポートの穏やかなリストで十分です。いくつかの答えはあいまいであり、1つの症状は2つの異なる不具合を示唆することがあります。これは、「保証されたソリューション」よりも「ベストエフォート」の方が優れています。
（過度に一般的で曖昧な）質問については、これを解決するにはどうすればよいですか？この種の問題に対する特定のアルゴリズム、方法、または一般化されたソリューションがありますか？どのように一般化されたルールセットを書いて、それらに対してマッチするのですか？どのようにソフトマッチングを行うには？ （例えば、入力モジュールが非常停止の真ん中で壊れた、それは無視される完全に無関係のイベントです）。
キーワード：「イベント相関」 –