6. OSEK OS-Task

Embbeded system OS ≠ Windows, Linux
OS는 크게 4가지 관리를 한다. process 관리, Memory 관리, I/O device 관리, file 관리가 있다.

Requirements on RTOS

• Determinism
  • 어떤 상태(state)에 있을 때 event가 발생하면 항상 똑같은 반응을 보일 때
  • Deterministic system calls
• Responsiveness(quoted by vendors)
  • Fast process/thread switch : OS가 빠르게 처리해야 한다.(context switching)
  • Fast interrupt response : 실시간성 만족
• Support for concurrency and real-time
  • Multi-tasking
  • Real-time
  • synchronization
• User control over OS policies
  • Mainly scheduling, many priority levels
  • Memory support(especially embedded)
    • pages locked in main memory
    • cache partitioning/coloring on multicore
• Controlled code size

Existing RTOS : 4 categories

1. Priority based kernel for embbeded applications
   ex. OSEK(automotive)
2. Real Time Extensions of existing time-sharing OS
3. Research RT Kernels
4. Run-time systems
   프로그래밍 언어(ex. Ada, Erlang, Real-Time Java...) -> compiler

Micro-kernel architecture

• OS기능 중에서 process관리 기능만 가져와서 kernel의 개념으로 구현하고 있는 것이다.
• 일반 OS와 OSEK은 다르다.
  

Process, Thread, Task

• Process는 병렬처리, Thread는 process 안에서 하나의 address space를 공유하면서 병렬처리, Task는 thread를 규정해주는 작업의 단위
• 하나의 프로그램 상에는 여러개의 task들이 있을 수 있고, 하나의 task로부터는 여러 개의 thread들이 만들어질 수 있다. Process는 프로그램 단위로 만들어진다.
• Process 내에서 thread들은 stack영역(local variable)은 각자지만 static area(global variable)는 공유한다. 따라서 이 영역에서는 synchronization이 필요하다.
  

System philosophy

• Standardised interface
  OS System call API를 표준화 시키자.
• Scalability
• Error checking
• Portability of application software
  
• Special support for automotive requirements
  • 자동차에 특화된 성질
  • running on ROM
  • statically, predictable -> 자동차 OS가 추구하는 핵심적인

Development process for Application

• Executable file = (OS + Lib) + (App) 가 ECU에 targeting되어 프로그램 실행
• 두개의 파일을 만들어야 한다.
  User's source code -> App C programming
  OIL 파일 : OS에 대한 configuration(운영체제를 어떤 형식으로 사용하겠다.)

=> SG가 읽어서 그에 맞는 OSEK OS를 만들어줌, header file도 만들어준다.(Files produced by SG)

• Example
  • OIL file : OS configuration
  • App.c file : user's source code
    
    -> SG가 읽는다.

The service groups

• Task management
  • Activation and termination of tasks
    thread가 시작된 시점을 실행, task의 thread 종료
  • Management of task states, task switching
• Synchronization
  • Resource management
  • Event control
• Interrupt management
• Alarms
  • Relative and absolute alarms
• Intra processor message handling
  task를 start하면 파라미터를 전달할 수 없다. 그 때 사용한다.
• Error treatment

Architecture of the OSEK operating system

• Processing levels

  • interface를 통해 system call 제공

    • Interrupt service routines managed by the operating system
    • Tasks(basic tasks and extended tasks)

    -> OS관점에서 보면 OSEK을 가지고 프로그램을 짜면 OS kernel이 있고, OS kernel에서 제공해주는 API interface가 있고, 돌아가는 루틴을 두 종류로 나눌 수 있다. Task와 interrupt handler가 있다. 이 두가지가 OS kernel의 도움을 받아 서로 병렬로 multitasking이 이루어지도록 한다.

  • OSEK은 세가지 processing levels가 있다.

    1. Interrupt level
    2. Logical level for scheduler
    3. Task level

  • tasks는 세가지 방식으로 스케줄 된다.(non, full or mixed preemptive scheduling)

  • run time context : task가 있으면 정상적으로 실행되기 위한 memory 영역과 필요한 정보를 세팅

    
    Interrupt의 handler는 task보다 priority가 높다. 항상 interrupt handler가 먼저 처리된다.

• priority rules
  • Interrupt의 priority가 높다.
  • Interrupt routine간에도 다른 priority가 주어질 수 있다.
    OSEK에서는 task와 interrupt handler는 자신의 고유한 priority가 사전에 결정되어있어야 한다.
  • 모든 interrupt에 대한 값을 user가 정할 수 있는 것은 아니다.

Task Scheduling

1. Preemptive Scheduling
   priority가 높은 task가 먼저 돈다.
   
2. Non-Preemptive Scheduling
   task가 끝날 때 까지 돈다. Priority가 높아도 바뀌지 않는다.
   
3. Cooperative Scheduling
   자신보다 prority가 높은 task가 오면 낮은 task가 가끔 양보한다.
   

