安全なシステムのためのソフトウェア構築法（PDF）

(1)

安全なシステムのためのソフトウェア構築法

How to develop software for safety systems－audit/control and software engineering 福良博史 FUKURA Hirofumi ��はじめに初めての実用化コンピュータ _{ENIAC が登場} したのが _{1946 年で、既に半世紀以上が経過し} ている。この間、ハードウェアとしてのコンピュータそのものおよび、その知能ともいうべきソフトウェアの進歩は目覚しいものがある。今日、IT（情報技術）の発展はとどまるところをしらない。このように発展し続けている IT をささえているハードウェアとソフトウェアの身近な例として、情報端末のスマートフォンの場合を見てみよう。このハードウェアは、コンピュータ、通信機器、カメラおよび画面などで構成されている。画面に表示される各種サービスは、ソフトウェアから構成されている。現在、ソフトウェアの入っていない機器を探すほうが困難になっていると言っても過言ではない。テレビ、ビデオ、電子レンジ、洗濯機、車、銀行の ATM など、ありとあらゆる場面にソフトウェアが大きな役割を担っている。このようにソフトウェアは、色々な機器に内蔵されており、人々の生活に深く根を下ろしている。以下、ソフトウェアに関連する障害の例を挙げ、安全を考慮した場合のソフトウェアが、ハードウェアとどのような性質の違いがあるのかなどを説明し、ソフトウェアの安全を考える上での問題点を示す。そして、安全なソフトウェアを構築するためのベストでは無いが、次善の策としてのソフトウェア構築法の提案をする。 ��ソフトウェアが関係している障害の例ソフトウェアが関係した障害として公表されているもののうち状況が異なるものを3 件紹介する。 (1) Therac-25 放射線治療器の障害この放射線治療器に関しては、1985 年から 1987 年の間に 6 人が大量の放射線を浴びるという事故 2)_{が発生した。オペレータが、治療を} 受ける者と別室に隔離されていることが障害の認識の妨げになった。Therac-25 以前のモデルでは、過電流が流れると、ヒューズが切れて物理的に停止するような防御機能があった。しかし、このモデルではソフトで対応するように変更された。旧モデルで使われていたソフトはそのまま流用された。しかし、ソフトウェアのインターフェースは同じでも、物理的なメカニズムとしてTherac-25 は過電流対策のヒューズが無いという設計になっていた。このため、以前のモデルからの過電流が流れる障害は見過ごされたまま、新しいモデルがTherac-25 として造られた。本当の原因が判るまでに数年かかり、その間死亡事故が何件か続いた。これは製造の効率化による判断、人間工学上の問題なども加わった、複雑なソフトウェア・バグのケースとして知られている。 (2) パソコンの CPU のアルゴリズムの障害インテルの Pentium プロセッサの浮動小数点演算の割り算のアルゴリズムにおける障害 3) が、1994 年に発生した。この障害は、最初は確率的な誤差との意見もあり、すぐには解明できなかった。しかし、ある条件のときに必ず障害が発生することが判明し最終的にインテルがバグを認めた。調査の結果、計算速度を上げるために用意したテーブルの更新にバグがあったことが判明した。インテルは、当時おおよそ_{5 億} ドルの損失を被ったと言われている。 (3) JR 東日本の COSMOS の障害 2011 年 1 月 17 日に 5 つの新幹線が一時全線で運転停止した。17 日午前 7:00 に新白河駅、 7:43 に福島駅において、（筆者注：雪のため）ポイントが切り替わらなくなった。このため、

(2)

