1

УДК 004.9КПN держреєстрації 0111U006119Інв. №

Міністерство освіти і науки УкраїниСумський державний університет

(СумДУ)40007, м.Суми, вул.Римського-Корсакова, 2;

тел. (0542) 33 53 83; факс 33 40 58

ЗАТВЕРДЖУЮПроректор з наукової роботи, д.ф-м.н., проф.__________________А.М.Чорноус__________________

ЗВIТ

ПРО НАУКОВО-ДОСЛIДНУ РОБОТУ

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

РОЗРОБКА МОДЕЛЕЙ ТА АЛГОРИТМІВ ВІЗУАЛІЗАЦІЇ ДАНИХ У РОЗПОДІЛЕНИХ СИСТЕМАХ

(заключний)

Начальник НДЧкандидат фіз.-мат. наук Д.І.Курбатов

Керівник НДРканд. техн. наук, доцент І.В. Баранова

2013

Рукопис закінчено 20 грудня 2013 р.

Результати цієї роботи розглянуто науковою радою СумДУ,протокол від 2013.12.26 №3

СПИСОК АВТОРІВ

Керівник НДР (2013.12.20) І.В.Барановаканд. техн. наук, доц. секції ІТП (розд. 1, 2)

Виконавець НДР, (2013.12.20) В. В. Шендрикканд. техн. наук, доц. секції ІТП (розд. 1,2,5)

Виконавець НДР, (2013.12.20) В. Г. Неняканд. техн. наук, доц. секції ІТП (розд. 1-3)

Виконавець НДР, (2013.12.20) О. В. Алексенкоканд. техн. наук, доц. секції ІТП (розд. 1,3)

Виконавець НДР, (2013.12.20) С. М. Ващенкоканд. техн. наук, ст. викладач секції ІТП (розд. 4)

Виконавець НДР, (2013.12.20) Ю. В. Парфененкопров. фахівець секції ІТП (розд. 1-3)

Виконавець НДР, (2013.12.20) О. В. Шулимааспірант (розд. 1,3, 4)

Виконавець НДР, (2013.12.20) Р. П. Окопнийаспірант (розд. 2,3)

Виконавець НДР, (2013.12.20) О. В. Духностудент (розд. 5)

Виконавець НДР, (2013.12.20) А. С. Богачовстудент (розд. 4)

Виконавець НДР, (2013.12.20) А. О. Бондаренкостудент (розд. 4)

Виконавець НДР, (2013.12.20) М.М. Прокловастудент (розд. 1,3)

Виконавець НДР, (2013.12.20) К. О. Овсієнкостудент (розд. 2, 3)

2

РЕФЕРАТ

Звіт про НДР: 91 с., 8 табл., 47 рис., 49 джерел.

Об'єкт дослідження: інформаційна технологія обробки інформації в

розподілених системах.

Мета роботи: аналіз теоретико-методологічних підходів до проблеми

моделювання та керування розподіленими інформаційними системами,

розробка моделей та методів обробки інформації в розподілених системах,

аналіз способів та розробка технології візуалізації даних.

Методи дослідження: системний аналіз, математичне моделювання,

теорія графів, теорія множин, СASE інструменти інформаційного моделювання,

теорія баз даних.

Результатом роботи є моделі інформаційного моніторингу та методика

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

діяльності, а також розроблення відповідного програмного забезпечення з

урахуванням автоматизації збору та обробки даних.

Рекомендації по використанню результатів роботи: на підґрунті

запропонованих моделей та інформаційної технології реалізовано інформаційні

системи моніторингу теплозабезпечення будівель та інтегроване середовище

управління міською інфраструктурою.

Галузь застосування: для підприємств управління міською

інфраструктурою, установ соціально-культурного та побутового призначення.

Значущість роботи i висновки: дозволяє удосконалити моделі обробки

даних та методи їх візуалізації в розподілених системах різного призначення.

Прогнозні припущення про розвиток об’єкту дослідження: повна

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

КЕРУВАННЯ, МОДЕЛЮВАННЯ, ІНФОРМАЦІЙНА ТЕХНОЛОГІЯ,

СИСТЕМНИЙ АНАЛІЗ, МОНІТОРИНГ, АГЕНТ, БАЗА ДАНИХ.

3

ЗМІСТ С.

ВСТУП....................................................................................................................…..7

1...................... АНАЛІЗ СИСТЕМ ЕНЕРГОЗАБЕЗПЕЧЕННЯ ЯК ОБ’ЄКТА

УПРАВЛІННЯ...........................................................................................................8

1.1 Науково-методологічні аспекти керування функціонуванням СТРТЕ………8

1.2 Обгрунтування методики побудови інформаційної моделі розподіленої

системи альтернативних джерел енергії………………………………………….15

2 ....................ІНФОРМАЦІЙНА СИСТЕМА МОНІТОРИНГУ Й АНАЛІЗУ

ТЕПЛОЗАБЕЗПЕЧЕННЯ БУДІВЕЛЬ................................................................19

2.1 Концептуальна модель інформаційної системи аналізу теплозабезпечення.19

2.2 Структурно-функціональний аналіз інформаційної системи моніторингу й

аналізу теплозабезпечення будівель………………………………………………22

2.3 Загальна архітектура інформаційної системи моніторингу й аналізу

теплозабезпечення будівель……………………………………………………….32

2.4 Аналіз способів забезпечення цілісності даних web-системи

теплозабезпечення…………………………………………………………………42

3 ІНФОРМАЦІЙНА ТЕХНОЛОГІЯ ВІЗУАЛІЗАЦІЇ ДАНИХ В

РОЗПОДІЛЕНИХ СИСТЕМАХ............................................................................49

3.1 Модель графічного відображення даних інформаційної системи обліку в

СТРТЕ……………………………………………………………………………….49

3.2 Вибір технології візуалізації даних при інформаційному моделюванні

розподіленої системи альтернативних джерел енергії………………………......56

4 РОЗПОДІЛЕНА ІНФОРМАЦІЙНА СИСТЕМА АВТОМАТИЗАЦІЇ

РОБОТИ СЕКРЕТАРЯ ДЕК.................................................................................60

4.1 Концептуальна модель інформаційної системи автоматизації роботи

секретаря ДЕК………………………………………………………………………60

4.2 Технологія реалізації інформаційної системи автоматизації роботи

секретаря ДЕК………………………………………………………………………63

4

5 МЕТОД ІНТЕГРАЦІЇ ІНФОРМАЦІЙНИХ СИСТЕМ УПРАВЛІННЯ

МІСЬКОЮ ІНФРАСТРУКТУРОЮ.....................................................................65

5.1 Методика розроблення інтегрованого інформаційного середовища.............65

5.2 Архітектура інтегрованої інформаційної системи управління……………...78

ВИСНОВКИ.......…………………………………………………………………..85

ПЕРЕЛІК ПОСИЛАНЬ..........................................................................................86

5

ПЕРЕЛІК УМОВНИХ СКОРОЧЕНЬ

Скорочення, термін,

позначення

Пояснення

СТРТЕ Система транспортування й розподілу теплової

енергіїМТ Мережа теплопостачання

СТ Система теплозабезпечення

СЕ Система енергетики

АСУ Автоматизована система управління

ІАСУ Інформаційно-аналітична автоматизована

система управління

СППР Система підтримки прийняття рішень

ГІС Географічна інформаційна система

СУБД Система управління базами даних

6

ВСТУП

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

окремі, предметно орієнтовані інформаційні системи, але це не дозволяє їм

оперативно та ефективно співпрацювати одна з одною.

На рівні управління організацією внаслідок розрізненості інформаційних

систем, що здійснюють управління її документообігом, неможливо досягти

достатнього рівня ефективності взаємодії між різними відділами та службами.

Необхідна для одного й того ж звіту інформація часто зберігається в декількох

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

Застосування можливостей сучасних інформаційних технологій дозволяє

реалізувати процес інтегрування декількох підсистем на рівні єдиної

розподіленох системи зі зручним інтерфейсом взаємодії з користувачем.

На рівні управління міським господарством це дозволить ефективніше та

швидше обмінюватися інформацією між установами та між громадянами міста,

скоротити витрати часу на оформлення різних документів, оплату рахунків,

оформлення замовлень, організацію подій, дозволить краще співпрацювати між

організаціями однакової сфери, але з різними наборами послуг, які залежать або

використовують послуги одна одної.

При вирішенні задачі управління теплозабезпеченням будівель

бюджетної сфери запровадження єдиної інформаційної системи моніторингу

споживання теплової енергії дозволить організувати роботу установи більш

ритмічно, оскільки зведе до мінімуму можливість виникнення кризових

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

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

обліку, подбати про перевірку достовірності даних,

Таким чином метою даної роботи є розробка науково-методологічних

основ розробки та програмних засобів реалізації розподілених інформаційних

систем при вирішенні різних прикладних задач.

7

1 АНАЛІЗ СИСТЕМ ЕНЕРГОЗАБЕЗПЕЧЕННЯ ЯК ОБ’ЄКТА

УПРАВЛІННЯ

1.1 Науково-методологічні аспекти керування функціонуванням СТРТЕ

Теплозабезпечення підприємств та населення м.Суми здійснюється за

рахунок поєднання централізованого, автономного та індивідуального

опалення. За даними [1] загальний річний обсяг споживання централізованої

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

для потреб народного господарства складає 325 тис. Гкал, для житлових

приміщень – 1115 тис. Гкал, для установ та організацій бюджетної сфери –

300 тис. Гкал. Втрати теплової енергії, зокрема при її транспортуванні,

перевищують середній рівень по Україні та складають близько 18%. Таким

чином понаднормове використання теплової енергії та значні її втрати

зумовлюють підвищення тарифів на житлово-комунальні послуги.

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

основних чинників, таких як неефективність керування та енергоємність

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

теплоенергетики України відслідковуються два шляхи: заміна морально

застарілого та фізично зношеного обладнання на більш сучасне та помірна

децентралізація теплопостачання [2]. Застосування сучасних інформаційних

технологій при вирішенні питання керування функціонуванням СТРТЕ є одним

із механізмів підвищення ефективності даного процесу.

Напрямок досліджень, що розглядає галузь енергетики як сукупність

систем, що перебувають в стані неперервного розвитку, започаткував

Мелентьєв Л.А. В подальшому при проведенні міждисциплінарних досліджень

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

8

енергетичних установок (Попирін Л.С.), режимів електроенергетичних систем

(Крумм Л.А.) та трубопровідних систем (Меренков А.П., Хасилев В.Я.).

В роботі [3] сформульовано компоненти системного підходу, що

стосуються дослідження енергетичної галузі, а саме:

врахування зв’язків досліджуваної системи з навколишнім

середовищем;

ієрархічне подання внутрішньої структури об’єкта системного

дослідження та процесів управління ним, тобто всі процеси мають

розглядатися з позицій закономірностей цілого та взаємодії його

частин;

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

багатокритеріальністю та ін. факторами;

застосування математичних методів та ЕОМ.

Місце систем транспортування й розподілу теплової енергії серед інших

систем наведено в табл.1.1.

Таблиця 1.1 – Місце СТРТ в ієрархії системКлас систем Характерні ознакиСистеми взагалі Впорядковані множини структурно

взаємопов’язаних та функціонально взаємозалежних елементів, які володіють новою якістю, не притаманною окремим елементам

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

Великі системи енергетики (СЕ) Різновид великих виробничих систем; складні ієрархічні системи, призначені для виробництва, розподілу та споживання енергії.

Системи теплозабезпечення (СТ) Різновид великих систем енергетики, призначені для виробництва, розподілу та споживання теплової енергії.

Системи транспортування й розподілу теплової енергії (СТРТ)

Підстистеми СТ, складні системи, що призначені для транспортування теплоносія та розподілу його між споживачами.

У розглянутій ієрархії систем в якості кінцевих елементів СТРТ

виступають джерело теплоти (процес виробництва теплової енергії дана

9

підсистема не охоплює), що подає в трубопровідну мережу (МТ) теплоносій з

певними параметрами та кінцевий споживач послуг з теплопостачання.

Функціональну структуру СТРТ наведено в [4].

Властивості, що притаманні СЕ можна умовно розділити на чотири

групи: структури, розвитку, функціонування та можливості управління

ними [5]. Структурні властивості вказують на цілісніть та узгодженість на

різних рівнях ієрархії. Властивості розвитку характеризують динамічність змін

параметрів СЕ при необхідності сталості основних показників її

функціонування, тобто прояву стабільності. Властивостями функціонування є

кономічність та надійність.

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

властивостей СТ, як властивість неповности інформації, що є результатом

складності внутрішньої структури та наявності зовнішніх факторів впливу.

Властивість недостатньої визначеності полягає у відсутності єдиного

оптимального рішення щодо функціонування та розвитку СТ з точки зору

критерія управління. На кожному з рівнів управління приймаються різні тип

рішень, що є проявом властивості багатокритеріальності. СТРТ має власні

специфічні особливості, які виділяють її серед систем енергетики та

ускладнюють управління даним класом систем.

До структурних особливостей відносимо значну територіальну

протяжність та розгалудженість, використання декількох джерел теплоти, до

функціональних – необхідність регулювання не самого продукту передачі

(теплоносія), а його параметрів (тиску та температури), що відрізняються за

фізичною сутністю, значна інерційність процесів, вплив на них зовнішнього

середовища.

Процес теплоспоживання характеризується нерівномірністю, так в

управлінні доводиться орієнтуватися на найбільш віддаленого від джерела

споживача.

СТРТ як об’єкт управління характеризується рядом невизначеностей [6]:

10

невизначеність моделей СТРТ, що пов’язана з нестаціонарністю

процесів, що в ній протікають;

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

характером кліматичного фактору та режимами теплоспоживання

(сезонність, графік роботи споживача).

невизначеність критеріїв управління – на різних рівнях управління

пріорітетними є різні цілі, загальна стратегія на енергозбереження

на вищому рівні управління, при цьому дотримання для кінцевого

споживача нормативних умов у приміщеннях.

Таким чином СТ (у тому числі й СТРТ) є системою, що має складну

ієрархічну структуру, знаходиться в постійному розвитку зі зміною складу її

елементів та зв’язків між ними, а також вимагає наявності органів управління

нею, тобто належить до класу людино-машинних систем.

Комп’ютеризація управління СТ, впровадження автоматизованих систем

управління (АСУ) є одним із засобів підвищення ефективного функціонування

даного класу систем. Основні напрямки дослідження в галузі

теплозабезпечення, у тому числі й із застосуванням інформаційних технологій

та засобів автоматизації наведені в табл.2.

Значний потенціал ефективної експлуатації СТ, забезпечення можливості

