[miksher2008 0]

Здравствуйте.

Хотелось бы спросить у вас, кто-нибудь занимался разработкой программного обеспечения для мониторинга различных контроллеров? Напишите пожалуйста мне кто писал программы мониторинга.

 

Я занимаюсь разработкой ПО для мониторинга дизель-электро установок(ДЭУ), то есть программа ведет опрос контроллеров установленных в ДЭУ через COM-порты.

Хотел поинтересоваться различными идеями, алгоритмами таких или подобных проектов, а так же поделится своими мыслями.

Пишите пожалуйста сюда, буду благодарен за отклик.

[miksher2008 0]

Здравствуйте.

Хотелось бы спросить у вас, кто-нибудь занимался разработкой программного обеспечения для мониторинга различных контроллеров? Напишите пожалуйста мне кто писал программы мониторинга.

 

Я занимаюсь разработкой ПО для мониторинга дизель-электро установок(ДЭУ), то есть программа ведет опрос контроллеров установленных в ДЭУ через COM-порты.

Хотел поинтересоваться различными идеями, алгоритмами таких или подобных проектов, а так же поделится своими мыслями.

Пишите пожалуйста сюда, буду благодарен за отклик.

[AlexandrY 3]

Приходится заниматься регулярно такой писаниной.

СOM порты худшее, что можно придумать для таких дел.

Во первых из-за низкой скорости, во вторых из-за низкой интеграбельности в стандартные системы сбора данных.

Т.е. конечно на COM порт есть море проприетарных(закрытых) протоколов или примитивных открытых (вроде MODBUS) но они создают сильные трудности когда надо действительно много дивайсов контролировать.

 

Много - это ближе к тысяче и более. Впрочем это могут быть не дивайсы, а отдельные узлы дивайсов или даже отдельные параметры тогда узлов даже при нескольких дивайсах может стать больше тысячи.

Другая проблема это разделение на потоки по интересам или мультиплексирование потоков данных в разные програмные комплексы для анализа.

Это тоже на рудиментарном уровне при использовании COM интерфейса.

 

Если ориентироваться на открытые решения, то очень удобно использовать протокол SNMP.

SNMP работает поверх UDP, а тот в свою очередь поверх IP.

Протокол IP можно реализовать как на интерфейсе Ethernet, так и на COM порту но придется еще подставить снизу либо протокол SLIP либо протокол PPP. Вернее Direct connect PPP. Такой PPP не требует вспомогательного движка AT команд и вносит оверхед в считанные байты.

Правда заголовки IP, UDP и SNMP под сотню байт могут нагрузить каждый пакет.

Поэтому COM всетаки будет медленоват.

 

Но зато протокол SNMP понимают большинство SCADA, открытые системы распределенного управления как OpenNMS, море простых програм для управления по SNMP и наконец есть доступные компоненты работы с SNMP для RAD Studio, Visual Studio и т.д. вплоть до ActiveX для Excel-а

 

SNMP выполнен так, что поддерживает работу с параметрами структурированными в виде иерархического дерева. Это позволяет легко отфильтровавать в реальном времени интересующие домены параметров прямо во входном потоке без обратного поиска по таблицам или сравнений с фильтрами.

Реальное время и разгрузка процессора от поиска и сравнения позволяет применять SNMP в системах с постоянными, мощными и разнообразными потоками данных.

 

Другие интересные варианты предлагают пакеты вроде NI LabVIEW Embedded Module и Matlab.

Они хороши тем, что прямо в них можно делать и анализ и визуализацию данных.

Речи о простой организации связи с тысячами устройств там не идет но с десятком можно связь наладить опять же дешево и сердито.

Особенно интересен NI LabVIEW под ARM где они дают исходники эффективного движка на базе RTOS от Keil. Исходники автоматически компилируются и грузятся в микроконтроллер. А на PC LabVIEW одновременно формирует приложение которое те данные принимает (и по COM, и по Ethernet)и может вывести куда надо: на график, в файл, в блок анализа и фильтрации, в Интенет и т.д.

 

 

А вообщем мысль такая, есть куча методов не писать программу мониторинга.

Исключение разве что реалтайм мониторинг через малоисследованные каналы передачи данных, как GPRS или ZigBee

 

 

Здравствуйте.

Хотелось бы спросить у вас, кто-нибудь занимался разработкой программного обеспечения для мониторинга различных контроллеров? Напишите пожалуйста мне кто писал программы мониторинга.

 

