IoT의 클라우드 기반 소프트웨어 업데이트를 위한 구성요소

제한된 에지 기기와 더 강력한 컨트롤러 및 게이트웨이에서 소프트웨어(구성 요소)를 업데이트하는 것은 대부분의 IoT 시나리오에서 일반적인 요구 사항입니다.

소프트웨어 업데이트 기능이 있으면 보안 IoT 보장 IoT 프로젝트에 Pandora의 상자에 맞서 싸울 기회를 제공함으로써 기기가 연결되는 순간 열렸습니다. . 그 순간부터 장치는 IT 보안 위협의 최전선에 있으며 역사적으로 많은 임베디드 소프트웨어 개발자가 직면한 적이 없습니다. 예를 들어, 요즘에는 평생 동안 보안 업데이트가 적용되지 않은 Linux 기반 웹 연결 기기를 배송하는 것은 자살과 유사합니다.

소프트웨어 업데이트에 대한 더 매력적인 주장은 하드웨어 및 하드웨어 관련 구성요소의 민첩한 개발을 가능하게 한다는 것입니다. 모든 기능이 제조 시점에 준비될 필요가 없기 때문에 최소 실행 가능한 제품과 같은 개념을 장치에 적용할 수 있습니다. IoT 솔루션의 클라우드 측 변경 사항은 런타임 시 기기에도 적용될 수 있습니다.

장치가 업데이트 가능한 경우 고객에게 훨씬 더 매력적이기 때문에 소프트웨어 업데이트 자체가 비즈니스 모델인 경우가 있습니다. 즉, 소비자는 고정된 기능 집합을 얻을 수 있을 뿐만 아니라 향후 제품 업데이트의 이점도 기대할 수 있다는 것을 알고 있습니다. 또한 추가 기능(예:앱 ) 새 기기(개정판)를 설계, 제조 및 배송할 필요가 없습니다.

기기 연결

장치를 클라우드 서비스에 연결하는 다양한 옵션이 있습니다. 아키텍처 관점에서 기기를 직접 연결해야 하는지 여부를 결정해야 합니다. 소프트웨어 업데이트 서비스에 또는 간접적으로 장치 연결 계층(예:Bosch IoT Hub, AWS IoT, IBM Watson IoT, Azure IoT Hub 등)을 통해, 그 자체로도 IoT 솔루션 서비스가 될 수 있습니다. 나는 직접 접근 방식을 크게 신뢰하며 내 제품인 Bosch IoT Rollouts는 실제로 두 가지를 모두 지원합니다. 그 이유는 아래에서 설명하겠습니다.

시작하겠습니다. 직접 연결을 사용하면 IoT 솔루션이 기기 이벤트 스트림 및 명령에 사용하는 자체 채널 외에 소프트웨어 업데이트를 위한 별개의 채널을 가짐으로써 IoT 솔루션이 문제를 분리할 수 있습니다.

이것은 두 가지 이유에서 흥미로운 접근 방식입니다. 첫째, 다른 채널의 모든 비즈니스 요구 사항에 신경 쓸 필요가 없다면 소프트웨어 업데이트 채널의 API를 안정적으로 유지하는 것이 훨씬 쉬워집니다 . IoT에는 연결된 장치가 백엔드와 접촉하지 않고 오랜 시간 동안 작동할 수 있는 시나리오가 있다는 것을 잊어서는 안됩니다. 어떤 경우에는 특히 제조와 초기 연결 사이에 몇 년이 걸릴 수 있습니다. 전송 계층을 일정 시간 동안 안정적으로 유지하는 것은 쉽지만 비즈니스 계층의 경우에는 확실히 그렇지 않습니다. 이는 많은 클라우드 솔루션이 아직 성숙 단계에 있는 IoT에서 특히 그렇습니다.

둘째, 별도의 채널을 사용하면 비즈니스를 분리하고 기기 자체의 기능을 업데이트할 수도 있습니다. . 특히 복잡한 스택(예:IoT 게이트웨이)에서 잠재적으로 손상된 스택이 문제를 해결하기 위해 자체 업데이트해야 하는 위험을 감수하고 싶습니까? 그리고 항상 그렇게 할 수 있다고 보장할 수 있습니까? 메모리 부족 예외를 일으키는 하나의 번들과 함께 게이트웨이에 OSGi 런타임이 있고 소프트웨어 업데이트 클라이언트가 동일한 런타임에서 실행되는 시나리오를 상상해 보십시오. 결과를 예측하는 것은 매우 어려울 수 있습니다.

