JP2021535477A - フォールトツリー分析を使用して機能安全のため制御フローグラフを最適化するシステム及び方法 - Google Patents

Abstract

ここに記載のシステム、方法、および他の実施形態は安全関連機能のためのプログラムの制御フローを改善することに関する。一実施形態では、方法は、プログラムの安全関連機能を識別することを含む。安全関連機能は、関連する装置が機能安全基準に従って動作するかどうかに影響を与える、プログラムによって実行される機能と関連付けられている。方法は、安全関連機能のフォールトツリーをプログラムの制御フローグラフの関連部分に統合することを含む。制御フローグラフは、プログラム内の少なくとも手続き型の制御フローを識別し、フォールトツリーは、プログラムによって障害を生じさせるプログラム内の状態の組み合わせを示す。方法は、プログラムの制御フローを改善するための電子的出力として制御フローグラフを提供することを含む。

Description

関連出願の相互参照

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

本明細書に記載の主題は、概して、制御フローグラフを最適化するためのシステム及び方法に関し、特に、プログラムにおける安全関連機能を識別し、それに応じて制御フローグラフを最適化することに関する。

ソフトウェアプログラムの開発は、プログラムの完全性を脅かす可能性のある様々な観点を考慮した作業になり得る。例えば、プログラムは、データフロー、プログラムフローなどに関連する様々な脆弱性を含み得る。悪意のある攻撃者は、これらの脆弱性を悪用してデータを操作し、及び／又は、悪意を持ってプログラムをリダイレクトするかもしれない。この悪意のある操作により、ランタイムエラー、データ破壊、データ公開、認証機能のバイパスなど、プログラムによる意図しないアクションが起こり得る。さらに、プログラムは、プログラムのさまざまな内部状態の組み合わせに対応して、意図しない障害が発生するかもしれないという先天的な問題を含み得る。

そのため、プログラムが車両の制御や、他の安全性が重要である機能を提供すべきものである場合、近隣の個人（歩行者や車両の乗員など）の健康が危ぶまれる可能性が高くなるので、そのような攻撃や障害が問題となり得る。従って、これらの悪意のある攻撃や障害を防ぐために、プログラムがフォーマット、セキュリティに関する所望の基準、およびその他の基準に準拠していることを確保することは、特にプログラムが比較的複雑な場合（例えば、関数、データ構造の間に多くの様々な関係を含む、など）、非常に困難になる可能性がある。一般的に、開発者は、プログラムを最適化、および／またはプログラム内の異なる関数／セグメント間の関係をよりよく理解しようとして、制御フローグラフおよび／または他のツールを参照する場合がある。しかし、現在のアプローチでは、開発者が解釈するのが現実的ではない可能性のある大きく複雑なグラフが生成され、その結果、気付かれない脆弱性がプログラムに残ってしまう。同様に、悪意のある攻撃や障害に対するセキュリティを提供するために、プログラムのソースコードに計装を追加することは、開発をさらに複雑にする可能性がある。そのため、プログラムフローとプログラムの障害回復力の保護が不十分になり、プログラムが障害の影響を受けやすくなるとの結果を招く。

一実施形態において、制御フローグラフ内にフォールトツリーを統合することによって、安全関連機能を計装することに関連する例示的なシステム及び方法が開示される。前述のように、ソースコードの特定の態様を識別し、ランタイムチェックを提供するようにソースコードを計装する現在のアプローチは、アプローチが過度に複雑である、および／又は、手作業のサポートに大きく依存しているという問題を抱えているため、一般的に不十分である。

従って、一実施形態では、機能安全とプログラム内の様々なパスのプログラムフローの完全性の両方を確保するために、フォールトツリーと制御フローグラフを統合するフォールト制御システムが開示される。さらに、フォールト制御システムは、一実施形態において、統合制御フローグラフを使用して、プログラムフローを検証し、フォールトツリーで識別される障害状態を回避する、ランタイムチェックを備えたプログラムのソースコードの自動計装などの追加機能を提供する。

１つのアプローチでは、開示されるフォールト制御システムは、制御フローグラフとフォールトツリーの両方を並行して展開するように実行される。例えば、フォールト制御システムは、プログラムのソースコードを分析して制御フローの特性を識別すると同時に、ソースコード内の機能を分析して安全関連の機能を識別する。安全関連機能は、例えば、機能安全に関連するプログラムおよび／またはそのプログラムによって制御される関連装置の態様に潜在的に影響を与えるプログラムの機能である。一般的に、機能安全とは、人体への身体的傷害または装置自体の損傷のリスクに関係する、関連装置の安全な操作を指す。従って、安全関連機能には、例えば、車両を制御してブレーキをかける機能、または機能の障害／故障が発生した場合に傷害または損傷が生じる可能性がある他の機能を実行する機能が含まれ得る。

このように、フォールト制御システムは、フォールトツリー分析を実行することによって安全関連機能をさらに分析するために、それらの機能を識別する。フォールトツリー分析を通じて、フォールト制御システムはフォールトツリーを生成する。フォールトツリーは、一態様において、プログラム内で障害（例えば、誤った出力、重大な停止など）をもたらす可能性のあるプログラムの入力、内部状態、または他の状態の組み合わせを具現化する。フォールト制御システムは、概して、ブール論理を使用してフォールトツリー内のそのような故障／障害を表し、障害を発生させる状態の組み合わせを識別する。

さらに、フォールトツリーを作成すると同時に、フォールト制御システムは制御フローグラフも生成する。一般的に、フォールト制御システムは、プログラムのソースコードをリアルタイムで分析するか、プログラムの制御フロー特性を識別するための要求に応答して分析する。制御フロー特性は、一実施形態において、関数呼び出し、リターンアドレス、スタックポインタなどのような、プログラムの工程内および／または工程間の制御フロー（例えば、制御データ）に影響を与える態様を含む。さらなる特徴において、制御フロー特性には、非制御データ引数に関するデータ特性も含まれる。したがって、制御データを識別することに加えて、フォールト制御システムは、データ引数がインスタンス化されたとき、使用されたとき、変更されたときなど、関連付けられたデータ引数の状態に関連する態様を含む非制御データのデータ特性を識別してもよい。さらに、データ特性は、データ引数が渡される関数、どの関数がデータ引数を変更することができるかなど、データ引数に関連する関係も含んでもよい。

いずれの場合も、フォールト制御システムは、プログラムフロー及び制御フローの特性に従う他の注目すべき態様を表すために制御フローグラフを生成する。このように、フォールト制御システムは、ソースコードのさまざまな観点に関するノード、有向エッジ、およびノード内のタグ／メーカーを生成する。１つのアプローチでは、ソースコードが変更されると（例えば、修正される、調整されるなど）、制御フロー特性をさらに表すため、フォールト制御システムは、制御フローグラフに新しいセグメントの追加、及び／又は、既存のセグメントの変更も行うように、フォールト制御システムは、制御フローグラフをリアルタイムで動的に更新する。

このようにして、フォールト制御システムは、一実施形態において、制御フローグラフを使用してプログラムの重要な態様をさらに識別するために、フォールトツリーを制御フローグラフに統合する。１つの特徴では、フォールト制御システムは、制御フローグラフのノード／エッジにフォールトツリーによって識別された状態を用いて注釈を付けることによってフォールトツリーを統合する。従って、フォールトツリーによって識別された状態に関連付けられたソースコードの様々なブロックに制御フローグラフ内で注釈が付けられ、特定の状態／出来事によって障害が発生する可能性のある制御フローグラフの危険なパスをさらに識別する。

その結果、制御フローグラフは、単一の拡張データ構造内にプログラムのさまざまな重要な態様を具体化する。このように、フォールト制御システムは、一実施形態において、追加の機能を容易にするために、制御フローグラフをさらなるモジュール／システムに提供する。例えば、一実施形態において、フォールト制御システムは、ソースコードを自動的に計装するメカニズムとして制御フローグラフを使用する。制御フローグラフは、計装されるべき他の態様に加えて、安全関連機能に関する情報を含むように生成されるため、制御フローグラフは、計装を使用してプログラムフローの保護／障害防止を容易にするための追加システム／モジュールへの道標として役立つことができる。このように、システムは制御フローグラフに従って計装を自動的に統合する。このようにして、フォールト制御システムは、プログラムの障害に対する回復力を向上させると同時に、制御および非制御の観点に対する悪意のある攻撃に対してもプログラムを保護する。

一実施形態において、安全関連機能のためのプログラムにおける制御フローを改善するためのフォールト制御システムが開示される。フォールト制御システムは、１つ以上のプロセッサと、その１つ以上のプロセッサに通信可能に結合されたメモリとを含む。メモリは、1つ以上のプロセッサによって実行されるとき、1つ以上のプロセッサに、プログラムの安全関連機能を識別させる命令を含む分析モジュールを格納する。安全関連機能は、関連する装置が機能安全基準に従って動作するかどうかに影響を与えるプログラムによって実行される機能と関連付けられている。メモリは、1つ以上のプロセッサによって実行されるとき、1つ以上のプロセッサに、安全関連機能のフォールトツリーをプログラムの制御フローグラフの関連部分に統合させる命令を含むグラフモジュールを格納する。制御フローグラフは、プログラム内の少なくとも手続き型の制御フローを識別し、フォールトツリーは、プログラムによって障害を生じさせるプログラム内の状態の組み合わせを示す。グラフモジュールには、プログラムの制御フローを改善するための電子的出力として制御フローグラフを提供するための命令が含まれる。

一実施形態において、非一時的なコンピュータ可読媒体が開示される。コンピュータ可読媒体は、１つ以上のプロセッサによって実行されたとき、１つまたは複数のプロセッサに開示された機能を実行させる命令を格納する。命令には、プログラムの安全関連機能を識別するための命令が含まれる。安全関連機能は、関連する装置が機能安全基準に従って動作するかどうかに影響を与えるプログラムによって実行される機能に関連付けられている。命令には、安全関連機能のフォールトツリーをプログラムの制御フローグラフの関連部分に統合するための命令が含まれている。制御フローグラフは、プログラム内の少なくとも手続き型の制御フローを識別し、フォールトツリーは、プログラムによって障害を生じさせるプログラム内の状態の組み合わせを示す。命令には、プログラムの制御フローを改善するための電子的出力として制御フローグラフを提供するための命令が含まれる。

一実施形態において、安全関連機能のためのプログラムにおける制御フローを改善する方法が開示される。この方法には、プログラムの安全関連機能を識別することが含まれる。安全関連機能は、関連する装置が機能安全基準に従って動作するかどうかに影響を与えるプログラムによって実行される機能に関連付けられている。この方法には、安全関連機能のフォールトツリーをプログラムの制御フローグラフの関連部分に統合することが含まれる。制御フローグラフは、プログラム内の少なくとも手続き型の制御フローを識別し、フォールトツリーは、プログラムによって障害を生じさせるプログラム内の状態の組み合わせを示す。この方法は、プログラムの制御フローを改善するための電子的出力として制御フローグラフを提供することを含む。

本明細書に組み込まれ、その一部を構成する添付図面は、本開示の様々なシステム、方法、および他の実施形態を示す。図中に示された要素の境界（例えば、ボックス、ボックスのグループ、または他の形状）は、境界の一実施形態を表すことが理解されよう。いくつかの実施形態では、１つの要素が複数の要素として設計されてもよく、または複数の要素が１つの要素として設計されてもよい。いくつかの実施形態では、別の要素の内部コンポーネントとして示される要素は、外部コンポーネントとして実装されてもよく、その逆もあり得る。さらに、要素は縮尺どおりに描かれない場合がある。
図１は、制御フローグラフの生成及びプログラムのソースコードに関連する他の機能の実行に関連付けられたフォールト制御システムの一実施形態を示す。 図２は、プログラムのソースコードの一例を示す。 図３は、図１のシステムが、図２のソースコードから導出する、制御フローグラフの一例を示す。 図４は、論理ゲートを使用した状態の組み合わせを表すフォールトツリーの一例を示す。 図５は、制御フローグラフのさらなる例を示す。 図６は、制御フローグラフの追加の例を示す。 図７は、制御フローグラフの生成に関連する方法の一実施形態を示す。 図８は、安全関連機能を識別し、フォールトツリーを生成することに関連する方法の一実施形態を示す。 図９は、ソースコードを自動的に計装することに関連する方法の一実施形態を示す。

一実施形態では、制御フローグラフ内にフォールトツリーを統合することによって安全関連機能のランタイムチェックを実行することに関連する例示的なシステム及び方法が開示される。前述のように、制御フローとフォールトツリー分析への現在のアプローチは、一般に過度に複雑であるか、手作業のサポートに大きく依存しており、その結果、効果的でない解決策になってしまう。

そのため、一実施形態では、制御フロー分析とフォールトツリー分析の両方を同時に実行し、結果として生じるフォールトツリーを制御フローグラフ内にさらに統合して、プログラム内の機能安全とプログラムフローの完全性の両方を改善する合理化された解決策を提供するフォールト制御システムが開示される。このように、フォールト制御システムは、一実施形態において、充実された制御フローグラフを使用して、プログラムを自動的に計装し、それによってプログラム／データフローを検証し、障害状態を回避して、機能安全基準への準拠を確実にするランタイムチェックを自動的に報告する。

１つのアプローチにおいて、開示されるフォールト制御システムは、組み合わされた分析のプロセスを通じて、制御フローグラフとフォールトツリーの両方を並行して生成する。例えば、フロー制御システムは、プログラムのソースコードを分析して制御フローの特性を識別すると同時に、ソースコード内の機能も分析して安全関連の機能を識別する。安全関連機能は、例えば、関連する装置の機能安全に関連するプログラムの機能である。一般的に、機能安全とは、人体への身体的傷害または装置自体の損傷のリスクに関係する、関連装置の安全な操作を指す。このように、安全関連機能には、例えば、車両を制御してブレーキをかける機能、または障害／故障が人体への傷害または装置（例えば、車両）への広範な損傷をもたらす可能性がある他の機能を実行する機能が含まれ得る。

このような問題の回避を容易にするために、フォールト制御システムは安全関連機能を識別し、フォールトツリー分析に従ってそれらの機能を分析する。フォールトツリー分析を通じて、フォールト制御システムはフォールトツリーを生成する。フォールトツリーは、１つの特徴において、プログラム内で障害（例えば、誤った出力、重大な停止など）をもたらす可能性のある入力、内部状態、またはその他の状態の組み合わせを具現化する。１つのアプローチにおいて、フォールト制御システムは、グラフポリシーによって識別される障害特性に従って状態の組み合わせを識別する。概して、グラフポリシーは、プログラムが実行されているハードウェア、入力／状態の特定の組み合わせなどに関係する特定の態様を示すことができる。フォールト制御システムは、通常、フォールトツリーを使用してそのような故障／障害を表し、論理および細分化された状態（入力および関連する値など）の体系的な表現に従って、障害を生じさせる状態の組み合わせを識別する。

さらに、フォールトツリーを作成すると同時に、フォールト制御システムは制御フローグラフも生成する。付随する説明を通じてよりよく理解されるように、制御フローグラフは、通常、プログラムフローおよびプログラムのデータフローに関連する脆弱性を表すように機能する。つまり、基本的な形式の制御フローグラフは、プログラムのリダイレクト、プログラムに関連付けられたデータの変更などを試みる悪意のある攻撃に対してプログラムのどの側面が脆弱であるかを表すように生成される。

概して、フォールト制御システムは、プログラムのソースコードをリアルタイムで分析するか、プログラムの制御フロー特性を識別する要求に応じて分析する。制御フロー特性は、一実施形態において、プログラムの工程内および／または工程間の制御フロー（例えば、制御データ）に影響を与える態様を含む。さらなる態様では、制御フロー特性は、非制御データ引数に関するデータ特性も含む。いずれの場合も、フォールト制御システムは、制御フロー特性に従ってプログラムフローを表す制御フローグラフを生成する。例えば、フォールト制御システムは、プログラム／データフローに従って、ソースコードのさまざまな観点に関係するノード、有向エッジ、およびノード内のタグ／メーカーを生成する。

さらに、フォールト制御システムは、一実施形態において、単一の表現を使用してプログラムの重要な観点（例えば、危険なパス）をさらに識別するために、フォールトツリーを制御フローグラフに統合する。一態様では、フォールト制御システムは、制御フローグラフのノード／エッジにフォールトツリーによって識別された状態を用いて注釈を付けることによってフォールトツリーを統合する。従って、フォールトツリーによって識別された状態に関連付けられたソースコードの様々なブロックに制御フローグラフ内で注釈が付けられ、特定の状態が障害／エラーをもたらす可能性のある制御フローグラフの危険なパスをさらに識別する。

その結果、制御フローグラフは、単一の拡張データ構造内にプログラムの様々な重要な観点を具体化する。制御フローグラフは、計装されるべき他の態様に加えて、安全関連機能に関する情報を含むように生成されるため、制御フローグラフは、計装を使用してプログラムフローの保護／障害防止を容易にするための追加システム／モジュールへの道標として役立つことができる。このように、システムは制御フローグラフに従って計装を自動的に統合する。このようにして、フォールト制御システムは、障害及び悪意のある攻撃からプログラムを保護することにより、プログラムフローの完全性及び機能安全に関連するプログラムの回復力を促進する。

さらなる特徴において、フォールト制御システムはまた、プログラムの実行フローおよび起こり得る障害の視覚的表現を生成するために、制御フローグラフを使用する。言い換えると、フォールト制御システムは、１つのアプローチにおいて、プログラムが開発されている間、プログラムについて開発者に知らせる方法として、リアルタイムの更新を伴う、統合開発環境（ＩＤＥ）内の制御フローグラフの視覚的表現を電子的に表示する。このように、制御フローグラフをリアルタイムで提供することにより、制御フローデータ引数、非制御データ引数、および機能安全の観点に関連する、プログラムの適切なプログラム構造を確保することが容易になる。このようにして、フォールト制御システムは、開発中にプログラムの重要な観点のより良い認識を促進することにより、プログラムの機能を向上させる。

図１を参照すると、フォールト制御システム１００の一実施形態が示されている。本明細書では、フォールト制御システム１００に関して構成を説明するが、実施形態は、図示のような単一のシステムに限定されないことが理解されよう。いくつかの実装形態において、フォールト制御システム１００は、クラウドコンピューティングシステム、クラスタコンピューティングシステム、分散コンピューティングシステム、ソフトウェア−アズ−ア−サービス（ＳａａＳ）システムなどとして具現化され得る。従って、フォールト制御システム１００は、説明の目的のため単一のデバイスとして図示され、説明されるが、開示されるコンポーネントが構成され得る全体的な可能な構成を制限するように解釈されるべきではない。例えば、別個のモジュール、メモリ、データベースなどは、様々な組み合わせで様々なコンピューティングシステムに分散されても良い。

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

加えて、図のシンプルさと分かり易さのため、適宜、対応するまたは類似の要素を示すために、異なる図の間で参照番号が繰り返されることが理解されよう。さらに、説明は、本明細書に記載された実施形態の完全な理解を提供するために、多くの特定の詳細を概説する。しかしながら、当業者は、本明細書に記載の実施形態が、これらの要素の様々な組み合わせを使用して実施され得ることを理解するであろう。

いずれの場合も、フォールト制御システム１００は、フォールトツリーを統合した制御フローグラフを生成するために、プログラム上で制御フローおよびフォールトツリー分析を実行することに関連する、本明細書に開示される方法および他の機能を実行するように実現される。言及された機能と方法は、図のさらなる説明でより明らかになるであろう。さらに、フォールト制御システム１００は、プロセッサ１１０を含むものとして示されている。このように、様々な実施例において、プロセッサ１１０は、フォールト制御システム１００の一部であっても良いし、フォールト制御システム１００は、データバスまたは別の通信経路を介してプロセッサ１１０にアクセスしても良いし、プロセッサ１１０は、フォールト制御システム１００によってアクセス可能なリモートコンピューティングリソースであっても良い。いずれの場合も、プロセッサ１１０は、他の電子デバイスを制御する、または他の電子デバイスの制御を引き起こすために使用され得る様々な電子的出力を生成するようにマシン可読命令を実行することができる、マイクロプロセッサ、ＡＳＩＣ、グラフィックス処理ユニット（ＧＰＵ）、または別のコンピューティングコンポーネントなどの電子デバイスである。

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

フォールト制御システム１００を引き続き参照すると、一実施形態では、システム１００はデータベース１６０を含む。 データベース１６０は、一実施形態では、メモリ１２０、分散メモリ、クラウドベースメモリ、または別のデータストアに格納された電子データ構造であり、格納されたデータを分析する、格納されたデータを提供する、格納されたデータを整理するなどのため、プロセッサ１１０によって実行され得るルーチンで構成される。例えば、一実施形態では、データベース１６０は、様々な決定を実行する際にモジュール１３０、１４０、および１５０によって使用されるデータを格納する。一実施形態では、データベース１６０は、制御フローグラフ１７０を格納する。さらなる実施形態では、フォールト制御システム１００は、グラフ１７０を、メモリ１２０、特化型データ構造、プロセッサ１１０のキャッシュメモリ、または別の適切なデータストレージコンポーネントに格納する。同様に、データベース１６０は、一実施形態において、例えば、パスを危険にする可能性のある状態とともに、グラフ１７０内の危険なパスを識別するフォールトツリーを格納する。

