マツダの「人馬一体」の取組の中では、クルマのコックピットの中でのドライバーのポジショニングを　人間工学モデル(脱力した状態での
ひざ、ひじなどの角度などの人間の特性) を活用して、操作軌跡などを評価しながら、最適化している例があります。
　　
　　感性モデル　としては、自動車運転時のワクワク感・　不安感など　運転操作に影響する内容を　観測可能な人体の情報(心拍数、発汗、心電図、顔の表情、挙動、反応など、、)から、感情をモデル推定して、例えば、運転支援への活用が研究されていますが、実際には、観測可能な情報の制約や、個人ばらつきによる予測精度の問題により、適用領域は限定的かもしれません。

　また、病気などで影響を受ける運転行動などから人の状態を検知・分析して、ドライバー異常やその予兆を検知する研究もあります。
   走行環境などに対するドライバーの正常な反応をモデル化し、実際の観測情報と比較することで、まだまだ課題も多いのですが、異常や予兆を検知を行う研究例もあります。　

ひろ自連の中の内燃機関専門部会、モデルベース開発専門部会の参画メンバーの一部が、それぞれAICE,  MBD推進センターにも参画しております。この体制により、より密接な情報共有、活動連携ができるように努めています。

端末から、クラウドにデータをアップロードする際のデータ量が大きくなると、通信コスト、計算コストがかさむかもしれませんが、このことは致し方なく、開発スピードとのトレードオフではないでしょうか。　

ありがたいお言葉を頂き、励みになります。
そもそも、広島と言う土地において、弊社は様々なステークホルダーに支えられながらここまで成長してきたと言う歴史があります。元々、戦艦大和などのように、古くからモノづくりに対する礎があり、官としてもモノづくりを支えるマインドが高いと考えております。
一方で、デジタル化などの大きい波に対して、ハードウェアのモノづくりに留まり衰退してしまうと言う懸念があり、この危機感も共有されており、かつ各社自前で対応できるほど大きな会社がない、と言う点で、会社間や産官学を跨って協力していこうと言う風土となっているのではと考えております。

ご質問ありがとうございます。MBDを狭義のToolの一種と考えると、CAEと同様に　“手段”とらえられますが、今回の研修や、自動車業界などで使われているMBDは、設計論の “思想” です。
　つまり、最小限のキーパラメータを特定し、それを基に論理的に要件を満足する仕様を、CAEなどの解析技術を駆使して、決めて、モノにしていく、　そのプロセス、考え方、思想が今回のMBDです。

MBDを数式で考えること　というふうに理解すれば、品質工学があります。この事例として、エンジンのオイル消費の削減に向けた取り組みがあります。
シリンダブロックのFEMﾓﾃﾞﾙがあるとして、実験計画法で計画した実験を繰り返して目的変数を最適化するような取り組みです。
品質機能展開も相性が良いです。
ただし、MBDを狭義のToolの一種（手段）と考えるのは今回のMBD講座を受けられると“違うな”と思って欲しかったです。これは設計論の思想です。
最小限のキーパラメータを特定し、それを基に論理的に要件を満足する仕様を特定する。その仕様を実現するようにCAEなど駆使して決めて、モノにしていく。そのプロセス、考え方、思想が今回のMBDです。
当然、その前にやりたいことを特定すること（価値あるモノとは？）があってのMBDである、その観点でのツールの一種だといわれているなら同意します。

MBD活用が向かない事例は、思い当たりません。

　ご指摘の通り、MBDはツールであり、モデルの特性を理解しておくことが必要です。
　　・対象のすべてをモデルで表現できているのではなく、ある前提の範囲内で、目的の特性を再現したものであること。
　　・モデル化誤差、不確定要素による誤差を含んでおり、予測値と現実値には少なからず違いのあること。
　　
例えば、上記のようなMBDの理解に差があると、結果的に以下のような弊害が挙げられます。
　・実機でやることをモデルに置き換えて満足してしまう、
　・精度追及にはまって、物事を細かく分析的にみる傾向が強くなって、解析のみして満足、俯瞰した理解が出来なくなる。

そもそもMBDは合理的な設計を行うことが目的であることを常に自問して頂ければ弊害を防げます。

スパコンは、弊センターのワークステーション（４４コア）では処理能力が不足する際に利用頂いておりますが、利用頻度はさほど多くありません。複数利用者が同時に利用できるため、スパコンリソースが空いていれば、いつでも利用可能です。

また、スパコンの利用には資格など不要ですが、ファイルの転送やJOBの起動などを行うには、Linuxの知識が少し必要になります。
難しいものではなく、必要であれば当方でフォロー致します。FOCUSスパコンの利用登録者は、FOCUS主催のLinux初級教育を無償で受講いただくこともできます。

補足になりますが、利用の際は事前に、弊センターの年間登録、FOCUSスパコンの利用登録の手続きが必要になります。
詳しい説明をさせていただくことも出来ますので、必要な際はひろデジまでご連絡下さい。

ご質問をいただき、ありがとうございます。
　今回の講義の中でも一部紹介された弊社のSkyactiv の燃焼解析などでは、製品開発上の課題を大学と共有し、大学のシーズや知見を活用したり、逆に企業側の開発ニーズを研究テーマを設定いただき、大学の工学との共同研究を通じて開発に合ったモデル化により、シミュレーションでの現象可視化などで、製品開発へ活用し、その成果を反映しています。
　　また、今回受講いただいたMBDプロセス研修他、教育領域での連携もあります。
　もともと制御系領域でMBDは、一般的に活用されていた手法でありますし、学生に対しての教育実績を踏まえた大学の強みと、
産業界でより実践的に利用したいというニーズを踏まえて、社会人にもわかりやすいカリキュラムを開発し、提供いただけています。
　　企業側の開発ニーズは、より多様化していますし、MBDは、設計思想(対象のカラクリ(原理)を把握して、コンピュータを駆使したバーチャルでの予測検証の徹底) ですので、モノづくりだけでなく、コトづくりや、医学、デザイン、経済など、さまざまな領域に適用されていくものと期待しています。

今後広がっていく分野に、AI/IT系の技術との融合を目指す領域は一つ確実にあります。モノづくりに向けて画期的な進化（主にスピード）をもたらすでしょう。

広げていく業界でいうと、造船、重工、医療なども視野に入ります。直接ひろ自連では広げないかもしれませんが、MBD推進センタ（JAMBE）のスコープとしてはさらに先々航空、宇宙なども入ってきます。

非常に大雑把な割合でしかお答えできないこと申し訳ありません。また製品づくり（開発）に取り組む企業のモノ作りが、

企画　設計　製造　実研

で行われるとして、全ての部門でﾓﾃﾞﾙは使います。
企画や設計で用いる　機能モデル
設計で用いる　機能モデル＋CAEモデル＋CADモデル
製造で用いる　CADﾓﾃﾞﾙ
実研で用いる　機能ﾓﾃﾞﾙ＋CAEモデル

モデル化作業の占める割合を一概にいくら　とは言えないので感覚ですが、おおむね総工数の3-4割程度は掛けているのではないでしょうか。ただしこれも外にアウトソースすると変わりますので、あくまで目安程度でしかないです。

MBDの知識はおおよそ30年かけて蓄えてきております。実はMBDの知識はあったのです、ただしそれを開発に適用して、ﾓﾃﾞﾙで設計して判断していく　価値を作り出すところに使えてなかったということです。

