Болид 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 и запрос вида:
Сохраняем в test.txt отправляем на сервер СКУД, в нашем случае он локальный C:\curl\bin\curl.exe -X POST -d @C:\test.txt 127.0.0.1:8080
В скором времени наш основной БЦ стал уже тесен и не удовлетворял текущим запросам, для этого специально для нас было надстроено три этажа в конгрессно-выстовочном центре по соседству, в котором и сейчас благополучно находится наш главный офис.
В ходе знакомства с текущими системами нового бизнес-центра нам снова встретился Болид: в виде пожарной, охранной системы и системы контроля доступа, на нем мы и продолжили строиться.
Сборы и переезд — отдельная тема, но результат того стоил того.
Интеграция болида в 1С существенно облегчила администрирование, позволила создавать автоматические правила по смене уровней доступа при перемещении сотрудника между отделами и автоматической блокировки при увольнении, но при замене карт по-прежнему требовалось вмешательство оператора.
Список сотрудников с телефонами хранится в 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 ] ];
Теперь каждый сотрудник может самостоятельно в любое время заменить себе проходку и попасть в офис согласно своему уровню доступа, да ещё и пообедать «по проходке» через пару часов после активации.
Если форм фактор в виде карточки не устраивает, любой сотрудник может взять кожаный брелок, силиконовый браслет или наклейку на телефон — кому что удобнее — и самостоятельно активировать при получении, в отделе HR по той же процедуре.
В процессе этой автоматической замены, конечно же, слишком много посредников, и всё это можно сделать на одном устройстве в виде планшета с gsm и nfc или raspberry с подключенным считывателем и gsm модемом, но в исходных данных у нас был Болид, и нам важно было показать возможности интеграции и автоматизации системы контроля доступа именно на его основе.
Выводы и итоги
Эти решения помогли нам избавиться от ручного вмешательства в СКУД; свести к нулю риск возникновения ошибок при назначении уровней доступа и замене\выдаче ключей; ускорить выдачу новых карт; повысить общую безопасность системы и интегрировать новые сервисы.
По прошествии нескольких лет наш партнер, достаточно крупная компания, занимающаяся ритейлом в сфере FMCG, обратилась за помощью в подобной интеграции в свою инфраструктуру, что мы успешно сделали, естественно, учитывая все трудности, с которыми нам пришлось столкнуться при внедрении системы в i-Free. То есть сейчас наше решение доказало возможность быстрого масштабирования и в других компаниях, независимо от специфики работы и количества сотрудников.
Введение
Для общения используются 2 шифрованных протокола: Орион или Орион Про. На момент написания статьи я пока не знаю в чём между ними разница, во всяком случае дальше будет речь о протоколе Орион (без “Про”).
Существует устройство С2000-ПП для общения с bolid-устройствами через протокол Modbus-RTU. Но его функционал крайне ограничен.
Протокол Орион
Протокол Орион представляет из себя подобие Modbus-RTU, есть команда, количество передаваемых байт и CRC.
Мы общаемся со slave-устройствами как master, мы отправляем запросы, устройства нам отвечают.
При отправке шифрованных команд используется MESSAGE_KEY при каждом запросе.
Для общения с Bolid-устройствами нам нужно подключиться в любое место линии RS-485 (не забываем про терминаторы, иногда без них работа нестабильна).
Расчёт контрольной суммы
Установка “глобального ключа”
Для того, чтобы общаться с каким-то устройством, ему нужно задать “глобальный ключ” (для забавы и наглядности выбран ключ 0xBA, получается “BABA”).
Далее по тексту операция исключающего “или” (XOR) будет обозначаться символом “^”.
Зададим Bolid-устройству с адресом 3 глобальный ключ следующей командой:
0x03 - адрес Bolid-устройства, в данном случае устройство имеет адрес 3 (из возможных 1..127);
0x00 - GLOBAL_KEY ^ MESSAGE_KEY (в данном случае GLOBAL_KEY = MESSAGE_KEY, поэтому GLOBAL_KEY ^ MESSAGE_KEY == 0);
0x11 - команда на запись нового ключа устройства;
0xBA - новый GLOBAL_KEY;
0xBA - новый GLOBAL_KEY (повтор байта, видимо на всякий случай);
0x8D - контрольная сумма CRC-8.
Считаем статус устройства
Для того, чтобы получить текущий статус устройства, отправим следующую команду:
0x83 - ADDRESS + 0x80(смещение адреса при шифровании) (ADDRESS == 3);
0x00 - GLOBAL_KEY ^ MESSAGE_KEY (они одинаковые, поэтому ноль);
0xED - 0x57 ^ MESSAGE_KEY команда на чтение статуса;
0xB8 - 0x02 ^ MESSAGE_KEY команда на чтение статуса;
0x62 - контрольная сумма CRC-8.
На данную команду мы можем получить ответ навроде:
0x83 - ADDRESS + 0x80 (ADDRESS == 3);
Читайте также: