MQTTとMessagePub+ :ラベル（MessagePub+ ）

MessagePub+ では、特徴をラベルで表現できる

MessagePub+ には、ラベル機能と呼ばれる、トピックにタグ付けする機能があります。例えば、Rv1.0/N/Bldg01/04/Meeting1/Aircon/1/RoomTempというトピックに着目してみます。これは、ビル1の4階のエアコン1の室温を意味します。このトピックの特徴から、ラベルを抽出してみます。

6664_1.png
  • ルール
    • Rv1.0
  • 種別
    • Notify or Request
  • ビル1
    • Blgd1
  • 4階
    • Floor4
  • 部屋種別
    • MeetingRoom
  • 部屋番号
    • Room1
  • エアコン
    • Aircon
  • デバイス番号
    • Device1
  • 室温
    • RoomTemp

9つのラベルが抽出されました。これら全てを、トピックRv1.0/N/Bldg01/04/Meeting1/Aircon/1/RoomTempに関連付けます。関連付けを行った上で、当該トピックをラベルで指定するためには、Rv1.0&Notify&Bldg1&Floor4&MeetingRoom&Room1&Aircon&Device1&RoomTempと、各ラベルを&で繋いで指定します。このような表現をラベル式と呼びます。ラベル式は最終的にMQTTのトピックとして、$SYS/label/というプレフィックスが付与され、$SYS/label/Rv1.0&Notify&Bldg1&Floor4&MeetingRoom&Room1&Aircon&Device1&RoomTempと展開されます。MessagePub+ SDKを利用している場合は、プレフィックスを意識する必要はありません。一般のMQTTクライアントソフトウェアを利用している場合は、このプレフィックスを付与することで、MessagePub+ ブローカに、以降の文字列がラベル式であるということを伝えます。なお、ラベル式は、論理式と同様の記述が可能で、

  • 論理積 &
  • 論理和|
  • 否定 !

    • という演算子を使うことができます。さらに、演算の優先度を指定する（と）を使うことができます。

    ワイルドカードがMQTTの規格上、サブスクライブにしか適用できないのに対して、ラベル式は、サブスクライブだけではなくパブリッシュにも適用することができます。

    例えば、以下の要求系トピックがあるとします。

    6664_2.png

    エアコンと照明の全ての電源をOFFする、といった場合、Rv1.0&Request&Bldg1&Floor4&MeetingRoom&Room1&（Aircon|Light）&Powerというラベル式でトピックを絞り込み、OFFといったメッセージを送ることができます。同じ階層に存在するTvは、対象から外すことができるのです。

    ラベルは後から拡張できる

    トピックは、あらかじめ注意深く階層を決めておく必要がありましたが、ラベルは後からの追加、削除、変更が比較的容易です。例えば、スマートビルにおいて、現在対象となっているビルはひとつだけで、将来複数のビルに展開するかもしれない、という状況を考えてみます。この段階では、Bldg1というラベルは不要です。例えば、Request&Aircon&Powerと指定すれば、ルール、ビル、階数、部屋を問わず、全てのエアコンの電源の制御要求トピックが対象となります。

    ラベルは動的に変更できる

    トピックとラベルの関連付けは動的に変更することができます。例えば、メンテナンス中（maintaining）というラベルを準備しておき、機器のメンテナンスを開始する時に、その危機に対応するトピックに、メンテナンス中ラベルを関連付けておきます。機器に制御指示を出す時、Floor4&!maintainingというラベル式でパブリッシュすることで、4階のメンテナンス中の機器を除く全ての機器に指示を送ることができます。

    ラベルに対するサブスクライブ

    ここまで、ラベルの活用方法についてご紹介しましたが、実はこれらは、ラベルに対するパブリッシュに焦点を当てたものでした。では、ラベルに対するサブスクライブはどのように行うのでしょうか。

    6664_3.png

    降雨センサー（雨量計）を例に考えてみます。まず、地域一帯に降雨センサーが設置されており、それぞれが、対応したトピックに雨量をパブリッシュするとします。図の降雨というアイコンがセンサーに対応するトピックで実際はRain001, Rain002などのセンサーIDを持っているとします。このうち、畑などの農耕地周辺のセンサーには、「農業」というラベルを関連付けます。このラベルには、土壌センサートピックなど農業に関係するトピックを関連付けておきます。そうすれば、ラベル「農業」を指定してサブスクライブすることで、一度に農業関連トピック群をサブスクライブすることができます。同様に土砂災害を予測するために、山や崖周辺の降雨センサーに対応するトピック群に「防災」というラベルを関連付けます。その他震度、風向、風量センサーなどのトピックも「防災」ラベルに関連付けておき、「防災」ラベルをサブスクライブすることで、一度に防災関連トピック群をサブスクライブすることができます。

    メリット

    ラベルに対するサブスクライブのメリットは、例に示したようなグルーピングや、特にワイルドカードでは難しい、階層を超えてグルーピングしたトピック群を一括してサブスクライブできる点にあるといえます。センサーの追加、削除があった場合、トピックとラベルの関連付けだけメンテナンスすれば、アプリケーションには影響がありません。結果としてIoTアプリケーションのメンテナンス性向上に繋がります。

    注意点と解決策

    ラベルに対するサブスクライブには注意点もあります。それは、図の「農業」ラベルと「防災」ラベル、両方にひとつのトピックが関連付けられる時の取り扱いです。例えば、雨量の平均値を求める処理を考えてみます。「農業」ラベルと、「防災」ラベルでサブスクライブしたトピックには随時、それぞれの箇所の雨量がパブリッシュされます。農業アプリと防災アプリが、それぞれ別のMessagePub+クライアント（あるいはMQTTクライアント）を準備し、それぞれが「農業」ラベルと「防災」ラベルでサブスクライブする場合は、特に注意することはありません。しかし、もしこれら「農業」と「防災」が、ひとつのアプリに集約され、ひとつのMessagePub+クライアントとして「農業」ラベルと「防災」ラベルの両方をサブスクライブする場合は注意が必要です

    MQTTのPUBLISHパケットの仕様上、通知されるメッセージには、トピック名と雨量（Payload）は含まれますが「農業」「防災」といったラベル情報は含まれません。ですから、両方のラベルに関連付けられたトピック名を持つメッセージを受信した場合、「農業」「防災」どちらに対応するメッセージか区別しなければなりません。これらの区別には、Subscription Identifierプロパティを使うと良いでしょう。

    6664_4.png

    Subscription Identifierプロパティは、サブスクライブを区別する仕組みで、数値を設定します。例えば、「農業」ラベルでサブスクライブする時にSubscription Identifier:1というプロパティを設定します。次に、「防災」ラベルでサブスクライブする時にSubscription Identifier:2というプロパティを設定します。こうしておけば降雨センサーが雨量情報をパブリッシュした時、MessagePub+ ブローカがサブスクライブに応じたSubscription Identifierプロパティを追加して、PUBLISHパケットを配信します。アプリケーションは配信されたPUBLISHパケットを確認し、Subscription Identifierが1なら「農業」、2なら「防災」と処理を振り分け、それぞれに平均値を求めるなどの処理を行うことができます。「農業」ラベルと「防災」ラベルの両方に関連付けられたトピックにメッセージがパブリッシュされた場合は、Subscription Identifier:1とSubscription Identifier:2の、2つのパブリッシュメッセージがMessagePub+ ブローカから配信されるので、正しく値の計算を行うことができます。

    ラベルに関連付けられたトピックが、複数ラベル間で重複する場合、Subscription Identifierプロパティを使うことで、適切に取り扱うことができます。

    ラベルを用いたIoTシステムの設計

    ラベルを用いてパブリッシュ/サブスクライブすることで、IoTデバイスの詳細と、IoTアプリケーションを切り離すことができます。IoTデバイスは、トピックに対してパブリッシュ/サブスクライブを行います。IoTアプリケーションは、トピックの代わりにラベルに対してパブリッシュ/サブスクライブを行います。

    6664_5.png

    ラベルはアプリケーションの目的やビジネスロジックに応じて、適切に特徴付け、グルーピングを行う形でトピックと関連付けておきます。そして、IoTアプリケーションはトピックを直接意識するのではなく、ラベルのみを意識する形で設計します。これは、インターフェースと実装の分離にも通じる、抽象化の一種といえます。この抽象化により、IoTアプリケーションは、実装すなわちIoTデバイスの追加、削除、変更の影響を受けなくなります。

    MQTTとMessagePub+

    ・MQTTとMessagePub+ 目次に戻る

    ※この記事に掲載されている内容、および製品仕様、所属情報（会社名・部署名）は公開当時のものです。予告なく変更される場合がありますので、あらかじめご了承ください。

関連サービス

関連記事一覧