Интеграция Bolid в 1С или как мы приручили СКУД

Где-то в 2009 году, когда еще речи не шло о группе компаний в сегодняшнем виде, i-Free арендовала помещения в бизнес-центре, сначала занимая одну комнату и расширяясь с годами.
Филиалы в шести странах мира и размещение «с трудом» в четырёх бизнес-центрах Санкт-Петербурга ещё впереди, а пока только 5 кабинетов в разных концах коридора и даже на разных этажах. Коридор общий для разных арендаторов, вход в БЦ свободный. Бегая к коллегам в другой кабинет, замыкать двери на ключ нередко забывали. Стало быть, СКУД стал необходимостью. Задумались о решении, и тогда выбор пал на Болид.


Почему Болид? Альтернатив особо не было, что было реализовано в бизнес-центре, то и «продлили» для себя, просто потому, что был нужный специалист «под рукой».

Быстро решили отделить свою систему от бизнес-центра, чтобы не было дискуссий о доступах и управлении СКУДом.
После появления большего количества помещений, отказались от контактных «таблеток» в пользу более удобных бесконтактных. Появились считыватели em marine, карточки. Купили «аж 150 карточек» и вбивали их в систему.
Спроектировали, смонтировали, настройка закончена, карточки выданы, пошла ежедневная работа.

Я опущу плюсы, буду писать о минусах, чтобы было понятно, как и почему мы пришли к сегодняшней системе.

Итак, минусы:

— для простой выдачи карточки требуется специалист, обученный работе с весьма замысловатым интерфейсом Болида, имеющий соответствующие доступы в программу управления. Значит «в отпуск нельзя, болеть нельзя, умереть запрещено под страхом смертной казни»;
— очень быстро пришло понимание, что карточки нужно не только выдавать, но и менять. При росте компании свыше 200 сотрудников теряли не менее 2-х карточек в неделю;
— гораздо чаще «ой я забыл сегодня дома, дай карточку». До десятка в день;
— а еще «к нам гости из Пекина, 10 человек, в коридоре, нужно срочно карточки… что значит тебе некогда? мне же нужно!»;
— дублирование ввода информации — кадровик вводит информацию о сотруднике в 1С, администратор — в AD, инженер СКУД — в Болид. Три раза;
— а еще, компания оплачивает питание сотрудников, и всё время в воздухе витала идея «а как бы это нам по карточкам обедать в нашем кафе»;
— «а неплохо бы еще вооот такой отчётик, у нас же все ходы логируются… что значит нельзя сделать отчет? это же база данных...». Отчеты у Болида тогда были предусмотрены, но за деньги. И весьма ограниченный набор отчётов при этом;

Реализация

Первым шагом к интеграции стал перевод базы данных Болида на сервер. Описание БД есть, попробовали подключиться из 1С — ура! Вопрос с отчетами решен. Какой хотим, такой и получаем.

Шло время, и была разработана система оплаты питания «по карточкам», предвестник нынешнего наЛанча
Система питания потребовала формата Mifare, дабы организовать на карточке «кошелёк», пришлось заменить все считыватели. И это был следующий этап.

В какой-то момент мы выросли из «нашего» бизнес-центра, арендовали дополнительно еще два этажа в другом. Подключили удаленные помещения по локальной сети, благо Болид позоляет такую архитектуру. Намного позднее к нашей системе подключили даже филиалы в Москве, Украине, Казахстане.

Узким местом остались турникеты на входе во второй БЦ — пришлось навешать на чужие приборы, работающие с em marine, наши считыватели Mifare. Если «на этажах» вход в наши помещения мы контролировали самостоятельно, то «на турникеты» приходилось регулярно передавать списки ключей, новых и заблокированных. Один раз в неделю, что создавало проблемы для «потеряшек» и новых сотрудников. В какой-то момент удалось договориться с удаленными бизнес-центрами поставить параллельно не считыватели, а наши приборы, подключенные по сети. И тогда вопрос обновления ключей стал делом минут, а не дней.

В то же время мы активно изучали Болид изнутри, это оказалась довольно гибкая система. За счет внутреннего макроязыка сценариев, нам удалось дисциплинировать сотрудников: ежедневно скрипт проверял порядка 50 помещений на предмет взятия под охрану, если помещение не под охраной, создавался алерт ответственному, для разборки полетов. Плюс дополнительные удобства: постановка под охрану сразу нескольких помещений при определенном алгоритме, или получение комментариев от охраны на e-mail, при возникновении тревожных ситуаций.