8 時ころから、駅間に列車を止めないようにするため、短時間に 24 本の列車に対して各駅に停止させる変更入力を行った。この変更入力を行ったシステムを _{COSMOS（COmputerized} Safety Maintenance and Operation systems of Shinkansen、1995 年 11 月より運用開始）という。COSMOS は、変更入力を行うと、その変更に伴った予想ダイヤにデータ修正が必要な箇所を表示する仕組みとなっている。司令員は、データ修正が必要な箇所を順次変更入力し、運転のための整理を行った。このとき、一時的にデータ修正が必要な箇所が600 件を超えると、予想ダイヤの表示ができなくなる。この表示が消えたことにより、コンピュータの不具合かもしれないと判断し、中央装置と駅とのデータ整合性を確認するために、全列車を停止させた。その後、異常のないことを確認した上で、全線で運転再開した。今後の対策を、JR 東日本の発表内容そのまま以下に書き記す。 (1) データ修正が必要な箇所が多く生じる入力を連続して行う場合、修正箇所を解消してから新たな入力を行う。 (2) データ修正が必要な箇所が 600 件を超えても、予想ダイヤを表示できるようにプログラムを改修することを検討する。以上2 点が対策として公表されている。以上、各々の障害は、治療機械、CPU 内部、そしてネットワーク監視システムと性格は一見異なるが、それぞれ企業が提供するサービスとそのリスクについて考えさせられることが多々ある。 ��ハードウェアとソフトウェアの大きな相違ソフトウェアは工作機械、ロボット、家電製品、前述のTherac-25 のような医療機器などの中に組み込まれている場合もあれば、COSMOS や、銀行の ATM のようにメインフレーム系のシステムもある。また、Pentium の演算障害のように、CPU 内部に潜んでいる場合もある。品質について考えるとき、ハードウェアとソフトウェアとでは大きな相違がある。ハードウェアは、一度設計して、製品化すると、その製品に含まれている部品は、経年変化する。図1 のような歯車4)_{を考えてみる。この歯車} は、ある製品にとっては、仕様どおりとする。しかし、これが何年も、現場で稼動していると、磨耗や欠損が生じる恐れがある。通常の信頼性という考え方は、このような疲労などが原因として発生する障害を扱っている。つまり障害発生の確率を問題にしている。図_{1 機械部品の例} しかし、ソフトウェアの場合は、機械部品と状況が異なる。ソフトウェアは、一度作られると、経年変化ということは有り得ない。ソフトウェアの場合、ビジネス慣行や法律などに変化が無い限り半永久的に利用することができる。同種のハードウェアに対しては、何度でも複写ができる。以上のことを機械部品のイメージで表現すると、「ソフトウェアはいつでも新品のまま」ということになる。○○○を買ったけどこれはハズレだ、アタリだ、などと言うのは、機械については日常良くある。しかし、ソフトウェアの場合は、何時、何処で購入しても、同じバージョンの製品は、まったく同じ動きをするので、このような会話は通常成り立たない。また、ソフトウェアの場合は、安全を脅かす状況は、潜在的なバグや JR 東日本のようにダイヤの増加などによるビジネスの変化により生じてくることが考えられる。特に、バグについては、機械部品と比べ、別の大きな問題がある。ソフトウェア部品の場合、ある部品が初めから欠陥部品かもしれない。上記の歯車で言えば、歯が初めから欠けているものを使っている可能性がある。こんな馬鹿なことは、有り得ないと考えるかもしれない。しかし 2000 年問題のと

(3)

