電力変換アプリケーション向けの制御アルゴリズム、その迅速なプロトタイピングと実装

概要

モデル駆動開発(MDD:Model Driven Development)は、プロトタイピングの高速化や市場投入までの時間の短縮を目的としたソリューションです。現在、普及が進んでいる状況にありますが、実は、モデルの性能と製品の性能の整合性をとるために、実装の最終段階において、かなりの時間と労力を注ぐ必要があります。このことが原因となって、実際には、MDDの可能性を最大限に引き出せる状態にはなっていません。本稿では、これまでに確立されてきた指針や手法に従ってMDDを進めることにより、この問題を解決可能であることを示します。また、モデルから効率良くコードを生成することによって、製品を市場に投入するまでの時間を短縮する方法についても説明します。

はじめに

電力網に接続されたソーラー・インバータなど、分散型のエネルギー源の普及が進んでいます。それに伴い、電力変換の業界では、そうした市場に対する効率的で費用対効果の高い、より優れたソリューションが求められるようになりました。実際、電力変換のプロセスにおいて、出力の品質と効率を改善するためのアルゴリズムやトポロジについて記した数多くの文献が発表されています。また、ICベンダーは、そのようなアルゴリズムを効率的に実装するための機能や、ハードウェアによるサポートを提供可能な制御プロセッサを新たに開発しています。インバータ全体のプロトタイプをハードウェアとして構築し、様々な条件下で実験によって性能を確認するには、かなりのコストがかかります。加えて、アルゴリズムの不具合が原因となって、実験中にシステム全体が破損してしまうおそれもあります。更に、こうした市場向けの製品は、安全基準を満たすように設計/実装されていなければなりません。このような理由から、従来の電力変換業界は、最終製品へのイノベーションの適用に多大な時間を要すという状態にありました。

このような問題の解決策として導入されたのがMDDです。MDDでは、プロトタイプをハードウェアとして構築する前に、システム全体のモデルを構築してシミュレーションを実施します。それにより、アルゴリズムの機能を検証し、リスクを大幅に軽減します。また、モデリング・ツールを使用すれば、安全認証の基準への適応作業を簡素化/緩和するモデルから、直接コードを生成することができます。しかし、MDDは、業界からの完全な支持を得ているわけではありません。その理由は、主に以下の2つです。

  • 最終製品とモデルの性能が大きく異なる
  • 生成されるコードが、ターゲットとなる制御プロセッサに対してあまり効率的ではなく、製品化の前の段階で手作業で修正を施す必要がある

本稿では、モデルの性能を最終製品の性能に近づけて、ハードウェアの変更や開発の遅延のリスクを最小限に抑えるためのテクニックとアプローチを紹介します。また、製品を早く市場に投入できるように、モデルからコードを効率良く生成する方法についても説明します。

モデル開発のガイドライン

MDDの概要

図1は、電力網に接続された家庭用ソーラー・インバータを簡略化して示したものです。ソーラー・パネル(PVパネル)では、太陽光の放射強度に比例するDC電力が生成されます。コンバータは、このDC電力を、家電機器で使用したり、電力網に供給したりすることが可能なAC電力に変換します。その際には、シグナル・チェーン上の様々な個所で、センサーによって電流と電圧の信号が取得されます。それらの信号は、インバータの制御プロセッサに送られます。制御プロセッサでは、アルゴリズムを実行することにより、それらの信号に対する解析を行います。そして、生成された電流と電圧の周波数、振幅、位相が電力網の要件に合致するように、パワー・モジュールが制御されます。この例では、ソーラー・パネルはソース(電源)、電力網と家電機器はシンクとして動作します。電力変換システムによってソースとシンクは異なりますが、そのほとんどが図2に示す構造に当てはまります。

図1. ソーラー・インバータの簡略図

図1. ソーラー・インバータの簡略図

図2. 電力変換システムのブロック図

図2. 電力変換システムのブロック図

