2016
임베디드월드


글: 한상호 차장, 윈드리버코리아 / 2016-07-27


최태우 기자 desk@epnc.co.kr




산업용 사물인터넷(Industrial Internet of Things) 애플리케이션과 시스템을 위한 테스팅 소프트웨어의 개발과 구성은 쉬운 일이 아니다. 시스템은 물리적으로도 그 규모가 크고, 수백 또는 수천 개의 노드를 포함하는 경우가 많아 실제 개발 환경에서 관리하기가 쉽지 않는다.


수천 개 노드 간에 실행되는 소프트웨어를 테스트하려면, 테스트를 자동화하고, 검사하고, 제어할 수 있는 기능이 필요하지만 방대한 규모의 실제 기기를 대상으로 테스트를 자동화하는 것은 어려운 일이다.



이러한 문제는 가상플랫폼(Virtual platforms)과 무선 네트워크 및 환경에 대한 시뮬레이션을 통해 극복할 수 있다. 이를 통해 하드웨어를 소프트웨어 시뮬레이션으로 전환해 쉽게 하드웨어를 생성하고 구성하고, 제어할 수 있다. 지난 호에 이어 이번 호에서는 보안·인증과 구현 환경과 개발 도구에 대해 알아보겠다.



보안과 인증 
보안은 모든 IoT 시스템의 아주 중요한 부분이며 반드시 주기적으로 테스트를 진행해야 하는 대상이다. 새로운 디바이스의 추가와 이전 디바이스의 폐기를 위한 메커니즘도 테스팅에 포함되어야 한다.


신뢰할 수 있는 디바이스의 멤버십을 관리하는 것이 IoT 보안의 중요 문제 중 하나이다. 네트워크 수준의 공격에 시스템이 견고한지 살펴보아야 하고, 노드와 게이트웨이의 취약점도 평가해야 한다. 


새 노드 추가와 인증 메커니즘 테스트를 위해 노드를 빠르게 정상 상태로 되돌리는 것도 시뮬레이션을 통해 가능하다.


실제 하드웨어에서는 테스트 전에 아주 조심스럽게 이전 테스트의 결과를 지우거나 초기화해야 이후 테스트에 영향을 미치지 않도록 할 수 있다. 하지만 시뮬레이션에서는 모든 테스트를 초기 상태에서 시작하고, 이전 테스트의 결과가 영향을 주는 현상을 막을 수 있다. 


시뮬레이션을 통해 노드를 네트워크 테스팅 도구나 퍼저(Fuzzer)에 연결하고 이러한 테스팅의 결과를 기록하거나 반복할 수 있다. 물론 다른 기기에 영향을 주거나 외부 무선 네트워크로의 유출은 걱정하지 않아도 된다. 이미 설명했듯이 새 소프트웨어가 출시될 때마다 동시에 자동으로 테스트할 수 있다. 



실제 세계와 환경 
IoT는 컴퓨터가 물리적 세계를 감지하고 제어하기 위해 인터페이싱하는 것을 기본으로 한다. 실제 세계와 상호 작용하는 소프트웨어를 테스트하려면 센서에 데이터를 보내고 엑큐에이터에 결과물을 보낼 곳이 필요하다. 


물리적 하드웨어를 사용한 테스트의 경우는 실제 센서에 조절 가능한 방식으로 물리적 입력을 제공하는 것이 매우 어려우므로 입력 및 출력 시스템을 이와 동일한 시스템에서 실행되는 간단한 소프트웨어로 교체하곤 한다.


실제 입력 및 출력을 외부 세계의 디지털 시뮬레이션에 연결하는 경우도 있지만 이렇게 하려면 규모가 크고 고가의 사용자 지정 설정이 필요하다. 


