RT на собеседовании

2017 год. SpaceX Falcon 9 садится на баржу в Атлантике; за 8 минут спуска бортовой компьютер обрабатывает 100 000 sensor readings в секунду, держа жёсткий 1 мс control loop. Кандидат на staff embedded engineer в SpaceX получает на собеседовании вопрос: *"Как вы спроектируете эту систему?"* Правильный ответ не начинается с 'я бы взял VxWorks' - он начинается с уточнения latency budget, criticality classification и failure modes. RT-собеседование - это не quiz по терминологии, а проверка способности структурно мыслить под жёсткими timing-constraints, и именно за это staff engineers в Tesla, SpaceX, NVIDIA Drive получают USD 400K base + equity.

• **Tesla Autopilot**: staff embedded interview - 4 секции по 45 минут, одна из них posed как 'design adaptive suspension', оценивается как L5+ design
• **SpaceX Avionics**: ARINC 653-style partitioning на custom RTOS, кандидаты обязаны знать DO-178C DAL B/C на интервью
• **NVIDIA Drive**: mixed-criticality systems на DRIVE Thor (2000 TOPS), интервью покрывает hypervisor partitioning и cache QoS
• **Cruise/Waymo**: ROS 2 + DDS + custom scheduler, kandidat получает live-coding вопросы по schedulability и priority inversion

Вопросы про планирование: Rate Monotonic и EDF

Типичный первый вопрос на собеседовании в Tesla/SpaceX/Rivian: *"Дано три задачи с периодами 10, 20, 40 мс и WCET 3, 5, 8 мс. Расписать по Rate Monotonic. Будет ли система schedulable?"* Это не вопрос про знание определений - проверяется способность за две минуты применить формулу Liu-Layland $U \leq n(2^{1/n} - 1)$, для $n=3$ это $\approx 0.78$. Считаем utilization: $3/10 + 5/20 + 8/40 = 0.3 + 0.25 + 0.2 = 0.75 < 0.78$ - schedulable по достаточному условию. Если ответ закончился здесь - кандидат не разглядел подводный камень: условие Liu-Layland *достаточное, но не необходимое*. Между ним и 100% utilization (необходимое условие) лежит зона, где требуется response-time analysis - и именно эту зону любят интервьюеры. Тот же шаблон, что в ML interviews со SGD convergence: достаточные условия - простые, необходимые - тонкие.

Второй классический вопрос: *"Когда EDF предпочтительнее Rate Monotonic?"* Правильный ответ имеет три уровня. **Поверхностный**: EDF даёт 100% bound по utilization против 69-78% у RM. **Средний**: EDF справляется с задачами без жёсткой периодичности (aperiodic, sporadic). **Глубокий**: EDF хуже ведёт себя при перегрузке - один пропущенный deadline вызывает каскад, потому что динамические приоритеты не сохраняют свойство 'критичные первыми'. RM при перегрузке деградирует предсказуемо: низкоприоритетные задачи пропускаются, высокоприоритетные выживают. Поэтому в авионике (DAL A, перегрузка - катастрофа) выбирают RM; в multimedia processing (soft RT, перегрузка - дёрганый звук, не смерть) - EDF.

На уровне L6+/staff engineer спрашивают про **priority inheritance** и **priority ceiling protocol** - механизмы против priority inversion. Канонический cas Mars Pathfinder 1997 знают все, но различия между **inheritance** (приоритет наследуется на время блокировки) и **ceiling protocol** (захват ресурса повышает приоритет до максимума его пользователей) - не все. Inheritance проще, но не предотвращает deadlock; ceiling protocol дороже, но гарантирует bound на блокировку. В реальном коде FreeRTOS использует priority inheritance, VxWorks - оба варианта на выбор. Знание этого различия отделяет 'читал главу в книге' от 'писал driver под VxWorks'.

WCET анализ: как защитить worst-case, не получив 10x запас

Любимый вопрос на собеседовании в Airbus или GM: *"Как вы измерите WCET для функции обработки сигнала с камеры?"* Плохой ответ: *"Запущу 10000 раз и возьму максимум."* Это measurement-based WCET - и оно недостоверно по двум причинам. Во-первых, измерения не покрывают все pathways через код (branch coverage не равно path coverage). Во-вторых, кэш-промахи, branch misprediction и interrupt timing зависят от состояния системы, которого в измерениях не было. Реальный ответ - три уровня. **Static analysis** (aiT, OTAWA) даёт upper bound через анализ control-flow graph и cache модели процессора - результат гарантированный, но pessimistic, типично в 2-3 раза больше реального максимума. **Hybrid** комбинирует static анализ структуры с measurement timings отдельных базовых блоков. **Measurement-based** допустим только для soft RT и как sanity check для static.

Подвох вопроса: интервьюер ждёт упоминания **execution time variability** на современных out-of-order процессорах с кэшем. На ARM Cortex-A72 та же функция может выполняться от 12 до 47 микросекунд в зависимости от того, что в L1 cache - речь о 4x вариации. Это убивает classical WCET analysis, разработанный под детерминированный Cortex-M (нет out-of-order, нет L2). Решение: либо использовать **cache partitioning** (резервировать L2 way для критической задачи), либо переходить к **Probabilistic WCET** (доверительный интервал, например 99.99%-tile из 10^5 запусков с randomized cache). Тот же подход в ML, когда p99 latency важнее среднего: SLO задаётся как distribution, а не как точка.

Классический trap-вопрос: *"Что если WCET включает время на garbage collection?"* На JVM или V8 этот вопрос звучит абсурдно для hard RT, и это правильный инстинкт. Но **Real-Time Java** (RTSJ, JSR-1) существует с 2002 года и используется в военных системах, где legacy Java-код нельзя переписать. Решение: **Realtime GC** (Metronome, IBM J9) даёт bounded pause times через incremental collection. Стоимость - 30-50% throughput overhead. Аналогично в Go: GC stop-the-world сократился с 300 мс в Go 1.4 до <1 мс в Go 1.8 благодаря concurrent collection - и теперь Go применим для multimedia soft RT, чего нельзя было сказать 10 лет назад.

System design RT: 'спроектируйте автопилот'

На staff/principal интервью даётся открытая задача: *"Спроектируйте систему управления подвеской электромобиля с активной адаптацией к дорожному покрытию."* Это RT system design, и подход к нему такой же структурный, как у Grokking System Design Interview, только с timing constraints вместо QPS. Пять шагов. **Шаг 1: latency budget**. Спросить интервьюера про требования - типично 10 мс sensor-to-actuator для подвески, 100 мс для steering, 1 мс для airbag deployment. **Шаг 2: criticality classification**. ASIL D для airbag, ASIL B для adaptive suspension, QM для infotainment. **Шаг 3: hardware architecture**. Дискутировать между centralized ECU (Tesla подход) и distributed ECUs (классический automotive). **Шаг 4: software architecture**. AUTOSAR Classic для ASIL D, AUTOSAR Adaptive или Linux PREEMPT_RT для infotainment. **Шаг 5: failure modes**. Что происходит при отказе одного сенсора, одного ECU, потери CAN-bus.

Главное отличие от обычного backend system design: в RT **отказ - это часть нормальной работы**, а не исключение. CAN-bus может потерять frame; lidar может вернуть данные с задержкой 20 мс вместо 10; main MCU может уйти в watchdog reset. Архитектура обязана это переживать без остановки сервиса. Поэтому появляются паттерны вроде **graceful degradation** (если адаптивная подвеска отказала, активируется fallback на пассивные настройки), **lockstep CPU** (два процессора выполняют ту же программу, голосование при расхождении), **TMR - Triple Modular Redundancy** (три копии с majority voting, используется в авионике DAL A). На собеседовании ожидается, что кандидат сам предложит эти паттерны до того, как интервьюер задаст вопрос *"А что если...?"*.

На уровне principal/distinguished engineer задача переходит в **mixed-criticality systems**: один SoC исполняет ASIL D, ASIL B и QM-задачи одновременно. Это сейчас актуально для Tesla FSD и NVIDIA Drive: 8 GPU + 4 ARM core executing safety-critical autopilot и non-safety infotainment на одной плате. Решение - **hypervisor partitioning** (PikeOS, QNX Hypervisor) + **time partitioning** для CPU + **cache partitioning** для shared L3. Знание этих паттернов отличает кандидата на staff engineer в Tesla Autopilot или Cruise от обычного embedded developer.

Tradeoffs: что выбирать и когда уходить от RT

