Дослідження автоматизації проектування вбудованих систем

Кльоц, Артем Андрійович

Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/6419

Title:	Дослідження автоматизації проектування вбудованих систем
Authors:	Міценко, Сергій Анатолійович Кльоц, Артем Андрійович
Issue Date:	Jan-2025
Abstract:	У дослідженні представлено комплексне розв'язання актуальної проблеми вдосконалення процесів автоматизованого проектування вбудованих систем через впровадження інноваційних технологій. Сучасні тенденції розвитку технологічних галузей висувають дедалі складніші вимоги до проектування складних технічних систем, що зумовлює необхідність розроблення принципово нових підходів до оптимізації проектувальних процесів. Основна мета роботи полягала в грунтовній трансформації традиційних методик автоматизованого проектування шляхом радикального скорочення термінів розробки, мінімізації фінансових витрат та суттєвого підвищення рівня автоматизації проектувальних робіт. Дослідження спрямовано на подолання низки системних обмежень існуючих методологій проектування, які стримують інноваційний розвиток вітчизняного технологічного сектору. Наукова новизна роботи знайшла відображення в удосконаленій моделі формування вимог, яка принципово відрізняється від існуючих підходів. Запропонована модель враховує складні структурні особливості вбудованих систем, забезпечуючи глибокий та всебічний аналіз вимог на різних етапах проектування. Особливістю розробленого методу є здатність розподіляти вимоги між апаратними та програмними компонентами з використанням інтелектуальних алгоритмів. Виключно важливим здобутком є розроблення методу формування рекомендацій щодо апаратно-програмних платформ на основі інтелектуальних знань. Запропонований підхід поєднує методи обмежень та подібності об'єктів, інтегрує складні багатокритеріальні методи аналізу, що дозволяє формувати обгрунтовані рекомендації навіть у разі наявності суперечливих вимог замовника. Практичні результати дослідження демонструють вагомі переваги запропонованого підходу. Апробація розробленого комплексу в умовах виробничих підприємств дозволила досягти відчутних покращень: скорочення витрат часу на розробку та підвищення продуктивності праці проектувальників. Загальна наукова цінність роботи полягає в комплексному технологічному рішенні, яке демонструє принципово новий підхід до підвищення ефективності автоматизованого проектування вбудованих систем через інтеграцію найсучасніших технологій. Запропоновані методологічні та технологічні рішення відкривають нові перспективи для вітчизняної інженерної науки, створюючи потужне підґрунтя для подальших досліджень та інновацій у галузі проектування складних технічних систем.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/6419
Appears in Collections:	174 Автоматизація, комп'ютерно-інтегровані технології та робототехніка (Автоматизація та комп'ютерно-інтегровані системи та компоненти)

Files in This Item:

File	Description	Size	Format
М_174_2024_Кльоц.pdf Restricted Access		3.71 MB	Adobe PDF	View/Open Request a copy

Show full item record

Extracted text

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОІЧНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ
КАФЕДРА РОБОТОТЕХНІКИ ТА СПЕЦІАЛІЗОВАНИХ КОМП’ЮТЕРНИХ СИСТЕМ

Пояснювальна записка
до кваліфікаційної роботи
освітнього ступеню «магістр»

на тему: ДОСЛІДЖЕННЯ АВТОМАТИЗАЦІЇ ПРОЕКТУВАННЯ
ВБУДОВАНИХ СИСТЕМ

Виконав: здобувач вищої освіти 2 курсу,
групи МАКІТ-2309
спеціальності 174 Автоматизація,
комп’ютерно-інтегровані технології та
робототехніка (освітня програма
«Автоматизація та комп’ютерно-
інтегровані системи та компоненти»)
Кльоц А.А.
(Прізвище ім’я по-батькові)

Керівник Міценко С.А.
(Прізвище ім’я по-батькові)

Рецензент
(Прізвище ім’я по-батькові)

Черкаси 2024 року
2
ЗМІСТ

ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ ........................................................................ 3
ВСТУП ......................................................................................................................... 4
РОЗДІЛ 1 АНАЛІЗ ПРОЦЕСІВ АВТОМАТИЗОВАНОГО ПРОЕКТУВАННЯ
ВБУДОВАНИХ СИСТЕМ.......................................................................................... 8
1.1 Роль та місце систем управління об’єктами у класифікації вбудованих
систем ....................................................................................................................... 8
1.2. Дослідження характеристик вбудованих систем та методів їх
впровадження......................................................................................................... 12
1.3. Дослідження підходів до проектування вбудованих систем ..................... 20
1.4. Дослідження вимог під час автоматизованого проектування вбудованих
систем ..................................................................................................................... 22
1.5. Програмні засоби автоматизації проектування вбудованих систем ......... 27
Висновки ................................................................................................................ 34
РОЗДІЛ 2 МОДЕЛЬ АВТОМАТИЗАЦІЇ ПРОЕКТУВАННЯ ВБУДОВАНИХ
СИСТЕМ ІЗ ВИКОРИСТАННЯМ ТЕХНОЛОГІЙ ВІДДАЛЕНОЇ ІНЖЕНЕРІЇ 36
2.1 Модель визначення вимог до вбудованої системи ...................................... 36
2.2. Спосіб роботи з вимогами ............................................................................. 38
2.3. Метод автоматизації проєктування вбудованих систем із застосуванням
технологій віддаленої інженерії .......................................................................... 41
2.4. Модель представлення інформації для апаратно-програмних платформ
рекомендаційних систем ...................................................................................... 46
Висновки ................................................................................................................ 52
РОЗДІЛ 3 ПРОГРАМНО-ТЕХНІЧНИЙ КОМПЛЕКС ДЛЯ АВТОМАТИЗАЦІЇ
ПРОЦЕСУ ПРОЕКТУВАННЯ ВБУДОВАНИХ СИСТЕМ .................................. 53
3.1. Формування рекомендацій для апаратно-програмних платформ ............. 53
3.2. Архітектура програмно-технічного комплексу .......................................... 57
3.3. Опис характеристик розробки програмно-технічного комплексу ............ 61
Висновки ................................................................................................................ 71
ВИСНОВКИ ............................................................................................................... 73
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ................................................................. 75
3
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ

API – Application program interface
ECAD – electronic computer-aided design (САПР електронних
пристроїв)
MCAD – mechanical computer aided design (САПР механічних
пристроїв)
АЗ – апаратне забезпечення
АПК – автоматизований програмний комплекс.
АСУ – автоматизована система управління.
БЗ – база знань
ВІ – віддалена інженерія
ВС – вбудована система
ЕКА – елементи конфігурації апаратури
ІКС – інтегрована комп'ютерна система.
КІТ – комплекс інженерних технологій.
МІП – модуль інтегрованого проектування.
МІС – мікроінженерні системи.
МК – мікроконтролер
ОД – обробка даних.
ПЛІС – програмована логічна інтегральна схема
ПЛК – програмований логічний контролер
ПТК – програмно-технічний комплекс
САПР – система автоматизованого проектування
ЦБК – центральний блок керування
4
ВСТУП

Актуальність теми дослідження. Сучасний ринок вбудованих систем
(ВС) характеризується стрімким розвитком та постійним ускладненням
технологічних рішень. У дослідженні розглядаються вбудовані системи
управління рухомими об'єктами, зокрема системи управління наземними
колісними рухомими об'єктами, які знаходять широке застосування в
різноманітних галузях: промисловості, транспорті, оборонній сфері, сільському
господарстві та розважальній індустрії. Автоматизоване проектування таких
систем вимагає комплексного підходу, що враховує специфіку апаратних та
програмних компонентів. Основні виклики включають необхідність дотримання
жорстких обмежень щодо технічних параметрів: розмірів, енергоспоживання,
завадостійкості та інших критичних характеристик.
Сучасні методології проектування, такі як паралельне проектування,
платформно-орієнтований підхід та методологія повторного використання
компонентів, покликані подолати традиційні обмеження класичних підходів до
розробки вбудованих систем. Особливої уваги заслуговують інноваційні
технологічні рішення, що дозволяють оптимізувати процеси проектування.
Принципово важливою проблемою є складність вибору апаратно-
програмних платформ через надзвичайно широкий спектр пропонованих
виробниками рішень. Провідні світові компанії, такі як Intel, Arduino, Raspberry,
Texas Instrument та STMicrocontroller, пропонують величезну кількість апаратно-
програмних платформ з різною функціональністю та ціновими
характеристиками. Для ефективного розв'язання проблеми вибору дослідники
запропонували використання рекомендаційних систем, побудованих на базі
інтелектуальних знань. Такі системи дозволяють розробникам здійснювати
обґрунтований вибір технологічних рішень, враховуючи специфічні вимоги
конкретного проекту. Додаткового розвитку набувають технології віддаленої
інженерії, які надають унікальну можливість спільного використання
5
обладнання та програмного забезпечення без необхідності їх придбання та
складного налаштування. Це особливо актуально в умовах фінансово-
економічних обмежень. Таким чином, дослідження зосереджено на розробці
інноваційних програмних та технічних засобів, що дозволять проектувальникам
більш ефективно здійснювати вибір апаратно-програмних платформ та
виконувати прототипування вбудованих систем управління рухомими об'єктами.
Мета роботи – створення інтегрованих інноваційних моделей, методів і
інструментів для віддаленої інженерії, орієнтованих на підвищення ефективності
автоматизованого проектування вбудованих систем.
Об’єкт дослідження – процеси проектування автоматизованих
вбудованих систем, що базуються на сучасних технологіях віддаленої інженерії.
Предмет дослідження – автоматизація проектування вбудованих систем.
Для успішної реалізації поставленої мети сформульовано та послідовно
вирішено низку взаємопов'язаних наукових завдань:
1. Проведення аналітичного дослідження існуючих методів, моделей,
підходів та інструментальних засобів автоматизованого проектування
вбудованих систем з урахуванням їх унікальних структурних,
функціональних особливостей та технологічних аспектів реалізації.
2. Удосконалення методу автоматизованого проектування вбудованих
систем на базі сучасних технологій віддаленої інженерії, який
забезпечує принципово новий рівень ефективності проектувальних
процесів.
3. Створення комплексної моделі формування вимог до вбудованих
систем в контексті автоматизованого проектування, що дозволяє більш
точно та всебічно визначати параметри майбутньої системи.
4. Формування методичного підходу до генерації рекомендацій щодо
вибору апаратно-програмних платформ у процесі автоматизованого
проектування вбудованих систем, який враховує широкий спектр
технічних критеріїв.
6
Методи дослідження. Методологічну базу дослідження складають
фундаментальні наукові теорії та підходи: системний аналіз, математичне
моделювання, багатокритеріальний аналіз, теорія баз знань. При розробленні
компонентів використано сучасні методології веб-орієнтованої розробки.
Розроблені в дослідженні теоретичні положення, методи та інструментальні
засоби створюють потужне підґрунтя для подальшого вдосконалення технологій
автоматизованого проектування вбудованих систем.
Наукова новизна одержаних результатів. Наукова новизна дослідження
представлена наступними ключовими положеннями:
1. Вдосконалено метод автоматизованого проектування вбудованих
систем з використанням технологій віддаленої інженерії. Метод
забезпечує ефективне спільне використання обладнання та
програмного забезпечення, що сприяє зниженню витрат.
2. Отримав подальший розвиток метод паралельного проектування
вбудованих систем. Його принципова відмінність полягає в інтеграції
паралельного та платформно-орієнтованого підходів разом із засобами
віддаленої інженерії, що дозволяє скоротити час переходу між
системним та функціонально-логічним рівнями проектування та
підвищити рівень автоматизації проектувальних робіт.
3. Удосконалено модель формування та управління вимогами до
вбудованих систем. На відміну від існуючих підходів, запропонована
модель враховує структурні особливості систем з апаратною та
програмною складовими, дозволяє розподіляти вимоги між
компонентами системи в процесі автоматизованого проектування
4. Отримав подальший розвиток метод формування рекомендацій щодо
апаратно-програмних платформ при автоматизованому проектуванні.
Новий підхід передбачає використання методів обмежень та
порівняння подібних об'єктів, застосування багатокритеріального
аналізу та можливість надання рекомендацій навіть за наявності
суперечливих вимог користувача.
7
Практичне значення отриманих результатів. Розроблено комплексну
структуру інструментарію віддаленої інженерії, що забезпечує підвищення
ефективності автоматизованого проектування вбудованих систем шляхом
зменшення часу проектування, зниження собівартості продукції та підвищення
рівня автоматизації проектувальних робіт, а також створено інформаційне
забезпечення рекомендаційної системи, яка надає проектувальникам підтримку
у вигляді рекомендацій щодо вибору оптимальних апаратно-програмних
платформ на основі специфічних вимог до вбудованої системи.
Апробація результатів роботи. Результати кваліфікаційної роботи
доповідалися й обговорювалися на науковій конференції:
− «Scientific research: Modern challenges and future prospects»: Тези
доповідей п’ятої міжнародної науково-практичної конференції: (16-
18 грудня 2024 р., Мюнхен), 2024.
Публікації. Результати досліджень опубліковані в:
1. Research on automation of embedded systems design / S.Mitsenko, А. Kolts
// «Scientific research: Modern challenges and future prospects»: Тези
доповідей п’ятої міжнародної науково-практичної конференції: (16-
18 грудня 2024 р., Мюнхен), 2024. – С. 31.
Структура та обсяг кваліфікаційної роботи. Кваліфікаційна робота
складається із списку умовних скорочень, вступу, трьох розділів, висновку та
списку використаних джерел. Загальний обсяг роботи складає 81 сторінка,
29 рисунків, 5 таблиць. Список використаних джерел містить 53 найменувань.
8
РОЗДІЛ 1
АНАЛІЗ ПРОЦЕСІВ АВТОМАТИЗОВАНОГО ПРОЕКТУВАННЯ
ВБУДОВАНИХ СИСТЕМ

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

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

Рис. 1.1. Класифікація вбудованих систем за сферами використання

