Версия для печати

-   Форум Теплопункта https://teplopunkt.ru/forum/
--  Учет тепла, воды, газа, пара https://teplopunkt.ru/forum//index.php?f=2
--- Диспетчеризация.Муки выбора https://teplopunkt.ru/forum//index.php?t=268




-- Уемов Владимир написал 9 июня 2008 6:11
Здравствуйте уважаемые специалисты!
Набравшись смелости, открываю новую тему: «Диспетчеризация. Муки выбора».
Предисловие.
Наша организация обслуживает порядка 126 счетчиков (не считая частников), установленных на границах раздела м/у ТСО и организацией-транспортировщиком тепловой энергии.
Парк приборов следующий:
Половина Взлет ТСР-031
Другая половина ТЭМ-104
Ну и по мелочи СПТ-941, ТЭМ-05М2, SA-94 «Aswega».
В качестве адаптера GSM планируется АССВ-030 производства того же Взлета.
Поехали…
К сожалению, мне не довелось «пощупать» ни одну из систем диспетчеризации :mad: .
Как я понял из информации, почерпнутой из рунета, предложений довольно много.
Что же выбрать? Может, кто поделится опытом эксплуатации или внедрения.





-- alekcandr написал 9 июня 2008 9:12
Любая сеть требует много вложений.
Наша организация Обслуживает 1980 узлов учета.
Так как основную часть составляют КМ-5 (1600) узлов мы рассматревали многие варианты сети.
была создана сеть на 45 узлов через диспечерскую Лифтов. по заявленным данным Все работает исправно, но переодически преходится перезапускать отдельные преобразователи сети RS 232/Ethernet.
неплохое предложение сделал "ТЭМ-прибор" АвтоМобильная Диспетчеризация! но есть свои трудности. Так как приборы установлены в подвалах связь не везде возможна. Требуется вложения для вывода антен.


-- Уемов Владимир написал 9 июня 2008 9:45
1980- ну вы ребята и крутые! :thumbup:
alekcandr-то есть получается что 1980-45=1935 УУТЭ вы обслуживаете вручную.
Как вам это удается?
У нас предложения от Взлета-это многострадальный "Взлет СП", от ТЭМа тоже что то было, даже обратились в НПФ Круг.
Все хвалят свой товар-но кто обеспечить наилучшею надежность мне до сих пор непонятно.
Есть конечно идея создать свою на базе scada-системы WinCC, но пока неизвестно во что и во сколько это выльется.


-- Павел Валентинович написал 9 июня 2008 14:00
Владимир, добрый день. Помнится мне часть специалистов с "Логики" ушла к "Взлету" поэтому свяжитесь со "взлетом" кажется у них есть программный продукт, который может опрашивать как ВЗЛЕТЫ так и СПТ.
Асвега это отдельный разговор. Нормально по модему вяжутся ТС-07, ЭСКОТ,
СПТ и СПГ(это то, что тестировали в большом кол-ве и что работает на всяких телефонных линиях)
С уважением.


-- Уемов Владимир написал 10 июня 2008 7:09
Уважаемый Павел Валентинович!
Это хорошо, что кадры идут в правильном направлении ;)
Взлет СП- вероятно, тоже хорошо!
Но так хочется, чтоб система была обкатана где-нибудь.
К сожелению нет возможности использовать проводные виды связи, ибо ТСЧ установлены в местах "труднопроходимых" (подвалы жилых домов)





-- sansanwch написал 10 июня 2008 15:42
Не забудьте поставить таймеры суточные на модемы GSM. А то забудете заплатить за сотовую связь и придётся ездить по подвалам включать-выключать"чёрные ящики".


-- sansanwch написал 10 июня 2008 15:44
Кстати по витой паре лучше делать подключение модема,если хочешь наладить хорошую GSM связь!, а антенну удлинять можно всего метров до десяти!


-- Дмитрий Анисимов написал 10 июня 2008 16:13

