2012-07-29

ISO 26262との向き合い方 (12) 対訳版を読み始めて思うことあれこれ

ISO 26262-1 第1部:用語集 (日本規格協会から発行されている英和対訳版)を読んでいる。読んでいて思うのは、ISO 26262 は用語の定義の全体数が多く、かつ、専門用語が多いのでソフトウェアエンジニアには難解なことばがあるという点だ。

それと、ISO 26262 全体の構成について感じるのは、ハードウェアの開発プロセスとソフトウェアの開発プロセスをそれぞれ別パートで分けていながら、安全の評価基準であるASILはハード、ソフトを一緒に考えているところに「本当にそれで大丈夫か」と感じる。

ASILを分割する考え方であるASILデコンポジッションについても、十分に独立したエレメントが存在することが前提となっている。ようするに、自動車は独立した部品の組み合わせで構成されているという考え方だ。

しかし、我々は複雑化したソフトウェアをそれぞれコンポーネントとして十分に独立させることができていないことが、様々な問題を起こしていることを知っている。

ハードウェアの独立とソフトウェアの独立の議論は同じレベルで語れないはずなのに、ISO 26262では、ハード、ソフト込みのエレメントがベースになっている。

まあ、それはそれとして今回はISO 26262-1 第1部:用語集の気になる用語のいくつかを話題に取り上げようと思う。

【Anomaly:アノマリー】
例えば、要求、仕様、設計文書、ユーザ文書、標準又は経験をもとにした期待から逸脱している状態。
備考 アノマリーは、レビュー、テスト、分析、まとめ、あるいはコンポーネントや適用可能な文書の仕様といった別の機会に発見される場合がある。
ISO 26262 の対訳版では Anomaly をそのまま「アノマリー」と表現している。

Anomaly を辞書で引くと Longman の英英辞書では
Something that is noticeable because it is different from what is usual:
ウィズダムの英和辞書では
1 異常(なこと)、例外(的なこと)、特異な存在、異例、変則;不合理
とある。医療機器のソフトウェアライフサイクル規格 IEC 62304:2006 の JIS 版 JIS T 2304:2012 では Anomaly は日本語では「異常」としている。

異常(ANOMALY)
要求仕様書,設計文書,規格など,又は既存の認識若しくは経験に基づいて予想した結果を逸脱する状態。異常は,ソフトウェア製品又は該当する文書のレビュー,試験,分析,コンパイル又は使用中に発見されることがあるが,これには限定しない。
この日本ではなじみのない Anomaly:アノマリーということばを、今回 ISO 26262 の対訳版でそのまま「アノマリー」と表現したのは、その本質的な意味を表す適当な日本語が見つからなかったのであろう。

何が日本語では表現できないのかというと、アノマリーは発見された時点では不具合と確定していないというという点だ。Error, Failure, Fault はそれぞれ、問題があるということが分かっている。しかし、Anomaly:アノマリーは、"Something that is noticeable because it is different from what is usual:" だから、いつもとは違う、あるいは期待から逸脱しているだけで、発見された時点で不具合であることが確定している訳ではない。

ここで、Anomaly を「異常」と言ってしまうと、問題がある、瑕疵・欠陥があることを認識しているいうニュアンスが強くなってしまう。

Anomaly が組織が不具合と認めている欠陥なのか、それとも不具合があるかもしれないし、ないかもしれない問題なのかその違いは大きい。欠陥を認める前なのか後なのかが重要なのだ。

ようするにソフトウェアの開発時に問題など山ほど起こる。我々はそれらをBUG:バグと言うわけだが、バグの中には仕様の誤りや勘違いも少なからずあるし、バグだと思って調べたら実はそうではなかったということもある。

もし、ソフトウェアに起因する事故が発生し、訴訟が起きたとき重要なのは、問題点を製造業者側が不具合、欠陥と認識していたかどうかだ。不具合と認識していていたにも関わらずそれを修正せずに放置したことで事故が起こったのならば、その責任は製造業者にある。

現実には開発の工程で発見された問題点は、それが受容できないリスクに繋がるのか、それとも受容できるのかを判定する。受容できる場合は、製造業者はその問題点を修正しない選択しを取ることも許されている。一般の方はそれが不合理だと思うかもしれないが、例えばこういう例を考えて欲しい。保守用のソフトウェアで自己診断の"PASS" というメッセージの最後のSの右側縦1ドットがまれに欠けることがあったとする。装置の診断は問題がないし、PASSからFAILの判定もできる。しかし、どこで誰が縦1ドットを消しているのかが、どうしても分からない。これはソフトウェアのバグであり不具合ではあるが、ユーザーが受容できるリスクと判定できる。この場合、バグは残留しており、どのようなバグであるのか、誰がリスクを重要できると判断したのかを残しておくことで商品をリリースすることができる。(Anomaly がゼロの状態でソフトウェアがリリースされているとは誰も思っていない)

