機能安全編

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

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

（ソフトウェアの構想設計の重要性）
System FMEAやFTAは、青写真に示した機能ブロックの故障を取り扱います。このため多くの場合、ハードウェアに関連するブロック図に終始しがちです。しかし、機能安全がシステム全体の動きの信頼性を評価するものであることを鑑みれば、ソフトウェアについても正確に構想設計することが必要です。

たとえば、あるマイコンを搭載した電子基板を考えてみましょう。CPUに与えるクロックの水晶発信器、およびそれから生成されるタイマが、システムにどのような影響を与えるでしょうか。それはそのタイマがどのように使われているのかによって変化します。CPUに２つのクロックソースがあれば、当然どちらかはソフトウェアタスクの定周期起動に関連している可能性があります。それはどちらのタイマでしょうか。

このように部品の故障影響を分析する際、それがソフトウェアのどのような機能に関連しているのかの情報が必要になります。つまり構想設計段階でソフトウェアの大まかな構造も設計しておく必要があるのです。



この様にソフトウェアも大まかな機能をブロックとして明記し、その構想設計を行うことが必要になります。上の図では水晶発信器はスケジューラのタスクの起動タイマに使われていることが判りますから、タイマは非常に重要な部位であることがわかります。

ソフトウェアの構想設計を早い段階で行うメリットはもう一つあります。それは、ソフトウェア側の課題をハードウェアに伝達し、設計を見直すことが出来る点です。

たとえば前述のような場合、ソフトウェア側では、そのタスクの定周期の確実な実行のために、Supervisorと呼称する、タスクの終了時間をチェックするコンポーネントがあるものとしましょう。このコンポーネントは、Schedulerが起動したタスクの完了時間をタイマで確認し、その動作時間が長すぎたり、短すぎたりした場合、規定の処理をしてないとみなして、システムを安全状態（安全な停止状態など）に移行させる機能を持っているとします。

プログラムの動作状態のチェック構造としてはかなり慎重なつくりですが、SchedulerもSupervisorも同じTimer1つまり一つの水晶発信器で駆動されていますから、水晶発信器そのものに異常が発生した場合、Supervisorのチェック機能の信頼性が根底から揺らいでしまいます。

このようなケースでは、たとえばクロックソースを２つにして、ソフトウェア側でも使い分けるようにすることが打ち手として考えられます。



このように、構想設計段階でソフトウェアの構造を大まかに規定することは、ソフトウェアの課題を早い段階でハードウェア側の設計に反映することを可能にします。これが構想設計段階でソフトウェアについてきちんと記述するもう一つの必要性でありメリットです。（もちろん、このような議論から発生した新しいRequirementも、Requirementの台帳にきちんと記録して管理してゆかなくてはなりません。）


（構造からはわからないCommon Cause Failure）
Common Cause Failureは、System FMEAや特にFTAの分析の中で明らかにしてゆくと一般に説明されますが、ハードウェアとソフトウェアの関係性の中に内在する要因は、なかなか明らかに出来ないものです。前述のタイマ「Timer1」は、ソフトウェアから見ていわばCommon Cause Failureと言えますよね。このようなものは、ハードウェアとソフトウェアを別々に分担して議論していては、なかなか見つかりません。

前述のようなタイマ割り込みの例えはわかりやすいですが、GPIOなど様々なI/Fをマイコンが持つ場合、その動作つまり振舞いの中に潜む問題を見つけることは、形式的な分析手法では一概に完璧とは言いがたいのが実情です。なぜならばSystem FMEAやFTAという解析手法は、ハードウェアであれソフトウェアであれ、部分（部品やコンポーネント）の故障に着眼して行うものだからです。

故障にはランダム故障（いわゆる物理的な破損や、劣化、不良などランダムに発生する故障）と、システマティック故障（構造的な故障）に分けて考えることが出来ます。ソフトウェアは、動作するハードウェアに起因するランダム故障も想定は出来ますが、基本的に後者のシステマティック故障（いわゆるバグと呼ばれるものも含めた構造的な問題）が大きなウェートを占めます。