енергозбереження міститься заходах, пов’язаних із впровадженням

автоматизованих інформаційно-аналітичних систем управління (ІАСУ) для

забезпечення управління режимами функціонування СТ. Зміст цих задач

(рис. 1.1) полягає в постійному моніторингу поточного стану СТ, у

представленні інформації у формі, зручній для прийняття рішень, розробці

імітаційних, оптимізаційних та прогнозних математичних моделей, що

дозволяють опрацьовувати різні варінти управління.

11

Рисунок 1.1 – Задачі управління СТРТ

Основні принципи автоматизації СТ викладено в роботах Монахова Г.В.,

Чистовича С.А, Дубового В.М. [7-9]. Моніторинг як одна із функціональних

задач ІАСУ здійснюється для одержання оперативної інформації про

функціонування об’єкта управління, стан зовнішнього середовища. Він

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

забезпечує повноту і своєчасність подання інформації, об'єктивність даних,

мінімізація ризику помилковості даних, наявність алгоритмів обробки

інформації та подання її за запитом [10]. Сучасний стан розвитку

інформаційних і телекомунікаційних технологій характеризується

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

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

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

випадку система моніторингу повинна виконувати наступні функції:

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

спеціалізованому вигляді, перетворення їх у формат, зручний для передачі по

СТРТзадача управління

Моніторинг ОптимізаціяАналіз Прийняття рішень

фактичного споживання теплових ресурсів

параметрів зовнішнього середовища

параметрів функціонування СТРТ

якості надання послуг

математичнемоделювання потокорозподілу

імітаційне моделювання

еквівалентування схем теплових мереж

споживання теплової енергії

потокорозподілу

структрури (схеми) теплової мережі

розташування вимірювальних пристроїв

розподілу теплового навантаження між джерелами теплопостачання

усунення втрат теплової енергії

регулювання кількості спожитої теплової енергії

усунення можливих аварійних ситуацій шляхом діагностування несправностей обладнання

12

каналу зв’язку; архівування інформації в базі даних; візуалізація результатів

аналізу даних у формі, графіків,діаграм, стандартизованих звітів для підтримки

прийняття рішень і управління всистемі інженерних комунікацій; забезпечення

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

web-інтерфейс незалежно від програмної платформи.

На сьогоднішній день існує декілька різновидів систем такого класу, які

відрізняються функціональною спрямованістю, модифікацією встановленого

обладнання, його вартістю, протоколами передачі даних тощо. В роботі [11]

Фіногеєвим А.М. представлено систему моніторингу теплової мережі з

використанням бездротових технологій передачі даних ZigBee для

оперативного інформування аварійних бригад. З її допомогою можна

прогнозувати, дистанційно детектувати та своєчасно визначати місця

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

працездатності інженерної мережі. Архітектура інформаційної системи

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

технології передачі даних GPRS/GSM та наявністю web-інтерфейсу

представлення даних моніторингу описана в роботі [12]. Системи моніторинга

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

енегрозабезпеченням. При розробці таких систем використовуються технології

автоматизації й диспетчерського управління SCADA [13-14], а також концепції

розробки систем на основі взамодіючих між собою програмних агентів [15].

Одним із засобів аналізу поточних режимів функціонування СТ є

моделювання. Застосування методів динамічного програмування при

моделюванні СТ дозволило підвищити точність моделювання, здійснивши

перехід від дискретних до неперервних, змінних у часі параметрів, виконувати

апроксимацію нелінійних залежностей, вводити припущення, використовувати

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

Моделювання систем теплозабезпечення (СТ) також застосовується для

вирішення оптимізаційних задач. Хасилевим В.Я. поставлена та вирішена

задача оптимізації параметрів теплової мережі, а саме вибору опору її гілок та

13

розрахунок витрат теплоносія та втрат тиску по кожній з гілок мережі. Ця

задача програмування була вирішена з використанням методу динамічного,

коли оптимізаційні обмеження задаються не лише технічними,

конструктривними параметрами (наприклад, діаметри трубопроводів), а й

соціальними (забезпечення найності при транспортування теплової енергії,

вимоги задоволення комфортних умов в опалювальних приміщеннях).

Хасилевим В.Я. та Некрасовою О.А. були сформульовані задачі схемно-

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

розташуванняі потужності джерел) та пошуку найвигіднішого потокорозподілу

в різних варіантах схем мережі. Вони вирішували задачі оптимізації схеми

теплової мережі шляхом вибору розмірів ділянок теплової мережі з метою

мінімізації втрат теплової енергії теплоносія при його транспортуванні методом

кінцевих елементів.

Застосування технології імітаційного моделювання дозволяє поєднати

процеси дослідження СТ і прийняття рішень при управлінні їх

функціонуванням, розглядаючи СТ як велику динамічну систему. Системи

імітаційного моделювання для встановлення початкових параметрів теплової

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

Таким чином вирішення задачі управління функціонуванням СТРТ

вимагає попереднього відображення в математичних та імітаційних моделях

фактичної топології і структури конкретних систем, технічних особливостей їх

організації, впливу факторів зовнішнього середовища, а також оперативного

моніторингу зміни фактичних параметрів функціонування.

Основними задачами управління теплозабезпеченням будівель є

забезпечення комфортних умов в опалювальних приміщенням, економія

споживання енергетичних ресурсів, підвищення найдійності систем

теплозабезпечення при їх експлуатації.

14

1.2 Обгрунтування методики побудови інформаційної моделі

розподіленої системи альтернативних джерел енергії

Існуючі сьогодні технології не дозволяють побудувати стійку

енергетичну систему, що використовує тільки альтернативні види енергії.

Інтеграція таких джерел з традиційними має безліч проблем. При цьому

використання альтернативних джерел енергії частково вирішує задачу

досягнення балансу між користувачем і генерацією як на макро , так і на мікро

рівні.

Існує кілька варіантів використання тих чи інших ВДЕ, але географічні

умови і система енергопостачання можуть мати значні відмінності по всій

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

об'єднання даних у загальну систему , яка дозволить скоротити час на аналіз

доцільності використання ВДЕ .

Висока вартість побудови нових енергомереж, витрати на

транспортування і втрати корисної електроенергії також вимагають

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

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

існуючої мікромережі.

В [16] авторами була запропонована наступна класифікація моделей для

побудови енергетичних систем:

Енергетичні моделі попиту та пропозиції.

Прогнозні моделі:

Енергетичні моделі для економічних показників.

Моделі для ВДЕ:

Моделі для сонячної енергетики.

Моделей для біомаси та біоенергії.

Оптимізаційні моделі.

Енергетичні моделі на основі нейронних мереж.

15

Моделі для скорочення викидів.

Дані моделі можна об'єднувати у більш складні, використовувати для

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

системі існує необхідність отримання зведеної інформації по роботі мережі,

отриманні рекомендацій тощо Для цього можуть створюватися системи

підтримки прийняття рішень (СППР). Згідно [17] СППР – це інтерактивна

система, здатна виробляти дані та інформацію а, в деяких випадках, сприяти

розумінню відносяться до даної предметної області з метою надати корисну

допомогу у вирішенні складних і погано певних завдань.

Можна виділити три напрями розвитку СППР в енергозабезпеченні

будівель за кількістю відновлюваних джерел енергії (ВДЕ). Перші

використовують одне джерело альтернативної електроенергії, інші комбінують

джерела енергії, як тепло, так і електроенергії.

Існуючі СППР відрізняються залежно від функціональних можливостей:

використовуються різні багатокритеріальні підходи, способи розрахунку

технічних характеристик; а також від способу подання даних. Вхідні параметри

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

географії, архітектурі, міських інженерних систем і т.д.

В роботі [17] представлений інструмент для планування ресурсів та

управління ними, який використовує Multi- criteria decision analysis (MCDA), а

також метод NAIADE для пошуку компромісного рішення в нечіткому

середовищі прийняття рішень. Підхід NAIADE передбачає будівництво матриці

оцінки, яка включає в себе, по одній осі, обмежений набір альтернатив, а з

іншого боку, обмежений набір різних критеріїв, за якими такі альтернативи

повинні бути оцінені, далі використовується порівняння пар альтернатив.

В роботі [18] запропоновано використовувати інтегровану систему, що

використовує сонячну і вітрову енергію, показники розраховуються щогодини.

Як аварійні засоби для ізольованих ділянок подачі електроенергії

запропоновані дизельний генератор і акумуляторна батарея.

16

В основу кінцевого вибору установки покладена функція мінімізації

витрат, яка враховує вартість життєвого циклу установки.

Згідно [19] була побудована розподілена система управління енергією в

будівлях реального часу в Capo Vado ( Liguria Region ), яка дозволяє визначити

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

поновлюваних ресурсів. Для розрахунків використовують один сонячний

колектор, фотоелектричні модулі, один пристрій перетворення біомаси, вітрову

турбіну і одну акумуляторну батарею. СППР дозволяє визначити час

найбільшої генерації енергії від різних джерел енергії.

Для розрахунку енергії виробленої вітрової турбіною використовуються

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

регіоні , які надходять в систему щогодини. Енергія з фотоелектричних модулів

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

