まず、ECUのPCB上の部品を全てリストアップします。FMEAの考え方により、抜け漏れを防止するため、全ての部品を検討する必要があります。

• ISO 26262の入り口は、他の規格、例えばIEC TR 62380やSN29500等の故障率データベース、ないしは信頼性試験から算出された、部品の要素故障率です。この故障率を$\lambda$とし、左上の入り口から入ります。ただし、Part 5のフローチャートは定量計算ができないので、以下は定性的に考えます。

• 最初の菱形の判断は、この部品が安全関連であるかどうかです。Noの場合は「非安全関連」に分類され、分析から除かれます。最初に全ての部品を検討する理由は、抜け漏れの防止となるためですが、一方、無関係な部品はここでふるい落とされます。ちなみに、無関係な部品は実務上はあまり存在せず、例えばデバッグ回路等のように運転中に全く動作しない回路が相当します。他はたいていの場合安全関連です。Yesの場合は右に行き、「安全関連」と分類されます。言葉として紛らわしいのは、安全関連＝危険側、非安全関連＝安全側ということです。従って、安全関連と分類された部品は危険側を意味します。

• 次にこの部品に関して全ての故障モードを検討します。以下のフローは全ての故障モードに対して通ります。

• 次の菱形の判断は、安全機構(SM)を取り去った場合に安全目標侵害(VSG)を侵害するかどうかです。SMが無い場合はもちろん取り去るSMはありません。なぜ仮定の話を考えるかというと、ある部品の故障がVSGにつながるかどうかを考えるのがFMEAですが、一般的にSMが入っているので、ほとんどの部品はVSGとならないと判定されてしまうためです。それでは意味がないので、まずSMを除いて考えるわけです。

前のブログ 次のブログ

機能安全のハードウェア編の最初の山場が故障分類です。

特に、故障分類フローチャートは大変重要なトピックスです。規格では、Part 5のFigure B.2に簡略化された故障分類フローが掲載されています。さらにPart10のFigure 10では重要なKパラメータである$K_\text{FMC,RF}$と、$K_\text{FMC,MPF}$、加えてそれらの計算式が掲載されています。従って、簡略化されたPart 5 Figure B.2を解説し、概要を述べた後にPart 10のFigure 10を解説します。さらに、本ブログでは、分かりにくいと思われている理由を挙げ、理解するノウハウを解説します。

以下はPart 5の簡略化された故障分類フローチャートです。

前のブログ 次のブログ

6809 IPは、Verilogステートマシン設計されているため、Vivadoのロジックシミュレータでステート毎に値をチェックして行きました。飛び先である\$FF12を用意されているものの、PCに書き込まれていないことが判りました。とは言え、JMP命令は正しくデコードされ、内部信号のop_JMP(JMP命令であることを示すデコード信号)は正しく出力されています。

ステート遷移を修正し、レジスタ書き込みで終わっている箇所をジャンプステートに修正し、さらに、PCへの書き込みアサートを追加しました。

ステートの遷移は、修正前が、0f,16, 17, 18, 19, 11, 12, (09=次の命令フェッチ)のようになっているのに対して、修正後は0f, 16, 17, 18, 19, 1b, (09=次の命令フェッチ)のように遷移し、かつ、オレンジ色で示したk_write_pc信号がアサートされ、new_pcである\$FF12\$FF12がPCにセットされています。結果として正しく\$FF12にジャンプしています。

修正前は誤ってステートが、\$11(SEQ_GRAL_ALU), \$12(SEQ_GRAL_WBACK)と、レジスタ書き込みのステート遷移となっているのに対して、修正後は\$1b(SEQ_JMP_LOAD_PC)と、JMP命令のステートに遷移しています。

例えばメインフレームのような大型機をどのようにテストしているかと言えば、もちろん単体命令をひとつづつテストすることも行いますが、キャッシュ、仮想記憶、ページングの記憶階層があります。そのためのタイミングによるバグの可能性があるので、ランダム試験を実施します。命令を乱数で発生し、ただし不正命令とはならないように制約をかけ、ソフトシミュレータで正解値を取得します。これを論理シミュレータにかけ、結果値であるレジスタの値やメモリの値が正しいかをチェックします。メモリの値はひとつずつチェックすることなく、領域のチェックサムを取ることで確認します。

さらにこれを発展させ、実機にランダムプログラム生成プログラムを載せて、実行時に正解値を生成しチェックします。一見バグ値どうしを比較してOKとなりそうですが、いろいろと条件を変え、命令をページクロスさせて前半と後半でキャッシュやページのヒットミスを変えることで、演算値が変わることがあり得ます。これはプロセッサがパイプライン動作していることから、バグによってはタイミングによって結果が変わることがありうるためです。

ということで、メインフレーム並みの信頼性を保証するなら、上記のようなテストを実施しなければなりません。

前のブログ 次のブログ