무선 소프트웨어 업데이트 기술은 과거 모바일이 주요 대상이었지만 최근에는 IoT와 자동자 분야로 대상을 넓혀가고 있다.

사물인터넷 기술의 확산 속도가 무섭다. 시장조사기관 가트너에 따르면, 2020년에는 전자제품의 95%에 사물인터넷(IoT) 기술이 탑재된다고 한다. 바야흐로 사물인터넷 기술을 기반으로 한 ‘초연결 시대’의 도래가 머지않았다. 문제는 ‘기하급수적으로 불어나는 사물인터넷 기기들을 어떻게 관리할 것인가’다.



인터넷에 연결되는 기기 수는 계속 증가하는데, 이를 효율적으로 통합 관리할 체계가 없다면 큰 혼란이 야기된다. 우리 사회 곳곳에 퍼져있는 사물인터넷 기기를 포괄적으로 업데이트하고 또 보안 위협으로부터 실시간으로 보호할 수 있는 기술 개발이 필요하다. 이러한 사물인터넷 기기 관리 이슈와 맞물려 ‘무선 소프트웨어 업데이트 기술’에 대한 관심이 커지고 있다.

무선 소프트웨어 업데이트 기술은 쉽게 말해 원격지에서 기기의 펌웨어 및 소프트웨어를 무선으로 업그레이드하는 것을 의미한다. FOTA(Firmware Over the Air) 혹은 SOTA(Software Over the Air)가 대표적인 기술이다. 과거에는 모바일을 주요 대상으로 했으나, 최근 각종 사물인터넷(Internet of Things, IoT)과 자동차 분야로 그 대상을 확대하고 있다.

주목적은 자동차 OEM의 소프트웨어 리콜 비용을 절감하기 위해서다. 시장조사 기관 IHS에 따르면 무선 소프트웨어 시장은 2022년까지 자동차 분야에서만 350억 달러 이상 규모로 성장할 것으로 예상된다. 고객의 요구사항이 점점 다양해짐에 따라 업데이트 패키지 생성, 기기 관리 클라이언트 및 서버, 스마트 게이트웨이, 보안 등 주요 기술의 확보와 관련 솔루션 개발이 시급해지고 있다.



무선 소프트웨어 업데이트 기술의 구성

일반적으로 무선 소프트웨어 업데이트는 (그림 1)에 예시된 바와 같이 구성된다. 주로 제조사가 업데이트 패키지를 생성하고, 관리자(Customer Support Representative, CSR) 소프트웨어가 업데이트 서버, 단말에 내장되어 있는 소프트웨어 클라이언트와 실제 업데이트를 수행하고 관리한다. 제조사의 신구 소프트웨어 버전으로부터 생성된 업데이트 패키지는 업데이트 서버에 등록된다. 단말은 다양한 FOTA 개시 동작을 통해 서버로부터 해당 업데이트 패키지를 다운로드한다.

이후 업데이트 에이전트(Update Agent) 소프트웨어를 통해 실제 업데이트 동작을 수행하고, 그 결과를 서버에 통보하면 관리자는 이를 서버와의 인터페이스를 통해 확인할 수 있다. 이러한 시스템 동작을 안정적으로 수행하기 위해서는 다음과 같은 주요 기술이 필요하다.

업데이트 패키지 생성 기술

무선 소프트웨어 솔루션 업체는 통상적으로 업데이트 패키지를 생성하는 툴과 이와 연계하여 단말에 포팅되는 업데이트 에이전트를 묶음으로 제공한다. 업데이트 패키지 생성은 신규 펌웨어 전체를 데이터로 사용하는 풀 이미지(Full Image) 업데이트 방식과 기존 펌웨어 대비 신규 펌웨어 데이터의 차이를 계산하여 데이터를 사용하는 델타(Delta) 업데이트 방식이 있다.

 
델타 이미지 방식은 풀 이미지 방식보다 업데이트 패키지를 작게 만들 수 있어 효율적이나, 버전 관리가 어렵다는 단점이 있다. 델타 업데이트 패키지 생성은 (그림 2)와 같이 이전 소프트웨어 버전과 신규 소프트웨어 버전으로부터 차이를 계산하는 부분(Diff Generation)과 이를 패키징하여 최종 업데이트 패키지를 생성하는 부분(Package Generation)으로 이루어진다. 패키징하는 방법으로는 UPC(Update Package Container) 혹은 PIC(Package Ingest Container) 규격이 사용된다.

표준 기기 관리 클라이언트/서버 기술

무선 FOTA 동작을 위해서는 크게 3가지 기능을 하는 클라이언트 소프트웨어가 단말 단계에서 구현되어야 한다. 이는 각각 FOTA 동작을 위해 서버와의 통신을 담당하는 기기 관리 에이전트(Device Management Agent, DMA), 서버에 등록되어 있는 업데이트 패키지를 다운로드하기 위한 다운로드 에이전트(Download Agent, DLA), 실제 단말 내 업데이트 동작을 수행하는 업데이트 에이전트(Update Agent, UA)이다.

 

DMA에 사용되는 표준 프로토콜은 초기 모바일 분야에서 일본 KDDI에서 사용했던 WAMP(Web Application Messaging Protocol)과 버라이즌과 같은 북미 사업자 중심으로 사용된 OMA DM(Open Mobile Alliance Device Management)이 주를 이루었다.

하지만 최근 들어서는 LwM2M(Lightweight Machine to Machine) 프로토콜의 사용이 점점 많아지고 있음을 (그림 3)을 통해 확인할 수 있다. LwM2M은 OMA DM을 만든 OMA에서 사물인터넷용으로 신규 제정한 프로토콜이다. 표준은 아니지만 FOTA의 다운로드 에이전트와 업데이트 에이전트간의 인터페이스를 규정한 OTAFF(Over The Air Flash Forum) 규격도 많이 사용되는 추세다.

 
LWM2M 표준에서는 단말에 내장되어 있는 클라이언트 소프트웨어가 업데이트 서버와의 통신을 통해 (그림 4)와 같이 4가지 상태로 동작한다. 소프트웨어 업데이트 동작이 개시(Initiation)되면 클라이언트는 ‘IDLE’ 상태에서 ‘DOWNLOADING’ 상태로 이동한다. Package URI에 명시된 다운로드 서버에 접속하거나 서버로부터 직접 업데이트에 필요한 패키지를 다운로드 한다.

정상적으로 다운로드를 마치면 동작 상태는 ‘DOWNLOADED’ 상태가 되고 수신된 업데이트 패키지에 대한 모호성(Integrity)을 체크한다. 정상적인 패키지의 경우, 추가적인 업데이트 동작이 실행되며 실제 업데이트 동작을 실행하기 위한 ‘UPDATING’ 상태로 이동한다. 이후 업데이트 결과에 따라 클라이언트 소프트웨어는 업데이트 동작 결과를 서버에 통보하여 결과를 관리자가 알 수 있도록 한다.

대부분의 통신 사업자가 제정한 FOTA 요구사항 문서에 따르면 소프트웨어 업데이트를 개시하는 방법으로 다음 4가지를 들 수 있다.

- 서버 개시(Server Initiation) : 업데이트 관리자가 다수의 단말에 대해 업데이트 캠페인을 수행할 경우, 서버로부터 SMSC를 통해 특정 업데이트용 WAP Push 메시지(OMADM의 경우 Package 0 메시지)를 단말에 전송하여 업데이트를 개시하는 방식. 네트워크 개시(Network Initiation) 방법으로도 불린다.

- 유저 개시(User Initiation) : 실제 단말의 사용자가 유저 인터페이스를 통해 소프트웨어 업데이트를 개시하는 방법. 통상적으로 스마트폰의 경우, 세팅 메뉴 내 소프트웨어 업데이트 화면으로부터 업데이트를 개시할 수 있다.

- 클라이언트 개시(Client Initiation) : 단말의 기기 이동이나 신규 구입 시 기기 등록(Activation) 동작을 수행할 때마다 업데이트 클라이언트가 서버에 접속하여 업데이트 필요 유무를 체크하는 방법. 모바일 번호를 저장하는 SIM이 변경되거나 기기 고유의 제조번호 변경 시 자동으로 개시된다.

