대메뉴 바로가기 본문 바로가기

데이터 기술 자료

데이터 기술 자료 상세보기
제목 윈도우 임베디드 운영체제와 IoT, 그리고 마이크로소프트 애저
등록일 조회수 7090
첨부파일  

MS 윈도우 임베디드와 IoT

윈도우 임베디드 운영체제와 IoT, 그리고 마이크로소프트 애저

이번 시간에는 윈도우 임베디드 운영체제가 사물인터넷(Internet of Things, 이하 IoT)에 대응하는 방법에 대해 알아볼 것이다. 또 마이크로소프트(이하 MS)의 클라우드 서비스인 애저(Azure)를 이용해 IoT 관련 시나리오를 구현할 때의 장점에 대해서도 알아본다.



최근 2년간 IT 업계에서 가장 큰 화두 중에 하나는 IoT다. IoT란 임베디드 기술이 적용된 사물이 네트워크 통신을 통해 상태를 전달하고, 외부 환경에 따라 상태를 변화시키는 기술을 말한다. 예를 들어, IoT 기술이 적용된 스마트홈 시스템은 집 내부의 상태(온도, 습도, 조도 등)를 감지하고, 이 정보를 네트워크로 외부에 있는 집주인에게 알려준다. 그러면 집주인은 보일러, 정수기, 전기밥솥을 원격지에서 가동할 수 있다. 정리하면, 기존의 전자 기기나 보일러 등 집안에 존재하는 기기에 인터넷을 연결하고 사용자가 언제 어디서든지 해당 기기들과 소통할 수 있다는 게 IoT의 기본 개념이다.



왜 IoT인가?

IoT 기술의 응용 분야는 굉장히 방대하다. 스마트 공장, 스마트 도시, 의료 기기 등 데이터를 실시간으로 수집해 응용할 수 있는 분야는 대단히 많다. 이는 다양한 분야에 응용될 새로운 IoT 기기를 양산할 기회가 열림을 의미한다. IoT 시장이 주목받는 이유도 이 때문이다. 해외 여러 유명 조사 기관에서는 2020년에 IoT 관련 기기의 수가 200억대 이상 존재할 것으로 예측한다. 이 200억대가 넘는 기기는 스마트폰 시장처럼 소수 제조 업체에만 해당하는 것은 아니다. 스마트폰 시장과 다르게 IoT 기기 시장은 모든 제조사에 열려있다는 점에서 의미하는 바가 남다르다.

서버와 클라우드 업체들도 IoT에 귀를 기울이고 있다. 200억대의 기기가 서로 통신하기 위해서는 서버, 클라우드에 연결해야 하기 때문이다. 서버를 통해 기기를 연결하고 메시지를 주고받을 수 있도록 할 수 있으며, 여러 웹서비스와 연결해 데이터를 가공하는 등 200억대의 기기를 연동하는 시장 또한 잠재력이 크다고 할 수 있다.

IoT 시스템에 적용할 수 있는 IT는 크게 사물에 적용하는 클라이언트 관련 기술과 서버에 적용하는 서버 관련 기술로 나뉜다. 사물에 OS를 탑재하는 임베디드 기술, 환경의 데이터를 수집하는 센서 기술을 비롯해 해당 데이터를 내·외부의 서버 환경으로 전송하기 위한 네트워크 통신 기술 등이 사물에 적용할 수 있는 클라이언트 관련 기술이다. 서버 관련 기술에는 데이터 수집 기술, 데이터 분석 및 가공 기술, 여러 웹서비스와의 연동 기술 등이 있다.



마이크로소프트의 IoT 플랫폼 전략

