#include <stdio.h>
int main ()
{
printf("Hello world!"\n)
return 0;
}
이런 코드를 실행시켰습니다.
이 코드가 1.0초 내에 실행되길 기대했는데,
무슨 이유에선지 2.0초가 걸렸습니다.
그닥 큰 일이 생기지 않죠?
근데, 이런 코드가 있다고 칩시다.
if (crash_detected) {
activate_airbag();
}
근데 이 코드가 실행되는데 시간이 좀 걸렸다고 해봅시다.
매우 큰 일이 날 것만 같죠?
이처럼,
시스템 중에는 Time Constraint (Deadline)를 가지고 실행되는 시스템들이 있습니다.
반드시 Time Constraint를 맞춰야 하는 시스템들이죠.
Real-Time system은 다음과 같이 정의됩니다.
A computing system that must react within precise time-constraints to events in the environment.
또는,
Systems whose correctness depend on their temporal aspects as well as their functional aspects.
time-constraint (deadline)이 존재하고,
그 안에 결과물을 도출해야 하는 시스템인 것입니다.
Safety-critical systems (안전에 직결된 시스템. 에어백 등)이나,
Mission-critical systems (실패 시 돈이 좀 크게 깨지는 시스템. 미사일 발사 등)에서 쓰이죠.
이 '데드라인'을 지킬 수 있냐 없냐가 엄청 중요해서,
Real-time system은 performance measure로 Timeliness on timing constraints를 고려합니다.
Timing Constraint (Deadline) 내에 실행이 가능하냐를 보는거죠.
Average case performance나, Speed는 우선순위가 밀립니다.

전자같은 경우는 평균치가 훌륭하지만,
Deadline이 생길 경우 조금 더 Deadline 전에 timely하게 작동할 가능성이 낮죠.
하지만, 후자같은 경우는 평균 response time은 높지만,
Worst case가 전자보다 좋기에,
Deadline 이전에 Timeliness를 보장받을 확률이 늘어납니다.
Real-time이 fast와 같은 의미일까요?
아닙니다!
2번째 말하지만, real-time은 average case가 그닥 중요하지 않습니다.
fast보단, predictable에 가까운 의미이죠.

수심이 낮지만, 아마 이 남자는 죽겠죠?
real-time 관점에선 아주 별로인 상황입니다.
Real-time system도 3개로 분류할 수 있는데요,
Soft, Hard, Firm으로 분류 가능합니다.
방금까지 한 Real time system입니다.
Deadline miss 발생 시 Disastrous한 일이 발생합니다.
에어백, 미사일 발사체계, 공장 생산체계, 원격의료 등이 해당하겠죠?
전부 delay가 발생하면 어떤 일이 생길지 끔찍한 상상이 듭니다.
그렇기 때문에, Deterministic한 보장이 필요합니다.
공식 등을 이용해서, deadline에 대한 수학적 보장이 필요하죠.
"이 시스템은 음.. 대부분 80ms 안에 실행될걸요?" 같은건 큰일을 발생시킬 수도 있으니까요.
또한, 최악의 경우에도 작동한다는 Validation이 필수입니다.
A대리, 미사일 발사체계는 몇ms 안에 실행되지?
아 예 부장님. 네트워크 지연까지 고려해서 대부분의 경우 12ms입니다.
네트워크 지연이 발생하면?
작동 안 합니다!
큰일이 나겠죠?

deadline을 지나면 Utility가 아예 음수로 떨어지는 모습입니다.
손해라는 뜻이죠.
Deadline을 못 지켜도 상관은 없지만, 조금의 성능 저하가 발생합니다.
대부분의 시스템이 여기에 속합니다.
Deadline을 지켜야 최대의 Performance를 낼 수 있습니다.
Deadline miss가 발생 시 조금의 성능 저하가 발생하죠.
Best-effort approach와 Statistical Guarantee가 필요합니다.
Best Effort approach - 최선을 다했으나, 딱히 deadline을 맞춘다는 보장을 하지는 못합니다.
Statistical Guarantee - 한 95%의 확률로 deadline을 맞추는게 보장된다,
이런 통계적 보장을 뜻합니다.

큰일은 나지 않지만, utility가 줄어들어 손해를 봅니다.
Hard, soft 사이의 어딘가입니다.
Deadline을 지키지 못하면 무언가 큰일이 터지는 건 아니지만,
Benefit이 사라집니다.

