先回のコラムではPLM上で管理している製品マスターデータを軸とした「データ一気通貫」についてお話しました。今回はそのデータ一気通貫の取り組みのなかから、「シミュレーション」にフォーカスをあてたいと思います。

せっかくCADで製品3Dデータを作っていますので、その3Dデータを使ってコンピュータ上で仮想試作・試験を行い、実機試作の前に製品性能・品質を作り込んでしまいたいものです。そうすることで開発のフロントローディング化を推し進められ、下記の実現が近づいてきます

- 実機試作にかかる費用の削減

- 試作および評価期間の短縮

- 実機製作後の設計のやり直しの削減　など

しかし、これらは単にシミュレーションツールを導入するだけでは実現しません。そこで、今回はどうしたらシミュレーション活用の効果を最大化できるのか？をPLM的観点から紹介していきたいと思います。

なお今回のコラムでは「シミュレーション」、「CAE」、「MBD」という言葉が出てきますが、それぞれ以下のような定義で使用しています。

- シミュレーション…コンピュータ上で製品・システム・部品の性能・機能・品質を予測すること

- CAE…Computer Aided Design：CADの3D形状を直接的に利用する構造解析や流体解析などのシミュレーション技術

- MBD…Model Based Development：システムの挙動を数理モデルで定義しシステムや部品の挙動を予測するシミュレーション技術およびその活用手法

あいかわらず実機試作してるよね～

CADを入れて3D設計が定着した、そしてシミュレーションツールも入れて日々解析も行っている。それなのに、試作フェーズ回数や試作機台数はこれまでと大して変わっていない、という状況に皆さまの会社では陥っていないでしょうか。

もしそのような状況なら、開発プロセスとデータ管理について考え直してみるとよいかもしれません。シミュレーションツールは技術開発にとって非常に有用な手段ですが、実機試作を減らしたい場合は開発プロセスそのものに手を入れ、そのプロセスにあった関連データの管理方法を定着させる必要があります。

シミュレーションに使った製品データを特定できるように

まずは、シミュレーションに関連するデータの管理について考えてみます。

シミュレーション結果の管理をしっかり行うことはもちろんですが、重要なのはCAEに使った3D製品データがどれか？どのバージョンだったか？が辿れるようになっていることです。CAEの結果で「OK」だったとしても、そのCAEに使った製品データが実機試作で用いられるものと異なればその「OK」という結果は意味のないものになってしまいます。しかしCAE結果と製品CADデータが紐づいて管理されていれば、もし製品形状に変更が入った場合でもCAEをやり直さないといけない、ということに気付けるようになります。

また、MBDを活用する場合でも、どの部品のどの諸元を利用したか？が辿れるようになっていることが必要です。こちらは後述のセッションでもう少し詳しく紹介します。

しかし、上記のような管理ルールを制定していたとしても、製品形状の更新とCAEの実施が無秩序に行われているようでは、最新CAE結果と最新製品形状の整合性確保は困難なものとなります。そのような場合には、「バーチャル試作」フェーズを開発プロセスに織り込むことを検討します。

試作出図後にモノづくりが行われ実機評価が始まる実際の試作プロセスと同じように、「バーチャル出図」をして、そこで出図されたデータで「バーチャル試作評価（シミュレーション）」をするというフェーズを開発プロセスに新たに設けるのです。そうすることで、最新製品データによる最新CAE結果の担保が確実にできるようになります。開発プロセスにおけるシミュレーションの重要性も高めることができるでしょう。

そのためには、現在行っている実機試作評価のうち、シミュレーションで代替できるもの、実機試作でなければ評価できないことの仕分けを行わなければなりません。設計部門、解析部門、試作部門、評価部門、生産技術部門などの関係部署を巻き込んだ変革が必要になります。

MBDの結果と製品データの関係

近年、開発の上流工程で製品のシステム全体の仕様や動作・性能検証を行うMBDの活用が広まっています。このMBDで得られた結果は製品仕様や主要部品の設計指標・設計諸元となるため、これら仕様・諸元情報をその後工程となる製品設計などにキチンとつなげていくことはとても重要になります。世間では「要件管理」というカテゴリーに分類される取組になります。

要件管理の詳細については今回触れませんが、PLMの観点からは製品3Dデータがどの要件と紐づいているか、つまりどの仕様・諸元を満足しなければならないのか？がわかるようになっていることが大切になってきます。そうすることで、上位仕様・諸元が変わったときに変更しなければいけない部品が明確になりますし、逆にある部品が要求仕様を満足できそうにないケースに、もし仕様変更したら製品システム全体へどれだけ影響を与えるのか？を把握することができるようになります。

MBDもCAEと同様に、ただ単にシミュレーションツール導入に留めるのではなくこのような製品データなどとの関連付けをしていくことができれば、開発プロセス全体でのやり直し削減に大きく貢献することができるようになります。

シミュレーションに加え実機評価まで含めたデータ管理・連携を

今回の内容を、開発の上流から整理してみましょう。

1. MBDで製品システム全体の仕様を検討する（インプットに実機評価結果や各部品諸元などを使う場合あり）

2. 製品仕様と製品3Dデータを紐づける

3. 製品3Dデータ詳細設計を行う

4. 設計途中にCAEを活用し設計品質を高める

5. バーチャル試作フェーズのためにバーチャル出図を行う

6. 出図された製品3Dデータを活用してバーチャル評価（シミュレーション）を行う

7. シミュレーション結果は出図した製品3Dデータと紐づけて管理する

8. 実機試作する

9. 実機評価を行い、その結果を管理する

10. 評価結果に基づき、仕様見直しや設計変更を行う

これら各プロセスで生成されるデータを管理（管理システムは一つのシステムに統合されていなくてもよいです）し、PLMでその関係性を把握できるようにすることが「データ一気通貫」の核心です。これにより開発のフロントローディング化実現にぐっと近づけるようになるでしょう。今回は設計の事例でお話しましたが、型設計や生産準備などのプロセスでも同じ考えでデータ管理・連携をしていくことが必要です。

この取組を推進していくと管理対象となるデータが多岐に渡ってきます。PLM以外のシステムで管理されているデータも増えて異システム間の連携なども考慮する必要が出てくるため、システム的な難易度も上がってきます。社内IT部門や社外ベンダーなどを巻き込んだチーム作りも考えなければいけません（このあたりは第8回のコラムで紹介します）

連載コラム「いまさら聞けないPLM入門」の第6回「シミュレーションを活用しよう　～ PLMとCAEとMBDの関係 ～」は以上になります。ここまで取組が進むと自社のPLM内で管理・連携しているデータがかなり増えてきていると思います。そこで次回コラムでは、これらデータを社外の協力会社などと共有していくうえでのやり方や注意点などについて紹介したいと思います。