＊1）バラックセットとは、構想段階の回路アイデアや従来モデルに不足している機能を補うために追加する回路を、ユニバーサル基板などを使って実際に組み立てたものを指します。あるいは、カスタムICを設計・開発するに当たって、ICや応用回路の完成度を高めるため、ICの開発と並行して、その機能を等価的に実装した回路ブロックをバラックセットという場合もあります。特にアナログICを設計・開発する際には、信号の回り込み（寄生回路）による誤動作が発生しやすいので、バラックセットによる事前評価は必要不可欠です。

　まずは、その使用目的から考えてみましょう。根拠・スタンスが曖昧なまま導入すれば、一度トラブルに突き当たった時に、「やっぱりダメだ。しょせん計算だ。実験とは違う」となって頓挫するのが関の山です。そのようなことは、この連載の趣旨からいえばとても不本意なことです。

　ですから、「イザ！トラブル」という場面でも信念がブレないように、SPICEを使用する理由を明確にすることは重要です。ここでは、「分かって設計する」という連載テーマに従って、次のように利用目的を大まかに3つに分けて挙げておきます。

1）設計案の事前確認・選択

　考案した設計案は必ずしも想定通りに動作するとは限りません。そこで、事前の動作確認や特性比較を、モノづくりの前に確認します。概略的な特性を得ることで、アイデアの取捨選択にもなります。簡略化モデルを使って、短い時間内に数をこなすのが特徴です。

2）他の解析ツールとの連携

　電磁界解析ツールや熱流体解析ツールを利用する場合、入力値が実際と10％異なっていれば、解析結果も10％ズレます。正しい波形を与えなければ高性能の解析ツールも正しい答えは出せません。妥当性のある波形を得ることが目的になります。解析の本数は少ないですが、精度が要求されるのが特徴です。

3）市場品質の予測

　市場に投入してからの機器の使われ方は千差万別であり、環境変動に対する感度が敏感・急峻であれば特性変動は避けられません。市場で不具合が発生するたびに評価条件を追加したり、いくら実験室で事前評価したりしても、全てを網羅できるものではありません。昨今の市場トラブルの多くは、そのような驕（おご）りと、評価モレから発生しています。市場品質を改善するためには、“どのような設計因子が特性変動の感度を左右しているのか"を見極める、品質工学的な評価が必要になります。実験計画法を使うので、解析本数が多い場合は簡略化モデルを使うときもあります。タグチメソッドを使って、設計因子の環境変動に対する感度の事前評価を行い、解析結果から感度に応じて必要な管理値・精度を検討します。

「分かって設計する」ために

　本連載は、先述した通り「分かって設計する」というテーマを基に進めていく予定です。この「分かって設計する」とは、設計出力を自由自在に変化させられることを意味します。言い換えると、それは設計を管理できるということです。

図1　「設計」を構築する知識ピラミッド（クリックすると拡大）

　そして、「管理する」ためには、設計因子がブラックボックスであってはいけません。設計するということは、図1に示すように、技術的知識の階層から構築されるピラミッドとして表現できます。

　「分かっている設計」とは、図1のようなピラミッドの頂点から裾野を眺めるようなものです。そして、その中での解析とは、物事を論理的に調べることであり、シミュレーションとはその解析のために現象を模擬する一手段にしかすぎないのです。決して、「シミュレーション＝設計」ではないのです。

　CAE（Computer Aided Engineering）とは、この「解析する」という目的のために、手計算や実機で対応し切れない事象についてコンピュータの力を借りて対応することです。また、技術者がよく使う「V＆V」という言葉は、そのようにして得られたシミュレーションを含む解析結果の検証を行い（Verification）、妥当性を判断し（Validation）、設計に応用して行くことなのです。

　もう一つ「分かって設計する」ためのキーワードを紹介しましょう。

　例えばあなたが見知らぬ海外へ一人で出張する場合、何を準備しますか？空港の場所、交通手段、通貨レート、旅費、地図などいろいろなことを事前に調べ、情報の正誤を判断しませんか？このような下調べをしておけば、実際に現地を訪れてからのトラブルや、後から「しまった！」と言ってしまうようなミスを減らせるでしょう。

　そして、このような「理解する意識を持って行う事前の下調べ」を設計に適用した場合、それをフロントローディング設計と呼ぶのです。

　机上の計算での設計変更は試作コストがほとんどど掛かりません。設計の初期段階ほど、設計自由度は高く、設計変更による影響は軽微です。設計内容に他者の意思が介在するような段階に入る前に、自身でより良い設計に仕上げられれば後々楽になるはずです。

　CAEは開発・設計の初期段階で使ってこそ、効果を発揮するものです^＊2）。

＊2）このような使い方とは逆に、CAEは不具合の再現に使われることも多くあります。しかし、こういったQC（品質管理）的な使い方は時間と手間が掛かる割には実入り（付加価値）は少ないのです。トラブルを未然に防止することこそが、CAEの本来の目的なのです。

　そして、「設計が分かる」ためには、図1に示した設計に必要な技術的な知識の階層構造や「CAE≠シミュレーション」であることを理解し、現象を理解する意識を常に持つことが重要なのです。なおかつ、このような開発環境を育て、定着させるためには、経営者による技術に対する正しい評価が必要不可欠です。分かりやすい目先の成果だけを評価していては、砂上の楼閣はできても、このようなピラミッドは築けないことを経営者は理解し、実践することが求められているのです。

SPICEとは

　　　　　　 1|2|3 次のページへ