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

І. Е. Аблін

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

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

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

Вирішення проблем - комплексний підхід

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

Чи може цей підхід вважатися універсальним з точки зору використовуваного устаткування? Адже вимоги з боку конкретних об'єктів досить сильно розрізняються: необхідні різні типи і кількість каналів вводу-виводу, різні комунікаційні можливості, різне конструктивне і кліматичне виконання. Відповідь на поставлене запитання, тим не менше, позитивний, оскільки контролерних виконавча система MasterPLC зі складу MasterSCADA сумісна практично з будь-якими контролерами з відкритою архітектурою. Такими можуть вважатися контролери, які мають можливість завантаження виконуваних програм, створених на універсальних мовах програмування: C, C + + і т.д. А це означає можливість використання нескінченного розмаїття моделей безлічі виробників на базі процесорів з різною архітектурою (x86, ARM7, ARM9, StrongARM, xScale) і різними ОС (DOS, Linux, Windows CE та ін.) Підтримується список з декількох десятків моделей зарубіжних і російських виробників (Adam, ICP-DAS, Moxa, Teconic, Owen і тощо), при цьому портування системи MasterPLC на нову модель зазвичай займає лічені дні. Згадане вимога (виконання на контролері програми, написаної на мовах типу C або C + +) ставиться, зрозуміло, не до способу написання прикладної програми користувача, що звичайно створюється на технологічних мовах стандарту МЕК-61131-3 (як правило, FBD), а до можливості роботи на процесорі контролера універсальної переносимої виконавчої системи MasterPLC, що реалізує всі системні функції контролера. Залишивши осторонь базові з них, такі як опитування модулів вводу-виводу, підтримка протоколу зв'язку з верхнім рівнем, виконання технологічної програми, розглянемо додаткові можливості, забезпечують придатність і зручність застосування контролера в системах диспетчеризації.

Можливості MasterPLC-контролерів для систем диспетчеризації

Основні вимоги до контролера в системах диспетчеризації - комунікаційні. MasterPLC відповідає практично всім відомим вимогам: забезпечення зв'язку з верхнім рівнем (Master-SCADA або OPC-сервером) по каналу RS232/RS485, Ethernet, GSM, SMS, радіо, телефону; резервування основного каналу зв'язку з верхнім рівнем за допомогою каналу того самого або іншого типу; підтримка Modbus (Master/Slave) для підключення зовнішніх пристроїв, модулів введення-виведення сигналів, операторських панелей; підтримка протоколу DCON (модулі Adam, ICPDAS, Teconic, Owen тощо); наявність універсального конфігуровані драйвера для обміну даними з зовнішніми інтелектуальними пристроями без програмування; можливість межконтроллерной зв'язку з іншими MasterPLC-контролерами (незалежно від типу їх моделі); наявність набору драйверів для ряду популярних контролерів (Danfoss ECL) і модулів вводу-виводу сигналів; відкритий інтерфейс для програмного розробки драйверів; можливість ініціативної передачі інформації на верхній рівень (при використанні модемного зв'язку або GSM дозвон по заданому списку номерів); передача повідомлень і даних за допомогою SMS.

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

Тиражування однотипних об'єктів в проект

Особливість більшості диспетчерських систем полягає в тому, що при великому або навіть дуже великій кількості контрольованих об'єктів (таких як ЦТП, ІТП, ГРП, РП, ВНС, КНС та ін) багато хто з них є однотипними або майже однотипними. Це дає можливість істотно спростити розробку проектів. Як правило, SCADA-системи дозволяють при проектуванні тиражувати динамічні символи об'єктів, описи каналів введення-виведення сигналів, мнемосхеми та інші документи. Недолік такого (найбільш поширеного) підходу полягає в тому, що для роботи з ще одним об'єктом, подібному до попереднього, доведеться виконати ряд рутинних операцій з копіювання і прив'язці до джерел сигналів кожного що відноситься до об'єкту елементи: окремо мнемосхеми, окремо списку повідомлень і т.п.

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

Масштабованість системи

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

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

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

З одного боку, вимоги до опитування тут простіше, ніж в системах диспетчеризації, що дозволяє проводити прямий опитування лічильників з диспетчерської без використання будь-яких проміжних пристроїв. З іншого боку, на практиці така ситуація зустрічається все рідше. Поєднання облікових і диспетчерських функцій, необхідність поділу між ними каналу зв'язку, потреба в опитуванні декількох типів комерційних обчислювачів, розташованих на одному майданчику, навпаки, породжують нові проблеми, при вирішенні яких не можна обійтися без пристроїв збору і передачі даних (УЗПД). Будь-який MasterPLC-контролер з успіхом може бути використаний в цій якості. Основні можливості MasterPLC, що позиціонують його як базовий ПЗ для УЗПД: архівування в контролері в одному темпі з циклом програми користувача; включення в єдиний репозиторій архівів підключених зовнішніх пристроїв (лічильників і т.п.); передача архівів кількох серверів вводу-виводу верхнього рівня; автоматична синхронізація часу в системі (при використанні з MasterSCADA); набір драйверів для ряду популярних комерційних обчислювачів ( "Логіка"), електролічильників ( "Меркурій-230"), лічильників імпульсів ( "Пульсар") та ін; прозорий канал зв'язку з порту на порт.

Розширення функцій SCADA для систем обліку ресурсів

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

Вбудований в MasterSCADA потужний генератор звітів комплектується бібліотеками шаблонів готових звітів по споживанню електроенергії та тепла, що дозволяє без додаткових зусиль на розробку атестувати створювану систему в якості комерційної (АСКОЕ). Для передачі інформації про споживання електроенергії в енергозбутової організацію MasterSCADA формує XML-файл встановленого зразка.

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

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

Наявність у будівлях і на промислових підприємствах можливостей для побудови мереж на базі Ethernet дозволяє різко знизити вимоги до підсистеми опитування, а також надає вибір між прямим опитуванням периферійних пристроїв (лічильників і модулів вводу-виводу сигналів, що підключаються через конвертори RS232/485 в Ethernet) та їх опитуванням через проміжний контролер. Однак при побудові великих систем потреба в такому контролері зберігається, як з метою зниження навантаження на мережа (за рахунок проміжної консолідації даних та використання більш ефективного протоколу UDP замість TCP), так і з метою спрощення конфігурування, розгортання та розвитку системи з використанням типових комплектів розширення. Розвиток IP-мереж в містах поступово зближує завдання диспетчеризації та обліку в ЖКГ з рішенням тих самих задач у промисловості.

Досвід впровадження

Система MasterSCADA впроваджена практично у всіх типах розглянутих систем: в інженерних мережах міст і територій (в водоканалах, теплових, газових і електричних мережах), у системах автоматизації торгових і бізнес-центрів, житлових будинків, мікрорайонів і котеджних селищ, у системах комплексного комерційного і технічного обліку великих промислових підприємств. Накопичений виробником цього продукту - компанією "ІнСАТ" досвід дозволяє рекомендувати ряд типових апробованих структур систем, що підбираються на основі короткого опису постановки задачі.

І. Е. Аблін, генеральний директор, компанія "ІнСАТ"

Список літератури

Раціональне Управління Підприємством № 6 2008