Скуд

Прошло больше года с момента введения жестких ограничительных мер, связанных с распространением COVID-19. Сейчас мир постепенно возвращается в нормальный режим жизни, хотя угроза новых вспышек заболевания остается. Поэтому принимаются все необходимые меры: маски, перчатки и сдача ПЦР-тестов по разным поводам. С административной точки зрения, это, скорее всего, правильно. А вот с организационной система не готова. Главная проблема слабо организованная система проведения ПЦР-тестов. В сегодняшней статье поговорим о том, как ее усовершенствовать.

С точки зрения организации администрирования всего процесса, в целом, ПЦР-тестирование это не просто мазок из носоглотки. Необходимо организовать следующие процессы:

• регистрация клиента и взятие мазка из ротоглотки ПЦР-теста (в стационарных или мобильных пунктах);

• логистика биоматериала до исследовательской лаборатории;

• проведение анализа биоматериала;

• предоставление результатов тестирования;

• контроль результатов на пропускных пунктах (в аэропортах, гостиницах, офисах и т.п.).

Оказывается, в качестве bottle neck в приведенном списке выступают первая и последняя позиции. Действительно, логистика и проведение самого анализа биоматериала давно автоматизированные и проработанные со стороны лабораторий процессы. А вот процедура взятия мазка и последующий контроль результатов исследования на пропускных пунктах в условиях массового наплыва клиентов новая задача.

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

Регистрация клиента в лаборатории

Первый этап автоматизации ввод персональных данных клиента и заключение договора на оказание медицинских услуг. Smart Engines уже выпустил продукт для автоматизации ввода персональных данных. Намного проще вводить паспортные данные, просто сфотографировав документ на веб-камеру или приложив его на секунду к специализированному паспортному сканеру. Банки, мобильные операторы, транспортные компании уже оценили удобство технологии распознавания документов. Кстати, даже в РЖД автоматизировали кассы на вокзалах волшебными коробочками, которые за мгновение вводят паспортные данные.

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

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

Если честно, не важно, какой способ автоматизации при регистрации клиентов использовать. Главное, чтобы специалисты биохимических лабораторий занимались своим профессиональным делом, а не заполнением различных бумаг, которые уже можно и нужно доверить искусственному интеллекту.

Контроль результатов ПЦР-теста

Второй этап автоматизации это контроль валидности выданных тестов. Нет ничего сложного, если надо проверить результаты теста у 100 человек. А если их тысячи (крупные офисы в мегаполисе) или десятки и даже сотни тысяч человек (аэропорта, ж/д вокзалы, речные и морские порты)? И каждый идет со своим индивидуальным бланком справки (как бы это смешно ни звучало, но нет единого шаблона таких справок о результатах ПЦР тестирования).

Помимо проверки непосредственно результата теста, важно следить за валидностью и подлинностью таких справок. Помните этот громкий международный скандал, когда 190 пассажиров рейса Москва Чжэнчжоу предоставили идентичные результаты серологического теста на антитела к COVID-19, что в результате привело к проблемам международного авиасообщения?

Система распознавания Smart Document Engine не только автоматически контролирует результаты в сертификатах тестирования COVID-19 для трех основных лабораторий России (Гемотест, Инвитро и Хеликс), но и возвращает все необходимые данные (как текстовые, так и графические), которые могут быть использованы для анализа валидности и подлинности таких сертификатов.

Помимо мобильного кейса, на базе Smart Document Engine можно построить полноценный роботизированный комплекс - автономный программно-аппаратный комплекс сканирования и анализа данных, совместимый с различными системами СКУД. Роботизированный комплекс способен за мгновение распознать данные из сертификата, контролировать наличие или отсутствие РНК и передавать управляющее действие в СКУД. Таким образом удастся полностью исключить человека из контроля тестов на загруженных пропускных пунктах.

Итого

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

Update. Буквально вчера была опубликована новость о том, что россиян, прибывающих из Турции и Танзании до 1 мая, а после 1 мая всех граждан, прибывающих из-за границы, обязали дважды сдать тест на COVID-19. Такие нововведения лишь подтверждают, что крайне необходима автоматизация процесса проведения ПЦР тестирования и контроля полученных результатов.

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

На предприятиях куча различных механизмов, станков и различного оборудования. На некоторых из них, безусловно, есть электронный учет параметров, однако, как быть, если стоит оборудование постарше или просто без какого-либо электронного учета? Конечно же, идти по заданному маршруту с обычным блокнотом и шариковой ручкой, попутно снимая все показатели. И это хорошо, если сотрудник добросовестно пройдет все контрольные точки, а не просто для вида поставит галочки в блокнот, минуя все условности.

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

Естественно, здесь обязательно вмешается и человеческий фактор: не очень понятный почерк, не туда посмотрел, не то записал, пропустил какие-нибудь параметры или, как говорилось выше, сотрудник просто проигнорировал обход, создав лишь видимость работы. Все эти косяки можно выявить много позже, когда начальник начнет листать журнал и удивляться показаниям или вообще не понимать, что обозначают данные каракули и откуда они взялись. И это еще хорошо, если все оборудование в порядке или проблемы успели устранить. А что если нет? Сразу, можно сказать, что остановка оборудования и его ремонт обходятся для компании в космические суммы, ибо такие инциденты могут вывести из строя весь технологический процесс.

