4本目＿MBDを使うということ①
さて、前回の投稿では私の恥ずかしい失敗談を掲載しましたが、いかがでしたでしょうか？
当時の失敗でトータル数千万円が半年で溶けてしまったと思うとなかなか恐れ多いのですが、そこから色々と挽回したので今となってはクライアントとは冗談混じりで話せるぐらいには何とかなっています。（何とかなっていると思いたいです…）
ではでは、前回の失敗談についてお話しすると、実は根本的なところから過ちがあったと言えます。
まず依頼の初めにあった内容に関して、「モデルを作ってある特定の現象を再現する」という箇所に関してスタートが間違っていることにお気づきでしたでしょうか？
そもそも、特定の現象を再現するのであれば物理モデルを作成する必要はなく、マップやマップを使った物理計算モデルで十分再現されます。でも、それはモデルベースとした開発ではなく、単にValidation(検証)したモデルを動かしただけになります。そこで当時の私はとにかく物理現象を再現できるようにとモデルを作成したのですが、その裏に何を解決しないといけないのかを理解せずに思い込みのまま作成したことが問題だったのです。
昨今のビジネス書にある、論点思考における「問い」の設定が甘かったが故に発生した事だと言えます。
では、何を初めにすべきだったのでしょうか？それは、「モデルをどんな開発に使うのか？」を明確にすべきだったという事です。
どんなシミュレーションもそうなのですが、ある程度の現象は地球上のもので古典物理の範囲であれば再現はできます(相対性理論などの現代物理に関してはどこまでできるのかは専門外なのでご勘弁を)。ただ、そのシミュレーションをどのように次へ活用できるかを認識していなければそれはただの「同じ動きしかしないもの」でしかありません。
モデルベース開発は、その名のとおり開発に活用できなければ意味がなく、ゴミ同然です(実際、ゴミになってしまっていましたが…)。それを避けるために導入を検討している会社においては、自社の製品開発におけるどんな段階で何をVerification(検証)したいから現物ではなくシミュレーションをすることで効率化が図れるのかを理解して活用していただきたいです。
※ちなみに、少し言葉の定義としてお伝えすると、私の文章中には「検証」の使い分けの英語として"Validation"と"Verification"で表現したいと考えております。"Validation"は主にモデルそのものの整合性を確認する。つまり、作ったモデルが検証データと同じ結果を出せることでそのモデルの正当性を示したものを言います。一方で"Verification"は前述のとおり、整合性を取れてモデルを使ってパラメータスタディを実施して最適値を効率よく求めることになります。あえて英単語で表現されている場合はこれらを意識していただければと思います。
3本目＿MBD導入失敗事例①
いきなりですが、私が携わった過去のプロジェクトで起こったMBDの導入失敗事例に関してお伝えします。
“え、いきなり失敗事例！？”っと、思いかもしれませんが、失敗から学べることは多々あります。むしろ成功したものを説明するとそちらが一人歩きしてしまう可能性があり、魔法のような技術だと勘違いされるのを避けるためあえて失敗事例をお伝えしたいと思います。
そして、その失敗から何をすれば成功に導けたのかを次の記事で説明したいと思います。（今回の記事より、何が駄目だったのかを考察していただくことも狙いとしてあります。）
私がMBD導入を知り始めた20XX年、某自動車会社で1Dシミュレーションを使った車両全系モデルを作成して欲しいというプロジェクトを受注いただき、当初の自分はとにかく現存データでモデルを作成することに集中しました。なお、初めに再現したかった現象は車両のある加速性能となります。
そこで作成したモデルは以下となります。
①エンジンモデル
→筒内の燃焼を加味した詳細物理モデル（燃焼の広がりを検討しながらピストンへの圧力を計算し、トルクを算出）
→マップモデル（ある入力値、例えば噴射量をエネルギー換算し、そこからの内部損失を加味して最終的にトルクにするためマップを使い計算）
②車両全系モデル
→上記のエンジンに繋ぐためのトランスミッション(ギア変速の条件によって可変する値を損失エネルギーに掛け合わせたもの)、タイヤ(摩擦係数一定の簡易摩擦モデル)、車両(車体を一つの剛体とみなしたもの)、制御(ドライバーアクセル踏み込み量から各指示値をマップで算出)、ドライバー(目標車両速度、実車両速度の乖離からアクセル踏み込み量をマップで算出)を繋げたモデル
上記のモデルを検証(Validation)し、現象としては再現性のあるモデルを作成できたと意気揚々と成果物として提出しました。
…っが、結果としてこのモデルは開発に使われることなく終わってしまいました。
さて、このプロセスの中で何が考慮不足だったでしょうか？
2本目＿MBD、MBSEの定義(簡易版)
さて、今回のブログを進めて行くにあたり、言葉の定義をここで実施しておきたいと思います。（なお、この回ではまずは導入として簡易的な説明とさせていただき、回を追うことで正式な定義の説明をしてゆきたいと思います。）
MBD…Model Based Developmentの略
世の中にはDを“Design”とする内容もありますが、DesignはあくまでDevelopmentの一部だと考えていますのでこのブログでは上記の訳詞で統一します。
MBDを簡略化した形で説明すると、「あるモデルをシミュレーションを使って開発をすること」と言えます。
では、シミュレーションとはどんなものがあるのか？
- 3Dシミュレーション…字の如く、3次元空間を用いたシミュレーションで空間的要素を含む物理演算が実施できるもの。（一般の方々が想像する”シミュレーション“はこちらが大きいかと思います。）
- 1Dシミュレーション…エネルギー保存を原則とした各要素に対する物理演算、言い換えればエネルギーがどんどん各要素で交換されてゆく(1次元方向)有様を表現したシミュレーション（MBDで使われるシミュレーションは現在こちらが多くなっていると思います。）また、某ソフトウェア会社が仰っているように制御モデルも指示系統の1方向性を記述したものになりますので1Dシミュレーションとみなすこととします。
ただ、注意していただきたいのは今後の内容でも掲載しますが、いづれの計算においても完璧なシミュレーションは現代技術ではまだ到達できていないこと、よって必要に応じて双方（3D,1D）のシミュレーションをそれぞれ使い分ける必要があるということに今のところは留意していただければと思います。（なぜ完璧な計算ができないかは別途お伝えします。）
MBSE…Model Based System Engineeringの略
モデルベースとした「システム」レベルでのエンジニアリング、要はシミュレーションでシステム開発(車で言えばトランスミッションやエンジンという括り。ただし、自動車会社なのか部品会社なのかでこの”システム“の括りが異なることに注意する)をするということ。
これまでのエンジニアはある特定の部品開発で要求仕様を満たせれば良かったが、MBDを使うことでより上位のシステムとしてのエンジニアもできるようになるということ。（つまり、部品開発者が部品だけの耐久性だけでなく燃費まで検討できる仕様までモデルを使って考えれるようになるということ）
次に、上記２つの関係性に関して言及しておくと、MBSEの中にMBDが包含されているという関係になります。その理由として、MBDはモデルを使った開発であり、それを活用してシステムズエンジニアリング(＝SE)するということから、あくまで包含関係としてあると認識していただくのが良いかと思います。
また、これも認識していただきたい一つとしてMBSEと MBDは両方とも「手段」でしかないということに注意して下さい。よって、戦略的な検討もせずに導入するだけでは確実にただの宝の持ち腐れになりますしお金をかけたのに製造業におけるVモデル開発の改善がうまくいかない．．．っという結果になるのは目に見えている(私は見てきました)ので、是非導入したいと考えているのでしたら自社の開発を見て、どのように導入することでうまくいくのかをしっかりと戦略立てて対応していただけると幸いです。（後々ですが、その導入方法に関しての戦略的な考え方なども掲載します。）
今回は定義とその関係性に関してまとめました。
1本目＿このMBDブログを書く覚悟
まず初めに、私がこのブログを書くきっかけになった内容に関して説明します。
私は某自動車会社と某シミュレーション会社にトータル10年近く在籍し、設計→制御→制御シミュレーション→物理シミュレーションという経験から実開発とシミュレーションを使った開発の両方の視点を有しています。
その結果、経歴の後半では車両の全体を異なる詳細度でモデル化（今後は「車両全系モデル」と統一させてください。）するまでの経験を得ることができました。
その経験から、MBDは単に制御だけでも物理モデルだけでも成り立たない、つまり双方のモデル（つなぐためのアクチュエータも含む）が繋がってシステムエンジニアとして車がどのような挙動を取るかを理解することができるという事が分かった時にこの上ない満足感を得たことを覚えています。
昨今のMBDはどうしても制御モデル、物理モデルに偏る傾向があること、異なる詳細度のモデルがどんな条件で必要なのかが曖昧な結果としてとにかく企業はモデルを作ることに留意しているように感じます。（これはシミュレーションがどんな現象も一つのモデルで表現できるという思い込みからきている感じもしますが…）
本来あるべきMBDとは、自動車会社だけでなく部品メーカーも巻き込んで要求仕様にあったモデルを準備し、管理されてこそシステムとしてのエンジニアができることをもっと理解して欲しいと切に願っています。
もちろん、自動車会社がモデルをどんどん検証し、開発に使ってゆくことは賛成ですがあるべき姿はあくまで部品メーカーも含めての全体システムを俯瞰しながら精度の高い結果を共有してこそだと思います。
正直にお伝えするとここが抜けた状態でとにかく自社の開発工程に入れることに注力して、（MBDやMBSEの定義が曖昧なままで）全体がみれておらず戦略が立てきれていない企業は多いです。
私はできる限りこの考えをまず剥がしてゆき、今一度MBDとは？MBSEの本来の到達点とは？これらを導入することで製造業にどのような大変さが発生し、最終的にはどのような進化が起こるのか？を伝えることができればと考えています。
いやいや、そうは言っても…っとお考えでしたら是非ともコメントいただければと思います。
どうか、これから少しずつですがどうかよろしくお願いいたします。
0本目＿このMBD関連ブログについて
初めまして。
元エンジニアで設計＆制御開発とシミュレーションを使った開発を行なっていた者です。
（2021年11月19日追記・実はちょっと時間を取ることができ、私の脳みそに関して色々と調査／診断してもらったのですが、どうやら私は言語に関しての脳の機能が劣っているそうです。よって、こちらで記載させていただく内容が矛盾や誤った単語などが散見されるかもしれませんが御了承のほどよろしくお願い致します。なお、劣っているものの、空間認知に関してはそれを凌駕してくれているそうです。）
このブログではモデルベース開発(Model Based Development:略してMBD)に関してこれまで関わってきた経験を基にまとめてゆきたいと考えています。
と言いますのも、まだ世の中にはMBDに関してまとまった情報がなく(あるんですが内容が薄かったり…色んな定義があったり…)、かつそれが結果的にどのように会社や世の中に影響してゆくのかを明確に示したものがなかった事から、自分でこれまでの経験を基に本音ベースでまとめてゆこうと思った事から今回こちらでつらつらと書いてゆくことにしました。
以下には、今後このブログを進めてゆくためのポリシーを記載しておきます。
- 本ブログは初心者の方でも理解できるようにしたいと思いますが、多少の専門知識を要する箇所が出てくるところがあるかもしれません。できる限り本ブログ内で説明したいと思いますが、詳細については別途お調べいただくことになると思いますのでご了承をよろしくお願いいたします。
- 本ブログはできる限り精度をもってお伝えできるようにしてゆきたいと思いますが、誤りがございましたら容赦なくご指摘いただければと思います。それを重々受け止め、必要に応じて修正してゆきたいと思います。（皆様と作り上げてゆけるようにしたいと思っています。）
- このブログは100回をめどにつらつらと色々な項目で書いてゆこうと考えております。話が前後する可能性もございますので、その際は別途まとめ直しが発生することをご了承下さい。
- 基本的にはMBDに関するまじめな内容を書いてゆきたいと思いますが、時折内容がこれまでと異なるもの(雑筆系)のものを記載するかもしれません。興味がなければ飛ばしていただければと思います。
また、現状としては以下の項目をテーマとして記載してゆこうと思います。（こちらはあくまで仮の内容ですので、状況によっては修正もしたいと思います。）
- MBD、MBSE、SEの定義
- 経験から伝えるMBD、MBSEのあるべき姿
- 大企業こそMBDが必要な訳
- 実践的MBD導入とMBSEへの昇華方法(モデルの種類、作り方、管理等)
- MBSEからSEへの手引き
- まとめ
- 近未来へのモデルベースへの期待