本明細書で使用されるように、プログラムは、ソースコードから導出されるコンパイルされたマシンコードを指す。例えば、一実施形態において、プログラムは、マシンコードであるコンパイル済みのプログラムまたはその一部である。本明細書で使用される「マシンコード」という語句は、一般的に、例えば、プロセッサ１１０などのマイクロプロセッサによって実行することができる機械語命令で表されるプログラムを指す。さらに、マシンコードは、一般的に、関連するハードウェアによって実行される命令セットによって定義されるオペコードで構成される、原始言語またはハードウェア依存言語であると理解される。さらに、マシンコード自体は、データ値、レジスタアドレス、メモリアドレスなどでさらに構成される。もちろん、プログラムはマシンコードであると説明されているが、さらなる実施形態では、プログラムは、アセンブリコードまたはソースコードから導出される別の中間表現である。

プログラムのコンパイル元となるソースコードは、例えば、関数、データ構造、オブジェクト、ステートメントなどで構成される。ソースコードの一部として含まれている計装は、さらに同じ要素（オブジェクト、ステートメントなど）で構成される。一般的に、プログラムは一連の関数として編成されている。様々な表現において、関数は、サブ関数として互いに入れ子にされ得る。さらに、関数は、通常、一連のステートメント（ループ、Ｉ／Ｏステートメントなど）から構成され、典型的には特定の機能に焦点を合わせている。つまり、各個別の関数は、通常、特定のタスクを行うために実行される。例えば、サブ関数は、親関数のより広範な機能をサポートするサブルーチンを実行することができる。いずれの場合も、関数は、関数自体を形成するステートメントを定義し、その関数に関連付けられた機能の実現を提供するソースコードを含む。

さらに、本明細書で説明されるように、記載されたモジュール１３０、１４０、１５０は、統合開発環境へのプラグインとして、またはスタンドアロン機能として機能し得る。統合開発環境（ＩＤＥ）は、ソフトウェア開発のための便宜を提供するプログラムまたはプログラムの集合である。たとえば、ＩＤＥは、ソースコードエディタ、ビルドツール、デバッガ、コンパイラ、インタプリタ、グラフィカルユーザーインターフェイス（GUI）などが含むことができる。一般的に、ＩＤＥは、プログラムの作成を容易にするツールやその他の態様を備える総合的な環境を提供することを通じて、開発者（つまり、プログラマ）の効率を向上させる仕組みである。例えば、前述のように、１つ以上の構成では、モジュール１３０、１４０、１５０は、追加の機能を提供するためにＩＤＥと統合するプラグインである。そして、１つのアプローチでは、モジュール１３０、１４０、１５０は、例えば、ＩＤＥに電子的に提供されるコードセグメントを含む、電子的入力および出力ストリームを含む、ＩＤＥの電子データにアクセスする。モジュール１３０、１４０、および１５０は、アクセスを容易にするために、ＩＤＥのアプリケーションプログラムインターフェース（ＡＰＩ）を活用することができる。さらに、そのようなアクセスは、モジュール１３０、１４０、１５０の統合を自動化する（例えば、直接的な統合アクセスを提供する）アプリケーションフックの形で提供されてもよい。いずれの場合も、システム１００およびモジュール１３０、１４０、１５０は、通常に、ＩＤＥと協調して機能する。例えば、ＩＤＥは、実行時に、通常、プログラムのコンパイル元のソースコードを管理し、実際にソースコードをプログラムにコンパイルする機能を提供することもある。

データベース１６０の要素について続けると、グラフ１７０は、プログラムを通じて、実行パスを表す制御フローグラフである。さらなる態様では、グラフ１７０はまた、データ引数およびグラフ１７０内の異なるノードでのデータ引数の関連状態を表す。さらに、グラフ１７０は、一実施形態では、注釈、タグ、ラベル、または、関連するソースコードの他の関連特性の他の識別子を含む。後に詳細に説明するように、一実施形態では、グラフ１７０は、フォールトツリーの対応する態様を識別するノード／有向エッジ内に注釈を含む。そして、フォールトツリーは、例えば、プログラム／データフローに関する情報と一緒にグラフ１７０内に統合される。

一実施形態において、分析モジュール１３０及びグラフモジュール１４０は、ソースコードが動的にＩＤＥに提供されるときに、ソースコードからグラフ１７０を導出するように一緒に機能する。代替の実施形態では、分析モジュール１３０及びグラフモジュール１４０は、特定の要求に応答して、断続的に、またはソースコードがコンパイルされる前に、記載された機能を実行するように動作する。

グラフモジュール１４０は、１つのアプローチにおいて、ノード、及びノード間の有向エッジを使用してグラフ１７０を形成する。ノードはソースコードのブロックを表し、一方、ノード間の有向エッジはブロック間のジャンプ／制御ハンドオーバーを表す。ブロックは、例えば、コードの原子セグメント（例えば、中断されない）または少なくとも一体的に関連するソースコードのセグメントである。一実施形態では、有向エッジは、ブロック／セグメント間の工程内および／または工程間の制御フロー転送を示す。つまり、エッジは、ハンドオーバー、関数呼び出し、具体的および／または記号的な関数の引数などを表す。概して、有向エッジは、個別のブロック間のプログラム実行における転送を示す。さらに、グラフモジュール１４０は、フォールトツリーをグラフ１７０の必須部分として提供するために、安全関連機能に関連するエッジおよびノードを識別し、グラフ１７０のそのようなセクションに状態を用いて注釈を付けることによって、実質的に、フォールトツリーを制御フローグラフ１７０上に重ねる。

さらに、一実施形態において、グラフモジュール１４０は、非制御データ引数に関するデータ特性を使用して、制御フローグラフ１７０に注釈を付ける。例えば、グラフモジュール１４０は、ソースコード内のデータ引数に関する注釈を含むようにグラフ１７０を生成する。記載されているデータ引数の一部は、プログラムによって生成されるフォールトツリー及び入力／内部値に関連する場合がある。従って、グラフモジュール１４０は、フォールトツリーを統合するために、および／またはデータ引数がデータ露出などのさらなるリスクを表す場合に、制御フローグラフ１７０の一部として様々なデータ引数を含むことができる。

一般的に、制御フロー特性の一部として含まれるデータ引数は、関数間で渡される変数などの非制御データ引数である。対照的に、制御フロー特性内に含まれる制御データは、プログラムの実行パスに影響を与えるノードおよび有向エッジにおけるグラフ１７０の実際の構造の基礎を与える。いずれの場合も、グラフモジュール１４０は、フォールトツリー及び／又はノード／エッジに関連するデータ特性を含むように、ノード及び／又は有向エッジに注釈を付ける。このようにして、グラフモジュール１４０は、悪意のある攻撃および／または障害の影響を受けやすい可能性があるプログラムの潜在的に脆弱な側面のより分かりやすい表現を有するようにグラフ１７０を生成する。

別の実施形態では、ノードおよび有向エッジは、本明細書に記載されているものとは異なって定義され得ることを理解されたい。例えば、1つのアプローチにおいて、有効エッジと、ノードと統合されたフォールトツリーの注釈とを定義する状態及びノードを含むセグメント／ブロックは、グラフポリシーに従って指定される。グラフポリシー１８０は、ブロック／セグメント、状態、遷移などを識別するためのテンプレート、例示的なセグメント、および／またはメトリクスを定義する。一般論として、グラフポリシー１８０は、分析モジュール１３０が、ソースコードを分析する際に様々な態様を識別することができるように、例えば、障害、工程内および／または工程間の制御フロー、データ引数などと関連付けられる特性に基づく様々な規則を用いて定義される。さらに、グラフポリシー１８０は、１つのアプローチにおいて、安全関連機能から導出されたフォールトツリーがグラフ１７０とどのように統合されるか（例えば、どの部分にどの情報で注釈を付けるか）をさらに定義する。従って、システム１００は、別個の実施例に従って制御フローグラフ１７０の態様を柔軟に定義するように実現され得る。

例として、図２は、プログラムのソースコードのサンプルセグメントを示す。さらに、図３は、例示的な制御フローグラフ３００を示す。制御フローグラフ３００は、分析モジュール１３０を介して提供される入力からグラフモジュール１４０によって生成され得るグラフの例示である。そして、グラフ３００は、ソースコード２００からのコードのセグメント／ブロックに対応するノード３０５、３１０、３１５、３２０、３２５、３３０、３３５、３４０、および３４５を含む。グラフ３００は、ソースコード２００のセグメント間の関係に対応するノード間の有向エッジをさらに示す。さらなる態様において、グラフ３００には明示的に示されていないが、グラフモジュール１４０は、グラフ３００内に非制御データ引数のデータ特性を含む。例えば、分析モジュール１３０は、文字列ｃｈａｒを非制御データ引数として識別することができる。従って、文字列ｃｈａｒのデータ特性は、ＰｒｉｎｔｆやＰｕｔｃなどの1つ以上の関数による変更を示す一方で、グラフ１７０内の追加の注釈として、文字列がどこで／いつ初期化され得るかを示すことができる。

さらに、個々のノード及び有向エッジは、例えば、ソースコードの制御フロー特性に従って定義される。つまり、ソースコードのブロック／セグメントが相互に関連する方法と、ブロック／セグメント自体の間の画定とが、ソースコードの制御フロー特性に従って定義される。後でさらに説明されるように、グラフモジュール１４０は、概して、１つ以上の実施形態において、プログラムのソースコードからのデータ特性を含む制御フロー特性を識別し、システム１００内で定義されたグラフポリシーに従ってそのようにしてもよい。

図４は、分析モジュール１３０によって生成され、グラフモジュール１４０によってグラフ１７０に統合され得るフォールトツリー４００の一例を示す。フォールトツリー４００は、論理ゲート４１０、４２０、４３０、４４０、４５０を含むものとして示され、これらは、ＯＲゲートとＡＮＤゲートとして示されている。様々な論理ゲートへの入力には、他の論理ゲートからの出力、及び／又はプログラムの状態が含まれる。状態は、例えば、変数の内部生成値、メモリアドレス、入力／出力値、ハードウェア相互作用などを含み、フォールトツリー４００において整数１〜８でラベル付けされた円によって表されている。このように、実際には、分析モジュール１３０は、例えば、予想される実行環境（例えば、プログラムを実行するためのハードウェアプラットフォーム）に従い、グラフポリシー１８０を使用してソースコードを分析し、安全違反につながる可能性のある、またはプログラムを実行するシステムにおいて致命的な障害を引き起こす可能性のある様々な制御パスに沿った状態の組み合わせを識別する。

