eng
Выпуск #6/2024
Н.В.Зорина, В.Е.Счетов
Информационная система для автоматизации мониторинга техобслуживания электросетевого хозяйства объектов связи
Информационная система для автоматизации мониторинга техобслуживания электросетевого хозяйства объектов связи
Просмотры: 699
DOI: 10.22184/2070-8963.2024.122.6.30.38
Предлагается ИТ-решение в виде простой, гибкой и масштабируемой системы для автоматической генерации СМС-оповещений, генерации и контроля выполнения заданий, контроля сотрудников мобильных бригад. Описана концепция системы мониторинга и прототип программного продукта, включающий разработанное авторами математическое и программное обеспечение в виде БД и набора программных модулей для реализации необходимого для работы системы функционала. Предложены алгоритмы расчета приоритезации задач на проведение технических работ по обслуживанию и ремонту, оценки объема выполненных работ, рейтинга сотрудников для автоматизации формирования заданий, учета выработки и загруженности персонала.
Предлагается ИТ-решение в виде простой, гибкой и масштабируемой системы для автоматической генерации СМС-оповещений, генерации и контроля выполнения заданий, контроля сотрудников мобильных бригад. Описана концепция системы мониторинга и прототип программного продукта, включающий разработанное авторами математическое и программное обеспечение в виде БД и набора программных модулей для реализации необходимого для работы системы функционала. Предложены алгоритмы расчета приоритезации задач на проведение технических работ по обслуживанию и ремонту, оценки объема выполненных работ, рейтинга сотрудников для автоматизации формирования заданий, учета выработки и загруженности персонала.
Теги: aios modules electrical equipment maintenance maintenance monitoring maintenance prioritisation management of emergency repair teams mi measurement module power distribution units remer production group second-generation rem power distribution units мониторинг техобслуживания приоретизация техобслуживания техническое обслуживание электрооборудования управление аварийно-восстановительными бригадами
Информационная система для автоматизации мониторинга техобслуживания
электросетевого хозяйства объектов связи
Н.В.Зорина, ст. преподаватель Института искусственного интеллекта
РТУ МИРЭА / zorina_n@mail.ru,
В.Е.Счетов, младший Джава-разработчик ООО "Федаг" / schetov.v.e@edu.mirea.ru
УДК 004.4, DOI: 10.22184/2070-8963.2024.122.6.30.38
Предлагается ИТ-решение в виде простой, гибкой и масштабируемой системы для автоматической генерации СМС-оповещений, генерации и контроля выполнения заданий, контроля сотрудников мобильных бригад. Описана концепция системы мониторинга и прототип программного продукта, включающий разработанное авторами математическое и программное обеспечение в виде БД и набора программных модулей для реализации необходимого для работы системы функционала. Предложены алгоритмы расчета приоритезации задач на проведение технических работ по обслуживанию и ремонту, оценки объема выполненных работ, рейтинга сотрудников для автоматизации формирования заданий, учета выработки и загруженности персонала.
Введение
Обеспечение гарантированным электропитанием является важной задачей организации систем жизнеобеспечения стационарных и мобильных сетей связи. Организация круглосуточного бесперебойного обслуживания требует больших затрат времени и сил работников. В статье рассмотрена информационная система, которая автоматизирует процессы организации и проведения обслуживания элементов электрохозяйства, обеспечивающих бесперебойную работу телекоммуникационного оборудования, что помогает снизить нагрузку работников и менеджеров, а также упростить и сделать более качественным обслуживание сетей связи.
Цель работы
Целью работы является создание прототипа ИТ-системы для управления аварийно-восстановительными бригадами, мониторинга и контроля проведения технического обслуживания электросетевого хозяйства объектов связи с использованием централизованного подхода в обслуживании станций.
Основными задачами проведения технического обслуживания (ТО) электросетевого хозяйства являются следующие:
Централизация и оптимизация технического персонала требует проведения регулярного ТО для сокращения аварийных работ и поддержания требуемого уровня качества услуг связи. Персонал посещает станции только для устранения неисправностей или для выполнения определенных видов работ на месте [1]. Такой подход обеспечит снижение совокупности стоимости эксплуатации всех объектов за счет оптимизации персонала и увеличения выработки на одного сотрудника.
Виды работ при проведении технического обслуживания объектов электрохозяйства
В обслуживании электроподстанций выделяют три вида работ [2]:
Наиболее сложной является задача управления и планирования работ в условиях ограниченного ресурса. Менеджеры должны отслеживать график выполнения работ на каждой станции, график сотрудников, распределять наряды, отслеживать объем и качество выполненных работ, готовить отчеты [2].
Приоритезация обслуживания электроподстанций
Для оценки рисков повреждения производственных активов применяются матрицы приоритезации для оборудования [3]. Исходными данными для матрицы приоритезации в случае обслуживания электроподстанций предлагается взять предварительно рассчитанные, находящиеся в актуальном состоянии:
В результате формирования приоритезированного перечня производственные активы сортируются по мере уменьшения вероятности отказа по техническим причинам и потенциальным последствиям отказа. Наименьший номер приоритета в группе выбранного оборудования определяет наивысший приоритет необходимости осуществления технического воздействия (замены или технического обслуживания и ремонта). Матрица приоритезации для целей обобщенного анализа приведена в табл.1.
На рис.1 представлены диаграмма в нотации IDEF0 процесса обслуживания. На ней приведены следующие входные информационные потоки:
Также на вход системы подаются такие ограничения, как: правила организации работ, правила эксплуатации станций и технический регламент. Из материальных ресурсов в процессе задействуется: ПК менеджера (сервер) и мобильный ПК (смартфон) оператора, необходимый для его взаимодействия с информацией о задачах.
Процесс обслуживания подстанций формирует на выход такие информационные потоки:
На диаграмме отображены пять основных подпроцессов:
Процесс генерации заданий, в который поступает информация о плановых работах, об авариях, а также внеплановых работах, которые будут описаны далее. Из материальных ресурсов для этого процесса необходим ПК менеджера, который непосредственно генерирует задания, принимая в расчет правила обслуживания и эксплуатации телефонных станций.
Процесс подтверждения заданий менеджером, в котором он, получая информацию о работниках, назначает их на выполнение задач, а также разрабатывает текст сообщений для СМС-рассылки.
Процесс выполнения задания, в ходе которого работники обслуживают подстанцию, руководствуясь правилами эксплуатации телефонных станций, а также техническим регламентом выполнения работ. На выходе мы получаем информацию о выполнении работ сотрудниками.
Процесс отправки СМС-оповещений, в ходе которого граждане оповещаются об отключении связи, если это необходимо, а также о сроках устранения аварий.
Процесс контроля за выполнением работ, который получает информацию о выполнении заданий, информацию о местоположении работника и информацию о работниках, на выходе мы получаем актуальные рейтинги работника. Этот процесс в свою очередь декомпозируется на два подпроцесса: контроль во время выполнения работ, а также пост-анализ, с помощью которого и обновляется рейтинг работников.
Техническое задание на разработку системы должно содержать следующие пункты и обеспечивать выполнение следующих функций:
Наличие личного кабинета менеджера, где доступны следующие функции:
Наличие личного кабинета работника, производящего работы по обслуживанию, со следующими функциями:
Функция рассылки СМС-уведомлений клиентам (автоматическая, два вида: информация об аварии и сроках устранения, информация о плановых отключениях связи).
Функция хранения регламентов обслуживания для автоматического составления списка необходимых работ на объекте.
Функция отправки автоматического сигнала об аварии при помощи датчиков, размещенных в подстанциях (прим. система контроля за показателями в статье не рассматривается, берется готовый сигнал об аварии).
В качестве математического обеспечения для автоматизации процессов были разработаны два основных алгоритма: расчета рейтинга работника, а также приоритезации задач.
Алгоритм расчета рейтинга работника
Алгоритм расчета рейтинга (эффективности) предполагает хранение в базе данных следующих данных:
актуальный рейтинг работника (rating) от 0 до 100%, начальная величина 100%;
информация о задании (task), в том числе:
время старта выполнения в формате timestamp (timestart);
время окончания выполнения в формате timestamp (timeend);
виды работ в задании (typesOfWork), для каждого расчетное время выполнения в человеко-часах (timeHuman).
Предполагается, что алгоритм в системе запускается раз в сутки в определенное время после окончания рабочего дня.
Далее приведем описание последовательности шагов работы алгоритма:
Получить из базы данных список всех задач, выполненных в этот день.
Анализировать каждую задачу. Для каждой задачи получить список работников.
Высчитать время выполнения задания в минутах для большей точности (timeminutes)
timeminutes = (task.timestart – task.timeend)minutes.
Перевести время выполнения в часы (далее все дробные вычисления идут с точностью до двух знаков после запятой):
.
Далее вычислить суммарное расчетное время выполнения задачи:
timehuman = ∑typesOfWorktimeHuman.
Вычислить отклонение реального времени от расчетного в человеко-часах:
,
где countworkers – количество работников, выполнявших задачу.
Мы предлагаем ввести шкалу рейтинга, чтобы удобно представлять его в процентах. Кроме того, визуальный контроль позволяет оценить менеджеру оперативность сотрудника, что важно при выполнении срочных задач. Возьмем максимальное опоздание за 6 человеко-часов, а минимальное опоздание – за 0 человеко-часов. Пусть рейтинг работника считается как среднее опоздание в человеко-часах от –6 до 0. В случае выхода за эти границы среднее округляется до одной из них. Итоговый рейтинг переводится в проценты, где –6 – 0%, а 0 – 100%.
Анализировать каждого работника, выполнявшего задачу. Для каждого работника получить рейтинг в процентах, хранящийся в БД (rating), а также из БД получить количество прошлых задач (nold).
Получить из рейтинга среднее опоздание в процентах по шкале (rcoefficient):
.
Посчитать новое среднее опоздание с учетом новой задачи:
.
Новое среднее сопоставить со шкалой:
.
Посчитать новый рейтинг (newRating) в процентах:
.
После пересчета рейтинга для каждого сотрудника выполнить сохранение новых рейтингов в БД.
Завершить выполнение для каждой задачи.
Данный критерий влияет на фонд оплаты труда и оценку утилизации персонала.
Алгоритм приоритезации задач
Разработанный для системы алгоритм приоритезации задач предполагает хранение следующих данных в БД:
техническое состояние каждой станции (EXCELLENT, GOOD, FAIR, POOR, CRITICAL);
последствия отказа каждой станции (HIGH, MIDDLE, LOW, MINOR);
типы заданий (ACCIDENT, PLANING, NOT_PLANING);
статическая Map у класса сервиса, в которой ключи – это сочетания последствий отказа и технического состояния, а значения – соответствующее значение приоритета по табл.1.
Алгоритм запускается в системе при выполнении менеджером действия: запрос списка неподтвержденных задач.
Опишем пошаговый процесс работы разработанного алгоритма приоритезации задач:
Получаем из БД список неподтвержденных задач.
Разделяем его на три списка по типу задач со следующим приоритетом:
Таким образом самыми приоритетными являются аварийные задачи, ко второму списку отнесены внеплановые. Плановые работы имеют самый низкий приоритет.
Далее рассматриваем каждый список отдельно. Проводим сортировку каждого списка по номеру приоритета, который можно получить по последствиям отказа и техническому состоянию из Map приоритетов.
Объединяем списки в один с приоритетом из п.2 и возвращаем общий список приоритезированных задач.
Для локализации сотрудника используются коммерческие разработки мониторинга на основе систем ГЛОНАСС или GPS.
Аппаратно-программное решение для реализации предлагаемой системы предлагает реализацию следующих функций:
контроля и организации процесса обслуживания телекоммуникационного оборудования;
автоматизированного формирования заданий для сотрудников с использованием информации о регламентах обслуживания из базы данных, а также с помощью получения сигнала об аварии;
отслеживания GPS-треков сотрудников (будет использоваться для сбора статистики о проведении работ, автоматического отслеживания сотрудников, выполняющих задание).
Для реализации функции контроля и организации процесса обслуживания необходимо разработать программный модуль, обеспечивающий автоматическую рассылку СМС-оповещений на номера мобильных телефонов дежурного персонала подразделений, участвующих в проведении работ. Такая рассылка оповещений предполагается для информирования о сроках отключения связи при проведении плановых работ, а также о сроках устранения аварий, в случае их возникновения. Данный модуль будет получать также информацию из заданий, назначенных сотрудникам.
Описание реализации предлагаемой системы автоматизации
Организация системы мониторинга состояния оборудования КТП, ВЭС и ЭПУ осуществляется на базе отдельных контроллеров на базе протоколов SNMP, групп сухих контактов и встроенной системы мониторинга электропитающего оборудования. Подключение к сети Интернет осуществляется через служебные каналы, мобильные сети операторов. Схематично это решение изображено на рис.2.
Чтобы лучше сформировать структуру нашей системы, начнем с описания внешних сущностей, с которыми она взаимодействует. Для этого рассмотрим диаграмму в нотации DFD, приведенную на рис.3.
Рассмотрев данную диаграмму, можно выделить несколько основных сущностей, с которыми взаимодействует система. Первые две сущности – это интерфейсы двух основных ролей системы: менеджера и работника.
Через эти интерфейсы они взаимодействуют с системой. Интерфейс работника находится на его мобильном ПК, что позволяет ему получать информацию о заданиях, а также передавать результаты их выполнения прямо во время работы на объектах. Интерфейс менеджера разворачивается на его офисном компьютере. Также с системой взаимодействует контроллер, размещенный на станции, о работе которого было рассказано выше.
Важной внешней сущностью является сервер хранения данных, на котором находится база данных системы, в которой хранится вся необходимая информация. Прежде чем обсуждать саму реализацию предлагаемой системы, необходимо разобраться с моделью данных, которая необходима для описания нашего процесса. Данные классы должны быть описаны в системе, а также однозначно отображены в БД в реляционной форме.
Первый класс – это класс "Менеджер". Нам необходимо хранить его личные данные (фамилия, имя и отчество), а также логин и пароль для входа в свой аккаунт. С менеджером также связана сущность "Сообщение" (мы помним о том, что менеджер может генерировать сообщения для СМС-рассылки), в этом классе хранится текст сообщения, а также ссылка на менеджера, которым оно было сгенерировано.
Следующий большой класс, с которым связана сущность менеджера, – это класс "Работник". Для работника у нас также хранятся его личные данные, логин и пароль для входа в личный кабинет. Также для работника необходимо хранить рейтинг, процесс расчета которого был описан выше; id подстанции, на которой работник находится в настоящий момент (актуальное местоположение); номер метки UWB, которую использует работник. Также для отслеживания менеджером работников, у каждого объекта работника в системе хранится ссылка на менеджера, к которому он прикреплен. И, конечно, у объекта класса "Работник" хранится список задач, которые он выполнял и выполняет.
Рассмотрим класс "Задача". В нем хранится информация о верификации задачи (одобрена она менеджером или нет), также в ней хранится дата создания, время начала работ и время завершения работ. Также в задаче хранятся ссылки на ее тип, ее состояние, подстанция, на которой она выполняется, и список типов работ, которые необходимо на ней выполнить.
"Состояние задачи" и "Тип задачи" – это классы, которые внутри хранят значение из словаря. Словарь типов задач содержит три описанных выше вида (аварийные, плановые, внеплановые), а словарь состояний задачи описывает такие состояние, как "не начата", "в работе", "завершена". Класс "Тип работы" требует более подробного описания. В нем хранится информация о названии работы, ее описании (описание хранится ссылкой на объект отдельного класса, хранящего текст описания), а также о периоде профилактического повторения работ и норме ее выполнения в человеко-часах.
"Подстанция" – отдельный большой класс. О подстанциях хранится следующая информация: логин и пароль для авторизации контроллера подстанции в системе, уникальный код регистрации, использующийся при первой инициализации подстанции в системе, имя хоста, список которых позволяет настроить Cors Polisy в модуле связи с контроллерами подстанций в системе. Также хранятся: последствия отказа, состояние подстанции и техническое состояние подстанции. Хранится эта информация ссылками на объекты, содержащие в себе значения словарей. Словари последствий отказа и технического состояния взяты из табл.1. Их хранение в системе обусловлено задачей приоритезации. Словарь состояний подстанции хранит в себе три значения: "РАБОТАЕТ", "В РЕМОНТЕ", "АВАРИЯ".
Далее более подробно рассмотрим структуру сервера обработки данных, которая подробно представлена на рис.4. Первый сервис, который напрямую не относится к серверу обработки данных, но при этом все равно требует описания – это сервис контроллера подстанции, на котором будет выполняться код, занимающийся двумя основными вещами: отправкой сообщения об аварии и отправкой актуальной информации о присутствующих сотрудниках.
Начнем рассмотрение с сообщений об аварии. Такие сообщения отправляются в сервис связи с подстанциями, который реализован с помощью фреймворка Spring Web Flux, обеспечивающего асинхронную обработку данных. Там он проходит необходимую аутентификацию, после чего сообщение об аварии направляется в сервер-брокер (используется Kafka), в котором находятся еще несколько очередей, назначение которых описано ниже. Очередь сообщений об аварии прослушивает сервис генерации заданий (также реализован на асинхронном веб-фреймворке от Spring, чтобы повысить эффективность операций), который выполняет свою работу на основе этих сообщений, а также на основе информации из базы данных (используется СУБД PostgreSQL) о плановом обслуживании конкретных подстанций, а также в том же брокере прослушивает очередь, в которую отправляются сообщения о создании дополнительных задач на обслуживание из личного кабинета работника.
Задание, сгенерированное прошлым сервисом, сохраняется в базу данных, откуда его запрашивает сервис кабинета менеджера для подтверждения. Также этот сервис запрашивает информацию о работниках и объектах обслуживания.
После успешного подтверждения задания сервис менеджера генерирует сообщение для СМС-рассылки, которое попадает в очередь сообщений брокера. Из брокера сообщение попадает в сервис СМС-рассылки, из которого происходит оповещение.
Теперь вернемся к отправке информации с меток сотрудников. Она сохраняется в базу данных. Также последний нерассмотренный нами сервис – личный кабинет работника. Он получает информацию об актуальных заданиях из базы данных, а также отправляет подтверждения о выполнении работ и сообщения о создании внеплановых заданий, о которых говорилось выше. Сервисы работника, менеджера и отправки СМС реализованы с помощью классического синхронного веб-фреймворка Spring Boot.
Также стоит отметить, что сервисы кабинетов менеджера и работника связаны с внешними серверами веб-интерфейсов для менеджеров и работников, через которые те осуществляют взаимодействие с системой.
Заключение
Предлагаемое решение в виде информационной системы для автоматизации мониторинга работ по техническому обслуживанию электросетевого хозяйства объектов связи позволит проводить дистанционное наблюдение за выполнением назначенных работ, осуществляя контроль состояния действующего оборудования, тем самым снижая вероятность появления нештатных и аварийных ситуаций.
Основное преимущество предлагаемого решения заключается в возможности спрогнозировать изменения технического состояния оборудования и перейти к организации технического обслуживания и ремонта основного сетевого оборудования по его фактическому состоянию, а накапливаемая в системе информация может использоваться в дальнейшем для анализа и поддержки принятия решений.
ЛИТЕРАТУРА
Стандарт СТО 34.01-24-002-2021. Организация технического обслуживания и ремонта объектов электросетевого хозяйства: стандарт организации группы "РОССЕТИ" [Электронный ресурс]. URL: https://rosseti.ru/upload/iblock/edb/93cjbu3o8pfgjjc3sdv234692ukukigd.pdf (дата обращения: 18.07.2024).
Ремонт электрооборудования [Электронный ресурс]. URL: https://www.air-ventilation.ru/Remont-elektrooborudovaniya.htm (дата обращения 18.07.2024).
Матрица Эйзенхауэра [Электронный ресурс]. URL: https://roistat.com/rublog/matrica-jejzenhaujera/ (дата обращения10.07.2024.
электросетевого хозяйства объектов связи
Н.В.Зорина, ст. преподаватель Института искусственного интеллекта
РТУ МИРЭА / zorina_n@mail.ru,
В.Е.Счетов, младший Джава-разработчик ООО "Федаг" / schetov.v.e@edu.mirea.ru
УДК 004.4, DOI: 10.22184/2070-8963.2024.122.6.30.38
Предлагается ИТ-решение в виде простой, гибкой и масштабируемой системы для автоматической генерации СМС-оповещений, генерации и контроля выполнения заданий, контроля сотрудников мобильных бригад. Описана концепция системы мониторинга и прототип программного продукта, включающий разработанное авторами математическое и программное обеспечение в виде БД и набора программных модулей для реализации необходимого для работы системы функционала. Предложены алгоритмы расчета приоритезации задач на проведение технических работ по обслуживанию и ремонту, оценки объема выполненных работ, рейтинга сотрудников для автоматизации формирования заданий, учета выработки и загруженности персонала.
Введение
Обеспечение гарантированным электропитанием является важной задачей организации систем жизнеобеспечения стационарных и мобильных сетей связи. Организация круглосуточного бесперебойного обслуживания требует больших затрат времени и сил работников. В статье рассмотрена информационная система, которая автоматизирует процессы организации и проведения обслуживания элементов электрохозяйства, обеспечивающих бесперебойную работу телекоммуникационного оборудования, что помогает снизить нагрузку работников и менеджеров, а также упростить и сделать более качественным обслуживание сетей связи.
Цель работы
Целью работы является создание прототипа ИТ-системы для управления аварийно-восстановительными бригадами, мониторинга и контроля проведения технического обслуживания электросетевого хозяйства объектов связи с использованием централизованного подхода в обслуживании станций.
Основными задачами проведения технического обслуживания (ТО) электросетевого хозяйства являются следующие:
- контроль за состоянием систем внешнего электроснабжения, ЭПУ и АКБ;
- проверка их работоспособности, плановые технологические работы (очистка, контроль системы охлаждения, проверка изоляции);
- другие работы, предотвращающие аварийные ситуации.
Централизация и оптимизация технического персонала требует проведения регулярного ТО для сокращения аварийных работ и поддержания требуемого уровня качества услуг связи. Персонал посещает станции только для устранения неисправностей или для выполнения определенных видов работ на месте [1]. Такой подход обеспечит снижение совокупности стоимости эксплуатации всех объектов за счет оптимизации персонала и увеличения выработки на одного сотрудника.
Виды работ при проведении технического обслуживания объектов электрохозяйства
В обслуживании электроподстанций выделяют три вида работ [2]:
- плановое ТО – регулярное обслуживание (проводится по постоянному графику);
- планово-профилактические работы – нерегулярное обслуживание (проводится при выявлении неисправностей в ходе регулярного обслуживания и необходимости проведения дополнительных длительных работ по их устранению, не является незамедлительным);
- аварийное обслуживание (проводится в срочном порядке по факту происшествия на подстанции или аварии).
Наиболее сложной является задача управления и планирования работ в условиях ограниченного ресурса. Менеджеры должны отслеживать график выполнения работ на каждой станции, график сотрудников, распределять наряды, отслеживать объем и качество выполненных работ, готовить отчеты [2].
Приоритезация обслуживания электроподстанций
Для оценки рисков повреждения производственных активов применяются матрицы приоритезации для оборудования [3]. Исходными данными для матрицы приоритезации в случае обслуживания электроподстанций предлагается взять предварительно рассчитанные, находящиеся в актуальном состоянии:
- индекс технического состояния;
- последствия отказа.
В результате формирования приоритезированного перечня производственные активы сортируются по мере уменьшения вероятности отказа по техническим причинам и потенциальным последствиям отказа. Наименьший номер приоритета в группе выбранного оборудования определяет наивысший приоритет необходимости осуществления технического воздействия (замены или технического обслуживания и ремонта). Матрица приоритезации для целей обобщенного анализа приведена в табл.1.
На рис.1 представлены диаграмма в нотации IDEF0 процесса обслуживания. На ней приведены следующие входные информационные потоки:
- информация о сотрудниках;
- информация о плановых работах;
- информация об авариях;
- информация о местоположении работников.
Также на вход системы подаются такие ограничения, как: правила организации работ, правила эксплуатации станций и технический регламент. Из материальных ресурсов в процессе задействуется: ПК менеджера (сервер) и мобильный ПК (смартфон) оператора, необходимый для его взаимодействия с информацией о задачах.
Процесс обслуживания подстанций формирует на выход такие информационные потоки:
- СМС-оповещения заинтересованных участников о событии;
- сгенерированные задания для работников;
- информация о выполнении заданий работниками;
- рейтинг работника (оценка эффективности).
На диаграмме отображены пять основных подпроцессов:
Процесс генерации заданий, в который поступает информация о плановых работах, об авариях, а также внеплановых работах, которые будут описаны далее. Из материальных ресурсов для этого процесса необходим ПК менеджера, который непосредственно генерирует задания, принимая в расчет правила обслуживания и эксплуатации телефонных станций.
Процесс подтверждения заданий менеджером, в котором он, получая информацию о работниках, назначает их на выполнение задач, а также разрабатывает текст сообщений для СМС-рассылки.
Процесс выполнения задания, в ходе которого работники обслуживают подстанцию, руководствуясь правилами эксплуатации телефонных станций, а также техническим регламентом выполнения работ. На выходе мы получаем информацию о выполнении работ сотрудниками.
Процесс отправки СМС-оповещений, в ходе которого граждане оповещаются об отключении связи, если это необходимо, а также о сроках устранения аварий.
Процесс контроля за выполнением работ, который получает информацию о выполнении заданий, информацию о местоположении работника и информацию о работниках, на выходе мы получаем актуальные рейтинги работника. Этот процесс в свою очередь декомпозируется на два подпроцесса: контроль во время выполнения работ, а также пост-анализ, с помощью которого и обновляется рейтинг работников.
Техническое задание на разработку системы должно содержать следующие пункты и обеспечивать выполнение следующих функций:
Наличие личного кабинета менеджера, где доступны следующие функции:
- просмотр списка сотрудников;
- просмотр личной странички сотрудника со статистикой и актуальным местоположением на одном из объектов;
- информация о всех объектах с историей обслуживания;
- задачи с актуальными авариями (необходимо устранять немедленно);
- задачи для объектов, у которых необходимо провести плановую работу;
- задачи на проведение внеплановых работ на объектах (ремонтных работ после ТО);
- возможность назначить на задачу работников (вручную или автоматически).
Наличие личного кабинета работника, производящего работы по обслуживанию, со следующими функциями:
- просмотр списка задач;
- список необходимого обслуживания для каждой задачи;
- возможность для сотрудника поставить отметку под каждым пунктом о выполнении данного вида работ;
- возможность отправить запрос на создание задачи по внеплановым работам.
Функция рассылки СМС-уведомлений клиентам (автоматическая, два вида: информация об аварии и сроках устранения, информация о плановых отключениях связи).
Функция хранения регламентов обслуживания для автоматического составления списка необходимых работ на объекте.
Функция отправки автоматического сигнала об аварии при помощи датчиков, размещенных в подстанциях (прим. система контроля за показателями в статье не рассматривается, берется готовый сигнал об аварии).
В качестве математического обеспечения для автоматизации процессов были разработаны два основных алгоритма: расчета рейтинга работника, а также приоритезации задач.
Алгоритм расчета рейтинга работника
Алгоритм расчета рейтинга (эффективности) предполагает хранение в базе данных следующих данных:
актуальный рейтинг работника (rating) от 0 до 100%, начальная величина 100%;
информация о задании (task), в том числе:
время старта выполнения в формате timestamp (timestart);
время окончания выполнения в формате timestamp (timeend);
виды работ в задании (typesOfWork), для каждого расчетное время выполнения в человеко-часах (timeHuman).
Предполагается, что алгоритм в системе запускается раз в сутки в определенное время после окончания рабочего дня.
Далее приведем описание последовательности шагов работы алгоритма:
Получить из базы данных список всех задач, выполненных в этот день.
Анализировать каждую задачу. Для каждой задачи получить список работников.
Высчитать время выполнения задания в минутах для большей точности (timeminutes)
timeminutes = (task.timestart – task.timeend)minutes.
Перевести время выполнения в часы (далее все дробные вычисления идут с точностью до двух знаков после запятой):
.
Далее вычислить суммарное расчетное время выполнения задачи:
timehuman = ∑typesOfWorktimeHuman.
Вычислить отклонение реального времени от расчетного в человеко-часах:
,
где countworkers – количество работников, выполнявших задачу.
Мы предлагаем ввести шкалу рейтинга, чтобы удобно представлять его в процентах. Кроме того, визуальный контроль позволяет оценить менеджеру оперативность сотрудника, что важно при выполнении срочных задач. Возьмем максимальное опоздание за 6 человеко-часов, а минимальное опоздание – за 0 человеко-часов. Пусть рейтинг работника считается как среднее опоздание в человеко-часах от –6 до 0. В случае выхода за эти границы среднее округляется до одной из них. Итоговый рейтинг переводится в проценты, где –6 – 0%, а 0 – 100%.
Анализировать каждого работника, выполнявшего задачу. Для каждого работника получить рейтинг в процентах, хранящийся в БД (rating), а также из БД получить количество прошлых задач (nold).
Получить из рейтинга среднее опоздание в процентах по шкале (rcoefficient):
.
Посчитать новое среднее опоздание с учетом новой задачи:
.
Новое среднее сопоставить со шкалой:
.
Посчитать новый рейтинг (newRating) в процентах:
.
После пересчета рейтинга для каждого сотрудника выполнить сохранение новых рейтингов в БД.
Завершить выполнение для каждой задачи.
Данный критерий влияет на фонд оплаты труда и оценку утилизации персонала.
Алгоритм приоритезации задач
Разработанный для системы алгоритм приоритезации задач предполагает хранение следующих данных в БД:
техническое состояние каждой станции (EXCELLENT, GOOD, FAIR, POOR, CRITICAL);
последствия отказа каждой станции (HIGH, MIDDLE, LOW, MINOR);
типы заданий (ACCIDENT, PLANING, NOT_PLANING);
статическая Map у класса сервиса, в которой ключи – это сочетания последствий отказа и технического состояния, а значения – соответствующее значение приоритета по табл.1.
Алгоритм запускается в системе при выполнении менеджером действия: запрос списка неподтвержденных задач.
Опишем пошаговый процесс работы разработанного алгоритма приоритезации задач:
Получаем из БД список неподтвержденных задач.
Разделяем его на три списка по типу задач со следующим приоритетом:
- ACCIDENT – 1;
- NOT_PLANING – 2;
- PLANING – 3.
Таким образом самыми приоритетными являются аварийные задачи, ко второму списку отнесены внеплановые. Плановые работы имеют самый низкий приоритет.
Далее рассматриваем каждый список отдельно. Проводим сортировку каждого списка по номеру приоритета, который можно получить по последствиям отказа и техническому состоянию из Map приоритетов.
Объединяем списки в один с приоритетом из п.2 и возвращаем общий список приоритезированных задач.
Для локализации сотрудника используются коммерческие разработки мониторинга на основе систем ГЛОНАСС или GPS.
Аппаратно-программное решение для реализации предлагаемой системы предлагает реализацию следующих функций:
контроля и организации процесса обслуживания телекоммуникационного оборудования;
автоматизированного формирования заданий для сотрудников с использованием информации о регламентах обслуживания из базы данных, а также с помощью получения сигнала об аварии;
отслеживания GPS-треков сотрудников (будет использоваться для сбора статистики о проведении работ, автоматического отслеживания сотрудников, выполняющих задание).
Для реализации функции контроля и организации процесса обслуживания необходимо разработать программный модуль, обеспечивающий автоматическую рассылку СМС-оповещений на номера мобильных телефонов дежурного персонала подразделений, участвующих в проведении работ. Такая рассылка оповещений предполагается для информирования о сроках отключения связи при проведении плановых работ, а также о сроках устранения аварий, в случае их возникновения. Данный модуль будет получать также информацию из заданий, назначенных сотрудникам.
Описание реализации предлагаемой системы автоматизации
Организация системы мониторинга состояния оборудования КТП, ВЭС и ЭПУ осуществляется на базе отдельных контроллеров на базе протоколов SNMP, групп сухих контактов и встроенной системы мониторинга электропитающего оборудования. Подключение к сети Интернет осуществляется через служебные каналы, мобильные сети операторов. Схематично это решение изображено на рис.2.
Чтобы лучше сформировать структуру нашей системы, начнем с описания внешних сущностей, с которыми она взаимодействует. Для этого рассмотрим диаграмму в нотации DFD, приведенную на рис.3.
Рассмотрев данную диаграмму, можно выделить несколько основных сущностей, с которыми взаимодействует система. Первые две сущности – это интерфейсы двух основных ролей системы: менеджера и работника.
Через эти интерфейсы они взаимодействуют с системой. Интерфейс работника находится на его мобильном ПК, что позволяет ему получать информацию о заданиях, а также передавать результаты их выполнения прямо во время работы на объектах. Интерфейс менеджера разворачивается на его офисном компьютере. Также с системой взаимодействует контроллер, размещенный на станции, о работе которого было рассказано выше.
Важной внешней сущностью является сервер хранения данных, на котором находится база данных системы, в которой хранится вся необходимая информация. Прежде чем обсуждать саму реализацию предлагаемой системы, необходимо разобраться с моделью данных, которая необходима для описания нашего процесса. Данные классы должны быть описаны в системе, а также однозначно отображены в БД в реляционной форме.
Первый класс – это класс "Менеджер". Нам необходимо хранить его личные данные (фамилия, имя и отчество), а также логин и пароль для входа в свой аккаунт. С менеджером также связана сущность "Сообщение" (мы помним о том, что менеджер может генерировать сообщения для СМС-рассылки), в этом классе хранится текст сообщения, а также ссылка на менеджера, которым оно было сгенерировано.
Следующий большой класс, с которым связана сущность менеджера, – это класс "Работник". Для работника у нас также хранятся его личные данные, логин и пароль для входа в личный кабинет. Также для работника необходимо хранить рейтинг, процесс расчета которого был описан выше; id подстанции, на которой работник находится в настоящий момент (актуальное местоположение); номер метки UWB, которую использует работник. Также для отслеживания менеджером работников, у каждого объекта работника в системе хранится ссылка на менеджера, к которому он прикреплен. И, конечно, у объекта класса "Работник" хранится список задач, которые он выполнял и выполняет.
Рассмотрим класс "Задача". В нем хранится информация о верификации задачи (одобрена она менеджером или нет), также в ней хранится дата создания, время начала работ и время завершения работ. Также в задаче хранятся ссылки на ее тип, ее состояние, подстанция, на которой она выполняется, и список типов работ, которые необходимо на ней выполнить.
"Состояние задачи" и "Тип задачи" – это классы, которые внутри хранят значение из словаря. Словарь типов задач содержит три описанных выше вида (аварийные, плановые, внеплановые), а словарь состояний задачи описывает такие состояние, как "не начата", "в работе", "завершена". Класс "Тип работы" требует более подробного описания. В нем хранится информация о названии работы, ее описании (описание хранится ссылкой на объект отдельного класса, хранящего текст описания), а также о периоде профилактического повторения работ и норме ее выполнения в человеко-часах.
"Подстанция" – отдельный большой класс. О подстанциях хранится следующая информация: логин и пароль для авторизации контроллера подстанции в системе, уникальный код регистрации, использующийся при первой инициализации подстанции в системе, имя хоста, список которых позволяет настроить Cors Polisy в модуле связи с контроллерами подстанций в системе. Также хранятся: последствия отказа, состояние подстанции и техническое состояние подстанции. Хранится эта информация ссылками на объекты, содержащие в себе значения словарей. Словари последствий отказа и технического состояния взяты из табл.1. Их хранение в системе обусловлено задачей приоритезации. Словарь состояний подстанции хранит в себе три значения: "РАБОТАЕТ", "В РЕМОНТЕ", "АВАРИЯ".
Далее более подробно рассмотрим структуру сервера обработки данных, которая подробно представлена на рис.4. Первый сервис, который напрямую не относится к серверу обработки данных, но при этом все равно требует описания – это сервис контроллера подстанции, на котором будет выполняться код, занимающийся двумя основными вещами: отправкой сообщения об аварии и отправкой актуальной информации о присутствующих сотрудниках.
Начнем рассмотрение с сообщений об аварии. Такие сообщения отправляются в сервис связи с подстанциями, который реализован с помощью фреймворка Spring Web Flux, обеспечивающего асинхронную обработку данных. Там он проходит необходимую аутентификацию, после чего сообщение об аварии направляется в сервер-брокер (используется Kafka), в котором находятся еще несколько очередей, назначение которых описано ниже. Очередь сообщений об аварии прослушивает сервис генерации заданий (также реализован на асинхронном веб-фреймворке от Spring, чтобы повысить эффективность операций), который выполняет свою работу на основе этих сообщений, а также на основе информации из базы данных (используется СУБД PostgreSQL) о плановом обслуживании конкретных подстанций, а также в том же брокере прослушивает очередь, в которую отправляются сообщения о создании дополнительных задач на обслуживание из личного кабинета работника.
Задание, сгенерированное прошлым сервисом, сохраняется в базу данных, откуда его запрашивает сервис кабинета менеджера для подтверждения. Также этот сервис запрашивает информацию о работниках и объектах обслуживания.
После успешного подтверждения задания сервис менеджера генерирует сообщение для СМС-рассылки, которое попадает в очередь сообщений брокера. Из брокера сообщение попадает в сервис СМС-рассылки, из которого происходит оповещение.
Теперь вернемся к отправке информации с меток сотрудников. Она сохраняется в базу данных. Также последний нерассмотренный нами сервис – личный кабинет работника. Он получает информацию об актуальных заданиях из базы данных, а также отправляет подтверждения о выполнении работ и сообщения о создании внеплановых заданий, о которых говорилось выше. Сервисы работника, менеджера и отправки СМС реализованы с помощью классического синхронного веб-фреймворка Spring Boot.
Также стоит отметить, что сервисы кабинетов менеджера и работника связаны с внешними серверами веб-интерфейсов для менеджеров и работников, через которые те осуществляют взаимодействие с системой.
Заключение
Предлагаемое решение в виде информационной системы для автоматизации мониторинга работ по техническому обслуживанию электросетевого хозяйства объектов связи позволит проводить дистанционное наблюдение за выполнением назначенных работ, осуществляя контроль состояния действующего оборудования, тем самым снижая вероятность появления нештатных и аварийных ситуаций.
Основное преимущество предлагаемого решения заключается в возможности спрогнозировать изменения технического состояния оборудования и перейти к организации технического обслуживания и ремонта основного сетевого оборудования по его фактическому состоянию, а накапливаемая в системе информация может использоваться в дальнейшем для анализа и поддержки принятия решений.
ЛИТЕРАТУРА
Стандарт СТО 34.01-24-002-2021. Организация технического обслуживания и ремонта объектов электросетевого хозяйства: стандарт организации группы "РОССЕТИ" [Электронный ресурс]. URL: https://rosseti.ru/upload/iblock/edb/93cjbu3o8pfgjjc3sdv234692ukukigd.pdf (дата обращения: 18.07.2024).
Ремонт электрооборудования [Электронный ресурс]. URL: https://www.air-ventilation.ru/Remont-elektrooborudovaniya.htm (дата обращения 18.07.2024).
Матрица Эйзенхауэра [Электронный ресурс]. URL: https://roistat.com/rublog/matrica-jejzenhaujera/ (дата обращения10.07.2024.
Отзывы читателей