不具合、欠陥を組織が認める前なのか後なのかの識別が重要であることがおわかりいただけたと思う。そう考えると、いつもとは違う、あるいは期待から逸脱している、怪しいが確証はない事柄は現実に存在し、それらが不具合や欠陥であると確定していないことを表現する言葉が必要になる。それがアノマリーだ。

アノマリーに関連して、 inspection:インスペクションtesting:テストwalk-through:ウォークスルー の説明も見てみよう。

インスペクション
アノマリーを検出するため、形式が定められた手続きに従う作業成果物の審査
備考1 インスペクションは検証の一手段である。
備考2 関連するアイテム又はエレメントの動作を通常伴わない点が、テストと異なる。
備考3 通常、検出されたアノマリーは再作業により扱われ、その作業成果物は再度インスペクションされる。
備考4 通常、形式が定められた手続きには前もって定められた手順、チェックリスト(の使用)、調整役(の出席)及び結果のレビューが含まれる。
テスト
指定された要求を満たすことの検証、アノマリーの検出及びふるまいに対する確認を得るための、計画と準備とアイテムまたはエレメントの動作又は実行のプロセス。
ウォークスルー
アノマリーを検出するための、作業成果物の体系的な審査

備考1 ウォークスルーは検証の一手段である。
備考2 関連するアイテム又はエレメントの動作を通常伴わない点がテストと異なる。
備考3 通常、検出されたアノマリーは再作業により扱われ、その作業成果物は再度ウォークスルーされる。

例 ウォークスルー中、開発者は一人以上のアセッサーに対して、段階を追って作業成果物を説明する。この目的は作業成果物に対する共通理解を築き、作業成果物に存在するアノマリーを識別することである。インスペクションとウォークスルーはいずれもピアレビューの一形式であるが、ウォークスルーと比べると、インスペクションの方がやや難しい。
【ISO 26262-2 第2部 機能安全の管理 付属書B(参考) 安全文化評価の例】

ISO 26262-2 第2部 機能安全の管理 付属書Bに 安全文化評価の例が載っている。これは本文には入っておらず、参考なので規格要求ではないが、非常に興味深い内容なので、掲載しておく。


不十分な安全文化を示す例良い安全文化を示す例 
責任がトレースできない。プロセスが関連する機能安全の決定責任のトレースを保証する。
常に費用及びスケジュールが安全及び品質に優先する。安全が最も優先順位が高い。
報酬システムが安全及び品質に対してよりも費用及びスケジュールを評価する。報酬システムが機能安全の効果的な達成を支持し、動機付ける。

報酬システムが、安全及び品質を危険にさらす近道を取る者を罰する。
安全、品質及びそれらの管理を評価する者が、プロセスを実行する責任者に過度に影響される。プロセスが適切なチェック及びバランスを与える。例えば、組み込まれたプロセス(安全、品質、検証、妥当性確認及びコンフィグレーション管理)の適正な独立性。
安全に対する受動的な態度、例えば

-製品開発サイクルの最後のテストへの過度の依存
-フィールドに問題がある場合だけ管理者が動く
安全に対する積極的な態度、例えば

-安全及び品質の問題は製品ライフサイクルの初期の段階で発見され、解決されている。
必要なリソースがタイムリーに計画、配置されない。必要なリソースが配置されている。

技能のあるリソースが割り当てられた活動に相応しい能力をもつ。
“集団思考”

レビューグループを作る際に“不正工作”をする。
反対者が追放される、または“チームの者ではない”とレッテルを貼られる。
異議は勤務評定でマイナスに働く。
 “少数派の反対者”が“トラブルメーカー”、“チームの者ではない”又は“密告者”といった扱いをされたり、レッテルを貼られる。
 関連する従業者が跳ね返りを恐れている。
プロセスが率先して多様性を行使する:

-知的な多様性が求められ、価値を与えられすべてのプロセスに組み込まれる。
-多様性に行使に反対するふるまいをやめさせ、罰する。
     
 コミュニケーションの支持及び意志決定のチャネルが存在し、管理者はそれらの行使を推奨する。
-自己開示が推奨される。
-他のだれによる発見の公開も推奨される。
-発見及び解決のプロセスがフィードで継続される。
体系化された継続的な改善のプロセス、学習サイクル又は“教訓”の活用がない。継続的な改善がすべてのプロセスに組み込まれている。
プロセスが“その場しのぎである”又は暗黙である。定義され、トレース可能で、管理されたプロセスに以下を含むすべてのレベルで従っている。

-管理
-エンジニアリング
-開発インタフェース
-検証
-妥当性確認
-機能安全監査
-機能安全アセスメント

これは安全文化について書かれているのだから、安全文化が不十分か、それとも十分かの判断に違和感を覚える部分があれば、それが欧米と日本の意識の違いであると言える。


例えば、「レビューグループを作る際に“不正工作”をする。」「反対者が追放される、または“チームの者ではない”とレッテルを貼られる。」「異議は勤務評定でマイナスに働く。」などは、そこまではないだろうと思う一方で、製品開発サイクルの最後のテストへの過度の依存」や「フィールドに問題がある場合だけ管理者が動く」などという指摘点は、どこも同じなんだなと感じる。


