Мы следуем пятиэтапному процессу разработки прошивки.

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

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

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

Шаг 1: Определите необходимые характеристики.

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

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

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

Ключевым элементом является тестируемость. Хорошо написанное требование позволяет легко создать набор тестов для проверки выполнения требования.

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

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

Шаг 2. Различайте архитектуру и дизайн

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

Архитектура системы — это верхний уровень функциональности продукта. Этот слой определяет долговременные характеристики, поэтому их трудно изменить. В результате важно тщательно оценить целевые и утвержденные цели продукта.

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

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

Внедрение является наиболее детальным этапом процесса. Четкие интерфейсы, созданные на этапе проектирования, позволяют инженерам одновременно создавать отдельные компоненты.

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

Шаг 3: Тайм-менеджмент

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

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

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

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

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

Шаг 4. Тестово-ориентированное проектирование

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

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

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

3. Юнит-тесты подтверждают, что назначенные компоненты программного обеспечения, указанные в промежуточном проекте, работают так, как задумано разработчиком.

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

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

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

Шаг 5: Подготовьтесь к переменам

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

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

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