Расширяемая система учета электроэнергии

[akcount]

Доброго времени суток, коллеги.

На этапе строительства завода прорабатываю еще и концепцию системы учета электрической энергии, которая в идеале (и в будущем, да) будет расширена до некоего единого комплекса учета всех энергопотоков (электричество, вода, газ, в общем - всего).

Я - "промышленник" чистой воды (PLC, SCADA и все), понимание доходит медленно. Взываю о помощи.

Вот добрался я до описания эльстеровского "Альфа-центра". По описаниям все хорошо (как обычно), коллеги дают положительные отзывы. Тем не менее, существует уже одна глобальная заминка.

Дело в том, что основной поставщик АСУТП (Danieli, Италия) уже поставил нам на склад систему тех. учета. То есть, она существует, даже какое-то по для PLC поставлено. Купленная в составе прочих систем АСУТП подсистема тех. учета базирована на Simatic PLC S7-400, верхушка - InTouch. То есть, всеми правдами и неправдами (чтение импульса с приборов энергоучета, или по профибусу, или с других даниелевских контроллеров) у меня есть более-менее полная картина.

Ситуация усугубляется дальше. Кроме основного поставщика есть несколько других, поменьше. Пара систем поставляется так же итальянцами. Еще парочка - российские проектировщики и интеграторы. Как таковой сборной солянки я не вижу, кругом лишь сименс и АББ.

Но дело-то в том, что Альфа-центр - это "вещь в себе". Я не говорю, что это плохо. Я лишь говорю про то, что А-центр работает строго с ограниченным набором счетчиков. И он не умеет читать данные ни с других контроллеров (что было бы чЮдом), ни с других датчиков.

А данные уже есть.

Сущствует ли в природе системы учета, которые умеют не только собирать данные со "своих" счетчиков? В идеале, чтоб при мелкой доработке напильником система умела напрямую собирать данные с PLC. То есть, нечто более гибкое и расшяряемое.

При этом связываться с молодыми фирмами-разработчиками особого желания нет. И дело даже не в том, что у них софт сырой. У них может быть идеальный софт, вылизанный до блеска. Дело в том, что сегодня они есть, а завтра может и не быть... А мне потом всю эту кухню еще и обслуживать. Что даже с исходниками всего ПО - дело чрезвычайно трудозатратное.

WBR, Alex

[Dmitry Isaev]

я с 2005 года в этом котле варюсь (АИИС КУЭ) и пока кроме систем "местных умельцев" ничего не встречал

более того: в связи с тем, что КАЖДЫЙ счётчик электроэнергии имеет собственный протокол, а в своё время заказчики приобрели системы конкретного производителя, они стали зависимы в выборе ДАЖЕ счётчиков для развития системы учета электроэнергии

и никакого движения на сближение...
всем и так хорошо

[akcount]

То есть, моим наивным мечтам об некоем промежуточном OPC-RTU-устройстве не суждено сбыться?

Значит ли это, что все системы АСКЭУ опрашивают лишь "свои" счетчики, и фигу вам - а не возможность простейшими манипуляциями вклиниваться в любой сторонний контроллер или девайс, для которого написан OPC-сервер?

[akcount]

Вот давайте прикинем, что бы я хотел.

СУБД на сервере, на нем же некий софт связи, TCP/IP протокол. То есть, функции сервера - это база данных и опрос промежуточныз устройств RTU по любому своему протоколу прикладного уровня. К серверу цепляются АРМы, делающие выборки из БД и строящие отчеты/графики и прочую чехарду так, как захотят главные электрики. Собственно, стандартная кухня.

Самая интересная часть - это промежуточное устройство связи с объектом, назовем его для простоты RTU. Представим его в виде "ч0рного ящика". С одного конца RTU подцеплен к центральному серверу. Средствами протокола связи (неважно по чьей инициативе) эта RTU записывает на сервер параметры энергии: потраченные кВт*ч активной и реактивной, межфазные напряжения, токи по фазам, косинус Фи и прочее, и прочее.

На этом RTU установлен OPC-сервер, заточенный под конкретное устройство. То есть, под конкретный девайс, который считывает параметры энергии. И за счет использования технологии OPC этот полевой девайс может быть каким угодно (счетчик энергии и даже свободнопрограммируемый контроллер, который уже сам опрашивает свои входа и вычисляет энергию).

Важная фича этого RTU - умение накапливать данные внутри себя на моменты отсутствия связи с главным сервером.

По идее, желание очевидно. Вопрос - умеет ли так делать хоть кто-нибудь на рынке?

Писать такую систему своими силами - дела гиблое и нестоящее. Много времени, много денег, много трудозатрат, конечный результат - под огромным вопросом. Даже если каким-то чудом я мог бы убедить руководство холдинга вложиться в эти разработки... даже если бы и мог, не стал бы этого делать. У АСУТП завода совершенно другие задачи и функции, чем вести собственные разработки на много лет и много-много миллионов долларов.

[atamkosta]

Вопрос: речь идет о комерческом учете или технологическом?
Есть мультиметры-счетчики у тех же дешевых итальянцев типа Ловато, Терасаки... Имеющие Profibus интерфейс. Небольшой сервер 2003тий с WinAC и WinCC решают проблему сбора на Ура. Из этой кормушки питается MES система клиента.
Я не беру за разработку приложения на WinCC больше десяти тысяч. Еще две тысячи с меня содрали барыги при центре стандартизации за то что они мою модель мультиметра-счетчика провели в реестр.

[akcount]

Сейчас речь идет об учете техническом.

Решения на скаде меня не интересуют. Мне нужна информационная система (чем, грубо говоря, и является АСКУЭ), которая умеет забирать данные со скады и/или других железок.

Завод может себе позволить купить и Альфа-центр, и затратить деньги на приобретение дополнительных счетчиков типа А1800, ЕвроАльфа и т.д. Просто мне элементарно дущит жаба, что половина счетчиков уже поставлено на завод, участвует в системе диспетчеризации электроресурсов, но не будет применяться в тех. учете.

Дублирование датчиков - это просто не изящный вариант.

С другой стороны, подход Альфа-Центра упрощает жизнь в обслуживании. Энергоучет получается "вещью в себе", не зависящий от других подсистем.