Руководство по разработке прошивок: инжиниринг, процесс и партнеры

Устройство работает безупречно месяцами. Затем оно начинает пропускать окно связи один раз за несколько тысяч циклов. В журналах нет ничего очевидного. На столе остаются три объяснения: инверсия приоритетов в планировщике, временной бюджет, более жесткий, чем указано на бумаге, или медленная утечка памяти, которая проявляется только после достаточного времени работы. Ни одно из трех не подтверждено, и это нормально для такого рода проблем. На производственных линиях, где промышленные HMI-панели работают годами без перерыва, это знакомый тип неисправности. Он проявляется как закономерность, а не как трассировка стека, и поиск истинной причины обычно означает сначала исключение вероятных.

Такого рода расследования — это повседневная работа в разработке прошивок. Эта дисциплина лежит в основе практически каждого встраиваемого продукта — промышленных HMI-панелей, модулей ПЛК, узлов датчиков. Она имеет больший вес, чем обычный прикладной код, поскольку под ней нет операционной системы, которая могла бы перехватить сбой. Что бы ни сделала прошивка неправильно, аппаратура должна с этим смириться. На этой странице рассматривается инженерная сторона этой работы. Не менее важно, что она охватывает то, как это выглядит с другой стороны стола: процесс, терминология и вопросы, которые стоит задать перед выбором компании по разработке прошивок.

Введение

Что такое разработка прошивок?

Прошивка — это программный слой, наиболее близкий к кремнию. Она находится в энергонемикронезависимой памяти и выполняется непосредственно на микроконтроллере. В отличие от прикладного программного обеспечения, она редко работает поверх общей операционной системы. Она управляет собственной памятью, обрабатывает собственное время и восстанавливается после собственных сбоев — или не восстанавливается вовсе. Каждый регистр в технической документации — это ограничение, а не рекомендация: карта регистров определяет, что на самом деле возможно, прежде чем будет набрана хоть одна строка кода.

Критическая роль прошивки в современных встраиваемых системах

Каждый встраиваемый продукт зависит от прошивки для согласования замысла и физики. Сенсорная панель нуждается в прошивке для правильного подавления шумов сигнала. Контроллер двигателя нуждается в ней для обеспечения пределов крутящего момента, которые, как предполагает механическая конструкция, уже обеспечены. Когда прошивка ошибается, сбой не является косметическим. Это устройство, которое непредсказуемо ведет себя в полевых условиях, иногда в течение нескольких месяцев, прежде чем кто-либо заметит закономерность.

Ключевые инженерные проблемы, формирующие дизайн прошивки

Три ограничения формируют почти каждое решение по прошивке: ограниченные ресурсы, жесткие сроки реального времени и длительный срок службы. Почему именно эти три? Потому что они взаимодействуют. Микроконтроллер с несколькими сотнями килобайт памяти должен запускать стек связи, планировщик и прикладную логику, без какого-либо запаса, который есть у сервера. Сроки редко подлежат обсуждению — их пропуск означает не медлительность, а ошибку. И поскольку многие промышленные устройства остаются в эксплуатации в течение десятилетия или более, код должен оставаться понятным для кого-то, кто его не писал, задолго после того, как первоначальный автор ушел.

Принципы проектирования

Ограничения реального времени и детерминированное поведение

Реальное время не означает быстро. Это означает предсказуемость. Один и тот же вход, в наихудших условиях, должен давать одинаковый отклик в рамках одного и того же временного бюджета. Это достигается тщательным контролем приоритетов прерываний и короткими процедурами обработки прерываний, при этом недетерминированные операции выполняются вне критически важных по времени путей. Очевидным решением является просто ускорение всего. Это помогает среднему случаю. Это ничего не говорит о наихудшем случае, который здесь действительно имеет значение. Это различие постоянно проявляется при разработке прошивки для встраиваемых систем, где среднее значение выглядит нормально до тех пор, пока в полевых условиях не произойдет пик наихудшего случая.

Управление ресурсами: бюджеты памяти, питания и обработки

Каждый байт ОЗУ — это решение, а не значение по умолчанию. Встраиваемое ПО обычно предпочитает статическое выделение памяти динамическому, потому что фрагментированный кусок памяти приводит к непредсказуемым сбоям, часто вскоре после того, как код, вызвавший их, перестает вызывать подозрения. В долгоживущих промышленных конструкциях принято закладывать заметно больше Flash-памяти, чем предполагает первоначальная оценка, часто с запасом 20-30%. Нехватка памяти в середине проекта обходится гораздо дороже, чем первоначальная оплата немного более крупной детали. Энергетические бюджеты следуют аналогичной логике: устройство, агрессивно переходящее в спящий режим между событиями, может потреблять незначительную долю энергии по сравнению с устройством, находящимся в режиме ожидания, но только если сам путь пробуждения дисциплинирован. Процедура пробуждения, которая казалась слишком короткой, чтобы иметь значение, является обычным местом, где сэкономленная энергия может тихо утечь обратно.

Надежность, отказоустойчивость и безопасный отказ

Встраиваемое ПО должно предполагать, что что-то пойдет не так, потому что в реальных условиях это обязательно произойдет. Сторожевой таймер — это последняя линия обороны, а не вся оборона. Система, которая сбрасывается только при зависшем основном цикле, все еще может пропустить задачу, которая жива, но застряла, продолжая потреблять процессорное время, ничего полезного не делая. Многоуровневая защита работает лучше, чем полагаться на один механизм. Локальное восстановление после тайм-аутов связи, безопасные значения по умолчанию для поврежденной конфигурации и документированный путь возврата к известному рабочему состоянию после любого сброса охватывают большинство путей сбоя, независимо от причины их возникновения.

Архитектура системы

Паттерны архитектуры встраиваемого ПО: подходы на основе Bare-Metal, RTOS и Linux

Выбор архитектуры обычно сводится к тому, сколько независимых временных доменов должен одновременно управлять продукт. Суперцикл Bare-Metal прост и не имеет накладных расходов на планирование, что делает его разумным выбором для устройства, выполняющего одну задачу. RTOS оправдывает свои накладные расходы, когда продукту приходится одновременно управлять несколькими задачами — дисплеем, стеком связи и циклом управления, который не может ждать ни одного из них. Подход на основе Linux обменивает детерминизм на гибкость, и этот компромисс имеет смысл, когда продукту требуется богатый интерфейс или сетевой стек больше, чем гарантии жесткого реального времени.

Подход	Наилучшее соответствие	Основной компромисс
Bare-metal	Одноцелевые, экономически чувствительные устройства	Мало возможностей для роста при добавлении функций
RTOS	Несколько одновременных временных доменов	Дополнительный объем флэш-памяти/ОЗУ, накладные расходы на управление приоритетами
На базе Linux	Богатый пользовательский интерфейс, сетевые возможности, меньшая потребность в жестком реальном времени	Более слабые гарантии по времени, больший объем ресурсов

Уровни аппаратных абстракций и проектирование периферийных интерфейсов

Уровень аппаратных абстракций отделяет то, что логика приложения должна делать, от того, как это делает конкретный чип. Это разделение окупается в тот день, когда поставщик прекращает поставку компонента в середине производственного цикла — нужно менять только уровень абстракции, а не логику, построенную поверх него. Стоимость — это небольшие накладные расходы от косвенного вызова функций, порядка нескольких дополнительных циклов ЦП на вызов. Это стоит того, чтобы принять везде, кроме тех немногих путей, где каждый цикл уже имеет свою задачу.

Модульная архитектура для тестируемости, поддерживаемости и масштабируемости

Кодовая база прошивки, которая разделяет доступ к аппаратуре, основную логику и поведение приложения на отдельные уровни, может быть протестирована по частям, а не только целиком. Почему такое разделение так важно на практике? Потому что тестирование прошивки от начала до конца на реальном оборудовании — это медленно и часто требует физического доступа. Четкое разделение позволяет основной логике запускаться, сбоить и исправляться на ноутбуке разработчика задолго до того, как она коснется кремния. Пропуск этого разделения на ранних этапах — распространенный компромисс в быстро развивающихся проектах, и это обычно первое, к чему возвращаются, когда ревизия оборудования требует переписывания, а не замены.

Типичный стек разработки прошивок

Большинство встраиваемых продуктов, как только они выходят за рамки одноцелевой конструкции «bare-metal», переходят к довольно узнаваемому слоистому стеку. Логика приложения находится наверху. Ниже нее уровень промежуточного ПО обрабатывает такие вещи, как набор инструментов для пользовательского интерфейса, файловая система или стек протоколов. RTOS, если продукт ее использует, обеспечивает планирование ниже этого. Ниже RTOS находится уровень аппаратных абстракций, затем поставляемые поставщиком драйверы периферийных устройств, а внизу — сам микроконтроллер. Каждый слой существует для того, чтобы изолировать вышележащие уровни от детали, которая, вероятно, изменится — сегодня чип, завтра RTOS, послезавтра — фреймворк пользовательского интерфейса.

Руководство по внедрению

Жизненный цикл разработки прошивки: от требований до выпуска

Прошивка проходит этапы требований, ввода в эксплуатацию оборудования, архитектурного проектирования, реализации и валидации. В отличие от чистого программного обеспечения, доступность оборудования здесь задает темп. Ранние работы часто проводятся на оценочных платах, которые не совсем соответствуют финальному производственному оборудованию — достаточно близки для логики, но недостаточно для поведения при питании или целостности сигналов. Разрыв между ними — это то место, где обычно проявляются неожиданности на поздних стадиях.

Проектирование загрузчика, безопасные обновления и возможность перепрограммирования в полевых условиях

Загрузчик должен быть правильным с первой попытки. Это фрагмент кода, который восстанавливает все остальное, когда обновление идет не так. Двухбанковая компоновка, где новый образ проверяется перед активацией, позволяет устройству автоматически вернуться к предыдущему состоянию вместо того, чтобы стать неработоспособным. Проверка подписи закрывает вторую половину риска. Без нее канал обновления становится поверхностью для атаки, а не инструментом обслуживания. Большая часть проблем с загрузчиком в полевых условиях связана не столько с самой логикой проверки, сколько с предположениями о компоновке флэш-памяти, которые незаметно перестали соответствовать реальности после изменения размера раздела.

Стратегии тестирования: модульное, интеграционное, HIL и валидация на производстве

Модульные тесты выявляют логические ошибки на хост-машине, быстро и недорого, еще до того, как оборудование вообще появляется. Интеграционные тесты подтверждают корректное взаимодействие модулей. Тестирование Hardware-in-the-loop (HIL) — это момент, когда прошивка сталкивается с чем-то близким к реальности: реальное время, реальный электрический шум, реальное поведение датчиков. Оно обычно выявляет категорию ошибок, которую первые два уровня структурно не могут обнаружить, поскольку эта ошибка существует только при наличии реального времени и реального шума. Как в узлах датчиков с батарейным питанием, так и в промышленных продуктах HMI, HIL — это обычно место, где впервые обнаруживается фактическое поведение конструкции в наихудшем случае.

Отладка и наблюдаемость в условиях ограниченных ресурсов

Отладка прошивки в полевых условиях означает работу без инструментов, которые разработчик настольных систем считает само собой разумеющимися. Нет дампа ядра, ожидающего на диске. Зарезервированная область флэш-памяти для журналов сбоев и отладочный UART для легковесного трассировки охватывают основы. Подключение JTAG или SWD обеспечивает пошаговую отладку на стенде, а логический анализатор или осциллограф охватывают все, связанное со временем. Иногда единственная доступная наблюдаемость — это один вывод GPIO, переключаемый в нужный момент и считываемый на осциллографе. Ничто из этого не изящно. Все это работает, когда ничего другого недоступно.

Лучшие практики

Стандарты кодирования, обзор кода и статический анализ

Стандарт кодирования, такой как MISRA C, существует для устранения целых категорий ошибок до их возникновения, а не для того, чтобы замедлять инженеров ради самого себя. Инструменты статического анализа автоматически обнаруживают значительную часть из них. Тем не менее, обзор по-прежнему важен — человек-читатель часто задает вопрос, действительно ли обработчик прерываний настолько короток, как должен быть, а не просто компилируется ли он без ошибок.

Готовность к производству: анализ видов отказов, восстановление и защищенность

Прежде чем дизайн будет отправлен, стоит сознательно спросить, что произойдет, если эта переменная будет повреждена или этот датчик вернет значение вне нормального диапазона. Такой вид анализа видов отказов — негламурная работа. Именно эта работа не позволяет продукту отказывать способами, которые никто не подумал протестировать. Защищенность от температуры, вибрации и электрических помех следует той же логике: предполагайте, что окружающая среда окажет на устройство более сильное воздействие, чем в лаборатории.

CI/CD, конвейеры автоматизированного тестирования и предотвращение регрессий для прошивок

Конвейер сборки прошивки, который выполняет статический анализ и модульные тесты при каждом коммите, выявляет регрессии, пока они еще дешевы в исправлении. Дисциплина управления версиями так же важна, как и сам конвейер. Четкая модель ветвления, тегированные выпуски, связанные с конкретными аппаратными ревизиями, и заблокированные версии инструментария позволяют воспроизвести точный скомпилированный бинарный файл, который был выпущен месяцами ранее, из того же исходного кода, который фактически находится в эксплуатации. Без такой дисциплины отчет об ошибке от устройства в производстве может превратиться в небольшое расследование, только чтобы выяснить, какая сборка вообще запущена.

Укрепление безопасности для производственных прошивок

Безопасность должна быть частью архитектуры с самого начала, а не слоем, добавляемым прямо перед выпуском. Безопасная загрузка, шифрованная связь и минимальная площадь атаки — все это требует затрат времени на обработку, энергии и усложнения, поэтому именно безопасность отодвигается на второй план под давлением сроков. Так быть не должно. Подключенное устройство со слабым механизмом обновления — это уже не риск обслуживания. Это ответственность с серийным номером.

Протоколы связи и средства отладки

Прошивка редко работает изолированно от внешнего мира, и выбор протокола удивительным образом влияет на окружающую архитектуру. UART остается стандартом для простых соединений точка-точка и отладки при начальном запуске. CAN и RS-485 доминируют в промышленных и автомобильных условиях, где несколько узлов совместно используют шину, а электрические помехи являются реальностью. Ethernet и USB используются там, где более высокая пропускная способность или возможность подключения «plug-and-play» важнее, чем детерминированное время. Выбор неправильного протокола редко ломает прототип; он проявляется позже, когда шина оказывается загружена большим объемом трафика, чем тот, что был сгенерирован во время первоначального тестирования.

Что касается средств отладки, JTAG и SWD обеспечивают низкоуровневый доступ, необходимый для установки точек останова и проверки регистров во время начального запуска. Логический анализатор окупает себя при решении вопросов временных характеристик протоколов, например, прибывает ли кадр CAN в нужное время. Осциллограф является лучшим инструментом для всего, что связано с электрическими сигналами: провалы напряжения, дрожание тактового сигнала, сигнал, который теоретически выглядит чистым, но является шумным на реальной плате.

Процесс разработки прошивки: чего ожидать

Этапы от требований до развертывания

Проект прошивки обычно проходит пять видимых этапов: требования и осуществимость, начальный запуск оборудования, проектирование архитектуры и интерфейсов, реализация и валидация перед выпуском. Отличие от типичного программного проекта заключается во втором этапе. Прошивка не может по-настоящему начаться до тех пор, пока оборудование не будет существовать в какой-либо форме, даже в виде грубой оценочной платы, поскольку карта регистров и временное поведение не будут полностью известны до этого момента. Проекты, в которых архитектура прошивки пытается быть финализирована до поступления какого-либо оборудования, как правило, пересматривают эту архитектуру после получения реальных плат.

Временные рамки и факторы риска

Два фактора больше всего влияют на временные рамки разработки прошивки: стабильность аппаратного обеспечения к моменту начала работы над прошивкой и раннее начало тестирования по методу "аппаратное обеспечение в контуре" (hardware-in-the-loop). Когда аппаратное и программное обеспечение разрабатываются параллельно при тесном взаимодействии, большинство неожиданностей выявляются на ранней стадии, когда их еще дешево исправить. Эта схема достаточно распространена в проектах промышленной автоматизации, чтобы опытные команды намеренно строили вокруг нее контрольные точки обзора. Когда аппаратное и программное обеспечение разрабатываются изолированно, неожиданности, как правило, проявляются во время валидации, ближе к дате выпуска, где каждое исправление стоит больше времени в графике.

Разработка прошивки и встраиваемого ПО

Эти два термина настолько пересекаются, что часто используются как взаимозаменяемые, и в обычной беседе это обычно приемлемо. Технически, прошивка относится к коду низкого уровня, который работает ближе всего к аппаратному обеспечению, часто без операционной системы под ним. Встраиваемое программное обеспечение (embedded software) — это более широкая категория, которая включает прошивку, но также охватывает код прикладного уровня, работающий в системе встраиваемой Linux, промежуточном слое или фреймворке пользовательского интерфейса, расположенном поверх RTOS.

Аспект	Прошивка	Встраиваемое ПО (более широкое понятие)
Типичный слой	Ближе всего к кремнию, на уровне регистров	Может включать прикладные и пользовательские интерфейсы
Зависимость от ОС	Часто отсутствует или используется облегченная RTOS	Часто работает под управлением Linux или полноценной ОС
Частота обновлений	Нерегулярные, высокий риск при изменении	Может обновляться подобно обычному программному обеспечению

На практике различие имеет наибольшее значение при определении масштаба проекта. Компания, занимающаяся разработкой прошивок, цитируя работу по «прошивке», должна четко указывать, включает ли это уровни пользовательского интерфейса и сетевых взаимодействий, или только низкоуровневый управляющий код под ними.

Выбор языков, инструментов и платформы микроконтроллера

Языки программирования: C, C++ и место Rust

C остается стандартом для разработки прошивок, в основном из-за предсказуемой модели памяти и зрелости его инструментария у практически каждого поставщика микроконтроллеров. C++ добавляет полезные абстракции — классы, шаблоны — не жертвуя существенным контролем, и ограниченный набор его возможностей часто используется в производственных прошивках. Rust набирает обороты благодаря гарантиям безопасности памяти. Однако его инструментарий и поддержка поставщиков по-прежнему неравномерны за пределами набора популярных семейств чипов, что является основной причиной, по которой внедрение в промышленной прошивке происходит постепенно, а не немедленно.

Инструментарий и среды разработки

Выбор инструментария редко сводится только к компилятору. Он включает отладчик, инструмент прошивки и то, насколько хорошо поддерживается библиотека аппаратных абстракций поставщика. Часты случаи использования специфических IDE от поставщиков, построенных на основе открытых инструментариев, таких как GCC. Они имеют меньшее значение для повседневного кодирования, чем для того, насколько хорошо они интегрируются со статическим анализом и CI — именно эта интеграция позволяет управлять растущей кодовой базой годами, а не месяцами.

Выбор платформы микроконтроллера

Выбор чипа сводится к сопоставлению запаса ресурсов с фактическими временными доменами продукта, а не с самой высокой доступной тактовой частотой. Компонент с достаточным запасом флэш-памяти и ОЗУ стоит немного дороже за единицу, но позволяет избежать гораздо более дорогостоящей проблемы нехватки места в середине проекта. Долгосрочная доступность у поставщика имеет такое же значение, как и основные характеристики, особенно для промышленных продуктов с жизненным циклом, измеряемым годами, а не продуктовыми циклами, измеряемыми месяцами.

Периферийные устройства заслуживают такого же внимания, как и основные характеристики. Компонент, который экономит средства за счет сокращения количества каналов UART или АЦП, может потребовать неудобных обходных путей позже, когда дизайн будет завершен, а эти каналы окажутся востребованными. Экосистема вокруг семейства чипов — эталонные дизайны, поддержка сообщества, активно поддерживаемая библиотека абстракции — часто сокращает время разработки больше, чем незначительно более быстрая тактовая частота ядра.

Где применяется разработка встраиваемого ПО

Эта область выглядит схожей в разных отраслях, хотя ограничения меняются. Промышленные HMI-панели и модули ПЛК требуют длительного срока службы и устойчивости к электрическим помехам на производстве. Медицинские устройства добавляют строгие требования к валидации и прослеживаемости в дополнение к обычным требованиям надежности. Системы энергоснабжения и оборудование для зарядки электромобилей сочетают управление в реальном времени с обработкой отказов, рассчитанной на безопасность. Потребительские и промышленные IoT-устройства больше всего ориентированы на энергопотребление, поскольку многие работают от батарей или используют сбор энергии в течение нескольких лет до технического обслуживания. Робототехника и системы управления движением находятся ближе всего к крайнему пределу реального времени, где пропущенный срок выполнения — это механическое событие, а не просто программное.

Как выбрать партнера по разработке встраиваемого ПО

Критерии оценки

Несколько вопросов помогают отделить надежного партнера от рискованного еще до написания какого-либо кода. Есть ли у команды документированный процесс управления требованиями и тестирования, или она полагается на неформальные привычки, которые хранятся в голове у одного инженера? Смогут ли они объяснить, как справятся с ревизией оборудования, поступающей в середине проекта? Тестируют ли они на реальном оборудовании на раннем этапе или рассматривают тестирование в замкнутом контуре (hardware-in-the-loop) как нечто, что нужно добавить ближе к концу? Один вопрос, как правило, раскрывает больше, чем остальные: спросите, как предполагаемый партнер справился с последним срывом сроков и что он изменил после этого. Команда с реальным опытом поставки ответит на это прямо. Команда без такого опыта, как правило, уклоняется.

• Документированный процесс разработки, а не просто неформальные инженерные привычки
• Раннее и постоянное тестирование в замкнутом контуре (hardware-in-the-loop), а не тестирование, отложенное на конец
• Четкий план действий при изменении требований или оборудования в середине проекта
• Готовность обсудить недавнее отставание от графика и его последствия
• Знание соответствующих норм соответствия и практики безопасности для целевой отрасли

Что ожидать при работе с опытной командой

Структурированный процесс проявляется не столько в словах, сколько в результатах, получаемых по ходу работы. Отслеживаемые требования, записи испытаний, связанные с конкретными сборками, а также загрузчик и стратегия обновления, разработанные с самого начала, а не добавленные перед выпуском, являются видимыми признаками этого. Такая дисциплина снижает риск поставки, в основном, за счет более раннего выявления неожиданностей, когда их все еще легко устранить, вместо того, чтобы оставлять их для этапа валидации или для эксплуатации. STONE HMI применяет структурированные процессы разработки прошивок в рамках проектов автоматизации. Для покупателя, оценивающего услуги по разработке прошивок, такое соответствие процессов обычно является лучшим предиктором результата, чем индивидуальный послужной список любого отдельного инженера.

Часто задаваемые вопросы

Сколько обычно занимает разработка прошивки?

Это в значительной степени зависит от стабильности используемого оборудования. Хорошо определенное, одноцелевое устройство на известном оборудовании может быть готово за пару месяцев. Продукт с несколькими протоколами связи, пользовательским интерфейсом и оборудованием, которое все еще дорабатывается параллельно, занимает значительно больше времени, в основном из-за циклов проверки и повторной валидации, которые следуют за каждым изменением оборудования.

Нужна ли мне RTOS или достаточно bare-metal?

Если устройство управляет одной критичной по времени задачей с несколькими простыми фоновыми задачами, bare-metal обычно проще и дешевле в обслуживании. Как только появляются несколько независимых временных доменов, конкурирующих за один и тот же процессор, RTOS оправдывает свои накладные расходы, делая эту конкуренцию управляемой, а не случайной.

Каков самый большой риск в проекте прошивки?

Обнаружение проблемы синхронизации или ресурсов во время валидации, а не во время запуска. Почти каждое серьезное отставание от графика связано с предположением, которое было верным на оценочной плате и тихо перестало быть верным на производственном оборудовании.

Можно ли обновлять прошивку после выпуска устройства?

Обычно да, через загрузчик, предназначенный для этого — но безопасность такого обновления полностью зависит от решений, принятых на раннем этапе, особенно в отношении проверки подписи и поведения при откате. Доработка безопасных обновлений для устройства, выпущенного без них, возможна, но гораздо более ограничена, чем проектирование с учетом этого с самого начала.

Что увеличивает или уменьшает стоимость проекта прошивки?

Сложность синхронизации и коммуникационных протоколов важнее фактического объема кода. Устройство с одним циклом управления и простым дисплеем стоит значительно дешевле в разработке, чем устройство, одновременно управляющее несколькими протоколами, сложным пользовательским интерфейсом и строгими требованиями безопасности. Другим основным фактором стоимости является то, насколько поздно выявляются аппаратные проблемы — проблемы, обнаруженные во время запуска, дешевы, а те же проблемы, обнаруженные во время полевой валидации, — нет.

Для инженеров честным испытанием любой прошивки является то, что происходит в непредвиденных условиях — поврежденный пакет, кратковременное падение напряжения во время записи, датчик, который возвращает некорректные данные вместо чистого сбоя. Для руководителей проектов расчет проще, чем кажется: часы, не потраченные на проверку и валидацию перед выпуском, никуда не исчезают. Они смещаются вниз по цепочке разработки, и их стоимость растет с каждым пройденным этапом.

Именно поэтому сценарий, подобный описанному в начале этой страницы, редко разрешается одной драматической причиной. На практике проблемы планировщика и временные ограничения обычно исключаются первыми, поскольку они, как правило, проявляются раньше в процессе тестирования, если вообще присутствуют. То, что остается после исключения, — это часто «медленная утечка» — режим отказа, достаточно «терпеливый», чтобы скрываться месяцами безупречной работы. В промышленных HMI-системах такая утечка обычно проявляется через несколько недель непрерывной работы, что значительно превышает продолжительность большинства лабораторных испытаний. Прошивка — это та часть продукта, которую никто не видит до тех пор, пока она не выйдет из строя. Создание ее правильно с первого раза и ее валидация так, как будто она будет работать годами без присмотра, по-прежнему является более дешевым вариантом.