Я занимаюсь разработкой ПО для мониторинга дизель-электро установок(ДЭУ), то есть программа ведет опрос контроллеров установленных в ДЭУ через COM-порты.

Хотел поинтересоваться различными идеями, алгоритмами таких или подобных проектов, а так же поделится своими мыслями.

Пишите пожалуйста сюда, буду благодарен за отклик.

[DimMil 0]

Регулярно приходится с микроконтроллерами через RS порт общатся. Ethernet конечно круче, но не всякий микроконтроллер его тянет.

 

Хочу заметить что под .NET лучше не использовать готовый компонент, а связываться через вызовы API - OpenFile и т.д.

То что предлагает микрософт для .NET слишком тормознутый, да и глучит.

[AlexandrY 3]

.NET очень разнообразен и легко ошибиться в тактическом применении его отдельных фичей.

 

Ясно, что реалтайм парсеры транспортных протоколов на нем писать мягко говоря проблематично.

Но когда поверх .NET ставят движок Microsoft Robotics Studio, то этот сибиоз может стать чемпионом по скорости распределенного управления http://msdn.microsoft.com/ru-ru/robotics/aa731536.aspx

 

Т.е. .NET в этом случае должен стоять на обоих концах. И на микроконтроллерах и на PC.

С недавних пор Windows CE поддерживает .NET так что вариант с Robotics Studio очень реалистичный даже для очень дешевых микроконтроллеров.

 

 

 

Регулярно приходится с микроконтроллерами через RS порт общатся. Ethernet конечно круче, но не всякий микроконтроллер его тянет.

 

Хочу заметить что под .NET лучше не использовать готовый компонент, а связываться через вызовы API - OpenFile и т.д.

То что предлагает микрософт для .NET слишком тормознутый, да и глучит.

[miksher2008 0]

У меня в основном пока для начала задействовано до 8 COM-портов, а далее с числом роста ДЭУ, где установленно до 8 контроллеров соответственно и число портов возростет до N-ного числа, а когда это N-ое число будет выше 255(масимальное число COM в Windows), то возникает проблема.

 

Сейчас я использую в качестве узла связи между контроллерами ДЭУ и ПК порт сервер (8-ми портовый EDG 4508 фирмы Advantech), он работает с компом через Ethrnet, у него свои программное обеспечение для ПК, для одного такого порт-сервера в Windows можно создать 8 виртуальных COM-портов. А когда порт-серверов будет больше сотни, а Windows не даст создать больше 255, вот тут проблема.

 

Пока при работе с COM-портами не порблем не было. Во сновном сбои с контроллерами, то захлебывались, то обрудование, которое осуществляет связь порт-сервера с ПК(витая пара, RS 485, оптоволокно) работало с маленькой скоростью, полудуплексом и т.д.

 

Хотелось бы спросить, а вот если вы давно занимались мониторингом контроллеров, можете посоветовать какую-нибудь литературу (книги, сайты, ссылки и т.д.). И вообще узнать есть ли подобные программки по мониторингу ДЭУ.

[AlexandrY 3]

Дизель-электро установки это так понимаю элементы системы питания.

 

Я в частности занимаюсь соединением в сеть тоже элементов питания, а именно инвертеров, UPS-ов, конвертеров и проч.

В этой области SNMP стал стандартом дефакто где системы питания обслуживают крупных операторов связи.

Сам стандарт SNMP читать из RFC бесполезно, там все концентрируется на мониторинге коммуникационных сетей.

Из официального SNMP интересует только способ кодирования ASN и принципы использования MIB файлов

Остальная информация ищется на профильных сайтах производителей продвинутых (многокиловатных) UPS-ов.

В частности надо искать отраслевые спецификации на общепринятый состав MIB-ов.

Кстати разрабатываю контроллеры конвертирующие инфу из COM порта в SNMP потоки.

 

 

 

У меня в основном пока для начала задействовано до 8 COM-портов, а далее с числом роста ДЭУ, где установленно до 8 контроллеров соответственно и число портов возростет до N-ного числа, а когда это N-ое число будет выше 255(масимальное число COM в Windows), то возникает проблема.

 

Сейчас я использую в качестве узла связи между контроллерами ДЭУ и ПК порт сервер (8-ми портовый EDG 4508 фирмы Advantech), он работает с компом через Ethrnet, у него свои программное обеспечение для ПК, для одного такого порт-сервера в Windows можно создать 8 виртуальных COM-портов. А когда порт-серверов будет больше сотни, а Windows не даст создать больше 255, вот тут проблема.

 