그러나 분리에는 대가가 따릅니다. 일반적으로 2개의 채널은 장치 측에서 더 많은 구현 노력을 의미하며 일부 시나리오에서는 트래픽 예산이나 배터리 수명의 소모를 증가시킬 수도 있습니다.

두 번째 옵션은 단일 채널에서 사용 사례를 결합하는 것입니다. 이를 간접이라고 합니다. 클라우드 연결 레이어가 실제로 장치에 연결되고 클라우드의 업데이트 트래픽에서 솔루션을 분리해야 하므로 소프트웨어 업데이트 서비스와 통합됩니다.

이는 단순화된 연결 아키텍처의 큰 이점이 있습니다. 또한 일반적으로 표준의 하위 섹션으로만 소프트웨어 업데이트를 포함하는 범용 장치 관리 프로토콜 표준(예:LWM2M, OMA-DM, TR-069)을 활용할 수 있습니다. 또한 장치(제조업체) 자체에서 정의한 독점 프로토콜을 사용할 수 있습니다.

결국 IoT 솔루션 엔지니어는 선택의 여지가 있습니다. 관심사의 분리 vs. 단순성. Bosch IoT 출시를 통해 두 가지 옵션을 모두 지원하기로 결정했으며 두 가지 옵션을 모두 사용하는 고객이 있습니다. 직접 연결은 IoT 솔루션의 유지 관리가 훨씬 쉬운 반면 간접 연결은 전체 아키텍처에 많은 복잡성을 추가합니다.

그러나 대부분의 IoT 엔지니어는 대부분의 경우 핵심 비즈니스 기능의 일부가 아니기 때문에 프로젝트 후반부에 설계 프로세스에 소프트웨어 업데이트 문제를 포함하며, 이러한 문제가 발생하면 더 이상 변경하고 싶지 않습니다. 그들의 건축에. 결과적으로 대부분의 솔루션은 간접적인 접근 방식을 취하여 가동 후 결과로 고통을 받을 수 있습니다.

IoT에서 클라우드 기반 소프트웨어 업데이트에 대한 두 번째 결정은 프로토콜과 관련이 있습니다. 표준 장치 관리 프로토콜을 사용해야 합니까 아니면 맞춤형 프로토콜을 설계해야 합니까? 오늘날 많은 IoT 솔루션은 맨 위에 사용자 지정 프로토콜이 있는 MQTT를 선호합니다. 또한 시장에 나와 있는 많은 IoT 연결 계층도 HTTP, MQTT 또는 AMQP 위에 독점 프로토콜을 제공합니다.

개인적으로 일부 표준에는 가치가 있으며 최소한 고려되어야 한다고 생각합니다. OMA-DM v2는 유망해 보이며 LWM2M에도 약간의 경험이 있습니다. 항상 그렇듯이 표준은 좋은 프레임워크를 제공하지만 일반적으로 일련의 제약 조건이 있습니다. 특히 IoT 프로젝트의 초기 단계에서 이는 많은 복잡성을 추가할 수 있습니다. 그러나 소프트웨어 업데이트를 다루는 좋은 표준은 장치와 소프트웨어 업데이트 서비스가 모두 기성품을 지원하는 경우 IoT 솔루션이 코드 한 줄도 작성할 필요 없이 소프트웨어 업데이트를 기능으로 포함할 수 있도록 합니다.

마지막으로 장치 인증에 대한 질문이 있습니다. 물론 이것은 모든 IoT 솔루션에 대한 일반적인 질문입니다. 그러나 특히 직접 통합 경로의 경우 소프트웨어 업데이트 및 IoT 솔루션 채널에 동일한 인증 메커니즘을 사용할 수 있는지 여부를 선택해야 합니다. 나는 보통 같은 메커니즘을 사용하는 것에 대해 주장합니다. 이것은 실제로 비대칭 인증(예:X.509 인증서)으로 구현하기 쉽습니다. Bosch IoT 롤아웃은 직접 장치 통합 API와 IoT에서 일반적으로 사용되는 대부분의 연결 계층에 대해 이를 지원합니다. 비대칭이 옵션이 아닌 경우(제한된 임베디드 장치의 경우에 자주 발생함) 다른 채널에서 사용할 수 있는 중앙(대칭) 키 저장소로 이동하는 것이 좋습니다.

위에서 지적한 바와 같이 선택해야 할 선택 사항과 답변해야 할 질문이 있습니다. 불행히도 IoT는 아직 대부분의 시나리오에 맞는 하나의 아키텍처를 찾은 상태가 아닙니다. 하지만 좋은 소식은 옵션이 있으며 효과가 있다는 것입니다.