産業用IoTアプリケーションの開発を促進する—パート1：IoTデバイスデータのシミュレーション

編集後記：組み込みアプリケーションの開発プロジェクトは、開発者が新しいデバイスでハードウェアを実装できるようになるのを待機することが原因で遅延する場合がよくあります。産業用モノのインターネット（IIoT）アプリケーション開発も、産業用の予知保全システムや、機械学習方式に基づく設備のオートメーションシステムのようなアプリケーションに必要なセンサデータを待つという、同じようなボトルネックに直面します。2つのパートで構成されるこのシリーズでは、IIoTアプリケーションの開発を促進するのに必要な初期データストリームの提供に代わる手段について見ていきます。このパート1では、こうしたデータストリームを生成するためのシミュレーション方式の活用について説明します。パート2では、データ生成を目的とした、センサシステムの迅速な試作に関する選択肢について取り上げます。

大規模な産業用モノのインターネット（IIoT）アプリケーションには、展開を失速させ、実装に必要な多数のリソースにおける投資利益率について企業が疑問を持つ原因となる課題が多数あります。こうした状況を回避し、IIoTを展開する利点について開発者がもっと早く確認できるようにするためには、展開のシミュレーションに必要なデータへすぐにアクセスできる必要があります。

シミュレーション方式を利用して現実的なデータストリームを生成することにより、開発者はIIoTアプリケーション開発をIoTネットワークの展開までに十分な期間を取って開始することができ、IIoTセンサネットワーク自体の定義を詳細に吟味することも可能です。

この記事では、各種のIoTクラウドプラットフォームがデータシミュレーションを実現する方法について説明し、その例として、展開を大幅に高速化できるMulti-Tech Systems Inc.のゲートウェイを紹介します。

IIoTデータのシミュレーション事例

もちろん、アプリケーションやシステムの開発を推進するためにシミュレーションされたデータを使用するのは、特に新しいことではありません。開発者は数十年にわたってシステムレベルのシミュレーションを使用して、コンピューティングインフラストラクチャやコネクティビティサービスに対するストレステストを実施してきました。これらのテストは、静的な構成の堅牢性を検証するために重要な役割を果たしてきました。クラウドサービスプラットフォームでは、こうしたテストによって、仮想マシンなどのクラウドリソースの自動スケーリングを検証する比較的単純な方法を実現してきました。

IIoTアプリケーションの場合は、このような場合と同じ要件に加えて、別の要件も必要になります。データシミュレーションは負荷テストや自動スケーリングに役立つのに加え、エンタープライズレベルのIIoTアプリケーションと同程度に複雑なソフトウェアを実装するのに必要な、さまざまなサービスおよびリソースの統合を検証するための重要なツールになります。データシミュレーションにより、このような比較的基本的な施策だけでなく、先進的なクラウドプロバイダが提供するさらに高度なサービスプラットフォーム上に構築される、複雑なIIoTアプリケーションの開発も推進することができます。

ソフトウェアからの視点

アプリケーションソフトウェアの開発者とセンサおよびアクチュエータシステムの開発者では、複雑なアーキテクチャ上で稼働するIIoTアプリケーションに対する見方がまったく異なります。後者にとって大規模なIIoTアーキテクチャは、アプリケーション全体に関係する物理プロセスと連動する、センサおよびアクチュエータの大規模なアセンブリです。アプリケーションソフトウェアの開発者にとっては、エンタープライズレベルのIIoTアーキテクチャは多数のサービスで構成されており、その連携するアクティビティが最終的にアプリケーションの機能を実現します。

Microsoft Azure IoTリファレンスアーキテクチャは、アプリケーションソフトウェアの視点から見た、典型的なIIoTアプリケーション（および一般的なIoTアプリケーション）の代表例です。この図は、周辺モジュールのエンドポイントおよびエッジデバイスからのデータに基づいて洞察を提供してアクションを実施するために、一般的なアプリケーションによってクラウドで統合された複数の機能サービスをまとめたものです（図1）。

図1：このMicrosoft Azure IoTリファレンスアーキテクチャは、一般的にIIoTアプリケーションにおいて、周辺モジュールのデバイスネットワークによって生成されるデータから役に立つ洞察やアクションを提供するために必要とされるクラウドの各種サービスおよびリソースを示しています。（画像提供：Microsoft Corp.）

具体的なアプリケーションソリューションでは、これらのクラウドリソースが適切に組み合わせられ、標準化された互換性メカニズムを使用して、アプリケーションロジックによって連携された状態で機能的に接続されます。たとえば、Amazon Web Services（AWS）のコネクテッドカーソリューションでは、アプリケーションの各種の機能や能力を実現する役割を担うモジュールにおいて、クラウドサービスがどのように組み合わされ、適合されているかが分かります（図2）。

図2：AWSのコネクテッドカーソリューションは、一般的で大規模なIoTアプリケーションで必要な機能を提供するためにクラウドサービスがオーケストレーションされている代表的な事例です。（画像提供：Amazon Web Services）

こうしたアーキテクチャの例から分かるとおり、IIoTアプリケーションを製作するためのソフトウェア開発に関連した取り組みはいずれも、センサおよびアクチュエータシステムの周辺ネットワークを実装するのと同様に困難かつ広範です。こうした複雑なソフトウェアの開発を、デバイスネットワークが十分なデータを生成するまで遅らせるゆとりがある組織はほとんどありません。現実には、分析スペシャリストや機械学習のエキスパートがアプリケーションの結果を基に作業を開始するまで、デバイスネットワークの展開における詳細な定義や調整を始めることはできません。最悪の場合、デバイスネットワークの展開とソフトウェアの開発がお互いの結果に依存することが原因で、こう着状態が発生することもあり得ます。

幸いにも、IoTアーキテクチャには、こうしたジレンマを解消することができるソリューションを備えているという特性があります。上記で紹介したMicrosoftやAWSのクラウドサービスアーキテクチャには大まかな共通点はあるものの、詳細はもちろん異なっています。しかし、これらのアーキテクチャはどれもIoTクラウドプラットフォームが一般的に備えている、以下のようなアーキテクチャ上の共通した特性を持っています。IoTデバイスの周辺機器ネットワークとクラウドベースのソフトウェアアプリケーションの違いは、定義済みのインターフェースサービスモジュールまたはレイヤの機能が使用されているかどうかです。均一なコネクティビティの実現に加えて、こうしたインターフェースサービスは、デバイス管理、セキュリティ、そして大規模なIIoTアプリケーションに必要とされる主要な機能にとって必要不可欠なものです。

Microsoft Azureクラウドでは、このインターフェースサービスはAzure IoT Hub（図1を再度参照）、AWSクラウドではAWS IoT Core（図2を再度参照）と呼ばれています。Google Cloud Platformでは、このインターフェースはCloud IoT Core、IBM CloudではIBM Watson IoT Platformサービスです。ThingWorx IoTプラットフォームなど、他のプラットフォームも、ThingWorx Edge Microserver、ThingWorx Kepware Server、またはプロトコルアダプタツールキットのようなコネクティビティサービスを使用して同様の接続を実現しています。つまり、どのクラウドプラットフォームも、周辺機器からのデータをクラウドサービスに送り込むための一貫したインターフェースサービスを提供する必要があるということです。そうしないと、周辺機器デバイスからクラウドの奥底にある個別のリソースに直接接続するという込み入った事態に対処しなければならなくなります。

シミュレーションされたデータの注入

