JP2021533487A - 障害保護のための並列実行および関連プロセスの比較のためのシステムおよび方法 - Google Patents

Abstract

この明細書に記載されるシステム、方法、および他の実施形態は、プログラム障害の検出の改善に関する。一実施形態では、方法は、拡張プログラムおよび計装プログラムを並列に実行することを含む。計装プログラムは、ランタイムチェックを実施するベースラインプログラムの計装バージョンである。拡張プログラムは、実行時間を計装プログラムと一致させるために、ベースラインプログラムのソースコードに意図的な遅延が挿入された、ベースラインプログラムの拡張バージョンである。この方法は、拡張プログラムと計装プログラムとの間の不一致状態の発生を識別するために、計装プログラムの実行状態を監視することを含む。この方法は、関連するデバイスの機能に対するプログラム障害の影響を軽減するために、不一致状態を管理することを含む。

Description

関連出願の相互参照

この出願は、２０１８年１０月１８日に出願された米国特許出願第１６／１６４，０４２号の利益を主張する。上記出願の全開示が、参照によりこの明細書に組み込まれる。

この明細書に記載される主題は、一般に、障害に対するプログラムの回復力を向上させるためのシステムおよび方法、特に、プログラムの別個のバージョンを並列に実行し、プログラム間の不一致状態にしたがって障害を検出するためのシステムおよび方法に関する。

この欄は、必ずしも公知技術に該当しない、本開示に関連する背景情報を提供する。

プログラムが、たとえば、フォーマット、セキュリティ、性能などに関して、様々な規格に適合していることを保証することは、特にプログラムが比較的複雑な場合には、かなりの困難を伴うことがある。言及された規格は、障害／エラー保護プログラムを提供するための業界のベストプラクティス、および／または、特定の実施形態のために確立された安全／信頼性基準に関連する。一般に、開発者は、言及された規格への適合を容易にするために様々なチェックを実行する計装をプログラム内に含めることができる。様々なランタイムチェックは、プログラムの実行中に実行され、ネイティブ（たとえば、プログラムのバグ）および／又は外部の困難（たとえば、悪意のある攻撃）から保護し、それによって、プログラムの障害／故障からの保護を提供する。

しかし、たとえば適切にコード化されていない場合には、計装自体が問題の原因となることがある。その結果、プログラムフローの完全性などの計装によって提供される機能が適切に機能しない場合があり、セキュリティホール、計装自体に直接起因する障害などの問題がさらに発生する虞がある。

この欄は、開示の概要を提供するが、その全範囲またはその全特徴の包括的な開示ではない。

一実施形態では、プログラムの耐障害性（フォールトトレランス）の改善に関連する例示的なシステムおよび方法が開示されている。前述したように、プログラムを計装するプロセスは、プログラムの開発に複雑さをもたらし、その結果、潜在的に計装されていないソースコード、潜在的な障害／エラーをプログラムに追加する計装、および／または、一般に所望の機能を達成しない計装コードが発生する可能性がある。プログラム内でランタイムチェックを提供する際のこのような問題は、機能安全規格（たとえば、ＩＳＯ２６２６２）への適合をさらに複雑にしてしまう。

したがって、一実施形態では、障害状態の発生を識別するためにプログラムの非計装バージョンを並列に実行することによって、計装プログラムの実行を能動的に監視する監視制御システムが開示される。たとえば、ひとつのアプローチでは、開示された監視制御システムは、最初に、ベースラインプログラムを直接計装することによって、または、別のソースからプログラムの計装バージョンを受信することによって、計装プログラムを取得する。いずれの場合も、計装プログラムは、様々な機能安全規格への適合を達成するための、または、より一般には、様々なリスクに対する保護を提供するためのランタイムチェックを実施するための計装を含むベースラインプログラムの計装バージョンを表す。

さらに、監視制御システムは拡張プログラムを取得する。監視制御システムは、拡張プログラムを直接生成してもよいし、計装プログラムと同様に、二次ソースから拡張プログラムを取得してもよい。いずれの場合も、拡張プログラムは、計装プログラムと実質的に同一のタイムライン上で実行されるように調整されたベースラインプログラムのバージョンである。一実施形態では、監視制御システムは、計装プログラムを分析して、計装などの別個のステートメントに関連付けられた実行サイクルを識別する。監視制御システムは、ひとつのアプローチでは、実行サイクルのカウントを使用して、計装がいつどこで実行されているか、および、どのサイクルが計装に起因するかを決定する。

実行サイクルカウントの知識を用いて、監視制御システムは、一態様において、ベースラインプログラムにＮｏ−Ｏｐ命令を追加し、ベースラインプログラムの別個のバージョンとして拡張プログラムを生成する。示されているように、拡張プログラムは計装を含まないが、拡張プログラムに追加されたＮｏ−Ｏｐ命令のために、ほぼ同じサイクルカウントで実行される。そのため、拡張プログラムと計装プログラムは、同じタスクを実行するときにほぼ同じ実行時間を消費する。

したがって、一実施形態では、監視制御システムは、計装プログラムと拡張プログラムとを並列に実行する。ひとつのアプローチでは、プログラムはファームウェアとして別個のコントローラに埋め込まれるため、監視制御システムは別個のコントローラでプログラムを並列に実行する。別のアプローチでは、監視制御システムは、仮想マシン上で拡張プログラムを実行しながら、計装プログラムをコントローラ上の組み込みファームウェアとして実行する。いずれの場合も、拡張プログラムにはＮｏ−Ｏｐ命令が組み込まれているため、プログラムはロックステップで実行される。

したがって、監視制御システムは、両方のプログラムの実行を監視して、プログラムの障害を識別する。すなわち、監視制御システムは、計装プログラムを監視するための比較ポイントとして拡張プログラムを使用する。拡張プログラムは、様々なプログラム障害をもたらす可能性のある計装を含まないため、ふたつのプログラム間で共有される入力値、中間値、出力値、および、その他の態様の不一致は、計装プログラムの潜在的または実現された障害を示すものと考えられる。したがって、監視制御システムは、一実施形態では、様々な値を監視し、その値を比較してふたつのプログラム間の不一致の実行状態を識別することにより、プログラムの実行を監視する。

一般に、不一致状態の発生は、何らかのエラー、悪意のある攻撃、または他の異常が進行中であり、それがプログラムの障害を引き起こす可能性があるという推論を提供する。したがって、プログラムは、たとえば車両または他のデバイスのいくつかの安全関連の態様を制御するように動作している場合があるため、そのような障害の発生は、望ましくない傷害または他の困難をもたらす可能性がある。したがって、監視制御システムは、ひとつのアプローチにおいて、プログラムを実行するコントローラをリセットすることによって、不一致状態を管理する。その結果、監視制御システムは不一致状態を修正し、プログラムの障害を回避する。このようにして、監視制御システムは、計装プログラムの実行状態をよりよく認識することによってプログラムの機能を改善し、その結果、障害／エラーに対するプログラムの回復力を改善する。

一実施形態では、プログラム障害の検出を改善するための監視制御システムが開示される。監視制御システムは、ひとつ以上のプロセッサと、ひとつ以上のプロセッサに通信可能に結合されたメモリとを含む。メモリは、ひとつ以上のプロセッサによって実行されると、ひとつ以上のプロセッサに拡張プログラムおよび計装プログラムを並列に実行させる命令を含む実行モジュールを格納する。計装プログラムは、ランタイムチェックを実施するベースラインプログラムの計装バージョンである。拡張プログラムは、計装プログラムと実行時間が一致するように、ベースラインプログラムのソースコードに意図的な遅延が挿入されたベースラインプログラムの拡張バージョンである。メモリは、ひとつ以上のプロセッサによって実行されると、ひとつ以上のプロセッサに拡張プログラムと計装プログラムとの間の不一致状態の発生を識別するために計装プログラムの実行状態を監視させる命令を含むウォッチドッグモジュールを格納する。ウォッチドッグモジュールは、関連デバイスの機能に対するプログラム障害の影響を軽減するために、不一致状態を管理させる命令を含む。

一実施形態では、プログラム障害の検出を改善するための非一時的コンピュータ可読媒体が開示される。コンピュータ可読媒体は、ひとつ以上のプロセッサによって実行されると、ひとつ以上のプロセッサに、開示された機能を実行させる命令を格納する。命令は、拡張プログラムと計装プログラムとを並列に実行するための命令を含む。計装プログラムは、ランタイムチェックを実施するベースラインプログラムの計装バージョンである。拡張プログラムは、計装プログラムと実行時間が一致するように、ベースラインプログラムのソースコードに意図的な遅延が挿入されたベースラインプログラムの拡張バージョンである。命令は、拡張プログラムと計装プログラムとの間の不一致状態の発生を識別するために、計装プログラムの実行状態を監視する命令を含む。命令に、関連デバイスの機能に対するプログラム障害の影響を軽減するために、不一致状態を管理する命令を含む。

一実施形態では、プログラム障害の検出を改善するための方法が開示される。この方法は、拡張プログラムと計装プログラムとを並列に実行することを含む。計装プログラムは、ランタイムチェックを実施するベースラインプログラムの計装バージョンである。拡張プログラムは、計装プログラムと実行時間が一致するように、ベースラインプログラムのソースコードに意図的な遅延が挿入されたベースラインプログラムの拡張バージョンである。この方法は、拡張プログラムと計装プログラムとの間の不一致状態の発生を識別するために、計装プログラムの実行状態を監視することを含む。この方法は、関連デバイスの機能に対するプログラム障害の影響を軽減するために、不一致状態を管理することを含む。