Шло время, наконец закончился переход на Mifare и мучения с двумя карточками у сотрудников. Отчеты по СКУД уже в 1С, корпоративное питание тоже, дело за малым — добиться того, чтобы данные из 1С сами попадали в контроллеры. Здесь нам на помощь пришел комплект разработчика для Ориона Про.



С помощью XML-RPC процедур мы смогли немедленно обновлять данные на контроллерах системы, оперативно блокировать ключи или изменять уровни доступа сотрудников.

Вот пример, как можно поиграться с дверьми, если у вас аналогичная система — запрос ControlAccess отправляет команду на открытие двери, для этого нам понадобится Curl и запрос вида:

ControlAccess

<?xml version="1.0" encoding="windows-1251"?>
<methodCall>
<methodName>ControlAccess</methodName>
<params>
<param>
<value>
<struct>
<member>
<name>ComPort</name>
<value>
<int>1</int>  //адрес компорта к которому подключена ветка контроллеров;
</value>
</member>
<member>
<name>PKUAddress</name>
<value>
<int>0</int> //при наличии клавиатуры управления С2000\С2000М, указываем её адрес;
</value>
</member>
<member>
<name>DeviceAddress</name>
<value>
<int>111</int> //адрес нашего контроллера с экспериментируемой дверью;
</value>
</member>
<member>
<name>AggregateAddress</name>
<value>
<int>1</int>  //номер реле, для С2000-2 с однодверной конфигурацией это 1;
</value>
</member>
<member>
<name>Command</name>
<value>
<int>0</int> //команда управления 0 – предоставление доступа на время, заданное в контроллере, обычно на вход ставят около 10 сек;
</value>
</member>
<member>
<name>MethodNameForAnswer</name>
<value>
<string>Result</string>
</value>
</member>
<member>
<name>IPSERVER</name>
<value>
<string>127.0.0.1</string> //куда отправлять ответ о выполнении запроса;
</value>
</member>
<member>
<name>PORTSERVER</name>
<value>
<int>8080</int>
</value>
</member>
</struct>
</value>
</param>
</params>
</methodCall>

Сохраняем в test.txt отправляем на сервер СКУД, в нашем случае он локальный C:\curl\bin\curl.exe -X POST -d @C:\test.txt 127.0.0.1:8080

Замок разблокируется на выставленное время или до момента открытия двери, только не надо рассчитывать, что это действие останется незамеченным. В логе событий Ориона увидим запись: ДатаВремя – хх.хх.ххх чч.мм.сс; Событие — Доступ предоставлен (по кнопке); Дверь — название; Описание – Вход\Выход; Адрес – 1/0/111/1; Зона доступа – прописанная в контроллере.

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



В ходе знакомства с текущими системами нового бизнес-центра нам снова встретился Болид: в виде пожарной, охранной системы и системы контроля доступа, на нем мы и продолжили строиться.

Сборы и переезд — отдельная тема, но результат того стоил того.



Интеграция болида в 1С существенно облегчила администрирование, позволила создавать автоматические правила по смене уровней доступа при перемещении сотрудника между отделами и автоматической блокировки при увольнении, но при замене карт по-прежнему требовалось вмешательство оператора.

Здесь с помощью нашего SMS-Direct мы подключили сервис по автоматической замене и блокировке карт, для этого сотруднику необходимо отправить кодовые слова, если skud block, то блокируются все имеющиеся ключи у сотрудника, если skud pin то в ответ приходит код, который в дальнейшем необходимо ввести на клавиатуре для аутентификации.

Список сотрудников с телефонами хранится в 1С, ежедневно в ноду SMS-Direct выгружается белый список телефонных номеров сотрудников. При поступлении SMS с запросом номер телефона проверяется по списку, если нет в списке, отправляется ответ о том, что хорошо бы зайти в отдел HR и провериться, если всё Ok — генерируется случайный короткий номер и отправляется в 1С и сотруднику, 1С конвертирует пин-код в ключ для контроллеров:

1234 = F300000000123401
4321 = 1B00000000432101
9876 = 9E00000000987601
4582 = 8200000000458201
123456 = 0500000012345601

Если разобрать последний пример, то 05 – контрольная сумма, 000000 – добивает до 16 символов, 123456 – наш короткий код, 01 – добавляется в конец ко всем ключам.

Циклическая контрольная сумма получается по правилу фирмы Dallas. Расчет осуществляется следующим образом:

CRCTable: array [0..255] of byte = (
0,94,188,226,97,63,221,131,194,156,126,32,163,253,31,65,
157,195,33,127,252,162,64,30,95,1,227,189,62,96,130,220,
35,125,159,193,66,28,254,160,225,191,93,3,128,222,60,98,
190,224,2,92,223,129,99,61,124,34,192,158,29,67,161,255,
70,24,250,164,39,121,155,197,132,218,56,102,229,187,89,7,
219,133,103,57,186,228,6,88,25,71,165,251,120,38,196,154,
101,59,217,135,4,90,184,230,167,249,27,69,198,152,122,36,
248,166,68,26,153,199,37,123,58,100,134,216,91,5,231,185,
140,210,48,110,237,179,81,15,78,16,242,172,47,113,147,205,
17,79,173,243,112,46,204,146,211,141,111,49,178,236,14,80,
175,241,19,77,206,144,114,44,109,51,209,143,12,82,176,238,
50,108,142,208,83,13,239,177,240,174,76,18,145,207,45,115,
202,148,118,40,171,245,23,73,8,86,180,234,105,55,213,139,
87,9,235,181,54,104,138,212,149,203,41,119,244,170,72,22,
233,183,85,11,136,214,52,106,43,117,151,201,74,20,246,168,
116,42,200,150,21,75,169,247,182,232,10,84,215,137,107,53);

KeyCode: array[1..8] of byte;
KeyCode[ 8 ] := 0;

For j := 1 to 7 do
KeyCode[ 8 ] := CRCTable[ KeyCode[ 8 ] xor KeyCode[ j ] ];

Далее в 1С задается заранее установленный уровень доступа с включенным antipassback (дабы ключ не вводили по 5 раз) и отправляется XML на ядро. Орион, согласно уровню доступа, рассылает ключи необходимым контроллерам, контроллеры ждут появления нашего сотрудника. Обычно процедура запроса пин-кода занимает не более минуты, после ввода сотрудником пин-кода на клавиатуре, контроллер формирует сигнал о предоставлении доступа и отправляет в Орион сообщение об успешной аутентификации сотрудника. В Орионе начинается мониторинг поднесенного ключа к нужному нам считывателю, методом ReadKeyCodeFromReader, и отправляется команда на включение реле 2 для подачи сигнала пользователю о «прислонении» карты, после получения кода отпускается реле (активируя antipassback) и формируется запрос в 1С, в котором передается короткий код аутентификации и новый код карты. В 1С по этому запросу создаются соответствующие документы замены ключей. Вся операция от отправки смс до активации карты занимает не более пары минут.

Терминал для активации карт представляет из себя контроллер С2000-2 и подключенные к нему считыватель и клавиатуру, плюс пачка незарегистрированных карточек. Мы расположили один на посту охраны, второй в отделе HR.



Теперь каждый сотрудник может самостоятельно в любое время заменить себе проходку и попасть в офис согласно своему уровню доступа, да ещё и пообедать «по проходке» через пару часов после активации.
Если форм фактор в виде карточки не устраивает, любой сотрудник может взять кожаный брелок, силиконовый браслет или наклейку на телефон — кому что удобнее — и самостоятельно активировать при получении, в отделе HR по той же процедуре.

В процессе этой автоматической замены, конечно же, слишком много посредников, и всё это можно сделать на одном устройстве в виде планшета с gsm и nfc или raspberry с подключенным считывателем и gsm модемом, но в исходных данных у нас был Болид, и нам важно было показать возможности интеграции и автоматизации системы контроля доступа именно на его основе.

Выводы и итоги

Эти решения помогли нам избавиться от ручного вмешательства в СКУД; свести к нулю риск возникновения ошибок при назначении уровней доступа и замене\выдаче ключей; ускорить выдачу новых карт; повысить общую безопасность системы и интегрировать новые сервисы.

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