[펌]OSEK - OS

Y.Evan 님의 허락을 받아 퍼온 글입니다.

블로그 주소 : http://autosar4.tistory.com/

---

• OSEK/VDS
  • OSEK: Offene System und deren Schnittstellen furdie Elektronik im Kraftfahrzeug
  • VDX: Vehicle Distributed eXecutive
• OSEK 표준 주요 환경
  • 표준화된 SW Architecture 제공
  • 확장성 제공
  • 이식성 제공
  • OSEK OS
    • 구동을 위한 논리환경 제공
    • 주요 API
      • Task
      • Schedule
      • GetTaskID
      • Interrupts
      • GetResource
      • Event
      • Alarm
      • StartOS
      • ShutdownOS
      • Hook routines
      • etc

           

  • OSEK COM
    • 내/외부 통신환경 제공
    • 주요 API
      • StartCOM
      • StopCOM
      • GetCOMApplicationMode
      • InitMessage
      • Setflag
      • SendMessage
      • ReceiveMessage
      • GetMessageStatus
      • COMErrorGetServiceID
      • etc
  • OSEK OIL
    • 이식성을 위한 환경 제공
    • 주요 설정 값(OSEK OS와 OSEK COM구동에 필요한 환경 설정)
    • STACKSIZE
    • PRIORITY
    • SCHEDULE
    • ACTIVATION
    • AUTOSTART
    • RESOURCEPROPERTY
    • CATEGORY
    • MESSAGEPROPERTY
    • etc
  • OSEK NM
    • 네트워크 관리환경 제공
• OSEK OS
  • Automotive application SW를 제어하기 위한 운영체제
  • Automotive는 real-time을 요구하기 때문에 event driven control system이 요구된다
  • Application SW와 OS간의 interface는 system service로 정의된다
  • Application SW의 portability와 re-usability를 지원
    • 표준 시스템 서비스와 잘 정의된 기능으로 정의가 되어야 함
    • 유지보수 노력을 줄이고 개발생산성을 높인다
  • 운영체제의 메모리 영영 및 환경설정 영역을 Application에서 설정해야 함
  • 
  • OSEK의 3가지 Processing levels
    • Interrupt level
    • Logical level for scheduler
    • Task level
    • 
• Priority Rule
  • Task level에서 Task는 사용자가 부여한 우선순위에 따라 non, full, mixed로 스케쥴링 된다
  • interrupt가 task보다 우선순위가 높다
  • interrupt processing level은 하나 이상의 interrupt 우선순위로 구성된다
  • ISR은 고정적으로 부여된 interrupt priority level이 있다
  • ISR에 interrupt 우선 순위를 부여하는 것은 수행 및 하드웨어 architecture에 의존적이다
  • task의 우선순위는 숫자가 클수록 우선순위가 높다
  • task의 우선순위는 사용자에 의해 고정적으로 할당된다
  • 스케쥴러에 우선순위를 할당하는 것은 직접적으로 우선순위를 사용하지 않고 수행할 수 있는 논리적인 개념일 뿐이다
• Conformance classes
  • Application SW의 다양한 요구사항과 시스템의 다양한 capability를 을 지원하기 위해 다른 feature의 OS를 지원한다
  • 

       

  • 
• Relationship between OSEK OS and OSEKtime OS
  • OSEKtime OS는 특별히 time triggered architecture에 잘 맞도록 된 OS
• Task management
  • 기능 실행에 대한 프레임워크를 제공
  • OS는 task의 concurrent 실행과 비 동기적인 실행을 제공한다
  • OSEK OS는 task switching mechanism을 제공한다
  • Basic Task
    • wait event가 없다
    • 불필요한 자원사용을 방지하기 위함
    • 다음의 경우 processor를 release
      • 스스로 terminate 할 때
      • OSEK OS가 높은 우선순위 task로 바꿀 때
      • processor를 ISR로 바꾸는 interrupt가 일어날 때
  • Extended Task
    • wait event가 있다
    • waiting state는 processor가 release되도록 하고 실행중인 running extended task를 terminate하지 않고 더 낮은 priority로 재할당
  • Activating a task
    • task activation은 'ActivateTask'나 'ChainTask'를 이용해서 수행
    • 'Parallel implementation and Multiple requesting of task activation'이 가능
  • Task switching mechanism
    • task를 start, trigger 시키기 위해서는 OSEK OS의 internal activity인 scheduler가 필요
    • 실행된 스케쥴링 정책에 따라 task switching이 가능할 때마다 scheduler가 activate됨
    • scheduler는 tasks에 의해 occupied되고 released될 수 있는 resource로 볼 수 있음
    • task는 release될 때까지 task switching을 피하기 위해서 scheduler를 예약 가능
  • Task priority
    • task priority는 고정적으로 부여되며 실행 중에 변화시킬 수 없음
    • same priority를 가진 task는 activating order에 따라 시작됨