하지만 시뮬레이션에서는 실제 환경을 시뮬레이션된 제어 시스템에 아주 편리하게 제공할 수 있다. 시뮬레이션에서 실행되는 대상 소프트웨어의 관점에서 보면 아날로그-디지털 컨버터(ADC, Analog-to-digital converters), 디지털-아날로그 컨버터DAC (Digital-to-analog converters), 범용 I/O(GPIO, General-purpose I/O) 등과 같은 외부 세계의 물리적 하드웨어와 상호 작용하는 것과 동일한 하드웨어 인터페이스를 사용하는 것이다.


이러한 디바이스는 실제 세계의 시뮬레이션으로 연결된다. 또는 호스트 머신의 실제 외부 물리적 환경를 통해 연결될 수도 있다.


물리적인 시뮬레이션은 입력으로 제공되는 값의 스크립트 목록일 수도 있고 실제 세계의 동적인 시뮬레이션일 수도 있다. 실제 환경에 대한 시뮬레이션을 사용하는 가장 큰 혜택은 서로 다른 다양한 실제 상황에 대한 코드 경로를 테스트하기 위해 다양한 상황과 조건을 변경할 수 있다는 점이다.


예를 들어 실제 화재가 발생한 상황이 아니더라도, 화재 알람을 울릴 수 있는 자극을 만들어 알람을 울릴 수 있다. 에어컨을 더운 날씨에서만이 아니라 추운 날씨에서도 작동시킬 수 있다. 특정한 날씨가 되도록 기다릴 필요가 없으며, 원하는 조건을 만들기 위해 장비를 사용할 필요도 없다. 


따라서 시뮬레이션된 조건은 IoT 테스팅을 위한 중요한 소스가 되며, 조건 시뮬레이션은 그림 2와 같이 테스팅 솔루션의 중요한 부분이 된다. 


시스템의 서버 부분은 외부 환경 또는 시장, 대규모의 환경과 연결된다. 이 경우 스크립트로 작성된 폐쇄 루프 제어 실험을 위해서는 이 역시 시뮬레이션하는 것도 좋은 방법이다. 예를 들어, 현재 시장 정보나 날씨 데이터를 사용하는 대신 역사 속 흥미로운 지점의 데이터를 대신 사용해 보는 것도 가능하다. 


또한 외부 세계를 시뮬레이션하면 즉석으로 동적인 결과를 만들어낼 수 있다. 대규모의 외부 환경과의 교류는 일반적으로 웹 기반의 서비스 인터페이스나 데이터베이스 API 형식으로 이루어지므로, 외부 네트워크 기능으로 시뮬레이션해야 한다. 서버 쪽은 실제 세계와 직접적으로 상호 작용하지 않으므로, 센서 수준의 시뮬레이션은 필요하지 않는다. 



개발 도구 
IoT 시스템 자체를 테스트하는 것 외에 시뮬레이션은 시스템의 구성과 디버깅을 촉진하는 기존 개발 도구와의 인터페이스에도 사용할 수 있다. 예를 들어 노드의 USB 연결은 호스트에 노출될 수 있으며, 동일한 도구로 연결하면 실제 노드에 연결될 수 있다.


실제 세계의 네트워크 연결은 노드와 게이트웨이에 다양한 기존 디버그 및 분석 도구를 연결하는데 사용할 수 있다. 시뮬레이션된 IoT 시스템을 실제 세계에 연결하여 가치를 추가하고 시뮬레이션된 시스템으로 기존 도구와 워크플로를 재사용할 수 있는 많은 경우가 있다.



그림 5. 노드와 게이트웨이 시뮬레이션.

시연 
시뮬레이션은 IoT 소프트웨어와 시스템을 시연하는 데에도 사용할 수 있다. 클라우드 서버에서 호스팅하는 작은 규모의 IoT 네트워크를 통해 서버 쪽 소프트웨어를 고객에게 시연하는 많은 팀을 보아 왔다.


네트워크 장비를 들고 다니거나 원격 연구 네트워크를 사무실에서 호스팅하는 것보다, 각자 영업 사원이 자신의 작은 IoT 시스템을 꺼내어 시연을 위해 사용하는 것이다. 공유 리소스에 대한 액세스 동기화나 다른 사람이 실수로 시연 환경을 망치는 것을 걱정을 할 필요가 없다.



디버그 
모든 테스트는 디버그로 이어진다. 테스트에 시뮬레이터를 활용하는 것은 디버그에도 도움이 된다. 먼저, 체크 포인트 및 기록-재현을 통해 문제를 잡아내고 전달할 수 있다.


예기치 못하거나 잘못된 결과가 시뮬레이션된 테스트 실행에서 탐지되면, 이를 저장하여 엔지니어링 환경에서 재현, 실패한 테스트 사례를 쉽게 만들 수 있다. 버그의 재현이 더 쉽기 때문에 문제를 해결할 가능성도 커지는 것이다.


개발 중에 문제가 재현되면 시뮬레이터를 사용하여 시스템을 디버깅하는 것이 더 유용하다. 특히 노드의 수가 적은 시스템의 경우, 시뮬레이션을 사용하면 실제 현장의 어딘가에 있는 특정 노드로의 물리적 연결에 걱정할 필요 없이 모든 노드의 모든 상태에 액세스할 수 있다. 시뮬레이션에서는 전체 시스템을 즉시 중단하고, 중단된 상태에서 상태를 점검할 수도 있다. 디버그를 위해 액세스할 수 있는 상태에는 하드웨어와 소프트웨어가 모두 포함된다. 



노드와 게이트웨이 시뮬레이션 
지금까지 테스트하려는 내용과 테스트에 시뮬레이션이 어떤 도움이 되는지 살펴보았다. 이제 방대한 IoT 시스템에서 고려할 수 있는 유용한 시뮬레이션 방안에 대해 알아보겠다.


제안하는 IoT 시뮬레이션의 시작점은 개별 게이트웨이와 노드, 때로는 서버에 대한 빠른 트랜잭션 수준 가상 플랫폼을 사용하는 것이다. 빠른 가상 플랫폼은 (임베디드) 대상 시스템의 하드웨어를 시뮬레이션하고 실제 시스템에서 실행되는 동일한 바이너리를 실행한다.


설명을 위해 여기서는 Simics 라는 가상 플랫폼 시스템을 사용하겠다. 여기서 설명하는 대부분의 기술은 모든 가상 플랫폼 도구에 적용할 수 있으며, IoT 시뮬레이션 스타일도 COOJA와 같은 도구에서 이전에 구현된 바 있다.


그림 5에서 볼 수 있듯이 시뮬레이션은 많은 수의 개별 시스템과 하드웨어로 구성되며 각각 가상 플랫폼을 적용해 시뮬레이션된다. 가상 플랫폼은 프로세서 코어 명령 세트, 디바이스 등록, RAM, ROM, 플래시, 메모리 맵, 인터럽트, 타이머, 주변 디바이스 및 I/O 디바이스의 기능과 같은 대상 소프트웨어에 관련된 실제 시스템을 정확하게 모델링한다.


가상 플랫폼의 아키텍처와 하드웨어는 호스트 시스템과 완전히 독립되어 있다. 예를 들어 저렴한 마이크로컨트롤러 ARM Cortex-M 또는 Intel Quark 코어를 위해 컴파일된 코드를 강력한 Intel Xeon 기반 서버에서 실행할 수 있다. 


빠른 가상 플랫폼은 일반적으로 하드웨어와 그 마이크로 아키텍처의 상세한 부분(버스 프로토콜, 클록, 파이프라인, 캐시 등)까지는 모델링하지 않는다. 여기서 설명하는 시뮬레이션은 실제 워크로드에서 실행하기에 충분히 빠르며, 일반적으로 모든 소프트웨어 테스트와 발생 가능한 문제의 80% ~ 95%까지는 포함된다.


