Думаю, сегодня никого не нужно убеждать в необходимости постоянного мониторинга сети и устройств, входящих в нее. Даже если, скажем, сервер уже давно работает без сбоев, это не означает, что какие-нибудь «доброжелатели» не произведут ДДОС-атаку на него. В этом случае, единственное, что спасет от вероятных убытков - это быстро предпринятые действия администратором. А как узнать, что сервер перестал отвечать? Ну, можно периодически заходить на его web-сервер или подключаться к FTP. А как часто вы будете это делать? А не забудете ли? А если домой ушли или лежите с гриппом в постели?
Да, минусов в таком подходе хоть отбавляй. Но ведь можно же как-то автоматизировать свой труд? Вот как раз для этого и была разработана программа визуального мониторинга сети 10-Strike LANState Pro .
По сути, эта программа – глаза системного администратора и его рабочий стол . Пока админ занят выполнением своих многочисленных обязанностей, LANState Pro будет неусыпно следить за работой вверенных ему сервисов и сетевых устройств. И в критической ситуации сообщит о проблемах своему хозяину. Как сообщит? Ну, может сирену проиграть, а может и SMS отправить на заданный номер телефона. Для этого нужно либо старый мобильник подключить к компьютеру с LANState Pro, либо узнать у оператора сотовой связи, на какой адрес отправить электронное письмо, чтобы оно пришло как SMS на телефон. Во втором случае программе будет нужен доступ в Internet.
Кроме всего, пожалуй самым главным достоинством LANState Pro является то, что она умеет показывать вашу сеть в графическом виде, как вы привыкли видеть её в проектной документации. Каждый тип устройства имеет свой значок, который может быть соединен линиями заданного стиля, цвета и толщины с другими. Но самое главное - значок может меняться в зависимости от состояния закрепленного за ним физического устройства. Выключился компьютер – его значок на карте сети «потух». Включился – значок вновь заиграл цветами. Не даром же говорят, что лучше один раз увидеть, чем много раз услышать. Ну, в данном случае, админ скорее всего услышит вопль недовольного пользователя или начальника. Дабы не доводить до такой крайности, лучше быстро решить проблему. А на карте всё и видно, где что перестало работать.
Это конечно всё хорошо, если организация находится в одном здании и сеть одна, скажете вы. А если есть много филиалов и все они в разных частях города, да вообще, в разных городах? Как тогда увидеть карту их сетей и состояние устройств? Да запросто!
Как правило, между филиалами установлена связь по VPN или как-то еще. Если доступ к компьютерам филиала есть из центрального офиса хоть по какому-то протоколу (пусть пингуются хотя бы), то проблем нет никаких – создаете несколько карт сетей и программа их мониторит одновременно. Между картами можно быстро переключаться, используя специальные значки-линки.
А если нет VPN? Проблема? Нет – опять не вопрос, LANState Pro и тут «стреляет». В программе реализован встроенный web-сервер , с помощью которого вы можете просматривать карту сети в окне браузера. Всё, что нужно для этого – это наличие физического сервера в филиалах, с доступом к нему по HTTP-протоколу через Internet (или свой канал, опять же). Схема мониторинга в данном случае выглядит так:
1. Устанавливаете программу LANState Pro в каждом филиале на web-сервер или компьютер, который доступен из центрального офиса по HTTP. Создаете карту сети, настраиваете мониторинг. В настройках программы включаете web-сервер, задаете порт, авторизацию, фильтр IP-адресов и т.д.
2. В центральном офисе через браузер подключаетесь к web-серверу каждого филиала и лицезреете карту сети с состоянием устройств на ней. Причем, выбрав в меню значка определённый пункт меню, можно увидеть график времени отклика и детальное состояние тестовой проверки, с диагностическими сообщениями.
Всё, за два действия вы получаете систему мониторинга сети территориально-распределённой организации. Перестало что-то работать в филиале – получаете письмо на e-mail или SMS. Открываете браузер – визуально оцениваете ситуацию, планируете свои дальнейшие действия. И всё это происходит оперативно. Чем меньше время простоя оборудования – тем меньше вероятные финансовые потери. А в некоторых случаях, программа может попытаться исправить возникшую проблему даже без участия администратора. Например, перезапустить сбойную службу, перезагрузить компьютер, выполнить какое-то специальное внешнее приложение или скрипт, которое самостоятельно решит проблему, в конце концов. Возможностей в программе масса.
При этом простота внедрения и настройки программы 10-Strike LANState Pro создает ей преимущество перед бесплатными, но сложными в настройке opensource-проектами.
Работа с картой сети в веб-режиме:
Просмотр графиков времени отклика устройств через веб-интерфейс:
Просмотр списка проверок мониторинга устройств:
Контекстное меню карты:
Скачайте бесплатную 30-дневную версию прямо сейчас и попробуйте!
Если вам необходимо средство для полноценного мониторинга и управления вашим компьютером через мобильное устройство, то PC Monitor - это то, что вам нужно. Сейчас я вкратце расскажу о принципе действия этого сервиса: на сайте разработчика вы скачиваете программу-клиент для того компьютера, который вы хотите мониторить и которым желаете управлять удалённо. После скачивания и установки ПО вам будет предложено создать свой аккаунт для использования системы. После этого остаётся лишь скачать приложение под операционную систему вашего мобильного устройства и авторизоваться в системе.
Теперь о поддерживаемых платформах. Мониторить и управлять можно компьютерами с установленными ОС Windows XP и более поздними версиями, а также популярными дистрибутивами Linux. Совсем немного огорчает отсутствие поддержки Mac OS. Ниже представлены прямые ссылки на скачивание клиента для различных версий ОС:
Среди поддерживаемых платформ для устройств, с которых осуществляется мониторинг и управление удалённым компьютером, присутствуют iOS версии 4.0 и выше, Android версии 2.1 и выше, а также Windows Phone 7. Загрузить мобильный клиент для вашего устройства вы можете по этим ссылкам:
- PC Monitor для Android (версия для смартфонов и планшетов)
- PC Monitor для iOS (iPhone, iPad и iPod Touch версия)
Ещё больше радует возможность управлять компьютером с любого другого компьютера через специальную панель администратора, которую можно скачать (Windows 32 bit) и (Windows 64 bit). Или же просто авторизуйтесь в сервисе через любой веб-браузер и управляйте вашей системой.
Бесплатная версия позволяет одновременно работать с тремя компьютерами. Если вам необходимо работать с большим количеством машин, то придётся купить дополнительную лицензию. Стоимость варьируется от €59 в год за 10 компьютеров до €399 за 100 компьютеров.
А теперь о том, что же может мониторить эта программа:
- Статус и аптайм всех ваших компьютеров
- Текущая загруженность ЦП и памяти с возможностью просмотра статистики нагрузки
- IP адрес вашего компьютера и местоположение, определяемое GeoIP
- Пинг к вашему компьютеру с возможностью просмотра статистики
- Статус и просмотр жёстких дисков
- Статус сервисов и служб
- Статус сетевых интерфейсов с возможностью просмотра статистики
- Запущенные в данный момент процессы
- Лог событий в системе
- Статус запланированных задач
- Список всех авторизовавшихся в системе пользователей (локальных и удалённых)
- Информация о состоянии железа (температура ЦП, жёстких дисков, скорость вращения кулеров)
- Поиск и просмотр групп, аккаунтов пользователей и их статусов в Active Directory
- Счётчик производительности системы
Ниже представлены некоторые из действий, которые вы можете совершать удалённо:
- Запуск и остановка любой службы
- Завершение процессов
- Запуск и остановка запланированных задач
- Отключение любого пользователя от системы
- Отправка сообщений всем авторизованным в системе пользователям
- Использование командной строки
- Перезагрузка, выключение и включение компьютера
- Управление группами, аккаунтами и паролями пользователей в Active Directory
- Поиск и установка обновлений Windows
- Мониторинг и управление Exchange
- Поддержка Hyper-V
- Управление списком мобильных устройств, которые могут отправлять системные команды на компьютер
Программа может присылать уведомления о событиях, происходящих на компьютере:
- Незапланированная остановка сервиса
- Вход различных пользователей в систему
- Отклонение от нормальных значений показателей пинга, загрузки ЦП и памяти, заполненности жёсткого диска, показателей железа
- Определённые события в логе системы
Огромным плюсом является использование SSL для связи компьютера и мобильного устройства, что значительно повышает уровень безопасности. В целом сервис представляет собой полноценную систему для удалённого мониторинга и управления вашими компьютерами с помощью мобильных устройств и других компьютеров, обладающую широким функционалом и множеством полезных возможностей. Настройка не составит большого труда и осуществляется очень быстро. При возникновении трудностей всегда можно обратиться к руководству на сайте разработчика.
Дмитрий Ганьжа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 администратор может реализовать превентивное управление своей сетью, т. е. выявлять проблемы до их возникновения. Ключом к реализации такой стратегии является установление типичной картины трафика и задание порогов для предупреждения об отклонении трафика в сети от стандартных шаблонов.
Таблица 1. Группы RMON для Ethernet |
|
Название | Описание |
Statictics | Статистика по числу октетов и пакетов (в том числе многоадресных и широковещательных), об ошибках и размере пакетов. |
History | Распределение переменных первой группы за определенный период через заданные интервалы. |
Host | Информация о трафике по каждому хосту в сегменте. |
Host TopN | Отсортированные данные по указанному числу хостов в порядке убывания. |
Matrix | Статистика по диалогам между парами хостов, в том числе о величине трафика и количестве ошибок в обоих направлениях. |
Filter | Определения шаблонов для сбора пакетов. |
Packet Capture | Сбор заданного числа пакетов, отвечающих указанному шаблону. |
Alarm | Пороги для счетчиков для сигнализации об изменениях в функционировании сети. |
Event | Протоколирование событий и определение действий при их наступлении. |
Прежде всего администратору требуется в течение определенного времени собрать данные относительно производительности и использования сети, на которые он мог бы опираться в качестве исходных. Такими данными могут быть, например, сведения о количестве широковещательных, многоадресных и ошибочных пакетов. Затем полученные значения можно усреднить и найти типичные отклонения от этих значений. Найденные отклонения могут служить в качестве ориентиров для задания порогов.
Задание порогов - это целое искусство, и тут администратору может помочь только опыт. Если пороги заданы слишком низкими, то администратор будет получать неоправданно большое количество предупреждений; если же пороги установлены на чересчур высоком уровне, то он может пропустить момент накопления отрицательных тенденций в работе сети. Кроме того, кратковременное отклонение от привычной картины трафика зачастую никак не сказывается на общей работе сети, поэтому задавать пороги следует так, чтобы администратору не приходилось потом отвлекаться на временные самоликвидирующиеся проблемы.
Вместе с тем ни одна сеть не является статичной, поэтому картина трафика со временем изменяется. Анализ тенденций с помощью групп 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 - магистраль, где они находятся в наилучшем положении для сбора статистики о картине трафике на сетевом и прикладном уровнях.
Рисунок 1. Вместе базы управляющей информации RMON-1 и RMON-2 позволяют собирать статистику о трафике на всех уровнях модели OSI.
RMON-2 обладает гораздо более мощными возможностями фильтрации, так как ему приходится работать с трафиком гораздо большего числа протоколов и на более высоких уровнях.
ЧТО МОЖЕТ RMON-2?
Наиболее очевидная и привлекательная возможность RMON-2 - это мониторинг трафика на сетевом и прикладном уровнях. Стандарт определяет еще девять групп (см. Таблицу 2). Ниже мы кратко рассмотрим, зачем каждая из них нужна и какую информацию администратор может извлечь из содержащихся в них данных.
Группа Protocol Directory позволяет управляющему приложению узнать, какой протокол (или протоколы) реализует конкретный агент. Такая информация просто необходима, если приложение и агент написаны разными разработчиками.
Таблица 2. Группы RMON-2 |
|
Название | Описание |
Protocol Directory | Список протоколов, мониторинг пакетов которых зонд может осуществлять. |
Protocol Distribution | Статистика трафика для каждого протокола с информацией о распределении и тенденциях в использовании протоколов. |
Address Mapping | Соответствие между адресами сетевого и MAC-уровней. |
Network-Layer Host | Статистика трафика от и к каждому обнаруженному хосту. |
Network-Layer Matrix | Статистика трафика о диалогах между парами хостов. |
Application-Layer Host | Статистика трафика от и к каждому хосту по протоколам. |
Application-Layer Host | Статистика трафика о диалогах между парами хостов по протоколам. |
User History Collection | Периодические выборки для определенных пользователем переменных. |
Probe Configuration | Удаленная конфигурация параметров зонда. |
Группа 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. С ним можно связаться по адресу:
Обзор
Для разветвленных инфраструктур, расположенных в отдаленных, изолированных местах, использование неуправляемых систем мониторинга было долгое время ограничено предельной дальностью линий связи. Традиционно, радиосвязь использовалась лишь как часть комплексного решения, и несмотря на то, что она доказала свою рентабельность, существенными недостатками были ограничения, связанные с возможной скоростью передачи данных, длительностью времени передачи и повышенной вероятностью потери данных при расширении области передачи.
Появление новейших технологий сотовой связи позволило системным интеграторам найти выход из перечисленных ограничений, предоставляя новые возможности для использования удаленного мониторинга. Для проведения мониторинга и управления коммуникациями через сотовую связь инженеры могут построить удаленно управляемую платформу, которая проста и практична в применении, минимизирует посещение объекта для настройки и обслуживания. Данная платформа может надежно передавать в режиме реального времени информацию как от приложений с высокой пропускной способностью, например с видеонаблюдения, так и критические сигналы тревоги с низкой пропускной способностью.
Задачи и решения
В этой статье мы рассмотрим технические проблемы касающиеся удаленного сбора данных, обратим внимание на приложения, которые связанны с мониторингом и управлением информацией с чрезвычайно удалённых трубопроводов, насосов и периферийного оборудования. Сначала рассмотрим, что должно быть в системах сотовой связи для удаленного мониторинга, а так же предельные возможности и функциональность, необходимые для осуществления данного решения.
Рассмотрим следующие темы:
Почему сотовая связь?
- Динамический или статический IP
- Активная передача данных:
- оптимизация пропускной способности
- предотвращение задержек работы
- оптимизация уровней сбора данных
- снижение затрат на обслуживание
- Гарантированная целостность данных
Почему сотовая связь?
При использовании радиосвязи для управления трубопроводами системные администраторы обычно настраивают блоки удаленных терминалов (RTU – Remote Terminal Unit) так, чтобы регистрирование данных происходило в локальных устройствах хранения, а затем уже отправлялись обслуживающему персоналу для сбора данных. Поскольку данные не передаются в реальном времени, реализация приложений с высокой пропускной способностью, например видео наблюдение, сопровождается трудностями управления ресурсами, которые часто непреодолимы, в то время как дорогостоящие ресурсы должны быть распределены для сбора и анализа данных с удаленных объектов. Как следствие, в настоящее время разработчики обращаются к сотовой связи для более гибкой и эффективной информационной платформы.
Превосходство сотовой сети заключается в том, что она может использовать IP сети, а так как подавляющее большинство полевых устройств сейчас с поддержкой протокола IP, то возможно передавать любые данные через каналы сотовой связи. Но недостаточно использовать только IP средства связи, так как пропускная способность и время задержки также важные составляющие. Так как сотовая связь передает данные через большее расстояние, чем традиционные радио средства связи и средства связи сверхвысокочастотного диапазона, то значительно уменьшается необходимое количество узлов ретрансляции по сравнению с радио системами и системами сверхвысокочастотного излучения. Кроме того, расширенная пропускная способность и улучшенная устойчивость к помехам у сотовых сетей, а также использование информационной инфраструктуры, которая уже установлена у сотовых провайдеров, что позволяет уменьшить количество необходимых точек ретрансляции, позволяет системным операторам сократить расходы на инфраструктуру сети.
После недавнего перехода с GPRS на HSPA сетевые технологии сразу показали значительное улучшение пропускной способности и уменьшение времени задержки в сети. Максимальная исходящая пропуская способность для сотовой сети может достигать приблизительно 5,76 Мбит/сек, входящая пропускная способность может достигать 14,4 Мбит/сек. Также была значительно уменьшена задержка в сотовой сети, при этом в некоторых сетях время задержки достигало всего 100 миллисекунд. По сути дела на сегодняшний день, во всех отношениях производительность сотовой сети превышает почти все другие доступные технологии связи дальнего действия.
Динамический или статический
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
сетей, например, база данных это полный набор данных полученный опросом за определенный период времени), с возможностью её получения при просмотре базы данных. Это очень неэффективный способ управления удаленными объектами, тем более что это может привести к дублированию полученных данных и созданию многоуровневых сетей, в которых надо будет разбираться операторам. Использование сотовой связи предоставляет операторам прямой, в режиме реального времени доступ ко всем удаленным данным. По этой причине оптимизация базы данных также важная часть эффективности системы сбора данных. Оптимизация систем управления базами данных под OPC
решения не только упрощает сбор данных в режиме реального времени, но также автоматизирует преобразование статистических данных в различные форматы и воспринимаемые человеком формы, работая связующим звеном между областью информации и сохраненными базами данных или электронными таблицами. Так как активные сотовые клиенты преобразуют и загружают журнал регистрации данных в центральную базу, оптимизированная система управления базами данных, собирающая информацию, может автоматически собирать теги с отдельных удаленных терминалов и других устройств ввода/вывода в массив данных или электронные таблицы, давая возможность пользователям извлекать данные не только в сыром виде, но и в форме подготовленных отчетов. В итоге, с «
push
» связью, активными тегами и подходящей оптимизацией баз данных, удаленные терминалы должны при сбое в сети автоматически передавать данные, которые были получены при ее отключении.
Сотовые технологии делают возможным использование современных систем удаленного мониторинга
Системы удаленного мониторинга изменились с появлением сотовых сетей. Проще говоря, благодаря сотовым IP
технологиям системы удаленного мониторинга обладают большими возможностями, чем когда либо прежде, снижают сложность системы за счет устранения уровней сбора данных, а это в свою очередь ведет к снижению затрат на управление и обслуживание. Используя сотовые удаленные терминалы следующего поколения от фирмы Моха с поддержкой языков программирования
C
/
C
++ и
IEC
61131-3, с учетом программного обеспечения для разработки приложений, программного обеспечения базы данных
DA
-
Center
и активного
OPC
сервера, возможно быстро и эффективно развернуть удаленные, недорогие решения по сбору данных в режиме реального времени с высокой защитой целостности данных.
Специалист по маркетингу Moxa Inc.
Схема системы удаленного мониторинга и управления параллельной работой ДГУ PowerCommand Network
- RS-232C
- Рабочее место главного диспетчера системы управления
- Модуль ввода-вывода Digital I/O Module
- Панель управления PowerCommand с коммуникационным модулем GenSet Communication Module
- ДГУ1 с панелью управления
- ДГУ2 без панели управления с коммуникационным модулем Controls Communication Module
- Сетевой шлюз Network Gateway Module
- Модем или сетевой интерфейс i.LON 100
- Удаленный экран диспетчера
- Панель переключения
- Система контроля параллельной работы Digital Master Control
PowerCommandTM Network позволяет управлять работой всей системы резервного электропитания и осуществлять удобный мониторинг любых параметров, в том числе при параллельной работе нескольких ДГУ. Все данные о работе двигателей, генераторов, панелей переключения нагрузки и другого оборудования обрабатываются микропроцессором и анализируются в непрерывном режиме.
PowerCommandTM Network работает по протоколам технологии Echelon LonWorksTM, объединяющей систему управления в единое целое посредством обычной витой пары. Значения всех предупреждающих и аварийных состояний могут быть запрограммированы и сохраняются в автоматически ведущихся журналах событий на компьютере диспетчера.
Это действительно удобная полностью настраиваемая система с возможностями дальнейшего расширения и последующей модернизации в соответствии с новыми требованиями и условиями эксплуатации. Диспетчерские экраны мониторинга могут быть самостоятельно модифицированы в соответствии с любыми требованиями.
Полностью автоматизированный сбор и архивирование всех зарегистрированных событий. В систему могут быть дополнительно включены новые объекты мониторинга, такие как зарядные устройства аккумуляторов (контроль уровня заряда), топливные баки (контроль расхода топлива и его текущего уровня) и другие.
Удобный доступ к любому объекту контроля и любому диспетческому экрану одним кликом. Реализация концепции удаленного мониторинга посредством Интернет не потребует существенных дополнительных затрат. Всей информацией диспетчер располагает в режиме реального времени.
PowerCommand Network легко интегрируется в среду Microsoft Windows при помощи комплекта программного обеспечения PowerCommand Software, что делает работу оператора удобной и привычной. Все получаемые системой данные могут быть экспортированы в прикладное программное обеспечение для анализа или последующего архивирования.
PowerCommand Network позволяет настраивать всю систему передачи аварийных и статусных сообщений, в том числе на предварительно заданный телефонный номер, e-mail, пейджер, web-сайт. Описание сообщения может быть отправлено в явном виде или в виде алфавитно-цифрового кода.
Все коммуникационные соединения выполняются обычным неэкранированным проводом типа "витая пара", что не требует существенных затрат и обязательного привлечения высококвалифицированного персонала для монтажа.
P/N | Описание PowerCommand Software для Windows |
PCWL 101L | Локальная версия, без модемной поддержки, до 10 модулей |
PCWL 101U | Локальная версия, без модемной поддержки, модулей неограничено |
PCWL 101L | Сетевая версия, одно рабочее место мониторинга, до 10 модулей |
PCWL 105L | Сетевая версия, от 1 до 5 рабочих мест мониторинга, до 10 модулей |
PCWL 110L | Сетевая версия, от 6 до 10 рабочих мест мониторинга, до 10 модулей |
PCWL 150L | Сетевая версия, от 11 до 50 рабочих мест мониторинга, до 10 модулей |
PCWL 101U | Сетевая версия, одно рабочее место мониторинга, модулей неограничено |
PCWL 105U | Сетевая версия, от 1 до 5 рабочих мест мониторинга, модулей неограничено |
PCWL 110U | Сетевая версия, от 6 до 10 рабочих мест мониторинга, модулей неограничено |
PCWL 150U | Сетевая версия, от 11 до 50 рабочих мест мониторинга, модулей неограничено |
PCWL 100P | Модуль конфигурирования отправки аварийных сообщений на пейджер |
PCWL 100P | Модуль конфигурирования отправки сообщений по списку пользователей |
по запросу | Сетевая версия, свыше 50 рабочих мест мониторинга |
Основные компоненты системы
PowerCommandTM Network может включать в себя несколько дополнительных компонентов, предназначенных для реализации эффективного информационного обмена в используемой LonWorksTM-сети.
Плата-адаптер Multi-Site Communication Module
Представляет собой плату для ПК типа AT-bus с интерфейсом RS-232 для подключения к ПК до 8-ми коммуникационных входов одновременно. При использовании программного обеспечения PowerCommandTM Software для Windows плата Multi-Site Communication Module в состоянии временно сохранять поступающие данные в специальном буфере памяти в том случае, если шина данных переполнена.
Коммуникационный модуль панели управления GenSet Communication Module
Представляет собой плату, предназначенную для подключения панели управления ДГУ к LonWorks-сети удаленного мониторинга и управления. Коммуникационный модуль имеет собственные инструменты конфигурирования, позволяющие отправлять в сеть мониторинга и управления такие, например, параметры, как сигнал аварийного останова или предупреждение о сбое в работе. Для панели управления PCC 2100 разработан специальный коммуникационный модуль.
Коммуникационный модуль Controls Communication Module
Представляет собой плату, предназначенную для подключения ДГУ без встроенной панели управления, а также к автоматической панели переключения или другого оборудования системы к LonWorksTM-сети удаленного мониторинга и управления. Коммуникационный модуль имеет 32 встроенных цифровых входа для статусных и аварийных сообщений, аналоговые входы для контроля параметров температуры и давления, входы контроля напряжения аккумуляторов, аналоговые входы системы мониторинга (4-20 mA, 0-1 mA, 0-5 В), по два реле для сигналов запуска/останова, входы для контроля трехфазного напряжения и тока. Все цифровые входы могут быть сконфигурированы в соответствии с конкретной задачей для реализации процедуры автоматической отправки данных.
Сетевая панель удаленного мониторинга
Выносная панель удаленного мониторинга - сетевое устройство, отображающее основные параметры функционирования системы, такие, например, как наличие основного питания сети, запуск ДГУ и его режим (ручной или автоматический), состояние аккумуляторов, нормальные/аварийные режимы температуры двигателя, масла, охлаждающей жидкости путем нагладной светодиодной и звуковой индикации. Использование сети технологии LonWorks позволяет располагать панель удаленного мониторинга на удалении до 1400 м (при использовании кабель NEMA Level 4, 24 VDC) и производить обмен данных для 16 каналов. Имеется четыре дополнительных пользовательских канала индикации.
Модуль ввода-вывода Digital I/O module
Цифровой модуль ввода/вывода представляет собой устройство, позволяющее реализовать обмен и поступление сигналов с различных датчиков, переключателей и электроприводов в LonWorks -сеть. Все параметры работы устройства поддаются конфигурированию. Каждый цифровой модуль ввода/вывода включает в себя до 16 независимых "сухих" контактов (Form-C), задействующих выходные реле (250 В, 5А), а также до 4 индивидуально программируемых "сухих" контактов.
Сетевой шлюз NetWorks Gateway Module
Сетевой шлюз предназначен для обеспечения подключения персонального компьютера с установленным программным обеспечением PowerCommand Software для Windows к сетевому каналу LonWorks посредством встроенного интерфейса RS-232. Подключение производится с использованием авторизации для предотвращения несанкционированного входа в контролируемую сеть.
Распределительный модуль Junction Box Terminator Module
Распределительный модуль обеспечивает удобный монтаж и ветвление цепей питания оборудования и шины данных. Модуль содержит встроенный терминатор, необходимый для случаев, когда оборудование, задействованное в сети, является концевым и не содержит собственного терминатора. Распределительный модуль содержит два стандартных 6-позиционных блока контактов, два сетевых разъема RJ-45 и конфигурационные переключатели.
Несетевой сериальный интерфейс Single-Site - PSCM
Сериальный коммуникационный интерфейс предназначен для подключения панели управления ДГУ PowerCommand Control к компьютеру посредством шины RS-232. Плата интерфейса устанавливается в короб ДГУ и подключается к панели управления так же, как CenSet Communication Module. Но, в отличие от последнего, не позволяет интегрироваться в LonWorks -сеть. Сериальный интерфейс Single-Site позволяет производить мониторинг и управление ДГУ с использованием PowerCommand Software для Windows локальной версии. Для конфигурирования работы используется специальный инструментарий PowerCommand Serial Configuration Tool (PSCT).
Все сетевые соединения выполняются стандартным неэкранированным кабелем типа "витая пара" 22AWG.
PMCM 100 | Плата-адаптер Multi-Site Communication Module - до 8 коммуникационных входов |
PGCM 100 | Коммуникационный модуль GenSet Communication Module |
PNAM 101 | Панель удаленного мониторинга Network Annunciator Module встраиваемая |
PNAM 102 | Панель удаленного мониторинга Network Annunciator Module для настенного монтажа |
PCCM 100 | Коммуникационный модуль Controls Communication Module для панели ДГУ |
PCCM 101 | Коммуникационный модуль Controls Communication Module для панели переключения |
0541-0770 | Коммуникационный модуль Controls Communication Module для панели PCC 2100 |
PDIM 100 | Модуль ввода-вывода Digital I/O Module |
PNGM 103 | Сетевой шлюз Network GateWay Module - 220B |
PJBT 100 | Распределительный модуль Junction Box Terminator Module |