프레임워크 및 전송:최고의 IIoT 연결 솔루션 선택

오늘날 새롭게 부상하는 IIoT(산업용 사물 인터넷) 환경에서 분산 시스템 인프라를 구축하는 것은 말할 것도 없이 벅찬 일이 될 수 있습니다. 개발자 또는 시스템 설계자라면 분산 응용 프로그램에서 데이터를 이동하는 데 사용할 수 있는 도구와 프로토콜이 많다는 것을 알고 있습니다. TCP 또는 UDP 소켓에서 직접 사용자 정의 솔루션을 구축할 가능성은 말할 것도 없습니다. 다음 인프라에 대한 결정을 내리기 전에 수행해야 하는 많은 작업이 이미 완료되어 있다면 좋지 않을까요?

그거 알아? 작업이 완료되었으며 이제 해당 결정을 내리는 데 도움이 됩니다. "이 모든 조사를 누가 수행했으며 자체 솔루션을 판매하려는 일부 회사에서 편향된 것입니까?"라고 질문해야 합니다. 좋은 소식은 이 연구가 독립 컨소시엄인 IIC(Industrial Internet Consortium)에서 완료되었다는 것입니다. 이는 공급업체 중립적이고 편견 없는 방식으로 수행되었으며 결과 정보를 이제 사용할 수 있습니다.

전체 면책 조항:예, 저는 산업용 인터넷을 위한 인프라를 제공하는 회사에서 일하지만 결코 우리 솔루션이 최고의 솔루션이라고 말하는 것은 아닙니다. "최선의 솔루션은 무엇입니까?"라는 질문에 대한 진정한 답은 무엇입니까? "에 따라 다릅니다."

대답은 인프라 솔루션에서 필요한 것에 따라 다릅니다.

<울>

A 지점에서 B 지점으로 데이터 바이트만 보내야 합니까?

데이터를 안정적으로 전달해야 합니까?

인프라가 보다 지능적인 솔루션을 위한 효율적인 제공 결정을 제공할 수 있도록 데이터 중심 인식이 필요하십니까?

데이터 처리의 어느 정도를 인프라에 넘기고 싶습니까?

이러한 중요한 질문에 대한 답변과 그 외 많은 사항이 이 게시물에서 제가 조사한 것입니다. 이 게시물이 끝날 때쯤에는 귀하의 고유한 응용 프로그램에 가장 적합한 솔루션이 무엇인지 정보에 입각한 결정을 내리는 데 필요한 정보를 얻으셨기를 바랍니다.

산업 인터넷 컨소시엄(IIC) 정보

IIC는 2014년에 산업 인터넷 환경의 일부 거대 기업에 의해 설립되었습니다. 창립 회사(Cisco, Intel, AT&T, IBM 및 GE)는 산업용 인터넷 응용 프로그램의 요구 사항에만 중점을 둔 조직을 만들기 시작했습니다. 이제 컨소시엄은 크고 작은 250개 이상의 회사로 구성됩니다. 이 컨소시엄의 결과에는 이러한 유형의 산업용 인터넷 응용 프로그램에 대한 요구 사항과 잠재적 솔루션을 설명하는 일련의 문서가 포함됩니다. 지침 문서인 IIC IICF(Industrial Internet Connectivity Framework) 문서는 시장 기반 사례에 대한 최상의 솔루션을 결정하는 데 완벽합니다. 다양한 문서 외에도 다양한 실제 시장 사례를 충족하는 다양한 기술의 능력을 입증하는 데 사용할 테스트베드도 구축했습니다. 사용 가능한 문서 및 시장 기반 테스트베드에 대한 정보는 IIC 웹사이트에서 확인할 수 있습니다.

데이터 제공:전송 및 프레임워크

오늘날 응용 프로그램 간에 데이터를 가져오는 데 사용할 수 있는 솔루션이 많이 있습니다. IICF 문서에서 이러한 솔루션은 전송 및 프레임워크의 두 가지 범주로 분류됩니다. 이 두 가지 유형의 데이터 전송 솔루션을 살펴보고 연결 계층의 전체 스택에서 어디에 적합한지 살펴보겠습니다. 아래 그림 1은 이 연결 스택을 보여줍니다.

그림 1. IIC 연결 프레임워크 스택

이 문서를 읽는 거의 모든 사람들은 이와 같은 연결 스택을 보았지만 IIC의 스택에는 전송 및 프레임워크 계층이라는 한 가지 분명한 차이점이 있습니다.

일반적으로 전송 및 프레임워크 범주에서 볼 수 있는 모든 솔루션을 함께 그룹화하는 경향이 있지만 전송과 프레임워크 사이에는 한 가지 매우 큰 차이점이 있습니다. 전송은 A 지점에서 B 지점으로 데이터를 전달하는 데 사용되는 반면 프레임워크는 기본적으로 상호 운용성을 위한 데이터 유형 시스템을 제공하면서 전송 기능을 활용합니다. 간단히 말해서, 전송만 사용할 때 애플리케이션은 전송에 전달하기 위해 데이터를 일반 버퍼로 공식화해야 합니다. 그러나 프레임워크를 사용하면 애플리케이션은 데이터를 프레임워크에 넘겨주기만 하면 되며 프레임워크는 기본 전송을 위한 버퍼 구성을 처리하여 데이터를 보냅니다. 응용 프로그램의 데이터 수준에서 작업하면 콘텐츠 필터링 및 검색과 같은 기능을 제공하는 응용 프로그램에 많은 이점이 있는 반면 응용 프로그램이 전송 계층에서만 사용하는 경우 필요한 경우 검색 및 필터링을 구현하는 것은 응용 프로그램에 달려 있습니다. 표 1은 전송 또는 프레임워크의 각 계층에서 사용할 수 있는 모든 기능을 제공합니다.

표 1. 전송 및 프레임워크 기능

전송을 사용하여 분산 산업용 인터넷 애플리케이션을 구축할 수 있습니까? 예. 프레임워크를 사용하여 분산형 산업용 인터넷 애플리케이션을 구축할 수 있습니까? 예. 하나가 다른 것보다 낫습니까? 진짜 대답은 "그것은 상황에 따라 다릅니다."입니다. 인프라에 가장 적합한 솔루션은 애플리케이션의 요구 사항에 따라 다릅니다. 이 게시물의 나머지 부분에서는 애플리케이션에 적합한 기술을 결정할 수 있도록 이러한 프레임워크 및 전송 중 몇 가지를 살펴볼 것입니다.

교통수단

오늘날 응용 프로그램 간에 데이터를 가져오는 데 사용할 수 있는 솔루션이 많이 있습니다. IICF에는 UDP 또는 TCP의 표준 IP 소켓 인터페이스를 활용하는 전송이 있습니다. 애플리케이션에 안정적인 데이터 전송이 필요한 경우 개발자는 연결 지향 기능과 안정적인 메커니즘을 위해 TCP를 선택합니다. 더 간단한 연결과 신뢰할 수 없는 데이터 전송을 위해 UDP는 사용 용이성과 멀티캐스트 전달을 위해 선택됩니다. 수년 동안 대부분의 네트워크 응용 프로그램은 데이터 송수신에 이러한 기본 인터페이스를 사용했습니다. 상위 계층 전송(표 1에 나열)이 제공하는 모든 기능은 애플리케이션 내에서 직접 구축되어야 합니다. DDS-RTPS, CoAP, MQTT, HTTP 및 OPC-UA Bin의 상위 계층 전송을 볼 때 실제로 CoAP 및 MQTT에 대한 세부 정보만 볼 것입니다. DDS-RTPS, HTTP 및 OPC-UA Bin 전송은 기본적으로 각각 DDS, 웹 서비스 및 OPC-UA 위의 프레임워크에 직접 연결됩니다. 이러한 전송의 기능은 다음 프레임워크 논의의 일부로 논의될 것입니다.

MQTT

MQTT(Message Queuing Telemetry Transport)에 대해 살펴보겠습니다. 다시 말하지만, MQTT는 애플리케이션에 대한 데이터 모델을 시행하거나 구현하지 않기 때문에 여기에 전송으로 나열됩니다. 애플리케이션이 전송 및 수신을 위해 데이터를 공식화해야 하는 버퍼만 제공합니다. 생성된 주요 목적은 Telemetry라는 이름에 바로 나열되어 있습니다. 현장에 있는 장치 또는 애플리케이션을 백엔드 클라우드 또는 오프사이트 처리 위치에 연결하고 데이터를 보고합니다. 이 전송은 홈 IoT 게이트웨이 또는 배포된 장치 집합의 관리자와 같은 작업에 적합합니다. MQTT의 기본 아키텍처는 그림 2에서 볼 수 있듯이 브로커 기반입니다.

그림 2. MQTT 브로커 아키텍처

이 아키텍처에서 모든 원격 클라이언트는 데이터를 MQTT 브로커에 보내고 브로커는 해당 데이터를 요청한 모든 클라이언트에 데이터를 보낼 책임이 있습니다. 이 브로커 기반 아키텍처를 사용하면 느슨하게 결합된 방식으로 데이터를 쉽게 보내고 받을 수 있지만 대기 시간이 짧고 결정성이 높은 산업 응용 프로그램을 지원하는 데 적합하지 않습니다. 전송으로서 MQTT는 분산 산업 응용 프로그램의 전체 환경에서 위치를 차지합니다. 다음은 MQTT가 다음 또는 현재 프로젝트에 사용해야 하는 항목인지 결정하는 데 사용할 수 있는 도구입니다. 다음은 5가지 "예" 또는 "아니오" 질문입니다. 이 질문 중 3개 이상에 대한 대답이 "예"인 경우 MQTT가 올바른 선택입니다.

MQTT 질문

<올>

귀하의 애플리케이션을 데이터 수집이라고 생각하십니까?

기기 간 통신이 거의 없습니까?

상호 운용성은 고려 대상이 아닌가요?

소형 기기가 많습니까?

소프트웨어는 사소한 문제입니까?

MQTT는 실제로 상위 계층 프레임워크에 연결되지 않은 IICF 문서에 나열된 유일한 전송입니다. 이것이 우리가 운송 수단으로 별도로 분리 한 이유입니다. 이제 IIC 문서에 나열된 프레임워크를 살펴보겠습니다.

프레임워크

앞에서 언급했듯이 프레임워크와 전송의 구별되는 차이점은 프레임워크에 참여하는 응용 프로그램에서 사용하는 데이터 모델을 유지 관리하고 적용하는 기능이 포함되어 있다는 사실입니다. OPC-UA, OneM2M, DDS 및 웹 서비스라는 네 가지 프레임워크 중에서 처음 세 개만 살펴보겠습니다. 웹 서비스는 연구를 위해 찾을 수 있는 많은 온라인 참조가 있는 매우 잘 알려진 프레임워크이므로 이 게시물에서 검토하지 않습니다. 선택한 각 프레임워크(OPC-UA, OneM2M 및 DDS)에 대해 해당 프레임워크의 기본 개요와 해당 프레임워크가 분산 IIoT 애플리케이션에 대한 올바른 솔루션인지 결정하기 위해 답해야 하는 주요 질문을 제공합니다.

OPC-UA

첫 번째 프레임워크인 OPC-UA를 살펴보겠습니다. 개방형 플랫폼 통신 통합 아키텍처(OPC-UA)는 IICF 문서에서 "플랫폼 독립적, 고성능, 보안, 신뢰성 및 의미론적 상호 운용성을 위한 산업용 통신 아키텍처로 센서, 필드 장치, 컨트롤러 및 애플리케이션 간의 작업 현장 수준은 물론 작업 현장과 엔터프라이즈 IT 클라우드 간에도 실시간으로 확인할 수 있습니다."

MQTT와 마찬가지로 OPC-UA도 브로커 기반 아키텍처입니다. OPC-UA 클라이언트는 서버에 데이터 개체를 제공하고 서버는 다른 OPC-UA 클라이언트의 요청에 응답합니다. 일반적으로 이러한 데이터 개체는 기본적으로 다양한 장치 입력 및 출력 변수의 모음인 매우 장치 중심적인 개체입니다. 클라이언트는 원하는 개체의 그래프를 구성할 수 있으며 서버는 수집된 모든 개체를 매핑하고 요청하는 클라이언트에 일관된 응답을 제공합니다. 그림 3은 주어진 시스템에서 사용 가능한 기존 개체의 그래프를 보여주는 일반적인 아키텍처 다이어그램입니다.

그림 3. OPC-UA의 일반적인 장치 데이터 개체 그래프

OPC-UA 인프라는 주로 산업 자동화 및 제조 환경에서 사용됩니다. 다음은 OPC-UA가 귀하의 애플리케이션에 올바른 솔루션인지 판단하기 위해 답변해야 하는 4가지 질문입니다.

OPC-UA 질문

<올>

단일 제조에 종사하고 계십니까?

독일 플랫폼 인더스트리 4.0 프로그램에 참여하고 계십니까?

소프트웨어 엔지니어가 아닌 제어 또는 프로세스 엔지니어나 기술자가 통합할 장치를 만들고 있습니까?

귀하의 제품이 아키텍처를 제어하는 ​​하나의 시스템이 아닌 다른 시스템의 다른 애플리케이션에서 사용됩니까?

"작업실"을 위한 장비를 만들고 있습니까?

이 세 가지 질문에 "예"라고 답할 수 있다면 OPC-UA가 귀하의 애플리케이션에 적합한 선택입니다.

원엠투엠

IIC 문서에서 호출한 두 번째 프레임워크는 oneM2M입니다. IICF 문서의 한 M2M에 대한 설명은 "oneM2M은 애플리케이션과 연결 전송 사이에 있는 공통 서비스 계층을 제공합니다. 다양한 산업 부문의 IoT 애플리케이션이 일반적으로 필요로 하는 기능을 제공합니다. 이러한 기능은 RESTful API를 통해 애플리케이션에 노출됩니다. OneM2M 표준은 응용 프로그램, 미들웨어 서비스 및 네트워크로 구성된 3계층 모델에 맞는 수평적 플랫폼 아키텍처로 구성됩니다. OneM2M의 연결 표준은 연결된 기계 및 장치, 엔터프라이즈 시스템 및 모바일 장치에서 호스팅되는 응용 프로그램이 효율적인 방식으로 서로 통신할 수 있도록 합니다. , 보안 방식. oneM2M 수평 플랫폼은 호스트, 인접 네트워크 에지 또는 엔터프라이즈 클라우드 내에서 공통 서비스 요소를 배포할 수 있으므로 확장 가능합니다." 오늘날 oneM2M을 사용하는 주요 애플리케이션은 홈 오토메이션과 모바일 시스템을 활용하는 대규모 애플리케이션입니다. Common Service Layer에서 사용할 수 있는 서비스는 대형 통신 회사에서 제공합니다. 그림 4는 oneM2M에서 호출되는 3개의 레이어 아키텍처를 보여줍니다.

그림 4. oneM2M 아키텍처

다음은 oneM2M이 귀하의 애플리케이션에 올바른 선택인지 결정하기 위해 답변해야 하는 5가지 특정 질문입니다. 이 질문 중 3개에 "예"라고 답하면 oneM2M이 귀하에게 올바른 선택임을 나타냅니다.

OneM2M 질문

<올>

"ICT"가 무엇을 의미하는지 알고 있습니까? 그것이 바로 당신입니까? (정보 및 통신 기술)

셀룰러 네트워크가 주요 연결 기술입니까?

대상 애플리케이션이 주로 움직이는 부분으로 구성되어 있습니까?

시스템 구성 요소가 간헐적인 연결과 느슨하게 제어되는 대기 시간을 견딜 수 있습니까?

귀하의 시스템은 통신 회사와 같은 통신 제공업체에서 제공하는 서비스를 활용합니까?

데이터 배포 서비스(DDS)

마지막으로 살펴볼 프레임워크는 DDS입니다. 이 게시물의 작성자이자 RTI 직원인 저는 14년 넘게 DDS와 함께 일했기 때문에 DDS에 편향되어 있음을 인정해야 합니다. IIC IICF에서 언급된 네 가지 프레임워크 중 DDS는 P2P, 게시/구독 아키텍처를 제공하는 유일한 프레임워크입니다. DDS를 사용하면 각 응용 프로그램은 공유 전역 데이터 공간을 만드는 "데이터 버스"에 참여합니다. 이는 데이터 버스가 각각 고유한 데이터 모델로 정의된 데이터 주제 세트로 구성되어 데이터 버스의 모든 참가자가 검색할 수 있음을 의미합니다. 피어 응용 프로그램이 주제에 대한 데이터를 게시하거나 주제에 대한 데이터를 구독하려는 의도를 선언하면 DDS는 검색 메커니즘을 통해 모든 적절한 게시자를 구독자와 연결합니다. 그림 5는 수평 계층 사이에 위치한 게이트웨이를 통해 연결되는 3개의 데이터 버스를 인스턴스화하는 계층화된 데이터 버스 아키텍처의 다이어그램입니다.

그림 5. DDS를 사용한 Layered Databus Architecture

이 예제 다이어그램은 병원에서 볼 수 있는 의료 환자 모니터링 애플리케이션을 기반으로 합니다. 그러나 이것은 오늘날 DDS가 사용되는 다양한 유형의 실시간 자율 애플리케이션 중 하나일 뿐입니다. 다른 응용 분야로는 스마트 그리드, 석유 및 가스, 자율 주행 차량, 운송 및 방위 시스템이 있습니다. 다음은 DDS가 귀하에게 적합한 선택인지 확인하기 위해 귀하의 신청서에 대해 스스로에게 물어봐야 하는 5가지 질문입니다.

DDS 질문

<올>

몇 분/초/밀리초 동안 오프라인 상태인 경우 심각한 결과가 발생합니까?

지난 2주 동안 "밀리초" 또는 "마이크로초"라고 말한 적이 있습니까?

10명 이상의 프로그래머가 있습니까?

데이터에 여러 목적지가 있습니까?

차세대 IIoT 설계를 구축하고 있습니까?

정리하기

앞서 언급했듯이 저는 DDS 회사에서 일하기 때문에 DDS 인프라와 DDS 인프라가 실시간 자율 시스템에서 해결하는 문제에 부분적으로 동의합니다. 하지만 이 게시물이 귀하의 다음 또는 현재 분산 인프라 프로젝트. 실제로 이러한 전송 및 프레임워크는 모두 매우 다른 문제를 해결하는 데 능숙하기 때문입니다. 핵심은 사용 가능한 솔루션의 범위 내에서 애플리케이션 요구 사항이 적합한 위치를 파악하는 것입니다. 여기에서 권장하는 도구에는 IIC IICF(산업 인터넷 연결 프레임워크)와 각 솔루션에 대한 주요 질문 목록이 포함됩니다. 빠진 것이 있으면 주저하지 말고 댓글로 연락해 주세요. 토론을 계속하고 싶고 개발자와 설계자가 맞춤형 독점 솔루션으로 바퀴를 다시 만들 필요 없이 연결 문제를 해결하는 데 도움이 될 수 있는 다른 솔루션에 대해 배우고 싶습니다.

추가 리소스:

<울>

RTI 블로그>> 산업 인터넷 연결 문서에서 핵심 표준 평가:DDS, OPC-UA, WebServices

무료 주문형 웹 세미나:IIC의 연결 프레임워크가 IIoT 연결 선택을 안내하는 방법