Удаленный мониторинг. Основные компоненты системы

Динамический или статический IP для удаленного сбора данных

Для того чтобы установить двунаправленную связь (центральный объект может напрямую запрашивать регистраторы данных и наоборот), лучше всего, если модемам сотовой сети на удаленных объектах и серверу системы SCADA будут назначены внешние IP адреса. Однако, пока стоимость статического IP адреса для устройств сотовой сети больше, чем для частного, динамического IP адреса, эта установка сразу приведет к увеличению стоимости проекта.

Тем не менее, использование специально созданного программного обеспечения OPC дает возможность настроить удаленные устройства на автоматическую регистрацию самих себя в управляющей SCADA системе, которая использует фиксированный IP адрес. В этом случае SCADA сможет получать и регистрировать IP адреса удаленных устройств, а также соответственно возможность передавать или обновлять запись тегов. Такое взаимодействие является простым и экономически выгодным способом управления удаленных устройств через сотовую сеть. Дополнительное использование регистрации данных с помощью OPC сервера дает возможность использовать динамическое DNS регистрирование, где удаленное устройство преобразует свой динамический или частный IP адрес в DNS имя хоста (т.е. URL ). В этом случае главному программному обеспечению необходима только база данных URL для связи с удаленным устройством HSPA .

Активная передача данных оптимизирует использование полосы пропускания и помогает ликвидировать простой сети

Когда пользователь решает использовать сотовые сети, самым важным и очевидным вопросом является: «Сколько это будет стоить?». В традиционной ориентированной на автоматизацию среде операторы используют устройства PLC для получения данных и в этом случае пропускная способность не является проблемой, т.к. PLC является обычно частью локальной, проводной инфраструктуры. Для удаленных приложений, работающих через сотовую связь, пропускная способность имеет определенную стоимость и это является большой проблемой. Поэтому опросные архитектуры системы плохо подходят для сотовой сети.

Активная push -связь устраняет необходимость опроса сервером, что значительно снижает нагрузку на сеть и позволяет сократить расходы, связанные с развертыванием системы сотовой связи. Без опроса сервера удаленные устройства активно отправляют данные центральному серверу по своей инициативе. Таким образом, данные передаются один раз от датчиков или систем предупреждения на объекте; изменение данных отправляется в базу данных управляющей системы, где оператор затем может просматривать отчеты.

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

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

Активные передачи данных оптимизируют уровни передачи данных и снижают затраты на обслуживание

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

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

Действенное, эффективное программирование для улучшенного удаленного мониторинга

Для комплексного подхода не предоставляется ничего более гибкого, чем эффективная платформа программирования. Платформа программирования используется для приложений, требующих высочайшего универсального уровня в программировании, таких как пользовательские протоколы, комплексные вычисления и запись данных. Программируемые сотовые RTU контроллеры, которые поддерживают языки программирования C / C ++ или стандарт IEC 61131-3 (которые включают в себя ряд инструментов Linux ), могут быть эффективно настроены для быстрого решения многообразных требований пользователя. Среда программирования помогает пользователям сэкономить время на установку и настройку, снижая накладные расходы на программирование в таких ключевых областях, как контроллеры ввода/вывода, средства предупреждения и управление сетевой связью, в которую входит сотовая связь и SMS , а также на совместимость с существующими системами SCADA / DB . По сравнению с другими платформами программирования, Linux и IEC -61131-3 совместимы с сотовыми устройствами RTU , предоставляя максимальную гибкость кодирования, а оптимизированная с помощью предоставляемого программного обеспечения установка контроллеров ввода/вывода и сигналов тревоги становится проще и быстрее чем когда-либо до этого.

Возможность установить сбор данных в реальном времени в удаленной среде, которая имеет ненадежную инфраструктуру связи, очень важна, так как операторам необходима информация в реальном времени для принятия решений, которые влияют на распределение ресурсов и доставку. Обычно операторы используют регистраторы данных для хранения информации о событиях (для PLC сетей, например, база данных это полный набор данных полученный опросом за определенный период времени), с возможностью её получения при просмотре базы данных. Это очень неэффективный способ управления удаленными объектами, тем более что это может привести к дублированию полученных данных и созданию многоуровневых сетей, в которых надо будет разбираться операторам.

Специалист по маркетингу Moxa Inc.

RMON, или база управляющей информации для удаленного мониторинга (Remote MONitoring MIB), был разработан IETF для поддержки мониторинга и анализа протоколов в локальных сетях Ethernet и Token Ring. Эта стандартная спецификация обеспечивает во многом те же функциональные возможности, что и нестандартные сетевые и протокольные анализаторы.

Начало работ над RMON-1 MIB было положено созданием IETF рабочей группы RMON в 1990 году. Предложение по стандарту было опубликовано в RFC 1271 в ноябре 1991 года, причем оно касалось исключительно Ethernet (см. Таблицу 1). Дополнительная группа для Token Ring была предложена в RFC 1513 в 1993 году. С появлением совместимых реализаций RMON-1 MIB был присвоен статус проекта по стандарту в RFC 1757 в 1994 году. Летом того же года рабочая группа RMON-2 занялась подготовкой стандарта для расширения RMON-1. Ее усилия нашли впоследствии свое отражение в RFC 2021 и 2074.

