dataPARC Historian アーキテクチャのベストプラクティス
  • 29 Aug 2025
  • PDF

dataPARC Historian アーキテクチャのベストプラクティス

  • PDF

記事の要約

HeaderImage12

プロセス・データ・ヒストリアン・システムを構築する際には、多くのアーキテクチャ・オプションが存在します。最適な構成は、各サイトに固有のさまざまな要因によって異なりますが、アーキテクチャ設計プロセスを開始するには、いくつかの全体的な指針が役立ちます。このドキュメントでは、次の 3 つの一般的なシナリオで dataPARC Historian をデプロイする際の基本的なベスト プラクティスの概要を説明します。

単一サイトヒストリアン

単一の物理プラントサイトにオンプレミスにインストールされたデータヒストリアンソリューションには、通常、最も単純なアーキテクチャが必要です。ただし、セキュリティ、信頼性、コストなどのいくつかの懸念を考慮する必要があります。

標準シングルファイアウォール

以下の図の例は、ファイアウォールが 1 つある一般的なシステムを示しています。1台以上のデータコレクタPCがプロセス制御ネットワーク(別名OTネットワーク)にインストールされ、オートメーションデバイスやその他のリアルタイムデータソースからの直接かつ高速なデータストリーミングが可能になります。データ・コレクターは、このデータをバッファーにしてパッケージ化し、dataPARC Historian サーバーに送信します。データコレクタは通常、高性能PCである必要はなく、適切なネットワーク接続が装備されていれば、複数のデータソースに組み合わせることができることがよくあります。

通常、プロセス制御ネットワークとビジネスネットワーク(別名ITネットワーク)の間のファイアウォールを介して2つのポートのみを開く必要があるため、セキュリティ上の懸念は最小限に抑えられます。データは、GRPCプロトコルを介してデータコレクタからdataPARC Historianサーバに送信されます。

dataPARC アプリケーションサーバーは、サイトのサイズと予想されるデータロードに応じて、別のマシンである場合もあれば、dataPARC Historian サーバーと共有されている場合もあります。ヒストリアンサーバーとアプリケーションサーバー間の通信もGRPCプロトコルによって行われます。dataPARC アプリケーションサーバーは、さまざまなプロトコルを介してビジネスネットワーク上の他のソースとデータを交換することもできます。次の図はいくつかの例を示していますが、他にも多くの例が可能です。

dataPARC クライアントワークステーションもビジネスネットワーク上にあり、OPCUA を介してアプリケーションサーバーと通信します。これにより、アプリケーション・サーバーとの間のすべての通信が同じネットワーク上で行われるため、高いクライアント・パフォーマンスが得られます。

DMZ の実装

セキュリティ上の理由から、ビジネスネットワークとプロセス制御ネットワークの分離レベルを高める必要がある場合は、単一のサイトで、dataPARC Historianサーバーが常駐するDMZを設定することを選択できます。この場合、HistorianサーバーにはSQL(SQL ExpressまたはPostgreSQLなど)も必要になることに注意してください。このオプションの例を以下に示します。

全社的なヒストリアン

複数の物理的なプラントサイトを持つ企業には、完全に接続されたヒストリアンソリューションを構築する際のオプションもあります。各サイトのアーキテクチャは通常、上記の例と似ていますが、1 つの組織内のサイト間で多少の違いがある場合があります。

マルチロケーション「メッシュ」

dataPARCは、複数の「ロケーション」を相互接続して、プラントサイトのデータヒストリアンのメッシュスタイルのネットワークを構築する機能を提供します。このようにして、すべてのサイトが同じワイドエリアネットワーク(WAN)上にあり、各アプリケーションサーバーのPARCsecurity設定が他のサーバーとの接続を許可するように構成されている場合、各サイトのユーザーは、社内の他のサイトからデータを表示できます。事前に構成されたディスプレイをサイト間で共有したい場合は、他のサイトの PARCview ディスプレイ共有ディレクトリへのリンクを各アプリケーションサーバーのディスプレイディレクトリに追加し、適切なファイル権限を設定する必要があります。

一元化された企業歴史家

サイト間のデータ・アクセス負荷が高くなることが予想される場合は、一元化されたコーポレート・ヒストリアンとアプリケーション・サーバーを実装することで、システム全体のパフォーマンスを向上させることができます。このサーバーは、すべてのサイトの場所のヒストリアンをミラーリングでき、自分の場所の外部からデータを表示したいすべてのサイトからのクライアント接続をホストすることもできます。各サイト Application Server は、他の複数のサイトからクライアントにサービスを提供するのではなく、独自のローカル クライアントにサービスを提供するだけで済み、各サーバーの負荷を軽減します。コーポレート・アプリケーション・サーバーは、すべてのコーポレート・クライアントおよびサイト間クライアント接続に対応し、サイト間データ・アクセスのパフォーマンスを向上させます。

クラウドベースのヒストリアン

dataPARC HistorianおよびServer Applicationsは、Amazon AWSとMicrosoft Azureの両方のクラウドプラットフォームへのインストールと互換性があります。クラウド・ヒストリアン・アーキテクチャーは、地理的に独立した接続性があり、ハードウェアの購入やメンテナンスが不要な、拡張性の高いシステムという利点を提供します。ただし、クラウド ホスティングは多額の継続的なコストにつながる可能性があり、クライアントでのデータ ストリーミングのパフォーマンスは Web 接続の速度/信頼性に依存します。さらに、収集されたすべてのデータが Web 経由でクラウド サーバーに送信されるため、追加のサイバーセキュリティ対策が必要になる場合があります。

次の図は、ヒストリアンとアプリケーション サーバーがすべて Azure クラウド環境でホストされている例を示しています。プロセス制御ネットワークとビジネスネットワークの間のファイアウォールは、まだ存在していることに注意してください。


この記事は役に立ちましたか?