OSEK Error Handling — VDX가 제공하는 OS 서비스 오류 식별·통지 체계. 모든 OSEK API는 StatusType을 반환하며, 오류 발생 시 OS는 사용자 정의 ErrorHook 루틴을 호출해 에러 코드와 호출 문맥을 전달한다. OS를 빌드할 때 Standard 또는 Extended Status로 설정해 반환 에러의 범위를 조절할 수 있다.
Status 설정 — Standard vs Extended
OIL에서 OS의 STATUS 속성으로 에러 보고 수준을 고른다.
| Status | 반환 가능 에러 | 용도 |
|---|---|---|
| Standard | E_OK, E_OS_LIMIT만 | 양산·릴리스 빌드 |
| Extended | 아래 9종 전체 + vendor-specific 에러 허용 | 개발·디버그 빌드 |
Extended는 진단용 검증 비용이 추가되므로 릴리스에서는 Standard로 축소한다. (OSEK Hook Routines의 OIL 예시 참고.)
주요 에러 코드
| 코드 | 발생 조건 |
|---|---|
E_OS_ACCESS | ① 이미 점유된 Resource를 다시 점유 시도, ② 정적으로 지정된 Task/ISR 우선순위가 ceiling priority보다 높음, ③ Basic Task에서 ClearEvent / WaitEvent 호출 (Basic Task는 wait 상태 미지원) |
E_OS_CALLEVEL | ISR 또는 Hook Routine에서 허용되지 않은 OS API 호출 |
E_OS_ID | TaskID, EventID 등 API 호출에 유효하지 않은 object ID 사용 |
E_OS_LIMIT | 동일 Task가 동시에 활성화 허용 개수(ACTIVATION)를 초과 |
E_OS_NOFUNC | 점유하지 않은 Resource 해제, 또는 동작 중이 아닌 Alarm 취소 |
E_OS_RESOURCE | Resource 점유한 채로 Task/ISR 종료 |
E_OS_STATE | Activation되지 않은 Task에 event set 등 잘못된 상태 전이 |
E_OS_VALUE | Alarm 설정 시 허용 범위를 벗어난 parameter |
| 기타 vendor 특화 | 예: E_OS_SYS_STACK, E_OS_SYS_PARITY |
Standard 모드에서는 API가 이들을 에러로 반환하지 않고 OS 내부에서 미정의 동작이 될 수 있으므로, 개발 단계에서 Extended로 충분히 검증한 뒤 Standard로 배포하는 것이 일반적인 패턴이다.
ErrorHook — 컨텍스트 조회 메커니즘
OSEK 서비스가 E_OK가 아닌 값을 반환할 때 OS는 [[OSEK Hook Routines|ErrorHook(StatusType error)]]을 호출한다. 훅 내부에서는 다음 두 가지 컨텍스트 정보를 조회할 수 있다.
Service ID — 에러를 일으킨 API 식별.
ServiceIdType sid = OSErrorGetServiceId();
// 예: OSServiceId_ActivateTask, OSServiceId_SetRelAlarm, OSServiceId_SetEvent, ...API 파라미터 값 — OSEK 스펙이 정한 매크로 규칙으로 노출.
OSError_<Name1>_<Name2>()
Name1 : OS 서비스 이름 (예: SetRelAlarm)
Name2 : OSEK 스펙이 정의한 파라미터 공식 이름 (예: AlarmID, increment, cycle)예 — SetRelAlarm 에러 디버깅
void ErrorHook(StatusType error) {
TaskType calling_task;
GetTaskID(&calling_task);
if (OSErrorGetServiceId() == OSServiceId_SetRelAlarm) {
AlarmType id = OSError_SetRelAlarm_AlarmID();
TickType inc = OSError_SetRelAlarm_increment();
TickType cyc = OSError_SetRelAlarm_cycle();
/* id·inc·cyc·calling_task 및 error 로 로그 기록 */
}
}ErrorHook 컨텍스트에서는 스스로가 재호출되지 않으며, OS Service Restrictions에 따라 호출 가능한 OS API가 제한된다.
AUTOSAR Service Protection 확장
AUTOSAR OS(SC3 이상)의 Service Protection은 이 Standard/Extended status 체계를 재사용하되, OSEK이 커버하지 못한 패턴에 대해 추가 에러 코드를 정의한다.
| 추가 코드 | 감지 상황 |
|---|---|
E_OS_MISSINGEND | Task가 TerminateTask / ChainTask 없이 종료 |
E_OS_DISABLEINT | Cat2 ISR이 interrupt locked 상태로 종료 |
E_OS_RESOURCE | Cat2 ISR이 resource 점유 상태로 종료 (OSEK의 동일 코드 재사용) |
E_OS_ACCESS | 권한 없는 cross-OS-Application object 접근 (OSEK 코드 재사용) |
E_OS_CALLEVEL | StartupHook 등 잘못된 context에서 API 호출 |
Service Protection은 ErrorHook으로 이들을 통지하고, 치명적인 stack/timing/memory 사건은 Protection Hook으로 흐른다. 두 훅이 AUTOSAR OS의 에러 대응 양대 경로다.