データ活用からナレッジ活用へ ～ モードによる評価と履歴データの活用 ～（後編）

はじめに

前回のブログでは、計算モデルや計算結果のような数値データだけでなく、バージョン管理のなかで生まれるドキュメントを含むデータ活用の考え方についてご紹介しました。今回は自動車衝突安全シミュレーションの事例を用いて、どのような効果が期待できるかについてご紹介します。

自動車衝突安全シミュレーションでの事例

モード分解を用いた類似形状検索と、バージョン管理システムを用いたモデル変更の履歴管理を行うことで、どのようなことが可能になるでしょうか。皆さんもご経験があると思いますが、業務を行っていく中で見覚えのある状況に遭遇することは少なくないと思います。自身が行った検討であれば記憶を頼りにメールやフォルダーをひっくり返して参考になるデータやドキュメントを見つけられるかもしれません。しかしそれが別の誰かが行った検討であればそう簡単にはいきません。結局また一からデータやドキュメントを作成することになってしまいます。

もうひとつの問題が、レポートなどのドキュメントはあらかじめ定められた性能評価指標のような代表値に基づいて書かれるので、その値で検索をしても困っている現象にヒットしにくいという問題です。つまりトラブル指数のような検索ができないということです。しかし先述のように、現在困っている挙動そのものをキーとして検索ができ、どこかの誰かが作成したモデル、ドキュメントが紐づいていれば、試行錯誤の結果や分析レポート、議論の議事録などを参照することで検討の方針を参考にしたり、やっても無駄な検討を省いたりが可能になるはずです。

今回、事例として自動車衝突安全解析のフルフラットケースで、Ansys LS-DYNAを用いた構造計算を行いました。問題の単純化のため、エネルギー吸収部材の厚みを変更して性能を向上させる課題において変形モードで好ましくない状況が発生した場合を想定します。また、開発の初期状態をV01として複数のエンジニアが板厚に変更を加える検討を行い、変更のたびにバージョンが1つずつ上がるものとします。

実際の現場では枝分かれをした数百の検討結果ですが、ここでは簡単のため、V19で受け取ったモデルに対して変更を行いV20として計算を行った際に、左側の部材に望ましくない変形モードが発生したとします。

もしここで何の手掛かりもなければ、どう対策するかは担当するエンジニアの能力に完全に依存してしまいます。しかし、もし過去のバージョンの中に、同じような現象が起きていれば、その前後で行ったモデル変更やドキュメントを参考に対策をし、素早く対応することができます。

ここで対象とする計算におけるサイドメンバーのパートと着目する時刻を入力として、本手法によりすべてのモデルバージョンの各時刻における同一パートの形状についてモード空間の探査を行った結果を示します。この表において、列はモデルの各バージョンを示し、行はそれぞれの時刻歴での形状類似度を示します。また各セルの数値はモード空間における距離を元に算出した形状類似度を0から1の尺度で示した数値で、1に近づくほど形状が似ていることを示します。類似度は時刻ごとに計算されており検索対象のモデルについても算出されています。一番右の列の数字が徐々に上昇し最後に1になるのは初期形状から衝突によって部材が変形していき最終的に求める形状になったことを示しています。

分析結果としてV06、V11、V15に類似性が見られ、中でもV11がV20に極めて近い形状である事が示されました。実際にV11とV20の最終時刻における形状比較を行った結果と類似度が最も低いV18について図に示します。本手法で検索された形状はリファレンスであるV20におけるサイドメンバー挙動の特徴をよく捉えており、本手法により着目する形状そのものをキーとして似た現象が起きたバージョンを特定することができました。今回はモデル数が少ないため手動でもできなくはないですが、これが大規模モデルの比較となると膨大な時間が掛かります。

これをモード空間で見るとどのように見えるでしょうか。モード空間上の点はそれぞれ計算結果を示します。一般的にはこれらは「結果の分布」として扱われます。しかし、ここにバージョン管理という概念を導入するとこれはただの「分布図」ではなく、前後関係を持った「経路図」になります。開発が進みバージョンとともに性能が上がっていく経路は左上から右下の全体トレンドです。それに対してV06、V11、V15そしてV20はいわゆる外れ値であり、問題が起きるたびに対策が打たれ元の集団に戻っていることがこの図から読み取れるのです。

さらにGitには前回述べたように、変更を行ったユーザーの情報や、コミットメッセージとして変更の趣旨の記述、ドキュメントファイルの追加や更新などの情報も記録されており、エンジニアの思考や検討、判断の知的プロセスも読み取ることができます。これらの情報を得ることができれば、過去に試された打ち手をとりあえず試してみることも、それらを参考に自ら打ち手を考えることも、ユーザー情報を元に担当者に相談に行くことも可能になります。

データ活用からナレッジ活用、さらにその先へ

今回、自動車衝突安全解析におけるサイドメンバー変形モードを題材として、モード空間上における距離に基づく類似形状検索手法をご紹介しました。

本手法ではパートの節点すべてを用いモードとして形状を認識するため、検索タグのようなセンサーを事前に埋め込む必要も、パラメトリックCADのような特別なツールを使用する必要もないことが特徴です。またバージョン管理システムと組み合わせることで過去事例における発生要因分析や対策の思考プロセスを読み解くことも可能なことを示しました。また、それらを参考にすることで車輪の再発明を避け、有効な対策のみに時間を割くことも可能になると期待できます。今後、製品開発に対する要求が高まり開発期間や工数の削減がますます求められていく中では、異常検知技術により素早く問題を把握したり、類似挙動検索技術により過去知見を有効に活用したりすることがますます重要になると考えられます。

ところでDIKWモデルというのをご存知でしょうか。別名ナレッジピラミッドとも呼ばれますが、知的活動をData、Information、Knowledge、Wisdomの4階層に整理したモデルです。この図においてデータは最下層であり、データそのものを活用することよりも、エンジニアを媒体とした知的活動の成果であるドキュメントも活用するほうがはるかにレベルの高い成果が得られると考えられます。

昨今は生成系AIの進化も目を見張るものがあり、これまでは不可能だと思われていた非定型処理の自動化や自然言語の高度な処理なども急速に可能になってきています。今後加速度的に進化が進み、最終的にはナレッジをも超えた叡智（Wisdom）にも到達する日もそう遠くない気がしてきます。

シミュレーション業務で発生するデータの管理システムSCALE.sdmを提供しているSCALE社は先述のSAFECAR-MLのプロジェクトにも参画しており、SCALE.sdmにも試験的ではありますがすでに自然言語処理を用いてモデルの変更点を言語化する機能が追加されています。具体的にはバージョンを2つ選びボタンを押すと2つのバージョン間の差分を自然言語でレポートしてくれます。これにより作業レポートの工数削減はもちろん、バージョン間でエンジニアが意図した変更点と実際にモデルに施された変更がきちんと一致しているかの確認が容易になることで、作業ミスによる手戻りを大幅に減らすことが期待されます。ご興味持たれた方はこちらよりお問い合わせください。