본문 바로가기

2016
임베디드월드


글: 최태우 기자 desk@epnc.co.kr / 2016-07-20




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


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


이러한 문제는 가상플랫폼(Virtual platforms)과 무선 네트워크 및 환경에 대한 시뮬레이션을 통해 극복할 수 있다. 이를 통해 하드웨어를 소프트웨어 시뮬레이션으로 전환해 쉽게 하드웨어를 생성하고 구성하고, 제어할 수 있다. 이 글에서는 IoT 시스템 시뮬레이션 및 테스팅을 위한 기술에 대해 자세히 소개하고 확장 가능한 테스팅 시스템 구축 방안을 다뤄보고자 한다.


소개 


지난 몇 년간 사물인터넷, 즉 IoT는 이와 관련된 제품을 판매하는 업체들에게 있어서 단순히 흥미로운 아이디어에서 반드시 확보해야 하는 주력 기술로 자리 잡아 왔다.


산업용 IoT 시스템과 애플리케이션에 대한 보다 혁신적인 테스트 방법에 대해 알아보자. 산업용 IoT라고 하면 비즈니스나 전문적인 목적을 위해 단일 개체가 규모가 상대적으로 큰 대량 IoT 노드의 네트워크를 배포하는 환경의 애플리케이션을 의미한다. 대부분의 소비자용 애플리케이션은 적은 수의 디바이스에만 연결되며, 테스팅 프로필도 서로 다르다. 


일반적인 산업용 IoT 시스템의 계층 구조는 그림 1과 같다. 많은 수의 노드 또는 디바이스가 각각 실제 환경에서 상호 작용한다. 이 노드들은 일반적으로 저전력의 저렴한 디바이스로, 하나의 지점 또는 단일 설정에서 수백 또는 수천 개의 유닛에 사용된다. 여러 노드들은 게이트웨이로 연결된다. 


게이트웨이는 처리량이 많은 보안 소프트웨어를 실행하고 방대한 계산을 자체적으로 수행할 수 있는 보다 강력한 기기이다. 한편에서는 게이트웨이가 노드에서 사용하는 네트워크나 저전력 네트워크로 연결되며 다른 쪽에서는 이를 서버로 연결한다.


게이트웨이는 커뮤니케이션 주체이자 중재자로, 시스템의 구조를 완성하고 노드를 인터넷 기반의 공격으로부터 보호하는데 도움을 준다.



[그림 1] IoT 계층 구조


또한 게이트웨이는 애그리게이터(Aggregator)로써 서버망에 데이터를 전달하기 전에 이를 수집, 융합하고 완충 작용을 하는 역할도 한다. 하나의 게이트웨이는 소매점이나 주거 건물과 같이, 일부 제한된 지역적 위치에 있는 노드들을 책임지게 된다. 안정성이나 가용성을 확보하기 위해 한 지점에 여러 게이트웨이를 배치할 수도 있다. 


서버 또는 백엔드(Backend)는 종종 클라우드에서 호스팅되며 이는 노드의 데이터가 기업의 비즈니스 로직과 만나는 지점이다. 데이터는 게이트웨이를 통해 노드에서 수집되고 명령과 컨피규레이션이 게이트웨이와 노드로 전달된다.


서버는 더 넓은 세상과 상호 작용한다. 예를 들어 농업 시스템의 경우 서버는 일기 예보와 시장 정보를 사용하여 어떤 작물을 언제, 어떻게 심고 수확할지 결정한다. 각 서버는 여러 사이트에 다수의 게이트웨이, 매우 많은 수의 노드에 연결된다.


시스템의 사용자는 자신의 휴대폰, 태블릿, PC에서 웹 브라우저나 사용자 지정 애플리케이션을 통해 서버와 상호 작용할 수 있다.


물론 모든 시스템이 이런 계층 구조를 따르는 것은 아니다. 일부 경우에는 개별 리프(leaf) 노드가 서버와 직접 상호 작용할 수도 있고, 서버가 없을 수도 있으며 모든 계산이 노드나 게이트웨이에서 수행될 수도 있고 사용자가 게이트웨이 또는 디바이스와 직접 상호 작용할 수도 있다. 그러나 이러한 차이점으로 인해 실제 운영 및 애플리케이션 코드와 상호 작용하는 네트워크에 배포된 많은 기기에 대한 테스트가 쉽지 않다는 점은 기본적으로 변하지 않는다.  


IoT를 위한 소프트웨어 테스팅 


IoT 시스템을 위한 소프트웨어 테스트와 구성에 있어, 물리적인 하드웨어를 사용할 때 실제 문제에 부딪히게 된다. 일단 많은 수의 하드웨어 노드가 방대한 물리적 영역에 배포되어 있어야 한다. 무선 네트워크를 테스트할 때는 개발 환경 기기 간, 그리고 개발 환경과 실제 환경간에 무선 연결을 격리하거나 제어할 수 있어야 한다.


아무리 저렴한 노드를 사용한다고 해도 센서 데이터나 네트워크 오류의 경우 하드웨어 설정에 많은 비용이 들 수 있다. 시스템의 네트워크 토폴로지나 실제 구성을 변경하려면 많은 수작업이 요구되며 반복 가능한 방식으로 자동화하기 어렵다. 이러한 경우 IoT 하드웨어 및 네트워크의 시뮬레이션을 통해 많은 테스트와 관련된 문제들을 매우 효율적으로 해결할 수 있다.



[그림 2] IoT 시스템 테스팅


그림 2와 같이 가장 우선적인 부분은 IoT 시스템을 작동시키는 소프트웨어를 테스트하는 것이다. 다른 최신 시스템과 마찬가지로, IoT 시스템이 사용자에게 주는 가치와 경쟁력은 바로 소프트웨어에 있다.


기본 센서 노드 하드웨어는 기본적인 것으로 쉽게 구할 수 있지만, 차별화하기 어렵다. 결국 소프트웨어와 데이터 수집 역량이 IoT 시스템을 보다 스마트하게 만들고 사용자에게 가치가 있다. 


하드웨어가 개발되고 현장에 배포된 후에도 소프트웨어는 지속적으로 개발되고 향상된다. 사용자는 시스템의 소프트웨어 업데이트, 기능 추가, 버그 수정, 보안 위험 요소의 해결을 기대한다. 출시하고 나서 이 모든 요구 사항을 그냥 무시할 수는 없다.


IoT 소프트웨어 개발은 일반적인 데스크톱 또는 모바일 소프트웨어 개발과 달리 처음에 소프트웨어가 하드웨어에 설치된 이후에 더 오랜 시간 동안의 유지 관리와 업데이트를 필요로 한다.


여기서는 가상 플랫폼을 활용하여 얼마나 빠르게 시뮬레이션을 구현할 수 있는지, 그리고 IoT 시스템을 위한 소프트웨어를 보다 효율적으로 테스트하는데 어떤 도움이 되는지 다뤄보고자 한다.


IoT 시스템을 위한 시뮬레이션 방법은 이 외에도 많이 존재하고 있으며 실제 코드를 실행하지 않거나 범위 내에 실제 노드 소프트웨어를 포함시키지 않는 방법도 있다. IoT 시뮬레이터를 선택할 때는 시뮬레이션의 추상화 수준과 여러분에게 필요한 콘텐츠와 잘 맞는지를 확인해 보는 것이 좋다. 


IoT를 위한 준비 단계 
IoT 시스템을 실제 환경에 배포하기 전에 개발자는 이 시스템이 배포되었을 때와 동일한 환경에서 소프트웨어와 시스템을 테스트하는 것이 좋다. 웹, 클라우드, 서버 소프트웨어의 개발에 있어서 부딪히게 되는 공통적인 문제가 바로 이것이다.


