| |
Диспетчеризация.Муки выбораПоделитесь опытом эксплуатации и внедрения
Владимир Штурмин
Новичок
Откуда: Ульяновск Всего сообщений: 24 СсылкаДата регистрации на форуме: 18 авг. 2008
|
Профиль | ИгнорироватьNEW! Сообщение отправлено: 23 сентября 2008 14:48
alekcandr написал: [q] Так как основную часть составляют КМ-5 (1600) узлов мы рассматревали многие варианты сети. была создана сеть на 45 узлов через диспечерскую Лифтов. по заявленным данным Все работает исправно, но переодически преходится перезапускать отдельные преобразователи сети RS 232/Ethernet.[/q]
Александр, если не секрет, какую систему диспетчеризации лифтов Вы используете? | | |
Владимир Штурмин
Новичок
Откуда: Ульяновск Всего сообщений: 24 СсылкаДата регистрации на форуме: 18 авг. 2008
|
Профиль | ИгнорироватьNEW! Сообщение отправлено: 23 сентября 2008 15:05
Уемов Владимир
Владимир, если данный вопрос еще актуален, то могу порекомендовать оду хорошую, я бы даже сказал боевую систему, проверенную временем. При прочих равных система имеет широкий спектр каналов связи (Ethernet, GSM, радиоканал, провод ...), набор дополнительных ТС, ТИ, ТУ, Хорошее и гибкое ПО. | | |
pap
Новичок
Всего сообщений: 25 СсылкаДата регистрации на форуме: 24 сен. 2008
|
Профиль | ИгнорироватьNEW! Сообщение отправлено: 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 штук.Но в базе ПО и тепло-газосчетчика все инструменты имелись и решение не вызвало системных изменений.Посмотрели как это реализовано у других , особенно по контроллерам энергоучета...Каждый выкидывает деньги по своему Хватит, а то уже целая статья.
| | |
Дмитрий Анисимов
Администратор
Откуда: Верхняя Салда Всего сообщений: 8268 СсылкаДата регистрации на форуме: 1 мар. 2008
|
Профиль | ИгнорироватьNEW! Сообщение отправлено: 25 сентября 2008 11:52
pap написал: [q] Хватит, а то уже целая статья.[/q]
Нет уж, Александр Петрович, Вы пишите! И статью тоже напишите и присылайте. | | |
Лев
Долгожитель форума
Всего сообщений: 582 СсылкаДата регистрации на форуме: 22 мар. 2008
|
Профиль | ИгнорироватьNEW! Сообщение отправлено: 25 сентября 2008 13:26
[q] Хватит, а то уже целая статья[/q] И вовсе не хватит, наоборот. Просим, уважаемый рар: очень интересно, даже то, что и так знали, не говоря уж о том, что не знали. | | |
Владимир Штурмин
Новичок
Откуда: Ульяновск Всего сообщений: 24 СсылкаДата регистрации на форуме: 18 авг. 2008
|
Профиль | ИгнорироватьNEW! Сообщение отправлено: 25 сентября 2008 14:27
Полностью разделяю точку зрения рар и хочу добавить, что в ПО верхнего уровня (для диспетчеризации УУ) достаточно модуля базы данных, модуля администратора, модуля отчетов, модуля диспетчера и модуль автоопроса, а отображение информации наиболее предпочтительно в виде таблиц и графиков, я полагаю спецам так более понятно, чем смотреть на красивую схему теплового пункта, где меняется цвет трубы, в зависимости от температуры теплоносителя и прочее другое. Еще большим плюсам ПО верхнего уровня является ее гибкость, способность оперативной доработки ее под определенные требования Заказчиков, но это под силу в основном мелким и средним производителям (разумеется при наличии грамотной команды программистов) крупные и "уважающие" себя фирмы такой "самодеятельностью" не занимается. Что касается канала связи, считаю наиболее перспективным - компьютерные сети (Ethernet), предполагаю, что не за горами то время, когда вместо разъема под RS- 232 на приборах повсеместно будет разъем RJ-45 и достаточно будет только объединить их в сеть. GSM пока то же не стоит сбрасывать со счетов. Действительно большой проблемой разработчиком систем диспетчеризации является отсутствия единого стандарта передачи данных и закрытость многих протоколов, но эта проблема наблюдается во многих отраслях.
| | |
Павел Валентинович
Долгожитель форума
Всего сообщений: 312 СсылкаДата регистрации на форуме: 3 мар. 2008
|
Профиль | ИгнорироватьNEW! Сообщение отправлено: 25 сентября 2008 16:10 Заголовок сообщения: Маленький вопросик
Спасибо коллега за информацию Можно ли указать типы приборов (вычислители и корректоры) которые вам удалось объединить в одну сеть и хотя бы вкратце используемые адаптеры | | |
Владимир Штурмин
Новичок
Откуда: Ульяновск Всего сообщений: 24 СсылкаДата регистрации на форуме: 18 авг. 2008
|
Профиль | ИгнорироватьNEW! Сообщение отправлено: 26 сентября 2008 7:11
В одну сеть объединили:
Взлет Карат КМ-5 ВКТ-7 SA-94 СПТ 961 СТД СТУ-1 ТМК-Н ЦЭ6822 ЦЭ6827М, ЦЭ6827М1 СЭТ-4ТМ Сетевой контроллер – КРОСЛАН. Изделие предназначено для дистанционного доступа пользовательского программного обеспечения к объектовому оборудованию с интерфейсом RS232 и RS485 по компьютерным сетям, телесигнализации, дистанционного управления, реализации переговорной связи и мониторинга сегментов сетей | | |
Павел Валентинович
Долгожитель форума
Всего сообщений: 312 СсылкаДата регистрации на форуме: 3 мар. 2008
|
Профиль | ИгнорироватьNEW! Сообщение отправлено: 26 сентября 2008 7:42
Большое спасибо за перечень , с какими приборами было больше всего мороки??? | | |
Владимир Штурмин
Новичок
Откуда: Ульяновск Всего сообщений: 24 СсылкаДата регистрации на форуме: 18 авг. 2008
|
Профиль | ИгнорироватьNEW! Сообщение отправлено: 26 сентября 2008 9:01
Данный список наращивался годами, и по каждому прибору были свой проблемы, которые приходилось решать. Что-то конкретного по каждому прибору сказать не могу, т.к. занимался этим отдел программирования, а там ребята не "разговорчивые". Что касается не ответа прибора, то реализована функция автоповтора и “долбить” прибор можно хоть весь день (как правило, заложено 5…10 повторов) | | |
|
Время выполнения скрипта: 0.0436. Количество выполненных запросов: 18, время выполнения запросов 0.0264
|