Proven in Use とナノと

23/09/2012 – 2:02 PM

今回は，ISO26262 Part 10 の話しに戻ります．再利用の手段の一つに proven in use があります（このほかの再利用手段としては，SEooC やQualification of SW componentというのがあります）．これは定まった訳語がなく，それ自身が説明的名称になっています．「長く使っていて問題ないので，あらためて証明するまでもない」ものということになります．あえて訳すと，「実績が示された」くらいでしょうか．以下では，長いので，PiUとしておきます．正式発行のPart 10では例（といっても想像するほど具体的なわけではありませんが）があります．

***

さて，今回はこのPiUについて見てみます．定義しているのは，Part 8 のClause 14です．例えば，8-14.4.5.2.4では，ASILに応じた観測可能なインシデント率が定められています．それぞれ以下の左側に示すような数字になっています．右側は，インシデントがゼロの場合の最小のサービス期間（実績）を示した表ですが，左側と同等のものです．そこで，もう少し数字の感覚を掴むために詳しく見てみることにします．

右側の平均故障間隔に関して一般に以下の式に従います．もちろん条件が必要で，例えば故障率が期間中一定で，期間を限定するということになります（故障率が一定でない場合は，8-14.4.5.2.6にあるとおり別の考慮が必要になります）．また，これは，8-14.4.5.2.4の NOTE 4にある式と同一です．

規格では，カイ2乗分布に従うものとして信頼レベルが70%以上を求められています（α=0.3）．また，期間中の故障はこの表ではゼロとしますから(n=0)，自由度は２となります．これから計算するカイ2乗分布の境界値の値は，2.4079….ですから，計算の都合が良いように，2.4としておきます．そうすると，故障間隔は，単純にT/1.2と云うことになります．

いま，（故障のない）最小サービス期間が，表右側に示すものですから，Tにこの値（1.2×109）を代入すると，少なくとも109時間という切りの良い数字になります．従って，逆数をとれば，上記の表は，左右で基本的に同一だということが分かるかと思います．

さて，この想像しがたい時間を待たないとPiUといえないかというとそうではありません．同一のエレメントを使用した車はたくさんあるでしょうから，加算によって稼ぐことができます．10,000台の場合で考えます．また，時間だとイメージしづらいので，平均一日2時間使用されているとします（商用車はそんなことはないのですが，対象が3.5トン以下の乗用車ですから自ずと限定されると思います）．この場合，年に730時間．従って，先の最小時間を達成するためには，簡単な割り算で，137年ほどかかることになります．結局，なかなか達成は難しい．

逆に，2年ほどで，達成できる台数を考えると68万台強ということになります．こちらも難しい．ASIL D にこのPiUを適用するのは現実的ではないということになります．一方で，それ以下の場合だと，オーダで変化しますから，可能性は高いかもしれません．

観測中にインシデント(n)がゼロではなかった場合の最小期間についてもせっかくなので計算しておくことにします．ついでの計算ということで，比較的線形性があることと，困難さが（当然ながら）増加するということを見て頂ければと思います．

ところで，機能安全の説明によく10-9といった数値が使われます．しかし，ISO 26262 ではこういった数字を目にするところは限られています．PiUはその数少ない場所です．しかし，幾つかの恣意性を感じます．例えば，先の表ですが，ASIL CとASIL Bで同じ値です（間違いではありません）．ISO 61508のSILとASILとは単純な対応をしていないと云われますが，その例の一つです（もちろん対応しなくてよいという考えもありますが，わかりにくさは残ります．同じことはSIL 4 とASIL D の関係についてもいえます．自動車で SIL 4 はないという主張もありますが，そうだとするとPIUにおける10-9は，市場での評価ということでより厳しい条件を与えられていると云うことになります）．
また，最低期間には残念ながら達していないが用いることが可能と判断可能な場合の暫定インシデント率は，ASIL D で3×10-9以下と示されています（8-14.4.5.2.5 Table 9）．この3についても，不思議な3であり，特段の合理的な説明はなく，いわゆるエイヤだろうと思います．

自動車のように市場に多数出荷される製品において，このPiUに期待される役割は大きく，上記に挙げた課題を含めて，これからより研究が進められ，その結果が反映されてくるのではと思います．

また，実務上は，如何に市場におけるインシデントの発生状況を把握するかです．これができていないと，結局は n はゼロのままなので，そのエレメントは実際以上に安全とみなしてしまうことになります．Part-10 では実績の観測手段として，以下を例として挙げています．

  • 保証クレーム
  • フィールド欠陥分析 ないしは
  • 車輌製造業者からの欠陥パーツの返却

こちらは，（先の研究以前に）PiU規格を適用する上で困難な点だろうと思います．いまのところ販売した乗用車がつねに追跡されているわけではありませんから．

***

さて，タイトルのナノですが，これは本文中でも使用した10-9の別名です．ナノメートルといえば原子よりは少し大きく有名なフラーレンの修飾を含まないサイズくらいでしょうか．どちらにしろ小さなものです．


故障率ではきわめてマレであることを示すために，よくナノが用いられます．別の例をあげると，原子力発電所の場合，10万炉年に一回といういい方をします．時間換算するとおおむねナノになります（24時間*365日=8760≒104）．世界で約400炉あるので，250年に一回は起きるという頻度になります．稼働年数を考えるとそれほど気の遠くなる数字ではなくなります．

(nil)

By nil | Posted in ISO 26262, SOUP, 安全 | Proven in Use とナノと はコメントを受け付けていません

人間の条件

16/09/2012 – 7:44 PM

セーフティケースの考え方からは，ゴールが最初にあり，プロセスは二次的に作られる．というのが前回の話でした．

IPSEという言葉が20年ほど前にありました．Integrated Process Support Environment の略です．2つめの単語は，Projectの間違いではありません．もともとソフトウェアプロセス開発に関わる議論は，技術に関わるものでした．代表的な論文は，Osterweilさんの”Software processes are software too”(doi:10.1007/11608035_3)です．直訳すると，ソフトウェアプロセスもまたソフトウェアであるということになります．このタイトルは，少し誤解を招きやすいタイトルです．特に今の時代ですと，人間機械に対してプロセスもプログラムすることが可能であるという風に解釈してしまうかもしれません．

実際には，読んで頂くしかないのですが，主張しているのは次のことです．ソフトウェア開発というのは，プロジェクト毎に環境も求められるものが異なっている．かつ，一度しか作られない．しかし，これは我々が対象としているプログラミング開発に似ている．例えば，我々は場面に応じたライブラリを用意し，必要に応じて組み合わせる．万能プログラムはなく，必要に応じて我々はプログラムを構成するように，開発支援環境を考えることができるのではないのか．というのが主眼でした．我々の活動をプログラミングするということではなく，我々の活動が多様であることを前提に，如何にその多様性を（我々が持っているソフトウェア技術を使って）支援できるかというのが主眼でした．そして支援のための環境を作る，それがIPSEというわけです．

しかし，世紀が変わる頃から，プロセスについての議論というといかにプロジェクトを管理をするかという話が主流になってきます．他とは異なりソフトウェア開発が持つ本質的な多様性は変わらないわけですから，単なる管理だけだと，膨大なリストを作って全体を包含しようとするか，とにかく目に見える要素を増やそうということでしかなくなります．例えば，そこでは労働時間という肉体に密接に結びついた要素が重要と云うことになります．

***

ゴール指向のアプローチの特徴的なところは，ナゼを含むところにあります．GSNでいえば，立証のノードであったり正当化ノードが相当します．安全性に間接的に関係するKAOSのアプローチでいえば，アンチゴールやドメインプロパティノードを通してナゼを説明することができます．どういう証拠を用意すれば，安全要求を達成できていると説明できるかを考え，そう行動し，そのこと自身を記録に残すということになります．ここでも記録が大事なのではなく，ナゼを考えた上で，ナゼを含めた記録を残すことが重要です．それがないと，例えば設計に対してレビューを対応づけるという機械的接続だけでよしとしてしまうかもしれません．

このことを敷衍すると，安全性に限らず一般の開発プロセスでも同様ということがわかります．同じようなものを同じように作る場合ですら，一般的にこのナゼは必要なわけですから，ましてや多様な入力を持つソフトウェア開発において，このナゼが書かれないまま，例えば，設計に対してレビューをしましたというプロセス記述が妥当だとは誰にもいえないと云うことになります．レビューをしたという事実が重要ではなく，どういうゴールを達成するために，いかなるレビューをしたかが意味を持ちます．多くの場合客観的証拠のみでは意味がありません（レビューでの不具合指摘ゼロは，設計が完全であったかもしれないし，レビュー中みんな寝ていたかもしれない）．

ナゼを考えるのはきわめて人間的な精神活動です．しかし，だからこそ，何かを作るというのは，楽しいのだろうと思います．

***

今回のタイトルは，ハンナ・アレントの著作の一つからとりました．「技術的知識という現代的意味での知識と思考とが，真実，永遠に分離してしまうなら，私たちは機械の奴隷というよりはむしろ技術的知識の救いがたい奴隷となるだろう（志水速雄訳）」この一文のためにタイトルをお借りしました（実は，今回は別の内容を書くつもりだったのですが，ついタイトルを先に決めてしまったので少し内容と合っていないのですが，ご容赦を）．

この本では，人間の活動を三つの視点からみます．労働（ここでは生命が人間であることの必要条件）・仕事（生命を越えて社会に働きかける−世界性−が人間の必要条件）・活動（無媒介に人と人とが結びつくー多数性ーが人間の必要条件）です．ところで，私が考えごとをするときに参照する無形労働の提唱者の Lazzaratoさんは，ことある毎に（すくなくとも最近の著書でつづけて(*)）アレントのこの見方が無効であるといいます．Lazzaratoさんの無形労働概念は，「不安定な労働を通して仕事をするために活動を強いられるという現実」からスタートします（それは欧州ではすでに10年以上前から起きており日本も近づいている現実）．従って三つの視点を区別することができない．しかし，アレントの区分があることによって，無形労働概念が説明しやすいというのは間違いないだろうと思います．

(*) 邦訳での最新刊は，「<借金人間>製造工場」（杉村昌昭訳，作品社）．原題もほぼ同じで”la fabrique de l’homme endetté”．

（nil）

【追記】お知らせです．今月の26日SEA-SPINで「システムの安全性」を考えるという会があります．ご興味がありましたらご参加ください．

By nil | Posted in セーフティケース, プロセス, 安全 | 人間の条件 はコメントを受け付けていません

made in Japan

09/09/2012 – 4:57 PM

先月の終わり，日本学術会議主催の一般向けセミナーに出かけてきました．「原発事故調査で明らかになったこと」というタイトルで，三つの代表的な報告書（国会・政府・民間）について，それぞれまとめられた方から説明がありました．この報告書については，いずれ書く機会があるかもしれませんが，今回は別のことです．

*** 

重大事故については報告書が提出されます．ここではそのうち有名な報告書の一つを取り上げて考えてみたいと思います．一般に，カレン報告と呼ばれているものです（Cullen氏は当時スコットランドの裁判官で，このほかにも幾つかの事故報告をまとめています）．司法関係者ならではの分かりやすい記述で，証拠を示し立証を通して次に進むべき道を示すという構成になっています（GSNの例としてもふさわしい）．

1988年に北海の海上油田パイパー・アルファで火災が発生し167名が死亡しています．報告書は1990年に”Public Inquiry into the Piper Alpha Disaster”として，上下2巻として発行されています．

上巻では事故の発生（The Disaster）と背景・原因（Background To The Disaster）について記述されています．大きな事故ではありがちですが，多数の事柄が事故に関係してきます．関係するといっても，必ずしも同時に故障するということではありません．それは，健康体であれば問題がない菌も，入院中に日和見感染するということにています．弱みをみせると，通常はなんでもないことが，牙をむく．例えば，パイパー・アルファの事故では，海水による自動消火装置が働かなかった理由の一つとして，マニュアルモードに切り替わっていたたために「自動」ではなかったということが挙げられています（12.6）．ダイバーが夜間作業をするのですが，海中の作業エリアが，海水の消火装置用取水口に近いため，ダイバーの「安全」を確保するために，恒常的にマニュアルモードにしていた．事故の時には，ダイバーはいなかったにも関わらずマニュアルモードのままでした．かつ，事故の進展によってモードを変更することができなかった．安全のためのマニュアルモードが，結果的に多くの犠牲者を生むことになりました．いくら自動消火装置システムが（ダイバーの）安全と信頼性に配慮した作りだったとしても，より広いシステムからみれば，問題があったということが，ここでは事後的に分かります．

下巻は，The Future というタイトルで今後の対策について書かれています．ここで興味深いのが，勧告の章です（Chapter 23）．様々な勧告が書かれているのですが，一番最初がセーフティケースです．セーフティケースは別の分野では用いられており，この報告書で初めて示されたというわけではないのですが，大きな事故のあとの注目されていた勧告で強調されたと云うことで，これ以降の英国の法規制においてセーフティケースは，重要な意味を持つことになります．

勧告の一部を抜き出してみます（23.1，直訳ではありません）．

セーフティケースは，当該目的に適合していることを示さなくてはならない．そのためには以下を含むこと．

  • 組織の安全管理システム（SMS）およびその運用は，施設の設計や施設の運用が安全であることを保証するのに十分であること．
  • 施設における潜在的な主たるハザードおよび作業者に対するリスクが識別されていること．また適切な制御手段が提示されていること
  • 施設に影響する緊急事態の事象がにおいて，次の十分な準備が保証されていること．(a) 施設作業者のための一時的安全避難（TSR）(b) 安全で十分な待避・脱出・救助

特に最初の勧告に英国におけるセーフティケースの役割が示されています．セーフティケースは，安全管理システム（SMS）を含んでいます．安全管理システムの一部としてセーフティケースがあるわけではなく，場合によってはその設計もセーフティケースの範疇になります．安全に関する設計と記録の集合体として，セーフティケースが定義されています．これは，Cullen報告で参照したCIMAH規制から来ています．セーフティケースとは，単にGSN／CAEを書くということではないということに注意が必要です．

これは，以前に書いたように，英国の安全に対する取り組みの特徴的なところです．プロセスや手順といったものは，安全を考えた後に派生する*二次的な*ものとなります．

***

ところで，今回のタイトルです．英国物理学会の学会誌であるphysics world の8月号に，”Fukushima accident was ‘made in Japan'”という記事があり，そのタイトルをお借りしました．国会事故調査委員会の報告で，「福島第一原発の事故は人災である」との結論を受けてのタイトルです．事故は自然災害が原因ではなく，日本人によって作られたものだという，これも英国的なシニカルなタイトルになっています．

(nil)

By nil | Posted in セーフティケース, プロセス, 安全 | made in Japan はコメントを受け付けていません