|
２２ ポンプ制御システム（水位計を含む）
ポンプ制御用のシステムバックアップ
ポンプの制御については、故障時の想定が重要です。水位計が故障した場合を含め各制御機器が故障した場合の制御、バックアップを考慮しておきます。
１ 水位計のシステム構成
（１）水位計は同等の２台を設置します。
（２）ポンプ制御用の水位計は保守、故障等により切り替え可能とします。
切り替えと簡単に書きましたが、単純にスイッチ又はリレーでアナログ信号を切り替えるのはいいのですが、
切り替えの瞬間、アナログ信号が途切れることになります。
警報設定器のＬＬやＬが誤動作し、現在運転中のポンプが停止します。
この回路は、シンプルでいいのですが、切り替え時に停止させないためには、アナログ信号切替器が
必要です。（各計装品は、入力信号処理の仕様確認が必要）
切り替えは、緊急時と割り切れば、スイッチでもいいかもしれない。
（３）水位計の計測値がＣＴＲの伝送によらない直送監視ループは以下を想定します。
①機側盤 機側運転時に使用
②ポンプ制御室 伝送不具合時や保守点検時の監視ができない時に使用
③監視室 伝送路異常時対応とともに、ポンプ井水位を全員で共有
（４）警報設定器の系統数
警報設定器は制御に使用される水位計の系統数（常用・予備の場合）に併せて１系統ずつで良いように
思います。
しかし、１系統でＬＬの警報器が故障したすると全台のポンプが動かないことになります。
（言い換えると１台数万円の警報設定器に浸水するかしないかが委ねられている）
設備の規模によりますが通常であれば２系統以上が望ましと考えます。
検討項目
①ポンプの号機数
②分流、合流、雨水等など水位計の系統数
③ＭＣＴＲ、ＣＴＲ、ＳＱＣの構成との整合性
（５）警報設定器はポンプ連動制御用のＳＱＣが故障時でも、部分運転できるポンプ群を分けておきます。
ＳＱＣ故障のポンプ群は、機側運転のみ対応となります。
機側運転時にＬＬ（最低水位）のインターロックを「組み込むか」、「組み込まないか」の議論はどちらで
痛い目に遭っているかによると思われます。
妥協案としては、ポンプ操作の機側盤内に「ＬＬ」保護あり、なしの切り替えスイッチを取り付けておくのも
一案です。
（常用運転時は、どちらにスイッチが入っていてもインターロックあり、とします。）
２ ポンプの制御システム構成
（１）ポンプの制御システムの構成以下のようなものがあります。
水位計システムもそうですが、設備の故障時にどこまでバックアップをするかで大幅にコストが変わってきます。
強いて言えば被害をどこまで許容するのかにかかわる重要な要件と考えています。
|
用語説明（中央監視制御設備の構成）参照
| 制御機器 |
機能・特徴 |
備 考 |
コントローラ
（ＣＴＲ）
|
ＣＴＲはコントローラ、主にアナログ制御を主に行う。ＰＩＤ制御を行い、
アナログ入出力、パルスの取り込み等を実施します。
ソフトなのでシステム完成まで随時修正可能。
対象機器全ての制御不可。
|
制御周期は１ｓｅｃ前後となります。
定期的な点検が必要。
|
シーケンサ
（ＳＱＣ）
|
ＳＱＣはシーケンスコントローラ、シーケインス制御を主に行います。
ＯＮ・ＯＦＦ信号の入出力を扱います。
ソフトなのでシステム完成まで随時修正可能。
対象機器全ての制御不可。
|
制御周期は２００ｍｓ以下の高速となります。
定期的な点検が必要。
|
マルチ
コントローラ
（ＭＣＴＲ）
|
ＣＴＲとＳＱＣの両方の機能を持ち合わせていますアナログ制御とシーケンス制御を行います。
ソフトなのでシステム完成まで随時修正可能。
対象機器全ての制御不可。
|
制御周期は内部のプログラム分割により、機能（ＣＴＲ要素・ＳＱＣ要素）に合わせてスピードを変更できます。
定期的な点検が必要。
|
ハードシーケンス
|
接点絶縁や簡単な連動シーケンス作製用。故障が少なく影響範囲が狭い。
複雑な回路は作成できない。
一度できあがると変更は難しい。早期に仕様確定が必要。
（シーケンス比較）
|
故障要因がすくない。長期にメンテを必要としない。
|
|
①ＭＣＴＲシングル構成
ＭＣＴＲ故障するとポンプの運転が全台監視・制御ができない。
機側運転がバックアップ運転レベルとなる。
なお、ハードシーケンスと警報設定器で限定された自動運転シーケンスの製作は可能。
②ＭＣＴＲのＣＰＵ２重化構成
ＭＣＴＲのＣＰＵが故障してももう１台のＣＰＵがバックアップするためポンプは通常制御運転が可能。
ＰＩＯなど共通部分が故障した場合は全台監視ができない。
機側運転がバックアップ運転レベルとなる。
なお、ハードシーケンスと警報設定器で限定された自動運転シーケンスの製作は可能。
ただ、故障時のＣＰＵ切り替えは、なかなかうまくいかない？
③ＭＣＴＲのＣＰＵ・ＰＩＯ２重化構成
ＭＣＴＲが故障してももう１台のＭＣＴＲがバックアップするためポンプは通常制御運転が可能。
ＭＣＴＲが機能しない場合は、機側運転によるバックアップ運転レベルとなる。
昔から存在する構成に以下のものがあります。
ＣＴＲ、ＳＱＣを組み合わせたシングル構成
ＣＴＲが故障すると、ＳＱＣを行うバックアップの自動運転が可能です。
（中央監視制御設備の構成）
ただし、ＣＴＲとＳＱＣの伝送装置に対する位置関係で、例では監視室からの監視ができません。
過去に、ＳＱＣとＣＴＲが伝送装置に対して、並列にしているメーカーがありました。この場合は、ＣＴＲが
故障しても、ＳＱＣの監視制御可能です。
ＣＴＲが故障すると流量制御がでないためバックアップ操作器による固定流量の運転となります。
なお、ＣＴＲ故障時に、最大流量に設定し直すことは可能。
ＣＴＲ、ＳＱＣを組み合わ分散構成
シングルで全て組むと、大規模ポンプ場の場合故障の影響が大きいのでＣＴＲ分散、ＳＱＣ分散を行っています。
ＣＴＲが故障すると、ＳＱＣがバックアップの自動運転が可能です。ＣＴＲによる流量制御がでないためバックアップ操作器
による固定流量の運転となります（現状維持）。なお、ＣＴＲ故障時に、最大流量に設定し直す考えもあります。
ＣＴＲ＋ＳＱＣの分散化がシステムとして信頼性があると思うのですが、
現在はコスト面と能力からＭＣＴＲ（ＣＰＵ２重化）に移行されつつあります。
上の図のようにＭＣＴＲからＳＱＣ制御機能をハード分離し、ポンプ数台を分散制御した事例もあります。
個人的な感想としては、小型シーケンサでポンプ１台ずつ制御するかハードシーケンスにある程度明け渡す考えもあります。
ハード思考（半導体不信）なのでできるかぎり、ハードシーケンスに移したい気もします。
現状の限界
ＭＣＴＲでＰＩＯの２重化までいかないのはコスト面からの要請です。
（中央監視制御設備の構成）
（１）ポンプはコントローラ（ＣＴＲ、ＭＣＴＲを含む）が故障時の仕組み
このシステムはＭＣＴＲのＣＰＵの故障時には現在の制御上の構成に関係なく現状制御を維持できます。
ＰＩＯを含む故障の場合は、２重化されていないので正常に運転できません。
その際、ポンプの運転をどのようにするかでシステムの考え方が分かれます。
①ＭＣＴＲ故障時は、ＳＱＣ故障時とも機側運転ができれば良いと割り切る。
②ＳＱＣと警報設置器により、固定速運転のＯＮ・ＯＦＦ制御を目指す。
（ＯＮ・ＯＦＦ制御）
ＭＣＴＲ故障時の問題点
ＭＣＴＲの下位にＳＱＣが入っている場合、ポンプの運転順位の変更や受電・自家発との電力制御ができなく
なります。
①ポンプの同時起動防止
警報設定器の水位設定値は、ポンプ毎に順位を決めておきます。
②受電・自家発の電力制御
ＭＣＴＲ故障時は、電力制御を行えません。受電・自家発ＭＣＴＲが正常であれば、デマンド制御により
自家発が自動起動し給電します。
|
補足
高圧受電など受電環境が貧弱な場合に、大容量のポンプは受電側で運転できません。
このため、ポンプは自家発対象となっています。
受電・自家発ＭＣＴＲに起動要求がこないので自家発を運転させるためには「手動」で運転し給電
します。
自家発が１台運転中でポンプの追加運転するために自家発の追加起動が必要なポンプについても、
通常追加信号が来ないので１台目が過負荷になり停止してしまうことが考えられます。
当初からＳＱＣと受電・自家発ＭＣＴＲで起動・停止の制御ができるシーケンス組んでおくなど対策
がいるかもしれません。（ＭＣＴＲとの制御区分の調整が必要）
なお、上記のシステム構成図からＳＱＣはＭＣＴＲの下位に位置します。
このため、監視室からポンプの「自動」・「手動」、「運転」・「停止」の操作ができません。
操作ができるのは、制御室か機側盤になります。
まだ、検討が足りない？
ＭＣＴＲ故障時の扱いについては、考慮すべき点が多々あるため機上特性により個別の検証が必要です。
制御のイメージ
|
どこまでのバックアップを考慮するかで無限ループ
ＣＴＲの故障時ではポンプはＳＱＣの運転に移行すると考え、例題では運転範囲が警報設定器の設定範囲に変更になり４台の自動運転可能とします。
ポンプの流量制御（ＣＴＲで制御）はバックアップ操作器により現状維持かＭＡＸによるかは、機上の制御仕様となります。
ただ、ここでも上記に書いたように制御システムの検討は簡単ではありません。コストもかかります。
さて次に、ＳＱＣが故障したときに、どのようにするのか？
通常、ＳＱＣで警報設定器のＬＬ信号を取り込んでいるため、ＳＱＣ故障時ＬＬ信号が落ちることにより、
ポンプは停止します。
（水位システムの例では２台）
ＳＱＣが故障しても止めないで運転継続させることは大雨時に排水優先となってベターに思えます。
しかし、ＬＬレベルではポンプを停止させることが必要になります。
その際、強制的停止するのか。人が止めにいくのか。ここでシーケンスに工夫がいります。難問です。
ＳＱＣをやめてハードシーケンスによるとの考えもあるかもしれません。
ただ、この考えだけでは問題があります。
ハードシーケンスのみで、ポンプ単独起動だけを考え、４台の協調がないとすると電力の心配が生じます。
容量の大きいポンプの電力協調が取れず、同時起動するかもしれません。
（受電・自家発ＣＴＲのやりとりをＳＱＣではなくやはりＣＴＲに戻すのか）
バックアップをなぜこのように追い続けるのか。
下水処理場は大雨、台風など災害時に必ず運転できるように求められるからです。
そして、マーフィーの法則にあるように、「壊れる可能性のあるものは必ず壊れる」ことにあります。
制御システム機器の開発が日進月歩の状態で止まっていないので、残念ながら未だに結論が出ていません。
ただ、バックアップができたとしてもシステムが複雑になり、故障要因が増えると何をしているかわからなくなります。
「バックアップ」と「Ｓｉｍｐｌｅ ｉｓ ｂｅｓｔ」は両立すのか。
「下手な考え休むににたり」か。
|
（４）吐出井水位計
吐出井の水位計の計装回路の考え方に注意が必要です。
（１）図の例では、水処理系統に飲み込めない合流雨水がオーバーフローして直接放流されると考えています。
このため、通常運用で、吐出井のＨＨは警報というより、雨水が放流された確認となり、帳票で雨水放出量の演算に
使用したりします。
（２）雨水排水ポンプ場では、吐出井のＨＨは吐出井からあふれるかもしれなことを意味します。
このために、このＨＨにはポンプの停止を含むインターロックをつけたくなります。
注意してください。吐出井のＨＨは大雨で発生しています。
①河川の水位が集中豪雨で想定以上に高かい。
②集中豪雨で大量の雨水が流入しており、ポンプ井の水位が高い状態で釣り合っており、ポンプ全台最大流量以上の流量を排水している。
この際に、インターロックでポンプを停止させるとどうなるか。想像に難くありません。
警報設定器の誤動作も想定し、吐出井のＨＨは「警報のみ」にとどめておくべきと考えます。
ただ、やむを得ない事情で組み込みたい場合は、ポンプ停止のインターロックは、影響を考慮し全台ではなく限定号機にとどめるなど工夫が必要です。
また、時間を経ても薄れない「管理者への周知」が必要です。
やっぱり難しいので、警報だけにしたい。
|