第12回熱解析結果を効果的に設計につなげるSTREAMのHeatPathView：設計者に寄り添った機能強化でより使いやすく

以前にも増して、解析ソフトウェア業界が設計者を意識し始めている。熱流体解析ソフトウェアにおいても、それは例外ではない。ここではその一例として、国産の熱流体解析ソフトウェアのベンダーであるソフトウェアクレイドルの解析ソフトウェア「STREAM」（ストリーム）向け解析結果表示ユーティリティ「HeatPathView」（ヒートパスビュー）を取り上げる。

[PR／MONOist] PC用表示

LINE

Hatena

設計に役立つ流体解析 top＞

　ソフトウェアクレイドルでは、「STREAM（および、熱設計PAC）」と「SCRYU/Tetra®」という2つの熱流体解析ツールを提供している。どちらの解析ツールも「空気の流れや熱の移動などを計算する」という目的は共通しているが、メッシュ分割方法が異なる。STREAMは解析をする領域の形状にかかわらずメッシュをサイの目状に分割する直交構造格子のメッシュを採用しているのに対して、SCRYU/Tetra®の場合にはオリジナルの外形線にフィットするように分割する非構造格子系のメッシュを採用している。直交構造格子の場合、メッシュ分割が手軽ではあるが、形状の表面が微小な階段状になる。

　直交構造格子を採用するSTREAMは細かい形状が解析結果に影響を与えないタイプの解析に用いて、非構造格子を採用するSCRYU/Tetra®は車体の空力性能など詳細形状が重要な解析に用いるというのが1つの選択基準となる。今回紹介するのは、前者であるSTREAMのユーティリティ「HeatPathView」である。

解析結果を設計にきちんと反映させるHeatPathView

　熱流体解析のソフトウェアは、ソルバーを中心に多くの機能が成熟してきている。現在はより大規模な解析を高速に実行するとともに、いよいよ設計者でも使えるユーザビリティにも力を入れ始めている。実際、解析結果を設計に反映させるという部分が1つの壁になっていることも少なくない。

　そのような状況を解消するツールの1つが、HeatPathViewだ。設計開発現場の技術者が熱流体解析をする大きな理由の1つは、「いかに効率よくコンポーネントの温度を下げるのか」。熱流体解析ソフトウェアには多くの機能が備わっているが、それらが、解析の目的へ確実につながらなければならない。

　単に「温度の分布を知る」ということだけではなく、「熱の流れがどのようになっているのか」「どのように設計を変えれば、もっと効率よく温度を下げられるのか」も把握したいという現場のニーズがある。言い換えれば、ある部品の温度が特に高い場合、その部品を特定して温度を知るということだけでは不十分だ。「なぜ、その部品が、その温度になっているのか」ということを知ることが、実際に設計を進める上では必要だ。

　もちろん、熱の流れを可視化すること自体は、従来のポストプロセス機能を使うことで十分に可能だった。しかしそれは、あくまでも既存の機能の組み合わせによることだった。設計者は「熱の流れが分かりやすく簡単に分かり、それを対策のために役立てる」という、従来のツールからすると逆引きともいえる機能を求めていた。そこで登場したのがSTREAMの一機能として開発された「HeatPathView」という機能である。

　しかし一言で「熱の流れを分かりやすく可視化し、全体像が大局的に把握できるように情報を提供する」といっても、そう簡単ではない。

　そのような課題に対して同社は、技術者にとって最も基本的な情報を整理することにしたという。HeatPathViewでは熱を扱うエンジニアにとってなじみの深い「伝熱の基本3形態」（熱伝導、熱伝達、熱輻射）を意識した情報の伝え方にした。このフレーズを使って整理することで、設計者もなじみやすいものになると考えたとのことだ。

“設計者寄り”なHeatPathViewの機能

　ここからは、LED電球を用いて具体的にHeatPathViewの機能を説明する。

　HeatPathViewのユーザーインタフェースには主に3つのタブを備え、それを切り替えながら状況を知り、それを「どのように設計に生かしていくのか」を考えていく。「部品温度」のタブでは各コンポーネントが属性とともに最高・平均温度などの情報を把握し、「問題のあるコンポーネントがないかどうか」を把握する。

　「ヒートバランス」のタブにおいては、製品を構成する各コンポーネントの平均温度が分かるだけではない（図1）。

図1 ヒートシンクの放熱／受熱バランス（ヒートバランスタブ）

　例えば、その中の着目したいコンポーネントを選択すれば、「どこに対し、どのくらいの熱量が移動しているのか」「その熱源はどれなのか」ということが、受熱・放熱のバランスとともに一目瞭然だ。これによって設計者が現状を把握しやすくなるわけだ。

　3番目のタブである「ヒートパス」は、「どのように熱が流れているのか」、つまり放熱の経路を把握することを目的とする（図2）。

図2 LED素子からの放熱経路（ヒートパスタブ）

　図2は、LED素子からの放熱経路を示している。この図が示しているのは、「LED素子からの熱は、配線層から基板へ」「ヒートシンクへ」「そして空気へ」……という流れと、その経路上のコンポーネントの温度と部品間熱抵抗である。

　メインの熱経路だけではなく、2番目以降の熱経路も簡単に調べられる。設計者は総合的に、「どこが放熱のためのボトルネックになっているのか」を「標準機能」で確認できる。このようにHeatPathViewは、非常に“設計者寄り”の機能となっている。

設計開発現場を熟知したエンジニアの発案

　このHeatPathViewの開発をリードしたのは、技術部技術2課の衛藤潤氏。同氏は、ソフトウェア開発部門ではなく、エンドユーザーを実際にサポートすることを主要な業務としている。つまり設計開発のフィールドに身を置くエンジニアなのだ。だからこそ、HeatPathViewも非常に現場を意識した機能となった。

　通常、新機能はソフトウェア開発部門が中心になって開発する。しかし今回、ソフトウェアクレイドルでは、現場技術者のリードの下に開発を行った。このような柔軟性は、実際のユーザーと開発部門が物理的に非常に近い場所にある国内ソフトウェアベンダーだからこそ実現できたといえる。この取り組みをはじめとして、今後とも、一層ユーザー目線の開発が進むことが期待できそうだ。