【情報・生産技術部】

IoT におけるデータ取得手段と通信方式の選択について
水矢 亨，長尾 達明，奥田 誠（情報・生産技術部システム技術グループ）

中島 岳彦（情報・生産技術部試作加工グループ）

佐々 知栄子（情報・生産技術部 デザイン・設計グループ）

１．

はじめにIoT（モノのインターネット）やインダストリー 4.0（第非 IP 通信的手段、非通信的手段の 3 通りに分類することができる。なお、“取得手段なし”という場合は、基本的四次産業革命）では、サービスやものづくり等のライフサイクル全体において、ICT（情報通信技術）活用による最に IoT への対応は不可であるため、ここでの検討対象とはしないこととする。先の 3 つのデータ取得手段に関して、適化や高度化が期待されている(1)。当初はモノをネットワークに接続する部分や、データ収集の部分に興味が集中す

IoT 対応に必要な条件は、次のようになる。
[1] IP 通信的手段： IP 通信用のインターフェースがある傾向があったが、最近は IoT 本来の目的であるデータ活用に関心が移りつつある。AI（人工知能）に対する社会的り、データ取得用の IP 通信方式（プロトコル）が開示されていれば、その機器やデバイスは、IP 通信による IoT 対関心が大きくなる中、様々なデータを収集し、そのデータに対して AI による分析や判断・制御を行うことへの期待応が可能である。
[2] 非 IP 通信的手段：シリアル通信や USB などが、こが高まっている(2)。
その一方で、IoT を導入するには IP(インターネットプ

こでの非 IP 通信に該当する。非 IP 通信用のインターフェースがあり、データ取得用の通信プロトコルが開示されてロトコル)通信ネットワークやサーバなど ICT 分野の知識が必要であり、身近な環境で IoT を試してみることも必ずいれば、その機器やデバイスからのデータ取得は可能である。ただし、 IoT 対応するためには、 IP 通信ネットワー

しも容易ではない。さらに、IoT に対応させたい機器やデバイスのネットワーク対応状況に応じて IoT の実現手段

クへのデータ送信するためのゲートウェイを別に確保する必要がある。

を選択する必要があることも IoT を始める際の課題となっている。実際、通信用インターフェースの有無、利用可[3] 非通信的手段：データ通信以外の手段で電圧や光などの信号を物理的に取得する。機器に設置された三色灯か能な通信手段等の条件は、機器やデバイスごとに異なっていることが多い。

ら光（或いは色）の信号を取得できる場合(3)が、その一例である。このような場合に IoT へ対応をするには、取得可

そこで、IoT 導入において課題となりうる点を予め抽出しておき、それらに対する検討手順を設けておくことが、能な物理信号に応じたセンサや、そのセンサデータを IP通信ネットワークに送信するためのゲートウェイが必要

IoT 導入のハードルを下げることにつながると考えられる。
本研究では、機器やデバイスからのデータ取得手段や、IPとなる。
以上のように、機器やデバイスの IoT 対応にあたっては、通信プロトコルの選択等における考え方と具体的な候補について示し、実際のシステム構築での適用事例と合わせ〇 通信によるデータ取得〇 物理的信号の取得て報告する。

〇 ゲートウェイによる IP ネットワークへの中継の３点について確認・検討することが重要であり、IoT 対２．

応に必要な条件をまとめると表 1 のようになる。

機器やデバイスの IoT 対応

IoT では、データを“集め”、IP ネットワーク上での通信によりデータを“運び”、必要に応じてデータを“使う”という 3 つの段階が基本的である。それらを実現する上で表 1．機器やデバイスのデータ取得手段と IoT 対応の条件

は、データの供給源となる“モノ”（機器やデバイス）、“モノ”をネットワークに接続するための通信インターフェー

データ取得手段IP 通信

ス／ゲートウェイ（中継機器）、データ処理を行うためのサーバが基本的な構成要素である。

非 IP 通信IoT を導入／試す際、最初に必要となるのは、機器やデバイスからのデータ取得手段について確認して、IP 通信ネその他（非通信）ットワークへの接続の方法を決めることである。機器やデバイスからのデータ取得手段については、IP 通信的手段、

