Месяц назад вы писали, что сделали мост TCP/Modbus для доступа, по-видимому, к каким-то технологическим девайсам АСУТП. Иначе, зачем бы вообще заморачиваться на Modbus? Также вы писали, что в каждом удаленном девайсе реализовали HTTP-сервер, который отвечает на запросы Flash-плеера. Я правильно понял ситуацию? Если не очень ошибся, то скажу- это неэффективный путь именно для АСУТП. Я его прошел два года назад и сейчас уверен- для простых приборов в локальной сети не имеет никакого смысла встраивать накрученные стеки с протоколами TCP и тем более HTTP. Хранить Flash файлы или Ajax скрипты в каждом приборе и гонять их в броузер тоже неэффективно. Самое оптимальное по эффективности- обыкновенное UDP. Причем, обойтись можно даже без ARP и IP, а управлять девайсами через Вroadcast посылками на заранее выбранный порт. И это прекрасно работает в локальной сети без всякого пингования.

Давайте все же мух отдельно, котлеты отдельно.

Мост он нужен для того, чтобы существующему у меня ПО общаться с существующими модулями АСУ, у которых физика - RS485, транспорт - Modbus RTU.

Кроме того, мой модуль позволяет организовать обмен с этими модулями со стороны компа средствами HTTP. При этом странички в самом модуле не хранятся, они поднимаются прямо с диска браузером. Единственно что, передается маленький ифрейм для обхода проблем вебсекюрити. Это отдельно.

Отдельно в этом же устройстве реализован функционал пинговалки (то, что нужно было заказчику у истоков этой темы). Статус этой пинговалки можно получить любым удобным вышеописанным способом, и, кроме того, девайс еще и SNMP TRAP'ы рассылает по событиям.

А использование броадкастов, к сожалению, не позволяет организовывать маршрутизацию таких пакетов в сетях, у которых топология содержит роутеры. Точнее, извратиться то можно, но сколько гемора. В чем смысл?

Пространство у нас 7-ми мерное. Базис надо побольше (Читаем теорию струн )

Раскрываю тезис буду формальным, опровергните его если время я не указал. Сеть не управляемая, ну или не совсем управляемая, то есть управляемый коммутатор сделать хабом можно достаточно просто. Я всего лишь пытаюсь доказать, что слабый контроллер и самописный стек приведут к большому количеству ложных срабатываний в год.
И милипиздричный девайс который дергает коммутатором это не путь сетестроения.
Я не знаю на какой ступени пищевой пирамиды вы в телекоме и вообще относитесь к какой либо ступени. Но мои девайсы стоят в большом количестве на сетях, Тфу. Тфу. Тфу. без феерических отказов.

Тогда уж 11тимерное. Только 5 пальцев могут составить базис только в 5тимерном пространстве.



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

И эти люди запрещают нам ковыряться в носу



Зайдите на nag.ru да почитайте у путях сетестроения. Павел Нагибин сейчас, например, вообще от технологий класса CWDM кипятком писяет, а цветные технологии позволяют при вменяемом количестве волокон вообще резко уменьшить количество активки. Там ни Ваши, ни мои девайсы будут не нужны.



Я стою рядом с пищевой пирамидой пионернетов, не хватало еще работать в этих гадюшниках.



Мои тоже. И тоже работают. Так зачем платить больше?

Хе а мы GEPON выпускаем И обзоры товарища Нагибина иногда читаю. Скоро будут GPON решения. Мы работаем просто с телекомами по больше.

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

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

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