величини сонячної радіації. Енергія біомаси залежить від якісних (відсотка

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

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

від різних вимог до джерел .

Інформацію, отриману в "реальному" часі, можна імпортувати в

географічні інформаційні системи (ГІС) для проведення різних видів

просторового аналізу. Інформація про розташування обладнання, оцінка

потенціалу поновлюваних джерел може передаватися в систему для

забезпечення кращого розуміння розташування.

Деякі проекти вже побудовані, які пов'язують СППР та ГІС для оцінки

поновлюваних джерел енергії в розподіленої генерації електроенергії. Нижче

наведені деякі з існуючих.

В [20] методика призначена для визначення кращого місця для

використання нових енергетичних систем, але в даному проекті відсутня

дослідження енергосистеми. В роботі [21] ГІС використовується для оцінки

ГЕС. Система підтримки прийняття рішень в [22] з використанням ГІС

допомагає визначити переважне місце установки ВДЕ, вказує на потенційні

17

майданчики для установок ВДЕ, а потім аналізує поведінку мережі і

розподілених енергетичних систем.

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

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

дані про існуючі станціях з ВДЕ в регіонах, тому необхідно доповнювати і

розширювати представлені моделі.

Також універсальність моделі вимагає, додатково до інформації про

місцевість з рельєфом, комунікаціями (наземними і підземними), благоустроєм

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

будову і загальних інженерних систем.

У результаті повинна вийти досить складна СППР з безліччю складових

підсистем . Наступним етапом на шляху створення системи повинен стати збір

та аналіз інформації про потенціал ВДЕ в залежності від обраної території,

накопичення загальної бази даних, а також створення ГІС, як основи

майбутньої СППР.

Таким чином у даному розділі визначається актуальність побудови

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

використанні відновлювальних джерел енергії, шляхом аналізу сучасного стану

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

області альтернативної енергетики на території України.

18

2 ІНФОРМАЦІЙНА СИСТЕМА МОНІТОРИНГУ Й АНАЛІЗУ

ТЕПЛОЗАБЕЗПЕЧЕННЯ БУДІВЕЛЬ

2.1 Концептуальна модель інформаційної системи аналізу

теплозабезпечення

У загальному випадку систему теплопостачання S з точки зору її

функціонування будемо розглядати у вигляді кортежа S=<X,Y,R>. Вхідні

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

X=(x1, x2, .x3,…,xi, …xn), де xi – окремо взятий ресурс. Вектор вихідних

параметрів Y складається з елементів, які відповідають реалізації мети

функціонування системи: забезпечення послугами опалення та гарячого

водопостачання. Відношення R X×Y характеризує взаємозв’язок між вхідними

та вихідними елементами системи.

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

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

області, виділити її основні сутності, взаємозв’язки між ними. На

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

якої розробляється база даних, незалежно від сприйняття її окремими

користувачами та способів опису в комп’ютерній системі [23]. При розробці

даної інформаційно-аналітичної системи в якості експертів предметної галузі

виступили науковці групи з енергозбереження СумДУ.

Етап концептуального проектування передбачає опис предметної

області у термінах формальної мови. Широкого використання при побудові

концептуальної моделі бази даних набуло ER-моделювання. Першим етапом

побудови ER-діаграми є виділення сутностей. Системний аналіз предметної

області дав змогу побудувати концептуальну модель бази даних інформаційно-

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

[24].

19

Основними сутностями бази даних є КОРПУС, ЛІЧИЛЬНИК,

ЕНЕРГОМЕНЕДЖЕР, ТЕМПЕРАТУРНИЙ ГРАФІК, ДЕНЬ МОНІТОРИНГУ,

ДАНІ МОНІТОРИНГУ, РЕЗУЛЬТАТИ МОНІТОРИНГУ. На рис. 2.1 наведено

діаграму «сутність-зв’язок» (ER-діаграму) в нотації Чена, яка використовується

для опису бази даних інформаційно-аналітичної системи моніторингу та

прогнозування теплоспоживання на концептуальному рівні проектування.

Рисунок 2.1 – Діаграма сутність-зв’язок

Діаграма показана у спрощеному вигляді, атрибути сутностей не

представлені. Сутність ЕНЕРГОМЕНЕДЖЕР містить інформацію про

відповідальну особу за збирання даних моніторингу. Сутність ЛІЧИЛЬНИК

містить дані про об’єкт моніторингу.

Сутність КОРПУС містить дані про всі навчальні корпуси, їх площу,

кількість поверхів тощо. Множина сутностей ЛІЧИЛЬНИК пов’язана з

множиною сутностей КОРПУС зв’язком розміщено типу «один до багатьох».

Одержано

ДЕНЬМОНІТОРИНГУ

ТЕМПЕРАТУР-НИЙ

ГРАФІК

КОРПУСЕНЕРГО-МЕНЕДЖЕР Обслуговує

Розміщено

ЛІЧИЛЬНИКВстановлено

РЕЗУЛЬТАТИМОНІТОРИНГУ

Одержано

Розраховано

Розраховано

1

1

1

1

1 1

1

М

М М

М

М

М

М

ДАНІ МОНІТОРИНГУ

20

Розміщення лічильників теплової енергії передбачає, що один лічильник

встановлено для обліку теплоспоживання декількох корпусів.

Сутність ТЕМПЕРАТУРНИЙ ГРАФІК містить інформацію про

нормативні показники об’єкту моніторингу (тиски, температури, кількість

спожитої теплової енергії). Для кожного лічильника (об’єкту моніторингу)

встановлюється багато значень нормативних показників, які вибираються в

залежності від температури навколишнього середовища. Множина сутностей

ЛІЧИЛЬНИК пов’язана з множиною сутностей ТЕМПЕРАТУРНИЙ ГРАФІК

зв’язком встановлено типу «один до багатьох».

Сутність ДАНІ МОНІТОРИНГУ призначена для зберігання фактичних

даних, знятих з приладів обліку (тиски, температури, фактична кількість

спожитої теплової енергії). Сутність РЕЗУЛЬТАТИ МОНІТОРИНГУ містить

усі розрахункові показники, які використовуються для аналізу

теплоспоживання і є основою для прийняття рішень з його регулювання.

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

Особливістю роботи системи теплопостачання є її сезонність. Одиницею

часового відрізку при проведенні моніторингу та прогнозування є доба

опалювального сезону. Існує декілька типів баз даних в залежності від

реалізації аспектів часу: бази даних знімків, історичні бази даних, бази даних

відкочувань [23].

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

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

дискретної осі дійсного часу, кожен відрізок якої дорівнює тривалості

опалювального сезону. Дійсний час проведення моніторингу (встановлений

енергоаудиторами час кожної доби опалювального сезону) є одним з атрибутів

сутності ДЕНЬ МОНІТОРИНГУ. Дана сутність містить атрибути, які пов’язано

лише з дійсним часом, а саме умови навколишнього середовища (температура,

швидкість вітру, вологість повітря).

На рис.2.2 наведено даталогічну модель бази даних, яку реалізовано в

MySQL [25].

21

Рисунок 2.2 – Модель бази даних

Значення температури дозволяє вибрати нормативні показники

теплоспоживання для конкретного об’єкту моніторингу з сутності

ТЕМПЕРАТУРНИЙ ГРАФІК. Для будь-якого об’єкту моніторинга

ЛІЧИЛЬНИК в один момент часу відбувається лише одна подія – зняття даних

з приладів обліку, тобто заповнення атрибутів сутності ДАНІ новими

значеннями.

2.2 Структурно-функціональний аналіз інформаційної системи

моніторингу й аналізу теплозабезпечення будівель

Узагальнену схему процесу моніторингу можна представити у вигляді,

зображеному на рис. 2.3.

Згідно до цієї схеми інформаційно-аналітична система моніторингу та

прогнозування має виконувати наступні функції [26]:

зняття інформації про стан об’єкта спостереження;

передачу інформації до серверу системи моніторингу;

обробку та зберігання інформації;

представлення та використання інформації.

22

Рисунок 2.3 – Процес моніторингу теплозабезпечення в загальному

вигляді

Здійснення процесу моніторингу та прогнозу у загальному випадку

передбачає обов'язкову наявність:

об'єкта спостереження;

зовнішнього середовища;

технічних засобів збору інформації;

програмних засобів збору та передачі інформації;

засобів зберігання інформації;

алгоритмів їх математичної обробки;

надання інформації оператору для прийняття рішень.

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

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

про зовнішнє середовище включає інформацію про добову температуру повітря

в м. Суми, що надходить від українського Гідрометцентру. Необхідні

показники моніторингу наведено в [27].

Як бачимо з рис. 2.3, процес моніторингу не обмежується збиранням

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

механізм формування звітів та видачі рекомендацій щодо керування

функціонуванням СТРТЕ.

Тобто, після збору і аналізу даних подаються звіти на вищий рівень

управління, а також, в разі необхідності, надаються рекомендації щодо

підвищення ефективності використання теплової енергії в закладі, де

проводиться енергоаудит.

навколишнє середовище

теплозабезпечення будівель

аналіз даних

збір даних прийняття рішень щодо регулювання

23

Аналіз даних включає:

перевірку відповідності, отриманих від теплопостачаючих

організацій даних;

розрахунок можливої економії теплової енергії;

порівняння теплоспоживання за поточний місяць з тепло

споживанням за аналогічний період року;

порівняння теплоспоживання за поточний період та

аналогічний період минулих років;

виявлення відхилень в теплоспоживанні і з’ясування їх

причин.

Після проведення аналізу системи теплозабезпечення будівель СумДУ

виявлено 12 приладів обліку теплової енергії на всі будівлі Сумського

державного університету:

Лічильник № 1: - корпус Ц, ЕТ, Г, бібліотека, лабораторний корпус,

ремстройгруппа.

Лічильник № 2: - гуртожиток № 2.

Лічильник № 3: - гуртожиток № 3.

Лічильник № 4: - медичний інститут, гуртожитки № 4, № 5 (+ лічильники

гарячої води).

Лічильник № 5: - басейн.

Лічильник № 6: - корпус М.

Лічильник № 7: - спортзал.

Лічильник № 8: - корпус Т.

Лічильник № 9: - лабораторний корпус, ввод № 2.

Лічильник № 10: - їдальня.

Лічильник № 11: - гуртожиток № 1.

Лічильник № 12: - НВК (Навчально-виробничий комплекс).

24

Схема розміщення лічильників теплової енергії показана на рис. 2.4. На

цій схемі показані всі корпуса СумДУ та в яких корпусах знаходяться прилади

обліку теплової енергії.

Система теплозабезпечення СумДУ є територіально розподіленою,

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

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

моніторингу.

Рисунок 2.4 – Схема розміщення лічильників теплової енергії у будівлях СумДУ

При розробці системи моніторингу важливою складовою на перших

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

Л. №6

Л. №8

Л. №4

Л. №11

Л. №9

Л. №5

Л. №1

ЕТЦ

НВ

К

БК

спорт-комплекс

М

Т

Їдал

ьня

с А Б

Г. №1

Басейн

Г

Г. №4

Г. №5

Мед

інст

итут

Г. №

3

Г. №

2

Л. №7Л. №12

Л. №10

Л. №2

25

Л. №3

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

Відомості про всі дані, які використовуються системою моніторингу, описані

нижче в табл. 2.1, 2.2 та 2.3.

В табл. 2.1 показано вхідні дані, тобто дані, які будуть зніматися та

вноситися в систему з теплолічильників, з сайту про погодні умови, а також

сталі величини, які будуть братися з температурного графіка постачальника

тепла.

В табл. 2.2 показано розрахункові дані, тобто дані, які будуть

використовуватися в розрахунках.

В табл. 2.3 показані вихідні дані, тобто результат роботи системи

моніторингу.

Таблиця 2.1 – Вхідні дані

Назва Позначення

Вимірювання

Звідки беруться дані

Температура теплоносія прямого (фактична)

Т1 ºС З теплолічильника

Температура теплоносія зворотного (фактична)

Т2 ºС З теплолічильника

Витрата теплоносія (фактична)

G м3/год З теплолічильника

Теплова потужність q Гкал/год З теплолічильникаЗначення показань

лічильника у момент зняттяА Гкал З теплолічильника

Температура теплоносія за елеватором на подачі

Т3 ºС З теплолічильника

Тиск на вході в будівлю перед елеватором

Р1 кг/см2 З теплолічильника

Тиск на виході із системи у зворотньому трубопроводі

Р2 кг/см2 З теплолічильника

Тиск на подаючому трубопроводі після елеватора

Р3 кг/см2 З теплолічильника

Значення коефіцієнта теплоти за фактичною температурі зовнішнього повітря

k К З таблиці температурного графіка постачальника

Фактична температура зовнішнього повітря

tфакт ° C З сайту Gismeteo

26

Швидкість вітру v м/с З сайту GismeteoНаправлення вітру n - З сайту Gismeteo

Таблиця 2.2 – Розрахункові дані

Назва Позначення

Вимірювання

Звідки беруться дані

Відхилення потужності годинного теплового навантаження

∆q Гкал/год ∆q=qрозрах - qфакт

Відхилення витрати теплоносія фактичної від розрахункового значення

∆G м3/год ∆G=Gфакт - Gрозрах

Добове споживання теплової енергії Qфакт Гкал/добу Qфакт=А-Б

Відхилення добового споживання теплової енергії ∆Q Гкал/добу ∆Q=Qфакт - Qрозрах

Відхилення температури Т1 фактичної від Т1 температурного графіка постачальника

∆Т1 ºС ∆Т1=Т1факт - Т1

Відхилення температури Т2 фактичної від Т2 температурного графіка постачальника

∆Т2 ºС ∆Т2=Т2факт - Т2

Відхилення температури Т3 фактичної від Т3 температурного графіка користувача (споживача)

∆Т3 ºС ∆Т3=Т3факт - Т3

Коефіцієнт підмішування фактичний Uфакт -

Uфакт=(Т1факт-Т3факт) / (Т3факт -

Т2факт)Коефіцієнт підмішування

розрахунковий Uрозрах кг/см2 Uрозрах=(Т1-Т3)/(Т3-Т2)

Відхилення коефіцієнту підмішування ∆U - ∆U=Uфакт-Uрозрах

27

Таблиця 2.3 – Вихідні дані

Назва Позначення

Вимірювання

Звідки беруться дані

Розрахункове добове споживання теплової енергії (ліміт технологічний прогнозний) за прогнозною tсер.н.пов

Qрозрах.прог

нозн.Гкал/добу

Розрахункове добове споживання теплової енергії (ліміт технологічний за фактичною температурою)

Qрозрах.за

факт.темп.Гкал/добу

Відхилення в теплоспоживанні будівлі - +/- Qрозрах.за факт.темп. -

Qрозрах.прогнозн

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

наступні множини вхідних даних, які можна класифікувати в залежності від

способу їх отримання:

внесення даних з приладів обліку, та датчиків

S = {data, T1f, T2f, T3f, Gf, qf, A, nomer_schetch},

де: data – дата показань лічильника,

T1f – середньодобова температура прямого теплоносія, (ºС)

T2f – середньодобова температура зворотнього теплоносія, (ºС)

T3f – середньодобова температура теплоносія після

змішування, (ºC)

Gf – миттєва середньодобова витрата теплоносія, (м3/год)

qf – миттєва середньодобова теплова потужність, (Гкал/год)

A – показник лічильника, (Гкал)

nomer_schetch – номер лічильника.

множина даних прогнозного стану погодних умов

G = {date, time, t},

де: date – дата, на яку зроблений прогноз;

time – час, за яким надаються кліматичні показники на сайті;

28

t – температура, (°С).

Множини формуються внаслідок збирання даних (з теплопунктів, даних

про погодні умови та інші) за визначені інтервали часу. Передбачено як

автоматичний збір даних (за допомогою терміналу власної конструкції), так і

можливість внесення даних за допомогою форм у ручному режимі (для даних,

які накопичились за попередні опалювальні періоди до впровадження

інформаційно-аналітичної системи теплоспоживання) [28].

Створення інформаційної моделі функціонування системи виконувалося

за допомогою CASE-засобу BPWin. На рис. 2.5 – 2.7 згідно із нотацією IDEF0

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

прогнозування.

В даній роботі структура функціонування системи моніторингу була

розроблена за допомогою CASE-засобу BPWin. BPWin підтримує три

методології моделювання: функціональне моделювання (IDEF0); опис бізнес-

процесів (IDEF3); діаграми потоків даних (DFD), що дозволяють аналізувати

ваш процес функціонування з декількох ключових точок зору, забезпечуючи

спільний доступ до екрана або окремих додатків (screen sharing). На рис. 2.3 –

2.5 згідно із нотацією IDEF0 зображено схеми функціонування діяльності

системи моніторингу.

В IDEF0 система подається як сукупність взаємодіючих робіт або

функцій. Така чисто функціональна орієнтація є принциповою - функції

системи аналізуються незалежно від об'єктів, якими вони оперують. Це

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

моделлю в IDEF0 розуміють опис системи (текстове та графічне), яке має дати

відповідь на деякі заздалегідь певні питання.

Основу методології IDEF0 складає графічна мова опису функціонування

системи. Модель в нотації IDEF0 є сукупністю ієрархічно впорядкованих і

взаємозалежних діаграм. Кожна діаграма є одиницею опису системи і

розташовується на окремому аркуші.

Модель може містити чотири типи діаграм:

29

• контекстну діаграму (у кожній моделі може бути тільки одна

контекстна діаграма);

• діаграми декомпозиції;

• діаграми дерева вузлів;

• діаграми тільки для експозиції (FEO).

Процес роботи системи моніторингу теплоспоживання будівель СумДУ

проходить в наступні етапи:

Оскільки система є закритою, то першим етапом є авторизація

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

Вхідна інформацію в залежності від способу розміщення даних в базі

поділяється на такі види:

внесення даних в ручну (М1={G, q, A});

дані парсинга температури (М2={tн, v, n});

дані опитування датчиків (М3={T1, T2, T3, P1, P2, P3}).

Далі проходить збір даних (з теплопунктів, даних о погодних умовах та

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

форм внесення даних та редагування даних.

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

верифікація даних.

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

(щодобові, подекадні); аналіз відхилення від ліміту споживання; порівняльний

аналіз енергоспоживання за минулі аналогічні періоди (в т.ч. по підрозділах);

аналіз стану платежів за спожиті енергоресурси та інше.

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

графіки, документація по проведеному моніторингу.

При цьому для забезпечення оператора відповідною інформацією

необхідна певна організація взаємодії об'єкта і засобів моніторингу та

прогнозування, що є можливим в результаті функціонування інформаційно-

аналітичної системи моніторингу. При аналізі та моделюванні треба

30

враховувати, що об'єкт моніторингу та зовнішнє середовище, яке впливає на

прогнозний стан об’єкту моніторингу, змінює свої параметри у часі.

Рисунок 2.5 – Контекстна діаграма

Рисунок 2.6 – Діаграма декомпозиції 1-го рівня

31

Рисунок 2.7 – Діаграма декомпозиції 2-го рівня2.3 Загальна архітектура інформаційної системи моніторингу й аналізу

теплозабезпечення будівель

Інформаційно-аналітична система моніторингу та прогнозування має

виконувати наступні функції:

знімати інформацію про стан об’єкта спостереження;

передавати зібрані дані до серверу системи моніторингу;

виконувати обробку та зберігання інформації;

надавати візуальне представлення інформації у вигляді графіків,

таблиць, звітів.

Після вивчення системи визначено, що основними функціями системи

аналізу теплозабезпечення є: розрахунок прогнозованих показників

теплозабезпечення на наступну добу, формування звіту показників

теплопостачання за добу, що минула, формування протоколу звіту за добу, що

минула і надання регулюючих рекомендацій на наступні 2-3 доби. Модель

системи побудована за допомогою CASE-засобу ERWin. На рис.2.8 зображено

контекстну діаграму процесу моніторингу теплоспоживання будевель

Сумського державного університету (СумДУ).

Рисунок 2.8 – Контекстна діаграма системи моніторингу теплоспоживання будівель

32

Інформаційна системи моніторингу та аналізу теплозабезпечення

будівель (IAC «HeatCaM») реалізована у вигляді веб-ресурсу, який розміщено у

мережі Інтернет для авторизованого доступу [29]. Дана система складається з

декількох взаємодіючих між собою підсистем (рис.2.9).

Рисунок 2.9 – Архітектура системи моніторингу теплоспоживання

Підсистема збирання даних IAC «HeatCaM» призначена для збирання,

перевірки на коректність та розміщення в єдиній базі інформації, необхідної

для оцінки поточного рівня та розрахунку короткострокових лімітів тепло

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

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

Для одержання інформації про кліматичні умови навколишнього

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

оновлення інформації, яка надається у вільному доступі на сервері сайту

прогнозу погодних умов у встановлені інтервали часу та розміщує її у базі

даних [30].

Автоматизований збір даних стану функціонування системи

теплопостачання будівлі реалізовано за допомогою технології бездротової

передачі даних (рис.2.10). Термінали, до яких підключено лічильники теплової

енергії, датчики температури та тиску, передають зібрані дані на web-сервер за

допомогою використання технології GPRS. Після того, як дані було передано

Підсистема відображення даних

Модульоперативного збирання

даних теплозабезпечення

Модуль збирання даних про погодні умови

Підсистема розрахунків та короткострокового

прогнозування Підсистема зберігання

інформації

Підсистема збирання даних

33

на базову станцію мобільного оператора, вони передаються на web-сервер

інформаційно-аналітичної системи. На web-сервері дані перевіряються на

коректність та заносяться до бази даних. Спеціально розроблене програмне

забезпечення веде записи усіх виконаних дій (журнал) у текстовий файл на

жорсткий диск web-серверу. У випадку, якщо об’єктом моніторингу є одна

будівля, в якості терміналу передачі даних може бути використаний комп’ютер,

підключений до мережі Інтернет. На цьому комп’ютері має бути запущено на

виконання спеціально розроблене програмне забезпечення [31]. Програма

перетворює дані, отримані із датчиків та лічильника, у вигляд запиту, та

передає ці дані на web-сервер з періодичністю в одну хвилину. Зібрана

інформація зберігається в базі даних MySQL.

Рисунок 2.10 – Структурна схема бездротової системи збору даних

У випадку, коли для збору даних з лічильників та датчиків

використовуючи персональний комп’ютер, було розроблено спеціалізоване

програмне забезпечення. Для цього було обрано мову програмування

Builder C++ 6. При розробці програми були актуальними наступні вимоги до

програмного забезпечення:

мінімальні вимоги до характеристик комп’ютера;

Інтернет

Хостинг

БД MySQL

Сайт

Термінал 1

Базова станція

GSM

Термінал N

Термінал 2

...

34

програма повинна безперебійно працювати протягом

опалювального сезону;

забезпечення збору даних з лічильників та датчиків;

передачу даних на сервер системи моніторингу;

обробку виключних ситуацій;

запис всіх виконаних дій у журнал, маркуючи всі дії часовим

штампом.

Перелічені вище можливості було реалізовано у власному

спеціалізованому програмному забезпеченні Heat Data Collector, встановленому

на терміналі власної розробки. Основні компоненти термінала показано на

рис 2.11.

Рисунок 2.11 – Основні елементи термінала

Клеми живлення плати терміналу

Роз’єм для програмування

мікроконтроллера

Мікроконтроллер

Кварцевий резонатор

Головна плата терміналу

Індикатори Клеми для підключення лічильника та

датчиків

Плата GSM модема

Антена

Тримач SIM карти

Літієва батареядля годинника

35

Мовою програмування C++ написана керуюча програма для

мікроконтроллера терміналу передачі даних, вона виконує опитування

лічильника та датчиків температури і тиску, всі отримані таким чином дані

форматує у вигляді запиту. Ця програма подає команди для встановлення

конфігурації GSM модема та для передачі даних через мережу мобільного

оператора на web-сервер інформаційно-аналітичної системи моніторингу та

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

на web-сервері інформаційно-аналітичної системи моніторингу, написані на

мові програмування PHP. Ці скрипти виконують прийом, верифікацію та запис

даних до бази даних за допомогою мови запитів SQL.

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

реалізована у вигляді PHP скрипта. Він повинен запускатися за допомогою

служби CRON декілька разів на добу [31].

Взаємодія компонентів підсистеми накопичення метеорологічних даних

представлена на рис. 2.12.

Рисунок 2.12 – Схема взаємодії компонентів інтерактивної підсистеми

збирання даних про погодні умови

Web-сайтwww.gismeteo.ua

Інформаційно-аналітична система моніторингу та прогнозування

теплоспоживання бідівель

36

Також засобами PHP реалізована підсистема створення резервних копій

бази даних та контента сайту. Ці дані архівуються та передаються на резервний

ftp-сервер. Запуск скрипта виконує служба CRON раз на добу.

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

спеціальну таблицю. Якщо помилка є критичною для подальшого

функціонування системи, то система відправляє СМС повідомлення про

помилку адміністратору. Відправка СМС повідомлень реалізована за

допомогою університетського GSM шлюзу.

Дані про прогнозний стан та поточні значення системи опалення

виводяться з бази даних на монітор у табличному та графічному вигляді, а

також формуються звіти для додатків MS Office.

Дана інформаційно-аналітична система моніторингу та прогнозування

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

мережі Інтернет для авторизованого доступу групи осіб, які забезпечують

адміністрування ресурсу та оперативне управління системою опалення [32-35].

Основні функції користувачів системи «HeatCAM» представлено на

рис. 2.13 у вигляді UML-діаграми варіантів використання.

Повні права управління web-ресурсом має адміністратор. Він відповідає

за розподіл прав доступу між користувачами до системи моніторингу, має

право на внесення та редагування усіх даних для моніторингу та коригування

всіх вихідних даних. Також адміністратор є відповідальним за інформаційне

наповнення сторінок web-сайту, адміністрування бази даних, створення її

резервних копій.

До функцій оператора відносимо збір даних зі встановлених датчиків, з

лічильників споживання теплової енергії та інформаційних ресурсів про

погодні умови, а також занесення зібраних даних до єдиної бази даних. В ІАС

«HeatCAM» функцію оператора виконують спеціалізований термінал та

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

введенні усі дані проходять верифікацію і після успішної перевірки

записуються до бази даних.

37

Інженер, відповідальний за енергоаудит та енергозбереження, виконує

щодобовий аналіз фактичного рівня теплоспоживання, порівняльний аналіз

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

заходів для дотримання граничних величин теплоспоживання.

Рисунок 2.13 Діаграма варіантів використання web-сайту системи

«HeatCAM»

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

споживання теплової енергії, заплановані та фактичні обсяги споживання, стан

оплати за спожиту теплову енергію.

Бухгалтер виконує формування документів бухгалтерського обліку на

підставі первинних даних про теплоспоживання.

Робота з web-сайтом починається з авторизації. Потім для користувача в

залежності від його повноважень доступні відповідні елементи верхнього

меню. На рис. 2.14 представлено інтерфейс web-сайту для профілю користувача

– інженера установи. За цим профілем можливості введення даних не

передбачено.

38

Рисунок 2.14 – Представлення даних моніторингу у табличному вигляді.

Погодинні дані

Сайт складається з 6 сторінок, перехід між якими забезпечують пункти

головного меню. Інтерфейс сайту при виборі певних пунктів меню показано на

рис. 2.15-2.16. Погодинні дані з теплопунктів – на даній сторінці

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

окремо. На цій сторінці відображаються фактичні середньодобові показники

опалювальної мережі. Дані про погодні умови – перегляд погодинних та

добових даних погодних умов (фактичних та прогнозних). Моніторинг та

прогноз – дана сторінка показує ліміти за прогнозованими та фактичними

температурами та прогноз на сьогодні. Порівняння за роками – сторінка

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

показників у відповідності до температури зовнішнього середовища для

адекватного порівняння). Введення даних з теплопункту – сторінка дозволяє

вводити дані про стан мережі. Цей режим вводу використовується для

внесення даних зібраних в ручному режимі, даних за минулі роки, даних при

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

успішної перевірки записуються до бази даних. Редагування даних з

теплопункту – ця сторінка дозволяє редагувати дані введені у ручному режимі,

для виправлення можливих помилок вводу.

39

а) б)

а) – представлення інформації у табличному вигляді

б) – представлення інформації у графічному вигляді

Рисунок 2.15 – Табличне та графічне відображення інформації

моніторингу

а) б)

а) – прогнозна інформація споживання теплової енергії на поточну добу

б) – представлення інформації про прогнозне та фактичне теплоспоживання

будівлі за місяць

Рисунок 2.16 – Табличне та графічне відображення інформації

теплоспоживання

Інформаційно-аналітична система протестована у опалювальному сезоні

2012-2013 та функціонує в поточному опалювальному сезоні 2013-2014 р.р. та є

основним інструментом короткострокового прогнозування теплоспоживання

будівель СумДУ.

40

Ефективність впровадження енергозберігаючих заходів на основі

пропонованих системою рішень зображено на рис. 2.17, який надає порівняння

рівня теплоспоживання за аналогогічні періоди (тиждень) кінця листопаду –

початку грудня минулого та поточного опалювальних сезонів. Результати

приведені до єдиних температурних умов зовнішнього середовища, що

підтверджує точність отриманих висновків. На графіку (рис. 2.17) червоною

лінією показане фактичне теплоспоживання енергії будівлею а чорною –

нормативні значення теплоспоживання будівлі.

а) б)

а) – опалювальний сезон 2011-2012

б) – опалювальний сезон 2012-2013

Рисунок 2.17 – Нормативна та фактична витрата теплоносія

Рис. 2.17 ілюструє ефективність впровадження запропонованої системи

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

застосуванню заходів з регулювання на основі інформаційно-аналітичної

системи фактичне значення не перевищує нормативне.

У порівнянні з періодом, коли регулювання здійснювалося без

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

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

спостереження (опалювальний сезон 2011-2012), у поточному опалювальному

сезоні було досягнено економію споживання теплової енергії близько 25-30%

при збереженні необхідних санітарно-гігієнічних норм в опалювальних

приміщеннях (рис. 2.18).

41

Рисунок А5 – Діаграма порівняння подобового теплоспоживання

Рисунок 2.18– Порівняння тепло споживання за різні опалювальні сезони

Таким чином розроблено інформаційно-аналітичну систему, що

відслідковує поточний стан об’єкта спостереження та виконує прогноз

можливого стану об’єкта спостереження на визначений період часу (добу).

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

обгрунтованих рішень щодо регулювання теплоспоживання будівлі на основі

прогнозу та корекції впливу зовнішнього середовища на функціонування

системи теплоспоживання. При прогнозуванні використовуються аналітичні

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

........................2.4 Аналіз способів забезпечення цілісності даних web-системи

теплозабезпечення

Для того, щоб мінімізувати втрати часу при маніпуляції базою даних

використовують системи управління базами даних – сукупність програмних і

лінгвістичних засобів загального або спеціального призначення, що

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

База даних використовується в системі «Нeating», що знаходиться за

Інтернет адресою: http://heating.sumdu.edu.ua/. Це web-система, яка надає

42

0

5

10

15

20

25

30

35

25 26 27 28 29 30 1

2011

2012

Гкал

Доба

інформацію про теплоспоживання будівель Сумського державного

університету. Завдяки функціонуванню даного сайту можна прогнозувати та

аналізувати витрати на теплоспоживання. У системі реалізовані засоби, що

створюють звіти за роками та за сезонами. Засоби, які збирають інформацію

про метеоумови, що прогнозуються (використовуються інтернет-ресурси). На

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

необхідні для обігріву кожного з корпусів.

Система «Нeating» функціонує на основі даних, які збираються з

датчиків, передаються по GSM- протоколу, та заносяться у базу даних, після

чого опрацьовується завдяки СУБД MySQL та реплікуються у мережі Інтернет.

Так як, дані проходять довгий шлях від першоджерела - датчика до вигляду

інформації, що відображується на Інтернет-сторінці, то висока ймовірність

втрати цілісності даних.

Цілісність бази даних характеризується тим, що у кожний момент

часу існування  бази даних відомості, що зберігаються в ній, повинні бути

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

Цілісність може бути пошкоджена, якщо:

Зламаний датчик;

Проблеми GSM зв’язку;

База даних перенавантажена;

База даних недоступна для прийняття нових даних;

Існують проблеми з доступом до необхідних таблиць;

Неполадки в роботі обраної СУБД;

Сервер втратив зв’язок з мережею Інтренет.

З метою убезпечення системи від втрати цілісності необхідно

розглянути проблеми, що можуть виникнути з базою даних і підвищити її

рівень захищеності та стійкості.

Цілісність бази даних досягається внаслідок введення обмеження

цілісності (вказівка діапазону допустимих значень, співвідношення між

43

значеннями даних, обмеження на видалення інформації), тобто описується за

допомогою умов, яким повинні відповідати дані, що зберігаються

Відновлюваність тісно зв’язана з цілісністю. Адже саме створення

резервних копій, контрольних точок забезпечує цілісність бази даних у разі

виникнення збоїв, критичних ситуацій. Так одним із способів захисту втрати

даних є резервне копіювання.

Резервне копіювання даних не увійшло в звичку у користувачів. Згідно з

дослідженням, проведеним компанією Iomega [36], майже половина опитаних

втрачали важливі дані в результаті невірних дій, аварії або зараження вірусом,

оскільки вони не робили резервних копій своїх даних.

Перш за все, резервне копіювання – це процес створення копії даних на

носії, призначеному для відновлення даних в разі їх пошкодження або

видалення. Це засіб, що дозволяє швидко та досить дешево відновити дані

(документів, програм, налаштувань та ін.) в разі втрати працюючої копії

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

покриває ще, не менш важливі, завдання: дублювання даних та передача даних

і робота з загальними документами [37].

Вимоги, що ставляться до систем резервного копіювання:

надійність зберігання інформації - забезпечується застосуванням

відмовостійкого обладнання систем зберігання, дублюванням

інформації та заміною втраченої копії іншою у разі знищення

однієї з копій (у тому числі як частина відмовостійкості );

простота в експлуатації - автоматизація (мінімізація участі

людини: як користувача, так і адміністратора бази даних);

швидке впровадження - проста установка та налаштування

програм, швидке навчання користувачів [38].

Основними та ключовими параметрами резервного копіювання є : RPO -

Recovery Point Objective, що визначає точку відкату – момент часу в минулому,

який буде прийнятий, як точка, до якої «оновлюються» дані та RTO - Recovery

44

Time Objective – параметр, який визначає час, необхідний для відновлення з

резервної копії.

Резервні копії слід робити на інший фізичний диск. Одним із надійних

способів зберігання резервних копій це хмарні сховища. Ці сервіси надають

деякий об'єм вільного місця на спеціальних серверах, доступ до яких надається

через Інтернет.

Розглянемо декілька видів створення резервної копії:

Повне резервне копіювання -  метод який забезпечує створення повної

копії бази даних. Цей метод дозволяє забезпечити максимальну відповідність

оригіналу даних та його копії.

Диференціальне резервне копіювання – безпосереднє копіювання змін,

що були зроблені після створення останньої повної копії. Створення такої копії

потребує більше часу та займає більший об'єм ніж додаткове копіювання, але

дозволяє пришвидшити процес відновлення. Загалом є альтернативою між

створенням повної або додаткової копії.

Додаткове резервне копіювання копіювання змін що відбулись з

повного, диференційоного або додаткового копіювання. Загалом на додаткове

копіювання затрачається менше часу так як копіюється менше файлів. Однак

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

дані останньої повної копії і після цього всі резервні копії від яких залежить

додаткова копія.

Якщо база даних є ядром сайту, то слід створювати резервні копії

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

знайти робочу версію сайту.

Створити резервну копію можна за допомогою програми phpMyAdmin,

де слід вказати ім’я архіву та тип архіву, попередньо обравши базу даних, яку

треба зберігати. Приклад зображено на рис. 2.19.

45

.Рисунок 2. 19– створення резервної копії

Інший спосіб створення резервної копії, який використовується в

системі «HeatCAM» є використання утиліти mysqldump – програма резервного

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

баз даних для резервного копіювання, або переносу на інший сервер SQL (не

обов'язково сервера MySQL). Дамп зазвичай містить запити мови SQL для

створення таблиці , заповнення її, або обидва типи запитів відразу.

При використані mysqldump можна здійснювати гнучкі налаштування

дампа: кілька баз даних або всі бази даних, можлива архівація в gzip, додавання

команд lock, drop і багато іншого. Також можливий зворотний імпорт

резервних копій баз даних. Здійснювати бекап бази даних можна також і за

допомогою PHP.

Утиліта mysqldump є досить простою в використанні та дуже корисною

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

Для того щоб створити резервну копію слід у командній строці ввести:

mysqldump -uroot database > database.sql

46

де –uroot вказівка на те, що використовуються права root, database –

зазначається ім’я бази, з якої буде створена резервна копія, > database.sql –

по факту, це перенаправлення в файл, який вказано з розширенням .sql.

Приклад реалізації наведено на рис. 2.20.

Рисунок 2.20 – Реалізація запиту резервного копіювання

Для того, щоб створити резервну копію декількох баз даних слід ввести таку команду:

mysqldump -uroot -B database1 database2 database3 > databases.sql,

де після – B (аналогічний параметр-databases)зазначаються ім’я баз

даних, з яких створюються миттєвий знімок (рис. 2.21).

Рисунок 2.21 – створення резервної копії декількох баз

Мysqldump також використовується для розгортання резервних копій,

адже якщо данні було втрачено їх потрібно поновити (розгорнути) з резервної

копії, що була створена раніше. Для цього необхідно в командний рядок ввести

47

mysqldump -uroot -p database < database.sql,

де команда цілком аналогічна окрім знаку «<», який вказує, що

відбувається не запис потоку у файл, а зчитування з файлу потока даних, який

буде відтворено у базі даних з назвою database (рис. 2.22).

Рисунок 2.22 – розгортання резервної копії

Якщо нам необхідна лише структура бази даних в резервній копії слід

використовувати:

mysqldump -uroot -h82.82.82.82 -p --no-data database > database.sql,

де параметри аналогічні з попередніми запитами окрім

-h82.82.82.82 – адреса хоста (якщо локальний – то можна не

використовувати параметр), -p – вказівка паролю (якщо паролю нема то можна

опустити параметр), --no-data database - вказівка, що копіюємо лише структуру,

а не взагалі всі дані.

48

49

3. ІНФОРМАЦІЙНА ТЕХНОЛОГІЯ ВІЗУАЛІЗАЦІЇ ДАНИХ В

РОЗПОДІЛЕНИХ СИСТЕМАХ

3.1 Модель графічного відображення даних інформаційної системи обліку в

СТРТЕ

Графи є істотним елементом багатьох математичних моделей в самих

різноманітних галузях науки та практики [39]. Їх застосування забезпечує

наочне представлення взаємозв’язків між об’єктами та процесами в складних

системах. При моделюванні топології трубопровідної мережі доцільно

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

здійснювати перехід від математичної моделі до графічного зображення мережі

і навпаки.

Так як підсистеми транспортування та розподілу теплової енергії

теплоносія взаємопов’язані та виконують роль зв’язуючої ланки між

виробництвом та споживанням тепла, пропонуємо об’єднати їх в єдину систему

транспортування й розподілу тепла (СТРТ), основною функцією якої є

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

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

мінімальними втратами [40].

Аналіз літературних джерел показав, що в якості інструмента при

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

Це пов’язано перш за все з тим, що таким чином зручно описувати

розташування об’єктів на площині та зв’язки між ними. Питанням практичного

використання теорії графів присвячені роботи О.Оре, В.А.Євстігнєєва,

В.Є.Алєксєєва, В.Н.Касянова [41-42].

При моделюванні топології мережі такі дані, як довжина чи діаметр труб

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

кінцях тієї чи іншої труби.

Схема мережі теплопостачання являє собою сукупність двох

упорядкованих множин: множини вузлів I={i: i=1..m}, яка складається з

підмножини споживачів I1, джерела I2 та простих точок розгалуження на схемі

I3; множини труб J={j:j=1..n}, яка відображає задані попарні зв’язки між

вузлами (рис. 3.1).

Рисунок 3.1 – Інформаційна модель топології мережі теплопостачання

Сутність ТРУБА, яка представлена множиною атрибутів {номер труби,

новий номер труби (номер, який буде мати труба після упорядкування матриці

інциденцій), номер початкового вузла, номер кінцевого вузла} являє собою

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

представляє собою упорядковану пару G=(V,E), що складається із множини

вершин V та множини ребер E, причому V={1,2,...,n} і E={1,2,...,m}. Хоча

графічне представлення топології і є наочним, подальше комп’ютерне

моделювання параметрів функціонування мережі потребує дискретного

подання інформації.

Сутніть ВУЗОЛ, представлена множиною атрибутів {номер вузла, новий

номер вузла (номер вузла після упорядкування матриці інциденцій), координата

X, координата Y}, містить інформацію про координати вузлів, необхідну дл

графічного зображення мережі теплопостачання.

На рис. 3.2 зображено приклад результату моделювання топології

мережі теплопостачання – граф мережі теплопостачання мікрорайону.

Рисунок 3.2 – Граф мережі теплопостачання

ТРУБАномер труби

початковий вузол

кінцевий вузол

МЕРЕЖА

ВУЗОЛ

координата Y

координата X

номер вузламає координатиновий номер труби новий номер вузла

50

Наведена модель топології мережі є базовою, і при моделюванні

теплогідравлічних розрахунків [43] може бути розширена шляхом наповнення

новими атрибутами. Наприклад, в сутність ТРУБА можуть бути включені

атрибути «номер труби», «довжина труби» та ін.

Інформаційна модель топології мережі теплопостачання базується на

представленні графа мережі у матричному вигляді. В якості вхідної інформації

для його побудови виступають схеми теплопостачання. Граф мережі

теплопостачання однозначно можна представити за допомогою матриці

інциденцій А, яка будується за наступними правилами:

Матриця інциденцій містить всю інформацію про граф, проте при її

побудові зіштовхуємося з такою проблемою: нумерація труб та вузлів може

бути не суцільною, якщо труба була при побудові видалена.

Аналіз графа, зображеного на рис.3.2 показує, що номери труб та вузлів

при побудові можуть розташовуватися не по порядку. З метою вирішення цієї

проблеми пропонується упорядкування матриці інциденцій, побудованої на

основі списку інцидентності типу ej=(v1i,v2i), тобто ребро e виходить із

вершини v1 і входить у вершину v2. При цьому вихідна матриця інциденцій А

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

При упорядкуванні вихідної матриці інциденцій використовується метод

сортування. В якості критерію розділення множин A1.. An на дві категорії:

пусті та не пусті виступає сума елементів кожної із множин, яка формує масив

VS[i],i=1...n. Аналогічно при розділенні множин А'1.. А'm формується масив

TS[i],i=1...m. Аналіз масивів дозволяє здійснити розділення множин на пусті та

непусті: наприклад, якщо VS[i]=0, множина Aі є пустою, тобто жодна з труб не

приєднана до і-го вузла. При цьому методом сортування знайдена пуста

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

інциденцій рядки та стовпчики, що містять лише нульові елементи. Тобто,

перестановка стовпців у матриці інциденцій змінює номера труб (гілок графу

51

розрахункової схеми), а перестановка рядків – номера вузлів, і подальша

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

Для візуалізації топології мережі теплопостачання на сайті системи

«HeatCAM» в базі даних передбачено таблицю Nodes для збереження

інформації про координати вузлів ( власне для малювання вузлів), номери

вузлів і типи вузла - цей тип буде визначати, чи є цей вузол власне вузлом або

в цьому місці встановлено теплолічильник, засувка, насос, або інший об'єкт.

Власне вузли потрібно виводити точками, а графічне позначення інших об'єктів

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

типу вузла.

Також передбачено таблицю Pipes з полями - номер труби, початковий

вузол, кінцевий вузол, діаметр, довжина, шорсткість, тип труби.

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

використано мови програмування PHP і Java Script, технологію AJAX,

бібліотеку Jquery, мову розмітки гіпертекстових сторінок CSS, а також

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

СУБД MySQL.

Для реалізації даного завдання проведено аналіз двох технологій (SVG,

CANVAS) з метою виявлення найбільш відповідної технології. Порівняльну

характеристику наведено в табл. 3.1.

Таблиця 3.1 – Порівняльна характеристика технологій SVG та Canvas

Canvas SVG

На основі пікселів

(динамічний PNG) На основі фігур

Один елемент HTML Кілька графічних елементів, які

входять до складу DOM

52

Змінюється тільки за допомогою

сценарію

Змінюється за допомогою

сценарію і CSS

Модель події/взаємодія з

користувачем, координати (x,y)

Модель події / взаємодія з

користувачем, абстрактні фігури

(прямокутник, шлях)

Продуктивність поліпшується

при зменшенні поверхні,

збільшенні числа об'єктів (> 10

000) чи наявності обох умов

Продуктивність поліпшується

при зменшенні числа об'єктів

(<10 000), збільшенні поверхні

або наявності обох умов

Мова SVG використовується для опису масштабованої векторної

графіки, яка представляє собою модель абстрактної графіки, вона зберігається в

пам'яті моделі, якою можна керувати за допомогою результатів виконання коду

при повторному рендерінгу.

SVG слід використовувати для:

Створення користувацьких інтерфейсів веб-додатків, незалежних

від дозволу екрану.

Високоінтерактівних анімованих користувальницьких інтерфейсів.

Графіків і діаграм.

Редагування векторних зображень.

Перевагами застосування мови SVG є ітерактивність схем, виконаних із

застосуванням даної технології, а також можливість масштабування

зображення на екрані браузера. В SVG реалізовано модель подій, що спрощує

взаємодію компонентів програм, так як на відміну від Canvas усі елементи

графічної схеми представляють собою окремі об’єкти, тобто існує можливість

надавати кожному об’єкту свої атрибути, створювати обробники подій об’єктів.

На рис. 3.3. показано механізм роботи підсистеми візуалізації даних системи «HeatCAM».

53

Рисунок 3.3 – Схема роботи підсистеми візуалізації даних

Користувач відвідує сторінку http://heating.sumdu.edu.ua/maps/index.php,

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

браузер користувачеві. При наведенні миші на об’єкт графічної схеми,

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

інформація.

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

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

JSON – простий, заснований на використанні тексту спосіб зберігати і

передавати структуровані дані. За допомогою простого синтаксису ви можете

легко зберігати все, що завгодно, починаючи від одного числа до рядків,

масивів та об'єктів, в простому тексті . Також можна пов'язувати між собою

масиви та об'єкти , створюючи складні структури даних.

Нижче наведено фрагмент JSON-запиту.$.ajax({type: "POST",url: "korpus.php",data: "id=1",success: function(data){$("#korpus").html(data); } });

За вибірку координат з бази даних відповідає наступний фрагмент коду:

54

$result2 = mysql_query ("SELECT `id_s`,`nomer` FROM `jos_schetchuk` where `id_s`=".$row['id_k']."",$db);//делаем запрос

$row2 = mysql_fetch_assoc($result2);$result3 = mysql_query ("SELECT `A`,`t1`,`t2` FROM

`rusikokSensus` where `number`=".$row2['nomer']."",$db);//делаем запрос

$row3 = mysql_fetch_assoc($result3);$result4 = mysql_query ("SELECT

`t1`,`t2`,`sumHeat2`,`t3Terminal` FROM `rusikokKompData` where `number`=".$row2['nomer']."",$db);//делаем запрос

$row4 = mysql_fetch_assoc($result4);Результат візуалізації даних моніторингу на графічній схемі мережі

теплопостачання наведено на рис. 3.4.

Рисунок 3.4 – Результатат візуалізації даних моніторингу

3.2. Вибір технології візуалізації даних при інформаційному

моделюванні розподіленої системи альтернативних джерел енергії.

Інформацію, отриману в "реальному" часі, можна імпортувати в

географічні інформаційні системи (ГІС) для проведення різних видів

просторового аналізу. Інформація про розташування обладнання, оцінка

потенціалу поновлюваних джерел енергії може передаватися в систему для

забезпечення кращого її сприйняття .

55

Геоінформаційні аналітичні системи (ГІС) державного регіонального

моніторингу дозволяють оптимальним чином поєднати картографічний

матеріал регіону з базами даних про об'єкти карт, реалізувавши це в зручному

програмному середовищі з різноманітним аналітичним інструментарієм.

ГІС – це комп'ютерна система для введення, зберігання, обслуговування,

управління, пошуку, аналізу, синтезу, і висновок географічних або інформація

про місцезнаходження.

ГІС – сучасна комп'ютерна технологія, що дозволяє поєднати модельне

зображення території з інформацією табличного типу (різноманітні статистичні

дані, списки, технічні показники тощо). Наявність просторових даних відрізняє

ГІС від других систем.

Проблемна орієнтація ГІС визначається розв'язуваними в ній

завданнями (науковими та прикладними), серед них інвентаризація ресурсів (у

тому числі кадастр), аналіз, оцінка, моніторинг, управління і планування,

підтримка прийняття рішень. Інтегровані ГІС, ІГІС (integrated GIS, IGIS)

поєднують функціональні можливості ГІС і систем цифрової обробки

зображень (даних дистанційного зондування) в єдиному

інтегрованомусередовищі.

До даних, які може містити ГІС при моделюванні розподіленої

енергосистеми з ВДЕ можна віднести:

пропускну спроможність існуючої енергосистеми;

кількість сонячної енергії в регіоні;

швидкість вітру;

Окрім того, на карту доречно нанести дані про існуючі установки

альтернативної енергетики. До просторової інформації можна віднести:

цифрові моделі рельєфу;

супутникові зображення;

кліматичні дані;

географічні дані;

екологічні дані.

56

Використання ГІС для роботи з відновлюваними джерелами енергії

почалося в 1990-х роках. Розроблено безліч різних інструментів систем

підтримки прийняття рішень (СППР) на базі ГІС, які можна розділити на

чотири групи:

1) Для інтеграції відновлюваних видів енергії у великих масштабах і на

регіональному рівні.

2) Для оцінки розподіленої генерації енергії.

