CC BY
34
Стоимость [$]
1200
Повышение комфорта
1100 1000 900 800 700 600 500 400 300 200
с ______
То1 шиво
К онстру 'ктивнь ю элем енты
А
[
1700 1750 1800 1850 1900 1950 2000 2050 2100 Стоимость жизненного цикла
Рис. 4. Зависимость компонентов стоимости здания от ограничений стоимости жизненного цикла
лизировать, как изменяется структура затрат с увеличением стоимости жизненного цикла: дополнительные затраты идут, в основном, на топливо при относительно постоянной стоимости конструкции.
В заключение отметим, что в работе предложена методология экономии затрат энергии в проектируемых жилых зданиях на основе автоматизированного использования комплексной онтологии теплоснабжения, которая позволяет учесть весь набор факторов и параметров при проектировании, включая субъективные предпочтения разработчика и заказчика.
Программная реализация методологии и ее экспериментальное апробирование на типовом проекте позволяют сделать следующие выводы: а) применение методологии позволяет сократить расход топлива на 35%, что уменьшает расходы на жизненный цикл здания по сравнению с типовым проектом на 10%; б) на достижение подобного эффекта основное влияние оказывают параметры основных ограждающих конструкций; в) оптимальные конструктивные решения для разных соотношений комфортности и стоимости в диапазоне, отвечающем стандартам, довольно близки друг
к другу, что позволяет для схожих по базовым конструктивным решениям зданий, отличающихся соотношением комфортности и стоимости, варьировать только параметрами системы теплоснабжения; г) полученные оптимальные конструктивные параметры превосходят типовое решение по теплозащитным свойствам наружных стен, что свидетельствует о недоучете эксплуатационных затрат при типовом проектировании.
И, наконец, хотелось бы отметить, что так как вычисления осуществлялись приближенными методами, а выбор начальных значений для расчета производился достаточно произвольно, то, на наш взгляд, точность выявленных закономерностей требует дополнительной проверки.
Список литературы
1. Налимов В.В. Вероятностная модель языка. - М.: Наука, 1979.
2. Rousseau P. G., Mathews E. H., Needs and trends in integrated building and HVAC thermal design tools. Building and Environment, 28(4), 439-452, 1993.
3. Clarke J. A. and Maver T. W., Advanced design tools for energy conscious building design: Development and dissemination. Building and Environment, 26, 25-34, 1991.
4. Bevington R., Rosenfeld A. H., Energy for buildings and homes. Scient. Amer., September, 39-45, 1990.
5. Mathews E. H., Richards P. G., An efficient tool for future building design. Building and Environment, 28(4), 409-417, 1993.
6. Ushold M., Gruninger M., "Ontologies: Principles, Methods and Application" Knowledge Engineering Reviw. Vol. 11, No 2, 1996.
7. Алефельд Г., Херцбергер Ю., Введение в интервальные вычисления. /Пер. с англ. -М.:Мир, 1987.
8. Иванищев В.В., Автоматизация моделирования потоковых систем. - Л.: Наука, 1986.
9. Машунин Ю. К., Методы и модели векторной оптимизации. - М.: Наука, 1986.
10. Box M. J., A new method of constrained optimisation and comparison with other methods. The Comp. Journal, 8, 42-52, 1965.
11. SWI-Prolog 2.7, Reference Manual, University of Amsterdam, 1996.
12. Типовой Проект 144-000-669.13.87 ТК-113-4-3 Одноэтажный одноквартирный 3-комнатный мансардный жилой дом. - Госстрой Лит. ССР, 1987.
13. Соснин Ю.П., Бухаркин Е.Н., Отопление и горячее водоснабжение индивидуального дома: Справ. пособие.- М.: Стройиздат, 1993.
МОДЕЛИРОВАНИЕ ПРОЦЕССОВ, УПРАВЛЯЕМЫХ СОБЫТИЯМИ, В СИСТЕМЕ "ДИНАМИКА"
С.А. Бутырин
Система программного обеспечения (СПО) "ДИНАМИКА" [1-4] является интегрированной диалоговой средой языка MATFOR (MATrix FORmula), предназначенной для создания при-
кладных программ в различных областях инженерной деятельности. Она обеспечивает:
• создание моделей объектов предметной области;
• агрегирование объектов;
• численную имитацию процессов в непрерывно-дискретных логико-динамических системах;
• программирование пользовательского интерфейса;
• средства научной графики и документирования.
Входной язык, средства трансляции и организация численного моделирования в СПО "ДИНАМИКА" рассмотрены в [3]. В СПО поддерживается пакетная технология работы, причем каждый пакет прикладных программ поставляется в виде отдельного специализированного архива, содержащего модели и методы предметной области. Элементами архива могут быть модели и задачи.
Модель есть описание на языке MATFOR компонента моделируемой системы, например, в виде набора нелинейных дифференциальных и конечно-разностных уравнений. Для каждой завершенной модели имеется и результат ее трансляции в виде объектного кода в библиотеке с именем архива. Модели компонентов могут объединяться, образуя модели второго и других уровня сложности, модель самого верхнего уровня называется моделью системы.
Задача - это исполняемый (exe-файл), получаемый после трансляции головной программы, которая вызывает модель системы с присоединенным к ней методом интегрирования.
Интегрирование модели системы выполняется в системном времени. Результатом имитации поведения любой модели является некоторый процесс. По умолчанию все модели функционируют в темпе системного времени с момента начала интегрирования. Специальный вид модели - управляемая модель процесса (УМП) имеет булевый выход и может быть как активной, так и не активной. Если модель не активна, то это означает, что процесс либо не начат, либо закончен. Активная модель порождает процесс в соответствии со своей логикой и динамикой в темпе системного времени. Ее собственное время сдвинуто относительно системного на отрезок времени, прошедший от момента начала моделирования до момента запуска процесса. Одна УМП может порождать множество различных процессов, определяемых номером комплекта ее входных и выходных параметров. Число комплектов равно числу однотипных УМП в моделируемом процессе.
В отличие от традиционного подхода, связанного с расширением языка за счет введения в него специальных операторов имитационного моделирования (ИМ) управляемых систем (типа языка SIMULA и др.) или создания интеллектуальной компоненты (например, как в G2 фирмы "Gensym" [5]), поставлена и успешно решена задача разработки инструментария ИМ без расширения вход-
ного языка и изменения системной организации СПО "ДИНАМИКА". Согласно концепции пакетной технологии работы с СПО дополнительные средства лингвистической поддержки и реализованные методы ИМ поставляются в специальном архиве.
Управление имитационной моделью осуществляется с помощью многомерного асинхронного логического автомата (АЛА) с памятью, причем логика формирования его выхода записывается во внешнем файле на специализированном языке. Это позволяет выполнять отладку и верификацию логики управляющего АЛА без перепрограммирования моделируемой системы. Модель АЛА представляется в виде
y = (Pis) (1)
s
v+1 = J sv, sv = 0 v 1 fi(xi,zi), si =-1 '
(2)
где s = (si}, y = (yt} - векторы-столбцы состояния и выхода АЛА; xi = (xj}, j = 1:ki и zi = (zl}, l = 1:ni -множества векторов входов и транзитных (вход/выход) переменных УМП; i = 1:m; m - число УМП.
Компоненты вектор-функции <p(s) выходов АЛА (1) описываются в файле логических условий (ФЛУ) запуска процессов, а функции переходов (2) определяются алгоритмически. Функции fi(xi>zi) представляют собой собственно УМП, при создании которых могут использоваться все возможности языка программирования, в частности, множества xi и zi могут включать переменные любых допустимых в MATFOR размеров и типов.
Процесс управления моделью системы наглядно представляется в виде схемы, где одинарными стрелками показаны связи по данным, а двойными - связи по управлению. Основную роль здесь играет системная программа EVENT, представляющая собой интерпретатор логических формул из ФЛУ. Этот файл считывается в память и предварительно обрабатывается единственный раз в момент начала моделирования, при этом выполняется синтаксический разбор логических формул и в оперативной памяти создаются соответствующие таблицы для быстрого вычисления значений формул в процессе имитации.
При каждом вызове EVENT формируется вектор единичных импульсных сигналов для тех процессов, условия запуска которых выполнены. Для обеспечения одновременности запуска мгновенных (в общем случае зависимых друг от друга) процессов модель системы вызывается m раз. Если на i-м вызове внутреннего цикла на схеме не запущен ни один процесс, то цикл прерывается.
Языковые средства. Для записи логических условий запуска процессов в моделируемой системы разработан специальный язык, модифициро-
ванная нормальная форма Бэкуса-Наура имеет вид:
<слагаемое>=<множитель>?<множитель>
<множитель>=<терм>&<терм> <терм>=1<слагаемое> 1<процесс> 1+<процесс>1--<процесс> 1(<слагаемое>)
<процесс>=<цифра> {<цифра>} <цифра>=0111213141516171819. В реализованной версии каждому процессу присваивается номер, соответствующий номеру строки в ФЛУ. Знак (-) перед таким номером означает, что процесс не начат, знак (+), что он завершен, а отсутствие знака означает, что процесс начат, но не завершен (продолжается). Знаки логических отношений включают операции классического базиса: & - "и", ? - "или", ! - "не". Алфавит языка можно изменять, например легко перейти от числовых обозначений процессов к некоторому тексту, как это будет показано ниже.
Текстуально ФЛУ оформляется в виде таблицы 1, которая содержит 5 колонок, а именно: номер процесса; алиас имени процесса; параметры; логические условия запуска; комментарий. Если процессов много, то они могут разбиваться на нумерованные секции (логически завершенные участки - отдельные АЛА) начинающиеся с символа #. Внутри каждой такой секции процессы нумеруются, начиная с 1. Второй и третий столбцы таблицы содержат алиас имени УМП и значения его параметров. Соответствие алиаса действительному имени УМП (по правилам языка ИЛТЕОК) и число параметров процесса указываются в отдельном файле.
В приведенном в таблице 1 примере приводится часть временной диаграммы функционирования системы управления движением космического аппарата (КА). Этот фрагмент соответствует режиму определения ориентации КА в пространстве - построения инерциальной системы координат (ИСК), что основано на поиске навигационной звезды (З), которую необходимо "пой-
мать" в поле зрения (ПЗ) датчика звезды (ДЗ). После необходимой подготовки ДЗ включается (процесс 1) и выполняется несколько пространственных эволюций (программных поворотов (ПП) и поисковых вращений) с различными режимами работы ДЗ с целью найти З (процессы 2-12) и определить ее координаты в ПЗ датчика. Если З найдена, то определяется ориентация КА в пространстве (процесс 14) и ДЗ выключается, при этом выставляется признак нормального завершения режима 0 (процесс 15). Если З не найдена, то ДЗ выключается и устанавливается признак аварийного завершения режима 1 или 2 (процессы 16-17).
Приведем пример расшифровки условий запуска процесса 17 на формальном уровне:
[Если] "процесс 6 завершен" и "процесс 4 продолжается " и " процесс 7 не начат", [то] "запустить процесс 17".
Если вместо "процесс N ..." подставить комментарий, то получится содержательная расшифровка:
[Если] "поисковое вращение закончено" и "продолжается ожидание АО" и "2-й ПП не начинался ", [то] "выключить ДЗ с установкой сигнализатора аварийного завершения режима равного 2 ".
Имеется 2 типа УМП - пользовательские и стандартные. Текст пользовательских УМП создается их разработчиком приложения по определенному шаблону с единственным логическим выходом. При работе приложения коды УМП становятся доступны для выполнения только с момента запуска модели. Шаблон пользовательской УМП имеет секции:
• инициализации, срабатывающей единственный раз при запуске модели;
• выполнения, где разработчик помещает исходные коды модели процесса;
• завершения, в которой выполняются операции в момент окончания процесса.
В секции выполнения должно содержаться условие завершения процесса, а именно присвоение ее выходу значения 1 по некоторому логическому условию события, например, if(x > 0.2) s1 = 1, где x - входная, а s1 - выходная переменная модели. В этом примере событие перехода x через значение 0.2 приведет к завершению процесса.
Стандартные УМП:
• проверка абсолютного времени - возвращает 1, когда системное время достигнет заданного значения;
• выдержка времени - возвращает 1 по истечении заданного интервала времени, который от-считывается с момента его включения;
• установка состояния - принудительно устанавливает состояние процесса в 0, -1 или 1;
Таблица 1
№ про- УМП Пара- Логические Комментарий
цесса метры условия
1 Интервал 10 +0 Интервал подго-
говки к вкл. ДЗ
2 Вкл.ДЗ 6 12 +1 Вкл. Датчика З
3 Вкл.РС 7 0 +2 Вкл. Режима "с"
4 Ожидание 1 +2 Ожидание З в ПЗ
5 ПП1 1 120 +2 Первый ПП
6 Вращение 2 +5 Вращение поиска
7 ПП2 2 42 +4&+6 2-й ПП (нашли З)
13 Интервал 31 +4&(+9?+12) Вычисление ИСК
14 ИСК +13&+4 ИСК построен?
15 Выкл.ДЗ 0 +14 Выкл. ДЗ(0)
16 Выкл.ДЗ 1 4&+13 Выкл. ДЗ(1)
17 Выкл.ДЗ 2 +6&4&-7 Выкл. ДЗ(2)
18 КОНЕЦ +15?+16?+17
Таблица 2
№ процесса УМП Параметры Логические условия Комментарий
1 П1 +0
2 Счетчик 10 +1
3 Установка 1 0 2&+1
4 Установка 2 0 2&+1
5 П2 +2
• счетчик - возвращает 1 при достижении заданного количества вызовов;
• исключение процесса из списка - сбрасывает флаг присутствия указанного процесса, если он в этот момент не активен; исключенный процесс не может быть запущен в работу ни при каких условиях;
• включение в список - устанавливает флаг присутствия заданного и ранее исключенного процесса;
• счетчикО - сброс значения УМП счетчик;
• завершение работы.
В примере ФЛУ (см. табл. 1) для обозначения стандартных УМП выдержка времени и завершение работы использованы алиасы "Интервал" и "КОНЕЦ".
Ветвление организуется автоматически по логическим условиям. Циклы в ФЛУ организуются с использованием стандартных УМП управление по счетчику и установка состояния. Пример приведен в таблице 2.
Здесь организован цикл 10 запусков процесса П1. После завершения работы процесса П1 запускается процесс счетчик, который при каждом вызове добавляет к своей внутренней переменной 1, начиная с 0. Пока значение этой переменной не будет равно 10, процесс не будет завершен. Если процесс 2 (счетчик) идет, то после завершения П1 будут выполнены процессы 3 и 4 установки состояния, которые сбросят флаги завершения процессов П1 и счетчик, то есть объявят их невыполненными (первый параметр - номер, а второй -устанавливаемое состояние процесса). Особенностью УМП установки состояния является то, что после выполнения они объявляют невыполненными сами себя. Таким образом, процесс П1 будет запущен 10 раз, после чего процесс счетчик будет завершен (+2) и запустится процесс П2.
Работа программы моделирования процессов, управляемых событиями, происходит в следующей последовательности (см. схему):
• в начальный момент системного времени происходит чтение и обработка ФЛУ, в результате которой: определяется число процессов т; создается и заполняется вектор состояния ж; определяются имена процессов (по алиасам имен); формируются массивы параметров; вектор ж инициализируется нулями; происходит проверка синтаксиса логических формул 4-й колонки ФЛУ, и если об-
наружены ошибки, то выдаются соответствующие сообщения, процесс моделирования прерывается;
• происходит синтаксический разбор логических формул (раскрытие скобок, эквивалентиро-вание и др.) и заполняются соответствующие структуры данных для вычисления их значений (число переменных в логической формуле, номера входящих в нее элементов вектора s, коды логических отношений и др.);
• далее работает основной цикл по числу строк ФЛУ m, причем в начале цикла вызывается интерпретатор логических формул EVENT, вычисляющий их значения и формирующий выходной вектор АЛА y в (1) с элементами yi=Qi&Li, где Qb Li - булевы переменные, в том числе Li - значение логического условия в i-й строке ФЛУ, а Qi - результат логического сравнения si с нулем Qi=(si= =0);
• выполнение ФЛУ начинается с запуска процесса с номером нуль, который ничего не выполняет и для которого всегда Q0 = 1 и L0=1;
• при запуске i-го процесса происходит вызов соответствующей УМП (2) и одновременно i-й элемент вектора состояния si выставляется в -1 (признак того, что процесс идет);
• i-й процесс будет продолжаться, пока выход УМП si не будет выставлен в 1 по логике разработчика модели, то есть процесс будет идти и значения транзитных переменных zi будут изменяться до тех пор, пока выражение yiv(si= = -1) остается истинным;
• моделирование заканчивается после выполнения системной УМП завершение работы.
Практическое применение. Описываемый метод был использован, при создании имитационной модели системы управления движением раз-
гонного блока ИКАР ракеты-носителя "Союз" для выведения на орбиту спутников "Globalstar" (в 1999 г. выведено суммарно 24 таких спутника) и в других аналогичных разработках [4].
Список литературы
1. Matrosov V.M, Somov Ye.I, Butyrin S.A, et. al. Software System DYNAMICS - a Tool for Computer-Aided Modelling and Simulation of the spacecrafts Fail-safe Control Systems.// Actual Problems of Aviation and Aerospace Systems, 1997, N1(4), pp. 8-17.
2. Матросов В.М., Козлов Р.И., Сомов Е.И., Бутырин С.А. и др. Методы и программное обеспечение для автомати-
зации проектирования систем управления ориентацией космических аппаратов//Динамика и управление космическими объектами. - Новосибирск: Наука, 1992. - С. 163-179.
3. Бутырин С.А, Герасин С.А, Герасин И.А, Сомов Е.И. Технология создания моделей и задач в системе ДИНАМИКА//Программные продукты и системы. - 1999. -№1. - С. 38-41.
4. Сомов Е.И., Бутырин С.А, Герасин И.А, Герасин С.А. Программное средство ДИНАМИКА в моделировании отказоустойчивых систем управления ориентацией космических аппаратов //Гироскопия и навигация.- 1999. - №2. - С. 92-105.
5. G2 GUIDE. User's Guide, Gensym Corporation, Inc., Cambridge, Mass., USA, 1997.
МОДЕЛИРОВАНИЕ АДАПТАЦИИ В АЛГОРИТМАХ СИНТЕЗА ТОПОЛОГИИ ЭЛЕКТРОННЫХ СИСТЕМ
В.М. Курейчик, А.В. Мухлаев
Термин адаптация известен из биологии как приспособление организма к изменению внешних условий [I]. Наблюдения в области адаптации живых организмов привели к идее наделить указанным свойством технические системы, комплексы программ и т.д. Подразумевается, что такие адаптивные объекты создают предпосылки гибкости при решении задач, а также используют накапливаемый в процессе работы опыт для повышения целесообразности своего функционирования. Как правило, под адаптивной понимают систему, которая работает при наличии частичной (или полной) априорной неопределенности и при изменяющихся внешних условиях, а получаемую в процессе работы информацию об этих условиях использует для повышения эффективности работы.
Адаптация является неотъемлемым качеством интеллекта, а мышление человека - это высшая форма приспособительного процесса [I]. Так как в качестве перспективных направлений развития информационных систем выделяются интеллектуализация и интеграция, то качество адаптивности должно быть присуще и интеллектуализиро-ванным техническим системам, в частности системам автоматизированного проектирования (САПР). То есть интеллектуализация САПР должна привести к качественно новому уровню организации САПР с присущим интеллектуальным системам свойством адаптации. При этом адаптивными связями должны быть затронуты все компоненты интеллектуальной САПР: пакеты прикладных программ решения конструкторских задач, база знаний, система логического вывода, диалоговый интерфейс и т.д. Общепризнано, что высшим проявлением интеллекта (как естественного,
так и искусственного) является творчество, связа-ное, в частности, с проблемой выбора [2], которая, в свою очередь, во многом определяется способностью эффективной адаптации.
Рассматривая адаптацию в САПР как в сложной системе, состоящей из четырех основных компонентов (комплекса технических средств (КТС), комплекса программных средств (КПС), объекта проектирования (ОП) и пользователя (П)), остановимся на адаптации КПС к ОП, которая означает способность САПР приспосабливаться к потоку ОП в изменяющихся условиях с целью достижения оптимального проектирования на основе поступающей априорной и апостериорной информации.
Интерпретируя известную постановку задачи адаптации для систем автоматического управления (САУ) [2], получаем постановку задачи адаптации для САПР. Объектом управления в указанном случае будет служить САПР, а адаптивным регулятором - специальная подсистема адаптации (рис. 1). Пусть каждое получаемое решение при этом динамически оценивается в блоке оценок (БО). Задача адаптации состоит в том, чтобы сформировать в блоке адаптации (БА) последовательность воздействий, экстремизирующих показатели качества получаемых решений (критерии адаптации), то есть где £ - об-
уел
ласть допустимых управлений.
Интересом же данного изложения будет служить апостериорная адаптация, которая применяется при полном отсутствии или скудости априорной адаптации.
Известна классификация ПА в зависимости от свойств объекта адаптации [2]. Модифицируя из-