きのことを思い出してみよう。うるう年 5)_の判定は、現在以下のように定義されている。「4 で割切れ、かつ 100 で割切れない西暦年かまたは、 400 で割切れる西暦年」が、うるう年西暦の下_{2 桁で西暦の値を持っていたという} 記憶域のコスト削減策ばかりではなく、うるう年の判定アルゴリズムが、「4 で割り切れる」が、うるう年としていたソフトウェアが市場に出荷され、使われていたことを思い出して欲しい。 ��リスクの�在企業は、色々なリスクにさらされている。取引上の問題としては、手形の不渡り、債務者の倒産など、それに加え製造業の場合は、製品による人身事故など、サービス業の場合は適正なサービスを受けられなかったことによる利用者からの訴訟など、日常のニュースにリスクの種は事欠かない。先ほどの JR 東日本の障害について考えてみる。この障害は、乗客の迷惑はもちろん、通常の駅務に対しても、マスコミ対応、原因究明、早急な再開に向けた各立場の人々が奔走しなければならなかった。このようなことになり、このときのリスクとしては、(1)目に見える費用だけではなく、(2)目に見えない損失（例：海外への安全な新幹線の売り込み営業に対する機会損失など）なども考えられる。企業にとってはこのようなリスクを避けることが望まれている。ここではこのような、企業活動の中での、特にソフトウェアの安全を考えたときのリスクの低減策を考察する。 ��信頼性と安全についてものづくりの中で、品質に関連してよく使われる言葉に信頼性という言葉がある。例えば、故障しないクレーンは、信頼性が100 パーセントということになる。しかし、操作を誤って人に障害を与えるかもしれない。この意味では、いくらクレーンの信頼性があるといっても安全ではない。もっと極端な例として、後続の車がない道路上で、突然エンストした乗用車は、信頼性の面では問題があっても取りあえず安全だったと言える。しかし、これが飛行機の場合は、突然エンジンが停止したのでは安全とは言えない。このように、安全と信頼性とは異なる性質を持っている。念のためソフトウェアに関係する信頼性・安全について_{JIS 規格のデイペンダ} ビリティ（信頼性）用語からいくつかの用語の定義6)_{を引用する。} ・信頼性（信頼性性能）：アイテムが与えられた条件の下で、与えられた期間、要求機能を遂行できる能力。（筆者注：備考に、適切な尺度で数量化され、これを信頼度という、との記述がある）・安全：人への危害又は資（機）材の損傷の危険性が、許容可能な水準に抑えられている状態。（筆者注：安全は、安全度というような安全を数量化した用語の定義は此処にない）・アイテム：ディペンダビリティの対象となる、部品、構成品、デバイス、装置、機能ユニット、機器、サブシステム、システムなどの総称又はいずれか。・ディペンダビリティ：信頼性性能、保全性性能及び保全支援能力を記述するために用いられる包括的な用語。以上の用語から、信頼性とは、ある機能が使えるか否かの尺度となっていることが理解できると思う。しかし安全は、人などへの危険性が抑制されているか否かの状態を示している。つまり、信頼性が低くても、人に危険をおよぼすことが無ければ、安全なシステムということになる。 ��安全の保証とはソフトウェアに関する安全の保証とはどのようなものか。信頼性と安全は、性質が異なることは、5.で説明した。しかし、基本的に、信頼性の保証がなされていなければ一般的に安心はできない。そこで、ここでは以下に、高い信頼性を維持するための手段の主なものを見ていく。

(4)

�� システム監査などによる管理システム監査などの観点から、企業の戦略上の要件と製作品または購入された品物との間に矛盾が無く、趣旨が一致するか否かという点から安全性について検証することができる。例えば米国のシステム監査用ガイドラインに該当する COBIT7)_{には、「調達と導入」の章には、コ} ンピュータ化対応策の明確化として、リスクの特定などが提示されている。そして「サービス提供とサポート」の章に安全に関連するいくつかの監査項目が掲げられている。以下にそれらをCOBIT の章別に主なものを列挙する。・物理的環境の管理直接、安全衛生に言及している箇所が数箇所ある。・性�とキ��シティの管理及��続的なサービスの保証システムの保守は、安全に対して、配慮する期間が一番長い。なぜなら、開発または購入されたソフトを長年にわたり利用することが考えられるからだ。特に、ビジネス環境・法律などが変更にならなければ半永久的に使い続けることになる。このとき、法的な変更はハッキリ目に見えるが、ビジネス環境の変化はなかなか見えにくい。前述のJR 東日本の障害は、COSMOS 開発から 10 年以上経過している。この間の新幹線の運行数の増大などをどのように評価するのかが問われることになる。忙しい日常業務の中でこのような観点での注意を払うことはかなり難しいと思う。このための予防策としては、ある許容限界を超えたところで、予防メッセージが出るような仕組みを考えることが望まれる。・システムセキュリティの保障ソフトウェアの場合、セキュリティも安全対策の一環として重要となる。ソフトウェアの場合は、ハッキングされることにより、どのようなリスクが生じるか検討しておかなければならない。個人情報が犯される、国家・企業等の機密情報が外部に流出する、安全な制御を破壊される等、あらゆることが考えられる。・サービス�スクとインシ�ント管理事故のみではなく、色々な問合せに対しても常に記録を残し、ステークホルダからの質問の傾向を時系列・頻度などを基に、常に分析し、問題が発生しそうな兆候が見られたら、未然に防ぐ手立てを講じられるような仕組みを用意しておくことが望まれる。以上のような項目に基づき、リスク管理を行うようにすることが IT を利用したシステムのリスクを低減させ、信頼性を高め、安全な運用を保障するための方策の一つと考える。この考え方は、 CSR(Corporate Social Responsibility )とも密接に関係してくる。 �� ソフトの安全を数値化できるか機器の安全を考える場合、以下の式_(1)のようにリスクを数値化 8)_{してとらえることが考えら} れている。リスク＝ _i i i

C

P

∑

・・・(1)

P

_i：失敗・故障の頻度

C

_i：失敗・故障の影響（事故あたりのコスト）例えば、式(1)を用いると、個々のリスクが・事故A：頻度年 0.1 回、100 万円/事故・事故B：頻度年 2 回、30 万円/事故とすると、年間のリスクはリスク＝0.1×100＋2×30＝10＋60 ＝70 万円/年となる。しかし、ソフトウェアの故障の頻度をどのように数値化できるか。これは非常に難しい問題を含んでいる。ソフトウェアが一切関与していない機械製品の場合は、同じ製品を同じように動かしても同じ障害が出るとは限らない。このような事象から数理統計のランダム性の考え方を基にして信

(5)

頼性の理論が組み立てられている。ところが、ソフトウェアは、このような確率的なことが適用されない。同じ操作をすれば、確実に、同じ現象が生じるのがソフトウェアであり、この意味において、ソフトウェアは非常にハードな仕組みを内蔵している。何度でもコピーをして、同じ製品が販売できる。機械製品のようにアタリ・ハズレなどが生じない。ソフトウェアのバグの発生率を評価するための考え方を見てみよう。一般にソフトウェアの品質測定には、以下のような指標が採用される。バグ発生率＝

総コード行数

バグ発生件数

・・・(2) テスト網羅率＝

総テスト項目数

テスト完了項目数

・・・(3) このとき、先ほどのうるう年のアルゴリズムを用いて簡単な思考実験をしてみよう。テスト項目は、以下の5 項目と考える。１．2000 年・・・うるう年（400 で割切れる）２．2011 年・・・平年(4 で割切れない) ３．2012 年・・・うるう年（100 で割切れない）４．2013 年・・・平年(4 で割切れない) ５．2100 年・・・平年（100 で割り切れる）うるう年の判定のコードは、C 言語での記述は、以下のようになる。

year%4==0 && year%100!= 0 || year%400==0

もしこれを間違えて year%4==0 とコードを書いて、2100 年のテストをし、バグが発見されたとする。このとき、の記録はバグ発生率＝1/1＝1（件/行）テスト網羅率＝0/5＝0（0%）注：現実にはこの1 行ではコンパイルも出来ないが、とりあえずの思考実験で、総コード数＝１と考えるそこで、以下のようにコードを訂正し、

year%4==0 && year%100!= 0

2100 年のテストが OK となる。このとき、網羅率は、テスト網羅率＝1/5＝0.2（20%）今度は 2000 年のテストをして、バグが発見されたとする。このとき記録は、先ほどのバグと合わせて、2 件目のバグとなり、バグ発生率＝2/1＝2（件/行）テスト網羅率＝_{1/5＝0.2 のまま} そこで、以下のようにコードを訂正し、

year%4==0 && year%100!= 0 || year%400==0

2000 年のテストが OK となる。このとき、網羅率は、テスト網羅率＝2/5＝0.4（40%）残りの３ケースのテストを実施し、テストが無事完了したとする。最終的にバグ発生件数は 2 件で、5 項目のテストが完了したので、最終記録はバグ発生率＝2/1＝2（件/行）テスト網羅率＝5/5＝1.0 (100%完了) となる。しかし、このテスト対象のアプリケーションが、操作当日から_{±２年以内の年月日を} 入力するもので、それ以上離れた過去や未来の年月日の入力は、意味が無いとしたなら、過去の2000 年やこれから 80 年以上先の 2100 年などのテストをすること自身が無意味ともいえる。と考えてて評価すれば、バグ発生率＝0/1＝0（件/行）と考えても良いのではないか。その場合、テスト項目は、前述の5 項目のうち、2～4 の 3 項目のみでよくなり、テスト工数も削減できる。このように、平年かうるう年かの判定一つとっても、設計・製造の過程での問題発見が出来、瑕疵を訂正できれば、100%正しい製品として出荷される。もし瑕疵を発見できなければ、バグを潜ませたまま、不良製品の出荷をすることになる。このことを確率論として扱うことは無理があると考える。式(1)の Pi を求めることは難しい。つまり、ソフトウェアはたまたま「ある操作」を行うと障害が発生し、人体に危険が及ぶという状況で納入された場合を考えると、その「ある操作」をしなければ、その装置が潜在的に障害を持っていても、100%安全なシステムとして使われたと言える。逆に、その「ある操作」を実行すると、世界中どこに納入されたシステムであっても、必ず同じ障害が発生する。このよ

(6)

うな場合に信頼性の確率による評価というものは、あまり意味をなさないと考える。 �� ソフトウェア工学による対応それでは、もっと良い方法があるのか。現在のソフトウェア工学の流れの中で、安全性とは直接関係無いが、信頼性の観点からバグの無いシステムの保障を得るために、数理論理学を応用した形式手法9) 10)_{による設計を行い、障害の} 事前除去を行うことが考えられている。しかし、未だ誰でも、どこでも簡単に使えるレベルではない。人命にかかわるようなシステムに対しては、形式手法の訓練を受けた専門家を投入し、形式手法を用いて高信頼性のソフトウェアを構築することが望ましいと考えている。過去に発生した障害の例として、Therac-25 やインテルにおける Pentium プロセッサの浮動小数点演算における障害がある。前者の事例の場合、ソフトウェア設計上の問題とマン・マシンインターフェースや開発プロセスおよび、開発者は、CMMI の成熟度11)_{が未熟（レベル}₁ かまたはそれに近いか）であった等、色々なソフトウェア工学上の問題を含んでいた。後者の事例は、障害発生後インテルにおいて、形式手法による設計方法12)_{が採用された。これは形式} 手法の事例として非常に良く適合したものと考える。この形式手法による、高信頼性の保障が得られると、人間の目視による確認ではなく、機械的なルールに従った信頼性の保障が得られる。このことにより、システムの安全への貢献も大きくなると考える。 ��安全なソフトウェアへの�� いつでも、どこでも 100%安全なシステムを構築することはとても現実的とは言えない。しかし、いい加減な設計・製造をした場合に事故が発生したときは、その説明責任を問われることになる。そこで、ソフトウェアのバグを減らすことにより、信頼性を高め、それに伴い安全なシステムに近いものを構築するためには、形式手法のような高度な設計法以外に、次善の策として、製造工程での対応方法が考えられる。システム監査の観点からは、各種チェック項目を用意しておき、その項目を全て確認したか否か、その結果問題点が有ったのか否か、などから製品を保証する方法を6.1 で述べた。これは製造工程での管理としても利用可能である。このチェック方式は、人手に頼っている。しかし、このような管理ではなく、より積極的に製造工程で高信頼性を求める方法は、目的別の言語を用意することが良いと考えている。それぞれの分野に適合した超高級言語を用いることにより、人間のケアレスミスおよび、システム上の決められた手順を遵守したコードを自動的に生成できるならば、現実的な次善の策となり得る。イメージとして理解しやすい言語として、レゴのマインドストーム用のプログラミング環境がある。この環境はドラッグ・アンド・ドロップ形式でのプログラミングが可能になっている。プログラミングにあまりトリッキーで細かい機能を付加することよりも、基本的に必要な機能が使えるようになっていることが言語設計上の王道と考える。言語を設計するということは、コンパイラなりインタープリタなりを作ることになるが、現在は色々な道具がそろっており、言語を造ることにそれほどの困難は無い。現在、C 言語を用いてコンパイラを開発する場合は lex（又は flex）および yacc（又は bison）13)_{を用いるこ}

とができる。Java 言語でコンパイラを開発する場合は、JavaCC14)_または _SableCC15)_を用いて簡単に構築できる。筆者の経験では、JavaCC を用いて簡単な BASIC 形式のインタープリタの場合、1 日あれば構築できた。このような言語をつくる（コンパイラをつくる）ための情報は、インターネット上で検索すると、色々なサンプルや解説が見つけられる。今、最も大切なことは、その分野にうまく適合した簡易かつ実用上の要件を十分満たした言語の設計をすることに尽きる。ウェブ・アプリケーションの場合を考えると、php よりもより簡単に、かつセッション管理などによるセキュリティも内蔵した言語があれば、通常のソフトウェア開発者ならば、誰もが助かると思う。なお、新たな言語は、手続き型の言語ではな

(7)

く関数型の言語が望ましい16)_{と考えている。} ��まとめ安全かつ高信頼性のソフトウェアを構築するためには色々な考え方がある。形式手法のように _{100%の信頼性を望まずに、高い安全性を維} 持していくことは、都合の良い高級言語を考え出せれば割合簡単に実現できると考えている。今後も、このようなソフトウェアの構築方法の実現に向けて考えていきたい。参考�� 1) 東日本旅客鉄道株式会社，新幹線新幹線輸送障害,2011 年 1 月 18 日，プレスリリース http://www.jreast.co.jp/press/2010/ 20110106.pdf 2)_{Nancy Leveson，}

Medical Devices: The Therac-25， http://sunnyday.mit.edu/papers/ therac.pdf

3)_{Pentium FDIV bug，}

http://en.wikipedia.org/wiki/ Pentium_FDIV_bug 4)_{素材辞典 vol.27，メカ・歯車編，} 株式会社データクラフト 5)_{カーニハン、リッチー著（石田晴久訳），プ} ログラミング言語C 第 2 版 ANSI 規格準拠この中にC 言語でのうるう年判定のアルゴリズムが1 行で書かれている(下記参照)

year%4==0 && year%100!= 0 || year%400==0

6)_{JIS Z8115，} デイペンダビリティ（信頼性）用語 7)_{福良博史他共同訳，COBIT4.0（米国システ} ム監査のガイドライン）， ISACA, 2007 年 3 月公開、現在 COBIT4.1 の翻訳が下記にて公開 http://www.isaca.org/Knowledge-Center/ cobit/Pages/Downloads.aspx 8)_{J.X.Wang、M.L.Roush 著，日本技術士会訳，} リスク分析工学 FTA,FMEA,PERT, 田口メソッドの活用法，丸善株式会社，H15 9)_{福良博史，ソフトウェア技術者の道具とし} ての「formal methods」，茨城職業能力開発短期大学校紀要，第11 号 pp.17-22,1998 年 12 月 10)_{IPA，「形式手法適用調査」報告書，} http://sec.ipa.go.jp/reports/20100729.html 11)_CMMI， http://www.sei.cmu.edu/cmmi/ 12)_{John Harrison，}

Formal verification of floating point trigonometric functions， http://www.cl.cam.ac.uk/~jrh13/slides/ fmcad-02nov00/slides.pdf 13)_{flex/bison を用いて以下のような応用例が} ある数値計算用インタプリタを作ろう， http://www.oishi.info.waseda.ac.jp/~oishi /interpreter/interpreter.htm 14)_{JavaCC でスクリプト言語を作成する，} http://codezine.jp/article/detail/367 15)_{コンパイラコンパイラ SableCC チュートリ} アル， http://ameblo.jp/spicysoft/ entry-10604354166.html 16)_{福良博史，ソフトウェアにおけるものつく} りの変革―Haskell と FPGA から見えてくる組込み系のものつくりの革新―，職業能力開発総合大学校東京校紀要，第22 号 pp.83-90,2007 年 2 月