마이크로소프트(이하 MS)는 지난 수년간 OS를 개발해 온 업체다. 그러다 새로운 리더로 사티야 나델라 CEO가 부임하면서 변화하는 모습을 보이고 있다. 그는 ‘모바일, 클라우드 퍼스트’라는 슬로건 아래 OS를 경량화하고 멀티 플랫폼을 지원하는 클라이언트 전략을 내세웠다. 더불어 클라우드 플랫폼의 서비스 기술에도 많이 투자하고 있다. IoT 플랫폼은 크게 사물(클라이언트)과 서버(클라우드)로 나뉜다. 임베디드 기술 즉, 사물에 OS 기술이 들어갈 수 있는 클라이언트 플랫폼과 이 클라이언트에 메시지 처리, 데이터 수집 등을 연동할 수 있는 클라우드 플랫폼이 IoT 플랫폼이라 할 수 있다.



MS는 윈도우 임베디드 OS를 통해 IoT 클라이언트 기기 개발을 지원해 왔다. 최근에는 윈도우10을 발표하면서 윈도우10 IoT 플랫폼도 공개했다. 최신 IoT 트렌드를 반영한 새로운 OS를 발표하고 좀 더 다양한 IoT 시나리오를 염두에 두고 있다. 클라우드 플랫폼은 마이크로소프트 애저(Microsoft Azure)를 통해 준비해 왔다. 애저의 솔루션은 하루가 다르게 발전하고 있다. 애저를 사용하기 위해 포털에 들어가면 새로운 기능들이 계속 추가되는 것을 확인할 수 있다. 이를 통해 MS가 애저에 대규모 투자를 지속하고 있음을 알 수 있다. MS는 윈도우10 IoT 플랫폼과 윈도우 임베디드 기반의 플랫폼으로 IoT의 클라이언트 플랫폼을, 클라우드 시장은 애저를 이용해 공략하는 전략을 취하고 있다. 이를 통해 클라이언트와 클라우드 시장을 모두 섭렵하려 하고 있다.



IoT 클라우드 플랫폼

IoT를 언급할 때 빼놓지 않고 등장하는 단어가 클라우드다. 애저나 아마존의 AWS(Amazon Web Service) 같은 클라우드 시스템이 IoT와 어떤 연관이 있을까? 200억대의 기기로부터 생성되는 데이터를 지금의 회사들이 운영하는 서버에 담기는 부족할 수 있다. 또한 클라우드의 가장 큰 특징인 ‘온디맨드(On demand)’ 즉, 필요할 때만 서버를 구동할 수 있는 점에 주목해보자.

IoT 시장에서 기기를 만드는 제조사들은 서버의 구축과 운용에 대한 고민을 클라우드로 덜 수 있다. 이를 통해 서비스를 실행할 기기의 디자인과 생산성에 좀 더 집중할 수 있다. 그리고 IoT 시장은 아직 성숙한 시장이 아니다. 시장이 성숙해지기까지 많은 변화가 있을 수 있다. 얼마나 많은 기기를 생산해야 하고, 어떤 데이터를 수집해야 하는지 가늠하기 쉽지 않을 뿐 아니라 시시각각 데이터 수집에 대한 요구사항도 바뀔 수 있다. 서버 구축에 대한 위험 부담을 클라우드 전문 업체에 넘기고 필요할 때 서버를 가동하는 온디맨드 특징을 감안하면 IoT의 백엔드 서버는 클라우드가 적격이다.

MS는 애저에 다양한 기능을 추가함으로써 여러 웹서비스와 빅데이터, IoT 시장으로의 진출을 꾀하고 있다. IoT 기기들이 애저의 클라우드 서버와 메시지를 주고받고, 수집된 데이터는 애저에 저장된다. 데이터 분석도 애저 위에서 진행되며, Power BI를 활용한 데이터 시각화 등 여러 가지 IoT 서비스 스택을 제공한다.



클라우드 컴퓨팅 시스템의 메시지 처리

멀티 프로세싱을 지원하는 컴퓨팅 시스템에서 중요한 부분 중 하나는 메시지 처리이다. 멀티 프로세싱 시스템에서는 여러 프로세스, 스레드가 동시에 구동되면서 커널에 프로세스 진행 상태와 중단/완료 여부를 전달한다. 윈도우에서는 스레드, 메시지, 메모리 공유에 관한 API를 제공해 여러 프로세스가 데이터 손실 없이 원활하게 구동되도록 한다.