3) Системи децентралізованого та автономного виробництво

електроенергії.

4) ГІС, як інструмент підтримки прийняття рішень для відновлюваних

джерел енергетичного менеджменту і планування розташування установок в

найбільш сприятливих районах. Класифікацію існуючих ГІС за типом

архітектури наведено в табл. 3.2.

Таблиця 3.2 – Класифікація ГІС за типом архітектури:

Десктоп-клієнти WEB-клієнти Мобільні клієнти

QGIS

GRASS

gvSIG

SAGA

PostGIS

MapBuilder

InterMap

OpenLayers

gvSIG Mobile

Класифікацію існуючих ГІС за принципом розповсюдження наведено в

табл. 3.3.

Таблиця 3.3 – Класифікація ГІС за принципом розповсюдження

З оплатою Безкоштовні Спеціалізовані

програмні продукти

ГІС

ArcINFO QGIS (Quantum GIS) K-MINE

57

ArcGIS

ІнГео

GeoMedia

MapInfo

Modular GIS

Environment (MGE)

GRASS

gvSIG

gvSIG Mobile

SAGA

PostGIS

MapBuilder

InterMap

OpenLayers

Tekla Xpower

ГІС ІНТЕГРО

Також був проведений аналіз за динамікою зросту. Оцінка приросту

вільних декстоп-клієнтів ГІС наведена на рис. 3.5.

Рисунок 3.5 – Оцінка приросту вільних декстоп-клієнтів ГІС

Оцінка виконана за кількістю приросту рядків програмного коду за 2008-

2010 р.р.

Порівняльну характеристику програмних продуктів ГІС наведено в

табл. 3.4.

Таблиця 3.4 – Порівняльна характеристика деяких інструментів ГІС

58

Найпоширенішим в світі серед ГІС серед наведених є програмний

продукт ArcGIS компанії ESRI, якій належать 57% програмного ГІС у

транспортній сфері, 53% у державному секторі, 67% у сфері освіти.

У ході проведення даного аналізу було визначено необхідність побудови

ГІС, як підсистеми інформаційної моделі енергозабезпечення будівель, що

базується на використанні альтернативних джерел енергії.

Було вирішено подальше дослідження та побудову імітаційної моделі

вести з використанням програмного пакету QGIS (Quantum GIS).

59

4. РОЗПОДІЛЕНА ІНФОРМАЦІЙНА СИСТЕМА АВТОМАТИЗАЦІЇ

РОБОТИ СЕКРЕТАРЯ ДЕК

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

нових підходів до організації обробки інформації в різних установах. Особливу

увагу приділяють автоматизації тих процесів, які пов’язані із значними

витратами часу, матеріальних або інших ресурсів.

Однією з таких сфер діяльності є робота секретаря державної

екзаменаційної комісії (ДЕК) в вищих навчальних закладах. Кожного року

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

усіх кваліфікаційних рівнів. Обсяг інформації, який потрібно обробити,

достатньо великий. Використання окремих програмних продуктів для

автоматизації обробки інформації на різних етапах роботи секретаря не

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

комбінацію результатів окремих етапів. Розв’язання такої проблеми полягає в

розробці єдиної інформаційної системи, яка автоматизувала б усі аспекти

діяльності секретаря комісії.

4.1. Концептуальна модель інформаційної системи автоматизації роботи

секретаря ДЕК

Ознайомившись із технічним завданням було вирішено створити клієнт-

серверний додаток, у якому реалізовано робота секретаря ДЕК, що

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

випускаються, та державних іспитів.

Оскільки система є клієнт-серверною, то сервер, тобто база даних,

розміщується на сервері секції ІТП, а клієнтський додаток працюватиме лише з

комп’ютерів, що підключені до мережі секції ІТП [44]. Дане рішення є

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

ІТП і зручним доступ з будь-якого комп’ютера секції.

60

Загальна архітектура інформаційної системи автоматизації роботи

секретаря ДЕК наведена на рис. 4.1.

Рисунок 4.1 – Структура функціонування системи автоматизованого

робочого місця секретаря ДЕК

Вимоги до інформаційної системи наступні:

Додавання, редагування та видалення кортежів усіх таблиць, присутніх у

даній базі даних;

Можливість складання усіх необхідних звітів;

Зручно реалізований інструмент ведення засідань у реальному часі.

Вибір програмного забезпечення

Для зберігання даних та інформації використовуються засоби СУБД

MySQL – зазвичай використовується в якості сервера, до якого звертаються

61

локальні або видалені клієнти, проте в дистрибутив входить бібліотека

внутрішнього сервера, що дозволяє включати MySQL в автономні програми.

Гнучкість СУБД MySQL забезпечується підтримкою великої кількості

типів таблиць: користувачі можуть вибрати як таблиці типу MyISAM, під-

витримують повнотекстовий пошук, так і таблиці InnoDB, що підтримують

транзакції на рівні окремих записів. Більш того, СУБД MySQL постачається із

спеціальним типом таблиць EXAMPLE, що демонструє принципи створення

нових типів таблиць. Завдяки відкритій архітектурі і GPL-ліцензуванню, в

СУБД MySQL постійно з'являються нові типи таблиць. Схему бази даних

інформаційної системи автоматизації секретаря ДЕК наведено на рис. 4.2.

Рисунок 4.2 – Схема бази даних інформаційної системи

62

Для розроблення додатка-клієнта обрано, як інструмент, мову

програмування Visual C# у середовищі програмування Microsoft Visual Studio

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

для платформи Microsoft, так і для інших платформ. Visual Studio також

дозволяє пов'язати всі необхідні проекти, групи і всіх зацікавлених осіб.

Інструменти Visual Studio 2010 допоможуть не тільки в створенні звичних

програм для мобільних телефонів і персональних комп'ютерів, але в розробці

хмарних застосунків. При цьому процес тестування, зневадження і розгортання

програм в «хмарі» аналогічний створенню .NET-застосунків. Іншим важливим

доповненням в Visual Studio 2010 є інструменти для багатонитевої розробки з

використанням як некерованого коду, так і .NET Framework.

У Visual Studio 2010 повністю перероблений інтерфейс з використанням

Windows Presentation Foundation (WPF), упроваджено наступне покоління

інструментів ASP.NET, є підтримка динамічних розширень в мовах

програмування C# і Visual Basic, використовуються нові шаблони проектів,

інструментарій для документування тестових сценаріїв і велика кількість нових

бібліотек, що підтримують Windows 7.

4.2 Технологія реалізації інформаційної системи автоматизації роботи

секретаря ДЕК

На вибір технології для реалізації інформаційної системи впливає багато

факторів, до яких належать: вимоги до продуктивності при обробці даних;

наявне технічне і базове програмне забезпечення, їх конфігурація, оперативна і

дискова пам'ять; тип моделі даних, що підтримується, специфіка предметної

області, топологія інформаційно-логічної моделі; потреби функціональних

програм користувача, що розробляються; наявність у СУБД необхідних

функціональних засобів; рівень кваліфікації користувачів.

Наступні технології було використано для вирішення поставленої задачі

та виконання вимог до даної системи:

● MySQL – дана вільна реляційна система управління базами даних була

63

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

легкість опанування роботи з даною технологією завдяки наявності

великої кількості навчальних матеріалів, легкість використання,

● С# – дана мова програмування увібрала в себе кращі можливості від

схожих мов, так те що було важко на С++ стає легшим на С#, забезпечує

більш високий рівень безпеки та продуктивності, також можлива робота

напряму з пам’яттю на відміну від Java.

● MS Word 2010 – на даний момент найбільш розповсюджений текстовий

редактор, з широкими можливостями, що до роботи з різними видами

документів, для нас найголовнішою перевагою є легка об’єктна модель,

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

документ.

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

задачі та дають можливість розширення системи на майбутнє, що зараз є дуже

актуальним у зв’язку з ростом потреб користувачів у новій функціональності.

64

5. МЕТОД ІНТЕГРАЦІЇ ІНФОРМАЦІЙНИХ СИСТЕМ УПРАВЛІННЯ

МІСЬКОЮ ІНФРАСТРУКТУРОЮ

Взаємодія двох та більше інформаційних систем передбачає не лише

обмін даними між цими системами, а інтегрування даних, тобто використання

при вирішенні певних задач даних з багатьох інформаційних джерел. До того ж,

сучасні інформаційні системи підприємств та установ зберігають не лише

комерційну інформацію, а й приватну інформацію клієнтів, яка захищається

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

інфраструктурою повинно гарантувати безпеку інформації, що надають його

користувачі.

Таким чином, існує потреба у створенні спільного інформаційного

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

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

установ міста.

5.1 Методика розроблення інтегрованого інформаційного середовища

Було проаналізовано функціональні можливості одного з відомих

аналогів для управління міською інфраструктурою – програмного продукту

компанії IBM Intelligent Operations Center for Smarter Cities [45]. Цей

програмний продукт пропонує інтелектуальні рішення для інтегрування даних

та їх візуалізацію, обмін даними в реальному часі та глибокі аналітичні функції,

що можуть допомогти агентствам міста підготуватися до можливих проблем,

координувати і управляти заходами підвищення поточної ефективності

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

керування ресурсами міста, який постачається одним комплексним

дистрибутивом для усіх міських установ та може розвиватися лише однією

компанією. Але цей програмний додаток має ряд недоліків, що ускладнюють

впровадження даного програмного продукту, а саме – відсутність відкритого

доступу, потреба у розгортанні– створення в рамках цього додатку окремих

65

нових підсистем, які відповідають за роботу організацій, що забезпечують

підтримку функціонування інфраструктури міста (тобто не враховує те, що такі

системи вже існують у кожній організації) та не дозволяє взаємодіяти з

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

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

та програмні додатки «розумний дім», інтеграція з якими дозволить пересічним

громадянам відслідковувати власні затрати в житлово-комунальній сфері та

аналізувати на майбутнє власний бюджет. Це дозволить пересічним

громадянам економити власні фінансові ресурси та природні ресурси міста та

країни.

Якщо розглядати місто, як систему, що складається з великої кількості

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

інформаційне середовище повинно справлятися з подібними потоками вхідних

запитів. Також треба враховувати деякі певні дати, або події, наприклад: в кінці

кожного місяцю кожен громадянин оплачує комунальні платежі, в кінці

кожного річного кварталу кожне підприємство, приватний підприємець

звітуються до податкової інспекції і т.п. Тобто в певні періоди часу,

упорядковані або ні, можливі сплески активності пересічних користувачів

системи. Для більшої стабільності інформаційної системи, вона повинна мати

децентралізовану розподілену архітектуру.

Для забезпечення безпеки даних та не допускання несанкціонованого

доступу до інформації пропонуємо систему захисту даних, основними

елементами управління правами в якій є користувачі та групи користувачів. У

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

повні права доступу до об’єкту. Кожен користувач має свою користувацьку

групу, у якої також є права на об’єкт даних, але обмежений, і вони можуть бути

розширені лише власником. Коли одному з сервісів потрібні данні користувача,

для виконання запиту користувача, користувач підтверджує передачу даних

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

Таким чином в будь-якій ситуації власник даних має повний контроль доступу

66

до його персональних даних іншими користувачами інформаційного

середовища.

Так як власник даних в інформаційному інтегруючому середовищі має

повний контроль персональних даних, іноді, коли користувач заводитиме

наступний запит в системі, він може надати або не ті данні, або неповну

інформацію. Для таких випадків середовище повинно вести статистику типів

запитів, типів переданої інформації (але не в якому разі не самої інформації,

згідно з системою безпеки). Використовуючи статистику та аналізуючи

постійні запити від користувачів, середовище зможе більш ефективно та

швидко обробляти запити користувачів.

Статистику також можна використовувати для моніторингу посилання

запитів від користувачів, аналізуючи їх. Програмні модулі інформаційного

середовища, використовуючи статистичні данні, можуть вирішувати наперед

якими сервісами користувач захоче скористатися та запропонує їм

скористатися.

Збір статистичних даних повинен виконуватися на будь-якому етапі

запиту. В статистику повинна входити інформація про запит, про інформацію,

яку надає користувач, запитати додаткової інформації (якщо інформація не

повна), статистика виконання запиту та результат виконання запиту. Подібна

інформація, дозволить в майбутньому вирішувати коли запитувати додаткову

інформацію, які можливі наступні запити користувача. На рис. 5.1 зображено

процес збору статистики, який виконується паралельно до виконання запиту.

Враховуючи, що протягом усього запиту збирається статистична

інформація, запит повинен відповідати чотирьом характеристикам

транзакційності:

атомністі;

консистенції;

ізоляції;

довговічності.

67

Тобто запит буде виконуватися як одна операція, його результати повинні

бути зафіксовані або відхилені повністю, виконання запитів не впливають на

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

Рисунок 5.1 – Процес збору статистики в інтегруючому інформаційному

середовищі

Розглянемо декілька методів інтеграції інформаційних систем.

Найпопулярнішими є інтеграція на рівні програмного додатку [46]. У цьому

випадку використовуються додаткові модулі для переводу даних з одного

формату в той, який підтримує інтегрована система, або на рівні сховищ даних,

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

конкретні поля структур даних з однієї системи взаємодіють з полями структур

даних іншої системи.

У випадку інтегрування на рівні програмного додатку усі інформаційні

системи можуть підтримуватися та удосконалюватися незалежно одна від

одної. Усі системи можуть виступати як сервіси інтегруючого середовища та

обмінюватися даними всередині. Якщо користувач захоче скористатися будь-

яким сервісом, йому просто потрібно зробити заявку, а середовище

68

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

інтегруючого середовища не буде монолітною. Така архітектура дозволить усім

інформаційним системам бути стабільними та надійними. Навіть якщо

центральний об’єднуючий модуль вийде зі строю усі інші системи будуть

повністю працездатні, але можливо втратять функціональність, яку надає

інтегруючий модуль [47].

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

середовищі можна використовувати або базу даних, або файли-дескриптори.

При використанні файлів-дескрипторів в середовищі повинні знаходитися:

файли, які описують правила збереження та доступу до даних користувача,

файли, які зберігають записи про реєстрацію користувачів та установ, та файли,

що описують відношення між установами, сервісами, що надаються

установами, та користувачами, які на них підписані. Дану задачу можуть

виконувати XML файли в групі з XML-schema файлами, які описують їх

структуру [47]. На рис. 5.2 зображена модель середовища з інтеграцією на рівні

програмного додатку.

Рисунок 5.2 – Модель середовища з інтеграцією на рівні програмного

продукту

69

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

окремою системою, яка просто приєднується до інших систем для отримання

даних. При такому підході, зовнішні системи, якщо вони будуть в майбутньому

активно підтримуватися, не зможуть використовувати функціонал інтегруючої

системи, але якщо в майбутньому і відбудеться інтеграція функціональності, то

велика можливість виникнення конфліктних ситуацій на різних рівнях

інтегрування. До того ж інтегрування на рівні програмного додатку надасть

більше функціональних можливостей, як зовнішнім інформаційним системам

так і інтегруючому середовищу [47].

Децентралізація дозволить збільшити надійність системи, та кожному

серверу працювати незалежно один від одного. Розподілення дозволить

створити мережу серверів, які зможуть розподіляти обробку запитів клієнтів

між собою. Розподілена система може мати спільне сховище даних (схема

«багато до одного») або для кожного серверу додатків може існувати своя база

даних, яка синхронізується з базами даних інших серверів через систему

реплікаторів (схема «багато до багатьох»). На рис. 5.3 та 5.4 зображено

приклади розподілених системи серверів зі спільною базою даних та окремою

базою даних для кожного з серверів додатків.

Рис.5.3 – Архітектура розподіленої системи серверів додатків з спільним

сервером системи керування базами даних

70

Рис. 5.4 – Архітектура розподіленої системи серверів додатків з окремим

сервером системи керування базами даних

Перша схема розподіленої системи є більш економною, тому що потребує

менше фізичних серверів, але сильно залежить від працездатності серверу, на

якому знаходиться система керування базою даних. У разі виходу зі строю

сервера системи керування базами даних вся система буде не працездатною.

Але існує варіант подібної схеми розподіленої системи. Створюється повна

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

основний сервер, то сервери додатків починають працювати з копією, поки

основний сервер не відповідає (схема «Багато до декількох»). На рис. 5.5

зображена подібна схема.

Рисунок 5.5– Архітектура розподіленої системи, яка використовує копію

серверу системи керування базами даних

Дана архітектура має певну подібність до схеми «багато до багатьох».

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

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

навіть ті запити, які виконувалися під час падіння основного серверу. В схемі

«Багато до багатьох», яка має такий підхід, усі її елементи є незалежними одна

від одної. Тобто при падінні одного з серверів додатків запити розподіляться

71

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

сервер додатків, який з ним працював, зможе перенести запити на інший сервер

системи керування базами даних.

На кожному сервері додатків виконується простий алгоритм дій:

приймає дані від клієнта;

обробляє запит;

записує оброблені дані;

передає оброблені дані сервісу;

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

Дані операції виконуються на вертикальній площині, але паралельно

кожному клієнтському запиту виконуються ряд дій:

збір статистичних даних;

аналіз статистичних даних;

удосконалення процесу обробки запитів;

аналіз взаємодії з іншими агентами у середовищі;

Схема процесів в агенті інтегруючого середовища зображена на рис. 5.6.

Рисунок 5.6 – Схема процесів в агенті інтегруючого середовища

72

Контроль сервісів, розподілення між сервісами запитів, передача

обробленої інформації сервісом користувачу, аналізу статистичних даних та

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

архітектуру, всі ці функціональні можливості можливо реалізувати через

модель мультиагентної системи.

Запропонована мультиагентна система складається з агентів, які

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

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

існую спеціальний керуючий агент, який виходячи з основних функціональних

можливостей агентів у системі, розподіляє задачу між групою агентів. Тобто в

подібній системі повинен бути агент-контролер, для розподілення задач, та

агенти-виконавці, для рішення задачі, або частини задачі [48].

В інтегруючому інформаційному середовищі агент-контролер, який

розподіляє клієнтські запити між сервісами (агентами-виконавцями) або/та

виконує декомпозицію задач між ними. Згідно з [48], процес розподілу задач в

загальному вигляді зображена на рис. 5.7.

Рисунок 5.7 – Декомпозиція клієнтського запиту

73

Найчастіше агент-контролер розподіляє задачу між агентами-

виконавцями та інтегрує результати виконання підзадач [48].

У випадку інтегруючого інформаційного середовища схема декомпозиції

буде відрізнятися тим, що агент-контролер буде мати декілька екземплярів,

виходячи з розподіленої архітектури додатку [48]. Використовуючи накопичену

статистику, виконання подібних запитів від користувачів агенти-контролери

можуть виконувати різні підходи по розподіленню задачі для агентів-

виконавців. Також агент-контролер, який приймав дані від користувача та

розподіляв задачу, може не виконувати задачу об’єднання результатів

виконання підзадач, а дану задачу виконає інший агент-контролер. На рис. 5.8

та 5.9 зображено можливі варіанти розподілення задачі та інтегрування

результату для користувача [49].

Рисунок 5.8 – Конвеєрне виконання підзадач або одна за одною

74

Рисунок 5.9 – Зміна послідовності виконання підзадач

Мультиагентна система має єдине сховище даних, що потребує створення

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

інформація про користувачів середовища, опис сервісів та опис системи

безпеки даних користувачів [49].

Для ефективного управління правами користувача у середовищі повинні

бути сформовані групи користувачів, для яких будуть описані права доступу до

певного ресурсу в середовищі. У кожного ресурсу повинен бути власник та

первина група, тобто група власника, та групу псевдовласників, які мають ті ж

самі права на ресурс, що і сам власник. Права на ресурс для первинної групи

власника налаштовує сам власник, за замовчуванням лише права на читання.

Група псевдовласників може бути як одиничною групою, так і множиною груп

та окремих користувачів.

Користувач може входити до декількох груп, але доступ до ресурсу,

власником якого він не є, може отримати шляхом членства первинної групи

власника ресурсу або буди псевдовласником. На рис. 5.10 – 5.12 зображені

подібні ситуації.

75

Рисунок 5.10 – Доступ користувачів та груп до ресурсу

Рис. 5.10 описує доступ до ресурсу користувача групи, яка не є первиною

для даного користувача, але він є її членом, та іншого користувача в

інтегруючому середовищі.

Рисунок 5.11 – Доступ до ресурсу через підгрупу первинної групи

На рис. 5.11 зображено ситуацію, коли не власник ресурсу має обмежені

права, тобто такі ж самі як і первинна група власника ресурсу, якщо він в

ходить в групу користувачів, у якої первина група таж сама, що і первина група

власника ресурсу.

На рис. 5.12 зображено доступ до ресурсу групи користувачів

псевдовласників та іншого користувача псевдовласника ресурсу, який не в

ходить до групи користувачів.

76

Рисунок 5.12 – Доступ до ресурсу псевдовласників

Виконання функціонального аналізу дозволило отримати рішення таких

питань:

визначено яким чином здійснювати обробку запитів;

враховуючи необхідність контролю надійної та правильної роботи

середовища, визначені методи організації збору статистичних

даних про обробку запитів користувачів;

вибрана архітектура інтегруючого середовища;

виконано розподіл ролей користувачів, визначені групи

користувачів та сформульовані основні принципи захисту даних від

несанкціонованого доступу.

Збір статистичних даних дозволяє контролювати правильність виконання

запитів та, в майбутньому, розуміти потреби користувачів і наперед планувати

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

до відмов програмного забезпечення найкращим варіантом реалізації

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

кращої інтеграції з зовнішніми (користувацькими) інформаційними системами

та використання їх як сервісів, обрана мультиагентна архітектура середовища.

Така архітектура дозволяє кожній зовнішній інформаційній системі виступати

як агент-виконавець, та розробити для розподілення задач та узгодження

спільної роботи інформаційних системі-агентів аагента-контролера. Для

77

захисту даних в інтегруючому середовищі можна використовувати сутності

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

доступом до даних в середовищі та записами користувачів середовища.

5.2 Архітектура інтегрованої інформаційної системи управління

На фізичному рівні інтегруюче середовище складається з чотирьох

частин:

- приладів для клієнтських додатків,

- уже існуючих інформаційних систем підприємств або

організацій,

- кластера серверів для обробки запитів усіх користувачів,

- сховища даних, з копією усіх даних для підтримки роботи в

нештатному режимі.

Запропонована структура дозволяє середовищу бути максимально

гнучким та досить надійним при роботі з великою кількістю підключених

клієнтів. Структура інтегруючого середовища зображена на рис. 5.13.

Рисунок 5.13 – Фізична модель системи

78

Кластер та сховище даних знаходяться у локальній мережі для захисту від

несанкціонованого доступу. Запити користувачів потрапляють на пограничні

комутатори локальної мережі, потім на розподільник запитів, який передає

запит на один з серверів в кластері. Схема внутрішньої локальної мережі

зображено на рис. 5.14.

Рисунок 5.14 – Локальна мережа інтегруючого середовища

На логічному рівні середовище складається з декількох програмних

модулів, які дозволяють працювати з різними структурами даних та

інтегруватися з зовнішніми інформаційними системами для взаємодії з ними.

На рис. 5.15 зображена архітектура програмного додатку інтегруючого

середовища.

У сховищі даних знаходяться як структуровані дані, так і

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

типом даних в серверній частині передбачений «модуль керування даними».

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

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

опрацювання запитів від користувачів передбачений універсальний модуль

«обробки запитів користувачів». Цей модуль універсальний для будь-якого

типу користувацького додатку: веб, мобільного або настільного. Також окремо

розроблений «модуль взаємодії з інформаційними системами установ». Це

79

модуль з більш розширеним функціоналом, ніж модуль «обробки запитів

користувачів». Даний модуль потрібен для зв’язку з інформаційними

системами установ, які можуть керувати різнорідними структурами даних.

Рисунок 5.15 – Логічна модель інтегруючого середовища

Модуль призначений для зв’язування запитів від користувачів та даних,

які потрапляють в середовище з інших інформаційних систем. Також в системі

є модуль «Інтерфейс роботи з сервісами», який дозволяє використовувати

під’єднанні інформаційні системи як сервіси, та виконувати запити до цих

систем. Різниця між «Інтерфейсом роботи з сервісами» та «Модулем взаємодії з

інформаційними системами установ» в тому, що сервісами можу виступати

будь-які системи, і передача даних відбувається в установленій структурі під

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

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

конфігурування додаткового з’єднання з інформаційною системою установи. В

той час як «Модуль взаємодії з інформаційними системами установ» має

80

довгостроковий характер і контролює повноту переданої інформації,

відбувається контроль якості інформації. Кожен з модулів має розширюючі

модулі, які можуть встановлюватися на стороні сторонньої інформаційної

системи. Також система має клієнтські додатки: мобільний, веб та настільний –

для більш зручного створення запитів до інтегруючого середовища.

Інтегруюче середовище повинно мати внутрішнє сховище даних. При

інтегруванні на рівні програмного додатку інтегруюче середовище може мати

як структуроване так і неструктуроване сховище, або навіть обидва види

сховищ одночасно, і при роботі з зовнішніми інформаційними системами, не

потрібно вдаватися в точне розуміння, яку структуру мають дані, які

передаються через нього. При цьому в інтегруючому середовищі не будуть

зберігатися ніякі проміжні дані. Інтегруюче середовище, використовуючи

власне сховище, записує описи даних, якими маніпулюють зовнішні системи,

та правила перетворення даних між двома форматами. На рис. 5.16 зображена

схема даних сховища даних середовища при інтеграції на рівні даних.

Рисунок 5.16 – Схема даних сховища даних при інтеграції на рівні даних

81

У разі інтегрування на рівні даних інтегруюче середовище повинно мати

сховище, в якому зберігаються дані опису збереження даних в зовнішніх

системах, а також описи як структури однієї зовнішньої системи зв’язуються зі

структурами інших, причому інтегруюче середовище повинно самостійно

слідкувати та відповідати за правильну відповідність даного опису.

Основними таблицями є MSIS_Entities, MSIS_Entity_Types,

MSIS_Parameters. Таблиця MSIS_Entities зберігає в собі усі існуючі в зовнішніх

системах фізичні сутності. Головною характеристикою сутності є її тип, який

зберігається в таблиці MSIS_Entity_Types. Дана таблиця зберігає в собі всі види

сутностей.

Основну інформацію про тип сутності зберігає поле Interface. В цьому

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

працює розробник даного програмного забезпечення (більш детально

програмну частину системи буде описано нижче).

Таблиця MSIS_Parameters містить в собі всі параметри, які мають типи

сутностей. Зв'язок між типами сутностей та параметрами зберігається в таблиці

MSIS_Entity_Type_Parameters, також в цій таблиці знаходиться додаткове поле,

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

Таблиця MSIS_Entity_Type_Parents дозволяє створювати ієрархію типів

сутностей. Дочірній тип сутності наслідує усі параметри батьківського типу.

Тип сутності може мати декілька батьківських типів.

Маючи таке сховище даних, подібне інтегруюче середовище повинно

мати представлення об’єктів безпосередньо в програмній його частині.

Схема взаємодії об’єктів зображена на рис. 5.17.

82

Рису

нок

5.17

– С

хема

об’

єкті

в та

їх з

алеж

ніст

ь од

ного

від

одно

го в

сер

едов

ищі п

ри ін

тегр

ації

на р

івні

дан

их

83

До цієї структури входять JDBCDriver, DBMS, DBMSType, Database,

Node, DriverType, JavaDataType, SQLDataType, DBColumn, DBTable, DBUser,

ColumnMapping, UserMapping, Project, ColumnMappingType, UserMappingType.

Для підтримки системою ієрархії сутностей кожна сутність повинна бути

представлена Java interface-ом, який розширює можливості батьківських

інтерфейсів.

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

об’єктно-орієнтована мова програмування Java, використовуючи технології, які

надаються компанією Red Hat, такий як Infinispan. Даний фреймворк ефективно

працює з NoSQL даними. Для розробки модулів обробки даних використано

стандартизовану технологію Enterprise Java Beans (EJB) и Java Transaction API

(JTA). Сервер інтегруючого середовища буде виконувати взаємодію з

