WWW.NVTO.RU



Навигация






карта работы АСКУЭ MetCon









Печать E-mail

Автор: admin1   
Дата публикации:  12.10.2017 г.
Источник: WWW.NVTO.RU

Вопросы создания и эксплуатации АСКУЭ в современных условиях

Счётчики электроэнергии

     В 1999 году я написал небольшую интернет-статью – обзор основных цифровых счётчиков электроэнергии, применяемых в российской энергетике. Статья выражала моё субъективное мнение как разработчика программного обеспечения взаимодействия со счётчиками. Тогда системы АСКУЭ, работающие с цифровыми счётчиками, можно было пересчитать по пальцам одной руки, да и сами приборы учёта с ‘мозгами’ компьютера выглядели весьма диковинно. Сейчас, что радует, АСКУЭ не занимается только ленивый. Счётчиком, который сам считает импульсы, сам запоминает график нагрузки, сейчас никого не удивишь. Но развитие есть – счётчики научились фиксировать качество электроэнергии, формируя при этом таблицы выходов и возвратов за установленные границы; научились работать на высоких скоростях, да ещё по двум независимым интерфейсам, что позволяет строить 2 полноценные системы АСКУЭ на одних и тех же приборах учёта; хранят теперь не 4 массива профиля нагрузки (активные отдача\приём, реактивные отдача\приём), а 8, что позволяет, к примеру, наряду с коммерческим 30-минутным профилем вести технический 3-х минутный. Появляются и экстравагантные решения- тупиковые, на мой взгляд, – счётчик с массивом профиля в вещественных величинах, или счётчик, пытающийся фиксировать данные уже с учётом потерь.

АТС, техническая часть

     Будем надеяться на то, что наши учёные мужи досконально продумали экономическую модель оптового рынка, но в конце концов рынок развивается, и никто не запрещал коррекцию, время ещё есть. Гораздо меньше времени по доработке технической модели АТС , т.к. системы учёта аккредитируются и устанавливаются уже сейчас.

    В модели сбора и передачи коммерческих данных АТС есть ряд недоработок. Похоже, концепция формировалась по схеме маленького завода с 10 счётчиками, одним потребителем и одним поставщиком. В этих условиях всё достаточно гладко ложится и в практической реализации. Однако, если взять реальную картину весомой части Западной Сибири, где на подстанциях одного поставщика существуют точки учёта разных потребителей, и эти точки пересекаются, станет ясно, что данная модель реализуема с достаточно большими трудностями и, главное, – потерями и риском для потребителей коммерческой информации. Потери - материальные, т.к. существующие и благополучно функционирующие системы АСКУЭ потребителю придётся снимать. Тем, кто хочет вступить в ОРЭ, – по причине несоответствия этих систем требованиям АТС, тем кто не хочет – по причине монополизации АТС точек учёта. АТС запрещает доступ к цифровым интерфейсам счётчика соседствующих систем АСКУЭ и предлагает получение данных с верхнего уровня ,– т.е. опять потребитель, не желающий вступать в ОРЭ, несёт материальные затраты на реализацию механизма скачивания данных по верхнему уровню. Риск в том, что потребитель, ранее получавший данные из одной системы, теперь будет пытаться склеить их из разных систем – к примеру, 5 счётчиков своей системы АСКУЭ, 10- от первого соседа, вступившего в ОРЭ и забравшего интерфейсные выходы, 20- от второго соседа, вступившего в ОРЭ и забравшего свои интерфейсные выходы. Непонятно ещё и то, как они регламентируют это взаимодействие на верхнем уровне: всё может упереться и в каналы связи, и в политики безопасности предприятий, и просто в ‘не хочу’. При выходе из строя хотя бы одной системы, страдать будут все, получающие от неё информацию. При такой «каше» я бы серьёзно рассматривал предложение подключить страховые компании на этапе заключения договоров.

    Понятно желание АТС обезопасить первичный источник информации–счётчик от несанкционированного доступа, но зачем такими методами ?
    Почему у нас всегда – разрушить всё до основания, а затем ... ? Ведь есть ряд технических решений для обеспечения уживаемости со старыми системами АСКУЭ, – это, к примеру, использование аппаратного коммутатора интерфейсов – простого устройства, позволяющего работать на одной интерфейсной шине нескольким системам и не мешать друг другу. Можно его встраивать в УСПД потребителя, вступающего в ОРЭ, и предоставлять интерфейсные выходы остальным системам АСКУЭ. Если не нравится аппаратная коммутация, можно применить программную в том же УСПД. Вопрос безопасности, а иначе - запрета применения команд, приводящих к изменению конфигурации счётчика, – можно решить на уровне паролей прибора или, во-втором варианте, на уровне фильтрации команд в УСПД. В любом случае, есть журнал событий, и обмануть тут можно один раз, потом тебя всё равно поймают. Ни разу я не встречал такого случая, чтобы какая- нибудь из сторон занималась обманом на уровне счётчика, это просто глупо. Кстати, журнала событий в объёме, предлагаемом АТС, недостаточно, – к примеру, нужны флаги счётчика, позволяющие фиксировать аппаратные и программные неполадки в приборе. Мир приборов учёта постоянно растёт и совершенствуется, добавляются новые ‘бонусные’ сервисы, от которых не хочется отказываться только потому, что это не нужно на уровне АТС.
    Не надо забывать, что любой новый программно-технический комплекс должен пройти свой эволюционный путь отладки и совершенствования, и большая часть этого пути лежит уже после внедрения. То, что на УСПД поставили печать и дали документ, позволяющий именоваться полноценным «чёрным ящиком», – всего лишь открытая дверь в мир неизведанных сюрпризов отладки. Существование параллельных, уже работоспособных систем только сократит этот период и поможет выявить и исправить неизбежные ошибки.

