T-Engine의 심장부 ‘T-Kernel’, 현재 그리고 미래

심층분석

T-Kernel’이란 임베디드 시스템을 위한 실시간 운영체제(RTOS)다. 그 기술 기반은 TRON(The Real-time Operating system Nucleus)이다. T-Kernel은 2004년 2월부터 소스코드가 일반에 공개됐다. ‘T-License’라는 라이선스 계약에 동의하면 누구나 무상으로 자유롭게 이용할 수 있다. 현재 공개돼 있는 소스코드는 임베디드 시스템에서 사용되고 있는 르네사스 SH, ARM, MIPS 등 대부분의 임베디드 CPU를 지원한다.그럼, T-Kernel은 어떤 OS인지 하나하나 짚어보기로 하자.T-Kernel은 (일본에서) 임베디드 시스템에 널리 보급되어 높은 실적을 자랑하고 있는 ITRON의 기능과 성능을 계승한 실시간 OS다. 현재 대규모화·고기능화 되어가는 임베디드 시스템의 요구에 대응한 각종 기능을 제공하고 있다. 특히, 임베디드 시스템에 적합한 라이선스에 의해 무상으로 소스코드가 공개되어 자유롭게 제품에 사용할 수 있다는 점에 주목하라.ITRON의 기능과 성능 계승T-Kernel의 가장 큰 특징은 실시간 OS (RTOS)라는 점과, 임베디드 시스템을 위한 OS라는 점이다. 실시간 OS는 마이크로초(μs) 단위로 발생하는 이벤트에 대하여 높은 응답성을 실현한 OS다. 단순히 처리속도가 빠르다는 것 외에도, 처리시간을 예측할 수 있도록 시간제약을 지킬 필요가 있다. 실시간 OS로서 현재 널리 사용되고 있는 기술은 ITRON이며, 일본 트론(TRON)협회의 ‘2005년도 실시간 OS 이용 동향 앙케트 조사결과’에 따르면 일본의 임베디드 시스템에서 사용되고 있는 OS의 절반이 ITRON이라고 한다.T-Kernel은 ITRON의 기능과 성능을 계승하고 있다. 따라서 ITRON의 대부분 기능을 T-Kernel 역시 지원하고 있다(표 1 참조).대규모화, 고기능화에 대응임베디드 시스템 소프트웨어는 해마다 대규모화, 고기능화 되어가고 있다. 최근의 하드디스크나 DVD를 이용한 디지털 비디오 레코더(DVR)는 동영상 자체를 디지털 데이터로 처리하며 디스크 상의 파일 시스템에 기록한다. 이것은 기능적으로는 기존의 임베디드 시스템보다 PC에 가까우며, 당연히 OS에 대한 요구 기능도 바뀔 수밖에 없다. 초창기의 임베디드 소프트웨어가 특정 하드웨어에서만 동작하는 일회용에 가까웠지만, 지금의 임베디드 소프트웨어는 재활용성이나 이식성이 중시되고 있다. 아울러 개발기간을 단축하기 위해서 소프트웨어 부품, 미들웨어에 대한 요구도 증가하고 있다.이러한 요구는 ITRON이 발표된 당시(80년대 중반)에는 생각할 수 없었던 것이며, 이것이 현시점에서 ITRON의 단점이 되고 있다. 물론 ITRON도 확장이 계속되고 있지만 한계가 있다. 그래서 ITRON의 장점을 계승하여 새롭게 설계된 실시간 OS가 T-Kernel이다.T-Kernel에서는 실장 의존성을 없애고, 프로세서가 다른 하드웨어에 대해서도 재컴파일 하는 것만으로 소프트웨어의 이식이 가능하도록 했다. 최신의 CPU에서 제공하는 MMU(Memory Management Unit)에도 대응하고 있다. 더욱이 T-Kernel /Standard Extension에 의해 파일 시스템이나 네트워크에 대응한 시스템 구축도 가능해지고 있다.T-Kernel의 기능 확장고기능화 되는 임베디드 시스템은 메모리 보호나 파일 시스템 기능을 OS에 요구하고 있다. 그러나 임베디드 시스템은 다양하므로, 모든 시스템이 이런 기능을 요구하는 것은 아니다. T-Kernel에 이들 기능을 직접 내장하는 것은 OS의 비대화로 직결되며, ITRON의 장점인 경량성을 잃게 된다. 그래서 고안된 것이 ‘Extension’이다.파일 시스템 등의 기능은 Extension으로서 T-Kernel에 제공된다. 필요 없으면 Extension을 사용하지 않고, ITRON과 같은 수준의 경량 OS로 사용할 수도 있다. 또한 Extension 자체를 교환함으로써 다른 시스템을 구축할 수도 있다.Extension은 마이크로 커널인 T-Kernel이 경량성을 잃지 않으면서 동시에 보다 다양한 기능을 구축할 수 있도록 해준다. 다만, 일반적인 마이크로 커널과 달리 Extension은 유저 모드가 아니라 T-Kernel과 같은 시스템 모드에서 동작함으로써 실행효율은 유지하고 있다.T-Engine 포럼에 있어서 표준 Extension으로 개발되고 있는 것이 ‘T-Kernel/Standard Extension’(T-Kernel/SE)이다.T-Kernel/SET-Kernel/SE는 고기능의 정보단말기, 정보가전, 차세대 휴대전화 등 임베디드 시스템 중에서도 대규모/고기능의 시스템에서의 사용을 고려하여 설계되었다. T-Kernel/SE는 여러 가지 기능을 가지고 있지만, 그 중에서도 중요한 것은 ▲독립된 논리 메모리 공간을 갖는 프로세스 관리, ▲FAT나 CD-ROM에 대응한 파일 시스템, ▲가상 메모리를 포함하는 MMU에 대응한 메모리 관리, ▲TCP/IP 네트워크에의 대응 등을 들 수 있다.현재 T-Kernel/SE는 T-Engine 포럼 내에서 베타판이 발표되어 평가가 이뤄지고 있다. 정식 버전이 완성되는 대로 T-Kernel과 마찬가지로 일반에 무상으로 공개될 예정이다.T-Kernel/SE의 프로그램 모델T-Kernel은 ‘태스크’를 프로그램의 실행 단위로 하고 있지만, T-Kernel/SE에서는 실행 단위가 ‘프로세스’이다. 프로세스는 독립된 논리 메모리 공간에서 동작한다. 프로세스 간에 데이터를 주고받기 위해서는 메시지에 의한 통신 기능이나 데이터 공유 기능을 사용한다.프로세스 스케줄링은 T-Kernel과 마찬가지로 ‘절대 우선도(Preemptive Priority) 스케줄링’ 외에 ‘라운드 로빈(round robin) 스케줄링’도 선택할 수 있다. 실시간성이 높은 처리는 절대 우선도로, 비교적 실시간성이 요구되지 않는 상위 애플리케이션 등은 라운드 로빈으로 분리해 사용할 수 있다.이와 같이 T-Kernel/SE의 프로세스 기반 프로그램에서는 리눅스나 윈도우 OS에 가까운 프로그램 모델을 구축할 수 있다. 단, T-Kernel/SE의 프로그램이 T-Kernel의 태스크 기반 프로그램과 반드시 동떨어져 있는 것은 아니다. 세마포어나 이벤트 플래그, 메시지 버퍼라는 T-Kernel의 동기 통신 기능은 T-Kernel/SE에서도 대부분 사용할 수 있다.사실, 프로세스의 실체는 T-Kernel 태스크에 고유의 논리 메모리 공간과 자원을 부여한 것이다. 프로세스를 생성하면 하나의 논리 메모리 공간과 그것에 속한 하나의 태스크가 생성된다. 이 단계에서는 프로세스와 태스크는 1대 1로 대응하고 있으며, 특별히 차이를 의식할 필요는 없다. 그러나 동일한 프로세스 내에 여러 개의 태스크를 만들 수 있다. 즉, 하나의 논리 메모리 공간 상에 여러 개의 태스크가 존재할 수 있는 것이다. T-Kernel/SE에서 프로세스와 태스크의 관계는 윈도우나 UNIX계 OS 등에 있어서 프로세스와 스레드의 관계로 이해해도 좋다.T-Kernel과 T-Kernel/SET-Kernel/SE는 프로세스나 파일 시스템, 가상 메모리 등 상용 OS에 가까운 기능을 T-Kernel에 제공하지만 동시에 T-Kernel 기반의 프로그램과도 강한 친화성을 가지고 있어 T-Kernel의 실시간 성능을 떨어뜨릴 일은 없다.디바이스 드라이버나 서브시스템은 T-Kernel이 그대로 사용되고, 많은 미들웨어는 어느 쪽 환경에서도 사용할 수 있다. T-Kernel/SE 자체가 T-Kernel 상에서 움직이고 있는 것이어서, T-Kernel/SE의 동작환경이라고 해도 T-Kernel 기반의 소프트웨어는 동작 가능하다. 또한 T-Kernel의 태스크 기반 프로그램과 T-Kernel/SE의 프로세스 기반 프로그램을 혼재시킬 수도 있다. 태스크 기반의 프로그램을 프로세스 기반으로 이식하는 것도 용이하다. 가장 손쉬운 이식 방법은 ‘데이터를 공유하는’ 등 관련성이 높은 태스크군을 하나의 프로세스로 하는 것이다. 각각의 태스크 독립성이 높으면 그대로 따로따로 프로세스 할 수도 있다.이와 같이 T-Kernel과 T-Kernel/SE에서는 소프트웨어 자산이나 노하우를 공유할 수 있다. 이 부분이 단순한 하이브리드형 OS와 다른 점이기도 하다.T-Kernel의 미래지금까지 T-Kernel의 현재 모습을 소개했다. 이쯤에서 T-Kernel의 미래를 들여다 보자.T-Kernel 로드맵의 중심이 되는 것은 T-Kernel 그 자체다. 그러나 T-Kernel 자체의 기능적인 버전업은 예정돼 있지 않으며, 품질향상이나 성능개선 작업만 진행될 전망이다. T-Kernel 규격은 소프트웨어의 호환성을 보증하기 위해서 고정되는 것이다. 즉, OS가 버전업되었기 때문에 아직 사용할 수 있는 소프트웨어를 바꿔야 하는 일은 T-Kernel에서는 일어나지 않는다.새로운 전개는 현재 T-Kernel이 대응하지 않고 있는 분야에 대하여 계획되어 있다. 우선 16비트 CPU나 싱글 칩 마이크로컨트롤러 등 자원이 부족한 시스템에 대응하여 μT-Kernel을 개발하고 있다. 또한 멀티프로세서 요구에 대해서도 대응하고 있다. 마지막으로 T-Kernel은 유비쿼터스 네트워킹 환경의 초소형 센서 노드에서부터 멀티프로세서를 사용한 고기능 정보 시스템까지 폭넓게 대응해 가는 것을 목표로 하고 있다. T-Kernel의 로드맵 가운데 현재 개발이 진행되고 있는 μT-Kernel과 멀티프로세서 대응 T-Kernel에 대해 좀더 자세히 살펴보자.μT-KernelμT-Kernel은 8/16비트 CPU나 싱글 칩 마이크로컨트롤러 등 메모리 용량과 CPU 처리능력에 제약이 많은 소규모 임베디드 시스템을 대상으로 한다. T-Kernel 자체는 결코 큰 OS가 아니지만, 그래도 단일 소스코드로 다양한 CPU에 대응하고, 또 서브셋을 만들지 않고 모든 기능을 실장하고 있기 때문에 소규모의 시스템에서 보면 장황한 부분도 존재한다.μT-Kernel에서는 T-Kernel과의 호환성을 고려하면서도 OS 전체의 효율에 영향을 미치는 요인이 규격에서 제외된다. 예를 들면 MMU 대응 기능 등은 μT-Kernel에는 존재하지 않는다. 또한 소스코드도 T-Kernel과 같이 단일 소스로 일괄 관리되는 것은 아니다. 이것은 소규모의 시스템에서는 어셈블러의 사용도 포함시킨 최적화가 필요하다고 생각되기 때문이다.당연히 μT-Kernel에서는 T-Kernel에 대한 소프트웨어 호환성은 보증되지 않는다. 표준화나 호환성보다도 최적화나 적응화를 우선한 것이 μT-Kernel이기 때문이다. 만약에 표준화나 호환성을 중시한다면 T-Kernel을 사용해야 한다.그러나 정해진 가이드라인에 따라 작성된 μT-Kernel 상의 프로그램은 T-Kernel 상에서의 작동도 고려되고 있다. 디바이스 드라이버 등도 이식이 용이하다.μT-Kernel을 사용하는 것의 이점 중 하나는 기존의 시스템이 보다 고기능의 하드웨어를 사용하게 되었을 때 T-Kernel로 용이하게 이행할 수 있다는 점이다. 또 하나의 이점은 싱글 칩 마이크로컨트롤러 시스템에서 대규모·고기능의 시스템까지 같은 아키텍처의 OS를 사용함으로써 소프트웨어 자산이나 노하우를 축적할 수 있다는 데 있다.멀티프로세서 대응멀티프로세서는 서버나 PC 분야에서는 이미 일반적이지만, 최근 임베디드 시스템에서도 주목을 받고 있다. 그 배경에는 고기능화 되는 임베디드 시스템에서 높은 CPU 처리능력을 요구하고 클록 업으로는 한계가 보이고 있다는 데 있다. 또한 하나의 패키지에 복수의 프로세서 코어를 내장한 멀티코어 프로세서의 등장이 임베디드 시스템에 멀티프로세서를 사용하는 것에 현실성을 갖게 했다.T-Kernel에서는 ‘임베디드 시스템에 적합한 멀티프로세서 대응 실시간 OS’를 목표로 대응하고 있다. 멀티프로세서는 ‘비대칭형 멀티프로세서(AMP)’와 ‘대칭형 멀티프로세서(SMP)’로 구분할 수 있다.AMP는 각 프로세서의 역할 분담이 결정되어 있는 기능분산형 멀티프로세서다. 프로세서마다 OS를 포함시켜서 다른 프로그램이 동작하고, 서로 동기 통신해서 유기적으로 동작한다. AMP는 임베디드 시스템에서는 비교적 친숙하다. 예를 들어 휴대전화의 베이스밴드 칩과 애플리케이션 프로세서도 일종의 AMP 구성이다.SMP는 각 프로세서가 동등한 입장에서 처리를 분담하는 부하분산형 멀티프로세서다. 하나의 OS가 프로세서 간의 처리를 조율하므로 상위 프로그램의 경우에는 멀티프로세서 유무를 의식할 수 없다. 즉, 애플리케이션을 변경할 일 없이 프로세서를 고속화하는 대신 멀티프로세서로 교체하는 것이 가능해진다. SMP는 지금까지 서버나 PC에 주로 사용돼 왔지만, 앞으로는 임베디드 시스템에도 사용이 확산될 전망이다.AMP와 SMP는 어느 쪽이 더 우수하다고 말하기는 어렵다. 단지 용도에 따라 사용하는 것 일 뿐이다. T-Kernel에서는 AMP와 SMP에 모두 대응하고 있다.T-Kernel의 AMP 대응AMP 시스템에서 T-Kernel은 각각의 프로세서마다 독립하여 동작하고 또 프로세서마다 태스크의 스케줄링이 이루어진다.AMP 대응 T-Kernel은 기존 T-Kernel과의 호환성을 중시하여, 소프트웨어 자산이나 노하우를 유용하기 쉽게 설계돼 있다. 각 프로세서 간의 동기 통신은 특별한 동기 통신 오브젝트를 설정하지 않고 기존 T-Kernel의 기능을 확장해서 사용한다. 또 기능 확장에 있어서 기존 T-Kernel과의 API 호환성을 가능한 한 유지하는 방침으로 설계돼 있다.예를 들어 어떤 태스크가 세마포어를 조작하려는 경우, 그 세마포어가 동일 프로세서 상이든 다른 프로세서 상이든 같은 시스템 호출로 조작할 수 있다. T-Kernal이 시스템 호출의 조작 대상을 판단하고, 다른 프로세서 상이라면 프로세서 간 통신을 하여 조작을 실현한다.주의해야 할 점은 태스크의 스케줄링이 프로세서마다 이루어진다는 점이다. 우선도나 디스패치 금지에 의한 배타제어(exclusive control)는 프로세스 간에는 효과가 없다. 멀티프로세서 환경에서 배타제어는 세마포어나 이벤트 플래그 등 동기 오브젝트를 사용하지 않으면 안된다. 이것만 지키면 싱글 프로세서이든 AMP이든 구별 없이 동작하는 프로그램을 작성할 수 있다.T-Kernel의 SMP 대응태스크 등 각종 오브젝트는 프로세서에 자동적으로 할당할 수 있어 멀티프로세서를 의식할 일은 없다. 이것이 SMP의 이점이지만, 임베디드 시스템에서 이 단순한 SMP 모델은 몇 가지 문제점이 있다.우선, 오브젝트가 자동적으로 할당될 수 있기 때문에 실시간성을 어디까지 보증할 수 있을 지 문제가 된다. 높은 실시간성이 요구되는 처리에는 AMP와 같이 프로세서를 의식할 필요가 있다.또한 단일 프로세서에서 개발된 프로그램을 단순히 SMP 환경으로 이행할 경우, 기대한 성능을 얻을 수 없을 수도 있다. 현재 SMP에 대응하고 있는 리눅스 등의 OS는 라운드 로빈 방식에 의한 스케줄링을 기본으로 하고 있다. 원래 태스크(프로세스)를 평등하게 취급하는 방식은 SMP와 잘 맞는다. 그러나 처음에 설명한 것처럼 실시간 처리에 적합하다고는 말할 수 없다. T-Kernel 등의 실시간 OS는 절대우선도에 따라 스케줄링을 하고 있다. 이것을 단순히 SMP로 움직이면 다음과 같은 문제가 발생한다.예를 들면, 원래 절대우선도의 스케줄링으로는 우선도가 높은 태스크 동작 중에 그 태스크 보다 우선도가 낮은 태스크가 움직이는 일은 없다. 동일 우선도의 태스크라면 각 프로세서에서 동시에 움직일 수 있지만, 우선도가 높은 태스크가 하나밖에 존재하지 않는 경우 아무리 프로세스가 비어 있어도 사용할 수 없게 된다.이와 같이 임베디드 시스템에서 SMP를 사용하기 위해서는 SMP에서도 프로세서를 고려한 AMP적인 수법의 도입이나 프로그램 모델 자체의 검토를 하지 않으면 안된다. T-Kernel에서는 이 점을 고려하여 임베디드 시스템에 적합한 SMP 대응 실시간 OS로서 개발이 이루어지고 있다.

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

개의 댓글

회원로그인

작성자 비밀번호

댓글 내용입력

댓글 정렬

최신순 추천순 답글순

BEST댓글

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

더보기

김가희 (webmaster@techworld.co.kr)

기자의 다른기사 보기

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