внутрішнім сховищем даних через технологію Enterprise Java Bean для

зберігання та управління внутрішніми даними. З зовнішніми базами даних

сервер буде взаємодіяти через API, які базуються на JDBC драйвері. За

допомогою даного API сервер виконує аналіз структури баз даних: структури

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

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

взаємодії серверів додатків з зовнішніми базами даних зовнішніх

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

запуск, зупинка, перезагрузка серверів додатків здійснюється клієнтською

частиною інтегруючого середовища [47].

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

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

підвищити його ефективність, гнучкість та надасть можливість швидко

розвивати систему.

Таким чином, у даному розділі сформульовані логічна модель

функціонування інтегруючого середовища (програмного додатку) та фізична

(апаратна) модель, що здатна забезпечувати підтримки життєздатності

програмного додатку.

84

ВИСНОВКИ

У ході проведеного дослідження закладені науково-методологічні основи

та розроблене інформаційне та програмне забезпечення з урахуванням

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

Розроблено інформаційно-аналітичну систему «HeatCAM», в результаті

функціонування якої виробляється інформація для прийняття обгрунтованих

рішень щодо керування СТРТЕ на основі прогнозу та корекції впливу

зовнішнього середовища на функціонування СТРТЕ.

Реалізовано алгоритм збирання прогнозної інформації щодо погодних

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

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

Окремим напрямком дослідження з даного питання є вирішення

проблеми візуалізації даних шляхом застосування ГІС-технологій, а також web-

технології SVG.

Також у ході проведеного дослідження закладені науково-методологічні

основи та визначено архітектуру інформаційного середовища як розподіленої

системи з використанням мультиагентного підходу, методи контролю

працездатності даного середовища на основі використання статистичних даних

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

характеристики для створення на їх основі універсального середовища

взаємодії різних інформаційних систем.

Подальші напрямки дослідження пов’язані з удосконаленням модулів

аналізу даних, прийняття рішень щодо керування функціонуванням та

дослідження зворотного впливу на об’єкт спостереження.

85

86

ПЕРЕЛІК ПОСИЛАНЬ

1. Стратегія економічного і соціального розвитку Сумської області на

період до 2015 року "Нова Сумщина – 2015". – Режим доступу:

http://www.state-gov.sumy.ua/docs/nova_sumscina_2015.html. – Назва з

екрану.

2. Левчук А.П. Оптимизация работы системы центрального теплоснабжения

как решение нелинейной сетевой транспортной задачи / А.П. Левчук,

Д.О. Боцула, В.Г. Загурский, Ю.А. Левчук // Проблемы общей

энергетики. – 2008. – № 17. – С. 61 – 65.

3. Теоретические основы системных исследований в энергетике / [отв. ред.

Л.С.Беляев и Ю.Н.Руденко]. – Новосибирск. : Наука, 1986. – 335 с.

4. Парфененко Ю.В. Аналіз функціонування системи теплопостачання як

об'єкта управління / Ю.В. Парфененко, В.Г. Неня, О.І. Пономаренко //

Вісник Національного технічного універсистету «ХПІ». Тематичний

випуск: Нові рішення в сучасних технологіях. – 2010. – № 57. – С.264-

268.

5. Исследование систем теплоснабжения / [Попырин Л.С., Светлов К.С.,

Беляева Г.М. и др.] ; под ред. Л.С. Попырина. – М. : Наука, 1989. – 215с.

6. Монахов Г.В. Моделирование управления режимами тепловых сетей :

[Монографія] / Г.В. Монахов, Ю.А. Войтинская – М. : Энергоатомиздат,

1995. – 224 с.

7. Автоматизированные системы теплоснабжения и отопления /

[С.А.Чистович, В. К. Аверьянов, Ю. Я. Темпель, С. И. Быков]. – Л. :

Стройиздат, 1987. – 248 c.

8. Меренков А.П. Теория гидравлических цепей : [Монографія] / А.П.

Меренков, В.Я. Хасилев – М.: Наука, 1985. – 279 с.

9. Дубовой В.М. Контроль та керування в мережах теплопостачання :

[Монографія] / В.М. Дубовой, В.В.Кабачій, Ю.М. Паночишин –

Вінниця:УНІВЕРСУМ-Вінниця, 2005.– 190 с.

10.Мониторинг и поддержка принятия решений в системе городского

теплоснабжения на базе гетерогенной беспроводной сети / А. Г Финогеев,

В. Е. Богатырев., В. А. Маслов, А. А. Финогеев // Известия

Волгоградского государственного технического университета. Серия

Актуальные проблемы управления, вычислительной техники и

информатики в технических системах. – 2011. – № 3 (76). – С.73-81.

11.Финогеев А. Г. Система оперативного дистанционного мониторинга и

управления тепловыми сетями на основе беспроводных сенсорных сетей /

А. Г. Финогеев, В. Б. Дильман, В. А. Маслов, А. А. Финогеев //

Прикладная информатика. . – 2011. – № 3 (33). – С. 83–93.

12. Автоматизированная система поквартирного учета тепловой энергии /

Н.И. Муслимова, Д.Н. Ушарова, А.В. Егоров [и др.] // Доклады Томского

государственного университета систем управления и радиоэлектроники –

2011. – №. 2 (24). – С. 232 – 237.

13.Wojciech Grega. Information Technologies Supporting Control and

Monitoring of Power System / Grega Wojciech // Przeglad Elektrotechniczny

(Electrical Review). – 2012. –No.5a. – Pp. 193-197.

14.Wolfgang Kastner. Communication Systems for Building Automation and

Control / Kastner Wolfgang, Georg Neugschwandtner, Stefan Soucek, H.

Michael Newman // Proceedings of the IEEE. – 2005. – Vol.93, No.6. – Pp.

1178-1203.

15.Wernstedt Fredrik. Multi-Agent Systems for Distributed Control of District

Heating Systems : Doctoral Dissertation / Fredrik Wernstedt. – Blekinge

Institute of Technology, Sweden, 2005. – 164 p.

16. S. Jebaraj, S. Iniyan (2006). A review of energy models. Renewable and

Sustainable Energy Reviews, 10(4), 281–311.

17. T.V. Ramachandra (2009). RIEP: Regional integrated energy plan. Renew

Sustain Energy Rev, 13(2), 285–317.

18. I. M. Muslih, Y. Abdellatif (2011). Hybrid Micro-Power Energy Station;

87

Design and Optimization by Using HOMER Modeling Software. Proceedings

of the 2011 international conference on Modeling, Simulation & Visualization

methods, 183.

19. H. Dagdougui, R. Minciardi, A. Ouammi, M. Robba, R. Sacile (2010). A

dynamic optimization model for smart micro-grid: integration of a mix of

renewable resources for a green building. Proceedings of International

Congress on Environmental Modelling and Software.

20. C. Tiba, A.L.B. Candeias, N. Fraidenraich, E.M. de Barbosa, P.B. de Carvalho

Neto, J.B. de Melo Filho (2010). A GIS-based decision support tool for

renewable energy management and planning in semi-arid rural environments

of northeast of Brazil. Renewable Energy, 35(12), 2921-2932.

21.Choong-Sung Yi, Jin-Hee Lee, Myung-Pil Shim (2010). Site location analysis

for small hydropower using geo-spatial information system. Renewable

Energy, 35(4), 852-861.

22. S. Lazarou, D.S. Oikonomou, L. Ekonomou (2012). A platform for Planning

and Evaluating Distributed Generation connected to the Hellenic Electric

Distribution Grid. Advances in Circuits, Systems, Automation and Mechanics,

80-86.

23.Жежнич П.І. Часові бази даних: моделі та методи реалізації :

[Монографія] / П.І. Жежнич – Львів: Видавництво Національного

університету «Львівська політехніка», 2007.– 260 с.

24.Парфененко Ю.В. Концептуальна модель інформаційної системи аналізу

теплозабезпечення [Текст] / Ю.В. Парфененко, В.В. Шендрик, С.І.

Красніков // Вісник Національного університету "Львівська політехніка".

Cерія: Інформаційні системи та мережі. – 2012. – № 743. – С. 131-140.

25.А. с. 51229 Україна. Комп’ютерна програма «Heat Data Storage» /

В. В.  Шендрик, В. Г. Неня, Ю.В. Парфененко. – зареєстр. 18.09.2013.

26.Литвин В. І. Моніторинг режимів теплоспоживання об’єктів бюджетної

сфери / В. І. Литвин // Енергетика. Екологія. Людина: збірник наукових

праць науково-технічної конференції Інституту енергозбереження й

88

енергоменеджменту НТУУ «КПІ», 28-29 квітня 2009 р. – Київ: НТУУ

«КПІ», 2009– С. 151-155.

27.Сотник М.І. Про уточнення показників системи моніторингу

теплозабезпечення будівель / М.І. Сотник, Л.В. Гапич, О.О. Скоромний //

Сучасні технології в промисловому виробництві : матеріали науково-

технічної конференції викладачів, співробітників, аспірантів і студентів

факультету технічних систем та енергоефективних технологій. – Суми:

Вид-во СумДУ, 2011. – С. 132-133.

28.Парфененко Ю.В. Розробка інструментальних засобів контролю тепло

забезпечення будівель / Ю. В. Парфененко, Р. П. Окопний, В.Г. Неня //

Вісник НТУ «ХПІ». – 2012. – № – С.22-25.

29.Парфененко Ю.В.Інформаційно-аналітична система моніторингу та

прогнозування теплозабезпечення будівель / Ю.В. Парфененко, В.Г.

Неня, Р.П. Окопний // Вісник Східноукраїнського національного

університету імені Володимира Даля. – 2013. – № 743. – Ч.1. – С. 38-43.

30.Коваленко, К.О. Інтерактивна інформаційна система збирання

метеорологічних даних [Текст] / К.О. Коваленко, В.В. Шендрик, Ю.В.

Парфененко // Сучасні інформаційні системи і технології : матеріали

Першої міжнародної науково-практичної конференції, м. Суми, 15-18

травня 2012 р. / Ред.кол.: А.С. Довбиш, О.А. Борисенко, І.В. Баранова. —

Суми : СумДУ, 2012. — С. 192-193.

31. А. с. 47753 Україна. Комп’ютерна програма «Підсистема

автоматизованого збирання даних «Heat Data Collector»» / Р. П. Окопний,

В. Г. Неня . – № 47753; заявл. 20.11.2012 ; зареєстр. 21.01.2013.

32.Парфененко, Ю.В. Аналіз даних для моніторингу функціонування

системи теплопостачання [Текст] / Ю.В. Парфененко // Інтелектуальні

системи в промисловості і освіті (ІСПО)-2009 : Тези доповідей Другої

міжнародної науково-технічної конференції (Суми, 3-5 грудня 2009

року) / Редкол.: А.С. Довбиш, О.А.Борисенко, С.П. Шаповалов. - Суми :

СумДУ, 2009. - С.96-97.

89

33.Парфененко Ю. В. Інформаційна модель топології мережі

теплопостачання / Ю.В.Парфененко // Вісник Національного технічного

універсистету «ХПІ». Тематичний випуск: Інформатика і моделювання. –

2010. – № 21. – С.136-140.

34. Парфененко Ю. В. Інформаційна технологія моніторингу функціонування

системи теплопостачання підвищеної надійності / Ю.В. Парфененко, В.Г.

Неня // Східно-Європейський журнал передових технологій. – 2010. – №

4/9 (46). – С.22-25.

35. Шендрик В.В. Система збирання, розміщення та аналізу даних [Текст] /

В.В. Шедрик, С.М. Ващенко // Вісник Національного університету

"Львівська політехніка".– 2011. – № 715. – С. 1-11.

36. Офіційний сайт компанії iomega – Режим доступу : http://iomega.com.

Дата доступу : 08.01.2014 – Назва з екрану.

37. Лаборатория востановления данных – Режим доступу :

http://www.mhdd.ru. Дата доступу : 13.12.2013 – Назва з екрану

38. Малыхина, М. П. / Базы данных. Основы, проектирование,

использование. — СПб.: БХВ-Петербург, 2008. — 512 с.

39.Сарычев Д.С. Применение графовых моделей для анализа инженерных

сетей / Д.С. Сарычев, А.В. Скворцов, С.Г. Слюсаренко // Вестник

Томского гос. ун-та. – 2002. – № 275 – С. 70 – 74.

40. Парфененко, Ю.В. Узагальнена математична та інформаційна моделі

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

[Текст] / Ю.В. Парфененко, В.П. Захарченко, В.Г. Неня // Інформатика,

математика, механіка (ІММ-2009) : матеріали та програма IV

міжвузівської науково-технічної конференції викладачів, співробітників,

аспірантів і студентів, 21-24 квітня 2009 р. / Відпов. за вип. С.І. Проценко.

- Суми : СумДУ, 2009. - С. 59-60.

41. Алексеев В.Е. Графы. Модели вычислений. Структуры данных / В.Е.

Алексеев, В.А. Таланов – Нижний Новгород, Изд-во ННГУ. – 2005. –

307 с.

90

42. Касьянов В.Н. Графы в программировании: обработка, визуализация и

применение / В.Н. Касьянов, В.А. Евстигнеев – СПб.: БХВ – Петербург,

2003. – 1104 с.

43. Неня, В.Г. Теплогідравлічний аналіз гідравлічної мережі теплопостачання

[Текст] / В.Г. Неня, С.О. Хованський, Ю.В. Парфененко //

Гідроаеромеханіка в інженерній практиці матеріали XVII Міжнародної

науково-технічної конференції. - Черкаси, 2012. — С. 137.

44. Богачов А.С. Автоматизоване робоче місце секретаря державної

екзаменаційної комісії / А.С. Богачов, А.О. Бондаренко, С.М. Ващенко //

Матеріали третьої міжнародної конференції студентів і молодих

науковців "Сучасні інформаційні технології 2013", 25-26 квітня 2013 р. :

тези доп. – Одеса, 2013.

45.IBM Intelligent Operations Center for Smarter Cities. Сайт компанії IBM

http :// www . ibm . com / .

46.Главные направления развития многоагентных систем [Електронний

ресурс] // Режим доступу: http://www.aiportal.ru/. – Назва з екрану.

47.Dukhno A.V. Conceptual model of ManSerIS system / A.V. Dukhno, V.V.

Shendryk, Y.V. Parfenenko. Kharkiv: PDCS, 2013. – 82 с.

48.Многоагентные системы [Електронний ресурс] // Режим доступу:

http://www.aiportal.ru/. – Назва з екрану.

49.Распределенный искусственный интеллект [Електронний ресурс] //

Режим доступу: http://www.aiportal.ru/. – Назва з екрану.

91