MQTT란 무엇이며 산업 자동화 회사는 이를 어떻게 사용할 수 있습니까?

산업용 사물 인터넷(IIoT)에 조금이라도 관여하고 있다면 여기저기서 MQTT라는 새로운 약어가 사용되는 것을 보게 될 것입니다. MQTT는 자동화에 있어 상당히 새로운 기술이지만 20년 이상 사용되었습니다. 원래 원격 유전에서 데이터를 가져오는 프로토콜로 개발되었지만 최근까지 이 틈새 응용 프로그램 외부에서 많이 채택되지 않았습니다. 이제 제조를 위한 디지털 혁신 프로젝트의 주요 프로토콜 중 하나로 부상하고 있습니다.

MQTT란 무엇입니까?

MQTT는 메시지 큐 원격 분석 전송을 나타냅니다. 클라이언트 서버 발행/구독 메시징 전송 프로토콜로, 제한된 대역폭 애플리케이션에서 작은 정보 패킷을 보내기 위한 경량 메시징 프로토콜로 간주됩니다. 그 핵심은 IoT 연결의 핵심인 OASIS 표준으로 간주됩니다.

기록

1990년대 후반에는 300보(baud)와 같이 매우 낮은 연결 속도로 원격 석유 사이트에서 데이터를 전송할 수 있는 경량 통신 프로토콜이 필요했습니다. 이 전략은 TCP 프로토콜을 사용하는 전송 계층에서 이미 제공되는 기능을 활용하는 것이었습니다. 제안된 애플리케이션 프로토콜은 전송 페이로드에 추가된 모든 중복성을 제거합니다. 또한 상태가 있어야 하고 예외에 의해서만 보고해야 합니다. 이러한 제약을 염두에 두고 Phillips 66은 Cirrus Link Solutions의 Arlen Nipper 및 IBM의 Andy Stanford-Clark와 협력하여 현재 MQTT 프로토콜로 알려진 프로토콜을 개발했습니다.

초기 상업적 사용

자동화 회사는 2000년대 초 MQTT 프로토콜로 접근했지만, 다른 상업적 용도는 Facebook Messenger 및 Apple Messages 애플리케이션뿐이었습니다. 흥미로운 주요 기능은 프로토콜이 데이터의 상태와 품질을 보장한다는 것입니다. 보낸 사람이 타이핑을 하고 있을 때 받는 사람은 화면에서 이제는 너무나 친숙한 세 개의 점을 보게 됩니다. 일부 가정 모니터링 및 날씨 데이터 애플리케이션에도 사용되었지만 그 시점에서 MQTT의 사용은 다소 제한적이었습니다.

자동화 채택

2010년대 중반에 Arlen Nipper는 MQTT 사용을 촉진하기 위해 다시 한 번 자동화 회사에 접근했습니다. 상당한 네트워크 요구 없이 집계된 추가 제조 데이터를 가져와야 할 필요성이 대두되었습니다. 그러나 제조 분야에서 승인을 얻으려면 몇 가지 추가 기능을 개발해야 했습니다. Cirrus Link Solutions는 Inductive Automation과 함께 자동화에 필요한 속성, 즉 정의된 주제 세트, 표준 페이로드 및 메시지 압축을 포함하는 현재 Sparkplug 표준의 개발을 진행했습니다.

구조 개요

MQTT는 컴퓨터의 폴더 구조와 유사한 구조를 사용합니다. Windows 바탕 화면을 예로 사용하겠습니다. 바탕 화면에는 내 문서라는 폴더가 있습니다. 내 문서에는 Family라는 또 다른 폴더가 있으며 그 폴더에는 각 가족 구성원의 폴더가 있습니다. 내 폴더의 경로는 Desktop/My Documents/Family/David입니다. 내 모든 문서를 David에게 저장(게시)할 것입니다. 내 문서를 읽고 싶어하는 사람은 누구나 David를 열어(구독) 할 것입니다.

MQTT 프로토콜을 사용하는 장치는 네임스페이스라는 유사한 주제 경로를 게시하고 구독합니다. 컴퓨터와 매우 유사하게 가장 일반적인 것부터 가장 구체적인 것까지 구성됩니다. 내가 구독하는 레벨이 높을수록 더 많은 데이터를 받게 됩니다. 주제 경로를 정의하는 데 사용할 수 있는 와일드카드도 있습니다. 별표(*)에는 현재 수준 이하의 모든 항목이 포함됩니다. 더하기(+)는 ​​경로를 한 단계 아래로 이동합니다. 기사 아래에 몇 가지 예를 더 포함했습니다.

ISA 표준과 일치

ISA-95 표준은 제조 분야에서 잘 알려져 있습니다. 엔터프라이즈와 제어 시스템 간의 인터페이스에 대한 표준 모델 및 용어를 설명합니다. 일반적으로 ERP가 맨 위에 있고 장치가 맨 아래에 있는 계층 구조로 구현되지만 표준은 주로 제조 데이터와 구조화 방법을 다룹니다. MQTT는 토픽 네임스페이스를 사용하기 때문에 ISA-95 계층 구조와 쉽게 정렬될 수 있습니다. 토픽 네임스페이스를 구성할 때 Enterprise, Site, Area, Line, Cell 다음에 오는 것이 좋습니다. 게시자/구독자의 루트 폴더도 적절한 수준에 있어야 합니다. 예를 들어, 셀을 제어하는 ​​PLC는 Enterprise/Site/Area/Line/Cell의 주제에 데이터를 게시해야 합니다. 프로세스 히스토리언이 특정 영역에 해당하는 경우 Enterprise/Site/Area 수준의 모든 데이터를 구독해야 합니다.

