Analytics Builder をはじめる

はじめに

本レポートは、Things Cloud の利用例をより知っていただくための実利用レポートとして作成したものです。 Things Cloud は極力後方互換性を持つよう開発されていますが、今後のリリースにより、一部画面やコマンド、手順などが変更となったり、 利用できない可能性があることをあらかじめご了承ください。 なお、作成にあたり、以下バージョンを用いています。

• ver. 1014.0.370 (backend/UI)
• Streaming Analytics ver. 1014.0.133 (UI)
• Apama-ctrl-05c-1g ver 10.14.0.5.20230223

Things Cloud のカスタムストリーミング処理機能(CEP/EPL)について記載しているカスタムストリーミング処理機能ガイドもあわせてご覧ください。

前提条件

• 本機能のご利用にはカスタムストリーミング処理機能申し込みが必要であること
• Apama Analytics Builder（以降、Analytics Builderとします） アプリをテナントに登録していること
• Analytics Builder 利用に必要な権限（CEP管理：管理者、オプション管理：読み取り、インベントリ： 読み取り）が付与されていること

Apama Analytics Builderの強みと活用シーンについて

難易度　★

所要時間

10分

目次

• Analytics Builder とは
• Analytics Builderが解決する課題
• Analytics Builderの強み
  • 処理がブロックに「まとまる」ので簡単
  • ブロックを「選ぶだけ」なので簡単
  • 「流れが見える」から理解しやすい
  • 強みまとめ
• Analytics Builderの活用例
  • 通信途絶からの復旧通知メールを出す
  • 計測値の統計データを計算する

Analytics Builder とは

Analytics Builder は、ブラウザ上でグラフィカルに、ノーコードでストリーミング分析モデルを構築できる機能です。下図のように、事前定義された処理ブロックを線でつなぐことで分析モデルを構築することができます。ブロックは処理内容、ブロック間をつなぐ矢印（ワイヤー）はデータの入出力を表しています。

Analytics Builderが解決する課題

Things Cloudにはapamaと呼ばれる分析プラットフォームが存在します。apamaの分析モデルの構築方法としてはこれまで、事前に定義された機能をパラメータ設定のみ行って動作させる「スマートルール」と、apama固有のイベント処理言語を使ってコーディングする「EPLコーディング」の2種類がありました。

Things Cloudのストリーミング分析ではまずスマートルールの活用を考えます。スマートルールでは「しきい値超過時にアラームを発生させる」「アラーム発生時に通知メールを送る」など頻繁に利用される機能が定義されており、操作も非常に簡単であるためです。スマートルールで実施できない処理が必要な場合には、EPLコーディングによりモデルを構築することができます。ただし、EPLコーディングは自由に処理機能を記述できる一方で、コーディングには一定の習熟コストが必要という課題がありました。

Analytics Builderは、その習熟コストの低さによりこの課題を解決します。ではなぜAnalytics BuilderがEPLコーディングより小さな習熟コストで分析モデルを構築できるのか、その理由を次章で説明します。

Analytics Builderの強み

処理がブロックに「まとまる」ので簡単

Analytics Builderでは、分析モデルを構築するうえで大事な処理がブロックとして定義されています。EPLコーディングであれば複数行のコード記述が必要な処理に関して１つのブロックにまとまっているため、非常に簡潔な表現で分析モデルを構築できます。

ブロックを「選ぶだけ」なので簡単

Analytics Builderでは、カテゴリ分けされたブロック群から必要なブロックを選択し、ブロック間をワイヤーでつなぐだけで分析モデルを構築できます。EPLコーディングのように様々な文法・組み込み関数・設計パターンを学習する必要がなく、それぞれのブロックが実現する処理さえ把握できればOKなので小さな学習コストで簡単に構築できます。

また、ブロックのパラメータ設定も簡潔です。例えば下図のMeasurement（計測値）の平均を計算するブロックは、最低限の処理を動作させるためのパラメータがデフォルトで設定されており、手動でのパラメータ設定なしでも動作します。また、設定可能パラメータは厳選されており、たとえば平均値計算のブロックでは「ウインドウ期間（何秒ごとに平均値を計算するか）」「一定以上の値だけを出力させるためのしきい値」のみが設定可能パラメータになっています。設定可能パラメータが厳選されることで、複雑な設定に迷わされることなく、簡単にストリーミング処理を実施できるのもAnalytics Builderの強みです。

「流れが見える」から理解しやすい

可読性が高いのもAnalytics Builderの強みです。Analytics Builderでは、ブロック間のデータの流れが矢印でグラフィカルに表示されます。起点となるブロックから始まり、どの順番で処理が行われているのか、あるブロックでの処理結果がどのブロックに送られているのか、いわゆる処理フローを直感的に理解することができます。

この特徴により、分析モデルを構築する際はもちろん、構築後の機能追加・不具合修正を行う場合にも、容易に処理フローを理解できます。

Analytics Builderの強みまとめ

まとめると、Analytics Builderは下記の強みをもつと言えます。

• ブロックとしてまとまった処理機能を選んでつなぐだけであり、設定すべきパラメータも厳選されているため、小さな学習コストで簡単に構築できる。
• 処理の流れがグラフィカルに目で見えるので直感的に理解しやすい。

Analytics Builderの活用例

前章では、Analytics Builderの強みをご説明しました。本章では、前述の強みをもつAnalytics Builderを実際にどのように活用できるか、実現できる処理の具体例を紹介します。

通信途絶からの復旧通知メールの送信

具体例の一つとして、デバイスが通信途絶状態から復旧した際に復旧通知メールを送信する、という実装をご紹介します。（より詳細な内容についてはこちらでご紹介しています。）

前提として、Things Cloudではスマートルールの機能を活用することで、特定のアラームの発生をトリガーにメールを送信する処理を実装できます。一方、特定のアラームがクリア（解消）された際にメールを送信する処理の実装は、スマートルールでは現状難しいです。そこで、本節では特定のアラームとして、デバイスの通信途絶を表す"c8y_UnavailabilityAlarm"というアラームを選択し、通信途絶アラームがクリア（解消）された際にメールを送信する処理をAnalytics Builderで構築します。上述の処理はスマートルールでは現状実装が難しいのですが、Analytics Builderを用いると非常に簡単に実装できます。

本処理機能は、下記のように最低限たった2ブロックで構築することができます。

入力ブロックのブロックタイプとして「アラーム入力」を選択し、ブロックの発火条件としてアラームタイプで「c8y_UnavailabilityAlarm」、デバイスとしてたとえば「温度センサ」、アラームステータスで「クリア」を選択するだけで、デバイス通信途絶のアラームがクリアされたことを電子メール送信のブロックに伝えることができます。