sansanwch написал:
[q]
по витой паре лучше делать подключение модема,если хочешь наладить хорошую GSM связь
[/q]


Что-то не понял. Совсем не понял. Вы рекомендуете GSM-модем к теплосчетчику подключать витой парой?


-- Павел Валентинович написал 10 июня 2008 16:34
Добрый день, Владимир.
По большому счету есть нормальные теплосчетчики на базе которых можно делать диспетчеризацию , а есть оборудование, в описании которого заявлено что есть возможность подключние GSM модема и сетевого модема,
а на практике связь устанавливается после десятков попыток дозвона.
Поэтому при проектировании сразу необходимо определиться с качественным прибором, что бы потом не было мучительно больно за бесцельно выкинутые деньги.
С уважением.


-- Уемов Владимир написал 11 июня 2008 5:40
Спасибо, Павел Валентинович!
Меняю деньги на опыт.
Коммерчески-риск оправдан. Хотя слово "риск" мне не очень нравиться.
Вообщем, закупаем пробно "Взлет-СП". Одисптчерим часть "взлетов".
Попробуем, если..., то....





-- sansanwch написал 11 июня 2008 7:15
Да,например у меня один СПТ-943 соединён витой парой на расстоянии около 50 м и при этом стабильно работает.


-- Дмитрий Анисимов написал 11 июня 2008 9:38
Витая пара, а что "на конце"? Разъем RS232?


-- sansanwch написал 11 июня 2008 9:42
Объясняю популярно: в СПТ-943 - 4 выхода, в витой паре восемь жил,по два на один вход и поехали....а в модеме RS232 там тоже нужно четыре конца...при этом затухание сигнала снижается - обычная физика не помню какого класса.


-- Дмитрий Анисимов написал 11 июня 2008 10:20

sansanwch написал:
[q]
обычная физика не помню какого класса
[/q]


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

Так вот, если Вы берете два устройства с интерфейсом RS232 (линии TxD, RxD и две GND), берете кабель, в котором четыре витых пары и два "конца" каждой витой пары цепляете на один и тот же контакт RS232... то, к сожалению, не получаете никакого полезного эффекта. Ровно с тем же успехом СПТ и модем можно соединить обычным четырехжильным кабелем. Лучше - экранированным.


-- sansanwch написал 16 июня 2008 9:24
Факт в том,что такое подключение работает и имеет место.


-- Дмитрий Анисимов написал 16 июня 2008 9:27
Я не спорю, что работает. Но я думаю, что оно ничуть не хуже работало бы и с "обычным кабелем".


-- Павел Валентинович написал 16 июня 2008 13:58
Коллеги, СПТ и СПГ вообще по своему принципу нормально вяжутся по телефонной линии и с GSM модемом и в СПТ для модемов есть даже такая опция "тест".
Давайте наооборот рассматривать приборы с которыми" полная клиника"


-- Уемов Владимир написал 18 июня 2008 10:14
Ну вот, поставили программу Взлет СП на приборы того же Взлета.
Работает!!!
Осталось придумать как ентой программе привинтить теплосчетчик ТЭМ-104.
И будет счастье :biggrin:


-- alekcandr написал 18 июня 2008 12:22
прошу прощения, не понял какую связь используете?


-- sansanwch написал 18 сентября 2008 14:06
Я не знаю может быть кто-то может объяснить - законно ли поступает ОАО "Ленэнерго" в г. СПб заставляя абонентов ставить на уутэ приборы фирмы "Взлёт" - АССВ-030. Есть среди нас юристы?


-- Владимир Штурмин написал 23 сентября 2008 14:48

alekcandr написал:
[q]
Так как основную часть составляют КМ-5 (1600) узлов мы рассматревали многие варианты сети.
была создана сеть на 45 узлов через диспечерскую Лифтов. по заявленным данным Все работает исправно, но переодически преходится перезапускать отдельные преобразователи сети RS 232/Ethernet.
[/q]

Александр, если не секрет, какую систему диспетчеризации лифтов Вы используете?