Поэтому хотелось бы описать одну реальную историю, которая произошла несколько лет назад. Одна известная компания, которой свойственны все проблемы, описанные выше, обратилась к нам и запросила дополнительный функционал для нашего ПО, которым они уже давно пользовались (облачная система учета рабочего времени TARGControl). Когда мы начали вникать в суть проблемы, то поняли, насколько важным для предприятий является проблема обхода маршрутов и ужаснулись, с чем сталкиваются компании на постсоветском пространстве, где данные процессы не автоматизированы. Собирая бизнес-аналитику от клиента, анализируя существующие решения, мы поняли, какие вопросы должен будет закрыть наш новый модуль:

1. Создание графиков и маршрутов обходов.

2. Контроль своевременного обхода маршрутов сотрудниками.

3. Учет действий сотрудников при прохождении маршрутов.

4. Возможность получать фото- и текстовые уведомления с контрольных точек.

5. Удобство для обходчика: возможность фиксировать все с помощью телефона (планшета), никаких журналов.

6. Хранение отчетов в системе на протяжении всего времени.

Формирование системы обхода маршрутов

Сперва нужно было доработать нашу существующую систему. Исходя из составленного плана было решено разработать специальное приложение под Android (TARGControl Patrol) и новый модуль для нашей облачной системы, который мы назвали просто Маршруты.

Для WEB сразу написали возможность добавления точек обхода и формирования из них маршрутов (первоначально это были только RFID-метки), чтобы изучить возможность сканирования меток на устройствах с помощью NFC-считывателя. Параллельно велась работа и над APP (приложение писали на Java/Kotlin), с помощью которого мы собственно и считывали метки.

После первых успешных тестов мы начали допиливать функционал WEB. Сразу же для визуализации маршрутов был создан раздел Отчеты, где можно было просмотреть время прохождения маршрута и точек, после чего добавили в систему раздел Расписания маршрутов для тестирования возможностей прохождения маршрутов по заданному графику (дням и времени).

В ходе накопления данных и расширения возможностей (текстовые и фото-заметки, снятие показателей на точках прохода), были разработаны Отчеты по параметрам, где можно просмотреть показатели оборудования (реальные и установленные значения). Позже был реализован и Отчет по точкам для просмотра данных по каждой точке маршрута на протяжении установленного нами времени.

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

Итого на WEB были сформированы следующие разделы модуля Маршруты:

1. Отчет (глобальный отчет по маршрутам).

2. Отчет по точке (отчет по конкретной точке за заданный интервал времени).

3. Отчет по параметрам (отчет по показателям оборудования, снятыми соответствующим персоналом).

4. Контрольные метки (в данном разделе создаются (QR) или вносятся существующие (RFID) контрольные метки).

5. Маршруты (создание маршрутов с помощью внесенных в систему меток).

6. Расписание маршрутов.

7. Графические планы.

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

Итого функционал приложения позволяет:

1. Авторизация в приложении с помощи карты или личного PIN-кода.

2. Просмотр маршрутов и их контрольных точек.

3. Просмотр расписания маршрутов.

4. Процесс прохождения маршрутов по контрольным точкам и просмотр прогресса.

5. Возможность оставлять у каждой контрольной точки текстовую и фотоинформацию. Можно просто сфотографировать показатели или оставить дополнительную информацию, если на объекте, например, произошло ЧП.

6. Регистрация меток.

7. Замена этих же меток.

Настройка системы маршрутов обхода для производства

Чтобы не быть голословным, опишу процесс настройки и расскажу, что мы использовали для создания автоматизированной системы маршрутов на производстве. Для полноценной работы маршрутов нам необходимо следующее оборудование:

1. RFID-метки, которые будут использоваться как контрольные точки маршрута (возможны QR-метки).

2. Приложение TARGControl Patrol.

3. Смартфон (или планшет) на операционной системе Android.

4. Система учета рабочего времени (УРВ) TARGControl Cloud

В качестве устройства выбрали такие защищенные устройства, которые в условиях предприятия сможет с легкостью выжить. Менять телефоны каждый месяц дело не из дешевых. Плюс главное условие для устройств наличие NFC, с чем данные модели успешно справляются. Сразу скажу, возможен вариант и с устройством без NFC однако вместо RFID-меток придется использовать QR-коды, что иногда является не самым удобным вариантом.

В качестве контрольных точек были взяты RFID-метки следующего вида.

Данные метки хороши тем, что подходят для помещений с тяжелыми условиями работают при температуре от -20 до 200 C, что соответствовало запросам предприятия.

Подробнее остановимся на создании самих маршрутов в системе TARGControl Cloud. Компания, для которой разработали приложение и доработали облачное ПО, использовало нашу систему УРВ и активно пользовалась ей, поэтому весь список необходимых сотрудников был внесен и все учетки, необходимые для входа в приложение, были созданы. Осталось дело за малым настроить сам модуль Маршруты.