이는 여러 프로젝트를 통해 이미 입증되었으며 하드웨어 타이밍을 사이클 기준으로 모델링하지 않고도 소프트웨어가 문제없이 실행되는 시뮬레이션된 디바이스를 개발할 수 있게 된다. 가상 플랫폼은 시간에 민감한 디바이스 드라이버 개발에 적합하며 SoC용 하드웨어 설계 프로젝트의 일부로 제작되기도 한다.


하지만 이러한 정확한 타이밍의 가상 플랫폼은 많은 노드로 확장할 IoT 시스템 테스팅을 위한 시뮬레이션으로 확장하기에는 너무 느리게 실행된다. 방대한 규모의 소프트웨어 및 시스템 테스팅에는 신속하고, 트랜잭션 레벨의 가상 플랫폼이 현명한 대안이 될 수 있다. 


가상 플랫폼에서 실행되는 타깃 소프트웨어에는 낮은 단계의 펌웨어 및 부트 로더, 운영 체제, 드라이버, 미들웨어 및 애플리케이션이 포함된다. 시스템에서 하이퍼바이저나 컨테이너를 사용한다면 이는 플랫폼의 소프트웨어 스택의 일부가 된다.


I/O 디바이스의 드라이버도 설정의 일부이며, 센서 및 엑츄에이터는 자체 소프트웨어 표시 인터페이스(메모리가 매핑된 레지스터, 인터럽트, DMA; Direct memory access)의 시뮬레이션으로 표현된다. 


그림 5를 보면 단일 시뮬레이션에서 여러 보드를 실행하고 이를 네트워크로 연결할 수 있다. 가상 플랫폼을 네트워크나 다른 시뮬레이터를 통한 통합을 통해 외부 세계에 연결할 수 있다. 


실제 세계에 연결하면 실제 노드의 소프트웨어를 통해 기존 소프트웨어 테스팅 인프라와 시스템을 재사용할 수 있다.매우 방대한 수의 노드를 자동으로 테스팅할 수 있다는 점은 오직 시뮬레이션을 통해서만 가능한 것이다. 실제 시스템에서는 현실적으로 불가능한 작업이다. 



실제 환경의 시뮬레이션 
실제 환경의 시뮬레이션은 보통 대상 시스템의 컴퓨터 시스템에 사용되는 가상 플랫폼과는 다른 기술을 사용하여 수행된다. C, C++, Python, Java와 같은 일반 컴퓨터 언어나 Matlab/Simulink, Labview, Esterel과 같은 모델 기반 접근 방식을 사용하여 작성된 시뮬레이터를 많이 볼 수 있다. 간단한 값의 목록을 센서에 전달할 수도 있다.


피드백이나 액츄에이터의 출력 처리 등은 전혀 없다. 가장 일반적인 경우 제어 시스템은 시간에 따른 입력값 변화를 기준으로 모델링해 시뮬레이션하는 것이 가장 좋다. 테스트 사례와 목적에 따라 다른 수준의 모델링이 사용될 수 있다. 


시뮬레이션은 수행 방법과 관계없이 IoT 노드 시뮬레이터에 연결되어야 한다. 시뮬레이션이 광범위하게, 더 나아가서는 전 세계를 대상으로(많은 노드가 연결된 하나의 실제 시스템을 모델링) 하더라도 이 작업은 각 노드에 대해 수행되어야 한다(그림 5 참조).


또 하나 중요한 것은 시뮬레이션 시간이 IoT 노드 시뮬레이션과 실제 세계의 시뮬레이션 사이에 동기화되어야 한다. 일반적으로 이는 컴퓨터 쪽에서 가상 시간을 시뮬레이션하여 IoT 노드 시뮬레이션 드라이브와 실제 환경 시뮬레이션에 적용하는 방식으로 수행된다.



네트워크 시뮬레이션 
컴퓨터 하드웨어의 가상 플랫폼 시뮬레이션과 마찬가지로, 무선 네트워크의 시뮬레이션 역시 많은 추상화 레벨로 수행 가능하다. 일부 애플리케이션의 경우는 여러 노드가 동시에 데이터를 전송하여 다른 노드의 메시지를 제거하는 등의, 전파의 실제 물리적 특성을 그대로 시뮬레이션하는 것이 중요하다.


하지만 동시 액세스를 올바르게 모델링하고 시뮬레이션하기 위해서는 많은 비용이 투입된다. 시뮬레이션된 모든 노드가 공유 매체의 현재 상태 확인해 자주 동기화해야 하기 때문이다. 때문에 시뮬레이션이 자주 느려지게 된다. 전파의 복잡한 부분 중 또 다른 하나는 노드가 다른 노드에 반응하여 신호 강도에 영향을 미친다는 점이다. 


Simics에서는 물리적 계층을 패킷 수준의 메시지 시스템으로 추상화하는 트랜잭션 기반 네트워크 모델을 통해 확장 가능한 방식의 IEEE 802.15.4 네트워크를 모델링한다.


이 시뮬레이션에서는 전체 패킷을 유닛으로 전송하며 시뮬레이션에 너무 많은 동기화가 발생하지 않도록 하여 동시 및 분산 시뮬레이션으로 확장성을 증가시킬 수 있도록 시스템 소프트웨어의 관련된 가시적 효과만 강조시킨 점이 특징이다.



>그림 6. Simics의 IEEE 802.15.4 네트워크 시뮬레이션.

반대로 Cooja에 사용된 전파 모델은 전송 범위와 동시 전송으로 인한 간섭에 이르기까지 전파 부분에 초점을 맞추고 있다. 유사한 수준의 모델링이 동시 및 분산 DiSens 시뮬레이터에도 사용된다. 두 경우 모두 더 구체적인 전파 모델로 설계되어 낮은 수준의 프로토콜 테스팅에 사용되지만 아주 큰 규모의 네트워크 시뮬레이션에는 적합하지 않는다.


여기서 설명하는 시뮬레이션에서는 낮은 수준의 전파 시스템이 상당히 안정적이라고 가정하고, 시스템의 규모가 커지고 새로운 소프트웨어 기능이 네트워크에 추가됨에 따라 소프트웨어를 테스트하는 것에 초점을 맞춘다.


OMNeT++와 같은 순수 네트워크 시뮬레이터는 한층 더 나아가, 충돌 감지 다중 액세스(CSMA, the collision-sense multiple access) 미디어 액세스(Media access), 클리어 채널 액세스(CCA, Clear channel access) 감지 및 유사 기능도 모델링되어 있다.


이러한 네트워크 시뮬레이터에는 일반적으로 더 높은 수준의 프로토콜이 포함되어 있지만, 여기서는 프로토콜을 노드에서 실행되는 소프트웨어로 간주하여 시스템 테스트의 일부로 이 소프트웨어를 테스트한다.


Zigbee와 6LoWPAN 모두 Simics의 IEEE 802.15.4 네트워크에서 실행되었으며, 프로토콜보다 트래픽 전송을 모델링하는데 적합하다. 추가로 패킷 전송 레벨에서 모델링함으로써Wireshark와 같은 도구로 트래픽을 분석할 수 있다. 실제 네트워크에서 전송되는 것과 같이 패킷을 추적할 수 있는 도구이다.  


그림 6에서 볼 수 있는 이 모델에서 모든 노드는 같은 무선 네트워크에 연결되어 있어 어떤 노드든 다른 모든 노드로 메시지를 보낼 수 있다. 모든 메시지는 네트워크를 통해 유닛(패킷)으로 전달되며 여러 노드에서 메시지가 겹치거나 동시에 보내는 것을 감지하려는 시도는 없다.


이는 유선 네트워크를 위한 표준 방식의 트랜잭션 수준 모델링으로, 무선 네트워크에도 적용할 수 있다. 자체 패킷 부하 외에도 무선 네트워크에서는 사용되는 특정 전파 채널을 추적해야 하며, 발신자에서 수신자로 전송되는 메시지의 신호 강도도 확인해야 한다. 


메시지의 내용은 IEEE 802.15.4 표준에 정의된 내용이다. 네트워크 주소의 관리는 전파 모델(예를 들어 잘못된 수신 주소로 보내는 메시지는 거부)과 소프트웨어에 따르게 된다.


네트워크 시뮬레이션은 단순히 수신할 수 있는 모든 노드로 메시지를 전송하는 것이다. 일반적인 전파 네트워크와 동일한다. 유선 이더넷과 다르게, 올바른 노드만 특정 패킷을 받도록 하는 스위치는 없다. 


특정 채널에서 메시지를 받도록 노드의 전파 수신을 설정하려면 채널 정보가 필요하다. 
신호 강도는 세 가지 목적으로 사용된다. 첫 번째는 수신 노드의 시뮬레이션된 전파 수신기가 어떤 신호 강도를 소프트웨어에 보고해야 하는지 지정하는데 사용된다.


두 번째는 전달 거리를 모델링하는 데 사용된다. 이를 0으로 설정하면 특정 노드가 다른 노드에 도달할 수 없도록 모델링할 수 있다. 세 번째는 시뮬레이션의 특정 수준의 불확실성을 적용하는데 사용된다.


신호 강도를 통해 메시지가 무작위로 누락될 수 있다. 신호 강도가 낮을수록 메시지가 누락될 가능성이 높아진다. 


따라서 신호 강도 매트릭스에 있는 값을 사용하여 설정하면 사용자가 자신이 원하는 전파 시나리오를 모델링할 수 있다. 가상 공간에 노드를 분포시키고 실제 위치를 기반으로 전달 거리를 계산하는데 스크립트나 프로그램을 사용할 수 있으며, 특정 토폴로지를 모델링하기 위해 고정된 설정으로 값을 지정할 수도 있다.


실행하는 동안 신호 강도 값은 무선 환경에서 모델이 변경됨에 따라 바꿀 수 있다. 신호 강도 매트릭스의 저장은 시뮬레이션의 로컬 특성을 극대화하기 위해 각 전송 노드에서 수행되어야 한다. 


마지막으로 임시 간섭(Temporary interference)을 모델링하려면 특정 노드가 메시지를 보내거나 받지 못하도록 차단하면 된다. 해당 노드는 차단이 해제될 때까지 어떤 메시지도 받지 못하며 보내지도 못한다. 간단한 이 메커니즘으로 실제 세계의 많은 개입과 간섭을 모델링할 수 있다. 


이 무선 네트워크 모델은 다른 유형의 무선 네트워크에도 적용할 수 있다. 모든 프로토콜 수준의 처리를 소프트웨어가 담당한다고 가정하고, 패킷 기반의 무선 네트워크에서 전송 계층의 필수 동작을 캡처할 수 있기 때문이다. 



서버 포함 
IoT 시스템의 서버 쪽 테스트는 게이트웨이나 노드의 경우와는 다른 방법으로 수행된다. 서버는 하나의 매우 강력한 시스템이며, 대개 아주 일반적이거나 표준 클라우드에서 실행된다.


따라서 그 하드웨어를 노드와 게이트웨이를 다루는 것처럼 시뮬레이션하면 여러 유형의 테스트가 제대로 이루어질 수 없다. 대신 그림 7에서 볼 수 있는 것처럼 서버는 IoT 시뮬레이션의 외부에 두고 시뮬레이터에 사용되는 실제 환경과의 연결 형태로 유지한다.


실제 운영 서버도 일부 테스팅에 사용할 수 있지만 이는 실제 사용과 테스트 사용을 분리하기 쉬울 경우에만 가능하다. 테스트 데이터나 테스트 구성이 운영 환경으로 실수로 누출되면 매우 심각한 상황이 발생할 수 있기 때문이다. 



그림 7. 서버 테스팅 방식.

