安全なシステムのためのソフトウェア構築法 How to develop software for safety systems－audit/control and software engineering 福良 博史 FUKURA Hirofumi この放射線治療器に関しては、1985 年から ��はじめに 初めての実用化コンピュータ ENIAC が登場 1987 年の間に 6 人が大量の放射線を浴びると したのが 1946 年で、既に半世紀以上が経過し いう事故 ている。この間、ハードウェアとしてのコンピ 受ける者と別室に隔離されていることが障害の ュータそのものおよび、その知能ともいうべき 認識の妨げになった。Therac-25 以前のモデル ソフトウェアの進歩は目覚しいものがある。今 では、過電流が流れると、ヒューズが切れて物 日、IT（情報技術）の発展はとどまるところを 理的に停止するような防御機能があった。しか しらない。 し、このモデルではソフトで対応するように変 2)が発生した。オペレータが、治療を このように発展し続けている IT をささえて 更された。旧モデルで使われていたソフトはそ いるハードウェアとソフトウェアの身近な例と のまま流用された。しかし、ソフトウェアのイ して、情報端末のスマートフォンの場合を見て ンターフェースは同じでも、物理的なメカニズ みよう。このハードウェアは、コンピュータ、 ムとして Therac-25 は過電流対策のヒューズが 通信機器、カメラおよび画面などで構成されて 無いという設計になっていた。このため、以前 いる。画面に表示される各種サービスは、ソフ のモデルからの過電流が流れる障害は見過ごさ トウェアから構成されている。現在、ソフトウ れたまま、新しいモデルが Therac-25 として造 ェアの入っていない機器を探すほうが困難にな られた。本当の原因が判るまでに数年かかり、 っていると言っても過言ではない。テレビ、ビ その間死亡事故が何件か続いた。これは製造の デオ、電子レンジ、洗濯機、車、銀行の ATM 効率化による判断、人間工学上の問題なども加 など、ありとあらゆる場面にソフトウェアが大 わった、複雑なソフトウェア・バグのケースと きな役割を担っている。 して知られている。 このようにソフトウェアは、色々な機器に内 蔵されており、人々の生活に深く根を下ろして (2) パソコンの CPU のアルゴリズムの障害 インテルの Pentium プロセッサの浮動小数 点演算の割り算のアルゴリズムにおける障害 いる。 3) 以下、ソフトウェアに関連する障害の例を挙 が、1994 年に発生した。この障害は、最初は確 げ、安全を考慮した場合のソフトウェアが、ハ 率的な誤差との意見もあり、すぐには解明でき ードウェアとどのような性質の違いがあるのか なかった。しかし、ある条件のときに必ず障害 などを説明し、ソフトウェアの安全を考える上 が発生することが判明し最終的にインテルがバ での問題点を示す。そして、安全なソフトウェ グを認めた。調査の結果、計算速度を上げるた アを構築するためのベストでは無いが、次善の めに用意したテーブルの更新にバグがあったこ 策としてのソフトウェア構築法の提案をする。 とが判明した。インテルは、当時おおよそ 5 億 ドルの損失を被ったと言われている。 (3) JR 東日本の COSMOS の障害 ��ソフトウェアが関係している障害の例 ソフトウェアが関係した障害として公表され 2011 年 1 月 17 日に 5 つの新幹線が一時全線 ているもののうち状況が異なるものを 3 件紹介 で運転停止した。17 日午前 7:00 に新白河駅、 する。 7:43 に福島駅において、（筆者注：雪のため） (1) Therac-25 放射線治療器の障害 ポイントが切り替わらなくなった。このため、 － 31 － 8 時ころから、駅間に列車を止めないようにす 品に含まれている部品は、経年変化する。 るため、短時間に 24 本の列車に対して各駅に 図 1 のような歯車 4)を考えてみる。この歯車 停止させる変更入力を行った。この変更入力を は、ある製品にとっては、仕様どおりとする。 行ったシステムを COSMOS（COmputerized しかし、これが何年も、現場で稼動していると、 Safety Maintenance and Operation systems 磨耗や欠損が生じる恐れがある。通常の信頼性 of Shinkansen、1995 年 11 月より運用開始） という考え方は、このような疲労などが原因と という。COSMOS は、変更入力を行うと、そ して発生する障害を扱っている。つまり障害発 の変更に伴った予想ダイヤにデータ修正が必要 生の確率を問題にしている。 な箇所を表示する仕組みとなっている。司令員 は、データ修正が必要な箇所を順次変更入力し、 運転のための整理を行った。このとき、一時的 にデータ修正が必要な箇所が 600 件を超えると、 予想ダイヤの表示ができなくなる。この表示が 消えたことにより、コンピュータの不具合かも しれないと判断し、中央装置と駅とのデータ整 合性を確認するために、全列車を停止させた。 その後、異常のないことを確認した上で、全線 図1 で運転再開した。今後の対策を、JR 東日本の 機械部品の例 発表内容そのまま以下に書き記す。 (1) (2) データ修正が必要な箇所が多く生じる しかし、ソフトウェアの場合は、機械部品と 入力を連続して行う場合、修正箇所を解 状況が異なる。ソフトウェアは、一度作られる 消してから新たな入力を行う。 と、経年変化ということは有り得ない。ソフト データ修正が必要な箇所が 600 件を超 ウェアの場合、ビジネス慣行や法律などに変化 えても、予想ダイヤを表示できるように が無い限り半永久的に利用することができる。 プログラムを改修することを検討する。 同種のハードウェアに対しては、何度でも複写 以上 2 点が対策として公表されている。 ができる。以上のことを機械部品のイメージで 表現すると、「ソフトウェアはいつでも新品の 以上、各々の障害は、治療機械、CPU 内部、 まま」ということになる。○○○を買ったけどこ そしてネットワーク監視システムと性格は一見 れはハズレだ、アタリだ、などと言うのは、機 異なるが、それぞれ企業が提供するサービスと 械については日常良くある。しかし、ソフトウ そのリスクについて考えさせられることが多々 ェアの場合は、何時、何処で購入しても、同じ ある。 バージョンの製品は、まったく同じ動きをする ので、このような会話は通常成り立たない。 ��ハードウェアとソフトウェアの大きな相違 また、ソフトウェアの場合は、安全を脅かす ソフトウェアは工作機械、ロボット、家電製 状況は、潜在的なバグや JR 東日本のようにダ 品、前述の Therac-25 のような医療機器などの イヤの増加などによるビジネスの変化により生 中に組み込まれている場合もあれば、COSMOS じてくることが考えられる。特に、バグについ や、銀行の ATM のようにメインフレーム系の ては、機械部品と比べ、別の大きな問題がある。 システムもある。また、Pentium の演算障害の ソフトウェア部品の場合、ある部品が初めから ように、CPU 内部に潜んでいる場合もある。 欠陥部品かもしれない。上記の歯車で言えば、 品質について考えるとき、ハードウェアとソ 歯が初めから欠けているものを使っている可能 フトウェアとでは大きな相違がある。ハードウ 性がある。こんな馬鹿なことは、有り得ないと ェアは、一度設計して、製品化すると、その製 考えるかもしれない。しかし 2000 年問題のと － 32 － きのことを思い出してみよう。うるう年 5)の判 定は、現在以下のように定義されている。 頼性の面では問題があっても取りあえず安全だ ったと言える。しかし、これが飛行機の場合は、 「4 で割切れ、かつ 100 で割切れない西暦年 かまたは、 突然エンジンが停止したのでは安全とは言えな い。このように、安全と信頼性とは異なる性質 400 で割切れる西暦年」が、うるう年 を持っている。念のためソフトウェアに関係す 西暦の下 2 桁で西暦の値を持っていたという る信頼性・安全について JIS 規格のデイペンダ 記憶域のコスト削減策ばかりではなく、うるう ビリティ（信頼性）用語からいくつかの用語の 年の判定アルゴリズムが、 定義 6)を引用する。 「4 で割り切れる」が、うるう年 としていたソフトウェアが市場に出荷され、使 信頼性（信頼性性能）：アイテムが与えら ・ れた条件の下で、与えられた期間、要求機 われていたことを思い出して欲しい。 能を遂行できる能力。 （筆者注：備考に、適切な尺度で数量化さ ��リスクの�在 企業は、色々なリスクにさらされている。取 引上の問題としては、手形の不渡り、債務者の れ、これを信頼度という、との記述がある） ・ 安全：人への危害又は資（機）材の損傷の危 倒産など、それに加え製造業の場合は、製品に 険性が、許容可能な水準に抑えられている状 よる人身事故など、サービス業の場合は適正な 態。 サービスを受けられなかったことによる利用者 （筆者注：安全は、安全度というような安 からの訴訟など、日常のニュースにリスクの種 全を数量化した用語の定義は此処にない） ・ は事欠かない。 アイテム：ディペンダビリティの対象とな 先ほどの JR 東日本の障害について考えてみ る、部品、構成品、デバイス、装置、機能 る。この障害は、乗客の迷惑はもちろん、通常 ユニット、機器、サブシステム、システム の駅務に対しても、マスコミ対応、原因究明、 などの総称又はいずれか。 早急な再開に向けた各立場の人々が奔走しなけ ・ ディペンダビリティ：信頼性性能、保全性 ればならなかった。このようなことになり、こ 性能及び保全支援能力を記述するために のときのリスクとしては、(1)目に見える費用だ 用いられる包括的な用語。 けではなく、(2)目に見えない損失（例：海外へ の安全な新幹線の売り込み営業に対する機会損 以上の用語から、信頼性とは、ある機能が使 えるか否かの尺度となっていることが理解でき 失など）なども考えられる。 企業にとってはこのようなリスクを避けるこ ると思う。しかし安全は、人などへの危険性が とが望まれている。ここではこのような、企業 抑制されているか否かの状態を示している。つ 活動の中での、特にソフトウェアの安全を考え まり、信頼性が低くても、人に危険をおよぼす たときのリスクの低減策を考察する。 ことが無ければ、安全なシステムということに なる。 ��信頼性と安全について ものづくりの中で、品質に関連してよく使わ ��安全の保証とは れる言葉に信頼性という言葉がある。例えば、 ソフトウェアに関する安全の保証とはどのよ 故障しないクレーンは、信頼性が 100 パーセン うなものか。信頼性と安全は、性質が異なるこ トということになる。しかし、操作を誤って人 とは、5.で説明した。しかし、基本的に、信頼 に障害を与えるかもしれない。この意味では、 性の保証がなされていなければ一般的に安心は いくらクレーンの信頼性があるといっても安全 できない。そこで、ここでは以下に、高い信頼 ではない。もっと極端な例として、後続の車が 性を維持するための手段の主なものを見ていく。 ない道路上で、突然エンストした乗用車は、信 － 33 － ��� システム監査などによる管理 ・ サービス�スクとインシ�ント管理 システム監査などの観点から、企業の戦略上 事故のみではなく、色々な問合せに対し の要件と製作品または購入された品物との間に ても常に記録を残し、ステークホルダから 矛盾が無く、趣旨が一致するか否かという点か の質問の傾向を時系列・頻度などを基に、 ら安全性について検証することができる。例え 常に分析し、問題が発生しそうな兆候が見 ば米国のシステム監査用ガイドラインに該当す られたら、未然に防ぐ手立てを講じられる COBIT7)には、「調達と導入」の章には、コ ような仕組みを用意しておくことが望ま る ンピュータ化対応策の明確化として、リスクの れる。 特定などが提示されている。そして「サービス 提供とサポート」の章に安全に関連するいくつ 以上のような項目に基づき、リスク管理を行 かの監査項目が掲げられている。以下にそれら うようにすることが IT を利用したシステムの を COBIT の章別に主なものを列挙する。 リスクを低減させ、信頼性を高め、安全な運用 ・ 物理的環境の管理 を保障するための方策の一つと考える。 直接、安全衛生に言及している箇所が数 こ の 考 え 方 は 、 CSR(Corporate Social Responsibility )とも密接に関係してくる。 箇所ある。 ・ 性�とキ��シティの管理及��続的なサ ービスの保証 ソフトの安全を数値化できるか ��� システムの保守は、安全に対して、配慮 機器の安全を考える場合、以下の式(1)のよう する期間が一番長い。なぜなら、開発また にリスクを数値化 は購入されたソフトを長年にわたり利用 れている。 8)してとらえることが考えら することが考えられるからだ。特に、ビジ ネス環境・法律などが変更にならなければ リスク＝ 半永久的に使い続けることになる。このと ∑ PC ・・・(1) i i き、法的な変更はハッキリ目に見えるが、 i Pi ：失敗・故障の頻度 ビジネス環境の変化はなかなか見えにく い。前述の JR 東日本の障害は、COSMOS Ci ：失敗・故障の影響 開発から 10 年以上経過している。この間 （事故あたりのコスト） の新幹線の運行数の増大などをどのよう に評価するのかが問われることになる。忙 しい日常業務の中でこのような観点での 例えば、式(1)を用いると、個々のリスクが 注意を払うことはかなり難しいと思う。こ ・事故 A：頻度年 0.1 回、100 万円/事故 のための予防策としては、ある許容限界を ・事故 B：頻度年 2 回、30 万円/事故 超えたところで、予防メッセージが出るよ とすると、年間のリスクは リスク＝0.1×100＋2×30＝10＋60 うな仕組みを考えることが望まれる。 ＝70 万円/年 ・ システムセキュリティの保障 ソフトウェアの場合、セキュリティも安 となる。 全対策の一環として重要となる。ソフトウ しかし、ソフトウェアの故障の頻度をどのよ ェアの場合は、ハッキングされることによ うに数値化できるか。これは非常に難しい問題 り、どのようなリスクが生じるか検討して を含んでいる。 おかなければならない。個人情報が犯され ソフトウェアが一切関与していない機械製品 る、国家・企業等の機密情報が外部に流出 の場合は、同じ製品を同じように動かしても同 する、安全な制御を破壊される等、あらゆ じ障害が出るとは限らない。このような事象か ることが考えられる。 ら数理統計のランダム性の考え方を基にして信 － 34 － 頼性の理論が組み立てられている。ところが、 今度は 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) バグ発生率 ＝ 総コード行数 録は バグ発生率＝2/1＝2（件/行） テスト完了項目数 ・・・(3) テスト網羅率＝ 総テスト項目数 テスト網羅率＝5/5＝1.0 (100%完了) となる。しかし、このテスト対象のアプリケー ションが、操作当日から±２年以内の年月日を 入力するもので、それ以上離れた過去や未来の このとき、先ほどのうるう年のアルゴリズム 年月日の入力は、意味が無いとしたなら、過去 の 2000 年やこれから 80 年以上先の 2100 年な を用いて簡単な思考実験をしてみよう。 テスト項目は、以下の 5 項目と考える。 どのテストをすること自身が無意味ともいえる。 １．2000 年・・・うるう年（400 で割切れる） と考えてて評価すれば、 ２．2011 年・・・平年(4 で割切れない) バグ発生率＝0/1＝0（件/行） ３．2012 年・・・うるう年（100 で割切れない） と考えても良いのではないか。その場合、テス ４．2013 年・・・平年(4 で割切れない) ト項目は、前述の 5 項目のうち、2～4 の 3 項目 ５．2100 年・・・平年（100 で割り切れる） のみでよくなり、テスト工数も削減できる。 うるう年の判定のコードは、C 言語での記述は、 以下のようになる。 このように、平年かうるう年かの判定一つと っても、設計・製造の過程での問題発見が出来、 year%4==0 && year%100!= 0 || year%400==0 もしこれを間違えて 瑕疵を訂正できれば、100%正しい製品として出 荷される。もし瑕疵を発見できなければ、バグ year%4==0 を潜ませたまま、不良製品の出荷をすることに とコードを書いて、2100 年のテストをし、バグ なる。このことを確率論として扱うことは無理 が発見されたとする。このとき、の記録は があると考える。式(1)の Pi を求めることは難 しい。 バグ発生率＝1/1＝1（件/行） つまり、ソフトウェアはたまたま「ある操作」 テスト網羅率＝0/5＝0（0%） 注：現実にはこの 1 行ではコンパイルも出来ないが、 を行うと障害が発生し、人体に危険が及ぶとい とりあえずの思考実験で、総コード数＝１と考える う状況で納入された場合を考えると、その「あ そこで、以下のようにコードを訂正し、 る操作」をしなければ、その装置が潜在的に障 害を持っていても、100%安全なシステムとして year%4==0 && year%100!= 0 2100 年のテストが OK となる。このとき、網 使われたと言える。逆に、その「ある操作」を 羅率は、 実行すると、世界中どこに納入されたシステム テスト網羅率＝1/5＝0.2（20%） であっても、必ず同じ障害が発生する。このよ － 35 － うな場合に信頼性の確率による評価というもの 監査の観点からは、各種チェック項目を用意し は、あまり意味をなさないと考える。 ておき、その項目を全て確認したか否か、その 結果問題点が有ったのか否か、などから製品を ��� 保証する方法を 6.1 で述べた。これは製造工程 ソフトウェア工学による対応 それでは、もっと良い方法があるのか。現在 での管理としても利用可能である。このチェッ のソフトウェア工学の流れの中で、安全性とは ク方式は、人手に頼っている。しかし、このよ 直接関係無いが、信頼性の観点からバグの無い うな管理ではなく、より積極的に製造工程で高 システムの保障を得るために、数理論理学を応 信頼性を求める方法は、目的別の言語を用意す 9) 10)による設計を行い、障害の ることが良いと考えている。それぞれの分野に 用した形式手法 事前除去を行うことが考えられている。しかし、 適合した超高級言語を用いることにより、人間 未だ誰でも、どこでも簡単に使えるレベルでは のケアレスミスおよび、システム上の決められ ない。人命にかかわるようなシステムに対して た手順を遵守したコードを自動的に生成できる は、形式手法の訓練を受けた専門家を投入し、 ならば、現実的な次善の策となり得る。 形式手法を用いて高信頼性のソフトウェアを構 築することが望ましいと考えている。 イメージとして理解しやすい言語として、レ ゴのマインドストーム用のプログラミング環境 過去に発生した障害の例として、Therac-25 がある。この環境はドラッグ・アンド・ドロッ やインテルにおける Pentium プロセッサの浮 プ形式でのプログラミングが可能になっている。 動小数点演算における障害がある。前者の事例 プログラミングにあまりトリッキーで細かい機 の場合、ソフトウェア設計上の問題とマン・マ 能を付加することよりも、基本的に必要な機能 シンインターフェースや開発プロセスおよび、 が使えるようになっていることが言語設計上の 開発者は、CMMI の成熟度 11)が未熟（レベル 1 王道と考える。 かまたはそれに近いか）であった等、色々なソ 言語を設計するということは、コンパイラな フトウェア工学上の問題を含んでいた。後者の りインタープリタなりを作ることになるが、現 事例は、障害発生後インテルにおいて、形式手 在は色々な道具がそろっており、言語を造るこ 12)が採用された。これは形式 とにそれほどの困難は無い。現在、C 言語を用 手法の事例として非常に良く適合したものと考 いてコンパイラを開発する場合は lex（又は える。この形式手法による、高信頼性の保障が flex）および yacc（又は bison） 13)を用いるこ 得られると、人間の目視による確認ではなく、 とができる。Java 言語でコンパイラを開発する 機械的なルールに従った信頼性の保障が得られ 場合は、JavaCC14)または SableCC15)を用いて る。このことにより、システムの安全への貢献 簡単に構築できる。筆者の経験では、JavaCC も大きくなると考える。 を用いて簡単な BASIC 形式のインタープリタ 法による設計方法 の場合、1 日あれば構築できた。このような言 語をつくる（コンパイラをつくる）ための情報 ��安全なソフトウェアへの�� いつでも、どこでも 100%安全なシステムを 構築することはとても現実的とは言えない。し は、インターネット上で検索すると、色々なサ ンプルや解説が見つけられる。 かし、いい加減な設計・製造をした場合に事故 今、最も大切なことは、その分野にうまく適 が発生したときは、その説明責任を問われるこ 合した簡易かつ実用上の要件を十分満たした言 とになる。 語の設計をすることに尽きる。ウェブ・アプリ そこで、ソフトウェアのバグを減らすことに ケーションの場合を考えると、php よりもより より、信頼性を高め、それに伴い安全なシステ 簡単に、かつセッション管理などによるセキュ ムに近いものを構築するためには、形式手法の リティも内蔵した言語があれば、通常のソフト ような高度な設計法以外に、次善の策として、 ウェア開発者ならば、誰もが助かると思う。 製造工程での対応方法が考えられる。システム － 36 － なお、新たな言語は、手続き型の言語ではな く関数型の言語が望ましい 16)と考えている。 9) 福良博史，ソフトウェア技術者の道具とし ての「formal methods」， ��まとめ 茨城職業能力開発短期大学校紀要， 第 11 号 pp.17-22,1998 年 12 月 安全かつ高信頼性のソフトウェアを構築する ためには色々な考え方がある。形式手法のよう 10) IPA，「形式手法適用調査」報告書， に 100%の信頼性を望まずに、高い安全性を維 持していくことは、都合の良い高級言語を考え 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 参考�� 1) 東日本旅客鉄道株式会社，新幹線新幹線輸 13) flex/bison を用いて以下のような応用例が 送障害,2011 年 1 月 18 日， ある プレスリリース 数値計算用インタプリタを作ろう， http://www.jreast.co.jp/press/2010/ http://www.oishi.info.waseda.ac.jp/~oishi 20110106.pdf /interpreter/interpreter.htm 2) Nancy Leveson， 14) JavaCC でスクリプト言語を作成する， Medical Devices: The Therac-25， http://codezine.jp/article/detail/367 15) コンパイラコンパイラ SableCC チュートリ http://sunnyday.mit.edu/papers/ therac.pdf アル， 3) Pentium FDIV bug， http://ameblo.jp/spicysoft/ http://en.wikipedia.org/wiki/ entry-10604354166.html Pentium_FDIV_bug 16) 福良博史，ソフトウェアにおけるものつく 4) 素材辞典 vol.27，メカ・歯車編， りの変革―Haskell と FPGA から見えてく 株式会社データクラフト る組込み系のものつくりの革新―， 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 － 37 － 職業能力開発総合大学校東京校紀要， 第 22 号 pp.83-90,2007 年 2 月
© Copyright 2024 Paperzz
