Урв

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

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

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

Как обычно происходит процесс обхода маршрутов (если проходит)

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

Поэтому хотелось бы описать одну реальную историю, которая произошла несколько лет назад. Одна известная компания, которой свойственны все проблемы, описанные выше, обратилась к нам и запросила дополнительный функционал для нашего ПО, которым они уже давно пользовались (облачная система учета рабочего времени 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), благодаря чему руководство смогло всегда знать, какой сотрудник прошел маршрут не по расписанию или же допустил какие-нибудь нарушения.

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

Вступление

Ранее, в предыдущих статьях, я рассказывал о бизнес-процессах, которые можно закрыть различными решениями нашего программного обеспечения, однако настало время рассказать о разработке железа, а именно терминале, который способен служить 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 для подключения кнопок, электромагнитных замков, защёлок, алкостестера в дискретном режиме работы и картаприемников.

Схема реализации Ethernet и USB

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

Схема расширения количества UART-ов

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

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

Suprema-SFM6020-OP6-8M

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

RS-485

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

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

Входной 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 секунды.

Подключение турникета PERCo

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

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

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

Схема организации интерфейсов DSI и CSI

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

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

Корпус терминала

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

Знакомьтесь, терминал D1!

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

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