alekcandr написал:

[q]

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

[/q]

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

Занимаюсь диспетчеризацией более 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 штук.Но в базе ПО и тепло-газосчетчика все инструменты имелись и решение не вызвало системных изменений.Посмотрели как это реализовано у других , особенно по контроллерам энергоучета...Каждый выкидывает деньги по своему
Хватит, а то уже целая статья.

[q]

Хватит, а то уже целая статья

[/q]

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

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

Большое спасибо за перечень , с какими приборами было больше всего мороки???