Skip to content

Category: GSN-theory

ISO26262指向 安全コンセプトの記述法 (Part 1/2)

自動車用 機能安全規格ISO26262の「安全コンセプト」について、現状の悩み、課題

Advertisements

「アシュアランス・セーフティーケース概論」〜歴史的背景と制度〜

モデリングしてますか? 今日は産総研(AIST:産業技術研究所)から田口研治さんに来ていただいて、セーフティケースの歴史的背景やGSNについてお話しをいただきたいと思います。 では、田口さん、よろしくお願いします。 産業技術研究所の田口と申します。 本日はセーフティケースの背景から始まって、どのようにGSNという表記法が使われているかについて簡単に説明させていただきたいと思います。    セーフティケースの歴史的背景 まずですね、セーフティケースについて歴史的な背景を説明する際に重要な用語として「セイフティケースレジーム」という言葉があります。これは、セーフティケースというのは単にドキュメントではなくて、やはりその法規的な問題から始まって社会制度としてどのように安全性を保証するかという、相対的なものとして捉える必要があるということです。 セーフティケース自身は有名な話として、パイパー・アルファ(Piper Alpha)という北海の油田の事故から始まりました。 実際に北海の油田の事故においては、その結果ですね、Offshore Installations Regulationという実際に法制度として確立されたという歴史的背景があります。  セーフティケースの定義 セーフティケースの定義ですけれども、英国の防衛規格であるDefence Standard 00-56という定義においては、 「与えられた運用環境におけるシステムの適用に関して、安全であることを、強制的かつ理解可能、妥当な事例として提供する、根拠資料の集まりにより支援された構造化された議論」という定義になっています。 ここでやはり重要なのは「根拠資料の集まりにより支援された構造化された議論である」という、この点だと思います。  セーフティケースが義務付けられている産業分野、規格 実際にセーフティケースが義務づけられている産業分野、規格等は様々あります。 航空機関係では、EUROCONTROLというヨーロッパの航空機管制システムに関する安全性の保証に関するガイドラインがあります。鉄道関係では、Rail Yellow Book(レール・イエロー・ブック)というものや Railway Safety Case Regulations(レールウェイ・セーフティケース・レギュレーションズ)というような英国の規格があります。 国際規格としては IEC62425、ヨーロッパの規格ではEN50129という鉄道システムに関するセーフティケースの規格があります。また車載関係では、ISO26262というものがあります。 […]

GSN記法チュートリアル〜書き方のコツ〜

「モデリングしてますか?」 今日は産総研(AIST:産業技術総合研究所)の相馬大輔さんをお招きして、GSN記法のチュートリアルをお願いしたいと思います。では相馬さん、よろしくお願いします。   ありがとうございます。産総研の相馬です。 本日は、GSNの基本についてご説明をさせていただきたいと思います。    ゴール志向分析と似たようなトップダウンの手法 GSN、Goal Structuring Notationと呼ばれるセーフティケースを記述するための記法なんですが、York大学のTim Kelly等(Tim Kellyの対談ビデオはこちらから)によって開発され、FTAなどのゴール志向分析と似たようなトップダウンの手法になります。      GSNの要素 ノードとしては、基本的には、Goal、Strategy、Solution、Contextといったノードと、それらを繋ぐSupported by、In context ofといった矢印で、それらを繋いで形作ります。主張をStrategyやSub goalに分解し、最終的に、その根拠資料となるSolutionを配置して、その議論を構成するというものです。  専門的な知識を持たない人にも理解できるように明瞭に記述する GSNを描くときの注意点がいくつかございます。 Goal、Context、Solutionなど1つの要素に、複数の要素を含めない、内容をかかない、という事が注意点になります。 次に、明確に記述するという事ですね。 曖昧な2つ以上の意味に捉えられるような文章を書かない、きちんと定義されていない分に関しては、Contextなどをつけて、その意味を明確にするという事が必要になります。 GSNは、もちろん、システムや作ったものに関して専門的な知識を持った方が作りますので、議論の飛躍が起こりやすくなります。 ですので、読む方は、専門的な知識を持たない可能性もあるので、きちんとワンステップずつ議論を構成していかないといけない、というよう注意点もございます。    できるだけシンプルな議論構造に また、GSNの描き方、議論の構造に関してですが、よくコミュニティスタンダードの方でも出てくる「各ハザードに対して、それが対抗されている」といったような議論をかく事が多いのですが、実際には、それらは根拠資料の中に入っている事になりますので、それよりは、もう少しシンプルに、「こういう考えで全部に対して対抗されている」、ということであれば、その根拠資料だけを配置する、といったシンプルな書き方の方が良いと思います。 […]

GSNとD-Case、パターンとモジュール化、日本流の差分・派生開発への適応

「モデリングしてますか?」 今日は、電通大(電気通信大学)に来ています。ここに、松野先生がいらっしゃいます。   みなさん、こんにちは。電気通信大学の松野と申します。 今日は、わざわざ平鍋さんに調布まで起こしいただきまして、今撮影しています。    GSNのおさらい 今日はですね、山本さんが前回話したGSN、アシュアランスケースの話の続きです。 GSNというのは、アシュアランスケースの記法の一つで、システムの安全性とかディペンダリティを、色んな人にきちんと説明するためのドキュメントです。 例えば「システムが安全ですよ」など、色んな人に説明しないといけないんですけど、いろんな説明の仕方があります。GSNは、それを、議論構造を明確にした上で説明できるようにしたものです。 この場合「システムが安全である」というゴールがあるんですが、いろいろ言い方があります。ここでは、システムが持っている機能ごとに分解して説明する、としています。 システムが機能1と2を持っていた場合、システムが安全であるためには、機能1が安全、機能2も安全、という風に分けて考えていきます。 最後にどんどん詳細化していくんですが、最後にテスト結果とか、皆さんが普段やられておられるテスト等の結果を基に、最終的に議論を支えるものを書きます。  パターン機能 さて、こういのをどんどん描いていくわけで、astah* GSNなどを使ってかいていくわけですけども、こういのをバーとかいていくと、どんどん量も多くなっていくし、しかも、これを形自体をどう形作っていけばいいか、ということが問題になってきます。 プログラミング言語、みなさん詳しいと思うんですけど、そうした問題にどう対処していくかというのは、GSNでも一緒です。 1つは「パターンにしてしまう」ということ。要するに、すごく頭いい人が作ったGSNのパターンをそのまま使って、皆さんのGSNもかいてしまえばいい、という話があります。 例えば、簡単な図なんですけど、このシステムを変数として扱うことができます。 例えば、ここに、皆さんの作っている自動車、飛行機、ご自身のシステムの名前をいれるということがあります。また、機能毎といってますが、当然皆さんのシステム毎に、機能の種類や数が全然違いますよね。ここら辺もパターン化して、汎用化するという仕組みも挙げられます。 たとえば、このパターンにありますが、このシステムという所自体を変数化してしまう、という考えがあります。安全と書きます。このシステムというものをプログラミング言語のように変数宣言してしまいます。 システムはストリング型であると、そうすると、ここで定義したシステムというものは、サブゴール、つまり下の構造で、システムというものの変数を自由に使えるようになります。たとえば、システムの機能ごとに議論する、といった事ができるようになります。 ここでもし皆さんが「自分のシステムの名前にしたい」と、車など入れたとしますね。 そうすると、ここでシステムとなっていた所が、自動車、という風に置き換えられます。 こうすると、皆さんがいちいち自動車、自動車、自動車、、と書かなくても、一気に全部変わるわけですね。これが、パターンを実現するための機能になります。 もう一つ、例えば、自動車だったとしたら、機能1、2、3があって、「自動車の機能毎に安全である」というゴールを作らなければいけないんのですが、ここで、機能が100個あったとします。ここで100と指定すると、パターンとすると、ここに100個のサブゴールが作られる、こういうことを実現すると、非常に汎用性の高いパターンを作ることができます。 これがパターン機能です。  GSNの巨大化を防ぐ為のモジュール化 もう1つ、GSNに対しての拡張として「モジュール化」という考えがあります。 モジュールは、みなさん普段プログラム作る時にやられてると思いますが、例えば「機能1は安全である」ということを展開するとします。すると、これだけでもサブがどんどんと果てしなく大きくなっていって、巨大なGSNになってしまいます。 […]

GSN解説(1) – GSN (Goal Structuring Notation)とは何か?

みなさん、こんにちは。これからお話するのは、説明責任とGSN(Goal Structuring Notation)の関係についてでございます。  「システムや活動プロセスといったものが、ある一定の基準や原則に基づいてることを第三者に説明する」、これが説明責任の遂行 説明責任て、皆さん、何だかご存知ですか? 「システムや活動プロセスといったものが、ある一定の基準や原則に基づいていることを第三者に説明する」というのが、説明責任の遂行という考え方ですね。 ということは、我々が開発しているシステムがあるとします。 すると「このシステムが、ある原則に従って開発されている」という事を説明する手段が必要になります。 その説明手段がGSNである、と言うことができると思います。 ということは、GSNで説明することは「システムが原則に従っていること」、これを説明する必要があります。  GSNの4つの基本的な構成要素 そのために、GSNでは、4つの要素を用意しています。 1つは「主張」ですね。「システムが原則に従って振舞う」といったことです。 それから、その主張を直接説明することは、なかなか難しいので、更に細かな主張に分解する必要がでてきます。その時に使われるのが「戦略ノード」と呼ばれるような、分解するノードです。 それから、更に、「システムが原則に従う」ということを説明するために、どのような前提条件に基づいてこの議論が展開されているのかを示すための「前提ノード」というものがあります。 それから最後に「確かにシステムがこの原則に従って振舞う」ということを説明するための、もっとも単純な主張を説明する「証拠」がでてきます。 そういう意味で、GSNには、この4つの基本的な構成要素を使って、こういう主張を説明することができます。 これが、GSNを使って説明責任を遂行する方法です。 [関連記事] – GSN解説(2) – GSNの基礎とその構成要素 – 【対談】GSN, D-Caseの動向と必要性 – 名古屋大学 山本先生 x […]