Модели поддержки принятия решений в социокиберфизических системах Текст научной статьи по специальности «Компьютерные и информационные науки»

\ МОДЕЛИРОВАНИЕ СИСТЕМ И ПРОЦЕССОВ

удк 004.822: 004.896:007.51 Научные статьи

doi:10.31799/1684-8853-2019-3-55-70 Articles

Модели поддержки принятия решений в социокиберфизических системах

А. В. Смирнов*, доктор техн. наук, профессор, orcid.org/0000-0001-8364-073X, smir@iias.spb.su Т. В. Левашоваа, канд. техн. наук, старший научный сотрудник, orcid.org/0000-0002-1962-7044, tatiana.levashova@iias.spb.su

аСанкт-Петербургский институт информатики и автоматизации РАН, 14-я линия В. О., 39, Санкт-Петербург, 199178, РФ

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

Ключевые слова — социокиберфизическая система, поддержка принятия решений, онтология, планирование процесса выполнения задачи.

Для цитирования: Смирнов А. В., Левашова Т. В. Модели поддержки принятия решений в социокиберфизических системах. Информационно-управляющие системы, 2019, № 3, с. 55-70. doi:10.31799/1684-8853-2019-3-55-70

For citation: Smirnov A. V., Levashova T. V. Models of decision support in socio-cyber-physical systems. Informatsionno-upravliaiushchie sistemy [Information and Control Systems], 2019, no. 3, pp. 55-70 (In Russian). doi:10.31799/1684-8853-2019-3-55-70

Введение

Социокиберфизические системы (СКФС) появились как результат интенсивного взаимодействия киберфизических систем (КФС) с социальной сферой и средой функционирования КФС. Среда функционирования КФС — это система или структура, в которой данная КФС используется (например, организация, производственная система, автомобиль и т. п.).

Решения в КФС принимаются компонентами этих систем. Компоненты КФС делятся на физические и кибернетические. Физические компоненты являются «носителями» кибернетических, так как кибернетическим компонентам требуется физическая (аппаратная) платформа для запуска программ и для обмена информацией с другими кибернетическими компонентами и со средой функционирования КФС [1]. Примерами физических компонентов являются бортовой компьютер в автомобиле, беспилотное воздушное транспортное средство, различные интеллектуальные сенсоры и т. п. Примером кибернетических компонентов является программное

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

Компоненты КФС могут принимать решения в целях удовлетворения текущих потребностей человека, или КФС может выполнять роль системы поддержки принятия решений. Например, в производственном сценарии [2] автоматическое принятие решений внедрено в производственный процесс, где роботы самостоятельно принимают решения о том, какие действия они должны выполнять в текущей ситуации. Этот сценарий целиком направлен на удовлетворение потребностей человека, и человеку отводится роль потребителя произведенного продукта. Другим примером являются архитектуры КФС, которые предназначены для помощи человеку в принятии решений [3, 4]. Архитектура, основанная на имитационном мета-моделировании [3], оказывает поддержку в принятии решений по планированию и оперативному управлению. Поддержка осуществляется посредством 1) предоставления дополнительных

знаний о производительности рассматриваемого объекта в текущих условиях, 2) предоставления информации о производстве для оценки различных сценариев ради их возможного расширения или уточнения целей, 3) быстрого выбора оптимального множества переменных решения из большого диапазона возможных решений. КФС, построенная на архитектуре для обоснованного принятия решений в конструировании [4], собирает информацию от кибернетических моделей и физических активов, относящуюся к конструкторскому проекту, интегрирует ее и синтезирует контекстную информацию. Контекстная информация является основой для принятия решений человеком.

Решения в КФС принимаются на локальном и системном уровнях. На локальном уровне компоненты КФС могут принимать ситуационные решения и стремиться к автоматическому решению задач посредством сбора дескриптивной информации и применения контекстно-зависимого казуального и процедурного логического вывода. На системном уровне принятие решений в КФС распределено между большим числом компонентов и основано на рефлексивном взаимодействии между компонентами и многокритериальном анализе (оптимизации) [5]. При рефлексивном взаимодействии одна сторона передает второй стороне основания, из которых вторая сторона может логически вывести свое, но предопределенное первой стороной, решение.

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

Социокиберфизические системы наследуют характеристики КФС как сложной нелинейной системы и включают человека в свой состав [7].

СКФС могут рассматриваться как сложные со-циотехнические системы с непредсказуемым поведением, в которых социальные и технические аспекты сильно переплетены [5]. Так как в СКФС человек становится частью системы, он может стать участником процесса принятия решений. Более того, так как возможности кибернетических компонентов в части принятия решений ограничены имеющейся у них вычислительной мощностью и встроенными интеллектуальными возможностями [8], человек пока является единственным, кто способен преодолеть последствия непредсказуемого поведения СКФС, поскольку он может использовать свой опыт и интуицию, а не только предварительно запрограммированные правила и процедуры.

Анализ ряда работ, в которых имеет место принятие решений в КФС и СКФС (например, [3, 4, 9, 10]), позволяет выявить общую схему поддержки принятия решений в таких системах (рис. 1). КФС собирает данные, поставляемые сенсорами, актуаторами, RFID-метками и другими электронными устройствами. Кибернетические компоненты обрабатывают эти данные и формируют контекст. Контекст доступен всем компонентам системы, для чего в архитектурах систем предусматривают специальный элемент, обеспечивающий общедоступность контекста (например, центральный сервер, облачное хранилище информации и др.). Контекст представляет информацию, позволяющую сформировать взгляд на текущее положение дел в среде функционирования системы. Например, для КФС, внедренной в производственную среду, контекст представляет информацию о производственном процессе, состоянии объектов этого процесса, неисправностях, операциях, выполняемых в данный момент, и т. п. Контекст является основой для генерации возможных решений. В КФС стараются сделать так, чтобы эти решения генерировались автоматически кибернетическими компонентами на основе заложенных в них методов и моделей. Если кибернетические компоненты не могут предложить решение, то на помощь приходит человек.

Принятие решений поддерживается процессами обмена информацией и взаимодействия между компонентами системы. В рамках общей схемы поддержки принятия решений обмен информацией осуществляется от кибернетического компонента к кибернетическому, от кибернетического компонента к человеку, от человека к кибернетическому компоненту, от кибернетических компонентов и человека к центральному хранилищу информации и от центрального хранилища информации к кибернетическим компонентам и к человеку [11]. В рассмотренной выше схеме роль центрального хранилища информации играет контекст. СКФС формирует контекст

----> is-a (подкласс)

■ Рис. 1. Общая схема поддержки принятия решений в СКФС

■ Fig. 1. Scheme of decision support in socio-cyber-physical system

посредством преобразования данных в информацию и выбора релевантной информации. Для формирования контекста в различных системах используются различные подходы. Широко распространен подход, основанный на использовании онтологических моделей знаний [12-14]. При таком подходе в СКФС, как правило, присутствует онтология, которая, так же как и контекст, является доступной всем компонентам системы и обеспечивает их интероперабельность. Несмотря на то, что на представленной схеме (см. рис. 1) явно онтология не показана, она считается входящей в структуру СКФС.

Концептуальная модель поддержки принятия решений в СКФС

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

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

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

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

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

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

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

Человек Преобразователь Кибернетический

поддержка сообщений поддержка компонент

▲ человекочитаемой формы машиночитаемой формы ▲

подкласс

подкласс

Профиль

Онтология проблемной области

т

данные

представлен

Участник процесса принятия решений

взаимодействует

имеет доступ информация

Модель поддержки принятия решения

определяет

формулирует

Задача

предмет взаимодействия

■ Рис. 2. Концептуальная модель поддержки принятия решений в СКФС

■ Fig. 2. Conceptual framework of decision making in socio-cyber-physical system

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

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

Сообщения, представленные при помощи шаблонов, легко понимаются кибернетическими

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

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

С каждым событием в онтологии связаны знания, относящиеся к этому виду события. На основании этих связей формируется контекст в форме онтологической модели текущей ситуации [17].

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

дачу, в рамках которой и осуществляется поддержка.

Задача является предметом информационного взаимодействия участников процесса принятия решений. Она определяет, какие компоненты могут участвовать в процессе принятия решений и какой информацией будут обмениваться участники. В процессе принятия решений могут принимать участие компоненты, информация в профилях которых соответствует требованиям со стороны среды функционирования СКФС к участникам. Например, участники должны обладать определенной компетенцией, выполнять определенные роли, иметь определенный уровень доступа и т. п. Участники обмениваются информацией о том, как выполнять задачу. Эта информация считывается из контекста и подставляется в соответствующий шаблон текстового сообщения.

Преобразователи сообщений трансформируют формализованные сообщения в человекочитае-мую форму. Преобразованию подлежат сообщения от кибернетических компонентов к человеку и обратно.

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

Модели поддержки принятия решений компонентами СКФС на различных этапах этого процесса описаны в разделе «Модели поддержки принятия решений». Использование моделей иллюстрируется на примере сценария поддержки принятия решений при выполнении роботами поведенческих задач.

Пример сценария поддержки принятия решений

В сценарии поддержки принятия решений, используемом в качестве примера, робот Alfa выполняет задание, заключающееся в том, что он должен двигаться по прямой из точки Start в точку End. На своем пути робот встречает препятствие, наличие которого определяет имеющийся у робота сенсор. В онтологии робота не представлены знания о том, как преодолеть препятствие. На основании информации от сенсора и онтологии проблемной области СКФС определяет тип события как «препятствие» и устанавливает, что, для того чтобы робот мог преодолеть препятствие, должны быть определены размеры этого препятствия и выяснена последовательность действий, которую требуется выполнить для преодоления этого препятствия. Измерением объектов (в рассматриваемом сценарии — препятствия) занимается еще один робот — Beta. Оба робота фор-

мируют совместный план действий. Реализация плана заключается в том, что робот Beta измеряет препятствие, а робот Alfa преодолевает препятствие и завершает движение в точке End.

Для реализации описанного сценария были разработаны прототипы двух мобильных роботов, построенные на базе робототехнического набора Lego Mindstorm EV3. Данный набор позволяет легко сконструировать робота необходимой функциональности для целей обучения. При этом есть возможность использовать электронные блоки, моторы и датчики и программировать их на языке Java [18].

