Встроенное программное обеспечение управляет электронной частью изделия: читает входные сигналы, выполняет алгоритм, управляет выходами и обменивается данными с другими узлами. Поэтому его нельзя полноценно проверить отдельно от платы, датчиков, исполнительных устройств и реальных режимов работы.
Ниже — практическая схема для заказчика электронного устройства. Она помогает описать поведение программы, согласовать интерфейсы и заранее определить, что должен подтвердить опытный образец.
Что называют встроенным программным обеспечением
Встроенное ПО, или прошивка, выполняется внутри электронного устройства. Пользователь может вообще не видеть его как отдельную программу: результат проявляется в реакции контроллера на кнопку, показание датчика, сообщение по CAN или выход параметра за допустимый диапазон.
Состав программы зависит от архитектуры изделия. В одном устройстве это может быть компактный цикл опроса входов и управления выходами, в другом — несколько задач, журнал событий, диагностика и обмен с другими блоками. Название технологии само по себе не описывает результат. Для проекта важнее определить функции, режимы и ограничения.
Какие задачи решает программа внутри устройства
Удобно рассматривать встроенное ПО по пяти связанным группам задач.
- Запуск и начальная настройка. После подачи питания программа приводит аппаратные узлы в заданное состояние, настраивает периферию и определяет, можно ли перейти в рабочий режим.
- Работа с входами и выходами. Программа получает дискретные и аналоговые сигналы, фильтрует или преобразует данные и управляет реле, силовыми ключами, индикацией и другими исполнительными узлами.
- Алгоритм управления. Здесь задаются состояния, условия переходов, задержки, приоритеты, блокировки и реакции на ошибки. Для приемки важен не объем кода, а соответствие этого поведения требованиям.
- Обмен данными. Устройство принимает и передает сообщения через предусмотренные аппаратной частью интерфейсы. Программа должна знать формат данных, адресацию, периодичность и реакцию на потерю связи или некорректное сообщение.
- Диагностика и обслуживание. Проект может предусматривать контроль состояния, фиксацию ошибок, сервисные режимы и обновление программы. Нужный состав этих функций определяют в требованиях, а не добавляют автоматически ко всем изделиям.
Такое деление помогает обсуждать программу через наблюдаемые функции. Например, вместо фразы «нужна поддержка датчика» можно описать тип сигнала, диапазон, частоту чтения, допустимую задержку, обработку обрыва и действие системы при недостоверном значении.
Интерфейс — это не только название шины
UART, SPI, I2C и CAN обозначают способы обмена, но одного названия недостаточно для согласования двух узлов. Разработчику нужны электрические и программные параметры интерфейса.
| Что нужно определить | Пример вопроса |
|---|---|
| Физическое подключение | Какие уровни сигналов, разъем и назначение контактов используются? |
| Параметры обмена | Какая скорость, адресация и последовательность запуска нужны? |
| Формат данных | Какие сообщения, поля, единицы измерения и допустимые значения передаются? |
| Временные требования | Как часто приходят данные и какая задержка реакции допустима? |
| Ошибки | Что считать потерей связи, как обнаружить некорректные данные и в какое состояние перейти? |
| Совместимость версий | Как определить версию протокола и что делать при несовпадении? |
Для CAN дополнительно важны состав идентификаторов, периодические и событийные сообщения, тайм-ауты и поведение узла при нарушении обмена. Для локальной периферии важны последовательность включения, режимы работы и ограничения конкретного компонента. Эти решения связывают схему и программу: изменение аппаратного узла может потребовать изменения драйвера, конфигурации или логики.
Почему плату и программу проверяют совместно
Программа работает не с абстрактным входом, а с конкретной электрической цепью и периферией микроконтроллера. Ошибка может находиться по обе стороны этой границы. Неверный номинал или назначение вывода выглядит как программный сбой; неправильная конфигурация периферии — как неисправность платы.
Поэтому разработка обычно идет итерациями:
- требования переводят в архитектуру аппаратной и программной частей;
- определяют границу между драйверами, логикой устройства и протоколами;
- отдельные алгоритмы проверяют без целевой платы там, где это возможно;
- на опытном образце запускают питание, тактирование, память и периферию;
- последовательно подключают входы, выходы и каналы связи;
- проверяют нормальные, граничные и аварийные сценарии;
- найденные изменения переносят в код, схему и документацию.
Единый программный интерфейс драйверов, подобный описанному в документации Arm CMSIS-Driver, помогает отделить прикладную логику от деталей периферии. Но такая граница не отменяет проверку на целевой плате: электрические параметры, разводка, питание и реальная нагрузка остаются частью результата.
Как строится проверка встроенного ПО
Один успешный запуск подтверждает только один сценарий. Чтобы принять устройство осознанно, проверки связывают с требованиями и проводят на нескольких уровнях.
Отдельные функции и алгоритмы
Сначала проверяют вычисления, преобразование данных, переходы между состояниями и обработку известных входных наборов. Часть таких тестов можно выполнять без готового устройства. Это ускоряет поиск логических ошибок, но не заменяет аппаратную проверку.
Работа на опытной плате
После сборки образца проверяют запуск, входы и выходы, память, таймеры и интерфейсы. Инженеру важно сопоставлять события программы с электрическими сигналами: для этого используют средства отладки и измерительное оборудование.
Интеграция с другими узлами
Далее контроллер подключают к датчикам, исполнительным устройствам и каналам связи. Проверяют не только правильный обмен, но и паузы, повторные сообщения, выход параметров за диапазон и восстановление после ошибки.
Моделирование внешней системы
Когда реальное оборудование сложно, дорого или небезопасно использовать для каждого сценария, часть сигналов может формировать испытательный стенд. В HIL-подходе контроллер работает на своей аппаратуре, а стенд имитирует внешнюю систему, подает входы и оценивает выходы. Нужен ли такой уровень, зависит от проекта.
Проверка в составе изделия
Финальный сценарий должен учитывать реальное подключение и условия применения. НСЭ указывает, что опытные образцы проверяются на стенде и, если это предусмотрено задачей, в составе реального оборудования. Состав и критерии такой проверки нужно согласовать заранее.
Какие сценарии стоит записать до начала испытаний
Список зависит от назначения изделия, но обычно полезно разделить проверки на несколько групп:
- включение, выключение и повторный запуск;
- штатные режимы и переходы между ними;
- минимальные и максимальные допустимые входные значения;
- потеря датчика или связи;
- обрыв, короткое замыкание или недостоверный сигнал, если такой контроль предусмотрен схемой;
- одновременное возникновение нескольких команд или ошибок;
- восстановление после устранения причины отказа;
- сохранение и применение настроек, если эта функция входит в требования.
Для каждого сценария нужны исходное состояние, действие, ожидаемая реакция и критерий успешного результата. Формулировка «ошибка обрабатывается» слишком общая. Лучше указать, какой выход отключается, какое состояние фиксируется и при каком условии работа может продолжиться.
Что подготовить для обсуждения встроенного ПО
Полное техническое задание на первом обращении необязательно. Инженеру помогут исходные данные, которые уже известны:
- назначение устройства и оборудование, в составе которого оно работает;
- перечень входов, выходов, датчиков и нагрузок;
- питание, типы сигналов и аппаратные интерфейсы;
- алгоритм в виде режимов, состояний, условий и приоритетов;
- нормальная реакция и безопасное поведение при ошибках;
- состав обмена с другими устройствами;
- требования к настройке, диагностике и обновлению;
- условия эксплуатации и временные ограничения;
- сценарии, по которым будет приниматься опытный образец;
- имеющиеся схемы, протоколы, образец или описание действующего устройства.
Если часть параметров неизвестна, это тоже стоит отметить. Так инженер сможет отделить заданные требования от решений, которые предстоит выбрать в процессе разработки.
Как встроенное ПО входит в проект НСЭ
НСЭ рассматривает встроенное ПО как часть комплексной разработки электронного устройства. В подтвержденный состав проекта могут входить требования и архитектура, схема и печатная плата, подбор компонентов, программное обеспечение и протоколы обмена, опытные образцы и подготовка выпуска.
Для устройств управления отдельно описываются нормальные режимы, блокировки, диагностика и поведение при отказах. Состав работ, результат, сроки и стоимость определяются после оценки задачи и исходных материалов; универсальных условий для любого устройства на сайте не установлено.
Если требуется новый контроллер или электронный модуль, начните со страницы контрактной разработки электроники или посмотрите, какие данные нужны для разработки контроллера.
Материал подготовлен по действующим страницам НСЭ и открытой технической документации Arm CMSIS-Driver, Zephyr Project и NI по HIL-тестированию.
