システムの統合化(3)モデルベースのシステム工学(MBSE)その1

「システム工学(system engineering)」なら、防衛装備品の業界をはじめとするさまざまな分野で当たり前のように用いられているが、それとMBSE(Model-Based System Engineering)は、いったい何が違うのか。

前回の内容を受けて、急遽、連載に加えることにしたのが今回のテーマ。

「システム工学(system engineering)」なら、防衛装備品の業界をはじめとするさまざまな分野で当たり前のように用いられているが、それとMBSE(Model-Based System Engineering)は、いったい何が違うのか。→連載「軍事とIT」のこれまでの回はこちらを参照。

システム工学とは

システム工学とは工学の一分野で、システムの設計、制御、効率などについて研究する学問である。この言葉は、航空宇宙・防衛産業界では頻出しているし、米国防総省の契約情報でもしばしば「システム工学業務の契約」が出てくる。

一つのシステムを構成するためには、さまざまな学問分野や技術が関わり、融合する。そして防衛装備品の分野に限ったことではないが、各種のシステムは高度化・複雑化の一途をたどっている。

大規模で複雑なシステムを構築するための、研究開発・試験・評価といったプロセスでは、多大な時間と手間と経費を要している。大規模で複雑なSystem of Systemsを構成するウェポン・システムの代表といえるF-35が、計画の立ち上げから実戦配備までにべらぼうな時間と経費を要したのは、その典型例といえる。

しかも、システムの構築に際しては、まず運用側の要求に対する分析が十分に、かつ適切になされている必要がある。それが不十分なまま話が進んでしまうと、要求された機能・能力を適切に備えていない「出来損ない」ができてしまう。

また、要求の変更に適切に対処できなかったり、試験の過程で発生した不具合に対処しようとして大きな手戻りが発生したり、といったことも起こる。

全体最適化を図るために考案されたMBSE

今のウェポン・システムはライフサイクル全体を通じて改良が続く、いわば「永遠の未完成品」である。曲解する人が出るといけないので念を押すと、この場合の「未完成」とは、以下のような意味だ。

「最終的な完成状態といえるものが存在せず、常に進化を続ける」

すると、システムの要求・設計・分析・検証・妥当性確認といったプロセスは、構想段階から始まり、ライフサイクル全体を通じて回し続ける必要がある。

そこで、システム構築を成功に導くとともに全体最適化を図る観点から、MBSEが考案されたのだという。

モデルというと一般的に想起されるのは、コンピュータ・シミュレーションのための数値モデルだろう。前回に少し言及したデジタル・ツインも、そうしたモデルの一つといえる。これは実在するモノを数値化する「解析モデル」である。

システム工学ではそれに加えて、論理的な構成や関係性について記した「記述型モデル」も登場する。そしてMBSEでは、「解析モデル」と「記述モデル」の両方を使って構築するシステムの全体像を作り上げるとともに、開発に携わる関係者の間で理解を共有することを企図している。

要求事項を起点とする二元V字モデル

MBSEにおけるキーワードが「二元V字モデル」。

• 

  二元V字モデル　引用：IPA「モデルベースシステムズエンジニアリング導入の手引き」

まず、システムを構成する個別のサブシステムを仕上げてから、それらを組み合わせてシステム全体を構築するという考え方もある。しかしそれでは、部分最適にはなっても全体最適になるかというと怪しい。

そこでMBSEでは、逆のアプローチをとる。まず、システム全体を俯瞰して、要求事項を実現するためにどんな機能・能力が必要なのか、というところから話を始める。

この段階では、抽象的な形で全体像をまとめることになる。これから構築しようとしているシステムは、まだ「こういう機能・能力を実現する」ことが分かっているだけで、中身はいってみればブラックボックスである。

そこから掘り下げる形で、求められる機能・能力を実現するために必要となる「サブシステム」「コンポーネント」の話に切り込んでいく。これは「V」の字の左半分である。

実際に何をするかというと、システムのコンセプトやアーキテクチャ、個々のサブシステムごとの機能や振る舞いの定義、ハードウェアとソフトウェアへの分割、といった具合に作業を進める。

次に、それを実際に開発・実装して、組み合わせていく。つまり、「コンポーネント→サブシステム→システム」といった順番で開発・実装を進めて、統合していく。最終的に、すべての構成要素を組み合わせた完成品のシステムができあがる。これは「V」の字の右半分である。

初っ端から「この技術を使う」「このハードウェアを使う」「このソフトウェアを使う」という話を先行させるのではない。そもそも論をいえば、技術にしろハードウェアにしろソフトウェアにしろ、要求された機能・能力を実現するための手段である。技術やハードウェアを使うこと自体を目的にするのでは本末転倒だ。

関係者が共通言語を持って関係性を理解すること

システムの構築によって機能・能力を実現する過程では、さまざまな構成要素が関わり、互いに影響し合う。その関係性について、関係者全員が共有・理解することが重要になる。つまり「共通言語」を持つ必要があり、そこで前述の「記述モデル」が登場する。

そうしないと、開発の途中で要求や仕様の変更が発生したときに、それがどこにどう影響するかを見通すのが難しい。もちろん、変更・変化に関する記録を残すことも重要である。

そうしたプロセスを実現するソリューションを手掛ける企業の一つに、ダッソー・システムズがある。同社は2018年に、MBSEやモデリング・ソリューションを手掛けているNo Magicを買収、自社のプラットフォームにNo Magicのソリューションを取り込んだ(これ自体も一つのシステム構築といえよう)。ユーザーとしては、BMW、ロッキード・マーティン、ティッセンクルップ・マリン・システムズ(TKMS)などが挙げられるそうだ。

いろいろ書いていたら話が長くなってしまったので、続きは次回で。