deadline을 지키지 못하면 Benefit이 사라지는 모습입니다.
손해가 날 수도 있구요.
CPU, Memory, I/O Device 등 여러 시스템들이
특정 기능을 위해 특정 장치 안에 Embed (심어져 있다) 된 형태입니다.
전기자동차, MRI, 아이언맨 수트같은 경우도 임베디드 시스템이고,
심지어는 전자시계 안에도 CPU와 메모리가 있다면 임베디드 시스템이라 할 수 있습니다.
전동 칫솔도 소량의 코드를 가진 Embedded 시스템이구요,
토스트기, 전자레인지 등도 Embedded 시스템입니다.
CPU 없이 전선과 gate만으로 작동하진 않을테니까요.
그럼 이 임베디드 시스템이 마주한 challenge는 뭐가 있을까요?
어떻게 해야 임베디드 시스템을 좀 더 쓸만하게 할 수 있을까요?
우선, 경량화가 중요합니다.
사이즈를 줄이고, 무게를 줄여야 합니다.
아무래도 손에 들고 다니고, 휴대하고 다니고,
책상 위에 가만히 냅두는 Desktop이 아니기 때문에, 가벼워야 하죠
Low power도 중요합니다.
전자시계를 생각하면 편한데,
전자시계가 일주일만에 픽 죽어버리면 너무 슬프죠.
전력을 한번 넣어놓으면 오랫동안 작동하는게 중요합니다.
Harsh Environment도 고려 요소입니다.
책상 위에 고이 모셔놓는 컴퓨터와는 다르죠.
전자시계는 여기 구르고 저기 구르고,
작동 환경이 빡세다 보니 고려할 요소가 많습니다.
진동이나 온도를 고려하지 않고 만들면, 어지간하면 시스템이 작동하지 않겠죠.
Safety-Critical Operation도 고려해야 합니다.
컴퓨터가 안 켜지면 "안 켜지는구나" 하겠죠.
근데 지하철 System이 안 켜지면 어떻게 될까요?
자율주행 자동차의 자율주행 시스템이 먹통이 되면 어떻게 될까요?
큰일나겠죠?
EXTREME Cost Sensitivity
임베디드 시스템은 보통 시제품인데,
전자시계 공장에서 전자시계에 작은 회로를 추가했더니,
시계당 $.05만큼의 cost가 추가되었다고 칩시다.
그럼 1,000,000개를 생산하면 cost가 자그마치 50,000$나 추가됩니다.
1억개를 생산하면 50억원정도의 추가 cost가 발생하구요.
엄청 예민하죠.

일반적인 시스템에선 성능 향상을 위해서
속도가 빨라져야 한다,
메모리를 키워야 한다 정도를 고려할텐데,

임베디드 시스템에서는
속도도 빨라야하고 메모리도 커야 하고 그와 동시에 Size / Weight는 너무 커져서는 안되고 Cost는 줄일수록 좋고 생산성이 괜찮아서 Time-to-market이 일정부분 보장되어야 하고 Reliable하며 Harsh environment에 대한 대응성도 있어야 하고
이런 것들을 다 고려해야 하는 악질적 상황이 생긴거죠.
게다가 보통은 임베디드 시스템은 Real-time과 연관이 깊습니다!
그래서 Real-time embedded system을 많이들 생산하죠.
이럼에도 불구하고 Embedded System 시장은 점점 커지고 있습니다.
Physical Entity를 관장하는 Computational element의 집합을 CPS라 칭합니다.

뭐 전자농업, 헬스케어, 항공우주 정도가 해당됩니다.
사물인터넷입니다.
사물들끼리 정보를 공유하고, 데이터를 나누는 것을 사물인터넷이라 부릅니다.
CPS와 얼추 비슷한 면이 있죠.

사이의 연관은 다음과 같게 표시됩니다.
Real-Time이면서 Embedded이면서 IoT이면서 CPS의 일부인 시스템도
어딘가엔 있겠죠?
일반적으로 Cache는 computing unit 사이 이동하는 시간을 줄이기 위해 사용됩니다.
CPU가 RAM에서 데이터를 찾기 전에 Cache를 미리 뒤져보는거죠.
그래서 보통의 시스템에서는 Caching이 Average Response speed를 높이는데 도움이 됩니다.
근데, 과연 Real-time system에서도 캐시를 고려해야 할까요?

Cache가 없었다면,
CPU -> Memory까지 접근해야 하기에 t_CPUMEM만큼의 접근시간을 갖겠죠.
Cache가 있다면,
cache hit 시 CPU -> L1 Cache로 흐름이 가기에,
t_CPUL1만큼의 시간을 갖습니다. (t_CPUL1 << t_CPUMEM)
근데, Cache miss가 일어난다면요?
t_CPUL1 + t_CPUL2 + t_CPUMEM만큼의 시간을 소비하게 되겠죠.
즉, Cache Miss 상황에선 Cache가 오히려 안 좋은 결과를 낳게 되는 겁니다.
그리고 Worst-case에서의 guarantee가 필요한 Real time system의 경우,
Cache가 오히려 없어야겠죠?