ハザードを見つけるという点で，ソフトウェアはなかなかやっかいなものです．
他の分野には，実績ある手法を見つけることができます．例えば，FMEA（Failure Mode and Effects Analysis）がそうです．ボトムアップの手法で，構成部品の故障モードを最初に考えます．各故障モードが全体に対してどのような影響を及ぼすかを調べることで，ハザードとします．FMEAのポイントは，その名が示す通り，故障モードにあるのではと思います．例えば，機械であれば，摩耗／振動／溶接不良といった一般的な故障モードを考えることができます．これらを過去の経験から十分にリストアップできれば，網羅性を担保することができます．安全性は，個々の機能の十全性ではなくて，如何に危険源であるハザードを見つけるかに掛かっていますから，この網羅性が大事と云うことになります．
一方で，ソフトウェアは，（それ自体）物理法則に従うわけではありませんから，この故障モードを網羅的に選びだすことは，簡単にできそうにありません．
もちろん，できなくても構わないと考えることもできます．ソフトウェア自身が暴走したとしても（物理的に存在しているわけではないが故にそれ自身は）痛くはないので良いと考えることもできます．防御は，あくまで機械的／電気的に担保できれば良いと考えることもできます．しかし，システムの経済性やシステムに対して優雅なふるまいを期待するとなると，やはり考えなくてはいけなくなります．
ではどうするかです．もちろん，（消極的な解決策として）がんばって故障モードを列挙するという方法があります．機械とか電気とかに限定されない一般的な故障モードを考えます．例えば，「設計通り値が入力されない」といった一般的なモードを考える方法です．そういったものをひたすら列挙しようということは不可能ではありませんが，なかなか網羅性を主張するまでいかないだろうと思います．
他の方法で有力なものにHAZOP（Hazard and Operability Studie）があります．ボトムアップのFMEAやトップダウンのFTA（Fault Tree Analysis）の中間に位置するようなアプローチになります．網羅性は，時空間上のキーワードである「数が多い／少ない」，「時間が早い／遅い」というガイドワードと呼ばれるものによって担保します．ただ，今度は逆に抽象的故に，網羅性は担保されたとしても，そのままソフトウェアに適用するのはやはり難しいかと思います．
***
ここのところ，HAZOPを利用したソフトウェアのハザード分析ということを考えています．基本になるのは，ハードの人達が例えばFMEA解析に図面を使用するように，ソフトウェアの我々は（例えばUMLといった）設計図を使うという方法です．単純な操作としてハザード分析が（少なくとも）単なるHAZOPよりは簡単になります．空間上のガイドワードはER図やクラス図に適用でき，時間上のガイドワードは，有限状態機械図に適用することになります．すなわち，分析・設計されたものに対して，網羅的なガイドワードを適用する，これによってハザード分析ができるというアイデアです．これにより，ハードウェアにおけるFMEAと同じくらい，ハザードを見つける容易な手立てを手に入れることができるようになります．
***
しかしそれでもなお，まだ問題が残ります．実際にやってみると分かるのですが，上記においてもまだガイドワードからハザードを見つけ出すというのは，やはり難しいのです．そして，この難しさは，網羅性と云うよりハザードを見つけ出すということそのものにあります．ガイドワードに従って，例えば属性を操作する．その時に何がおきるかを考えると云うことは，どうしても思考の跳躍を必要とします．即ち，創造性を必要とする作業だということです．このことについては機会があればまた書いてみたいと思います．
（nil）
今週はデンマークのロスキレで開かれていた EuroSPI（Software Process Improvement & Inovation）2011 に出席していました．xDTSの新しい版のベースになっている Glimmering Interface 概念の発表が目的でした．
ロスキレはコペンハーゲンからは列車で20分ほどの郊外ですが，かつてはデンマーク王国の首都が置かれていた由緒正しい町です．この会議では，プロセスにまつわる様々な話題があり，たぶん他にはない会議になっていると思います（昼食の時に，プロセスの会議は日本にもあるだろうに，どうして来るのかと聞かれました．ヨーロッパのSPIの会議ですから，不思議で仕方がないのでしょう．いろいろ話したのですが，ヨーロッパでも変わった会議として認識されているとのことでしたが）．
初日は，機能安全のワークショップに参加しました．興味深い話題が沢山あり，いろんなことを考えさせられました．
さて，その中で一瞬だけ26262のItemは得体が知れないという話になりました．得体の知れなさには，共感するので，少し考えてみたいと思います．
まずは，DISにおける定義です（ISO/DIS 26262-1）．
1.69 item
system or array of systems or a function to which ISO 26262 is applied
システムないしはシステムの集合体ないしは機能であり，26262が適用されるもの
ガイドラインを見ると，図にして示されます（8-4.2 Item, system, element, component, hardware part, and software unit）
ER風の図を見ると，上位にシステムがあって（これは入れ子でも可），その下位にコンポーネントがある（これも入れ子可能），更に，それは部品／ユニットに分割される．アイテムに対する下位概念は，合わせてエレメントと呼ばれ，規格中では，アイテムとエレメントが対置されています．分かりづらいのですが，アイテムがシステムの集合とすれば，エレメントはそれ以下ですから，システムやコンポーネント及び部品／ユニットを含むということになります．もし，アイテムが単一のシステムとすれば，エレメントは，それ以下のコンポーネントや部品／ユニットということになります．丁寧に説明すればするほどアイテムが分かりづらくなります．とりあえず，横においておくという手もあるのですが，例えば，ASILはアイテム毎に振ることになるので，適当にお茶を濁すというわけにはいきません．
先の定義は，少し説明不足に思います．もうすぐ正式発行なので，改善されていることを期待して，少し昔の記憶を辿ってみることにします．
***
ソフトウェアのライフサイクルやプロセスを，私は前職でMIL-std-1679A（の日本語訳）で初めて学びました．まだ，DOD規格にあがっていない米海軍の規格だった頃のものです．おそろしいもので，私自身はこの規格の刷り込みが入っています．そうはいっても，この規格は，いまではすっかり obsolete の規格で，その後 DOD-std-2167Aに置き換わります（ちなみに，この規格も現役ではなく別の規格に更に置き換わっています）．1679Aはとても分かりやすかったのですが，2167Aに置き換わった時に，少しうろたえました．それまでになかった（ソフトウェアに限っても）CSCIやCSCという新しい鍵となる概念がでてきました．前者は，Computer Software Configuration Item，後者は，Computer Software Component です．CSCIは，CSCに分割されます．機制としては，アイテムが上位概念で，コンポーネントはそれを分割した単位になります．最初に2167Aに移行したときのわかりにくさを後で考えると，全体が構成管理概念に紐付いていることだと思います．CSCIを日本語に訳すと，コンピューターソフトウェア構成品目ですから，構成管理概念がベースだと思えば，きわめて分かりやすい単位になります．いわゆる構成管理表に記載される項目ということですから．何をCSCIとするかも，2167Aが米軍の調達基準である以上，契約者同士の合意の上で定まるとすることができます．その意味では，明瞭な基準となっているように思います．
一方で，26262はスタートラインとしては不特定多数の顧客になるので（以降では，OEM-Supplier関係があるにしても），もう少し厳密な定義が必要になるのではと思います．
***
さて，デンマークといえば，LEGOが有名です．このように相互に依存性のないビルディングブロックからソフトウェアが構成されているとすれば，きっと上記で考えたような悩みは生まれないという気がします．
（nil）
数学セミナーの7月号をつらつら読んでいるとペアノの紹介のところで，有名な宵の明星と明けの明星の話がありました．これは，自同律の不快で見たような話です．宵の明星と明けの明星は共に金星なので，これは，a = a とすべきか或いは a = b とすべきか．フレーゲはこれを「意味と意義」の使い分けとします．有名なフレーゲのこの論文の最後は次のように書かれています．
「a = b」において表現されている思想も「a = a」で表現されている思想とは異なる．つまり，この場合には，二つの文が同じ認識上の価値を持つことにはならない（坂本百大編 現代哲学基本論文集）
意義というのは文から読み手が受ける影響なので，a = b には意義がある．意味は真理に関わっていて，そこでは a = a である．両方とも金星なので．このように意義と意味を明確にし，真理に近づくべきということになります．
数学セミナーで私が面白かったのは，次の部分です．
彼の議論は評判が悪く，ペアノはフレーゲに，「私の記号法であなたの仕事を書いてみてはどうか」と勧め，フレーゲがその勧めに従っていたならば，学会から無視されることもなかったのではと惜しまれる．
さもありなん．数学と哲学の違いになるでしょうか．ちなみに，私はフレーゲ派です．
***
さて，ISO/DIS26262には，confidenceという単語がでてきます．Part毎に見てみると次のようになります（括弧内が使用回数）．
part 1 (1)
part 2 (1)
part 3 (2)
part 4 (3)
part 5 (4)
part 6 (1)
part 7 (1)
part 8 (26)
part9 (1)
顕著に多い Part. 8 は支援プロセスに関する規定で，この中でもっとも典型的な例といえば，TCL（Tool Confidence Level）でしょうか．TCLはASILと同様に4段階定められていて機能安全確保のためにツールが満足すべき規定となっています．なぜ，confidence なのでしょう．Oxford英語辞典で引いてみると第一義は次になります．
The mental attitude of trusting in or relying on a person or thing; firm trust, reliance, faith （人やものを信用したり頼ったりするする*心理的*傾向）
ふーむ．心理的というのは，余りに心許ない気がします．SILが Integrity（完全性）という強い言葉を使っているのと比較すると余計そのように思います．
ツールは，それ自身がシステムの一部として実行したり，勝手にシステムを作ったりするわけではない，あくまで間接的にシステムと関わるからということなのかもしれません．
一方で，Kellyさんたちが，GSNに Confidence の概念を持ち込もうとしているのをつらつら考えるに，26262に見られるように，直接は integrity で，間接（支援）は confidenceというのは，素朴すぎる区分のようにも思います．意義と意味ではないのですが，真理（そこに到達することはないのですが）と，納得としての意義は両方必要に思います．
***
さて，今回のタイトルは，きわめて単純な連想です．おわかりになったでしょうか．Confidence -> LA Confidential -> Hush Hush です．J. Ellroy は私の好きな作家の一人で，彼の一連の代表作にでてくる雑誌名がこのHush Hush です．ここでの Confidence は，内緒の意味ですね．MCL (Magazine Confidence Lelvel)があれば，4 でしょうか．
(nil)
