산업용 IoT 응용 제품 개발 가속화 - 1부: IoT 장치 데이터 시뮬레이션

편집자 주: 개발자가 새로운 장치에서 하드웨어가 구현될 때까지 기다리느라 내장형 응용 제품 개발 프로젝트가 지연되는 경우가 있습니다. 산업용 사물 인터넷(IIoT) 응용 제품 개발의 경우에도 머신 러닝 방법에 기반한 산업용 예측 유지 보수 시스템 또는 시설 자동화 시스템과 같은 응용 제품에 필요한 센서 데이터를 대기하느라 비슷한 병목 현상이 발생합니다. 2부로 구성된 이 시리즈에서는 IIoT 응용 제품 개발을 가속화하는 데 필요한 데이터 스트림을 조기에 제공하기 위한 대안을 살펴봅니다. 여기 1부에서는 시뮬레이션을 사용하여 데이터 스트림을 생성하는 방법을 설명합니다. 2부에서는 데이터 생성을 위한 센서 시스템의 시제품을 빠르게 제작하기 위한 옵션을 살펴봅니다.

대규모 산업용 사물 인터넷(IIoT) 응용 분야에서는 배포를 정체시키고 기업으로 하여금 구현에 필요한 다양한 리소스에 대한 투자 수익을 의심하게 만드는 여러 가지 과제가 있습니다. 그런 상황을 방지하고 개발자가 IIoT 배포 시 이점을 더 빠르게 확인하게 하려면 배포 시뮬레이션 데이터에 즉시 액세스할 수 있어야 합니다.

시뮬레이션 방법을 통해 실용적인 데이터 스트림을 생성하면 개발자가 IoT 네트워크를 배포하기 이전에 IIoT 응용 제품 개발을 시작하고 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 허브라고 하고(그림 1), AWS 클라우드에서는 AWS IoT Core라고 합니다(그림 2). Google Cloud Platform에서는 이 인터페이스가 Cloud IoT Core이고 IBM Cloud에서는 IBM Watson IoT 플랫폼 서비스입니다. 마찬가지로 ThingWorx IoT 플랫폼과 같은 기타 플랫폼은 ThingWorx Edge Microserver, ThingWorx Kepware Server 또는 프로토콜 어댑터 도구 키트와 같은 연결 서비스를 통해 연결됩니다. 요약하면 모든 클라우드 플랫폼은 주변 장치의 데이터를 클라우드 서비스로 수집하는 일관된 인터페이스 서비스를 제공해야 합니다. 그렇지 않으면 주변 장치를 클라우드 내의 개별 리소스에 직접 연결하여 혼란스러워지는 위험을 감수해야 합니다.

시뮬레이션된 데이터 주입

각 IoT 플랫폼의 소프트웨어 개발 키트(SDK)를 사용하여 개발자는 응용 제품의 기능과 성능을 확인하는 데 필요한 볼륨, 속도 및 다양성 레벨에서 시뮬레이션된 센서 데이터를 플랫폼의 인터페이스 서비스에 주입할 수 있습니다. 원하는 속도와 분해능으로 생성되는 시뮬레이션된 데이터는 MQTT(MQ Telemetry Transport), CoAP(Constrained Application Protocol) 등과 같은 표준 프로토콜을 사용하여 인터페이스 서비스에 전달됩니다. 인터페이스 서비스(및 다운스트림 응용 소프트웨어)에 전달된 시뮬레이션된 데이터 스트림은 하드웨어 센서 시스템에서 수집된 데이터와 구분되지 않습니다. 장치 네트워크를 온라인으로 연결할 준비가 되면 인터페이스 서비스에 전달된 시뮬레이션된 데이터 스트림이 센서 데이터 스트림으로 대체됩니다.

클라우드 플랫폼 제공업체는 일반적으로 다양한 기능 레벨에서 이 데이터 시뮬레이션 방식을 지원합니다. 예를 들어 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() 메서드는 응용 제품에 비즈니스 논리를 제공하여 온도가 정의된 값 이상으로 상승하면 팬 상태를 on으로 설정하고 그 아래로 떨어지면 팬 상태를 off로 설정합니다. (코드 출처: Google)