아키텍처

MQTT 사용으로 인해 발생하는 일반적인 질문 중 하나는 연결이 끊어지면 어떻게 되는지입니다. 이러한 상황을 완화하는 데 사용할 수 있는 몇 가지 옵션이 있습니다. 일반적인 솔루션은 "저장 후 전달" 방법을 사용하는 것입니다. 예를 들어, 제어 계층에 있는 SCADA 시스템은 MQTT 브로커에 대한 연결이 재개될 때까지 계속해서 데이터를 수집합니다. 브로커 연결이 재개될 때 저장된 모든 데이터의 타임스탬프는 그대로 유지된다는 점에 유의해야 합니다.

MQTT는 백업 브로커 사용도 지원합니다. 기본 브로커가 있는 동안 이 연결이 끊어지면 연결된 노드가 자동으로 다른 브로커로 전환됩니다. 관계는 일반적으로 이 기능을 지원하는 애플리케이션(예:SCADA 시스템)을 통해 구성됩니다.

클러스터링을 사용하여 또 다른 솔루션을 얻을 수 있습니다. 이는 데이터 손실을 감당할 수 없는 응용 프로그램에 일반적입니다. 일반적인 설정은 클러스터에 여러 MQTT 브로커를 배치하는 것입니다. 이러한 모든 브로커는 서로를 인식하고 클러스터 내에서 메시지를 공유합니다. 연결이 끊어지면 데이터 게시자와 구독자는 손실 없이 데이터를 다른 브로커로 원활하게 라우팅합니다.

엔터프라이즈 애플리케이션이 모든 플랜트의 데이터를 사용하는 것은 일반적입니다. 이 시나리오에서 MQTT는 저장 후 전달 시스템과 유사한 브리징 사용을 지원합니다. 이 아키텍처에서 한 브로커는 네임스페이스의 일부 또는 전체를 다른 브로커에 게시하거나 연결합니다. 다시 말해, 플랜트 브로커는 엔터프라이즈 브로커와 연결됩니다. 게시된 주제와 네임스페이스 구조를 모두 정의할 수 있습니다. 이는 게시된 데이터의 양을 제한하고 수신 브로커에 대한 컨텍스트를 제공합니다.

별표(*)가 있는 모든 데이터를 있는 그대로 게시하고 구조를 정의하지 않는 것이 가장 간단한 방법이지만 이로 인해 불필요하고 잠재적으로 혼란스러운 데이터가 많이 발생할 수 있습니다. 일부 데이터 컨텍스트를 제공하기 위해 게시된 주제 네임스페이스의 시작 부분에 주제를 추가할 수 있습니다. 예를 들어 Enterprise/Site를 플랜트 Area/+/Cell 네임스페이스에 추가하면 Enterprise/Site/Area/+/Cell이 Enterprise 브로커로 전송됩니다. 결과는 모든 라인의 셀 수준 데이터가 이 시스템에서 사용할 수 있다는 것입니다(+ 와일드카드 사용에 주의).

이러한 모든 시나리오를 배포할 수 있습니다. SCADA 시스템은 MQTT 클러스터에 저장 후 전달을 사용할 수 있습니다. 기본 및 백업 클러스터가 있을 수 있지만 이는 불필요한 복잡성을 추가할 수 있습니다. 마지막으로 플랜트 클러스터는 엔터프라이즈 클러스터에 브리지하여 데이터 무결성을 최대화할 수 있습니다. 이는 상당한 양의 양질의 데이터가 필요하기 때문에 엔터프라이즈 분석 및 기계 학습에 적합합니다.

보안

인터넷을 통해 제조 데이터를 송수신할 때의 주요 관심사 중 하나는 사이버 보안입니다. 진정한 보안을 위한 유일한 방법은 에어 갭을 사용하는 것이지만, 이는 조직의 디지털 혁신 능력을 방해합니다. MQTT의 주요 이점 중 하나는 보안입니다. 다른 통신 프로토콜은 네트워크 포트를 열어야 하지만 MQTT는 브로커에 대한 아웃바운드 연결만 필요합니다. 공장은 인바운드 포트를 열 필요가 없으므로 IT 조직에 매우 매력적입니다.

향후 고려 사항

향후 기사에서는 MQTT를 사용하는 일반적인 애플리케이션을 살펴보겠습니다. 프로토콜은 플러그 앤 플레이 방식으로 되어 있지만 추가 기술 세부 사항에 관심이 있을 것입니다. 비즈니스 리더는 MQTT가 현재의 디지털 혁신 노력에 어떤 영향을 미칠지 고려할 수 있습니다. 물론 엔지니어링 리더는 MQTT가 자신에게 어떤 영향을 미칠지 확실히 알고 싶어할 것입니다.

결론적으로 MQTT는 기존 아키텍처를 대체하는 것으로 간주되어서는 안 됩니다. 인더스트리 4.0 요구 사항에 맞춰 이미 있는 것을 활용합니다. OPC UA 및 기타 프로토콜은 제어 응용 프로그램에 대해 더 장황하기 때문에 계속해서 필요합니다. 그러나 상당한 양의 데이터를 집계하는 경우 MQTT가 탁월한 선택입니다.