IoT в моей жизни. Кейс №3 — СКУД

Наиболее сложным примером использования IoT в нашем офисе является работа с системой контроля и управления доступом. СКУД представляет собой электронный модуль, предназначенный для управления доступом в помещения, учета времени прохода и событий.

Контроллер обрабатывает информацию, поступающую со считывателя, имеющего выходной интерфейс «Wiegand» и с помощью встроенного реле осуществляет коммутацию исполнительного устройства — электромагнитного замка. У него нет выхода в Интернет и видимой возможности подключения к платформе. Однако у него есть свой протокол обмена данными с компьютером управления, благодаря которому можно отправлять на контроллер команды, такие как считать из контроллера, записать в контроллер, открыть/закрыть замок и другие. Поэтому в данном случае был организован нестандартный подход — использование агента.

Работа по протоколу контроллера была реализована в коде С++ и запущена на исполнение на Raspberry Pi, которая, в свою очередь, была соединена с контроллером по RS-485 через преобразователь интерфейса. Основная задача программы — осуществить подключение к платформе, сериализировать команды и десериализировать данные, полученные с контроллера. Таким образом, мы смогли с помощью небольшой программной прослойки сделать устройство “умным”.

Модель устройства выглядит следующим образом:

Основная информация с контроллера — это события. На платформу она приходит в формате JSON и включает поля:

• время события,
• код события,
• номер карты сотрудника.

Для разбора JSON-полей по разным параметрам также используется модель.

В интерфейсе объекта это выглядит следующим образом:

А так выглядит интерфейс для отправки команд:

Можно заметить, что есть команда не только на чтение буфера событий, но и на запись новых границ. В памяти контроллера хранятся границы буфера — начало и конец. Когда на устройство приходит команда чтения, считываются эти границы и в этих пределах происходит чтение из буфера событий. Граница конца буфера сдвигается автоматически на контроллере при получении новых событий. А вот начальную границу буфера нужно перезаписать (указав конечную границу после прошедшего чтения), чтобы не прочитать одни и те же данные повторно. Но это необходимо сделать только после того, как данные о событиях были успешно отправлены на платформу. Зафиксировать получение данных и затем отправить команду на перезапись границ также удобно в автомате.

Данный проект нашел свое продолжение в интеграции с нашей внутренней CRM-системой, в которой на вкладке информации о сотрудниках всегда видны актуальные сведения о том, кто находится или отсутствует в офисе. Также отображается время входа/выхода из офиса, считается суммарное количество часов в месяц.

Забор данных из платформы производится по RESTful API. API платформы предоставляет возможность работы, взаимодействия и использования сущностей платформы и их данных в таких внешних системах, как веб-порталы, мобильные и веб-приложения или, как в нашем случае, — CRM-системах.

Также возникают случаи, когда в компанию пришел гость/доставщик еды или кто-то еще, кому нужно открыть дверь. Чтобы не пользоваться своей картой и тем самым не передать некорректные показания о своем статусе, можно воспользоваться кнопкой “Unlock” на платформе. А если человека нужно встретить у двери, то удобно сделать то же самое из мобильного приложения.

Все статьи на эту тему: - "IoT в моей жизни. Кейс №1 — Agile-gong"; - "IoT в моей жизни. Кейс №2 — Датчик углекислого газа"; - "IoT в моей жизни. Кейс №3 — СКУД"; - "IoT в моей жизни. Кейс №4 — Умный огород".