各IoTプラットフォームのソフトウェア開発キット（SDK）を使用することで、シミュレーションされたセンサデータを、プラットフォームのインターフェースサービスに対して、アプリケーションの機能およびパフォーマンスを検証するのに必要な量、速度、多様性の水準で直接注入することができます。必要なレートおよび分解能で生成されたシミュレーション済みのデータは、MQ Telemetry Transport（MQTT）、Constrained Application Protocol（CoAP）などの標準的なプロトコルを使用してインターフェースサービスに到着します。インターフェースサービス（そしてダウンストリームのアプリケーションソフトウェア）では、シミュレーション済みのデータストリームとハードウェアセンサシステムで取得されたデータとを区別することができません。デバイスネットワークがオンラインになる準備ができると、センサデータストリームが、インターフェースサービスに到達するシミュレーションされたデータストリームを単純に置き換えます。

クラウドプラットフォームプロバイダは一般に、このデータシミュレーションアプローチをさまざまな水準の機能によってサポートします。たとえばGoogleは、シンプルなシミュレーション駆動型のアプリケーションを、アーキテクチャおよび温度制御ファンの単純な制御ループを実装するサンプルコードのリファレンスによって公開しています。先ほど紹介したアーキテクチャと同様に、このアーキテクチャでも、Google Cloud IoT Coreサービスインターフェースのデータを使用するGoogle Cloud Platformサービスが活用されています（図3）。

図3：任意のIoTクラウドプラットフォームで、デバイスシミュレータが物理デバイスと同じ通信プロトコルを使用して、ここに示すGoogle Cloud Platformアプリケーションアーキテクチャ用のGoogle Cloud IoT Coreなどのインターフェースサービスにデータを供給します。（画像提供：Google）

このサンプルアプリケーションでは、温度センサデバイスのシミュレータが選択された更新頻度でデータを生成し、そのデータがMQTTメッセージングプロトコルを使用してGoogle Cloud IoT Coreインターフェースサービスに渡されています。一方、このインターフェースサービスはプラットフォーム標準のパブリック-サブスクライブ（pub/sub）プロトコルを使用して、データをシミュレーションされたサーバに渡します。サーバは必要に応じてファンをオンまたはオフにするコマンドで応答します（図4）。

図4：サンプルのGoogleアプリケーションは、シミュレーションされたデバイスを構成する基本的な制御ループを示しています。このデバイスは標準の通信メソッドを使用して、Google Cloud IoT Core経由でデータをシミュレーションされたサーバに送信します。（画像提供：Google）

Googleは、この基本的なアプリケーションを実装するためのサンプルのPythonコードを提供しています。このコードでは、Deviceクラスインスタンスに、シミュレーションされたファンの状態に基づいてシミュレーションされた温度を更新するメソッドが含まれています。メインルーチンは指定された頻度でメソッドを呼び出し、Eclipse paho-mqtt Python MQTTクライアントモジュールによって提供されるMQTT接続サービスを使用してデータを送信します（リスト1）。

コピー
class Device(object): 
     """Represents the state of a single device.""" 
    def __init__(self):
         self.temperature = 0
         self.fan_on = False
         self.connected = False
 
    def update_sensor_data(self):
         """Pretend to read the device's sensor data.
        If the fan is on, assume the temperature decreased one degree,
        otherwise assume that it increased one degree.
        """
         if self.fan_on:
             self.temperature -= 1
         else:
             self.temperature += 1
...def main(): 
...
    device = Device()
 
 
    client.on_connect = device.on_connect
     client.on_publish = device.on_publish
     client.on_disconnect = device.on_disconnect
     client.on_subscribe = device.on_subscribe
     client.on_message = device.on_message
 
 
    client.connect(args.mqtt_bridge_hostname, args.mqtt_bridge_port)
 
 
    client.loop_start()
 
 
    # This is the topic that the device will publish telemetry events
     # (temperature data) to.     mqtt_telemetry_topic = '/devices/{}/events'.format(args.device_id)
 
 
    # This is the topic that the device will receive configuration updates on.     mqtt_config_topic = '/devices/{}/config'.format(args.device_id)
 
 
    # Wait up to 5 seconds for the device to connect.     device.wait_for_connection(5)
 
 
    # Subscribe to the config topic.     client.subscribe(mqtt_config_topic, qos=1)
 
 
    # Update and publish temperature readings at a rate of one per second.     for _ in range(args.num_messages):
         # In an actual device, this would read the device's sensors.Here,
         # you update the temperature based on whether the fan is on.         device.update_sensor_data()
 
 
        # Report the device's temperature to the server by serializing it
         # as a JSON string.         payload = json.dumps({'temperature': device.temperature})
         print('Publishing payload', payload)
         client.publish(mqtt_telemetry_topic, payload, qos=1)
         # Send events every second.         time.sleep(1)
 
 
    client.disconnect()
     client.loop_stop()
     print('Finished loop successfully.Goodbye!')

