ナビゲーションをスキップする
All Places > All Things PI - Ask, Discuss, Connect > Japan PI Square > ブログ > 2017 > April
2017

ユーザーカンファレンス2017が行われ、その中でAF SDKの実装についての発表があったので、そのご紹介をさせていただきます。

Best Practices for Building AF SDK Applications (David Moler )

http://www.osisoft.com/Presentations/Best-Practices-for-Building-AF-SDK-Applications/

AF SDKでデータ取得するときにBulk Callにより飛躍的にパフォーマンスが向上する話が出ています。

パフォーマンスは以下で計測したそうです。

1000個を超えるメーターがあった際にその中のpowerを積算する計算を例にしています。

(Rollupでもいいのではと思ってしまいますが、まあパフォーマンステストなので、お付き合いください)

以下のようにシンプルに式を書くと、すごく時間がかかります。

①シンプル (1分24秒)

結果としては1分24秒もかかっています。(Elapsed timeがすべてのかかった秒数です)

以下はAF サーバー側とAF クライアント側、PI クライアント側のどこで時刻がかかったかを示しています。

この1分24秒を改善していくというシナリオで、まず試したのが Full Loadの使用です。

 

② Full Load の使用 (33秒)

foreachでFindElements(fullLoad: true)を追加しています。

そうすることで、foreach内の属性ではすでに属性がロードされているため、速度向上が図れます。

ちなみにEndOfStreamはsnapshotをUOM変換をプラスして取得するメソッドです。

詳しくはPI Live Libraryをご参照ください。(英語となります)

https://techsupport.osisoft.com/Documentation/PI-AF-SDK/html/M_OSIsoft_AF_Data_AFData_EndOfStream.htm

 

Full Loadの結果33秒という数字がでています。大幅な改善ですね。

さらにその後追加したのがBulk Loadの使用です。

 

③Bulk Load の使用 (17秒)

AFAttributeListにオブジェクトを追加し、そのlistオブジェクトからデータを取得します。

そうすることで1つ1つの属性に対して1回ずつサーバーに問合せに行く必要がなくなり、まとめてデータ取得が可能です。

その結果 17秒という結果となりました。

通常は大体ここまでですが、このプレゼンテーションではさらに次のことを試しています。

 

④ Cache search resultの使用 (14秒)

上記Bulk Loadの結果を見るとSearchObjectIdsというところでAF Server 3,354 AF Client 3,489と7秒近くかかっています。

キャッシュを使用することでこの速度が改善されます。

CacheTimeoutはキャッシュの保持期間となります。

もちろん、キャッシュなので、初期クエリ時はキャッシュがありません。2回目から速度改善が見込めるということですね。

その結果 14秒となっています。キャッシュを使用することでSearchObjectIdsにかかる時間が大幅に減りました。

ただし、GetModelsでまだ時間がかかっていることがわかります。

そこで次に試したのが以下です。

 

⑤Multi thread Load (4.7秒)

Multi threadを使用すると複数のプロセスが同時進行でクエリを処理します。

Multi threadの結果 4.7秒となっています。

上記結果をまとめると以下のように表で表せます。

上記より、

1. 沢山のRPCコールを行うならBulk callとしましょう

2. サーチに時間がかかっているならキャッシュを使用しましょう

3 Client側でプロセスに時間がかかっているならMulti threadとChunkが使用できます。

Buik, Multi thread(Parallel)については以下ポストも参考にしてください。

https://pisquare.osisoft.com/community/all-things-pi/japanese/blog/2017/03/28/afsdkによる複数アイテムのbulk読み込み

上記ビデオではほかにも将来のバージョンでサーチ時の速度向上についてやAFDataCacheの使用方法なども紹介しています。

 

さらに2017のLondonのユーザーカンファレンスでも同様の発表がされました。

https://www.osisoft.com/Presentations/Best-Practices-for-Building-AF-SDK-Applications-1x/

こちらではEvent Frames Searchの効率化やAttribute Search, Cacheについて追加されています。

以下がその内容です。

通常の方法で取得すると、2.442秒という結果でした。

Lite-Weight Searchという方法で、取得するフィールドを限定できます。

結果0.789秒で取得できるようになりました。

 

また、Attribute Searchのメソッドも紹介されています。このメソッドは2017 R2以降のバージョンで使用できます。

Light-Weight Searchもあります。

 

さらに長期にわたり動作するサービスアプリケーションを使用するときはキャッシュが利用できます。

このData Cacheを使用することで0.039秒で結果が取得できました。

複数のデータアイテムの更新を取得することもできます。

 

このコードにより、複数アイテムの変更も0.069秒で処理が完了しています。

キャッシュのアップデートが完了したらデータを読めばよいわけですね。

PI Coresight 2016 R2に写真を表示するカスタムシンボルについてのブログポストを作成した後に、PI ProcessBookで同じことできますでしょうかという質問を受けました。

 

取り急ぎですが、

 

ブログポストは下記にあります。

PI Coresight 2016 R2にて時系列の写真を表示するカスタムシンボル 

 

  • PI ProcessBookに写真の表示の仕方
  1. 表示したい写真をフォルダーのパスを取得する

  1. タグに表示したいファイル名を保存する。

  1. PI ProcessBookのディスプレイに値のシンボルと画像のシンボルを追加する。

   

  1. 画像のシンボルをVBAでアクセスするため、「スクリプト記述」を有効する。

 

 

 

 

  1. 値が更新すると、この画像も更新するために、下記の関数をプロジェクトに追加する
Private Sub Value1_DataUpdate()
    Dim path As String
    Dim filename As String
    Dim vrStatus As Variant
    Dim vrDate As Variant

    ' このディスプレイを共有する場合は、画像のフォルダーを共有フォルダーにするとお勧め致します。
    path = "C:\OSISoft\OSIsoft_Projects\GeneratePicturesForCoresightDemo\frames"
    filename = ThisDisplay.Value1.GetValue(vrDate, vrStatus)
    
    ThisDisplay.Graphic1.Load (path + filename)
End Sub