CC BY
59
Проблематика и описание подхода к интеграции инструментов системного
проектирования
А.С. Королев, С.Г. Кюрчева
Аннотация — В современном мире прослеживается тенденция к увеличению сложности объектов, что требует внедрения в производство оптимизированных подходов к разработке продуктов. Одним из таких подходов является использование единой цифровой модели на всех этапах жизненного цикла изделий. В данной статье речь идет о необходимости наличия единой цифровой модели продукта при внедрении концепции цифрового производства (Индустрия 4.0). Для построения сквозного процесса проектирования необходимо совмещение таких подходов как концепция управления жизненным циклом и моделе-ориентированная системная инженерия. В статье рассматриваются основные проблемы интеграции между инструментами моделе-ориентированной системной инженерии и PLM-системами, которые поддерживают концепцию управления жизненными циклом продукта.
В частности, рассматривается проблема взаимосвязи между упомянутыми ранее подходами. На данный момент не существует оптимального решения в виде единой системы проектирования сложных технологических объектов, которая поддерживала бы связь между подходом моделе-ориентированной системной инженерии и концепцией управления жизненным циклом. В связи с вышесказанным встаёт вопрос о создании интеграции между инструментами моделе-ориентированной системной инженерии и системами управления жизненным циклом с целью повышения эффективности процесса актуализации изменений.
В статье предложен и описан подход к интеграции между инструментами системного проектирования с помощью преобразования структуры данных на примере инструмента моделе-ориентированной системной инженерии PolarSys Capella и PLM-платформы T-FLEX DOCs.
Ключевые слова — моделе-ориентированная системная инженерия, управление жизненным циклом, PLM платформа, PolarSys Capella, T-FLEX.
I. Введение
В современном мире прослеживается тенденция к увеличению сложности технологических объектов. Это обусловлено тем, что технологические объекты включают в себя множество подсистем, которые связаны между собой определенным образом и охватывают множество инженерных областей. Кроме
Статья получена 16 июня 2021.
А. С. Королев, НИЯУ МИФИ (e-mail: askorolev@mephi.ru).
C. Г. Кюрчева, НИЯУ МИФИ (e-mail: kyurcheva@yandex.ru).
этого, объекты имеют несколько вариантов системных архитектур на различных уровнях проектирования. Так же возрастающую сложность современных объектов в значительной мере повлияло резкое увеличение числа дисциплин, задействованных при создании и использовании объектов, это означает, что предметная область инженерных объектов с течением времени только увеличивается. Сложность технологических объектов в сочетании с глобальной конкурентоспособностью компаний требует внедрения оптимизированных подходов к разработке продуктов, которые могут использовать весь потенциал передовых технологий в проектировании и производстве. Индустрия 4.0 (Четвертая промышленная революция) требует дополнения инженерных подходов современными технологии, тем самым изменяя взгляды на разработку и производство технологических объектов.
Концепция цифрового производства позволяет создавать цифровые производственные предприятия, элементы которых взаимосвязаны между собой и которое также обменивается данными, анализирует и использует информацию для дальнейших интеллектуальных действий в физическом мире. Одним из ключевых факторов, способствующих развитию цифрового производства, является концепция управления жизненным циклом продукта (РЬМ). Это своего рода бизнес-стратегия, которая сопровождает разработку объектов, используя ресурсы, необходимые для их информационной поддержки на протяжении всех этапов жизненного цикла.
Хотя РЬМ имеет дело с мельчайшими деталями управления жизненным циклом, его можно считать независимым от метода, и поэтому для определения деятельности по проектированию и разработке используется дисциплина системного проектирования. Процесс системной инженерии ^Б) был предложен и фактически принят рядом организаций и компаний для решения сложных задач разработки сложных современных систем. Очень скоро стало понятно, что переход от реализации SE на основе документов к проектированию систем на основе моделей необходим для поддержки индустрии 4.0, в том числе для создания цифрового производства [1]. Согласно Международному совету системной инженерии (INCOSE), моделе-ориентированную системную инженерию (MBSE)
можно определить, как формализованное приложение моделирования, которое поддерживает требования к системе, проектирование, анализ, верификацию и валидацию, начиная с этапа концептуального проектирования и на протяжении всех последующих этапах жизненного цикла. Существует несколько инструментов и методов, которые поддерживают SE / MBSE, но не являются частью всего процесса РЬМ, даже несмотря на то, что концепция совместной работы в течение жизненного цикла разделяется обоими, и конвергенция этих двух технологий является отраслевой тенденцией.
Возможность разрабатывать современные продукты (которые обычно представляют собой системы, стоящие на стыке нескольких предметных областей) с использованием интегрированной цифровой платформы, сочетающей в себе как концепцию РЬМ-платформы, так и подходы MBSE, охватывающей весь жизненный цикл, лежит в основе революции цифровизации, которая движет цифровым предприятием и Индустрией 4.0.
Если рассматривать процесс проектирования объекта привлекая концепцию цифрового производства, то на всех этапах жизненного цикла необходимо иметь единую информационную модель, которая все время будет содержать актуальные данные, необходимые в процессе разработки. Таким образом для одного проектируемого технологического объекта необходимо иметь набор информационных моделей, используемых на разных этапах жизненного цикла, которые будут призваны обеспечить целостные процесс разработки.
Но возникает проблема, которая заключается в том, что, используя несколько информационных моделей в процессе проектирования объектов, нужно пристально следить за релевантностью этих моделей. При изменении элементов в одной модели, необходимо оперативно вносить изменения и в остальные, которые с ней связаны тем или иным образом для того, чтобы предотвратить ситуации с утерей актуальных изменений в процессе проектирования.
На данный момент не существует оптимального решения в виде единой системы для проектирования объектов, которая бы поддерживала связь между подходом MBSE и концепцией управления жизненным циклом продукта и предоставляла единое пространство для работы с полной цифровой моделью объекта\изделия, без привлечения сторонних ресурсов в виде дополнительного программного обеспечения, хранилища данных (справочников), временных затрат.
В связи с вышесказанным встаёт вопрос об интеграции между инструментами MBSE и системами управления жизненным циклом для того, чтобы сделать процесс актуализации изменений более эффективным.
II. Методический аспект интеграции систем
ПРОЕКТИРОВАНИЯ
Важным аспектом современного производства является управление моделью жизненного цикла создаваемых систем, с целью обеспечения
эффективности разработки с точки зрения всех заинтересованных сторон. В современной системной инженерии сейчас активно развивается моделе-ориентированный подход к разработке, при котором разработка систем ведётся с применением моделей вплоть до выпуска первого изделия. Модели, обладающие достаточной степенью детализации и прошедшие верификацию и валидацию, используются в качестве задания для разработки систем. В моделе-ориентированной системной инженерии система моделируется на всех этапах ее жизненного цикла. Для этого используются соответствующие языки моделирования, инструменты и методы. Одним из примеров языков моделирования является SySML.
Основной целью моделе-ориентированной системной инженерии является определение функциональных и нефункциональных требований к системе на основе потребностей различных заинтересованных сторон. Таким образом модель может обеспечить архитектурное представление системы, которое соответствует этим требованиям. Оно должно представлять функциональную и логическую архитектуры системы, а также её физическую архитектуру на всех уровнях абстракции. Функциональные требования к системе позволяют идентифицировать различные функции системного уровня, которые в дальнейшем декомпозируются и распределяются между различными логическими подсистемами и компонентами системы. Физическая архитектура - это техническая реализация логической архитектуры. Архитектуры вместе составляют структурную и поведенческую модель системного проектирования.
Если смотреть на современный инструментарий подхода моделе-ориентированной системной инженерии, то целесообразно, в первую очередь, обратить внимание на метод ARCADIA (Architecture Analysis & Design Integrated Approach) [2]. Данный метод представляет архитектурный подход к функциональному анализу систем в соответствии со стандартом ИСО/МЭК 42010. При этом он четко разделяет область проблем с целями, потребностями и требованиями заинтересованных сторон и область решений с функциями системы и ее компонентов и соответствующим списком требований.
Если мы посмотрим подход к архитектурному описанию систем согласно ISO/IEC 42010, то целью там является идентифицировать заинтересованные стороны, их интересы и точки зрения. Каждая точка зрения определяет информацию, требуемую для охвата интереса соответствующей заинтересованной стороны.
На рис. 1 представлена модель, которая описывает один из возможных подходов использования MBSE в процессе создания системы по водопадной модели с ориентацией на документ как основной артефакт. При этом подходе модель системной архитектуры и системная модель должны разрабатываться наряду с проектными моделями (в западной практике - Detailed Design). Системная модель используется как
централизованный хаб обмена данными, обеспечивающий интерфейсы между различными инструментами разработки [3].
Polarsys Capella Design software
Рис. 1. Применение моделей на стадиях ЖЦ изделия
В результате мы получим связанные между собой модель требований, системную архитектуру, системную модель и проектные модели. Верификация и валидация проектных решений может осуществляться при этом, начиная с ранних стадий разработки.
Polarsys Capella является одним из инструментов, который совмещает и язык построения архитектурных описаний системы и метод такого построения и, собственно программную реализацию системы поддержки. Capella позволяет моделировать систему в домене архитектуры и в домене требований. Для этого в этом инструменте есть набор соответствующих диаграмм. По типам это древовидные диаграммы декомпозиции, диаграммы взаимодействия,
возможностей, функций, деятельности, потоков данных, сценариев и другие. При помощи Capella можно выполнить поддержку разработки на предпроектных и проектных стадиях по ГОСТ 34.601. Можно это сделать и в домене архитектуры, и в домене требований, реализовав объектные модели требований и связав сущности требований с элементами архитектурных описаний. В домене архитектуры моделируются архитектура применения, архитектура системы в целом, логическая, физическая архитектуры и конфигурация конечного продукта. В домене требований моделируются требования заинтересованных сторон, требования к системе в целом, к логическим и физическим компонентам. При этом, можно вести управление передачей требований с уровня на уровень, порождением новых требований, распределением требований по архитектурным компонентам. На рис.2 показан процесс разработки системы в архитектурном домене и в домене требований [4].
Рис. 2. Процесс формирования архитектурных описаний и требований к системе
Диаграммы ARCADIA/Capella довольно точно отражают системные требования и позволяют описать структуру и поведение системы. Тем не менее, анализ поведения систем для оценки требований здесь не предусмотрен. На помощь приходят инструменты моделирования, предназначенные для конкретной области. Одним из специализированных инструментов, предназначенным, в частности, для моделирования и симуляции поведения системы является, например, MathWorks Simulink [5].
Непрерывность потока информации может обеспечиваться использованием PLM платформы, которая позволяет консолидировать и интегрировать различные модели, используемые на протяжении всего жизненного цикла разработки изделия. Платформа PLM также используется для проектирования производственного процесса и управления данными предприятия.
На основании предложенного стека программного обеспечения для задачи симуляции цифрового производства подойдёт цифровая платформа T-Flex PLM. Она поддерживает интеграции со многими CAD системами, в том числе поддерживается двухсторонняя интеграция с T-Flex CAD.
Объединяя сказанное ранее можно предложить один из вариантов инструментария поддержки разработки систем на стадиях жизненного цикла (рис. 3). Он включает в себя инструментарий построения архитектурных описаний и инженерии требований, инструментарий имитационного моделирования, инструментарий PDM/PLM, инструментарий CAD с разными инструментами анализа и планирования производства [5].
Рис. 3. Специализированное программное обеспечение для поддержки системного проектирования и разработки
Перед многими предприятиями сейчас остро стоит задача разработки интеграционных модулей между PLM системами и сторонним программным обеспечением, типа PolarSys Саре11а и MathWorks Simulink, так как наличие подобных модулей может значительно повысить эффективность использования ресурсов проекта.
Хоть компания Thaïes продвинулась в решении этих проблем, интегрировав методику, язык и инструмент в одном средстве - Capella (методика ARCADIA, язык Thaïes, основанный на SySML). Но до сих пор остается актуальной задача интеграции методики, языка и инструмента таким образом, чтобы проводить функциональный анализ совместно с инженерией требований, построением системной архитектуры, разработкой проектной и конструкторской документацией на изделие. Это позволит повысить эффективность междисциплинарной работы проектных групп как на стадии разработки концепции, так и на стадии инженерной разработки в жизненном цикле систем.
III. Технический аспект интеграции систем
ПРОЕКТИРОВАНИЯ
На данный момент существует необходимость в интеграции PLM-системы со сторонними программными решениями, которые смогут покрыть высокий уровень проектирования, описанного выше ранее сквозного процесса разработки. Такая связь между инструментами проектирования позволит наиболее эффективно проходить все стадии жизненного цикла, избегая потерь актуальной информации и использовать единую цифровую модель на протяжении всех этапов жизненного цикла.
Если спускаться сверху вниз по модели жизненного цикла, то на этапе проектирования системы можно рассматривать стыковку между артефактами производимыми разными инструментами системного проектирования. А так как модели Capella обладают достаточной степенью детализации и проходят формальную верификацию, они могут использоваться как основа описания объектов, которыми оперирует PLM-система.
После обоснования связи двух систем на идейном уровне, можно перейти к рассмотрению моделей данных, которыми оперируют системы, представляющие интерес в контексте данной статьи.
Структура данных T-FLEX DOCs (ядра T-FLEX PLM) является логичной и достаточно простой для восприятия, потому что построена на основании принципа иерархичности. Система состоит из справочников, которые в логическом смысле являются контейнерами, хранящими совокупность данных. Единица данных внутри справочника - это объект. Объекты представляют собой сущность, имеющую набор атрибутов - параметров, который определенным образом характеризует ее. При этом объекты могут принадлежать разным типам, и тогда набор параметров у таких объектов будет разный. Кроме этого, объекты могут иметь связь с другими объектами, причем не только внутри справочника, которому они принадлежат, но и за его пределами. Таким образом на уровне бизнес-логики PLM-система использует простую объектную модель представления данных.
Далее будет рассмотрена модель данных, которую использует инструмент моделе-ориентированной системной инженерии Polarsys Capella. Использование методологии ARCADIA, позволяет моделировать систему на разных архитектурных уровнях (рис.4): уровне анализа применения, уровне функциональных и нефункциональных потребностей, уровне логической архитектуры и уровне физической архитектуры. На них существует определенный набор диаграмм, которые позволяют максимально описать систему при проектировании [2].
Для решения поставленных в данной работе задач, особый интерес представляет уровень физической архитектуры. Данный уровень наиболее приближен к физически реализуемой системе и поэтому именно он может быть задействован для интеграции c T-FLEX DOCs. При детальном изучении диаграмм, которые Capella позволяет использовать на физическом уровне проектирования, была выделена диаграмма Физической архитектуры (Physical Architecture Blank). Диаграммы данного вида могут содержать три типа элементов:
• физические компоненты узла
• физические компоненты поведения
• физические функции
Рис.4 - Уровни проектирования Capella (ARCADIA)
Компоненты узла представляют собой элементы, которые в будущем подлежат физической реализации. Этими же элементами оперирует PLM-система в процессе управления жизненным циклом продукта. С помощью компонентов узла представляются физически реализуемые системы (или подсистемы), которые впоследствии проектируются с помощью систем автоматизированного проектирования (CAD) для
дальнейшего производства.
Для хранения данных об объектах и справочниках в T-FLEX DOCs используется база данных. Справочник в базе данных представляется таблицей, либо совокупностью таблиц. Объекты справочников представлены в виде записей в таблице, которая ассоциирована с определенным справочником. Например, справочник «Электронная структура изделий», который содержит состав сборочной единицы, комплекса или комплекта и иерархические (связи) между его составными частями, представлен с помощью двух таблиц Nomenclature (данная таблица отвечает за описание единиц объекта) и NomenclatureHierarchy (отвечает описание единиц иерархических связей между объектами справочника).
Модель хранения данных в Capella представляет собой XML-структуру, которая описывает построенные диаграммы на формальном языке разметки. XML-документ представляет собой дерево элементов, каждый из которых описан с помощью определенного тега и имеет набор атрибутов.
Внутри тега «ownedArchitectures» с атрибутом «name» равным «Physical Architecture» содержится описание архитектуры физического уровня.
Представление компонентов узла осуществляется с помощью тега «ownedPhysicalComponents», у которого атрибут «nature» равен «NODE».
Capella хранит описание моделей с помощью специальных, определенных под данную задачу, XML-тегов и поддерживает принцип иерархичности между элементами. Такое представление данных делает возможным разработку алгоритма, для получения конкретных, интересующих в данный момент элементом, который может быть использован для реализации интеграции между системами.
Таким образом, зная формат представления одних и тех же объектов в разных системах, можно предпринять попытку интеграции на основе преобразования представления данных.
В структуре XML данных Capella производится поиск тега <ownedArchitectures> с атрибутом name="Physical Architecture", который отвечает за представление всех объектов на физическом уровне проектирования. Для наглядности, можно сказать, что модуль обращается к архитектурной диаграмме физического уровня Capella (Physical Architecture Blank). Далее, внутри тега производится поиск физических компонент узла. В XML структуре данные компоненты представляются с помощью тега <ownedPhysicalComponents> c указанием атрибута nature = "NODE". После получения всех верхнеуровневых физических компонент узла, определяется их принадлежности к целевой системе или внешнему окружению. Для данной цели используется отслеживание распределения компонент поведения физического уровня и системных функций. Если физическая компонента узла содержит в себе компоненту поведения, которая в свою очередь имеет распределенные системные функции, то данная
физическая компонента узла представляется как целевая система.
Когда компонент представляющий целевую систему определен, модуль получает все дочерние физические компоненты узла внутри него. Дочерние компоненты, так же представлены тегом <ownedPhysicalComponents> c указанием атрибута nature = "NODE".
Далее, набор данных об элементах, которые подлежат переносу в PLM-среду, преобразовывается в представление понятное для T-FLEX DOCs. Конвертация происходит как с помощью сопоставления полей таблиц базы данных T-FLEX DOCs с тегами, атрибутами и оценкой иерархии структуры XML-схемы Capella (Таблица 1). Таким образом получается набор значений, который однозначно описывает элементы справочника «Электронная структура изделий» T-FLEX DOCs.
Далее полученная структура данных может быть напрямую загружена в базу данных T-FLEX DOCs при использовании средств авторизации Windows.
Затем происходит подключение к базе данных MS SQL Server, которую использует T-FLEX DOCs для хранения данных об объектах. Подключение происходит с помощью учетной записи Windows от имени администратора. И затем осуществляет добавление сгенерированных из XML представления Capella объектов напрямую в базу данных посредством базовых SQL-запросов с конструкцией INSERT INTO.
На основании описанного выше подхода было реализовано приложение, обеспечивающее интеграцию между инструментами проектирования Capella и T-FLEX DOCs. Приложение запускается по требованию пользователя и требует для работы указания трех параметров:
• Путь к папке проекта Capella
• Название сервера T-FLEX DOCs
• Название базы данных T-FLEX DOCs
Таблица 1 - Логика сопоставления атрибутов Capella и полей таблицы T-FLEX
Структура Capella Поля в таблицах T-FLEX DOCs
<ownedPhysicalComponents> пате=(«Обозначение» + «Имя») Object (Nomeclature)
Name = «Имя» (Nomeclature)
Denotation = «Обозначение» (Nomeclature)
FNN = «Обозначение» (Nomeclature)
Name = «Имя» (Documents)
<ownedPhysicalComponents> summary Comment (Nomeclature)
<ownedPhysicalComponents> -корневой тег среди тегов <ownedPhysicalComponents> s_ClassID = 610 (кодификатор типа -Сборочная единица)
(Nomeclature)
s_ClassID = 265 (кодификатор типа -Деталь) (Documents)
<ownedPhysicalComponents> -НЕ корневой тег среди тегов <ownedPhysicalComponents> s_ClassID = 609 (кодификатор типа -Деталь) (Nomeclature)
s_ClassID = 264 (кодификатор типа -Деталь) (Documents)
4924-4, Print on Demand(PoD) ISBN: 978-1-5386-4925-1, DOI: 10.1109/MLSD.2018.8551837
[4] Wasson, Charles S. System engineering analysis, design, and development: concepts, principles, and practices / Published by John Wiley & Sons. 2016. - 880 pages.
[5] Королев А.С., Егоров И.И, Щербаков В.В. Информационные технологии поддержки управления жизненным циклом сложных технологических объектов// Информатизация и связь -Таганрог: Издательство ЮФУ, №6, 2020. С.61-65.
После этого происходит поиск и преобразование необходимых представлений компонентов целевой системы и последующая загрузка их в базу данных Т-БЬЕХ DOCs. В итоге внутри справочника «Электронная структура изделий» автоматически создаются и отображаются необходимые нам элементы целевой системы, которые были представлены на архитектурной диаграмме физического уровня Саре11а (Рис.5).
Электронная структура изделий X
ОЭЭ®«£@°О0 BS О1 Bio™, - ^Операции -
Изделие: Не задана на Любую дату
Структура: | К. Dl ПС 3, □ Ф, Цэ
► Щ Электронная структура изделий ►
Объект
л ф Электронная структура изделий
л $$ С2020.1 - Умная колонка - А. 1
С.2020,1,1 - Микрофон -А.1 Ф 1
^ С.2020,1,2 - Динамик - А.1 О 1
С.2020,1,3 - Микрокомпьютер А.1 Ф 1
t^l С.2020.1.6 - Внешняя звуковая арта - А.1 Ф 1
С.2020,1,4 - Коммутатор памяти -А.1 Ф 1
С.2020,1.5 - WrFr модуль - А.1 Í 1
Рис. 5 Справочник «Электронная структура изделий» с добавленными объектами
IV. ЗАКЛЮЧЕНИЕ
В статье был продемонстрирован подход к разработке интеграционного модуля, между предложенной PLM-системой T-FLEX DOCs и инструментом моделе-ориентированной системной инженерии Polarsys Capelo, который может повысить эффективность использования ресурсов проекта. Рассмотрены как методические, так и технические аспекты интеграции. Результаты работы применимы как на производственных предприятиях для автоматизации деятельности по проектированию систем, так и в образовательных учреждениях для создания систем поддержки учебного процесса по таким дисциплинам, как «Системная инженерия», «Управление жизненным циклом» и схожих с ними.
БИБЛИОГРАФИЯ
[1] Егоров И. И., Королев А. С. Система обеспечения образовательного продукта" Управление жизненным циклом сложных технологических объектов" //УПРАВЛЕНИЕ РАЗВИТИЕМ КРУПНОМАСШТАБНЫХ СИСТЕМ MLSD'2020. -2020. - С. 1492-1498.
[2] Jean-Luc Voirin. Model-based System and Architecture Engineering with the Arcadia Method 1st Edition // ISBN: 9780081017944 ISTE Press - Elsevier. 2017.
[3] Anton S. Korolev, Alexander Yu. Shamanin. The Use of Formal Methods of Verification and Validation in NPP Design // IEEE Xplore Digital Library, 29 November 2018, Electronic ISBN: 978-1-5386-
Problems and description of the approach to integrating systems design tools
A.S. Korolev, S.G. Kyurcheva
Adstract — In the modern world, there is a tendency towards an increase in the complexity of objects, which requires the introduction of optimized approaches to product development into production. One of these approaches is the use of a single digital model at all stages of the product life cycle. In this article, we are talking about the need for a single digital product model when implementing the concept of digital production (Industry 4.0). To build an end-to-end design process, it is necessary to combine such approaches as the concept of life cycle management and model-based systems engineering. This article discusses the main issues of integration between model-based systems engineering tools and PLM systems that support the concept of product lifecycle management.
In particular, the problem of the relationship between the previously mentioned approaches is considered. At the moment, there is no optimal solution in the form of a unified design system for complex technological objects that would support the connection between the approach of model-based systems engineering and the concept of life cycle management. In connection with the above, the question arises of creating an integration between model-based systems engineering tools and life cycle management systems in order to increase the efficiency of the process of updating changes.
The article proposes and describes an approach to integration between systems design tools using data structure transformation using the example of the model-oriented systems engineering tool PolarSys Capella and the T-FLEX DOCs PLM platform.
Keywords — model-based systems engineering, lifecycle management, PLM platform, PolarSys Capella, T-FLEX.
References
[1] Egorov I. I., Korolev A. S. The system for providing the education product "Management of life cycle of complex technological objects" //MANAGEMENT OF LARGE-SCALE SYSTEM DEVELOPMENT MLSD'2020. - 2020. - C. 1492-1498.
[2] Jean-Luc Voirin. Model-based System and Architecture Engineering with the Arcadia Method 1st Edition // ISBN: 9780081017944 ISTE Press - Elsevier. 2017.
[3] Anton S. Korolev, Alexander Yu. Shamanin. The Use of Formal Methods of Verification and Validation in NPP Design // IEEE Xplore Digital Library, 29 November 2018, Electronic ISBN: 978-1-53864924-4, Print on Demand(PoD) ISBN: 978-1-5386-4925-1, DOI: 10.1109/MLSD.2018.8551837
[4] Wasson, Charles S. System engineering analysis, design, and development: concepts, principles, and practices / Published by John Wiley & Sons. 2016. - 880 pages.
[5] Korolev A.S., Egorov I.I, Shcherbakov V.V. Information technologies to support life cycle management of complex technological objects // Informatization and communication -Taganrog: SFedU Publishing House, №6, 2020. C.61-65.