-- Владимир Штурмин написал 23 сентября 2008 15:05
Уемов Владимир

Владимир, если данный вопрос еще актуален, то могу порекомендовать оду хорошую, я бы даже сказал боевую систему, проверенную временем. При прочих равных система имеет широкий спектр каналов связи (Ethernet, GSM, радиоканал, провод ...), набор дополнительных ТС, ТИ, ТУ, Хорошее и гибкое ПО.


-- pap написал 25 сентября 2008 9:31
Занимаюсь диспетчеризацией более 15 лет в фирме по производству оборудования и технологий энергоучета. Спервых дней принимаем участие или ведем полностью пилотные проекты ,которые наиболее характерны для применения наших возможностей и являются самыми любимыми (а заказчиков и потребителей сотни ).Это ЖКХ (УК почти 400 УУ, к концу года порядка 500, с 1996г.),крупный завод (более 100 УУ,с 1994г.) транспортники ( 250 ЦТП, с 1995г.) и соцсфера (130 УУ,с 1998г.).
Цель мониторинга
- снижение стоимости эксплуатации (на 1 сотрудника 70-100 УУ или 700-1000 ед.оборудования) при непрерывной и достоверной работе УУ (99%)
- исключение на 100% из процесса формирования отчетов и БД человеческого фактора и создание доверительных отношений между потребителем и поставщиком
- постоянный контроль достоверности показаний УУ и качества потребления
- работа УУ (90%) с момента включения отопления, остальное в течении недели
- мониторинг оборудования УУ в реальных условиях эксплуатации и в первую очередь расходометрии (в результате отказались применять оборудование многих производителей , а также методов измерения, т.к. происходит обман ПОСТАВЩИКА на существенные деньги и недоверие с его стороны)
и т.д.
Инфраструктура - любая, зависит от кошелька заказчика, поставленных задач (и подкрепленных деньгами) , территориальную возможность или исторически используемую (Газпром, большая энергетика и т.д.)На ЖКХ используем изернет проблем ни с последней милей не имеем, ни до подключения узла УУ, в соцсфере - GSM, GPRS или АТС (особенности !)
ПО верхнего уровня - открытая архитектура , работай хоть с нашим продуктом , хоть сам делай,

А теперь немного о некоторых заблуждениях, особенно касающиеся ПО у потребителя (ЖКХ, соцсфера и т.д.) по учету энергоресурсов

1.Лучший и универсальный инструмент ПО - Скада системы

Скада-системы предназначены для получения оперативной информации , как правило технологически взаимосвязанной (например котел или прокатный стан) и где архивы идут от оперативки. Последние скады имеют возможность работать с архивной локальных объектов (УУ, особенно коммерческие), но зачем тогда продукт заточенный на оперативку ? Купим вольво и будем возить навоз, а может лучше трактор с тележкой - и функцио нальней и намного дешевле.
2.Применять только водо-газосчетчики обязательно имеющие ОРС-сервер для унификации нижнего уровня

ОРС -сервер, да нужная вещь особенно там где заказчик ,в рамках своих задач ,определил ,пускай разнообразный парк приборов ,но ограниченный и озаботился о быстрой их замене. И это, как правило, опять привязано к оперативке и единичному параметру.А ЖКХ, соцсфере один чиновник что-то пролоббировал ,а потом подарил или передал УК (как правило бестолковой) или школе, устроив зоопарк,при этом каждый год другое. А тепло-газосчетчики - это куча разных датчиков и расчетных параметров ,и ломается в основном первичка (расходомер,давление, термометр и к ОРС серверу отношение не имеющее ). И для чего спрашивается нужен ОРС-сервер в данных условиях?

3.SQL сервер ORACLE или R3 - престижно и круто
SQL сервер ORACLE или R3 - наверно таким системам ,как Газпром, ТГК, ОГК без такого рода продукта просто не обойтись.Но остальным зачем ?Разница в цене относительно "бюджетной" продукции на 2-3 порядка (ни в разы!). При этом дополнительно обуза - наличие многочисленной и высокооплачиваемой группы поддержки. А результат тот же ,только потенциал продукта используется на пару процентов.

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