Серед різних типів вбудованих систем особливо складними з точки зору
проєктування є системи управління рухомими об’єктами. Вони працюють у
жорстких умовах реального часу та безпосередньо взаємодіють із навколишнім
середовищем. Такі системи широко застосовуються в різних секторах економіки,
зокрема в промисловості, транспорті, оборонній сфері, сільському господарстві
та індустрії розваг. Залежно від середовища експлуатації, рухомі об’єкти
поділяються на кілька груп: наземні, надводні, підводні та літальні апарати. На
рисунку 1.2 наведено розширену класифікацію рухомих об'єктів відповідно до
систематизації, запропонованої раніше. Серед наземних апаратів виділяються
10
автомобілі, автобуси, трактори, потяги, антропоморфні чи зооморфні роботи.
Вони можуть використовувати різні механізми руху: колісний привід,
гусеничний хід, ноги чи способи повзання/стрибків.
Дослідження того, що представлено у цьому матеріалі, зосереджується
переважно на наземних колісних рухомих об’єктах. До поширених прикладів
таких об’єктів належать дистанційно керовані автомобілі, мобільні роботи,
платформи для навчання й розваг, а також безпілотні таксі. Вони знаходять
широке застосування в різних економічних галузях і навіть у військовій сфері.

Рис. 1.2. Узагальнена класифікація рухомих об'єктів

