AUTOSAR OS — AUTOSAR Classic Platform의 OS 계층. OSEK OS의 확장판으로, OSEK API와의 backward compatibility를 유지한 채 Schedule Table, Stack Monitoring, Protection Hook, Timing Protection, OS-Application, IOC, Call Trusted Function, Memory Protection, Service Protection을 Scalability Class(SC) 별로 선택 제공한다.
OSEK 대비 확장 기능
| 기능 | OSEK | AUTOSAR OS |
|---|---|---|
| Task / ISR / Resource | ✅ | ✅ (그대로 상속) |
| Counter / Alarm | ✅ | ✅ |
| Hook Routines | ✅ | ✅ + ProtectionHook |
| Schedule Table | ✗ | ✅ |
| Stack Monitoring | ✗ | ✅ |
| Timing Protection | ✗ | ✅ |
| Memory Protection | ✗ | ✅ |
| OS-Application / IOC | ✗ | ✅ |
| Service Protection | ✗ | ✅ |
| Multi-Core 지원 | ✗ | ✅ (SC4, 2009년~) |
Scalability Class (SC)
4개 SC로 기능을 선택적으로 활성화해 footprint·오버헤드를 조절한다. SC가 올라갈수록 누적 제공.
| SC | 제공되는 주요 Service |
|---|---|
| SC1 | OSEK OS (backward compatible) / SWFRT(Software Free-Run Timer) / Counter (OSEK Counter 제어 API 추가) / Schedule Table / Stack Monitoring |
| SC2 | SC1 + Protection Hook + Timing Protection |
| SC3 | SC1 + Protection Hook + OS-Application + IOC + Call Trusted Function + Memory Protection + Service Protection |
| SC4 | SC2 + SC3 (모든 기능) |
[SRS_Os_00097]The OS shall provide an API that is backward compatible to the API of OSEK OS.
non-trusted application은 전체 시스템에 영향을 주지 않도록 권한이 제한된다 (예: ShutdownOS 호출 불가).
Schedule Table
여러 Alarm을 묶어 하나의 주기적 테이블로 관리하는 구조. 테이블 1회 순환 동안 발생할 Task Activation / Event Setting을 Expiry Point들로 고정 선언한다.
구성 요소
- Expiry Point — 테이블 시작 기준 Offset이 지난 시점에 Action(Task activation 또는 Event setting)을 수행
- Initial / Final Expiry Point — 테이블 시작·끝 시점
- Offset — Expiry Point의 상대 tick
- Duration — 테이블 1회 길이 (예: 50 ticks)
동작
- Initial Expiry Point부터 Final Expiry Point까지 offset 증가 순서로 처리
- 다수의 Schedule Table을 동시에 처리 가능
- 반복 모드:
- Single-shot — 한 번 실행 후 종료
- Repeating — 반복 실행
- 설정에 따라 Startup 시 자동 시작 또는 직접 호출을 통한 시작
OSEK Counter와 Alarm의 Counter 메커니즘 위에서 동작하며, 서로 관련된 여러 이벤트의 시점 관계를 한 테이블로 캡슐화해 Time-Triggered 스타일 실행을 OS 레벨에서 직접 지원한다.
Stack Monitoring (SC1+)
Task/Cat2 ISR의 stack overflow를 OS가 감시하는 SC1 기본 서비스.
- 검사 대상: Task, Category 2 ISR
- 검사 시점: context switching 시점 — 다른 Task/ISR로 전환될 때 직전 주인의 stack 크기 확인
- 한계: 연속 overflow라도 다음 context switch까지 감지되지 못하므로, 에러 발생 후 발견까지 시간이 흐를 수 있음
- SC3/SC4의 경우 Memory Protection이 먼저 Trap을 일으켜 stack fault보다 memory protection error로 보고되기도 함
Stack fault 감지 시 처리:
- ProtectionHook 설정됨 →
[[Protection Hook|ProtectionHook(E_OS_STACKFAULT)]]호출 - ProtectionHook 미설정 →
ShutdownOS(E_OS_STACKFAULT)호출
Protection Hook (SC2+)
OS가 감지한 심각한 에러에 대해 사용자 정책을 적용하는 복구 훅. 감지되는 4대 카테고리(Stack Fault / Timing / Instruction Exception / Memory)와 5가지 반환 옵션(PRO_IGNORE / PRO_TERMINATETASKISR / PRO_TERMINATEAPPL / PRO_TERMINATEAPPL_RESTART / PRO_SHUTDOWN) 상세는 Protection Hook 참고.
Timing Protection (SC2+)
런타임에 Task/ISR의 시간 계약을 OS가 강제하는 메커니즘. Real-time system에서 timing fault가 발생했을 때, deadline을 놓친 Task가 항상 원인은 아니라는 점을 해결하기 위해 가해자를 직접 식별해 ProtectionHook을 호출한다.
3가지 Timing Fault
| 종류 | 조건 | 에러 코드 |
|---|---|---|
| Execution Budget | Task/ISR의 execution time이 선언된 상한을 초과 | E_OS_PROTECTION_TIME |
| Lock Budget | 공유 resource lock / interrupt disable로 발생시킨 blocking time이 상한을 초과 | E_OS_PROTECTION_LOCKED |
| Time Frame | 같은 Task/ISR 간 inter-arrival time이 하한보다 짧음 (= 너무 잦은 activation). 예상 외 빈번 인터럽트, 설계 주기 불일치 검출 | E_OS_PROTECTION_ARRIVAL |
Execution Budget은 “혼자 너무 오래 쓰지 말 것”, Lock Budget은 “남을 막는 시간을 너무 길게 갖지 말 것”, Time Frame은 “너무 자주 오지 말 것”을 강제하는 계약이다.
설정 항목
- Timing Protection 이름
- Task/ISR 최대 수행 시간
- Resource lock 사용 시 최대 시간 + 대상 resource
- 모든 인터럽트 정지 최대 시간
- Cat2 인터럽트 정지 최대 시간
- Task/ISR inter-arrival time의 최소값
OS-Application · IOC · Call Trusted Function (SC3+)
OS 객체를 기능 단위로 묶고 애플리케이션 간 격리·통신을 제공하는 SC3 핵심 확장.
- OS-Application — Task/ISR/Alarm/Schedule Table/Counter를 묶는 기능적 그룹. 3-state 모델 (ACCESSIBLE/RESTARTING/TERMINATED), Trusted/Non-Trusted 구분, 접근 권한 명시
- IOC — App. 간·Core 간 정보 전달. Memory Protection을 넘나드는 유일한 허용 경로
- Call Trusted Function — Non-Trusted OS-App.이 Trusted OS-App.의 함수를 권한 상승 호출 (OS-Application에서 상세 설명)
Memory Protection (SC3+)
MPU (Memory Protection Unit) 기반으로 Task/ISR이 허가되지 않은 메모리 영역에 접근하지 못하도록 보호하는 서비스.
보호 대상 영역
| 영역 | 저장 위치 |
|---|---|
| Code | Flash |
| Data | Flash (const), RAM (bss·data) |
| Stack | RAM |
조건·제약
- SC3 또는 SC4 선택 필수
- HW 지원 필요 — AURIX의 경우 Trap Class 1(Internal Protection Traps)에서 정의
- OS가 관리하는 object에 대해서만 보호. Library 영역은 대상 외
접근 규칙 (App. 타입별)
| 권한 | Trusted OS-App. | Non-Trusted OS-App. |
|---|---|---|
| 자기 code·data | 접근 가능 | 접근 가능 |
| 타 App./OS data 쓰기 | 가능 | 불가 |
| 타 App./OS data 읽기 | 가능 | 설정에 따라 읽기 허용 또는 차단 |
Memory Access Violation
권한 없는 접근 발생 시 [[Protection Hook|ProtectionHook(E_OS_PROTECTION_MEMORY)]] 호출. 한 애플리케이션의 버그가 다른 애플리케이션의 stack/data/code를 덮어쓰지 못하게 한다 (Adaptive Platform의 MMU 기반 가상 주소 공간과 대비).
Service Protection (SC3+)
잘못된 OS Service 사용으로 OS 내부가 corruption되는 것을 방지. OSEK이 커버하지 못한 case에 OSEK OS의 error status 체계를 확장 적용한다 (OSEK Error Handling과 연결).
감지되는 패턴
| 패턴 | 반환 코드 |
|---|---|
| OS API에 유효하지 않은 parameter | E_OS_ID / E_OS_VALUE |
잘못된 context에서 OS API 호출 (예: StartupHook에서 ActivateTask) | E_OS_CALLEVEL |
Task가 TerminateTask / ChainTask 없이 종료 | E_OS_MISSINGEND |
| Cat2 ISR이 interrupt locked 상태 / resource 점유 상태로 종료 | E_OS_DISABLEINT / E_OS_RESOURCE |
Non-Trusted OS-App.에서 ShutdownOS 호출 | 무시 |
| 권한 없는 cross-OS-Application object 접근 | E_OS_ACCESS |
OSEK의 Extended Status 체계를 재사용하되, AUTOSAR는 위 코드들을 추가해 에러 통지 범위를 확장한다.