대부분의 경우 테스트 서버 설정은 테스트 전용으로만 사용된다. 이는 연구실 네트워크의 내부 서버이거나, 외부 클라우드 기반 서버의 특정 설정을 활용할 수 있다. 테스트 서버는 실제 세계를 시뮬레이션할 수 있는 기능이 있어야 한다. 노드의 시뮬레이션된 실제 I/O와 서버 쪽 실제 환경 조건과 일치해야 한다는 의미이다. 


IoT 노드에서 서버로의 연결을 테스팅하는 또 하나의 대표적인 기술로는 서버에서 제공하는 서비스를 시뮬레이션하는 것으로, 서비스 가상화라고 부른다. 이는 실제 서버를 운영 체제, 데이터베이스, 실제 코드와 함께 설정하지 않고 간단한 시뮬레이션 시스템을 사용하여 노드와 게이트웨이가 수신하는 API만 노출하는 개념이다.


이는 전체 테스트 서버를 실행하는 것보다 훨씬 간단하며 오류를 줄이는 테스트나 서버와의 통신에 특정한 응답을 하는 테스트에 유용하다. 하지만 이 기술은 서비스의 실제 구현을 테스트할 필요가 없을 때만 유용하다. 실제 코드가 아니라 간단한 구현만 사용하기 때문에 실제 사용하는 서버 코드에 대한 상호 작용을 구현할 수 없다.



확장하기 
IoT 테스팅의 고유한 고려사항 중 하나는 수백 수천 개의 노드로 어떻게 시뮬레이션을 확장할 수 있는가 하는 부분이다. 가상 플랫폼과 시뮬레이션 기술은 대부분 개별 머신에 포함된 대상 시스템을 통해 수행되지만, IoT의 경우 그 규모가 훨씬 크기 때문이다.


일반적으로 Simics 가상 플랫폼은 수천 개의 대상 프로세서를 포함하는 큰 규모의 워크로드를 실행하는 데에도 충분히 빠른 것으로 입증됐다. 특히 IoT의 경우 타깃 시스템의 몇 가지 특성으로 인해 시뮬레이션의 속도를 높일 수 있다.


첫 번째는 IoT 노드가 일반적으로 호스트 PC에 비해 저전력, 저속 프로세서 코어를 기반으로 하기 때문이다. 두 번째는 대부분의 IoT 노드가 매우 낮은 작동 주기를 가지기 때문이다. 실제 작업은 수행하는 시간을 짧고, 나머지 대부분의 시간은 주기적 작업을 트리거하는 다음 네트워크 패킷의 수신을 기다리기만 한다. 게이트웨이와 서버는 좀 더 바쁘지만, 노드가 별로 없다면 큰 영향은 없다. 


이렇게 일반적으로 시스템에 유휴 시간이 많지만, 이러한 유휴 시간은 하이퍼 시뮬레이션(Hypersimulation)을 통해 시뮬레이션을 가속화하는데 활용될 수 있다.


사이클 주기로 유휴 시간에 대기하지 않고, Simics와 같은 시뮬레이터는 절전 모드에서 깨어나게 만든 다음 이벤트로 바로 이동한다. 즉 낮은 작동 주기를 가진 노드의 시스템은 아주 적은 호스트 리소스만으로 매우 효율적으로 시뮬레이션할 수 있다는 것이며, 이는 방대한 IoT 시뮬레이션에서는 아주 좋은 효과를 낸다. 


빠른 시뮬레이션을 위해 병행 운영할 수도 있다. 많은 코어를 가진 멀티코어 기기를 효율적으로 사용하면, 시뮬레이션의 속도를 보다 높이고 방대한 네트워크를 효율적으로 시뮬레이션할 수 있다.


병행성을 달성하려면 병행 가능한 가상 플랫폼 시뮬레이터를 확보하는 것과 더불어 네트워크 시뮬레이션에서 개별 노드 시뮬레이션의 느슨한 결합을 허용해야 하며, 물리적인 시뮬레이션에 글로벌 동기화는 필요로하지 않는다. 