В системе создаем группу меток (для удобства), после чего вносим туда сами метки, в нашем случае это RFID.

При создании метки вбиваем имя, выбираем тип метки, вносим сам код (как писал выше, можно выполнить данную операцию и с помощью приложения) и создаем нужные строки для снятия показаний. Готово, выполним операцию еще n-ое количество раз, пока не внесем все нужные метки.

Далее создаем сами маршруты. Вводим название, выбираем цвет индикатора (для лучшего визуального восприятия на устройствах), выбираем нужные для нас метки, которые будут использоваться в маршруте обхода. Чтобы поторопить обходчика, выставим время на прохождение точки и все, маршрут готов. В этом случае для примера я выставил только 2 точки, но сути это не меняет в системе можно указать любое количество точек.

Остается лишь создать расписание: указать дату/время обходов, выбрать необходимых сотрудников, которые будут осуществлять обход по заданному маршруту и проставить галочку напротив поля Учитывать порядок обхода, чтобы считывание меток осуществлялось в заданном заранее порядке. Существует возможность и дополнительных настроек расписания, таких как Учитывать время начала и Учитывать время окончания, благодаря чему сотрудники, проходящие маршрут, должны будут начать и закончить маршрут только в определенно установленное время (с допустимым интервалом). На этом настройки закончены, можно приступить к самому принципу работы.

Как происходит процесс обхода?

Площадка, на которой происходит обход, обвешана RFID-метками, находящимся возле оборудования, с которых необходимо списывать показатели. Общий порядок действий при прохождении маршрута выглядит следующим образом:

1. Сотрудник, который начинает обход, берет в руки устройство и проходит процесс авторизации в приложении вводит личный PIN или подносит свою карту. Данную операцию можно выполнить один раз, однако если маршрут проходит другой сотрудник с этого же устройства, то ему нужно нажать кнопку Выйти и авторизоваться под своим именем.

2. Зайдя под своим именем, сотрудник выбирает маршрут, на котором будет осуществлен обход. Выбрав нужный маршрут, сотрудник отправляется в путь.

3. Подойдя к первой точке маршрута, сотрудник подносит телефон (планшет) к метке, после чего приложение просканирует ее и предложит ввести определенные параметры оборудования, которые мы заранее указали в облаке TARGControl Cloud (описано выше). Существует возможность прикрепить фотографию. Все данные сразу же прилетают в систему.

4. Далее обходчик просто направляется к следующей точке маршрута и повторяет операцию. На маршруте могут комбинироваться типы меток. Например, точка 1, 2 и 3 RFID-метки, а точка 4 QR.

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

При просмотре отчета руководящий персонал сразу же может обнаружить показатели, не соответствующие норме и выслать работников на устранение проблемы, что позволит избежать экстренной остановки оборудования.

Итог

После внедрения решения маршрутов обхода, на предприятии отпала необходимость вести бумажные журналы на предприятии и все отчеты по маршрутам были размещены в облачной системе УРВ TARGControl (с возможностью экспорта в Excel). Все показатели оборудования стали фиксироваться в режиме реального времени, что позволило оперативно устранять неисправности.

Особо полезной функцией для руководителей стала реализация уведомлений в мессенджер (которая была реализована через API), благодаря чему руководство смогло всегда знать, какой сотрудник прошел маршрут не по расписанию или же допустил какие-нибудь нарушения.

В ходе дальнейшего сотрудничества было разработано еще множество улучшений как для модуля Маршруты, так и для всей системы УРВ в целом, однако эти нюансы заслуживают отдельной статьи.

И снова привет, мир!

В прошлой статье про IoT-елочку в голосовании многие отметили, что интересна тема управления устройствами в зависимости от количества человек в помещении. Это довольно масштабная задача, и мы предлагаем разделить ее решение на несколько этапов. Сегодня поговорим о системе контроля управления доступом (СКУД), которая, будучи подключенной к платформе интернета вещей Rightech IoT Cloud (далее по тексту - платформа), является базовым элементом в системе подсчета количества человек в офисе. Мы уже поверхностно освещали этот кейс в одной из статей, но сегодня рассмотрим этот проект более подробно и погрузимся в особенности исполнения.

С чего все началось

Задача обеспечить контроль за входом-выходом в офисе возникла еще в те времена, когда у нас был выход на крышу с отличным видом на Москву, и поэтому часто приходили люди, не являющиеся нашими сотрудниками. Тогда мы решили принять какие-то меры по безопасности и установить СКУД.

Архитектура

Система открытия дверей по карте

В качестве модуля, отвечающего за обработку информации по считыванию бесконтактных карт, выбрали GATE-8000.

Основные достоинства контроллера:

• формирование и хранение необходимой информации о факте открытия двери по карте и времени прохода человека в офис;

• возможность автономной работы и защиты от зависания;

• хранение 16 тысяч ключей и 8 тысяч событий;

• простое подключение и управление;

• российский производитель, хорошая документация с описанием работы контроллера.

