特表 2022-531597 モータ制御ユニットを監視するための方法

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-07-07

(54)【発明の名称】モータ制御ユニットを監視するための方法

(51)【国際特許分類】

   G06F 11/22 20060101AFI20220630BHJP

   G05B 23/02 20060101ALI20220630BHJP

   G06F 11/16 20060101ALI20220630BHJP

【ＦＩ】

G06F11/22 675C

G05B23/02 Z

G06F11/16 629

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2021564979

(86)(22)【出願日】2020-04-30

(85)【翻訳文提出日】2021-12-17

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

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

(87)【国際公開日】2020-11-12

(31)【優先権主張番号】1904675

(32)【優先日】2019-05-03

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】516227272

【氏名又は名称】サフラン・エアクラフト・エンジンズ

(74)【代理人】

【識別番号】110001173

【氏名又は名称】特許業務法人川口國際特許事務所

(72)【発明者】

【氏名】マルタン，クリストフ・ピエール・ジョルジュ

【テーマコード（参考）】

3C223

5B034

5B048

【Ｆターム（参考）】

3C223AA15

3C223BA01

3C223CC01

3C223DD01

3C223EB01

3C223EB02

3C223GG01

3C223HH01

5B034AA02

5B034CC01

5B048CC11

(57)【要約】

本発明は、少なくとも２つの別個のチャネル（４、６）を用いてモータ制御ユニット（２）を監視する方法（１、２８）であって、前記２つのチャネル（４、６）の各々は、少なくとも：
－ レイテンシ期間が経過する間の複数の連続的に実行される算出から部分的になる所与のアプリケーションタスクＡＳを実行するための手段；
－ 算出を行うことができる第１の構成要素（１４）；
－ データを記憶することができる第２の構成要素（１６）；を備え、チャネル（４）のアプリケーションタスクＡＳは、通信することができ、方法は、以下のステップ：
ａ）レイテンシ期間を検出するステップ；
ｂ）このレイテンシ期間中に、構成要素（１４、１６）のうちの少なくとも１つの動作状態テスト（２６）を行うステップ；
ｃ）故障状態または健全状態に対応する前記構成要素（１４、１６）の状態を決定するステップを含む、方法（１、２８）に関する。

【特許請求の範囲】

【請求項1】

各々が計算機を備える、少なくとも２つの別個のチャネル（４、６）を用いてエンジン制御ユニット（２）を監視する方法（１、２８）であって、前記２つのチャネル（４、６）の各々は、少なくとも、
－ レイテンシ期間が経過する間の複数の連続的に実行される計算から部分的になる所与のアプリケーションタスク（ＡＳ）を実行するための手段、
－ 入力データから前記アプリケーションタスク（ＡＳ）の計算を遂行することができる第１の構成要素（１４）、
－ データを記憶するように適合されている第２の構成要素（１６）を備え、第１のチャネル（４）によって実行されるアプリケーションタスク（ＡＳ）および第２のチャネル（６）によって実行されるアプリケーションタスク（ＡＳ）は、互いに通信するように適合され、方法は、チャネル（４、６）ごとにアプリケーションタスク（ＡＳ）の現在の実行サイクル（ｊ）中に、以下のステップ、
ａ）レイテンシ期間を検出するステップ、
ｂ）このレイテンシ期間中に、第１の構成要素（１４）および第２の構成要素（１６）のうちの少なくとも１つの動作状態テスト（２６）を行うステップ、
ｃ）故障状態または健全状態に対応する前記構成要素（１４、１６）の状態を決定するステップ
を含む、方法。

【請求項2】

ステップａ）からｃ）が、以下のステップ、
－ ２つのチャネル（４、６）の構成要素（１４、１６）うちの少なくとも１つの故障から生じる症状を検出するステップ
が完了すると行われる、請求項１に記載の方法（１、２８）。

【請求項3】

症状が、２つのチャネル間のシグネチャの差異、および／または２つの計算機（４、６）間の通信の喪失である、請求項２に記載の方法。

【請求項4】

検出された症状が、２つのチャネル（４、６）間のシグネチャの差異である場合、検出が、現在の実行サイクル（ｊ）に先立つ先行する実行サイクル（ｊ－１）において行われる、請求項３に記載の方法。

【請求項5】

シグネチャの差異が、現在の実行サイクル（ｊ）中に行われるアプリケーションタスク（ＡＳ）の計算の合計を、現在の実行サイクル（ｊ）の終わりにおよび２つのチャネル（４、６）で並列に比較することに存する、請求項３または４に記載の方法。

【請求項6】

検出された症状が、２つの計算機（４、６）間の通信の喪失である場合、検出が、現在の実行サイクル（ｊ）中に行われる、請求項３に記載の方法。

【請求項7】

ステップｂ）のテストの実行のための命令が、アプリケーションタスク（ＡＳ）によって送られる、請求項１から６のいずれか一項に記載の方法。

【請求項8】

第１の構成要素（１４）が、再プログラム可能な集積回路またはＦＰＧＡからなる、請求項１から７のいずれか一項に記載の方法。

【請求項9】

構成要素（１６）が、ダイナミックＲＡＭからなる、請求項１から８のいずれか一項に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、航空機のターボジェットまたはターボプロップエンジンなどのターボ機械に関し、より詳細には、そのようなターボ機械の制御ユニットに関する。

【背景技術】

【0002】

航空機のターボ機械の動作は、航空機の飛行の様々な段階中にターボ機械を操縦および調整することができる制御ユニットによって制御される。

【0003】

これらの制御ユニットは、例えば、ターボ機械の様々な部分のためのコマンドを確立するために、互いに通信するとともにセンサからの同じ入力データに基づいて並列で計算を遂行するオンボード電子計算機を備える。

【0004】

計算機の計算サイクル中に、３つのタスクが行われる。第１のタスクは、ＯＳタスクと呼ばれ、オペレーティングシステム、すなわち、アプリケーションタスクによるリソースの使用を管理するプログラムのセットを起動することからなる。第２のタスクは、アプリケーティブシステム（ＡＳ）として知られており、ターボ機械を制御および調整するためのコマンドを決定するために必要な計算を遂行することからなる。ＡＳタスクの実行時間は、計算サイクルに必要な時間の８０％から９０％を示す。第３のタスクは、計算サイクルを終える。これは、第１のタスクと同一のＯＳタスクである。

【0005】

多くの構成要素を含むこれらの計算機は、それらの構成要素に大きな誤動作がないことを確認するためにセルフテストを行う。これらのセルフテストは、ＯＳタスク中に、すなわち、計算サイクルの始まりと終わりに行われる。図１は、先行技術において知られているようなタスクおよびセルフテストのシーケンシングを示す。計算サイクル２４の始まりに、単一のセルフテスト２６が、ＯＳタスクで開始される。

【0006】

それにもかかわらず、構成要素の誤動作は、アプリケーションタスク中に計算機の構成要素に発生し得る。したがって、そのような誤動作は、モータ制御ユニットに混乱をもたらし得る。混乱から欠陥のある構成要素、およびしたがって欠陥のある計算機を追跡することは、後処理解析によって可能である。これは、欠陥のある計算機が隔離されることを可能にする。

【発明の概要】

【発明が解決しようとする課題】

【0007】

この隔離は、ターボ機械の制御および調整に対する誤動作の影響を低減させるために、できるだけすぐに遂行される必要がある。本発明の目的は、特に、上述した先行技術の問題に対してシンプルで、有効で、経済的な解決策を提供することである。

【課題を解決するための手段】

【0008】

この目的を達成するために、各々が計算機を備える、少なくとも２つの別個のチャネルを用いてエンジン制御ユニットを監視するための方法であって、前記２つのチャネルの各々が、少なくとも：
－ レイテンシ期間が経過する間の複数の連続的に実行される算出から部分的になる所与のアプリケーションタスクを実行するための手段；
－ 入力データに基づいてアプリケーションタスクの算出を行うように適合された第１の構成要素；
－ データを記憶するように適合されている第２の構成要素；を備え、
第１のチャネルによって実行されるアプリケーションタスクおよび第２のチャネルによって実行されるアプリケーションタスクは、互いに通信するように適合され、方法は、チャネルごとにアプリケーションタスクの現在の実行サイクルｊ中に、以下のステップ：
ａ）レイテンシ期間を検出するステップ；
ｂ）このレイテンシ期間中に、第１の構成要素および第２の構成要素のうちの少なくとも１つの動作状態テストを行うステップ；
ｃ）故障状態または健全状態に対応する構成要素の状態を決定するステップ
を含む、方法が提案される。

【0009】

したがって、そのような方法は、計算機に含まれる様々な構成要素のステータスを、各計算機がアプリケーションタスク中に、特にレイテンシ期間中に、計算サイクルの終わりを待つことなく、決定できるようにセルフテストを行うことを可能にする。したがって、そのような方法のおかげで、計算サイクルの終わりを待つことなく欠陥のある計算機を検出し、サイクルの終わりにそれを適切に隔離することが可能である。

【0010】

これは、セルフテストの回数を増加させることによって、保守診断が、続く地上の保守動作を容易にすることを可能にもする。

【0011】

所与のアプリケーションタスクは、第１のチャネルによって実行されるアプリケーションタスク、および第２のチャネルによってアプリケーションタスクとすることができる。したがって、第１および第２のチャネルは、同じ所与のアプリケーションタスクを実行することができる。

【0012】

代替として、ステップａ）からｃ）は、以下のステップ：
－ ２つのチャネルの構成要素うちの少なくとも１つの故障から生じる症状を検出するステップ
が完了すると遂行することができる。

【0013】

したがって、この監視方法は、構成要素の故障から生じる症状が検出されるとすぐに、構成要素のセルフテストがトリガされることを可能にする。このようにして、セルフテストは、エンジン制御ユニットの計算機における構成要素の故障から生じる先に識別された症状が発生すると、必要に応じてトリガされる。

【0014】

したがって、本発明は、構成要素の故障をモータ制御ユニットのイベントおよび／または望ましくない挙動にリンクすることを可能にする。これは、オンボード電子機器、言い換えれば構成要素の故障に症状をリンクする対応テーブルを得ることを可能にする。

【0015】

各サイクル中、検出された症状（および結果として得られる故障）は、保守作業を容易にするために、例えば熱および／または振動の、様々な環境情報と共に不揮発性メモリに記録される。

【0016】

加えて、症状は、２つのチャネル間のシグネチャの差異、および／または２つの計算機間の通信の喪失であり得る。

【0017】

目標は、計算機に影響を与える故障の症状を識別することである。これらの症状は、同じアプリケーションタスクを実行する２つのチャネル間のシグネチャの差異、すなわち、アプリケーションタスクの終わりの、第１のチャネルおよび第２のチャネルの計算機のそれぞれによって遂行される計算の結果間の差異に関連し得、またはそれらは、チャネルのうちの少なくとも１つのアプリケーションタスクの計算の実行を妨げる未到着データに関連し得る。

【0018】

２つのチャネルは、計算機でそれぞれ構成されることができる。

【0019】

さらに、検出された症状が２つのチャネル間のシグネチャの差異である場合、検出は、現在の実行サイクルｊに先立つ実行サイクルｊ－１に行われ得る。実行サイクルｊ－１は、「先行する実行サイクル」または「先行するサイクル」と呼ばれる。

【0020】

シグネチャの差異は、現在の実行サイクルｊ中に行われるアプリケーションタスクの計算の合計を、サイクルｊの終わりにおよび２つのチャネルで並列に比較することからなり得る。

【0021】

検出された症状が計算機間の通信の喪失である場合、検出は、現在の実行サイクルｊ中に行われ得る。

【0022】

別の特徴によれば、ステップｂ）のテストの実行のための命令は、アプリケーションタスクによって送られることができる。

【0023】

したがって、アプリケーションタスクは、アプリケーションタスクの計算に影響を与えることなく構成要素の機能ステータスが規則正しく確立され得るように、適切な頻度でレイテンシ期間中に機能ステータステストを開始する。

【0024】

さらなる特徴では、第１の構成要素は、再プログラム可能な集積回路またはＦＰＧＡであり得る。

【0025】

加えて、第２の構成要素は、ダイナミックＲＡＭであってもよい。

【図面の簡単な説明】

【0026】

【図1】従来技術による算出サイクルにおけるタスクおよび状態テストのシーケンシングを示す図である。

【図2】本発明に係る方法の簡略化されたフローチャートである。

【図3】２つの別個のチャネルを用いたモータ制御ユニットの一例のハードウェアアーキテクチャを示す図である。

【図4】本発明の方法による計算サイクル中のタスクおよび状態テストのシーケンシングを示す図である。

【図5】本発明に係る方法の一実施形態のフローチャートである。

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

【0027】

監視方法１（そのフローチャートは、図２に示されている）は、少なくとも２つの別個のチャネル４、６を用いてモータ制御ユニット２を監視することを目指すものであり、そのアーキテクチャの例は、図３に示されている。

