M2M 및 IoT 기능을 위한 애플리케이션 계층 프로토콜 옵션

사물 인터넷(IoT) 및 산업 4.0 기능을 채택함에 따라 산업용 프로토콜을 통해 장치를 연결하는 일이 늘어나고 있습니다. 게다가 오늘날의 기계 간(M2M) 통신은 이러한 프로토콜에서 빠르게 표준화되고 있습니다. 더욱 복잡한 문제는 현재 여러 표준이 시행되고 있기 때문에 IoT 프로토콜이 단일 애플리케이션 계층 프로토콜을 설명하지 않는다는 것입니다. 따라서 초기 IoT 구현에서는 표준 인터넷 프로토콜을 사용했지만 이제는 전용 IoT 프로토콜도 사용할 수 있습니다.

통신 구조를 모델링하고 특정 애플리케이션에 대해 올바른 프로토콜을 식별하는 것은 벅찬 과제일 수 있습니다. 이 기사에서는 설계 엔지니어가 통합할 가장 적합한 프로토콜을 손쉽게 선택할 수 있도록, 다양한 프로토콜이 수행하는 작업과 이러한 프로토콜에 사용 가능한 옵션을 설명합니다.

그림 1: 산업 자동화에서의 IIoT 함수는 네트워킹을 위한 산업용 프로토콜을 사용하는, 갈수록 더 연결되는 장치에 의존합니다. 이러한 네트워크에 대한 추상적 계층에는 기본 계층 함수에 대한 이해가 필요 없습니다. 이것이 바로, 많은 설계 엔지니어링이 기계 네트워크의 최상위(애플리케이션) 계층에 중점을 두는 이유입니다. (이미지 출처: Getty Images)

산업용 네트워크를 위한 애플리케이션 계층 프로토콜 정의

디지털 M2M 및 IoT 시스템을 위한 통신 프로토콜의 구조는 개념상으로 추상 계층으로 나눠집니다. 가장 일반적인 모델은 3계층, 4계층, 5계층 또는 7계층으로 구성됩니다. 이러한 개념적 프레임워크는 모든 계층이 통신 중인 다른 장치 또는 알고리즘으로부터 주어진 장치 또는 소프트웨어 계층의 세부적 작업을 본질적으로 "숨긴다"고 가정합니다. 계층은 데이터 교환에 충분한 정보만 포함하는 것으로 정의되기 때문입니다.

그림 2: 기존 시스템 아키텍처는 계층적이지만, 클라우드 및 포그 컴퓨팅은 구성 요소 기능 간에 선이 분명하지 않습니다. 이로 인해 새로운 네트워크 프로토콜 모델의 사용이 촉발되었습니다. (이미지 출처: motioncontroltips.com)

사용되는 모델에 상관없이, 애플리케이션 계층은 네트워크상에서 서로 통신하는 장치 사이에서 가장 높은 추상 계층으로 지정됩니다. 애플리케이션 계층을 개방형 시스템 간 상호 연결(OSI) 모델의 개념으로 간주해 보겠습니다. 이는 거의 30년 전에 네트워크 통신을 위해 국제 표준화 기구(ISO)에 의해 처음 정의되었습니다. 이 기본 7계층 모델은 오늘날의 일부 프로토콜을 설명하기에는 다소 복잡하지만 시스템 내의 데이터 흐름을 완전히 이해하는 데에는 여전히 유용합니다.

프로토콜의 물리 계층을 통해 원시 데이터(디지털 비트)를 전기, 무선, 광학 신호로 전송할 수 있습니다. 이 계층은 핀 레이아웃, 전압 레벨, 데이터 전송율, 및 데이터를 전송하는 물리 소자의 회선 임피던스를 지정합니다. 이더넷은 일반적인 물리 계층 프로토콜입니다. 이에 대한 자세한 내용은 DigiKey 기사 EtherNet/IP와 PROFINET 비교를 참조하세요.

데이터 링크 계층은 네트워크 노드를 연결하여 장치가 물리 계층에서 연결을 설정하고 오류를 수정할 수 있도록 합니다. IEEE 802 표준 내에서 데이터 링크 계층은 매체 접근 제어(MAC) 계층(장치가 연결되도록 함)과, 사용할 다음 계층(네트워크 계층) 식별, 오류 확인 및 동기화를 위한 논리 링크 제어(LLC) 계층으로 나뉩니다. DigiKey 기사 32비트 MCU를 통해 산업용 이더넷 구현에서 데이터 링크 계층의 기능에 대해 자세히 알아보세요. 대조적으로, 네트워크 계층은 데이터 패킷을 네트워크 주소로 전달할 수 있습니다. 인터넷 프로토콜이 전송 제어 프로토콜 및 인터넷 프로토콜(TCP/IP) 모델(이 기사의 다음 섹션에서 다룸)을 가리키는 경우 데이터 링크와 네트워크 계층 사이에 인터넷 계층이 있습니다. 실제로, 인터넷 계층은 종종 네트워크 계층의 일부로 간주됩니다.

다음 3개 OSI 모델 계층 중 첫 번째는 데이터 시퀀스 전송 중 통신 신뢰성과 보안을 보장하는 전송 계층입니다. 두 번째 세션 계층은 장치가 서로 연결되는 시기와 해당 연결이 단방향(단일)인지 또는 두 방향(2중)인지를 제어합니다. 마지막으로 프레젠테이션 계층은 데이터 변환을 허용하므로 서로 다른 구문을 사용하는 장치가 통신할 수 있습니다.

이 기사의 중심인 애플리케이션 계층은 추상의 최상위 레벨이며 사용자와 시스템 소프트웨어가 상호 작용하는 계층입니다.

그림 3: 최신 네트워킹 프로토콜(및 애플리케이션 계층)은 종종 산업(및 상업) 네트워크의 기본 OSI 모델을 사용하는 것으로 기술됩니다. 대조적으로, 3계층 IoT 아키텍처 모델은 인식 및 네트워크 계층 위에 애플리케이션 계층을 설정합니다. 4계층 모델은 이를 데이터 처리, 네트워크 및 감지 계층 위에 둡니다. 5계층 IoT 프로토콜 모델은 유사하지만 처리 계층과 엔터프라이즈 계층이 추가됩니다. (이미지 출처: Design World)

산업 자동화에서의 인터넷 프로토콜

인터넷 프로토콜은 경계 간 통신을 위해 네트워크 간에(일반적으로 상호적으로) 데이터를 전달하는 방식에 대해 명명된 통신 시스템입니다. 인터넷 프로토콜의 기능은 위에서 언급한 TCP/IP의 4계층 모델로 종종 설명됩니다. 여기서, 물리 네트워크 또는 링크 계층은 OSI 모델의 물리 계층과 동일합니다. 반대로, TCP/IP 인터넷 계층(대략적으로 OSI 모델의 데이터 링크와 네트워크 계층 기능의 조합)은 연결과 데이터 패킷을 처리합니다. IPv6에서 이 계층은 128비트 IP 주소를 사용하여 네트워크상의 호스트를 식별하며 10³⁸개 이상의 고유 호스트를 허용합니다.

TCP/IP의 전송 계층은 일반적으로 전송 제어 프로토콜(TCP) 또는 사용자 데이터 그램 프로토콜(UDP)로 구성됩니다. TCP는 일반적으로 이메일 및 웹 브라우징과 같은 인간 상호 작용에 사용됩니다. 이는 논리적 연결, 전송된 패킷 확인, 손실된 패킷 재전송 및 흐름 제어를 제공합니다. 그러나 임베디드 시스템은 UDP를 사용하여 오버헤드를 줄이고 실시간 성능을 향상시킵니다. UDP는 도메인 이름 서버(DNS), 동적 호스트 구성 프로토콜(DHCP), 새로운 IoT 애플리케이션에서 작동합니다.

애플리케이션 계층은 네트워크의 TCP/IP 모델의 최상위 레벨입니다. 기능에는 OSI 모델의 세션 계층 및 프리젠테이션 계층과 관련된 기능이 포함됩니다.

일반 TCP/IP 애플리케이션 계층 프로토콜

각각의 애플리케이션 계층 프로토콜은 서로 다른 데이터 대역폭, 실시간 기능 및 하드웨어 요구 사항을 가집니다. 프로토콜에 대한 시설 또는 OEM 팀의 친숙도와 함께 이러한 요소는 종종 중요한 선택 기준입니다. 하이퍼텍스트 전송 프로토콜(HTTP) 및 간이 전자 우편 전송 프로토콜(SMTP)을 포함한 초기 인터넷 프로토콜은 주로 인간 중심 및 인간 소비 통신에 사용되지만 IIoT 관점의 TCP/IP 프로토콜은 기계 간(M2M) 통신 및 기타 산업용 통신에 더 중점을 둡니다.