Пока при работе с COM-портами не порблем не было. Во сновном сбои с контроллерами, то захлебывались, то обрудование, которое осуществляет связь порт-сервера с ПК(витая пара, RS 485, оптоволокно) работало с маленькой скоростью, полудуплексом и т.д.

 

Хотелось бы спросить, а вот если вы давно занимались мониторингом контроллеров, можете посоветовать какую-нибудь литературу (книги, сайты, ссылки и т.д.). И вообще узнать есть ли подобные программки по мониторингу ДЭУ.

[miksher2008 0]

Я в частности занимаюсь соединением в сеть тоже элементов питания, а именно инвертеров, UPS-ов, конвертеров и проч.

Я так понимаю ты соединяешь и аппаратную часть и пишешь ПО (т.е. программную часть).

В сеть инвертер, UPS-ы соединяются по интерфейсу Eyhernet, я так понимаю.

В этой области SNMP стал стандартом дефакто где системы питания обслуживают крупных операторов связи.

У меня же контроллеры ДЭУ соединяются через RS-232и каждый тоже имеет свой собственный протокол (или это можно назвать как команды), поэтому протокола как такового ниту но есть команды.

А вот есть еще такой девайс в разработке на добавление в ПО по мониторингу, который имеет протокол MODBUS, ты можешь помочь с литературой по MODBUS-у, буду благодарен за помощь.

А еще, в какой среде ты пишешь ПО?

[733259 0]

Занимался похожей задачей, сейчас подключено 360 устройств через RS-422, платы Adaptech, две четырехпортовые, с целью экономии кабеля в неск. местах поставлены разветвители на трёх max1480. Притокол самопальный.

[miksher2008 0]

Занимался похожей задачей, сейчас подключено 360 устройств через RS-422, платы Adaptech, две четырехпортовые, с целью экономии кабеля в неск. местах поставлены разветвители на трёх max1480. Притокол самопальный.

360 устройств работают по обычному COM-порту или другим способом?

[733259 0]

Через 8 портов на 2 платах, со стороны ОС выглядят как COM-порты (COM3 - COM10).

RS-422 позволяет поцепить 32 устройства в одном сегменте, кабель - 2 витые пары, 120 ом, в инете можно найти подробную инфу.

У каждого устройства свой адрес, уникальный в своем сегменте, одно работает, остальные молчат.

[miksher2008 0]

Через 8 портов на 2 платах, со стороны ОС выглядят как COM-порты (COM3 - COM10).

RS-422 позволяет поцепить 32 устройства в одном сегменте, кабель - 2 витые пары, 120 ом, в инете можно найти подробную инфу.

У каждого устройства свой адрес, уникальный в своем сегменте, одно работает, остальные молчат.

А что за девайсы мониторишь? В какой области?

[AlexandrY 3]

Standalone серверы пишу в RAD STUDIO.

Вот есть сервер на 1000 одновременно подключенных дивайсов.

Тестировался с перегрузкой до 3-х тысяч дивайсов.

У каждого дивайса по нескольку сотен параметров.

http://aly.ogmis.lt/OpenProjects/ARMDominator3/ARMD3.htm

 

Редкие UPS-ы и инверторы имеют встроенный Ethernet. У большинства есть штатные только COM-ы

Ethernet любят продавать отдельно.

Мои адаптеры конвертируют весь зверинец протоколов в единый стандарт SNMP.

Работал и с MODBUS, с тучей других протоколов начиная с электросчетчиков по IEC62056-21 и кончая промышленными весами.

У многих стиль обмена действительно и протоколом назвать нельзя, просто реакции на команды.

Но часто можно инициировать и непрерывные стримы и асинхронные пересылки по событиям.

Полезность спец адаптеров и SNMP в том числе в том, что можно вставить штамп времени и просеивать поток по времени еще до того как он войдет в ближайший концентратор.

 

 

Про принцип работы с MODBUS можете посмотреть вот в этом моем открытом проекте:

http://aly.ogmis.lt/OpenProjects/SimpleRFNet/SimpleRFNet.htm

 

 

 

Я так понимаю ты соединяешь и аппаратную часть и пишешь ПО (т.е. программную часть).

В сеть инвертер, UPS-ы соединяются по интерфейсу Eyhernet, я так понимаю.

 

У меня же контроллеры ДЭУ соединяются через RS-232и каждый тоже имеет свой собственный протокол (или это можно назвать как команды), поэтому протокола как такового ниту но есть команды.

А вот есть еще такой девайс в разработке на добавление в ПО по мониторингу, который имеет протокол MODBUS, ты можешь помочь с литературой по MODBUS-у, буду благодарен за помощь.