System FMEAやFTAという解析手法は部分の故障に着眼して行うため、振舞いや仕組みそのものに潜在する構造的な間違いや危険を見つけ出すことが苦手です。単純なバグはコードレビューやテストで見つかることも期待できますが、一つ一つのコンポーネントは仕様書どおりでも、相互の振舞いに内在するようなアルゴリズムに近い間違いは、さらに見つけ出すことが困難です。

ソフトウェアはよく「小説」や「映画」に例えられます。何百ページも有る「小説」をすらすら読んで犯人を捜したり、恋愛の顛末の流れを追たったりする事は容易です。ソフトウェアでいえば、それは実現する機能です。しかしすべての描写、すべての記述のなかにたった１つも矛盾がないか、それは本文のストーリを単に追っていては、見つけることが出来ません。小説が書きあがってから、そのあとに何百ページの中から矛盾を洗い出すのは、極めて難しいですよね？

もっとも、普通の小説では程度によって、そのような矛盾も作品の質に影響はしません。しかしソフトウェアではそうはいきません。メインストーリである「機能」とは別な部分で、意外な枝葉で矛盾がある場合、それがシステムの危険性を高める可能性があるのです。

システマティック故障、とりわけソフトウェアのこのような問題を確実に解消するためには、様々な設計手法やコーディングルールを取り決めたり、テストを積み上げたりする必要があります。（この部分は、メルマガの次回以降でまたお話します。）しかし、もっとも大切なことは、ソフトウェアは作成するプロセスが大切だ、ということです。

小説や映画も出来上がってから枝葉の矛盾を調べつくすのは無理です。登場人物のキャラクターやプロットを図にしたり、相関関係を図にしたり、描写を絵コンテにするなどし、様々な角度で予め矛盾や間違いをチェックしてから実際の文章作成に入ることが必要になります。

ソフトウェアもまさにそのように、「コーディング」以前に振舞いをシーケンス図で記述したり、クラス図で相関関係を示したりなど、様々な（ただし一貫した）表現形態で表してみて、それをチェックすることが大切になります。

このような手順を経て、これから作成するソフトウェア＝（小説や映画）の意図や中身を表現し、作者以外の人に、どちらかといえば批判的に見てもらうことが、システマティック故障であるバグを排除する最も効果的な活動になります。この批判的に別な人がチェックする、という活動が大切です。いくら大量の図書を形式手法で作成しても、つくりっぱなしでは、その意味が半減します。チェックのための図書作成という意味では、描き方や表現方法にこだわることは本質ではありません。

IEC-61508では、設計開発全体のAssessmentについて次のような表で独立性の必要性を示唆しています。その一方、設計をVerification and Validationするチェックの方は、十分な独立性を求めながらも表などでの規定はしていません。しかし、複雑なシステムであればあるほど、そのシステマティック故障を排除するためには、出来る限り多くの人の目で、その構造や振舞いを「批判的に」チェックしてもらうことが大切であることは言うまでもありません。

その意味で、Assessmentに必要な独立性は、ソフトウェアのシステマティック故障を排除するための必要なチェック部隊の独立性の必要度と考えても差し支えないものと思えます。



ソフトウェアの構造的な間違い、振舞いの中の危険性をチェックするためには、構想設計段階で、その振舞い、動きを様々な方法で表現し、作者とは別なチェックする人物・組織でそれを評価(批評)できるようにする、そのような運営の積み重ねが必要です。


今回は構想設計とSystem FMEAと題し、ようやく本メルマガの主題である構想設計の具体的な重要性について話を進めました。次回は構想設計の後に行うハードウェアやソフトウェアの設計や分析に触れ、そこから改めて構想設計段階で大切になる活動についてお話します。

Archive

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