5. Разработчики По верхнего уровня не реагируют на заказчика по применению другого оборудования ( а он порой имеет на то основания), кроме рекомендуемого ими.
По мнению разработчика ПО (правда бывает и обоснованно) предлагаемое оборудование не соответствует каким-то его принципам , сложный или неудобный протокол или интерфейс т.д. А в реальности причины гораздо проще- лоббируют определенного производителя ,нет грамотного сотрудника (уволился),фирма просто интегратор ,на разработчик (а позиционируют себя гораздо выше) и далее.
6. По верхнего уровня должно делать все
А зачем? Если есть структура БД , то ты ,как пользователь независим и деньги будешь платить когда надо и в объеме реально соответствующиее сделанной работе.А сегодня многие потребители ПО верхнего уровня как рыба на крючке.

6. И самое интересное .У меня зоопарк по приборам учета и я все это подключу к диспетчерской через инженерный терминал.
Очень популярно у больших систем - большие энергетики, структуры ЖКХ и соцсферы и прочие. Сколько не моделировал обоснованность такого технического решения ,но смог прийти только к одному выводу, но это не тот форум , необсуждаю. На эту тему можно написать целую статью, но ограничусь минусами, а плюсов я пока не знаю
- дорого ,притом в разы ,фактически это системный блок в промышленном исполненении с кучей всяких интерфейсов
- излишняя избыточность(предусмотрены все ситуации , а используются процентов 10
- полная зависомость от интегратора этого инженерного терминала
- сложность в настройке и однозначность в передачи нужного параметра , а также возможности контроля качества работы персонала при многоступенчатой передаче
- возможность злостного искажения информации в интересах какой-либо стороны
- и главное , тот кто оплатил или заинтересован в данной информации в перспективе будет оплачивать эту информацию .
7. Если работает 5 приборов в сети , то и остальное любое количество будет работать
После появления 100 УУ, решали проблемы, много решили проблем после 350 штук.Но в базе ПО и тепло-газосчетчика все инструменты имелись и решение не вызвало системных изменений.Посмотрели как это реализовано у других , особенно по контроллерам энергоучета...Каждый выкидывает деньги по своему
Хватит, а то уже целая статья.









-- Дмитрий Анисимов написал 25 сентября 2008 11:52

pap написал:
[q]
Хватит, а то уже целая статья.
[/q]


Нет уж, Александр Петрович, Вы пишите! ;) И статью тоже напишите и присылайте.


-- Лев написал 25 сентября 2008 13:26
[q]
Хватит, а то уже целая статья
[/q]

И вовсе не хватит, наоборот. Просим, уважаемый рар: очень интересно, даже то, что и так знали, не говоря уж о том, что не знали.


-- Владимир Штурмин написал 25 сентября 2008 14:27
Полностью разделяю точку зрения рар и хочу добавить, что в ПО верхнего уровня (для диспетчеризации УУ) достаточно модуля базы данных, модуля администратора, модуля отчетов, модуля диспетчера и модуль автоопроса, а отображение информации наиболее предпочтительно в виде таблиц и графиков, я полагаю спецам так более понятно, чем смотреть на красивую схему теплового пункта, где меняется цвет трубы, в зависимости от температуры теплоносителя и прочее другое.
Еще большим плюсам ПО верхнего уровня является ее гибкость, способность оперативной доработки ее под определенные требования Заказчиков, но это под силу в основном мелким и средним производителям (разумеется при наличии грамотной команды программистов) крупные и "уважающие" себя фирмы такой "самодеятельностью" не занимается.
Что касается канала связи, считаю наиболее перспективным - компьютерные сети (Ethernet), предполагаю, что не за горами то время, когда вместо разъема под RS- 232 на приборах повсеместно будет разъем RJ-45 и достаточно будет только объединить их в сеть. GSM пока то же не стоит сбрасывать со счетов.
Действительно большой проблемой разработчиком систем диспетчеризации является отсутствия единого стандарта передачи данных и закрытость многих протоколов, но эта проблема наблюдается во многих отраслях.