【0028】

したがって、２チャネルモータ制御ユニット２、４、６は、図３に見ることができるように、２つのチャネル４、６、すなわち、２つの計算機を備える。計算機４、６のこの冗長性は、計算機４、６の一方の起こり得る故障に対する耐性を確かなものにする。２つの計算機４、６は、同じ入力データから並列で同じ計算を行う（すなわち、同じアプリケーションタスクを行う）が、計算機４の１つのみが、コマンドを計算することによってターボ機械を制御および調整する。したがって、パッシブとも呼ばれる冗長な計算機６は、ターボ機械の構成部分にいかなるコマンドも送らない。

【0029】

図示されるエンジン制御ユニット２の計算機４、６は、同じアーキテクチャを有する。

【0030】

まず、各計算機４、６は、所与のアプリケーションタスクを行うための手段を含む。これらの手段は計算機のデジタルコア８および通信ボード１０に分散される。

【0031】

デジタルコア８は、とりわけ、マイクロプロセッサ１２を備える。計算機間の通信に関与する通信ボード１０は、第１および第２の構成要素１４、１６を備える。入力データからアプリケーションタスクの計算を行うことができる第１の構成要素１４は、この例ではＦＰＧＡであるが、再プログラム可能な集積回路とすることもできる。データを記憶することができる第２の構成要素１６は、メモリ、好ましくはダイナミックＲＡＭである。

【0032】

第１の構成要素１４、この例ではＦＰＧＡ（フィールドプログラマブルゲートアレイ）は、クロック制御される２つの計算機４、６間の交換を可能にする。第２の構成要素１６、好ましくはＤＰＲＡＭ（デュアルポートランダムアクセスメモリ）は、第１の構成要素１４から信号を受信し、センサからの入力データなどのデータおよび計算の中間結果を記憶する。

【0033】

レイテンシ期間が経過する間の複数の連続的に実行される計算から部分的になるアプリケーションタスクＡＳは、例えばセンサからくる入力データから、ターボ機械を構成する可動要素のアクチュエータに対して意図された制御電流を計算することを特に可能にさせる。そのようなアクチュエータは、例えば、シリンダまたは他のデバイスと組み合わせて電気油圧式サーボ弁を含む。このように、アプリケーションタスクＡＳは、エンジン制御ユニット２の各計算機４、６で並列に同時に実行される。第１のチャネル４で走るＡＳアプリケーションタスク、および第２のチャネル６で走るＡＳアプリケーションタスクは、第１のバス１８、第２のバス２０、および第３のバス２２を介して互いに通信することができる。第１のバス１８は、取り出されるデータメモリのアドレスを交換するために使用される。第２のバス２０は、センサの入力データなどのデータを交換するために使用される。これは、例えば、エンジン温度値の取得などの測定を含み得る。中間計算および最終計算の結果は、計算を行うデジタルコア８から通信ボード１０に向かって、例えば、計算された電流を伝達する第２のバス２０を通過する。第３のバスは、入力データから計算されたコマンドを交換するために使用される。これは、計算機４、６ごとに第１のバス１８および第２のバス２０上で読み出しおよび書き込みの許可を制御するいわゆる制御バスである。したがって、この制御パスは、読み出し、書き込み、および交換の動作についての優先順位の交換および管理のシーケンシングを可能にする。

【0034】

図４に示されるように、監視方法１は、チャネルごとに各実行サイクル２４で実行される。

【0035】

方法１の１のステップＡは、２つのチャネル４、６の構成要素１４、１６うちの少なくとも１つの故障から生じる症状を検出することである。

【0036】

２つのチャネル４、６のうちの１つでの構成要素の故障１４、１６の症状は、以下の通りである：
－ データが到着していない：（先行する計算からのまたはセンサからの）入力データアイテムを待っているＡＳアプリケーションタスクは、さらなる計算を遂行するためのデータアイテムを受信していない。
－ 誤ったデータ：（先行する計算からのまたはセンサからの）入力データアイテムを待っているＡＳアプリケーションタスクは、誤ったデータアイテムを受信して、さらなる計算を遂行し、誤った計算という結果になっている。
－ 間違ったアドレスに記憶されたデータ：データアイテムが受信されたときに、データアイテムが、第２の構成要素１６、ダイナミックＲＡＭにおけるアドレスに記憶される。

【0037】

