[07] Introduction to Real-Time Operating Systems

Real-time OS에 대한 소개와 Static RTOS, UNIX-like RTOS에 대해 다룬다.

 

1. RTOS?

Predictable + well structured real-time application의 구현을 간단하게 해주는 resource management + abstraction을 RTOS라고 한다.

• Predictable : worst-case delay를 statically determine할 수 있음
• Resource management & abstraction : 제한적인 HW 자원을 multiplexing + 일관된 interface

 

General purpose PC와 다른 점은 크게

• Full control (no kernel-level)
• Compile time에 시스템 config. 결정
• Predictable worst case
• Resource reservation
• Worload is known and often simple

Well-structured system

RTOS를 사용하는 이유는 development를 간단하게 하기 위해서, well-structured system(certification 관리 용이)을 얻기 위해서, flexibility를 위해서이다.

 

RTOS를 위해서 꼭 필요한 구현 내용은 다음과 같다.

• Task abstraction & scheduler
• Synchronization & communication
• Timers : periodic task를 위해 꼭 필요하다.
• Events / Interrupts

 

현재 RTOS는 굉장히 많이 구현되었으며, 하나의 RTOS로는 모든 goal을 충족할 수 없기도 하고 HW 다양성이 크기 때문이다. 이러다 보니, RTOS 구현에는 여러 방향이 있다.

• Abstraction : portability, correctness
  • 100ms wait하려면 무엇을 기준으로 wait?
• Isolation : fault containment, security
  • memory corruption, WCET overrun, unbounded operation으로 인한 문제
• Predictability : predictable scheduling policy, bounded scheduling latency
  • OS 자체의 optimize로 인한 fairness 문제, power balancing, timer coalescing
• Minimal resource requirements : ROM, RAM, MMU, CPU
  • System blackbox? interaction of components
  • Real system constraint : SWaP (size, weight, power) + cost
• Simplicty : reliability, testing
  • 코드가 잘 작성되었니? clever OS code = buggy / simple OS code = easy to test

 

RTOS complexity는 abstraction, isolation에 비례하며 predictability, simplicty, requirement에 반비례한다.

 

2. RTOS classes

크게 4가지로 분류할 수 있다.

Library RTOS	Static RTOS	UNIX-like RTOS	Separation kernel
limited isolation trust all task low complexity low abstraction low resource requirements	limited isolation trust all task low complexity low abstraction low resource requirements	isolation by default only trust kernel high complexity high abstraction high resource requirements	isolation by default only trust kernel high complexity high abstraction high resource requirements

 

3. Static RTOS

OSEK, AUTOSAR이 대표적인 static RTOS로 industrial system에서 사용되고 있다.

Complexity를 피하기 위해, dynamic resource management를 사용하지 않는다. 따라서 모든 system configuration은 compile time에 결정된다. 보통, single binary image로 컴파일된다.

• RTOS code와 apllication code는 하나의 program
• RTOS는 source와 정교한 build system임
• RTOS vendor는 platform-specific한 portable API 구현 (common building block 사용; tasks, timer, locks)

 

Advantage	Limitation
low overhead simplicity predictability optimization 가능 (unused 지우기) low memory requirements	statically declare 해야함 reuse memory가 어려움 no isolation

Limited resources와 workload가 static하고 fully trusted한 경우에 효과적이다.

 

기본적으로 매우 다양한 static RTOS가 있었지만, protable하지 않아 문제였다. 이를 해결하여 나온 것이 standardize API의 제공을 하는 OSEK과 AUTOSAR이다.

 

3.1. OSEK

기본적인 task는 완료할 때까지 run하며, 실행 중에 block하거나 wait하지 않는다. Extended task의 경우에는 비동기 이벤트에 의해 block하고 wait할 수 있게 구현되었다. 또한 extended task는 특정 자원이 사용 가능해질 때까지 대기할 수 있다.

 

두 개의 interrupt을 가지고 있다.

• ISR1 : OSEK에서 제공하지 않는 interrupt을 위한 것으로 OS 서비스를 invoke할 수 없다.
• ISR2 : OSEK에서 사용하는 interrupt이다.

 

스케쥴링의 경우, 컴파일 타임에 결정되는 preemptive fixed-priority scheduling을 사용한다. 