Основной принцип работы: контроллер обрабатывает информацию, поступающую со считывателя, и с помощью встроенного реле коммутирует исполнительное устройство - электромагнитный замок двери.

Система взаимодействия с платформой

После того, как контроллер установили в систему по общей схеме подключения, а карты записали в память, мы уже обезопасили себя от прохода в офис посторонних. А дальше возник вопрос, как подключить этот контроллер к платформе Rightech ioT Cloud. Ведь очень здорово иметь а) графический интерфейс, в котором можно полистать историю всех проходов, б) возможность отправки команд на открытие двери удаленно, не отходя от рабочего места, например, для гостей или доставщика еды.

У контроллера нет выхода в Интернет и видимой возможности подключения к платформе, к тому же все события нужно принудительно считывать из его циклического буфера. Однако у него есть свой протокол обмена данными с компьютером управления, благодаря которому можно отправлять на контроллер команды, такие как считать из контроллера, записать в контроллер, открыть/закрыть замок и другие. Значит, нужно сделать некоторую программно-аппаратную прослойку между контроллером и платформой - агента, который будет отправлять команды на чтение событий и управление контроллером.

Обращаем внимание, что в данной архитектуре функция открытия двери при прикладывании карты не перестанет выполняться при отсутствии Интернета. За открытие двери и сбор информации отвечает контроллер СКУД, поэтому в случае потери Интернета, единственное, что нам грозит, - это то, что агент, который доставляет данные на платформу, не будет функционировать, так как не сможет получать команды на чтение буфера. Однако при восстановлении соединения все события считаются в полном объеме и не потеряются, так как они будут сохранены в буфере контроллера СКУД.

Аппаратная часть

Для начала нужно было выбрать устройство, которое будет всегда в активном состоянии с включенной программой-агентом в непосредственной близости от платы СКУД. Из многообразия микрокомпьютеров первое что попало под руку выбор пал на Raspberry Pi.

Дальше возник вопрос, как подсоединить GATE-8000 к Raspberry - то есть как подключить последовательный интерфейс RS485 от GATE к USB от микрокомпьютера. Начались поиски переходника USB-RS485. Первый вариант, который мы испробовали, - Espada за 200 рублей. Надежда на то, что маленький хлипкий китайский переходник заработает, была небольшой. Он и не заработал. Вместо нужных данных приходило что-то похожее по виду и размеру, но всё же не то. В чем было дело: в отсутствии гальванической развязки, невозможности поддерживать скорость 19200 bps или же просто в некачественной элементной базе, - загадка. Но после обращения к производителю GATE-8000, мы получили рекомендацию на более дорогой (в 10 раз) и громоздкий (но аккуратный и корпусированный) переходник Z-397, который заработал тут же как надо.

Программная часть

Начинаем разработку программы с определения, какие функции она должна выполнять.

1. Что нужно - взаимодействие с GATE-8000 для отправки команд и получения данных.

   Как решим - изучим протокол GATE, напишем сериализатор и десериализатор данных, подключим библиотеку для работы с последовательным портом.

2. Что нужно - взаимодействие с платформой для получения команд и отправки данных.

   Как решим - выберем для общения протокол MQTT, в коде воспользуемся готовой библиотекой Paho MQTT.

Итак, мы приступили к изучению протокола GATE-8000, который является закрытым, поэтому ниже рассказано только о некоторых его особенностях. Он достаточно низкоуровневый, и необходимо обращаться напрямую к регистрам памяти устройства. В документе по этому протоколу описаны кадры запросов от компьютера контроллеру и кадры ответов контроллера компьютеру. Меняя поля в кадре запроса, можно отправлять на устройство различные команды и получать информацию из регистров.

Одна из особенностей протокола в том, что инициатором обмена всегда является компьютер. Поэтому есть два подхода работы с устройством:

1) задавать всю логику работы в агенте;

2) использовать внешние запросы (от платформы).

Мы выбрали второй вариант и вынесли логику с конечного устройства на платформу (подробнее про сервис сценариев автоматизации >>>). Так ее легко адаптировать и подстроить, при этом код программы остается компактным и позволяет просто формировать команды для устройства, а платформа в свою очередь координирует отправку команд и их периодичность.

После того как мы внимательно изучили этот протокол, формат кадров и список команд, возникла первая сложность. Команды для чтения буфера, в котором содержатся события о том, кто и во сколько пришел, не оказалось. А ведь получить эту информацию - первоочередная задача. Понадобилось изучить карту памяти контроллера, чтобы определить адреса, по которым нужно считывать данные.

Следующая особенность работы с контроллером в том, что за один цикл чтения можно получить только 12 событий, по 8 байт на каждое. А на каждый проход человека в офис генерируется уже два события:

1) найден ключ в банке ключей (банк ключей - еще один блок в распределенной памяти контроллера);

2) состоялся проход (если он, конечно, состоялся).

Ниже представлен фрагмент кода на С++, реализующий метод одного цикла чтения буфера.

