| Автор: Леонид СТАСЕНКО, кандидат технических наук, ООО «Диамант Групп» | |
Встречайте — OSDP! | |
| Сегодня, наконец-то, можно говорить о том, что в интерфейсах
периферийных устройств систем безопасности появилось
достаточно интересное и перспективное решение, хотя от роду
ему уже более десятка лет. Речь идет о протоколе OSDP, призванном коренным образом изменить работу с периферией — считывателями СКУД, зонными и релейными расширителями и другими устройствами, без которых функционирование систем безопасности просто невозможно. О чем речь Когда случается что-то, чего долго ждали, есть присказка: «Не прошло и года...». Если смотреть на историю OSDP, то ему уже примерно 13 лет. И проблема не в том, что данный стандарт плох, просто кардинально новые технологии долго пробивают себе дорогу в жизнь по множеству причин. Аналогичная судьба у ныне популярных ZigBee, NFC и многих других решений. Причин тому много, но главное – это трудозатраты, необходимые для перехода от старых, проверенных годами решений, к новым, их заменяющим. И консервативность рынков (и безопасности, в частности) – тоже тому причина. Однако сегодня можно говорить о том, что OSDP наконец-то начинает (только начинает!) свой победоносный путь в жизнь. В статье рассмотрены как общие положения, позволяющие аргументировать достоинства OSDP, так и ряд технических деталей, интересных только специалистам. Каждый сам решит, с какого места перестать читать материал, чтобы не забивать голову непонятной терминологией. От себя могу сказать, что при всех достоинствах протокола как такового, стандарт написан «спустя рукава» – много неопределенностей, противоречий, недосказанности, проблем с форматированием документа (такая уважаемая организация могла бы себе позволить и лучшее) и других проблем, что, однако, не умаляет самой идеи. И надеемся, что по мере расширения применения стандарта редакторские недочеты постепенно будут исправлены. Далее подобные комментарии будут отмечены тэгом «мнение автора» – оно никоим образом не претендует на истину в конечной инстанции, поэтому не должны восприниматься как догма. Когда мы начинали проработку этого протокола, его доступность была очень ограничена, нам, например, пришлось покупать его через заграничных друзей, поскольку американцы не отвечали на наши запросы о покупке стандарта. Сегодня его можно сравнительно легко найти в интернете. Например, «Ардуинщики» выкладывают его в составе своих проектов на GitHub (https://github.com/Bobbbl/Marvin-Arduino). Итак, начнем от простого – к сложному. Что это такое? OSDP – Open Supervised Device Protocol, по-русски примерно так: открытый протокол контролируемых устройств. Открытый – в том смысле, что стандарт могут использовать все заинтересованные компании, за счет чего обеспечивается совместимость оборудования разных производителей. Контролируемых – достаточно важный аспект с учетом того, что отчасти этот протокол должен заменить и wiegand, которому ныне уже более 30 лет. Стандарт разработан ассоциацией SIA (Security Inductry Association — Ассоциация индустрии безопасности), членами которой являются на сегодня более 400 компаний, работающих в сфере безопасности. Большая часть членов ассоциации — американские компании или интернациональные объединения. В частности, почти все известные зарубежные компании, работающие в области СКУД, являются членами ассоциации. Стандарт имеет достаточно длинную историю (первая версия вышла в январе 2007 года). На сегодня действует версия 2.1.7 от 2015 года, а реальное применение протокола в серийном «железе» насчитывает буквально пару – тройку лет. Но, видимо, пришло время массовой замены wiegand и других проприетарных на OSDP. Мы в значительной мере будем проецировать изложение материала на системы контроля доступа, но и в других подсистемах безопасности переход на OSDP прочит получение множества преимуществ. Стандарт охватывает такие предметные области, как считыватели СКУД, биометрические устройства, клавиатуры и дисплеи, в общем, практически любые типы периферийных устройств систем безопасности. Очень важный аспект стандарта – возможность использования криптографии при обмене периферийных устройств с ведущими шинами. Это немаловажно с точки зрения защиты от физических атак на систему. Например, для считывателя с протоколом wiegand имеется только возможность для конкретного считывателя, подключившись к проводам Data0, Data1 эмулировать код карты (если он известен), а для периферийного устройства OSDP возможности намного шире, включая, например, прямое управление замком или турникетом. В основу алгоритма криптообмена положены принципы, используемые для банковских карт, что само по себе уже говорит об уровне защиты. Зачем? Более 30 лет в СКУД используется протокол wiegand, который на сегодня не обеспечивает требуемой функциональности, неудобен при монтаже (требуется минимум 5 — 6 проводов для подключения одного считывателя), длины кабелей не превышают при этом 100 метров, что для ряда инсталляций явно мало. Для связи с другой периферией (охранные клавиатуры, различные модули расширения) до сих пор вообще использовались исключительно проприетарные шины и протоколы. Назначение стандарта – унифицировать обмен контроллеров и охранных панелей с различной периферией (считыватели, расширители, клавиатуры и так далее). Как и любая стандартизация, OSDP позволяет (в принципе) комбинировать разные устройства от разных производителей, что хорошо для конечного потребителя. С точки зрения СКУД, это (наконец-то!) возможность уйти от старого «глупого» wiegand, значительно при этом расширив возможности работы с подключаемым оборудованием. Очень важным для обеспечения совместимости устройств разных вендоров является возможность определения производителя, модели и версий устройств (ID report в стандарте), а также информации об основных возможностях устройства (сколько каких компонентов с какими возможностями содержит периферийное устройство – Capability report в стандарте). Немного подробнее об этом будет сказано далее. Преимущества для монтажников • Позволяет уменьшить количество проводов. • Упрощает монтаж. Преимущества для пользователей • Более дешевый монтаж системы. • Больше функциональности. Преимущества для разработчиков • Шире возможности по конфигурированию и управлению периферией. • Упрощение плат и уменьшение их размеров (при современной элементной базе львиную часть платы контроллера забирают клеммные колодки для подключения периферии). • Возможность использования Plug-and-Play при работе с неизвестным оборудованием. Ниже в таблице дано сравнение ключевых свойств wiegand и OSDP. wiegand OSDP | |
 Как видно из таблицы, все преимущества на стороне OSDP. Как он работает Физический уровень Физическую основу OSDP составляет шина RS-485, давно и хорошо себя зарекомендовавшая как средство коммуникации ведущего (контроллера, охранной панели, компьютера) и подключенных к шине периферийных (ведомых) устройств во множестве областей. В OSDP принимается стандартный формат передачи байтов: 8-N-1 при поумолчательной скорости обмена 9600 бод. Скорость невелика и накладывает ряд ограничений, которые мы рассмотрим позднее, но реально даже на предельных дальностях (более километра) можно работать как минимум на скорости 57600, а на более коротких дистанциях использовать и более высокие скорости. Например, по спецификации RS 485 при дальности в 500 метров скорость уже может составлять более 300 килобод (бит в секунду). Для обмена информацией достаточно одной витой пары (два провода) для обмена со всеми подключенными к шине устройства. Но для реальных устройств требуется питание и желателен «нулевой» провод, поэтому в реальной жизни требуется 4 провода (два сигнальных и два для питания устройств на шине, если они не имеют отдельного питания). Количество устройств на шине может достигать сотни (в зависимости от применяемых микросхем приемо-передатчиков), но в реальной жизни, ввиду ограничений на время отклика, это количество, к сожалению, ограничивается максимум десятком (если говорить о подключении считывателей СКУД). Если же приемлемым временем реакции считать пару-тройку секунд (что, например, может оказаться приемлемым для модулей релейных расширителей, некоторых типов датчиков), то ограничение в 10 устройств исчезает. На рисунке приведена схема подключения устройств по OSDP. | |
 В терминах стандарта, контроллер (ведущее устройство) именуется CP (Control Panel — контрольная панель), а ведомые устройства именуются PD (Perepherial Device – периферийное устройство). Как уже упоминалось, при перечислении преимуществ OSDP (в таблице), любое PD может иметь дополнительные входы и выходы, полностью контролируемые по шине со стороны СР. В качестве примера: считыватель карт может иметь дополнительные входы (например, для подключения дверного контакта и кнопки запроса на выход — ведь считыватель всегда монтируется возле двери), и это не потребует ни одного дополнительного провода от контроллера к двери. Аналогично, считыватель может иметь управляемый со стороны контроллера выход, например, для управления замком. В этом случае возле двери дополнительно может потребоваться источник питания для замка, но, опять же, это не потребует прокладки проводов от контроллера, а кроме того, упростит питание замка на удаленной двери, когда падение напряжения на проводах (если их вести от контроллера) может оказаться столь большим, что потребуется провод очень большого сечения. Транспортный уровень Физический протокол RS 485 используется многими «полевыми» протоколами или шинами, например, хорошо известный ModBus. Транспортный уровень описывает форматы пакетов, передаваемых по шине RS-485 при обмене устройств, и для OSDP он вполне специфический. Ниже представлен общий формат пакета OSDP (с опущенными опциональными полями, используемыми при зашифрованном обмене устройств). SOM ADDR LEN_LSB LEN_MSB CTRL CMD/REPLAY DATA CHECK Каждый пакет начинается с байта SOM (Start Of Message), служащего для разделения пакетов при приеме. Далее следует адрес устройства (ADDR), который может принимать значения от 1 до 0x7E (что позволяет адресовать до 126 устройств). Имеется зарезервированный адрес 0x7F, предназначенный для конфигурирования устройств при инсталляции системы. За адресом следуют два байта длины сообщения, что позволяет теоретически использовать сообщения длиной до 65535 байтов, однако это слишком много для реального применения, в стандарте указано, что все устройства должны уметь принимать пакеты длиной до 128 байтов, но при этом «переваривать» (пропускать без последствий для себя) пакеты, адресованные другим устройствам, с длиной до 1440 байтов. За длиной следует управляющий байт, который выполняет две функции: содержит информацию о наличии шифрования в пакете и типе используемой контрольной суммы, а также содержит номер пакета (пакеты нумеруются для контроля пропуска данных или повторной отправки при обмене). После управляющего байта следует байт кода команды (от ведущего) либо кода ответа (от ведомого). Наконец, за байтом CMD/REPLAY следуют опциональные данные (ряд команд не содержит данных). Завершается пакет либо онобайтовой контрольной суммой по модулю 2, либо двухбайтовой циклической контрольной суммой (более предпочтительный, но несколько более затратный с точки зрения вычислений вариант). Контрольная сумма по модулю 2 является сегодня архаизмом, поскольку на заре появления стандарта еще не сильно были распространены процессоры с мощностью, достаточной для быстрого вычисления циклической контрольной суммы. Сегодня таких ограничений нет, поскольку современные микропроцессоры при стоимости в несколько долларов имеют ресурсы, значительно превосходящие возможности персональных компьютеров 80 х годов прошлого века. Поэтому циклическая контрольная сумма – наиболее предпочтительный вариант в наше время. Как следует из предыдущего описания, минимальный размер запроса по шине и ответа на него (при отсутствии данных) составляет по 8 байт (при использовании циклической контрольной суммы). Для обеспечения возможности периферийному устройству «успеть» начать прием сообщения стандарт рекомендует ведущему начинать запрос с холостого байта. Немаловажными являются требования к временам обмена по шине. В частности, должны выполняться следующие требования: • Передающее устройство должно обеспечить зазор, как минимум, в два символа перед началом передачи — это требуется для обеспечения возможности примопередатчика переключить направление передачи. Это особо важно для аппаратного управления направлением передачи в устройствах с OS типа Linux, не являющейся операционной системой реального времени. • Передающее устройство должно переключить линию на прием не позднее, чем длительность одного символа (байта) после окончания передачи. • Устройство, получившее команду, должно начать ответ не позднее, чем через 200 миллисекунд после получения команды. • Устройство должно переходить в состояние «off-line», если не фиксирует обмена на линии в течение 8 секунд. • Допускается задержка между отдельными символами (байтами) пакета до 20 миллисекунд. Мнение автора: последнее допущение было рассчитано на маломощные микроконтроллеры, сегодня имеется физическая возможность не использовать данное допущение. Основой межпакетной синхронизации является ожидание символа начала пакета (SOM). При этом PD принимает адрес, и если сообщение адресовано ему, то устройство принимает и обрабатывает весь пакет, а если адрес «чужой», то устройство должно его отследить («пропустить» через себя, чтобы дождаться конца пакета), но не обрабатывать, а игнорировать. Прикладной уровень На данном уровне специфицировано все множество допустимых команд CP (ведущего) и ответов PD (ведомых). Ниже приведено описание некоторых наиболее важных команд для общего представления о возможностях протокола. | |
 Выше не указаны такие интересные команды, как управление текстовыми дисплеями, работа с отпечатками пальцев для биометрических считывателей, работа со смарт-картами, поскольку они требуют отдельного описания, а для понимания возможностей протокола и приведенных основных команд вполне достаточно. Первая из перечисленных команд (osdp_POLL) посылается ведущим (СР) в течение всего времени, свободного от передачи других команд. Периферийные устройства при отсутствии данных отвечают кодом подтверждения (ASK), а при наличии новых данных (изменении статуса входов или выходов, наличии кода карты, введенного ПИН-кода) передают их значение. Команда занимает большую часть трафика шины OSDP, позволяя одновременно контролировать наличие опрашиваемого устройства на линии. Идентификация устройств Очень важным в стандарте является то, что ведущий шины (CP) может получить достаточно подробную информацию о подключенном устройстве. За счет этого можно обеспечить совместную работу на шине устройств различных вендоров, подбирая допустимый именно для данного устройства набор команд. Информация об устройстве получается как ответы на две команды: osdp_ID и osdp_CAP. Посмотрим, что же мы можем получить. Характеристика PD (ID report) В ответ на команду osdp_ID устройство отвечает следующей структурой, размером 12 байт: | |
 Таким образом, по данной структуре можно однозначно определить производителя и тип устройства, что дает уже немалое знание о том, с чем мы имеем дело. При наличии руководства (datasheet) от производителя можно понять, чего можно ожидать от данного устройства. Если же такой информации нет, то большинство свойств устройства можно получить в ответ на запрос совместимости устройства командой osdp_CAP через Capabilities report. Совместимость PD (Capabilities report) Ответ на команду osdp_CAP содержит некоторое количество трехбайтовых структур следующего вида: | |
 Функциональные коды и значения описываемых параметров представлены ниже. Код 1— мониторинг статуса контактов (входов). Возможные значения совместимости: • 01 – PD (периферийное устройство) контролирует и сообщает состояние входа без дополнительной обработки, сообщая состояние в виде активен/не активен. • 02 – как 01, плюс PD может конфигурироваться, какой уровень считается активным, а какой – пассивным (нормально замкнутый — нормально разомкнутый). • 03 – как 02, но дополнительно имеется возможность контроля состояния входа (шлейфа). Режим работы входа может устанавливаться (конфигурироваться). • 04 – как 03, плюс имеется возможность настройки контроля шлейфа в соответствии с пользовательскими характеристиками. Параметры схемы контроля шлейфа определяются производителем оборудования. Код 2 — управление выходами (например, реле). Возможные значения следующие: • 01 – PD активирует выход в соответствии с командами CP (включить — выключить). • 02 – как 01, плюс возможность конфигурирования неактивного состояния выхода. Типичное неактивное состояние – это состояние, которое устанавливается после включения питания, и выход (реле) в неактивном состоянии. • 03 – как 01, плюс выход может использовать управление с заданным временем. • 04 – как 02 и 03, плюс возможность управления активным уровнем с управлением по времени. Код 03 — формат представления кодов карт. Возможны следующие значения: • 01 – PD отправляет данные карты как массив битов (не более 1024 бит). При этом фактически массив битов представляет wiegand – формат. В стандарте это описано как RAW-формат. • 02 – PD отправляет данные карты в виде двоично-десятичных символов с суммарной длиной не более 256 байт. • 03 – PD может отправлять данные карты в обоих форматах, упомянутых выше. Код 04 — управление светодиодами. Возможные варианты перечислены ниже: • 01 – PD поддерживает только управление включить/выключить. • 02 – PD поддерживает управление с отработкой времени. • 03 – как 02, плюс двухцветный светодиод. • 04 – как 02, плюс трехцветный светодиод. Код 05 — управление бипером. Возможные значения: • 01 – PD поддерживает только команды включить/выключить. • 02 – PD поддерживает управление с отработкой времени. Код 06 — текстовый дисплей. Поддерживаются следующие значения: • 00 – PD текстовый дисплей не поддерживается. • 01 – PD поддерживает 1 строку с 16 символами. • 02 – PD поддерживает 2 строки с 16 символами. • 03 – PD поддерживает 4 строки с 16 символами. • 04 — будет определено позднее. Код 07 — поддержка часов реального времени (RTC). Возможные варианты: • 00 – PD не поддерживает RTC. • 01 – PD поддерживает установку времени командой osdp_TDSET. • 02 – PD умеет сам обновлять текущее время (например, с NTP сервера). Код 8 — контрольная сумма. Варианты приведены ниже: • 00 – PD не поддерживает CRC-16, только checksum. • 01 – PD поддерживает 16-bit CRC. Код 9 — поддержка шифрованного обмена. Возможные значения: • 0x01 – (Bit-0) поддерживается AES128 как описано в стандарте. • 0x02 – (Bit-1) — будет определен в будущем. Код 10 — размер приемного буфера. Значения первого байта – младший байт размера, NumberOf – старший байт размера буфера. Код 11 — максимальный размер сегментированного сообщения (предаваемого несколькими пакетами). Значения первого байта – младший байт размера, NumberOf – старший байт размера сообщения. Код 12 — поддержка работы со смарт-картами в «прозрачном» режиме (возможность прозрачно общаться с картой в соответствии с протоколом ее работы, например, ISO-14443). Возможные значения: • 0 — PD не поддерживает режим прозрачного обмена с картами. Код 13 — количество поддерживаемых в устройстве считывателей. Уровень совместимости является битовым полем, трактовка которых в стандарте не определена: • 0x01 – (Bit-0) • 0X02 – (Bit-1) В поле Number of указывается число считывателей. Код 14 — поддержка биометрии. Возможны следующие значения: • 0 – биометрия не поддерживается. • 1 – отпечатки пальцев, Template 1. • 2 – отпечатки пальцев, Template 2. • 3 – радужная оболочка глаза, Template 1. • 4 – … и так далее. Мнение автора: в вышеприведенном списке не хватает, как минимум, еще одного важного кода: наличие и характеристики клавиатуры (например, клавиатуры нет, только цифровая клавиатура, алфавитно- цифровая клавиатура). А если чего-то не хватает? Современная периферия представляет собой достаточно «умные» устройства, имеющие множество вариантов использования, а также много тонких настроек для различных вариантов применения. Для тонкой настройки периферии набора стандартных команд однозначно не хватает, и в стандарте (спасибо разработчикам!) предусмотрена команда производителя, которая позволяет полностью кастомизировать протокол под дополнительные возможности устройств. Формат команды osdp_MFG выглядит следующим образом: | |
 Ответом на команду производителя могут быть как стандартный ответ типа osdp_ACK, osdp_NAK, так и коды, определяемые производителем osdp_MFGRE, которые, как правило, используется в случае, если команда возвращает специфические данные. До версии 2.1.7 стандарта определялись только первые три байта, остальное отдавалось на откуп производителю, поэтому ранее разработанные устройства могут отличаться по формату от приведенного выше формата. Всегда запрашивайте документацию по командам производителя у вендора устройства, которое вы хотите использовать – это позволит максимально использовать его функционал. Большие объемы данных В предыдущей версии стандарта (2.1.6) были аннулированы команды, позволяющие передавать большие объемы данных путем разбиения их на последовательность пакетов небольшого размера. Однако в последней редакции стандарта введены уже два механизма передачи большого объема данных – сообщения, состоящие из нескольких пакетов с возможностью передачи данных размером до 65,534 байт (здесь в стандарте опечатка, в оригинале 64,534 байта). Для реализации такой возможности предусмотрены команды osdp_MPcccc и ответы sdp_MPRrrrr (передача от PD к CP), а также возможность передачи файлов с максимальным размером теоретически до 4 гигабайт (определяется форматом команды sdp_FTcccc и ответа sdp_FTRrrrr). Последняя опция позволяет организовать по протоколу OSDP обновление прошивки устройства, что является весьма важным решением. Мнение автора: как и во многих других случаях, текст стандарта содержит недоработки: ни при описании этого функционала, ни в списке команд и ответов на команды в Приложении А рассмотренные выше команды отсутствуют, и что в этом случае делать (как их реализовывать) – непонятно... Пример что и как Светодиодная индикация Для окончательного понимания прелестей стандарта приведем детальное описание управления светодиодной индикацией. Все светодиоды в PD имеют свой номер от 0 до 255 (!) – более чем достаточно для одного устройства. Сама индикация делится на временную и постоянную, которая работает, если не включена временная. Для постоянной индикации каждый светодиод (а каждый светодиод может быть одноцветным, двухцветным, трехцветным) ему назначаются параметры: • Время включенного состояния (в квантах по 100 мсек). • Время выключенного состояния. • Цвет включенного состояния. • Цвет выключенного состояния. Например, чтобы мигал красный светодиод вспышками по 100 мсек с паузами по полсекунды надо назначить параметры (в порядке их перечисления выше): 1 — 5 — red – black. Для поочередного мигания красного и синего светодиодов с периодом в одну секунду необходимо назначить параметры: 5 — 5 — red – blue. Временная индикация назначается так же с той разницей, что еще указывается время, в течение которого она должна работать (от 0,1 секунды до 6500 секунд). Выдача кода карты В соответствии со стандартом, специальной команды для чтения кода поднесенной карты нет. Код карты (если она прочитана) передается в ответ на следующую команду полинга (а эта команда формируется CP постоянно, если только не надо в данный момент передать другую команду на PD). Код карты может передаваться в «сыром» (RAW) или в текстовом формате. Надо заметить, что последний в стандарте явно не специфицирован, и попытка вытащить информацию из других источников успехом не увенчалась. По RAW формату детальную информацию удалось получить у HID, и при этом выяснилось, что они фактически «засовывают» в ответ примерно то же, что ранее передавали по wiegand. Видимо, это тяжелое наследие старого, поскольку логика обработки карт в контроллерах пока не менялась. Но при всем при этом есть один плюс: при выдаче кода карты дополнительно явно указывается, сколько бит (даже не байтов) кода содержится в ответе, а также в прямом или обратном порядке эти биты в ответе следуют. Ограничений на длину кода в явном виде нет, так что можно работать с картами с любой длиной ID. Аналогично осуществляется и работа с клавиатурой, поэтому подробно рассматривать здесь выдачу кодов клавиш на контроллер смысла не имеет. | |
Внимание! Копирование материалов, размещенных на данном сайте допускается только со ссылкой на ресурс http://www.tzmagazine.ru |