Первый робот (рис. 3, а), Alfa, способен двигаться вперед, обнаруживать препятствия на пути и преодолевать их. Для того чтобы робот был способен преодолевать препятствия, он сконструирован из нескольких блоков. Благодаря этому робот может взбираться на препятствие постепенно, сначала поднимая и фиксируя на препятствии передний блок, затем, опираясь на передний и задний блоки, поднимать средний. Все блоки оснащены приводной парой колес; помимо этого, центральный блок имеет бесприводную пару колес для поддержания равновесия. Также на центральном блоке установлен ультразвуковой датчик для измерения расстояния до объектов. Этот датчик используется для обнаружения препятствия на пути робота, при котором происходит автоматическая остановка. Второй робот (3, б), Beta, способен подъезжать к объектам и измерять их.

На рис. 4 приведена онтология проблемной области, которая для наглядности сильно упрощена. Она представляет только те концепты, которые важны для понимания рассматриваемого сценария. Для описания онтологии проблемной области и онтологий роботов использовался язык веб-онтологий OWL [19]. Онтология проблемной области создана при помощи редактора онтоло-гий Protégé, в котором типовые онтологические отношения и классы представлены при помощи латиницы [20]. Для устранения двуязычного представления при именовании классов, отношений и индивидов в разрабатываемых онтологиях также использовалась латиница.

В онтологии робот (Robot) определен как кибернетический (Cyber) компонент (Component). Робот может быть мобильным (Mobile_robot) или стационарным (не представлен на рисунке). Оба робота, фигурирующих в сценарии (Alfa и Beta), относятся к категории мобильных роботов. Роботы могут (isCapable) выполнять определенные задачи, которые представлены в классе Task. Для спецификации выполняемых роботами задач в текущей ситуации (контексте) используется отношение isPerforming, позволяющее выразить, какую именно задачу (какое действие) робот выполняет в данное время. В рамках сценария опре-

а)

■ Рис. 3. Мобильный робот Alfa (а) и Beta (б)

■ Fig. 3. Mobile robot Alfa (а) and Beta (б)

делены три базовые задачи: двигаться прямолинейно (MoveStraight), двигаться под углом (Climb) и измерять (Measure). Причем задачи, целью которых является перемещение (MoveStraight и Climb), являются подклассами класса Move, который соответствует задаче перемещения. В рассматриваемой части онтологии определены два класса для представления событий: HumanTask и Barrier. Класс HumanTask предназначен для спецификации событий, связанных с назначением человеком заданий для роботов; класс Barrier — для спецификации событий, связанных с препятствиями. Препятствия имеют размеры, что в онтологии представлено при помо-

щи отношения hasSize между классом Barrier и классами Length (длина), Height (высота) и Width (ширина). Длина, высота и ширина специфицированы в классе SizeCharacteristic как три измерения габаритных размеров. Размеры препятствия могут быть измерены (beMeasured) посредством выполнения действий, определенных в задаче Measure. Препятствие может быть преодолено (beOvercome), если двигаться под углом (Climb). Для описания пространственных характеристик компонентов СКФС и пространственных параметров задач (действий) используются отношения и концепты, специфицированные в классах Location (местоположение) и Time (вре-

Context_Charact eristic

hasSubclass

hasSubclass,

HumanTask

SlzeCharacteris tic

/7

hasSubclass

Event

hasSubclass

hasSubclass isCapable у

S

//

hasSubclass

/1 1

Cyber

V

hasSubclass

hasSubclass 1

/

/

/

/ /

1

hasSubclass

isPerforming

beMeasured

Robot ■—1-

hasSubclass

J

\

beOvercome

ome

hasSubclass hasSize hasSize hasSize

Mobile_robot

MoveStralglit

Climb

hasIndividual

/

/

Height

Length

Width

' ♦ Alfa

' ♦ Beta

hasSubclass — иметь подкласс

hasIndividual — иметь индивида (представителя класса)

■ Рис. 4. Онтология проблемной области

■ Fig. 4. Domain ontology

мя). Оба эти класса являются подклассами класса, представляющего контекстно-зависимые категории — Context_Characteristic.

Модели поддержки принятия решений

Этапы принятия решений образуют последовательность, которая, в свою очередь, обусловливает последовательность выполнения моделей поддержки принятия решений. На рис. 5 показаны информационные зависимости между моделями поддержки принятия решений.

Модель поддержки принятия решений на этапе осознания ситуации

Социокиберфизическая система постоянно посылает кибернетическим компонентам сообщения о наступлении различных событий. Задачей кибернетических компонентов на этапе осознания ситуации является выявление на основе этих сообщений информации о необходимости вычислений (действий). Для этого кибернетические компоненты используют свои онтологии и (или) онтологию проблемной области. Онтологии кибернетических компонентов представляют знания этих компонентов о том, как выполнять известные им вычислительные и поведенческие задачи. Эти знания могут дублироваться в онтологии проблемной области, но это дублирование не является обязательным. При получении сообщения о наступлении события кибернетические

Признак

отсутствия

необходимости

выполнения

вычислений

или действий

Признак выполнения задания

■ Рис. 5. Информационные потоки между моделями поддержки принятия решений

■ Fig. 5. Information flows between decision support models

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

