CC BY-NC-ND
27
БИЗНЕС-ИНФОРМАТИКА Т. 15 № 4 - 2021 DOI: 10.17323/2587-814X.2021.4.76.92
Технология проектирования инновационных процессов создания продукции и услуг сетевого предприятия с использованием i4.0-системы, основанной на знаниях
Ю.Ф. Тельнов О
E-mail: Telnov.YUF@rea.ru
В.А. Казаков
E-mail: Kazakov.VA@rea.ru
А.В. Данилов
E-mail: Danilov.AV@rea.ru
Российский экономический университет им. Г.В. Плеханова Адрес: 117997, г. Москва, Стремянный пер., д. 36
Аннотация
Создание сетевых предприятий на основе цифровых технологий индустрии четвертого поколения открывает широкие возможности для повышения гибкости производства, клиентоориентированности и осуществления непрерывных инноваций в выпускаемой продукции и оказываемых услугах. Вместе с тем, новые возможности вызывают необходимость разработки новых методов и технологий проектирования инновационных процессов в условиях применения цифровых 14.0-платформ, что обусловливает актуальность темы представленной работы. Целью работы является определение технологий проектирования инновационных процессов создания продукции и услуг с использованием 14.0-систем, которые основаны на многоагентном взаимодействии оболочек администрирования ресурсов, отображающих цифровые двойники компонентов продуктов, и применении онтологических и когнитивных методов формирования и обоснования проектных решений. Представленная работа использует предметно-ориентированный подход к проектированию, архитектурный фреймворк построения 14.0-систем, методы онтологического инжиниринга, развертывания функции качества, анализа видов и последствий потенциальных несоответствий, обработки нечетких множеств. В работе предложены принципы выделения ограниченных контекстов предметной области в соответствии с выполняемыми проектными работами для стадий жизненного цикла и подсистем (компонентов) продукции. Для ограниченных контекстов предметной области предусматривается создание оболочек администрирования ресурсов 14.0-систем, с помощью которых осуществляется поддержка инновационного процесса и многоагентное
взаимодействие его участников. В качестве когнитивных инструментов принятия проектных решений предлагается использовать сервисы оценки важности определяемых качественных характеристик продукции и минимизации отклонений предлагаемых решений от формируемых функциональных и нефункциональных требований. Используемые методы онтологического инжиниринга и моделирования данных позволяют динамически развивать инновационный проект и поддерживать в процессе проектирования различные версии проекта. Применение предложенной технологии проектирования инновационных процессов создания продукции и услуг на сетевых предприятиях с использованием i4.0-систем позволит улучшить качество принимаемых проектных решений, повысить динамичность и непрерывное развитие инновационных проектов.
Ключевые слова: инновационный процесс; цифровой двойник; предметно-ориентированный подход; ограниченный контекст; цепочка создания ценности; онтология; многоагентное взаимодействие; i4.0-система; i4.0-платформа; оболочка администрирования ресурса.
Цитирование: Тельнов Ю.Ф., Казаков В.А., Данилов А.В. Технология проектирования инновационных процессов создания продукции и услуг сетевого предприятия с использованием i4.0-системы, основанной на знаниях // Бизнес-информатика. 2021. Т. 15. № 4. С. 76-92. DOI: 10.17323/2587-814Х.2021.4.76.92
Введение
Инновационный процесс проектирования продукции и услуг на сетевом предприятии представляет собой итерационный процесс построения цепочки создания ценности, в котором концептуальная проработка конструкции изделия сопровождается выбором участников проекта и согласованием с ними условий выполнения работ на стадии реализации. Архитектура системы, основанной на знаниях (СОЗ), поддерживающей инновационный процесс проектирования продукции и услуг, была предложена авторами в работе [1], отличительной особенностью которой является применение технологий цифровых нитей [2, 3] и цифровых двойников [4-6] для отображения процесса проектирования в системе моделей продукта и связанных процессов, многоагентной технологии для организации взаимодействия участников цепочки создания ценности [7-9] и онтологического подхода [10-12] для автоматизации поиска релевантных источников информации и организации информационного обмена между программными агентами. Для дальнейшего развития технологии проектирования инновационных процессов создания продукции и услуг необходимо провести обоснование выбора программной платформы для многоагентной реализации системы, основанной на знаниях, и, с учетом выбранной программной среды реализации, определить более детально технологию проектирования.
Методологические основы концептуального проектирования таких сложных процессов, как инновационные процессы проектирования продукции и
услуг, заложены в предметно-ориентированном подходе [13, 14], который позволяет структурировать предметную область с учетом ее объективной структуры и субъективной составляющей, определяющей формирование эффективно работающих проектных коллективов. В этой связи в статье рассматривается применение предметно-ориентированного подхода к выделению ограниченных контекстов инновационного процесса в соответствии со стадиями жизненного цикла и с цепочкой создания ценности для декомпозиции процесса на отдельные компоненты и установление между ними различных типов интерфейсов в соответствии с потребностями многоагент-ного взаимодействия участников инновационного процесса.
Многоагентная реализация системы, основанной на знаниях, для поддержки инновационного процесса проектирования продукции и услуг нацелена на обеспечение устойчивости всей структуры и автономности и интероперабельности ее компонентов, распределенных в вычислительной системе и функционирующих на единой программной платформе. С учетом того факта, что предлагаемая СОЗ реализует технологию цифровых нитей и двойников [1], в статье рассматривается применение программной платформы индустрии четвертого поколения ^4.0-платформы) [15] и оболочек администрирования ресурсов (asset administration shell, AAS) [16, 17] для представления ограниченных контекстов программных агентов, соответствующих отдельным компонентам цепочки создания ценности. При этом определяется состав функци-
ональных и платформенных (инфраструктурных) сервисов, необходимых для осуществления инновационного процесса создания продукции и услуг в сетевой распределенной среде.
В целях разработки механизмов поддержки процессов планирования и организации цепочки создания ценности, которая реализуется путем взаимодействия программных агентов отдельных AAS, в статье предлагается применение онтологического [11, 12] и когнитивного [18, 19] подходов, обеспечивающих формализацию алгоритмов выбора партнеров по бизнесу и согласование условий взаимодействия на основе методов семантического поиска и нечеткой оценки соответствия требований и возможностей их исполнения. Применение онтологического и когнитивного подходов во взаимосвязи позволит выстраивать эффективные цепочки создания ценности, направленные на реализацию перспективных и реально исполняемых конструкций продукции, а механизмы мно-гоагентного взаимодействия партнеров по бизнесу на основе технологии цифровых двойников на i4.0-платформе обеспечат сокращение времени и повышение гибкости проектирования инновационных процессов.
1. Предметно-ориентированный подход к структурированию предметной области проектирования инновационных процессов
В ходе проектирования инновационных процессов создания продукции и услуг возникают проблемы рационального определения границ проектных задач, принятия решений при формировании проектных групп, организации взаимодействия между проектными группами. В качестве методологии проектирования инновационных процессов создания продукции и услуг предлагается использовать предметно-ориентированный подход, который наилучшим образом ориентирован на решение когнитивных проблем в проектных коллективах, возникающих в ходе согласования и обоснования проектных решений [13, 14].
Предметно-ориентированный подход к инновационному проектированию направлен на проведение эффективной декомпозиции процесса проектирования по предметному и контекстному (когнитивному) принципам и позволяет вырабатывать общий язык взаимодействия в проектных группах разнопрофильных специалистов. Концеп-
ты этого языка и соответствующих проектных решений с нашей точки зрения могут отражаться в компьютерно-поддерживаемых моделях в виде он-тологий.
В своей основе предметно-ориентированный подход предназначен для проектирования особого вида инновационной продукции — программного обеспечения (ПО) и применения гибких итерационных технологий разработки ПО, в которых каждая итерация предполагает создание работающей версии программного обеспечения. Учитывая тот факт, что современное производство обычной продукции становится цифровым (то есть продукты, с одной стороны, насыщаются встроенным программным обеспечением, а с другой стороны, поддерживаются удаленными компьютерными моделями — цифровыми двойниками) принципы предметно-ориентированного проектирования в полной мере можно распространить и на традиционную продукцию и услуги с каскадной (последовательной) технологией разработки.
Декомпозиция и моделирование предметной области для проектирования инновационных процессов рассматривается с двух точек зрения, со стороны отдельных подсистем, так называемых подобластей, и с точки зрения решения отдельных задач, так называемых ограниченных контекстов, для совместного решения которых создаются проектные группы.
С точки зрения выделения подсистем (подобластей) и последующего моделирования обычно применяется функциональный принцип, то есть принцип выделения функций, которые должен исполнять продукт, при этом могут выделяться межфункциональные области интеграции. Очень часто разработка функциональных подсистем приводит к разработке соответствующих физических частей продукции. Например, при проектировании автомобиля в качестве подобластей выделяются ходовая часть, топливная система, электрооборудование, система безопасности и др., которые в свою очередь могут быть разбиты на компоненты, соответствующие отдельным узлам или деталям. На рисунке 1 подсистемы и компоненты (поддомены) показаны скругленными прямоугольниками, а стрелки отражают порядок декомпозиции предметной области.
Ограниченные контексты связаны с конкретными решаемыми задачами и имеют четко очерченные границы. Над решением инновационных задач
Рис. 1. Пример взаимодействия подсистем и ограниченных контекстов
в ограниченном контексте задействуются специалисты, прежде всего, двух типов: разработчики и эксперты предметной области. В зависимости от сложности решаемой задачи к инновационному процессу могут привлекаться разработчики и эксперты разных профилей.
В инновационных процессах создания продукции ограниченные контексты целесообразно выделять по этапам жизненного цикла: формирование концепции и требований к продукции, проектирование конструкции и цепочки создания ценности, изготовление опытного образца и испытание, промышленное производство и сопровождение, утилизация. При этом если одна и та же группа занимается несколькими работами на протяжении жизненного цикла, то эти работы могут быть объединены в один ограниченный контекст. Например, работы по формированию концепции (качественных характеристик продукции) и требований, проектированию конструкции и цепочки создания ценности могут быть объединены в один и тот же ограниченный контекст при условии совместной работы над перечисленными задачами одних и тех же специалистов. На рисунке 1 отдельные работы показаны овалами, а их объединение в ограниченные контексты — прямоугольниками. При этом реализация ограниченных контекстов в зависимости от функциональных подсистем или даже составных
частей продукта может существенно отличаться друг от друга.
Внутри одного ограниченного контекста участники процесса создания продукта работают на равноправной основе, формируя наборы свойств и правила (процедуры) поведения. При этом в рамках одного ограниченного контекста могут использоваться типовые онтологии, справочники, любые другие внешние информационные ресурсы. В процессе совместной работы формируется единый язык взаимодействия, оформляемый в виде итерационно-развиваемой онтологии. По ходу работы могут разрабатываться математические и имитационные модели, которые позволяют обосновывать принятие оптимальных или рациональных проектных решений.
Ограниченные контексты инновационного процесса создания продукции могут задаваться как на продукт в целом, так и для более детальной проработки на его отдельные компоненты. В ограниченном контексте проектирования продукта в целом прорабатывается цепочка создания ценности, вызывающая необходимость выбора исполнителей отдельных компонентов. В этом случае должны организовываться интерфейсы между ограниченными контекстами для всего продукта и для его отдельных компонентов, как правило, в парадигме «требование — исполнение».
Интерфейсы между ограниченными контекстами могут осуществляться посредством различных способов [14]:
♦ партнерство (partnership). В этом случае группы исполнителей процесса, работающие над смежными предметными подобластями, активно обмениваются результатами совместной работы; участники групп работают над общими частями онтологии и должны обмениваться как разрабатываемыми частями онтологии, так и проектными результатами;
♦ общее ядро (shared kernel). Данный способ взаимодействия можно рассматривать как частный случай организации партнерства. В этом случае организуется общий ограниченный контекст для нескольких групп, которые имеют к нему доступ с различными режимами разделения ресурсов и согласования результатов;
♦ разработка «заказчик — поставщик» (customer — supplier development). Этот способ можно рассматривать как способ взаимодействия по цепочке создания ценности, когда вышестоящая группа продукта, представляющая заказчика, формирует спецификации требований для исполнителя заказа (поставщика). Поставщик должен когнитивно и экономически оценить полученные требования, в соответствии с этими требованиями дать согласие на исполнение и, соответственно, их исполнить. В данном случае возможно взаимодействие с внешними поставщиками (производителями) в режиме рассылки сообщений и отложенного принятия решений. Для согласования требований между заказчиками и исполнителями необходимо также осуществлять согласование взаимодействующих фрагментов онтологий;
♦ конформист (conformist). Данный способ взаимодействия является частным случаем интерфейса «заказчик — поставщик». В этом случае исполнитель находится в подчиненном положении и исполняет требования заказчика без согласования с последним возможностей выполнения заказа. Такой способ установления интерфейса характерен для внутренних отношений подразделений предприятия, когда вышестоящая структура хорошо представляет возможности нижестоящих структур, а нижестоящие структуры в полной мере владеют онтологией или принимают непосредственное участие в ее выработке;
♦ предохранительный уровень (anticorruption layer). Данный способ взаимодействия также является частным случаем интерфейса «заказчик —
поставщик». Но в этом случае однозначно запрещается прямой доступ к данным поставщика для критериального выбора. Получение ответов на интересующие запросы возможен только через посылку сообщений, как правило, в офлайн-режиме. Таким образом, нижестоящий уровень организации защищает себя от возможного доступа заказчика к конфиденциальной информации. В этом случае согласование требований через онтологию является наиболее сложным, и чаще всего требуется трансляция представления совместно используемых знаний;
♦ служба с открытым протоколом (open host service). В данном случае используется протокол, который открывает доступ к ограниченному контексту через набор сервисов, которые расширяются и уточняются по мере развития проекта;
♦ общедоступный язык (published language). Этот способ является частным случаем способа «служба с отрытым протоколом». Использование общедоступного языка предполагает использование общей онтологии проекта. В некоторых случаях возможна трансляция концептов в обоих направлениях взаимодействия;
♦ отдельное существование (separate ways). Несвязанное использование ограниченных контекстов может быть обусловлено конкурирующей разработкой продукции и услуг. В этом случае принятие решений осуществляется по мере завершения проекта;
♦ «большой комок грязи» (big ball of mud). Это взаимодействие нового продукта с уже существующей частью продукта, которая может быть выполнена без соблюдения требования предметно-ориентированного проектирования.
С позиции создания некоторого материального продукта структурная модель ограниченного контекста преобразуется в программный код цифрового двойника. При этом цифровой двойник будет соответствовать одному ограниченному контексту, отражающему либо продукт в целом, либо его отдельный компонент, и представлять по сути автономный программный агент в многоагентной системе, основанной на знаниях, для решения задач проектирования инновационного процесса создания продукции и оказания услуг. При этом наличие нескольких подсистем (подобластей) у продукта делает возможным специализацию разработки программных модулей под соответствующие подобласти и необходимость получения интегрированных решений на уровне всего продукта.
2. Программная реализации многоагентной системы, основанной на знаниях, для проектирования инновационных процессов с использованием оболочки администрирования ресурса
Предложенная в работе [1] система, основанная на знаниях, для проектирования инновационных процессов создания продукции и услуг может быть реализована в архитектуре системы индустрии четвертого поколения ^4.0-система) [20—22]. Она включает набор взаимодействующих между собой i4.0-компонентов оболочек администрирования ресурсов (AAS), к которым обращаются i4.0-приложения участников инновационных процессов. AAS является программной реализацией концепции цифровых двойников создаваемых продуктов или его частей, а также связанных ресурсов: станков, производственных линий, цепочек поставок, субъектов-исполнителей производственных процессов, информационных и организационно-управляющих ресурсов. С точки зрения предметно-ориентиро-
ванного подхода AAS продуктов и их компонентов в процессах проектирования инновационных процессов создания продукции и услуг будут составлять смысловое ядро СОЗ, а AAS остальных ресурсов — вспомогательные сущности.
Сервисы AAS разделяются на сервисы компонентов приложений и инфраструктурные сервисы платформы AAS. На рисунке 2 представлена структура оболочки администрирования ресурсов для продуктов (компонентов продуктов), взаимодействующая с i4.0-платформой.
Оболочка администрирования ресурса цифрового двойника отражает данные о некоторой физической сущности (любом ресурсе) и включает набор сервисов, реализующих функциональные модули решения проектных задач.
Данные о ресурсе определяют состояние этой сущности на различных этапах жизненного цикла, могут быть планируемыми, фактическими, прогнозируемыми, моделируемыми и т.д. Данные могут быть разнесены по подмоделям, например, иденти-
Оболочка администрирования ресурса (AAS)
Модуль формирования качественных характеристик ресурса
Платформа ¡4.0
Модуль управления Й Модуль управления 3 Модуль контроля
онтологиями 1 AAS ---- доступа к AAS
Модуль управления i СОА
Модули моделирования ресурсов
Модуль управления взаимодействиями AAS
Рис. 2. Структура оболочки администрирования ресурсов для продуктов (компонентов продуктов), взаимодействующая с 14.0-платформой
фикационным, техническим, операционным и до-кументационным подмоделям: 4 идентификационные данные, которые должны быть неизменяемыми в течение всего жизненного цикла проекта; 4- технические данные — количественные и качественные характеристики, соответствующие бизнес-требованиям к продукту по выполнению функций продукта;
♦ функциональные данные — требования к функциональным подсистемам продукта в случае достаточно сложной его структуры;
♦ проектные документируемые данные, отражающие характеристики реализации функциональных требований в части используемых технологий и исполнителей процессов;
4- операционные данные, отражающие результаты функционирования продуктов на стадии эксплуатации или результаты имитационного и математического моделирования на стадиях проектирования и разработки.
Сервисы компонентов приложений AAS соответствуют функциональным модулям приложений. В случае ограниченного контекста, связанного с проектированием инновационного процесса создания продукции и услуг, сервисы компонентов приложений вызывают модули приложений формирования качественных характеристики, требований к продуктам, проектирования конструкции и цепочек создания ценности, а также модуль-планировщик, координирующий выполнение всех функциональных модулей [1].
Инфраструктурные сервисы i4.0-платформы являются вспомогательными. Они обеспечивают функционирование собственно AAS и взаимодействие между AAS, и с этой точки зрения являются платформенными и стандартизированными. Инфраструктурные сервисы относятся к i4.0-платформе, на основе которой создается i4.0-система.
К инфраструктурным сервисам относятся, прежде всего, сервисы управления AAS, которые выполняют функции создания компонентов AAS, регистрацию и создание реестров сервисов, поиск и представление сервисов, поиск и представление данных и подмоделей AAS.
Набор стандартизированных сервисов моделирования ресурса позволяет генерировать и использовать данные о ресурсах с помощью инструментов
моделирования. В качестве типовых инструментов моделирования используются инструменты, реализующие:
4 методы развертывания функции качества (quality function deployment, QFD) для определения приоритетов реализации бизнес и функциональных требований; 4 методы анализа видов и последствий потенциальных несоответствий (failure mode and effects analysis, FMEA); 4 методы обработки нечетких множеств; 4 методы имитационного моделирования; 4 методы статистического моделирования; 4 методы машинного обучения и нейросетевого моделирования и др.
Таким образом, на i4.0-платформе можно реализовать общую функциональность различных видов моделирования (модули моделирования ресурса), необходимого для построения цепочки создания ценности — механизмы имитационного моделирования, алгоритмы QFD и FMEA, прочие математические и статистические алгоритмы моделирования. При этом любая AAS, участвующая на различных этапах цепочки создания ценности, может вызывать эти сервисы для реализации соответствующей функциональности (рис. 2), подставляя необходимые входные данные для моделирования из собственных подмоделей и получая необходимые результаты.
Для контроля доступа сервисов компонентов приложений к данным и моделям в конкретных AAS используются инфраструктурные сервисы i4.0-платформы, которые задают ограничения доступа для различных компонентов приложений, осуществляют обращение к онтологиям, определяют контекст совместного использования компонентов приложений, проверяют (классифицируют) соответствие обращений к сервисам компонентов приложений стандартам. На рисунке 2 инфраструктурные платформенные сервисы реализуют функции управления онтологиями, сервисно-ориентированной архитектурой, взаимодействия с другими AAS и контроля доступа к AAS.
AAS может предоставлять сервисные интерфейсы для программных приложений для доступа к своим данным и вызова команд или запуска моделей. Сервисные интерфейсы (например, реализованные в форме API RESTful) обеспечивают связь и взаимодействие между AAS и c приложениями.
Как правило, современная промышленная продукция имеет сложную структуру. В этом случае для продукта в целом и для его отдельных частей создаются отдельные i4.0-компоненты (AAS), которые между собой связываются отношениями, реализуемыми с помощью сервисных интерфейсов (рис. 3). В качестве акторов запуска функциональных приложений и соответствующих i4.0-компонентов могут выступать как внешние субподрядчики, так и внутренние исполнители.
Эти i4.0-компоненты обмениваются между собой информацией с помощью трех режимов взаимодействия:
4- пассивный режим — обмен файлами; ♦ реактивный режим — с помощью организации
обмена данными и вызова сервисов через API; 4- проактивный режим (pear-to-pear), когда цифровые двойники в автоматическом режиме совместно выполняют некоторые производственные процессы.
Рис. 3. Пример многоуровневой системы AAS (на основе [21])
Поскольку в статье речь идет только о начальных этапах создания продукции и услуг, связанные с формированием концепции и проектированием цепочки создания ценности, то в качестве режимов взаимодействия рассматриваются либо пассивный, либо реактивный режим взаимодействия, предполагающий активное участие людей в процессе проектирования. С точки зрения многоагентной реализации процесса взаимодействия i4.0-компонентов, принадлежащих внешним участникам цепочки создания ценности, реактивный режим взаимодействия соответствует различным режимам рассылки сообщений и подписки на информацию, а также сервисного взаимодействия (см. раздел «Предметно-ориентированный подход к структурированию предметной области проектирования инновационных процессов»).
3. Технология проектирования инновационных процессов создания продуктов с использованием онтологического и когнитивного подходов в i4.0-системе
Схема взаимодействия участников сетевого предприятия в i4.0-системе, реализующей функции системы, основанной на знаниях, по поддержке инновационных процессов создания продукции, представлена на рисунке 4. На основе референсной модели онтологии предметной области формируются онтологии проектов как для проекта в целом, так и для его составных частей. Как было отмечено в первом разделе, онтологии формируются итерационно и используются для решения поисковых задач в базах знаний и обмена знаниями между отдельными оболочками администрирования ресурсов. Стандартизированные сервисы методов QFD [23], FMEA [24], обработки нечетких множеств [25] используются в функциональных модулях AAS, реализуя когнитивные механизмы принятия решений. Рассмотрим технологию проектирования инновационных процессов создания продуктов в i4.0-системе более детально.
Ядром AAS является модуль планирования, реализующий интерфейсные сервисы для взаимодействия с участниками инновационного процесса создания продукции и обеспечивающий координацию функциональных сервисов. В частности, модуль поддерживает процесс принятия решений по выбору варианта конструкции продукта и цепочки создания ценности на основе сочетания ме-
%
AAS Продукция
Пользовательские Клиенты ожидания и предпочтения, ценностные характеристики
Л Сервисы
■•л?
Цепочка создания ценности
Головная _ организация
о ш о " ^ Q.^ со
Ограничения, требования, риски, факторы успеха
Платформа
u и
А Серв
исы
AAS Узел N
AAS Узел 1
Спецификация
Л Сервисы
^ ^ ш й
Референсные онтологии
Онтология Проекта
Ограничения, требования, риски, факторы успеха
ь
Подрядные организации (поставщики)
Рис. 4. Схема взаимодействия участников сетевого предприятия в 14.0-системе
тодов QFD и нечеткой логики. В рамках метода QFD при описании каждой качественной характеристики (бизнес-требования) экспертным путем устанавливается приоритет (вес), где самая важная характеристика с наибольшим потребительским интересом имеет максимальный вес. Дальнейшая процедура предусматривает сбор требований и оценку их влияния на ценностные характеристики, выбор наиболее важных требований. Последующая оценка конструктивных элементов с точки зрения их влияния на реализацию требований связана с выбором варианта конструкции продукции, в большей степени отвечающей выбранным требованиям, а оценка рисков, связанных с поставщиками и/или подрядчиками, учитывает сформированные варианты конструкции. В результате осуществляется выбор оптимальной цепочки процесса создания ценности, в которой для всех участников определены требования и связанные риски, организован доступ к данным моделей AAS (распределенному репозиторию). Подробное описание методики использования метода QFD представлено в статье [26].
Формирование проектов продуктов инициируется в AAS и проходит ряд итераций [1, 26], в рамках которых осуществляются вызовы сервисов, реализуемых модулями AAS.
Ценность продукта для потребителя определяется через ценностные (качественные) характеристики (или бизнес-требования), которые описываются в онтологии проекта с помощью сервисов модуля
формирования качественных характеристик, а также набор функциональных и нефункциональных требований, критериальную базу оценки реализации требований, которые описываются с помощью сервисов модуля формирования требований.
Интегрированное выражение когнитивного понимания рыночной ситуации по рассматриваемому виду продукции находит свое представление в методологии SWOT анализа, который в обобщенной форме выявляет достоинства и недостатки производства рассматриваемого вида продукции, а также возможности и угрозы рыночной реализации проекта [27].
Процесс формирования качественных характеристик продукта является слабоформализуемой задачей анализа внешних и внутренних факторов соответствующего рынка продукции и услуг. В этом процессе принимают участие специалисты различных профилей: маркетологи, исследователи новых технологий и материалов, конструкторы и технологи аналогичных видов продукции. В решении задачи отбора важнейших свойств проектируемого продукта могут использоваться методы анализа больших данных о рынках продукции, технологий и материалов, предиктивного прогнозирования тенденций развития, анализа ресурсных ограничений и рисков освоения новых видов продукции и технологий.
Классификация продуктов, типовые (обязательные и опциональные) ценностные характеристики, параметры продукта и некоторые логические пра-
вила, представленные в референсной онтологии, используются при описании инновационного продукта (нового класса продукции) в онтологии проекта, наследующего ряд ценностных характеристик той категории, к которой он принадлежит, и/или имеющего некоторые уникальные, несвойственные для данной категории продуктов, характеристики.
С помощью существующих сервисов дополнительно оцениваются и классифицируются в онтологии проекта ожидаемые и привлекающие характеристики (согласно Кано [28]), а также минимизируется наличие не влияющих, противоречивых и отвращающих характеристик. При этом наибольший приоритет (вес) согласно QFD будут иметь именно обязательные (ожидаемые) и привлекающие характеристики, а противоречивые или отвращающие характеристики — наименьший. В ходе дальнейшей работы над проектом из набора может быть исключена часть опциональных характеристик, реализация которых приводит к значительным издержкам проекта, а также отвращающие и противоречивые характеристики, снижающие ценность продукта для потребителя.
Сведения о качественных (ценностных) характеристиках продукта могут уточняться в ходе проекта и используются в модуле формирования требований, где для каждой из выявленных качественных (ценностных) характеристик определяется как минимум одно требование, реализация которого обеспечивает соответствующую характеристику. Функциональные требования должны быть распределены по подсистемам (поддоменам предметной области).
В онтологию проекта из референсной онтологии переносятся типовые требования, свойственные определенным категориям продукта и задаваемые стандартами (например, ТУ и ГОСТами), и вносятся производные от этих требований (или независимые от них) оригинальные требования и ограничения проекта.
Для выявления обязательных требований оценивается степень связанности каждого требования с реализацией качественной характеристики. В результате использования функции фазификации коэффициента уверенности для оценки такой связи приводится к шкале [0, 1]. Суммарная важность для реализации всего набора качественных характеристик рассчитывается для каждого требования по формуле [29]:
^ = (D
/
где Т — нечеткая оценка важности j-го требования для реализации качественных характеристик (бизнес-требований) инновационного продукта;
С^ — уровень связанности j-го требования и f-й характеристики по шкале [0, 1, 3, 9];
Pf — заданный приоритет f-й характеристики по шкале [1, N];
(р{ — функция фазификации по шкале [0, 1]: чем больше важность j-го требования для реализации f-й характеристики, тем ближе значение функции к 1;
^ — операция аддитивного суммирования нечетких чисел.
Для определения итогового множества групп обязательных и необязательных требований, которые должны обеспечивать наличие всех обязательных и ожидаемых характеристик, используются заданные пороговые значения оценки Т. Ожидаемые и необязательные требования, имеющие оценки ниже пороговых, не учитываются в дальнейшем.
Детализация требований проводится до уровня конкретных функций и конструктивных элементов. Они описываются в онтологии проекта в рамках модуля проектирования конструкции.
Условием для включения конструктивного элемента в вариант конструкции продукта (bill of materials, BOM) является обеспечение возможности выполнения некоторых функций продукта или реализация обязательных интерфейсных требований. Также может происходить наследование структуры (product breakdown structure, PBS) из онтологии продукта. Таким образом, каждый конструктивный элемент и функция продукта прямо или косвенно связаны с одним или несколькими требованиями, которые в совокупности определяют вариант конструкции продукта.
Ранжировать (сравнивать) различные варианты конструкций продукта можно обращаясь к сервисам метода QFD для оценки влияния конструктивных элементов на обеспечение соответствующих требований. При этом полученные по указанной выше формуле оценки важности требований учитываются при расчете оценок для отдельных конструктивных элементов.
Спецификация BOM — задача слабоформализу-емая, итерационная и имеющая инновационный характер. В ходе выполнения этой задачи BOM определяется таким образом, чтобы обеспечить, с
одной стороны, полное соответствие существующим требованиям (в варианте конструкции всегда должен быть предусмотрен хотя бы один элемент для каждого обязательного требования) и, с другой стороны, соответствующий уровень издержек. Для отбора необязательных конструктивных элементов и/или элементов, с которыми связаны высокие издержки, может задаваться и использоваться некоторое пороговое значение.
Определяющим фактором является возможность приобретения выбранных типов конструктивных элементов и/или их производства. Для оценки такой возможности сформированный вариант конструкции передается модулю планировщику, который в свою очередь вызывает сервисы, реализуемые модулем проектирования цепочки создания ценности. С помощью указанных сервисов в том числе проводится анализ рынка, выбор варианта инновационного процесса и подбор его участников.
Отсутствие входящих в проект продукта конструктивных элементов у поставщиков, связанных с обязательными требованиями, может привести к одному из следующих организационных сценариев, инициируемых модулем планирования: 4- поиск подрядчиков, которые могли бы обеспечить производство отсутствующего конструктивного элемента на заказ с применением заданных технологий, инструментов и проектных ограничений; 4 выбор согласно рангу другого варианта конструкции продукта, не содержащего отсутствующие элементы; 4 пересмотр концепции продукта с целью уточнения характеристик и требований для исключения отсутствующего элемента конструкции; 4 завершение работ, обусловленное отсутствием возможности пересмотра концепции продукта.
Для того, чтобы выявить предприятия, способные произвести на заказ отсутствующие конструктивные элементы, необходимо сформировать вариант цепочки создания ценности, включающий работы по производству, проектированию, сборке, обработке, наладке, обслуживанию и поставке продукции. Состав и связи таких работ содержатся в онтологии проекта, где также могут быть определены возможные инструменты и технологии, а также соответствие заданным проектным ограничениям и установленным требованиям.
Оценка суммарного влияния всех работ в цепочке процесса на обеспечение качественных харак-
теристик и удовлетворение требований позволяет отобрать участников процесса с учетом их компетенций (способности выполнять некоторые виды работ, владение инструментами и технологиями).
Формула расчета отклонений требований от возможностей предприятия, основанная на суммировании нечетких чисел, представлена ниже; при этом определяется возможность выполнения некоторых видов работ собственными силами или их передача на аутсорсинг [29]:
(2)
где — нечеткая оценка конкурентоспособности и-го компонента продукции на рынке, поставляемого (производимого) г'-м исполнителем;
Т.у. — заданный уровень у'-го требования для реализации и-го компонента г'-м исполнителем;
В..у. — уровень реализации у'-го требования для и-го компонента г'-м исполнителем;
6?. — функция фазификации по шкале (0, 1): чем меньше отклонение, тем выше конкурентоспособность.
^ — операция аддитивного суммирования нечетких чисел.
Уровень реализации у'-го требования для и-го компонента г'-м исполнителем определяется в процессе согласования требования с исполнителем путем интерпретации получаемых данных от исполнителя (по натуральной или нечеткой шкале [0, 1]).
Соответственно, выбор исполнителя (поставщика или производителя) осуществляется по максимальной оценке конкурентоспособности поставляемого (производимого) и-го компонента на рынке:
V' =тахК,К„,
(3)
где V* — максимальная оценка конкурентоспособности и-го поставляемого (производимого) компонента;
— нечеткая оценка конкурентоспособности и-го компонента продукции, поставляемого (производимого) г-м исполнителем;
Кш — коэффициент риска, связанный с реализацией и-го компонента г'-м исполнителем.
Коэффициент риска рассчитывается как мультипликативное произведение нечетких чисел, соответствующих отдельным видам рисков, которые определяются по нечеткой шкале [0, 1]:
- П кьл,
(4)
где Кш — коэффициент риска, связанный с реализацией и-го компонента г-м исполнителем;
Кшк — коэффициент риска к-го вида, связанный с реализацией и-го компонента г'-м исполнителем;
п
операция произведения нечетких чисел.
В ходе поиска подрядчиков используются платформенные сервисы обеспечения взаимодействия AAS, посредством которых осуществляется рассылка в адрес производителей запросов-требований. В частности, направляется спецификация набора конструктивных элементов, в которых заинтересована инициирующая разработку продукта организация, описание соответствующих инструментов и технологий, требования к конструктивному элементу и проектные ограничения. Посредством существующего или созданного AAS производитель обращается к сведениям, представленным в базах данных предприятий, и расчетным моделям для оценки возможностей производства. Для этого вызываются аналогичные сервисы, реализуемые модулями формирования качественных характеристик, формирования требований, проектирования конструкции на уровне конструктивного элемента, а не продукта в целом.
Если предприятие не соответствует заданным условиям полностью, то посредством платформенных сервисов направляется соответствующий ответ, в противном случае направляются результаты расчетных моделей и характеристики конструктивного элемента, который может быть разработан. Отсутствие положительных ответов на рассылку со стороны производителей является основанием для перехода к другим вариантам процесса согласно ранее определенному рангу.
Выбранный вариант процесса с перечнем работ и ответственных, детальным описанием продукта и конструктивных элементов сохраняются платформенными сервисами в подмодели проектных документируемых данных AAS и используются на стадии производства для координации работ (прямого общения между сервисами участников процесса), а также в ходе эксплуатации изделий и при разработке новых видов продукции.
Заключение
В результате проведенного исследования технологии проектирования инновационных процессов создания продукции сетевого предприятия с ис-
пользованием i4.0-системы, основанной на знаниях, можно сделать следующие выводы.
Декомпозицию предметной области для проектирования инновационных процессов создания продукции и услуг целесообразно осуществлять на основе применения предметно-ориентированного подхода, который обеспечивает, с одной стороны, объективное отражение структуры продукции и услуг и цепочек создания ценностей, а с другой стороны, формирование проектных коллективов, способных эффективно взаимодействовать в рамках поставленных задач.
Система, основанная на знаниях, для проектирования инновационных процессов создания продукции и услуг, может быть реализована на платформе индустрии 4.0 (платформа i4.0), которая обеспечивает многоагентную реализацию процесса проектирования в распределенной сетевой архитектуре с использованием технологии цифровых двойников и нитей.
Предметно-ориентированное проектирование позволяет выделять ограниченные контексты создания продукции и услуг по стадиям жизненного цикла, а для этапа проектирования — последовательность работ по формированию концепции, функциональных и нефункциональных требований, проектированию конструкции изделия и цепочки создания ценности. Соответственно, структура i4.0-системы, основанной на предметно-ориентированной декомпозиции, будет включать наборы взаимодействующих оболочек администрирования ресурсов, реализующих ограниченные контексты проектирования.
Особенностью предлагаемой технологии проектирования инновационных процессов создания продукции и услуг является ее итерационный характер, в ходе исполнения которой для цифровых двойников продуктов и их составных частей динамически создаются оболочки администрирования ресурсов, формирующие и оценивающие версии цепочек создания ценностей на предмет наилучшего выполнения функциональных и нефункциональных требований.
Применение стандартизированных онтологических сервисов i4.0-платформы обеспечивает динамическое создание онтологий из референсных моделей и их актуализацию по мере развития инновационного проекта создания продукции и услуг.
Стандартизированные методы i4.0-платформы в части обмена информацией между AAS позволяют выполнять различные режимы активного взаимо-
действия участников инновационного процесса, направленные на получение обоснованных и согласованных проектных решений.
Функциональные модули оболочек администрирования ресурсов базируются на применении стандартизированных сервисов, реализующих когнитивные методы: развертывания функции качества для определения приоритетов реализации бизнес-и функциональных требований, анализа видов и последствий потенциальных несоответствий для оценки рисков, метода обработки нечетких множеств для получения многокритериальных оценок целесообразности принятия тех или иных проектных решений. Применение перечисленных методов позволяет осуществлять многокритериальную оптимизацию инновационного процесса проектирования.
Характеризуя предлагаемую технологию проектирования инновационных процессов создания продукции и услуг в целом, следует отметить ее новизну в части предложенных методов реализации многоагентного взаимодействия участников инновационного процесса в рамках динамического построения i4.0-системы и использования онтологических и когнитивных методов формирования проектных решений. В перспективе предполагается продолжить исследования применения разработанных методов и механизмов i4.0-систем для реализации последующих этапов жизненного цикла создания продукции и услуг. ■
Благодарности
Работа выполнена при поддержке РФФИ, грант № 19-07-01137а.
Литература
1. Тельнов Ю.Ф., Казаков В.А., Трембач В.М. Разработка системы, основанной на знаниях, для проектирования инновационных процессов создания продукции сетевых предприятий // Бизнес-информатика. 2020. Т. 14. № 3. С. 35—53. DOI: 10.17323/2587-814X.2020.3.35.53.
2. Bajaj M., Hedberg T. System lifecycle handler - Spinning a digital thread for manufacturing // 28th Annual INCOSE International Symposium. Washington, DC, 7-12 July 2018. Vol. 28. P. 1636-1650. DOI: 10.1002/j.2334-5837.2018.00573.x.
3. Digital thread for smart manufacturing // NIST. Created April 25, 2014, Updated December 11, 2020. [Электронный ресурс]: https://www.nist.gov/programs-projects/digital-thread-smart-manufacturing (дата обращения 26.07.2021).
4. Grieves M. Origins of the digital twin concept. 2016. [Электронный ресурс]: https://www.researchgate.net/publication/307509727_ Origins_of_the_Digital_Twin_Concept (дата обращения 26.07.2021). DOI: 10.13140/RG.2.2.26367.61609.
5. Минаев В.А., Мазин А.В., Здирук К.Б., Куликов Л.С. Цифровые двойники объектов в решении задач управления // Радиопромышленность. 2019. Т. 29. № 3. С. 68-78. DOI: 10.21778/2413-9599-2019-29-3-68-78.
6. Цифровые двойники в высокотехнологичной промышленности. Экспертно-аналитический доклад // Инфраструктурный центр «Технет» НТИ. Москва, 2019. [Электронный ресурс]: http://assets.fea.ru/uploads/fea/news/2019/12_december/28/ cifrovoy_dvoinik.pdf (дата обращения 26.07.2021).
7. Wooldridge M. An introduction to multi-agent systems. New York: Wiley, 2009.
8. Городецкий В.И., Грушинский М.С., Хабалов А.В. Многоагентные системы (обзор) // Новости искусственного интеллекта. 1998. № 2. С. 64-116.
9. Разработка прототипа многоагентной системы сетевого взаимодействия учебных заведений / Ю.Ф. Тельнов и [др.] // Открытое образование. 2018. Т. 22. № 6. С. 14-26. DOI: 10.21686/1818-4243-2018-6-14-26.
10. Uschold M., King M., Moralee S., Zorgios Y. The enterprise ontology // Knowledge Engineer Review. 1998. Vol. 13. No 1. P. 31-89. DOI: 10.1017/S0269888998001088.
11. Гаврилова Т.А., Кудрявцев Д.В., Муромцев Д.И. Инженерия знаний. Модели и методы. Санкт-Петербург: Лань, 2016.
12. Ефименко И.В., Хорошевский В.Ф. Онтологическое моделирование экономики предприятий и отраслей современной России: Часть 1. Онтологическое моделирование: подходы, модели, методы, средства, решенияЖР7/2011/08 (ч. 1). М.: ВШЭ, 2011.
13. Evans E. Domain-driven design: Tackling complexity in the heart of software. Boston: Addison-Wesley, 2003.
14. Vernon V. Domain driven design distilled. Boston: Addison-Wesley, 2016.
15. Architecture alignment and interoperability // Industrial Internet Consortium and Plattform Industrie 4.0 Joint Whitepaper, 2017. [Электронный ресурс]: https://www.iiconsortium.org/pdf/JTG2_Whitepaper_final_20171205.pdf (дата обращения 26.07.2021).
16. Details of the asset administration shell from idea to implementation // Plattform Industrie 4.0. 2019. [Электронный ресурс]:
https://www.plattform-i40.de/IP/Redaktion/EN/Downloads/Publikation/vws-in-detail-presentation.pdf?_
blob=publicationFile&v=12 (дата обращения 26.07.2021).
17. Digital twin and asset administration shell concepts and application in the industrial internet and Industrie 4.0 // Industrial Internet Consortium and Plattform Industrie 4.0 Joint Whitepaper, 2020. [Электронный ресурс]: https://www.iiconsortium.org/pdf/Digital-Twin-and-Asset-Administration-Shell-Concepts-and-Application-Joint-Whitepaper.pdf (дата обращения 26.07.2021).
18. Кузнецов О.П. Когнитивная семантика и искусственный интеллект // Искусственный интеллект и принятие решений. 2012. № 4. C. 95-105.
19. Трембач В.М. Когнитивный подход к созданию интеллектуальных модулей организационно-технических систем // Открытое образование. 2017. Т. 21. № 2. С. 78-87. DOI: 10.21686/1818-4243-2017-2-78-87.
20. Details of the asset administration shell. Part 1 - The exchange of information between partners in the value chain of Industrie 4.0 (Version 3.0RC01) // Plattform Industrie 4.0, 2020. [Электронный ресурс]: https://www.plattform-i40.de/IP/Redaktion/EN/
Downloads/Publikation/Details_of_the_Asset_Administration_Shell_Part1_V3.pdf?__blob=publicationFile&v=5 (дата обращения
26.07.2021).
21. Usage view of asset administration shell. Discussion paper // Plattform Industrie 4.0, 2019. [Электронный ресурс]:
https://www.plattform-i40.de/IP/Redaktion/DE/Downloads/Publikation/2019-usage-view-asset-administration-shell.pdf?_
blob=publicationFile&v=4 (дата обращения 26.07.2021).
22. Functional view of the asset administration shell in an Industrie 4.0 system environment. Discussion paper // Plattform Industrie 4.0, 2019. [Электронный ресурс]: https://www.plattform-i40.de/IP/Redaktion/DE/Downloads/Publikation/Functional- View. pdf?_blob=publicationFile&v=5 (дата обращения 26.07.2021).
23. Вашуков Ю.А., Дмитриев А.Я., Митрошкина Т.А. QFD: Разработка продукции и технологических процессов на основе требований и ожиданий потребителей: методические указания. Самара: Самар. гос. аэрокосм. ун-т, 2012.
24. Вашуков Ю.А., Дмитриев А.Я., Митрошкина Т.А. Анализ видов, последствий и причин потенциальных несоответствий (FMEA): методические указания. Самара: Самар. гос. аэрокосм. ун-т, 2008.
25. Аверкин А.Н. Нечеткие множества в моделях управления и искусственного интеллекта. М.: Книга по требованию, 2013.
26. Построение структуры сетевого предприятия для создания инновационных продуктов / Ю.Ф. Тельнов и [др.] // Открытое образование. 2019. Т. 23. № 6. С. 59-73. DOI: 10.21686/1818-4243-2019-6-59-73.
27. Thompson A.A. Jr., Strickland III A.J. Strategic management: Concepts and cases. Boston, Mass.: McGraw-Hill/Irvin, 2003.
28. Kano N., Seraku N., Takahashi F., Tsuji S. Attractive quality and must-be quality // Journal of the Japanese Society for Quality Control. 1984. Vol. 14. No 2. P. 147-156. DOI: 10.20684/quality.14.2_147.
29. Калачихин П.А., Тельнов Ю.Ф. Формирование цепочек создания ценностей в сетевых структурах взаимодействия на основе интеллектуальных технологий // XVI Национальная научная конференция по искусственному интеллекту с международным участием (КИИ-2018). Москва, 24-27 сентября 2018 г. В 2-х томах. Т. 1. С. 106-115.
Об авторах
Тельнов Юрий Филиппович
доктор экономических наук, профессор;
заведующий кафедрой прикладной информатики и информационной безопасности, Российский экономический университет им. Г.В. Плеханова, 117997, г. Москва, Стремянный пер., д. 36; E-mail: Telnov.YUF@rea.ru ORCID: 0000-0002-2983-8232
Казаков Василий Александрович
кандидат экономических наук;
ведущий научный сотрудник НИИ «Стратегические информационные технологии», Российский экономический университет им. Г.В. Плеханова, 117997, г. Москва, Стремянный пер., д. 36; E-mail: Kazakov.VA@rea.ru ORCID: 0000-0001-8939-2087
Данилов Андрей Владимирович
старший преподаватель кафедры прикладной информатики и информационной безопасности, Российский экономический университет им. Г.В. Плеханова, 117997, г. Москва, Стремянный пер., д. 36; E-mail: Danilov.AV@rea.ru ORCID: 0000-0002-0433-9701
Technology for designing innovative processes
for creating products and services of a network enterprise
using an ¡4.0 knowledge-based system
Yury F. Telnov
E-mail: Telnov.YUF@rea.ru
Vasily A. Kazakov
E-mail: Kazakov.VA@rea.ru
Andrey V. Danilov
E-mail: Danilov.AV@rea.ru
Plekhanov Russian University of Economics Address: 36, Stremyanny Lane, Moscow 117997, Russia
Abstract
The creation of network enterprises based on the digital technologies of the Industrie 4.0 (the 4th Industrial Revolution, i4.0) opens broad opportunities for increasing production flexibility, customer focus and continuous innovation in products and services provided. At the same time, new opportunities necessitate the development of new methods and technologies for designing innovative processes in the context of digital i4.0 platforms, all of which highlights the relevance of the presented research topic. This work aims to define technologies for designing innovative processes to create products and services using i4.0 systems which are based on multi-agent interaction of asset administration shells (AAS), displaying digital twins of product components, and the use of ontological and cognitive methods for forming and justifying design decisions. The work presented here uses the Domain-Driven Design approach, an architectural framework for building i4.0 systems, methods of ontological engineering, quality function deployment (QFD), analysis of the types and consequences of potential inconsistencies (FMEA) and processing of fuzzy sets. The paper proposes principles for identifying bounded contexts of the domain under the design activities for the stages of the life cycle and products' subsystems (components). For bounded contexts of the domain, it is envisaged to create AAS of i4.0 systems, with the help of which the innovative process is supported and the multi-agent interaction of its participants is carried out. As cognitive tools for making design decisions, we proposed to use services for assessing the importance of the determined quality characteristics of products and minimizing deviations of the proposed solutions from the formed functional and non-functional requirements. The methods of ontological engineering and data modelling allow us to dynamically develop an innovative project and support various versions of the project in the design process. Application of the proposed technology for designing innovative processes to create products and services at network enterprises using i4.0 systems will improve the quality of design decisions, increase the dynamism and continuous design of innovative projects.
Key words: innovative process; digital twin; domain-driven design; bounded context; value-added chain; ontology; multiagent interaction; i4.0 system; i4.0 platform; asset administration shell (AAS).
Citation: Telnov Yu.F., Kazakov V.A., Danilov A.V. (2021) Technology for designing innovative processes for creating products and services of a network enterprise using an i4.0 knowledge-based system. Business Informatics, vol. 15, no 4, pp. 76—92. DOI: 10.17323/2587-814X.2021.4.76.92
References
1. Telnov Yu.F, Kazakov V.A., Trembach V.M. (2020) Developing a knowledge-based system for the design of innovative product creation processes for network enterprises. Business Informatics, vol. 14, no 3, pp. 35-53. DOI: 10.17323/2587-814X.2020.3.35.53.
2. Bajaj M., Hedberg T. (2018) System lifecycle handler — Spinning a digital thread for manufacturing. Proceedings of the 28th AnnualINCOSE International Symposium. Washington, DC, 7-12 July 2018, vol. 28, pp. 1636—1650. DOI: 10.1002/j.2334-5837.2018.00573.x.
3. NIST (2020) Digital thread for smart manufacturing. Available at: https://www.nist.gov/programs-projects/digital-thread-smart-manufacturing (accessed 26 July 2021).
4. Grieves M. (2016) Origins of the digital twin concept. Available at: https://www.researchgate.net/publication/307509727_0rigins_of_the_Digital_ Twin_Concept (accessed 26 July 2021). DOI: 10.13140/RG.2.2.26367.61609.
5. Minaev V.A., Mazin A.Y, Zdiruk K.B., Kulikov L.S. (2019) Digital twins of objects in the solution of control problems. Radioindustry, vol. 29, no 3, pp. 68—78 (in Russian). DOI: 10.21778/2413-9599-2019-29-3-68-78.
6. NTI (2019) Digital twins in the high-tech industry. Expert and analytical report. Available at: http://assets.fea.ru/uploads/fea/news/2019/12_december/28/ cifrovoy_dvoinik.pdf (accessed 26 July 2021).
7. Wooldridge M. (2009) An introduction to multi-agent systems. New York: Wiley, 2009.
8. Gorodetskiy V.I., Grushinskiy M.S., Khabalov A.V (1998) Multi-agent systems (review). Artificial Intelligence News, no 2, pp. 64—116 (in Russian).
9. Telnov Yu.F, Danilov A.V., Diveev R.I., Kazakov V.A., Yaroshenko E.V. (2018) Development of a prototype ofmulti-agent system ofnetwork interaction of educational institutions. Open Education, vol. 22, no 6, pp. 14—26 (in Russian). DOI: 10.21686/1818-4243-2018-6-14-26.
10. Uschold M., King M., Moralee S., Zorgios Y. (1998) The enterprise ontology. Knowledge Engineer Review, vol. 13, no 1, pp. 31—89. DOI: 10.1017/S0269888998001088.
11. Gavrilova T.A., Kudryavtsev D.V., Muromtsev D.I. (2016) Knowledge engineering. Models and methods. Saint Petersburg: Lan' (in Russian).
12. Efimenko I.V., Khoroshevsky V.F. (2011) Ontological modeling of enterprises and markets of modern Russia. Part 1. Ontological modeling: Approaches, models, methods, tools, solutions. Working paper WP7/2011/08 (part 1). Moscow: HSE Publishing House (in Russian).
13. Evans E. (2003) Domain-driven design: Tackling complexity in the heart of software. Boston: Addison-Wesley.
14. Vernon V (2016) Domain driven design distilled. Boston: Addison-Wesley.
15. Industrial Internet Consortium, Plattform Industrie 4.0 (2017) Architecture alignment and interoperability. Joint Whitepaper. Available at: https://www.iiconsortium.org/pdf/JTG2_Whitepaper_final_20171205.pdf (accessed 26 July 2021).
16. Plattform Industrie 4.0. (2019) Details of the asset administration shell from idea to implementation. Available at: https://www.plattform-i40.de/IP/ Redaktion/EN/Downloads/Publikation/vws-in-detail-presentation.pdf? blob=publicationFile&v=12 (accessed 26 July 2021).
17. Industrial Internet Consortium, Plattform Industrie 4.0 (2020) Digital twin and asset administration shell concepts and application in the industrial internet and Industrie 4.0. Joint Whitepaper. Available at: https://www.iiconsortium.org/pdf/Digital-Twin-and-Asset-Administration-Shell-Concepts-and-Application-Joint-Whitepaper.pdf (accessed 26 July 2021).
18. Kuznetsov O.P (2012) Cognitive semantics and artificial intelligence. Artificial Intelligence and Decision Making, no 4, pp. 95—105 (in Russian).
19. Trembach V.M. (2017) Cognitive approach to developing the intelligent modules of organizational and technical systems. Open Education, vol. 21, no 2, pp. 78—87 (in Russian). DOI: 10.21686/1818-4243-2017-2-78-87.
20. The Plattform Industrie 4.0 (2020) Details of the asset administration shell. Part 1 — The exchange of information between partners in the value chain ofIndustrie 4.0(Version 3.0RC01). Available at: https://www.plattform-i40.de/IP/Redaktion/EN/Downloads/Publikation/Details_of_the_Asset_ Administration_Shell_Part1_V3.pdf?_blob=publicationFile&v=5 (accessed 26 July 2021).
21. Plattform Industrie 4.0 (2019) Usage view of asset administration shell. Discussion paper. Available at: https://www.plattform-i40.de/IP/Redaktion/ DE/Downloads/Publikation/2019-usage-view-asset-administration-shell.pdf?_blob=publicationFile&v=4 (accessed 26 July 2021).
22. Plattform Industrie 4.0 (2019) Functional view of the asset administration shell in an Industrie 4.0 system environment. Discussion paper.
Available at: https://www.plattform-i40.de/IP/Redaktion/DE/Downloads/Publikation/Functional- View.pdf?_blob=publicationFile&v=5
(accessed 26 July 2021).
23. Vashukov Yu.A., Dmitriyev A.Ya., Mitroshkina T.A. (2012) QFD: Product andprocess development based on customer requirements and expectations: A methodological guide. Samara: SSAU (in Russian).
24. Vashukov Yu.A., Dmitriyev A.Ya., Mitroshkina T.A. (2008) Type, consequence and cause analysis of potential nonconformities (FMEA): A methodological guide. Samara: SSAU (in Russian).
25. Averkin A.N. (2013) Fuzzy sets in management and artificial intelligence models. Moscow: Kniga po Trebovaniyu (in Russian).
26. Telnov Yu.F, Trembach V.M., Danilov A.V., Yaroshenko E.V, Kazakov V.A., Kozlova O.A. (2019) Constructing network enterprise structure to create innovative products. Open Education, vol. 23, no 6, pp. 59—73 (in Russian). DOI: 10.21686/1818-4243-2019-6-59-73.
27. Thompson A.A. Jr., Strickland III A.J. (2003) Strategic management: Concepts and cases. Boston, Mass.: McGraw-Hill/Irvin.
28. Kano N., Seraku N., Takahashi F., Tsuji S. (1984) Attractive quality and must-be quality. Journal of the Japanese Society for Quality Control, vol. 14, no 2, pp. 147—156. DOI: 10.20684/quality.14.2_147.
29. Kalachikhin P.A., Telnov Yu.F (2018) Value-added chains formation in network structures of interaction based on intelligent technologies. Proceedings of the XVI National Scientific Conference on Artificial Intelligence with International Participation (KII—2018), Moscow, 24—27September 2018, vol. 1, pp. 106—115 (in Russian).
About the authors
Yury F. Telnov
Dr. Sci. (Econ.), Professor;
Head of the Department ofApplied Information Technologies and Information Security, Plekhanov Russian University of Economics, 36, Stremyanny Lane, Moscow 117997, Russia; E-mail: Telnov.YUF@rea.ru ORCID: 0000-0002-2983-8232
Vasily A. Kazakov
Cand. Sci. (Econ.);
Leading Researcher, Research Institute "Strategic Information Technologies", Plekhanov Russian University of Economics, 36, Stremyanny Lane, Moscow 117997, Russia; E-mail: Kazakov.VA@rea.ru ORCID: 0000-0001-8939-2087
Andrey V. Danilov
Senior Lecturer, Department of Applied Information Technologies and Information Security, Plekhanov Russian University of Economics, 36, Stremyanny Lane, Moscow 117997, Russia; E-mail: Danilov.AV@rea.ru ORCID: 0000-0002-0433-9701
