ULTIMATE-SUBARU：
MBSEを用いたシステム仕様の策定
大野 良人、美濃和 陽典、本原 顕太郎、田中 壱、柳澤 顕史 （国立天文台)
第9回 可視赤外線観測装置技術ワークショップ 2020

この発表の背景と概要• すばる望遠鏡の次世代広視野近赤外装置を開発するULTIMATE-Suabruプロジェクトが進行中• 現在、科学要求からULTIMATE-Subaru全体のシステム要求・仕様を検討している• システムが巨大。望遠鏡の改修、補償光学、観測装置（MOIRCS、WFI、それ以外）、観測所など• 国際協力が必須。作成した仕様は共有しないといけない。
• どうやって仕様をまとめればいいか？

• 海外の協力機関からModel-Based System Engineering（MBSE) を紹介された。
• 今年の夏から専門家（企業）のコンサルティングを受けつつ、MBSEによるULTIMATE-Subaruのシステム要求・仕様の検討を開始した。
• この発表では、我々（素人）がこの数カ月でMBSEに関して学んだこと、困ったことなどを紹介。
• SEやMBSEをすでに活用している人、もしくは気になっている人と情報共有できれば。

そもそもシステムエンジニアリングって何？
システム検討製作・インテグレーション• システムの目的（ミッション要求）を実現するための工学的方法論（及び、その一連の活動）である。（JAXA：システムズエンジニアリングの基本的な考え方より）• 何か作るときに誰しもがなんとなくやっていることをちゃんと方法論としてまとめたもの。よく見るのはVチャート。
• 今回は左側のシステム検討についての話。
• システム検討の主なステップとしては• 要求定義 （科学要求、運用要求、制約の定義）• 要求分析 （上の要求を満たすために必要な技術的な要求に落とし込む）• 機能設計 （技術的な要求を実現するための論理構造に分解）• 物理設計 （分解された論理構造を実現するための物理・方式と仕様の設計）• システム、サブシステム、コンポーネント、・・・の各段階でこのステップを行う。
• 最終的に全体がつながっていることが大事。
システムズエンジニアリングの基本的な考え方 (JAXA)

Model-Based System Engineeringって何？
• SEの各ステップについてモデルや図を使って進めていくSEの一種• ユースケース図、振る舞い図、内部ブロック図、ブロック定義図、パラメトリック図など• MBSEのモデルはSysMLというUMLから派生した専用の言語（手法）に基づいており、実際にMBSEを進めていくためにはSysMLを扱うためのツールが必要。
• Cameo System Modeler、エンタープライズ・アーキテクチャ（EA）など• MBSEに期待していること。
• モデルを使うことで、トップの要求から各コンポーネントの仕様までの根拠の流れを可視化できる。
• 何か変更が必要になった場合、他のコンポーネントやシステムへの影響を把握しやすい• ちゃんとモデルを構築すれば、シミュレーションを行ってモデルの検証もできるらしい （残念ながら、我々はここまでできていない）

我々がこれまで進めたことやり方• だいたい週１ペースで我々5人と専門家の合わせて6人で6時間作業＋議論• それにプラスして、週１で我々5人で集まって2-3時間の内部議論、宿題を進める。
• パワーポイントなどを利用して議論。実際にツールを使ってモデルを作るのは一人。
• だんだん進むに連れて、宿題量が多くなってきた。
実際にやった作業• 科学要求の一部をトップレベルのシステム要求に落とし込んだ• ライフサイクル（製作、組み立て、輸送、運用、メンテナンスなど）の各ステージでの要求・制約を洗い出している最中• 観測に対するシステム要求と振る舞いから、トップレベルのシステムの論理構造を考え、それを実現するための物理構造（サブシステム）と仕様を検討した• トップレベルのシステム検討で出てきたサブシステム（GLAO、WFI）について同様のシステム検討を進めた。

科学要求からシステム要求へ• サイエンスチームによってまとめられた”Science Requirement Document”から科学要求を抜き出し、システム要求に落とし込んで、要求図としてモデル化した

要求図
科学要求

システム要求ライフサイクルの各ステージでの要求• 設計•

各ステージで誰がどのようにULTIMATE-Subaruを使うか？（ユースケース図）

• 製作

•

そのための要求は？ 例えばインターフェイス要求など•

科学要求はライフサイクルのうちの運用の中の観測に対する要求• 組み立て試験• 輸送
ライフサイクル• ハワイまでの輸送• 山頂までの輸送• 取り付け（望遠鏡への取り付け）• コミッショニング、試験観測
• 運用
• 観測
• メンテナンス・修理• 山頂山麓間輸送• 装置交換

• デコミッション

ユースケース図観測のユースケースについての振る舞い• ”観測”というユースケースに対して、振る舞い図を書いてみる。

• ”観測”を実現する上で必要な振る舞いは？
• 各振る舞い間でやり取りされるパラメータは？
• ”観測”の振る舞いに対して、外から入ってくる情報と外にアウトプットされる情報は？

振る舞い図

振る舞いを実現する機能を検討• 振る舞いを実現する機能を考える。システムを論理的に構築していく

機能に対するブロック定義図

振る舞いを実現する機能を検討• 各機能のつながりとその間にやり取りされているものを内部ブロック図で表現
機能に対する内部ブロック図

振る舞いを実現する機能を検討• 各機能のつながりとその間にやり取りされているものを内部ブロック図で表現
機能に対する内部ブロック図

振る舞いを実現する機能を検討• すべての振る舞いが検討した論理構造でカバーされているか確認
Allocation Matrix

物理構成の検討• 機能を実現する物理構造を検討する
物理に対するブロック定義図

物理間のつながり• 各物理の間が何で繋がっているかを物理内部ブロック図で整理。
• 機能の内部ブロック図と合わせることで、各物理間がどのように繋がっていて、何がやり取りされているかが決まる。

物理構成の検討• 機能を実現する物理に割り当てる

物理構造

論理構造

機能から物理への割当

物理仕様の検討• 機能に割当てられてたシステム要求を実現するために必要な各物理システムの仕様を検討する• パラメトリック図でその間の関係を明確にする.
• ここで決定された仕様を基にサブシステムのシステム検討に進む

パラメトリック図これまでMBSEをやってみて• モデルを作ること自体に意味がある• モデルや図にすることで理解が深まる、全員で認識を共有できる• ついつい後回しにしてしまう、運用面などにも意識がいく• システムの理屈がちゃんと形に残る• 今後作成したモデルをどう使うかは、まだわからない• 設計や仕様の裏付けとしての補足資料• 図はレビューの書類などで使えるか？
• 外部の協力機関との情報共有に使える？

• コツをつかむまでには時間がかかる• 論理構造と物理構造（目的と手段）の切り分け、論理的思考でシステムを考えることが重要• 観測のオペレーションなどは細かいところまでわかっている分、ついつい細かい点に意識がいってしまう。
• ついついモデルをちゃんと作ることにこだわってしまう。
• どこまでモデルにすればいいのかわからない。
• なんのためにMBSEを使うのかを意識するのが大事。（しかし、この感覚をつかむには時間がかかる。。。）• 客観的に見てくれるファシリテーターは必須

まとめ• ULTIMATE-Subaruプロジェクトのシステム要求・仕様の検討手法としてMBSEを使っている• 今年の夏から、専門家のコンサルティングのもと作業を開始• 一通りのプロセスを経験したが、まだまだ勉強が必要な点も多い。今後は質の向上が課題。
• 詳しい人、興味のある人と情報共有できれば嬉しいです。