Как я пнимаю, существующее ПО- это стандартный броузер, localhost WEB-сервер и dll-ка в каталоге CGI, которая и осуществляет мост HTTP/Modbus? Знаем, проходили. В таком подходе много проще все-таки использовать технологию Flash потому, что там более компактно передаются и автоматически парсятся переменные. Я имею ввиду класс LoadVars(). Hо это частности. В целом же, поигравшись в таком ключе, я вынес твердое убеждение- если уже есть оборудование с Modbus, то не следует затевать модные штучки с HTTP, который рассчитан все-таки как-минимум на Ethernet и крутые стеки протоколов. Труда будет затрачено много, а выигрыш- ... я лично никакого выигрыша не вижу.
Я точно не знаю, но по-моему в Modbus оконечные устройства не имеют возможности самостоятельно вываливаться на шину RS-485, а только реагируют на запросы мастера. Как же тогда они у вас шлют SNMP по своим асинхронным событиям?

Да в сети с роутерами, маршрутизаторами и прокси, мой прием броадкастига не проходит. Hо в локалке, в которой стоят обычные свитчи- работает прекрасно. Смысл UDP-броадкастига на выделенный порт в значительном упрощении софта девайсов, подключенных по Ethernet. В них не надо реализовать громоздкие и тихоходные стеки протоколов, а значит и OC реального времени... много всего сразу упрощается.

5 раз перечитал, так и не понял, что значат первые два предложения. Наверное, девайсы автора так же работают
А на счет "слабый контролер" - бред полнейший. Есть контроллер, есть задача, которую нужно решить. Тут вполне достаточно ATMEGA или аналогичного. "слабых контроллеров" не бывает. Бывает "слабая" программа, бывает "неподходящая для данного контроллера" программа, но это все решаемо, причем без раскидывания пальцев в пространствах.
Лично мне во всей этой затее не нравится только то, что логика завязана на javascript, flash. По моей задумке должно быть один-несколько серверов, которые будут общаться с этими девайсами, ползьователь уже пусть общается с этими серверами. Если кому интересно, могу поделиться своми мыслями по данному поводу.

Логика не завязана. Девайсы сами примут решение и выполнят перезапуск. Ума у них для этого вполне достаточно. А вот отображение информации на каком-нибудь контрольном посту можно сделать как угодно - в моем варианте это может быть браузер, который ходит к устройствам через аякс; любой существующий приниматель snmp trap'ов; любая SCADA-система через Modbus over TCP - выбирайте наиболее подходящий вариант.



Вообщем, аля-SCADA. Нечто подобное я неспеша сейчас пишу, но если ребята из Днепропетровска асилят стабильность своей OpenSCADA к маю сего года, как обещали, то наверное брошу.

Давайте, делитесь.

Насчет ATMeg вы правы.
Вот эти дивайсы
http://www.hw-group.com/products/damocles/...es_2404_en.html
сделаны на ATMege.
У них и WEB, и FLASH, и SNMP, и SMTP. Все есть.

Применение SNMP как бы закрывает тему серверов и группового управления, что тут еще можно более гибкое и доступное придумать?





Не знаю как, у вас там со SCADA-ми, но солидные серверы SNMP не станут работать с дивайсом от которого только trap-ы идут.
Тот же HP OpenView откажется включать дивайс в свою базу если он не поддерживает весь SNMP протокол.
У вас же расчет на простого линуксового демона.
Вы же его логику работы переделать не можете.
Т.е. большой риск ложных срабатываний т.к. сервер не может перепроверить истинное состояние, нельзя реализовать логику принятия решений на стороне сервера, а это уже очень плохо (прежде всего для вас) так как оператор системы быстро озвереет от беспричинных неперепроверяемых алярмов.

Не пойму, если девайс принял решение о перезапуске и сообщил об этом трапом, что большому серверу перепроверять? Действительно ли у меня бит аварии в статусе поднялся???



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

Кроме того, я, как разработчик систем пожарной безопасности, могу Вам рассказать, как таким "звереющим операторам" давали некислой 3.14зды их непосредственные начальники за то, что вместо того, чтобы отодрать зад от дивана в операторской и бегом на место сработки, писали в журнал про "ложняки".

В пионернетовских колхозах способ реагирования не должен отличаться. Сработка - оделся, пошел на объект.