Самый недооценённый тип вопроса на staff interview: *"Когда не нужно строить hard real-time систему?"* Кандидаты часто хотят показать знания, и предлагают RT-решение для всего. Но честная инженерная позиция: hard RT - дорогое удовольствие, и применять его без необходимости - технический долг. Цена hard RT: специальные RTOS, MISRA C, formal methods, сертификация, ограниченный пул инженеров, плохая совместимость с современными ML-фреймворками. Если задача допускает p99 latency вместо worst-case, выбор обычного Linux с PREEMPT_RT и моделирования распределений латентности - валидный ответ, который интервьюер уважает больше, чем reflex 'давайте VxWorks'. То же напряжение в ML: deterministic inference vs throughput-optimized batching - две разных стратегии для разных SLO.

Канонический tradeoff: **VxWorks vs Linux PREEMPT_RT**. VxWorks - сертифицированный RTOS под DO-178C/ISO 26262, deterministic worst-case, лицензия USD 50K+ на проект и USD 50K runtime royalty per million units. Linux PREEMPT_RT - бесплатный, гибкий, поддерживает Docker и ML-стек, но best-effort latency бывает 200-500 мкс worst-case при высокой нагрузке. Tesla выбрала PREEMPT_RT для FSD (нужна гибкость ML pipeline), Airbus оставила VxWorks 653 для A350 FCC (без альтернативы для DAL A). Знание этого исторического контекста - сигнал инженерной зрелости.

Финальный сигнал зрелости на интервью - умение **признавать неопределённость**. Вопрос: *"Какой RTOS лучше для нашего проекта - VxWorks или QNX?"* Слабый ответ - выбрать один с обоснованием 'я работал с этим'. Сильный ответ - перечислить факторы (regulatory, hardware support, существующая команда, лицензионная стоимость, ecosystem драйверов) и сказать *"Без знания этих деталей я не могу дать честный ответ; вот вопросы, которые я бы задал customer."* Интервьюер в Tesla или SpaceX ищет именно эту способность - не уверенность ради уверенности, а структурное мышление под неопределённостью. То же поведение ценится в Anthropic при design review LLM safety - не *'я знаю правильный ответ'*, а *'вот мои гипотезы и эксперименты, которые их проверят'*.

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

RT-собеседования пересекаются с несколькими дисциплинами:

• Schedulability analysis — Liu-Layland, response-time analysis, EDF bounds - математический ядро RT-секции
• Formal methods и model checking — UPPAAL, TLA+ - инструменты для staff+ уровня в DAL A/ASIL D компаниях
• Industry standards — ISO 26262, DO-178C, IEC 62304 - знание стандартов критично для automotive/avionics/medical interviews
• Realtime backend — Latency budgets в realtime web (WebSocket, SSE) имеют ту же логику что в hard RT, на других порядках значений

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

• **Schedulability questions**: Liu-Layland - достаточное условие, response-time analysis - точное; знать tradeoff RM vs EDF и поведение при перегрузке
• **WCET анализ**: static (aiT), measurement-based, hybrid; на out-of-order CPU (Cortex-A72) classical WCET pessimistic, нужны cache partitioning и Probabilistic WCET
• **System design**: 5 шагов - latency budget, criticality, hardware, software stack, failure modes; mixed-criticality требует hypervisor + cache partitioning, не приоритетов
• **Tradeoffs**: VxWorks для DAL A/ASIL D, Linux PREEMPT_RT для soft RT + ML; зрелость кандидата - в признании контекста и неопределённости, не в reflex-выборе

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

• Mars Pathfinder priority inversion - знаменитый кейс. Какие современные системы (Tesla FSD, SpaceX Dragon) теоретически подвержены тому же классу проблем, и какие архитектурные защиты применяются?
• Stafford engineer в Tesla получает в 2 раза больше, чем в обычной embedded компании. За какие конкретные навыки платят эту премию - и какие вопросы на собеседовании их проверяют?
• Если PREEMPT_RT может заменить VxWorks для большинства soft RT задач, почему регулируемые отрасли (авионика, medical) сохраняют VxWorks/QNX десятилетиями?

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

• rts-01 — Без определения hard/soft RT отвечать на schedulability невозможно
• rts-12 — Formal methods - частая глубинная тема в RT-секции на L6+
• rts-13 — Архитектуры automotive/avionics/medical обсуждаются на architecture round
• ml-28-optimizers — Online learning тоже работает на latency budget, как RT
• rt-01-what-is-realtime — Realtime backend разделяет понятийный аппарат латентности
• ds-04-consistent-hashing — Шардирование задач между ядрами - тот же приём, что в распределённых системах
• os-01-intro