一番苦労した点は、組織を巻き込むことです。モデルを信じない、実機でやることが一番正しいと思い込んでいる人々を、ﾓﾃﾞﾙを上手く使えば、さらに効率的に良い答えへたどり着けること。そこを確信できるようになることです。

そのほか技術面での一番の苦労は、モデル化（燃焼）に大学/ツールベンダなどの協力も得ながら地道な研究で成功させたことです。

ご質問ありがとうございます。
そもそも、実物では設計値や諸元を振ったものの準備やテストが大変ですので、品質工学はモデルで行うのが相性が良いと考えています。設計パラメータについては、正に品質工学を用いて感度の高い項目を探索することになると思います。モデルの実力もあるので、結果をうのみにしてはいけませんが、思い切った水準を振ってみて、その結果から逆に新しい知見を得ると言うような活用の仕方もあるのでは、と考えております。

新規開発要素がある限り、下記の観点から、モデル化率は100%になりませんが、その前提を理解した上であれば、新規開発などに対しても十分に適用は可能です。
   ・　　完成度
　　　　　新機能、新規開発項目についてのモデル化　(80%は、既存モデルを使用)　　
　　　　　先行開発の中で、モデル化し、量産開発を通じて、精度アップ　　⇒　派生開発で活用。
　・　　カバー率
　　　　重要な機能から、優先度をつけてモデル化、(工数面)

ご指摘の問題は想定されますが、実際には　例えば、性能(燃費、動力性能)　や耐久信頼性　など、必要な機能、性能毎に　開発目標を達成できるかどうかを検証するため、その目的に合わせて各々のモデル化を進めております。
　そのような個々のモデルをデータベース化しながら、各々の目的に合わせて修正、組み合わせて活用しております。

ご質問ありがとうございます。質問の意図を正しく捉えられているか心配なのですが、S/N比ですので、SとNを分けてと言う扱いの情報ではありません。基本的にばらつき度合いを表すのがS/N比ですので、このS/N比が最大となるような因子水準をまず採用して、ロバストな設計を目指す、という事になると思います。

当時の考えを推測するに（回答者の私は当事者ではないので）、一番難しいことは、実は皆さんの業務の中の様々なプロセスを上手くやろうとしたときにネックになっている、もしくは、そのネックを回避するために面倒なプロセスをわざわざ構築した。。。ということになってないでしょうか。なのでその一番難しいところを打破できれば、様々なものが一気に、楽に、より高い次元で出来る（＝変革が起こる）　ということです。

専門外ですので、一般論になりますが、ピストンリングは、ピストンと、シリンダーの間にあって、高速ピストン運動、広範囲な温度、圧力条件の中で使用されますので、課題の燃焼によるオイル消費についての直接の評価は困難です。
しかし、各部品のFEMモデルがあれば、運転状態での形状解析は可能ですので、運転条件ごとに　ピストンリングとシリンダー間の隙間を計算し、そこからのオイル量の通過量を推定して、実機のオイル消費量と比較して、モデルの確からしさを評価することになります。
　実際は、実験計画法で　目的変数(オイル消費)を最適化できる制御因子をシミュレーションで繰り返しながら、効果の大きい部品仕様を試作して、実機測定結果と符合するかどうかを確認しながら、モデル検証をしたものと考えます。
　一から、実機テストを繰り返すよりは、はるかに効率的ですし、可視化したものをチーム、組織に共有することで、多くの人のアイディアを集めることができたのではないかと思います。

ご質問いただき、ありがとうございます。
①新機能、新規開発項目について、100%のモデル化して、製品化移行は、理想ですが、現実問題としては下記の観点から、モデル化率は、100%にならないと考えています。
　　 ・　　完成度
　　　　　新機能、新規開発項目についてのモデル化　(80%は、既存モデルを使用)　　
　　　　　先行開発の中で、モデル化し、量産開発を通じて、精度アップ　　⇒　派生開発で活用。
　・　　カバー率
　　　　重要な機能から、優先度をつけてモデル化、(工数面)
　
②　モデルは、その評価する内容、目的に応じて、さまざまな抽象度のモデルを活用していますので、一概にお答えすることは難しいです。

　動画収録は、2020年11月に行いました。

　ご質問の意図を取り違えているかもしれませんが、モデル化することが難しい項目とは、原理、カラクリの解明が進んでいないと考えられます。このような要素を製品に利用すると、机上での性能予測、挙動予測が難しく、机上検証は困難になりますので、ものベースでの評価となりがちで、手戻りが起こりやすくなります。
　もし、このような要素を製品に織り込むためには、通常、研究開発、先行開発段階で、徹底した分析、解明をして、素性を把握、モデル化して、取り組まれているのではないでしょうか?
  動画の中で、紹介のあったSkyactiv は、予測が困難であった高圧縮燃焼の解析、現象解明、モデル化を通じて、机上予測精度を上げ、可視化する過程で、さまざまなアイディアが生まれ、かつ、机上で高速試行、検証が可能となった結果ではないかと考えます。　

ご質問ありがとうございます。質問の意図を正しく捉えられているか心配なのですが、1Dレベルのモデルを用いた検討は、複数のシステム(例えばエンジン・トランスミッションと電気駆動デバイス、等)が組み合わさった時のシステム全体の振る舞いの妥当性確認やシステム性能配分の最適化などが活用の中心となります。3Dレベルのモデルを用いた検討は、例として挙げて頂いている燃焼解析等、具体的な諸元や寸法などの形状を決定するために用いるのが中心となります。一般的に3Dレベルの解析は時間が多くかかりますので、部品レベルの検討が主流となります。

ご理解のとおりです。
　　開発全体の中で、制御開発の規模が爆発しており、排気量毎に新たな制御を開発する体力はないため、同じ制御が使えるように、制御ソフトの構造化、階層化と共に、ハードウェアの特性を揃えた　＝コモンアーキテクチャーという考え方を導入し、これにより、エンジン制御(点火、進角、燃料) 補正量などの多くのパラメータを　排気量によらず、共通してきています。

また、姿かたちの無いエンジンで、燃焼室などの形状を変えて特性を作り込むため、シミュレーションを駆使しております。
この技術は、派生エンジンのハードウェア開発の効率化にも貢献しています。

もともと物理現象のモデリングを生業にしているチームからMBDは生まれてます（制御屋さんではない！）。そこではエネルギーベースにモデルを作ることはごく自然なこと。もともとがエネルギーベースである点です。

一般的には、外製は汎用性の高いものであり、弊害ではなく、要求レベルが違うのではないかと考えています。
　
　例えば、高速MILSは、開発の最前線の中で、エンジンECU全体での機能検証を進めたいという高い開発要求からでたものであり、
その開発にはソフトウェア技術だけでなく、制御対象(エンジン、車両など)の特性なども理解した上での試行、最適化が求められるからです。

ここは元々あったものをベースにSim結果を見ながら人が形状を修正していったと聞いております。
おっしゃるように、今あるものをスタート地点にすると、量産の中ではどの程度　合う、合わないかが大問題にされてしまいますね。おっしゃる通り妨げる原因です。
考え方としては、まだ、ものが出来てない段階で、そのポテンシャルを見る（一体どの因子が主要なのか？　補助因子のか？　変化したときに性能はどう変わるのかの大域的な地図を造る）ことが出来れば、アプローチを考えることが非常楽になるはずです。そんなところから考えていくプロセスが大事になってきます。

