윈드리버 임베디드용 OS의 현재와 미래

Embedded OS

글 : 이정섭 이사, 김동일 차장 / 윈드리버 코리아 기술지원부www.windriver.co.kr근래 개최되는 임베디드 관련 세미나에 참석하거나 기술지원을 위해 개발자들을 만나보게 되면 모두가 한결같이 무척 분주하고 바쁜 모습들이다. 이야기를 들어 보면 현재 진행중인 프로젝트에서 엔드 커스터머(End Customer)의 요구사항에 따른 기능 추가, 커스터마이징(Customizing) 및 디버깅(Debugging)을 하느라 시간과의 싸움을 하고 있으며 병행하여 새롭게 진행할 프로젝트를 기획하느라 더욱 분주하다고 한다. 특히 임베디드 디바이스를 개발하는 개발자들은 수시로 변화하는 제품 요구사항을 맞추고 더욱 짧아지고 있는 개발기간 때문에 정신이 없는 듯 하다. 이러한 어려움을 헤쳐 나가기 위해 개발자들은 현재와 미래의 상황에 대응할 수 있는 최적의 솔루션(Solution)을 끊임없이 찾게 된다. 그 중 대표적인 것으로 임베디드 디바이스의 핵심인 임베디드용 프로세서와 이를 최적으로 구동 시켜줄 수 있는 임베디드 OS 그리고 개발기간을 단축시켜줄 수 있는 편리한 개발환경이 있다.이러한 이유에서인지 많은 개발자들이 이 분야에서 최적의 솔루션을 제공하며 마켓을 선도하고 있는 윈드리버의 OS인 VxWorks와 WR Linux(윈드리버 리눅스)가 앞으로 어떻게 발전해가며 어떤 솔루션들을 제공해 나갈 지에 큰 관심을 보이고 있다. 이 글은 이에 대한 궁금증을 풀어드리고자 하며, 앞 부분에서는 VxWorks에 대해서 살펴보고 후반부에서는 WR Linux에 대해서, 끝 부분에서는 요즘 임베디드 분야에서 화두가 되고 있는 OS 가상화(OS Virtualization)에 대한 윈드리버 솔루션을 살펴보도록 하겠다.임베디드 리얼타임 OS VxWorksVxWorks의 미래를 이야기하려면, 반드시 임베디드 디바이스 시장의 요구사항에 대한 변화에 대해 이야기를 함께 해야만 가능하다. 왜냐하면 VxWorks는 시장의 요구에 의해 탄생되었으며, 성장해 가고 있고 앞으로도 계속 성장해 나갈 것이기 때문이다.초기의 VxWorks초창기의 VxWorks는 지금 모두가 알고 있는 VxWorks와는 다른 모양이었다. 즉, VxWorks는 1980년대 초에 4K 짜리 VRTX 커널을 보강해 주는 파일시스템(File System), 타깃쉘(Target shell) 등 액세서리 컴포넌트로 만들어지면서 탄생되었다. 이러한 연유로 VxWorks란 이름으로 불리게 되었는데 VRTX 커널에서 작동되는 악세서리란 의미로 이는VrtX Works의 줄임말 이다. 이후, 1987년에 지금의 VxWorks의 핵심이 된 커널의 효시인 윈드커널(Wind Kernel)이 만들어지게 되어 현재 알고 있는 완전한 커널의 모습을 갖추게 되었다. 다만, 이름은 바꾸지 않고 VxWorks를 그대로 사용해 오고 있다. 이 당시의 VxWorks는 모토롤라 MC68000 프로세서에 어셈블리어로 작성되었다가 곧 C로 재 작성되어 68K 계열 뿐만 아니라 다양한 CPU 아키텍처에 포팅되었다. 이 시기의 임베디드 디바이스는 대부분 4bit 마이콤이나 8bit짜리 마이크로 컨트롤러를 사용하여 만들어졌으며, 68K면 16bit로 꽤 고급 시스템에 해당되었다. 하지만 이 위에 실행되는 애플리케이션 코드는 커봐야 몇 백라인에서 천 라인 미만 정도였다.1990년도에 들어서면서 본격적으로 라우터와 같은 데이터 통신장비들이 개발되기 시작하였는데 이 때부터 32bit CPU를 채택하기 시작하였으며 이 시기부터 VxWorks가 본격적으로 임베디드 장비를 위한 리얼타임 OS로서의 역할을 수행하기 시작했다. 파일시스템 및 IPv4 TCP/IP 네트워크 스택과 라우팅 프로토콜 및 SNMP 같은 망관리 프로토콜들이 사용됨으로서 이에 실행되는 애플리케이션 소스 코드의 길이는 몇 만 라인으로 늘어나게 된다.이 당시만 해도 임베디드 네트워크 장비의 개발은 대략 1~2년 정도의 프로젝트 기간을 가지고 수행되었다. 물론 이때의 디버깅은 콘솔 기반의 printf나 타깃쉘을 사용하여 수행되었고 RTOS 회사에서 제공한 솔루션을 거의 그대로 사용하던 시기이기도 하다.VxWorks 5.4와 토네이도1997년도에는 구이(GUI) 기반의 토네이도(Tornado) 개발환경과 VxWorks 5.4가 출시되어 임베디드 개발환경에 대대적인 혁신을 일으켰으며, 국내에서는 주로 교환기, 라우터 같은 통신장비 개발에 사용되었다. 이때에는 IPv4 TCP/IP 스택에 대한 새로운 RFC가 점차 많아지는 이유로 네트워크 스택 및 애플리케이션 소프트웨어의 코드 길이가 몇 십만 라인으로 늘어나게 되었다. 점차 코드가 늘어나면서 디버깅 이슈도 대두되었지만 여전히 RTOS 회사에서 출시한 제품에 약간의 수정만으로 제품화가 되던 시기였다.이 시기에는 RTOS에 대한 요구사항이라는 것이 성능 및 크기(foot print) 정도가 거의 대부분이었으며, 메모리 크기가 작았던 관계로 작고 빠른 가벼운 OS면 충분하였다. 이를 구현하기 위해 CPU 프로세서의 커널모드를 사용했다(그림 1). 모든 VxWorks 시스템 콜은 펑션 콜을 사용하였으며 커널, 디바이스드라이버 및 애플리케이션이 전체 메모리 주소 공간을 공유하였다. 개발자가 필요에 따라 애플리케이션 코드에서 커널의 오브젝트를 직접 건드릴 수 있었고, 디바이스 드라이버 및 메모리를 자유롭게 아무런 제약 없이 접근 할 수 있어서 상황에 따라 유연한 프로그래밍이 가능하였고 실행속도도 빠른 장점이 있었으나 커널이 애플리케이션 코드로부터 보호 받을 수 없는 구조로 인해, 애플리케이션 내의 사소한 버그(bug)만으로도 시스템이 다운되는 경우가 발생할 수 있었다.VxWorks 5.5 & 5.5.1과 토네이도Ⅱ 2000년도에 들어와서는 네트워크 통신 장비 외에 다른 분야에서도 임베디드 디바이스가 점차 많이 사용되기 시작하였고 이에 따라 임베디드란 용어가 조금씩 대중화되기 시작하였다. 특히 컨수머(Consumer) 제품 부문에서는 풀 디지털화가 시도되면서 RTOS가 많이 사용되었다. DTV, 셋톱박스 등이 대표적인 예이다. 그 외에는 산업용 장비 및 자동차용 디바이스, 의료장비, 항공우주 분야에도 널리 사용되기 시작했다. 이 시기의 임베디드 OS에 대한 시장의 요구 사항은 다음과 같다.- 신뢰성, 견고성(Reliable)- 설계된 시간에 따라 정확히 수행되는 실행(Deterministic)- 작은 이미지 크기(Small foot print)- 확장성(Scalable)그리고 시장에는 이미 다양한 종류의 임베디드 RTOS들이 있었고 또 새로이 생겨나기도 했는데, 당시 고객들의 RTOS의 선정기준은 커널의 성능(컨텍스트 스위칭 타임, 인터럽트 응답시간, 시스템 콜 수행시간)과 크기(Foot print)이었다. VxWorks 5.5/5.5.1 역시 [그림 1]처럼 5.4와 비슷한 주소구조와 커널모드로 운영 되었는데 단지 5.4와의 차이점이 있다면 pSOS+ 에서만 제공되었던 기능 중 장점으로 여겨졌던 이벤트 시스템 콜과 시스템 큐에 대한 기능이 5.5에 추가 되었다는 점이다. 또한 핸드폰시장이 커지기 시작했던 때이기도 하며, 일반 리눅스가 점차적으로 다양한 임베디드 디바이스에 포팅되던 시기이기도 하다.2002년 ~ 2003년도에는 기간망에 들어가는 교환기 같은 통신 장비와 네트워크 장비 보다는 개인이 주로 사용하게 되는 컨수머 디바이스 제품의 개발과 출시가 더욱 많아지는 시기이다. 컨수머 이기 때문에 앞서 이야기 되었던 내용 외에 커널에서의 전원 관리기능과 외부 디바이스들(USB 디바이스 등)의 핫 플러그인/아웃(Hot Plug in-out) 기능이 요구되었다. 또한 디지털 카메라 같은 디바이스에서는 부팅 시간도 매우 중요해지게 되었다. 더불어 요구되는 미들웨어들도 점차 다양해지기 시작하였으며, USB, 블루투스(Bluetooth), 와이파이(WiFi) 및 플래시 화일 시스템 지원이 기본사항으로 여겨지기 시작하였다. 이렇게 필요한 코드들이 늘어나면서 코드는 애플리케이션까지 합쳐 수 백만 라인을 훌쩍 뛰어 넘게 되었다. 따라서 디버깅이 굉장히 어려워 졌으며, 다이내믹하게 로딩되는 모듈에 대해 커널 및 리소스 등을 보호하는 기능이 필요하게 되었다.VxWorks 6.0~6.4와 워크벤치(Workbench)2004년 말에 VxWorks 6.0과 개발환경인 Workbench 2.2가 출시되었는데, 이는 다음과 같은 임베디드 디바이스 시장의 요구사항에 대한 윈드리버의 RTOS 솔루션이다.- 신뢰성, 견고성(Reliable)- 설계된 시간에 따라 정확히 수행되는 실행(Deterministic)- 작은 이미지 크기(Small foot print)- 확장성(Scalable)- 커널 성능 개선- MMU 기반의 메모리 보호(Virtual memory 지원)- 사용자 모드 지원- 이전 버전인 VxWorks 5.5와 하위 호환성 보장(5.5의 애플리케이션 마이그레이션(Migration)이 용이)위의 요구사항을 지원하기 위해 [그림 2]와 같이 VxWorks 6.x의 구조가 설계되고 구현되었으며 이전 버전의 VxWorks에서는 없던 RTP(Real Time Process)라 불리는 사용자 모드가 등장하였다. 이 모드는 유저모드로 메모리 보호기능이 제공된다. 그리고 이전 VxWorks 5.5에서 개발된 애플리케이션과 미들웨어를 손쉽게 마이그레이션할 수 있도록 5.5와 비슷하게 메모리 보호가 되지 않는 커널모드 또한 제공하고 있다. 개발자는 이전 버전에서 개발되어 검증된 어플리케이션 코드를 컴파일만 다시하는 수준에서 VxWorks 6.x 커널모드로 동작시킬 수 있고 새롭게 추가되거나 개발되는 기능들은 메모리 보호 기능이 지원되는 RTP모드를 사용할 수 있도록 하였다. 또한 [그림 3]과 같이 에러 검출과 보고 기능이 강화되어 애플리케이션 개발 및 디버깅 시간을 전보다 줄일 수 있도록 하였다.2005년에는 VxWorks 6.1이 출시되었고, TIPC 기능이 추가되었다. 이 기능은 Transparent Inter Process Communication의 약자로 임베디드 시스템에 여러 장의 프로세서 보드가 장착되는 경우, 각 프로세서에 탑재된 VxWorks간의 통신에 사용되며, VxWorks외에 WR Linux나 다른 OS가 탑재되어 있다 할지라도 각 OS에서 오픈소스 산업표준인 TIPC 기능이 지원 된다면, 서로 다른 OS에서의 상호통신도 가능하게 해준다.이는 기존 TCP/IP 소켓을 통하는 것 보다 보드 간에 더 빠른 통신 채널을 제공한다.VxWorks 6.2에서는 전원관리 기능과 고신뢰성 화일시스템(HRFS), POSIX 2.2.1 기능이 지원되고 있으며, VxWorks 6.3에 이르러서는 Scaled OS 컨피규레이션(Configuration) 프로파일(Profile) 기능을 제공하여 VxWorks 커널도 필요에 따라 크기를 다양하게 조절할 수 있도록 하였다(그림 4, 그림 5).- 최소커널 프로파일 (Minimal Kernel Profile) < 100 KB- 기본 커널 프로파일 (Basic Kernel Profile) ~ 150 KB- 기본 OS 프로파일 (Basic OS Profile) ~ 250 KB2007년에는 VxWorks 6.5가 출시되었으며, VxWorks 커널 성능개선과 함께 인터피크(InterPeak)사의 네트워크 스택이 기존의 윈드리버 네트워크 스택을 대체하게 되었다. 인터피크사는 윈드리버가 합병한 회사로 IPv6/v4 듀얼스택의 전문 기업이다. 이로서 VxWorks의 네트워크 성능은 더욱 좋아지게 되었다.VxWorks 6.6과 Workbench 3.0/3.0.22008년 현재 VxWorks 6.6 버젼이 출시되었고, 특히 임베디드 RTOS에서 구현이 아주 어렵다고 알려져 있는 VxWorks 6.6 SMP 버전도 출시 되었다. SMP 버전은 Symmetric Multi Processing으로 동종의 멀티프로세서 또는 멀티코어 환경에서 동작하며, 커널이 애플리케이션을 실행시킬 때 태스크들을 각각의 프로세서 또는 프로세서 코어에 적절히 할당해주어 좀 더 빠른 성능으로 실행할 수 있도록 해준다. 당연히 애플리케이션은 SMP 환경에서 잘 실행될 수 있도록 어느 정도 수정이 필요하다.이는 시장에서 지속적으로 요구되고 있는 소형화, 저전력, 고성능 이라는 숙제를 해결하는 방법으로 서버와 같은 범용 시스템에서는 이미 사용되고 있던 기술이지만, 임베디드 디바이스에서는 이제야 적용되기 시작했다. 그리고 VxWorks 6.6에 번들된 IPv6/v4 듀얼 스택은 최근 IPv6 Ready Logo phase II 인증을 받았으며 고객이 이 제품을 사용하면, 고객이 만든 제품에 대해 IPv6 Ready Logo phase II 인증을 보다 쉽게 받을 수 있다.VxWorks 6.7 과 앞으로의 VxWorks 버전VxWorks 6.7은 내년 봄 경에 출시될 예정으로, 커널의 지속적인 실행 성능개선 및 풋 프린트 최적화 그리고 SMP 기능에 대한 성능 최적화가 이루어질 것이며, IPv6/v4 네트워크 스택에 대한 SMP 기능지원이 될 것이다.또한 SMP에 대응되는 개념인 AMP(Asymmetric Multi Processing) 기능도 지원될 예정이다. VxWorks 6.7 다음으로는 6.8이 계획되어 있고, 이후로도 정해진 로드맵에 따라 버전 업그레이드가 계속 이루어질 예정이며 다음에 소개되는 VxWorks만의 핵심 밸류를 지키고 임베디드 디바이스 제품들의 요구기능을 충족시키기 위해 지속적인 연구/개발이 이루어 질 것이다.- 고객에게 최고의 RTOS를 제공(World Class RTOS)- 고객에게 완전한 멀티코어, 가상화(OS Virtualization), AMP 및 SMP 솔루션 제공- 고객이 많이 필요로 하는 프로세서 및 하드웨어 지원- 업계를 선도하는 네트워킹 솔루션 제공예를 들면, 반도체 기술의 비약적인 발전에 힘입어 우수한 성능의 멀티코어 프로세서들이 계속 출시되고 있고 대용량의 메모리들이 점점 저렴해져 가고 있는 상황에 따라 이를 최대한 활용하는 임베디드 디바이스의 설계가 점차 많아질 것으로 예측되며, 기존 개발되어 있는 검증된 애플리케이션 코드와 미들웨어들을 최소한의 작업으로 빠르게 재활용 할 수 있도록 해주는 솔루션을 찾고 있는 개발자를 위해 윈드리버에서는 VxWorks AMP 및 SMP 그리고 OS 가상화 기술의 제품인 하이퍼바이저(Hypervisor)를 통합한 솔루션을 제공할 것이다. 또한 완전한64bit를 지원하는 VxWorks와 VxWorks SMP가 제공될 것이며 OS 뿐만 아니라 OS 컴포넌트, 미들웨어등도 임베디드 디바이스가 요구하는 성능 및 크기를 맞추기 위해 손쉽게 커스터마이징이 가능한 솔루션을 제공할 것이다.스페셜버전 VxWorks앞에서 살펴본 VxWorks는 임베디드의 범용 버전으로 각종 다양한 임베디드 디바이스에 사용된다. 하지만 임베디드 디바이스가 특수한 분야에서 사용되는 경우 각각의 분야에 대한 특별한 인증을 획득해야만 최종제품을 판매할 수 있는 경우도 있다. 예를 들면 항공기, 군용 등과 같은 미션크리티컬(Mission Critical) 한 곳에 사용될 때는 DO-178B라는 인증을 받아야하고, 항공전자기기에 사용될 때는 ARINC653 인증을, 원자력발전소 또는 의료기기 같은 곳에 사용될 때는 IEC61508 인증을, 네트워크 시큐리티 장비 같은 경우에는 EAL4 이상의 인증을 받아야 한다. 윈드리버에서는 이러한 규격에 대한 OS 수준의 인증을 받아 놓은 스페셜 버전의 VxWorks 솔루션도 제공하고 있다. 이 제품들을 사용하면, OS에 대한 부분은 이미 윈드리버에서 받아놓은 스페셜 버전의 인증서와 최종제품을 가지고 OS에 대한 시험 스크립트를 실행시켜 나온 결과를 함께 제출하여 OS에 대한 인증을 받음으로 시간과 비용을 절약할 수 있다. 다음은 각 인증시험 규격에 대한 VxWorks의 스페셜 버전 제품 목록이다.- PSC VxCERT : DO-178B용 VxWorks 스페셜 버전- PSC ARINC653 : ARINC653용 VxWorks 스페셜 버전- PSC 61508 : IEC61508용 VxWorks 스페셜 버전- VxWorks MILS : EAL4+ 인증용 VxWorks 스페셜 버전윈드리버는 시장의 요구사항 및 고객의 요청사항을 지속적으로 모니터링하여 스페셜 버전의 VxWorks도 계속 업데이트 또는 버전업시켜 갈 것 이다.WR Linux 이력 및 미래리눅스는 1991년 핀란드 헬싱키 대학 전산전공 학생이었던 리누즈 토발즈(Linus B. Torvalds)가 미닉스(MINIX)라는 교육 목적의 운영체제에서 영감을 얻어 만든 작은 커널(Kernel)이었다. 여기에 리차드 스톨만(Rechard M. Stallman)이 주도하고 전 세계의 수 많은 개발자들이 참여한 GNU(Gnu is Not Unix) 프로젝트의 결과물들이 더해지면서 현재의 모습을 갖추게 되었다.초창기의 리눅스는 임베디드 시스템(Embedded system)보다는 주로 메일이나 웹과 같은 서버 애플리케이션(Application)을 위해 사용되었지만 90년대 중후반 네트워크 장비와 같은 임베디드 시스템에 사용되기 시작하면서 현재는 하드 리얼타임(Hard Realtime)이 필요한 몇몇 분야를 제외하고는 거의 모든 임베디드 업계에서 사용되어지고 있다.개발자들이 임베디드 시스템 개발에 리눅스를 도입하게 된 주된 이유는 다음과 같다.-초기투자 비용 절감-많은 개발자 지원(Unpaid Community support)-풍부한 애플리케이션리눅스는 자유/오픈 소스(Free/Open source)정책을 따르고 있기 때문에 인터넷을 통해 다운로드하여 자유롭게 사용하는 것이 가능하다. 리눅스가 가진 또 다른 매력은 전 세계에 걸친 수 많은 개발자 공동체의 뉴스그룹이나 웹을 통하여 문제 해결을 위한 다양한 정보를 얻을 수 있다는 것이다. 더불어 수 많은 애플리케이션들이 소스 코드와 함께 제공되는 경우가 많으므로 자신의 용도에 맞게 수정하여 제품 개발에 사용하는 것이 가능하다.상용 리눅스의 등장불과 10여년 전만 하더라도 개발자들이 하드웨어를 위해 사용 할 수 있는 칩의 선택 폭은 그리 넓지 않았다. 몇몇 주로 사용되어지는 칩들이 있었고 개발자들은 인터넷을 통해 자신들이 선택한 칩에 맞는 커널과 패치를 다운 받아 사용하거나 무료로 제공되는 유명한 배포판을 기반으로 제품을 개발할 수 있었다.하지만 최근 시장에서 많이 사용되는 칩셋들을 보게 되면 MIPS, PowerPC, ARM 등 특정 코어(Core)를 라이선싱하고 여기에 다양한 IP(Intellectual Property)나 DSP(Digital Signal Processing) 유닛을 추가한 시스템 온칩(SoC, System on Chip)의 형태로 출시되는 것이 추세이다.시스템 온칩을 사용한 제품 개발이 많아지면서 개발자가 인터넷을 통해 커널과 패치를 다운 받고 칩이 올바르게 구동 될 수 있도록 직접 포팅하는 작업은 이제 더 이상 쉽게 찾아보기 힘든 상황이 되었다. 칩을 제공하는 하드웨어 업체에서 포팅된 리눅스를 제공하기는 하나 하드웨어 업체에서 운영체제 부분을 전문적으로 개발/관리하기에는 어려움이 있다. 개발자들은 리눅스 커널이 단순히 칩이나 보드에 포팅되는 것을 넘어 자신들이 필요한 미들웨어(Middleware) 패키지나 애플리케이션 패키지까지 함께 제공받기를 원하기 때문이다. 더불어 기술지원에 대한 요구사항을 충족시키기도 어렵다.이 같은 상황에서 전문 OS(Operating System) 업체들은 칩을 만드는 하드웨어 업체와 파트너십을 맺고 상용 리눅스를 출시하기 시작하였다. 상용 리눅스는 개발자로 하여금 플랫폼(Platfrom)쪽에 필요한 인력을 최소화 시키고 제품의 가치를 높일 수 있는 애플리케이션에 더욱 집중할 수 있도록 도와주고 있다. 제품 개발 사이클이 점점 빨라지고 항상 최신의 시스템 온칩들이 개발자의 선택을 기다리며 경쟁하는 상황에서 상용 리눅스가 전체 임베디드 리눅스 시장에서 차지하는 비율은 점점 더 높아 질 것으로 기대된다.이러한 시장의 변화를 받아들여 윈드리버 또한 2003년부터 상용 임베디드 리눅스 제품을 선보이기 시작했다.윈드리버 리눅스 전략윈드리버가 추구하는 리눅스 전략은 크게 3가지로 볼 수 있다.1) 윈드리버의 리눅스 커널은 최대한 오픈소스 진영의 것과 진행 방향을 같이 한다.메인 스트림(Main stream) 커널을 크게 수정하여 새로운 포크(Fork)를 만들기 보다는 메인 스트림의 코드를 철저히 테스트하여 안정성을 높이고 다양한 아키텍처(Architecture)를 지원하는 것을 목표로 하고 있다. 이를 통해 개발자들은 벤더 종속성을 최대한 줄일 수 있고 오픈소스 진영의 최신 기술들을 큰 무리 없이 쉽게 윈드리버 리눅스에 적용할 수 있다.2) 여러 분야의 미들웨어 요구를 충족시킬 수 있는 다양한 플랫폼들을 제공한다.[그림 6]은 윈드리버에서 제공하는 있는 리눅스 플랫폼들이다. 앞서도 언급한 바와 같이 제품 출시 사이클(Time to Market)이 점점 짧아지면서 개발자들이 보는 리눅스는 더 이상 단순히 하드웨어에 포팅된 커널만이 아닌 미들웨어, 애플리케이션이 통합된 플랫폼인 것이다. 네트워크 장비를 예로 들면, 장비의 안정성과 서비스기능 향상을 위한 CGL(Carrier Grade Linux) 요구사항, SAF(Service Availability Forum) 표준 등의 구현 여부는 통신 서비스 제공자들이 장비를 선정하는데 있어서 중요한 고려 사항이 되었다. 또 다른 예로 자동차의 오토모티브 인포테인먼트(Automotive Infortainment) 플랫폼을 보게 되면 운전자의 편의성을 위해 음성인식, SMS/MMS 게이트웨이, 인터넷 액세스, 블루투스 기능 등을 제공하고 엔진 전자제어 시스템(ECU)과 자동차에 부착된 각종 센서간의 빠른 통신을 위한 CAN(Controller Area Network)버스의 제어와 같이 상당히 많은 기능들이 인포테인먼트 플랫폼에 통합되어 제공되고 있다.제품 특성에 따라 수직적으로 나누어진 리눅스 플랫폼은 앞으로 더욱 세분화 될 것으로 예상되며 윈드리버에서는 모블린(Moblin)을 기반으로 하는 MID (Mobile Internet Device) 플랫폼과 구글 안드로이드를 기반으로 하는 모바일 플랫폼 또한 내년 출시를 목표로 개발 중이다.3) 개발시간 단축 및 개발 편의성을 위한 도구를 제공한다.제품 개발은 통상적으로 설계 -> 코딩/구현 -> 유닛테스트 -> 시스템 통합테스트 -> 품질/양산 테스트 -> 제품양산 과 같은 사이클을 가지고 진행된다. 실제적으로 개발자가 코딩이나 구현에 사용하는 시간보다는 코드를 디버깅하고 테스트 하는데 사용하는 시간이 훨씬 많은 것이다. 그러므로 디버깅과 테스트를 위해 투입되는 시간을 줄이는 것이 바로 제품 출시일을 맞추고 인건비 및 제반 비용을 줄일 수 있는 중요한 요소가 된다. 리눅스 개발자라면 vi, emacs, printk, gdb 등을 사용하지 않고 개발하는 것은 상상하기도 어려울 것이다. 이와 같이 리눅스에서는 Command Line 형태의 도구들을 많이 사용해 왔으나 멀티코어(Multicore), 가상화(Virtualizaiton) 기술과 같이 시스템이 점점 더 복잡해짐에 따라 좀 더 체계적으로 시스템 정보를 분석하여 보여줄 수 있는 도구에 대한 필요성이 대두되고 있다.[그림 7]는 윈드리버 워크벤치(Work bench)라는 개발 도구로서 코드 설계 단계부터 코딩, 디버깅, 품질 테스트 등 제품 개발의 전 영역에서 사용할 수 있는 도구이다. 또한 이클립스(Eclipse)에 기반하고 있으므로 사용자가 원하는 플러그인(Plug-in)들을 손쉽게 가져다 사용할 수 있는 편의성을 가지고 있다.이러한 툴들을 통해 단편적으로 볼 수 있었던 시스템 동작상태나 디버깅 정보를 종합적으로 분석 가능하다.리눅스의 리얼타임리눅스는 앞에서 언급한 바와 같이 하드 리얼타임을 완벽히 구현하는데 문제가 있다. 커널이 2.6으로 올라오면서 O1 스케줄링(Scheduling)이나 커널 공간 내에서도 선점(Preemption)이 가능하도록 설계되어 커널의 응답성이 비약적으로 좋아진 것은 사실이다. 그러나 약간의 시간 지연(time delay)로도 막대한 재산 피해 및 더 나아가 인명 피해가 발생할 수 있는 산업(Industrial), A&D, 로봇(Robotics) 산업 등에는 Linux를 적용하는데 어려움이 있었다.리얼타임 지원을 개선하기 위한 방법으로 많은 OS 업체에서 취하고 있는 방법 중의 하나가 커널 내의 여러 실행 Path에 대해서 선점을 막을 수 있는 critical section 부분을 [그림 8]과 같이 여러 개로 세분화 시키거나 인터럽트 응답시간을 최적화 시키는 방법 등이 있다. 이를 통해 프로세스가 커널 내에서 수행하는 동안 더 높은 우선 순위의 프로세스가 실행 대기하게 되는 경우 선점을 통해 높은 우선순위의 프로세스가 실행권을 가질 수 있는 확률을 높여준다.위와 같은 방식을 사용하는 경우 평균적으로 상당히 좋은 응답시간을 보이기는 하나 성능 개선을 위해 특정 부분의 커널 소스를 수정하게 되면 이전에 하드리얼타임으로 동작하던 다른 실행 path에 영향을 줄 수 있다는 문제점이 있다. 그러므로 어떤 경우에도 하드리얼타임의 동작성을 보인다고 보장하기가 어려운 면이 있다.윈드리버에서는 VxWorks와 비슷한 수준의 하드 리얼타임을 지원하며 동시에 리눅스의 유용한 모든 기능을 그대로 사용할 수 있는 RTCore라는 솔루션을 제공한다. RTCore는 커널 모듈의 형태로 리눅스 커널에 삽입되며 [그림 9]에서 볼 수 있듯이 커널 공간내에 자신의 스케줄러를 동작시켜 리얼타임 애플리케이션들이 하드리얼타임으로 동작할 수 있도록 스케줄링하게 된다. 이를 위해 RTCore 스케쥴러는 인터럽트(Interrupt)와 타이머(Timer)를 중간에서 가로채며 [그림 8]의 오른편에서 볼 수 있는 리눅스를 RTCore 스케줄러의 제일 낮은 우선순위 태스크(Task)로 동작시킨다. 즉 리얼타임 애플리케이션 쪽에서 수행할 태스크가 없는 경우에만 리눅스쪽으로 스케줄링 되어 리눅스상의 일반 애플리케이션들이 동작하는 구조인 것이다.이 방식은 기존 커널의 동작에는 영향을 미치지 않고 하드리얼타임을 지원하는 태스크와 리눅스 상에서 동작하는 일반 태스크를 분리해 주게 되는데 하드리얼타임이 필요한 태스크와 리눅스상의 태스크를 적절히 조합하여 서로의 장점만을 살릴 수 있는 설계가 가능하다.WR HypervisorWR Hypervisor는 임베디드 디바이스 영역에서 떠오르고 있는 화두인 “소프트웨어 컨버젼스”에 대한 솔루션으로 다양한 조합의 OS 가상화(virtualization) 기능이 제공된다. 이것은 소형화, 저전력화, 고성능 등의 풍부한 하드웨어 프로세싱 리소스와 저렴해져가는 대용량의 메모리 덕분에 상용화가 가능해진 기술로 기존에 이전 버전의 VxWorks 기반으로 개발되어 QA 검증되어 있거나 리눅스 기반 또는 타 OS 기반으로 개발되어 있는 애플리케이션 코드 및 미들웨어들을 최소한의 수정으로 대부분 그대로 재사용하기를 바라던 개발자들의 희망사항이 실현 가능해 졌다. Hypervisor를 사용하게 되면 개발자는 기존에 개발된 코드를 다른 OS와 같이 사용하려는 과정에서 아예 버리거나 또는 참조하여 새롭게 개발하지 않아도 되므로 개발시간을 상당히 단축시킬 수 있는 장점이 있다.예를 들면, VxWorks 5.5로 개발되어 있는 애플리케이션과 VxWorks 6.6으로 개발되어 있는 애플리케이션 또는 WR Linux에서 개발되어 있는 애플리케이션을 그대로 하나의 하드웨어 기반위에 WR Hypervisor가 제공하는 가상보드 기능과 파티셔닝 기능을 사용하여 독립적으로 동작시킬 수 있다.즉, VxWorks 5.5의 애플리케이션은 데이터를 매우 빠른 속도로 입력 받아 처리하고 이를 IPC를 사용하여 유저 인터페이스를 담당하는 리눅스 애플리케이션에 전달하여 출력할 수 있도록 만들 수 있다. Hypervisor 기술이 없는 경우 VxWorks 5.5에 기반 한 애플리케이션 코드 전체를 리눅스 기반으로 수정하던지 반대의 과정을 거쳐야 하므로 수개월 이상의 개발기간이 소요되어야 하는 일을 Hypervisor를 이용함으로써 서로간의 인터페이스 부분만을 구현하는 비교적 간단한 작업만으로 이전에 개발해 놓았던 코드들을 그대로 다 사용할 수 있게 된다. 그러므로 각 OS에서 동작하던 애플리케이션의 크기가 복잡하고 몇 십만~몇 백만 라인정도 된다면 Hypervisor의 가치는 극대화 될 수 있다.그림 10에 몇 가지 조합의 예를 보인다.맺음말윈드리버는 미래의 시장과 고객이 필요로 하는 사항들을 정기적으로 모니터링하고 있으며 고객이 필요로 하는 시점에 필요로 하는 기능을 갖춘 OS 솔루션 및 미들웨어를 제공하여 고객이 시장에서 성공할 수 있도록 VxWorks 및 WR Linux를 지속적으로 버전업 또는 업데이트 해갈 것이다.

회원가입 후 이용바랍니다.

개의 댓글

회원로그인

작성자 비밀번호

댓글 내용입력

댓글 정렬

최신순 추천순 답글순

BEST댓글

BEST 댓글 답글과 추천수를 합산하여 자동으로 노출됩니다. 닫기

더보기

강혜리 (webmaster@techworld.co.kr)

기자의 다른기사 보기

저작권자 © 테크월드뉴스 무단전재 및 재배포 금지