CC BY
11СЕМИОТИЧЕСКАЯ МОДЕЛЬ СИТУАЦИОННОГО УПРАВЛЕНИЯ ПРИМЕНИТЕЛЬНО К ЗАДАЧЕ УПРАВЛЕНИЯ ОБЛАЧНОЙ ИНФРАСТРУКТУРОЙ
Попов И.Б.
Магистрант Алматинского университета энергетики и связи
г. Алматы, Республика Казахстан
SEMIOTIC MODEL OF SITUATION MANAGEMENT APPLIED TO THE PROBLEM OF CLOUD
INFRASTRUCTURE MANAGEMENT
Popov I.
Master student of Almaty University of Power Engineering and Telecommunications
Almaty, Kazakhstan
Аннотация
В настоящее время управление облачной инфраструктурой требует использования специализированных инструментов в виде веб-консоли или утилиты командной строки. Использование в управлении естественного языка пока не получило широкого распространение. В данной статье исследуется возможность представления инфраструктуры на основе семиотической модели, как часть разработки системы управления с использованием естественного языка.
Abstract
Currently, managing cloud infrastructure requires the use of specialized tools in the form of a web console or command line utility. The use of natural language in management has not yet become widespread. This article explores the possibility of representing an infrastructure based on a semiotic model as part of the development of a control system using natural language.
Ключевые слова: облачная инфраструктура, ситуационное управление, семиотическая модель.
Keywords: cloud infrastructure, situational management, semiotic model.
Традиционная процедура управления из теории автоматического управления[1] может работать только с объектами, соответствующими некоторым критериям, одним из которых является четкая зависимость выхода от входа. Если данная зависимость нас не устраивает, мы оказываем управляющее воздействие. Основная задача при проектировании подобной системы управления -нахождение критерия управления.
Однако, многими системами, в том числе платформой, предоставляющей облачную инфраструктуру, управлять таким образом невозможно.
Если пользователь, например, попытается ввести команду «создать сервер с 8 процессорами и 32 Гб памяти», как система управления должна отреагировать на такой «вход»? Возможно, ему сначала необходимо создать ЦОД или жесткий диск, который будет подключен к серверу. Но на входе этой информации нет, соответственно система управления не сможет принять верное решение.
Другой проблемой является то, что облачная платформа не является статической системой. При работе с ней могут изменяться как набор входов, так и набор выходы, что требует изменения критерия управления.
Поэтому, в случае необходимости управления объектом с уникальной структурой, который может изменяться со временем, можно применить метод ситуационного управления[2]. Он основан на понятии ситуации, их классификации и преобразовании. Рассмотрим ключевые понятия.
Вполне логично, что в любой конкретный момент времени объект управления можно охарактеризовать через его совокупность сведений о его текущей структуре и состоянии. Такая совокупность в ситуационном управлении называется текущей ситуацией.
Также существует понятие полной ситуации, которая является совокупностью текущей ситуации, знаний о состоянии системы управления и знаний о технологии управления.
При этом в распоряжении системы управления имеется некоторое конечное множество возможных воздействий на объект, называемых одношаго-выми решениями.
Если обозначить полные ситуации через 5;, текущие ситуации через Qj, а одношаговые решения через ик, то акт управления можно записать в следующем виде[3]:
So Qj =f> Qi
ик
(1)
То есть, если сложившиеся текущая ситуация и полная ситуация на объекте и в системе управления позволяют применить определенное воздействие, оно применяется, что приводит к появлению новой текущей ситуации. Правила таких преобразований называются корреляционными правилами или логико-трансформационными правилами. Именно они определяют возможности системы управления воздействовать на объект.
Так как количество возможных воздействий на объект конечно и, как правило, количество возможных полных ситуаций существенно больше количе-
ства возможных решений, обычно создаются неко- На Рисунке 1 представлена схема управления
торые правила классификации, делящие полные си- по ситуационной модели. туации на классы, к каждому из которых применяется одно решение. При этом, ситуация может быть отнесена к нескольким классам.
на объект
Рисунок 0 - схема управления по ситуационной модели
Процесс управления в общем виде можно представить следующим образом:
1. Описание текущей ситуации на объекте управления попадает в Анализатор. Именно в нем оценивается необходимость вмешательства системы управления в процесс.
2. Если такая необходимость обнаружена, описание текущей ситуации передается в Классификатор, который относит ее к одному или нескольким классам, каждому из которых соответствует одно одношаговое решение.
3. Далее эта информация передается в Коррелятор, содержащий корреляционные правила. Он выбирает то правило, которое должно быть использовано в данной ситуации. Если такое правило одно, то на объект управления оказывается соответствующее воздействие.
4. Если на предыдущем этапе выявлено несколько применимых правил, в действие вступает Экстраполятор. Он выполняет обработку предварительных решений и выбирает лучшее из предложенных правил. Далее Коррелятор выдает воздействие.
5. Если Классификатор и Коррелятор не смогли по поступившему описанию ситуации принять решение, то может быть задействован Блок случайного выбора. Он выбирает одно из воздей-
ствий, которое окажет небольшое влияние на объект. Или система управления просто откажется от любого воздействия, по причине недостаточности данных.
Для описания динамических систем удобно использовать семиотическую модель. Семиотика изучает знаковые системы в целом и основные аспекты отдельных знаков: имя знака (синтаксический аспект), содержание знака (семантический аспект) и назначение знака (прагматический аспект) [4,5].
Однако перед тем как описывать семиотическую модель, необходимо дать понятие формальной модели, на которой она основана:
М = <Т,Р,А,П (2)
>
Множество Т модели содержит множество базовых элементов, на основе которых строятся все другие элементы системы. На него не накладывается никаких ограничений, но каждый из этих «строительных блоков» должен отличаться от остальных. Применительно к нашей облачной платформе, к базовым элементам можно отнести, например, имена объектов, имена их параметров и т.д.
Множество Р содержит синтаксические правила. Их использование позволяет строить совокупности из базовых элементов, которые будут считаться синтаксически правильными. На это
множество не накладывается особых ограничений, но должна существовать возможность дать четкий ответ, является ли конкретная совокупность базовых элементов синтаксически правильной или нет. Для облачной платформы, система синтаксических правил может быть такой, что синтаксически правильными будут считаться любые сочетания имени объекта и имен обязательных и необязательных параметров, и даже нескольких имен объектов.
Множество А содержит систему аксиом, которую может образовывать любое множество синтаксически правильных совокупностей. В нашем случае, это могут быть сочетания, которые характеризуют полное состояние системы. Например, если у нас есть пользователь, для которого заданы только имя пользователя и пароль, то совокупность этих элементов будет входить в это множество. Но если к ней добавить еще адрес электронной почты, то данная совокупность уже не будет считаться аксиомой.
Множество П содержит семантические правила, которые позволяют расширить множество ак-
сиом, путем добавления новых синтаксически правильных совокупностей. Применяя эти правила, мы получаем множество семантически правильных совокупностей. Для облачной платформы, любое сочетание из имени объекта и как минимум его обязательных параметров будет являться семантических правильной совокупностью. Однако, если добавить любой из параметров, объекту не принадлежащий, семантически правильной такая совокупность уже не будет.
Подобные формальные модели позволяют описывать только статические системы, поэтому для описания сложных динамических систем мы переходим к семиотической модели.
Суть ее заключается в том, что для каждого из множеств формальной системы имеется набор правил, согласно которому оно изменяется:
С = < М,/т,/Р,/А,/П > (3)
Соответственно, семиотические модели позволяют изменять синтаксис базовых элементов, их семантику и прагматику.
На Рисунке 1 показана семиотическая модель в виде сети.
Рисунок 1 - семиотическая модель
На вышеприведенной схеме сети происходит переход от одной формальной системы к другой в связи с изменением х\ которое может совпадать с Хт ХР, Ха или хп, или с любым их сочетанием.
При создании системы управления облачной платформой, невозможно обойтись одной формальной системой, ее описывающей, в связи с тем, что она является динамической.
Рассмотрим несколько возможных вариантов изменений, которые потребуют перехода к новой формальной системе. В данной работе мы будем использовать платформу СБКлауд[6] в качестве примера, однако при минимальной доработке, разрабатываемая система должна позволить управлять любой облачной инфраструктурой, имеющей API, соответствующий неофициальному стандарту RESTful API[7].
Во-первых, совершенно очевидно, что множество базовых элементов Т облачной платформы будет со временем изменяться. Она не имеет какого-то конечного идеального состояния, по достижении которого работа над ней будет закончена.
Любое изменение, будь то добавление нового сервиса, добавление одного нового параметра для сервиса существующего или просто возможности управлять имеющимся сервисом, которой раньше не было, приведет к необходимости внесения изменений во множество базовых элементов системы.
Таким образом, должен существовать набор правил %т, который позволит вносить эти изменения. В нашем случае предполагается наличие некой процедуры, которая на регулярной основе обновляет множество базовых элементов на основе анализа API облачной платформы.
Во-вторых, т.к. облачная платформа является динамической системой, возможно изменение множества аксиом А. В терминах ситуационного управления, такой набор утверждений о системе позволяет отразить текущее положение вещей на объекте управления и в системе управления. Т.е. множество аксиом отражает полную ситуацию St.
В случае работы большой команды над проектом, может сложиться ситуация, когда одним ресурсом в конкретный момент времени пытаются
управлять более одного человека. Выполнение нескольких несогласованных управляющих воздействий может привести к нежелательному результату.
В другом случае, такая несогласованность может возникнуть даже при работе одного человека. Например, если на сервере было запущено пакетное задание, подразумевающее его выключение по завершению работы, это приведет к изменению контекста, текущей ситуации. Некоторые действия с ним потеряют смысл, другие наоборот станут возможны.
Следовательно, в нашей семиотической модели появляется необходимость создания набора правил ха, выполняющего изменение набора аксиом системы. Например, туда может быть включена процедура, запрашивающая данные о ресурсе, с которым пользователь работает в данный момент, и обновляющая при необходимости текущую ситуацию.
В-третьих, существует возможность изменения назначения какого-то ресурса облачной платформы. Например, в нашем случае конечные точки /v1/client/{entity_pk}/team,
/v1/partner/{entity_pk}/team и еще несколько других в API сейчас позволяет пользователю получить список своей команды. Возможно, что в дальнейшем их функционал будет изменен, чтобы избежать дублирования, что приведет к изменению прагматики.
Это приводит нас к необходимости создания правил хп, которые позволят выполнять обновление корреляционных правил.
Наконец, маловероятно, что при работе системы управления нам понадобится менять синтаксические правила. Поэтому, в наборе правил хр, нет необходимости. Их добавление может понадобиться, например, в том случае, если мы попытаемся добавить возможность вводить команды в систему управления не только на русском языке.
Таким образом, информация о ситуации в инфраструктуре может быть достоверно представлена в виде семантической сети, которая будет изменяться по правилам %т, хр, Ха, Хп или их сочетанию. Имея достоверное представление и выполнив синтаксический и семантический анализ запроса поль-
зователя на естественном языке, можно сопоставить информацию из него с информацией о состоянии системы. И в итоге выполнить управляющее воздействие, при необходимости.
В данный момент времени, управление облачной инфраструктурой через трансляцию запросов с естественного языка не имеет широкого распространения. Это вызвано рядом проблем, одной из которых является сложность и динамичность подобной инфраструктуры. В то же время, подобный подход не имеет недостатков классических инструментов управления (веб-консоль, утилиты командной строки): необходимости изучения синтаксиса работы с утилитой, проприетарности данных инструментов для каждого поставщика облачных сервисов и т.д. Естественный язык называется «естественным» не просто так, общение на нем является наиболее простым.
Данная работа показывает возможность использования семиотической модели ситуационного управления для представления информацию о динамической системе, в частности облачной инфраструктуре, как часть разработки системы управления с использованием естественного языка.
Список литературы
1. Страшинин Е.Э. Основы теории автоматичиского управления, Часть 1. Линейные непрерывные системы управления.: Учебное пособие. Екатеринбург: УГТУ, 2000. 217 с.
2. Поспелов Д.А. Большие системы. Ситуационное управление. Москва: Знание, 1975. 64 с.
3. Поспелов Д.А. Ситуационное управление: теория и практика. Москва: Наука, 1986. 288 с.
4. Поспелов Д.А., Осипов Г.С. Прикладная семиотика. Часть 1 // Новости искусственного интелекта. 1999. № 1. С. 9-35.
5. Кулинич А.А. Ситуационный, когнитивный и семиотический подходы к принятию решений в организациях // Open Educ. 2016. № 6. С. 9-17.
6. СБКлауд [Электронный ресурс]. URL: https://sbcloud.ru (дата обращения: 16.04.2021).
7. REST API Tutorial [Электронный ресурс]. URL: https://www.restapitutorial.com (дата обращения: 16.04.2021).
