構築した制御システムがうまく動かなかったときは、その原因を分析する、デバッグ作業を行う必要があります。
制御結果の分析・デバッグ方法は制御の種類や目的によって様々ですが、このページでは、どんなケースにも共通する基礎的な考え方について解説します。
- システムを分析するときは、入力信号と出力信号の両方を見るのが基本
- システム全体を小さなシステムに分割し、それぞれの入出力を見ていく
- 後から入出力を詳しく確認できるように、信号を計測・保存しておくことも重要
分析の基本は入出力関係
制御におけるシステムとは、「時々刻々何らかの入力信号を受け取り、それに応じた何らかの出力信号を返すもの」でした。
よって「システムの分析」とは、「入力と出力の両方を確認し、両者の関係性を分析すること」であると言えます。
分析・デバッグは面倒ですが、この基本を守って忍耐強くコツコツ進めることが極意と言えるでしょう。「急がば回れ」というわけですね。
※システムと信号の基礎については、こちらのページをご覧ください。
特に重要な入出力関係
とはいえ、通常の制御システムは、複数の小さなシステムの組み合わせで構成されるため、最初はどの入出力関係を見ればよいのか迷うかもしれません。
ここからは、次のシンプルなフィードバック制御システムを例に、分析時に特に重要となる入出力関係について、順番に解説していきます。
制御システム全体の入出力関係
まず基本中の基本となるのが、制御システム全体の入出力関係です。制御用語を使うと、「閉ループシステムの入出力関係」ですね。
平たく言うと「目標値$r$に対して実際の出力$y$がどう追従しているか」という関係です。ほとんどの場合はこれをチェックすると思います。
問題は、「うまく追従していなかったときに次に何を見るか」ですよね。これについて、重要な順に紹介していきましょう。
※「閉ループシステム」など、システムを表す用語については、こちらのページをご覧ください。
制御対象の入出力関係
次に重要なのは、制御対象単体の入出力関係です。
「システムの出力$y$と、それを直接作り出している入力$u$の関係」なので、制御対象の稼働状態をチェックすることができます。
例えば出力$y$の挙動が意図通りでなかったとして、もし入力$u$の挙動も明らかにおかしいのであれば、入力信号を作る制御器に原因があると分かります。
逆に入力$u$がおかしくなさそうであれば、制御対象の構成や設定が間違っている可能性があると分かります。
制御器の入出力関係
次に見ておきたいのは、制御器単体の入出力関係です。
「フィードバックされた信号$e$に対して、制御器がどのような入力$u$を生成したか」なので、自身で組んだ制御器のチェックが可能です。
さらに細かな入出力関係
ここで例に挙げたようなシンプルなシステムであれば、ここまで紹介した入出力関係を見れば、だいたい分析には事足りるかと思います。システム内のすべての信号が網羅されていますからね。
ただし、取り扱うシステムがより複雑な場合、すべての信号を見ることは難しくなります。
このようなシステムの分析も基本は同じで、まずは大きなくくりでシステムを制御器と制御対象に分け、それぞれの入出力関係を見ていけばよいでしょう。
その後必要に応じて、制御器・制御対象をさらに小さな単位に分割し、それぞれの入出力関係を見ていくことになります。
どのように分割してどれから見ていくかは、システムに応じて異なってきますので、自身で怪しい部分を抽出してみてくださいね。ここが制御屋さんの腕の見せ所とも言えます。
入出力を見るために準備が必要
当然、入出力信号を見るためには、システムの動作中に入出力信号を記録しておく必要があります。
そのためには、システム設計の段階で、記録すべき信号・取り付けるべきセンサを検討しておく必要がありますね。
理想的には、全ての信号を記録できればそれがベストです。それが難しい場合は、「どこの動作を分析するために、どの信号が必要か」を考え、優先順位を付けて記録する信号を決定しましょう。
※ちなみに、現代制御の「オブザーバ」という手法を用いれば、直接計測した信号の挙動から、直接計測していない信号の挙動を推定することも可能です。
よくある「悪い入力」とその対策
入出力信号を見てみたけど、それがいいのか悪いのかよく分からないんですけど…
とならないように、ここからは、よくある「悪い信号」の具体例とその対策を紹介していきます。
出力信号については「システムが意図通りに動いているかどうか」を考えれば、良し悪しはすぐに分かると思います。よって以下では、出力が何かおかしいとして、その原因となっている「悪い入力」について、ありがちな例を紹介しておきましょう。
以降、下記制御システムの「制御対象の入出力関係」を例に、説明していきます。
制御対象以外の入出力関係を考える場合でも、考え方は同様です。よって、ここでは「悪い入力」のイメージをしっかりと把握しておいてくださいね。
入力が大きすぎる
まず非常に多いのは、ハードウェアの能力以上の大きな入力を要求してしまっているケースです。
例えば下図では、制御器によってモーターの限界以上のトルクが要求されてしまっています。
当然モーターはそんなにトルクを出せないので、実際のトルクは頭打ちし、結果的に意図しない動作が生じているというわけです。
このような状態は「入力飽和が生じている」とよばれ、基本的には回避すべき悪いことだとされています。システムが制御器の意図通りに動かない状態ですし、ハードウェアの能力の限界付近で動かすと故障のリスクが高まるからです。
入力飽和が生じているかどうかは、指令入力（上で言うトルク指令$u$）だけでなく、システムの中で実際に生み出される入力（上で言うトルク$\tau$）も見ないと検証できないので、両者をしっかりと記録しておきましょう。
入力飽和に対する対策としては、入力が大きくなりすぎないように制御器や制御ゲインを見直すことや、ハードウェアをより能力の高いものへ交換することなどが挙げられます。どちらにせよ、ハードウェアの能力をしっかりと把握しておくことが重要ですね。
入力が小さすぎる
逆に、入力が小さすぎる場合にも注意が必要です。この場合は、システムがほとんど動いてくれなくなります。
例えば、制御器内での単位の計算に間違いがあり、入力信号の大きさが大幅に小さくなってしまうケースなどがこれに当たります。
対策としては、システムを動かすためにはどれくらいの大きさの入力が妥当なのかを把握し、入出力をしっかりと確認することが挙げられます。
入力が速すぎる
入力の大きさだけでなく、速さ（周波数）にも注意が必要です。
例えば、システムが動作可能な速度よりも速い入力を与えても、システムはまともに反応できませんよね。
このような「速い入力成分」はムダになるため、そのような信号を生成している制御器にはムダがある、ということになります。
※制御工学において、信号の速さは周波数という尺度によって表現・分析されます。周波数を用いた解析の詳細については、こちらのページをご覧ください。
例えば、周波数の高いノイズ信号に対して制御器が過敏に反応しすぎている場合などがこれに当たりますね。
これに対する対策としては、システムの動作周波数を把握し、不要な周波数の信号に反応しないような制御器を構築することが挙げられます。
入力が遅すぎる
逆に、システムの動作速度に対して遅すぎる入力を与えても、システムはゆ～っくり動くだけなので望ましくありません。
上記は周波数の観点での「遅い入力」ですが、その他にも、制御開始後しばらく経ってから入力が生じるような「立ち上がりの遅い入力」もよくあります。
上図は極端な例ですが、制御開始後にしばらく小さな入力しか生じていない場合も、このケースを疑ってみましょう。
こういった「遅い入力」が生じた場合は、まずそれが生じているメカニズムを分析する必要があります。例えば、そもそもフィードバックされる誤差信号が遅れているのか、それとも制御器内の計算に遅れが生じているのか、などを確かめることになるでしょう。
その上で、この「遅れ」が必要だから生じているのかどうかを確認し、不要であれば上記メカニズムを元に遅れを解消する、というのが基本的な対策の流れとなります。
上記の複合
ここまで述べてきた「悪い入力」が、複合的に発生する場合もあります。
特に制御システムを構築して初めて動作させる場合は、システムに何らかのバグ・不具合が含まれることが多く、その結果としてこのような入力信号がよく見られます。
以上、 制御結果の分析・デバッグ方法の基礎に関する解説でした。上に挙げたような信号が発生しても、焦らずじっくりと対応していきましょう！
- システムを分析するときは、入力信号と出力信号の両方を見るのが基本
- システム全体を小さなシステムに分割し、それぞれの入出力を見ていく
- 後から入出力を詳しく確認できるように、信号を計測・保存しておくことも重要
コメント