フォールトツリー４００に示されるように、論理４４０、４３０、または４２０のいずれかが注目される状態の発生を示す場合、ＯＲゲート４５０は、出力ブロック４６０で潜在的な障害／故障の表示を生成する。例えば、４４０、４３０、および４２０の別々の論理ゲートは、安全関連機能の別々の内部ステートメントに関連付けることができる。さらに、図示されるように、論理ゲート４２０は、入れ子になった論理ゲート４１０からの入力を受け入れる。このような入力は、追加のサブ関数／ルーチン又はイベントの特定の組み合わせ、特定の値を持つように生成される変数、特定のメモリアドレス／範囲の使用、Ｉ／Ｏの組み合わせなどについて条件付けされた態様を表すことが可能である。一般的に、フォールトツリーを形成するために組み合わされるロジックと変数／状態の配置は、障害を生じるプログラム内の望ましくない状態につながる状態を正確に表すために、多くの異なる形式をとることができる。

いずれの場合も、一例として、グラフモジュール１４０は、フォールトツリー４００を、例えば図３の制御フローグラフ３００に統合する。提供された図には示されていないが、グラフモジュール１４０は、通常、プログラムのプログラムフローにおいて、状態が発生する場所に関して、状態を特定するために、グラフに注釈を付けることによって、フォールトツリー４００をグラフ３００に統合する。すなわち、グラフ１７０／３００がプログラムフローを表すことを考慮すると、グラフモジュール１４０は、フォールトツリー４００を、状態の組み合わせが発生するノードおよび有向エッジに対応する注釈に変換する。例として、グラフモジュール１４０は、グラフ３００のブロック３１５に、特定の反復との組み合わせにおいて障害をもたらす場合に、注目すべき変数の値の指標を用いて注釈を付けてもよい。グラフモジュール１４０は、フォールトツリー４００から導出された注釈に従って識別され得る、ソースコード２００内の危険な実行パスに関する情報で制御フローグラフ３００を充実させるために、フォールトツリー４００からの、この組み合わせの態様を、それぞれのノードおよびエッジに注釈付ける。

いずれの場合も、図５および６は、ソースコードの多様なセグメントに対応する制御フローグラフ５００および６００のさらなる例を示している。例えば、図５に示されるように、グラフ５００は、対応する有向エッジによって示されるように、ｉｆ−ｔｈｅｎ−ｅｌｓｅステートメントを介して別々のパスで互いに関係するソースコードの別々のセグメントに対応する４つの別々のノード５１０、５２０、５３０、５４０を含む。さらに、図６は、関連するブロック／関数内のコードのセグメントを表すノード６１０、６２０、６３０、６４０を含むグラフ６００を示している。図示のように、グラフ６００は、出口ノード６４０につながる別々の有向エッジによって示される２つの別個の退出状態を含むループを表す。このように、グラフ１７０は、プログラムの実行フローを表すために、ソースコードの多くの異なる構成を描写することができる。

グラフモジュール１４０がフォールトツリーを制御フローグラフに統合する方法のさらなる例として、グラフ５００および６００に示される別々のパスを考慮する。様々な状況において、グラフモジュール１４０は、フォールトツリーによって表される状態に関連付けられる１つ以上の有向エッジに注釈を付ける。例として、図５のノード５１０と５３０との間の有向エッジはノード間の遷移に関連付けられた状態が障害をもたらし得る場合、グラフモジュール１４０によって注釈を付けることができる。同様に、グラフモジュール１４０は、フォールトツリーがそのようなノードは潜在的な障害に関連付けられることを示すとき、ブロック６１０および６２０に対して、退出状態に注釈を付けることができる。このようにして、グラフモジュール１４０は、フォールトツリーを制御フローグラフに統合して、潜在的な障害について制御フローグラフによって伝達される情報を充実させる。

さらに、提供される例は、比較的短いコードセグメントに関するものであり、一般的な傾向として、グラフ１７０は、複数のノードおよびそれらの間の有向エッジを含むことを理解されたい。一例として、例示的なグラフ５００および６００に示されるような「出口」ノードは、様々な実施例において、通常、実際のプログラム出口ではなく、別個のコードセグメントへの遷移を示す。さらに、グラフ５００および６００は、非制御データ引数と一緒に示されていないが、グラフ５００及び６００を有する別個のノードは、関連する非制御データ引数の態様をさらに指定するために注釈を付けられ得ることを理解されたい。このように、グラフ１７０は、視覚的な形式で表現されたとき、開発者によるより良い理解を容易にし、また、様々なモジュールにプログラムフローおよびデータ特性の理解を提供することにより、さらなる自動化機能を促進するためのものでもある。

追記として、制御フローグラフは、プログラムフローおよびフォールトツリーに関連する態様を含むものとして説明されているが、システム１００は、１つのアプローチにおいて、グラフ１７０内の非制御データ引数に関する態様も含む。本明細書で参照されるように、データ引数は、通常、ソースコード内で記述される変数であり、文字列、整数、文字などの様々なタイプであり得る。さらに、ソースコードは複数のそのような非制御データ引数を含むことができるが、分析モジュール１３０は、１つのアプローチにおいて、グラフポリシー１８０によって示される条件に従って、データ引数の特定のもののデータ特性を選択的に識別する。このように、グラフ１７０内でのデータ引数の包含は、分析モジュール１３０がデータ引数は包含の条件を満たすと決定することに左右され得る。条件は実施例によって異なり得るが、一般的に、グラフポリシーは、操作にさらされる可能性があるか、または含まれるべきデータ引数としてより機密性の高い（例えば、パスワード）、グラフ１７０内のデータ引数を示す。

図１のデータベース１６０について続けると、計装ポリシー１９０は、後でより詳細に説明されるように、計装モジュール１５０がソースコード内に計装を含める対象とする、様々な状態および／またはソースコードのセグメントを定義する。概して、計装は、特定の実装例に応じて異なる目的を果たすことができる。例えば、計装は関数内に統合されて、プログラムフローを制御する（例えば、プログラムが誤った方向に向かわないことの確認）、デバッグする、データ引数を検証する（例えば、データ値の操作の防止）、Ｉ／Ｏを検証する、障害を防止する、特定の状態が発生したときにプログラムをリダイレクトする、などを提供することができる。例えば、プログラムが先進運転支援システム（ＡＤＡＳ）を制御して、道路上で車両がどのように制御されるかを自動的に調整する例において、計装は、プログラムが悪意のある攻撃によって操作された場合に、事故や乗員の負傷をもたらし得るプログラムフロー及び／又はデータ値の悪意のある操作を防ぐためのセキュリティ計装を含むことができる。さらなる例として、1つ以上の既知の障害状態がプログラムに存在する場合、計装は、状態の発生を検出すると、プログラムフローを安全な終了手順にリダイレクトする。

さらなる態様では、計装ポリシー１９０はまた、計装閾値又は少なくとも計装閾値を生成するためのメトリクスを定義する。１つのアプローチでは、計装ポリシー１９０は、計装がプログラムに含まれるべき時期に関連して、多様なクラスの関数、データ引数などの計装閾値を定義する。例えば、計装ポリシー１９０は、一実施形態において、開発者によってタグ付けされ得るか、またはコードセグメントに関連付けられ、定義されたメトリクスに従って導出され得るセキュリティレベルに従って関数／引数のクラスを定義する。概して、セキュリティレベルの個別のクラス及び関連する閾値は、特定の関数／引数の脆弱性（例えば、操作への露出）又は他の観点に関連する場合がある。そのため、計装ポリシー１９０は、計装の包含を最適化するために、セグメントが計装されるべきである異なる閾値を示し得る。従って、実際には、計装モジュール１５０が、例えば、コードセグメントを評価し、注目された閾値が満たされると、評価に従って計装を自動的に含める。

さらに、コードセグメント内に含まれる実際の計装そのものは、一実施形態において、前述のグラフポリシー１８０内のテンプレートとして定義される。例えば、テンプレートは、プログラムフローの制御、Ｉ／Ｏの検証、追加の機能のフックの提供、データ引数へのデータ整合性の提供などに関連してさまざまな機能を実行する一連の標準化された計装を定義する。これらの機能は、通常、データの整合性、プログラムフローの整合性を確保し、障害／故障を防ぐためにプログラムへの制約を強化するランタイムチェックである。

さらに、テンプレートは、１つのアプローチにおいて、例えば、計装が含まれる特定のコードセグメントに従って計装モジュール１５０によってカスタマイズされる変数をさらに示す。すなわち、計装モジュール１５０は、一例において、関数の戻りアドレスを検証する、又は変数へのアクセスを制御するための計装を含むことができる。このように、計装モジュール１５０は、テンプレートを特定の計装が構築されるフォームとして使用することにより、関連するソースコードに対応し、関連するソースコードセグメントにセキュリティ、障害保護、又は他の機能を提供するように、テンプレートから関連する計装ステートメントの変数を変更する。計装ポリシー１９０および計装モジュール１５０のさらなる態様は、後述される。

図１について続けると、分析モジュール１３０は、一実施形態において、プロセッサ１１０によって実行されるとき、プロセッサ１１０に、ソースコードに追加されているコードセグメント、又はソースコードの分析を開始する別の条件（例えば、電子的要求）を検出させるコンピュータ可読命令を含む。１つのアプローチでは、分析モジュール１３０は、アプリケーションプログラムインターフェース（ＡＰＩ）または他のプログラムフックを介して内部的にＩＤＥにアクセスして、ＩＤＥ内の電子的入力ストリームを監視する。電子的入力ストリームは、通常、関連するコンピューティングデバイスの他のシステムコンポーネントを介してＩＤＥに提供される電子的入力を含む。例えば、分析モジュール１３０は、プロセッサ１１０上で実行される他のプロセスからの電子的入力、ネットワーク通信インターフェースを介して受信される電子的通信、プロセス内（すなわち、ＩＤＥ内）通信、コンピューティングデバイス（例えば、キーボード）と接続されたマシンインターフェースデバイスからのＩ／Ｏ入力、ファイルシステムリソース、などを監視する。

そして、分析モジュール１３０は、１つのアプローチにおいて、ソースコードの変更のための注目すべき電子的入力、又はソースコードを分析するための個別の要求を指定する入力を監視する。さらに、分析モジュール１３０は、一実施形態において、ソースコードを分析して、制御フロー特性、安全関連機能、およびソースコードの障害特性を識別するための命令も含む。すなわち、１つのアプローチでは、ソースコード内で変更が行われると、分析モジュール１３０は、変更が生じたときにリアルタイムで変更をアクティブに検出し、注目すべき態様を特定するためにソースコードを分析する。一実施形態では、制御フロー特性は、関数呼び出しなどのプログラムの工程内及び／又は工程間制御フロー転送、及び、呼び出し規約と一緒に、記号名、関数引数および戻り値を伴う戻りアドレスなどを含む。より一般的には、制御フロー特性は、プログラムの実行に影響を与え、ハンドオーバー、終了、ジャンプなどをもたらす態様に関連する。

さらに、制御フロー特性には、ソースコード内の様々なポイントでのデータ引数の現在の状態、データ引数に関連付けられた関係（例えば、変数が渡される、及び／又は変数を操作することができる関数）などのような非制御データに関連する対応も含まれ得る。より一般的には、非制御データの特性は、変数及び変数の許可された使用／アクセスを識別する。このように、分析モジュール１３０は、一実施形態において、制御フロー／データ特性を識別するために、注目すべき監視および分析をリアルタイムで実施し、その結果、グラフモジュール１４０は、ソースコードの様々な態様に関して更新されたフォームにグラフ１７０を維持することができる。

加えて、分析モジュール１３０は、プロセッサ１１０にソースコード内の安全関連機能を識別させるための命令を含む。一実施形態では、分析モジュール１３０は、ソースコードが開発されるときに、ソースコード内に含まれる定義されたタグに従って安全関連機能を識別する。さらなる実施形態では、グラフポリシー１８０は、安全関連機能を自動的に識別するために、分析モジュール１３０によって使用される安全関連機能に関連付けられた特性を示す。一実施形態では、特性は、故障が人に傷害をもたらす可能性があるデバイスの制御に関連する全体的な機能、他の関数によって使用される値を生成する機能、およびそのような障害をもたらすように広がる可能性のあるエラー、及びより一般的には、機能安全に影響を与えるプログラムの機能を含む。機能安全への影響は、通常、例えば、特定の機能が危険な故障／障害を経験する確率に従って評価される。従って、機能を識別する安全関連の特性には、特定のＩ／Ｏ許可／アクセス、特定の変数に関連するデータ処理、障害のある／バグのあるハードウェアコンポーネントへのアクセス、さまざまなＡＰＩへのアクセス、及び類似の特性が含まれる。

分析モジュール１３０はさらに、安全関連機能に対してフォールトツリー分析を実行して、フォールトツリーを生成する。一実施形態では、フォールトツリーは、イベント、及びイベントと障害との関係を記述するロジックで構成される。イベントは、プログラムによって生成される間隔値、Ｉ／Ｏ変数／値、プログラム及び内部／外部値に関連付けられた実行状態、様々なハードウェアコンポーネントとの相互作用などに関連付けられた状態である。分析モジュール１３０は、例えば、障害をもたらす状態の組み合わせ及びそれらの間の関係を示すグラフポリシー１８０を参照する。１つのアプローチでは、グラフポリシー１８０は、通常、既知のバグのリスト、障害を識別するテスト環境でのプログラムの実行などを通じて、そのような障害の認識を含むように実現される。

いずれの場合も、分析モジュール１３０は、安全関連機能を解析して、その構成部分を識別し、その機能の部分がグラフポリシー１８０において識別される注目すべき状態を満たすかどうかを決定し、障害を生じるのは安全関連機能のどの態様であるか、また、どのような状態の下で障害が発生される可能性があるかを追跡する手法としてフォールトツリーを生成することにより、フォールトツリー分析を実行する。一実施形態では、分析モジュール１３０は、ソフトウェアフォールトツリー分析（ＦＴＡ）を実施する。このように、分析モジュール１３０は、図４に関連して前述したように、論理ゲートおよびイベント／変数識別子を使用することにより、状態の組み合わせを含むようにフォールトツリーを生成する。結果として得られるフォールトツリーは、プログラム内の危険な実行パスと、状態の組み合わせが満たされたときに、そこからもたらされるかもしれない潜在的な障害の凝縮表現を提供する。従って、フォールト制御システム１００は、概して、障害の発生を防止するため、または少なくとも障害が関連するデバイス（例えば、車両内のコントローラ）の故障を引き起こすことを防止するために使用される。

そして、グラフモジュール１４０は、一実施形態において、プロセッサ１１０によって実行されるとき、プロセッサ１１０に制御フロー特性に従って制御フローグラフ１７０を生成させるコンピュータ可読命令を含む。グラフモジュール１４０は、概して、非制御データ引数およびフォールトツリーに関連する態様についての注釈／タグとともに、ノードおよび有向エッジを表すためのプログラム要素を含む電子データ構造としてグラフ１７０を生成することに留意されたい。最初に、グラフモジュール１４０は、ヌル値またはエントリノードを含むグラフ１７０を生成し、そこから、グラフモジュール１４０は、プログラムに渡る様々なパスの分析を通じてグラフ１７０を構築する。

１つのアプローチでは、グラフモジュール１４０は、グラフ１７０に調整／変更が行われるときに、グラフ１７０をリアルタイムで更新する。あるいは、前述のように、グラフモジュール１４０は、例えば、間欠的、ソースコードの完了時、ソースコードをコンパイルする前などに、電子的要求を受信すると、グラフ１７０を生成してもよい。例えば、グラフモジュール１４０は、一実施形態において、ソースコードによって定義されるプログラムのリアルタイム評価を提供するために、修正／追加が行われる区分的にグラフ１７０を生成する。

加えて、グラフモジュール１４０は、識別された障害を生じる状態の組み合わせに関する情報をさらに含めるために、制御フローグラフと並行して生成されるフォールトツリーを使用する。前述のように、グラフモジュール１４０は、状態および障害がいつ発生するかを特定する情報でグラフ１７０のノードおよびエッジに注釈を付けることによって、グラフ１７０を充実させる。そして、グラフモジュール１４０は、制御フロー特性及びフォールトツリーの分かりやすい評価を含むようにグラフ１７０を生成し、その結果、追加の機能がそれにより容易となり得る。

さらなる態様として、グラフモジュール１４０は、一実施形態において、制御フローグラフ１７０を電子的に提供するための命令をさらに含み、計装の包含などのソースコードの調整を容易にする。グラフ１７０は、起こり得る実行パス及び実行に関する関連状態を表す。従って、グラフ１７０は、ソースコード内の潜在的なエラー（例えば、無限ループ、露出される関数、安全でないデータ、障害など）についての見識を提供し、それは、様々なモジュールやシステムによって、コンパイルされた後のプログラムにおける困難（例えば、セキュリティホール、プログラム障害など）を回避するべく、ソースコードを改善するために活用され得る。

このように、グラフモジュール１４０は、一実施形態において、制御フローグラフ１７０の視覚的表現を生成し、統合開発環境（ＩＤＥ）内で視覚的表現を動的に表示することによってグラフ１７０を提供する。さらに、代替の実施形態では、グラフモジュール１４０は、システム１００内のさらなるモジュール／コンポーネント、またはグラフモジュール１４０から離れたシステム／モジュールにグラフ１７０を提供する。

例えば、一実施形態では、フォールト制御システム１００は、計装モジュール１５０を含む。計装モジュール１５０は、プロセッサによって実行されるとき、プロセッサ（例えば、プロセッサ１１０）に、制御フローグラフ１７０に従って、ソースコード内に計装を統合させる命令を含む。例えば、１つのアプローチでは、計装モジュール１５０は、実行時にプログラム内でランタイムチェックを提供する計装をソースコードに追加する。ランタイムチェックは、プログラムフロー、データの整合性を確保し、フォールトツリーで識別される状態の組み合わせによってプログラムで発生する障害／故障を防ぐための監視プロセスとして動作する。

従って、計装モジュール１５０は、グラフ１７０の変化、ソースコードへの新しいコードセグメントの包含、既存のコードセグメントへの変更、個別の要求など、例えば、ＩＤＥのＡＰＩ又は別の適切な仕組みを通じて、計装モジュール１５０への電子的要求として動作する、特定の状態を監視することができる。電子的要求は、一実施形態では、計装モジュール１５０を誘導して、プログラムの注目すべき態様を保護するためにランタイムチェックが実施されるように、ソースコード内に計装を含める。

前述のように、計装ポリシー１９０は、ソースコードのどの態様が計装されるべきかを（例えば、計装の場所およびタイプを特定するためのメトリクス又は他の条件を介して）識別するための様々なメカニズムを示す。様々なアプローチにおいて、計装モジュール１５０によって含められる計装は、プログラムの実行が制御フローグラフ１７０に従うことを保証し、特定のデータ引数の完全性を保証し、及び／又は障害を防止するためにフォールトツリーと関連付けられた状態を監視することによって、プログラム内のランタイムチェックを強化するためのものである。このように、計装モジュール１５０は、通常、ソースコード内に計装を含める方法を知るために、グラフ１７０を介して伝達される知識を使用する。例えば、計装モジュール１５０は、一実施形態において、アドレスチェック（例えば、データおよびプログラムフローのメモリアドレス）、変数／関数の戻り型チェック、データバインドチェック、オペコードチェック、コール−リターンペアの一致（例えば、非単一クラス）などを実行する計装を含める。

もちろん、計装モジュール１５０は、リアルタイムでソースコード内に計装を動的に含めるものとして説明されているが、代替の構成では、計装モジュール１５０は、ソースコードの完成バージョンまたは初期バージョン上で、計装を追加するように実行される。１つのアプローチでは、計装モジュール１５０は、ソースコードをプログラムにコンパイルする要求と並行して開始されたときに、計装を自動的に追加する。

いずれの構成においても、計装モジュール１５０は、ソースコードおよび制御フローグラフ１７０を分析して、計装をソースコード内に統合する。特に、計装モジュール１５０は、グラフ１７０の有効エッジによって特定されるソースコード内の工程遷移、グラフ１７０内に識別されるデータ引数が使用／変更される場所、特定の状態が障害を発生させる危険なパスなどのような、制御フローグラフ１７０とソースコードとの間の相関関係に従って、計装されるべきソースコードのセグメントを識別する。さらに、計装モジュール１５０は、ソースコードに従ってテンプレートの定義された計装をカスタマイズするように、定義された計装のテンプレートを変更することによって、識別されたセグメントに従い計装を自動的に追加する。このようにして、追加されたインストルメンテーションが希望どおりに機能することを確実にするために、定義されたインストルメンテーションのセットを事前にテストし、検証することができる。

制御フローグラフを生成し、そこからさらなる機能を提供することの追加の態様が、図７に関連して説明される。図７は、制御フローグラフの生成に関連する方法７００を示している。方法７００は、図１のフォールト制御システム１００の観点から説明される。方法７００は、フォールト制御システム１００と組み合わせて説明されるが、方法７００はフォールト制御システム１００内で実行されることに限定されず、むしろ、方法７００を実行することができるシステムの一例であることを理解されたい。