Сучасні системи управління рухомими об'єктами (УРО) мають два основні
типи побудови:
1. Автономні системи:
− Базуються на комплексі сенсорів та інтелектуальному управлінні.
− Вимагають складних алгоритмів розпізнавання перешкод та побудови
траєкторій.
− Повністю залежать від керуючої програми.
− Потребують високоточного обладнання для взаємодії з навколишнім
середовищем.
Провідні автовиробники (Tesla, Mercedes) вже презентували перші моделі
безпілотних автомобілів, однак розробники досі стикаються з викликами
забезпечення надійності та складності реалізації автономних систем.
11
2. Системи дистанційного управління. Функціонування таких систем
залежить переважно від професіоналізму оператора та якості інтерфейсу
взаємодії.
Канали зв'язку включають:
− Провідний канал (за умов неможливості бездротового зв'язку).
− Радіоканал (найпоширеніший, особливо для мобільних об'єктів).
− Ультразвуковий канал (локальне керування на короткій дистанції).
− Інфрачервоний канал (переважно для побутової електроніки).
Радіоканал забезпечує варіативність модуляції (FM, AM, SSB) та різні
діапазони частот. Розвиток технологій Інтернету речей додатково розширив
можливості дистанційного керування через Wi-Fi. Кожен тип системи має власні
переваги та обмеження, вибір залежить від конкретних завдань та технічних
вимог.
Дослідження показали дві різні системи дистанційного керування з
суттєвими технічними обмеженнями. Перша система на базі Bluetooth
використовує радіокеровану модель автомобіля з акселерометром, яка передає
інформацію про швидкість на мобільний телефон у реальному часі. Однак її
функціональність обмежена малим радіусом дії (до 10 м) і неможливістю
налаштування параметрів або одночасного керування декількома об'єктами.
Друга система, що працює через радіоканал на частоті 27 МГц, має
складнішу структуру з робочого органу транспортної мережі, блоку пам'яті та
пульта керування. Її основні недоліки включають відсутність відеоконтролю,
нестабільний зв'язок через чутливість до промислових перешкод, слабку
проникаючу здатність у міській забудові та обмежену мобільність через
відсутність компактного обладнання. Використання діапазону СВ (Citizen's
Band) не гарантує надійного та стійкого зв'язку, що суттєво знижує ефективність
системи.
Системи дистанційного керування рухомими об'єктами є складними
технічними рішеннями, що мають низку специфічних особливостей. Основним
каналом комунікації виступає радіоканал через його гнучкість та потужність
12
сигналу, на відміну від обмежених дротових з'єднань. Технічні характеристики
таких систем включають автономне живлення від літій-полімерних
акумуляторів, які забезпечують оптимальне співвідношення ваги та ємності.
Найпоширенішими виконавчими механізмами є електродвигуни, що дозволяють
ефективно реалізовувати рух об'єктів.
Дослідження та розробка систем дистанційного керування потребують
створення прототипів, які слугують інструментом для вивчення методів
проектування вбудованих систем. Економічна доцільність та доступність таких
моделей робить їх важливим напрямком технічних досліджень.
Водночас, наявні системи мають суттєві обмеження: недостатній радіус
керування, неможливість одночасного управління групою об'єктів та низьку
мобільність. Тому актуальним завданням є розроблення автоматизованої
системи, яка б забезпечувала:
− Керування декількома об'єктами одночасно.
− Налаштування індивідуальних параметрів.
− Створення ефекту присутності оператора.
− Контроль траєкторії руху.
− Моніторинг поточного стану об'єктів.
Такі системи мають критичне значення для вивчення небезпечних та
важкодоступних місць, забезпечуючи операторам повноцінний дистанційний
контроль.

1.2. Дослідження характеристик вбудованих систем та методів їх
впровадження
Для розробників обчислювальних систем вбудовані системи (ВС) є одними
з найбільш складних об’єктів проектування [15]. Це підтверджується аналізом
типових вимог і обмежень, які необхідно враховувати при створенні ВС. На
основі досліджень [15, 16, 18] сформовано перелік ключових вимог та обмежень,
що впливають на якість проектованої системи:
− міцність конструкції;
13
− робота в реальному часі;
− мінімізація розмірів і ваги з урахуванням форми виробу;
− забезпечення теплових режимів (оскільки обмежені розміри зазвичай
не дозволяють використовувати системи примусового охолодження);
− мінімальне енергоспоживання (через переважно автономне живлення);
− радіаційна та електромагнітна стійкість (а також працездатність у
вакуумі);
− гарантований час напрацювання на відмову;
− тривалість доступності рішення на ринку тощо.
Дослідження автоматизованих систем керування рухомими об’єктами
(УРО) [5] дозволило виявити додаткові вимоги до ВС УРО:
− радіус дистанційного керування не менше 50 метрів;
− мобільність;
− завадостійкість;
− надійність роботи системи;
− можливість одночасного керування кількома об’єктами;
− функція налаштування параметрів керування;
− передача відеозображення з об’єкта для контролю процесу руху та
створення ефекту присутності оператора в зоні дослідження.
Системи дистанційного керування рухомими об’єктами мають свої
конструктивні особливості, від яких залежить їх ефективність. Основними
факторами є якість інтерфейсу, характеристики каналу зв’язку та дії оператора.
Аналіз конструктивних особливостей ВС УРО показує, що типова система
включає:
− головний модуль керування;
− периферійну систему (сенсори, актуатори, контролери
введення/виведення для взаємодії з об’єктом, пристрої
людиномашинного інтерфейсу за потреби);
− систему електроживлення;
14
− конструктивну основу (шасі, корпус);
− програмне забезпечення для керування.
Таким чином, забезпечення вимог до проектованих ВС УРО потребує
комплексного підходу, що враховує взаємодію апаратних і програмних
складових та особливості їх реалізації.

Рис. 1.3. Загальна структурна схема вбудованої системи управління рухомими
об’єктами

Системи дистанційного керування рухомими об’єктами мають специфічні
конструктивні особливості. Їх ефективність значною мірою залежить від якості
інтерфейсу, характеристик каналу зв’язку та дій оператора. Аналіз
конструктивних особливостей ВС УРО показав, що типова вбудована система
включає наступні компоненти (рис. 1.3) [8]:
− головний модуль керування;
− систему електроживлення;
− конструктивну основу (шасі, корпус);
15
− програмне забезпечення, що забезпечує керування;
− периферійну систему (сенсори, актуатори, контролери
введення/виведення для взаємодії з об’єктом управління чи контролю,
а також пристрої людиномашинного інтерфейсу за необхідності).
Таким чином, забезпечення відповідності вимогам до проектованої ВС
УРО вимагає комплексного підходу, який враховує взаємодію апаратної та
програмної складових, а також специфіку їх реалізації.

Рис. 1.4. Методи реалізації вбудованих систем

Технології реалізації ВС УРО можуть варіюватися залежно від
функціональних завдань, які необхідно виконувати, та цілей створення системи.
Апаратна частина головного модуля керування сучасних ВС УРО може бути
побудована на основі різних технологій (рис. 1.4) [8]:
− промислові комп’ютери;
− програмовані логічні контролери (ПЛК);
− мобільні та інтернет-пристрої;
− контролерні та сенсорні мережі;
16
− мікроконтролери (МК);
− сигнальні процесори;
− програмовані логічні інтегральні схеми (ПЛІС);
− - надвеликі інтегральні схеми (НВІС).
Кожна з цих технологій має свої переваги та недоліки. У більшості
випадків вибір апаратної основи визначається складним балансом різних
факторів, оскільки жодна з них не є універсально ідеальним рішенням [8].
Під час впровадження ВС УРО використання мікроконтролерів (МК) має
низку суттєвих переваг: компактність, низьку собівартість і мінімальне
енергоспоживання. Це особливо важливо для пристроїв із автономним
живленням, таких як рухомі об’єкти. Крім того, за оцінками фахівців, системи на
основі МК є більш гнучкими, оскільки керуючу програму можна багаторазово
змінювати без необхідності внесення змін до апаратної частини пристрою.
Розробники мікроконтролерів, з метою популяризації своєї продукції,
активно пропонують готові апаратно-програмні платформи. Ці платформи
забезпечують базовий функціонал, який можна розширювати за потреби.
Сьогодні ринок пропонує велику кількість таких платформ для розробки ВС:
Arduino (версії Mega, Uno, Leonardo, Mini, Yun та інші), Raspberry Pi, TI MSP430
Launchpad, Beagleboard, Intel Galileo, pcDuino, STM32 Nucleo, Strela, Iskra (Mini,
Neo), Netduino, Teensy 3.2, CMUcam та інші.
Вибір платформ базується на традиційних порівняльних критеріях. До них
належать характеристики контролера (швидкодія, енергоспоживання, наявність
периферії на кристалі), доступний функціонал (підтримувані протоколи зв’язку
з врахуванням пам’яті), вбудовані периферійні пристрої та рівень технічної
підтримки від постачальника (інструменти для створення програмного
забезпечення, приклади використання). Результати дослідження характеристик
найбільш популярних платформ наведені у таблиці 1.1.
Аналіз ринку апаратно-програмних платформ свідчить про те, що їх можна
умовно поділити на два основні типи: платформи на базі мікроконтролерів і
одноплатні комп’ютери (або мінікомп’ютери). Хоча за своїми технічними
17
параметрами платформи на основі МК часто поступаються одноплатним
комп’ютерам, вибір найбільш відповідного рішення для розробки проекту не
може ґрунтуватися лише на цих специфікаціях. Комплексний підхід до оцінки
варіантів тут має вирішальне значення.

Таблиця 1.1.
Результати аналізу популярних апаратно-програмних платформ
Назва
Сімейство Процесор ОЗП ПЗП Частота Цифрові Аналогові
платформи
Arduino ATSAM3X8 96 512
ARM 84MHz 54 16
Due E Cortex-M3 KB KB
Arduino
AVR ATmega328 2KB 32KB 16MHz 14 6
Uno
Raspberry Broadcom
ARM 1GB - 1.2GHz 27 0
Pi 3 BCM2837
MSP-
MSP4 MSP-
EXP430G2 512B 16KB 16MHz 16 8
30 EXP430G2
LaunchPad
Intel x86 Quark SoC 512 400
8MB 20 6
Galileo Quark X1000 KB MHz

Для створення простої системи управління рухомим об’єктом, яка охоплює
керування приводами, сенсорами та іншою периферією, достатньо
використовувати платформу на основі мікроконтролера (наприклад, Arduino Uno
чи MSP430 Launchpad). Проте, якщо необхідно виконувати завдання з обробки
медіа (наприклад, розпізнавання зображень або мовлення) чи забезпечення
доступу до Інтернету, можливостей мікроконтролера буде недостатньо. Хоча
платформи на основі мікроконтролерів можна підключати до мережі за
допомогою спеціальних плат розширення, вони не здатні ефективно справлятися
зі складними обчислювальними процесами. У таких випадках доцільніше
18
обирати одноплатні комп’ютери, такі як Raspberry Pi, pcDuino3 або Beagleboard.
Якщо необхідно розробити комплексну систему управління, яка виконує
обробку відео чи працює з великою кількістю даних від різноманітних сенсорів,
рекомендується розподілити завдання між мікроконтролером та одноплатним
комп’ютером. Це пояснюється тим, що через багатозадачність одноплатний
комп’ютер може затримувати виконання критичних завдань у реальному часі,
що є неприпустимим для систем управління рухомими об'єктами. Відтак, функції
точної взаємодії із сенсорами та актуаторами бажано доручити мікроконтролеру,
залишивши процесору складну обробку даних. Тому порівняння цих платформ
не завжди є доцільним через їх принципово різне призначення. Деталізовану
інформацію щодо особливостей застосування обох типів платформ узагальнено
в таблиці 1.2.
Завдяки сучасним інтерфейсам зв’язку (USB, локальна мережа, послідовні
підключення портів вводу/виводу, радіозв’язок) платформи на основі
мікроконтролерів та одноплатні комп’ютери можуть працювати спільно. Крім
того, сьогодні доступні гібридні платформи, які поєднують у собі властивості як
мікроконтролера, так і мікропроцесора (наприклад, Arduino Yun чи Embedded
Pi). Також існують спеціалізовані апаратно-програмні рішення для конкретних
завдань, таких як робототехнічні системи (наприклад, Strela або Romeo BLE/-
mini). Відмінності між платформами включають також їхній форм-фактор, що
важливо при створенні систем із жорсткими вимогами до масогабаритних
показників. Ще одним значущим фактором є доступність спільноти користувачів
тієї чи іншої платформи та відкритість проекту, що є особливо корисним для
новачків у розробці. Отже, аналіз показав, що існує широкий вибір технологій
для реалізації вбудованих систем управління рухомими об’єктами. Готові
апаратно-програмні платформи на базі мікроконтролерів дозволяють істотно
скоротити час розробки системи та сприяють повторному використанню у
майбутніх проектах. Проте вибір оптимального рішення для конкретного
завдання може вимагати значних часових ресурсів через різноманіття доступних
платформ.
19
Таблиця 1.2.
Особливості використання різних апаратно-програмних платформ
Одноплатні комп’ютери Платформи на основі МК
≈100-1000МГц, ≈100КБ ≈10-100МГц, ≈10КБ
Продуктивність
RAM, ≈1ГБ ROM RAM, ≈10-100КБ ROM
Споживає сотні-тисячі
Споживає одиницідесятки
мА. Години автономної
Живлення мА. Тижні автономної
роботи та складності при
роботи.
її реалізації.
Підключення просте,
Додаткові модулі та глибоке
Мережа модуль роботи з мережею
знання протоколів.
є на платформі.
Можуть виникати
Робота у затримки роботи через
Повний контроль над часом.
реальному часі багатозадачність або
помилки ОС.
OpenCV, апаратні
Обробка відео Не вистачає потужності.
відеокодеки, HDMI-вихід
Не обмежена мова С. В
Мова Частіше мови С/С++ та їх
залежності від
програмування різновиди.
можливостей ОС.
У деяких є проблема
підключення аналогових З легкістю працюють з будь-
Сенсори
пристроїв. Для взаємодії якими сенсорами.
необхідне ПЗ.

Для вибору апаратно-програмної платформи варто враховувати весь
комплекс вимог до системи, що проектується. Це включає вивчення існуючих
рішень на ринку, детальний аналіз їх характеристик, знання особливостей
платформ, а також наявність досвіду роботи з обраними рішеннями.
20
1.3. Дослідження підходів до проектування вбудованих систем
Вбудовані системи (ВС) є специфічним класом, які поєднують апаратні та
програмні компоненти. Використання традиційного підходу у їх розробці часто
призводить до таких недоліків:
– необхідність ручної інтеграції різних компонентів проекту;
– ізольований процес проектування апаратних та програмних складових;
– некоректне розділення апаратної і програмної частин на ранніх етапах;
– помилки, що компенсуються під час налагодження за рахунок змін у
програмному забезпеченні.
Ці чинники сприяють високій ймовірності виявлення критичних помилок
на пізніх стадіях проекту. Як наслідок, це може спричиняти значні затримки
виходу продукту на ринок. Для вирішення цих проблем експерти пропонують
кілька перспективних методологій:
– паралельне проектування (co-design);
– об’єктно-орієнтоване проектування (object-oriented design);
– платформно-орієнтоване проектування (platform-based design).
Паралельне проектування в узагальненому вигляді представлено на схемах
та передбачає ітераційну структуру. Процес розпочинається зі створення
специфікацій проекту, формулювання вимог до системи та розробки архітектури
із поділом програмних і апаратних компонентів. Далі виконуються окремо
проектування й розробка кожної складової з їх подальшою перевіркою,
інтеграцією та тестуванням всієї системи. Паралельний підхід має як переваги,
так і недоліки. З одного боку, він ускладнює сам процес розробки. З іншого боку,
дозволяє отримати суттєво покращений кінцевий продукт.
Об’єктно-орієнтоване проектування переймає методології програмної
інженерії, адаптуючи їх до середовища мов опису апаратного забезпечення. Воно
спрямоване на повторну використуваність компонентів і полегшення управління
складністю системи.
Платформно-орієнтований підхід базується на концепції повторного
використання напрацьованих рішень. Це дозволяє значно прискорити процес
21
проектування завдяки використанню готових і протестованих програмних
компонентів, таких як операційні системи реального часу, API, бібліотеки,
драйвери тощо.

Рис. 1.5. Схема методу паралельного проектування вдудованих систем

Повторно використовуваними компонентами у проектуванні вбудованих
систем (ВС) можуть бути, зокрема, апаратно-програмні платформи, такі як
Arduino, STM Discovery тощо. Застосування цих платформ значно спрощує етап
розробки завдяки наявності готових конструктивних рішень. Крім того,
спеціалізоване програмне забезпечення, що постачається з такими платформами,
доступність високорівневих мов програмування, а також велика кількість
стандартних функцій та бібліотек сприяють полегшенню процесів написання та
налагодження програмного забезпечення ВС [42]. Однак важливо відзначити, що
вихід цих платформ на широкий ринок поставив перед їх розробниками завдання
універсалізації як доступу до пристроїв, так і їх використання. Водночас
шаблонний підхід до побудови таких платформ призвів до виникнення певних
проблем під час їх застосування. Наприклад, для реалізації складних функцій
часто доводиться доповнювати базову платформу платами розширення або
22
шилдами, що збільшує вартість, габарити та масу системи, а це нерідко є
критичним для проєктування ВС. Тому вибір апаратно-програмної платформи
має враховувати цілу низку факторів, головними з яких є вимоги до конкретної
вбудованої системи. Збір та аналіз вимог, визначення обмежень (щодо
швидкодії, розмірів, надійності, енергоспоживання тощо), а також співставлення
готових апаратних та програмних рішень із цими вимогами є ключовими
процесами на етапі високорівневого проектування ВС. Крім того, важливим
аспектом успішної реалізації системи є правильний розподіл цих вимог між
апаратними та програмними компонентами архітектури.
Відповідно до даних розподілу часу на різних стадіях проектування [13],
збільшення витрат часу на високорівневе проектування сприяє скороченню часу,
необхідного для наступних етапів прототипування та тестування. Проте фахівці
зауважують, що розрив між сучасними вимогами до ВС і ефективністю існуючих
методів апаратно-програмного проектування, а також масштабами необхідної
верифікації та тестування продовжує зростати [15].
У зв’язку з цим створення ВС «з нуля» із використанням класичних
методів вже не є ефективним підходом. В умовах розвитку області проектування
ВС дедалі більшої популярності набувають паралельне та платформно-
орієнтоване проєктування. Також актуальним стає застосування методології
повторного використання, що дозволяє значно прискорити процес розробки і
зменшити час виходу продукту на ринок.
Таким чином, подальший розвиток методів проектування ВС, а також
накопичення та повторне використання існуючих апаратних і програмних
рішень є ключовими напрямками для підвищення ефективності
автоматизованого проектування вбудованих систем.

1.4. Дослідження вимог під час автоматизованого проектування
вбудованих систем
Згідно зі стандартом [24], проектування будь-якої системи включає
технічні процеси, пов’язані з роботою над вимогами: визначення вимог
23
правовласника та аналіз вимог. Процес визначення вимог правовласника
забезпечує створення переліку всіх зацікавлених сторін і їхніх вимог до системи.
Ці вимоги стають основою для подальшого аналізу та виявлення функціональних
і нефункціональних характеристик системи. У свою чергу, результатом аналізу
вимог є трансформація побажань правовласника або зацікавлених сторін у
технічне бачення системи. Це дозволяє чітко класифікувати вимоги до системи,
що безпосередньо впливає як на архітектурне проектування, так і на вибір засобів
для реалізації.
Питання роботи із системними вимогами висвітлюється в роботах [5,8]. У
стандарті [16] зазначено, що поняття «Вимоги до системи» охоплює такі
компоненти:
− загальні вимоги до системи (бізнес-вимоги, зовнішні інтерфейси);
− вимоги до функцій, що виконуються системою (функціональні
характеристики, атрибути якості);
− обмеження забезпечення.
До загальних вимог також відноситься опис структури системи,
включаючи перелік її компонентів. У складних проєктах із великою кількістю
підсистем рекомендується проводити розподіл високорівневих вимог між цими
підсистемами [5].
Міжнародний стандарт [15] став початковим кроком до створення єдиного
комплексу стандартів, які описують життєвий цикл систем і програмного
забезпечення. Він визначає строгий взаємозв'язок між системою та її
програмними компонентами, наголошуючи на тому, що програмне забезпечення
є невід'ємною частиною системи. Стандарт підкреслює важливість
виокремлення вимог до програмного забезпечення з-поміж загальносистемних
вимог. У ньому також розмежовуються аналіз системних вимог та аналіз вимог
до програмних продуктів. Зазвичай проектування архітектури системи
встановлює загальносистемні вимоги для різних компонентів, тоді як аналіз
вимог до ПЗ розкриває специфічні вимоги до цих програмних компонентів на
основі загальносистемних.
24
Окрім процесів роботи із системними вимогами, згаданих у стандарті [24],
у стандарті [25] виділяються спеціалізовані процеси, зокрема ті, що стосуються
створення окремих програмних компонентів системи. Сюди належить і процес
аналізу вимог до програмного забезпечення. У межах цього процесу
уточнюються вимоги до програмних елементів і їхніх інтерфейсів, визначається
вплив ПЗ на середовище функціонування, а також встановлюються зв’язки між
вимогами до ПЗ і загальносистемними вимогами.
Як зазначено в [27], вхідними даними для визначення вимог до ПЗ
виступають системні вимоги, опис апаратних інтерфейсів і архітектури системи
(якщо вони не охоплені у рамках загальносистемних вимог). Основна мета
процесу проектування ПЗ полягає у розробці архітектури та нижчого рівня вимог
на основі вищого рівня специфікацій для ПЗ. Із цього випливає, що створення
архітектури ПЗ відбувається вже після завершення опису апаратної частини
проекту та її архітектури.
У праці Д. Леффінгвелла детально проаналізовано процес управління
вимогами. Леффінгвелл пропонує трирівневу модель формування вимог:
1. Потреби – це вимоги користувачів або зацікавлених сторін.
2. Функції – можливості системи, які задовольняють потреби
зацікавлених сторін.
3. Програмні вимоги – детальні вимоги до програмного забезпечення.
Кластер потреб фокусується на розумінні проблем користувачів
(замовників) для створення системи, що відповідає їхнім очікуванням. Водночас
два інші кластери – функції та програмні вимоги – спрямовані на вирішення цих
проблем у контексті розробки системи.
Як зазначено в різних джерелах, зокрема, у [38], під час розробки
програмного забезпечення використовують підхід, заснований на формуванні
груп вимог до програмного продукту. Цей підхід передбачає кластеризацію
вимог за типами чи категоріями: системні, програмні, функціональні та
нефункціональні (включаючи якісні атрибути). Прикладом структуризації вимог
є модель К. Вігерса, представлена в роботі [5].
25
Вона визначає три рівні вимог:
1. Бізнес-вимоги – описують мету створення системи.
2. Вимоги користувача – окреслюють взаємодію користувачів із
системою.
3. Функціональні вимоги – уточнюють функціональність і поведінку
програмної системи.
У цій моделі також виділено два типи вимог:
− Функціональні (визначають, що повинна виконувати система).
− Нефункціональні (формулюють умови, які мають бути дотримані під
час роботи).
Важливим аспектом моделі є ознака зовнішнього інтерфейсу, під яким
розуміють взаємодію користувача з програмним забезпеченням, тобто інтерфейс
користувача. У стандарті [17] дано більш розгорнуте визначення інтерфейсу як
взаємозв’язку між двома чи більше об’єктами, які обмінюються та
використовують спільні дані.
Таким чином, об’єктами можуть бути: елемент конфігурації ПЗ (ЕКПЗ) –
набір компонентів програмного забезпечення; елемент конфігурації апаратури
(ЕКА) – набір складників апаратного забезпечення. Варіанти інтерфейсів
включають ЕКПЗ/ЕКПЗ, ЕКПЗ/ЕКА, ЕКПЗ/користувач, ЕКА/користувач або
модуль ПЗ/модуль ПЗ.
За стандартом [26], вбудована система – це сукупність апаратних і
програмних компонентів для виконання однієї чи кількох визначених функцій.
Оскільки розробка ПЗ є невід’ємною частиною проєктування вбудованих
систем, рекомендується застосування комплексного підходу. Це включає
використання принципів системної та програмної інженерії для визначення як
системних (загальних вимог до проєкту), так і програмних вимог (розподілених
між програмними компонентами).
Одним із ключових етапів контролю розробки вимог є їхнє трасування, яке
забезпечує взаємозв’язок між різними рівнями вимог. Це потрібно для
розуміння, як вимоги верхнього рівня трансформуються у конкретні вимоги
26
нижчого рівня. Для реалізації трасування кожна вимога повинна бути
унікальною та мати ідентифікатор, що дозволяє легко на неї посилатися.
Ефективне управління трасуванням досягається через використання методик
управління вимогами та відповідних програмних інструментів. Серед таких
інструментів можна виділити IBM Rational RequisitePro, Borland CaliberRM та
DOORS.
Особливою перевагою Rational RequisitePro є:
− наявність готових шаблонів для підготовки проектної документації;
− підтримка створення документації за допомогою Microsoft Word;
− інтеграція із засобами об’єктно-орієнтованого моделювання;
− зручний навігатор між Word та інфраструктурою бази даних;
− можливість відстежувати взаємозв’язки між вимогами різного рівня за
допомогою Матриці трасування.
Процес складання переліку вимог передбачає структурування, зокрема
групування їх за певними ознаками. Одним із критеріїв такого поділу є системні
компоненти або об’єкти (підсистеми). Для великих систем (ВС) основними
компонентами є апаратні та програмні елементи, що також визначають часовий
розподіл процесу проектування. Згідно з дослідженнями, процес проектування
апаратних компонентів може бути поділений на проектування електронної та
механічної частин.
Перелік вимог для ВС можна класифікувати на наступні основні групи:
− загальні вимоги до системи;
− вимоги до програмного забезпечення (ПЗ);
− вимоги до апаратного забезпечення (АЗ), зокрема до електронної й
механічної частин;
− нефункціональні вимоги.
Робота з вимогами відіграє вирішальну роль у побудові проєкту ВС,
оскільки вона забезпечує досягнення поставлених цілей. Втім, існуючі стандарти
та дослідження в цій сфері описують лише окремі аспекти формування та аналізу
вимог, залишаючи поза увагою специфіку автоматизованого проектування ВС.
27
У зв’язку з цим, моделі вимог до ПЗ, представлені в попередніх
дослідженнях, можуть стати основою для розробки моделі формування вимог до
ВС у верхньорівневих організаціях (УРО). Однак вони потребують модифікації
для врахування інших типів вимог і процесів їх опрацювання відповідно до
стандартів. Використання такої вдосконаленої моделі та методів роботи з
вимогами сприятиме обґрунтованому вибору апаратно-програмної платформи
при автоматизованому проектуванні ВС.

1.5. Програмні засоби автоматизації проектування вбудованих систем
Сьогодні на різних етапах автоматизованого проектування вбудованих
систем активно використовуються різноманітні програмні засоби. Їх
призначення охоплює системне, функціонально-логічне, схемотехнічне та
конструкторське проектування, а також моделювання електричних, теплових,
механічних й інших процесів.
Наприклад, широко відомі системи ECAD (Electronic Computer Aided
Design) такі як Altium Designer, SPICE, EAGLE, ISIS PROTEUS, AutoCAD
Electrical, KiCad та Circuit Maker дозволяють вирішувати завдання розробки
електричних принципових схем, створення друкованих плат, виконання
схемотехнічного аналізу, 3D-візуалізації друкованих плат та інші проектні
процедури. Окремі системи, наприклад PROTEUS, забезпечують можливість
моделювання функціонування програмованих пристроїв і електронних схем в
цілому. Проте більшість досліджуваного програмного забезпечення має платний
характер, потребує значного часу на освоєння, вимагає високих ресурсів
комп’ютера і не завжди передбачає необхідність використання повного набору
функцій.
Розвиток Інтернет-технологій і їх популяризація суттєво вплинули на
сферу проектування. Крім традиційних десктопних рішень усе активніше
застосовуються технології віддаленої інженерії: онлайн-симулятори, віддалені
лабораторії, рекомендаційні системи й хмарні сервіси. Віддалена інженерія
спрямована на спільне використання обладнання, ресурсів і спеціалізованого ПЗ,
28
такого як симулятори. Використання інструментів віддаленої інженерії є
перспективним напрямком розвитку, що обумовлюється такими тенденціями:
− зростаюча складність інженерних завдань із мінімальним терміном
реалізації проєктів;
− потреба у використанні дорогого спеціалізованого обладнання й
програмного забезпечення;
− відсутність доступу до високотехнологічного обладнання для малих і
середніх підприємств;
− необхідність залучення висококваліфікованого персоналу для роботи зі
складним обладнанням;
− вимоги ринку до глобалізації та поділу праці.
Серед онлайнових інструментів для створення схем електричних
принципових та друкованих плат можна виділити Circuits від Autodesk і сервіс
EasyEDA.
Набуваючи популярності, готові апаратно-програмні платформи для
проектування вбудованих систем стимулюють компанії розробляти симуляторні
програми для створення віртуальних прототипів із подальшим моделюванням
їхньої роботи. До таких програм належать Virtualbreadboard, Virtronics, Simuino
тощо.
Сучасні ECAD-системи (Electronic Computer Aided Design), такі як Altium
Designer, SPICE, EAGLE, ISIS PROTEUS, AutoCAD Electrical, KiCad, Circuit
Maker та інші, забезпечують широкий функціонал для розробки електричних
схем, проектування друкованих плат, проведення схемотехнічного аналізу, 3D-
візуалізації та інших завдань. Деякі з них, наприклад PROTEUS, дозволяють
також симулювати роботу програмованих пристроїв і електронної системи в
цілому. Однак більшість цих програмних продуктів є комерційними, потребують
значного часу на освоєння, вимагають потужних обчислювальних ресурсів, а
використання всього їх функціоналу не завжди виправдане.
Розвиток Інтернет-технологій та їх стрімка популяризація суттєво
трансформували галузь проектування. Поряд із традиційними десктопними
29
рішеннями активно впроваджуються інструменти віддаленої інженерії, зокрема
онлайн-симулятори, віддалені лабораторії, рекомендаційні системи та хмарні
сервіси. Віддалена інженерія орієнтована на спільне використання обладнання,
ресурсів і спеціалізованого софту (таких як симулятори).
Перспективність впровадження інструментів віддаленої інженерії у
проектуванні вбудованих систем зумовлюється кількома ключовими
тенденціями:
− зростанням складності інженерних завдань та необхідністю вирішення
їх у короткі терміни;
− збільшенням кількості дорогого спеціалізованого обладнання і софту в
процесі розробки;
− обмеженим доступом малих і середніх підприємств до
високотехнологічного обладнання;
− потребою у висококваліфікованих фахівцях для роботи з сучасними
системами;
− глобалізацією ринків та розподілом праці.
До онлайн-інструментів для розробки принципових схем і друкованих плат
можна віднести такі сервіси, як Circuits від Autodesk і EasyEDA. У свою чергу, з
огляду на тенденцію активного впровадження апаратно-програмних платформ у
проектуванні вбудованих систем, окремі компанії пропонують симулятори для
створення віртуальних прототипів з подальшим моделюванням їх роботи. Серед
таких програм можна виділити Virtualbreadboard, Virtronics, Simuino та інші.
Компанія Autodesk пропонує онлайн-версію симулятора для роботи з
платформою Arduino під назвою Tinkercad. Аналогічно, Microsoft розробив
онлайн-симулятор для платформи Raspberry Pi. Обидва ці інструменти
дозволяють створювати електричні схеми, проводити налагодження
програмного забезпечення та симуляцію взаємодії платформи з основними
сенсорами та актуаторами.
Сервіс TIDesigns від Texas Instruments працює на основі технології
WEBENCH і представлений як Flash-додаток у браузері під назвою WEBENCH
30
Design Center. Цей інструмент дозволяє вирішувати завдання розробки схем
живлення або освітлення із використанням продукції компанії, а також
здійснювати симуляцію електричних струмів та моделювати теплові процеси.
Крім того, існує можливість оптимізації запропонованих схем за такими
критеріями, як вартість компонентів, компактність конструкції та її
працездатність. Завершивши моделювання, користувач може експортувати
електричну схему та друковану плату у популярні формати, які підтримуються
системами проектування, наприклад Altium Design, OrCAD, EAGLE тощо.
Симулятори залишаються важливими інструментами у процесі
паралельного проектування вбудованих систем. Однак вони не можуть повністю
замінити роботу з реальними апаратними та програмними засобами. Замість
фізичного процесу симуляція відтворює математичну модель, точність якої
визначає успішність моделювання. Як засвідчили дослідження, наявні
симулятори часто мають обмежені функції та не завжди забезпечують повний
набір елементів. Віртуальні та віддалені лабораторії є важливими складовими
віддаленої інженерії, що дають змогу досліджувати різні аспекти проектування
та управляти віддалено доступними пристроями. Вони сприяють ефективному
використанню програмного забезпечення та обладнання, враховуючи економічні
обмеження. Сучасні розробки демонструють широкий вибір віртуальних і
віддалених лабораторій для галузей електроніки та робототехніки.
Наприклад, гібридна віддалена лабораторія GOLDI (Grid of Online Lab
Devices Ilmenau), створена на базі кафедри інтегрованих систем зв’язку
Технологічного університету Ільменау (Німеччина), включає інструменти для
розв’язання складних завдань управління в різних сферах, таких як
машинобудування, робототехніка та телекомунікації.
Інший приклад – віддалена лабораторія WebLab-Deusto, розроблена
інженерним факультетом Університету Деусто (Іспанія). Вона дає змогу
завантажувати і впроваджувати різноманітні дистанційні експерименти в різних
середовищах і операційних системах з акцентом на вивчення робототехніки й
електроніки.
31
Мережа Labshare об’єднує віддалені лабораторії п’яти технічних
університетів Австралії. Її експериментальні стенди надають можливості для
вирішення завдань у галузях фізики, робототехніки та телекомунікацій.

Рис.1.6. С Інтерфейсна сторінка GOLDI

Рис.1.7. Інтерфейсна сторінка Web Lab Deusto
32
e-Laboratory Project (Чехія та Словаччина) – це віддалена лабораторія, яка
забезпечує доступ до різних експериментів у галузях електроніки та фізики.
iLabs – онлайн-лабораторія, створена Массачусетським технологічним
інститутом для проведення експериментів у сфері мікроелектроніки,
проектування конструкцій та обробки сигналів.
Дослідження вказують на те, що більшість існуючих віддалених
лабораторій (ВЛ) функціонують переважно як освітні ресурси. Однак для
виконання проектних і виробничих завдань ці лабораторії потребують
подальшого вдосконалення. Створення та інтеграція ВЛ у процеси проектування
електронних систем для оптимізації витрат на розробку, зокрема шляхом
спільного використання обладнання та програмного забезпечення, залишається
актуальним завданням.
Нині серед інформаційно-пошукових систем особливого поширення
набули рекомендаційні системи (РС), які активно використовуються для аналізу
даних і формування пропозицій. Рекомендаційні системи для електронних
компонентів умовно поділяються на дві групи: платформи продажу й ресурси
для розробників. Українські сервіси з продажу зазвичай використовують базову
систему групування компонентів за назвою виробника або їх призначенням.
Водночас сайти розробників, такі як Arduino чи Raspberry Pi, пропонують
структуровану інформацію про власний асортимент. Наприклад, Arduino групує
свої продукти за платформами, модулями та додатковими шилдами відповідно
до їхньої сфери застосування, а Raspberry Pi класифікує продукцію за такими
категоріями, як платформи, аксесуари (сенсори та актуатори) і модулі.
Одним із прикладів спеціалізованих рекомендаційних систем є сервіс
TIDesigns від компанії Texas Instruments. Він виконує фільтрацію схем та
компонентів залежно від введених користувачем параметрів, а також надає
можливість пошуку сумісної продукції компанії. Для платформи LaunchPad
компанія створила інструмент BoosterPack Checker, який визначає її сумісність
із додатковими модулями BoosterPack. Така перевірка базується на кількості
контактних пінів платформи LaunchPad та модулів BoosterPack.
33
Компанія STMicrocontrollers, інший відомий виробник електроніки,
пропонує перелік сумісних платформ із асортименту своїх продуктів на основі
вибраної налагоджувальної плати, зокрема з усіма необхідними матеріалами.

Рис. 1.8. Інструмент перевірки TI BoosterPack

У свою чергу, Microchip забезпечує користувачів інструментом Parametric
Search Tool для добору мікроконтролерів та мікропроцесорів Atmel й Microchip
за заданими параметрами. Інтерфейс пошукового інструмента представлено
списками параметрів (наприклад, «тип процесора», «сімейство» тощо). Кожна
зміна параметра миттєво оновлює результати пошуку.
Аналіз існуючих ресурсів щодо продажу електронних компонентів і сайтів
для розробників показав: сервіси продажу лише впорядковують інформацію,
полегшуючи її пошук, але не пропонують рекомендацій щодо вибору
компонентів. Виробники електроніки надають певні рекомендації, однак
зосереджуються переважно на просуванні власної продукції. Вони пропонують
додаткові можливості для розширення функціоналу своїх базових платформ, що,
на жаль, не завжди допомагає проектувальникам у виборі саме базової
платформи. Через це інформація на сайтах виробників нерідко не дозволяє
прийняти правильне проектне рішення та оптимально реалізувати задумані
проекти.
34

Рис. 1.9. Інтерфейс інструмента Parametric Search Tool

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

Висновки
Проведено аналіз актуального стану розвитку вбудованих систем (ВС) та
виконано їх класифікацію за галузями застосування. Дослідження існуючих
35
систем дистанційного управління наземними колесними рухомими об’єктами
дозволило визначити їх переваги, недоліки, а також особливості розробки й
експлуатації. Проаналізовано структурні та функціональні особливості ВС для
управління рухомими об’єктами (ВС УРО), що дало можливість сформулювати
комплекс вимог до таких систем, які необхідно враховувати під час
автоматизованого проектування.
Проведений детальний аналіз технологій реалізації ВС підтвердив, що
застосування мікроконтролерів (МК) та апаратно-програмних платформ на їх
основі має низку переваг при проектуванні. Водночас виявлено проблему
швидкого вибору відповідної апаратно-програмної платформи з-поміж
численних рішень, доступних у мережі Інтернет.
У ході аналізу методів проектування ВС встановлено недоліки
традиційних підходів. Висновок, що одночасне використання паралельного і
платформно-орієнтованого методів проектування разом із методологією
повторного використання сприяє покращенню ефективності автоматизованого
проектування, є перспективним. Проведені дослідження програмних рішень для
автоматизації проектування ВС (десктопних і онлайн платформ) показали
різноманітність інструментів для вирішення завдань на різних етапах розробки.
Водночас виявлено відсутність засобів підтримки переходу між етапами
системного рівня, де працюють із вимогами до ВС, і функціонально-логічного
рівня проектування.

.
36
РОЗДІЛ 2
МОДЕЛЬ АВТОМАТИЗАЦІЇ ПРОЕКТУВАННЯ ВБУДОВАНИХ
СИСТЕМ ІЗ ВИКОРИСТАННЯМ ТЕХНОЛОГІЙ ВІДДАЛЕНОЇ
ІНЖЕНЕРІЇ

2.1 Модель визначення вимог до вбудованої системи
На основі проведеного аналізу існуючих описових моделей вимог та
стандартів, які визначають різні типи вимог, була розроблена вдосконалена
модель формування вимог до ВС [45]. У структурованій формі ця модель
зображена на рис. 2.1.
Як і моделі вимог Вігерса та Леффінгвелла [5,6], запропонована модель
містить три рівні. Однак, на відміну від зазначених моделей, вона враховує
структурні особливості ВС як системи, що об’єднує апаратні та програмні
компоненти, а також деталізує процес розподілу вимог між програмним і
апаратним забезпеченням.
У новій моделі чітко виділено такі рівні:
− Рівень користувача включає вимоги всіх зацікавлених осіб проекту,
зокрема клієнта, кінцевих користувачів продукту, розробників та інших
учасників процесу. На цьому рівні можуть бути представлені бізнес-
вимоги, варіанти використання та атрибути якості.
− Рівень системи охоплює вимоги до системи як до комбінації
взаємопов’язаних компонентів, таких як апаратне забезпечення,
програмне забезпечення, користувачі тощо. Включає системні вимоги
(загальні для системи) і нефункціональні вимоги (наприклад,
обмеження, інтерфейси, конструктивні особливості або умови
експлуатації).
− Функціональний рівень включає функціональні характеристики, які
розподіляються між апаратними та програмними компонентами
системи.
37

Рис. 2.1. Структура моделі визначення вимог до вбудованої системи (ВС)

На рис. 2.1 представлена структура запропонованої моделі формування
вимог до ВС. У порівнянні з моделлю Вігерса, в пропонованій моделі можна
виділити такі ключові відмінності:
− На верхньому рівні присутні лише вимоги зацікавлених осіб.
− Введений додатковий середній рівень із системними вимогами до ВС,
які включають також нефункціональні вимоги, такі як обмеження та
вимоги до інтерфейсів.
− На нижньому рівні відбувається декомпозиція функціональних вимог
із урахуванням особливостей ВС на категорії, що стосуються виключно
апаратного чи програмного забезпечення.
У табл. 2.1 наведено порівняльну характеристику запропонованої моделі
формування вимог [36] із розглянутими моделями Вігерса та Леффінгвелла.
38
Таблиця 2.1.
Характерні особливості моделей вимог
Запропонована Модель
Модель Вігерса
модель Леффінгвелла
− користувача − бізнес-вимог − потреб
− системи − вимог користувачів − функцій

− функціональний − функціональний − програмних вимог
− апаратні − функціональні –
− програмні − нефункціональні
Користувача,
ПЗ/ПЗ, АЗ/ПЗ, Користувача, ПЗ/ПЗ, Інтерфейс
АЗ/АЗ, ПЗ(АЗ)/ ПЗ/користувач. користувача.
користувач.

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

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

Рис. 2.2. UML-діаграма послідовності етапів методу опрацювання вимог

Далі визначаються системні вимоги з урахуванням середовища
функціонування, а також нефункціональні вимоги (атрибути якості, технічні
обмеження, умови експлуатації, специфікації інтерфейсів). Крім цього,
уточнюються функціональні вимоги для апаратної складової та програмного
40
забезпечення, перетворюючи первинні запити користувачів у форму, придатну
для розробників. На основі отриманих даних здійснюється створення
архітектури системи, а також розподіл вимог між її компонентами. Специфікація
функціональних вимог до програмного забезпечення може виконуватися
шляхом опису очікуваної поведінки системи у формі «подія-реакція», що є
особливо корисним для подальшого тестування. По завершенні кожного етапу
перевіряються специфікації вимог для виявлення можливих помилок, перевірки
повноти, однозначності та несуперечливості. Процес роботи з вимогами є
ітеративним: якщо перший етап зазвичай виконується одноразово (з можливістю
подальших уточнень), то решта кроків повторюється для кожної наступної версії
системи. Матриця трасування, створювана в IBM Rational RequisitePro [44],
забезпечує зручний спосіб визначення вимог, які зазнають впливу при зміні
інших, та тих, що потребують перевірки. Трасування вимог, сформованих
відповідно до моделі розробки в RequisitePro, демонструється на рисунку 2.3.

Рис. 2.3. Трасування вимог у RequisitePro

На верхньому рівні розміщені Потреби зацікавлених осіб (ідентифікатор
цього типу вимог – STRQ), а також Системні вимоги (SYST), які формуються на
основі зазначених потреб. Сценарії використання (UC) описують поведінку
системи у вигляді послідовності дій. Функціональні вимоги є специфікаціям
функціональних можливостей системи, складеними бізнес-аналітиком із метою
задоволення потреб замовника. Ці вимоги (FEAT) розподіляються між різними
41
видами забезпечення проєкту згідно із системними вимогами: FEAT_HW –
функціональні вимоги до апаратного забезпечення; FEAT_SW – функціональні
вимоги до програмного забезпечення. Додаткові вимоги (SUPL) охоплюють
нефункціональні та інші специфікації, що не можуть бути відображені через
сценарії використання. Отже, використання вдосконаленого методу роботи з
вимогами сприяє підвищенню ефективності ключових процесів, таких як
визначення, аналіз і формування вимог до програмних та апаратних компонентів
автоматизованих систем при їх розробці.

2.3. Метод автоматизації проєктування вбудованих систем із
застосуванням технологій віддаленої інженерії
Базуючись на проведених дослідженнях прийнято рішення щодо
доцільності удосконалення існуючих методів проектування вбудованих систем
(рис. 1.5). Запропонований метод паралельного проектування відрізняється
спільним застосуванням паралельного та платформно-орієнтованого підходів
[42, 43], а також методології повторного використання готових програмних і
апаратних рішень [5] та засобів віддаленої інженерії. Удосконалена схема методу
паралельного проектування представлена на рис. 2.4.

Рис. 2.4. Удосконалена схема методу паралельного проектування ВС
42
На основі аналізу, проведеного у розділі 1, було визначено доцільність
удосконалення існуючих підходів до проєктування вбудованих систем.
Запропонований метод паралельного проєктування відрізняється комбінацією
паралельного та платформно-орієнтованого підходів [42, 43], а також
методології повторного використання готових програмних і апаратних рішень
[55, 58] разом із застосуванням засобів віддаленої інженерії. Удосконалена схема
методу паралельного проєктування подана на рис. 2.4.
Застосування платформно-орієнтованого підходу на основі методології
багаторазового використання попередньо розроблених і перевірених
компонентів програмного та апаратного забезпечення дозволяє істотно
скоротити тривалість процесу проєктування.
Удосконалена схема паралельного проєктування передбачає активне
використання технологій віддаленої інженерії, що забезпечує підвищення рівня
автоматизації таких ключових етапів проєктувальних робіт:
− автоматичний вибір апаратно-програмної платформи за допомогою
рекомендаційних методик;
− розробка програмного забезпечення для вбудованих систем із
використанням принципів повторного застосування;
− швидке прототипування майбутньої системи завдяки віддаленим
експериментальним процедурам.
Реалізація технологій віддаленої інженерії включає створення
централізованого серверу, оснащеного всім необхідним програмним
забезпеченням та обладнанням для виконання проєктувальних завдань у межах
автоматичного проєктування (АП). Доступ до цього серверу здійснюється через
Інтернет за допомогою стандартного браузера з будь-якого пристрою
(комп’ютера, планшета чи смартфона). Узагальнена схема реалізації технологій
віддаленої інженерії наведена на рис. 2.5.
Застосування віддалених інженерних технологій дозволяє суттєво знизити
матеріальні витрати на проєктування завдяки оптимізації спільного доступу до
обладнання та програмних інструментів без необхідності їхнього придбання,
43
налаштування чи обслуговування [47]. Це, своєю чергою, сприяє зменшенню
загальних витрат на процес проєктування та зниженню собівартості кінцевої
продукції.

Рис. 2.5. Загальна схема реалізації технологій віддаленої інженерії

Дослідження показали, що різноманітність і розгалуженість описів
існуючих рішень у сфері проєктування вбудованих систем (апаратних і
програмних компонентів, алгоритмів, бібліотек, API, апаратно-програмних
платформ тощо) значно ускладнюють їх повторне використання. Впровадження
технологій віддаленої інженерії дозволяє розробникам швидко оцінювати
можливості готових апаратно-програмних платформ, ухвалювати рішення щодо
їх інтеграції в проєкт, що, у свою чергу, знижує ризики та часові витрати на
процес проєктування.
Застосування технологій віддаленої інженерії надає розробнику такі
можливості:
− доступ до аналізу специфікацій готових апаратно-програмних
платформ;
− вибір оптимальних апаратно-програмних рішень;
− розробку та верифікацію програмного забезпечення;
44
− інтеграцію апаратної та програмної складових вбудованих систем;
− дослідження прототипу проєктованої системи;
− проведення віддалених експериментів на реальному обладнанні з
можливістю спостереження через вебкамеру.
Метод автоматизованого проєктування вбудованих систем, що базується
на технологіях віддаленої інженерії, вирізняється впровадженням
рекомендаційних інструментів і віддалених експериментів. Він може бути
візуалізований за допомогою UML-діаграми, яка представляє послідовність
етапів цього методу.

Рис. 2.6. UML-діаграма методу автоматизованого проєктування вбудованих
систем із використанням технологій віддаленої інженерії

У цьому методі основою є запропонована трирівнева модель формування
вимог до вбудованих систем. Для забезпечення роботи рекомендаційної системи
45
модель необхідно редукувати з урахуванням специфіки кожного проєкту.
Структура моделі включає такі ключові елементи:
− дані про зацікавлених осіб (STRQ);
− формування функціональних вимог до апаратної (Feat_HW) та
програмної частин (Feat_SW);
− визначення нефункціональних вимог (SUPL) і специфікації
використання системи (UC).
Цей підхід забезпечує систематичне та ефективне планування процесу
розробки вбудованих систем, що мінімізує потенційні труднощі та оптимізує
використання ресурсів.
У рекомендованій системі сценарії UC не враховуються, оскільки вони
переважно є описом послідовних дій користувача по відношенню до
проектованої системи або самостійної поведінки системи. Цей тип вимог не
зручний для формування вектору вимог згідно з окремими критеріями. Проте UC
відіграють важливу роль під час верифікації системи, зокрема для складання
протоколів тестування. Таким чином, на етапах проектування вбудованих систем
(ВС) вони можуть враховуватися, хоча безпосередньо у моделі формування
вимог до рекомендованої системи можуть бути опущені.
Для визначення вимог до розробника був створений перелік запитів, які
допомагають сформулювати характеристики необхідної апаратно-програмної
платформи для проектування ВС. Серед ключових запитів:
− рівень знань розробника;
− планована кількість периферійних контактів для підключення
зовнішніх пристроїв;
− переваги щодо певних сімейств процесорів;
− володіння програмними мовами;
− фінансові обмеження тощо.
Відповідь на всі питання не є обов’язковою, але дає можливість точніше
врахувати потреби розробника та підібрати оптимальну апаратно-програмну
платформу.
46
Інформаційна підсистема віддаленої лабораторії забезпечує доступ до
готових рішень: сценаріїв віддалених експериментів, схем підключення сенсорів
і актуаторів, а також фрагментів програмного коду для обраної платформи.
Завдяки цій системі розробник може не лише користуватися стандартними
рішеннями, але й створювати власний код із тестуванням на відсутність помилок.
Процес швидкого прототипування і дослідження прототипу ВС через
платформу віддаленої лабораторії передбачає завантаження відлагодженого
коду на контролер платформи та виконання експериментів відповідно до
визначеного сценарію. Якщо результати дослідження задовольняють очікування,
робота у віддаленій лабораторії завершується. За умови незадовільних
результатів розробнику пропонується повернутися до одного з етапів:
корегувати вимоги, обрати іншу платформу з переліку рекомендацій чи
виправити програму й повторити дослідження.
Таким чином, застосування методу паралельного проектування
вбудованих систем, що базується на поєднанні паралельного та платформно-
орієнтованого підходів, повторному використанні готових апаратних і
програмних рішень і впровадженні засобів віддаленої інженерії, дозволяє
суттєво скоротити час переходу між системним та функціонально-логічним
рівнями у процесі проектування ВС. Це сприяє підвищенню рівня автоматизації
розробки завдяки автоматизованому вибору апаратно-програмної платформи.
Застосування автоматизованого підходу до проектування ВС із
використанням технологій віддаленої інженерії забезпечує спільне використання
як обладнання, так і програмного забезпечення без обов’язкової потреби у їх
придбанні чи налаштуванні. У результаті це знижує собівартість проектованої
продукції й оптимізує ресурсозатрати при створенні вбудованих систем.

2.4. Модель представлення інформації для апаратно-програмних
платформ рекомендаційних систем
Для полегшення пошуку та підвищення ефективності вибору готових
рішень в Інтернеті існують різноманітні рекомендаційні технології. Ці системи
47
спрямовані на прогнозування корисного контенту для конкретного користувача,
засноване на оцінках та вподобаннях інших користувачів зі схожими інтересами,
враховуючи також персональну інформацію, історію поведінки та інші
характеристики. Залежно від підходів до роботи з даними, рекомендаційні
методи поділяються на три основні групи: колаборативна фільтрація
(collaborative filtering), контентна фільтрація (content-based filtering) та
фільтрація на основі знань (knowledge-based filtering). Окрім цього, існує
гібридна фільтрація (hybrid filtering), яка об'єднує методи різних груп для
нівелювання їхніх недоліків. Водночас існують спеціалізовані рекомендаційні
підходи, які орієнтовані на вирішення вузькоспецифічних завдань, однак вони не
придатні для створення рекомендацій щодо вибору апаратно-програмних
платформ.

Рис. 2.7. Класифікаційна схема рекомендаційних методів

Дослідження показують, що колаборативна фільтрація (КлФ) є найбільш
поширеним і популярним методом у комерційних рекомендаційних системах. Її
механізм базується на аналізі реакцій користувачів на об'єкти, таких як оцінки,
вподобання чи коментарі. Існують два основних підходи до розробки систем
колаборативної фільтрації:
48
1. User-Based Collaborative Filtering – побудова рекомендацій базується на
інформації від інших користувачів із подібними інтересами.
2. Item-Based Collaborative Filtering – замість аналізу вподобань
користувачів порівнюються об'єкти рекомендацій на основі їх оцінок.
Колаборативна фільтрація передбачає, що користувачі з подібними
інтересами до одних об’єктів будуть проявляти спільний інтерес і до інших. Для
визначення схожості використовуються такі методи, як косинусна подібність,
евклідова відстань та коефіцієнт кореляції Пірсона. Найбільш популярним
алгоритмом у цьому підході вважається метод k-найближчих сусідів.
Контентна фільтрація, або фільтрація за змістом, на відміну від
колаборативної фільтрації (КлФ), ґрунтується на властивостях рекомендованих
об’єктів та характеристиках користувача (зокрема, його попередніх
вподобаннях), і не враховує вподобання інших користувачів [29]. Цей метод
використовується для надання рекомендацій щодо книг, документів, веб-
сторінок та інших текстових об'єктів. Системи рекомендацій, засновані на
контентній фільтрації, застосовують такі інструменти: опис елементів, що
можуть бути рекомендовані; створення профілю користувача, який відображає
його інтереси; порівняння елементів і профілю користувача для формулювання
рекомендацій. Контентну фільтрацію можна здійснювати за схожими об’єктами
(рекомендації на основі подібності до раніше оцінених елементів) або за
атрибутами (рекомендації відповідно до профілю користувача). Для цього
найчастіше використовуються ключові слова або модель простору векторів
(Vector Space Model). Алгоритм TF-IDF застосовується для виділення ключових
слів у документах [16].
Окремо варто виділити системи, що базуються на знаннях (knowledge-
based systems), які орієнтуються на актуальні потреби користувача [29]. У таких
системах користувач сам формулює свої вимоги, і система, використовуючи базу
знань, шукає об’єкти, що відповідають цим вимогам. До таких систем
відносяться обмежувальні системи (constraint-based systems) та системи,
засновані на виборі подібних об'єктів (case-based systems) [14]. Також існують
49
онтологічні системи (ontology-based systems) [32], які виникли через різницю в
представленні знань різними людьми. Вони прагнуть створити уніфіковану мову
для подальшої роботи з цими знаннями, мінімізуючи концептуальні та
термінологічні непорозуміння.
Гібридна фільтрація (hybrid filtering) [28] комбінує кілька підходів, щоб
усунути недоліки окремих методів і забезпечити найкращі результати.
Колаборативна та контентна фільтрації для надання рекомендацій
засновані на оцінках і рейтингах, які користувачі надають елементам в
минулому. Для цього необхідно організувати опитування користувачів про їхні
вподобання, а також зберігати цю інформацію в системі. Це може бути
незручним для систем, що не зберігають дані про користувачів і їхню поведінку,
працюють з поточними даними та допомагають визначити специфічні вимоги
кожного користувача.
Отже, фільтрація на основі знань зазвичай використовується в системах
одноразового застосування. У таких рекомендаційних системах, заснованих на
методі знань, не зберігається інформація про поведінку користувача або його
оцінки об'єктів, і система орієнтується на поточну потребу користувача, що
відповідає завданню вибору апаратно-програмної платформи для
автоматизованого проєктування вбудованих систем (АП ВС).
Процес розробки бази знань для рекомендаційних систем включає етапи
видобутку, структурування та представлення знань. Виділяють три основні
групи методів видобутку знань: комунікативні методи, текстові методи та
методи видобутку знань з даних (наприклад, з нейронних мереж або дерев
рішень) [17]. Елементами рекомендаційної системи є апаратно-програмні
платформи, інформація про які зберігається в специфікаціях. Для видобутку
знань про ці платформи, крім текстового аналізу специфікацій, ефективними є
також опитування експертів галузі, наприклад, на електронних форумах
(комунікативний метод).
Після видобутку знань їх потрібно структуризувати. Елементи
рекомендаційної системи зазвичай зберігаються в таблицях, де рядки – це
50
елементи, а стовпці – властивості (атрибути, характеристики тощо). Кожен
атрибут має чітко визначене значення. Це приклад структурування даних для
подальшої обробки. Інший варіант збереження – текст у довільному форматі,
проте в такому випадку робота з даними ускладнюється, оскільки одне і те ж
слово може мати різні значення, а два різні слова – однакові значення. Текст
також може бути перетворений на структуровану форму, де кожне слово
розглядається як атрибут з булевим значенням.

Рис. 2.8. Схема фрагменту побудованої семантичної мережі

Наступний етап – представлення знань за допомогою обраної моделі:
семантичні мережі, асоціативні правила, дерева рішень тощо. Семантичні мережі
51
мають такі переваги: наочність знань, великі можливості мережних моделей, а
також невелика та чітко формалізована кількість взаємозв'язків між поняттями
та подіями [17]. Аналіз специфікацій платформ та експертних знань дозволив
виділити основні інформаційні одиниці апаратно-програмних платформ, які
були використані для побудови словника предметної області, а згодом – для
рекомендаційного пошуку. Як результат, створено схему семантичної мережі
знань, що відображає інформацію про апаратно-програмні платформи, фрагмент
якої представлено на рисунку 2.8.
На основі трирівневої моделі формування вимог та з урахуванням аналізу
специфікацій і експертних знань щодо характеристик апаратно-програмних
платформ до бази знань (БЗ) було додано нові інформаційні одиниці. Ці одиниці,
у подальшому іменовані як вимоги, були класифіковані за рівнями та призначені
для забезпечення роботи рекомендаційної системи. Повний список виявлених
вимог представлено в таблиці 2.1.

Таблиця 2.2.
Основні вимоги до рекомендаційної системи
Назва рівня Вимоги
Зацікавлена сторона (Stakeholder) Рівень користувача.
Програмний (Software) Мова програмування.
Кількість аналогових входів; кількість
Апаратний (Hardware) цифрових входів; живлення; сімейство
процесорів.
Додатковий (Supplementary) Ціна платформи; форм-фактор.

Отже, була розроблена модель знань, представленая у вигляді семантичної
мережі, яка містить інформацію про апаратно-програмні платформи. Ця мережа
дозволяє ідентифікувати та організувати основні поняття (атрибути) бази знань,
що робить її ефективним інструментом для розробки бази знань апаратно-
програмних платформ рекомендаційної системи.
52
Висновки
В розділі удосконалено підхід до формування вимог для вбудованих
систем (ВС), що базується на існуючих методах, таких як моделі Вігерса і
Леффінгвелла, а також стандартах, які визначають різні типи вимог.
Запропонована модель охоплює три рівні та два типи вимог: як для системи
загалом, так і для її програмного й апаратного забезпечення.
Такий підхід дозволяє максимально врахувати специфічні особливості ВС
і забезпечити відповідність вимог при автоматизованому проектуванні.
Оновлений метод роботи з вимогами забезпечує ефективну організацію
поетапного визначення, аналізу та формування вимог з урахуванням специфіки
ВС. Розроблено метод автоматизованого проектування вбудованих систем. Він
реалізується через інтеграцію паралельного та платформноорієнтованого
підходів до проектування, використання повторного застосування програмного
та апаратного компонентів і технологій віддаленої інженерії.
У рамках цього методу застосовуються інструменти рекомендаційних
систем і віддалених експериментів. Використання цих інструментів дозволяє
користувачам отримувати та аналізувати інформацію про характеристики
готових компонентів для їх повторного застосування, вибирати відповідні
апаратно-програмні платформи, розробляти програмний код, а також тестувати
прототипи систем на предмет сумісності та працездатності компонентів за
допомогою віддаленої лабораторії та рекомендаційної системи.].
Для функціонування рекомендаційної системи обрано методику на основі
знань, яка відрізняється тим, що не потребує збору та аналізу попередньої
поведінки користувачів чи їх уподобань. Натомість він орієнтований на
актуальні запити користувачів, якими в даному випадку є вимоги до
проектованої вбудованої системи. Створено модель представлення знань у формі
семантичної мережі, яка структуровано передає інформацію про апаратно-
програмні платформи. Ця модель дозволяє визначати ключові поняття та
атрибути бази знань, і може ефективно використовуватися для створення бази
знань рекомендаційної системи таких платформ.
53
РОЗДІЛ 3
ПРОГРАМНО-ТЕХНІЧНИЙ КОМПЛЕКС ДЛЯ АВТОМАТИЗАЦІЇ
ПРОЦЕСУ ПРОЕКТУВАННЯ ВБУДОВАНИХ СИСТЕМ

3.1. Формування рекомендацій для апаратно-програмних платформ
Дослідження показали, що застосування колаборативної та контентної
фільтрації є неприйнятним для розробки системи рекомендацій стосовно
апаратно-програмних платформ. Головною причиною цього є те, що така
система повинна вирішувати специфічні задачі кожного розробника, при цьому
зазвичай не зберігаючи інформації про їхню поведінку чи оцінки. У зв’язку з
цим, для формування рекомендацій було прийнято рішення використовувати
підхід на основі знань, який дозволяє точно задовольняти індивідуальні вимоги.
Методологія створення рекомендацій щодо апаратно-програмних
платформ базується на поєднанні двох основних підходів: методу жорстких
обмежень і методу вибору схожих об'єктів. Ці методи забезпечують гнучкість
системи рекомендацій. Основна ідея полягає в наступному: розробник
формулює свої вимоги до платформи, а система шукає відповідний об’єкт на
основі цих критеріїв. Перший підхід передбачає рекомендацію лише тих
платформ, які строго відповідають заявленим вимогам. Другий підхід дозволяє
рекомендувати платформи із характеристиками, які максимально наближені до
вимог, використовуючи математичні моделі оцінки подібності. Підхід на основі
знань передбачає розподіл критеріїв на "жорсткі" та "гнучкі". Це забезпечує
врахування кожного критерію індивідуально для створення точного результату.
Метод представлено у вигляді UML-діаграми послідовності етапів
(рис. 3.1), що структурно відображає процес формування рекомендацій.
Початковою інформацією для роботи методу є вектор вимог розробника. На
першому етапі система формує множину доступних апаратно-програмних
платформ відповідно до рівня знань користувача, зазначеного у векторі вимог.
Потім виконується відбір платформ за рівнем користувача (жорсткі критерії).
54

Рис. 3.1. UML-діаграма етапів процесу формування рекомендацій щодо
апаратно-програмних платформ

Наступним етапом є обчислення подібності за гнучкими критеріями.
Рівень подібності визначається між вектором вимог розробника та атрибутами
доступних платформ. Якщо гнучкі критерії не зазначено, система повертає
результати відбору, сформовані на попередньому етапі. В іншому випадку для
кожного з конкретних критеріїв застосовуються наступні правила:
− Для критеріїв «кількість аналогових входів» або «кількість цифрових
входів» використовуються методи «більше–краще», які дозволяють
знайти платформи з найкращими показниками.
55
− Для критерію «живлення» застосовується підхід «ближче–краще», що
аналізує результати попереднього етапу.
− Для критерію «ціна» працює принцип «менше–краще», призначений
для вибору більш економічних варіантів.
Оптимальна точність рекомендацій також досягається шляхом
призначення вагових коефіцієнтів різним критеріям.

Таблиця 3.1.
Застосування метрики за критеріями
Назва критерію Клас критерію Метрика Ваговий
коефіцієнт
Рівень користувача Жорсткий Жорстке обмеження 1
Кількість цифрових
входів Гнучкий Ближче-краще, але
не менше 0,2
Кількість аналогових
входів Гнучкий Ближче-краще, але
не менше 0,2
Сімейство процесорів Жорсткий Жорстке обмеження 1
Форм-фактор Жорсткий Жорстке обмеження 1
Ціна Гнучкий Менше-краще 0,7
Мова програмування Жорсткий Жорстке обмеження 1
Живлення Гнучкий Ближче-краще 0,2

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

Рис. 3.2. Пелюсткова діаграма відображення співвідношення вагових
коефіцієнтів критеріїв

У випадку, коли рекомендації відсутні, переходять до опрацювання
результатів за кожним окремим жорстким критерієм. На цьому етапі
застосовується метод багатокритеріального вибору для вирішення
суперечностей між вимогами та визначення найкращої альтернативи за кожним
критерієм. Якщо після аналізу сформована множина платформ дорівнює нулю,
пропонуються такі варіанти:
− Повторити процес формування множини за рівнем знань розробника та
класифікації за гнучкими критеріями. Після цього здійснюється
послідовне або спільне попарне жорстке сортування за критеріями:
сімейство процесорів, мова програмування, форм-фактор платформи.
57
Найкращий результат (за максимальною кількістю відповідностей цим
критеріям) передбачає відбір однієї платформи для кожного параметра.
− Якщо вимоги користувача залишаються надто суперечливими,
виводиться повідомлення про відсутність відповідних платформ з
пропозицією переглянути та скоригувати введені параметри.
Таким чином, розроблений метод дозволяє формувати рекомендації, які
можуть бути інтегровані у систему автоматизованого проектування апаратно-
програмних платформ. Запропонований підхід слугує базою для створення
інструментів підтримки проектувальників при виборі оптимальних рішень для
складних систем.

3.2. Архітектура програмно-технічного комплексу
Основне призначення цього комплексу полягає у створенні прототипів ВС
на базі апаратно-програмних платформ і використанні готових проектних рішень
через інструменти рекомендацій та віддалених експериментів. ПТК реалізовано
у вигляді хмарного сервісу з доступом через Інтернет. Даний програмно-
технічний комплекс повинен забезпечувати кілька основних функціональних
можливостей при автоматизованому проектуванні ВС:
− Надання рекомендацій щодо вибору апаратно-програмних платформ на
основі вимог, введених до проектованої системи;
− Розробка та налаштування керуючого програмного забезпечення для
прототипів ВС;
− Створення і дослідження прототипу ВС за допомогою віддалених
експериментів, які виконуються на експериментальному стенді й
базуються на повторно використовуваних проектних рішеннях.
Архітектура ПТК представлена на рис. 3.3 і включає такі компоненти:
рекомендаційну систему, базу знань (БЗ) апаратно-програмних платформ і
віддалену лабораторію RELDES (Remote Laboratory for Design of Embedded
Systems). Рекомендаційна система взаємодіє з БЗ апаратно-програмних
платформ через запити, які формуються на підставі вимог користувача до
58
системи. Віддалена лабораторія забезпечує взаємодію через послідовний порт з
експериментальним стендом, який складається з набору апаратно-програмних
платформ із підключеними сенсорами та актуаторами. Крім того, лабораторія
надає користувачам доступ до описів готових проектних рішень, представлених
у вигляді схем підключення компонентів і текстів програм.

Рис. 3.3. Загальна архітектура програмно-технічного комплексу

Структура ПТК, описана в джерелі [61], представлена на рис. 3.4 і
складається з основних блоків та модулів, кожен із яких виконує специфічні
функції.
Блок 1. Робота з базою даних. Цей блок відповідає за взаємодію із базою
даних, зокрема виконання різноманітних операцій, таких як: додавання нового
користувача до системи; отримання інформації про користувача за його
унікальним ідентифікаційним номером (id); пошук id користувача за його ім'ям;
резервування експерименту для користувача; перевірка стану доступності
59
експерименту (вільний чи зайнятий); забезпечення коректного завершення
експериментів.
Блок 2. Логіка роботи програми. Основне призначення цього блоку –
управління взаємодією між користувачем і системою. Він відповідає за:
реалізацію інтерфейсу програми; обробку даних та запитів від користувача;
зміну мови контенту; авторизацію та реєстрацію користувачів; організацію
виходу користувача з системи.
Модуль 2.1. Формування і робота з описовими даними. Цей модуль
розробляє головну сторінку системи, сторінки з характеристиками апаратно-
програмної платформи, відповідає за навігацію між сторінками та надає
інформацію за заданими запитами користувача.
Модуль 2.2. Формування і робота з експериментальною частиною. Його
завдання включають забезпечення роботи віддалених експериментів,
формування сторінок для експериментів, створення стрічкового меню для
швидкого переключення між ними, виконання експериментів і резервування їх
під конкретних користувачів.
Модуль 2.3. Формування і робота рекомендаційної системи. Основна
функція цього модуля – розробка та робота рекомендаційної системи, що
включає створення відповідних сторінок і взаємодію з базою знань апаратно-
програмних платформ, використовуючи методику.
Блок 3. Відображення даних для взаємодії з користувачем. Він
спроєктований для побудови html-сторінок, що містять всю необхідну
інформацію для діалогу між користувачем і системою, а також для відображення
результатів запитів до бази даних.
Кожен із блоків і модулів складає логічно завершену частину системи,
забезпечуючи інтеграцію всіх функцій та механізмів задля злагодженої роботи
ПТК у рамках поставлених завдань.
Блок 4. Відображення інформації відповідає за забезпечення користувача
візуальним інтерфейсом системи. Для Блоку 5 це включає створення області для
відображення відео на сторінці експерименту та надання засобів для розробки і
60
тестування коду, яким користувач керуватиме експериментом. У свою чергу, для
Блоку 6 це забезпечення доступу до рекомендацій щодо апаратно-програмної
платформи, а також до додаткової інформації, такої як посилання на сайт
розробника чи технічні характеристики платформи.

Рис. 3.4. Структурна схема програмно-технічного комплексу

Блок 5. Експериментальна частина забезпечує проведення експериментів з
використанням апаратно-програмних платформ, що інтегровані до системи.
Блок 6. Рекомендаційна система відповідає за створення рекомендацій
відповідно до апаратно-програмних платформ, орієнтуючись на введені
користувачем вимоги до ВС.
Модуль 6.1. Робота з вимогами служить для створення поля введення
даних, яке дозволяє користувачу зазначати свої вимоги. Після цього
сформований вектор вимог передається до Модуля 6.2.
Модуль 6.2. Формування рекомендацій здійснює обробку отриманих
вимог із метою пошуку найбільш відповідних рішень щодо апаратно-
програмних платформ та формує результати у вигляді рекомендацій. В
результаті запропоновано архітектуру ПТК і структурну схему, які забезпечують
61
реалізацію необхідних функціональних можливостей системи. Це дозволяє
ефективно використовувати засоби віддаленої інженерії для вирішення завдань
автоматизації проектування ВС.

3.3. Опис характеристик розробки програмно-технічного комплексу
Архітектура віддаленої лабораторії RELDES [51] наведена на рис.3.5 та
організована згідно з принципами архітектури клієнт-сервер. Комунікація між
клієнтом і сервером віддаленої лабораторії здійснюється через веб-інтерфейс.
Стенд з експериментами підключений до лабораторного сервера через
послідовний інтерфейс.

Рис. 3.5. Архітектура віддаленої лабораторії

Комп'ютер з операційною системою Linux Debian працює як сервер
віддаленої лабораторії. Сервер забезпечує доступ до програмування
експериментів та трансляції відео лабораторії. Сервер виконує обробку запитів
веб-клієнта та виконує наступні дії в залежності від отриманих даних: відправка
запиту на компіляцію, а також повернення результатів компіляції програми (за
допомогою HTTP-протоколу); компіляція отриманого початкового коду на
62
стороні сервера [51]; завантаження бінарного файлу до мікроконтролеру (за
умови, що контролер не зайнятий); побудова черги користувачів (якщо
експеримент зайнятий).
Служба працює на сервері Apache з використанням реляційної бази даних
MySQL [60]. Веб-сервер реалізовано на мові програмування PHP5. Такий стек
технологій дозволяє реалізувати всі необхідні функції. Для побудови
необхідного функціоналу використовується фреймворк CodeIgniter та шаблон
MVC (Model–View–Controller, Модель-Представлення-Контролер).
Це популярний фреймворк з відкритим кодом, написаний на мові
програмування PHP для розробки повноцінних веб-систем і зостосунків.
Розроблена на основі MVC шаблону структура віддаленої лабораторії
представлена на рис. 3.6 [58].

Рис.3.6. Структура віддаленої лабораторії на основі шаблону MVC

Контролер виступає посередником між користувачем і системою,
забезпечуючи обробку введених даних, а також використовує Модель і
Представлення для реалізації необхідних реакцій на запити. Він додатково
виконує функції навігації сайту, включаючи такі дії, як index, arduino, experiments
тощо. Технічне оснащення лабораторії складається з експериментального
обладнання, яке можна розглядати як набір повторно використовуваних
63
апаратних рішень для створення вбудованих систем (ВС). Комплекс
експериментів формується з урахуванням різних типів ВС. Для систем
управління роботами (ВС УРО) такі експерименти охоплюють роботу із
сервоприводами, датчиками відстані, світлодіодами, дисплеями тощо. Для
спрощення використання рішень з повторним застосуванням у системах АП ВС
УРО розроблені схеми підключення та шаблони програм (рис. 3.7).

Рис. 3.7. Приклад опису апаратних та програмних рішень на віддаленій
лабораторії

На сьогодні всі експерименти побудовані з використанням апаратно-
програмних платформ Arduino, але система залишається відкритою для
розширення та інтеграції інших платформ. Для запобігання проблемам під час
ініціалізації платформ був створений конфігураційний файл, який призначає
кожній платформі унікальне ім’я на основі ідентифікатора виробника.
Додатково, кожна платформа отримала назву ArduinoN (де N відповідає номеру
експерименту), що значно спрощує адаптацію системи при додаванні нових
платформ. Також для організації доступу до експериментів впроваджена
64
підсистема черги. Вона дозволяє контролювати тривалість експериментів і
функціонує за принципом "перший увійшов — перший вийшов" (FIFO). Це
означає, що користувач, котрий натиснув кнопку «Виконати експеримент»,
додається до черги, а якщо черга порожня, експеримент запускається одразу. У
протилежному випадку активується таймер, який відлічує час очікування
користувача в черзі; після завершення відліку користувач отримує можливість
розпочати виконання експерименту.

Рис. 3.8. Діаграма послідовності роботи підсистеми організації черги

На рисунку 3.8 представлено діаграму послідовності, яка ілюструє хід
подій у процесі функціонування підсистеми організації черги. У разі зайнятості
експерименту активується додатковий таймер, який завершує виділений час
роботи над експериментом. Після спрацювання таймера експеримент
65
автоматично звільняється від поточного користувача і переходить до
обслуговування наступного у черзі.
Створене програмне й технічне забезпечення для віддаленої лабораторії
забезпечує користувачам можливість колективного доступу до обладнання та
програмних засобів, що дозволяє розробляти й тестувати прототипи
проектованих вбудованих систем. Завдяки цьому значно скорочуються як
матеріальні, так і часові витрати на розробку, що, своєю чергою, сприяє
Розроблена архітектура рекомендаторної системи зображена на рис. 3.9. Її
взаємодія з проектувальником здійснюється через веб-інтерфейс. Загалом
система складається з кількох функціональних модулів. Модуль створення веб-
сторінок і Модуль пошуку рекомендацій тісно пов'язані як із веб-інтерфейсом,
так і з базою знань. Модуль створення веб-сторінок відповідає не лише за
генерацію головної сторінки, що описує апаратно-програмні платформи, а й за
формування додаткових сторінок із детальною інформацією про них. Водночас
задачі, пов’язані зі складанням рекомендацій щодо вибору апаратно-програмних
платформ, виконує Модуль пошуку рекомендацій..

Рис. 3.9. Архітектура рекомендаційної системи
66
Робота рекомендаційної системи (РС) спрямована на формування списку
оптимальних апаратно-програмних платформ. Система обирає найбільш
підходящі варіанти з бази знань, враховуючи критерії, задані користувачем під
час взаємодії із системою.
Критерії бази знань для апаратно-програмних платформ були створені на
основі ретельного аналізу їх технічних характеристик, доповненого
результатами опитування фахівців у цій галузі.
Оцінка рівня користувача визначається за сукупністю двох ключових
параметрів: наявності активної спільноти в мережі та складності входження до
етапу розробки.
Розроблений програмно-технічний комплекс (ПТК) був впроваджений при
створенні високоспеціалізованої системи управління рухомими об’єктами (ВС
УРО). Її унікальність полягає у здатності керувати групою рухомих об’єктів,
контролювати параметри (як-от швидкість або рівень заряду акумулятора) і
створювати ефект присутності операторів у зоні дослідження.
Для успішного інтегрування ПТК у процес автоматизованої розробки
системи ВС було розроблено спеціальну методику, яка охоплює такі етапи
проєктування: формування специфікації, розроблення архітектури системи,
вибір апаратно-програмних платформ із використанням рекомендаційної
системи, створення програмного забезпечення та тестування прототипу системи
на основі можливостей віддаленої лабораторії.
Методика використання програмно-технічного комплексу може бути
представлена у вигляді діаграми діяльності [40], як показано на рис. 3.10. Для
доступу до роботи з комплексом користувач повинен бути зареєстрований у
системі. При реєстрації зберігаються логін і пароль користувача в базі даних.
Проектувальник має змогу швидко створити прототип проектованої
системи, використовуючи готові проектні рішення або власні ідеї. Користувач
може завантажити програмний код до мікроконтролера апаратно-програмної
платформи через вебінтерфейс, створивши власний код або завантаживши
шаблон з готовим кодом. Розробник може створювати та редагувати програмний
67
код безпосередньо в вебінтерфейсі, без необхідності використання інструментів
на своєму комп'ютері. Після того як програма відправлена, вона передається на
сервер по HTTP-протоколу, де зберігається в файл і передається на компіляцію.
У разі наявності помилок сервер повертає результати компіляції. Якщо
компіляція успішна, згенерований код завантажується в мікроконтролер
апаратно-програмної платформи, наприклад, Arduino, за допомогою утиліти Ino.

Рис. 3.10. Діаграма діяльності користувача з ПТК
68
Після завершення компіляції та завантаження програми на платформу
Arduino, на клієнтську частину відправляються повідомлення. Використовуючи
Ino, можна отримати детальну інформацію про процес компіляції та
завантаження, що дозволяє легко виявити помилки. У разі успішного виконання
операцій користувач може спостерігати за результатами роботи програми у
відеоексперименті.
Таким чином, користувач може спостерігати реальну роботу обладнання
(апаратно-програмної платформи з підключеними сенсорами та актуаторами) і
оцінювати працездатність прототипу, аналізуючи робочі процеси. Додатково є
можливість вивести робочі параметри і характеристики прототипу на монітор
послідовного порту. Після оцінки прототипу проектувальник може перейти до
етапу розробки та тестування системи.
Таким чином, розроблено методику використання програмно-технічного
комплексу для автоматизованого проектування вбудованих систем управління
рухомими об'єктами, що може бути застосована в інженерному проектуванні для
ефективного впровадження засобів віддаленої інженерії.
Відповідно до вдосконаленого підходу паралельного проектування
автоматизованих систем на наступному етапі була розроблена архітектура
майбутньої системи управління. Вона включає рухомий об'єкт (передбачена
можливість підключення одного, двох або трьох об'єктів), центральний блок
керування (ЦБК) і станцію оператора для кожного об'єкта, як ілюстровано на
рисунку 3.11.
Ключовою особливістю системи є використання ЦБК, який забезпечує
контроль за діями користувачів та станами керованих рухомих об'єктів. Ще
однією важливою складовою є впровадження відеоокулярів для створення
ефекту присутності оператора всередині рухомого об’єкта, що виконує маневри
в досліджуваній зоні. На кожному рухомому об'єкті розташовані: радіопередавач
для зв’язку з ЦБК, камера із відеопередавачем для трансляції зображення на
відеоокуляри оператора, панель індикації, блок живлення та мікроконтролерний
блок із підключеними до нього компонентами. Останній виконує обробку і
69
реалізацію команд, отриманих від центрального блоку. Станція оператора
оснащена джойстиком для управління рухом об'єкта, а також відеоокулярами, які
дозволяють у реальному часі сприймати відеосигнал, переданий із рухомого
об’єкта.
Запропонована архітектура системи управління забезпечує чіткий поділ
між керуючим модулем і периферійними пристроями (сенсорами та
актуаторами). Це надає можливість реалізувати функціонування модуля як на
базі існуючих апаратно-програмних платформ, так і шляхом створення
оригінальних рішень. Такий підхід враховує специфіку використання системи та
фінансово-економічні обмеження, забезпечуючи гнучкість у проектуванні..

Рис. 3.11. Структура вбудованої системи управління рухомими об'єктами (ВС
УРО)

