機能安全編

印刷用表示 | テキストサイズ 小 | 中 | 大 |


clubZ_info_renewal.jpg

| HOME | 機能安全 | 第5回 | P1 |

更新日 2016-01-20 | 作成日 2007-12-03


☑機能安全 ~上流で設計すべきもうひとつの品質

第5回:構想設計とSafety Measure

株式会社制御システム研究所 森本 賢一

2010.12.16
※記事執筆時は、三菱重工業株式会社 原動機事業本部に在籍

TVアニメ「機動戦士ガンダムSEED」には、冒頭、機能安全的に興味深い描写が登場します。
主人公キラ・ヤマトはコーディネイタと呼ばれる遺伝子組み換えを受けた超人です。コーディネイタは、肉体も頭脳も反射神経もものすごく優秀です。彼らはスペースコロニーで独立政府を運営しています。地球連合は普通の人ばかりですが、彼らに宣戦布告します。当然相手は超人ばかりですから、戦いはコーディネイタ側が有利です。主人公のキラ・ヤマトだけは、訳あって地球の人類側に味方することになります。

地球連合は起死回生を狙って、モビルスーツ(人間が搭乗して運転するロボット)を5台開発します。冒頭でこのモビルスーツを敵が奪うのですが、モビルスーツに搭乗した敵は冷静にモビルスーツを初期化することから始めます。OSを書き換えているようです。どうも地球連合のモビルスーツの制御コンピュータは、OSが貧弱で使いづらいようです。コーディネイタたるもの、まずは盗む前にシステムをカスタマイズするぐらいの冷静さが必要です。プライドが許さないようです。おかげでドキドキハラハラの演出となります。

直後に主人公キラ・ヤマトも、同じ機種のモビルスーツに搭乗し敵を迎撃しようとしますが、やはりかなり制御コンピュータに不満があるようです。動きも遅く、先に書き換えて起動した敵に翻弄されます。

そこでキラ・ヤマトは、なんとモビルスーツで敵と戦いながら、OSを書き換え始めます。おいおい。どんだけ超人なんだ。早く逃げろよ。
本格的な書換えは後に戦艦内で落ち着いてやっている描写がありますから、おそらく暫定的な処置をしただけのようですが、敵が驚くぐらいみるみる動きがよくなって、最後は敵を追い払います。キラ・ヤマト恐るべし。

ぼろいOSで遅くって遅くって、つかわない無駄な機能を削るとかなり軽くなる、という経験を普段している私達は、なんとなく納得してしまう描写です。しかし地球連合が起死回生を期して開発したシステムです。不要な機能や、画面の一部が立体的に見えるとか透明になるなんて、そんな無駄な機能で遅くなっていたなんてことはないでしょう。

また、ロボット工学を学んだ人ならば感じると思いますが、モビルスーツぐらい可動箇所に自由度が多いと、逆動力学計算の処理は膨大です。CPUやハードウェアを換装せずに、OSを多少触ったからといって、動きが格段によくなるなんてちょっと信じられませんよね。

しかし機能安全的には、ありえるかもしれません。
今回のメルマガでは、キラ・ヤマトが何をやったのか、機能安全的に考えてみたいと思います。

(前回の振り返り)
前回は有効な構想設計(=青写真)に関係し、System FMEAやFTAという信頼性分析をすることで、システムの脆弱な部分、危険な部分を洗い出す活動をご紹介しました。構想設計(=青写真)は、業務の役割分担やフローをあらわすものではなく、信頼性分析をするための土台であり、分析を通して設計をブラシュアップしてゆくものでしたね。

信頼性分析を行う中で、危険な部位や振舞いが見つかった場合、それに対処する打ち手を新たなRequirementとして抽出し、Requirementの台帳に登録し、ハードウェアからソフトウェアへ、またはソフトウェアからハードウェアへの要求事項として取り扱うこともお話ししました。このように、「設計」→「分析」→「Requirementの抽出」→「設計」→「分析」を繰り返すことが、構想設計を豊かにしてゆくステップでした。

この信頼性分析は、システムの中にある個々のブロック、つまりサブシステムの故障・障害を取り扱います。それらの故障について、それが危険事態に至るならば、何らかの打ち手を考えなければなりません。この分析は、最終的にはシステムの不動作確率PFDave/PFHや、SFFなどの数値指標を算出する際に、非常に重要な役割を果たします。この『打ち手』を、「Safety Measure」と呼称しましょう。

これまでのメルマガで、SILという指標は、システムの危険側不動作確率が、その設備のリスク分析の結果から許容できるレベルを満たすかどうかを、評価するものであることをお話ししてきました。第3回では、その確率をどのように導くのか、数式を交えて解説しました。その中で構成物品の故障率(λ)を、「安全側」と「危険側」に区分すること、そしてさらにそれらを、「検知できるもの」と「検知できないもの」に分類して、算出することを思い出してください。今回はこの辺りからお話を始めます。

safe_101216_1.JPG

(危険側故障率λ D
システムの信頼性を評価する指標であるPFDave/PFHやSFFを必要な値にするためには、分類した故障率のうち、危険側故障率(λ D )を小さくすること、さらにその中でも、検知できない危険側故障率(λ DU )を小さくすることが重要でした。

信頼性分析の過程で「危険な事象に至る」と指摘された故障に対する打ち手、すなわちSafety Measureとは、言い換えれば、λ DU をλ DD に移しかえる働きをするものだともいえるのです。豊かな構想設計から導かれたSafety Measureは、のちのちのλ DU との戦いにおいて、非常に有効な武器になります。

なぜならば、詳細な回路設計は構想設計の後で行うとしても、各々の回路ブロックの機能や障害がどのような振舞いに至るかは、この構想設計段階の分析でおおよそ網羅できているはずだからです。(逆に言えば、網羅できるような構想設計と信頼性分析をしなければならない、ということです。)

つまりゆくゆく下流の詳細設計で、全ての電子部品のひとつひとつの故障率(λ)を、危険側、安全側、検知できる側、検知できない側に割り当てる際に、構想設計段階でリストアップしたSafety Measureを使うことで、詳細設計後の故障解析の際、それぞれの部品の故障を「危険側ではあっても検知できる側」に割り当てられる可能性が高くなるのです。

検知できる危険側故障率(λ DD )に割り当てられれば、それだけPFDave/PFHやSFFの算出の際に、より望ましい値を導くことが出来ます。


(Safety Measureの例①)
マイコンを使用するシステムでよくあるSafety Measureは、メモリーのエラー検知です。
メモリーは、物質としての劣化故障も考えられますが、中性子などの宇宙線があたることで、偶発的なビット変化を発生させることがあります。これをソフトエラーといいます。

ええええっまさか。それは、ロケットでも作る際の話でしょう?と言われそうですが、地上でも大量の宇宙線が降り注いでいます。上野の国立科学博物館には、宇宙線を可視化させる「霧箱」が地下階に展示されています。確かに結構ピュンピュン飛んでいるのが素人目にも判ります。このようなエネルギーを持った宇宙線が不幸にも安全関連システムのメモリーに当たった場合、あるビットを0から1に変化させるかもしれません。ましてやガンダムは宇宙で使用しますから、それはもうびゅんびゅんの3乗ぐらい飛んでいるはずです。

このようなソフトエラーをチェックするためにはどうしたら良いでしょうか?

一つはデータを複数の異なるエリアに保管し、使うたびに比較することが考えられます。または、保存しているデータをコード化し、内容が変わったことを検知できるようにする方法もあるでしょう。そのほかにも様々な手法が考えられます。

いずれにせよ、近年どんどん処理が複雑になり多くのプログラムが動作する様になってきた組み込みシステムに於いて、普通にメモリーの容量から導かれる故障率を、すべてλ DU と捕らえてしまうと、目標とするPFDave/PFHには到底到達できません。

そこで、前述のような手法を打ち手(=Safety Measure)を駆使して、メモリーのソフトエラーを、「検知できる危険側故障率」として扱えるようにするわけです。

(Safety Measureの例②)
組み込みシステムであれば、マイコンに供給する電源の電圧低下は重要な監視対象です。3.3vであれば、たとえば2.8v程度に下がったら、マイコンがぎりぎりまだ動作できるとしても、割込みをかけてマイコンを退避処理させ、意図しない動作や暴走を防止する。こんな仕組みはよくある話です。

この2.8vという電圧低下を検知する素子(または回路)の検査は、通常製品出荷前にきちんと行います。しかし製品出荷後、システムが稼動している長い時間の間に素子が劣化し、ひょっとすると将来、2.8v未満に低下しても、検知する素子が動作しなくなるかもしれません。そうなると、万一の電圧低下の際に適切に退避処理ができず、結果的に意図しない動作をしたり、暴走をしたりするかもしれません。

このような場合、この電圧低検知素子および回路の故障は、「危険側」であると判断することが出来ます。さらに製品出荷のときだけしか正常な検知をチェックしないならば、それは「検知できない危険側故障率」に分類されます。

このような場合、製品が稼動している間に、「あえて無理やり2.8v以下に電圧を下げて、本当に2.8v以下で割り込みが発生するかどうか」を、定期的且つ自動的にチェックする機能があったとしたらどうでしょうか。この電圧低検知素子および回路が故障したとしても、それは検知することが可能です。すなわち、「検知できる危険側故障率」に分類できることを意味します。

このようなチェックは日常生活でも効果的です。

彼氏の携帯をのぞいて、直接的に浮気の状況を確認できる。これは検知可能な危険側故障ですね。しかし、携帯を使わない彼氏の浮気(=検知できない故障)は、なかなか判らなくて厄介です。しかし、友人の女性にわざと彼氏を誘惑させてみて、その挙動を確認すれば、それは検知できる故障として彼氏の信頼度を評価できる、という寸法です。勿論、その結果本当に彼氏がその友人のほうに行ってしまわないよう、予め手立てが必要です。これは、前述の電圧低検知素子および回路のテストでも同様です。そのテストをシステムの稼働中に行って、本当にマイコンを暴走させてしまっては本末転倒ですから。

Safety Measureは設計手法に関するものなど様々ありますが、前述のようなものを、自己診断(Diagnostic機能、またはSelf Test機能)と呼んでいます。