電子メール送信ブロックの設定は割愛しますが、同様にブロック内のパラメータ（宛先、件名、本文など）をGUI上で設定することで最終的な通知メールの送信も可能となります。

「みんながよく使う処理」は書きやすい

なぜこんなにも少ないブロック数で処理機能を実現できるのでしょうか。それは、誰もが頻繁に用いる定型的な処理パターンが優先的にブロック化されているからです。「typeやステータスに応じてアラーム（あるいはイベント、メジャーメント）を受け付ける」「電子メールを送信する」という処理はThings Cloud利用者の誰もが利用する処理です。こうした定型的な処理がそれぞれ1ブロックで表現されているため、上述したシンプルな構成でモデルを構築できます。

計測値の統計データを計算する

前節では、通信途絶の復旧通知メール送信を例に、「イベント発生の受付」という入力処理と「電子メール送信」という出力処理を組み合わせてモデルを構築しました。本節では入力処理と出力処理に加え、その間で実施される演算処理も交えた活用例をご紹介します。（より詳細な内容についてはこちらでご紹介しています。）

具体的には、一定期間内に受け取ったメジャーメントの平均値を計算する処理を実装します。平均値計算をはじめ、統計処理はデータの分析をするうえで頻繁に実施される処理です。例えば「機器の異常を発見するため、デバイスの1時間ごとのCPU利用率の平均値を知りたい」「電力使用量の削減のため、1日ごとの電力使用量の平均値を知りたい」など、多くの利用シーンが想定されます。

一定期間内に受け取ったメジャーメントの平均値を計算する処理は、下記の3ブロックで構築することができます。

一番左の入力ブロックでメジャーメントを受付け、中央の処理ブロックで平均値計算を行い、右側の出力ブロックで計算した平均値を新たなメジャーメントとしてThings Cloudに出力しています。

平均値計算のような統計処理も「みんながよく使う処理」であるため、Analytics Builderでは1ブロックで表現できるようになっています。よく使う処理を少数のブロックで表現できる強みは、平均値計算の処理でも前節の例と同様に示されています。

パラメータ設定のガイドがあるので迷わない

本節の事例では、設定すべきパラメータが厳選され、さらにパラメータ設置が画面上でガイドされるという、Analytics Builderの強みが活かされています。

Things Cloudにデータを出力する際に悩むのは「出力するデータにどんなパラメータを設定する必要があるのか」ということです。例えば、今回のようにメジャーメントをThings Cloudに送信する際には、「フラグメント名」「シリーズ名」「単位」という3つのパラメータを設定する必要があります。仮に、こうしたデータ出力の処理をEPLコーディングによって実装する場合、リファレンス文書を参照してデータ構造を把握する必要があります。

一方、Analytics Builderでは、下記のようにメジャーメント出力に必要なパラメータがGUI上で表示されるため、パラメータ設定で悩む必要がほとんどありません。

EPLコーディングの場合ではリファレンス文書を参照する必要があったパラメータ設定の作業が、GUI上のガイドに従うだけで完了するというのは、Analytics Builderを利用する際の大きなメリットです。

イベント処理モデルを作成する

※ このセクションは、旧バージョン ver. 1006.6.32(UI) に関する記述を含みます。

目次

• はじめに
  • 画面について
  • モデルの構成
• モデルを作ってみよう
  • 例題
  • Step1：温度シミュレーターの作成
  • Step2：モデルの作成
  • Step3：モデルの有効化
  • Step4：動作確認
• 実践
  • 実現したいこと
  • モデル構築例
• 参考：Block SDK を用いたカスタムブロック開発

はじめに

画面について

Analytics Builder はモデルマネージャとモデルエディタの2つの画面から構成されています。

• モデルマネージャ：モデルの新規登録/削除/インポート/有効化などを実施
• モデルエディタ：モデルを編集する画面。ドラッグアンドドロップで各パーツを移動させ、処理を組み上げる

モデルマネージャの画面は以下の通りです。 　

モデルマネージャにあるモデルをクリックし、モデルエディタの画面に移動すると以下のような画面が表示されます。

1. モデルエディタ起動時の画面 　
   
   
2. ブロッククリック時の画面 　
   
   

モデルの構成

Analytics Builder で構築するモデルは以下のブロックから構成されています。これらのブロックをワイヤーと呼ばれる線で繋ぎ、モデルを作成していきます。

• 入力ブロック（Input）
  モデルが起動するトリガーとなる情報（Measurement/Event など）の生成元を示すパーツ
  

• 処理ブロック（Logic/Calculation/Aggregate/Flow Manipulation/Utility）
  情報を処理するためのパーツで、集約、計算などの処理が可能
  

• 出力ブロック（Output）
  処理結果の出力先となるパーツ
  

以下の図のように、基本的には処理ブロックを中心とし、処理ブロックの入力として左側に入力ブロック、出力として右側に出力ブロックを配置します。

参考：便利な処理ブロック
処理ブロックには計算から集約、ユーティリティ用など、さまざまなブロックが用意されています。例えば以下のようなブロックが用意されています。その他ブロックの詳細は Overview of all blocks もご覧ください。今後のバージョンで多数ブロックが追加され、さらに柔軟な定義が可能となっていく予定です。

• AND/NOT/OR: 入力値に対する論理演算
• Difference: 入力値の絶対差と符号付きの差を計算
• Expression: 入力値を式に基づいて評価
• Threshold: 入力値がしきい値を超える/超えない/またいずれかを検知
• Minimum/Maximum: 入力値の最小/最大を計算
• Combiner: （複数）入力値に対する最小/最大/平均/最新算出、いずれかを実施
• Missing Data: 入力値が指定期間発生していないことを検知

モデルを作ってみよう

ここからは、例題をもとにモデルの作り方を学んでいきます。

例題

スマートルール「計測値のしきい値超過時 アラームを作成」を Analytics Builder で実現してみます。 温度シミュレーターの温度が -5℃から5℃ の場合を障害範囲に設定し、計測値がこの範囲に作成された場合、アラームを発生させることにします。

**参考：スマートルール「計測値のしきい値超過時 アラームを作成」**

補足：Analytics Builder ではアラーム作成のみ対応しています。スマートルールでは計測値が障害範囲外になった場合自動的にアラームはクリアされますが、今回はアラーム作成部分のみ実施します。

Step1：温度シミュレーターの作成