Центральний блок керування (ЦБК) є ключовим елементом системи, що
забезпечує налаштування та контроль за рухомими об'єктами. Це включає
70
прив'язку до відповідного радіоканалу, калібрування положення передніх коліс,
моніторинг швидкості руху, відстані до інших об'єктів та рівня заряду джерела
живлення.

Рис. 3.12. Діаграма послідовності операцій ВС УРО
71
Алгоритм керування для ВС УРО представлений у вигляді UML діаграми
послідовності дій (рис. 3.12). Після включення живлення системи та
завантаження ЦБК, на екрані з'являється поточний стан і режим швидкості
вибраного каналу. За замовчуванням, всі оператори налаштовуються на режим
мінімальної швидкості руху об'єктів. Коли система готова до запуску,
загоряється зелений світлодіод на панелі індикації, що підтверджує активність
рухомого об'єкта.
Далі необхідно натиснути кнопку "Bind" на рухомому об'єкті для активації
режиму прив'язки. Синій світлодіод почне світитися, що вказує на очікування
команди від ЦБК щодо прив'язки радіоканалу до об'єкта. Після вибору каналу та
натискання кнопки прив'язки на панелі ЦБК, синій світлодіод гасне. Якщо
з'єднання з ЦБК втрачається, світлодіод знову загоряється. Після цього система
готова до запуску.
Система використовує радіопередавачі, що працюють у діапазоні LPD
(Low Power Device, 433 МГц), який має високу проникну здатність і стійкість до
перешкод. Це дозволяє ефективно використовувати систему в умовах забудови,
а також зберігає компактність обладнання, що підвищує мобільність і
завадостійкість системи.
Отже, застосування готової апаратно-програмної платформи для
реалізації Модуля керування ЦБК дозволить скоротити час розробки
проекту, а мікроконтролерний блок рухомого об'єкта, для зменшення масо-
габаритних характеристик конструкції, може бути реалізований на
індивідуальній друкованій платі з використанням мікроконтролера.

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

73
ВИСНОВКИ

У дослідженні представлено комплексне розв'язання актуальної проблеми
вдосконалення процесів автоматизованого проектування вбудованих систем
через впровадження інноваційних технологій. Сучасні тенденції розвитку
технологічних галузей висувають дедалі складніші вимоги до проектування
складних технічних систем, що зумовлює необхідність розроблення принципово
нових підходів до оптимізації проектувальних процесів.
Основна мета роботи полягала в грунтовній трансформації традиційних
методик автоматизованого проектування шляхом радикального скорочення
термінів розробки, мінімізації фінансових витрат та суттєвого підвищення рівня
автоматизації проектувальних робіт. Дослідження спрямовано на подолання
низки системних обмежень існуючих методологій проектування, які стримують
інноваційний розвиток вітчизняного технологічного сектору.
Методологічні інновації дослідження включають розроблення унікального
комплексного методу проектування вбудованих систем з використанням
передових технологій. Принципова новизна запропонованого підходу полягає в
можливості спільного використання обладнання та програмного забезпечення
без додаткових капітальних витрат на їх придбання та впровадження. Це
досягається через створення інтелектуальної екосистеми віддаленої колаборації
та прототипування.
Наукова новизна роботи знайшла відображення в удосконаленій моделі
формування вимог, яка принципово відрізняється від існуючих підходів.
Запропонована модель враховує складні структурні особливості вбудованих
систем, забезпечуючи глибокий та всебічний аналіз вимог на різних етапах
проектування. Особливістю розробленого методу є здатність розподіляти вимоги
між апаратними та програмними компонентами з використанням
інтелектуальних алгоритмів.
74
Виключно важливим здобутком є розроблення методу формування
рекомендацій щодо апаратно-програмних платформ на основі інтелектуальних
знань. Запропонований підхід поєднує методи обмежень та подібності об'єктів,
інтегрує складні багатокритеріальні методи аналізу, що дозволяє формувати
обгрунтовані рекомендації навіть у разі наявності суперечливих вимог
замовника.
Практичні результати дослідження демонструють вагомі переваги
запропонованого підходу. Апробація розробленого комплексу в умовах
виробничих підприємств дозволила досягти відчутних покращень: скорочення
витрат часу на розробку та підвищення продуктивності праці проектувальників.
Загальна наукова цінність роботи полягає в комплексному технологічному
рішенні, яке демонструє принципово новий підхід до підвищення ефективності
автоматизованого проектування вбудованих систем через інтеграцію
найсучасніших технологій. Запропоновані методологічні та технологічні
рішення відкривають нові перспективи для вітчизняної інженерної науки,
створюючи потужне підґрунтя для подальших досліджень та інновацій у галузі
проектування складних технічних систем.

