Software & Systems

Система программного обеспечения (СПО) "ДИНАМИКА" [1-4] является интегрированной диалоговой средой языка MATFOR (MATrix FORmula), предназначенной для создания прикладных программ в различных областях инженерной деятельности. Она обеспечивает:

·     создание моделей объектов предметной области;

·     агрегирование объектов;

·     численную имитацию процессов в непрерывно-дискретных логико-динамических системах;

·     программирование пользовательского интерфейса;

·     средства научной графики и документирования.

Входной язык, средства трансляции и организация численного моделирования в СПО "ДИНАМИКА" рассмотрены в [3]. В СПО поддерживается пакетная технология работы, причем каждый пакет прикладных программ поставляется в виде отдельного специализированного архива, содержащего модели и методы предметной области. Элементами архива могут быть модели и задачи.

Модель есть описание на языке MATFOR компонента моделируемой системы, например, в виде набора нелинейных дифференциальных и конечно-разностных уравнений. Для каждой завершенной модели имеется и результат ее трансляции в виде объектного кода в библиотеке с именем архива. Модели компонентов могут объединяться, образуя модели второго и других уровней сложности, модель самого верхнего уровня называется моделью системы.

Задача – это исполняемый (exe-файл), получаемый после трансляции головной программы, которая вызывает модель системы с присоединенным к ней методом интегрирования.

Интегрирование модели системы выполняется в системном времени. Результатом имитации поведения любой модели является некоторый процесс. По умолчанию все модели функционируют в темпе системного времени с момента начала интегрирования. Специальный вид модели – управляемая модель процесса (УМП) имеет булевый выход и может быть как активной, так и не активной. Если модель не активна, то это означает, что процесс либо не начат, либо закончен. Активная модель порождает процесс в соответствии со своей логикой и динамикой в темпе системного времени. Ее собственное время сдвинуто относительно системного на отрезок времени, прошедший от момента начала моделирования до момента запуска процесса. Одна УМП может порождать множество различных процессов, определяемых номером комплекта ее входных и выходных параметров. Число комплектов равно числу однотипных УМП в моделируемом процессе.

В отличие от традиционного подхода, связанного с расширением языка за счет введения в него специальных операторов имитационного моделирования (ИМ) управляемых систем (типа языка SIMULA и др.) или создания интеллектуальной компоненты (например, как в G2 фирмы "Gensym" [5]), поставлена и успешно решена задача разработки инструментария ИМ без расширения входного языка и изменения системной организации СПО "ДИНАМИКА". Согласно концепции пакетной технологии работы с СПО дополнительные средства лингвистической поддержки и реализованные методы ИМ поставляются в специальном архиве. Управление имитационной моделью осуществляется с помощью многомерного асинхронного логического автомата (АЛА) с памятью, причем логика формирования его выхода записывается во внешнем файле на специализированном языке. Это позволяет выполнять отладку и верификацию логики управляющего АЛА без перепрограммирования моделируемой системы. Модель АЛА представляется в виде

                                                               (1)

,                      (2)

где s={si }, y={yi } – векторы-столбцы состояния и выхода АЛА; xi={xj }, j=1:ki и zi={zl }, l=1:ni – множества векторов входов и транзитных (вход/выход) переменных УМП; i=1:m; m – число УМП.

Компоненты вектор-функции j(s) выходов АЛА (1) описываются в файле логических условий (ФЛУ) запуска процессов, а функции переходов (2) определяются алгоритмически. Функции fi(xi,zi) представляют собой собственно УМП, при создании которых могут использоваться все возможности языка программирования, в частности, множества xi и zi могут включать переменные любых допустимых в MATFOR размеров и типов.

Процесс управления моделью системы наглядно представляется в виде схемы, где одинарными стрелками показаны связи по данным, а двойными – связи по управлению. Основную роль здесь играет системная программа EVENT, представляющая собой интерпретатор логических формул из ФЛУ. Этот файл считывается в память и предварительно обрабатывается единственный раз в момент начала моделирования, при этом выполняется синтаксический разбор логических формул и в оперативной памяти создаются соответствующие таблицы для быстрого вычисления значений формул в процессе имитации.

