«У нас уже є SCADA, навіщо нам АСКОЕ?» і «АСКОЕ ж показує споживання, нащо окрема диспетчеризація?» — два найчастіші питання на передпроєктних обстеженнях. Обидві системи працюють з одними й тими самими фізичними величинами, але роблять це принципово по-різному. Ключова відмінність не в протоколах і не в інтерфейсах, а в тому, хто і коли ставить мітку часу на дані. Розбираємо різницю на рівні архітектури і показуємо єдиний коректний спосіб поєднання двох систем.
Дві філософії роботи з даними
Облік: лічильник сам веде базу даних
Сучасний лічильник комерційного обліку — це метрологічний прилад з власним годинником і власною пам’яттю. Він самостійно, без жодної участі верхнього рівня, формує архіви: профіль навантаження з інтервалом 15, 30 або 60 хвилин, добові зрізи, журнали подій. Кожен запис отримує мітку часу в момент вимірювання, від годинника лічильника. У типовому смарт-лічильнику за DLMS/COSEM таких об’єктів даних понад 500: профілі, тарифні регістри, календарі, журнали.
АСКОЕ у цій схемі нічого не «вимірює у реальному часі». Вона вичитує вже готову базу даних з лічильника: раз на годину, раз на добу або за запитом. Звідси головна властивість обліку: зник зв’язок на три доби — нічого не втрачено. Система дочитає архів з пам’яті лічильника, і кожен інтервал стане на своє місце з оригінальною міткою часу. Повнота даних не залежить від якості каналу.
Диспетчеризація: сервер питає «що зараз?»
SCADA працює дзеркально. Вона циклічно опитує пристрої (типовий цикл 1-5 секунд) і отримує поточні значення: температуру подачі, тиск, стан насоса, миттєву потужність. Мітку часу цим значенням присвоює SCADA-сервер у момент запису в свою БД, а не пристрій у момент вимірювання. Для оперативного керування цього достатньо: диспетчеру важливо, що відбувається зараз, з точністю до секунд.
Але у цієї моделі є зворотний бік. Якщо зв’язок зник на годину, ця година в трендах SCADA — діра назавжди: поточні значення ніде не збереглись і дочитати їх нема звідки. А мітка часу включає латентність каналу і чергу опитування, тому для комерційних розрахунків такі дані непридатні у принципі.
Порівняння для інженера
| Критерій | Облік (АСКОЕ) | Диспетчеризація (SCADA) |
|---|---|---|
| Задача | скільки спожито за інтервал | що відбувається зараз |
| Тип даних | інтегральні: кВт·год, Гкал, м³ за 15-60 хв | миттєві: кВт, °C, бар, стани |
| Хто ставить мітку часу | лічильник у момент вимірювання | сервер при записі в БД |
| Втрата зв’язку | дані дочитуються з архіву лічильника | дані втрачені безповоротно |
| Типові протоколи | DLMS/COSEM (IEC 62056), M-Bus | IEC 60870-5-104, Modbus, OPC UA |
| Цикл | інтервал профілю 15-60 хв, зчитування 1-24 рази/добу | полінг 1-5 с |
| Метрологія | клас 0,5S/0,2S, повірка, пломби | вимог немає, датчики класу 1-2% |
| Юридична сила | розрахунки на ринку, Datahub АКО за ККОЕЕ | технологічна інформація |
З таблиці видно, чому «замінити АСКОЕ SCADA-системою» неможливо: у SCADA-даних немає ні метрологічної, ні юридичної сили, а головне — немає гарантії повноти ряду. І навпаки: АСКОЕ з її годинним циклом зчитування не побачить, що насос зупинився 40 секунд тому.
Як поєднувати: тільки через базу даних, тільки в один бік
Правильна інтеграція виглядає так: кожна система збирає дані своїм шляхом, а обмін відбувається на рівні баз даних. SCADA читає з БД обліку готові верифіковані архіви (через SQL-view, API або OPC-шлюз) і показує їх диспетчеру поруч з оперативними трендами: фактичне споживання по годинах поверх миттєвих параметрів.
Що це дає на практиці:
- Диспетчер бачить баланс, а не тільки стани. Поточний тиск у нормі, а погодинне споживання води на 18% вище за аналогічну добу — витік, який SCADA сама по собі не помітила б.
- Верифікація датчиків. Розбіжність між інтегралом миттєвої потужності зі SCADA і профілем лічильника понад 2-3% — сигнал про проблему вимірювального кола.
- Один екран для двох систем. Оператору не потрібно тримати окремий кабінет обліку: архівні дані приходять у звичні мнемосхеми і тренди.
Чому не навпаки? Записувати дані зі SCADA у систему обліку не можна: мітка часу від сервера, датчики без повірки, ряди з дірами. Такі дані не приймуть ні АКО, ні аудитор, а «підмішування» їх до комерційних архівів руйнує довіру до всієї БД обліку. Потік завжди один: з обліку в диспетчеризацію, ніколи навпаки.
Чому не на рівні протоколу? Спокуса «нехай SCADA сама читає лічильники по DLMS» закінчується однаково: два майстри на одній шині RS-485 ламають сеанси один одному, канал GSM не витримує подвійного трафіку, а SCADA-драйвер DLMS все одно не вміє коректно дочитувати архіви за пропущені періоди. Лічильник має одного господаря — систему обліку. Всі інші споживачі даних працюють з її БД.
Будуємо обидва контури і їхнє поєднання
Хмарний облік ASKUE.net™ (реєстр АКО, ID 1540) + диспетчеризація на scada.askue.net з інтеграцією на рівні БД: диспетчер бачить архіви обліку у своїх трендах. Так працює, наприклад, ОСББ Портова 12: SCADA-контроль ІТП плюс комерційний облік тепла в одному інтерфейсі.
АСКОЕ під ключ · Послуги ППКО · Диспетчеризація та обслуговування ІТП
Розрахунок безкоштовно. Зателефонуйте +38 (050) 228-228-0. Інженер відповість за 5 хвилин.
Типові помилки проєктування
- «Куплю контролер з обліком і SCADA в одному». Поки прилад не внесений у реєстр ЗВТ і не має статусу засобу комерційного обліку, його «облік» — це технічний підрахунок без юридичної сили.
- Аналітика споживання на SCADA-трендах. Інтеграл миттєвих значень з дірами дає похибку 5-15% проти профілю лічильника. Балансові звіти на таких даних — джерело хибних висновків.
- Дві незалежні бази без обміну. Підприємство платить за обидві системи, але диспетчер не бачить споживання, а енергетик не бачить подій. Інтеграційний шар на рівні БД коштує 3-5% бюджету систем і повертає більшу частину їхньої цінності.
- Спроба «дотягнути» цикл АСКОЕ до реального часу. Зчитування лічильників щохвилини вбиває канал і батареї модемів, а секундної оперативності все одно не дає. Для оперативності є SCADA.
Часті питання
Чи може SCADA показувати дані комерційного обліку в реальному часі?
Майже: з затримкою на інтервал профілю і цикл зчитування. Для годинного профілю і щогодинного опитування дані у SCADA з’являються з лагом до 2 годин. Для оперативніших задач поруч виводяться миттєві значення з датчиків.
У лічильника є імпульсний вихід. Можна завести його прямо у SCADA?
Можна, і для технічного контролю це робочий варіант. Але лічити комерційні об’єми за імпульсами не можна: без синхронізації з тарифним календарем і архівом лічильника розбіжності неминучі, а юридичної сили імпульсний підрахунок не має.
Одна БД для обліку і SCADA — це можливо?
Фізично так: сучасні платформи тримають обидва типи даних в одній СУБД (окремі схеми для комерційних архівів і оперативних трендів). Головне не змішувати таблиці: комерційні дані незмінні після верифікації, оперативні — потоковий журнал.
З чого почати, якщо немає жодної системи?
З обліку: він обов’язковий за Кодексом комерційного обліку і дає економічний ефект одразу. Диспетчеризація додається другим кроком на ту саму інфраструктуру зв’язку, і поєднання закладається в проєкт з першого дня.
Висновки
Облік і диспетчеризація відповідають на різні питання: «скільки спожито» проти «що відбувається зараз». Лічильник ставить мітку часу сам і гарантує повноту архіву, SCADA дає секундну оперативність без метрології. Поєднання коректне лише одне: SCADA читає архівні дані з БД обліку. Проєктуйте обидва контури одразу з інтеграційним шаром — це 3-5% бюджету і подвійна віддача від кожної системи.
Потрібна схема поєднання під ваш об’єкт? Зателефонуйте 050 228 228 0.
Читайте також:
