Increasing efficiency and safety of operation of underground tunnel escalators. The software architecture

Full Text

ВВЕДЕНИЕ

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

В этих условиях для обеспечения своего существования и поддержания надлежащего уровня качества результатов своей деятельности на первый план для организаций выходят задачи динамичной перестройки внутренних бизнес-процессов [3].

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

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

Архитектура [6] в свою очередь определяет интенсивность использования вычислительных ресурсов для обслуживания пользователей, производительность, отказоустойчивость и масштабируемость инфраструктуры, а также скорость выпуска обновлений (релизов). Выбор архитектуры также влияет на величину потребных ресурсов на разработку системы, ее обслуживание и развитие, включая размер наиболее эффективных команд их структуру и формат взаимоотношений между ними.

Цель данной статьи — установить один из возможных вариантов архитектуры программного обеспечения для планирования и контроля проведения технического обслуживания и ремонта эскалаторного хозяйства метрополитена.

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

1. Краткий обзор существующих архитектур в приложении к цели исследования

1.1 Теоретические основы

В основе построения любой архитектуры сложного многофункционального программного обеспечения лежит абстрагирование, а также дробление и инкапсуляция (изоляция), иными словами, расчленение сложных действий на более простые (ограничение бизнес-контекста [7]), имеющие однозначно определяемые входы/выходы и не влияющие на другие, управляемые с более высокого уровня (функциями нижнего уровня описываются сложные действия верхнего (абстрактного) уровня).

Несоблюдение изолированности отдельных логических единиц, разграничивающих (декомпозирующих) логику и ответственность разработчиков, приводит к непредсказуемому влиянию изменений на поведение всей системы и появлению ошибок (сбоев) [8].

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

 

Рис. 1. Уровни абстракции.

Fig. 1. Abstraction levels.

 

Разные архитектуры разделяют логику на компоненты и слои в зависимости от (используемого технологического стека [10]), среды и жизненного цикла программного обеспечения.

В приложение к цели исследования особенности представленного выше разделения логики рассмотрим на примере клиент-серверного подхода.

При клиент-серверном подходе клиентские и серверные компоненты программного обеспечения функционируют физически раздельно, взаимодействуя через согласованный набор команд — API (Application Programming Interface).

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

Клиент-серверный подход [11], приведенный на рис. 2, разделяет логику работы на три подсистемы:

• серверная часть (back-end — BE) — основная логика (ценность);
• клиентская часть (front-end — FE) — пользовательский интерфейс (UX/UI дизайн);
• база данных (BD) — хранилище данных.

Таким образом, в одной подсистеме аккумулировано все, что касается взаимодействия с пользователем, а в другой — вся полезная логика (расчеты/преобразование данных и т. п.).

 

Рис. 2. Упрощенное представление разделения на FE и BE.

Fig. 2. A simplified image of division to FE and BE.

 

Клиент-серверный подход обеспечивает независимое выполнение работ при разработке/тестировании/поддержке в эксплуатации/рефакторинге разнопрофильными специалистами; повышение качества программного обеспечения за счет разграничения зон ответственности и вовлеченности; переход от веб-приложения к мобильному без дополнительных сложностей и ресурсов за счет изоляции BE от FE и использования унифицированных API; простоту адаптации под высокие нагрузки за счет изоляции бизнес логики в отдельные модули, которые проще горизонтально/вертикально масштабировать; уменьшение нагрузки на сетевую инфраструктуру за счет того, что исполняемая логика размещается на сервере.

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

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

1.2 Микросервисная архитектура

Микросервисы позволяют оперативно реагировать на изменения бизнес-требований (ограниченного контекста), сохранять работоспособность, понятность, изолированность и инкапсулированность кода в отдельных связных модулях (сервисах) за счет соблюдения пределов ограниченных контекстов [12].

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

 

Рис. 3. Обобщенный пример микросервисной архитектуры.

Fig. 3. A general example of the microservice architecture.

 

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

Для микросервисной архитектуры также характерно разделение FE и BE на независимые свободно сопряженные приложения — сервисы/микросервисы, обслуживающие определенную функциональную область или отдельные функции, которые могут быть структурированы следующим образом:

1. Через распределение пользовательского интерфейса между несколькими микросервисами с сохранением взаимосвязи с BE. При такой структуре налаживается внутрипроцессное взаимодействие между FE и BE, но усложняется обеспечение связности пользовательского интерфейса (UI), и в случае перекрестных изменений границ UI приходится одновременно обновлять несколько микросервисов, создавая новые взаимосвязи и нарушая изолированность и независимость существующих микро- сервисов.
2. Через разделение пользовательского интерфейса между FE и BE, которое осуществляется таким образом, чтобы UI изолировался одним сервисом и взаимодействовал с BE через стандартные протоколы. При этом UI поддерживается целиком, не теряя связность. Для этой структуры взаимодействия между FE и BE осуществляется либо несколькими небольшими асинхронными HTTP-запросами, исключающими их блокировку, либо выделяется один большой запрос к специализированным сервисам (шлюз/агрегатор/кеш), собирающим данные со всей микросервисной экосистемы.

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

 

Таблица 1. Особенности управления

Table 1. Management features

Особенность	Описание
При управлении гибкостью технологий	С учетом использования разнообразного технического стека при разработке микросервисов из экосистемы при реализации одних и тех же задач должен использоваться одинаковый стек и технологические приемы.
При управлении нестабильностью интерфейса	При внесении изменений в API (ввод/вывод) необходимо контролировать влияние этого изменения на другие микросервисы и систему в целом.
При управлении согласованностью данных	В связи с тем, что большинство микросервисов обладает собственными базами данных, которые изолированы от других и доступны для внешнего взаимодействия (CRUD) только через соответствующие интерфейсы, общая степень устойчивости данных варьируется в зависимости от сервиса. Хранилища данных из серверных микросервисов могут частично или целиком копироваться в клиентские микросервисы. При изменении исходных хранилищ запускается обновление данных, скопированных клиентским микросервисом, посредством отправки сообщений и постановки их в очередь на прочтение. До тех пор, пока клиентский микросервис не получит и не прочтет сообщение, данные в нем будут устаревшими, а с исходным микросервисом не согласованными. Описанное выше постепенное выполнение изменений и несогласованность данных на протяжение короткого периода времени называется согласованием в конечном счете и имеет особое значение при разработке от серверной части до UX-уровней.
При управлении развертыванием и мониторингом	При реализации микросервисной архитектуры, обеспечивающей независимое обновление отдельного функционала программного обеспечения, особое значение имеет использование DevOps-культуры и технологий непрерывной интеграции/непрерывного развертывания (доставки) (CI/CD). Технологии, реализующие CI/CD, позволяют быстро вводить в эксплуатацию производственные мощности за счет оперативного мониторинга и перераспределения мощностей для разработки, тестирования, приемки и эксплуатации и быстро устанавливать программное обеспечение (обновления/релизы) за счет автоматизации сборки, упаковки, настройки специфических параметров окружения, конфигурируемых при развертывании. DevOps-культура подразумевает взаимодействие на стыке разработки, тестирования и эксплуатации. Культура формируется за счет стандартизации информационных окружений при разработке, тестировании и эксплуатации, а также объединения инструментов автоматизации для оперативного переноса программного обеспечения или отдельных сервисов через стадии жизненного цикла, обеспечивая быстрый выпуск версий (релизов).
При управлении организацией работ	Согласно перефразированному закону Конвея, микросервисисную архитектуру, порождает организационная структура, повторяющая ее. Иными словами, наиболее эффективным способом организации работы при создании и сопровождении программного обеспечения, построенного на основе микросервисной архитектуры, является выделение группы исполнителей на основе бизнес-возможностей для каждого или группы сервисов, имеющих возможность изменять (обновлять) отдельные микросервисы независимо от других (без дополнительных согласований и синхронизации) за счет межсервисного взаимодействия через API.

 

На основе описанных выше особенностей формируются следующие преимущества микросервисной архитектуры:

• Частичное развертывание, позволяющее обновлять программное обеспечение по частям.
• Устойчивость при сбоях, так как сбой одного микросервиса не приводит к сбою всего программного обеспечения.
• Устойчивость инкапсуляции ограниченного контекста за счет отсутствия общих состояний (shared state) между модулями и физического разделения между серверами.
• Независимая эволюция подсистем достигается за счет способности микросервисов раздельно развиваться и изменять обратную совместимость без поддержки старых версий всего программного обеспечения, так как старая версия отдельного сервиса может еще работать необходимое время.
• Мультиплатформенность и гетерогенность, предотвращающие возникновение тесных связей между микросервисами и позволяющие выбирать подходящие и удобные технические решения и экспериментировать с новыми технологиями, достигаются за счет использования различных способов взаимодействия, и языков программирования микросервисов, и их распределения по разным серверным узлам, а также корректного подбора инструментов мониторинга и хранения данных.
• Независимая друг от друга и от остального программного обеспечения масштабируемость микросервисов достигается за счет инкапсуляции определенных ограниченных контекстов в сервисы, работающие на разных узлах и взаимодействующие между собой по сети с помощью заранее согласованных и редко изменяемых API.
• Эффективное использование облачных мощностей за счет облачных контейнеров, обеспечивающих микросервисам обслуживание большой нагрузки и удобство масштабирования, позволяющих по запросу выделять необходимое количество вычислительной мощности для нужд микросервиса.

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

2. Архитектурное решение программного обеспечения для планирования и контроля проведения технического обслуживания и ремонта эскалаторного хозяйства метрополитена

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

Внешний информационный контур является адаптацией типовых решений в области СЭД, ЭДО, ERP и прочих корпоративных сервисов и не представляет интерес для подробного рассмотрения в данной работе [14, 15].

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

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

Далее более подробно рассмотрим внутренний обрабатывающий контур, представленный программно-аппаратным комплексом.

На первом этапе, в процессе реальной эксплуатации, в рамках операционной и проектной деятельности, ответственными лицами из подразделений эскалаторного хозяйства, в соответствии с первичной/обновленной «идеальной» моделью технического состояния формируются перечни запрашиваемых работ — заполняются карточки шаблонов-трафаретов(наряды-допуски) на выполнение тех или иных работ. В результате внутри паспорта создаются множества отдельных субсущностей, соответствующие тому или иному виду работ, содержащие соответствующие им плановые и фактические значения параметров. При этом под операционной деятельностью понимается обслуживание, текущее содержание, дефектация, экспертизы и прочие работы, не требующие значительных затрат (включая капитальные). В данной работе под проектной деятельностью [16, 17, 18] понимаются ремонтные работы и реконструкции/модернизации, состоящие из совокупности скоординированных и управляемых видов деятельности с начальной и конечной датами, предпринятые для достижения соответствующей конкретным требованиям цели, включающие ограничения по срокам, стоимости и ресурсам и связанные со значительными затратами (включая капитальные). На этом этапе пользователь также видит динамику реализации и оценку выполненных работ в виде лингвистических характеристик, выставленных на основе количества баллов, отражающих объем работ, срок и ресурсы.

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

И сырые, и подготовленные данные с конвейера для первичной аналитической обработки (условные сита грохота/сепаратора), на третьем этапе, передаются в сервис управления мастер-данными, где раскладываются на составляющие элементы (фракционирование), верифицируются, оцениваются по уровню выполнения предыдущей потребности, соотносятся с эталонной моделью данных и дополняются служебной информацией. После чего «просеянные» данные обратно возвращаются на конвейер данных для формирования OLAP-кубов. Затем через сервис OLAP-кубы «просеянные» данные подаются в сервис добычи данных, внутри которого первично оценивается набор параметрической информации по принадлежности допусковым зонам и аномалиям поведения. При наличии данных об экспертизе промышленной безопасности (заполненных соответствующих субсущностях) и другой параметрической информации, полученной по результатам ранее выполненных работ, рассчитывается остаточный ресурс. После, с учетом ранее добытых данных и данных из хранилища, прогнозируется техническое состояние. Так как техническое состояние — это динамичная сущность, фиксируемая в электронных документах (сущностях/субсущностях) и определяемая в каждый момент времени комплексом плановых и фактических технических и экономических параметров, то задача сервиса — на основе предыдущей истории запросов и пользовательской активности формировать ранжированный перечень релевантных комплексов технических воздействий для поддержания заданного уровня, к примеру, на основе алгоритма Палех, Королев и YATI, используемых Яндексом, или их аналогов. При этом в зависимости от ранее принятых управленческих решений и уровня реализации, удовлетворения предыдущей потребности (утвержденных потребностей) алгоритм обучается (изменяет вес/ценность причинно-следственных конструкций) и может формировать корректировки к предлагаемому перечню рекомендаций (идеальной модели), а также сигнализировать об отклонении от идеальной модели, включая наличие недостающих или избыточных запросов. Предварительно добытые данные и данные из хранилища (соответствующие субсущности в карточках внешних информационных систем) используются для расчета рисков работ из запрашиваемого перечня, а также для оценки их влияния на перевозимый объем пассажиропотока и общей оценки технического состояния.

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

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

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