проблемной области, так как эта модель содержит в себе знания из этой онтологии, релевантные текущей ситуации (и текущему событию). Решения о необходимости вычислений (действий) принимаются на основании ответов на запросы. Ответ (А) на запрос содержит неструктурированную информацию обо всех вычислениях и действиях, которые ожидаются от СКФС при наступлении рассматриваемого события.

В модели принятия решений на этапе осознания ситуации не предполагается, что кибернети-

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

Context_Chaiact eristic

RefcS.

isPerforming

hasSubclass

hasSubclass _i_

hasSubclass

hasSubclass

Move_Straight

hasLocation isPerforming i hasIndividual

4 Location ф Alfa 4 Mows Straight

URI: littp:/Mww.semanticvieb.orgrtanyalor tion

I' ll.] property assertions

Location Cunent_X Location Current_Z Location Current Y

Ща

URI: iittp:/Aftwjwsemantic^eb.org Object property assertions:

Alfa hasLocation Location .Alfa isPerforming MoveStraight

MoveStraigiit

URI: iTttpi/A^^^.seniantipAeb.orgrtanvBj'ontologies/SOia/S/irntitleci-ontologv-iiMove

Straight Data property assertions:

MoveStraigiit Start

MoveStra[ghrt Finish_

■ Рис. 6. Контекст при выполнении роботом Alfa задания двигаться по прямой (MoveStraight)

■ Fig. 6. Context when robot Alfa is performing the task to move in a straight line (MoveStraight)

■ Рис. 7. Фрагмент контекста, соответствующий расширению контекста (рис. 6) при появлении препятствия

■ Fig. 7. Context fragment corresponding to the enhancement of the context (Fig. 6) for the event Barrier

компонентам СКФС информации о сложившейся ситуации.

Применительно к используемому в качестве примера сценарию поддержки принятия решений рассматривается момент, когда на пути робота Alfa появляется препятствие. После того как СКФС распознала информацию от сенсора робота как «препятствие», контекст, ранее созданный при выполнении роботом Alfa задания двигаться по прямой (рис. 6), расширяется (рис. 7). В расширенном контексте появляются класс Barrier и все задачи и действия, которые связаны с этим классом. На рис. 7 классы, присутствующие в ранее созданном контексте (см. рис. 6), обведены пунктиром; остальные классы соответствуют классам, появившимся при наступлении события «препятствие» (Barrier).

Как только событие появилось в контексте, роботы отправляют запросы в онтологии и контекст на предмет наличия связанных с событием задач. В онтологии робота Alfa задачи, связанные с этим событием, не представлены. Запросы от роботов в контекст возвращают список всех задач и действий, связанных с классом Barrier, т. е. ответ A содержит следующие задачи: A = {Climb, ClimbUp, ClimbDown, FixLimb, LiftLimb, GoToObject,

PullDownLimb, Measure, MeasureLength, Measure-Height, MeasureWidth}. На рис. 7 классы, представляющие перечисленные задачи, обведены жирной линией. На этапе осознания ситуации такой список сигнализирует о наличии в текущей ситуации проблем, требующих решения.

Модель поддержки принятия решений на этапе идентификации проблемы

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

■ Рис. 8. Поддержка принятия решений на этапе идентификации проблемы

■ Fig. 8. Decision support when problem identification

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

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

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

В рассматриваемом сценарии для определения родовой задачи используется последовательность простейших SPARQL-запросов [21], формируемых по результатам ответа A, который может рассматриваться как множество классов. Для каждого класса, входящего в множество A, определяется его надкласс (рис. 9). Результатом выполнения каждого запроса будет ближайший надкласс (SuperTask) для класса Ai, где At — i-й элемент множества A. Если SuperTask совпадает с хотя бы одним из классов, представленным в множестве A, класс Ai не является родовым. Как только для SuperTask нет соответствия в множестве A, класс Ai считается классом, представляющим родовую задачу. Например, ответом на запрос, в котором At = ClimbUp, будет Climb

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-nsf>

PREFIX owl: <http://www.w3.org/2002/07/owlf> PREFIX xsd: <http://www.w3.org/2001/XMLSchemaf> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schemaf> PREFIX inter: <http://www.semanticweb.org/tanya/ ontologies/2019/2/Domain#> SELECT DISTINCT ?SuperTask

WHERE (inter:Ai rdfs:subClassOf ?SuperTask.)

■ Рис. 9. Запрос на определение родовой задачи

■ Fig. 9. Request on generic task

(SuperTask = Climb). Climb присутствует во множестве A, поэтому ClimbUp не является родовой задачей. Ответом на запрос, в котором Ai = Climb, будет Move. Move не присутствует во множестве A, значит класс Climb представляет родовую задачу. В результате выполнения описанной процедуры в рассматриваемом сценарии было выявлено две родовые задачи: двигаться под углом (Climb) и измерять (Measure).

Модель поддержки принятия решений на этапе определения альтернатив

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

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

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

Если в рамках одной последовательности для всех подзадач и действий найдены кибернетиче-

Да

Назначить подзадачи (действия), которые умеет выполнять данный компонент в последовательности i, этому компоненту

Сопоставление онтологий кибернетических компонентов с представлением задачи в онтологии проблемной области

Определить компоненты K, способные выполнить какие-либо подзадачи (действия), заданные в последовательности i

Создать множество альтернативных планов из частичных планов

Создать множество альтернативных планов из полных планов

■ Рис. 10. Процедура выдвижения альтернатив

■ Fig. 10. Procedure of development of alternatives

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

Если ни для одной из последовательностей не сформирован набор компонентов, которые были бы способны выполнить все подзадачи или дей-

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

и действия, для которых не найдено исполнителей, остаются «открытыми» (исполнители для этих подзадач и действий не определены).

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

Поддержка принятия решений на рассматриваемом этапе осуществляется посредством предоставления компонентам СКФС знаний о возможных альтернативах выполнения задачи.

В рассматриваемом сценарии поддержки принятия решений задача преодоления препятствия имеет два способа решения: преодолеть препятствие посредством подъема (движения под углом вверх (ClimbUp)) или спуска (движения под углом вниз (ClimbDown)) по этому препятствию. На этапе идентификации проблемы выявлено две задачи, требующие решения: Climb и Measure. Спецификация задачи измерения препятствий (Measure) содержится в онтологии робота Beta и в онтологии проблемной области. Так как робот Beta обнаружил эту задачу в своей онтологии, он предлагает себя в качестве исполнителя. Задача движения под углом (Climb) представлена только в онтологии проблемной области. Исполнителем этой задачи может быть компонент, в профиле которого содержится информация о том, что он обладает соответствующей компетенцией, или компонент, назначенный человеком.

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

а) Beta: Measure(Obj, O_Loc), Alfa: ClimbUp (Barrier_H), Alfa: MoveStraight(Start1, End);

