МІНІСТЕРСТВО ТРАНСПОРТУ ТА ЗВ'ЯЗКУ УКРАЇНИ

ДНІПРОПЕТРОВСЬКИЙ НАЦІОНАЛЬНИЙ

УНІВЕРСИТЕТ ЗАЛІЗНИЧНОГО ТРАНСПОРТУ

імені академіка В.Лазаряна

Кафедра: Комп'ютерні інформаційні технології

До захисту Зав. каф. Комп'ютерні інформаційні технології д. т. н. проф. Скалозуб В.В.________ ___._________2005р	Затверджую результат захисту Голова ДЕК_________ ________ ___________ оцінка підпис ___._________2005р

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

РОЗРАХУНОКОВО-ПОЯСНЮВАЛЬНА ЗАПИСКА ДО ДИПЛОМНОГО ПРОЕКТУ

Розробник:	студент 3 ПЗ групи Савоченко Роман Олексійович

Факультет:	Інститут післядипломної освіти

Спеціальність:	8.080403 “Програмне забезпечення автоматизованих систем”

Розробник	Савоченко Р.О.		
Головний керівник	проф. Скалозуб В.В.		
Основний керівник	ас. Разумов С.Ю.		
Нормоконтроль	доц. Шинкаренко В.І.		
Консультанти	доц. Шевченко В.М.		
	ст. викл. Козар З.Ф.		

2005

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

Факультет	“Інститут післядипломної освіти”

Кафедра	“Комп'ютерні інформаційні технології”

Спеціальність	8.080403 “Програмне забезпечення автоматизованих систем”

	ЗАТВЕРДЖУЮ зав. кафедрою ___________________ “___”_________2005р

ЗАВДАННЯ

до дипломного проекту студента

САВОЧЕНКО Романа Олексійовича

Тема проекту “Розробка компонентів середовища програмування системи OpenSCADA для хіміко-технологічних процесів” затверджена наказом по університету № 613ст від 30 вересня 2005 р.

Термін подання студентом закінченого проекту _______________

Вихідні дані проекту

Пояснювальна записка

Технічна документація

Розроблена програма

Плакати

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

Вступ; Проектування компонентів середовища програмування; Реалізація; Тестування та відлагодження; Реалізація математичної моделі частини технологічного процесу; Охорона праці програміста SCADA системи при виконанні робіт на ЕОМ; Висновки; Бібліографічний список; Додатки.

Перелік креслень (з переліком обов'язкових креслень)

Розгалужена структура SCADA; Архітектура системи OpenSCADA; Мета розробки та основа середовища програмування; Архітектура середовища програмування; Компоненти середовища програмування; Математична модель вузла технологічного процесу.

Консультанти (з назвами розділів)

Розділ	Консультант	Підпис, дата завдання видав завдання прийняв
Техніко-економічні розрахунки	ст. викладач Козар З.Ф.		
Охорона праці	доц. Шевченко В.М.		

Дата видачі завдання 30 вересня 2005 р.

Керівник проекту_________________________/ас. С.Ю. Разумов/

Завдання прийняв до виконання_____________/Р.О. Савоченко/

КАЛЕНДАРНИЙ ПЛАН

№ п/п	Назва розділів дипломного проекту	Термін виконання розділів проекту	Примітка
1	Обґрунтування необхідності розробки компонентів.	30.09.2005	
2	Розробка та затвердження технічного завдання.	02.10.2005	
3	Складання UML-моделі	05.10.2005	
4	Розробка компонентів середовища програмування.	20.10.2005	
5	Налагодження компонентів, розробка тестів та тестування компонентів середовища програмування.	30.10.2005	
6	Розробка статичних бібліотек функцій	01.11.2005	
7	Розробка бібліотеки моделей технологічних апаратів.	05.11.2005	
8	Створення моделі вузла технологічного процесу.	10.11.2005	
9	Створення дистрибутиву.	14.11.2005	
10	Створення опису компонентів середовища програмування.	15.11.2005	
11	Створення керівництво програміста SCADA системи.	17.11.2005	
12	Створення керівництва системного програміста.	20.11.2005	

Студент-дипломник______________/Р.О.Савоченко/

Керівник проекту_______________/ас. С.Ю.Разумов/

ЗМІСТ

ВСТУП	6

1 ПРОЕКТУВАННЯ КОМПОНЕНТІВ СЕРЕДОВИЩА ПРОГРАМУВАННЯ	9

1.1 Зовнішнє проектування	9

1.1.1 Постанова задачі	9

1.1.2 Функція як ключовий елемент середовища програмування	10

1.1.3 Вибір мови високого рівня для реалізації обчислювача на цій мові	12

1.1.4 Концептуальна модель середовища	13

1.1.4.1 Концептуальна модель обчислювача на мові високого рівня	15

1.1.4.2 Концептуальна модель обчислювача на мові блоків	17

1.1.4.3 Концептуальна модель модуля бібліотек статичних функцій	18

1.2 Внутрішнє проектування	19

1.2.1 Вибір парадигми проектування	19

1.2.2 Проектування граматики синтаксичного аналізатору. Вибір інструменту для побудови синтаксичного аналізатору, формування граматики та лексичного аналізатора	20

1.2.2.1 Елементи мови	27

1.2.2.2 Операції	28

1.2.2.3 Вбудовані функції	29

1.2.2.4 Оператори	30

1.2.2.5 Приклади програми на Java-подібній мові	30

1.2.3 Розробка внутрішньої віртуальної машини	31

1.2.4 Розробка мови блокового програмування	33

1.2.5 Проектування архітектури	35

1.2.5.1 Архітектура обчислювача на мові високого рівня	39

1.2.5.2 Архітектура обчислювача на мові блоків	43

1.2.5.3 Архітектура модуля бібліотек статичних функції	45

1.2.6 Проектування динаміки	51

1.2.7 Проектування інтерфейсу користувача	55

1.2.7.1 Проектування інтерфейсу модуля «JavaLikeCalc»	57

1.2.7.2 Проектування інтерфейсу модуля «BlockCalc»	58

1.2.8 Вибір мови програмування	60

2 РЕАЛІЗАЦІЯ	61

3 ТЕСТУВАННЯ ТА ВІДЛАГОДЖЕННЯ	62

3.1 Вибір стратегії відлагодження	62

3.2 Покриття тестами	62

3.2.1 TFunctionS:	63

3.2.2 TLibFunc:	65

3.2.3 TValFunc:	67

3.3 Висновки	68

4 РЕАЛІЗАЦІЯ МАТЕМАТИЧНОЇ МОДЕЛІ ЧАСТИНИ ТЕХНОЛОГІЧНОГО ПРОЦЕСУ	69

5 ОХОРОНА ПРАЦІ ПРОГРАМІСТА SCADA СИСТЕМИ ПРИ ВИКОНАННІ РОБІТ НА ЕОМ	74

5.1 Аналіз шкідливих та небезпечних виробничих факторів	74

5.2 Проектні заходи	78

5.3 Вимоги безпеки праці при роботі на ЕОМ	80

ВИСНОВКИ	84

БІБЛІОГРАФІЧНИЙ СПИСОК	86

ДОДАТОК А. Структура системи OpenSCADA	87

ДОДАТОК Б. Команди внутрішньої віртуальної машини	89

ДОДАТОК С. Протоколи тестування	92

ДОДАТОК D. Технічна документація. Технічне завдання. Робочий проект.	94

ВСТУП

Розроблені компоненти середовища програмування системи OpenSCADA є складовою частиною і призначені для SCADA системи OpenSCADA.

OpenSCADA[6] це відкрита SCADA систему, яку побудовано за принципами модульності, багатоплатформності та масштабованості. SCADA[7] (Supervisory Control And Data Acquisition) у перекладі: «Системи диспетчерського керування та збору даних» є терміном який використовується у сфері автоматизації технологічних процесів. Система OpenSCADA призначена для: збору, архівації, візуалізації інформації, видачі керуючих дій, а також для інших споріднених операцій, характерних для повноцінної SCADA системи.

Основними цілями, які переслідує проект OpenSCADA є:

відкритість;

багатоплатформність;

надійність;

гнучкість;

масштабованість;

безпека;

фінансова доступність;

надання зручного інтерфейсу керування.

У якості політики розробки проекту OpenSCADA вибрані «Open Source» принципи розробки ПО. Дана політика дозволяє залучити до розробки, тестування, розвитку, розповсюдженню та використання продукту значну кількість розробників, ентузіастів та інших зацікавлених лиць при мінімальних фінансових витрат. Система OpenSCADA розповсюджується на умовах ліцензії GPL v2.

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

Система OpenSCADA може використовуватися:

на промислових об'єктах, у якості повноцінної SCADA системи;

всередині вбудованих системах, у якості середовища виконання (у тому числі і PLC);

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

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

У якості базової (хостової) операційної системи (ОС) для розробки та використання вибрана ОС Linux, яка є стандартною POSIX сумісною ОС. Крім того, ОС Linux є оптимальним компромісом у питаннях:

надійності;

гнучкості/масштабованості;

доступності;

популярності та розповсюдженості.

Оскільки система OpenSCADA розробляється на стандартній POSIX ОС, за принципами багатоплатформності, то її адаптація на інші ОС не складе проблеми.

Для організації обчислень у середовищі промислових контролерів та SCADA систем застосовуються різноманітні мови програмування. У випадку з контролерами, у якості таких мов частіш за все використовуються мови низького рівня (асемблери), однак останнім часом все частіше використовуються мови високого рівня (C, Pascal та інші), а також формальні мови (блокові схеми, релейні схеми, логічні схеми та інші). У випадку з SCADA системами, обчислення, частіше, забезпечуються мовами програмування високого рівня та формальними мовами.

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

Розроблені компоненти середовища програмування системи OpenSCADA призначені для надання можливості гнучкого створення:

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

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

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

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

допоміжних обчислень.

Розроблене середовище програмування системи OpenSCADA представляє собою комплекс компонентів, які надають обчислювальне середовище. До складу компонентів середовища програмування входять:

підсистема “Функції” системи OpenSCADA;

модуль “JavaLikeCalc” підсистеми “Контролери”;

модуль “BlockCalc” підсистеми “Контролери”;

модуль “StaticFuncLibs” підсистеми “Спеціальні”.

Окрім, безпосередньо, програмних компонентів у межах цього проекту та на основі створених програмних компонентів, реалізовані компоненти моделювання хіміко-технологічних процесів. До цих компонентів входять:

бібліотека технологічних апаратів хіміко-технологічних процесів;

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

ПРОЕКТУВАННЯ КОМПОНЕНТІВ СЕРЕДОВИЩА ПРОГРАМУВАННЯ

Зовнішнє проектування

Постанова задачі

Будь який складний програмний комплекс має містити середовище програмування. Наявність такого середовища значним чином розширює гнучкість системи і як наслідок сферу її використання. Середовище програмування яке використовується у таких програмних комплексах може базуватися на різних мовах програмування. Але частіше за все використовуються мови наділені високим рівнем формалізму, наприклад мови блоків (блочні схеми, логічні схеми, релейні схеми та інше). Та на рівні з ними використовуються мови високого рівня типу С та С++ у своїй спрощеній реінкарнації Java, JavaScript. Не в останню чергу, також використовуються мови логічного виводу Prolog, Lisp.

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

Головною метою створення середовища програмування є надання у систему OpenSCADA гнучкого та потужного механізму програмування.

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

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

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

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

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

допоміжних обчислень.

У межах проекту створені:

обчислювач на мові високого рівня;

обчислювач на мові блоків;

бібліотека статичних функції.

Обчислювач на мові високого рівня призначено для:

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

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

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

Бібліотека статичних функцій призначена для надання у систему OpenSCADA бібліотек статичних функцій. У межах дипломного проекту розроблено модуль бібліотек статичних функцій який надає наступні бібліотеки:

бібліотека функцій сумісності зі SCADA Complex1 фірми НІП «ДІЯ»;

бібліотека стандартних математичних функцій.

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

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

Тобто маємо елементарний модуль рис.1 .

Рис. 1. Функція Де:	X – множина входів;

Y – множина виходів.

A – алгоритм обробки виходів.

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

Рис. 2. Основа середовища програмування системи OpenSCADA

Вибір мови високого рівня для реалізації обчислювача на цій мові

Для реалізації мови програмування високого рівня треба визначитися з мовою яку треба взяти за основу. Виходячи із принципу, що мова має бути достатньо відомою і, по можливості, використовуватися іншими проектами у якості внутрішньої мови обчислень, зупинимося на наступних мовах: С, С++, Java, JavaScript та Phiton. Оскільки мови С, С++, Java та JavaScript практично вийшли з однієї мови C то звузимо коло до мов С++, Java та JavaScript[5]. Мова C++ є дещо складною оскільки містить механізми роботи з адресами та вказівками. Ці можливості є зайвими для мови такого рівня.

Зупиняємося на мовах Java та JavaScript, граматика яких спрощена але містить всі потрібні можливості. Спершу реалізуємо спільну граматику для мов Java та JavaScript з поступовим ухилом на мову JavaScript оскільки вона часто використовується всередині інших проектів (Web-браузери, KDE).

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

Концептуальна модель середовища

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

З архітектурних особливостей видно, що для збереження загальних структур даних треба передбачити проміжний шар для збереження їх у ядрі системи OpenSCADA. Гарним рішенням буде створення підсистеми «Функції» для цих цілей.

Отримаємо концептуальну модель середовища програмування яку представимо діаграмою використань UML-моделі[3] (Use Case Diagram) яку зображено на рис.3.

Рис. 3. Діаграма використання середовища програмування

Виходячи з діаграми, можна відокремити три модулі:

контейнер бібліотек;

обчислювач;

підсистема «Функції»

Розглянемо функції кожного модуля. Першим визначимо функції які середовище має обслуговувати у відношення до користувача:

створення бібліотеки функцій користувача;

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

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

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

реєстрація бібліотек та функції які він надає або які створює користувач;

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

Обчислювач, при цьому має забезпечувати функції:

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

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

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

Підсистема “Функції”, при цьому, має виконувати:

обслуговування запитів на реєстрацію функцій та їх бібліотек;

обслуговування запитів на доступ до функцій.

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

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

Рис. 4. Діаграма використання обчислювача на мові високого рівня Концептуальну модель обчислювача на мові високого рівня можна представити діаграмою використань UML-моделі(Use Case Diagram), яку зображено на рис.4.

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

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

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

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

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

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

При цьому, на модуль обчислювач покладаються наступні обов'язки:

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

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

реєстрація бібліотек та функцій користувача у підсистемі “Функції”.

Концептуальна модель обчислювача на мові блоків

Концептуальну модель обчислювача на мові блоків можна представити діаграмою використань UML-моделі(Use Case Diagram), яку зображено на рис.5.

Рис. 5. Діаграма використання модуля "BlockCalc"

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

створення обчислювальних контролерів;

створення блоків у блочній схемі контролера;

створення параметру контролера;

отримання результатів обчислень.

При цьому на модуль “BlockCalc” покладаються наступні обов'язки:

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

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

Концептуальна модель модуля бібліотек статичних функцій

Концептуальну модель модуля бібліотек статичних функцій можна представити діаграмою використань UML-моделі(Use Case Diagram), яку зображено на рис.6.

Рис. 6. Діаграма використання модуля "StaticFuncLibs"

Виходячи з діаграми використання, модуль непрямо обслуговує операцію запита функції модуля. Для цього, модуль “BlockCalc” реєструє наявні бібліотеки та функції у підсистемі “Функції”.

Внутрішнє проектування

Вибір парадигми проектування

Оскільки, компоненти середовища програмування є складовою частиною іншої системи (OpenSCADA), то вибір парадигми проектування зводиться до парадигми яка використовується у системі OpenSCADA.

Систему OpenSCADA спроектовано за об'єктно-орієнтованою парадигмою, а реалізовано за допомогою об'єктів мови C++. Тому, для проектування компонентів середовища програмування використаємо об'єктно-орієнтовану парадигму. Така парадигма дозволяє абстрагуватися від реалізації, та сконцентруватися на сутностях(об'єктах).

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

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