データアイテムが記憶されているアドレスが間違っているとき、２つの結果があり得る：
－ データアイテムが到着しない：データアイテムが記憶されるはずだったアドレスにおいて、ＡＳアプリケーションタスクの計算に使用可能なデータアイテムがない。
－ 誤ったデータアイテム：データアイテムが記憶されるはずだったアドレスにおいて、そこに先に記憶されたデータアイテムが、ＡＳアプリケーションタスクによってさらなる計算に使用される。

【0038】

これらの症状は、２つの結果を有し得る。第１の結果は、観察された故障が、２つのチャネル４、６での、すなわち、所与のＡＳアプリケーションタスクについてのシグネチャの差異に対応し、計算機４、６ごとに行われた計算は、異なる結果をもたらすということである。第２の結果は、観察された故障は、計算機間の通信の中断からなるということである（交換されたデータが誤っているまたは欠如している）。

【0039】

したがって、これらの症状の検出は、計算機４、６のうちの少なくとも１つの少なくとも１つ構成要素１４、１６の故障を示す。

【0040】

次いで、方法の第２のステップＢは、アプリケーションタスクＡＳのレイテンシ期間を検出することからなる。実際は、ＡＳアプリケーションタスクが、いくつかの入力データアイテムからの複数の計算からなるとき、ＡＳアプリケーションタスクが次の計算を行うためデータを待っている計算間のレイテンシ期間がある。これらのレイテンシ期間中、チャネル４、６、すなわち、第１の構成要素４および第２の構成要素６のリソースは使用されない。したがって、これらのレイテンシ期間は、第１の計算機４および第２の計算機６の第１の構成要素１４および第２の構成要素１６のどちらが故障しており、識別された症状を引き起こしているのか決定するために、動作ステータステストを行うために利用することができる。

【0041】

次いで、方法１の第３のステップＣは、このレイテンシ期間中に、第１の構成要素１４および第２の構成要素１６のうちの少なくとも１つの動作状態テストを実行することからなる。この機能ステータステストは、２つのチャネル４、６で、すなわち、２つの計算機で並列に構成要素１４、１６ごとに遂行されることが好ましい。動作ステータステストのシーケンシングは、図４に見られることができる。したがって、いくつかの機能テストが、ＯＳタスク中のサイクルの始めにトリガされたものに加えて、アプリケーションタスクのレイテンシの間にトリガされる。

【0042】

セルフテストは、マーチテスト（Ｍａｒｃｈ ｔｅｓｔ）と呼ばれる。セルフテストは、各構成要素の読み書きする能力をテストするために使用される。これをするために、１６進法でタイプＡＡＡＡおよび次いで５５５５のメッセージが、１６進法でタイプ５５５５および次いでＡＡＡＡのアドレスへ連続的に書き込まれる。これらの２つのアドレスに内容を書き込むことにより、読み込みテストを自動でトリガする。

【0043】

これらのセルフテストは、レイテンシ時間（すなわち、自由時間）中におよびバス上の各交換とほとんど同時に遂行される。

【0044】

したがって、アプリケーションタスクＡＳは、それぞれ、動作ステータステスト２６を行うために、構成要素１４、１６ごとに命令を送る。言い換えれば、動作状態テスト２６は、それらがレイテンシ時間中に実行されるようにＡＳアプリケーションタスクによって呼び出される。したがって、行われるテストは、ＡＳアプリケーションタスクの計算時間に影響を与えない。

【0045】

方法１の第４のステップＤは、動作ステータステスト２６が行われた構成要素１４、１６のステータスを決定することである。状態は、故障した状態または健全状態のどちらかであり得る。したがって、同じサイクルまたは２つの連続したサイクル中に、症状が観察され、構成要素１４、１６の一方の欠陥のある状態が発見された場合、検出された症状と発見された構成要素の欠陥の相関がなされる。

【0046】

識別された故障した構成要素の影響を制限するために、故障した構成要素を含む計算機が隔離される。言い換えれば、ＡＳアプリケーションタスクによって開始される機能ステータステストまたはセルフテスト２６の後に、検出され立証された故障を有する計算機は、続くサイクルにおいてＡＳアプリケーションタスクをもはや実行せず、したがって、健全であると考えられる計算機ともはや通信しない。次いで、エンジン制御ユニット２は、シングルチャネルになり、アプリケーションタスクＡＳは、健全であると考えられる１つのみの計算機で実行される。

【0047】