MBDの弊害は、使う人が多くなってくると、MBDの理解に差が出ることです。
結果、実機でやることをモデルに置き換えて満足してしまう、もしくは精度追及にはまって、物事を細かく分析的にみる傾向が強くなって、解析のみして満足、俯瞰した理解が出来なくなる。ということが挙げられます。
そもそもMBDは合理的な設計を行うことが目的であることを常に自問して頂ければ弊害を防げます。

企業としてのMATAB/Simulinkの活用は部門単位で本格的な活用は90年代後半です。これはFord時代にもたらされました。
2004年ごろには部門単位ではなくMDI推進室が取りまとめた一括投資に切り替わり潤沢に使える環境が整いました。

ご質問ありがとうございます。非常に答えにくい質問と感じています。
と言いますのも、設計者自身が実機結果を確認することも当然ありますし、実験を行っている人も現象を解明する探究を行って設計指針を得ようとしていることもあるからです。
また、MBDも様々な粒度(ご質問にあるような上流工程やMILSなどの検証段階等)がありますので、粒度によっても異なります。
個人的な大まかなイメージで恐縮ですが、設計業務中心の方と実研中心の方の比率は2対1くらいかなと感じています。

モデルの使用する目的によりますが、部品仕様に立脚した詳細モデルが必要な場合には、基本、部品サプライヤーさんに協力をお願いして、モデル化を行います。　機密などの問題があれば、内部を暗号化して、入出力の関係のみがわかるようなモデルを提出いただき評価します。　　機能レベルの評価でよい場合は、自社で作成するなどで、代用します。

オートコードツール(例えば、Simulink　オートコーダー)などを使う場合、意図通りのプログラム生成をさせるには、ツールの特性を考慮したモデリングが必要です。　このため、JMAAB(Japan MBD Automotive Advisory Board)や、各社の社内規格、Mathworks社などで、スタイルガイドラインが制定され、それに沿ったモデル作成が進められています。　これにより、モデルと生成されたコードを業界標準*へ準拠する可能性を高めています。　(*  ISO26262, AUTOSAR,  MISRA C :2012などなど)
　既に、ガイドラインへの適用チェック、自動修正を行う　モデルチェッカーもあり、ガイドラインもチェッカーを使用する前提に修正が進んでいます。
　なお、オートコード環境構築のコスト(費用、期間)については、一概にお答えすることは難しいです。

既にモデル化する対象が存在する場合は、当然、実機を活用します。
　机上での評価目的に合わせて、実機を分析(構造、機能、振舞いなど)し、要素分解し、モデルを作成し、モデルの妥当性については、実機とモデルで、同じインプットに対する応答を比較して、評価に十分なモデルかどうかを確認しています。

それと、忘れてはいけないのは、モデルはあくまでモデル、本物とは違う　その前提で如何に開発の中で分かった知識をモデル化して、開発に生かすか。ということが重要になります。

“METI　プラントモデル　インターフェースガイドライン”は、欧州側では、下記名称で通っています。“Plant Modeling I/F Guidelines　for Vehicle Development Model Exchange”　

広げていく業界でいうと、造船、重工、医療なども視野に入ります。直接ひろ自連では広げないかもしれませんが、MBD推進センタ（JAMBE）のスコープとしてはさらに先々航空、宇宙なども入ってきます。

今後広がっていく分野に、AI/IT系の技術との融合を目指す領域は一つ確実にあります。モノづくりに向けて画期的な進化（主にスピード）をもたらすでしょう。

HEVのシステム構成が変わらない限りは、（マイナーチェンジやフルモデルチェンジであっても）I/F物理量と向きを規定したブロック図の変更はありません。ブロックの中身はモデルそのものになりますので、ご推察の通り、モデルチェンジ等によって変更されます。HEVの事例を出しているのは、複雑な例としてカバー範囲を広げるためです。システム構成が変わる場合は作り直す必要はありますが、基本となる五原則に基づいて規定することになります。

多くの工数をどちらに？　という質問は対象にもよると思われますが、一般的にはMILSへ投入すべきです。なぜならモノを造ってない段階だから、このタイミングで発見された致命傷は本当に有難い。なのでまずはMILSというのは第一に投入すべきです。
一方で、HILSは、MILSとそもそも目的が違います。MILSの裏返し（同じ評価項目がHILS）ではありません。
HILSはソフトとハードの間で起こる問題を発見するためにあります。一方でテストそのものが実時間でしかできないでのそこからくる制約が出てきます。なので車全体の立ち上げやハードとの関係での不具合の早期発見などに向けて、目的を絞って活用されると効果的だと考えております。

対象システム、使用目的などにより、モデルへの要求仕様、モデル作成費用などは異なりますので、詳細はサプライヤとの事前協議により、双方で確認、合意して進めています。

おっしゃる通り、ムズムズ感じられるのはよくわかります。
実際の開発現場ではありました！　解釈のずれが小さくなるようにドキュメントを管理したり、単品モデルでのV&V(Verification & Validation :検証と妥当性確認)を行うことで防ぎます。システムﾚﾍﾞﾙではMILSやHILSでやはりV&Vを行うように、徐々に曖昧（SILSﾚﾍﾞﾙ）なところから固めていく（現物でのHILSや実車試験）プロセスで手戻りを防いで（最小化）いきます。解釈のずれはどの段階でも起こりえます。現場現物主義はモノベースの時代は正しいですが、ソフトの規模がここまで大きくなってきている中で可能でしょうか。既に破綻していると感じてます。
各人での解釈のズレを無くすために、モデルを作る時のルールやガイドラインが重要なのと、何の目的のために、どういう制約でこのモデルを作ったのか　という情報（これをシミュレーションメタデータ）が重要になります。今世の中の最先端では、このモデルのメタデータをどのように決めて取り扱うかが議論されておりやがて公開されるはずです。
JAMBE(MBD推進センター)などではまさにそこを議論しております。

質問の意図をとらえきれていないかもしれませんが、
弊社の場合、逆にそれだけの人員を確保できませんでしたので、開発効率をあげるために、コンピュータをフル活用可能なMBDを導入せざるを得なかったというのが正しいかもしれません。

どのレベルのモデル作成ルールを統一するかによると思います。
現在のルールでは、入出力のインターフェースの統一といったレベルですので、機能に影響する仕様には影響しません。
今後、制御ロジックなどを含めた統一が進んだとしても、パラメータチューニングによる味付け、例えば、走り感などの感性に訴える領域の差別化は十分可能ではないかと考えますので、今後のさらに共創領域が広がってくることを期待しています。

経済産業省様のご支援を頂いて作成してきたガイドラインやモデルは、MBD推進センター（JAMBE）の発足に伴い、EPC様のHPから移管され、現在は、以下の場所で公開されております。
<https://www.jambe.jp/system/download>

