3日～1週間かかっていた実測との合わせこみ作業を半日に短縮

まずはmodeFRONTIERのご利用用途からご紹介いただけますでしょうか。

最初は車両挙動シミュレーションの車両パラメータの合わせこみから始めました。車両挙動のシミュレーション結果が実測値と大幅に乖離した状態では、製品仕様や制御の確認の目的に対して適当ではありません。そのため、シミュレーションを調整して、できるだけ実測値に近づけておく必要があります。しかしながら、不明な車両パラメータが多い場合は実測値と合わないことが多く、そのパラメータを何度も調整して実測に合わせていきます。1回あたりのシミュレーションには数十秒から1分かかり、それを繰り返し実行すると、1つのパラメータを合わせるだけでも半日から1日以上かかります。検証する内容によってはシミュレーションをせずに目の前のテストコースで車両試験をした方が早い場合もあり、シミュレーションの準備に時間がかかっていては、シミュレーションする意味が失われます。このような不便さを解消し、かつ、合わせこみ業務を効率化するために、modeFRONTIERをカーブフィッティングに利用することにしました。
こちらはmodeFRONTIERと車両挙動シミュレーションソフトウェアveDYNA（註：現DYNA4）を連成させた事例です。modeFRONTIERとDYNA4はPythonスクリプト経由で接続することができます。4輪の車輪速の時系列の解析結果を実測と合わせるため、まずはエンジンのダイナミクスにかかる時定数やイナーシャなどをパラメータとして振りました。
その結果、エンジンのパラメータ調整だけでは合わせられないパラメータの存在がわかりましたので、トランスミッションのパラメータも併せて調整し、この段階で動力系はそこそこ合うようになりました。最適化計算のフローは私が作成しましたが、どのパラメータが寄与するのかを判断する際には、車両挙動シミュレーションツールのベンダーと一緒に探っていきました。

modeFRONTIERを適用された効果はどれくらいでしょうか。

手動で調整していたころは3日～1週間かかっていたパラメータの合わせこみ作業を半日程度に短縮することができました。
パワートレイン、シャーシ、ステアリング、タイヤ、路面など自動車全体で考えると、調整が必要なパラメータは軽く数百を越えます。これらのパラメータを一度に調整することはできないので、この中からシミュレーションのシナリオに対して寄与度の高いと思われるものを4～5個に絞り込んで手動で調整していました。1つのパラメータを調整し終わっても、その他のパラメータと合わせるとうまくいかないことがよくあるので、調整が終わったパラメータを再度見直して、改めて範囲を広げて調整するという試行錯誤を繰り返すことになります。直進時には動力系のパラメータ調整のみでもそこそこの結果が出ますが、旋回が加わると対象となるパラメータはさらに増加します。合わせこむべきパラメータが増えれば増えるほど、その調整には多くの時間を要するため、非常に悩みどころでした。
modeFRONTIERであれば、パラメータが増えても一度に合わせこむことができますし、シミュレーション中に自席を離れて別の業務にとりかかれることも大きなメリットで、日々の仕事の流れの中で効率的だと感じています。
今後、多目的最適化を適用したパラメータ合わせ込みの流れをより明確にして自動化を推進し、他のシミュレーション利用者にも利用しやすい環境づくりを目指したいと考えています。同じソフトウェアで車両挙動シミュレーションを実施している海外の同僚や部署内のメンバーへ展開できれば、シミュレーションを有効に活用する人が増え、各自の作業効率がアップし、部署全体として対応できる車両の種類を増やすことができます。

多目的最適化の設計者展開を視野に入れたシミュレーション環境づくりを検討中

少しお話を戻させていただいて、2016年に最適化ツールとしてmodeFRONTIERを選択された理由をお聞かせいただけますか。