А еще, в какой среде ты пишешь ПО?

[Kabron 0]

По работе именно этим и занимаюсь - удаленный мониторинг систем бесперебойного электроснабжения. Это не только УПСы и ДГУ, есть и вспомогательные девайсы COC(common output cabinet), CROSS(быстродействующий АВР) и т.п. Не все к сож. поддерживают SNMP даже в линейках одного производителя. Сделади, пожалуй единственную в своем роде универсальную прогу мониторинга SNMP устройств (не путать с NMS типа OpenView). Дема 15 минутная лежит тут http://www.inelt.ru/ru/attach_file/upslook_install.zip описуха http://www.inelt.ru/ru/attach_file/UPSLook_UM_Rus.pdf. Проблема еще в том что очень немногие производители четко следуют стандартному МИБу RFC1628 , почти каждый старается его расширить. В последнее время обратили внимание на Modbus, и не зря. Во-первых этот протокол поддерживается практически всеми производителями (хочеш чтобы тебя покупали для BMS(buildind management system- будь любезен Modbus), во-вторых лекго расширяется и гибко наращивается ну и удобно формализуется - по аналогии с MIB придумали JIB. Щас сделали мониторинг ДГУ и ИБП, на очереди кондиционеры и прочая хрень. Чистый RS232 вещь неудобная и отживающая.

 

 

 

Standalone серверы пишу в RAD STUDIO.

Вот есть сервер на 1000 одновременно подключенных дивайсов.

Тестировался с перегрузкой до 3-х тысяч дивайсов.

У каждого дивайса по нескольку сотен параметров.

http://aly.ogmis.lt/OpenProjects/ARMDominator3/ARMD3.htm

 

Тоже интересное решение. Сами о таком думали.

Вопрос сколько примерно стоит у вас создание SNMP агента для известного протокола?

Изменено 30 декабря, 2008 пользователем Kabron

[AlexandrY 3]

Страная склонность к MODBUS, если конечно его спецификацию не модернизировали сильно за прошедшие несколько лет.

MODBUS был исключительно локальным протоклом полевой шины.

SNMP особенно в 3-й версии расчитан на глобальные сети.

 

Собственно SNMP агент в нашем исполнении - это один из набора аппаратных универсальных модулей, и они вообщем особенно не изменяются от приложения к приложению.

Протоколы обслуживаемых дивайсов проблему не представляют и расходы на их подключение теряются на фоне других сложностей и обычно даже не включаются в себестоимость.

Реальная сложность в интеграции в систему клиента.

Действительно форматы MIB-ов создают большие проблемы.

Каждый производитель, а часто и потребитель хочет по своему закодировать переменные, свободно интерпретирует правила синтаксиса, в первых версиях SNMP явно мало номеров TRAP-ов и производители любят делать динамическое изменение назначений TRAP-ов.

Но такие фокусы плохо переносят серверы SNMP как HP OpenView и т.д.

А изменения логики формирования TRAP-ов приводят к сильным изменениям в софте агента.

Поэтому как бы к каждому приложению приходится делать предварительный анализ ситуации.

 

 

По работе именно этим и занимаюсь - удаленный мониторинг систем бесперебойного электроснабжения. Это не только УПСы и ДГУ, есть и вспомогательные девайсы COC(common output cabinet), CROSS(быстродействующий АВР) и т.п. Не все к сож. поддерживают SNMP даже в линейках одного производителя. Сделади, пожалуй единственную в своем роде универсальную прогу мониторинга SNMP устройств (не путать с NMS типа OpenView). Дема 15 минутная лежит тут http://www.inelt.ru/ru/attach_file/upslook_install.zip описуха http://www.inelt.ru/ru/attach_file/UPSLook_UM_Rus.pdf. Проблема еще в том что очень немногие производители четко следуют стандартному МИБу RFC1628 , почти каждый старается его расширить. В последнее время обратили внимание на Modbus, и не зря. Во-первых этот протокол поддерживается практически всеми производителями (хочеш чтобы тебя покупали для BMS(buildind management system- будь любезен Modbus), во-вторых лекго расширяется и гибко наращивается ну и удобно формализуется - по аналогии с MIB придумали JIB. Щас сделали мониторинг ДГУ и ИБП, на очереди кондиционеры и прочая хрень. Чистый RS232 вещь неудобная и отживающая.

Тоже интересное решение. Сами о таком думали.

Вопрос сколько примерно стоит у вас создание SNMP агента для известного протокола?