Да я уже не о том.
С вашими сетями все ясно, скупой платит дважды и это его право.

Народ вроде о более общих принципах построения сетей хочет поговорить.
Вот я и поддерживаю тему
В нормальных сетях с большой ценой простоя вами предлагаемое решение так скажем не жилец.
Ему будет трудно конкурировать с теми на которые я дал ссылку.

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



Чем же мое устройство в корне отличается от устройства по Вашей ссылке? Если использовать ее как пинговалку, то устройство по Вашей ссылке не обеспечивает необходимый функционал, потому как для простой работы по перезапуску какого либо оборудования в данном конкретном месте требует наличие удаленного (!!!) мозга, который примет решение и имеет надежность на порядок меньшую, чем собственно девайс.

Сейчас буду бить себя пяткой в грудь и говорить, я на меге легко заставлю контроллер ложно срабатывать. Супер программистов и главное супер QA не существует дыры есть будут, я думаю через определенное время какая либо крайняя версия прошивки будет сносно работать. Linux просто убирает большую часть дыр(зарплата хорошего программиста тоже идет в цену устройства). Про javascript, flash, полностью поддерживаю это не путь Джедая . Был опыт объяснения людям что сервер конфигурации на ASP который работать на AT91rm9200 не путь. Но красиво было глаз не оторвать

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


Об этом уже тем достаточно, только на других форумах
По этому, если хотите, то давайте это обсудим в другой теме.


Опять же не понимаю, что вы хотите этим сказать.
А я легко заставлю вашу железку с линухом "ложно срабатывать"
Вы сами себе противоречите. Пусть это будет хоть линух, хоть вы туда поставите писюк с windows XP и будете программу на VB.NETе писать - везде могут быть ошибки. Только если устройство с ограниченной функциональностью и все самописанное, то будет проще отловить эти ошибки. А в случае линуха или еще чего у Вас будет еще куча глюков самого линуха, помимо ваших ошибок. Потому как "Супер программистов не существует"
И вообще, чем устройство сложнее, тем его надежность меньше. Это справедливо во многих случаях и в этом тоже.

Лично я себе всю систему предствляю так:
на свитчах стоят "пинговалки", которые обладают следующими характеристиками:

• имеют свой IP-адрес
• отвечают на ICMP запросы
• имеют веб-интерфейс для конфигурирования(опционально)
• конфигурируются полностью удаленно
• имеют резервное питание и RTC (опционально)

Должны обеспечивать следующие функции:

• пинговать 1-несколько адресов и при наступлении определенных условий перегружать свитч
• вести лог пропаданий связи, пропаданий питания
• выдавать сведения о температуре (опционально)
• сигнализация при открытии ящика (опционально)
• контроллер заряда батареи для бесперебойного питания свитча (опционально)

В свою очередь, должен быть установлен сервер, который бы собирал информацию (логи) по каждому свитчу.
Постоянно мониторил бы устройства пингом (или UDP).
Вся информация должна писаться в базу данных. При аварийных ситуациях оповещение: e-mail, sms, и т.д.
Визуализацию осуществлять графически на схеме. Если есть возможность, то вообще на карте города.
По такой информации легко можно анализировать работу сети, на предмет обрывов кабеля, потерь пакетов, пропадания питания в домах.
В общем большая часть функционала зависит именно от серверной части, по этому легко наращиваемая.

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

Упрощать не стоит, понятно.
Понимаю, что не каждый IT отдел может иметь настоящего профессионала способного найти оптимальные технологии управления сетью.
Тогда да - "пинговалки" и от большей навороченности смысла не будет.
Скупость не в приобретении дешевых "пинговалок" даже, а в отсутсвие инвестиций в технологии.
Так что не принимайте на свой счет

Я как помните начал тему с представления вполне дешевых дивайсов поддерживающих технологию RMON в составе сети SNMP-оборудованных узлов
О технологии здесь - http://www.osp.ru/nets/1996/06/141763/

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

Простой пинг вполне может себе проходить раз в 5-ть минут допустим в то время как вся сеть будет стоять колом.
И та же пинговалка может методично убивать аппаратуру сбросами просто потому что сменили IP адрес у целевого узла пинговалки.
Поскольку пинговалки невозможно включить в IT структуру управления, то это создает дополнительные накладные расходы на управление и риски.

