CC BY
43
ГИАБ. Горный информационно-аналитический бюллетень / MIAB. Mining Informational and Analytical Bulletin, 2022;(2):97-110 ОРИГИНАЛЬНАЯ СТАТЬЯ / ORIGINAL PAPER
УДК 004:622 DOI: 10.25018/0236_1493_2022_2_0_97
ЯЗЫК МОДЕЛИРОВАНИЯ АРХИТЕКТУРЫ ЦИФРОВОГО ПРЕДПРИЯТИЯ: МЕТОДОЛОГИЧЕСКИЙ ПОДХОД К ПРОЕКТИРОВАНИЮ СИСТЕМ ИНДУСТРИИ 4.0
С.А. Дерябин1, Е.И. Кондратьев1, Рзазаде Ульви Азар оглы1, И.О. Темкин1
1 НИТУ «МИСиС», Москва, Россия, e-mail: deryabin.sa@misis.ru
Аннотация: Рассмотрены предложения по унификации способов графического моделирования архитектуры сложных крупномасштабных систем при проектировании цифровой трансформации предприятий в рамках концепции Индустрии 4.0. Работа структурирована следующим образом: раздел 2 посвящен формализации и обсуждению функциональных и нефункциональных требований к архитектуре цифровых предприятий в рамках концепции Индустрия 4.0. В разделе 3 рассмотрены некоторые проблемы использования традиционных нотаций графического моделирования систем, а также предлагается минимальный набор взаимосвязанных диаграмм, которые могли бы быть использованы на стадии проектирования архитектуры цифрового предприятия, включая оригинальные диаграммы, разработанные авторами. В разделе 4 показан пример реализации такого подхода к формированию набора диаграмм, названного DEAL 1.0 (Digital Enterprise Architecture Language), для проектирования архитектуры системы управления горнодобывающим предприятием открытого типа. По результатам работы определены ключевые функциональные и нефункциональные требования к цифровым предприятиям в рамках концепции Индустрия 4.0 и предложена методология проектирования дата-цен-тричной микросервисной архитектуры цифрового предприятия, включающая переосмысление и модификацию существующих нотаций графического моделирования, оригинальные подходы к построению диаграмм, компромиссный подход к проектированию систем и инструментарий для проектирования и контроля качества реализации сложного крупномасштабного программного продукта.
Ключевые слова: DEAL 1.0, цифровая трансформация предприятий, Индустрия 4.0, цифровая платформа, графическое моделирование, сервис-ориентированная архитектура, микросервисная архитектура, дата-центричная архитектура, архитектурирование программного обеспечения, модель архитектуры.
Благодарность: Работа выполнена при поддержке гранта Российского Научного Фонда проект № 19-17-00184.
Для цитирования: Дерябин С. А., Кондратьев Е. И., Рзазаде Ульви Азар оглы, Темкин И. О. Язык моделирования архитектуры цифрового предприятия: методологический подход к проектированию систем Индустрии 4.0 // Горный информационно-аналитический бюллетень. - 2022. - № 2. - С. 97-110. DOI: 10.25018/0236_1493_2022_2_0_97.
© С.А. Дерябин, Е.И. Кондратьев, Рзазаде Ульви Азар оглы, И.О. Темкин. 2022.
Digital Mine architecture modeling language: Methodological approach to design in Industry 4.0
S.A. Deryabin1, E.I. Kondratev1, Rzazade Ulvi Azar ogly1, I.O. Temkin1
1 National University of Science and Technology «MISiS», Moscow, Russia, e-mail: deryabin.sa@misis.ru
Abstract: The article discusses proposals on unification of methods for graphical modeling of architecture of complex large-scale systems in digital transformation design of production units within the concept of Industry 4.0. Article's Section 2 formalizes and examines the functional and nonfunctional requirements for the architecture of digital mines in Industry 4.0. Section 3 focuses on some problems connected with traditional notations of graphical modeling and offers a minimum set of interconnected diagrams suitable for the digital mine architecture design, including original diagrams developed by the present article authors. Sections 4 illustrates implementation of an approach to compilation of a set of diagrams — DEAL 1.0 (Digital Enterprise Architecture Language) — for the architectural design of an open pit mine management system. Based on the research results, the key functional and nonfunctional requirements are formulated for the digital mines within the concept of Industry 4.0, and the design methodology is proposed for the data-centric microservice architecture of a digital mine, including rethinking and modification of the current notations of graphical modeling, an original approach to construction of diagrams, a trade-off approach to systems engineering and an apparatus for the design and quality control in implementation of the complex large-scale program product. Key words: DEAL 1.0, digital transformation of enterprises. Industry 4.0, digital platform, graphical modeling, service-oriented architecture, microservice architecture, data-centric architecture, software architecturization, architecture model.
Acknowledgements: The study was supported by the Russian Science Foundation, Grant No. 19-17-00184.
For citation: Deryabin S. A., Kondratev E. I.,Rzazade Ulvi Azar ogly, Temkin I. O. Digital Mine architecture modeling language: Methodological approach to design in Industry 4.0. MIAB. Mining Inf. Anal. Bull. 2022;(2):97-110. [In Russ]. DOI: 10.25018/0236_1493_2022_2_0_97.
Введение
При реализации таких масштабных проектов, как цифровая трансформация промышленных предприятий в рамках концепции Индустрия 4.0, существенную роль ввиду особенностей формулирования исходных требований играют вопросы разработки графических моделей будущей структурно-функциональной архитектуры системы управления цифровым предприятием [1—3]:
• необходимость нахождения компромисса при составлении и чтении модели между пользователями, обладающими компетенциями в понимании биз-
нес-процессов и не разбирающимися в программной реализации систем, и разработчиками, не обладающими знаниями в тонкостях бизнес-процессов, но требующими четкости понимания ставящихся перед ними задач [4-6];
• сложность формализации, а в некоторых случаях полное отсутствие понимания, конечных функциональных и не функциональных требований к цифровому предприятию как к единой системе [1, 2, 7];
• необходимость учета существующий архитектуры предприятия, которая может включать в себя в том числе вы-
полнение отдельных бизнес-процессов в «ручном режиме», для приведения ее к сервис-ориентированному и дата-цент-ричному видам [3, 4];
• включение в архитектуру будущей системы множества слабосвязанных новых и перспективных технологий, еще не реализованных на предприятии на момент разработки проекта, а также отсутствие успешных примеров промышленной интеграции подобных решений [5, 8, 9].
Существующие методологические подходы к разработке моделей архитектуры систем, такие, как, например, «4+1» [10] и «С4» [11], предлагающие конкретизацию минимального и достаточного набора диаграмм, которые необходимо сформировать на стадии проектирования для последующей разработки системы, на наш взгляд, не отвечают полностью всем изложенным требованиям. Так, наследуемый во всех методологических подходах принцип иерархичности связи элементов от верхнего «концептуального уровня» архитектуры к нижнему «физическому уровню развертывания» подходит только для некрупных или новых систем, т.к. используемые диаграммы неизбежно становятся нечитабельными из-за избыточности структурных элементов и связей между ними [12]. Кроме того, уже только на концептуальном уровне процесс составления модели архитектуры может быть абсолютно непонятен людям, не обладающим специфическими навыками в проектировании систем и знаниями в области нотаций, а в то же время участие отраслевых специалистов в процессе составления модели архитектуры представляется абсолютно необходимым, так как это гарантирует корректность модели и, следовательно, минимизацию количества ошибок при ее последующей программной реализации. Исходя из вышеизложенного можно сделать вывод о необхо-
димости разработки такой методологии проектирования, в которой учитывались бы основные требования цифровой трансформации предприятий, и которая обладала бы свойствами выразительности и компактности.
Функциональные и нефункциональные требования Индустрии 4.0 к цифровой трансформации предприятий
Рассмотрим некоторые аспекты технологий Индустрии 4.0 (рис. 1) в рамках цифровой трансформации предприятий для определения обобщенных требований к составлению диаграмм при проектировании архитектуры. Так, одной из ключевых особенностей архитектуры цифрового предприятия является ее реализация в микросервисном виде [3, 13 — 15]. Под микросервисом понимается элементарная (неделимая) функциональная задача из перечня реализуемых бизнес-процессов, которая может (и должна) исполняться программным обеспечением в автономном режиме, либо в автоматизированном или ручном режиме специалистом предприятия, что неизбежно при поэтапной цифровой трансформации. При этом основным показателем действительной цифровой трансформации предприятия является переход от ручного или автоматизированного режима выполнения задач к их автономному выполнению программными микросервисами [16].
Процесс же взаимодействия микросервисов при реализации бизнес-процессов предприятия должен быть урегулирован с использованием специализированных инфраструктурных программных компонентов, объединяемых общим термином «Цифровая Платформа» [13, 14, 17].
Основными особенностями платформенной части микросервисной архитектуры являются:
• использование общей интеграционной шины данных (Integration Bus) с программным интерфейсом приложений (Application Program Interface) [13];
• формализация взаимоотношения между микросервисами (процесса обмена информацией) в терминологии «издатель-подписчик» и регуляризацией таких взаимоотношений брокером сообщений [17].
Понимание данных также переосмысливается в контексте цифровой трансформации в виде «данные как сервис», а сегодня встречается такое понятие, как «дата-центричная архитектура» (data-centric architecture) [18]. Под дата-цент-ричностью подразумевается выстраивание всей архитектуры взаимодействия микросервисов и логики их работы вокруг данных. При таком подходе предполагается, что в архитектуре системы
должны быть учтены особенности работы микросервисов с данными для реализации их автономной работы. Иными словами, микросервисы должны обладать «знаниями» о собственных функциональных возможностях, определяемых в виде структур данных, поступающих на внешние вход и выход.
Стоит отметить, что большая часть предприятий сегодня, в том числе и горнодобывающей отрасли, не обладает такой дата-центричной микросервисной архитектурой, необходимой для полноценной цифровой трансформации [4, 8, 15]. Некоторые из эксплуатируемых информационных, автоматизированных и других систем, участвующих в реализации отдельных бизнес-процессов, хоть и могут обладать сервис-ориентированной архитектурой, все же требуют существенных доработок.
Индустрии 4.D
v*11
ЦИФРОВОЙ XT Д^алнвинап ДВОЙНИК % Р-П—™
□Влачные вычисление
Рис. 1. Элементы Индустрии 4.0, включаемые в архитектуру цифрового предприятия Fig. 1. Industry 4.0 components included in digital enterprise architecture
Технический агент
Агрегация данных
Data in Data out
Вес груза Скорость фактическая Координаты фактические Дата/Время Вес груза Скорость фактическая Координаты фактические
Управлениедвижением
Data in Data out
Скорость требуемая Координаты требуемые Скорость фактическая Координаты фактические
->
АСУ ГТК
Диспетчерское управление
Data in Data out
Точки разгрузки Точки погрузки Прогноз прибыли Скорость требуемая Координаты требуемые
Расчет интегральных параметров (мониторинг)
Data in Data out
Дата/Время Вес груза Скорость фактическая Координаты фактические Количество рейсов Объем перевезенного груза Средняя скорость движения Точки разгрузки Точки погрузки
ERP
Прогнозирование прибыли
Data in Data out
Остаточные запасы Средняя скорость движения Прогноз прибыли
ггис
Расчет остаточных запасов
Data in Data out
Объем перевезенного груза Точки погрузки Остаточные запасы
Рис. 2. Диаграмма структурно-функциональной архитектуры решения задачи централизованного управления горнотранспортной техникой
Fig. 2. Diagram of structurally function architecture for centralized management of mining machinery
Вследствие этого интеграция технологий Индустрии 4.0, нацеленных на цифровую трансформацию предприятия, может (и должна) быть осуществлена посредством проработки техно-рабочей проектной документации будущей системы и поэтапного внесения изменений в способы организации и функционирования собственных бизнес-процессов. Для этого нами предлагаются следующие процедуры, на которые необходимо ориентироваться:
• Переработка структурно-функциональной архитектуры реализации бизнес-процессов к микросервсиному виду с приведением порядка взаимодействия микросервисов к виду отношений издателя и подписчика.
• Организация автономного получения первичных данных всеми заинтере-
сованными сторонами, осуществляемая путем формализации функциональных возможностей микросервисов и приведением данных к требуемой структуре.
Проблемы использования классических нотаций при проектировании архитектуры цифрового предприятия
С учетом высказанных предложений по приведению архитектуры предприятия к виду, пригодному для цифровой трансформации [19], естественно встает вопрос об адекватных новым требованиям технологиях разработки проектной документации. Фактически речь идет о создании инструмента для графического моделирования, поскольку существующие нотации неспособны отразить ряд особенностей взаимодействия элементов
дата-центричной микросервисной архитектуры.
На рис. 2 приведен упрощенный пример использования нотации UML для графического моделирования динамической связи структуры сервисов (автоматизированных программных систем) и микросервисов в рамках задачи централизованного управления автономными техническими агентами (роботизированными самосвалами) горнодобывающего предприятия открытого типа [2 — 5, 8, 15]. Данная схема, естественно, не отражает все микросервисы, участвующие в процессе управления автономными техническими агентами, но даже в таком виде прекрасно демонстрирует недостатки традиционных нотаций, а именно:
• избыточность количества структурно-функциональных элементов и их описательной составляющей для однозначного понимания функциональных возможностей микросервисов;
• избыточность количества связей между элементами для однозначного
понимания процессов передачи данных между микросервисами в целях обеспечения их работы (и невозможность отображения связей без пересечений вообще, как того требуют все нотации);
• отсутствие наглядной динамики связи между элементами, характеризующей сложный порядок работы микросервисов при решении общей бизнес-задачи.
Для решения поставленной задачи графического моделирования архитектуры цифрового предприятия нами была определена возможность использования отдельных диаграмм нотации UML для описания технической реализации микросервисов с учетом их небольшой модификации, а также их иерархической компоновки в общем семействе графических моделей, «4+1» или «С4». Предложенному подходу к проектированию модели архитектуры цифрового предприятия дано название «DEAL 1.0» — Digital Enterprise Architecture Language или Язык архитектурирования цифрового предприятия (рис. 3).
Рис. 3. Состав и связь диаграмм моделирования архитектуры цифрового предприятия «DEAL 1.0» (Digital Enterprise Architecture Language)
Fig. 3. Contents and interconnection of modeling charts in digital enterprise architecture in DEAL 1.0 (Digital Enterprise Architecture Language)
«DEAL 1.0» — Digital Enterprise Architecture Language (Язык архитектурирования цифрового предприятия)
Первый концептуальный уровень нашего подхода к моделированию архитектуры цифрового предприятия предполагает использование довольно простой и широко распространенной организационно-функциональной диаграммы. Нам кажется, что не имеет смысла объяснять то, каким образом она строится, но мы бы хотели обозначить некоторые ключевые аспекты, связанные с причинами ее применения:
1. Поскольку в первую очередь заинтересованной стороной в самом процессе цифровой трансформации является предприятие, а наиболее компетентной стороной в выделении и структурировании всех исполняемых бизнес-процес-
сов являются сотрудники предприятия, на начальной стадии проектирования архитектуры должна создаваться такая модель, которая была бы понятна сотрудникам, и которая могла бы быть создана ими или с их непосредственным участием.
2. Как правило, каждое предприятие, по крайней мере, в отечественной практике, уже обладает организационной моделью, в которой выделены ключевые лица принимающие решения (ЛПР) и отделы, занятые в бизнес-процессах. Превратить же организационную модель в функциональную достаточно просто, это не требует специфических знаний и навыков в разработке диаграмм моделирования систем — достаточно заменить в организационной модели обозначения ЛПР и отделов на бизнес-задачи, которые являются центральными в их деятельности.
Рис. 4. Концептуальный уровень (0 уровень) — организационно-функциональная диаграмма предприятия
Fig. 4. Conceptual level 0—organizational and functional diagram of production unit
На рис. 4 представлен пример организационно-функциональной диаграммы применительно к горнодобывающему предприятию. На данной диаграмме намеренно исключены ветки, связанные с управлением финансово-хозяйственной и кадровой деятельностью, с целью иллюстрации именно ключевых технологических процессов и выделения той бизнес-задачи, которая была показана на рис. 2.
Процессный уровень (1):
диаграмма процесса
Следуя нашей нотации, далее необходимо «провалиться» в каждую из задач для создания диаграмм, описывающих, из каких элементарных (неделимых) операций (мироксервисов) они состоят, и каков порядок выполнения этих операций (взаимодействия микросервисов). На рис. 5 показана такая диаграмма для задачи управления автотранспортом (при этом имеется в виду централизованное управление роботизированными самосвалами).
«Алфавитом» диаграммы процесса является:
1. Разделение диаграммы на две части: в левой, структурной, части отображаются сервисы/микросервисы,участвующие в реализации бизнес-процесса, а также их связи с другими сервисами/ микросервисами для выполнения собственных функций; в правой части отображается порядок выполнения функций сервисами/микросервисами при реализации бизнес-процесса.
2. «Сервис»/«Микросервис» — обозначаемый в виде прямоугольника, разделенного на три части: верхняя часть содержит имя сервиса/микросервиса, левая нижняя часть служит «внешним входом» (IN) для подписки на данные и содержит идентификационный номер сервиса/микросервиса; правая нижняя часть служит «внешним выходом» (OUT) для издания (публикации) данных.
3. «Флажок» — обозначение связи в левой части диаграммы между двумя сервисами/микросервисами, содержит в левой части номер сервиса/микросер-
Диаграмма процесса
АСУ ГТК
2 - Диспетчерское управление
IN (2) OUT (2)
3 - Расчет m параметров тегральных мониторинг)
IN{3) OUT (3)
Технический агент
1 - Агрегация данных
IN(1) OUT (1)
)б:1 1:3
6 -Управление движением
)2:6 IN (6) OUT (6) 6:l]
>5:2
>3:2
2:6
ггис
4 - Расчет остаточных запасов
IN (4) OUT (4)
)з:4 4:5;
1:3
^
3:4
й 4:5
Й
5:2
&
2:6
^
6:1
3:5
У
3:2
V
Рис. 5. Уровень процесса (1 уровень) — диаграмма процесса Fig. 5. Process level 1 — diagram of process
виса, из которого выходит информация, а справа номер сервиса/микросервиса, в который информация поступает.
4. «Линия связи» — обозначение связи в правой части диаграммы между «флажками» для определения последовательности или параллельности работы микросервисов. Отсутствие входной линии связи во флажок подразумевает асинхронный, т.е. независимый от предыдущей операции, режим работы микросервиса.
Уровень реализации и исполнения (2): диаграмма архитектуры микросервиса и диаграмма пайплайна Следующим шагом моделирования архитектуры цифрового предприятия является создание детализированных диаграмм архитектур микросервисов и диаграмм пайплайнов.
Диаграмма архитектуры микросервиса (рис. 6) представляет собой комбинацию диаграммы компонентов и диаграммы классов UML. В верхней «компонен-
той» части отображается наименование (сервис) физического места размещения (развертывания) микросервиса (в нашем случае это «Технический агент»), а также сопутствующая необходимая техническая информация о способах, инструментах и условиях выполнения размещения микросервиса — это могут быть, например, технические характеристики вычислительных устройств.
В основной части данной диаграммы отображается следующее.
1. «Микросервис» — вертикальный прямоугольник, разделенный на четыре части. В верхней части располагается идентификатор и наименование микро-серсивиса; в средней левой части отображаются «методы» микросервиса; в средней правой части — «данные» на внешний выход; в нижней части — «конфигурация»:
• «Методы» — набор простейших (вычислительных) операций, которыми оперирует данный микросервис для реализации заданной функции и которые могут быть реализованы как с помощью
Диаграмма архитектуры микросервиса
Технический агент: 100 Мбайт ОЗУ, 20 Мбайт HDD, Intel Core2Duo+
Рис. 6. Уровень реализации и исполнения (2): диаграмма архитектуры микросервиса Fig. 6. Implementation level 2—microservice architecture diagram
программного кода, так и в ручном режиме специалистами предприятия;
• «Данные» —информация, которую продуцирует микросервис по результатам выполнения собственных функций (методов) и которая поступает на внешний выход;
• «Конфигурация» — программное представление структуры микросервиса, отражающая набор служебных параметров микросервиса (ID, адрес, порт, тип, состояние, качество работы и др.) для организации брокером его взаимодействия на интеграционной шине с другими микросервисами, а также метаин-формацию структуры внешних входа (IN) и выхода (OUT).
2. «Связи» — горизонтальные прямоугольники с соединительной линией, обозначающие:
• «Связи методов» (IN) — связи, ассоциированные с другими микросервисами, передающими информацию методам микросервиса для реализации его функций;
• «Связи данных» (OUT) — связи, ассоциированные с внешним выходом для публикации и передачи информации другим микросервисам;
• «Связи наследования» — связи, ассоциируемые с общими наследуемыми методами из служебной библиотеки предприятия, необходимые для работы микросервиса, (например, запрос на конфигурацию, настройку схем отправки данных, определение системного времени и т.п.).
Диаграмма пайплайна представляет собой некоторую комбинацию диаграммы классов UML и принципов ER диаграмм. В диаграмме пайплайна (рис. 7) отображается непосредственная связь между выходом (OUT) и входом (IN) двух микросервисов — «пайплайн». Слева должен быть изображен микросервис, из которого поступает информация (OUT) в данной связи, а справа микросервис,
в который поступает информация (IN). В данной диаграмме указывается:
1. «Микросервис» — горизонтальный прямоугольник, разделяемый на три части: верхняя часть содержит идентификационный номер и имя микросервиса; средняя часть содержит «перечень данных»; нижняя часть содержит программный вид «пакета данных».
2. «Перечень данных» — блок, содержащий наименование данных, отправляемых или получаемых микросервисами в ходе реализации их функций, а также человекочитаемые характеристики данных: тип числа, диапазон измерений, единица измерений и др.
3. «Пакет данных» — форматы программного представления данных на выходе и входе из микросервисов, необходимые для последующего преобразования данных брокером на интеграционной шине в целях фактической реализации передачи информации между микросервисами в соответствии с их возможностями и потребностями.
Обсуждение
В совокупности, предложенный подход к моделированию архитектуры цифрового предприятия DEAL 1.0, на наш взгляд, имеет ряд следующих преимуществ:
1. Получаемый набор диаграмм универсален относительно разных предметных областей и может быть применим как при проектировании архитектуры цифрового предприятия горнодобывающего сектора, так и любого другого предприятия из смежных отраслей экономики.
2. Большая часть диаграмм вполне абстрактны и просты в понимании; могут описывать бизнес-процессы, находящиеся на разных уровнях автоматизации (от полностью автономного выполнения до ручного режима); могут читаться и составляться специалистами
Диаграмма пайплайна
1 - Агрегация данных (OUT) 3 - Расчет интегральных параметров (IN)
Вес груза: float, [0Д00], kg Вес груза: float, [0,0.1], ton
Скорость фактическая: float, [0,100], km/h Координаты фактические: float, [0,90], degrees, float, [0,180], degrees Скорость фактическая: float, [0,28], m/s Широта: float, [0,90], degrees Долгота: float, [0,180], degrees
■data": { "Weight": 50.0, "speed Fact": 10.0, "coordsFacf: { "1аГ: 40.00000, "Ion": 41.00000} } "data": { "weight": 0.05, "speedFact": 2.77778, "laf: 40.00000, "Ion": 41.00000
Рис. 7. Уровень реализации и исполнения (2): диаграмма пайплайна Fig. 7. Pipeline diagram
предприятия, т.к. обладают минимальным количеством единиц «алфавита», но при этом на «нижнем уровне» достаточно детализированы для последующей передачи графических моделей в реализацию разработчикам программного обеспечения.
3. Все диаграммы обладают вертикально-горизонтальной взаимосвязанностью, что дает возможность наглядного контролирования процесса графического моделирования архитектуры и в конечном счете обеспечивает минимизацию рисков возникновения ошибки.
4. DEAL 1.0 учитывает ключевые особенности проектирования систем Индустрии 4.0 и в действительности позволяет сформировать дата-центричную микросервисную архитектуру цифрового предприятия в наглядном и удобочитаемом виде.
Заключение
По результатам работы:
1. Определены ключевые функциональные и нефункциональные требования к цифровым предприятиям в рамках концепции Индустрия 4.0, которые должны быть учтены при графическом
моделировании архитектуры сложной крупномасштабной системы.
2. Предложен методологический подход к проектированию архитектуры цифрового предприятия DEAL 1.0, включающий в себя:
• переосмысление и модификацию существующих нотаций графического моделирования для приведения их в соответствие с требованиями концепции Индустрия 4.0;
• оригинальные подходы к построению диаграмм, иллюстрирующие микросервисную дата-центричную архитектуру в виде горизонтально-вертикальной иерархической связи графических моделей различного назначения;
• компромиссный подход к проектированию систем, под которым понимается привлечение отраслевых экспертов-пользователей и разработчиков программного обеспечения для составления техно-рабочей проектной документации;
• удобный инструментарий для проектирования и контроля качества реализации сложного крупномасштабного программного продукта.
3. Показан пример реализации DEAL 1.0 при графическом моделировании
архитектуры системы управления горнодобывающим предприятием открытого типа, иллюстрирующий основные преимущества предложенного подхода.
Вклад авторов
Темкин И.О. — постановка задачи и анализ результатов.
Дерябин С.А. — генерация идеи исследования, концептуализация и подготовка публикации.
Кондартьев Е.И. — разработка графических материалов для публикации.
Рзазаде У.А. — выполнение работы по систематизации исходных данных.
СПИСОК ЛИТЕРАТУРЫ
1. Лукичев С. В., Наговицын О. В. Цифровая трансформация горнодобывающей промышленности: прошлое, настоящее, будущее // Горный журнал. - 2020. - № 9. — С. 13 — 18. DOI: 10.17580/gzh.2020.09.01.
2. Владимиров Д. Я., Клебанов А. Ф., Кузнецов И. В. Цифровая трансформация открытых горных работ и новое поколение карьерной техники // Горная промышленность. —
2020. — № 6. — С. 10 — 12.
3. Клебанов А. Ф. Автоматизация и роботизация открытых горных работ: опыт цифровой трансформации // Горная промышленность. — 2020. — № 1. — С. 8 — 11.
4. Наговицын О. В., Возняк М. Г. К вопросам управления роботизированным горнодобывающим предприятием // Горный информационно-аналитический бюллетень. —
2021. — № 5(1). — С. 326 — 335. DOI: 10.25018/0236_1493_2021_51_0_326.
5. Deryabin S. A., Temkin I. O., Zykov S. V. About some issues of developing Digital Twins for the intelligent process control in quarries // Procedia Computer Science. 2020, no. 176, pp. 3210-3216. DOI: 10.1016/j.procs.2020.09.128.
6. Kulikova E, IvannikovA. Geographic information systems in geological monitoring during the construction of urban underground structures // Monitoring of Geological Processes and Ecological Condition of the Environment. 2019, no. 19, pp. 1 — 5. DOI: 10.3997/22144609.201903192.
7. Kongar-Syuryun Ch, Ubysz A., Faradzhov V. Models and algorithms of choice of development technology of deposits when selecting the composition of the backfilling mixture // IOP Conference Series: Earth and Environmental Science. 2021, vol. 684, no. 1, article 012008. DOI: 10.1088/1755-1315/684/1/012008.
8. Temkin I., Myaskov A., Deryabin S., Konov I., Ivannikov A. Design of a digital 3D model of transport-technological environment of open-pit mines based on the common use of telem-etric and geospatial information // Sensors. 2021, vol. 21, no. 18, article 6277. DOI: 10.3390/ s21186277.
9. Хайрутдинов А. М., Конгар-Сюрюн Ч. Б., Kowalik Т., Тюляева Ю. С. Управление напряженно-деформационным состоянием массива горных пород путем формирования разнопрочностной закладки // Горный информационно-аналитический бюллетень. — 2020. — № 10. — С. 42-55. DOI: 10.25018/0236-1493-2020-10-0-42-55.
10. Kruchten P. The 4+1 view model of architecture // IEEE Software. 1995, vol. 12, no. 6, pp. 45 — 50. DOI: 10.1109/52.469759.
11. Vazquez-Ingelmo A., Garcia-Holgado A., Garcia-Penalvo F. J. C4 model in a software engineering subject to ease the comprehension of UML and the software // IEEE Global Engineering Education Conference. 2020, pp. 919 — 924. DOI: 10.1109/EDUCON45650.2020.9125335.
12. Kozma D., Varga P., Larrinaga F. Dynamic multilevel workflow management concept for industrial IoT systems // IEEE Transactions on Automation Science and Engineering. 2021, vol. 18, no. 3, pp. 1354—1366. DOI: 10.1109/TASE.2020.3004313.
13. Liua C., Su Z., Xu X., Lu Y. Service-oriented industrial internet of things gateway for cloud manufacturing // Robotics and Computer-Integrated Manufacturing. 2022, vol. 73, article 102217. DOI: 10.1016/j.rcim.2021.102217.
14. Resende C., Folgado D, Oliveira J., Franco B, Moreira W, Oliveira Junior A. C, Cavaleiro A., Carvalho R. TIP4.0: industrial internet of things platform for predictive maintenance // Sensors. 2021, vol. 21, no. 14, rticle 4676. DOI: 10.3390/s21144676.
15. Темкин И. О., Клебанов Д. А., Дерябин С. А., Конов И. С. Построение интеллектуальной геоинформационной системы горного предприятия с использованием методов прогнозной аналитики // Горный информационно-аналитический бюллетень. - 2020. -№ 3. - С. 114-125. DOI: 10.25018/0236-1493-2020-3-0-114-125.
16. Zaytseva E, Agafonov V. The concept of establishing a digital industrial enterprise in the cement industry // Materials of the International Conference «Scientific Research of the SCO Countries: Synergy and Integration». Beijing, 2019, pp. 12-18.
17. Sahal R., Breslin J. G., Ali M. I. Big data and stream processing platforms for industry 4.0 requirements mapping for a predictive maintenance use case // Journal of Manufacturing Systems. 2020, vol. 54, pp. 138-151. DOI: 10.1016/j.jmsy.2019.11.004.
18. Martínez P. L., Dintén R., Drake J. M., Zorrilla M. A big data-centric architecture metamodel for Industry 4.0 // Future Generation Computer Systems. 2021, vol. 125, pp. 263-284. DOI: 10.1016/j.future.2021.06.020.
19. VostrikovA. V., Prokofeva E. N., Goncharenko S. N., Gribanov I. V Analytical modeling for the modern mining industry // Eurasian Mining. 2019, no. 2, pp. 30-35. DOI: 10.17580/ em.2019.02.07. ЕШ2
REFERENCES
1. Lukichev S. V., Nagovitsin O. V. Digital transformation of mining industry: past, present and future. Gornyi Zhurnal. 2020, no. 9, pp. 13-18. [In Russ]. DOI: 10.17580/gzh.2020.09.01.
2. Vladimirov D. Y., Klebanov A. F., Kuznetsov I. V. Digital transformation of open-pit mining and a new generation of quarry equipment. Russian Mining Industry. 2020, no. 6, pp. 1012. [In Russ].
3. Klebanov A. F. Automation and robotization of open-pit mining: the experience of digital transformation. Russian Mining Industry. 2020, no. 1, pp. 8-11. [In Russ].
4. Nagovitsyn O. V., Voznyak M. G. Robotic mine management. MIAB. Mining Inf. Anal. Bull. 2021, no. 5(1), pp. 326-335. [In Russ]. DOI: 10.25018/0236_1493_2021_51_0_326.
5. Deryabin S. A., Temkin I. O., Zykov S. V. About some issues of developing Digital Twins for the intelligent process control in quarries. Procedia Computer Science. 2020, no. 176, pp. 3210-3216. DOI: 10.1016/j.procs.2020.09.128.
6. Kulikova E., Ivannikov A. Geographic information systems in geological monitoring during the construction of urban underground structures. Monitoring of Geological Processes and Ecological Condition of the Environment. 2019, no. 19, pp. 1-5. DOI: 10.3997/22144609.201903192.
7. Kongar-Syuryun Ch., Ubysz A., Faradzhov V. Models and algorithms of choice of development technology of deposits when selecting the composition of the backfilling mixture. IOP Conference Series: Earth and Environmental Science. 2021, vol. 684, no. 1, article 012008. DOI: 10.1088/1755-1315/684/1/012008.
8. Temkin I., Myaskov A., Deryabin S., Konov I., Ivannikov A. Design of a digital 3D model of transport-technological environment of open-pit mines based on the common use of telem-etric and geospatial information. Sensors. 2021, vol. 21, no. 18, article 6277. DOI: 10.3390/ s21186277.
9. Khayrutdinov A. M., Kongar-Syuryun Ch. B., Kowalik T., Tyulyaeva Yu. S. Stress-strain behavior control in rock mass using different-strength backfill. MIAB. Mining Inf. Anal. Bull. 2020, no. 10, pp. 42-55. DOI: 10.25018/0236-1493-2020-10-0-42-55.
10. Kruchten P. The 4+1 view model of architecture. IEEE Software. 1995, vol. 12, no. 6, pp. 45 — 50. DOI: 10.1109/52.469759.
11. Vazquez-Ingelmo A., Garcia-Holgado A., Garcia-Penalvo F. J. C4 model in a software engineering subject to ease the comprehension of UML and the software. IEEE Global Engineering Education Conference. 2020, pp. 919 — 924. DOI: 10.1109/EDUCON45650.2020.9125335.
12. Kozma D., Varga P., Larrinaga F. Dynamic multilevel workflow management concept for industrial IoT systems. IEEE Transactions on Automation Science and Engineering. 2021, vol. 18, no. 3, pp. 1354—1366. DOI: 10.1109/TASE.2020.3004313.
13. Liua C., Su Z., Xu X., Lu Y. Service-oriented industrial internet of things gateway for cloud manufacturing. Robotics and Computer-Integrated Manufacturing. 2022, vol. 73, article 102217. DOI: 10.1016/j.rcim.2021.102217.
14. Resende C., Folgado D., Oliveira J., Franco B., Moreira W., Oliveira Junior A. C., Cava-leiro A., Carvalho R. TIP4.0: industrial internet of things platform for predictive maintenance. Sensors. 2021, vol. 21, no. 14, rticle 4676. DOI: 10.3390/s21144676.
15. Temkin I. O., Klebanov D. A., Deryabin S. A., Konov I. S. Construction of intelligent geoinformation system for a mine using forecasting analytics techniques. MIAB. Mining Inf. Anal. Bull. 2020, no. 3, pp. 114-125. [In Russ]. DOI: 10.25018/0236-1493-2020-3-0-114-125.
16. Zaytseva E., Agafonov V. The concept of establishing a digital industrial enterprise in the cement industry. Materials of the International Conference «Scientific Research of the SCO Countries: Synergy and Integration». Beijing, 2019, pp. 12 — 18.
17. Sahal R., Breslin J. G., Ali M. I. Big data and stream processing platforms for industry 4.0 requirements mapping for a predictive maintenance use case. Journal of Manufacturing Systems. 2020, vol. 54, pp. 138 — 151. DOI: 10.1016/j.jmsy.2019.11.004.
18. Martinez P. L., Dinten R., Drake J. M., Zorrilla M. A big data-centric architecture metamodel for Industry 4.0. Future Generation Computer Systems. 2021, vol. 125, pp. 263 — 284. DOI: 10.1016/j.future.2021.06.020.
19. Vostrikov A. V., Prokofeva E. N., Goncharenko S. N., Gribanov I. V. Analytical modeling for the modern mining industry. Eurasian Mining. 2019, no. 2, pp. 30-35. DOI: 10.17580/ em.2019.02.07.
ИНФОРМАЦИЯ ОБ АВТОРАХ
Дерябин Сергей Андреевич1 — зав. лабораторией,
e-mail: deryabin.sa@misis.ru, ORCID ID: 0000-0003-3165-7032,
Кондратьев Егор Игоревич1 — лаборант,
Рзазаде Ульви Азар оглы1 — старший преподаватель,
Темкин Игорь Олегович1 — д-р техн. наук, зав. кафедрой,
1 НИТУ «МИСиС» .
Для контактов: Дерябин С.А., e-mail: deryabin.sa@misis.ru.
INFORMATION ABOUT THE AUTHORS S.A. Deryabin1, Head of Laboratory,
e-mail: deryabin.sa@misis.ru, ORCID ID: 0000-0003-3165-7032,
E.I. Kondratev1, Laboratory Assistant,
Rzazade Ulvi Azar ogly1, Senior Lecturer,
I.O. Temkin1, Dr. Sci. (Eng.), Head of Chair,
1 National University of Science and Technology «MISiS»,
119049, Moscow, Russia.
Corresponding author: S.A. Deryabin, e-mail: deryabin.sa@misis.ru.
Получена редакцией 24.11.2021; получена после рецензии 24.12.2021; принята к печати 10.01.2022. Received by the editors 24.11.2021; received after the review 24.12.2021; accepted for printing 10.01.2022.