リスト1：Googleサンプルアプリケーションのこのスニペットは、mainルーチンがDeviceクラスインスタンスを定期的に更新する方法を示しています。このクラスインスタンスはシミュレーションされた温度センサの現在の値を格納しており、シミュレーションされたファンの状態に応じて値を更新するメソッドを提供します。（コード提供：Google）

一方、Serverクラスインスタンスは、Deviceクラスインスタンスから受け取った温度データに応じて、ファンの状態を更新するモジュールを提供します（リスト2）。

コピー
class Server(object):
     """Represents the state of the server."""...
    def _update_device_config(self, project_id, region, registry_id, device_id,
                               data):
         """Push the data to the given device as configuration."""         config_data = None
         print('The device ({}) has a temperature '
               'of: {}'.format(device_id, data['temperature']))
         if data['temperature'] < 0:
             # Turn off the fan.             config_data = {'fan_on': False}
             print('Setting fan state for device', device_id, 'to off.')         elif data['temperature'] > 10:
             # Turn on the fan
             config_data = {'fan_on': True}
             print('Setting fan state for device', device_id, 'to on.')         else:
             # Temperature is OK, don't need to push a new config.             return

リスト2：Googleサンプルアプリケーションのこのスニペットでは、Serverクラスで定義された_update_device_config()メソッドがこのアプリケーションのビジネスロジックを提供し、温度が定義した値を上回った場合はファンの状態をオンにし、温度が低下した場合はファンの状態をオフにします。（コード提供：Google）

開発者はGoogleのサンプルコードに加えて、多数のオープンソースのIoTデバイス、システム、およびネットワークシミュレータをGitHubのようなリポジトリで見つけることができます。たとえば、MicrosoftのオープンソースであるRaspberry Piシステムシミュレータのコードには、Raspberry Piボードと連動するクラウドベースアプリケーションの迅速な開発のために、事前に作成されたAzure IoT Hubとの統合が組み込まれています。また、Node-REDのようなローコードプログラミングツールでは、シミュレーションされたセンサデータを主要なクラウドプラットフォームのIoTサービスインターフェースに供給するために、事前に作成されたモジュール（ノード）がサポートされています。こうしたアプローチを利用することで、開発者はセンサデータのストリームを簡単に生成することができます。

大規模なシミュレーションを実行する

デバイスレベルのシミュレータや関連ツールを使用する場合の難しさは、データシミュレーションの管理自体がプロジェクトとなることにあります。シミュレータを実行するには、あらゆるアプリケーションと同様に、開発者がリソースをプロビジョニングおよびメンテナンスする必要があります。さらに懸念されるのは、実際のデータを生成するのに使用されるデバイスモデルが、IIoTアプリケーション開発プロセスに含まれない、別のプロジェクトになるということです。開発者は開発の進捗に合わせて、デバイスモデルをIIoTデバイスネットワークおよびアプリケーションの定義のあらゆる変更が同期された状態にしておく必要があります。エンタープライズレベルのIIoTアプリケーションの場合、これらのシミュレーションのスケーリングが難しいだけでなく、アプリケーションの開発に必要なリソースの利用も開始されます。