この明細書に組み込まれ、その一部を構成する添付図面は、本開示の様々なシステム、方法、および他の実施形態を示している。図中の図示された要素の境界（たとえば、ボックス、ボックスのグループ、または他の形状）は、境界の一実施形態を表すことが理解されるであろう。いくつかの実施形態では、ひとつの要素が複数の要素として設計されてもよく、または複数の要素がひとつの要素として設計されてもよい。いくつかの実施形態では、別の要素の内部コンポーネントとして示される要素は、外部コンポーネントとして実装されてもよく、その逆もあり得る。さらに、要素は縮尺どおりに描かれない場合がある。
計装プログラムにおけるプログラム障害の耐性の改善に関連する監視制御システムの一実施形態を示す。 プログラムのソースコードの一例を示す。 図１のシステムが図２のソースコードから導出する制御フローグラフの一例を示す。 拡張プログラムおよび計装プログラムが実行される実行環境の一実施形態を示す。 ソースコードを自動的に計装することに関連する方法の一実施形態を示す。 計装プログラムの実行を監視することに関連する方法の一実施形態を示す。

プログラムの障害処理の改善に関連するシステム、方法、および他の実施形態が開示されている。前述したように、プログラムを計装するための現在のアプローチは、複雑であることがあり、その結果、プログラムに潜在的な障害／エラーを実際に追加する計装、および／または、一般に所望の機能を達成しない計装コードをもたらす。プログラム内でランタイムチェックを提供する際のこのような問題は、プログラムの信頼性および最終的な認証をさらに複雑にする可能性がある。

したがって、一実施形態では、並列に実行されるプログラムの非計装拡張バージョンの監視された比較を通じて、計装プログラムの実行を能動的に監視する監視制御システムが開示される。たとえば、ひとつのアプローチでは、開示された監視制御システムは、プログラム故障を検出し、管理するために、同じベースラインプログラムのふたつの異なるバージョンを使用する。監視制御システムは、プログラムの計装バージョンと、プログラムの非計装／拡張バージョンを使用する。計装バージョンは、ランタイムチェックを実施する計装を含むように変更されたベースラインプログラムを表す。ランタイムチェックは、プログラムフローの完全性、データの完全性、障害検出（たとえば、メモリの破損）などのチェックの実行など、プログラムをサポートする様々な機能を実行する。

拡張バージョンは、実行時間を調整するための追加命令を含むベースラインプログラムを表す。Ｎｏ−Ｏｐ命令は、ベースラインプログラムに追加されて拡張プログラムを形成し、実行時間（すなわち、サイクルカウント）を拡張して、計装プログラムと実行時間をほぼ一致させる。したがって、一実施形態では、監視制御システムは、計装プログラムと拡張プログラムを並列に実行する。ひとつのアプローチでは、プログラムは、別個のコントローラ内にファームウェアとして埋め込まれ、したがって、監視制御システムは、別個のコントローラ上のプログラムを並列に実行する。別のアプローチでは、監視制御システムは、仮想マシン上で拡張プログラムを実行しながら、計装プログラムをコントローラ（たとえば、ＥＣＵ）に組み込まれたファームウェアとして実行する。いずれの場合も、計装プログラムの実行時間と一致する拡張プログラムに埋め込まれたＮｏ−Ｏｐ命令のために、プログラムはロックステップで実行される。

したがって、監視制御システムは、プログラムの実行を監視して、プログラム障害を識別する。すなわち、監視制御システムは、計装プログラムを監視するための比較ポイントとして拡張プログラムを使用する。拡張プログラムには、様々なプログラム障害を引き起こす可能性のある計装が含まれていないため、拡張プログラムの値は、たとえば、計装に関連した障害／エラーを含まないものとして、信頼性がより高くなる。したがって、ふたつのプログラム間で入力値、中間値、出力値、およびその他のそのような値に相違が生じる場合、監視制御システムは、相違／不一致が、計装プログラムの潜在的または実現された障害を示すものみなすことができる。

したがって、監視制御システムは、一実施形態では、様々な値を監視し、値を比較して、プログラム間の不一致の実行状態を識別することにより、プログラムの実行を監視する。一般に、不一致状態の発生は、何らかのエラー、悪意のある攻撃、または他の異常が進行中であり、それがプログラムの障害を引き起こす可能性があるという推論を提供する。したがって、監視制御システムは、ひとつのアプローチでプログラムをリセットすることにより、不一致状態を管理する。その結果、監視制御システムは、不一致状態を修正し、プログラム障害を回避する。このように、監視制御システムは、実行状態をよりよく認識することにより計装プログラムの機能を改善し、その結果、障害／エラーに対するプログラムの回復力を改善する。

図１を参照すると、監視制御システム１００の一実施形態が示されている。この明細書では、監視制御システム１００に関する構成について説明するが、実施形態は、図示のような単一システムに限定されない。いくつかの実装形態では、監視制御システム１００は、クラウドコンピューティングシステム、クラスタコンピューティングシステム、分散コンピューティングシステム、サービスとしてのＳａａＳシステムなどとして具現化することができる。ＳａａＳは、software as a serviceの略称である。監視制御システム１００は、説明の目的で単一のデバイス（装置）として示され、説明されているが、開示された構成要素が構成され得る全体的な可能な構成を制限するものとして解釈されるべきではない。たとえば、別個のモジュール、メモリ、データベースなどは、様々な組み合わせで様々なコンピューティングシステムに分散されてもよい。

監視制御システム１００は、また、様々な要素を含む。様々な実施形態では、監視制御システム１００が、図１に示される要素のすべてを有さなくてもよいことが理解される。監視制御システム１００は、図１に示される様々な要素の任意の組み合わせを有することができる。さらに、監視制御システム１００は、図１に示される様々な要素に対して追加の要素を有することができる。いくつかの構成では、監視制御システム１００は、図１に示されるひとつ以上の要素なしで実施されてもよい。さらに、様々な要素は、図１の監視制御システム１００内に位置するものとして示されているが、これらの要素のうちのひとつ以上が監視制御システム１００の外部に配置できることが理解される。さらに、示された要素は、長い距離で物理的に分離されてもよい。

さらに、図示の単純化および明確化のために、参照番号が適宜、対応するまたは類似する要素を示すために、異なる図面間で繰り返されていることが理解される。さらに、この明細書に記載の実施形態の完全な理解を提供するために、多数の具体的な内容を説明する。しかしながら、当業であれば、この明細書に記載された実施形態は、これらの要素の様々な組み合わせを用いて実施され得ることを理解できる。

いずれの場合も、監視制御システム１００は、プログラムに関連する障害検出および処理の改善に関して、この明細書に開示されているような方法、および、他の機能を実行するために実装される。言及された機能と方法は、図のさらなる説明でより明らかになる。さらに、監視制御システム１００は、プロセッサ１１０を備えるものとして示されている。様々な実施形態において、プロセッサ１１０は、監視制御システム１００の一部であってもよく、監視制御システム１００は、データバス、または、別の通信経路を介してプロセッサ１１０にアクセスしてもよく、プロセッサ１１０は、監視制御システム１００によってアクセス可能なリモートコンピューティングリソースであってもよい。いずれの場合も、プロセッサ１１０は、マイクロプロセッサ、ＡＳＩＣ、グラフィックス処理装置（ＧＰＵ）、電子制御装置（ＥＣＵ）、または、他の電子デバイスの制御のために使用され得る様々な電子出力をそこから生成するための機械可読命令を実行することが可能な他のコンピューティングコンポーネント、のような電子デバイスである。

一実施形態では、監視制御システム１００は、実行モジュール１３０と、ウォッチドッグモジュール１４０と、計装モジュール１５０を格納するメモリ１２０を備える。実行モジュール１３０、ウォッチドッグモジュール１４０、および計装モジュール１５０を、モジュール１３０、１４０、１５０と示すことがある。メモリ１２０は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、ハードディスクドライブ、フラッシュメモリ、または、モジュール１３０、１４０、１５０を格納するための他の適切なメモリである。モジュール１３０、１４０、１５０は、たとえば、プロセッサ１１０によって実行されると、プロセッサ１１０に、この明細書に開示される様々な機能を実行させるコンピュータ可読命令である。様々な実施形態では、モジュール１３０、１４０、１５０は、ハードウェアロジック、ＡＳＩＣ、グラフィックス処理装置（ＧＰＵ）、プロセッサ１１０のコンポーネント、電子メモリ内に埋め込まれた命令などを含むことができるが、これらに限定されない様々な形態で実装され得る。

監視制御システム１００は、一実施形態では、データベース１６０を備える。データベース１６０は、一実施形態では、メモリ１２０、分散メモリ、クラウドベースのメモリ、または、別のデータストアに格納された電子データ構造であり、格納されたデータの分析、格納されたデータの提供、格納されたデータの整理などのためにプロセッサ１１０によって実行され得るルーチンで構成される。一実施形態では、データベース１６０は、様々な決定を実行する際にモジュール１３０、１４０、１５０によって使用されるデータを格納する。一実施形態では、データベース１６０は、制御フローグラフ、計装ポリシー、ベースラインプログラム、拡張プログラム１７０、計装プログラム１８０、および／または、開示された機能を実行する際にモジュール１３０、１４０、１５０によって使用され得る他のデータを格納する。

この明細書で使用される場合、「プログラム」という用語は、ソースコードから派生したコンパイルされたマシンコードを指す。したがって、ベースラインプログラムは、一実施形態では、マシンコードであるコンパイルされたプログラムまたはその一部である。この明細書で使用される「マシンコード」という語句は、一般に、たとえばプロセッサ１１０のような、マイクロプロセッサによって実行され得る機械語命令で表されるプログラムを指す。さらに、マシンコードは、一般に、関連するハードウェアによって実装された命令セットによって定義されるオペコード（たとえば、Ｎｏ−Ｏｐ命令）で構成されるプリミティブ言語、または、ハードウェア依存言語であると理解される。Ｎｏ−Ｏｐは、Ｎｏ−Ｏｐerationの略称である。さらに、マシンコード自体は、データ値、レジスタアドレス、メモリアドレスなどでさらに構成される。もちろん、プログラムはマシンコードであると説明されているが、さらなる実施形態では、プログラムは、アセンブリコード、または、ソースコードの別の中間表現である。