-> task별로 종류를 정할 수 있다. 이를 통해 kernel이 scheduling한다.

Basic and Extended Tasks

• Basic tasks
  • thread가 시작되면 실행되고 끝나는 것(singleshot tasking)
  • 포로세서가 끝날 때만 release 혹은 높은 priority task에 의해 preempted될 때 release
• Extended tasks
  • thread가 시작되고 실행되면 wait가 있고(어떤 특정한 event가 벌어지지 않으면 종료하지 않는다.) 선택적으로 종료한다.
  • Infinity roof로 만들어질 수 있기 때문에 스스로 종료 못 할 수도 있다.

Task States

• RUNNING state : CPU를 점령하고 자신이 돌고 있는 상태, 실행되고 있는 상태
• READY state : Processor가 할당되면 돌 수 있는 상태, priority 때문에 자신은 돌고 있지 못하는 상태
  

Task management

• Task state model : Basic tasks
  
• Task state model : Extended tasks
  

Task switching mechanism

• The scheduler
  • Run되야할 task 결정
  • OSEK OS 내부 activity가 스케줄러에 의해 trigger된다.
  • The scheduler can be considered as a resource which can be occupied and relased by tasks.
• priority별로 queue가 있다. 어떤 task가 activate되면(task의 thread를 시작시키겠다.) 해당 task는 자신에게 할당된 priority를 확인하고 ready queue에서 가장 오래된 task를 돌릴 준비를 한다.
  
  • Basic task는 queue에 한번 들어오면 자신이 ready, running상태가 되면 terminate될때까지 그 상태를 (queue에서) 유지하다가 preemption당하기도 하고 되기도 하면서 돌다가 끝나면 빠져나간다.
  • Extended task는 ready 상태가 되더라도 자신이 wait상태로 빠지면 queue에서 빠져나와 event를 기다리는 wait queue에 들어가고 event가 완료되면 빠져나와 해당 priority queue의 가장 뒤로 다시 들어간다.

Task Priorities

• task의 priority는 statically하게 정의되어있다.
• OSEK Priority Ceiling Protocol
• OSEK은 서로 다른 task가 priority를 share할 수 있다.
• Tasks on the same priority level are started depending on their order of activation

Multiple requesting of task activation

• task를 activate되면 해당 task는 ready가 된다. 같은 task를 동시에 activate시킨다.
• 하나의 task를 여러번 부를 때 얼마까지 부를 수 있는 것인지는 사전에 정의되어 있다.
• Basic task에서만 가능하다. Extended에서는 불가능하다.

OSEK OS Task Attributes

• 5 attributes
  1. Name
  2. Priority
  3. Scheduling
  4. Activations
  5. Autostart

Conformance Classes

oil 파일을 어떻게 만드느냐에 따라서 OS kernel을 4가지 유형으로 나눌 수 있다.

• Conformance classes는 다음과 같은 속성에 의해 결정된다.
  • Task typed : basic or extended
  • Number of tasks per priority
  • Multiple requesting of task activation(Queued Task Activiation)
    하나의 task를 동시에 여러번 active 시키느냐
• Conformance classes의 목적
  • operating system이 가지는 기능을 그룹핑하는 효과가 있다.
  • OS를 제작하는데 있어서 partial implementations
  • upgrade path
• 4가지 유형
  복잡도 : BCC1 -> BCC2-> ECC1 -> ECC2

  1. BCC1
     basic task만 지원, one activation request per task, one task per priority

  2. BCC2
     BCC1 + more than one task per priority possible, multiple activation

  3. ECC1
     BCC1 + extended tasks

  4. ECC2
     ECC1 + more than one task per priority possible, multiple requesting of task activation allowed for basic tasks

     

• Conformance classes가 높아지면 높아질수록 OSEK OS의 복잡도가 커진다. 가능하면 낮은 class의 kernel을 쓸 수 있는 형식의 OS로 만드는 것이 좋다. 그러면 그만큼 kernel이 차지하는 size, 시간이 줄어들 수 있다.

Implementing Tasks

C function과 비슷

• Basic task
  • TerminateTask() : 반드시 호출, OS API, 자기 task를 끝낸다, Task가 종료되고 suspend state로 된다.
• Extended Task Waiting
  • while문
  • WaitEvent : OS API, waitevent가 발생하지 않으면 block된다(ready queue에 들어간다.), 누군가 wait event 걸어주면 다시 ready상태로 되고 run
    

Activating Tasks

Task의 operation : activation(task를 ready state로), termination(task를 suspend state로)

• task는 activate되야만 돌 수 있다.
• Activation은 task를 suspend state에서 ready state로 바꿔주는 것이다. task가 스케줄러의 ready queue에 들어간다.
• Task는 각각의 activation에서 한번만 돈다.
• activation count가 넘어가면 error
• task activation은 다른 task나 (Category 2)ISRs(interrupt handler)에서 시킨다.
• Direct Activation
  
