先日，高校時代の同級生に八方尾根に連れて行ってもらいました．
白馬から故郷の福井に帰るときには，糸魚川沿いを走ることになります．この途中にフォッサマグナ（正確にはその西縁．東側は柏崎を通る）が可視化されている場所があります．「可視化」というのは，すべからくみたいものを見るということでしかないのですが，それでも何かしらの感慨があります．
ひきつづき，興味深い ISO26262 part 10 についてみてみたいと思います．汎用部品を作るソフトウェアベンダのアプローチについてです．自動車の場合，複数の車種で部品を共通に用います．この共通部品は，特定のOEMに対してとは限らず，複数のOEMで共通に用いる場合もあります．これら部品が，ベンダーで作成される場合（後者の場合は基本的にそうなります），通常のシナリオ通りにはいかなくなくります．
ISO26262では，これまでにもみたようにアイテムが基本単位になります．このアイテムに対してのみASILを考えることができます．一旦，アイテムがきまれば，そこから段階的に詳細化することによって，部品に対する要求が定まります．
しかし，複数のアイテムで共通に使用することを目的としている部品は，この流れに該当しなくなります．多くの部品を使用する自動車においては，一般的に生じることだろうと思います．このための対処の一つが，SEooC（Safety Element out of Context）ということになります．あえて訳すと，”コンテキスト独立の安全エレメント”ということになるでしょうか．ここでのエレメントは，前回の図でアイテムを具現化した部分を指します．コンテキスト独立というのは，アイテムからスタートする通常のISO26262の文脈とは別に存在しているという意味になります．
SEooCに関してDIS版ではもともと２頁ほどしかありません．しかし，正式版ではずいぶんと丁寧に記載されています（10頁）．内容の一番の違いは，そのプロセスの記載でしょうか．DIS版では同一組織での平行プロセスのような記載になっています（図12）．しかし，正式版では（ソフトウェアの場合は図21），UMLでいうスイムレーンを用いた表現になっています．明確にSEooCを作るベンダー側と，利用するOEM側を明確に分離した記載になっています．OEMーベンダの「き裂」の存在を明確にしているとここではいっておきます．
***
さて，スタートは，前提（assumption）の設定になります．これがSEooCの場合は重要です．アイテムの代わりになるものです．
通常の開発であれば，アイテム定義に引き続いて，セーフティゴールの設定やASIL付加を行います（3-7）．しかし，SEooCの場合は，（共通あるいは汎用部品として）複数のまだ見ぬアイテムを対象とするということになります．従って，それら仮想的なアイテムの和集合を考える必要があります．このほかに，他システムとの境界等，必要な情報を付加することで，前提を構成します．前提という言葉は，通常のアイテム定義の中にも出てくるのですが（例えば3-5.4.1），SEooCで使用する場合は，より広い範囲を指しています．
ちなみに，GSNにも前提という概念があります．立証が成立するための「前提」というノードがあります．場合によってはそれ自身も証拠づけられる必要があります．従って，同じ単語なのですが，GSNでは異なった意味となります．GSNでは無条件に設定するものを「前提」とは呼びません．どちらかというと，GSNでは文脈（コンテキスト／Context）の方が近いかと思います．しかし，それだとSEooCと単語としては不整合になります（ooCはコンテキスト独立という意味なので）．
***
もう少し余談を続けます．SEooCに関して具体的な例を用いて説明している論文があります（”Safety Element out of Context – A Practical Approach” DOI: 10.4271/2012-01-0033）．もちろん，正式版の発行前のものですが，SEooCについて，とても分かりやすく記載されています．この中では，SEooCに振るASILのことをプロセスASILと呼んでいます．
この名称は，二重の意味でとてもよい名前付けだと思います．まず，ASILはアイテムに対して最初に付加されるものなので，前提からスタートしているSEooCの場合は，通常のASILと区別する方が適切に思います．また，ASILの違いというのは，ISO26262においては，主としてプロセスの違いであり，そのことを「プロセス」ということばは端的に表現していると思います．
（nil）