Google의 샘플 코드 외에도 개발자는 GitHub와 같은 저장소에서 수십 개의 오픈 소스 IoT 장치, 시스템 및 네트워크 시뮬레이터를 찾을 수 있습니다. 예를 들어 Microsoft의 오픈 소스 Raspberry Pi 시스템 시뮬레이터 코드에는 Raspberry Pi 기판에 연결되는 클라우드 기반 응용 제품을 빠르게 개발하기 위해 사전 빌드된 Azure IoT Hub 통합이 포함되어 있습니다. 또한 Node-RED와 같은 로우 코드 프로그래밍 도구는 주요 클라우드 플랫폼 IoT 서비스 인터페이스에 시뮬레이션된 센서 데이터를 공급하는 사전 빌드된 모듈(모드)을 지원합니다. 개발자는 이러한 방식으로 센서 데이터 스트림을 쉽게 생성할 수 있습니다.

대규모 시뮬레이션 실행

장치 레벨 시뮬레이터 및 관련 도구를 사용할 경우 데이터 시뮬레이션을 관리하는 것이 그 자체로 부담이 된다는 어려움이 있습니다. 시뮬레이터를 실행하기 위해 개발자는 모든 응용 제품과 마찬가지로 리소스를 프로비저닝하고 유지 보수해야 합니다. 더 큰 문제는 실제 데이터를 생성하는 데 사용되는 장치 모델이 IIoT 응용 제품 개발 프로세스 밖에서 별도의 프로세스가 된다는 것입니다. 개발을 진행하면서 개발자는 장치 모델이 IIoT 장치 네트워크 및 응용 제품의 변경된 정의와 기능적으로 동기화된 상태로 유지되는지 확인해야 합니다. 엔터프라이즈급 IIoT 응용 분야의 경우 개발자는 이러한 시뮬레이션을 비율 조정하는 것이 아무리 잘해도 어렵다는 것을 알고 응용 제품을 개발하는 데 필요한 리소스에 의존하기 시작할 수 있습니다.

주요 IoT 클라우드 플랫폼 제공업체는 해당 플랫폼의 다른 클라우드 리소스처럼 쉽게 비율 조정하도록 설계된 IoT 장치 시뮬레이션 솔루션으로 이러한 문제를 해결합니다. 예를 들어 AWS IoT Device Simulator는 AWS Fargate 서버리스 엔진에서 실행 중인 컨테이너에서 구현되는 마이크로 서비스를 연결하는 가상 사설망을 배포하는 CloudFormation 구성 서비스를 위한 AWS 템플릿을 제공합니다(그림 5).

그림 5: AWS IoT Device Simulator는 여러 AWS 서비스를 결합하여 물리적 장치에 사용되는 것과 동일한 AWS IoT Core에 확장 가능한 장치 데이터 스트림을 제공합니다. (이미지 출처: Amazon Web Services)

개발자는 Amazon S3 서비스에서 실행 중인 그래픽 사용자 인터페이스(GUI) 콘솔을 통해 대화식으로 시뮬레이션에 액세스하거나, Amazon API Gateway 서비스의 CloudFormation 템플릿에서 생성되는 IoT Device Simulator 응용 프로그래밍 인터페이스(API)를 통해 프로그래밍 방식으로 시뮬레이션에 액세스합니다. 시뮬레이션 실행 중에 IoT Device Simulator 마이크로 서비스에서는 자체 구성 항목에 설명된 전체 시뮬레이션 계획에 따라 Amazon DynamoDB NoSQL 데이터베이스에서 장치 구성을 가져옵니다.

장치 구성은 장치 속성 이름(예: 온도), 값의 범위(예: -40 ~ 85), 장치 업데이트 간격, 시뮬레이션 기간 등을 정의하는 JSON 기록입니다. 개발자는 콘솔을 통해 대화식으로 또는 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)를 사용합니다. W3C(World Wide Web Consortium)의 후원으로 JSON-LD는 다양한 응용 제품 세그먼트에서 이미 사용 중인 산업 표준 JSON 형식을 기반으로 연결된 데이터를 직렬화하기 위한 표준 형식을 제공합니다.

표준화된 디지털 쌍둥이 설명은 센서 및 액추에이터에 대한 사전 빌드된 디지털 쌍둥이 설명 저장소의 등장으로 개발을 가속화할 수 있습니다. 예를 들어 Bosch에서는 이미 Eclipse Vorto 언어로 작성되고 Eclipse Vorto 저장소에 게시되는 다양한 센서에 대한 오픈 소스 디지털 쌍둥이 설명을 제공하고 있습니다. 대부분의 프로그래머에게 친숙한 문법을 사용하는 Eclipse Vorto 언어에서는 디지털 쌍둥이에 대한 모델 및 인터페이스를 설명하는 간단한 방법을 제공합니다. 나중에 개발자는 필요에 따라 Vorto 언어 설명을 JSON-LD 또는 다른 형식으로 변환할 수 있습니다.

IIoT 응용 제품 빌드

개별 시뮬레이터를 사용하든 마이크로 서비스 중심 플랫폼을 사용하든 상관없이 장치 데이터 시뮬레이션에서는 응용 제품 개발을 가속화하는 효과적인 소프트웨어 기반 솔루션을 제공합니다. 여러 장치 네트워크를 사용하는 IIoT 응용 제품의 경우 장치 시뮬레이션을 에지로 마이그레이션하면 응용 제품 개발 초기에 담당자 데이터에 대한 필요성을 유지하면서 배포 단계로 쉽게 이전할 수 있습니다.

에지 컴퓨팅 시스템은 대규모 IoT 응용 제품에서 중요한 역할을 합니다. 이러한 시스템은 클라우드에 도달하는 데이터의 양을 줄이기 위한 기본 데이터 전처리부터 머신 러닝 인터페이스 모델과 같은 고급 분류 기능까지 새롭게 등장하는 요구 사항을 충족하는 로컬 리소스를 제공합니다. 또한 에지 컴퓨팅 시스템은 기본적으로 현장 장치 네트워크와 고속 백홀 네트워크 간의 통신 게이트웨이 역할을 합니다.

Multi-Tech Systems의 프로그래밍 가능 MultiConnect Conduit 제품군과 같은 게이트웨이는 통신 지원을 에지 처리 기능과 결합하는 플랫폼을 제공합니다. 915MHz 영역용 Multi-Tech MTCAP-915-001A와 868MHz 영역용 MTCAP-868-001A는 현장 네트워크 장치 데이터 집계를 위한 LoRaWAN 연결과 클라우드측 이더넷 또는 4G-LTE 연결을 제공합니다. 또한 오픈 소스 Multi-Tech Linux(mLinux) 운영 체제를 기반으로 하는 이러한 플랫폼은 장치 시뮬레이션을 실행하기 위한 친숙한 개발 환경을 제공합니다. 개별 현장 네트워크가 물리적 센서 및 다른 장치와 온라인으로 연결되면 각 장치는 통신 게이트웨이 역할로 복귀하여 처리 노력을 데이터 전처리와 같은 요구 사항으로 리디렉션할 수 있습니다.

결론

IIoT 응용 제품은 현장에서 센서 네트워크를 배포하고 센서 데이터를 유용한 결과로 변환할 수 있는 클라우드 기반 응용 소프트웨어를 개발해야 하는 중요한 과제를 제공합니다. 센서 네트워크와 응용 소프트웨어 간의 상호 의존성으로 인해 개발하는 데 어려움이 따르며 상호 간에 충분한 임계 질량 레벨에 도달할 때까지 센서 배포와 소프트웨어 구현이 지연됩니다.

위에서 살펴본 바와 같이 개발자는 실제 볼륨, 속도 및 다양성 레벨에서 데이터 스트림을 시뮬레이션하여 이러한 교착 상태를 타개하고 IIoT 응용 제품 개발을 가속화할 수 있습니다.