さらに混迷を深めているのは ISO 26262 ではエレメントの概念がハードとソフトを明確に区別していない、それぞれの特徴を十分に考慮できていない、エレメント同士の結合について踏み込めていないところだ。
そもそも ISO 26262 はECU を含む自動車の構成部品をメーカーがサプライヤから“調達する”という前提に立っているから、ハードウェアの特性とかソフトウェアの特性を考慮した安全設計という概念が不足していように感じる。
ASIL D は ASIL C(D) + ASIL A(D) や ASIL B(D) + ASIL B(D)にデコンポジション（分解）できると書かれているのだが、デコンポジション後のエレメントの十分な独立性の証拠が必要（原文では evidence for sufficient independence of the elements after decomposition shall be made available, 訳文では 十分な独立性の証拠が利用可能でなければならない）とされている。
この規格の問題点は独立性の証拠の証明のしかたについては言及していないところだ。（ソフトウェア開発の方法論、検証方法には言及しているのに）
エレメント同士の独立の条件として、従属故障を起こさないということが書かれており、ISO 26262-8 （支援プロセス）に従って安全分析をしなさいと書いてある。
では、最近複数の自動車メーカーがCMで宣伝している前方に障害物があると自動的にブレーキがかかるプリクラッシュブレーキシステムの場合はどうなるのだろうか。
ブレーキの基本機能は ASIL D だろう。画像解析のエレメントは ASIL D なの？という疑問が生まれる。 プリクラッシュブレーキ システムはシステム全体としては ASIL D だろうから、ブレーキの基本機能は ASIL D のままで、画像解析エレメントは ASIL C(D) にデコンボジションしたとする。
その際にブレーキエレメントと画像解析エレメントは独立しており従属故障は起こらないと言えるのだろうか。
画像解析エレメントが対象物を誤認して、対象物があるのにないと判定したり、逆に対象物がないのにあると判定したりしたら、ブレーキエレメントに誤った指令を送ることになる。これは意図した使用とは異なっているので従属故障ではないのか？
ではこれは従属故障ではないとして、システムの複雑化の代償としてのケーススタディを考えてみよう。
台風で1m以上の木の枝が車の前にが飛び出してきた。でも後ろから大型トラックがほとんど車間距離なしで追走しており、バックミラーをみたら大型トラックの運転手は携帯電話を見ている。
「 プリクラッシュブレーキシステムは今は働いて欲しくない」と運転手は思ったが、システムは作動し、大型トラックに追突された。このケースは故障ではない？ でも事故に遭ったユーザーはどう考えるだろうか。そんなことろまで考えて作るのが自動車メーカーだと考えないだろうか。想定外を想定するのが日本の企業だと思わないだろうか。
また、障害物の認識と運転手のハンドル操作がほとんど同時だった場合はどうするのだろうか。仕様では運転手のハンドル操作を認識するとプリクラッシュブレーキシステムは動作しない仕様があるとして、例えば障害物の認識とハンドルを切り始めた時点が100msも遅れていなかったら、どっちが優先されるのだろうか、判断を許容範囲の時間（例えば3秒）を設けなくてもよいのだろうか。プリクラッシュブレーキの起動が始まってから1秒後に運転手のハンドル操作を認識したら、プリクラッシュブレーキを中断するのだろうか。
プリクラッシュブレーキによる後ろの車両からの追突といった危険状態（Hazardous Situation）を回避するために、車の後ろにもセンサーを設置して、十分な車間距離が取れているときだけ自動停止システムを働くようにしたとする。しかし、そうするとますますシステムは複雑化する。また、車間距離センサに泥や異物がくっついていて十分に働かなかったらどうする。その時はエラーを表示する。そのエラーインジケート処理が失敗していたらどうする。
安全のためだと思ってリスコントロール手段を追加すると、追加したリスクコントロール手段によって発生しうる新たなリスクに対処しなければいけない。新たなリスクコントロール手段の設置によって、システムは複雑化し、さらなるリスクを生む可能性がある。リスクを回避するために追加したリスクコントロール手段によって発生する二次的なリスクは元のリスクよりも小さくなるのが普通だろうと思ったら大間違いだ。
ハードウェアの故障だったら確率は漸次小さくなる可能性が高い。ハードウェアの故障はランダム故障の場合が多いから、もとのシステムと安全装置の故障が二重に起こる確率は下がる。部品の故障率ならば1万分の１×1万分の1で、10億分の1など。
ところが、リスクコントロール手段をソフトウェアで実施した場合はそうではない、ソフトウェアはハードウェアのような壊れ方（不具合の発生のしかた）をしない。Systematic Failure を起こす。
問題の種類によっては、リスクコントロール手段として用意した安全装置のソフトウェアのちょっとした問題が元のシステムに多大な影響を与えることがある。それがソフトウェアのおそろしいところだ。
サーバー管理会社が起こした大規模障害
レンタルサーバーを提供するファーストサーバが6月20日に大規模なデータ消失事故を起こしたのをご存じだろうか。
Computerworld の記事が図入りで分かりやすかったのでリンクを示しておく。
『ファーストサーバ、大規模障害の概要と原因を中間報告――複数要因が重なりデータ消失』
こちらはファーストサーバの原因説明ページ
『大規模障害の概要と原因について（中間報告）』
自分の所属コミュニティの SESSAME のWEBサイトはファーストサーバを使っており、サイトの情報は一時、きれいさっぱり消えてしまった。（幸いSESSAMEのWEBサイトは1時間足らずの作業で元通り復旧した。）
さて、みなさんの組織は重要な企業情報のデータのバックアップを取っておられるだろう。個人のローカルPCの中のデータはもしかしたらバックアップは取っておらず、誤って消さないように気をつけて使っているかもしれない。
バックアップシステムは安全対策（=安全アーキテクチャ）はフォールト・トレラント (Fault Tolerant) の一種と言える。
フォールト・トレラント (Fault Tolerant) とは、故障や誤動作が発生しても機能が正しく維持されることで、大抵は構成要素の多重化 (冗長化) によって実現される。
本体に何かがあってもバックアップで冗長化したことで元の機能を復帰させることができる。
フォールト・トレラント (Fault Tolerant) とは対照的な安全対策として、フォールト・アボイダンス (Fault Avoidance)がある。フォールト・アボイダンス (Fault Avoidance)は故障の可能性を充分に低くすることであり、部品の高信頼性を目指すことで安全を実現する。バックアップを取らずに慎重に作業するという行為はフォールト・アボイダンス (Fault Avoidance)に近い。
フォールト・アボイダンス (Fault Avoidance)は、そもそも故障しないようにして、安全性を確保するやり方だ。
フォールト・トレラント (Fault Tolerant)は多重化・冗長化をするために、システムとしての複雑性が増す。逆に、フォールト・アボイダンス (Fault Avoidance)は冗長化設計より構造がシンプルになる。
安全対策では、フォールト・トレラント (Fault Tolerant)もフォールト・アボイダンス (Fault Avoidance)もどっちも選択できる。フォールト・トレラント (Fault Tolerant)を選べば、システムの複雑性は増すが、部品の故障率は厳格に管理しなくてもよい。（ランダム故障なら二重故障、三重故障の確率は低くなるから。）
フォールト・アボイダンス (Fault Avoidance)を選ぶと、故障率の低い部品を選んだり、ソフトウェアなら検証の網羅性を高めないといけないが安全システムの構造はシンプルになる。
この構造がシンプルかどうか、すなわち安全を司るエレメントやソフトウェアモジュールが、他から見て高凝集で疎結合であるかどうかが、ソフトウェアの場合非常に重要な要素である。
ハードウェアだけで構成されるシステムの場合は、フォールト・トレラント (Fault Tolerant)にしたことによるリスクは少ないが、ソフトウェアの場合フォールト・トレラント (Fault Tolerant)を採用したときのリスクは小さくない。
なぜなら、ソフトウェアによる冗長設計は問題がないことを証明することが困難であり、ちょっとした問題がシステム全体に影響を及ぼす Systematic Failure の特性を持っているからだ。
ファーストサーバの障害は、次のような事象が重なって発生した。
- 更新プログラム自体に不具合があった。
- 検証環境下での確認による防止機能が十分に働かなかった。
- メンテナンス時のバックアップ仕様の変更が重なり、バックアップ・データの消失を含む今回のデータ消失が発生した。
ファーストサーバの中間報告では原因1として下記の説明がある。
脆弱性対策のためのメンテナンスが必要となる都度、メンテナンスのための更新プログラムを作成しており、今回も更新プログラムを作成しています。メインテナンスのための更新プログラムを都度作成しているとある。オペレーション的には普通に思えるが、安全対策でフォールト・トレラント (Fault Tolerant)を採用していたと考えると、冗長設計したもう片方の安全システムへの変更を定常的に行っていたとも読み取れる。
そのプログラムの記述において、ファイル削除コマンドを停止させるための記述漏れと、メンテナンスの対象となるサーバー群を指定するための記述漏れが発生していました。
もちろん、変更に対するデグレードの危険性は考慮していた。だから、検証環境で試してから本番環境に移すというオペレーションを実行していた。
しかし、それでも事故が起こってしまったのは、検証環境と本番環境には差があり、本番環境で実施して初めて分かる問題があった、すなわち検証環境で行ったテストはレグレッションテストとしては漏れがあったということである。（100%の検証はできないので、検証環境ではテストの漏れを完全に無くすことはできない。）
そして、たった数行の意図しない動作で今回の大規模障害は起こった。
具体的には「ファイル削除コマンドを停止させるための記述漏れ」と、「メンテナンスの対象となるサーバー群を指定するための記述漏れ」が組み合わさった結果である。
ソフトウェアの Systematic Failure の恐ろしさはここにある。たった二つの記述漏れが、とんでもない大規模障害を生み出してしまうのだ。ハードウェアのランダムエラーではこんな被害の拡大の仕方はしない。
今回の障害のきっかけもソフトウェアの変更だった。何事もなく動作していているシステムに対するソフトウェアの変更には危険が潜んでいる。
何事もなく動作している自動車システムのソフトウェア搭載部品を部品ごと変更するのも同様に危険を含んでいるし、エレメント内部のソフトウェアに変更を加えるのも危ない。
ASIL のデコンポジションの独立性証明
最初の話に戻ると、ISO 26262 では ASIL のデコンポジションの独立性を、従属故障の可能性の分析して判断せよと言っているが、その際にソフトウェアの特性を考慮しなくてもいいのだろうか。結合の仕方についてもっと突っ込まなくていいのだろうか。エレメントやサブエレメント同士の結合に関する考察が不足しているように感じる。下記の appropriate measures （独立性を達成するための適切な対策）って何なのということだ。
【ISO 26262-9:2011 5.4.6 より】
If ASIL decomposition is applied at the software level, sufficient independence between the elements implementing the decomposed requirement shall be checked at the system level and appropriate measures shall be taken at the software level, or hardware level, or system level to achieve sufficient independence.
ASIL デコンポジションがソフトウェアレベルで適用される場合、デコンポジションされた要求を実装するエレメント間の十分な独立性がシステムレベルにおいてチェックされなければならず、十分な独立性を達成するために、ソフトウェアレベルまたはハードウェアレベルまたはシステムレベルにおいて、適切な方策がとられなければならない。
【引用終わり】
安全対策の複雑化と安全アーキテクチャの安定性にはトレードオフの関係があり、それはシステム全体として考えていかなければいけないのに、サプライヤから供給される部品をくみ上げて車を作ることだけを前提に考えていると安全アーキテクチャの安定性が軽視されるのではないかと感じる。
市販化されているプリクラッシュブレーキシステムも、安全対策はよく考えられているのだろう。WEBサイトを覗いてみたら運転手がハンドル操作やブレーキングをした場合はシステムは動かないと書いてあった。運転手の意思の方を優先させていることが読み取れる。
しかし、システムの複雑化、特にソフトウェアが絡んだシステムの複雑化は思わぬ問題を生み出す危険性がある。ASIL D のエレメントをデコンポジションできていると言えないと、複雑化した巨大システム全体のすべての機能の信頼性が高いことを証明しないといけない。
ASIL 分解の独立性を証明できないから、数十万行、数百万行のソフトウェアシステムの信頼性をフォーマルメソッドで証明せよというのはナンセンスだと思う。安全対策をより確実なものとするために ASIL のデコンポジションは必要だ。でも、独立性の完全性や従属故障が絶対に起きないなどとは言えない。その状況下でベストな選択は何かを考えないといけない。
ソフトウェアが搭載されたエレメントの信頼性の証明は難しいし、自分はソフトウェアの完全性の証明は永遠にできないと思っている。ソフトウェアでシステムを実現している以上、Systematic Failure のリスクは一生背負っていると考えた方がよい。それを完全に排除しようとするのではなく、できるだけ小さくするには何をどうすればよいのか考えないといけない。
そう考えると、ソフトウェアモジュールの分割とその独立性の証明、アーキテクチャの洗練は非常に重要になる。それは、ASIL D = ASIL C(D) + ASIL C(D) といった単純な式で表せるようなものではないと思う。
むろん、プロセスアプローチだけで解決できない。もっと、ISO 26262 を読み込まないといけない。
P.S.
ファーストサーバの事故再発防止策はおそらくこんな感じになるだろう。
- 検証環境におけるテストの網羅性の向上。（レグレッションテストに対するカバレッジの計測と記録も必要）
- ファイル削除コマンドといった影響度の高いコマンドをリストアップし、保守ソフトにおいてそれらのコマンドが使用されていればそこだけ抽出し、設計者以外の第三者によるレビューを行う。
- さらなるフォールト・トレラント (Fault Tolerant)として、保守ソフトを監視するソフトウェアを追加し、危険を察知したら保守ソフトを止める。（システムが複雑になるので、あまりお勧めはしない）
----------
この記事を読まれた方は『要求分析と安全設計との関係（機能安全の致命的な欠陥）』もどうぞ。
2 件のコメント:
今回のブログをISO26262について調べていてたまたま発見し、大変面白く読ませていただきました。
私はISO26262を遵守した設計をするシステムLSIの設計にかかわってます。
ソフトウェアと同様にシステム構成を持つＬＳＩ(当然組み込みソフトと協調して動作します)の場合も、同様な問題があり、正直言って、この規格に従ったところで安全性が高まると思えない部分が多くあります。
一方、とりあえず、商売のために規格を遵守し、そのエビデンスを作成する。(手法が定義されていない部分は、このように定義した手法で解決しているとエビデンスを残す)ことによりISO26262を遵守した設計を行っています。
ヨーロッパの人にそんなに知り合いは多くないですが、議論をすると必要性や、理由をしつこく聞いてきて、彼らが納得しないと何もしない。という気がします。厳格な(様に見える)規格を作りそれを守っているから品質が高いと言い切り、その規格を強制させないと話が始まらないかとも思いました。(気に入らなかったら、カウンターの規格等で対抗せよというスタンス)
どちらにせよ、国内のメーカーも規格化等がめんどくさいので同じ要求となると、仕事がめんどくさいことになるとは思っています。
今後も、いろいろ発信してください。
以下の場所に、例示されており、
ISO 26262:2018 Part 10 11.3 An example of ASIL decomposition
次のような記述があるので参考にしてください。
"The original requirement A 2 has been replaced by the redundant requirements B 2 and B 4, both of
which comply with the safety goal, and therefore ASIL decomposition can be applied."
つまりASILデコンポジションの必要条件に冗長性があります。
コメントを投稿