例題では、簡易化のため温度シミュレーターをデバイスとして利用します。 デバイス管理 > デバイス > シミュレーター より、温度計測のプリセットから温度シミュレーターを作成します。

Step2：モデルの作成

モデルの新規作成

アプリケーションスイッチャーから、「Apama Analytics Builder」へログインします。 モデルマネージャから「New model」をクリック、「Model Configuration」画面の「Model Name」を任意の名前に設定し、OKをクリックします。

入力/処理/出力ブロックを配置する

まず、計測値の生成元となる入力ブロック、アラームの生成先となる出力ブロックを配置します。 例題では、先ほど作成した温度シミュレーターを入力の計測値生成元、出力のアラーム生成元として使用します。

• 入力ブロック
  モデルエディタ左サイドバーの「Input」>「Devices」から 温度 #1 を選択し、ドラッグアンドドロップでエディタの中央に配置します。

• 出力ブロック
  Input の下の「Output」>「Devices」から同様に 温度 #1 を選択し、中央に配置します。

• 処理ブロック
  計測値を処理するための処理ブロックを選択します。今回は -5℃ から 5℃ が障害範囲で、計測値がこの障害範囲に 入っているかどうかを判定したいので、「Calculation」の中の Thresholdブロックを使用します。 「計測値が-5℃より大きい場合」かつ「計測値が5℃より小さい場合」という条件を作りたいので、2つ「Threshold」ブロックを配置し、 それぞれの結果を「Logic」の「AND」ブロックに渡すため、AND ブロックを配置します。

この時点では、モデルは以下の構成になっていると思います。

各ブロックのパラメータを設定してブロックを繋げる

次に、先ほど並べたブロックのパラメータを設定します。以下を参考に設定してください。

• Input ブロック

  パラメータ名	設定値
  Block Type	Measurement Input
  Device or Device Group	温度 #1
  Fragment and Series	c8y_Temperature => T

• Threshold ブロック1つ目
  Threshold ブロックでは、しきい値の数値と、しきい値に対する Direction（方向）を指定する必要があります。しきい値より大きい条件の場合は Above/Above or Equal、小さい条件の場合は Below/Below or Equal を指定します。大小関わらずしきい値を超えるという条件の場合（例えばしきい値8の場合、5 -> 10 や 12 -> 3 のように数値が推移する場合）は Crossing を指定します。

  パラメータ名	設定値
  Threshold Value	-5
  Direction	Above

• Threshold ブロック2つ目

  パラメータ名	設定値
  Threshold Value	5
  Direction	Below

• AND ブロック
  パラメータ設定項目なし

• Output ブロック

  パラメータ名	設定値
  Block Type	Alarm Input
  Device or Device Group	温度 #1
  Alarm Type	com_ThresholdAlarm
  Message	計測値が異常です
  Severity	Critical

パラメータの設定が完了したら、各ブロックを以下のようにワイヤーで繋ぎます。モデルが正しく処理されるようにするため、以下の画像通りにブロックの接続を行ってください。

参考：ブロックのグループ化
以下のように、ブロックをいくつか選択してエディタ上部のグループ化アイコンをクリックすると、ブロックをグルーピングすることができます。

Step3：モデルの有効化

一通りブロックを配置、設定したらモデルを有効化します。モデルエディタ上部ツールバーのフロッピーマークをクリックし、モデルを保存します。 次に、モデルエディタ右上の × をクリックしてエディタを終了し、モデルマネージャへ移動します。

モデルの実行モード

モデルの実行モードには、Draft、Test、Simulation、Production の4つが存在しています。これらを使い分けることにより、 より柔軟にモデルを開発できます。それぞれのモードについての説明は以下の通りです。より詳細は Deploying a model をご覧ください。

作成したモデルのモードで「Production」を選択し、「Inactive」スイッチを押して有効化します。有効化すると画像のようにスイッチが Active へと切り替わります。

参考：仮想デバイス（c8y_VirtualDevices）
Analytics Builder では、モデルのモードを Test または Simulation に設定した場合、モデルの出力イベントは c8y_VirtualDevices フラグメントを持つ仮想デバイスに出力されます。 仮想デバイスは Test/Simulation モードのモデルの実行結果が出力されるデバイスで、デバイス管理アプリケーションには表示されず、デバイスリクエストカウントの対象外です。Test/Simulation モードでモデルを実行する度に仮想デバイスが作成され、デフォルトでは30日間保持されます。

また、デバイス管理アプリケーション上部の検索バーから「c8y_VirtualDevice」でテナント内に作成されている仮想デバイスを確認できます。 より詳細は Virtual devices をご覧ください。

Step4：動作確認

次に、入力デバイスとして指定した温度シミュレーターを動作させ、モデルが期待通り動作するか確認します。

まず、「デバイス管理アプリケーション」>「デバイス」>「シミュレーター」から最初に作成した温度シミュレーターを on にします。 「デバイス管理アプリケーション」>「デバイス」>「すべてのデバイス」から、「温度 #1」を選択し、デバイス詳細画面を表示します。 「アラーム」タブを表示し、しばらく待って「計測値が異常です」というアラームが発生するのを確認します。

下の画像のようにアラームが表示されていれば期待通りモデルが動作しています。

例題では「Threshold」「AND」ブロックを組み合わせて利用しましたが、「Expression」ブロックを利用してモデルを構築することも可能です。

参考：モデルのエクスポート/インポート
モデルマネージャから、作成したモデルをエクスポート/インポートすることができます。今回作成したモデルは こちら からダウンロード可能です。テナントにインポートした際に、各ブロックで設定しているデバイスを変更する必要があることにご注意ください。

実践

では次に、実現したいことをもとにモデル構築を実践してみましょう。

実現したいこと

冷蔵庫内に温度センサーを取り付けて、庫内温度を監視するために以下を実現してみるとします。 温度センサーはシミュレーターで代用します。

1. 温度センサーの平均/最小/最大を計算し、新規計測値を生成する
2. 平均値が -5℃ より小さい場合、もしくは 8℃ より大きい場合、温度異常アラーム（マイナー）を生成する
3. 温度センサーの計測値を 60秒間受信していない場合、機器異常アラーム（クリティカル）を生成する

構築のヒント

• 入力元のデバイス、モデル動作のトリガーとなる入力イベントの種類（Alarm/Eventなど）は何でしょうか？
• 出力先のデバイス、出力するイベントの種類は何でしょうか？
• どのような処理が必要でしょうか？
• 新規作成する計測値のデータモデルはどのような構成にするのがいいでしょうか？

モデル構築例

モデルの構築例は以下の通りです。こちら からモデルをダウンロードできます。
※ 動作確認の際は「Missing Data」ブロックが動作するよう、シミュレーターを手動停止するか、温度シミュレーターの命令に60秒以上のsleep命令を追加してください。

参考：Block SDK を用いたカスタムブロック開発

Apama Analytics Builder Block SDK を用いて、カスタムブロックを開発し、Analytics Builder へアップロードできます。

下図はカスタムブロックとして LogOutput ブロックを Utility に追加した例です。任意のカテゴリに追加でき、任意のパラメータ、リファレンスなどを設定できます。

Block SDK のダウンロードやカスタムブロックのアップロード等の詳細については SoftwareAG/apama-analytics-builder-block-sdk（GitHub リポジトリ） をご覧ください。

例題

前提条件

• イベント処理モデルを作成するを習得していること

目次

• 例題1) アラームがクリアされた時に、メールを送信する
  • 概要
    • 例題の概要
    • シナリオ
  • 環境の準備
    • Step1: 対象デバイスへの死活監視設定
    • Step2: 対象デバイスへデータ送信
    • Step3: Alarm発生確認
  • 実践
    • モデルの作成
  • 確認
    • Step4: 発生したAlarmをクリア
    • Step5: メールが送信されることを確認
• 例題2) 温度の平均値を出力する
  • ステップ1 平均値ブロックでモデル作成
  • ステップ2 グループ統計ブロックでモデル作成
  • ステップ3 個別統計ブロックでモデル作成
  • それぞれのモデルで出力した平均値の比較
  • 平均値集約まとめ

アラームがクリアされた時に、メールを送信する

概要

例題の概要

Things Cloudのスマートルール機能では、Alarm 発生時にメールが送られる機能が用意されています。
例えばデバイスとThings Cloud間で通信途絶があった場合、デバイスでの死活監視設定及びスマートルールを使用し、Alarm発生及びメール送信を実現します。
しかし、Alarm のステータスがクリア状態となった際に、メールが送られる機能は用意されていません。
メールが送信されないと、Things Cloudを見ないと通信途絶状態が復旧したかどうかわからず、不便です。
そのため、今回はその機能を Analytics Builder を用いて実現します。
これにより、Things Cloud上からのみでなく、メールの確認によりデバイスが故障状態から復帰したことを確認できます。

本例題では、Things Cloud 上において、デバイスが故障状態から復旧した際に、メール 送信が実行される Analytics Builder のモデル作成を目標とします。

シナリオ

今回は以下のシナリオで設定していきます。Step1-4 までは Things Cloud の標準機能を用い、Step5 を Analytics Builder で実現します。

• Step1 : 対象デバイスへの死活監視設定
• Step2 : 対象デバイスへデータ送信
• Step3 : Alarm 発生確認
• Step4 : 発生した Alarm をクリア
• Step5 : メールが送信されることを確認

環境の準備

Step1: 対象デバイスへの死活監視設定

まずは、Alarm を発生させるための環境を準備します。
今回は、デバイスが故障状態となるシナリオのため、故障状態になった際の Alarm(c8y_UnavailabilityAlarm) が発生する状況を再現します。
Unavailability Alarm が発生する条件は以下です。

デバイスの 必要な間隔 へ設定されている時間以上、そのデバイスへデータ(Measurement)が送信されなかった場合

こちらの設定は 死活監視設定 と呼ばれます。
詳しくは こちら をご参照ください。

Things Cloud GUI 上において、デバイス管理画面 → デバイス → すべてのデバイス の順に遷移し、該当のデバイスを選択します。
デバイスステータス内の必要な間隔の値を、任意の値へ変更します。(ここでは1分と設定します。)

Step2: 対象デバイスへデータ送信

死活監視設定を実施したデバイスへデータ(Measurement)を送信します。
Measurement を送信した時間から、死活監視設定で設定されている時間以上データの送信がなかった場合、Unavailability Alarm が発生します。
今回は、Postman を使用し、POST API を call します。
Postman の使い方について、詳細は こちら をご参照ください。

送信するデータの内容は以下となります。

• path : {{url}}/measurement/measurements
• body

{
  "com_testMeasurement": {
    "speed": { 
      "value": 25,
      "unit": "km/h" 
    }
  },
  "time":"{{time}}",
  "source": {
    "id":"{{deviceId}}"
  },
  "type": "com_testMeasurement"
}

各変数の説明

• {{url}}: テナントのURLを指定します。 例: https://example.je1.thingscloud.ntt.com/
• {{time}}: データを作成する時間を指定します。 例: 2023-06-12T14:50:00.000+09:00
• {{deviceId}}: データを作成するデバイスのIDを指定します。 例: 207

Step3: Alarm 発生確認

Unavailability Alarm が発生する前に、デバイスの Alarm 確認画面へ遷移します。
Things Cloud GUI 上において、デバイス管理画面 → デバイス → すべてのデバイス の順に遷移し、該当のデバイスを選択します。
設定した時間待機し、GUI 上に以下のような Alarm が発生することを確認します。

実践

モデルの作成

モデルを作成していく一連の流れを考えてみましょう。今回は Unavailability Alarm の ステータスがクリア状態へ遷移した時点 が起点(入力)となりそうです。
また、出力はメールを送ることになるでしょう。メールを送るために、メールの宛先/件名/本文 の作成が必要です。
そのため、以下の流れが想定されます。

• 1. 入力ブロック作成
• 2. 出力ブロック作成
• 3. 入力と出力ブロックを接続
• 4. (オプション) メールの宛先/件名/本文 を間接的に指定する

1. 入力ブロック作成

Analytics Builder の作成ページへ遷移します。
新しいモデル ボタンを押下し、モデル名 (及び説明/タグ名) を入力します。OK ボタンを押下すると、新しいモデルが作成されます。

Unavailability Alarm の ステータスがクリア状態 となったことを検出する入力ブロックを作成します。
左側の入力タブより、対象のデバイスを選択し、ドラッグ&ドロップで右側のブロック作成画面へ移します。
対象のブロックを選択し、各値を以下のように変更します。

• ブロックタイプ : アラーム入力
• アラームタイプ : c8y_UnavailabilityAlarm
• デバイスまたはデバイスタイプ : (そのまま)
• 重大度 : 重要
• アラームステータス : クリア
• 通知モード : すべて
• タイムスタンプを無視 : (チェックを入れる)

タイムスタンプについて、詳しくは こちら をご参照ください。

2. 出力ブロック作成

左側の 出力 タブ内に存在する 電子メールの送信 ブロックを選択し、ドラッグ&ドロップで右側のブロック作成画面へ移します。
対象のブロックを選択し、各値を以下のように変更します。

• 件名 : (デバイス名)　の c8y_UnavailabilityAlarm がクリア
• 本文 : (デバイス名)　の c8y_UnavailabilityAlarm がクリアされました
• 返信先 : (設定なし)
• 終了 : (宛先メールアドレス)
• CC : (CC が必要であれば設定)
• BCC : (BCC が必要であれば設定)

3. 入力と出力ブロックを接続

入力のブロックと出力のブロックを接続します。
入力ブロックの右側の 出力ポート(アラーム) から、出力ブロック左側の 入力ポート(送信) までドラッグ&ドロップを行います。
以下のような状態になると完成となります。

ここで、Alarm がクリアされるとメールが送信されることを確認できると、モデルが正常に動作しています。

4. (オプション) メールの宛先/件名/本文 を間接的に指定する

注意
本手順はオプション手順となります。本手順を実施していない状態でも、Alarm クリア時のメール送信は確認することができます。

各値を固定値でなく(間接的に)指定するには、以下2つの方法が存在します。

• テンプレートパラメータを使用する
• テキストの代替 ブロックから、対象ブロックの入力側に存在する値のinputパラメータへ線を繋ぐ

テンプレートパラメータを使用する

テンプレートパラメータを使用する場合、まずブロックを選択し、値の入力ポップアップを表示させます。(今回は 電子メールの送信 ブロックを例とします。)
各値の入力欄左側に、ドロップダウンの入力選択蘭が存在します。こちらの値を =値 から　[x]テンプレートパラメータ へ変更すると、値の指定を直接入力からテンプレートパラメータからの入力とすることができます。

テンプレートパラメータのタイプやオプション設定を行うには、画面上部の [x] ボタンを押下し設定画面を開きます。
+新しいテンプレートパラメータ をクリックすると、テンプレートパラメータが追加できます。 ここで追加したテンプレートパラメータをブロックで使用することができます。

実行時には、対象のモデル内の インスタンス 部分を押下し、実際の値を投入します。

新しいインスタンス を押下し、必要なパラメータを入力します。稼働時には、実行モードを本稼働、ステータスをアクティブに変更します。
インスタンスエディタ について、詳しくは こちら をご参照ください。

テキストの代替 ブロックから、対象ブロックの入力側に存在する値のinputパラメータへ線を繋ぐ

こちらの方法は、テキストの代替 ブロック(及びテンプレートパラメータ)を使用した方法となります。
テキストの代替ブロックは、オブジェクト と ソース の 入力ポートが存在します。
オブジェクト は、例えば アラーム入力ブロックからの出力ポートを繋げることができます。
ソース へは、例えば管理オブジェクト入力ブロックからの出力ポートを繋げることができます。

#{source.name} や #{type} のように指定すると、変数として扱うことができ、メールの内容をデバイスやアラームの内容毎に変更することができます。
変数指定について、詳しくは こちら をご参照ください。

また、デバイスの情報を上記の変数指定でメールの本文へ記載するために、デバイス情報を入力とするブロックを作成します。
左側の入力タブより、任意のデバイスを選択し、ドラッグ&ドロップで右側のブロック作成画面へ移します。
対象のブロックを選択し、各値を以下のように変更します。テンプレートパラメータに関しては別途設定をお願いします。

• ブロックタイプ : 管理オブジェクト入力
• デバイスまたはデバイスグループ
  • [x]テンプレートパラメーター へ変更
  • テンプレートパラメータ : device
• プロパティ名 : (そのまま)
• 開始値のキャプチャ : (チェックを入れる)
  

最終的には以下のようなモデルとなれば成功です。

確認

Step4: 発生した Alarm を クリア

Alarm 確認画面で Alarm が発生したことを確認後、対象の Alarm をクリア状態へ変更します。
対象 Alarm の チェックボタン を押下することで、Alarm をクリア状態へ変更できます。

Step5: メールが送信されることを確認

Analytics Builder の 出力ブロックへ指定したメールアドレスを開き、設定した内容のメールが届いていることを確認します。

温度の平均値を出力する

本例題では、計測値データの集約した値を生成するモデルの作成と、集約ブロックの使い分けの理解を目標とします。

たとえば環境センサーで計測される温度から、ある一定期間の最高/最低気温、平均気温、あるいは平均だとバラつきがわからないから標準偏差、などデバイスから報告される計測値データから集計した値を知りたい、またはその値を使 って可視化したいという要望を簡単に実現することができます。
ここでは、温度シミュレーターを使って平均温度を生成するモデルを作成してみましょう。

集約ブロックにはいくつか種類かありますが、平均値を生成するブロックはグループ統計、個別統計、平均値(平均)の3ブロックあります。

*以降、グループ統計(緑)、個別統計(オレンジ)、平均値(平均)(水色)で表現

ステップ1

平均値(平均) ブロックを使って、1時間の温度の平均値を生成してみましょう。- Average (Mean)

• 新規モデルを任意名で作成します。

• 集約 > 平均値(平均)ブロックをエディタへドラッグアンドドロップし、下記のように設定します。

  

  参考: ウィンドウ時間(秒) とは？
  指定した秒単位で測定値データをウィンドウ内に保持する時間 です。
  ストリームを流れる特定の範囲のイベント、たとえば現在を基準とした場合には、現在からさかのぼった指定時間すべての計測値イベントを対象としウィンドウ内に保持します。今回のように3600(秒)とした場合は、現在から1時間前の範囲での平均気温を出力します。
  また、ウィンドウ内の集計データは最新のイベントにより逐次計算され、生成されます。

• 入力 > デバイス > 温度シミュレータ をエディタへドラッグアンドドロップし、下記のように設定します。

  

  参考: タイムスタンプを無視 とは？
  ブロックがデータを受信した順序で処理するかどうか です。
  Things Cloud では、デバイスからの測定値データなどには測定が実際に発生した時間がタイムスタンプで記されていますが、データを送信する際になんらか遅延が発生するなどで、ブロックがストリームを流れるイベント(データ)を順番どおりに受信しない可能性を考慮したものです。
  タイムスタンプを無視する(チェックあり)場合、イベントのタイムスタンプは無視され、ブロックがイベントを受信したときに処理するようになります。今回のように無視しない(チェックなし)場合は、受信したイベントより過去のイベントは削除されます。

• 出力 > デバイス > 温度シミュレータ をエディタへドラッグアンドドロップし、下記のように設定します。

  

• 各ブロックをワイヤーで繋げます。

  

  • 入力ブロックの値 → 平均値(平均)ブロックの値
  • 平均値(平均)ブロックの平均値 → 出力ブロックの値

平均値(平均)ブロック の 平均値

作成したモデルを「本稼働」で「アクティブ」にし、データポイントグラフで出力したデバイスの平均値を観察してみましょう。

なんらか値が出力されました。値については後に解説します。

ステップ2

グループ統計 ブロック を使って、温度の平均値を生成してみましょう。- Group Statistics

• 新規モデルを任意名で作成します。

• 集約 > グループ統計ブロック をエディタへドラッグアンドドロップし、下記のように設定します。

  

• 入出力ブロックは、ステップ1と同じにします(下記は変更)。

  • 出力 > フラグメント名: c8y_AverageTemperature2

• 各ブロックをワイヤーで繋げます。

  

  • 入力ブロックの値 → 個別統計ブロックの値
  • グループ統計ブロックの平均値 → 出力ブロックの値

ランタイムエラー

作成したモデルを「本稼働」で「アクティブ」にしてみましょう。ランタイムエラーが発生しアクティブにできません。

グループ統計は、グループ内のすべてのデバイスで定期的な集約値を生成するブロックであり、入力は デバイスグループ を指定する必要があります。

• 入力ブロックの 「デバイスまたはデバイスグループ」をデバイスではなく、「analytics-builder」というデバイスグループに変更します。「analytics-builder」デバイスグループには、既出の温度シミュレーターと、同じフラグメントタイプシリーズで温度20.0℃の計測値データのみ生成し続けるシミュレーターの2つを所属させます。

  

再び、作成したモデルを「本稼働」で「アクティブ」にしてみましょう。ランタイムエラーが消えません。メッセージ内容が前回と変わっています。

ランタイムエラーの詳細は、「ランタイムエラー」をクリックして内容を確認することも可能です。

グループ統計は、ブロードキャスト、つまり同じデバイスグループに設定されているすべてのデバイスに集計データを生成するモデルであるため、出力にも デバイスグループ を指定する必要があります。

• 出力ブロックの「デバイスまたはトリガーデバイス」を トリガーデバイス に変更します。

  

  参考: トリガーデバイス とは？
  デバイスグループからのデータが入力の場合は、出力ブロックに特別なデバイスである トリガーデバイス を指定する必要があります。
  トリガーデバイスは、今回のようにデバイスグループ内のすべてのデバイスにわたって集計した値を出力する場合や、 デバイスグループ内の集約モデルのトリガーとなるデバイス、つまり入力のデバイスそれぞれに集計した値を出力する場合に、集計モデルのインスタンスが適用される元となるデバイス、またはそのインスタンスをトリガーするためにデータを送信したデバイスデータを生成します。

グループ統計ブロック の 平均値

作成したモデルを「本稼働」で「アクティブ」にし、データポイントグラフで出力したデバイスの平均値を観察してみましょう。

なんらか値が出力されました。値については後に解説します。

ステップ3

個別統計 ブロック を使って、毎時0分にリセットされる平均値を生成してみましょう。- Discrete Statistics

• 新規モデルを任意名で作成します。

• 集約 > 個別統計ブロック をエディタへドラッグアンドドロップします。

  

• ユーティリティ > Cron Timer をエディタへドラッグアンドドロップし、毎時0分の1時間ごとに起動する設定をします。

  

  参考: リセット とは？
  集計しているデータの状態をリセットします。
  何らかのイベント、たとえば、Cron のような定期タイマーで特定の時刻に信号をトリガーすることで、集計データをリセットすることもできます。
  

• 入出力ブロックは、ステップ2と同じデバイスグループにします(下記は変更)。

  • 出力
    • フラグメント名: c8y_AverageTemperature3
      
      

• 各ブロックをワイヤーで繋げます。

  

  • 入力ブロックの値 → 個別統計ブロックの値
  • Cron Timerブロックのタイマー → 個別統計ブロックのリセット
  • 個別統計ブロックの平均値 → 出力ブロックの値

個別統計の平均値

作成したモデルを「本稼働」で「アクティブ」にし、データポイントグラフで出力したデバイスの平均値を観察してみましょう。

なんらか値が出力されました。値については後に解説します。

平均値の比較

これまでに作成したモデルごとに生成した平均値を比較してみましょう。

今回は5秒間隔で -10℃ - 10℃ の 温度が計測される温度シミュレーターを入力としたため、時間が経過すると平均値ブロックと個別統計ブロックの平均値はおおよそ0℃となり、グループ統計ブロックは10℃の一定温度の複数デバイスにわたった平均値のため おおよそ10℃となります。
また、個別統計ブロックには毎時0分の1時間ごとに集約データをリセットするため 15:00に値がリセットされます。

モデル起動時には、ストリームにデータが蓄積されていないため、下記のような値になります。
*出力値には端数がありますが、一部省略しています。

以下のように平均値にはそれぞれ違う計算/出力が行われます。

• ステップ1 平均値は、時間を考慮した累積値を時間を考慮した累積数で除算した値
  • #5の平均値の計算: 00:27-00:47までの20秒間の平均値
  • 2.021 ≒ (-1.045 * 5(秒間) + 1.045 * 5(秒間) + 3.090 * 5(秒間) + 5.00 * 5(秒間)) / 20(秒間)
• ステップ2 グループ統計は、グループすべての入力の累積値を計測データ数で除算した値
  • #5の平均値の計算: 00:27-00:47までの20秒間の平均値
  • 11.191 ≒ (10.714 + ((6.691 + 20.0) / 2)) / 2
• ステップ3 個別統計は、計測値を加算し計測データ数で除算した値
  • #5の平均値の計算: #4の直近の入力値と現在の入力値を2で除算
  • 5.845 ≒ (5.000 + 6.691) / 2

詳しくは、 On-change inputs and time windows または、Discrete-time measurements をご覧ください。

集約ブロック まとめ

集約ブロックは、入力となるデータの特性によって使いわけが必要です。
定期、あるいは温度が変化した場合にのみ測定値を生成するような不定期な温度センサーなど、 連続するデータ を入力とする場合には、時間の経過に伴う値を計算するために平均値ブロックを利用します。このブロックは、入力データ間の時間が重要であり、データの数は重要ではありません。
その一方で、会議室やトイレなど人を検知したときに測定値を生成する人感センサーなど、 独立したデータ を入力とする場合には、時間に関係ない値を計算するために個別統計ブロックやグループ統計ブロックを利用します。このブロックは、入力データの数が重要であり、データ間の時間は重要ではありません。

リファレンス

目次

• インスタンス作成機能
• 便利なブロック
  • KPI
  • 式
  • インテグラル
  • ラッチ

インスタンス作成機能

「他のデバイスでも同じモデルを適用したい。ただし、モデルに設定した閾値やデータポイントはデバイス固有のものにしたい。」といったシーンが出てくることもあると思います。この課題は、これから紹介するインスタンス作成機能を活用することで解決できます。

Analytics Builder では、分析モデルを設計図のようなものとして、設計図を元に異なるパラメーターを持った複数のインスタンスを作成できます。具体的には、以下のようなシナリオを実現できます。この場合、「アラーム時に電子メールを送信」モデルを設計図として、デバイスA, Bそれぞれに対応するインスタンスを作成することになります。

• 分析モデル「アラーム時に電子メールを送信」を使用して：
  • デバイスAでは、クリティカルアラーム（type: com_CriticalAlarm）が作成された際にメールを送信したい
  • デバイスBでは、メジャーアラーム（type: com_MajorAlarm）が作成された際にメールを送信したい

インスタンス作成機能の使い方

ここからは、サンプルモデルの「アラーム時に電子メールを送信」を例に説明していきます。

ブロックのテンプレートパラメーターを設定

まずは、モデルの各ブロックの「パラメーター」のうち、可変の値が入るものについては、パラメーター設定項目の左プルダウンから [x] タイプを選択します。この可変の値が入るパラメーターのことを テンプレートパラメーター と呼びます。

右プルダウンには、テンプレートパラメーターの名前を設定します。サンプルモデルはすでに「Device or device group」というパラメーター名が設定されていますが、任意のものを設定できます。右プルダウンに直接入力して設定するか、画面右上のツールボタンからも設定可能です。

ツールボタンをクリックすると下記の画面が表示されます。既存のテンプレートパラメーターの修正や新規テンプレートパラメーターを追加できます。今回はサンプルモデルで設定されていた「Device or device group」から「デバイス」という名前に変更してみました。

この状態で一度モデルを保存します。

テンプレートパラメーターには一例として、下記のようなタイプ（値の型）を設定できます。

• 基本的な値型
  • boolean
  • string
  • float
  • integer
• Things Cloud特有の型
  • デバイスまたはデバイスグループ
  • フラグメントおよびシリーズ
  • ジオフェンス
  • Alarm の重大度やステータス
• ブロック特有の型
  • 「パルス」ブロックのモード（入力時、値変更時など）
  • 「しきい値」ブロックの方向（上、下、超過など）

インスタンスエディタからインスタンスを作る

モデル一覧画面に移動すると、モデルに「0インスタンス」という表示が追加されています。モデルでテンプレートパラメーターを利用している場合に表示されます。「0インスタンス」をクリックして、インスタンス作成画面を開きます。

冒頭のシナリオは下記のように設定できます。

• 分析モデル「アラーム時に電子メールを送信」を使用して：
  • デバイスAでは、クリティカルアラーム（type: com_CriticalAlarm）が作成された際にメールを送信したい
  • デバイスBでは、メジャーアラーム（type: com_MajorAlarm）が作成された際にメールを送信したい

これでインスタンス作成機能の紹介は終了です。 インスタンス作成機能を組み合わせることでモデル開発の幅を一気に広げられます。 その他の詳細な使い方は Using the Instance Editor をご覧ください。

便利なブロック紹介

ここでは、Annlytics Builder でモデルを作る際に利用できるブロックをいくつかご紹介します。

KPI

「計算」カテゴリに存在するKPIブロックは、データポイントもしくは c8y_Kpi プロパティを持つ ManagedObject に設定された黄色/赤色範囲を読み込み、 入力された数値がどちらの範囲内に存在するのかを判定できます。

用途

次のような用途が考えられます。

• データポイントライブラリに設定したデータポイントを基に、黄色範囲・赤色範囲ごとに異なる設定を施す
  • 値が黄色範囲内の場合：マイナーアラームを生成する
  • 値が赤色範囲の場合：クリティカルアラームを生成する

ブロック

ブロックの入出力項目には、以下があります。

入力ポート

出力ポート

パラメーター

全ての設定パラメータにおいてテンプレートパラメータを設定可能です。

ブロック設定例

本項では、下記を実現するモデル例を用いて設定内容を説明します。

• 黄色範囲の温度計測値を観測した場合、マイナーアラーム com_YellowAlarm を生成
• 赤色範囲の温度計測値を観測した場合、クリティカルアラーム com_RedAlarm を生成

データポイントの設定

まず、コックピットからデータポイントを設定します。 「コックピット > 構成 > データポイントライブラリ」から、任意のデータポイントを設定してください。 ここで設定する注意範囲、障害範囲がKPIブロックの黄色・赤色と対応します。

データポイント設定の詳細は コックピット > データポイントライブラリ をご覧ください。

参考：データポイントには下記の c8y_Kpi 配下のプロパティが含まれており、これが黄色/赤色範囲の判定元になります。

    {
        "creationTime": "2020-05-07T14:05:19.656+09:00",
        "lastUpdated": "2023-06-19T08:22:02.078Z",
        "id": "8477750",
        ...
        "c8y_Kpi": {
            "redRangeMax": 30,
            "fragment": "c8y_TemperatureMeasurement",
            "unit": "C",
            "min": -20,
            "color": "#f5e38f",
            "max": 60,
            "series": "T",
            "label": "温度",
            "yellowRangeMax": 18,
            "yellowRangeMin": 10,
            "redRangeMin": 18
        }
    }

入力

次に、入力となるブロックを2つ配置します。今回はデバイスにシミュレータを使います。

KPIブロックの「値」ポートに接続する入力ブロック	KPIブロックの「KPI」ポートに接続する入力ブロック
「フラグメントおよびシリーズ」から、 作成したデータポイントを設定します	「デバイスまたはデバイスグループ」から、 作成したデータポイントもしくは ManagedObjectの名前を設定します

処理と出力

処理ブロック KPI	出力ブロック 任意のデバイス/グループ
黄色範囲内の場合は com_YellowAlarm を生成、 値が赤色範囲内の場合は com_RedAlarm を生成するため、 黄/赤色ポートをそれぞれアラームを生成させたいブロックに繋ぎます	KPIブロックの出力を各アラーム出力ブロック の最上部「アラームの作成」入力ポートに繋ぎ、 生成したいアラームの内容を設定します

アラーム生成の確認

シミュレータを起動し「本稼働」モードで動作させると、データポイントで設定した注意・障害範囲に応じて com_YellowAlarm と com_RedAlarm が生成されることを確認できます。

定義した範囲外に値が遷移した場合にアラームをクリアしたい場合は、サンプルモデルの「測定のしきい値の場合、アラームを作成」を参考にしてみてください。

式

「計算」カテゴリに存在する式ブロックは、入力値を元に任意の演算を実行し、演算結果を出力できます。様々な式を自由記述で設定できるため、柔軟性が高く便利なブロックです。

用途

次のような用途が考えられます。

• センサー値を使った演算
• ManagedObjectの特定のプロパティ値を結合する文字列操作
• 他の処理ブロックの出力を使った演算処理

ブロック

ブロックの入出力項目には、以下があります。

入力ポート

出力ポート

パラメーター

テンプレートパラメータを設定可能です。

ブロック設定例

本項では、下記を実現するモデル例を用いて設定内容を説明します。

• 温度が25度を超えた場合、かつ湿度が70%を超えた場合、閾値超過のメジャーアラームを作成する

ブロックの詳細

次に、各ブロックを配置します。今回はデバイスにシミュレータを使います。

入力ブロック	処理ブロック	出力ブロック
温度センサーと湿度センサーの 計測値を指定します	「式」パラメーターに式を入力します input1 > 25 and input2 > 70| 出力したいアラームの内容を設定します

本稼働モードでモデルの動作を確認すると、com_ThresholdAlarm タイプを持ったメジャーアラームの発生を確認できます。

インテグラル

インテグラルブロックは、時間にわたる総和を計算するのに使えるブロックです。 数学的な表現を使うと、入力値に対する時間積分を計算します。

用途

次のような用途が考えられます。

• 消費電力(W)情報から消費電力量(kWh)を求める
• 速度(m/s)情報から移動距離(m)を求める
• 流量(m3/s)情報から体積(積算流量)(m3)を求める

ブロック

ブロックの入出力項目には、以下があります。

入力ポート

出力ポート

パラメーター

ブロック設定例

左のブロック(入力デバイス)の設定内容です。デバイスの出力するメジャーメントを指定しています。

中央のインテグラルブロックは特別な設定を行っていません。

右のブロック(出力デバイス)の設定内容です。値を同じデバイスの別のデータポイント(系列)を指定しています。

入力デバイス設定

入力デバイスはシミュレーターとしています。 以下のようなデータを繰り返し出力するように設定しています。 どのような計算かの説明のため、「7」を出力した後だけ 10 秒待ちとしました。

出力デバイス設定

出力デバイスは同じシミュレーターで、別の系列のデータ(com_TestSum.SV)を生成するようにしました。

出力結果

結果は以下のようになりました。入力(上段)は周期的な値で、出力(下段)は右肩上がりになっています。

出力値には端数がありますが、一部省略しています。

計算ロジック

以下のような計算/出力が行われます。

• 出力タイミングは入力タイミングと同じ
• モデル開始時点の値は 0
• 入力値到着ごとに (入力値)×(経過時間(秒)) を算出し、開始時点から累積加算
  • 時刻 0:05: (1 × 5秒) + (2 × 0 秒) = 5
  • 時刻 0:10: (1 × 5秒) + (2 × 5 秒) + (5 × 0 秒) = 15
  • 時刻 0:15: (1 × 5秒) + (2 × 5 秒) + (5 × 5 秒) + (7 × 0秒) = 40
  • 時刻 0:25: (1 × 5秒) + (2 × 5 秒) + (5 × 5 秒) + (7 × 10秒) + (1 × 0秒) = 110
  • : (以下略)
  • ※ 出力値の端数は入力値到着時刻の微小なずれに起因

入力

リセット

• 「リセット」にイベントが到着すると、それまで累積加算されていた値が 0 になります。
• 出力結果 の例で、0:05 ぴったりの時点で「リセット」にイベントが入力された場合、以下のようになります。
  • 0:05 出力値 0
  • 0:10 出力値 10
  • 0:15 出力値 35
  • :

サンプル

• 「サンプル」にイベントが到着すると、その時点で累積加算値が計算され、出力されます。
• 出力結果 の例で、0:07 の時点で「サンプル」にイベントが入力された場合、以下のようになります。
  • 0:05 出力値 0
  • 0:07 出力値 2 (= 1 × 2秒) 「サンプル」入力により出力された値
  • 0:10 出力値 10
  • 0:15 出力値 35
  • :

パラメータ

ウィンドウ期間(秒) - オプション

• この値を設定した場合(w(秒) とします)、出力値は出力時から w 秒さかのぼったタイミングからの累積値となります。

出力しきい値 - オプション

• この値を設定した場合(t とします)、累積値が t 変化したタイミングごとに出力され、他のタイミングでは出力されません。

ラッチ

ラッチブロックは、有効である間の最後の値(数値以外でも大丈夫です)を保持し続けるブロックです。 また、値変化検出機能も持っています。

用途

次のような用途が考えられます。

• 計測値や状態変化が起こったときのみイベントを発生させる
• 不規則なタイミングの計測値を一定間隔ごとに変換

ブロック

ブロックの入出力項目には、以下があります。

入力ポート

出力ポート

パラメーター

パラメーターはありません。

ブロック設定例

左のブロック(入力デバイス)の設定内容です。デバイスの出力するメジャーメントを指定しています。 シミュレーターで「値」「有効化」入力のタイミングを合わせるため、同一シミュレーターの異なる系列を指定しています。

右のブロック(出力デバイス)の設定内容です。右の４出力に対して同様の設定を行っていますが、同様なのでそのうち１つだけを示します。

入力デバイス設定

入力デバイスはシミュレーターとしています。 以下のようなデータを繰り返し出力するように設定しています。

出力デバイス設定

出力デバイスは同じシミュレーターで、出力と同名のテキストを持つイベント(ラッチ値/変更済み/有効化/無効)を生成させています。

出力結果

結果は以下のようになりました。イベントリストなので、逆順(古いものが下、新しいものが上)になっています。

時系列的には下から上の順になっています。下から #9→#8→#7→ の順に見るとわかりやすいと思います。

入力

有効化

boolean で指定しますが、以下のように暗黙的に変換が行われます。

• pulse: 発生時のみ true, それ以外 false
• boolean: 変換無し
• float: 0 → false, 0 以外 → true
• string: 空文字 → false, 空文字以外 → true
• any: 空や0 → false, それ以外 → true