Вычислительные стратегии

ГЛАВА 3. АВТОМАТИЗИРОВАННАЯ СИСТЕМА РЕШЕНИЯ ЗАДАЧ
ОПТИМАЛЬНОГО
УПРАВЛЕНИЯ
С
ВЫЧИСЛИТЕЛЬНЫМИ
ОСОБЕННОСТЯМИ OPTCON/SMART.
3.1. Анализ традиционного подхода к построению программных
комплексов для решения ЗОУ.
Как в отечественной, так и в зарубежной практике разработки
программных комплексов для решения ЗОУ закрепилась архитектура,
естественным
образом
отразившая
в
себе
парадигму
процедурного
программирования. Исходный код комплексов(optcon?), построенных по такому
типу, представляет из себя набор модулей – процедур (часто с общей памятью),
каждая из которых выполняет свою строго определенную задачу. Данные
процедуры можно(условно?) разделить на 8 классов:
1. Процедуры вспомогательных математических операций. Включают в
себя необходимые элементарные математические операции, такие как
перемножение и обращение матриц, а также отыскание их определителей,
отыскание минимума\максимума из 2-х значений и др.
2. Процедуры методов улучшения. К этому классу, например, относятся
процедуры
вычисления
различных
порядков,
гамильтонианов,
интегрирования
частных
прямых
и
производных
сопряженных
(вспомогательных) систем дифференциальных уравнений, вычисление
определенных интегралов, процедуры одномерной минимизации и т д.
3. Процедуры
необходимых
интерфейса
для
анализа
пользователя.
и
Осуществляют
последующего
принятия
вывод
решения
результатов вычислений (значения функционалов, норм градиентов,
текущего шага процедуры одномерной минимизации и многих других) на
экран в виде таблиц и графиков в реальном режиме времени, позволяют
пользователю
вмешиваться
в
ход
решения
задачи
–
останавливать/запускать счет, изменять параметры алгоритмов и многое
другое.
Важнейшей
задачей
таких
55
процедур,
помимо
всего
вышеизложенного,
является
информирование
пользователя
о
возникновении нештатных ситуаций («АВОСТов») или ситуаций,
препятствующих запуску комплекса (например, при наличии явных
ошибок в программной постановке задачи);
4. Процедуры ввода-вывода. Осуществляют файловый ввод-вывод массивов,
содержащих значения переменных модели на всем отрезке времени.
Также предоставляют сервис «дампа» - контрольных точек, содержащих
полный «снимок» процесса на данном этапе решения, позволяющий, при
дальнейшем
неблагоприятном
исходе
вернуться
в
сохраненную
контрольную точку. К этому же классу процедур следует отнести
создание протокола решения задачи – подробного (по итерациям)
журнала, содержащего значения переменных модели, основного и
вспомогательных функционалов, различных параметров алгоритма и т д.;
5. Процедуры постановки задачи. К данному классу относятся процедуры,
содержащие программную постановку задачи, а именно:
 отрезок времени;
 размерности задачи (число фазовых переменных, управлений и
постановочных параметров, терминальных и фазовых ограничений
типа равенств и неравенств и др.);
 функции правых частей систем ДУ модели;
 начальные значения фазовых переменных;
 функции терминальных, фазовых и промежуточных ограничений;
 функционалы;
 параметры алгоритмов;
 ограничения на управление;
 начальное управление;
 управляющие параметры вычислительных алгоритмов;
 управляющие параметры программного комплекса;
6. Процедуры
верификации.
Осуществляют
проверку
программной
постановки задачи на наличие явных ошибок (например, несоответствия
56
размерностей, ошибки в индексах массивов, ошибки при задании
параметров и т. д.);
7. Процедуры постоптимизационного анализа. Осуществляют с той или
иной степенью автоматизации проверку адекватности полученного
решения либо сбор и предоставление необходимой для такого анализа
информации;
8. Основная процедура. Определяет последовательность вызова процедур
необходимых
для
подготовки,
запуска,
контроля
и
остановки
итерационных методов.
Необходимо отметить, что каждый из представленных выше классов
процедур реализован в том или ином программном комплексе в большей или
меньшей степени. Исключения составляют, пожалуй, только процедуры
постоптимизационного анализа, реализация конструктивной части которых
достаточно трудоемко.
Архитектуру большинства современных программных комплексов можно
схематически представить на рис. 3.1. Цифрами на рисунке обозначена
циклическая последовательность работы пользователя с комплексом. Серые
стрелки обозначают информационные потоки, черные – управляющие
воздействия.
Такая непростая с точки зрения конечного пользователя и, в то же время
максимально
гибкая
архитектура
обусловлена
самой
сложностью
формулировок практических ЗОУ. Зачастую, одна только динамическая
система является настолько громоздкой, что ее программное описание
приходится
распределять
по
нескольким
процедурам.
Традиционная
архитектура позволяет пользователю с достаточным уровнем квалификации
программиста легко это проделать. Еще одним преимуществом такого подхода
является возможность использования в описании модели функций и
параметров, заданных в табличном виде либо полученных в результате
некоторых нетривиальных математических операций (например, решения
системы линейных алгебраических уравнений). Такая архитектура, в целом,
57
предоставляет
широкие
возможности
по
описанию
и
всесторонней
корректировке «на лету» самых сложных моделей, описывающих явления и
процессы реального мира. Возможности традиционной схемы ограничены,
пожалуй, только ресурсом времени, программистскими способностями самого
исследователя и его математической квалификацией.
Рис. 3.1. Традиционная архитектура построения программных
комплексов для решения ЗОУ.
Недостатки архитектуры начинают проявляться при попытке отчуждения
программного комплекса от разработчика:

необходимость хорошего владения языком программирования, на
котором написан программный комплекс (чаще FORTRAN или C/C++,
реже – специфические MATLAB-подобные языки);
58

необходимость знания и соблюдения пользователем всех аспектов
технологической постановки задачи;

повышенные
требования
к
пользователю
на
этапах
анализа
промежуточных и окончательных результатов;

отсутствие четких рекомендаций по
комплексной конфигурации
управляющих параметров вычислительных алгоритмов;

наличие недокументированных возможностей.
Основными
недостатками
данной
архитектуры
в
контексте
рассматриваемого в работе класса ЗОУВО можно назвать:

отсутствие конструктивных механизмов обработки «АВОСТов»;

отсутствие автоматизированных механизмов решения серий задач;

отсутствие
механизмов
генерирования
адекватных
начальных
управлений;

отсутствие модулей автоматизированного построения регуляризующих
вычислительных схем.
Недостатки, выделенные курсивом, имеют одну важную особенность –
возможные способы их устранения тесно сопряжены с необходимостью
отчуждения вместе с программным комплексом знаний и опыта экспертаразработчика. В новой архитектуре для устранения указанных недостатков,
должна быть предусмотрена некая программная среда, позволяющая с
различной степенью автоматизации для каждой конкретной задачи строить
серию вычислительных экспериментов, на основе которых комплексом будет
генерироваться уникальный алгоритм решения именно этой конкретной задачи.
Возвращаясь к рассматриваемому классу ЗОУВО с характерной для него
второй группой недостатков, отметим, что нередко попытки решения конечным
пользователем таких задач с использованием программных комплексов в
традиционной архитектуре приводят к ситуации, схематически представленной
на рис. 3.2. На нем видно, что основная часть работы над задачей ложится на
эксперта, который, вообще говоря, может по тем или иным причинам оказаться
труднодоступным для пользователя.
59
Рис. 3.2. Взаимодействие пользователя, эксперта-разработчика и
программного комплекса при решении ЗОУВО.
Заканчивая данный обзор, следует отметить тенденцию реализации
интерфейсов программных комплексов в виде интерактивных web-оболочек,
позволяющих проводить вычисления удаленно через сети Интернет/Интранет.
Для этого конечному пользователю достаточно на своем рабочем месте иметь
лишь соответствующий канал связи и один из стандартных Интернет-браузеров
[?Массель, Горнов, Подкаменный, Лемперт, Гаченко]. За этой архитектурой
закрепилось
название
«трехзвенная»
60
[?].
Такой
подход,
безусловно,
обеспечивает пользователям и разработчикам удобство работы, однако
проблемы отчуждения знаний и опыта эксперта, рассмотренные выше,
остаются актуальными и в этом случае.
3.2. Подход к автоматизации программных комплексов для решения
ЗОУ.
Основной
существующей
целью
предлагаемого
архитектуры
от
подхода
недостатков,
является
избавление
характерных
для
рассматриваемого класса задач. При этом новая архитектура должна в полной
мере сохранить возможности прежней и даже несколько их расширить. В
процессе устранения описанных в предыдущем параграфе недостатков
программных
комплексов
в
традиционной
архитектуре,
разработчик
сталкивается с рядом принципиальных проблем, обусловленных самой
природой «знаний». Знания эксперта  его понимание множества возможных
ситуаций и способы перехода объекта из одного состояния к другому. Под
объектом, в данном случае подразумевается конкретная задача оптимального
управления, погруженная в аппроксимирующее параметрическое семейство.
Важнейшие инструменты получения знания – гипотезы, их выдвижение,
последующая проверка и вынесение заключительного решения. Попытка
внедрения в соответствующие модули комплекса элементов «знаний» на
соответствующем традиционном императивном языке программирования,
возможно приведет к определенному успеху, однако, построенный по такому
принципу комплекс, сразу приобретет ряд негативных свойств, таких как:

существенное
усложнение
кода
вычислительных
процедур,
обусловленное большим (возрастающим на порядки) числом ветвлений
(IF-THEN-ELSE, SELECT-CASE), логических связок (AND, OR, NOT), а
также простых (равно, не равно, больше или равно, меньше или равно и
т.д.)
и
сложных
(MATCH)
программировании «знаний»;
61
сравнений,
появляющихся
при

нарушение принципа жесткой структурированности, характерной для
вычислительных комплексов решения ЗОУ, вызванное перемешиванием
участков кода, отвечающих за принципиально разные задачи (логический
вывод и непосредственно вычисления);

как следствие первых двух – существенное усложнение процедур отладки
и дальнейшей модификации комплекса, как в плане вычислительных
процедур, так и в плане процедур приобретения, хранения и обработки
«знаний»;

сложность
создания
«объяснение»
тех
механизмов,
или
отвечающих
иных
действий,
за
комплексное
предпринятых
автоматизированным комплексом в процессе решения задачи;

