特許 7105371 ソフトウェアシステムで原因および結果を決定的に報告する方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-07-13

(45)【発行日】2022-07-22

(54)【発明の名称】ソフトウェアシステムで原因および結果を決定的に報告する方法

(51)【国際特許分類】

   G06F 11/07 20060101AFI20220714BHJP

   G01N 35/00 20060101ALI20220714BHJP

【ＦＩ】

G06F11/07 190

G01N35/00 F

【請求項の数】 28

(21)【出願番号】P 2021517219

(86)(22)【出願日】2019-09-26

(65)【公表番号】

(43)【公表日】2022-01-06

(86)【国際出願番号】 US2019053296

(87)【国際公開番号】W WO2020069218

(87)【国際公開日】2020-04-02

【審査請求日】2021-06-18

(31)【優先権主張番号】62/737,691

(32)【優先日】2018-09-27

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】508147326

【氏名又は名称】シーメンス・ヘルスケア・ダイアグノスティックス・インコーポレイテッド

(74)【代理人】

【識別番号】100127926

【弁理士】

【氏名又は名称】結田 純次

(74)【代理人】

【識別番号】100140132

【弁理士】

【氏名又は名称】竹林 則幸

(72)【発明者】

【氏名】デレック・ヘインズ

【審査官】金木 陽一

(56)【参考文献】

【文献】米国特許出願公開第２０１４／００２６００２（ＵＳ，Ａ１）

【文献】特開平０４－０７６６３３（ＪＰ，Ａ）

【文献】特開２０１３－２２２３１３（ＪＰ，Ａ）

【文献】特開２０１０－１８１２１２（ＪＰ，Ａ）

【文献】特開２００２－３６２８４６（ＪＰ，Ａ）

【文献】特開２００５－１８２４６５（ＪＰ，Ａ）

【文献】特開２０１６－００４２７９（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ １１／０７

Ｇ０１Ｎ ３５／００

(57)【特許請求の範囲】

【請求項1】

ソフトウェアシステム内で原因イベントを追跡する方法であって：
複数の事前定義された原因条件の１つを満たす、該システムの演算中に発生する複数の原因イベントを、プロセッサによって識別する工程と；
実質的に固有の原因ＩＤを各原因イベントに割り当て、原因データベース内に各原因イベントに対するエントリを作成する工程と；
プロセッサによって、システム状態を記述するシステム状態値に各原因ＩＤを関連付ける工程と；
プロセッサによって、各原因ブール演算が１つまたはそれ以上の入力原因ＩＤおよび関連付けられたシステム状態値を入力として取得し、ブール値および入力原因ＩＤの選択された１つまたはそれ以上を出力する複数の原因ブール演算を実行する工程であって、それによって入力原因ＩＤが、該入力原因ＩＤに関連付けられたシステム状態値を変化させることにより出力ブール値が変化することになる場合、出力するためにプロセッサによって選択される、工程と；
該ソフトウェアシステムのユーザに対して、原因ブール演算の実行および原因データベースの内容に基づいて、該ソフトウェアシステム内のユーザに対するイベントと否定的帰結との原因関係を伝達するインターフェースを表示する工程とを含む、前記方法。

【請求項2】

原因ブール演算の少なくとも１つはＡＮＤ演算であり、出力が偽である場合、偽の入力状態に関連付けられた少なくとも１つの原因ＩＤを、出力するために選択し、出力が真である場合、少なくとも１つの入力原因ＩＤを、出力するために選択する、請求項１に記載の方法。

【請求項3】

ＡＮＤ演算は、出力が真である場合、すべての入力原因ＩＤを出力する、請求項２に記載の方法。

【請求項4】

原因ブール演算の少なくとも１つはＯＲ演算であり、出力が真である場合、真の入力状態に関連付けられた少なくとも１つの原因ＩＤを、出力するために選択し、出力が偽である場合、少なくとも１つの入力原因ＩＤを、出力するために選択する、請求項１に記載の方法。

【請求項5】

ＯＲ演算は、出力が偽である場合、すべての入力原因ＩＤを出力する、請求項４に記載の方法。

【請求項6】

原因ブール演算の少なくとも１つはＮＯＴ演算であり、出力が偽である場合、真の入力状態に関連付けられた少なくとも１つの原因ＩＤを、出力するために選択し、出力が真である場合、少なくとも１つの入力原因ＩＤを、出力するために選択する、請求項１に記載の方法。

【請求項7】

グラフィカルインターフェースにより、ユーザは、否定的帰結をクリックして、その否定的帰結に対する根本原因イベントの表示を展開しまたは折り畳むことが可能になる、請求項１に記載の方法。

【請求項8】

プロセッサは、原因ＩＤおよびシステム状態に関する１つまたはそれ以上のデータの両方を含む複数のオブジェクトを各状態オブジェクトの変数として維持することによって、原因ＩＤをシステム状態値に関連付ける、請求項１に記載の方法。

【請求項9】

非ブール原因演算を実行する工程をさらに含み、非ブール原因演算は、出力値を返し、該出力値に寄与したとプロセッサによって判定された入力値に関連付けられた原因ＩＤを選択的に返す、請求項１に記載の方法。

【請求項10】

ソフトウェアシステムは、臨床アナライザの動作を容易にする、請求項１に記載の方法。

【請求項11】

ソフトウェアシステム内で原因イベントを追跡する方法であって：
複数の事前定義された原因条件の１つを満たす、該システムの演算中に発生する複数の原因イベントをプロセッサによって識別する工程と；
実質的に固有の原因ＩＤを各原因イベントに割り当て、原因データベース内に各原因イベントに対するエントリを作成する工程と；
プロセッサによって、原因データベースを介して、原因ＩＤが割り当てられた原因イベントに起因するシステム状態を記述するシステム状態値に各原因ＩＤを関連付ける工程と；
プロセッサによって、複数の原因関数を実行する工程であって、各原因関数が、１つまたはそれ以上の入力システム状態値および関連付けられた原因ＩＤを入力として取得し、入力システム状態値の原因関数によって定義された結果および入力原因ＩＤの選択された１つまたはそれ以上を出力し、選択された入力原因値は、変化した場合に結果を変化させることになるシステム状態値に関連付けられた原因ＩＤである、工程と；
該ソフトウェアシステムのユーザに対して、否定的帰結を招いた１つまたはそれ以上の状態に関連付けられた１つまたはそれ以上の原因ＩＤおよび原因データベースの内容に基づいて、該ソフトウェアシステム内のユーザに対するイベントと否定的帰結との関係を伝達するインターフェースを表示する工程とを含む、前記方法。

【請求項12】

複数の原因関数の少なくとも１つはＡＮＤ演算であり、出力が偽である場合、偽の入力状態に関連付けられた少なくとも１つの原因ＩＤを、出力するために選択し、出力が真である場合、少なくとも１つの入力原因ＩＤを、出力するために選択する、請求項１１に記載の方法。

【請求項13】

ＡＮＤ演算は、出力が真である場合、すべての入力原因ＩＤを出力する、請求項１２に記載の方法。

【請求項14】

複数の原因関数の少なくとも１つはＯＲ演算であり、出力が真である場合、真の入力状態に関連付けられた少なくとも１つの原因ＩＤを、出力するために選択し、出力が偽である場合、少なくとも１つの入力原因ＩＤを、出力するために選択する、請求項１１に記載の方法。

【請求項15】

ＯＲ演算は、出力が偽である場合、すべての入力原因ＩＤを出力する、請求項１４に記載の方法。

【請求項16】

原因ブール演算の少なくとも１つはＮＯＴ演算であり、出力が偽である場合、真の入力状態に関連付けられた少なくとも１つの原因ＩＤを、出力するために選択し、出力が真である場合、少なくとも１つの入力原因ＩＤを、出力するために選択する、請求項１１に記載の方法。

【請求項17】

インターフェースにより、ユーザは、否定的帰結をクリックして、その否定的帰結に対する根本原因イベントの表示を展開しまたは折り畳むことが可能になる、請求項１１に記載の方法。

【請求項18】

プロセッサは、原因ＩＤおよびシステム状態に関する１つまたはそれ以上のデータの両方を含む複数のオブジェクトを原因データベース内で各状態オブジェクトの変数として維持することによって、原因ＩＤをシステム状態値に関連付ける、請求項１１に記載の方法。

【請求項19】

複数の原因関数は、出力値を返し、該出力値に寄与したとプロセッサによって判定された入力値に関連付けられた原因ＩＤを選択的に返す非ブール原因演算を含む、請求項１１に記載の方法。

【請求項20】

ソフトウェアシステムは、臨床アナライザの動作を容易にする、請求項１１に記載の方法。

【請求項21】

ソフトウェアシステム内で原因イベントを追跡する方法であって：
プロセッサによって、原因イベントデータベースを維持する工程であって、複数の原因イベントの各々に関する情報が記憶され、複数の原因イベントが各々、割り当てられた実質的に固有の原因ＩＤを有し、原因イベントの少なくともサブセットがまた各々、１つまたはそれ以上の原因イベントをその原因イベントの親原因として識別する、工程と；
プロセッサによって、少なくとも１つの事前定義された原因条件を満たす、ソフトウェアシーケンスの実行中に発生する第１の原因イベントを識別する工程と；
プロセッサによって、第１の原因イベントが１つまたはそれ以上の既存の親原因イベントの結果であるかどうかを判定する工程と；
第１の実質的に固有の原因ＩＤを原因イベントに割り当てる工程と；
少なくとも１つが判定された場合、第１の実質的に固有の原因ＩＤ、関連する状態情報、および１つまたはそれ以上の親原因イベントの原因ＩＤを含めて、第１の原因イベントに関する情報を記憶する工程と；
第１の実質的に固有の原因ＩＤをソフトウェアシーケンスの出力に渡す工程であって、ユーザにとって負の追加の原因イベントおよび状態値に遭遇する後続のソフトウェアシーケンスは、第１の原因イベントを親原因イベントとして追加の原因イベントおよび負の状態値にリンクさせることができる、工程とを含む、前記方法。

【請求項22】

ソフトウェアシステムのユーザに対して、原因データベースの内容およびユーザにとってそれらの負の状態値に関連付けられた原因ＩＤ値に基づいて、原因イベントと他の原因イベントとの原因関係、およびユーザにとって負の状態値を有する原因イベントを伝達するインターフェースを表示する工程をさらに含む、請求項２１に記載の方法。

【請求項23】

プロセッサによって、後続のソフトウェアシーケンス内で、状態値および少なくとも１つの原因ＩＤを各々含む１つまたはそれ以上の原因データ値を入力として取得する複数の原因ブール演算を実行する工程をさらに含み、原因ブール演算は各々、出力ブール値、および１つまたはそれ以上の入力原因データ値のうち、関連付けられた状態値が変化した場合に異なる出力ブール値をもたらすことになる少なくとも１つの入力原因データ値の選択に対して評価する、請求項２１に記載の方法。

【請求項24】

原因ブール演算は、変化した場合に異なる出力ブール値をもたらすことになる、各入力状態値に関連付けられた原因ＩＤをすべて、出力として選択する、請求項２３に記載の方法。

【請求項25】

原因ブール演算は、変化した場合に異なる出力ブール値をもたらすことになる複数の入力状態値が存在する場合、１つの原因ＩＤのみを出力として選択する、請求項２３に記載の方法。

【請求項26】

原因イベントを補正するために必要とされる努力量に近似する努力値が、各原因イベントに割り当てられる、請求項２４に記載の方法。

【請求項27】

原因イベントがユーザインターフェースを介してユーザに表示され、各子原因イベントが、インターフェースでその親原因イベントのすべてにリンクされる、請求項２６に記載の方法。

【請求項28】

親原因イベントの努力値がユーザインターフェースを介してユーザに表示され、ユーザは、どの親原因イベントが解決するのに最小の努力量を要するかについて近似を見ることが可能になる、請求項２７に記載の方法。

【発明の詳細な説明】

【技術分野】

【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】

【図1】いくつかの実施形態によって使用するための例示的なシステムのシステム図である。

【図2A】エラー報告に対する例示的な従来技術の手法のユーザインターフェースの図である。

【図2B】エラー報告に対する例示的な従来技術の手法のユーザインターフェースの図である。

【図2C】エラー報告に対する例示的な従来技術の手法のユーザインターフェースの図である。

【図3】依存度を示すいくつかの実施形態によって使用するための例示的なシステムの記号的システム図である。

【図4】図４Ａ～図４Ｂは、いくつかの実施形態によって使用するための例示的なシステムで発生し得る例示的な因果関係ツリーである。

【図5A】特定の例示的な実施形態におけるスレッド間の相互作用を示すタイミング図である。

【図5B】特定の例示的な実施形態におけるスレッド間の相互作用を示すタイミング図である。

【図5C】特定の例示的な実施形態におけるスレッド間の相互作用を示すタイミング図である。

【図6A】特定の例示的な実施形態におけるスレッド間の相互作用を示すタイミング図である。

【図6B】特定の例示的な実施形態におけるスレッド間の相互作用を示すタイミング図である。

【図6C】特定の例示的な実施形態におけるスレッド間の相互作用を示すタイミング図である。

【図7A】特定の例示的な実施形態におけるスレッド間の相互作用を示すタイミング図である。

【図7B】特定の例示的な実施形態におけるスレッド間の相互作用を示すタイミング図である。

【図8A】いくつかの実施形態によって使用することができる例示的なシステムにおける状態およびエラー伝搬を示す例示的な実行時間関係の依存関係図である。

【図8B】いくつかの実施形態によって使用することができる例示的なシステムにおける状態およびエラー伝搬を示す例示的な実行時間関係の依存関係図である。

【図8C】いくつかの実施形態によって使用することができる例示的なシステムにおける状態およびエラー伝搬を示す例示的な実行時間関係の依存関係図である。

【図8D】いくつかの実施形態によって使用することができる例示的なシステムにおける状態およびエラー伝搬を示す例示的な実行時間関係の依存関係図である。

【図8E】いくつかの実施形態によって使用することができる例示的なシステムにおける状態およびエラー伝搬を示す例示的な実行時間関係の依存関係図である。

【図9】いくつかの例示的な実施形態における特定の根本原因条件に基づいてユーザに表示することができる否定的帰結のタイプを示す関係図である。

【図10A】いくつかの実施形態によって使用することができる例示的なシステムにおける状態およびエラー伝搬を示す例示的な実行時間関係の依存関係図である。

【図10B】いくつかの実施形態によって使用することができる例示的なシステムにおける状態およびエラー伝搬を示す例示的な実行時間関係の依存関係図である。

【図10C】いくつかの実施形態によって使用することができる例示的なシステムにおける状態およびエラー伝搬を示す例示的な実行時間関係の依存関係図である。

【図11】いくつかの実施形態によって使用することができる例示的なシステムにおける原因状態伝搬を示す例示的な実行時間関係の依存関係図である。

【図12】システム状態と肯定的／否定的帰結との間の差を示す表である。

【図13A】いくつかの実施形態によって使用することができる例示的なシステムにおける原因ＩＤ伝搬を示す例示的な実行時間関係の依存関係図である。

【図13B】いくつかの実施形態によって使用することができる例示的なシステムにおける原因ＩＤ伝搬を示す例示的な実行時間関係の依存関係図である。

【図13C】いくつかの実施形態によって使用することができる例示的なシステムにおける原因ＩＤ伝搬を示す例示的な実行時間関係の依存関係図である。

【図13D】いくつかの実施形態によって使用することができる例示的なシステムにおける原因ＩＤ伝搬を示す例示的な実行時間関係の依存関係図である。

【図14-1】図１４Ａ～図１４Ｎは、特定の実施形態におけるソフトウェアによる出力ブール値への原因ＩＤの割当ておよびそれらの論理特性を示す例示的な原因出力表である。

【図14-2】図１４－１の続き。

【図14-3】図１４－２の続き。

【図14-4】図１４－３の続き。

【図14-5】図１４－４の続き。

【図14-6】図１４－５の続き。

【図14-7】図１４－６の続き。

【図14-8】図１４－７の続き。

【図15-1】図１５Ａ～図１５Ｆは、特定の実施形態におけるソフトウェアによる出力ブール値への原因ＩＤの割当てを示す例示的な原因出力表である。

【図15-2】図１５－１の続き。

【図15-3】図１５－２の続き。

【図15-4】図１５－３の続き。

【図16】いくつかの実施形態を実装するのに好適なシステムのシステム図である。

【図17A】いくつかの例示的な実施形態の演算の流れ図である。

【図17B】いくつかの例示的な実施形態の演算の流れ図である。

【図17C】いくつかの例示的な実施形態の演算の流れ図である。

【図17D】いくつかの例示的な実施形態の演算の流れ図である。

【図17E】いくつかの例示的な実施形態の演算の流れ図である。

【図17F】いくつかの例示的な実施形態の演算の流れ図である。

【図17G】いくつかの例示的な実施形態の演算の流れ図である。

【図17H】いくつかの例示的な実施形態の演算の流れ図である。

【図17I】いくつかの例示的な実施形態の演算の流れ図である。

【図17J】いくつかの例示的な実施形態の演算の流れ図である。

【図17K】いくつかの例示的な実施形態の演算の流れ図である。

【図17L】いくつかの例示的な実施形態の演算の流れ図である。

【図18A】否定的帰結をユーザに表示するべきかどうかを判定するために評価された例示的な原因ブール演算による例示的な原因ＩＤ伝搬およびその帰結の根本原因の論理図である。

【図18B】否定的帰結をユーザに表示するべきかどうかを判定するために評価された例示的な原因ブール演算による例示的な原因ＩＤ伝搬およびその帰結の根本原因の論理図である。

【図18C】否定的帰結をユーザに表示するべきかどうかを判定するために評価された例示的な原因ブール演算による例示的な原因ＩＤ伝搬およびその帰結の根本原因の論理図である。

【図18D】否定的帰結をユーザに表示するべきかどうかを判定するために評価された例示的な原因ブール演算による例示的な原因ＩＤ伝搬およびその帰結の根本原因の論理図である。

【図18E】否定的帰結をユーザに表示するべきかどうかを判定するために評価された例示的な原因ブール演算による例示的な原因ＩＤ伝搬およびその帰結の根本原因の論理図である。

【図18F】否定的帰結をユーザに表示するべきかどうかを判定するために評価された例示的な原因ブール演算による例示的な原因ＩＤ伝搬およびその帰結の根本原因の論理図である。

【図18G】否定的帰結をユーザに表示するべきかどうかを判定するために評価された例示的な原因ブール演算による例示的な原因ＩＤ伝搬およびその帰結の根本原因の論理図である。

【図18H】否定的帰結をユーザに表示するべきかどうかを判定するために評価された例示的な原因ブール演算による例示的な原因ＩＤ伝搬およびその帰結の根本原因の論理図である。

【図19A】否定的帰結をユーザに表示するべきかどうかを判定するために評価された例示的な原因ブール演算による例示的な原因ＩＤ伝搬およびその帰結の根本原因の論理図である。

【図19B】否定的帰結をユーザに表示するべきかどうかを判定するために評価された例示的な原因ブール演算による例示的な原因ＩＤ伝搬およびその帰結の根本原因の論理図である。

【図19C】否定的帰結をユーザに表示するべきかどうかを判定するために評価された例示的な原因ブール演算による例示的な原因ＩＤ伝搬およびその帰結の根本原因の論理図である。

【図20】特定の実施形態によって使用するための例示的なコンピューティングシステムのシステム図である。

【発明を実施するための形態】

【0030】

ソフトウェアユーザは、問題を診断および補正するためにソフトウェアによって通信される障害モードの問題解決に、膨大な量の時間を費やしている。この大量の時間は、ユーザが経験した任意の所与の障害に対して、ソフトウェアによって検出される詳細な根本原因条件を判定しようとして費やされている。

【0031】

すなわち、ユーザは多くの場合、基本的な障害または問題がどこかに存在することをソフトウェアによって知らされ、すなわち要求が失敗したことが報告され、またはシステムが将来の要求を処理するのに使用不能であることが報告されるユーザインターフェースにおける「否定的帰結」を受け、次いでそれらのユーザは、否定的帰結を表示させたソフトウェアによって検出された根本条件にその否定的帰結を再び関係付けようとして、大量の時間を費やす。ここで、「障害モード」とは、ソフトウェアによって検出される１つの可能な根本原因条件と、その条件に起因するユーザインターフェースにおける１つの可能な否定的帰結との組合せとして定義される。

【0032】

任意の所与の障害モードを修復するために、ユーザはしばしば、ユーザインターフェースレベルで経験した特有の否定的帰結から、ソフトウェアによって検出された特有のソース条件まで遡って因果関係を形成する必要がある。多くの場合、ユーザは、この関係を形成し、関連するソース条件への入力を修復して初めて、意図したとおりソフトウェアの使用を継続することができる。

【0033】

ソフトウェアの２つの共通の特性は、単一の根本原因条件が多くの異なるタイプの異なる否定的帰結を引き起こす可能性があり、これらの否定的帰結は場合により並行して発生すること、および単一の否定的帰結が多くのタイプの根本原因条件によって引き起こされる可能性があり、これらの根本原因条件もまた場合により並行して発生することである。したがって、システムにおける可能な障害モードの総数は、ソース条件およびそれらの可能な否定的帰結のすべての可能な組合せであると考えられる。適度な複雑さのソフトウェアでも、可能な障害モードの数は典型的に数百万の範囲であり、これは実際的に列挙またはドキュメンテーションするにはあまりに大きすぎる。すなわち、たとえば問題解決ガイドのためのすべての可能な障害モードの網羅的なリストを提供することは典型的に、扱いにくい問題である。扱いにくいほど多数の可能な障害モード、および後述するソフトウェアの他の特性のため、ユーザおよび開発者がこの診断関係を形成するために利用する現在の技法は、効率的なユーザ経験にとって不十分なことが多い。

【0034】

したがって、これは、ソフトウェア事業者とその顧客との両方が、どの基本ソフトウェア条件がユーザに明示的に表示するべき障害を引き起こしたかに答えようとして巨大な量の資源を費やす領域である。否定的帰結の特定の発生からその発生の特定の根本原因条件まで遡って関係を迅速かつ効果的に形成できなければ、大量の時間および金銭がかかる。多くのソフトウェアオペレータおよび技術者が、単一の画面上の障害をログ内の簡単なハードウェアエラーまたはユーザアクションまで遡って追跡しようとして、数時間または数日を費やしているところを目の当たりにするのはよくあることである。

【0035】

後述する多くの理由で、ほとんどのソフトウェアは現在、比較的制限された「成功」、「失敗」、または失敗表示のための類似のインジケータだけを提供し、ユーザが問題を修復するために必要とする実際の失敗条件に関する詳細な情報のほとんどは別の場所に提供されており、ユーザが最初に表示された否定的帰結に関係付けることは極めて困難である。この問題の例は、典型的な臨床アナライザに多い。たとえば、ほぼすべてのＵＩディスプレイは、何らかの基本的な方法で否定的帰結をユーザに通信することができるが（たとえば、患者検査の失敗、使用不能なモジュール、保守行動の失敗、使用不能な能力など）、ソース条件は多くの場合、異なるディスプレイで捕捉される（たとえば、複合型の汎用エラーログ、またはオペレーティングシステムのイベントログ内）。問題は、ソフトウェアが典型的に、様々な画面に示された否定的帰結を、イベントログディスプレイで捕捉された詳細なソース条件情報まで遡って関係付けることができないことである。これにより、顧客から製造者へ、さらに多くの場合はサービスおよび研究開発組織へ、問題のさらなる推測および拡大が生じ、これは極めて高価である。今までソフトウェアおよびユーザがこれらの関係を容易に形成することができない理由について、以下に説明する。

【0036】

この問題は、検査室診断製品に限定されるものでも、さらには医療製品または医療ソフトウェア全般に限定されるものではない。この問題は、否定的帰結をユーザに報告することができるほぼすべてのソフトウェアシステムに影響を及ぼし、それはほとんどのソフトウェアである。これは、オペレーティングシステムとそこで動作するアプリケーションとの両方を含む。

【0037】

ユーザが診断しようとしているソース原因条件の多くは、実際にはソフトウェアによって内部で検出されるが、ほぼすべてのソフトウェアシステムにおけるデータフローの複雑さ、ならびにこれらのデータフローに関するソフトウェア技術者による誤認のため、現在のソフトウェア設計は、否定的帰結が表示されているのをユーザが見たとき、これらの詳細なソース原因条件をユーザに正確または効果的に報告しない。これにより、場合により軽微で容易に補正可能な問題であると考えられるものに対して必要とされる問題解決分析の延長、およびより複雑な問題で必要とされることが多いさらなる分析のため、ソフトウェア顧客とソフトウェア提供者との両方にとって大幅なダウン時間が生じる。

【0038】

医療および他のハードウェア機器または概して機器以外のソフトウェアでユーザに通信することができる否定的帰結の例には：患者検査が開始または完了しないこと；較正またはＱＣ検査が開始または完了しないこと；試薬ローディング／アンローディングが開始または完了しないこと；消耗品の交換、プライミング、洗浄などの手動で要求された保守行動が開始または完了しないこと；自動化された保守行動が開始または完了しないこと；消耗品が空または他の状態で使用不能であることを予期せずに示すこと；モジュール状態がダウンまたは使用不能であること；モジュール能力がダウンまたは使用不能であること；サブシステムがダウンまたは使用不能であること；不能にされた（グレーアウトした）ユーザ制御；何らかの他の手動または自動で要求された動作が開始または完了しないこと；および何らかの他のシステム状態または能力がダウンまたは使用不能であることを報告することが含まれる。

【0039】

ソフトウェアによって検出されるが、多くの場合は何らかの所与の否定的帰結の発生の直接原因として通信されない一般的な根本原因条件には：任意のハードウェアエラー（アクチュエータエラー；誤ったモータまたはソレノイド位置、限界を超えた電流の引込みなどを報告するアクチュエータセンサフィードバックエラー；化学、機械、または他の問題を示す１つまたはそれ以上のセンサからの複数の読取り分析を含むデータ分析エラー；通信エラー；論理問題など）；他の要求を取り消しかつ／またはシステムを使用不能にするオペレータアクション（オペレータが「休止」または「停止」を押下する）；他の要求のためにシステムを使用不能にする保守シーケンスを実行することを求めるオペレータからの要求；システムが初期化中に他の要求された関数を処理することを使用不能にするシステムを開始またはリセットすることを求めるオペレータからの要求；何らかの期間にわたってより低い優先権の要求を打ち切りかつ／またはシステムを使用不能にするオペレータまたは他のより高い優先権の結果からの要求；オペレータがシステムを入力モード、レビューモードなどの異なるシステムモードに切り換え、それにより任意の動作もしくは制御が使用不能になること；またはオペレータがソフトウェアをインストールし、もしくはデータベース化された、もしくは他の持続データをリセットし、それにより将来の要求を処理するのにまだ好適でない初期データ条件を生じさせ、較正が実行されていないというデフォルト、消耗品が空であるというデフォルトなどを示し得ること；他の要求を取り消しかつ／またはシステムを使用不能にする行動が自動で開始されること（自動化された保守行動、自動化されたウォームアップまたはクールダウン期間、および自動化されたシステムリセットなど）；上記でリスト化した問題が１つまたはそれ以上のさらに検出された問題を下流で引き起こし、次いで否定的帰結を引き起こすエラーまたはイベントをカスケード化すること（それらの後続の実体で他のエラーまたは原因条件を引き起こす関数呼出し、データパス、スレッド、プロセス、コンピュータ、および／またはネットワークおよびネットワークノードにわたって伝搬するエラーまたは他の根本原因条件、ならびにゼロまたはより下流の否定条件へのこのカスケード化原理の再帰的または反復的アプリケーションなど）が含まれる。

【0040】

図３は、５つのハードウェア機構制御スレッド間の大きくなった依存度の例示的なグラフ１０を示す。図３に示す例では、機構Ａが根本原因エラーを有する。機構Ａが終了しておらず、他の機構がタスクを完了することを妨げるため、他のすべての機構スレッドも最終的に独自のエラーを有する。これらの問題のいくつかに対する１つの解決策は、本出願の権利者が所有し、参照によって本明細書に組み入れる、米国特許第９，２９８，５３５号に説明されている。

【0041】

因果関係ツリーを構築することもできる。このツリーの枝を観察することによって、どのエラーが他の分岐エラーの根本原因であるかを迅速に認めることができる。親が、その子の原因であると見なされる。親が定義されていないエラー（ツリーの根）は、可能な根本原因エラーと見なされる。親が定義されたエラー（枝または葉）は、確実な根本原因でないエラーと見なされる。下方へ分岐するグラフとして表現されたとき、親は、その下に位置するすべての子供に対する究極原因である。

【0042】

図４Ａは、ＧＵＩの一部としてユーザに表示することができる２つの親エラー（機構Ａのモータエラーおよび機構Ｅのホーミング失敗）を有する例示的な根本原因ツリー１４を示す。

【0043】

図４Ｂは、ユーザインターフェース上のボタンによりツリーを折り畳んで子エラーを隠すことが可能である例示的なユーザインターフェースを示し、ユーザは、可能な根本原因エラーを迅速に見て、折り畳まれた因果関係ツリー１８を作成することが可能であり、これは因果関係ツリー１４の修正された表示である。ツリーを折り畳むことで、ユーザが根本原因を急速に評価することを支援することができる。

【0044】

因果関係ツリーを構築するために、ソフトウェアは、構築時間のエラーをともにリンクさせ、次いで実行時間のエラーをともにリンクさせる能力をもたらすべきである。Ｄｉｍｅｎｓｉｏｎ Ｖｉｓｔａの例では、エラーはｔｈｒｏｗａｂｌｅクラスのオブジェクトによって表される：
class ErrorClass
{
int iErrorCode;
string strErrorDescription;
…
};

【0045】

リンク能力をもたらすために、エラークラスを２つの新しいフィールド：１）生成されたすべてのエラーインスタンスを固有に識別するｉＳｅｒｉａｌＮｕｍｂｅｒ；および２）親が既知の場合、現在のエラーの親を指すｉＰａｒｅｎｔＳｅｒｉａｌＮｕｍｂｅｒに拡張することができる。
class ErrorClass
{
int iErrorCode;
string strErrorDescription;
…
//すべてのオブジェクトインスタンスに対する固有ＩＤ
int iSerialNumber;

//親インスタンスのＳＮ。親がない場合は０に等しい
int iParentSerialNumber;

};

【0046】

この例を使用すると、次のコードを使用して、エラーをリンクしないで表示することができる。
void InitializeMechanism()
{
try
{
MoveMotor();
}
catch ( ErrorClass originalError )
{
PostErrorToUserInterface( originalError );
ErrorClass initializationError(
INITIALIZATION_ERROR );
PostErrorToUserInterface( initializationError );
}
}

【0047】

リンクされたバージョンは、次の例示的なコードを使用して親のシリアル番号を追加することによって表示することができる：
void InitializeMechanism()
{
try
{
MoveMotor();
}
catch ( ErrorClass originalError )
{
PostErrorToUserInterface( originalError );
ErrorClass initializationError(
INITIALIZATION_ERROR );
initializationError.SetParentSerialNumber(
originalError.GetSerialNumber() );
PostErrorToUserInterface( initializationError );
}
}

【0048】

親ＩＤを使用してエラーをリンクさせるための複数の解決策が存在する。これはエラータイプに依存する。エラーをリンクさせる一般的な方策は、コード内でエラー発生点を発見し、エラーが親エラーによって引き起こされた子であるかどうかを判定し、その場合、子に対する親のシリアル番号を得る方法を見出すことである。

【0049】

単一スレッドのエラー間のリンクは、関連付けられたエラーコードおよびイベントとともにコールスタックの上下にシリアル番号を渡すことによって実現することができる。クロススレッドエラー（タイムアウト、スレッド割込み）は、それよりやや扱いにくい傾向があるが、いくつかの実施形態では取り扱うことができる。例示的なクロススレッドエラーには、タイムアウトエラー、一方向信号のタイムアウトエラー、およびスレッド割込みエラーが含まれる。

【0050】

図５Ａは、物理的共有空間を保護するためにミューテックス２５を使用してスレッドＡ２２とスレッドＢ２４との間の例示的な相互作用２０を示す。この図で、スレッドＡ２２はミューテックス２５をロックしながら空間内でその仕事を実行し、次いでミューテックスを解放する。スレッドＢ２４は、スレッドＡ２２がミューテックス２５を解放するのを待ってから、空間内でその仕事中にミューテックスをロックし、次いでその仕事が完了した後にミューテックスを解放する。

【0051】

図５Ｂは、ミューテックス２５の結果、スレッドＡ２２がモータエラー３２に遭遇した後、スレッドＢ２４が演算に成功するまでの時間内に、スレッドＡ２２がミューテックス２５を解放することができないため、スレッドＢ２４にタイムアウトエラー３４が生じる例示的な相互作用３０を示す。

【0052】

これらのエラーをリンクさせることを容易にするために、ミューテックスクラスを拡張して、エラーシリアル番号を記憶し、タイムアウト時の現在のエラーシリアル番号を返すことができる。この概念は、米国特許第９，２９８，５３５号にさらに詳細に議論されている。これは、次の例示的なコードを含むことによって実現することができる。
class Mutex
{
…

int iErrorSerialNumber;

//偽が返された場合はタイムアウトし、iSerialNumberは
//親エラーシリアル番号に等しい。
bool AcquireMutex( [out] int & iSerialNumber );

};

【0053】

これを使用して、何らかのエラー取扱いルーチンの一部としてエラーが発生した後、現在のスレッドによって獲得されたすべてのミューテックスにエラーシリアル番号を押し込むことができる。次いで、別のスレッドがミューテックスを獲得しようとしたとき、ＡｃｑｕｉｒｅＭｕｔｅｘルーチンがタイムアウトを返すと、ミューテックスに保存された有効なエラーシリアル番号も親エラーとして返すことができる。これは次いで、その第２のスレッドで何らかのエラー取扱いルーチンに沿って渡すことができる。

【0054】

各スレッドは、インテントリストを使用して、獲得されたすべてのミューテックスを追跡することができる。インテントリストは、現在のスレッドによって保持されている、何らかの他のスレッドが信号のオン状態を待っている可能性のあるすべてのオブジェクトを表すために使用することができる。これは、「インテント信号」リストまたは「インテント」リストと呼ぶことができる。インテントリストは、他のスレッドが待っている可能性のある項目を追跡することができる。各リストは、スレッドローカルとすることができ、スレッドごとに１つのリストが存在することができる。インテントリスト内のすべての項目は、エラーシリアル番号を保存して、それらの同じ項目に依拠している可能性のある他のスレッドにエラーを伝搬する能力を実装するべきである。インテントリストとともに使用することができるいくつかの例示的なコマンド（自己記述名を有する）は次のとおりである：

【0055】

ａ）ミューテックスを獲得したとき：ＡｄｄＴｏＩｎｔｅｎｔＬｉｓｔ（ｓｉｇｎａｌａｂｌｅ＿ｉｔｅｍ）、たとえばミューテックス、信号、イベント；

【0056】

ｂ）ミューテックスを解放したとき：ＲｅｍｏｖｅＦｒｏｍＩｎｔｅｎｔＬｉｓｔ（ｓｉｇｎａｌａｂｌｅ＿ｉｔｅｍ）およびＳｅｔＳｎＯｎＩｎｔｅｎｔＬｉｓｔ（ｓｅｒｉａｌ＿ｎｕｍｂｅｒ）（現在リストにある各項目に対して特別な「エラーなし」エラーシリアル番号（たとえば、ヌルまたはゼロのシリアル番号）を保存する）。

【0057】

ｃ）何らかのエラーに遭遇したとき：ＳｅｔＳｎＯｎＩｎｔｅｎｔＬｉｓｔ（ｅｒｒｏｒ．ＧｅｔＳｅｒｉａｌＮｕｍｂｅｒ（））（インテントリスト内のすべての項目、すなわち現在のスレッドによって現在獲得されているすべてのミューテックスに対してエラーシリアル番号を保存する）。

【0058】

ｄ）ミューテックスタイムアウトエラーに遭遇したとき：ミューテックスにタイムアウトエラーの親として保存されているシリアル番号を使用する。

【0059】

図５Ｃは、ミューテックスおよびモータエラーによってエラーを伝搬するためにこれらのコマンドのいくつかをどのように使用することができるかを示す。状況３６では、スレッドＡ２２がモータエラー３２に遭遇したとき、ミューテックス２５にエラーシリアル番号を入れる。スレッドＢ２４がミューテックス２５を待っている間にタイムアウトエラーに遭遇したとき、エラーシリアル番号を取得し、そのシリアル番号をエラー通知とともに渡して、モータエラー３２をタイムアウトエラー３４の根本原因エラーとして後の分析中にリンクさせることを可能にすることができる。

【0060】

信号伝達可能なオブジェクトはまた、エラー伝搬によって強化することができる。図６Ａは、信号オブジェクトを使用して２つのスレッド間の例示的な相互作用４０を示す。この例では、信号伝達オブジェクト４５を使用して、スレッドＡ４２からスレッドＢ４４へ信号を渡す。これは、スレッドＡが特定の仕事を完了したことをスレッドＢに知らせるハンドシェークと同様に作用することができる。スレッドＢ４４は、結果として生じる仕事の実行へ進む前にスレッドＡ４２によって後に送られる信号を待つ。スレッドＢ４４は、スレッドＢ４４がスレッドＡ４２の信号伝達を待つ時間量を制限することができるように、タイムアウト閾値を有することができる。

【0061】

図６Ｂは、モータエラーのためにスレッドＡからスレッドＢへ信号が送られない場合にスレッドＡ内のモータエラー５０によって引き起こされるスレッドＢ内のタイムアウトエラー４８の一例による相互作用４６を示す。信号タイムアウトをリンクさせることは、ミューテックスタイムアウトをリンクさせることに非常によく類似している。ミューテックスクラスと同様に、信号クラスを拡張して、シリアル番号を設定することを可能にすることができる。信号オブジェクトは、各仕事ユニット中の適当な時点でインテントリストに追加および削除することができる。

【0062】

図６Ｃは、スレッドＡ４２からスレッドＢ４４へエラーシリアル番号を渡すことを可能にするように修正された信号オブジェクトの一例による相互作用５２を示す。この例では、第１のスレッドＡ４２が信号オブジェクトをそのインテントリストに追加する。モータエラーが発生したとき、スレッドは、エラーシリアル番号（１０５）をそのインテントリスト内の各オブジェクト（信号４５など）に渡し、これは、エラーシリアル番号を信号オブジェクトに渡すことを含む。次いでスレッドＡ４２は、オブジェクトの信号伝達を遅延させた何らかのエラー取扱いを終了したとき、信号オブジェクトをそのインテントリストから削除する。第２のスレッドが信号オブジェクトを待っている間にタイムアウトエラーに遭遇したとき、エラーシリアル番号を発見し、その情報をエラー取扱いルーチンで渡すことができる。信号伝達する仕事ユニットを開始したとき、例示的なスレッドはＡｄｄＴｏＩｎｔｅｎｔＬｉｓｔ（ｓｉｇｎａｌ）を実行する。信号を設定するとき、スレッドはＲｅｍｏｖｅＦｒｏｍＩｎｔｅｎｔＬｉｓｔ（ｓｉｇｎａｌ）を実行し、信号オブジェクト内のシリアル番号を０に設定する。何らかのエラーに遭遇したとき、スレッドはＳｅｔＳｎＯｎＩｎｔｅｎｔＬｉｓｔ（ｓｎ）を実行し、それによりインテントリスト内のすべての項目（すなわち、現在のスレッドによって信号伝達されることが意図されたすべてのミューテックスおよび信号）にエラーシリアル番号を保存する。エラー取扱いが終了したとき、スレッドはＲｅｍｏｖｅＦｒｏｍＩｎｔｅｎｔＬｉｓｔ（ｓｉｇｎａｌ）を実行する。信号タイムアウトエラーに遭遇したとき、各スレッドは、信号オブジェクトからタイムアウトエラーの親として返されたシリアル番号を使用する。

【0063】

スレッドはまた、スレッド割込みエラーに遭遇する可能性がある。スレッド割込みは典型的に、別のエラーまたはイベントに応答して、スレッド演算を打ち切るために使用される。これらのエラーは多くの場合、スローされた例外または返されたエラーフラグとして現れ、したがって多くの場合、割り込まれたスレッドによってエラー取扱いで処理される。したがって、割込みによってスレッドを打ち切った親エラーまたはイベントをリンクさせることが望ましい。

【0064】

図７Ａは、スレッド割込みエラーを追跡するという従来の問題の一例を示す。状況５４で、スレッドＡは、モータエラー５０が発生した後、スレッドＢのスレッドオブジェクト５６に割込み要求を送信することができる。その間にスレッドＢは、そのスレッドオブジェクト５６を割込みに関して定期的にポーリングする。割込みに遭遇したとき、スレッドＢは打ち切られ、割込みエラー５８に対するエラー取扱いを実行する。

【0065】

図７Ｂは、スレッドＡが割込みを送信したときにエラーシリアル番号を引数として受信し、スレッドＢが割込みに遭遇したときにスレッドオブジェクト６２からエラーシリアル番号を受信することを可能にする修正されたスレッドオブジェクト６２による類似のプロセス６０を示す。したがって、割込みエラー５８を取り扱うとき、スレッドＢは、割込みをスレッドＡに原因としてリンクさせることができる。

【0066】

割込み要求によってシリアル番号を設定し、スレッドが割込みを受信したときに受信したシリアル番号を返すことを可能にするように、割込みシステムを実装するスレッドクラスを修正するために、例示的なスレッドクラスは、次の関数を含むと定義することができる。
class Thread
{
…

int iInterruptErrorSerialNumber;

void Interrupt( int iSerialNumber );

//真が返された場合は割り込まれ、
//iSerialNumberは親エラーシリアル番号に等しい。
bool CheckForInterrupt( [out] int & iSerialNumber );
};

【0067】

上記は、スレッド間でエラーシリアル番号を渡すことを可能にし、親イベントおよび子イベントを識別し、親イベントをネストして識別するようにユーザに表示することを可能にすることができるが、この解決策は、競合状態を含む可能性があることに留意されたい。すなわち、別のスレッドが共有同期オブジェクトにエラーシリアル番号を設定することが可能になる前に、タイムアウトが発生する可能性がある。この場合、子に対して親が識別されず、したがってこの子がツリーの根であると見なされる。これらのシステムはモータおよび他のハードウェアとインターフェースするため、タイムアウト制限が従来のソフトウェアアプリケーションより実質的に長くなる可能性がある。

【0068】

さらに、ソフトウェアによってユーザに提供される挙動契約では、根本原因を検索するとき（何らかの原因の検索ではない）、子として識別された何らかのエラーが明確に根本原因ではないと見なされ、親エラーは子供の原因であることが知られているが、子の究極の根本原因であるかどうか分からないため、競合状態は特に問題でない可能性がある（たとえば、特に構成要素の物理的相互作用が他の構成要素内でエラーを引き起こしたハードウェアシステムにおいて、相互作用がソフトウェアによって予想されていない場合、親はソフトウェアによって識別されなかった別の根本原因の子の結果である可能性がある）。したがって、子からそのツリーの根までリネージ内のすべてのエラーは、その子の原因と見なされるが、そのリネージの究極の根は、最終的な根本原因であるかどうか分からない。多くの場合、それでもなお、親のリネージの少なくとも一部を知ることは、それによりユーザが真の根本原因の発見にはるかに迅速に近づくことから役に立つ。

【0069】

エラーは、予期された状態と実際の状態との間の不整合として理解することができる。将来のエラーを引き起こし得るものにエラーによって状態が変化したとき、ソフトウェアは、そのエラーのシリアル番号を、その状態に基づく将来のエラーに対する状態とともに通信することができる。この予期しない状態が、通常はエラー自体と見なされないときでも、通信することができる。従来、タイムアウトエラーは、必ずしもデイジーチェーンを行わないことから問題となる可能性があり；依存スレッドは、それらのスレッドが依存するスレッドの前にタイムアウトする可能性がある。これは、エラーシリアル番号を共有オブジェクトに入れたとき、依存スレッド内でエラーを即座にトリップするコードを含むことによって軽減することができる。したがって、タイムアウト制限に当たる前に、子エラーをスローすることができる。これは、強化されたスレッド同期クラスを使用して実装することができる。さらに、イベントまたはエラーシリアル番号などのそれらのプリミティブに従来記憶されないデータをアトミックに記憶するように、システム内でプリミティブ演算が修正された場合、エラー／イベントのシリアル番号をより広範に伝搬することができる。修正されたプリミティブクラスを使用することで、システムに性能のオーバーヘッドを加えることができるが、機械的機構を制御するシステムは、システムのコンピューティング能力に対して高い性能要件を有していない可能性があり、強化されたプリミティブの追加の負担を取り扱うのに十分なコンピューティング時間が可能になる。

【0070】

これらの基本的な概念について、エラーに関して説明したが、これらの原理は、システム内に因果関係を有する任意のタイプのイベントに適用することができることを理解されたい。したがって、ユーザアクションまたは他のイベントによって引き起こされたが、必ずしもまたは通常は誤っていると見なされていないエラーを、必ずしもエラーでないイベントまで追跡することができる。

【0071】

任意のソフトウェアシステムに対する原因および結果の可能なパスウェイを簡略化した例示的なグラフが、図８Ａに示す原因および結果グラフ７０である。図の左端の各ノード（円）は、上に挙げた例（たとえば、ハードウェアエラー、オペレータアクションなど）に応じてソフトウェアによって検出された可能なタイプの根本原因条件（ソース条件７２）を表す。現実のソフトウェアシステムは、数十、数百、またはそれ以上のこれらの可能な条件を有することができる。右端の各ノード（否定的帰結７６）は、上に挙げた例（異なるユーザ要求の処理の失敗、使用不能な異なるサブシステムなど）に応じてユーザに表示される可能なタイプの否定的帰結を表す。現実のソフトウェアシステムは、数十、数百、またはそれ以上のこれらの可能な否定的帰結を有することができる。中心領域の各ノード（中間データおよび実行パス７４）は、左側のソース条件による直接または間接の影響を受けており、右側の否定的帰結を直接または間接に引き起こす可能性があるデータまたは実行パスウェイ（データ変数、データオブジェクト、持続データ、ネットワークデータ、関数呼出し、条件文、コードブロックなど）を表す。現実のソフトウェアシステムは、数百、数千、またはそれ以上のこれらの中間パスウェイを有することができ、多くの場合は有している。矢印は、ノード間の原因および結果のパスを表し、矢印（の左端）から指し示されたノードは、因果関係の原因を表し、矢印（の右端）へ指し示されたノードは、因果関係の帰結を表す。実際的に、因果関係の帰結による影響を受けたノードは、そのノードの状態の変化：そのノードによって表されるデータ値の変化、またはそのノードによって表される関数、条件、コードブロック、演算などの実行もしくは不実行の変化を示すことになる。

【0072】

図８Ａの図は非常に簡略化されていることに留意されたい。現実のソフトウェアシステムはまた、多くの場合、追加のカスケード化イベント条件およびさらなる可能なパスを引き起こすために、右側のノードから左側のノードへ戻る矢印を伴うフィードバックループを有する。この図によって実証するように、任意の所与のソフトウェアシステムには原因および結果の多くの複雑なパスが存在し、これらのパスは多くのサブパスおよびサブセグメントに分割される。

【0073】

上記の「障害モード」の定義に応じて、ソース条件から否定的帰結への単一のパスは、図８Ｂに単一の失敗パス７８によって示すように、単一のタイプの障害モードを示す。

【0074】

全体的な問題には、その全体的な問題を解決する複雑さに著しく寄与する根本原因イベントまで遡ってユーザに対して否定的帰結を自動で関係付けるという複数の技術的な副次的問題がある。

【0075】

副次的問題＃１：因果パスの複雑さ。根本原因（ソース）条件と否定的帰結との間の関係は、多対１、１対多、および共有パスの挙動を呈する可能性があり、多くの場合は呈する。多対１の関係の一例として、１つのタイプの否定的帰結だけに関連付けられたソース条件が、複数ソースの失敗パス８０によって図８Ｃに示されている。図８Ｃで、ソース条件は、右側の否定的帰結を選び、その帰結のすべての可能な原因を左側へ遡って追跡することによって発見された。

【0076】

図８Ｄは、１対多の関係の一例である。左側の１つのタイプのソース条件だけに関連付けられた否定的帰結が、右側に位置する。否定的帰結は、左側のソース条件を選び、そのソース条件のすべての可能な帰結を右側へ進んで追跡することによって発見された。単一ソース、複数エラーの失敗パス８２は、単一の根本原因が多くのエラーを引き起こす可能性があることを示す。

【0077】

図８Ｅは、共有パス挙動の一例であり、２つの異なるソース条件が各々、２つの異なる否定的帰結をもたらすが、それら２つの異なるソース条件間で１つまたはそれ以上の因果パスウェイを共有する可能性がある。中心ノードは、共有パスウェイを有する。複数ソース、複数エラーの失敗パス８４は、複数の根本原因が多くのエラーを引き起こす可能性があり、中間ノードで単一の失敗パスを共有する可能性があることを示す。

【0078】

ソフトウェアにおける原因および結果のこれらの特性のうちのどの単一の特性も、何らかの所与の否定的帰結が発生した場合に、実際のソース条件をユーザに正確に報告するという全体的な問題を解決するのに重大な妨げになることになる。これらの特性はすべて、根本的な問題のために解決しなければならない解決策への従来の試みでは手に負えない点まで、非常に複雑な挙動をもたらす。

【0079】

副次的問題＃２：多すぎる可能な障害モード。図９は、異なる根本原因条件８６が複数の異なるタイプの否定的帰結８８をどのように引き起こす可能性があるかを示す。根本原因条件８６にリスト化された各根本条件は、概略的なクラスの条件であり、各クラスは、数百または数千のより詳細な実際の根本条件を含み得る。否定的帰結８８にリスト化された各否定的帰結は、概略的なクラスの否定的帰結であり、各クラスは、数百または数千のより詳細な実際の否定的帰結を含み得る。中程度またはそれ以上に複雑なソフトウェアシステムの場合、これによりユーザにとって根本原因条件および否定的帰結の可能な組合せが文字通り数百万になる。これらの可能な組合せが数百万になることで、可能な障害モードをすべて記述するために効果的なドキュメンテーションを作成することが妨げられ、このドキュメンテーション経路が真に包括的な問題解決のための実行可能な手段になることが妨げられる。また、組合せ数が多いことで、すべての可能な組合せが自動表示のためにソフトウェア内で明示的に列挙されまたは他の方法で捕捉されることが妨げられ、これはソフトウェアにおける問題解決の複雑さに著しく寄与する。

【0080】

副次的問題＃３：実際の原因および結果は、周辺のシステム状態に応じて変動する可能性がある。同じ単一の根本原因条件の様々な発生が検出されることで、システムの残り部分の現在の状態に応じて、０、１、２、またはそれ以上の否定的帰結が任意に引き起こされる可能性がある。すなわち、根本原因条件と否定的帰結との関係は、任意の所与の時点で、その時間に存在する他の任意の演算条件または状態に基づいて、一見ランダムになることが多い。図１０Ａ～図１０Ｃは、同じ厳密なソース条件「Ｄ」が３つの異なる時間に発生するが、各時間に３つの異なる全体的な帰結が生じた一例である。図１０Ａは、最初に発生するソース条件Ｄの結果を示す。この場合、Ｄの第１の発生は、タイプ「Ｕ」および「Ｘ」の２つの否定的帰結を引き起こす。図１０Ｂは、中間状態または条件の何らかの任意の差のため、ソース条件Ｄの第２の発生が否定的帰結の発生を一切招かない事例を示す。図１０Ｃは、ソース条件「Ｄ」の第３の発生がさらに第３の全体的なタイプの帰結を発生させ、これが否定的帰結「Ｚ」であった第３の事例を示す。Ｚのこの単一の否定的帰結は、２つの帰結ＵおよびＸを発生させたＤの第１の発生とは異なることに留意されたい。この一例は、劣化し始めて断続的に動かなくなり、断続的なエラーを生成し、次いでそのようなエラーからユーザの介入なく自動で回復するモータである。そのモータを必要とする２つの患者検査「Ｕ」および「Ｘ」が実行されている間にモータエラーが発生した場合、ＵおよびＸはモータのために失敗する。この場合、このモータエラーを２つの患者検査の失敗の原因として報告したいと考える。後に、システムがアイドル状態にあり、モータが比較的重要でない自動のすすぎルーチン中にエラーが生じたが、自動で回復した場合、このエラーに対する否定的帰結はなく、モータエラーをユーザに直接報告する必要はない（ただし、通常はそれでもなお内部でログ記録されることになる）。後に再び、エラーが全体的なシステム停止「Ｚ」を引き起こすことが定義されたスタートアップ初期化プロセスをシステム全体が受けており、モータエラーが発生した場合、システム全体が停止し、そのモータエラーをその全体的なシステム停止の原因として報告したいと考える。これらは、同じ共有ソース条件（モータが問題を有しているかどうかを確認するソフトウェアコード）が、システム内の他の状態に応じて異なる帰結を引き起こす可能性がある例である。したがって、所与のソース条件の帰結は常に演繹的に予測することができるとは限らない。

【0081】

概して、根本原因条件が発生したことだけで、そのために否定的帰結が常に発生することを意味するものではなく、否定的帰結が生じるたびに同じ否定的帰結が発生するわけでもない。したがって、すべての可能な根本原因条件、特に否定的帰結を引き起こさなかった条件の発生をユーザに常に表示することは、誤解を招くような多くの情報をユーザに与え、したがって場合により問題解決の負荷を低減させるのではなく増大させる可能性がある。

【0082】

理論上、この問題に対する解決策は、該当するときにのみ根本原因条件をユーザに直接報告するべきであり、結果が一切ないとき、または現在ユーザによって診断されている否定的帰結に対する結果がないときは報告するべきでない。この問題は、根本原因条件が様々なコード設計を伝搬する方法、および任意の所与の障害モードを左右する中間状態を要因として含む他の条件の数から導出される。これは、全体的な問題に対する確実な解決策を提供するために対処しなければならない重大な複雑化要因である。

【0083】

副次的問題＃４：根本原因条件の結果が無制限である。根本原因条件と否定的帰結との関係は、時間に関して無制限である。過去数秒、数分、数時間、または数日生じた根本原因条件は、システムで新しい要求がなされると新しい否定的帰結を生成し続ける可能性がある。たとえば、単一の発生の結果が最初に何らかの中間ノードで止まるが（たとえば、図１０Ｂのように）、将来の遅延失敗を発生させる可能性がある何らかの状態をそのノードに設定する（たとえば、条件Ｄの単一の発生に関するが、図１０Ｃ）ソース条件を考慮されたい。たとえば、ソース条件が発生してから１時間後、ユーザは、そのノードの状態を確認することを求める要求を行い、その状態がソース条件によってその要求にとって何らかの否定に設定されていたことから、ユーザは否定的帰結（図１０Ｃの否定的帰結Ｚなど）を経験する。この例では、さらに時間を進めると、ソース条件が発生してから丸１日後、ユーザは、別の種類の要求を行い、別のタイプの否定的帰結を経験する（たとえば、帰結Ｚに加えて否定的帰結Ｖをもたらす）。最後に、１カ月後、別のユーザ要求に対して同じことが再び生じ、中間状態を依然として解決することができないことから、このユーザ要求は失敗する（たとえば、否定的帰結Ｗを同様に引き起こす）。この問題は、任意の所与のデータまたは実行状態に対する根本原因条件の結果が無制限に持続することができる方法から導出され：根本原因条件が否定的結果をもたらす可能性がある時間量は、その根本条件によって引き起こされた中間の否定状態が持続する長さによって判定され、この長さは、当該ソフトウェアの設計に基づいて、未知、予測不能、および／または無制限であることが多い。これは、全体的な問題に対する確実な解決策を提供するために対処しなければならない重大な複雑化要因であり：否定的帰結の原因は、この問題を問題解決しようとしているユーザによって予期され得る場合よりさらに時間的に過去に生じた根本原因条件の発生まで遡ることができる。

【0084】

副次的問題＃５：二重性の因果パスウェイ。障害モードはまた、ある領域では何らかの所望の肯定的帰結を実現しているが、何らかの他の領域では否定的帰結にも同時に寄与していることがあるスタートアップ、初期化、自動化された保守行動、より高い優先権のユーザ要求などの「肯定パス条件」によって引き起こされる可能性がある。図１１は、否定的帰結だけではなく、ソース条件と肯定的帰結８９および否定的帰結７６の両方との間の例示的なパスのグラフである。見て取ることができるように、単一のソース条件が、肯定的帰結および否定的帰結の両方の組合せを招く可能性がある。これは、肯定的帰結および否定的帰結の両方を引き起こす可能性がある根本原因条件をどのように分類または報告するか、ならびにその報告でさえするべきかどうか、またはいつ報告するべきかがはっきりしないことが多いため、追跡するのが困難な可能性がある。肯定的帰結は、修復する必要のある問題を表さないユーザに対するシナリオ：たとえばユーザの要求が予期されたとおり成功したこと、またはサブシステム状態が予期されたとおりであることなどを示すユーザに表示されるユーザインターフェースとして定義される。場合により同時に肯定および否定の両方である根本原因条件の二重性は、この問題を解決することの複雑さに著しく寄与する。

【0085】

より具体的な例として、次の簡単な特性を有するソフトウェアモジュールを考慮されたい。モジュールは、そのモジュールに要求することができる２つの関数を有し：患者検査を実行することができ、または診断検査を実行することができる。モジュールは「モジュール状態」変数を有し、この変数には２つの可能な状態：実行または停止がある。モジュールが患者検査するには、モジュールは実行状態になければならない。したがって、ユーザが患者検査を実行することを要求し、モジュールが実行状態にある場合、成功が表示され；モジュールが実行状態にない場合、失敗が表示される。

【0086】

モジュールが診断検査を実行するには、モジュールは停止状態になければならない。したがって、ユーザが診断検査を実行することを要求し、モジュールが停止状態にある場合、成功が表示され；モジュールが停止状態にない場合、失敗が表示される。

【0087】

ここで、「モジュール状態」変数は、患者検査を実行することができるか、それとも診断検査を実行することができるかに関する二重性原因条件である。モジュールが実行状態にあるとき、これは患者検査を実行するには良好であるが、診断検査を実行するには不良である。逆に、モジュールが停止状態にあるとき、これは患者検査を実行するには不良であるが、診断検査を実行するには良好である。

【0088】

図１２に示す表は、この変数の二重性を実証しており、その２つの異なる可能な値は各々、肯定的帰結および否定的帰結をもたらす可能性がある。任意の所与の時点にモジュール状態変数の値が良好であるか、それとも不良であるかは、任意の所与の時点に下流で要求されているものの内容に排他的に依存する。すなわち、状態変数の現在の値が肯定的帰結を招く可能性もある場合、その状態変数の値に基づく何らかのエラーの根本原因は、通常はエラー自体と見なされない。これは典型的に、同じ原因条件が肯定的帰結にも任意に寄与する可能性があるため、否定的帰結に対する原因条件を外へ通信するという全体的な問題を解決しようとする開発者を混乱させる。現実の例は、これより複雑になる可能性があり、多くの場合はこれより複雑であり、所与の変数で３つ以上の値が可能であり、２つ以上の変数が何らかの所与の肯定的帰結および否定的帰結のシナリオに寄与する。したがって、このように二重性があり、同時に正／負になる、内容に依存する値のこの複雑化要因は、全体的な問題に対する解決策を提供することにとって重大な妨げになっている。

【0089】

副次的問題＃６：任意の構成および複雑さの演算および式による正しい原因メタデータの伝搬。いくつかの実施形態は、参照によって本明細書に組み入れる米国特許第９，２９８，５３５号に記載されている技法を活用および拡大することによって、上述した主な報告問題を解決する。例示的な技法は、ここで「原因ＩＤ」と再定義および再命名された固有の「エラーシリアル番号」を様々なコードパスに付与して、主に複数のスレッドによって共有されるオブジェクトを通じて原因ＩＤを渡すことによって、複数のエラーインスタンス間で親子因果関係を確立するのを助けることを含む。これを実装することで、複数の因果パス入力が１つまたはそれ以上の演算で収束して複合型の因果パス出力を形成するとき、単一の複合出力の状態が複数の入力の状態に任意に依存する場合、該当する正しい原因ＩＤをどのように正確に計算および伝搬するかに関して別の副次的問題が明らかになる。

【0090】

これらの収束点の多くは、ブール、比較、算術、および他の演算から構成された複合式など、任意の構成および複雑さの式である。トップレベルの式、その部分式、およびその部分演算は通常、入力値の何らかの複合操作を表す出力値を生じさせることが予期される。次いで、式全体が、適当な原因ＩＤを入力値から出力値に付与する必要がある。これらの場合、式に対する異なる複数の入力値に関連付けられた複数の異なる原因ＩＤが存在する可能性があり、多くの場合は存在する。したがって、式および演算は、出力値への伝搬のために複数の入力の中からどの原因ＩＤを含むかを判定するべきであり、誤った根本原因がユーザに通信されることを防止するために、入力からのどの原因ＩＤを出力値から除外するかを判定するべきであることも同じように重要である。

【0091】

因果パスが流れる演算および式の例には、様々なブール演算および式、比較演算および式、列挙状態演算および式、算術演算および式などが挙げられる。これらの個々の演算のほとんどは、場合により異なる原因ソースから２つまたはそれ以上の入力を取得して、単一の原因出力を生じさせる。このとき、データおよび実行パスに原因ＩＤを付与することは、式または演算が原因ＩＤのうちのゼロ、いくつか、またはすべてを出力へ伝搬する必要があることを意味する。ソフトウェア内の多くの式は、これらの演算のうちの２つまたはそれ以上から構成されており、その結果、多くの場合は３つまたはそれ以上の入力から構成される複合式が得られる。蓄積または「畳み込み」式は、多くの場合、数十、数百、またはそれ以上の入力から構成することができる。

【0092】

複数入力の原因から単一出力の結果へのこれらの収束点は、間違った原因を出力の結果として報告することを避けるために、原因情報を故意に廃棄しなければならないことがある。これらの包含／除外の決定は、入力値および出力値が評価間で異なり得るため、同じ式の複数の評価によって異なる可能性があることが重要であることに留意されたい。従来、どの原因メタデータが任意の所与の演算を伝搬するかに関してこれらの決定をどのようになすべきか明らかでない（または考慮されてもいない）。

【0093】

上記の副次的問題５はこの問題を複雑にしており、単一のデータ状態（または式）の実際の値が、肯定的帰結および否定的帰結の両方に同時に寄与するという二重性を有することがある。任意の所与の複合式の入力および／または出力がその式を横切るときに肯定的帰結をもたらすか、および／または否定的帰結をもたらすかを個々に追跡しようとすることは扱いにくい問題であり：一般的な解決策として、これは開発の観点から法外に複雑かつ高価になる可能性がある。

【0094】

この問題を示すために、２つの入力変数に基づいて簡単なブール式に集まる次の２つの入力例を考慮されたい。何らかのシステムが使用不能になったとき、エラー例外をスローするソフトウェアモジュールを考慮されたい。ここで、システムが使用可能であるかどうかを判定する関数は、２つの基本的なブール変数に基づいて簡単なブール式の値を単に返すことが任意に定義される。次の擬似コードがこれを示している。
//システムが使用可能であるかどうか
//を判定する要因として含まれる２つの値。
bool bValue1 = ...;
bool bValue2 = ...;


///////////////////////////////////////////////////////
//
//システムが使用可能であるかどうかを返す。
//
bool IsSystemAvailable()
{
return (bValue1 && bValue2);
}


///////////////////////////////////////////////////////
//
//システムが使用不能である場合、例外をスローする。
//（たとえば、患者検査を実行する前に確認する。）
//
void ThrowErrorIfUnavailable()
{
bool bSystemAvailable = IsSystemAvailable();

if ( ! bSystemAvailable )
{
Exception AvailabilityError(
"System is unexpectedly unavailable.");

throw AvailabilityError;
}
}


////////////////////////////////////////////////////////
//
//システムが使用可能である場合、例外をスローする。
//（たとえば、診断ルーチンを実行する前に確認する。）
//
void ThrowErrorIfAvailable()
{
bool bSystemAvailable = IsSystemAvailable();

if ( bSystemAvailable )
{
Exception UnavailabilityError(
"System is unexpectedly available.");

throw UnavailabilityError;
}
}

【0095】

ここで、ＴｈｒｏｗＥｒｒｏｒＩｆＵｎａｖａｉｌａｂｌｅ（）は、公称では、患者検査の実行など、一般的な使用可能性を必要とする何らかの関数の前に呼び出され、ＴｈｒｏｗＥｒｒｏｒＩｆＡｖａｉｌａｂｌｅ（）は、公称では、診断検査の実行など、使用不能性を必要とする何らかの関数の前に呼び出される。ユーザの観点から、ここでの目標は、患者検査を要求したときにシステムが予期せずになぜ使用不能になったかというソース理由を報告すること、および診断検査を要求したときにシステムが予期せずになぜ使用可能になったかというソース理由を報告することである。

【0096】

ソースコードの観点から、それらの理由はどちらも、ＴｈｒｏｗＥｒｒｏｒＩｆＡｖａｉｌａｂｌｅ（）およびＴｈｒｏｗＥｒｒｏｒＩｆＵｎａｖａｉｌａｂｌｅ（）の両方で呼び出される同じ関数ＩｓＳｙｓｔｅｍＡｖａｉｌａｂｌｅ（）を流れる。２つのスロー関数はまた、ＩｓＳｙｓｔｅｍＡｖａｉｌａｂｌｅ（）の戻り値を確認する「ｉｆ」状態で異なり、一方は戻り値を直接確認し、他方は戻り値の否定を確認することに留意されたい。さらに、ＩｓＳｙｓｔｅｍＡｖａｉｌａｂｌｅ（）によって返された値は、２つの正反対のコンテキストのうちのどちらで呼び出されたかにかかわらず、最終的には、ｂＶａｌｕｅ１およびｂＶａｌｕｅ２の厳密に同じ値、ならびにこれらを組み合わせた厳密に同じブールＡＮＤ式から導出される。典型的に任意の正常なソフトウェアアプリケーションに位置する異なるソース障害モード条件を介して、ｂＶａｌｕｅ１およびｂＶａｌｕｅ２を互いに独立して修正することができる場合、ソフトウェアは、それらのソース理由のうちのどちらでもＩｓＳｙｓｔｅｍＡｖａｉｌａｂｌｅ（）によって返された値を招いたものを通信することが可能になるべきであり、このとき原因要因でなかった理由は除外するべきである。ＩｓＳｙｓｔｅｍＡｖａｉｌａｂｌｅ（）は事実上、それら２つの入力原因変数を取得して、単一の原因変数を返し、その出力変数の２つの可能な値は各々、ＩｓＳｙｓｔｅｍＡｖａｉｌａｂｌｅ（）がなぜ呼び出されているかに応じて、失敗または成功を表すことができる。

【0097】

実際のソフトウェアにおける多くの因果パスでより典型的な複数のタイプの演算とともに処理される５つの入力を含むより複雑な例を考慮されたい。
//システムが使用可能であるかどうか
//を判定する要因として含まれる５つの値。

bool bValue1 = ...;
bool bValue2 = ...;

enum StateEnum
{
Initializing,
Running,
Stopped,
Resetting,
Diagnostics
};

StateEnum enState_SubSysA = ...;
StateEnum enState_SubSysB = ...;

float fSensorReading = ...;


////////////////////////////////////////////////////////
//
//システムが使用可能であるかどうかを返す。
//
bool IsSystemAvailable()
{
return
(bValue1 && bValue2) ||
(((enState_SubSysA == StateEnum::Running) &&
(enState_SubSysB != StateEnum::Diagnostics)) ||
((fSensorReading <= 5000.0) &&
(fSensorReading > 100.0)));
}


//．．．同じ「ThrowErrorIf．．．（）」関数を
//上記から含む．．．

【0098】

ここで、使用可能性を計算するＩｓＳｙｓｔｅｍＡｖａｉｌａｂｌｅ（）の式は、次の６つのタイプ：ブールＡＮＤ；ブールＯＲ；同等；不等；以下；および大なりの９つの演算子を含む複雑なネストされた式である。これらは、５つの別個のデータ値入力：ｂＶａｌｕｅ１；ｂＶａｌｕｅ２；ｅｎＳｔａｔｅ＿ＳｕｂＳｙｓＡ；ｅｎＳｔａｔｅ＿ＳｕｂＳｙｓＢ；およびｆＳｅｎｓｏｒＲｅａｄｉｎｇを組み合わせる。このデータは、３つの異なるデータ型：ｂｏｏｌ；ＳｔａｔｅＥｎｕｍ；およびｆｌｏａｔから構成される。ここでは直接表されていないが、ソースコードには、式全体の個々の演算を評価するときにコンパイラが生成する一時的な値が含まれる。これらは、より低レベルの式からの中間出力およびより高レベルの式への入力を表し、したがって原因ＩＤ情報も同様に保持することが必要になることもある。

【0099】

上記の２入力バージョンと同様に、典型的に任意の正常なソフトウェアアプリケーションに位置する異なるソース障害モード条件から、これら５つの異なるデータ入力を異なる方法で設定することができる場合、ソフトウェアはこの場合も、それらのソース理由のうちのどちらでもＩｓＳｙｓｔｅｍＡｖａｉｌａｂｌｅ（）によって返された値を招いたものを通信することが可能である必要があり、その主要な式のいずれの特定の評価でも原因要因でなかった理由は除外する必要がある。

【0100】

任意の式のどの入力がその式の何らかの所与の評価でその出力に原因として寄与したかをソフトウェアがどのように自動で判定することができるかという問題は、何らかの知られている従来のソフトウェア工学の観点から解決すべきささいな問題ではない。ソフトウェアのすべての原因式が直接、５入力の例と同程度に複雑であるとは言えないが、式は異なる部分式に暗示的に分割されることが多く、それらの部分式がコードの異なる関数、ブロック、または領域で計算されることから、多くは同等に複雑でありかつ／またはさらに複雑であることが多い。ソフトウェアにおいて式が複雑であることに気付いていない場合でも、通常、同じまたは類似の方法で処理する必要がある同等に複雑な式が示唆される。

【0101】

これまで、任意のソースコード式にわたって原因情報を正しく伝搬するというこの副次的問題を処理するための広く知られている方法はなく、ここで正しさは、適当なソース原因をユーザに提供し、かつ不適当なソース原因をユーザに提供しないこととして定義される。

【0102】

副次的問題＃７：混ざり合ったソフトウェアアーキテクチャ。中程度または大規模なほとんどのソフトウェアシステムは、互いに通信する多くの異なるサブシステムから構成され、各サブシステムは、異なる内部データ、イベント、ならびにエラー取扱い表現および設計を有している。このため、これらの異なるサブシステムの入力／出力およびアーキテクチャ境界を越えて伝搬するため、任意の根本原因条件の因果関係の結果を追跡することがより困難になる。この要因はまた、副次的問題＃２と組み合わされて、ユーザにとって全体的な問題の解決に対する別の大きな障害をもたらし：多くの異なるサブシステムの実装は、多くの場合、多くの異なる根本原因条件（たとえば、エラーまたはイベント型）を含有および定義し、どの個々のサブシステムも、多くの場合、個々のサブシステムと相互作用する他のサブシステム内の可能な外部根本条件または根本イベントのすべてを知っているわけではなく、すべてを知ることは不可能であり、したがって個々のサブシステムが否定的帰結をもたらす可能性がある。このため従来、個々のサブシステムがその否定的帰結の特有の外部原因を報告することは極めて困難であった。

【0103】

副次的問題の概要：これらの要因はすべて、今日まで一般的または効率的な方法で解決されていないほど複雑な性質を有する全体的な技術的問題をともにもたらす。通常、開発者による全体的な問題の認識は、ソフトウェアシステムにおける原因および結果の挙動が極度に複雑であり、したがって解決策も必然的に極度に複雑になるということであり、したがって開発者は、この問題が性質上扱いにくいと結論付ける。すなわち、開発者は、この問題が開発資源および／またはコンピューティング能力の点から解決するにはあまりにも資源集約的であると結論付け、したがって仮に何らかの試みを行うとしても、その解決には制限された試みしか行わない。したがって、これらの副次的問題は、否定的帰結を経験したユーザと、その帰結に対する根本原因条件を迅速かつ効果的に識別することが可能なユーザとの間に、大きな技術的障壁を集合的、根本的、かつ伝統的にもたらしてきた重大な複雑化要因である。

【0104】

周知の従来技術の解決策は、概して、重要な基礎的なアーキテクチャおよび実装の詳細（低レベルでの共有エラー表現など）を共有するために含まれるソフトウェアサブシステムのすべてを必要とするが、これは概して、現実世界のソフトウェアがほぼ常に動作する非常に混ざり合ったソフトウェアおよび製品環境において、実行可能でもなく費用効果が高くもない。これらの解決策はまた、ソフトウェアにおけるすべての可能な原因シナリオのわずかな部分しかカバーしない。

【0105】

理想的な解決策は、ユーザに表示される任意の否定的帰結を、それらの帰結を引き起こしたソフトウェアで検出された任意の原因イベントまで遡って自動で関係付けるべきである。原因イベントを根本原因まで適切に追跡するシステムは、否定的帰結を経験すると即座に、または可能な限りほぼ即座に、活動中のソフトウェアにおいて原因イベントまで遡ってこの関係を作成および表示するべきである。否定的帰結を経験した後に、「事後」ツールまたは分析を実行することを必要とするべきではない。根本原因に関するフィードバックおよび詳細な情報は、可能な限り即座にかつ簡単に獲得することができるべきである。システムは、ユーザがユーザインターフェースの追加の領域（たとえば、他の画面、アプリケーション、またはファイル）で原因を検索する必要を最小にしまたはなくすために、否定的帰結が表示されるちょうどその場所に、または可能な限り近くに、何らかの所与の否定的帰結を招いた原因イベントをユーザに表示するべきである。この理想的な解決策は、ソフトウェアのアーキテクチャ、設計、および実装の他の態様に対する影響を最小化すべきである。問題のカバー範囲を最大化するために、ユーザに対する最初の根本原因条件と否定的帰結との間で、可能な限り多くの因果パスにわたって原因イベントおよび否定的帰結を関係付けることを可能にするべきである。問題解決の精度の最大化および実装コストの最小化の両方を行うために、原因イベント条件と否定的帰結との間で一般に遭遇する多対１、１対多、および一般的な共有パスウェイの特性の関係を支持し、可能な限り決定的であり、可能な限りヒューリスティクスを避けるべきである。実施形態は、これらの目標の１つまたはそれ以上を実現することを試みるが、これらの目標の所与の組合せを実現する必要はない。

【0106】

いくつかの実施形態の概説
ほとんどのソフトウェアシステムは、否定的帰結をユーザに表示することができることに留意されたい。概して、ソフトウェアシステム全体のどこかに少なくとも１つの条件付き演算が存在することになり、ソフトウェアシステムは、最初の原因を内部で検出し、次いで少なくとも１つの方法でその条件検出に作用して、最終的に否定的帰結を表示する。すなわち、ソフトウェアの一般特性は、ユーザに表示されるすべての否定的帰結が、ソフトウェアシステム全体における１つまたはそれ以上の条件まで遡って最終的に関係付けられることである。

【0107】

否定的帰結の表示を駆動することができる任意のソフトウェア条件が、ここで「原因イベント条件」として定義される。原因イベント条件が満たされ、したがってその出力節が実行されるインスタンスが、「原因イベント」と見なされる。否定的帰結を引き起こす原因イベント条件は、たとえば：エラー条件に対する任意の種類の確認；（センサデータ分析、ネットワークデータ分析、ユーザ提供データ分析、論理確認、システム使用可能性の確認、ステータスまたは状態の確認など）；ユーザアクションに対する任意の種類の確認（他のアクションを打ち切るためにユーザが「停止」ボタンを押下したことの確認、ユーザが新しいソフトウェアをインストールしたことの確認、ユーザがソフトウェアを開始したことの確認、ユーザがシステムをリセットしたことの確認、ユーザがデータベースまたはそのいくつかの部分などの持続式またはメモリ内データを初期化または再初期化したことの確認など）；任意の他の種類の確認（たとえば経過時間間隔または他のシステムカウントに基づいて、上記のユーザアクションのいずれかの自動化されたバージョンに関与し始めたことの確認、必要とされる資源の消耗または満了の確認など）とすることができる。

【0108】

含まれるソフトウェアに応じて、それらの条件のすべてが、一般に否定的帰結を招く可能性がある。実施形態は、ソフトウェアのこの一般特性を活用することができ、否定的帰結は最終的に、任意の原因イベントを否定的帰結に対する理由としてユーザに総称的に表示するために、ソフトウェア内の条件から調達される。ソフトウェア内の原因イベント条件は、物理的ボタンがオペレータによって押されること、センサとの流体相互作用、ハードウェアの障害など、ソフトウェアの外部の物理イベントによってトリガされる可能性があることに留意されたい。したがって、否定的帰結に対する「真」の根本原因は、ソフトウェアによって検出された原因イベント条件を超えて、再び物理的（非ソフトウェア）領域まで延びる可能性がある。したがって、問題を真に修復するために、ユーザは、ソフトウェアコードでトリガされた条件の物理的原因を診断することが必要とされる可能性がある。しかし、ここでの説明は、ソフトウェアで（原因イベントの形で）検出された根本条件を否定的帰結に対する原因として表現すること、およびそれらの厳密な原因イベントを可能な限り最も正確かつ効果的にユーザに報告することのみに関する。

【0109】

問題解決ガイドの形のユーザに対する助けなどを含むソフトウェアに対して、原因イベント条件が否定的帰結の原因として識別された後、それらのガイドは多くの場合、原因イベント条件がすでに識別されているという仮定から始まり（その術語によってそれらの条件を識別しない場合でも）、その特有の条件を修復する形で助けを提供する。実施形態は、否定的帰結の経験と原因イベント条件の発見との間の間隙を標的とすることができ、判定された後にその原因条件をどのように修復するかは標的とせず、すなわち非常にソフトウェアおよびシステム特有であり、問題解決ガイドを含むソフトウェアシステムは多くの場合、それらの修復工程もすでに標的とする。

【0110】

否定的帰結の表示を駆動する際、複数の条件が含まれることは珍しくない。すなわち、ソフトウェア根本原因条件から否定的帰結への因果関係のチェーンは、評価されて満たされる２つ以上の条件を含むことができる。コード内の任意の条件付き演算を原因イベント条件と見なすことができるかどうかは、満たされたその条件とＵＩに表示された否定的帰結との間に因果パスが存在するかどうかに依存する。

【0111】

１組の原因イベント条件のうち、否定的帰結に寄与し得る条件は、２つの概略的なグループ：「根本原因条件」および「中間条件」に分類することができる。否定的帰結を全体的または部分的に開始し得る条件は、その条件が否定条件と見なされるか否かにかかわらず、因果関係チェーン内でその前に他の条件が存在しない場合、根本原因条件であると見なされる。因果関係チェーン内で根本原因条件に続く条件は、中間条件であると見なされる。

【0112】

これらの概念を示すために、簡単な１組の肯定的帰結挙動および否定的帰結挙動を実証する次の例示的なＣ＋＋コードを考慮されたい。「／／［Ｎ］」コメントは、以下の説明の行を参照するために使用されるタグである：
class Sensor
{
public:

bool CheckSensor()
{
int l_nSensorReading = GetReading();

bool l_bSuccess = true;

if( l_SensorReading > SENSOR_READING_MAX ) // [1]
{
//限界外のセンサを返す。
l_bSuccess = false;
}

if( l_SensorReading < SENSOR_READING_MIN_WARNING ) // [2]
{
//センサはまだ限界内にあると見なされるが、
//ディスクへ警告をログ記録する。

Log(“Sensor below expected minimum”);
}

return l_bSuccess;
}
};


void VerifySensor()
{
Sensor l_Sensor;

if( l_Sensor.CheckSensor() ) // [3]
{
DisplaySuccess( “Sensor OK.” );
}
else
{
DisplayFailure( “Sensor failed.” ); // [4]
}
}


void VerifyAllSensors
{
Sensor l_Sensor1;
Sensor l_Sensor2;

if( l_Sensor1.CheckSensor() && l_Sensor2.CheckSensor()) // [5]
{
DisplaySuccess( “All sensors OK.” );
}
else
{
DisplayFailure( “One or more sensors failed.” ); // [6]
}
}

【0113】

ここで、関数Ｓｅｎｓｏｒ：：ＧｅｔＲｅａｄｉｎｇ（）は、センサクラスのインスタンスに関連付けられた何らかのハードウェアセンサから読取りを獲得すると定義される。関数Ｌｏｇ（）は、メッセージをディスクに書き込む。議論のために、この関数によってディスクに書き込まれたメッセージは、この特定のソフトウェアに対する否定的帰結と見なされない。関数ＤｉｓｐｌａｙＳｕｃｃｅｓｓ（）およびＤｉｓｐｌａｙＦａｉｌｕｒｅ（）は、ユーザインターフェース関数であると定義される。ＤｉｓｐｌａｙＳｕｃｃｅｓｓ（）が呼び出されたときはいつでも、肯定的帰結をユーザに表示する。ＤｉｓｐｌａｙＦａｉｌｕｒｅ（）が呼び出されたときはいつでも、否定的帰結をユーザに表示する。関数ＶｅｒｉｆｙＳｅｎｓｏｒ（）およびＶｅｒｉｆｙＡｌｌＳｅｎｓｏｒｓ（）は、公称では、ある時点で何らかの外部コードによって呼び出すことができる。これらの関数は、センサから読取りを獲得し、それらの読取りに基づいて、成功または失敗をユーザに直接表示する。

【0114】

したがって、ＤｉｓｐｌａｙＦａｉｌｕｒｅ（）が呼び出されることにつながる条件は、原因イベント条件であると見なされる。このコードを調べると、ＶｅｒｉｆｙＳｅｎｓｏｒ（）の行［４］およびＶｅｒｉｆｙＡｌｌＳｅｎｓｏｒｓ（）の行［６］で、ＤｉｓｐｌａｙＦａｉｌｕｒｅ（）を呼び出すことができる。

【0115】

ＶｅｒｉｆｙＳｅｎｓｏｒ（）の事例を調べると、行［３］の条件が偽と評価された場合のみ、ＤｉｓｐｌａｙＦａｉｌｕｒｅ（）が呼び出され、これは、Ｓｅｎｓｏｒ：：ＣｈｅｃｋＳｅｎｓｏｒ（）が偽を返した場合のみ生じる。Ｓｅｎｓｏｒ：：ＣｈｅｃｋＳｅｎｓｏｒ（）は、行［１］の条件が真を返した場合のみ偽を返す。この因果関係チェーン内で行［１］の条件の前にそれ以上の条件が存在しないため、行［１］の条件が、行［４］のＤｉｓｐｌａｙＦａｉｌｕｒｅ（）の否定的帰結に対する根本原因条件である。

【0116】

同様に、ＶｅｒｉｆｙＡｌｌＳｅｎｓｏｒｓ（）の事例を調べると、行［５］の条件が偽と評価された場合のみ、ＤｉｓｐｌａｙＦａｉｌｕｒｅ（）が呼び出され、これは、Ｓｅｎｓｏｒ：：ＣｈｅｃｋＳｅｎｓｏｒ（）が偽を返した場合のみ生じる。この場合も、Ｓｅｎｓｏｒ：：ＣｈｅｃｋＳｅｎｓｏｒ（）は、行［１］の条件が真を返した場合のみ偽を返す。行［１］の条件はまた、行［６］のＤｉｓｐｌａｙＦａｉｌｕｒｅ（）の否定的帰結に対する根本原因条件である。

【0117】

この全体的な例では、Ｓｅｎｓｏｒ：：ＣｈｅｃｋＳｅｎｓｏｒ（）内の行［１］の条件は、２つの異なる障害モード（行［４］のＤｉｓｐｌａｙＦａｉｌｕｒｅ（）の否定的帰結、および行［６］のＤｉｓｐｌａｙＦａｉｌｕｒｅ（）の否定的帰結）に対する根本原因イベント条件である。行［３］および［５］の条件が、中間条件であると見なされる。これらの条件は各々、１つまたはそれ以上の否定的帰結を駆動するためのパス内にあるが、１つまたはそれ以上の他の根本原因条件が最初に満たされなければ、これらの条件を満たすことはできない。行［２］の条件は、この特定のソフトウェアにおいて何が否定的帰結と見なされるかに関する上記の定義に応じて、トリガされた位置といずれの定義された否定的帰結との間にもパスが存在しないため、原因イベント条件であると見なされない。しかし、「ディスクへ警告をログ記録する」が否定的帰結であると見なされるように変更された場合、行［２］の条件は、原因イベント条件およびその根本原因条件であると見なされることになる。

【0118】

ソフトウェア全般に戻ると、因果関係チェーン内の複数の条件を「直列」の構成で配置することができ、否定的帰結が表示されるまで、条件Ａを評価して満たされると、条件Ｂを評価して潜在的に満たされ、以下同様である。この場合、これらの条件は「論理ＡＮＤ」としてともに挙動し、否定的帰結を表示させるためには、直列構成の条件のすべてが満たされる必要がある。同様に、複数の条件を「並列」の構成で配置することができ、条件Ａを評価して満たされること、または条件Ｂを評価して満たされることのいずれかで、否定的帰結を表示させることができる。この場合、これらの条件は「論理ＯＲ」として挙動し、並列構成の条件のいずれかが満たされることで、否定的帰結が表示される。

【0119】

多くの場合、因果関係チェーンは、直列および並列の両方で配置された複数の条件から構成される。これは、上記の例示的なコードに当てはまる。行［１］の根本原因条件は、後の行［３］および［５］の中間条件の各々と直列である。加えて、「ｉｆ／ｅｌｓｅ」文の「ｅｌｓｅ」節に対して暗示される行［５］の条件、特にその否定されたバージョンは、２つの根本原因条件の並列構成を含む。本当のコードはまた、はるかに複雑な因果関係チェーンおよび条件の組合せを有することが多い。

【0120】

留意すべきもう１つの重要なことは、いくつかの原因イベント条件が「明示的」であり、これらの原因イベント条件およびそれらの直接出力節が、ファーストパーティコードで開発者によって修正のためにアクセス可能であることである。他の原因イベント条件は「暗示的」であり、基本条件およびその直接出力節は、開発者によって妥当に修正することができないコード内にアクセス不能に埋設される。そのようなコードの一般的な例として、クローズドソース、プロプライエタリオペレーティングシステムなどのコンパイル済みサードパーティコード、外部ライブラリ、または他の修正が難しいソフトウェアが挙げられる。開発者に対するそれらの相対的な修正可能性またはアクセス可能性にかかわらず、サードパーティコード内の暗示的根本原因条件はなお、関数呼出しまたはデータ送達を介して、根本原因条件を含むサードパーティコードからファーストパーティコードへ、ファーストパーティコードで否定的帰結の表示を駆動することができ、ファーストパーティコードが最終的に、否定的帰結の表示を駆動する。

【0121】

サードパーティコード内の暗示的条件の一般的な例には、プロセススタートアップ（たとえば、外部条件がオペレーティングシステムによって検出されることによって、ファーストパーティソフトウェア内のｍａｉｎ（）プロセススタートアップ関数が呼び出される）、およびユーザ入力イベント（オペレーティングシステムによって検出されたキーボードおよびマウス入力条件が、ファーストパーティソフトウェア内で通知を作成する）が含まれる。これらの例は、場合により、否定的帰結を駆動する可能性があり：初期化が完了するまで、プロセスの基本機能がスタートアップで使用可能でなくなり、それによりユーザへの「使用不能」報告を一時的に生じさせ、ユーザ入力は、前の要求および／または「使用不能」状態の取消しを引き起こす可能性がある。これらの条件はどちらも、ユーザにとって、そのユーザによって開始された場合でも、意図しない苛立ちを招く可能性がある。これらは、ソフトウェアのいくつかの領域では肯定パスを表すが、ソフトウェアの他の領域では否定的帰結をもたらす可能性もある。

【0122】

したがって、いくつかの実施形態では、否定的帰結を駆動する可能性のあるファーストパーティコードにおけるこれらのコールバックおよびデータ送達は、元のサードパーティ条件の直接出力節の拡張出力節と見なすことができる。条件の「出力節」を指すここでの説明は適宜、ファーストパーティコード内の原因条件に関連付けられた直接出力節、および／またはサードパーティコード内の原因条件によって間接的に実行されるファーストパーティコード内の「拡張」出力節を指す。

【0123】

根本原因条件とそこから最終的に表示される否定的帰結との間には、データフローの多くの層および多くの境界が存在し得ることに留意されたい。これらの層は：異なる型および異なる値、異なる関数呼出し、異なるパラメータ、異なるクラス、オブジェクト、スレッド、プロセス、コンピュータなどの複数のデータインスタンスを含むことができる。

【0124】

ソフトウェアユーザの観点から、いくつかの実施形態では、ＵＩが否定的帰結をユーザに表示するときはいつでも、ＵＩはまた、ソフトウェアがその否定的帰結を引き起こした特有の根本原因条件インスタンスを追跡することが可能であった場合、それを探索して表示することができる。すなわち、ソフトウェアは、原因イベントが発生するとそれらを追跡し、原因イベントの特有のインスタンスを否定的帰結に対する理由として報告する。

【0125】

いくつかの実施形態は、任意のソフトウェアシステムで原因および結果の非常に複雑な完全なグラフを分析しようとする大規模な扱いにくい技術的問題を回避および阻止し、ソフトウェアシステムに対する可能な障害モードのすべてをリスト化または他の形で捕捉することを避けることが望ましい。すなわち、少なくとも１つの実施形態は、任意の所与のソフトウェアシステムにおいて、すべての可能な根本原因条件がすべての可能な否定的帰結にどのように寄与するか、またはどのように寄与しないかを実際的に識別、分類、または列挙することは単に実行不能であるため、そうしようとしない。代わりに、活動中のソフトウェア状況において否定的帰結の何らかの所与の発生の実際の根本原因を自動で判定するために、そのような実施形態は、そのソフトウェアのコード自体の構造を活用してそれに依拠し、そのようなソフトウェアのコードは最終的に、そのソフトウェアに対する原因および結果のグラフを定義するものであり、そのコードが生成する中間結果に対する原因、したがってそのコードが生成する最終的な否定的帰結を自動で渡す。

【0126】

より具体的には、実施形態は、エラーを検出する条件、ユーザアクションを検出する条件、または場合により否定的帰結を引き起こすことが知られているシステム状態もしくは入力の他の検出など、コード内の根本原因条件を修正して、それらの実行のすべてのインスタンス（すなわち、すべての原因イベント）をデータベースに記録し、新しい固有の動的に生成された原因ＩＤ値によってそれらのインスタンスを即座に識別することができる。次いで、原因グラフ内の各原因ノード（すなわち、否定的帰結に寄与する可能性がある各データ変数、オブジェクトインスタンス、関数呼出し、コードブロックなど）を修正して、可変の原因ＩＤ項を付与して渡す。この付与された可変の原因ＩＤ項の値は事実上、そのノードの現在のデータまたは実行状態に対する「理由」であることが知られているデータベース内の原因イベントを「指し示す」。所望のシステム挙動およびシステム制約に応じて、原因ＩＤ項は、ニルもしくは非ニルの原因ＩＤ値に等しい単一の原因ＩＤ変数、またはゼロ、１つ、２つ、もしくはそれ以上の非ニル原因ＩＤ値を可変に含むことができるコンテナとして実装することができる。根本原因条件は、状態を変化させることによって（すなわち、データを修正すること、または何らかの演算を実行することによって）、結果を１つまたはそれ以上の下流ノード内へ伝搬したとき、ノードの新しい状態とともに記憶するために、影響を受けたノードの付与された原因ＩＤ項に入れることを介して、その根本原因条件によって生成された現在の原因イベントを識別する原因ＩＤ値を、影響を受けたノードへ渡す。このとき、ノードの付与された原因ＩＤ項内の原因ＩＤの値は、任意の所与の時点のノード上の現在の状態および結果に対する理由を記述する。すなわち、原因ノードに付与された原因ＩＤ項は、そのノードの現在の状態に関するメタデータとして働く。中間ノードはまた、可変の原因ＩＤ項を適宜それらの出力結果へ伝搬する。すなわち、現在の中間ノードの値または状態が別の下流ノードで新しい値または状態を発生させた場合、現在のノードの原因ＩＤ項もまた、その下流ノードで渡されて記憶され、場合によりそのノード内の前の原因ＩＤ項の値を上書きする。各ノードに対する原因ＩＤ項メタデータは可変であり、その値は多くの場合、各原因ノードの状態が変化すると変化することに留意されたい。

【0127】

次いでノードの現在の状態または結果により、否定的帰結が発生した場合、その否定的帰結の表示を処理するコードは、その否定的帰結の入力ノードに付与された原因ＩＤ項内の原因ＩＤの値を使用して、ここでその帰結の原因であることが知られているその否定的帰結の根本原因イベントをデータベースから探索して表示する。これは、ユーザの観点からの解決策であり：ユーザが否定的帰結を見たとき、ソフトウェアは、ここでその帰結を引き起こしたことが知られている任意の根本原因条件を原因イベントの形でデータベースから表示することができる。

【0128】

この基本設計は、当該ソフトウェアの固有の任意の構造が、何らかの所与の結果の実際の原因を外へ正確に、動的に、かつ自動で通信することを可能にし、それに依拠しており、開発者またはソフトウェアは、すべての可能な原因、すべての可能な帰結、またはシステム内のそれらの間のすべての可能な関係の全体を知ることまたは理解することすら必要ない。

【0129】

いくつかの実施形態は、各実施形態の実装自体が著しく複雑になることなく、任意の複雑さのソフトウェアを取り扱うように自然に拡大する。これらの例は簡単であるが、これらの実施形態は、本発明の能力および的確さを正確に反映するべきである。

【0130】

本当のコードの任意の所与の領域は、次のタイプの原因コードのうちの１つまたはそれ以上によって記述することができることに留意されたい。すなわち、任意の所与のコード区分は、原因イベント条件、因果パスウェイ、および／またはユーザインターフェース表示のうちの１つまたはそれ以上を含むことができることから、これらの領域間の何らかの機能的重複を含むことがある。

【0131】

いくつかの実施形態では、原因イベントが発生したとき、すなわち所定の条件に応答して原因イベント条件の出力節が実行されたとき、その原因イベントが取った他のアクションが何であっても、原因イベントはまた常に、そのイベントインスタンスを記述する原因イベントデータベースに原因イベントエントリを書き込むことを確実にする。このエントリは、原因イベントを招いたシステム状態情報を含むべきである。イベントエントリをデータベースに、またはその一部として書き込む前に、節は新しい固有の原因ＩＤ値を動的に生成して、データベース内でイベントおよびそのエントリを識別する。この局所的に生成された原因ＩＤ値は次いで、エントリの一部としてデータベースに書き込まれる。この時点で、原因ＩＤ値は、現在データベースに位置しまたはすぐにデータベースに入る特有の原因イベントに対する「ポインタ」と見なすことができる。ユーザインターフェースレベルのコードだけが、このポインタをさらに「逆参照」し、イベントを探索して表示するが、原因イベント条件とＵＩ表示との間の他のコードはすべて、必要に応じてこのポインタを渡して記憶し、ＵＩ内の関連付けられた否定的帰結に与えることができる。したがって、原因イベント条件の出力節でちょうど生成された新しい原因ＩＤ値はまた、必要に応じてさらに伝送するためにその節で局所的に保持される。

【0132】

別の因果パスウェイが現在の原因イベント条件を部分的または全体的に招いたかどうかによって判定されるように、別の原因イベントが、生成されている現在のイベントを引き起こしたことが知られた場合、出力節はまた、現在のイベントの「親原因ＩＤ」フィールドを他のイベントに適宜設定して、それらのイベント間の原因関係を反映することができる。これは、原因イベントが他の原因イベントによって引き起こされることがある「カスケード化エラー」または「カスケード化イベント」のシナリオを支持する。

【0133】

サードパーティコード内に存在する暗示的原因イベント条件に対するファーストパーティコード内の出力節は、概して、場合により否定的帰結を生成する可能性がある場合、同様にも原因イベントを生成することができ、生成するべきであることに留意されたい。局所的なファーストパーティ出力節の例としては、サードパーティコードによって呼び出されるファーストパーティコード内の関数コールバック、またはサードパーティコードからファーストパーティコードへのデータ送達が挙げられる。ファーストパーティコードは、開発者が修正することが可能なコードであると定義され、サードパーティコードは、開発者が修正することが可能でないコードであると定義される。これらの場合は概して、サードパーティ条件によって実行されるファーストパーティコードの第１の行は、原因イベントをデータベースにポスティングするべきである。これにより、いくつかの原因イベント条件に対する実際の条件節および主節がファーストパーティコードの外に存在するという一般的問題が解決される。典型的に、原因イベント条件は、エラー条件、オペレータアクション、および場合によりユーザに対して否定的帰結を引き起こすことが知られているシステム状態もしくは入力の他の検出に対応する。

【0134】

原因イベント条件と否定的帰結が表示されるべきかどうかを判定するユーザインターフェースコードとの間のデータまたは実行パスは、因果パスウェイであると見なされる。因果パスウェイは、必要に応じて可変の原因ＩＤ項パラメータを付与して、何らかの表示された否定的帰結に対する原因ＩＤがＵＩシステムに達することを確実にするべきである。

【0135】

したがって、ＵＩが場合により否定的帰結をユーザに表示する可能性のある１つまたはそれ以上のアクションを、原因イベント条件の出力節が取ったときはいつでも、この節は、新しい原因ＩＤ値をアクションの一部として渡すべきである。この原因ＩＤ値は、アクションが取られている「理由」、したがってＵＩが否定的帰結を表示している理由（ＵＩが最終的に否定的帰結を表示することになった場合）を記述する。すなわち、原因ＩＤは、データベースに位置する（またはすぐにデータベースに入る）どの原因イベントが、ユーザによって観察されている否定的帰結に対する理由であるかを記述する。

【0136】

アクションは、関数の呼出しおよび他の実行のトリガ、ならびに／または状態変数、局所変数、オブジェクト、および／もしくはそれらのメンバ変数、持続データなどを含む何らかの種類のデータの修正を含むことができる。

【0137】

様々な実施形態では、原因ＩＤ項内の原因ＩＤの現在の値は、否定的帰結を招くデータの現在の値に対する理由、および／または否定的帰結を招く現在のコード実行に対する理由を記述する。この目標は、ＵＩに否定的帰結を表示させたアクションおよび／またはデータがまた、その否定的帰結が表示されるべきイベント理由を指す正しい原因ＩＤ項を含むことを確実にすることである。

【0138】

原因ＩＤ項値を渡すことは、いくつもの数の形で：直接関数パラメータとして、渡されているオブジェクトインスタンスに追加された追加のデータメンバとして、（たとえば、汎用体またはテンプレートによって実装されるラッパクラスを介して）渡されている変数に結合された値として、状態変数に結合された値として、戻り値として、既存の変数に隣接する別個の変数などとして、起こる可能性がある。このようにしてアクションおよびデータに付与されたとき、原因ＩＤ項は、それらのアクションおよびデータに関するメタデータになり、したがってアクションまたはデータに対する原因ＩＤ項は、特有のアクションが現在取られている「理由」、またはデータがその特定の瞬間にその特定の値を有する「理由」を表し、「理由」は、データベース内に記憶される１つまたはそれ以上の原因イベントであると見なされる。

【0139】

加えて、２つ以上の入力因果パスウェイを組み合わせてより少ない数の出力因果パスウェイにする演算は、もしあれば、出力に含むように、適当な入力原因ＩＤ項を選ぶべきである。これはまた、出力値またはアクションの原因でないことが知られているとき、入力からのいくつかの原因ＩＤ項を出力から故意に除外することができることを示唆している。

【0140】

データ分析（成功／失敗値の調査など）、または直接アクション要求（エラーを表示するための関数呼出しなど）のため、否定的帰結をユーザに表示しなければならず、そのデータまたはアクション要求に原因ＩＤ項が付与されており、かつ原因ＩＤ項が１つまたはそれ以上の非ニル原因ＩＤ値を含むと、ユーザインターフェースが判定した場合、ＵＩは、それらの非ニル原因ＩＤ値によって指定されたイベントデータベース内の原因イベントエントリを参照し、それらの１つまたはそれ以上の関連付けられたイベントエントリを、表示すべき否定的帰結の原因としてユーザに報告するための候補イベントと見なす。

【0141】

候補イベントの親原因ＩＤがニル原因ＩＤである場合、ＵＩは、その候補イベントの情報を否定的帰結の表示とともに否定的帰結に対する理由としてユーザに報告する。候補イベントの親原因ＩＤがニル原因ＩＤでない場合、ＵＩは、その親原因ＩＤに関連付けられた親原因イベントを参照し、次いでこの親原因イベントが新しい候補イベントになる。このプロセスは、各イベントの親原因ＩＤによって暗示される親子イベントツリーを遡って、ニル原因ＩＤに等しい親原因ＩＤを有する候補イベントが見つかるまで繰り返され、ニル原因ＩＤに等しい親原因ＩＤを有する候補イベントが見つかった時点で、最後の候補イベントの情報が、否定的帰結の表示とともに否定的帰結に対する理由としてユーザに表示される。これは、場合により単一の否定的帰結に対する根本原因として表示されている複数のイベントを支持し、これは実際に発生する可能性があることに留意されたい。

【0142】

参照されている原因ＩＤに対するイベントエントリがデータベース内にまだない場合、この参照は、そのイベントが現れるのを待つことができ、かつ／またはタイムアウトによって失敗し、「情報がまだ使用可能でない」などの表示を返すことができる。定義上、ニル原因ＩＤでないすべての原因ＩＤは、最終的にデータベース内のイベントエントリを指すべきであり、したがってデータベース内のイベントエントリは、最終的に存在することが予期される。

【0143】

２つ以上の入力因果パスウェイを組み合わせてより少ない数の出力因果パスウェイにする演算は、もしあれば、出力に含むように、適当な入力原因ＩＤ項を選ばなければならない。これはまた、出力値またはアクションの原因でないことが知られているとき、入力からのいくつかの原因ＩＤ項を出力から故意に除外することができることを示唆している。概略的かつ一般的な例は、２つ以上の原因データパスから複数の入力値を取得し、次いで同等比較、ブールＡＮＤ、ＯＲ、およびＮＯＴ、算術演算などの様々な演算をそれらの入力値に適用して、単一の出力値を計算する複合式であり、次いでこの単一の出力値が、ＵＩへの因果パスウェイの一部になる。入力の１つまたはそれ以上に原因ＩＤ項が付与されていた場合、この式は、それらの原因ＩＤ項のうちのどれを出力値へ伝搬するか、およびどれを出力値から除外するかを正確に選ぶ必要がある。これは、入力値を分析し、所与の出力値をもたらすことが知られている値を有する原因ＩＤ項をそれらの入力から出力値に対して選択するために必要とされる演算を修正または多重定義することによって行われる。

【0144】

複合式で多くの場合に生じるように、その出力が次いで別の演算への入力として働く場合、ほとんどのプログラミング言語の指定の挙動に応じて、その言語による一時的な値および他の自動の取扱いが、式中の各演算による適当な原因ＩＤ項の伝搬を処理する。本発明の実施形態の概念を使用して、演算が原因ＩＤ項を取り扱うように総称的に修正された後、その演算を含むほとんどの式は、原因報告の観点から、その式自体を自動で「処理」する。

【0145】

いつでも、ソフトウェアがたとえばアクションまたはデータ割当ての一部として原因ＩＤ項値を充填することを必要とし、かつたとえばその原因アクションまたはデータ修正への入力または出力が原因イベントの報告のためにまだ修正されていないことから、原因ＩＤまたは原因ＩＤ項が使用可能でない場合、代わりにニル原因ＩＤ値が指定されるべきである。これは、付与されたデータまたはアクションに対する「既知の理由がない」ことを示し、常に充填するのに安全な値であると見なされる。ニル原因ＩＤの結果、原因イベント情報がユーザに表示されず、これは間違った原因イベント情報がユーザに表示されるより適切である。

【0146】

いくつかの実施形態は、何らかの単一の否定的帰結の発生に対して一度に単一の原因イベントを報告する。これは典型的に、ユーザにとって十分すぎる結果になる。しかし、いくつかの実施形態では、何らかの１つの帰結に対して一度に複数の原因を報告することも可能である。いずれの報告モードを支持することも、因果パスウェイに付与された原因ＩＤ項がどのように実装されるかによって実現される。話を簡単にするために、この説明のほとんどは、汎用原因ＩＤ項を因果パスウェイに付与することについて説明する。原因ＩＤ項が単一の原因ＩＤ値として実装された場合、これは概して、何らかの所与の否定的帰結に対して多くともゼロまたは１つの根本原因イベントを報告することを支持する。この場合、ニル原因ＩＤ値は、原因ＩＤ項が付与されたノードの現在の状態に対して「既知の理由がない」ことを示し、非ニル原因ＩＤ値は、ノードの値（したがって、そのノードによる下流の否定的帰結）を招いた原因イベントを参照する。原因ＩＤ項がゼロ、１つ、２つ、またはそれ以上の原因ＩＤ値のコンテナとして実装された場合、これは概して、何らかの所与の否定的帰結に対してゼロ、１つ、２つ、またはそれ以上の原因イベントを報告することを支持する。原因ＩＤ項コンテナが空である（すなわち、原因ＩＤ値を含まない）場合、これは、原因ＩＤ項が付与されたノードの現在の状態に対して「既知の理由がない」ことを示す。原因ＩＤ項コンテナが空でない場合、コンテナ内の各原因ＩＤ値は、ノードの値（したがって、そのノードによる下流の否定的帰結）を招いた原因イベントを表す。

【0147】

例
コードに対するその影響を最小化するための様々な重要な技法が、図１３Ａ～図１３Ｄに関して説明されている。図１３Ａは、一実施形態における簡単な原因および結果を示す。太線の円形ノードは、データまたは実行パスウェイのインスタンスを表し、原因ＩＤ項変数（親／根ノードＢ、Ｃ、Ｄ、子／葉ノードＶ、Ｘ、およびｙ、ならびに介在する子ノード）が付与されている。この例では、議論を簡単にするために、各ノードは、演算工程を実施し、概して次いで次のノードによって使用される値／結果を生成するソフトウェア内の原因関数／関数オブジェクトと定義される。見やすいように、各関数の値／結果はここでは図示せず、後続の関数へ渡される各関数に対する原因ＩＤ項だけが示されている。ソース条件（原因イベント条件７２）に関しては、太線のノード（Ｂ、Ｃ、およびＤ）は、実行されるとデータベース内に原因イベントを生成し、かつそのイベントを識別するための関連付けられた固有の原因ＩＤ値（任意の関数値に加えて）を生成する根本原因ソース条件を表し、この原因ＩＤ値は、その上流ノードの値が下流ノードの値または状態を引き起こしたことが知られているとき、その上流ノードの結果を関数入力として使用する下流の後続の関数（ノード）の原因ＩＤ項に渡される。中間パスノード（上流の関数／ノードの帰結を使用するそれらの関数、またはそれらの値を入力として取得する関数）に関しては、太線のノードは、そのそれぞれのデータまたは実行パスに付与された原因ＩＤ項変数を示す。太線のノードはまた、関数値も含むことになるが、これらはここに表示されていない。任意の所与の時点における各ノードに対する可変の原因ＩＤ項の値は、そのノードの現在の状態に対する原因イベントの理由を示す。概して、各下流ノード（Ｖ、Ｘ、Ｙ）が否定的帰結（たとえば、公称システム状態から逸脱する関数値を有する）に関連付けられている場合、その下流ノードの原因ＩＤ項を使用して、その否定的帰結に対してデータベース内の原因イベントを参照し、ＵＩ表示を介して否定的帰結に対する理由としてそれらを提示することができる。

【0148】

図１３Ｂは、タイプ「Ｄ」のソース条件が最初に発生し、任意に生成された固有の原因ＩＤ「１」を有する原因イベントインスタンスを生成し、その原因ＩＤをその出力結果の原因ＩＤ項（のいくつか）へ渡した例の原因および結果グラフである。太線のパス１２０に沿ったすべてのノードは、それらの現在の状態がすべて原因ＩＤ「１」によって参照されたイベント条件によって引き起こされたことから、共通の原因ＩＤ項「１」を共有し、この原因ＩＤ項は、原因イベント条件Ｄの出力節の結果として、現在の状態が設定されたときに設定された。もたらされた否定的帰結「Ｖ」を表示する準備をし、この帰結の表示の駆動を招いたデータまたはアクションに付与された非ニル原因ＩＤ項「１」を見たとき、ＵＩは、原因イベントがデータベース内に存在することになること、またはすぐにデータベースに入ることを知り、この原因イベントを否定的帰結に対する理由として参照および表示することができる。この場合、ＵＩは、「１」の原因ＩＤに関連付けられた原因イベントインスタンスを表示することになり、これはデータベースにポスティングされたタイプＤのイベントインスタンスである。

【0149】

図１３Ｃは、タイプ「Ｂ」の異なるソース原因イベント条件が実行され、新しい原因イベントを生成し、動的に生成された固有の原因ＩＤ「２」によってそれを識別する例の原因および結果グラフである。このソース条件の発生は、上記のソース条件Ｄの第１の事例で発生した否定的帰結「Ｖ」の同じタイプの別のインスタンスを引き起こす。この場合、同じタイプの否定的帰結のこの第２の発生は、「２」に関連付けられた原因イベントを表示し、これはタイプＢのイベントインスタンスであり、前述のように「１」に関連付けられた原因イベントインスタンス（タイプＤのイベント）ではない。この原因ＩＤは、太線のパス１２２に沿って伝搬し、パス１２２は、ソース条件Ｂによって生成された原因イベントインスタンスにエラーＶをリンクさせる。

【0150】

図１３Ｄは、第１の事例と同じ条件である同じソース原因イベント条件Ｄ（図１３Ｂと同様）がこの場合も実行される例の原因および結果グラフである。これは、原因、結果、および否定的帰結Ｖの第１の事例と同じ厳密なパターンを生成する。これはソース条件の別個の発生であるため、新しい原因イベントインスタンスエントリがデータベース内に生成され、新しい固有の原因ＩＤ値が「３」になるように任意に生成されることに留意されたい。この原因ＩＤは、太線のパス１２４に沿って伝搬し、パス１２４は、ソース条件Ｄによって生成された最も新しい原因イベントインスタンスにエラーＶをリンクさせる。

【0151】

ここで、否定的帰結Ｖのこの第３の発生は、上記の第１の事例からの「１」ではなく、原因ＩＤ「３」に関連付けられた原因イベントを表示することになる。エラーを引き起こす異なるセンサ読取り、または発生に関連付けられた異なる日時スタンプなど、原因イベント条件Ｄのこの発生をトリガしまたはこの発生に関連付けられた異なるコアデータ値が存在した場合、表示されたイベントは、根本原因条件Ｄの異なるインスタンスに関するこの異なる情報をユーザに反映することになる。

【0152】

原因イベント条件が結果を得てから長い間にわたってノードが同じ状態で変わらない場合、そのノードに付与された原因ＩＤ項の値も同様に変わらない。このとき、そのノードが有する将来の否定的帰結の結果は依然として、適当な原因ＩＤ項を帰結に対する理由として報告する。これにより、ソース条件の結果が時間に関して無制限であるという問題を処理する。

【0153】

ソフトウェアシステム内の条件、データパスウェイ、および実行パスウェイのうち、原因ではなく、否定的帰結をもたらさないものに対して、実際に原因となり、否定的帰結をもたらす可能性のあるものの数は、典型的に少ない。この図から、原因イベントの報告を実装するために多くの重大な修正が必要とされることが見受けられるが、多くの実施形態では、これはソフトウェアまたはソフトウェア開発に対して大きな影響を与えない。

【0154】

いくつかの実施形態では、各原因イベント（すなわち、原因イベント条件が満たされ、その出力節が実行される各インスタンス）を記録するために、原因イベントデータベースが使用される。データベース内の各原因イベントエントリは、原因イベント条件の出力節の１つの実行を表し、少なくとも次のフィールドを含む：

【0155】

記述：イベントのタイプを記述するコード、ストリング、または類似のフィールド。

【0156】

原因ＩＤ：原因イベントインスタンスを固有に識別するための原因ＩＤ値。原因ＩＤは常に、固有／擬似固有（データベース内で固有であり、保証があり、または固有でない可能性が十分に低い）の非ニル原因ＩＤ値に等しくなるべきである。

【0157】

親原因ＩＤ項：他の原因イベントが現在の原因イベントを引き起こしたことが知られている場合、それらの他の原因イベントの原因ＩＤ項を含む親原因ＩＤ項フィールド。他の原因イベントが現在のイベントを引き起こしたことが知られていない場合、親原因ＩＤフィールドがニル原因ＩＤに設定される。

【0158】

他の関連情報：他のフィールドおよび情報は理論上、イベントインスタンスを問題解決するとき、ユーザに対するさらなる診断情報を提供するために同様に追加されるべきである。例には：関連センサの読取り、論理確認入力、関連タイプのユーザもしくは自動化アクションなど、イベント条件への関連入力；イベントが発生したときの日／時間スタンプ、関連イベント条件入力を発生させたもしくはイベント時にログインしたユーザ、またはソースハードウェア識別子、ソースネットワーク識別子など、周辺の演算コンテキストが含まれる。

【0159】

原因イベントが発生したときはいつでも、原因イベントの条件に関連付けられた出力節は、出力節が行う他の特定用途向けアクションに加えて、次の発明特有のアクションを行う。原因ＩＤの生成：出力節は、その原因イベントインスタンスを識別し、その原因条件の他の実行（すなわち、その条件によって作成された他の原因イベントインスタンス）または任意の他の原因条件によって作成された任意の他の原因イベントインスタンスから区別するために、新しい固有の原因ＩＤ値を動的に生成する。データベースへの原因イベントのポスティング：出力節は、原因イベントデータベースへの新しい原因イベント記録の書込みを実施または開始する。追加すべきデータベースイベントエントリのフィールドには：基本原因イベント条件を記述するためのイベントのタイプ；生成された原因ＩＤに設定されたイベントの原因ＩＤ；上流因果パスウェイを介して、イベントが他のイベントによって引き起こされたことが知られている場合、現在のイベントの親原因ＩＤ項は適宜、因果パスウェイに関連付けられた原因ＩＤ項に設定され、そうでない場合、現在のイベントの親原因ＩＤ項は、ニル原因ＩＤまたは空に設定される；イベントに対する他の関連情報を含むことができる。出力節がデータを修正し、または否定的帰結を引き起こす可能性がある他のアクションを取ったとき、出力節は、データまたはアクションの一部として生成された原因ＩＤ値を渡し、それにより関連因果パスウェイに沿って原因ＩＤの通信を開始する。

【0160】

否定的帰結を引き起こすために特定のデータ値および／または実行が必要とされる場合、原因イベント条件の節と、否定的帰結を最後に表示するＵＩコードとの間の何らかのソフトウェアパスウェイが、「因果パスウェイ」であるとここで定義される。因果パスウェイは概して、データパスウェイおよび実行パスウェイに分割することができる。解の一部として、原因ＩＤ項変数が因果パスウェイに結合（または付与）される。因果パスウェイに付与された原因ＩＤ項変数の値は、そのパスウェイの現在の状態に対する「理由」、すなわちデータがその現在の値を有する理由、または実行パスウェイが現在実行されている理由を表す。「理由」は、パスウェイに付与された原因ＩＤ項の現在の値によって指し示される原因イベントであると見なされる。データパスウェイと実行パスウェイとの間には重大な相互作用および重複が存在する可能性があり；実行パスウェイはデータを修正することが多く、データパスウェイは実行パスウェイをトリガすることが多いことに留意されたい。

【0161】

原因データパスウェイは、簡単な変数、オブジェクトインスタンス、データベースエントリ、複雑なデータ構造などのデータとして定義され、データの１つまたはそれ以上の可能な値が、最終的に否定的帰結をもたらす可能性がある。原因データは、ソフトウェア工学におけるデータの基準に応じて、多くの異なる形で表すことができる。たとえば、データは、簡単なブール値、整数値、浮動小数点値、列挙値、他のデータへのポインタ、他の固有タイプとして；クラス、構造、アレイ、コンテナ、より複雑なデータ構造などの集合体などで存在することができる。イベント節と否定的帰結を表示するＵＩコードとの間の各原因データパスウェイに対して、原因ＩＤ項変数が導入されて、そのデータに関連付けられる（付与される）。本明細書に論じるように、原因ＩＤ項内に記憶される原因ＩＤ値は、固有または擬似固有として記述される。概して、原因ＩＤ値は、少なくとも実質的に固有であるべきである。すなわち、原因ＩＤには、既知の固有値（たとえば、ＩＤを追跡して固有性を検証するプロセスによって割り当てられ、プロセスによって現在使用されていない値、および任意のプロセスによって使用される持続データ内に現在記憶されていない値）、または他の擬似固有ＩＤと衝突する確率が十分に低い擬似固有値（たとえば、何らかの所与のシステム状態に対して複数の原因イベントが不注意で同じ原因ＩＤを使用する確率が統計的に小さくなるように十分な合計値範囲でランダムに生成された値）が割り当てられるべきである。概して、何らかの擬似固有の原因ＩＤの必要なビットサイズは、原因イベントデータベース内の任意の時点に根本原因イベントに割り当てられた原因ＩＤの最大数に依存する。たとえば、いくつかの簡単な実施形態の場合、ランダム３２ビット値で十分であるが、より複雑な実施形態の場合、６４ビット（または１２８ビット）値が好ましい可能性がある。実質的に固有の原因ＩＤ値に対する十分な生成器は、システムが任意の所与の時点での使用中に不注意で同一の２つの原因ＩＤを有する可能性が、すべてのシステムインスタンスを組み合わせた寿命にわたって１％未満になるように設計されたものであるが、この可能性が低ければ低いほどよいことは理解されよう。

【0162】

データに結合された原因ＩＤ項の現在の値は、そのデータの現在の値に対する「理由」を事実上記述する。「理由」は、原因ＩＤ項が参照するデータベース内の原因イベント（またはまもなくデータベースに入る原因イベント）であると見なされる。原因ＩＤ項の現在の値は、データが現在有する値をなぜ有するかを記述することが知られている原因イベントを指し示す。いくつかの実施形態では、原因ＩＤ項の値は、一般的な意味で、データの値以外の態様を参照しない。原因ＩＤ項の値は、データの一般タイプ、変数名、記憶タイプもしくは位置、または標的データに関する何らかの他の一般特性もしくはメタデータを参照しない。原因ＩＤ項の値は、データの現在の値に対する１つまたはそれ以上のソースイベントのみを記述する。原因ＩＤ項変数の値は、関連付けられたデータの値に対する理由を記述するため、その原因ＩＤ項の値は、その関連付けられたデータの値が変化したときはいつでも変化する可能性がある。

【0163】

様々な実施形態では、ソフトウェアの開発にとって好都合になるように、原因データに関連付けられた原因ＩＤ項を異なる形で表すことができ、その原因データに結合することができる。原因データパスウェイを構成することができるデータの例示的な形には：簡単な変数、オブジェクト、データベースエントリ、および他のデータパスウェイを含むことができる。ブールフラグまたは列挙状態またはステータス変数などの簡単な原因データ変数の場合、簡単なデータ変数とともに「活動中」になるように、原因ＩＤ項変数を導入することができる。様々なプログラミング言語が、原因ＩＤ値を任意の変数に容易または効率的に結合するためのより多くの方法を提供することができる。たとえば、それを支持する言語では、標的原因データに対するテンプレート変数および関連付けられた原因ＩＤ項変数を含む汎用原因クラスを使用して、原因ＩＤ項を原因データに結合することができる。オブジェクトインスタンスデータの場合、原因ＩＤ項フィールドを含むように、オブジェクトのクラスを修正することができる。または、簡単な変数と同様に、汎用原因クラスを使用して、オブジェクト参照もしくは値を保持する変数を原因ＩＤに結合することもでき、またはその変数とともに「活動中」になるように、新しい原因ＩＤ変数を導入することができる。データベースエントリデータの場合、エントリに対する原因ＩＤフィールドを含むように、表を修正することができる。これは、原因イベントデータベース内に記憶された原因イベント以外のデータベース内のデータを参照していることに留意されたい。いくつかの実施形態では、必要に応じて原因ＩＤパラメータを他のタイプのデータに結合するために、類似または他の技法が使用される。

【0164】

原因実行パスウェイは、否定的帰結をもたらす可能性のあるシステムが取り得る任意の演算として定義される。実行パスウェイは、関数呼出し、演算子、コードブロック、ならびにソフトウェアシステムによって取られる他のアクションおよびアクション群を含む。実行パスウェイは、否定的帰結を実際に表示するジョブを有するＵＩ内の関数など、表示される否定的帰結を直接もたらすことができる。実行パスウェイはまた、他の因果パスウェイをトリガすること、および／または原因データを修正することによって、否定的帰結を間接的にもたらすことができる。実行パスウェイはまた、最終的に否定的帰結をもたらし得る値にデータの値を変化させることができる。

【0165】

データを間接的に修正することによるか、またはＵＩ変化を直接もたらすことによるかにかかわらず、否定的帰結をもたらす可能性のある各実行パスウェイに対して、通常は原因ＩＤ項パラメータが導入されて、そのパスウェイに付与される。実行パスウェイに結合された原因ＩＤ項の現在の値は、そのパスウェイが現在実行されている理由を事実上記述する。原因ＩＤ項の現在の値は、そのパスウェイの現在の実行がなぜ開始されたかを記述することが知られているデータベース内の原因イベント（またはまもなくデータベースに入る原因イベント）を指し示す。原因ＩＤ項変数の値は、現在の実行パスウェイが実行している理由を記述するため、その実行パスウェイを呼び出すための理由が変化するときはいつでも、その原因ＩＤ項の値も変化することができる。

【0166】

原因データを出力もしくは修正し、または他の原因実行パスウェイを呼び出す関数呼出しの場合、関数のパラメータリストに原因ＩＤ項パラメータを追加することができる。別法として、スレッドローカルな後入れ先出し（ＬＩＦＯ）データスタックを導入することもでき、関数呼出しまたは一連の呼出しを行う前に、スタックの前に原因ＩＤ項をプッシュすることができ、最も前の原因ＩＤ項を関数呼出し内で読み取ることができ、関数呼出しから返された後、原因ＩＤ項はスタックから取り出される。関数が原因ＩＤ項を受け付けるという事実を本質的に隠すため、実装の観点から一般には推奨されないが、非常に深いコールスタック内の多くの関数が修正される必要があり、ほとんどパススルーとして作用している場合は有用になる可能性がある。関数が２つ以上の原因入力を受け付けることができる場合、いくつかの実施形態では、原因データを修正するとき、または他の因果パスウェイを実行するとき、複数の入力原因ＩＤ項の中から選択する必要がある。いくつかの実施形態では、原因関数は、出力状態を招いた原因入力を識別するように適合され、その出力とともにそれらの入力の原因ＩＤ項の１つまたはそれ以上を含む。それを招いた原因入力を正確に選ぶことについて、以下に説明する。

【0167】

ソフトウェア関数演算子は、データ修正に密接に関連付けられた明確な挙動を有することが多い。したがって、ソフトウェア関数演算子は、実行およびデータパスウェイの境界にまたがる傾向がある。いくつかの実施形態では、典型的に、データ式を構成および評価するために使用される演算子には、新しい原因ＩＤ項パラメータが付与されていない。代わりに、原因領域におけるそれらのジョブは通常、各演算子の基本挙動の詳細、および演算子のその現在の実行時に提供された特有の入力値に応じて、適当な原因ＩＤ項を入力値から出力値へ選択的に伝搬することである。

【0168】

プログラミング言語が演算子の多重定義に対応する場合、要求されている基礎的なコア演算を実行することに加えて、原因入力および出力値の処理も提供し、出力値への自動伝搬のために適当な原因ＩＤ項を選択するように、演算子を多重定義することができる。言語が演算子の多重定義に対応しない場合、演算子として挙動し、出力値への入力原因ＩＤ項の適当な自動伝搬を実行する新しい関数を定義することができる。演算子が２つ以上の原因入力を受け付けることができる場合、原因データを出力するとき、または他の因果パスウェイを実行するとき、複数の入力原因ＩＤ項の中から選択する必要がある。

【0169】

いくつかの実施形態では、コードブロックは典型的に、ブロック内のアクションに対する理由を記述するために、必要に応じて、周辺の関数呼出しに渡された原因ＩＤ項を使用し、または別の実行パスウェイもしくはデータパスウェイによって返された原因ＩＤ項を使用することができる。いくつかの実施形態では、パスウェイがなぜ実行されているかを記述する適当な原因ＩＤ項を渡すために、必要に応じて、異なるプログラミング言語またはカスタムソースコードで存在し得る他の実行パスウェイを類似または適当な方法で修正することができる。

【0170】

演算をまたぐ原因ＩＤの伝搬
そのパスウェイから下流の原因データの割当て中、または別の原因実行パスウェイの実行をトリガするとき、または複数の原因入力を含む演算の結果を処理するときにどの原因ＩＤ項を出力データもしくはアクションに割り当てるかを選択するためなど、因果パスウェイがその出力に付与するために入力原因ＩＤ項値の選択を必要とするとき、現在のパスウェイによって引き起こされた任意のさらなるパスウェイの現在の状態に対する理由を正確に記述するために、そのパスウェイの、出力するために正しい原因ＩＤ項を提供することが必要である。概して、原因ＩＤ項の目的が、データパスウェイに対してデータの現在の値によって表される因果パスウェイの現在の状態に対する理由を記述することであるため、どの原因ＩＤ項が演算にわたって伝搬するかの選択は、その演算の各実行時の実際の入力および出力値に依存しており、実施形態ごとに変動することがある。

【0171】

以下の原因ＩＤ伝搬規則の適用は、それらの式の将来の評価に対する帰結を変化させるためにどのソース条件を修復する必要があるかをユーザに正確に知らせるために、任意の複雑さおよび構成の式にわたって適当なソース原因イベント情報を正確に伝搬するのに十分である。したがって、原因ＩＤ項伝搬規則の適用により、システムは、それらの式に依存していた否定的帰結の将来の帰結を変化させるためにどのソース条件を修復する必要があるかをユーザに正確に知らせることが可能になる。

【0172】

因果パスウェイが割り当てられまたはトリガされる（たとえば、原因データに値が割り当てられ、または原因実行パスウェイが実行される）たびに、その因果パスウェイに付与された原因ＩＤ項も割り当てられる（または上書きされる）。他の任意の演算のために必要とされる原因の取扱いに対して、割当ては、他の演算を取り扱うために使用されたものに取って代わることができる規則を有する特別な事例の演算と見なされる（これは、ソフトウェアにおける正常な割当ておよび割当て演算子が、たとえば追加演算子、またはブールＡＮＤ演算子などとは異なる形で挙動するという点で、同様に特別な事例になる傾向があることを反映する）。ソフトウェアの基準に応じて、割当てのソース（出力変数にコピーされている入力値）は概して、リテラル値、名前付き変数値、またはコンパイラで生成された名前のない一時変数値とすることができる。割当ての入力変数の値（特に、一時変数であるとき）は、任意の構成および複雑さの式の結果となり得る。

【0173】

通常、原因データが割り当てられたときまたは原因実行パスウェイがトリガされたときに割り当てられる原因ＩＤ項は、割り当てられているまたは実行をトリガしている入力原因式から直接調達される。しかし、入力式の原因ＩＤ項が無視される事例があり、割当てのために基礎的なデータをコピーするとき、代わりにニル原因ＩＤ項が割り当てられる。割当てのためにいくつかの実施形態によって使用される規則がここにリスト化されており、入力式に付与された原因ＩＤ項をいつ使用するか、およびニル原因ＩＤ項をいつ使用するかを記述している。これらの規則は、「データ」（原因データパスウェイ）への割当てについて記載しているが、これらの規則は、どの原因ＩＤ項を原因実行パスウェイに付与するかを選択するときにも当てはまり、原因ＩＤ項は、データが付与されていない原因ＩＤ項タイプのパラメータとして直接指定されてもされなくてもよいことに留意されたい。いくつかの実施形態では、処理効率または他の望ましい特徴を考慮に入れて、他の規則を使用することもできる。

【0174】

否定的帰結との割当て：常に最終的に否定的帰結を引き起こすことが知られている値に原因データが割り当てられた場合、そのデータに付与された原因ＩＤ項もまた、新しいデータ値を割り当てた原因イベントを表す原因ＩＤ項に同時に割り当てられるべきである。割当ての入力値がリテラル値である場合、原因ＩＤ項は通常、（ａ）割当てが出力節の一部として起こっている場合、原因イベント条件の出力節で生成された原因イベントの原因ＩＤ、または（ｂ）割当てを招いた別の原因式もしくはデータの原因項から調達されることになる。割当てが別の原因データからきた場合、ソースデータの原因ＩＤ項は典型的に、割当ての標的にそのまま割り当てられる。

【0175】

否定的帰結のない割当て：最終的に否定的帰結を引き起こさないことが知られている値にデータが割り当てられた場合、そのデータに関連付けられた原因ＩＤ項は、ニル原因ＩＤ項値に同時に割り当てられるべきである。これは典型的に、イベント条件節の外のコードで発生し、データ値は、たとえば何らかの形のリセット、回復、初期化、新しい要求などのため、否定的帰結を引き起こさない状態に変化させることができる。これはまた、イベント条件節において、独自の否定的帰結を開始するプロセスで他の否定的帰結条件をクリア（またはリセット）しているとき、同様に発生する可能性がある。これはまた、代わりにニル原因ＩＤ項を割り当てることを優先して、割当ての入力値に付与された非ニル原因ＩＤ項が故意に無視されることを意味することができる。「可能な否定的帰結との割当て」値（次の段落に記載）が、現在のコンテキストで否定的帰結を引き起こさないことが最後に知られた場合、ニル原因ＩＤ項を優先して、その「ときどき」の値に関連付けられた原因ＩＤ項は最後に無視される。

【0176】

可能な否定的帰結との割当て：否定的帰結をときどき引き起こすが、常に引き起こすわけではない値にデータが割り当てられ、どの帰結が発生するかが現在の実行コンテキストで知られていない場合、いくつかの実施形態では、そのデータに関連付けられた原因ＩＤ項は、否定的帰結の割当てと同様に、最終的にそのデータ値を割り当てた原因イベントの原因ＩＤ項に割り当てられるべきである。実行中の後の時点で、データの値が否定的帰結を表さないことが知られたとき、データ値がここで否定的帰結をもたらさないことが知られているため、影響された式は、ここで割り当てられた原因ＩＤ項を無視し、代わりにニル原因ＩＤ項を伝搬しまたは割り当てる。

【0177】

ソース原因ＩＤ項のない否定的帰結との割当て：否定的帰結を引き起こすことが知られている値にデータが割り当てられたが、その値を引き起こした原因イベントを表す原因ＩＤ項をデータ割当てに通信することができない場合、そのデータに関連付けられた原因ＩＤ項は、ニル原因ＩＤ項に割り当てられるべきである。これにより、ＵＩが誤った原因情報をユーザに表示することが防止される。誤った原因情報を表示するより、原因情報を表示しない方がよいと見なされる。

【0178】

多くの場合、可変の原因ＩＤ項が付与された可変データとしてここで定義される原因変数に、何らかの複合式の出力が割り当てられ、割り当てられた値は、１つ、２つ、またはそれ以上の入力値で演算する１つ、２つ、またはそれ以上の演算から構成される。式の１つまたはそれ以上の部分自体が、一時変数または名前付き変数であるかどうかにかかわらず、原因値（原因変数または原因リテラル）である場合、その式から割り当てられた原因ＩＤ項は、式中のどの実際の部分式および／または入力データ値が出力される最終値に寄与したかを反映することになる。これにより、否定的帰結に対する正しい理由が選択され、ソース条件からＵＩ表示までシステムを流れることが可能になる。出力原因変数に付与された原因ＩＤ項の値は、どの原因イベントがその出力変数の現在の値を招いたか、したがってどのイベントが実際の当該否定的帰結を引き起こしたかを反映するべきである。

【0179】

事実上、２つまたはそれ以上の原因入力を含む複合式または演算は、２つまたはそれ以上の異なる原因イベント条件が何らかの単一の否定的帰結に寄与する可能性があることを示唆する（これにより、可能な原因の複雑さが迅速に高まるため、根本原因を追跡するための従来の努力が困難になる）。加えて、いくつかの場合、異なる原因入力のサブセットだけが式の結果に寄与する可能性があり、これは、実際の結果値に寄与しなかった入力に関連付けられた原因ＩＤ項が、その結果値に付与されるべきではないことを示唆する。これは、否定的帰結に対する偽の根本原因がユーザに報告されることを防止するために重要である。因果的に任意の式を取り扱うために、式中の個々の各演算は、その原因入力および出力を適当に取り扱うように修正されるべきである。各演算は、その出力へ伝搬するためにその入力から正しい原因ＩＤ項を選択し、それに対応してその入力からのどの原因ＩＤ項をその出力から除外するかを選択する必要がある。これが行われた後、コンパイラが複雑なネスト化された式を取り扱う方法（たとえば、一時的な中間値による）の典型的な性質により、典型的に、開発者による特別な介入を必要とすることなく、式全体に対する原因出力を「自動」で計算することが可能になる。

【0180】

次の説明では、「原因値」は、（１）「基礎値」（同じく値に設定される任意のタイプを有する特定用途向けデータ）と、（２）基礎値が現在のように設定された理由を最終的に招いた原因イベントを記述する原因ＩＤ項値との集合体と定義されるものとする。ここで基礎値は本質的に、当該の演算が演算する正常なデータ型および値である。すなわち、これは、修正されていない演算に対する正常なオペランドである。その基礎値と合計した原因ＩＤ項の値は、その特有の基礎値を設定させた１つまたはそれ以上の原因イベントを記述する。

【0181】

任意の演算に対するどの入力原因ＩＤ項がその演算の出力値への伝搬のために含まれるべきか、およびどの原因ＩＤ項が伝搬のために除外されるべきかを計算するために、以下の規則に応じて、どの入力原因ＩＤ項がどの入力値と出力値の組合せに対して演算の出力へ伝搬するかを宣言する「因果表」が、まず演算に対して定義される。次いで、因果表によって指定された原因ＩＤ項伝搬挙動を呈するように、演算実装が修正される。データパスウェイに付与された原因ＩＤ項の目的は、そのパスウェイの現在の値または状態に対する「理由」（原因イベント）を記述することであるため、因果表は、演算に対する可能な入力値、複数の可能な同時入力が存在するときのそれらの組合せ、およびそれらの対応する出力値のすべての分析および分類に基づいて判定される。具体的には、演算に対する因果表はまず、原因の観点から、演算に対する入力値のすべての可能な組合せを、それらに対応する出力値とともに分類する。因果表は次いで、入力値のリスト化された各分類に対してどの入力原因ＩＤ項が伝搬するかを定義する。入力値の可能な各分類に対して出力値へ伝搬するように選択される原因ＩＤ項は、以下の規則に応じて、どの入力値が観察された出力値を引き起こしたかを分析することによって判定される。

【0182】

演算に対する因果表が判定された後、演算は次いで、ベース演算に加えて、この表によって定義される追加の原因挙動を実装するように、その従来の演算相手からコードで修正される。修正された演算全体の目標は、原因入力ではなかったかのように、元のベース（非原因）演算をその入力原因値の基礎値のすべてに適用し、次いでそれを原因値としたことを除いて、ベース演算と同じ値を出力することであり、正しい入力原因ＩＤ項がその値に付与される。出力に付与される原因ＩＤ項は、演算に対して開発された因果表に基づいて判定される。

【0183】

実施形態は、それらのプログラミング環境で最も好都合な形で、演算を修正することができる。たとえば、Ｃ＋＋の「＆＆」、「｜｜」、「＊」の演算子などの組込み演算子を修正するために、開発者は、原因値を入力として受け付け、原因値を出力として作成する演算子の多重定義（使用可能なとき）を提供することができ、原因値は、演算子が通常演算することになる基礎的な項目タイプと、原因ＩＤ項変数との集合体である。演算子の多重定義が使用可能でない場合、開発者は、ＣａｕｓａｌＡｎｄ（）、ＣａｕｓａｌＯｒ（）、ＣａｕｓａｌＭｕｌｔｉｐｌｙ（）などの同等の関数を提供することができる。当該演算がカスタム関数ですでに定義されており、したがってカスタム関数がここで、原因入力および出力を処理する必要がある場合、関数を直接修正することができ、または原因入力が提供されかつ原因出力が予期されるときに処理するための関数の多重定義もしくは代案を提供することができる。

【0184】

多くの実施形態では、原因機能を追加するために、従来の演算に次の修正が加えられる。演算は、「原因値」である１つまたはそれ以上の入力を受け付けるように修正される。原因値でない入力に対して、演算は、入力を原因値に一時的に格上げする（通常、中間のローカルまたは一時変数を介して）ように修正され、基礎値は元の入力の値に等しく、原因ＩＤ項はニル原因ＩＤ項に等しい。演算は、その入力の１つまたはそれ以上が原因値であるとき、原因値を出力するように修正される。このとき、出力される原因値は、ベースの適用に等しい基礎値、入力の基礎値に対する非原因演算、および基礎出力値が現在のように設定された理由を最終的に招いた原因イベントを記述する原因ＩＤ項値の集合体である。観察されたどの入力値が観察された出力値の原因であると見なされるかを判定するために、反事実的手法が利用され：入力の任意のサブセットの観察された値のすべてを変化させることにより出力の観察された値が変化することになる場合、入力値のそのサブセットはともに、観察された出力の１つの原因であると見なされる。入力のサブセットの観察された値のすべてを変化させることにより出力の観察された値が変化しないことになる場合、入力値のそのサブセットはともに、観察された出力の原因であると見なされない。概して、可能な各出力値に対して、観察された入力値の可能な各サブセットを分析して、入力値のどのサブセットが観察された出力を招いたか（すなわち、どの入力サブセットがその特定の出力の原因と見なされるか、および入力のどのサブセットがその特定の出力を招いていないか、およびどの入力サブセットが出力の原因と見なされないか）を判定する。観察された出力を招いたすべての入力サブセットが識別された後、それらのサブセット内の入力に関連付けられた原因ＩＤ項が出力へ伝搬される。出力へのその伝搬が起こる前に、複製を低減させ、出力を簡略化するために、可能な場合、それを招いた原因ＩＤ項が折り畳まれる。加えて、入力原因ＩＤ項のその最後のサブセットに関するさらなる意味を収集し、全体的な出力原因ＩＤ項の一部として含むことができる。このとき、これらの追加の意味を後に使用して、より詳細な問題解決論理および手法をユーザに提供することができる。

【0185】

関連付けられた因果パスウェイの現在の状態を招いた原因イベントを記述する原因ＩＤ値を含むことに加えて、原因ＩＤ項はまた、この項に含まれる原因ＩＤの追加の原因の意味を記述することができる。原因ＩＤ項は、次の形式：単一の原因ＩＤ「ｘ１」；「角括弧の意味」を有するピア化原因ＩＤ項のリスト、すなわち「［ｘ１．．．ｘｎ］」；「山括弧の意味」を有するピア化原因ＩＤ項のリスト、すなわち「＜ｘ１．．．ｘｎ＞」；または括弧内のピア化原因ＩＤ項の複合（すなわち合成）リスト（角括弧または山括弧セット内の個々の原因ＩＤ項の１つまたはそれ以上自体がネスト化されたピア化原因ＩＤ項となることができ、このネスト化は任意の深さとすることができる）のうちの１つによって表すことができる。すなわち、原因ＩＤ項は、原因ＩＤ、または原因ＩＤのネスト化された角括弧もしくは山括弧セットの別の原因ＩＤ項、またはより多くの原因ＩＤ項、たとえば「［ｘ１ ｘ３ ｘ５＜［ｘ４ ｘ２］ｘ４＞］」とすることができる。何らかのリスト内の原因ＩＤ項は、２回見られる最後の例の原因ＩＤ項ｘ４など、任意の回数だけ複製することができる。上記の原因ＩＤ項形成の意味について、以下の段落で説明する。

【0186】

原因ＩＤの括弧の意味の実際のソフトウェア表現は、コード内で括弧を使用することを必要としないことに留意されたい。ここでは括弧は、特定の意味を表すために使用される。いくつかの実施形態では、意味は、ピア化原因ＩＤ項、ピア化原因ＩＤ項に関連付けられた列挙値などを含むコンテナのタイプによって示すこともできる。

【0187】

ここで各原因ＩＤ項ｘ１、ｘ２、．．．ｘｎは、演算の基礎値入力項Ｘ１、Ｘ２．．．ＸＮのうちの１つに付与された原因ＩＤ項を表す。すなわち、ｘ１は主入力項Ｘ１に付与された原因ＩＤ項を表し、ｘ２は主入力項Ｘ２に付与された原因ＩＤ項を表し、以下同様である。したがって、たとえば、演算が２つの入力のみを有する場合、これは主入力項Ｘ１およびＸ２に関連付けられた原因ＩＤ項ｘ１およびｘ２にのみ関係する。

【0188】

大文字を有する角括弧の主入力項表記「［Ａｊ．．．Ａｋ］」は、何らかの原因演算の実行に対して観察される可変主入力項のサブセットを表し、サブセット［Ａｊ．．．Ａｋ］内の項のすべての値を同時に変化させることにより原因演算の観察された出力も変化することになる。このとき入力項「［Ａｊ．．．Ａｋ］」は集合的にともに、原因演算の観察された出力の１つの単一の原因であると見なされる。

【0189】

したがって、小文字を有する角括弧の原因ＩＤ項表記「［ａｊ．．．ａｋ］」は、主入力項［Ａｊ．．．Ａｋ］に関連付けられた１組の原因ＩＤ項を表すものとする。入力項サブセット［Ａｊ．．．Ａｋ］は集合的にともに、特定の観察された出力の原因であると考えられることから、主入力項［Ａｊ．．．Ａｋ］に関連付けられた原因ＩＤ項サブセット［ａｊ．．．ａｋ］は、原因演算の特定の観察された出力を集合的にともに引き起こした原因イベントを表す。

【0190】

原因ＩＤ項［ａｊ．．．ａｋ］によって表されるすべての原因イベントがともに、観察された出力を引き起こすことが必要とされたことから、次の同等のブール式は、観察された出力が変化するために、どの原因イベント（すなわち、主入力項）が変化しなければならないか：ＯｕｔｐｕｔＷｉｌｌＣｈａｎｇｅ＝Ｃｈａｎｇｅ（ａｊ） ＡＮＤ．．．ＡＮＤ Ｃｈａｎｇｅ（ａｋ）を表すように構築することができる。Ｃｈａｎｇｅ（ｘ）は、関連付けられた基礎的原因イベント条件の入力を変化させることによって、原因ＩＤ項ｘによって表される入力項が変化するかどうかを表し、変化した場合は真を返す。したがって、原因ＩＤ項［ａｊ．．．ａｋ］に関連付けられた原因イベントに関連付けられた条件のすべてが変化した場合のみ、ＯｕｔｐｕｔＷｉｌｌＣｈａｎｇｅは真になる。

【0191】

大文字を有する山括弧の表記「＜Ｂｊ．．．Ｂｋ＞」は、何らかの原因演算の実行に対して観察される可変入力項のサブセットを表すものとし、サブセット＜Ｂｊ．．．Ｂｋ＞内のいずれかの単一の入力Ｂｉを変化させること、およびその入力だけで、原因演算の観察された出力が変化することになり、これは＜Ｂｊ．．．Ｂｋ＞のすべての入力項に対して真である。＜Ｂｊ．．．Ｂｋ＞の各入力項はこのとき、原因演算の観察された出力の独立した原因であると見なされる。

【0192】

したがって、小文字を有する山括弧の主入力項表記「＜ｂｊ．．．ｂｋ＞」は、主入力項＜Ｂｊ．．．Ｂｋ＞に関連付けられた１組の原因ＩＤ項を表す。サブセット内の各主入力項＜Ｂｊ．．．Ｂｋ＞は、特定の観察された出力の独立した原因であると考えられることから、主入力項＜Ｂｊ．．．Ｂｋ＞に関連付けられた原因ＩＤ項サブセット＜ｂｊ．．．ｂｋ＞は、特定の観察された出力を互いに独立して引き起こした原因イベントを表す。

【0193】

＜ｂｊ．．．ｂｋ＞の原因ＩＤ項の各々によって表される各原因イベントは、観察された出力の独立した原因であると見なされたことから、次の同等のブール式は、観察された出力が変化するために、どの原因イベント（すなわち、主入力項）が変化しなければならないか：ＯｕｔｐｕｔＷｉｌｌＣｈａｎｇｅ＝Ｃｈａｎｇｅ（ｂｊ） ＯＲ．．．ＯＲ Ｃｈａｎｇｅ（ｂｋ）を表すように構築することができる。角括弧の表記と同様に、Ｃｈａｎｇｅ（ｘ）は、関連付けられた基礎的原因イベント条件の入力を変化させることによって、原因ＩＤｘによって表される入力項が変化するかどうかを表し、変化した場合は真を返す。したがって、＜ｂｊ．．．ｂｋ＞に関連付けられた原因イベントに関連付けられた条件のいずれか１つまたはそれ以上が変化した場合のみ、ＯｕｔｐｕｔＷｉｌｌＣｈａｎｇｅは真になる。

【0194】

手短に言えば、角括弧の表記［．．．］は、出力が変化するために、角括弧の内側に直接参照されるすべての原因イベントを修復しなければならないことを示し、山括弧の表記＜．．．＞は、出力が変化するために、角括弧の内側に直接参照される１つ（またはそれ以上）の原因イベントのみを修復しなければならないことを示す。たとえば、「［ｐｑｒ］」によって表記される原因ＩＤ項は、ｐ、ｑ、およびｒによって参照される原因イベントに関連付けられた条件のすべてが反転された（すなわち、発生しないように変化した）場合のみ、その原因ＩＤ項に関連付けられた基礎値が変化することになることを示す。対照的に、「＜ｐｑｒ＞」によって表記される原因ＩＤ項は、ｐ、ｑ、またはｒによって参照されるイベントに関連付けられた条件のいずれか１つまたはそれ以上が反転された（すなわち、発生しないように変化した）場合、その原因ＩＤ項に関連付けられた基礎値が変化することになることを示す。

【0195】

括弧表記内の入力項および原因ＩＤ項は、ネスト化することができる。たとえば、表記「＜ｐｑ［ｒｓｔ］＞」は、原因ＩＤｐに関連付けられたイベント自体、もしくはｑに関連付けられたイベント自体、または［ｒｓｔ］に関連付けられたイベントがすべてともに、出力が変化するために変化しなければならないことを示す。このネスト化は、任意の深さとすることができる。

【0196】

次いで、同等のブール式もネスト化される。たとえば、＜ｐｑ［ｒｓｔ］＞は：ＯｕｔｐｕｔＷｉｌｌＣｈａｎｇｅ＝Ｃｈａｎｇｅ（ｐ） ＯＲ Ｃｈａｎｇｅ（ｑ） ＯＲ （Ｃｈａｎｇｅ（ｒ） ＡＮＤ Ｃｈａｎｇｅ（ｓ） ＡＮＤ Ｃｈａｎｇｅ（ｔ））と表すことができる。原因ＩＤ項および含まれる原因ＩＤを介して、出力を変化させるためにどの原因イベントが変化する必要があるかに関するこれらのブール式はまた、原因ＩＤ項表記（すなわち、括弧付きの表記）に再び変換することができる。たとえば、式： ＯｕｔｐｕｔＷｉｌｌＣｈａｎｇｅ＝Ｃｈａｎｇｅ（ｒ） ＡＮＤ （Ｃｈａｎｇｅ（ｓ） ＯＲ Ｃｈａｎｇｅ（ｔ））は、括弧表記：［ｒ＜ｓｔ＞］に同等である。

【0197】

原因ＩＤ項のこれらのブール同値を使用して、まず原因ＩＤ項形式を同等のブール式に変換し、次いでブール代数の法則を使用して式を所望の形式に変形し、次いで再び原因ＩＤ項形式に変換することによって、他の同等の原因ＩＤリストを判定することができる。たとえば、原因ＩＤ項：＜［ｐｑ］［ｐｒ］＞は、ＯｕｔｐｕｔＷｉｌｌＣｈａｎｇｅ＝（Ｃｈａｎｇｅ（ｐ） ＡＮＤ Ｃｈａｎｇｅ（ｑ）） ＯＲ （Ｃｈａｎｇｅ（ｐ） ＡＮＤ Ｃｈａｎｇｅ（ｑ））に同等である。

【0198】

ブール分配法則によって、これは：ＯｕｔｐｕｔＷｉｌｌＣｈａｎｇｅ＝（Ｃｈａｎｇｅ（ｐ） ＯＲ （Ｃｈａｎｇｅ（ｑ） ＡＮＤ Ｃｈａｎｇｅ（ｑ））に等しい。これは次いで：［ｐ＜ｑｒ＞］に再び変換することができる。これは、＜［ｐｑ］［ｐｒ］＞が［ｐ＜ｑｒ＞］に意味的に等しいことを実証している。

【0199】

別のさらに簡単な例は、可換法則を使用する：
＜ｐｑ＞→ＯｕｔｐｕｔＷｉｌｌＣｈａｎｇｅ＝Ｃｈａｎｇｅ（ｐ） ＯＲ Ｃｈａｎｇｅ（ｑ）
→ＯｕｔｐｕｔＷｉｌｌＣｈａｎｇｅ＝Ｃｈａｎｇｅ（ｑ） ＯＲ Ｃｈａｎｇｅ（ｐ）
→＜ｑｐ＞

【0200】

次の原因ＩＤ項の同値は、ブール代数の法則から同様に導出することができる。否定的帰結を変化させるためにどの原因イベントを修復しなければならないかを記述する原因ＩＤ項表記をブール代数によって表すことができるため、これは通常のブール代数と同じ特性を受け、したがってブール代数の同一性および法則を活用して、原因ＩＤリスト上で様々な変形を実現することができる。ソフトウェアは、ユーザへの出力の簡略化および／または性能の改善のために、これらの変形を実行することを選ぶことができる。これらの変形を使用して、以下に説明する原因イベント報告方法のさらなる態様を簡略化することもできる：

【0201】

【表1】

【0202】

次の手順を使用して、任意の演算に対する因果表を構築する。これは、一例としてブールＡＮＤ演算を使用する。

【0203】

工程１：演算に対するすべての入力項、次いでそれらの入力項に対する入力値のすべての可能な組合せ、および演算からの対応する出力をリスト化する。各入力項に対する１つの列と、出力に対する１つの列とを使用し、それらの入力項に対する可能な入力値および対応する出力の各々の組合せに対して１つの行を使用する：

【0204】

【表2】

【0205】

中括弧付きの表記｛Ｘ，ｘ｝は原因値を表し、原因ＩＤ項「ｘ」は基礎値「Ｘ」に関連付けられる。ここで、原因演算ブールＡＮＤへの一般入力項は、｛Ｐ，ｐ｝および｛Ｑ，ｑ｝として指定され、ここでＰおよびＱはそれぞれ、基礎的なブール入力項（たとえば、真または偽を表すことができる変数）であり、ｐおよびｑはそれぞれ、それらの基礎入力値に現在関連付けられている可変の原因ＩＤ項である。「出力値」列の「？？」は、その方法によって判定している伝搬すべき標的原因ＩＤを表す。これは本質的に、その入力および出力に原因ＩＤを付与するように拡大された従来のブール表説明に対応することに留意されたい。

【0206】

工程２：リスト化された入力項の値およびそれらの入力項のみを変化させることでその行に記述された演算の出力が変化するかどうかを記述する入力項（たとえば、Ｐ、Ｑ、ＰＱなど）の可能な各サブセット（組合せ）に対する列を追加する。Ｍ個の入力項を有する演算の場合、すべての可能な１入力の組合せから始まり、それに続いてすべての可能な２入力の組合せ、次いで３入力の組合せなど、すべてのＭ入力の組合せまでを行い、それらは１つだけ存在することになる。この例では、演算ブールＡＮＤは２つの入力項を含み、したがってその表は、このように見えるように拡大される：

【0207】

【表3】

【0208】

ここでは、単一の組の括弧内にともにグループ化されたすべての入力項の値およびそれらの入力項のみが同時に変化したときに起こることを追跡するという目的で、角括弧表記［Ｘ１．．．Ｘｎ］が、異なる可能なサブセット（組合せ）のすべての入力項をグループ化するために使用される。この場合、２つの可能な１入力のサブセット［Ｐ］および［Ｑ］があり、１つの可能な２入力のサブセット［ＰＱ］がある。これは、すべての可能な入力サブセットの完全な集合であり、それに対応して表にリスト化されている。

【0209】

これらの列は、次の質問に対する答えを追跡するために使用される：括弧内にリスト化されたすべての項の値が変化し、かつ括弧内にリスト化されたそれらの項のみが変化した場合、行によって指定される演算の出力値が変化するか。「Ｙ」（「はい」）は、指定された入力項の値が変化し、かつそれらの項のみが変化した場合、出力値がその行の現在の出力値から変化することになることを表す。「Ｎ」（「いいえ」）は、指定された入力項の値が変化し、かつそれらの項のみが変化した場合、出力値がその行の出力値から変化しないことになることを表す。これは、演算の何らかの所与の評価に対してどの入力値（したがって、入力項）が観察された出力を引き起こしたかを判定するという問題の解決に対する反事実的手法の新規な使用を表す。

【0210】

たとえば、ＡＮＤ演算へのすべての可能な値入力を集合的に指定する４つの行の各々について、第１の行（列ヘッダが含まれる）から考慮するものとする：

【0211】

【表4】

【0212】

この行は、入力「ｆａｌｓｅ ＡＮＤ ｆａｌｓｅ」および対応する出力「ｆａｌｓｅ」によって、ＡＮＤ演算「Ｐ ＡＮＤ Ｑ」を指定する。［Ｐ］列は、Ｐの値を偽から真へ変化させることで演算の出力が偽から真へ変化しないため、「Ｎ」（「いいえ」）を得る。すなわち、その行に対する元の演算（左側の３つの列によって指定される）は「ｆａｌｓｅ ＡＮＤ ｆａｌｓｅ」であり、これは出力「ｆａｌｓｅ」をもたらす。Ｐを偽から真へ変化させることによって、これを「ｔｒｕｅ ＡＮＤ ｆａｌｓｅ」に変化させると、依然として出力「ｆａｌｓｅ」をもたらし、これは帰結を変化させない。したがって、［Ｐ］列は「Ｎ」を得る。

【0213】

［Ｐ］列と同様に、［Ｑ］列もまた、Ｑの値を偽から真へ変化させることでその行のＡＮＤ演算の出力が偽から真へ変化しないため、「Ｎ」を得る。最後に、［ＰＱ］列は、Ｐを偽から真へかつＱを偽から真へともに同時に変化させることによりその行の演算の出力が偽から真へ変化するため、「Ｙ」（「はい」）を得る。すなわち、その行に対する元の演算は（依然として）「ｆａｌｓｅ ＡＮＤ ｆａｌｓｅ」であり、これは出力「ｆａｌｓｅ」をもたらす。ＰおよびＱの両方を変化させることによって、これを「ｔｒｕｅ ＡＮＤ ｔｒｕｅ」に変化させると、出力「ｔｒｕｅ」をもたらすことになり、これは帰結を変化させる。したがって、［ＰＱ］列は「Ｙ」を得る。

【0214】

ここで、第２の行（列ヘッダが含まれる）は次のとおりである：

【0215】

【表5】

【0216】

この行は、入力「ｆａｌｓｅ ＡＮＤ ｔｒｕｅ」および対応する出力「ｆａｌｓｅ」によって、ＡＮＤ演算「Ｐ ＡＮＤ Ｑ」を指定する。この場合、［Ｐ］列は、演算を「ｆａｌｓｅ ＡＮＤ ｔｒｕｅ」から「ｔｒｕｅ ＡＮＤ ｔｒｕｅ」へ変化させることで（Ｐを変化させることによる）、帰結が偽から真へ変化することになるため、「Ｙ」を得る。［Ｑ］列は、演算を「ｆａｌｓｅ ＡＮＤ ｔｒｕｅ」から「ｆａｌｓｅ ＡＮＤ ｆａｌｓｅ」へ変化させることで（Ｑを変化させることによる）、偽の帰結が変化しないことになるため、「Ｎ」を得る。［ＰＱ］列もまた、演算を「ｆａｌｓｅ ＡＮＤ ｔｒｕｅ」から「ｔｒｕｅ ＡＮＤ ｆａｌｓｅ」へ変化させることで（ＰおよびＱの両方を変化させることによる）、偽の帰結が変化しないことになるため、「Ｎ」を得る。

【0217】

ここで、第３の行（列ヘッダが含まれる）は次のとおりである：

【0218】

【表6】

【0219】

この行は、入力「ｔｒｕｅ ＡＮＤ ｆａｌｓｅ」および対応する出力「ｆａｌｓｅ」によって、ＡＮＤ演算「Ｐ ＡＮＤ Ｑ」を指定する。［Ｐ］列は、演算を「ｔｒｕｅ ＡＮＤ ｆａｌｓｅ」から「ｆａｌｓｅ ＡＮＤ ｆａｌｓｅ」へ変化させることにより（Ｐを変化させることによる）、偽の帰結が変化しないことになるため、「Ｎ」を得る。［Ｑ］列は、演算を「ｔｒｕｅ ＡＮＤ ｆａｌｓｅ」から「ｔｒｕｅ ＡＮＤ ｔｒｕｅ」へ変化させることで（Ｑを変化させることによる）、帰結が偽から真へ変化することになるため、「Ｙ」を得る。［ＰＱ］列は、演算を「ｔｒｕｅ ＡＮＤ ｆａｌｓｅ」から「ｆａｌｓｅ ＡＮＤ ｔｒｕｅ」へ変化させることで（ＰおよびＱの両方を変化させることによる）、偽の帰結が変化しないことになるため、「Ｎ」を得る。

【0220】

ここで、第４の行（列ヘッダが含まれる）は次のとおりである：

【0221】

【表7】

【0222】

この行は、入力「ｔｒｕｅ ＡＮＤ ｔｒｕｅ」および対応する出力「ｔｒｕｅ」によって、ＡＮＤ演算「Ｐ ＡＮＤ Ｑ」を指定する。［Ｐ］列は、演算を「ｔｒｕｅ ＡＮＤ ｔｒｕｅ」から「ｆａｌｓｅ ＡＮＤ ｔｒｕｅ」へ変化させることで（Ｐを変化させることによる）、帰結が真から偽へ変化することになるため、「Ｙ」を得る。［Ｑ］列もまた、演算を「ｔｒｕｅ ＡＮＤ ｔｒｕｅ」から「ｔｒｕｅ ＡＮＤ ｆａｌｓｅ」へ変化させることで（Ｑを変化させることによる）、帰結が真から偽へ変化することになるため、「Ｙ」を得る。［ＰＱ］列もまた、演算を「ｔｒｕｅ ＡＮＤ ｔｒｕｅ」から「ｆａｌｓｅ ＡＮＤ ｆａｌｓｅ」へ変化させることで（ＰおよびＱの両方を変化させることによる）、帰結が真から偽へ変化することになるため、「Ｙ」を得る。

【0223】

工程３：工程２で追加および計算された列の情報に基づいて、伝搬すべき原因ＩＤの初期「非選別」リストを提供する列を追加する：

【0224】

【表8】

【0225】

この列を充填するために、次の規則が適用される。各行に対して、１つまたはそれ以上のセルが「Ｙ」に設定されている場合、非選別リストは以下によって構築される。「Ｙ」に設定された各セルに対して、そのセルの関連付けられた角括弧項「［．．．］」に関連付けられた原因ＩＤ項自体が角括弧に入れられ、その行に対するリストに追加される。すべての括弧原因ＩＤのリスト自体が、外側の１組の山括弧「＜．．．＞」に含まれる。山括弧は、関連付けられた項のいずれかの値が変化した場合に何が起こることになるかを表すために使用される（これを、関連付けられた項のすべてが変化した場合に何が起こることになるかを表す角括弧と比較されたい）。

【0226】

たとえば、ヘッダ「［Ａ］」、「［Ｂ］」、「［ＡＣ］」、「［ＣＤ］」、および「［ＤＢ］」を有する行に対するセルがすべて「Ｙ」に設定された場合、非選別リストは、「＜［ａ］［ｂ］［ａｃ］［ｃｄ］［ｄｂ］＞」に設定される。同様に、セル「［ＱＳ］」および「［ＰＱＲＳ］」が「Ｙ」に設定された場合、非選別リストは、「＜［ｑｓ］［ｐｑｒｓ］＞」に設定される。

【0227】

行内のすべてのセルが「Ｎ」に設定された場合、非選別リストは「＜Ｃｌａｕｓｅ ＩＤ＞」に設定される。

【0228】

工程４：各非選別リストに原因ＩＤ項変換を適用することによって導出された出力へ伝搬すべき原因ＩＤの「選別」リストを記憶する列を追加する：

【0229】

【表9】

【0230】

この列を充填するために、いくつかの実施形態では、各行に対する非選別リストをその対応する選別リストセルへコピーし、選別セル内の各リストに次の規則を順序正しく適用する。リストが「＜Ｃｌａｕｓｅ ＩＤ＞」に等しい場合、変化は存在しない。これが選別「リスト」である。これは、入力項が出力値に影響しないことを示し、いずれの出力原因ＩＤ項も、演算の外部の節から調達されるべきである。すなわち、その行内の出力値に対する原因ＩＤ項は、周辺のソースコード節を介して開発者によって手動で（適宜）割り当てられるべきである（これは、定数またはリテラルからの割当てに概ね同等である）。いくつかの実施形態では、入力からの原因ＩＤ項が出力へ伝搬されず、少なくとも修正済みの演算によって自動で伝搬されない（開発者は、節の文脈で、入力原因ＩＤ項のうちの１つを伝搬することが正しい行動であるが、特定用途向けであり、ここでは方法の範囲外であると判断する可能性がある）。

【0231】

いくつかの実施形態では、リストが角括弧付きの項を含む（すなわち、リストが＜Ｃｌａｕｓｅ ＩＤ＞に等しくない）場合、その原因ＩＤ項のサブセットもリスト内にある原因ＩＤ項の括弧付きの「［．．．］」サブリストを削除する。これは本質的に、リストを簡略化するための吸収および連合型の同値の適用であり、重要でない原因ＩＤ項を削除することによってより正確な結果をもたらす。

【0232】

たとえば、非選別リストが＜［ｐ］［ｓ］［ｐｑ］［ｑｒ］［ｒｓ］＞である場合、［ｐｑ］および［ｒｓ］の両方を削除して、リストを＜［ｐ］［ｓ］［ｑｒ］＞に変換するべきである。［ｐｑ］は、［ｐ］がリストにあり、［ｐ］が［ｐｑ］のサブセットであることから削除され；［ｒｓ］は、［ｓ］がリストにあり、［ｓ］が［ｒｓ］のサブセットであることから削除される。非選別リストが＜［ｑｓ］［ｐｑｒｓ］＞である場合、［ｐｑｒｓ］を削除して、リストを＜［ｑｓ］＞に変換するべきである。［ｐｑｒｓ］は、［ｑｓ］がリストにあり、［ｑｓ］が［ｐｑｒｓ］のサブセットであることから削除される。

【0233】

工程５：必要な情報のみを強調することによって人間とコンピュータの理解を改善するために、選別リストの表記を簡略化する列を追加する。この列はまた、各演算に対して出力すべき最終的な原因ＩＤ項およびそれらの意味的特性を反映する。したがって、「？？」の原因ＩＤ項は最終的に、この列からの情報で充填することができる：

【0234】

【表10】

【0235】

この列を充填するために、各行に対する選別リストをその対応する簡略化されたリストセルにコピーし、選別セル内の各リストに次の規則を順序正しく適用する。原因ＩＤ項の「［．．．］」の括弧付きの各リストに対して、「［．．．］」の括弧内に１つの原因ＩＤ項のみが存在する場合、その原因ＩＤ項から周辺の「［．．．］」括弧を削除する。たとえば、＜［ｐ］［ｓ］［ｑｒ］＞は＜ｐｓ［ｑｒ］＞に変換され；＜［ｐ］［ｑ］［ｒ］［ｓ］＞は＜ｐｑｒｓ＞に変換され；＜［ｐｑ］［ｐｒｓ］［ｑｓ］＞は変換を必要とせず；＜［ｑ］＞は＜ｑ＞に変換される。

【0236】

「＜．．．＞」の場合、「＜．．．＞」内に１つの原因ＩＤ項または１つの「［．．．］」括弧のみが存在する場合、周辺の「＜．．．＞」括弧を削除する。たとえば、＜［ｑｒ］＞は［ｑｒ］に変換され；＜ｐ＞はｐに変換され；＜［ｐｑ］［ｐｒｓ］［ｑｓ］＞は変換を必要とせず；＜ｐｑ＞は変換を必要としない。

【0237】

この時点で、方法は完了し、可能な各組の入力値に対する伝搬すべき原因ＩＤ項の最終リストが完成する。ここで、最終的な所望の情報のみを有するブールＡＮＤに対する最終的な表は次のとおりである：

【0238】

【表11】

【0239】

「｛Ｐ，ｐ｝」および「｛Ｑ，ｑ｝」は、原因値式、または一時的に原因値に格上げされ、ブールＡＮＤによって演算することができる非原因値式である。「｛ｕｎｄｅｒｌｙｉｎｇ＿ｖａｌｕｅ，ｃａｕｓａｌ＿ｉｄ＿ｔｅｒｍ｝」は、原因値を表す集合体であり、ここでｕｎｄｅｒｌｙｉｎｇ＿ｖａｌｕｅは、元のブールＡＮＤによって演算することができる何らかの値であり、ｃａｕｓａｌ＿ｉｄ＿ｔｅｒｍは、その基礎値に現在関連付けられている原因ＩＤ項である。ｕｎｄｅｒｌｙｉｎｇ＿ｖａｌｕｅの同じ値を、異なる時点で異なる原因ＩＤに関連付けることができることに留意されたい。ｃａｕｓａｌ＿ｉｄ＿ｔｅｒｍ値の現在の値は、ｕｎｄｅｒｌｙｉｎｇ＿ｖａｌｕｅがその現在の値をなぜ有するかを記述する。ｕｎｄｅｒｌｙｉｎｇ＿ｖａｌｕｅがそれらの異なる時点に同じ値をなぜ有するかについて、異なる時点で異なる理由が存在することがある。したがって、ｃａｕｓａｌ＿ｉｄ＿ｔｅｒｍの値は、ｕｎｄｅｒｌｙｉｎｇ＿ｖａｌｕｅの関連付けられた入力値が異なる時点で同じときでも、演算子の適用間で異なることがある。

【0240】

表の目的で、ｃａｕｓａｌ＿ｉｄ＿ｔｅｒｍは、次の値のうちの１つを有することができる：

【0241】

「ｐ」は、原因入力値Ｐに付与された原因ＩＤ項を表す。表の右側の出力値に対して、これは、出力ｕｎｄｅｒｌｙｉｎｇ＿ｖａｌｕｅの現在の値が、ｐに関連付けられた原因イベントにのみ依存し、したがって入力Ｐのｕｎｄｅｒｌｙｉｎｇ＿ｖａｌｕｅが仮に異なった場合、当該出力ｕｎｄｅｒｌｙｉｎｇ＿ｖａｌｕｅの値も同様に異なることになる（演算の詳細に応じる）ことを示す。

【0242】

「ｑ」は、原因入力値Ｑに付与された原因ＩＤ項を表す。表の右側の出力値に対して、これは、出力ｕｎｄｅｒｌｙｉｎｇ＿ｖａｌｕｅの現在の値が、ｑに関連付けられた原因イベントにのみ依存し、したがって入力Ｑのｕｎｄｅｒｌｙｉｎｇ＿ｖａｌｕｅが仮に異なった場合、当該出力ｕｎｄｅｒｌｙｉｎｇ＿ｖａｌｕｅの値も同様に異なることになる（演算の詳細に応じる）ことを示す。

【0243】

「＜ｐｑ＞」は、原因入力値ＰおよびＱにそれぞれ付与された原因ＩＤ項ｐおよびｑの両方を表す。表の右側の出力値に対して、ここで山括弧「＜ ＞」の使用は、出力ｕｎｄｅｒｌｙｉｎｇ＿ｖａｌｕｅの現在の値が、ｐおよびｑに関連付けられた原因イベントの両方に依存し、したがって入力ＰまたはＱのいずれか１つが仮に異なる値に設定された場合、当該出力ｕｎｄｅｒｌｙｉｎｇ＿ｖａｌｕｅの値も同様に異なることになる（演算の詳細に応じる）ことを示す。これは、この特定の出力の値を変化させるために、ｐまたはｑに関連付けられた原因条件の１つのみを場合により修復する必要があることになることを意味する。いくつかの実施形態は、ｐまたはｑの１つのみを選択し、それを出力に関連付けられた原因ＩＤとして返すことを選ぶ（以下参照）。

【0244】

「［ｐｑ］」は、原因入力値ＰおよびＱにそれぞれ付与された原因ＩＤ項ｐおよびｑの両方を表す。表の右側の出力値に対して、ここで角括弧「［ ］」の使用は、出力ｕｎｄｅｒｌｙｉｎｇ＿ｖａｌｕｅの現在の値が、ｐおよびｑに関連付けられた原因イベントの両方に依存し、したがって入力ＰまたはＱの両方が仮に異なる値に設定された場合、かつその場合に限り、当該出力ｕｎｄｅｒｌｙｉｎｇ＿ｖａｌｕｅの値も同様に異なることになる（演算の詳細に応じる）ことを示す。これは、この特定の出力の値を変化させるために、ｐおよびｑに関連付けられた原因条件の両方を場合により修復する必要があることになることを意味する。いくつかの実施形態は、ｐまたはｑの１つのみを選択し、それを出力に関連付けられた原因ＩＤとして返すことを選ぶ（以下参照）。

【0245】

ｐおよびｑは、ＰおよびＱにそれぞれ関連付けられた原因ＩＤ項を表すことに留意されたい。これらは各々、ニル原因ＩＤ値、原因イベントを参照する非ニル原因ＩＤ値、１つもしくはそれ以上の非ニル原因ＩＤ値のリスト、または別のネスト化された原因ＩＤ項に等しくなり得る。具体的に任意の所与の時点でこれらが何に設定されるかは、ソフトウェアアプリケーションの詳細に依存する。いくつかの実施形態では、集合体原因値のｕｎｄｅｒｌｙｉｎｇ＿ｖａｌｕｅ部分は、１つまたはそれ以上の時点で、ソフトウェアでリテラル真または偽の値に設定され、これらの時点で、ニルまたは非ニルの原因ＩＤ項が故意に指定され、真または偽とともに設定される。たとえば、原因ブール値が、原因イベント条件節の外でリテラル「ｔｒｕｅ」または「ｆａｌｓｅ」に設定された場合、原因ＩＤ項もまた典型的に、その時点で同様にニル原因ＩＤ項に設定される。リテラルの割当てが通常非ニル原因ＩＤ項も設定する唯一の場所は、原因イベント条件節内であり、ここで原因イベントが、単にポスティングされ、その原因ＩＤは、ブールがその時点で真もしくは偽になぜ設定されているかを記述するために、または下流因果パスウェイの一部として使用される。これはすべて、原因イベントおよびそれらの原因ＩＤがいつ、どのように、およびどこで生成されるか、ならびにそれらの基本目的が何であるかに関する上述した規則に応じる。上表の演算出力値に対して、ｃａｕｓａｌ＿ｉｄ＿ｔｅｒｍは、入力原因ＩＤ項のどれが出力値へ伝搬されるかを記述する。これはまた、どの入力原因ＩＤ項が故意に伝搬されないかを示唆する。

【0246】

＜ｐｑ＞と［ｐｑ］との主な違いは：＜ｐｑ＞は、入力値ＰまたはＱのいずれかが変化した場合に出力値が変化することを示し（これは、この特定の出力を変化させるために、公称ではｐまたはｑに関連付けられた原因条件の１つのみを修復する必要があることになることを意味する）、［ｐｑ］は、入力値ＰおよびＱの両方が変化した場合、かつその場合に限り、出力値が変化することを示す（これは、この特定の出力を変化させるために、公称ではｐまたはｑに関連付けられた原因条件の両方を修復する必要があることになることを意味する）ことである。その意味の違いにかかわらず、＜ｐｑ＞および［ｐｑ］は、両方で、ＰおよびＱの両方の値が出力値に対する直接原因理由であることを示すことを共通点として共有するのに対して、「ｐ」のみは、Ｐの値のみが出力値に影響することを示し、または「ｑ」のみは、Ｑの値のみが出力値に影響することを示す。いくつかの実施形態では、原因の性質が＜ｐｑ＞であるか、それとも［ｐｑ］であるかの指示はまた、将来の試行時に否定的帰結を変化させるために修復する必要がある原因の最小集合に関するさらなる情報を提供するために伝搬することができる。

【0247】

括弧内の原因ＩＤの数は、１または２に限定されるものではないことに留意されたい。その演算に対して存在する入力項と同じ数の原因ＩＤが、単一の組の括弧内に存在することができる。たとえば、演算が４つの異なる入力Ａ、Ｂ、Ｃ、およびＤを受け付けた場合、出力項内の原因ＩＤは、＜ａｂｃｄ＞、＜ａｃ＞、［ａｂｃｄ］、［ｃｄ］などを含む多くの異なる組合せを含むことができる。

【0248】

いくつかの実施形態では、＜ｐｑ＞、［ｐｑ］、または複数の原因ＩＤ項の伝搬を指定する他の帰結に遭遇したとき、ソフトウェアは、ｐまたはｑの１つのみを選び、原因ＩＤ項として出力値に関連付けて返す。これは、特に多くの場合、原因ＩＤ値または他の原因ＩＤ項のコンテナとしてではなく、原因ＩＤ項が単一の原因ＩＤ値として実装されたときに発生することがある。これは、性能の理由で行うことができる。いくつかの実施形態によって実行される、両方のｐおよびｑを返す（したがって複数の原因ＩＤのリストを単一の原因値に関連付ける）代替アクションは場合により、項目の任意かつ可変に長いリストおよび任意かつ可変に深いリストが、動的記憶を利用することを必要とし得るため、特に実時間の適用に関して、性能の問題をもたらす可能性がある。いくつかの実施形態では、２つの理由のため、単一の原因データ値につき１つの原因ＩＤ値を伝搬すると十分である。第１に、大半の場合、通常は１つの原因条件だけが、実際に経験した何らかの所与の障害モードに寄与する。第２に、否定的帰結に対して２つ以上の原因イベントが存在する場合、これらのイベントのうちの１つのみをユーザに表示すれば十分である。ユーザは、その１つの失敗ソースを修復し、再びアクションを試行することができ、まだ発生している別の原因イベントのために否定的帰結が発生し続ける場合、その他の原因イベントが次に表示され（前の原因イベントは修復され、したがって否定的帰結に寄与しなくなるため）、ユーザは次いで、その次の条件を修復し、再びアクションを試行することができ、否定的帰結を引き起こすすべての条件が訂正されるまで以下同様である。

【0249】

因果表が［ｐｑ］を返すことを指定するときに原因ＩＤ項ｐまたはｑの１つのみを返すことなど、演算の、出力するために指定することができる複数の原因ＩＤ項のサブセットのみを返すことを選ぶ実施形態では、原因ＩＤ項のサブセットのどれかを判定して指定された出力原因ＩＤ項から選択するための１組の規則は、最も有用な原因情報により、ユーザが：因果表によって指定された出力がニルおよび非ニルの両方の原因ＩＤ項を含む場合、ニル原因ＩＤ項より非ニル原因ＩＤ項を返すことを選び；原因ＩＤ項の２つまたはそれ以上が非ニルである場合、演算の「最も左」または「最も右」の入力を常に選ぶことができることを確実にすることを助ける。これらの場合、非ニル原因ＩＤ項が返され、これがユーザに表示される少なくとも１つの関連ソースイベントになる。また、演算に対する最も左または最も右の入力の同じものを選択することで、ソフトウェア開発者は、入力の順序に関して式をどのように配置するかに基づいて、たとえばどの式が演算子の左側または右側にくるかを介して、より低いレベルでどの原因イベントを表示することができるかを選ぶ上で、何らかの制御を有することが可能になる。

【0250】

いくつかの実施形態では、ソフトウェアは、単一の原因ＩＤ値を全体的な原因ＩＤ項に関連付けるのではなく、原因ＩＤ項を原因ＩＤのリスト、および場合により原因ＩＤ項のネスト化されたツリー構造として実装することを介して、１つの原因ＩＤ項につき複数の原因ＩＤ値を伝搬することができる。万一たとえば以前の演算から出力されたｐｑ型の原因ＩＤリストが、別の新しい演算に対する入力原因ＩＤ項として働く場合、その原因ＩＤ項内の原因ＩＤリストは、単一のユニット、たとえばＮｅｗＩｎｐｕｔ：ｐ＝ＯｌｄＯｕｔｐｕｔ：ｐｑとして処理される。新しい演算で出力として選択された場合、これはネスト化作用を有することができ、したがってすべての寄与する原因イベントが適当に捕捉される。これには、一度に１つのイベントだけでなく、否定的帰結を招いたすべての原因イベントをＵＩに同時に表示することが可能であるという利点がある。複数のイベントが原因となったときに一度に１つの根本原因イベントを表示するには、ユーザは、否定的帰結に対する単一の根本原因イベントを考察し、その単一のイベントを修復し、主なアクションを再試行し、否定的帰結を再び経験し、次の根本原因イベントを考察し、その次の根本原因イベントを修復し、主なアクションを再び再試行するというシーケンスを複数回繰り返す必要があり、すべての根本原因イベントが修復されるまで以下同様である。比較として、すべての根本原因イベントを同時に表示することで、ユーザは、主なアクションを再試行する前に、すべての根本原因イベントを一度に修復することを試行することが可能になり、時間を節約することができる。

【0251】

原因ＩＤ項を原因ＩＤ項のネスト化されたツリーとして実装する場合、ソフトウェアはまた、＜ｐ．．．ｑ＞の結果（すなわち、「すべてのこれらのイベントが発生した必要がある」）と、［ｐ．．．ｑ］の結果（すなわち、「これらのイベントのいずれかが発生した必要がある」）との意味の違いを、ネスト化された各原因ＩＤ項（ツリーノード）の一部として伝搬し、否定的帰結に含まれる原因条件の性質に関するさらなる情報をユーザに提供することができる。これは、ＵＩ表示の一部として、すべての原因イベントを修復する必要があるか、それともサブセットのみを修復する必要があるかを知ることができるため、ユーザにとって有用である。ＯｕｔｐｕｔＷｉｌｌＣｈａｎｇｅ＝Ｃｈａｎｇｅ（Ｐ） ＡＮＤ．．．ＡＮＤ Ｃｈａｎｇｅ（Ｑ）を有する［ｐ．．．ｑ］、およびＯｕｔｐｕｔＷｉｌｌＣｈａｎｇｅ＝Ｃｈａｎｇｅ（Ｐ） ＯＲ．．．ＯＲ Ｃｈａｎｇｅ（Ｑ）を有する＜ｐ．．．ｑ＞という上述した２次ブール同値に応じて、ソフトウェアは、各原因ＩＤ項に含まれるこれらの「括弧」の意味を利用して、帰結が変化するために修復する必要のあるイベントの最小数を計算することができる。ここでこの技法の説明では、「ノード」という用語は、原因ＩＤ項ツリー内の原因ＩＤ項を指す。

【0252】

ユーザに対する否定的帰結を訂正するために修復する必要のあるイベントの最小数を計算するために、システムは、根ノード（根本原因ＩＤ項）からの原因ＩＤ項の内部部分項ツリーに関する再帰的な降順分析を実行し、親項が修復済みと見なされるために所与のノードにおけるすべての子ノードを修復する必要があるかどうか（［］ノードの場合）、または親項が修復済みと見なされるためにそのノード内のいずれか１つまたはそれ以上の部分項を修復する必要があるかどうか（＜＞ノードの場合）を考慮に入れて、現在のノードを訂正するために修復しなければならない現在の各ノードにおいて、子ノードおよびイベント（すなわち、ノード内の原因ＩＤ）のサブセットを追跡、計数、および構築する。システムは、ツリー内のすべてのノードが補償され、かつすべての根項および部分項が、それらのツリーおよびそれらのサブツリー内に含まれる原因ＩＤの異なるサブセットを修復することによって、それらすべての根項および部分項を修復することができるすべての可能な方法のリストを有するまで、これを再帰的に行う。

【0253】

たとえば、否定的帰結に対する原因ＩＤ項が「＜ａｂｃ［ｄｅ＜ａｆ＞］＞」であった場合、本発明は、この追加の態様がなくても、次の原因イベントをすべて否定的帰結の根本原因として報告することになる（これらのイベント間に親子関係がないと仮定しており、親子関係がある場合、子イベントが表示リストから削除されることになる）：ａ、ｂ、ｃ、ｄ、ｅ、およびｆ。この追加の態様がある場合でも、本発明はまた、全体的な否定的帰結を訂正するために、ユーザはその全根本原因イベントリストの次のサブセットのうちの１つで条件を修復するだけでよいことを報告することができる：ａ、ｂ、ｃ、ｄｅａ、またはｄｅｆ。これらのサブセットは各々、「解サブセット」と見なすことができる。すなわち、単一のサブセット内のイベント条件を修復するだけで、ユーザの否定的帰結を変更するのに十分である。たとえば、イベントａおよびイベントａ単独を修復するだけで、否定的帰結を訂正するのに十分であり、同じことが、イベントｂまたはｃのみを修復することにも当てはまり：ａ、ｂ、またはｃのいずれかを単独で修復することで、否定的帰結が変更される。同じことがまた、イベントｄｅａのすべてまたはｄｅｆのすべてにおける収集されたイベント条件にも当てはまり、いずれのサブセットでも、そのサブセット単独でイベントのすべてを修復することで、否定的帰結を変更するのに十分である。以下に示す原因ＩＤブール同値の吸収原理によって、イベントａの存在自体でｄｅａを有用な解として不要にするのに十分であるため、さらなる分析はまた、表示された解のリストからサブセットｄｅａを削除することを可能にすることができる。

【0254】

この時点で、各解サブセット内のイベントの数を計数することができ、最小数のイベントを有するサブセット（または最小数のイベントに対して結合されたサブセット）を、否定的帰結に対する「最も簡単な可能性が高い」解として表示することができる。変形例は、修復すべき最小のイベントから修復すべき最多のイベントまで、異なる可能な修復シナリオを提示するために、すべての解サブセットを最小数のイベントから最多数のイベントへ分類された順序でユーザに表示することを含む。

【0255】

これに対するさらなる改良は、単一の各タイプの原因イベント条件を修復するために必要とされる実世界の努力が、たとえば外部の特定用途向け分析（たとえば、典型的に、根本原因イベント条件を解決する際に問題解決ガイドまたはサービスマニュアルで捕捉することができる）によって、すでに知られている場合、または推定することが可能である場合、各イベントタイプに対する数学的な重みとして、これらの努力値を分析結果に要因として含むことができることである。次いで、システムは、イベントの数を累計するのではなく解サブセット内の各イベントの重みを累計することができ、それによって可能な各解に必要とされる実際のまたは推定される実世界の努力を計算し、次いでそれを使用して、最小の実世界の努力から最多の実世界の努力まで、否定的帰結に対する推奨される解を順序付けることができる。

【0256】

たとえば、上記の個々のイベントタイプが、次の時間量：ａ＝６０分、ｂ＝４５分、ｃ＝１２０分、ｄ＝１０分、ｅ＝１０分、ｆ＝５分が固定されることを必要とすることが事前決定された場合、ソフトウェアは、各解サブセットを修復するのに必要とされる実際の努力：ａ＝６０分、ｂ＝４５分、ｃ＝１２０分、ｄｅａ＝８０分、ｄｅｆ＝２５分を計算することができる。この場合、修復すべきイベントの合計がより少ないサブセットが存在するが（すなわち、サブセットａ、ｂ、およびｃは各々、１つのイベントを有する）、最小量の実世界の努力を必要とする可能性が高い解サブセットはｄｅｆであり、２５分を必要とすることが発見された。解サブセットａ、ｂ、およびｃは各々、６０、４５、および１２０分の努力をそれぞれ必要とする。したがって、ソフトウェアは、すべての可能な解の最小の努力量を必要とする可能性が高いため、否定的帰結を固定するために、まずｄｅｆの修復を試行することを、ユーザに推奨することができる。

【0257】

次の例示的な演算は、いくつかの特有の一般的なタイプの演算を詳細に説明し、各組の原因ＩＤ規則の原因解釈および直観的理解を与える。

【0258】

ブール演算：これらは、「ｔｒｕｅ」および「ｆａｌｓｅ」のブール値に作用する演算である。特に、ここに記載する演算は、単一ビットの入力値でのみ演算する。背景として、論理ＮＯＴ（否定）、論理ＡＮＤ（論理積）、および論理ＯＲ（論理和）のコアブール演算に対する標準的な真の表をここに示す。上記の表と同様に、同じ基本規定が使用される。下表は、単項のＮＯＴ演算、ならびに２項のＡＮＤおよびＯＲ演算に対する入力のすべての可能な組合せを示す。

【0259】

【表12】

【0260】

再び同じ表をここに示すが、今回は上記の規則に応じて原因伝搬が更新されている。この場合も、上記の汎用因果表と同様に、同じ基本規定が使用される。ここで表中のすべての入力および出力値は、原因ブール値であると見なされる。原因ブール値は、標準的なブール値（「ｔｒｕｅ」または「ｆａｌｓｅ」）と、標準的なブール値がその特有の現在の値をなぜ有するかを表す何らかの原因ＩＤ項値との集合体である。以下、表中の各演算について詳細に説明し、各原因ＩＤ項出力に対する理論的根拠を与える。これらは各々、以下の因果表からの関連する抜粋を含む。

【0261】

【表13】

【0262】

ブール「ＮＯＴ」演算：ブールＮＯＴは、単項演算（単一の入力項）であり、２つの可能な入力値：「ｔｒｕｅ」および「ｆａｌｓｅ」のみを有する。次表は、ブールＮＯＴ演算から返されるべき原因ＩＤ項について、上記の方法からの中間工程とともに説明する。

【0263】

【表14】

【0264】

すべての事例において、入力項Ｐの値を変化させることで出力値が変化し、したがってすべての事例に対して、入力原因ＩＤ項「ｐ」は常に、出力へ簡単に伝搬される。

【0265】

ブール「ＡＮＤ」演算：次表は、２項（２つの入力項）のブールＡＮＤ演算から返されるべき原因ＩＤ項について、上記の方法からの中間工程とともに説明する。

【0266】

【表15】

【0267】

入力ＰおよびＱがどちらも偽に等しい値の第１の行では、出力は、通常のＡＮＤ演算に応じて偽に設定される。ここで、出力が偽になるように、ＰまたはＱも偽になることになり、この場合はどちらも偽である。すなわち、入力の両方が真に切り換わった場合、かつその場合に限り、出力は真に切り換わる。入力原因ＩＤ項「［ｐｑ］」が出力へ伝搬され、出力値が両方の入力の特有の値に依存したこと、およびそれらの入力値の両方が異なった場合、かつその場合に限り、出力値も同様に異なることになることを表す。

【0268】

入力Ｐが偽に等しく、入力Ｑが真に等しい値の第２の行では、出力は、通常のＡＮＤ演算に応じて偽に設定される。ここで、Ｑが偽に設定された場合、出力に対する変化はないことになる。Ｐが真に設定された場合、出力は真に変化することになる。入力原因ＩＤ項「ｐ」が出力へ伝搬され、出力値がＰの値のみに依存したことを表す。これはまた、Ｑの値が出力値の要因にならなかったことを反映する。

【0269】

入力Ｐが真に等しく、入力Ｑが偽に等しい値の第３の行では、出力は、通常のＡＮＤ演算に応じて偽に設定される。ここで、Ｐが偽に設定された場合、出力に対する変化はないことになる。Ｑが真に設定された場合、出力は真に変化することになる。入力原因ＩＤ項「ｑ」が出力へ伝搬され、出力値がＱの値のみに依存したことを表す。これはまた、Ｐの値が出力値の要因にならなかったことを反映する。

【0270】

入力ＰおよびＱがどちらも真に等しい値の第４の行では、出力は、通常のＡＮＤ演算に応じて真に設定される。ここで、出力が真になるように、両方の入力も真であることが必要である。すなわち、入力のいずれかが値を偽に切り換えた場合、出力値も偽に変化することになる。入力原因ＩＤ項「＜ｐｑ＞」が出力へ伝搬され、出力値が両方の入力の特有の値に依存したこと、およびそれらの入力値のいずれかが異なった場合、出力値も異なることになることを表す。

【0271】

ブール「ＯＲ」演算：次表は、ブールＯＲ演算から返されるべき原因ＩＤ項について、上記の方法からの中間工程とともに説明する。

【0272】

【表16】

【0273】

入力ＰおよびＱがどちらも偽に等しい値の第１の行では、出力は、通常のＯＲ演算に応じて偽に設定される。ここで、出力が偽になるように、両方の入力も偽であることが必要である。すなわち、入力のいずれかが値を真に切り換えた場合、出力値も真に変化することになる。入力原因ＩＤ項「＜ｐｑ＞」が出力へ伝搬され、出力値が両方の入力の特有の値に依存したこと、およびそれらの入力値のいずれかが異なった場合、出力値も異なることになることを表す。

【0274】

入力Ｐが偽に等しく、入力Ｑが真に等しい値の第２の行では、出力は、通常のＯＲ演算に応じて真に設定される。ここで、Ｐが真に設定された場合、出力に対する変化はないことになる。Ｑが偽に設定された場合、出力も偽に変化することになる。入力原因ＩＤ項「ｑ」が出力へ伝搬され、出力値がＱの値のみに依存したことを表す。これはまた、Ｐの値が出力値の要因にならなかったことを反映する。

【0275】

入力Ｐが真に等しく、入力Ｑが偽に等しい値の第３の行では、出力は、通常のＯＲ演算に応じて真に設定される。ここで、Ｑが真に設定された場合、出力に対する変化はないことになる。Ｐが偽に設定された場合、出力も偽に変化することになる。入力原因ＩＤ項「ｐ」が出力へ伝搬され、出力値がＰの値のみに依存したことを表す。これはまた、Ｑの値が出力値の要因にならなかったことを反映する。

【0276】

入力ＰおよびＱがどちらも真に等しい値の第４の行では、出力もまた、通常のＯＲ演算に応じて真に設定される。ここで、出力が真になるように、ＰまたはＱも真になることになり、この場合はどちらも真である。すなわち、入力の両方が偽に切り換わった場合、かつその場合に限り、出力は偽に切り換わる。入力原因ＩＤ項「［ｐｑ］」が出力へ伝搬され、出力値が両方の入力の特有の値に依存したこと、およびそれらの入力値の両方が異なった場合、かつその場合に限り、出力値も同様に異なることになることを表す。

【0277】

複合ブール式および原因同値：いくつかの実施形態では、一時値を使用して部分演算の中間結果を式に記憶することによって、任意の構成および複雑さのブール式にわたって、原因ＩＤ項を容易かつ正確に伝搬することができる。これは、原因ＩＤ項の伝搬が、ブール代数に必要とされる基本規則：冪等性、可換性、結合性、吸収、分配性、普遍限界、および補数性のすべてにわたって一貫していることを示すことによって実証される。次の表は、これらの同値のすべての計算を示し：適当な場合、異なるが同等の形式の各ブール式タイプに対して出力される原因ＩＤ項自体が同等であることを示す（これらのブール同値はここで、上述した原因ＩＤ項レベルではなく主演算レベルで適用されていることに留意されたい）。

【0278】

原因ＡＮＤおよびＯＲの冪等性が、図１４Ａおよび図１４Ｂにそれぞれ示されている。各表中の印を付けた列は、冪等演算中に原因伝搬の同値を実証するために、互いに等しくなるべきである。

【0279】

原因ＡＮＤおよびＯＲの可換性が、図１４Ｃおよび図１４Ｄにそれぞれ示されている。各表中の印を付けた列は、原因伝搬の同値を実証するために、互いに等しくなるべきである。

【0280】

原因ＡＮＤおよびＯＲの結合性が、図１４Ｅおよび図１４Ｆにそれぞれ示されている。各表中の印を付けた列は、原因伝搬の同値を実証するために、互いに等しくなるべきである。

【0281】

原因ＡＮＤおよびＯＲならびにＯＲおよびＡＮＤの吸収が、図１４Ｇに示されている。各表中の印を付けた列は、原因伝搬の同値を実証するために、互いに等しくなるべきである。

【0282】

原因ＡＮＤおよびＯＲならびにＯＲおよびＡＮＤの分配性が、図１４Ｈおよび図１４Ｉにそれぞれ示されている。各表中の印を付けた列は、原因伝搬の同値を実証するために、互いに等しくなるべきである。

【0283】

原因ＡＮＤおよびＯＲの普遍限界が、図１４Ｊに示されている。

【0284】

原因ＡＮＤおよびＯＲの補数性が、図１４Ｋに示されている。

【0285】

ドモルガンの法則を、上記の規則に対するさらなる試験として使用することができる。ドモルガンの法則は、ブール演算ＡＮＤおよびＯＲに対する次の同値を示す：

【数1】

【0286】

第１の同値は、ＡＮＤ演算をＯＲおよびＮＯＴ演算の複合式として表すことができることを示す。同様に、第２の同値は、ＯＲ演算をＡＮＤおよびＮＯＴ演算の複合式として表すことができることを示す。これらの同値を使用して、コアブール演算に対して上記で判定した因果表の一貫性および実用性の試験を助け、したがって全体的な因果規則の一貫性および実用性の試験を助けることができる。これは、各同値の右側の複合式に生成された因果表を適用し、それらを各部分式に適用して、最終出力値までの結果を構築し、次いで同値の右側によって出力される原因ＩＤ項が同値の左側のコア演算に対して宣言された原因ＩＤ項に整合することを検証することによって行われる。

【0287】

図１４Ｌの表は、ドモルガンの同値を介してＡＮＤの計算を分解する。左のＡＮＤ列１２８は、ＡＮＤに対して本発明に提示される公理的（コア）因果表を示し、右のＡＮＤ列１３０は、ＯＲおよびＮＯＴに対して本発明に提示される因果規則を適用した後にドモルガンの同値を使用して計算された最終原因値を示す。［ｐｑ］および＜ｐｑ＞の組合せの意味的タイプを含む各組の入力に対して返される原因ＩＤ項は、厳密に整合する。

【0288】

図１４Ｍの表は、ドモルガンの同値を介してＯＲの計算を分解する。左のＯＲ列１３２は、ＯＲに対して本発明に提示される公理的（コア）因果表を示し、右のＯＲ列１３４は、ＡＮＤおよびＮＯＴに対して本発明に提示される因果規則を適用した後にドモルガンの同値を使用して計算された最終値を示す。［ｐｑ］および＜ｐｑ＞の組合せの意味的タイプを含む各組の入力に対して返される原因ＩＤ項は、厳密に整合する。

【0289】

公理的ブール同値演算中のこれらの原因伝搬の同値は、原因ＩＤ項規則が互いに一貫していること、および原因伝搬が例示的な実施形態で意図したとおり機能していることを示す。図１４Ａ～図１４Ｂに見られるように、多くの実施形態では、ブール式で使用される原因出力は、そのドモルガン同値に一貫している。いくつかの実施形態によって使用される上記のブール演算およびそれらによってもたらされる原因出力値について、図１４Ｎに要約する。

【0290】

他のブール演算：ＡＮＤ、ＯＲ、およびＮＯＴ以外に、より多くのブール演算が存在することに留意されたい。２つのブール入力で演算するとき、合計１６個の可能な演算が存在する。これらは、ＸＯＲ、ＮＡＮＤ、ＮＯＲ、ＸＮＯＲ、および他のそれほど一般的でないものなどの演算を含む。これらの演算に対する因果表は、上記の方法を使用して直接導出することができる。これらの演算のいくつかは、ＡＮＤ、ＯＲ、およびＮＯＴに関して同等に表すこともでき、したがって上記のドモルガンの法則に対して行ったように、途中で同値を評価し、因果規則を適用することによって、それらの原因の真理表を導出することもできる。

【0291】

図１５Ａ～図１５Ｄの原因出力表は、上記の規則から導出され、またはコアＡＮＤ、ＯＲ、およびＮＯＴ演算に対する同値から導出された、すべての原因挙動が含まれた１６個のブール演算の一式である。

【0292】

図１５Ａ～図１５Ｄで、演算Ａｌｗａｙｓ Ｆａｌｓｅ、Ｎｏｔ ｏｎ Ｐ、Ｎｏｔ ｏｎ Ｑ、ＡＮＤ、Ｉｄｅｎｔｉｔｙ ｏｎ Ｐ、Ｉｄｅｎｔｉｔｙ ｏｎ Ｑ、ＯＲ、ＡＮＤ、ＯＲ、およびＮＯＴは、コア因果規則を実装する。２つの「一致」演算（演算１３０および１３２）は、可変入力からの簡単な割当てまたはその式に同等であり、ブール値は入力と出力との間で変化せず、入力原因ＩＤ項を出力原因ＩＤ項として簡単に選択する。「Ａｌｗａｙｓ Ｔｒｕｅ」（「恒真」演算１３６）および「Ａｌｗａｙｓ Ｆａｌｓｅ」（「矛盾」演算１３８）演算は、リテラルまたは他の定数値からの簡単な割当てまたはその式に本質的に同等である（ソースコード内の明示的な「ｔｒｕｅ」または「ｆａｌｓｅ」など）。この場合、出力原因ＩＤ項は、「＜ＣｌａｕｓｅＩｄ＞」として指定され、これは原因ＩＤ項が通常、周辺のソースコードブロックまたは節から手動で獲得および設定されるべきであることを示す。これらの演算は本質的に、ブール変数ならびに他のデータセットおよび演算へのデータおよびそれらの原因の「エントリポイント」を表す。したがって、原因ＩＤ項は、原因値を割り当てるときに原因ＩＤ項をいつ、どこで、およびどのように設定するかに関して上述した規則に従って設定される。リテラルが原因イベント条件出力節内にある場合、原因ＩＤ項値は、イベントの原因ＩＤに設定されてもされなくてもよい（適用の詳細に応じる）。リテラルが原因イベント条件出力節外にある場合、原因ＩＤ項は、ニル原因ＩＤ項に設定されてもされなくてもよい（この場合も、依存する）。

【0293】

他の演算に対する原因ＩＤ項規則も同様に挙動する。たとえば、ＸＯＲ１４６に対する原因ＩＤ項規則は、すべての値の帰結に対して、返された原因ＩＤが＜ｐｑ＞として指定されるように挙動する。これは、すべてのＸＯＲ入力の事例に対して、いずれかの入力を変化させることで出力が変化することを示す。

【0294】

上述したように、因果表を構築するための技法は、任意の数の入力を有する演算、すなわち３つ以上の入力を有する演算にも適用することができる。この技法を使用して、図１５Ｅに示す何らかのカスタム３入力ブール演算に対する因果表を構築する一例をここに示す。

【0295】

ここで、ＣｕｓｔｏｍＯｐｅｒａｔｉｏｎ（）関数は、３つの入力原因ブール項｛Ｐ，ｐ｝、｛Ｑ，ｑ｝、および｛Ｒ，ｒ｝を受け付け、表に従って、入力値の各々の可能な組合せに対して単一の原因ブール真または偽の値を出力する。出力値は、ここでは任意に一例として選択された。

【0296】

このカスタム演算はまた、標準的な２入力のブール演算から構築された任意の複合式（（￢Ｐ’）∧Ｒ’）∨（（Ｐ’∧Ｑ’）∧（￢Ｒ’））に同等になることに留意されたい。数学的な「プライム」記号’（単一アポストロフィ）が、ここで原因値を示すために略記として使用されることに留意されたい。したがって、ＣｕｓｔｏｍＯｐｅｒａｔｉｏｎ（）関数は、少なくとも２つの基本的な異なる方法で：ルックアップテーブルとして、または２入力ブール演算の複合式として、実際的に実装することができる。ルックアップテーブルとして実装される場合、返すべき原因ＩＤ項は、上記のように判定および符号化されることになる。複合式として実装される場合、２入力ブール演算の原因バージョンは、正しい原因出力を自動で導出する。上表は、因果表を構築する未修正の技法が、同値を介してこの表を暗示的に導出することにも再び完全に一貫していることを実証する。

【0297】

因果表を構築する工程２に対して、試験すべき入力項の７つの可能な組合せ：Ｐ、Ｑ、Ｒ、ＰＱ、ＰＲ、ＱＲ、およびＰＱＲ、したがって７つの対応する列が、表の中央に存在する。

【0298】

いくつかの、出力するために返されたより複雑な原因ＩＤ項に留意されたい。

【0299】

第１の行で、出力原因ＩＤ項「＜ｒ［ｐｑ］＞」は、この特定の帰結を訂正するために、ユーザは、原因ＩＤｒに関連付けられたイベント条件自体を訂正し（すなわち、入力Ｒを変化させる）、または原因ＩＤｐおよびｑに関連付けられたイベント条件をともに訂正する（すなわち、入力ＰおよびＱをともに変化させる）ことができることを示す。入力Ｒ、Ｐ、およびＱのすべてをともに変化させても、帰結が変化しないことに留意されたい。それが有効な分解能であった場合、「［ｐｑｒ］」として導出および反映されたことになる。

【0300】

同様に、行５、６、および７で、出力原因ＩＤ項はそれぞれ＜ｑ［ｐｒ］＞、＜ｐ［ｑｒ］＞、および＜ｐｑｒ＞である。これら３つの異なる行（出力）は同じ原因ＩＤを含むが、その意味は各々に対して異なる。行５で、＜ｑ［ｐｒ］＞は、帰結を変化させるために、ユーザがＱ自体を変化させ、またはＰおよびＲをともに変化させなければならないことを示す。行６で、＜ｐ［ｑｒ］＞は、帰結を変化させるために、ユーザがＰ自体を変化させ、またはＱおよびＲをともに変化させなければならないことを示す。行７で、＜ｐｑｒ＞は、帰結を変化させるために、ユーザがＰ、Ｑ、またはＲのいずれか１つを変化させることができることを示す。

【0301】

これはまた、ネスト化されたまたは合成の演算が行われるときに発生し得る原因の意味的報告のネスト化を実証する。すなわち、このカスタム演算に対する因果表が、（（￢Ｐ’）∧Ｒ’）∨（（Ｐ’∧Ｑ’）∧（￢Ｒ’））の上述した同値を介して導出された場合（ソースコード内で直接または間接的に適度に発生する可能性がある）、これらの同じ「ネスト化された」因果関係の帰結が発生する。図１５Ｆは、上記のドモルガンの導出と同様に、同値を介して導出された因果表である：

【0302】

行７で、列１０の原因出力「＜ｐｑｒ＞」は、列９の部分式の原因出力「＜＜ｐｑ＞ｒ」から直接導出されることに留意されたい。これら２つの原因出力の表現は同等である。これは、＜＜ｐｑ＞ｒ＞が、「帰結を変化させるために、ｒまたは＜ｐｑ＞のいずれか１つを訂正し、ここで＜ｐｑ＞は、ｐまたはｑのいずれか１つを訂正することを意味する」ことを意味し、＜ｐｑｒ＞が、「ｐ、ｑ、またはｒのいずれか１つを訂正する」ことを意味するからである。これらの文はどちらも、ユーザが全体的な帰結を訂正したいと考えたとしても、同一の意味、したがって同一の命令をユーザにもたらす。行２、列９で、その部分式に対する「［ｒ［ｐｑ］］」の参照は、［ｐｑｒ］に同等であるという点で類似の作用があり：これは、その部分式の帰結を変化させるために、ｒ、ｐ、およびｑのすべてをともに変化させなければならないことを意味する。しかしその場合、その特定の部分帰結は、最終出力まで到達せず：式全体で何らかの他の因果関係の結果によってマスクされて除去された。

【0303】

算術およびビット演算：これは概して、加算、減算、乗算、累乗など、出力原因変数のビットパターン全体に影響を及ぼし得る数値型に対して演算するすべての算術演算を含む。算術演算以外に、これはまた、ブール演算と同様に単一のビットだけでなく、変数内のすべてのビット群に対してブール演算を行うビット演算を含む。

【0304】

【表17】

【0305】

記号「◎」は、何らかの汎用算術演算を表す。「Ｍ」および「Ｎ」は、すべての可能な入力値を表す。

【0306】

表１０は、一般算術演算に対する基本的な「フォールバック」因果表を表し、いずれかの入力に対する変化が常に出力を変化させると仮定する。算術およびビット演算に対する可能な入力の数は、因果表に実際的に列挙するには大きすぎることが多いことに留意されたい。所望される場合、これらの演算に対するより多くの具体的な因果表をなお生成することができることが多い。

【0307】

第１に、原因ＩＤ項の伝搬は、否定的帰結を引き起こすことが知られている出力値に対して判定するだけでよい。算術演算の場合、単一の値または小さい１組の出力値だけが否定的帰結を引き起こす可能性があり、大部分の出力値は否定的帰結にならないことが多い。場合により否定的帰結を引き起こすことが知られているそれらの出力値に関連付けられた因果表の行のみが、伝搬された識別済みの原因ＩＤ項を有する必要があり：他の非原因出力値は無視することができる。

【0308】

第２に、負の値を引き起こす可能性がある算術演算の出力値は、「強制要素」になる特性を有する値に制限されることが多い。強制要素値とは、他の入力の値にかかわらず、出力値を強制的に単一の特定値にすることが知られている特定の演算に対する入力値である。他の入力の値にかかわらず、出力値を強制的に単一の特定値にする特性を満たす任意の入力値が、「強制要素」（または「強制入力値」）として知られているものとする。異なる演算に対する強制要素の例は、次のとおりである：

【0309】

乗算に対する「０」（ゼロ）：任意の値に０を掛けると、出力は常に０になる。すなわち、０の入力は、他の入力の値にかかわらず、常に出力を強制的に０にする。
（Ｍ）＊（０）＝０
（０）＊（Ｍ）＝０
ここでＭは任意の数に等しい。

【0310】

累乗の底入力に対する「０」および累乗の指数入力に対する「０」：０を任意の指数値で累乗すると、出力は０になり、０以外の任意のベース値を０の指数値で累乗すると、出力は１になる。累乗演算には出力値を強制する２つの要素があること、および強制された出力値が互いに異なることに留意されたい。候補強制要素のすべてが互いに対して予測可能な優先順位を有する場合（ここでは、０の底入力が０の指数入力に対して優先順位を得るため、これに該当する）、これらは強制要素と見なされる。これらの優先順位は、因果関係および適当な原因ＩＤ項選択を判定する要因として含むことができる。
（０）＾（Ｍ）＝０
（Ｎ）＊（０）＝１
ここでＭは任意の数に等しく、Ｎは０以外の任意の数に等しい。

【0311】

演算に対する「吸収要素」の数学的な概念を満たす値は、強制要素と見なされる。吸収要素とは、出力値を強制的に吸収要素と同じ値にする入力値である。累乗の指数入力に対する０の場合は出力を強制的に０ではなく１にするためそれを除いて、上記の例はすべて、吸収要素と見なされる。

【0312】

「ｓＮａＮ」（「ｓｉｇｎａｌｉｎｇ ｎｏｔ ａ ｎｕｍｂｅｒ」）、「ｑＮａＮ」（「ｑｕｉｅｔ ｎｏｔ ａ ｎｕｍｂｅｒ」）、「＋ＩＮＦ」（ｐｏｓｉｔｉｖｅ ｉｎｆｉｎｉｔｙ）、および「－ＩＮＦ」（「ｎｅｇａｔｉｖｅ ｉｎｆｉｎｉｔｙ」）値などのＩＥＥＥ７５４規格の特別な値。これらの値は強制要素として作用する。たとえば、ｑＮａＮ値への浮動小数点加算を介して任意の数を足すと、出力はｑＮａＮ値になる。

【0313】

因果表は、否定的帰結を引き起こす出力値に対する原因ＩＤ項を伝搬するだけでよく、したがってこれらの強制要素のいずれかが演算に対して否定的帰結を引き起こした場合、因果表を大幅に簡略化することができることが多い。一例は、ＩＥＥＥ７５４の浮動小数点乗算である。上述したＮａＮおよびＩＮＦの強制要素に加えて、値０も強制要素である。当該ソフトウェアが、ＮａＮ値とは別個に否定的帰結を表すためにＩＮＦまたは０の値を乗算で使用せず、否定的帰結を表すためにＮａＮ値のみを使用した場合、ＩＮＦおよび０の値の別個のリストを因果表から除外することができ、それらの除外された値は、強制要素値以外の行に暗示的に含むことができる：

【0314】

【表18】

【0315】

この表で、ＭおよびＮは、ＮａＮを除く任意の入力値である（ここでは説明を簡単にするために、ｑＮａＮとｓＮａＮとの違いは無視する）。

【0316】

同様に、演算が強制要素を含むが、それらの強制要素がいずれも、非強制要素とは別個に否定的帰結をもたらすために使用されていない場合、演算は、強制要素を有していないものとして処理することができる。

【0317】

いくつかの実施形態では、不必要な強制要素処理の実装を避けることで、信頼性、保守性、および演算性能が改善される。いくつかの実施形態では、原因イベント報告が追加されたソフトウェアは、この節の表のいずれも実装する必要がない。ここで算術およびビット演算は概して、次のカテゴリに分割することができ、これらのカテゴリは概して、各カテゴリ内で共通の因果表を共有する。

【0318】

強制要素を有していない算術演算：例としては、整数加算および減算、ならびにビット演算の一般的な実装が挙げられる。これにはまた、強制要素を有し得るが、強制要素と非強制要素との間で帰結を区別しない演算が含まれる。これらの演算に対する因果表（表１１）は通常、非常に簡単であり：＜ｐｑ＞の意味を有する原因ＩＤ項を入力から出力へ伝搬する。

【0319】

【表19】

【0320】

記号「◎」は、何らかの汎用算術演算を表す。「Ｍ」および「Ｎ」は、すべての可能な入力値を表す。

【0321】

強制要素を有する算術演算：例としては、ＩＥＥＥ７５４規格に応じて実装される浮動小数点演算が含まれ、ＩＥＥＥ７５４の浮動小数点演算として実装されるかどうかにかかわらず、以下により詳細に説明する強制要素を有する次の演算：乗算、除算、累乗などが含まれる。

【0322】

乗算：表１２は、唯一の強制要素がゼロである整数乗算、および強制要素０およびＮａＮを有するＩＥＥＥ７５４の浮動小数点乗算に対する原因関係を示す（話を簡単にするために、ｑＮａＮとｓＮａＮとの違いは無視し、＋ＩＮＦおよび－ＩＮＦの強制要素を無視する）。この表は、ＮａＮまたは０が否定的帰結を引き起こした可能性があることが知られているときに使用されることになる。何らかの所与のソフトウェアシステムで乗算表のこの特定の原因変形例を使用する必要は非常にまれである可能性が高いが、ここではそれの可能性があることを示すために含まれる。

【0323】

【表20】

【0324】

「Ｍ」および「Ｎ」は、別の行に明示的にリスト化されていない複数の組のすべての他の可能な入力値を表す。

【0325】

任意のＩＥＥＥ７５４の浮動小数点演算：表１３は、ｑＮａＮ、ｓＮａＮ、およびＩＮＦの強制要素を有する任意のＩＥＥＥ７５４の浮動小数点演算に対する汎用ベース因果表である（話を簡単にするために、＋ＩＮＦと－ＩＮＦとの違いは無視する）。この表は、出力値ｓＮａＮ、ｑＮａＮ、およびＩｎｆが否定的帰結を引き起こす可能性があるシステムに対して使用されることになる。

【0326】

【表21】

【0327】

ＩＥＥＥ７５４の浮動小数点加算：表１４は、強制要素ＮａＮを有するＩＥＥＥ７５４の浮動小数点加算に対する因果表であり（話を簡単にするために、ｓＮａＮとｑＮａＮとの違いは無視する）、規格内の他の強制要素は無視している。これを、強制要素を有しておらず、したがって簡単であり、毎回ｐまたはｑを送信する整数加算に対する因果表と対比されたい。この表は、出力値ＮａＮが否定的帰結を引き起こす可能性があるシステムに対して使用されることになる。

【0328】

【表22】

【0329】

除算：整数除算について、整数除算に対する因果表である表１５に関して説明し、ここで分子の０および分母の０はどちらも強制要素であるが、異なる結果をもたらす。ＩＥＥＥ７５４の浮動小数点除算について、ＩＥＥＥ７５４規格に応じてＮａＮ入力を含むように拡大された除算に対する因果表である表１６を介して説明する（ｓＮａＮとｑＮａＮとの違いは無視する）。表１５は、未定義の挙動（「ｕｎｄｅｆ／ｉｎｆ／ｅｒｒ」）または０が否定的帰結を引き起こす可能性があるシステムに対して使用されることになる。

【0330】

【表23】

【0331】

【表24】

【0332】

累乗：表１７は、ＮａＮ値を取り扱うように拡大された累乗に対する因果表である（ｑＮａＮとｓＮａＮとの違いは無視する）。これは、出力値ＮａＮおよび０が否定的帰結を引き起こす可能性があるソフトウェアシステムに対して使用されることになる。

【0333】

【表25】

【0334】

ほとんどのソフトウェアシステムの設計は、ユーザへの良好な原因報告を実現するために算術演算子の原因バージョンを実装することを必要としないことに留意されたい。したがって、算術の因果表の使用は概してまれなことになり、したがってほとんどのソフトウェアシステムに影響しないことになる。原因算術演算が必要とされる場合、何らかの所与の演算に使用される特有の表は、どの出力値または出力値のクラスが当該ソフトウェアシステムで否定的帰結を招く可能性があるかに依存する。

【0335】

比較演算：これには、次の演算：同等、不等、大なり、以上、小なり、以下などが含まれる。第１に、比較演算は基礎値のみを比較するべきであることに留意されたい。基礎値に関連付けられた原因ＩＤ項を比較するべきではない。多くの場合、出力型は入力型とは異なることがあることにも留意されたい。たとえば、ソフトウェアのほとんどの同等演算は、入力型にかかわらず、ブール型を出力する。概して、比較演算でいずれかの入力を変化させることにより出力も変化する。したがって、任意の比較に対する因果表は典型的に、＜ｐｑ＞の意味を有する原因ＩＤ項の入力値から出力値への直接的な伝搬である。これは、基礎入力値のタイプにかかわらず、ほとんどの比較演算に必要とされる原因挙動を満たす。

【0336】

【表26】

【0337】

実施形態を実装するとき、第１の工程は概して、上記のように因果表を判定することである。因果表が構築された後、演算は、指定された入力値に対する指定された入力原因ＩＤ項を出力するように修正されるべきである。ほとんどの実施形態は、システム内のすべての可能な演算を修正することも、すべての入力値の組合せをカバーするように演算を広範に修正することも必要としない。概して、演算内で否定的帰結を引き起こす可能性があるそれらの出力値のみに対して、原因ＩＤを伝搬する必要がある。いくつかの実施形態は、一般的なブール演算および比較演算のみを修正する。対応するソフトウェア言語および開発環境において、汎用体および演算子の多重定義を使用することで、これらの実装を大幅に簡略化することができる。

【0338】

以下は、ブールＡＮＤに対する例示的な実装である。ここで、Ｃ＋＋クラスＣａｕｓａｌは、開発者によって指定された任意のデータ型をラップし、そのデータ型に原因ＩＤ項を付与するテンプレートクラスである。この場合、原因ＩＤ項は、単一の原因ＩＤ値として実装され、この原因ＩＤ値は、ニル原因ＩＤ値または何らかの非ニル原因ＩＤ値とすることができる。これはまた、基礎型の値に対する原因報告および自動ダウンキャストを行うために演算子の多重定義を含む。これはまた、関数ＧｅｔＦｉｒｓｔＣａｕｓｅ（）を含み、この関数は、２つの指定された入力の原因ＩＤパラメータのうちのどちらでも非ニルＩＤになるものを返し、両方が非ニルである場合は第１のパラメータを選び、または両方がニルである場合はニルＩＤを返す。これは、いくつかの実施形態によれば、＜ｐｑ＞および［ｐｑ］の状況で、出力するために単一の原因ＩＤを選ぶことを支持する。この例示的なコードは、適当な場合、ｐおよびｑの両方を返す実施形態によって使用するために容易に修正することができる。
//論理ＡＮＤ演算子、どちらのオペランドも原因型である。

template< typename t_ItemType1, typename t_ItemType2 >
decltype(auto)
operator&& (
const Causal<t_ItemType1> & a_rCausalOperand1,
const Causal<t_ItemType2> & a_rCausalOperand2)
{
// ? && ?
if (t_ItemType1(a_rCausalOperand1))
{
// true && ?
if (t_ItemType2(a_rCausalOperand2))
{
// true && true
return Causal(
t_ItemType1(a_rCausalOperand1) &&
t_ItemType2(a_rCausalOperand2),
GetFirstCause(a_rCausalOperand1, a_rCausalOperand2));
}
else
{
// true && false
return Causal(
t_ItemType1(a_rCausalOperand1) &&
t_ItemType2(a_rCausalOperand2),
a_rCausalOperand2.GetCausalId());
}
}
else
{
// false && ?
if (t_ItemType2(a_rCausalOperand2))
{
// false && true
return Causal(
t_ItemType1(a_rCausalOperand1) &&
t_ItemType2(a_rCausalOperand2),
a_rCausalOperand1.GetCausalId());
}
else
{
// false && false
return Causal(
t_ItemType1(a_rCausalOperand1) &&
t_ItemType2(a_rCausalOperand2),
GetFirstCause(a_rCausalOperand1, a_rCausalOperand2));
}
}
}

【0339】

ここに、原因乗算を実装するための例示的なコードを示し、任意の値が否定的帰結を引き起こす可能性がある。
//乗算演算子、ここでどちらのオペランドも
//原因型である。

template< typename t_ItemType1, typename t_ItemType2 >
decltype(auto)
operator* (
const Causal<t_ItemType1> & a_rCausalOperand1,
const Causal<t_ItemType2> & a_rCausalOperand2)
{
return Causal(
t_ItemType1(a_rCausalOperand1) *
t_ItemType2(a_rCausalOperand2),
GetFirstCause(a_rCausalOperand1, a_rCausalOperand2));
}

【0340】

本明細書全体にわたって論じる他の原因関数も、類似の手法を使用して実装することができる。この原因乗算演算子の実装は、特有の出力値（０（ゼロ）またはＮａＮなど）の結果を追跡しないため、その実装および同等の演算子の実装はどちらも、原因ＩＤ伝搬に関して同一であることに留意されたい。２つの関数の唯一の違いは、出力の基礎値に対する演算子＊および演算子＝＝の適用である。

【0341】

ユーザインターフェース因果表示：ＵＩに要求されたアクション、またはＵＩに渡されたデータに基づいて、否定的帰結を表示するべきであるとＵＩが判定し、かつ否定的帰結を表示させているその実行パスウェイまたはデータパスウェイに非ニル原因ＩＤ項が関連付けられている場合、ＵＩは、原因イベントデータベース内のその原因ＩＤ項に関連付けられた原因イベントを参照し、次いでそれらのイベントを、否定的帰結に対する原因として表示すべき現在の候補イベントと見なす。候補イベントに非ニル親原因ＩＤ項が関連付けられている場合、その親原因ＩＤ項から親イベントが参照され、親イベントは、新しい候補イベントとしてそれらの子イベントに取って代わる。現在の候補に対して親イベントを発見するこのプロセスは、発見されたすべての候補イベントがニル親原因ＩＤ項を有するまで繰り返される。

【0342】

すべての候補イベントがニル親原因ＩＤ項を有することが分かったとき、それらのイベントは、否定的帰結に対する理由としてＵＩに表示される。理論上、イベント表示は否定的帰結表示に密接に関連付けられるべきであり、したがってユーザは、否定的帰結に対する理由を見つけるための検索をしなくて済み、または最小の検索で済む。ＵＩに否定的帰結を表示させた実行またはデータパスウェイに関連付けられた原因ＩＤ項が、ニル原因ＩＤ項値に設定されている場合、これは、否定的帰結に対して「原因が未知である」ことを示す。この場合、ＵＩは、否定的帰結に対する追加の原因イベント情報を表示しない。または、ＵＩは、「原因が未知である」に同等のインジケータなどを表示する。この挙動は、ニル原因ＩＤ項をいつ設定するか、または設定しないかに関する規則とともに、否定的帰結に対する誤った根本原因イベントがユーザに表示されないことを確実にする。

【0343】

マルチスレッドおよび他の形式の並列処理に基づいて、原因ＩＤに対する原因イベントは、その原因ＩＤに対する参照が発生したときに原因イベントデータベースにまだない可能性があることに留意されたい。これが当てはまる場合、イベント表示機能は理論上、イベントがデータベースに到達し、参照が成功するまで待つべきであり（参照を周期的に再試行すること、またはデータベース実装で使用可能な何らかの待機機能を利用することによる）、かつ／または、原因ＩＤに関連付けられた原因イベントの発見に失敗した場合、ある時点でのタイムアウトまたは論理問題などを宣言するべきである。これは、非ニル原因ＩＤが、ここで解決策の定義上、データベース内のイベントまたはすぐにデータベースに入るイベントを常に参照していることになるからである。何らかの妥当な期間後も原因イベントを発見できない原因ＩＤは、原因イベント報告システム外の論理、通信、または他の類似の問題を示すことになる。

【0344】

術語
否定的帰結：ＵＩによってユーザに表示される失敗ステータス。典型的に、表示される失敗は、２つの概略的なカテゴリ：ユーザ要求の実行の成功に対するソフトウェアシステムによる失敗（成功がユーザによって予期されたとき）、および新しい将来の要求の処理に対するソフトウェアシステムの１つまたはそれ以上の部分の使用不能性（使用可能性がユーザによって予期されたとき）に入る。否定的帰結の一般特性は、全体的なソフトウェアシステム内のどこかで１つまたはそれ以上の原因イベント条件によって常に引き起こされ、したがって概念上はそれらの１つまたはそれ以上のイベント条件まで遡って追跡可能であることである。ここで定義されるいくつかの否定的帰結は、システムの初期化手順が長時間にわたって実行中であるために、システムが一時的にスタートアップに使用可能でないなど、実際には深刻と見なされないことがあり、または通常はユーザの観点から「肯定パス」と見なされることさえあるが、それらはシステムの使用不能性を表し、または要求の拒否もしくは失敗を引き起こす可能性があり、したがって場合によりユーザを（一時的にでも）苛つかせる可能性があるため、ここで否定的帰結の定義に含まれる。すなわち実際には、これらの場合、肯定パスおよび／または深刻でないと見なされたものが根本原因であり（たとえば、ユーザアクションによるシステムのスタートアップ）、否定的と見なされ、したがってユーザをなお苛つかせるものが帰結である（たとえば、新しい将来の要求を（一時的に）処理できない）。これらのタイプの肯定パスの否定的帰結はまた、使用不能性のソースを報告することによって、ここでも同様にユーザの苛立ちを低減させるのに役立つことができるため、原因イベント報告の発明から大きな利益を得る。

【0345】

原因イベント条件（またはイベント条件）：ソフトウェア内の条件分岐点、および分岐点の条件が満たされたときに実行される関連出力節。ここで出力節は最終的に、ＵＩが否定的帰結をユーザに表示することを引き起こすことができる。典型的に、原因イベント条件は、エラーを検出する条件、ユーザアクションを検出する条件、およびユーザに対する否定的帰結を引き起こす可能性がある他のシステム検出または入力に対応する。条件分岐点は、ソフトウェアプログラミングで使用可能な通常の条件構成体、たとえば「ｉｆ」文、「ｉｆ／ｅｌｓｅ」文、「ｓｗｉｔｃｈ」文、３項演算子「？：」、様々なループ条件、そのような機械命令実装などのいずれかとすることができる。これらの条件構成体は典型的に、もしあればどの出力節が実行されるかを判定するために評価される条件式を含む。

【0346】

条件に関連付けられた出力節は、任意の深さの他の関数または実行コードへの部分呼出しを含む単一の文または１群の文とすることができる。出力節はまた、ソフトウェアシステムの他の任意の部分への呼出しおよび出力を含む。ここでは出力節という用語は、満たされている条件の下流の結果を全体として包含するために使用される。いくつかのソフトウェア言語の条件文は、２つ以上の出力節を含むことができるため、コード内の単一の条件文が複数の原因イベント条件を含むこともできることに留意されたい。たとえば、「ｉｆ／ｅｌｓｅ」文は、その単一の明示条件式によって、２つの出力節を含む。「ｉｆ」の部分は、明示条件式および節を含み、「ｅｌｓｅ」の部分は、その節によって、「ｉｆ」部分に含まれる明示式の否定に等しい第２の条件式を暗示する。別の例として、「ｓｗｉｔｃｈ」文は、任意の数の出力節を含むことができ：「ｓｗｉｔｃｈ」文の各「ｃａｓｅ」節はまた、追加の条件を指定する。これらの場合、何らかの出力節とその明示または暗示条件との組合せは、その節の実行が否定的帰結をもたらす可能性がある限り、別個の原因イベント条件と見なされる。同様に、コード内の単一の条件文の複数の節のいくつかのみが原因イベント条件である可能性もある。節が否定的帰結に寄与することが知られていない場合、これは原因イベント条件を形成しない。同様に、条件文に関連付けられた節がいずれも、否定的帰結を引き起こすことが知られていない場合、その条件文およびその節は原因イベント条件ではない。

【0347】

いくつかの実施形態では、ＵＩ内の表示された否定的帰結が原因条件および節からどれだけ「離れている」かも、節が常にＵＩに否定的帰結を表示させているか否かも問題でない。条件およびその関連付けられた出力節が、ほんのときどきでもユーザに対する否定的帰結の生成に寄与する可能性がある場合、これは原因イベント条件と見なされる。原因イベント条件となるために必要なものは、条件および節が既知の否定的帰結の一部であることであり、したがって節を実行するには、否定的帰結を引き起こす必要がある。これは、条件が部分的にのみ必要な場合でも当てはまる（すなわち、実行して否定的帰結を引き起こすために同じく必要とされる他の条件および節があり、これらも同様に他の原因イベント条件になり得る）。

【0348】

明示的原因イベント条件：条件文およびその直接出力節が開発者による修正のために使用可能なコードで表されている原因イベント条件。

【0349】

暗示的原因イベント条件：条件文およびその直接出力節が開発者による修正のために使用可能でないコードで表されているが、条件の節は、開発者の制御下にあるコードに否定的帰結を表示させることができる原因イベント条件。これは典型的に、開発者が修正するために使用可能でないが、開発者のアプリケーションに否定的帰結を表示させることができるコードのイベント条件である。典型的な例としては：マウスクリック、キーボードタイピング、および他のユーザ開始ハードウェア入力、（サードパーティオペレーティングシステムまたは他の外部環境内の外部コードが、これらのイベントを検出してファーストパーティアプリケーションコード内のコールバック関数または他の入力システムに送り込む条件を含む）；ネットワーク入力イベントおよびデータ（サードパーティソフトウェアが、ファーストパーティコードへのネットワークまたは他のデータの送信をもたらす条件を含み、次いでファーストパーティコードが否定的帰結を引き起こす）；アプリケーションスタートアップ（サードパーティオペレーティングシステムソフトウェアが、アプリケーションプロセススタートアップ要求を検出するために使用される条件を含み、したがって新しいアプリケーションプロセスの「ｍａｉｎ（）」または類似の関数を条件の出力節の一部として呼び出し、アプリケーションのスタートアップおよび初期化が、システムが一時的に使用不能になる有効な理由となり、これも本発明者らの目的で（一時的な）否定的帰結と見なされる）などのユーザ入力イベントが挙げられる。

【0350】

これらの場合はすべて、いくつかの実施形態では、外部システムが外部条件の結果としてファーストパーティソフトウェア（局所的な開発者定義関数コールバックなど）を呼び出す第１の局所コードを、暗示的イベント条件の出力節の一部と見なすことができる。これは、条件部分が実際には外部サードパーティコードに存在する場合でも当てはまる。したがって、暗示的原因条件による影響を受ける第１の局所ファーストパーティコード（節）は、公称では、原因イベント条件として挙動するべきであり、これは、適宜原因イベントをポスティングして、局所下流結果とともに原因ＩＤの伝送を開始するべきであることを意味する。これにより、外部条件に対する原因イベントデータベースによって原因イベントをなお生成および追跡することが可能になる。

【0351】

出力節：その条件式が評価されて満たされたときに条件文によって取られるアクション。この定義では、出力節は概して、条件に起因する下流アクションのすべてを包含する。これは、ここで節の「最上」コードであると定義され、多くの場合は条件式に隣接または近接する単一の文または１群の文としてコードで、ソースコードと同じレベルで表される「直接」出力節、ならびに直接出力節によって呼び出されてトリガされる下流コードおよびアクションである「間接」出力節を含む。これは、関数、オブジェクト、プロセス、またはコンピュータ境界などの様々なソフトウェア境界にまたがることができる。

【0352】

「ｉｆ／ｅｌｓｅ」文の別個の「ｉｆ」および「ｅｌｓｅ」節および「ｓｗｉｔｃｈ」文の複数の「ｃａｓｅ」節など、２つ以上の出力節が１つの条件に関連付けられることもあることに留意されたい。この場合、「出力節」という語句の使用は通常、どの節でも議論の文脈で実行されたものを指す。出力節が場合により否定的帰結を引き起こすことが知られているとき、節およびその条件は、原因イベント条件と見なされる。

【0353】

原因イベント（またはイベント）：原因イベント条件が満たされ、その出力節が実行されているインスタンス。いくつかの実施形態では、すべての原因イベントは理論上、原因イベントのインスタンスを記録するために、原因イベントデータベース内にエントリを作成するべきである。データベース内のこのエントリの作成は典型的に、出力節内で行われ、または出力節によって直接開始される。データベース内の各原因イベントおよびそのイベントエントリは、それを識別する固有の原因ＩＤを有するべきである。新しい原因イベントに対する新しい原因ＩＤは、原因イベント条件の出力節で局所的に生成または獲得されるべきであり、したがって即座に参照して節内の他のアクションへ渡すことができる。各原因イベントおよびそのイベントエントリはまた、他の原因イベントが現在の原因イベントを引き起こしたことが知られているかどうかを指定するために使用することができる親原因ＩＤ項特性および／またはフィールドを有するべきである。他の原因イベントが現在のイベントを引き起こしたことが知られていない場合、親原因ＩＤ項フィールドはニル原因ＩＤ項に設定されるべきである。

【0354】

子原因イベント（子イベント）：１つまたはそれ以上の他の原因イベントによって全体的または部分的に引き起こされたことが知られている原因イベント。子イベントを引き起こした他のイベントは、その子イベントの親原因イベントであると見なされる。

【0355】

親原因イベント（親イベント）：別の原因イベントを全体的または部分的に発生させたことが知られている原因イベント。親イベントによって引き起こされた他の原因イベントは、子原因イベントであると見なされる。

【0356】

原因ＩＤ：原因イベントデータベース内の原因イベントおよびその関連付けられたエントリを固有に識別するデータ型またはデータ値。イベントデータベース内の各原因イベントおよび原因イベントエントリは概して、固有の原因ＩＤ値によって識別される。いくつかの実施形態では、原因ＩＤは、標準的な１２８ビットのＵＵＩＤとして実装される。したがって固有の原因ＩＤは、ランダム化された１２８ビットのＵＵＩＤ（すなわち、固有または擬似固有）として生成される。いくつかの実施形態では、原因ＩＤは、単調増加整数として実装される。

【0357】

ニル原因ＩＤ値を除いて、イベントデータベース内の原因ＩＤ値とイベントエントリとの間には、１対１の対応関係が存在する。原因ＩＤ値は、厳密に１つの原因イベントを表し、原因イベントは、厳密に１つの原因ＩＤ値によって表される。「原因イベント」は、原因イベント条件の単一の実行インスタンスを指すことに留意されたい。以前実行されたか否かにかかわらず、原因イベント条件が実行されるたびに、それはその新しいイベントインスタンスを識別するために新しい固有の原因ＩＤを有する新しい原因イベントを生成する。非ニル原因ＩＤ値が存在し、その関連付けられたイベントがデータベースに入る前に、関連付けられた原因ＩＤとして渡すことができる。この場合、関連付けられたイベントは常に、最終的にデータベースへ進むべきである。すなわち、非ニル原因ＩＤは、すでにイベントデータベースにありまたは将来のある時点でデータベースに入るイベントエントリを参照する。実際には、概略化された実施形態では、ニル原因ＩＤ値の他に原因ＩＤ値は存在しないことになり、ニル原因ＩＤ値は、すでにイベントデータベースにありまたは最終的にイベントデータベースに入る発生したイベントを参照しない。原因ＩＤは、原因イベントに対する汎用のユニバーサルポインタと考えることができる。

【0358】

原因ＩＤ項：因果パスウェイに付与または結合すべき１組の原因ＩＤおよび／または他の原因ＩＤ項。ここで原因ＩＤ項内の原因ＩＤの値は、その因果パスウェイの現在の状態を引き起こしたことが知られている原因イベントを記述する。原因ＩＤ項は概して、ソフトウェアシステムの必要および要件に応じて、２つの基本形式のうちの１つで実装される。第１の形式は、ニル原因ＩＤまたは非ニル原因ＩＤ値のいずれかに等しくなり得る単一の原因ＩＤ値である。第２の形式は、ゼロ、１つ、２つ、またはそれ以上の要素のコンテナであり、コンテナの各要素は、原因ＩＤまたは別の原因ＩＤ項とすることができ、この別の原因ＩＤ項は次いで、ネスト化されたコンテナとすることができる。コンテナ原因ＩＤ項をネスト化することで、ツリーが形成され、これは任意の深さとすることができる。ネスト化されたコンテナ原因ＩＤ項を含む各コンテナ原因ＩＤ項はまた、その原因ＩＤ項が直接含む要素の原因特性に関する意味情報を含むことができる。特に、「角括弧」または「山括弧」の意味に対する情報は、根本原因に関するさらなる分析および結論を自動で計算してユーザに表示することが可能になるように、コンテナによって記憶することができる。

【0359】

ニル原因ＩＤ：「既知の原因イベントがない」ことを意味するように予約された単一の固有の原因ＩＤ値。ＵＵＩＤを有する原因ＩＤを実装するいくつかの実施形態では、ニル原因ＩＤは、ニルＵＵＩＤによって表され、これはすべてゼロのＵＵＩＤ値「００００００００－００００－００００－００００－００００００００００００」である。原因ＩＤを単調増加整数として実装するいくつかの実施形態では、ニル原因ＩＤは値ゼロ「０」によって表される。ニル原因ＩＤ値は、原因イベントデータベース内の原因イベントまたは関連付けられたエントリに対応しない。その目的は、原因ＩＤが因果パスウェイの現在の状態に対する理由を記述することが予期されるが、特有の原因イベントがそのパスウェイを引き起こしたことが現在知られていないときに使用するための充填値を提供することである。

【0360】

ニル原因ＩＤ項：原因ＩＤ項が付与された因果パスウェイの現在の状態に対する「既知の原因がない」こと、または「既知の原因イベントがない」ことを表す原因ＩＤ項値。原因ＩＤ項が単一の原因ＩＤ値として実装される場合、ニル原因ＩＤ項は、基礎原因ＩＤがニル原因ＩＤ値に等しい原因ＩＤ項である。原因ＩＤ項がゼロ、１つ、２つ、またはそれ以上の要素を含むことができるコンテナとして実装される場合、ニル原因ＩＤ項は、コンテナがゼロの要素を含む（コンテナが空である）場合に等しく、コンテナが１つもしくはそれ以上の要素、またはすべての要素を含む場合は、ニル原因ＩＤ値に等しい。因果パスウェイに付与されたニル原因ＩＤ項は、その因果パスウェイの現在の状態に対する「既知の原因がない」ことを示す。

【0361】

親原因ＩＤ項：任意の親原因イベントの原因ＩＤ項。

【0362】

原因イベントデータベース（またはイベントデータベース）：原因イベントを記録するデータベース。すなわち、データベースは、原因イベント条件の出力節が実行されたときはいつでも記録する。各データベースエントリは、原因イベントを表す。イベントエントリは、否定的帰結に対する理由としてＵＩによって表示することができる。したがって、エントリテーブルに対するフィールドは概して、ユーザが障害モードを診断するために可能な最善の情報を反映することになる。一般的なフィールドとしては：障害モードを引き起こした基本条件の特定用途向けコードおよび／もしくはストリング説明；イベント発生した日時；どのハードウェアもしくはソフトウェア構成要素がエラーを生成したか、その時点で実行されていたハードウェアもしくはソフトウェアコマンドに関する情報、含まれるセンサ読取りの値、その時点にログインしたユーザなど、その特定のイベントに関連付けられた変数データパラメータ；ならびに／またはイベント生成および／もしくはイベントエントリ生成の時点で既知でありかつ使用可能な他の有用なデータおよびコンテキストが挙げられる。

【0363】

エントリテーブルはまた、各イベントの原因ＩＤを記録するためのフィールドを含むべきである。これは、各イベントに対して生成された固有のＩＤ値である。これは、その原因イベントインスタンスを固有に識別するために使用される。データベースは、通常はこの原因ＩＤ値を自動で生成せず、この原因ＩＤ値は概して、原因イベント条件の出力節から生成および調達されるべきであり、典型的にデータベース表に追加されているイベントエントリに関する他の情報のすべてを伴うことに留意されたい。エントリテーブルはまた、各イベントの親原因ＩＤ項を記録するためのフィールドを含むべきである。他のイベントが現在のイベントを（全体的または部分的に）引き起こしたことが知られている場合、それらの他のイベントは、現在のイベントの親原因イベントと見なされ、現在のイベントは、それらの親の子原因イベントであると見なされる。この場合、親の原因ＩＤ項は次いで理論上、可能な場合、子イベントに対するデータベースエントリに記録されるべきである。他のイベントが現在のイベントを引き起こしたことが知られていない場合、またはソフトウェア内で親原因ＩＤ項を子イベントに通信することができない場合、データベース内の子イベントに対する親原因ＩＤ項が、ニル原因ＩＤ項に設定されるべきである。

【0364】

データベースは、原因イベント条件節を含む任意のソフトウェアサブシステムから直接または間接的に書込み可能であるべきである。データベースは、否定的帰結をユーザに表示することができる任意のソフトウェアＵＩから可読であるべきである。いくつかの実施形態では、否定的帰結を表示することができる関連付けられたＵＩが、関心原因イベントを発見および報告するために必要とされるデータベースにアクセスして読み取ることが可能である限り、実際に２つ以上の物理データベースが２つ以上のソフトウェアまたはハードウェアモジュールに位置することができることに留意されたい。すなわち、否定的帰結をユーザに表示する任意のソフトウェアＵＩは概して、受信した任意の原因ＩＤに対する原因イベントを参照することが可能であるべきである。

【0365】

障害モード：原因イベント条件およびもたらされる否定的帰結の組合せ。ソフトウェアの一般特性は、原因イベント条件と否定的帰結との間の１対１の対応関係はめったに存在しないことである。すなわち、単一の原因イベント条件は、２つ以上のタイプの否定的帰結を引き起こす可能性があることが多く、単一のタイプの否定的帰結は、２つ以上の原因イベント条件によって引き起こされる可能性があることが多い。したがって、異なる原因イベント条件は、異なるタイプの否定的帰結をもたらすことが多く、それによって無数の可能な障害モードが作られる。適度な複雑さの何らかのソフトウェアに対する障害モードの全リストでも、計算不能かつ列挙不能であることが多い。

【0366】

いくつかの障害モードは、満たされている２つまたはそれ以上の原因イベント条件の組合せに起因する可能性があることに留意されたい。同様に、異なる組合せの原因イベント条件も異なる否定的帰結を引き起こす可能性がある。概して、否定的帰結を生じさせる原因イベント条件のこれらの可能な組合せの各々もまた、単一の障害モードとして計数することができる。このとき異なる障害モードは、原因イベント条件のサブセットの重複を含むことがあり、それによりすべての可能な障害モードを列挙しようとするとき、さらなる分析の難題が生じることに留意されたい。

【0367】

選択実施形態の実装構成
いくつかの実施形態の例示的な構成：必要な場合のみ原因ＩＤ項を追加する。コード内のすべてのパスウェイが、因果パスウェイであるとは限らない。すなわち、すべてのデータおよび実行パスウェイが、否定的帰結を招く可能性があるとは限らない。したがって、すべてのデータまたはすべての実行パスウェイに、原因ＩＤ項を関連付ける必要があるとも限らない。これらの実施形態では、否定的帰結を招いたデータまたは実行パスウェイのみに、原因ＩＤ項が関連付けられるべきである。すなわち、因果パスウェイであることが知られているパスウェイのみが、原因報告のために修正されるべきである。典型的に、因果パスウェイは、コード内のパスウェイのうちのほんの少数である。必要とされない場合に原因ＩＤ項を追加しないことで、システムの性能、信頼性、および保守性を助ける。

【0368】

いくつかの実施形態では、実装は、因果関係を示す必要がない場合に因果関係を示すように従来の演算を修正しない。因果関係を示すように演算を修正するとき、実装では、それらの出力値が否定的帰結を表す可能性がない場合、因果関係の処理のための演算ですべての出力値を結び付ける必要はない。たとえば、ゼロの出力が乗算の結果のときの原因要因でないが、ＮａＮ値のときの原因要因である場合、実装者は、ＮａＮ値のみを結び付けることを考えることができる。演算に対する出力値が特有のソフトウェアシステムで失敗を引き起こす可能性がまったくない（すなわち、原因報告のためにまったく必要とされない）が、基礎値はなお比較によって否定的帰結を表すことができる（たとえば、「整数値３、５、および６が失敗を引き起こす可能性がある」）場合、いくつかの実施形態は、常に「＜ｐｑ＞」の原因を出力し、同じことを行う原因比較演算子を提供して、障害モードの報告を取り扱うように、演算を修正することができる。

【0369】

いくつかの実施形態の例示的な構成：専用のクラス型を有する原因ＩＤを実装する。原因ＩＤの基礎的な実装にかかわらず、いくつかの実施形態は、専用のクラスを使用して、「ｃｌａｓｓ ＣａｕｓａｌＩｄ｛．．．ＵＵＩＤ ｍ＿Ｕｕｉｄ；．．．｝」などの原因ＩＤを表す。たとえば、原因ＩＤは、標準的なＵＵＩＤ（ＧＵＩＤとも呼ばれる）型によって実装することができる。しかし、ＣａｕｓａｌＩｄの厳密にどのパラメータが：ニル原因ＩＤ値（すなわち、ニルＵＵＩＤ）、または生成された原因イベントを参照する原因ＩＤ値（ＵＵＩＤ）を指定することだけが安全であることを意味するかを開発者に示すために、ＣａｕｓａｌＩｄクラスでそのＵＵＩＤをラップした方がよい可能性がある（専用のクラスで実装をラップすることはまた、基礎的実装がいつか変化する場合に一般に推奨される慣行である）。

【0370】

いくつかの実施形態の例示的な構成：汎用体および演算子の多重定義を活用して、原因ｉｄ項を自動で取り扱う：それに対応するソフトウェア言語の場合、汎用体（テンプレートとも呼ばれる）および／または演算子の多重定義を活用して、式をまたいだ原因ＩＤ項の付与および伝搬を自動で取り扱うことで、全体的な実装を大幅に簡略化することができる。たとえば、原因ＩＤ変数を任意のデータ型に結合する汎用Ｃ＋＋クラス「Ｃａｕｓａｌ」を作成することができる。

【0371】

この例では、簡単なＣ＋＋ブール成功フラグを原因ＩＤ項も含む原因型に変換するために、ブール変数の型をｂｏｏｌからＣａｕｓａｌ＜ｂｏｏｌ＞に変換することができる。次いで、Ｃａｕｓａｌ＜ｂｏｏｌ＞変数の基礎ｂｏｏｌ値を偽に設定して失敗を示し、Ｃａｕｓａｌ＜ｂｏｏｌ＞変数の原因ＩＤ項を、ちょうどポスティングされた原因イベントの原因ＩＤに等しくなるように設定することができる。Ｃａｕｓａｌクラスは、可能な場合、変数の式を基礎データ型との間で自動で変換することによって、ラップされたクラス挙動を可能な限り式中の基礎値型のようにするために、自動タイプの変換演算子を含むことができる。演算子の多重定義は、必要とされるとき、組込み演算子が因果関係を示すように提供することができる。すなわち、これらは、原因入力を受け付け、正しい原因ＩＤ項を有する原因出力を返すように修正される。

【0372】

臨床アナライザにおいて流体検査を実装するためのルーチンを考慮されたい。ＧｅｔＦｌｕｉｄＬｅｖｅｌＳｔａｔｕｓ（）関数が、Ｃａｕｓａｌ＜ｂｏｏｌ＞成功結果を返すことができる。この結果は、成功戻り値を「ｆａｌｓｅ」または「ｔｒｕｅ」に等しくした原因イベントの原因ＩＤ項を含み、これはそれらのイベントが、結果変数の式の割当て（すなわち、因果パスウェイ）に原因演算子をどのように送り込んだかによって、自動で判定される。この結果は、平易なｂｏｏｌ値の場合と同様に、「ｉｆ」条件で直接使用することができることにも留意されたい。これは、基礎項目型への暗示的キャスト変換演算子がＣａｕｓａｌクラスに提供され、適当または可能な場合、結果が簡単なブールとして作用することが可能になったからである。

【0373】

この実装のため、多くのタイプのデータ変数への原因イベント報告の追加を容易に行うことができる。たとえば「ｂｏｏｌ」から「Ｃａｕｓａｌ＜ｂｏｏｌ＞」へ、または「ＳｔａｔｅＥｎｕｍ」から「Ｃａｕｓａｌ＜ＳｔａｔｅＥｎｕｍ＞」へ、タイプを変換することによって、仕事およびコードの複雑さの大部分が簡単に解消される。原因ＩＤの関連付け、原因ＩＤの記憶、ラップされたデータ型との間のアップキャストおよびダウンキャスト、ならびに任意の構成および複雑さの式をまたいで原因ＩＤを正確に伝搬するための演算子の多重定義はすべて、Ｃａｕｓａｌ＜＞クラス内の標的変数をラップすることによって、通常自動で処理される。加えて、原因ＩＤ項が単一の原因ＩＤ値として実装されるとき、挙動は容易に実時間にすることができ、したがって実時間コードで安全に使用することができる。

【0374】

いくつかの実施形態の例示的な構成：２つの入力例。すでに論じた２つの入力ブール演算を考慮されたい。関数ＩｓＳｙｓｔｅｍＡｖａｉｌａｂｌｅ（）は、２つの入力条件（ｂＶａｌｕｅ１およびｂＶａｌｕｅ２）に対するＡＮＤ演算子「＆＆」の結果が真であった場合、真を返す。関数ＴｈｒｏｗＥｒｒｏｒＩｆＵｎａｖａｉｌａｂｌｅ（）は、通常のシステム演算中に呼び出すことができ、ＴｈｒｏｗＥｒｒｏｒＩｆＡｖａｉｌａｂｌｅ（）は、診断モード中に呼び出すことができる。各々は、ＩｓＳｙｓｔｅｍＡｖａｉｌａｂｌｅ（）の出力を異なる形で使用することができ、システム状態がそれぞれ使用不能または使用可能である場合、エラーをスローする。したがって、これらのエラーのうちの１つがスローされたとき、原因出力が使用可能である場合、エラーは、ＩｓＳｙｓｔｅｍＡｖａｉｌａｂｌｅ（）の何らかの原因ＩＤ出力への参照を含むべきである。

【0375】

例示的な実施形態の目標は、ソース原因理由まで遡って２つの可能な例外をリンクさせることである。この例では、例外クラスは、捕捉されると中間原因イベントとしてポスティングされ、親原因ＩＤ項を設定することが可能になる。ここで、変数ｂＶａｌｕｅ１およびｂＶａｌｕｅ２は、因果パスウェイの最初の部分である。汎用体または演算子の多重定義が使用されず、一般的な原因演算を取り扱うために演算特有の効用関数が作成されない場合、原因報告を式ごとに手動で追加するためのコードの修正は、本明細書全体にわたって論じる適当な因果表に従って関連する原因入力の各々から原因ＩＤ項を得ることによって行うことができる。したがって、ＴｈｒｏｗＥｒｒｏｒＩｆＵｎａｖａｉｌａｂｌｅ（）またはＴｈｒｏｗＥｒｒｏｒＩｆＡｖａｉｌａｂｌｅ（）が呼び出されたとき、ｂＶａｌｕｅ１および／またはｂＶａｌｕｅ２の適当な原因ＩＤ項を報告する。

【0376】

ＩｓＳｙｓｔｅｍＡｖａｉｌａｂｌｅ（）の原因実装における簡単な式ｒｅｔｕｒｎ（ｂＶａｌｕｅ１ ＆＆ ｂＶａｌｕｅ２）は次いで、複雑な２重にネスト化されたｉｆ－ｅｌｓｅ構造を使用して、ブールＡＮＤ演算に対して構築された因果表に応じて、どの入力原因ＩＤを出力値へ伝搬するべきかを判定することができる。これは、これらのネスト化されたｉｆ－ｅｌｓｅ構造をソフトウェア内のすべての原因式に追加することが必要になり得るため、望ましい実装ではない可能性がある。これにより、コードの複雑さが増大し、信頼性および保守性が低減し、したがって開発にコストがかかりすぎる可能性がある。加えて、ｂＶａｌｕｅ１、ｂＶａｌｕｅ２、およびＩｓＳｙｓｔｅｍＡｖａｉｌａｂｌｅ（）への２つの呼出しから返された値とともに、「付与」された原因ＩＤを記憶するために、４つの明示変数を追加しなければならない。これもまた、どの原因ＩＤ変数がどの標的変数に関連付けられているかを開発者が知っている必要があるという複雑さをもたらすため、理想的ではない。

【0377】

いくつかの実施形態で使用される次のコードは、Ｃａｕｓａｌクラスを使用して、原因値をラップする。Ｃａｕｓａｌクラスは、一般的な原因演算に対する演算子の多重定義を有する汎用「ラッパ」クラスである。このクラスは、原因ＩＤ項値を標的データ値に結合し、それにより原因ＩＤ項を単一のＣａｕｓａｌＩｄ値として実装し、ブール式および他の組込み演算子を自動で取り扱うために演算子の多重定義を提供し、ＴｈｒｏｗＥｒｒｏｒＩｆＵｎａｖａｉｌａｂｌｅ（）およびＴｈｒｏｗＥｒｒｏｒＩｆＵｎａｖａｉｌａｂｌｅ（）内の「ｉｆ」条件など、原因挙動を必要としない式においてＣａｕｓａｌ＜＞値をその基礎的なラップ型のように自動で挙動させるために、自動タイプの変換演算子を提供する。
//システムが使用可能であるかどうか
//を判定する要因として含まれる２つの値。
Causal<bool> bValue1 = ...;
Causal<bool> bValue2 = ...;


//システムが使用可能であるかどうかを返す。
Causal<bool> IsSystemAvailable()
{
return (bValue1 && bValue2);
}


//システムが使用不能である場合、例外をスローする。
//（たとえば、患者検査を実行する前に確認する。）
Void ThrowErrorIfUnavailable()
{
Causal<bool> bSystemAvailable = IsSystemAvailable();

if( ! bSystemAvailable )
{
Exception AvailabilityError(
"System is unexpectedly unavailable.");

AvailabilityError.SetParentCausalId(
bSystemAvailable.GetCausalId() );

throw AvailabilityError;
}
}


//システムが使用可能である場合、例外をスローする。
//（たとえば、診断ルーチンを実行する前に確認する。）
void ThrowErrorIfAvailable()
{
Causal<bool> bSystemAvailable = IsSystemAvailable();

if( bSystemAvailable )
{
Exception UnavailabilityError(
"System is unexpectedly available.");

UnavailabilityError.SetParentCausalId(
bSystemAvailable.GetCausalId() );

throw UnavailabilityError;
}
}

【0378】

したがって、原因ラッパクラスを利用して原因挙動を自動で取り扱う方が、既存の非原因関数に明示的原因コードを追加するより、簡単に実装および維持することができる。特に、関心コア原因式を含む関数ＩｓＳｙｓｔｅｍＡｖａｉｌａｂｌｅ（）は、ほとんど修正を必要としない。Ｃ＋＋ブールＡＮＤ演算子「＆＆」に対するＣａｕｓａｌクラスの演算子多重定義は、その２つの入力から正しい原因ＩＤを選択し、次に関数から返される一時変数にそれを割り当てることを自動で処理する。また、自動タイプの変換により、ＴｈｒｏｗＥｒｒｏｒＩｆＵｎａｖａｉｌａｂｌｅ（）およびＴｈｒｏｗＥｒｒｏｒＩｆＡｖａｉｌａｂｌｅ（）内の「ｉｆ」条件の現在のＣａｕｓａｌ＜ｂｏｏｌ＞ｂＳｙｓｔｅｍＡｖａｉｌａｂｌｅ変数の値の確認が簡単になる。基礎的な真／偽の値を抽出するために、変化は必要とされない。

【0379】

いくつかの実施形態の例示的な構成：５つの入力の例。すでに論じた原因報告のない従来の５つの入力の演算を考慮されたい。汎用体または演算子の多重定義が使用されず、一般的な原因演算を取り扱うために効用関数が作成されない場合、原因報告を式ごとに手動で追加するためのコードの修正を行うことができる。しかし、ＩｓＳｙｓｔｅｍＡｖａｉｌａｂｌｅ（）内の原因式に対して多くの中間値を明示的に計算する必要があり、返すべき正しい原因ＩＤを判定するために、多くのネスト化されたｉｆ－ｅｌｓｅブロックが必要とされる。よりよい実装のために、いくつかの実施形態によれば、関数は、一般的な原因演算に対する演算子多重定義を有する汎用「ラッパ」クラスであるＣａｕｓａｌクラスを使用して原因イベントの報告を行うように修正することができる。
//システムが使用可能であるかどうかを判定する要因として含まれる５つの値。
Causal<bool> bValue1 = ...;
Causal<bool> bValue2 = ...;

enum StateEnum
{
Initializing,
Running,
Stopped,
Resetting,
Diagnostics
};

Causal<StateEnum> enState_SubSysA = ...;
Causal<StateEnum> enState_SubSysB = ...;

Causal<float> fSensorReading = ...;


////////////////////////////////////////////////////////////////
//
//システムが使用可能であるかどうかを返す。
//
Causal<bool> IsSystemAvailable()
{
return
(bValue1 && bValue2) ||
(((enState_SubSysA == StateEnum::Running) &&
(enState_SubSysB != StateEnum::Diagnostics)) ||
((fSensorReading <= 5000.0) && (fSensorReading > 100.0)));
}


//．．．同じ修正済み「ThrowErrorIf．．．（）」関数を
//上記から含む．．．

【0380】

この実施形態では、Ｃａｕｓａｌクラスは、多数のネスト化された原因入力値の確認を追加するという実際的に扱いにくい問題を受け、含まれる演算が因果関係を示すようにし、代わりに実行可能かつ容易にする。その複雑な式を有する関数ＩｓＳｙｓｔｅｍＡｖａｉｌａｂｌｅ（）は、ほとんど修正を必要としないことに留意されたい。特に、その式の部分はここで、修正をまったく必要としない。この実施形態で従来の関数に適用される唯一の変化は、Ｃａｕｓａｌクラスでラップすることによって、その入力および戻り値のタイプを修正することである。

【0381】

いくつかの実施形態の例示的な構成：原因イベント条件例。例示的なセンサを使用して原因イベントの報告を行うように修正された臨床アナライザなどの電気機械システムに原因イベント条件を含むコードの次の例を考慮されたい。
class Sensor
{
public:

Causal<bool> CheckSensor()
{
int l_nSensorReading = GetReading();

Causal<bool> l_bSuccess = true;

if( l_SensorReading > SENSOR_READING_MAX ) // [1]
{
//限界外のセンサを返す。
CausalEvent l_CausalEvent(
"Sensor reading of " + l_SensorReading
+ " is above maximum limit of " + l_nSensorReading
+ "." );

PostCausalEventToDatabase( l_CausalEvent );

l_bSuccess = Causal<bool>(
false,
l_CausalEvent.GetCausalId() );
}

if( l_SensorReading < SENSOR_READING_MIN_WARNING ) // [2]
{
//センサはまだ限界内にあると見なされるが、
//ディスクへ警告をログ記録する。
//
Log( “Sensor below expected minimum” );
}

return l_bSuccess;
}
};


void VerifySensor()
{
Sensor l_Sensor;

Causal<bool> l_bSensorOk = l_Sensor.CheckSensor();

if( l_bSensorOk ) // [3]
{
DisplaySuccess( “Sensor OK.” );
}
else
{
DisplayFailure(
“Sensor failed.”, l_bSensorOk.GetCausalId() ); // [4]
}
}


void VerifyAllSensors
{
Sensor l_Sensor1;
Sensor l_Sensor2;

Causal<bool> l_bSensorsOk =
l_Sensor1.CheckSensor() && l_Sensor2.CheckSensor();

if( l_bSensorsOk ) // [5]
{
DisplaySuccess( “All sensors OK.” );
}
else
{
DisplayFailure(
“One or more sensors failed.”,
l_bSensorsOk.GetCausalId() ); // [6]
}
}

【0382】

クラスＣａｕｓａｌＥｖｅｎｔおよび関数ＰｏｓｔＣａｕｓａｌＥｖｅｎｔＴｏＤａｔａｂａｓｅ（）が、原因イベントを作成およびポスティングするための汎用ライブラリユーティリティとして追加される。ＣａｕｓａｌＥｖｅｎｔクラスは、インスタンスが構築されたときはいつでも、それ自体に対する固有のＣａｕｓａｌＩｄ（ランダム化された１２８ビットのＵＵＩＤ）を自動で生成する。この原因ＩＤは、ＣａｕｓａｌＥｖｅｎｔ：：ＧｅｔＣａｕｓａｌＩｄ（）によって取り出すことができる。ＤｉｓｐｌａｙＦａｉｌｕｒｅ（）は、原因ＩＤを受け付け、データベースからの関連付けられた原因イベントを参照および表示するように修正されている。

【0383】

［１］のすぐ上のｌ＿ｂＳｕｃｃｅｓｓへの「ｔｒｕｅ」の割当ては、ニル原因ＩＤ項も同様に割り当てられることを示唆する。これはまた、自動タイプの変換を活用して、関連付けられた原因ＩＤ項が必要とされるまで可能な限り、ｌ＿ｂＳｕｃｃｅｓｓを平易なｂｏｏｌのように挙動させる。これは、いくつかの実施形態では、様々なコードに原因イベントの報告を追加することが典型的にどれだけ容易であるかを実証する。

【0384】

いくつかの実施形態の例示的な構成：演算子多重定義に対する代替。演算子の多重定義が使用可能でない場合、または修正すべき演算が演算子によって実装されない場合、いくつかの実施形態では、ＣａｕｓａｌＡｎｄ（）、ＣａｕｓａｌＯｒ（）、ＣａｕｓａｌＮｏｔ（）、ＣａｕｓａｌＥｑｕａｌｓ（）などの同等のことを行うための専用の関数を提供することで、この技法をなお完全に実行可能にすることができる。ここに、原因演算子のような関数を使用するために書き換えられた２入力および５入力の例に対するＩｓＳｙｓｔｅｍＡｖａｉｌａｂｌｅ（）関数を示す。この場合、汎用Ｃａｕｓａｌクラスは、原因ＩＤ項値への結合を提供するのみであり、演算子多重定義を含まない。
//システムが使用可能であるかどうかを返す。（２入力の例）
Causal<bool> IsSystemAvailable()
{
return CausalAnd(bValue1, bValue2);
}


//システムが使用可能であるかどうかを返す。（５入力の例）
Causal<bool> IsSystemAvailable()
{
return
CausalOr(
CausalAnd(bValue1, bValue2),
CausalOr(
CausalAnd(
CausalEqual(
enState_SubSysA,
StateEnum::Running),
CausalNotEqual(
enState_SubSysB,
StateEnum::Diagnostics)),
CausalAnd(
CausalLessThanEqual(fSensorReading, 5000.0),
CausalGreaterThan(fSensorReading, 100.0))));
}

【0385】

演算子多重定義を使用するときほど簡単でも低衝撃でもないが、これは、出力原因ＩＤ項を判定するためにｉｆ－ｅｌｓｅ構造および中間演算を手動で書き込むのに非常に好ましい可能性がある。この例は、演算子の多重定義が使用可能でない場合でも、原因イベント報告技法がなお実行可能であることを実証する。典型的に、何らかの所与のソフトウェアアプリケーション内のほんの少数の式が原因報告を所望し、したがって上記のような構造はそれほど一般的でないことになることに留意されたい。否定的帰結を頻繁に報告することができるソフトウェアシステムの場合、ソフトウェアのすべてのユーザの間で節約される集合的な問題解決時間を考えると、上記の式を書き込んで維持するための努力は許容可能である。

【0386】

いくつかの実施形態の例示的な構成：複数の原因を表す：単一の原因ＩＤと複数の原因ＩＤ。物理的な非ソフトウェアの帰結およびソフトウェアの帰結の両方における原因および結果の一般特性は、何らかの所与の帰結に対して２つ以上の原因が存在し得ることである。通常、何らかの肯定的帰結は、ほぼ無限の数の原因を有する。肯定的帰結が発生するためには、非常に多くの事柄が「うまくいく」必要がある。肯定的帰結のそれらの原因のいずれか１つ、または場合によりそれらの原因の特有の集合サブセットを失うと、否定的帰結が発生する。したがって、否定的帰結が発生するには、典型的に、１つの原因または一握りの原因のみが存在する。典型的に、否定的帰結が発生するとき、１つまたはわずかな数の事柄のみが「うまくいかない」。ほとんどの場合、実際には１つの根本原因のみが存在する。

【0387】

原因ＩＤ項が単一の原因ＩＤ値として実装されるとき、本発明は、各々の否定的帰結の発生に対して一度に多くとも１つの単一の原因イベントを報告する。ここではこれを、「単一原因の報告」と呼ぶ。所望される場合、いくつかの実施形態によって複数の原因を表して報告することができる。ここではこれを、「複数原因の報告」と呼ぶ。１つの因果パスウェイに一度に単一の原因ＩＤを付与するのではなく、１つの帰結に対して複数の原因を表すために、原因ＩＤ項は、２つ以上の原因ＩＤを集合セットまたはポインタとしてＩＤのセットに付与することができる。任意の所与の時点でパスウェイに付与された現在のセットの原因ＩＤは、そのパスウェイの現在のデータまたは実行状態に対する原因の現在の集合セットを表す。典型的に、原因ＩＤのこのセットは、従来の「セット」コンテナの意味によって実装されることになり、パスウェイに対する現在のセットの原因を表す原因ＩＤが、次の特性を有するセット型コンテナに含まれる：複製ＩＤが無効にされ（複製ＩＤはそっと折り畳まれて単にＩＤの１つのコピーになる）、空のセットがニル原因ＩＤの同等になる。

【0388】

原因ＩＤ項が複数の原因ＩＤまたは原因ＩＤ項値のコンテナとして実装されるとき、因果表は、次のように使用される。「ｐ」の値は、入力オペランド「Ｐ」に付与された原因ＩＤ項を表し、「ｑ」の値は、入力オペランド「Ｑ」に付与された原因ＩＤ項を表す。このとき「ｐ」および「ｑ」の出力ケースはどちらも、指定された原因ＩＤ項（ｐまたはｑ）をその入力オペランドから出力値へ伝搬するだけである。「＜ｐｑ＞」および「［ｐｑ］」の出力ケースはどちらも、「ｐ」および「ｑ」の入力セット原因ＩＤ項を併合して、その結果得られる併合された項を出力値に付与する。

【0389】

ＵＩが否定的帰結に対する原因を表示するとき、否定的帰結に関連付けられた原因ＩＤ項が原因ＩＤ値のセットまたはツリーとして実装されており、かつ空でない場合、ＵＩは、原因ＩＤ項内の各原因ＩＤに対するイベントを参照し、各イベントの根イベントを発見し（再帰的な親の参照）、複製根イベントを非複製根イベントの最終リストに折り畳み、次いで各根イベントを否定的帰結の原因として表示する。否定的帰結に関連付けられた原因ＩＤ項が代わりに空である場合、ニル原因ＩＤの場合と同様に、追加のものは表示されない。いくつかの実施形態における１つの実装の選択肢は、結果として付与される原因ＩＤおよび／または原因ＩＤセットで、＜ｐｑ＞の出力ケースと［ｐｑ］の出力ケースとの意味の違いを維持し、特定のサブセットのすべての表示された原因（［ｐｑ］関係によって伝搬されたもの）および／または特定のサブセットのいくつかの表示された原因のみ（＜ｐｑ＞の関係によって伝搬されたもの）を修復する必要があるかどうかに関して、より多くの情報をユーザに提供することである。

【0390】

いくつかの実施形態は、原因ＩＤの各セットをツリーで記憶し、入力を併合する＜ｐｑ＞および［ｐｑ］出力ケースは、帰結を引き起こすために必要な条件の階層構造を文字通り反映するツリーに組み立てられ、複製ＩＤは折り畳まれない。どの実施形態を実装するかの決定に影響し得る潜在的な性能の影響には、複数の原因ＩＤを付与するとき、多くのソフトウェアライブラリで見られるように、原因ＩＤセットコンテナに対するメモリ管理がヒープベースである場合の通常の実時間およびメモリの断片化の考慮、および原因報告のために修正された演算に追加された追加のリスト処理による概略的なタイミングの考慮が含まれる。

【0391】

複数の原因ＩＤの伝搬に関連する潜在的な性能の影響のため、いくつかの実施形態は、単一の原因ＩＤを因果パスウェイに簡単に付与する。単一の原因ＩＤの実装の追加の利点は、実時間で実装するのが非常に容易であることである。単一の原因ＩＤを付与することは、大部分のケースでユーザにとって十分すぎる結果になる。前述のように、ほとんどの否定的帰結は、単一の条件によってのみ引き起こされ、したがって単一の原因ＩＤを報告すれば、ほとんどの問題の原因を報告するのに十分である。否定的帰結が２つ以上の原因イベントによって引き起こされる場合、それでもなお通常、原因の１つのみを表示するのに十分である。これは、ユーザがその１つの原因を修復し、次いで再び演算を試行することができるからである。演算が１つまたはそれ以上の他の原因によってさらに失敗した場合、演算の再試行時にそれらの他の原因のうちの１つが表示され、次いでユーザはその原因を修復し、再び試行することができる。これは、すべての原因が修復されるまで繰り返される。

【0392】

実施形態を使用して、否定的帰結だけでなく、肯定的帰結に対する原因も報告することが可能であることにも留意されたい。しかし、肯定的帰結の原因の報告がエンドユーザにとって実際的に有用になるように、実装は、公称では、単一原因の報告（単一イベントの報告）ではなく、複数原因の報告（複数イベントの報告）を行うべきである。これは、所与の肯定的帰結が典型的に非常に多くの入力原因の結果であるという上記の一般的な原因および結果の観察のためである。本発明によって複数原因の報告を使用して肯定的帰結の報告が実現される場合、膨大な数の原因入力イベントが各肯定的帰結に対して報告される可能性が高いことになる。このため、ユーザにとって関心のある可能性が最も高い原因イベントを強調するために、特別な分類および原因イベントツリー横断フィルタを開発することが必要になる。これらのフィルタが有用になるように、「肯定的帰結におけるユーザにとっての関心イベント」もまた、各タイプの肯定的帰結に対して定義する必要があり、かつ／または帰結の発生ごとに実行時間で構成可能とする必要がある。

【0393】

これは、いくつかの実施形態が、肯定的帰結の原因を報告するより、否定的帰結の原因を報告するのに有用になり得ることを強調する。これに対する理由の一部は、肯定的帰結に対する原因および結果の性質が、否定的帰結の場合よりはるかに複雑であり、正常使用の場合はそれほど関係しないことである。

【0394】

いくつかの実施形態の例示的な構成：中間原因イベント条件に対する原因イベントエントリを生成しない。コード内の原因イベント条件は、根本原因条件または中間条件として分類することができる。いくつかの実施形態は、根本原因条件内の原因イベントのみをポスティングし、中間条件内の原因イベントのポスティングを避ける。中間条件内の原因イベントをポスティングすることは、少なくとも部分的に冗長になることが多く、中間イベントの条件節が前の根本原因結果の持続している結果に対して常に再実行される場合、膨大な数の無用の情報またはデータベースエントリをもたらす可能性がある。

【0395】

１つまたはそれ以上の中間条件が原因イベントをポスティングすることが望ましい少なくとも２つの顕著な状況がある。第１に、ソフトウェアによってそのように実際の根本原因条件を識別することができないとき、フィードバックをまったく提供しないのではなく、最適でない場合でも、少なくともある種の原因フィードバックをユーザに対して提供するために、中間原因イベントをポスティングすることが望ましい。この種のフィードバックは、実際の根本原因イベントまで遡る部分的な追跡として働き、問題を引き起こした特有の根本条件を指し示していない場合でも、ユーザが調査すべき可能な根本原因条件のリストを狭める傾向がある。第２に、上流の根本原因条件もイベントをポスティングしているときでも、全体的な障害モードの内容、状態、および中間結果に関してより多くの情報をユーザに提供するために、中間条件は原因イベント条件を故意にポスティングすることが望ましいことがある。これらの場合、中間イベントは理論上、場合により根本原因イベントを表示することを優先して否定的帰結に対する中間イベントの表示を抑制するために、または場合により発生したときの原因および結果の階層を表示するために、その親原因ＩＤ項を、根本原因条件から渡された原因ＩＤ項（使用可能な場合）に設定するべきである。

【0396】

いくつかの実施形態の例示的な構成：原因ｉｄまたは原因ＩＤ項をエラーコードまたは他のタイプの成功ステータスとして処理しない。原因ＩＤおよび原因ＩＤ項は、たとえばエラーがあるか否か、またはエラーをもたらす可能性があるか否かを表す何らかの他の値に関するメタデータを含めて、何らかの他の値または状態に関するメタデータである。原因ＩＤおよび原因ＩＤ項自体は、可能なエラーまたは失敗状態を表さず、したがって何らかの種類のエラー／非エラーステータス自体を表すために使用されるべきでない。代わりに、実施形態は、原因ＩＤが付与された他の状態またはステータスの値に依拠して、何らかの所与の因果パスウェイの状態が最終的に肯定的および／または否定的帰結をもたらすかどうかを示す。

【0397】

これは、因果パスウェイの状態が場合により、肯定および否定的帰結の両方の結果を同時に表しまたは引き起こし得ることから有用である。原因ＩＤを直接正または負のステータス値として誤って使用すると、その副次的問題に対する解決策を破り、したがって正確な原因イベント報告を提供するという全体的な問題に対する解決策を破る。

【0398】

ニル原因ＩＤ項（およびニル原因ＩＤ）は、根本原因を表示するときに特有の意味を有し、ニル原因ＩＤ項値は、失敗状態値に有効に付与され、その失敗状態に対する「既知の理由がない」ことを示す。たとえば非ニルＩＤ項が失敗を表し、ニルＩＤ項が成功を表すようにすることによって（原因ＩＤが別個であるが付与された成功または失敗値に対する理由を記述する代わりに）、原因ＩＤ項変数が成功または失敗値を直接示すように不適切に使用された場合、「この失敗の既知の原因がない」という原因ケースを正確に表すことができない。これは、この場合、「既知の理由がない」原因をその失敗状態に付与する方法がないため、意味的に多重定義された原因ＩＤはここで、ニル（「この状態に対する既知の理由がない」ことを表す）および非ニル（何らかの否定的帰結が状態をもたらすことを表す）の両方が同時に存在することはできないことからである。

【0399】

類似の問題はまた、ニル原因ＩＤ項が代わりに失敗状態を表すために使用される仮説的実装にも当てはまる。この特定の実装は、非ニルＩＤ項もまた失敗に対するソース原因イベントを表すために必要とされ、原因ＩＤ項はニル（失敗状態）および非ニル（失敗理由）に同時になることができないため、解が失敗に対する理由を表す基本能力を簡単に破る。したがって、いくつかの実施形態では、原因ＩＤ項を負の状態自体として処理することで、間違った根本原因の頻繁な報告、または根本原因の報告の頻繁な失敗が生じ、これらはどちらも避けるべきである。代わりに、コードは、最小でも「成功／失敗」ｂｏｏｌまたはエラーコードｅｎｕｍなどの何らかの他の成功／失敗ステータス値を返し、次いで理論上、場合により否定的帰結を引き起こすことが知られている場合、その値に別個の原因ＩＤ値を付与することによって、その値を原因値にするように書かれるべきである。

【0400】

失敗が発生したか否かを示すために原因ＩＤ項を返すのではなく、例示的なＭｏｖｅＭｏｔｏｒ（）関数は、ｂｏｏｌを返して成功または失敗を示し、Ｃａｕｓａｌ＜＞ラッパを介してそこに原因ＩＤ項を付与して、真であるかそれとも偽であるかにかかわらず、返された特定の値に対する理由を示す。したがって、結果に付与された原因ＩＤ項は、その結果に関するメタデータであり、これはほとんどの実施形態にとって正しい実装である。

【0401】

いくつかの実施形態の他の例示的な構成。実施形態は概して、原因演算に対して、可能な各入力値がその演算の可能な各出力値に対する原因または非原因であることが知られているかどうかを定義し、次いで演算の任意の各実行にその入力値を分析させて、入力値のどの組合せが発見されたかに基づいて、伝搬すべき原因メタデータを選択する。ソフトウェアシステム内のすべての可能な原因および結果の判定を必要とする代わりに、実施形態は、ソフトウェアシステムの既存の任意の構造を活用して、任意の部分原因および部分結果を、それらが発生するときにシステム内で引き起こす特定値の変化にリンクさせることを介して、それらを互いにリンクさせる。これは次いで、ソフトウェアシステムの任意の部分構造、ならびにシステム内の現在の値および状態に対するそれらの結果が、何がその特定のシステムの可能な原因および結果のすべてを最終的に定義するか、ならびにどの特定の原因が任意の所与の時点で有効であるかであるため、全体的な当該ソフトウェアシステム内の何らかの結果（否定的帰結）に対する正しい究極原因の報告を自動でもたらすことができる。

【0402】

これは：ソフトウェア内の原因イベント条件をユーザに対する任意の否定的帰結の任意のソースとして明示的および暗示的に識別すること；原因イベント条件が発生するたびに、データベースイベントエントリおよびそのイベントエントリを指し示す固有の原因ＩＤ値を生成すること；それらの原因ＩＤ値をメタデータとして、その原因条件の結果として発生する任意の活動中のデータ値パスウェイおよび活動中の実行パスウェイに付与し、入力された原因ＩＤ値を、何らかの他のパスウェイに対して原因変化をもたらす影響を受けたパスウェイから、その他のパスウェイへ伝搬することによって行われ、伝搬すべき原因ＩＤは、含まれる演算の反事実的事前分析によって判定される。次いでこれにより、任意の所与の時点における各因果パスウェイが、データベース内に記録された原因イベントを、そのパスウェイの現在の値または状態に対する原因理由として「指し示す」ことが可能になり、したがってパスウェイが次いで活動中の否定的帰結結果の直接原因として作用する場合、否定的帰結が帰結を招いたデータベース内のソース原因イベントを指し示すことが可能になる。

【0403】

実施形態は、簡単な「成功／失敗」ステータスコード、および／または静的エラーコードではなく、根本原因条件発生の特有のインスタンスを、ユーザによって経験された否定的帰結に対する理由として動的に報告することができる。これは、同じタイプの根本原因条件（たとえば、エラー条件またはオペレータアクション条件）の異なるインスタンスが異なる否定的帰結に対して報告されるとき、根本原因発生の日／時間スタンプなどの場合により収集することができる各根本原因インスタンスに特有の可変情報、その根本原因発生に特有のセンサデータ、その根本原因の発生時にログインした演算子などを、否定的帰結に対して同様に動的に報告することができることを意味する。

【0404】

いくつかの実施形態は、活動中に即座の結果をもたらし、ユーザによって経験されると、帰結前準備または帰結後分析をユーザが実行することも必要とすることなく、否定的帰結に対してソフトウェアを能動的に実行する。実施形態は、ユーザに対して非常に正確かつ決定的な結果をもたらし、誤った結果または過度に高い開発コストを招き得るヒューリスティック手法を避けることができる。ソフトウェアを実装する実施形態は、否定的帰結に対して特有の原因イベントを報告することができるときはそのように行い、そうでない場合は、偽情報を提供するのではなく、追加の情報を提供しない。

【0405】

ヒューリスティック解から導出される結果は、頻繁に誤っていることが知られており、これはユーザに対する問題解決の負荷を増大させ、したがって問題解決時間が長いという基本的な問題を減少させずに増大させる可能性がある。実施形態は概して、ヒューリスティック解は開発が実行不能に高価になる可能性があるため、ヒューリスティック手法を避ける。異なる問題領域でヒューリスティック解を得ようとする多くの試みは、それらの目標の実現にすぐに失敗し、実用されていない。すなわち、これらの手法は、顧客へ出荷されておらず、または社内で部分的に使用されることもなく、計画の失敗および事業者資源の大きな無駄に終わった。

【0406】

概して、実施形態を使用するとき、ユーザは、任意の否定的帰結に対する根本原因条件を判定するために普通なら行われるのとほぼ同じ頻度で、根本原因を推測するためにイベント報告の独立したリストを検索したり、よく知らない任意の内部ソフトウェア設計を表すよく知らない追跡ファイルを掘り起こしたり、問題の解決を他に格上げしたりする必要はない。根本原因条件は、公称では、否定的帰結が表示されるとすぐに報告される。

【0407】

実施形態はまた、開発資源が許す限り既存のソフトウェアで１つ１つ実装することができる。これは、原因イベントの報告を行うように個々の因果パスおよびサブパスを変換することによって行うことができる。変換されていないパスは事実上、関心否定的帰結に対する追加の情報をユーザに報告しないという前の挙動に戻る。変換された各因果パスウェイは、すべてのパスウェイの変換が終了していないときでも、問題解決時間を低減させるのに役立つ。

【0408】

サブパスにおける原因報告の実装は、共通の原因ＩＤタイプの使用を介して相互運用可能になるように設計されており、正の「臨界質量」の副作用が発生し、より多くの個々の根本原因条件と否定的帰結のパスが変換されるため、根から帰結への完全なパスがコード内で中間サブパスを共有することが多いことから、新しい各パスの変換がより容易になる傾向がある。

【0409】

標準的なランダム化された１２８ビットのＵＵＩＤによって実質的に固有の原因ＩＤ（たとえば、各ＩＤに対してＩＤ衝突が発生する可能性は十億分の１未満である）を実装し、影響を受けるＵＩからアクセス可能な共通のデータベースへ、または影響を受けるＵＩからアクセス可能な論理的に共通の１組のデータベースへ、それらの原因イベントを報告するいくつかの実施形態は、それらの個々のサブシステムアーキテクチャまたは内部原因イベント（たとえば、エラーまたはオペレータアクション）表現にかかわらず、それらの間で原因および結果の情報を伝搬することができる。これは、多くの場合、複数の離散したソフトウェアスレッド、ソフトウェアプロセス、ソフトウェアアプリケーション、コンピュータ、ネットワークノードなどにわたって原因および結果を正確に追跡するように、ソフトウェアを実装することができることを意味する。

【0410】

実施形態は概して、各発生に対して新しい実質的に固有の原因ＩＤ値を生成し、発生特有のデータを有するその新しい固有の原因ＩＤによって識別される新しい原因イベントインスタンスを各発生に対してデータベースに書き込み、「現在」の原因ＩＤ項変数を付与して、ソフトウェアシステム内の実際の現在のデータ値および実際の現在の実行に対するその原因イベントおよび他の原因イベントの影響を、ユーザインターフェース内のそれらの任意の否定的帰結まで遡って追跡し、中間パスウェイに付与された原因ＩＤ項変数を介して、原因イベント条件の発生で初めに生成された固有の原因ＩＤ値を否定的帰結の表示まで伝搬することによって、原因イベント条件の個々の発生を追跡することを支持する。

【0411】

様々な実施形態は、従来のソフトウェアコードにすでにある因果パスウェイを活用して、それらのパスウェイ（原因ＩＤ変数）に簡単なメタデータを追加することによって、それが発生した原因および結果を自動で追跡し、原因および結果を判定するために、すべての可能な障害モード（数百万の範囲に及ぶことが多い原因イベント条件および否定的帰結のすべての可能な組合せ）の外部分析に依拠しない。

【0412】

原因および結果チェーン内の因果パスウェイの各セグメントまたはノードに原因ＩＤ項を追加することで、活動中状態で駆動される「自己追跡」がシステムに事実上加えられ、各ノードの出力が１つまたはそれ以上の他のノードの状態に影響を及ぼすか否かにかかわらず、影響を受けた原因状態変化時に１つのノードから次のノードへ原因ＩＤ項が伝搬すること、および影響を受けていない状態変化時に原因ＩＤ項が伝搬しないことにより、多数の可能な障害モードに対する理由の報告が自動で自然に処理される。またこれにより、多くの場合は重複する中間パスおよび帰結を共有する多くの障害モードが自動で処理される。

【0413】

原因ＩＤをランダムに生成された実質的に固有の１２８ビットのＵＵＩＤとして実装し、原因イベントを共通のデータベースに出力することで、異なるソフトウェアアーキテクチャにわたって実施可能かつ低衝撃である可能性がはるかに高いイベント（たとえば、エラー）表現分母（ＵＵＩＤ）を使用することによって、原因エラーを追跡することに寄与する。ほとんどのソフトウェア言語およびシステムは、ＵＵＩＤに対処することが可能であり、多くのソフトウェアシステムはすでに、内部イベント表現（たとえば、エラー表現）にかかわらず、それらの関心イベントを報告するために異なるソフトウェアサブシステムが必要とされる何らかの形式のイベントデータベースを含む。

【0414】

図１６は、本明細書に開示する原因イベント報告の様々な実施形態を実装するために使用することができる例示的なシステム１７０のシステム図である。様々なハードウェアシステム１７２を、プロセッサ１７４によって制御することができる。いくつかの実施形態では、システム１７０は、患者サンプル検査を実行するために使用される臨床アナライザである。他の実施形態では、ハードウェアシステム１７２は、自動車、製造、コンピュータ周辺機器などからの任意のハードウェアとすることができ、本明細書に論じる概念を臨床化学技術の範囲外で使用することができ、臨床アナライザは、これらの概念から利益を得ることができる単に１つの実施形態である。ハードウェアシステム１７２は、患者検査を実行および管理するために使用される様々なモータ、センサ、検査システムなどを含むことができる。プロセッサ１７４は、１つまたはそれ以上のプロセッサおよび関連するコンピューティングハードウェア、ならびにハードウェアシステム１７２の制御およびハードウェアシステム１７２との相互作用のために必要とされる他の回路に対するマイクロコントローラを有する任意の好適なコンピューティングシステムの一部とすることができる。プロセッサ１７４では、複数の原因スレッド１７６が実行している。これらの原因スレッドは、本明細書に開示するように、原因関数などの原因実行パスウェイを含む。様々な原因スレッド１７６は、簡単な変数、オブジェクト、持続データなどの原因データパスウェイ１７８と相互作用する。原因データ１７８は、ソフトウェアシステムの所望の特定用途向け関数を実行するために、ハードウェアシステム１７２と、コンピューティングシステムと、またはＵＩ１８２を介してユーザと相互作用するスレッド１７６によって使用される。論じたように、これらの原因スレッドは、原因根本条件に遭遇し、原因イベントを生成し、選択された原因ＩＤを特有の状態変化時に原因データに付与して割り当てることがある。

【0415】

原因スレッド１７６はまた、論じたように、原因データベース１８０を利用して、原因としてリンクされたシステムイベントを追跡する。原因スレッド１７６は、ユーザインターフェース１８２と相互作用して、ユーザ入力を探し、エラーまたは他の情報を表示する。エラーに対して、ＵＩ１８２は、スレッド１７６および原因データ１７８によって報告されるエラーに応答し、原因データベース１８０にアクセスし、否定的帰結の根原因イベントをユーザに報告し、親子関係を判定し、原因ツリーを表示することができる。これにより、ユーザは、原因の性質に基づいて、負のシステム状態を容易に修復することが可能になる。

【0416】

実施形態は、コンピュータ（延長としてプロセッサ）上で実行されるソフトウェア実装を利用する。このソフトウェアは、任意の好適なコンピュータ上で、任意の好適なプログラミング言語で実装することができる。特定の実施形態について、臨床アナライザのハードウェアおよびシステムによって使用するために説明するが、これは単に、これらの実施形態の概念から利益を得ることができるシステムの一例である。いくつかの実施形態は、任意のコンピュータまたはコンピュータおよびハードウェアシステムによって使用するのに好適である。図２０は、本明細書に記載する実施形態を実装するために使用することができる例示的なコンピューティング環境７００を示す。コンピューティング環境７００は、コンピュータシステム７１０を含み、これは本発明の実施形態を実装することができるコンピューティングシステムの一例である。コンピュータシステム７１０およびコンピューティング環境７００などのコンピュータおよびコンピューティング環境は、当業者には知られており、したがって本明細書では簡潔に説明する。

【0417】

図１７Ａは、プロセッサによって原因機能を有するソフトウェアモジュールを実行することに含まれる工程を示す高レベルの流れ図である。方法２００は、プロセッサがアプリケーション依存シーケンスに遭遇する工程２０２から始まる。原因機能を用いるソフトウェアアプリケーションは、アプリケーションに実装された実際の関数に特有の様々な異なる機能を含むことができる。したがって、遭遇した各関数、およびそれがどのように取り扱われるかは、アプリケーションに依存する。工程２０２より下の工程は、アプリケーション内で遭遇することができる例示的なタイプの関数シーケンスである。工程２０２で遭遇するアプリケーションの各依存シーケンスは、原因データおよび非原因データの任意の組合せを含むことができる入力パラメータを含むことができる。ソフトウェアは、次のアプリケーション依存シーケンスのいずれかを含むことができ、各シーケンスが図１７Ａに１つの工程として示されている。これらのタイプのシーケンスのすべてについてここに説明するが、所与のアプリケーションは、工程２１０、２２０、２９０、３００、３５０、および３７０のこれらのアプリケーション依存シーケンスの任意のサブセットを使用することができることに留意されたい。これらのタイプのアプリケーション依存シーケンスのいずれかに遭遇した場合、対応するプロセスがプロセッサによって実行される。

【0418】

工程２１０で、プロセッサは、否定的帰結を引き起こす可能性のないシーケンスに遭遇することがある。これらは、設計によって誤ったまたは否定的な帰結をもたらす可能性のないシーケンスである。たとえば、多くの算術演算子または関数は、否定的帰結を一度も引き起こすことなく実行することができる。多くのインスタンスでは、そのような関数の実行におけるエラーでも、システムに対して全体として否定的帰結をもたらすことはない。システムを実装するソフトウェア技術者は、工程２１０に一貫して演算するように、任意の所与の関数を処理することができる。工程２１０については、図１７Ｂに関してさらに説明する。

【0419】

工程２２０で、プロセッサは、原因式に遭遇することがあり、それによってプロセッサは、図１７Ｃに応じてこの原因式を評価する。工程２９０で、いくつかの関数は原因の割当てをもたらすことができ、これについては図１７Ｈに説明する。プロセッサはまた、アプリケーション依存シーケンスに遭遇することがあり、それにより工程３００で、図１７Ｉに説明するように、原因イベント条件がもたらされる。プロセッサが遭遇したアプリケーション依存シーケンスが、ユーザに表示する必要のある帰結をもたらし得る関数など、原因帰結の表示を必要とするものである場合、処理は、図１７Ｌに示す工程３５０へ進む。多くの場合、アプリケーション依存シーケンスは、従来の関数などの原因機能を含まず、その場合、処理は工程３７０へ進み、工程３７０で従来のアプリケーション依存命令が実行される。これらの工程の各々は、各アプリケーション依存シーケンスで使用される関数によって定義される原因データまたは非原因データの任意の組合せとすることができる引数を使用して実行される。

【0420】

所与のアプリケーション依存シーケンスが実行された後、プロセッサは、工程２０４で、アプリケーションコードを確認し、実行が終了したかどうか、または追加のアプリケーション依存シーケンスを実行するべきかどうかを判定する。実行が終了した場合、プロセッサは、アプリケーション依存シーケンスの処理を完了し、工程２０６で、原因および非原因データの任意の組合せを返す。

【0421】

図１７Ａのほぼシーケンスが、任意の他のシーケンスを呼び出すことができることに留意されたい。いくつかの実施形態では、ほとんどのシーケンスが、付与された原因ＩＤ項を有する原因データパラメータと、非原因データパラメータとの両方を受け付ける。１つのシーケンスに対するどの入力パラメータも、他のシーケンスに対する引数を形成してもしなくてもよい。原因特性は、１つのシーケンスが別のシーケンスを呼び出すとき、原因データ引数を非原因データ引数に、またその逆に変換してもしなくてもよいという特性を利用することができる。シーケンス呼出しは、それらの引数とともに送信された原因ＩＤ項を修正してもしなくてもよい。シーケンスは典型的に、次のシーケンスに対する引数として渡される原因ＩＤ項に対して、次の１つまたはそれ以上を行う：そのままにし；原因データを非原因データに変換するときに削除し；または非原因データを原因データに変換するときにニル原因ＩＤ項に設定する。原因イベント条件（プロセス３００）は、原因ＩＤ項が新しい原因ＩＤ値で充填される唯一の場所である。それ以外は、原因ＩＤ項は、伝搬され、最初にニルに設定され、ニルに上書きされ、または削除される。

【0422】

図１７Ｂは、否定的帰結を引き起こす可能性のないシーケンスに対するプロセス２１０を示す。工程２１２で、プロセッサは、原因または非原因データパラメータを渡して、否定的帰結を引き起こす可能性のないシーケンスを開始することによって、実行を開始する。そのような帰結を引き起こす可能性のない関数としての指名は、アプリケーションの機能性の草案によって行われる。たとえば、データの集合または基本ＵＩ表示関数は、否定的帰結を引き起こす可能性がないことが多い。典型的に、外部ハードウェアを制御するソフトウェア関数は、否定的帰結を引き起こす可能性があるが、純粋な演算命令のほとんどは、否定的帰結を引き起こす可能性がない。実行は次いで、再帰的に進むことができ、工程２１４で、新しいアプリケーション依存シーケンス２００が開始する。否定的帰結を引き起こす可能性のないシーケンスが工程２１２で開始された場合、工程２１４で開始されるアプリケーション依存シーケンスの結果もまた、否定的帰結をもたらす可能性がないことに留意されたい。したがって、定義上、プロセス２１０によって呼び出される部分関数が否定的帰結を引き起こす可能性がないため、再帰的呼出しによって工程２００に返される結果の原因ＩＤは削除され、またはニル原因ＩＤと交換される。プロセス２００への呼出しは、ニル原因ＩＤを有する原因データに変換された非原因データまたは非原因データに変換された原因データである引数を含むことができ、したがって原因ＩＤ項または非原因データを削除する。

【0423】

別法として、プロセッサは、否定的帰結を引き起こす可能性のないアプリケーション依存命令に遭遇することがあり、したがってプロセス２００への再帰的呼出しがもたらされない。これは、否定的帰結を引き起こす可能性のない任意の定義済み関数とすることができ、原因および非原因データである引数を使用することができる。命令または再帰的呼出しが評価された後、プロセッサは、否定的帰結を引き起こす可能性のない値を含む結果を返す。これらの値は、ニル原因ＩＤを有する原因データに変換された非原因データ、非原因データに変換された原因データ、または非原因データを含むことができる。

【0424】

原因式の評価であるプロセス２２０について、図１７Ｃに説明する。工程２２２で、プロセッサは、原因および非原因データの任意の組合せであるパラメータを含むことができる原因式の評価を開始する。これは、４つの可能な方法のいずれかで進むことができる。原因式がブールＡＮＤである場合、評価は工程２３０へ進み、プロセッサはブールＡＮＤを評価する。原因式がブールＯＲである場合、評価は工程２５０へ進み、プロセッサはブールＯＲを評価する。原因式がブールＮＯＴである場合、評価は工程２７０へ進み、プロセッサはブールＮＯＴを評価する。原因式が任意の他の演算である場合、評価は工程２８０へ進み、プロセッサは演算（Ｏｐｅｒａｔｉｏｎ＿Ｘのラベル付き）を評価する。これらのプロセスの各々は、原因データまたは非原因データを引数として取得することができ、非原因データは、原因ＩＤ項をニルに設定することによって原因データに変換される。これらのプロセスについて、図１７Ｄ～図１７Ｇに関して説明する。工程２２４で、原因式が評価された後、プロセッサは原因データ結果を返す。

【0425】

図１７Ｄは、原因ＡＮＤを実行するための例示的なプロセス２３０の詳細を示す。工程２３２で、プロセッサは、ブールＡＮＤの実行を開始し、変数ＰおよびＱ（または多方向ＡＮＤに対する任意の他の変数）の原因形式を含むパラメータを渡す。工程２３４で、プロセッサは、原因値Ｐの非原因値を評価して、Ｐの非原因部分（Ｐのラベル付き）が真であるかどうかを判定する。工程２３６および２４２で、プロセッサは、原因値Ｑの非原因部分（Ｑのラベル付き）が真であるかどうかを判定する。いずれも真でなかった場合、工程２３８で、プロセッサは偽を返し、ＰおよびＱの両方に対する原因ＩＤ項またはその任意のサブセットを含む新しい原因ＩＤ項を返す。Ｐが偽であり、かつＱが真である場合、工程２４０で、プロセッサは偽を返し、Ｐに対する原因ＩＤ項を返す。Ｐが真であり、かつＱが偽である場合、プロセッサは偽を返し、原因ＩＤ項Ｑを返す。ＰおよびＱの両方が真である場合、プロセッサは真を返し、ＰおよびＱの両方に対する原因項またはその任意のサブセットを含む新しい原因ＩＤ項を返す。これは、本明細書全体にわたって説明するように、原因ＡＮＤ関数がどのように機能するかを説明する表に一貫している。

【0426】

図１７Ｅに示すように、原因ＯＲを実行するための例示的なプロセス２５０はまた、本明細書全体にわたって説明する表に一貫して挙動する。工程２５２で、プロセッサは、原因ブールＯＲ演算を開始し、原因値をパラメータとして取得する。工程２５４で、プロセッサは、Ｐが真であるかどうかを評価する。工程２５６および２６２で、プロセッサは、Ｑが真であるかどうかを評価する。表に一貫して、ＰまたはＱのどちらも真でない場合、工程２５８で、プロセスは偽を返し、ＰおよびＱの両方に対する原因ＩＤ項またはその任意のサブセットを含む新しい原因ＩＤ項を返す。Ｐが偽であり、かつＱが真である場合、工程２６０で、プロセスは真を返し、Ｑに対する原因ＩＤ項を返す。Ｐが真であり、かつＱが偽である場合、工程２６４で、プロセスは真を返し、Ｐに対する原因ＩＤ項を返す。ＰおよびＱの両方が真である場合、工程２６８で、プロセスは真を返し、ＰおよびＱの両方に対する原因ＩＤ項またはその任意のサブセットを含む新しい原因ＩＤ項を返す。

【0427】

図１７Ｆに示すように、原因ＮＯＴを実行するための例示的なプロセス２７０はまた、本明細書全体にわたって説明する表に一貫して挙動する。工程２７２で、プロセッサは、原因ブールｎｏｔ演算を開始し、原因値Ｐをパラメータとして取得する。ＮＯＴ演算は、工程２７４で、値Ｐの論理ＮＯＴおよびＰに対する原因ＩＤ項を簡単に返す。

【0428】

図１７Ｇで、汎用原因関数（Ｏｐｅｒａｔｉｏｎ＿Ｘのラベル付き）を実行するためのキャッチオールプロセス２８０を示す。これは、比較、算術などを含むことができる。ソフトウェア開発者は、原因機能を作成するために、本明細書に記載する方法による因果表を提供するべきである。工程２８２で、プロセッサは、Ｏｐｅｒａｔｉｏｎ＿Ｘを開始し、定義された数の原因値｛Ａ＿１，ａ＿１｝，．．．，｛Ａ＿ｎ，ａ＿ｎ｝を受信する。工程２８４で、Ｏｐｅｒａｔｉｏｎ＿Ｘは、その定義によって実行され、演算の定義によって判定された非原因成分と、ソフトウェア開発者によってＯｐｅｒａｔｉｏｎ＿Ｘに対して作成された因果表に一貫した原因ＩＤ項とを有する原因値を返す。

【0429】

図１７Ｈは、原因の割当ての簡単な場合に対するプロセス２９０を示し、関数は、原因データ値をコピー、設定、または初期化する。プロセッサは、原因ＩＤ項内の基礎値をともに簡単にコピーする。原因データ値がリテラル値から割り当てられ、次いで原因値としてキャストされるとき、リテラル値に対する既知の原因がない場合、ニル原因ＩＤ項を指定することができ、または節が割り当てられているリテラル値の原因であることが開発者に知られている場合、実行中の原因イベント条件節に関連付けられた原因データから原因ＩＤ項を調達することができる。原因データ値が非原因データから割り当てられ、次いで原因値としてキャストされるとき、非原因データ値に対する既知の原因がない場合、ニル原因ＩＤ項を指定することができ、または節が割り当てられているリテラル値の原因であることが開発者に知られている場合、実行中の原因イベント条件節に関連付けられた原因データから原因ＩＤ項を調達することができる。工程２９２で、プロセッサは、原因割当てを開始し、原因データまたは原因データに変換された非原因データを、新しい原因値のメモリ内の位置に割り当てる。工程２９４で、プロセッサは、原因パラメータ、基礎値、および関連付けられた原因ＩＤ項を、割当て標的データ位置にコピーし、前の値を無効にする。工程２９６で、プロセスが戻る。

【0430】

図１７Ｉは、原因イベント条件を評価するためのプロセス３００を示す。概して２種類の原因イベント条件：送信された親イベントを有していない親なし原因イベント（原因式でないコア条件式から生じる）、および原因式である式によってトリガされると親ＩＤを送信することができる親を有する原因イベントがある。工程３０２で、プロセッサは、原因データまたは非原因データをパラメータとして取得することができる原因イベント条件を実行し始める。状況に応じて、原因イベント条件は、親なし原因イベント条件（プロセス３１０、図１７Ｊ）とすることができ、または親あり原因イベント条件（プロセス３３０、図１７Ｋ）とすることができる。プロセス３１０は、原因ＩＤ項または非原因データを引数として削除することによって、非原因データに変換された原因データを取得する。親なしと呼ばれる条件へ渡される原因ＩＤ項は、定義上、イベントを別の原因イベントによってトリガすることができず、またはイベントをトリガした入力が非ニル原因ＩＤを有するべきでないため、原因ＩＤ項を無視するべきである。プロセス３３０は、ニル原因ＩＤによって引数として、原因データまたは原因データに変換された非原因データを取得する。定義上、親あり原因イベントは、非ニル原因ＩＤを有する少なくとも１つの入力パラメータを有するべきである。

【0431】

親なし原因イベント条件を取り扱うためのプロセス３１０について、図１７Ｊで説明する。工程３１２、プロセッサは、親なし原因イベント条件を評価し始め、非原因データをパラメータとして取得する。工程３１４で、非原因式が評価され、結果が工程３１６へ送信される。工程３１６で、プロセッサは、式の結果値を、エラー条件などの場合により否定的帰結をもたらすことが知られている条件と比較する。原因条件が満たされない場合、プロセッサは、工程３２４で戻るべきであり、場合により、ニル原因ＩＤ項を有する成功コードを含むことができる。

【0432】

原因条件が満たされた場合（エラー条件など）、プロセッサは、工程３１８で、新しい原因ＩＤを作成するプロセスを開始する。工程３１８で、プロセッサは、好適に固有の原因ＩＤ項を生成し、条件に関連する診断情報を収集する。プロセッサは次いで、新しい原因イベントエントリを生成し、原因データベースにポスティングし：イベントの原因ＩＤは、ちょうど生成された固有の原因ＩＤに設定され；イベントの親原因ＩＤ項は、ニル原因ＩＤ項に設定され；イベントのタイプは、この原因条件を識別するタイプに設定され；イベントの診断データは、ちょうど収集された診断データに設定される。プロセッサは次いで、新しく生成された原因ＩＤを次の工程（３２０）へ、渡される引数のための原因ＩＤ項として送信する。

【0433】

工程３２０で、プロセッサは、場合により否定的帰結を引き起こすことが知られているアクションを実行する。これは、プロセス２００を呼び出して、否定的帰結を引き起こす可能性があるアクションを実行するために必要とされるシーケンスを実行することによって行うことができる。渡される引数は、新しく生成された原因ＩＤ項に設定された原因ＩＤ項を有する原因データまたは非原因データを含む。工程３２２で、プロセスが戻る。返される値は、場合により、失敗コードなどの原因データを含むことができ、原因ＩＤ項は、ちょうど生成された原因ＩＤなどに設定することができる。

【0434】

原因親を有するイベント条件を取り扱うためのプロセス３３０を、図１７Ｋに示す。工程３３２で、プロセッサは、パラメータとして渡された原因データを有する原因イベント条件を評価し始める（非原因データがパラメータとして渡される工程３１２と比較されたい）。工程３３４は、工程２２０と実質的に同じであり、プロセッサは、原因式を評価し、原因データを引数として取得し、結果を工程３３６へ送信する。工程３３６で、原因式の基礎値が、工程３１６と同様に、場合により否定的帰結をもたらすことが知られている条件と比較される。満たされない場合、プロセッサは工程３４６で戻り、場合によりニルに設定された原因ＩＤ項を有する原因成功コードを含むことができる。満たされる場合、工程３３８で、プロセッサは、工程３１８と同様に、イベントに対する親原因ＩＤ項のように、イベントが工程３３４の結果で原因ＩＤ項を指名することを除いて、原因イベントを原因データベースにポスティングする。すなわち、プロセッサは、好適に固有の原因ＩＤを生成し、条件に関する診断情報を収集し、原因データベース内に新しい原因イベントエントリを作成し、新しく生成された原因ＩＤを使用し、工程３３４で返された原因ＩＤに親原因ＩＤ項を設定し、原因条件に基づいて原因イベント型を設定し、データベース内のイベントに任意の診断データを含む。ちょうど生成された原因ＩＤは、次の工程へ送信される。

【0435】

工程３４０で、プロセッサは、場合により否定的帰結を引き起こすことが知られているアクションを実行する。これは、プロセス２００を呼び出して、否定的帰結を引き起こす可能性があるアクションを実行するために必要とされるシーケンスを実行することによって行うことができる。渡される引数は、新しく生成された原因ＩＤ項に設定される原因ＩＤ項を有する原因データ、または非原因データを含む。工程３４２で、プロセッサが戻る。返される値は、場合により、失敗コードなどの原因データを含むことができ、原因ＩＤ項は、ちょうど生成された原因ＩＤなどに設定することができる。

【0436】

プロセッサが因果関係の帰結に対する確認を実行するプロセス３５０を、図１７Ｌに示す。工程３５２で、プロセッサは、表示すべき因果関係の帰結を確認するためのプロセスを開始し、パラメータとして原因データまたはニル原因ＩＤ項を有するように変換された非原因データを取得する。

【0437】

工程３５４で、プロセッサは、原因データの値が、ユーザに（即座に）表示すべきアプリケーション依存否定的帰結を表すかどうかを判定する。特定の否定的帰結は、他のものより重要となる可能性があり、ユーザに警報する必要がある。否定的帰結の表示が許可された場合、実行は工程３５６へ進み、そうでない場合、実行は工程３６４へ進む。工程３５６で、プロセッサは、原因データに関連付けられた原因ＩＤ項がニル原因ＩＤ項であるか否かを判定する。ニル原因ＩＤ項である場合、工程３６２で、プロセッサは、アプリケーション依存否定的帰結をアプリケーションのユーザに表示し、この帰結に関連付けられたまたは表示された原因イベント（理由）はない。

【0438】

原因ＩＤ項がニルＩＤでない場合、工程３５８で、プロセッサは、原因データの原因項の原因ＩＤに基づいて、原因イベントデータベース内の原因イベントを参照する。非ニル親原因ＩＤを有するすべてのイベントに対して、これらの親イベントが参照される。このプロセスは、すべての関連する子なしイベントが発見されるまで、すべての新しく参照されたイベントに対するすべての親イベントを参照して継続される。これらの子なしイベントの各々は、潜在的な根本原因イベントである。工程３６０で、プロセッサは、アプリケーション依存否定的帰結を、工程３５８で否定的帰結に対する理由として見つけられた根本原因イベントとともに、ユーザに表示する。いくつかの実施形態では、原因イベントのフォーマット化および解釈は、ソース原因項に含まれる意味、アプリケーション依存の詳細、イベント型、または各原因ＩＤに関連付けられた原因イベントデータベースに含まれる特有の情報に基づいて行うことができる。ＧＵＩはまた、ユーザの追加コンテキストを提供するために、子イベントのトグルを可能にするように構成することができる。

【0439】

工程３６４へ戻ると、プロセッサはまた、原因データの値がユーザに即座に表示すべきアプリケーション依存の肯定的帰結を表すかどうかを判定することができる。いくつかの実施形態では、タスクの完了成功などの特定の肯定イベントをユーザに表示することができる。原因データがそのような帰結を表す場合、実行は工程３６８へ進み、そうでない場合、実行は工程３６６へ進む。工程３６８で、インターフェースは、アプリケーション依存の肯定的帰結をユーザに表示する。概して、表示は、帰結に関連付けられた原因イベントを含まず、原因データに関連付けられた原因ＩＤ項を無視する。これは、肯定イベントが通常、ユーザが根本原因と考えることになるものを有しておらず、または根本原因が重要でないからであり、したがって重要な情報に関してユーザが混乱する可能性がある。工程３６６で、表示すべき肯定的帰結がないとき、インターフェースは、プロセッサの制御下で、肯定的または否定的帰結をユーザに表示しない。概して、原因イベントが表示されず、原因ＩＤ項が無視される。工程３６９で、プロセスは戻る。

【0440】

図１８Ａ～図１８Ｈおよび図１９Ａ～図１９Ｃは、異なるデータ値および原因ＩＤが、本明細書全体にわたって論じる因果表を使用して、基本的なブール演算から構成された同じおよび異なる式をどのように流れることができるか、ならびに方法が所望の結果をもたらすことの例を示す。これらの例で、開発者は、最後の結果を表示するときを除いて、任意の所与の時点で真または偽がエラーを表すか、それとも成功を表すかを心配する必要はない。例示的な関数ＲｅａｄｉｎｇＩｓＨｉｇｈ（）は、何らかの読取りが高い場合は真を返し、読取りが低い場合は偽を返す。読取りを処理する式に依存して、いくつかの場合、高い読取りは良好であり、低い読取りは不良であり、他の場合、低い読取りは良好であり、高い読取りは不良である。この例では、センサおよび読取りを識別するＲｅａｄｉｎｇＩｓＨｉｇｈ（）が呼び出されるとき、原因イベントがポスティングされ、そのイベントの原因ＩＤが、呼出しの真／偽の結果とともに返されると仮定する。たとえば、センサＡは、｛ｔｒｕｅ，ａ｝または｛ｆａｌｓｅ，ａ｝を返し、ここで「ａ」は、センサＡのＲｅａｄｉｎｇＩｓＨｉｇｈ（）への呼出しによってポスティングされた原因イベントの原因ＩＤであり；センサＢは、｛ｔｒｕｅ，ｂ｝または｛ｆａｌｓｅ，ｂ｝を返し、ここで「ｂ」は、センサｂのＲｅａｄｉｎｇＩｓＨｉｇｈ（）への呼出しによってポスティングされた原因イベントの原因ＩＤであり；以下同様である。「ａ」によって参照される原因イベントは、センサＡをソースと呼び、理論上はセンサ読取り、日／時間などを含むことになる。同様に、「ｂ」によって参照される原因イベントは、センサＢをソースと呼び、理論上はセンサ読取り、日／時間などを含むことになる。ＲｅａｄｉｎｇＩｓＨｉｇｈ（）は、センサ高／低い値（真または偽）、およびセンサを読み取るイベントに関連付けられた原因ＩＤを含む原因値出力を有する。これらの例は、原因値が式を伝搬するときの、原因ＯＲ、原因ＡＮＤ、および原因ＮＯＴを含む各原因関数の原因出力を示す。

【0441】

図１８Ａは、否定的帰結が表示されるべきであるかどうかを読取りセンサＡが判定する２つの簡単なケースを示す。関数の結果が偽である場合、否定的帰結が表示され、関数結果が真である場合、否定的帰結は表示されない。図１８Ｂは逆を示し、関数の出力が真であるときに否定的帰結が表示される。図１８Ｃは、図１８Ａおよび図１８Ｂに示す類似の規則を示すが、原因ＮＯＴ関数が論理に追加され、帰結が反転している。

【0442】

図１８Ｄは、わずかにより複雑な例を示し、２つのセンサが使用され、それらの結果が原因ＡＮＤと組み合わされており、その結果、関数が偽と評価された場合、エラーを引き起こす。センサ読取り関数出力の４つの可能な論理の組合せの各々が提示される。センサＡおよびＢに対する読取り関数の否定的評価が、否定的帰結の原因である可能性があるため、否定的帰結が表示され、ソースイベントは、どのセンサが高い読取りを有することに失敗したかを指し示す。図１８Ｅは、類似の状況を示し、関数が真と評価された場合、エラーが表示される。表示される否定的帰結は、両方の読取り関数が真と評価されたとき、両方のセンサの識別を含む。他の組合せも、否定的帰結の表示をもたらさない。これらの例では、本明細書全体にわたって論じる論理表に応じて挙動するＡＮＤ関数に基づいて、合理的な原因が表示される。

【0443】

図１８Ｆおよび図１８Ｇは、原因ＯＲが使用される２つの異なる例を提示する。図１８Ｆは、ＯＲが偽と評価された場合に否定的帰結が表示される体系の結果を示し；図１８Ｇは、ＯＲが真と評価された場合に否定的帰結が表示される体系の結果を示す。これらの例では、本明細書全体にわたって論じる論理表に応じて挙動するＯＲ関数に基づいて、合理的な原因が表示される。

【0444】

図１８Ｈは、ＮＯＴおよびＡＮＤの原因バージョンの組合せを使用して否定的帰結を表示するかどうかを判定するために、合成論理式が使用される一例を示す。合理的な根本原因は、予期されるように、これらの演算に応じて、原因ＩＤの伝搬に基づいて識別される。

【0445】

図１９Ａ～図１９Ｃは、３つのセンサに対するＮＯＴ、ＯＲ、およびＡＮＤの原因バージョンの組合せを使用して否定的帰結を表示するかどうかを判定するために、合成論理式が使用される一例を示す（ＲｅａｄｉｎｇＩｓＨｉｇｈ（）関数の出力に対する可能な組合せのサブセットのみが提示される）。合理的な根本原因は、予期されるように、これらの演算に応じて、原因ＩＤの伝搬に基づいて識別される。

【0446】

図２０に示すように、コンピュータシステム７１０は、システムバス７２１などの通信機構またはコンピュータシステム７１０内で情報を通信するための他の通信機構を含むことができる。コンピュータシステム７１０は、情報を処理するようにシステムバス７２１に結合された１つまたはそれ以上のプロセッサ７２０をさらに含む。プロセッサ７２０は、１つまたはそれ以上の中央処理装置（ＣＰＵ）、グラフィック処理ユニット（ＧＰＵ）、または当技術分野で知られている任意の他のプロセッサを含むことができる。

【0447】

コンピュータシステム７１０はまた、プロセッサ７２０によって実行される情報および命令を記憶するようにバス７２１に結合されたシステムメモリ７３０を含む。システムメモリ７３０は、読取り専用メモリ（ＲＯＭ）７３１および／またはランダムアクセスメモリ（ＲＡＭ）７３２などの揮発性および／または不揮発性メモリの形態で、コンピュータ可読記憶媒体を含むことができる。システムメモリＲＡＭ７３２は、他の動的記憶デバイス（たとえば、動的ＲＡＭ、静的ＲＡＭ、および同期ＤＲＡＭ）を含むことができる。システムメモリＲＯＭ７３１は、他の静的記憶デバイス（たとえば、プログラマブルＲＯＭ、消去可能ＰＲＯＭ、および電気的消去可能ＰＲＯＭ）を含むことができる。加えて、システムメモリ７３０は、プロセッサ７２０による命令の実行中に一時変数または他の中間情報を記憶するために使用することができる。基本入出力システム（ＢＩＯＳ）７３３が、スタートアップ中などにコンピュータシステム７１０内の要素間の情報の伝達を助ける基本ルーチンを含み、これらの基本ルーチンは、ＲＯＭ７３１に記憶することができる。ＲＡＭ７３２は、プロセッサ７２０にとって即座にアクセス可能であり、かつ／またはプロセッサ７２０によって現在動作されている、データおよび／またはプログラムモジュールを含むことができる。システムメモリ７３０は、たとえば、オペレーティングシステム７３４、アプリケーションプログラム７３５、他のプログラムモジュール７３６、およびプログラムデータ７３７をさらに含むことができる。アプリケーションプログラム７３５は、たとえば、本明細書全体にわたって論じる様々な原因スレッドおよび原因ＩＤデータベースの実装など、１つまたはそれ以上の実行可能なアプリケーションを含むことができる。

【0448】

コンピュータシステム７１０はまた、ハードディスク７４１および取外し可能メディアドライブ７４２（たとえば、コンパクトディスクドライブ、ソリッドステートドライブなど）など、情報および命令を記憶するように１つまたはそれ以上の記憶デバイスを制御するようにシステムバス７２１に結合されたディスクコントローラ７４０を含む。記憶デバイスは、適当なデバイスインターフェース（たとえば、小型コンピュータシステムインターフェース（ＳＣＳＩ）、統合デバイスエレクトロニクス、ユニバーサルシリアルバス（ＵＳＢ）、またはファイアワイア）を使用して、コンピュータシステム７１０に追加することができる。

【0449】

コンピュータシステム７１０はまた、静止ロボットシステムのコントローラコンピューティングシステムのプログラミングまたは保守のタスクを負ったコンピュータユーザに情報を表示するように液晶ディスプレイ（ＬＣＤ）などのディスプレイ７６６を制御するようにバス７２１に結合されたディスプレイコントローラ７６５を含むことができる。コンピュータシステムは、コンピュータユーザと相互作用し、プロセッサ７２０に情報を提供するために、キーボード７６２およびポインティングデバイス７６１などの入力インターフェース７６０および１つまたはそれ以上の入力デバイスを含む。ポインティングデバイス７６１は、たとえば、指示情報およびコマンド選択をプロセッサ７２０に通信し、ディスプレイ７６６上のカーソルの動きを制御するためのマウスまたはポインティングスティックとすることができる。ディスプレイ７６６は、ポインティングデバイス７６１による指示情報およびコマンド選択の通信を補足または置換する入力を可能にするタッチスクリーンインターフェースを提供することができる。

【0450】

コンピュータシステム７１０は、プロセッサ７２０がシステムメモリ７３０などのメモリ内に含まれる１つまたはそれ以上の命令の１つまたはそれ以上のシーケンスを実行することに応答して、本発明の実施形態の処理工程の一部分またはすべてを実行することができる。そのような命令は、ハードディスク７４１または取外し可能メディアドライブ７４２などの別のコンピュータ可読媒体から、システムメモリ７３０に読み込むことができる。ハードディスク７４１は、本発明の実施形態によって使用される１つまたはそれ以上のデータストアおよびデータファイルを含むことができる。データストアのコンテンツおよびデータファイルは、セキュリティを改善するために暗号化することができる。プロセッサ７２０はまた、システムメモリ７３０に含まれる命令の１つまたはそれ以上のシーケンスを実行するために、多重処理配置で用いることができる。代替実施形態では、ソフトウェア命令の代わりに、またはソフトウェア命令と組み合わせて、ハードワイヤード回路を使用することができる。したがって、実施形態は、ハードウェア回路およびソフトウェアの特有の組合せに限定されるものではない。

【0451】

上述したように、コンピュータシステム７１０は、本発明の実施形態によってプログラムされた命令を保持し、データ構造、表、記録、または本明細書に記載の他のデータを含むために、少なくとも１つのコンピュータ可読媒体またはメモリを含むことができる。本明細書では、「コンピュータ可読媒体」という用語は、実行のためにプロセッサ７２０へ命令を提供することに関与する任意の媒体を指す。コンピュータ可読媒体は、それだけに限定されるものではないが、不揮発性媒体、揮発性媒体、および伝送媒体を含む多くの形態を取ることができる。不揮発性媒体の非限定的な例には、ハードディスク７４１または取外し可能メディアドライブ７４２など、光ディスク、ソリッドステートドライブ、磁気ディスク、および光磁気ディスクが含まれる。揮発性媒体の非限定的な例には、システムメモリ７３０などの動的メモリが含まれる。伝送媒体の非限定的な例には、バス７２１を構成するワイアを含む同軸ケーブル、銅ワイア、および光ファイバが含まれる。伝送媒体はまた、無線波および赤外データ通信中に生成されるものなどの音波または光波の形態を取ることができる。

【0452】

ネットワーキング環境で使用されたとき、コンピュータシステム７１０は、クラウドサービス６１０によってネットワーク７７１を介して通信を確立するためのモデム７７２を含むことができる（図６参照）。モデム７７２は、ユーザネットワークインターフェース７７０または別の適当な機構を介して、バス７２１に接続することができる。ネットワーク７７１は、インターネット、イントラネット、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、直接接続もしくは一連の接続、携帯電話ネットワーク、またはコンピュータシステム７１０と他のコンピュータとの間の通信を容易にすることが可能な任意の他のネットワークもしくは媒体を含む、概して当技術分野で知られている任意のネットワークまたはシステムとすることができる。ネットワーク７７１は、有線、無線、またはそれらの組合せとすることができる。有線接続は、イーサネット、ユニバーサルシリアルバス（ＵＳＢ）、ＲＪ－１１、または概して当技術分野で知られている任意の他の有線接続を使用して実装することができる。無線接続は、Ｗｉ－Ｆｉ、ＷｉＭＡＸ、およびＢｌｕｅｔｏｏｔｈ、赤外線、セルラーネットワーク、衛星、または概して当技術分野で知られている任意の他の無線接続方法を使用して実装することができる。加えて、いくつかのネットワークが、ネットワーク７７１内の通信を容易にするために、単独で、または互いに通信して機能することができる。

【0453】

本開示の実施形態は、ハードウェアおよびソフトウェアの任意の組合せで実装することができる。加えて、本開示の実施形態は、たとえばコンピュータ可読非一過性媒体を有する製品（たとえば、１つまたはそれ以上のコンピュータプログラム製品）内に含むことができる。媒体はその中に、本開示の実施形態の機構を提供して容易にするように、たとえばコンピュータ可読プログラムコードを実施している。製品は、コンピュータシステムの一部として含むことができ、または別個に販売することができる。

【0454】

様々な態様および実施形態について本明細書に開示したが、他の態様および実施形態は当業者には明らかである。本明細書に開示する様々な態様および実施形態は、例示を目的とし、限定することを意図したものではなく、本当の範囲および精神は、次の特許請求の範囲によって示されている。別段の記載がない限り、次の議論から明らかなように、「適用」、「生成」、「識別」、「判定」、「処理」、「コンピューティング」、「選択」などの用語は、コンピュータシステムのレジスタおよびメモリ内の物理（たとえば、電子）量として表されるデータを、コンピュータシステムメモリもしくはレジスタまたは他のそのような情報記憶、伝送、もしくは表示デバイス内の物理量として同様に表される他のデータに操作および変換する、コンピュータシステムまたは類似の電子コンピューティングデバイスのアクションおよびプロセスを指すことができることが理解されよう。本明細書に記載する方法の実施形態は、コンピュータソフトウェアを使用して実装することができる。広く認められた規格に準拠するプログラミング言語で書かれた場合、方法を実装するように設計された命令シーケンスは、様々なハードウェアプラットホームでの実行および様々なオペレーティングシステムへのインターフェースのためにコンパイルすることができる。加えて、本発明の実施形態は、何らかの特定のプログラミング言語を参照して記載したものではない。様々なプログラミング言語を使用して、本発明の実施形態を実装することができることが理解されよう。本明細書では、実行可能なアプリケーションは、たとえばユーザコマンドまたは入力に応答して、オペレーティングシステム、コンテキストデータ取得システム、または他の情報処理システムのものなど、所定の機能を実装するようにプロセッサを調整するためのコードまたは機械可読命令を含む。

【0455】

実行可能なアプリケーションは、コードもしくは機械可読命令、サブルーチン、または１つもしくはそれ以上の特定のプロセスを実行するための実行可能なアプリケーションのコードもしくは部分の他の別個の区分のセグメントである。これらのプロセスは、入力データおよび／もしくはパラメータを受信すること、受信した入力データで動作を実行すること、および／または受信した入力パラメータに応答して機能を実行すること、ならびに結果として得られる出力データおよび／もしくはパラメータを提供することを含むことができる。

【0456】

本明細書では、「グラフィカルユーザインターフェース」（ＧＵＩ）は、ディスプレイプロセッサによって生成された１つまたはそれ以上の表示画像を含み、プロセッサまたは他のデバイスならびに関連するデータ取得および処理機能とのユーザ相互作用を可能にする。ＧＵＩはまた、実行可能な手順または実行可能なアプリケーションを含む。実行可能な手順または実行可能なアプリケーションは、ＧＵＩ表示画像を表す信号を生成するように、ディスプレイプロセッサを調整する。これらの信号は、ユーザによって観察されるように画像を表示する表示デバイスへ供給される。プロセッサは、実行可能な手順または実行可能なアプリケーションの制御下で、入力デバイスから受信する信号に応答して、ＧＵＩ表示画像を操作する。このようにして、ユーザは、入力デバイスを使用して表示画像と相互作用することができ、それによりプロセッサまたは他のデバイスとのユーザ相互作用が可能になる。

【0457】

本明細書の機能およびプロセス工程は、自動で実行することができ、または全体的もしくは部分的にユーザコマンドに応答して実行することができる。自動で実行される行動（工程を含む）は、ユーザによる行動の直接始動なく、１つまたはそれ以上の実行可能な命令またはデバイス動作に応答して実行される。

【0458】

図のシステムおよびプロセスは、排他的でない。本発明の原理によれば、同じ目的を実現するために、他のシステム、プロセス、およびメニューを導出することができる。本発明について、特定の実施形態を参照して説明したが、本明細書に図示および記載する実施形態および変形例は、例示のみを目的とすることを理解されたい。本発明の範囲から逸脱することなく、当業者であれば、現在の設計に対する修正を実装することができる。本明細書に記載するように、様々なシステム、サブシステム、エージェント、マネージャ、およびプロセスは、ハードウェア構成要素、ソフトウェア構成要素、および／またはそれらの組合せを使用して実装することができる。本明細書の特許請求の範囲の要素は、その要素が「～手段（ｍｅａｎｓ ｆｏｒ）」の語句を使用して明示的に引用されない限り、米国特許法第１１２条（ｆ）の規定に基づいて解釈されるべきではない。

【図1】

【図2A】

【図2B】

【図2C】

【図3】

【図4】

【図5A】

【図5B】

【図5C】

【図6A】

【図6B】

【図6C】

【図7A】

【図7B】

【図8A】

【図8B】

【図8C】

【図8D】

【図8E】

【図9】

【図10A】

【図10B】

【図10C】

【図11】

【図12】

【図13A】

【図13B】

【図13C】

【図13D】

【図14-1】

【図14-2】

【図14-3】

【図14-4】

【図14-5】

【図14-6】

【図14-7】

【図14-8】

【図15-1】

【図15-2】

【図15-3】

【図15-4】

【図16】

【図17A】

【図17B】

【図17C】

【図17D】

【図17E】

【図17F】

【図17G】

【図17H】

【図17I】

【図17J】

【図17K】

【図17L】

【図18A】

【図18B】

【図18C】

【図18D】

【図18E】

【図18F】

【図18G】

【図18H】

【図19A】

【図19B】

【図19C】

【図20】