정의
타이밍 파라미터는 태스크와 인터럽트 서비스 루틴의 실행을 계측할 때 쓰는 시간 값들이며, 활성화·시작·종료 세 시점과 그 사이에 벌어지는 선점을 기준으로 정의된다.[1]
실행 시간을 하나의 수로 말하면 곧 어긋난다. 같은 태스크라도 “실제로 CPU를 잡고 있던 시간”과 “시작해서 끝날 때까지 흐른 시간”이 다르고, 후자는 그 사이에 누가 선점했느냐에 따라 매번 달라진다. 계측 결과를 요구사항과 견주려면 무엇을 재고 있는지가 먼저 고정되어야 한다.
기준이 되는 세 시점은 규격에도 그대로 들어 있다. 실행 단위가 “시작될 예정” 상태로 들어간 시점이 활성화, 활성화 뒤 실제로 시작된 시점이 시작, 실행을 마치고 종료 상태로 들어간 시점이 종료다.[2] 상태 사이를 오가는 규칙 자체는 OSEK 태스크가 정한다.
실행 시간
CET(core execution time)는 running 상태에 머물며 실제로 명령을 실행한 시간이고, GET(gross execution time)는 시작에서 종료까지 흐른 시간이다.[1] 선점이 한 번도 일어나지 않으면 두 값은 같고, 선점이 끼어들면 CET는 여러 조각으로 나뉜 채 그 합만 남는 반면 GET에는 선점당한 시간이 그대로 포함된다.
총과 순을 가르는 다른 기준
AUTOSAR 타이밍 확장도 실행 시간을 총(gross)과 순(net)으로 나누지만 가르는 기준이 다르다. 양쪽 모두 다른 엔티티에 의한 중단을 빼고 재며, 외부 호출을 포함하면 총, 포함하지 않으면 순이다.[2] 선점 포함 여부로 갈리는 CET와 GET의 대비와 혼동하지 않아야 한다.
대기와 응답
IPT(initial pending time)는 활성화된 뒤 실제로 시작하기까지 ready 상태로 기다린 시간이다. PRE(preemption time)는 IPT를 뺀 나머지 ready 시간의 합, 곧 시작한 뒤에 선점당해 밀려 있던 시간이다.[1]
RT(response time)는 활성화부터 종료까지의 시간이며 스케줄가능성 분석에서 다루는 그 응답 시간이고, DL(deadline)이 이 값에 걸리는 상한이다. 규격도 같은 값을 두고 “다른 엔티티에 의한 중단과 외부 호출을 포함해 실행 단위를 수행하는 데 걸리는 시간을 흔히 응답 시간이라 부른다”고 적으며, 실행 단위의 시작에서 종료까지를 잇는 이벤트 체인에 지연 제약을 걸어 이를 표현한다.[2] 이 값을 계산으로 미리 구하는 방법은 응답 시간 분석에서, 계산의 입력이 되는 실행 시간의 상한은 최악 실행 시간에서, 상한이 되는 값 자체는 데드라인에서 다룬다.
주기와 지터
PER(period)는 연속한 두 활성화 사이의 시간 간격이고, DT(delta time)는 같은 종류의 연속한 두 사건 사이의 시간 간격, 곧 관측된 주기다.[1] 설정한 값과 실제로 관측되는 값을 굳이 다른 이름으로 두는 이유는 둘이 어긋나기 때문이며, 그 어긋남의 크기가 지터다. 타이밍 요구사항으로는 목표 주기로부터의 최대 편차를 제한하는 형태로 걸린다.[3]
여유
ST(slack time)는 종료 뒤 다음 활성화까지 비어 있는 틈의 길이다 — 인터럽트에서는 종료에서 다음 시작까지다. NST(net slack time)는 그 틈에서 같은 구간 동안 실행된 더 높은 우선순위 태스크와 ISR의 CET 조각을 모두 뺀 값이다.[4] 곧 이 태스크가 CET에 더 얹을 수 있는 headroom이다.[1] 앞의 값이 시간축 위에서 눈에 보이는 빈자리라면 뒤의 값은 그 빈자리 가운데 이 태스크가 실제로 가져다 쓸 수 있는 몫이다. NST가 0이면 그 태스크에는 더 얹을 여지가 없다.
조각으로 나뉘는 쪽도 둘 사이에서 갈린다. ST는 종료에서 다음 활성화까지 끊기지 않는 하나의 구간이지만, 그 구간에 더 높은 우선순위의 실행이 끼어들면 NST는 그 사이사이의 조각들로 나뉘고 그 합만 남는다 — CET가 선점에 잘리는 것과 같은 모양이다.
CPU 부하
CPU 부하는 관측 구간 가운데 유휴 코드가 아닌 것을 처리한 시간의 비율이다. 관측 구간의 길이를 , 그 구간에 들어오는 태스크와 ISR의 CET를 모두 더한 값을 라 하면 다음과 같다.[1]
이 정의에는 함정이 하나 있다. 관측 구간을 어디에 얼마나 잡느냐에 따라 같은 시스템에서 전혀 다른 값이 나오기 때문이다. 구간을 짧게 잡으면 한 태스크가 도는 동안 100%가 되기 쉽고, 길게 잡으면 태스크 활성화가 실패할 만큼 몰린 구간조차 평균에 묻힌다. 구간을 정확히 어디서 끊느냐에 따라서도 값이 달라져서, 같은 길이의 구간을 조금 옮기기만 해도 결과가 바뀐다. 은탄환은 없고 프로젝트의 스케줄과 요구사항에 맞춰 골라야 하며, 주 제어 루프가 있다면 그것이 대개 좋은 출발점이 된다.
태스크 부하 제안
CPU 부하 하나로 시스템을 요약하려는 시도가 관측 구간 문제에 부딪히자, 태스크 단위로 여유를 재자는 제안이 나왔다. NST는 headroom을 잘 나타내지만 단위가 시간이라 부하로 쓰기에 맞지 않으므로, 주기 태스크에 대해 주기 가운데 이미 써 버린 몫의 비율로 환산하자는 것이다.[1]
각 태스크의 태스크 부하는 관측된 최댓값으로 잡고, 주기 태스크 q개로 이뤄진 시스템의 태스크 부하는 그 값들의 최댓값으로 정의한다. 다만 이것은 규격화된 지표가 아니라 논의를 위해 내놓은 제안이며, 주기적이지 않은 태스크와 ISR을 어떻게 다룰지는 열린 채로 남아 있다.