• Indirect Activation
  OS가 자기가 알아서 특정 task 실행
  • Activation by an Alarm
  • Activation by a Schedule Table

Controlling Task Execution Ordering

• Direct Activation Chains
  
• Using Priority Levels
  

Terminating Tasks

• TerminateTask() : task를 suspended state로, 파라미터 가질 수 없다.
• ChainTask(TaskID) : task를 종료시키고 TaskID를 가진 task를 activate
• Task 1이 terminate
  

Resources

• OS의 binary semaphore와 개념이 같다.
  • task, Category2 ISR 사이에서 작동한다.
• critical section에 대해서 배타적인 access(mutual exclusion)를 할 수 있도록 한다.
• resources에 기반한 mutual exclusion mechanism을 제공한다.

Resource management

• Resource management ensures that
  • 2개의 서로 다른 task가 같은 resource를 같은 시간에 차지할 수 없다.
  • priority inversion이 발생하지 않는다.
  • resource에 의해서는 deadlock이 발생하지 않는다.
    priority inversion을 방지하는 protocol 때문
  • resource 때문에 waiting state에 빠지는 일은 없다.
• interrupt level에서도 적용된다.
• resource를 쓸 때 제약
  • 특정 task가 resource를 가진채로 OS API(TerminateTask, ChainTask, Schedule, WaitEvent)를 하면 안된다.(task가 suspent state로 빠지는 것들)
  • Interrupt service routine도 resource를 차지하고 있으면 complete될 수 없다.
  • 한 테스크다 여러개의 resource를 차지하려면 LIFO를 통해 request와 release해야한다.
• Scheduler as a resource
  • RES_SCHEDULER이 자동적으로 생성된다.

Priority Inversion

• task안에서 resource를 사용하게 되면 낮은 priority를 가진 task가 자기보다 높은 priority를 가진 task를 방해한다. 낮은 priority task가 먼저 실행될 수도 있다.
• priority inversion을 피하기 위해 OSEK Priority Ceiling Protocol로 예방한다.
• priority inversion이 벌이지는 이유
  T1이 제일 priority가 높고 T4가 가장 낮다. T4가 가장 먼저 activation 됐다. T1, T2, T3가 들어오면 priority가 높은 T1이 시작된다. 하지만 resource가 T4에게 있어 T4가 끝날때까지 T1은 끝날 수 없다.
  

-> Priority inversion protocol이 해결해준다.

Dead Lock

• 특정 task가 어떤 event나 resource를 점유하고 있고 다른 resource를 기다리고 있고, 다른 task는 특정 task가 점유하고 있는 resource를 기다리고 서로가 물려있어 더이상 진행되지 않는 경우
  
• OSEK에서 basic task에서는 deadlock을 걱정하지 않아도 된다.

-> Priority inversion protocol이 해결해준다.(event가 개입되 않을 때)
하지만 위 사진의 경우에는 deadlock이 발생한다. event를 같이 사용했기 때문이다.

OSEK Priority Ceiling Protocol

• resource에 대해서 ceiling priority가 정해진다.
  해당 resource를 access하는 모든 task들 중에서 priority가 가장 높은 것
• 모든 task는 priority가 사전에 세팅된다. 더불어 어떤 resource를 사용할 것인지도 사전에 세팅된다. 따라서 resource ceiling priority도 사전에 결정된다.
• 해당 resource를 중심으로 2그룹으로 나눌 수 있다. resource를 사용하는 task, 사용하지 않는 task -> 사용하는 그룹의 가장 높은 priority가 resource ceiling priority이다.
• 해당 task가 돌다가 해당 resource를 request하는 경우에 순간적으로 task의 priority가 높아진다.
• Resource가 release되면 다시 낮아진다.
• Resource assignment with priority ceiling between preemptable tasks
  
  T1이 조금 delay는 있다. 하지만 끝나는 순서는 priority순이다.
• Interrupt가 개입했을 때
  interrupt도 영향을 받는다.
  

Resource Configuration

• Resource의 종류
  • Standard resource
    binary semaphore, normal OS semaphore
  • Linked resource
    
  • Internal resource
    • 해당 task가 시작될 때 resource를 get, task가 terminate할 때 resource release
    • 전체 task를 critical section으로 만들고 싶을 때
    
• OSEK OS는 task와 ISRs가 어떤 resource를 사용할지 알고 있어야한다.

Using Resources

Interrupt Service Routines

• Category 1 Interrupts
  • Bare-metal program 방식(하드웨어)으로 작성된 ISRs
  • I/O 입출력 device의 라이브러리만 사용해서 돌아가는 하드웨어에서 인터럽트 발생 시 아무조건 없이 돌아야한다.
• Category 2 Interrupts
  • OS의 kernel을 사용하는 ISR
  • OS가 제공하는 타이머라던가 event, resource를 활용해서 프로그램을 쓰면서 사용하는 ISR