完全な SCADA システムを作成しました(カスタム計測ハードウェアを除く)。このシステムは、新しいハードウェア モデル、計測器、およびデータ収集を作成できるように汎用的に設計されました。個々の企業/工場向けの多くの SCADA システムのようには書かれていませんが、何千もの企業/工場で国際的に使用されています。
私は唯一の開発者/デザイナーであり、経営陣の 1 人がプロジェクトを監督および指導していました。その方法は時間がかかりましたが、実行可能でした。すでに存在する他の SCADA 固有のシステム/フレームワークを調べたところ、ユニットがカスタムであったため、既存の開発フレームワークとサードパーティ コンポーネントを活用してゼロからシステムを作成する方が簡単かつ柔軟であると判断しました。振り返ってみると、時間とスキルがあったため、これは私たちにとって非常にうまく機能しましたが、ビジネス/契約モデルによっては、これは一般的に最適なソリューションではありません.
私はもうその会社にはいませんが、彼らはまだ私のソフトウェアを独占的に使用しており、私は素晴らしい条件で退職しました. 一般的な質問にお答えし、正しい方向に導くお手伝いをさせていただきます。
システムアーキテクチャー
システムの構成要素の概要は次のとおりです。
- さまざまなタイプ(アナログ、デジタル、圧力、アンペア数、フロートなど)の複数の計測器に対応する汎用入力を備えたカスタム セルラー デバイス
- カスタム形式の UDP/TCP パケットは、セル ネットワーク (GPRS) を介してユニットからサーバー ( Windows Server 2003 R2) に送信されました。情報はレポートのために定期的に送信され、デバイスまたはオンラインでプログラムできるカスタマイズ可能な状態変更(セル ネットワーク経由で送信される構成) についても送信されました。
- TCP/UDP リスナーを使用するカスタム マルチスレッド.NETアプリケーションは、着信パケット(1 日に数十万件)を取得し、カスタム ヘッダーを解読し、それ以上解釈せずに正しいデータベースにパケットをルーティングします(クライアントによっては、独自のスタンドアロン システムが必要でした)。
- システム全体の頭脳として機能するMicrosoft SQL 2005データベース。パケットはCLR 関数を使用して解釈され、(構成に従って)アラームが自動的にトリガーされ、レポートがコンパイルされ、完全な履歴が保持されます。
- 電話をかけたり、SMS メッセージを送信したり、電子メールを送信したりして、アラートを処理するカスタム.NETアプリケーション。電話のロジックは、録音されたプロンプトとテキスト読み上げの組み合わせを使用して、アナログ回線を介してIntel Dialogic Cardによって処理されました。
- 3 つのASP.NETサイト:
- アカウント/サブユーザーの管理、アラートの追跡、ユニットとアラートの構成、データのチャート化、デバイスのマッピング、レポートのエクスポートなどを可能にする顧客向けサイト。
- 営業担当者への資料の配布、個々のデバイスの追跡、デバイスの状態レポートなどを許可する販売サイト。
- 顧客アカウントの作成、ユニットの構成/構築、および必要に応じて他のすべての管理機能を可能にする内部管理サイト。
- また、システムの正常性を確認し、システムが 24 時間年中無休で稼働する必要があるため、必要に応じて技術者に問題を警告するカスタムの内部監視システムもありました。
- さらに、iOS アプリ、モバイル サイト、およびカスタム Web サービス/クライアント ( API ) を作成して、顧客が顧客データを直接取得できるようにし、顧客が当社のソリューションを既存の(通常はカスタム) SCADA システムと統合できるようにしました。
これらは私たちが使用したコンポーネントであり、機能しました。もう一度やり直すと、いくつかのことが変わります。Windows Server 2008 R2、SQL 2008 R2を使用し、Dialogic カードの代わりに VoIP を使用する Microsoft TellMeを使用します。ASP.NET の代わりにSilverlightも使用します。私は ASP.NET が本当に好きですが、Silverlight ははるかに優れたプレゼンテーションを提供でき、必要に応じてブラウザーの外部で使用できます (SCADA オペレーターからの一般的な要求)。
サイトはすべてサードパーティのコンポーネントを使用していたため、グラフや表を最初から作成する必要はありませんでした。SCADA 固有のコンポーネント(主に Java ベース)がいくつかあります。しかし、それらのほとんどは、私たちの一般的なシステムで使用するには粗雑で醜い、またはあまりにも具体的であることがわかりました (これも高価です! ゲージ/チャート パッケージをカスタマイズして独自のものを「作成」する方が簡単で柔軟性がありました)。
前述のように、システムの頭脳はデータベースでした。これが行われたのは、Microsoft SQL が優れたバックアップとパフォーマンス オプションを備えた極端なアップタイム用に設計された、十分にサポートされた非常に優れた製品であるためです。また、カスタム .NET コードをそのプロセスの一部として実行できる.NET CLR 統合にも感銘を受けました。私たちがサポートしていたユニットにはさまざまなモデルがあり、さまざまな機器の組み合わせを使用するように構成できたため、データベースを柔軟に保つことが重要でした。 多くの正規化を使用しました。
本当に役に立ったことの 1 つは、再帰 CTEを使用して、値がまだデフォルトであるときにデータの存在を偽造したことです。これはデータベースのスペースを節約するために行いましたが、データベースに抽象化のレイヤーを導入して、クエリを柔軟にすることもできました。
過去に OPC を台無しにしたことはありましたが、柔軟性に欠け、困難で、私たちのニーズにはいらいらしていました。それは数年前のことですが、それ以来私はそれを見ていませんでした。
それはあなたの質問に対する長くて非常に一般的な答えです。その情報はその会社の所有物であるため、特定のコードを提供したり、非常に詳細に説明したりすることはできませんが、設計に関するいくつかの質問に答えて、役立つフレームワーク/ツールを紹介することはできます. 私の主なアドバイスは、すべてを個別のコンポーネントに分割し、それぞれにブラック ボックス モデルを採用して、個々のコンポーネントを必要に応じて交換/改善できるようにすることです。そうでなければ、プロジェクトの範囲は圧倒されるように思えるかもしれません。さらに質問がある場合、または詳細情報が必要な場合はお知らせください。頑張ってください!