б) Beta: Measure(Obj, O_Loc), Alfa: ClimbDown (-Barrier_H), Alfa: MoveStraight(Start1, End).

В приведенных планах робот Beta измеряет препятствие, робот Alfa преодолевает препятствие и продолжает движение по прямой с точки, в которой он находится после преодоления препятствия (Startl), к точке End. Данные планы сфокусированы на целях выполнения задач и не учитывают время, затрачиваемое роботами на выполнение действий. То есть планы представлены в виде последовательности действий, которые роботы должны выполнить, чтобы достичь поставленных целей.

Модель поддержки принятия решений на этапе выбора предпочтительной альтернативы

Решением, принимаемым на этапе выбора предпочтительной альтернативы, является решение о предпочтительном плане работ.

Если множество альтернатив состоит из полностью сформированных планов, то предпочтительный план выбирается кибернетическими компонентами посредством переговоров на предмет соответствия предложенному критерию, который определяется проблемной областью и может быть представлен функцией от одной или нескольких характеристик компонента (стоимости, скорости выполнения задачи, уровня надежности и т. п.). Значения этих характеристик являются результатом профилирования и хранятся в профилях компонентов. После завершения переговоров [22] определяется интегральный показатель по каждому плану и выбирается окончательный вариант на основании соответствия этих показателей предложенному критерию.

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

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

Модель поддержки принятия решений на этапе реализации решения

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

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

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

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

В рассматриваемом сценарии роботы начинают выполнять сформированные планы, и робот Beta сталкивается с трудностями при вы-

полнении первой задачи — Measure(Obj, O_Loc). Именно в соответствии с планом он должен измерить препятствие, но в месте его текущего местоположения препятствия нет. Поэтому он обращается за помощью к человеку и отправляет сообщение, пользуясь шаблоном, который предназначен для отправки сообщений при возникновении трудностей в процессе выполнения задачи:

<Type, Sender, Recipient, Activity, Event, Content, Status>,

где Type — тип сообщения (возможны три значения: запрос (Request), ответ (Reply), уведомление (Notification)); Sender — идентификатор (имя) отправителя сообщения; Recipient — имя, идентификатор или роль получателя сообщения; Activity — выполняемая отправителем сообщения задача (задача, связанная отношением isPerforming с отправителем); Content — специфическая информация, представляющая появившиеся проблемы; Status — статус выполнения задачи (для статуса определено три значения: выполнено (Completed), не выполнено (Failed), приостановлено (Suspended)).

Отправляемое текстовое сообщение выглядит следующим образом:

<Request, Beta, Consultant, Measure(Steps, StepsLocation), Barrier, ?, Suspended>,

где Request — тип сообщения — запрос; отправитель сообщения — робот Beta; получатель сообщения — любой компонент СКФС, выполняющий роль консультанта (Consultant); робот выполняет задачу измерения размеров (Measure) объек-

■ Рис. 11. Пример реализации плана

■ Fig. 11. An example of plan implementation

та Steps, расположенного в месте StepsLocation; имеет место событие — препятствие (Barrier); Content = ? означает, что робот не знает, что ему делать. Content может использоваться, чтобы представлять конкретные действия, которые робот не может выполнить, или аргументы задач (более подробно этот элемент рассмотрен в работе [11]).

В качестве ответа консультант отправляет роботу пошаговую инструкцию, что он должен делать. Например, сообщение вида

<Reply, Consultant, Beta, GoTo(StepsLocation)>

означает, что робот должен подойти к месту расположения объекта Steps. После того как робот выполнил это действие, он сообщает об удачном его завершении:

<Notification, Beta, Consultant, GoTo(StepsLocation), , , Completed>.

