これはなに？
本稿はそもそもアンチワインドアップってなんでいるの？
というのを細かくおっかけてみることを目的とします。
知っている人からすると当たり前のことです。
でも、自分の理解を振り返るためにも細かく、冗長にアンチワインドアップについて書いてみます。
よろしくお願いいたします。
1.時間がたっぷりある人がみるポエム
さて、なんでアンチワインドアップっているんですかね？
そう思った時期が私にもありました。
それはどうやら3年前のようです。
なぜわかるかって？
こんな奇妙なポエムがiphoneのメモに残っていたのを最近見つけたんですが、
作成日が3年前だったからです。 よろしければこちらご覧ください。
ポエム興味ない人は飛ばしても大丈夫ですよ。
俺の仕事はいわゆる管理職ってやつだな！ 朝起きるとお客様から、確保しときたい在庫量に対して現状の在庫量との差、すなわち誤差を教えてくれるんだ！ さて、今日のメールをチェックするかぁ。お客様から誤差についてメールが来てるはずだ。 ん？？ここのところずっと0だった誤差がいきなり10になったぞ。 こいつはうかうかしてられねぇ！まずは部下の“P制御くん"に連絡だ！ 俺「おい、P!久しく仕事がなかったが今日は思いっきりラインぶん回して商品を作ってくれよ！」 この状況はしばらく続くかもしんねえ。Pは瞬発力はあるが、誤差がある時にしか仕事しないから偏差を0にはできねぇ。目標値ぴったりに収束させる繊細かつ継続的な仕事は苦手だ。 「Iさん！今日は誤差がいつもより多いんだ。今後を見越して今の生産量を少しずつ増やしていってくんねぇか？」 よしっ！これで今日の仕事は完璧だな！二人とも頼むぞ！ あれから10日たった。メールに記載されている誤差は毎日10だ！二人の部下は絶好調で生産を継続しているぜ！ ん？お客様から電話だ。メールじゃないとは珍しいな。 お客様「PIさんですか？いつもお世話になっております。実は弊社に御社の商品を送ってくださっている運送業者からここ10日間毎日トラックが事故を起こしてしまって(!?)トラックがうちに来なかったんです。そのお話ご存知でしたか？」 PI「ええっ！？そんな報告は受けていませんが・・・」 お客様「そうなんですか・・・弊社からもその点報告できず申し訳ないです。10日前10個出荷して以来、この10日間在庫の変動は一切なくて。トラックがこないものですからずっと誤差10でメールを出していたのですよ。ですが・・・昨日久しぶりにトラックがきまして商品を受け取れました。いつもより大量のご納品ありがとうございます。ただ・・・今日からしばらく誤差は-30が続きそうです。今はギリギリ倉庫に入りましたがこれ以上は厳しいですね。申し訳ないですがしばらく納品は控えて頂きたいんです。よろしくお願いいたしますね。」 やべーぞ、-30だって！？もう生産数はどんどん増えてる。なんとかしないと！ 「P!すまねぇ。手違いが起こったみたいだ！生産を大至急止めてくれ！」 相変わらず瞬発力は超一級だな・・・ つぎはIさんだな。 あーやっちまった！Iさんは仕事は丁寧だがこういう時融通がきかねぇんだ・・・とにかく減量はお願いできたが明日はどうしよう・・・ 次の日・・・ お客様「PIさん！商品を売りたいという熱意はわかりますがもううちの倉庫はパンパンなんです！これ以上送られると困りますよ！本日は-60ですよ！よろしくお願いしますね！」 あぁなんてことだ。こんな事になるなら運送会社から何かあれば電話で連絡をよこすようお願いしておいたら良かった！ そしたら現状よりも早く生産量が減らせたのに・・ つまりこのような事態が起こったことを検知し、即座にI制御の蓄積をとめる仕組みがすごく長いポエムの続きを読みたい人は展開
1.1 俺はPI制御器だ！宜しくな！
毎日お客様の倉庫に、常に一定量在庫が保たれるように商品を納品する数を決めてるんだ！
商品の生産・出荷の手続きは2人の部下がやってくれてる。頼もしい部下たちだ！
俺はそれをみて毎日何個商品を出荷したらいいか決めてる！
もしかしてうちの商品がバカ売れしてんのか！？
1.2 悲劇の始まり
P「っしゃあー！もう急ピッチで生産始めてんぜ！」
はええなこいつ・・・
ここはそういうのが得意なもう一人の部下の"I制御さん"にも連絡しとくか。いつも誤差を0(定常偏差をなくす)で生産できてるのはIさんのおかげなんだ。
I「誤差は10ですね。わかりました。ではこの誤差が続く限り1日あたり2個ずつ出荷数を増やしていきましょう。」
1.3 迫りくる恐怖
Iさんなんか最初のあの日から10×2=20個も毎日の出荷量を増やしてる！こいつはすげーぜ！
これでも誤差が0にならないなんてよほど商品が売れてるんだな！
1.4 避けることができない現実
まずはPからか。
P「もう生産ライン撤収しましたよ。」
「Iさん！申し訳ないないが生産を大至急止めてくれねぇか」
I「それは無理です。生産数は1日あたり数個ずつしか変動できませんので、1週間以上稼働は止まりませんよ」
1.5 残酷
1.6 かくかくしかじかで
事故があったあの日、もし連絡をくれたならIさんに増産のお願いをしなかったのに！
アンチワインドアップなのです！
2 まじめな説明
これがiPhoneのメモ帳にのこってるとか・・・怖いわぁ。恐怖でしかないわぁ・・・・
さて、
アンチワインドアップが必要な状況はどのようなときでしょうか。
ポエムに書いているように何らかのトラブルで操作量（出荷量）を制御対象（倉庫の在庫量）に反映できない状態が続くことは現実にはありえるのでしょうか。
ポエムの事例は大袈裟ですが、
現実には例えば制御補償器が出力する操作量に上限・下限を設けている時にそのようなことがおこりえます。
例えばパルス幅で出力の平均電圧を操作するPWM制御では一定周波数で出力されるパルスのDutyを操作します。
ただこのパルスは理想状態においても0%～100%の振れ幅しかなく、120%のパルスを出力することはできません。
120%というのはすなわちパルスの周波数を操作することに等しいためです。
しかし、
普通のPI制御は操作量に上限下限があることは意識していません。
ですから、大きな偏差が来たときに出力値を例えば100%以上にすることはありえるのです。
実際にわざとこのようなことを引き起こすように作ったSimulinkモデルを見てみましょう。
2.1 アンチワインドアップがない時
-図１.出力に制限がある/ないのSimulinkFB制御モデル-
では普通にやってみましょう。上がLimitがあるPI したがLimitがないPIです。
こいつらに指令値として1秒後に0→0.5に変動するステップ信号を与えてみましょう。
制御パラメータは適当にこんなかんじにしました。
-図2.Simulationモデルパラメータ一覧-
さて、Plantの出力を見てみましょう。
Limitがかかっているほうはオーバーシュートが大きく、収束が遅くなっているのがわかります。良くないですね
-図3.Plantモデルの出力比較-
ではPIの出力はどうなってるでしょうか。
-図4.PIモデルの出力比較-
Limitはかかってないほうは操作量として５というでっかい値をぶち込めているので収束が早いようです。
また、I制御の積分に値が蓄積されていない分PIの出力が収束するのも早いですね。ちょうど5秒ぐらいで出力の変動がなくなります。
一方でリミットがあるほうは１より大きい値が出せずサチっています。
ここで注目したいのは図３で目標値である0.5をPlantの出力が超えているにもかかわらずPIの出力が下がっていない点です。
0.5を超えると偏差がマイナスになるのでPIの出力が下がってもいいと思うのですが・・・
2.2 なんでこうなんの？
まぁ皆さんお気づきだとおもいますがこれはI制御がたっぷり値をため込んでいるせいで急に値をもどせなくなっているためです。
Limitによって出力が制限されているとその分偏差が縮まらないので、I制御にはそのぶんたっぷり値が蓄積されます。
この大量にたまった値を抜くのに時間がかかるから
Limitが解除された後、収束までにとっても時間がかかってしまうのです。
これはSatulationブロックの前後の値を見てみるとよくわかります。
-図5.Satulationブロックの前後の値-
じゃあなるべく収束を早めるにはどうしたらいいか？
それは
Limitがかかったらそれ以上積分に蓄積をさせないようにすればいいのです。
これがアンチワインドアップと呼ばれる手法の一つです。
2.3 固定アンチワインドアップがある時
一般的にアンチワインドアップというとこの”積分を停止・固定する”アンチワインドアップを言うようです。
とりあえずLimitがかかったことを検知して積分の蓄積を止めるわけですから
Simulinkで書くとこういうことになりそうですね。
-図6．アンチワインドアップ（AWU）あり/なしのSimulinkFB制御モデル-
出力を見ると、なるほどオーバーシュートが低減されているじゃないですか。
-図7.Plantモデルの出力 AWUありなし比較-
PIの出力を見るとLimitがかかってるものの、従来よりも早くゲインを下げているのがわかります。
-図8.PIモデルの出力 AWUありなし比較-
さっきと同じようにアンチワインドアップを実装したほうのLimitの前後を見ると
Limitの前の値、すなわち純粋なPIの出力が図5より早く収束しているのがわかります。
これはLimitがかかったことを検知してI制御の蓄積を止めているためです。
-図9.AWUありPIのSatulationブロックの前後の値-
3.まとめ
- Limitがかかった制御系だとI制御に無駄に値がたまってしまうことで応答が遅くなることがある
- これを抑制するのがアンチワインドアップ
- 手法の一つにLimitがかかった時点でI制御の蓄積をやめる手法がある
- Simulinkで実装してみてその効果を確認した。
- 意味不明のポエムも書いておけば後々役に立つことがある。
ポエム かいてみるもんだなぁ。
以上 ありがとうございました！！
おまけ ほかの手法ってあるの？
世の中にはすごい人がいるもんですごいしっかりまとめてくださっている記事がありました。
こちらの記事をみていただけるとご満足いただけるかと。
僕のおすすめは自動整合ですね。
https://hamachannel.hatenablog.com/entry/2019/01/06/135004