ご質問ありがとうございます。まとまった書籍という意味では、コロナ社「改訂 実習で学ぶ モデルベース開発」は考え方をまとめており参考になると思います。それ以外で過去のMBD関連の記事で主要なものは以下になりますのでご参考まで。ご指摘部分の回答も部分的に触れられていると思います。
・原田靖裕(2012), SKYACTIVテクノロジーを支えたモデルベース開発, SEC journal Vol.8, No.2
・岡田吉誼，岡村一徳，片村修一(2000)，MDI支援システムの紹介，マツダ技報(2000 No.18)，pp. 8-15，マツダ株式会社
・滝口哲郎(2007),「マツダにおける"くるまづくり"革新プロジェクトMDI(マツダ・デジタル・イノベーション)の取り組み事例」, FUJITSUファミリ会 2007年度秋季大会, https://jp.fujitsu.com/family/familyroom/e-family/2007-27/pdf/2007_autumnsession2.pdf, (参照 2022-04-05)
・平松 繁喜，百田 浩一，小森 賢，徳光 文広，城谷 佳孝，村井 亜樹(2004)，パワートレイン構想設計のVirtual Testing技術の紹介，マツダ技報(2004 No.22)，p.p.51-52，マツダ株式会社
・河内 正行，大地 正樹，上岡 孝志(2004)，Virtual Testingの紹介，マツダ技報(2004 No.22)，p.4，マツダ株式会社
・新見光弘(2000)，製造業のデジタル革新，マツダ技報(2000 No.18)，p.p.3-4，マツダ株式会社
・飯田健次，児玉信宏，縄淳二，平野誠一，花野木寛(2007)，全ての開発活動に活かせるデジタルモックアップ構築とその運用，マツダ技報(2007 No.25)，p.91，マツダ株式会社
・谷口雅昭，井口勇，田端伸章，橋本裕信(2002)，新型MZR I4エンジン，マツダ技報(2002 No.20)，page 60，マツダ株式会社
・池原昭雄(2018)，【池原昭雄の単眼複眼】マツダ，200万台体制へ脱・「一括企画」の商品開発とは？，レスポンス，
https://response.jp/article/2018/05/09/309445.html，(参照 2022-01-05)

ご質問ありがとうございます。
ご質問の件ですが、下図にあるように、OEM で、内製開発する部分は、アプリケーション層が中心となります。
量産いただくサプライヤさまでは、ECUハードウェア、ハードウェア依存層
の開発、およびECU全体の製造と品質保証を担っていただくことになります。



メータへの適用について、形状の3DCAD化、構造のCAE検証はされていますが、
プラントのモデル化はされていないようです。
(内部の機能、構成部品は量産流用品の使用が多いため必要性が低いのかも
しれません。)
メータはデザイン要件も多いため、質感などの評価は、現物ベースとなることが
多いようですが、一部VR(Virtual Reality)を活用した事前評価を行うこともあるようです。

詳しくはNIのHPを参照下さい。
https://www.ni.com/ja-jp/innovations/case-studies/19/advanced-vehicle-electronics-test-with-a-software-defined-automated-test-system.html

はい、あります。　一部ですが、下記　2枚のスライドの情報を共有させていただきます。

ご質問ありがとうございます。
一般論にはなりますが、作成したモデル自身に不備がある場合、定量的な差以前に、定性的な動き、特に大まかな動的挙動が異なっていることが多いので、その段階でモデルの見直しを行います。
定性的な動きが合えば、パラメータを同定したりしながら、定量的な動きを合わせに行きます。
そこでも再現できない詳細な挙動があれば、モデルとしての考慮部分、すなわちご質問の「追加すべき要素が抜けていた」ことになると思います。
ただ、モデルの活用は用途次第ですので、どんどん詳細化していった結果、精度は改善するものの演算時間が伸びて使い物にならなくなる懸念もあるため、目的にあったモデルの詳細度の見極めが重要になると考えています。

ご質問ありがとうございます。

　マツダでは、MBDを、下記実現のためのツール、考え方として、広くとらえていこうとしています。
　①　人/環境/制御/車などの開発対象を　0D、1D, 3Dなどのさまざまで粒度のモデルで、適切に理解する
　②　それらを使って車全体の設計開発を、合理的に、かつ、効率的に行う

　まだまだ、部分的なつながりではありますが、これらが　クルマのライフサイクル(企画、設計、製造、販売、使用、再生)を前提に
デジタル　モデルでつながり、目的に応じて適切なモデル群を組み合わせて机上シミュレーションで評価することができるようになれば、大きな手戻りなく、より全体最適な設計開発に近づけるものと考えています。　さらには、人間だけでは、解決の難しい、より大規模で、複雑な最適化問題を解決できる可能性も出てきます。

　ただ、ご指摘のように、MBDでは　モデル化誤差や、新規開発などでの不確実な要素も含まれるため、万能ではありません。
　この点を十分、承知の上で、高速な検討、意思決定につなげられれば、開発効率化に大きく貢献できるものと考えています。　

ご質問ありがとうございます。認証法規に関してはあまり詳しくなく、正確な回答が難しいのですが、架装種類の多いため実車で全機種揃えるのが難しいトラック等の領域では、従来よりバーチャル認証が活発に行われています。最近では乗用車においても、再現テストが難しい先進安全装備に関する認証試験の一部について、シミュレーション結果での証拠提出でも可能、という国連法規（UN-R）が出てきており、今後もその範囲は拡大していく方向です。

ご質問ありがとうございます。ご質問中の「協業」が、企業間の協業なのか、経産省に支援を頂きながらMBDの推進を行ってきた活動における日欧の協業なのか、判断がついておりませんが、前者であれば、おっしゃる通り目的や検討対象、プロセス等も企業間で異なるものと思います。逆に言えば、異なるやり方であるがゆえに、例えば、どこの部分のモデルなのか、どこのプロセスなのか、等、共通の定義も必要になると言えると思います。ですので、後者のような活動で標準化できる所を持ち寄ることになると考えております。

ご質問ありがとうございます。3D-CAEの領域はあまり詳しくはないのですが、衝突の領域は、精度はともかく、もっとも早く計算によるシミュレーションが活用され始めた領域です。衝突試験は、当然ながら高価な試作車を壊してしまう試験で、非常に費用がかかるため、何度も行えるものではないからです。衝突時の予測を行い、補強材の追加等の検討は行われていると思います。

ご質問ありがとうございます。
他産業については、申し訳ないのですが、あまり詳しく存じ上げておりません。
ただ、一般的に試作費用が高いものは当然たくさんの試作機を作る訳にはいかないので、モデルで事前検討を行う、と言う文化ができやすいのではないかと考えております。その意味で、航空産業や建機産業などはMBDの導入が進んでいると思います。特に建機は、様々なバリエーションが存在する事、機械と電気と油圧と言う複数の工学分野にまたがって制御する必要があることなどから、以前から進んだ事例を伺っています。
また、自動車産業が進んだ取り組みをしていると言うのは、競争が激しい事も一因かと思います。他社に対して短期間で低コストで開発を行わなければならないというプレッシャーは相対的に大きいと思います。逆に、企業を跨った様々な標準化活動も行われており、協調領域を見つけて、業界として取り組んでいける部分は強みと呼べるのではないでしょうか。

CASE　重要性/影響度の評価に関してはあくまで私見になります。
現在本当に重要なのは、CとEだと思います。
ソースコードの肥大を招いるのはC。またCN(カーボンニュートラル)の観点から待ったなしはEです。
しかし顧客からみた影響度は今の自動車の延長線上です。
一方影響度は、AとCです。これは顧客の生活が一変します。

モデリングの手法になるのですが、「スルー変数を受け取りアクロス変数を出力する蓄積要素」と「アクロス変数を受け取りスルー変数を出力する蓄積要素」を交互に配置することで、うまく接続でき、かつ計算も安定的に解けます。ですので、慣性質量のような要素とバネのような要素を、実際の車のシステムのどこに割り当てるかを、モデリング＝抽象化する際に考えることがポイントになります。
ただ、おっしゃるように、この原則だけだと分かりにくいので、一つの事例として燃費レベルの検討を行う際のI/Fを定めることでモデリングを行う際のガイドラインにしています。

ご質問ありがとうございます。「本研修で習ってきたような一方向の流れ」と言うのは、ラプラス変換等を用いた伝達関数形式のモデルの事を差していると推察しています。「モーター」と言った制御対象を一つで表す場合には、信号は制御と制御対象の間の話になりますので、一方向に見えるかもしれません。（それでも正確には、制御から制御信号を渡し、センサの信号を返してもらっているはずなので、一方向ではなく双方向になっていると思います。）今回の説明は、プラントモデルとプラントモデルの間の接続の話ですので、制御対象を複数の構成要素でモデル化した場合の内部の話になります。

ご質問ありがとうございます。おっしゃる通り、今回の説明は、制御対象のモデルであるプラントモデルとプラントモデルの間の接続の話ですので、コントローラとプラントモデルの間の話は対象となっておりません。この部分については今後順次議論の対象になっていくものと思いますが、対象によってセンサ信号の種類も多種多様ですので、汎用的な標準化は難しい側面があります。ですので、対象を絞った論議からになると考えています。

ご質問ありがとうございます。MBD推進センター(JAMBE)の発足に伴い、これまで経産省の委託事業として公開されていたEPCのホームページから、JAMBEのホームページにガイドライン類の公開が移管されております。下記をご参照頂ければと思います。
<https://www.jambe.jp/system/download>
→No 20002です。

ご質問ありがとうございます。
耳慣れない用語かもしれませんが、やりとりする物理的な信号を大きく2つに分けた、くらいに考えて頂いた方が楽かもしれません。
ある分岐点で、入ってくるものと出ていくものが同じになるようなものがスルー変数（通過変数）で、川の流れのようなイメージです。
2つの点の差を取るようなものがアクロス変数（横断変数）で、電圧（電位）の差のようなイメージです。

これらが逆向きになっているのは、個々の要素できちんと計算できるようにするためです。
例えば、M=1kgの重さの物体があるとして、アクロス変数である速度v=1m/sと、スルー変数である力F=5Nが入力として与えられたとすると、ニュートンの法則から
  F=M*a=M*(dv/dt)
となります。1秒の幅で微分をしたとすると、a=1m/s^2となりますが、
 5=1*1
となると矛盾することになります。
  F=M*a
で言えば、Mは一旦変化しない定数とした時に、a(vの微分)かFのどちらかが与えられると、もう片方が決まることになります。
ですので、どちらか一方を入力とし、計算された結果を出力とするため、入出力が逆向きにすることになります。

原因と結果、と言う意味で言えば、入力が原因、出力が結果と考えられますが、要素によって入力がアクロス変数だったり、スルー変数だったりするので、「アクロス変数・スルー変数」と「原因・結果」は一致しないことになります。

ご質問ありがとうございます。
基本的にはエネルギーを生み出すものがソースですので、オルタネータはご理解の通りです。
バッテリについては、生成されたエネルギーをためる（水を溜めるバケツのようなイメージ）ものになりますので、シンクとして扱っています。
モータードライブについては、機械系の側面と電気的な側面があると思います。駆動時には、機械的にはエネルギー（トルクや回転）を生み出すので、ソースに近いイメージになりますが、電気的にはエネルギーを消費する側になると思います。逆に回生時には、機械的にはエネルギーを消費する側になり、電気的にはエネルギーを生み出す側になります。ですので、機械・電気の両側面とモーター・ジェネレータとしての側面を持ちますので、判断はおっしゃる通り難しいと思います。
策定の際には、当時一番複雑な機構としてTHS（TOYOTA Hybrid System）を題材にして、OEM、サプライヤを交えて議論を行い、最終的にこのようになったと聞いております。機械的な駆動面を重視したものかと推察しております。

ご質問ありがとうございます。エネルギーは、アクロス変数とスルー変数の掛け算になりますので、少しご質問の理解とは異なると思います。逆に言えば、エネルギー（仕事率）を2つの物理量の掛け算で表現し、同一点で同じ値を取るものをアクロス変数、同一点で総和が0になるものをスルー変数にしています。様々な工学領域のアクロス変数・スルー変数の例は、以下が分かりやすいかと思います。
https://jp.mathworks.com/help/simscape/ug/basic-principles-of-modeling-physical-networks.html;jsessionid=a3f6d8ccb7cbae30f9cd45dd8f72

ご質問ありがとうございます。
耳慣れない用語かもしれませんが、やりとりする物理的な信号を大きく2つに分けた、くらいに考えて頂いた方が楽かもしれません。
ある分岐点で、入ってくるものと出ていくものが同じになるようなものがスルー変数（通過変数）で、川の流れのようなイメージです。
2つの点の差を取るようなものがアクロス変数（横断変数）で、電圧（電位）の差のようなイメージです。

これらが逆向きになっているのは、個々の要素できちんと計算できるようにするためです。
例えば、M=1kgの重さの物体があるとして、アクロス変数である速度v=1m/sと、スルー変数である力F=5Nが入力として与えられたとすると、ニュートンの法則から
  F=M*a=M*(dv/dt)
となります。1秒の幅で微分をしたとすると、a=1m/s^2となりますが、
 5=1*1
となると矛盾することになります。
  F=M*a
で言えば、Mは一旦変化しない定数とした時に、a(vの微分)かFのどちらかが与えられると、もう片方が決まることになります。
ですので、どちらか一方を入力とし、計算された結果を出力とするため、入出力が逆向きにすることになります。

原因と結果、と言う意味で言えば、入力が原因、出力が結果と考えられますが、要素によって入力がアクロス変数だったり、スルー変数だったりするので、「アクロス変数・スルー変数」と「原因・結果」は一致しないことになります。

ご質問ありがとうございます。　
　
ドイツの標準化団体Prostep ivipや、フランスの標準化団体SystemXでは、モデル流通時のプロセスや、モデルに付随するデータ項目などが中心に規格化が進められており、日本が取り組んできたプラントモデル間のI/F(インターフェース)については対象となっておりませんでした。
現在、Prostepについては、お互いの良い所を持ち寄って統合したガイドラインを作るような動きも行っておりますので、注意点は　特にないのではないでしょうか?

いずれにしても、重要なのは、事前によくI/Fについては話をしてすり合わせることが重要です。
アイシンさんはJAMBEメンバなので、I/FのガイドラインについてはJAMBE担当の方に問い合わせていただければ幸いです。

ご質問ありがとうございます。

策定の際には、当時一番複雑な機構としてTHS（TOYOTA Hybrid System）を題材にして、OEM、サプライヤを交えて議論を行い、最終的にこのようになったと聞いており、機械的な駆動面を重視したものかと推察しております。