IoT 시스템도 여러 기기와 클라우드가 연동되는 거대한 멀티 프로세싱 시스템이라고 할 수 있다. 여러 IoT 기기를 프로세스와 스레드로, 클라우드를 커널로 가정하면 이 두 분류 간에 빠르고 안정적인 통신이 이뤄져야 비로소 멀티 프로세싱을 지원하는 컴퓨팅 시스템이라 할 수 있다. 빠르고 안정적인 메시지 통신은 클라이언트 기기가 서버의 여러 서비스를 사용할 수 있도록 하는 중요한 전제 조건이다.



IoT의 메시지 패턴

IoT 기기와 서버가 통신하면서 발생할 수 있는 메시지 패턴은 크게 네 가지다. Telemetry, Inquire, Command, Notification이 그것이다. Telemetry는 기기가 조건 없이 지속적으로 서버에 데이터를 보내는 메시지 타입이고, Inquire는 기기가 서버로부터 특정 데이터를 요청하는 메시지 타입이다.

들면 어제의 평균 온도가 어떻게 되는지 기기 단에서 서버로 요청하는 것이 이에 해당한다.
Command는 여러 IoT 기기에 사용자가 명령을 내리는 메시지 패턴이다.

이를 이용해 전기밥솥에 요리를 실행하거나 전구의 불을 끌 수 있다. Notification은 Telemetry와 비슷하나, 어떤 조건이 있을 때만 메시지를 전달하는 패턴이다.



메시지 패턴 구현을 위한 애저 서비스 버스

애저는 서비스 버스라는 메시지 서비스를 제공한다. 이 메시지 서비스를 이용하면 클라우드와 기기에 좀 더 탄력적인 메시지 서비스를 운용할 수 있고, 클라이언트 기기에서 발생할 수 있는 폴링 기법으로 인한 과부하를 피할 수 있다. 또한, 세계 어디에나 1초 미만의 응답시간으로 수백 만개의 IoT 기기들을 연결할 수 있다.

애저의 서비스 버스를 이용하면 IoT 기기에서 발생할 수 있는 상위 네 가지 메시지 패턴을 구현할 수 있다. 서비스 버스의 이벤트 허브를 이용하면 많은 양의 데이터를 처리할 수 있는 Telemetry 패턴을 구현할 수 있다. 이벤트 허브는 Telemetry에 최적화된 메시지 브로커 역할을 하며, 1초당 1GB의 데이터양을 견뎌내도록 디자인됐다. 그리고 Queue나 Topic의 서비스 버스를 이용하면 Inquire, Command 패턴 구현이 가능하다. 그중 Topic은 Pub/Sub의 모델로 서버에 등록된 IoT 기기들의 데이터를 받고 명령을 내리는 데 유용한 서비스다.



HTTP보다 가벼운 AMQP 프로토콜

인터넷 통신 프로토콜 중 가장 흔한 프로토콜이 HTTP이다. 흔히 인터넷을 사용할 때 클라이언트와 서버 간 통신을 위해 사용하는 프로토콜이다. 요즘 IoT 시장은 프로토콜 전쟁이라는 말이 있다. 이는 HTTP가 기존 인터넷 환경보다 통신이 잦은 IoT 시장에 적합한 프로토콜인지를 되묻게 한다.

