Опубликовано: 09 Марта 2009
Начнем с того, что это не революция, а скорее эволюция. Процесс идет уже не первый год, но по сей день доля контроллеров СКУД с Ethernet-интерфейсом не так уж велика на рынке. По крайней мере, до сегодняшнего дня они не являются доминирующими.
Таким образом, мигрирование систем доступа в этом направлении вполне объяснимо, при этом неспешность процесса объясняется не только и не столько необходимостью новой разработки, сколько консерватизмом отрасли безопасности, да еще опасением, что через общую сеть появится новая «дырка», повышающая уязвимость как со стороны злоумышленников, так и со стороны разного рода случайных сбоев в работе в общем-то «чужой» сети.
Как же можно сэкономить на проводах и включиться в общую «паутину»? Путей несколько. Самый простой путь, который пытались использовать на практике передовые инсталляторы еще несколько лет назад, состоит в использовании аппаратных шлюзов, позволяющих реализовать через Ethernet виртуальный СОМ-порт. Такие устройства производятся достаточно давно различными компаниями, в частности, для систем промышленной автоматизации. Наиболее эффектным решением можно считать устройство под названием X-Port от компаии Lantronix (рисунок 1). Это устройство полностью выполнено в корпусе розетки Ethernet – разъема, устанавливаемого на печатную плату целевого устройства. Существует также множество внешних устройств, похожих внешне на стандартные сетевые коммутаторы, которые можно включить между кабелем Ethernet и контроллером системы доступа. В литературе все устройства данного класса чаще всего называют асинхронными серверами. На рисунке 2 представлена схема подключения стандартного контроллера СКУД через такой сервер.
Рисунок 1. Конвертер Ethernet в СОМ – порт.
Рисунок 2. Подключение через асинхронный сервер.
Итак, мы получили возможность подключать контроллеры СКУД к ПК, на котором работает ПО системы доступа, через общую (а может, и выделенную) сеть Ethernet. Какие проблемы могут нас ждать на этом пути? Проблемы эти, как правило, появляются при работе в общей сети, которую администрирует сисадмин IT-отдела, у которого свои взгляды (и, как правило, небезосновательные) на то, как должна работать корпоративная сеть, какие протоколы и порты разрешать или запрещать в разных сегментах сети. Посмотрим сначала, насколько СКУД может использовать те или иные сетевые протоколы. Их не так уж и много – это UDP, TCP/IP и HTTP.
Самый быстрый и ненакладный протокол. Позволяет обмениваться пакетами размером не более одного Ethernet-кадра (примерно 1500 байт). Но нам и этого за глаза хватит – в СКУД контроллер редко обменивается с ПК-пакетами размером более 100 байт. Таким образом, за счет скорости и простоты UDP – первый кандидат на использование в системе реального времени. Не случайно многие сетевые протоколы систем промышленной автоматизации работают именно на нем. Недостаток UDP – отсутствие гарантированной доставки сообщений – легко обходится теми же методами, что и при работе с RS-485: квитированием, т. е. передачей подтверждения приема каждого пакета.
Данный протокол обеспечивает гарантированную доставку, сам умеет на передающей стороне «резать», а на приемной «склеивать» большие пакеты данных, но это нам не очень нужно. Зато он менее расторопен и намного более накладен в программной реализации. Преимущество его только в том, что чаще всего по умолчанию проходит через корпоративные коммутаторы и маршрутизаторы.
Это самый медленный из протоколов, он «надстроен» над TCP/IP и используется в качестве основного в WEB, т. е. именно с его помощью мы получаем информацию из Internet. Из этого следует, что он проходим практически в мировом масштабе, в чем его определенное преимущество. Но в системах реального времени его применение практически невозможно из-за медлительности.
Из краткого обзора очевидно, что для систем реального времени, какими являются системы управления доступом, предпочтительнее использовать протокол UDP. Если у вас простейшая сеть, то это вообще не вызовет никаких проблем, все будет замечательно работать, причем на прекрасной скорости. Если сеть немного посложнее, да еще системный администратор «позакрывал» лишние порты и протоколы, система работать не будет, пока указанные ограничения, направленные на IT-безопасность, не будут сняты. Точно так же не будет работать и Internet, если закрыть для прохождения пакеты, адресованные на порт номер 80.
VPN – Virtual Private Network, или по-русски виртуальная частная Ссеть. Это неплохое изобретение, позволяющее через сети общего пользования передавать любые данные по любым стандартным протоколам. Если вам сказали, что использовать на садовом участке синюю трубу нельзя, а вам ну очень уж хочется, то вы можете взять разрешенную трубу красного цвета немного большего диаметра и в нее засунуть свою синюю трубу. Вот так, образно говоря, работает VPN. А поскольку это мировой стандарт, то при организации связи в любых сетях проблем практически не будет – по крайней мере, проблемы эти всегда разрешимы.
Итак, мы (а точнее – суровая реальность) отвергли протокол HTTP как средство коммуникации для систем реального времени. Вместе с тем именно на базе этого протокола уже реализуют новый и достаточно интересный функционал в СКУД. Во-первых, есть задачи, не требующие реакции в течение долей секунды. К таким задачам, например, относится формирование и просмотр отчетов о работе системы (контроль посещений, учет рабочего времени и т. д.). А поскольку протокол обеспечивает проходимость по любым сетям в мировом масштабе, мы получаем возможность смотреть отчеты из любой точки Земного шара. Единственное, что для этого требуется – это «дооснастить» ПО системы доступа небольшим WEB-сервером, который и обеспечит связь между базой данных событий системы и клиентом на другой стороне всемирной «паутины».
Автор: Леонид Стасенко, группа компаний «Релвест»
Источник: Журнал ТЗ №6 2008
Сайт: www.tzmagazine.ru
Добавить комментарий