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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

:

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

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

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

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

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

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