モデルベース・システムズエンジニアリング (MBSE）の進め方

最近、いろいろなところで、いろいろな会社の人から、モデルベース・システムズエンジニアリングの相談を受けます。そして、すごく多いのが、「Sysmlを使って書いてみたんですけど・・・・」という相談です。
いつも、「ん？」と思うのですが、あまりにも多くこのような話の持ってこられ方をするので、「なんでこんなことになっているんだろう」と不思議に思ってしまいます。
もちろん、「モデルベース・システムズエンジニアリング」というからには、「モデル」を活用した「システムズエンジニアリング」であることには違いないのですが、システムは多様ですし、その設計のアプローチも多様なので、そんなに単純にはすすみません。
自分としても、エアバス社（当時のダイムラークライスラーエアロスペース、後のEADS Astrium社）に駐在していたいときに、モデルベースシステムズエンジニアリング（MBSE）を立ち上げたメンバーの一人だったので、その立ち上げのときの苦労とアプローチをはっきりと覚えています。（ちなみに、そのエアバス社は、SysMLを作ったメンバー会社の一つです）
では、当時はどんな議論からはじめていたかというと、まずは、何のためにモデルベースシステムズエンジニアリングをおこなうのか、という点です。コスト削減のためなのか、スケジュール短縮のためなのか、あるいは品質向上のためなのか、目的によって、そのあとの検討が全くかわってきますので、まずはそこを明確にしました。もちろん、自社の戦略ははっきりしていますので、ここではそれほど時間がかかりませんでした。
次におこなったのが、では、開発プロセスの中で、どこをどのような（抽象度の）モデルにすれば、その目的を実現できるかの検討でした。これは、開発プロセスを明確にし、どこでどのようなモデルがあれば、よいか、そのためにはどのような情報が必要なのか、といったことを一つ一つ検討し、ライフサイクルを通じてシステムモデルを活用することで上記の目的が実現できるモデルベース開発をデザインすることでした。つまり、現在モデル化をしていない何を、どのようなモデルにするか。あるいは、現在すでにモデル化をしている何を、どのようなモデルに変更するかを考えることです。目的を考え、このモデルベース開発のアプローチをデザインすることだけで、ほぼ１年を有しました。
その後、どのようなモデルを活用するか、とうことを考え始めたのですが、適切にシステムモデルを標記するための記述法がなかったために、SysMLを作る方向に進みました。
ちなみに、結果として、当該部署ではSysMLは使わないこととなりました。あまりにも汎用的すぎて、目的のためには”Too much"だったようです。
もしモデルベースシステムズエンジニアリングをはじめたい方は、もちろん、SysMLの勉強として、いろいろなものをSysMLの標記法で書いてみるのはいいですが、本格的に進めるためには、やっぱり上記のようなことをしないと単に書いてみただけで、目的に適合しない活動になってしまうようです。
でも、そのためには、まずはシステムズエンジニアリングを理解しないと検討すらできないという問題点にぶつかってしまう場合も多いのですが。。。。

インダストリー4.0リファレンスアーキテクチャモデル:RAMI4.0

ドイツが国をあげて進めているインダストリー4.0ですが、その実行の中心的な役割をになっている「インダストリー4.0プラットフォーム」が、「インダストリー4.0の実装戦略 (Implementation Strategy 4.0)」を発表しました。（ドイツ語では、「Umsetzungsstrategie Industrie 4.0」となっています。）
この中でとても興味をひかれたのが、「Reference Architecture Model Industrie 4.0（RAMI4.0）」という「インダストリー4.0リファレンスアーキテクチャモデル」です。


（出展：Umsetzungsstrategie Industrie 4.0）
見た瞬間に、「あ、またこのパターンできたか」という風に感じましたが、まさにCEN-CENELEC-ETSIのSmart Grid Coordination Groupがつくった、Smart Grid Reference ArchitectureにでてくるSmart Grid Architecture Model (SGAM) Frameworkにそっくりな形態となっています。

RAMI4.0をみてみると、「Life Cycle&Value Stream」と「Hierarchy Levels」で平面をつくり、そこに縦軸として「Layers」を配置しています。
「Life Cycle&Value Stream」では、IEC62890「産業用プロセス計測・制御・オートメーションにおけるシステム・機器に関するライフサイクルマネジメント」をベースとしているようです。SGAMでは、「Domain」にあたる軸ですね。「SGAM」では、ライフサイクルというよりもValue Streamというほうが適切で、発電してから末端の機器にいたるまでの流れになっています。RAMI4.0では、大きく「Type」と「Instance」にわけ、「Type」の中が「Development」と「Maintenance/usage」に、「Instance」の中が「Production」と「Maintenance/usage」にわかれています。
「Hierarchy Levels」は、IEC62264/61512から構成されています。IEC62264は、企業の経営と制御システムとの統合を目指す標準「Enterprise-control System Integration」となっています。これと「バッチ制御」の標準であるIEC61512を組み合わせ、インダストリー4.0用にいくつかを追加したものとなっています。


（出展：Umsetzungsstrategie Industrie 4.0）
これはSGAMで「Zones」という名前でいわれていたものと同様で、奥にいくほど、より上位の概念となるようになっています。
「Layers」は、ほぼSGAMの「Interoperability Layer」を踏襲したものとなっていますが、最後の層がSGAMでは「component」だったのが、「Integration」と「Asset」となっているます。


図Smart Grid Architecture Model (SGAM)
個人的には、SGAMも、RAMI4.0もこの縦軸はいまいちかなぁ〜と思っています。
というのも、情報というのは、決して、「Function」の下だけにあるものではなく、「Function」の結果としての「Information」を「Business」がつかうこともあるので、「Information」をどこかの層にいれてしまうと、誤解をあたえてしまうからです。その点では、DoDAF2.0 (DoD Architecture Framework)はよくできていると思います。DoDAF2.0では、データやインフォメーションは、あらゆるレベルで使われるため、すべてのレイヤーに共通なものとして用意されています。

図 DoDAF2.0のViewpoints
但し、DoDAFは、時間と空間の概念をFrameworkのレベルにいれていないからできているのですが。
本質的にはこちらのほうが正しいかと思っています。

詳細は、上記のような懸念点はあるにしても、俯瞰的に捉えるArchitecture Reference Modelとして、時間x空間xEnablerという組み合わせでつくるのは有効なようですね。

MIT Oliver deWeck教授によるProduct Family Workshop

今年も、MITのOliver deWeck教授によるProduct FamilyのWorkshopを開催いたしました。
このWorkshopは、MIT SDMでは、５日間に渡り、数十万円の費用を払ってうけるものを、慶應SDMで１日に短縮して実施してもらっているものです。



このワークショップは、３つの異なるタイプの車をレゴで効率よく作るためにProduct Familyという考え方をいかに活用するかをビジネスゲームを通じて体感的に理解できるものとなっています。
学生たちは、製造グループ以外に、サプライヤー、カスタマーの役割も分担して、多視点からこの活動を見ることを促すやり方となっています
今回もかなり早いスピードの授業でしたが、分かりやすいdeWeck教授の英語と説明で十分にそのエッセンスを理解できたことと思います。