電力変換システムやアルゴリズムの設計者は、次のようなことを目的として開発作業を行います。それは、制御プロセッサとコンバータのハードウェア(図2)に向けて適切なコンポーネントとアルゴリズムを用意し、ソースと負荷のあらゆる変化に対して、所望の性能を達成できるようにすることです。そのためには、システムの動作環境について明確に把握した上で設計を行うことが重要になります。例えば、システム用のソーラー・インバータ(図1)を設計する際には、インバータの設置場所、太陽光の放射強度の変化、ソーラー・パネルの効率、電力網の状態などを把握する必要があります。MDDでは、最初にコンバータのモデルを作成し、予測される変化に対応したシミュレーションを実施します。それにより、モデルが期待どおりに動作するか否かを検証します。ほとんどのモデリング・ツールには、ソースとシンクをモデル化するためのモデルやライブラリ(機能ブロック群)が用意されています。例えば、TheMathworksの「Simscape Power Systems」には、電力網、ソーラー・パネル、様々な負荷のモデルが用意されています。これらを使用すれば、システムの様々なユース・ケースについて、シミュレーションを実施して検証を行うことができます。

システムの性能は、システムのすべてのコンポーネントに依存します。設計者がシステムのすべてのコンポーネントをゼロから設計し、ソースと負荷の制約を満たせばよいというケースもあり得ます。しかし、実際には、設計者による管理の範囲を超える理由で、システムの一部が既に固定されていることがほとんどでしょう。その場合、自由に設計できるコンポーネントは、ごくわずかに限られるかもしれません。本稿では、設計者の主要な目的は、既存のトポロジに対する適切な制御アルゴリズムを選択して実装することだという仮定に基づいて話を進めます。ただ、以下で説明するガイドラインのほとんどは、そのような仮定に当てはまらないケースにも適用できます。

モデルの構築

モデルの構築に当たっては、適切なインターフェースを用意すると共に、モジュール形式を採用することが重要です。モデルを適切に構築すれば、様々なユース・ケースに応じて素早くモデルの解析を行い、適応させることができます。通常、モデリング・ツールには、コンポーネントを適切なレベルで抽象化したり再利用したりすることができるようにグループ化するための様々なオプションが用意されています。例えば、「Simulink」では、サブシステム、ライブラリ・モデル、リファレンス・モデルを作成できるようになっています。図3に示したのは、図2の電力変換システムを基にSimulinkで作成したモデルのトップレベル・ビューの例です。この図において、パワー・コンバータと制御プロセッサは、ADIInverterというラベルを付加したサブシステムでカプセル化されています。また、Simscape Power Systemsに用意されているソーラー・パネルと電力網のモデルを使用して、ソースのモデル化を実施します。その際には、強度と温度の構成について規定します。サブシステムであるADIInverterは、更に階層的に分割し、制御プロセッサと制御アルゴリズムのブロックに分けることができます。

図3. Simulinkのモデルの例

図3. Simulinkのモデルの例

制御プロセッサ上で実行する制御アルゴリズム以外のブロックは、いずれもハードウェアのブロックです。したがって、それらのコンポーネントに課せられるすべての制約を、シミュレーションにどれだけ正確に反映できるかということが、最も重要な条件になります。

各ブロックのインターフェースでやり取りされるのはアナログ信号です。それらに対しては、連続モデルを選択するのが適切です。一方、制御アルゴリズムは、マイクロコントローラ上で実行されるものなので、離散的な状態と固定のステップを使用しなければなりません。異なる構成とソルバーの設定に対応するモデルを別に用意し、そのモデルをトップレベルのモデルから参照することを推奨します。後述しますが、これは、アルゴリズムのコードの生成とPIL(Processor in Loop)テストにおいても役に立ちます。

ソルバーのステップ・サイズとデータ・タイプ

シミュレーションの速度と精度は、主にソルバーの種類とステップ・サイズによって決まります。ステップ・サイズが小さければ、より正確な結果が得られます。但し、シミュレーションの実行速度は遅くなります。ここでの目的は、ハードウェア・コンポーネントのシミュレーションを最大限の精度で実施することです。可変ステップ・サイズの連続ソルバーであれば、ほとんどのケースに対応できるはずです。しかし、スイッチング周波数が高い場合、最大ステップ・サイズを手作業で調整しなければならない可能性があります。例えば、スイッチング周波数が100kHzの場合、ステップ・サイズが大きすぎると、生成されるPWM波に歪みが生じる可能性があります(図4)。高速にスイッチングするデバイスについては、必ず出力をチェックし、ステップ・サイズが適切であることを確認するべきです。制御アルゴリズムは、マイクロコントローラ上で実行されるので、ステップ・サイズが固定の離散モデルを使用する必要があります。使用するステップ・サイズは、システムに適用されるサンプリング周期の最大公約数に設定しなければなりません。ほとんどの場合、モデリング用ソフトウェアによって、その値が自動的に選択されます。

(a)ステップ・サイズが適切である場合の出力

(a)ステップ・サイズが適切である場合の出力

(b)ステップ・サイズが大きすぎる場合の出力

(b)ステップ・サイズが大きすぎる場合の出力

図4. PWM出力のシミュレーション結果。スイッチング周波数が100kHzの場合の例です。

使用するデータ・タイプも、シミュレーションの精度を左右します。倍精度の演算によるシミュレーションは、単精度の演算によるシミュレーションよりも、必ず精度が高まります。ハードウェア・ブロックのシミュレーションを行う場合、モデリング用のソフトウェアでサポートされる最大精度のデータ・タイプを使用することを推奨します。一方、制御アルゴリズムについては、アルゴリズムの性能を制御プロセッサ上で実行する場合と同等に設定します。現実よりも高い精度に設定すべきではなく、制御プロセッサでサポートされるデータ・タイプを使用しなければなりません。例えば、制御プロセッサとしてアナログ・デバイセズの「ADSP-CM41x」を使用する場合、適切なデータ・タイプは、単精度浮動小数点数になります。ADSPCM41xは、FPU(浮動小数点演算ユニット)を備えるARMプロセッサ「Cortex®-M4」を採用しているからです。一方、制御プロセッサとして「Cortex-M3」などの固定小数点プロセッサを使用する場合には、データ・タイプを固定小数点数としてアルゴリズムを設計/実装する必要があります。モデリング用ソフトウェアが浮動小数点から固定小数点へのデータ・タイプの自動変換をサポートしている場合もあります。その場合、開発作業の高速化が図れます。

サンプリング・レートと精度

先述したように、電力変換システムのシグナル・チェーンでは、様々な個所の電流と電圧の信号がセンサーによって取得されます。取得した信号は、制御プロセッサのA/Dコンバータ(ADC)でデジタル・データに変換されてアルゴリズムに引き渡されます。ADCのサンプリング・レートは、主にパワー・モジュールのスイッチング周波数の値がいくつであるかということと、パワー・モジュールをどれだけ高速に制御しなければならないかということによって決まります。サンプリング周波数は、制御アルゴリズムの性能と動作に多大な影響を及ぼします。したがって、システムに対する適切なサンプリング・レートを選択して、シミュレーションを実行する必要があります。また、制御プロセッサのADCは、事前に定められた範囲の入力信号しか受け付けられません。最大限の性能を得るには、検知した信号の範囲がADCの入力範囲内に確実に収まるように、センサーの出力を正規化する必要があります。

ADCの分解能と精度は、それを内蔵するプロセッサ製品によってまちまちです。ADCの分解能と精度も、アルゴリズムの性能に多大な影響を及ぼします。ADCの精度が高ければ、出力を制御しやすくなり、アルゴリズムは簡素化され、指定された制御の条件を満たすための制御周波数を低く抑えることができます。正確なシミュレーション結果を得るには、これらの特性をモデルに反映させる必要があります。例えば、ADSP-CM41xは、分解能が16ビットのADCを内蔵しています。その有効ビット数(ENOB:Effective Number of Bits)は13ビット以上です。ADCのモデルは、所望のサンプリング周波数と精度で連続信号を入力として受け取り、離散信号を出力するように作成する必要があります。また、電流をサンプリングする場合には、サンプリング点が重要な意味を持つことがあります。その場合、ADCのモデルでサンプリング点を選択できるようになっていれば、シミュレーションの精度をより高めることができます。

コードの生成

モデルを開発し、ユース・ケースのシミュレーションを実行してアルゴリズムの性能を検証すれば、リスクが大幅に軽減されると共に、製品を市場に投入するまでの時間が短縮されます。それだけでも効果があるわけですが、モデリング・ツールの機能を活用すれば、更なるメリットを享受できます。ハードウェアのプロトタイプを構築する前に、従来よりもはるかに多くの作業を行えるからです。ICベンダーは、自社のプロセッサ製品上で実行するアルゴリズムを開発するための評価用プラットフォームを提供しています。評価用のハードウェア上でアルゴリズムを実行して検証を実施できれば、その性能についてより大きな確信を得ることができます。但し、組み込みプロセッサ用のコンパイラは通常、C/C++のコードにしか対応していません。一般に、そのC/C++のコードをモデル化と検証の段階で手作業で開発しようとすると、それらが完成するまで非常に長い時間待たなければ先に進めなくなります。そのため、評価用のハードウェアを用いた検証の作業は、後回しにされることが少なくありませんでした。幸い、現在のほとんどのモデリング用ソフトウェアは、モデルからコードを自動生成する機能を備えるようになりました。制御アルゴリズムのモデルは、定義済みのAPI(Application Programming Interface)を使用して、コードを生成するように設定することができます。シミュレーション・ツールには、モデリング環境から生成したコードを直接ターゲット上で実行するためのPILオプションも用意されています。PILシミュレーションでは、制御アルゴリズムの入出力が、UARTなどのインターフェースを介して評価用ボードとの間で送受されます。このオプションを使用すれば、ターゲット上でシミュレーションを実行した場合と、ホスト・マシン上でシミュレーションを実行した場合のアルゴリズムの性能を容易に比較することができます。

一般に、モデリング/シミュレーション用のソフトウェアは、広範な種類のプロセッサをターゲットとし、C言語のコードの生成をサポートします。ICベンダーは、プロセッサ上で動作するアプリケーションの高速化を図るために、差別化要因を備えた機能を用意します。例えば、ADSP-CM41xの場合、正弦/余弦/平方根などの算術演算を高速化するための演算ユニット・アクセラレータを搭載しています。そうした機能を活用し、プロセッサの性能を最大限に引き出すことが重要です。モデリング・ツールでは、コードの一部をカスタムのコードに置き換えたり、アルゴリズムのブロック全体を別のコードで置き換えたりすることが可能です。電力変換のアルゴリズムについては、DQZ(Direct Quadrature Zero)変換やフェーズ・ロック・ループ(PLL)などの一般的なアルゴリズム・ブロックに対し、マニュアルで記述した最適化用のルーチンを適用することで、より高い性能が得られるコードを生成することができます。コードを生成する際、デフォルトの汎用ルーチンの代わりに、マニュアルで記述したルーチンを使用するように設定できるようになっています。ICベンダーは、自社のプロセッサ上でアルゴリズムを高速で実行できるようにするために、モデル・ライブラリを提供しています。このようなオプションを活用することにより、制御プロセッサ用に最適化されたコードを生成することが可能になります。