RMON В СРАВНЕНИИ С SNMP

При всех своих неоспоримых достоинствах инфраструктура SNMP имеет ряд существенных недостатков с точки зрения ее применения в крупных корпоративных сетях. В соответствии с принятой моделью станция управления сетью через регулярные интервалы времени опрашивает своих агентов о значениях всех счетчиков. Объем управляющего трафика таков, что он сам по себе может вызвать заторы, особенно если передается по каналам глобальной сети. Кроме того, вся тяжесть сбора и обработки информации возлагается на станцию управления, причем сложность возрастает пропорционально увеличению числа управляемых устройств. Однако наиболее серьезный недостаток исходной спецификации SNMP состоит в том, что базы управляющей информации MIB-1 и MIB-2 предоставляют данные только по каждой наблюдаемой системе в отдельности. Так, менеджеры SNMP могут предоставить данные об объеме входящего и исходящего трафика для конкретного устройства, но не картину трафика во всем сегменте, а тем более во всей сети (во всяком случае они не могут получить эту информацию непосредственно от своих агентов).

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

Исследование McConnel Consulting показывает, что, по сравнению с традиционными инструментами управления, применение RMON позволяет тому же административному персоналу поддерживать в два с половиной раза большее число пользователей и сегментов (правда, такой выигрыш достигается лишь в относительно крупных сетях).

АРХИТЕКТУРА RMON

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

СТРАТЕГИЯ ИСПОЛЬЗОВАНИЯ

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

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

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

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

МОНИТОРИНГ КОММУТИРУЕМЫХ СЕТЕЙ

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

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

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

Оригинальный подход был предложен компанией 3Com в ее Desktop RMON - программные агенты устанавливаются непосредственно на рабочую станцию и используют ее ресурсы для сбора статистики (при этом сетевая плата должна работать в режиме приема всех пакетов). Такое решение позволяет разгрузить коммутатор и собирать статистику об его работе в полном объеме - для этого программное обеспечение достаточ-но установить хотя бы на одну станцию в сегменте.

RMON-2 В СРАВНЕНИИ С RMON-1

Однако RMON-1 имел свои ограничения. В частности, из-за того, что он функционировал на уровне MAC, зонд RMON не мог определить действительного отправителя пакета, попавшего в локальный сегмент через маршрутизатор. Образно говоря, кругозор RMON-1 ограничивался одним сегментом на уровне МАС. Чтобы иметь возможность определить отправителя (или получателя) трафика по другую сторону маршрутизатора, зонд или агент должен уметь идентифицировать трафик на сетевом уровне. Это позволило бы ему предоставлять статистику по всем хостам, кто только обращается в сегмент, независимо от их местонахождения. С этой целью стандарт RMON-2 определяет спецификацию для мониторинга сетевого трафика на сетевом уровне и выше.

RMON-2 не является надмножеством или заменой для RMON-1 - они логически дополняют друг друга (см. Рисунок 1). Так, наиболее предпочтительное место для зондов RMON-1 - сегмент, где они будут полезнее всего для выявления физических ошибок, сбора статистики по станциям и т. п.; а для зондов RMON-2 - магистраль, где они находятся в наилучшем положении для сбора статистики о картине трафике на сетевом и прикладном уровнях.

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

ЧТО МОЖЕТ RMON-2?

Наиболее очевидная и привлекательная возможность RMON-2 - это мониторинг трафика на сетевом и прикладном уровнях. Стандарт определяет еще девять групп (см. Таблицу 2). Ниже мы кратко рассмотрим, зачем каждая из них нужна и какую информацию администратор может извлечь из содержащихся в них данных.

Группа Protocol Directory позволяет управляющему приложению узнать, какой протокол (или протоколы) реализует конкретный агент. Такая информация просто необходима, если приложение и агент написаны разными разработчиками.

Группа Address Translation устанавливает связь между адресами сетевого и MAC-уровней. На основании этих данных администратор может, например, выявить, какие станции имеют одинаковые IP-адреса.

Группы Network-Layer Host, Network-Layer Matrix, Application-Layer Host и Application-Layer Matrix предназначены для сбора статистики о трафике хостов и пар хостов на сетевом и прикладном уровнях. На основании этой статистики администратор может установить, какие клиенты с какими серверами общаются, так что системы могут быть перераспределены между сегментами сети для оптимизации потоков трафика.

Группа User History Collection позволяет администратору самому настроить сбор статистики за определенный период времени по любому из имеющихся счетчиков, например для файлового сервера или соединения между маршрутизаторами (в RMON-1 это можно было сделать только для предопределенных счетчиков), а группа Probe Configuration - удаленно конфигурировать зонд другого разработчика.

ПРАКТИЧЕСКИЙ ПРИМЕР