сложность,
а
в
некоторых
случаях
и
полная
невозможность
использования унаследованного программного обеспечения в рамках
автоматизированных программных комплексов.
Рис. 3.3. Принцип построения автоматизированного комплекса для
решения ЗОУ.
В целях решения ряда этих и иных проблем предлагается архитектура,
схематически представленная на рис. 3.3. Черными стрелками на рисунке, по-
62
прежнему, обозначены управляющие воздействия, а серыми – информационные
потоки.
Принципиально новым отличием этой архитектуры является наличие в
ней интеллектуального динамического планировщика (ИДП) – управляющей
компоненты, реализованной на более подходящем для моделирования знаний
типе языка программирования – декларативном. Основными задачами ИДП
являются:

получение качественной начальной информации о решаемой ЗОУВО;

построение
и
численное
исследование
аппроксимирующего
параметрического семейства в целях нахождения решения исходной
задачи, либо в некоторых случаях генерирования рекомендаций для
пользователя по корректировке модели;

осуществление постоптимизационного анализа;

управление технологическими этапами решения ЗОУВО;

обеспечение интеллектуального интерфейса взаимодействия между
пользователем и исполнительным модулем.
ИДП содержит:

факты, характеризующие начальное, текущее и желаемое состояние
объекта;

закономерности, характерные для рассматриваемой предметной области;

механизмы выдвижения и проверки гипотез – реализация метода
вычислительного эксперимента над объектом – ЗОУВО.
Для удобства работы, как разработчика-исследователя, так и конечного
пользователя, не имеющего достаточной квалификации в рассматриваемой
предметной области, программный комплекс, имеющий в своем составе ИДП,
должен обеспечивать пользователю работу в 4 режимах:
1.
Автоматический - режим работы программного комплекса, при котором
пользователю отведена роль наблюдателя. Все действия по принятию
решений берет на себя ИДП.
63
2.
Консультационный - режим работы программного комплекса, при
котором пользователь может взаимодействовать с ИДП, по желанию
корректируя предлагаемый им путь решения задачи.
3.
Ручной (командный) – режим, при котором ИДП выполняет любое
действие только по команде пользователя;
4.
Отладочный – режим с максимально подробным online-выводом на экран
(или в файл) всех технологических параметров работы ИДП.
Вычислительный (исполнительный) модуль (ИМ) является управляемой
ИДП компонентой и представляет собой вычислительный комплекс для
решения ЗОУ, построенный по традиционной схеме с тем отличием, что в
качестве его «пользователя», с определенной долей условности, выступает
ИДП. Основными задачами ИМ являются:

решение поставленной ЗОУ со степенью точности и параметрами
(алгоритмическими и постановочными), заданными ИДП;

решение с различной точностью вспомогательных вычислительных задач
для
ИДП
(например,
интегрирование
систем
дифференциальных
уравнений, вычисление функционалов).
Интерфейс пользователя в данной архитектуре может быть реализован
любым из принятых в настоящее время способов:

консоль (как локальная, так и удаленная - терминал);

псевдографика;

окна и элементы управления локального Win32-приложения;

окна и элементы управления локального X-приложения (приложения,
функционирующего
под
управлением
операционных систем семейства UNIX);

API для вышестоящего ПО;

Интерактивная WEB-оболочка.
64
оконных
менеджеров
Взаимодействие между ИДП и ИМ осуществляется через некоторый
программный интерфейс, который в зависимости от архитектуры конкретного
исполнительного модуля строится тем или иным способом.
Отметим основные преимущества предлагаемой архитектуры:

облегчение
процедуры
отчуждения
программного
комплекса
от
разработчика;

возможность независимой модификации ИДП и ИМ;

возможность использования в качестве исполнительного модуля ПО
различных разработчиков с условием соответствующей доработки
интерфейсов взаимодействия ИДП и ИМ;

возможность
программного
использования
в
обеспечения,
качестве
ИМ
построенного
унаследованного
по
архитектуре,
представленной в 3.1;

избавление пользователя от рутинной, зачастую, длительной процедуры
«ручного»
перебора
значений
постановочных
параметров
аппроксимирующего семейства при решении ЗОУВО;

возможность генерирования для пользователя ряда рекомендаций по
корректировке
динамической
модели
в
целях
избавления
сформулированной на ее базе ЗОУ от вычислительных особенностей.
При условии качественного построения ПО для ЗОУ в рамках
предлагаемой архитектуры, процесс взаимодействия пользователя, экспертаразработчика и программного комплекса при решении ЗОУВО в большинстве
случаев примет характер, представленный на рис. 3.4..
65
Рис. 3.4. Взаимодействие пользователя, эксперта-разработчика и
автоматизированного программного комплекса при решении ЗОУВО.
К сожалению, предлагаемая архитектура не лишена недостатков, к
наиболее серьезным из которых можно отнести:

сложность и разнообразие способов формализации знаний экспертаразработчика;

наличие характерной
для
полуразрешимости
отсутствия
–
систем логического
априорных
вывода проблемы
гарантий
получения
требуемого решения за разумный промежуток времени;

потенциально возможны ситуации зацикливания логического вывода;
66

сохранение проблем со сложностью программной постановки;