• Task State Model
  • 
  • OS에서 복잡도를 줄이기 위한 제한 항목
    • Task의 종료는 task 자신만이 terminate시킬 수 있다(self-termination)
    • Suspended state에서 waiting state로 바로 갈 수 없다
• Scheduler (order of event)
  • 
  • 현재 동일한 priority를 가진 'ready'리스트에서 'preempted task'가 first task로 취급
  • 'waiting state'에서 released된 task는 priority의 'ready queue'에서 last task로 취급
  • 'ready/running' 상태에 있는 모든 task를 조사
  • 'ready/running' 상태에 있는 task의 묶음에서 scheduler는highest priority를 가진 task묶음을 결정
  • 'ready/running'상태와 highest priority에 있는 task 묶음에서 scheduler는 oldest task를 찾음
• Scheduling policy
• Full preemptive scheduling
  • 

       

  • Full preemptive scheduling이란 현재 running중인 task가 os에 의해서 미리 정해진 상황 발생 지침에 의해 rescheduling되는 것을 의미
  • Preemptive scheduling은 더 높은 우선순위의 task가 'ready'가 되자마자 'running' task를 'ready' task로 입력
  • Preemptive scheduling에서 latency time은 lower priority task의 실행시점과는 무관
  • Preemptive scheduling은 더 높은 우선순위의 task가 'ready'가 되자마자 'running' task를 'ready' task로 만듦(우선순위가 높은 것을 실행시키기 위해서 현재 실행중인 우선순위가 낮은 task를 강제로 'ready'상태로 만듦)
  • Task의 일부분이 preempted되지 않으면 시스템 서비스인 'GetResource'를 이용해서 scheduler를 일시적으로 막아서 task가 모두 preempted되도록 할 수 있음(preemptive scheduling은 'GetResource'를 사용함)
  • ISR이 실행되는 동안에는 rescheduling이 수행되지 않음
• Non Preemptive scheduling
  • Lower priority를 가진 'running'중인 task의 non preemptable section은 higher priority를 가진 task의 시작 시점을 다음 rescheduling 시점까지 지연시킴
  • Non preemptable task의 실행은 rescheduling을 일으키는 OS 서비스가 highest task 프로그램 level에서 호출되는 것으로 규정
  • 
• Groups of tasks
  • Mixed preemptive scheduling
    • preemptable task와 non preemptable task의 조합
    • schedule 정책은 running task의 preemption 속성에 따른다
• Application Mode
• Interrupt processing
  • ISR(Interrupt Service Routine) : Interrupt 처리를 위한 기능
    • ISR category 1
      • OS service 사용 X
    • ISR category 2
      • OS service 사용 O
    • 
•  
• Event mechanism
  • 동조화의 수단
  • Extended Task에서만 사용\
  • Waiting state로 들어가거나 나오는 task의 상태 변화(state transition)를 초기화
  • 모든 task는 suspended extended task상태가 아닌 모든 event를 set할 수 있음
  • ISR과 BT는 event사용 불가
  • Extended task는 event의 number를 가지고 있다(owner)
  • 오직 owner만이 event나 wait를 clear할 수 있다
  • OS는 setting, clearing, interrogation을 위한 service를 제공한다
  • 모든 task 또는 ISR2는 suspended task로 빠지지 않도록 event를 set 할 수 있다
  • extended task에 알리기 위해서 모든 event를 통해서 status를 변경
  • 

       

  • 

       

• Resource management
  • Resource management는 다른 우선 순위를 가진 여러 task가 scheduler, program sequences, memory, hardware등의 공유된 resource에 동시에 접속할 수 있도록 공유
  • Resource management는 CC1~CC4까지 모든 클래스에 Mandatory
  • Optional로 task와 ISR의 동시 접근도 resource management할 수 있다
  • 주의사항
    • 두 개의 task와 ISR은 동시에 같은 resource를 차지할 수 없음
    • Priority inversion(도치,역전)은 일어날 수 없음
    • 이런 resource들의 사용에 의한 deadlock은 일어나지 않음
    • waiting state에서는 resource에 접근할 수 없음
  • Resource management는 다음의 경우에 유용하다
    • preemtable tasks
    • non preemtable tasks
    • 유저가 다른 scheduling 정책 아래서 실행된 application code를 가지려 할 때
    • task와 ISR사이에서 resource sharing 할 경우
    • ISR간에 resource sharing 할 경우
  • 모든 resource가 사용 중일 때 ISR이 release한다
  • OSEK은 같은 resource에 중첩된 access를 금지한다
  • Resource가 사용 중일 때 TerminateTask, ChainTask Schedule, WaitEvent는 호출 되면 안 된다
  • 하나의 task에서 multiple resource를 사용하는 경우 유저는 LIFO(stack) 원칙에 따라 request를 해야 하고 release resource를 해야 한다
  • 다른 task들로부터 선점을 보호하려면 scheduler를 lock할 수 있다
  • scheduler는 모든 task에서 resource처럼 다루어 진다(RES_SCHEDULER가 자동적으로 predefine 된다)
  • Interrupt는 RES_SCHEDULER의 상태와 독립적으로 수신하고 처리하지만 task의 rescheduling을 예방할 수 있다
