Русский
Русский
English
Статистика
Реклама

Контроля

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

10.05.2021 14:18:51 | Автор: admin

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

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

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

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

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

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

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

Подробнее..

О системах контроля версий

30.09.2020 12:15:28 | Автор: admin
Всем привет! Уже на следующей неделе в OTUS стартует Супер-практикум по использованию и настройке GIT. Этому я и решил посвятить сегодняшнюю публикацию.



Введение


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


Системы контроля версий


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

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

Copy-paste


Известный метод при применении к данной задаче может выглядеть следующим образом: будем называть файлы по шаблону filename_{version}, возможно с добавлением времени создания или изменения.

Данный способ является очень простым, но он подвержен различным ошибкам: можно случайно изменить не тот файл, можно скопировать не из той директории (ведь именно так переносятся файлы в этой модели).

Локальная система контроля версий


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

Одним из примеров таких систем является система контроля версий RCS, которая была разработана в 1985 году (последний патч был написан в 2015 году) и хранит изменений в файлах (патчи), осуществляя контроль версий. Набор этих изменений позволяет восстановить любое состояние файла. RCS поставляется с Linux'ом.

Локальная система контроля версий хорошо решает поставленную перед ней задачу, однако ее проблемой является основное свойство локальность. Она совершенно не преднезначена для коллективного использования.

Централизованная система контроля версий


Централизованная система контроля версий предназначена для решения основной проблемы локальной системы контроля версий.

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

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

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

Распределенная система контроля версий


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

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

К данному виду систем контроля версий относятся Mercurial, Bazaar, Darcs и Git. Последняя система контроля версий и будет рассмотрена нами далее более детально.

История Git


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

Заключение


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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru