ЗАТВЕРДЖЕНО 1116139.00218-01-ЛЗ	

Середовище програмування системи OpenSCADA

Технічне завдання

1116139.00218-01

Листів 22

2005

ЗМІСТ

ВСТУП	3

1 ПІДСТАВА ДО РОЗРОБКИ	4

2 ПРИЗНАЧЕННЯ РОЗРОБКИ	4

3 ВИМОГИ ДО СИСТЕМИ	5

3.1 Архітектурні вимоги до компонентів середовища програмування	5

3.2 Загальні вимоги	5

3.3 Вимоги до розробляємої мови програмування високого рівня	7

3.4 Вимоги до розробляємої мови блокового програмування	8

3.5 Вхідні дані	8

3.6 Вихідні дані	9

3.7 Вимоги до надійності	9

3.8 Умови експлуатації	9

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

3.10 Умови до інформаційної та програмної сумісності	12

3.11 Вимоги до маркування та пакування	13

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

3.13 Спеціальні вимоги	15

4 ВИМОГИ ДО ПРОГРАМНОЇ ДОКУМЕНТАЦІЇ	16

5 ТЕХНІКО-ЕКОНОМІЧНІ ПОКАЗНИКИ	17

6 СТАДІЇ ТА ЕТАПИ РОЗРОБКИ	20

7 ПОРЯДОК КОНТРОЛЮ ТА ПРИЙОМУ	21

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

ВСТУП

Відкрита SCADA система OpenSCADA[1] належить до класу SCADA(Supervisory Control and Data Aquisition)[2] систем. Системи даного класу використовуються як елемент систем автоматизації технологічних процесів(АСУ-ТП).

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

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

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

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

ПІДСТАВА ДО РОЗРОБКИ

Підставою до розробки компонентів середовища програмування є наказ №613 ст від 30 вересня 2005р ректора Дніпропетровського національного університету залізничного транспорту імені академіка В. Лазаряна, Пшінько О. М. «Про затвердження тем та керівників дипломного проектування студентів групи 3 ПЗ «Інституту післядипломної освіти» спеціальності 8.080403 «Програмне забезпечення автоматизованих систем»

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

ПРИЗНАЧЕННЯ РОЗРОБКИ

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

Експлуатаційним призначенням розробки є

розширення сфери застосування системи OpenSCADA за рахунок підвищення гнучкості середовищем програмування;

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

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

ВИМОГИ ДО СИСТЕМИ

Архітектурні вимоги до компонентів середовища програмування

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

Особливість архітектури системи OpenSCADA накладає відповідні умови на архітектуру розробки. Так, враховуючи модульність, гнучкість та розширюваність системи OpenSCADA, необхідно забезпечити такими ж характеристиками розробку.

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

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

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

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

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

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

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

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

середовище візуалізації;

логічний рівень параметрів.

Загальні вимоги

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

Підсистема «Функції» системи OpenSCADA має забезпечити:

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

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

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

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

зв'язування кадру значень з функцією;

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

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

У межах проекту мають бути реалізовані наступні бібліотеки функцій та обчислювальні контролери:

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

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

модуль обчислювача на мові блоків.

Модуль статичних бібліотек функцій має забезпечити:

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

формування та реєстрацію бібліотеки функцій сумісності з SCADA Complex1 фірми НІП “ДІЯ”;

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

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

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

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

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

створення програми обчислення для контролера;

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

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

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

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

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

Модуль обчислювача на мові блоків має забезпечити:

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

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

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

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

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

Для реалізації модуля обчислювача на мові програмування високого рівня та модуля бібліотек функцій на мові програмування високого рівня треба використати граматику однієї з відомих мов програмування високого рівня. Рекомендується використати граматику мови JavaScript[3] або С/С++[4].

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

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

підтримка основних операцій;

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

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

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

підтримка полегшеної схеми приведення типів;

підтримка умовних операторів, у їх складі: if, for, while;

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

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

Вимоги до розробляємої мови блокового програмування

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

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

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

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

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

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

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

Вхідні дані

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

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

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

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

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

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

Вихідні дані

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

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

Вимоги до надійності

Компоненти середовища програмування мають задовольняти наступним вимогам надійності:

стабільна та неперервна робота, включаючи нештатні ситуації у режимі 24години/добу;

містити не більш однієї помилки на 1000 операторів.

Умови експлуатації

Умови експлуатації компонентів середовища програмування треба розглядати у комплексі з системою OpenSCADA та технічними засобами, тобто треба розглядати як програмно-технічний комплекс (ПТК). Умови експлуатації для стандартних класів ПТК наведено у таблиці 1.

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

Таблиця 1. Умови експлуатації ПТК

Клас ПТК	Умови експлуатації
Робоче місце оператора-технолога.	Комплекс має використовуватися у кондиційованому приміщені з кліматичними умовами: температура: 0 - 30°С; вологість: 40 - 60%.
Технологічний сервер збору та обробки даних.	Комплекс має використовуватися у кондиційованому приміщені з кліматичними умовами: температура: 0 - 50°С; вологість: 30 - 70%.
Одноплатний контролер технологічного процесу (PC104)	Комплекс може використовуватися під відкритим небом у герметичному корпусі з кліматичними умовами: температура: -40 - 80°С; вологість: 20 - 100%.

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

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

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

Таблиця 2. Вимоги до технічних засобів за класом ПТК

Клас ПТК	Вимоги до складу технічних засобів
1	2
Робоче місце оператора-технолога.	процесор з сімейства x86 або x86_64 з частотою мінімум 1 ГГц, для підвищення продуктивності рекомендується 2 ГГц; ОЗУ: мінімум 256 Мб, для підвищення продуктивності рекомендується 512 Мб; HDD: мінімум 3 Гб, де 2.5Гб для ОC та 500Мб на систему OpenSCADA; монітор: мінімум TFT 17”, рекомендується TFT 19” для якіснішого сприйняття технологічного процесу на значній відстані; клавіатура технологічна; маніпулятор типу “миша”; аудіо-колонки для сигналізації; мережевий адаптер для підключення у мережу з технологічним сервером збору та обробки даних.
Технологічний сервер збору та обробки даних.	процесор з сімейства x86 або x86_64 з частотою мінімум 1 ГГц, для підвищення продуктивності обчислень рекомендується 2 ГГц; ОЗУ: мінімум 128 Мб, для сервера з графічним інтерфейсом рекомендується 256 Мб; HDD: мінімум RAID масив дзеркало 2x20 Гб, де 1 Гб для ОC та 19Гб на систему OpenSCADA з архівами; мережевий адаптер для підключення у мережу та надання даних системам оператора-технолога; відповідні до джерел даних комунікаційні інтерфейси.

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

1	2
Одноплатний контролер технологічного процесу (PC104)	обчислювальна система сімейства x86 з частотою процесора мінімум 100МГц, для підвищення продуктивності обчислень рекомендується 400МГц; ОЗУ: мінімум 32 Мб, для підвищення продуктивності рекомендується 128 Мб; FlashDisk: 256 Мб, де 56Мб для ОС та 200Мб на систему OpenSCADA з архівами; мережевий адаптер для підключення у мережу та надання даних технологічним серверам; відповідні до джерел даних комунікаційні інтерфейси. канали входу/виходу IO (AI,AO,DI,DO).

Умови до інформаційної та програмної сумісності

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

Виходячи з умов багатоплатформності, до мови програмування, компілятору та бібліотек можна, також, пред'явити умову доступності на багатьох програмно-апаратних платформах. Цим умовам найбільше задовольняють:

мова програмування:	С/С++

компілятор:	GCC

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

ANSI;

POSIX;

ISO;

XML;

HTML;

XHTML;

SQL.

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

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

Вимоги до програмного оточення системи можна сформулювати виходячи із стандартних класів ПТК. Програмне оточення для стандартних класів ПТК наведено у таблиці 3.

Таблиця 3. Вимоги до програмного оточення за класами ПТК

Клас ПТК	Програмне оточення
Робоче місце оператора-технолога.	ОС; графічне середовище; ПО мережевих комунікацій.
Технологічний сервер збору та обробки даних.	ОС; ПО мережевих комунікацій; ПО комунікації з зовнішніми джерелами даних.
Одноплатний контролер технологічного процесу (PC104)	ОС; ПО мережевих комунікацій;

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

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

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

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

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

Для розповсюдження, система має упаковуватися у дистрибутив. Причому, вміст дистрибутиву може бути різноманітний, у плані наповнення модулями(компонентами). Комплектація модулями може визначатися призначенням дистрибутиву. Цей метод може доповнюватися створенням дистрибутивів окремо на модуль(компонент). Назва дистрибутиву має включати ім'я системи/модуля/компонента, та версію.

Метод упаковки у дистрибутив значним чином залежить від ОС. Наприклад у ОС Linux, це можуть бути пакети RPM. Для запобігання необґрунтованих претензій, у випадку пошкодження дистрибутиву, метод упаковки в дистрибутив має передбачати перевірку цілісності дистрибутиву.

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

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

Дистрибутиви системи OpenSCADA можуть зберігатися як на фізичних носіях, так і на інформаційних ресурсах Інтернету.

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

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

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

Спеціальні вимоги

Проект компонентів середовища програмування має розроблятись як відкрита розробка за принципами “Open Source”, відповідно до чого треба використовувати одну з “вільних” ліцензій. Наприклад, це може бути GNU-ліцензія GPL. Допускається, також застосування подвійного ліцензування, це коли одна ліцензія є “вільною”, а інше комерційна.

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

Оскільки компоненти середовища програмування розробляються за принципами «Open Source» та процес розробки припускає публікацію вихідного коду, з можливістю приєднання до розробки сторонніх програмістів та організацій, то треба створити центральний репозиторій дерева вихідного кода з можливістю анонімного доступу до вихідних текстів на читання. У якості системи керування репозиторієм вихідного тексту можна використовувати системи типу: CVS, Subversion.

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

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

Випуск нової версії повинен супроводжуватися створенням протоколу змін (ChangeLog) та звіту(анонсу) про нову версію. Окрім цього, для публікації планів на майбутнє, треба випускати перелік задач запланованих до реалізації (ToDO), а також глобальний план випуску майбутніх версій з включенням ключових запланованих можливостей кожної версії(RoadMap).

ВИМОГИ ДО ПРОГРАМНОЇ ДОКУМЕНТАЦІЇ

До складу документації на середовище програмування мають входити:

технічне завдання;

робочий проект:

специфікація;

текст програми;

опис програми;

керівництво користувача. Програміста SCADA системи;

керівництво системного програміста.

ТЕХНІКО-ЕКОНОМІЧНІ ПОКАЗНИКИ

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

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

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

Таблиця 4. Витрати на видаткові матеріали

№ п/п	Найменування матеріалу	Витрати, шт.	Ціна, грн./шт.	Сума, грн.
1	Послуги Інтернету	700Мб.	1 грн./Мб	700
2	Допоміжна література	5	100	500
3	Канцтовари	-	-	100
Разом	1300

Тепер визначимо основну заробітну платню розробника ПЗ за станами розробки. Розрахунок основної заробітної платні розробника для окладу 1000 грн. зведено у таблицю 5.

Таблиця 5. Основна заробітна платня розробника

№ п/п	Найменування стану	Трудомі-сткість, чол.дн.	Трудомі-сткість, чол.міс.	Витрати по з/п, грн
1	Обґрунтування необхідності розробки компонентів.	5	0.22	220
2	Розробка та затвердження технічного завдання.	10	0.45	450
3	Складання UML-моделі	5	0.22	220
4	Розробка компонентів середовища програмування.	50	2.27	2270
5	Налагодження компонентів, розробка тестів та тестування компонентів середовища програмування.	10	0.45	450
6	Розробка статичних бібліотек функцій	5	0.22	220
7	Розробка бібліотеки моделей технологічних апаратів.	14	0.63	630
8	Створення моделі вузла технологічного процесу.	20	0.909	909
9	Створення дистрибутиву.	5	0.22	220
10	Створення опису компонентів середовища програмування.	7	0.318	318
11	Створення керівництво програміста SCADA системи.	7	0.318	318
12	Створення керівництва системного програміста.	7	0.318	318
Разом	6543

Визначимо додаткову заробітну платню, яка складає 10% від основної заробітної плати:

0,1 * 6543 = 654,3 грн.

Визначимо фонд заробітної плати який складає основну та додаткову заробітну плату:

6543 + 654,3 = 7197,3 грн.

Визначимо відрахування на соціальні нестатки які складають 38,51% від фонду оплати праці:

0,3851 * 7197,3 = 2771,68 грн.

Визначимо загальновиробничі витрати які складають 25 % від величини основної заробітної плати:

0,25 * 6543 = 1635,75 грн.

Визначимо прямі виробничі витрати які включають витрати на машинний час (131 день розробки вартісттю 5грн./годину та 2% від фонду заробітної плати):

(1048 * 5) + (0,02 * 7197,3) = 5383,946 грн.

Калькуляцію зведено у таблицю 6.

Таблиця 6. Калькуляція загальних витрат

№ п/п	Найменування статей витрат	Витрати, грн
1	Видаткові матеріали.	1300
2	Основна заробітна плата розробника.	6543
3	Додаткова заробітна плата розробника.	654.3
4	Відрахування на соціальне страхування.	2771.68
5	Загальновиробничі витрати.	1635,75
5	Прямі виробничі витрати.	5383,946
Разом	Зт = 14862,7

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

СТАДІЇ ТА ЕТАПИ РОЗРОБКИ

Таблиця 7. Стадії та етапи розробки

Стадії розробки, звітна документація	Етапи робот	Строк
Технічне завдання	Обґрунтування необхідності розробки компонентів. 30.09.2005 Розробка та затвердження технічного завдання. 02.10.2005
Робочий проект, та документація у його складі	Складання UML-моделі 05.10.2005 Розробка компонентів середовища програмування. 20.10.2005 Налагодження компонентів, розробка тестів та тестування компонентів середовища програмування. 30.10.2005 Розробка статичних бібліотек функцій 01.11.2005 Розробка бібліотеки моделей технологічних апаратів. 05.11.2005 Створення моделі вузла технологічного процесу. 10.11.2005 Створення дистрибутиву. 14.11.2005 Створення опису компонентів середовища програмування. 15.11.2005 Створення керівництво програміста SCADA системи. 17.11.2005 Створення керівництва системного програміста. 20.11.2005

ПОРЯДОК КОНТРОЛЮ ТА ПРИЙОМУ

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

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

створювати тести які покривають нові функції;

виконувати повну перебудову системи;

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

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

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

Прийом здійснюється комісією за погодженням сторін.

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

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

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

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

4. Дейтел Х., Дейтел П. "Как программировать на C++. Третье издание", Бином, 2001, 700стр.

1116139.00218-01

2

2005-05-21T12:09:12