이러한 요구 사항들이 충족되면, 그 성능은 탁월한 효과를 낸다. 작성한 테스트 설정을 사용하여 가능한 확장 규모를 측정하기 위한 몇 가지 실험을 해 보았다. 이 설정은 가상 500MHz ARM Cortex-A9 프로세서와 VxWorks 6.9 운영 체제, 매초 작동하는 제어 알고리즘을 사용하는 다소 규모가 있는 IoT 노드를 사용한다. 각 노드에는 로컬 물리 모델이 연결되어 있다.


Wind River Simics(윈드리버 시믹스)에서 이 설정을 사용하여 10개의 호스트 코어만으로 실제보다 두 배 빠른 250개의 노드를 시뮬레이션할 수 있었습다. 수천 개의 노드를 실행하자 시뮬레이션은 느려졌으며, 결과적으로 2배 정도 느린 상태로 종료되었다. 노드를 더 낮은 클록 속도로 설정하면 시뮬레이션의 속도도 역시 저하됐다.



조정과 보정 
테스트가 대부분 시뮬레이션을 통해 수행된다고 하더라도 하드웨어와 그 동작은 여전히 고려 대상이다. 최종 목적은 실제 세계의 하드웨어에서 작동하는 소프트웨어를 제작하는 것이므로, 시뮬레이션은 실제 세계에 적절한 영향을 주도록 보정하고 조정해야 한다.


이러한 조정은 신호 강도의 적절한 범위 값을 설정하거나, 전파 메시지 전송의 대기 시간을 조정하여 대역폭에 영향을 주는 과정으로 이루어진다. 가상 플랫폼이 대상 명령을 처리하는 속도는 실제 하드웨어에서 측정한 평균 명령 시간에 따라 조정할 수 있다.


센서에 사용되는 데이터 값과 물리적인 시뮬레이션의 동작은 해당하는 실제 세계 시나리오에 따라 보정해야 한다. 보정된 동작에서 파생된 결과로 시뮬레이션을 수행해야 하는 경우도 있다. 예를 들어 검사의 목적이 오류 상황, 극한의 상황이나 매우 드문 상황에서의 작동을 살펴보는 것이라면, 평균적인 표준의 경우보다는 다른, 강력한 동작이 필요할 것이다. 



정리 
가상 플랫폼 기반의 트랜잭션 레벨의 시뮬레이션으로 방대한 규모의 IoT 시스템의 테스트를 수행하는 방법에 대해 알아보았다. 목표는 노드, 게이트웨이, 서버의 소프트웨어가 시스템의 관점에서 어떻게 작동하는지 테스트하는 것이다.


시스템 시뮬레이션은 특정 레벨의 추상화를 사용하여, 실제 코드를 사용한 시스템 수준의 테스팅보다 훨씬 빠르게 수행된다. 이를 가능하게 하는 주요 요인은 802.15.4 네트워크의 높은 수준의 모델, 실제 대상 코드를 빠르게 실행할 수 있는 빠른 가상 플랫폼이다.


시뮬레이션을 기반으로 하는 소프트웨어 테스팅은 IoT 시스템의 테스팅 영역을 크게 확장시킨다. 시뮬레이션은 개발 및 지속적 통합 프로세스의 일부로 내부에서 사용될 수도 있고, 소프트웨어를 출시하여 실제 세계에 배포하기 전에 이 소프트웨어가 어떻게 작동할지 예상하기 위한 준비 환경 설정에 적용될 수도 있다.




※ 본 내용은 (주)테크월드(http://www.ibeddedworld.co.kr)의 저작권 동의에 의해 공유되고 있습니다.
    Copyright ⓒ Techworld, Inc. 무단전재 및 재배포 금지


[원문출처 : http://www.epnc.co.kr/news/articleView.html?idxno=63250]

맨 위로
맨 위로