IoT 기기를 위한 견고한 클라우드 기반 소프트웨어 업데이트

리소스 제약 엣지 디바이스와 강력한 컨트롤러 또는 게이트웨이 모두를 최신 상태로 유지하는 것은 사실상 모든 IoT 배포에서 필수적입니다.

소프트웨어 업데이트 기능은 기기가 인터넷에 연결되는 순간 등장하는 진화하는 위협 환경으로부터 커넥티드 디바이스를 보호하는 최전선 방어선입니다. 보안 패치를 결코 받지 않는 리눅스 기반 웹 연결 디바이스는 운영자에게 사실상 자살 임무나 다름없습니다.

보안 너머로 업데이트는 애자일 하드웨어 개발을 가능하게 합니다. 기능을 점진적으로 롤아웃하여 최소 기능 제품을 지속적으로 진화하는 플랫폼으로 전환. 고객은 시간이 지남에 따라 새로운 기능을 수신하는 기기를 선호하며, 제조업체는 하드웨어 재설계나 재배송 없이 앱 같은 기능 확장을 수익화하여 새로운 수익원을 열 수 있습니다.

디바이스 연결 선택

업데이트 전략 계획 시 첫 결정은 디바이스가 업데이트 서비스에 직접 연결할지, 간접적으로 디바이스 연결 레이어(예: 보쉬 IoT 허브, AWS IoT, IBM Watson IoT, Azure IoT Hub)를 통해 연결할지입니다. 보쉬 IoT Rollouts는 두 접근법 모두 지원하며, 그 유연성이 중요한 이유입니다.

직접 연결은 업데이트 채널을 다른 데이터 스트림에서 격리하여 각각이 독립적으로 진화하도록 합니다. 이 분리는 비즈니스 채널이 급격히 변하더라도 업데이트 API를 안정적으로 유지합니다. 이는 제조 후 수개월 또는 수년 동안 오프라인 상태일 수 있는 초기 단계 IoT 솔루션에서 흔한 시나리오입니다.

또한 디바이스에서 비즈니스 로직을 업데이트 프로세스에서 격리합니다. OSGi 런타임을 실행하는 IoT 게이트웨이 같은 복잡한 스택에서 업데이트 클라이언트가 미션 크리티컬 번들과 같은 런타임을 공유하면 런타임이 불안정해질 경우 실패할 수 있습니다. 업데이트 프로세스를 분리하면 이 위험을 완화합니다.

물론 두 채널은 디바이스에서 추가 구현 노력 필요하고 트래픽이나 배터리 소모 증가시킬 수 있습니다. 그럼에도 많은 엔지니어는 유지보수성 이점이 추가 복잡성을 상회한다고 봅니다.

간접 연결은 모든 트래픽을 클라우드 연결 레이어가 관리하는 단일 채널로 통합합니다. 이는 디바이스 펌웨어를 단순화하고 이미 업데이트 하위 프로토콜을 포함하는 성숙한 디바이스 관리 프로토콜(LWM2M, OMA-DM, TR-069) 사용 가능. 제조업체 정의 독점 프로토콜도 수용 가능.

실제로 엔지니어들은 프로젝트 후반까지 업데이트 통합을 미루며 기본적으로 간접 경로를 택하고 배포 후 결과 처리하는 경향이 있습니다. 보쉬 IoT Rollouts로 프로젝트 성숙도와 복잡성에 가장 부합하는 접근법 선택 가능.

직접과 간접 선택 시 관심사 분리 vs 아키텍처 단순성 중 무엇이 우선인지 자문하세요. 보쉬 IoT Rollouts는 둘 다 지원하여 단일 패턴에 락인되지 않고 솔루션 진화 가능.

또 다른 핵심 결정은 전송 프로토콜입니다. 많은 솔루션이 커스텀 오버레이가 있는 MQTT 채택, 다른 솔루션은 연결 레이어가 제공하는 독점 프로토콜 활용. OMA-DM v2나 LWM2M 같은 표준은 견고한 프레임워크 제공하지만 초기 단계 복잡성 유발 가능. 잘 선택된 표준이면 커스텀 코드 작성 없이 디바이스와 업데이트 서비스가 아웃-오브-박스로 작동.

디바이스 인증은 두 경로 모두에 중요. 가능한 경우 업데이트 채널과 주 IoT 채널 모두에 동일한 비대칭 메커니즘(예: X.509 인증서) 사용 – 보쉬 IoT Rollouts의 직접 디바이스 통합 API가 지원. 제약된 디바이스에 비대칭 자격증명 불가능하면 중앙 대칭 키 스토어가 간극 메움.

궁극적으로 단일 아키텍처가 모든 IoT 시나리오에 적합하지 않습니다. 좋은 소식은 검증된 다양한 옵션이 존재하며, 각각 보안, 민첩성, 운영 요구사항에 맞게 조정 가능하다는 점입니다.