プログラムのコンパイル元のソースコードは、たとえば、関数、データ構造、オブジェクト、ステートメント（文）などで構成される。ソースコードの一部として含まれる計装は、さらに同じ要素（たとえば、オブジェクト、ステートメントなど）で構成される。一般に、プログラムは、関数のセット（集まり）として構成されている。様々な例では、関数は、サブ関数として相互にネスト（入れ子）になっている場合がある。さらに、関数は、一般に、ステートメントのセット（たとえば、ループ、Ｉ／Ｏステートメントなど）で構成され、通常は特定の機能に焦点を当てている。すなわち、個々の関数は、一般に、識別のタスクを実行するために実装される。したがって、サブ関数は、親関数のより広範な機能をサポートするサブルーチンを実装することができる。いずれの場合も、関数は、関数自体を構成するステートメントを定義し、関数に関連付けられた機能を実装するためのソースコードが含まれる。

ひとつのアプローチでは、モジュール１３０、１４０、１５０は、たとえば、統合開発環境（ＩＤＥ）に電子的に提供されるコードセグメントを含む電子的な入力および出力ストリームを含むＩＤＥの電子データにアクセスする。モジュール１３０、１４０、１５０は、アクセスを容易にするために、ＩＤＥのアプリケーションプログラムインターフェース（ＡＰＩ）を活用してもよい。さらに、そのようなアクセスは、モジュール１３０、１４０、１５０によるアクセスを自動化する（たとえば、直接統合アクセスを提供する）アプリケーションフックの形で提供されてもよい。いずれの場合も、システム１００、および、モジュール１３０、１４０、１５０は、たとえば、計装プログラム１８０の実行時間の分析、計装プログラム１８０の生成、拡張プログラム１７０の生成などを行うために、ＩＤＥと協調的に機能することができる。

データベース１６０の要素に続いて、拡張プログラム１７０および計装プログラム１８０は、データベース１６０に格納されているものとして示されている。もちろん、アプリケーションでは、拡張プログラム１７０および計装プログラム１８０は、実行されると、それぞれのコントローラ（図示せず）のメモリに埋め込まれる。しかしながら、図１に示されるように、説明の便宜上、プログラム１７０および１８０は、データベース１６０に格納されている。さらに、一実施形態では、監視制御システム１００は、最初に、拡張プログラム１７０および計装プログラム１８０を、データベース１６０などのローカルメモリ／データストアから格納および分析する。すなわち、後でより詳細に説明するように、一実施形態では、監視制御システム１００は、計装プログラム１８０を生成するためにベースラインプログラムを計装するように構成される。さらに、監視制御システム１００はまた、拡張プログラム１７０を、計装プログラム１８０に関連する態様にしたがって生成することができる。

たとえば、一実施形態では、データベース１６０は、ベースラインプログラムを計装し、計装プログラム１８０を生成するために計装モジュール１５０によって使用されるグラフを格納する。グラフは、たとえば、ベースラインプログラムの実行パスを表す制御フローグラフである。一実施形態では、計装モジュール１５０は、ベースラインプログラムのソースコードからグラフを導出する。計装モジュール１５０は、ひとつのアプローチでは、ノードおよびノード間の有向エッジを使用してグラフを形成する。

ノードはソースコードのブロック／セグメントを表し、ノード間の有向エッジはブロック間の遷移（ジャンプ）を表す。ブロックは、コードの原子セグメント（たとえば、途切れのない）、または、ソースコードの少なくとも一体的に関連するセグメントである。一実施形態では、有向エッジは、ブロック／セグメント間の手順内、および／または、手順間の制御フロー転送を示す。すなわち、エッジは、ハンドオーバ、関数呼び出し、具象関数および／またはシンボリック関数の引数などを表す。一般に、有向エッジは、別個のブロック間のプログラム実行における転送を示す。別の実施形態では、ノードおよび有向エッジは、この明細書に記載されているものとは異なって定義されてもよいことが理解されたい。グラフポリシーは、ノードおよびエッジをそれぞれ形成するブロック／セグメントと遷移を識別するための、テンプレート、例示的なセグメント／条件、および／または、指標（メトリクス）を定義する。したがって、システム１００は、別々の実装にしたがってグラフの態様を柔軟に定義するように実装することができる。

例として、図２は、プログラムのソースコード２００のサンプルセグメントを示している。また、図３は、制御フローグラフ３００の一例を示している。制御フローグラフ３００は、実行モジュール１３０を介して提供される入力からグラフモジュールによって生成され得るグラフの例である。図示しないグラフモジュールは、メモリ１２０に格納されている。グラフ３００は、ソースコード２００からのコードのセグメント／ブロックに対応するノード３０５、３１０、３１５、３２０、３２５、３３０、３３５、３４０、３４５を含む。グラフ３００は、ソースコード２００のセグメント間の関係に対応するノード間の有向エッジをさらに示す。さらに、分離されたノードおよび有向エッジは、たとえば、ソースコードの制御フロー特性にしたがって定義される。すなわち、ソースコードのブロック／セグメントが相互に関連する方法、および、ブロック／セグメント間の区切り自体は、ソースコードの制御フロー特性に従って定義される。後述するように、計装モジュール１５０は、一般に、プログラムのソースコードから制御フロー特性を識別し、計装の包含に関する決定が導出されるグラフを形成するために、システム１００内に定義されたグラフポリシーにしたがって識別することができる。

図１のデータベース１６０に続いて、一実施形態では、データベース１６０は、また、計装モジュール１５０が計装をソースコードに挿入して最終的に計装プログラム１８０を形成するためのソースコードの様々な条件、および／または、セグメントを定義する計装ポリシーを含む。一般に、計装は、特定の実装に応じて異なる目的を果たすことができる。たとえば、計装は、プログラムフローの制御（たとえば、プログラムが間違った方向に進んでいないことを保証する）、デバッグ、データ引数の検証、Ｉ／Ｏの検証などを提供するために、関数内に統合することができる。プログラムが、道路上で車両がどのように制御されるかを自動的に調整する高度運転支援システム（ＡＤＡＳ）を制御する場合、計装は、プログラムが悪意のある攻撃によって誤った方向に導かれた場合に、乗客に事故や負傷をもたらす可能性があるプログラムフローの悪意のある操作を防止するためのセキュリティ計装を含んでもよい（たとえば、プログラム制御フローの完全性を保証する）。

さらに、計装ポリシーは、ひとつのアプローチでは、計装自体に関連する特性と、計装モジュール１５０が拡張プログラムを生成するためにベースラインプログラムにＮｏ−Ｏｐ命令を含める方法に関連する特性を定義する。たとえば、計装ポリシーは、計装ポリシーで定義された様々なテンプレートに含まれる、様々な計装ステートメントのサイクルカウントを示す。したがって、プログラム内にカスタマイズして組み込むためのテンプレートの形で計装を指定するとともに、計装ポリシーは、計装によって消費される実行サイクル数などの計装の特性を示す。このように、後に拡張プログラム１７０を生成するとき、計装モジュール１５０は、ひとつのアプローチにおいて、計装ポリシーを参照して、計装に起因する実行サイクル、したがって、計装の実行時間を考慮して拡張プログラム１７０内に挿入する対応する数のＮｏ−Ｏｐ命令を決定する。

さらに別の態様では、計装ポリシーは、拡張プログラム１７０を生成するために、ベースラインプログラムがＮｏ−Ｏｐ命令によってどのように計装されるかを定義する。すなわち、計測ポリシーは、Ｎｏ−Ｏｐ命令が挿入されるＮｏ−Ｏｐ命令の形式、および、実行時間に一致するようにＮｏ−Ｏｐ命令を使用して拡張プログラム１７０を形成するためのベースラインプログラムの計装に関する他の詳細を定義する。

さらに、計装ポリシーは、プログラムの計装方法に関連するさらなる態様を定義することもできる。したがって、一実施形態では、計装ポリシーは、計装閾値、または、少なくとも計装閾値を生成するための指標（メトリクス）を定義する。ひとつのアプローチでは、計装ポリシーは、関数の特性が計装で変更されるために関連する計装閾値を満たすように、異なるクラスの関数に対して計装閾値を定義する。たとえば、一実施形態では、計装ポリシーは、開発者によってタグ付けされるか、または、関数内のコードセグメントに関連付けられた定義された指標にしたがって導出され得るセキュリティレベルにしたがって、関数のクラスを定義する。したがって、計装ポリシーは、第１のクラスに対する第１の閾値、第２のクラスに対する第２の閾値、第３のクラスに対する第３の閾値などを示すことができる。一般に、セキュリティレベルのための別個のクラスおよび関連する閾値は、特定の機能の脆弱性（たとえば、操作への暴露）または他の態様に関連してもよい。したがって、計装ポリシーは、計装の包含を最適化するために、セグメントが計装されるべきである異なる閾値を示してもよい。実際には、計装モジュール１５０は、たとえば、コードセグメントを評価し、計装プログラム１８０を生成するために、評価にしたがって計装を自動的に含む。

さらに、コードセグメント内に含まれる実際の計装自体は、一実施形態では、計装ポリシー、または、前述したグラフポリシー内のテンプレートとして定義される。たとえば、テンプレートは、プログラムフローの制御、Ｉ／Ｏの検証、追加の関数フックの提供、障害処理の実行、データ整合性のチェックなどに関する様々な機能を実行する、標準化された計装のセットを定義する。さらに、ひとつのアプローチでは、テンプレートは、計装が含まれる特定のコードセグメントにしたがって、たとえば、計装モジュール１５０によりカスタマイズされる計装テンプレート内の変数をさらに示す。すなわち、計装モジュール１５０は、一例では、関数のリターンアドレスを検証するための計装を含んでもよい。このように、計装モジュール１５０は、テンプレートをベースとして使用することによって、関連するソースコードに対応するようにテンプレートから関連する計装ステートメントの変数を修正し、関連するソースコードセグメントにセキュリティまたは他の機能を提供する。計装ポリシーおよび計装モジュール１５０のさらなる態様については、後述する。

