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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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