Это действие робот заносит в свою онтологию. В дальнейшем робот будет знать, что перед началом измерений он должен подойти к объекту.

Теперь роботы могут приступить к реализации сформированных планов. Робот Beta устанавливает размеры препятствия и сообщает их роботу Alfa. В зависимости от значения Barrier_H, которое обозначает высоту препятствия, робот Alfa выбирает соответствующий план. В данном примере значение Barrier_H определяет выбор плана преодоления препятствия посредством подъема (рис. 11). Преодоление препятствия реализуется в результате выполнения последовательности действий, заданной в онтологии: GotoObject ^ LiftLimb ^ PullDownLimb ^ FixLimb, — которая назначается при помощи шаблона проектирования онтологий (Ontology Design Pattern) для задания последовательностей — sequence.owl [23].

Литература

1. Petnga L., Austin M. An ontological framework for knowledge modeling and decision support in cy-ber-physical systems. Advanced Engineering Informatics, 2016, vol. 30, pp. 77-94. doi:http://dx.doi. org/10.1016/j.aei.2015.12.003

2. Klober-Koch J., Pielmeier J., Grimm S., Brandt M. M., Schneider M., Reinharta G. Knowledge-based decision making in a cyber-physical production scenario. Procedia Manufacturing, 2017, vol. 9, pp. 167-174. doi:https://doi.org/10.1016/j.promfg.2017.04.014

3. Salama S., Eltawil A. A decision support system architecture based on simulation optimization for cy-ber-physical systems. Procedia Manufacturing, 2018, vol. 26, pp. 1147-1158. doi:10.1016/j.promfg.2018.07.151

Заключение

В работе описаны модели поддержки принятия решений в СКФС на типовых этапах процесса принятия решений: осознания ситуации, идентификации проблемы, выдвижения альтернатив, выбора предпочтительной альтернативы, реализации решения. Модели позволяют формировать и реализовывать планы работ компонентов систем по решению общей задачи и достижению цели. Общая схема принятия решений заключается в том, что вначале решение принимают кибернетические компоненты, а если они не могут этого сделать, то обращаются за помощью к человеку. В настоящее время такой подход является наиболее реализуемым вследствие того, что СКФС обладают свойством непредсказуемости. Человек пока является единственным, кто способен преодолеть последствия непредсказуемого поведения этих систем, поскольку он может использовать свой опыт и интуицию, а не только предварительно запрограммированные правила и процедуры. Также такой подход представляется целесообразным при помещении уже существующих кибернетических компонентов в новую среду. Благодаря возможности взаимодействия с человеком, эти компоненты могут быстро получить от него недостающие знания и приспособиться к выполнению новых для них задач. Рассмотренный в работе сценарий поддержки принятия решений при планировании роботами процесса выполнения общей задачи подтверждает применимость разработанных моделей.

Финансовая поддержка

Работа выполнена при финансовой поддержке РФФИ (проекты № 17-07-00248 и 17-29-07073) и бюджетной темы № 0073-2019-0005.

4. Fang Y., Roofigari-Esfahan N., Anumba C. A Knowledge-based cyber-physical system (CPS) architecture for informed decision making in construction. Construction Research Congress 2018, ASCE, 2018, pp. 662-672.

5. Horvath I. What the Design Theory of Social-Cy-ber-Physical Systems Must Describe, Explain and Predict? In: An Anthology of Theories and Models of Design / eds. by A. Chakrabarti, L. T. M. Blessing. London, Springer-Verlag, 2014. Pp. 99-120. doi:10.1007/ 978-1-4471-6338-1_2

6. Arthur W. B. Why do things become more complex? Scientific American, 1993, vol. 268, no. 5, p. 92.

7. Liu Z., Yang D.-S., Wen D., Zhang W.-M., Mao W. Cy-ber-physical-social systems for command and control. IEEE Intelligent Systems, 2011, July/August, pp. 9296.

8. Naveed K., Khan Z. H., Hussain A. Adaptive trajectory tracking of wheeled mobile robot with uncertain parameters. In: Computational Intelligence for Decision Support in Cyber-Physical Systems / eds. by Z. H. Khan; Studies in Computational Intelligence, Springer, 2014, vol. 540. Pp. 237-262. doi:10.1007/978-981-4585-36-1_8

9. Lee J., Ardakani H. D., Yang S., Bagheri B. Industrial big data analytics and cyber-physical systems for future maintenance & service innovation. Procedia CIRP, 2015, vol. 38, pp. 3-7. doi:10.1016/j.procir.2015.08.026

10. Badampudi D., Wnuk K., Wohlin C., Franke U., Smite D., Cicchetti A. A decision-making process-line for selection of software asset origins and components. Journal of Systems and Software, 2018, vol. 135, pp. 88-104. doi:10.1016/j.jss.2017.09.033

11. Смирнов А., Левашова Т. Приобретение знаний в социокиберфизических системах в процессе информационного взаимодействия ресурсов. Информационно-управляющие системы, 2017, № 6, с. 113-122. doi:10.15217/issn1684-8853.2017.6.113

12. Sun Y., Yang G., Zhou X. A novel ontology-based service model for cyber physical system. 2016 5th International Conference on Computer Science and Network Technology (ICCSNT), IEEE, 2016, pp. 125131. doi:10.1109/ICCSNT.2016.8070133