- 클라이언트 체크인(Client Check-in) : 미리 설정된 설정 주기마다 혹은 설정 주기 내 임의 방식으로 업데이트 클라이언트가 서버에 접속하여 업데이트 유무를 체크하는 방법. 서버 개시 방법이나 유저 인터페이스 구현이 어려운 다수의 사물인터넷 기기 단말에 적용 가능한 매우 유용한 방식이다.

 
OMA DM 기반 FOTA 응용을 규정하는 ‘FUMO1.0’ 규격에 따르면 FOTA 업데이트 패키지 다운로드 방식은 (그림 5)와 같이 나타난다. 서버와 클라이언트 간 다운로드 방식에 따라 하나의 서버에서 PkgData로 바로 전송 처리하는 인밴드(In-band) 방식과 다운로드 서버를 별개로 구성하여 PkgURL로 처리하는 얼터너티브(Alternative) 방식이 있다.

다운로드 후에는 업데이트 개시 방법에 따라 다운로드와 업데이트를 동시에 처리하는 원이벤트(One-event) 방식과 다운로드 동작과 업데이트 동작을 구분하여 처리하는 투이벤트(Two-events) 방식으로 구분된다.

 

원이벤트 얼터너티브 다운로드 방식이 주로 사용되고 있으며, 이 경우 OMADM 표준 기반 서버와 클라이언트 간 통신은 (그림 6)과 같이 표현할 수 있다. 즉 패키지 0 메시지는 서버 개시를 위한 Wap 푸쉬 메시지며 패키지 1, 2 메시지 교환을 통해 클라이언트 인증 및 디바이스 정보를 서버에 전달한다.

신규로 업데이트 할 소프트웨어가 있는 경우 서버는 패키지 4 메시지를 통해서 클라이언트에 다운로드와 업데이트를 원이벤트(Replace)로 처리하는 명령어 (Replace FwPkg/ DownloadandUpdate/ PkgURI)를 송신한다. 이 명령어는 얼터네티브 다운로드 방식의 경우 DM 섭외와 별개로 다운로드 서버의 주소(URI)를 포함한다. 패키지 3는 클라이언트의 서버로부터 메시지 실행에 대한 응답이며 정상적인 경우 200 코드를 서버로 전송한다.

이후 클라이언트는 다운로드 서버에 접속하여 DD(Download Descriptor)를 수신하고 사용자 인터페이스를 통해서 업데이트 정보를 사용자에게 알려주며 업데이트 패키지 다운로드를 개시한다. 다운로드 완료 후 업데이트를 개시하고 업데이트 결과를 다시 패키지 1, 2의 인증절차를 거쳐서 서버에 전송한다.

스마트 게이트웨이 기술

과거 모바일이 주요 대상이었던 기기 관리 기술을 스마트카 및 사물인터넷 기기용으로 확대 적용하기 위해 가장 필요한 것은 스마트 게이트웨이 기술이다. 스마트 게이트웨이는 궁극적으로 모든 사물인터넷 기기를 서버에 연결하기 위한 연결성(Connectivity)을 제공하고자 하는 기술이다. 서비스 관점에서 센서 데이터 수집 및 분석을 주목적으로 하는 데이터 관리(Data Management)와 FOTA와 같은 기기 관리 기능 또한 동시에 제공한다.
 

LwM2M에 기반한 스마트 게이트웨이는 (그림 7)과 같이 나타낼 수 있다. 기존의 센서 및 저사양 소물기기를 유무선 I/O를 통해서 표준형 리소스를 구성하여 서버에 전달한다. 센서 데이터 모니터링 같은 데이터 관리 기능을 수행할 수 있다. CoAP 기반 SDK를 사물인터넷 기기에 포팅하면 데이터 관리 및 기기 관리의 양방향 서비스 구축이 가능하다.

또한 스마트 게이트웨이는 서로 다른 프로토콜을 사용하는 사물인터넷 기기들을 LwM2M으로 변환하여 서버에 연결하는 기능도 제공한다. 헬스케어용 기기(Public Heath Device, PHD)를 예로 들어보자. 헬스케어용 기기로는 주로 Continua 프로토콜 기반 BLE 및 X73 기기 혹은 OCF 표준 기반 기기가 사용된다.

 