７１０で、分析モジュール１３０は、プログラムのソースコードに追加されているコードセグメントを監視する。本明細書で使用されるように、７１０でコードセグメントを追加することは、概して、新しいコードセグメントを追加すること、及びプログラムのソースコード内の既存のコードセグメントを変更することも指すことに留意されたい。より普遍的には、分析モジュール１３０は、ソースコードへの変更を伴う入力（例えば、コード、コマンドなど）について、コンピューティングデバイス内の統合開発環境（ＩＤＥ）への電子入力ストリームを監視する。従って、分析モジュール１３０は、一実施形態において、例えば、ＡＰＩを介したＩＤＥへの入力ストリームを継続的に監視して、いつソースコードが修正されている（すなわち、追加又は変更されている）かを識別する。結果として、注目すべき変更を検出すると、分析モジュール１３０は、制御フロー特性を識別するためにブロック７２０に進む。もちろん、方法７００は、グラフ１７０のリアルタイム検出および生成に関連して説明されているが、さらなる態様では、分析モジュール１３０は、ソースコードが完成したとき、又は、ソースコードの分析を開始する別の時期に生成され得る電子的要求または他の指示を７１０で検出する。

７２０で、分析モジュール１３０は、グラフ１７０の制御フロー特性を識別する。一実施形態では、分析モジュール１３０は、深さ優先探索を使用してソースコードを分析し、ソースコード内のステートメントを考察する。さらなる態様では、分析モジュール１３０は、ソースコードを考察し、理解され得るように特性を識別するための他の適切なアプローチを実施する。分析モジュール１３０がソースコードを考察しているとき、モジュール１３０は、少なくとも関数呼び出し、関数戻りアドレス、具体的および記号的関数引数、関数戻り値、および制御フロー特性としてのステートメント間の関係を識別するために、ソースコード内のステートメントを解析する。

様々な実装形態において、分析モジュール１３０は、検出された変更に関連するソースコードの部分を分析し、一方、さらなる態様では、分析モジュール１３０は、制御フロー特性を識別するためにソースコード全体を再分析する。概して、実行されるアプローチは、ソースコードの全サイズ、変更のサイズ、および分析を実行するために利用可能なリソースに関連する。例えば、一実施形態では、分析モジュール１３０は、示された選好に従って制御フロー特性を決定するために、部分的または完全なレビューを選択的に行う。分析モジュール１３０によって実行されるアプローチがどちらであっても、制御フロー特性は、グラフ１７０に表されるプログラムの工程内および／または工程間制御フロー転送に関する情報を提供する。

さらなる実施形態では、分析モジュール１３０は、７２０で、ソースコードも分析して、制御フロー特性の一部として非制御データ引数を識別する。分析モジュール１３０は、例えば、データ引数が制御データ引数であるか非制御データ引数であるかを定義するデータ型およびデータ型の関連付けなど、グラフポリシー１８０によって特定される指標に従ってデータ引数を識別する。いずれの場合も、分析モジュール１３０は、コードセグメントでソースコードを解析して、データ引数を識別し、そこからデータ特性を収集する。一実施形態では、データ特性は、制御フローグラフ１７０内の様々なポイントでのデータ引数の状態、およびデータ引数に関連する少なくとも１つの関係（例えば、データ引数が渡される関数）を示す。さらに、状態は、データ引数との許容される相互作用を識別するために、設定／開始、使用、および変更の少なくとも1つを含むことができるアクセスまたは使用のタイプを示す。

追加的に、分析モジュール１３０は、一実施形態において、制御フロー特性をグラフポリシー１８０と比較することによって、ソースコードのどのステートメントが脆弱性を含むかをさらに識別する。一実施形態では、グラフポリシー１８０は、セキュリティの脆弱性およびパフォーマンスのボトルネックを示す状態を定義する。従って、脆弱性およびボトルネックに関する追加情報も制御フロー特性内に含めることができ、その結果、情報はその後グラフ１７０と統合されて、ソースコードの多様な部分の特性に関するさらなる指標を提供する。いずれの場合も、分析モジュール１３０は、グラフ１７０に含めるために、制御フロー特性内に、プログラムフローに直接的および間接的に関連する態様を含むことができる。

７３０で、グラフモジュール１４０は、制御フローグラフ１７０を生成する。一実施形態では、グラフモジュール１４０は、グラフ１７０のノードおよび有向エッジを形成するために、７２０で識別される制御フロー特性を使用する。さらに、一実施形態では、グラフモジュール１４０は、ソースコードに追加される態様として区分的にグラフ１７０を生成する。さらに、制御フローグラフ１７０は、概して、プログラムに渡る実行パスを表すことを考慮し、そのため、グラフモジュール１４０は、制御フロー特性を使用して、グラフ１７０が形成される異なるコードセグメント（例えば、ノード）間のパス（例えば、有向エッジ）を識別する。このように、グラフモジュール１４０は、コードセグメントに適応させるように制御フローグラフの既存のノードおよびエッジを変更しながら、検出されたコードセグメントに対応する制御フロー特性を追加することによって、制御フローグラフ１７０を更新する。つまり、例えば、既存の有向エッジは、追加のノードが追加され、既存のノードが変更され、示される状態が変更され、又は新たな状態が追加されるなどと同時に、再ルーティングされてもよい。もちろん、さらなる態様では、グラフモジュール１４０は、区分的に行う代わりに、グラフ１７０を一度に完全に生成することができる。

７４０で、グラフモジュール１４０は、ソースコードの調整を容易にし、それによってプログラムを改善するために、制御フローグラフ１７０を提供する。前に説明したように、制御フローグラフ１７０は、注目すべきデータ引数などの関連する態様とともにプログラムの実行の表現を提供し、さもなくば、概して識別できないソースコードに関する見識を提供する。このように、様々なシステムは、グラフ１７０を活用して、ソースコードを操作し、および／または開発者にさらなる機能を提供することができる。

制御フローグラフを生成すること、特に、制御フローグラフ１７０と統合されるフォールトツリーを生成することの追加の態様が、図８に関連して説明される。図８は、非制御データ引数のデータ特性を制御フローグラフに統合することによって、データ引数を検証することに関連する方法８００を示している。方法８００は、図１のフォールト制御システム１００の観点から説明される。方法８００は、フォールト制御システム１００と組み合わせて説明されるが、方法８００は、フォールト制御システム１００内で実施されることに限定されず、むしろ、方法９００を実施することができるシステムの一例であることを理解されたい。さらに、方法８００は、概して、方法８００とは分けて説明されるが、方法７００と方法８００の両方は、１つのアプローチにおいて、並行して実行されて、グラフ１７０を作成するために使用され、その後、追加機能を容易にするために、計装モジュール１５０及び／又は他のシステムによって使用される関連情報を生成することを理解されたい。

８１０で、分析モジュール１３０は、要求を監視する。一実施形態では、要求は、フォールトツリー分析を開始するために生成される電子的要求である。様々なアプローチでは、要求は様々なソースから発せられる。例えば、要求は、ソースコードの変更に応答して、ソースコードを計装する要求に応答して、ソースコードをコンパイルする要求に応答して、などで生成され得る。概して、方法８００は、異なるイベントに応じてインスタンス化され得る。しかしながら、方法８００は、通常、方法７００と並行して実行され、したがって、同じまたは類似の出来事に応答して実行され得る。

８２０で、分析モジュール１３０は、１つ以上の安全関連機能を識別する。
一実施形態では、ブロック８２０での安全関連機能の識別は、方法７００のブロック７２０での制御フロー特性の識別と並行して行われる。分析モジュール１３０は、例えば、傷害または損傷をもたらす可能性または確率などのグラフポリシー１８０によって指定された指標に従って、安全関連機能を識別する。このように、分析モジュール１３０は、１つのアプローチにおいて、安全関連機能を示すポリシー１８０によって識別される特性についてソースコードをスキャンする。一般的な問題として、グラフポリシー１８０は、安全違反などの機能に関連して発生する可能性がある特定の障害、および関連するデバイスで引き起こされる可能性がある故障を指定することができる。

さらなる態様では、安全関連機能は、ソースコード内で事前にラベル付けされるか、さもなければタグ付けされ得る。そのような場合、安全関連機能の識別は、分析モジュール１３０がラベルについてソースコードをスキャンすることを含む。いずれの場合も、安全関連機能は、関連するデバイスの機能安全に影響を及ぼす、インパクトを与える、またはその他の方法で影響を与える機能である。関連するデバイスは、例えば、プログラムの故障が人への傷害、又はデバイスもしくはデバイスの近くにある他のデバイスへの損傷をもたらす可能性がある車両または他のデバイスである。さらに、機能安全は、一実施形態において、特定のタイプのデバイスに関連する業界固有の規格である機能安全規格に従って定義される。例えば、車両の場合、機能安全規格は、例えば、ＩＳＯ２６２６２または別の適切な機能安全規格である。

８３０で、分析モジュール１３０は、安全関連機能を分析して、フォールトツリーを生成する。一実施形態では、分析モジュール１３０は、フォールトツリー分析を実行し、実行状態を備えたブール論理ゲートを使用して、障害がいつ発生するか、およびプログラム内のどの実行パスが危険であるかを表す。状態は、少なくとも、プログラムへの入力から導出されるプログラムの実行状態と、障害が発生するプログラムの内部生成値を含む。以前に示したように、障害は機能安全基準に従って定義され得るか、さもなければ、機能とその機能に関連する関連ハードウェア（例えば、その機能によって制御されるハードウェア）との間で共有される特性に従って識別される。さらに、一実施形態では、フォールトツリー自体は、ソースコードの識別された態様と、障害を生じる識別された態様間の関係とを含む。

追加的に、分析モジュール１３０は、一実施形態では、障害を示すグラフポリシー１８０の態様をソースコード内のステートメントと比較することによって、ソースコードのどのステートメントが障害につながる脆弱性に関連づけられるかをさらに識別する。一実施形態では、グラフポリシー１８０は、障害を示す状態を定義する。代替の実施形態では、分析モジュール１３０は、この技術分野で理解され得るように、ソフトウェアフォールトツリー分析（ＦＴＡ）を実施する。いずれの場合も、分析モジュール１３０は、状態を識別し、障害をもたらすと決定された状態の論理的な組み合わせに従ってグラフを形成する。

