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 が現実になり、そこから思いもよらない大規模な障害が発生するという事態もありうる。


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

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

ISO 26262との向き合い方 (11) ASILの分解は本当に可能か

日本規格協会から発売された ISO 26262 の英和対訳版が手元に届いた。まず、ISO 26262-9 Automotive Safety Integrity Level(ASIL) - oriented and safety-oriented analyses を読んでいるのだが、何しろ具体例がないからわかりにくい。

さらに混迷を深めているのは 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. 更新プログラム自体に不具合があった。
2. 検証環境下での確認による防止機能が十分に働かなかった。
3. メンテナンス時のバックアップ仕様の変更が重なり、バックアップ・データの消失を含む今回のデータ消失が発生した。

余談だが、こういう事故が発生したとき、事故の原因を間違っても、作業者のケアレスミスなどと結論づけてはいけない。そんな結論なら、必ずまた同じことが起こる。ファーストサーバも再発防止策として当面、緊急性がなければ保守作業をしないと告知しているが、それは恒久対策ではない。

ファーストサーバの中間報告では原因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.

ファーストサーバの事故再発防止策はおそらくこんな感じになるだろう。

1.  検証環境におけるテストの網羅性の向上。（レグレッションテストに対するカバレッジの計測と記録も必要）
2. ファイル削除コマンドといった影響度の高いコマンドをリストアップし、保守ソフトにおいてそれらのコマンドが使用されていればそこだけ抽出し、設計者以外の第三者によるレビューを行う。
3. さらなるフォールト・トレラント (Fault Tolerant)として、保守ソフトを監視するソフトウェアを追加し、危険を察知したら保守ソフトを止める。（システムが複雑になるので、あまりお勧めはしない）

人間が関わっている限りヒューマンエラーはゼロにはならない。逆に言えば、バックアップを取らずに、大事なファイルの取り扱いや、削除コマンドを使うときは慎重に行うといった人間の意識に働きかける対策の方が実質的な効果が高かったりする。日本人の品質を心配する意識の高さが、Made in Japan の品質の高さに貢献していると考えるのはそういう理由からだ。ただ、品質を心配する意識だけで安全を担保できないほどシステムが複雑化しているのも事実だ。

----------
この記事を読まれた方は『要求分析と安全設計との関係（機能安全の致命的な欠陥）』もどうぞ。