Методичні вказівки до виконання курсової роботи з дисципліни “Програмна інженерія в системах управління”

Редакція 2026 року

Вступ

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

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

1. Мета і завдання курсового проектування

Мета курсової роботи – зміцнення і поглиблення теоретичних знань з дисципліни “Програмна інженерія в системах управління” а також набуття практичних навичок в розробці проектів IoT-рішень та впровадженні їх частин в умовах командної роботи.

Курсова робота передбачає розробку проекту та впровадження його частин для IoT рішення в різноманітних областях життєдіяльності людини, у тому числі автоматизація будинків, будівель, ЖКХ, транспорті, торгівлі, дозвіллі і т.д. У якості класичного прототипу структури IoT-рішення розглядається система, яка включає в себе наступні апаратні частини:

• Raspberry PI у якості центрального компоненту системи
• підключену до GPIO периферію - датчики, виконавчі механізми, інші елементи
• за необхідності інші пристрої, підключені через цифрові шини GPIO, USB або Ethernet
• додаткові матеріали та монтажні компоненти
• мобільні пристрої (смартфони, планшети, тощо)
• шлюзи, маршрутизатори для виходу в Інтернет
• інші компоненти за необхідності

рис.1. Типова структура системи IoT для курсового проекту

Передбачається, що в класичній структурі будуть застосовуватися наступні програмні компоненти:

• Node-RED у якості середовища програмування для Raspberry PI та надання Веб-інтерфейсу
• MariaDB у якості реляційної бази даних для збереження інформації
• Google Sheet або віддалену базу даних (наприклад PostgreSQL у сервісів redis) у якості зберігання даних для звітності в Інтернеті
• Discord у якості месенжера для взаємодії з системою
• мобільні браузери та застосунки для роботи з MQTT

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

2. Тематика курсових робіт

Умовно теми курсових робіт можна розділити на кілька типів:

• розробка системи віддаленого контролю та керування об’єктом
• розробка прототипу установки керування
• спеціальна тема що стосується розробки програмного компоненту або комплексу

Також можлива тема що стосується підготовки нового компоненту для навчального курсу.

Перелік орієнтовних тем курсових робіт даний за посиланням

3. Порядок видачі завдання на курсову роботу

Протягом перших двох тижнів семестру здобувач повинен вибрати і затвердити тему та сформувати приватний репозиторій GitHub, в якому вписати тему.

4. Зміст курсової роботи та послідовність виконання

Структура роботи по розробці IoT рішень має наступний вигляд:

Вступ

1) Розробка вимог до системи та ПЗ. 1.1. Загальний опис проектованої системи. 1.2. Вимоги до функцій та задач. 1.3. Вимоги до видів забезпечення.

2) Розробка архітектури та необхідної проектної документації. 2.1. Технічна структура системи (структура комплексу технічних засобів). 2.2. Принципові схеми та схеми підключення. 2.3. Відомість та опис апаратних засобів. 2.4. Програмна структура системи.

3) Методика перевірки та засоби тестування. 3.1. Методика перевірки підсистеми Edge-рівня. 3.2. Методика перевірки функцій архівування. 3.3. Методика перевірки аналітичних сервісів. 3.4. Методика перевірки діалогових сервісів. 4) Розробка та налагодження програмного забезпечення та супровідної документації. 4.1. ПЗ для Edge-рівня. 4.2. Схеми інформаційної взаємодії 4.3. ПЗ для хмарних рішень 4.4. WEB-інтерфейси (локальний для Edge та глобальний)

5) Список використаних джерел.

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

Орієнтовний календарний графік для виконання курсових робіт по розробці IoT рішень має вигляд як в таблиці 1.

Таблиця 1. Календарний графік виконання курсової роботи

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

Далі послідовність робіт може відбуватися в тому порядку, який наведено в таб.1.

5. Вказівки до виконання окремих розділів роботи

Вступна частина та список використаних джерел

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

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

Розділ 1. Розробка вимог до системи та ПЗ

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

1. Загальний опис проектованої системи.
2. Вимоги до функцій та задач.
3. Вимоги до видів забезпечення.

У загальному описі проектованої системи вказується кілька речень для того щоб описати функціональність системи без деталізації. Наприклад:

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

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

Система повинна передбачати виконання наступних функцій:

1. неперервне вимірювання відстані до об’єкту (в сантиметрах) з періодичністю не більше ніж 1 секунда
2. індикація відстані через інтенсивність світіння світлодіоду
3. відображення плинного значення відстані до об’єкту на локальному WEB-інтерфейсі та віддалено за допомогою Телеграм-бота та мобільного застосунку:
   • на локальному WEB-інтерфейсі та мобільному застосунку періодично, 1 раз/сек у вигляді кругової діаграми і числового значення в сантиметрах;
   • у Телеграм-боті передбачити режими: відображення по запиту плинного значення; включення/відключення періодичного оповіщення 1 раз/5 секунд за командою;
4. архівування значень відстані до об’єкту в локальну базу даних середнє за останні 10 секунд
5. відображення розміщення об’єкту у вигляді трендів за останні 60 секунд на:
   • локальному ВЕБ-інтерфейсі
   • мобільному застосунку
   • Google Worksheet
6. оповіщення через Телеграм-бот та пошту, якщо відстань менше заданої уставки
7. формування звітів на Веб-сайті раз/годину або за запитом з відображенням:
   • у табличному та графічному вигляді відстань за останню годину
   • показники мінімальної/максимальної та середньої відстані до об’єкту

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

Приклад вимог до апаратного забезпечення:

Необхідно використання наступних засобів:

• Raspberry PI5, або аналогічний
• датчики наближення від 0 до 2 метрів
• наявне підключення RPI до мережі Internet через мережу WiFi або Ethernet
• смартфон або планшет з Android > V5
• прототип буде знаходитися у кімнатних умовах

Приклад вимог до програмного забезпечення та Інтернет-сервісів:

Необхідне використання наступних програмних засобів:

• Node-RED як база для розробки ПЗ + dashboard для локального веб-інтерфейсу
• система керування базами даних, розгорнута на RPI (MariaDB)
• хмарний застосунок Google Sheets для аналітики
• веб-сайт для онлайн доступу для звітів на базі Google Sites
• Telegram-бот для віддаленого контролю та керування
• IoT MQTT Panel для віддаленого контролю та керування

Розділ 2. Розробка архітектури та необхідної проектної документації

Усі рішення які стосуються вибору технічних та програмних компонентів та їх взаємодії описуються саме в цьому розділі. У класичному варіанті роботи розділ складається з 4-х підрозділів:

2.1. Технічна структура системи (структура комплексу технічних засобів). 2.2. Принципові схеми та схеми підключення. 2.3. Відомість та опис апаратних засобів. 2.4. Програмна структура системи.

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

Для початку розробляють технічну структуру системи. Приклад дуже простої технічної структури показаний на рис.4.

рис.4. Приклад технічної структури системи

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

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

Структурна схема слугує тільки для вибору компонентів і представлення загального технічного рішення.

Усі необхідні компоненти та матеріали вписуються у відомість апаратних засобів з посиланням на місце їх опису в доступних інформаційних ресурсах.

Таб.2. Приклад відомості апаратних засобів

Вибраний технічний засіб відповідно до варіанту необхідно описати у цьому розділі. Наприклад, нижче наведений опис ультразвукового датчика відстані HC-SR04.

Ультразвуковий датчик HC-SR04 - це стабільний та точний ultrasonic sonar (сонар) датчик відстані який не має “сліпих зон”. Може вимірювати відстань від 0 см до 1500мм, точність досягає 3 мм.

рис.7. Зовнішній вигляд датчика HC-SR04 з різних боків

​ Характеристики

• Робоча напруга: 3.8 - 5.5В
• Тип: HC-SR04
• Струм: 8 мА
• Частота: 40 кГц
• Максимальна дистанція: 1500 мм
• Мінімальна дистанція: 0 см
• Роздільна здатність: 3 мм
• Ширина імпульсів: 10 мкс
• Кут: 15 градусів
• Зовнішні габарити: 37x20x15 мм

​ Рекомендується додатково кронштейн для кріплення.

​ Принцип роботи

1. На вихід trig (тригер) посилаємо високий рівень протягом як мінімум 10мкс

2. Модуль починає посилати ультразвукові імпульси з частотою 40 кГц і приймає їх назад, якщо в зоні видимості є будь-які перешкоди

3. Якщо сигнал повертається, модуль встановлює низький рівень на виході echo на 150мс. За часом, який минув з п.1 до низького рівня на виході echo можна розрахувати відстань до перешкоди за формулою:

Відстань = (time * sound velocity)/2

де time - виміряний час імпульсу, sound velocity - швидкість звуку (340 м/с)

У цьому розділі також наводиться перелік програмного забезпечення для кожного апаратного компонента та опис його призначення. Нижче наведений приклад такого переліку:

ПЗ Raspberry PI

• операційна система: Raspbian
• VNC Server
• СКБД MariaDB
• середовище Node.JS
• середовище Node-RED
• модулі Node-RED: …

Хмарні застосунки та сервіси

• Google Sites
• Telegram
• Google Sheet

ПЗ для Android (для смартфона користувача)

• IoT MQTT Panel
• будь-який браузер
• Телеграм-клієнт

У переліку вказуються модулі Node-RED, які необхідно встановлювати для даного рішення.

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

Розділ 3. Методика перевірки та засоби тестування

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

Методика може включати кілька частин:

1. Методика перевірки підсистеми Edge-рівня.
2. Методика перевірки функцій архівування.
3. Методика перевірки аналітичних сервісів.
4. Методика перевірки діалогових сервісів.

Методика перевірки підсистеми Edge-рівня передбачає перевірку роботи усіх функцій, які не стосуються взаємодії з Інтернетом.

Слід зауважити, що при перевірці можуть бути відсутні усі або частина апаратних засобів. Наприклад може бути відсутній Raspberry PI або датчики. У цьому випадку, в програмі повинен бути передбачений особливий режим роботи для тестування, а в методиці повинен бути описаний механізм його використання.

Нижче наведений приклад методики:

Методика перевірки Edge-рівня передбачає окрему перевірку функцій:

• функцій вводу/виводу
• функцій відображення та керування на локальному Веб-інтерфейсі
• функцій архівування в локальну базу даних
• функцій взаємодії з зовнішніми сервісами за застосунками

Перевірка функцій архівування описана в наступному підрозділі. Перевірка функцій взаємодії з зовнішніми сервісами за застосунками проводиться разом з перевіркою відповідних функцій.

Перевірка функцій вводу виводу

• використовуючи вивід в налагоджувач перевіряється, що при зміні положення об’єкту у вікні Node-RED відображається коректні значення з періодичністю 1 секунда
• використовуючи вузол inject задаючи необхідну потужність перевіряється чи змінюється інтенсивність світіння індикаторного світлодіоду

Перевірка функцій відображення та керування на локальному Веб-інтерфейсі

• використовуючи вузол inject задаючи необхідне значення відстані, воно повинно відображатися у полі
• повинна бути передбачена окрема закладка у локальному Веб-інтерфейсі для налагодження:
  • перемикач імітація/реальний об’єкт для можливості вибору джерела даних (з датчиків або імітоване)
  • повзунками для імітації значення наближення, або задаванням значення в полі, необхідно задати імітоване значення, яке повинно відобразитися на полі відображення відстані
• при зміні значення уставки мінімального значення наближення нижче дійсного повинно з’явитися повідомлення “Об’єкт надто близько!”, при поверненні в норму, напис повинен щезнути
• імітуючи зміну значення наближення проконтролювати що графік (тренд реального часу) правильно показує цю зміну

Розділ 4. Розробка та налагодження програмного забезпечення та супровідної документації

У цьому розділі варто описати програмне забезпечення та усі програмні компоненти. Він може включати наступні частини:

1. ПЗ для Edge-рівня.
2. Схеми інформаційної взаємодії
3. ПЗ для хмарних рішень
4. WEB-інтерфейси (локальний для Edge та глобальний)

Приклад деяких фрагментів наведений нижче.

ПЗ для Edge-рівня

ПЗ розроблено в середовищі Node-RED, яке запускається автоматично з запуском Raspberry PI.

Застосунок включає кілька потоків (Flow):

• IO для обробки значень входів та керування виходами
• process для обробки і імітації змінних
• History для роботи з локальною базою даних для збереження даних
• Alarm для роботи з тривогами
• UI для роботи з локальним ВЕБ-інтерфейсом
• Bot для роботи з чат-ботом Telegram
• Report для формування звітів та взаємодії з Google Sheet

Система передбачає взаємодію через глобальні контексти Noe-RED. Передбачено наступні глобальні контексти:

• RTDB - для збереження конфігураційних та плинних даних вимірювання та керування та трендів на останню хвилину
• ALM - для збереження конфігураційних даних для налаштування тривог та стану тривог
• RPRT - для збереження буферу для формування звітів

ПЗ для хмарних рішень

• Налаштування Google Sheet
• Налаштування Telegram

WEB-інтерфейси (локальний для Edge та глобальний)

• зовнішній вигляд локального WEB-інтерфейсу
• опис потоку UI
• зовнішній вигляд та опис інтерфейсу глобального Веб-інтерфейсу

6. Вимоги до оформлення розрахунково-пояснювальної записки і графічної частини роботи

• усі проекті файли оформлюються у форматі MarkDown, у якості редактору пропонується Typora
• рисунки надаються в PNG (схеми), JPG (малюнки) або SVG
• усі частини проекту повинні бути завантажені на GitHub
• після підтвердження, проект оформлюється в один файл формату PDF або DOCX

7. Порядок захисту курсової роботи

Після здачі проекту на перевірку, назначається час захисту. Здобувач демонструє результати роботи за методикою перевірки.

1. Поясніть роботу системи за технічною та програмною структурою.
2. Поясніть принцип роботи пристрою (вказати).
3. Поясніть принципи роботи програмного компоненту.
4. Як відбувається зв’язок між програмними компонентами?
5. Які є функції інформаційного захисту в проекті і як вони реалізовані?
6. Як функціонує протокол (вказати)?
7. Які бібліотечні компоненти використані і чому саме вони?
8. Як реалізована взаємодія між різними апаратними засобами?

8. Рекомендована література

Базова

1. Пупена, О. М. Довідник з розроблення застосунків в середовищі NODE-RED [Електронний ресурс] : електронний довідник/О. М. Пупена; Національний університет харчових технологій. – Київ : НУХТ, 2021. – 170 с. – № 100.115

2. Лавріщева К.М. Технологія програмування інформаційних систем: методи, засоби, інструменти [Текст] / К. М. Лавріщева, М. С. Нікітченко, Л. Л. Омельчук ; підручник. — Київ. нац. ун-т ім. Т. Шевченка. — Київ : Київ. ун-т, 2015. — 367 с.

3. Основи програмування та алгоритмічні мови [Електронний ресурс]: навч. посіб. / С. В. Грибков, О. Л. Сєдих. — Київ: НУХТ, 2019. — 475 с.

4. Промислові мережі та інтеграційні технології в автоматизованих системах: навч. посіб./ О.М. Пупена, І.В.Ельперін, Н.М.Луцька, А.П.Ладанюк – К.: Ліра-К, 2011. – 552 с.

Допоміжна

1. Алгоритмізація та програмування [Текст]: курс лекцій для студ. спец. 7.092501, 7.092502 “Автоматизоване управління технологічними процесами”, “Комп’ютерно-інтегровані технологічні процеси та виробництва” заоч. форми навч. / Л. Ю. Маноха, Н. Н. Бровченко ; Нац. ун-т харч. технол. — К.: НУХТ, 2007. — 115 с.

2. Основи програмування та алгоритмічні мови [Електронний ресурс]: лабораторний практикум для здобувачів освітнього ступеня «Бакалавр» спеціальності 122 «Комп’ютерні науки» денної та заочної форм навчання / уклад. С.В. Грибков, О.Л. Сєдих, К.Є. Бобрівник. – К.: НУХТ, 2018. – 443 с.