制御プロセッサ向けには、制御アルゴリズムのコードだけを用意すればよいわけではありません。それ以外にも、ADCやPWMなどのペリフェラルを構成するためのコードや、システムのタイミングや各種機能を維持するためのフレームワークのコードも必要になります。モデリング・ツールは、そのようなコードの生成にも利用できます。但し、フレームワークのコードは、制御アルゴリズムのコードよりもはるかに膨大な規模になります。関連するすべてのタスクに対してモデルを作成し、それらのモデルからコードを生成していたのでは、却って作業効率が低下してしまう可能性があります。そのような場合、フレームワークのコードとペリフェラルの構成用のコードは別途開発し、自動生成された制御アルゴリズムのコードと統合する方が適切かもしれません。

HILシミュレーション

通常、パワー・モジュールのシミュレーションやシステムのシミュレーションは、ホストPC上で実行します。PILシミュレーションであっても、ターゲットとなる制御プロセッサ上で実行されるのは、制御アルゴリズムだけです。それ以外の部分のシミュレーションは、すべてホスト・マシン上のモデリング・ソフトウェアによって実行されます。このPC上のシミュレーションには、かなりのリソースと実行時間を要します。ソフトウェアでリアルタイムに実行するのは不可能です。言い換えると、この種のシミュレーションで、システムの動作やADC/PWMの性能まで検証することはできません。このような欠点を解消するのがHIL(Hardware-in-the-Loop)シミュレーションです。HILでは、コンバータのコンポーネント、ソース、シンクのシミュレーションを、高速のハードウェアであるFPGA(フィールド・プログラマブル・ゲート・アレイ)を使用して実行します。これであれば、シミュレーション全体をリアルタイムに実行し、ADCによるサンプリングとPWM制御の性能を確認することができます。通常、HILシミュレーション用のハードウェアは、制御プロセッサに対するインターフェースを含めて、別のベンダーから提供されます。なお、HILシミュレーション用のプラットフォームでは、パワー・モジュールの細かいスイッチング特性までシミュレーションできるわけではありません。この点には注意が必要です。最終製品へと開発を進める際には、スイッチング特性の影響などを個々に確認して、リスクの低減を図る必要があります。

まとめ

最新のモデリング・ツールは、大きな進化を遂げています。本稿では、モデルの出力を最終製品の出力に近づけるための様々なアプローチについて説明しました。但し、EMC(電磁両立性)などの特性については、この種のシミュレーション環境では検証できません。どのような特性がそれに該当するのか特定し、代替手法によって解析/検証を実施する必要があります。

HILシミュレーションを除くと、本稿で説明したステップは、3レベルのANPC(アクティブ中性点クランプ)トポロジを採用したインバータ向けのプロセッサとして、ADSP-CM41xを採用したケースを想定しています。実際、同プロセッサをターゲットとする制御アルゴリズムの設計と開発に、本稿で説明した内容を適用し、成果を得ることができています。

謝辞

本稿の執筆に協力してくれたアナログ・デバイセズ オートメーション・エネルギー(AEG)事業部門の同僚たちに感謝します。

Bijesh-Poyil

Bijesh Poyil

Bijesh Poyilは、アナログ・デバイセズのエンジニアリング・マネージャとして、インドのバンガロールで勤務しています。現在は、オートメーション・エネルギー(AEG)事業部門の産業用システム・グループ(ISG)に所属しています。専門分野は、組み込みシステムを対象とした電力変換、コンピュータ・ビジョン、機械学習のアルゴリズムです。インドのNITカリカットで電子/通信工学の学士号を取得しています。

Martin Murnane

Martin Murnane

Martin Murnane。アイルランド、リムリックにあるアナログ・デバイセズのエネルギー貯蔵および変換チームのシステム・アーキテクト。以前は、アナログ・デバイセズのオートモーティブ・チームに在籍。アナログ・デバイス入社前は、エネルギー・リサイクル・システムのアプリケーション開発、Windowsベースのアプリケーション・ソフトウェア/データベースの開発、ひずみゲージ技術を使用した製品開発(BMS)など、いくつかの業務に従事。リムリック大学にて電子工学の学位とM. B. A. を取得。