８４０で、グラフモジュール１４０は、フォールトツリーを制御フローグラフ１７０に統合する。一実施形態では、グラフモジュール１４０は、８２０で提供されるフォールトツリーからの識別情報を使用して、描写された状態に対応する位置でグラフ１７０内に格納される注釈／タグを生成する。すなわち、例えば、グラフ１７０を通る様々な実行パスが、パスが危険であるかどうか、および危険である場合、どの状態が、危険なパスおよび障害の発生をもたらすか示すために注釈付けされるように、グラフ１７０のノードおよびエッジは、フォールトツリー内に具体化された障害特性で注釈付け／タグ付けされる。従って、特定のコードブロックを表し、フォールトツリーで識別された状態に関連するノードに対して、グラフモジュール１４０は、アクセスの関係および特性を示すために、関連する注釈をそのノードに追加する。従って、グラフモジュール１４０は、プログラム制御フローに関連する態様を含むようにグラフ１７０を積極的に発展させるだけでなく、グラフモジュール１４０はまた、さらなる情報でグラフ１７０を充実させるためにフォールトツリーに関する追加情報を提供する。

８５０で、グラフモジュール１４０は、制御フローグラフ１７０を電子的出力として提供する。以前に説明したように、制御フローグラフ１７０は、実行時に様々なステップでのデータ引数の使用に関する特性描写、及び状態の特定の組み合わせの下で、プログラムに障害を引き起こし得る危険なパスに関する状態とともに、プログラムの実行がどのように進行するかの表現を提供する。このように、グラフ１７０は、一般に別の方法では識別できないソースコードについての見識を提供する。これにより、様々なシステムは、グラフ１７０を活用して、ソースコードを操作し、及び／又はさらなる機能を提供することができる。

８５０で制御フローグラフ１７０を提供する１つの態様として、グラフモジュール１４０は、グラフ１７０を計装モジュール１５０に電子的に通信し、その結果、制御フローグラフ１７０で識別されるソースコードのセグメントは計装されることができ、計装の追加によるランタイムチェックの組み込みを通じて、データの完全性、プログラムフローの整合性、および障害耐性を確保することができる。さらに、以前に説明したように、グラフモジュール１４０は、一実施形態において、電子ディスプレイ上で開発者に表示される視覚的表現の形態の電子的出力としてグラフ１７０を提供することもできる。このように、グラフ１７０は、ノード、エッジ、注釈などによって表され、開発を容易にするための視覚化として提供され得る。

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

最初の注意点として、方法９００は、ブロック９１０、９２０、９３０を含むものとして示され、これらは、方法７００および８００の並列実行から生成されるグラフ１７０を電子的入力として受け入れると一般に理解されるべきである。

９１０で、計装モジュール１５０は、ソースコードを計装する要求を監視する。様々な実施形態では、要求は異なる形式をとることができる。例えば、１つのアプローチでは、要求は、グラフ１７０も変更されるソースコードへの変更と同時に行われる。すなわち、グラフ１７０がソースコードへの変更に従って更新されるとき、計装モジュール１５０も、その変更に対してリアルタイムでソースコードを計装するように機能する。

あるいは、計装要求は、ソースコードが完了すると、またはさらなる態様では、ソースコードがプログラムにコンパイルされるときに、システム１００によって生成される。従って、ソースコードを計装する要求は、一実施形態において、ＩＤＥ内で生成されたソースコードをコンパイルする要求に応答してシステム１００によって生成され、コンパイルの前に処理される。このように、計装モジュール１５０は、ソースコードが変更されるとき、またはソースコードがコンパイルされる準備ができると、リアルタイムで機能して、ソースコードを計装する。さらに別の態様では、計装モジュール１５０は、プログラム内にランタイムチェックを追加する要求に応答してソースコードを計装する。いずれの場合も、計装モジュール１５０は要求を監視し、その要求は、通常、グラフ１７０を含む。すなわち、システム１００は、９１０で、要求とともに、またはその一部として、グラフ１７０を計装モジュール１５０に提供する。

９２０で、計装モジュール１５０は、計装されるべきソースコードのセクション（例えば、コードセグメントまたは個々のステートメント）を識別する。一実施形態では、計装モジュール１５０は、コードセグメントに関連付けられたグラフ１７０内のラベル付けされた特性に従って、グラフ１７０内に表された識別された制御フローに従って、グラフ１７０内の識別された非制御データ引数に従って、フォールトツリーからグラフ１７０に注釈付された危険なパスに従って、及び／又は、計装ポリシー１９０によって定義されるさらなるメトリクス／特性に従って、コードセグメントを識別する。概して、計装モジュール１５０は、実行中のプログラムのプログラムフローの整合性、データの完全性、及び／又は障害耐性を保証するためにソースコードを計装している。従って、計装モジュール１５０は、機能間で制御を直接的または間接的に転送し、プログラムフローアドレスを調整し、データ引数を操作し、および他のそのようなコードセグメントに関与する、障害を生じるリスクがあるプログラムの態様を識別する。概して、注目されるコードセグメントは、グラフ１７０内のノードおよび有向エッジ、またはノードおよびエッジに関連付けられた状態（例えば、有向エッジによって具体化された制御転送）に関連する。

従って、さらなる態様では、計装モジュール１５０は、制御フローグラフ１７０に従ってソースコードを分析する。計装モジュール１５０はまた、１つ以上の実施形態において、コードセグメントが計装を含むために実装される計装ポリシー１９０を満たすかどうかを決定するために、個々のコードセグメントを分析することができる。つまり、機能／ステートメント内にいつ計装を含めるべきか、及び、例えば、その計装がどの程度まで含めるべきか（例えば、「完全な計装される」対「大まかな／最小限の計装」）を決定するために、重要度レベル、セキュリティレベルなどに応じた閾値のような様々な態様が、識別され得る。このようにして、プログラムのパフォーマンスとセキュリティを考慮し、必要とされないかもしれない場合に、計装、もしくは過度の計装を不必要に含めることを避けるように、計装をインテリジェントな方法で含めることができる。

いずれの場合も、計装モジュール１５０は、ソースコード内のすべてのコードセグメント／機能が、計装および／または完全に計装されるべきではないとのポリシーを実装できるので、９２０でのチェックは、コードセグメントが計装されるべきか、どの程度かを評価することを含むことができる。すなわち、例えば、計装モジュール１５０は、別個のコードセグメント／ステートメント／機能の特性を評価して、計装を含めるべきかどうか、およびどのレベルの計装（例えば、どの程度堅牢であるか／どの程度行き渡らせるか）が含まれるべきか決定する。計装モジュール１５０が計装は含まれるべきであると決定すると、計装モジュール１５０は、ブロック９３０で説明するように計装の統合を継続する。そうでなければ、計装モジュール１５０は、プログラムの特定の態様は計装を含まないことを注釈するか、さもなければログに記録することができる。

９３０で、計装モジュール１５０は、計装をソースコード内に統合する。以前に述べたように、一実施形態では、計装モジュール１５０は、制御データ引数、非制御データ引数のための、およびフォールトツリーを強化するための計装を含める。その結果、ソースコードに含まれる計装は、本質的にプログラム内に統合された監視プロセスであるランタイムチェックを実施する。ランタイムチェックは、プログラムの実行を監視して、データの完全性、プログラム制御フローの整合性、および障害防止を確保する。

例えば、ランタイムチェックは、プログラムがグラフ１７０によって表される実行パス外に向けられないことを保証し、データ（すなわち、変数）がソースコードから識別される許容される使用／変更外に悪意を持って変更されないことを保証し、障害をもたらし得る状態が発生しないことを保証し、または、万一障害が発生しても、プログラムの壊滅的な機能不全に陥ることなく障害が処理されることを保証するように機能し得る。1つのアプローチでは、計装はランタイムチェックを実施して障害を捉え、それにより、プログラムが回復、または障害や関連デバイスの損傷を防ぐバックアッププロセスに制御をハンドオーバーするフェイルオーバールーチンに、プログラムをリダイレクトする。例として、関連デバイスが自動ブレーキを提供する車両のコントローラであり、障害はプログラムが車両のブレーキに緊急制動状態を誤って適用する状態である場合、ランタイムチェックは、障害につながる状態の発生を識別し、緊急制動状態も防ぎつつ、故障を識別するバックアッププロセスに制御を受け渡す。このように、プログラムの障害耐性は、プログラム内の危険な実行パスの自動識別と、危険なパスに関連付けられた障害を防止する計装の自動組み込みによって改善される。

さらに、計装を統合するプロセスは、一実施形態において、計装モジュール１５０が、ソースコードに従って、定義された計装のテンプレートを修正することによって、識別されたセグメントに応じた計装を自動的に追加することを含む。計装モジュール１５０は、計装が統合されているコードセグメントに適合するようにテンプレートの変数を調整する。従って、計装モジュール１５０は、含まれる計装をカスタマイズして、特定の機能を達成すると同時に、例えば、事前に承認され、一般に正しく機能することが知られている計装も使用する。このようにして、計装モジュール１５０は、グラフ１７０を使用して、計装を介して実施されるランタイムチェックを通じて、結果として生じるプログラムを究極的に改善する追加の機能を提供する。このように、結果として得られるプログラムは、悪意のある攻撃からのプログラムのセキュリティと障害の防止を保証するより優れた計装によって改善される。

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

別の実施形態では、説明された方法及び／又はそれらの均等物は、コンピュータ実行可能命令で実現することができる。従って、一実施形態では、非一時的なコンピュータ可読媒体が、マシン（例えば、プロセッサ、コンピュータなど）によって実行されるとき、マシン（及び／又は関連するコンポーネント）にその方法を実行させる、格納されたコンピュータ実行可能命令を有して構成される。

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

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

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

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

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

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

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

「１つの実施形態」、「一実施形態」、「１つの例」、「一例」などへの言及は、そのように記載された実施形態または例が、特定の特徴、構造、特性、特質、要素、または限定を含むかもしれないが、すべての実施形態または例が、必ずしも、その特定の特徴、構造、特性、特質、要素、または限定を含むわけではない。さらに、「１つの実施形態では」という語句の繰り返しの使用は、同じ実施形態を指す場合もあるが、必ずしもそうとは限らない。

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

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

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

