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