bool SerialPortInlet::readBufferCycle(unsigned short& bottom, unsigned short const& top, unsigned char& u_lowerBound,    unsigned char& l_lowerBound, std::vector<unsigned char>& readBuffer, std::string& result){// Подсчет байтов, которые необходимо считатьunsigned short byteCountTmp = top - bottom;BOOST_LOG_SEV(log_, logging::info) << "Need read " << byteCountTmp << " byte";unsigned char byteCount;// За один цикл нельзя прочитать более 12 событий (96 байт)byteCount = byteCountTmp > 0x60 ? 0x60 : (unsigned char)byteCountTmp;BOOST_LOG_SEV(log_, logging::info) << "Read " << +byteCount << " byte";// Описываем тело командыstd::vector<unsigned char> body = {0x02, 0xA0, byteCount, u_lowerBound, l_lowerBound};std::vector<unsigned char> command;// Получаем полный текст командыgenerateComplexCommand(command, Command::BYTE_CODE_READ, body);// Если не удалось по каким-то причинам отправить команду (например, конечное устройство не подключено), возвращается falseif (!sendCommand(command, result)){    return false;}// Иначе отправляем ответ с устройства на парсинг по событиямSerialPortType::Answer answerEvents;if(!Parsers::parserAnswer(log_, result, answerEvents, Command::BYTE_CODE_READ)){    BOOST_LOG_SEV(log_, logging::error) << "Failed parse buffer reading";    return false;}readBuffer.insert(readBuffer.end(), answerEvents.body.begin(), answerEvents.body.end());// Сдвигаем нижнюю границу буфера для чтения следующих событийbottom = bottom + byteCount;u_lowerBound = (unsigned char)(bottom >> 8) ;l_lowerBound = (unsigned char)bottom;return true;}

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

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

Пример байтстаффинга из документации

Полная структурная схема разработанной системы выглядит так.

Работоспособность всех устройств было очень удобно проверять с помощью графического последовательного терминала СuteCom. После успешного тестирования программа была поставлена на автозапуск, а Raspberry отправилась жить на потолке рядом с платой СКУДа.

Работа на платформе Rightech IoT Cloud

Модель

Основные данные с контроллера - это события, на платформу они приходит в формате JSON и включают в себя поля

• eventTime - время наступления события;

• eventCode - код события;

• keyNumber - номер карты сотрудника (поле может быть пустым, если событие вызвано не картой).

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

Посмотреть оригинал >>>

Возможные события:

• нажата кнопка звонка;

• неопознанный ключ на входе;

• неопознанный ключ на выходе;

• ключ найден в банке ключей при входе;

• ключ найден в банке ключей при выходе;

• открывание оператором по сети;

• дверь заблокирована оператором;

• дверь оставлена открытой после входа;

• дверь оставлена открытой после выхода;

• проход состоялся на вход;

• проход состоялся на выход;

• перезагрузка контроллера.

Объект

Интерфейс объекта полностью формируется согласно разработанной модели.

Посмотреть оригинал >>>

Ура, теперь, собравшись на кухне офиса в ожидании пиццы на праздник, можно никуда не идти, а просто открыть мобильное приложение и нажать кнопку открытия двери для курьера!

Автомат

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

Зафиксировать успешное получение данных и затем отправить команду на перезапись начальной границы удобно в автомате.

Посмотреть оригинал >>>

Здесь виден цикл <чтение>-<запись новой границы буфера>-<ожидание таймера> (сейчас события считываются каждые 30 секунд).

1. В состоянии Read events читаем новые события.

2. В состоянии Clear buffer записываем новую границу.

3. В состоянии Await timer ожидаем начала нового цикла.

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

Дальнейшее использование собранных данных

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

Также отображается время входа/выхода из офиса, считается суммарное количество часов в месяц.

Посмотреть оригинал >>>

В мессенджер Slack каждый день пишется о том, что офис открыт, когда приходит первый человек, взявший ключи на ресепшене.

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

Посмотреть проект, в котором есть пример настройки взаимодействия и получения данных с платформы >>>

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

Алгоритм бинарного поиска или поиска делением пополам известен давно. В данной статье будет рассмотрен пример его железячной реализации на 8-битном микроконтроллере и особенностях, которые возникают при этом.

Одно время мы выпускали несложный контроллер облачной СКУД на 100 пользователей. В его основе лежал микроконтроллер PIC18F46K22. В качестве памяти для хранения кодов ключей пользователей использовалась FLASH-память с интерфейсом I^₂C ёмкостью 64 кБ. Сама флешка довольно быстрая, но на шине I²C находилась ещё микросхема часов DS1307, которая работает на скорости не выше 100 кбит/сек. Высокой скорости работы нам не требовалось, поэтому в итоге вся шина была запущена на частоте 100 кГц.

Однако со временем мы начали разрабатывать новую версию контроллера, поддерживающего уже 3000 пользователей. Не хотелось сильно менять архитектуру, поэтому основные узлы были сохранены, но при этом был увеличен объём FLASH-памяти до 256 кБ.

И вот тут возник один интересный момент. В первой версии поиск ключа в памяти осуществлялся простым перебором всех 100 ключей. Этот процесс занимал долю секунды и поэтому каких-либо оптимизаций кода не производилось. Но при количестве в 3000 записей это время увеличилось в 30 раз, что оказалось недопустимым, так как у пользователя появлялась неприятная задержка между считыванием карты и открытием замка.

Решить данную проблему можно двумя способами. Первый аппаратный вариант, предполагающий использование более быстрого интерфейса с флешкой, например, SPI. Скорости чтения здесь на два порядка выше, чем при использовании I²C. Это, так сказать, решение в лоб. Неудобство лишь состоит в том, что приходится закладывать в устройство новый компонент, переделывать код и печатную плату. Плюс потребуются дополнительные линии микроконтроллера для подключения такой микросхемы памяти.

Но есть и другой способ программный. Заключается он в переделке самой процедуры поиска. Изначально она выглядела так:

typedef struct{    uint32_t COD;    uint8_t nSchedule;} TSKUD_User;bool skudFindUserByCode(uint32_t pCOD){  TSKUD_User user;  for (uint8_t i = 0; i < SKUD_USERS_COUNT; i++)  {    skudReadUser(i, &user);    if (user.COD == pCOD)      return 1;  }  return 0;}

Функция skudReadUser считывала блок данных из I²C памяти, далее осуществлялась проверка на совпадение кода.

При ста пользователях в худшей случае (когда код находился в самом конце массива данных) время поиска занимало порядка 0,1 сек. При переходе же к 3000 пользователей время выросло 3 сек!

Поэтому для ускорения функция была переписана следующим образом:

bool skudFindUserByCode(uint32_t pCOD){  TSKUD_User user;  int16_t m, beg, end;  beg = 0;  end = SKUD_USERS_COUNT - 1;  while (beg <= end)  {    m = (beg + end) / 2;    skudReadUser(m, &user);    if (pCOD == user.COD)      return true;    if ((pCOD < user.COD) || (user.COD == 0))      end = m - 1;    else      beg = m + 1;  }  return false;}

Это классический вариант реализации алгоритма, работающий на отсортированном по возрастанию массиве данных. В нашем случае это не составляет проблемы, так как данные грузятся с сервера, который и осуществляет их сортировку перед отправкой в контроллер.

О различных частных случаях при реализации бинарного поиска можно почитать в статье:Я не могу написать бинарный поиск (http://personeltest.ru/aways/habr.com/ru/post/146228).

Итак, рассмотрим работу алгоритма. Переменные beg и end задают начальный и конечный индекс массива данных. На каждой итерации мы вычисляем индекс m, который находится посередине между beg и end, и сравниваем требуемое значения ключа с тем, что находится по этому индексу. В этом случае возможны три варианта:

1. Если значения совпадают, то мы нашли нужный ключ и можно открывать замок.

2. Если номер искомой карты меньше, то следует его искать в левой части массива. Тут мы отбрасываем сразу половину заведомо не подходящих вариантов. Индекс end теперь будет равен m 1.

3. Если номер искомой карты меньше, то следует его искать в правой части массива. Так же отбрасываем сразу половину заведомо не подходящих вариантов, но меняем индекс beg (он будет равен m + 1).

Если в массиве данных вообще нет искомого значения ключа, то нам нужно выйти из цикла. Условием выхода является beg > end.

Очень важным является дополнительное условие user.COD == 0 в строке:

    if ((pCOD < user.COD) || (user.COD == 0))

Дело в том, что неиспользуемые элементы массива данных мы просто заполняем нулями. Реально это происходит так. Из базы данных получается отсортированная по значению кода карты выборка пользователей. Эта информация записывается в массив данных, начиная с нулевого индекса. Остальные значения дописываются нулями:

Можно было бы записывать туда значения 0xFFFFFFFF, но его мы используем в качестве сервисного для служебных нужд системы. Поэтому дополнительное условие user.COD== 0 всегда заставляет алгоритм искать код в левой половине массива данных.

Кто-то может справедливо заметить, что нет смысла тогда вообще обрабатывать эти нулевые значения. Но дело в том, что мы не передаём в контроллер реальное количество карт доступа. Изначально для 100 карт это не имело смысла (поиск и так работал очень быстро), а потом мы просто не стали менять структуру данных. Но, по большому счёту, это и не нужно, так как бинарный поиск очень сильно ускоряет работу.

Рассмотрим следующий пример. Пусть у нас имеется полный массив из 3000 записей. Пользователь подносит ключ и мы должны проверить, есть такая карта или нет. При линейном поиске нам понадобится в худшем случае просмотреть все записи. Итого нужно будет сделать 3000 сравнений.

А вот при бинарном поиске количество сравнений будет составлять log₂3000 11 шт!

Интересно, что если записей будет аж 4 миллиарда, то количество сравнений при использовании бинарного поиска увеличится всего лишь до 32!

Попробуем пошагово проверить алгоритм бинарного поиска на вышеприведённой табличке. Допустим, нам требуется найти значение ключа 2174082.

В итоге мы за 11 итераций нашли искомое значение. Важно понимать, что 11 итераций это максимальное время поиска. В вышеприведённом примере в случае, если бы мы искали значение 2290467, то количество итераций было бы равно 9.

Так в чём преимущество такого решения? В начале статьи я указывал, что алгоритм реализовывался на микроконтроллере. Использование крайне дешёвой памяти с интерфейсом I^₂C снижает общую себестоимость изделия, а новый алгоритм поиска сильно уменьшает время реакции контроллера.

Всегда интересно посмотреть как реализации алгоритмов работают вживую. Для этого я снял два небольших видео, где показана работа контроллера в двух вариантах: с линейным поиском и бинарным. Нужное значение карты памяти я специально внёс в самый конец списка (индекс 2999), чтобы можно было оценить работы обоих алгоритмов в худшем случае.

Вот работа линейного поиска:

А вот бинарного:

Результат, как говориться, на лицо!

Вступление

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

Историю можно начать с того, что наша компания очень долгое время сотрудничает со всемирно известной сетью фастфудов - KFC (на территории Беларуси и Украины). Головной болью такой сферы, как HoReCa, был и будет учет рабочего времени сотрудников. Учитывая огромную текучку кадров, в том числе и обычных студентов, которые пришли подработать на непродолжительное время, становится сложно проконтролировать, сколько часов отработано тем или иным сотрудником. Плюс немаловажным моментом стало то, что сотрудники часто перемещаются с ресторана на ресторан, а это требует дополнительного контроля. Как же быть?

Нашей компанией было принято решение разработать терминал учета рабочего времени, который бы регистрировал рабочие (или не рабочие) интервалы рабочего времени сотрудников с привязкой к конкретному месту работы. При этом нужна была поддержка нескольких видов идентификаторов - биометрия по отпечатку пальцев, RFID и PIN с возможностью фотофиксации событий доступа.

Поэтому был придумал предельно простой и быстрый сценарий действий на терминале:

1. Прийти на рабочее место, подойти к терминалу и пройти идентификацию (приложить палец, карту к считывателю или ввести PIN)

2. Выбрать на тачскрине Работа, после чего отправиться на свое рабочее место и приступить к работе

3. При необходимости перерыва подойти к терминалу, пройти идентификацию, выбрать Перерыв

4. При возвращении на рабочее место - подойти к терминалу, пройти идентификацию, выбрать Работа

5. По окончанию рабочей смены подойти к терминалу, пройти идентификацию и выбрать Завершить работу.

То есть все события должны были фиксироваться на терминале, после чего все данные залетали бы на облако системы рабочего времени TARGControl. И там, административным персоналом, формировались табели и отчеты по объектам (ресторанам), что позволило бы корректно начислять заработную плату сотрудникам.

Разработка

Имея на руках техническое задание, была разработана структурная и функциональная схема. Далее пошло самое интересное: мы начали рассматривать различные варианты одноплатных компьютеров, которые бы смогли обеспечить нужный функционал терминала. Среди вариантов были следующие компьютеры: Banana Pi M4, Orange Pi PC+, ODROID-C4, NanoPi M4 и Raspberry PI Computer Module 3+. Произведем небольшое сравнение данных моделей.

После детального изучения и анализа цены (все модели находились в примерно одном ценовом диапазоне на момент их анализа - 2019 год), мы все же пришли к выводу, что лучше всего подойдет Raspberry PI Computer Module 3+. Почему Raspberry ? Да, некоторые характеристики уступают конкурентам, однако главным преимуществом стало то, что по Raspberry банально больше поддерживаемых библиотек и лучше техническая поддержка, т.к Raspberry на рынке с 2012 года и вокруг него сформировалось активное комьюнити.

Решение со встроенной памятью eMMC, предусмотренное в CM3, позволяет не использовать флеш-карту в качестве носителя ОС. Большое количество циклов перезаписи eMMC повышает надежность и срок службы памяти по сравнению с флеш-картами. При этом мы зарезервировали разъем для SD карт. Сразу можно сказать, что заявленной памяти для терминала хватает с лихвой, ибо сохраняемые события весят от силы пару килобайт. Что касается хранения фотографий, то здесь все сложнее: программно мы поставили ограничение в 5000 фото, но так как у нас зарезервирована флеш-карта, то данный лимит можно расширить до приемлемого значения.

Разработку управляющей платы мы начали с организации необходимых питающих напряжений. На нашей плате нам необходимо было обеспечить 3 значения напряжений: 5.0В, 3.3В и 1.8В. Внешний источник питания у нас 12В 3А. Для получения 5В и 3.3В мы использовали схему на основе широтной импульсной модуляции. Для источника питания 1.8В мы задействовали линейный понижающий преобразователь. Это выглядит, примерно, следующим образом.

Исходя из схемы видно, что для электрической части терминала была организована схема защиты питания от короткого замыкания и переполюсовки.

Отметим также и схему защиты питания внешних считывателей, представленную ниже.

То есть если закоротить питание, считыватель уйдет в защиту (питание считывателя отключится), а терминал продолжит работу. Номиналы резисторов R51 и R52 задают выходной ток. Изменяя номинал резистора R51 можно менять ток ограничения в значительных пределах (у нас стоят заданные на схеме номиналы исходя из рассчитанной нами нагрузки).

Питание мы организовали, самое время перейти к периферии.

К слову, Raspberry поддерживает UART-интерфейс и 2 USB версии 2.0. Через один из доступных USB мы решили организовать доступ к Ethernet с помощью микросхемы LAN9514 . Второй USB используется для подключения периферии, например индикатор алкоголя. Также задействовав GPIO для подключения кнопок, электромагнитных замков, защёлок, алкостестера в дискретном режиме работы и картаприемников.

У CM3 на борту всего 2 UART. Один нам пригодится для организации интерфейса RS-485, а второй - debug. Поэтому мы использовали микросхему FT4232HL, для увеличения количества интерфейсов. У нее есть входной интерфейс USB, который поддерживает связь с LAN9514, он же в свою очередь коннектится с CM3.

Вот теперь у нас стало больше на целых 4 UARTa (задействуем всего 2). Один используется для подключения биометрического модуля отпечатков пальцев от южнокорейского производителя Suprema-SFM6020-OP6-8M/16M (8M - 5К отпечатков, 16М- 25К отпечатков).

Второй для подключения карточного модуля 7941D (поддерживает 2 частоты Emarine (125 кГц) и Mifare (13,56 МГц).

Один из выделенных UART, как и планировали, мы задействовали под RS-485, позволяющий подключать внешние карточные или биометрические считыватели, а также передавать информацию во внешние системы при необходимости интеграции. Схема 485-го представлена ниже.

В этой схеме мы прибегли к некоторым хитрым схемотехническим решениям, объединив и подключив линии RE и DE через транзистор, что позволило нам автоматизировать на аппаратном уровне переключение режимов приема/передачи.

Что касается интеграции с другими системами традиционным для СКУД способом, для передачи минимальной информации у нас организован выходной Wiegand. Есть и два входных Wiegand'а для подключения внешних считывателей. Ниже представлены их электрические принципиальные схемы.

Немаловажным моментом будет, что терминал имеет 2 реле для управления замком, турникетом или шлагбаумом. Рассмотрим данный момент на примере подключения турникета (стандартная ситуация для СКУД). Есть два режима управления турникетом, потенциальный режим и импульсный. При потенциальном режиме управления для разблокировки турникета в направлении А срабатывает выход L1 OUT (в направлении В выход L2 OUT). При окончании данного времени или при совершении прохода выходной сигнал возвращается в исходное состояние.

В импульсном режиме для разблокировки выхода L1 OUT и L2 OUT срабатывают кратковременно, посылая управляющий импульс на турникет (обычно 0,2-0,3 секунды). При получении импульса турникет разблокируется в соответствующем направлении на время 5 секунд либо пока не будет совершен проход в данном направлении.

Для контроля прохода в направлении А или направлении В используются две линии, на которые контроллер турникета выдает импульсные сигналы при совершении прохода в том либо другом направлении. Данные импульсные сигналы подключаются к входам SENS1 для прохода в направлении А и SENS2 для прохода в направлении В.

Например, для работы с турникетами PERCo в контроллере должен быть установлен импульсный режим управления. Для этого время срабатывания сигналов L1 OUT и L2 OUT должно быть установлено в пределах от 0,2 до 1 секунды.

Как описано в самом начале статьи, по нашему техническому заданию, на терминале должна была быть организована фотофиксация, поэтому решили выбрать камеру от Raspberry, которая в терминалах имеет 2 исполнения:

1. RPi D - 72.4 градуса обзор, 5 mpx, размер камеры 25x24 мм (старое исполнение).

2. RPi G - 160 градусов обзор, 5 mpx, размер камеры 25x24 мм (теперь используем только этот вариант).

Выбирая дисплей, выбор снова пал на знакомый бренд - 7-ми дюймовый touch-screen от Raspberry с разрешением 800x480 и DSI интерфейсом.

Исходя из размеров дисплея, считывателя и общей компоновки плат, были определены габариты корпуса для терминала - 210 x 173 x 44. Корпус решено было сделать цельнометаллическим алюминиевыми с гальваническим покрытием, что обеспечивало хотя бы минимальную вандалоустойчивость. Дисплей, конечно же, так не защищен.

Собрав все воедино мы получили терминал данного вида.

Немного отклоняясь от темы, можно сказать, что мы были обмануты Raspberry, когда они в 4-ом поколении Compute Module поменяли форм-фактор и мы уже не смогли его просто заменить в нашей текущей плате и были вынуждены переходить на новое поколение путем разработки новой платы, но об этом в следующих статьях.

На данный момент с 2019 года нашей компаний было продано более 500 терминалов данной модели, а это показывает, что решение оказалось весьма успешным и надежным. В данной статье я коснулся лишь одной части - железа, однако большая работа была проделана и над прошивкой терминала. В следующей статье я расскажу, как реализована программная часть терминала. В случае возникновения вопросов или критических замечаний, прошу последовать в комментарии для бурного обсуждения!