УСПД, куда его ставить

 Должен признаться, УСПД нам удалось установить на двух подстанциях (пятисотка, где на самой подстанции смотрят баланс, и узловая подстанция, до которой слабый канал связи, а с неё идёт опрос ещё десятка подстанций, и прямых каналов с центра нет). Пытались на большем количестве – не удаётся. Потому что, не имеет смысла. Всё-таки модель АСКУЭ – радиальная, иерархия появляется только на уровне АТС.

    С развитием аппаратуры связи и появлением таких цифровых технологий как радиоизернет, сотовая связь, спутниковые модемы, всё у большего числа разработчиков и пользователей систем АСКУЭ возникает вопрос: а зачем нужно ставить УСПД на уровень подстанции, зачем фактически дублировать функции счётчиков, объединяя их в одном устройстве? Применение УСПД на уровне подстанции оправдано там, где нужна коммерческая информация, – например, для построения баланса подстанции, при условии, что нет постоянного канала связи с центральным сервером. Оправдано применение УСПД на подстанциях со специфическими каналами связи,- к примеру, со спутниковым модемом, где применяется витиеватая система тарификации. На подстанциях с радио-, телефонными, ВЧ, сотовыми каналами связи такое устройство выглядит неуместно. В большинстве своём УСПД уровня подстанции – атавизм, доставшийся нам от сумматоров импульсных счётчиков и неудачных попыток скрестить телемеханику с АСКУЭ. В идеале нужно признавать сервер верхнего уровня + хост машину опроса- полноценным и самодостаточным программно-аппаратным средством сбора и накопления данных, проводить его метрологическую поверку, а все оставшиеся силы и средства употребить на создание нормальных современных каналов связи. К тому же, эти средства сторицей окупятся, к примеру, тот же радиоизернет позволит сделать до подстанции локальную сеть, IP-телефонию, передавать телеинформацию, данные по аварийным осциллографам и т.п.
    Надо стремиться к УСПД уровня предприятия, а на подстанциях ставить современные цифровые приборы учёта.

Время и как с ним бороться

Вечный вопрос – вопрос времени, точнее того, как мы сами пытаемся себя запутать в этом времени. Казалось бы, простая вещь – переход времени и всего- то на час, и всего- то два раза в год, но последствия этого отражаются на все системы АСКУЭ, и все борются как могут, и все неправильно. Потому что, с точки зрения любой технологической системы это вообще неправильно, перехода просто не должно быть. Ну не бывает суток с 23 и 25 часами, не должно быть и месяца некратного суткам (по часам). И куда девать данные за лишний час? Прибавлять к предыдущему – не уложимся в максимум, округлять – сумма получасовок за месяц не будет равна расходу. В общем, опять два пишем , три в уме, пять в кармане. Думаю, тут солидарны со мной будут не только разработчики систем АСКУЭ, но и разработчики счётчиков, т.к. они тоже  все по-разному решают эту проблему, и у всех не очень гладко выходит, именно поэтому проще отключать функцию перевода времени в приборах учёта и эмулировать переход в клиентских приложениях, хотя и это неправильно. Разные часовые пояса – тоже замечательная почва для появления различного рода ошибок в программном обеспечении, особенно на уровне АТС, куда будут сливаться данные с весьма обширной территории.
    Правильно – ввести единую систему времени в ФСК, по Гринвичу, без перехода. Как у космонавтов. Космонавты люди не глупые и давно не шутят со временем.

Форматы первичных данных

                                Под первичными данными мы понимаем то, что выдаёт нам прибор учёта по цифровому интерфейсу - профиль нагрузки, показания энергии, диагностические данные.
    Важно создать преемственность формата данных прибора учёта в базе данных АСКУЭ.
    Во-первых: всегда легко можно контролировать корректную работоспособность системы в целом - и на этапе метрологической поверки, и в процессе эксплуатации, ведь тогда нужно сравнивать 2 числа – из ‘мозгов’ прибора и из таблиц базы данных. Эти числа просто должны быть равны.
    Во-вторых: это позволяет избежать погрешности в дальнейших вычислениях, ведь с первичными данными система очень серьёзно работает- и делит, и умножает, - всё для того , чтобы получить конечное число и выдать его в отчёт. Лучше уж позаботиться о максимальной достоверности информации до всех этих расчётов.
