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

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

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

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

【対談】ロボットのハードウェア抽象化層を標準化する – JASAがOMGでHAL(Hardware Abstraction Layer)の規格を提案

米国OMGの規格策定会議に参加中のJASA(組込み技術協会)の中村理事に、JASAが提案しているOpenELおよびHAL規格について、その思いをお話頂きました。 モデリングしてますか? 今日は米国のテキサス、オースチンに来ています。OMGの標準化ミーティングに参加しています。今日は中村さんをお招きしてお話を伺いたいと思います。こんにちは、中村さん。   こんにちは。      ロボットのハードウェア抽象化レイヤーの標準化活動 今回OMGはどういった目的で参加されているんですか?     はい。私はOMGではロボットのハードウェア抽象化レイヤーの標準化を進めようということで参加しております。     HALってやつですね。エイチエーエル。     はい。ハードウェア・アブストラクション・レイヤーの略で「ハル」と呼んでおります。     その辺に関わることになった経緯も含めて自己紹介をお願いできますか?     私は、日本では社団法人組込みシステム技術協会、略称でJASAと言いますが、そちらで理事をしておりまして、その中のプラットフォーム研究会というところで、ロボットのハードウェアの抽象化を標準化しましょうという活動を行っております。JASAではOpenEL(Open Embedded Library)という規格を現在作っておりまして、OMGに参加して、ロボティクスDTFで活動しております。 JASAってETロボコンとかもやってらっしゃいますよね?     はい。既にETロボコンの開発キットとして弊社よりOpenELに対応しましたリアルタイムOS、およびOpenELのライブラリを配布しておりますので、ETロボコンの参加者の方は既にOpenELを使っていただける環境にあります。 […]

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の描き方、議論の構造に関してですが、よくコミュニティスタンダードの方でも出てくる「各ハザードに対して、それが対抗されている」といったような議論をかく事が多いのですが、実際には、それらは根拠資料の中に入っている事になりますので、それよりは、もう少しシンプルに、「こういう考えで全部に対して対抗されている」、ということであれば、その根拠資料だけを配置する、といったシンプルな書き方の方が良いと思います。 […]