伝達方向の向きについては、基本的にはエネルギーを生み出すものがソースです。　バッテリについては、生成されたエネルギーをためる（水を溜めるバケツのようなイメージ）ものになりますので、シンクとして扱っています。
　モータードライブについては、機械系の側面と電気的な側面があると思います。
　駆動時には、機械的にはエネルギー（トルクや回転）を生み出すので、ソースに近いイメージになりますが、
　電気的にはエネルギーを消費する側になると思います。
　逆に回生時には、機械的にはエネルギーを消費する側になり、電気的にはエネルギーを生み出す側になります。
　
　機械・電気の両側面とモーター・ジェネレータとしての側面を持ちます。

ご質問ありがとうございます。おっしゃる通り、現在は従来のJC08モードからWLTCモードへと燃費表示義務が変更になっております。

ご質問ありがとうございます。
回生制御については、「ALT_CNT_set_params.m」中のALT_CNT_flag_disable_kaiseiの値を変えられたものと推察します。
回生制御をオフにすると、おっしゃる通り、モデルの計算上、実際には「ありえない」状態まで充電し続けることになり、正しい結果が得られないモデルとなっています。計算上バッテリのSOC（フル充電時の容量に対する充電量の比率）が100%を超えるような状態になってしまっていますので、妥当な結果は得られないと思われます。実際に、オルタネータの負荷トルクがより小さい値（負の値が0に近い値）になっているのを確認しましたので、抵抗が減って燃費が良くなってしまっているものと思われます。

ご質問ありがとうございます。

MATLABとSimulinkのみで、演習可能です。

ご質問ありがとうございます。
ご推察の通り、一番簡単な方法は単純にSOCの値を100%までで上限を設けることです。ただしこの場合も、モニター値だけ100%にしても、内部的に積分されて実際には100%を超えてしまっていることもあります（この場合、内部的に例えば110%とかになってしまい、そこから電流を消費しても、なかなか100%を下回らないことになってしまいます）ので、積分器にも制限をかける必要があります。もう少し詳細なモデルになると、バッテリのモデルとして内部抵抗を持たせ、SOCが100%に近くなると内部抵抗を大きくしていき、電流が流れにくくなるようにする、という手もあります。もちろんもっと詳細にして化学反応を解く手もありますが、モデルの詳細度は目的次第かと思います。

システム全体のどこまで見るかでシミュレーションの重さも変わりますね。
やり方の工夫としては、すべて同じ粒度の全体モデルではなく、見たいところの機能的に大きな塊は詳しくモデル化、その塊とつながる部分は境界条件を与えるレベルのモデルとしてシミュレーションを行うなどします。

申し訳ないのですが、場所が特定できておりません。
オルターネータの電圧と言うことで、下記の場所を表示させてみましたが、研修中で扱う修正前後のモデルにおいて、いずれも11V以上の値を出しておりました。

データはありますので、ご自分のニーズに合わせて、表示方法などのUIを工夫してみていただければ、幸いです。

 例えば、一例として、Simulinkに　「Display」というブロックがあり、これに　確認したいパラメータを入力すれば、数値での表示が可能です。

ご質問ありがとうございます。どこの場における「運用」か、測りかねておりますので、回答のポイントがずれていましたら、ご容赦ください。
　まず一般論として、モデルそのものを変換せずに流通するためには、出し手と受け手が、同じツールもしくは同じ言語のツールである必要があります。出し手と受け手がこの条件を満たすのであれば、ModelicaでもVHDL-AMSでも問題ないと思います。ただし、実際の現実として、例えばModelica言語で記述されたモデルであってもツールによって解釈が一部異なることがあるため、Modelica系のツールでもツールが異なれば動作しないこともあります。
　これらの課題を解決するため、モデルを流通する場合には、FMI(Functional Mock-up Interface)と言う規約に基づいたFMU(Functional Mock-up Unit)と言うものにモデルを変換して行うのがメジャーになってきています。つまり、モデルを作る際にはいろんなツールを使用可能ですが、流通の際には標準フォーマットに従ったコンポーネントでやり取りしましょう、と言うものです。ツール間の互換性等も公開されていますので、下記を参照頂ければと思います。
<https://fmi-standard.org/>

申し訳ないのですが、場所が特定できておりません。
オルターネータの電圧と言うことで、下記の場所を表示させてみましたが、研修中で扱う修正前後のモデルにおいて、いずれも11V以上の値を出しておりました。

ご質問ありがとうございます。経済産業省様のご支援を頂いて作成してきたモデルは、MBD推進センター（JAMBE）に移管され、現在は、以下の場所で公開されております。
<https://www.jambe.jp/system/download>

ご質問ありがとうございます。
実車においても、改善のためのアイディアを出したりするために、制御については多くの値をモニターしております。
一方、ハードウェアに関わる部分は、計測器や設備の制約が大きいので、「測れる部分を測る」ことになります。
（なお、実車に量産用のセンサがついている部分はそのまま制御側でモニターすることになります。）

とても良いご質問を頂き、ありがとうございます。おっしゃる通り、様々な標準化活動が行われております。制御系、プラントモデル系、それらを含むシミュレーション系、プロセス・管理系などに大別できると考えていますが、ツールに依存するもの、シミュレーションだけでなく計測器やハードウェアも絡むものまで、多岐にわたっているため、これらをすべて把握する事自身が既に難しくなっております。例えば今JAMBEの中で制御系I/Fの標準化について議論を開始しておりますが、まずは既存の標準を調査する所からスタートと言う状況です。JAMBEの活動の中でこれらの情報を整理して、正しく情報発信できるよう努めて参りますので、しばらくお時間を頂ければと思います。

欧州を意識しているのは事実です。正直レベルでいうと、まだUSと中国には正式に持ち込んでいないというのが正しいステータスです。特に彼らを排除しようとは考えておりません。各社サプライヤ殿との関係においては同様の問題を抱えておられるはずです。
（経産省の活動はJAMBEに引き継がれてますが）JAMBEの取り組みとして、ドイツProSTEP、フランスのSystemXと連携してきおります。ProSTEP直近の以下アナウンスメントでは、ProSTEPがフランスのディジタル規格化団体AFNeTとUSのディジタル化推進コンソーシアムであるPDES,incと協業開始の覚書を交わしました。なので欧州から始め、USへの展開が見えてきてます。
＜ProSTEP報道から＞
September 2021: prostep ivip, PDES, Inc. and AFNeT announce cooperation in MBx Interoperability Forums prostep ivip Association, PDES, Inc. and AFNeT Association have signed a Memorandum of Understanding (MoU) for closer cooperation in the field of MBx Interoperability Forums, to accelerate MBx translator development & ensure the satisfaction of user requirements. 

中国に関しては、今のところJAMBEからのアプローチなどは計画しておりません、電池以外グローバルTire1と呼べるところはない、ツールベンダ、エンジニアリングサービスプロバイダがほとんどないため。ただし今後の動向には注意を払いたいと思っております。

