Skip to content

Category: GSN/D-Case

安全分析の説明技術ーHAZOPやFTAの結果をGSNを使って可視化する

デンソークリエイト 小林展英様による、HAZOPやFTA等の安全分析の結果を、GSNを使って説明する手法についてのチュートリアルです­。

Advertisements

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

DNV GLの山下さんによる、今、自動車業界で大変話題になっている「ISO26262」規格の「安全コンセプト表記法」の紹介。2回目の本レクチャーでは、設計成果物について、例を用いで解説くださいました。

【対談】技術レビューの現場におけるGSNの活用法 〜 デンソークリエイト 小林さん

モデリングしてますか? 前回に引き続き、デンソークリエイトの小林さんと今日は対談という事で、よろしくお願いします。   ありがとうございます。     GSN(Goal Structuring Notation)って、実際に描いてみると難しいじゃないですか。     そうですね。     今回は「GSNやD-caseをレビューに使う」という話でしたが、そもそも、GSNやD-Caseをレビューに使いたいと考えたきっかけは、何だったんですか?    もっと中に踏み込んだ議論をしたくてGSNを使い始めた うちの会社では、レビューの場では「手順」をしっかり抑えておこうと、チェックリストなど色々あるのですが、最近それに慣れてしまったメンバーもいて、プロダクトの中身について議論する機会が減ってきたんです。 そこで、GSNというフォーマットを使うと、「前提」という形で考え方などを見える化できるので、中に踏み込んだ議論ができるようになるんじゃないかな、と。 なるほど。 確かに、議論は個人個人違うじゃないですか。でも、前提というか、周り、議論を支える前提となる基準だったり、コンテキストや、エビデンスとか、実は議論と関係なく存在してますよね。会社でプロセスを決めてくっていうのは、議論構造を決めてくよりも、実は基準を決めてくことじゃないんですか? はい。その辺りに基づいて議論を作っていくと、相手が非常に納得できるという流れになるんじゃないかと思います。  GSNで、知見を「コンテキスト」として定義、蓄積、形式知化する やはり、過去にやった人が持っている知見って貴重で、毎回同じ失敗を繰り返したくない、と、皆そうですよね?あれって、GSNでうまく吸い出せないですかね?   そこは、GSNのコンテキストという形で定義して、それをどんどん蓄積していくという形ができると、非常にいい流れになるんじゃないかな、と。     なるほど。じゃあ、GSNは、議論の構造としては、勿論描く。それは毎回描いても構わないんだけど、そこでやってく中で出てきた知見を、うまくコンテキスト側に押し出していく。 それを、会社なり組織なり、あるいはもうちょっと言うと世界標準なり認証機関を持つ認証かもしれないですが、そっち側の形式知化していく、という活動が、GSNの持ってる力なんでしょうかね? […]

GSN の記述例〜RAMS(IEC62278)

「モデリングしてますか?」 今日は、産総研 (AIST: 産業技術総合研究所)の相馬さん、本日2回目になりますが、今回は、GSNの具体的な記述例を、ご紹介いただけるという事です。では、よろしくお願いします。  鉄道の機能安全規格 IEC62278 – RAMSのドキュメントをGSNで描いた例 産総研の相馬です。 本日は、鉄道の機能安全規格であるIEC62278、RAMSと呼ばれる規格のGSNによる記述について、ご紹介したいと思います。 まず簡単に、RAMSのご説明をさせていただきたいと思いますが、鉄道分野の機能安全規格の最上位のものになります。 ソフトウェア、ハードウェア、それから通信といった規格もありますが、それら全ての上位の規格となります。 RAMSは、全部で14の段階からなっており、コンセプト、それから実装等を経て最終的に廃棄の段階まであります。 この各14段階、それぞれを段階ごとに、今回はGSNによる記述を行いました。 今日ご紹介するのは、第3段階のリスク分析に関する部分です。それともう1つ、RAMSに関してですが、各段階で5つの構成要素からなっています。目的であるObjective、その段階へのInput、要求事項Requirementその段階で作成される成果物Deliverableと呼ばれるものです。そして最後にVerification、検証、といった5つの項目から必ず成り立っております。 では、どのように記述していくのか、まずは第3段階リスク分析のフェーズになりますが、このリスク分析のフェーズが十分行われている、実施されているという事をトップのゴールとしておいて議論を展開していきます。左側に関しては、RAMSの目的Objectivesがきちんと達成されている事に関する議論、右側は、入力が適切なものを持ってきているという議論になります。 このようにアーキテクチャーをまず決定してから、GSNを構成していきます。今日は、この上位概念部分のGSNの記述と、ある1つの目的に関する議論の部分を紹介します。 こちらが、IEC6788 RAMSの実際の記述内容になります。一部抜粋してきております。 まずはじめに、トップゴールを置いて、先ほど述べたように「目的が達成されているという議論」、それと「入力が適切であるという議論」に分解していきます。 更に、目的は、このように4つあります。全ての目的が達成されている、各目的に対して議論を展開すると。ただ、全ての目的とかいても、いくつあるのか、というのが分からないので、それをコンテキストで補うようにします。 実際に、4つの各目的が達成されているゴールを配置していきます。このように上位概念を構成していきます。 それでは、1つの目的である「十分なハザードが特定されている」というゴールに対する議論になります。 目的を達成するためにしなくてはならないこと、要求事項、それから、検証といった部分に記述されています。 例えば、要求事項、検証等から「どのような事を達成すれば十分なハザードが特定できているのか」、ここでは体系的な手法によるハザード特定が行われていること、さらにハザードの原因となる所に関して、全て網羅的に考慮されていること、そして実際にハザード特定を行う方の力量が示されている、ちゃんと力量を持った方が、ハザード特定を行っているということがサブゴールとして配置されます。 さらに、ハザード特定の方法に関しては、セーフティプランという計画で考えられていた方法通りのものが用いられていること、もしくは、ハザード特定の範囲がきちんと定義され、その範囲内で行われている事などが、コンテキストとして配置されております。 実際に行われたハザード特定であったり、力量を示す資料などが、Deliverable(成果物)として作成されておりますので、これらが、最終的なソリューションとして配置されるという事になります。 IEC 62788 RAMSをGSNで描くと、このような形になります。 […]

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

モデリングしてますか? 今日は産総研(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の活用法(2)〜相手と自分の共通理解をつくるには

「モデリングしてますか?」 DENSOクリエイトの小林さんを再度お招きして、GSNを使ってレビューをする際に問題となる「共通の合意の作り方」についてお話ししていただきたいと思います。では小林さん、よろしくお願いします。   前回「議論においては、前提を相手と合わせる事が大切だ」とお話させていただきましたが、今回は、そこについて簡単に紹介させていただきたいと思います。 まずはじめに、相手と自分の、議論の前提の認識が合っているかどうか、という状況を図示すると、おそらくこういう4ディションになるのではないかと思います。  自分と相手が共に知っている状態 1つ目については「自分と相手が共に知っている状態」。ここは、実際の開発現場で考えると、相手がずっと仕事をやってきて、自分も一緒に仕事をやってきた、というのが、このディションになるのではないかと思います。  相手は知らず、自分のみ知っている状態 – しっかり教える 「相手が知らなくて、自分が知っている」所というのは、自分たちの技術に、お客様が非常に関心を持ってくれている、「新しく仕事を始めよう」という状態、あるいは、お客さんの方の窓口が変わった、という場合は、こういう所になります。 ここでは、自分の知っていることを相手にしっかり説明しておかなければ、相手が、いつまで経っても「自分のこととして仕事に取り組んでくれない」とか「中を見てくれない」といったことになるのではないかと思います。  相手のみ知って、自分が知らない状態 – しっかり教えてもらい明文化する 「相手が知っていて、自分が知らない」という領域については、お客さんが長らくやってきた製品開発の中で、自分たちが参入する、という場合になると思うのですが、ここの前提もしっかり合わせておかないと、後になって「なぜこんな事も分からないのか?」というような話があがるかもしれません。 そういうリスクがあるので、ここの領域については、相手にしっかり教えてもらって、明文化するという事が必要になると思います。 前後しますが、ここ (相手が知らず、自分のみ知っている領域)は「教えてあげる」という事がいりますね。  自分も相手も知らない状態 – 一緒に前提を作り上げる 最後に「自分も知らずに、相手も知らない」という領域については、相手と自分が一緒になってまずは前提を作っていくという作業があって、それに基づいて仕事を始めるとうまくいくのではないかと思います。 ここは「一緒に作り上げる」ということが大切ではないかと思います。 議論自体は、こういう形になると思ってます。  議論の周囲にある「相手と合意しているもの」を明らかにしてから議論を形作る 議論の対象がこのスコープだとします。その時に、先ほどのモデル(相手と自分の状態)を念頭に置きながら、どういった前提文書があるか、相手と合意形成されている前提文書や証拠文書、こういったものをしっかりと洗い出すことが、まず大事だと思います。 その上で、議論の対象となるもの、「何を主張したいか」ということ、例えばこの主張が妥当であることを証明したいのであれば、前提文書等を用いて、この主張を分解していき、相手と合意形成をできる証拠文書に基づいて、ここを証明する、と、こんな形で先ほどの議論モデルを念頭においてまとめてくると、GSNでこういった形で伝わるのではないかと。 そこが合ってることによって、共通理解をもったGSNを書いて、相手に納得してもらえるのではないかと、そういうことを考えています。 はい、ありがとうございました。 […]

技術レビューにおけるGSN, D-Caseの現場活用法(1)〜レビューの前提となる基準を作る

モデリングしてますか? 今日は、DENSOクリエイトの小林さんをお招きしてGSNを現場のレビューで活用する、という例についてお話をしていただきます。 では、小林さん、よろしくお願いします。   クリエイトの小林です。今日は、平鍋さんに機会をいただきましてGSN(Goal Structuring Notation)の現場活用についてお話させていただきます。    GSN(Goal Structuring Notation)の記述ルール 先ずはじめに、GSNの簡単な記述ルールですが、GSNとは、トップに自分の主張したいものの状態を置きまして、それを、相手と合意形成している前提に基づいてサブの主張に分解していく、と、最終的に、そのサブの主張が、証拠に基づいて証明される、といった記法になっております。  GSNを使って解決したいこと 実際これを開発現場で、どう活用していこうかという事なんですが、現状は、現場が抱えている問題としまして、皆様もよく感じられる事があると思うのですが、上位の方が、部下の成果を見た時に「この内容って、何でこういう形になってるの?」という事が分からない、とか、そういった話がよくあると思います。又は「僕の思った通りに作ってくれないじゃないか」といったような事もあるんじゃないかと思います。また部下の視点からいくと、上司の人に見てもらったんだけど何回見てもらってもOKがでない、といった事もあるように思います。 それを簡単に図示した絵が、こちらの絵になるのですが、この絵の中では、作成者の方が、成果物を、自分の考えに基づいて作成し、上位の方も、自分の経験に基づいて確認する、といったことになっています。 当然ここで、上位の方と部下の方、作成者の方ですね。ここの考え方というのが合ってるはずがないので、その結果、度重なるやり直しとか、手戻りといったことが発生しているのではないかと考えております。 そうしたものを解決するために、一番簡単なのが「上司の方と部下の方の認識を合わせる」「考え方を共通化する」という事が大事だろうと。 ですので、こちらの図に書かれていますように、色んな基準というものレベルがあると思うのですが、それを上位と会議の担当者の方と合わせることによって、作成者の方はその基準に基づいてものを作り、上位の方は、その基準に基づいて成果物をレビューする、と、そうすることによって、手戻りなく、うまく仕事ができるんじゃないかなという風に考えて、こういった活動を現場に投入していこうと、いま考えております。 GSNを使って解決する方法としましては、こちらの図に示しましたように、相手と自分の考え方を共通化する、という上司と部下の認識を合わせることによって、部下の方は、成果物をそれに基づいて作成し、上司の方は、それに基づいて部下の成果を確認する、という仕組みを作ることで、うまく仕事が回るようになるのではないかと思っております。 ということは、このコンテキストの所に、「基準」というものを書いていく、ということによって全体の考え方が、上司と部下、あるいはレビュイーとレビューワーの間で合意を先に作っておく、ということで、このGSNが、よりレビューしやすくなるという風に考えればいいですね。 この続きについては、次のビデオでご紹介します。

【対談】GSN, D-Caseの動向と必要性 – 名古屋大学 山本先生 x 平鍋対談

 最近のGSN(Goal Structuring Notation)の動向 では、先生、最近のGSNの動向について、少しお話をいただけませんか?     最近、我々がまとめたのが… お、これは!     DEOSの本ですね。所さん(所眞理雄氏)が中心になって、7年間のプロジェクトの成果がまとまったんですね。それが、このDEOSという本です。この中に「ディペンダビリティ工学」というのがあるんですけど…   これは、新しい名前ですか?「ディペンダビリティ工学」?     そうですね。「Dependability Engineering for Open Systems」という事で、変化し続けるシステムのためのディペンダビリティ工学。その変化し続けるシステムのディペンダビリティ、信頼性を保証するために、ここに図があるんですけど(右下画像)、D-Caseが使われています。D-Caseは、GSNを拡張した表記法ですね。   これは日本で書かれた本ですか?     はい、日本で書かれた本です。この取り組みを、オープングループというエンタープライズアーキテクチャの標準化をやっている組織があるんですけど、そこに我々が一緒になって提案しています。それは、エンタープライズアーキテクチャを高信頼化するための手法で、GSNが、本格的に採用されています。そういう動きがあります。    ISO26262の機能安全の中で、GSNは標準的な表記法として採用されている 先生は、GSNに着目された、”D-case“として、DEOSの中に持ち込もうとされた着目の動機みたいなものはありますか?   それは、「受け身」で始まったんですけど。笑。 […]

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解説(2) – GSNの基礎とその構成要素

こんにちは。名古屋大学の山本修一郎です。 GSNは「あるシステムやプロセスが、基準を満たす」ということを説明するための手段です。 ですので、まず「主張」というものがあります。 この主張は、システムや基準、原則がありまして「こういうシステムや基準を対象にして、システムが、ある基準や原則を満たす」ということを説明するための手段です。 これを説明するためには、例えば「システムの構成で説明する」という事になります。 そうすると、システムの構成というのは、例えばこのシステムには構成要素があるので、 「構成要素がこの基準や原則を満たすこと」と 「構成要素の関係が原則を満たす」 この2つを説明する必要が有ります。 それぞれについて、確かに関係が原則を満たす客観的な「証拠」があります。要素についての証拠もあります。 そうすると、今度はこの要素に基づいて、確かにシステムが、こういった原則を満たしているということを、第三者に対して論理的、合理的に説明することができます。 これが、GSNの最も基本的な考え方なんです。 [関連記事] – GSN解説(1) – GSN (Goal Structuring Notation)とは何か? – 【対談】GSN, D-Caseの動向と必要性 – 名古屋大学 山本先生 x 平鍋対談

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 […]