이들 헬스케어용 기기들은 스마트 게이트웨이를 통해 LwM2M 서버 플랫폼에 연결함으로써 양방향 서비스 구축이 기능하다. 스마트 게이트웨이는 이종 프로토콜 기기와의 통신을 통해 관리용 리소스를 구성하는 프로토콜 어댑터와 이를 LwM2M 기반 리소스로 변환해 주는 프록시, 그리고 LwM2M 서버와의 양방향 통신을 수행하는 LwM2M 클라이언트 소프트웨어로 구성된다.

 

예를 들면, (표 1)과 같이 Continua 프로토콜 기반 X73 디바이스의 관리 객체와 리소스는 LwM2M 표준 리소스로 프록시 기능을 통해 변환될 수 있다. 리소스 변환이 가능한 기능은 PHD 소프트웨어의 변경 없이 스마트 게이트웨이를 통해 구현이 가능하다. 하지만 기존에 구현되어 있지 않은 소프트웨어 업데이트 기능과 같은 신규 기기 관리 기능을 추가하기 위해서는 스마트 게이트웨이 구현과 함께 PHD 소프트웨어의 신규 개발이 추가로 필요하다.

 

‘LWM2M 1.0’ 규격에 의하면 스마트 게이트웨이의 디바이스 정보와 펌웨어 업데이트를 위한 객체 ID는 3번과 5번의 싱글 인스턴스(Single Instance)로 각각 정의되어 있다. 하지만 게이트웨이에 연결되는 단말 기기(예를 들면 PHD)를 위한 객체 ID는 정의되어 있지 않다. 따라서 게이트웨이는 물론, 이에 연결된 단말 기기 관리 및 소프트웨어 업데이트를 위해서는 (표 2)와 같이 단말 기기를 위한 별도의 객체 ID가 추가로 표준 규격이나 제조사에 할당 가능한(Vendor Specific) 객체 ID 규격으로 지정할 필요가 있다.

 

(그림 9)를 통해 구체적 사례를 살펴보자. 최근 한컴MDS는 전동블라인드를 LwM2M 플랫폼과 연동시키는 통신 게이트웨이 모듈을 개발했다. OCF 기반 블라인드용 상용 제품을 기존 소프트웨어의 변경없이 LwM2M서버 플랫폼에 연결시키는 게이트웨이 모듈과 OCF 표준 오픈 소스(IoTivity)를 적용한 것이다. 이렇듯 스마트 게이트웨이를 통해 제조사 고유의 소물기기를 소프트웨어의 변경없이 LwM2M서버와 연결할 수 있을 뿐만 아니라, OCF 표준 기반의 기기와도 연동함으로써 원격으로 상태 모니터링, 기기 제어 및 소프트웨어 업데이트 구현이 가능하다.

보안기술

무선 소프트웨어 업데이트를 안전하게 실행하기 위해서는 업데이트 실행 단계별로 통합적인 보안 기술이 필요하다.

- 업데이트 패키지 관련 보안

델타 패키지를 생성하는 툴을 제공하는 솔루션 업체는 고유의 알고리즘을 사용하고 있어 다른 업데이트 에이전트를 통해 업데이트를 수행할 수 없다. 이러한 연관성은 보안 관점에서 큰 장점을 부여한다. 또한 생성된 델타 이미지를 패키징하기 전에 AES, 3DES, DES등과 같은 암호화를 수행할 수 있으며, 패키징 단계에서 CRC(Cyclic Redundancy Check)나 디지털 서명(Digital Signature) 등의 보안을 추가로 구현할 수 있다.

- 네트워크 보안

스마트카 및 사물인터넷 기기용 소프트웨어 업데이트를 위해서는 크게 3가지 네트워크에 대한 보안이 고려되어야 한다. 일반적으로 홈네트워크(Home Network), 라스트마일 네트워크(Last mile network) 혹은 모세혈관 네트워크(Capillary Network)로 불리는 단말 기기와 스마트 게이트웨이간 네트워크, 액세스 네트워크(Access Network)로 불리는 게이트웨이와 업데이트 서버 간 네트워크 및 유저 인터페이스를 위한 서버와 어플리케이션 소프트웨어 간의 보안이 필요하다.

