CC BY
60
функционирование и координацию их деятельности с центральной Платформой КЦДО и другими компаниями, отвечающими за обеспечение технологий дистанционного обучения.
Взаимоотношения между КЦДО и его клиентами и пользователями строятся на договорной основе. Каждый договор определяет количество предоставляемых видов услуг и расценки на них согласно тарифной политике, устанавливаемой КЦДО.
К исключительному ведению Управляющей компании КЦДО относятся:
1) координация деятельности холдинга КЦДО на основе плана стратегического развития технологий дистанционного образования в ЕОИС Российской Федерации;
2) интеграция деятельности КЦДО в мировое образовательное пространство;
3) маркетинговая стратегия и технологи дистанционного обучения;
4) финансовая политика и программа развития КЦДО;
5) тарифная политика;
6) инвестиционная политика;
7) кадровая политика;
8) представление интересов холдинга в международных организациях, органах государственного управления, учреждениях и организациях как в Российской Федерации, так и за рубежом.
Таким образом, изложенное в этой статье предложение по организации КЦДО является вербальным описанием возможного проекта развития в РФ открытых образовательных систем, в основе которых лежат технологии дистанционного обучения и которые, по мнению автора, могли бы вызвать интерес у руководства Минобрнауки РФ и ректоров высших учебных заведений.
УДК 004.896
ФОРМАЛИЗАЦИЯ МЕХАНИЗМОВ ВЗАИМОДЕЙСТВИЯ СЕРВИСОВ И АГЕНТОВ ДИНАМИЧЕСКОЙ ИНТЕЛЛЕКТУАЛЬНОЙ СИСТЕМЫ УПРАВЛЕНИЯ БИЗНЕС-ПРОЦЕССАМИ
Ю. Ф. Тельнов, д. э. н., проф., проректор по научной работе Тел.: (495) 442-71-22, e-mail: [email protected] В. А. Казаков, к. э. н., начальник научно-образовательного центра Тел.: (495) 442-80-98, e-mail: [email protected] А. В. Данилов, ст. преподаватель Тел.: (495) 442-24-90, e-mail: [email protected] Московский государственный университет экономики, статистики и информатики
МЭСИ
http://www.mesi.ru
Работа выполнена при финансовой поддержке РФФИ (проект № 10-07-00672а)
The design features of dynamic intelligent systems for managing business processes based on multi-agent technology and service-oriented architecture are presented in this article. The mechanisms of interaction of the agents that implement the functions of business process management, and services that implement business functions are considered. In particular, ontology-based communication methods are proposed and described.
В статье представляются особенности построения динамической интеллектуальной системы управления бизнес-процессами на основе многоагентных технологий и сервисно-ориентированной архитектуры. Рассматриваются механизмы взаимодействия агентов, реализующих функции управления бизнес-процессами, и сервисов, реализующих бизнес-функции. В частности, предлагаются и описываются способы коммуникации на основе использования онтологии.
Ключевые слова: сервисно-ориентированная архитектура, динамические интеллектуальные системы, многоагентные технологии, бизнес-процессы, онтология.
Keywords: service-oriented architecture, dynamic intelligent systems, multi-agent technology, business processes, ontology.
Введение
В настоящее время в области автоматизации бизнеса все большее распространение получают системы управления бизнес-процессами (СУБП, BPMS - Business Process Management System/Suite), функциональность
которых покрывает задачи управления бизнес-процессами на различных уровнях - от оперативного до стратегического. Основной целью таких систем является обеспечение оптимального уровня показателей бизнес-процесса. Обычно для достижения этой цели в состав таких систем включают инструментарий, который позволяет предварительно спроектировать процесс, оперативно контролировать ход выполнения процесса в соответствии с запроектированной моделью, формировать заданные показатели процесса и анализировать их с целью улучшения процесса.
Главными факторами, определяющими интерес со стороны бизнеса к СУБП, являются направленность на интеграцию отдельных задач в единый автоматизированный бизнес-процесс и ориентация на задачи ме-
неджмен-та - планирование (проектирование) бизнес-процесса и анализ результатов.
В то же время, несмотря на относительную молодость направления СУБП, данный класс систем находится под пристальным вниманием и критикой со стороны ИТ-сообщества и бизнеса и постоянно развивается. К основным недостаткам, свойственным в настоящее время большинству решений, относятся:
• высокая стоимость традиционных СУБП;
• недостаточная гибкость архитектуры, связанная с ориентацией на инструментарий од-
ного вендора и отсутствием единых стандартов построения таких систем;
• недостаточность механизмов динамического изменения предварительно построенной модели бизнес-процесса непосредственно на этапе выполнения.
В целом эти недостатки наиболее критичны для инновационных и неустоявшихся процессов, свойственных малым и средним предприятиям, и менее критичны для крупных предприятий, процессам которых свойственны строгая регламентация и меньшая динамика изменений. Поэтому в настоящее время появились различные альтернативные тенденции в вопросе построения СУБП, в том числе ориентация на сервисную модель (SaaS), построение структуры процесса в ходе его выполнения на основе предварительно определенных компонентов, отражающих накопленный ранее опыт, и другие решения.
Динамическая организация бизнес-процесса отличается от статической зависимостью способа реализации и структуры биз-
нес-процесса от текущей ситуа-
ции, имеющихся ресурсов и поставленных целей. В значительной степени при этом возрастает ответственность владельца процесса, который на основе изменяющихся входных и выходных параметров должен иметь возможность динамически изменять состав функций и исполнителей бизнес-процесса. Для ускорения, повышения качества этой работы необходимо использовать интеллектуальные средства, позволяющие в режиме реального времени интегрировать информацию о бизнес-процессах, целях и ресурсах, моделировать процесс принятия решений.
Учитывая вовлеченность в бизнес-процесс специалистов различных направлений, в том числе и управляющих процессом, в качестве основы архитектуры динамической интеллектуальной системы была взята архитектура многоагентной системы (МАС), где каждому специалисту соответствует свой интеллектуальный агент. Агенты здесь вы-
ступают в качестве активных сущностей, управляющих и выполняющих бизнес-процесс. Агент моделирует поведение реального владельца процесса, исполнителей бизнес-процессов и при необходимости может быть заменен реальным агентом-человеком, т. е. система оставляет возможность принятия решений человеком-экспертом.
Основной задачей при построении СУБП является увеличение динамичности системы за счет внедрения в нее средств интеллектуального анализа и оперативного принятия решений по изменению структуры процесса для обеспечения достижения заданных целей и выполнения ограничений. Обеспечение заданного результата бизнес-процесса обусловливает необходимость получения промежуточных результатов (как материальных, так и информационных или финансовых), выходов отдельных подпроцессов или бизнес-функций, входящих в состав бизнес-процессов. Такие самостоятельные компоненты, обеспечивающие некоторый продукт или предоставляющие некоторую услугу, в терминах сервисноориентированной архитектуры (СОА) называются сервисами. В таком случае выполнение бизнес-процесса означает последовательное инициирование и получение результатов независимых сервисов, предоставляемых как внутренними, так и внешними поставщиками услуг.
В рамках СУБП исполняемые сервисы хранятся в информационной базе. При этом агенты могут их обнаружить и при необходимости использовать (инициировать и получить результат) в режиме реального времени. Таким образом, обеспечивается динамическое объединение сервисов в исполняемые бизнес-процессы. Однако для взаимодействия агентов и сервисов требуется наличие единого стандарта, языка, описывающего проблемную область и задачи управления бизнес-процессами. В качестве такого средства используется онтология, которая также выступает как архитектурная основа МАС и СОА [1].
В данной статье рассматриваются механизмы взаимодействия элементов динамической интеллектуальной системы управления бизнес-процессами, построенной на основе
многоагентных технологий и сервисноориентированной архитектуры. Их использование обеспечит построение СУБП, способной во время выполнения процесса оперативно анализировать текущую ситуацию, вырабатывать и реализовывать решения как по изменению структуры и параметров процесса, так и по выполнению отдельных функций на основе подбора и выполнения соответствующих сервисов, существующих в открытой среде.
1. Принципы управления динамическими бизнес-процессами на основе многоагентной системы
Принципы управления бизнес-процессами подразумевают наличие единого ответственного за результат, выход процесса. Таким ответственным является владелец процесса, которому в СУБП соответствует агент «Владелец процесса». Типичными задачами такого агента, осуществляющего ди-
Рис. 1. Задачи управления бизнес-процессами агента «Владелец процесса»
намическое управление в многоагентной системе, являются планирование бизнес-процесса, мониторинг его выполнения и динамическая корректировка структуры исполняемого процесса (рис. 1):
• В СУБП планирование выполнения экземпляра процесса выполняется в два шага:
о на первом шаге агентом определяются основные параметры процесса, способ реализации и его структура. На этом шаге определяются необходимые для получения конечного результата промежуточные продукты и услуги, а также бизнес-функции, которые позволяют их получить. Кроме того, для фор-
мирования структуры могут использоваться готовые шаблоны (модели процесса); о на втором шаге, при необходимости, в соответствии с поставленными целями и решаемыми задачами осуществляется подбор агентов-исполнителей, выставление и согласование задач. На этом шаге осуществляется взаимодействие агентов в рамках системы, делегирование задач и закрепление ответственности в соответствии с характеристиками агента.
• Мониторинг показателей бизнес-процесса в режиме реального времени также является текущей задачей агента «Владелец процесса». При необходимости агент может запросить детальную информацию о выполнении бизнес-функций у агентов-исполнителей, в обязанности которых входит контроль предоставления отдельных сервисов и уведомление об отклонениях показателей бизнес-процесса от запланированных значений.
• Перепланирование выполнения экземпляра процесса проводится в случае отклонения значений показателей бизнес-процесса от ранее запланированных значений, изменении исходных данных или состояния среды. Перепланирование может проводиться на любом этапе выполнения процесса, а исходными данными для него служат результаты мониторинга и сигналы внешней среды, что позволяет обеспечить необходимое качество результатов бизнес-процессов.
Объектом управления агента «Владелец процесса» является модель бизнес-процесса, содержащая:
• информацию о последовательности выполняемых работ;
• требования и ограничения всего процесса и его отдельных функций;
• спецификацию требований к входной и выходной информации.
Анализ, формирование и корректировка модели - основные задачи агента «Владелец процесса». В ходе реализации процесса агент-исполнитель использует содержащееся в модели описание бизнес-функции, выполнение которой лежит в его зоне ответственности, как постановку задачи и формирует базу оперативных данных процесса.
Эти данные используются агентом «Владелец процесса» для принятия решений.
Структура репозитория бизнес-процессов, содержащего описания моделей, представлена на рис. 2.
В ходе планирования процесса агент «Владелец процесса» определяет взаимосвя-
действующими функциями, оцениваемыми показателями эффективности, устанавливает цели процесса. При этом общие цели, характерные для всех бизнес-процессов, устанавливаются пользователями системы и варьируются в зависимости от потребностей бизнеса. Таким образом, на первом этапе агент дополняет репозиторий бизнес-процессов описанием новой исполняемой модели бизнес-процесса.
На этапах 2 и 3 агент использует данные, содержащиеся в репозитории, для назначения ответственных агентов-
исполнителей, мониторинга выполнения экземпляра процесса. На этапе 4 агент обновляет описание модели в репозитории или, используя ту же модель бизнес-процесса, проводит замену агентов-исполнителей.
Реализация указанных задач предполагает активное взаимодействие агентов друг с другом и с сервисами, а также вывод и принятие решений на основе собственной базы знаний и репозитория бизнес-процессов. Онтология при этом обеспечивает единый словарь предметной области и правил построения процесса. Принципы динамического управления бизнес-процессами на основе использования онтологии представлены на рис. 3:
зи между компонентами процесса, взаимо-
Рис. 2. Структура репозитория бизнес-процессов
• На основе данных онтологии агент «Владелец процесса» классифицирует поступивший запрос и определяет бизнес-процесс, который необходимо выполнить. В соответствии с шаблоном описания бизнес-процесса агент выявляет основные требования и целевые показатели процесса.
• Описание модели бизнес-процесса в репозитории осуществляется агентом «Владелец
• процесса» в терминах онтологии бизнес-процессов, что позволяет однозначно сопоставить параметры и структуру процесса. На этапе планирования в репозиторий вносятся данные по выполняемым функциям, описанные в терминах онтологии.
Задание на выполнение
Агент: исполнитель Функции БП
Рис.
3. Концепция динамического управления бизнес-процессами
• Агенты-исполнители, получившие задание на исполнение, описанное в терминах онтологии, имеют одинаковое с агентом «Владелец процесса» понимание структуры процесса и решаемой задачи. Точность понимания задачи позволяет искать и отбирать сервисы, которые полностью соответствуют поставленным целям.
• Использование описанных в терминах общей онтологии результатов мониторинга выполняемых сервисов позволяет принимать объективные решения по изменению структуры процесса.
2. Взаимодействие сервисов и агентов в системе управления бизнес-процессами
Сервисно-ориентированная архитектура позволяет использовать функциональность внешних систем при решении отдельных задач бизнес-процесса. При этом решение задачи, выполнение бизнес-функции может быть передано различным поставщикам независимых сервисов.
Одним из ключевых элементов в реализации подобной архитектуры является реестр сервисов UDDI [2]. Реестр используется для целей классификации, каталогизации и
управления сервисами, с тем чтобы они могли быть обнаружены и использованы в рамках того или иного бизнес-процесса. Реестр UDDI представляет собой структурированное описание информации и метаданных о сервисах, что позволяет агентам или экспертам осуществлять поиск сервисов по ключевым словам и типам, обнаруживать поставщиков сервисов определенного типа, определять модели взаимодействия и использовать техническую информацию о сервисе, описывающую параметры и протоколы взаимодействия.
Представленный в формате XML реестр UDDI имеет четыре основных структуры (раздела), взаимосвязанных и определяющих свойства и характеристики сервиса:
• businessEntity - «бизнес-структура» - определяет область деятельности, название, контакты и описание поставщика сервиса;
• businessService - «бизнес-сервис» - определяет название, описание, вид сервиса;
• bindingTemplate - «представление сервиса» - определяет описание, точку доступа и вид представления сервиса;
• tModels - «модель доступа» - определяет название модели доступа, технические параметры взаимодействия, форматы данных и т. д.
Взаимосвязь разделов реестра и их содержание показаны на рис. 4 [2].
Для дополнительного описания сервисов в UDDI могут использоваться параметры identifierBag и categoryBag. Эти параметры представляют собой расширяемый набор свойств поставщиков сервисов и самих сервисов, связь с различными (в т. ч. внешними) классификаторами (ИНН, место расположения, отрасль). С помощью указанных параметров возможна классификация и дальнейший отбор сервисов, например, по отрасли или типу решаемых задач.
Семантические описания сервисов соответствуют описанию функциональности, которую реализуют указанные сервисы. Описания также содержат структурированное представление информации о сервисе, его результатах, параметрах взаимодействия с ним в терминах онтологии сервисов [3].
Реестр UDDI может находиться в закрытой части корпоративной информационной системы или быть общедоступным и иметь ссылки на семантические описания сервисов, размещенные в глобальной сети и привязанные к ресурсу поставщика сервиса. Для реа-
лизации поставленных задач реестр UDDI должен быть организован таким образом, чтобы описания сервисов в нем соотносились с семантическими описаниями и использовали единую терминологию. Таким образом, с помощью онтологии и реестра
UDDI возможно описать семантику сервисов, а также обеспечить централизованное хранение сведений об имеющихся (зарегистрированных) сервисах и интеллектуальный подбор необходимого сервиса.
ПОСТАВЩИК СЕРВИСА
БИЗНЕС-СЕРВИС (БС}
ПРЕДСТАВЛЕНИЕ БС
МОДЕЛЬ ДОСТУПА К БС
^иййкоиегиіеїлгОос [+]
—-у- —уЛ 0..®
^иййічсІепШегВад \+\ ^исІйксаІедогуВад [+]
^(ІзідіЗідпаІиге [+]
■ ■■■■■■■■■ .уп1 о..®
Рис. 4. Структура реестра UDDI
Агент-исполнитель, используя онтоло- вис, обращаться к нему для решения задачи,
гию и данные реестра, сможет подбирать как это показано на рис. 5.
наиболее подходящий и эффективный серп ^ ^
Рис. 5. Взаимодействие агентов и сервисов на основе онтологии
В настоящее время процедура отбора • на основе требований к сервису форми-
сервисов выполняется экспертом по сле-
дующему алгоритму:
• на основе бизнес-потребностей уточняются требования к сервису;
руется запрос к поисковым системам;
• отбираются и просматриваются вебстраницы с размещенными ссылками на сервисы;
• по завершении отбора сервис выполняется и проверяется (на соответствие требованиям) также вручную и самостоятельно экспертом.
Реализация в СУБП поискового механизма, автоматизирующего рутинные операции и оценку релевантности результатов поиска сервисов на основе онтологии и данных реестра UDDI, позволит в значительной степени сократить время на подбор сервисов, адекватных предъявляемым требованиям.
3. Алгоритмизация поиска и выбора сервисов
Для обеспечения поиска и выбора сервисов в СУБП предполагается наличие ряда встроенных механизмов, реализующих:
• формализацию и разбор запросов на основе онтологии;
• вывод на основе продукций (дедуктивный, индуктивный и абдуктивный вывод), позволяющий формировать модель процесса, анализировать данные, принимать решения;
• оценку семантической близости терминов в онтологии;
• оценку качества сервисов [4].
При этом алгоритм поиска и выбора сервисов предполагает выполнение следующей последовательности шагов:
Клиент (пользователь системы или агент)
3.1. С использованием онтологии клиентом бизнес-процесса формируется запрос на реализацию некоторого бизнес-процесса (получение некоторого результата) с установленными критериями эффективности и результативности (например, время выполнения, минимизация совокупной стоимости владения результатами закупки), сформулированными в виде ограничений.
Агент «Владелец процесса»
3.2. Агент получает от пользователя (или другого агента) запрос на формирование некоторого результата с установленными критериями и характеристиками.
3.3. Агент создает новую модель бизнес-процесса в репозитории для планируемого экземпляра бизнес-процесса на основе шаблона (описания бизнес-процесса, соответствующего запросу и имеющего выходом необходимый результат) и с учетом потребностей клиента.
3.4. В случае комплексности решаемой задачи агент на основе данных, поступивших от пользователя, онтологии бизнес-процессов и содержащихся в репозитории моделей бизнес-процессов декомпозирует процесс до уровня бизнес-функций.
3.5. Агент делегирует задачи, которые не могут быть реализованы силами самого агента (переход на шаг 3.6), также агент осуществляет запросы на предоставление
необходимых входных данных (переход на шаг 3.1).
3.6. На основе модели бизнес-процесса, содержащейся в репозитории, агент формирует запросы на выполнение бизнес-функций, которые передаются агентам-исполнителям системы управления бизнес-процессами;
Агент-исполнитель
3.7. Агент получает запрос на реализацию бизнес-функции, описанный в терминах онтологии сервисов.
3.8. Для обнаружения сервиса, реализующего указанную бизнес-функцию, агент формирует запрос к UDDI с использованием онтологии через имеющиеся интерфейсы UDDI API, которые позволяют найти сервисы нужного поставщика, нужной области/отрасли, связанные по принципу поставщики - потребители, или похожие сервисы.
3.9. После обнаружения сервиса/сер -висов агент осуществляет перебор описаний сервисов в реестре UDDI и переход по ссылке к семантическому описанию сервиса в глобальной сети.
3.10. Агент рассматривает семантическое описание сервиса и на основе методов оценки семантической близости обеспечивает сопоставление терминов, используемых агентами в СУБП и разработчиком сервиса в семантическом описании.
3.11. Агент анализирует функциональный раздел семантического описания (functionality description) с точки зрения его соответствия модели бизнес-процесса и описанию бизнес-функции в репозитории, при этом используются методы оценки семантической близости параметров бизнес-функции и сервиса.
3.12. Агент рассматривает варианты поставщиков и сервисов, подходящих для получения заданного результата, с точки зрения их рейтинга, опыта работы, имеющейся оценки качества результатов.
Агент «Владелец процесса»
3.13. Агент получает информацию о выбранном сервисе от агента-исполнителя.
3.14. Для формирования цепочки сервисов агент с использованием механизмов вывода подбирает сервисы, сопоставимые по входу-выходу, которые могут взаимодействовать друг с другом:
о на первом этапе рассматривается функциональный раздел семантического описания сервиса (functionality description) и по результатам оценки семантической близости определяется возможность взаимодействия двух связанных сервисов на уровне
понятий (сущностей). В случае выявления противоречий осуществляется подбор нового сервиса.
о на втором этапе рассматривается раздел tModel и по результатам оценки технических параметров сервисов, описания интерфейсов определяется возможность взаимодействия на уровне данных (формата данных). В случае выявления противоречий осуществляется подбор нового сервиса или добавление промежуточных сервисов-конвертеров, осуществляется самостоятельная конвертация данных.
3.15. Агент рассматривает затраты на выполнение последовательности сервисов на предмет соответствия системе ограничений:
где N - число сервисов, ^ -время выполнения /'-го сервиса, с/ - стоимость /-го сервиса, Т -ограничение по времени на выполнение процесса, С - бюджет процесса.
3.16. Агент принимает решение об
использовании данного сервиса и передает соответствующую информацию агенту-
исполнителю либо повторяет запрос на подбор сервиса (переход на шаг 3.6).
4. Контроль выполнения и перепланирование бизнес-процесса
Отобранные для выполнения бизнес-функций или всего бизнес-процесса сервисы необходимо контролировать, чтобы обеспечить агента «Владелец процесса» и клиентов процесса необходимой информацией о ходе реализации процесса и возможных проблемах, а также гарантировать согласованный уровень отдельных сервисов [5]. Для обеспечения заданного уровня сервиса в системе управления бизнес-процессами реализуется следующий алгоритм:
Агент-исполнитель
4.1. Агент получает данные о ходе выполнения некоторой бизнес-функции и контролирует согласованные показатели сервиса в режиме реального времени.
4.2. Агент получает данные о текущем состоянии среды реализации сервиса и анализирует их.
4.3. В случае неполадок отдельного сервиса, влекущих отклонение показателей сервиса и не влияющих на показатели бизнес-процесса, агент принимает решение о
Литература
замене сервиса или воздействии на среду.
4.4. В случае влияния неполадок отдельного сервиса или состояния среды на показатели бизнес-процесса в целом агент передает полученную информацию агенту «Владелец процесса».
Агент «Владелец процесса»
4.5. Агент собирает данные о критических отклонениях показателей сервисов и бизнес-процесса от агентов-исполнителей.
4.6. В случае неполадок отдельного сервиса, влекущих отклонения показателей сервиса и бизнес-процесса в целом, агент принимает решение о замене сервиса и информирует об этом агента-исполнителя (переход на шаг 3.6);
4.7. В случае неполадок нескольких сервисов агент может завершить и перепроектировать весь бизнес-процесс (переход на шаг 3.3).
4.8. Агент сохраняет историю модификации модели бизнес-процесса в репозитории.
Заключение
Использование многоагентных технологий и сервисно-ориентированных архитектур в управлении бизнес-процессами обеспечивает исполнение и качество инновационных динамических процессов. Наличие интеллектуальных средств позволяет динамической интеллектуальной системе управления бизнес-процессами формировать последова-
тельность выполняемых сервисов на всех этапах управления процессами: во время планирования, непосредственно в ходе реализации и на этапе корректировки модели бизнес-процесса.
Для повышения качества совместной работы агентов и сервисов в рамках системы управления бизнес-процессами предложена модель взаимодействия, основанная на использовании общей онтологии. Ключевым элементом системы с точки зрения авторов является семантическое описание функциональности и параметров сервисов, позволяющее однозначно сопоставить бизнес-процессы, бизнес-функции, их параметры и характеристики сервисов, повысить скорость и качество формируемой цепочки исполняемых сервисов.
Zi=i ti<T
N
Ъ<с
¿=1
1. Данилов А. В., Казаков В. А., Тельнов Ю. Ф. Сервисно-ориентированная архитектура динамической интеллектуальной системы управления бизнес-процессами // Открытое образование, 2010. № 6. С.78-84
2. UDDI Version 3.0.2. http://uddi.org/pubs/uddi_v3.htm.
3. OWL-S: Semantic Markup for Web Services. http://www.w3.org/Submission/OWL-S.
4. Казаков В. А. Использование динамической интеллектуальной системы в управлении закупками // Реинжиниринг бизнес-процессов на основе современных информационных технологий. Системы управления знаниями (РБП-СУЗ-2011): Материалы XIV научно-практической конференции. - М.: МЭ-СИ, 2011.
5. Павлова Е. В. Контроль облачных сервисов на базе многоагентных технологий // Открытое образование, 2011. № 3. С. 37-41.
УДК 681.3.06 (075.32)
НЕКОТОРЫЕ ПОДХОДЫ К СИТУАЦИОННОМУ АНАЛИЗУ
ПОТОКОВ СОБЫТИЙ
А. А. Зацаринный, д. т. н., заместитель директора института Тел.: (499) 137-60-31, e-mail: [email protected] А. П. Сучков, д. т. н., ведущий научный сотрудник Тел.: (499) 135-88-01, e-mail: [email protected] Институт проблем информатики РАН http://www.ipiran.ru
Formalization methods of events streams monitoring data and ways of their analysis are discussed in the article. The authors suggest using integral criteria of current situation, based on incoming information about changes of situation elements. The range of analytical problems, methods of their solution, tendencies and anomalies determination in events streams based on statistics data models creation and prediction of its development are substantiated.
В статье обсуждаются методы формализации данных мониторинга потоков событий в контролируемом пространстве и способы их анализа. Предлагается использовать интегральные показатели состояния обстановки, формируемые на основе поступающих данных об изменении элементов обстановки. Обосновывается круг аналитических задач и методов их решения с использованием статистических моделей данных и выявления на их основе тенденций и аномалий в потоках событий, а также прогнозирования их развития.
Ключевые слова: ситуационный анализ, системы управления, мониторинг, информационные технологии.
Key words: Situational Analysis, control systems, monitoring, information technology
Введение
Ситуационный анализ, реализующий процессы поддержки принятия решений в системах управления, опирается на такие понятия, как событие, обстановка, ситуация, угроза, управление. Ситуация определяется со-
стоянием взаимосвязанных элементов обстановки в контролируемом пространстве; изменения обстановки определяются событиями, образующими некоторые разворачивающиеся во времени, наблюдаемые и
регистрируемые потоки. При этом под управлением понимается целенаправленное воздействие органа управления на подчиненные ему или взаимодействующие элементы обста-
новки (ресурсы).
Совокупность ситуаций в системе управления распадается на текущие, прогнозируемые и целевые ситуации. При этом текущие ситуации являются результатом наблюдения и регистрации событий, прогнозируемые - определяются методами ситуационного анализа, а целевые - отражают краткосрочные,