Пользователям, назначенным в субсущностях во внешних информационных системах на те или иные виды технического воздействия, на девятом этапе, поступает на исполнение утвержденный перечень работ с плановыми значениями. Динамика исполнения и результаты работ (фактические значения) фиксируются пользователями в соответствующих сущностях/субсущностях — карточках (электронных документах). Зафиксированные данные во внешней информационной системе обновляют данные в субсущностях/сущностях обеспечивающих служб и структурных подразделений инициирующих запрос работ. Также по результатам этого этапа в «идеальную» модель (этап 0) могут быть внесены изменения посредством обновления.

Функционирование предложенной архитектуры представлено на рис. 4 и 5 и описано в табл. 2.

 

Рис. 4. Схема ИТ-ландшафта информационной системы.

Fig. 4. The scheme of the IT landscape of the information system.

 

Рис. 5. Структурная схема программного обеспечения.

Fig. 5. The block diagram of the software.

 

Таблица 2. Описание последовательности этапов работы программного обеспечения

Table 2. Description of a sequence of stages of the software operation

Процесс	Этап	Содержание	Данные	Модули	Сервисы
Внешний	Этап 0	Формирование/обновление библиотек трафаретов и итоговая оценка исполнения работ	Рекомендованный перечень работ	Внешние информационные системы	Сервисы внешних информационных систем
	Этап 1	Использование (заполнение) трафаретов для отображения потребности в работах и их оценок	Запрашиваемый перечень работ
Внутренний	Этап 2	Конвейер подготовки данных из запрашиваемой потребности в работах	Запрашиваемый перечень работ	ELT, DL, ETL, DWH, OLAP-кубы, DM	Сервис Data Pipeline
	Этап 3	Аналитическая обработка и оценка подготовленных данных	Запрашиваемый перечень работ	КР, ЭЗ, ДД, АП, ОР, ПР, Рек, Рис, ОЦ	Сервис Master Data Management, Сервис Data Mining
	Этап 4	Расстановка данных в витрине для совмещения потребности в работах с результатами аналитической обработки и предоставления пользователям	Запрашиваемый перечень работ	СПР, РОР, РС	Сервис Data Enrichment
Внешний	Этап 5	Обеспечение работ	Обеспеченный перечень работ	Внешние информационные системы	Сервисы внешних информационных систем
Внутренний	Этап 6	Формирование консолидированной отчетности (сводки) по хозяйству	Обеспеченный перечень работ	КО	Сервис Data Steward
	Этап 7	Принятие управленческого решения по составу работ и подготовка рекомендаций по обновлению библиотек	Утвержденный перечень работ	DSS, EIS, BI, АС ЛК
	Этап 8	Выдача на исполнение утвержденного перечня работ	Утвержденный перечень работ
Внешний	Этап 9	Фиксация результатов работ	Утвержденный перечень работ	Внешние информационные системы	Сервисы внешних информационных систем

 

На рис. 5 обозначено: FE — front-end — клиентская часть; BE — back-end — серверная часть; DB —Database — работа с базами данных. ОПР — обеспеченный перечень работ; УПР — утвержденный перечень работ; ЗПР — запрашиваемый перечень работ; РПР — рекомендованный перечень работ. Сервис Data Access Management — сервис управления доступом и балансировки данных: УД — программно-аппаратный комплекс предназначенный для организации эффективной защиты периметра сети (к примеру ПАК «Рубикон»); NLB (Network Load Balancing L4) — сервис распределение приходящих запросов на несколько физических или виртуальных узлов серверов; ALB (Application Load Balancing L7) — сервис для распределения нагрузки по сервисам и приложениям; API getway — шлюз между пользователями и сервисами через API; AUT — модуль аутентификации пользователя. Сервис Data Pipeline — конвейер подготовки данных в составе: ELT — сервис работы с данными; DL (Data Lake) — хранилище сырых данных; ETL — сервис работы с данными; DWH (Data Warehouse) – хранилище подготовленных данных; OLAP-кубы — многомерный массив данных; DM (Data Mart) — множество тематических баз данных. Сервис Master Data Management —сервис управления мастер-данными и нормативно-справочной информацией в составе: КР — сервис контроля работ (управление качеством выполненных работ через балльную оценку); ЭЗ — сервис эталонных значений (управление мастер-данными); ДД — сервис дополнительных данных (управление нормативно-справочной информацией). Сервис Data mining — сервис интеллектуального анализа данных в составе: АП — сервис анализа подготовленной параметрической информации; ОР — сервис расчета остаточного ресурса; ПР — сервис нейросетевого прогнозирования; Рек — сервис подготовки рекомендаций; Рис — сервис управления рисками; ОЦ — сервис подготовки оценок. Сервис Data enrichment — сервис насыщения данных новой информацией для повышения их ценности для анализа в составе: СПР — сервис совмещения перечня работ; РОР — сервис расчета обеспеченности ресурсами; РС — сервис расчета стоимости. Сервис Data Steward — сервис управлении данными для принятия управленческих решений в составе: КО — сервис подготовки консолидированной отчетности; DSS/EIS/BI — сервис поддержки принятия решения и BI инструментов; АС ЛК — автоматизированная система “Личный кабинет” (серверный компонент); ЛК — сервис “Личный кабинет” (клиентский компонент — UX/UI дизайн).

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

ЗАКЛЮЧЕНИЕ

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

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

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

Таким образом, предлагаемое программное обеспечение предназначено для регулярного использования в качестве инструмента мониторинга и контроля реестра объектов управления, создающих и не создающих ценность для компании (обеспечивающих/не обеспечивающих транспортировку пассажиропотоков).

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

Основными задачами, решаемыми предлагаемым инструментом, являются наглядное отображение текущего состояния (при необходимости накопительные итоги) объектов управления, попавших в реестр за отчетный период, обеспечивающее общее представление о их статусе управления и идентификации проблемных участков; фокусировка внимания лица, принимающего решение (ЛПР), или иного потребителя на выделенных текущих значениях ключевых параметров объекта управления и метриках их измерения, т. к. текущее состояние объекта управления влияет на величину KPI ЛПР; отслеживание влияния задаваемых плановых показателей верхнего уровня и привил меппинга данных между используемыми информационными системами — источниками на другие показатели; использование источников первичных данных, фиксирующих ключевые параметры и их метрики; детализация информации (при необходимости до исполнителя).

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

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

ДОПОЛНИТЕЛЬНО

Вклад авторов. В.А. Попов ― поиск публикаций по теме статьи, редактирование текста и изображение рукописи, экспертная оценка, утверждение финальной версии; В.В. Еланцев ― написание текста рукописи и создание изображений. Авторы подтверждают соответствие своего авторства международным критериям ICMJE (все авторы внесли существенный вклад в разработку концепции, проведение исследования и подготовку статьи, прочли и одобрили финальную версию перед публикацией).

Конфликт интересов. Авторы декларируют отсутствие явных и потенциальных конфликтов интересов, связанных с публикацией настоящей статьи.

Источник финансирования. Авторы заявляют об отсутствии внешнего финансирования при проведении исследования.

ADDITIONAL INFORMATION

Authors’ contribution. V.A. Popov ― search for publications, editing the text and images of the manuscript, expert opinion, approval of the final version; V.V. Elantsev ― writing the text and creating images of the manuscript. All authors made a substantial contribution to the conception of the work, acquisition, analysis, interpretation of data for the work, drafting and revising the work, final approval of the version to be published and agree to be accountable for all aspects of the work.

Competing interests. The authors declare that they have no competing interests.

Funding source. This study was not supported by any external sources of funding.

About the authors

Valery A. Popov

Emperor Alexander I St. Petersburg State Transport University

Email: vpopov_58@mail.ru
ORCID iD: 0000-0003-2635-5427
SPIN-code: 2418-7152

Associate Professor, Dr. Sci. (Tech.), Associate Professor of the Mechanical Handling and Road Building Machines Department

Russian Federation, Saint Petersburg

Valentin V. Elantsev

Emperor Alexander I St. Petersburg State Transport University

Author for correspondence.
Email: evv3012@gmail.com
ORCID iD: 0000-0003-1731-5626
SPIN-code: 9667-9716

Postgraduate of the Mechanical Handling and Road Building Machines Department

Russian Federation, Saint Petersburg

References

Supplementary files