IoT 프로토콜 전쟁에서 자주 언급되는 프로토콜 중에 하나인 AMQP는 HTTP보다 작은 사이즈의 바이너리로 통신한다. 그 때문에 보다 안정적이고 유연한 통신이 가능하다. HTTP는 소켓당 하나의 연결을 지원하고 데이터를 잃을 수 있는 펜딩 오퍼레이션이 있다. 반면에 AMQP는 소켓당 여러 연결을 지원하고 연결을 세션으로 관리해 좀 더 유연하게 통신할 수 있다. AMQP는 오픈소스 플랫폼이며, 현재 OASIS, ISO 표준으로 등록돼 있다. 안정적인 통신이 필요한 금융권에서 많이 사용되고 있는 것을 보면 표준화된 안정적인 프로토콜이라는 것을 알 수 있다. 애저의 서비스 버스는 HTTP, AMQP 프로토콜을 지원한다. IoT 기기가 HTTP나 AMQP 프로토콜을 사용해 데이터를 전송하면 애저에서 데이터를 처리할 수 있다.



IoT 클라이언트 기기 전략

IoT의 클라이언트 기기들은 무엇이 있을까? 우선 라즈베리파이, 아두이노와 같이 데이터를 수집하고 클라우드에 전송하는 임베디드 기기들이 있다. 사용자가 데이터를 받고 기기에 명령할 수 있는 스마트폰, 태블릿 같은 기기도 있다. 마이크로소프트는 지난 20여년간 x86과 ARM 아키텍처 기반의 임베디드 기기를 지원하고자 윈도우 임베디드 플랫폼을 발전시켜 왔다. 윈도우 임베디드 플랫폼에는 데스크탑과 커널 구조가 같은 Windows Embedded Standard/Industry가 있다. 또 ARM과 x86을 지원하기 위해 산업용 경량화 커널로 설계된 Windows Embedded Compact(기존 WinCE, 이하 WEC) 제품이 있다. 두 모델의 커널로 파생되는 임베디드 OS로 Windows Embedded Handheld(기존 Windows Mobile, 이하 WEHH )가 있다. 많은 산업용 장비에 윈도우 임베디드 OS가 광범위하게 사용되고 있다.

이미 많은 임베디드 장비나 기기에 윈도우 임베디드 OS가 탑재돼 있다. 이 기기들에 센서를 연결하고, 서버/클라우드 플랫폼에 메시지 처리를 위한 부분을 구현하면 IoT 기기로 재구성되는 셈이다.





윈도우 임베디드에서 AMQP로 애저와 통신하기

IoT 기기들은 x86과 ARM 아키텍처가 모두 사용된다. 이처럼 IoT는 이기종 코어가 사용되는 시장이다. 만약 IoT 기기가 인터넷을 통해 애저의 서비스 버스와 연결되고 AMQP까지 지원하면 클라우드 플랫폼과 안정적으로 연동되는 진정한 IoT 기기로 거듭날 수 있다. MS의 기본 OS에서는 AMQP를 사용할 수 있다. 데스크톱과 커널 구조가 같은 Windows Embedded Standard/Industry나 윈도우10 기반 IoT 플랫폼에서는 비주얼 스튜디오(Visual Studio) 프로젝트에 통신 타입을 AMQP로 설정하면 된다. 그러면 기존 프로그래밍 방법으로 애저 서비스 버스와 AMQP로 통신할 수 있다.



만약 생산하는 기기나 필드에서 동작 중인 기기가 데스크톱과 커널 구조가 같은 Windows Embedded Standard/Industry라면 AMQP를 별 무리 없이 사용할 수 있다. 그렇다면 데스크톱 커널이 아닌 WEC 기반의 기기에서는 AMQP를 어떻게 사용할 수 있을까? MS의 코드 공유 페이지인 CodePlex에 공개된 AMQP.Net Lite 프로젝트를 사용하면 WEC, .NETMF 기반의 소형기기에서 AMQP를 사용해 애저 서비스 버스와 메시지를 주고받을 수 있다. AMQP.Net Lite는 C# 기반의 오픈 프로젝트이므로 라이브러리를 수정할 수도 있다.



AMQP.Net Lite로 애저 서비스 버스 토픽 연결하기

클라이언트 기기 프로그래밍에 앞서 클라이언트로부터 메시지를 전송받을 애저 서비스 버스 토픽(Topic)을 생성해 보도록 하자. 서비스 버스의 토픽을 활용해 기기에서 데이터를 전송받아 기기의 상태나 기기와 연동되는 센서들의 상태 값을 전송(Telemetry)받을 수 있다. 그뿐만 아니라 토픽을 활용해 기기에 특정 명령(Command)을 수행하게 할 수도 있다. <그림 6>의 서비스 버스 토픽 생성 예에서는 in/t0000 경로를 통해 등록된 기기에 명령(Command)을 실행해 특정 행위를 하도록 한다. out/t0000을 통해 상태를 주기적으로 전달하는 Telemetry를 실행해 기기의 상태를 주기적으로 전달할 것이다.



애저에 토픽을 생산하고 토픽에 메시지를 전송할 WEC, .NETMF 기기에 AMQP.Net Lite 라이브러리를 활용하면 AMQP의 안정적이고 가벼운 프로토콜을 활용해 애저의 서비스 버스 토픽과 통신할 수 있다. Address 클래스를 생성할 때 매개변수의 문자열은 서비스 버스의 토픽에 접근하기 위한 사용자 이름, 사용자 이름에 대한 키 값, 도메인 주소에 대한 값들이다. 이 값들은 애저 포탈에서 확인할 수 있다.

Address, Connection, Session 클래스들로 기기와 서비스 버스의 토픽에 연결하면 SenderLink와 ReceiverLink를 통해 자유로운 메시지 처리가 가능하다. 웹사이트의 대시보드나 모바일 기기로 클라이언트 기기의 상태를 확인하는 것은 out/t0000 경로를 통해 가능하다. in/t0000 경로를 통해 특정 기기에 명령도 내릴 수 있다. 윈도우 임베디드 기기와 애저 서??시지 서비스를 구현할 수 있다. 상태 확인이나 세계 어디서든 1초 미만의 응답시간으로 명령을 내릴 수 있는 메시지 서비스 구현이 가능한 것이다.



<리스트 1> AMQP.Net Lite를 활용한 서비스 버스 토픽 통신 방법 Address address = new Address(string.Format("amqps://{0}:{1}@{2}:5671/", HttpUtility.UrlEncode(username), HttpUtility.UrlEncode(password), hostname)); Connection connection = new Connection(address); Session session = new Session(connection); SenderLink sender = new SenderLink(session, "send=link", "out/t0000"); ReceiverLink receiver = new ReceiverLink( session, "receive-link", "in/t0000/Subscriptions/LastValue");



애저의 다른 IoT 스택 연동

IoT의 클라이언트 기기들에서 애저의 서비스 버스와 연동할 준비가 됐다면 애저의 다른 IoT 스택들을 쉽게 활용할 수 있다. 애저의 이벤트 허브를 통해 토픽보다 더 많은 기기에서의 데이터 전송을 구현할 수 있고, 이벤트 허브에 쌓이는 대용량 데이터를 실시간 분석(Stream Analytics)으로 필터링할 수 있다. 애저의 IoT 스택을 이용한다는 것은 클라이언트 기기들과 애저가 연동하는 것을 의미한다. 클라이언트와 클라우드 연동의 중심에는 실시간성과 안정적인 메시지 처리를 지원하는 서비스 버스가 있다.





윈도우10 IoT 플랫폼

MS의 Build 2015 행사에서 윈도우10 기반의 IoT 플랫폼이 공개됐다. 이는 윈도우10 기반 커널에 새로운 IoT 구현 트렌드를 적용한 윈도우 임베디드의 차세대 버전이라고 할 수 있다. 윈도우10 기반 IoT 플랫폼은 크게 세 가지로 구분되며 엔터프라이즈, 모바일, 코어로 불린다. 이 플랫폼들은 x86과 ARM 아키텍처를 지원하면서 같은 윈도우10 커널을 사용한다. 같은 커널을 사용하므로 앱(유니버설 앱)과 드라이버(유니버설 드라이버)도 공유한다. 이는 그동안 마이크로소프트 임베디드 OS 안에서도 완벽히 지원되지 않았던 OS 커널 통합이 이루어진 것이다. 앱/드라이버 개발자는 생산성 측면에서 많은 이득을 볼 것으로 생각된다.





마치며

요즘 IoT 기술을 통해 무엇인가를 해보려는 업체들이 참 많다. IoT가 IT 업계의 큰 화두라는 것을 피부로 쉽게 느낄 수 있다. 많은 업체가 IoT를 활용한 여러 가지 시나리오를 구상 중이다. IoT 관련 시나리오는 결국 어떤 플랫폼으로 어떻게 구현하느냐가 프로젝트를 성공으로 이끄는 핵심이다. x86과 ARM 아키텍처 그리고 MCU까지 모든 플랫폼을 아우르는 MS의 윈도우 임베디드, 윈도우 IoT 플랫폼으로 IoT 클라이언트 기기 전략을 세우고, 애저의 서비스 버스, 이벤트 허브, 실시간 분석 등의 IoT 스택으로 IoT 클라우드 전략을 세우면 IoT 시나리오를 안정적이고 쉽게 구현할 수 있을 것으로 기대된다.



애저 토픽 생성해 Pub/Sub 통신 구현하기

1. 토픽 사용을 위한 준비
애저 홈페이지(www.microsoftazure.com)에서 무료 평가판을 신청하면 바로 사용이 가능하다. 애저 포탈에서 서비스 버스(Service bus)를 선택한 후 고유의 네임 스페이스를 설정해 보자(예 : servicebustest-ns).

2. 애저 토픽 생성하기
비주얼 스튜디오 2013(이하 VS 2013)의 메뉴에서 View → Server Explorer를 통해 애저 계정으로 접속해 보자. 접속하면 본인의 계정 정보를 확인할 수 있고 VS 2013의 Server Explorer를 사용해 토픽을 생성할 수 있다. 애저 포털에서 생성한 서비스 버스의 네임스페이스를 Server Explorer에서 확인하고, Topics에 마우스 오른쪽 번튼을 클릭해 새로운 토픽을 생성한다.





생성된 in/t0000에 새로운 Subscription을 생성할 수 있다. in/t0000에 마우스 오른쪽 버튼을 클릭해 새로운 Subscription인 LastValue를 생성한다. 게이트웨이 디바이스(t0000)는 LastValue를 Receiver로 사용해 Command를 실행한다.



게이트웨이 디바이스로(t0000)부터 생성되는 데이터를 모니터링하기 위한 토픽인 out/t0000을 만들고 2개의 Subscription(WEC2013, WES)을 추가한다. 추가된 Subscription을 이용해 디바이스, 웹사이트를 통해 데이터를 모니터링할 수 있다.



3. 애저 토픽으로 데이터 주고 받기
구성된 토픽을 통해 게이트웨이 디바이스(t0000)에서 out/t0000으로 데이터를 주기적으로 보낼 수 있다(Telemetry). 그리고 WES2013이나 WES로 등록된 디바이스를 통해 관리자가 t0000의 상태를 실시간으로 확인할 수 있고, in/t0000/Subscriptions/LastValue를 이용해 t0000의 디바이스에 명령을 내릴 수도 있다. 게이트웨이의 수가 늘어나면 t0001부터 n까지 숫자를 늘려 디바이스를 관리할 수 있다.



게이트웨이 디바이스(t0000)에서는 AMQP.Net Lite를 활용해 SenderLink와 RecieverLink 로 데이트를 송수신할 수 있다.

SenderLink와 RecieverLink의 데이터 송수신 SenderLink sender = new SenderLink(session, "send=link", "out/t0000"); ReceiverLink receiver = new ReceiverLink( session, "receive-link", "in/t0000/Subscriptions/LastValue");





출처 : 마이크로소프트웨어 7월호

제공 : 데이터 전문가 지식포털 DBguide.net