CLAIM – научно-образовательный кластер

 

О проекте

 

Введение

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

Рассмотрим структуру системы SIE, состоящей из уровней:

  1. Структурного
  2. Событийного
  3. Ситуационного
  4. Экспертного

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

Ситуационный уровень на основании данных событийного уровня и определенных экспертом правил осуществляет моделирование бизнес-процессов.


Рисунок1. Структура системы SIE.

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

Алгоритм работы ситуационного модуля

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


Рисунок2. Веб-сервисная оркестровка.

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

  • invoke - в контексте веб-серверной оркестровки - синхронный вызов сервиса;
  • receive - в контексте веб-серверной оркестровки - ожидание ответа сервиса
  • assign - арифметические преобразования данных
  • switch и case - логические переходы между блоками операторов

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

  • invoke - генерация события, запись события в файл
  • receive - ожидание события, поиск записи в файле событий
  • assign - арифметические преобразования данных
  • switch и case - логические переходы между блоками операторов

Рисунок3. Начальная форма программы.

Приведем описание алгоритма работы программы:


Рисунок4. Схема работы программы.
  1. Программа выбирает BPEL-модель процесса для моделирования. Далее осуществляем проход по дереву алгоритма процесса, в ходе которого:
    • Осуществляется поиск сообщения в файле событий, необходимого для запуска процесса, соответствующей модели
    • На основании алгоритма процесса осуществляются преобразования с переменными, поступившими вместе с захваченными сообщениями
    • На основании алгоритма процесса выполняется генерация событий (запись сообщения в файл событий) и их ожидание
  2. По окончанию обхода осуществляется домоделирование подвешенных процессов в связи с генерацией новых событий
  3. По окончанию симуляции, на основании параметров процессов и значений переменных событий вычисляются KPI, на основании задержек сообщений определяются статусы подразделений компании. На основании метрик процессов, значений KPI и статусов подразделений, определяется макроситуация, сложившаяся к концу моделирования)

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


Рисунок5. Параметры процессов, значения KPI, макроситуация.

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


Рисунок6. Статусы подразделений.

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

Значения KPI -ключевых показателей эффективности и макроситуаций определяются на основании правил, введенных экспертом в соответствующие файлы. Файл правил определения kpi хранит деревья, представляющие отдельные показатели, все вершины которых, кроме листьевых представляют арифмитические операции. Файл правил определения ситуаций хранит деревья, все вершины которых, кроме листьевых представляют логические операции И-НЕ.
Примеры файлов входных данных.

Литература

  1. Филиппович А.Ю. Интеграция систем ситуационного, имитационного и экспертного моделирования. – М.: Изд-во "ООО Эликс+", 2003. – 300 с.
  2. Н. Дубова. «На пути к SOA» Открытые системы №9 20/9/2005.
  3. Леонид Черняк. «Мониторинг бизнес-процессов» Открытые системы №10 20/10/2005.
  4. Matjaz Juric «Практическое введение в BPEL» Oracle Magazine №8 20/08/2005.
  5. Олег Гришко «Опыт внедрения Oracle BAM в ЦНИИ Атоминформ» Oracle Magazine №5 20/05/2007.
  6. А. Лоу, В. Кельтон Имитационное моделирование. Изд-во Питер 2004 г.
  7. http://www.xjtek.ru/anylogic/

 © НОК CLAIM. Замечания, вопросы и сведения об ошибках просим сообщать в форуме или присылать администратору сайта.

OZON.ru Rambler's Top100