私の観察によると、SCADAを扱うほとんどのインテリジェントACADスペシャリストは、「感情的な成長」のいくつかの段階を経ます。SCADAをマスターし、より良いものを探し、独自のバージョンを書くためのアイデアと試み、問題に対する哲学的態度を開発し、既存の製品。
はい、例外があります。 たとえば、機能するものを作成する非常に熱心で熱心な愛好家がいますが、彼らは絵をまったく変えません。
これがなぜ起こるのか、この悪循環から抜け出す方法があるかどうかを考えてみましょう。
注：さらなる考慮事項は主に商用製品に関係しますが、多くの点でオープンソースプロジェクトに当てはまります。これについては別途説明します。
最初の近似では、SCADAシステムを使用するプロセスは、PLCとのデータ交換用のパラメーターの選択、特別なエディターでのニーモニック図の開発、イベントロギングとパラメーターの状態の設定など、いくつかのアクションに削減されます。 ニーモニックダイアグラムのグラフィック要素と単純な数学的計算の複雑な動作を保証するには、スクリプトを使用するか、エディターで構成された最も単純なアニメーションの手段で十分であると一般に想定されています。
このアプローチの大部分は正当化されています-簡単に習得でき、簡単なプロジェクトをすばやく実装できます。 概して、始めるための最小限のプログラミング知識さえ持っていないかもしれません。
現在、機能、コスト、開発の容易さなどが異なるかなり多数のSCADAシステムがあります。 適切なオプションを選択して、良い、明るい、永遠の創造を開始するように思えます...しかし、それはすべてがそれほど単純ではないことがわかります。
- 模倣図上に多数の要素を含む大規模なプロジェクトを作成する必要が生じた場合、またはかなりの量の計算が必要になった場合、非常に低い速度がすぐに目を引きます。 計算をPLCにシフトする必要がある場合、状況は特に滑comicです。ただし、その速度は最新のPCに比べて比較にならないほど遅いです。 ほとんどの場合、いくつかのスレッドの実行を整理することも忘れることができます。
- SCADA開発者が想定していないことをしようとする試みは、膨大な人件費を伴う非常に重要な決定に容易に変換されます。
- 閉じた内部メカニズムと不完全なドキュメント。 たとえば、商用SCADAのデータストレージ形式とデータベース構造の完全な説明を見つけてみてください。
- 最新のソフトウェア開発戦略に関する記事の多くの著者は、最適化やコードテストよりも新機能の作成に比類なきほどの注意が払われている場合、一般的なアプローチについて否定的に語っています。 残念ながら、これはSCADAの世界でよく見られます。 開発プロセスでは、実際に開発するよりも、文書化されていないシステムの動作を回避するためにより多くの時間を費やす必要がある場合があります。 しかし、これらは高い信頼性が要求される産業用システムです。
- 高コスト-数百万の価値がある大規模な産業施設を作成する場合、5〜1万ユーロを割り当てることは大きな問題ではありませんが、大規模な印刷で生産された比較的安価な機器について言えば、コピーあたり200ユーロのコストでさえ許容できない贅沢になることがあります。
オープンソースシステムについて一言。 開発者への誠実な敬意を払って、すべての魅力にもかかわらず、このアイデアは実際には実行不可能であるように思えます。 その理由は、目に見えるコミュニティがない場合の莫大な人件費です。 そのような製品に興味を持ち、同時にオブジェクト指向言語で高品質のコードを書くことができ、そのようなプロジェクトに自由時間を費やす準備ができている人は少なすぎます。 実際には、既存の市販製品と競合できるものを作成するための作業量を認識し、あきらめます。
困難な点がわかったので、理想的なSCADAの要件を策定し、従来のパラダイムをわずかに超えて問題を解決できるかどうかを確認します。
- 高速が必要です。 これは、インタープリターがなく、出力は実行可能なマシンコードでなければならないことを意味します。
- 簡単かつ重大なリスクなしに、既存のコンポーネントの動作を変更したり、独自のコンポーネントを追加したりできます。
- 設定および履歴データを保存するための形式の透明性。 たとえば、レポートを作成するためにアーカイブから特定の選択を行う必要がある場合、SCADAに含まれるツールの長期的なリバースエンジニアリングは発生しません。
- シンプルさと開発のスピード。 コードの記述を最小限に抑え、ビジュアルプログラミングを最大限に使用する必要があります。 自動化プロジェクトで作業するために、商用SCADAと比較して大幅に多くの労力を費やす必要がある場合、誰がこれをすべて必要としますか？
- 便利で最新の開発環境（IDE）。 プログラマーの通常のツールが必要です：コード補完、バージョン管理など。
- サードパーティソフトウェアの低コスト、理想的には無料のオープンソースコード。
- これらの要件はすべて、複数の開発者の最小限の労力で実装する必要があります。
これはソリューションを請います-ビジュアルプログラミングのための既存の良好な環境を利用し、SCADAシステムの特定のタスクに合わせて調整されたコンポーネントのライブラリを作成する必要があります。 このように推論して、Qtを選択しました。 ここと既製のコンポーネントの塊、優れたIDE、そして巨大な開発者コミュニティ。
私が最初にQtに出会ったとき、私はこのライブラリの内部ロジックと豊富さに驚くばかりでした。 何かをするというタスクが発生するとすぐに、非常に多くの場合、これはすでにQtで実際に実装されており、ニーズに合わせて調整するだけでよいことがわかります。
タスクが正しく定式化されると、それを実装するのは簡単なままになります。 今日まで、最小限の紳士用コンポーネントのセットを実装することができました。
作成されたセットは、条件付きでいくつかのグループに分割できます。
- PLCとの通信用コンポーネント
- タグシステム。 実際、ドライバーとライブラリの他の部分との間のバッファーで、さまざまなプログラムコンポーネントからのデータへのアクセスを提供します。
- OPC DA2用ドライバークライアント。 私の意見では、現時点ではこれがPLCとデータを交換する最も一般的な方法であり、OPCサーバーなしで少なくともいくつかの一般的なデバイスを見つけることは非常に困難です。
- 記録の提供とアーカイブ情報へのアクセス
- 警報システム。
- 技術的パラメーターのログ。
- グラフィカルコンポーネント（ウィジェット）のセット。
- 技術的なパラメーターログからのグラフと傾向の構築。 ここではすべてが古典的です-蓄積されたデータの表示の選択と構成。
- 緊急メッセージの処理-アクティブなメッセージの出力、オペレーターによる確認（確認）、アーカイブ情報へのアクセス。
- ニーモニックダイアグラムのさまざまな要素の表示。 世論調査が示したように、ほとんどの企業は独自のアイコンを使用して技術機器の状態を示しています。 このため、タグの値に応じてグラフィックイメージ（点滅効果のあるイメージを含む）を表示できるコンポーネントが作成されました。
- 大規模なアニメーションパイピングスキームの構築。 SCADAで既製のアナログに出会ったことはありませんが、その必要性は明らかです。200〜300個のバルブを備えた大規模なシステムで指示を取得してください。
- カスタム要素の作成を容易にするコンポーネントのセット。
もちろん、まだ長い道のりがありますが、現在、産業オートメーションの古典的なタスクのすべてのタイプに加えて、アプリケーションのいくつかの可能な方向が検討されています。
- 既存のシステムの副次的問題を解決するためのユーティリティの作成。 たとえば、たまたま豊富な機能を備えたMatrikon OPC Data Managerの類似物を作成し、約4時間しか費やさず、かなりのお金を節約しました。
- 科学機器を操作するためのアプリケーションの開発。
- スマートホームシステム。
どういうわけか私には気付かないうちに、私の趣味はもっと何かに変わり、他の人に興味を持ちました。 この作品をスタートアップに変えるというアイデアがありましたが、これまでのところ、すべてはこの作品を私と共有する準備ができている人々の不足にかかっています。 スタートアップの開発に参加したい、新しい会社の原点に立ちたい、または共同創業者として自分自身を試してみたいという希望があれば、私に個人的に書いてください。
Facebookのページでもう少し情報を見つけることができます。
また、建設的な批判と新しいアイデアに非常に感謝しています。
最後に、小さなビデオFAQ：