この隔離の後、２つのチャネル４、６の１つが隔離されるときにＩＦＳＤ（飛行中のシャットダウン）を避けるために、アプリケーションタスクＡＳによるセルフテスト２６の起動が一時中断される。したがって、セルフテスト２６は、サイクルの始まりと終わりにＯＳタスクによって行われるセルフテスト２６を除いて、残りの計算機で行われない。

【0048】

図５は、本発明に係る方法２８の別の例をフローチャートで示す。このシステムの全体的なストラテジは、制御ユニット２に症状が発生するとセルフテス２６をトリガすることである。第１のステップは上で詳しく述べたように、サイクルｊにおいて次の故障症状を検出することである。症状は、以下のものを含み得る：
－ データアイテムが到着しない：ＡＳアプリケーションタスクがレイテンシ期間中にデータアイテムをアクティブに待っているとき、到着しないデータアイテムが、アプリケーションタスクがデータアイテムを待つ時間が最大待機時間を超えるとすぐに検出される。最大待機時間は、少なくとも３ｍｓである。
－ 第１のチャネル４と第２のチャネル６の間のシグネチャの差異：ＡＳアプリケーションタスクの終わりに、２つのチャネル４、６でＡＳアプリケーションタスクによって行われた計算の結果の合計が比較される。これは、２つのチャネル４、６が同じ計算を行うことを検証する。合計が２つのチャネル４、６で異なっている場合、これは、２つのチャネル４、６のうちの少なくとも１つが間違った計算入力を使用していることを意味する。アプリケーションタスクＡＳ、すなわち、サイクルの終わりに合計は行われるので、この症状の検出は、セルフテスト２６がサイクルｊで起動されるように、先行するサイクルｊ－１において行われる。言い換えれば、シグネチャの差異は、先行するサイクルｊ－１の終わりにおよび２つのチャネル４、６で並列に、先行するサイクルｊ－１中に行われたアプリケーションタスクＡＳの計算の合計を比較することからなる。先行するサイクルｊ－１におけるシグネチャの逸脱の検出の場合には、（図２のフローチャートの）プロセス１のステップＢからＤが、現在のサイクルｊにおいて行われる。

【0049】

上記の症状の１つが識別されるとき、アプリケーションタスクＡＳは、症状を引き起こしているかもしれない構成要素の故障を識別するために、レイテンシ期間中のセルフテスト２６のランの回数を増加させる。したがって、セルフテスト２６は、現在の実行サイクルｊの終わりまでに始められる。

【0050】

したがって、セルフテストの回数を増加させ、計算サイクルのレイテンシ期間にわたってそれらを分散させることによって、その結果として、セルフテストのカバレッジが増加される。

【0051】

第１の構成要素１４、ＦＰＧＡの起こり得る故障は、以下の通りである：
－ 構成要素１４の１６個の分岐（ｂｒａｎｃｈ）のうちの１つのはんだ接合の１つのマイクロクラッキング：マイクロクラッキングが対応する下位ビットの分岐はんだ接合に影響を与えるときを除いて、いくつかのマイクロクラックは、影響を与えないものであり得る；
－ データが更新されない；
－ メモリへの読み込みおよび／または書き込みのアクセス中の故障。

【0052】

第２の構成要素１６、ＤＰＲＡＭの起こり得る故障は、以下の通りである：
－ メモリ内の間違ったアドレスでのデータアイテムの記憶；
－ データアイテムの不記憶；
－ 以下の３つのタイプであり得る内部メモリ故障：短絡、結合の欠陥、および付着の欠陥。

【0053】

セルフテスト２６によって故障が識別されるとすぐに、欠陥が検出されたトラックが安全にされ、すなわち、チャネルは隔離される。また、故障、ならびに温度、振動ステータス、エンジン速度、航空機の姿勢、エンジンの健康、故障の飛行ナンバーおよび日付などの制御ユニットのステータスについてのコンテキスト上の情報が、保守作業を容易にするために不揮発性メモリに記憶される。

【0054】

構成要素の故障が識別されない場合、監視プロセス２８によってトリップが提供される。計算機を安全にすることは：
－ ＯＳタスクは、もはやＡＳアプリケーションタスクを呼ばない、
－ 制御電流はもはや計算されず、したがって、この計算機によってもはや発せられない
ことを確実にすることを意味する。

【0055】

そして、冗長性が失われる。

【図1】

【図2】

【図3】

【図4】

【図5】

【国際調査報告】