主要なIoTクラウドプラットフォームのプロバイダは、規模を拡張するために設計されたIoTデバイスのシミュレーションに関するこうした懸念事項に対し、自社の個別プラットフォームの他のクラウドリソースと同様の方法で簡単に対処しています。たとえば、AWSのIoTデバイスシミュレータには同社のCloudFormation構成サービス用のAWSテンプレートが用意されています。このサービスは、AWS Fargateサーバレスエンジンで実行されるコンテナに実装されるマイクロサービスを接続する仮想プライベートネットワークを展開します（図5）。

図5：AWSのIoTデバイスシミュレータでは、複数のAWSサービスが組み合わされており、物理デバイスによって使用されるのと同じAWS IoT Coreへのデバイスデータのスケーラブルなストリームを提供します。（画像提供：Amazon Web Services）

このシミュレーションには、Amazon S3サービスで実行されるグラフィカルユーザーインターフェース（GUI）コンソール経由でインタラクティブにアクセスするか、Amazon API GatewayサービスのCloudFormationテンプレートによって生成されるIoTデバイスシミュレータのアプリケーションプログラミングインターフェース（API）経由でプログラムを使用してアクセスします。シミュレーションの実行中、IoTデバイスシミュレータのマイクロサービスは、自身の構成項目で記述された全体的なシミュレーション計画に従って、Amazon DynamoDB NoSQLデータベースからデバイス構成を取得します。

このデバイス構成はJSONレコードであり、デバイスの属性名（temperatureなど）、値の範囲（-40～85など）を定義し、情報のうち、デバイスの間隔およびシミュレーション期間を更新します。開発者は、コンソール経由でインタラクティブに、またはAPI経由でプログラムを使用して、デバイスの種類を追加できます。通常のDevOps方式を使用して、デバイスの種類、構成、およびインフラストラクチャを素早く拡張し、目的とするデータの更新率がAWS IoT Coreおよびダウンストリームアプリケーションに到達するようにします。

Azureデバイスシミュレータでは、開発者は属性の基本リストと、シミュレーションの実行中にデバイスによってサポートされる一連の動作に加えて、クラウドアプリケーションが直接呼び出すことができるメソッドのセットをさらに追加することができます。

デジタルツイン

このようなデバイスデータシミュレーションは、商用IoTクラウドプラットフォームで急速に採用が進んでいる「デジタルツイン」機能と概念的に緊密に関連しています。一般にデバイスの状態の静的な表現のみを提供するデバイスシャドウとは対照的に、デジタルツインでは仮想デバイスモデルが物理デバイスの状態およびその動作と一致するように拡張されています。

MicrosoftのAzureでは、Azure Digital Twinsサービスを使用することにより、デバイスのシミュレーション中の動作を定義するユーザー定義の機能を組み込んで、以前と同様にAzure IoT Hubに結果の供給を続けることができます。シミュレーションされたものか現実のものかを問わず、受信されたデータはイベントのルーティングサービスに対して送信され、アプリケーション内でさらに配布されます。Microsoftもデジタルツインデータを使用して、複数のネットワークで構成される産業用オートメーションシステムなど、複雑で階層化された環境内の要素間のインタラクションおよび状態を表現した空間グラフを作成しています（図6）。

図6：Microsoft Azure Digital Twinsサービスを使用することにより、機能および能力の点で物理デバイスに相当する仮想デバイスを構築し、複雑なIIoT階層の空間グラフのような、高度なサービスのための基盤を提供することができます。（画像提供：Microsoft）

IIoTアプリケーションに対しては、デジタルツインによって、これらの機能を中心として構築されたアプリケーションのライフサイクル全体をサポートする強力なメカニズムを実現することができます。開発の初期段階では、プラットフォームのデバイスシミュレーションサービスによって、デジタルツインを大規模に駆動することができます。物理的なIIoTネットワークがオンラインになったら、デジタルツインに対するこれらのシミュレーションされたデータフィードをデバイスのデータフィードに置き換えることができます。その後、完全に展開されたIIoTアプリケーションでは、物理デバイスとそのデジタルツインの間で見つかった差異を、予知保全アルゴリズムまたはセキュリティ侵入検知器などに対する追加の入力として利用できます。デジタルツインはライフサイクルを通じて、ネットワークの障害やIIoTデバイスネットワークの構成における大幅な変更からアプリケーションを保護することができます。

