risk = nil;

機能安全の世界には，システマテック故障（systematic failure）ということばがあります．このシステマテックの部分は，よく系統的とか決定論的とか訳されます．ここでは，とりあえずシステマテックとカタカナのままにしておきます．

ちなみにシステマテック故障の定義は，次のようになっています（ISO26262-1 1.130）．

ある原因から確定的に生じた故障のこと．次の方法によってのみ取り除くことができる．設計変更，製造工程変更，運用手順変更，文書変更およびその他関連する要素の変更

ことばの定義は難しくて，これだけだと良く分からないのですが，次のように推定することはできます．複数の構成品を組み合わせてできあがった<系>があるとします．<系>をシステムとしても良いのですが，規格の中では別の定義を与えられているので，通常の意味で使用するために，ここでは<系>としておきます．このときに，故障にはおおむね2つのパターンがあります．一つは特定の構成要素がだめだった場合．2つめは，構成要素同士の関係がだめだった場合です．前者は典型的には経時的な劣化に伴うもので，システマテック故障には含まれません（いわゆる確率的故障の範疇）．後者が，システマテック故障の例です．Part-10 には，ワイパーケーブルからの電磁的な干渉により，エンジン制御ユニットが影響を受けるという場合が示されています．何らかの設計変更が必要になります．

この<系>というのは，一般的にはもっと広げて考えることができますし，安全確保のためには重要になります．

***

さて，先日，ある本をパラパラと読んでいました．モンテカルロシミュレーションの本です．（シミュレーションなら当然のことですが）誤差に関する記述があります．誤差には，システマテックと統計的があると．ここにも同様の対比があります(*)．一時期，シミュレーションプログラムを良く書いている時期がありました（今でもときどきは模擬計算しています）．例えば差分で適切な離散化を行わないと，いくらグリッドを細かくしても，計算時間を長く取っても収束しなかったり，誤った計算結果を出すことになります．改善するには，離散化の方法や境界条件を見直すしかないありません．一方，統計的誤差では，例えば標本数を増やすことによって改善できます．パラメータの変更で済んでしまいますが，システマテック誤差の場合は，計算モデルを見直さないといけないというのがポイントになるかと思います．

(*)システマテックに対比する言葉が，「確率的」と「統計的」で異なるのですが，カイ2乗分布に従うとして世界を見ているという意味では同じだろうと思います．

さて，ここでのシステマテックの意味を考えます．シミュレーションの世界では，<現実>を計算モデルに変換して計算します．<現実>に相当する部分は一般に微分・偏微分方程式で表現されます（従って，<現実>とは，あくまで現実がそうであると見なしている物理的モデルに過ぎません）．ここでの誤差は，その<現実>と計算モデルとの間の齟齬の程度ということになります．言い換えれば，計算モデルにより構築したシステムの誤りだともいえるわけです．ですから，システマテック誤差というのは分かりやすい表現になります．また，ここでの<系>は，計算モデル（とそこから導出したプログラム）ということになります．

もう少し範囲を広げてみます．

シリンジの目盛の話です．例えば，シリンジに指示通り薬液を入れる場合，いくら慎重に操作したとして，もしシリンジの目盛が違っていれば，或いは目盛の読み方を勘違いしていれば，常に間違った量を注入することになります．注射というアクションは，シリンジ（のめもり）＋看護師からなる<系>と考える必要があり，もしここに誤りがあるのだとすると，これもシステマテック誤差になります．

システマテック故障の定義にあるとおり，<系>における安全は設計だけの問題ではなく，実装・運用などもその範囲になるということになります．

***

 多くの場合，こういった議論はハードウェア／ソフトウェア分離以前の話だと思うのですが，不思議なことに先の Part 10 にある例（figure 5）を見ると，システマテックソフトウェアにおける障害（Fault）からError（誤り）への遷移例として，無限ループが挙げられています．これもちょっとおもしろい場所です．ソフトウェアの場合，個人的には，障害という状態はなくて，Error から直接にFailureとすべきだろうと思います．これが，個人的に私の一番目の面白いところです（もちろんISO26262に限らない話ですし，通常は気にしなくて済むますが，Part 10 でも念を押されているような気がして少し引っかかります）．2つ目としては，この例がまったくシステマテックになっていないところです．少なくともこれをして，先の用語定義の範疇と思うことは難しい．

では，ソフトウェアはシステマテックなものとして考えられないかというと，そんなことはないのだろうと思います．独立した構成品の集合として構築可能と思います．しかし，この規格では，おおむね何か一つの大きな黒い箱のような扱いがなされます．ソフトウェアの人はもう少し声を上げるべきかもしれません．

***

