2011-12-10

ISO 26262との向き合い方 (4) 用語の定義からのトピックス

ISO 26262-1:2011 Part 1: Vocabulary を邦訳しようと思ったら用語が142もあって、さすがに一晩や二晩でできる分量ではないことが分かった。用語の定義の邦訳(全体)については正月明けを目標にリリースを目指したいと思っている。

ちなみにVocabularyは用語とか用語集と訳した方が正確かもしれないが、用語の内容を正確に理解することが規格解釈の重要なポイントであることを強調したいためこのブログサイトでは『用語の定義』とした。

用語の定義の翻訳作業をしていてつくづく思ったのが、英語を日本語にすると原文のニュアンスが伝わりにくくなるということだ。例えば、safety architecture を安全構造とか安全方式と訳してしまうと、ソフトウェアには関係ないような印象を与えてしまう。safety validation も安全妥当性確認としてしまうのはイマイチだと感じる。よって今回は、それらカタカナで示すことでニュアンスが伝わりそうな用語はそのまま、セーフティアーキテクチャやセーフティバリデーションと書くようにした。ただし、safety measure (セーフティメジャー)のようなカタカナにすると意味が認識しにくくなる言葉は、「安全対策」と日本語にするようにした。(セーフティ対策は語呂がよくないので安全対策とした) 英語のままにしておくか、日本語にするかはこの規格を適用するエンジニアにとってどちらの方が規格要求を正しく理解できるかと考えながら振り分けた。

さて、ISO 26262 の142の用語を眺めてみると、次の3つのグループに分かれることが分かる。
  1. 安全工学、品質工学、規格適合に関係することば
  2. ソフトウェア品質工学に関係することば
  3. 自動車ドメイン特有のことばまたはISO 26262 特有のことば
例えば、1の安全工学、品質工学、規格適合のことばとしては、assessment:アセスメント、audit:オーディット、harm:危害、hazard:ハザード、failure:故障、failure mode:故障モード、fault:欠陥、residual risk:残留リスク safety case:セーフティケース、safety measure:安全対策 などが、

2 のソフトウェア品質工学に関係することばとしては、statement coverage:ステートメントカバレッジ、branch coverage:分岐カバレッジ、verification:検証、walk-through:ウォークスルー、random hardware failure:ランダムハードウェア故障、systematic failure:決定論的故障、software unit:ソフトウェアユニット、software component:ソフトウェアコンポーネント などが、

3 の自動車ドメイン特有のことばまたはISO 26262 特有のことばとしては、Automotive Safety Integrity Level:ASIL, ASIL decomposition:ASILデコンボジション、special-purpose vehicle:特別目的車両、single-point failure:シングルポイント故障、dual-point failure:デュアルポイント故障

などがある。この規格には3つの分野のことばが多く使われていることから ISO 26262 全体を理解するには3つの分野を総合的に理解していないとダメだということが推察される。このことは今後の ISO 26262 を適合する現場のエンジニアにとって悩ましい問題になると考えている。

それはどういうことかというと、1. 安全工学、品質工学、規格適合 に関する知識は規格適合会社が得意とすることだが、彼らはソフトウェア品質工学や自動車ドメイン特有の知識にはうとい。2. ソフトウェア工学に関する知識は、ソフトウェア系品質コンサルタントが得意な分野であるが、彼らは安全工学、規格適合、自動車特有のドメインの知識、経験があまりない。また、今回 ISO 26262 のために新しく導入された概念、ASILや ASILデコンポジションなどの概念は、ISO 26262 の規格制定に関わった人たちが詳しい。

そこを踏まえたうえで、自動車ドメインの技術者は、自動車ドメインに特化した部分、ISO 26262で初めて導入された概念は自分たちで理解を進めるとして、安全工学、品質工学、規格適合、ソフトウェア品質工学に関する知識に関しては、外部から指導を受ける必要性はあると感じる。このとき、お勧めしたいのは、急に ISO 26262 の適合を看板に掲げたところよりも、それぞれの分野の知識や方法論を昔から、ひたむきに、純粋に教えているところに教えを請うということだ。例えば、安全工学、ソフトウェア品質工学なら日科技連などがお勧めだ。例えば、FMEAやFTAを含む品質管理セミナー、ソフトウェア品質マネジメントセミナーは何十年も前から開催している。

このブログを利用するのも一つの手だが、エンジニアや品質保証担当はこれからたくさん勉強しないといけないということは間違いない。自らの勉強する努力なしに、今後複雑化する安全機能をユーザーに安心して使ってもらうことはできない。現場のたたき上げでここまでやってきたという自負があってもダメだ。その自負だけでは未来の自動車システムの実質的な安全性を確保できないし、諸外国に安全性を証明することができない。

諸外国への安全性の証明という観点から考えると、ISO 26262 を日本語だけで理解してしまうのは危険であると感じる。英語の規格を日本語に訳して、安全性の説明を日本語でして英語の翻訳して外国人に伝えると、二回変換があるので真意が正しく伝わらないかもしれない。よって、自分の仕事に関係する規格原文の箇所は必ず読んでおく必要がある。

【ランダム故障と決定論的故障の違い】

用語の定義は今後、少しずつ紹介していくとして、今回は random hardware failure:ランダムハードウェア故障と systematic failure:決定論的故障 について説明しようと思う。
1.92
random hardware failure
failure (1.39) that can occur unpredictably during the lifetime of a hardware element (1.32) and that follows a probability distribution
NOTE Random hardware failure rates (1.41) can be predicted with reasonable accuracy.
※(1.39)といった記述はその言葉の定義が ISO 26262-1:2011 Part 1: Vocabulary の別の項にあるということ。

ランダムハードウェア故障
邦訳:確率分布に従ったハードウェアエレメントのライフタイム中に予知できずに発生する故障
NOTE:ランダムハードウェア故障率は妥当な正確性で予測することができる。

ランダムハードウェア故障は、後述する決定論的故障の対照的な位置づけにある。ようするにある一定の故障率、歩留まりを持ったハードウェア部品の故障のことで、例えば1万個に3個の確率で故障するとか、10万時間使い続けると故障するといったもの。確率論的に故障を予測できるため、対策も立てやすい。
1.130
systematic failure 
failure (1.39), related in a deterministic way to a certain cause, that can only be eliminated by a change of the design or of the manufacturing process, operational procedures, documentation or other relevant factors
決定論的故障
邦訳:設計、開発プロセス、運用手順、ドキュメント、その他の関連する要因の変更{改善}によってのみ取り除くことができる決定論的な故障
1.131
systematic fault 
fault (1.42) whose failure (1.39) is manifested in a deterministic way that can only be prevented by applying process or design measures
決定論的欠陥
邦訳:プロセスまたは設計対策によってのみ取り除くことができる決定論的に現れる故障の原因となる欠陥

※failure と fault は用語の定義の中で何回もでてくる。 fault:欠陥 が原因となって failure:故障が発生すると考えるとよいだろう。

さて、systematic failure/fault をシステマテック故障/欠陥とせずに、あえて決定論的故障/欠陥とした理由は、どっちにしてもその言葉だけではわかりにくい概念であるため、よりわかりにくい日本語の方にして、「この言葉はなんだろう」という疑問を常に持って欲しいと思ったからである。

「設計、開発プロセス、運用手順、ドキュメント、その他の関連する要因の変更{改善}によってのみ取り除くことができる決定論的な故障」という説明でsystematic failure:決定論的故障を理解できる者は何人いるだろうか。

簡単にいってしまえばソフトウェアのバグが systematic fault で、ソフトウェアのバグ、欠陥によって起こる故障、不具合が systematic failure である。(ハードウェアによる決定論的故障もまったくないとはいえないので、ソフトウェアによる決定論的故障は systematic software fault と言うこともある)

ソフトウェアのバグによって起こる不具合を考えてみれば分かるが、ランダムハードウェア故障のようにある一定の確率で起こるようなものではない。例えばめったに通らないプログラムのある箇所を通ったときにのみ発生する不具合だったとする。そして、それが普段あまり行わない複雑なオペレーションの組み合わせによって発生する不具合だったとする。

これはまれにしか行わないオペレーションなのだから、確率で表すことができるだろうか。人間工学的にはできるかもしれない。しかし、安全保障という観点から考えてみて欲しい。ランダムハードウェア故障はある一定の確率で起きるが、今起きるかどうかと言えばほとんどの場合起きない。ユーザーも「めったに起きないがある確率で発生する故障」という状態に理解を示してくれる。

ところが、めったに通らないパスに存在するバグが原因の不具合はどんなに複雑なオペレーションであっても、そのオペレーションを実施すると確実に発生する。だからこそ、systematic:決定論的ということばが使われる。しかし、この不具合は修正したソフトウェアと入れ替えると直ってしまう。被害の大きさにもよるが、直せば直る不具合を放置することをユーザーは許してくれない。

これが、systematic failure/fault:決定論的故障/欠陥 の正体だ。ソフトウェア品質工学の世界では長年、決定論的故障/欠陥はレビューやテスト、検証、妥当性確認を含む設計プロセスや設計対策によってのみ防止できると言われ続けてきた。日本人がアウトプットする商品の品質が高い理由はプロセスや設計対策だけが要因ではないという主張はソフトウェア品質論の世界では証明できていない。(詳しくは 『ソフトウェア品質論の歴史的推移』を参照のこと)

さて、ソフトウェアの不具合に起因する危険からユーザーを守ることは、エンジニアや品質保証担当と決定論的故障/欠陥との戦いであると言える。

しかし、ソフトウェアエンジニアは数百万行もあるソースコードのすべてのパスをテストするような完璧なテストを実施することは不可能だし、不具合をたたき出すテストだけで、何も問題はないという安心を得ることなどできるないことはよく分かっている。ソフトウェアは簡単に変更することができるし、たった一行、たった一ビット変えたことでシステムの動作が変わることだってあるし、コンパイラやMAT LAB などのモデルベース設計ツールによりはき出すされたコードに変換ミスがまったくないなどと言える訳がないことは分かっている。

だからといって、ISO 26262 の適用の全体工数、全体費用に対して、ツールやコンパイラの検証に30%以上の工数や費用を割くのはナンセンスだと思う。(あくまでも個人的な見解)

ユーザーの安全確保を第一に考えれば、まずやるべきことはシステムを安全に関わる大事な部分とそうでない部分に分けて印を付けることだ。それが ASIL であり、コンポーネントも分解すれば危ない部分とそれほどでもない部分にわけることができるかもしれない、それが ASILデコンボジションだ。

システムの中の大事な部分、安全を担っている部分をできるだけを機能ごとに凝集し、他のコンポーネントとの結合を疎にして、その大事なコンポーネントに関わる設計や検証に工数や費用を投入するのがよい。そのためにはシステム全体の安全に対する分析を最初に進める必要がある。ISO 26262 の Part で言えば、2, 3, 4, 9 にあたる。

ただし、ハイブリッド車のブレーキシステムのように、多様な安全要求が求められる市場環境を見れば安全機能を一つのコンポーネントだけに集約できないことも予想される。

そのときに重要なのが安全を実現しているアーキテクチャを可視化し、それがシステムの中で有効に働いていて、かつ、決定論的欠陥が含まれていない、またはリスクが受容できていることを明確にすることが大事なのだ。

※用語の定義の邦訳にあたり、ISO 26262 の全体像を説明する図も一部ことばを見直して Ver 1.01 としたので利用して欲しい。(ISO 26262 全体構造図 開くためのパスワードは"guild26262")







ISO 26262 に関するアンケート結果(投票総数 47, 複数選択可)

44 (93%)  もっとこの規格に関する記事を書いて欲しい。
 8 (17%)  どこから手を付ければよいか分からない。  
 5 (10%)  技術者がやるべきことが分かりません。
 5 (10%)  お金や工数がどれくらいかかるか知りたい。
1 ( 2%) 売り込みが多くて困っています。  1 ( 2%)  特に興味ありません。       
 0 ( 0%)  この話題はもういい。

投票ありがとうございました。この結果を記事を書き続けるモチベーションにしたいと思います。

0 件のコメント: