AWS IoT Greengrass の OPC-UA シミュレーターを使って AWS IoT SiteWise の検証を気軽に始めてみる

AWS IoT SiteWise は標準で OPC UA プロトコルをサポートしているため、製造現場で OPC サーバを導入している場合、比較的簡単に AWS とデータ連携を行うことができます。

しかし、いきなり本番のサーバにつなぎたくない場合や、SiteWise のことを事前に検証してみたいという場合があると思います。

そんな時のために、OPC UA のダミーデータを生成する OPC サーバのシミュレーターが AWS から提供されています。最近このシミュレーターを試してみる機会があったので、その手順をご紹介したいと思います。

事前準備

シミュレーターを動かす環境の準備

シミュレーターは SiteWise Edge が動くマシンと同じマシン上で動かす必要があるため、物理マシン（PCなど）もしくはクラウド上の仮想サーバを用意してください。

物理マシンを用意される場合は、amd64 のマシン環境を用意してください。Raspberry Pi などの Arm アーキテクチャはシミュレーターがサポートしていないので注意してください。
本記事では、手元にあった 「Linux が動いているミニ PC」 を使って検証作業をすることにしました。EC2 を利用する場合は Arm 対応の Gravition インスタンスは利用しないように注意してください。

AWS IoT SiteWise Edge の準備

シミュレーターを動かす環境の用意ができたら、2 つ目の準備はシミュレーターが動く環境の作成です。

シミュレーターはローカルで動く OPC サーバとして動くので、この OPC サーバをデータソースとして 「OPC UA でデータ収集して SiteWise に転送する仕組み」 を作ります。
そのためには、用意したマシン環境に AWS IoT SiteWise Edge のデータ収集アプリをデプロイする必要があります。（わかりやすく言うと、SiteWise Edge ゲートウェイを作る、ということです）

以下は動作イメージです。

SiteWise Edge の環境を構築する方法は下記のブログで紹介しています。
マネジメントコンソール上で簡単な入力を行うと、SiteWise Edge のインストーラをダウンロードできるので、用意したマシン環境でインストーラを実行すれば OK です。

https://dev.classmethod.jp/articles/sitewise-opcua-swgw/

なお、上記の手順ではデータソースとなる OPC サーバの「ローカルエンドポイント」に opc.tcp://localhost:4840 を指定していますが、ここはスキップして構いません。今回のシミュレーターをデプロイした後で、改めて設定します。

SiteWise Edge の準備ができたら、この時点で既に設定された OPC サーバ（シミュレーター）からデータを収集して SiteWise に転送する処理が動いています。
（しかし、今の時点ではまだ OPC サーバのエンドポイント設定が正しくないので、データ取得できていない状態が続いています）

補足

OPC UA シミュレーターは localhost を LISTEN するプロセスとして動くので、シミュレーターと SiteWise Edge は基本的に同じマシン上で動かす必要があります。

SiteWise Edge のマシンから SSH ポートフォワーディングで接続すれば、シミュレーターは別マシンでも問題ありませんが、検証のためにあえてマシンを分ける必要性がないので今回は1台のマシン上で検証しています。
何らかの理由で別ホストに分かれる環境で検証するような場合に利用することになるかと思います。

ポートフォワーディングする時は、SiteWise Edge のマシン上で次のようにしてやれば、opc.tcp://localhost:4840/bifrost-opc-ua というエンドポイントで別マシン上のシミュレーターにアクセスできます。

ssh -L 4840:localhost:4840 [User]@[シミュレータが動いているマシンのホスト名 or IP]

OPC UA シミュレーターのデプロイ

SiteWise Edge の環境（EC2などによるダミー環境含めて）を作成できたら、シミュレーターのデプロイを行います。
先ほどの SiteWise Edge の環境作成ではマネジメントコンソールから提供されるシェルスクリプト（インストーラ）を実行していたと思います。これにより、対象の環境には「AWS IoT Greengrass のコアソフトウェア」と「OPC UA でデータを収集して SiteWise サービスへ転送する Greengrass コンポーネント」がデプロイされています。

シミュレーターは、AWS IoT Greengrass のコンポーネントとして提供されているので、該当するコンポーネントを追加でデプロイすることでシミュレーターが利用できるようになります。

最終的には次のような構成になります。

コンポーネントをデプロイするために Greengrass のコンソール画面から「コンポーネント」の画面を開きます。
「パブリックコンポーネント」のタブ画面からSimulatorなどのワードで表示をフィルタリングして、該当のコンポーネントをクリックします。

aws.iot.SiteWiseEdgeOpcuaDataSourceSimulator の画面が開いたら、左上の「デプロイ」ボタンをクリックしてください。

デプロイ対象の選択では 「既存のデプロイに追加」 を選択します。
ここまでの作業で既に SiteWise Edge がデプロイされているので、そのときの「デプロイ」が残っていると思います。既存の「デプロイ」を更新する形でコンポーネントを追加することでミスオペレーションの予防に役立ちます。

次の画面ではターゲットを指定します。デプロイの名前は適当なものを付けてください。今回は deploy_opcua_simulator としています。
「デプロイターゲット」は既存の「デプロイ」を使うので変更なしで OK です。

「コンポーネントの選択」画面では、見やすさのため 「選択したコンポーネントのみを表示」 を有効にしておきます。コンポーネントの一覧に aws.iot.SiteWiseEdgeOpcuaDataSourceSimulator があれば OK です。

次の画面はそのまま「次へ」をクリックして進めます。

「詳細設定を構成」の画面もそのままで問題ありません。

最後にデプロイ設定をレビューして、問題なければ 「デプロイ」 をクリックします。

動作確認

正常にデプロイできていれば、localhost でシミュレーター(OPC サーバー)が起動しているはずなので確認してみましょう。

OPC UA のエンドポイントの確認

動作確認するためには、シミュレータとして動いている OPC サーバのエンドポイントを知らなければいけません。
このエンドポイント情報は AWS のマネジメントコンソールなどでは確認できないので、シミュレーターとしてデプロイしたコンポーネントのログから確認します。

該当のログは下記にあります。/greengrass/v2/ の部分は Greengrass コアソフトウェアのインストール時の設定で変わります。これはデフォルトの設定です。

/greengrass/v2/logs/aws.iot.SiteWiseEdgeOpcuaDataSourceSimulator.log

このログの中に次のように opc.tcp://... と記載がある部分を確認します。これがエンドポイントになります。
シミュレーターはローカルホストで LISTEN しているので、利用するエンドポイント名は opc.tcp://localhost:4840/bifrost-opc-ua となります。

UaStackServer - Binding endpoint opc.tcp://[YOUR_HOST_NAME]:4840/bifrost-opc-ua to 127.0.0.1:4840 [None/None].

類似のログとして、末尾に [Basic128Rsa15/SignAndEncrypt]. などが付くものがありますが、エンドポイントは同じなのでどのログを見ても問題ありません。接続時の認証の種類の数だけログが出ているものになります。

デバイス上で確認

シミュレーターがどのようなダミーデータを生成しているか確認したいので、デバイス上に OPC UA クライアントをインストールして確認してみます。

今回利用した OPC UA クライアントは GUI で利用できる 「UaExpert」 というものです。
クライアントアプリの入手方法や簡単な使い方については、下記のブログで紹介しているので参考にしてください。

https://dev.classmethod.jp/articles/use-gui-opcua-client-uaexpert/

なお、今回のデバイスは Linux マシンなのでクライアントアプリは Linux 版のものをダウンロードします。Linux 版のアプリは AppImage 形式で配布されています。

UaExpert が起動したら先程紹介したブログのように、接続する OPC サーバ（シミュレーター）の情報をセットしていきます。OPC サーバの URL を入力する場合は、先ほど確認した opc.tcp://localhost:4840/bifrost-opc-ua をセットしてください。

検証作業なので今回も相互認証無しで接続します。そのためセキュリティ設定の選択は None を選択します。

この状態でサーバに接続できるようになったので、左上のペインにできた OPC サーバー（OPC UA シミュレーター）を選択して接続します。

初回の接続時に OPC サーバーの証明書を信用するか確認されます。永続的に信用するなら Trust Server Certificate をクリックします。今回はこのセッションだけ許可したかったので（特に意図はありません）、Accept the server certificate... にチェックを入れて Continue をクリックします。

無事に接続できれば、OPC UA シミュレーターで生成されている各種データを参照することができるようになります。

下記では、次の2点のデータを中央ペインに表示しています。

• /integration/counter/Counter_000000
• /integration/random/Double_000000

OPC UA クライアントを使えばシミュレーターがどんなデータを持っているか分かるので、SiteWise の検証をする場合にどのデータを使えばいいか選択しやすくなります。

OPC UA シミュレーターのデータの詳細を把握するには？

先程は、UaExpert という OPC UA クライアントを使ってシミュレーターが生成するデータの詳細を確認できました。その他の方法で確認する方法が無いか確認してみましたが、公式ドキュメントやコンポーネントのログには記載がありませんでした。

SiteWise サービス側にデータを転送できていれば、アセットがなくてもデータストリームを見ればどのようなデータがどのようなエイリアス名で転送されているかを確認できます。
下記画像では、/integration で始まるエイリアスとして転送されているので、データストリームの表示をシミュレーターからのデータだけにフィルタリングしています。

しかし、データストリームからはデータ型など付随情報は取れないので、やはり事前に別途確認しておくのが良いかと思割れます。

（余談）SiteWise Edge の サーバー認証

ちなみに、SiteWise Edge で OPC サーバに接続する時は、上記の OPC UA クライアントのような「証明書の検証」を行う作業は発生しません。
SiteWise Edge では、デフォルトで「任意の証明書を信頼する」仕様になっているため、「認証無し」で設定されていると特に何事もなく OPC サーバに接続します。

相互認証を設定している場合は、SiteWise Edge の証明書を OPC サーバ側で信頼させるなどの事前作業が必要になります。

SiteWise 側で確認

最後に SiteWise Edge 経由でクラウドに転送されたシミュレータのデータをAWS 上（SiteWise 側）で確認したいと思います。

まず、SiteWise サービス側から SiteWise Edge に対してシミュレータのエンドポイント情報を更新する必要があります。
SiteWise のコンソール画面から更新したいゲートウェイの画面を開きます。「データソース」の設定画面にある「ローカルエンドポイント」の値を事前に確認しておいた opc.tcp://localhost:4840/bifrost-opc-ua に修正します。

次に SiteWise のアセットモデルを次のような内容で作成します。これは先程 OPC UA クライアントで確認した 2つのデータを SiteWise 上で確認したいためにセットするものになります。
(他のデータを確認したい場合は、適宜変更してください)

モデルができたら、このモデルからアセットを次のような内容で作ります。プロパティエイリアスはそれぞれ次のようにセットしています。(こちらも他のデータを確認したい場合は、適宜変更してください)

アセットの設定ができれば、該当アセットの画面から最新のデータ値を確認することができます。

注意点

OPC UA シミュレーターは明示的に止めない限り延々とメッセージの生成を続けます。そのため、SiteWise Edge によるデータ収集・転送も継続するので、利用していない間でも AWS IoT SiteWise のデータ取り込み料金が発生します。
使わない時はコスト削減のために、シミュレーターのコンポーネントを止めるか、削除しておいた方がいいかと思われます。

コンポーネントの停止は、該当マシン上で Greengrass CLI から止めるか、ローカルデバッグコンソールで実行できます。Greengrass CLI で行う場合は下記を実行します。

sudo /greengrass/v2/bin/greengrass-cli component stop \
  --names aws.iot.SiteWiseEdgeOpcuaDataSourceSimulator

ローカルデバッグコンソールは下記を参考にしてください。

https://dev.classmethod.jp/articles/greengrass-v2-aws-greengrass-localdebugconsole/

なお、Greengrass CLI やローカルデバッグコンソールでコンポーネントを止めても、恒久的には停止にはなりません。マシンの再起動などが発生するとコンソールは起動状態になるので、安心のためには多少面倒ですがコンポーネントを削除しておくといいと思います。

コンポーネントの削除は、コンポーネントのデプロイと同じ作業の中で該当コンポーネントのチェックを外すことで削除できます。

最後に

OPC サーバを実際に利用していないケースでは、その準備に時間がかかります。
各種プログラミング言語のライブラリなどを使って検証用の OPC サーバを自作してもいいですが、簡単にダミーデータを利用できるシミュレーターがあると便利です。

エンドポイント情報や接続時に使える認証の種類など、詳細はコンポーネントのログから確認する必要がありますが、最低限の動作検証をするには十分な機能を持っているのではないかと思います。

記事のボリューム的に「気軽な」雰囲気が感じられないかもしれませんが（汗）、「OPC サーバの用意と検証用データの用意」という観点では、ゼロから実環境を用意する場合に比べて全体の作業量は大幅にカットできると思います。

もし機会がありましたらご活用ください。