1 Embedded System 이란?
RTOS(Real Time OS)를 논하기 이전에 우리는 먼저 Embedded System 이란 무엇인가를 정의해야 한다. 이유는 이후에 설명할 를 Embedded System 이란 말과 혼용하는 데서 생기는 오용을 막기 위함이다. 쉽게 말하면, Embedded System 은 RTOS 를 포함한다고 볼 수 있다. 즉, 모든 RTOS 를 사용하는 system 은 전부 embedded system 이라고 볼 수 있다. 하지만, 이것 자체로는 정확한 정의가 아니다. 만약 PC 같은 곳에 RTOS 를 사용해서 window 와 같은 것을 만들었다고 했을 때, 이것을 embedded system 으로 볼 것인가라는 문제가 생긴다. 즉, Embedded System 이란 PC 와 같은 시스템과는 차이가 난다는 것을 우리는 인지하고 있다. 그럼 무엇이 이러한 차이점을 만들어 내는 것일까?
많은 Embedded System 을 정의하는 책을 보았지만, 정확히 정의하고 있는 책은 드물다.
그렇다고 그 정의가 절대적인 것도 역시 아니다. 그 중에서 기억에 남는 Embedded System 을 정의하는 구절로는 다음과 같은 것이 있었다.
즉, 사용자가 더 이상의 프로그래밍을 할 필요가 없이 정해진 목적으로만 사용자의 input 에 대해서 반응하는 시스템을 말한다. PC 와 같은 시스템은 만들어진 목적자체가 general 한 시스템으로 특정한 사용처를 염두에 두지 않았다. 즉, 사무용이나, 기타 program 개발용 등 여러 가지 목적으로 사용할 수 있다. 하지만, Embedded System 은 만들어진 것 자체가 특수한 목적을 가지고 있으며, 그 목적만을 잘 수행하면 문제가 될 것이 없는 것이다. 그 목적이 무엇인가에 따라서, 다시 Embedded System 은 Real-Time System 혹은 그렇지 않은 Embedded System 으로 구분될 수 있을 것이다. 즉, Real-Time System 도 실제로는 Embedded System 의 하나의 subset 정도 밖에는 되지 않는다. Windows 와 같은 경우에도 Embedded System 을 구성하는 OS 로 사용할 수 있으며, 편의점의 POS(Post On Sale) 단말기와 같은 곳에서 흔히 발견할 수 있다. 즉, POS 와 같은 시스템은 굳이 Real-Time System 일 필요는 없는 것이다.
Real-Time System 도 크게 2 가지로 나누어진다. 이와 같은 구분은 결과의 유효성이 얼마만큼의 시간 동안 유효한가에 따른 분류이다. 이때 시간이라는 중요한 요소가 생기는데, 그 시간을 흔히 deadline 이라고 표현한다. 모든 Real-Time System 이 반드시 10msec, 1msec, 1usec 와 같이 극히 작은 시간의 단위의 정밀성을 요구하는 것은 아니다. 어떤 시스템의 경우에는 1 초라는 deadline 이 있을 수 있으며, 어떤 시스템의 경우에는 10 초 혹은, 100 초, 혹은 1 년이라는 deadline 이 있을 수도 있다. 하지만, 대부분의 Real-Time System 의 경우에는 시간의 정밀성을 극히 많이 요구하며, Real-Time System 의 성능을 평가하는 요소로 시간의 해상도(resolution)을 사용하기도 한다. 하지만, 궁극적으로 목적하고 있는 일이 무슨 일인가를 통해서, 그 시스템이 요구를 만족시키는가 아닌가를 따져야 하는 것이지, 무조건 더 좋은 resolution 을 가지는 시스템이 좋은 시스템이라는 것은 아니다. 간혹 이러한 것을 혼동해서 필요 이상의 시스템을 구성하는 경우가 있는데, 이는 분명 낭비이다.
Real-Time System 을 deadline 에 따른 결과값의 유효성에 따라 Hard Real-Time System 과 Soft Real-Time System 으로 구분한다. Hard Real-Time System 은 deadline 이전에 반드시 결과 값을 돌려주어야 하는 시스템이며, 만약 deadline 이후에 결과 값을 받는다면, 결과값은 유효하지 않는 것이다. 하지만, Soft Real-Time System 은 deadline 이 지나더라도 그 결과값의 유효성은 떨어지지만 완전히 무효가 되는 것은 아니다. 하지만, 시간의 경과에 따라 점차 그 유효성이 줄어들고, 결국에는 특정 임계 점을 지나게 되면 완전히 무효가 된다. 간단한 예로 흔히 Hard Real-Time System 은 공장의 특정 공정에서 많이 사용되며, 결과가 나오지 않을 경우에 치명적인 오류를 발생시키는 시스템을 말한다. 치명적인 오류는 인명의 손실과 같은 돈으로 계산할 수 없는 것까지 포함될 수 있다. 하지만, Soft Real-Time System 같은 경우에는 이와 같은 것이 경감된다. 흔히 접하는 영상 매체인 경우를 예를 들어본다면, VOD service 와 같은 것이 원활히 보여지게 하려면 초당 26 에서 30 frame 이상을 보여주어야 한다. 하지만, 24 frame 정도만 보여준다고 해서 못 볼 정도는 아닌 것이다. 다만 사용자가 화면의 끊어짐을 파악할 수 있게
되고, 결과적으로 시스템의 성능이 좋지 못하다고 느끼게 된다는 것이다. 따라서, 이와 같은 시스템에서는 사용자의 관점이라는 요소가 크게 작용하며, 임계 치가 얼마인가가 중요하게 된다.
이제 우리는 Embedded System 에 대한 기본적인 것을 파악했고, Real-Time System 이라는 것이 무엇인지도 어느 정도 이해를 했다. 그렇다면, 왜 Real-Time System 에는 Real-Time Operating System 을 사용해야 하는지를 알아보도록 하자.
일반적으로 micom 레벨에서 프로그램하는 것은 프로그램의 특정 부분을 반복적으로 수행하는 구조를 가진다. 즉, event loop 를 돌면서 외부에서 발생하는 event 들에 대해서 특정 함수를호출해서 처리하는 구조를 작성된다. 이때는 굳이 OS 와 같은 것을 사용할 필요는 없다. 하지만, 문제가 될 부분은 분명히 존재한다. 즉, 외부로부터 발생하는 event 가 순서가 정해져 있어야 한다는 것이며, 이 순서에 따라 처리가 일어나게 되므로, 이것 자체가 우선순위(priority)가 된다는 것이다. 따라서, 우선 순위가 잘못된 할당이 된다면, 발생하는 실시간 event 들에 대해서 적절히 대응해 줄 수 없게 된다. 또한, 만약 event 를 처리하는 function 자체가 길어진다면 그 함수의 처리시간에 대한 예측을 할 수 없게 되며, 실시간 event 에 대해서 deadline 을 만족시키지 못하게 되는 경우가 발생할 수 있다. 여기서 우리는 실시간 시스템에서 가장 중요하게 여겨지는 결정성(determinism)이란 것을 배우게 된다. 즉, 모든 시스템의 활동(activity)가 예측 가능해야 한다는 것이다.
RTOS(Real Time OS)를 논하기 이전에 우리는 먼저 Embedded System 이란 무엇인가를 정의해야 한다. 이유는 이후에 설명할 를 Embedded System 이란 말과 혼용하는 데서 생기는 오용을 막기 위함이다. 쉽게 말하면, Embedded System 은 RTOS 를 포함한다고 볼 수 있다. 즉, 모든 RTOS 를 사용하는 system 은 전부 embedded system 이라고 볼 수 있다. 하지만, 이것 자체로는 정확한 정의가 아니다. 만약 PC 같은 곳에 RTOS 를 사용해서 window 와 같은 것을 만들었다고 했을 때, 이것을 embedded system 으로 볼 것인가라는 문제가 생긴다. 즉, Embedded System 이란 PC 와 같은 시스템과는 차이가 난다는 것을 우리는 인지하고 있다. 그럼 무엇이 이러한 차이점을 만들어 내는 것일까?
많은 Embedded System 을 정의하는 책을 보았지만, 정확히 정의하고 있는 책은 드물다.
그렇다고 그 정의가 절대적인 것도 역시 아니다. 그 중에서 기억에 남는 Embedded System 을 정의하는 구절로는 다음과 같은 것이 있었다.
“사용자의 프로그래밍을 필요로 하지 않는 시스템”
즉, 사용자가 더 이상의 프로그래밍을 할 필요가 없이 정해진 목적으로만 사용자의 input 에 대해서 반응하는 시스템을 말한다. PC 와 같은 시스템은 만들어진 목적자체가 general 한 시스템으로 특정한 사용처를 염두에 두지 않았다. 즉, 사무용이나, 기타 program 개발용 등 여러 가지 목적으로 사용할 수 있다. 하지만, Embedded System 은 만들어진 것 자체가 특수한 목적을 가지고 있으며, 그 목적만을 잘 수행하면 문제가 될 것이 없는 것이다. 그 목적이 무엇인가에 따라서, 다시 Embedded System 은 Real-Time System 혹은 그렇지 않은 Embedded System 으로 구분될 수 있을 것이다. 즉, Real-Time System 도 실제로는 Embedded System 의 하나의 subset 정도 밖에는 되지 않는다. Windows 와 같은 경우에도 Embedded System 을 구성하는 OS 로 사용할 수 있으며, 편의점의 POS(Post On Sale) 단말기와 같은 곳에서 흔히 발견할 수 있다. 즉, POS 와 같은 시스템은 굳이 Real-Time System 일 필요는 없는 것이다.
Real-Time System 도 크게 2 가지로 나누어진다. 이와 같은 구분은 결과의 유효성이 얼마만큼의 시간 동안 유효한가에 따른 분류이다. 이때 시간이라는 중요한 요소가 생기는데, 그 시간을 흔히 deadline 이라고 표현한다. 모든 Real-Time System 이 반드시 10msec, 1msec, 1usec 와 같이 극히 작은 시간의 단위의 정밀성을 요구하는 것은 아니다. 어떤 시스템의 경우에는 1 초라는 deadline 이 있을 수 있으며, 어떤 시스템의 경우에는 10 초 혹은, 100 초, 혹은 1 년이라는 deadline 이 있을 수도 있다. 하지만, 대부분의 Real-Time System 의 경우에는 시간의 정밀성을 극히 많이 요구하며, Real-Time System 의 성능을 평가하는 요소로 시간의 해상도(resolution)을 사용하기도 한다. 하지만, 궁극적으로 목적하고 있는 일이 무슨 일인가를 통해서, 그 시스템이 요구를 만족시키는가 아닌가를 따져야 하는 것이지, 무조건 더 좋은 resolution 을 가지는 시스템이 좋은 시스템이라는 것은 아니다. 간혹 이러한 것을 혼동해서 필요 이상의 시스템을 구성하는 경우가 있는데, 이는 분명 낭비이다.
Real-Time System 을 deadline 에 따른 결과값의 유효성에 따라 Hard Real-Time System 과 Soft Real-Time System 으로 구분한다. Hard Real-Time System 은 deadline 이전에 반드시 결과 값을 돌려주어야 하는 시스템이며, 만약 deadline 이후에 결과 값을 받는다면, 결과값은 유효하지 않는 것이다. 하지만, Soft Real-Time System 은 deadline 이 지나더라도 그 결과값의 유효성은 떨어지지만 완전히 무효가 되는 것은 아니다. 하지만, 시간의 경과에 따라 점차 그 유효성이 줄어들고, 결국에는 특정 임계 점을 지나게 되면 완전히 무효가 된다. 간단한 예로 흔히 Hard Real-Time System 은 공장의 특정 공정에서 많이 사용되며, 결과가 나오지 않을 경우에 치명적인 오류를 발생시키는 시스템을 말한다. 치명적인 오류는 인명의 손실과 같은 돈으로 계산할 수 없는 것까지 포함될 수 있다. 하지만, Soft Real-Time System 같은 경우에는 이와 같은 것이 경감된다. 흔히 접하는 영상 매체인 경우를 예를 들어본다면, VOD service 와 같은 것이 원활히 보여지게 하려면 초당 26 에서 30 frame 이상을 보여주어야 한다. 하지만, 24 frame 정도만 보여준다고 해서 못 볼 정도는 아닌 것이다. 다만 사용자가 화면의 끊어짐을 파악할 수 있게
되고, 결과적으로 시스템의 성능이 좋지 못하다고 느끼게 된다는 것이다. 따라서, 이와 같은 시스템에서는 사용자의 관점이라는 요소가 크게 작용하며, 임계 치가 얼마인가가 중요하게 된다.
그림 1. Hard Real-Time System VS. Soft Real-Time System
이제 우리는 Embedded System 에 대한 기본적인 것을 파악했고, Real-Time System 이라는 것이 무엇인지도 어느 정도 이해를 했다. 그렇다면, 왜 Real-Time System 에는 Real-Time Operating System 을 사용해야 하는지를 알아보도록 하자.
일반적으로 micom 레벨에서 프로그램하는 것은 프로그램의 특정 부분을 반복적으로 수행하는 구조를 가진다. 즉, event loop 를 돌면서 외부에서 발생하는 event 들에 대해서 특정 함수를호출해서 처리하는 구조를 작성된다. 이때는 굳이 OS 와 같은 것을 사용할 필요는 없다. 하지만, 문제가 될 부분은 분명히 존재한다. 즉, 외부로부터 발생하는 event 가 순서가 정해져 있어야 한다는 것이며, 이 순서에 따라 처리가 일어나게 되므로, 이것 자체가 우선순위(priority)가 된다는 것이다. 따라서, 우선 순위가 잘못된 할당이 된다면, 발생하는 실시간 event 들에 대해서 적절히 대응해 줄 수 없게 된다. 또한, 만약 event 를 처리하는 function 자체가 길어진다면 그 함수의 처리시간에 대한 예측을 할 수 없게 되며, 실시간 event 에 대해서 deadline 을 만족시키지 못하게 되는 경우가 발생할 수 있다. 여기서 우리는 실시간 시스템에서 가장 중요하게 여겨지는 결정성(determinism)이란 것을 배우게 된다. 즉, 모든 시스템의 활동(activity)가 예측 가능해야 한다는 것이다.
