Выбор OpenSCADA для реализации АСКУЭ
| Author |
Message |
|
Written on: 13. 04. 2011 [13:56]
|
|
yra-joey
Юрий Лозинский
Topic creator
registered since: 13.04.2011
Posts: 2
|
Здравствуйте. Ищу решение для создания системы автоматизированного учета потребления энергоресурсов (а именно электричество, газ, хол.вода, гор. вода, тепло) средствами SCADA. Приборы учета работают через протоколы, разработанные самой фирмой производителем счетчика. Пока не могу понять реально ли наладить взаимодействие между SCADA и этими счетчиками и что для этого нужно. Не судите строго, недавно только начал изучать SCADA...
|
|
Written on: 13. 04. 2011 [14:15]
|
|
Maxim
Maxim Lisenko
Contributor
registered since: 18.08.2008
Posts: 141
|
Здравствуйте. Реально, если доступны протоколы этих счетчиков. Есть еще момент: АСКУЭ подразумевает коммерческий учет, а для этого система, осуществляющая его, должна быть сертифицирована.
|
|
Written on: 13. 04. 2011 [14:23]
|
|
yra-joey
Юрий Лозинский
Topic creator
registered since: 13.04.2011
Posts: 2
|
ага, понятно. Протоколы доступны. Для начала хотелось бы осуществить хотя бы просто учет показаний... А в каком направлении копать? какие модули вашей SCADA использовать? С чего начать собственно?
|
|
Written on: 13. 04. 2011 [15:07]
|
|
Maxim
Maxim Lisenko
Contributor
registered since: 18.08.2008
Posts: 141
|
Можно или дополнить модуль подсистемы DAQ AMRDevs, или воспользоваться модулем "Пользовательский протокол" ( http://wiki.oscada.org/Doc/UserProtocol ) для реализации протоколов. Стоит почитать ветку форума: http://oscada.org/ru/forum/posts//opros_ustroistv_po_sobytiju . А также: http://oscada.org/ru/forum/posts/vnedrenie/vozmozhno_li_snimat_pokazanija_s_atopitelnykh_kotlov/ .
[This article was edited 1 times, at last 13.04.2011 at 15:13.]
|
|
Written on: 13. 04. 2011 [15:23]
|
|
almaz
Almaz Karimov
Contributor
registered since: 25.09.2008
Posts: 516
|
Какие счётчики энерго- и материальных ресурсов собираетесь использовать? Какие протоколы? Ссылки, если можно.
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Written on: 14. 04. 2011 [20:25]
|
|
Nika
Николай Емакаев
registered since: 10.03.2011
Posts: 18
|
Для начала вы должны составить таблицу где в графах указать тип средства учёта, Ввходной сигнал (имрульсный, токовый, сухой контакт, напряжение или протокол на основе 485 или любого другово интерфейса). Следующая графа - скорость изменения сигнала, графа скорость изменения параметра.
Следующий шаг - подбираете контроллеры - желательно одного типа с единым протоколом обмена. Если сигналы изменяются со скоростями не более 10 Герц и вас не интересует анализ типа воровства электроэнергии и утечки воды или газа, то можете исрользовать контроллеры IPCCON, NIDAM, ADAM и им подобные. Далее распределите протоколы по уровням. Далее четвертого уровня забиратся не стоит. На первом уровне - среда передачи. (провод, эфир, стекловолокно и т. д.) Второй уровень - параметры сигналов и способ передачи (дуплекс - полудуплекс, синхронный - асинхронный). На данном этапе определяется в какую дыру компютера совать сигнал и нужны ли дополнительные согласователи между компьютером и вашим железом. Дальнейшие рекомендации зависят от вашей таблицы.
|
|
Written on: 26. 05. 2011 [10:42]
|
|
king
Сергей Удовенко
registered since: 26.05.2011
Posts: 3
|
"Maxim" wrote:
Есть еще момент: АСКУЭ подразумевает коммерческий учет, а для этого система, осуществляющая его, должна быть сертифицирована.
Я тоже долгое время считал что АСКУЭ - это автоматизированная система коммерческого учета электроэнергии, но нашлись люди, которые вкладывают другой смысл в эту аббревиатуру (автоматизированная система комплексного учета энергоносителей :) ) Сейчас уже применяют другой термин АИИС КУЭ - автоматизированная информационно измерительная система коммерческого учета электроэнергии. Что касается сертификации, то если отбросить многие нюансы, то главное чтобы все средства измерения были внесены в гос. реестр средств измерения. Контроллер, если он не считает импульсы с импульсных выходов приборов учета, а опрашивает прибор учета по RS-485, CAN, RS-323, то он не является средством измерения. Многие обзывают его в системе как преобразователь или конвертер. Что касается сертификации ПО, то в нашей стране это пока вещь добровольная, т.е. не является обязательной для системы. В любом случае у нас на предприятии работает система АИИС КУЭ, которая прошла испытания и используется сбытом для коммерческих расчетов на обтовом рынке электроэнергии и мощности, но ни одно специализированное ПО не имеет сертификата.
|
|
Written on: 26. 05. 2011 [14:49]
|
|
king
Сергей Удовенко
registered since: 26.05.2011
Posts: 3
|
Меня тоже интересует возможность использования SCADA для АИИС КУЭ. Попробую схематично описать задачу. Есть большое количество объектов (несколько тысяч) на каждом из которых установлено от одного до двадцати, тридцати приборов учета возможно разных производителей, и как следствие этого, у них разные протоколы обмена, причем свои собственные, некоторые из протоколов похожи на MODBUS, но не они в чистом виде где-то в интернете нашел что один из протоколов MODBUS с расширенной адресацией. Если на объекте не один прибор учета, то между собой они связаны одной из шин (RS-485, CAN, RS-232). Связь объектов с внешним миром осуществляется через или GSM CSD или GSM GPRS или конвертер Ethernet/RS-485/CAN/RS-232 , который висит на той же шине (RS-485, CAN, RS-232). Сами приборы учета микропроцессорные по сути являются контроллерами и имеют порядка двухсот - трехсот параметров (зависит от производителя и модели приборов учета). Эти параметры можно разделить на несколько групп:
1. Статические/конфигурационные (сетевой адрес, серийный номер, настройки интерфейсов (скорость, количество бит, четность и т.д и т.п.);
2. Изменяющиеся в реальном масштабе времени. Это мгновенные значения токов, напряжений, мощности, частоты сети, внутреннее время прибора и т.д. и т.п.;
3. Профиль мощности. Кольцевой массив в памяти прибора в котором хранятся усредненные значения мощности. Интервал усреднения программируется и может быть 3 мин, 15 мин, 30 мин и т.д. глубина массива должна обеспечивать хранение профиля на глубину не менее 30 суток. Т.е. данные в массив добавляются в зависимости от выбранного интервала усреднения либо каждые три минуту, либо каждые 15 минут и т.д.;
4. Журналы. Кольцевые массивы в памяти прибора емкостью от 10 до 100 записей (зависит от модели прибора) содержащие время включения/выключения прибора, коррекции времени, пропадания фаз. сброса показаний, изменения параметров и т.д. и т.п.;
5. Энергия. Ячейки памяти хранящие показания от сброса, потребление за прошлый год, потребление за этот год, потребление за каждый из 12 месяцев года.
Видно что в каждом приборе учета (контроллере) есть различные данные, которые изменяются с разной скоростью от 250 мкс до нескольких лет. Скорость обмена на шине RS-485/CAN/RS-232 составляет 9600. Понятно, что считать данные с прибора учета на той скорости на которой он их меряет не получится в виду того, что скорость на шине всего 9600, но этого и не нужно. Достаточно обеспечить возможность считывать значения мгновенных значений только с одного прибора учета по выбору пользователя на скорости, которую сможет обеспечить канал связи. Остальные параметры нужно считывать со всех приборов учета по мере их появления и по запросу пользователя.
Теперь что касается реализации. Самое понятное для меня сейчас - это то, что протокол конкретного прибора учета можно реализовать используя UserProtocol. Далее логику считывания и обработки каждого параметра из прибора учета можно организовать на JavaLikeCalc.
Но на очень многие вопросы я пока не нашел ответ:
1. Возможно ли использование SCADA в системе такого объема?
2. Вычислитель на JavaLikeCalc позволяет создать несколько библиотек функций в каждой из которых может быть не одна функция, но в параметрах контроллера JavaLikeCalc выбирается всего одна функция из библиотеки. Возможно ли вызывать одну функцию из другой?
3. Если я правильно все понимаю, то каждому прибору учета должен соответствовать контроллер в JavaLikeCalc, а где хранить таблицу опроса, т.е. с какого прибора, какой параметр опрашивать и в какое время это нужно делать?
Теперь что касается транспорта.
GSM CSD Поскольку объектов несколько тысяч, то опрашивать их последовательно один за другим через один модем очень долгое занятие. Можно использовать много модемов для опроса. Несколько тысяч модемов поставить в одной стойке не получится потому как это дорого да и базовая станция не сможет обеспечить такую нагрузку. Можно организовать модемный пул из нескольких модемов (16, 32), но тогда возникает вопрос как автоматически распределить нагрузку на несколько модемов, чтобы для опроса использовался не конкретный модем жестко привязанный к объекту, а выбирался любой свободный. Это возможно? Поскольку объектов много, а модемов в пуле несколько как можно организовать очередь на доступ к модемному пулу?
GSM GPRS Поскольку использовать фиксированные IP-адреса на каждой симке дело расточительное, связь через GPRS организована следующим образом, через определенный интервал GSM GPRS модем, установленный на объекте, посылает на фиксированный IP-адрес сервера "пинг", суть которого состоит в том чтобы сказать серверу какой объект на каком IP-адресе и порту доступен в этот момент. Т.е. наличие самого транспорта и его параметры появляются в процессе работы. Можно ли создавать транспорт в процессе работы, менять его параметры и как связать его с контроллером?
|
|
Written on: 26. 05. 2011 [16:45]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"king" wrote:
Видно что в каждом приборе учета (контроллере) есть различные данные, которые изменяются с разной скоростью от 250 мкс до нескольких лет.
250 мкс это только для анализа формы потребления электроэнергии, активная и реактивная мощности, внутри счётчика и на внешний интерфейс он их никогда не отдаёт. А типовой дискретностью счётчиков является час.
"king" wrote:
Теперь что касается реализации. Самое понятное для меня сейчас - это то, что протокол конкретного прибора учета можно реализовать используя UserProtocol. Далее логику считывания и обработки каждого параметра из прибора учета можно организовать на JavaLikeCalc.
Лучше всего логику опроса такого рода счётчиков реализовавать на уровне шаблона параметра. Т.е. создаётся библиотека шаблонов "AMR-устройства" и в ней для каждого типа счётчика реализуется шаблон с логикой опроса. Далее эти шаблоны используются в модуле DAQ.LogicLev столько раз сколько присутствует счётчиков конкретного типа.
Такой подход позволит просто расширять степень и объём охвата протокола счётчика, под потребности.
"king" wrote:
Но на очень многие вопросы я пока не нашел ответ:
1. Возможно ли использование SCADA в системе такого объема?
Это зависит ни сколько от объемов, сколько от коммуникаций и производительности собирающей данные станции.
"king" wrote:
2. Вычислитель на JavaLikeCalc позволяет создать несколько библиотек функций в каждой из которых может быть не одна функция, но в параметрах контроллера JavaLikeCalc выбирается всего одна функция из библиотеки. Возможно ли вызывать одну функцию из другой?
Конечно можно.
"king" wrote:
3. Если я правильно все понимаю, то каждому прибору учета должен соответствовать контроллер в JavaLikeCalc, а где хранить таблицу опроса, т.е. с какого прибора, какой параметр опрашивать и в какое время это нужно делать?
Про концепцию реализации на логическом уровне DAQ.LogicLev я выше говорил.
"king" wrote:
Теперь что касается транспорта.
GSM CSD Поскольку объектов несколько тысяч, то опрашивать их последовательно один за другим через один модем очень долгое занятие. Можно использовать много модемов для опроса. Несколько тысяч модемов поставить в одной стойке не получится потому как это дорого да и базовая станция не сможет обеспечить такую нагрузку. Можно организовать модемный пул из нескольких модемов (16, 32), но тогда возникает вопрос как автоматически распределить нагрузку на несколько модемов, чтобы для опроса использовался не конкретный модем жестко привязанный к объекту, а выбирался любой свободный. Это возможно?
В концепции с шаблонами возможно. Пишите отдельную функцию запросов на JavaLikeCalc, которая будет иметь список пула транспортов с модемами и таблицу в БД с очередью запросов.
"king" wrote:
GSM GPRS Поскольку использовать фиксированные IP-адреса на каждой симке дело расточительное, связь через GPRS организована следующим образом, через определенный интервал GSM GPRS модем, установленный на объекте, посылает на фиксированный IP-адрес сервера "пинг", суть которого состоит в том чтобы сказать серверу какой объект на каком IP-адресе и порту доступен в этот момент. Т.е. наличие самого транспорта и его параметры появляются в процессе работы. Можно ли создавать транспорт в процессе работы, менять его параметры и как связать его с контроллером?
Можно. Только обычно, счётчики работающие через GPRS, умеют сами высылать свои данные на сервер сбора, например по протоколу HTTP.
Learn, learn and learn better than work, work and work.
|
|
Written on: 27. 05. 2011 [09:03]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"roman" wrote:
"king" wrote:
Теперь что касается транспорта.
GSM CSD Поскольку объектов несколько тысяч, то опрашивать их последовательно один за другим через один модем очень долгое занятие. Можно использовать много модемов для опроса. Несколько тысяч модемов поставить в одной стойке не получится потому как это дорого да и базовая станция не сможет обеспечить такую нагрузку. Можно организовать модемный пул из нескольких модемов (16, 32), но тогда возникает вопрос как автоматически распределить нагрузку на несколько модемов, чтобы для опроса использовался не конкретный модем жестко привязанный к объекту, а выбирался любой свободный. Это возможно?
В концепции с шаблонами возможно. Пишите отдельную функцию запросов на JavaLikeCalc, которая будет иметь список пула транспортов с модемами и таблицу в БД с очередью запросов.
Хотя можно проще. Поскольку контроллер логического уровня это отдельный поток, то очередь можно строить просто помещая счётчики в разные контроллеры логического уровня, где один контроллер логического уровня это отдельный модем и исходящий транспорт. Итого контроллеров логического уровня будет столько сколько модемов.
Learn, learn and learn better than work, work and work.
|
|
|
