1

現在、煩雑であることが判明しているばらばらのリアルタイムOPCシステムを再設計中です。私たちのテクノロジースタックは、32ビットのWindows Server 2003でホストされるC＃、. NET 4、SQL Server 2008 R2です。物理的なアーキテクチャでは、現在、すべての層を単一のサーバーでホストするように指示されていますが、十分な動機付け（読み取り：ROI）があれば可能です。 2に増やします。

基本的な既存のアーキテクチャは次のとおりです。

  • 外部OPCデバイスは、Webサービスを呼び出して、SQLにリアルタイムデータ（1秒あたり約300イベント）を入力します。ここでは、ボリュームまたはバッチ処理を制御できませんが、書き直しでは、1秒あたり300の挿入ステートメントからSQLを節約するために、Webサービスにバッチ処理を実装したいと思います。
  • SQLは、アラームからレポートに至るまでのタスクを実行するさまざまなコンポーネント（合計で約9つ、すべて再設計される）の中心的なリソースとして使用されます。これは現在、既存の設計の最大の問題であり、これらすべてのコンポーネントがデータを消費/操作したり、動作を制御したりする単一のBLLやDALさえありません。
  • コンポーネントの範囲は、WindowsサービスからWebサービス、Windowsアプリケーションまでです。CPU時間とSQL接続の最大の消費者は、すべてのリアルタイムデータを監視し、必要に応じてアラームを発生させるWindowsフォームアプリケーションです。また、実行にかなりの費用がかかるリアルタイムのトレンドグラフも実行します。

書き直しについては、学習曲線を除けば問題がないWPFへの強い推進力があります。私の質問は、基盤となるアーキテクチャにもっと関係しています。

  • 私は現在、単一のDALとBLLを実装する方法についていくつかの調査を行っています。DALの場合、私はEFまたはnHibernateに傾倒しており、Linq-to-SQLも可能です。
  • BLLの場合、私はCSLA.NETの経験しかありません。これは、速度とリソースの消費が重要なシステムでは、少しやり過ぎかもしれないと思います。

誰かが同様のシステムの経験があり、いくつかのレッスンや設計ガイドラインを喜んで共有しますか？

4

2 に答える 2

1

私が実装したアプリケーションはあなたのアプリケーションほど大規模ではなかったと思いますが、私はOPCサーバーからデータを取得することにある程度触れています。私のアプリケーションでは、パブリッシュ/サブスクライブアーキテクチャベースのメッセージングレイヤーがあり、私の経験に基づいた提案は次のようになります。

1）リアルタイムのデータ取得には、パブリッシュ/サブスクライブメカニズムに基づくものが必要になります。Bizトークサーバーは、ESBに対するマイクロソフトの回答です。だから私はこれを見るでしょう。
2）Windowsフォームアプリケーションはデータベースを直接調べる必要がありますか？つまり、履歴目的でデータベースを確認したり、リアルタイム情報だけが気になる場合はリアルタイムフィードをサブスクライブしたりできる中間体を確認できますか？

于 2011-04-12T13:39:00.907 に答える
0

SQLサーバーをシステムの中心点として使用するというアイデアが好きかどうかはわかりません。このサーバーは打撃を受けます-デバイス上のデータが変更されるたびに、データベースに書き込みます。その後、すべてのクライアントは一定の速度で継続的に更新し、変更があるかどうかを検出します。これは、SQLサーバーにとって多くの作業になります。

OPCプロトコルには、サーバーにサブスクライブしているクライアントが関与するため、データの変更についてクライアントに通知できます。途中でSQLを使用すると、これを防ぐことができます。

OPCサーバーを使用/作成してデバイスからすべてのデータを取得し、各クライアントがこれに接続できるようにする方がはるかに良いと思いませんか？そうすれば、データが変更されたときにのみデータを受信し、更新を常にチェックする必要はありませんか？

履歴上の理由でログを記録する必要がある場合は、いつでも追加のクライアントを作成して、データをSQLデータベースに記録できます。

于 2011-04-12T13:39:25.197 に答える