необходимость
корректировки (часто существенной) интерфейсов
взаимодействия ИДП и ИМ в процессе переориентации ИДП на новый
тип ИМ.
3.3. Общая архитектура системы и средства ее программной
реализации.
Общая
архитектура
разработанного
программного
комплекса
представлена на рис. 3.5. Как и прежде, серыми стрелками на рисунке
обозначены информационные потоки, а черными  управляющие воздействия.
В основу построения данной системы положен подход к созданию
автоматизированных комплексов для решения ЗОУ, подробно описанный в
разд. 3.2.
Назначение
и
устройство
основных
компонент
архитектуры
программного комплекса, а также механизмы и протоколы их взаимодействия
более детально описаны в последующих разделах этой главы. Здесь отметим
лишь некоторые моменты.
Все элементы ИДП, представленные на схеме, за исключением Базы
Фактов, интерпретатора результатов и резидента нештатных ситуаций по
смыслу являются разделами Базы Знаний  сгруппированными по областям
применения правилами-продукциями. Однако сама техническая реализация
Базы Знаний эти области четко не ограничивает. Например, одно и то же
правило, являясь синтаксически законченной конструкцией в программном
коде, по области своего применения может быть в равной мере отнесено, как к
конструктору вычислительных схем, так и конструктору начального состояния.
Такая ситуация, по-видимому, отражает свойство человеческого мышления
применять одни и те же подходы в похожих обстоятельствах.
67
ИДП
Интерфейс пользователя
Супервайзер
Модуль
протоколирования
Конструктор
выч. схем
РАБОЧАЯ
ПАМЯТЬ ИДП
(БАЗА ФАКТОВ)
Менеджер
программной
постановки
Исполнительный модуль
Интерпретатор
результатов
Конструктор
начального
состояния
Резидент
нештатных
ситуаций
Файлы
результатов
Исполняемый
вычислительный
модуль
(ВЫЧИСЛИТЕЛЬ)
Компоновщик
код
программной
постановки
код
вычислительных
процедур
Рис. 3.5. Архитектура программного комплекса OPTCON/SMART
68
Интерпретатор результатов, резидент нештатных ситуаций, а также
вызовы компоновщика и Вычислителя, организованы модификацией исходного
С-кода
(файл
CLIPS
дистрибутива
Фактически,
userfunctions.c).
в
операционную среду CLIPS дописаны функции, позволяющие запускать и
контролировать
любые
внешние
по
отношению
к
CLIPS
процессы
непосредственно из RHS правил-продукций. В нашем случае этими процессами
являются компоновщик, Вычислитель и лексический анализатор FLEX.
Интерпретатор результатов и резидент нештатных ситуаций имеют
похожую структуру, поскольку оба являются XML-парсерами, написанными на
языке C, и используют функции одной и той же библиотеки eXpat.
Опосредовано вызываясь через правила конструктора вычислительных схем и
начальных состояний, они формируют в Базе Фактов текущий статус задачи,
тем самым напрямую влияя на дальнейший логический вывод.
Менеджер программной постановки оказался одним из самых трудных в
реализации модулей ИДП. Большинство его функциональных компонент,
управляемых несколькими правилами Базы Знаний, также реализованы в виде
C-функций модифицированного автором дистрибутива CLIPS.
В качестве Компоновщика в исполнительном модуле используется
традиционная
для
UNIX-систем
утилита
make
c
соответствующим
конфигурационным файлом Makefile.
Изначально
разработанного
ориентируясь
на
дальнейшее
развитие
комплекса
Web-ориентированного
на
базе
приложения
(вычислительного сервера) с возможностью использования суперкомпьютеров,
при выборе платформы, а также инструментальных средств создания
OPTCON/SMART
предпочтение
было
отдано
OpenSource-продуктам,
функционирующим на базе операционной системы FreeBSD семейства UNIX.
Версии средств программной реализации, использовавшихся при разработке,
отладке и тестировании, представлены в таблице 3.1.
69
Таблица 3.1. Средства программной реализации комплекса OPTCON/SMART.
1
Операционная система
2
Интеллектуальный динамический
планировщик  База Фактов, База Знаний,
машина вывода
Компилятор С
3
4
5
6
FreeBSD (версия 7.0RELEASE от 27.02.2008)
Генератор С-кода лексического
анализатора (одного из вспомогательных
модулей ИДП)
Парсер XML (обеспечение
функционирования протокола
двустороннего взаимодействия между
ИДП и ИМ)
Отладчик
CLIPS
(версия 6.24 от 15.06.2006)
gcc
(версия 4.2.1 от 19.07.2007
FLEX
(версия 2.5.4 )
Библиотека eXpat
(версия 2.0.1 от 05.06.2007)
gdb
(версия 6.6.1 от 18.12.06)
Основной сложностью при технической реализации предложенной
архитектуры
оказались, пожалуй, переход при разработке ИДП к более
подходящему для этой цели декларативному стилю программирования, а также
поиск и отработка эффективных методов взаимодействия ИДП с любым ИМ,
удовлетворяющим требованиям п. 3.7.1 настоящей работы.
3.4. Принципы обнаружения нештатных ситуаций.
Своевременное фиксирование и локализация нештатных ситуаций,
неизбежно возникающих при численном решении ЗОУВО, является залогом
эффективной работы программного комплекса. Для решения этой задачи
предлагается использовать подход, учитывающий возможности современной
архитектуры Intel-совместимых процессоров.
3.4.1. Некоторые особенности работы FPU (Floating Point Unit) в
современных архитектурах Intel-совместимых процессоров.
70
В ранних операционных системах, например MS DOS (а существенная
часть унаследованного программного обеспечения для решения ЗОУ было
построено либо адаптировано именно под эту ОС), любая нештатная ситуация,
например, нарушение области определения встроенных в сопроцессор функций
или переполнение, всегда вызывала исключение – сигнал специального вида,
информирующий пользовательский процесс о возникшей проблеме. Используя
специальные конструкции, процесс мог перехватить такой сигнал и обработать
его тем или иным способом. В случае отсутствия в программе таких
конструкций процесс, при возникновении исключения, «грубо» завершал свою
работу.
Современные математические сопроцессоры способны работать в двух
режимах в зависимости от способа инициализации регистров математического
сопроцессора. Первый
возникновении
из этих
режимов аналогичен старому
исключительной
ситуации
в
процесс
–
при
посылается
соответствующий сигнал. Второй режим обладает большей гибкостью – вместо
посылки сигнала сопроцессор выставляет соответствующий ситуации флаг в
специальном регистре, не прерывая пользовательский процесс. При этом
регистры, связанные с переменными (в том числе элементами массивов,
хранящих управление и траекторию) задачи, в которые должен быть помещен
результат операции, вызвавшей сбой, заполняются специальными значениями,
носящими в терминологии Intel определение “не-число” (NaN – Not-a-Number).
Заметим, что данный режим устанавливается современными операционными
системами режимом «по умолчанию».
3.4.2. Датчики нештатных ситуаций.
Датчики
нештатных
ситуаций
представляют
собой
программные
компоненты, назначение которых – своевременное информирование ИДП о
характере и месте возникновения нештатной ситуации (АВОСТа), требующей
немедленного вмешательства. Использование штатных средств перехвата
исключительных ситуаций, предусмотренных языком программирования
71
(например, TRY-CATCH или использование функций обработки сигналов ядра
в UNIX-системах), в нашем случае представляется не вполне удобным по
следующим причинам:

непредсказуемость числа и последовательности срабатывания функцийперехватчиков;

в контексте ИДП - усложненная процедура установления места
возникновения нештатной ситуации.
В программном коде исполнительного модуля выделены следующие
участки «вокруг» которых при решении задач описываемого класса необходима
установка датчиков нештатных ситуаций:

интегрирование прямой и сопряженной (вспомогательной) систем
дифференциальных уравнений;

вычисление функционалов;

вычисление функций ограничений (если таковые существуют);

вычисление производных функций.
FPU процессора Intel предоставляет пользователю два специальных
регистра, позволяющих организовывать «мягкое» отслеживание ошибок,
возникающих при использовании математических операций:
SW – Status Word. 2-байтный регистр операционного статуса FPU,
содержащий в 6 младших битах информацию обо всех произошедших с
момента инициализации FPU инструкциями FINIT/FNINIT нештатных
ситуациях. Отсутствие нештатной ситуации кодируется нулем, наличие –
единицей.
Бит SW
Обозначение
Вид исключения
0
IM
1
DM
денормализованный операнд
2
ZM
деление на ноль
3
OM
переполнение
нарушение области определения элементарной
математической функции
72
4
UM
антипереполнение
5
PM
нарушение точности представления результата
CW – Control Word. Управляющий 2-байтный регистр, содержащий в 6
младших битах маску исключений. Это означает, что если соответствующий
исключению бит регистра CW установлен в 1, то при возникновении в процессе
решения задачи такого исключения, соответствующий бит статусного регистра
SW будет так же установлен в 1. При этом основной процесс не получает от
операционной
системы
никакого
«разрушительного»
сигнала.
Если
соответствующий исключению бит регистра CW установлен в 0, то при
отсутствии
соответствующих
функций-перехватчиков
процесс
аварийно
завершает свою работу по сигналу SIGFPE.
Работа любого датчика нештатной ситуации разбита на следующие
последовательные этапы:

инициализация FPU;

инициализация (маскирование) соответствующего бита управляющего
слова (CW-регистра) FPU;

опрос состояния статусного слова (SW-регистра) FPU на определенных
этапах вычислительного процесса с целью фиксирования «АВОСТа»;

внесение в соответствующую область рабочей памяти ИДП информации
о
текущем
состоянии
вычислительного
процесса
и,
в
случае
возникновения нештатной ситуации, информации о характере и месте ее
возникновения (проверка показания датчика);

сброс управляющих регистров FPU в исходное «штатное» состояние.
Датчики нештатных ситуаций реализованы в исполнительном модуле
средствами inline-ассемблера. Ниже приведены примеры построения функций
инициализации и проверки датчика «деление на 0».
Функция инициализации датчика:
73
void SensorInit_ZM() {
unsigned short cw,cw_mask = 4; // 000100B
asm("FSTCW %0":"=m"(cw));
cw |= cw_mask;
asm("FLDCW %1;":"=m"(cw):"m"(cw));
}
Здесь:
FSTCW – инструкция загрузки управляющего слова CW в переменную cw,
FLDCW – инструкция загрузки значения переменной cw в регистр CW.
Функция проверки датчика:
void SensorCheck_ZM(int p1,int p2,…) {
unsigned short sw,sw_mask = 4; // 000100B
asm("FSTSW %0":"=m"(sw));
sw &= sw_mask;
if(sw) {
ZM_Handler(p1,p2,…);
asm("FINIT");
}
}
Здесь:
p1,p2,… – параметры, однозначно определяющие местонахождение
датчика в иерархии вызовов вычислительных процедур исполнительного
модуля,
FSTSW – инструкция загрузки статусного слова SW в переменную sw,
ZM_Handler()– функция обработки данной нештатной ситуации
(информирование ИДП о месте возникновения и характере исключения),
FINIT – инструкция переинициализации FPU (обнуление статусного
слова
SW
и
установка
битов
управляющих
предусмотренные «по-умолчанию»).
74
регистров
в
значения,
3.5 Интеллектуальный динамический планировщик.
3.5.1 Общие принципы построения ИДП.
Интеллектуальный
динамический
планировщик
реализован
в
операционной среде CLIPS и состоит из 3-х основных компонент.
1.
База Фактов (рабочая память). Содержит как статические (заданные
пользователем априори) данные о решаемой задаче, так и динамические, т.е.
полученные непосредственно в ходе решения. Важнейшей динамической
информацией, содержащейся в базе фактов, является набор локальных
вычислительных
стратегий
–
специальным
образом
сформированных
инструкций для вычислительного модуля, определяющих последовательность
перебора постановочных параметров, а также информация об успешности либо
не успешности применения таких стратегий. Источниками формирования базы
фактов являются:

эксперт-разработчик или инженер по знаниям;

конечный пользователь;

элементы базы знаний;
2.
База знаний (правил). Содержит формализованные в виде правил-
продукций и сгруппированные по областям использования знания экспертавычислителя по решению задач рассматриваемого класса. Источниками
формирования базы знаний могут являться лишь эксперт-разработчик или
инженер по знаниям. Это означает, что на данном этапе развития ИДП не
предполагается возможности его «самообучения» - способности формирования
принципиально новых элементов-правил базы знаний на основе уже
существующих.
3.
Машина вывода (интерпретатор правил). Механизм, непосредственно
имитирующий
действия
эксперта-вычислителя
на
основе
содержащихся в базе знаний.
Принципиальная схема работы ИДП представлена на рис. 3.6.
75
правил,
База фактов
Интерпретатор
(машина вывода)
Факты
(данные)
память состояний
База знаний
Образцы
(шаблоны)
фактов
Формирование и выполнение
действий
Образцы
(шаблоны)
действий
"Объяснение" хода решения
Рис. 3.6. Схема работы ИДП.
3.5.2 Структура базы фактов
Здесь и далее при описании требуемых конструкций будем использовать
терминологию и синтаксис языка CLIPS, который применялся при создании
ИДП. База фактов содержит набор утверждений, сформированных по
определенным экспертом шаблонам. В рамках модели, описанной в главе 2, в
базе фактов определено три основных шаблона – ls, ctrl и p. Ниже
приводится подробное описание всех трех шаблонов, представленных в
синтаксисе языка формирования структуры базы фактов среды CLIPS.
Шаблон неупорядоченного факта CLIPS, описывающего локальную
вычислительную стратегию, по сути – план решения ЗОУВО на определенном
промежутке изменения постановочного параметра:
(deftemplate ls
(slot p0 (type INTEGER))
(slot p1 (type INTEGER))
(slot dp (type INTEGER))
(slot status)
(multislot role)
)
Здесь:
76
p0 – слот, содержащий начальное значение постановочного параметра,
умноженное на 10 k ;
p1 – слот, содержащий конечное значение постановочного параметра,
умноженное на 10 k ;
dp – слот, содержащий изменение шага по параметру на промежутке от
p0 до p1, умноженное на 10 k ;
status – слот, описывающий текущий статус стратегии. Содержимое
слота может принимать одно из 3-х значений:

active, активная стратегия – стратегия, обрабатываемая в
настоящий момент исполнительным модулем;

none, пассивная стратегия – стратегия, планируемая к обработке
исполнительным модулем, либо еще не проверенная гипотеза об
эффективном уменьшении шага по параметру;

success,
успешная
стратегия
–
стратегия,
полностью
обработанная исполнительным модулем в штатном режиме (без
возникновения нештатной ситуации).
role – слот, описывающий роль стратегии в процессе принятия
решения. Может принимать два значения:

std, обычная стратегия;

spec
<N>, гипотеза об эффективном уменьшении шага по
параметру,
проверяемая
исполнительным
либо
модулем.
Здесь
планируемая
N
–
к
число,
проверке
обратно
пропорциональное степени уверенности эксперта (а точнее его
модели) в справедливости выдвинутой гипотезы. Обычно, при
возникновении
нештатной
ситуации,
выдвигается
2-3
(в
зависимости от текущего размера шага dp) гипотезы, проверяемые
в последовательности, определяемой числом N.
Заметим, что в слотах p0, p1 и dp хранятся числовые значения,
умноженные на 10 k . Здесь и далее это связано с тем, что арифметические
77
операции с постановочным параметром, заданным в формате числа с
плавающей точкой в среде CLIPS, очень быстро приводят к серьезным
ошибкам округления, что существенно влияет на механизм сопоставления в
машине вывода. Во избежание этого в фактах, описывающих локальные
вычислительные стратегии и другие конструкции, используются целые числа, а
исполнительному модулю передаются эти же значения, деленные на 10 k .
Число k вычисляется по формуле k  e* , где e * - предельно допустимое
значение
порядка
приращения
постановочного
параметра
pi
в
соответствующей локальной вычислительной стратегии S i (см. гл. 2).
Шаблон неупорядоченного факта, отражающего текущее состояние
программного
комплекса
в
ходе
решения
ЗОУВО,
погруженной
в
аппроксимирующее семейство:
(deftemplate ctrl
(slot p(type INTEGER))
(slot pz(type FLOAT))
(slot z)
)
Здесь:
p – слот, содержащий текущее значение постановочного параметра,
умноженное на 10 k ;
pz – слот, содержащий текущее значение постановочного параметра,
переданное или планируемое к передаче в исполнительный модуль;
z – слот, содержащий информацию о статусе соответствующей значению
pz задачи оптимального управления из параметрического семейства. Может
принимать следующие значения:

u (unknown), означает, что попыток решения задачи с таким
значением параметра не производилось;

n (negative), означает, что попытка решения задачи привела к
нештатной ситуации;
78

y (yes), означает, что задача с заданным значением параметра pz
решена успешно.
Шаблон неупорядоченного факта, описывающего аппроксимирующее
параметрическое семейство ЗОУ:
(deftemplate p
(slot name)
(slot type)
(slot p0 (type INTEGER))
(slot pa (type INTEGER))
(slot status)
(slot priority)
)
Здесь:
name – слот, содержащий имя постановочного параметра, порождающего
параметрическое семейство в том виде, в котором это имя содержится в
программной постановке задачи;
type – слот, описывающий тип метода параметризации. В соответствии
с типом параметризации (см. гл. 1) он может принимать одно из следующих
значений:

pf, uBox, uf, pD, x0, stab.
p0 – слот, содержащий значение постановочного параметра на «левой»
границе «восходящего» или «правой» границе «нисходящего» интервала его
изменения, умноженное на 10 k ;
pa (p-asterisk) – слот, содержащий значение постановочного параметра,
умноженное на 10 k , при котором ЗОУ из параметрического семейства
идентична исходной;
status
– слот, описывающий текущий статус параметрического
семейства по отношению к вычислительному процессу. Содержимое слота
может принимать одно из следующих значений:

none, означает,
что данный тип параметризации еще не
применялся;
79

init, означает,
что данный тип параметризации выбран для
построения аппроксимирующего семейства задач и производится
его инициализация – поиск значения p 0 по схемам, определенным
в модели, представленной в главе 2 настоящей работы;

active, означает, что инициализация выполнена и на данном типе
параметризации
ведется
поиск
в
пространстве
полных
вычислительных стратегий.

fail, означает,
что данный тип параметризации признан
неэффективным.
priority – слот, содержащий целое число, обратно пропорциональное
степени уверенности эксперта в эффективности применения данного типа
параметризации.
В качестве примера на рис. 3.7 представлен фрагмент базы фактов при
решении ЗОУВО.
Приведем пример критерия (состояния базы фактов), по которому в
предложенной структуре ИДП делает вывод об успешном окончании решения
ЗОУВО:
(p(name prp0)(type pf)(p0 10)(pa 1000)(status active)(priority 1))
(ctrl (p 1000) (pz 1.000) (z y))
Приведенные выше факты говорят о том, что:

построено и инициализировано pf-параметрическое семейство ЗОУ со
значениями
p *  1, p 0  0,1
и
предельным
значением
порядка
приращения параметра e*  10 3 ;

в
ходе
последовательного
решения
серии
ЗОУ
из
данного
параметрического семейства удалось найти оптимальное управление для
задачи,
соответствующей
значению
параметра
равносильно нахождению решения исходной ЗОУВО;
80
p  p *  1,0 ,
что
Рис. 3.7. Фрагмент листинга базы фактов в процессе решения ЗОУВО.
3.5.3 База Знаний
База Знаний является основным управляющим компонентом ИДП и всего
программного комплекса в целом, включая в
себя полную программную
реализацию модели действий эксперта, описанной в главе 2 настоящей работы,
а так же модули управления всеми технологическими этапами решения
ЗОУ/ЗОУВО и вспомогательных задач.
С учетом специфики исследуемого класса задач согласно общей методике
построения программных систем для решения задач оптимального управления,
представленной в работе [Горнов, дисс.], База Знаний разбита на следующие
функциональные модули:
Модуль
Конструктор
вычислительных схем
Назначение
 принятие решения о методе параметризации
задачи;
 принятие
решения
о
выборе
метода
оптимизации;
 генерирование и реализация схем подбора
последовательности
постановочных
параметров;
 в
случае
81
невозможности
нахождения
оптимального управления на всем отрезке
времени
-
принятие
решения
об
его
сокращении;
 информирование пользователя о принятых
решениях.
Конструктор
начального  диагностика
состояния
неудовлетворительного
начального управления;
 построение
приемлемого
начального
управления
 нахождение начальной точки в пространстве
полных вычислительных стратегий.
Менеджер
программной
постановки
 получение
информации
о
виде
задачи
(упрощенная классификация)
 определение наличия в задаче потенциально
«опасных» компонент, таких как присутствие
в динамической системе дробных выражений
и элементарных математических функций с
ограниченной областью определения;
 построение и использование специальных
стеков
для
управления
автоматической
параметризацией задачи.
Модуль протоколирования
 запись в файлы протокола всей доступной
информации о ходе решения задачи.
«Супервайзер»
вычислительного процесса
 координация работы всего программного
комплекса в целом;
 осуществление
вычислительного
взаимодействия
и
интеллектуального
модулей;
 осуществление взаимодействия внутри ИДП
82
на
уровне
отдельных
осуществляющих
все
компонент,
описанные
выше
функции;
 интерпретация команд пользователя при
работе
программного
комплекса
в
командном (ручном) режиме.
База Знаний ИДП содержит 2 вида правил:

эмпирические, которые определяют набор действий, выполняемых при
определенном состоянии базы фактов;

процедурные, описанные в виде традиционных императивных функций.
Каждое эмпирическое правило базы знаний состоит из двух частей –
антецедента (предпосылки, LHS) и консеквента (следствия, RHS). LHS правила
представляет собой набор условий (или условных элементов – набора
ограничений, используемых для того, чтобы определить удовлетворяет ли
некоторый факт данному условию), которые должны выполниться для того,
чтобы правило «сработало». LHS правила удовлетворяются в зависимости от
наличия/отсутствия некоторых элементов или их логических комбинаций
(шаблонов), содержащихся на данный момент в базе фактов. RHS правила
представляется набором шаблонов некоторых действий, которые необходимо
сформировать и выполнить в случае «срабатывания» данного правила. Под
формированием действия здесь и далее понимается подстановка в RHS правила
реальных значений из базы фактов на место, определенное для них в шаблоне.
RHS правил содержат действия следующих категорий:
1.
2.
Управление элементами Базы Фактов:

добавление ( директива assert);

модификация (директива modify);

удаление (директива retract).
Вызов
внешних
пользовательских
действия, как:
83
функций,
выполняющих
такие

вызов
компонент
автоматического
менеджера
программной
постановки;

формирование программной постановки задачи;

конфигурация исполнительного модуля;

вызов исполнительного модуля (запуск компоновщика);

вызов функций интерфейса пользователя и др.;
Ниже приводится пример последовательного выполнения двух простых
правил Базы Знаний, первое из которых определяет процесс шага по параметру,
согласно текущей локальной вычислительной стратегии, а второе осуществляет
дальнейший вычислительный эксперимент.
LHS
ПРАВИЛО «step»
(ls (status active)(dp ?dp)(p1 ?p1))
?pp<- (ctrl (z y)(p ?p&:(< ?p ?p1)))
RHS
=>
(modify ?pp (z u)(p (+ ?p ?dp))(pz (n (+ ?p ?dp))))
Опишем ряд условий, которым должны удовлетворять элементы базы
фактов, при которых процесс сопоставления с LHS вызовет «сработку» данного
правила в машине вывода:
1.
существует активная локальная вычислительная стратегия с некоторым
значением шага ?dp и значением p1 равным некоторому ?p1
2.
имеет место факт успешного решения ЗОУ из параметрического
семейства при значении параметра p, меньшего, чем значение ?p1.
В результате «сработки» данного правила в базе фактов появится
утверждение о том, что следует решить следующую ЗОУ из параметрического
семейства со значением параметра p, равного ?p+?dp. Далее приводится
пример состояния базы фактов до и после «сработки» данного правила.
84
значимое содержимое Базы Фактов
До «сработки» step
После «сработки» step
(ls(p0 30)(p1 40)(dp 5)(status active))
(ctrl(p 35)(pz 0.035)(z y))
(ctrl(p 40)(pz 0.040)(z u))
Поскольку состояние базы фактов изменилось, машина вывода вновь
осуществляет сопоставление LHS правил базы знаний со вновь появившимися
утверждениями.
LHS
ПРАВИЛО «try»
?cc<- (ctrl (z u) (pz ?pz))
?fam<- (p (name ?nn) (status active))
RHS
=>
(modify ?cc (z (try ?nn ?pz y n)))
Условия «сработки» данного правила следующие:
1.
введением постановочного параметра с именем ?nn сформировано и
инициализировано аппроксимирующее семейство ЗОУ;
2.
существует
задача
из
этого
параметрического
семейства
с
соответствующим значением параметра p равного ?pz, попыток решения
которой еще не предпринималось.
В результате «сработки» данного правила в Базе Фактов будет отражен
результат
вычислительного
эксперимента
по
решению
ЗОУ
из
параметрического семейства со значением параметра ?nn равным ?pz.
Функция try, вызываемая из RHS этого правила, осуществляет вызов
исполнительного модуля, которому передается имя постановочного параметра
(?nn) и его значение (?pz). Данная функция возвращает одно из двух значений y
или n, которые означают, соответственно, успех либо неуспех проведенного
эксперимента.
85
значимое содержимое Базы Фактов
До «сработки» try
После «сработки» try
(p (name prp0)
(type pf)
(p0 10)
(pa 1000)
(status active)
(priority 1))
(ctrl(p
40)(pz 0.040)(z y))
или
(ctrl(p 40)(pz 0.040)(z n))
(ctrl(p 40)(pz 0.040)(z u))
3.5.4 Машина вывода
Механизм,
непосредственно
имитирующий
действия
эксперта-
вычислителя на основе правил, содержащихся в базе знаний включает в себя
два компонента:

компонент вывода – реализует непосредственно вывод на основе
известного правила modus ponens («Если «А»-истина и «Из А следует В»,
то «В-истина»). Таким образом, правила «срабатывают», когда в базе
фактов находятся элементы, удовлетворяющие их LHS;

управляющий компонент – определяет порядок применения правил.
Управляющий компонент машины вывода выполняет четыре функции:
1. Сопоставление – LHS каждого правила сопоставляется с текущими
элементами базы фактов. Результат сопоставления – активирование одного или
нескольких правил базы знаний. Активирование означает не непосредственное
выполнение, а подготовку правила к возможному дальнейшему применению;
2. Выбор (разрешение конфликта) – если в конкретный момент
активировано более одного правила (сформировано конфликтное множество),
то из них должно быть выбрано одно, наиболее подходящее по заданному
критерию;
3. Формирование действия – выполняется подстановка значений из
реальных фактов в точки, определенные шаблоном действия в RHS выбранного
к выполнению правила.
86
4. Действие – выполняются все действия, заключенные в RHS правила,
выбранного к выполнению.
Работа
машины
вывода
представляет
собой
цикл,
в
котором
последовательно выполняются все три описанные выше функции. Критерием
останова является отсутствие в базе фактов элементов, способных активировать
хотя бы одно правило. Цикл интерпретатора правил схематически представлен
на рис. 3.8.
База фактов
База знаний
Сопоставление
Конфликтное
множество
Срабатывание
правила
Разрешение
конфликта
Критерий
выбора правила
Действие
Рис. 3.8. Цикл работы машины вывода.
3.5.5. Механизм взаимодействия с исполнительным модулем
Различие технических реализаций ИДП и ИМ носит кардинальный
характер. Машина вывода ИДП по способу своего исполнения является
87
интерпретатором кода декларативной программы. Вычислитель же, как
правило, является исполняемым файлом, скомпилированным из исходного
кода, написанного на одном из императивных языков программирования. В
нашем случае это C. Кроме этого, функционирование комплекса подразумевает
регулярную перекомпиляцию исходного кода Вычислителя (использование
внешнего, по отношению как к ИДП, так и ИМ компоновщика make). Во
избежание сложностей при «сращивании» столь разных компонент в единый
исполняемый файл, при реализации OPTCON/SMART использовались средства
межпроцессного взаимодействия UNIX [t11,12/Хэвилэнд,Грэй,Салама / Чан].
Изменение кода программной постановки задачи для Вычислителя в
зависимости от генерируемых ИДП инструкций осуществляет менеджер
программной постановки (см. разд. 3.6).
Запуск на исполнение компоновщика и Вычислителя, а также передача
информации от ИМ к ИДП реализованы с использованием системных функций
popen(), pclose(), определенных в стандартном заголовочном файле
stdio.h.
Получение информации о ходе итерационного процесса от Вычислителя
осуществляется по специальному текстовому XML-протоколу (см. разд. 3.7.3)
через поток стандартного вывода (STDOUT) Вычислителя. Используя
дескриптор этого потока, полученный при помощи функции popen(), вывод
Вычислителя подается на вход функций-парсеров интерпретатора результатов
и резидента нештатных ситуаций. Применение такого подхода позволяет
минимизировать усилия по модификации исходного кода Вычислителя и,
вообще говоря, позволяет ему работать как под управлением ИДП, так и в
обычном «stand-alone»-режиме.
На
рис.
3.9
схематически
представлен
описанный
механизм
взаимодействия на примере RHS правил конструктора вычислительных схем.
88
Конструктор вычислительных схем
cp=popen("optcon3", "r");
Интерпретатор результатов
Резидент нештатных ситуаций
РАБОЧАЯ
ПАМЯТЬ ИДП
(БАЗА ФАКТОВ)
stdout
fread(..., cp );
ВЫЧИСЛИТЕЛЬ
Рис. 3.9. Механизм взаимодействия ИДП и ИМ.
В качестве примера реализации такого взаимодействия, ниже приводится
прототип соответствующего программного кода.
#include <stdio.h>
#include "expat.h"
void startElement(void *userData, const char *name, const char **atts)
{
//формирование утверждения для Базы Фактов
}
void endElement(void *userData, const char *name)
{
//Внесение утверждения в Базу Фактов
}
void TryCalc()
{
char buf[BUFSIZ];
//Инициализация интерпретатора результатов
XML_Parser ir = XML_ParserCreate(NULL);
//Назначение функций-обработчиков
XML_SetElementHandler(ir, startElement, endElement);
FILE *cp = popen("./optcon3","r"); //Запуск вычислителя
//Чтение и обработка результатов вывода Вычислителя
while(fread(buf, 1, sizeof(buf), cp))
XML_Parse(ir,buf,sizeof(buf),…);
XML_ParserFree(ir);
pclose(cp);
return;
}
3.6 Менеджер программной постановки
Менеджер программной постановки (МПП) задачи – комплексный
модуль (группа правил и несколько вспомогательных конструкций) ИДП,
задачами которого являются:
89

автоматическая
параметризация
математических
выражений,
составляющих программную постановку задачи;

обеспечение для пользователя возможности свободного именования
переменных модели;

добавление
в
базу
фактов
общей
информации
о
виде
задачи
(классификация ЗОУ).
На данном этапе развития ИДП МПП, в некоторых случаях, когда правые
части динамической системы и функционал заданы аналитически, способен
определять линейны или билинейны они по управлению и траектории, что
может быть полезно, например, при выборе метода решения.
МПП основан на использовании элементов теории компиляции [t13/Ахо,
Ульман] и состоит из состоит из 1) группы правил базы знаний, управляющих
взаимодействием компонент МПП; 2) лексического анализатора; 3) менеджера
стеков; 4) RPN-фильтра.
Схема функционирования МПП представлена на рис. 3.10. Цифры на
рисунке
определяют
последовательность
осуществления
управляющих
воздействий (черные стрелки) и передачи информационных сообщений (серые
стрелки) в процессе работы МПП.
Все управляющие на МПП воздействия выполнены в Базе Знаний в виде
вызовов соответствующих пользовательских функций (категория 2 действий
RHS, см. разд. 3.4.3), предусматривающих обязательное наличие обратной
связи
(возврат
кода
завершения),
взаимодействующих компонент.
90
необходимой
для
синхронизации
База Фактов
11
программная
постановка
задачи
10
1
#include "math.h"
#include "tinymath.h"
#include
"user.h"
#include
"math.h"
#include "tinymath.h"
//
#include
"user.h"
#include
"math.h"
void F(double t, double *x, double *u, double *ff)
#include "tinymath.h"
{
/ / "user.h"
#include
ff[0] = 0.3*u1;
void F(double
t, double *x, double *u, double *ff)
ff[1] = 0.3*sqrt((1.0+u1*u1)/x1);
{
//
return;
ff[0] = t,0.3*u1;
void F(double
double *x, double *u, double *ff)
} = 0.3*sqrt((1.0+u1*u1)/x1);
ff[1]
{
return;
ff[0] = 0.3*u1;
void X0(double *x0)
} = 0.3*sqrt((1.0+u1*u1)/x1);
ff[1]
{
return;
x0[0] =
3.0;
void X0(double
*x0)
}
x0[1] = 0.0;
{
//x0[0]x0[2]
= 0.055;
= 3.0;
void X0(double
*x0)
x0[1]return;
= 0.0;
{
//
x0[0]} x0[2]
= 3.0;= 0.055;
x0[1] return;
= 0.0;
}x0[2]//-= f0
//
0.055;
double F0(double t, double *x, double *u)
return;
//- f0{
}
return(0.0);
double F0(double
t, double *x, double *u)
}
//- f0 {
return(0.0);
double F0(double
double *x, double *u)
//- F(tk, t,
x(tk))
}
{
double FK(double tk, double *xtk)
return(0.0);
{
//- F(tk,
x(tk))
}
return(xtk[1]+1000*(xtk[0]-10.0)*);
double FK(double
tk, double *xtk)
}
{ x(tk))
//- F(tk,
return(xtk[1]+1000*(xtk[0]-10.0)*);
double FK(double
tk, double *xtk)
}
{
return(xtk[1]+1000*(xtk[0]-10.0));
}
менеджер
стеков
7
База Знаний
12
4
лексический
анализатор 5
2
RPN
RPN-фильтр 8
3
13
{1}
w
{1}{2}
w12,656
{1}{2}{3} w12,656
v
{2}{3}{4}12,656
v x
{3}{4}{5} v x y
{4}{5}{6} x y vv
{5}{6}{7} y vv t
{6}{7}
vv t
{7}
t
компоновщик
CTRL
CTRL
CONST
CTRL
CTRL
CONST
CTRL
TRAJ
CONST
CTRL
TRAJ
TRAJ
TRAJ
TRAJ
TRAJ
TRAJ
TRAJ
TIME
TRAJ
TIME
TIME
6
9
таблицы лексем
Рис. 3.10. Схема функционирования МПП.
3.6.1. Лексический анализатор.
Компонент МПП, решающий следующие задачи:

лексический
разбор
(распознавание
и
перечисление
неделимых
смысловых элементов) кода программной постановки задачи по
правилам, заданным в специальном конфигурационном файле;

формирование
таблиц
лексем
(увязка
уникальных
числовых
идентификаторов распознанных смысловых элементов программной
постановки с их типами и именами в контекстах пользователя и
программного комплекса);

запись математических выражений программной постановки задачи в
виде обратной польской нотации [посмотреть ссылку в старом диссере]
(RPN);
Исходный
код
лексического
анализатора
выполнен
на
языке
программирования C++ и получен при помощи стандартного в UNIX-системах
генератора
FLEX
[].
Правила
лексического
91
разбора
для
анализатора
формируются соответствующим модулем Базы Знаний. Каждое такое правило
представляет собой описание одной неделимой смысловой единицы (лексемы)
программной постановки (например, «управление», «траектория») в виде
регулярного выражения и сопоставленного ему ряда действий, которые
необходимо выполнить в случае обнаружения в общем потоке подстроки,
подходящей под описание.
Преобразование математических
выражений программной постановки
задачи к RPN осуществляется по известному алгоритму Дейкстры [t14/Лебедев]
и осуществляется параллельно процессу лексического анализа, с помощью
действий, описанных в правилах конфигурационного файла.
Строка
RPN-представления,
полученная
на
выходе
лексического
анализатора, вместо распознанных лексем содержит только их числовые
идентификаторы из соответствующей таблицы, заключенные в угловые скобки.
3.6.2. Таблицы лексем.
Таблицы лексем МПП содержат пронумерованное описание всех
распознанных неделимых элементов программной постановки задачи с их
качественными характеристиками. МПП различает 6 типов лексем:
1.
«управление» (CTRL)
2.
«траектория» (TRAJ)
3.
«время» (TIME)
4.
«коэффициент» (VARCONST)
5.
«константа» (CONST)
6.
«постановочный параметр» (PRP)  лексемы данного типа, ввиду
их
отсутствия
в
первоначальной
постановке
задачи,
не
распознаются анализатором, а вводятся супервайзером Базы Знаний
на этапе работы RPN-фильтра.
Каждая таблица содержит количество строк, равное количеству
распознанных лексем и четыре столбца:
92
Имя столбца
Содержимое
Уникальный числовой идентификатор (порядковый номер)
ID
распознанной
символов
лексемы
в
потоке
математического
обрабатываемых
выражения
из
МПП
программной
постановки задачи
TYPE
Тип лексемы
VAL
Значение лексемы в обозначениях пользователя. Данное поле
заполняется только для лексем типа CTRL или TRAJ, во всех
остальных случаях содержит NULL.
PVAL
Значение лексемы в обозначениях программного комплекса
Наличие в таблицах лексем привязки имен переменных программного
комплекса (PVAL) к переменным пользователя (VAL), позволяет последнему
решать задачу в привычных для него обозначениях, облегчая процедуру
отчуждения от разработчика. В этих же целях при лексическом разборе
различаются
понятия
«коэффициента»
и
«константы».
Это
позволяет
пользователю применять широко распространенный способ записи модели, при
котором некоторые элементы программной постановки задачи содержат только
имена коэффициентов, а значения им присваиваются в отдельном фрагменте
программного кода.
Таблицы
лексем
также
используются
в
элементах
интерфейса
пользователя (мониторинг вычислительного процесса, легенды графиков,
протоколы решения задачи и т. д.) везде, где требуется осуществить увязку
имен фазовых переменных и управлений, определенных пользователем к
именам соответствующих переменных и массивов, в действительности
используемых программным комплексом при проведении вычислений.
Далее, при ссылке на определенную ячейку таблицы лексем, будем
использовать обозначение вида <id>.name, где id – идентификатор лексемы, а
name- имя столбца.
93
Таблицы лексем хранятся в Базе Фактов ИДП в виде утверждений,
составленных по шаблону:
(deftemplate lex
(slot id (type INTEGER))
(slot type)
(slot val)
(slot pval)
)
3.6.3. RPN-фильтр
RPN-фильтр
представляет
собой
обработчик
RPN-представления
математического выражения программной постановки задачи. На текущем
этапе развития автоматизирует процессы pf-, uf- и двух видов pDпараметризаций выражения путем модификации его RPN-представления по
следующим правилам:
Параметризация
Входной элемент
Выходная строка (RPN)
pf
`\0`, символ конца строки
`<prp_id> × \0`
uf
`<id>`, <id>.type=CTRL
`< prp_id > <id> ×`
pD
`F1`, F1::=`ASIN`|`ACOS` | `< prp_id > × F1`
`TAN`
pD
`F2`, F2::=`SQRT` | `LOG` `< prp_id > + F2`
| `LOG10` | `/`
Здесь
<prp_id>

числовой
идентификатор
соответствующего
постановочного параметра из таблицы лексем.
На данном этапе развития МПП более простые для автоматической
обработки типы параметризации uBox, stab и x0 осуществляются без его
использования путем парсинга (поиска с заменой) оставшейся части
программного
кода
постановки
задачи.
Парсинг
осуществляется
по
специальным тегам – кодовым словам, открывающим и закрывающим
соответствующие участки кода программной постановки.
94
3.6.4. Менеджер стеков
Менеджер стеков – компонент МПП, реализующий программный
интерфейс работы со стеками и предназначен для для 1) приведения
«параметризованного»
RPN-представления
в
традиционный
инфиксный
формат, соответствующий языку программирования; 2) определения наличия
свойств линейности/билинейности исходной задачи.
Стек в МПП представляет собой объект, сочетающий в себе особый
безадресный тип памяти с методами добавления, модификации и удаления
значений ее ячеек. Каждая такая ячейка носит название регистра стека и
представляет собой нетипизированный массив (хэш), первый элемент которого
содержит строку (последовательность символов), а второй и третий элементы
содержат
по 1 байту информации, кодирующей выполнение свойства
линейности выражения, содержащегося в первом элементе массива по фазовым
переменным и управлениям соответственно. На рис. 3.11 приведен пример
регистра стека.
(C*x[0]+D)/u[0]+u[1]*SIN(x[1])+x[3] 00001001B 00000010B
Wi
Ui
Xi
i
r
Рис. 3.11. Регистр стека.
В данном примере выражение
Cx1  D
 u 2 sin( x2 )  x4 , содержащееся в
u1
переменной W i в виде кода на языке С, линейно по x[0] и x[3] (в
обозначениях пользователя, соответственно, по x1 и x 4 ), что кодируется
установкой 1 в 0-м и 3-м бите переменной X i . Линейность данного выражения
также и по u[1] (в обозначениях пользователя по u 2 ) аналогичным способом
кодируется в переменной U i .
Регистры стека нумеруются «сверху вниз» 0 до N, где N носит название
глубины стека. Обработка RPN-представлений компонент программной
95
постановки
задачи
на стеке
осуществляется
путем последовательного
выполнения стековых операций, выбираемых в зависимости от характера
элементов, поступающих на вход менеджера. Эти элементы подразделяются на
три категории:
Категория 1. Выделенные с помощью лексического анализатора лексемы.
Категория 2. Символы бинарных математических операций `+`,`-`,`×`,`/`,`^`.
Категория 3. Обозначения одноместных элементарных математических
функций `SIN`, `COS`,`TAN`, `ASIN`,`ACOS`, `ATAN`, `EXP`, `LOG`, `LOG10`,
`SQRT`.
Для определения стековых операций введем n-местную функцию
конкатенации значений строковых переменных C ( s1 , s2 ,..., sn ) '[ s1 ][ s2 ]...[sn ]' ,
где s1 , s2 ,..., sn - некоторые строковые переменные, а [ s1 ], [ s 2 ],...,[ s n ] - их
значения (фиксированные строки). Также, нам понадобится функция
0, если s является подсловом S
E ( s, S )  
;
1, в противном случае
Введем следующие обозначения:
W i , X i , U i  компоненты i-го регистра стека до проведения операции;
(W i ) , ( X i ) , (U i )  компоненты i-го регистра стека после проведения
операции;
X ki , U ki , ( X ki ), (U ki )  k-е биты значений переменных X i , U i до и после
проведения стековой операции соответственно;
&,  операции побитового логического умножения и сложения
соответственно.
Приведем
шесть
утверждений,
касающихся
влияния
основных
математических операций на свойство линейности выражения:
1.
Выражение, не содержащее какую-либо переменную или состоящее
только из нее самой, является линейным по этой переменной.
2.
Унарные нелинейные математические операции, отнесенные к 3-й
категории не нарушают линейности результирующего (полученного в
96
результате выполнения операции) выражения по некоторой переменной,
только если эта переменная не присутствует в выражении, являющемся
операндом для этих операций.
3.
Выражение, полученное в результате операций '' или '' , будет
линейно по некоторой переменной, если выражения, представляющие
операнды этих операций являются линейными по этой переменной.
4.
Выражение, полученное в результате операции ' /' , будет линейно по
некоторой переменной, если выражение, представляющее первый
операнд этой операции является линейным по этой переменной, а
выражение,
являющееся
вторым
операндом
не
содержит
эту
переменную.
5.
Выражение, полученное в результате операции ' ^ ' будет нелинейным по
некоторой переменной , за исключением того случая, когда оба операнда
не содержат этой переменной
6.
Выражение, полученное в результате операции '' , будет линейно по
некоторой переменной, если выражение, представляющее один из
операндов является линейным по этой переменной, а выражение,
представляющее другой операнд не содержит эту переменную.
На основании данных утверждений введем следующие стековые
операции:
Вход: `<id>`
Категория: 1
Операция: PUSH
Назначение: Запись лексемы в стек
W
(W 0 ) =<id>.pval; (W i )  W i 1 , i  1,2,...
X
( X 0 )  11111111 B; ( X i )  X i 1 , i  1,2,...
U
(U 0 )  11111111 B; (U i )  U i 1 , i  1,2,...
Вход: `+`
Категория: 2
97
Операция: SUM
Назначение: Запись и анализ суммы выражений
W
(W 0 ) =С(W 1 ,``,W 0 ); (W i )  W i 1 , i  1,2,...
X
( X 0 )  X 1 & X 0 ; ( X i )  X i 1 , i  1,2,...
U
(U 0 )  U 1 & U 0 ; (U i )  U i 1 , i  1,2,...
Категория: 2
Вход: ``
Операция: DIFF
Назначение: Запись и анализ разности выражений
W
(W 0 ) =С(W 1 ,``,W 0 ); (W i )  W i 1 , i  1,2,...
X
( X 0 )  X 1 & X 0 ; ( X i )  X i 1 , i  1,2,...
U
(U 0 )  U 1 & U 0 ; (U i )  U i 1 , i  1,2,...
Вход: `×`
Категория: 2
Операция: MULT
Назначение: Запись и анализ произведения выражений
(W 0 ) =С( `(`, W 1 ,`) * (`, W 0 ,`)`); (W i )  W i 1 , i  1,2,...
W
X
U
( X 0 )   2 k [ X k1 & X k0 & ( E (C (`x[`, k ,`]`),W 0 )  E (C (`x[`, k ,`]`),W 1 ))] ;
k
( X i )  X i 1 , i  1,2,...
(U 0 )   2 k [U k1 & U k0 & ( E (C (`u[`, k ,`]`),W 0 )  E (C (`u[`, k ,`]`),W 1 ))] ;
k
(U i )  U i 1 , i  1,2,...
Вход: `/`
Категория: 2
Операция: DIV
98
Назначение: Запись и анализ частного выражений
W
(W 0 ) =С( `(`, W 1 ,`) /(`, W 0 ,`)`); (W i )  W i 1 , i  1,2,...
X
( X 0 )   2 k [ X k1 & E (C (`x[`, k ,`]`),W 0 )] ; ( X i )  X i 1 , i  1,2,...
U
(U 0 )   2 k [U k1 & E (C (`u[`, k ,`]`),W 0 )] ; (U i )  U i 1 , i  1,2,...
k
k
Вход: `^`
Категория: 2
Операция: POW
Назначение: Запись и анализ показательно-степенной функции
(W 0 ) = C (`POW (`,W 1 ,`,`,W 0 ,`)`) ; (W i )  W i 1 , i  1,2,...
W
( X 0 )   2 k [ E (C (`x[`, k ,`]`),W 1 ) & E (C (`x[`, k ,`]`),W 0 )];
X
k
( X i )  X i 1 , i  1,2,...
(U 0 )   2 k [ E (C (`u[`, k ,`]`),U 1 ) & E (C (`u[`, k ,`]`),U 0 )]
U
k
(U i )  U i 1 , i  1,2,...
Вход: `log`
Категория: 3
Операция: LOG
Назначение: Запись и анализ натурального логарифма
W
(W 0 ) = C (`LOG (`, W 0 `,`)`) , (W i )  W i , i  1,2,...
X
( X 0 )   2 k E (C (`x[`, k ,`]`),W 0 ); ( X i )  X i , i  1,2,...
U
(U 0 )   2 k E (C (`u[`, k ,`]`),W 0 ); (U i )  U i , i  1,2,...
k
k
Запись остальных стековых операций 3-й категории производится
аналогично операции LOG.
99
В результате последовательной
представления
обработки всего входного
RPN-
в переменной W 0 будет содержаться выходная строка
программного кода в инфиксном формате, содержащая все требуемые
постановочные параметры, а в переменных
X 0 и U 0  информация о
линейности результирующего выражения по траекториям и управлениям.
3.6.5. Функционирование МПП
Приведем пример работы МПП, параметризовав тестовое выражение,
описывающее компоненту вектора правых частей динамической системы:
At  B

Здесь переменная
log(sin( Cx  y))
3,001  4 x
определена пользователем, как управление,
переменные x, y – траектории, A, B и С – числовые коэффициенты модели.
Соответствующая запись программной постановки на языке С имеет вид:
A*t+B*w*log(sin(C*x+y))/(3.001+4*x)
После
разбора
данного
выражения
лексическим
анализатором
формируется следующая таблица лексем:
ID
1
2
3
4
5
6
7
8
9
TYPE
VARCONST
TIME
VARCONST
CTRL
VARCONST
TRAJ
TRAJ
CONST
CONST
VAL
A
t
B
w
C
x
y
3.001
4
PVAL
A
t
B
u[0]
C
x[0]
x[1]
3.001
4
Параллельно с формированием таблицы строится RPN-представление
рассматриваемого выражения, в котором вместо распознанных анализатором
лексем вписаны их соответствующие уникальные числовые идентификаторы из
таблицы:
<1> <2> × <3> <4> <5> <6> × <7> + sin log <8> <9> <6> × + / × × +
100
Полученное RPN-представление подается на RPN-фильтр, на выходе из
которого оно принимает вид:
<1> <2> × <3> <10> <4> × <5> <6> × <7> + sin <11> + log <8> <9> <6> × + <12> + / × × + <13> ×
При
этом
в
таблицу
лексем
добавляются
следующие
строки,
описывающие 4 введенных в выражение постановочных параметра:
ID
10
11
12
13
TYPE
PRP
PRP
PRP
PRP
VAL
p1
p2
p3
p4
PVAL
p1
p2
p3
p4
В Базу Фактов добавляются элементы, описывающие аппроксимирующие
семейства ЗОУ, соответствующие только что введенным в задачу параметрам:
(p
(p
(p
(p
(name
(name
(name
(name
p1)(type
p2)(type
p3)(type
p4)(type
Далее,
uf)(p0
pD)(p0
pD)(p0
pf)(p0
NULL)(pa
NULL)(pa
NULL)(pa
NULL)(pa
модифицированное
1000)(status none)(priority 3))
0)(status none)(priority 5))
0)(status none)(priority 5))
1000)(status none)(priority 1))
при
RPN-представление,
помощи
соответствующих стековых операций, поэлементно обрабатывается на стеке.
Порядок осуществления стековых операций определяется последовательностью
элементов RPN-представления.
Вх: <1>
Операция: PUSH
W0
A
X0
11B
U0
Вх: <2>
Операция: PUSH
11B
W0
W1
X1
U1
W1
W2
X2
U2
W2
Вх: <10>
Операция: PUSH
W0
W1
p1
B
W2
X0
X1
11B
U0
U1
11B
X3
11B
X1
11B
11B
U0
U1
11B
11B
U2
X2
11B
W0
X0
W1
X1
u[0]
p1
W2
11B
U3
A
X0
Вх: <4>
Операция: PUSH
U2
X2
A*t
W3
11B
t
Вх: ×
Операция: MULT
11B
11B
B
A*t
U1
11B
11B
11B
11B
X0
W1
X1
U1
W1
X1
W2
X2
U2
W2
X2
A*t
11B
W0
X0
W1
X1
p1*u[0]
B
W2
11B
U0
11B
101
11B
11B
W0
11B
U0
U1
11B
X3
B
A*t
11B
11B
U2
X2
A*t
W3
U3
X3
W0
Вх: ×
Операция: MULT
U2
X2
W3
U0
Вх: <3>
Операция: PUSH
11B
U3
X0
11B
11B
U0
U1
U2
11B
11B
Вх: <5>
Операция: PUSH
W0
C
X0
W1
X1
W2
X2
p1*u[0]
B
W3
11B
11B
11B
A*t
U0
W0
U1
W1
U2
W2
11B
11B
11B
11B
X1
C
B
x[1]
X0
W1
X1
W2
X2
C*x[0]
p1*u[0]
W3
11B
11B
11B
B
W4
11B
A*t
11B
U2
W2
X2
p1*u[0]
B
W1
X1
U2
W2
11B
p1*u[0]
B
A*t
A*t
11B
11B
11B
U3
11B
11B
U4
X4
11B
U0
W0
X0
U1
W1
X1
U2
W2
11B
11B
X4
SIN(C*x[0]+x[1])
p1*u[0]
B
11B
A*t
X0
X2
SIN(C*x[0]+x[1])
p1*u[0]
W3
11B
00B
U1
11B
B
11B
11B
11B
U4
X4
W0
SIN(C*x[0]+x[1])+p2
W1
p1*u[0]
W2
11B
00B
11B
U1
11B
A*t
W4
U0
11B
11B
U3
11B
X4
11B
U2
X3
11B
11B
X1
B
W3
U4
X0
X2
11B
U3
X4
A*t
U0
U2
X3
W4
11B
U4
11B
Вх: log
Операция: LOG
Вх: <8>
Операция: PUSH
LOG(SIN(C*x[0]+x[1])+p2)
p1*u[0]
W2
B
W3
X0
U0
W0
X1
U1
W1
X2
U2
W2
00B
11B
11B
X3
A*t
W4
11B
X4
11B
11B
3.001
LOG(SIN(C*x[0]+x[1])+p2)
p1*u[0]
W3
Вх: <9>
Операция: PUSH
00B
U1
11B
B
W4
U0
11B
11B
U2
11B
U3
X3
11B
U4
X1
11B
X2
11B
U3
X0
11B
11B
U4
X4
A*t
11B
11B
Вх: <6>
Операция: PUSH
4
3.001
W2
LOG(SIN(C*x[0]+x[1])+p2)
W3
X0
U0
W0
X1
U1
W1
X2
U2
W2
11B
11B
00B
X3
p1*u[0]
W4
11B
X4
B
W5
11B
X5
A*t
W6
11B
Вх: +
Операция: SUM
W2
W1
11B
U3
11B
W4
11B
11B
X1
W0
U1
U2
X3
11B
U0
11B
W3
U4
00B
X2
11B
U3
11B
W4
11B
11B
X3
11B
U1
U2
X3
W4
11B
W3
11B
U0
11B
W3
11B
X2
11B
11B
Вх: sin
Операция: SIN
U1
C*x[0]+x[1]
X0
C*x[0]
11B
11B
X0
p2
W1
X1
U4
W0
11B
W1
W0
W1
11B
X4
Вх: <11>
Операция: PUSH
W0
U1
U3
U0
U4
X4
W0
Вх: +
Операция: SUM
U3
X3
11B
11B
W4
U0
11B
11B
A*t
W0
11B
X3
11B
Вх: <7>
Операция: PUSH
Вх: ×
Операция: MULT
X2
p1*u[0]
U4
X4
X0
x[0]
W3
U3
X3
W4
Вх: <6>
Операция: PUSH
11B
X6
11B
11B
11B
U3
X1
11B
11B
11B
11B
11B
U5
11B
11B
U6
X6
A*t
11B
U4
X5
B
11B
U3
00B
p1*u[0]
W6
U1
11B
X4
W5
U0
U2
X3
LOG(SIN(C*x[0]+x[1])+p2)
102
11B
X2
W4
11B
U6
X0
3.001
11B
U5
4
W3
11B
U4
x[0]
11B
11B
Вх: ×
Операция: MULT
W0
Вх: +
Операция: SUM
4*x[0]
W1
3.001
W2
LOG(SIN(C*x[0]+x[1])+p2)
W3
X0
U0
W0
X1
U1
W1
X2
U2
W2
11B
11B
00B
X3
p1*u[0]
W4
11B
X4
B
W5
11B
X5
A*t
11B
11B
11B
p1*u[0]
W3
00B
3.001+4*x[0]
W2
LOG(SIN(C*x[0]+x[1])+p2)
W3
p1*u[0]
W4
U0
W0
X1
U1
W1
X2
U2
W2
11B
11B
00B
11B
X4
B
W5
11B
X5
A*t
11B
11B
11B
11B
11B
U3
3.001+4*x[0]+p3
LOG(SIN(C*x[0]+x[1])+p2)
11B
00B
11B
p1*u[0]
W2
B
W3
A*t
X1
X2
X3
00B
11B
11B
11B
U0
U1
U2
U3
11B
11B
11B
11B
Вх: ×
Операция: MULT
p1*u[0]*(LOG(SIN(C*x[0]+x[1])+p2))/(3.001+4*x[0]+p3)
W1
B
W2
A*t
X0
X1
X2
00B
11B
11B
U0
U1
U2
11B
11B
11B
Вх: ×
Операция: MULT
B*p1*u[0]*(LOG(SIN(C*x[0]+x[1])+p2))/(3.001+4*x[0]+p3)
W1
A*t
X0
X1
00B
11B
U0
U1
11B
11B
Вх: +
Операция: SUM
W0
A*t+B*p1*u[0]*(LOG(SIN(C*x[0]+x[1])+p2))/(3.001+4*x[0]+p3)
X0
00B
U0
11B
Вх: <13>
Операция: PUSH
W0
W1
p4
A*t+B*p1*u[0]*(LOG(SIN(C*x[0]+x[1])+p2))/(3.001+4*x[0]+p3)
103
X0
X1
11B
00B
U0
U1
11B
U5
11B
X0
11B
U4
X5
(LOG(SIN(C*x[0]+x[1])+p2))/(3.001+4*x[0]+p3)
11B
11B
11B
A*t
11B
U3
X4
W5
U1
11B
B
W4
U0
U2
X3
11B
U5
X1
p1*u[0]
11B
U4
X0
X2
W3
W1
W0
11B
U5
X5
Вх: /
Операция: DIV
W0
11B
U4
11B
X0
X3
W0
11B
11B
11B
A*t
11B
U3
X4
W5
U1
11B
B
W4
U0
U2
X3
11B
U5
X1
11B
X2
11B
U4
X0
Вх: +
Операция: SUM
p3
W1
LOG(SIN(C*x[0]+x[1])+p2)
11B
U3
Вх: <12>
Операция: PUSH
W0
3.001+4*x[0]
11B
11B
Вх: ×
Операция: MULT
W0
(A*t+B*p1*u[0]*(LOG(SIN(C*x[0]+x[1])+p2))/(3.001+4*x[0]+p3))*p4
X0
00B
U0
11B
По окончании обработки RPN-представления значение переменной W 0
соответствует записи на языке C математического выражения:

log(sin( Cx1  x2 )  p 2 ) 
 At  Bp1u
 p 4 , где x1  x, x2  y, u  w .
3
,
001

4
x

p
1
3


Значение
переменной
X 0 =00B,
говорит
о
нелинейности
параметризованного выражения по обеим траекториям, а U 0 =11B о его
линейности по управлениям.
3.7 Исполнительный модуль.
Исполнительный модуль, в рамках описываемой архитектуры состоит из
двух компонент:
Компоновщик  управляет процессом создания исполняемого файла
(вычислителя). Простым примером компоновщика может служить bat-файл,
вызывающий требуемый компилятор с набором необходимых параметров
(ключей управления процессом компиляции и сборки, имен файлов исходного
кода, в том числе, содержащих программную постановку задачи);
Вычислитель  исполняемый файл, созданный компоновщиком и
реализующий ряд алгоритмов и, возможно, несколько комплексных схем
решения ЗОУ.
3.7.1. Требования к вычислительному модулю
Для работы в рамках автоматизированной системы с использованием
ИДП исполнительный модуль должен удовлетворять ряду следующих
требований:

отсутствие
либо
возможность
отключения
графического
(псевдографического) интерфейса пользователя в вычислителе;
104

возможность использования вычислителем стандартного потока вывода
STDOUT для взаимодействия с ИДП по специальному протоколу (см.
разд. 3.7.3);

исходный
код
вычислителя
должен
быть
по
согласованию
с
разработчиком ИДП дополнен датчиками нештатных ситуаций; в случае
невозможности установки датчиков во всех требуемых участках кода,
допускается установка единственного датчика, фиксирующего «общий»
АВОСТ;
Разработчику ИДП должны быть сообщены:

язык
программирования,
на
котором
написан
вычислитель
(FORTRAN, ANSI C, C++) и его версия;

имена и назначение всех переменных
(массивов) и функций
технологической постановки задачи, а также места их размещения
(инициализации) в файлах исходного кода вычислителя;

правила работы компоновщика;

имена и форматы входных и выходных файлов вычислителя.
3.7.2. Вычислитель OPTCON-III
В качестве вычислителя в исполнительном модуле рассматриваемой
автоматизированной системы используется вычислительное ядро OPTCON-III
(версия 2.2, ноябрь 2006), разработанное А.Ю. Горновым и Т.С. Зароднюк.
Ниже приведен список методов, реализация которых включена в данный
комплекс.
Методы безусловной оптимизации:

алгоритмы, основанные на принципе максимума;

алгоритмы сопряженного градиента;

овражный алгоритм Нестерова;

Spectral Projected Gradient Евтушенко;

алгоритм выпуклых оболочек;

квазиньютоновский алгоритм BFGS;
105

алгоритм Ньютона;

алгоритм покоординатного спуска;

поисковый алгоритм Пауэлла.
Методы учета параллелепипедных ограничений:

алгоритм условного градиента;

алгоритм проекции градиента;

алгоритмы неэквивалентных преобразований.
Методы учета терминальных ограничений:

алгоритм внешних штрафных функций;

алгоритм модифицированной функции Лагранжа;

алгоритм линеаризации;

алгоритм точной дифференцируемой штрафной функции.
Методы учета фазовых ограничений:

алгоритм внешних штрафных функционалов;

алгоритм функциональных множителей Лагранжа;

алгоритм параметризации ограничений;

алгоритм нелинейного приведенного градиента.
Для исследования нелокальных свойств ЗОУ в ядре OPTCON-III
реализованы также четыре глобализующих технологии:
1.
метод случайного мультистарта, позволяющий с высокой вероятностью
находить глобальный экстремум целевого функционала и все локальные,
оценивать размеры областей притяжения экстремумов,
оценивать
вероятности нахождения новых экстремумов, визуализировать множество
достижимости системы (МД) и процесс решения;
2.
метод редукции к задаче математического программирования. Строится
последовательность аппроксимирующих задач для исходной ЗОУ, в
которых
постепенно
увеличивается
соответственно, размерности
точность
вспомогательных
106
приближения
и,
задач. Для поиска
глобального экстремума в аппроксимирующих задачах конечномерной
оптимизации используются комбинации методов случайного поиска и
методов покоординатного спуска.
3.
на основе модификации классического метода «сеток» решения
невыпуклых экстремальных задач [g111]. На первом этапе генерируется
априори заданное количество случайных начальных управлений и в этих
точках вычисляется значение целевого функциоала. На втором этапе
приозводистя спуск локальными методами, начиная с наилучшего
управления, найденного на первом этапе.
4.
На
основе
методов
«овыпукления».
Вместо
исходной
задачи
рассматривается расширенная задача оптимального управления большой
размерности,
исходной
оптимальной решение которой совпадает с решением
задачи
(в
соответствии
с
известными
теоретическими
результатами [?Гамкрелидзе, Кларк, Толстоногов, Мордухович,…].
Решение
овыпукленной
задачи
также
производится
локальными
методами.
С
целью
контроля
сформированной
пользователем
постановки задачи, а также получения оценок
программной
качества дискретизации и
окончательного решения в OPTCON-III реализованы следующие алгоритмы
верификации компонентов ЗОУ:

алгоритм ревизии данных;

алгоритм ревизии формул;

алгоритм верификации аналитических формул для производных;

алгоритм подбора метода интегрирования;

алгоритм оценки погрешности интегрирования;

алгоритм оценки погрешности дискретизации;

алгоритм постоптимизационного анализа.
107
Вычислительное ядро OPTCON-III также предлагает пользователю
возможность
использования
шести
следующих
специализированных
алгоритмических схем, ориентированных на решение определенных классов
задач:
1. классическая схема для задач с терминальными ограничениями: метод
внешних штрафных функций – метод модифицированной функции
Лагранжа – метод линеаризации.
2. схема для задач с релейными управлениями и близким к ним: метод
принципа максимума  метод сопряженного градиента – метод
приведенного градиента.
3. схема для задач с фазовыми ограничениями: метод внешних штрафных
функционалов – метод параметризации ограничений – метод проекции
градиента.
4. схема для задач оптимизации по параметрам: метод Пауэлла – метод
сопряженного
градиента
–
квазиньютоновский
метод
BFGS
–
декомпозиция оптимизируемого множества.
5. схема для сингулярно-возмущенных задач:
поиск магистрального
приближения – декомпозиция по интервалу времени  метод принципа
максимума – метод сопряженного градиента.
6. схема для общей задачи:
метод сопряженного градиента – метод
проекции градиента – метод модифицированной функции Лагранжа –
параметризация фазовых ограничений – последовательная дискретизация.
3.7.3. Протокол взаимодействия с ИДП
Как было уже подробно описано в п. 3.5.5, для передачи информации о
ходе итерационного процесса в ИДП
Вычислитель использует свой
стандартный поток вывода STDOUT. Вывод оформлен в стиле XML-документа
со следующей спецификацией:
Имя тэга: <task>
Дочерние тэги: <iter>
108
Описание: Корневой тэг документа. Начальная информация о задаче.
Атрибуты:
Имя
формат
описание
Pid
%i
Идентификатор процесса Вычислителя
Name
%s
Имя задачи
Nu
%i
Размерность вектора управления
Nx
%i
Размерность вектора траектории
t0
%18.10e
Начальный момент времени
t1
%18.10e
Конечный момент времени
N
%i
Число точек дискретизации
Имя тэга: <iter>
Дочерние тэги: <u>
Описание: Результат итерации вычислительного процесса
Атрибуты:
имя
формат
описание
seq
%i
Номер итерации
res
ok|fail
Результат итерации
func
%18.10e
Значение функционала
failtype
IM | DM |
Тип нештатной ситуации:
ZM | OM |
IM  нарушение области определения
UM |PM |
элементарной математической функции;
COMMON
DM  денормализованный операнд;
ZM  деление на ноль;
OM  переполнение;
UM  антипереполнение;
PM  нарушение точности представления
результата;
COMMON  общий сбой программы.
location df | dpsi | Область возникновения нештатной ситуации:
func |
df  интегрирование прямой системы;
resr | deriv
dpsi  интегрирование сопряженной системы;
func  вычисление функционала;
restr  вычисление функций ограничений;
deriv  вычисление производных функций.
Дочерние тэги: нет
Имя тэга: <u>
Описание: Новое управление, полученное на итерации
Атрибуты:
имя
формат
описание
n
%i
Номер точки дискретизации
t
%18.10e
Значение переменной времени в данной точке
дискретизации
109
%18.10e[:%18.10e]… Значения компонент вектора управления в
val
данной точке дискретизации
Числовой формат данных в значениях атрибутов совпадает с тем,
который используется в C-функциях printf(), fprintf() и т. д.
Ниже представлен пример вывода Вычислителя:
<?xml version="1.0"?>
<task pid='3456' name='test04' nu='2' nx='3' t0='0.0000000000e+00' t1='3.0000000000e+00' N='301'>
<iter seq='0' res='ok' func='2.2099561687e-03' />
<u n='0' t='0.0000000000e+00' val='-9.906677546e-01:1.1453908976e+00' />
<u n='1' t='1.0000000000e-02' val='-9.929232978e-01:1.1488398555e+00' />
...
<u n='300' t='3.0000000000e+00' val='-1.148839857e-02:-1.876583007e-04' />
</iter>
...
<iter seq='5' res='fail' failtype='ZM' location='df' />
</task>
Под окончанием 0-й итерациии подразумевается такое состояние
вычислительного процесса при котором:
а)
Интегрированием
динамической
системы
получены
траектории,
соответствующие начальному управлению u 0 ;
б)
на начальных управлениях и траекториях подсчитаны значения целевого
и
вспомогательного
функционала,
а
также
ограничений (если таковые присутствуют в задаче).
110
значения
функций