새로운 소프트웨어를 개발 환경에서 바로 배포할 수 없는데도, 실제 환경에서 어떻게 작동할지 먼저 확인해야 한다는 점이다. 


이 문제에 대한 표준 해결책은 준비 설정 단계를 거치는 것이다. 준비 설정 또는 준비 서버는 실제 생성 시스템과 유사하게 구성된 시스템이지만, 개발자의 제어 및 운영 범위 내에 있으면서도 아직 실제 사용자가 사용하지는 않는 시스템이다. 


실제 환경을 본뜬 테스트 설정인 것이다. 준비 설정은 소프트웨어가 실제 적용 환경에서 발생하는 문제에 의해 설치, 업그레이드, 시작, 실행에 문제가 발생하지 않는지 검사하는데 사용된다. 준비 설정은 단일 디바이스나 개발 연구 단계에서뿐만 아니라, 특정 완성 시스템의 사용 환경에서 소프트웨어가 제대로 실행되는지 확인하는 것이다. 


IoT로 인해 임베디드 시스템에 대한 실시간 소프트웨어 업데이트가 갈수록 일반화되면서 준비 단계가 소프트웨어 개발에 있어서 더욱 중요한 단계가 되고 있다. 노드의 특정 토폴로지, 네트워크 및 게이트웨이가 포함된 완전한 통합 소프트웨어 시스템을 테스트해 단순한 표준 테스트가 아니라 실제 환경에서 제대로 작동하는지 확인해야 한다. 



[그림 3] 노드 6개에 대한 서로 다른 네트워크 토폴로지 구성의 예


준비 설정에는 실제 환경과 같은 실제 노드 ID와 주소 지정 방식이 사용되므로 이전 버전의 기반 OS와 새로운 버전의 소프트웨어 애플리케이션 조합과 같은 양상도 반영할 수 있다. 준비 설정의 올바른 적용은 "개발 환경에서는 문제가 없다", "하지만 나의 환경에서는 작동하지 않는다"라는 당황스러운 문제가 발생하지 않도록 하는 중요한 과정이다.   


시뮬레이션을 적용한 소프트웨어 테스팅 및 준비 단계 
IoT 소프트웨어 테스팅은 IoT 시스템이 혹독하고 거친 실제의 환경에서 작동해야 하며 방대하게 배포된 네트워크 시스템이라는 점에서 기본적으로 매우 까다롭다. 한 노드를 대상으로 한다면 어려울 것이 없지만, 수백 수천 개의 노드를 대상으로 테스팅, 개발, 사전 준비 작업을 진행하는 하는 데에는 많은 어려움이 있다. 


실제 물리적인 하드웨어를 사용해 테스트하려면 방대한 영역에 분산된 무선 노드의 환경이 마련되어야 하며, 이들 모두가 서로 연결되어 있지 않을 수도 있다. 이는 전체 건물이나 학교 자체를 실험실로 만들어야 한다는 의미이다.


이러한 설정을 구성하고 유지 관리하려면 상당한 노력이 필요하며, 노드 자체의 가격보다 투입되는 인건비가 더 높을 것이다. 실제 적용 환경과 같은 개발 환경은 사용할 수 있는 노드와 토폴로지의 다양성이 제한된다는 점에서도 한계가 있다.


드라이버 및 보드 지원 


가장 낮은 단계에서는 IoT 시스템의 드라이버와 하드웨어가 서로 잘 맞는지 테스트해야 한다. 보통 이는 로컬 문제이므로 하나의 노드나 소수의 노드를 사용하여 테스트할 수 있다. 배터리 전원이나 복잡한 무선 인터페이스 작동도 하나의 노드에서 테스트할 수 있다. 아직 하드웨어가 없다면 이러한 개발에는 가상 플랫폼을 사용할 수 있다.


하지만 저전력의 저렴한 하드웨어일수록 실제 하드웨어에서만 발생하는 문제들이 나타날 수 있기 때문에 실제 하드웨어에서 직접 테스트해 보는 것이 매우 중요하다.


대부분 IoT 시스템은 기존의 안정적인 하드웨어와 드라이버 및 보드 지원을 기반으로 한다. 그리고 시뮬레이터의 주된 역할은 이러한 드라이버 스택을 실행하여 동일한 바이너리가 실제 하드웨어와 같이 시뮬레이터에서도 작동하도록 하는 것이다. 소프트웨어 개발자가 직면하는 가장 주된 문제는 기본 플랫폼이 작동한다는 가정아래 시스템 레벨의 기능을 어떻게 테스트할까 하는 점이다.



[그림 4] 프로그래밍 가능한 설정


단일 노드


일부 IoT 시스템은 인터넷에 직접 연결된 개별 노드로 운영된다. 이런 시스템의 경우 다른 시스템과 마찬가지로 가상 플랫폼과 시뮬레이션을 유용하게 활용할 수 있다. 가상 플랫폼을 활용하면 하드웨어와 자동화가 어려운 하드웨어에 의존하지 않고 자동화된 테스팅과 지속적으로 관리 운영이 가능한 통합 워크플로를 구현할 수 있다.


가상 플랫폼을 더 큰 서버나 클라우드에서 실행하면 테스팅의 규모도 늘릴 수 있다. 오류 주입(Fault injection)과 회귀(Regression) 테스트를 위해 네트워크 입력을 제어, 기록, 재생할 수도 있다. 


무선 프로토콜 및 통신 


기본 무선 통신 기능이 있다고 가정하면 다음 단계는 사용하는 프로토콜과 네트워킹 스택의 작동 방식과 견고성을 검증하는 것이다. 


설정은 무제한으로 얼마든지 다르게 바꿀 수 있다. 여기에는 고려할 수 있는 흥미로운 사례가 많으며, 시스템에서 특정 규모까지 노드가 늘어나지 않으면 이런 사례는 대부분 발생하지 않는다. 무선 네트워크의 토폴로지는 다양하므로, 테스트하는 네트워크의 규모는 반드시 고려해야할 사항이다.


예를 들어 그림 3을 보면 6개의 노드가 게이트웨이에 연결되는 두 가지 방법이 있다. 한 경우를 보면 피어 노드(Peer Nodes) 간의 메시 네트워킹에 의존하여 노드가 게이트웨이에 메시지를 보낸다. 다른 경우는 모든 노드가 게이트웨이와 직접 통신한다. 네트워킹 시스템에 스트레스가 발생하는 요인이 매우 다양하다는 점을 보여주는 명확한 예이다. 


시뮬레이터에서는 아주 쉽게 방대한 네트워크를 설정할 수 있다. 그림 4에서처럼 원하는 가상 공간에 배포할 노드를 프로그래밍하고 가상으로 배포한 다음 노드 사이의 무선 연결 가능성을 모델링하면 된다. 수백 개의 실제 아이템들을 수동으로 처리하는 대신 하나의 스크립트나 프로그램만 관리하면 되는 것이다. 


무선 네트워크는 태생적으로 안정적이지 않다. 따라서 오류가 매끄럽게 처리되어야 한다. 패킷이 유실되거나 왜곡될 경우, 또는 노드가 보내야할 응답을 보내지 못하면 시스템에 어떤 일이 생길까? 실제 환경의 변화로 인해 두 노드 사이의 연결에 문제가 생기면 연결과 전송에 무슨 지장이 발생할까? 전파 잡음이 특정 노드에 가까이 있어 전파에 영향을 미쳐 노드의 전송 기능이 차단된다면 어떻게 될까?


이러한 사례는 시뮬레이터에서 아주 쉽게 재현할 수 있으며, 회귀 테스팅을 위해 반복 확인해 수정 작업이 실제로 문제를 해결했는지 손쉽게 확인할 수 있다. 시뮬레이션을 사용하면 소프트웨어를 실제와 똑같은 환경에 맞춰 좋지 않은 상황을 구현해 반복적으로, 그러나 안전하게 테스트해볼 수 있다.  


시뮬레이터는 또한 실제 전파 네트워크를 사용할 필요가 없으므로 다른 무선 시스템에 간섭하거나 외부 잡음에 영향을 받을 일이 없다는 장점을 가지고 있다. 실제 세계에서 무선을 위한 테스트 시스템을 만들려면 특별한 격리 공간안에서 전파 신호를 제어해야 한다. 


준비 작업을 위해 시뮬레이션된 네트워크를 사용하면 실제 시스템의 네트워크와 통신 토폴로지를 정밀하게 모델링할 수 있으므로 실제 토폴로지와 유사한 환경에서 시스템 소프트웨어를 테스트할 수 있다. 시스템의 견고성을 테스트하기 위해 오류를 주입하는 것도 테스트의 한 방법이다.


더 많은 네트워크 노드 


IoT 시스템 개발과 테스트의 핵심은 시스템 규모의 확장에 대처하는 방식이다. 시스템의 규모가 커지면 생각하지 못했던 상황이 발생할 수 있다는 것이 일반적인 상식이다. 10개의 노드만 가진 상태의 시스템 동작만이 아니라 노드가 100개, 1,000개일 때의 시스템 동작과 노드 사이의 연결 방식에 따른 운영도 고려해야 한다. 


따라서 가장 작은 유닛 테스트에서 하위 시스템 테스트, 상상할 수 있는 가장 큰 규모에 대한 테스트까지 모든 규모에 대한 시스템 동작을 테스트해야 한다. 때로는 각 시스템의 규모가 커지면서 시스템에 다른 문제가 생기기도 한다. 가장 큰 규모의 설정에서만 그런 것이 아니라, 중간 수준의 규모에서도 이러한 문제는 생길 수 있다.


위에서 설명했고 그림 4에서 볼 수 있듯 규모가 큰 시스템도 시뮬레이션에서는 설정하기가 어렵지 않는다. 구성 프로그램을 실행하고 원하는 규모를 선택하기만 하면 된다. 각 테스트에 임의의 요소를 적용하도록 프로그래밍할 수도 있고, 안정적인 회귀 테스트를 위해 정해진 설정을 적용할 수도 있다. 


네트워크로 연결된 IoT 시스템은 분산 시스템이며 분산 시스템에서는 타이밍이 중요한 변수이다. 너무 빨리 발생하는 이벤트나 특정 순서로 발생하는 이벤트는 시스템 충돌을 일으킬 수 있다.


예를 들어 많은 노드가 동시에 재시작하면 마스터/슬레이브(Master/Slave) 시스템에서 마스터에 과부하가 유발될 수 있다. 실제 세계에서 이러한 이벤트를 재현하기가 매우 어렵지만 시뮬레이터에서는 아주 간단한 일이다. 


IoT 시스템은 대개 다양한 종류의 장치로 구성된다. 서로 다른 종류의 게이트웨이와 노드, 다양한 종류의 노드가 네트워크 내에 공존하게 된다. 시뮬레이션을 사용하면 모든 종류의 하드웨어를 무한으로 도입해 볼 수 있으므로 임의로 혼합된 네트워크를 만들어 소프트웨어가 이러한 혼합 환경 하드웨어에서 잘 작동하는지 확인할 수 있다. 


준비를 위해 시뮬레이션 단계에서 특정 고객의 설정을 스크립트로 프로그래밍할 수 있다. 노드, 게이트웨이, 상호 연결 방식과 ID, 주소가 여기에 포함된다. 이러한 고객 구성을 저장해 버전을 관리하고 다시 사용할 수 있다. 개발 환경을 물리적으로 재구성하는 것보다, 원하는 설정을 위해 프로그램을 실행하기만 하면 된다. 


엔드 투 엔드(End-to-End) 기능 및 통합 


IoT는 격리되었던 시스템에 대한 네트워킹 및 연결성에 대한 것이므로, 노드가 게이트웨이 및 네트워크를 통해 서버 애플리케이션과 어떻게 통신하는지 테스트하는 것은 정확한 시스템의 기능을 보장하기 위해 필수적이다. 많은 중요 워크플로우에서 시스템의 모든 부분이 제대로 작동하는지 테스트해야 한다.  


하나의 핵심적인 예로는 데이터 수집과 집계를 들 수 있다. 노드의 센서 값은 서버에 전달되어야 하며 올바르게 처리돼야 한다. 시뮬레이션을 활용하면 하나의 노드에서 수천 개의 노드까지 모든 환경에서 이 워크플로우를 테스트할 수 있다.


또한 시뮬레이션은 서버가 방대한 양의 데이터를 처리할 수 있는지 노드의 수가 늘어나도 시스템이 노드와 데이터를 연결할 수 있는지 테스트할 수 있다. 


서버 쪽 소프트웨어를 업데이트한 다음서버를 다시 테스트할 수 있는 기능도 제공한다. 많은 노드에 대한 서버 관리와 유저 프레젠테이션도 테스트할 수 있으므로 시스템의 규모가 커질수록 사용자 인터페이스 역시 늘어나는 것을 확인할 수 있다. 


다른 방향으로의 통신도 테스트할 수 있다. 서버에서 컨피규레이션과 명령을 게이트웨이와 노드에 전송해 적용하도록 할 수 있으며 무선 소프트웨어 업데이트도 가능하다. 소프트웨어 업데이트 메커니즘도 네트워크나 노드 오류를 업데이트 도중에 주입함해 재시작 여부와 견고성을 확인할 수 있다. 


노드 사이의 인터페이스와 협업도 또 다른 테스트 대상이다. 많은 IoT 네트워크가 메시 네트워크를 기반으로 하며, 이는 자체적으로 구성되고 새 네트워크 구성원을 자동으로 찾아낸다.


노드의 수와 전원을 켜는 타이밍, 네트워크에 추가되는 시기를 다르게 하여 테스팅하는 것은 시뮬레이션에서 손쉽게 설정할 수 있지만, 하드웨어에서는 안정적으로 테스트하기가 매우 어렵다. 네트워크를 절반으로 나누어 각 부분이 어떻게 바뀌는지 노드가 시스템의 일부에서 자신이 연결 해제되었다는 것을 인지하는지 시뮬레이션할 수도 있다. 


엔드 투 엔드 테스팅의 또 다른 측면은 IoT 시스템을 통한 지속적 통합(CI, Continuous integration)이다. CI 시스템에서는 새로운 코드가 작은 규모(단일 노드나 게이트웨이)에서 먼저 테스트되고, 여기서 통과하면 점차 더 큰 규모에서 테스트되어 최종적으로 전체 시스템에 대한 테스트를 수행하게 된다.


IoT를 위한 CI를 위해 시뮬레이션을 사용하면 단일 노드, 단일 노드와 게이트웨이 조합, 소량의 노드와 게이트웨이 조합 등 다양한 통합 수준에 대한 설정이 손쉬워진다. 


통합과 엔드 투 엔드 테스팅은 IoT 시스템이 여러 다른 팀이나 회사들에서 만든 경우 더욱 중요하다. 이러한 경우 공유할 수 있는 시뮬레이션 테스트 장치를 만들고 CI를 사용하여 점진적으로 통합하면 개발 리스크를 줄일 수 있다. 다음글에서는 보안·인증과 구현 환경과 개발 도구에 대해 알아보겠다. 




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


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

맨 위로
맨 위로