メディア

システムズエンジニアリングの魂を入れた「MBSE」アプローチとは超速解説 MBSE(2/2 ページ)

» 2018年04月13日 09時00分 公開
前のページへ 1|2       

ドキュメントベースとモデルベース

 ここまで、システムズエンジニアリングの説明をしてきました。ここからは、新しい時代におけるシステムズエンジニアリングに対応するMBSEの話に移ります。

 モデルベースとは何か? ということを考える際、必ず対となる反対概念であるドキュメントベースが語られます。「ドキュメント」とは、もともと要求項目や設計情報を記録し、他の人たちに伝えるというコミュニケーションを目的として作成されてきた文書です。

 ところが、このドキュメントベースというものには幾つかの問題点があります。1つは、ドキュメントには恣意(しい)性があり、人によって書き方や読み方が異なるという点です。次に、設計/開発情報はさまざまな領域にまたがり、蜘蛛(くも)の巣のようなネットワークでつながっているにもかかわらず、ドキュメントベースでは1ページずつ見ていく必要があるため、全体像がつかみにくいという点も挙げられます。さらに、外的または内的要因で設計変更が発生した際、1つの変更に対し何百ページものドキュメントの中にある関連する全ての情報を適切に書き換える必要があり、変更漏れや間違いが発生しやすいという課題もあります。

 これに対し、文書の代わりに「モデル」と呼ばれるものを中心に作り、関係者全員がそのモデルにアクセスし、共通のモデルをアップデートしながら、最新のモデルを使って業務を遂行するのがモデルベースのアプローチです。

モデルベース vs. ドキュメントベース モデルベース vs. ドキュメントベース

 一般的に“モデル”というものは文書ではなく、“抽象的な概念”と考えた方がよいでしょう。抽象的な概念を特定の視点から見た断面で表現したものが、“図(ダイヤグラム)”です。

 図同士は無関係なわけではなく、Webサイトのようにお互いの情報がひも付いています。そのため、1ページずつ読み進めていくドキュメントベースと比較し、全体像が把握しやすくなっています。変更が発生した際も中心にあるモデル自体に修正を加えるため、関連ドキュメント全てに変更を加えるといった手間や、変更漏れなどの問題はなくなります。

モデルベースのための標準言語SysMLとモデルを理解するための図の関係

 モデルベースでは、さまざまな領域の人が中心にあるモデルにアクセスし、情報をアップデートすることになります。その中で、これまで別の領域で仕事をしていた人たちとコミュニケーションをする必要が出てくるため、標準言語が必須となります。

 現在、標準言語として主に使用されているのが、2006年にOMG(Object Management Group)によって仕様が策定された「SysML」です。この国際標準の共通言語、SysMLを使用してモデリングを行うことにより、まるで違う領域で仕事をしてきた人同士でも、表現されたダイヤグラムに関してお互いに正しい解釈ができるようになります。

SysMLのダイヤグラム例と情報のつながり SysMLのダイヤグラム例と情報のつながり ※クリックで拡大

 このSysMLを導入し、MBSEによる設計を進めていこうとする際に考えるべきポイントが3つあります。1つ目は、言うまでもなく言語習得。2つ目は、SysMLでのモデリングをサポートするツールをきちんと使用することです。そして、3つ目が方法論(メソドロジー)です。この3本柱をバランスよく育てていくことが大切です。

 モデルというものは、非常に抽象的なものです。図の中には静的な構造を表現するものもあれば、動的な振る舞いを表現するものもありますが、これらの図の奥にある抽象的なものがモデルなのです。モデルを理解し伝達するために、ある側面を切り出して図を作成するのです。例えば、「シーケンス図」はシステム要素とシステム要素との間に、どのような順番でメッセージやサービスがやりとりされて、どういう結果を戻してきているのかという“流れ”を時系列的に表現するものです。

シーケンス図の例 シーケンス図の例

 ここで、「SysML全体を使うのが難しいからシーケンス図だけ使おう」「図だけなら『PowerPoint』でも描けるからモデリングツールを使わずに図だけを作成しよう」というアプローチが散見されます。これではモデルの1つの側面を見ているにすぎず、モデルの全体を見ていることにはなりません。“モデルベースの顔をして、ドキュメントベースをやっている”ことになり、振り出しに戻ってしまいます。これらの図はモデルの実体ではなく、モデルの1つの側面に過ぎません。

 とはいえ、下請けやパートナー企業とのコミュニケーションの中で、ドキュメントのやりとりが必要になる場合もあり得ます。モデルベースになると、ドキュメントはなくなってしまうのかというとそうではありません。きちんとしたモデリングツールを使っていれば、モデルからドキュメントを生成できます。これまでのドキュメントベースではドキュメントが第一次生産物でしたが、モデルベースでは作られたモデルから自動的にドキュメントが作られます。人間はモデルを良いものにすることに注力するだけで、ドキュメントの生成に労力を費やすことはなくなります。こういったアプローチで仕事をするのがMBSEです。

MBSEにおける今後の課題

 ところで、自動車をSysMLで設計しようとしたとき、言語自体が“汎用的過ぎる”という課題もあります。

 そこで、自動車用の「DSL(Domain Specific Language)」の標準化の動きがあります。この言語対応については、技術的にはきちんとしたモデリングツールを使用していればプロファイルの拡張で対応が可能です。しかしながら、DSLの活用できめ細かい自動車のモデリングが可能になる半面、標準にのっとったSysMLであれば世界中どこでも通用するのに対し、リファインしたモデリング言語(DSL)では通用しない可能性もあり“もろ刃の剣”ともいえます。

 設計のためだけにSysMLを使い、自動車業界で閉じているときはよかったのですが、冒頭に紹介したような自動運転環境の世界では、他の領域とも協調していかなければなりません。せっかくのMBSEが、システムズエンジニアリングのテーマの1つであるInter Disciplineを損ねるようでは、“魂の入らない仏”のようなものです。真の意味でのシステムズエンジニアリングの実現において、MBSEでの設計における今後の課題といえるでしょう。


前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.