본문 바로가기
# Programming/- Embedded 관련 지식

임베디드 시스템의 핵심 기술, RTOS란? - Part.1 (기본 개념 및 특징, FreeRTOS, OSEK/VDX, 용어 정리-Task, Deadline 등)

by Graffitio 2023. 8. 16.
임베디드 시스템의 핵심 기술, RTOS란? - Part.1 (기본 개념 및 특징, FreeRTOS, OSEK/VDX, 용어 정리-Task, Deadline 등)
728x90
반응형
[OS - Operating System]

 

OS란?

 

 

Operating System의 약자로, 운영체제라고 부르기도 한다.

응용프로그램이 요청하는 시스템 자원을 효율적으로 분배하고 관리하는 기능을 하며, 사용자가 컴퓨터를 편리하고 효과적으로 사용할 수 있도록 환경을 제공하는 여러 프로그램의 모임으로 사용자와 하드웨어(입출력, Memory) 간의 인터페이스로서 동작하는 시스템 소프트웨어이다. 즉, 응용프로그램이 요청하는 시스템 자원을 효율적으로 분배하고 관리하는 기능을 한다.

대표적인 운영체제로는 Windows, Mac, UNIX, LINUS가 있다.

  - 기능 -

     ① 응용프로그램이 요청하는 메모리를 허가하고 분배

     ② 응용프로그램이 요청하는 CPU 시간을 제공

     ③ 응용프로그램이 요청하는 입출력 장치 사용 여부를 허가 및 제어

 

1. 시스템 자원(System Resource)

컴퓨터 하드웨어와 같은 개념으로 CPU, 메모리, 입출력 장치, 저장 매체 등 시스템에서 사용할 수 있는 자원을 의미한다.

시스템 자원은 스스로 메모리 확보, 저장 위치, 저장 방법 등을 직접 결정할 수 없기 때문에 반드시 운영체제가 필요하다.

 

2. 응용프로그램(Appliation)

운영체제를 제외한 나머지 소프트웨어로 엑셀, 파워포인트, 액세스 등 사용자가 평소에 사용하는 프로그램을 의미한다.

(소프트웨어 = 운영체제 + 응용프로그램)

응용프로그램은 운영체제의 제어를 받아 운용되기 때문에 종속적인 관계를 가진다.

 


 

운영체제의 구조

 

 

<Kernel>

운영체제는 규모가 매우 큰 프로그램이므로 운영체제의 모든 부분을 메모리에 올려놓는 것은 메모리 측면에서 봤을 때 굉장히 비효율적이다. 따라서 운영체제는 필요한 부분만을 메모리에 올려서 사용하게 되는데, 이때 메모리에 상주하는 운영체제의 핵심 부분을 <커널>이라 한다.

커널은 메모리에 상주하는 부분이므로 운영체제의 핵심 부분이라고 볼 수 있기 때문에, 주로 "운영체제 = 커널" 이라고도 한다.

 

<System Call>

사용자는 운영체제의 기능을 담당하는 커널에 직접 접근할 수 없는데,  이때문에 사용자와 커널 사이에 인터네이스 역할을 하는 기능이 필요하고 이 기능이 바로 <시스템 콜>이다. 즉, 사용자가 커널 영역을 사용할 수 있도록 응용 프로그램이 시스템 자원에 직접 접근하여 필요한 기능을 사용할 수 있게 해주는 함수를 의미한다.

하지만 보통 응용프로그램은 시스템 콜을 직접 사용하지 않고 해당 시스템 콜을 사용하여 만든 언어 별 라이브러리 API를 통해 커널어 접근할 수 있다.

 

<API>

Application Programming Interface의 약자로, 운영체제가 응용 프로그램을 위해 제공하는 함수를 말한다.

 


 

[RTOS의 기본 개념]

 

RTOS란?

 

 

Real-Time Operating System의 약자로, 실시간 응용 프로그램을 지원하기 위해 설계된 운영 체제이다.

실시간 감시 중, 어떤 이벤트가 발생하였을 때 정해진 시간 내에 그에 해당하는 응답이 이루어져야 하는 시스템

(Real TIme은 실시간이라기보다 "정확한 시간"이 더 적합한 표현)

즉, 주어진 시간 내에 우선 순위대로 어떠한 작업을 반드시 처리해야 하는 시스템

 

위와 같은 시스템에서는 작업의 완료 시기가 민감하기 때문에

실시간 응용 프로그램은 지연없이 예측 가능한 시간 내에 작업을 처리해야 하며,

논리적으로 올바르게 계산했더라도 이를 주어진 시간 안에 계산해내지 못하면 의미없기에

따라서 RTOS를 사용한 기기는 응용프로그램을 최대 1초 안에 처리하는 것을 보장하고

이를 위해 RTOS는 특별한 설계와 스케쥴링 알고리즘을 사용하여 작업을 표율적으로 관리한다.

 

 

RTOS의 주요 특징

 

1. Scheduling

RTOS는 작업들 간의 우선순위를 관리하고 CPU 시간을 효율적으로 분배하는 스케쥴링 기능을 제공한다.

이로써 중요한 작업은 높은 우선순위를 부여받아, 더 높은 처리 우선 순위를 가질 수 있다.

즉, 언제 어떤 task를 실행할 지를 결정하는 알고리즘을 제공하는 기능을 한다.

 

2. 인터럽트 관리

RTOS는 H/W Interrupt와 S/W Interrupt를 관리하여, 작업 간의 전환을 가능하게 하며,

중요한 인터럽트나 이벤트에 대한 신속한 응답을 보장하고 짧은 Interrupt Latency를 가진다.

(Interrupt latency : 실제 인터럽트가 발생한 후, 인터럽트 핸들러까지 도착하는 시간)

 

3. 동기화 및 통신

공유 자원에 대한 접근을 동기화하고, 작업 간의 효율적인 통신을 위한 매커니즘을 제공하고,

세마포어, 뮤텍스, 메시지 큐 등의 동기화 및 동신 매커니즘을 지원한다.

 

4. 타이머 및 디바이스 관리

정확한 타이밍을 위해 타이머 및 디바이스 관리 기능을 제공하고 이를 통해 정확한 타이밍 요구를 충족하며

하드웨어 리소스를 효율적으로 사용할 수 있다.

 

5. 작업 관리

작업들의 생성, 삭제, 일시 중단 및 재개를 관리하고 이를 통해 시스템의 동작을 유연하게 제어할 수 있다.

 

6. 작은 Kernel size

 


 

RTOS의 종류

 

1. Hart RTOS

   : 어떤 작업을 일정한 시간 내에 반드시 수행, 처리해야 하며

     그 시간이 지난 경우에는 결과 값이 아무리 정확해도 필요없음.

     (예 : 군사장비, 비행기 시스템, 미사일 시스템)

 

2. Soft RTOS

    : 주어진 시간 안에 처리하면 좋지만,

      그렇지 못한 경우에는 그 시간에서 약간 경과한 후의 값도 인정함.

      (예 : 세탁기, 냉장고)

 


 

GPOS vs RTOS

 

 

특성 GPOS RTOS
용도 다양한 응용 분야에 사용
효율성을 중시함.
실시간 응용 분야에 사용
효율보다는 시간을 중시함.
응답 시간 일반적으로 예측 가능한 응답 시간 엄격한 응답 시간 요구(최대 1초)
스케쥴링 완전성 우선 순위 또는 다중 큐 스케쥴링 우선 순위 기반 또는 시간 분할 스케쥴링
자원 할당 및 관리 동적 자원 할당과 해제 가능  고정된 용량의 자원 할당 및 관리 가능
우선 순위 일반적으로 우선순위 관리가 유연함 엄격한 우선 순위 관리
커널 크기 및 복잡성 큰 크기 및 복잡성을 가질 수 있다 작은 크기와 상대적으로 간단한 구조
이식성 여러 플랫폼에서 동작 가능  다양한 하드웨어 플랫폼에 이식 가능
시스템 완전성 일반적으로 완전성을 보장하지 않음 높은 수준의 시스템 완전성 보장
응용 분야 데스크톱, 모바일, 서버 등 자동차, 의료, 항공 등 실시간 시스템 응용

 

 

코딩 방식의 차이(Firmware vs RTOS)

 

코딩 방식의 차이는 주로 H/W 초기화, Task 관리, 스케쥴링 및 동기화 매커니즘 등에서 나타난다.

요약하면, 다음과 같다.

구분 Firmware RTOS
Coding main funcion에 들어가 초기화 후 진행
(작은 어플리케이션 설계 시 유용함)
Timing requirement를 명시
Superloop에서 모든 작업을 수행 쓰레드 프로그래밍과 흡사하다.
main function은 중요하지 않고,
function을 등록하면 알아서 작동한다.

 

1. H/W 초기화

   <Firmware>

void initializeHardware() {
    // GPIO 초기화
    configureGPIO();
    
    // UART 초기화
    configureUART();
    
    // 타이머 초기화
    configureTimer();
    
    // ...
}

 

   <RTOS>

     : RTOS는 일반적으로 보다 추상회된 레벨에서 하드웨어 초기화를 처리한다.

       플랫폼마다 다르지만, 하드웨어 초기화는 RTOS 내부에서 처리되기도 하며, 따라서 RTOS를 사용할 때

       개발자가 직접 하드웨어 초기화를 작성하지 않아도 될 수 있다.

 

2. Task, Scheduling

   <Firmware>

void main() {
    while (1) {
        // 주요 작업 실행
        processMainTask();
    }
}

 

   <RTOS>

      : RTOS를 사용할 경우, 태스크를 정의하고 운영체제에게 스케쥴링을 맡긴다.

        각 태스크는 우선 순위와 실행 주기를 가지며, RTOS는 스케쥴링을 통해 작업을 관리한다.

void task1() {
    // 태스크 1의 동작
}

void task2() {
    // 태스크 2의 동작
}

int main() {
    // 태스크 생성
    createTask(task1, priority1, period1);
    createTask(task2, priority2, period2);
    
    // RTOS 시작
    startRTOS();
}

 

3. 동기화 및 통신

 

   <Firmware>

void main() {
    // 인터럽트 비활성화
    disableInterrupts();
    
    // 공유 데이터 접근
    accessSharedData();
    
    // 인터럽트 활성화
    enableInterrupts();
    
    // ...
}

 

   <RTOS>

     : RTOS는 세마포어, 뮤텍스, 메시지 큐와 같은 동기화 매커니즘을 제공하여

       Task간의 안전한 데이터 공유와 통신을 관리한다.

SemaphoreHandle_t sem;

void task1() {
    // 세마포어 대기
    xSemaphoreTake(sem, portMAX_DELAY);
    
    // 공유 데이터 접근
    accessSharedData();
    
    // 세마포어 반환
    xSemaphoreGive(sem);
}

void task2() {
    // 세마포어 대기
    xSemaphoreTake(sem, portMAX_DELAY);
    
    // 다른 공유 데이터 접근
    accessOtherSharedData();
    
    // 세마포어 반환
    xSemaphoreGive(sem);
}

 

 

RTOS의 구성

 

 

RTOS는 커널(Kernal), File system, Networking Protocols stack, 특정 응용에 필요한 여러 가지 요소 등

다양한 모듈(Module)의 조합으로 구성되며, 커널로만 구성되는 경우도 있다.

 

<Kernal>

: 커널은 하드웨어와 응용 프로그램간의 상호작용을 관리하며,

  실시간 응용 프로그램을 스케쥴링하고 제어하는 역할을 한다.

 

 

1. Schedular

    : 커널에 포함되어 있으며, 언제 어떤 Task를 실행할 지 결정하는 알고리즘을 제공한다.

      대표적인 스케쥴링 알고리즘의 예는 'round-robin' 스케쥴링과 'preemptive' 스케쥴링이 있다.

 

2. Object

    : 개발자가 실시간 임베디드 시스템용 응용 프로그램을 만들 때 사용하는 특별한 구조체이다.

      대표적으로 'tack', 'semaphore', 'message-queue' 등이 있다.

 

3. Service

    : 커널이 오브젝트를 대상으로 수행하는 동작을 의미한다.

      대표적으로 Timer, Interrupt, Memory/Device management 등이 있다.

 


 

[RTOS의 여러가지 형태]

 

FreeRTOS

 

실시간 응용프로그램을 위한 오픈소스 RTOS이다.

Free라는 수식어가 붙은 이유는 누구나 사용 가능하고, 상업용으로 사용해도 비용을 지불하지 않아도 되기 때문이다.

 

주요 특징

  - 기타 고성능 OS(Linux, Windows, iOS, Android 등)와는 다르게 1초 내에 Task의 작업을 끝내는 것을 보장한다.

    즉, 단순히 빨리 끝내는 것이 아니라 작업의 처리를 보장한다.

  - 실시가 처리가 필요한 시스템(국방 시스템, 안전 보조 장치 등)에 많이 사용된다.

  - RTOS가 활용되는 기기는 거의 대부분 임베디드 시스템이다.

  - 응용 프로그램의 처리 요청을 정해진 시간 내에 끝마칠 수 있는 성능에 중점을 두고 있다.

  - 선점형 멀티 태스킹을 지원하고 각 프로세스의 실행 순서를 지정해 효율적은 처리가 가능하다.

  - 100% 완전 무료이며, 보증 및 기술적인 법적 보호는 지원하지 않는다

    (OpenRTOS는 보증과 법적 보호까지 지원함.)

 

 

OSEK/VDX

 

OSEK은 Operating System Embedded Kernel의 약자로,

실시간 임베디드 시스템을 위한 표준화된 운영 체제 커널이며,

차량용 임베디드 시스템을 위한 운영체제, 통신 stack 및 네트워크 관리 프로토콜을 만든

표준 기관 혹은 규격 그 자체를 말한다.

VDX(Vehicle Distributed eXecutive)는 OSEK의 자동차 분야에서의 확장 버전인 OSCK/VDX의 약자이다.

자동차 업계에서는 AUTOSAR의 근간이 되는 OSEK OS를 실시간 운영 체제의 표준으로서 사용하고

이는 자동차 제어 및 통신 시스템에서 실시간 요구 사항을 충족시키기 위해 설계되었다.

 


 

[RTOS 용어 정리]

 

RTOS Scheduling

 

1. 의미

RTOS에서 Task들을 어떻게 실행할 지 결정하는 프로세스를 의미한다.

RTOS는 다양한 스케쥴링 알고리즘을 제공하여 Task들의 우선순위, 실행 주기, 처리 시간 등을 관리하고

효율적으로 할당한다.

 

2. Sequence

.

  • Workload : Task를 의미한다.
  • RTOS schedular는 CPU를 활용하여 N개의 Task들의 우선순위를 지정해준다
  • 이후 프로세서가 resource되어 Workload(Task)들을 순차적으로 해결.
  • 자동차 제어 분야에서는 아직 Singlecore CPU를 많이 사용하지만, 점차 Multicore가 대두되고 있는 추세이다.
  • RTOS Schedular의 목적 : 모든 Task의 Timing requirement를 만족시키는 것.

 

3. 프로그래머 관점에서의 Workload

.

프로그래머 관점에서의 Workload는 Task와 ISR과 같은 것이다.

RTOS에서 프로그래밍을 할 때는 Firmware programming과 달리, main function을 건드리지 않고(OS가 가지고 있음.)

Task, ISR을 function 형태로 작성하여 OS에게 제공하게 되고 OS는 이 function을 활용하여 scheduling한다.

 

cf)

Task와 ISR의 차이

   - Task : 정해진 주기마다 OS가 trigger시켜준다.

                OS에게 주기를 알려주면, OS가 정해진 시간에 해당 함수 호출

   - ISR : OS가 아닌, H/W interrupt 발생 시 호출된다.

 

 

Task & Jobs

 

.

1. Task

    : 실행 가능한 독립적인 작업 단위

      이 작업 단위는 프로세스나 함수와 같은 의미를 가지며,

      RTOS는 이러한 Task들을 스케쥴링하여 실행한다.

 

2. Jobs

    : 태스크의 실행 단위로서 태스크 내부에 정의된 동작을 의미한다.

      Job들의 묶음들이 Task

      Task A가 10ms마다 한 번씩 실행된다면, 각 주기마다 실행되는 instance를 job이라 부르고

      그 모음을 task라 부른다.

 

 

Task Offset

 

.

- Task의 실행이 시작되는 시점을 나타내는 값을 의미한다.

- Task offset은 주로 주기적으로 반복되는 실시간 작업에서 사용되며, Task의 시작 시간을 정의하는데 사용된다.

- Time을 처음 초기화할 때(시스템 시작 시) task를 동시에 Release할 수 있지만,

  각각을 Shifting시켜서 release할 수도 있다.

  위 그림처럼 일정 시간의 Delay를 두고 실행시키는 것을 Task Offset이라 한다.

 

 

Release time & Deadline

 

.

1. Release Time(Task 실행 시간)

    : Task나 작업이 시스템에 도착하여 실행 가능한 상태가 되는 시간

      즉, Real-Time 작업이 시스템에 들어와 작업이 시작될 수 있는 시간을 의미하며

      스케쥴링 알고리즘에서 해당 작업을 언제 실행할 지 결정하는데 사용된다.

      이때, 여러 가지 job들이 동시에 release될 수는 있지만,

      CPU가 하나라면 다른 job는 실행이 미뤄져야 한다.

 

2. Deadline

    : Task나 작업이 완료되어야 하는 시간 제한

      Deadline을 지키지 못하면 시스템이 실시간 성능 요구 사항을 만족시키지 못할 수 있다.

      RTOS에서 가장 중요한 개념 중 하나로, Deadline을 만족시키기 위해 작업의 실행이

      타이밍에 맞게 이루어져야 한다.

      job의 실행은 밀릴 수 있지만, 어디까지 밀려도 되는가? 와 관련있는 것이 바로 Deadline

      따라서 Task는 Release time와 Deadline 사이에서 실행되면 문제없다.

 

 

Release Time의 종류

 

1. Periodic Task

 

주기적으로 Release되는 Task

 

2. Sporadic Task

 

Release와 그 다음 Release까지의 minimum gap을 의미

 

3. Aperiodic Task

 

규칙이 없는 Task

 

 

Deadline의 종류

 

1. Absolute Deadline

 

Deadline을 절대적인 단위로 표현한다.

 

2. Relative Deadline

 

Deadline을 Release tile과 상대적으로 비교

3. Implicit Deadline

 

-------Deadline에 대한 별도의 언급이 없다면, Deadline은 다음 job의 Release time(주기)이 된다------(대부분 여기에 해당)

 

4. Constrained Deadline

 

Deadline이 Period보다 작은 경우

 

 

Execution Time

 

.

    Task나 작업의 실행 시간을 의미한다.

    이는 해당 Task나 Job(작업)이 CPU에서 얼마나 오랜 시간동안 실행되는지를 나타내며,

    이 정보를 통해 스케쥴링 알고리즘이 Task를 어떻게 할당할 지 결정한다.

     job을 실행시킬 때마다 cache의 상태, 분기문의 실행이 달라지므로 같은 task의 서로 다른 job의

    실행 시간이 달라질 수 있고 이때문에 task의 execution time을 정의할 방법이 필요하다.

 

따라서 위와 같이 Task의 실행 시간을 측정하기 위해, 다양한 입력 값을 주어 정규분포를 그린다.

그림에서 하얀색 분포가 실제 실행시켜 측정한 실행시간(Measured execution time)을 나타내지만,

이 분호가 모든 경우를 커버할 수는 없다.

이 때, 검은색 분포(Possible execution time)는 해당 task의 실제 실행 시간이고

우리가 알고 싶은 부분은 검은색 부분인데, 실제로는 측정 불가능하다.

 

① BCET(Best Case Executuin Time)

    : Task나 Job이 가장 이상적인 조건에서 실행될 때 걸리는 최소 실행 시간

      주로 최적화된 컴파일러나 특정 입력 데이터에 대한 실행 시간을 예측할 때 사용된다.

 

② WCET(Worst Case Execution Time)

    : Task나 Job이 가장 악화된 조건에서 실행될 때 걸리는 최대 실행 시간

      RTOS에서 중요한 개념 중 하나로, 시스템의 실시간 요구 사항을 충족시키기 위해

      반드시 고려되어야 하며, 이를 분석해주는 SW도 존재한다.

 

 

참조

http://www.kocw.net/home/search/kemView.do?kemId=1188160

728x90
반응형