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

КОСЕНКО, Андрій
Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал: https://er.chdtu.edu.ua/handle/ChSTU/9418
Назва:	Дослідження і синтез автоматизованої системи зберігання та передавання показників лічильників до комунальних служб
Автори:	ТАЗЕТДІНОВ, Валерій КОСЕНКО, Андрій
Ключові слова:	АВТОМАТИЗОВАНА СИСТЕМА;WEB-ДОДАТОК;МАТЕМАТИЧНА МОДЕЛЬ;ФРЕЙМВОРК;БАЗА ДАНИХ;ІНТЕРФЕЙС КОРИСТУВАЧА;ЕКРАННЯ ФОРМА;ТЕХНОЛОГІЇ ПРОГРАМУВАННЯ
Дата публікації:	2022
Короткий огляд (реферат):	Кваліфікаційна робота магістра присвячена дослідженню і синтезу автоматизованої системи зберігання та передавання показників лічильників до комунальних служб. Пояснювальна записка містить 72 сторінки, використано 21 джерело. Метою кваліфікаційної роботи магістра дослідження та синтез автоматизованої системи зберігання та передавання показників лічильників до комунальних служб. Кваліфікаційна робота магістра складається з 3 розділів. В першому розділі розглянуто питання формування облікових даних про комунальні послуги з використанням автоматизованих лічильників енергоресурсів В другому розділі побудовано модель автоматизованої системи зберігання та передавання показників лічильників до комунальних служб. В третьому розділі виконано синтез автоматизованої системи зберігання та передавання показників лічильників до комунальних служб. В четвертому розділі досліджено спроектовану автоматизовану систему зберігання та передавання показників лічильників до комунальних служб. В рамках роботи використано та засвоєно сучасні технології розробки програмного забезпечення.
URI (Уніфікований ідентифікатор ресурсу):	https://er.chdtu.edu.ua/handle/ChSTU/9418
Розташовується у зібраннях:	123 Комп’ютерна інженерія (Комп'ютерні системи та мережі)
Файли цього матеріалу:
Файл	Опис	Розмір	Формат
1_ТИТУЛКА+4_РОБОТА_Косенко-merged.pdf Restricted Access		1.34 MB	Adobe PDF	Переглянути/Відкрити Запит копії
Показати повний опис матеріалу Перегляд статистики
Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ
КАФЕДРА ІНФОРМАЦІЙНОЇ БЕЗПЕКИ ТА КОМП’ЮТЕРНОЇ
ІНЖЕНЕРІЇ
Пояснювальна записка
до кваліфікаційної роботи магістра
на тему: «Дослідження і синтез автоматизованої
системи зберігання та передавання показників
лічильників до комунальних служб»
ЧДТУ.222284.001 ПЗ
Виконав: студент 2 курсу, групи МКМ-2105
спеціальності 123 – Комп’ютерна інженерія
за освітньою програмою – Комп’ютерні системи та
мережі
Андрій КОСЕНКО
Керівник
к.т.н., доцент
Валерій ТАЗЕТДІНОВ
Н. контроль
Світлана ГРЕСЬКО
Рецензент
к.т.н., доцент
Марія ЗАХАРОВА
«ЗАХИСТ ДОЗВОЛЯЮ»
Завідувач кафедри ІБ та КІ
д.т.н., професор ______ Володимир РУДНИЦЬКИЙ
Черкаси 2022 року
Форма № Н-9.01
Черкаський державний технологічний університет
Факультет інформаційних технологій і систем
Кафедра інформаційної безпеки та комп‘ютерної інженерії
Освітньо-кваліфікаційний рівень Магістр
Спеціальність 123 – Комп’ютерна інженерія
Освітня програма Комп’ютерні системи та мережі
«ЗАТВЕРДЖУЮ»
Завідувач кафедри _____ Володимир РУДНИЦЬКИЙ
«20» жовтня 2022 року
ЗАВДАННЯ
на кваліфікаційну роботу магістра студенту
Косенку Андрію Віталійовичу
(прізвище, ім‘я, по батькові)
1. Тема роботи: Дослідження і синтез автоматизованої системи зберігання та
передавання показників лічильників до комунальних служб
Керівник роботи к.т.н., доцент Тазетдінов Валерій Абударович
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом університету від «14» жовтня 2022 року № 275/04
2. Строк подання студентом роботи «01» грудня 2022 року
3. Вихідні дані до роботи:
Створити та дослідити систему, за допомогою якої буде можливо передавати показники
лічильників до комунальних та інших підприємств та переглядати історію передач
показань за попередні періоди.
Можливість користування системою забезпечити як для веб-пристроїв за допомогою браузера,
так і за допомогою мобільного додатку для мобільних пристроїв з операційними
системами iOS та android.
4. Зміст розрахунково-пояснювальної записки (перелік питань, що їх належить розробити):
Вступ
Розділ 1 Побудова моделі автоматизованої системи зберігання та передавання показників
лічильників до комунальних служб
Розділ 2 Синтез автоматизованої системи зберігання та передавання показників
лічильників до комунальних служб
Розділ 3 Дослідження автоматизованої системи зберігання та передавання показників
лічильників до комунальних служб
Висновки
Список використаних джерел
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень, плакатів):
6. Консультанти розділів роботи
Підпис, дата
Розділ Прізвище, ініціали та
посада завдання видав завдання прийняв
консультанта
7. Дата видачі завдання 20 жовтня 2022 року
КАЛЕНДАРНИЙ ПЛАН
№ з/п Назва етапів кваліфікаційної роботи магістра Строк виконання
етапів роботи Примітка
1 Вибір теми та керівника кваліфікаційної роботи 20.10.22-01.11.22 Виконано
2 Написання пунктів плану та обговорення їх з
керівником 02.11.22-04.11.22 Виконано
3 Початок роботи, постановка задач 05.11.22-07.11.22 Виконано
4 Аналіз концепції побудови автоматизованої
системи 08.11.22-10.11.22 Виконано
Побудова моделі автоматизованої системи
5 зберігання та передавання показників лічильників 11.11.22-14.10.22 Виконано
до комунальних служб
Синтез автоматизованої системи зберігання та
6 передавання показників лічильників до 15.11.22-20.11.22 Виконано
комунальних служб
Дослідження автоматизованої системи
7 зберігання та передавання показників лічильників 21.11.22-27.11.22 Виконано
до комунальних служб
8 Оформлення пояснювальної записки 28.11.22-30.11.22 Виконано
9 Подання роботи на рецензування 01.12.22 Виконано
Студент-магістрант ____________________________ Андрій КОСЕНКО
(підпис)
Керівник роботи ____________________________ Валерій ТАЗЕТДІНОВ
(підпис)
АНОТАЦІЯ
Кваліфікаційна робота магістра присвячена дослідженню і синтезу
автоматизованої системи зберігання та передавання показників лічильників
до комунальних служб.
Пояснювальна записка містить 72 сторінки, використано 21 джерело.
Метою кваліфікаційної роботи магістра дослідження та синтез
автоматизованої системи зберігання та передавання показників лічильників
до комунальних служб.
Кваліфікаційна робота магістра складається з 3 розділів.
В першому розділі розглянуто питання формування облікових даних
про комунальні послуги з використанням автоматизованих лічильників
енергоресурсів
В другому розділі побудовано модель автоматизованої системи
зберігання та передавання показників лічильників до комунальних служб.
В третьому розділі виконано синтез автоматизованої системи
зберігання та передавання показників лічильників до комунальних служб.
В четвертому розділі досліджено спроектовану автоматизовану
систему зберігання та передавання показників лічильників до комунальних
служб.
В рамках роботи використано та засвоєно сучасні технології розробки
програмного забезпечення.
Ключові слова: АВТОМАТИЗОВАНА СИСТЕМА, WEB-ДОДАТОК,
МАТЕМАТИЧНА МОДЕЛЬ, ФРЕЙМВОРК, БАЗА ДАНИХ, ІНТЕРФЕЙС
КОРИСТУВАЧА, ЕКРАННЯ ФОРМА, ТЕХНОЛОГІЇ ПРОГРАМУВАННЯ
ANNOTATION
The master's qualification work is devoted to the research and synthesis of
an automated system of storage and transfer of meter readings to utility services.
The explanatory note contains 72 pages, 21 sources are used.
The purpose of the master's qualification work is research and synthesis of
an automated system of storage and transmission of meter readings to utility
services.
The master's qualification work consists of 3 sections.
In the first section, the issue of generating accounting data on communal
services using automated energy resource meters is considered
In the second section, a model of an automated system of storage and
transmission of meter readings to utility services is built.
In the third section, the synthesis of the automated system of storage and
transfer of meter readings to utility services is carried out.
In the fourth chapter, the designed automated system of storage and transfer
of meter readings to utility services is investigated.
As part of the work, modern software development technologies were used
and mastered.
Keywords: AUTOMATED SYSTEM, WEB APPLICATION,
MATHEMATICAL MODEL, FRAMEWORK, DATABASE, USER
INTERFACE, SCREEN FORM, PROGRAMMING TECHNOLOGIES
2
ЗМІСТ
ВСТУП………………………………………………………………………….3
РОЗДІЛ 1 ФОРМУВАННЯ ОБЛІКОВИХ ДАНИХ ПРО КОМУНАЛЬНІ
ПОСЛУГИ З ВИКОРИСТАННЯМ АВТОМАТИЗОВАНИХ
ЛІЧИЛЬНИКІВ ЕНЕРГОРЕСУРСІВ…………………………………………6
РОЗДІЛ 2 ПОБУДОВА МОДЕЛІ АВТОМАТИЗОВАНОЇ СИСТЕМИ
ЗБЕРІГАННЯ ТА ПЕРЕДАВАННЯ ПОКАЗНИКІВ ЛІЧИЛЬНИКІВ ДО
КОМУНАЛЬНИХ СЛУЖБ…………………………………………………..22
2.1 Опис можливостей…………………………………………………22
2.2 Розробка високорівневої структури………………………………22
2.3 Вибір цільової платформи………………………………………...23
2.4 Порівняння технологій для синтезу системи…………………….26
РОЗДІЛ 3 СИНТЕЗ АВТОМАТИЗОВАНОЇ СИСТЕМИ ЗБЕРІГАННЯ ТА
ПЕРЕДАВАННЯ ПОКАЗНИКІВ ЛІЧИЛЬНИКІВ ДО КОМУНАЛЬНИХ
СЛУЖБ………………………………………………………………………..33
3.1 Backend……………………………………………………………..33
3.2 Frontend……………………………………………………………..36
3.3 База даних…………………………………………………………..45
РОЗДІЛ 4 ДОСЛІДЖЕННЯ АВТОМАТИЗОВАНОЇ СИСТЕМИ
ЗБЕРІГАННЯ ТА ПЕРЕДАВАННЯ ПОКАЗНИКІВ ЛІЧИЛЬНИКІВ ДО
КОМУНАЛЬНИХ СЛУЖБ…………………………………………………..52
4.1 Інтерфейс користувача…………………………………………….52
4.2 Лістинг екранів…………………………………………………….60
4.3 Серверна частина додатку………………………………………...64
4.4 Розробка математичної моделі…………………………………....67
ВИСНОВКИ…………………………………………………………………..69
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ…………………………………….71
3
ВСТУП
З появою та активним розвитком технологій світ прискорив темпи та
задав високий стандарт до інформатизації та розвитку технологій. Це
проявляється в різних сферах життєдіяльності: від фармакології та
медицини, до металургії, геодезії та торгівлі. Навіть цілі країни переходять
на цифрову форму діяльності.
Наразі коли щось неможливо або складно зробити онлайн -
вважається, що така система застаріла. Людина прагне до покращень та
розвитку існуючих рішень, а також до виробництва нових.
Завдяки цьому мною, але не тільки мною, було помічено
неефективність передачі показників звичайними абонентами,
користувачами послуг з водопостачання, газопостачання та електроенергії.
Проблематика
Зараз абоненти вимушені або користуватись сайтами та пам’ятати
паролі та логіни від них, цо проблематично, враховуючи використання цих
сайтів один раз за місяць, або блукати по месенджерам накшталт Viber,
Telegram чи WhatsApp, шукати чати місячної давності, що також не дуже
оптимально. Кінцевий користувач був би зацікавлений отримувати легкий
доступ до передачі даних та перегляду показань лічильників в одному
місці та ефективно.
Ця робота розглядає спосіб покращення комунікації між
комунальними службами та звичайними користувачами.
Актуальність
Зважаючи на те, що передавання показань до служб може економити
кошти потрібно заохочувати користувачів до цього. Таким чином служба
4
буде отримувати меншу дельту непереданих показань а користувачу буде
нараховано стільки коштів, скільки він витратив ресурсу, а не норму на
кількість людей.
Також користувачі зацікавлені в спрощенні процесу передавання
лічильників, що дає можливість розробляти відразу робочу версію та
випускати її в ринок програмних продуктів знаючи, що клієнт точно буде.
Об’єкт дослідження
В даній роботі потрібно дослідити відразу декілька об’єктів та
комбінувати отримані результати.
Для частини підбору технологій, а також методів та засобів розробки
потрібно дослідити їхні варіанти та поставити їх одним із об’єктів
дослідження.
Наступним об’єктом дослідження потрібно синтезувати систему і
дослідити, чи виконує вона вимоги та поставлені перед нею задачі.
Також потрібно впевнитись в тому, що самому додатку не потрібне
доповнення додаткового чи потенційно навіть основного функціоналу.
Предмет дослідження
Предметом дослідження в даній роботі було обрано кінцевого
користувача, служби. Також одним з важливих предметів дослідження є
самі служби, що поставляють користувачам послуги, з якими може бути
налагоджене співробітництво.
Огляд рішень
Також, враховуючи, що подібних рішень на ринку ще не існує,
виникає ціла низка можливостей монетизації такого рішення.
Перед тим як ми розглянемо основні приклади можливості
монетизації, потрібно поділити ці можливості на два сектори: b2b - тобто
5
business to business відношення, та b2c - business to client відношення.
Перейдемо до прикладів монетизації.
Почнемо з b2b-відношень:
1) з одного боку самі служби-надавачі послуг зацікавлені в зменшенні
дельти між переданими та не переданими показниками і готові
платити певну невелику суму за кожного клієнта, що передав
показник через цю систему. в ході співробітництва з однією з служб
вдалось дійти саме такого рішення.
2) з іншого боку, є клієнти, що мають декілька житлових будівель, що
здаються в оренду. Вони були б зацікавлені бачити та контролювати
передачу показників орендарями, бачити історію споживання
ресурсів, зміну цінової політики компанії-постачальника та вплив на
витрати.
Стосовно b2c-відношень:
1) клієнт матиме можливість безкоштовно передати показники
лічильника. Платним функціоналом буде можливість просканувати
лічильник за допомогою камери мобільного пристрою при його
використанні. Штучний інтелект зможе визначити тип та номер
лічильника, його показання та записати їх в автоматичному режимі.
Користувачу залишиться тільки відправити показання.
6
РОЗДІЛ 1 ФОРМУВАННЯ ОБЛІКОВИХ ДАНИХ ПРО
КОМУНАЛЬНІ ПОСЛУГИ З ВИКОРИСТАННЯМ
АВТОМАТИЗОВАНИХ ЛІЧИЛЬНИКІВ ЕНЕРГОРЕСУРСІВ
В умовах фінансово-економічних диспропорцій і комплексних
реформ соціальної сфери належної уваги потребує житлово-комунальне
господарство. Найбільшими споживачами енергоресурсів є підприємства.
Недосконалість облікового обґрунтування управлінських рішень у сфері
постачання електроенергії, тепла, газу, води є причиною низької
енергетичної ефективності функціонування підприємств, регіонів і
держави загалом. Підприємства не зацікавлені в економному використанні
енергоресурсів і не мають змоги здійснювати контроль за якістю
отриманих комунальних послуг.
У більшості випадків постачальники комунальних послуг є
монополістами на ринку. Як наслідок, у споживача відсутній конкурентний
вибір оператора енергомереж. Недосконалі методики публічногоконтролю за
процесом ціноутворення у сфері житлово-комунального господарства
призводять до штучного завищення вартості комунальних послуг. Дотації та
субсидії для компенсації витрат за спожиті енергоресурси без ефективного
їхнього обліку є причиною зростання видаткової частини місцевих і
державного бюджетів.
Проблемні моменти житлово-комунальної сфери України у
напрямку вдосконалення обліку і контролю спожитих енергоресурсів
через запровадження лічильних приладів активно досліджують
вітчизняні науковці. Найбільш комплексне дослідження методики
комп’ютеризації обліку енергоресурсів здійснене В. В. Кухарчуком та О.
М. Заславським [16]. Також С. А. Приведений розглядав порядок
передавання облікової інформації з лічильників енергоресурсів для
7
подальшої автоматизованої обробки [20, c. 59]. Програмно-технічну
компоненту системи обліку комунальних послуг проаналізував Б. М.
Березянський, який побудував також математичну модель зміни тарифів при
споживанні енергії [13, c. 150]. Б. М. Микийчуком удосконалив методику
обліку споживання енергоресурсів у напрямку запровадження контролю
якості надання комунальних послуг [19, c. 194]. Проте науковці у більшості
випадків розглядають застосування лічильників комунальних послуг з
позиції технічного обліку, залишаючи поза увагою бухгалтерський облік
енергоресурсів. Окрім того, порядок комерційного обліку споживання
електроенергії, води, тепла, газу з використанням лічильниківрегулюється
відповідними нормативно-правовими актами: ЗакономУкраїни «Про питну
воду та питне водопостачання» [17], Законом України «Про заходи,
спрямовані на забезпечення сталого функціонування підприємств паливно-
енергетичного комплексу» [16], Правилами користування електричною
енергією, затвердженими Постановою Національної комісії з питань
регулювання електроенергетики України [11], Порядком доступу до
газотранспортної системи, затвердженим наказом НАК «Нафтогаз України».
Зокрема, Правилами користування електричною енергією дозволено
використання автоматизованої системи комерційного обліку електричної
енергії, що є сукупністю об’єднаних в єдину функціональну метрологічно-
атестовану систему локального устаткування збору й обробки даних засобів
обліку, каналів передачі інформації та пристроїв приймання, обробки,
відображення і реєстрації інформації [11]. Комп’ютеризований збір і
передача інформації про обсягиотриманого тепла, води, газу жодним чином
державою не регламентуються. Лічильники електроенергії з можливістю
автоматизованої відправки інформації активно впроваджуються в практику
сучасних енергогенеруючих компаній – ПрАТ «Київобленерго», АТ
«Одесаобленерго», АТ «Чернівціобленерго» та інших. Також вони
дублюють функції традиційних лічильників і забезпечують автоматизацію
8
лише процедур збору та відправки інформації до оператора енергосистем.
Широкі можливості з комп’ютеризації обліку залишаються
недослідженими.
Знаковою в реформуванні житлово-комунального господарства є
затверджена Міжнародним банком реконструкції та розвитку Програма
«Модернізація системи централізованого теплопостачання вУкраїні: облік
тепла та впровадження платежів на основі його фактичного споживання»,
що містить порівняння національної таіноземної практики обліку і контролю
енергоресурсів з обов’язковим встановленням лічильників комунальних
послуг у користувачів.
Таким чином, вирішення проблем житлово-комунального
господарства більшість фахівців вбачає у впровадженні лічильних
приладів обліку кількості використаних енергоресурсів. Проте обов’язкове
встановлення лічильників без розроблення дієвих методик їхнього
застосування для удосконалення бухгалтерського обліку, контролю та
управління всіма учасниками ринку комунальних послуг не забезпечить
належного позитивного результату.
В межах проведення реформи житлово-комунальної сфери для
зростання енергетичної незалежності, ефективності та рентабельності
діяльності важливою є організація своєчасного та достовірного обліку
спожитих енергоресурсів на основі впровадження сучасних
автоматизованих лічильних приладів використання електроенергії, тепла,
газу, води.
Для впровадження комплексної інформаційної системи
комп’ютеризованого обліку енергоресурсів необхідне виконання таких
основних завдань:
 обґрунтування доцільності порядку встановлення
(обслуговування) лічильників спожитих енергоресурсів для
підприємства, групи чи окремого приміщення, поверху, частини
9
кімнати з визначенням переваг і недоліків організації обліку та
контролю;
 визначення інституційної складової автоматизації обліку і
контролю в учасників ринку комунальних послуг: суб’єктів
господарювання – споживачів, операторів – постачальників
послуг, об’єднань співмешканців багатоквартирних будинків,
орендарів таорендодавців, держави і громадян;
 з’ясування форми розрахунку вартості спожитої електроенергії,
тепла, газу, води пропорційно до площі приміщення, кількості
працівників підприємства, обсягу спожитого ресурсу тощо;
 розробка системи договірних відносин, що впливає на схему
транспортування й тарифікацію енергоносіїв, порядок нарахування
та оплати заборгованості перед постачальниками комунальних
послуг, одержання державних субсидій і компенсацій;
 моніторинг якості, ефективності та повноти отриманих
комунальних послуг через впровадження автоматизованих
лічильних приладів.
Поступове зростання вартості енергоресурсів передбачає
необхідність підвищення рентабельності енергетичного сектору економіки
та енергоефективності діяльності суб’єктів господарювання. Реформа
ринку комунальних послуг має за мету підвищення енергетичної
незалежності суб’єктів господарювання та держави загалом. Збільшення
тарифів на споживання комунальних послуг поєднано з державною
програмою адресного субсидіювання. Дотаційні компенсації надаються
домогосподарствам і суб’єктам господарювання за їхнім сукупним
доходом пропорційно до нормативів споживання комунальних послуг.
Розрахунок обсягу спожитих енергоносіїв на основі нормативних
показників кількості мешканців, працівників, метражу корисної чи повної
площі приміщення не дає змоги достовірно організувати облік
10
комунальних послуг. Роздрібненість споживачів енергоресурсів,
різноманітністьджерел постачання та низький рівень оснащення засобами
обліку споживання у житлово-комунальній сфері зумовлюють виникнення
значних розбіжностей між встановленими нормативами та фактичним
споживанням енергії, води і газу [18].
Наявні інформаційні викривлення при визначенні розміру
комунальних платежів і державних субсидій. Відбувається завищення
видаткової частини місцевих бюджетів, за рахунок яких виділяються
кошти для субсидіювання населення, в обсягах, які значно перевищують
реальні витрати постачальників комунальних послуг. Використання
загальних вимірників нівелює доцільність упровадження програм з
економії та стимулювання зростання ефективності використання
електроенергії, тепла, газу, води. Вирішення інфраструктурних та
економічних проблем у житлово-комунальному господарстві пов’язане із
доцільністю застосування автоматизованих лічильників енергоресурсів, які
мають значні переваги перед традиційною методикою обліку комунальних
послуг (таблиця 1.1).
Впровадження лічильних прикладів дає змогу встановити пряму
залежність між обсягом отриманих комунальних послуг, зміною тарифу
при лімітованому споживанні та державними компенсаціями витрат на
енергоносії. Із масовим використанням лічильників доцільною є
децентралізована організація обліково-контрольних процедур у житлово-
комунальній сфері, що дає змогу впровадити пооб’єктний облік споживання
комунальних послуг навіть у кожному приміщенні будинку. Якщо
загальнобудинковий облік енергоресурсів дає змогу фіксувати обсяг
використаних енергоресурсів, то пооб’єктний облік спонукає до економного
споживання.
Автоматизація обліку і контролю споживання комунальних послуг
можлива одночасно за декількома калькуляційними одиницями. В умовах
11
значної втрати енергоресурсів при їхньому транспортуваннівід постачальника
до споживача корисно оперувати інформацією про фактичний обсяг
отриманої електроенергії, тепла, газу, води не лише в класичних вимірниках,
а й у кілоджоулях чи кілокалоріях. У цьомуразі є можливість для контролю за
якістю отриманих комунальних послугах і здійснення дуального обліку в
калькуляційних одиницях, запропонованих оператором енергоресурсів та
зручних для споживача.
Таблиця 1.1 – Функціональне порівняння традиційної та сучасної
методикавтоматизованого обліку і контролю енергоресурсів
Доцільним є встановлення на всіх підприємствах та у квартирах
об’єднань співмешканців багатоквартирних будинків автоматизованих
лічильних приладів енергоресурсів, мета функціонуванняяких – первинний
12
збір інформації про обсяг отриманої електроенергії, тепла, газу, води без
участі працівників чи мешканців приміщень. Доволі часто через
неможливість фізичного контролю за функціонуванням класичних
вимірювальних приладів споживачі самостійно подавалися показники по
телефону чи через мережу Інтернет, що могло призвести до
маніпулювання та викривлення облікової інформації. Поширені випадки,
коли після певного терміну експлуатації припиняються розрахунки за
показами класичнихлічильників води та тепла, оскільки не виконана чергова
метрологічна перевірка цих лічильників та у разі виходу їх з ладу [19].
Лічильники можуть бути під’єднані до комунікаційної мережі, через
яку без участі будь-яких осіб передається облікова інформація про
кількісні параметри спожитих енергоресурсів. На великих підприємствах
використовуються комунікаційні мережі, запропоновані операторами
енергоресурсів. Проте у більшості випадків облікові дані передаються
через мережу Інтернет, що зменшує вартість впровадження проекту з
автоматизації обліку комунальних послуг. Порядок інформаційної
взаємодії споживача та постачальника енергоресурсів подано на
рисунку 1.1.
13
Рисунок 1 1 – Інформаційна взаємодія систем обліку отриманих/наданих
комунальних послуг у споживачата постачальника енергоресурсів
У підприємства, яке надає послуги з постачання енергоресурсів,
організовується дата-центр, який в автоматизованому режимі опрацьовує
інформацію, отриману з індивідуальних лічильників. У більшості випадків
оператори енергосистем володіють належним програмно-технічним
забезпеченням, яке обробляє інформацію, подану споживачем по телефону
чи через мережу Інтернет про обсяг використаної електроенергії, тепла,
газу, води. З огляду на це інформаційну систему обліку енергоресурсів без
значних капітальних витрат можливо модернізувати для використання
автоматизованих лічильників. Автоматизовані лічильники аналогічно до
традиційних лічильних засобів потребують стандартизації та метрологічної
перевірки, але лише одноразово при монтажі в одержувача енергоресурсів.
У подальшому контрольна перевірка може здійснюватися дистанційно.
Після завершення розрахункового періоду (години, частини дня, доби,
14
тижня, місяця) лічильники можуть автоматизовано та дистанційно
передавати облікову інформацію з метою взаєм- ної звірки всіма
учасниками ринку комунальних послуг (рисунок 1.2).
Рисунок 1.2 – Схема інформаційного обміну в умовах комп’ютеризованого
обліку та контролю енергоресурсів учасниками ринку комунальних
послуг
У такому разі унеможливлюються махінації з показниками
лічильника, який при зовнішньому втручанні в алгоритм функціонування
сигналізуватиме про це споживачеві та постачальнику комунальних
послуг. Суттєво зменшується необхідність у розміщенні лічильників у
місцях, доступних для візуального огляду представниками оператора
енергомереж, а також періодичного відвідування ізольованих приміщень
для «зняття» показників.
15
Одержання облікової інформації може ініціювати автоматизоване
формування облікових проведень у споживача та постачальника
енергоресурсів щодо зростання доходів, витрат, дебіторської чи
кредиторської заборгованості. Для індивідуального врахування витрат на
комунальні послуги за напрямками діяльності лічильники використаної
електроенергії, тепла, газу, води доцільно встановлювати в кожному
структурному підрозділі підприємства. За вимірювальним приладом
закріплюється відповідна стаття витрат. Усі лічильні прилади відповідно
до місць встановлення доцільно класифікувати на лічильники обліку
споживання комунальних послуг виробничого, загальновиробничого,
адміністративного, збутового та іншого призначення. Якщо витрати,
пов’язані зі споживанням електроенергії, тепла, газу, води, не можливо
ідентифікувати як виробничі, то їх доцільно зараховувати до
загальновиробничих із необхідністю подальшого розподілу. На
виробничому суб’єкті господарювання базою розподілу є вартість
виготовленої продукції. На невиробничому підприємстві
загальновиробничі витрати доцільнорозподіляти пропорційно до кількості
або розміру заробітної праці працівників, які надають виробничі послуги і
безпосередньо споживають енергоносії. Надходження первинної
інформації про споживання послуги автоматично формуватиме облікові
проведення щодо збільшення відповідних витрат підприємства та
кредиторської заборгованості перед постачальниками енергоносіїв.
У лічильних приладах доцільно запрограмувати часовий моніторинг
надання комунальних послуг. Облікові проведення можливо формувати
автоматизовано у кінці дня. Однак при використанні електроенергії
добовий часовий облік доцільно скоригувати на можливість окремого
врахування денного та нічного тарифів.
З впровадженням комп’ютеризованого обліку та контролю
споживання комунальних послуг доцільно поетапно автоматизовано
16
відображати на рахунках обліку використану електроенергію спочатку за
денним, а потім за нічним тарифом, за єдиним індивідуальним рахунком
платника. Обліковий запис слід здійснювати на основі показників
спожитої енергії в останню хвилину застосування відповідного часового
(денного, нічного) тарифу, що сприятиме уніфікації обліково-контрольних
процедур.
Доволі часто підприємство може виготовляти ресурси. Дедалі
більше суб’єктів господарювання застосовують альтернативні джерела
енергії, будують котельні та добувають воду. Якщо виготовлена
електроенергія чи добута вода використовується лише для внутрішніх
цілей, то її собівартість передається на вартість виготовленої продукції
(робіт, послуг) через списання витрат допоміжного виробництва на
рахунок основного виробництва.
При реалізації, особливо електроенергії, підприємству вигідно
здійснювати її виробництво для продажу за так званим «зеленим
тарифом». У такому разі систему обліку енергоносіїв доцільно
використовувати в реверсному режимі. Автоматизовані лічильники
формуватимуть облікові проведення з реалізації електроенергії відповідно
до кількості кіловат енергії, переданої в єдину енергосистему. Важливою є
організація ефективного комп’ютеризованого обліку і контролю за
співвідношенням між кількістю спожитої та реалізованої енергії. В кінці
розрахункового періоду рекомендованого за методом «червоного сторно»
відображати вартість спожитої енергії в межах обсягів виробництва.
Іншими словами, система обліку автоматизовано зменшуватиме
заборгованість підприємства перед постачальниками на суму переданої
енергії в єдину енергосистему. Вартість електроенергії, обсяг виробництва
якої перевищує споживання, можна визнати доходом підприємства.
Проблемним є питання обліку споживання комунальних послуг за
орендованим майном. Можливі три варіанти розрахунку та оплати
17
використаних енергоресурсів: орендодавець оплачує комунальні послуги
та компенсує їх через збільшення орендної плати; орендар самостійно
оплачує рахунки за використання електроенергії, тепла, газу, води;
орендар перераховує вартість отриманих комунальних послуг
орендодавцю. У всіх випадках доцільним є застосування автоматизованих
лічильних приладів енергоносіїв.
У разі, коли орендодавець згідно з договором оренди одержує від
орендаря відшкодування витрат на оплату отриманихкомунальних послуг і
на утримання приміщення, то при обчисленні об’єкта оподаткування
орендодавець враховує суми такої компенсації у складі доходу на підставі
пп. 135.5.15 ПКУ, а суму коштів, сплачених постачальнику комунальних
послуг, – у складі інших витрат операційної діяльності, пов’язаних з
господарськоюдіяльністю.
Система обліку і контролю оперативно надаватиме орендодавцю та
орендарю інформацію про обсяг спожитих енергоносіїв. Якщо
орендодавець сплачує вартість комунальних послуг, то інформація з
автоматизованих лічильників дасть змогу коригувати розмір орендної
плати на подальші періоди, якщо це обумовлено договором. На основі
інформації про прогнозований обсяг споживання можливо достовірно
визначити вартість оренди на майбутнє. Орендар отримує достовірний
механізм контролю за процесом обґрунтування розміру орендних платежів
кожного звітного періоду. Якщо орендар самостійно сплачує рахунки за
енергоносії на основі показників лічильників, то орендодавець лише
здійснюєконтроль за своєчасністю та повнотою погашення боргів перед
постачальниками послуг. Автоматизований контроль орендодавця
спрямований на уникнення штрафних санкцій за порушення термінів
оплати та запобігання від’єднань від енергоносіїв. Оскільки у більшості
випадків фінансові санкції будуть виставлятися власнику, а не орендарю
майна, то в належному контролі безпосередньо зацікавлений
18
орендодавець. У такому разі доходом орендодавця буде лише сума
орендної плати. Облік витрат за отриману електроенергію, тепло, газ, воду
на основі інформації з автоматизованих лічильників енергоносіїв ведеться
лише в орендаря.
Проте бувають випадки, коли частина комунальних послуг
споживається орендодавцем, тобто вони є певною часткою витрат на
утримання об’єкта оренди. Наприклад, це може бути освітлення
громадських місць спільного користування: під’їзних шляхів, коридорів,
складів, автостоянок тощо. Як і у разі організації договірних відносин,
коли орендар перераховує суму отриманих комунальних послуг власнику
приміщення, доцільною є організаціяобліку доходів і витрат енергоносіїв в
орендодавця.
Витрати на комунальні послуги за об’єктами, що здані в оренду,
доцільно розглядати як інші операційні витрати на субрахунку 949 «Інші
витрати операційної діяльності». Відповідно доходи від компенсацій
орендарем вартості комунальних послуг, інформація про які отримана з
автоматизованих лічильних приладів, відображають на субрахунку 719
«Інші доходи від операційної діяльності»[14].
До лічильників (персоніфікованого абонентського рахунка) доцільно
прив’язати банківський рахунок. Як підсумок, можливим є перманентне
погашення боргів перед постачальником комунальних послуг чи
орендодавцем в автоматизованому режимі. Функцію автоматичних
платежів пропонує більшість банків, які дають змогу клієнтам формувати
список періодичних платежів за рахунками. Після завершення
розрахункового періоду (робочої зміни, доби, дня, ночі) система
автоматизовано перераховуватиме коштиза отримані комунальні послуги.
Перед оплатою, за бажанням керівництва, посадовій особі,
відповідальній за грошові розрахунки, видаватиметься запит на
підтвердження чи заборону здійснення грошової трансакції. Аналогічну
19
інформацію доцільно надсилати обліковим працівникам у разі
недостатності коштів на банківському рахунку. Бухгалтер зможе
своєчасно поповнити банківський рахунок або обрати інше джерело
погашення боргів за отримані комунальні послуги. Автоматично
формуватиметься облікове проведення зі списання грошових коштів на
користь одержувача. Забезпечується контроль за своєчасним і повним
погашенням боргів за отримані комунальні послуги, що дасть змогу
запобігти від’єднанню підприємства від енергомереж за несплату.
У лічильник можливо вмонтувати функцію обмеження або
припинення надання комунальних послуг за певних умов. У такій
функціональній можливості можуть бути зацікавлені як користувачі,
орендодавці, так і оператори енергоносіїв. При досягненні граничних
обсягів споживання електроенергії, тепла, газу, води за бажанням
керівництва підприємства автоматизована система обмежить обсяг
отриманих комунальних послуг з метою недопущення надмірного їхнього
використання. Наприклад, можливо автоматично зменшувати яскравість
освітлення у допоміжних приміщеннях, мінімізувати температуру повітря
у виробничому приміщенні при завершенні робочого дня, припиняти
подачу газу у разі швидкого зростання його використання, що може
свідчити про вихід з ладу виробничого обладнання тощо. Оператор
комунальних послуг чи орендодавець може дистанційно управляти
автоматизованою системою з метою припинення чи дозування подачі
енергоресурсів споживачам, які протерміновують платежі за комунальні
послуги. Після їхньої сплати система обліку і контролю автоматично
розблоковуватиме подачу енергоносіїв.
Комп’ютеризовану систему також рекомендовано використовувати
для диференційованого тарифікування комунальних послуг залежно від
обсягу їхнього споживання. Державою передбачено суттєве зростання
тарифу на електроенергію після перевищення встановлених лімітів.
20
Автоматизований лічильник енергоносіїв можливо запрограмувати на
виконання функції повідомлення керівництву про досягнення лімітних
показників. Контроль може бути багатоступеневих: 1) попередження
персоналу з метою більш економного використання; 2) інформування
керівництва для прийняття рішення щодопризупинення або відтермінування
господарської діяльності; 3) автоматичне від’єднання виробничо неважливих
функцій підприємства.
Сума облікового відображення операцій зі споживання комунальних
послуг автоматично змінюватиметься після перевищення ліміту. Функція
автоматичної зміни тарифів у вимірювальних приладах може бути
корисною для мобільної підприємницької діяльності. Наприклад,
пересувна торгівля, мобільні розважальні послуги, авіа- та автоперевезення
пасажирів пов’язані з встановленням мобільних лічильних приладів, які
автоматично змінюватимуть тарифи на спожиті енергоносії залежно від
територіального розміщення рухомого складу підприємства. Таким чином,
реальним є достовірний облік споживання комунальних послуг, вартість
яких змінюється після переміщення виробничих потужностей
підприємства з одного населеного пункту в інший.
Від кількості спожитих енергоресурсів залежить також можливість
одержання дотаційних компенсацій із місцевого чи державного бюджету
для відшкодування витрат на комунальні послуги. Для деяких видів
господарської діяльності або малозабезпечених громадян у формі ОСББ
необхідним є достовірний облік одержаних дотацій. Законодавцем
передбачено відшкодування вартості спожитих енергоносіїв операторам
комунальних послуг у межах ліміту.
Одноразове, на початку або в кінці місяця, відображення дотацій на
рахунках обліку може призвести до завищення реальних фінансових
результатів. Доцільним є пропорційне відображення одержаного цільового
фінансування відповідно до кількості отриманих комунальних послуг. У
21
кінці розрахункового періоду (робочої доби, дня, ночі) необхідно
відображати частину одержаного цільового фінансування в розмірі
використаних енергоносіїв за аналогічний часовий проміжок. Таким
чином, встановлюється прямий зв’язок між обсягом використання
електроенергії, тепла, газу, води та дотаційним відшкодуванням їхньої
вартості. Зменшення розрахункових термінів при обліку цільового
надходження(фінансування) дасть змогу ефективно організувати контроль
за своєчасним і повним використанням дотацій, оперативно виявляти
порушення та моніторити освоєння державних коштів.
Комп’ютеризована система обліку і контролю споживання
комунальних послуг за використання сучасних комунікаційних технологій
дає можливість перенести центр управління енергоносіями від оператора до
споживача. Всі обліково-управлінські процеси відбуваються на
підприємстві. Найбільш радикальні зміни децентралізація управління
комунальними послугами вносить у порядок обліку податку на додану
вартість. В умовах загального електронного декларування сум
нарахованого та відшкодованого ПДВ системі обліку і контролю
споживання комунальних послуг доцільно доручити функцію формування
та відправки податкових накладних
22
РОЗДІЛ 2 ПОБУДОВА МОДЕЛІ АВТОМАТИЗОВАНОЇ СИСТЕМИ
ЗБЕРІГАННЯ ТА ПЕРЕДАВАННЯ ПОКАЗНИКІВ ЛІЧИЛЬНИКІВ
ДО КОМУНАЛЬНИХ СЛУЖБ
2.1 Опис можливостей
Виходячи з опису системи, що була представлена у вступі роботи,
можемо почати побудову моделі системи. Для початку потрібно виділити
функціональні можливості системи.
Повинна бути можливість:
1) користувачу створити акаунт власника адреси
2) власнику додати його адреси
3) власнику додати служби до адреси
4) власнику передати показник
5) власнику редагувати доступ інших користувачів до його адрес
6) власнику створити посилання для реєстрації дочірніх користувачів
7) користувачу просканувати показник за допомогою камери
2.2 Розробка високорівневої структури
В ході роботи над системою вдалось налагодити комунікацію з КП
«Черкасиводоканал». Після обговорення деталей та погодження інтеграції
з їхньою інфраструктурою як однією з комунальних служб, до яких можна
буде передати показання лічильників.
Виходячи з цього можемо сформувати список сервісів, що потрібні
для синтезу системи.
Систему можна поділити на дві частини:
1) Частина додатку
23
2) Частина, з якою комунікує додаток
До частини додатку відноситься:
1) Рівень відображення
2) Рівень логіки, обробки та збереження даних
3) База даних для збереження інформації
Частина, з якою комунікує додаток – це простий веб-сервер, що
комунікує з базою даних служби надавача послуг і має можливість
відповідати на запити додатку через захищений канал зв’язку. Вона
виконує роль API для основного додатку.
На рисунку 2.1 відображено високорівневу структуру додатку та
комунікацію між різними сервісами системи.
Рисунок 2.1 – Високорівнева структура додатку та комунікацію між
різними сервісами системи
2.3 Вибір цільової платформи
Враховуючи специфіку проекту потрібно продумати, на якій/яких
цільових платформах повинен бути додаток.
Розглянемо наступні варіанти:
24
 Web-додаток
 PWA (Progressive Web App)
 Нативний додаток чи додатки для мобільних операційних систем
iOS та Android
 Нативний додаток під операційні системи Windows, MacOS,
Linux
 Комбіновані (гібридні) рішення з використанням різних підходів
та цільових платформ або декілька додатків
Розглянемо кожен із варіантів більш детально.
Web-додаток
Web-додаток - одна з найпопулярніших опцій для більшості додатків
сучасності. Web-додаток це прикладна програма, доступ до якої можливий
через web-браузер.
Такий варіант підходить більшості користувачів, так як він охоплює
найбільшу кількість користувачів. Але для вище описаної системи такий
вибір не може бути основним, оскільки у користувача буде функціональна
можливість використовувати камеру, виходячи з опису можливостей (3.1).
PWA (Progressive Web Application)
Progressive Web App – це тип додатку, що поширюється за
допомогою web-браузера, збудований на популярних web-технологіях
(html, css, js, webassembly), та здатний працювати на всіх пристроях, що
підтримують браузер.
Його головним мінусом є те, що більшість користувачів не знають
про можливість встановлення додатку через браузер. Головним плюсом
цього підходу є одна кодова база.
25
Також ще одним недоліком такого підходу є те, що не всі функції,
що присутні в API мобільних додатків доступні для реалізації через
Progressive Web Application.
З переваг такого підходу є простота написання коду та простота
підтримки.
Нативний додаток чи додатки для мобільних операційних систем iOS
та Android
Нативний мобільний додаток – програмне забезпечення, що
призначене для роботи на мобільних пристроях.
Такі додатки можна встановлювати та скачувати за допомогою
звичного для користувача способу - використовуючи App Store на iOS та
Play Market на Android. Це також є однією з переваг такого підходу.
Ще однією перевагою є те, що додаток пишеться таким чином, як це
задумали розробники мобільної операційної системи, що дає невеликий
приріст до швидкодії додатку.
До основних недоліків такого підходу відносять:
 Необхідність створення окремого додатку під кожну мобільну
операційну систему
 Знання технологій та підходів, що використовуються для створення
додатків для кожної мобільної операційної системи
 Для написання нативного додатку для операційної системи iOS
потрібен пристрій на MacOS
Тож цей підхід є найбільш правильним, але найбільш ресурсоємким.
Враховуючи те, що потрібно отримати розробку найбільш швидким
способом, цей метод - не найкраща опція в даному сценарії.
26
Нативний додаток під операційні системи Windows, MacOS, Linux
Виходячи з цільової аудиторії та потреб додатку, переважна
більшість користувачів буде використовувати саме мобільні пристрої,
тому написання нативних рішень під вищезазначені операційні системи
хоч і можливе, але не доцільне.
Комбіновані (гібридні) рішення з використанням різних підходів та
цільових платформ або декілька додатків
Комбіновані засоби дозволяють створити збірки для кожної
мобільної операційної системи та web-додаток з однієї кодової бази. Вони
мають перевагу над Progressive Web Application, адже мобільні додатки,
створені за допомогою цього підходу встановлюються найбільш зручним
для користувача способом – через Play Market (для операційної системи
Android) або через App Store (для операційної системи iOS).
На відміну від Progressive Web Application, вони також не мають
обмежень по API для мобільних пристроїв.
Висновок до вибору цільової платформи:
Виходячи з потреб поставлених вимог та враховуючи всі
вищезазначені переваги та недоліки кожного з підходів найкращим
вибором було б використати гібридний підхід. Він дозволяє реалізувати
усі функціональні можливості, що потрібні даному додатку. Має широкий
API на мобільних пристроях, дозволяє тримати одну кодову базу.
2.4 Порівняння технологій для синтезу системи
За допомогою описаних вище частин додатку визначимо та
розглянемо технології, що були застосовані при імплементації додатку.
27
Рівень відображення (Frontend)
Звузивши коло технологій на стадії планування в пункті 3.3 даної
роботи постає вибір між двоми технологіями: Flutter або React Native.
Розглянемо обидві, щоб зрозуміти відмінності між цими
технологіями.
Flutter використовує canvas для відображення контенту. Це дозволяє
йому відображати контент на високій частоті кадрів. Мінусом є не дуже
нативний підхід на мобільних пристроях.
React Native дотримується підходу відображення контенту як веб-
сторінки всередині вікна на мобільних пристроїв. Це дозволяє отримувати
кращу крос-платформеність.
В даному випадку було обрано React Native.
Рівень логіки, обробки та збереження даних (Backend)
Для цього рівня існує багато технологій, завдяки яким можна
імплементувати логіку, що потрібна для роботи додатку.
Так як хотілось би мати можливість будувати гнучку та швидку
систему, що не займає багато ресурсів, було відкинуто такі мови
програмування як C#, Java. Python та Ruby динамічно типізовані і можуть
мати помилки в runtime. Враховуючи це було прийняте рішення не брати
їх в роботу.
Виходячи з потреби мати можливість швидко адаптувати систему до
змін, вільно комунікувати між рівнями та мати широкий інструментарій за
замовчуванням було обрано мову JavaScript і оточення для запуску -
Node.js.
Це потужний і водночас простий інструмент для розробки. В цього
інструмента є лише один недолік - динамічна типізація. Динамічна
типізація робить можливою швидку розробку, та одночасно вимушує
розробника ретельно слідкувати за тим, що саме передається в функції і
28
зберігається в змінних. Неправильні дані легко можуть порушити
правильність роботи, і такі помилки виникають тільки в runtime. Це
достатньо пізно, і деякі дефекти таким чином навіть можуть успішно
пройти тестування і завдати шкоди в production оточеннях. Саме для
усунення цього недоліку та надання можливості слідкувати за типами
даних, але не забираючи можливість швидкого написання функціоналу
використовують надстройку над JavaScript - TypeScript, тому вибір падає
на нього.
База даних для збереження інформації (DB)
Бази даних та системи управління базами даних бувають декількох
видів.
В класичному понятті виділяють такі види баз даних:
1) Документно-орієнтовані
2) Реляційні
3) Графові
Враховуючи присутність зв’язків між профілями користувачів та
показниками, адресами і службами можемо відразу відкинути документно-
орієнтовані бази даних. Вони мають дуже специфічну сферу застосування
і не підходять як основний спосіб збереження даних.
Графові бази мають за концепт математичні графи, які часто
використовуються в інших суміжних галузях, наприклад в задачах, які
іноді називають “знаходження найкоротшого шляху нафтопроводу” та
інших.
Ідея заключається в тому, щоб створювати графи на кожну вагому
сутність системи та мислити об’єктно. Кожен граф відображає, наприклад,
користувача, чи, скажімо, адресу. Граф з’єднаний з іншими в графову
мережу. Це гарно працює на системах, де є статично задані графи або
29
кількість самих графів невелика. Враховуючи це, графові бази - не
найкраще рішення для даного додатку.
Реляційні бази схожі на графові присутністю зв’язків між
сутностями. Зв’язки формуються завдяки первинним та зовнішнім
ключам, так званим primary key і foreign key.
Реляційні бази – найпопулярніше рішення, в зв’язку з його
швидкістю роботи та налаштуванням а також можливістю гнучко
налаштувати роботу та схему даних.
Вони беруть за основу схеми і таблиці. В таблицях зберігаються колонки,
а в колонках значення різних атомарних і комплексних типів даних.
В якості бази даних для цього проекту було обрано PostgreSQL. Ця
база безкоштовна для використання в комерційних проектах. Також вона
одна з (і єдина з безкоштовних) баз даних, яка старається підтримувати
найновітніші функціональні можливості стандарту SQL.
Комунікація між службами
Для комунікації між службами можуть бути використані різні
технології.
В залежності від того, які служби між собою комунікують,
виділяють три типи комунікації.
Для комунікації між службами різних систем використовують
RESTful API. Це загальноприйняті правила передачі даних по HTTP-
протоколу, яким слідують різні компанії, що продукують API для
використання його іншими системами.
Якщо сервіси одного додатку повинні обмінюватись якимись
короткими повідомленнями з так званою “плоскою” інфраструктурою -
використовуються різного роду key-value сховища даних. Такі рішення
корисні, наприклад, для поширення між сервісами даних для
аутентифікації користувачів, деяких службових даних, тощо.
30
Прикладом такої комунікації є Redis, Kafka, RabbitMQ, та інші.
Іноді виникає необхідність в комунікації між сервісами за
допомогою комплексних структур, як наприклад при RESTful API. Для
того, щоб зменшити навантаження на мережу та мати більшу швидкодію
використовують різні протоколи, що є більш легкими, ніж HTTP.
Наприклад, MQTT, RPC та різні надстройки над ним, тощо.
Враховуючи необхідність швидкої передачі складних та
різноманітних даних між сервісами та рівнями додатку, а також більш
захищеного протоколу передачі, було обрано використати протокол RPC.
RPC (Remote Procedure Call) - дозволяє одному сервісу викликати
певні методи іншого сервісу. За основу комунікації в RPC взято HTTP, з
якого прибрали все зайве, щоб прискорити роботу та зменшити кількість
метаданих, що передаються разом з пакетом даних.
Визначення розподілу та балансування навантаження на систему
При формуванні вимог до кінцевого продукту також потрібно було
вирішити, яке саме буде навантаження на систему, в які дні та години буде
пікове навантаження та як воно буде балансуватись.
Це питання вимагає глибокого дослідження та аналізу. Враховуючи
те різноманіття різних сервісів, що пропонують service-провайдери та
платформи, потрібно обрати саме те, що потрібно даному додатку.
При спілкуванні з фахівцями з КП “Черкасиводоканал” стало
зрозуміло, що покази лічильників передають в кінці місяця. Основне
навантаження - з 11 години ранку по 10 годин вечора с 25 по останній день
місяця. Передається від 6-8 тисяч показань на день, починаючи близько
20-х чисел.
Таким чином можемо сформувати критерії, за якими будемо
обирати тип серверів на service-провайдері.
31
1) Web
Щоб зекономити на серверному часі, статичну збірку web частини
було вирішено покласти на on-demand cloud functions. Таким чином, коли
користувач заходить в додаток, для нього моментально запускається міні-
сервер, що обробляє саме цього користувача. Якщо в момент коли
користувач покидає додаток до системи приєднується інший користувач,
то сервер перемикається на цього. Таким навантаження визначає скільки
коштує сервер. І таким чином вдається на платити за той час, коли сервер
знаходиться в простої без користувачів.
2) Mobile
Мобільні пристрої мають завантажену версію додатку, тому не
потрібно балансувати та керувати навантаженням на цю частину системи.
Приймаючи до уваги те, що основна кількість користувачів
використовують саме мобільні додатки, вдається значною мірою
економити на серверах.
3) Backend
Сервер, що обробляє всі запити від клієнтів з мобільних пристроїв та
з web-додатків повинен бути ввімкненим завжди. Таке рішення було
прийнято тому що користувач повинен мати можливість додати службу,
переглянути історію та статистику в будь-який проміжок часу.
4) Database
База даних налаштована таким чином, що вона майже не витрачає
коштів коли в простої, але з підвищенням читань та записів до бази
підвищується й ціна.
32
Також для того, щоб реалізувати таку архітектуру, потрібно
визначитись із провайдером послуг.
Найпопулярнішими провайдерами є:
1) GCP
2) AWS
3) DigitalOcean
4) Azure
Враховуючи цінову політику та популярність і стабільність, а також
попередній досвід, було обрано Amazon Web Services (AWS).
Він дозволяє реалізувати гнучку інфраструктуру що підходить за
вимогами вище описаній.
33
РОЗДІЛ 3 СИНТЕЗ АВТОМАТИЗОВАНОЇ СИСТЕМИ ЗБЕРІГАННЯ
ТА ПЕРЕДАВАННЯ ПОКАЗНИКІВ ЛІЧИЛЬНИКІВ ДО
КОМУНАЛЬНИХ СЛУЖБ
Після ретельного аналізу вхідних вимог та вибору технологій для
додатку та його типу можемо почати процес синтезу, тобто безпосередньо
імплементації додатку.
3.1 Backend
Розглянемо для прикладу аутентифікацію користувача:
export const authRouter = t.router({
me: t.procedure.use(isLoggedIn).query(({ ctx }) => ctx.user),
login: t.procedure
.use(isLoggedOut)
.input(
z.object({
login: z.string(),
password: z.string(),
}),
)
.mutation(async ({ input: { login, password } }) => {
const user = await prisma.user.findFirst({
where: {
OR: [{ email: login }, { phone: login }],
},
});
if (!user || !(await bcrypt.compare(password, user.password)))
34
throw new TRPCError({
code: 'NOT_FOUND',
message: 'User with such email/phone number and password is not
found',
});
return user;
}),
logout: t.procedure.use(isLoggedIn).mutation(() => {
}),
register: t.procedure
.use(isLoggedOut)
.input(
z.object({
// TODO: Share validation with app
email: z.string().min(4).email(),
phone: z.string().min(4),
password: z.string().min(8),
darkTheme: z.boolean().default(false),
}),
)
.mutation(async ({ input }) => {
const userWithSimmilarEmailOrNumber = await
prisma.user.findFirst({
where: {
OR: [{ email: input.email }, { phone: input.phone }],
},
});
35
if (userWithSimmilarEmailOrNumber?.email === input.email) {
throw new TRPCError({
code: 'BAD_REQUEST',
message: 'User with such email already exists',
});
} else if (userWithSimmilarEmailOrNumber?.phone ===
input.phone) {
throw new TRPCError({
code: 'BAD_REQUEST',
message: 'User with such number already exists',
});
}
return prisma.user.create({
data: {
email: input.email,
phone: input.phone,
darkTheme: input.darkTheme,
password: await bcrypt.hash(input.password, 10),
},
});
}),
});
Таким чином ми створили router. Його завдання - направляти всі
RPC запити на правильні методи самого роутера.
Роутери створюються під окремі частини системи, таким чином ми
можемо досягнути розділення відповідальності (також відоме, як поняття
separation of concerns) між частинами системи.
36
Для того, щоб отримати більшу підтримку і синхронізованість між
сервером та клієнтом, а також враховуючи, що обидві частини написані на
TypeScript, використовується tRPC.
tRPC – це надстройка над звичайним RPC, що дозволяє
синхронізувати типи backend сутностей з тими, що приходять на frontend.
Це, в свою чергу, дає можливість змінювати модель даних в одному місці і
позбавляє розробника типових помилок. Також такий підхід надає
можливість перевикористати частину коду, зменшуючи тим самим кодову
базу.
Окрім цього, backend вміє робити запити на сторонні служби та
використовувати закриті API різних служб.
3.2 Frontend
На frontend ми пишемо на звичайному React таким чином, як ми це
робили б з web-додатком. React - це бібліотека для побудування
інтерфейсів. Вона побудована на концепті компонентів. Розробник може
створити невеликі куски html, css та js і перевикористовувати код по
додатку.
React дає можливість будувати інтерфейси пишучи на мові, схожій
на html - jsx. Вона – майже повна копія, тільки мовою JavaScript.
Для порівняння, ось шматок HTML:
<div><p>hello</p>, <span class=“world-class”>world</span></div>
А ось JSX:
<div><p>hello</p>, <span className={“world-
class”}>world</span></div>
37
Виходячи з даного прикладу, можна зрозуміти що вивчити JSX дуже
легко коли є базові знання HTML. Окрім передачі параметрів в атрибути
тегів в якості об’єктів і заміни class на className (в зв’язку з тим, що class
- зарезервоване слово в JavaScript) майже нічого не змінилось.
В React є одна чудова особливість - virtual DOM. Кожен компонент
має свій внутрішній DOM, що дозволяє оновлювати не всю сторінку а
лише певні компоненти. Завдяки цьому підвищується швидкодія.
DOM - документна об’єктна модель. Це деревовидне представлення
всього дерева компонентів об’єктами JavaScript.
Компонент за своєю структурою та будовою це по своїй суті проста
JavaScript-функція що опціонально приймає об’єкт props та повертає
певний jsx-код.
До прикладу, ось так виглядає найпростіший компонент:
export const helloComponent = () => {
return (<div>hello, sample react component!</div>);
}
Цей компонент вертає JSX елемент, а отже вважається, що такий
компонент і сам є JSX елементом.
Таким чином можемо використати компонент:
<div>
<helloComponent />
</div>
Тепер трохи ускладнимо цей приклад, додавши до цього типізацію:
interface ComponentProps {
}
38
export const helloComponent: FC<ComponentProps> = (props:
ComponentProps) => {
return (<div>hello, this is a sample component</div>);
}
Ми додали можливість прийняти props, проте не очікуємо нічого.
Якщо б ми дійсно захотіли б зараз щось передати, то отримали б помилку
про невідповідність типів.
Таким чином з’являється можливість створити точну сигнатуру для
компонента.
Завдяки TypeScript з’являється можливість передбачити як
компонент буде працювати в яких сценаріях.
Тепер розглянемо реальний приклад одного з компонентів:
import { FC, useState } from 'react';
import { Text } from 'react-native-paper';
import { Routes } from '../../constants/navigation';
import { usePersistentStore } from '../../store';
import { LoginFields, useLoginForm } from './Login.validation';
import { Link } from '../../components/Link';
import { FormError } from '../../components/FormError';
import {
LoginWrapper,
LoginTitle,
LoginButton,
LoginButtonText,
LoginTextField,
} from './Login.styled';
39
import { useTranslation } from 'react-i18next';
export const Login: FC = () => {
const { t } = useTranslation();
const { login } = usePersistentStore();
const [loginError, setLoginError] = useState<Error>();
const { control, handleSubmit } = useLoginForm();
const onSubmit = handleSubmit(fields => {
setLoginError(undefined);
try {
login(fields[LoginFields.Login], fields[LoginFields.Password]);
} catch (e) {
setLoginError(e as Error);
}
});
return (
<LoginWrapper>
<LoginTitle
variant="headlineLarge">{t('common.login')}</LoginTitle>
<LoginTextField
control={control}
autoComplete="username"
name={LoginFields.Login}
label={t('screens.Login.phoneOrEmail')}
/>
40
<LoginTextField
control={control}
autoComplete="password"
keyboardType="visible-password"
name={LoginFields.Password}
label={t('screens.Login.password')}
secureTextEntry
/>
<FormError error={loginError?.message} />
<LoginButton mode="contained" onPress={onSubmit}>
<LoginButtonText
variant="bodyLarge">{t('common.login')}</LoginButtonText>
</LoginButton>
<Text variant="bodyLarge" style={{ marginTop: 15 }}>
{t('screens.Login.dontHaveAnAccount')}
<Link to={Routes.Register}> {t('screens.Login.register')}</Link>
</Text>
</LoginWrapper>
);
};
А в іншому файлі зберігаються styled-components стилі:
import { View } from 'react-native';
import { Button, Text } from 'react-native-paper';
import styled from 'styled-components/native';
import { FormTextField } from '../../components/TextField';
export const LoginWrapper = styled(View)(({ theme }) => ({
41
flex: 1,
backgroundColor: theme.colors.background,
alignItems: 'center',
justifyContent: 'center',
}));
export const LoginTitle = styled(Text)({
width: '60%',
marginBottom: 23,
textAlign: 'center',
});
export const LoginButton = styled(Button)({
width: '60%',
marginTop: 10,
});
export const LoginButtonText = styled(Text)(({ theme }) => ({
color: theme.colors.onPrimary,
}));
export const LoginTextField = styled(FormTextField)({
width: '60%',
marginBottom: 10,
});
Відразу бачимо декілька цікавих нововведень, що не були описані в
прикладах вище. А саме:
1) const { t } = useTranslation();
42
2) const { control, handleSubmit } = useLoginForm();
Стосовно першого пункту. Таким чином використовується
бібліотека для інтернаціоналізації. Вона дозволяє створити словник для
кожної мови і надати можливість для перемикання між мовами.
Ось, для прикладу, англійський словник:
{
"common": {
"save": "Save",
"cancel": "Cancel",
"login": "Login"
},
"components": {
"Addresses": {
"addresses": "Addresses",
"noAddressesYet": "No addresses yet",
"startAddingFirstAddress": "Start by adding your first address,
pressing the button below",
"addAnAddress": "Add an address"
},
"Services": {
"lastValue": "Last value:",
"send": "Send"
}
},
"screens": {
"Login": {
"phoneOrEmail": "Phone number or email",
"password": "Password",
43
"dontHaveAnAccount": "Don't have an account?",
"register": "Register"
},
"Register": {
"registration": "Register",
"register": "Register",
"email": "Email",
"phoneNumber": "Phone number",
"password": "Password",
"haveAnAccount": "Already have an account?"
},
"Settings": {
"language": "Language",
"theme": "Dark theme",
"logout": "Logout"
}
}
}
Використовується формат даних - JSON. JSON - JavaScript Object
Notation. В цьому форматі мові JavaScript найбільш просто розуміти дані.
Стосовно другого пункту. Таким чином ми можемо валідувати
форми в додатку.
Файл з валідацією знаходиться на тому ж рівні, що й основний
компонент і стилі до нього. Це також видно з імпорту файлу.
Файл валідації виглядає таким чином:
import { z } from 'zod';
import { zodResolver } from '@hookform/resolvers/zod';
import { useAppForm } from '../../hooks';
44
export enum LoginFields {
Login = 'Login',
Password = 'Password',
}
export const loginDefaultValues = {
[LoginFields.Login]: '',
[LoginFields.Password]: '',
};
export const loginValidation = z.object({
[LoginFields.Login]: z.string().min(4),
[LoginFields.Password]: z.string().min(8),
});
export const useLoginForm = () =>
useAppForm({
defaultValues: loginDefaultValues,
resolver: zodResolver(loginValidation),
});
Додаток використовує бібліотеку zod для валідації значень форм.
Таким чином отримуємо результат, представлений на рисунку 3.1.
45
Рисунок 3.1 – Екранна форма «Авторизація»
3.3 База даних
Реляційні бази даних – це бази, що використовують реляційний
концепт за основу своєї роботи та імплементують стандарт SQL.
В стандарті SQL прописана специфікація до мови SQL.
SQL (Structured Query Language) це мова, завдяки якій здійснюється
додавання, редагування та видалення даних із таблиць. Також мова
підтримує деякі операції з управління параметрами таблички.
Це обширний і потужний інструмент, завдяки якому можливо
комбінувати, сортувати, перетворювати дані.
В рамках управління структурою та деякими службовими функціями
користувач системи менеджменту бази даних може за допомогою неї
редагувати таблиці, зв’язки між ними, колонки, редагувати та
налаштовувати права доступу до схем, налаштовувати користувачів, тощо.
Розглянемо приклад мови SQL:
SELECT * FROM users WHERE id = 3;
46
Таким чином ми можемо робити запити на отримання певних
даних.
Розглянемо типи зв’язків між таблицями.
One-to-one - для кожного запису в одній табличці може існувати
тільки один запис в іншій.
One-to-Many або Many-to-One - Використовується для представлення
ситуацій, коли у однієї сутності одного типу може бути декілька сутностей
іншого типу.
Many-to-Many - Використовується щоб мати двосторонній зв’язок
між двома сутностями.
До прикладу, у кожної машини є двигун. Але один і той же двигун
ставився і на інші машини. Так само і з іншої сторони: на одну й ту ж
модель машини могли встановлювати різні двигуни.
В ході роботи над додатком було виведено таблиці та зв’язки між
ними, що потрібні для збереження інформації. Завдяки цьому вдалось
отримати базу даних, структура якої представлена на рисунку 3.2.
47
Рисунок 3.2 – Структура бази даних
Розглянемо кожну таблицю окремо та визначимо її призначення в
системі
Таблиця Preferences – використовується системою для збереження
користувацьких налаштувань. На даний момент вона зберігає
ідентифікатори користувачів, чиї настройки зберігаються (user_id), опцію
використання темної теми (dark_theme), мову додатку (language), опцію
збереження даних до Google Spreadsheets (backup_to_gsheets), опцію
створення події в календарі (create_calendar_event).
48
Таблиця 3.1 – Таблиця Preferences
Preferences
id Integer, autoincrement, unique, primary key, not
null
user_id Integer, foreign key, not null
dark_theme Boolean, not null
language Varchar(64), not null
backup_to_gsheets Boolean, not null
create_calendar_event Boolean, not null
Таблиця Users – зберігає ідентифікатор користувача Google
(google_id). Так як єдиним і основним механізмом авторизації в додатку є
Google Auth API, то це все, що нам потрібно зберігати для авторизації
користувачів.
Таблиця 3.2 – Таблиця Users
Users
id Integer, autoincrement, unique, primary key, not
null
google_id Varchar(256), unique, not null
Таблиця Services – містить список усіх служб, з якими є інтеграція в
додатку. В цій таблиці зберігається назва служби (name) і тип служби
(type_id), до якого ця служба відноситься.
49
Таблиця 3.3 – Таблиця Services
Services
id Integer, autoincrement, unique, primary key, not
null
name Varchar(256), not null
type_id Integer, foreign key, not null
Таблиця Addresses – містить дані користувачів, що обумовлені
колонкою user_id. В даній таблиці зберігаються дані щодо назв вулиць
(street_name), номерів будинків (building_number) та номерів квартир
(apartment_number).
Таблиця 3.4 – Таблиця Addresses
Addresses
id Number, autoincrement, unique, primary key, not
null
street_name Varchar(256), not null
building_number Varchar(256), not null
apartment_number Varchar(256), null
user_id Number, foreign key, not null
Таблиця Counters – зберігає показники лічильників (value) для
різних служб різних користувачів системи (user_service_id) за певний
місяць (submission_date).
50
Таблиця 3.5 – Таблиця Counters
Counters
id Integer, autoincrement, unique, primary key, not
null
user_service_id Integer, foreign key, not null
value Number, not null
submission_date Date, not null
Таблиця ServiceTypes – містить ім’я типу сервісу. Сервіси в системі
поділені на такі категорії: електроенергія, газ, гаряча вода, холодна вода.
Таблиця 3.6 – Таблиця ServiceTypes
ServiceTypes
id Integer, autoincrement, unique, primary key, not
null
name Varchar(256), not null
Таблиця Users_Services – використовується для визначення зв’язків
між службами (service_id), користувачами (user_id) та адресами
(address_id). Також містить інформацію про авторизацію на ресурсі
служби (token) та обліковий номер, виданий службою (account_number).
51
Таблиця 3.7 – Таблиця Users_Services
Users_Services
id Number, autoincrement, unique,
primary key, not null
service_id Integer, foreign key, not null
user_id Integer, foreign key, not null
address_id Integer, foreign key, not null
token Varchar(256), not null
account_number Integer, not null
Це базова частина таблиць, що необхідна для коректної роботи
додатку.
Також система розрахована на розширення функціональних
можливостей та великого навантаження.
52
РОЗДІЛ 4 ДОСЛІДЖЕННЯ АВТОМАТИЗОВАНОЇ СИСТЕМИ
ЗБЕРІГАННЯ ТА ПЕРЕДАВАННЯ ПОКАЗНИКІВ ЛІЧИЛЬНИКІВ
ДО КОМУНАЛЬНИХ СЛУЖБ
Розглянемо та дослідимо результат роботи – готовий додаток.
Перевіримо, що додаток відповідає критеріям, що були задані в
технічному завданні та описані у вступі.
4.1 Інтерфейс користувача
На рисунку 4.1 представлено сукупність екранних форм, що було
створено та зв’язки між ними.
53
Рисунок 4.1 – Екранні форми веб-додатку та зв’язки між ними
Розглянемо кожну екранну форму окремо і визначимо, які
функціональні можливості кожна з них надає.
Екранна форма «Авторизація»
Екранна форма «Авторизація» служить для виконання входу в
додаток за допомогою Google Auth API (рисунок 4.2).
54
Рисунок 4.2 – Екранна форма «Авторизація»
Екранна форма «Адреси»
Екранна форма «Адреси» використовується для менеджменту адрес
та переходу в якусь конкретну за для подачі показників (рисунок 4.3).
55
Рисунок 4.3 – Екранна форма «Адреси»
Екранна форма «Додавання адреси»
В екранній формі «Додавання адреси» користувач може заповнити
свою назву вулиці, номер будинку та номер квартири (якщо додається не
приватний будинок де немає квартир). Ці дані будуть використані при
додаванні служб до адреси (рисунок 4.4).
56
Рисунок 4.4 – Екранна форма «Додавання адреси»
Екранна форма «Перелік служб»
В даній екранній формі «Перелік служб» користувач може обрати
службу для подання показників чи перегляду історії.
57
Рисунок 4.5 – Екранна форма «Перелік служб»
Екранна форма «Історія»
Екранна форма «Історія» дозволяє користувачу переглянути історію
поданих показників. Також ця сторінка дозволяє подаки показник
58
лічильника. В майбутньому на цій сторінці також можна буде переглянути
графік витрат виходячи з показників лічильників.
Рисунок 4.6 – Екранна форма «Історія»
59
Екранна форма «Введення показників лічильників»
Екранна форма «Введення показників лічильників» відповідає за
одну з основних функціональних можливостей додатку – передачу
показників лічильників.
Рисунок 4.7 – Екранна форма «Введення показників лічильників»
60
Маючи дизайн, описаний та продемонстрований вище, можемо
створити візуальну частину додатку на основі даного дизайну.
4.2 Лістинг екранів
Переглянемо лістинг екранів, що було створено в ході роботи:
Рисунок 4.8 – Екран «Адреси»
Екран «Адреси» – використовується щоб переглянути доступні
адреси, додати нову адресу, а також вибрати адресу із списку доступних
(попередньо доданих адрес). Екран доступний тільки для авторизованого
користувача.
61
Рисунок 4.9 – Екран «Налаштування»
Екран «Налаштування» – використовується, щоб змінювати мову
додатку (наразі доступна українська та англійська мови), змінювати тему
додатку (світла або темна тема, світла використовується за
замовчуванням) та вийти з акаунту. Екран доступний тільки для
авторизованого користувача.
62
Рисунок 4.10 – Екран «Передача показань за адресою»
Екран «Передача показань за адресою» – використовується, щоб
передати показання до служб або служби. При переданні не всіх служб,
наступний раз екран буде відображати тільки не передані служби для
обраної адреси. Екран доступний тільки для авторизованого користувача.
63
Рисунок 4.11 – Форма «Додати адресу»
Форма «Додати адресу» – надає можливість користувачу додати
адресу. Форма доступна тільки для авторизованого користувача.
Рисунок 4.12 – Екран «Увійти»
Екран «Увійти» – надає вже зареєстрованому користувачу
можливість увійти до акаунту.
64
Рисунок 4.13 – Екран «Реєстрація»
Екран «Реєстрація» – надає можливість користувачу зареєструватись
в системі.
4.3 Серверна частина додатку
Для розробки серверної частини додатку (мається на увазі back-end
частина) потрібно:
 описати бізнес-логіку;
 провести аналіз технологічних рішень;
 створити високорівневу структуру серверу;
 визначити складність частин структури серверу.
Після цього можна почати розробку серверної частини,
використовуючи обрану технологію.
65
Опис бізнес-логіки
Виходячи з технічного завдання можна виділити бізнес-логіку, що
повинна бути реалізована. Основним функціоналом системи є подача
показників. Вона може бути реалізована за допомогою формування
стандартизованого API та інтеграції з сайтами різних комунальних служб.
Задля стандартизації та враховуючи можливу потребу в розширенні
на інші ринки, служби краще всього поділити на типи для простішого
менеджменту та роботою з ними. Враховуючи доменну область додатку
можна поділити служби по типах наданих послуг. Бізнес-сторона питання
реалізації додатку повинна також враховувати вартість тих чи інших
рішень в короткостроковому періоді та на довгий термін.
Аналіз технологічних рішень
Технологічні рішення можна розглянути за цінністю, яку вони
приносять в проект. Таким чином потрібно дотримуватись збалансованої
безпеки даних та додатку, функціоналу додатку, ефективності коду та його
роботи, часу на реалізацію нового функціоналу та на підтримку і
виправлення існуючого. Саме тому було обрано використання JavaScript-
технологій для швидкого досягнення результатів та достатньо високого
рівня захисту додатку. Також в порівнянні з технологіями Java чи Python
підтримка такого коду та додання нових функціональних та інших
можливостей до додатку обходиться дешевше по витратам часу та
складності.
Створення високорівневої структури
Створимо базову високорівневу структуру додатку (рисунок 4.14),
так як більш низькорівневу та детальну структуру було показано вище.
66
Рисунок 4.14 – Високорівнева структура додатку
Опишемо хід дій, що відбувається при основних операціях.
Користувач заходить до додатку та хоче подивитись історію
показників. Для цього система спочатку використає необхідну сторінку на
front-end, потім відправить HTTP-запит на back-end. Back-end тим часом
зробить SQL-запит до бази даних, яка містить дану інформацію.
Візьмемо ситуацію, коли потрібно подати показник. Для цього front-
end зробить HTTP-запит на backend, який, в свою чергу, зробить HTTP-
запит до потрібного сервісу за допомогою Service API. Після цього дані
опиняться на backend і запишуться в базу, а також відобразяться на front-
end.
Визначення складності частин структури серверу
Задача front-end частини додатку достатньо проста і буде
ускладнюватись з доданням функціональних можливостей в майбутньому.
Back-end являється як посередником між сервісами та front-end, так і
між базою та front-end і виконує дуже важливу роль в системі. Також
Services API знаходиться на back-end.
67
База даних не може бути високо навантаженою а її структура
достатньо проста, тому в даному випадку вона не становить складності в
обслуговуванні, підтримці та модифікації.
4.4 Розробка математичної моделі
В ході розробки додатку також постало питання про розробку
математичної моделі для розпізнавання цифр з поверхонь (в нашому
випадку з лічильників).
Тож спочатку потрібно розглянути більш детально саме цю частину
системи, потім провести її декомпозицію на складові частини і створити
модель, за допомогою якої можливо досягнути результату.
Пропоную почати з того, як людина сприймає цифри на лічильнику.
Предмети відбивають світло певною мірою та певними частинами
спектру видимих променів. Таким чином те, що людиною сприймається як
зелений колір означає, що предмет зеленого кольору поглинає промені, що
відповідають всім кольорам (виходячи з довжини хвилі), окрім зеленого.
Натомість зелений колір відбивається від предмета та потрапляє до
людини в очі.
Очі мають в своїй будові колбочки, що реагують певною мірою на
різні кольори. В залежності від кількості різних довжин хвиль, що
потрапляють до очей, останні формують електричний сигнал до мозку,
який обробляє його.
Таким чином насправді людина не вміє бачити, адже очі це просто
подразник на хвилі певних довжин. При подразненні виникає слабкий
потенціал, який далі інтерпретує мозок.
Як мозок розуміє, що саме перед ним?
68
Він робить це з власного досвіду а також з асоціативною пам’яттю.
Таким чином навіть якщо мозок не бачив ніколи в житті номер, написаний
від руки незнайомою йому людиною, він може зрозуміти цифри номера.
Це вдається зробити з одного боку тому що людина вже бачила багато
схожих цифр, а з іншого - тому що цифри мають певні характерні їм риси і
ознаки.
При створенні системи, що буде зчитувати показання лічильника та
перетворювати дані на картинці в текст із чисел потрібно:
1) Зібрати багато картинок різних лічильників в різних станах для
навчання штучного інтелекту
2) Для кожної картинки надати правильний показник
3) Створити модель з коефіцієнтами, так званими, “вагами”
4) Заохочувати штучний інтелект до навчання
В основі будь-якого інтелекту лежить поняття про перцептрон.
Таким чином, як у людини, так і у штучного інтелекту є:
Рецептори - частини, що сприймають сигнал.
Мережа нейронних зв’язків – або декілька рівнів обробки інформації
перед віддачею на ефектори. Перший рівень завжди приймає сигнал або
дані з рецепторів.
Останній рівень завжди віддає сигнал або дані ефекторам.
Ефектори – частини, що реагують на основі обробленої інформації
певним чином.
У сучасному світі вже є цілі бібліотеки та фреймворки для
спрощення роботи з штучним інтелектом, агрегацією даних для навчання,
деякі алгоритми машинного навчання. Ця галузь зараз розвивається як
ніяка інша.
69
ВИСНОВКИ
В результаті виконання кваліфікаційної роботи магістра було
виконано дослідження і синтез автоматизованої системи зберігання та
передавання показників лічильників до комунальних служб. Розроблений
веб-додаток дозволяє передавати показники лічильників всіх комунальних
служб, що використовують лічильники для підрахунку вартості наданих
послуг в тій чи іншій мірі та зробити механізм подачі показників якомога
простішим.
При розробці веб-додатку було виконано аналіз сучасних web-
технологій та обрано для реалізації поставленого завдання фреймворк
Node.js, тому що він відповідає всім вимогам для розробки.
Всі задачі, які були поставлені в технічному завданні виконані, а
саме:
 створено та досліджено автоматизовану систему, за допомогою якої
буде можливо передавати показники лічильників до комунальних та
інших підприємств та переглядати історію передач показань за
попередні періоди;
 в розробці передбачена можливість користування системою як для
веб-пристроїв за допомогою браузера, так і за допомогою
мобільного додатку для мобільних пристроїв з операційними
системами iOS та android.
В ході роботи над додатком було проведено аналіз вхідних критеріїв
системи, дослідження можливих варіантів при виборі інструментарію,
засобів та методів розробки, технологій та підходів до написання.
70
Також переглянули можливість та створили математичну модель,
завдяки якій вдалось створити штучний інтелект, що зчитує дані
показників лічильників.
Як результат отримали додаток, що доступний для користування на
мобільних операційних системах android та iOS, також доступний з будь-
якого пристрою з підтримкою браузера як web-додаток.
71
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Daly B., Daly B., Daly C. Web Development with Node and Express:
Leveraging the JavaScript Stack. – 2nd ed. – Sebastopol, CA : O’Reilly
Media, 2020. – 656 p.
2. Brown E. Web Development with Node and Express: Leveraging the
JavaScript Stack. – 2nd ed. – Sebastopol, CA : O’Reilly Media, 2020. –
656 p.
3. Casciaro M., Mammino L. Node.js Design Patterns: Design and
Implement Production-Grade Node.js Applications Using Proven Patterns
and Techniques. – 3rd ed. – Birmingham : Packt Publishing, 2020. – 664
p.
4. Powers S. Learning Node: Moving to the Server Side. – 2nd ed. –
Sebastopol, CA : O’Reilly Media, 2016. – 288 p.
5. Brown E. Web Development with Node and Express: Leveraging the
JavaScript Stack. – 2nd ed. – Sebastopol, CA : O’Reilly Media, 2020. –
656 p.
6. Powers S. Learning Node: Moving to the Server Side. – 2nd ed. –
Sebastopol, CA : O’Reilly Media, 2016. – 288 p.
7. Young A., Meck B., Cantelon M., Harter T. Node.js in Action. – 2nd ed.
– Shelter Island, NY : Manning Publications, 2017. – 432 p.
8. Fowler M. Refactoring: Improving the Design of Existing Code. – 2nd
ed. – Boston : Addison-Wesley Professional, 2018. – 448 p.
9. Duckett J. JavaScript and JQuery: Interactive Front-End Web
Development. – Indianapolis, IN : John Wiley & Sons, 2014. – 640 p.
72
10.Morgan N. JavaScript for Kids: A Playful Introduction to Programming.
– San Francisco : No Starch Press, 2014. – 336 p.
11.Duckett J. JavaScript and JQuery: Interactive Front-End Web
Development. – Indianapolis, IN : John Wiley & Sons, 2014. – 640 p.
12.Resig J., Bibeault B., Maras J. Secrets of the JavaScript Ninja. – 2nd ed. –
Shelter Island, NY : Manning Publications, 2016. – 536 p.
13.Nixon R. Learning PHP, MySQL & JavaScript: With jQuery, CSS &
HTML5. – 5th ed. – Sebastopol, CA : O’Reilly Media, 2018. – 820 p.
14.Flanagan D. JavaScript Pocket Reference. – 3rd ed. – Sebastopol, CA :
O’Reilly Media, 2014. – 280 p.
15.Хмарні технології [Електронний ресурс]. – Точка доступу: URL:
http://j.parus.ua/ua/358/ – Хмарні технології.
16.MDN Web Docs [Electronic resource]. – Access mode:
https://developer.mozilla.org/
17.Clean Architecture: A Craftsman’s Guide to Software Structure and
Design by Robert C. Martin, 2016
18.The art of project management by Scott Berkun, 2005
19.Clean Code: A Handbook of Agile Software Craftsmanship by Robert C.
Martin, 2007
20.Eloquent JavaScript 3rd edition by Marijn Haverbeke, 2018
21.Seven Databases in Seven Weeks: A Guide to Modern Databases and the
NoSQL Movement 1st Edition by Eric Redmond , Jim Wilson, 2012
Репозиторій ЧДТУ
