Наш процесс разработки прошивки основан на пятиэтапном подходе

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

Шаг 1: Определите требования

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

Тестируемость — ключевой фактор; грамотно сформулированное требование должно позволять легко создавать тесты для проверки его выполнения. Правильный набор требований состоит из утверждений, начинающихся со слов «[продукт] должен…», концентрируясь на том, что требуется, а не на том, как это достигается, и обеспечивая ясность и тестируемость. Следовательно, эффективная архитектура основана на чётко определённых требованиях.

Шаг 2: Различия между архитектурой и дизайном

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

Проектирование системы представляет собой промежуточный уровень «как». Архитектура описывает общие характеристики, но не определяет имена функций и переменных. Документация по проектированию микропрограммного обеспечения заполняет эти детали, включая имена задач и обязанности в рамках конкретных подсистем или драйверов устройств, используемую ОСРВ (если таковая имеется) и особенности интерфейсов между подсистемами.

Фаза внедрения представляет собой самый низкий уровень иерархии управления проектами. Когда интерфейсы чётко определены на этапе проектирования, инженеры могут приступить к параллельной реализации различных компонентов. Хотя задачи могут различаться в зависимости от отрасли, их обычно можно разделить на три основные категории: соблюдение сроков в режиме реального времени, тестирование и управление разнообразием. Эти вопросы решаются на последних трёх этапах.

Шаг 3: Управление временем

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

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

Шаг 4: Проектирование с учетом тестирования

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

Наиболее распространенные уровни тестирования включают

:

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

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

3. Модульные тесты гарантируют, что отдельные программные компоненты, определенные на промежуточном этапе проектирования, работают должным образом. Эти тесты концентрируются на открытом API (интерфейсе прикладного программирования), который компонент предоставляет другим компонентам. Как правило, модульные тесты разрабатываются теми же разработчиками, которые пишут тестируемый код.

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

Шаг 5: Подготовьтесь к изменениям

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