Заказные системы реального времени
С чего начать — «реальное время» — это не «быстро»
Система реального времени (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 — как работает компьютер, промышленность.
:::info Экономика РВ-проекты дороже: спецжелезо, стенды, длинные прогоны, сертификация. В 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 в архитектуре | 1116 |
| Нагрузочное тестирование (веб) | 122 |
| Качество и метрики | ISO 25010 |
| Маршрут курса | intro |
См. также
Другие статьи этого же раздела в боковом меню (как на странице «О разделе»). На совещании вы слышите: «эта фича — 8 story points». Это работает внутри команды, когда все знают прошлые спринты. Восемь характеристик качества ПО простым языком: что писать в ТЗ, как проверять на приёмке и почему «без багов» — мало. SCM простым языком: конфигурационные единицы, baseline, контроль изменений и связь с Git, CI/CD и ГОСТ-документацией. Что происходит с заказным ПО после акта приёмки: виды сопровождения, SLA, экономика и типичные ошибки — простым языком. Испытания, удостоверение качества и сертификация — простым языком: ПМИ, акт приёмки, ФСТЭК и что закладывать в смету. Какие компетенции нужны PM, архитектору, аналитику, разработчику и QA на заказном проекте — и как это влияет на оценку COCOMO.Модель COCOMO II — прогноз трудоёмкости и стоимости
Модель качества ISO/IEC 25010
Управление конфигурацией программных комплексов
Сопровождение программных комплексов
Сертификация и приёмка заказных программных продуктов
Квалификация команды для заказной разработки