Заказные системы реального времени
Качество данных — Data Governance, роль БД.
С чего начать — "реальное время" — это не "быстро"
Система реального времени (Real-Time System, RTS) — такая, где результат считается правильным, только если он получен вовремя. Опоздание на 200 мс в интернет-магазине — неприятность для пользователя. Опоздание в АСУ ТП (автоматизированная система управления технологическим процессом), медоборудовании или системе управления движением может означать аварию.
В курсе "экономика производства ПО" РВ-системы связаны с гл. 1.3 (требования) и гл. 2.5 (динамическое тестирование). Здесь — мост между учебной теорией и практикой заказной разработки.
Обычная ИС: "Посчитали верно?" — главный вопрос.
РВ-система: "Посчитали верно и уложились в дедлайн?" — оба вопроса обязательны.
Мини-глоссарий
| Термин | Простыми словами |
|---|---|
| Дедлайн (deadline) | Крайний срок, к которому должен быть готов ответ |
| Latency (задержка) | Время от "событие пришло" до "реакция системы" |
| Jitter | Разброс задержки: то 5 мс, то 50 мс при "одинаковой" нагрузке |
| WCET | Worst-Case Execution Time — худшее время выполнения критичного кода |
| RTOS | Real-Time OS — ОС с предсказуемым планированием задач |
| HIL / SIL | Тест со "железом в контуре" / только программный симулятор среды |
| Fail-safe | При сбое система переходит в безопасное состояние (реле отключено, клапан закрыт) |
Жёсткое, мягкое и "твёрдое" реальное время
| Тип | Дедлайн | Последствие срыва | Пример |
|---|---|---|---|
| Hard real-time | Обязателен всегда | Катастрофа, травма, авария | Отключение защиты двигателя за 10 мс |
| Soft real-time | Желателен | Падает качество услуги | Видеозвонок: кадр пропустили — раздражение, редко — смерть |
| Firm real-time | Периодический | Единичный срыв терпим, серия срывов — провал | Поток телеметрии: потеря 1 пакета из 1000 OK, потеря 10% — нет |
Как понять, что перед вами hard RT: спросите заказчика — "Что случится, если ответ придёт на 100 мс позже в худшем случае?" Если ответ про людей, оборудование или регулятор — почти наверняка hard.
Когда "обычного веба" достаточно, а когда нужен РВ-подход
| Ситуация | Обычно достаточно | Нужен РВ-подход |
|---|---|---|
| Корпоративный портал, CRM | Да | Редко |
| Интернет-магазин | p95 latency важен, но hard RT нет | Нет |
| SCADA, PLC, робототехника | Нет | Да |
| Медицинский инфузомат, кардиостимулятор | Нет | Да |
| Биржевой HFT | Особые требования к задержке | Да (своя ниша) |
Путаница: "нам нужно быстро" ≠ "нам нужно гарантированно в срок в worst case". В ТЗ для РВ пишут верхние границы и процентили (p99, max), а не только "в среднем 200 мс".
Особенности требований (гл. 1.3)
Помимо функциональных сценариев ("при сигнале X включить Y") в ТЗ фиксируют временные и ресурсные ограничения.
| Категория | Что означает | Пример формулировки для ТЗ |
|---|---|---|
| Latency / jitter | Скорость и стабильность реакции | "Цикл управления ≤ 10 мс; jitter ≤ 1 мс при 8 ядрах загрузки 70%" |
| Throughput | Сколько событий в секунду обрабатываем | "Не менее 1000 телеметрий/с без потерь при номинальной нагрузке" |
| Determinism | Предсказуемость worst case | "WCET модуля расчёта PID документирован и ≤ 2 мс" |
| Fail-safe | Безопасное состояние при отказе | "При потере связи с датчиком — перевод в safe за ≤ 50 мс" |
| Availability | Допустимый простой | "В штатном режиме простой недопустим" (для hard RT) |
Требования должны быть проверяемы на стенде, близком к целевому железу — см. ISO 25010, производительность.
Функциональная пригодность для РВ: система успевает считать правильно, а не только "в принципе считает правильно на dev-ноутбуке".
Архитектурные следствия (что меняется в проектировании)
- RTOS или разделение на critical / non-critical домены (ОС, RTOS).
- Осторожность с сборщиком мусора (Java, C#): паузы GC ломают hard RT; часто критичный код на C/C++ или выделенные профили без GC.
- Приоритеты потоков, минимум блокировок в "горячем" пути (hot path).
- Watchdog (сторожевой таймер): если задача не отчиталась — перезапуск или safe state.
- Резервирование каналов, аппаратные таймеры.
- Сближение OT (операционные технологии на заводе) и IT — как работает компьютер, промышленность.
РВ-проекты дороже — спецжелезо, стенды, длинные прогоны, сертификация. В COCOMO это отражается в RELY, VIRT, STOR, опыте PCAP и режиме embedded-подобных проектов.
Динамическое тестирование (гл. 2.5)
Динамическое тестирование — проверка работающей системы с потоком событий, как в эксплуатации. Статический анализ кода ("на бумаге всё верно") не доказывает соблюдение дедлайнов под нагрузкой.
Компоненты стенда
| Компонент | Роль | Аналогия |
|---|---|---|
| Генератор среды | Имитация датчиков, шины, протоколов | "Искусственный завод" вместо реального цеха |
| HIL (Hardware-in-the-Loop) | Реальное или близкое железо в контуре | Контроллер настоящий, объект — симулятор |
| SIL (Software-in-the-Loop) | Всё в ПО, быстрее и дешевле | Ранние итерации до сборки стенда |
| Захват времени | Метки времени, трассировка | Осциллограф для программы |
| Мониторинг ресурсов | CPU, RAM, прерывания | "Почему в этот момент цикл сорвался" |
Генератор динамических тестов внешней среды в учебнике — это симулятор + сценарии — "датчик шлёт 10 kHz", "один пакет потерян", "помеха на шине 200 мс".
Что проверяют на стенде
- Соблюдение дедлайнов — max и p99 latency, сравнение с WCET-бюджетом.
- Перегрузка — очереди растут, отброс пакетов, backpressure — система не уходит в unsafe.
- Recovery — перезапуск подсистемы без опасного состояния.
- Soak test — длительный прогон 72+ часа (утечки памяти, дрейф таймеров).
- Безопасность — fail-safe при отказе компонента (25010 Security).
Обработка результатов: гистограммы latency, не только среднее. Среднее 8 мс при пиках 80 мс может убить контур управления.
Связь с unit-тестами и white-box
Unit-тесты дополняют, но не заменяют стенд — в тесте нет конкуренции за CPU, прерываний, реальной шины.
Полезно на критичных модулях:
- white-box и профилирование hot path;
- покрытие веток с таймаутами;
- статический анализ на неблокирующие вызовы в critical path.
Выход на HIL — когда логика модуля уже стабильна.
Документирование и приёмка
В ПМИ (программа и методика испытаний) для РВ обязательно указывают:
- конфигурацию стенда (железо, версии прошивок, ОС);
- сценарии с частотами, длительностью, профилем нагрузки;
- критерии по времени (таблица: сценарий → max latency → pass/fail);
- протоколы с сырыми метриками (не только "тест прошёл").
См. ПМИ и сертификацию.
Типичные ошибки
- Нагрузка "средняя" — worst case не воспроизведён (пик в 8:00, аварийный шторм сигналов).
- Тест только на dev-PC — другой CPU, нет RTOS, нет реальной шины.
- Смотрят только среднее latency — jitter убивает control loop.
- Нет трассировки — при miss deadline нельзя доказать причину (какой поток, какой драйвер).
- Смешивают soft и hard требования — заказчик ждёт гарантии, команда сдаёт "в среднем норм".
Рекомендую читать дальше
| Тема | Материал |
|---|---|
| NFR в архитектуре | Проектирование под нефункциональные требования |
| Нагрузочное тестирование (веб) | Нагрузочное и стресс-тестирование производительности |
| Качество и метрики | ISO 25010 |
| Маршрут курса | intro |