当課の役割や最初に最適化したいと考えていたケースから、多目的最適化に対応したツールというのが条件でしたので、modeFRONTIERにほぼ決めていました。
車両挙動シミュレーションは性質上、パラメータが多く、トレードオフが多いこともわかっていましたので、単目的で一つのパラメータを合わせるというよりは、大きくパラメータを振って寄与度があるパラメータを見つけ、それらのトレードオフを含めてバランスのとれたパラメータを見つけるために、多目的最適化が可能なツールが適していると考えていました。
また、パレート解の選定時に必要なポスト処理機能の充実もポイントの一つでした。なぜこの製品仕様や制御パラメータに決めたのか？、なぜこの“効き具合”にしたのか？と質問された際に、“ある条件で最適化計算した結果です“、または“最適解は○○と△△のトレードオフから見てここにあります”と回答した方が説得力があります。
特に限界値は最適化の結果を使った方がうまく説明できる可能性があります。実験などの経験から来る値でパラメータを決定すると、経験していない領域にもっと良いパラメータが残っているのではないか？と疑問が残ります。そんな時は限界値だと予想したあたりをターゲットに最適化計算すれば、探索する余地があるか否かが見えてきます。
こういった結果を、社内外問わずわかりやすく示すためには、直感的に把握しやすい結果表示が必要だと思っていました。その点、modeFRONTIERはポスト処理機能が直感的でわかりやすく、また設計原理抽出機能（CAP）も搭載されているのが魅力的でした。
最適化ツールを検討し始めたときには、車両挙動シミュレーションのみを最適化の対象として、DYNA4専用ツールの開発も考えました。しかしその場合は、自分の業務にしか適用することができません。部署や会社全体のことを考えると、最適化を適用すべき業務は他にも数多くあります。多目的最適化ができること、最適解を可視化するためのポスト処理機能とともに、車両挙動シミュレーション以外でも使用可能で汎用性があることも選択理由の一つになりました。

先ほどご紹介いただいた車両シミュレーションパラメータの合わせこみ以外に、現在はどのようなご業務にお使いでしょうか。また、今後のご利用予定についてもお聞かせください。

弊社が設計・製造している駆動系製品の中に、車両の運動性能を向上させる製品があり、多目的最適化をこのような製品の理想的な諸元を決めるシミュレーションに適用しています。お客様が想定される条件に対して考えられる評価指標を達成するために、製品の諸元を最適化してご提案できるような活動を行っています。
設計分野での利用にもトライしています。制御を担当していると、製品の性能を上げるために機械的な設計諸元も変更したいと思うことがあります。手始めに、設計者が使っているエクセルでのトルク計算をmodeFRONTIERと連成させて最適化計算にかけてみました。この際、制御する立場として必要な項目、例えば、応答時間などに関する計算をそこに追加しています。これにより、このパラメータを上げるとトルクは高くなるけれど、上げ過ぎると応答が悪くなるといったトレードオフを可視化できるようになりました。この最適化結果をもとに制御を検討しなおすともに、設計者に対して改善案の提示できるようにすることを目的にしていましたが、このような活動が、設計者が最適化を利用するきっかけとなり、設計と制御のバランスの良いシステム作りにつながることを期待しています。
車両シミュレーションの誤差最小化を目的関数とするパラメータ合わせ込みからスタートして、製品開発にフィードバッドバックできる製品仕様の最適化のシミュレーションへと少しずつ技術構築を進めてきましたので、今後もその流れに沿った利用をしていく予定です。
車両シミュレーション誤差の最適化については、カタログではわからない諸元を、最適化計算で補完して実測値と合わせるという手順を整理して、うまく標準化したいと考えています。また、極力自動化も進めていきたいところです。
製品仕様の最適化については、製品のモデルと制御のモデルを車両挙動シミュレーションの中に取り込んだ上で、製品仕様とその制御パラメータをまとめて最適化することを目指しています。特に、制御パラメータの調整は、実際に乗ってみて決めていくことが多いのですが、最適化とシミュレーションで決定できる領域を増やしたいですね。また理想を言えば、シミュレーションの自動実行と並行して車両試験・制御適合を行えるような体制に近づけ、効率よく仕事をしたいという思いもあります。さらには先行開発に近いところにいますので、新規開発品であっても多目的最適化を適用できるようなアプローチを考えています。初めて開発する場合には、諸元の設定に迷うことがありますので、まずは、製品としての目標性能を決めて、最適化した結果を最初の諸元とし、同時にワーストのケースを作成しておくことで、早い段階から試作レベルを上げるアプローチができればと思っています。modeFRONTIERには設計原理抽出の機能がありますので、開発の早い段階から適用することにも興味が出てきました。活用のアイディアは数多くあるのですが、様々なプロジェクトを掛け持ちしているため、なかなか時間をとれないのが目下の悩みです。

このインタビューの詳細は季刊情報誌IDAJ news vol.99でご覧いただけます。
ユーザー登録済の方はユーザーサポートセンターからダウンロードできます。