9月1日(水)、チェンジビジョンとしては久しぶりのオンラインセミナーを開催しました。7月から無料公開しているダウンロード資料「astah* System Safety 利用イメージ MBSEと、安全分析から論証のサンプル」を教材に、掲載されているサンプルモデル図の中からいくつかを取り上げて詳しく解説するものです。解説と質疑応答でおよそ一時間のセミナーから、始まりとまとめの部分をレポートとしてお伝えします。
セミナーの目標と事例
今回のセミナーではMBSEに関心のある方、MBSEの知識があり実践のポイントを掴みたい方を対象としました。セミナーに参加することで、MBSEの流れや実際のモデルの使い方のイメージが湧くことが目標です。事例として、皆さんの暮らしに身近な家電を取り上げ、電気ポット（電気ケトル）を開発するプロジェクトを想定しています。ご自宅に電気ポットがある方も多いかと思いますし、日々の暮らしに近い製品ですと具体的なイメージを持ちやすいですね。
始まりを見てみよう
モデリングをするための枠組み
電気ケトルを開発するにあたって様々な技術者が関わっていることは容易に想像できます。役割としては、ユーザーからの要求を分析する人が居るでしょうし、熱湯を扱うことから安全への考慮が必要ですし、電気で温めるため電気の技術者なども必要です。
各関係者の関心事の異なりと、モデルに必要な観点の検討
開発プロジェクトに関わる技術者は、それぞれ関心事が異なります。例えば、要求アナリストはユーザーがシステムを使う際の視点を持つでしょうし、ソフトウェア技術者はそれが動作する環境に関心があります。モデリングは対象を抽象的に記述すること、抽象化は情報を切り落としていくことでもあります。残した情報で関係者の関心事確認できるか、表現できるかが妥当性の根拠にもなるので、こういった検討をします。
この後は、五つにまとめた観点をUAF®（Unified Architecture Framework®）を用いてモデル構造に反映し、ブロック定義図や内部ブロック図、ステートマシン図といった各図を解説する時間となりました。
解説されたサンプルモデル図
- ブロック定義図
- 内部ブロック図
- ユースケース図
- シーケンス図
- 要求図
- アクティビティ図
- STPA コントロールストラクチャー図
- STPA UCA表
- ステートマシン図
まとめ
最後に、MBSEの基本的な流れをまとめて終了となりました。
質疑応答
質疑応答では3名の方からそれぞれご質問いただきました。各回答にボリュームがありますので、文章にまとめてみました。
Q. SCDLやGSNはどのような目的で活用できますか？
A. SCDLはSafety Concept Description Languageで、安全設計を書くためのモデリング手法です。主に、ISO26262、自動車の機能安全の分野でコンセプトレベルでの安全要求をまとめるための方法論としてSCDLが提案されていて、日本では使われています。もちろんISO26262だけではなく、他のシステムの安全設計でも使えます。ポイントは、単位が機能になっていて、機能間でどのようなインタラクションがあるかを書けるところです。SysMLの場合は、機能に対するアロケーションを書く場合、別の図に移って、アロケートの矢印でハードウェアとロジカルな機能をつなげる書き方になりますが、SCDLでは一枚の図で割り付け先を後ろに置いて、それが実現する機能を前に書くという表現ができます。もう一つのポイントは、ISO26262の重要な概念であるASIL（Automotive Safety Integrity Level）、システムを安全に開発するときにその安全性にも度合いがあるでしょう、というある種の安全度レベルをシステマティックに記述できることです。例えば、自動車を考えてみるとブレーキとパワーウィンドウの危険度には違いがあり、どの程度の開発コストを必要とするかも異なるでしょう。厳しい安全度で開発しなければならないが、冗長化したときには少し低い安全度での開発が可能であるというASIL Decomposition（ASIL分解）もシステマティックに記述する表記法があります。
STAMP/STPAのコントロールストラクチャー図と多少役割が重なる部分がありますが、コントロールストラクチャー図ではより上位の要求レベルでの安全の達成の仕組みを書きます。一方、SCDLではコンポーネント単位でどの程度のコストをかけて開発するかを決定するという役割分担があります。
GSN（Goal Structure Notation）は、要求も一つのゴールですが、ゴール一般の構造を書くための表記法です。主には安全分野での論証を書くために使われます。システムの安全性について、かつては規格を全てクリアしていることを表すために表のチェックで進めていました。GSNは、安全について我々はこのように考える、その考え方に基づいて試験やレビュー、テストといった活動をした、その結果、このシステムは安全であると言えるというような論証構造を書くための表記法です。ISO26262の認証でも使いますし、個別の開発プロジェクトで目的や活動を合意するために使われてもいます。
Q. 電気ポット（電気ケトル）本体が倒れてもあふれない、といった安全設計はどう書くと良いでしょうか？
A. 電気ポットが倒れるというのは、ハザードの一つだと思います。ハザード分析によって何らかの対応をしなければならないと分かった後で、例えば、底面を広くしたり脚を付けたりといった全体構造を倒れにくくする方法が考えられます。他には、（この資料で書いている）倒れても水がこぼれないような安全弁をロック機構とは別に用意するなどです。構造として倒れない形も、安全弁も、安全を担う構成要素の一部ですので、コントロールストラクチャー図に反映して、まずそういった要素が必要であることを明記した上で、ソフトウェア技術者やハードウェア技術者から見たときにどう実現するのが良いかを検討します。ハードウェアで実現する場合は構成要素を追加し、倒れない度合いを数値化できるなら本体の制約としてそれをブロックに記述します。SysMLの大きな特長として制約の記述があり、各ブロックに対してパラメーターを定義したり、パラメーターが満たさないといけない範囲、パラメーター間の関係も定義できるようになっていますので、倒れない構造のためのパラメーターの範囲などを記述しておけば良いと思います。
Q. 五つにまとめられた観点の基準は何でしょうか？
A. 今回ご紹介したUAF®（Unified Architecture Framework®）で言うと、各観点で詳しい説明があり、ステークホルダーから、どういう関心事（Concern）を表現しているのか、どのモデルで表現するのかが説明されています。UAFだけではなくて、ISO規格やIEEE規格でも観点が定義されています。（ここで、ISO/IEC 30141: 2018 Internet of Things (IoT) Reference architecture、IEEE Std 2413-2019 IEEE Standards for an Architectural Framework for the Internet of Thingsが紹介されました。）
リファレンスとして使えるものがいくつか公開されていますので、そういったものを確認してから、自分たちにはどれが必要か、自分たちが持っているConcernはどれによって表現できるかを考えていくのが良いのではと思います。
今回の事例では、まずは使用、機能、実装の観点を定めました。これは、大きく、要求アナリストが利用者視点で記述する使用、ソフトウェア技術者が、自分たちの開発するソフトウェアの仕様を記述する機能、ハードウェア技術者や電気など各分野の技術者の視点を表す実装のそれぞれの観点が必要になると考えたからです。次に、安全性をどのように表現するか検討しました。一つの案として、安全性は、使用、機能、実装それぞれに安全の議論が必要であるため、それぞれの層に分散して記述することも考えましたが、それらを統一してみられる視点が必要との考えから、独立した安全性の観点を用意しました。同様に、要求についてもステークホルダー要求やシステム要求、ソフトウェア要求という分け方があるため、既存の観点に分散して記述することも考えましたが、機能や実装の層においては、必ずしも自然言語による要求の記述が必要な場面が必要ではないことから、あえて分散させずに、必要な箇所だけ自然言語で記述したモデルが統一的に確認できる視点として独立した要求の観点を用意しました。
ビデオも公開中
具体的なモデル図を目にしながらMBSEの流れを追っていくことのできる本セミナーは、ビデオを公開しています。どなたでも、いつでも、どんな場所でもご覧いただけますので、ぜひ資料のダウンロードと合わせてご活用ください。
astah in 5 min 