-- Павел Валентинович написал 25 сентября 2008 16:10
Спасибо коллега за информацию
Можно ли указать типы приборов (вычислители и корректоры) которые вам удалось объединить в одну сеть и хотя бы вкратце используемые адаптеры


-- Владимир Штурмин написал 26 сентября 2008 7:11
В одну сеть объединили:

Взлет
Карат
КМ-5
ВКТ-7
SA-94
СПТ 961
СТД
СТУ-1
ТМК-Н
ЦЭ6822
ЦЭ6827М, ЦЭ6827М1
СЭТ-4ТМ
Сетевой контроллер – КРОСЛАН. Изделие предназначено для дистанционного доступа пользовательского программного обеспечения к объектовому оборудованию с интерфейсом RS232 и RS485 по компьютерным сетям, телесигнализации, дистанционного управления, реализации переговорной связи и мониторинга сегментов сетей



-- Павел Валентинович написал 26 сентября 2008 7:42
Большое спасибо за перечень , с какими приборами было больше всего мороки???


-- Владимир Штурмин написал 26 сентября 2008 9:01
Данный список наращивался годами, и по каждому прибору были свой проблемы, которые приходилось решать. Что-то конкретного по каждому прибору сказать не могу, т.к. занимался этим отдел программирования, а там ребята не "разговорчивые". Что касается не ответа прибора, то реализована функция автоповтора и “долбить” прибор можно хоть весь день (как правило, заложено 5…10 повторов)


-- Павел Валентинович написал 26 сентября 2008 9:09
Мне больше нравиться в плане диспетчеризации СПТ, СПГ и ЭСКО вяжуться легко , без проблем. Очень проблемно ТВМ5 и приборы СТД


-- pap написал 30 сентября 2008 9:51
ТЭКОН 10, 17, 19 и т.д.


-- Уемов Владимир написал 30 сентября 2008 11:41
По проводам это круто.
Очень хочется, чтоб везде была возможность бросить "витую пару".
А теперь представим, что есть 1500 домов и есть желание все одиспечерить. Это же какую паутину надо сплести, чтобы вывести показания на единый диспетчерский пульт.
Поэтому будем обходиться GSM-сетями и GPRS-каналом. Scada-система подразумевает работу в реальном времени, а для инерционных тепловых объектов (типа жилой дом) в этом нет необходимости.
Согласен, есть свои минусы такой диспетчеризации, НО если строить систему диспетчеризации с пустого места, то вложения в такую систему минимальны.


-- написал 30 сентября 2008 13:00



-- pap написал 30 сентября 2008 13:22
Да не очень круто, а почти даром, да и паутины никакой нет .В каждом доме есть два -четыре провайдера , а где нет помогают чтоб появились.И на сервер приходит один оптический кабель , а вс е остальные ,в т.ч. и удаленные пользователи, работают с ним в рамках выданных полномочий. В обеспечении доставки информации участвуют штук шесть провайдеров( в зависимости у кого где сеть ,качество работы, трафик- вообщето он внутренний ,а значит бесплатен) .По GSM и GPRS - сами пользуем , но когда сотни объектов и антенна не везде относится в сторону , а также доступна вандалам - исключаем.И последнее - в GPRS скорей всего используете статистические адреса (если ошибся в ваших разработчиках искренне заранее извиняюсь) , а это ежемесячно 2-3 бакса дополнительно в месяц на точку к трафику да и количество их у провайдера ограничено как правило 2000 штук, , а интернет как обеспечить?


2008-2022, Дмитрий Анисимов
Этот форум работает на скрипте Intellect Board
© 2004-2007, 4X_Pro, Объединенный Открытый Проект