図１を続けると、計装モジュール１５０は、一実施形態では、プロセッサ１１０によって実行されると、たとえば計装プログラム１８０を形成するためにベースラインプログラムを自動的に計装する制御フローグラフをプロセッサに生成させるコンピュータ可読命令を含む。計装モジュール１５０は、ベースラインプログラムのソースコードの制御フロー特性を識別することによってグラフを形成する。すなわち、計装モジュール１５０は、ソースコードを（ソースコードが開発されるときにリアルタイムで、または要求に応じて）分析して、制御フロー特性を識別する。一実施形態では、制御フロー特性は、関数呼び出しなどのベースラインプログラムの手順内、および／または、手順間の制御フロー転送、たとえば、関数呼び出し、シンボリック名に沿ったリターンアドレス、具象関数および／またはシンボリック関数の引数および戻り値、呼び出し規約などを含む。より一般には、制御フロー特性は、グラフの形態、および／または、内容に影響を与える任意の態様に関連する。したがって、計装モジュール１５０は、計装モジュール１５０がグラフを更新された形式で維持できるように、一実施形態では、制御フロー特性を識別するために言及された監視および分析をリアルタイムで行う。

計装モジュール１５０は、一般に、ノードおよび有向エッジを表すためのプログラム要素を含む電子データ構造として、グラフを生成することに留意されたい。最初に、ひとつのアプローチでは、計装モジュール１５０は、ヌル値を含むグラフ、または、ソースコードが開発されるときに計装モジュール１５０が制御フローグラフを構築するための単なるエントリノードのみを生成する。このように、計装モジュール１５０は、グラフに対して調整／修正が行われると、グラフをリアルタイムで更新する。したがって、一実施形態では、計装モジュール１５０は、制御フロー特性を能動的に使用して、制御フローグラフを生成する。したがって、計装モジュール１５０は、ソースコードによって定義されるベースラインプログラムのリアルタイム評価を提供するために、修正／追加が発生するとグラフを区分的（断片的）に作成する。

さらに、計装モジュール１５０は、プロセッサによって実行されると、プロセッサ（たとえば、プロセッサ１１０）に、制御フローグラフにしたがってソースコード内に計装を統合させる命令を含む。たとえば、ひとつアプローチでは、計装モジュール１５０は、グラフによって参照されるように、ソースコードに計装を追加する。計装モジュール１５０は、一実施形態では、プログラムフローが保証される計装、および／または、計装がソースコードの特定のコードセグメントに関して別個の機能を提供する計装を含む。

前述したように、計装ポリシーは、ソースコードのどの態様（たとえば、計装の場所およびタイプを識別するための指標または他の条件を介して）を計装するかを識別するための様々なメカニズムを示す。様々な態様において、計装モジュール１５０に含まれる計装は、プログラムの実行が制御フローグラフにしたがうことを保証することによって、プログラム内でランタイムチェック（実行時チェック）を実施するためのものである。したがって、計装モジュール１５０は、一般に、プログラムフローを実施するための計装を含める方法を知るために、グラフを介して伝達されるプログラムフローの知識を使用する。さらに、計装モジュール１５０は、さらなる態様では、グラフを参照して、データフロー、危険な実行パスに沿った潜在的な障害状態、および、プログラム内に計装される他の態様を理解するために、グラフを参照する。このようにして、計装モジュール１５０は、計装プログラム１８０内のランタイムチェックを自動的に計装することにより、プログラムのセキュリティを向上する。さらに、計装モジュール１５０は、一実施形態では、アドレスチェック（たとえば、データおよびプログラムフローのためのメモリアドレス）、変数／関数の戻り値の型チェック、データバインドチェック、オペコードチェック、マッチコール−リターンペア（非単一クラス）など、を実行するための計装を含む。

いずれの構成においても、計装モジュール１５０は、ソースコードおよび制御フローグラフを分析して、計装をソースコード内に統合する。特に、計装モジュール１５０は、制御フローグラフとソースコードとの間の相関関係にしたがって計装されるべきソースコードのセグメント、たとえば、グラフ内の有向エッジによって識別されるソースコード内の手続き型遷移を識別する。さらに、計装モジュール１５０は、ソースコードにしたがってテンプレートの定義された計装をカスタマイズするために、定義された計装のテンプレートを修正することによって、識別（特定）されたセグメントにしたがって、計装を自動的に追加する。このようにして、定義された計装セットを、たとえば、追加された計装が要求どおりに動作することを保証するために、事前にテストして認定することができる。

さらに別の態様では、計装モジュール１５０は、ソースコードのタグ付け／ラベル付けされたセクションにしたがった計装を含む。たとえば、提供されるラベルは、制御フロー計装で計装されるべき高感度／高価値の関数を示すことができ、さらなる態様では、提供されるラベル／タグは、計装の特性を指定するものではなく、コードの一部が自動的に計装されるように計装モジュール１５０によって分析されるべきであることを単に示すものであってもよい。計装モジュール１５０は、ベースラインプログラムから計装プログラム１８０を自動的に生成するものとして説明されているが、もちろん、別のアプローチでは、計装プログラム１８０は二次ソースから取得され、したがって事前に計装される。さらに別の態様では、計装モジュール１５０は、他のセクションが先に含まれている間に、計装の少なくとも一部を計装プログラム１８０に追加する。

いずれの場合も、計装モジュール１５０は、様々なステートメントに関連する実行時間を決定するために、計装プログラム１８０を分析する命令を含む。最初の注記として、この明細書で使用される、サイクルカウント、実行時間、実行サイクル、および、他のそのような関連するフレーズはすべて、特定の命令または命令のセグメントによってプロセッサ、コントローラ、または、他の実行デバイス上で消費される時間の量を指す。一般に、プロセッサ／コントローラは、プロセッサ／コントローラ内で１秒間に実行される処理サイクル数を示す定義された周波数（たとえば、１００ＭＨｚ）で動作する。様々な命令が、プロセッサ／コントローラの命令キャッシュから実行され、その後リタイアされるために、異なる数のサイクルを使用することを理解されたい。ただし、別個の命令は、一般に、命令に関連する特定のタスク（たとえば、ＡＤＤ、ＪＵＭＰ、ＳＴＯＲＥ、ＬＯＡＤ、ＢＲＡＮＣＨなど）を実行するために使用されるサイクル数に関連して、プロセッサ／コントローラの帯域幅を消費する。したがって、一般的な問題として、別個の命令が、プログラムの全体的な実行時間に別個に寄与することがさらに理解されるべきである。

前述したように、計装ポリシーは、一実施形態では、サイクルカウントを、テンプレート内の計装の特定セグメントの特性として識別する。したがって、ひとつのアプローチでは、計装モジュール１５０が計装をプログラムに挿入すると、計装モジュール１５０は、計装が追加された（たとえば、プログラムフローに関連して）計装プログラム内の位置を、関連するサイクルカウントとともに追跡する。このようにして、計装モジュール１５０は、計装の個々のセグメントおよび計装が実行されるプログラムフロー内の相対的なポイントについて、予想される追加の実行時間を示すサイクルマッピングを開発する。一実施形態では、計装モジュール１５０は、計装プログラム内の異なる制御フローポイントで計装を直接参照し、サイクルカウントを示す手段を提供する方法として、制御フローグラフ内にサイクルマッピングを含む。

別の構成では、計装モジュール１５０は、試験環境で計装プログラム１８０を実行して、計装に関連する実行サイクルを追跡し、識別する。ひとつのアプローチでは、計装モジュール１５０は、計装プログラム１８０とベースラインプログラムとの比較を提供し、そこから、別個の計装命令に起因するプロセッサ／コントローラの実行時間を識別するために、テスト環境の一部としてベースラインプログラムを実行する。その結果、計装モジュール１５０は、計装に起因する実行時間の量を識別する。

いずれのアプローチが実行されても、計装モジュール１５０は、その後、実行時間を計装プログラム１８０と一致させるために拡張プログラム１７０を生成する。すなわち、計装プログラム１８０が実行されているとき、拡張プログラム１７０も、また、ベースラインプログラムに関連するプログラムフロー内の同一または類似のポイントで実行されている。計装プログラム１８０が計装ステートメントを実行している場合、拡張プログラム１７０は、Ｎｏ−Ｏｐ命令を実行するように構成される。Ｎｏ−Ｏｐ命令は、関連するハードウェア（たとえば、プロセッサまたはコントローラ）によって実装される命令であり、実行サイクルの間、ハードウェアが何もしないようにする。したがって、Ｎｏ−Ｏｐ命令は、計装プログラム１８０において計装が実行されている間、拡張プログラム１７０における実行を効果的に遅延させる。

したがって、計装モジュール１５０は、拡張プログラム１７０の実行と計装プログラムの実行とが一致するような方法で、拡張プログラムを生成するために、ベースラインプログラムにＮｏ−Ｏｐ命令を挿入する。一実施形態では、計装モジュール１５０は、制御フローグラフ、および／または、サイクルマッピングを使用して、拡張プログラム１７０を生成するためにベースラインプログラムに挿入されるＮｏ−Ｏｐ命令の場所、数、および他の特性を決定する。したがって、実行モジュール１３０が計装プログラム１８０を拡張プログラム１７０と並列に実行する場合、ふたつのプログラムは、計装プログラム１８０が計装を実行しているときに、Ｎｏ−Ｏｐ命令を実行に代入する拡張プログラムと同期して（ロックステップで）実行される。

したがって、一実施形態では、実行モジュール１３０は、計装プログラム１８０および拡張プログラムを並列に実行するように機能する命令を含む。一般に、実行モジュール１３０は、実行が同時かつ並列であることを保証するために、同時に実行を開始するようにプログラムを制御する。さらに、実行モジュール１３０は、一態様では、ふたつのプログラムの初期状態も一致させる。したがって、実行モジュール１３０は、ふたつのプログラムが同様に開始されることを確実にするために、ひとつ以上のメモリ位置を初期化して同じ値を格納することができる。

さらに、前述したように、計装プログラム１８０および拡張プログラム１７０は、たとえば、別個のコントローラ、コントローラと仮想マシンとの組み合わせ、または、ウォッチドッグモジュール１４０が実行を監視できるような別の適切な構成上で実行される。したがって、実行モジュール１３０は、プログラムがロックステップで（すなわち、ベースラインプログラムに対して同じポイントで一緒に並列に）実行されることを保証するために、コントローラを制御するか、さもなければアクセスすることができる。また、拡張プログラム１７０がマイクロプロセッサ上の仮想マシン上で実行される場合、実行モジュール１３０は、ふたつのプログラムの実行が一致するように、仮想マシンがコントローラと同様の特性（たとえば、同じクロック周波数）で構成されることを保証するために、仮想マシンおよび拡張プログラムを制御する。いずれにしても、実行モジュール１３０は、一般に、計装プログラム１８０および拡張プログラム１７０の実行環境の態様が対応していることを保証するように機能し、プログラムは、計装の有無を除いて実行が同一であることを保証するために、実質的に同じ状況内で実行することができる。

したがって、ウォッチドッグモジュール１４０は、一実施形態では、計装プログラム１８０および拡張プログラム１７０の実行を監視するように機能する命令を含む。一般に、ウォッチドッグモジュール１４０は、不一致または許容可能な既知の範囲外にある値について、プログラムの入力、出力、および内部状態を監視する。たとえば、図４に示すように、計装プログラム１８０および拡張プログラム１７０は、実行環境４００内で実行される。実行環境４００は、プログラム１７０および１８０が実行する特定の構成の表現であり、別個のコントローラ、同じコントローラ上の別個のプロセス、離散的なコントローラおよび離散的なプロセッサ上の仮想マシン、または、別の適切な構成を含むことができる。いずれの場合も、実行環境４００は、ウォッチドッグモジュール１４０がプログラムの実行状態を取得するために各プログラムにアクセスできるように構成される。

したがって、ウォッチドッグモジュール１４０は、一実施形態では、ＡＰＩ、実行環境４００の構成、または、他の適切な手段を介して、実行状態（たとえば、内部値、入力、出力、メモリアドレスなど）にアクセスする。各プログラムの実行状態とは、プログラムの実行にともなって変化する変数の値を指す。したがって、一実施形態では、実行状態は、入力値、出力値、制御引数値、非制御引数値、プログラム内の中間計算値などの組み合わせを含む。監視される実行状態を形成する値は、特定の実施形態に応じて変化し得るが、一般に、プログラムの実行に関連する値の任意の組み合わせを含み得ることを理解されたい。

ウォッチドッグモジュール１４０は、一実施形態では、取得された実行状態を比較して、プログラム障害、エラー、または、他の異常が存在するか否かを判断する。ひとつのアプローチでは、ウォッチドッグモジュール１４０は、実行環境（たとえば、図４に示すような環境４００）を介して、計装プログラム１８０および拡張プログラム１７０の内部値にアクセスする。そして、ウォッチドッグモジュール１４０は、たとえば、各実行サイクルにおいて実行状態を形成する値を比較する。

さらに、一態様では、ウォッチドッグモジュール１４０は、また、少なくとも計装プログラム１８０からの値を、値の可能な範囲のマップと比較して、値が合理的な範囲内にあるかどうかを決定する。すなわち、たとえば、ウォッチドッグモジュール１４０、および／または、実行モジュール１３０は、たとえば、記録された値の履歴に基づいて、異なる実行状態に対する値の範囲を決定する。この履歴を用いて、ウォッチドッグモジュール１４０は、値を分析し、それらが範囲内にあるか否かを判断する。

したがって、ウォッチドッグモジュール１４０が、プログラム間の実行状態が不一致である（すなわち、等しくない）、または、値が可能な値の範囲内（許容範囲内）にないと判断した場合、ウォッチドッグモジュール１４０は、不一致を管理する。ひとつのアプローチでは、ウォッチドッグモジュール１４０は、問題のあるプログラムのコントローラ（すなわち、計装プログラム１８０のコントローラ）をリセットすることにより、不一致を管理する。もちろん、リセットが発生すると、ふたつのプログラムが一致した状態で並列に実行され続けることを保証するために、拡張プログラムもリセットされる。さらなるアプローチでは、ウォッチドッグモジュール１４０は、プログラムをリセットするために、メモリ値（たとえば、入力、内部値、プログラムカウンタなど）をリセットする。このようにして、監視制御システム１００は、プログラム障害の処理（取り扱い）を改善するために、計装プログラムを監視および管理する。

図５は、プログラムのソースコードを自動的に計装することに関連する方法５００を示している。方法５００は、図１の監視制御システム１００の観点から説明される。方法５００は、監視制御システム１００と組み合わせて説明されるが、方法５００は、監視制御システム１００内で実施されることに限定されず、代わりに、方法５００を実施することができるシステムの一例であることを理解されたい。

５１０で、計装モジュール１５０は、プログラムのソースコードに追加されるコードセグメントを監視し、定期的に検出する。この明細書で使用されるように、５１０におけるコードセグメントの追加は、一般に、新しいコードセグメントを追加すること、および、プログラムのソースコード内の既存のコードセグメントを修正することを指すことに留意されたい。さらに、制御フローグラフの生成およびプログラムの計装は、リアルタイムで発生するものとして説明されているが、さらなる態様では、これらの機能は、たとえば、プログラムが完了したとき、および／または、コンパイルの準備ができたときに生成される離散的な要求に応答して発生してもよい。

計装モジュール１５０は、ソースコードへの変更をともなう入力（たとえば、コード、コマンドなど）について、コンピューティングデバイス内の統合開発環境（ＩＤＥ）への電子入力ストリームを監視する。したがって、計装モジュール１５０は、一実施形態では、ソースコードがいつ修正（すなわち、追加または変更）されるかを識別するために、ＡＰＩを介してＩＤＥへの入力ストリームを継続的に監視する。その結果、言及された修正、または、ソースコードを分析するための離散的な要求を検出すると、実行モジュール１３０は、ブロック５２０での制御フロー特性の識別に進む。

５２０で、計装モジュール１５０は、ソースコードの制御フロー特性を識別する。一実施形態では、計装モジュール１５０は、ソースコード内のステートメントをトラバース（走査）するために深さ優先探索を使用して、ベースラインプログラムのソースコードを分析する。さらなる態様では、計装モジュール１５０は、ソースコードをトラバースし、理解され得るような特性を識別するための他の適切なアプローチを実装する。計装モジュール１５０がソースコードをトラバースしているとき、計装モジュール１５０は、ソースコード内のステートメントを解析して、少なくとも関数呼び出し、関数リターンアドレス、具象関数またはシンボリック関数の引数、関数戻り値、および、ステートメント間の関係を制御フロー特性として識別する。

様々な実施形態では、実行モジュール１３０は、５１０で検出されたコードセグメント／変更に関連するソースコードの影響を受けた部分を分析し、さらなる態様では、計装モジュール１５０は、変更に応答して制御フロー特性を識別するために、ソースコード全体を再分析する。一般に、採用されるアプローチは、ソースコードの特性、システム１００で定義されたプリファレンス（好み）、および、分析を実行するために利用可能なリソースに関連する。計装モジュール１５０によって実行されるいずれのアプローチであっても、制御フロー特性を抽出することは、グラフに表されるプログラムの手順内、および／または、手順間の制御フロー転送に関する情報を提供する。一実施形態では、さらなる態様は、非制御データ引数、障害ツリーなどのような制御フロー特性の一部として識別されてもよい。いずれの場合も、実行モジュール１３０は、グラフに含めるために、制御フロー特性内のプログラムフローに直接的および間接的に関連する態様を含むことができる。

５３０で、計装モジュール１５０は、制御フローグラフを更新する。一実施形態では、計装モジュール１５０は、グラフのノードおよび有向エッジを形成するために、５２０で識別される制御フロー特性を使用する。制御フローグラフは、一般に、ベースラインプログラムの実行パスを表し、したがって、計装モジュール１５０は、制御フロー特性を使用して、グラフが形成される異なるコードセグメント（たとえば、ノード）間のパス（たとえば、有向エッジ）を識別する。したがって、計装モジュール１５０は、コードセグメントに対応するように制御フローグラフの既存のノードおよびエッジを修正しながら、検出されたコードセグメントに対応する制御フロー特性を追加することにより、制御フローグラフを更新する。すなわち、たとえば、既存の有向エッジは、追加ノードを追加しながら再ルーティングされてもよく、既存のノードは修正されてもよく、指示された条件は修正されてもよく、または新たな条件が追加されてもよい。

５４０で、計装モジュール１５０は、ソースコードを計装する要求を監視し、検出する。様々な実施形態では、要求は、異なる形式をとることができる。たとえば、ひとつのアプローチでは、要求は、グラフが修正されるソースコードに対する修正と一致する。すなわち、ソースコードの修正に応じてグラフが更新されると、計装モジュール１５０は、また、追加されたコードセグメントまたは既存のコードセグメントに対する変更のために計装が含まれる場合、修正のためにリアルタイムでソースコードを計装するように機能する。あるいは、計装要求は、離散的な要求にしたがって、ソースコードが完了したとき、または、さらなる態様では、ソースコードがプログラムにコンパイルされるときに、システム１００によって生成される。したがって、ソースコードの計装要求は、一実施形態では、ＩＤＥ内で生成されたソースコードをコンパイルする要求に応答してシステム１００によって生成され、コンパイルの前に実行される。

５５０で、計装モジュール１５０は、計装されるべきソースコードのコードセグメントを識別する。一実施形態では、計装モジュール１５０は、ソースコード内のセグメントに配置された既存のタグ、コードセグメントに関連付けられたグラフ内のラベル付けされた特性、制御フローグラフ内で表される識別された制御フロー、および／または、計装ポリシーによって定義されたさらなる指標／特性にしたがって、コードセグメントを識別する。一般に、計装モジュール１５０は、プログラムフローの完全性、データの完全性、および実行中のプログラムの他の態様、たとえば悪意のあるリダイレクトを防止することを含む、を確保するために、ソースコードを計装する。このように、計装モジュール１５０は、関数間の制御の転送、プログラムフローアドレスの調整、および、他のそのようなコードセグメントに関与するコードセグメントを識別する。一般に、言及されたコードセグメントは、グラフ内の有向エッジ、または、有向エッジによって具現化される転送に関連する条件に関連付けられる。

５６０で、計装モジュール１５０は、計装をベースラインプログラムのソースコード内に統合して、計装プログラム１８０を形成する。前述したように、一実施形態では、計装モジュール１５０は、様々な障害および／または攻撃に対するプログラムの回復力を向上させるプログラム内のランタイムチェックを実施するために、制御フローグラフにしたがった計装を含む。すなわち、ソースコードに追加される計装は、グラフで表される実行パスの外部にプログラムがリダイレクトされないこと、プログラムに関連付けられたデータが悪意を持って操作されないこと、などを保証する。

さらに、計装を統合するプロセスは、一実施形態では、計装を受け取るソースコード内のそれぞれの位置にしたがって、定義された計装のテンプレートを修正することにより、計装を自動的に追加する計装モジュール１５０を含む。前述したように、計装モジュール１５０は、計装が統合されているコードセグメントに適合するように、テンプレートの可変アスペクトを調整する。したがって、計装モジュール１５０は、特定の機能を達成するために、含まれる計装をカスタマイズする。このようにして、計装モジュール１５０は、制御フローグラフを使用して、安全なプログラムフローを保証することにより、最終的に得られるプログラムを改善する追加機能を提供する。しかしながら、追加された計装は、問題が発生する場合があり、プログラムの全体的な実行時間を増加させる。

このように、５６０での計装統合の一部として、計装モジュール１５０は、一実施形態では、計装プログラム１８０を形成するためにベースラインプログラムに追加された計装の位置および実行サイクルカウントを格納するサイクルマッピングを生成することにより、様々な計装命令の統合を追跡する。あるいは、計装モジュール１５０は、プログラム内の様々な実行ポイントで計装によって消費される可能性が高い実行サイクルについてのその後の分析／予測を提供するために、計装命令の少なくとも場所およびタイプを追跡する。このようにして、計装モジュール１５０は、前述したように、拡張プログラム１７０をその後に生成するための追加の手段を提供する。

図６は、プログラム内の潜在的な障害を識別し、処理することに関連する方法６００を示している。図５同様、方法６００は、図１の監視制御システム１００の観点から説明される。方法６００は、監視制御システム１００と組み合わせて説明されるが、方法６００は、監視制御システム１００内で実施されることに限定されず、代わりに、方法６００を実施することができるシステムの一例であることを理解されたい。

６１０で、実行モジュール１３０は、拡張プログラム１７０および計装プログラム１８０を並列に実行する。一実施形態では、実行モジュール１３０は、プログラム１７０および１８０を並列に実行するように制御する。すなわち、実行モジュール１３０は、たとえば、プログラム１７０および１８０がロックステップで実行されるように（すなわち、ベースラインプログラムに対して同じポイントで、命令のための命令（instruction for instruction））、プログラム１７０および１８０を同時に開始（起動）する。前述したように、拡張プログラム１７０は、拡張プログラム１７０が計装プログラム１８０と同じ数の実行サイクルを消費するように、遅延命令を含むように修正される。したがって、同時に開始され、同じ値のセットを使用する場合、プログラム１７０、１８０は、実行において互いに並列に実行される（すなわち、ベースラインプログラムからの同じ共有命令を同時に実行する）。

さらに、実行モジュール１３０は、別個のデバイス（装置）上でプログラム１７０および１８０の実行を制御することができる。すなわち、実行モジュール１３０は、一実施形態では、計装プログラムを実行するために電子制御ユニット（ＥＣＵ）と、拡張プログラム１７０を実行するために仮想マシンを実行する別のＥＣＵまたはプロセッサ（たとえば、プロセッサ１１０）と、を制御する。いずれの構成においても、プログラム１７０および１８０は、同時にかつ並列に、実質的に同一の実行時間にしたがって実行される。

６２０で、ウォッチドッグモジュール１４０は、プログラム間の実行状態の不一致（ミスマッチ）を識別するために、６１０における並列実行を監視する。一実施形態では、ウォッチドッグモジュール１４０は、拡張プログラム１７０および計装プログラム１８０に関連付けられた入力値、中間値、および出力値を監視する。さらなる態様では、ウォッチドッグモジュール１４０は、また、値に対して定義された可能な範囲（所定の許容範囲）にしたがって、実行状態を形成する上記した値を監視する。すなわち、ウォッチドッグモジュール１４０は、たとえば、プログラムのテスト、検証された実行中のプログラムの追跡などを通じて、様々な実行状態についての期待される／可能な値の範囲を取得する。ウォッチドッグモジュール１４０は、値の範囲が導出されるこの監視から観測値の履歴ログを生成することができる。

さらに、ウォッチドッグモジュール１４０によるプログラム１７０および１８０の観測値の比較は、一般に、計装プログラム１８０の値が拡張プログラム１７０と一致しない場合を識別するために行われる。このような一致の欠如は、一般に、プログラム１８０の障害の発生、障害の開始、または、プログラム１８０の障害をもたらす可能性のある別の異常を示す。さらなる態様では、ウォッチドッグモジュール１４０は、定義された指標（メトリック）にしたがって比較を行うことができる。たとえば、ウォッチドッグモジュール１４０は、定義されたパーセンテージの変動を、実行状態内の同じ値とみなされるものとして受け入れることができる。パーセンテージは、提供された値に存在するエラー（誤差）または固有の変動のマージンにしたがって定義できる。

６２０において不一致を識別すると、６３０で、ウォッチドッグモジュール１４０は、関連するデバイス（たとえば、コントローラおよび関連するデバイス／システム）の機能に対する関連するプログラム障害の影響を軽減するように、不一致状態を管理する。一実施形態では、ウォッチドッグモジュール１４０は、プログラム１８０を実行しているコントローラをリセットすることによって不一致を管理する。一般に、コントローラをリセットすると、実行状態がリセットされ、プログラム障害が解決される。すなわち、リセットは、メモリから不一致状態を効果的にクリアし、プログラム１７０および１８０を再起動する。さらに、ウォッチドッグモジュール１４０は、さらなる実施形態では、後続の分析のために不一致の実行状態をログに記録する、プログラム１７０および１８０に関連付けられたメモリ位置をリセットする、および、プログラム１８０によって提供されるサービスが長期間中断されないようにプログラム１７０および１８０を再初期化するなどの追加のアクションを実行する。

さらに、ひとつ以上の実施形態では、監視制御システム１００は、ＩＳＯ２６２６２などの機能安全規格にしたがって、プログラム１７０および１８０の並列実行および監視を実施することに留意されたい。

さらに、図１の監視制御システム１００は、別個の集積回路、および／または、チップを用いて様々な構成によって構成できることが理解されるべきである。そのような実施形態では、図１の実行モジュール１３０は、別個の集積回路として具現化される。さらに、ウォッチドッグモジュール１４０は、個々の集積回路上に具現化される。さらに、計装モジュール１５０は、別個の集積回路上に具現化される。回路は接続パスを介して接続され、別個の回路間で信号を通信する。もちろん、別個の集積回路が論じられているが、様々な実施形態では、回路は、共通の集積回路基板に統合されてもよい。さらに、集積回路は、より少ない集積回路に組み合わせるか、またはより多くの集積回路に分割することができる。別の実施形態では、モジュール１３０、１４０、および１５０は、別個の特定用途向け集積回路に組み合わされてもよい。さらなる実施形態では、モジュール１３０、１４０、および１５０に関連する機能の一部は、プロセッサによって実行可能であり、非一時的メモリに格納されてもよい。さらなる実施形態では、モジュール１３０、１４０、および１５０は、プロセッサ１１０のハードウェアコンポーネントとして統合される。

別の実施形態では、説明された方法、および／または、それらの等価物は、コンピュータ実行可能命令で実装されてもよい。このように、一実施形態では、非一時的コンピュータ可読媒体は、機械（たとえば、プロセッサ、コンピュータなど）によって実行されると、機械（および／または、関連するコンポーネント）に方法を実行させる、コンピュータ実行可能命令を記憶した状態で構成される。

（
説明を簡単にするために、図に示されている方法論は一連のブロックとして示され説明されているが、いくつかのブロックは異なる順序で実行されることがあり、および／または、図示および説明から他のブロックと同時に実行されることがあり、方法論はブロックの順序によって制限されないことが理解されるべきである。さらに、例示的な方法論を実施するために、図示されたすべてのブロックよりも少ない数のブロックが使用されてもよい。ブロックは、複数のコンポーネントに結合、または、分離されることがある。さらに、追加の、および／または、代替の方法論は、図示されていない追加のブロックを使用することができる。

監視制御システム１００は、ひとつ以上のプロセッサ１１０を含むことができる。ひとつ以上の構成では、プロセッサ１１０は、監視制御システム１００のメインプロセッサであり得る。たとえば、プロセッサ１１０は、電子制御装置（ＥＣＵ）であり得る。監視制御システム１００は、ひとつ以上のタイプのデータを格納するためのひとつ以上のデータストアを含むことができる。データストアは、揮発性、および／または、不揮発性メモリを含むことができる。適切なデータストアの例には、ＲＡＭ（ランダムアクセスメモリ）、フラッシュメモリ、ＲＯＭ（リードオンリーメモリ）、ＰＲＯＭ（プログラマブルリードオンリーメモリ）、ＥＰＲＯＭ（消去可能プログラマブルリードオンリーメモリ）、ＥＥＰＲＯＭ（電気的消去可能プログラマブルリードオンリーメモリ）、レジスタ、磁気ディスク、光ディスク、ハードドライブ、分散メモリ、クラウドベースのメモリ、開示されたデータを格納するのに適した他の記憶媒体、または、それらの任意の組み合わせが含まれる。データストアは、プロセッサ１１０のコンポーネントとすることができ、またはデータストアは、使用のためプロセッサ１１０に動作可能に接続することができる。この説明全体を通して使用される「動作可能に接続された」という用語は、直接的な物理的接触のない接続を含む、直接または間接の接続を含みえる。

この明細書では詳細な実施形態が開示されている。しかしながら、開示された実施形態は、例としてのみ意図されていることが理解されるべきである。したがって、この明細書に開示される特定の構造的および機能的詳細は、限定事項として解釈されるべきではなく単に請求項の基礎として、および、実質的に任意の適切な詳細な構造でこの明細書の態様を様々に使用することを当業者に教示するための代表的な基礎としてのみ解釈されるべきである。さらに、この明細書で使用される用語および語句は、限定することを意図するものではなく、可能な実装の理解可能な説明を提供することを意図している。種々の実施形態が図１〜図６に示されているが、実施形態は、図示された構造または用途に限定されない。

図中のフローチャート、および、ブロック図は、様々な実施形態による、システム、方法、および、コンピュータプログラム製品の可能な実装のアーキテクチャ、機能、および、動作を示している。これに関して、フローチャート、または、ブロック図の各ブロックは、指定された論理機能を実装するためのひとつ以上の実行可能な命令を構成するコードのモジュール、セグメント、または、部分を表すことができる。また、一部の代替実装では、ブロックに記載されている機能が、図に記載されている順序とは異なる順序で発生する場があることにも注意されるべきである。たとえば、連続して示されたふたつのブロックは、実際には実質的に同時実行されてもよいし、関係する機能に応じて、ブロックが逆の順序で実行されてもよい。

上記のシステム、コンポーネント、および／または、プロセスは、ハードウェア、または、ハードウェアとソフトウェアの組み合わせで実現でき、ひとつの処理システムで集中方式によって、または、複数の相互接続された処理システムに異なる要素が分散している分散方式によって実現することができる。この明細書に記載の方法を実行するように適合されたあらゆる種類の処理システム、または、別の装置が適している。ハードウェアとソフトウェアの組み合わせは、コンピュータで使用可能なプログラムコードを備えた処理システムであり、読み込まれて実行されると、ここで説明する方法を実行するように処理システムを制御する。システム、コンポーネント、および／または、処理は、たとえば、機械によって読み取り可能であって、ここに記述された処理、および、方法を実行するために機械によって実行可能な指令のプログラムに実体的に実装された、コンピュータプログラム製品の記憶装置、または、他のデータプログラムの記憶装置として、コンピュータによって読み取り可能な記憶装置に埋め込むことができる。これらの要素は、この明細書に記載の方法の実施を可能にし、処理システムにロードされたときにこれらの方法を実行できるすべての機能を含むアプリケーション製品に組み込むこともできる。

さらに、この明細書で説明された構成は、たとえば記憶されるなどして、実施されるコンピュータ可読プログラムコードを有するひとつ以上のコンピュータ可読媒体に具現化されるコンピュータプログラム製品の形をとることができる。ひとつ以上のコンピュータ可読媒体の任意の組み合わせが利用されてもよい。コンピュータ可読媒体は、コンピュータ可読信号媒体またはコンピュータ可読記憶媒体であり得る。「コンピュータ可読記憶媒体」という語句は、非一時的な記憶媒体を意味する。コンピュータ可読媒体は、限定されるものではないが、不揮発性媒体および揮発性媒体を含む、形態をとってもよい。不揮発性媒体には、たとえば、光ディスク、磁気ディスクなどが含まれる。揮発性媒体には、たとえば、半導体メモリ、ダイナミックメモリなどが含まれる。そのようなコンピュータ可読媒体の限定的ではない例には、フロッピーディスク、フレキシブルディスク、ハードディスク、磁気テープ、および、その他の磁気媒体、または、ＡＳＩＣ、または、グラフィックス処理装置（ＧＰＵ）のキャッシュまたは他のメモリ、ＣＤ、その他の光学媒体、ＲＡＭ、ＲＯＭ、メモリチップまたはメモリカード、メモリスティック、および、コンピュータ、プロセッサ、または、他の電子デバイスが読み取り可能な媒体があげられるが、これらに限定されない。この明細書の文脈において、コンピュータ可読記憶媒体は、命令実行システム、機器、またはデバイス（装置）によって、またはそれに関連して使用するためのプログラムを含むか、または、記憶することができる任意の有形の媒体であり得る。

以下の説明は、この明細書で使用される選択された用語の定義を含んでいる。定義には、用語の範囲に含まれ、様々な実装に使用できるコンポーネントの様々な例や形式が含まれている。例は、制限することを意図したものではない。用語の単数形と複数形の両方が定義内にある場合がある。

「ひとつの実施形態」、「一実施形態」、「ひとつの例」、「一例」などへの言及は、そのように説明された実施形態、または、例が、特定の特徴、構造、特性、内部特性、要素、または、制限を含み得ることを示すが、それらの実施形態、または、例が、必須のものとして、特定の特徴、構造、特性、内部特性、要素、または、制限を含むことを示すものではない。さらに、「一実施形態では」という語句の繰り返しの使用は、同じ実施形態を指す場合があるが、必ずしもそうであるとは限らない。

この明細書で使用される「モジュール」は、コンピュータ、または、電気ハードウェアコンポーネント、ファームウェア、命令を格納する非一時的なコンピュータ可読媒体、および／または、これらのコンポーネントの組み合わせを含み、これらは、機能、または、アクションを実行するか、および／または、別のロジック、方法、および／または、システムに、機能、または、アクションを発揮させるように構成されている。モジュールは、アルゴリズムによって制御されるマイクロプロセッサ、多数の電気素子を含む論理回路（たとえば、ＡＳＩＣ）、アナログ回路、デジタル回路、プログラムされた論理デバイス、実行時にアルゴリズムを実行する命令を含むメモリデバイスなどを含むことができる。モジュールは、ひとつ以上の実施形態では、ひとつ以上のＣＭＯＳゲート、ゲートの組み合わせ、または他の回路構成要素を含む。複数のモジュールが説明される場合、ひとつ以上の実施形態は、複数のモジュールをひとつの物理モジュール構成要素に組み込むことを含む。同様に、単一のモジュールが説明される場合、ひとつ以上の実施形態は、複数の物理的構成要素に、単一のモジュールを分配することを含む。

さらに、この明細書で使用されるモジュールには、タスクを実行したりデータ型を実装したりするルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。さらなる態様では、メモリは、一般に、言及されたモジュールを格納する。モジュールに関連付けられたメモリは、プロセッサ、ＲＡＭ、ＲＯＭ、フラッシュメモリ、または、別の適切な電子記憶媒体内に埋め込まれたバッファ、または、キャッシュである場合ある。さらに別の態様では、この開示によって想定されるモジュールは、特定用途向け集積回路（ＡＳＩＣ）、ＧＰＵ、システムオンチップ（ＳｏＣ）のハードウェアコンポーネント、プログラマブルロジックアレイ（ＰＬＡ）、または、開示された機能を実行するための定義された構成セット（たとえば、命令）が組み込まれた別の適切なハードウェアコンポーネントとして実装される。

ひとつ以上の構成では、この明細書で説明されるひとつ以上のモジュールは、人工知能要素、または、計算知能要素、たとえば、ニューラルネットワーク、ファジーロジック、または、他の機械学習アルゴリズムを含むことができる。さらに、ひとつ以上の構成では、ひとつ以上のモジュールを、この明細書で説明する複数のモジュール間で分散させることできる。ひとつ以上の構成では、この明細書で説明されているふたつ以上のモジュールを組み合わせて単一のモジュールにすることができる。

コンピュータ可読媒体上で実施されるプログラムコードは、無線、有線、光ファイバ、ケーブル、ＲＦなど、または、前述要素の任意の適切な組み合わせを含むがこれらに限定されない任意の適切な媒体を使用して送信することができる。この構成の態様の動作を実行するためのコンピュータプログラムコードは、Ｊａｖａ（登録商標）、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋などのオブジェクト指向プログラミング言語、および、Ｃプログラミング言語、同様のプログラミング言語などを含む従来の手続き型プログラミング言語を含むひとつ以上のプログラミング言語の任意の組み合わせで書くことができる。プログラムコードは、完全にユーザのコンピュータにおいて、一部はユーザのコンピュータにおいて、スタンドアロンソフトウェアパッケージとして、一部はユーザのコンピュータにおいて、残る一部はリモートコンピュータにおいて、または、完全にリモートコンピュータ、または、サーバーで実行することができる。後者のシナリオでは、リモートコンピュータは、ローカルエリアネットワーク（ＬＡＮ）、または、ワイドエリアネットワーク（ＷＡＮ）を含む任意のタイプのネットワークを介してユーザのコンピュータに接続されてもよく、または接続は、外部コンピュータ（たとえば、インターネットサービスプロバイダを使用してインターネットを介して）に接続されてもよい。

