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

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

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

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

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

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

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

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

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

Step 3: Time Management

Some product requirements will specify explicit time constraints. Typically, products include a combination of non-real-time, soft-real-time, and hard-real-time requirements. Of these, soft deadlines are often the most challenging to define clearly, test, and implement. Once deadlines are identified, the initial step in the architectural process is to offload as many time-sensitive requirements from the software to the hardware as possible.

The separation of real-time functionality from the main software provides two key benefits. Firstly, it simplifies the design and implementation of the non-real-time software. By removing time constraints from the bulk of the code, even novice developers can contribute without compromising user safety. Secondly, consolidating real-time functionality makes it easier to analyse and ensure that all deadlines are consistently met.

Step 4: Design with Testing in Mind

It is essential to test every embedded system at multiple levels. In many cases, testing at various levels is not only valuable but also mandatory.

The most common levels of testing include

1. System tests have confirmed that the product as a whole meets or exceeds the specified requirements. It is recommended that these tests be developed outside the engineering department, although they can be incorporated into a test harness designed by engineers.

2. Integration tests are conducted to ensure that subsets of the subsystems, as outlined in the architecture diagrams, interact properly and yield the expected results. These tests are typically developed by a testing team or individual within the software engineering department.

3. Unit tests guarantee that individual software components, as defined at the intermediate design stage, operate as intended. These tests concentrate on the public API (Application Programming Interface) that the component offers to other components. Typically, unit tests are developed by the same individuals who write the code being tested.

Of the three types of tests, system tests are the most straightforward to develop. A test harness may be required for engineering and factory acceptance tests, but this process is generally simpler than integration and unit tests, which require more internal visibility into the device's operation. To streamline the development, use, and maintenance of integration and unit tests, it's advisable to design the firmware in a way that aligns with a software test framework. The most effective approach is to structure the interactions between all software components at the levels you intend to test.

Step 5: Prepare for Change

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