2005. 9. 26. 11:27
이번에는 RTOS에 대하여 개괄적으로 정리해보려 하였습니다.
그런데 너무 무모한 도전이었던 것 같아 조금 후회되네요.. ^^ 워낙 방대하고 전문적인 내용도 많아 소화가 잘 안되는군요 ^^ 일단 나름대로 정리해보고, 다음 기회에 좀더 보충해볼 생각입니다.
RTOS( Real-Time Operating System)
RTOS란?
RTOS(Real-Time Operating System)는 Real-Time (Embedded) System을 위한 운영체계이다. 따라서 먼저 Embedded System과 Real-time System의 정의를 이해할 필요가 있다.
Embedded System
정의
마이크로프로세서 혹은 마이크로 컨트롤러를 내장하여(embedded) 미리 정해진 기능만을 수행하는 장치
cf) PC처럼 사용자가 프로그램을 바꿔가며, 여러 가지 용도로 활용할 수 있다면 그 시스템은 embedded system으로 분류하지 않는다.
응용분야
정보가전, 정보단말, 통신장비, 항공/군용, 물류/금융, 차량/교통, 사무, 산업/제어, 의료, 게임
Real-Time System
정의
“예고 없이 불시에” 발생하는 이벤트에 대하여 “정해진 시간” 내에 “정확한 결과”를 제공하되, 그 응답시간이 “예측가능”하고 일정해야 하는 시스템
즉 시간 상의 제약(Time Correctness, 시간적 정확성)이 중요시되는 시스템이다.
종류
Hard Real-Time System : deadline을 넘기면 처리가 의미 없음
Soft Real-Time System : deadline을 넘기더라도 여전히 처리는 의미 있음, 그 가치는 떨어짐
Real-Time Embedded System
정의
Real-Time 요건을 충족하여야 하는 Embedded System.
범위
대부분의 컨트롤 시스템은 Real-Time Embedded System.
ex) ID 체크 보안시스템, 공장 로봇, ATM(Automated Teller Machine)
RTOS
정의
Real-Time 성격의 어플리케이션을 개발/수행하기 위한 OS.
cf) 많은 RTOS는 Real-Time Embedded System을 위해 설계되고 사용되고 있다.
왜 RTOS가 필요한가?
Real-Time Embedded System을 개발하기 위해, 멀티태스킹과 같은 기능이 중요해지고 있는데, 기존 범용 멀티태스킹 OS는 시간적 정확성을 보장해주지 못해, 이를 지원해주는 RTOS가 필요하다.
멀티태스킹의 필요성
Real-Time Embedded System의 기능이 점점 복잡해져, S/W 개발과 유지보수가 점점 어려워지고, 더 많은 시간과 비용이 필요해지고 있다. 이를 해결하기 위해, 시스템의 기능을 “순차적으로 실행되는 하나의” 프로그램으로 구현하는 대신, 여러 개의 task(multi-task)로 분할하여 개발할 필요가 있다.
멀티태스킹의 형태로 개발하면 다음과 같은 잇점이 있다.
1) 코드의 개발, 수정, 유지, 보수가 보다 용이하다.
2) 이벤트에 대해 보다 신속하게 응답할 수 있다.
( interrupt가 발생하면, 진행 중인 task 대신 interrupt를 처리할 task를 우선적으로 실행할 수 있다. )
3) 시스템의 신뢰도와 성능을 높일 수 있다.
cf) Real-Time Embedded System에서의 멀티태스킹:
범용 시스템의 경우, 멀티태스킹은 서로 무관한 여러 작업( ex. word, email, media-player)을 동시에 수행하는 것을 말한다. 그러나 Embedded System의 경우는 하나의 임무를 수행하기 위해, 동시에 수행되어야 하는 여러 task를 수행하는 것을 말한다. 즉 이들 task들은 하나의 어플리케이션을 구성하는 모듈(부품)이 된다.
멀티태스킹 OS의 필요성
멀티태스킹은 다음과 같은 까다로운 문제를 일으킨다. 이들 문제는 직접 해결하기 보다는 OS를 도입하는 것이 훨씬 효과적이다.
1) task간 경쟁의 관리
2) 데드락
3) 우선순위 역전( priority inversion )
4) 재진입 문제( Reentrancy )
5) task간 통신
ex) ADSL Router
ADSL Router의 경우에, PPP, IP, TCP/UDP 프로토콜을 처리하면서, 동시에 라우터 간의 동기화를 위해 RIP 메시지를 주고받아야 하고, 시스템 관리 정보를 주고받기 위해 SNMP 메시지도 발송하는 등의 여러 task들을 동시에 수행하고 있다. 이것을 multitasking을 지원하는 OS의 도움 없이 “하나의 프로그램”으로 작성할 경우, 이 프로그램은 심각하게 복잡해진다.
RTOS의 필요성
기존의 범용 멀티태스킹 OS의 경우, 상대적으로 시간에 엄격하지 않아, Real-Time 요건을 만족시키기엔 부적합하다.
범용(상용) OS와의 차이점
범용 OS는 하드웨어 자원을 효율적으로 사용하고, 얼마나 공평하게 분배할 것인가에 초점을 맞추는데 비해, RTOS는 우선순위가 높은 Task가 보다 많은 자원을 할당하고, 하드웨어 자원의 낭비를 감수하더라도, 작업의 시간제한에 맞추는 것에 초점을 둔다.
RTOS 역할의 확대
지금은 멀티태스킹 뿐 아니라, Network, File System, GUI와 같은 다른 OS 서비스에 대한 필요성도 강조되고 있다.
RTOS는 뭘 갖추어야 하는가?
RTOS는 real-time을 보장해주는 것 뿐 아니라, embedded system환경에 맞는 특성을 갖추어야 한다.
시간적 정확성을 보장하는 멀티태스킹
멀티태스킹 환경에서 모든 OS 서비스 호출과 interrupt에 대한 반응시간의 최대값(WCET, worst case execution time)을 보장할 수 있고, 실행시간의 편차가 작아야 한다. 즉 작업 소요시간을 예측할 수 있어야 한다.
또한 최적화된 성능을 제공하되, 우선순위가 높은 일이 우선적으로 자원을 분배하여, 시간 제한 내에 끝날 수 있도록 해야 한다.
높은 신뢰도와 가용성
Embedded system은 범용 시스템에 비하여, 오작동하거나, 중지되었을 때, 치명적인 경우가 많아 높은 신뢰도와 가용성이 필요하다. 따라서, RTOS 역시 기능은 다소 적더라도 신뢰도와 가용성 확보가 중요하다.
ex. 의료용 X선 장비의 오작동으로 환자 사망. 화성탐사선 제어시스템의 오작동 혹은 중단으로 탐사선 분실.
원자력 발전소 냉각장치 컨트롤러의 중단 등…
작고 유연한 구조
Embedded System의 H/W는( CPU, 메모리 등) 그 사양이 일반적인 컴퓨터 시스템에 비해 열악하다. 따라서 RTOS가 Embedded System 을 지원하기 위해서는 최소의 자원(이를테면 2KB에서 10KB정도의 메모리공간)만을 활용하여 작동할 수 있어야 한다.
또한 각 시스템에 적합한 OS 서비스를 선별적으로 설치하여, 작은 크기를 유지하면서도 다양한 요건에 대응할 수 있어야 한다.
이식성
일반적인 컴퓨터 시스템에 비해 Embedded System은 그 H/W 구성이 훨씬 다양하다. 범용컴퓨터의 CPU는 Intel x86, PowerPC , Sparc 등 몇 가지 유형 중 하나를 사용하지만, Embedded System의 경우, Intel x86, Motorola 6800계열, ARM, StorngARM, MIPS, PowerPC 등 훨씬 다양하다.
RTOS는 이러한 다양한 환경 위에서 작동할 수 있는 이식성을 갖추어야 한다.
ex. VxWorks RTOS의 경우에는 20가지 이상의 CPU지원
RTOS의 기술 요소
RTOS로서 갖추어야 할 요건을 제대로 갖추기 위하여 RTOS에는 다음과 같은 기술들이 적용된다. ( 그러나 이들 기술이 항상 모두 사용되는 것은 아니고 경우에 따라 선택적으로 사용된다. )
우선순위 기반 스케쥴링
시간적 정확성을 보장하는 멀티태스킹
실행 중에 task에 자원을 공평하게 배분하기 보다는, 임무를 완수하는데 보다 중요한 task를 시간 내에 수행하는 것이 중요하므로, task간의 우선순위를 부여한 후, 그에 맞춰 자원을 배분한다.
우선순위 기반 스케쥴링에는 다음과 같은 알고리즘이 있다.
1) 주기단조분석( Rate Monotonic Analysis, RMA )
: 실행 주기가 짧을수록(자주 실행될수록?) 높은 우선순위를 고정적으로 부여
2) Earliest Deadline First( EDF )
: Dead line까지 남아있는 시간이 짧을수록 높은 우선순위를 동적으로 부여
선점형 스케쥴링
시간적 정확성을 보장하는 멀티태스킹
선점형 스케쥴링은 현재 실행 중인 task가 “양보”를 하지 않더라도, 스케쥴러가 컨트롤을 다른 task로 넘겨줄 수 있도록 하는 것이다.
RTOS는 선점형 스케쥴러를 선호하는데, 그 이유는 다음과 같다.
1) 선점형 스케쥴러를 사용하여야, 제대로 우선순위 기반의 스케쥴링을 할수 있다.
만약 실행 중인 task가 “양보”를 한 후에야 다른 task로 컨트롤을 넘길 수 있다면( 비선점형 스케쥴링), 우선 순위가 낮은 task가 제 때 양보를 하지 않아, 높은 우선순위의 task가 무작정 기다리는 일이 발생할 수 있다. 즉 반응 시간의 최대값을 보장하고 예측하기가 곤란해진다.
2) interrupt에 대한 반응시간을 줄이고 그 최대값을 예측가능하게 할 수 있다.
비선점형 스케쥴러에서는 interrupt가 발생했을 때, ISR이 interrupt를 처리한 후, 컨트롤이 현재 실행 중이던 task로 다시 돌아가, 그 태스크가 양보할 때까지 기다린 후, interrupt를 실제 처리한 task가 실행된다. 즉 interrupt에 대한 반응시간이 그 만큼 지연되고, 그 최대값을 보장하거나 예측하기 곤란해진다.
선점형 스케쥴러는 ISR 수행 후, interrupt를 실제 처리할 task로 컨트롤을 넘길 수 있으므로, 현재 실행 중인 task가 양보하기를 기다릴 필요가 없다.
선점형 커널(Preemptible Kernel) – 재진입 가능한(Reentrant) 커널 서비스
시간적 정확성을 보장하는 멀티태스킹
커널 서비스(system call)를 재진입가능하게 작성하여 시간적 정확성을 높일 수 있다.
“재진입가능”하는 것은 어떤 함수를 수행하던 도중 잠시 멈추고 다른 일을 수행하다가 다시 돌아오더라도 아무 문제없이 다시 진행할 수 있다는 뜻이다. 만약 커널 서비스가 재진입 가능하지 않게 작성되어 있다면, 그 서비스가 완결되기전에는 다른 task를 수행할 수 없다. 즉 시간적 정확성이 그만큼 떨어지게 된다.
커널 서비스가 재진입가능하게 작성되었을 때, 즉 system call 이 수행 도중에 잠시 멈추고 다른 task를 수행할 수 있을 때, 그 커널을 선점형 커널이라 부른다.
Semaphore ( Mutual Exclusion / Synchronization)
시간적 정확성을 보장하는 멀티태스킹
멀티태스크 환경에서 task간의 충돌을 방지하기 위해서, 하나의 task가 사용하고 있는 자원을 다른 task가 사용하지 못하도록 막거나( Mutual Exclusion ), 서로 다른 task사이에 실행속도를 맞출( Synchronization) 필요가 있는데, 이를 구현하는 여러 방법 중 세마포어가 시간적 정확성을 가장 잘 보장해 준다.
Mutual Exclusion를 구현하기 위해 다음과 같은 방법을 사용할 수 있다.
1) 공유자원을 사용하는 동안 interrupt 금지
2) 공유자원을 사용하는 동안 스케쥴링 금지
3) 세마포어 사용
interrupt를 금지하는 방법은 interrupt를 놓칠 우려가 있고, 스케쥴링을 금지하는 방법은 우선순위가 낮은 task가 많은 자원을 점유할 우려가 있다. 세마포어는 그럴 우려가 없어 시간적 정확성을 저해하지 않는다.
우선순위 역전( Priority Inversion ) 방지
시간적 정확성을 보장하는 멀티태스킹
우선 순위가 높은 task가 우선 순위가 낮은 task와 semaphore를 공유할 때, 낮은 task가 semaphore를 풀어주기를 “무작정” 기다리느라 같이 늦어지고 중간수준의 task만 실행되는 문제가 발생할 수 있다. 이를 “우선순위 역전 현상”이라 하며 이것을 방지하기 위해, 다음과 같은 기법을 사용할 수 있다.
우선순위 상속( Priority Inheritance Protocol)
높은 task를 기다리게 만드는 낮은 task의 우선순위를 높은 task와 같은 레벨로 (임시로) 올려, semaphore를 빨리 풀어줄 수 있도록 하는 방법
우선순위 한도 제한( Priority Ceiling Protocol)
당장 사용하지 않는 semaphore라 하더라도, 보다 높은 task가 그것을 사용할 가능성이 있으면 낮은 우선순위의 task를 기다리게 하는 방법
è 사실은 명확하게 이해하지 못했음 ^^;;;
Micro Kernel
작고 유연한 구조
OS 커널을 설계할 때, micro kernel과 monolithic kernel의 2가지 접근방법이 있는데, micro kernel이 embedded system에 보다 적합하다.
monolithic kernel 방식은 모든 OS 서비스를 하나의 커널 내에서 구현하는 방법이며, micro kernel은 최소한의 필수 기능만을 kernel에 구현하고, 나머지 OS 서비스들은 선택적으로 설치/수정/제거될 수 있는 모듈 형태로 kernel에 추가할 수 있도록 하는 방법이다.
micro kernel은 OS 서비스 간의 통신 부하나 컨텍스트 스위칭 부하로 인하여 전체적인 성능이 떨어지는 문제가 있지만, 필요한 OS 서비스 만을 선택적으로 설치할 수 있다는 점에서 H/W 환경이 열악한 embedded system에 보다 적합하다. 따라서 RTOS 전용 kernel의 경우에는 micro kernel 방식을 선호한다.
RTOS의 종류
RTOS 전용 커널( small, fast, proprietary kernels )
크기와 성능에 최적화된 커널
상용 OS에 비해, 추가적인 OS 서비스와 소프트웨어 개발 환경이 상대적으로 약하다.
예
eCos, QNX, PDOS, pSOS, VCOS, VRTX32, VxWorks
범용 OS 커널 ( real-time extensions to commercial operating systems )
상용(범용) OS에 실시간 지원기능 추가
뛰어난 기능과 소프트웨어 개발 환경
성능과 시간적 정확성에서 다소 미흡
예
RT-Linux, KURT Linux, RTE-Linux, RT-UNIX, RT-POSIX, RT-MACH, CHORUS
차세대 커널( research operating systems )
“시간적 정확성”을 직접적으로 관리하고자 시도(?)
예
ARX, MARS, SPRING, MARUTI, ARTS, CHAOS, HARTOS
RTOS 의 표준화
POSIX( Portable Operating System Interface )
IEEE의 OS 표준인 POSIX에 real-time 관련 내용을 추가
TRON ( The Real-time Operating system Nucleus )
일본 주도의 표준화
Reference
http://artoa.hanbat.ac.kr/lecture_data/embedded_sw/01.pdf
http://sjlee.sch.ac.kr/arch/arch-grad/발표-18-RTOS.ppt
http://www.ida.liu.se/~TDDB47/lectures/RTOS.pdf
http://cs.chungnam.ac.kr/~ykim/courses/grad-rts2000/notes/rtos-overview.pdf
http://www.netmanias.com/contents/whitepaper/20000318-cmyoo-rtos/rtos1.pdf
http://sinsi.cs.pusan.ac.kr/~idjung/list/hn/devel_es_rtos_for_IA.ppt
http://www.securitytechnet.com/resource/rsc-center/gartner/56450-1.pdf
http://www.dioiz.com/download/an1004.pdf
http://www.china-core.com/data/discourse/WuhanSeminar10.ppt
그런데 너무 무모한 도전이었던 것 같아 조금 후회되네요.. ^^ 워낙 방대하고 전문적인 내용도 많아 소화가 잘 안되는군요 ^^ 일단 나름대로 정리해보고, 다음 기회에 좀더 보충해볼 생각입니다.
RTOS( Real-Time Operating System)
RTOS란?
RTOS(Real-Time Operating System)는 Real-Time (Embedded) System을 위한 운영체계이다. 따라서 먼저 Embedded System과 Real-time System의 정의를 이해할 필요가 있다.
Embedded System
정의
마이크로프로세서 혹은 마이크로 컨트롤러를 내장하여(embedded) 미리 정해진 기능만을 수행하는 장치
cf) PC처럼 사용자가 프로그램을 바꿔가며, 여러 가지 용도로 활용할 수 있다면 그 시스템은 embedded system으로 분류하지 않는다.
응용분야
정보가전, 정보단말, 통신장비, 항공/군용, 물류/금융, 차량/교통, 사무, 산업/제어, 의료, 게임
Real-Time System
정의
“예고 없이 불시에” 발생하는 이벤트에 대하여 “정해진 시간” 내에 “정확한 결과”를 제공하되, 그 응답시간이 “예측가능”하고 일정해야 하는 시스템
즉 시간 상의 제약(Time Correctness, 시간적 정확성)이 중요시되는 시스템이다.
종류
Hard Real-Time System : deadline을 넘기면 처리가 의미 없음
Soft Real-Time System : deadline을 넘기더라도 여전히 처리는 의미 있음, 그 가치는 떨어짐
Real-Time Embedded System
정의
Real-Time 요건을 충족하여야 하는 Embedded System.
범위
대부분의 컨트롤 시스템은 Real-Time Embedded System.
ex) ID 체크 보안시스템, 공장 로봇, ATM(Automated Teller Machine)
RTOS
정의
Real-Time 성격의 어플리케이션을 개발/수행하기 위한 OS.
cf) 많은 RTOS는 Real-Time Embedded System을 위해 설계되고 사용되고 있다.
왜 RTOS가 필요한가?
Real-Time Embedded System을 개발하기 위해, 멀티태스킹과 같은 기능이 중요해지고 있는데, 기존 범용 멀티태스킹 OS는 시간적 정확성을 보장해주지 못해, 이를 지원해주는 RTOS가 필요하다.
멀티태스킹의 필요성
Real-Time Embedded System의 기능이 점점 복잡해져, S/W 개발과 유지보수가 점점 어려워지고, 더 많은 시간과 비용이 필요해지고 있다. 이를 해결하기 위해, 시스템의 기능을 “순차적으로 실행되는 하나의” 프로그램으로 구현하는 대신, 여러 개의 task(multi-task)로 분할하여 개발할 필요가 있다.
멀티태스킹의 형태로 개발하면 다음과 같은 잇점이 있다.
1) 코드의 개발, 수정, 유지, 보수가 보다 용이하다.
2) 이벤트에 대해 보다 신속하게 응답할 수 있다.
( interrupt가 발생하면, 진행 중인 task 대신 interrupt를 처리할 task를 우선적으로 실행할 수 있다. )
3) 시스템의 신뢰도와 성능을 높일 수 있다.
cf) Real-Time Embedded System에서의 멀티태스킹:
범용 시스템의 경우, 멀티태스킹은 서로 무관한 여러 작업( ex. word, email, media-player)을 동시에 수행하는 것을 말한다. 그러나 Embedded System의 경우는 하나의 임무를 수행하기 위해, 동시에 수행되어야 하는 여러 task를 수행하는 것을 말한다. 즉 이들 task들은 하나의 어플리케이션을 구성하는 모듈(부품)이 된다.
멀티태스킹 OS의 필요성
멀티태스킹은 다음과 같은 까다로운 문제를 일으킨다. 이들 문제는 직접 해결하기 보다는 OS를 도입하는 것이 훨씬 효과적이다.
1) task간 경쟁의 관리
2) 데드락
3) 우선순위 역전( priority inversion )
4) 재진입 문제( Reentrancy )
5) task간 통신
ex) ADSL Router
ADSL Router의 경우에, PPP, IP, TCP/UDP 프로토콜을 처리하면서, 동시에 라우터 간의 동기화를 위해 RIP 메시지를 주고받아야 하고, 시스템 관리 정보를 주고받기 위해 SNMP 메시지도 발송하는 등의 여러 task들을 동시에 수행하고 있다. 이것을 multitasking을 지원하는 OS의 도움 없이 “하나의 프로그램”으로 작성할 경우, 이 프로그램은 심각하게 복잡해진다.
RTOS의 필요성
기존의 범용 멀티태스킹 OS의 경우, 상대적으로 시간에 엄격하지 않아, Real-Time 요건을 만족시키기엔 부적합하다.
범용(상용) OS와의 차이점
범용 OS는 하드웨어 자원을 효율적으로 사용하고, 얼마나 공평하게 분배할 것인가에 초점을 맞추는데 비해, RTOS는 우선순위가 높은 Task가 보다 많은 자원을 할당하고, 하드웨어 자원의 낭비를 감수하더라도, 작업의 시간제한에 맞추는 것에 초점을 둔다.
RTOS 역할의 확대
지금은 멀티태스킹 뿐 아니라, Network, File System, GUI와 같은 다른 OS 서비스에 대한 필요성도 강조되고 있다.
RTOS는 뭘 갖추어야 하는가?
RTOS는 real-time을 보장해주는 것 뿐 아니라, embedded system환경에 맞는 특성을 갖추어야 한다.
시간적 정확성을 보장하는 멀티태스킹
멀티태스킹 환경에서 모든 OS 서비스 호출과 interrupt에 대한 반응시간의 최대값(WCET, worst case execution time)을 보장할 수 있고, 실행시간의 편차가 작아야 한다. 즉 작업 소요시간을 예측할 수 있어야 한다.
또한 최적화된 성능을 제공하되, 우선순위가 높은 일이 우선적으로 자원을 분배하여, 시간 제한 내에 끝날 수 있도록 해야 한다.
높은 신뢰도와 가용성
Embedded system은 범용 시스템에 비하여, 오작동하거나, 중지되었을 때, 치명적인 경우가 많아 높은 신뢰도와 가용성이 필요하다. 따라서, RTOS 역시 기능은 다소 적더라도 신뢰도와 가용성 확보가 중요하다.
ex. 의료용 X선 장비의 오작동으로 환자 사망. 화성탐사선 제어시스템의 오작동 혹은 중단으로 탐사선 분실.
원자력 발전소 냉각장치 컨트롤러의 중단 등…
작고 유연한 구조
Embedded System의 H/W는( CPU, 메모리 등) 그 사양이 일반적인 컴퓨터 시스템에 비해 열악하다. 따라서 RTOS가 Embedded System 을 지원하기 위해서는 최소의 자원(이를테면 2KB에서 10KB정도의 메모리공간)만을 활용하여 작동할 수 있어야 한다.
또한 각 시스템에 적합한 OS 서비스를 선별적으로 설치하여, 작은 크기를 유지하면서도 다양한 요건에 대응할 수 있어야 한다.
이식성
일반적인 컴퓨터 시스템에 비해 Embedded System은 그 H/W 구성이 훨씬 다양하다. 범용컴퓨터의 CPU는 Intel x86, PowerPC , Sparc 등 몇 가지 유형 중 하나를 사용하지만, Embedded System의 경우, Intel x86, Motorola 6800계열, ARM, StorngARM, MIPS, PowerPC 등 훨씬 다양하다.
RTOS는 이러한 다양한 환경 위에서 작동할 수 있는 이식성을 갖추어야 한다.
ex. VxWorks RTOS의 경우에는 20가지 이상의 CPU지원
RTOS의 기술 요소
RTOS로서 갖추어야 할 요건을 제대로 갖추기 위하여 RTOS에는 다음과 같은 기술들이 적용된다. ( 그러나 이들 기술이 항상 모두 사용되는 것은 아니고 경우에 따라 선택적으로 사용된다. )
우선순위 기반 스케쥴링
시간적 정확성을 보장하는 멀티태스킹
실행 중에 task에 자원을 공평하게 배분하기 보다는, 임무를 완수하는데 보다 중요한 task를 시간 내에 수행하는 것이 중요하므로, task간의 우선순위를 부여한 후, 그에 맞춰 자원을 배분한다.
우선순위 기반 스케쥴링에는 다음과 같은 알고리즘이 있다.
1) 주기단조분석( Rate Monotonic Analysis, RMA )
: 실행 주기가 짧을수록(자주 실행될수록?) 높은 우선순위를 고정적으로 부여
2) Earliest Deadline First( EDF )
: Dead line까지 남아있는 시간이 짧을수록 높은 우선순위를 동적으로 부여
선점형 스케쥴링
시간적 정확성을 보장하는 멀티태스킹
선점형 스케쥴링은 현재 실행 중인 task가 “양보”를 하지 않더라도, 스케쥴러가 컨트롤을 다른 task로 넘겨줄 수 있도록 하는 것이다.
RTOS는 선점형 스케쥴러를 선호하는데, 그 이유는 다음과 같다.
1) 선점형 스케쥴러를 사용하여야, 제대로 우선순위 기반의 스케쥴링을 할수 있다.
만약 실행 중인 task가 “양보”를 한 후에야 다른 task로 컨트롤을 넘길 수 있다면( 비선점형 스케쥴링), 우선 순위가 낮은 task가 제 때 양보를 하지 않아, 높은 우선순위의 task가 무작정 기다리는 일이 발생할 수 있다. 즉 반응 시간의 최대값을 보장하고 예측하기가 곤란해진다.
2) interrupt에 대한 반응시간을 줄이고 그 최대값을 예측가능하게 할 수 있다.
비선점형 스케쥴러에서는 interrupt가 발생했을 때, ISR이 interrupt를 처리한 후, 컨트롤이 현재 실행 중이던 task로 다시 돌아가, 그 태스크가 양보할 때까지 기다린 후, interrupt를 실제 처리한 task가 실행된다. 즉 interrupt에 대한 반응시간이 그 만큼 지연되고, 그 최대값을 보장하거나 예측하기 곤란해진다.
선점형 스케쥴러는 ISR 수행 후, interrupt를 실제 처리할 task로 컨트롤을 넘길 수 있으므로, 현재 실행 중인 task가 양보하기를 기다릴 필요가 없다.
선점형 커널(Preemptible Kernel) – 재진입 가능한(Reentrant) 커널 서비스
시간적 정확성을 보장하는 멀티태스킹
커널 서비스(system call)를 재진입가능하게 작성하여 시간적 정확성을 높일 수 있다.
“재진입가능”하는 것은 어떤 함수를 수행하던 도중 잠시 멈추고 다른 일을 수행하다가 다시 돌아오더라도 아무 문제없이 다시 진행할 수 있다는 뜻이다. 만약 커널 서비스가 재진입 가능하지 않게 작성되어 있다면, 그 서비스가 완결되기전에는 다른 task를 수행할 수 없다. 즉 시간적 정확성이 그만큼 떨어지게 된다.
커널 서비스가 재진입가능하게 작성되었을 때, 즉 system call 이 수행 도중에 잠시 멈추고 다른 task를 수행할 수 있을 때, 그 커널을 선점형 커널이라 부른다.
Semaphore ( Mutual Exclusion / Synchronization)
시간적 정확성을 보장하는 멀티태스킹
멀티태스크 환경에서 task간의 충돌을 방지하기 위해서, 하나의 task가 사용하고 있는 자원을 다른 task가 사용하지 못하도록 막거나( Mutual Exclusion ), 서로 다른 task사이에 실행속도를 맞출( Synchronization) 필요가 있는데, 이를 구현하는 여러 방법 중 세마포어가 시간적 정확성을 가장 잘 보장해 준다.
Mutual Exclusion를 구현하기 위해 다음과 같은 방법을 사용할 수 있다.
1) 공유자원을 사용하는 동안 interrupt 금지
2) 공유자원을 사용하는 동안 스케쥴링 금지
3) 세마포어 사용
interrupt를 금지하는 방법은 interrupt를 놓칠 우려가 있고, 스케쥴링을 금지하는 방법은 우선순위가 낮은 task가 많은 자원을 점유할 우려가 있다. 세마포어는 그럴 우려가 없어 시간적 정확성을 저해하지 않는다.
우선순위 역전( Priority Inversion ) 방지
시간적 정확성을 보장하는 멀티태스킹
우선 순위가 높은 task가 우선 순위가 낮은 task와 semaphore를 공유할 때, 낮은 task가 semaphore를 풀어주기를 “무작정” 기다리느라 같이 늦어지고 중간수준의 task만 실행되는 문제가 발생할 수 있다. 이를 “우선순위 역전 현상”이라 하며 이것을 방지하기 위해, 다음과 같은 기법을 사용할 수 있다.
우선순위 상속( Priority Inheritance Protocol)
높은 task를 기다리게 만드는 낮은 task의 우선순위를 높은 task와 같은 레벨로 (임시로) 올려, semaphore를 빨리 풀어줄 수 있도록 하는 방법
우선순위 한도 제한( Priority Ceiling Protocol)
당장 사용하지 않는 semaphore라 하더라도, 보다 높은 task가 그것을 사용할 가능성이 있으면 낮은 우선순위의 task를 기다리게 하는 방법
è 사실은 명확하게 이해하지 못했음 ^^;;;
Micro Kernel
작고 유연한 구조
OS 커널을 설계할 때, micro kernel과 monolithic kernel의 2가지 접근방법이 있는데, micro kernel이 embedded system에 보다 적합하다.
monolithic kernel 방식은 모든 OS 서비스를 하나의 커널 내에서 구현하는 방법이며, micro kernel은 최소한의 필수 기능만을 kernel에 구현하고, 나머지 OS 서비스들은 선택적으로 설치/수정/제거될 수 있는 모듈 형태로 kernel에 추가할 수 있도록 하는 방법이다.
micro kernel은 OS 서비스 간의 통신 부하나 컨텍스트 스위칭 부하로 인하여 전체적인 성능이 떨어지는 문제가 있지만, 필요한 OS 서비스 만을 선택적으로 설치할 수 있다는 점에서 H/W 환경이 열악한 embedded system에 보다 적합하다. 따라서 RTOS 전용 kernel의 경우에는 micro kernel 방식을 선호한다.
RTOS의 종류
RTOS 전용 커널( small, fast, proprietary kernels )
크기와 성능에 최적화된 커널
상용 OS에 비해, 추가적인 OS 서비스와 소프트웨어 개발 환경이 상대적으로 약하다.
예
eCos, QNX, PDOS, pSOS, VCOS, VRTX32, VxWorks
범용 OS 커널 ( real-time extensions to commercial operating systems )
상용(범용) OS에 실시간 지원기능 추가
뛰어난 기능과 소프트웨어 개발 환경
성능과 시간적 정확성에서 다소 미흡
예
RT-Linux, KURT Linux, RTE-Linux, RT-UNIX, RT-POSIX, RT-MACH, CHORUS
차세대 커널( research operating systems )
“시간적 정확성”을 직접적으로 관리하고자 시도(?)
예
ARX, MARS, SPRING, MARUTI, ARTS, CHAOS, HARTOS
RTOS 의 표준화
POSIX( Portable Operating System Interface )
IEEE의 OS 표준인 POSIX에 real-time 관련 내용을 추가
TRON ( The Real-time Operating system Nucleus )
일본 주도의 표준화
Reference
http://artoa.hanbat.ac.kr/lecture_data/embedded_sw/01.pdf
http://sjlee.sch.ac.kr/arch/arch-grad/발표-18-RTOS.ppt
http://www.ida.liu.se/~TDDB47/lectures/RTOS.pdf
http://cs.chungnam.ac.kr/~ykim/courses/grad-rts2000/notes/rtos-overview.pdf
http://www.netmanias.com/contents/whitepaper/20000318-cmyoo-rtos/rtos1.pdf
http://sinsi.cs.pusan.ac.kr/~idjung/list/hn/devel_es_rtos_for_IA.ppt
http://www.securitytechnet.com/resource/rsc-center/gartner/56450-1.pdf
http://www.dioiz.com/download/an1004.pdf
http://www.china-core.com/data/discourse/WuhanSeminar10.ppt