はじめに
業界のPLCでACSを含む典型的なオブジェクトを考えてみましょう。 鉱業では、加工工場（GO）で、鉱物（鉱石）を粉砕する段階でさまざまなタイプの工場が使用されます。 それらは球形、ロッド、垂直微粉砕などです。 これらの工場の主な機能は、鉱物の化学抽出に将来必要な鉱石を粉砕することです。 このような機器には、動作中に弱点があります。 Pobeditovyeメインベアリング、ギアボックスなど 一定の温度制御、潤滑などが必要です。 過熱または空運転の場合、ACSはノードの状態が臨界点に達するまでユニットをオフにする必要があります。 これらの保護とロックのソフトウェア実装は、この種の機器の典型的かつ標準的なものです。
間違いは何ですか？
このタイプの機器のACSの設計とプログラミングにおける2つの主なエラーを見てみましょう。 最初のエラーは、メインドライブまたはクリティカルメカニズムのリレー制御部分の誤った設計です。 2番目のエラーは、致命的なPLCエラーの処理に関するプログラムの欠如です。
スキームのエラー。
リレー部品の場合を考えます。 図は、このようなエラーの例を示しています。 この図は、機器のメインドライブのシャットダウン制御の一部のみを示しています。
一見、通常のリレー回路。 ただし、よく見ると、遅かれ早かれ、緊急時にリレー回路がメインドライブを切断できなくなる瞬間が来ると判断できます。 スキームを見てみましょう。 メインドライブは、ディスクリート出力を備えたPLCによってオフにされます。 この回路では、リレーですが、トランジスタでもかまいませんが、その本質は変わりません。 そのため、何らかの理由で機器の動作中にリレーコイルK1が焼損した場合、事故が発生すると、コントローラーはメインドライブをオフにする信号を出しますが、信号は焼けたリレーコイルを超えません。 しかし、結局のところ、技術によれば、メインドライブがオフになったとき、補助装置もオフにする必要があります。この場合はオイルポンプです。 したがって、事故中の水、オイルポンプは安全にオフになり、メインドライブは乾燥するために脱穀し続けます。 幸いなことに、システムにはアラートも含まれているため、不快な叫び声と赤いランプの点滅がサービス要員の注意を引き付け、「大惨事」は発生しません。 その後、地元の電気技師またはKIPOvtsyがこの不名誉の理由を見つけ、リレーを変更し、すべてが適切な場所に落ちます。おそらく誰かが将来これを避ける方法について考えるでしょうが、ほとんどありません。
したがって、この回路では、リレーK1が弱いリンクです。 これを防ぐためにできること。 小学校。 BBトリップ信号をリレーK1の常閉接点に設定し、メインドライブの起動中にリレー自体を引き付けて、作動状態に維持します。 ちなみに、非常停止ボタンもオンにしないでください。 ボタン接点はアクチュエータを直接オフにするか、そのようなメカニズムが複数ある場合は、接点がすでにアクチュエータをオフにしているリレー回路を切断する必要があります。 ところで、重要なアクチュエータによる中間制御リレーのこのオンは、PLCプログラミングエラー中に誤った処理を引き起こすことにもなります。
PLCプログラミングエラー。
PLCをプログラミングするとき、一部のプログラマは、産業上の緊急事態につながるミスを犯します。
最近、このような状況に直面しなければなりませんでした。 メインドライブのシャットダウンのリレー部分の回路は上記のとおりでした。 プログラミングエラーにより、メインドライブが4時間「ドライ」になり、ギアボックスが過熱しました。 その結果、ギアボックスは完全に故障しており、これはこの機器の高価な要素です。 何が悪かったのですか？
高い材料費につながる事故の原因を特定する際、ウォッチドッグタイマーの動作によりPLCが「STOP」モードに切り替わることがわかりました。 したがって、リレー回路はメインドライブを除くすべての補助機器をオフにしました。 ウォッチドッグタイマーは、メイン関数のループにつながらないアルゴリズムにデッドエンドブランチが存在するためにトリガーされました。 そしてご存じのように、PLCを製造しているほとんどすべての企業は、PLCのSTOPモードへの移行に伴い、ディスクリート出力を安全な状態でインストールしています。 この場合、状態は無効です。 このACSで、プログラマは2つのエラーを作成しました。
- 分岐アルゴリズムには行き止まりの分岐があり、それがウォッチドッグタイマーにつながりました。
- プログラムで例外が処理されなかったため、PLCはSTOPモードに切り替わりました。
プログラムの複雑さに関する最初のエラーを相殺します。このタイプのエラーを見つけるのは困難です。
2番目の間違いは、プログラマーの能力不足に起因します。
ご存知のように、多くのPLCには、さまざまな致命的なPLCエラーを処理するためのソフトウェアモジュールがあります。 例としてSiemens PLCを使用したこのようなモジュールを検討してください。
このようなエラーの小さな例を次に示します。
ここでは、プログラマはライブラリ関数FC105に基づいてアナログ入力を線形化します。 ビットM0.1を有効にするメインサイクルでは、アナログ信号がスケーリングされます。 すべて問題ありませんが、同じFC105がPLCにロードされていない場合、この行を実行すると、プログラムエラーハンドラー、いわゆるOB121を指定しないと、PLCは「STOP SF」で抜け落ちます。 そのようなプロセッサがPLCにロードされると、そのようなエラーでSF表示が表示されますが、PLCはSTOPモードにならず、ユーザープログラムの実行を継続します。
まとめると
リレー回路は、技術的な事故であってもPLCエラーであっても、事故の種類に関係なく、アクチュエータのシャットダウンが必ず実行されるように設計する必要があります。 メカニズムの破壊につながる重要な動作条件からACSを保護するように設計された機器は、ACS自体よりもはるかに高価であるため、PLCプログラミングにすべての責任でアプローチしてください。
この回路では、次のリレー回路コンポーネントを含める必要がありました。
また、ソフトウェアモジュールOB121で、PLCで発生した障害をアーカイブするためにいくつかのアクションを実行します。
ソフトウェアエラー中のPLCの動作とその処理を示すビデオを以下に示します。
おわりに
回路設計とソフトウェアの実装では、試運転の段階で常に検出されるとは限らない深刻なエラーが隠されることがよくあります。 運用中、会社の専門家は、システムの信頼性に関する完全なテストを常に実施するとは限りません。 さらに、メンテナンススタッフはしばしば資格を欠いています。 こうした緊急事態が無視できる程度になり、職場での負傷につながらないことを願っています。
PS
ハードウェアまたはソフトウェアのエラーを処理するために空のソフトウェアブロックだけを残すことも価値がありません。 このようなエラーを検出したり、PLCの障害と考えられる原因に関する統計を収集したりするには、何らかの措置を講じる必要があります。