Core OS API에 대한 스펙이 90 페이지 이하인 것도 특징이다.

 

Periodic task에 대한 구현

Task 단위로 구현하기 때문에, WCET 측정이 가능하며 period 또한 명시적으로 나와있다. 그러나 deadline에 대한 코드는 없다.

 

Sporadic(=event-triggered) task에 대한 구현

ActivateTask()

SetEvent() / WaitEvent() / ClearEvent()

Alarm-callback routines

ISR2를 이용해 MySporadicTask를 활성화하고 있다.

 

Critical section(= shared resource)에 대한 구현

Mutual exclusion이 OSEK [Priority] Ceiling Protocol (PCP)를 통해 구현되어 있다. Resource에 같이 접근하는 task가 없는 경우에만 task를 실행한다. Ceiling은 configuration에서 자동으로 결정된다.

 

4. UNIX-like RTOS

대표적으로 POSIX(Portable OS Interface)와 POSIX-like RTOS가 있다.

 

POSIX에는 4개의 profile을 가지고 있다.

PSE51 - minimal single process no MMU, no disk, no file system	PSE53 - dedicated multiple process MMU single user, no shell networking, full async. I/O stack
PSE52 - controller single process no MMU simplified file system message queue & tracing support	PSE54 - multi-purpose almost full UNIX shell, multi user, security full file system

 

POSIX scheduling

3개의 스케쥴링 policy가 있다.

SCHED_FIFO	SCHED_RR	SCHED_OTHER
preemptive fixed-priority scheduling equal ready task에 대해 FIFO classic response time analysis 가능	preemptive fixed-priority scheduling equal ready task에 대해 Round-Robin not practically useful from analysis POV	unknown policy timesharing for non-real-time tasks Linux로 치면 CFS임 (fair scheduling)

Preemptive fixed-priority는 RM으로 구현한다. POSIX에는 32개의 priority가 있다. (*Linux:1~99)

 

POSIX Periodic Task

Periodic activation with sleep call로 구현되어 있다. (Ready-made task나 periodic alarm abstraction 아님)

현재 코드는 'job()' 함수의 실행 시간이 period에 포함되지 않기 때문에, period+execution time으로 'job()'을 호출하고 있어 올바른 구현이 아니다. 

 

그렇다면 response time을 고려해 코드를 작성하면 해결될 것 같다.

그러나 이 코드 역시 preemption되었을 때 발생하는 시간 차이로 인한 drift 가능성을 배제하였기 때문에, 올바른 구현이 아니다. 가령 처음 시간을 측정하기 이전이나, 두 번째 시간 측정 이후에 preemption되면 period에 오차가 생긴다.

 

올바른 구현은 다음과 같다.

시작 시간을 측정하고, job()을 수행한 후에, 다음 release time을 계산하고 TIMER_ABSTIME 플래그를 사용하여 절대 시간 기준으로 release time이 될 때까지 대기하는 방식이다.

 

POSIX Sporadic(=event-triggered) Task

POSIX에서 event는 file descriptor를 통해 communicate한다.

• Datagram socket (UDP, CAN)
• Stream socket (pipe, TCP)
• Device files (GPIOs, serial ports, buses)

Event를 wait하는 방법은 select()이다.

 

event_source_fd를 기다리다 job(event_source_fd)를 통해 data를 한번에 읽는다.

 

POSIX Resource Sharing

POSIX에서 pthreads를 통해 resource sharing을 지원하며 기본적으로는 어떠한 lock protocol도 사용되지 않는다.  두 가지 uniprocessor에서 사용가능한 real-time locking protocol이 있다.

• PTHREAD_PRIO_INHERIT
  • Low priority thread가 자원을 점유하고 있을 때, high priority thread가 접근하면 Low priority thread를 high priority로 임시 상속 받음
  • Ceiling-based protocol보다 좋지 않음
  • Multiprocessor에서는 어떤 이점도 없음
• PTHREAD_PRIO_PROTECT
  • Resource 보호를 위해 미리 정해진 priority ceiling 설정 *pthread_mutex_setprioceiling()
  • Thread가 resource를 lock하면, 해당 thread의 priority로 ceiling 설정
  • OSEK PCP의 변형임
  • Multiprocessor에서는 제한적인 이점을 제공함