ТЕХНОЛОГИИ ПРОАКТИВНОГО УПРАВЛЕНИЯ СЛОЖНЫМИ ОБЪЕКТАМИ
УДК 519.8
С. А. Потрясаев
СИНТЕЗ СЦЕНАРИЕВ МОДЕЛИРОВАНИЯ СТРУКТУРНОЙ ДИНАМИКИ АСУ АКТИВНЫМИ ПОДВИЖНЫМИ ОБЪЕКТАМИ
Проанализированы возможные технологии синтеза сценариев моделирования структурной динамики АСУ активными подвижными объектами. Предложено при практической реализации сценариев использовать сервис-ориентированный подход, рассмотрена возможная структура соответствующего программно-математического обеспечения.
Ключевые слова: комплексное моделирование, технологии синтеза сценариев моделирования, сервис-ориентированный подход.
Введение. На базе концепции комплексного моделирования [1—2], которая, как показывает практика, может быть успешно реализована в рамках соответствующей имитационной системы, к настоящему времени решен широкий спектр задач анализа и синтеза автоматизированных систем управления (АСУ) группировками активных подвижных объектов (АПО). При исследовании различных прикладных задач важная роль в указанных системах отводится разработке специальных сценариев интерактивного взаимодействия лиц, принимающих решения, с имитационными системами. В настоящей статье рассматриваются особенности создания программно-математического обеспечения синтеза сценариев моделирования АСУ активными подвижными объектами на различных этапах их жизненного цикла.
Технологии синтеза сценариев моделирования структурной динамики АСУ АПО. Рассмотрим некоторые возможные сценарии моделирования процессов управления структурной динамикой АСУ АПО. Предположим, что обобщенное полимодальное многокритериальное описание задач управления структурной динамикой АСУ АПО имеет следующий вид [2—4]:
I(х(г), и(г), ), г) ^ ех1г; (1)
иеА
А = {и | х(г) = ф (х(г), и(г), \(г), р, г), у (г) = ¥ (х(г), и(г), \ (г), р, г),
х(То) е Хо(р), х(7>) е хг (р), и(г) е 0 (х(г), г), $(г) е Е(х(г), г), р е Вх(г) е XX(г)}, (2)
т
где I(х( г), и( г), £( г), г) = I _, 10, I, I р, I п, I е , I с , I — вектор показателей эффективности
р?"п-> е-> с-> у \Т 1Т
'р' п >"е'"с > "V
функционирования АСУ АПО; II, IТа, I\, Iр, IТп, IТе , IТс , IV — соответственно векторы
показателей эффективности управления движением, операциями взаимодействия, каналами, ресурсами, потоками, параметрами операции, структурами, вспомогательными операциями в АСУ АПО; индексы „£■", „о", „к", „р", „п", „с", „е", „у" указанных векторов обозначают соответствующие модели управления (Ыё, Мо, Мк, Мр, Мп, Ме, Мс, Му); х(£), у(^) — соответственно обобщенные векторы состояния и выходных характеристик динамической системы, описывающей процессы управления структурной динамикой АСУ АПО; и(^) — обобщенный вектор управляющих воздействий, £,(?) — обобщенный вектор возмущающих воздействий; Р — вектор структурных параметров (характеристик) АСУ АПО, определяющих ее облик; @(х(?),?), Е(х(0,0, В — заданные области изменений значений векторов и(^), Р; Х0(Р), Х'(Р), X (^) — заданные области изменений значений вектора х(^) соответственно в начальный, конечный и текущий моменты времени.
В выражении (2) переходная и выходная функции ф (х(^), и(^), \(1,), в, ^) и у (х(^), и(^), ^), в, I) в общем случае задаются в аналитико-алгоритмическом (имитационном) виде в рамках имитационной системы. Именно возможные варианты описания и реализации указанных функций (в более общем случае — операторов) определяют содержание методов и алгоритмов, которые могут быть положены в основу построения процедур получения скоординированных решений в задачах управления структурной динамикой АСУ АПО.
В рамках ранее выполненных исследований [2—4] указанные переходная и выходная функции задавались с использованием разработанного комплекса динамических моделей, а также соответствующего специального программного обеспечения, содержащего набор следующих программных модулей (ПМ):
„Координация" — программный модуль многокритериального анализа и упорядочения вариантов функционирования АСУ АПО при различных сценариях изменения обстановки и внешних воздействий;
„Надежность" — программный модуль расчета и многокритериального анализа показателей структурной надежности и устойчивости АСУ АПО;
„Расписание" — программный модуль расчета плана функционирования наземного комплекса управления АПО, а также расчета показателей пропускной способности, оперативности и ресурсоемкости АСУ АПО для детерминированных сценариев изменения внешних воздействий;
„Устойчивость" — программный модуль расчета и оптимизации показателей робаст-ности и динамической устойчивости программ функционирования АСУ АПО для интерваль-но заданных сценариев изменения внешних воздействий;
„Пропускная способность" — программный модуль расчета показателей пропускной способности и ресурсоемкости АСУ АПО для стохастических сценариев изменения внешних воздействий;
„Эффективность" — программный модуль расчета показателей эффективности функционирования АСУ АПО для стохастических сценариев изменения внешних воздействий.
Применительно к разработанной версии специального программного обеспечения в табл. 1 указаны (отмечены знаком „+") классы моделей (аналитических или имитационных) АСУ АПО, которые были использованы для описания соответствующей подсистемы рассматриваемой АСУ.
Для многокритериального оценивания и упорядочения возможных сценариев функционирования АСУ АПО в штатных и заданных условиях ее применения разработана соответствующая методика формирования и расчета интегрального показателя качества и эффективности работы системы, базирующаяся на комбинированном использовании математического аппарата нечеткой логики и теории планирования эксперимента.
Таблица 1
Тип модели подсистемы АСУ АПО Модели, реализованные в составе ПМ
„Надежность" ,.Расписание" „Устойчивость" „Пропускная способность" „Эффективность"
АМ ИМ АМ ИМ АМ ИМ АМ ИМ АМ ИМ
АИМ тракта ТМИ + - + - + - - + + -
АИМ тракта ИТНП + + + - + - - + + -
АИМ тракта КПИ + - + - + - - + + -
АИМ тракта СИ + - + - + - - + + -
АИМ ЦУП АПО + - + - + + - + + -
АИМ СОД + - + - + - - + + -
АИМ внешней среды + + - - + + - + + -
Примечания: АИМ — аналитико-имитационная модель, АМ — аналитическая модель, ИМ — имитационная модель, ТМИ — телеметрическая информация, ИТНП — измерения текущих навигационных параметров, КПИ — командно-программная информация, СИ — специальная информация, ЦУП — центр управления полетом, СОД — система обмена данными.
К настоящему времени разработаны многочисленные подходы, способы, методы, алгоритмы и методики координационного анализа и выбора комплексов разнородных моделей, описывающих различные предметные области. В табл. 2 приведены возможные варианты взаимодействия частных программных модулей разработанного полимодельного комплекса для решения задач управления структурной динамикой АСУ АПО [2, 5].
Таблица 2
Процедура решения задачи Модель задачи
fo(a) ^extr д(a) fo(a) ^ extr д(u) f0(a) ^ extr J0 Д(a) пД fo(u) ^ extr Д(a) /о(и ) Д(") f0(") ^ extr J0 д(-) пД(")
АОМ^-АР^-К /К 1 +
ИОМ^- АР ^К /К 1 + + +
* 1 АОМ^-ИОМ^- АР ^К А 1 + +
* 1 (АОМсИОМ)^- АР ^К +
* 1 (ИОМсАОМ)^- АР ^К t 1 + + +
f AOMj ^ и ИОМ ^ АР 1 aOM2 , t ^К + + +
Примечания: АОМ — аналитическая оптимизационная модель; ИОМ — имитационная оптимизационная модель; АР — анализ полученных результатов (проводимый автоматически, либо с привлечением ЛИР); К — коррекция полученных решений; Д(а), Д(м) — множества (либо подмножества) допустимых альтернатив вида (2),
заданных соответственно аналитически и алгоритмически; f(a\ f0(" ) — обобщенные показатели эффективности функционирования АСУ АПО, заданные соответственно аналитически и алгоритмически [3—5].
Указанные в табл. 2 возможные схемы координации (согласования) моделей и показателей f(а), /0(м) различаются способами генерации допустимых альтернативных решений;
правилами проверки алгоритмически и аналитически заданных ограничений; способами перехода от одного шага интерактивного сужения множества допустимых альтернатив к другому шагу; алгоритмами взаимодействия с внешними системами (внешней средой), т.е. системами, не входящими в состав АСУ АПО, но оказывающими на нее влияние. Данное взаимодействие может иметь как индифферентный характер (например, объекты живой и неживой природы), так и целенаправленный.
В рамках существующих имитационных систем выбор той или иной схемы координации (см. табл. 2) осуществляется, как правило, в интерактивном режиме с обязательным участием соответствующих ЛПР. Для этого должны быть синтезированы возможные сценарии человеко-машинного взаимодействия ЛПР с имитационной системой, а также разработано соответствующее специальное программно-математическое обеспечение (СПМО). Остановимся на возможных подходах к решению задач формирования сценариев.
Программно-математическое обеспечение формирования сценариев моделирования. Предлагаемое модульное построение программно-математического обеспечения имитационных систем позволяет с помощью относительно небольшого количества вычислительных модулей построить множество вычислительных программ (совокупности вычислительных модулей) для моделирования как АПО, так и АСУ АПО в целом с различной степенью детализации в рамках одной и той же системы.
Как показывает предварительный анализ, на этапе практической реализации имитационной системы может возникнуть ряд трудностей, связанных, во-первых, с существенной гетерогенностью создаваемого СПМО и, во-вторых, с организацией взаимодействия между вычислительными модулями. Перечисленные выше программные модули будут содержать унаследованные программные подсистемы, представленные в виде законченных решений (например, стандартных процедур-функций), прошедших валидацию и верификацию. Такие подсистемы планируется использовать в ПМ „Надежность", „Планирование", „Эффективность". Разработка подобных подсистем „с нуля" представляет собой экономически невыгодный процесс как по трудозатратам, так и по времени выполнения проекта. В связи с этим необходимо в рамках имитационной системы синтезировать такие сценарии взаимодействия программных модулей, чтобы обеспечить между ними беспрепятственный обмен согласованными исходными данными и выходными результатами при решении различных классов задач анализа и синтеза АСУ АПО.
Наиболее хорошо зарекомендовавшим себя подходом к построению модульных систем на сегодняшний день является сервис-ориентированная архитектура (Service Oriented Architecture — SOA) [6—8]. Данный подход эффективен при слабой связности и распределенности используемых модулей, но требует в то же время использования стандартизированных интерфейсов модулей и работы по стандартизированным протоколам, что не было реализовано в унаследованных программных продуктах. При этом СПМО формирования сценариев, в терминах предлагаемой сервис-ориентированной архитектуры, соответствует программному обеспечению сервисной шины предприятия (Enterprise Service Bus — ESB) [6] и будет базироваться на свободно распространяемом программном каркасе Zato, который предоставляет разработчикам программного обеспечения возможность быстрого проектирования сервера приложений, реализующего сервисную шину предприятия [6—8].
С учетом указанных выше особенностей используемых унаследованных программных продуктов предлагается следующий вариант сервис-ориентированной архитектуры имитационной системы (см. рисунок).
Предлагаемая сервис-ориентированная архитектура позволяет перевести разрабатываемую программную имитационную систему в формат „облачного" приложения, реализуемого
как сервис (Software as a Service — SaaS). Следствием перехода к облачным вычислениям является существенное повышение гибкости аппаратно-программной реализации. В частности, создаваемый программный комплекс может быть значительно распределен территориально и структурно, т. е. может быть реализован на базе вычислительных мощностей, принадлежащих разным организациям, в том числе находящимся в разных городах и странах. При этом синтезированная система, с точки зрения конечного пользователя, будет функционировать как целостное решение.
Авторизированный пользователь
Веб-портал
Сценарии функционирования
Модуль „Координация"
Модуль „Устойчивость"
Модуль „Пропускная способность"
состояние
Модуль Резервирование"
Модуль „Эффективность"
Отказоустойчивая система хранения данных
При объединении веб-сервисов в целях создания высокоуровневого приложения необходима стандартизация моделей их взаимодействия. Для стандартизации интерфейсов взаимодействия программных модулей, входящих в состав АСУ АПО, планируется использовать язык описания веб-сервисов WSDL (Web Services Description Language). Это язык, который описывает веб-сервис как набор конечных точек (портов), способных обмениваться сообщениями. WSDL служит для документирования и комплексного определения деталей взаимодействия распределенных систем в виде, удобном для машинной обработки.
Детальный анализ существующих технологий взаимодействия веб-сервисов показал, что при ориентации на интеграцию со сторонними системами наиболее строгим и перспективным для использования протоколом является SOAP.
Следует также заметить, что стандартизация моделей взаимодействия веб-сервисов не определяет логику работы программного комплекса. Для этих целей используются язык описания последовательности действий и инфраструктура для его реализации. В качестве такого языка целесообразно ориентироваться на стандарт моделирования последовательности взаимодействий веб-сервисов — язык Business Process Execution Language. В мае 2003 г. компании Microsoft, IBM, Siebel, BEA Systems и SAP совместно разработали первую версию спецификации этого языка для Web-Services (BPEL4WS или WS-BPEL) [9]. Указанная спецификация описывает язык, позволяющий моделировать поведение веб-сервисов при взаимодействии бизнес-процессов. Регламентируемый спецификацией механизм позволяет
Виртуализация
Отказоустойчивый пул аппаратных ■ ■ ■
координировать вычислительные процессы и компенсировать возникающие ошибки. Таким образом, рассмотренный выше язык WSDL определяет список возможных операций, а WS-BPEL задает порядок их выполнения. Спецификация поддерживает как структурные действия для управления потоком работ, так и базовые действия, которые включают взаимодействия с внешними веб-сервисами. Структурные действия определяют последовательность вызова веб-сервисов, а также поддерживают выполнение циклов и динамическое ветвление. По существу, они составляют основную логику программирования на WS-BPEL. Переменные используются для управления долговременным хранением данных в ходе обработки запросов веб-сервисов.
За последнее десятилетие WS-BPEL зарекомендовал себя как эффективный язык для описания логики работы приложений, основанных на распределенных веб-сервисах. Высокая частота его использования в современных распределенных приложениях, а также поддержка в различных программных средах исполнения позволяют обосновать целесообразность применения WS-BPEL в создаваемом программном комплексе [9].
Таким образом, синтез программной системы многокритериального оценивания и анализа показателей надежности и эффективности АСУ АПО на различных этапах жизненного цикла планируется осуществлять с помощью взаимодействия отдельных модулей программного комплекса на основе инструкций, описанных на языке WS-BPEL. При этом в дальнейшем планируется с использованием данного языка создать интеллектуальный интерфейс, базирующийся на результатах ранее выполненных исследований, основанных на динамической интерпретации процессов выполнения комплексов операций и синхронизированных с ними процессов получения/передачи, обработки, хранения и представления данных об АПО и АСУ АПО в целом. Использование интеллектуального интерфейса позволит пользователям не только описывать сценарии взаимодействия программных модулей, но и синтезировать данные сценарии, исходя из поставленной цели исследования. Указанные задачи могут быть решены в разрабатываемом ПМ „Координация".
Заключение. Предложенная архитектура имитационной системы позволяет:
— для преодоления проблем гетерогенности, с одной стороны, и удобства развертывания системы, с другой, разместить все модули с несовместимыми требованиями к среде исполнения на различных виртуальных машинах в рамках одного аппаратного сервера;
— с учетом перспектив дальнейшего развития данных систем в направлении создания территориально-распределенных архитектур обеспечить взаимодействие модулей посредством сетевого обмена данными; для этих целей предлагается создать программные „обертки", преобразующие частную систему ввода—вывода каждого модуля в стандартизированный интерфейс обмена данными;
— реализовать центральный модуль программного комплекса (ПМ „Координация"), позволяющий, в свою очередь, производить вызов всех остальных модулей, обеспечивать их согласованными исходными данными, осуществлять сбор и интерпретацию результатов;
— создать кроссплатформенный интегрированный пользовательский интерфейс, позволяющий удаленно использовать все возможности системы.
Исследования, выполненные по данной тематике, проводились при финансовой поддержке ведущих университетов Российской Федерации: Санкт-Петербургского государственного политехнического университета (мероприятие 6.1.1), Университета ИТМО (субсидия 074-U01), Программы научно-технического сотрудничества Союзного государства „Мониторинг СГ" (проект 1.4.1-1), Российского фонда фундаментальных исследований (гранты № 12-07-00302, 13-07-00279, 13-08-00702, 13-08-01250, 13-07-12120, 13-06-0087), Программы фундаментальных исследований ОНИТ РАН (проект № 2.11), проектов ESTLATRUS 2.1/ELRI-184/2011/14, 1.2/ELRI-121/2011/13.
52
Ю. С. Мануйлов, С. В. Зиновьев, Ю. В. Прищепа, Е. Н. Алешин
список литературы
1. Методологические вопросы построения имитационных систем: Обзор / С. В. Емельянов, В. В. Калашников, В. И. Лутков и др.; Под науч. ред. Д. М. Гвишиани, С. В. Емельянова. М.: МЦНТИ, 1973. 87 с.
2. Охтилев М.Ю., Соколов Б. В., Юсупов Р. М. Интеллектуальные технологии мониторинга и управления структурной динамикой сложных технических объектов. М.: Наука, 2006. 410 с.
3. Калинин В. Н., Соколов Б. В. Многомодельный подход к описанию процессов управления космическими средствами // Теория и системы управления. 1995. № 1. С. 56—61.
4. Соколов Б. В. Комплексное планирование операций и управление структурами в АСУ активными подвижными объектами. МО: 1992. 232 с.
5. Цвиркун А. Д., Акинфиев В. К. Структура многоуровневых и крупномасштабных систем (синтез и планирование развития). М.: Наука, 1993.
6. Шаппел Д. А. ESB — Сервисная Шина Предприятия. СПб: БХВ-Петербург, 2008.
7. OASIS Standard: Web Services Business Process Execution Language. 2007.
8. Laurent S. St., Johnson J., Dumbill E. Programming Web Services with XML-RPC. СА: O'Reily, 2001.
9. Vasiliev Y. SOA and WS-BPEL: Composing Service-Oriented Solution with PHP and Active BPEL. Birmingham, UK: Packt Publishing, 2007.
Сведения об авторе
Семен Алексеевич Потрясаев — канд. техн. наук; СПИИРАН, лаборатория информационных технологий в системном анализе и моделировании; E-mail: [email protected]
Рекомендована СПИИРАН Поступила в редакцию
10.06.14 г.
УДК 519.711.72
Ю. С. Мануйлов, С. В. Зиновьев, Ю. В. Прищепа, Е. Н. Алешин
ИССЛЕДОВАНИЕ ДИНАМИЧЕСКОЙ И ЭНЕРГЕТИЧЕСКОЙ СОВМЕСТИМОСТИ СИСТЕМЫ ПОЗИЦИОНИРОВАНИЯ И УПРАВЛЕНИЯ УГЛОВЫМ ДВИЖЕНИЕМ КОСМИЧЕСКОЙ СОЛНЕЧНОЙ ЭНЕРГОСТАНЦИИ
Исследуется взаимовлияние процессов функционирования системы позиционирования и управления угловым движением космической солнечной энергостанции в рамках решения оптимизационных задач структурно-параметрического синтеза ее основных подсистем.
Ключевые слова: космическая солнечная энергетическая станция, система позиционирования и управления угловым движением, панель солнечных батарей, концентраторы солнечного излучения.
Введение. Современные оценки целесообразности создания и использования космических солнечных энергетических станций (КСЭС), предназначенных для передачи энергии на Землю в виде СВЧ-излучения, основаны, главным образом, на результатах анализа и структурно-параметрического синтеза отдельных подсистем: солнечных батарей (СБ), генераторов СВЧ-излучения и активных фазированных антенных решеток (АФАР) [1—3]. При этом оценивание эффективности КСЭС осуществляется, как правило, без учета процесса совместного функционирования данных подсистем, внешних воздействий, а также особенностей энерге-