EXOR パネルのTutorial第9話になりました。前回はOPC UA 機能を紹介しましたが、次はOPC UA DA(Data Access)ではなくAlarm and Eventの機能・概要・そして簡単Nodeを紹介していきます。
さ、始めよう！
Reference Link
OPC UA Alarm
OPC UAアラームは、Acknowledgeable Conditionsを特殊化したもので、ConditionにActive状態やShelving状態、Suppressed状態などの概念を追加したものです。状態モデルは下図のように示されています。
Active状態のAlarmは、Conditionが表す状況が現在存在することを示す。アラームが非活性状態である場合、それは正常な状態に戻った状況を表している。
アラームのサブタイプの中には、アクティブ状態のサブステートを導入するものがある。例えば、温度を表すアラームは、高レベル状態だけでなく、クリティカル・ハイ状態も提供することができる。
また。サービス停止、抑制状態は、アラームがまだ完全に機能し、クライアントへのサブスクリプション通知に含めることができる点で、無効状態とは異なります。
一般的に、アラームに関連するアクションが一定期間とられないと、プロセスはある閾値を超え、その時点で結果が発生し始めることになります。OPC UAアラームモデルは、これらの状態、遅延、アクションを記述します。
Implementation
では実際EXORパネルからOPC UA Alarm機能を使ってみましょう。
Enable alarm
OPC UA Server InterfaceのところにEnable alarmsのCheckboxをいれてください。
Alarmsの作成は前回のTutorialにも説明しましたので、今回は省略します。
そしてUaExpertからEXORのOPC UA Serverをアクセスすると、AlarmsのFolderがありましてAlarm1,Alarm2,Alarm3のようなObjectがありました。それらのObjectはOPC UA Alarmsになります。
Severity
Severity は、OPC10000-5で定義された基本イベントモデルから継承される。特にProcessConditionClassTypeのAlarmsに関連して、Severity の緊急度を示し、もしくは「優先度」とも呼ばれる。
Event ID /Ack
では実際キーエンスKV8000のB2=Trueにしてみます。 Alarm B2はAcknowledgeの操作が必要のアラームになります。
いまからOPC UA サーバーからKeyence Alarm B2をAcknowledgeしてみます。Alarm3>Acknowledge>Callをクリックします。
Acknowledgeは実際OPC UA Methodになりまして、EventIdをInput パラメータとして受け取り。そのEventIdに沿って該当するアラームをAcknowledgeするような流れです。
Alarms>Alarm3>EventIdのNodeを開くとHEX Formatで表示してる値があります。それはEventIdです。
AcknowledgeのMethodに戻り、EvetnIdのField隣にある…ボタンをクリックします。
Edit Valueの画面が表示され。EventId値をそのままPasteしWriteボタンをクリックします。
最後はCallボタンを押してMethodを実行します。
Done!ResultにSucceededの緑Fieldが表示されたら、Methodが成功に実行しました。
EXORのパネルのアラーム画面を確認すると、Keyence Alarm B2のStateが”Trigger Acked”に変わりました、つまりAcknowledgeされた状態になります。
Disable
Disableメソッドは、ConditionインスタンスをDisabled状態に変更するために使用される。通常、ObjectIdとしてオブジェクトインスタンスのNodeIdをCall Serviceに渡しますが、AddressSpaceにConditionインスタンスを公開しないServerもある。したがって、すべてのサーバは、クライアントがObjectIdとしてConditionIdを指定してDisableメソッドを呼び出すことを許可する必要があります。（実際はこのアラームを無効にすると考えてたほうがいいでしょう。）
Alarms>Alarms3>Disbale>右クリックをクリックCallします。
DisbaleもMethodの1つ、Callするだけで該当するアラームが無効になります。
Done!Methodが実行成功になりました。
いまKeyence Alarm B2を発火させるデバイスB02=Trueになっても、アラームはTriggerされないようになります。
Enable
Enableメソッドは、Conditionインスタンスをenabled状態にするために使用される。通常、ObjectIdとしてオブジェクトインスタンスのNodeIdがCall Serviceに渡されますが、AddressSpaceにConditionインスタンスを公開しないServerもある。したがって、すべてのサーバは、クライアントがObjectIdとしてConditionIdを指定してEnableメソッドを呼び出すことを許可する必要があります。（実際はこのアラームを有効にすると考えてたほうがいいでしょう。）
Enableする方法はDisbaleと同じく、Alarms>Alarms3>Enable>Callします。
Enable Methodを実行するために”Call”をクリックします。
Done!
EXORのアラーム画面から確認すると、Keyence Alarm B2を発火させるデバイスB2=Trueになると、AlarmがTriggerされるようになりました。
Active Status
こちらのNodeでは該当するアラームの状態を文字列として確認できます。例えばAlarm3の状態を確認したいのであればAlarms>Alarms3>ActiveStateを開いていただければOkです。
いまはActive状態です。
EXORアラーム画面を確認してみます。Alarm3はいま”Trigger Not Acked”になっていて、つまりActiveされていますね。
アラームを解除するとActiveStateがInactiveに変わりました。
ACK Status
Acknowledgmentの承認は通常以下の２つの方向からきます。
- クライアントから
- サーバーの内部ロジック
例えば、アラームに関連するConditionのAcknowledgeは、このConditionがAcknowledgeされる結果、または自動的に Acknowledgeするようにセットアップされるかもしれない。
この規格では、2つのAcknowledge状態モデルがサポートされ、Ackの機能を拡張すれば、より複雑なアクノレッジ状況をサポートすることができる。
基本的なAcknowledge状態モデルは、下図のようになります。
このモデルは、AckedStateを定義している。具体的にどのような状態変化をもたらすかは、Serverの実装に依存する。たとえば、一般的なアラーム・モデルでは、変化はActive状態への遷移またはActive状態内の遷移に限定される。
アラームのAcknowledge状態を確認するには、Alarms>AlarmX>AckedStateからアラームのAcknowledge状態を文字列として確認できます。
Alarm3のStateはいま”Trigger Not Acked”に表示され、AckedState値は”Unacknowledged”になっています。つまりAckしてないと示しています。
Alarm3をAckしたらState=”Trigger Acked”になり、AckedStateも”Acknowledge”に変わりました。
SourceName/SourceNode
SoruceNameは文字列で該当するアラームの発火デバイス名を表示します。
SourceNodeは文字列で該当するアラームの発火デバイスNodeを表示します。
Message
Messageでは該当するアラームのメッセージが格納されています。