다소 복잡한 문제는 얼마나 많은 확립된 애플리케이션 계층 프로토콜(인간이 웹을 기반으로 하여 정보와 상호 작용할 수 있도록 TCP/IP에서 사용되는 확립된 애플리케이션 계층 프로토콜)이 소비자 가전용 및 산업용 IoT에도 사용되는가입니다. 이는 HTTP와 SMTP는 물론 시큐어 셸(SSH) 및 파일 전송 프로토콜(FTP)에서도 마찬가지입니다. 확장성 생성 언어(XML) 및 JavaScript 객체 표기법(JSON)도 사용되는 경우에는 대개 웹 기술을 통해 IoT 기능을 구현할 수 있습니다. 한 가지 주의할 점은 HTTP를 사용하면 보안에 영향을 미친다는 것입니다. 따라서 이러한 시스템의 IoT 장치에는 서버가 아닌 클라이언트만 포함하는 것이 가장 좋습니다. 이렇게 하면 장치가 네트워크에 대한 무단 외부 액세스를 허용할 수 있는 연결 요청을 수신하지 못합니다. 여기서 WebSocket 프로토콜은 HTTP를 통해 전이중 통신을 설정할 수 있습니다. 그렇지 않으면 우수한 보안 및 실시간 데이터 통신으로 여러 개의 장치를 처리해야 하는 설치에 확장 가능한 메시징 및 프리젠스 프로토콜(XMPP)이 선호될 수 있습니다.

IT 경험이 있는 직원이 IoT 프로젝트를 주도하는 경우 이러한 친숙한 표준(인간이 읽을 수 있는 웹)이 선호될 수 있습니다. 그러나 새로운 IIoT 프로토콜은 경우에 따라 M2M 및 기타 산업 통신에 더 적합할 수 있습니다.

수직 연결 전송 기능을 위한 MQTT

IIoT에서 가장 빠르게 채택되고 있는 것은 메시지 대기 텔레메트리 트랜스포트(MQTT) 프로토콜입니다. 이는 메모리가 제한된 IoT 장치를 위해 초기에 고안된 경량 프로토콜입니다. 콤팩트한 처리 공간에서 작업을 제공하고 최소한의 대역폭을 필요로 하는 MQTT는 송유관의 센서를 연결하기 위해 IBM에서 처음 개발되었습니다. 제약된 애플리케이션 프로토콜(CoAP)과 달리 MQTT는 이미 ISO/IEC 20922에 따라 표준화되어 있습니다. MQTT는 리소스 집약적인 TCP 전송 계층을 사용하므로 더 많은 전력을 소비하지만, 메시지 크기는 CoAP의 메시지 크기보다도 작은 2바이트일 수 있습니다.

개방형 특성으로 인해 MQTT는 구현하기가 특히 쉽습니다. Amazon Web Services의 AWS IoT가 메시지 전송에 MQTT를 사용하고(caveats 포함) v3.1.1 사양에 따라 MQTT를 지원하는 것은 당연합니다.

MQTT에는 몇 가지 제한 사항이 있습니다. 이는 MQTT가 초기에 원격 측정 프로토콜로 의도되었기 때문일 수 있습니다. 이는 곧 다룰 IoT 전용 경량 기계 간(LwM2M) 프로토콜과는 대조적입니다. 개체, 연결 모니터링 및 원격 장치 작업과 같은 기능은 표준에 포함되지 않으므로 제조업체에 따라 이러한 기능의 포함 여부가 달라질 수 있으며 이는 표준화된 프로토콜의 가치를 다소 떨어뜨립니다. MQTT는 오류 처리 기능도 제공하지 않습니다. 마지막으로 MQTT는 전체 TLS 프로토콜을 사용하여 보안을 유지할 수 있지만 그렇게 하면 오버헤드가 증가합니다.

엔터프라이즈 레벨의 기본: AMQP

고급 메시지 대기 프로토콜(AMQP)은 MQTT와 어느 정도 유사한 또 다른 개방형 표준입니다. 이 프로토콜은 메시지 대기와 같은 고급 기능을 제공합니다. 그러나 AMQP의 오버헤드는 MQTT의 오버헤드보다 높기 때문에 제약이 심한 장치를 연결하는 데 적합하지 않습니다. 당연히 산업용 IoT 애플리케이션에서의 사용보다는 고성능 엔터프라이즈 메시징에서의 사용이 일반적입니다.

단순 장치 연결을 위한 CoAP

인터넷 엔지니어링 프로젝트 팀(IETF)의 제약된 애플리케이션 프로토콜(CoAP)은 최소한의 메모리와 처리 능력으로 장치 간에 저전력 네트워크에서 통신할 수 있도록 합니다. 이는 매우 낮은 오버헤드로 작동할 수 있으며 요청 및 응답은 4바이트 정도로 작을 수 있습니다. CoAP는 UDP를 대신 사용하기 위해 복잡한 전송 스택을 사용하는 것을 피합니다. UDP에 대한 자세한 내용은 위에 링크된 DigiKey 기사 'EtherNet/IP와 PROFINET 비교'를 참조하세요. HTTP와 마찬가지로 CoAP는 REST 모델을 사용합니다. 서버는 URL에서 리소스를 사용할 수 있도록 하고 클라이언트는 POST, GET, DELETE 및 PUT 메서드를 통해 리소스에 액세스합니다. 또한 CoAP는 다른 웹 기능과의 통합을 위해 HTTP로 쉽게 변환될 수 있으며 XML 및 JSON과 통합됩니다. 엔지니어는 IoT 장치를 CoAP와 연결하는 것이 웹 API를 사용하여 장치를 연결하는 것과 매우 유사하다는 것을 알아야 합니다.

그림 4: Nordic의 SiP는 LTE-M 및 협대역(NB)-IoT 모뎀뿐만 아니라 GPS까지 통합된 저전력 MCU입니다. 소프트웨어 개발 키트를 사용하면 CoAP를 설정할 수 있습니다. (이미지 출처: Nordic Semiconductor)

LwM2M으로 배터리 구동 장치 연결

Open Mobile Alliance의 애플리케이션 계층 프로토콜은 IoT 응용 분야를 위해 특별히 제작된 LwM2M 프로토콜입니다. 스마트 시티 응용 제품, 선적 컨테이너 및 화물 추적, 자동화된 오프 하이웨이 루틴 및 유틸리티 모니터링에 사용되는 LwM2M은 CoAP를 기반으로 하므로 많은 속성을 공유합니다. 이 표준은 명확하게 정의되고 유지되는 광범위한 표준 개체와 연결 모니터링 및 원격 장치 작업을 포함합니다. 자동 펌웨어 업그레이드는 또한 LwM2M 연결 장치의 관리를 단순화합니다. JSON과 같은 모듈을 포함시키면 오버헤드가 증가하지만 개발자가 설계 작업을 손쉽게 수행할 수 있습니다. LwM2M은 IoT 응용 제품을 위해 특별히 설계되었기 때문에 오버헤드를 늘리지 않고도 강력한 DTLS 보안 프로토콜을 작동할 수 있습니다.

실시간 분산 애플리케이션을 위한 DDS

데이터 분산 서비스(DDS)는 약간 다르며 종종 애플리케이션 계층 프로토콜이 아닌 M2M 미들웨어로 분류됩니다. 이는 자율 주행 차량, 발전 및 항공 교통 제어 시스템에서 안전한 고성능 연결을 제공합니다. 이러한 설정에서 DDS는 게이트웨이에 과도하게 의존하지 않는 분산 제어를 위한 임베디드 시스템 연결을 지원합니다. DDS는 또한 애플리케이션의 개입 없이도 메시지 라우팅 및 전달을 처리합니다. 게다가 DDS 서비스 파라미터 변수의 품질을 구성할 수 있으므로 네트워크 운영을 시스템 제약 조건 내에서 작업에 최적화할 수 있습니다.

그림 5: 자율 주행 차량용 Connext Drive 소프트웨어는 데이터 분산 서비스(DDS) 미들웨어를 기반으로 하여 구축되었습니다. 이는 AUTOSAR(AUTomotive Open System ARchitecture) Adaptive 및 ROS2 소프트웨어 아키텍처에 대한 기반의 일부로 사용됩니다. 이는 DDS가 IoT 소프트웨어 통합을 지원하는 방법의 한 예일 뿐입니다. (이미지 출처: Real-Time Innovations)

결론: IIoT 애플리케이션 계층 프로토콜

모든 프로토콜에는 장단점이 있지만 IoT 애플리케이션에는 빠른 배포 및 보안(가급적 낮은 오버헤드 포함)을 허용하는 오픈 소스 옵션이 가장 적합합니다. 지속적으로 증가하는 컴퓨팅 기능을 갖춘 임베디드 시스템 및 SoC(시스템 온 칩) 장치는 계속해서 IIoT 구현에 박차를 가하고 있으며 다양한 프로토콜의 애플리케이션 계층에서 가능한 기능을 더욱 확장하고 있습니다.