13. Hildebrandt C., Torsleff S., Caesar B., Fay A. Ontology building for cyber-physical systems: A domain expert-centric approach. 2018 IEEE 14th International Conference on Automation Science and Engineering (CASE), IEEE, 2018, pp. 1079-1086. doi:10.1109/ C0ASE.2018.8560465

14. Smirnov A., Levashova T., Kashevnik A. Ontology-based resource interoperability in socio-cy-ber-physical systems. Information Technology in Industry, 2018, vol. 6, no. 2, pp. 19-25.

15. Dey A. K. Understanding and using context. Personal and Ubiquitous Computing, 2001, vol. 5, no. 1, pp. 4-7.

16. Simon H. A. Making management decisions: the role of intuition and emotion. The Academy of Management Executive, 1987, vol. 1, no. 1, pp. 57-64.

17. Смирнов А. В., Левашова Т. В. Онтологии в системах поддержки принятия оперативных решений: практические аспекты. Онтологическое моделирование: тр. второго симп., Казань, 11-12 октября 2010 г. / под ред. Л. А. Калиниченко, М., ИПИ РАН, 2011, с. 215-232.

18. Smirnov A., Kashevnik A. Semantic interoperability for coalition creation by mobile robots and humans: an approach and case study. IFAC-PapersOnLine / eds. by M. Macchi, L. Monostori, R. Pinto, 2018, vol. 51, no. 11, pp. 1409-1414. doi:https://doi.org/10. 1016/j.ifacol.2018.08.319

19. OWL Web Ontology Language Overview. W3C Recommendation, 10 Feb 2004 / eds. by D. L. McGuin-ness, F. van Harmelen. https://www.w3.org/TR/ owl-features/ (дата обращения: 06.03.2019).

20. Protégé. https://protege.stanford.edu/ (дата обращения: 06.03.2019).

21. Harris S., Seaborne A. SPARQL 1.1 Query Language. W3C Recommendation, 21 March 2013. http://www. w3.org/TR/sparql11-query (дата обращения: 07.07.2019).

22. Teslya N., Smirnov A., Levashova T., Shilov N. Ontology for resource self-organisation in cyber-physi-cal-social systems. Proceedings of the 5th International Conference of Knowledge Engineering and the Semantic Web (KESW 2014) / eds. by P. Klinov, D. Mouromtsev, Communications in Computer and Information Science, Springer, 2014, vol. 468, pp. 184-195.

23. Sequence Pattern / Ontology Design Patterns. http:// www.ontologydesignpatterns.org/cp/owl/sequence. owl (дата обращения: 12.03.2019).

UDC 004.822: 004.896:007.51 doi:10.31799/1684-8853-2019-3-55-70

Models of decision support in socio-cyber-physical systems

A. V. Smirnova, Dr. Sc., Tech., Professor, orcid.org/0000-0001-8364-073X, smir@iias.spb.su T. V. Levashovaa, PhD, Tech., Senior Researcher, orcid.org/0000-0002-1962-7044, tatiana.levashova@iias.spb.su aSaint-Petersburg Institute for Informatics and Automation of the RAS, 39, 14 Line, V. O., 199178, Saint-Petersburg, Russian Federation

Introduction: Socio-cyber-physical systems are complex non-linear systems. Such systems display emergent properties. Involvement of humans, as a part of these systems, in the decision-making process contributes to overcoming the consequences of the emergent system behavior, since people can use their experience and intuition, not just the programmed rules and procedures. Purpose: Development of models for decision support in socio-cyber-physical systems. Results: A scheme of decision making in socio-cyber-physical systems, a conceptual framework of decision support in these systems, and stepwise decision support models have been developed. The decisionmaking scheme is that cybernetic components make their decisions first, and if they cannot do this, they ask humans for help. The stepwise models support the decisions made by components of socio-cyber-physical systems at the conventional stages of the decision-making process: situation awareness, problem identification, development of alternatives, choice of a preferred alternative, and decision implementation. The application of the developed models is illustrated through a scenario for planning the execution of a common task for robots. Practical relevance: The developed models enable you to design plans on solving tasks common for system components or on achievement of common goals, and to implement these plans. The models contribute to overcoming the consequences of the emergent behavior of socio-cyber-physical systems, and to the research on machine learning and mobile robot control.

Keywords — socio-cyber-physical system, decision support, ontology, task planning process.

For citation: Smirnov A. V., Levashova T. V. Models of decision support in socio-cyber-physical systems. Informatsionno-upravliaiushchie sistemy [Information and Control Systems], 2019, no. 3, pp. 55-70 (In Russian). doi:10.31799/1684-8853-2019-3-55-70

References

1. Petnga L., Austin M. An ontological framework for knowledge modeling and decision support in cyber-physical systems. Advanced Engineering Informatics, 2016, vol. 30, pp. 77-94. doi:http://dx.doi.org/10.1016/j.aei.2015.12.003

2. Klober-Koch J., Pielmeier J., Grimm S., Brandt M. M., Schneider M., Reinharta G. Knowledge-based decision making in a cyber-physical production scenario. Procedia Manufacturing, 2017, vol. 9, pp. 167-174. doi:https://doi.org/ 10.1016/j.promfg.2017.04.014

