Skip to content

安全情報のトレーサビリティを改良する安全モデリング言語「SafeML」の紹介 – Part1/3

ロボット、自動車、家電などの設計に必要不可欠な「機能安全」。設計をする人、安全分析をする人、安全情報を認証する人など、システムに関わり、かつ異なる専門を持つ様々な人たちの間で、安全設計の情報を効率的に伝達、管理する手法「SafeML」の紹介

Advertisements

動詞de!! モデリング ③「C言語編」

「モデリング」してますか? 今日は、「動詞de!! モデリング」、③C言語による実装編、という事で、実際にプログラミングに落としていく過程を、セイコーエプソンの萩原さんにお話いただきます。(①導入編、②実践編) では、萩原さん。よろしくお願いします。    モデリング習得3つの壁とその対応策   「オブジェクト指向の設計の敷居が高い」という点と「UMLの習得が難しい」という点、この部分について説明したいと思います。    オブジェクト指向にこだわらなければよい まず「オブジェクト指向の敷居が高い」というのはですね、対策としては「オブジェクト指向を使わない」と決める。「データ抽象」という、オブジェクト指向以前のものを使ってですね、それをやりきる、という形になります。 「データ抽象」が何かというと、データと関係する関数を同じ場所に置く、というものが「データ抽象」になります。 C言語でいうとですね、.cの所に関係するデータ、つまり変数と、その変数を使う関数を集める、ということですね。 別の言い方にすると、「モジュラーアプローチ」というようなものになってきます。これをクラスにする、という形になります。   .hと.cのペアですね。これをクラスと対応付けることができます。クラスの中で公開する関数はプラス、パブリック属性になりますが、これをヘッダーファイルに置きます。非公開にする関数は、Cですとstatic宣言した関数になりますね。変数は、基本的に非公開にしますので、static宣言します。 Cの場合、.cからヘッダーファイルにincludeします。この時、クラス図の関連線が対応することになります。このようにすると、C言語の技術者でもクラス図を描くことができます。まぁ、多分ですね、普段作っているCの構造、Cのソースコードと同じ構造のクラスがすぐ作れると思います。    使うUML図は3種類でよい。クラス図、コミュニケーション図、ステートマシン図 「UMLの習得が難しい」というものがありますが、これについてですね、使用するダイアグラムの種類を3つに絞りました。 […]

koredake modeling UML

【対談】「これだけ」モデリング – Part 2/2

「これだけ」モデリングの生みの親、株式会社メソドロジックの山岸さんと、チェンジビジョン平鍋による対談、後半です。モデリングの威力や、出来上がった「モデル」ではなく「モデリング」というプロセス活動をチーム内で共有することが重要であること、など熱く語っています。(対談の前半は、こちら)

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

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

MBSE (モデルベース・システムズエンジニアリング) とSysML概説

 「モデルベース・システムズエンジニアリング」とSysML概説 「モデリングしてますか?」 システムが複雑になって、メカ、エレキ、ソフト、色んなコンポーネントが絡み合って、一つの目的を達成するようなシステム開発では役割を超えて、いろんな人が、メカ専門の人、エレキ専門の人、それからソフト専門の人集まってですね、システムの問題領域を理解する必要があります。 あるいは、その作ろうとしているシステムの構造や振る舞いについて、共通の理解を作っていく必要がありますが、その為にですね、今、「システムズエンジニアリング」といった領域が注目を集めています。 特に、中心に「モデル」を作ってですね、そのモデルで、全体の合意を作っていこう、という「モデルベース・システムズエンジニアリング」、略して「MBSE」と言いますが、そんな活動、新しい工学が、今、注目をされています。 最近ですと、鉄道、航空、自動車ですね。あと日本だとロボティクスやスマートハウスといった、そういったシステムも今言ったようなシステムズエンジニアリングの課題になってきています。  オーケストラのように、全員が全体を把握できる楽譜が必要 例えば、オーケストラを例にとるといいかもしれません。色々な楽器を吹く方々が集まって一つの音楽を作るときにやはり指揮者のような立場の人がいて全体をオーケストレイトしていく。そんな必要がでてきます。そういう時に、共通の図面というか言語が必要になります。 メカ、エレキ、ソフト、それぞれが独自の図面というか、ビジュアライゼーションの方法をもっていますが全体を通じたものって、今まで定義されてませんでした。 SysMLという言語がOMGで定義されて、そのオーケストラの楽譜のような全体で、それを見て全員が理解できるような言語が作られてきています。このAYM(Are you modeling?)サイトでは、SysML、それからMBSE(Model based systems engineering)それから、Safety関連ですね、特にGSNと呼ばれる「システムが安全である」ということを、ビジュアルな表現でもって議論をしていくような手法なんかも注目されています。こういった新しい手法をみなさんに紹介していきたいと思います。

UML ›

【対談】「これだけ」モデリング – Part 1/2

「これだけモデリング」は、なぜうまれたか - 対談その1。 UMLの仕様を全部使ってモデリングするなんて、無理。モデリングという「活動」を通して参加者に「残像」を残すことが重要。

「これだけ」モデリング – Part 2/2

「モデリングしてますか?」 今回は、前回の続き「これだけモデリング」ですが、アジャイル開発の中で、もっとモデリングを使おうという話をしていただきます。「これだけモデリングは、アジャイルを加速する」という事で、山岸さん、よろしくお願いします。   皆さん、こんにちは。メソドロジックの山岸です。 今日は、「これだけモデリングは、アジャイルを更に加速する」というテーマで、お話をさせていただきます。  アジャイルとモデリング 最近、アジャイルが非常に盛んになっておりますが、そうした中で「アジャイルは、ドキュメント削減するんでしょ、だからモデリングやりません」という混乱が散見されており、そこが随分違うなと、私は思っています。 アジャイルといっても、最近のアジャイルの話題は、エンタープライズにどう適用するか、です。アジャイルというと、スプリントのサイクルのところに話がフォーカスされる、つまりプロダクトバックログを作ってから以降の話、という事です。 ただ、エンタープライズというのは、色んなシステムが複雑系を成しているというか絡み合ったもので、且つデータの移行などの複雑なもので、対象も複雑な業務なわけです。  スプリント以前のモデリング ですから、一定のリズムでアウトプットを出していくというようなスプリントのサイクルに入るまでの所、つまり、バックログを積むまで、にやっておかなければいけないことが、沢山あるんです。 実際に、1番重要なのは「業務を正確に把握する」というところですね。そこで、モデリングは非常に有効に働くと私は思います。 スプリントに入ると、非常に高速になるわけですが、そこに至るプロセスをできるだけ素早くやっていくという部分は同じだと思うのですが、業務を更に素早く把握しようとするとモデリングの力を借りざるを得ない訳ですね。 モデリングによって、先ずちゃんと地図を描いておくこと、それからエンタープライズの場合、システムを長期に渡ってメンテナンスしていくという意味では、やはりアーキテクチャを、きちんと設計した上でスプリントのリズムに入っていかなければいけない。 という事で、この辺りは、モデリング無しで素手でやれるような領域ではないと考えています。 更に業務を正確に手早く把握するためには、モデリングの力を十分に活かさないと、まず難しいでしょう。  スプリント中のモデリング 実際のスプリントに入ると、設計者と実装者は変わりませんから、同じメンバー間のコミュニケーションを高める、という意味では、わざわざUMLで設計書を描いて、それをベースにコーディングする、というような情緒なサイクルではなく、「素早くやる」という事であれば、全体の構造をちゃんと理解した上で、それを時々見る、ということで、最初の段階でモデル化したものを参照しながらという事になります。 また「コミュニケーションを活性化する」という事は、アジャイルの中で非常に重要なわけですが、言葉より伝わる、というモデリングは、スケッチとしてあるわけですよね。いくら言葉で言うよりも、お互いが共通理解しているノーテーションで描いた方が、よっぽど早く伝わる。その方がよっぽどアジャイルだ、という話が、1つあります。 そういうところで、モデリングを使うと、更にスピードが加速する事ができます。 […]

SysML ›

GSN/D-Case ›

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

モデリングしてますか? 前回に引き続き、デンソークリエイトの小林さんと今日は対談という事で、よろしくお願いします。   ありがとうございます。     GSN(Goal Structuring Notation)って、実際に描いてみると難しいじゃないですか。     そうですね。     今回は「GSNやD-caseをレビューに使う」という話でしたが、そもそも、GSNやD-Caseをレビューに使いたいと考えたきっかけは、何だったんですか?    もっと中に踏み込んだ議論をしたくて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の実際の記述内容になります。一部抜粋してきております。 まずはじめに、トップゴールを置いて、先ほど述べたように「目的が達成されているという議論」、それと「入力が適切であるという議論」に分解していきます。 […]

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

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

Safety Case ›

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

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

介護補助システムの設計(1) 要求図編

チェンジビジョン astah* SysML製品プロダクトオーナーが、「介護移乗補助装置」を題材に、SysML要求­図の描き方を解説します。 [スクリプト] このシリーズでは、介護現場における移乗補助システムの設計を想定して、V字プロセスに沿ってSysMLモデリングの図を描いていきたいと思います。 移乗介助システムにおいて、この二つの要求があると考えられます。 各要求においてIDがあります。 そして、各要求において概要もあります。今回は概要の内容を省略します。 腰痛リスクを軽減するために、腰の負担を軽減しないといけないため、この二つの要求の­間に導出関係があります。 V字プロセスにおいて、要求段階で洗い出した要求に対して、検証段階において、必ずそ­の要求の妥当性を検証しないといけないため、非介護者の体重を反映したアシストが可能­というテストケースが登場します。 このテストケースによって腰痛リスクを軽減する要求が検証されます。 この一連の要求とテストケースを実際に要求図で描いていきましょう。 要求図を描いていきましょう。 ここに要求のアイコンがあります。 ここをクリックして要求を作成します。 astahでは、図面をダブルクリックしても要求を作成できます。 さて、要求の名前を編集しましょう。要求のIDと要求の概要も編集しましょう。 さて、もう一つの要求を作ります。 今度はプロパティビューから要求名などを編集しましょう。 この二つの要求の間に、導出関係があるため、導出関係を作成します。 […]

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

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

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

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

【対談】「これだけ」モデリング – Part 1/2

「これだけモデリング」は、なぜうまれたか - 対談その1。 UMLの仕様を全部使ってモデリングするなんて、無理。モデリングという「活動」を通して参加者に「残像」を残すことが重要。

技術レビューの現場におけるGSNの活用法(2)〜相手と自分の共通理解をつくるには

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

介護補助システムの設計(2) ブロック定義図編

チェンジビジョン astah* SysML製品プロダクトオーナーが「介護移乗補助装置」を題材に、SysMLモデリングを紹介するコンテンツの2回目です。 前回のSysML要求図に続き、今回はブロック定義図およびブロックと要求間の関係の描き方、ブロックや満足(satisfy)などのモデルを解説します。 ■SysML動画シリーズ (1) 要求図 (2) ブロック定義図 (3) 内部ブロック図 (4) パラメトリック図

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

モデリングしてますか? 前回に引き続き、デンソークリエイトの小林さんと今日は対談という事で、よろしくお願いします。   ありがとうございます。     GSN(Goal Structuring Notation)って、実際に描いてみると難しいじゃないですか。     そうですね。     今回は「GSNやD-caseをレビューに使う」という話でしたが、そもそも、GSNやD-Caseをレビューに使いたいと考えたきっかけは、何だったんですか?    もっと中に踏み込んだ議論をしたくてGSNを使い始めた うちの会社では、レビューの場では「手順」をしっかり抑えておこうと、チェックリストなど色々あるのですが、最近それに慣れてしまったメンバーもいて、プロダクトの中身について議論する機会が減ってきたんです。 そこで、GSNというフォーマットを使うと、「前提」という形で考え方などを見える化できるので、中に踏み込んだ議論ができるようになるんじゃないかな、と。 なるほど。 […]