При каждом вызове EVENT формируется вектор единичных импульсных сигналов для тех процессов, условия запуска которых выполнены. Для обеспечения одновременности запуска мгновенных (в общем случае зависимых друг от друга) процессов модель системы вызывается m раз. Если на i-м вызове внутреннего цикла на схеме не запущен ни один процесс, то цикл прерывается.

Языковые средства. Для записи логических условий запуска процессов в моделируемой системы разработан специальный язык, модифицированная нормальная форма Бэкуса-Наура имеет вид:

<слагаемое>=<множитель>?<множитель>

<множитель>=<терм>&<терм>

<терм>=|<слагаемое>|<процесс>|+<процесс>|––<процесс> |(<слагаемое>)

<процесс>=<цифра>{<цифра>}

<цифра>=0|1|2|3|4|5|6|7|8|9.

В реализованной версии каждому процессу присваивается номер, соответствующий номеру строки в ФЛУ. Знак (–) перед таким номером означает, что процесс не начат, знак (+), что он завершен, а отсутствие знака означает, что процесс начат, но не завершен (продолжается). Знаки логических отношений включают операции классического базиса: & – "и", ? – "или", ! – "не". Алфавит языка можно изменять, например, легко перейти от числовых обозначений процессов к некоторому тексту, как это будет показано ниже.

Текстуально ФЛУ оформляется в виде таблицы 1, которая содержит 5 колонок, а именно: номер процесса; алиас имени процесса; параметры; логические условия запуска; комментарий. Если процессов много, то они могут разбиваться на нумерованные секции (логически завершенные участки – отдельные АЛА) #N, начинающиеся c символа #. Внутри каждой такой секции процессы нумеруются, начиная с 1. Второй и третий столбцы таблицы содержат алиас имени УМП и значения его параметров. Соответствие алиаса действительному имени УМП (по правилам языка MATFOR) и число параметров процесса указываются в отдельном файле.

В приведенном в таблице 1 примере приводится часть временной диаграммы функционирования системы управления движением космического аппарата (КА). Этот фрагмент соответствует режиму определения ориентации КА в пространстве – построения инерциальной системы координат (ИСК), что основано на поиске навигационной звезды (З), которую необходимо "поймать" в поле зрения (ПЗ) датчика звезды (ДЗ). После необходимой подготовки ДЗ включается (процесс 1) и выполняется несколько пространственных эволюций (программных поворотов (ПП) и поисковых вращений) с различными режимами работы ДЗ с целью найти З (процессы 2-12) и определить ее координаты в ПЗ датчика. Если З найдена, то определяется ориентация КА в пространстве (процесс 14) и ДЗ выключается, при этом выставляется признак нормального завершения режима 0 (процесс 15). Если З не найдена, то ДЗ выключается и устанавливается признак аварийного завершения режима 1 или 2 (процессы 16-17).

Приведем пример расшифровки условий запуска процесса 17 на формальном уровне:

[Если] “процесс 6 завершен” и “процесс 4 продолжается” и “процесс 7 не начат”, [то] “запустить процесс 17”.

Если вместо “процесс N ...” подставить комментарий, то получится содержательная расшифровка:

[Если] “поисковое вращение закончено” и “продолжается ожидание АО” и “2-й ПП не начинался”, [то] “выключить ДЗ c установкой сигнализатора аварийного завершения режима равного 2”.

Имеется 2 типа УМП – пользовательские и стандартные. Текст пользовательских УМП создается их разработчиком приложения по определенному шаблону с единственным логическим выходом. При работе приложения коды УМП становятся доступны для выполнения только с момента запуска модели. Шаблон пользовательской УМП имеет секции:

·     инициализации, срабатывающей единственный раз при запуске модели;

·     выполнения, где разработчик помещает исходные коды модели процесса;

·     завершения, в которой выполняются операции в момент окончания процесса.

В секции выполнения должно содержаться условие завершения процесса, а именно присвоение ее выходу значения 1 по некоторому логическому условию события, например, if(x > 0.2) s1 = 1, где x – входная, а s1 – выходная переменная модели. В этом примере событие перехода x через значение 0.2 приведет к завершению процесса.

Стандартные УМП:

·     проверка абсолютного времени – возвращает 1, когда системное время достигнет заданного значения;

·     выдержка времени – возвращает 1 по истечении заданного интервала времени, который отсчитывается с момента его включения;

·     установка состояния – принудительно устанавливает состояние процесса в 0, -1 или 1;

·     счетчик – возвращает 1 при достижении заданного количества вызовов;

·     исключение процесса из списка – сбрасывает флаг присутствия указанного процесса, если он в этот момент не активен; исключенный процесс не может быть запущен в работу ни при каких условиях;

·     включение в список – устанавливает флаг присутствия заданного и ранее исключенного процесса;

·     счетчик0 – сброс значения УМП счетчик;

·     завершение работы.

В примере ФЛУ (см. табл. 1) для обозначения стандартных УМП выдержка времени и завершение работы использованы алиасы “Интервал“ и “КОНЕЦ“.

Ветвление организуется автоматически по логическим условиям. Циклы в ФЛУ организуются с использованием стандартных УМП управление по счетчику и установка состояния. Пример приведен в таблице 2.

Здесь организован цикл 10 запусков процесса П1. После завершения работы процесса П1 запускается процесс счетчик, который при каждом вызове добавляет к своей внутренней переменной 1, начиная с 0. Пока значение этой переменной не будет равно 10, процесс не будет завершен. Если процесс 2 (счетчик) идет, то после завершения П1 будут выполнены процессы 3 и 4 установки состояния, которые сбросят флаги завершения процессов П1 и счетчик, то есть объявят их невыполненными (первый параметр – номер, а второй – устанавливаемое состояние процесса). Особенностью УМП установки состояния является то, что после выполнения они объявляют невыполненными сами себя. Таким образом, процесс П1 будет запущен 10 раз, после чего процесс счетчик будет завершен (+2) и запустится процесс П2.

Работа программы моделирования процессов, управляемых событиями, происходит в следующей последовательности (см. схему):

·     в начальный момент системного времени происходит чтение и обработка ФЛУ, в результате которой: определяется число процессов m; создается и заполняется вектор состояния s; определяются имена процессов (по алиасам имен); формируются массивы параметров; вектор s инициализируется нулями; происходит проверка синтаксиса логических формул 4-й колонки ФЛУ, и если обнаружены ошибки, то выдаются соответствующие сообщения, процесс моделирования прерывается;

·     происходит синтаксический разбор логических формул (раскрытие скобок, эквивалентирование и др.) и заполняются соответствующие структуры данных для вычисления их значений (число переменных в логической формуле, номера входящих в нее элементов вектора s, коды логических отношений и др.);

·     далее работает основной цикл по числу строк ФЛУ m, причем в начале цикла вызывается интерпретатор логических формул EVENT, вычисляющий их значения и формирующий выходной вектор АЛА y в (1) с элементами yi=Qi&Li, где Qi, Li – булевы переменные, в том числе Li – значение логического условия в i-й строке ФЛУ, а Qi – результат логического сравнения si с нулем Qi=(si= =0);

·     выполнение ФЛУ начинается с запуска процесса с номером нуль, который ничего не выполняет и для которого всегда Q0=1 и L0=1;

·     при запуске i-го процесса происходит вызов соответствующей УМП (2) и одновременно i-й элемент вектора состояния si выставляется в –1 (признак того, что процесс идет);

·     i-й процесс будет продолжаться, пока выход УМП si не будет выставлен в 1 по логике разработчика модели, то есть процесс будет идти и значения транзитных переменных zi будут изменяться до тех пор, пока выражение yiÚ(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.