Насчет устройств по ссылке, то его я привел как пример хорошо управляемого узла для поддержания работоспособности инфраструктуры.
Никакого "мозга" в вашей формулировке, а точнее права единолично принимать решение о сбросе этот дивайс иметь не должен.
Поскольку решение это в ваших дивайсах на самом деле принимается вами разработчиком, причем без знания конкретной ситуации, основываясь может быть на ограниченном и не актуальном опыте.

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

Браво AlexandrY. Эти понятия которые вы сейчас сформировали, существовали у меня на уровне интуиции, а тут всё по полочкам . У нас обычно идут сети(не только передачи данных) под ключ с соответствующем ПО мониторинга всех устройств(бесплатно). На всех критических узлах модули телеметрии, фактически получающих только питания от этого узла. И уже по всем параметрам можно принять решение.

Простите, я может чего-то упускаю в специфике вашей задачи, но вопрос от дурака- почему бы не устроить простой постоянный опрос статуса устройств из центрального пульта? Зачем навороты с SNMP? Зачем TCP/IP? "Пингование" решается автоматически, просто по таймауту? Как я понимаю сеть у вас локальная, изолирована от Интернета.. Зачем тогда все эти навороты?

В АСУТП то зачем пинговалки?
Это не та отрасль, как я понимаю, где позволено виснуть свичерам.
Ту как бы нет предмета обсуждения.
Я вообще MAC пакетами обмен веду в реалтайме и че?

Ну так для этого и нужен тот-же TCP/IP. Или, кому не нравится TCP/IP, я отдаю в виде SNMP-TRAP'ов.



Не понял вопроса.



Сети бывают разные.



Где Вы тут у меня видите навороты? Тут минимум функционала. Навороты предлагают (а по мне, так навязывают) господа AlexandrY и Mihail Gluhowchenko.



Разные АСУТП бывают. А приказом "ни шагу назад" свичам не запретишь падать.

Вот давайте сюда АСУТП не будем приплетать
Изначально все пошло из темы "Владеем сеткой в 200 домов..."
Так что, лично я, отталкиваюсь именно от этого.

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

В АСУТП часто виснет или выгорает периферийное оборудование. "Пинговалка", хотя вряд ли сюда подходит этот термин, поможет обнаружить с центрального поста такое зависание или выгорание. Если удаленный сервер вдруг перестает отвечать на периодические запросы клиента, то пора бежать ремонтникам к месту расположения данного сервера. У Rst7, как я понял, не Ethernet сеть, поэтому говорить про свитчи и Raw-пакеты- тоже особо не имеет смысла.


У коллег видимо другие задачи, с выходом в Интернет, с роутерами и маршрутизаторами. Там да, - лучше выполнять все протоколы досконально.

Гм. Позвольте полюбопытствовать, почему Вы так думаете?

Ну прям навязывают...
У каждого свой опыт просто.
Как-то пришлось участвовать в конкурсе по разработке компонентов европейской региональной системы AMR (Automated Meter Reading) для корпорации ENEL.
Там был яркий пример.
Нужно было разработать некий узел типа конвертера от электросчетчиков в интернет в частности по GSM
Взялась бригада ушлых итальянских парней и наваяла через год.
Не нашли ничего лучше чем весь обмен и удаленный в том числе сделать по типу AT команд.
Нашли даже силы сварганить сервер работающий по AT командам.
Т.е. тоже были склонны к примитивизму, процессор выбрали на базе I51.
Надо-ж было подешевле. Это было одно из главных условий конкурса.
После года мучений ENEL плюнул и организовал новый конкурс и жестко поставил условие использовать SNMP!
Само, что требования к процу тоже поднялись.
А исходники старого проекта раздали всем желающим, чтоб знали авторов того поделия и как не надо делать

Из упоминания про Modbus.

А Вы не знаете, что существует Modbus over TCP?



А Вы не знаете, что существует Modbus over TCP?

Честно отвечу- не знаю такого. Всегда думал, что Modbus- это или RS-485 или RS-422. Hо, чтобы гонять кадры Modbus в Ethernet- это выше моего воображения. Расскажите.

Покурите это - http://modbus.org/docs/Modbus_Messaging_Im...Guide_V1_0b.pdf