[Из песочницы] Серьезная СКУД на несерьезной базе
Всем привет! Хотим рассказать историю о том, как мы СКУД создавали (собирали) практически из того, что было под рукой. А именно — микроконтроллер с сетевым интерфейсом, пара дешевых китайских считывателей, rs232 tcp сервер, конверторы интерфейсов rs232 to rs485, планшет на Андроиде ну и собственно сам турникет (точнее то, что от него осталось после предыдущих попыток запуска СКУД на предприятии— это, в основном, механическая часть).
В статье содержится много картинок!
Не так давно на одном предприятии встал вопрос установки СКУД. До этого на данном предприятии уже были попытки внедрения пропускных систем, но со временем карточки терялись, оборудование выходило из строя. По каким-то причинам не было должного технического обслуживания. Да и те, кто, скажем, контролировал тот самый доступ на территорию, как-то противились нововведениям и, по сути, просто жали кнопку открытия замка для тех кто забыл или потерял пропуск.
Сразу хочу предупредить, что мы ни разу не профессионалы в электротехнике, поэтому в этой статье можно увидеть много «боли» (особенно для электронщиков) и не самых лучших решений. Конструктивная критика приветствуется.
Турникет
Турникет достался нам примерно вот в таком состоянии. По сути там только механика; из электротехнического уцелели светодиоды стрелок-указателей, электромагниты с приводами замков и геркон.
Для управления внутренней начинкой была собрана вот такая схема — это транзисторные ключи с реле. Управлять нам нужно 2-мя зелеными стрелками 2-мя красными и 2-мя электромагнитами для открывания входа или выхода. Итого 4 ключа, два из которых включают зеленую стрелку и электромагнит, два остальных включают красные стрелки (нормальное состояние турникета все замки закрыты).
Да, да, знаю — пайка ужасна.
Разместили готовую плату в корпус который пришелся по размеру.
Контроллер
Итак, теперь у нас работает иллюминация и замки, но этим должен кто-то управлять, получать сигналы от геркона при прокручивании вертушки. Для этого мы использовали Ethernet модуль для управления внешними цепями / нагрузками и мониторинга / измерения различных параметров (напряжение, температура и т.д.) по локальной сети (LAN) Jerome, который был давно куплен и для других целей, но просто пылился.
Краткое описание, что это такое:
- Ethernet (LAN) модуль управления
- Web-интерфейс
- Линии ввода/вывода: 22 штуки
- Счетчик импульсов: 4 штуки
- ШИМ выход, USART, 4 x АЦП
- Открытый командный интерфейс по TCP/IP
- Система CAT — управляемая реакция на события
На момент начала всего этого проекта мы могли зайти в веб-интерфейс и подать сигнал на линию, куда мог быть подключен светодиод, или как в нашем случае, транзисторный ключ и, о чудо!, — светодиод светится, транзисторный ключ срабатывает, реле щелкает.
Кстати вот так он выглядит:
Линии могут работать, либо на вход, либо на выход.
Что бы как то облагородить модуль, разместили плату в корпус от розетки RJ45.
Теперь нужно было организовать подключение к пинам, тут нам в помощь тот же корпус от розетки Rj45 и сами разъемы:
В итоге во второй части нашего импровизированного корпуса для модуля расположились 2 разъемчика RJ 45. Тут, как бы с прицелом на будущее, один для управления турникетом, второй для управления шлагбаумом или воротами. После сборки получаем вот такую коробочку с тремя разъемами Rj45 и одним питание модуля. Получилось компактно и в общем аккуратно:
Считыватель
Как говорилось выше, проект создавался из того, что было на руках и выбирать было особо не из чего, поэтому за основу был взят дешевый RFID считыватель 13,56Mhz rs232. Изначально мы хотели сделать по классике — с каждой стороны (вход\выход) стоит отдельный считыватель, соответственно считали карту на считывателе №1 — значит мы входим на территорию, считали на считывателе №2 — значит выходим с территории. И вот тут встал вопрос каким образом различать считыватели? Возможно, у него есть некий ID? Подключаем читаем карту анализируем данные, нет, считыватель передает только ID карты. На этом казалось бы все. Нужны другие считыватели? Но нет, это не наш путь. Во-первых, мы передумали использовать два считывателя с каждой стороны и установили только один. Это означает, что теперь система следит за тем где находится посетитель на территории или вне ее. Начальное положение не на территории. В этом варианте есть как минусы, так и плюсы.
Минусы:
- нужно запоминать и хранить положение посетителя
- нельзя по одной карте пройти двум и более человекам (точнее можно, но вот вертушку придется прокручивать по нескольку раз, так как замок открывается в зависимости от положения посетителя)
Плюсы:
- нельзя пройти по одной карте двум и более человекам (это важно когда нужен учет «рабочего времени»)
- экономия на считывателях
В процессе эксплуатации при таком режиме мы столкнулись с проблемой. Для сотрудников компании заказчика ведется учет времени (пришел, ушел, сколько был, сколько не был). Помимо работников компании заказчика есть большое количество сотрудников арендаторов для них учет времени не нужен. А для учета времени важен учет направления перехода.
Самые «умные» пытались своим пропуском проводить по несколько человек (исходя, видимо, из раннего опыта в других компаниях), но не тут-то было. При проходе менялся статус перехода «на территории» и при по следующем считывании турникет уже открывался на выход. Это вводило многих в ступор, приходилось объяснять, писать объявления, но были и те кто понимал, прокручивал турникет и считывал снова карту и тогда уже проходил. Но такой режим воспринимался враждебно гневными высказываниями, что система не работает. Понятно, к каким последствиям приводил проход не через проходную, в нашем случае это ворота, которые бывают открытыми, и народ так и норовит проскочить, наживая себе проблемы на проходной. Решение не заставило себя ждать, фильтруем сотрудников по фирмам и те, по кому нужно вести учет, ходят как положено, все же остальные — ходят свободно, для них открываются оба замка независимо от направления перехода. И стал народ ходить толпами по одной карточке.
Гостевые карты
Да, в нашей системе существуют карты для посетителей. Данная карта позволяет посетителю войти на территорию и выйти. И тут встает законный вопрос: как сделать так, что бы карточки не уходили вместе с посетителем? Ведь охрана не всегда на месте (досмотр авто, покурить, туалет и т.д., и т.п.). Естественно нужен картоприемник, это же очевидно для каждого. Но изначально идея была такой — остался (сэкономленный) второй считыватель, предполагалось, что он будет стоять у охраны и при выходе посетитель будет отдавать карту охраннику в руки, а тот будет считывать ее на считывателе, тем самым выпуская посетителя. Но, по уже выше указанным причинам, пришлось отказаться от такого режима. Стали думать, как решить эту задачку. Если брать готовый картоприемник, то ценник очень кусачий, даже на простую модель. Но мы же делаем СКУД из того, что есть под рукой — не стоит забывать об этом! Взяли кусок оргстекла не прозрачного и склеили вот такой желоб.
В нижней части желоба был закреплен считыватель. Идея в том, что посетитель опускает карту в щель, она летит по желобу и, пролетая над считывателем, считывается. Собрали, протестировали — работает. Вот так выглядит уже готовый «картоприемник» (в правой нижней части окна).
Естественно, все как полагается: карточки складываются в лоток.
А вот так это выглядит с внешней стороны:
Единственное, на момент записи видео еще нет лотка для карточек.
Ах, да. Чуть не забыл. Как же мы все таки различаем считыватели? А давайте посмотрим, что внутри у творения «Поднебесной».
Разобрали, ничего особенного. Все! Точно нужны считыватели, которые могут передавать свой ID. Но, «это не наш путь»- подумали мы в очередной раз, и придумали как различать считыватели.
Видите светодиод с тремя ножками? Он двухцветный, обычно горит красным, а при считывании загорается зеленым. Решено, берем сигнал от этого светодиода.
Собираем нехитрую схему оптрон + транзистор. Зачем? О это долгая история, но этот вариант остался исторически, не стали переделывать. Еще эта схема зажигает нам светодиод. так как оригинальный в процессе вышел из строя. Суть в чем? Помните модуль Jerome? У него можно настраивать линии как на выход, так и на вход. Так вот настраиваем нужные линии на вход подключаем схему к соответствующим пинам и ловим входящий сигнал. Точнее Jerome нам сам скажет, когда на нужной нам линии появится сигнал. Таким нехитрым способом мы различаем считыватели.
Так, как вся система у нас построена на TCP технологиях, а считыватели rs232. Было решено использовать rs232/rs485 tcp сервер.
Но вот незадача — разъем rs232 один, а считывателей два. Но есть еще rs485, опаньки вспоминаем, что на rs485 можно «вешать» много устройств. Делаем по нашему, покупаем преобразователи интерфейсов rs232 to rs485 и подключаем параллельно, считываем по очереди — оба считывателя работают, ура! Так, что все хорошо.
Внутренности шкафчика:
Планшет
Ну и наконец, центром всей нашей системы является планшет на Android. Для него написано приложение. В рамках этой статьи я не буду описывать приложение, его работу и внутреннее устройство, так как это тянет на отдельную статью. Ограничусь лишь фотографиями и видео демонстрацией работы. Если кому интересно у нас Хабре уже опубликовано две статьи (раз, два) посвященные этому проекту. Там описаны структурная и динамические модели СКУД. Отдельно стоит упомянуть, что для разработки данного приложения был использован букет технологий Apache Cordova, JXCore (это node.js для мобильных платформ) ну и, куда же без них, — HTML и CSS. Зато у нас кроссплатформенность! В нашем случае есть две версии приложения и обе работают. Это Android версия (основная) и для ПК Windows. Что дает возможность при выходе из строя либо планшета, либо ПК быстро восстановить работу СКУД.
В общем и целом, не смотря на столь малый практический опыт во всех областях, которые затронул данный проект, нам удалось построить СКУД которая реально внедрена и работает по сей день на реальном предприятии в реальных условиях. Используя при этом не самое лучшее оборудование и не самые лучшие решения, а возможно и лучшие в данном контексте. Спасибо, за внимание будем рады ответит на вопросы.