IoTプラットフォームでのデジタルツインの台頭には、デバイスのモデル属性および動作を説明する標準化されたアプローチが提供されることによる副次的な利点もあります。説明の言語として、MicrosoftのAzure Digital TwinsサービスではJSON-LD（JavaScript Object Notation for Linked Data）が使用されています。World Wide Web Consortium（W3C）によって認定されているJSON-LDは、業界標準のJSON形式に基づいてリンクされたデータをシリアル化するための標準フォーマットを提供しています。このフォーマットは、他の多数のアプリケーションですでに利用されています。

標準化されたデジタルツインの説明に加えて、センサおよびアクチュエータを対象とした作成済みのデジタルツインの説明リポジトリの登場により、開発をより高速に行うことができるようになっています。たとえばBoschは、Eclipse Vorto言語で記述された複数の自社センサのオープンソースのデジタルツインの説明を、Eclipse Vortoリポジトリで提供しています。大半のプログラマが慣れ親しんでいる文法を使用するEclipse Vorto言語には、デジタルツインのモデルおよびインターフェースを説明するシンプルなメソッドが用意されています。Vorto言語の説明は、必要に応じて後からJSON-LDやその他の形式に変換することができます。

IIoTアプリケーションを構築する

個別のシミュレータまたはマイクロサービス向けのプラットフォームのどちらに組み込まれている場合でも、デバイスデータのシミュレーションは、アプリケーションの開発を促進する効果的なソフトウェアベースのソリューションを実現します。複数のデバイスネットワークを使用するIIoTアプリケーションの場合、デバイスのシミュレーションをエッジへと移行することにより、展開への移行が大幅に簡単になり、アプリケーション開発の初期段階の代表的データに対するニーズが犠牲になることはありません。

大規模なIoTアプリケーションにおいては、エッジコンピューティングシステムの役割の重要性が高まりつつあります。これらのシステムは、基本的なデータ処理からクラウドに到達するデータ量の削減、機械学習による推定モデルのような高度な分類機能に至るまで、増加しつつある要件に必要なローカルリソースを提供します。またエッジコンピューティングシステムも、フィールドエリアのデバイスネットワークと高速なバックホールネットワークの間の通信ゲートウェイとして、より根幹的な役割を果たすようになっています。

Multi-Tech Systemsのプログラム可能なMultiConnect Conduitファミリのようなゲートウェイには、通信サポートとエッジ処理機能が組み合わされたプラットフォームが用意されています。Multi-Techの915MHzリージョン用のMTCAP-915-001Aおよび868MHzリージョン用のMTCAP-868-001Aは、集約されたフィールドエリアネットワークのデバイスデータに対するLoRaWANコネクティビティ、およびクラウド側でのEthernetまたは4G-LTEコネクティビティを実現します。オープンソースのMulti-Tech Linux（mLinux）オペレーティングシステムを基盤としたこれらのプラットフォームには、デバイスのシミュレーションを実行するための使いなれた開発環境も用意されています。物理センサなどのデバイスがある個別のフィールドネットワークがオンラインになると、各ユニットは通信ゲートウェイとしての役割に戻り、処理の操作をデータ処理などの要件に転換します。

結論

IIoTアプリケーションは、現場でのセンサネットワークの展開における大きな課題であり、クラウドベースのアプリケーションソフトウェアの開発により、センサデータを実用的な結果へと転換することができます。センサネットワークとアプリケーションソフトウェアが相互に依存することにより、開発が停滞する可能性があると同時に、センサの展開とソフトウェアの実装は、それぞれが必要最小限の十分な水準に到達するのを待機します。

この記事で説明したとおり、開発者は量、速度、多様性の面で現実的な水準のデータストリームをシミュレーションすることでこの行き詰まりを解消し、IIoTアプリケーションの開発を促進することができます。