И ни к чему пром.железо нагружать тем, что не несет великой пользы для скорости реакции на события. Сейчас он и добавляется в поддерживаемые протоколы. Но не используется.
т.е. получить сообщение, молде там слипает плк по питанию, ошибкам на интерфейсе и пр, сильно хуже чем бегать и искать когда оно отвалилось? по сути это тренд. неминуемый.
ну отчего же. есть например связка ELK, которая визуально может га исторической перспективе дать много информации, понятно это можно вытащить и из opc/scada, но непонятно почему не напрямую
какие-то религиозные предубеждения 80х гг когда запрос snmp был сложен для контроллеров. не отказываемся , но не понятен полный игнор вполне себе хорошего инструмента. подчеркну для мониторинга в режиме RO.
Комментарии: 22
Anonim
Можно. Он больше к сетевикам относится. Мониторинг сетевого оборудования, ЦОД, ИБП, забикс и вот это вот все.
Sergei
возникает вопрос почему? проще ведь с дашборда мониторить ошибки и получать сообщения чем узнавать по факту в режиме пожара.
Anonim
Потому что изначально дашборды и прочие радости сетевиков не использовались в АСУ ТП.
Sergei
ну изначально и eth не было ведь. сейчас же оно есть.
Anonim
И ни к чему пром.железо нагружать тем, что не несет великой пользы для скорости реакции на события. Сейчас он и добавляется в поддерживаемые протоколы. Но не используется.
Evgeniy
По Snmp ИТ конторы любят мониторить используемое оборудование, трапы им подавай))
Sergei
т.е. получить сообщение, молде там слипает плк по питанию, ошибкам на интерфейсе и пр, сильно хуже чем бегать и искать когда оно отвалилось? по сути это тренд. неминуемый.
Anonim
Что мешает получить эти же данные по другому пром.протоколу? Пример расчета времени опроса 100 регистров: Modbus TCP: Один запрос: Заголовок (7 байт) + Данные (6 байт) = 13 байт. Ответ: Заголовок (7 байт) + Данные (2×100 + 2 байт) = 209 байт. Общее время: (13 + 209) × 8 / 100 Мбит/с ≈ 0.018 мс (без учета задержек TCP). SNMP (100 отдельных OID): 100 запросов GET: (48 байт запрос + 60 байт ответ) × 100 = 10,800 байт. Общее время: 10,800 × 8 / 100 Мбит/с ≈ 0.864 мс (без учета задержек UDP).
Sergei
в ручной поделии, зачем пилить свой велосипед, когда snmp с oid это многолетний (десятки) протокол. oid пилит вендор, инструментов считывания миллион.
Anonim
Что-то не припомню сходу бюджетных панелей (HMI), поддерживающих SNMP
Evgeniy
Так оно для АСУ ТП и нахер не сдалось
Anonim
Именно.
Evgeniy
Так, бедолагам ИТ-шникам для смежных дел)
Sergei
и как указанное мониторинга вляиет на решение, если ты смотришь график с историей в дни часы месяцы и видишь поведение системы.
Anonim
Или связку ПЛК, общающихся между собой по нему. Добавь графики дней часов и прочее по пром.протоколу. В чем разница?
Sergei
инструментах и скорости их развития.
Anonim
Из разряда Мне так удобней - используйте все и добавляйте во все устройства.
Sergei
ну отчего же. есть например связка ELK, которая визуально может га исторической перспективе дать много информации, понятно это можно вытащить и из opc/scada, но непонятно почему не напрямую
Anonim
В общем дружно отказываемся от CAN, Modbus, Profinet, HART, LON, OPC UA, BACnet и переходим на SNMP. А то развели тут солянку.
Sergei
какие-то религиозные предубеждения 80х гг когда запрос snmp был сложен для контроллеров. не отказываемся , но не понятен полный игнор вполне себе хорошего инструмента. подчеркну для мониторинга в режиме RO.
Anonim
Для мониторинга в режиме RO все его и используют, коих немного. В чем вопрос то?
Sergei
выше же задал, ответ увидел. редкий зверь для асутп.