Что такое системы реального времени

4 июня 1996-го. Ariane 5 взлетает. Через 37 секунд - взрыв. Причина: integer overflow в системе инерциальной навигации, скопированной с Ariane 4. Система не справилась с новым профилем полёта - и вместо graceful degradation выдала необработанное исключение. Стоимость: 370 миллионов. Boeing 737 MAX MCAS - система реального времени с ошибкой в логике приоритетов: датчик врал, а система верила ему, игнорируя пилота. 346 погибших. Разница между «быстро» и «реального времени» - не скорость, а гарантированная верхняя граница. ABS тормозит за 5-7 мс не потому что быстро, а потому что всегда укладывается в 5-7 мс. Пропустил дедлайн - машина не остановилась.

• **Ariane 5, 1996:** 370 млн сгорело за 37 секунд из-за пропущенного deadline в inertial reference system. Тот же код работал на Ariane 4 - но у Ariane 5 другой профиль ускорения, и число вышло за int16 boundary
• **ABS в каждой машине:** 5-7 мс от обнаружения блокировки до сброса давления - hard deadline. Программный стек: C + bare-metal RTOS. Никаких Java, никакого GC, никакого malloc в цикле управления
• **HFT (High-Frequency Trading):** ордер, пришедший через 101 мкс вместо 100, отправляется в /dev/null - цена уже другая. Firm RT. Именно поэтому биржевые серверы живут в одном здании с биржей (colocation) и соединены прямым оптоволокном

Hard Real-Time: дедлайн = закон

120 км/ч, мокрый асфальт. Колесо заблокировалось. ABS должна сбросить давление в тормозном цилиндре за **5-7 миллисекунд** - иначе машина потеряет управляемость. Не «лучше уложиться», не «желательно», а **обязательно**. Это и есть **hard real-time**: пропущенный дедлайн - это отказ системы, независимо от правильности вычисления.

В **hard real-time** системах корректность определяется не только правильностью результата, но и **временем** его получения. Правильный ответ, полученный после дедлайна, считается ошибкой - такой же, как неправильный ответ.

Именно поэтому ABS-контроллер написан на C, а не на Java. GC-пауза в 50 мс в неудачный момент - и дедлайн пропущен. Кардиостимуляторы работают на C и Ada. Boeing 737 MAX использовал C, но с ошибкой в логике приоритетов: датчик угла атаки врал, MCAS ему верил, а пилоту - нет. Hard RT не прощает ошибок в логике так же, как не прощает опозданий.

Soft Real-Time: качество деградирует

YouTube, 60 FPS. Один кадр опоздал на 5 мс - небольшой рывок на экране. Два подряд - заметное подёргивание. Но видео продолжается, сервер не упал, никто не пострадал. Это **soft real-time**: пропущенный дедлайн деградирует качество, не ломает систему. Utility function - ценность результата - снижается после дедлайна, но не обрушивается в ноль.

В **soft real-time** существует **функция ценности** (utility function): чем позже ответ, тем менее он полезен, но всё ещё имеет некоторую ценность. В hard RT ценность падает до нуля (или отрицательной!) мгновенно в момент дедлайна.

Firm Real-Time: просроченное - в мусор

Биржа. Алгоритм принял решение о сделке за 95 мкс - отлично. Но исполнение пришло через 200 мкс вместо 100 - цена сдвинулась, арбитражная возможность закрылась. Результат не опасен, не деградирован - просто **бесполезен**. Ордер отправляется в /dev/null. Это **firm real-time**: ценность просроченного результата строго ноль.

**Firm RT** часто путают с hard RT, но разница критична: в hard RT просроченный результат **опасен** (подушка безопасности после удара), в firm RT - просто **бесполезен** (торговый ордер на уже изменившуюся цену). Firm RT допускает пропуск некоторого процента дедлайнов.

Роботизированный конвейер Toyota: деталь проезжает точку сборки за 500 мс. Опоздал - деталь ушла, конвейер не остановился, следующая придёт через секунду. Каждый пропуск - дефект продукции или потеря производительности. Не авария. Именно firm RT.

Детерминизм: предсказуемость важнее скорости

Ariane 5 взорвался через 37 секунд. Inertial reference system работала прекрасно - 99.9% времени. Но в этот конкретный момент вылетел integer overflow, и вместо graceful degradation система выбросила необработанное исключение. 0.1% worst-case уничтожил 99.9% uptime. **В real-time нет статистики - есть только worst-case.** Алгоритм на 1 мс в среднем, но иногда 100 мс, хуже алгоритма, который всегда 10 мс.

**RTOS** (Real-Time Operating System): VxWorks, FreeRTOS, QNX - ОС, спроектированные для детерминизма. Они гарантируют максимальное время реакции на прерывание (interrupt latency < 10 мкс). Linux по умолчанию - не RT, но **PREEMPT_RT** патч превращает его в soft RT-систему.

Сервер на Core i9 с GC-языком vs STM32 за 2 доллара с bare-metal C. Средняя задержка сервера - 0.3 мс. Worst-case - 80 мс (GC-пауза). STM32 средняя - 8 мс. Worst-case - 9 мс. Для дедлайна 15 мс выбирают STM32. Не потому что дешевле - потому что предсказуемо. Именно этот принцип объясняет, почему в кардиостимуляторах не стоит Snapdragon.

Ключевые идеи

• **Real-time = предсказуемо в срок, не быстро:** STM32 за 2 доллара выигрывает у сервера на 5 ГГц, если дедлайн 10 мс и у сервера GC-паузы до 50 мс
• **Hard RT - нулевая терпимость:** ABS, кардиостимулятор, управление ядерным реактором. Правильный ответ после дедлайна = неправильный ответ. Языки: C, Rust, Ada. Никакого GC
• **Soft RT - graceful degradation:** видеозвонок, игры, стриминг. Пропущенный кадр = дёрганье, не катастрофа. Utility function снижается плавно
• **Firm RT - просроченное бесполезно:** HFT, роботизированный конвейер. Результат после дедлайна не опасен и не деградирует - просто выбрасывается

Связанные темы

RT-системы объединяют знания из нескольких областей:

• Планирование: Rate Monotonic — Алгоритмы планирования задач с дедлайнами
• Worst-Case Execution Time — Анализ worst-case времени выполнения для гарантий дедлайнов
• Операционные системы — RTOS vs general-purpose OS - разные приоритеты проектирования

Вопросы для размышления

• Почему автомобильные контроллеры используют микроконтроллеры за $2, а не мощные процессоры за $200?
• Можно ли превратить обычный Linux в hard RT-систему? Что для этого нужно изменить?
• Вернёмся к началу: как ABS в вашей машине гарантирует реакцию за 5 мс, учитывая все возможные сценарии?

Связанные уроки

• emb-01 — Реал-тайм системы обычно работают на embedded железе: прерывания, RTOS, ограниченные ресурсы
• os-01-intro — RTOS - специализация ОС: детерминированный планировщик вместо fair-share, жёсткие deadline вместо throughput
• ds-01-intro — Distributed systems тоже требуют determinism и fault tolerance, но в масштабе сети, а не одного устройства
• arch-01-binary — Понимание pipeline, кеша и прерываний процессора критично для worst-case execution time анализа