3. Salama S., Eltawil A. A decision support system architecture based on simulation optimization for cyber-physical systems. Procedia Manufacturing, 2018, vol. 26, pp. 11471158. doi:10.1016/j.promfg.2018.07.151

4. Fang Y., Roofigari-Esfahan N., Anumba C. A Knowledge-based cyber-physical system (CPS) architecture for informed decision making in construction. Construction Research Congress 2018, ASCE, 2018, pp. 662-672.

5. Horvath I. What the Design Theory of Social-Cyber-Physical Systems Must Describe, Explain and Predict? In: An Anthology of Theories and Models of Design; eds. by A. Chakrabar-ti, L. T. M. Blessing. London, Springer-Verlag, 2014. Pp. 99-120. doi:10.1007/978-1-4471-6338-1_2

6. Arthur W. B. Why do things become more complex? Scientific American, 1993, vol. 268, no. 5, p. 92.

7. Liu Z., Yang D.-S., Wen D., Zhang W.-M., Mao W. Cy-ber-physical-social systems for command and control. IEEE Intelligent Systems, 2011, July/August, pp. 92-96.

8. Naveed K., Khan Z. H., Hussain A. Adaptive trajectory tracking of wheeled mobile robot with uncertain parameters. In: Computational Intelligence for Decision Support in Cy-ber-Physical Systems; eds. by Z. H. Khan; Studies in Computational Intelligence, Springer, 2014, vol. 540. Pp. 237-262. doi:10.1007/978-981-4585-36-1_8

9. Lee J., Ardakani H. D., Yang S., Bagheri B. Industrial big data analytics and cyber-physical systems for future maintenance & service innovation. Procedia CIRP, 2015, vol. 38, pp. 3-7. doi:10.1016/j.procir.2015.08.026

10. Badampudi D., Wnuk K., Wohlin C., Franke U., Smite D., Cicchetti A. A decision-making process-line for selection of software asset origins and components. Journal of Systems and Software, 2018, vol. 135, pp. 88-104. doi:10.1016/j. jss.2017.09.033

11. Smirnov A., Levashova T. Knowledge acquisition in so-cio-cyber-physical systems through information exchange between resources. Informatsionno-upravliaiushchie siste-my [Information and Control Systems], 2017, no. 6, pp. 113122 (In Russian). doi:10.15217/issn1684-8853.2017.6.113

12. Sun Y., Yang G., Zhou X. A novel ontology-based service model for cyber physical system. 2016 5th International Conference on Computer Science and Network Technology (ICCSNT), IEEE, 2016, pp. 125-131. doi:10.1109/ICCSNT. 2016.8070133

13. Hildebrandt C., Törsleff S., Caesar B., Fay A. Ontology building for cyber-physical systems: A domain expert-centric approach. 2018 IEEE 14th International Conference on Automation Science and Engineering (CASE), IEEE, 2018, pp. 1079-1086. doi:10.1109/C0ASE.2018.8560465

14. Smirnov A., Levashova T., Kashevnik A. Ontology-based resource interoperability in socio-cyber-physical systems. Information Technology in Industry, 2018, vol. 6, no. 2, pp. 19-25.

15. Dey A. K. Understanding and using context. Personal and Ubiquitous Computing, 2001, vol. 5, no. 1, pp. 4-7.

16. Simon H. A. Making management decisions: the role of intuition and emotion. The Academy of Management Executive, 1987, vol. 1, no. 1, pp. 57-64.

17. Smirnov A., Levashova T. Ontologies in decision support systems for operation decisions: practical aspects. Trudy 2 simpoziuma "Ontologicheskoe modelirovanie" [Proc. of the 2nd Symp. "Ontological modeling"], Kazan, 11-12 October, 2010, ed. by L. A. Kalinichenko, Moscow, 2011, pp. 215-232 (In Russian).

18. Smirnov A., Kashevnik A. Semantic interoperability for coalition creation by mobile robots and humans: an approach and case study. IFAC-PapersOnLine, 2018, vol. 51, no. 11, pp. 14091414. doi:https://doi.org/10.1016/j.ifacol.2018.08.319

19. OWL Web Ontology Language Overview. W3C Recommendation, 10 Feb 2004. Eds. by D. L. McGuinness, F. van Harmelen. Available at: https://www.w3.org/TR/owl-features/ (accessed 6 March 2019).

20. Protégé. Available at: https://protege.stanford.edu/ (accessed 6 March 2019).

21. Harris S., Seaborne A. SPARQL 1.1 Query Language. W3C Recommendation, 21 March 2013. Available at: http://www. w3.org/TR/sparql11-query (accessed 6 March 2019).

22. Teslya N., Smirnov A., Levashova T., Shilov N. Ontology for resource self-organisation in cyber-physical-social systems. Proceedings of the 5th International Conference of Knowledge Engineering and the Semantic Web (KESW 2014), eds. by P. Klinov, D. Mouromtsev, Communications in Computer and Information Science, Springer, 2014, vol. 468, pp. 184-195.

23. Sequence Pattern / Ontology Design Patterns. Available at: http://www.ontologydesignpatterns.org/cp/owl/sequence. owl (accessed 6 March 2019).