티스토리 뷰

Study/EmbeddedSystem

[Study] Real Time Operating System

생각많은 소심남 2013. 3. 5. 16:47

실시간 시스템 수업을 듣는 중 RTOS의 정의에 대해서 정리할 필요성이 있어서 남긴다.


 시스템이란 간단하게 사용자의 입력에 맞는 적절한 출력을 내보내는 기기들의 총집합이라고 생각한다. 그래서 우리가 생활을 하는 주변에도 시스템은 언제나 존재한다. 그 와중에 Computation을 목적으로 삼지 않는 기기들을 따로 Embeded System이라고 한다. 그래서 컴퓨터와 같이 Computation을 바탕으로 돌아가는 시스템이 아닌, 냉장고, 세탁기와 같은 생활 가전 등에 들어가는 시스템을 embeded System이라고 할 수 있다. 예전에는 Cell phone 같은 경우도 임베디드 시스템에 포함시켰는데 요즘은 그 구분이 점점 모호해지는 듯 하다. 

 아무튼 그런 기기들을 보면 단순히 한 가지 기능만 수행하는 것이 아니라 여러 기능들이 함께 제공된다. 당연히 이 기능들을 효율적으로 처리하기 위해서는 OS가 들어가야 한다. 그런데 일반적인 Computing System의 OS의 초점이 복잡하고 다양한 일들을 효율적으로 처리하고 완수하는 데 맞추고 있지만, Embeded System의 OS는 사용자의 반응에 따라 얼마나 빠르게 입력을 처리하냐가 주요 목적이 된다. 따라서 일반 OS와는 다르게 시간이라는 개념이 포함되는 것이다. 결국은 시간이 개입한 OS가 Real Time Operating System이 되는 것이고, 보통은 Embeded System에 많이 적용되기 때문에 Real Time Embeded OS라고도 한다. 물론 시간이 주요 요소인 것이지 완수라는 개념도 RTOS에도 deadline이라는 이름으로 포함되어 있다. Deadline의 중요성에 따라서 System을 Hard한지 Soft한지를 구분하는 경우도 있다.


  아무래도 기존의 OS와 차이점이라면 가장 큰 차이는 사용자가 프로세스의 실행에 조금더 관여할 수 있다는 것이다. 조금더 구체적으로 말하자면 OS의 기본 역할 중 하나가 Task를 어떠한 기준에 맞춰 순차적으로 처리될 수 있게 하는 것인데, RTOS는 이 기준을 사용자가 조절할 수 있다는 것이다. 아주 극단적으로 말하자면 사용자가 급하게 처리해야 되는 프로세스의 우선순위를 확 높여서 시스템 프로세서보다 우선적으로 처리할 수 있게끔 조절할 수 있는 게 가능하다. 즉 이렇게 시간과 우선순위을 통해서 시스템을 굴리는 OS가 RTOS일 수 있겠다. 

 앞에서 계속 시간이 언급된 것처럼 이 시간에 따라 어떻게 처리할지를 결정하는 Scheduler의 역할이 무엇보다 중요하다. 다른 포스트에서 언급한 바와 같이 Kernel 상에 들어있는 Task Scheduler는 RTOS의 핵심이라 할 수 있다. 


<http://www.kalinskyassociates.com/Wpaper7.html>


 Task라는 말이 나왔으니 효율성을 극대화시키기 위해서는 이를 동시에 쓸 생각을 할 수 있고, 이걸 보면 대부분의 사람들이 Multi Task를 떠올릴 것이다. 그런데 사실 엄밀히 말하면 우리가 생각하는 Multi Task와는 약간 다르다.



이 것은 볼 수 있는 임베디드 기기중 하나이다. 이 임베디드 기기에서의 Multi Task라는 것은 위에 번호로 Matching되어 있는 것들이 하나의 목적, 시스템의 동작을 위해서 동시에 처리되는 것을 말한다. 즉, 다르게 말하면 이 장치 또는 모듈들이 하나하나의 Task라고 할 수 있는 것이다. 하지만 우리가 기존에 알던 Multi Task는 전혀 무관한 여러가지 일들이 동시에 수행되는 것을 말한다. 그냥 사람으로 따지면 Task가 수행되는 목적의 차이 정도가 될 듯 하다. 


물론 이렇게 일률적으로 처리되는 Task내에도 Priority를 적용할 수 있으면 현재 대부분의 RTOS는 Priority-based pre-emptive Scheduling을 채용한다. 굳이 한글로 직역하면 우선 순위 기반의 선점형 방식이다. 말그대로 우선 순위가 높은 task가 계속적으로 System 자원을 활용할 수 있는 것이다. 그런데 아마 Operating System을 공부하는 사람이라면 뭔가 이상한 것을 느낄 것이다. 만약 선점형 기법을 사용한다면 순위가 낮은 task는 계속 수행되지 못하는 starvation 현상이 발생하는 것이다. 그래서 다른 방법을 생각해볼 수 있는게 non-preemptive 방식이고, 이게 우리가 사용하고 있는 OS의 Task Scheduling의 기반이다. 그런데 우리가 사용하고 있는 OS는 RTOS가 아니다. 뭔가 이상하지 않은가..

 앞에서 언급했던 내용이지만 RTOS의 관건은 얼마나 빨리, 시간이다. 물론 우리가 PC를 사용하면서 요구하는 것은 얼마나 CPU를 굴리고 좋은 결과를 얻어낼 수 있느냐는 것이다. 결국은 목적 자체가 다른 것이다. 물론 문제가 될 수 있는 starvation을 해결하기 위한 기법으로 도입할 수 있는 것이 앞에서 언급했던 deadline을 활용한 deadline Scheduling 이 있는데 이 부분에 대한 자세한 설명은 링크를 참고하길 바란다. 

이에 대한 공부를 더하면 이전 포스트 중에서 다뤘던 MicroKernel이 RTOS에서 효율적으로 동작하는 것도 알 수 있고, 아무튼 임베디드 시스템의 영역이 확장되어가면서 많이 공부할 부분이다. 자세한 건 Reference로 남긴다. 참고로 kldp에 이와 관련한 흥미가 있었던 주제의 질문이 올라와있어서 이미지로 올려본다. 아마 RTOS를 배우는 이유를 명확히 할 수 있을 듯 하다.


<http://kldp.org/node/45459>


 추가로 이런 RTOS가 올라가는 RT Embeded System에 관해서 조금 정리해볼 필요가 있을 듯 하다.

앞에서 이야기 했던 것처럼 deadline을 활용한 scheduling이 있는데 이것도 scheduling시 deadline의 경중에 따라서 System을 구분지을 수 있다. 가령 Deadline을 중요하게 여기는 시스템, 즉 Hard deadline이 걸려있을 때는 그 동작 자체가 시스템에 큰 영향을 줄 정도로 치명적일 수 있는가 하면, soft deadline의 경우에는 앞의 case와는 다르게 그냥 처리되는 속도의 저하로만 야기하는 정도로 구분할 수 있다. 두번째 요소는 workload의 고정 여부이다. 어차피의 시스템의 특성상 work를 하는 것이 목적이고, 이에 따른 load가 걸리기 마련이다. 하지만 정해진 work을 수행하다 보면 그런 load가 static이겠지만, work가 상황에 따라 가변적이고 주변 상황에 따라 환경이 변하는 경우에는 workload가 Dynamic할 것이다.

 또는 work의 편중에 따라서도 구분할 수 있다. 앞에서 언급한 작은 기기는 사실 일을 그 기기 스스로 처리할 수 있을 정도로 처리하는 work가 매우 작다. 반면에 고성능, 고정밀을 요구하는 일 자체는 이런 embeded system이 단일이 아닌 여러개가 분산적으로 처리되는 것을 요구할 수 있다. 만약 이럴 경우에는 센서나 네트워크라는 외부 요소와 결합시켜서 활용하는 경우도 있을 것이다. 


위와 같이 RT Embeded System을 세가지 측면으로 나눠볼 수 있고, 이를 3차원 그래프 상에 투영시킬 수 있다.



그럼 위에 제시된 것처럼 VOD system과 pacemake는 어떤 축에 놓여질 수 있을까? 일단 VOD system을 먼저 따져보자.

우선 사용자 입장에서 고려해볼 때 VOD system에서 deadline을 고려해보면 아무 의미가 없다. 물론 deadline 이 너무 길면 사용자가 VOD를 시청하지 못한다던간에 문제가 발생할 수 있을 것이다. 하지만 그게 동작을 못하게 하는 치명적인 요소가 될 수 없다. 또한 편중 정도로 따져볼때는 VOD 자체가 network를 바탕으로 운영되는 시스템이기 때문에 사용자별로 나눠서 처리될 것이다. 또한 사용자가 원하면 언제든지 구동이 가능해야 되기 때문에 workload도 dynamic하게 생성될 것이다. 그래서 내가 생각한 답은 Y가 나타내고 있는 지점이다. 

 반면 pacemaker의 경우는 정 반대이다. 동작을 하지 않으면 생명에 지장을 줄 수 있고, 맥박과 관련한 동작이 진행되므로 무엇보다도 static workload가 걸려있어야 한다. 그런걸 고려해볼때는 X의 위치가 적합한게 아닐까 생각한다.

 몇가지 예가 있지만 이에 대한건 읽는 사람 마음대로 :)


Reference

RTOS의 정의 : http://en.wikipedia.org/wiki/Real-time_operating_system

RTOS 간략한 요약 : http://blog.naver.com/PostView.nhn?blogId=websphere&logNo=20001668295

New Direction of RTOS Kernel : http://www.kalinskyassociates.com/Wpaper7.html

Advantage of RTOS : http://www.t-engine.org/onwebseminar/chap2


댓글