コンピュータ可読媒体に具現化されるプログラムコードは、限定されるものではないが、無線、有線、光ファイバー、ケーブル、ＲＦなど、またはこれらの任意の適切な組み合わせを含む、任意の適切な媒体を使用して送信されてもよい。本構成の態様の動作を実行するためのコンピュータプログラムコードは、Python、Go、Java（登録商標）、Ruby、Objective-C、Visual Base.NET、Smalltalk、C ++などのオブジェクト指向プログラミング言語、および「C」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語を含む、１つ以上のプログラミング言語の任意の組み合わせで記述されてもよい。プログラムコードは、スタンドアロンソフトウェアパッケージとして、完全にユーザのコンピュータ上で、部分的にユーザのコンピュータ上で、あるいは、一部をユーザのコンピュータ上でかつ一部を遠隔コンピュータ上で、もしくは、完全に遠隔コンピュータまたはサーバ上で実行されてもよい。後者のシナリオでは、遠隔コンピュータは、ローカルエリアネットワーク（ＬＡＮ）またはワイドエリアネットワーク（ＷＡＮ）を含む任意のタイプのネットワークを介してユーザのコンピュータに接続されてもよいし、または、その接続は、外部コンピュータになされてもよい（例えば、インターネットサービスプロバイダを使用したインターネット経由）。

本明細書で使用される「ａ」および「ａｎ」という用語は、１つではなく、１つ以上として定義される。本明細書で使用される「複数」という用語は、２つではなく、２つ以上として定義される。本明細書で使用される「別の」という用語は、少なくとも２番目またはそれ以上として定義される。本明細書で使用される「含む」および／または「有する」という用語は、包含する（すなわち、オープン言語）と定義される。本明細書で使用される「...および...の少なくとも１つ」というフレーズは、関連する列挙されたアイテムの１つ以上の任意のおよび全ての可能な組み合わせを指し、包含する。例として、「Ａ、Ｂ、およびＣの少なくとも１つ」というフレーズは、Ａのみ、Ｂのみ、Ｃのみ、またはそれらの任意の組み合わせ（たとえば、ＡＢ、ＡＣ、ＢＣまたはＡＢＣ）を含む。

本明細書の態様は、その主旨または本質的な特質から逸脱することなく、他の形態で具現化することができる。したがって、本明細書の範囲を示すものとして、前述の明細書で
はなく、以下の特許請求の範囲を参照すべきである。

Claims (20)

1. 安全関連機能のためのプログラムにおける制御フローを改善するためのフォールト制御システムであって、
   １つ以上のプロセッサと、
   その１つ以上のプロセッサに通信可能に結合され、分析モジュール（１３０）とグラフモジュール（１４０）とを格納するメモリ（１２０）と、を備え、
   分析モジュール（１３０）は、1つ以上のプロセッサによって実行されるとき、1つ以上のプロセッサに、プログラムの安全関連機能を識別させる命令を含み、
   安全関連機能は、関連する装置が機能安全基準に従って動作するかどうかに影響を与える、プログラムによって実行される機能と関連付けられており、
   グラフモジュール（１４０）は、1つ以上のプロセッサによって実行されるとき、1つ以上のプロセッサに、安全関連機能のフォールトツリーをプログラムの制御フローグラフの関連部分に統合させる命令を含み、
   制御フローグラフは、プログラム内の少なくとも手続き型の制御フローを識別し、フォールトツリーは、プログラムによって障害を生じさせるプログラム内の状態の組み合わせを示し、
   グラフモジュールは、プログラムの制御フローを改善するための電子的出力として制御フローグラフを提供するための命令を含む、フォールト制御システム。
2. 分析モジュールは、安全関連機能を分析してフォールトツリーを生成するための命令をさらに含み、
   状態は、少なくとも、プログラムへの入力から導出されるプログラムの実行状態と、障害をもたらすプログラムの内部生成値とを含み、
   分析モジュールは、障害がいつ発生し、プログラム内のどの実行パスが危険であるかを識別する実行状態を備えたブール論理を使用してフォールトツリー分析を実行する命令を含む、安全関連機能を分析してフォールトツリーを生成するための命令を含む、請求項１のフォールト制御システム。
3. 分析モジュールは、安全関連機能に関連する特性を示すグラフポリシーに従って、プログラムのソースコードを分析する命令を含む、安全関連機能を識別する命令を含み、
   特性は、故障が人に傷害をもたらす可能性がある装置の制御を含む、請求項１又は２のフォールト制御システム。
4. 障害は少なくとも安全違反、及び関連する装置のプログラム故障を含み、
   グラフモジュールは、障害をもたらす可能性がある制御フローグラフ内の危険なパスに注釈を付けることによってフォールトツリーを統合する命令を含む、請求項１又は２のフォールト制御システム。
5. グラフモジュールは、プログラムのソースコードから識別される制御フロー特性に従って制御フローグラフを生成する命令をさらに含み、
   制御フローグラフは、ソースコードのブロックを表すノードと、ブロック間の制御ハンドオーバーを表すノード間の有向エッジとを含み、
   フォールトツリーは、ソースコードの識別された態様と、障害を生じる識別された態様間の関係とを含む、請求項１乃至４のいずれか１項のフォールト制御システム。
6. グラフモジュールは、フォールトツリーの生成と並行して、制御フローグラフを生成する命令を含む、請求項５のフォールト制御システム。
7. 1つ以上のプロセッサによって実行されるとき、1つ以上のプロセッサに、制御フローグラフに従ってソースコード内に計装を統合させる命令を含む計装モジュール（１５０）をさらに備え、
   計装モジュールは、制御フローグラフに従ってランタイムチェックを提供する定義された計装のテンプレートを変更することによってソースコードに計装を自動的に追加する命令を含む、計装を統合する命令を含み、
   ランタイムチェックは、プログラムフローの整合性を保証し、フォールトツリーによって識別される障害の発生を防止するために、少なくとも、プログラムの実行パスを監視する請求項１乃至６のいずれか１項のフォールト制御システム。
8. 計装モジュールは、制御フローグラフの代替パスを実行するようにプログラムをリダイレクトすることによって、障害を回避する計装を追加する命令を含む、計装を統合する命令を含む、請求項７のフォールト制御システム。
9. 安全関連機能のためのプログラムにおけるフローを改善するための命令であって、１つ以上のプロセッサ（１１０）によって実行されるとき、１つ以上のプロセッサに、
   プログラムの安全関連機能を識別させ、
   安全関連機能は、関連する装置が機能安全基準に従って動作するかどうかに影響を与える、プログラムによって実行される機能と関連付けられており、
   安全関連機能のフォールトツリーをプログラムの制御フローグラフの関連部分に統合させ、
   制御フローグラフは、プログラム内の少なくとも手続き型の制御フローを識別し、フォールトツリーは、プログラムによって障害を生じさせるプログラム内の状態の組み合わせを示し、
   プログラムの制御フローを改善するための電子的出力として制御フローグラフを提供させる命令を格納する非一時的コンピュータ可読媒体。
10. 命令は、安全関連機能を分析してフォールトツリーを生成するための命令を含み、
    状態は、少なくとも、プログラムへの入力から導出されるプログラムの実行状態と、障害をもたらすプログラムの内部生成値とを含み、
    安全関連機能を分析してフォールトツリーを生成するための命令は、障害がいつ発生し、プログラム内のどの実行パスが危険であるかを識別する実行状態を備えたブール論理を使用してフォールトツリー分析を実行する命令を含む、請求項９の非一時的コンピュータ可読媒体。
11. 命令は、安全関連機能に関連する特性を示すグラフポリシーに従って、プログラムのソースコードを分析する命令を含む、安全関連機能を識別する命令を含み、
    特性は、故障が人に傷害をもたらす可能性がある装置の制御を含む、請求項９又は１０の非一時的コンピュータ可読媒体。
12. 障害は少なくとも安全違反、及び関連する装置のプログラム故障を含み、
    フォールトツリーを統合する命令は、障害をもたらす可能性がある制御フローグラフ内の危険なパスに注釈を付ける命令を含む、請求項９又は１０の非一時的コンピュータ可読媒体。
13. 命令は、プログラムのソースコードから識別される制御フロー特性に従って制御フローグラフを生成する命令を含み、
    制御フローグラフは、ソースコードのブロックを表すノードと、ブロック間の制御ハンドオーバーを表すノード間の有向エッジとを含み、
    フォールトツリーは、ソースコードの識別された態様と、障害を生じる識別された態様間の関係とを含む、請求項９乃至１２のいずれか１項の非一時的コンピュータ可読媒体。
14. 安全関連機能のためのプログラムにおけるフローを改善する方法であって、
    プログラムの安全関連機能を識別すること、
    安全関連機能は、関連する装置が機能安全基準に従って動作するかどうかに影響を与える、プログラムによって実行される機能と関連付けられており、
    安全関連機能のフォールトツリーをプログラムの制御フローグラフの関連部分に統合すること、
    制御フローグラフは、プログラム内の少なくとも手続き型の制御フローを識別し、フォールトツリーは、プログラムによって障害を生じさせるプログラム内の状態の組み合わせを示し、
    プログラムの制御フローを改善するための電子的出力として制御フローグラフを提供すること、を備える方法。
15. フォールトツリーを生成するために安全関連機能を分析すること、をさらに備え、
    状態は、少なくとも、プログラムへの入力から導出されるプログラムの実行状態と、障害をもたらすプログラムの内部生成値とを含み、
    フォールトツリーを生成するために安全関連機能を分析することは、障害がいつ発生し、プログラム内のどの実行パスが危険であるかを識別する実行状態を備えたブール論理を使用してフォールトツリー分析を実行することを含む、請求項１４の方法。
16. 安全関連機能を識別することは、安全関連機能に関連する特性を示すグラフポリシーに従って、プログラムのソースコードを分析することを含み、
    特性は、故障が人に傷害をもたらす可能性がある装置の制御を含み、
    障害は少なくとも安全違反、及び関連する装置の故障を含み、
    フォールトツリーを統合することは、障害をもたらす可能性がある制御フローグラフ内の危険なパスに注釈を付けることである、請求項１４又は１５の方法。
17. プログラムのソースコードから識別される制御フロー特性に従って制御フローグラフを生成すること、をさらに備え、
    制御フローグラフは、ソースコードのブロックを表すノードと、ブロック間の制御ハンドオーバーを表すノード間の有向エッジとを含み、
    フォールトツリーは、ソースコードの識別された態様と、障害を生じる識別された態様間の関係とを含む、請求項１４乃至１６のいずれか１項の方法。
18. 制御フローグラフの生成は、フォールトツリーの生成と並行して行われる、請求項１７の方法。
19. 制御フローグラフに従ってソースコード内に計装を統合すること、をさらに備え、
    計装を統合することは、制御フローグラフに従ってランタイムチェックを提供する定義された計装のテンプレートを変更することによってソースコードに計装を自動的に追加することを含み、
    ランタイムチェックは、プログラムフローの整合性を保証し、フォールトツリーによって識別される障害を防止するために、少なくとも、プログラムの実行パスを監視する請求項１４乃至１８のいずれか１項の方法。
20. 計装を統合することは、代替パスを実行するようにプログラムをリダイレクトすることによって、障害を回避する計装を追加することを含む、請求項１９の方法。

Images