営業部通信：単純現象の組み合わせで成り立つ複雑現象
皆さま、こんにちは。
IDAJの営業部：担当Xです。
突然ですが、私は昔、器械体操をしておりました。
そこで学んだことはたくさんありますが、その一つが『複雑だと思うことも、実は単純な動作の組み合わせであると』いうことです。
言葉で説明してもなかなかイメージすることは難しいと思いますので、2016年リオデジャネイロオリンピック体操 男子個人総合王者の内村航平選手の鉄棒の技を例にご説明します。
ぜひ一度、「NHK おうちで学ぼう！for school」（リンクはこちら） で、内村選手の決勝での圧巻の演技をご覧ください。
この動画の5分39秒からおよそ2秒弱の間が、有名な伸身の新月面宙返り（2回宙返り2回ひねり）です。
人によって異なりますが、この動作は以下のように分解することができます。
1回宙返り半分ひねり
＋
1回宙返り1回半ひねり⇒ 1回半ひねりを、半分＋1回と分解することもできます。
このような高速で複雑な動作を意識することなく、一種の“感覚”のようなもので、すんなりとやってのける選手がいました。彼らをとてもうらやましく見ていたものです。
しかし、私の場合は彼らのようにはいかず、このような技に取り組む場合には、一度、一連の動作を細かい動作に切り分けて、一つずつの動作を丹念に繰り返しながら、最終的に一つの技として構築する方法をとっていました。
最近、私がこのことをとても強く意識し始めたのは、MBDに関するソリューションをお客様にご提案するようになったからです。
MBD（Model Based Development / Design、モデルベース開発）は、もともとは制御ソフトウェアの開発手法で、制御開発の上流工程において、制御モデルと制御対象となるプラントモデルを組み合わせたMILsを用いてシステムのふるまいを検証する手法です。自動車業界を中心に、「制御対象となるプラントそのものの設計開発＝メカやエレキの領域にMBDの考え方を拡張」が進んできました。従来は主に開発の上流工程でシステムシミュレーション（1D-CAE）を取り入れることを指していましたが、最近では3D-CAEも含めシミュレーションを使った設計開発手法全般をMBDと称す場合も増えています。これには、製造業各業界を取り巻く環境の変化が大きく影響しています。
MBDにおいては、シミュレーションの活用が不可欠ですが、CAEを適用することで開発は効率化できたのでしょうか？
開発プロセスにおける構想設計の段階では、熟練技術者や少数の主要技術者が「匠の技術（いわゆる”カン・コツ”）」によって検討、あるいは内製ツールによる簡易計算を行うことで全体構想を描きます。その後、Assy設計と部品設計を行い、シミュレーション（CAE）は設計が目論見通りに性能を発揮するか否かを評価するために、設計プロセスにおける下流工程で使われています。また、シミュレーションの対象も部品単体の構造解析や流体解析などの限定的な範囲でしか適用されていません。万が一、この段階で意図した性能が出ていないとなると、Assy設計やシステム評価の下流工程で手戻りが発生し、大きなロスを生むことになります。もちろん、今でも試作数の低減や自動化技術と組み合わせた解析技術を適用することで、一定の効果は得られてはいます。しかし現状では、いずれもボトムアップで、詳細なものから簡単なものへ組み込むという評価CAEの中での活用が進んでいるにすぎません。弊社のお客様でもある、マツダ様のお言葉をお借りすると「CAEの活用はモデルベース開発への序章」なのです。
これまでのプロセスに対してMBDを適用した場合には、従来のCAEのボトムアップの考え方とは異なるため、新しいプロセスが必要です。自動車設計を例にとると、まずはマーケットの要求があり、それに対して燃費の向上率やCO2の削減率などの性能目標が設定されます。ここから機能展開をし、燃費を改善するためにはどういった性能がエンジンに必要なのか、そのエンジン性能を達成するには、どのような機能を改善する必要があるのかを、樹形図を用いたRFLP展開で目標機能と設計パラメータの関連付け作業を行います。ここで導出したシステムやプラントの機能に対する要求を、0Dまたは1Dのプラントモデルに落とし込みます。そしてシステム全体の挙動検証や、最適緒元・目標達成度の予測、プラントを構成しているそれぞれのシステムの性能目標値をすりあわせます。そうして決まった性能の目標値をシステムモデルやサブシステム（エンジンであれば、クランクやシリンダ、動弁系などが構成要素）の目標値に落とし込み、1Dシミュレーションで検証したり、詳細の検討が必要な場合には3Dシミュレーションを活用します。
つまり、それぞれのサブシステムから、一つ一つのパーツや材料に対する目標値に落とし込んでいきますので、上位モデルが下流工程の「動く仕様書」となります。CAEのようなボトムアップ型ではなく、トップダウン型の考え方を取るのがモデルベース開発（MBD）の基本です。
開発製品によって企業によって設計プロセスは様々ですが、MBDのねらいは「高いレベルでの協調設計を実現するための手段」と言えるのではないでしょうか。
設計フェーズ／開発ドメイン間の認識の共有
ドメイン間で独立した開発からドメインを跨いで連携する開発へ
開発プロセスの改善による開発期間の短縮
コンカレントエンジニアリングの実現
品質の確保
パッチあて設計からの脱却と本質に基づく設計へ
では、高いレベルでの協調設計を実現するには、どうすれば良いでしょうか？
ポイント1：システムを俯瞰した設計開発
開発のターゲットとなるシステムやコンポネント（SOI; System Of Interest）だけでなく、取り巻く外部環境（境界条件）、1つ上位のシステムはどのような要求・要件を満たす必要があるのか？ SOIの要求・要件がどのように下りてきているのか？ といったその「外側」を意識する必要があります。
ポイント2：段階的詳細化
システムに対する要求やふるまい、アーキテクチャなどを抽象度の粗いものから細かいものへ、反復しながら段階的に設計していきます。要求分析とアーキテクチャの設計をそれぞれ個別に深堀りするのではなく、抽象度の粗いものから階層を分けて段階的に詳細化します。これに合わせて必要なモデルの抽象度も段階的に細かくなっていきます。
ここで欧州のおける取り組みをご紹介します。車載システムの開発プロジェクトにおいて実施されるべき活動をベストプラクティスとしてまとめた「開発プロセスの評価と改善のための共通言語」であるAutomotive SPICE（A-SPICE）。アセスメントという形で、開発プロジェクトにおいて実施した活動や作業成果物をA-SPICEに照らし合わせて評価し、開発プロジェクトの課題を抽出、プロセス改善を図ります。欧州では、OEMメーカーが各サプライヤーに対してA-SPICEへの対応を要求しています。当初は、ソフトウェアエンジニアリングをターゲットにしていましたが、近年は、メカニカルエンジニアリング向けのプロセスモデルへも拡張されています（Mechanical SPICE）。
回り道をしてきましたが、ここで冒頭の「複雑な現象を単純化し（機能ばらし）、各現象を確認する」というお話に戻ります。開発ターゲットとなるシステムやコンポネントは、必ず何かしらのシステムの構成要素となっており、同様の視点はシステムの複雑さに関わらず必須です。設計の段階的詳細化に合わせて必要十分な粒度を持つモデルを使いわけることが重要です。
上位のシステムに対する要求から、ターゲットとしているシステムの要求を具体化し、制御因子（機能）へ展開する
↓
各機能にサブシステムの構成要素を割り当て、要求を実現するためのコンセプトを検討する
↓
背反を考慮した上で上位のコンセプトの成立性を検討し、サブシステムの特性値に対して目標割り付けを行う
↓
サブシステムに対する要求を段階的に下位のサブシステムもしくはコンポーネント目標に落とし込む
↓
コンポーネント目標を満たす3次元形状を同定する
弊社では、「MBDプロセス構築コンサルティング」を承っておりますので、お困りごとやご不明な点がございましたら、お気軽にお問い合わせくださいますようお願いいたします。
■IDAJがご提供するオンラインコンテンツをご紹介しています。
■オンラインでの技術相談、お打合せ、技術サポートなどを承っています。下記までお気軽にお問い合わせください。ご連絡をお待ちしています。
株式会社 IDAJ 営業部
Webからのお問い合わせはこちら
E-mail：info@idaj.co.jp
TEL： 045-683-1990