Процес розробки нашого прошивки базується на п'ятиетапному підході

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

Крок 1: Визначення вимог

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

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

Крок 2: Розрізнення архітектури та дизайну

З нашого досвіду, багато інженерів та їхніх менеджерів мають труднощі з розмежуванням різних аспектів розробки прошивки. Архітектура системи являє собою найвищий рівень ЯК, визначаючи довготривалі функції продукту та ускладнюючи його зміну після встановлення. Це вимагає ретельного врахування передбачуваного та допустимого використання продукту, щоб забезпечити правильне виконання.

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

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

Крок 3: Управління часом

Деякі вимоги до продукту містять чіткі часові обмеження. Як правило, продукти містять комбінацію вимог нереального часу, м'якого реального часу та жорсткого реального часу. З них м'які терміни часто є найскладнішими для чіткого визначення, тестування та впровадження. Після визначення термінів першим кроком у процесі архітектури є перенесення якомога більшої кількості вимог, чутливих до часу, з програмного забезпечення на апаратне забезпечення.

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

Крок 4: Розробка з урахуванням тестування

Важливо тестувати кожну вбудовану систему на кількох рівнях. У багатьох випадках тестування на різних рівнях є не тільки цінним, але й обов'язковим.

Найпоширеніші рівні тестування включають

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

2. Інтеграційні тести проводяться для того, щоб переконатися, що підмножини підсистем, як зазначено на схемах архітектури, взаємодіють належним чином і дають очікувані результати. Ці тести зазвичай розробляються командою тестування або особою у відділі розробки програмного забезпечення.

3. Модульні тести гарантують, що окремі компоненти програмного забезпечення, визначені на проміжному етапі проектування, працюють належним чином. Ці тести зосереджені на публічному API (інтерфейсі прикладного програмування), який компонент пропонує іншим компонентам. Як правило, модульні тести розробляються тими ж людьми, які пишуть код, що тестується.

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

Крок 5: Підготуйтеся до змін

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