ご質問ありがとうございます。一般論にはなりますが、まずは流通させる相手との契約に依存すると思います。モデルの中身の開示を含むものなのかどうなのかを、まずしっかりと契約上確認する必要があると思います。
その上で、中身の開示をしない場合の留意点ですが、基本的にはモデルはバイナリーファイルで提供する必要があります。例えば、Functional Mock-up Unit(FMU)であったり、MATLAB/Simulinkで言えばS-Functionのようなものになります。ただ、これらも内部にモデルのソースコードを含む場合があるので、ソースコードを含まない形で生成するよう注意が必要です。
また、モデルと一緒に提供するパラメータも、自社製品そのものの特性を精度よく再現するものなのか、数値を丸めたりするなどして少し精度を落として大体合っているレベルのものなのか、もっと一般化して傾向を再現できれば良いものなのか、等、契約レベルに応じて適切な値を設定する必要があります。

情報が古くて申し訳ありませんでした。経済産業省様のご支援を頂いて作成してきたガイドラインやモデルは、MBD推進センター（JAMBE）の発足に伴い、EPC様のHPから移管され、現在は、以下の場所で公開されております。
<https://www.jambe.jp/system/download>

アメリカは　足並みをそろえる＝独禁法違反　という縛りが日本や欧州に比べて強いです
なのでまだモデル流通に向けた活動は意識はされていると思いますが、低調です。
SAEなどで語られ始めると動き出すとは思いますが、JSAEのようにはなっていません。

ご質問ありがとうございます。MBD推進センター(JAMBE)の発足に伴い、これまで経産省の委託事業として公開されていたEPCのホームページから、JAMBEのホームページにガイドライン類の公開が移管されております。下記をご参照頂ければと思います。
<https://www.jambe.jp/system/download>
→No 20002です。

おっしゃるように、コンポーネントのモデリングに注力でき、直観的にシステムレベルのモデルが構成できる点で、非因果モデリングはメリットが大きいです。弱点として考えられるのは以下のような点です。
１．モデリング言語の仕様
　既にある要素でモデリング可能な場合は良いのですが、既存の物が無いコンポーネントのモデルを詳細に記述しようとすると、ModelicaやVHDL-AMSと言ったモデリング言語を駆使することになります。コードレベルでの記述が必要になるので、少しハードルが上がるかもしれません。
２．実行速度
　モデリングそのものの生産性は非因果モデリングの方が高いと思いますが、計算実行時の速度は因果モデリングベースのツールに比べると若干遅い傾向があるように感じています。
３．計算結果
　システム全体の式の統合や演算をツールが担っているため、同じモデルでもツールによって若干計算結果が異なることがあります。もちろん因果モデリングでもソルバーを変えたりすると計算結果は変わるので、計算結果の妥当性を見極める力はどちらも必要になります。
４．ツールの普及度
　まだまだ非因果モデリングツールが普及している状態ではないので、モデルをそのまま流通をしようとしても先方がツールを持っていないという事がネックになる可能性があります。
５．ツールの値段
　4.とも絡みますが、非因果モデリングの商用のツールは値段が高い傾向があります。OpenModelicaのようなフリーツールはありますが、この場合はサポートがないため、問題が起きた際に自力で解決する力が求められます。

サイトは以下になります。
<https://epc.or.jp/fund_dept/sim_foundation/2020model>
複数のリンクがあるため分かりにくいのですが、
株式会社デジタルツインズ様の成果物の所になります。

ご質問ありがとうございます。I/Fガイドラインは、ツールに依存しないようにしており、接続する物理量の部分に着目したガイドラインです。おっしゃる通り、ツールで動作する/しないは、別の議論になります。現在、モデリングツールは様々なものが存在しますが、モデルを流通する場合には、FMI(Functional Mock-up Interface)と言う規約に基づいたFMU(Functional Mock-up Unit)と言うものにモデルを変換して行うのがメジャーになってきています。つまり、モデルを作る際にはいろんなツールを使用可能ですが、流通の際には標準フォーマットに従ったコンポーネントでやり取りしましょう、と言うものです。ツール間の互換性等も公開されていますので、下記を参照頂ければと思います。
<https://fmi-standard.org/>
なお、ご参考までに、モデルを「作る」際のツールとしては、MATLAB/Simulink/Simscape系、Modelica系(Dymola,SimulationX,MapleSim等)、VHDL-AMS系(TwinBuilder等)があります。

因果・非因果モデリングの動画のデモで紹介されたように、
「Open Modelica」というオープンソースの非因果ツールが公開されており、
”OpenModelica”をWeb検索いただければ、サイトから、ダウンロードして、利用可能です。
 
https://www.openmodelica.org/
 
 OpenModelicaは非因果中心のモデリングツールですが、因果的なブロックもライブラリとして用意されているので、Simulinkのような因果的なモデリングも可能になっています。

他にもScicosという、Simulinkに似たフリーソフトがありますが、数年前に評価した限りではあまり安定していませんでしたので、あまりお勧めは出来ません。

ご質問ありがとうございます。
「プラントモデル」のモデルについては、特に複数の要素を組み合わせる場合の生産性（作成効率）は、非因果モデリングツールの方が高いと考えています。個々の要素間の接続が線一本で出来、システム全体の振る舞いの計算をツールに任せることができるためです。
一方、因果モデリングツールで代表的なものはSimulinkですが、これはブロック線図に基づいてモデリング出来る「コントローラモデル」に適しています。「プラントモデル」においては、事例で示したように、微分方程式をそのままブロック線図で示してしまうと可読性は低くなるため、結果として再利用性も下がってしまうと思います。Simulink開発元もその点は理解しており、「プラントモデル」は、Simulink上でも動作できる非因果モデリングツールであるSimscapeを開発しています。
ですので、一般的に言えば、「コントローラモデル」には因果モデリングツール、「プラントモデル」には非因果モデリングツール、と言うことになります。

ただ、Simulinkに比べて、他のモデリングツールは圧倒的に普及度が低く、会社によって使っているツールも違っていたりすることもあるので、そのままモデルを提供しても、相手先がツールを持っていない、と言うような所が難点となると思われます。ですので、例えば自社内は非因果モデリングツールでモデル化をした上で、流通の際には因果モデリングツールで動く形に区切って提供するのが良いと思っています。（以前よりも変換に伴う問題は起きにくくなっていますが、この変換が心配だ、あるいは、非因果モデリングツールを追加で導入するコストが大きい、というようなケースでは、もし既にSimulinkをお持ちであれば、そのままSimulinkでモデル作成するのも致し方ないとは考えています。）

ご質問ありがとうございます。色々と考えてみたのですが、ご質問にあるような適用が難しい対象と言うのが思いつきませんでした。あるとすると、非因果モデリングツールでは、因果モデリングツールで起きる代数ループのような問題も解いてくれることが多いのですが、逆に計算過程がツールに依存してしまって見えにくいので、トラブルが発生した時のエラーが分かりにくく、対応が難しい点はあるかと思います。

ご質問ありがとうございます。　
デメリットについていろいろと考えてみたのですが、強いて上げるとすれば、以下の点があるかもしれません。　

　1) 非因果モデリングツールでは、因果モデリングツールで起きる代数ループのような問題も解いてくれることが多いのですが、
      逆に計算過程がツールに依存してしまって見えにくいので、トラブルが発生した時のエラーが分かりにくく、対応が難しい。
　2)非因果モデリングツールの方が、モデリングは素早く行えますが、計算速度は少し落ちる印象がある。

はいその理解で適切だと思います。
作成する目的は、最初にコンセプトの成立性を見たいときや、詳細なモデルに対して境界条件を与えるために作成することになると思います。

　一般的には、制御のコントローラモデルには、因果モデリングツールを、また、プラントモデルには、非因果モデリングツールを用いるなど、使い分けをするのが良いと思っています。
　「プラントモデル」に関して、特に複数の要素を組み合わせる場合の生産性（作成効率）は、非因果モデリングツールの方が高いと考えています。個々の要素間の接続が線一本で出来、システム全体の振る舞いの計算をツールに任せることができるためです。
一方、因果モデリングツールで代表的なものはSimulinkですが、これはブロック線図に基づいてモデリング出来る「コントローラモデル」に適しています。「プラントモデル」においては、事例で示したように、微分方程式をそのままブロック線図で示してしまうと可読性は低くなるため、結果として再利用性も下がってしまうと思います。Simulink開発元もその点は理解しており、「プラントモデル」は、Simulink上でも動作できる非因果モデリングツールであるSimscapeを開発しています。
しかし、「新たな言語を勉強するのはハードルが高い」「既存資産がある」等の理由で、例えばSimulinkでモデル化を行っている事も多々あります。理想的にはツールレベルで揃える方が良いのですが、なかなか難しいと言うのが現状です。
　
また、Simulinkに比べて、他のモデリングツールは圧倒的に普及度が低く、会社によって使っているツールも違っていたりすることもあるので、そのままモデルを提供しても、相手先がツールを持っていない、と言うような所が難点となると思われます。ですので、例えば自社内は非因果モデリングツールでモデル化をした上で、流通の際には因果モデリングツールで動く形に区切って提供するのが良いかもしれません。（以前よりも変換に伴う問題は起きにくくなっていますが、この変換が心配だ、あるいは、非因果モデリングツールを追加で導入するコストが大きい、というようなケースでは、もし既にSimulinkをお持ちであれば、そのままSimulinkでモデル作成するのも致し方ないとは考えています。）

ご質問ありがとうございます。
質問の意図を正しくとらえられていない部分がありますが、「OpenModelicaで作成したモデルをFMUでエクスポートして、MATLAB/Simulinkでインポートさせて動作させること」と考えて回答致します。
このパターンは、原理上は動作可能です。
下記ホームページで、OpenModelicaはFMUを生成できますし、SimulinkはFMUのインポートが可能になっています。
<https://fmi-standard.org/tools/>
ただし、OpenModelicaのFMU生成機能はver1.19.1時点の実態として、きちんと動作しませんでした。
（これは私が個人的に試したものですので、うまくいくケースもあるのかもしれません。）
その後さらにバージョンが上がっていますので、現時点では動作するようになっているかもしれません。
なお、MATLAB/Simulink側は、追加で必要なToolboxはありません。Simulinkの標準機能として利用できます。
(バージョンアップなどで方針が変わっていたら申し訳ありません。）

ご質問、ありがとうございます。
まずプロセスについて説明します。
以前、経済産業省の事業として実施していた際には、委託を受けた会社が、自動車関係各社に対して参加要請し、その代表者が集まった「ガイドライン構築委員会」という場で、内容を審議していました。現在は、MBD推進センターの中で議論されており、具体的な議論は「プラントモデルI/FガイドラインWP（ワークパッケージ）」、その内容の承認は、上位の「モデル流通推進委員会」、さらに上位の「企画統括委員会」で審議されるプロセスになっています。
（参考：https://www.jambe.jp/）
判断基準については、特に決まったものはなく、上記のプロセスの中で、参加した方々の意見を集約しながら進めているのが現状です。

SURIAWSE2.0は　プロセスの上流（企画から少し降りてきたところ）を１D系のモデルをサプライヤや社内で共有することでエコシステムを造ることを目指してます。現在ここは徐々にユースケースが増えてきていることはJAMBEで実践事例報告会でも会員様へ公開しております。また下流工程でのCADデータの流通も３DAという活動で、地域のサプライヤ殿とCADデータを共有してCADデータが集まれば性能のシミュレーションができて、大きく効率化する事例が出てきています。また学でもJAMBEが公開している車一台分のGenericモデル（１D系）を用いての研究事例が学会でも複数発表されてきており、認知が進んでいる状況です。
さらに車単体での開発はSURIAWASE2.0を強化していきますが、車の外のサービスとのセマンティックレイヤでのAPI定義をして、将来の混乱を防ごう（５G,6Gにしても車載通信は帯域が狭いので）というSURIAWASE3.0を提唱しております。

下に示すのが全体像です。これまで車単体の話の開発効率化を中心に進めてきてます（SURIAWASE2.0）。ご存じの通り、今後のクルマは車外のシステムと繋がります、その際のルールやインターフェースの議論を進めてリードすることで車を中心とした社会の変革をサポートしていく　という姿をSURIAWASE3.0として目指そうとしております。

ご質問ありがとうございます。基本的な捉え方は、おっしゃる通りだと思います。細かな部分で補足します。
・非因果モデルの個々の要素の中は因果律によるブロック線図で書く必要はなく、非因果律の要素(慣性モーメントなど)の組み合わせだけでも構成でき、それらをさらに細かくしていくと、現象を記述する数式となります。
・「手間の差」と書かれてある部分は、個々の要素をつなげて大きいシステムとなった時に、非因果モデリングでは全体の調停をツールが行ってくれると言う点かと思います。この際の解法は、数式による処理（微分代数方程式）になります。一方、因果モデリングでは、代数ループのような問題が発生し得るので、モデルを作る人が調停を行う必要があり、全体の解法は常微分方程式になります。（さらに細かく言えば、モデル化の時点である程度のルール化を行うことで、全体の調停をしなくて良いような因果律ベースのモデリング方法もありますが、少し話がややこしくなりますね・・）
非因果モデリングにおいても、ブロック間でやり取りしている情報は、因果モデリングでやりとりするような物理量になりますので、因果の関係を理解しておくと、非因果モデリングにおいてもイメージが付きやすいかと思います。

ご質問ありがとうございます。
明確な強み・弱みを示すような指標はないので、感覚的なものになってしまいますが、0D/1Dから3Dまでモデルを使って仕事をしようという動きが全社的に浸透しているのが強みではないかと思います。それは、開発リソースが少ないマツダとして、知恵を絞り開発を効率化することで対抗していく、と言う思いが、トップ含めてある種当たり前になっている所から来ているものと考えています。逆に弱みですが、仮にマツダがモデルを使って仕事をしたいと思っても、(マツダとしてノウハウのないような、あるいは開発初期の)部品レベルではサプライヤさんの協力が必要ですが、マツダのためだけだと対応してもらえないような場合もあります。その意味で、モデルを使った仕事が当たり前の状況を日本全体で作っていく必要があり、仲間を作りながら「当たり前」の状態にしていかなければならず、それがJAMBEの活動の意義の一つでもあります。

浸透度に関しての情報は残念ながら持ち合わせておりません。
一方でガイドラインそのものは特別なことを述べているのではないので、既に皆さんがモデルをやり取りする際には意識するしないに関わらず、“ほぼ”これに準拠されていると思います。もしこれを見て、“ない“部分を指摘して　やりましょう　というのは自然な受け入れがされるはずであると理解しております。
ルールの統一は、正直　関係する両社ですり合わせることになると思います。ただし、目的やそれに応じた粒度などをすり合わせれば、過去の実践事例などからも着地点は必ず見つかると思います。