前回，ISO26262におけるセーフティケースの特殊な位置づけについて書いてみました．安全性の確保を考える上で，アプローチの違い（プロセス的な定義をするかゴール指向で定義するか）は，きわめて重要です．つい最近（8月1日）に，ISO26262 Part 10の正式版が発行されたので，この正式版にあるセーフティケースを例にとり考えてみたいと思います．
ちなみに，Part 10 はISO26262のガイドラインとしての位置づけです．それ以外は，昨年の11月に正式発行ですから，8ヶ月ほど遅れて発行されたことになります．全体の構成はかなり変わっているのですが，セーフティケースの記述に関してはドラフト（DIS版）からあまり変わっていません（5.3 「セーフティケースを理解する」）．記述量は減っていて，約2頁ほどの記述です．これまでは，セーフティケースの一般的な説明となっていたのが，規格中の文章ということで，整合性をとるための変更が主たる目的でしょうか．ずいぶんすっきりとした文章に変わったのですが，その分，無味乾燥化しています．もちろん，私の主観です．ただ，私のそして誰かの主観は大事で，それがなくては，あるいはそれを知ることなしに，理解はできないだろうと思います．
***
ここではドラフト版との違いを見ることにします．
(1) セーフティケースの説明図
単純なところでは，セーフティケースを示す図の要素の名称が変わっています（図6）．以前は，Kellyさんの学位論文にあるものをそのまま使っていたのですが，今回，ISO26262の用語に合わせて変えています．引用図を説明なしに改変するのもどうかと思うのですが，それ以前に，単独でセーフティケースの説明にこの図を使用することはあまり見通しが良くないのではと思っています．
(2) セーフティケースの全体での位置づけ
セーフティケースをISO26262の主流のプロセス的定義の中に取り込む努力の一つとして，「セーフティケースの初期のバージョンは，安全計画の一部に含まれる」という記述があります（5.3.2 注記）．これは新たに追加された部分で，より積極的にセーフティケースについて記述しているということだと思います．ただ，もう一歩だと思うのは，セーフティケースは，安全計画とは原則区別されているので（Part2 6.5.1と6.5.3），単なる参照だけで良かったかもしれません．もちろん，この注記で大事なのは，漸次的に（incremental）セーフティケースは作られるという部分になります．それぞれのライフサイクルの段階で，証拠と共に作成されるというのが，一番重要な部分で，それぞれが（中間バージョンなどではない）完成されたものとなります．
(3) 確認レビュー(*)
最後に，新たに追加された部分が，最後から2つ目のパラグラフです．パラグラフといっても一行しかありませんが，「セーフティケースは，ISO26262-2:2011,6.4.7で規定されている確認レビュー（confirmation review）を前提としている」．ここでの確認レビューというのは，「必要な独立性レベルを持つレビューアによって，成果物が，ISO26262へ適合していることを確認することと」なっています（Part1 1.18）．また，独立の程度は別途規定されています．さて，この確認がどうして必要になるのでしょうか．次では，この点を中心に考えてみます．
(*) confirmation review に関する合意のとれた訳語はないと思います．ここでは，単に確認レビューとしておきます
***
究極的に，安全というのは信じ・納得することでしかありません．（包丁の例を持ち出すまでもなく）あるシステムが文脈を無視したところで安全といえるはずはありません．それは，システムとは社会の中に埋め込まれた存在として考えれば，とうぜんのことです．だとすると，ソフトウェアはよくハードウェアと違って確率的に扱えないという例外的な扱いをしますが，それは逆で，確率的に扱えるものの方が，この世においては希少なのだろうと思います．
セーフティケースは，安全ゴールと証拠関係における一つの視点を提供します．そこには，立証というかたちで，作成者の主観が投影されています．それはあくまで主観に過ぎないということです．立場が変われば，立証は成立しなくなります．従って，この主観を確認するということが必要になります．
セーフティケースの意味は，それが正しい安全ゴールと証拠との関係を示していることにあるのではありません．立証を通じて，どうしてその関係でよいと考えたのかという主観を明示することのみにあります．その論理の道筋がなければ，だれも良否を判定できないのです．あくまで判断の材料を提示しているに過ぎず，それ自身が安全を示しているわけではありません．
***
このことは，多くのプロセス的なアプローチに通じてもいえます．何かのタスクに対してレビューをしましょうという定義は，何もいっていないに等しいのです．如何なるレビューを実行することで，タスクの成果物を保証するということが如何に可能かを説明しない限り，そのプロセスの良否を評価することはできないということになります．
ちなみに，26262のドラフト版は，セーフティケースのもつ主観性を強調しています．それが正式版ではなくなっています．これによって，文章自体はすっきりとしました．しかし，ISO26262で主となっているプロセス的なアプローチと，セーフティケースの距離は遠ざかったかもしれません．
(nil)
今日は，東京も久しぶりの雪です（この文章も久しぶりです）．雪国に育った私にとっては，とてもほっとする一日になりました．
今回は，セーフティケースと 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）