Все установленные приборы учёта выдают профиль нагрузки в целом формате, энергию – одни в вещественном, другие тоже в целом. Значение получасовой усреднённой мощности – достаточно малая величина, это- количество импульсов, насчитанных счётчиком за период интеграции (не приведённых к часу) , у нас это 30 минут. В идеале, если мы сложим все получасовки месяца и умножим на коэффициенты (kсчётчика*kI*kU), то получим расход за месяц. В идеале, потому что каждая получасовка имеет ещё флаг ошибки, и она при определённых условиях может быть забракована, или быть неполной. Если мы на верхнем уровне системы храним профиль в первичном формате, то вполне реально можем добиться равенства расхода по профилю и по показаниям энергии. В противном случае, когда на верхнем уровне хранятся уже пересчитанные в вещественное число данные, мы такого равенства не добьемся, т.к. очевидно, что погрешность суммы произведений вещественных чисел выше погрешности произведения суммы целых.
    Счётчики в той или иной мере фиксируют 3 параметра, относящихся к тому, что мы называем энергией: это произвольные показания энергии ( можно считать только на момент опроса), показания на начало месяца ( на первое число каждого месяца 0 час 0 мин.), расход за месяц ( разность показаний на первые числа соседних месяцев). Есть ещё энергии по тарифам, энергии от начала месяца, но реально применяются первые три. Расход за произвольный период рассчитывается через профиль, так можно решать вопросы суточной тарификации. Вообще тарифы гораздо практичней вести на уровне базы данных, а не на уровне прибора учёта.     Достаточно вообразить себе забавную картину разъезда по подстанциям (особенно когда их больше сотни) в целях перепрограммирования счётчиков при изменении очередного тарифа, -каналы связи далеко не везде есть.

Обмен данными на верхнем уровне

                                В условиях, когда у одного потребителя коммерческой информации уже установлена АСКУЭ, удовлетворяющая потребностям остальных претендентов на эти данные, вполне разумно не строить параллельную систему, а пользоваться данными существующей.

    Обмен данными на верхнем уровне фактически является репликацией между серверами АСКУЭ, т.к. всё равно первичная информация в итоге попадает на SQL-сервер. Подавляющее большинство АСКУЭ работает с реляционными СУБД MS SQL или Oracle. При этом появляется ещё один очевидный плюс в пользу хранения данных в первичном формате – ликвидация погрешности при передаче данных и удобство при взаимодействии систем, т.к. этот формат должны знать все системы, ведь все они умеют самостоятельно опрашивать счётчики. Важно передавать и флаги, характеризующие достоверность каждого значения профиля нагрузки.
    Для обмена достаточно трёх таблиц первичных данных (профиль, энергия, диагностика) и несколько справочников. Уникальным ключом может служить сочетание заводского номера и типа прибора, в идеале двух приборов с одинаковыми этими параметрами быть не должно. Эти принципы позволили нам создать программный продукт, позволяющий вести обмен между любыми серверами и базами данных АСКУЭ по любым каналам, в том числе электронной почте. Уже сейчас мы ведём автоматический обмен коммерческими данными на верхнем уровне с АСКУЭ ведущих российских фирм. Причём настроить эту систему оказалось относительно просто. Очень хорошо зарекомендовали себя такие общедоступные средства связи как электронная почта, ftp, просто Dialup-соединения. Практически с нулевыми затратами можно объединить все разношёрстные источники данных АСКУЭ.
    Хорошая идея предложена АТС – применять для передачи данных демократичный и легко расширяемый XML формат. Это не накладывает никаких ограничений на внутренности АИИС. Желательно и здесь принять опыт уже существующих наработок и использовать первичные данные с флагами ошибок. Было бы удобно всем разработчикам, если бы АТС разработала свой вариант программы-ретранслятора и предлагала его применять всем разработчикам в своих АИИС. Тогда отлаживать пришлось бы один раз и все бы пользовались сертифицированным, проверенным продуктом. Разработчику осталось бы только написать свои SQL-процедуры для доступа к первичным данным своей базы, всё остальное (самое сложное)- пакетную пересылку с подтверждениями в заданном регламенте по основному и резервному каналам- выполнял бы модуль АТС. Написать мультиплатформенную программу, работающую с любой БД АСКУЭ – реальная задача.


Последнее обновление ( 12.10.2017 г. )
 
« Пред.   След. »


Использование любых материалов с сайта возможно только с письменного разрешения администрации.
При цитировании активная ссылка на сайт обязательна.
Идея сайта :  Фёдоров Д.В.
Дизайн и вёрстка :  Фокеев Д.А.
Художник :  Савоськина Л.В.
Copyright © НВТО Все права защищены.

Rambler's Top100