KISTEC研究報告（2018） 2018.1030IoT 対応に必要な条件
・IP 通信インターフェース
・通信プロトコルの開示
・非 IP 通信インターフェース
・通信プロトコルの開示
・(IP 通信との)ゲートウェイ
・信号を扱うセンサ
・(IP 通信との)ゲートウェイ【情報・生産技術部】

３．

ゲートウェイの選定

４．

IP ネットワーク上の通信方式の選択

既存の機器やデバイスにおいて、IP 通信でのデータ取得に対応しているものは必ずしも多くはない。そのため、先に述べたように、IoT では、IP ネットワーク上での通信によりデータを“運ぶ”ことが必要である。この部分でデータを IP 通信ネットワークへ中継するゲートウェイが必要となることも多く（表１の「非 IP 通信」と「非通信」

は、利用する IP 通信のプロトコルを検討・選択する必要がある。の場合が該当）、ゲートウェイの選定や用意が IoT 対応の成否において重要となる場合も多い。

まず、利用する IP ネットワーク環境において通信プロトコルに対する制約や要求事項があるかどうか確認する

ゲートウェイについては、機器やデバイスからのデータ受信、センサ等の信号からデータへの変換、および IP 通必要がある。特に、ファイアウォールを介して、インターネット等の外部ネットワークに接続している環境では注信ネットワークへのデータ（中継）送信等の機能が必要となる。そのたゲートウェイは、必要な通信機能をもつハー意が必要である。ファイアウォールが介在していても、Web で用いられる HTTP 通信は許可されていることが多ドウェアとそれらを制御するためのソフトウェアから構成されるのが一般的であり、既製品の選定だけでは不十分い。その場合は、HTTP 通信が有力な候補となる。また、
既 存 の 制 御 機 器 等 と の 通 信 が 必 要 で あ れ ば 、 Modbus

で個別の案件に応じた開発が必要な場合もある。
ゲートウェイの選定においては、次のような事項を検討

TCP/IP(8)の利用が有力である。
データの授受が 1:1（1 対 1）、1: n（1 対多）或いは n : mする必要がある。
〇 IP 通信の機能・性能（多対多）のいずれか、という観点も重要である。1 対 1のデータ授受については、サーバ／クライアント方式のプ〇〇ロトコルを用いればよいが、多対多の場合は MQTT のよ
うな Pub/Sub 型のメッセージング通信が適している。

対象の機器やデバイスとの接続性必要な（IP および非 IP）通信方式のサポート

これらのうち、機器やデバイスとの接続性については、（デジタル IO やアナログ IO を含む）GPIO、シリアル通

さらに、通信品質やセキュリティに対する要求がある場
合は、それに応じたプロトコルを検討する必要がある。例信、I2C 通信、USB 等での接続のサポートが望まれる。また、できるだけ多くの通信方式をサポートすることも望ま

えば、QoS（Quality of Service）に対する要求がある場合、先にあげた MQTT では、QoS を確保するための仕組みとれるため、内部の制御ソフトウェアを必要に応じて柔軟に追加・書換え可能なものは有力な選択肢である。以上をふして、Subscriber への配信が最大 1 回の QoS0（届かない可能性あり）、最低 1 回は配信される QoS1（複数回届く可能

まえると、イーサネットポートを持つボードコンピュータ
は、ゲートウェイ用に利用可能である。IoT の分野で広く性あり）、正確に 1 回だけ配信される QoS2 の 3 段階の QoSを指定することができる(9)。一方、セキュリティに関して使われている Linux ボードコンピュータ Raspberry Pi(4)もその 1 つである。また、産業系のシステムではイーサネッ

は、Industrie 4.0(10)で推奨規格とされている OPC UA(4)が有力な選択肢となる。

ト対応の PLC も選択肢となる。
図 1 は、ゲートウェイとして Raspberry Pi を利用した例

一方、データの構造に応じた通信プロトコルを検討することも可能である。特に、階層構造をもつ構造化データをである(5)。図 1 中のスカラロボット（水平多関節ロボット）
は、USB 接続のみが可能であり、USB HID デバイスとしネットワーク上で送受信する場合は、それに適した通信プロトコルを用いることが望ましい。OPC UA は、その一例て USB 経由で制御できるが、イーサネットポートは備えておらず、表 1 の非 IP 通信の場合に該当する。そのため、である。

ゲートウェイが必要であり、Raspberry Pi を用いている。
なお、本例のゲートウェイでは、IP 通信としてはソフトウ

表 2．IoT の IP 通信で用いるプロトコルの候補
IP 通信
利用が検討される主なケース
プロトコル・ファイアウォールあり
HTTP
・Web ブラウザでの閲覧
・XML や JSON の送受信

ェアを変更することで OPC UA(6)、MQTT(7)および HTTPなどへの対応が可能である。また、必要に応じてプログラ
ムを作成することで USB の他、GPIO や I2C 等への対応も可能である。

（Restful API の利用）
Modbus TCP/IP ・制御機器等との通信・軽量なメッセージ配信
MQTT
・多対多のデータ配信
・QoS の確保 (Subscriber への配信回数)
OPC UA・構造化データの送受信
・Industrie 4.0 への対応
（推奨規格の使用）
・セキュリティ確保・コンパニオン仕様で決められた
データ構造を使用する場合

図 1．スカラロボットと（ゲートウェイとしての）Raspberry Pi

31

KISTEC研究報告（2018） 2018.10

【情報・生産技術部】

OPC UA では、通信対象のデータ構造（アドレス空間）を
情 報 モ デ ル に よ り 定 義 す る こ と が で き る が 、 OPC
Foundation が他の業界団体等と連携して定めたコンパニオン仕様において定義された情報モデルを用いることも可能である。
なお、ここで取り上げたプロトコルについて、その利用が検討・想定されるケースをまとめると表 2 のようになる。

５．

IoT システムの構築事例

ここでは、実際の IoT システムの構築事例について紹介する。1 例目は、所内にある既存の試験設備を対象としたものである。
図 2 の家具耐久試験機は昭和 49 年製であり、通信用インターフェースは備えていない。本試験機は、椅子の試験機であり、図 2 右側にあるフレーム内部に据え付

図 3．制御盤背面へ付加したゲートウェイ（Raspberry Pi）(右図は追加部の拡大図)

けた椅子を 4000 回または 5000 回負荷をかけて揺らすという耐久試験を行うものである。
本試験機については、耐久試験の進行状況（負荷回数）を確認するには、図 3 左側にある制御盤のカウンタ値を見る他なく、試験担当者には、離れた場所からでも進行状況を確認（遠隔監視）できるようにしたいとの要望があった。
これが、本試験機を IoT 対応する動機であった。
既に述べたとおり、本試験機には通信用インターフェースは備わっていない。一方で、制御盤（図 3 左側）内部にはアクセス可能で、各種電気信号を取得することは可能である。本事例では、カウンタへの入力となっている電気信号を用いることとした。よって、本試験機は表 1 の「非通図 4．監視用画面信」に該当する。IP 通信ネットワークへの接続には、ゲートウェイが必要となるが、先に紹介した Raspberry Pi を用デザインの過程で、当初の要望（カウンタ値の確認）に加え、試験機の状況も遠隔で確認したいとの要望があったた
め、Raspberry Pi に USB カメラを接続し、撮影した映像をいることとした。IP 通信で用いるプロトコルについては、遠隔監視の UI に Web ブラウザを用いるため、Raspberry PiWeb ブラウザで閲覧することも可能となっている。このような追加の要望に応じることができたのは、Linux ボードで対応可能な HTTP を用いることとした（表 2 参照）。
以上の検討を経て、Raspberry Pi に GPIO の入力機能やコンピュータである Raspberry Pi をゲートウェイに用いており、ソフトウェアの追加や変更が可能だからである。

Restful API を使用した Web サーバ(HTTP サーバ)の実装を行い、図 3 のように制御盤背面にゲートウェイ（Raspberry

次の例は、産業用コントローラである PLC を含む IoTシステム構築の事例である(11)。本事例のシステムは搬送シPi）を付加した。なお、制御盤から取得した電気信号をRaspberry Pi の GPIO に入力可能な 3.3V の信号に変換するステムを模擬したものであり、図 5 に示すように、スカラロボット 2 機、ベルトコンベア 2 台、インデックステーブためにリレーを用いている。図 4 は、本事例で作成したWeb 画面であり、デザイン担当職員が作成した。なお画面

ル 1 台からなっている。2 機のスカラロボットは、図 1 で紹介したものと同型であり表 1 の「非 IP 通信」に該当する。それ以外のコンベアとインデックステーブルは、IO経由で制御するものとなっており、表 1 の「非通信」に該

図 2．家具耐久試験機
図5．搬送システム

KISTEC研究報告（2018） 2018.1032

【情報・生産技術部】

当する。本事例は、産業用システムを模擬していることか【参考文献】

ら、ゲートウェイには Raspberry Pi だけでなく PLC も用いることとした。Raspberry Pi はスカラロボット 2 機と USB

1. 経済産業省，製造業の新たな展開と将来像，2015 年版

ものづくり白書，156-216(2015).
2. 第５期科学技術基本計画，(2016).

接続されるゲートウェイとして、PLC はコンベア 2 台とイ
ンデックステーブルにデジタル IO 接続されるゲートウェ

3. 経済産業省，価値創造に向けた Connected Industries の推進，2018 年版ものづくり白書，129-183(2018).

イとなっている。本事例では、PLC との通信が必要だが、その IP 通信には Modbus TCP/IP ではなく、OPC UA を用

4. Raspberry Pi Foundation Website,
https://www.raspberrypi.org/

いている。
これは、OPC UA を推奨規格としている Industrie 4.0（10）5. T. Mizuya, M. Okuda, T. Nagao, A Case Study of Data
Acquisition from Field Devices using OPC UA and MQTT,を意識し、OPC UA 通信用のライブラリが提供されている
PLC を採用したことによるものである（表 2 参照）。このProc SICE Ann. Conf. 2017, 611-614, (2017).
6. OPC Foundation Website, https://opcfoundation.org/

場合は、利用する IP 通信ネットワーク環境において、通信プロトコルに対する制約や要求事項があり、それに応じ

7. MQTT.org Website, http://mqtt.org/
8. Modbus Organization, Modbus Application Protocolて IP 通信プロトコルを選択している場合に相当する。
以上の 2 例では、機器やデバイスへのアクセスの形態とSpecification V1.1b3, (2012),
9. OASIS, MQTT Version 3.1.1,

IP 通信プロトコルの選択について、表 1 と表 2 を用いて検討した。これにより、機器やデバイスへのアクセスの類型

http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1 .1-os.
html, (2014).

化や、IP 通信プロトコルの選択の手順が実際のシステム構築に対して適用可能である。また、このような検討を行う

10. ZVEI, The Reference Architectural Model Industrie4.0(RAMI 4.0) version 1.0, (2015).

ことで、IoT システムの構成を明確化しやすくなっている。

６．

11. 奥田，水矢，吉田，PLCopen OPC-UA Client FB を利用しまとめた機器制御に関する研究, 第 5 回計測自動制御学会制御部門マ

本研究では、機器やデバイスからのデータ取得手段や、

ルチシンポジウム, Fr31-3,(2018).

IP 通信プロトコルの選択等における考え方と具体的な候補を明らかにし、実際のシステム構築に対して適用可能であることを示した。
今後は、本研究では対象としなかった IP 通信で送受信するデータの構造等についても検討を行うことが必要である。その場合には、カメラで撮影した画像データや、CPS(Cyber Physical Systems)や物理シミュレーションシス
テムで用いられる 3D データなどサイズが大きくなりがちなデータの扱いが課題になると考えられる。

33

KISTEC研究報告（2018） 2018.10