Системы реального времени
RT System Design: автомобиль, авионика, медицина, индустрия
В 1986 году ракета Ariane 5 взорвалась через 37 секунд полёта - ущерб полмиллиарда долларов. Причина: переполнение 16-битного integer в коде, переиспользованном от Ariane 4 без анализа diff в требованиях. Через 8 лет аппарат Therac-25 убил трёх человек race condition в коде переключения мод. Эти случаи стали учебниками для четырёх отраслей - автомобильной, авиационной, медицинской, индустриальной - каждая выработала свой набор стандартов и архитектурных паттернов. На поверхности они кажутся отдельными мирами, но за стандартами скрываются три общих идеи: temporal isolation, spatial isolation и defence in depth.
- **Tesla**: Autopilot DAS3.0 использует mixed-criticality архитектуру на двух Tesla FSD chips с lockstep mode и watchdog между ними - cертифицируется по ISO 26262 ASIL D
- **Airbus A350**: FCMC (Flight Control Module Computer) использует ARINC 653 partitioning на VxWorks 653; DAL A части прошли formal verification
- **Medtronic infusion pumps**: IEC 62304 Class C архитектура с независимым safety MCU и hardware watchdog - сократила recall events на 60% против single-MCU предшественника
- **Siemens SIMATIC S7-1500**: PLC с 1ms scan cycle и сертификацией IEC 61508 SIL 3, используется в управлении турбинами и атомными электростанциями
Automotive: AUTOSAR, CAN и ISO 26262
Современный автомобиль содержит до 150 ECU (Electronic Control Unit), связанных шинами CAN, FlexRay, Ethernet. Стандарт **AUTOSAR Classic** определяет архитектуру: жёсткий runtime со статическим расписанием задач, фиксированная аллокация памяти, поверх RTOS уровня OSEK/VDX. Реакция тормозной системы на нажатие педали - 10 мс от датчика до актуатора, и это бюджет, а не среднее. Стандарт безопасности **ISO 26262** определяет четыре уровня ASIL (A-D): чем выше уровень риска, тем строже требования к разработке, тестированию и архитектуре. ASIL D - функции, отказ которых ведёт к жертвам (электроусилитель руля, тормоза); требует formal verification и резервирования.
AUTOSAR Adaptive (с 2017) пытается ответить на autonomous driving: POSIX-совместимая среда, динамическая аллокация, контейнеризация. Но требования по latency и сертификации остаются - запустить Linux PREEMPT_RT и назвать это 'adaptive AUTOSAR' нельзя. Реально применяется в advanced ADAS-функциях и infotainment; ASIL D-функции всё ещё на Classic из-за определимости поведения.
Почему AUTOSAR Classic применяется для ASIL D функций даже при наличии 'современного' AUTOSAR Adaptive?
Avionics: ARINC 653, DO-178C, partitioning
В авиации главный архитектурный принцип - **partitioning**: разные программы делят процессор, но физически изолированы и по времени, и по памяти. Стандарт **ARINC 653** определяет API для real-time OS на бортовых компьютерах: фиксированное Major Time Frame (например 50 мс), разбитое на partition windows. Каждая partition получает гарантированный слот - flight control 20 мс, navigation 10 мс, display 5 мс. Внутри partition - обычное расписание задач, но snапаружи partition не может превысить свой слот: монотонный таймер аппаратно прерывает её. Это даёт **temporal isolation** между функциями разного уровня критичности.
Сертификация по **DO-178C** для DAL A (катастрофический исход при отказе) требует: structural code coverage MC/DC 100%, formal requirements, independent verification team, traceability снизу вверх. Стоимость разработки DAL A кода - $200-500 за строчку, против $10-50 за обычный embedded C. Это объясняет, почему борт A350 содержит ~25 миллионов строк кода и стоит миллиарды в разработке.
Чем temporal isolation в ARINC 653 отличается от обычного preemptive scheduling?
Medical devices: IEC 62304 и риск-классификация
Медицинские устройства классифицируются по риску: **Class A** - отказ не наносит вреда; **Class B** - может привести к non-serious injury; **Class C** - может привести к смерти или serious injury. Стандарт **IEC 62304** определяет процессы разработки ПО для каждого класса. Class C - инфузионные помпы, кардиостимуляторы, аппараты ИВЛ, рентгеновские облучатели. Главный паттерн архитектуры: разделение safety-critical логики от non-safety функций через segregation - либо на отдельный микроконтроллер, либо через partitioning RTOS аналогично авионике.
Классический пример из истории, который привёл к ужесточению стандартов - **Therac-25** (1985-87): рентгенотерапевтический аппарат, в котором race condition в коде управления переключения мод привела к шестикратной передозировке облучения у пациентов. Три случая смерти. Корень бага: переменная states обновлялась без проверки текущего режима, и оператор мог переключить режим за окно времени, когда аппарат уже подал высокую дозу. Это пример, как software-only safety без аппаратных interlocks ведёт к катастрофе.
В архитектуре инфузионной помпы Class C safety check вынесен на отдельный MCU. Зачем?
Industrial: PLC, IEC 61131-3 и определимые циклы
Промышленная автоматизация (фабрики, нефтехимия, энергетика) построена на **PLC** (Programmable Logic Controller) - специализированном железе с одним фиксированным циклом: scan input -> execute logic -> write output. Длительность цикла - обычно 1-50 мс, гарантирована аппаратно. Программируется на языках **IEC 61131-3**: Ladder Diagram (LD), Function Block Diagram (FBD), Structured Text (ST). Реактивность здесь не означает прерываний - всё опрашивается каждый цикл. Безопасность критичных процессов (SIS - Safety Instrumented System) описывается стандартом **IEC 61508** с уровнями SIL 1-4, аналогичными ASIL автомобильной отрасли.
Парадигма PLC принципиально отличается от event-driven RTOS: вместо реакции на прерывания - синхронный poll каждый scan cycle. Это упрощает анализ: нет race conditions, нет priorities, выполнение детерминировано как у комбинаторной логики. Цена - latency не может быть короче полного цикла. Для медленных процессов (химический реактор с константой времени минуты) это идеально; для motion control нужны субмиллисекундные циклы, и PLC заменяются на EtherCAT-сервопривода со специализированными ASIC.
Почему в PLC-парадигме отсутствуют race conditions, типичные для RTOS-приложений?
Сравнение и общие паттерны
Четыре отрасли построили внешне различные real-time экосистемы, но за стандартами скрываются три общих паттерна. **Temporal isolation**: гарантированный временной слот для каждой функции независимо от других - ARINC partitions, AUTOSAR static schedule, PLC scan cycle. **Spatial isolation**: память одной функции защищена от другой - MPU, отдельные MCU, ARINC memory partitions. **Independence of failure**: критическая функция работает даже когда отказала рутинная - safety MCU, lockstep CPU, hardware interlocks. Различаются они по тому, какой ценой и какими стандартами эти паттерны выражаются.
Один общий метрический показатель - **failure rate target** для разных уровней критичности. ASIL D (auto): 10^-8 failure/hour. DAL A (avionics): 10^-9 failure/hour. SIL 4 (industrial): 10^-9 to 10^-8. Class C medical: типично 10^-7 to 10^-8. Эти числа определяют допустимое количество остаточных багов после сертификации и требуют либо doubled architecture (dual redundancy), либо tripled (TMR - Triple Modular Redundancy с голосованием) для достижения нужного MTBF.
Real-time system - это просто 'быстрый компьютер'
Real-time означает гарантированную верхнюю границу latency, доказанную заранее. Скорость средняя или peak не имеет значения - принципиальна предсказуемость худшего случая.
PLC с 10 мс scan cycle - real-time для химического процесса с константой минуты. Самый быстрый суперкомпьютер с непредсказуемыми GC паузами - не real-time для контроля квадрокоптера. Цель real-time проектирования - не максимальная производительность, а доказуемая ограниченность времени отклика.
Если объединить ASIL D + DAL A + SIL 4 в один сертифицируемый компонент - какая практическая сложность возникнет?
Ключевые идеи
- **Automotive**: AUTOSAR Classic + ISO 26262 ASIL D, статическое расписание задач на OSEK, lockstep CPU для критических функций; миллионы единиц в год диктуют упор на стоимость
- **Avionics**: ARINC 653 partitioning + DO-178C DAL A, formal verification, temporal isolation между partition windows, cтоимость $200-500 за строку DAL A
- **Medical**: IEC 62304 Class C, defence in depth - отдельный safety MCU + hardware interlocks + watchdog, история Therac-25 как урок против software-only safety
- **Industrial**: PLC + IEC 61131-3 + SIL 1-4, цикл scan-execute-write детерминирован и однопоточен - нет race conditions конструктивно
- **Общие паттерны**: temporal isolation, spatial isolation, independence of failure; различия в стандартах формальны, идеи universal
Связанные темы
Real-time system design на стыке нескольких направлений за пределами одной отрасли:
- Анализ schedulability — Rate Monotonic и EDF дают формальные методы оценки worst-case timing, применяемые во всех четырёх отраслях
- Hardware design — Lockstep CPU, watchdog timers, MPU - всё это аппаратные механизмы, без которых ни одна сертификация для критичных функций невозможна
- Formal methods — Frama-C, SPARK, TLA+ применяются в авионике и в части автомобильной отрасли для функций ASIL D / DAL A
Вопросы для размышления
- Если стандарты ISO 26262, DO-178C, IEC 62304, IEC 61508 имеют общие паттерны - почему до сих пор не появилось единого международного стандарта real-time safety, применимого ко всем отраслям?
- PLC scan cycle устраняет race conditions, но ограничивает latency самим циклом. В каких сценариях event-driven RTOS архитектура объективно эффективнее, а в каких уступает PLC?
- Cтоимость DAL A кода - $200-500 за строку. Если автономному автомобилю требуется ~25 миллионов строк аналогичного качества, что это означает для экономики массовой автономии?
Связанные уроки
- rts-12 — Fault tolerance - основа системного дизайна RT
- rts-14 — System design открывает дорогу к RT протоколам
- net-15-tcp-basics — TCP/UDP и детерминированность в RT-сетях
- ds-01-intro — Распределённые системы и RT имеют общие проблемы надёжности
- db-03-acid — ACID-гарантии и RT-детерминизм: аналогичные требования надёжности
- emb-01