今日は，東京も久しぶりの雪です（この文章も久しぶりです）．雪国に育った私にとっては，とてもほっとする一日になりました．
今回は，セーフティケースと ISO26262 の関係についてちょっと異なった側面から書いてみます．セーフティケースは英国において長年使用されてきました．また，英国の多くの規格（軍事・原子力発電所・航空）はセーフティケースを重視しています．ここでは，セーフティケース自身が，安全性を担保するための一つの文書体系となります．また，主として用いられている分野は，前述のように軍事・原発・航空です．調達（規制）する側と製造する側が明確に分かれている分野となります（どういう仕様とするかはユーザが規定するといっても良いかもしれません．自動車のような製品とは異なります）．セーフティケースは，内部で安全を確保するためにも用いられますが，第一義的には，外部（調達者・或いは規制当局）に対して安全であることを示すものという位置づけになります．
***
このことは，別の違いとも関係してきます．ISO26262では，従来のライフサイクルにあるように，安全に関する概念ー要求ー設計といったつながりを重視します．段階的に詳細化を行うことで，安全性を担保するという考え方は，ソフトウェア開発の伝統的な考え方と同様です（ウォータフォールモデル的と呼んでもよいかもしれません．価値判断は別としてソフトウェアの貢献だろうと思います）．ここでのセーフティケースの位置づけは，作業成果物を紐付け説明するという，どちらかといえば補助的なものとなります．安全の担保は，既に段階的な詳細化において，実施されていると考えて良いと思います．
一方で，伝統的なセーフティケースのアプローチは，ゴール指向の立場をとり，最初の主張（ゴール）に対して，如何に立証するかという点を先行して考え，分割していきます．ここでは，どう外部に説明するかということが重要です．同じようにトップダウンではあるのですが，安全性がどう担保されているかの証明（立証）を第一義とする機制になっています．この点で，ISO 26262 が，SLCPでいうタスクレベルのプロセスも成果物も定めている方式に対して，（パターンはあったとしても自由度は高く）思想的には異なっているといえると思います．
乱暴なくくりですが，前者はいかにも成文法のドイツ的ですし，セーフティケースを重視する後者は，伝統的に不文法主義のイギリス的なのかもしれません．
***
さて，ここからは宣伝です．今日弊社では，セーフティケースのための GSN エディタをリリースしました．また，今週の金曜日に SEA-SPIN のミーティングでセーフティケースをテーマにみなさんと議論する予定になっています．よろしければ，ご参加ください．
（nil）
むかし，プログラムの構造を示すために，幾つかの表記法がありました．典型的には流れ図なのですが，それ以外にもNSチャートやHCPなど沢山の表記法がありました．私が所属していた会社ではHIPOといわれる表記法を用いていました．90年代の初め頃は，まだ手書きで書くケースも多く，テンプレートを大事に使っていました．
HIPOは，その名の通り「入力ー処理ー出力」というかたちでプログラムの構造を記載します．記述全体が階層構造をとるので，hierarchy plus input-process-outputとなり，頭文字をとってHIPOです．入力と出力で処理を押さえるのは分かりやすいので，プログラム記述以外にも，ソフトウェアプロセスの記述をするときにも良く用いられています．入出力が文書で，処理の部分が実際の開発活動になります．
さて，今回は，ISO 26262-6 を成果物から見てみたいと思います．26262では，ライフサイクルを構成する要素として，フェーズという云い方をしています．フェーズを更に分割したものがサブフェーズになります．ソフトウェアライフサイクルプロセスの規格であるISO/IEC 12207(Systems and software engineering – Software life cycle processes)では，プロセス粒度に従って，プロセス／アクティビティ／タスクという使い分けをします．12207のアクティビティはプロセス粒度としては26262のサブフェーズに近く，タスクがそれより細かな単位となります．ちなみに，26262では，アクティビティはフェーズを横断する活動に対して名付けています．安全アクティビティ（safety activity）がその例です．
***
各サブフェーズと成果物の関係を記述してみました（成果物一覧は，Annex A にもあります．ただ，このあとのハードウェアソフトウェアインターフェイス仕様の他に，おそらくtypeと思われる間違いがあります．統合テスト報告の参照番号です）．
ソフトウェアレベル（Part 6）のサブフェーズ毎に，入力と出力を記載しています．入力側で網掛けになっている部分は，システムレベル（Part 4）から来ているものです．このほかに並行して開発されるハードウェアレベルからの情報もあるのですが，ここでは，prerequisites 即ち，先行するフェーズで必ず作成されている成果物に限定しています．出力側の網掛けの部分は，ソフトウェア開発レベルの出力となるものです．成果物が沢山あるようですが，多くは各サブフェーズで洗練・詳細化（refine）されて，後続のサブフェーズに受け渡されています．ソフトウェアレベルで新規に作成されるものはプログラムを含めて12種類でしょうか．
かなり複雑なのですが，幾つかのタイプがあることが見て取れます．
(1) ソフトウェア開発レベル外部から来て更新されるもの
安全計画は，最初のサブフェーズ（6-5）とソフトウェアアーキテクチャ設計（6-7）で更新され，全てのサブフェーズで参照されます．少し奇妙なのは，ハードウェアーソフトウェアインターフェイス仕様で，安全要求の仕様（6-6）で更新されるのですが，次のアーキテクチャ設計（6-7）では，そちらを参照せずに更新前のものを参照しています．そのほかでは，後続するサブフェーズでは，更新されたものを参照しているにもかかわらずです．サブフェーズレベルでの平行性を意図しているようにも思えないので，すこし不思議な規定です（ちなみにDIS版には入っていなくて，FDIS版から6-7に追加されています，Part-5 のハードウェアレベルでは正しいようです）．
(2) ソフトウェアレベルだけで繰り返し更新され，出力されるもの
代表的なのがソフトウェア検証計画です．最初のサブフェーズ（6-5）で作られた後，後続の多くのサブフェーズで更新されます．
フェーズに関連した名称を与えることで，複雑な参照線を避けることができます．例えば，単体テスト（6-9）で作られるのはソフトウェア単体検証仕様書として，統合テストで使用されるのは，ソフトウェア統合検証仕様書である．その上で，別途文書体系を規定する．この方式の方が一般には見通しが良くなると思うのですが，同名の文書を繰り返し更新することで，文書の内部構造を推量させるというポリシーのようです．そのために，一覧表にするとかなり複雑な参照線となっています．前回書いたようにDIA（Development Interface Agreement）によるOEMーサプライヤの切断を考えると，ソフトウェアに関しては，成果物の参照線を多数横断することになるので，その整理が大変だろうと思います．
***
さて，今回は上記に関連する他の論点もしておこうと思います．まず，機能安全が達成されていることを確認するための手段として，セーフティケースがキーになります．そのことは，Part-2 の管理にあります．気づきにくいのですが，セーフティケースは，今回見た成果物をエビデンスとして参照することになります．丁度，フェーズ／サブフェーズをまたいで串刺しにするような形になるのではと思います．もう一つは，上記の様々な成果物と既存成果物との関係です．機能安全に特化した規格で，それによって担保されている安全性を明確化するということですと，分かりやすいのです．しかし，例えば，ソフトウェアアーキテクチャ設計サブフェーズの記述を見ると，非ー機能安全部分の要求についても同一プロセスで扱うとありますので，あくまでこれまでの規定を包含するということなのだろうと思います．A-SPICEで「確証」という話しもそこから来ているのでしょう．この方式だと，容易に破綻しそうな気もします（例えば，上位の概念を考えます．一般の安全性も機能安全の上位概念ですし，Dependabilityは更に広く，ここには安全性の他に機密性といった多くの概念を含みます）．本来は，機能安全を如何に*分離*してモデル化／実現／確認できるか，に特化した方が良いのではと思います．この議論は，先のセーフティケースによる串刺しを含めて，ソフトウェアアーキテクチャ設計を例に，また続けようと思います．
***
さて，HIPOをはじめとするプログラムの構造表現を，何故，余り書かなくなったかです．一番は，そのときに発生する労力の問題かと思います．一度でも書いたことのある人なら分かるのですが，修正にとても弱い．考えながら最初に書くときは良いのですが，なかなか書き直す気になりません．しかし，安全に関するところですと，自動化の助けを借りることで，記載する必要性があるのではと思っています．プロセスのチェックだけでは，安全性を担保するエビデンスとはなりづらいように思います．
（nil）
先日，Science 誌をつらつら眺めていたら，Wrens（ミソサザイ）という小鳥がデュエットするときの神経学的調整機構に関する論文がありました（DOI: 10.1126/science. 1209867 著者による動画はここです．実際にデュエットを聞くことができます）．ミソサザイは，常にあるパターンに従った鳴き方をするのではなく，相手の声に反応して，素早く自分の鳴き方を変える．それによって，デュエットが成立します（勝手に雌雄で歌っているわけではない）．そのためには，一般に鳥が鳴くときに動作するHVCニューロンとは異なる回路，例えばCPG（中心パターン生成器）が関与するのではというのが，論文のテーマになっています．
***
さて，今回は機能安全における成果物のうち文書について考えてみたいと思います．文書というのはこうすれば良いという正解があるわけではなく，あくまで書き手ー読み手間の関係で定まります．技術文書といえどもその構図は変わらないだろうと思います．本当は，黙ってても伝わるというのが良いのでしょうが．
少し前に，文書チェックをお仕事となさっているから正しい技術文書の書き方といったお話しを伺って，幾つか昔のことを思い出しました．文書は，時間的・地理的に離れた人とコミュニケーションする上でソフトウェアの世界でも重要なものです（そもそもプログラムは，ある種の文書です）．最初に，一般的な技術文書が持つべき特性について考えます．IEEE Std 830-1998（ソフトウェア要求に対する推奨される実践，以下IEEE文書）という文書があります．特にSRS（ソフトウェア要求仕様書）を書くときにとても参考になるガイドラインです．ここで，SRSは，次のような特性を持つべきとしています．
- 正確である
- 明白である
- 完全である
- 一貫している
- 重要性，そして/または，安定性に従ってランク付けされている
- 検証可能である
- 修正可能である
- 追跡可能である
このうち，今回は (2) の明白であるというのを取り上げてみることにします．ここでの明白さというのは「記述された要求がたった一つの解釈しか持たない」ということなのですが，様々なコミュニケーション理論が示すように，これは簡単なことではありません．どのように書いたところで，書かれたものの解釈は，多義性から逃れることはできず，多少なりとも保証してくれるとすれば，それはコミュニティ内の約束を前提とするしかありません．先の文書でも次のような注意事項があります．
“…しかしながら，これらのグループは，しばしば同じバックグラウンドを持つというわけではない．従って，同じような流儀でソフトウェア要求について記述しない傾向がある．開発者が要求仕様を変更した時の表現は，ユーザにとっては理解しづらくなる可能性があるという意味で，生産的でない可能性がある．逆も同様にあり得る． “
文書は自然言語／要求仕様言語／表現ツール（図式）を使って記述しますが，先の多義性からは逃れることはできませんし，それぞれ長所・短所を持ちます．従って，「明白に」いうのは，正しい日本語で書くとか，ある特定の手法で書くといったことで，直ちに実現できるわけではありません．
「明白に」を実現するために，唯一の評価軸として採用できるのは，書き手ー読み手間の経済合理性しかないのだろうと思います．誰も読まないと思えば，書かない．チーム内の同じ技術者が読むと思えば，同一の土俵上で，最小限の記載を行う．この合理性を考慮しない技術文書の書き方はおよそ意味がないだろうと思います（もちろん，時間の経った書き手は読み手でもあります）．もちろん，とりあえず作ったソフトウェアが長く使われるのだけれど，文書がなくて困るということも沢山あるだろうと思います．しかし，予知能力が人間に備わっていない以上，そこにはやはり経済合理性を求めるべきだろうと思います．逆に，そういう自体に対処できるソフトウェアであるべきということだろうと思います．およそ，このように合理性を考慮しないとアリバイ的文書だけが存在して，結果的に明白さを著しく損なう気がします．
***
ISO 26262では，機能安全に関する成果物が定められています．そこでの成果物の構造は，とても興味深いのですが，また別の機会に書きたいと思います．ここでは，成果物の持つ特性に対する規定をみたいと思います（ISO 26262-6 6. Specification and management of safety requirements）．安全要求の特性として以下を挙げています．対応とあるのは，先のIEEEの文書で要求している特性の番号です
- a) あいまいさがなく，理解が容易であること 対応：（2）
- b) 原子的であること 対応：?
- c) 内部では一貫性のあること 対応：(4)
- d) 実現可能であること 対応：?
最初の「あいまいさがなく，理解が容易」というのは，必ずしも，「明白である」こととは一致していません．しかし，概ね意図していることは同じと云って良いと思います．読み手側に対する配慮になります．b)の原子的であることというのは，特定のレベルで考えたときにそれ以上分割できないということを示しています．こちらは，要求の記述と云うより，そもそも要求がどのように識別されるかということであり，IEEE文書には含まれていません．c)の一貫性については，IEEE文書の(4)に対応します．この(4)は，内部での一貫性と外部との一貫性の2種類の意味がありますが，26262では，6.4.2で内部の一貫性を，6.4.3で外部との一貫性を要求しています．d)は，安全要求が実現可能であるか否かです．こちらも，成果物の特性と云うよりは，要求の特性だろうと思います．或いは，一般には要求の実現可能性とは，要求と別に議論されるべきで，要求に含むのは違和感があります．書くとすれば，IEEE文書にある(5)のランク付けによる色分けに対応可能かも知れません．総じて，IEEE文書は，SRS文書がどう書かれるべきかということに重点を置いているのに対して，26262では，安全要求はどうあるべきかということ，文書記述を混在させているように見えます．6.4.3の管理をみると，前者に関する内容が主になるので，どういう表現かというよりは，安全要求の論理構造を議論していると考えた方がよさそうです．もちろん，その方が自然な気もしますが，表現に関する規定も含んでいるので分かりづらくなっています（本来，論理構造と表現は不可分です）．
さて，自動車の場合は一般にOEM-サプライヤの境界が存在します．この部分のインターフェイスは26262では，DIA（Development Interface Agreement）でとることになります．もちろん，この3文字で済ませても良いのですけれど，実際にDIAに記述されるべき内容は，ライフサイクル上の位置によって異なることになります．従って，かなり悩ましいことになりそうです．先の書き手ー読み手間の経済合理性を考慮した文書化というのも，OEMーサプライヤのインターフェイス位置によって表現を変える必要がでてきます．部位によって概ねそのインターフェイス位置は，現実的に決まっているとすれば，それに応じて適切な表現レベルを*合理性に基づいて*定めると云うことになるのだろうと思います．
***
ミソサザイのデュエットの話ですが．記事を読んで，少しショックを受けました．デュエットをリードしているのは，必ず雌とのこと．むかし，ペアのダンスをしていたことがあります．そのときに，注意されていたのは，リードするのは男性なのでしっかりしなさいと．陸上のダンスも，氷上のダンスも同じです．しかし，遠い目で，昔を振りかえってみると，決してリードしていたわけではなく，リードしやすいようにリードされていた気がしてきました．すべからくそうなのかもしれません．
(nil)
構成管理をイメージしてみます．各構成品目が複数あり，それらを横に並べます，各品目は，図面でいえばサフィックスが増えていくように，プログラムでは各コンパイル単位のバージョンが増えていくように，速度差はあっても時間軸方向に縦に伸びていくとします．一つの構成・ベースラインはそれらに横串を刺したものとなります．私には，ベースラインは，波のようにイメージできます．
11月の葉山海岸（SPIN世話人会のあとで）
***
ソフトウェアの世界でここ十年ほどでよく使われるるようになった構成管理ということばは，もちろん，Configuration Management の訳語です．別の訳語もあります．形態管理という言葉で，いまでも航空宇宙の分野で良く使われていると思います（私は形態管理という名前で最初に覚えました）．
形態というのは見えるさまで，使用する部品が異なれば見え方にも影響してきます．例えば，自動車の部品表に色を指定することで，形状は全く同じでも識別することが可能な別の車となります．
さて，この形態管理或いは構成管理は，ハードウェアの世界とソフトウェアの場合とで，少し異なっているように思います．今回，その違いを考えてみようと思います．分かりやすくするために，ハードウェアでは＜形態＞という用語を用いて，ソフトウェアでは＜構成＞という言葉を使うことにします．同じものを異なる相でみたいというだけで，基本的には同じものです．特に区別しないで済むところは構成管理とします．
***
ハードウェアの場合は，完成品を頂点として，多数の部品を組み合せることで成立します（自動車の場合は，何万点の部品という云い方がされますが，アッセンブリレベルでの指定が多いので，ある車に関して，実際に部品表に記載される数はそれほど多くはないでしょう．また，概念的には木構造を構成しますが，構成はフラットに表現します）．この組合せにより，一つの＜形態＞が生まれます．
ソフトウェアの場合は，通常は，より細かな単位，例えばコンパイル単位を構成品目とします．”細かな”というのはもちろん相対的な云い方です．ここに，幾つかの特性の違いを見ることができます．例えば，ハードウェアの場合，構成する品目は基本的に図面によって示され，しかるべき手順に則った管理がなされます．図面を書くと上司のチェックを受け，例えば図面室で受理されて初めて品目としての準備ができます．一方で，ソフトウェアの場合，構成品目として一般にコンパイル単位を選択します．この品目は，いわゆるリファクタリングの過程で，品目による構成そのものが変更対象となります．また，そうすることが保守性の観点から推奨されています．従って，ソフトウェアの分野における＜構成＞管理ソフトウェアは，ファイルの分割や併合に対して柔軟に対応可能となっています．ハードウェアの＜形態＞管理にあるように番号を付けて，会社が存続する限り全社共通で管理するという文化になじまないことになります．
***
私が，形態管理という言葉を知ったのは，MIL-std-1679Aという規格です（これは以前にアイテムの回で触れました）．その後継となったDOD-std-2167Aでは，形態管理に関して興味深い使い分けをしていました．2種類の形態管理があります．一つは開発時の管理であり，もう一つは，出荷時の管理ということです．先の二つの訳語を用いると，前者が開発時の＜構成＞管理ですし，後者が出荷時の＜形態＞管理と対応しているということもできます．この区分は形態・構成管理を考える上できわめて重要になります．一つは経時的な問題であり，もう一つは発注者ー受注者問題です．
最初に経時的な問題から考えます．ソフトウェアで一般に使われる構成管理は，主として多人数での開発をサポートするためのものです．一つのコンパイル単位の変更が他に影響を及ぼすことが大きい（これはソフトウェアの特性です），従って，今の＜構成＞状態（ベースライン）を知ることが重要になり，短ければ半日という時間刻みで更新されます．一方で，機械設計などでいう＜形態＞管理の対象となる品目は，設計者の設計結果ですから，その時点では固定したものとして，変更は容易ではありません．設計というプロセスでみると前者がその進行状態の話であり，後者は完了時点での話と云うことになります．
次の，発注者ー受注者問題というのは，如何にその構造に構成管理を写像するかということになります．例えば基本設計が終了した後に，受注者側にその結果を受け渡すとすると，発注者側での＜形態＞は，その時点で確定します．即ち，発注者にとって，その後，如何に細分化されようが，（アッセンブリという）単一の品目として扱うということになります．一方で，受注者側では，単一であるアッセンブリを開始点として，開発時＜構成＞管理及び，発注者に引き渡すための＜形態＞管理を行うということになります．この関係は，受注者が更に発注者でもある場面においても同様に繰り返されます．
このように考えることで，実務における構成管理を比較的考えやすくなります．
***
しかしながら，形態・構成管理を実務に適用しようとする場合に，考慮すべき事柄は上記に限定されるわけではありません．先ほど経時的な問題を考えましたが，より長い時間スパンにおける経時的な変化がその一つです．例えば，モデルチェンジを行うような場合（ソフトウェア的にはバージョンアップでしょうか）にどう対応するかといことがあります．このときは，（形態・構成管理がきちんとなされていると前提で）変更管理の枠組みを適用することで，多くの場合は対処可能です．逆の云い方をすると，製品が変化するのは必然なので，形態・構成管理と変更管理は，本来不可分だということになります．
もう一点は，通時的な変化です．民間におけるシステム製品のように，多くの変異（Variation）を持つ場合の効率良い形態・構成管理の方法を考慮しないといけないということです（2167では軍用の二者関契約ですので，変異は余り大きな問題とはなりません）．先に開発時と出荷時を分けましたが，ここでもその区分は有効になります．例えば，パラメータによってふるまいを変更するということを，変異への対応手段として良く行いますが，この場合は，パラメータの生成器は開発時の構成管理の対象とし，生成されたものが出荷時の構成管理の対象ということになります．
***
さて，ここまでは一般的な構成管理の話になります．機能安全（例えば，つい最近発行された ISO 26262を例にします）についても基本は同じだろうと思います．結局はテストしましょうということで一般のプロセスの枠組みを用います．しかし，このままだと，一般のテストと同じ構図で，不具合の不在証明はできないという議論に辿り着きます．或いは，ここまでの構成の議論で考えた多様な変異に対しては，「全ての構成をテストすることが現実的でない場合，合理的にサブセットを選択しても良い（Part8 9.4.2.2 (c)」ということになっています．しかし，機能安全は最後の砦であり，全ての不具合を防止することを意図しているわけではない．あくまで安全性に関わる機能の故障に特化しているのですから，網羅性が担保されないのだとすると，「合理的構成の組（reasonable subset）」のみを選択してテストということが，該当する場面はないように思います．構成管理というのはきわめて色々議論されて安定した枠組みですが，こと機能安全との関係（更にはSILとの関係）を考えるときに，いろいろと議論すべきことがあるように思います．
(nil)
先日の日曜日，桐生市の無鄰館で，金原寿浩さんの展覧会にでかけてきました．「黒くぬれ！」がテーマで，福島原発事故をモチーフにしていました．墨で書かれた無残な建屋は，リアルな写真で見るよりも，心に残ります．今回は，コンピュータを用いたインスタレーションの可能性について，少し可能性を議論したのですが，お互い得意とする表現分野が異なるので，伝え合うのは難しい．
***
さて，今回は良く云われる「要求」のあいまいさについて考えたいと思います．いつも気になるセリフに「要求」が曖昧だからソフトウェアが作れないというのがあります．多くの場合，これは間違っています．例えば，誰かに竜の絵を描いてもらおうと思います（来年は辰年ですし，二年連続日本シリーズおめでとうというのもありますね）．
”竜の絵を描いて，でも玉は咥えなくてもいいよ"
このとき，飛翔している姿にするか，どこかに潜んでいる姿にするか位は伝えた方がよいかもしれません．しかし，ヒゲの長さは，体長の12.98765%にすることとか，爪の幅は，耳に対して，1/11.23581321345589にしなさいとかはいわない．その数字が竜を表しているわけではないからです．事後的に，細かな数字をいうことは可能でしょう．しかし，それでは要求にならない．
この時点で，先の要求は十分に正確なのです．抽象度に応じて，必要な記述レベルは自ずと定まります．それをムリに記述しなければならないとするのは，誤りです．
では，仕様はどうかという議論もあります．要求は形式化の行為を経て仕様になります．ここでの形式性には，何らかの数学的な背景（例えば集合であったり時間的なふるまい記述）や，物理法則があります．その範囲では，或いはその側面では，無矛盾を担保できます．
ただ，ここにも問題があって，先の12.98765%を仕様として書くことはできますが，機械的に導出することはできません．それが可能なのは，線形で発展するシステムだけで（即ち，既存のささやかな改修），それ以外は別の手段をとる必要があります．形式性の持つ有効性は，あくまで存在するもの或いはコトの*形式上の*記述であること，また，形式性は新たなものを生み出すこととは別のことになります．
***
金原さんとは，先月末に同じ場所で個展を開かれた岸田孝一さんのパーティで知り合いました．岸田さんは画家として表現なさるのですが，「作者の意図を伝えない，そもそも意図はない」ということをおっしゃられます．誤解しているかも知れませんが，意図なき表現は，形式性を排除できる．また，より自由な表現を可能にすると，と理解しています．しかし，それもまたメタには意図だとすると，つくづく表現するということはムヅカシイと思います．
(nil)
レベルというのは，何か競争心を刺激するのか，好む人が多いように思います．レベルを達成しました！どうだ．
レベルというのは，分かりやすい道具なのですが，特定の文脈の中で，細部をきりはがしたものですから，それを目的化するとおかしくなります．つまり，十分に注意して，目的と手段の転倒を避けなければならないということは，良くおわかりのことと思います．
さて，ISO/FDIS 26262 には，ASILと呼ばれるレベルがあります．AからDのレベル分けがなされています．IEC 61508でいうSIL1がASIL Aに，SIL3がASIL Dにほぼ対応しているしているという云い方をされます（中間の数が異なりますが，ここではたいした問題ではありません）．乗用車の場合は，プラントの事故のように多くの人が傷つくということは考えにくいので，SIL4に相当するASILは想定されていません．
さて，今回は，ASILとはいったい何かということをその名前から考えたいと思います．Aは，Automobileの略ですから乗用車ということで済ませてしまいます（車としても良いのですが，26262は3.5トン以下の乗用車をスコープとしていますので，乗用車として先ずは問題ないだろうと思います）．問題は，SIL（Safety Integrity Level）です．こちらは，すでに幾つかの訳語があります．手元の本や類似の日本語規格などを見ると，安全度，安全度水準，安全整合性水準等々があります．
ところで，物象化の相での云い方になりますが，ASIL D は安全度が「高い」と書かれたりします．ASILの場合は，リスク発現時に人間が被る重傷度（Severity），遭遇度（Exposure），回避制御の困難さ（Controllability）で定まり，これらが全て高い時に，ASIL Dが与えられます．つまり，ASIL D というのは十全なる対処が必要とされるシナリオに対応したレベルということになります．いま，このASILを安全度とすると，ASIL D のような厳しい状況は，先の日本語訳を使うと「安全度が高い」という変換になります．このままでは，意味不明なのは，おわかりになるかと思います．身長が高いといえば，それは文字通りなのですが，安全度が高いといっても，それは，大変安全であるということではなくて，安全になるように設計・製造しなさいということを主張しているのです．安全度は逆の意味を与えています．
せっかくですから，もう少しこだわってみます．もともとの英語は，Safety Integrity Level ですから，「安全度」と訳したのでは，”Integrity” が残念なことにムシされてしまっています．「安全度水準」は数は増えているのですが，どうもLevelを丁寧に二度訳しているだけで，”Integrity” はやはりムシされているように思います．「安全整合性水準」は，この例のなかで，唯一 Integrity に取り組んだ訳語になっています．しかし，どうも整合性というのは，ここではピンときません（その訳語が適切な場合もあると思いますが）．
OEDにおいて，Integrity は，次のような明快な意味を与えられています．
The condition of having no part or element taken away or wanting; undivided or unbroken state; material wholeness, completeness, entirety.
即ち，端的には，欠落がないということです．ということでASILに対する私の（長い）訳語案は次になります．
乗用車の安全に関する完全度
私の日本語の語彙が少ないせいで長いのですが，少なくとも安全度とするより正確だろうと思います．ちなみに，フランス語だと以下になります（Part-9の規格のタイトルページから）．”les niveaux d’intégrité de sécurité automobile“．個人的には，先の日本語との相性は良いように思います．
***
さて，結局の所，レベルというのは道具に過ぎないというのは良いと思います．ASILを定めるというのも，分析段階（26262で，3-7）ですから，それは開始点に過ぎません．システム（アイテム）が置かれている位置に対して単に色分けをしてみます位の意味しかないだろうと思います．一方で，61508は少し違っていて，SILのレベルに従った故障率が定まっています．本来設計によって定まる故障率が開始点で決められているということになります．これはALARP原則を前提としているからで，そうではない26262が異なった対応となっているのは（整合性は良いのか，或いはALARP原則については同様に主張しているのではないか，ということをとりあえず等閑に伏すと），少なくともソフトウェアの視点からは適切に思います．
SILの設定は，必ずしも安全確保において必然というわけではありません．道具にすぎないのですから．英軍の規格である 00-56 （Safety Management Requirements for Defence Systems）の現在の版（Issue 4）では，かつて存在したSILは，いまは含まれていません．
（nil）
ALARPという原則があります．安全性に関する用語で，As Low As Reasonably Practical の略になります．リスクを実際的なレベルに低くする．もちろん，それは合理的に説明できるものでなくてはならない（reasonは，OEDによると古いフランス語から来ています，今でも，フランス語で「正しい」というのは，avoir reason で，正しいためには，そうである理屈を持たないといけない．正しいというのは俺は信じているという精神ではなく道理があるということだ，というのは，必ずしも同値ではなく，一つの考え方ということになるかと思います）．ALARPは，良く安全性に関する議論や教科書にでてきますし，IEC61508でも，それなりのページを使って説明しています．しかし，これはISO(/FDIS) 26262のような（乗用車を対象とする）規格だと，相性が悪いことになります．
簡単には，次のようになります．リスクの上限下限を，様々な条件（社会的な許容限度，技術的限度）から定める．リスクの下限は，BSO（Basic Safety Object）と呼ばれる目標値で，これ以下であれば，まあよしとする．リスク上限は，BSL（Basic Safety Level）と呼ばれる許容限度になります．ALARPというのは原則自身やモデルの説明にも使いますが，このBSOとBSLの間を指しています．この間で，できるだけリスクが低くなるように合理的に努力するということとなります．BSO以下はムシしてよいし，BSL以上は，相手に出来ないので，エンジニアリングとしては扱わないということになります．例えば，原発で破壊的な事故が発生し被曝するというリスクに対して，それに対処できないのであれば（BSLを超えるならば），そのBSL以上のリスク度を持つ場所には，人を居住させないようにするといった対処をとるということになります．これはエンジニアリングを超えています．かくのごとく，ALARPはもともと原発や化学プラントのような施設と社会との関わりのなかで考えられてきました．一方で，ISO(/FDIS) 26262が対象とするような乗用車ドメインでは，対象が限定的になります．ある車の障害が，一次的に社会に影響を及ぼすわけでありません．
別の相性の悪さもあります．例えば，ソフトウェアのばあいは，系統的故障となると云われますが，意地悪く云えば，確率的に計算できない故障カテゴリということです．従って，合理的に目標値（BSO）を定めることができません．更には，ソフトウェアに限らなくても，その使われる環境の多様さ，ユーザが訓練されたオペレータではなく一般人であることもまた，目標値の設定を難しくします．
IEC61508に対してC規格であるISO(/FDIS) 26262が，このALARPの扱いに関して，余りに収まりがわるいということは横に置くとして，ここでは別の原則についても考えてみることにします．
GALEと呼ばれる原則があります．Globally At Least Equivalent の略です．フランスにおける安全性の原則で，こちらはGAME（Globalement Au Moins Équivalent）或いは，GAMAB（Globalement Au Moins Aussi Bon）がオリジナルになります．比較対象は，既存のシステムになります．既存のシステムを改良したときに，安全性は良くならなければならない．少なくとも同等でなくてはいけないということになります．
常に自動車を一から設計することはきわめて稀ですから，実務的には，GALEの方が心が落ち着きます．しかし，何をして同等とするかについては，問題は残ったままとなります．
（nil）
昨年パリのChamps-Élyséesで見かけた究極のエコカー?
先週の土日に観音崎で開かれたSEA-SPINの世話人会での議論から，考えたことを少し書いてみます．SEA-SPINというのは，ソフトウェアのプロセスについて関心ある人の集まりです．さて，プロセスの話をしていて，ふと横をみるとプロダクトが伴走してることが多いと感じます．典型的には，「プロセスが良いとプロダクトは良くなるのか?」といった類の質問として現れていると思います．しかし，この問いそのもは間違っているだろうと思います．
ソフトウェアにおいて，プロセスを考えるというのは，一般のものつくりにおけるプロセスとは分けて考えないといけないだろうと思います．ものつくりにおけるプロセスというのは，偏差の制御ですから，その制御を行うための手順を如何に定めるかという点にあります．一方で，ソフトウェアは一品生産ですから，そもそも基準値を引くことが困難であったり，通常は不可能ということになります．もちろん，むりやり基準を作ることもできます．例えば，コード1行を一つのものと考えると，一時間に何個生産できるという基準値を作ることができます．しかし，それが無意味であることは，プログラムを書いている人なら良く分かるだろうと思います．
かくのごとく，ソフトウェアを作るということは，一般の製造とは異なる行為であるにも関わらず，多くのソフトウェアのプロセスの議論は，成功した製造業での流儀を用いようとしています．その帰結はあきらかなように，私には思えます．我々に必要なのは，安易な敷衍ではなく，いくばくかの「合理性」だろうと思います．
***
その例を少し考えてみます．通常のプロセスの意味で，プロセスの規定を担保するのは人間になります．それは，例えば，ソフトウェアの設計品質を，プロセスで規定しようとすると，最終的にはレビューを必要とし，誰もそのレビューが妥当であることを機械的に評価することはできません．通常のプロセスの意味では袋小路に入ります．レビューが妥当かどうかをレビューするといった具合に．大事なのは，レビューをすることではなくて，ある文脈のなかで，そのレビューが妥当であることを合理的に説明できるときに限られます．そうして，初めて，円環を閉じることができます．
プロダクトについては次が参考になります．Lazzaratoさんの無形労働の議論は，ソフトウェアの作るものは有形物としてではなく，社会に働きかける無形のものとして捉えるべき，としています．そこでは，ソフトウェアが単にbit列だから見えないということではなくて，一種の完成系としては存在し得ないということを示しています．
以上の議論から，（製造メタファに由来する）プロセスの議論もプロダクトとしてのソフトウェアの議論も，そもそもがソフトウェア（作り）の本質から遠いところにあるということが分かります．
***
いま，必要なのは単純なプロセス／プロダクトのdichotomyではないだろうと思います．実践的には，よりインスタンスとしてのプロセスに寄り添うことですし，メタには，「合理的なプロセス思考」というものが必要なのだろうと思います．後者に関して云えば，よく成功事例（best practice）の名のもとにインスタンスの共通項を探そうとしますが，それはそこに共通項があるという前提に立てるときにのみ成功します．ソフトウェアプロセスに関しては，多くの場合は，単なる物語の集合としてしか存在できず，物語としては面白くても，それが有益である保証は全くありません．「合理的なプロセス思考」というのは，共通項を探すと云うことではなくて，あるプロセスの構成要素の意味を合理的に考えると云うことです．また，そうすることでのみ，プロセスの議論に意味があるのだろうと思います．
***
さて，今回のタイトルは，（学生時代に私も講義を受けた）廣松渉さんの著作「もの・こと・ことば」から持ってきました．この単行本の帯は，「物的世界像から事的世界観へ！」となっています．このテーゼは廣松さんの著作のあちこちで使われています（その他の本のサブタイトルにも）．今回の内容に即して云うと，物象化的錯視状態にあるものとしてのプロセスを解放する！ということになるでしょうか．
(nil)
ハザードを見つけるという点で，ソフトウェアはなかなかやっかいなものです．
他の分野には，実績ある手法を見つけることができます．例えば，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）
