The problems of embedded systems special software effective testing and their elaboration
The paper examines the problem of sustainable testing of special software for embedded systems under conditions of rapid hardware evolution, configuration variability, and shortened update cycles. It shows that modern embedded products are characterized by a partial separation of hardware and softwa...
Збережено в:
| Дата: | 2026 |
|---|---|
| Автори: | , |
| Формат: | Стаття |
| Мова: | Українська |
| Опубліковано: |
PROBLEMS IN PROGRAMMING
2026
|
| Теми: | |
| Онлайн доступ: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/891 |
| Теги: |
Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
|
| Назва журналу: | Problems in programming |
| Завантажити файл: |  |
Репозитарії
Problems in programming| _version_ | 1863311599512584192 |
|---|---|
| author | Yerofieiev, Yu.V. Sinitsyn, I.P. |
| author_facet | Yerofieiev, Yu.V. Sinitsyn, I.P. |
| author_sort | Yerofieiev, Yu.V. |
| baseUrl_str | https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| collection | OJS |
| datestamp_date | 2026-04-23T22:26:13Z |
| description | The paper examines the problem of sustainable testing of special software for embedded systems under conditions of rapid hardware evolution, configuration variability, and shortened update cycles. It shows that modern embedded products are characterized by a partial separation of hardware and software life cycles, a growing role of controlled firmware updates, component reuse, and the integration of computer vision and artificial intelligence algorithms. It is substantiated that, in such conditions, testing should not be limited to defect detection, but should also support quality forecasting, integration decisions, and the accumulation of reusable testing assets. The study summarizes typical embedded-system architectures and approaches to constructing special software, including layered and microservice-oriented architectures, test-driven development, agile methods, model-based development, and continuous integration, continuous testing, quality assurance, and security practices. The role of XiL approaches, configuration management, and artifact traceability in ensuring environment reproducibility is highlighted. Sustainable reuse of testing work products within the software product line paradigm is proposed as a basis for increasing the maturity of development and testing processes for special embedded software.Problems in programming 2026; 1: 51-65 |
| first_indexed | 2026-04-24T01:00:15Z |
| format | Article |
| fulltext |
Програмна інженерія – прикладні методи
51
©Ю.В. Єрофеєв, І.П. Сініцин, 2026
ISSN 1727-4907. Проблеми програмування. 2026. №1
УДК 004.41:004.05 https://doi.org/10.15407/pp2026.01.051
Ю.В. Єрофеєв, І.П. Сініцин
ПРОБЛЕМИ ЕФЕКТИВНОГО ТЕСТУВАННЯ
СПЕЦІАЛЬНИХ ПРОГРАМНИХ ЗАСОБІВ
ВБУДОВАНИХ СИСТЕМ ТА ЇХ ОПРАЦЮВАННЯ
Розглянуто проблему результативного й ресурсно ефективного тестування спеціальних програмних за-
собів (СПЗ) вбудованих систем (ВС) в умовах істотної різнорідності й швидкої еволюції апаратних
платформ, мінливості конфігурацій і скорочення циклів еволюції СПЗ. Показано, що для сучасних вбу-
дованих виробів характерні часткова незалежність життєвих циклів апаратної та програмної складових
і зростання ролі керованої модернізованості СПЗ ВС. Обґрунтовано потребу в таких умовах не лише
виявлення дефектів, а й додаткових функцій тестування: прогнозування (не)задовільної якості СПЗ і
ВС загалом, підтримку рішень щодо інтеграції СПЗ і накопичення повторно використовуваних тесто-
вих активів. Узагальнено особливості типових архітектур ВС і підходів до конструювання СПЗ ВС,
значущі для забезпечення вищезазначених додаткових функцій тестування, зокрема, рамкову та мікро-
сервісну архітектури, розроблення, кероване тестами, гнучкі методології, розроблення на основі моде-
лей, а також підходи безперервної інтеграції й безперервного тестування. Показано роль XiL-підходів,
керування конфігураціями та контролювання зв’язків між артефактами для забезпечення відтворюва-
ності середовища тестування. Запропоновано розглядати стале повторне використання робочих проду-
ктів тестування в руслі парадигми лінійок програмних продуктів як основу для сталого підвищення зрі-
лості процесів тестування СПЗ ВС та їх конструювання загалом.
Ключові слова: вбудована система, спеціальні програмні засоби, тестування, повторне використання,
лінійка програмних продуктів, безперервна інтеграція, безперервне тестування, життєвий цикл, про-
грамна архітектура, керування конфігурацією.
Yu.V. Yerofieiev, I.P. Sinitsyn
THE PROBLEMS OF EMBEDDED SYSTEMS SPECIAL
SOFTWARE EFFECTIVE TESTING AND THEIR ELABORA-
TION
The paper examines the problem of sustainable testing of special software for embedded systems under
conditions of rapid hardware evolution, configuration variability, and shortened update cycles. It shows that
modern embedded products are characterized by a partial separation of hardware and software life cycles, a
growing role of controlled firmware updates, component reuse, and the integration of computer vision and
artificial intelligence algorithms. It is substantiated that, in such conditions, testing should not be limited to
defect detection, but should also support quality forecasting, integration decisions, and the accumulation of
reusable testing assets. The study summarizes typical embedded-system architectures and approaches to
constructing special software, including layered and microservice-oriented architectures, test-driven
development, agile methods, model-based development, and continuous integration, continuous testing, quality
assurance, and security practices. The role of XiL approaches, configuration management, and artifact
traceability in ensuring environment reproducibility is highlighted. Sustainable reuse of testing work products
within the software product line paradigm is proposed as a basis for increasing the maturity of development
and testing processes for special embedded software.
Keywords: embedded system, special software, testing, reuse, software product line, continuous integration,
continuous testing, life cycle, software architecture, configuration management.
https://pp.isofts.kiev.ua
CC BY 4.0
Програмна інженерія – прикладні методи
52
Вступ
У сучасних вбудованих системах
(ВС) спеціальні програмні засоби (СПЗ) є
одним із найскладніших, найуразливіших і
водночас найбільш критичних складників
[1, 2]. На відміну від програмних засобів
загального призначення, СПЗ ВС функціо-
нують в умовах жорстких ресурсних об-
межень, вимог реального часу або близь-
ких до нього, обмежень енергоспоживан-
ня, а також тісної залежності від апаратної
платформи й фізичного оточення через
взаємодію з датчиками та виконавчими
механізмами. У зв’язку з цим дефекти СПЗ
можуть спричиняти не лише функціональ-
ні збої, а й відмови ВС загалом, порушення
вимог безпеки, загрози й втрати для дов-
кілля та життя й здоров’я людини.
За цих умов тестування СПЗ ВС
має, крім традиційного виявлення дефектів
СПЗ, виконувати ще й додаткові функції:
а) надавати адекватні дані для
(не)кількісного прогнозування якості СПЗ
і ухвалення рішень щодо їх інтеграції з
операційною системою, процесором, апа-
ратними засобами;
б) підтримувати прогнозування ві-
рогідних технічних та організаційних про-
блем у життєвому циклі (ЖЦ) ВС;
в) забезпечувати накопичення тес-
тових артефактів і допоміжних даних для
постійного вдосконалення процесів тесту-
вання й конструювання СПЗ в умовах об-
межених ресурсів.
Разом функції a)-в) зумовлюють
зростання актуальності проблеми сталого
повторного використання робочих продук-
тів тестування в ЖЦ СПЗ і ВС. загалом.
Особливо важливою вона є для організа-
цій-розробників, що створюють ВС різних
типів у різних предметних областях і не
обмежуються однією апаратною та про-
грамною платформою. Саме розв’язання
цієї проблеми створює підґрунтя для узго-
дженого досягнення вищезазначених цілей
тестування та зрештою підвищення зрілос-
ті процесу конструювання ВС.
Метою статті є окреслення підходу
до сталого повторного використання робо-
чих продуктів тестування СПЗ ВС у рам-
ках парадигми лінійок програмних проду-
ктів (Software Product Lines), зумовленого
особливостями ЖЦ сучасних ВС: різнорі-
дністю апаратно-програмних платформ,
стислими термінами, обмеженими обчис-
лювальними ресурсами.
1. Особливості СПЗ ВС, значущі
для їх тестування
Типові архітектури ВС і СПЗ ВС.
Детальний аналіз сучасних ВС у різних
предметних областях [2] висвітлює три
узагальнені типи їхньої архітектури: рам-
кову (reference), із застосуванням шару
абстракції обладнання та мікросервісну.
В історично першій рамковій архі-
тектурі ВС (рис. 1) СПЗ безпосередньо
взаємодіє з драйверами пристроїв та опе-
раційною системою, які в свою чергу вза-
ємодіють з апаратними засобами [2, 3].
Рис. 1. Рамкова архітектура ВС
Подальший розвиток апаратних за-
собів зумовив поширення прошарованої
архітектури [2] для СПЗ ВС, що являють
собою монолітну збірку (так звану проши-
вку (firmware)). Ці СПЗ подано переліком
програмних шарів. Кожний шар має при-
наймні один інтерфейс щодо суміжного
шару, визначений його типом. Інтерфейси
надають узгоджений доступ до функцій
СПЗ, приховують внутрішні деталі їх реа-
лізації та можуть виступати як обгортки
для інтеграції несумісного коду між шара-
ми [1].
Найпоширенішим і водночас най-
практичнішим прошарком прошивки є шар
абстракції обладнання (hardware abstrac-
tion level) [1]. По суті це прикладний про-
грамний інтерфейс для взаємодії з облад-
Програмна інженерія – прикладні методи
53
нанням, який замінює доступи на рівні
апаратних засобів викликами функцій ви-
щого рівня (рис. 2).
Рис. 2. Архітектура ВС з використанням
шару абстракції обладнання
Саме він має забезпечити перенос-
ність і повторне використання СПЗ ВС та
його позитивні ефекти: зниження вартості
конструювання СПЗ і ВС загалом; підви-
щення рівня абстракції; зменшення кілько-
сті помилок завдяки багаторазовій експлу-
атації; спрощення масштабування, зокре-
ма, перенесення на нові апаратні засоби й
ВС у межах одного сімейства.
Нарешті для опрацювання обме-
жень розглянутих архітектур ВС протягом
останньої декади набула активного розви-
тку мікросервісна архітектура (рис. 3).
Рис. 3. Мікросервісна архітектура ВС на
базі вбудованої операційної системи
Мікросервісна архітектура подає
користувацький застосунок множиною
взаємодіючих автономних мікросервісів,
зорієнтованих на його прикладні функції.
Типова реалізація мікросервісу у ВС від-
повідає окремому процесу або зада-
чі/набору задач ОС із власними ресурсами
та механізмами ізоляції, якщо вони досту-
пні. Концептуально мікросервіс містить
код сервісу, вхідну чергу повідомлень,
механізми надсилання вихідних повідом-
лень, логування та індикатори стану для
моніторингу працездатності.
Мікросервісна архітектура є де-
факто стандартною для гнучких методоло-
гій розроблення СПЗ, практик DevSecOps і
конвеєра безперервної інтеграції й достав-
ки (CI/CD). Низький рівень зв’язності сер-
вісів полегшує й пришвидшує процес тес-
тування, спрощує масштабування та замі-
ну сервісів без істотного порушення робо-
ти всього СПЗ.
Однак, водночас із окресленими пе-
ревагами, ця архітектура підвищує склад-
ність проєктування та створює накладні
витрати на комунікації та пам’ять; децент-
ралізований обмін повідомленнями може
ускладнювати досягнення детермінованої
поведінки в реальному часі та збільшувати
час відгуку. Повна незалежність розгор-
тання сервісів не завжди має місце в ресу-
рсно-обмежених ВС, особливо за відсут-
ності розвиненого механізму керування
або в спрощених операційних -
середовищах.
Тому застосування мікросервісів у
ВС потребує попереднього аналізу вимог,
обмежень платформи та декомпозиції фу-
нкцій СПЗ ВС.
Зовнішнє ділове середовище
конструювання СПЗ ВС. Однією з визна-
чальних особливостей зовнішнього ділово-
го середовища конструювання ВС є зрос-
тання впродовж останнього десятиліття
ролі Інтернету речей – класу розподілених
ВС, здатних збирати й передавати дані
мережею без безпосередньої участі -
людини.
Ця тенденція зумовлює істотну різ-
норідність методів і технологій конструю-
вання СПЗ ВС, які зручно розподілити за
двома форматами:
а) «традиційним», згідно з яким
СПЗ ВС розробляють із вузько-
спеціалізованою функціональною метою
для певної апаратної платформи й визна-
ченого сценарію застосування;
Програмна інженерія – прикладні методи
54
б) «диверсифікованим», який пе-
редбачає конструювання низки мінливих
СПЗ ВС (і, можливо, самих ВС як послугу
повного циклу) для різних споживачів
та/або предметних областей із викорис-
танням подібних між собою, але мінливих,
апаратних платформ (рис. 4).
a)
б)
Рис. 4. Розподіл ВС: a) за предметними
областями; б) за мовами програмування
Такі СПЗ не лише допускають пев-
ну повторюваність операцій конструюван-
ня як на низькому (драйвери, первинні
завантажувачі, bootloaders) так і на вищих
рівнях (модулі й бібліотеки), а й потребу-
ють її для підвищення якості та зрілості
процесів конструювання. Основними мо-
вами програмування для конструювання
СПЗ ВС в обох форматах є С та С++. Од-
нак розвиток сучасних архітектур СПЗ ВС,
насамперед мікросервісної, зумовлює зро-
стання частки інших МП, зокрема, Python і
Java (рис. 4).
Внутрішнє ділове середовище
конструювання СПЗ ВС. Для врахування
описаних вище особливостей зовнішнього
ділового середовища компанії-розробники
активно вдосконалюють власні процеси та
інструменти для забезпечення конкуренто-
спроможної якості СПЗ ВС.
«Традиційний» формат а), за якого
СПЗ конструюють у де-факто спільному
життєвому циклі (ЖЦ) з пристроєм, пос-
тупово вичерпує потенціал [1, 3]: він
ускладнює швидке нарощування функцій,
адаптацію до нових умов застосування та
підтримку ВС упродовж тривалого строку
експлуатації.
Ключовою ідеєю новітніх підходів,
властивих «диверсифікованому» формату
б), є організація відносно незалежних ЖЦ
для СПЗ та апаратних засобів. Апаратна
платформа еволюціонує за власним цик-
лом (ревізії, компонентна база). Натомість
СПЗ конструюють як постійно оновлюва-
ний продукт: із можливістю регулярних
випусків, підтримкою сумісності й конт-
рольованими змінами без повного реінжи-
нірингу СПЗ і тим паче ВС під кожне вдо-
сконалення [1, 2].
Зокрема, у перспективній сфері ав-
тономних наземних комплексів вдоскона-
лення процесів конструювання відбуваєть-
ся одночасно двома «траєкторіями» – апа-
ратній і програмній, із різними темпами та
обмеженнями.
Вирішальним чинником реалізації
такого підходу стає гнучкість архітектури
СПЗ і здатність до керованого оновлення
як СПЗ загалом («прошивки»), так і окре-
мих компонентів СПЗ – бібліотек, сервісів,
модулів оброблення даних. Це дозволяє
прийнятно швидко покращувати функції
та якісні характеристики СПЗ, зберігаючи
контроль над версіями, залежностями та
конфігураціями в умовах мінливості плат-
форм і сценаріїв використання.
Вдосконалювальні зміни стосують-
ся двох взаємопов’язаних аспектів: органі-
заційного (процесного) та інфраструктур-
ного (технологічного).
До інфраструктурних тенденцій на-
лежать: удосконалення тестових стендів,
зокрема, із підтримкою віддаленого досту-
пу; розроблення та впровадження засобів
автоматизації тестування СПЗ ВС у конфі-
гураціях XiL (X-in-the-Loop), включно з
MiL (Model-in-the-Loop), SiL (Software-in-
the-Loop), PiL (Processor-in-the-Loop) та
HiL (Hardware-in-the-Loop) [4], а також
відповідних моделей середовища; наскріз-
на автоматизація тестів на різних рівнях;
керування конфігураціями й артефактами
повторного використання. Організаційно
ключовими є перехід до безперервної інте-
грації та регресійного тестування
Програмна інженерія – прикладні методи
55
(Continuous Integration (CI)), а також адап-
тація гнучких методів розроблення (Agile)
до специфіки СПЗ ВС та обмежень апара-
тної платформи.
Доцільно розрізняти такі XiL-
конфігурації:
– MiL (Model-in-the-Loop) –
верифікація алгоритмів на рівні моделей;
– SiL (Software-in-the-Loop) – тесту-
вання виконуваного коду в симульованому
середовищі;
– PiL (Processor-in-the-Loop) – ви-
конання коду на цільовому процесорі з
модельованими периферійними умовами;
– HiL (Hardware-in-the-Loop) – інте-
граційне тестування із реальним апарат-
ним компонентом у контурі.
Фактично конструювання СПЗ ВС
перебуває в стані технологічної конкурен-
ції, у межах якої постійно з’являються нові
пристрої та конфігурації, а самі СПЗ без-
перервно оновлюються й ускладнюються
(зокрема, бібліотеками й компонентами
для реалізації алгоритмів комп’ютерного
зору й штучного інтелекту). У цьому кон-
тексті дедалі більш запитаним стає підхід
QAOps [5, 6] – сукупність організаційно-
інфраструктурних практик, зорієнтована
на спільну відповідальність за якість
(Dev/QA/Ops), запровадження керованих
критеріїв допуску змін (quality gates), за-
безпечення відтворюваності середовищ і
накопичення повторно використовуваних
тестових активів (зокрема, в межах лінійок
програмних продуктів).
Актуальні особливості процесів
ЖЦ СПЗ ВС і ВС. У таблиці 1 співставле-
но особливості процесів технічного керу-
вання та технічних процесів, що безпосе-
редньо впливають на вимоги, архітектуру,
інтеграцію та верифікацію/валідацію СПЗ
у ЖЦ ВС, згідно з ДСТУ ISO/IEC/IEEE
12207, 1528.
Таблиця 1.
Особливості процесів ЖЦ СПЗ ВС
Процес ЖЦ Об’єкт процесу Особливість СПЗ ВССПЗ ВС
Процеси технічного керування
Керування ризи-
ками (Risk
Management)
Ризики системи:
технічні, виробничі,
експлуатаційні
Ризики ПЗ: дефекти,
вразливості, технічний
борг
Додаються ризики: обмежені ресурси,
реальний час, залежність від платформи,
кібербезпека, обмежений час доступно-
сті компонентів
Керування конфі-
гурацією
(Configuration
Management)
Конфігурація виробу
та варіантів: апаратна
ревізія, BOM, інтер-
фейси
Конфігурація коду, збірок
і релізів: версії, гілки,
артефакти
Єдина ідентифікація конфігурації.
Перелік (відомість) матеріалів програм-
ного забезпечення.
Специфікація складу апаратних компо-
нентів
Управління інфо-
рмацією
(Information
Management)
Артефакти системи:
вимоги, архітектура,
інтерфейси, протоко-
ли випробувань
Артефакти ПЗ: код, збір-
ки, тести, звіти
Простежуваність (traceability) артефак-
тів від вимог до тестів і випусків/релізів
Забезпечення
якості (Quality
Assurance)
Забезпечення якості
системи: відповід-
ність вимогам та
критеріям приймання
Забезпечення якості ПЗ:
стандарти кодування,
метрики, контроль дефе-
ктів
Атрибути якості: затримка, енергоспо-
живання, температурні режими, відмо-
востійкість, функціональна безпека та
кібербезпека
Технічні процеси
Визначення пот-
реб і вимог заінте-
ресованих сторін
(Stakeholder Needs
& Requirements)
Потреби користува-
чів/місії на рівні
виробу
Потреби до ПЗ як склад-
ника системи
Уточнення потреб до автономності,
сенсорів, зв’язку, експлуатаційних умов
і обмежень
Програмна інженерія – прикладні методи
56
Визначення сис-
темних і програм-
них вимог
(System/Software
Requirements
Definition)
Системні вимоги:
функціональні та
нефункціональні
Вимоги до ПЗ: функції,
інтерфейси, обмеження
Інтерфейси з периферією, протоколи,
обмеження пам’яті/CPU, вимоги до
оновлення/відновлення, захищений
завантажувач (secure boot)
Визначення архі-
тектури
(Architecture
Definition)
Архітектура системи
та розподіл функцій
між підсистемами
Архітектура ПЗ: компо-
ненти, інтерфейси, взає-
модія
Код-дизайн апаратної і програмної
частини , ізоляція безпечні межі взаємо-
дії
Визначення проє-
ктного рішення
(Design Definition)
Проектування ком-
понентів системи Проектування модулів ПЗ Проектування драйверів, станів і режи-
мів
Системний аналіз
(System Analysis)
Аналіз альтернатив і
компромісів систем-
ного рівня
Аналіз рішень на рівні ПЗ
Компроміси: точність vs швидкодія,
енергоспоживання vs продуктивність,
пам’ять vs функціональність
Реалізація
(Implementation)
Реалізація компонен-
тів системи
Реалізація ПЗ, збірка та
інтеграція залежностей
Крос-компіляція, оптимізації під плат-
форму, захист ключів і секретів
Інтеграція
(Integration)
Інтеграція на рівні
системи
Інтеграція компонентів
ПЗ
Робочий макет апартаного забеспечен-
ня, драйвери, інтеграція модулів
комп’ютерного зору та AI-моделей;
сумісність із ревізіями HW
Верифікація
(Verification)
Перевірка відповід-
ності вимогам
Верифікація ПЗ: огляди,
аналіз, тестування
SiL/HiL, ін’єкція відмов (fault injection),
fuzzing , аналіз покриття та часових
характеристик
Перехід
(Transition)
Передача в експлуа-
тацію та/або вироб-
ництво
Реліз ПЗ та розгортання
Підписані образи, provisioning, OTA;
перевірка у впливових умовах (темпера-
тура/вібрації/зв’язок) і сценаріях відмов
Валідація
(Validation)
Підтвердження при-
датності системи для
потреб у цільовому
середовищі
Валідація ПЗ в контексті
системи
Польові випробування, acceptance-
сценарії, оцінювання автономних функ-
цій у репрезентативних умовах
Експлуатація
(Operation)
Експлуатація систе-
ми Експлуатація ПЗ
Телеметрія, логування, віддалена
діагностика, контроль ресурсів і
конфігурації
Супровід
(Maintenance) Супровід системи. Супровід ПЗ. Регулярні оновлення, підтримка та
керування сумісністю варіантів.
Виведення з екс-
плуатації
(Disposal)
Виведення системи з
експлуатації
Виведення ПЗ/даних з
експлуатації
Безпечне стирання даних і ключів,
deprovisioning; вимоги комплаєнсу
(compliance)
Таблиця 1 надає процесне підґрунтя
для проєктування стратегії тестування са-
ме СПЗ ВС, визначення артефактів і меж
відповідальності між рівнями СПЗ і ВС та
ідентифікації специфічних для СПЗ ВС
чинників – обмежених ресурсів, режиму
реального часу, довготривалого супроводу,
постійного оновлення та вимог -
кібербезпеки.
Еволюція моделей ЖЦ СПЗ ВС,
особливості якої підсумовано в табл. 2,
зумовлена зростанням складності програ-
мно-апаратної інтеграції, підвищенням
вимог до швидкості внесення змін, а також
необхідністю забезпечення простежувано-
сті, надійності й безпеки на всіх рівнях
розроблення. Якщо традиційнуV-модель
зорієнтовано на послідовне проходження
Програмна інженерія – прикладні методи
57
етапів специфікації, проєктування, реалі-
зації, верифікації та валідації, то подаль-
ший розвиток підходів пов’язаний із пере-
ходом до більш гнучких ітеративних схем,
які скорочують цикл зворотного зв’язку
між розробленням, інтеграцією та тесту-
ванням.
Для сфери конструювання ВС така
трансформація має особливе значення,
оскільки програмні компоненти розробля-
ють у тісному зв’язку з апаратним середо-
вищем, обмеженнями цільової платформи
та вимогами до функціональної безпеки й
кібербезпеки.
Розвиток V-моделі до гнучких ме-
толологій (Agile) і далі до Embedded
DevSecOps відображає перехід від перева-
жно послідовного та документно-
орієнтованого підходу до безперервного,
автоматизованого й ризик-орієнтованого
керування ЖЦ ВС і СПЗ ВС. Якщо V-
модель забезпечує високу формалізацію та
простежуваність, то Agile підвищує адап-
тивність до змін, а Embedded DevSecOps
поєднує гнучкість із безперервною інтег-
рацією, тестуванням, контролем безпеки та
відповідності вимогам.
Таблиця 2.
Еволюція моделей ЖЦ СПЗ ВС
Модель Ключова особ-
ливість Вимоги Інтеграція Тестування
СПЗ ВС Безпека
V-модель Послідовний, фазо-
вий підхід
Фіксуються на
початку
Переважно
пізня
За рівнями верифі-
кації та валідації
Окремий на-
прям робіт
Agile
Ітеративний та
інкрементальний
підхід
Уточнюються
впродовж розроб-
лення
Регулярна,
поетапна
У межах ітерацій, з
автоматизацією
Враховується в
процесі
Embedded
DevSecTestOps
Безперервний,
автоматизований
підхід
Динамічне керу-
вання і простежу-
ваність
Безперервна
(CI/CD/CT)
Безперервне, авто-
матизоване, бага-
торівневе
Інтегрована в
повний цикл
розробки
2. Актуальні методології
конструювання СПЗ ВС
Одним із підходів до конструюван-
ня СПЗ ВС є адаптація принципів
об’єктно-орієнтованого програмування до
процедурної мови C. У цьому випадку ін-
капсуляція, композиція, обмежений полі-
морфізм та інші ООП-конструкції реалі-
зують через структури даних, вказівники
на функції, явні інтерфейси та усталені
шаблони виклику. Такий підхід застосо-
вують, коли необхідно забезпечити моду-
льну організацію коду, повторне викорис-
тання компонентів і формалізовану взає-
модію між ними без переходу до повно-
цінного C++. У конструюванні СПЗ ВС це
пов’язано з вимогами до їхнього функціо-
нування й сумісності з ресурсними обме-
женнями цільових платформ.
Подальший розвиток методологій
конструювання СПЗ ВС пов’язаний із пе-
ренесенням акценту з побудови структури
коду на керування процесом його поетап-
ного формування. У [3] підхід Test-Driven
Development (TDD) визначено як методо-
логію, де реалізацію функціональності
здійснюють через послідовність форму-
вання тестів, написання мінімально необ-
хідного коду та подальший рефакторинг.
За такого підходу тестування розглядають
не як завершальний етап перевіряння, а як
складову процесу конструювання програ-
мної архітектури. Для ВС це означає мож-
ливість раннього виявлення дефектів, зни-
ження складності налагодження та підви-
щення керованості змін у програмних
компонентах.
У контексті СПЗ ВС TDD адапту-
ють до апаратно-залежного середовища за
Програмна інженерія – прикладні методи
58
рахунок подвійно таргетованого тестуван-
ня (dual-target testing), ізоляції залежностей
від апаратної частини й операційної сис-
теми, а також використання тестових двій-
ників (test doubles), зокрема, підробок
(fakes), шпигунів (spies), імітацій (mocks).
Це дає змогу перевіряти логіку модулів
поза цільовою платформою, виконувати
поетапне нарощування функціональності
та підтримувати рефакторинг без безпосе-
редньої залежності від наявності апаратно-
го середовища. Таким чином, TDD у стру-
ктурі сучасних методологій конструюван-
ня СПЗ ВС пов’язують з ітеративною роз-
робкою, автоматизованим модульним тес-
туванням і поетапним формуванням архі-
тектури СПЗ ВС.
Поряд із TDD у створенні ВС засто-
совують гнучкі (agile) методи розроблення,
зорієнтовані на ітеративність, інкремент-
ність і скорочення циклу зворотного
зв’язку [7]. У межах такого підходу вимоги
організують у журнал завдань (backlog),
розробку виконують короткими ітерація-
ми, а перевіряння ухвалених рішень інтег-
рують у поточний процес робіт. Для ВС це
пов’язано з тим, що програмні складники
зазвичай уточнюють одночасно з апарат-
ною платформою, тому жорстко послідов-
ні моделі не завжди забезпечують належну
узгодженість між етапами розроблення.
Разом із тим у сфері СПЗ ВС agile-
підходи зазвичай налаштовують з ураху-
ванням вимог реального часу, апаратно-
програмної розробки, обмеженості обчис-
лювальних ресурсів і необхідності випро-
бувань на обладнанні. На практиці це реа-
лізують за рахунок окремих елементів,
зокрема, коротких циклів планування, час-
тішої інтеграції, раннього тестування та
інтенсивної командної взаємодії. У такому
трактуванні гнучкі методи розглядають як
процесне підґрунтя для підвищення узго-
дженості між розробленням, інтеграцією
та перевіркою програмних компонентів.
Іншим напрямом розвитку методо-
логій конструювання СПЗ ВС є перене-
сення основного акценту з вихідного коду
на модель системи. Model-based
Development (MBD) [8, 9] визначають як
підхід, де основним артефактом є модель,
що описує структуру, поведінку, часові
характеристики та взаємодію системи із
зовнішнім середовищем. У межах цього
підходу виконують моделювання, верифі-
каці. та раннє тестування до завершення
реалізації на цільовій платформі. Надалі
модель уточнюють до рівня, на якому мо-
жливе автоматизоване генерування про-
грамного коду або інших реалізаційних
артефактів.
Для ВС MBD пов’язано з інтеграці-
єю етапів формування вимог, проєктування,
тестування та реалізації в межах єдиного
модельного подання. Застосування моделі
як основного джерела опису системи забез-
печує трасування вимог, повторне викорис-
тання компонентів, аналіз поведінки та уз-
годження програмної й апаратної частин.
Такий підхід застосовується під час розро-
блення складних кіберфізичних і багатодо-
менних систем, у яких поєднуються алго-
ритмічний опис, часовий аналіз, симуляція
та автоматизоване генерування коду.
Наступний етап еволюції методоло-
гій конструювання СПЗ ВС пов’язаний з
інтеграцією процесів розроблення, тесту-
вання, постачання та гарантування безпеки
в межах безперервного циклу Embedded
DevSecOps [3, 6], насамперед у конструю-
ванні СПЗ ВС мовою C. Його поширення
зумовлене апаратними обмеженнями ці-
льових платформ, тривалим ЖЦ ВС, вимо-
гами до надійності функціонування та не-
обхідністю контролювання ризиків на піз-
ніх етапах впровадження ВС.
В [1] сучасне проєктування ВПЗ ро-
зглянуто через архітектуру програмного
забезпечення, процеси Agile і DevOps, а
також практики розроблення. До складу
відповідних інженерних практик віднесено
проєктування безпечних застосунків, ста-
тичний аналіз, перевірка коду (code
review), оцінювання покриття коду та ви-
користання CI/CD. У цьому контексті
Embedded DevSecOps розглядають як про-
цесну основу для інтеграції вимог безпеки
та якості до повного циклу розроблення
СПЗ ВС мовою C.
Окреме місце серед актуальних під-
ходів займає фреймворк-орієнтоване роз-
роблення СПЗ ВС на основі C++ і Qt. У
цьому випадку C++ застосовують для реа-
лізації прикладної логіки, системних серві-
Програмна інженерія – прикладні методи
59
сів і обчислювальних компонентів, тоді як
комерційний фрейморк Qt забезпечує за-
соби конструювання інтерфейсу (насампе-
ред Qt Quick і QML) організації взаємодії
між програмними модулями (механізм
signals and slots), оброблення подій і дося-
гнення переносності між апаратно-
програмними платформами. Такий підхід
застосовують, зокрема, для ВС на базі вбу-
дованої ОС Linux, де поєднують вимоги до
продуктивності, модульної організації та
супроводження СПЗ ВС. Тоді C++ і Qt
становлять інструментальну основу для
створення модульного та переносного СПЗ
ВС, зокрема панелей керування, людино-
машинних інтерфейсів та інших пристроїв
із розвиненою візуальною складовою.
Актуальні методології конструю-
вання СПЗ ВС охоплюють як підходи до
структурної організації програмного коду,
так і процесні, модельні та фреймворк-
орієнтовані засоби розроблення. Їх засто-
суванню притаманне поєднання вимог до
надійності, передбачуваності виконання,
інтеграції з апаратною платформою, тесто-
вності, безпеки та супроводженості
СПЗ ВС.
У практиці Embedded DevSecOps
безперервне тестування доцільно запрова-
джувати як багаторівневу систему переві-
рок, де окремі завдання можуть бути вико-
нані послідовно або паралельно залежно від
їхнього призначення та вартості виконання.
До такої системи зазвичай належать авто-
матизоване збирання, версії СПЗ, модульне
тестування, аналіз якості коду, перевірка
залежностей, тестування інтеграції компо-
нентів, а також спеціалізовані безпекові
процедури, що доповнюють класичний
CI/CD-конвеєр. Важливо, що результати
кожного запуску накопичують фактичні
дані про тривалість, успішність і чутливість
тестових процедур, які стають підґрунтям
для подальшої оптимізації CI/CD-конвеєра,
раціонального розподілу тестових завдань і
підвищення відтворюваності контролю
якості. Таким чином, безперервне тесту-
вання в Embedded DevSecOps (рис. 5) слу-
гує не лише засобом оперативного вияв-
лення помилок, а й механізмом системного
керування якістю, зокрема, та безпекою
СПЗ ВС протягом усього ЖЦ ВС [6].
Рис. 5. Позиція безперервного тестування
СПЗ ВС в Embedded DevSecOps
3. Особливості рівнів і видів тес-
тування СПЗ ВС
Позиція тестування СПЗ ВС у
життєвому циклі ВС. Рівні та види тесту-
вання спеціалізованого програмного забез-
печення вбудованих систем доцільно розг-
лядати як загальну методичну основу, ус-
падковану від усталених практик тестуван-
ня програмного забезпечення. У цьому під-
ході рівні тестування охоплюють компоне-
нтний, інтеграційний, системний і прийма-
льний рівні, тоді як види тестування опи-
сують аспект перевірки, зокрема, функцій-
ну та нефункційну відповідність. Однак для
СПЗ ВС ця класифікація набуває приклад-
ної специфіки: об’єкт тестування має бути
оцінено не лише як програмний код, а й як
складник програмно-апаратної системи,
який функціонує у взаємодії з процесором,
шинами обміну, сенсорами, виконавчими
механізмами та часовими обмеженнями.
Тому для СПЗ ВС тестові рівні фактично
відображають не лише їхню логічну деком-
позицію, а й ступінь наближення тестового
оточення до реального середовища функці-
онування СПЗ.
Саме з цієї причини в ЖЦ ВС широ-
ко застосовують сімейство конфігурацій X-
in-the-Loop (XiL) [4] як предметно-
орієнтоване уточнення класичних рівнів
тестування [5]. На ранніх етапах застосо-
вують Model-in-the-Loop (MiL), де верифі-
кують алгоритми та керувальну логіку на
рівні моделей без реального апаратного
виконання. Далі Software-in-the-Loop (SiL)
дає змогу перевіряти згенерований або реа-
лізований програмний код у середовищі
розроблення, зіставляючи його поведінку з
моделлю. Processor-in-the-Loop (PiL) пере-
носить перевірку на цільовий процесор або
його еквівалентний симулятор, що важливо
для виявлення ефектів, пов’язаних із компі-
Програмна інженерія – прикладні методи
60
лятором, архітектурою процесора та часо-
вими характеристиками виконання. Насту-
пний етап Hardware-in-the-Loop (HiL), пе-
редбачає підключення реального контроле-
ра до моделі фізичного об’єкта, що викону-
ється в реальному часі, і тому є ключовим
засобом перевірки інтеграції програмної та
апаратної частин. Таким чином, XiL-
послідовність конкретизує, як саме класич-
ні рівні тестування реалізуються в контекс-
ті СПЗ вбудованих систем.
Для складних кіберфізичних ВС
(транспортних тощо) цю послідовність до-
повнюють конфігурації Driver-in-the-Loop
(DiL) та Vehicle-in-the-Loop (ViL). У галузі
автоматизованих транспортних засобів DiL-
тестування зазвичай означає включення
людини-оператора або водія до замкнутого
контуру тестування, коли вже поведінку ВС
загалом оцінюють не лише за формальними
критеріями, а й з урахуванням реакції лю-
дини на сценарії керування, інтерфейси та
динаміку об’єкта. VIL із свого боку поєднує
реальний транспортний засіб із віртуальним
середовищем. Його застосовують для
зближення полігонних і віртуальних випро-
бувань. У результаті конфігурації MiL, SiL,
PiL, HiL, DiL і ViL слід трактувати не як
альтернативу традиційним рівням тесту-
вання, а як ієрархію середовищ для переві-
рки, у межах якої послідовно зростає реа-
лізм відтворення умов експлуатації і, відпо-
відно, достовірність оцінювання властивос-
тей СПЗ ВС. У цьому контексті концепція
зсуву ліворуч (рис. 6) означає перенесення
дій з тестування на максимально ранні ста-
дії ЖЦ СПЗ, коли ще можна дешево усуну-
ти дефекти вимог, архітектури, моделей і
програмної логіки.
Рис. 6. Концепція зсуву ліворуч і зсуву
праворуч у процесі тестування СПЗ ВС
Для СПЗ ВС це охоплює ранню ве-
рифікацію вимог, аналіз архітектурних
рішень, MiL-перевірки, статичний аналіз,
модульне тестування, а також SiL і PiL
тестування до повної інтеграції з апарат-
ними засобами. Натомість зсув праворуч
акцентує потребу у продовженні переві-
рянь після інтеграції та розгортання, коли
СПЗ ВС і ВС загалом демонструють свої
критичні властивості вже в реальних або
наближених до реальних умовах експлуа-
тації. Для ВС це означає HiL, DiL, ViL тес-
тування, аналіз телеметрії, експлуатацій-
ний моніторинг, перевірка оновлень і дов-
готривалі випробування стабільності. От-
же, для СПЗ ВС зсув ліворуч і зсув право-
руч доцільно розглядати як взаємодопов-
нювальні кращі практики, а XiL-
конфігурації – як практичний механізм їх
реалізації в безперервному контурі гаран-
тування якості.
У контексті тестування СПЗ ВС до-
цільно розмежовувати стандартизовані
техніки проєктування тестів і підходи типу
чорної, білої та сірої скриньки. Згідно з
ДСТУ ISO/IEC/IEEE 29119-3, 29119-4, до
стандартизованих належать насамперед
специфікаційно-орієнтовані, структурно-
орієнтовані та досвідно-орієнтовані техні-
ки. Їх застосовують під час проєктування
та реалізації тестів на різних рівнях, зок-
рема, також і для СПЗ ВС з урахуванням
апаратних обмежень, часових вимог та
залежності від периферії.
Підходи фазингу [10, 11] та чорної
й білої скриньки описуть не стандартну
класифікацію технік тестування, а ступінь
доступу тестувальника до внутрішньої
структури об’єкта тестування: від перевір-
ки лише зовнішньої поведінки до аналізу
внутрішніх структур, покриття коду та
проміжного комбінованого варіанта.
Серед цих технік фазинг слід розг-
лядати як окрему спеціалізовану техніку
динамічного автоматизованого тестування,
а не як самостійний «рівень» тестування.
Його сутність полягає в масованому по-
данні на вхід програми випадкових, спеці-
альним чином модифікованих або цілесп-
рямовано згенерованих даних для вияв-
лення аварійних завершень, порушень ро-
боти з пам’яттю та інших дефектів. У най-
Програмна інженерія – прикладні методи
61
простішому вигляді фазинг тяжіє до моде-
лі чорної скриньки, але сучасні варіанти,
зокрема, керований покриттям (coverage-
guided) фазинг [10], фактично наближають
його до сірої скриньки, оскільки передба-
чають внутрішній зворотний зв’язок щодо
виконання СПЗ для спрямування генерації
нових тестів. Для СПЗ ВС така техніка є
особливо цінною, але водночас складною
через тісну прив’язку СПЗ до регістрів,
переривань і периферійних інтерфейсів.
У сучасних практиках тестування
СПЗ ВС їх фазинг поєднують з емуляцією
та автоматичним моделюванням периферії.
У [12] прямо зазначено, що динамічне тес-
тування та фазинг СПЗ ВС істотно обме-
жені апаратними залежностями й низькою
масштабованістю, хоча запропонований
авторами підхід дає змогу тестувати
firmware у більш апаратно-незалежний
спосіб.
Перспективні підходи до органі-
зації тестування СПЗ ВС. У практиці ро-
зроблення й тестування СПЗ ВС сформу-
валося кілька стійких центрів компетенцій,
кожен з яких охоплює окремий клас ін-
струментів, платформ і послуг, пов’язаних
із забезпеченням якості, верифікацією та
випробуванням.
Статичний аналіз і якість коду
(Parasoft, IAR, MathWorks, Synopsys / Black
Duck (Coverity)). Засоби цього напряму
застосовують для тестування коду СПЗ без
їх виконання, виявлення дефектів, потен-
ційно небезпечних конструкцій, порушень
стандартів програмування та підтверджен-
ня відповідності вимогам до надійності й
безпеки.
HIL і випробувальні стенди
(dSPACE, National Instruments). Компанії
цього сегменту спеціалізуються на побу-
дові апаратно-програмних стендів для ви-
пробувань у реальному часі, моделюванні
середовищ функціонування та інтеграції
програмних компонентів із реальними ко-
нтролерами, платами й периферією.
Фазинг (Code Intelligence,
Defensics). Методи та засоби цього класу
зорієнтовано на автоматизоване форму-
вання великої кількості некоректних, гра-
ничних або несподіваних вхідних даних з
метою виявлення відмов і вразливостей
СПЗ ВС.
Новітні підходи: цифрові двійни-
ки та агентний штучний інтелект
Перспективним напрямом розвитку
тестування СПЗ ВС є використання циф-
рових двійників як основи безперервного
тестування. Цифровий двійник доцільно
розглядати як виконувану модель СПЗ ВС
та їх середовища, узгоджену з реальною
конфігурацією за параметрами, інтерфей-
сами й сценаріями функціонування. Такий
підхід дає змогу перенести значну частину
регресійних тестів до автоматизованих
конфігурацій із залученням реальних при-
строїв. Практична реалізація зазвичай охо-
плює моделі середовища, бібліотеки
(не)штатних і граничних сценаріїв, авто-
матизоване виконання в CI/CD-конвеєрі, а
також валідування самого двійника шля-
хом калібрування та підтвердження при-
йнятної точності моделі.
Іншим новітнім підходом є застосу-
вання агентного штучного інтелекту для
підтримки процесів тестування. Тоді аген-
тний штучний інтелект виконує допоміжні
функції в задачах, які складно масштабу-
вати вручну: генерування тестових загото-
вок на основі вимог та інтерфейсів, адап-
тацію тестів у разі зміни конфігурацій і
варіантів СПЗ ВС, аналіз журналів і логів
виконання, а також добір сценаріїв для
розширення покриття. Доцільним є також
його застосування для поглиблення тесту-
вання безпеки, зокрема, під час підготу-
вання фазингу. Водночас у критичних і
регульованих предметних областях такий
підхід має бути застосований лише за умо-
ви контролю результатів, коли артефакти
проходять формалізовані процедури пере-
вірки, аналізу та аудиту з боку експерта в
предметній області.
Перспективним є поєднання цифро-
вого двійника з агентним штучним інтеле-
ктом в об’єднаному xiL-контурі безперер-
вного тестування СПЗ. Тоді агент із функ-
ціями штучного інтелекту відбирає або, за
потреби, формує релевантні сценарії, іні-
ціює їх виконання на цифровому двійнику,
узагальнює результати прогонів, готує
Програмна інженерія – прикладні методи
62
описи дефектів і підтримує актуальність
тестового набору під час еволюції СПЗ ВC.
4. Авторський підхід до
опрацювання проблем тестування
СПЗ ВС
Зіставлення проаналізованих вище
особливостей СПЗ ВС і процесу безперер-
вного тестування СПЗ у SiL-конфігурації
Embedded DevSeсOps дозволяє уточнити
проблеми ефективної організації цього
процесу [13] на підтримку його додатко-
вих функцій а)-в), зафіксованих у Вступі
статті:
– ефективне керування артефактами
тестування СПЗ, зокрема їх адмініструван-
ня й контрольоване повторне використан-
ня як у межах окремих циклів DevSecOps,
так і між ними (P1);
– забезпечення повноаспектного
наскрізного простежування між самими
артефактами тестування та між ними й
іншими артефактами DevSecOps (P2);
– адаптування перспективних про-
цесів і технік динамічного тестування, рег-
ламентованих ДСТУ ISO/IEC/IEEE 29119-
3, 29119-4, з урахуванням ускладнюючих
особливостей СПЗ ВС (P3);
– своєчасне ґрунтовне відстеження
якості СПЗ ВС, насамперед кібер- і функ-
ціональної безпеки, прийнятної для пода-
льшого тестування СПЗ на цільових плат-
формах у конфігураціях PiL, HiL, ViL, DiL,
її гарантування й засвідчення (P4);
– ефективне розподілення й конт-
ролювання відповідальності й повнова-
жень між різними командами в Embedded
DevSeсOps: конструювання, тестування,
інформаційної безпеки, операційного пер-
соналу (P5);
– постійне (не)кількісне оцінювання
рівня зрілості процесу безперервного тес-
тування СПЗ і здобуття інформації щодо
його вдосконалення (P6).
Авторський підхід до опрацювання
проблем P1-P6 поєднує:
а) конструктивну постановку спіль-
ної для P1-P6 технічної задачі, а саме: роз-
роблення моделей і методів ефективного
розгортання й використання безпечного
конвеєра безперервного автоматизованого
тестування СПЗ ВС у siL-конфігурації в
Embedded DevSecOps для диверсифікова-
ного конструювання мінливих СПЗ ВС;
б) засади розв’язання цієї задачі, пі-
дсумовані положеннями B1–B7;
в) першочергові кроки з реалізації
підходу S1.–S7.
Запропоновані засади та кроки під-
сумовано в таблиці 3.
Таблиця 3.
Сутність авторського підходу до опрацювання проблем тестування СПЗ мінливих ВС
Засади підходу Кроки реалізації засад
Організація конвеєра (pipeline) безперервного автома-
тизованого тестування СПЗ ВС у TDD-стилі [3] як
підґрунтя для ефективного CI/CD конвеєра розгор-
тання СПЗ в DevSecOps (B1)
Побудова моделі властивостей (віртуальної) лінійки
СПЗ мінливих ВС шляхом виокремлення в CI/CD кон-
веєрі конструювання СПЗ обов’язкових фрагментів,
спільних для всіх СПЗ, і, відповідно, опціональних,
властивих лише окремим СПЗ (S1)
Формалізація обох конвеєрів у парадигмі лінійки
програмних продуктів (Software Product line) згідно з
ISO/IEC 26554 (для цільової Лінійки тестів мінливих
СПЗ) і ДСТУ ISO/IEC 26550 (як (віртуальної) лінійки
самих СПЗ) (B2)
Побудова на підставі отриманої моделі властивостей
технологічної моделі процесу автоматизованого тесту-
вання СПЗ як процесу розгортання й використання
Лінійки їх тестів , а саме вкладених моделей конвеєрів
тестування домену й застосунків та їх інфраструктури,
згідно із засадами [13] і B1, B2 (S2)
Декларативне моделювання процесів тестування
домену та застосунків у парадигмі Pipeline as a Code
[14] як часткових конвеєрів, вкладених до формованої
Лінійки тестів, а інфраструктури тестування СПЗ – у
Налаштування традиційних технік тестування коду на
рівнях від модульного до системного для СПЗ ВС та їх
інтеграція з техніками поглибленого статичного аналізу
[6] і фазингу [10,11] у модельованих вкладених кон-
Програмна інженерія – прикладні методи
63
Засади підходу Кроки реалізації засад
парадигмі Infrastructure as a Code [15] (B3) веєрах тестування домену й застосунків (S3)
Декларативне моделювання процесів розгортання та
адміністрування інфраструктури Лінійки тестів у
руслі підходів GitOps [16] і QAOps [5, 6] для адекват-
ного розподілу відповідальностей і взаємної довіри
різних команд в Embedded DevSecOps (B4)
Розроблення методів ситуативного вибору оптимально-
го інструмента, переважно з відкритим кодом, для
основних видів статичного й динамічного тестування в
модельованих конвеєрах рівня домену й застосунків
(S4) згідно з [17]
Застосування інструментальних засобів з відкритим
кодом для декларативного конфігураційного керуван-
ня автоматизованими конвеєрами Лінійки тестів та їх
інфраструктурою (B5)
Формування повної й ненадлишкової системи метрик
якості запропонованої Лінійки тестів та розроблення
процедур виявлення її неприйнятного зниження на їх
підставі (S5)
Забезпечення автоматизованого виявлення, у формо-
ваних конвеєрах Лінійки тестів, порушень відповідно-
сті тестованого СПЗ релевантним міжнародним і
галузевим стандартам, насамперед щодо кібер- та
інформаційної безпеки (B6)
Аналіз ефективності інструментів з відкритим кодом
для декларативного керування конвеєрами та інфра-
структурою як кодом, де-факто стандартизованих під-
ходами GitOps і QAOps, і визначення їх рамкового
переліку для розгортання й використання запропонова-
ної Лінійки тестів (S6)
Безперервне відстеження якості запропонованої Лі-
нійки тестів із вчасним виявленням її неприпустимого
зниження та можливостей і способів удосконалення
Лінійки (B7)
Розроблення макетного зразка інструментального засо-
бу вибору оптимального інструмента для певного виду
тестування за допомогою методів кроку S4, його інтег-
рація до процесів запропонованої Лінійки тестів разом
із вибраними засобами з кроку S6 та апробація отрима-
ного рішення у вітчизняній організації-розробнику
мінливих СПЗ ВС (S7)
Реалізація й ситуативне уточнення
кроків S1.–S7 є предметом подальших до-
сліджень авторів.
Висновки
Запропоновано линійку тестів згід-
но зі стандартом ISO/IEC 26554 практи-
ками QAOps для відокремленого тестуван-
ня СПЗ ВС на рівнях від модульного до
системного, де емуляцію замінено на ви-
користання тестових двійників (mocks,
SiL) для модулів СП3 і положеннями спе-
цифікації вимог до СПЗ.
Література
1. Beningo J. Embedded software design: A
practical approach to architecture, processes,
and coding techniques. Apress, 2022.
2. Lacamera D. Embedded systems architecture:
Design and write software for embedded
devices to build safe and connected systems.
2nd ed. Packt Publishing, 2023.
3. Grenning J.W. Test-Driven Development for
Embedded C. Pragmatic Bookshelf, 2011.
4. Association for Standartization of Automation
and Measuring Systems (ASAM). Generic
Simulator Interface. Specification. Part 1,
2024. – 396 p.
5. Clokie К. A practical guide to Testing in
DevOps – Leanpub, 2017. – 128 p.
6. Hornbeek M., Wakeman D. Continuous
Testing, Quality, Security, and Feedback:
Essential strategies and secure practices for
DevOps, DevSecOps, and SRE
transformations – Packt Publishing, Limited,
2024. – 420 p/
7. Salo O., Abrahamsson P. Agile methods in
European embedded software development
organisations: A survey on the actual use and
usefulness of Extreme Programming and
Scrum. IET Software. 2008. Vol. 2. No 1. P.
58–64.
8. Böhm W. et al. (Eds.): Model-Based
Engineering of Collaborative Embedded
Systems. ISBN 978-3-030-62135-3. Springer,
Jan. 2021 – 358 p.
9. Nicolescu G., Mosterman P.J. (eds.). Model-
Based Design for Embedded Systems. CRC
Press, 2009.
10. Yun J., Lee I., Xu M., Kim T. Fuzzing of
embedded systems: A survey. ACM
Програмна інженерія – прикладні методи
64
Computing Surveys. 2022. Vol. 55. No 7.
Article 132. P. 1–33.
11. Eisele M., Ebert D., Huth C., Zeller A.
Fuzzing embedded systems using debug
interfaces. Proceedings of the 32nd ACM
SIGSOFT International Symposium on
Software Testing and Analysis (ISSTA ’23).
2023. P. 1031–1042.
12. Feng B., Mera A., Lu L. P²IM: Scalable and
hardware-independent firmware testing via
automatic peripheral interface modeling. 29th
USENIX Security Symposium (USENIX
Security 20). 2020. P. 1237–1254.
13. Ierofeiev I., Sinitsyn I., Slabospitska O.
Embedded Software Testing Issues and
Addressing Them with Software Product
Lines Paradigm. CEUR Workshop
Proceedings. 2024. Vol. 4053. P. 13–23.
14. Soni M. Hands-on Pipeline as YAML with
Jenkins: A Beginner's Guide to Implement
CI/CD Pipelines for Mobile, Hybrid, and Web
Applications Using Jenkins BPB Publications,
2021 – 320 p.
15. Wang R.Infrastructure as Code, Patterns and
Practices. With examples in Python and
Terraform – Manning, 2022. – 400 p.
16. Salecha R. Practical GitOps : Infrastructure
Management Using Terraform, AWS, and
GitHub Actions – Apress L. P., 1st ed., 2022
–270 p.
17. Єрофеєв Ю.В., Слабоспицька О.О.
Embedded DevSecOps у хмарі: засоби та
перспективи оптимізації. Proc. of the XVIII
Int. scientific and practical conf. «Information
technologies and automation–2025». 2025 –
P. 837.
References
1. Beningo J. Embedded software design: A
practical approach to architecture, processes,
and coding techniques. Apress, 2022.
2. Lacamera D. Embedded systems architecture:
Design and write software for embedded
devices to build safe and connected systems.
2nd ed. Packt Publishing, 2023.
3. Grenning J.W. Test-Driven Development for
Embedded C. Pragmatic Bookshelf, 2011.
4. Association for Standartization of Automation
and Measuring Systems (ASAM). Generic
Simulator Interface. Specification. Part 1,
2024. – 396 p.
5. Clokie К. A practical guide to Testing in
DevOps – Leanpub, 2017. – 128 p.
6. Hornbeek M., Wakeman D. Continuous
Testing, Quality, Security, and Feedback:
Essential strategies and secure practices for
DevOps, DevSecOps, and SRE
transformations – Packt Publishing, Limited,
2024. – 420 p/
7. Salo O., Abrahamsson P. Agile methods in
European embedded software development
organisations: A survey on the actual use and
usefulness of Extreme Programming and
Scrum. IET Software. 2008. Vol. 2. No 1. P.
58–64.
8. Böhm W. et al. (Eds.): Model-Based
Engineering of Collaborative Embedded
Systems. ISBN 978-3-030-62135-3. Springer,
Jan. 2021 – 358 p.
9. Nicolescu G., Mosterman P.J. (eds.). Model-
Based Design for Embedded Systems. CRC
Press, 2009.
10. Yun J., Lee I., Xu M., Kim T. Fuzzing of
embedded systems: A survey. ACM
Computing Surveys. 2022. Vol. 55. No 7.
Article 132. P. 1–33.
11. Eisele M., Ebert D., Huth C., Zeller A.
Fuzzing embedded systems using debug
interfaces. Proceedings of the 32nd ACM
SIGSOFT International Symposium on
Software Testing and Analysis (ISSTA ’23).
2023. P. 1031–1042.
12. Feng B., Mera A., Lu L. P²IM: Scalable and
hardware-independent firmware testing via
automatic peripheral interface modeling. 29th
USENIX Security Symposium (USENIX
Security 20). 2020. P. 1237–1254.
13. Ierofeiev I., Sinitsyn I., Slabospitska O.
Embedded Software Testing Issues and
Addressing Them with Software Product
Lines Paradigm. CEUR Workshop
Proceedings. 2024. Vol. 4053. P. 13–23.
14. Soni M. Hands-on Pipeline as YAML with
Jenkins: A Beginner's Guide to Implement
CI/CD Pipelines for Mobile, Hybrid, and Web
Applications Using Jenkins BPB Publications,
2021 – 320 p.
15. Wang R.Infrastructure as Code, Patterns and
Practices. With examples in Python and
Terraform – Manning, 2022. – 400 p.
16. Salecha R. Practical GitOps : Infrastructure
Management Using Terraform, AWS, and
GitHub Actions – Apress L. P., 1st ed., 2022
–270 p.
17. Ierofeiev I., Slabospitska O. Cloude
Embedded DevSecOps: Optimization Tools
and Perspectives. Proc. of the XVIII Int.
scientific and practical conf. «Information
technologies and automation–2025». 2025. –
P. 837.
Програмна інженерія – прикладні методи
65
Дата першого надходження до видання:
10.03.2026
Внутрішня рецензія отримана: 14.03.2026
Зовнішня рецензія отримана: 15.04.2026
Дата прийняття статті до друку: 19.03.2026
Дата публікації: 16.04.2026
Про авторів:
1Єрофеєв Юрій Володимирович,
аспірант ІПС НАНУ
Yerofieiev Yuriy,
Post-graduate student
http://orcid.org/0009-0006-8985-2729.
2Сініцин Ігор Петрович,
доктор технічних наук,
директор.
Sinitsyn Igor,
Ph.D (doctor, technical sciences),
director
http://orcid.org/0000-0002-4120-0784.
Місце робот авторів:
1Інститут програмних систем
НАН України
Institute of Software Systems
National Academy of Sciences of Ukraine
тел. +38-044-522-62-42
E-mail: www.iss.nas.gov.ua
|
| id | pp_isofts_kiev_ua-article-891 |
| institution | Problems in programming |
| keywords_txt_mv | keywords |
| language | Ukrainian |
| last_indexed | 2026-04-24T01:00:15Z |
| publishDate | 2026 |
| publisher | PROBLEMS IN PROGRAMMING |
| record_format | ojs |
| resource_txt_mv | ppisoftskievua/aa/429863a937a4bfc5d097ab3043ce81aa.pdf |
| spelling | pp_isofts_kiev_ua-article-8912026-04-23T22:26:13Z The problems of embedded systems special software effective testing and their elaboration Проблеми ефективного тестування спеціальних програмних засобів вбудованих систем та їх опрацювання Yerofieiev, Yu.V. Sinitsyn, I.P. embedded system; special software; testing; reuse; software product line; continuous integration; continuous testing; life cycle; software architecture; configuration management UDC 004.41:004.05 вбудована система; спеціальні програмні засоби; тестування; повторне використання; лінійка програмних продуктів; безперервна інтеграція; безперервне тестування; життєвий цикл; програмна архітектура; керування конфігурацією УДК 004.41:004.05 The paper examines the problem of sustainable testing of special software for embedded systems under conditions of rapid hardware evolution, configuration variability, and shortened update cycles. It shows that modern embedded products are characterized by a partial separation of hardware and software life cycles, a growing role of controlled firmware updates, component reuse, and the integration of computer vision and artificial intelligence algorithms. It is substantiated that, in such conditions, testing should not be limited to defect detection, but should also support quality forecasting, integration decisions, and the accumulation of reusable testing assets. The study summarizes typical embedded-system architectures and approaches to constructing special software, including layered and microservice-oriented architectures, test-driven development, agile methods, model-based development, and continuous integration, continuous testing, quality assurance, and security practices. The role of XiL approaches, configuration management, and artifact traceability in ensuring environment reproducibility is highlighted. Sustainable reuse of testing work products within the software product line paradigm is proposed as a basis for increasing the maturity of development and testing processes for special embedded software.Problems in programming 2026; 1: 51-65 Розглянуто проблему результативного й ресурсно ефективного тестування спеціальних програмних за собів (СПЗ) вбудованих систем (ВС) в умовах істотної різнорідності й швидкої еволюції апаратних платформ, мінливості конфігурацій і скорочення циклів еволюції СПЗ. Показано, що для сучасних вбу дованих виробів характерні часткова незалежність життєвих циклів апаратної та програмної складових і зростання ролі керованої модернізованості СПЗ ВС. Обґрунтовано потребу в таких умовах не лише виявлення дефектів, а й додаткових функцій тестування: прогнозування (не)задовільної якості СПЗ і ВС загалом, підтримку рішень щодо інтеграції СПЗ і накопичення повторно використовуваних тесто вих активів. Узагальнено особливості типових архітектур ВС і підходів до конструювання СПЗ ВС, значущі для забезпечення вищезазначених додаткових функцій тестування, зокрема, рамкову та мікро сервісну архітектури, розроблення, кероване тестами, гнучкі методології, розроблення на основі моде лей, а також підходи безперервної інтеграції й безперервного тестування. Показано роль XiL-підходів, керування конфігураціями та контролювання зв’язків між артефактами для забезпечення відтворюва ності середовища тестування. Запропоновано розглядати стале повторне використання робочих проду ктів тестування в руслі парадигми лінійок програмних продуктів як основу для сталого підвищення зрі лості процесів тестування СПЗ ВС та їх конструювання загалом.Problems in programming 2026; 1: 51-65 PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2026-04-23 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/891 PROBLEMS IN PROGRAMMING; No 1 (2026); 51-65 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 1 (2026); 51-65 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 1 (2026); 51-65 1727-4907 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/891/944 Copyright (c) 2026 PROBLEMS IN PROGRAMMING |
| spellingShingle | embedded system special software testing reuse software product line continuous integration continuous testing life cycle software architecture configuration management UDC 004.41:004.05 Yerofieiev, Yu.V. Sinitsyn, I.P. The problems of embedded systems special software effective testing and their elaboration |
| title | The problems of embedded systems special software effective testing and their elaboration |
| title_alt | Проблеми ефективного тестування спеціальних програмних засобів вбудованих систем та їх опрацювання |
| title_full | The problems of embedded systems special software effective testing and their elaboration |
| title_fullStr | The problems of embedded systems special software effective testing and their elaboration |
| title_full_unstemmed | The problems of embedded systems special software effective testing and their elaboration |
| title_short | The problems of embedded systems special software effective testing and their elaboration |
| title_sort | problems of embedded systems special software effective testing and their elaboration |
| topic | embedded system special software testing reuse software product line continuous integration continuous testing life cycle software architecture configuration management UDC 004.41:004.05 |
| topic_facet | embedded system special software testing reuse software product line continuous integration continuous testing life cycle software architecture configuration management UDC 004.41:004.05 вбудована система спеціальні програмні засоби тестування повторне використання лінійка програмних продуктів безперервна інтеграція безперервне тестування життєвий цикл програмна архітектура керування конфігурацією УДК 004.41:004.05 |
| url | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/891 |
| work_keys_str_mv | AT yerofieievyuv theproblemsofembeddedsystemsspecialsoftwareeffectivetestingandtheirelaboration AT sinitsynip theproblemsofembeddedsystemsspecialsoftwareeffectivetestingandtheirelaboration AT yerofieievyuv problemiefektivnogotestuvannâspecíalʹnihprogramnihzasobívvbudovanihsistemtaíhopracûvannâ AT sinitsynip problemiefektivnogotestuvannâspecíalʹnihprogramnihzasobívvbudovanihsistemtaíhopracûvannâ AT yerofieievyuv problemsofembeddedsystemsspecialsoftwareeffectivetestingandtheirelaboration AT sinitsynip problemsofembeddedsystemsspecialsoftwareeffectivetestingandtheirelaboration |