이러한 네트워크 보안을 위해 보통 사용자 로그인 과정을 거치는 인증절차(Authentication) 이외에도 TCP/IP 네트워크에서는 SSL(Secure Socket Layer)에서 발전한 TLS(Transport Layer Security) 보안을 사용했다. 그러나 사물인터넷 기기 응용에 보다 적합한 UDP/IP를 사용하는 네트워크에서는 DTLS(Datagram Transport Layer Security)를 주로 사용한다.

 
LwM2M V1.0 규격은 DTLS를 표준으로 PSK(Pre-Shared Key), RPK(Raw Public Key) 및 X.509 인증 방법의 3가지 방식을 지원한다. LwM2M 클라이언트와 LwM2M서버가 보안 채널을 연결하기 위해서는 보안 관련 정보가 사전에 전달되어야 하는데, 이러한 역할을 부트스트랩 서버가 수행할 수 있다. (그림 10)은 인증서 기반 보안 정보 전달 절차이다. 사전에 부트스트랩 서버와 LwM2M서버 간에는 서버의 인증서를 공유하고 있으며, 이에 대한 비밀 키는 LwM2M서버만 보유한다.

 

클라이언트에는 부트스트랩 서버에 안전하게 연결할 수 있는 기본 정보가 미리 내장되어 있다. 그림에서 0/0 객체가 그것을 나타낸다. 이러한 정보를 이용하여 DTLS 채널을 만든다. 부트스트랩 서버는 이 채널을 통하여 PUT 0/1 메시지를 전송한다. 이 메시지에는 LwM2M서버와 보안 연결을 하는데 필요한 정보를 포함하고 있다.

즉 서버의 URI, 서버와 클라이언트 간에 사용할 인증서와 비밀 키, 서버의 인증서가 전달된다. 부트스트랩 서버는 PUT 1/0 메시지를 통해 서버에 관한 정보(Lifetime 및 Pmin, Pmax 디폴트 값 등)를 클라이언트에게 전달한다. 클라이언트는 이러한 정보를 이용하여 LwM2M서버와 DTLS 보안 채널을 형성하고, 이를 통해 보안 통신을 수행할 수 있다.



- 데이터 보안 및 보안 키 관리

안전한 무선 소프트웨어 업데이트를 위해서는 위에서 언급한 보안 방법에 부가하여 단말에 저장된 업데이트 패키지 및 보안 키와 같은 데이터를 안전하게 보관해야 한다. 이를 위해 TPM(Trusted Platform Module) 솔루션과 DTLS 보안 방법으로 가장 많이 사용되는 PSK 방식에서 보안 키를 안전하게 생성, 저장, 분배, 갱신 및 폐기할 수 있도록 부트스트랩 서버와 상용 키 관리 서버와의 연동도 고려되어야 한다.

은행 수준의 보안을 자랑하는 DTLS를 인터넷 주소(IP Address)가 없는 네트워크에서도 적용할 수 있는 기술의 적용도 필요하다.
종래의 무선 소프트웨어 업데이트 솔루션은 TCP/IP 기반의 모바일을 대상으로 소프트웨어 업데이트와 함께 기기 LAW(Lock And Wipe), 하드웨어 제어와 같은 RDM(Remote Device Management) 서비스를 목적으로 운영됐다.

 

최근 무선 소프트웨어 업데이트 솔루션은 스마트카의 엔진제어장치(ECU) 업데이트, 저사양 센서 및 가전 기기를 포함한 사물인터넷 기기 등으로 적용 대상을 확대하며 새로운 국면을 맞이하고 있다. 데이터 관리 위주의 기존 기술에 기기 관리 기능을 동시에 제공 가능한 표준 플랫폼 기술, 기존 사물인터넷 기기, 저사양 소물기기 및 이종 프로토콜을 적용한 다양한 사물인터넷 기기를 서버 플랫폼에 연결시키는 스마트 게이트웨이 기술이 그 해결책으로 떠오르고 있다.

서비스를 안정적으로 제공할 수 있는 통합 보안 기술 역시 개발이 시급하다. 결국 이러한 솔루션들은 급성장하는 사물인터넷 시장 환경에 부합하여 ‘모든 사물인터넷 기기(Any Device)를 서버 플랫폼에 연결하여 원하는 모든 서비스(Any Service)를 구축하는’ 핵심 기반이 될 것이다.