さて，今回の題は，サン=テグジュペリの「夜間飛行」からとりました．航空郵便の競争が熾烈で，危険な夜間飛行に挑戦する人たちが主人公です．熟練の整備士が長いキャリアの中で初めてミスをします．彼を整備士として首にするか考えるところでの主人公の内語です．堀口大學さんの訳だと次のようになります

（こうしてむげに首にしたのは，あの男ではない，）実は彼を通り抜けてきたその故障なのだ

整備士に責任はないかもしれない．しかし，その故障がその整備士を通じて現れたのなら，もうその人間はその仕事に就くことはできない．一般には，人を含む「整備」という<系>の誤りと見なして，人の責任を問わないというのが一般的かと思います．また，そうすることが建設的だといいます．確かに，そうなのでしょう．

しかし，サン＝テグジュペリ自身がそうだったように，人の生死がかかる場所においては，違うということだろうと思います．責任とは無関係に，二度とその場所にいてはいけない．<系>に対して総合的に誤りを見つけられない人間には，その資格がない．

(nil)

正式版のISO26262 Part 10 を読むと，直接書かれていること以外でいろいと思いを巡らすことができます．読み物としてはとても興味深いものです．

***

以前に「アイテム」について考察しました（不思議なアイテム）．Part 10をもとにちょっと違った側面から考えてみます．下の図をみてください．これは，ドラフト版と正式版にある用語の関係を示している図です（共に p4）．各ノード名称を日本語に変えています．また，色が付いている部分は，私の方で説明用に付加したもので，オリジナルにはありません．

せっかくですから，この２つの図を比較して，作成者の意図を想像してみることにします．共に基本的な構図は同じです（ノード的には「エレメント」が除外されていますが，説明しづらいので外したということでしょう．位置づけ的には変わっていないので，ちょっと複雑ですが表現は可能だろうと思います）．

ドラフト版では，E-R図風だったものが，UML風に変わっています．UML風というのは，基本的にはUML方式の記述だが一部違っている部分があるということです．例えば，点線矢印の部分は，UMLクラス図にはない記述方法です．ISO26262の説明では，実現（realization）を示しているとあります．UMLでも点線で実現を示すことができますが，アローヘッドは白抜き三角です．ただ，別にUMLで書くとは記載していないので，あまりたいした話ではありません．

さて，（規格書の説明によれば）ここでは，「一つのアイテムは，一つないしは複数のシステムによって実現されている」および「一つの機能は，一つないしは複数のシステムによって実現されている」と読むことができます．

即ち，赤い矩形の中の要素である「アイテム」および「機能」は，実現されるべき対象ということなりますから，抽象的なもの，すなわち観念的なものを示しているということができます．一方で，青い矩形の中にある「システム」や「コンポーネント」および「パーツ（ハードウェア）／ユニット（ソフトウェア）」は，（実現された）具体的なモノということになります（コンポーネントに関しては，論理的なまとまりをすることもできるのですが，すくなくともこれがコンポーネントと指し示すことはできるはずです）．

プラトンではないのですが，イデアとしての「アイテム」があって，「システム」以下が具現化される．「機能」というのは，いわばイデアとしての「アイテム」の（複数ある）特徴だということになります．まっさらの状態から開発を進めようとすれば，具体的なモノはないのですから，観念的なところからスタートしないといけないという云い方でもよいかもしれません．

このように「アイテム」は，「システム（或いはシステムの集合）」の（実現という意味で）上位にあたりますから，かなり広い範囲を指し示しています．また，「機能」も，特定の「パーツ／ユニット」といったものの一般的な機能ではなく，「アイテム」の機能ですから，ユーザ視点でのゴールと考えた方が適切です（本来はここに非機能も含まれるはずです）．この新しい図がUML風に表現されていることに敬意を表してUML的解釈をすると，最初のユースケース図において記載される，各ユースケースが，このゴールである「機能」に相当するといえそうです．

従って，普通名詞的に用いてしまいそうな「アイテム」「機能」には十分な注意が必要と云うことになります．日常生活とはかなり違った文脈で定義されているということを理解しておく必要があります．

***

さて，タイトルの「３は３でありながら」は，プラトンのパイドンからとりました．このあと次のように続きます．”（３は３でありながら），偶数になることに耐えるよりは，むしろ，それ以前に滅びるなり，そのほかどんな目にでもあうなりするだろう”（世界の名著シリーズ（プラトンⅠ））．壮大なイデア論における一つの典型的な例示になります．ところで，正式版のコンポーネントの濃度は，3以上になっています．この3は，（最低の区分としての）センサー／論理処理部／アクチュエータを指しているのですが，陽に書かずに，単に３としているところが，ちょっと微笑ましい．

(nil)