Лічильники електроенергії
АТС, технічна частина
Будемо сподіватися на те, що наші вчені мужі досконально продумали економічну модель оптового ринку, але в кінці кінців ринок розвивається, і ніхто не забороняв корекцію, час ще є. Набагато менше часу з доопрацювання технічної моделі АТС. тому системи обліку акредитуються і встановлюються вже зараз.
У моделі збору та передачі комерційних даних АТС є ряд недоробок. Схоже, концепція формувалася за схемою маленького заводу з 10 лічильниками, одним споживачем і одним постачальником. У цих умовах все досить гладко лягає і в практичній реалізації. Однак, якщо взяти реальну картину вагомої частини Західного Сибіру, де на підстанціях одного постачальника існують точки обліку різних споживачів, і ці точки перетинаються, стане ясно, що дана модель можна реалізувати з досить великими труднощами і, головне, - втратами і ризиком для споживачів комерційної інформації . Втрати - матеріальні, тому що існуючі та благополучно функціонують системи АСКОЕ споживача доведеться знімати. Тим, хто хоче вступити в ОРЕ. - через невідповідність цих систем вимогам АТС, тим хто не хоче - через монополізацію АТС точок обліку. АТС забороняє доступ до цифрових інтерфейсів лічильника сусідніх систем АСКОЕ та пропонує отримання даних з верхнього рівня, - тобто знову споживач, який не хоче вступати в ОРЕ, несе матеріальні витрати на реалізацію механізму скачування даних по верхньому рівню. Ризик в тому, що споживач, раніше отримував дані з однієї системи, тепер буде намагатися склеїти їх з різних систем - наприклад, 5 лічильників своєї системи АСКОЕ, 10- від першого сусіда, який набрав ОРЕ і забрав інтерфейсні виходи, 20- від другого сусіда, який набрав ОРЕ і забрав свої інтерфейсні виходи. Незрозуміло ще й те, як вони регламентують це взаємодія на верхньому рівні: все може впертися і в канали зв'язку, і в політики безпеки підприємств, і просто в 'не хочу'. При виході з ладу хоча б однієї системи, страждати будуть всі, які отримують від неї інформацію. При такій «каші» я б серйозно розглядав пропозицію підключити страхові компанії на етапі укладання договорів.
Зрозуміле бажання АТС убезпечити первинне джерело інформації-лічильник від несанкціонованого доступу, але навіщо такими методами?
Чому у нас завжди - зруйнувати все дощенту, а потім. Адже є ряд технічних рішень для забезпечення ужіваемость зі старими системами АСКОЕ, - це, наприклад, використання апаратного комутатора інтерфейсів - простого пристрою, що дозволяє працювати на одній інтерфейсної шині кільком системам і не заважати один одному. Можна його вбудовувати в УСПД споживача, який входить в ОРЕ, і надавати інтерфейсні виходи іншим системам АСКОЕ. Якщо не подобається апаратна комутація, можна застосувати програмну в тому ж УСПД. Питання безпеки, а інакше - заборони застосування команд, що призводять до зміни конфігурації лічильника, - можна вирішити на рівні паролів приладу або, по-другому варіанті, на рівні фільтрації команд в УСПД. У будь-якому випадку, є журнал подій, і обдурити тут можна один раз, потім тебе все одно зловлять. Жодного разу я не зустрічав такого випадку, щоб якасьнебудь зі сторін займалася обманом на рівні лічильника, це просто нерозумно. До речі, журналу подій в обсязі, запропонованому АТС, недостатньо, - наприклад, потрібні прапори лічильника, що дозволяють фіксувати апаратні і програмні неполадки в приладі. Світ приладів обліку постійно росте і вдосконалюється, додаються нові 'бонусні' сервіси, від яких не хочеться відмовлятися тільки тому, що це не потрібно на рівні АТС.
Не треба забувати, що будь-який новий програмно-технічний комплекс повинен пройти свій еволюційний шлях налагодження і вдосконалення, і велика частина цього шляху лежить вже після впровадження. Те, що на УСПД поставили печатку і дали документ, що дозволяє іменуватися повноцінним «чорним ящиком», - всього лише відкриті двері в світ незвіданих сюрпризів налагодження. Існування паралельних, вже працездатних систем тільки скоротить цей період і допоможе виявити і виправити неминучі помилки.
УСПД, куди його ставити
Повинен зізнатися, УСПД нам вдалося встановити на двох підстанціях (п'ятисотка, де на самій підстанції дивляться баланс, і вузлова підстанція, до якої слабкий канал зв'язку, а з неї йде опитування ще десятка підстанцій, і прямих каналів з центру немає). Намагалися на більшій кількості - не вдається. Тому що, не має сенсу. Все-таки модель АСКОЕ - радіальна, ієрархія з'являється тільки на рівні АТС.
Час і як з ним боротися
Вічне питання - питання часу, точніше того, як ми самі намагаємося себе заплутати в цей час. Здавалося б, проста річ - перехід часу і всього-то на годину, і всього-то два рази на рік, але наслідки цього відбиваються на всі системи АСКОЕ, і все борються як можуть, і все неправильно. Тому що, з точки зору будь-якої технологічної системи це взагалі неправильно, переходу просто не повинно бути. Ну не буває діб з 23 і 25 годинами, не повинно бути і місяці некратними діб (по годинах). І куди подіти дані за зайву годину? Додавати до попереднього - не вклався в максимум, округляти - сума получасовок за місяць не буде дорівнює витраті. Загалом, знову два пишемо. три в розумі, п'ять в кишені. Думаю, тут солідарні зі мною будуть не тільки розробники систем АСКОЕ, а й розробники лічильників, тому що вони теж все по-різному вирішують цю проблему, і у всіх не дуже гладко виходить, саме тому простіше відключати функцію перекладу часу в приладах обліку та емулювати перехід в клієнтських додатках, хоча і це неправильно. Різні часові пояси - теж чудова грунт для появи різного роду помилок в програмному забезпеченні, особливо на рівні АТС, куди будуть зливатися дані з досить великій території.
Правильно - ввести єдину систему часу в ФСК. за Гринвічем, без переходу. Як у космонавтів. Космонавти люди не дурні і давно не жартують з часом.
Формати первинних даних
Під первинними даними ми розуміємо те, що видає нам прилад обліку по цифровому інтерфейсу - профіль навантаження, показання енергії, діагностичні дані.
Важливо створити спадкоємність формату даних приладу обліку в базі даних АСКОЕ.
По-перше: завжди легко можна контролювати коректну працездатність системи в цілому - і на етапі метрологічної повірки, і в процесі експлуатації, адже тоді потрібно порівнювати 2 числа - з 'мізків' приладу і з таблиць бази даних. Ці числа просто повинні бути рівні.
По-друге: це дозволяє уникнути похибки в подальших обчисленнях, адже з первинними даними система дуже серйозно працює-й ділить, і примножує, - все для того. щоб отримати кінцеве число і видати його в звіт. Краще вже подбати про максимальну достовірності інформації до всіх цих розрахунків.
Всі встановлені прилади обліку видають профіль навантаження в цілому форматі, енергію - одні в матеріальному, інші теж в цілому. Значення півгодинної усередненої потужності - досить мала величина, це-кількість імпульсів, нарахованих лічильником за період інтеграції (не приведеним до години). у нас це 30 хвилин. В ідеалі, якщо ми складемо всі получасовкі місяці і помножимо на коефіцієнти (kсчётчіка * kI * kU), то отримаємо витрата за місяць. В ідеалі, тому що кожна получасовка має ще прапор помилки, і вона за певних умов може бути забракована, або бути неповною. Якщо ми на верхньому рівні системи зберігаємо профіль в первинному форматі, то цілком реально можемо домогтися рівності витрати за профілем і за показаннями енергії. В іншому випадку, коли на верхньому рівні зберігаються вже перелічені в дійсне число дані, ми такого рівності не доб'ємося, тому що очевидно, що похибка суми творів дійсних чисел вище похибки твори суми цілих.
Лічильники в тій чи іншій мірі фіксують 3 параметра, що відносяться до того, що ми називаємо енергією: це довільні показання енергії (можна вважати тільки на момент опитування), показання на початок місяця (на перше число кожного місяця 0 год 0 хв.), Витрата за місяць (різниця показань на перші числа сусідніх місяців). Є ще енергії за тарифами, енергії від початку місяця, але реально застосовуються перші три. Витрата за довільний період розраховується через профіль, так можна вирішувати питання добової тарифікації. Взагалі тарифи набагато практичніше вести на рівні бази даних, а не на рівні приладу обліку. Досить уявити собі забавну картину роз'їзду по підстанціях (особливо коли їх більше сотні) з метою перепрограмування лічильників при зміні чергового тарифу, -канали зв'язку далеко не скрізь є.
Обмін даними на верхньому рівні
В умовах, коли у одного споживача комерційної інформації вже встановлена АСКОЕ, яка задовольнить потребам інших претендентів на ці дані, цілком розумно не будувати паралельну систему, а користуватися даними існуючої.