【安全対策が簡単ではない例】

ISO 26262 とは関係ないが、ソフトウェアに関する安全はソフトウェアの複雑性から脅かされるという例を紹介したいと思う。

6/20 にレンタルサーバーを運営しているファーストサーバにて、大規模なデータ喪失障害が発生た。脆弱性対策のためのメインテナンスプログラムに問題があり、そのプログラムが稼働中のデータのみならずバックアップデータまで削除してしまったことが原因だった。

大規模障害が起こった原因の詳細についてはこちらを読んでいただくとして、なぜ、ソフトウェアのシステマティック故障が起こるのかについて考えたので下記を見て欲しい。システマティック故障がソフトウェアの複雑性に絡んで発生することがよく分かる。

障害の原因3:メンテナンス仕様
システムを含むデータのバックアップは毎朝6時に取得しております。しかしながら、脆弱性対策のためのメンテナンスはバックアップをしてあるシステムについても実施しておかないと、メンテナンス実施後にハードウェア障害が発生してバックアップに切り替えた途端に脆弱性対策が講じられていないシステムに戻ってしまうことが過去に発生し、脆弱性対策がなされていないシステムが動き続けていたという反省に立ち、脆弱性対策のメンテナンスに関しては対象サーバー群とそのサーバー群のバックアップ領域に対して同時に更新プログラムを適用するという構造に修正して実施しました。
過去に、脆弱性対策をバックアップシステムにも適用しておかなかったために、ハードウェア障害が発生してバックアップシステムに切り替わると脆弱性対策が行われていない状態になるという問題が発生したとある。今回の大規模障害と比べればリスクレベルは低い問題だ。しかし、リスクは受容できないレベルであると考えられ、脆弱性の対策は本番環境だけでなくバックアップシステムにも同時に実施するように運用が変更された。実は、このリスクコントロール対策自体にリスクがあった。


脆弱性対策のプログラムに問題があると本番環境とバックアップ環境の両方に影響を及ぼすという新たなリスクである。バックアップは本番環境に何か問題があったときのリカバーのための対策であるから、後に発見された相対的に小さなリスクに対するリスクコントロール対策を追加したことによって、もともとあった大きなリスクに対するリスクコントロール対策の効果及び堅牢性を低下させてしまったことに気がつかなかった。


実はリスクコントロール対策を行う際に追加したリスクコントロール対策が新たなリスクを生むことはよくある。よかれと思ってやったことが、逆にシステムを脅かしてしまうことがあるのだ。


だからリスクコントロール対策を追加したり、修正したりするときは、その対策を実行することにより発生する新たなリスクがないかを分析しなければいけない。また、ただ分析すればよい訳ではなく、これまで構築してきた安全対策のアーキテクチャが崩れていないかどうか、リスク対策の効果が弱まっていないかどうかをチェックする必要がある。


ソフトウェアエンジニアは商品やサービスのリリース後に問題が発見されると、すぐにソフトウェアを修正してしまうが、商品リリース後のソフトウェア修正は慎重かつ、何重ものチェックの上で実施されなければいけない。その慎重さのレベルは対象となっているソフトウェアアイテムの重要度の大きさによっても変わる。(変更に対するリスクが受容できることが明確ならばアジャイルでどんどん直すことも可能だが、人の命がかかっているようなソフトウェアはそれではまずいことは明白だ。)


さて、ファーストサーバの大規模障害では、本番環境とバックアップシステムの両方に脆弱性対策を行うという運用の変更を行った結果、脆弱性対策のプログラムのミスによるデータの削除が本番環境のみならずバックアップシステムにも及んでしまった。

脆弱性対策の削除コマンドを消し忘れたというプログラムミス自体はヒューマンエラーだ。
しかし、この大規模障害はよかれと思った実施した追加の対策により、最初に考えられていた安全対策の効果及び堅牢性が弱まってしまった。そこに、ミスが重なり、予想していなかった Hazardous Situation が現実のものとなってしまった。

ISO 26262でも同じことは起きると思う。サプライヤを含めたソフトウェア開発組織がISO 26262 の要求する要求(主にプロセス要求)を満たせたとしても、よかれと思って実施したソフトウェアの変更がソフトウェアシステムの複雑性を助長し、その変更が既存のリスクコントロール対策に悪い影響を与える可能性がある。そして、それまではリスクに対して堅牢であったのに、ソフトウェアを変更したことによって堅牢性が失われ、これまでブロックできていた  Hazardous Situation が現実になり、そこから思いもよらない大規模な障害が発生するという事態もありうる。


そうなることを防ぐためには、ソフトウェアの複雑性の特徴を考慮して、安全対策の評価やコンポーネント、エレメントの分割と独立性の評価が不可欠であると考える。

まだ、規格要求を読み始めたばかりだが、その部分の考慮が足らないと感じる。

0 件のコメント: