SCADA системи

РефератДопомога в написанніДізнатися вартістьмоєї роботи

SCADA системи (реферат, курсова, диплом, контрольна)

Министерство Спільного і Фахового Освіти Російської Федерации.

Івановський Державний Енергетичний Университет.

Кафедра Електроніки і Мікропроцесорних систем.

за курсом: «Системи контролю та візуалізації» на тему:

«SCADA-системы».

Виконав студент грн. 1−34M.

Шмаргун А.Н.

Проверил:

Анісімов А. А.

Іваново 2003.

Зміст: Запровадження 2 АСУ ТП і диспетчерське управління 2 Компоненти систем контролю та управління та його призначення 4 Розробка прикладного програмного забезпечення СКУ: вибір шляху й інструментарію 7 Технічні характеристики 8 Відкритість систем 9 Вартісні характеристики 10 Експлуатаційні характеристики 10 Графічний інтерфейс 11 Графічні кошти InTouch 11 Вікна в InTouch 11 Об'єкти і їхні властивості 13 Організація взаємодії з контролерами 16 Апаратна реалізація зв’язки й з пристроями ввода/вывода 17 Сервери ввода/вывода в InTouch 18 Підтримувані комунікаційні протоколи 18 Особливості адресації в InTouch 20 Обмін даними коїться з іншими додатками 21 Визначення імені доступу у Словнику змінних InTouch 22 Тренди в SCADA — системах 25 Тренди в InTouch 25 Архивирование (реєстрація) значень перемінної 26 Відображення трендів 26 Зміна параметрів архівних трендів як виконання 29 Система розподілених архівів 29 Вбудовані мови програмування 30 Скрипти в InTouch 31 Типи скриптов 31 Вбудовані функції 32 Функції Quick Functions 36 Розробка графопостроителя у системі InTouch 37 Розробка DDE-сервера 37 Розробка DDE — клієнта 39 Список літератури 41.

Введение

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

АСУ ТП і диспетчерське управление Непрерывную у часі картину розвитку АСУТП можна розділити втричі етапу, зумовлені появою якісно нових наукових ідей технічних коштів. У результаті історії змінюється характер об'єктів і методів управління, коштів автоматизації та інших компонентів, складових зміст сучасної системи управления.

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

(САР). Об'єктами управління цьому етапі є окремі параметри, установки, агрегати; вирішення завдань стабілізації, програмного управління, спостереження переходить від чоловіка до САР. Людина з’являються функції розрахунку завдання й параметри настройки регуляторов.

. Другий етап — автоматизація технологічних процесів. Об'єктом управління стає рассредоточенная у просторі система; з допомогою систем автоматичного управління (САУ) реалізуються дедалі більше складні закони управління, вирішуються завдання оптимального і адаптивного управління, проводиться ідентифікація об'єкту і станів системы.

Характерною ознакою цього етапу є систем телемеханіки у керування технологічними процесами. Людина дедалі більше віддаляється від об'єкта управління, між об'єктом і диспетчером вибудовується низку вимірювальних систем, виконавчих механізмів, коштів телемеханіки, мнемосхем та інших засобів відображення інформації (СОИ).

. Третій етап — автоматизовані системи управління технологічними процесами — характеризується впровадженням у управління технологічними процесами обчислювальної техніки. Спочатку — застосування мікропроцесорів, використання на окремих фазах управління обчислювальних систем; потім активний розвиток людино-машинних системам управління, інженерної психології, методів і моделей дослідження операцій та, нарешті, диспетчерське управління з урахуванням використання автоматичних інформаційних систем збирання цих і сучасних обчислювальних комплексів. Від етапи до етапу змінювалися і функції людини (оператора/диспетчера), покликаного забезпечити регламентне функціонування технологічного процесу. Розширюється коло завдань, розв’язуваних лише на рівні управління; обмежений прямий необхідністю управління технологічним процесом набір завдань поповнюється якісно новими завданнями, раніше мають допоміжний характер чи які стосуються іншому рівню управління. Диспетчер в багаторівневої автоматизованої паспортної системи управління технологічними процесами отримує інформацію з монітора ЕОМ чи з електронної системи відображення інформації та впливає на об'єкти, які перебувають від цього значній відстані відстані з допомогою телекомунікаційних систем, контролерів, інтелектуальних виконавчих механізмів. Основою, необхідною умовою ефективної реалізації диспетчерського управління, має яскраво виражений динамічного характеру, стає роботу з інформацією, т. е. процеси збору, передачі, обробки, відображення, подання. Від диспетчера вже потрібно тільки професійна знання технологічного процесу, основ управління ним, а й досвід роботи у інформаційних системах, вміння приймати рішення (у діалозі зі ЕОМ) в позаштатних і аварійних ситуаціях та багато іншого. Диспетчер стає головною дійовою особою під управлінням технологічним процесом. Ведучи мову про диспетчерском управлінні, мушу торкнутися проблеми технологічного ризику. Технологічні процеси енергетики, нафтогазової та інших галузей промисловості є потенційно небезпечними і за виникненні аварій призводять до людських жертв, і навіть до значному матеріального і екологічному збитку. Статистика каже, що з тридцять років кількість врахованих аварій подвоюється приблизно щодесять років. У основі будь-якого аварії крім стихійних лих лежить помилка людини. Через війну аналізу більшості аварій та подій всіма видами транспорту, у промисловості та енергетику отримано цікаві дані. У 60 — x роках помилка людини була спрямована початкової причиною аварій лише 20% випадків, тоді як до кінця 80-х частка «людського «стала наближатися до 80%. Один із причин цієї тенденції - старий традиційний підхід побудувати складних системам управління, т. е. орієнтація застосування новітніх технічних і технологічних здобутків і традицій недооцінка необхідності побудови ефективного человеко — машинного інтерфейсу, орієнтованого на людини (диспетчера). Отже, вимога підвищення надійності систем диспетчерського управління одній з передумов новий підходу при розробці таких систем: орієнтація на оператора/диспетчера та його завдання. Концепція SCАDA (Supervisory Control And Data Acquisition — диспетчерське управління економіки й збір даних) визначена всім ходом розвитку систем управління і результатами науково-технічного прогресу. Застосування SCADAтехнологій дозволяє досягти високого рівня автоматизації у вирішенні завдань розробки системам управління, збору, обробки, передачі, збереження і відображення інформації. Дружність человеко-машинного інтерфейсу (HMI/MMI), наданого SCADA — системами, повнота і наочність представленої на екрані інформації, доступність «важелів «управління, зручність користування підказками і довідкової системою та т. буд. — підвищує ефективність взаємодії диспетчера з системою і зводить нанівець його критичні помилки при управлінні. Слід зазначити, що концепцію SCADA, в основі якої становить автоматизована розробка системам управління, дозволяє вирішити і інших завдань, довгий час вважалися нерозв’язними: скоротити терміни розробки проектів із автоматизації і прямі фінансових витратах з їхньої розробку. Нині SCADA є основним і найперспективніших методом автоматизованого управління складними динамічними системами (процесами). Управління технологічними процесами з урахуванням систем SCADA стало здійснюватися у передових західні країни у роки. Область застосування охоплює складні об'єкти електроі водопостачання, хімічні, нафтохімічні і нафтопереробні виробництва, залізничний транспорт, транспорт нафти і ін. У Росії її диспетчерське управління технологічними процесами спиралося, переважно, на досвід оперативно-диспетчерського персоналу. Тому перехід до управління з урахуванням SCADA-систем став здійснюватися кілька пізніше. До труднощів освоєння у Росії нової інформаційної технології, який є SCADA-системы, належить як відсутність експлуатаційного досвіду, і недолік інформації про різноманітні SCADA-системах. У налічується десятки компаній, які займаються із розробкою та впровадженням SCADA-систем. Кожна SCADA-система — це «know-how «компанії та тому даних про тій чи іншій системі менш великі. Важливе значення у впровадженні сучасних систем диспетчерського управління має рішення наступних задач:

. вибору SCADA-системы (з вимог, і особливостей технологічного процесса);

. кадрового супроводу. Вибір SCADA-системы є досить важке завдання, аналогічну прийняттю рішень на умовах многокритериальности, ускладнену неможливістю кількісної оцінки низки критеріїв через брак інформації. Підготування спеціалістів з розробки й експлуатації системам управління на базі програмного забезпечення SCADA складає спеціалізованих курсах різних фірм, курсах підвищення кваліфікації. Нині в навчальні плани низки технічних університетів почали вводитися дисципліни, пов’язані вивчення SCADA-систем. Проте спеціальна література по SCADAсистемам відсутня; є лише окремі статті і рекламні проспекты.

Компоненты систем контролю та управління та його назначение Многие проекти автоматизованих систем контролю та управління (СКУ) для боль-шого спектра областей застосування дозволяють виділити узагальнену схему реалізації, подану на рис. 1.

|[pic] | |Мал.1. Узагальнена схема системи контролю та управління. |.

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

. Нижній рівень — рівень об'єкта (контроллерный) — включає різні датчики для збору інформації про перебіг технологічного процесу, електроприводи і виконавчі механізми для реалізації регулюючих і більше управляючих впливів. Датчики поставляють інформацію локальним программируемым логічним контролерам (PLC — Programming Logical.

Controoller), які можуть опинитися виконувати такі функції: o збирання та обробка інформації про параметрах технологічного процесу; o управління электроприводами та інші виконавчими механізмами; o вирішення завдань автоматичного логічного управління і др.

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

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

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

Для критичних з цим погляду об'єктів рекомендується використовувати контролери з операційними системами реального часу (ОСРВ). Контролери під керівництвом ОСРВ функціонують як жорсткого реального времени.

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

К цього класу інструментального ПО ставляться пакети типу ISaGRAF (CJ International France), InConrol (Wonderware, USA), Paradym 31 (Intellution, USA), мають відкриту архитектуру.

. Інформація з локальних контролерів можна направляти до мережі диспетчерського пункту безпосередньо, і навіть через контролери верхнього рівня (див. рис.). Залежно від поставленого завдання контролери верхнього рівня (концентратори, інтелектуальні чи комунікаційні контролери) реалізують різні функції. Деякі їх перераховані нижче: o збір даних із локальних контролерів; o обробка даних, включаючи масштабирование; o підтримку єдиного часу у системі; o синхронізація роботи підсистем; o організація архівів по обраним параметрами; o обміну інформацією між локальними контролерами і верхнім рівнем; o робота у автономному режимі при порушеннях зв’язки України із верхнім рівнем; o резервування каналів передачі і др.

. Верхній рівень — диспетчерський пункт (ДП) — включає, передусім, одну чи кілька станцій управління, що становлять автоматизоване робоче місце (АРМ) диспетчера/оператора. Але тут то, можливо розміщений сервер бази даних, робочі місця (комп'ютери) спеціалістів тощо. буд. Часто як робочу силу станцій используются.

ПЕОМ типу IBM PC різних конфигураций.

Станції управління призначені для відображення ходу технологічного процесу оперативно керувати. Ці завдання й покликані вирішувати SCADA.

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

Спектр функціональних можливостей визначено самої роллю SCADA в системах управління і було реалізовано практично переважають у всіх пакетах: o автоматизована розробка, що дозволяє створення ПЗ системи автоматизації без реального програмування; o кошти виконання прикладних програм; o збір первинної інформації від пристроїв нижнього рівня; o обробка первинної інформації; o реєстрація алармов і історичних даних; o зберігання інформації із її пост-обработки (зазвичай, реалізується через інтерфейси до найпопулярнішим баз даних); o візуалізація інформацією вигляді мнемосхем, графіків тощо.; o можливість роботи прикладної системи з наборами параметрів, аналізованих як «єдине ціле «(«recipe «чи «установки »).

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

SCADA — системи верхнього рівня є универсальными.

. Усі компоненти системи управління об'єднані між собою каналами зв’язку. Забезпечення взаємодії SCADA — систем з локальними контролерами, контролерами верхнього рівня, офісними і промисловими мережами покладено зване комунікаційне ПО. Це досить широке клас програмного забезпечення, вибір якого для конкретної системи управління визначається багатьох чинників, зокрема і типом застосовуваних контролерів, і використовуваної SCADA — системою. Більше докладна інформацію про комунікаційному ПО приведено у розділі 2.

. Великий обсяг інформації, безупинно який із пристроїв ввода/вывода системам управління, визначає його присутність серед таких системах баз даних (БД). Основне завдання баз даних — своєчасно забезпечити користувача всіх рівнів управління необхідної информацией.

Але якби верхніх рівнях АСУ це завдання вирішено за допомогою традиційних БД, то цього скажеш про рівень АСУ ТП. Донедавна реєстрація інформацією часі вирішувалася з урахуванням ПО інтелектуальних контролерів і SCADA — систем. Останнім часом з’явилися нові спроби з забезпечення високошвидкісного зберігання інформацією БД. Більше докладна інформація за базами даних реального часу приведено у розділі 6.

. Бурхливий розвиток Інтернет були не привернути увагу виробників програмного продукту SCADA. Чи можливо застосування Інтернет — технологій у системах управління технологічними процесами? Якщо можна, то які рішення пропонуються нині компаніями — розробниками? Обговоренню цих питань присвячена глава 7.

Разработка прикладного програмного забезпечення СКУ: вибір шляху й инструментария Приступая до розробки спеціалізованого прикладного програмного забезпечення (ВПО) до створення системи контролю та управління, системний інтегратор чи кінцевий користувач зазвичай вибирає одне із наступних путей:

. Програмування з допомогою «традиційних «коштів (традиційні мови програмування, стандартні кошти налагодження і пр.).

. Використання існуючих, готових — COTS (Commercial Of The Shelf) — інструментальних проблемно-орієнтованих коштів. Більшість вибір вже очевидний. Процес розробки ВПО важливо спростити, скоротити часові й прямі фінансових витратах розробці ВПО, мінімізувати витрати висококласних програмістів, наскільки можна залучаючи до розробки спеціалістів-технологів у сфері автоматизируемых процесів. За такої постановки завдання другий шлях може виявитися більш кращим. Для складних розподілених систем процес розробки власного ВПО з використанням «традиційних «коштів може бути неприпустимо тривалим, а видатки розробку невиправдано високими. Варіант з безпосереднім програмуванням щодо привабливий тільки до простих систем чи невеликих фрагментів великий системи, котрим немає стандартних рішень (не написано, наприклад, підходящий драйвер) або їх не влаштовують за тими чи інших причин у принципі. Отже, вибір шляху зроблено! Це дуже важливо, але давайте тоді потрібно зробити і друге крок — «визначитися «з інструментальними засобами розробки ППО.

Программные продукти класу SCADA широко представлені на світовому ринку. Це кілька десятків SCADA — систем, чимало з яких знайшли собі застосування у Росії. Найпопулярніші їх наведено ниже:

. InTouch (Wonderware) — США;

. Citect (CI Technology) — Австралия;

. FIX (Intellution) — США;

. Genesis (Iconics Co) — США;

. Factory Link (United States Data Co) — США;

. RealFlex (BJ Software Systems) — США;

. Sitex (Jade Software) — Великобритания;

. TraceMode (AdAstrA) — Россия;

. Cimplicity (GE Fanuc) — США;

. САРГОН (НВТ — Автоматика) — Росія. За такої різноманітті SCADA — продуктів російському ринку природно виникає запитання про вибір. Вибір SCADA-системы є досить важке завдання, аналогічну пошуку оптимального рішення на умовах многокритериальности. Нижче наводиться приблизний перелік критеріїв оцінки SCADA — систем, які насамперед повинні цікавити користувача. Цей перелік важливих не є авторським і які вже обговорюється у спеціальній періодичної пресі. У ньому виділити великі групи показателей:

. технічні характеристики;

. вартісні характеристики;

. експлуатаційні характеристики.

Технические характеристики Программно-аппаратные платформи для SCADA-систем.

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

В той час в SCADA-системах, як RealFlex і Sitex основу програмної платформи принципово становить єдина операційна система реального часу QNX. Переважна більшість SCADA-систем реалізовано на MS Windows платформах. Саме через такі системи пропонують найбільш цілковиті і легко наращиваемые MMI — кошти. З огляду на позиції Microsoft над ринком операційними системами (ОС), треба сказати, що й розробники многоплатформных SCADA-систем, такі як United States DATA Co (розробник FactoryLink), пріоритетним вважають розвиток своїх SCADA-систем на платформі Windows NT. Деякі фірми, досі підтримували SCADA-системы з урахуванням операційними системами реального часу (ОСРВ), почали змінювати орієнтацію, обираючи системи на платформі Windows NT. Дедалі більше очевидним стає застосування ОСРВ, переважно, у які вбудовуються системах, де їх справді хороші. Отже, основним полем, де нині розгортаються головні події глобального ринку SCADA—систем, стала MS Windows NT/2000 і натомість все ускоряющегося згортання активності у області MS DOS, MS Windows 3. xx/95. Наявні кошти мережевий підтримки. Однією з основних чорт сучасного світу систем автоматизації був частиною їхнього високий рівень інтеграції. У будь-якій із них можна задіяти об'єкти управління, виконавчі механізми, апаратура, реєструюча і обробна інформацію, робочі місця операторів, сервери баз даних, і т.д. Вочевидь, що з ефективного функціонування цієї різнорідною середовищі SCADA-система мають забезпечувати високий рівень мережного сервісу. Бажано, щоб він підтримувала роботу у стандартних мережевих середовищах (ARCNET, ETHERNET тощо.) з допомогою стандартних протоколів (NETBIOS, TCP/IP та інших.), і навіть забезпечувала підтримку найпопулярніших мережевих стандартів з класу промислових інтерфейсів (PROFIBUS, CANBUS, LON, MODBUS тощо.) Цим вимогам у тому чи іншою мірою задовольняють майже всі аналізовані SCADA-системы, про те лише відмінностями, що набір підтримуваних мережевих інтерфейсів, ясна річ, різний. Вбудовані командні мови. Більшість SCADA-систем мають вбудовані мови високого рівня, VBasicподібні мови, дозволяють генерувати адекватну реакцію на події, пов’язані зі зміною значення перемінної, з виконанням деякого логічного умови, з натисканням комбінації клавіш, ні з виконанням деякого фрагмента із заданою частотою щодо всього докладання чи окремого вікна. Підтримувані бази даних. Однією з основних цілей систем диспетчерського контролю та управління є обробка інформації: збір, оперативний аналіз, зберігання, стиснення, пересилання тощо. буд. Отже, у межах створюваної системи повинна функціонувати база даних. Практично всі SCADA-системы, зокрема, Genesis, InTouch, Citect, використовують ANSI SQL синтаксис, що є незалежною від типу бази даних. Отже, докладання віртуально ізольовані, що дозволяє змінювати базі даних без серйозного зміни самої прикладної завдання, створювати незалежні програми для аналізу інформації, використовувати вже напрацьоване програмне забезпечення, орієнтоване на обробку даних. Графічні можливості. Для специалиста-разработчика системи автоматизації, як і для фахівця — «технолога », чиє робоче місце створюється, дуже важливий графічний користувальницький інтерфейс. Функціонально графічні інтерфейси SCADA-систем дуже схожі. У кожній із них існує графічний объектно-ориентированный редактор з певним набором анімаційних функцій. Використовувана векторна графіка дає можливість здійснювати широкий набір операцій над обраним об'єктом, і навіть швидко оновлювати зображення на екрані, використовуючи кошти анімації. Вкрай мають значення питання про підтримку в системах стандартних функцій GUI (Graphic Users Interface). Оскільки більшість аналізованих SCADA-систем працюють під керівництвом Windows, те й визначає тип використовуваного GUI.

Открытость систем Система є відкритої, для неї визначено й описані використовувані формати даних, і процедурний інтерфейс, що дозволяє залучити до ній «зовнішні «, незалежно розроблені компоненти. Розробка власних програмних модулів. Перед фірмами-розробниками систем автоматизації часто йдеться про створенні власних (не передбачених у рамках систем SCADA) програмних модулів і включення їх у створювану систему автоматизації. Тому постає запитання про відкритість системи є важливим характеристикою SCADA-систем. Фактично відкритість системи означає доступність специфікацій системних (себто SCADA) викликів, що реалізують той чи інший системний сервіс. Це може бути доступом до графічним функцій, функцій роботи з базами даних тощо. Драйвери вводу-виводу. Сучасні SCADA-системы не обмежують вибору апаратури нижнього рівня, оскільки надають великий набір драйверів чи серверів виводу-введення-висновку і мають добре розвинені кошти створення власних програмних модулів чи драйверів нових пристроїв нижнього рівня. Самі драйвери розробляються з використанням стандартних мов програмування. Питання, проте, у цьому, чи достатньо лише специфікацій доступу до ядру системи, поставлених фирмой-разработчиком в штатному комплекті (система Trace Mode), або заради створення драйверів необхідні спеціальних пакетах (системи FactoryLink, InTouch), або ж, взагалі, розробку драйвера потрібно замовляти фірмарозробника. Розробки третіх фірм. Багато компаній займаються розробкою драйверів, ActiveX-объектов і іншого програмного забезпечення для SCADA-систем. Це дуже важливо оцінювати під час виборів SCADA-пакета, оскільки це розширює область застосування системи непрофесійними програмістами (не потрібно розробляти програми з допомогою мов З чи Basic).

Стоимостные характеристики При оцінці вартості SCADA-систем потрібно враховувати такі факторы:

. вартість програмно-апаратної платформы;

. вартість системы;

. вартість освоєння системы;

. вартість сопровождения.

Эксплуатационные характеристики Показатели цієї групи критеріїв найбільш суб'єктивні. Це той самий випадок, коли краще одного разу побачити, ніж сім разів почути. До цій групі можна отнести:

. зручність інтерфейсу середовища розробки — «Windows — такий інтерфейс », повнота інструментарію і державних функцій системы;

. якість документації - її повнота, рівень русификации;

. підтримку з боку творців — кількість інсталяцій, дилерська мережу, навчання, умови відновлення версій тощо. буд. Якщо припустити, що користувач впорався і з цим завданням — зупинив свій вибір у конкретній SCADA — системі, то далі починається розробка системи контролю та управління, що включає такі этапы:

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

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

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

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

. Налагодження створеної прикладної програми як эмуляции. У наступних розділах з прикладу двох визначних акторів і добре зарекомендували себе SCADA-систем (InTouch і Citect) розглянуті основні компоненти, функції й можливості систем диспетчерського управління та збору данных.

Графический интерфейс Средства візуалізації - одна з базових властивостей SCADA — систем. У кожній із них існує графічний объектно — орієнтований редактор з певним набором анімаційних функцій. Використовувана векторна графіка дає можливість здійснювати широке коло операцій над обраним об'єктом. Об'єкти може бути простими (лінії, прямокутники, текстові об'єкти тощо. буд.) складні. Можливості агрегирования складних об'єктів у різних SCADA — системах різні. Усі SCADA — системи включають бібліотеки стандартних графічних символів, бібліотеки складних графічних об'єктів, мають цілу низку інших стандартних можливостей. Але, тим щонайменше, кожна SCADA — система по-своєму унікальна й, попри підтримку стандартних функцій, має властивими лише йому особливостями. Зблизька графічних можливостей SCADA — систем InTouch і Citect передбачається звернути не лише спроможності інструментаріїв зі створення графічних об'єктів, а й у інші надані користувачеві послуги, які полегшують і що прискорюють процес розробки додатків (проектов).

Графические кошти InTouch.

Компоненты середовища розробки InTouch:

. WindowMaker — інструментальна середовище розробки приложений;

. Application Explorer — уявлення докладання в ієрархічному вигляді з доступом до будь-якого компоненту докладання і чим часто що використовуються командам і функцій WindowMaker. Проект, створений пакеті InTouch, є набір вікон (Window) з різними графічними і текстовими объектами.

Окна в InTouch.

Свойства кожного вікна (наявність заголовка, колір фону, розміри тощо. буд.) визначаються під час створення. Створення нового вікна виробляється у середовищі розробки WindowMaker клацанням по іконці панелі інструментів General чи командою File/New Window. На екрані з’явиться діалог Window Properties (Властивості вікна, рис. 2).

|[pic] | |Рис. 2. Діалог Window Properties (Властивості вікна). |.

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

У центрі Comment можна запровадити коментар, пов’язаний із цією вікном (необов'язково). Цю інформацію потрібна лише документування і використовується приложением.

InTouch пропонує три типу вікон (Window Туре):

. Replace (заменяющее) — закриває що існують вікна, перекрываемые їм під час появу на екрані, включаючи вікна типу Popup та інші вікна типа.

Replace.

. Overlay (перекрывающее) — з’являється поверх всіх відображуваних в цей час вікон. Коли вікно типу Overlay закривається, все приховувані їм вікна відновлюються. Щигля миші з кожного видимому ділянці лежачого нижче вікна призводить до переходу його за передній план.

. Popup (всплывающее) — схоже вікно типу Overlay, лише вона завше залишається поверх від інших відкритих вікон. Вікно закривається після відповідної команди користувача. Вибір типу створюваного вікна виробляється включенням відповідної кнопки на полі Window Туре.

В полі Frame Style (стиль обрамлення) вибирається необхідний стиль обрамлення окна:

. Single — вікно з рамкою, допускається заголовок;

. Double — вікно з рамкою без заголовка;

. None — вікно без рамки і заголовка. Щоб у вікна була смуга з заголовком, де виводиться ім'я вікна, включають опцію Title Bar. Ця смуга також є для переміщення вікна під час захоплення її мишею. При виборі цієї опції відключаться опції Double і None для стилю обрамления.

Для можливості зміни розмірів вікна, як його відкриється в WindowMaker, слід вибрати опцію Size Controls (управління размером).

В групі полів Dimentions визначаються поточні розміри і становище вікна на робочому поле:

. X Location — відстань пикселях між лівим краєм робочого поля.

WindowMaker і лівих краєм описуваного окна;

. Y Location — відстань пикселях між верхнім краєм робочого поля.

WindowMaker і верхнім краєм описуваного окна;

. Window Width — ширина вікна в пикселях;

. Window Height — висота вікна в пикселях. За умовчанням під час створення нового вікна ці параметри приймуть значення попереднього (останнього) створеного вікна. Кнопка Scripts (скрипти) дає можливість ввійти у діалог Window Script для створення віконного сценарію. Для уніфікації зовнішнього вигляду вікон докладання і скоротити терміни розробки додатків InTouch пропонує кілька прийомів. Одне з таких прийомів — дублювання вікон. Створення копій вікон виконується командою File/ Save Window As. Для швидкого доступу до команди можна скористатися меню правої кнопки миші (див. нижче). Другий прийом, також дозволяє заощаджувати час розробки докладання — імпорт вікон. Можна повторно використовувати усі раніше створені вікна, об'єкти і скрипти. Щоб імпортувати вікна з іншого InTouch — докладання, необхідно скористатися командою File/ Import. Інтерфейс WindowMaker з відкритою вікном представлений рис. 3. |[pic] | |Рис. 3. Інтерфейс WindowMaker. |.

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

Объекты та його свойства Простые объекты.

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

. Лінія — це об'єкт, являє собою чи кілька пов’язаних відрізків. Товщина лінії її стиль є статичними властивостями лінії, присваиваемыми їй під час створення, і тільки колір лінії може бути зв’язаний з анімаційної функцией.

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

. Текст є послідовність символів. До статичним властивостями тексту ставляться тип шрифту, її розмір, виділення, курсив, підкреслення, вирівнювання. Анімаційні властивості шрифту — колір, видимість і расположение.

. Кнопко — часто використовуваний об'єкт під час створення операторських інтерфейсів. З кнопками може бути пов’язані функції різних типов.

Натискання кнопки може викликати виконання скриптов, кнопкою можна робити введення аналогових і дискретних величин тощо. буд. Текст на кнопці редагується з допомогою команди Special/Substitute Strings… У цьому текстове полі може містити тільки один строку.

Один і хоча б об'єкт може мати набір різних динамічних властивостей. Комбінації цих властивостей дають можливість створювати на екрані в режимі виконання (Runtime) практично будь-які динамічні ефекти. Для установки динамічних властивостей треба передусім викликати на екран діалог їх вибору (рис.4). Це досягається командою Special/Animation Link чи подвійним клацанням лівої кнопки миші на объекте.

|[pic] | |Рис. 4. Діалог вибору динамічних властивостей об'єкта. |.

Все динамічні зв’язку можна розділити на дві групи: Touch Links (ліва колонка) і Display Links (три колонки справа). З допомогою властивостей Touch Links виконується який — або введення до системи. Властивості Display Links здійснюють висновок інформації на екран дисплея.

Натискання кожну клавішу діалогу (рис. 4) викликає поява нового діалогу визначення відповідного властивості об'єкта. Кількість діалогів відповідає кількості динамічних властивостей (кнопок) діалогу вибору. Усі діалоги різні, але із них має загальні характеристики:

. вікно типу объекта;

. однакову палітру цветов;

. швидкий виклик словника переменных;

. швидкий доступом до полях переменных;

. підтримку правої кнопки миші в полях Tagname (ім'я перемінної) и.

Expression (вираз). На див. мал.5 наведено діалог визначення властивостей об'єкта (кнопки), управляючого значенням дискретної переменной.

|[pic] | |Див. Мал.5. Діалог визначення властивостей кнопки. |.

Завершение роботи з діалогом виробляється натисканням кнопки Ok. Якщо змінна поля Tagname була раніше визначена у словнику змінних даного докладання, користувач повертається у діалог вибору динамічних властивостей об'єкта (рис. 4). Можна або продовжити визначення інших динамічних властивостей для даного об'єкта, або, натиснувши Ok, повернутися в полі розробки вікна приложения.

Сложные объекты.

. Символ — це деяка комбінація простих об'єктів, які обробляються одностайно об'єкт. Будь-яка зміна статичних чи динамічних властивостей символу впливає всі складові символа.

Наприклад, якщо створити символ «насос «з цих двох кіл і двох прямокутників і привласнити йому динамічний властивість Fill Color (колір заповнення), це властивість поширюватиметься чотири простих объекта.

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

. Компонент — це сукупність двох чи більше об'єктів, символів чи інших компонентів, їхнім виокремленням єдиний елемент. Вони створюються шляхом вибору двох і більше об'єктів, символів чи компонентів і наступного запуску команди Arrange/Make Cell. Компоненти реалізують просторову взаємозв'язок між складовими їх графічними елементами. Кожна складова компонента може мати свої власні динамічні властивості. Компоненти йдуть на таких віртуальних пристроїв, як панель управління контролером, движковый регулятор тощо. д.

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

Arrange/Break Cell. Проте компоненти можна дублювати, копіювати, вставляти, вирівнювати, переміщувати й т. буд. Мастер-объект — це попередньо створений компонент з деякими статичними і динамічними властивостями, що у бібліотеці майстероб'єктів (Wizards) і доступним багаторазового застосування. Але, на відміну від компонента, динамічні властивості якого настроюється кожної складової окремо до об'єднання на компонент, динамічні властивості мастер-объекта швидко настроюється з допомогою спеціалізованого діалогу. Інакше кажучи, фірма Wonderware провела велику роботи й створила величезне кількість мастер-объектов (кілька тисяч), визначивши кожного з них механізм швидкої настройки статичних і динамічних властивостей. Всі ці мастер-объекты розділені на дуже багато груп, і розміщені в відповідної бібліотеці. Доступ до неї здійснюється натисканням іконки Wizard в інтерфейсі WindowMaker, що викликає поява на екрані діалогу Wizard Selection (Вибір мастер-объекта. У лівої частини діалогу — список груп мастер-объектов, до складу якого такі категорії, як Buttons (кнопки), Sliders (ползунковые регулятори), Switches (перемикачі) тощо. д.

В правій частині діалогу приведено всі мастер-объекты обраної у цей момент групи. Подвійний щиголь по необхідному мастер-объекту повертає користувача у вікно розробки докладання. Курсор набуває форми куточка з символом. Нарешті, щиголь миші на вільному місці вікна призводить до появі мастер-объекта з вікна докладання. На його конфигурирования (визначення динамічних властивостей) слід двічі клацнути на майстеробъекте.

Достаточно запровадити ім'я дискретної перемінної, бажаний текст на кнопці, відзначити кілька опцій й тицьнути на Ok. Інструмент Bitmap інструментальної панелі малювання дозволяє скопіювати й вбудовувати в додаток InTouch растрові об'єкти (сукупність точок). З допомогою нього створюється «контейнер «для наступної вставки об'єкта з папки обміну Windows або файлів з розширенням .BMP, .JPG, .PCX, .TGA. Для WindowMaker растровое зображення є єдиним об'єктом. Неможливо ні анимировать його частини, ні вставляти Bitmap — об'єкти у символи (можна вставляти в компоненти). Такий об'єкт можна розгорнути робочому поле, на 90, 180, 270, 360 градусів, і навіть визначити йому колір «прозорості «, аби за нього було побачити й інші объекты.

· Тренди. InTouch пропонує користувачеві два складних об'єкта типу тренд: тренд реального часу й історичний (архівний) тренд. Ці об'єкти дозволяють відображати як графіків значення даних реального часу (4 пера) і архівах (8 пір'їн). Обидва типу трендів створюються при використанні спеціальних інструментів панелі малювання вікна WindowMaker з наступним конфигурированием. Детальна інформація зі створення й конфигурированию трендів буде приведено у відповідній главе.

Підсумовуючи опису графічних коштів пакета InTouch, треба сказати, що фірму Wonderware у плані пропонує споживачеві хороший набір возможностей:

. багатий, традиційний для користувачів Windows инструментарий;

. меню правої кнопки миші для вікон, графічних об'єктів і полів диалогов;

. широкий, спектр динамічних властивостей объектов;

. величезну бібліотеку мастеров-объектов (Wizards).

Организация взаємодії з контроллерами Современные SCADA — системи не обмежують вибору апаратури нижнього рівня (контролерів), оскільки надають великий набір драйверів чи серверів ввода/вывода і мають добре розвинені кошти створення власних програмних модулів чи драйверів нових пристроїв нижнього уровня.

Для під'єднання драйверів ввода/вывода до SCADA — системі на цей час використовуються такі механизмы:

. став стандартом de facto динамічний обмін даними (DDE);

. власні протоколи фірм-виробників SCADA — систем, реально щоб забезпечити самий швидкісної обмін данными;

. новий OPC — протокол, який, з одного боку, є стандартним і підтримується більшістю SCADA — систем, з другого боку, позбавлений недоліків протоколів DDE. Спочатку протокол DDE застосовувався у перших человеко — машинних інтерфейсах як механізм поділу даних між прикладними системами і пристроями типу ПЛК (программируемые логічні контролери). Для подолання недоліків DDE, передусім на підвищення надійності і швидкості обміну, розробники запропонували свої власні рішення (протоколи), такі як AdvancedDDE чи FastDDE — протоколи, пов’язані з пакетуванням інформації під час обміну з ПЛК і мережними контролерами. Але такі приватні рішення призводять до ряду проблем:

. кожної SCADA — системи пишеться свій драйвер для поставленого ринку оборудования;

. у випадку, два пакета що неспроможні мати доступом до одному драйверу за одну і те час, бо з них підтримує обмін саме з своїм драйвером. Основна мета OPC стандарту (OLE for Process Control) залежить від визначенні механізму доступу до даних з будь-якої світової устрою з додатків. OPC дозволяє виробникам устаткування поставляти програмні компоненти, які стандартним способом забезпечать клієнтів даними з ПЛК. При значне поширення OPC — стандарту з’являться такі преимущества:

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

. OPC — усунуть необхідність використання різного нестандартного устаткування й відповідних комунікаційних програмних драйверов;

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

Аппаратная реалізація в зв’язку зі пристроями ввода/вывода Для організації взаємодії з контролерами можна використовувати такі апаратні средства:

. COM — порты.

І тут контролер чи об'єднані мережею контролери підключаються за протоколами RS-232, RS-422, RS-485.

. Мережні платы.

Використання такий апаратної підтримки можливо, якщо відповідні контролери обладнані интерфейсным виходом на Ethernet.

. Вставні платы.

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

ISA, PCI, CompactPCI. Прикладні протоколи, використовувані в організацію взаємодії з контролерами, залишені по закордонах цієї книги.

Серверы ввода/вывода в InTouch.

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

InTouch — додаток підтримує взаємодію Космосу з DDE і OPC-серверами. На організації взаємодії з ними зупинимося ниже.

Поддерживаемые комунікаційні протоколы.

DDE (Dynamic Data Exchange — динамічний обмін даними) є комунікаційний протокол, розроблений компанією Microsoft обмінюватись даними між різними Windows — додатками. Цей протокол реалізує взаємозв'язку типу клієнт — сервер між двома одночасно исполняющимися программами.

В InTouch підтримується також запакетований DDE — обмін — FastDDE. Застосування останнього помітно підвищує ефективність яких і продуктивність обміну даними завдяки зменшенню загальної кількості DDE — пакетів, якими клієнт і сервер обмінюються між собою. Але принципові недоліки, пов’язані з надійністю і залежності від кількості завантажених в цей час додатків Windows, залишилися. Необхідність в появу досконалішого технологічн протоколу дозріла! Але треба відзначити, що від DDE-механизма відбувається миттєво хоча б оскільки у світі напрацьовано дуже багато DDE — серверов.

С метою можливостей стандартного протоколу DDE на локальну мережу компанія Wonderware запропонувала NetDDE. Він дає змогу додатків, запущеним на об'єднаних в локальну мережу комп’ютерах, вести DDE — обмін. Пізніше NetDDE ліцензується компанією Microsoft і приходить у дистрибутивном пакеті Windows. Слід зазначити і те, що NetDDE допускає обміну інформацією між додатками на IBM PC і додатками машинами іншого типу з операційній системою VMS чи UNIX. Компанія Wonderware пропонує і інструментальні кошти на розробки DDE-серверов, у цьому однині і для не-Windows-платформ.

Протокол SuiteLink був спеціально розроблений фірмою Wonderware у тому, щоб задовольнити таких вимог, як даних, висока продуктивність і простота діагностики. У основі протоколу SuiteLink лежить протокол TCP/IP. SuiteLink перестав бути заміною протоколів DDE, FastDDE і NetDDE. Новий протокол розроблений підтримки швидкодіючих промислових систем й володіє такими характеристиками:

. Передача даних ввозяться форматі VTQ (Value, Time, Quality — значення, час, якість), відповідно до яким кожна пересилають клієнту одиниця інформації супроводжується знаками часу й якості данных.

. Завдяки системному монітора ОС Windows NT.

(Performance Monitor) став можливий розширений аналіз продуктивності про передачу даних, ступеня завантаження серверу, ступеня споживання ресурсів комп’ютера та мережі, що особливо важливо задля проектування й супроводу великих розподілених промислових сетей.

. Підтримка обміну даними між додатками відбувається незалежно від цього, виконуються ці докладання однією вузлі сіті або різними. Задля реалізації функцій OPC — клієнта Wonderware пропонує OPCLink — сервер, перетворюючий OPC в SuitLink — протокол.

В матеріалах, запропонованих компанією Wonderware, відзначається, що більшість реалізованих OPC-серверов створюють кожному за подключаемого до серверу клієнта новий канал зв’язку чи нитку. Для поточної обробки кожного клієнта сервер повинен переключатися між нитками. Кожна нитку використовує DCOM (Distributed Component Object Model) в організацію обміну даними, і DCOM також управляє переключенням ниток. У результаті можлива досить низька продуктивність в сети.

Тесты, проведені фірмою Wonderware, показали, що з обслуговуванні OPCсервером 7 клієнтів (під час передачі 4 цілих чисел як відновлення) сервер на 95% обіймав ресурси CPU. Це означає, що ресурси комп’ютера практично повністю були задіяні перемиканням ниток і DCOMпроцедурами.

Поэтому на поточному етапі параметри продуктивності протоколу SuiteLink перевершують параметри DCOM. Поставлений в комплекті FactorySuite (Wonderware) OPCLink Server забезпечує прийом інформації з OPCсерверу та передачу її за протоколу SuiteLink в SCADA — систему InTouch і навпаки. Саме OPCLink Server рекомендується встановлювати однією вузлі з OPCсервером, щоб для мережевих передач використовувався SuiteLinkпротокол, а чи не DCOM (рис.7).

|[pic] | |Рис. 7. Використання SuiteLink — протоколу в SCADA — системах. |.

Все описані нижче особливості адресації поширюються і OPC-серверы з однією лише обмеженням. Під час розробки InTouch — докладання створюється канал через відкликання OPCLink — сервером (і з будь-якою іншою SuiteLink — сервером). Але рекомендується використовувати вмонтований в InTouch OPC Browser для спрощення вибору параметрів конфігурації подключаемого OPC — сервера.

Особенности адресації в InTouch.

В InTouch вищевказані механізми покладено основою обміну даними між додатками InTouch і DDE і SuiteLink — серверами, які, на свій чергу, пов’язані комунікаційними каналами з пристроями нижнього рівня (контроллерами).

Оскільки InTouch призначений і розробити й підтримки інтерфейсу збору даних, і диспетчерського управління (див. мал.8), середовище виконання WindowViewer при взаємодії з контроллерным рівнем виступає, зазвичай, у ролі докладання — клієнта (вузол View), запрашивающего дані у докладання — серверу (I/O Server).

|[pic] | |Див. Мал.8. Обмін даними між InTouch — додатком і технологічним | |процесом. |.

Через сервер ввода/вывода InTouch — додаток має можливість читати дані з контролера чи писати дані до нього. Процес обміну InTouch — докладання з контролером можна наступній схемой Здесь і постає одна з головних питань організації обміну з серверами ввода/вывода: як забезпечити клієнту доступом до яку просять їм информации?

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

. ім'я вузла (Node Name);

. ім'я докладання (Application Name);

. ім'я групи даних чи топік (Topic Name);

. ім'я елемента (Item Name). Ім'я докладання — це програми Windows, що виконує функції DDE, FastDDE, SuiteLink — серверів. Ім'я групи даних (топіка) визначається при конфигурировании серверу приймання чи передачу групи даних, якими сервер обмінюватиметься з контролером чи об'єднаними до мережі контролерами. Певні параметри групи (топіка) залежить від конкретного серверу (тому рекомендується вивчати документацію і довідкову систему обраного серверу). Наприклад, під час використання Modbus — серверу, що дозволяє забезпечити взаємодію Космосу з контролером Modicon Micro 984 PLC, як докладання (Application Name) може бути Modbus, як групи чи топіка (Topic Name) вводиться будь-яке ім'я (текстова рядок), але серед необхідних параметрів групи зі списку вибирається ім'я контролера Modicon 984 PLC. На ролі імені елемента (Item Name) слід вибирати назва конкретного регістру контролера (наприклад, 40 001 для контролера Modicon Micro 984). Щоб дізнатися правильний синтаксис імені елемента, необхідний конкретних PLC, потрібно звернутися до керівництва з відповідного серверу.

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

|[pic] | |Рис. 9. Обмін інформацією прикладі Modbus — серверу. |.

Фирма Wonderware пропонує DDE і SuiteLink — сервери, які підтримують більш 800 типів контролерів основних у виробників і різні протоколи. Якщо потрібного драйвера ні, можна скористатися пакетом розробки драйверів FactorySuite Toolkit. Схеми, наведені на рис. 9, інтерпретують стандартний обміну інформацією між вузлом (додатком) View і контролером (ПЛК) як збирання цих і управління. У цьому вся режимі, як було зазначено вище, додаток View — клієнт по определению.

Обмен даними коїться з іншими приложениями, Но докладання InTouch можуть взаємодіяти як між собою, але й іншими Windows — додатками. Однією з відомих прикладів такого докладання є Microsoft Excel. InTouch — додаток може зчитувати і записувати які - або значення будь-яку клітину відкритої Excel електронної таблиці. Те саме і програма Excel може читати і записувати інформацію до бази даних InTouch — докладання. Цей механізм забезпечує одночасне відновлення даних щодо одного додатку за зміни їх значень в другом.

Якщо клієнтом (додатком, запрашивающим інформацію) по — колишньому є вузол View, то Excel — це додаток, що поставляє інформацію (сервер). Як групи чи топіка (Topic) стане виступати ім'я таблиці Excel, а елемент обміну інформацією між — осередок в таблиці Excel (табл.2.1, варіант 1).

Коли клієнтом є додаток Excel, а сервером — додаток View, групою у разі завжди є словник змінних InTouch (база даних) безпосередньо з ім'ям Tagname. Елементом обміну буде елемент бази даних — ім'я перемінної (табл.2.1, варіант 2).

В разі обміну даними через мережу з допомогою пакета Wonderware NetDDE необхідно до трирівневої структурі адреси додати четвертий рівень — ім'я віддаленого вузла мережі (Node Name). Підсумовуючи вищевикладене, слід підкреслити, що про доступ до даних пристроїв ввода/вывода чи інших додатків повинна зберігатися в додатку (у Словнику змінних). І розробникові в InTouch-приложении важливо підключитися до вищеописаному каналу доступу. І тому в InTouch необхідно визначити ім'я доступу Access Name і намагається пов’язати його з перемінної приложения.

Определение імені доступу у Словнику змінних InTouch.

В InTouch — додатках всю інформацію про змінних докладання зберігається в Tagname Dictionary (Словник змінних). Не що інше, як даних реального часу — одне із центральних компонентів InTouch.

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

В пакеті InTouch використовується два базових типу змінних — Memory (внутрішні) і I/O (перемінні ввода/вывода).

Переменные типу Memory можна використовувати до створення різних системних констант, моделювання елементів системи управління й у вычисляемых змінних, доступних іншим Windows — программам.

Все перемінні, які отримують чи передають своє значення інший Windows — програмі, повинен мати тип ввода/вывода (I/O). У цю категорію потрапляють перемінні, котрі за допомогою каналу доступу (Access Name) приймають чи відправляють дані із/у серверів ввода/вывода, інших додатків InTouch, інших програм Windows.

Определение нової перемінної базі даних InTouch, як і перегляд, і модифікація атрибутів вже існуючих змінних, виробляється у діалозі Tagname Dictionary (рис.10). Доступ до цього діалогу здійснюється командою Speсial/Tagname Dictionary з вікна середовища розробки WindowMaker чи подвійним клацанням по іконці Tagname Dictionary з вікна Application Explorer.

|[pic] | |Рис. 10. Діалог Tagname Dictionary (Словник змінних). |.

Поля Tagname і Comment призначені для введення імені перемінної і відповідного коментарю. За умовчанням включена опція Read/Write (чтение/запись). Можна справити й опцію Read Only, тоді як процесі виконання WindowViewer має лише читати значення перемінної. У час як проектування можна відкрити список змінних докладання клацанням по кнопці Select для вибору відповідної перемінної, перегляду списку чи модифікації атрибутів. Діалог Select Tag (вибір перемінної) представлений рис. 11.

|[pic] | |Рис. 11. Діалог Select Tag (вибір перемінної). |.

Для кожної перемінної у тому діалозі приведено наступна інформація: ім'я перемінної, її тип, ім'я доступу, група аларма і коментар. Група алармов (Alarm group, рис.11) для перемінної визначається діалозі, викликуваному натисканням кнопки Group діалогу Tagname Dictionary. Усі, що стосується алармов, у відповідному розділі нижче. Вибір типу перемінної ввозяться діалозі Tag Types (тип перемінної, рис. 12), викликуваному на екран натисканням кнопки Туре діалогу Tagname Dictionary.

|[pic] | |Рис. 12. Діалог Tag Types (тип перемінної). |.

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

После вибору типу перемінної програма повертає користувача в діалог Tagname Dictionary (Словник змінних). У цьому буде відкрито і додатковий діалог докладну розповідь перемінної, зміст якого залежить вибраного типу. Кнопка Access Name (ім'я доступу) використовується визначення каналу обміну (каналу доступу) з сервером, з яким буде пов’язана описувана змінна. Ім'я доступу Access Name визначається ім'ям вузла, ім'ям докладання і ім'ям групи чи топіка. Ім'я топіка має збігатися з певним ім'ям, заданим при конфигурировании DDE, SuiteLink-сервера. Ім'я елемента, як компонента багаторівневого адреси, визначається полі Item (рис.13).

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

Локальные адреси використовують у тому випадку, коли View — вузли мають сервери ввода/вывода. На рис. 13 вузли виконання (View — вузли), кожний із своєї копією однієї й тієї ж докладання, посилаються за свої власні джерела даних ввода/вывода (сервери ввода/вывода).

|[pic] | |Рис. 13. Мережа View — вузлів зі своїми серверами ввода/вывода. |.

Поэтому щодо каналу доступу до інформації ввода/вывода досить трирівневого адреси (Application — додаток, Topic — об'єкт, Item — елемент). Ім'я вузла (Node) у разі опускається. Щигля по кнопці Access Name (рис. 2.3.8) викликає на екран однойменний діалог. Цей діалог призначений визначення нового каналу доступу (кнопка Add), модифікації існуючого (Modify) чи видалення (Delete). Щигля по кнопці Add викликає діалог визначення нового каналу доступу. Як імені (каналу) доступу (Access Names) рекомендується вибирати ім'я групи чи топіка (Topic Name). Слід сказати, що полі Node Name (ім'я вузла) залишено порожнім. Щигля по кнопці Ok повертає користувача в діалог Access Names (імена доступу) з певним ім'ям доступа.

Глобальные адреси джерел даних ввода/вывода дозволяють кільком View — вузлам звертатися одного й тому серверу ввода/вывода. Такий їхній підхід дає можливість відмовитися і від кількох серверів ввода/вывода, проте менш захищений від відмов (рис.14).

|[pic] | |Рис.14. Архітектура з цими двома View — вузлами і сервером ввода/вывода. |.

Два View — вузла виконують ідентичні копії однієї й тієї ж докладання і посилаються однією і хоча б джерело ввода/вывода (I/O сервер). Тому, за визначенні каналу доступу до інформації ввода/вывода необхідно використовувати четырехуровневый адресу (Node — вузол, Applicationдодаток, Topic — об'єкт, Item — елемент). При виборі імені доступу діє те правило, що й за локальної адресації: рекомендується, щоб це збігалося безпосередньо з ім'ям групи даних чи топіка (Topic Name). Але полі Node Name (ім'я вузла) необхідно заповнити. Як це ім'я при глобальної адресації вибирають ім'я вузла, на якому встановлено сервер ввода/вывода, є джерелом даних для кількох додатків. Для кожної перемінної ввода/вывода задається атрибут Access Name. З одним ім'ям доступу, зазвичай, пов’язано дуже багато змінних. Розподіл змінних за групами (топикам) — довільне. Для оптимізації функціонування серверів рекомендується до однієї групи відносити перемінні однаково часто відновлення. Інакше частота, що задається при конфигурировании топіка в сервері, має відповідати мінімального тимчасовому кванту. Бажано на етапі конфигурирования серверу визначити групи (топики) кожному за частотного діапазону й у відповідність до цими групами створити імена доступу (Access Name) в InTouch (краще навіть, щоб імена груп збігалися із конкретними іменами доступу). А далі кожну описувану в InTouch-приложении зміну типу I/O пов’язувати з підхожим ім'ям доступу задля забезпечення раціонального пакетирования данных.

Тренды в SCADA — системах Графическое уявлення значень технологічних параметрів у часі сприяє кращому розумінню динаміки технологічного процесу підприємства. Тому підсистема створення трендів і збереження інформації про параметрах із її подальшого аналізу та спрямування управління є невід'ємною частиною будь-який SCADA — системи. Тренди реального часу (Real Time) відбивають динамічні зміни параметра нинішнього року часу. За появи нового значення параметра з вікна тренду відбувається прокручування графіка справа-наліво. Отже поточне значення параметра виводиться завжди у правій частині вікна. Тренди стають історичними (Historical) по тому, як дані будуть записані на диск і можна використовувати режим прокручування попередніх значень з метою подивитися минулі значення. Що Відобразяться дані тренду такому режимі залишаться нерухомими і буде відображатись лише за певний период.

Тренды в InTouch.

InTouch пропонує користувачеві обидва типу графічних об'єктів, званих трендами: тренд реального часу й історичний (архівний) тренд. Тренди реального часу дають можливість створювати графіки зміни у часі чотирьох змінних (4 пера), тоді як історичних трендів можна конфіґурувати до максимально восьми пір'їн щодо одного об'єкті. Кількість об'єктів типу «тренд «при застосуванні, зокрема й у одному вікні, необмежена. Обидва типу трендів створюються з використанням спеціальних графічних об'єктів інструментальної панелі WindowMaker. InTouch також забезпечує повний контроль над конфигурированием трендів. Наприклад, можна визначити діапазон часу, область значень, дозвіл сітки, розміщення тимчасових оцінок, число пір'їн і атрибути кольору та т. буд. Допускається переконфигурирование архівного тренду на етапі виконання докладання (в Runtime).

Архивирование (реєстрація) значень переменной При роботі системи як WindowViewer (середовище виконання) InTouch може виробляти запис значень змінних в реєстраційний файл. А, щоб архивирование перемінної виконувалося, необхідно включити опцію Log Data (реєстрація даних) щодо перемінної у діалозі Tagname Dictionary.

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

Чтобы значення змінних, котрим опція Log Data дозволена, записувалися до реєстраційні файли, необхідно загальне дозвіл глобальної функції реєстрації. Його задають у діалозі Historical Logging Properties (параметри архівування, рис. 15), який викликається на екран командою Special/Configure/Historical Logging. У цілому цей діалог можна також ознайомитися ввійти з відкритого вікна Application Explorer. |[pic] | |Рис.15. Діалог Historical Logging Properties. |.

Включение опції Enable Historical Logging дає загальне дозволу реєстрацію значень змінних. Термін збереження реєстраційних файлів на диску (виключаючи поточний день) визначається полі Keep Log Files for в днях. Якщо це полі введено значення 0, файли зберігатимуться нескінченно довго. Реєстраційні файли можуть бути в каталозі докладання (опція за умовчанням Store Log Files in Application Directory). У протилежному разі треба сказати опцію Store Log Files in Specific Directory (зберігати файли будь-якому іншому каталозі) і введення повний шлях до каталогу, у якому зберігатимуться реєстраційні файли (під час роботи з розподіленими архівами — повний мережевий путь).

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

Чтобы створити тренд реального часу, необходимо:

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

WindowMaker;

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

. відпустити кнопку миші, що викличе появу тренду реального часу у вікні (рис.16). |[pic] | |Рис.16. Об'єкт «тренд реального часу ». |.

Під час створення тренду реального часу настройки його конфігурації встановлюються за умовчанням (настройки попереднього тренду). Для конфигурирования тренду реального часу слід або двічі клацнути на створеному об'єкті, або, попередньо обравши об'єкт, запустити команду Special/Animation Links. На екрані з’явиться діалог Real Time Trend Configuration (конфигурирование тренду реального часу). Серед настройок цього діалогу можна назвати діапазон часу, охоплюваний трендом (Time Span), частоту виведення значення перемінної (Interval), дозвіл сітки по великим та з малим розподілам горизонтальній і вертикальної осей (Time Division, Value Division), кольору фону і рамки графіка (Color). Конфигурирование пір'їн тренду включає вибір імені перемінної чи висловлювання, кольору та товщини лінії кожному за пера (полі Expression). На підвищення продуктивності системи треба сказати опцію Only update when in memory (оновлювати, як у пам’яті). І тут відновлення даних тренду здійснюватиметься лише у моменти, коли вікно з трендом відображається на дисплеї (перебуває у RAM). Є й інші способи підвищення продуктивності під час роботи з трендами реального часу (зменшення товщини лінії графіка, зменшення частоти висновки значень перемінної). Наприклад, якщо встановлено діапазон часу (Time Span) за 30 я хвилин, а частота виведення — 2 секунди, то число вимірів, потрібно провести за кожні 30 хвилин, дорівнюватиме 900 (30 * 60/2 = 900). При частоті виведення в розмірі 5 секунд число вимірів істотно зменшується: 30 * 60/5 = 360. Історичні (архівні) тренди є динамічними. Вони забезпечують «знімок «стану даних за час, тобто за архівним даним. У на відміну від трендів реального часу історичні тренди оновлюються лише за командою — під час запуску скрипта, зміні значення висловлювання чи натисканні оператором відповідної кнопки. При конфигурировании архівного тренду можна створити «визиры «(повзунки, бігунки), з допомогою яких зручно отримати значення всіх відображуваних змінних однією і хоча б момент часу. Бігунки архівного тренду є позиційні індикатори на тимчасової осі, становище визначає обсяг добуваних даних. Пов’язавши об'єкт «движковый регулятор «з полем бігунка, можна проводити переміщення вздовж архівного тренду. З іншого боку, є функції обчислення середнього, мінімального і максимального значень у певному бегунком становищі. Можна створити правий і лівий бігунки і виробляти обробку даних кривою, розташованої між бегунками. Обчислюються такі величини: середнє, мінімальне, максимальне, ставлення мин/макс і стандартне відхилення. Залежно від становища бігунків на осі можна реалізувати й інші функції (збільшення і зменшення яка є між бегунками області графіка). Завдяки системі розподілених архівів однією і хоча б графік можна виводити інформацію з кількох баз даних. Усе вище щодо створення тренду реального часу інструментом Real Time Trend серед розробки WindowMaker й про його наступному конфигурировании можна адресувати його й архівному тренду, створюваному інструментом Historical Trend середовища розробки. Запропонований нижче засіб створення і конфигурирования архівного тренду припускає використання мастер-средств бібліотеки Wizard. Натискання кнопки вибору мастер-средств в панелі інструментів викликає поява на екрані діалогу Wizard Selection (вибір мастер-средств).

После вибрати з запропонованого набору мастер-средств Hist Trend with Scooters (архівний тренд з бегунками) і щиглика по Ok програма повертає користувача у середу розробки. Курсор миші у своїй прийме форму вставки. Наступний щиголь миші на імовірному місці перебування створюваного об'єкта виводить на екран архівний тренд (рис.17). Об'єкти цього ведуть себе аналогічно будь-якою іншою об'єктах, тобто їх можна переміщати, масштабувати тощо. д.

|[pic] | |Рис.17. Об'єкт «архівний тренд ». |.

Двойной щиголь на об'єкті призводить до появи на екрані діалогу конфигурирования архівного тренду (Historical Trend Char Window).

|[pic] | |Рис.18. Діалог конфигурирования архівного тренду. |.

Для конфигурирования тренду з параметрами за умовчанням слід натиснути кнопку Suggest (варіант). Натискання кнопок Times і Values виводить на екран вікна конфигурирования дозволу сітки по великим малий розподілам горизонтальній і вертикальної осей, кольору фону і рамки графіка, тимчасового діапазону тощо. буд. Кнопко Pens (пера) варта настройки пір'їн архівного тренду. Щоб додати в тренд функції масштабирования і переміщення чи елементи управління пір'ям, варто використовувати панелі Zoom/Pan і Trend Pen Legend (рис.16), відповідно. А, щоб ці компоненти працювали спільно, вони повинні мати однакові імена (Hist Trend).

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

Для цього треба включити опцію Allow runtime changes (дозволити зміни під час виконання) у діалозі конфигурирования архівного тренду (у книзі не показан).

Теперь як WindowViewer щиголь на архівному тренде викликатиме на екран діалог зміни параметрів архівного тренду (Historical Trend Setup). У цьому вся діалозі можна визначити дату та палестинці час початку архівного тренду (полі Chart Start), його тимчасової діапазон (Chart Length), привласнити пір'я колір і імена змінних, обираючи їх із словаря.

Архивный тренд може виводитися у одному з трьох можливих режимах:

. Min/Max — графік зміни значень перемінної як вертикальних ліній у відсотках від України всього діапазону, дозволяє оцінити швидкість зміни переменной;

. Average/Scatter — графік середнього значення переменной;

. Average/Bar Chart — графік середнього значення перемінної як гистограммы. Вибір режиму виробляється у полі Display Mode.

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

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

Система, наведена на рис. 19, має дві провайдера архівів. Лівий провайдер реєструє інформацію тільки з вузла, розташованого зліва внизу. Правий провайдер реєструє інформацію з вузла, розташованого справа вгорі. Інші три вузла (вгорі зліва) лише використовують архівні дані. Читати інформацію з архівних файлів може кожен із вузлів системы.

Создание такої системи передбачає такі действия:

. створення списку провайдерів архивов;

. створення умов та визначення параметрів об'єкта «архівний тренд » ;

. конфигурирование докладання на глухе архивирование данных;

. копіювання докладання попри всі вузли. |[pic] | |Рис. 19. Розподілена система архівів. |.

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

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

. Орієнтація на системного інтегратора. І тут як мов найчастіше використовують VBasic — подібні мови. У кожному мові допускається розширення набору функцій. У мовами, орієнтованих технологів, це розширення досягається з допомогою додаткових інструментальних коштів (Toolkits). Розробка додаткових функцій виконується зазвичай програмістами — профессионалами.

Разработка нових функцій другий — коли підході виконується зазвичай розробниками додатків (як й у традиційних мовами програмування). Повнота використання можливостей вбудованих мов (особливо в другому підході) вимагає відповідного рівня кваліфікації розробника, якщо, звісно, цьому є необхідність. Вимоги завдання може бути менш високими, щоб застосовувати всю «міць «вмонтованого мови. В усіх життєвих мовами функції поділяються на групи, частина у тому числі присутній практично переважають у всіх мовами: математичні функції, функції роботи з рядками, обмін по SQL, DDE — міна й т. буд. У разрабатываемом додатку створюються програмні фрагменти, які з операторів та зняття функцій мови, які виконують деяку послідовність дій. Ці програмні фрагменти пов’язуються з різноманітними подіями при застосуванні, такі як натискання кнопки, відкриття вікна, виконання логічного умови (a +b > з). І з подій асоціюється з графічним об'єктом, вікном, таймером, відкриттям/ закриттям докладання. Коли додаток містить сотні вікон, тисячі різних графічних об'єктів, і з кожним із них пов’язано кілька таких подій, при застосуванні може «працювати «дуже багато окремих програмних фрагментів. Велика ймовірність їх «одночасної «активізації. Кожна з функцій у вмонтованому мові виконується в синхронному чи асинхронному режимі. У синхронному режимі виконання наступній функції не починається до того часу, доки завершилося виконання попередньої. При запуску асинхронної функції управління переходить наступній, без очікування завершення виконання попередньої функции.

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

Скрипты в InTouch.

Скрипты в InTouch — це програмні фрагменти, активизируемые з подій (по натискання клавіші, кнопки, відкриттю вікна, зміни значення перемінної і т. д.).

Типы скриптов В InTouch розрізняють кілька типів скриптов:

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

. Window Scripts (скрипти рівня вікна) пов’язуються з конкретним окном.

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

. Touch Pushbutton Action Scripts (скрипти, запущені кнопками) дуже схожі на на клавішні скрипти і пов’язуються з об'єктами, що використовуватимуться як виконавчих кнопок. Ці скрипти запускаються при кожному натисканні на объект-кнопку.

. Condition Scripts (скрипти зі зміни логічного висловлювання) пов’язуються з логічного перемінної чи вираженням, що буде приймати значення або «істина », або «брехня ». Логічні скрипти можуть утримувати у собі аналогові переменные.

. Data Change Scripts (скрипти зі зміни даних) зв’язуються або з перемінної, або з полем перемінної. Ці скрипти виконуються лише одне раз, коли значення перемінної або поля змінюється на величину, перевищує значення допуску, заданого у Словнику переменных.

. ActiveX Event (скрипти подій ActiveX) призначені на підтримку механізму реакцію події у ActiveX — об'єктах. Із кожним подією може бути зв’язаний один скрипт типу ActiveX Event, підготовлений до запуску в.

WindowViewer під час виконання приложения.

. Quick Function — скрипти, які можуть опинитися викликатися з деяких інших скриптов і використовуватися у висловлюваннях щодо динамічних властивостей об'єктів. Діалоги редактора, открываемые під час створення скриптов різних типів, мають невеликі відмінності. Виклик діалогу редактора скриптов з вікна WindowMaker здійснюється командою Special/Scripts з наступним вибором типу створюваного чи редагованого скрипта. І тому можна також ознайомитися скористатися вікном Application Explorer, обравши папку Scripts. На рис. 5.1.1 наведено діалог Application Scripts (скрипти рівня докладання). Редактор скриптов InTouch підтримує два типу скриптов: прості і складні. Прості скрипти — це скрипти, містять оператори присвоювання, порівняння, прості математичні функції тощо. буд. Складні скрипти дозволяють виконувати різні логічні операції типу IF — THEN — ELSE, і навіть можуть включати цикли типу FOR — NEXT. Праворуч, на полі Functions, розміщені клавіші виклику списків різних груп вбудованих функцій. Доступ до списків вбудованих функцій може бути також командою Insert/Functions з наступним вибором групи функцій (див. рис. 5.1.1).

Встроенные функции В пакеті InTouch є набір вбудованих функцій, які можна пов’язані з командами чи використані скриптах до виконання самих різних задач.

Усі вбудовані функції розбиті чотирма группы:

— String… — в обробці різних символьних рядків і переменных;

— Math… — математичні функции;

— System… — системні функции;

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

· Виклик списку функцій групи здійснюється натисканням відповідної клавіші. Наприклад, щиголь по клавіші String… редактора скриптов викликає поява діалогу Choose function (вибір функції) з переліком строковых функций.

Описание деяких функцій цього наведено в табл. 5.1.

Каждая строковая функція має чи кілька аргументів (до 6). Наприклад, синтаксис функції StringFromReal виглядає наступним образом:

StringFromReal (Number, Precision, Type);

— Number — конвертована речовинна величина;

— Precision — кількість десяткових знаков;

— Type — тип формату («f », «e », «E »). Наприклад, функція StringFromReal (263.365, 2, «f ») повертає «263.36 » ;

функція StringFromReal (263.365, 2, «e ») повертає «2.63e2 » ;

функція StringFromReal (263.55, 3, «E ») повертає «2.636E2 » .

Функція Text має дві аргументу: Text (Analog_Tag, «Format_Text »);

— Analog_Tag — речовинне чи ціле число;

— Format_Text — формат перетворення. Якщо зазначений формат функції Text — «#0.00 », то:

— при Analog_Tag = 66 функція повертає 66.00;

— при Analog_Tag =22.269 функція повертає 22.27;

— при Analog_Tag =9.999 функція повертає 10.00.

. Щигля по клавіші Math… викликає поява діалогу Choose function.

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

. Системні функції діляться на дві категорії: файлові (File) й у роботи з Windows — додатками (Info). Файлові функції призначені для зчитування і запис інформацією файли. В усіх файлових функцій є дві загальних аргументу — Filename і FillOffset. Аргумент Filename (ім'я файла) зберігає ім'я файла, з яких мусить бути зчитана чи який має бути записана інформація (ім'я також має вмикати й шлях до файлу). Аргумент FillOffset (усунення в файлі) задає відносну позицію у файлі, починаючи з якою читатимуться чи записуватися дані. Зміщення поставив у байтах з початку файла. Перший байт файла має усунення 0. Після закінчення кожна функція повертає таке доступне усунення в файлі. Наприклад, якщо функція читає 5 байтів даних, починаючи з 10-го байта, то після завершення функція поверне 15. Деякі вбудовані функції групи System наведені у табл. 5.2.

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

Наприклад, функція FileReadFields має чотири аргументу і такий синтаксис:

FileReadFields (Filename, FileOffset, StartTag, NumberOfFields);

— StartTag — ідентифікує перший елемент в імені InTouchпеременной;

— NumberOfFields — ідентифікує число полів для чтения.

. Група функцій Miscellaneous (клавіша Misc…) включає функції до роботи з алармами розподілених систем, трендами, печаткою та ін. У цьому широкої (з погляду призначення функцій) групи виділити трохи більше вузько спеціалізованих підгруп. Функції, назва яких починається з alm, задіяні лише в розподілених системах алармов. Деякі їх наведені у табл.5.3.1.

Первым аргументом всіх вбудованих функцій алармов є ObjectName (ім'я об'єкта алармов). Часто як один з аргументів виступає Comment (коментар). Наприклад, функція almAckSelect має наступний синтаксис: almAckDisplay (ObjectName, Comment); .

Функції, назва яких починається з HT, задіяні лише з архівними трендами. Приклади таких вбудованих функцій — в табл.5.3.2.

Встроенные функції до роботи з архівними трендами також може мати кілька аргументів (чотирьох). Функції, наведені у табл. 5.3.2, мають наступний синтаксис:

— HTGetPenName (Hist_Tag, UpdateCount, PenNum);

— HTGetValue (Hist_Tag, UpdateCount, PenNum, ValType_Text);

— HTScrollLeft (Hist_Tag, Percent);

— HTSetPenName (Hist_Tag, PenNum, Tagname);

— HTZoomIn (Hist_Tag, LockString). Перший аргумент всіх вбудованих функцій до роботи з трендами — Hist_Tag (ім'я тренду). Серед інших аргументів треба сказати PenNum (номер пера тренду), ValType_Text (рядок, яка вказує тип возвращаемого значення), Tagname (ім'я пера).

Функції, назва яких починається з wc (табл.5.3.3), використовуються з управляючими об'єктами вікна (прості списки, текстові вікна, спадаючі списки тощо. д.).

Функции цієї підгрупи також може мати чотирьох аргументов:

— wcDeleteItem («ControlName », ItemIndex);

— wcInsertItem («ControlName », ItemIndex, «MessageTag »);

— wcLoadText («ControlName », «Filrename »);. Перший аргумент всіх вбудованих функцій цієї підгрупи — ControlName (ім'я керованого вікна). Часто як аргумент використовуються ItemIndex (номер, відповідний позиції елемента), MessageTag (строковое повідомлення), Filrename (ім'я файла в форматі ASCII).

В аналізованої групі функцій Miscellaneous треба сказати функцію PrintWindow, i? aaiacia?aiioю до друку вікна. Її синтаксис виглядає наступним образом:

PrintWindow («Window », Left, Top, Width, Height, Options);, где:

— Window — ім'я окна;

— Left — число дюймів від лівого края;

— Top — число дюймів від верхнього края;

— Width — ширина распечатываемого окна;

— Height — висота распечатываемого окна;

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

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

Функции Quick Functions.

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

Наиболее ці функції використав висловлюваннях щодо динамічних властивостей об'єктів. Чим це викликано? Річ у тім, що довжина висловлювання на полі Expression діалогів визначення динамічних властивостей об'єктів мусить бути трохи більше 256 символів. Це стосується й таким динамічним властивостями, як колір лінії, колір заповнення, зміна висоти і ширини, вертикальне і горизонтальне переміщення, вертикальне і горизонтальне заповнення, видимість, мерехтіння, орієнтація, блокировка.

Для введення більш довгих висловів можна скористатися функціями Quick Functions. У цьому вираження у полі Expression повинна утримувати оператори CALL виклику функцій Quick Functions, кожна з яких, своєю чергою, повинен мати як останнього оператора RETURN для повернення результату в що викликає вираз. Організоване в такий спосіб вираз може утримувати багато тисяч символів і «бути як завгодно сложным.

Сохраненная функція Quick Functions можна використовувати будь-якому іншому скрипте чи выражении.

Quick Functions може бути синхронними і асинхронними скриптами. Синхронні скрипти виконуються послідовно, тоді, як після запуску одного асинхронного скрипта то, можливо запущено інший (синхронний чи асинхронний) скрипт. Це дозволяє відокремлювати виконуються тривалий час операції (типу інтерпретацій баз даних) основної програми. Асинхронні скрипти не можуть повертати результати. Тож у ролі скриптов Quick Functions, які у висловлюваннях (Expression) визначення динамічних властивостей об'єктів, слід застосувати синхронні скрипты.

Создание скриптов Quick Functions ввозяться діалоговому вікні редактора Quick Functions. Виклик цього діалогу на екран з вікна WindowMaker виробляється у командою Special/Scripts з наступним натисканням на рядку Quick Functions.

Список Name містить імена всіх певних на цей час скриптов Quick Functions. Щигля під назвою скрипта виводить його текст у робочий полі діалогу. Команда Scripts/New варта створення нової скрипта і на екран діалог для введення його від імені. Після щиглика по Ok ім'я буде включено до списку імен Name. Наступний етап — визначення аргументів нового скрипта в таблиці Arguments діалогу Quick Function. У ліву колонку таблиці вводять ім'я аргументу (до 31 символу), в праву — його тип (Integer, Real, Discrete, Message). У першому скрипте допускається до 16 аргументів. Після визначення типів аргументів можна братися до написання тексту скрипта Quick Function у робочому полі (під таблицею Arguments).

Розробка графопостроителя у системі InTouch.

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

Разработка DDE-сервера Приложение, одержавши дані з іншого докладання по DDE і/або котра управляє іншим додатком з допомогою команд через DDE є DDEклієнтом. І тут друге додаток є DDE-сервером. Розглянемо проект DDE-сервера, виконаного мовою програмування Borland Delphi 6. На рис. 20 представлено вікно DDE-сервера під час дизайну серед Delphi.

[pic].

Рис. 20. Вікно DDE-сервера на стадії проектування в Delphi.

Для побудові DDE-сервера в Delphi є об'єкта, розташовані на сторінці System Палітри Компонент — TDdeServerConv і TDdeServerItem. Зазвичай у проекті використовується об'єкта TDdeServerConv і тільки або як TDdeServerItem. Для отримання доступу до сервісу DDE-сервера, клієнту знадобиться знати кілька параметрів: ім'я сервісу (Service Name) — це ім'я докладання (зазвичай — ім'я виконуваного файла без розширення EXE, можливе з повним шляхом); Topic Name — в Delphi це компоненти TDdeServerConv; Item Name — в Delphi це потрібної компоненти TDdeServerItem. Призначення об'єкта TDdeServerConv — загальне управління DDE і обробка запитів від клієнтів виконання макросу. Об'єкт TDdeServerItem пов’язують із TDdeServerConv яких і визначає, що, власне, буде пересилатися по DDE. І тому він має властивості Text і Lines. (Text має саме значення, як і Lines[0].) При зміні значення цих властивостей автоматично відбувається пересилання оновлених даних в усі приложения-клиенты, котрі встановили зв’язку з сервером. Після запуску докладання відбувається виконання процедури TDDEServe. FormActivate:

procedure TDDEServe. FormActivate (Sender: TObject); var nidata: TNotifyIconData; begin.

Application.ShowMainForm := False;

ShowWindow (Application.Handle, SW_HIDE);

ShowWindow (Application.MainForm.Handle, SW_HIDE); with nidata do begin cbSize := SizeOf (TNotifyIconData);

Wnd := Self. Handle; uID := 1; uFlags := NIF_ICON or NIF_MESSAGE or NIF_TIP; uCallBackMessage := WM_MYICONNOTIFY; hIcon := Application.Icon.Handle;

StrPCopy (szTip, Application. Title); end;

Shell_NotifyIcon (NIM_ADD, @nidata); ru:=10; end;

В цій процедурі додаток звертається в системний Tray, а форма стає невидимою. Закінчення роботи DDE-сервера викликається шляхом натискання лівої чи правої кнопкою миші на іконці докладання у сфері системного Tray. Обробка цієї події виконується у процедурі TDDEServe. WMICON:

procedure TDDEServe. WMICON (var msg: TMessage); begin case msg. LParam of.

WM_RBUTTONDOWN, WM_LBUTTONDOWN: close; end; end;

При цьому, при закритті вікна докладання викликається процедура TDDEServe. FormDestroy, у якій відбувається видалення іконки з системного Tray:

procedure TDDEServe. FormDestroy (Sender: TObject); var nidata: TNotifyIconData; begin with nidata do begin cbSize := SizeOf (TNotifyIconData);

Wnd := Self. Handle; uID := 1; end;

Shell_NotifyIcon (NIM_DELETE, @nidata); end;

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

implementation.

{$R *.DFM} uses ComObj, activex, ShellApi, shlobj, registry; var xsin: integer; ru: real; boolka: boolean;

procedure TDDEServe. Timer1Timer (Sender: TObject); var LPTbyte: byte; begin xsin:=xsin+1; if xsin>1000 then xsin:=xsin-1000;

DDEItem100.Text:=inttostr (5*(xsin-20*trunc (xsin/20)));

//пилкоподібний сигнал asm mov dx, 379h in al, dx and al, 80h mov LPTbyte, al end;

DDEItem200.Text:=inttostr (LPTbyte*100); //стан лінії LPT-порта.

DDEItem300.Text:=inttostr (round (50+50*sin (xsin/20))); if (xsin/5)=trunc (xsin/5) then if (ru.

Показати весь текст

Заповнити форму поточною роботою