概要

山武製チャネルコントローラ(CHC)と通信接続するBAシステムの構築事例を紹介します。具体的には、山武CHCと通信接続を行うための通信ゲートウェイをVisual Studio(VB.net)による外部アプリケーションとして開発しています。通信ゲートウェイアプリは「HOST-CHC間通信プロトコル」でCHCとシリアル通信を行うとともに、IPLink経由でBA-Panelのタグにアクセスします。

リプレース前のシステム構成

この現場では、他社製の中央監視装置(HIM)と、電気・照明の制御を受け持つ専用コントローラ、空調制御を受け持つ「CHC」が稼働している環境でした。既設の中央監視装置は、専用コントローラとCHCそれぞれにRS232Cで接続されており、シリアル通信による電文授受を行い、HIMの画面上での表示および発停ポイントの操作をおこなっていました。しかしながら、長年運用されてきた設備の老朽化により、特にHIMの劣化が顕著であり、画面操作のレスポンスの悪化が通常業務に支障をきたしている状況でした。

 

設備の老朽化に伴うリプレースプロジェクトでは、いきなり全ての設備を置き換えるのではなく、空調、照明、などのサブシステム単位で段階的にリプレースしていく手段が求められますが、この事例では、第一段階として、老朽化した中央監視装置(HIM)をBA-Panelで再構築するとともに、電気系の専用コントローラをPLCで再構築し、空調制御のCHCは残した状態でリプレースする事となりました。

左記のうち、リプレース対象となったのは以下の機器です。
・中央監視装置一式   
・電気専用コントローラ一式   
・照明専用コントローラ一式

山武CHCは残しておく必要があるため、新システムでは何らかの方法でCHCとの通信ゲートウェイを構築する必要がありました。

また、既設中央監視は単体構成であり、いわゆる二重化(冗長化)がなされておらず、HIMが異常停止すると無監視となる点も問題視されていました。

総管理点数 約3000点
総画面数 約110画面
中央監視機器構成 ・他社製HIM
・冗長化なし
・モニタ2台設置
・タッチペン式のインターフェース
下位側機器構成 ・空調 ・・・山武CHC *1台(2チャネル)
・照明 ・・・専用コントローラ *1台
・電気 ・・・専用コントローラ *1台
特徴 ・既設の中央監視システムと各コントローラ間は、それぞれRS232Cで接続されている。
・空調設備のスケジュール制御はCHC側で行われている。
・機器異常、不一致などの検出はCHC側で行われている。
・照明設備のスケジュール制御は専用コントローラ側で行われている。
・その他、火災発生時の連動制御、復旧操作などもCHC側で行われている。

リプレース後のシステム構成

既設CHCとシリアル通信を行うゲートウェイとして、外部アプリを独自に開発しました(VB.net)。

 

G/W外部アプリはCHCとの定周期のシリアル通信(ポーリング)を行いつつ、IPLinkが提供するAPIを呼び出して、自PC内の「FA-Driver」が持つメモリデバイスタグに対してCHCから授受したデータを書き込みます。同様に、タグの変化を監視して、CHCに対して書き込みを行う発停操作等の下りデータも処理します(画面からの発停要求を、電文を介してCHC側に書き込む処理)。

 

中央監視を受け持つBA-PanelとFA-Driver間でのタグデータの授受については、BA-Panel側にIPLinkユニットを定義してFA-Driver上のタグを参照することにより、自動的にリンクされる仕組みとしました。

 

また、BA-Panelの二重化機能を利用し、中央監視の冗長化も行いました。二重化構成では主系(現在稼働している側)に異常が発生すると、自動的に待機系(現在待機している側)に制御が切り替わります。

使用パッケージ ・中央監視 ・・・ BA-Panel5 *二重化構成
・CHCゲートウェイ ・・・ FA-Driver5
総管理点数 約3000点
総画面数 約80画面(解像度向上による統廃合を実施し、画面数を削減)
中央監視機器構成 ・中央監視用のサーバPCを2台構成とし二重化を構築。
 メイン、サブの両サーバのそれぞれのモニタ上で、
 中央監視画面の表示・操作が可能。
・CHCゲートウェイ用に工業用PC1台。
下位側機器構成 ・空調 ・・・山武CHC *1台(2チャネル) 既設のまま残す
・照明 ・・・MELSEC-Q PLC *1台 MCプロトコルで接続
・電気 ・・・MELSEC-Q PLC *1台 同上

その後、この事例の現場では、第二段リプレース時にCHC配下の機器を全てLonWorks構成に置き換えました(各種I/OとDDCを、LonWorks対応の機器に段階的に置き換え)。BA-PanelはLonWorksにも標準で対応しているため、CHCと通信しているポイントの接続情報を段階的にLonWorksのポイントに切り替えていく事で、スムーズな更新対応を実現しました(この事例紹介では第二段リプレースの詳細は割愛します)。

技術的特長

               

CHCゲートウェイ機能 山武CHCとの通信ゲートウェイとして専用に1台のPCを用意し、VB.netにより独自に開発したG/W外部アプリを常駐実行させる構成としました。CHCとの通信仕様としては「HOST-CHC通信プロトコル」と呼ばれている仕様が存在しており、ポーリング/セレクティング方式のシリアル通信を行っています。通信プロトコルで定められている電文仕様の中から、本システムとして必要となる電文コードを全て洗い出して実装し、CHCに対する定周期でのポーリングおよび、上位からCHCに対する発停・設定の下り書込みを行うための常駐プログラムを構築しました。

また、ゲートウェイPCでは、中央監視側のBA-PanelとIPLink連携させる事を目的として、ロボティクスウェア製パッケージである「FA-Driver」を導入しました。G/W外部アプリはシリアル通信でCHCとの電文授受を行った結果を、FA-Driver上に定義されたメモリデバイスタグに対してIPLinkのAPIを介して展開しています。FA-Driver上のメモリデバイスタグはBA-Panel側のIPLinkユニットからネットワーク参照される事により、両者は自動的にリンクされ、結果としてBA-Panel側のポイントデータとの動的な連動を実現しています。

スケジュール制御 既設設備のスケジュール制御では、中央監視装置のHIM画面は表示・編集機能のみであり、実際のスケジュール発停制御は全て下位側コントローラ(CHCおよび専用コントローラ)によって実行されていました。

課題として、電気・照明の専用コントローラを全てPLCに移行してしまう事により、PLCに移行した照明ポイントのスケジュール制御をどのように実現するのかという点と、既設CHCのスケジュール制御ではスケジュールの「山」の数(1日の間にON/OFF制御できる回数)が少ないという制約に対して、1日にスケジュール可能な山の数をできるだけ増やしたいというユーザー改善要望も解決する必要がありました。

これらを実現するために、新システムでは全てのスケジュール制御機能をBA-Panel側に移行しました。具体的には、BA-Panelのスケジュール機能のうち、HIM側でスケジュール制御を行う「HIM制御」を用いて、BA-Panel側での自動スケジュール制御を実現しました。

工夫した点・生じた問題の解決策など

CHCとの事前電文調査

CHCと既設中央監視間で実際にどのような電文授受が行われているのか、念入りな事前調査を行いました。

具体的には、CHCと既設中央監視間に接続されている通信ケーブルをジャックしてラインモニター(プロトコルアナライザ)を仕込み、すべての通信内容の記録をとり、詳細な解析を行いました。考えられる一通りの電文を発生させるために、発停操作、設定操作、計測値を変化させる、計量をカウントアップさせる、現場側で一通りの警報種別(状態警報、上下限警報、不一致警報など)を発生させる、中央監視とCHC間での通信断からの復帰・初期化時の電文授受がどうなっているのかを調べる等々の現場調査を行いました。また、そのままラインモニタを数日間現場に設置してデータを記録させていただき、回収後、特に日をまたいだ際の処理がどのようになっているのか等を念入りに解析しました。

尚、このようなCHCリプレースを数件対応した経験からして、一見おなじプロトコルに見えても電文の詳細が現場により微妙に異なる場合があった事もあり、毎回、上記のような詳細な事前調査を行うようにしています。

(例えば、現場で実際に記録された電文を解析してみたところ、事前に入手していた通信仕様書に記載のない不明な2バイトコードがデータ部の末尾に付与されており、現場で稼働していたバージョンは仕様書の記載内容と異なる拡張バージョンである事が判明した事例あり)

CHC側の制御機能の移行

新システム側にスケジュール制御を移行する場合、実際にシステムを移行するタイミングで、CHC側に登録されていたスケジュール設定をすべて削除しておかないと、新システムによるスケジュール制御と重複した制御が行われることになります。従って、システム移行の際にはCHCに精通したエンジニアを確保し、適切なタイミングでCHC側のスケジュールデータをすべて削除してもらう必要があります。

同様に、火災連動や停復電制御などがCHC側で構築されていた場合、これらを新システムのHIM側に移行してしまう際には、スケジュール制御の場合と同様に、CHC側の設定をすべて無効にすることを忘れないようにしなければなりません。CHC側の火災や停電の入力信号をうっかりそのまま残していると、システム移行後に実際に停電が発生した際などに、CHC側で意図しない停電処理が走り、CHC側で復帰操作を行うまでCHC配下の発停ポイントの操作が保留になる等の運用障害が発生する可能性があります。