[0006] 本件の第1の態様は、安全性を要求する分野における端末、例えば、車両搭載端末、航空宇宙における制御端末に適用される障害検出方法を提供する。
[0007] 方法は、第1のタスクの第1のスケジューリング・テーブルを取得するステップを含み、第1のスケジューリング・テーブルは第1のテスト・パターンを含み、第1のテスト・パターンはターゲットの論理回路の障害を検出するために使用されるものであり、ターゲットの論理回路は第1のタスクを実行するように構成された論理回路であり、第1のタスクはターゲットの障害検出時間インターバル(fault detection time interval,FDTI)において実行される。
[0008] 第1のタスクは、端末におけるターゲットFDTIにおいて実行されることを必要とするタスクである可能性があり、例えば、端末におけるターゲットFDTIにおいて実行されることを必要とするプロセス又はスレッドであってもよい。端末が第1のタスクを決定する方式は、第1のタスクをタスク・キューから取得することであってもよい。タスク・キュー内のタスクは、実行されるべきタスクであって実行されていないタスクである(又は、準備完了状態にあるタスクと呼ばれる)。端末は、第1のタスクの識別子(identifier,ID)を取得することによって第1のタスクを決定したり、或いは、第1のタスクに対応するデータ構造に基づいて第1のタスクを決定したりする可能性がある。第1のタスクに対応するスケジューリング・テーブルは、少なくとも1つのテストパターン(例えば、本件出願の実施形態で言及される第1のテスト・パターン及び第2のテスト・パターンを含む)を含む可能性がある。少なくとも1つのテスト・パターンは、第1のタスクの機械命令コードに対応し、少なくとも1つのテスト・パターンは、ターゲット論理回路の障害を検出するために使用される。少なくとも1つのテスト・パターンが第1のタスクの機械命令コードに対応することは、第1のタスクの機械命令コードの実行が当てにしているターゲット論理回路の障害検出が、少なくとも1つのテスト・パターンに基づいて実施される可能性があることを意味する。
[0009] 方法は、更に:第1のテスト・パターンはターゲットFDTIにおいて実行されているかどうかを検出するステップ;及び 第1のテスト・パターンはターゲットFDTIにおいて実行されていないことが検出された場合に、第1のスケジューリング・テーブルに基づいてターゲットFDTIにおいて第1のテスト・パターンを実行して、ターゲットの論理回路の障害を検出するステップを含む。
[0010] 同じFDTI内の異なるタスクに対応するテスト・パターン・セットは、重複していてもよい(即ち、2つのセットの和集合は空ではない)。FDTI期間におけるテスト・パターンの繰り返される実行を回避するために、FDTIにおける実行済みテスト・パターンが解析され、適切なスケジューリング・セットが生成される。第1のスケジューリング・テーブルに含まれるテスト・パターンが実行される前に、第1のスケジューリング・テーブルに含まれるテスト・パターンが現在のFDTI期間内で実行されているかどうかが検出される必要がある。テスト・パターンが実行されているならば、テスト・パターンの実行はそのままスキップされてもよく、或いは、テスト・パターンが実行されていないならば、テスト・パターンが実行されてもよい。
[0011] 本件において、第1のテスト・パターンは、第1のテスト・パターンがターゲットFDTIにおいて初めて実行されることを必要とする場合に限り実行される。しかしながら、第1のテスト・パターンがターゲットFDTIにおいて実行されている場合、第1のテスト・パターンはターゲットFDTIにおいて再度実行されず、その結果、同じテスト・パターンはFDTIにおいて1回だけ実行され、反復的には実行されない。これは、STLのテスト・パターンのプロセッサへの負担を軽減し、障害を検出する際にプロセッサにより費やされる時間を短縮し、プロセッサの動作効率を向上させる。
[0012] 一部の可能な実装において、ターゲットFDTIにおいて第1のテスト・パターンを実行した後に、本方法は、更に:
第2のタスクの第2のスケジューリング・テーブルを取得するステップであって、第2のスケジューリング・テーブルは第1のテスト・パターンを含み、ターゲットの論理回路は第2のタスクを実行するために使用される論理回路であり、第2のタスクはターゲットの障害検出時間インターバルFDTIにおいて実行される、ステップ;及び 第1のテスト・パターンはターゲットFDTIにおいて実行されていることに基づいて、ターゲットFDTIにおける第1のテスト・パターンの実行をスキップするステップを含む。
[0013] 第1のテスト・パターンがターゲットFDTIにおいて最初に実行されることを必要とする場合に、第1のテスト・パターンは実行される可能性があり、更に、第2のタスク(第2のタスクは第1のタスクとは相違する)が、FDTIにおいて実行されることを必要とする。このケースでは、第2のタスクの第2のスケジューリング・テーブルが取得される可能性があり、第2のスケジューリング・テーブルは、第1のテスト・パターンも含む。タスク・スケジューリングの間に、第1のテスト・パターンはターゲットFDTIにおいて実行されているという事実に基づいて、ターゲットFDTIにおいて、第1のテスト・パターンの実行はスキップされる可能性がある。このように、第1のテスト・パターンは、FDTIにおいて1回だけ実行され、反復的には実行されない。
[0014] 一部の可能な実装において、第1のテスト・パターンはターゲットFDTIにおいて実行されているかどうかを検出するステップは:
第1のテスト・パターンに対応する第1の識別子を取得するステップを含み、第1の識別子は、第1のテスト・パターンがターゲットFDTIにおいて実行されているかどうかを示すために使用される。
[0015] 第1の識別子は、ビット・マスクによって表現される可能性がある(例えば、ビット・マスクはSTLMaskであってもよい)。例えば、マスク内の第1のテスト・パターンに対応するビットSTLMaskが1である場合、それは、第1のテスト・パターンが現在のFDTI期間において既に実行されていることを示し;また、マスク内の第1のテスト・パターンに対応するビットSTLMaskが0である場合、それは、第1のテスト・パターンが現在のFDTI期間において実行されていないことを示す。FDTIに関する初期化が実行される場合に、第1の識別子STLMaskは0に設定され、タイマーがイネーブルにされる。タイマーの期間はFDTIである。タイマーがトリガされるたびに、第1の識別子は0にリセットされ、タイマーはリセットされる。例えば、第1のタスクが実行される前に、第1のテスト・パターンに対応する第1の識別子STLMaskが0であることの検出に基づいて、第1のテスト・パターンはターゲットFDTIにおいて実行されていない、ということが判定されてもよい。
[0016] 一部の可能な実装において、第1のテスト・パターンはターゲットFDTIにおいて実行されていないことを検出するステップは:
第1のテスト・パターンに対応する第1の識別子は、第1のテスト・パターンがターゲットFDTIにおいて実行されていないことを示している、ということを検出するステップ;
を含み、ターゲットFDTIにおいて第1のテスト・パターンを実行した後に、本方法は、更に:
第1のテスト・パターンはターゲットFDTIにおいて実行されていることを、第1の識別子が指定するように、第1の識別子を修正するステップを含む。
[0017] 一部の可能な実装において、第1のテスト・パターンはターゲットFDTIにおいて実行されていないことを検出した後に、本方法は、更に:
第1のテスト・パターンに対応する第2の識別子を取得するステップであって、第2の識別子は、第1のテスト・パターンは実行されることを必要とするかどうかを示すために使用されるものである、ステップ;及び
ターゲットFDTIにおいて第1のテスト・パターンを実行する前に、本方法は、更に:
第2の識別子は第1のテスト・パターンが実行されることを必要とすることを示している、ということを検出するステップを含む。
[0018] 第2の識別子は、第1のテスト・パターンが実行されることを必要とするかどうかを示すために使用される可能性がある。第1のテスト・パターンは、第1のテスト・パターンが実行される必要があることを第2の識別子が示す場合に限り、ターゲットFDTIにおいて実行される。第2の識別子は、第1の識別子に関連付けられる。第1の識別子が、第1のテスト・パターンはターゲットFDTIにおいて実行されていないことを示す場合に限り、第2の識別子は第1のテスト・パターンが実行される必要があることを示す。第1の識別子は、第1のテスト・パターンがターゲットFDTIにおいて実行されていることを示し、第2の識別子は、第1のテスト・パターンが実行されることを必要としないことを示す。
[0019] 一部の可能な実装において、ターゲットFDTIにおいて第1のテスト・パターンを実行した後に、本方法は、更に:
第1のテスト・パターンは実行されることを必要としないことを、第2の識別子が指定するように、第2の識別子を修正するステップを含む。
[0020] 一部の可能な実装において、ターゲット・タスクは、プロセス又はスレッドを含む。
[0021] 本件出願の第2の態様は端末を提供する。端末は処理ユニットと取得ユニットを含む。取得ユニットは、第1のタスクの第1のスケジューリング・テーブルを取得するように構成されており、第1のスケジューリング・テーブルは第1のテスト・パターンを含み、第1のテスト・パターンはターゲットの論理回路の障害を検出するために使用されるものであり、ターゲットの論理回路は第1のタスクを実行するために使用される論理回路であり、第1のタスクはターゲットの障害検出時間インターバルFDTIにおいて実行される。処理ユニットは、第1のテスト・パターンはターゲットFDTIにおいて実行されているかどうかを検出し;及び 第1のテスト・パターンはターゲットFDTIにおいて実行されていないことが検出された場合に、ターゲットFDTIにおいて第1のテスト・パターンを実行して、ターゲットの論理回路の障害を検出するように構成されている。
[0022] 一部の可能な実装において、処理ユニットは、更に:第1のテスト・パターンはターゲットFDTIにおいて実行されていることが検出された場合に、ターゲットFDTIにおける第1のテスト・パターンの実行をスキップするように構成されている。
[0023] 一部の可能な実装において、取得ユニットは、第1のテスト・パターンがターゲットFDTIにおいて実行された後に、第2のタスクの第2のスケジューリング・テーブルを取得するように構成されており、第2のスケジューリング・テーブルは第1のテスト・パターンを含み、ターゲットの論理回路は第2のタスクを実行するように構成された論理回路であり、第2のタスクはターゲットの障害検出時間インターバルFDTIにおいて実行される。
[0024] 処理ユニットは、第1のテスト・パターンはターゲットFDTIにおいて実行されている場合に、ターゲットFDTIにおける第1のテスト・パターンの実行をスキップするように更に構成されている。
[0025] 一部の可能な実装において、取得ユニットは、第1のテスト・パターンに対応する第1の識別子を取得するように更に構成されており、第1の識別子は、第1のテスト・パターンがターゲットFDTIにおいて実行されているかどうかを示すために使用される。
[0026] 一部の可能な実装において、処理ユニットは、第1のテスト・パターンに対応する第1の識別子は、第1のテスト・パターンがターゲットFDTIにおいて実行されていないことを示している、ということを検出し;及び
第1のテスト・パターンがターゲットFDTIにおいて実行された後に、第1の識別子を修正し、その結果、第1のテスト・パターンはターゲットFDTIにおいて実行されていることを、第1の識別子が指定するように、更に構成されている。
[0027] 一部の可能な実装において、処理ユニットは、更に:
第1のテスト・パターンはターゲットFDTIにおいて実行されていないことを検出した後に、第1のテスト・パターンに対応する第2の識別子を取得するステップであって、第2の識別子は、第1のテスト・パターンは実行されることを必要とするかどうかを示すために使用されるものである、ステップ;及び
ターゲットFDTIにおいて第1のテスト・パターンが実行される前に、第2の識別子は、第1のテスト・パターンが実行されることを必要とすることを示している、ということを検出するステップを行うように構成されている。
[0028] 一部の可能な実装において、処理ユニットは、ターゲットFDTIにおいて第1のテスト・パターンが実行された後に、第2の識別子を修正し、その結果、第1のテスト・パターンは実行されることを必要としないことを、第2の識別子が指定するように更に構成されている。
[0029] 一部の可能な実装において、ターゲット・タスクは、プロセス又はスレッドを含む。
[0030] 本件の実施形態において、第1のテスト・パターンは、第1のテスト・パターンがターゲットFDTIにおいて初めて実行されることを必要とする場合に限り実行される。しかしながら、第1のテスト・パターンがターゲットFDTIにおいて実行されている場合、第1のテスト・パターンはターゲットFDTIにおいて再度実行されず、その結果、同じテスト・パターンはFDTIにおいて1回だけ実行され、反復的には実行されない。これは、STLのテスト・パターンのプロセッサへの負担を軽減し、障害を検出する際にプロセッサにより費やされる時間を短縮し、プロセッサの動作効率を向上させる。
[0031] 本件出願の第3の態様は端末を提供し、端末はプロセッサを含み、プロセッサは:
第1のタスクの第1のスケジューリング・テーブルを取得するステップであって、第1のスケジューリング・テーブルは第1のテスト・パターンを含み、第1のテスト・パターンはターゲットの論理回路の障害を検出するために使用されるものであり、ターゲットの論理回路は第1のタスクを実行するように構成された論理回路であり、第1のタスクはターゲットの障害検出時間インターバルFDTIにおいて実行される、ステップ;
第1のテスト・パターンはターゲットFDTIにおいて実行されているかどうかを検出するステップ;及び
第1のテスト・パターンはターゲットFDTIにおいて実行されていないことが検出された場合に、ターゲットFDTIにおいて前記第1のテスト・パターンを実行してターゲットの論理回路の障害を検出するステップを行うように構成されている。
[0032] 可能な実装において、プロセッサは、更に:
第1のテスト・パターンはターゲットFDTIにおいて実行されていることが検出された場合に、ターゲットFDTIにおける第1のテスト・パターンの実行をスキップするように構成されている。
[0033] 可能な実装において、プロセッサは、更に:
第1のテスト・パターンがターゲットFDTIにおいて実行された後に、第2のタスクの第2のスケジューリング・テーブルを取得するステップであって、第2のスケジューリング・テーブルは第1のテスト・パターンを含み、ターゲットの論理回路は第2のタスクを実行するように構成された論理回路であり、第2のタスクはターゲットの障害検出時間インターバルFDTIにおいて実行される、ステップ;及び
第1のテスト・パターンはターゲットFDTIにおいて実行されていることに基づいて、ターゲットFDTIにおける第1のテスト・パターンの実行をスキップするステップ;を行うように構成されている。
[0034] 可能な実装において、プロセッサは、具体的に:
第1のテスト・パターンに対応する第1の識別子を取得するように構成されており、第1の識別子は、第1のテスト・パターンがターゲットFDTIにおいて実行されているかどうかを示すために使用されるものである。
[0035] 可能な実装において、プロセッサは、具体的に:
第1のテスト・パターンに対応する第1の識別子は、第1のテスト・パターンがターゲットFDTIにおいて実行されていないことを示している、ということを検出し;及び
第1のテスト・パターンがターゲットFDTIにおいて実行された後に、第1の識別子を修正し、その結果、第1のテスト・パターンはターゲットFDTIにおいて実行されていることを、第1の識別子が指定するように構成されている。
[0036] 可能な実装において、プロセッサは、更に:
第1のテスト・パターンはターゲットFDTIにおいて実行されていないことを検出した後に、第1のテスト・パターンに対応する第2の識別子を取得するステップであって、第2の識別子は、第1のテスト・パターンは実行されることを必要とするかどうかを示すために使用されるものである、ステップ;及び
ターゲットFDTIにおいて第1のテスト・パターンが実行される前に、第2の識別子は第1のテスト・パターンが実行されることを必要とすることを示している、ということを検出するステップ;を行うように構成されている。
[0037] 可能な実装において、プロセッサは、更に:
ターゲットFDTIにおいて第1のテスト・パターンが実行された後に、第1のテスト・パターンは実行されることを必要としないことを、第2の識別子が指定するように、第2の識別子を修正するように構成されている。
[0038] 一部の可能な実装において、ターゲット・タスクは、プロセス又はスレッドを含む。
[0039] 本件出願の第4の態様は、コンピュータ読み取り可能な記憶媒体を提供する。コンピュータ読み取り可能な記憶媒体は、コンピュータ・プログラムを記憶する。コンピュータ・プログラムがコンピュータ上で実行されると、コンピュータは第1の態様の任意の実装による方法を実行することが可能になる。
[0040] 本件出願の第5の態様は、コンピュータ・プログラム製品を提供する。コンピュータ・プログラム製品がコンピュータ上で実行されると、コンピュータは第1の態様の任意の何れかの実装による方法を実行することが可能になる。
[0041] 本件出願の第6の態様は、1つ以上のプロセッサを含むチップを提供する。プロセッサのうちの全部又は一部は、メモリに記憶されたコンピュータ・プログラムを読み込んで実行し、前述の態様の可能な実装のうちの任意の何れかによる方法を実行するように構成されている。オプションとして、チップはメモリを含み、メモリ及びプロセッサは、回路又はワイヤを使用することによってメモリに接続される。更に、オプションとして、チップは通信インターフェースを更に含み、プロセッサは通信インターフェースに接続される。通信インターフェースは、処理されることを必要とするデータ、情報、又はその両方を受信するように構成されている。プロセッサは、データ及び/又は情報を通信インターフェースから取得し、データ及び/又は情報を処理し、通信インターフェースを介して処理結果を出力する。通信インターフェースは、入力/出力インターフェースであってもよい。本件出願の実施形態において提供される方法は、1つのチップによって実施されてもよいし、或いは、又は複数のチップによって連携して実施されてもよい。
[0042] 本件出願の実施形態は障害検出方法を提供し、本方法は:第1のタスクの第1のスケジューリング・テーブルを取得するステップであって、第1のスケジューリング・テーブルは第1のテスト・パターンを含み、第1のテスト・パターンはターゲットの論理回路の障害を検出するために使用されるものであり、ターゲットの論理回路は第1のタスクを実行するために使用される論理回路であり、第1のタスクはターゲットの障害検出時間インターバルFDTIにおいて実行される、ステップ;第1のテスト・パターンはターゲットFDTIにおいて実行されているかどうかを検出するステップ;及び 第1のテスト・パターンはターゲットFDTIにおいて実行されていないことが検出された場合に、第1のスケジューリング・テーブルに基づいてターゲットFDTIにおいて第1のテスト・パターンを実行して、ターゲットの論理回路の障害を検出するステップ;を含む。第1のテスト・パターンは、第1のテスト・パターンがターゲットFDTIにおいて初めて実行されることを必要とする場合に限り実行される。しかしながら、第1のテスト・パターンがターゲットFDTIにおいて実行されている場合、第1のテスト・パターンはターゲットFDTIにおいて再度実行されず、その結果、同じテスト・パターンはFDTIにおいて1回だけ実行され、反復的には実行されない。これは、STLのテスト・パターンのプロセッサへの負担を軽減し、障害を検出する際にプロセッサにより費やされる時間を短縮し、プロセッサの動作効率を向上させる。
[0055] 以下は、添付の図面を参照しながら本件出願の実施形態を説明している。説明される実施形態は、本件出願の実施形態の全てではなく、その一部に過ぎないことは明らかである。当業者は、新しいシナリオの出現及び技術開発に伴い、本件出願の実施形態において提供される技術的解決策は同様な技術的問題にも適用可能である、ということを知ることが可能である。
[0056] 本件出願の明細書、特許請求の範囲、及び添付の図面において、“第1”、“第2”などの用語は、同様なオブジェクトどうし区別するように意図されているが、必ずしも特定の順序又はシーケンスを示すとは限らない。そのように呼ばれるデータは、適切な状況においては交換可能であり、その結果、本件で説明される実施形態は、本件で例示又は説明されている順序以外の順序で実施されることが可能である、ということが理解されるべきである。更に、“含む(include)”、“含有する(contain)”という用語及び何らかのその他の派生語は、非排他的な包含をカバーすることを意味しており、例えば、ステップやモジュールのリストを含むプロセス、方法、システム、製品、又はデバイスは、必ずしもそれらのステップやモジュールに限定されず、明示的に列挙されていなかったり、或いはそのようなプロセス、方法、システム、製品、又はデバイスにとって本質的であるその他のステップやモジュールを含む可能性がある。本件出願におけるステップの命名又は番号付けは、方法手順におけるステップが、命名又は番号付けによって示される時間的/論理的な順序で実行されることを必要する、ということを意味してはいない。同一又は類似の技術的効果を達成できる限り、命名されたり又は番号付けられたりしたプロシジャにおけるステップの実行順序は、達成されるべき技術的課題に基づいて変更されることが可能である。
[0057] コンピュータ分野においては、例えば、集積回路内での短絡や開回路によって引き起こされる永続的な障害、又は、自然放射線にさらされることや粒子衝突によって引き起こされるビット反転のようなランダムなハードウェア障害が、データ処理装置内で発生する可能性がある。
[0058] 多数の分野におけるデータ処理装置の幅広い適用に伴い、データ処理装置において発生するハードウェア障害によって引き起こされる損失(loss)を回避するために、“機能的安全性(functional safety)”の概念が提案される。機能的安全性とは、電子システム障害によって引き起こされる許容不可能なリスクは存在しないことを意味する。機能的安全性の最終的なゴールは、電子システム障害によって引き起こされる人的傷害や多大な損失を防止することである。
[0059] 例えば、航空宇宙、輸送、及び医療のような高い安全性要件を有する分野では、機能安全要件を満たすために、相応の安全性機構が提供される。これらの安全性機構は、傷害が検出された後にシステムが安全な状態にあることを確実にして、危害を防止することを必要とする。例えば、自動車の分野では、典型的な安全性リスクは、通常、アンチ・ロック・システム又はパワー・ステアリング・システムの電子制御ユニットにおける故障によって引き起こされる。アンチ・ロック・システムやパワー・ステアリング・システムの電子制御ユニットに障害が発生すると、車両において致命的な衝突が発生する可能性がある。システムが安全であることを保証し且つ安全性リスクを防止するために、発生した障害は、適時に検出されて対処されることを必要とする。
[0060] 一般的に言えば、システム内で障害が発生した場合に、安全性機構は、障害を検出し、その障害を適時に処理して、危険が生じる前にシステムが安全な状態に到達できることを確実にする必要がある。通常、障害が発生した時間から、障害が検出される時間までのインターバルは、障害検出時間インターバル(Fault Detection Time Interval, FDTI)と呼ばれ、障害が検出された時間から、システムが安全な状態に入る時間までのインターバルは、障害処理時間インターバル(Fault Handle Time Interval, FHTI)と呼ばれる。例えば、図1aは、本件出願の実施形態によるFDTI及びFHTIの概略図である。危険を回避するためには、システムに障害が発生した後一定期間内に、システムは安全な状態に到達することを必要とする。即ち、FDTIとFHTIの合計は、時間閾値以下であることを必要とする。従って、FHTIが障害を処理するのに十分な長さであることを保証するために、障害をスムーズに処理できることを保証するために、FDTIをできるだけ短縮することが重要である。
[0061] 現在、関連技術における障害検出実現方法は、デュアル・コア・ロックステップ(Dual-core Lockstep, DCLS)である。DCLSの実装は、以下のように説明される:2つのプロセッサが、同じプログラムを実行し、2つのプロセッサの出力結果を比較ロジックに入力して、2つのプロセッサの出力結果が同じであるかどうかを比較する。2つのプロセッサの出力結果が同じである場合、障害は発生していないと判定することが可能であり;或いは、2つのプロセッサの出力結果が異なる場合、プロセッサにおいて障害が発生していると判定することが可能である。この障害検出方式は、障害を効果的に検出することが可能であるが、同じプログラムを実行するために2つのプロセッサを使用する必要があり、これは、高コストであり且つ柔軟性に乏しいという欠点を有する。
[0062] 従って、従来技術では、ソフトウェア・ベースのビルトイン・セルフ・テスト(software-based built-in self-test, SBIST)という別のソフトウェア・ベースの障害検出方法が提供されている。その障害検出方法では、プロセッサが、STL内のテスト・パターンを周期的に実行して論理回路の障害を検出する。DCLSと比較して、障害検出方法は、より低いコストであり且つより高い柔軟性を有する。しかしながら、システムは、通常、多数の論理回路を有するので、全ての論理回路の障害検出を実施するために、STLは、通常、多数のテスト・パターンを含む。従って、プロセッサがSTL内のテスト・パターンを周期的に実行することは、プロセッサのかなり重い負担を生じさせ、即ち、プロセッサは、障害を検出する際により多くの時間を費やす必要があり、それによって、プロセッサの動作効率に影響を及ぼす。
[0063] この点に鑑みて、障害検出を実行するプロセスにおいて、端末は、現在実行中のタスクに対応するスケジューリング・テーブルを決定して、スケジューリング・テーブルに含まれるテスト・パターンを実行することが可能である。スケジューリング・テーブルは、タスクの機械命令コードに対応するテスト・パターンのみを含むので、端末は、スケジューリング・テーブルに基づいて障害を検出し、その結果、ソフトウェア・テスト・ライブラリ内の全てのテスト・パターンの実行を回避することができる。これは、プロセッサの負荷を軽減し、プロセッサの動作効率を効果的に向上させる。
[0064] 図1cに示されるように、SBISTスケジューリングは、低レベル(low level,LL)スケジューリング及び高レベル(high level,HL)スケジューリングという2つのパートに分けることが可能である。LLスケジューリングは、主に、STLにおけるテスト・パターン切り替えのコンテキストの保存及び復元、並びに、特定のテスト・パターンの呼び出しのために使用される。HLスケジューリングは、タスク・スケジューリングとしてSBISTを使用する。フルSTLは、長時間を費やし、システムのリアル・タイム・パフォーマンスに大きく影響する。HLスケジュールは、スケジューリングの柔軟性を高めるために、カーネル・モードに入ることが可能である。これは、リアル・タイム・システムに対してよりフレンドリーであり、推奨されるものでもある。
[0065] しかしながら、既存の実装では、HLスケジューラは、粗い粒度でSTLの実行時間及び期間を取得し、STLにおけるテスト・パターンに関する情報にあまり気付いておらず、細かい粒度での制御を実装することはできていない。或るFDTIにおいて、実行されることを必要とする複数のタスクが存在する可能性があり、FDTIにおいて、実行されることを必要とする複数のタスクの各々に対応するテスト・パターンが、実行されることを必要とする。しかしながら、異なるタスクに対応するテスト・パターンが繰り返される可能性があり、実行されるべき各タスクに対応するテスト・パターンがFDTIにおいて完全に実行されている場合、複数の反復したテスト・パターンが実行される可能性がある。或るFDTIにおいて、同じテスト・パターンは、システムの安全性を保証するために1回だけ実行されることを必要とする。従って、前述のSBISTスケジューリング方式は、長いSBISTタスク・ブロッキング時間を引き起こし、更に、プロセッサの重い負担を生じさせる。即ち、プロセッサは、障害を検出するために、より多くの時間を費やすことを必要とし、それによって、プロセッサの動作効率に影響を及ぼす。
[0066] 本件出願の実施形態における端末は、安全性要件を有する分野におけるデータ処理デバイスである可能性がある。現在、例えば、端末は:輸送における車載端末、航空宇宙における制御端末、産業制御(industrial control)における無線端末、自動運転(self driving)における無線端末、遠隔医療手術(remote medical surgery)における無線端末、スマート・グリッド(smart grid)における無線端末、輸送安全(transportation safety)における無線端末、スマートシティ(smart city)における無線端末、スマート・ホーム(smart home)における無線端末などである可能性がある。
[0067] 図1bは、本件出願の実施形態による端末101の構造の概略図である。
[0068] 図1bに示されるように、端末101は、プロセッサ103を含み、プロセッサ103は、システム・バス105に結合される。プロセッサ103は、1つ以上のプロセッサである可能性がある。各プロセッサは、1つ以上のプロセッサ・コアを含む可能性がある。ビデオ・アダプタ(video adapter)107が更に含まれ、ビデオ・アダプタはディスプレイ109を駆動することが可能であり、ディスプレイ109はシステム・バス105に結合される。システム・バス105は、バス・ブリッジ111を介して入力/出力(I/O)バスに結合される。I/Oインターフェース115は、I/Oバスに結合される。I/Oインターフェース115は、複数のI/Oデバイス、例えば、入力デバイス117(タッチスクリーンなど)、マルチメディア・ディスク(メディア・トレイ)121(コンパクト・ディスク・リード・オンリー・メモリ(compact disc read-only memory,CD-ROM)、及びマルチメディア・インターフェースなど)と通信する。トランシーバ123(無線通信信号を送信及び/又は受信することが可能である)、カメラ155(静的及び動的デジタル・ビデオ画像をキャプチャすることが可能である)、及び、外部USBインターフェース125が更に含まれる。オプションとして、I/Oインターフェース115に接続されるインターフェースは、USBインターフェースであってもよい。
[0069] プロセッサ103は、縮小命令セット演算(reduced instruction set Computing, RISC)プロセッサ、複合命令セット演算(complex instruction set computing, CISC)プロセッサ、又はそれらの組み合わせを含む、任意の従来のプロセッサである可能性がある。オプションとして、プロセッサは、ASICのような専用装置であってもよい。
[0070] 端末101は、ネットワーク・インターフェース129を介してソフトウェア配置サーバー149と通信する可能性がある。例えば、ネットワーク・インターフェース129は、ハードウェア・ネットワーク・インターフェース、例えばネットワーク・アダプタである。ネットワーク127は、インターネットのような外部ネットワークであってもよいし、イーサーネットや仮想プライベート・ネットワーク(virtual private network, VPN)のような内部ネットワークであってもよい。オプションとして、ネットワーク127は、代替的に、無線ネットワーク、例えば、Wi-Fiネットワーク又はセルラー・ネットワークであってもよい。
[0071] ハード・ディスク・ドライブ・インターフェース131は、システム・バス105に結合される。ハードウェア・ドライブ・インターフェースは、ハード・ディスク・ドライブ133に接続される。システム・メモリ135は、システム・バス105に結合される。システム・メモリ135で動いているデータは、オペレーティング・システム(OS)137、アプリケーション143、及び端末101のスケジューリング・テーブルを含む可能性がある。
[0072] オペレーティング・システムは、シェル139及びカーネル(kernel)141を含む。シェル139は、ユーザーとオペレーティング・システムのカーネルとの間のインターフェースである。シェルは、オペレーティング・システムの最外層である。シェルは、ユーザーとオペレーティング・システムとの間の相互作用:ユーザーからの入力を待つこと、ユーザーからオペレーティング・システムへの入力を解釈すること、及びオペレーティング・システムの様々な出力結果を処理することを管理する。
[0073] カーネル141は、メモリ、ファイル、周辺機器、及びシステム・リソースを管理するように構成されたオペレーティング・システムの構成要素を含む。カーネル141は、ハードウェアと直接的に対話し、オペレーティング・システムのカーネルは、通常、プロセスを実行し、プロセス間通信を提供し、CPU時間スライス管理、割り込み、メモリ管理、及びI/O管理のような機能を提供する。
[0074] 例えば、端末101が車載端末である場合、アプリケーション143は、車両運転制御に関連するプログラム、例えば、自動運転車両と道路上の障害物との間の相互作用を管理するためのプログラム、自動運転車両の経路又は速度を制御するためのプログラム、及び、自動運転車両と道路上の別の自動運転車両との間の相互作用を制御するためのプログラムを含む。実施形態において、アプリケーション143が実行されることを必要とする場合に、端末101は、ソフトウェア配置サーバー149からアプリケーション143をダウンロードする可能性がある。実施形態において、端末101がアプリケーション143をソフトウェア配置サーバー149からダウンロードする場合に、端末101は、ソフトウェア配置サーバー149から、アプリケーション143に対応するスケジューリング・テーブルをダウンロードする可能性もある。
[0075] センサー153は、端末101に関連付けられている。センサー153は、端末101の周囲の環境を検出するように構成される。例えば、センサー153は、動物、自動車、障害物、横断歩道などを検出する可能性がある。また、センサー153は、例えば、上述した動物、自動車、障害物、横断歩道のような物体の周囲の環境、例えば、動物の周辺の環境、例えば、動物の周囲に出現する他の動物、天候、周囲環境の明るさ等を検出する可能性もある。オプションとして、端末101が自動運転車両内に位置する場合に、センサーは、レーダー・システムなどである可能性がある。
[0076] 上記は、本件出願の実施形態において提供される障害検出方法の適用シナリオを説明している。以下は、障害検出方法の実行プロセスを詳細に説明している。
[0077] 図2は、本件出願の実施形態による障害検出方法200の概略フローチャートである。図2に示すように、障害検出方法200は、以下のステップを含む。
[0078] ステップ201:第1のタスクの第1のスケジューリング・テーブルを取得する。ここで、第1のスケジューリング・テーブルは第1のテスト・パターンを含み、第1のテスト・パターンはターゲットの論理回路の障害を検出するために使用されるものであり、ターゲットの論理回路は第1のタスクを実行するように構成された論理回路であり、第1のタスクはターゲットの障害検出時間インターバルFDTIにおいて実行される。
[0079] この実施形態では、端末のノーマルな実行プロセスにおいて、発生した障害を遅れずに検出できることを確実にするために、端末は、障害検出方法200を周期的に実行し、例えば、30ミリ秒や50ミリ秒ごとに障害検出方法200を実行する可能性がある。
[0080] 可能な実施形態において、第1のタスクは、端末におけるターゲットFDTIにおいて実行されることを必要とするタスクである可能性があり、例えば、端末におけるターゲットFDTIにおいて実行されることを必要とするプロセス又はスレッドである可能性がある。端末によって第1のタスクを決定する方式は、タスクキューから第1のタスクを取得するものであってもよい。タスク・キュー内のタスクは、実行されるべきタスクであって実行されていないタスクである(又は、実行準備完了状態にあるタスクと言及される)。端末は、第1のタスクの識別子(identifier,ID)を取得することによって第1のタスクを決定する可能性があり、或いは、第1のタスクに対応するデータ構造に基づいて第1のタスクを決定する可能性があり、例えば、スレッドIDに基づいて、第1のタスクが参照する特定のスレッドを決定する可能性がある。例えば、第1のタスクがプロセスである場合に、第1のタスクは、例えば、車両ビデオ検査プロセス、車両速度算出プロセス、レーダー検出プロセス、車両アンチ・ロック・プロセス、タイヤ空気圧検出プロセスのようなプロセスである可能性がある。
[0081] 可能な実施形態において、非決定論的スケジューリング・シナリオでは、スケジューラは、次のFDTIにおいて実行されることを必要とするタスクを予測しないが、FDTIに入る場合に限り、次のFDTIにおいて実行されることを必要とするタスクをリアル・タイムで検知する。従って、優先度プリエンプション方式(priority preemption manner)がSBISTタスクに対して設定される。FDTIにおいて、各々の共通タスク(non-SBISTタスク)が実行される前に、そのタスクに対応するSTLサブセット(少なくとも1つのテスト・パターンを含む)が,中断されない方式で実行される。このシナリオでは、スケジューラは、第1のタスクを検知するために、現在のFDTIにおいて実行されることを必要とするタスクを、リアル・タイムで検知する可能性がある。
[0082] 可能な実施形態において、決定論的スケジューリング・シナリオでは、スケジューラは、次のFDTIにおいて実行されることを必要とするタスクを予測することが可能である。決定論的スケジューリングを確実にするために、ワースト・ケース実行時間(worst Case execution time, WCET)が、ほとんどのタスクについて静的に決定されて、優先順位を決定する必要がある。従って、このシナリオでは、デフォルトの高優先度はSBISTタスクには適しておらず、決定論的スケジューリング構成を実行するために、スケジューリング・アルゴリズムはSBISTタスクに適合させられることを必要とする。このシナリオでは、スケジューラは、第1のタスクを検知するために、現在のFDTIの前に、FDTIにおいて実行されることを必要とするタスクを検知することが可能である。
[0083] この実施形態において、端末で実行されることが可能な如何なるタスクも、対応するスケジューリング・テーブルを有する可能性がある。これらのスケジューリング・テーブルは、例えば、端末に予め設定されていてもよいし、或いは、タスク・ベースの機械命令コードに基づいて端末によって生成されてもよい。従って、端末は、複数のスケジューリング・テーブルにおいて、第1のタスクに対応する第1のスケジューリング・テーブルを決定する可能性がある。例えば、第1のタスクがプロセスである場合、端末は、プロセスIDに基づいて、第1のタスクに対応する第1のスケジューリング・テーブルを決定することが可能である。
[0084] 第1のタスクに対応するスケジューリング・テーブルは、少なくとも1つのテスト・パターン(例えば、本件出願の実施形態で言及される第1のテスト・パターン及び第2のテスト・パターンを含む)を含む可能性があり、少なくとも1つのテスト・パターンは、第1のタスクの機械命令コードに対応し、少なくとも1つのテスト・パターンは、ターゲット論理回路の障害を検出するために使用される。少なくとも1つのテスト・パターンが第1のタスクの機械命令コードに対応することは、第1のタスクの機械命令コードの実行が依存しているターゲット論理回路の障害検出が、少なくとも1つのテスト・パターンに基づいて実施できることを意味する。
[0085] 単に、マシン命令コードを実行する場合に、端末は、端末における論理回路に依存することを必要とし、即ち、論理回路に基づいてマシン命令コードを実行することを必要とする。従って、第1のタスクの機械命令コードに対応する少なくとも1つのテスト・パターンが決定されると、端末が第1のタスクの機械命令コードを実行する場合に使用される論理回路について、障害検出が、少なくとも1つのテスト・パターンに基づいて実施される可能性がある。
[0086] 端末が第1のタスクを実行するプロセスにおいて、第1のタスクを実行するプロセスで使用されることを必要とする論理回路において障害が発生した場合に、端末が第1のタスクを実行すると、論理回路の障害に起因して安全性リスクが生じる可能性がある、ということを理解することが可能である。従って、テスト・パターンは、第1のタスクに対応するスケジューリング・テーブルに基づいて実行され、その結果、使用されることを必要とする論理回路の障害検出を実施することが可能になり、安全性リスクの発生は回避される。別の論理回路については、現在の端末は対応するタスクを実行しないので、即ち、別の論理回路は使用されることを必要としないので、たとえ論理回路のこの部分で障害が発生したとしても、安全性リスクは発生しない。
[0087] 可能な実施形態において、第1のスケジューリング・テーブル内の少なくとも1つのテスト・パターンは、第1のマッピング関係及び少なくとも1つの命令タイプに基づいて決定される。第1のマッピング関係は、命令タイプとテスト・パターンとの間のマッピング関係を含み、少なくとも1つの命令タイプは、第2のマッピング関係とターゲット・タスクの機械命令コード・セットとに基づいて決定され、第2のマッピング関係は、機械命令コードと命令タイプとの間のマッピング関係を含み、機械命令コード・セットは、複数の機械命令コードを含む。例えば、第1のテスト・パターンは、第1のマッピング関係及び少なくとも1つの命令タイプに基づいて決定される可能性がある。
[0088] 図3を参照すると、前処理プロセスにおいて、命令スキャニングが、システム実行プロセスにおけるタスクに対して実行される可能性があり、対応するスケジューリング・テーブルが各タスクについて生成される(各スケジューリング・テーブルは少なくとも1つのテスト・パターンを含む)。STLスケジューリング分析プロセスにおいて、HLスケジューラのアナライザーは、タスクキュー情報、FDTI時間、及び、前処理段階で生成された各タスクのスケジューリング・テーブルに基づいて、現在の周期におけるSBISTテスト・シーケンスを分析する。STLスケジューリング生成プロセスにおいて、分析結果がジェネレータを通り、スケジューリング対象のSTLテスト・パターン・セットが生成され、LLスケジューリング・プロセスにおいて、HLによって転送されたSTLテスト・セットがスケジューリングされ、LLスケジューリングを介して最高特権階層で実行される。
[0089] ステップ202:第1のテスト・パターンはターゲットFDTIにおいて実行されているかどうかを検出する。
[0090] 可能な実施形態において、第1のタスクの第1のスケジューリング・テーブルが取得された後に、第1のテスト・パターンがターゲットFDTIにおいて実行されているかどうかが検出されてもよい。
[0091] 本件出願のこの実施形態では、同じFDTIの中で異なるタスクに対応するテスト・パターン・セットは重複している可能性がある(即ち、2つのセットの和集合は空ではない)。FDTI期間内におけるテスト・パターンの反復される実行を回避するために、FDTIにおいて実行されたテスト・パターンが分析され、適切なスケジューリング・セットが生成される。
[0092] 可能な実施形態において、第1のスケジューリング・テーブルに含まれるテスト・パターンが実行される前に、第1のスケジューリング・テーブルに含まれるテスト・パターンが現在のFDTI期間内に実行されているかどうかが検出されることを必要とする。テスト・パターンが実行されている場合には、テスト・パターンの実行はそのままスキップされることが可能であり、或いは、テスト・パターンが実行されていない場合には、テスト・パターンが実行されることが可能である。
[0093] 以下は、第1のテスト・パターンがターゲットFDTIにおいて実行されているかどうかを如何にして検出するかを説明している。
[0094] 可能な実施形態において、第1の識別子は、第1のテスト・パターンがターゲットFDTIにおいて実行されているかどうかを示すために使用される可能性がある。FDTIの初期化が実行される場合に、第1の識別子は、第1のテスト・パターンがターゲットFDTIにおいて実行されていないことを示すことが可能であり、第1のテスト・パターンがFDTIにおいて初めて実行された後に、第1の識別子は修正され、その結果、第1の識別子は、第1のテスト・パターンがターゲットFDTIにおいて実行されている、ということを示すことが可能になる。
[0095] 例えば、第1のタスクが実行される前に、第1のテスト・パターンに対応する第1の識別子が、第1のテスト・パターンはターゲットFDTIにおいて実行されていないことを示している、ということを検出したことに基づいて、第1のテスト・パターンはターゲットFDTIにおいて実行されていない、ということが判定されてもよい。
[0096] 例えば、第1の識別子は、ビット・マスクによって表現される可能性がある(例えば、ビット・マスクはSTLMaskであってもよい)。例えば、マスク内の第1のテスト・パターンに対応するビットSTLMaskが1である場合、それは、第1のテスト・パターンが現在のFDTI期間において既に実行されていることを示し;また、マスク内の第1のテスト・パターンに対応するビットSTLMaskが0である場合、それは、第1のテスト・パターンが現在のFDTI期間において実行されていないことを示す。FDTIに関する初期化が実行される場合に、第1の識別子STLMaskは0に設定され、タイマーがイネーブルにされる。タイマーの期間はFDTIである。タイマーがトリガされるたびに、第1の識別子は0にリセットされ、タイマーはリセットされる。例えば、第1のタスクが実行される前に、第1のテスト・パターンに対応する第1の識別子STLMaskが0であることの検出に基づいて、第1のテスト・パターンはターゲットFDTIにおいて実行されていない、ということが判定されてもよい。
[0097] 更に、第2の識別子は、第1のテスト・パターンが実行されることを必要とするかどうかを示すために更に使用される可能性がある。第1のテスト・パターンは、第1のテスト・パターンが実行されることを必要とすることを、第2の識別子が示している場合に限り、ターゲットFDTIにおいて実行される。第2の識別子は、第1の識別子に関連付けられる。第2の識別子は、第1のテスト・パターンがターゲットFDTIにおいて実行されていないことを、第1の識別子が示す場合に限り、第1のテスト・パターンが実行されることを必要する、ということを示す。第1の識別子は、第1のテスト・パターンがターゲットFDTIにおいて実行されていることを示し、第2の識別子は、第1のテスト・パターンが実行されることを必要としないことを示す。
[0098] 例えば、第1のタスクが実行される前に、第1のテスト・パターンが実行されることを必要とすることを第2の識別子が示していることの検出に基づいて、第1のテスト・パターンは実行されることを必要としている、ということが判定されてもよい。
[0099] 例えば、図4を参照すると、第2の識別子は、ビット・マスクによって表現される可能性がある(例えば、ビット・マスクはSTLNeedExcuteMaskであってもよい)。マスク内の第1のテスト・パターンに対応するビットSTLNeedExcuteMaskが1である場合、それは、第1のテスト・パターンが現在のFDTI期間において依然として実行されることを必要としていることを示し;マスク内の第1のテスト・パターンに対応するビットSTLNeedExcuteMaskが0である場合、それは、第1のテスト・パターンが現在のFDTI期間において実行されることを必要としないことを示す。
[0100] FDTIに関する初期化が実行される場合に、第2の識別子STLNeedExcuteMaskは0に設定され、タイマーがイネーブルにされる。タイマーの期間はFDTIである。タイマーがトリガされるたびに、第2の識別子STLNeedExcuteMaskは0にリセットされ、タイマーはリセットされる。例えば、第1のタスクが実行される前に、第1のテスト・パターンに対応する第2の識別子STLNeedExcuteMaskが1であることの検出に基づいて、第1のテスト・パターンは実行されることを必要としている、ということが判定されてもよい。
[0101] ステップ203:第1のテスト・パターンはターゲットFDTIにおいて実行されていないことが検出された場合に、第1のスケジューリング・テーブルに基づいてターゲットFDTIにおいて第1のテスト・パターンを実行して、ターゲット論理回路の障害を検出する。
[0102] 本件出願のこの実施形態において、第1のテスト・パターンはターゲットFDTIにおいて実行されていないことが検出された場合に、第1のテスト・パターンは、第1のスケジューリング・テーブルに基づいてターゲットFDTIにおいて実行される可能性があり;或いは、第1のテスト・パターンがターゲットFDTIにおいて実行されていることが検出された場合に、第1のテスト・パターンの実行は、ターゲットFDTIにおいてスキップされる。換言すれば、第1のテスト・パターンは、ターゲットFDTIにおいて最初に実行されることを必要としている場合に限り実行され、ターゲットFDTIにおいて実行された場合には、第1のテスト・パターンはターゲットFDTIにおいて再度実行されない。
[0103] 可能な実施形態において、第1のテスト・パターンがターゲットFDTIにおいて初めて実行されることを必要とする場合に、第1のテスト・パターンが実行されてもよく、更に、第2のタスク(第2のタスクは第1のタスクとは異なる)がFDTIにおいて実行されることを必要とする。このケースにおいて、第2のタスクの第2のスケジューリング・テーブルが取得されてもよく、第2のスケジューリング・テーブルは第1のテスト・パターンも含む。タスク・スケジューリングの間に、第1のテスト・パターンがターゲットFDTIにおいて実行されているという事実に基づいて、第1のテスト・パターンの実行は、ターゲットFDTIにおいてがスキップされる可能性がある。このように、第1のテスト・パターンは、FDTI内で1回だけ実行され、繰り返し実行されることはない。
[0104] 可能な実施形態において、第1のテスト・パターンがターゲットFDTIにおいて実行された後に、第1の識別子は修正されて、第1のテスト・パターンがターゲットFDTIにおいて実行されていることを、第1の識別子に指定させてもよい。同様に、第1のテスト・パターンがターゲットFDTIにおいて実行された後に、第2の識別子は修正されて、第1のテスト・パターンは実行されることを必要としないことを、第2の識別子に指定させてもよい。例えば、第1のテスト・パターンは実行されることを必要としないことを、第2の識別子が示しているという事実に基づいて、第1のテスト・パターンの実行は、ターゲットFDTIにおいてスキップされてもよく、その結果、第1のテスト・パターンはFDTIにおいて1回だけ実行され、繰り返して実行されない。
[0105] 例えば、図5を参照すると、非決定論的スケジューリング・シナリオにおいて、スケジューラは、次のFDTIにおいて実行されることを必要とするタスクを予測せず、FDTIに入った後に限り、次のFDTIにおいて実行されることを必要とするタスクをリアル・タイムで検知する。従って、優先度プリエンプション方式がSBISTタスクに対して設定される。FDTIにおいて、各々の共通タスク(non-SBISTタスク)が実行される前に、そのタスクに対応するSTLサブセット(少なくとも1つのテスト・パターンを含む)が、中断されない方式で実行される。このシナリオでは、スケジューラは、タスクを検知するために、現在のFDTIにおいて実行されることを必要とするタスクを、リアル・タイムで検知する可能性がある。スケジューラは、タスク・キューの中から準備完了状態のタスクをスケジューリングし、タスクのタスクIDを取得し、タスクのタスクIDに基づいて、対応するSTLサブセット、即ち、テスト・パターン・セットを見出し、STLMaskに基づいて、各STLサブセット内のテスト・パターンが現在のFDTI期間内で実行されるかどうかを判定する。テスト・パターンが実行されている場合、次のラウンドの判定が実行され;或いは、テスト・パターンが実行されていない場合、STLNeedExcuteMaskにおける対応するビットが1に設定され、テスト・パターンが実行され、実行されたテスト・パターンに対応するSTLMask及びSTLNeedExcuteMaskのビットは、実行されるように設定され、全てのテスト・パターンが横断されるまで実行される必要はない。現在スケジューリングされているタスクのSBISTタスクが実行されるようになった後、スケジューリングされたタスクは実行され続ける可能性がある。タスクキュー内の他のタスクは、順次実行される。
[0106] 図6を参照すると、水平座標は時間を表し、垂直座標はタスクの優先度を表し、各々の着色のブロックは、タスクが現在の時間に動作しているタイム・スライスであってCPUを占有しているタイム・スライスを表す。FDTI期間は、原点から始まり破線までである。この期間において、タスク1,2,3がスケジューラによってスケジューリングされると、先ず、タスクに対応するSBSITタスクが実行される。SBISTタスクは、タスクに関連するSTLテスト・パターン・セットを実行する。SBISTタスクは、より高い優先度を有し、テスト・シーケンスを中断することはできない。FDTIスケジューリング時間において、各タスクのテスト・パターンサブセットは一意であることを必要とする。例えば、タスク3が実行される前に、タスク3に対応するテスト・パターン・サブセット(テスト・パターン・サブセット内にあるテスト・パターンであってタスク2に対応するテスト・パターン以外)が実行される可能性がある。
[0107] 例えば、図7を参照すると、決定論的スケジューリング・シナリオにおいて、スケジューラは、次のFDTIにおいて実行されることを必要とするタスクを予測することが可能である。決定論的スケジューリングを確実にするために、ワースト・ケース実行時間(worst Case execution time, WCET)が、ほとんどのタスクについて静的に決定されて、優先順位を決定する必要がある。従って、このシナリオでは、デフォルトの高優先度はSBISTタスクには適しておらず、決定論的スケジューリング構成を実行するために、決定論的スケジューリング・アルゴリズムはSBISTタスクに適合させられることを必要とする。このシナリオでは、スケジューラは、タスクを検知するために、現在のFDTIの前に、FDTIにおいて実行されることを必要とするタスクを検知することが可能である。スケジューラは、タスク・キューから準備完了状態のタスクをスケジューリングする可能性がある。タスクが共通タスクである場合、共通タスクが実行される。具体的には、タスクのタスクIDが取得されることが可能であり、対応するSTLセット、即ちテスト・パターン・セットが、タスクのタスクIDに基づいて発見され、現在のFDTIがタイム・アウトしたかどうかが判定される。現在のFDTIがタイム・アウトしていない場合、各STLサブセット内のテスト・パターンについて、テスト・パターンが現在のFDTI期間内に実行されたかどうかが、STLMaskに基づいて判定される。テスト・パターンが実行された場合に、全てのテスト・パターンがトラバースされるまで、次のラウンドの判定が実行される。テスト・パターンが実行されていない場合、STLNeedExcuteMaskにおける対応するビットは1に設定される。FDTIがタイム・アウトすると、STLmaskにおける全てのビットが0にリセットされる。スケジューリングされたタスクがSBISTタスクである場合、SBISTテスト・シーケンスがSTLNeedExcuteMaskに基づいて実行される。実行の後に、STLNeedExcuteMaskにおける対応するビットは0に設定され、STLmaskにおける対応するビットは1に設定される。
[0108] 本件出願のこの実施形態において、図9に関し、SBISTタスク内のテスト・パターンは、3つの状態:(実行されない,実行されることを必要としない)、(実行されていない,実行されることを必要とする)、及び(実行されている,実行されることを必要としない)に分類されることが可能であり、初期状態は(実行されない,実行されることを必要としない)である。アナライザーが使用された後に、テスト・パターン・ステータスは、変更されないままであるか、又は(実行されていない,実行されることを必要とする)である。テスト・パターンが実行された後に、(実行されていない,実行されることを必要とする)のステータスは、(実行されている,実行されることを必要としない)に変更される。
[0109] 以下のテーブルに示すように、従来技術におけるSBISTスケジューリングと比較して、本件出願のこの実施形態における方法は、SBISTテスト・シーケンス実行時間を本発明において、従来技術におけるそれと比較して約75%短縮している。
[0110] 本件出願の実施形態は障害検出方法を提供し、本方法は:第1のタスクの第1のスケジューリング・テーブルを取得するステップであって、第1のスケジューリング・テーブルは第1のテスト・パターンを含み、第1のテスト・パターンはターゲットの論理回路の障害を検出するために使用されるものであり、ターゲットの論理回路は第1のタスクを実行するために使用される論理回路であり、第1のタスクはターゲットの障害検出時間インターバルFDTIにおいて実行される、ステップ;第1のテスト・パターンはターゲットFDTIにおいて実行されているかどうかを検出するステップ;及び 第1のテスト・パターンはターゲットFDTIにおいて実行されていないことが検出された場合に、第1のスケジューリング・テーブルに基づいてターゲットFDTIにおいて第1のテスト・パターンを実行して、ターゲットの論理回路の障害を検出するステップを含む。
第1のテスト・パターンは、第1のテスト・パターンがターゲットFDTIにおいて初めて実行されることを必要とする場合に限り実行される。しかしながら、第1のテスト・パターンがターゲットFDTIにおいて実行されている場合、第1のテスト・パターンはターゲットFDTIにおいて再度実行されず、その結果、同じテスト・パターンはFDTIにおいて1回だけ実行され、反復的には実行されない。これは、STLのテスト・パターンのプロセッサへの負担を軽減し、障害を検出する際にプロセッサにより費やされる時間を短縮し、プロセッサの動作効率を向上させる。
[0111] 図1aないし図9に対応する実施形態に基づいて、本件出願の実施形態における前述の解決策をより良く実施するために、以下、前述の解決策を実施するように構成された関連デバイスを更に提供する。具体的に、図10は、本件出願の実施形態による端末1000の構造の概略図である。端末1000は処理ユニット1001と取得ユニット1002を含む。取得ユニット1002は、第1のタスクの第1のスケジューリング・テーブルを取得するように構成されており、第1のスケジューリング・テーブルは第1のテスト・パターンを含み、第1のテスト・パターンはターゲットの論理回路の障害を検出するために使用されるものであり、ターゲットの論理回路は第1のタスクを実行するために使用される論理回路であり、第1のタスクはターゲットの障害検出時間インターバルFDTIにおいて実行される。処理ユニット1001は、第1のテスト・パターンはターゲットFDTIにおいて実行されているかどうかを検出し;第1のテスト・パターンはターゲットFDTIにおいて実行されていないことが検出された場合に、ターゲットFDTIにおいて第1のテスト・パターンを実行して、ターゲットの論理回路の障害を検出するように構成されている。
[0112] 一部の可能な実装において、処理ユニット1001は、更に:第1のテスト・パターンはターゲットFDTIにおいて実行されていることが検出された場合に、ターゲットFDTIにおける第1のテスト・パターンの実行をスキップするように構成されている。
[0113] 一部の可能な実装において、取得ユニット1002は、第1のテスト・パターンがターゲットFDTIにおいて実行された後に、第2のタスクの第2のスケジューリング・テーブルを取得するように構成されており、第2のスケジューリング・テーブルは第1のテスト・パターンを含み、ターゲットの論理回路は第2のタスクを実行するように構成された論理回路であり、第2のタスクはターゲットの障害検出時間インターバルFDTIにおいて実行される。
[0114] 処理ユニット1001は、第1のテスト・パターンはターゲットFDTIにおいて実行されている場合に、ターゲットFDTIにおける第1のテスト・パターンの実行をスキップするように更に構成されている。
[0115] 一部の可能な実装において、取得ユニット1002は、第1のテスト・パターンに対応する第1の識別子を取得するように更に構成されており、第1の識別子は、第1のテスト・パターンがターゲットFDTIにおいて実行されているかどうかを示すために使用される。
[0116] 一部の可能な実装において、処理ユニット1001は、第1のテスト・パターンに対応する第1の識別子は、第1のテスト・パターンがターゲットFDTIにおいて実行されていないことを示している、ということを検出し;及び
第1のテスト・パターンがターゲットFDTIにおいて実行された後に、第1の識別子を修正し、その結果、第1のテスト・パターンはターゲットFDTIにおいて実行されていることを、第1の識別子が指定するように、更に構成されている。
[0117] 一部の可能な実装において、処理ユニット1001は、更に:
第1のテスト・パターンはターゲットFDTIにおいて実行されていないことを検出した後に、第1のテスト・パターンに対応する第2の識別子を取得するステップであって、第2の識別子は、第1のテスト・パターンは実行されることを必要とするかどうかを示すために使用されるものである、ステップ;及び
ターゲットFDTIにおいて第1のテスト・パターンが実行される前に、第2の識別子は、第1のテスト・パターンが実行されることを必要とすることを示している、ということを検出するステップを行うように構成されている。
[0118] 一部の可能な実装において、処理ユニット1001は、ターゲットFDTIにおいて第1のテスト・パターンが実行された後に、第2の識別子を修正し、その結果、第1のテスト・パターンは実行されることを必要としないことを、第2の識別子が指定するように更に構成されている。
[0119] 一部の可能な実装において、ターゲット・タスクは、プロセス又はスレッドを含む。
[0120] 本件の実施形態において、第1のテスト・パターンは、第1のテスト・パターンがターゲットFDTIにおいて初めて実行されることを必要とする場合に限り実行される。しかしながら、第1のテスト・パターンがターゲットFDTIにおいて実行されている場合、第1のテスト・パターンはターゲットFDTIにおいて再度実行されず、その結果、同じテスト・パターンはFDTIにおいて1回だけ実行され、反復的には実行されない。これは、STLのテスト・パターンのプロセッサへの負担を軽減し、障害を検出する際にプロセッサにより費やされる時間を短縮し、プロセッサの動作効率を向上させる。
[0121] 以下は、本件出願の実施形態において提供される端末デバイスを説明している。端末デバイスは、図11における情報推薦デバイスである可能性がある。図11は、本件出願の実施形態による端末デバイスの構造の概略図である。端末デバイス1100は、具体的には、仮想現実VRデバイス、携帯電話、タブレット・コンピュータ、ノートブック・コンピュータ、インテリジェント・ウェアラブル・デバイスなどである可能性がある。これは本件において限定されない。具体的には、端末デバイス1100は、受信機1101、送信機1102、プロセッサ1103、及びメモリ1104を含む(端末デバイス1100には1つ以上のプロセッサ1103が存在する可能性があり、図11では、1つのプロセッサが例として使用されている)。プロセッサ1103は、アプリケーション・プロセッサ11031及び通信プロセッサ11032を含む可能性がある。本件出願の一部の実施形態では、受信機1101、送信機1102、プロセッサ1103、及びメモリ1104は、バスを介して又は別の方法で接続される可能性がある。
[0122] メモリ1104は、リード・オンリー・メモリとランダム・アクセス・メモリとを含み、命令やデータをプロセッサ1103に与えることが可能である。メモリ1104の一部は、不揮発性ランダム・アクセス・メモリ(non-volatile random access memory, NVRAM)を更に含む可能性がある。メモリ1104は、プロセッサ及び動作命令、実行可能モジュール又はデータ構造、それらのサブネット、又はそれらの拡張セットを記憶する。動作命令は、様々な動作を実施するための様々な動作命令を含む可能性がある。
[0123] プロセッサ1103は、端末デバイスの動作を制御する。特定のアプリケーションにおいて、端末デバイスの構成要素は、バス・システムを介して互いに結合される。データ・バスに加えて、バス・システムは、電力バス、制御バス、ステータス信号バスなどを更に含む可能性がある。しかしながら、明確な説明のために、様々なタイプのバスは図面においてはバス・システムとして記される。
[0124] 本件出願の前述の実施形態において開示される方法は、プロセッサ1103に適用されてもよいし、或いは、プロセッサ1103によって実現されてもよい。プロセッサ1103は、集積回路チップである可能性があり、信号処理能力を有する。実装プロセスにおいて、前述の方法の各ステップは、プロセッサ1103内のハードウェアの統合された論理回路又はソフトウェアの形態における命令を使用することによって完了されてもよい。プロセッサ1103は、汎用プロセッサ、デジタル信号プロセッサ(digital signal processor, DSP)、マイクロプロセッサ、又はマイクロコントローラであってもよい。プロセッサ1103は、特定用途向け集積回路(application-specific integrated circuit, ASIC)、フィールド・プログラマブル・ゲート・アレイ(field programmable gate array, FPGA)若しくは別のプログラマブル論理デバイス、個別ゲート、若しくはトランジスタ論理デバイス、又は、個別ハードウェア構成要素を更に含む可能性がある。プロセッサ1103は、本件出願の実施形態において開示される方法、ステップ、及び論理ブロック図を実現又は実施することが可能である。汎用プロセッサはマイクロプロセッサであってもよいし、又はプロセッサは任意の従来のプロセッサなどであってもよい。本件出願の実施形態を参照しながら開示される方法のステップは、ハードウェア復号化プロセッサによって直接的に実行され完了されてもよいし、又は、復号化プロセッサ内のハードウェア・モジュールとソフトウェア・モジュールとの組み合わせを使用することによって実行され完了されてもよい。ソフトウェア・モジュールは、当技術分野における成熟した記憶媒体、例えば、ランダム・アクセス・メモリ、フラッシュ・メモリ、リード・オンリー・メモリ、プログラマブル・リード・オンリー・メモリ、電気的に消去可能なプログラマブル・メモリ、又はレジスタに配置される可能性がある。記憶媒体はメモリ1104に配置され、プロセッサ1103はメモリ1104内の情報を読み込み、プロセッサのハードウェアとの組み合わせにおいて前述の方法のステップを完了する。具体的には、プロセッサ1103は、メモリ1104内の情報を読み込み、プロセッサ1103のハードウェアとの組み合わせにおいて、前述の実施形態におけるステップ201からステップ203のデータ処理に関連するステップを完了することが可能である。
[0125] 受信機1101は、入力されたデジタル又はキャラクタ情報を受信し、端末デバイスの関連する設定及び機能制御に関連する信号入力を生成するように構成される可能性がある。送信機1102は、第1インターフェースを介してデジタル又はキャラクタ情報を出力するように構成されてもよい。送信機1102は、ディスク・グループ内のデータを修正するために、第1のインターフェースを介してディスク・グループに命令を送信するように更に構成される可能性がある。
[0126] 本件出願の実施形態は、コンピュータ・プログラム製品を更に提供する。コンピュータ・プログラム製品がコンピュータにおいて実施されると、コンピュータは、前述の実施形態における図2に対応する実施形態で説明される障害検出方法のステップを実行できるようになる。
[0127] 本件出願の実施形態は、コンピュータ読み取り可能な記憶媒体を更に提供する。コンピュータ読み取り可能な記憶媒体は、信号処理のためのプログラムを記憶する。プログラムがコンピュータ上で実行されると、コンピュータは、前述の方法の実施形態における画像処理方法のステップを実行できるようになる。
[0128] 本件出願のこの実施形態において提供される画像処理装置は、チップであってもよい。チップは、処理ユニットと通信ユニットとを含む。処理ユニットは、例えば、プロセッサであってもよく、通信ユニットは、例えば、入力/出力インターフェース、ピン、回路などであってもよい。処理ユニットは、記憶ユニットに記憶されたコンピュータ実行可能命令を実行する可能性があり、その結果、実行デバイス内のチップは、実施形態において説明されるデータ処理方法を実行し、或いは、トレーニング・デバイス内のチップは、実施形態において説明されるデータ処理方法を実行する。オプションとして、記憶ユニットは、チップ内の記憶ユニット、例えば、レジスタ又はバッファである。あるいは、記憶ユニットは、無線アクセス・デバイス内ではあるがチップ外部にある記憶ユニット、例えば、リード・オンリー・メモリ(read-only memory, ROM)、静的な情報及び命令を記憶することが可能な別のタイプの静的記憶デバイス、又は、ランダム・アクセス・メモリ(random access memory, RAM)であってもよい。
[0129] 説明を簡便かつ簡潔にする目的で、前述のシステム、装置、及びユニットの詳細な動作プロセスについては、前述の方法の実施形態における対応するプロセスを参照されたい、ということは当業者によって明確に理解されるであろう。詳細はここで再び説明されない。
[0130] 本件出願において提供される幾つかの実施形態では、開示されるシステム、装置、及び方法は、他の方式で実施される可能性がある、ということを理解することが可能である。例えば、説明された装置の実施形態は単なる例であるに過ぎない。例えば、ユニットへの分割は、単に論理的な機能分割であるに過ぎず、実際の実装では他の分割である可能性がある。例えば、複数のユニット又は構成要素は、別のシステムに組み合わせられたり又は統合されたりしてもよいし、或いは、一部の特徴は無視されたり又は実行されなかったりしてもよい。更に、図示又は説明された相互結合又は直接的な結合又は通信接続は、一部のインターフェースを使用することによって実施される可能性がある。装置又はユニット間の間接的な結合又は通信接続は、電子的、機械的、又はその他の形態で実現されてもよい。
[0131] 個々のパートとして説明されたユニットは、物理的に個別的であってもなくてもよく、ユニットとして表示されたパートは、物理的なユニットであってもなくてもよく、一カ所に配置されていてもよいし、或いは、複数のネットワーク・ユニット上に分散されていてもよい。ユニットのうちの一部又は全部は、実施形態の解決策の目的を達成するために、実際の要件に基づいて選択される可能性がある。
[0132] 更に、本件出願の実施形態における機能ユニットは、1つの処理ユニットに統合されてもよく、ユニットの各々は、物理的に単独で存在してもよいし、或いは、2つ以上のユニットが1つのユニットに統合される。統合されたユニットは、ハードウェアの形態で実装されてもよいし、或いは、ソフトウェア機能ユニットの形態で実装されてもよい。
[0133] 統合されたユニットがソフトウェア機能ユニットの形態で実装され、独立した製品として販売又は使3用される場合に、統合されたユニットはコンピュータ読み取り可能な記憶媒体に記憶される可能性がある。そのような理解に基づいて、本件出願の技術的解決策は本質的に、若しくは従来技術に寄与する部分、又は、技術的解決策の全部若しくは一部は、ソフトウェア製品の形態で実現される可能性がある。コンピュータ・ソフトウェア製品は、記憶媒体に記憶され、また、本件出願の実施形態において説明される方法のステップの全部又は一部を実行するように、コンピュータ・デバイス(パーソナル・コンピュータ、サーバー、又はネットワーク・デバイスである可能性がある)に命令するための幾つかの命令を含む。前述の記憶媒体は、USBフラッシュ・ドライブ、リムーバブル・ハード・ディスク、リード・オンリー・メモリ、ランダム・アクセス・メモリ、磁気ディスク、又は光ディスクのような、プログラム・コードを記憶することが可能な任意の媒体を含む。