В своем исследовании "Методология RMON. На пути к успешному внедрению распределенного управления" Джон МакКоннел, глава McConnel Consulting, приводит ряд любопытных примеров применения RMON на практике.

Муниципалитет одного американского города столкнулся с тем, что периодически время отклика серверов возрастало до недопустимых пределов. Сначала пользователи сообщали о невозможности доступа к серверам UNIX по TCP/IP. По истечении часа или около того подобные проблемы начинали возникать с другими протоколами и сервисами. В конце концов, администратор вынужден был перегружать серверы. Однако по прошествии какого-то времени проблема возникала снова.

В результате администратор решил установить в локальной сети несколько зондов RMON. Он тут же обнаружил, что доля широковещательных пакетов составляла свыше 40% от всего трафика. Исходя из этого администратор настроил фильтры на зондах для сбора только широковещательных пакетов. Это позволило установить, что несколько серверов посылают запросы ARP неоправданно часто. Настроив фильтры на сбор пакетов в процессе диалогов между конкретными парами серверов и клиентов, он установил, что на каждый запрос клиента сервер посылает не ответ, а запрос ARP.

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

ВМЕСТО ЗАКЛЮЧЕНИЯ

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

Дмитрий Ганьжа - ответственный редактор LAN. С ним можно связаться по адресу:

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

Мониторинг удаленных компьютеров

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

Кроме мониторинга, программа также предлагает удаленные инструменты для вмешательства. Среди прочего, она позволяет администратору отправлять сообщения на удаленный компьютер или искать файлы, прекращать выполняемые процессы или делать снимки экрана. Такие функции можно использовать на всех клиентах одновременно: например, если выбрать команду «Запустить программу» (Run program) в AIDA64 и набрать «Блокнот», Блокнот Windows откроется на всех компьютерах в сети.

Удаленная системная информация

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

Удаленный контроль

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

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

AIDA64 Business всегда сообщает пользователям компьютера об установлении администратором удаленного подключения к их компьютеру.

Что говорят клиенты?

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

Габор Хайду, начальник ИТ-отдела,
Érd és Térsége Water Company

Если вас интересует мнение других клиентов о программе AIDA64,

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

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

Агенты сами устанавливают исходящие соединения с сервером. Они являются идеальным решением для сотовых и спутниковых сетей, которые не предоставляют белых IP-адресов. Эта же технология решает проблемы с брандмауэрами/NAT, типичные для промышленных сетей.

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

Отобразите устройства, группы, маршрутизаторы, геозоны, соединения и другие объекты на географических картах, использующих любой источник, например, Google Maps, Bing Maps, OpenStreetMap и другие. Добавляйте уровни, элементы управления и селекторы к вашим картам и визуально создавайте любые операторские интерфейсы.

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

Все коммуникации между сервером и агентами проходят через защищенные SSL-соединения и сжимаются для того, чтобы соответствовать GPRS/3G/LTE и спутниковой связи. Агенты достаточно умны, чтобы по необходимости посылать только важные события вместо необработанных значений метрик.

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

AggreGate поддерживает огромное количество коммуникационных протоколов , включая M2M/IoT, ИТ и протоколы автоматизации, а также общие протоколы, такие как SQL и SOAP. Если операции записи или управления поддерживаются каким-либо протоколом, AggreGate может их использовать.

Подключайтесь к системам контроля доступа, пожарной сигнализации, защиты периметра и другим системам безопасности для получения предупреждений об опасности и инцидентов через стандартные протоколы (SOAP, SQL, CAP, SNMP и т.д.) или собственные API. Создайте централизованное управление инцидентами безопасности и опрос систем, контролируйте порядок, используя автоматизацию и данные используемых сетевых устройств.

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

Как часть экосистемы AggreGate, Network Manager обеспечивает комплексный мониторинг инфраструктуры M2M/IoT-сетей. Функционал продукта включает автоматическое обнаружение сети, отображение L2/L3, аппаратные средства сервера и контроль операционных систем, консолидацию сетевых событий через ловушки SNMP и сообщения Syslog, корреляцию событий и анализ первопричин, возможности моделирования бизнес-услуг и обнаружение нарушений SLA, а также контроль приложений, услуг, баз данных, голосовых сетей, беспроводной инфраструктуры в рамках одного коробочного решения.

Добавьте свойства клиентов к сетевым устройствам и системным ресурсам, используйте таблицы свойств с желаемой структурой любого размера/длины. Возможность проведения инвентаризации, используя коробочное решение, с определением серии, ответственных людей, изменений, расположения, событий и т.д. Расширьте возможности системы по тревогам и событиям информацией, взятой у любой сторонней системы инвентаризации, используя любой протокол (SQL, SOAP, и т.д.).

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

IoT-платформа AggreGate предлагает много инноваций в технологии M2M/IoT. Это обеспечивает создание объединенной модели данных, которая включает нормализованные представления разнообразных аппаратных средств и представляет данные устройства для внутренних инструментов обработки/визуализации и внешних систем.

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

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

Используйте наши Java и.NET API с открытым исходным кодом, чтобы расширить возможности вашего IoT-решения и легко