この明細書で使用される要素の数は、ひとつ、または、ふたつ以上として定義される。この明細書で使用される「複数」という用語は、ふたつ、または、ふたつ以上として定義される。この明細書で使用される「別の」という用語は、少なくとも第２、または、それ以上として定義される。この明細書で使用される「含む」、および／または、「有する」という用語は、「備える」を意味し、すなわち、他の要素の存在を許容する用語として定義される。「・・・と・・・との少なくともひとつ」という表現は、関連付けて列挙された項目のひとつ、または、複数のありとあらゆる可能な組み合わせを指し、それらを包含するものとして解釈されるべきである。一例として、「Ａ、Ｂ、および、Ｃのうちの少なくともひとつ」という語句は、Ａのみ、Ｂのみ、Ｃのみ、またはそれらの任意の組み合わせ（たとえば、ＡＢ、ＡＣ、ＢＣ、または、ＡＢＣ）を含む。

この明細書の態様は、その精神、または、本質的な属性から逸脱することなく、他の形態で具体化することができる。したがって、この明細書の範囲を示すために、前述の明細書ではなく、以下の特許請求の範囲を参照する必要がある。

Claims (20)

1. プログラム障害の検出を改善するための監視制御システムであって、
   ひとつ以上のプロセッサ（１１０）と、
   ひとつ以上の前記プロセッサに通信可能に結合されたメモリ（１２０）と、
   前記メモリに格納された実行モジュール（１３０）およびウォッチドッグモジュール（１４０）と、を備え、
   前記実行モジュールは、ひとつ以上の前記プロセッサによって実行されると、ひとつ以上の前記プロセッサに、拡張プログラムおよび計装プログラムを並列に実行させる命令を含み、
   前記計装プログラムは、ランタイムチェックを実施するベースラインプログラムの計装バージョンであり、
   前記拡張プログラムは、実行時間を前記計装プログラムと一致させるために前記ベースラインプログラムのソースコードに意図的な遅延が挿入された、前記ベースラインプログラムの拡張バージョンであり、
   前記ウォッチドッグモジュールは、ひとつ以上の前記プロセッサによって実行されると、ひとつ以上の前記プロセッサに、前記拡張プログラムと前記計装プログラムとの間の不一致状態の発生を識別するために、前記計装プログラムの実行状態を監視させる命令を含み、
   前記ウォッチドッグモジュールは、関連デバイスの機能に対するプログラム障害の影響を軽減するために、不一致状態を管理させる命令を含む、監視制御システム。
2. 前記ウォッチドッグモジュールは、前記不一致状態を管理する命令として、前記拡張プログラムおよび前記計装プログラムが実行されている前記関連デバイスのコントローラをリセットする命令を含み、前記ウォッチドッグモジュールは、前記プログラム障害を解決するために前記実行状態をリセットすることによって前記コントローラをリセットする命令を含む、請求項１に記載の監視制御システム。
3. 前記ウォッチドッグモジュールは、前記計装プログラムおよび前記拡張プログラムの実行状態を監視する命令として、前記拡張プログラムおよび前記計装プログラムの実行中に、前記拡張プログラムおよび前記計装プログラムに関連付けられた入力値、中間値、および出力値を監視する命令を含む、請求項１に記載の監視制御システム。
4. 前記ウォッチドッグモジュールは、前記実行状態を監視する命令として、前記不一致状態として報告される差分を識別するために、前記拡張プログラムと前記計装プログラムとの間で前記入力値、前記中間値、および前記出力値を比較する命令を含む、請求項３に記載の監視制御システム。
5. 前記ウォッチドッグモジュールは、前記実行状態を監視する命令として、前記不一致状態を識別するために、前記入力値、前記中間値、および前記出力値を、所定の許容範囲の値と比較する命令を含む、請求項３に記載の監視制御システム。
6. 前記実行モジュールは、前記拡張プログラムおよび前記計装プログラムを並列に実行する命令として、前記拡張プログラムおよび前記計装プログラムを別々のデバイス上で実行する命令を含む、請求項１〜５のいずれか１項に記載の監視制御システム。
7. 前記拡張プログラムは、前記計装プログラム内の計装によって消費される実行サイクルを説明するために、所定のサイクル数の間、前記関連デバイスが何もしないようにするＮｏ−Ｏｐ命令である意図的な遅延を含み、
   前記ランタイムチェックは、前記計装プログラムを作成するための前記ベースラインプログラムのソースコードに計装を含めることによって、前記計装プログラム内に実装され、
   前記ランタイムチェックは、前記計装プログラムに関連する少なくともメモリの破損を防止する、請求項１〜６のいずれか１項に記載の監視制御システム。
8. 前記実行モジュールは、第１のコントローラ上で前記拡張プログラムを実行する命令と、第２のコントローラ上で前記計装プログラムを実行する命令とを含み、前記第１のコントローラおよび前記第２のコントローラは、前記関連デバイス内に埋め込まれている、請求項１〜５のいずれか１項に記載の監視制御システム。
9. プログラム障害の検出を改善するための命令を格納する非一時的コンピュータ可読媒体であって、
   ひとつ以上のプロセッサ（１１０）によって実行されると、ひとつ以上の前記プロセッサに、
   拡張プログラムおよび計装プログラムを並列に実行させる命令と、
   前記拡張プログラムと前記計装プログラムとの間の不一致状態の発生を識別するために、前記計装プログラムの実行状態を監視させる命令と、
   関連デバイスの機能に対するプログラム障害の影響を軽減するために、前記不一致状態を管理させる命令と、を含み、
   前記計装プログラムは、ランタイムチェックを実施するベースラインプログラムの計装バージョンであり、前記拡張プログラムは、実行時間を計装プログラムと一致させるためにベースラインプログラムのソースコードに意図的な遅延が挿入された、前記ベースラインプログラムの拡張バージョンである、非一時的コンピュータ可読媒体。
10. 前記不一致状態を管理する命令は、前記拡張プログラムおよび前記計装プログラムが実行されている前記関連デバイスのコントローラをリセットする命令を含み、
    前記コントローラをリセットする命令は、前記プログラム障害を解決するために前記実行状態をリセットする命令を含む、請求項９に記載の非一時的コンピュータ可読媒体。
11. 前記計装プログラムおよび前記拡張プログラムの実行状態を監視する命令は、前記拡張プログラムおよび前記計装プログラムの実行中に、前記拡張プログラムおよび前記計装プログラムに関連付けられた入力値、中間値、および出力値を監視する命令を含む、請求項９に記載の非一時的コンピュータ可読媒体。
12. 前記実行状態を監視する命令は、前記不一致状態として報告される差を識別するために、前記拡張プログラムと前記計装プログラムとの間の前記入力値、前記中間値、および前記出力値を比較する命令を含む、請求項１１に記載の非一時的コンピュータ可読媒体。
13. 前記拡張プログラムおよび前記計装プログラムを並列に実行する命令は、前記拡張プログラムおよび前記計装プログラムを別々のデバイス上で実行する命令を含む、請求項１１に記載の非一時的コンピュータ可読媒体。
14. プログラム障害の検出を改善するための方法であって、
    拡張プログラムおよび計装プログラムを並列に実行すること、
    前記拡張プログラムと前記計装プログラムとの間の不一致状態の発生を識別するために、前記計装プログラムの実行状態を監視すること、
    関連デバイスの機能に対するプログラム障害の影響を軽減するために、前記不一致状態を管理すること、を含み、
    前記計装プログラムは、ランタイムチェックを実施するベースラインプログラムの計装バージョンであり、前記拡張プログラムは、実行時間を計装プログラムと一致させるためにベースラインプログラムのソースコードに意図的な遅延が挿入された、前記ベースラインプログラムの拡張バージョンである、方法。
15. 前記不一致状態を管理することは、前記拡張プログラムおよび前記計装プログラムが実行されている前記関連デバイスのコントローラをリセットすることを含み、
    前記コントローラをリセットすることは、前記プログラム障害を解決するために前記実行状態をリセットすることを含む、請求項１４に記載の方法。
16. 前記計装プログラムおよび前記拡張プログラムの実行状態を監視することは、前記拡張プログラムおよび前記計装プログラムに関連づけられた入力値、中間値、および出力値を監視することを含む、請求項１４に記載の方法。
17. 前記実行状態を監視することは、前記不一致状態として報告される差を識別するために、前記拡張プログラムと前記計装プログラムとの間の前記入力値、前記中間値、および前記出力値を比較することを含む、請求項１６に記載の方法。
18. 前記実行状態を監視することは、前記不一致状態を識別するために、前記入力値、前記中間値、および前記出力値を、所定の許容範囲の値と比較することを含む、請求項１６に記載の方法。
19. 前記拡張プログラムおよび前記計装プログラムを並列に実行することは、前記拡張プログラムおよび前記計装プログラムを別々のデバイス上で実行することを含む、請求項１４に記載の方法。
20. 前記拡張プログラムは、前記計装プログラム内の計装によって消費される実行サイクルを説明するために、所定のサイクル数の間、前記関連デバイスが何もしないようにするＮｏ−Ｏｐ命令である意図的な遅延を含み、
    前記ランタイムチェックは、前記計装プログラムを作成するための前記ベースラインプログラムのソースコードに計装を含めることによって、前記計装プログラム内に実装され、
    前記ランタイムチェックは、前記計装プログラムに関連する少なくともメモリの破損を防止する、請求項１４〜１９のいずれか１項に記載の方法。

Images