Лексичний аналізатор будується достатньо просто.

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

З них можна відзначити генератор синтаксичних аналізаторів Yacc (AT&T та Berkeley). На основі цього, відомого, генератору синтаксичних аналізаторів побудовано багато інших, наприклад: Bison[2] та Zubr[1]. Всі вони сумісні і можуть замінювати один одного.

Для розробки мови програмування було вибрано генератор синтаксичних аналізаторів Bison[2], оскільки він вільно постачається практично зі всіма сучасними дистрибутивами ОС Linux, розвивається та взагалі є багатоплатформним.

Для того, щоб Bison міг розібрати програму на потрібній мові, цю мову треба описати контекстно-вільною граматикою. Це означає, що треба визначити одну або більше синтаксичних груп та задати правила їх збірки з складових частин. Наприклад, у мові C одна з груп називається «виразом». Правила доволі часто бувають рекурсивними, але має бути хоча б одне правило, яке виводить з рекурсії.

Найбільш розповсюдженою формальною системою для представлення таких правил у зручному для людини вигляді є форма Бекуса-Наура (БНФ, Backus-Naur Form, BNF), яка була розроблена для опису мови Algol 60. Будь яка граматика, яка виражена у формі Бекуса-Наура є контекстно-вільною граматикою. Bison приймає на вхід особливий вигляд БНФ, адаптованої для машинної обробки.

Bison може працювати не зі всіма контекстно-вільними граматиками, а тільки з граматиками класу LALR(1). Це означає, що має бути можливим визначити, як розібрати будь яку частину входу, заглядаючи вперед не більш, чим на одну лексему. Строго кажучи, це є опис LR(1)-граматики, клас LALR(1) має додаткові обмеження. У звичайній практиці рідко зустрічаються LR(1)-граматики, які не є LALR(1).

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

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

G = <A, N, , P>

де:	A – термінальний алфавіт;

N – нетермінальний алфавіт;

 - аксіома;

P – правила граматики.

Запишемо термінальний та нетермінальний алфавіти:

A = {ERR, IF, ELSE, =, ADDEQ, SUBEQ, MULEQ, DIVEQ, FUNC, B_FUNC, B_FUNC1, B_FUNC2, VAR, CONST, ?, :, OR, AND, |, &, ^, >, <, GE, LE, EQ, NE, +, -, *, /, %, UN_MINUS, !, ~, ',', (, ), '{', '}', ; }

N = {root, solver, solve,assign, expr, prmlst, if, if_expr, end }

Опис термінального алфавіту наведено у таблиці 1. Опис нетермінального алфавіту наведено у таблиці 2. Правила P граматики приведено у таблиці 3. У якості аксіоми граматики визначено:  = root;

Таблиця 1: Термінальний алфавіт Java-подібної мови (A)

Термінал	Опис
1	2
ERR	Помилка. Вставляється лексичним аналізатором у випадку помилки у ньому.
error	Помилка. Перериває роботу синтаксичного аналізатору.
IF	Ключове слово умови - “if”.
ELSE	Ключове слово умови - “else”.
=	Операція – присвоїти.
ADDEQ	Операція - “+=”
SUBEQ	Операція - “-=”
MULEQ	Операція - “*=”
DIVEQ	Операція - “/=”
FUNC	Зовнішня функція.
B_FUNC	Вбудована функція без параметрів.
B_FUNC1	Вбудована функція з одним параметром.
B_FUNC2	Вбудована функція з двома параметрами.
VAR	Змінна. Автоматична або параметр функції.
CONST	Константа.
?	Перший символ операції “?:”
:	Другий символ операції “?:”
OR	Логічна операція - “||”
AND	Логічна операція - “&&”
|	Операція – побітове “АБО”
&	Операція – побітове “І”
^	Операція – виключаюче “АБО”
>	Операція – більше.
<	Операція – менше.
GE	Операція – більше та дорівнює.
LE	Операція – менше та дорівнює.
EQ	Операція – еквівалентно.
NE	Операція – не еквівалентно.
+	Операція – додати.
-	Операція – відняти.
*	Операція – перемножити.
/	Операція – ділення.

Продовження таблиці 1

1	2
%	Операція – залишок від цілочисельного ділення.
UN_MINUS	Операція – унарний мінус.
!	Операція – інверсія.
~	Операція – побітове інвертування.
,	Поділяє параметри у функціях.
(	Виділення пріоритету у виразах та параметрів у функціях.
)	Виділення пріоритету у виразах та параметрів у функціях.
{	Виділення блоку програми.
}	Виділення блоку програми.
;	Завершення виразу.

Таблиця 2: Нетермінальний алфавіт Java-подібної мови (N)

Нетермінал	Опис
root	Корінь. Всі вирази мають згортатися в нього.
solver	Рішення.
solve	Елемент рішення.
assign	Присвоєння.
expr	Вираз.
prmlst	Список параметрів функції.
if	Умова.
if_expr	Вираз умови.
end	Кінець умови або програми.

Таблиця 3: Граматика Java-подібної мови

Правило	Опис
1	2
root: solver end | error	вирішення та закінчення програми; помилка.
solver: /*empty*/ | solver solve	порожнє рішення; рекурсія рішень.
solve: assign ';' | IF '(' expr ')' if solve end | IF '(' expr ')' if solve end ELSE solve end | FUNC '(' prmlst ')' ';' | '{' solver '}'	присвоєння; глобальна коротка умова; глобальна повна умова; процедурний виклик зовнішньої функції; блоки коду у дужках “{“ “}”.
assign: VAR '=' expr | VAR ADDEQ expr | VAR SUBEQ expr | VAR MULEQ expr | VAR DIVEQ expr	просте присвоєння; присвоєння з доданням; присвоєння з відніманням; присвоєння з множенням; присвоєння з діленням.
expr: CONST | VAR | VAR '=' expr | B_FUNC '(' ')' | B_FUNC1 '(' expr ')' | B_FUNC2 '(' expr ',' expr ')' | FUNC '(' prmlst ')' | expr '+' expr | expr '-' expr | expr '*' expr | expr '/' expr | expr '%' expr | expr '|' expr | expr '&' expr | expr '^' expr | '(' expr ')' | expr OR expr | expr AND expr | expr '<' expr | expr '>' expr | expr GE expr | expr LE expr | expr EQ expr | expr NE expr | '!' expr | '~' expr	константа; змінна; присвоєння змінної всередині виразу; вбудована функція без параметрів; вбудована функція з одним параметром; вбудована функція з двома параметрами; зовнішня функція; додання; віднімання; додаток; ділення; залишок від цілочисельного ділення; побітове “АБО”; побітове “І”; побітове виключаюче “АБО”; дужки у виразі; логічне “АБО”; логічне “І”; менше; більше; більше та дорівнює; менше та дорівнює; дорівнює; не дорівнює; логічне заперечення; побітове інвертування;

Продовження таблиці 3

1	2
| '-' expr | expr if_expr expr end ':' expr end	унарний мінус; умова в середині виразу;
prmlst: /*empty*/ | expr | prmlst ',' prmlst	порожній список параметрів; вираз як параметр; перелік параметрів через “,”.
if: /*empty*/	старт умови, для створення коду умови.
if_expr: '?'	старт умови всередині виразу.
end: /*empty*/	кінець програми або умови.

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

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

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

обробляти коментарі;

контролювати кінець потоку програми;

вирізняти цифри чотирьох типів: десятинне, восьмеричне, шістнадцятирічне та реальне;

вирізняти строки;

вирізняти символи за пріоритетним списком:

ключові слова;

константи;

вбудовані функції;

зовнішні функції;

вже зареєстровані символи змінних;

нові символи змінних.

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

Для спрощення мови використаємо неявні визначення локальних змінних, яке полягає у визначені нової змінної під час присвоєння їй першого значення. До того ж, тип локальної змінної має встановлюватися у відповідності з типом значення яке їй вперше було присвоєно. Наприклад, вираз <Qr=Q0*Pi+0.01;> має визначити змінну Qr типом змінної Q0.

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

Для коментування ділянок коду, мовою передбачимо символи «//». Все що йде після даних символів, до кінця строки, має ігноруватися компілятором (лексичним аналізатором).

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

Під оптимізацією за константами розуміється виконання обчислень над двома константами у процесі побудови коду та наступна вставка результату у код. Наприклад вираз <y=pi*10;> має згорнутися до простого присвоювання <y=31.4159;>.

Під приведенням типів констант до необхідного типу розуміється формування у коді константи, яка виключає приведення типу у процесі виконання. Наприклад вираз <y=x*10> у випадку реального типу змінної <x> має перетворитися у <y=x*10.0>.

Забезпечимо підтримку виклику зовнішніх та внутрішніх функцій. Формат виклику зовнішньої функції зробимо наступним: <бібліотека.функція>.

Елементи мови

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

Ключові слова:	if, else, true, false.

Постійні:

десятинні	- цифри 0–9 (12,111, 678);

восьмеричні	- цифри 0–7 ( 012, 011, 076);

шістнадцятирічні	- цифри 0–9, букви a-f або A-F (0x12, 0XAB);

реальні	- 345.23, 2.1e5, 3.4E-5, 3e6;

логічні	- true, false;

строкові	- “hello”.

Типи змінних:

ціле	- -2^31...2^31;

реальне	- 3.4 * 10^308;

логічне	- false, true;

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

Вбудовані константи:	pi = 3.14159265, e = 2.71828182.

Операції

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

Таблиця 4. Операції Java-подібної мови

Символ	Опис
()	Виклик функції.
{}	Програмні блоки.
-	Унарний мінус.
!	Логічне заперечення.
~	Побітове заперечення.
*	Множення.
/	Ділення.
%	Залишок від цілочисельного ділення.
+	Складання.
-	Віднімання.
>	Більше.
>=	Більше та дорівнює
<	Менше.
<=	Менше та дорівнює.
==	Дорівнює.
!=	Не дорівнює.
|	Побітове «АБО»
&	Побітове «І»
^	Побітове «Виключаюче АБО»
&&	Логічне «І»
||	Логічне «АБО»
?:	Умовна операція (i=(i<0)?0:i;)
=	Присвоєння.
+=	Присвоєння з доданням.
-=	Присвоєння з відніманням.
*=	Присвоєння з добутком.
/=	Присвоєння з діленням.

Вбудовані функції

Для забезпечення високої продуктивності роботи на математичних обчисленнях передбачимо підтримку вбудованих математичних функцій (таблиця 5), які будуть викликатися на рівні команд віртуальної машини.

Таблиця 5. Вбудовані функції Java-подібної мови

Функція	Опис
sin(x)	Синус x.
cos(x)	Косинус x.
tan(x)	Тангенс x.
sinh(x)	Синус гіперболічний x.
cosh(x)	Косинус гіперболічний x.
tanh(x)	Тангенс гіперболічний x.
asin(x)	Арксинус x.
acos(x)	Арккосинус x.
atan(x)	Арктангенс x.
rand(x)	Випадкове число від 0 до x.
lg(x)	Десятинний логарифм x.
ln(x)	Натуральний логарифм x.
exp(x)	Експонента x.
pow(x,y)	Взведення <x> у ступінь <y>.
sqrt(x)	Корінь квадратний x.
abs(x)	Абсолютне значення x.
sign(x)	Знак числа x.
ceil(x)	Округлення числа x до більшого цілого.
floor(x)	Округлення числа x до меншого цілого.

Оператори

Мовою модуля забезпечимо підтримку двох типів умовних операторів. Перший це умовний оператор для використання всередині виразу, другий – глобальний.

Умовний оператор для використання всередині виразу має будуватися на операції «?:». У якості прикладу можна записати наступний практичний вираз <st_open=(pos>=100)?true:false;> що читається як «Якщо змінна pos більше або дорівнює 100 то змінній st_open присвоюється значення true інакше false.

Глобальна умова має будуватися на основі ключових слів «if» та «else». У якості прикладу можна привести той же вираз, але записаний іншим способом <if(pos>100) st_open=true; else st_open=false;>. Як видно вираз записано по іншому але читається він також.

Приклади програми на Java-подібній мові

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

//Модель ходу виконавчого механізму шарового крана
if( !(st_close && !com) && !(st_open && com) )
{
tmp_up=(pos>0&&pos<100)?0:(tmp_up>0&&lst_com==com)?tmp_up-1./frq:t_up;
pos+=(tmp_up>0)?0:(100.*(com?1.:-1.))/(t_full*frq);
pos=(pos>100)?100:(pos<0)?0:pos;
st_open=(pos>=100)?true:false;
st_close=(pos<=0)?true:false;
lst_com=com;
}

//Модель клапану
Qr=Q0+Q0*Kpr*(Pi-1)+0.01;
Sr=(S_kl1*l_kl1+S_kl2*l_kl2)/100.;
Ftmp=(Pi>2.*Po)?Pi*pow(Q0*0.75/Ti,0.5):(Po>2.*Pi)?Po*pow(Q0*0.75/To,0.5):pow(abs(Q0*(pow(Pi,2)-pow(Po,2))/Ti),0.5);
Fi-=(Fi-7260.*Sr*sign(Pi-Po)*Ftmp)/(0.01*lo*frq);
Po+=0.27*(Fi-Fo)/(So*lo*Q0*frq);
Po=(Po<0)?0:(Po>100)?100:Po;
To+=(abs(Fi)*(Ti*pow(Po/Pi,0.02)-To)+(Fwind+1)*(Twind-To)/Riz)/(Ct*So*lo*Qr*frq);

Розробка внутрішньої віртуальної машини

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

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

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

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

Існує багато способів побудови віртуальної машини, з них можна відзначити:

стекові машини[2];

код на основі четвірок.

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

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

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

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

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

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

<код> <результат> <операнд1> <операнд2>

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

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

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

значення логічного типу;

значення цілого типу;

значення реального типу;

значення строкового типу;

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

Команди побудованої віртуальної машини приведено у додатку Б. Механізм роботи віртуальної машини буде наступним.

Синтаксичний аналізатор відокремлює команди та генерує код у семантичних процедурах Bison[2]. Під час генерації коду віртуальної машини має формуватися перелік регістрів. Регістри які містять посилання на параметри функції та внутрішні зміни мають ініціалізуватися під час генерації коду і більше не використовуватися на інші цілі. Інші регістри (динамічні дані) мають резервуватися та використовуватися на тимчасові потреби. Такі регістри ініціалізуються конкретними значеннями під час виконання програми у віртуальній машині. Отримана конфігурація регістрів (структура пам'яті) та код програми віртуальної машини має використовуватися у роботі віртуальної машини. При чому, конфігурація регістрів не буде змінюватися, що дозволить використати швидкі методи доступу до регістрів та первинної ініціалізації кадру регістрів.

Для адресації регістрів використаємо один байт, що забезпечить підтримку до 255 параметрів функції (у сумі з внутрішніми змінними).

Розробка мови блокового програмування

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

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

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

міжблокові, підключення входу одного блока до виходу іншого, а також входу одного блока до входу іншого;

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

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

зовнішній атрибут параметра.

Умовно, з'єднання блоків можна зобразити як зв'язки між блоками в цілому (рис. 7) або деталізація зв'язків (рис.8).

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

Оскільки блочний обчислювач буде базованим на функціях підсистеми «Функції», то і типи параметрів блоків будуть такими же, а тобто: ціле, реальне, логічне та строка.

Рис. 7. Загальні зв'язки між блоками блочної схеми

Рис. 8. Деталізовані зв'язки між блоками

Проектування архітектури

Виходячи з модульної архітектури системи OpenSCADA (додаток А), та міркувань наведених у минулих розділах була розроблена архітектура середовища програмування (рис.9).

Рис. 9. Загальна структура середовища програмування

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

підсистема “Функції” системи OpenSCADA;

бібліотеки функцій;

обчислювальні контролери.

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

При такій схемі має існувати компонент, який поєднує ті компоненти що надають алгоритми з тими які їх використовують, особливо це важливо у світлі того, що ці компоненти можуть бути відокремлені від системи, тобто бути модульними. Цим шаром і має виступати підсистема “Функції” системи OpenSCADA.

Виходячи з структури середовища програмування створимо класи об'єктів. Статичну діаграму класів з відокремленням кожного компоненту середовища програмування наведено на рис.10.

Рис. 10. Статична діаграма класів середовища програмування

Для оформлення функціональності класів застосуємо метод CRC-карток. Цей метод дозволяє визначити відповідальність кожного класу. CRC-карти середовища програмування наведено у таблицях 6-12.

Таблиця 6. CRC-карта класу підсистеми "Функції" TFunctionS

TFunctionS
Відповідальність	Зв'язки
Корінний клас підсистеми “Функції” системи OpenSCADA. Містить зареєстровані бібліотеки функцій.	Використовується компонентами які потребують обчислень для доступу до зареєстрованих бібліотек функцій.

Таблиця 7. CRC-карта класу TLibFunc

TLibFunc
Відповідальність	Зв'язки
Клас бібліотеки функцій. Містить функції. Може надавати користувачу механізм (у нащадку) для створення нових функції.	Використовується компонентами які потребують обчислень для доступу до функцій. Є абстрактним, наслідується компонентами які надають власні бібліотеки функції.

Таблиця 8. CRC-карта класу TFunction

TFunction
Відповідальність	Зв'язки
Клас функції. Містить опис параметрів (IO). У нащадку, має містити реалізацію алгоритму функції.	Використовується обчислювачами для зв'язування з кадром значень та обчислень. Є абстрактним, наслідується компонентами які надають власні бібліотеки функції.

Таблиця 9. CRC-карта класу TValFunc

TValFunc
Відповідальність	Зв'язки
Клас значень функції. Містить значення функції у відповідністю із складом параметрів (IO) класу TFunction.	Агрегується з об'єктом функцій TFunctionS для сумісних обчислень. Може наслідуватися класами обчислювачів. Екземпляр класу TValFunc передається класу TFunction під час обчислення для виконання алгоритму у TFunction над значеннями у TValFunc.

Таблиця 10. CRC-карта класу IO

IO
Відповідальність	Зв'язки
Клас параметру функції. Містить опис параметру, його тип та атрибути.	Використовується класом значень TValFunc для визначення значень параметрів.

Таблиця 11. CRC-карта класу UserLib

UserLib
Відповідальність	Зв'язки
Клас бібліотеки користувача.	Наслідує клас бібліотеки TLibFunc і може надавати інструмент створення функцій користувачем.

Таблиця 12. CRC-карта класу UserFunc

UserLib
Відповідальність	Зв'язки
Клас функції користувача. Надає параметри функції та алгоритм обчислення.	Наслідує клас бібліотеки TFunction.

Архітектура обчислювача на мові високого рівня

Виходячи з структури середовища програмування (рис.9) та його діаграми класів (рис.10), створимо класи обчислювача на мові програмування високого рівня (рис.11).

Рис. 11. Статична діаграма класів модуля "JavaLikeCalc"

Для оформлення функціональності класів обчислювача на мові високого рівня застосуємо метод CRC-карток. Цей метод дозволяє визначити відповідальність кожного класу. CRC-карти обчислювача на мові високого рівня наведено у таблицях 13-22.

Таблиця 13. CRC-карта класу TipContr

TipContr
Відповідальність	Зв'язки
Корінний клас модуля, головним призначенням якого є точка входу у модуль.	Наслідує клас інтерфейсу модулів підсистеми «Контролери» TTipController для інтеграції у систему OpenSCADA. Містить: перелік бібліотек, які надаються цим модулем; об'єкти класів (Bfunc) вбудованих функції мови; об'єкти класів (NConst) іменованих констант мови;

Таблиця 14. CRC-карта класу Contr

Contr
Відповідальність	Зв'язки
Клас реалізації контролера. Містить механізм періодичних обчислень над алгоритмом функції цього модуля.	Наслідує клас інтерфейсу контролера TСontroller. Наслідує клас кадру значень функції обчислення TValFunc.

Таблиця 15. CRC-карта класу Prm

Prm
Відповідальність	Зв'язки
Клас реалізації параметра. Містить механізм відображення таблиці даних контролера на структуру параметра системи OpenSCADA.	Наслідує клас інтерфейсу параметра TParamСontr. Містить посилання на таблицю даних контролера.

Таблиця 16. CRC-карта класу Lib

Lib
Відповідальність	Зв'язки
Клас реалізації бібліотеки. Містить механізм створення функцій на мові високого рівня.	Наслідує клас інтерфейсу бібліотеки TLibFunc. Посилання на бібліотеки містяться у класі TipContr.

Таблиця 17. CRC-карта класу Func

Func
Відповідальність	Зв'язки
Клас реалізації функції. Містить механізм створення параметрів функції та програми обчислення. Також містить механізм обчислення у вигляді віртуальної машини та компілятор для побудови програми віртуальної машини.	Наслідує клас інтерфейсу функції TFunction. Містить: робочі регістри; регістри обчислення; посилання на використані зовнішні функції.

Таблиця 18. CRC-карта класу BFunc

BFunc
Відповідальність	Зв'язки
Клас вбудованої функції. Містить опис та кількість параметрів функції.	Міститься у класі TTipContr. Використовується компілятором та віртуальною машиною у TFunc.

Таблиця 19. CRC-карта класу NConst

NConst
Відповідальність	Зв'язки
Клас іменованої константи. Містить опис та значення константи.	Міститься у класі TTipContr. Використовується компілятором та віртуальною машиною у TFunc.

Таблиця 20. CRC-карта класу Reg

Reg
Відповідальність	Зв'язки
Клас регістру віртуальної машини. Містить інформацію про тип регістру, його вміст та іншу інформацію потрібну для побудови програми віртуальної машини.	Міститься у класі функції Func. Використовується компілятором та віртуальною машиною.

Таблиця 21. CRC-карта класу RegW

RegW
Відповідальність	Зв'язки
Клас робочого регістру віртуальної машини. Містить тільки дані про тип та значення регістру, яких достатньо для роботи віртуальної машини.	Міститься у класі функції Func. Використовується віртуальною машиною під час обчислення.

Таблиця 22. CRC-карта класу UFunc

UFunc
Відповідальність	Зв'язки
Клас зовнішньої функції, який використовується програмою віртуальної машини.	Міститься у класі функції Func. Використовується віртуальною машиною під час обчислення.

Для безпосереднього обчислення треба забезпечити створення та зв'язуванням контролера з функцією цього ж модуля. Для зв'язування з функцією, у контролері має створюється кадр значень <TvalFunc> над яким і будуть виконуватися періодичні обчислення.

Для експорту отриманих значень з контролера до системи OpenSCADA та для імпорту значень із системи до контролера треба використовувати параметри контролера. Параметри контролера пов'язуються з параметром обчислювальної функції (полем таблиці даних) та мають виконувати відображення значень.

Архітектура обчислювача на мові блоків

Виходячи з структури середовища програмування (рис.9) та його діаграми класів (рис.10), створимо класи обчислювача на мові блочних схем (рис.12).

Рис. 12. Статична діаграма класів модуля "BlockCalc"

Для оформлення функціональності класів обчислювача на мові блочних схем застосуємо метод CRC-карток. Цей метод дозволяє визначити відповідальність кожного класу. CRC-карти обчислювача на мові блочних схем наведено у таблицях 23-26.

Таблиця 23. CRC-карта класу TipContr

TipContr
Відповідальність	Зв'язки
Корінний клас модуля, головним призначенням якого є точка входу у модуль.	Наслідує клас інтерфейсу модулів підсистеми «Контролери» TTipController для інтеграції у систему OpenSCADA.

Таблиця 24. CRC-карта класу Contr

Contr
Відповідальність	Зв'язки
Клас реалізації контролера. Містить механізм періодичних обчислення над алгоритмом блочної схеми.	Наслідує клас інтерфейсу контролера TСontroller. Містить блоки блочної схеми.

Таблиця 25. CRC-карта класу Prm

Prm
Відповідальність	Зв'язки
Клас реалізації параметра. Містить механізм відображення параметрів блоків блочної схеми на структуру параметра системи OpenSCADA.	Наслідує клас інтерфейсу параметра TParamСontr. Містить посилання на параметр блоку блочної схеми.

Таблиця 26. CRC-карта класу Block

Prm
Відповідальність	Зв'язки
Клас блоку. Містить кадр значень у відповідності з асоційованою функцією. Містить механізм зв'язків.	Наслідує клас інтерфейсу кадру значень TValFunc. На нього посилається клас параметру Prm. Екземпляри класу цього типу можуть містити зв'язки один на одного.

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

Самі блоки, при цьому, не міститимуть структури входів/виходів(IO), а міститимуть тільки значення виходячи із структури параметрів пов'язаної функції. Для поєднання з блоком будемо використовувати функції зареєстровані у підсистемі «Функції» системи OpenSCADA.

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

Архітектура модуля бібліотек статичних функції

Виходячи з структури середовища програмування (рис.9) та його діаграми класів (рис.10), створимо класи модуля бібліотек статичних функцій (рис.13).

Рис. 13. Статична діаграма класів модуля "StaticFuncLibs"

Для оформлення функціональності класів модуля бібліотек статичних функції застосуємо метод CRC-карток. Цей метод дозволяє визначити відповідальність кожного класу. CRC-карти модулю бібліотек статичних функцій наведено у таблицях 27-33. Оскільки, призначення функції бібліотек практично однакове, то у CRC-картах наведемо тільки декілька з них. Повний перелік функцій зведемо у окремі таблиці.

Таблиця 27. CRC-карта класу Libs

Libs
Відповідальність	Зв'язки
Корінний клас модуля, головним призначенням якого є точка входу у модуль. Ініціалізує бібліотеки функцій.	Наслідує клас інтерфейсу модулів підсистеми «Спеціальні» TSpecial для інтеграції у систему OpenSCADA.

Таблиця 28. CRC-карта класу Complex1

Complex1
Відповідальність	Зв'язки
Клас бібліотеки функцій сумісності зі SCADA Complex1. Виконує ініціалізацію функцій.	Наслідує клас інтерфейсу бібліотеки TLibFunc. Реєструється у підсистемі «Функцій» та використовується обчислювачами.

Таблиця 29. CRC-карта класу StdMath

StdMath
Відповідальність	Зв'язки
Клас бібліотеки стандартних математичних функцій. Виконує ініціалізацію функцій.	Наслідує клас інтерфейсу бібліотеки TLibFunc. Реєструється у підсистемі «Функцій» та використовується обчислювачами.

Таблиця 30. CRC-карта класу DigitBlock

StdMath
Відповідальність	Зв'язки
Клас функції цифрового блока. Містить структуру параметрів та алгоритм їх обчислення.	Наслідує клас інтерфейсу функції TFunction. Реєструється у підсистемі «Функцій» та використовується обчислювачами.

Таблиця 31. CRC-карта класу Lag

Lag
Відповідальність	Зв'язки
Клас функції фільтру. Містить структуру параметрів та алгоритм їх обчислення.	Наслідує клас інтерфейсу функції TFunction. Реєструється у підсистемі «Функцій» та використовується обчислювачами.

Таблиця 32. CRC-карта класу acos

Lag
Відповідальність	Зв'язки
Клас математичної функції арккосинусу. Містить структуру параметрів та алгоритм їх обчислення.	Наслідує клас інтерфейсу функції TFunction. Реєструється у підсистемі «Функцій» та використовується обчислювачами.

Таблиця 33. CRC-карта класу if

if
Відповідальність	Зв'язки
Клас математичної функції умови. Містить структуру параметрів та алгоритм їх обчислення.	Наслідує клас інтерфейсу функції TFunction. Реєструється у підсистемі «Функцій» та використовується обчислювачами.

Спеціальний модуль “StaticFuncLibs” має надавати в систему статичні бібліотеки функцій:

бібліотека функцій сумісності зі SCADA Complex1, функції якої приведено у таблиці 34;

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

Таблиця 34. Функції бібліотеки сумісності з SCADA Complex1

Id	Ім'я	Опис функції. Формула обчислення функції.
1	2	3
alarm	Сигнал	Сигнал за шкалою параметра: out = if(val>max || val<min) then true; else false;
cond <	Умова '<'	Умова '<' за формулою: out=if(in1<(in2_1*in2_2*in2_3*in2_4)) then in3_1*in3_2*in3_3*in3_4; else in4_1*in4_2*in4_3*in4_4;
cond >	Умова '>'	Умова '>' за формулою: out=if(in1>(in2_1*in2_2*in2_3*in2_4)) then in3_1*in3_2*in3_3*in3_4; else in4_1*in4_2*in4_3*in4_4;
cond_full	Повна умова	Повна умова за формулою: out = if(in1<(in2_1*in2_2*in2_3*in2_4)) then in3_1*in3_2*in3_3*in3_4; else if( in1>(in4_1*in4_2*in4_3*in4_4) then in5_1*in5_2*in5_3*in5_4; else in6_1*in6_2*in6_3*in6_4;
digitBlock	Дискретний блок	Збірка дискретних сигналів.
div	Дільник	Дільник за формулою: out = (in1_1*in1_2*in1_3*in1_4*in1_5 + in2_1*in2_2*in2_3*in2_4*in2_5 + in3) / (in4_1*in4_2*in4_3*in4_4*in4_5 + in5_1*in5_2*in5_3*in5_4*in5_5 + in6);
exp	Експонента	Експонента за формулою: out=exp (in1_1*in1_2*in1_3*in1_4*in1_5 + (in2_1*in2_2*in2_3*in2_4*in2_5+in3) / (in4_1*in4_2*in4_3*in4_4*in4_5+in
flow	Витрати	Розрахунок витрат за формулою: f = K1*((K3+K4*x)^K2);
increment	Ітератор	Ітератор за формулою: out = if( in1 > in2 ) then in2 + in3*(in1-in2); else in2 - in4*(in2-in1);
lag	Затримка	Затримка(фільтр) за формулою: y = y - Klag*( y - x );
mult	Просте множення	Просте множення за формулою: out=(in1_1*in1_2*in1_3*in1_4*in1_5*in1_6)/ (in2_1*in2_2*in2_3*in2_4);

Продовження таблиці 34

1	2	3
multDiv	Множення+ділення	Множення+ділення за формулою: out=in1_1*in1_2*in1_3*in1_4*in1_5* (in2_1*in2_2*in2_3*in2_4*in2_5+(in3_1*in3_2*in3_3*in3_4*in3_5)/ (in4_1*in4_2*in4_3*in4_4*in4_5));
pid	ПІД регулятор	ПІД регулятор
pow	Ступінь	Взведення у ступінь за формулою: out=(in1_1*in1_2*in1_3*in1_4*in1_5)^ (in2_1*in2_2*in2_3*in2_4*in2_5 + (in3_1*in3_2*in3_3*in3_4*in3_5)/ (in4_1*in4_2*in4_3*in4_4*in4_5));
select	Вибір	Вибір за формулою: out = if( sel = 1 ) then in1_1*in1_2*in1_3*in1_4; if( sel = 2 ) then in2_1*in2_2*in2_3*in2_4; if( sel = 3 ) then in3_1*in3_2*in3_3*in3_4; if( sel = 4 ) then in4_1*in4_2*in4_3*in4_4;
sum	Простий суматор	Простий суматор за формулою: out=in1_1*in1_2+in2_1*in2_2+in3_1*in3_2+in4_1*in4_2 + in5_1*in5_2+in6_1*in6_2+in7_1*in7_2+in8_1*in8_2;
sum_div	Сума з дільником	Сума з дільником за формулою: out = in1_1*in1_2*(in1_3+in1_4/in1_5) + in2_1*in2_2*(in2_3+in2_4/in2_5) + in4_1*in4_2*(in4_3+in4_4/in4_5) + in5_1*in5_2*(in5_3+in5_4/in5_5);
sum_mult	Сума з множенням	Сума з множенням за формулою: out = in1_1*in1_2*(in1_3*in1_4+in1_5) + in2_1*in2_2*(in2_3*in2_4+in2_5) + in4_1*in4_2*(in4_3*in4_4+in4_5) + in5_1*in5_2*(in5_3*in5_4+in5_5);

Таблиця 35. Функції бібліотеки стандартних математичних функцій

Id	Ім'я	Опис
abs	Модуль	Модуль від числа.
acos	Арккосинус	Арккосинус.
asin	Арксинус	Арксинус.
atan	Арктангенс	Арктангенс.
ceil	Округл. до більшого	Округлення до більшого цілого.
cos	Косинус	Косинус.
cosh	Косинус гіперболічний	Косинус гіперболічний.
exp	Експонента	Експонента.
floor	Округл. до меншого	Округлення до меншого цілого.
if	Умова Якщо	Умова Якщо.
lg	Десятинний логарифм	Десятинний логарифм.
ln	Натуральний логарифм	Натуральний логарифм.
pow	Степінь	Взведення у ступінь.
rand	Випадкове число	Генератор випадкових чисел.
sin	Синус	Синус.
sinh	Синус гіперболічний	Синус гіперболічний.
sqrt	Корінь квадратний	Корінь квадратний.
tan	Тангенс	Тангенс.
tanh	Тангенс гіперболічний	Тангенс гіперболічний.

Проектування динаміки

Для проектування динаміки опишемо функції середовища програмування за допомогою діаграм кооперації мови моделювання UML. Діаграми кооперації приведено на рис.14-19.

Рис. 14. Створення кадру значень та обчислення функції

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

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

у конструкторі буде викликано функція асоціації кадру значень з вказаною функцією TValFunc::func();

в процесі асоціації, у екземплярі класу TFunction, буде виконана реєстрація кадру значень за допомогою функції TFunction::valAtt();

після асоціації викликається функція обчислення TValFunc::calc();

далі викликається функція TFunction::calc() яка є віртуальною і як наслідок викликається функція UserFunc::calc() об'єкта реалізації цієї функції.

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

Рис. 15. Модифікація параметрів функції

Рис. 16. Створення бібліотеки функцій Complex1

Рис. 17. Отримання опису параметра функції з обчислювача

Рис. 18. Отримання функції за повним шляхом

Рис. 19. Створення та ввімкнення блоку модуля "BlockCalc"

Проектування інтерфейсу користувача

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

У системі OpenSCADA існує спеціальна мова сценаріїв на якій створюються всі інтерфейси системи OpenSCADA. Мова сценаріїв побудована на мові XML[4], Специфікацію цієї мови можна отримати в документації на систему OpenSCADA[8]. Вигляд інтерфейсу користувача який побудовано на цих сценаріях може мати різноманітний вигляд, який, значним чином, залежить від модуля який будує інтерфейс за цими сценаріями. Але, що важливо, структура інтерфейсу залишається єдиною.

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

Система OpenSCADA містить наступні модулі конфігурації:

WebCfg;

QTCfg.

Розглянемо інтерфейс який надає модуль QTCfg. Робоче вікно з позначками частин які його складають приведено на рис.20. Опис цих полів приведено у таблиці 36.

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

3 1 2 4 5 5.1 5.2 5.3 Рис. 20. Вікно конфігуратора системи OpenSCADA "QTCfg"

Таблиця 36. Пояснення до рис.20.

Поз.	Опис
1	Випадаюче меню конфігуратору.
2	Панель інструментів. Містить кнопки швидкого керування.
3	Навігатор по сторінкам конфігуратора. Містить дерево сторінок конфігурації та дозволяє виконувати безпосередні переходи на них.
4	Строка статусу. Містить шлях до сторінки (під час наведення на сторінку у навігаторі).
5	Панель поточної сторінки. Містить вміст вибраної сторінки конфігуратора.
5.1	Ім'я сторінки. Містить найменування поточної сторінки.
5.2	Поточний користувач. Кнопка поточного користувача, відображає поточного користувача та дозволяє його змінити.
5.3	Вкладки сторінки та їх вміст. Містить вкладки вибраної сторінки та дозволяє виконувати керуючі дії над компонентами сторінки.

Для підсистеми «Функції» розробимо сценарії наступних сторінок:

корінна сторінка підсистеми «Функції»;

сторінка бібліотеки функцій;

сторінка окремо взятої функції.

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

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

ідентифікатор бібліотеки;

ім'я бібліотеки функцій;

опис функції.

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

ідентифікатор функції;

ім'я функції;

опис функції.

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

Проектування інтерфейсу модуля «JavaLikeCalc»

Для модуля «JavaLikeCalc» розробимо сценарії наступних сторінок:

сторінка типу контролера «JavaLikeCalc»;

розширена сторінка бібліотек функції модуля «JavaLikeCalc»;

розширена сторінка функції модуля «JavaLikeCalc»;

розширена сторінка контролера модуля «JavaLikeCalc»;

розширена сторінка параметра контролера модуля «JavaLikeCalc».

Сторінка типу контролера «JavaLikeCalc» міститиме перелік контролерів цього модуля та дозволятиме викликати їх. Сторінка, також міститиме перелік бібліотек функцій цього модуля та дозволятиме викликати їх. Для отримання інформації про модуль сторінка міститиме повну інформацію про модуль.

Розширена сторінка бібліотек функцій модуля «JavaLikeCalc» міститиме, окрім інформації про бібліотеку та перелік функцій, механізм для створення нових бібліотек функцій та форму копіювання функцій.

Розширена сторінка функції модуля «JavaLikeCalc» міститиме, окрім інформації про функцію та форми тестування функції, інструмент для формування конфігурації параметрів функції та написання програми на Java-подібній мові. Буде забезпечено вільне створення, видалення та модифікація параметрів функції.

Розширена сторінка контролера модуля «JavaLikeCalc» міститиме, окрім, інформації про контролер та перелік параметрів, також таблицю даних та механізм безпосереднього обчислення її даних.

Розширена сторінка параметра контролера модуля «JavaLikeCalc» міститиме додаткове конфігураційне поле для вибору переліку полів таблиці даних з метою відображення їх на атрибути параметрів.

Проектування інтерфейсу модуля «BlockCalc»

Для модуля «BlockCalc» розробимо сценарії наступних сторінок:

сторінка типу контролера «BlockCalc»;

розширена сторінка контролера модуля «BlockCalc»;

сторінка блоку контролера модуля «BlockCalc»;

розширена сторінка параметра контролера модуля «BlockCalc».

Сторінка типу контролера «BlockCalc» міститиме перелік контролерів цього модуля та дозволятиме викликати їх. Для отримання інформації про модуль сторінка міститиме повну інформацію про модуль.

Розширена сторінка контролера модуля «BlockCalc» міститиме, окрім, інформації про контролер та перелік параметрів, також схему блоків у вигляді переліку блоків. Забезпечимо можливість редагування переліку блоків та виклику блоку. Для контролю за часом обчислення передбачимо поле яке відображатиме час обчислення блоку.

Передбачимо можливість виключення будь якого блоку з обробки для переконфігурації, з можливістю подальшого включення у обробку. Забезпечимо встановлення зв'язків між блоками без потреби виключення блоків з обробки та зупинки контролера. Значення всіх параметрів(IO) які не охоплені зв'язками можуть бути змінені у процесі обробки.

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

ідентифікатор блоку;

ім'я блоку;

опис блоку;

асоційована функція.

Розширена сторінка параметра контролера модуля «BlockCalc» міститиме додаткове конфігураційне поле для вибору блоку та переліку параметрів блоку з метою відображення їх на атрибути параметрів.

Вибір мови програмування

У зв'язку з тим, що компоненти середовища програмування є частиною системи OpenSCADA і мають добре інтегруватися у цю систему, то і мова програмування має відповідати мові на якій створено систему OpenSCADA. Систему OpenSCADA написано на мові С++ тому і для розробки компонентів буде використано цю мову.

У якості компілятора цієї мови також, у згоді із компілятором системи OpenSCADA, виберемо компілятор GNU GCC. GNU GCC[9] це навіть не компілятор, а колекція компіляторів для різних мов (С, C++, Objective-C, Fortran, Java та Ada).

Основою вибору цього компілятору для розробки системи OpenSCADA[8] стало те, що він є одним із відоміших багато-платформних компіляторів. Крім всього цього він є вільним!

РЕАЛІЗАЦІЯ

Початкову реалізацію середовища програмування у коді було виконано на основі отриманої UML-моделі, шляхом генерації C++ коду у програмі Umbrello.

У результаті була розроблена підсистема «Функції» системи OpenSCADA та окремі компоненти у вигляді модулів до системи OpenSCADA:

модуль “JavaLikeCalc” підсистеми “Контролери”;

модуль “BlockCalc” підсистеми “Контролери”;

модуль “StaticFuncLibs” підсистеми “Спеціальні”.

Загальна структуру всіх цих компонентів та підсистеми функції наведено на рис.21.

Рис. 21. Загальна структура компонентів середовища програмування

ТЕСТУВАННЯ ТА ВІДЛАГОДЖЕННЯ

Тестування є важливою частиною розробки будь якої системи[10]. Тестові модулі, у ідеалі, мають писатися одночасно з новими функціями. Тестові модулі мають викликатись кожного разу коли додається нова функція. Окрім цього на момент випуску нової версії система в цілому має ставитись на добове тестове навантаження.

Тестові модулі у системі OpenSCADA створюються у межах спеціальної системи. Для додання тестових функцій можна, як створювати нові спеціалізовані модулі, так і додавати нові тести у модуль тестування ядра «SystemTests»

Вибір стратегії відлагодження

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

Такий підхід дозволить глибоко проаналізувати помилку і одразу виправити інші ділянки коду с такими ж симптомами.

Покриття тестами

Оскільки, заявлені об'єкти належать ядру системи, то функції тестування створимо у модулі тестів ядра «SystemTests».

У відповідності з наявними ресурсами:

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

розробку виконує одна людина;

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

Виконаємо тестування об'єктів TFunctionS та TLibFunc за стратегією чорного ящика оскільки це є інтерфейсні класи.

Тестування об'єкту TValFunc виконувати тільки для функцій: func() та funcDisConnect() за стратегією білого ящика.

TFunctionS:

Основною функцією цього об'єкту є керування бібліотеками. Для цього передбачені функції: list, avoid, reg, unreg, at. Ці функції відбиваються на інтерфейс керування ресурсами системи, тому виконаємо тестування методом еквівалентної розбивки. Введемо класи еквівалентності:

коректне ім'я функції;

некоректне ім'я функції (порожнє, дублююче, відсутнє).

Зведемо тести у таблицю 37.

Таблиця 37. Тести класу TFunctionS

Тест	Клас еквівалентності	Вхідні дані	Результат
1	2	3	4
1	Коректне ім'я	Ім'я бібліотеки: «testLib»	Створення та реєстрація бібліотеки з коректним ім'ям. Функція – reg() має коректно викликатися і має підтверджуватися наявність бібліотеки функціями avoid() та list().
2	Некоректне ім'я	Ім'я бібліотеки: «testLib»	Створення та реєстрація дублюючої бібліотеки. Функція – reg() має викликати виключення.
3	Коректне ім'я	Ім'я бібліотеки: «testLib»	Перевіряється можливість підключення до коректної бібліотеки та неможливість видалити її під час використання. Функція – at() має коректно викликатись, а функція unreg() - має викликати виключення.
4	Некоректне ім'я	Ім'я бібліотеки: «testLib1»	Перевіряється неможливість підключення до відсутньої бібліотеки. Функція – at() має викликати виключення.

Продовження таблиці 37

1	2	3	4
5	Коректне ім'я	Ім'я бібліотеки: «testLib»	Видалення бібліотеки. Функцій unreg() - має коректно викликатись. Відсутність бібліотеки має підтверджуватися функціями avoid() та list().
6	Некоректне ім'я	Ім'я бібліотеки: «testLib»	Видалення відсутньої бібліотеки. Функція unreg() - має викликати виключення.
7	Некоректне ім'я	Ім'я бібліотеки: «»	Створення та реєстрація бібліотеки з порожнім іменем. Функція reg() має викликати виключення та видаляти порожній об'єкт.

Протокол тестування приведено у додатку С. Результати тестів приведено у таблиці 38.

Таблиця 38. Результати тесту TFunctionS

Тест	Результат
1	TEST:Func| Test1 passed!
2	TEST:Func| Test2 passed!
3	TEST:Func| Test3 passed!
4	TEST:Func| Test4 passed!
5	TEST:Func| Test5 passed!
6	TEST:Func| Test6 passed!
7	TEST:Func| Test7 passed!

TLibFunc:

Об'єкт призначено для керування та зберігання функцій. Для цього передбачені функції: list, avoid, reg, unreg, at. Ці функції відбиваються на інтерфейс керування ресурсами системи, тому виконаємо тестування методом еквівалентної розбивки.

Введемо класи еквівалентності:

коректне ім'я;

некоректне ім'я (порожнє, дублююче, відсутнє).

У зв'язку із схожістю інтерфейсів класів TFunctionS та TLibFunc будемо мати схожі тести але у відношенні до функцій. Зведемо тести у таблицю 39.

Таблиця 39. Тести класу TLibFunc

Тест	Клас еквівалентності	Вхідні дані	Результат
1	2	3	4
8	Коректне ім'я	Ім'я функції: «testFnc»	Створення та реєстрація функції з коректним ім'ям. Функція – reg() має коректно викликатися і має підтверджуватися наявність бібліотеки функціями avoid() та list().
9	Некоректне ім'я	Ім'я функції: «testFnc»	Створення та реєстрація дублюючої функції. Функція – reg() має викликати виключення.
10	Коректне ім'я	Ім'я функції: «testFnc»	Перевіряється можливість підключення до коректної функції та неможливість видалити її під час використання. Функція – at() має коректно викликатись, а функцій unreg() - має викликати виключення.

Продовження таблиці 39

1	2	3	4
11	Некоректне ім'я	Ім'я функції: «testFnc1»	Перевіряється неможливість підключення до відсутньої функції. Функція – at() має викликати виключення.
12	Коректне ім'я	Ім'я функції: «testFnc»	Видалення функції. Функцій unreg() - має коректно викликатись. Відсутність функції має підтверджуватися функціями avoid() та list().
13	Некоректне ім'я	Ім'я функції: «testFnc»	Видалення відсутньої функції. Функція unreg() - має викликати виключення.
14	Некоректне ім'я	Ім'я функції: «»	Створення та реєстрація функції з порожнім ім'ям. Функція reg() має викликати виключення та видаляти порожній об'єкт.

Протокол тестування приведено у додатку С. Результати тестів приведено у таблиці 40.

Таблиця 40. Результати тесту TLibFunc

Тест	Результат
8	TEST:Func| Test8 passed!
9	TEST:Func| Test9 passed!
10	TEST:Func| Test10 passed!
11	TEST:Func| Test11 passed!
12	TEST:Func| Test12 passed!
13	TEST:Func| Test13 passed!
14	TEST:Func| Test14 passed!

TValFunc:

Об'єкт призначено для надання функціям значень, тобто об'єкт містить значення IO у відповідності з їх типом. Функції зв'язування з «функціями» є завершеними, тобто підпадають під можливість тестування стратегією білого ящика. Цими функціями є <void func( TFunction *ifunc )> та породжена <void funcDisConnect( )>. Алгоритм функції приведено на рис.22.

Рис. 22. Алгоритм функції void func(TFunction *ifunc)

Алгоритм функції не містить складної логіки та обрахунків, тому використаємо метод покриття операторів. Для цього складемо таблицю 41. Для кожного тесту запишемо вхідні та вихідні параметри функції.

Таблиця 41. Тест функції func( TFunction *ifunc )

Тест	Вхідні дані	Результат
15	Посилання на функцію яка містить чотири типи IO з іменами: str, int, real, bool.	Підключення до функції за допомогою <func()> та створення IO значень. Мають писатися та читатися значення.
16	Значення функції NULL.	Вивільнення IO значень, від'єднання від функції та вихід за умовою NULL. При читанні значень має виникнути виключення.

Протокол тестування приведено у додатку С. Результати тестів приведено у таблиці 42.

Таблиця 42. Результати тестів функції void func( TFunConnect( )>.ction *ifunc )

Тест	Результат
15	TEST:Func| Test15 passed!
16	TEST:Func| Test16 passed!

Висновки

За допомогою тестів було виправлено:

додана статична функція перевірки порожності строк TSYS::strEmpty();

зменшено час очікування звільнення по замовченню до 2 сек.

РЕАЛІЗАЦІЯ МАТЕМАТИЧНОЇ МОДЕЛІ ЧАСТИНИ ТЕХНОЛОГІЧНОГО ПРОЦЕСУ

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

З метою налагодження, перевірки та демонстрації середовища програмування системи OpenSCADA реалізуємо математичну модель частини технологічного процесу. Для цього використаємо частину технологічного процесу, принципова технологічна схема якого зображена на рис.23.

Рис. 23. Принципова схема вузла технологічного процесу

Виходячи з умови ТЗ[12], треба моделі апаратів технологічної схеми реалізувати за допомогою Java-подібної мови, а зв'язувати їх у схему за допомогою мови блокових схем. Виходячи з цього створимо блочну схему з загальними зв'язками рис.24.

Рис. 24. Блочна схема вузла технологічного процесу

Виходячи з блочної схеми (рис.24) та принципової схеми (рис.23), нам потрібно реалізувати моделі декількох технологічних апаратів:

шум для вхідних витрат;

джерело витрат;

діафрагма;

клапанна збірка з лінійною характеристикою на два паралельних клапани;

виконавчий механізм шарового крану;

вузол з однієї на дві труби;

клапанна збірка з нелінійною характеристикою на два паралельних клапани;

затримка для ходу регулюючого клапана (чотири ланки);

мережа з стабільним тиском;

сепаратор двофазний (газ та рідина);

довга труба.

Будь який апарат будується на двох базових формулах:

(1)

(2)

де:	Fі – вхідні витрати;

Fо – вихідні витрати;

Pі – вхідний тиск;

Pо – вихідний тиск;

K – коефіцієнт врахування особливостей апарату.

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

Таким чином отримаємо два умовних потоки, прямий потік тиску та зворотній витрат:

P1->P2->P3->P4->P5->

F1<-F2<-F3<-F4<-F5<-

Приклад реалізації моделі діафрагми приведено на рис.25. Як видно з рисунку, блок містить обов'язкові параметри та реалізацію формул 1 та 2. Додатково, розраховуються: щільність середовища та перепад тиску на діафрагмі.

Рис. 25. Модель діафрагми.

Інші моделі апаратів побудовано таким же чином.

Отримані моделі апаратів треба поєднати у цільну модель. Для цього створимо блокову схему у якій скористаємося моделями апаратів на Java-подібній мові.

У відповідності з структурою моделей апаратів пов'язувати їх треба наступним чином:

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

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

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

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

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

З необов'язкових можна відзначити зв'язок на частоту обчислення. Цей зв'язок встановлюється на вхід одного блока що дозволяє змінювати частоту обрахунку у одному місці.

Приклад зв'язків блоків PP3 та КШ6 наведені на рис.26 та рис.27 відповідно.

Рис. 26. Зв'язки блоку PP3

Рис. 27. Зв'язки блоку КШ6

ОХОРОНА ПРАЦІ ПРОГРАМІСТА SCADA СИСТЕМИ ПРИ ВИКОНАННІ РОБІТ НА ЕОМ

Аналіз шкідливих та небезпечних виробничих факторів

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

Згідно санітарно-гігієнічним вимогам умови праці програміста SCADA, який працює з ЕОМ, повинні відповідати I або II класу відповідно до Гігієнічної класифікації праці по показниках шкідливості і небезпеки факторів виробничого середовища, складності та напруженості трудового процесу ДСанПіН 3.3.2-007-1998.

Робота на ЕОМ пов'язана з наступними шкідливими факторами:

недолік освітлення природним світлом;

відблиски на екрані монітора;

іонізуюче випромінювання;

електромагнітне поле.

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

Відблиски на екрані монітора, що виникають при неправильному висвітленні, приводить до погіршення зору, а у випадку тривалого впливу даного небезпечного фактора, може призвести до повної втрати зору. З метою зниження рівня впливу на програміста SCADA даного шкідливого фактора, варто дотримувати вимоги ДНАОП 0.00-1.31-99.

Основним джерелом іонізуючого випромінювання на робочому місці методиста є монітор – випромінювання α і β, що випускається люмінофором, згодом може призвести до променевої хвороби. Для зниження проникаючого випромінювання люмінофора рекомендується застосування моніторів із захисним покриттям екрана (напилювання свинцю), або (для виключення даного виду випромінювання) застосування рідкокристалічних панелей.

Рівні електромагнітного випромінювання і магнітних полів на робочому місці повинні відповідати вимогам ДСТ 12.1.006-84.

Небезпечні фактори – це виробничі фактори, вплив яких на працюючого у визначених умовах людини, приведе до травми різкого погіршення здоров'я. До різкого погіршення здоров'я можна віднести отруєння, опромінення, удар електрострумом, тепловий удар та інше ДСТУ 2293-99.

До небезпечних факторів відносяться:

електронебезпека.

пожежонебезпека.

При роботі з ЕОМ найчастіше трапляються нещасні випадки, пов'язані з враженням електричним струмом, викликаним дотиком до оголених місць струмоведучих частин устаткування, або частин, що знаходяться під напругою.

Вплив струму на людину залежить від його величини: струм до 0,6мА не відчувається людиною. Струм завбільшки 6мА призводить до скорочення м'язів тієї частини, тіла, що піддалася його впливу. Цей струм зветься «не відпускаючий». Струм, що перевищує 6мА, здатний викликати утрату свідомості і зупинку подиху, а при досягненні струму порога 100мА настає смерть. При впливі на тіло людини струму в 3-4 А виникає обвуглювання ділянок тіла.

Для захисту людини від ураження електричним струмом відеотермінали, ЕОМ, периферійні пристрої ЕОМ та оснащення для обслуговування, ремонту і налагодження ЕОМ повинні відповідати I класу захисту згідно ДСТУ 12.2.007.0 «ССБТ. Вироби електротехнічні. Загальні вимоги безпеки» і ДСТУ 25861-83 «Машини обчислювальні і системи обробки даних. Вимоги електричної і механічної безпеки і методи іспитів», чи повинні бути заземлені відповідно до Головних нормативних актів охорони праці ДНАОП 0.00-1.21-98 «Правила безпечної експлуатації електроустановок споживачів», ДНАОП 0.00.1.31-99.

Лінія електромережі для живлення ЕОМ, периферійних пристроїв ЕОМ та устаткування для обслуговування, ремонту і налагодження ЕОМ виконується як окрема група трьох провідної мережі, шляхом прокладки фазового, нульового робочого і нульового захисного провідників.

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

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

У приміщенні, де одночасно експлуатується чи обслуговується більш п'яти персональних ЕОМ, на видному доступному місці встановлюється аварійний вимикач, за допомогою якого можливо зробити знеструмлення приміщення (за винятком освітлення).

При роботі неприпустимо:

експлуатація кабелів та дротів з ушкодженою або втратившою захисні властивості за час експлуатації ізоляцією;

застосування саморобних подовжувачів, що не відповідають вимогам ПЭУ до переносних електропроводок;

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

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

Пожежі становлять особливу небезпеку для життя людини, і можуть призвести до великих матеріальних втрат. Джерелами загоряння можуть виявитися електронні схеми ЕОМ, елементи яких перегрілися, а іскри здатні викликати загоряння пальних матеріалів.

Для всіх споруджень та приміщень, у яких експлуатуються ВДТ і ЕОМ, повинна бути визначена категорія по вибухонебезпечній і пожежній безпеці відповідно до ОНТП05 «Визначення категорій приміщень і будинків по вибухонебезпечній і пожежній безпеці», і клас зони згідно ПЕУ. Відповідні позначення повинні бути нанесені на вхідні двері приміщення.

Будинки та ті їхні частини, у яких розміщуються ЕОМ, повинні мати не нижче II ступеня вогнестійкості. Приміщення для обслуговування, ремонту і налагодження ЕОМ повинні відноситися:

за пожежонебезпекою, до категорії В (пожежонебезпечні приміщення, де розташовуються тверді паливні речовини (ТПР), відповідно до ОНТП05;

за класом приміщення, до категорії П ІІ по ПЭУ.

Неприпустимим є розташування приміщень категорії А и Б (ОНТП05), а також виробництв із мокрими технологічними процесами поруч із приміщеннями, де розташовуються ЕОМ, виконується їхнє обслуговування, налагодження і ремонт, а також над такими приміщеннями під ними.

Приміщення з ЕОМ повинні бути оснащені системою автоматичної пожежної сигналізації відповідно до вимог переліку однотипних за значенням об'єктів, що підлягають устаткуванню автоматичними установками пожежегасіння і пожежної сигналізації, затвердженого наказом МВС України 28.11.97 під № 567/2371, та СНиП 2.04,09-84 «Пожежна автоматика будинків і споруджень» з димовими пожежними оповіщувачами та переносними вуглекислотними вогнегасниками з розрахунку 2 шт, на кожні 20 м2 площі приміщення з обліком гранично припустимих концентрацій вогнегасильної рідини відповідно до вимог правил пожежної безпеки в Україні.

Стіни приміщень з ЕОМ виготовляються з непальних матеріалів. Підходи до засобів пожежегасіння повинні бути вільними.

Проектні заходи

Для якісної і зручної роботи програміста SCADA з ЕОМ, необхідне проведення проектних заходів: правильна облаштованості, належне дотримання ергономічних характеристик основних елементів робочого місця, санітарно-гігієнічних вимог і т.п.

Облаштованість робочого місця програміста SCADA при роботі з ВДТ та ЕОМ повинне забезпечувати відповідність всіх елементів робочого місця і їхнього розташування ергономічним вимогам ДСТ 12.2.032 «ССБТ. Робоче місце при виконанні робіт сидячи. Загальні ергономічні вимоги»: ДНАОП 0.00-8.31-99.

Площа, виділена для одного робочого місця з ВДТ чи ЕОМ, повинна складати не менш 6 м2 , а обсяг – не менш 20 м3.

Робочі місця з ВДТ щодо світлових прорізів повинні розташовуватися так, щоб природне світло падало з боку, переважно ліворуч.

При розташуванні робочих місць із ВДТ необхідно дотримувати наступних вимог:

робочі місця з ВДТ розташовуються на відстані не менш 1 м від стін зі світловими прорізами;

відстань між бічними поверхнями ВДТ повинна бути не менш 1,2 м;

відстань між тильною поверхнею ВДТ і екраном іншого ВДТ повинна бути не менш 2,5 м;

прохід між рядами робочих місць повинен бути не менш 1 м.

Конструкція робочого місця програміста SCADA при роботі з ВДТ (при роботі сидячи) повинна забезпечувати підтримку оптимальної робочої пози з наступними ергономічними характеристиками: стопи ніг – на підлозі, на підставці для ніг; стегно - у горизонтальній площині; передпліччя - вертикально; лікті під кутом 70º-90º до вертикальної площини; зап'ястя - зігнуті під кутом не більш 20º щодо горизонтальної площини; нахил голови 15º-20º відносно вертикальної площини.

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

Розміри столу, що рекомендуються: висота -725 мм, ширина – приблизно 600-1400 мм, глибина - 800-1000 мм.

Робочий стіл для ВДТ повинний мати простір для ніг висотою не менш 600 мм, шириною не менш 500 мм, глибиною на рівні колін не менш 450 мм, на рівні витягнутої ноги – не менш 650 мм,

Можливість обертання екрана ВДТ навколо горизонтальної та вертикальної осі.

Рівні шуму на робочому місці людини, яка працює із ВДТ та ЕОМ, визначені ДСанПіН 3.3.2-007-98,

Для забезпечення нормованих рівнів шуму у виробничих приміщеннях і на робочих місцях застосовуються шумопоглинаючі засоби, вибір яких обумовлюється спеціальними інженерно-акустичними розрахунками. При роботі з ЕОМ вказується спеціальний граничний спектр (ПС), що складає 55.

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

Параметри мікроклімату, іонного складу повітря, зміст шкідливих речовин на робочому місці програміста SCADA, оснащеного ВДГ, повинні відповідати вимогам ДСТа 12.1.00-88 «ССБТ. Загальні санітарно-гігієнічні вимоги до повітря робочої зони», ДСанПіН 3.3.2.007-1998.

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

Вимоги безпеки праці при роботі на ЕОМ

По інструкції «Про охорону праці робочого місця програміста SCADA» програміст SCADA інструктується перед початком роботи первинним інструктажем.

Первинний інструктаж завжди проводиться на робочому місці з безпосереднім показом робіт (стажування один місяць). Потім, через кожні шість місяців проводиться повторний інструктаж,

Результати інструктажу заносяться в «Журнал реєстрації інструктажів з питань охорони праці». У журналі, після проходження інструктажу повинен бути підпис людини, яка інструктувала та програміста SCADA. Далі, підготовка робочого місця повинна виконується відповідно до нижче приведених пунктів:

увімкнути систему кондиціонування повітря в приміщенні;

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

все устаткування і блоки ЕОМ з'єднані із системним блоком за допомогою сполучних шнурів;

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

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

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

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

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

відрегулювати яскравість свічення екрану до яскравості навколишніх його поверхонь у робочій зоні не більше 3:1;

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

При роботі з клавіатурою існують наступні вимоги:

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

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

положення клавіатури і кут її повороту повинні відповідати побажанням програміста SCADA (користувача);

якщо в конструкції клавіатури не передбачений простір для опори долонь, то їх необхідно розташувати на відстані не менш 10 см від краю столу;

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

для зменшення несприйнятливого впливу на програміста SCADA пристроїв типу "миша" (змушена поза, необхідність постійного контролю за якістю дії) необхідно забезпечити вільну велику площу столу для переміщення "миші" і зручного упора ліктьового суглоба.

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

Для зменшення негативного впливу на здоров'я працюючих виробничих факторів, необхідно застосовувати регламентні перерви, У таблиці 43 приведено час регламентованих перерв програміста SCADA у залежності від категорії та групи робіт.

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

Категорія робіт	Група роботи А, кількість знаків Б, кількість знаків В,година	Час перерви при 8-годинній зміні, хв.
Оптимальна -І	до 20 000	до 15000	до 2	20
Припустима -ІІ	21 000-40000	до 30 000	до 4	40
Важка-ІІІ	понад 40 000 не більш 60 000	понад 30 000 не більш 45000	понад 4 не більш 6	60

Примітка. Група А – читання інформації з попереднім запитом (діалоговий режим роботи). Група Б – введення інформації. Група В – творча робота в режимі діалогу ЕОМ (налагодження програм, переклад і редагування текстів тощо).

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

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

для I категорії робіт - через 2 години від початку зміни і через 2 години після обідньої перерви (кожен тривалістю 10 хв.);

для II категорії робіт - через 2 години від початку зміни (тривалістю 15 хв.), через 1,5 і 2,5 годин після обідньої перерви (15 і 10 хв. відповідно чи тривалістю 5-10 хв; через щогодини роботи, в залежності від характеру технологічного процесу);

для III категорії робіт - через 2 години від початку зміни (тривалістю 15 хв.), через 1,5 і 2,5 годин після обідньої перерви (тривалістю 20 хв., кожний тривалістю 5–15 хв, щогодини роботи, в залежності від характеру технологічного процесу);

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

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

Після закінчення робіт з EOM треба:

закінчити і записати в пам'ять комп'ютера файл, що знаходився в роботі;

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

вимкнути системний блок, принтер, інші периферійні пристрої (якщо вони підключені до комп'ютера), вимкнути монітор; вимкнути стабілізатор живлення, якщо комп'ютер підключений до мережі через нього; штепсельні вилки витягнути з розетки; накрити клавіатуру кришкою для запобігання потрапляння на неї пилу;

прибрати робоче місце; забрати усі необхідні документи (чи покласти їх у шухляду);

ретельно помити руки теплою водою з милом;

виключити кондиціонер і загальне електроживлення.

ВИСНОВКИ

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

Завдяки цим компонентам система OpenSCADA отримала нові можливості які дозволяють:

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

створювати моделі технологічних, хімічних, фізичних та інших процесів;

створювати програми користувача для керування внутрішніми функціями системи OpenSCADA та її підсистемами і модулями;

виконувати допоміжні обчислення.

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

Завдяки новим можливостям, система OpenSCADA тепер може виконувати функції середовища виконання програмованих логічних контролерів. Так, найближчим часом планується адаптувати систему OpenSCADA до роботи на процесорній платі ATH400 формату PC104 фірми Diamond Systems.

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

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

Однак, розвиток середовища програмування не зупиняється. Вже зараз розглядається питання створення повноцінної об'єктної моделі системи OpenSCADA на основі середовища програмування та дерева об'єктів системи OpenSCADA.

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

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

БІБЛІОГРАФІЧНИЙ СПИСОК

1. Костельцев А.В. "Построение интерпретаторов и компиляторов", Санкт-Петербург: Наука и Техника, 2001, -224стр.

2. Чарльз Доннелли, Ричард Столлмен, "Bison. Генератор синтаксических анализаторов, совместимый с YACC", 2002, http://www.opennet.ru/docs/RUS/bison_yacc

3. А. Якобсон, Г. Буч, Дж. Рамбо "Унифицированный процесс разработки программного обеспечения", Санкт-Петербург: Питер, 2002, -496стр.

4. Элиот Расти Гарольд и У.Скотт Минс "XML – Справочник", O`REILLY, 2002, -576стр.

5. Дэвид Флэнаган "JavaScript подробное руководство", O'REILLY, 2004, -960стр.

6. Роман Савоченко, "Информационный ресурс системы OpenSCADA", 2004, http://diyaorg.dp.ua/oscada

7. Густав Олссон, Джангуидо Пиани "Цифровые системы автоматизации и управления", Невский Проспект, 2001, -557стр.

8. Роман Савоченко, "Проект системы OpenSCADA", 2005, http://diyaorg.dp.ua/oscada/doc/OpenScadaUMLdescr.pdf

9. Артур Гриффитс "GCC. Полное руководство", Киев: DiaSoft, 2004, -624стр.

10. Игорь Одинцов "Профессиональное программировани. Системный подход.", Санкт-Петербург: BHV, 2002, -512стр.

11. М.П.Гандзюк, Є.П.Желібо, М.О.Халімовський "Основи Охорони Праці", К: Каравела, 2004, -408стр.

12. Роман Савоченко "Среда програмирования OpenSCADA. Техническое задание", , 2005, -21стр.

13. Роман Савоченко "Середовище програмування системи OpenSCADA. Опис програми", , 2005, -61стр.

ДОДАТОК А. Структура системи OpenSCADA

(довідковий)

Рис. Структура системи OpenSCADA

Рис. Статична діаграма класів системи OpenSCADA

ДОДАТОК Б. Команди внутрішньої віртуальної машини

(обов'язковий)

Таблиця. Команди внутрішньої віртуальної машини модуля “JavaLikeCalc”

Команда	Код	Опис
1	2	3
End	01	Закінчення програми або виклику умови.
MviB	02 R V	Завантаження логічного признаку <V> до регістру <R>. Виконується ініціалізація регістру.
MviI	03 R V V V V	Завантаження цілого числа <V V V V> до регістру <R>. Виконується ініціалізація регістру.
MviR	04 R V V V V V V	Завантаження реального числа <V V V V V V> до регістру <R>. Виконується ініціалізація регістру.
MviS	05 R N S . .	Завантаження строки <S . .> довжиною <N> до регістру <R>. Виконується ініціалізація регістру.
AssB	06 R0 R1	Присвоєння логічного признаку з регістра <R1> регістру <R0>.
AssI	07 R0 R1	Присвоєння цілого з регістра <R1> регістру <R0>.
AssR	08 R0 R1	Присвоєння реального з регістра <R1> регістру <R0>.
AssS	09 R0 R1	Присвоєння строки з регістра <R1> регістру <R0>.
MovB	0A R0 R1	Пересунення логічного признаку з регістра <R1> до регістру <R0>. Виконується ініціалізація регістру.
MovI	0B R0 R1	Пересунення цілого з регістра <R1> до регістру <R0>. Виконується ініціалізація регістру.
MovR	0C R0 R1	Пересунення реального з регістра <R1> до регістру <R0>. Виконується ініціалізація регістру.
MovS	0D R0 R1	Пересунення строки з регістра <R1> до регістру <R0>. Виконується ініціалізація регістру.
AddI	OE R0 R1 R2	Додання цілих: R0 = R1 + R2.
AddR	OF R0 R1 R2	Додання реальних: R0 = R1 + R2.
AddS	1O R0 R1 R2	Додання строк: R0 = R1 + R2.

Продовження таблиці

1	2	3
SubI	11 R0 R1 R2	Віднімання цілих: R0 = R1 - R2.
SubR	12 R0 R1 R2	Віднімання реальних: R0 = R1 - R2.
MultI	13 R0 R1 R2	Додаток цілих: R0 = R1 * R2.
MultR	14 R0 R1 R2	Додаток реальних: R0 = R1 * R2.
DivI	15 R0 R1 R2	Ділення цілих: R0 = R1 / R2.
DivR	16 R0 R1 R2	Ділення реальних: R0 = R1 / R2.
RstI	17 R0 R1 R2	Залишок цілочисельного ділення: R0 = R1 % R2.
BitOr	18 R0 R1 R2	Побітове “АБО”: R0 = R1 | R2.
BitAnd	19 R0 R1 R2	Побітове “І”: R0 = R1 & R2.
BitXor	1A R0 R1 R2	Побітове виключаюче “АБО”: R0 = R1 ^ R2.
LOr	1B R0 R1 R2	Логічне “АБО”: R0 = R1 || R2.
LAnd	1C R0 R1 R2	Логічне “І”: R0 = R1 && R2.
LTI	1D R0 R1 R2	Ціле менше: R0 = R1 < R2.
LTR	1E R0 R1 R2	Реальне менше: R0 = R1 < R2.
GTI	1F R0 R1 R2	Ціле більше: R0 = R1 > R2.
GTR	20 R0 R1 R2	Реальне більше: R0 = R1 > R2.
LEI	21 R0 R1 R2	Ціле менше та дорівнює: R0 = R1 <= R2.
LER	22 R0 R1 R2	Реальне менше та дорівнює: R0 = R1 <= R2.
GEI	23 R0 R1 R2	Ціле більше та дорівнює: R0 = R1 >= R2.
GER	24 R0 R1 R2	Реальне більше та дорівнює: R0 = R1 >= R2.
EQI	25 R0 R1 R2	Ціле дорівнює: R0 = R1 == R2.
EQR	26 R0 R1 R2	Реальне дорівнює: R0 = R1 == R2.
EQS	27 R0 R1 R2	Строка дорівнює: R0 = R1 == R2.
NEI	28 R0 R1 R2	Ціле не дорівнює: R0 = R1 != R2.
NER	29 R0 R1 R2	Реальне не дорівнює: R0 = R1 != R2.
NES	2A R0 R1 R2	Строка не дорівнює: R0 = R1 != R2.
Not	2B R0 R1	Заперечення: R0 = !R1.
BitNot	2С R0 R1	Побітова інверсія: R0 = ~R1.
NegI	2D R0 R1	Інверсія цілого: R0 = -R1.
NegR	2E R0 R1	Інверсія реального: R0 = -R1.

Продовження таблиці

1	2	3
If	2F R E E N N	Умова, якщо <R> дійсне то виконуються команди після цієї операції і по завершенню виконується перехід по відносній адресі <N N> інакше виконуються команди за відносною адресою <EE> і по завершенню виконується перехід по відносній адресі <N N>.
FSin	30 R0 R1	Функція синус: R0 = sin(R1).
FCos	31 R0 R1	Функція косинус: R0 = cos(R1).
FTan	32 R0 R1	Функція тангенсу: R0 = tan(R1).
FSinh	33 R0 R1	Функція гіперболічного синусу: R0 = sinh(R1).
FCosh	34 R0 R1	Функція гіперболічного косинусу: R0 = cosh(R1).
FTanh	35 R0 R1	Функція гіперболічного тангенсу: R0 = tanh(R1).
FAsin	36 R0 R1	Функція арксинусу: R0 = asin(R1).
FAcos	37 R0 R1	Функція арккосинусу: R0 = acos(R1).
FAtan	38 R0 R1	Функція арктангенсу: R0 = atan(R1).
FRand	39 R0 R1	Випадкове число: R0 = rand(R1).
FLg	3A R0 R1	Десятинний логарифм: R0 = lg(R1).
FLn	3B R0 R1	Натуральний логарифм: R0 = ln(R1).
FExp	3С R0 R1	Експонента: R0 = exp(R1).
FPow	3D R0 R1 R2	Взведення у ступінь: R0 = pow(R1,R2).
FSqrt	3E R0 R1	Корінь квадратний: R0 = sqrt(R1).
FAbs	3F R0 R1	Абсолютне значення: R0 = |R1|.
FSign	40 R0 R1	Знак: R0 = sign(R1).
FCeil	41 R0 R1	Округлення до більшого: R0 = ceil(R1).
FFloor	42 R0 R1	Округлення до меншого: R0 = floor(R1).
CProc	43 F N R P P . .	Процедурний виклик зовнішньої функції <F> з параметрами <P P . .> у кількості <N>. <R> - не використовується.
CFunc	44 F N R P P . .	Виклик зовнішньої функції <F> з параметрами <P P . .> у кількості <N>. Результат функції розміщується у <R>.

ДОДАТОК С. Протоколи тестування

(обов'язковий)

Протокол тестування класу TFunctionS:

TEST:Func| TlibrarieS tests.

TEST:Func| Test1.

TEST:Func| Create the true library.

TEST:Func| Register the true library.

TEST:Func| Present check of library.

TEST:Func| Libraries list check.

TEST:Func| Test1 passed!

TEST:Func| Test2.

TEST:Func| Register the double library.

TEST:Func| Register the double library exception: Child <testLib> already avoid!

TEST:Func| Test2 passed!

TEST:Func| Test3.

TEST:Func| Library access check.

TEST:Func| Library blocking check.

DEBUG| testLib: Wait of free 1 users!

DEBUG| testLib: Wait of free 1 users!

DEBUG| testLib: Wait of free 1 users!

DEBUG| testLib: Wait of free 1 users!

DEBUG| testLib: Wait of free 1 users!

DEBUG| testLib: Wait of free 1 users!

DEBUG| testLib: Wait of free 1 users!

DEBUG| testLib: Wait of free 1 users!

DEBUG| testLib: Wait of free 1 users!

TEST:Func| Library blocking exception: testLib: Timeouted of wait!

TEST:Func| Test3 passed!

TEST:Func| Test4.

TEST:Func| Library access check.

TEST:Func| Library access exception: Child <testLib1> no avoid or disabled!

TEST:Func| Test4 passed!

TEST:Func| Test5.

TEST:Func| Remove the true library.

TEST:Func| Not present check of library.

TEST:Func| Libraries list check.

TEST:Func| Test5 passed!

TEST:Func| Test6.

TEST:Func| Remove no avoid library.

TEST:Func| Library remove exception: Child <testLib> no avoid!

TEST:Func| Test6 passed!

TEST:Func| Test7.

TEST:Func| Create the empty library.

TEST:Func| Register the empty library.

TEST:Func| Register the empty library exception: Add child id empty!

TEST:Func| Test7 passed!

Протокол тестування класу TLibFunc:

TEST:Func| TLibFunc tests.

TEST:Func| Test8.

TEST:Func| Create the true function.

TEST:Func| Register the true function.

TEST:Func| Present check of function.

TEST:Func| Functions list check.

TEST:Func| Test8 passed!

TEST:Func| Test9.

TEST:Func| Register the double function.

TEST:Func| Register the double function exception: Child <testFnc> already avoid!

TEST:Func| Test9 passed!

TEST:Func| Test10.

TEST:Func| Function access check.

TEST:Func| Function blocking check.

DEBUG| testFnc: Wait of free 1 users!

DEBUG| testFnc: Wait of free 1 users!

DEBUG| testFnc: Wait of free 1 users!

DEBUG| testFnc: Wait of free 1 users!

DEBUG| testFnc: Wait of free 1 users!

DEBUG| testFnc: Wait of free 1 users!

DEBUG| testFnc: Wait of free 1 users!

DEBUG| testFnc: Wait of free 1 users!

DEBUG| testFnc: Wait of free 1 users!

DEBUG| testFnc: Wait of free 1 users!

DEBUG| testFnc: Wait of free 1 users!

TEST:Func| Function blocking exception: testFnc: Timeouted of wait!

TEST:Func| Test10 passed!

TEST:Func| Test11.

TEST:Func| Function bad access check.

TEST:Func| Function access exception: Child <testFnc1> no avoid or disabled!

TEST:Func| Test11 passed!

TEST:Func| Test12.

TEST:Func| Remove the true function.

TEST:Func| Not present check of function.

TEST:Func| Functions list check.

TEST:Func| Test12 passed!

TEST:Func| Test13.

TEST:Func| Remove no avoid function.

TEST:Func| Function remove exception: Child <testFnc> no avoid!

TEST:Func| Test13 passed!

TEST:Func| Test14.

TEST:Func| Create the empty function.

TEST:Func| Register the empty function.

TEST:Func| Register the empty function exception: Add child id empty!

TEST:Func| Test14 passed!

Протокол тестування функції void func( TFunction *ifunc ):

TEST:Func| TValFunc tests.

TEST:Func| Test15.

TEST:Func| Create the function.

TEST:Func| Create the value function.

TEST:Func| Connect function to value.

TEST:Func| Write values.

TEST:Func| Read values

TEST:Func| Values: <TEST value>,<12345>,<12345.123450>,<1>

TEST:Func| Test15 passed!

TEST:Func| Test16.

TEST:Func| Disconnect function from value.

TEST:Func| Read values

TEST:Func| Read values exception: Function no attached!

TEST:Func| Test16 passed!

ДОДАТОК D. Технічна документація. Технічне завдання. Робочий проект.

86

Roman Savochenko

2005-11-09T17:54:49