• General problems with synchronization mechanisms
  • Explanation of priority inversion
    • 
    • priority inversion을 피하기 위해서 OSEK은 OSEK Priority Ceiling Protocol을 사용한다
  • Deadlocks
    • 
    • 무한정 waiting 상태에 빠지는 것
  • OSEK Priority Ceiling Protocol
    • OSEK은 priority inversion고 deadlock을 피하기 위해서 다음의 behavior가 요구된다
      • priority는 정적으로 할당 되어야 한다
      • 우선순위가 높은 task는 resource에 access가 가능해야 하고, 우선순위가 낮은 task는 resource에 access가 불가능 해야 한다(더 높은 우선순위의 task가 resource를 access)
      • 만약 resource의 ceiling priority보다 우선순위가 낮은 task가 resource access를 요구하면 resource의 ceiling priority로 priority가 오르게 된다
      • task가 resource를 release하면 이 task는 이전에 요구된 resource에 동적으로 할당된 priority로 남게 된다.
      • 

           

• Internal Resources
  • User에게 보이지 않는 Resource
  • System Function인 GetResource와 ReleaseResource 에 의해 호출 불가
  • System generation 동안에 하나의 internal resource가 호출 될 수 있다
    • resource는 running task로 진입할 때 자동적으로 취한다(이미 취했을 경우 제외), 그 결과 자동적으로 task의 priority는 자동적으로 resource의 ceiling priority로 변한다
    • resource는 자동적으로 release된다
    • Non preemtable task는 같은 priority의 internal resource의 특별한 그룹이다

         

• Resource
  • STANDARD : GetResource와 ReleaseResource를 사용할 수 있음
    • 
    • 현재 Task B가 Activate 상태임
    • Task A가 동작 대기중임(Task B가 Resource를 점유하고 있기 때문에 Task B가 Terminate 될 때까지 기다려야 함)
    • Task B가 Terminate 됨(Resource가 Release됨)
    • Task A가 Activate 된(Task A가 GetResource함), (GetResource 및 ReleaseResource를 사용 할 수 있음)

         

  • LINKED : GetResource와 ReleaseResource를 사용할 수 있음
    • 
    • Task (T1) {

      GetResource

      Activate (T2)

      Activate (T3)

      ReleaseResource

      }

    • 실행순서 : T1 -> T3 -> T2

         

  • INTERNAL :
    • GetResource와 ReleaseResource를 사용할 수 없음
    • app에 의해서 INTERNAL Resource에 접근할 수 없음
    • 
    • 현재 Task B가 Activate 상태임
    • Task A가 동작 대기중임
    • Task B가 Terminate 됨
    • 순서에 따라 Task B가 Terminate된 후, Task A가 Activate 됨
    •  
  • STANDARD & INTERNAL Resource
    • 
    • Task (T5)

      Activate(B)

      Activate(A)

      Activate(X)

      }

    • 실행순서 : T(B) -> T(X) -> T(A)
• Alarm
  • OSEK는 반복적인 event 처리를 위한 service를 제공한다
  • OSEK은 프로세스를 위한 2가지 stage를 제공한ㄷ
    • recurring event는 implementation specific counter에 의해 등록되어 있음
    • Counter에 기초해서 OSEK SW는 application SW는 alarm mechanism을 제공한다
• Counter
  • tick으로 측정되는 counter value에 의해서 Counter가 표현된다
  • OSEK은 counter를 직접적으로 조종하는 standard API를 제공하지 않는다
  • HW or SW로부터 파생된 최소한 하나의 counter를 제공한다
• Alarm management
  • OSEK은 alarm이 만료 되었을 때 activate task, event set, alarm call back routine 서비스를 제공한다
  • alarm-callback routine은 application에 의해 제공되는 짧은 기능이다
• Error handling, tracing, debugging
• Hook routine
  • OSEK은 OS internal processing안에 사용자 정의 action을 위해 system specific hook routine을 제공

       

• Interrupt Service Routines(ISR)
  • EnableAllInterrupts / DisableAllInterrupts
    • 소프트웨어 신호와 하드웨어 신호 모두 차단
    • 이 구간에는 외부의 어떤 Interrupts도 무시됨
    • ISR의 이전상태를 기억하지 않음
    • 
  • SuspendAllInterrupts / ResumeAllInterrupts
    • 소프트웨어 신호와 하드웨어 신호 모두 차단
    • 이 구간에는 외부의 어떤 Interrupts도 무시됨
    • ISR의 이전상태 기억
    • 
  • SuspendOSInterrupts / ResumeOSInterrupts
    • 소프트웨어 신호만 차단
    • 이 구간에는 외부의 소프트웨어에 의한 Interrupts만 무시됨
    • ISR의 이전상태를 기억하지 않음
    • 

 

---

[출처 : http://autosar4.tistory.com/125 ]