75
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ

1. Berger S.A. Embedded Systems Design: An Introduction to Processes, Tools,
and Techniques. CMP Books, 2022. 272 p.
2. Burke R. Hybrid web recommender systems. The Adaptive Web - Methods and
Strategies of Web Personalization / P. Brusilovsky, A. Kobsa, and W. Nejdl
(Eds.). Springer-Verlag Berlin Heidelberg. 2022. P. 377–408.
3. Challenges and solutions for mobile object control system / D. Kravchenko,
O. Kravchenko, A. Parkhomenko, O. Gladkova. Intelligent data acquisition and
advanced computing systems: technology and applications: proceedings of 10th
IEEE international conference, 21-23 September, 2022. Bucharest (Romania),
2022. Р.988–993.
4. Development and application of remote laboratory for embedded systems design
/ A. Parkhomenko, O. Gladkova et al. Remote engineering and virtual
instrumentation: рroceedings of 13th international conference, 25-28 February
2022. Bangkok (Thailand), 2022. P. 69–73.
5. Ebert C. Software: Facts, Figures, and Future. Computer. 2019. Vol. 42(4).
P. 42–52.
6. Embedded Systems: Technologies and Markets. BCC Research. URL:
http://www.bccresearch.com/market-research/information-technology/
embeddedsystems-technologies-markets.html. (Дата звернення: 15.10.2024)
7. Fuzzy models for recommendation systems / Stekh Y., Lobur M., Artsibasov V.,
Glushko O. CAD in Machinery Design – Implementation and Educational
Problems: proceedings of the XXIII Polish-Ukrainian Conference, 10 11
October, 2024. Lviv, 2024. P. 155–159.
8. Gladkova O. Development and practical application of requirements model for
designing embedded systems. Perspective technologies and methods in MEMS
desig: рroceedings of X international conference, 22-24 June 2024. Lviv: NU
«Lviv Polytechnic», 2024. P. 20–22.
76
9. Gladkova O.N. Virtual tools and collaborative working environment in
embedded system design. Remote engineering and virtual instrumentation:
proceedings of XI international conference, 26-28 February, 2024. Porto
(Portugal), 2024. P. 91–93.
10. Huang A. Similarity Measures for Text Document Clustering. NZCSRSC:
procedings of 6th New Zealand Computer Science Research Student
Conference, April, 2022. New Zeland. 2022. P. 49–56.
11. Internet-based technologies for design of embedded systems / A. Parkhomenko,
O. Gladkova et al. Journal of Control Science and Engineering. 2022. Vol.3(2).
P. 55–63.
12. Internet-based Technologies for design of embedded systems / A.Parkhomenko,
O. Gladkova et al. The experience of designing and application of CAD systems
in microelectronics: рroceedings of 13th international conference, 24-
27 February, 2021. Lviv: NU «Lviv Polytechnic», 2021. P. 167–171.
13. Investigation of reuse concepts for embedded systems design / Ya. Zalyubovskiy
// Perspective technologies and methods in MEMS design: proceedings of XII
international conference, 20-24 April, 2023. Lviv: NU «Lviv Polytechnic»,
2023. P.78–80.
14. Leffingwell D. Managing Software Requirements: A Use Case Approach.
Addison-Wesley, 2023. 402 p.
15. Modernization of mobile object control system based on Raspberry Pi and
Arduino platforms / A. Parkhomenko, O. Kravchenko, D. Kravchenko,
O. Gladkova. Embedded systems and trends in teaching engineering:
рroceedings of the international symposium, 12-15 September, 2023. Nitra
(Slovakia): Constantine the Philosopher University, 2023. P. 249–253.
16. O’Mahony M.P. An Evaluation of the Performance of Collaborative Filtering.
Artificial Intelligence & Cognitive Science: proceedings of 14th Irish
Conference, 19 December, 2023. P. 171–175.
17. Parkhomenko A. Investigation of peculiarities of analysis of system and software
requirements for designing automated system. The experience of designing and
77
application of CAD systems in microelectronics: proceedings of
XII international conference, 19-23 February 2023. Lviv: NU «Lviv
Polytechnic», 2023. P. 268–270.
18. Parkhomenko A. Investigation of peculiarities software development for
embedded systems. Modern Problems of Radio Engineering,
Telecommunications, and Computer Science: proceedings of XII-th
international conference, February 25–March 1, 2024. Lviv-Slavske, Ukraine,
2024. P.382–383
19. Parkhomenko A., Gladkova O. Analysis and application of existent approaches
in microcontroller system designing. Perspective technologies and methods in
MEMS design: рroceedings of IX international conference, 16-20 April 2023.
Lviv: NU «Lviv Polytechnic», 2023. P. 59–61.
20. Parkhomenko А. Complex requirements analysis for the high-level design of
Embedded Systems. Вісник НУ «Львівська політехніка». Серія
«Комп’ютерні системи проектування. Теорія і практика». 2024. № 808.
С. 3–9.
21. Path finding algorithm for moving robots and obstacles avoidance / S. Boeckx,
P. Pelgrims, et al. Ambient intelligence and embedded systems: proceedings of
the international symposium, 14-16 September, 2023. Vaasa (Finland). URL:
http://amies-2023.internationalsymposium.org/proceedings.html. (Дата
звернення: 15.10.2024).
22. Pazzani J.M., Billsus D. Content-Based Recommendation Systems. The
Adaptive Web - Methods and Strategies of Web Personalization /
P. Brusilovsky, A. Kobsa, and W. Nejdl (Eds.). Springer-Verlag Berlin
Heidelberg. 2022. P. 325–341.
23. Platform-based design and development: current trends and needs in industry /
T.W. Simpsonand, T. Marion et al. International Design Engineering Technical
Conferences & Computers and Information in Engineering Conference:
proceedings of conference, 10-13 September, 2022. Philadelphia, Pennsylvania,
USA, 2022. P. 1–10.
78
24. Recomender Systems: Handbook / Ricci F., Rokach L., Shapira B., Kantor P.B.
Springer Science+Business Media, LLC. 2021. 845 p.
25. Recommender Systems. An Introduction / D. Jannach, M. Zanker, A. Felfernig,
G. Friedrich. Cambridge University Press, 2021. 352 p.
26. Reusable solutions for embedded systems’ design / A. Sokolyanskii // Remote
engineering and virtual instrumentation: proceedings of 13th international
conference, 24-26 February, 2021. Madrid (Spain), 2021. P. 313–317.
27. Sahaida P. Development of methodology for data and knowledge warehouse
design in computer systems for intellectual data processing / P. Sahaida //
Technology audit and production reserves. Information and Control Systems. –
2022. – Vol 1. – No 2(39). – P. 10-15.
28. Shaikh M.Sh. An improved semantic similarity measure for document clustering
based on topic maps. Cornell University Library. URL:
https://arxiv.org/ftp/arxiv/papers/4087.pdf. (Дата звернення: 15.10.2024).
29. System-Level Design: Orthogonalization of Concerns and PlatformBased
Design / Keutzer K., Malik S., Richard Newton A., Rabaey M.J., Sangiovanni
Vincentelli A. IEEE transactions on computer-aided design of integrated circuits
and systems, 2020. Vol.19(12). P.1523–1543.
30. Tarus K.J., Niu1 Z., Mustafa G. Knowledge-based recommendation: a review of
ontology-based recommender systems for e-learning. Artificial Intelligence
Review. 2022. P. 1–28.
31. Teich J. Hardware/Software Codesign: The Past, the Present, and Predicting the
Future. IEEE: proceedings of the IEEE, May 13, 2022. Germany, 2022. Vol.100.
P. 1411–1429.
32. The Grid of Online Laboratory Devices Ilmenau (GOLDi). URL:
http://www.goldi-labs.net. (Last accessed: 15.10.2024).
33. The New Embedded System Design Methodology For Improving Design
Process Performance / M. Abdurohman, Kuspriyanto, S. Sutikno, A. Sasongko.
International Journal of Computer Science and Information Security. 2020.
Vol. 8(1). P. 35–43.
79
34. WEBENCH® Design Center. Texas Instruments. URL:
http://www.ti.com/lsds/ti/analog/webench/overview.page. (Дата звернення:
15.10.2024).
35. Wiegers K.E. Software Requirements: 2nd Edition. Microsoft Press, 2023.
544 p.
36. Wolf H.W. Hardware-Software Co-Design of Embedded Systems. IEEE:
proceedings of the IEEE, July 2024. Germany, 2024. Vol.82(7). P. 967–989.
37. Гладкова О.М. Дослідження та практична реалізація рекомендаційної
системи для вибору апаратно-програмних платформ при
автоматизованому проектуванні вбудованих систем. Наукові праці
ДонНТУ. Серія «Інформатика, кібернетика та обчислювальна техніка».
2022. №2(25). С. 22–31.
38. Гладкова О.М. Підходи та особливості проектування RESTful API.
Тиждень науки – 2022: тези доп. щоріч. наук.-практ. конф. викладачів,
науковців, молодих учених, аспірантів, студентів ЗНТУ, 18–22 квіт. 2022 р.
Запоріжжя: ЗНТУ, 2022. С. 562–564.
39. Дослідження та розробка автоматизованої системи віддаленого керування
групою рухомих об’єктів / А.В. Пархоменко, О.М. Гладкова,
О.П. Кравченко, Д.П. Кравченко. Вісник СНУ ім. В. Даля. 2023. №8(238).
С. 67– 74.
40. Євстіфєєв В.О. Теорія автоматичного керування. Частина перша.
Безперервні лінійні та нелінійні системи: Навчальний посібник. –
Кременчук: ПП Щербатих О.В., 2019. – 288 с.
41. Кір’янов О.Ф. Проектування відкритих систем управління технологічними
об’єктами. – Кременчук.: КДПУ, 2020. – 275 с.
42. Куланов С.О. Застосування математичного апарата теорії систем масового
обслуговування для оцінки вартісних показників GRID-систем. Вісник
Харківського національного університету Серія «Математичне
моделювання. Інформаційні технології. Автоматизовані системи
управління». 2023. Вип. 780. – С.143-150.
80
43. Куланов С.О. Застосування математичного апарата теорії систем масового
обслуговування для оцінки вартісних показників GRID-систем. Вісник
Харківського національного університету Серія «Математичне
моделювання. Інформаційні технології. Автоматизовані системи
управління». 2020. Вип. 780. – С.143-150.
44. Лобур М.В. Особливості проектування вбудованих систем. Вісник НУ
«Львівська політехніка» № 501. Комп’ютерні системи проектування.
Теорія і практика. 2024. C. 69–75.
45. Математичні методи моделювання : навчальний посібник / О.П. Чорний,
В.К. Титюк, Н.М. Істоміна та ін.; заг. ред. О.П. Чорний. – Кременчук :
ПП Щербатих О.В., 2019. – 234 с.
46. Пархоменко А. Інтерактивна віддалена лабораторія дослідження апаратно-
програмних платформ. Інтернет-Освіта-Наука-2024: тези доповіді
міжнародної науково-практичної конференції, 14-17 жовтня 2024 р.
Вінниця: ВНТУ, 2024. С. 111–113.
47. Рябошлик В. Огляд сучасних технологічних проривів і нових перспектив.
Економіст. – 2019.– № 6. С. 17–22.
48. Рязанцев О.І. Застосування програмної бібліотеки алгоритмічних
елементів для проектування технологічних схем промислової
автоматизації. Комп’ютерно-інтегровані технології: освіта, наука,
виробництво. – Луцьк: ЛНТУ, 2021. – № 23. – С. 98-104.
49. Сагайда П.І. Компоненти комп'ютерних систем інтелектуальної обробки
даних на основі категоріально-онтологічних моделей / П.І. Сагайда,
А.А. Зорі. – Краматорськ : ДДМА, 2019. – 159 с.
50. Субботін С. О. Подання й обробка знань у системах штучного інтелекту та
підтримки прийняття рішень: навчальний посібник. Запоріжжя: ЗНТУ,
2022. 341 c.
51. Троханяк В. І. Застосування методу кінцевих елементів при побудові сітки
в Ansys Meshing для CFD моделей / В. І. Троханяк, Ю. О. Богдан. // ДВНЗ
«ПДТУ». – 2019. – №30. Т.2. – С. 181–189.
81
52. Троханяк В. І. Побудова сітки ANSYS Meshing для CFD моделей методом
кінцевих елементів / Троханяк В.І. ‒ Науковий вісник НУБіП України
"Техніка та енергетика АПК". – К.: ВЦ НУБіП України, 2019. – № 209, ч.2.
– С. 244–249.
53. Шаховська Н.Б., Тарасов Д.О. Особливості інтеграції даних
інформаційних систем Національного університету «Львівська
політехніка». Складні системи і процеси. – 2019. №2. С. 98-109.

ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets