ソフトウェア品質の向上と安全の確保とは概念が異なることは何度となくこのブログで書いてきたが、今回、機能安全規格である IEC 61508 や ISO 26262 や、医療機器ソフトウェアのプロセス規格であるIEC 62304 の上位に位置する ISO/IEC GUIDE 51:1999 安全側面-規格への導入指針 にそのことがキチンと書いてあったので今回はそれを紹介しようと思う。
ISO/IECガイドとは、ISO と IEC の国際規格制定に関連する共通事項のガイドラインだ。ISO や IEC の規格制定、利用にあたっては ISO/IEC ガイドに留意する必要がある。例えば、下記のようなガイドがある。
ISO/IEC GUIDE 2 (2004)
Standardization and related activities -- General vocabulary
標準化及び関連活動－一般用語
ISO/IEC GUIDE 21 (1999)
Adoption of International Standards as regional or national standards
国際規格の国家規格への採用
ISO/IEC GUIDE 51 (1999)
Safety aspects -- Guidelines for their inclusion in standards
安全側面-規格への導入指針
これらは、ISO/IEC 規格を策定する際の共通事項のガイドなので、IEC 61508 も ISO 26262 も IEC 62304 もこれらのガイドに考慮する必要があるという訳だ。
今回、紹介するのは ISO/IEC GUIDE 51:1999 で、規格に安全に関する側面を導入する際の指針である。
なお、安全に関しては 日本では明治大学 理工学部 情報科学科の 向殿 政男 教授が有名である。向殿先生は、日本テレビ「世界一受けたい授業」やNHKの「クローズアップ現代」などにも出演されているのでテレビで顔を見たことがある方もいると思う。
向殿先生は ISO/IEC GUIDE 51 を解説した本『安全設計の基本概念―ISO/IEC Guide51(JIS Z 8051)、ISO 12100(JIS B 9700) (安全の国際規格) 』も出されているが、インターネット上の ISO/IEC GUIDE 51を説明した資料『2006-10-4日機連シンポジウム：「機械安全」の新しい波「機械安全」を取り巻く最近の動向』も公開されているのでそれを読むのもよいと思う。なお、ISO/IEC GUIDE 51は JIS Z 8051：2004 として JIS にもなっているので、このガイドのもとを日本語で読むことも可能である。
安全の定義
ISO/IEC GUIDE 51 によると安全(safety) とは 『受容できないリスクがないこと』 (safety: freedom from unacceptable risk) とある。この定義は非常に重要なのでクリティカルデバイスの開発に携わる技術者は頭の中にたたき込んでおいて欲しい。（受容できないリスク = unacceptable risk がキーワード。Risk は Acceptable か Unacceptable かを判断する。）安全の概念について ISO/IEC GUIDE 51に解説がある。
安全という概念
安全は，あらゆる技術領域にまたがり，かつ，ほとんどすべての製品，プロセス及びサービスのための規格で扱われている。市場に投入される製品，プロセス及びサービスは，ますます複雑化しており，安全の視点に立った配慮の優先度を高くすることが求められている。
絶対的な安全というものはありえない。この規格で残留リスクを定義しているように，ある程度のリスクは残る。そのため，製品，プロセス又はサービスは，相対的に安全であるとしかいえない。
安全は，リスクを許容可能なレベルまで低減させることで達成される。許容可能なリスクは，絶対的安全という理念，製品，プロセス又はサービス及び使用者の利便性，目的適合性，費用対効果，並びに関連社会の慣習のように諸要因によって満たされるべき要件とのバランスで決定される。したがって，許容可能なレベルは常に見直す必要がある。技術及び知識の両面の開発が進み，製品，プロセス又はサービスの使用と両立して，最小リスクを達成できるような改善が経済的に実現可能になったときには，特に見直しが必要である。
許容可能なリスクは，リスクアセスメント（リスク分析及びリスクの評価）によるリスク低減のプロセスを反復することによって達成させる（図 1 参照）。下記に「リスクアセスメント及びリスク低減の反復プロセス」の図を示す。
また、この図に出てくる用語も重要なので、言葉の定義を開催しておく。
リスク (risk)：危害の発生確率及びその危害の程度の組合せ。
危害 (harm)：人の受ける身体的傷害若しくは健康傷害，又は財産若しくは環境の受ける害。
危険事象 (harmful event)：危険状態から結果として危害に至る出来事。
ハザード (hazard)：危害の潜在的な源。備考 ハザードという用語は，起こる可能性のある危害の発生源又は性質を定義するために用いることが一般的に認められている（例えば，感電，押しつぶし，切断，毒性によるもの，火災，おぼれなどのハザード）。
危険状態 (hazardous situation)：人，財産又は環境が，一つ又は複数のハザードにさらされる状況。
許容可能なリスク(tolerable risk)：社会における現時点での評価に基づいた状況下で受け入れられるリスク。
保護方策 (protective measure)：リスクを低減するための手段。
備考 保護方策には，本質安全設計，保護装置，保護具，使用上及び据付け上の情報並びに訓練によるリスクの低減策を含む。
残留リスク (residual risk)：保護方策を講じた後にも残るリスク。
リスク分析 (risk analysis)：利用可能な情報を体系的に用いてハザードを特定し，リスクを見積もること。
リスクの評価 (risk evaluation)：リスク分析に基づき，許容可能なリスクに到達したかどうかを判定する過程。
リスクアセスメント (risk assessment)：リスク分析及びリスクの評価からなるすべてのプロセス。
意図した使用目的 (intended use)：供給者が提供する情報に基づいた製品，プロセス又はサービスの使用。
合理的に予見可能な誤使用 (reasonably foreseeable misuse)：供給者が意図しない方法であるが，人間の挙動から生じる容易に予測しうる製品，プロセス又はサービスの使用。
品質の定義
品質と安全を比較するために品質に関する情報を示す。SQuBOK（ソフトウェア品質知識体系ガイド）に品質の定義についていろいろな考え方が書かれているので、参考までに一部紹介しておく。（品質の概念はいろいろあるようだ。）
定義というよりは、つぶやきのようなもの？もある。詳細な説明はSQuBOKを参照して欲しい。なお、品質とソフトウェア品質は区別されていない。
- 「本来備わっている特性の集まりが、要求事項を満たす程度」[ISO 9000:2005]
- 「(1) システム、コンポーネント、またはプロセスが指定された要求を満たしている度合い。(2) システム、コンポーネント、またはプロセスが顧客またはユーザのニーズ、または期待を満たしている度合い」[IEEE Std 610.12-1990]
- 「指定された特定の条件で利用する場合の、明示的または暗示的なニーズを満たすソフトウェア製品の能力」[ISO/IEC 25000:2005]
- 「品質は誰かにとっての価値である。」[Weinberg 1994]
- 「システムが本稼働するときに、どこまで真のビジネス（ユーザ）ニーズにあっているかということ。」[Martin 1994]
- 「一つ目はプロダクトの特性が顧客のニーズに応えることで満足を提供するという観点、二つ目は不備（障害や誤り）から免れるという観点である」[Juran 1998]
- 「要件に対する適合」[Crosby 1980]
- 「機能および性能に関する明示的な要求事項、明確に文書化された開発標準、および職業的に開発が行われた全てのソフトウェアに期待される暗黙の特性に対する適合。」[Pressman 2005]
品質と安全は観点が異なる
一方、ISO/IEC GUIDE 51 には安全に関して次のような解説が書かれている。安全は『受容できないリスクがないこと』と定義される。すなわち安全は受け入れ不可能なリスクから解放されていることであり「受容できないリスクがない」ことを持って「安全」と規定される。
安全はリスクを経由して定義され，リスクはその時代，社会の情勢、環境によっても変化するため安全の尺度を一定にすることはできず，絶対的な安全を定義することはできない。そのため，製品，プロセスまたはサービスは相対的に安全であるとしか言えない。機器製造業者にとってリスクの概念は時代とともに厳しい方向に推移する。機器に施された安全装置、安全対策は消費者や社会が成熟するにつれて「付いているのが当たり前」「対策されているのが当たり前」と捉えるようになるからである。自動車のABS（アンチロック・ブレーキ・システム）が最初に登場したときはオプション機能だったが、今日本ではABSは付いていて当たり前になりつつある。国によって差がある点にも留意して欲しい。（機器の利用環境の成熟度によっても変わる。）
だから、リスクコントロール手段は一度設計すれば終わりという訳にはいかない。時代、社会の情勢、環境によって見直しを続けなければいけない。だから、上記の図は「リスクアセスメント及びリスク低減の反復プロセス」なのだ。機器が市場にある限り、リスクアセスメントとリスク低減は反復しなければならない。
安全は，リスクを許容可能なレベルまで低減させることで達成される。許容可能なリスクは，製品，プロセスまたはサービスにおける使用者の利便性，目的適合性，費用対効果，並びに関連社会の慣習のように諸要因によって満たされるべき要件とのバランスで決定される。
したがって，許容可能なリスクは常に見直す必要がある。技術及び知識の両面の開発が進み，製品，プロセスまたはサービスの使用と両立して，最小リスクを達成できるような改善が経済的に実現可能になったときは，特に見直しが必要である。技術は時代とともに進歩する。リスクコントロール手段も新しい技術によって、より効果的な対策に置き換えることができるかもしれない。だから、機器の後継機種を開発する際には、「リスクアセスメント及びリスク低減の反復プロセス」をもう一度回して、よりよいリスクコントロール手段がないかどうかを検討しなおす必要がある。
下記にリスクを受容可能にするための手順を示す。
- 製品，プロセスまたはサービスの対象と考えられる使用者及び触れることが予見される者を特定する。
- 製品，プロセスまたはサービスの意図した使用を特定し，合理的に予見可能な誤使用を見積もる。
- 製品，プロセスまたはサービスの使用（据え付け，保全，修理及び解体，廃棄を含む。）の全段階及び全条件においてハザード（危険状態及び危険事象を含む。）を個々に特定する。
- 特定したハザードが引き起こす個々に特定された使用者群及び接触者群に対するリスクを見積もり評価する。
- そのリスクが許容可能かどうかを判断する（例えば，類似の製品，プロセスまたはサービスを比較して）。
- そのリスクが許容可能なものでなければ，許容可能なレベルまでリスクを低減する。
- 本質安全設計
- 保護装置
- 使用者に対する情報
本質安全設計を実現する本質的安全設計方策とは「ガードまたは保護装置を使用しないで，機械の設計または運転特性を変更することによって，ハザードを除去するまたはハザードに関連するリスクを低減する保護方策」である。
また，保護安全を実現する方策は安全防護策と付加保護方策がある。保護防護策とは「本質安全設計によって合理的に除去できないハザード，または十分に低減できないリスクから人を保護するための安全防護物の使用による保護方策」であり，付加保護方策とは，非常停止，機械などに人が捕捉された場合の救助手段，脱出ルートの設置などを指す。この方策は支援安全機能と考える。
安全はリスクを許容可能なレベルまで低減させることで達成される。リスクを低減させるためには事前にリスクの特定、リスク分析、リスク評価といったリスクアセスメントが必要になる。
このことが安全に責任を負ったことのない人にはピンとこないらしい。品質を高める手法が仮にあったとしても、それがすべてのリスク低減に効くとは限らない。
例えば、OSやアプリケーションソフトウェアが暴走したときにCPUをリセットさせるためのウォッチドッグタイマーというCPUから独立したデバイスがある。一見、ウォッチドッグタイマーはすべてのリスクに有効なリスクコントロール手段になり得るような感じがする。
しかし、ウォッチドッグタイマーだけでは解決できないリスクもある。例えば、医療機器の生体情報モニタには意識のない患者さんの血圧を自動で定期的に測定するインターバル測定の機能がある。健康診断で使う上腕にカフを巻いて血圧を測定するやり方を例えば30分おきに機械が自動的に計測する機能だ。
そして、この非観血血圧測定の国際規格には次のような要求がある。
電源の瞬断があっても、血圧のインターバル測定の設定は維持されなければいけない。
※正確には下記が該当する要求文章。（すべての設定は変更されてはならない）
※正確には下記が該当する要求文章。（すべての設定は変更されてはならない）
When the equipment contains an internal electrical power source and is capable of operating from it, and the mains supply is interrupted, does not apply. In this case the equipment shall continue operation, and the mode of operation and all operator settings shall not be changed. (IEC 60601-2-30:1999)なぜ、こんな要求があるのかと言えば、意識のない患者さんの生体信号を計測している生体情報モニタにリセットがかかって、インターバル測定がリセットされると血圧の測定が中止されてしまう。ナースステーションにいる看護師さんや先生は血圧測定が定期的に行われていると思っているから、患者さんの血圧の変化に気がつかない。
このようなリスクがあるから個別規格にはこんな要求があるのだ。ちなみに、この要求は技術的にどのようにクリアすればよいか分かるだろうか。
まず、血圧のインターバル測定を開始したときは、装置内の不揮発性メモリ（例えばフラッシュメモリ）にその内容を記録しておく。インターバル測定が終了したときにはクリアする。
そして、電源が立ち上がったときに、まず、その領域をチェックしに行きインターバル測定のデータが残っている場合は、何らかの原因でインターバル測定が異常終了したと判断する。
※この方法を実施するには不揮発性のメモリが必ず必要だからコストダウンを理由にフラッシュメモリを取り除くことはできない。リスクアセスメントをしていなければやってしまうかもしれない。
ウォッチドックタイマーによるCPUのリセットはそこだけを捉えれば、信頼性を確保するための有効な手段かもしれないが、どんなシステムに使うのかが分からなければ、リスクの特定、リスクの分析、リスク評価ができないから、リスク低減策として使えるのかどうかを判定できない。したがって、”安全”を示す、すなわち「受容できないリスクがないこと」が言えないのである。
このことは、すべてのリスクに対して有効に働くリスク低減手段は存在せず、個々の製品、プロセスまたはサービスに対してスクアセスメントを行った上でリスク低減策を設計しなければ安全は確保できないことを示している。
これは、製品、プロセスまたはサービスの品質が高いことと安全であるとは同位ではなく、品質の概念と安全の概念の間に異なる観点が存在することを意味している。
品質と安全はビュー（観点）が異なるのだ。このことは、すべてのドメインに共通の品質向上策を武器に商売したい人たちにはとてつもなくマイナスな要素である。
品質の概念の一つに「顧客満足を高める」があり、これが安全の定義である「受容できないリスクがないこと」につながると思うが、どっちにしても安全を確保するためには、リスクを特定、分析、評価することは絶対に必要であり、それは機器やシステムが使われる場面を知っている者でなければできない。
ソフトウェアの品質特性を説くことと、リスクの特定、分析、評価は観点が異なるのだ。このことが分かっていないソフトウェア品質のエキスパートと呼ばれる人と話していても目指しているところが異なるからいつまでたっても議論がかみ合わない。
最後にもう一度繰り返すと、製品、プロセスまたはサービスの品質が高いことと安全であるとは同位ではなく、品質の概念と安全の概念では観点が異なる。
安全を実現するためには、リスクの特定、分析、評価といったリスクアセスメントを行った上で、リスク低減策を考える必要がある。リスク低減策を考える上で品質向上策は役立つかもしれないが、それはあくまでもリスクアセスメントを行った後に初めて判断できる。
そして、リスクアセスメント及びリスク低減のプロセスは、製品やサービスが市場にある限り反復しなければいけない。
したがって、セーフティ・クリティカルな製品を開発しているエンジニアは、リスク低減策について学ぶ前にリスクアセスメントに役立つ技術を習得すべきであると自分は考えている。そうしないと、受容できないリスクがなくなったかどうか判断できないからだ。
0 件のコメント:
コメントを投稿