Iotに時代には様々なデバイス・センサーをインタネットに接続することで人、もの、環境からデータを収集し分析、サービスを生まれます。インタネットの基本であるプロトコルはTCP/IPであり、そしてMQTTはMessage Queue Telemetry Transportという、TCP/IPベースから作られた標準のプロトコルの1つです。
MQTTは1990年代IBMが開発されたプロトコルで最初は油田のパイプラインに取り付けされてるセンサーを衛星に送信するために使用されました。
でも、なんでMQTTを選んだでしょうか？Iotの開発者はMQTTの特徴と相性が合うという理由で採用されたことが多いのようです。つまり、
- 軽量
- ネットワーク不安定な場所でも使える
- 柔軟性、様々なIoTデバイスにもサポート可能
じゃ、他のネットワークプロトコルはIotに向かないですか？
IoTのデバイスをそのままWebサービスに接続すればよいと思うかもしれないけど、Webサービスに接続すると色々な約束ことがありますね。例えば、
- 同期プロトコルです。つまりClientは常にServerの返事を常に待っています。IoTではデバイス・センサーはネットワークが不安定な場所に設置されることが多く、待ち時間が長くなりますね。でもMQTTは非同期通信なので、データをセンサーから送ったあと、QnSの設定で届くのタイミングなどをネットワークの質に任せることができます。
- HTTPは色々なHeaderを挟んで送る思いプロトコルです。先も言いましたが、ネットワーク不安定な場所に向いてません。
などなど…そこでMQTTが採用されました。MQTTは簡単に言えば、一回接続すればその後送るのはデータだけになります。
ではこれから簡単でMQTTの仕組みを説明します。まず下図をみてください。いくつの単語が出てきます。
Broker
Serverだと思ってください。メッセージを受けたり送ったりの中継役です。
Publish
データを送信する。
Publisher
データの送信者。
Subscribe
データを受信する。
Subscriber
データの受信者。
ここで特徴なのはPublisherはMQTT Serverへデータを送るときそのデータがどこのSubscriberに届くになるか、何台に届くのか一切しりません。
当然、SubscriberにもこのデータがどこのはPublisherからデータきたかもうしりません。
つまり流れはこうです：
まず事前SubscriberがMQTT Serverどんなデータほしいかを登録します。
その登録はSubscribeです。
そしてPublisherがデータをPublishするときServerが自動的にSubscriberにデータを送ります。
次は送るデータについてみてみます。先Subscriberが事前Brokerにほしいデータを登録する必要があると言いましたが、その欲しいデータはの場所？名前？はどう分別するでしょうか。そこに出てくるのはTopicです。Topicの構造は/で分かれいます。
下図に見えれば解ると思いますが、ほしいデータの場所は”Topic”という、その値は”Message”と言います。PublisherがこのTopicとMessageをBorkerに送ります。
つまりこのような構造になりますね。
構造には＋の文字使えます。＋を使うとこの構造は全部取ります。
Subscriber-AがStation/+/Unit1/TempのTopicをSubscribeすると、
Station/01/Unit1/Temp、Station/02/Unit1/Temp、Station/03/Unit1/TempがPublishされたらそのSubscriber-AがMessageをもらえます。
構造には#の文字にも使えます。#を使うとこの構造は全部取ります。
Subscriber-AがStation/01/#のTopicをSubscribeすると、
Station/01/Unit1/Temp、Station/01/Unit3/Speed、Station/03/Unit1/TempがPublishされたらそのSubscriber-AがMessageをもらえます。
説明はだいたいこれくらいですね。
Brokerのセットアップ・Siemens S7-1500とつながりなどの操作の公開していますのでもし必要であれば参考してくださいね。
お疲れ様です。ー