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

Это обстоятельство требует от нас более детального подхода к описанию нашего местоположения в науке, постановке задач, которые мы в состоянии решить, а также к формулированию вопросов, на которые мы сможем ответить.

Введение

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

Моделирование, в общем, является методом исследования систем путем их замены более удобными для экспериментов приближенными моделями, отражающими с достаточной степенью точности основные свойства оригинала. И, естественно, общие проблемы исследования систем накладывают свой отпечаток на создаваемые методы и технологии моделирования [12].

Наиболее важными вопросами здесь являются:

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

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

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

В настоящее время фундаментальные вопросы математического моделирования разрабатываются в двух равноправных и взаимодополняющих направлениях.

Данный анализ и рассуждения ведутся на основе материалов научных работ, опубликованных до 2001 года.

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

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

В подходе А.А.Самарского просматривается глубокий анализ опыта специалистов предметных областей, более полное использование методов математики как при построении математических моделей, так и при организации вычислительного эксперимента. Кроме того, подкупает основательный подход к прикладному программному обеспечению (ПО) процесса моделирования [22] именно на низком уровне, когда тестирование ПО ведется не только с точки зрения системного программиста ЭВМ, но и с позиций математики.

В связи с этим направление Г.С.Поспелова выглядит, на первый взгляд, более легковесным с точки зрения фундаментальной математики и может вызывать подчас необоснованные нападки со стороны приверженцев подхода А.А.Самарского. Такое недоверие, в первую очередь, может быть обусловлено тем, что разработка и реализация, "скрытых" от конечного пользователя, алгоритмов автоматизации процесса моделирования должна осуществляться в условиях открытого взаимодействия инженеров и ученых всех отраслей, а не в рамках отдельно взятого сообщества приверженцев той или иной научной стратегии.

Мы не будем защищать ни тех, ни других. Так или иначе стремления ученых в области автоматизации моделирования тяготеют к идеям второго направления (разумеется, не желая терять фундаментальные математические знания на этом пути) и это обстоятельство накладывает огромную ответственность на разработчиков систем автоматизации моделирования с точки зрения математического, технологического и программного обеспечения таких систем, которые обеспечат внедрение опыта обоих направлений в среду непрограммирующих математиков (исследователей) и позволят в конечном счете выйти на уровень ПО пятого поколения ЭВМ [59].

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

Рассмотрим несколько существующих систем цифрового машинного моделирования, являющихся наиболее яркими представителями двух направлений: А.А.Самарского и Г.С.Поспелова.

Система OLYMPUS, разработанная научной группой, входящей в состав Каллэмской лаборатории Комитета по атомной энергии Великобритании, и описанная в достаточной для нас степени в [22], представляет собой систему создания программных комплексов на языке FORTRAN для решения эволюционных задач. В ее основу положен глобальный модульный анализ организации вычислительных процессов при решении конкретных прикладных задач, проведенный на основе общей стратегии программирования класса нестационарных задач вычислительной физики. Это позволило разработчикам системы OLYMPUS зафиксировать общую структуру создаваемых программ в виде шаблона программы. Шаблон состоит из набора процедур-"пустышек", заполнение которых возложено на пользователя. Следующая схема позволяет представить набор подпрограмм и общую структуру готовой модели (рис. B.1).

Рис. B.1. Общая структура программ, создаваемых в системе OLYMPUS.

При создании программы в системе OLYMPUS изменяются лишь отдельные части, а структура программы, средства диагностики и т.д. используются как стандартные. Тем самым большая часть программы становится стандартной для многих пользователей системы OLYMPUS.

Кроме того, разработчиками системы OLYMPUS предприняты шаги по стандартизации имен идентификаторов в программах. Например, глобальные вещественные переменные принято обозначать идентификаторами, начинающимися с букв A-H, O, Q-Y, целые - L, M, N, логические - LL, ML, NL.

Такой подход к созданию программ позволил системе OLYMPUS получить широкое международное научное признание. На наш взгляд такое признание оправдано тем, что ученые были освобождены от множества действий, связанных с процессом программирования, им оставалось изучить язык FORTRAN лишь в части, достаточной для описания своих математических моделей (формул). Однако при этом для них вполне прозрачной оставалась структура программы и, следовательно, они могли делать выводы о правильности вычислений и взаимодействии отдельных компонентов готовой моделирующей программы.

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

Однако, несмотря на все недостатки, можно признать, что системы, подобные OLYMPUS, сделали значительный вклад в начало структурного анализа моделирующих программ, а также в обеспечение отчуждаемости готовых программных моделей, то есть возможности передачи моделей другим пользователям без необходимости утомительного сопровождения со стороны разработчиков.

Другой спектр программ, которые пока нельзя отнести к разряду средств моделирования (данное утверждение станет понятным при рассмотрении современных технологий обеспечения многомодельных вычислительных экспериментов), базируется на одной библиотеке функций, позволяющих интерпретировать модели, записанные на языке более близком математикам, делает шаг в сторону более естественного описания математических моделей. К числу таких программ относятся пакеты Maple V (именно его библиотека используется другими подобными системами), Mathematica, MATLAB.

Так, например, для задачи Коши

\begin{aligned} {y_1}' & = y_2y_3; \\ {y_2}' & = - y_1 y_3; \\ {y_3}' & = -0.51 y_1 y_2; \\ \: \\ y_1(0) & = 0; \\ y_2(0) & = 1; \\ y_3(0) & = 1; \\ \end{aligned}

(B.1)

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

 function dy = rigid(t, y);
 dy = zeros(3,1);
 dy(1) =  y(2) * y(3);
 dy(2) = -y(1) * y(3);
 dy(3) = -0.51 * y(1) * y(2);

(B.2)

и способа ее численного решения на интервале [0, 12]:

 options = odeset('RelTol', 1e-4, 'AbsTol', [1e-4 1e-4 1e-5]);
 [T,Y] = ode45(@rigid, [0 12], [0 1 1], options);

(B.3)

Из описаний (В.2), (В.3) видно, что пользователю так или иначе придется изучать язык, мало отличающийся от таких языков, как FORTRAN или ALGOL, единственно полезным свойством пакета MATLAB является наличие набора стандартных методов вычислительной математики и методов анализа и коррекции погрешностей вычислений. Однако, здесь пользователю приходится полагаться только на авторитет фирмы, создавшей MATLAB. Значительным недостатком систем подобных MATLAB является невозможность эксплуатации моделей вне самой системы (на которой модель создана), разве что, только в виде текста на языке C, который можно "попросить" у пакета MATLAB.

Конечно, можно долго спорить о лексике языков и полноте математического обеспечения систем, подобных только что рассмотренным. Однако эти вопросы по большей части зависят от вкусов, привычек и компьютерной грамотности пользователей. Мы сосредоточим внимание на вопросах связанных с обеспечением современных требований технологии моделирования, которая сейчас немыслима без возможности проведения многомодельных вычислительных экспериментов (и желательно в неоднородных по аппаратному обеспечению вычислительных сетях). Разумеется, все дальнейшие рассуждения будут связаны с организацией многопроцессных вычислений и внутренней архитектурой моделирующих программ. Поскольку системы, рассмотренные нами ранее (в виду, либо их закрытости, либо несовершенства), не дают представления о структуре моделирующих программ, получаемых с их помощью, мы вынуждены рассмотреть новейшие материалы, которые пока слабо подкреплены практическими достижениями. Например, еще не существует готовых к широкому использованию систем моделирования, применяющих архитектуру программных моделей описанную в [1].

Традиционно, разработчики и пользователи моделирующих программ стремились к повышению вычислительной производительности. В недавние годы для этих целей широко использовалась технология так называемого Парраллельно дискретного событийного моделирования - PDES (Parallel Discrete Event Simulation). Однако сейчас данная техника считается не убедительной [6]: как вывел David Nicol [5], производительность ограничена аппаратными возможностями и, в связи с этим, не является объективной функцией. Кроме того, Richard Fujimoto [3] акцентировал внимание на том, что техника PDES тяжела, так как требует значительного времени на планирование процессов и выполнение программ. К его заключению мы добавим тот факт, что и программирование моделирующих алгоритмов с помощью средств, придерживающихся методологии PDES, представляет собой непростую задачу для непрограммирующего математика особенно в части, касающейся организации многомодельных вычислительных экспериментов.

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

Шаги, которые делались и делаются на пути к таким достижениям требуют отдельного рассмотрения, так как являются тем базовым материалом, на основе которого формируются современные взгляды и именно эти "кирпичики" ложатся в основу новейших систем моделирования.

Современные системы моделирования по принципам организации вычислительных процессов можно условно разделить на три класса [1]. Эти классы, соответственно, используют следующие принципы организации работы и взаимодействия моделирующих программ [1]:

событийное планирование (event scheduling);
развертка активных процессов (activity scanning);
взаимодействие процессов (process interaction).

В стремлении более полно использовать достижения программных технологий был выдвинут термин "Logical Process Paradigm" (LPP) [2], основу которого составил механизм сообщений для обмена векторами состояний моделей и упрощение динамических процессов путем их декомпозиции на множество так называемых логических процессов, фактически являющиеся простыми подпрограммами с определенными в них статическими массивами для хранения векторов состояния, что позволило освободить пользователя от ручного программирования межпроцессного обмена и возложить эту задачу на систему моделирования.

Хотя логические процессы в понимании LPP еще не обладали способностью "наблюдать общее модельное время" они имели рациональное звено и стали примитивными прообразами моделей-компонентов Component-ORiented Simulation Architecure (CORSA).

На момент выхода публикации [1] в среде программистов уже давно использовались такие технологии и механизмы как: CORBA (Common Object Request Broker Architecture), COM (Component Object Model)[53] и, разумеется, таблицы виртуальных функций классов языка C++, позволявших упростить программирование интерфейсов между компонентами обычных программ для ЭВМ. Более того, операционные системы UNIX предоставляли механизмы межпроцессного взаимодействия, которые полностью покрывали потребности ученых, работающих над созданием различных систем моделирования.

В связи с этим нельзя было не обратить внимание на то, что ученые шли по пути подстраивания структур моделирующих программ под существующие методы программирования, неизменно оставаясь несколько позади, вместо того, чтобы разрабатывать структуры моделирующих алгоритмов, исходя из задач математического моделирования, а затем внедрять эти достижения в рамках различных программных технологий (непосредственно влияя на их развитие), примерно так, как это было в 1950 – 1970-е годы [14,21,26].

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

Если компонент намерен передать какие-либо данные, то для этого он просто помещает их в порт именуемый outport. Прием данных осуществляется простой выемкой данных из входного порта (inport). Компонент может иметь в своем составе несколько входных (inports) и несколько выходных (outports) портов.

В рамках общего вычислительного эксперимента компонентами управляет некая программная оболочка. Работа этой оболочки (по отношению к модели-компоненту) делится на две фазы:

параметризация (parametrization phase) и
конфигурирование (configuration phase).

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

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

Идея конфигурирования компонентов не нова. Еще в 1991 году Szymanski использовал фазу конфигурирования в языке EPL (Equational Programming Language) [8].

Идеология CORSA поддерживает три класса (типа) компонентов:

time-unaware	–	"часов не наблюдающие";
time-dependent	–	зависящие от показаний таймера общего модельного времени;
time-independent	–	ведущие отсчет собственного модельного времени (имеющие собственные "часы").

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

Второй тип (time-dependent) компонентов не может влиять на текущее модельное время и все исходящие от него сообщения (помимо его воли) маркируются текущим значением счетчика общего модельного времени.

Третий тип (time-independent) компонентов обладает собственным счетчиком модельного времени и представляет собой более самостоятельный объект, существующий в общей моделирующей среде. Компоненты данного типа могут получать сообщения, гарантированно свободные от возможных ошибок соблюдения масштаба модельного времени. Так, например, для обеспечения синхронизации состояний объектов, компоненты третьего типа лишены возможности принимать сообщения с просроченным сроком действия (т.е. компонент может принимать только те сообщения, которые содержат показания времени большие или равные текущему значению внутреннего счетчика модельного времени).

Далее рассуждения [1] уходят в сторону проблем компоновки моделей-компонентов друг с другом при объединении их в общую моделирующую сеть. Мы понимаем, что даже наличие трех различных классов объектов может превратить процесс компоновки в довольно замысловатый и длительный процесс, нам это не интересно. Поговорим о другом.

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

Далее мы будем говорить о программной модели (ПМ) не просто как об участнике коллективного процесса, а как о самостоятельно существующем объекте, для которого взаимодействие со средой и другими моделями – лишь часть его функционального наполнения. Дадим общую структуру программной модели такую, которая в отличие от CORSA может быть представлена одним типом (классом) объектов и, следовательно, позволит упростить компоновку моделей между собой; и, что самое главное, введенная нами структура позволит обеспечить единое представление моделирующих программ, полученных по различным исходным видам математических моделей. Кроме того, покажем как подобного рода структуризация позволяет создавать средства автоматизации процесса получения программных моделей на осное различных видов исходных текстов или графических представлений. Словом, речь пойдет об устранении того хаоса, который сейчас творится среди программистов, занимающихся созданием программных моделей.

Структура проблемы

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

Моделирование как инструмент системного анализа

Моделирование как новая методология проведения научных исследований применяется сейчас во многих областях науки и техники. Моделирование используется при проектировании, создании, внедрении и эксплуатации объектов и систем различного назначения, а также при изучении отдельных элементов или в комплексе, сложных природных и общественных систем, процессов и явлений.

Основными этапами процесса моделирования являются: создание модели, проведение экспериментов с моделью, обработка и анализ результатов моделирования.

Классификация моделей

Прежде чем начать более детальное рассмотрение этих этапов, следует провести некоторую классификацию моделей.

По целям разработки

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

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

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

Модели, разрабатываемые для анализа, изучения и выявления некоторых новых свойств и характеристик существующих объектов, систем и процессов.
Модели, разрабатываемые для синтеза новых объектов, систем и процессов.

В качестве основной цели создания модели можно указать обеспечение возможности проведения более широкого спектра исследований, которые невозможны для реального объекта, системы или процесса. Например, для прогнозирования поведения моделируемого объекта в несвойственных ему или недопустимых для него режимах работы. Одним словом, для реализации экспериментов, которые невозможны с реальным объектом.

Здесь, естественно, приходится решать задачу обеспечения адекватности МОДЕЛЬ – ОБЪЕКТ, что влечет за собой необходимость проведения дополнительных исследований.

Приведенная выше классификация моделей в равной степени относится как к физическому, так и к математическому моделированию [12, 22, 48].

Физические и математические модели

Физическое моделирование состоит в изучении объекта или системы посредством исследования некоторого материального макета, сохраняющего в определенном масштабе физическую природу изучаемого объекта (системы). Физические модели позволяют исследовать те свойства объектов моделирования, которые по той или иной причине невозможно исследовать на математических моделях. Такая ситуация возникает, когда математическая модель или вообще отсутствует и (с позиций современного уровня знаний) не можнт быть построена, или оказывается слишком сложной для ее исследования в требуемом объеме и с необходимой полнотой. В целом ряде случаев физическое моделирование применяется [48] для построения математической модели и уточнения ее структуры и параметров.

В данной работе рассматривается математическое моделирование, которое в сравнении с физическим представляется наиболее универсальным методом исследования систем. Универсальность метода математического моделирования определяется постоянным совершенствованием как аналитических, так и численных методов математики. Важную роль здесь играет возможность формализации наших представлений об объектах различной физической природы посредством одних и тех же предложений языка математики. Традиционным примером этому может служить описание динамики электрического колебательного контура и физического маятника дифференциальными уравнениями, имеющими одинаковую структуру. Следует также отметить привлекательность эксплуатационных свойств, которая усиливается возможностью реализации математических моделей на ЭВМ.

Аналоговые и цифровые модели

В соответствии с типами вычислительных машин, на которых реализуются математические модели, различают аналоговое и цифровое моделирование.

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

При моделировании на цифровых машинах, мы имеем дело с программами, в конечном счете представляющими собой исполняемые модули, содержащие инструкции (команды) процессора ЭВМ.

В дальнейшем, понятие "программа" мы не будем разделять на аналоговое и цифровое представления, и будем считать его равнозначным для любых видов ЭВМ. Просто в аналоговом представлении программой, в нашем понимании, является электрическая схема, а в цифровом, набор инструкций для процессора. Условимся только, что далее в тексте под словом программа мы будем подразумевать программу для ЦВМ, если специально не оговорено обратное. Более того, оговоримся, что в дальнейшем аналоговые модели нас будут интересовать с точки зрения возможности представления их на цифровых машинах, разумеется, если мы сможем обеспечить адекватность представления той модели, которая набрана на аналоговой машине.

Возрастающая сложность решаемых задач и интенсивность исследований в области естественных наук предъявляют высокие требования к создаваемым моделям, а также к средствам их реализации на ЭВМ. Важной тенденцией настоящего времени является формирование отдельной отрасли науки, нацеленной на создание средств автоматизации математического моделирования, позволяющих свести в единый технологический процесс решение основных фундаментальных задач моделирования в рамках той или иной предметной области. Большое внимание при создании таких средств уделяется сохранению естественного (для данной предметной области) языка описания математических моделей.

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

Математические, алгоритмические и программные модели

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

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

В этом отношении мы будем делить математические модели на непрерывные (в том числе кусочно непрерывные) и дискретные.

Примером ММ может служить запись системы обыкновенных дифференциальных уравнений (ОДУ) на бумаге, которая показывает нам структуру зависимостей переменных состояния модели. Также к ММ можно отнести формулу или набор формул, позволяющих получить точное значение переменных состояния модели в любой точке интервала определения независимой переменной (напрмер, времени).

Алгоритмической моделью (АМ), мы будем называть запись на любом языке, в том числе графическом, алгоритма вычисления траектории переменных состояния модели. Разумеется данный алгоритм включает в себя организацию модельного "времени", а также алгоритм перехода из одного состояния в другое. Организация модельного "времени" подразумевает задание конкретных граничных условий и для цифровых ПМ может представлять собой в самом простом случае некоторый программный цикл приращения "времени" на заданную постоянную величину.

Здесь слово "время" мы заключили в кавычки, т.к. под модельным временем мы понимаем изменение какой-либо независимой переменной, в интервале определения которой и рассматривается текущее состояние модели.

Алгоритм перехода из одного состояния в другое, по сути, является основным способом "жизни" модели. Например, для систем ОДУ таковым может являться процедура вычислений по методу Рунге-Кутты, позволяющая по вектору состояния, известному на предыдущем шаге, получить новое состояние модели.

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

Более подробно АМ мы рассмотрим при обсуждении вопросов алгоритмизации ММ и связанных с этим процессом преобразований моделей из одного вида в другой.

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

Программной моделью (ПМ) мы будем называть объектный исполняемый модуль, пригодный для работы под управлением либо операционной системы ЭВМ, либо другой программной среды, созданной специально для данных (или аналогичных) моделей; среда, по крайней мере, должна обеспечивать возможность запуска модели на выполнение и возврат пользователю ее следа.

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

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

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

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

В современной литературе, например в [12], часто путаются понятия АМ и ПМ. Мы не можем позволить себе такого разночтения, поскольку (для цифровых машин) процесс алгоритмизации ММ представляется нам отдельным этапом построения ПМ, на котором выполняются технологические действия, связанные с преобразованиями (может быть неадекватными) моделей, которые могут быть формализованы и, следовательно, поручены компиляторам языков моделирования.

Виды и формы представления математической модели

Математические модели принято [22] разбивать на два типа: фундаментальные и прикладные. Для пояснения существа такого деления моделей можно воспользоваться приведенной выше классификацией самих изучаемых объектов, систем и процессов. Очевидно, для первого их класса фундаментальные модели в некотором смысле можно считать уже существующими (как закон Ома для электрической цепи), а изучение свойств и характеристик таких объектов может осуществляться на конкретных прикладных моделях, являющихся, как правило, следствием их фундаментальных моделей и получаемых из них введением необходимых для данного исследования граничных условий, параметров элементов и входных воздействий. В то же время для изучения объектов третьего и, особенно, четвертого класса первоочередной задачей является построение для них именно фундаментальных моделей, а затем уже на их основе – построение соответствующих прикладных моделей. Последние при этом оказываются необходимыми как для изучения конкретных свойств и характеристик исследуемых объектов, так и для уточнения содержания и структуры фундаментальной модели. Это вытекает и из тезиса [22] (и подтверждает его) о том, что фундаментальные модели не могут быть выведены из эксперимента, но могут быть подсказаны (или уточнены) им. Следствия же из фундаментальных моделей, которые принято называть прикладными, должны сопоставляться с экспериментом или должны соответствовать экспериментальным данным об исследуемом объекте.

Не останавливаясь далее на многих других возможных принципах и признаках классификации моделей, которые можно найти, например, в [22,43,42,46,17,12,51,60,50] и других работах, отметим еще только некоторые из них, существенные, как нам кажется, с позиций предполагаемых дальнейших исследований в области создания программных моделей. Здесь целесообразно выделить математические модели по форме их математического представления. При этом они также разделяются [60] на параметрические и непараметрические. Согласно этой классификации к параметрическим математическим моделям относятся модели в форме отдельных уравнений или систем:

обыкновенных дифференциальных уравнений (ОДУ);
дифференциальных уравнений в частных производных;
интегральных уравнений и т.п.

К непараметрическим математическим моделям можно отнести:

передаточные функции;
весовые функции;
ряды Вольтерра или многочлены Колмогорова-Габора;
регрессионные модели;
ковариационные функции;
спектральные плотности и т.п.

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

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

алгоритмические сетевые модели [29];
сети Петри;
конечные автоматы;
цепи Маркова и др.

Кроме того, имея ввиду возможность построения компиляторов языков моделирования (для цифровых ЭВМ) способных воспринимать и адекватно преобразовывать непрерывные модели в дискретные, следует рассматривать также:

структурные схемы систем управления;
схемы для аналоговых вычислительных машин.

В таких моделях в графическом виде может быть отражено, с одной стороны, математическое описание и структура изучаемого объекта, а с другой стороны, непосредственно (один из возможных) алгоритм получения решения.

Не делая пока никаких предположений по поводу возможностей построения компиляторов, способных оперировать если не со всеми, то хотя-бы с большинством рассмотренных здесь видов ММ заметим следующее.

Некоторые вопросы квалиметрии моделей

Выбор того или иного вида модели во многом определяется наличием математического аппарата (методов), который, в конечном счете, может обеспечить возможность реализации и экспериментов с моделью.

Важным, здесь, является не только наличие методов получения решения, но и методов, позволяющих составить необходимый перечень квалиметрических характеристик модели [22,25,10,17,51], таких, например, как:

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

Это может быть продиктовано необходимостью обоснования возможности тех или иных изменений модели в процессе отладки, обеспечения некоторых эксплуатационных свойств и т.п.

В общем рассмотрение этих вопросов следует отнести на счет ПМ в том аспекте, что для среды моделирования (среды эксплуатации ПМ) программные модели представляются самостоятельными объектами и указанные выше характеристики могут проецироваться именно на взаимодействующую пару ПМ – СРЕДА примерно таким же образом, как это делается в теории автоматического управления при взаимодействии пары ОБЪЕКТ - Система управления (вопросы наблюдаемости, управляемости и идентифицируемости[56]).

Преобразования моделей

Поскольку мы обсуждаем вопросы, связанные с построением компиляторов языков высокого уровня или даже компиляторов языков моделирования, нам необходимо рассмотреть некоторые из возможных, целесообразных и допустимых направлений преобразования моделей из одного вида в другой. В самом простом случае нам могут понадобиться такие преобразования при переходе от математических к алгоритмическим моделям.

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

Разработкой такой формы (структуры) ПМ мы займемся позднее.

На рис.1.1 показана диаграмма преобразований моделей в программную форму, которая для нас будет базовой. Одновременно, на данной диаграмме мы попытались отразить некоторые особенности преобразований. Так:

Сплошными линиями показаны направления эквивалентных преобразований.
Штриховыми линиями показаны направления преобразований, которые можно, очевидно, назвать условно эквивалентными.
Штрих-пунктирными линиями на диаграмме показаны неэквивалентные преобразования.

Поясним введенные понятия.

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

Неэквивалентные преобразования приводят к нарушению структуры исходной модели и влекут за собой изменения степени адекватности.

Неэквивалентные преобразования приводят к нарушению адекватности МОДЕЛЬ – МОДЕЛЬ, и должны быть обеспечены алгоритмами ее оценки, либо позволять, при определенных условиях, свести к допустимому минимуму несоответствия в поведении полученной модели и исходной.

Рис. 1.1. Диаграмма преобразований моделей.

Необходимость проведения неэквивалентных преобразований может быть продиктована отсутствием на данный момент методов математики, позволяющих формализовать наши действия по переводу модели к алгоритмическому виду другими способами. В иных случаях мы можем сознательно идти на такие преобразования с целью обеспечения универсальности алгоритма преобразования моделей к программному виду. Тогда в обязательном порядке мы должны обеспечить систему (компилятор) алгоритмами оценки адекватности таких преобразований (в смысле МОДЕЛЬ – МОДЕЛЬ) [39]. Примером такого выбора может служить применение методов Рунге-Кутты дискретизации ОДУ с целью дальнейшей компиляции исходной модели на цифровую вычислительную машину.

Заметим, что схемы для аналоговых вычислительных машин пока нас интересуют с точки зрения моделирования на основе систем ОДУ связи на диграмме (рис.1.1), касающиеся аналоговых программных моделей можно нарастить, например, по материалам [41].

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

Приведенная на рис.1.1 диаграмма ни в коей мере не может претендовать на полноту отражения ни всей совокупности форм и видов моделей, ни возможных, целесообразных и допустимых направлений их трансформации. В дальнейшем мы будем обращаться к данной диаграмме по мере обсуждения конкретных алгоритмов преобразования моделей, вопросов связанных с построением алгоритмов оценки адекватности МОДЕЛЬ – МОДЕЛЬ и, разумеется, вопросов связанных с алгоритмизацией математических моделей.

Модельное время и алгоритмизация

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

Переход от математической к программной модели в любом случае требует некоторых шагов по алгоритмизации, даже если мы имеем точную, аналитически заданную формулу получения следа модели, нам все равно придется программировать вывод решения в определенных нами точках (для ЦВМ), либо устанавливать перемычки для подключения устройств отображения информации (для АВМ). При этом время "жизни" программной модели с точки зрения внешнего мира в случае использования ЦВМ будет дискретным, а в случае использования АВМ – непрерывным.

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

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

Например, если к вектору решения z(t) некоторой системы ОДУ добавить компонент u, удовлетворяющий условиям

\dot{u}(t)=1, \: \: \: u(t_0)=t_0.

Очевидно, что u(t)=t. Следовательно, из характера простого дискретного модельного времени (t_{n+1}=t_n+h), вытекает равенство

t_n+h=u_n+h.

Для дифференциальных уравнений в частных производных (именно согласно теории разностных схем [55]) мы лишь предположим, что в будущем мы сможем иметь семантические процедуры анализа и синтеза программ, которые позволят автоматически строить необходимый набор одномерных моделей (в понимании [55]) и сценарии их взаимодействия для получения суммарной апроксимации исходной задачи. В данной работе мы не будем рассматривать эти вопросы.

В дальнейших рассуждениях мы будем опираться на схему, приведенную на рис.1.2.

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

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

Рис. 1.2. Схема создания программной модели.

Данная работа посвящена динамическим системам, но коль скоро мы говорим о построении компиляторов языков моделирования, мы должны предусмотреть возможность сохранения той мощи обычных языков программирования, которая понадобится нам при построении программных моделей других систем. В этой связи приведем еще один пример дискретной математической модели – конечный автомат, который может быть задан с помощью функции перехода, определяющей алгоритм пересчета состояний в зависимости от входного воздействия. Здесь мы не можем говорить о какой-либо "самостоятельной жизни" данного объекта, и, следовательно, о языке моделирования, здесь достаточны средства обыкновенных языков (C, Pascal, FORTRAN и т.д.) [12].

Примером непрерывной математической модели может служить система ОДУ. Для простоты дальнейших рассуждений рассмотрим алгоритмизацию такой модели на основе задачи Коши.

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

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

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

Далее к программной модели будет подключена стандартная (библиотечная) процедура вычислений по методу Рунге-Кутты заданного порядка для системы из n уравнений, которая будет вызываться на каждом шаге модельного времени и обращаться к построенным ранее процедурам расчета правых частей системы ОДУ. При наличии такой стандартной процедуры сами методы могут быть заданы в виде массивов, содержащих коэффициенты таблицы Батчера и так же храниться в библиотеках ресурсов системы построения программных моделей.

Задание переменных коэффициентов модели в виде функции, вызываемой на каждом шаге модельного времени, тривиально для любого компилятора.

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

Рассмотренный нами пример, по существу, содержит неэквивалентное преобразование исходной ММ и, следовательно, здесь необходимо рассматривать проблему адекватности МОДЕЛЬ – МОДЕЛЬ [39], что в свою очередь влечет за собой предъявление новых требований к системе построения программных моделей. Эти требования заключаются в обеспечении возможности получения квалиметрических характеристик модели, о которых мы говорили ранее.

Мы не будем более подробно рассматривать схему приведенную на рис.1.2, которая, разумеется, не может претендовать на полноту, но, как нам кажется, отражает основные направления и указывает наиболее выжные места, нуждающиеся в математической, технологической и программной поддержке процесса создания программных моделей.

Пример построения ПМ по исходной системе ОДУ наталкивает нас на следующие рассуждения, связанные с принципами "существования" цифровых программных моделей. Эти рассуждения можно рассматривать как начало формирования требований к структуре программной модели, позволяющей представлять ПМ как самостоятельный объект.

Дискретное время подразумевает некоторые принципы реализации модели и необходимость четкой привязки отдельных функциональных частей программной модели к соответствующим моментам или периодам времени "жизни". Организация функциональной структуры ПМ на основе или с учетом расписания модельного времени является основополагающим моментом, позволяющим выделить этапы создания и эксплуатации ПМ, которые могут быть автоматизированы средствами вычислительной техники.

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

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

По структуре, приведенной на рис.1.3, функциональные блоки программной модели, построенной на основе системы ОДУ, можно распределить следующим образом. Вычисления или задание начальных значений переменных состояния модели следует отнести к процедурам инициализации. Функцию расчетов по выбранному методу дискретизации (Рунге-Кутты, например) отнести к вычислительным процедурам, выполняемым на каждом шаге модельного времени. Функции расчета значений правых частей уравнений исходной системы, вызываемые методом дискретизации, отнести к присоединенным процедурам (метод вызывает их на каждом этапе выполнения своего алгоритма). Такие вещи, как задание модельного времени (начало, шаг и конец), структуру следа (т.е. перечень переменных, предназначенных к выводу) и метод (заданный в виде таблицы Батчера) можно определить в тексте программы в виде синтаксических структур, воспринимаемых компилятором.

Рис. 1.3. Структура распределения основных функциональных процедур алгоритмической модели.

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

Кстати, в данную схему можно уложить не только динамические модели. Например, решение систем алгебраических уравнений так же можно представить схемой показанной на рис.1.3. Исключением является то, что основной цикл приращения модельного времени будет заключаться в выполнении одного шага, не имеющего размерности. Основным способом (столь краткой) жизни модели может стать, например, процедура вычислений по методу Ньютона-Рафсона [57].

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

Обсуждение существующих языков программирования и языков моделирования

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

Как уже отмечалось ранее, в мире накоплен богатый опыт создания различных программных средств, ориентированных, в том числе, и на решение некоторых задач моделирования. Однако, с точки зрения системного моделирования эти средства настолько специализированы и "закрыты", что пользователю приходится иметь в своем распоряжении целый набор программ (поддерживающих лишь отдельные этапы процесса моделирования), которые практически невозможно объединить в более или менее лаконичную среду построения и эксплуатации программных моделей. Условно такие средства можно разбить по следующим категориям.

Программы символьных преобразований и вычислений, ориентированные на то или иное текстовое представление математических выражений в естественной форме (REDUCE, Maple 5, и т.д.).
Программы, предназначенные для вычисления различных алгебраических выражений, решения некоторых видов уравнений и т.п. с помощью методов вычислительной математики, и, в качестве входной, воспринимающие информацию, если не в естественной текстовой форме, то, во всяком случае, в форме максимально приближенной к естественной (Mathlab, например).
Программы, созданные специально для конкретной текстовой или графической формы представления математических моделей (например, КОГНИТРОН [29], Simulink) и ориентированные на некоторые фундаментальные задачи моделирования.
Языки программирования для вычислительных машин (C, Pascal, FORTRAN, PL-1 и т.д.).

Средства первой и второй категории позволяют оперировать более или менее привычными для математиков формами представления информации о моделируемом объекте, но обладают весьма скудными средствами решения основных задач моделирования, не говоря уже о средствах квалиметрии моделей. Кроме того, зачастую требуют от пользователя некоторых специальных знаний, не относящихся к предметной области, в которой он проводит свои исследования. Примером может служить то обстоятельство, что, например, Mathlab, кроме математических знаний требует от пользователя изучить язык, на котором он принимает входную информацию.

Обычные языки программирования (четвертая категория) позволяют строить любые системы, но требуют от разработчика, в первую очередь, обширных знаний в области программирования, в том числе и системного (принципы построения и организация операционных систем ЭВМ). Разумеется здесь не может идти речь о математической и технологической поддержке процесса моделирования.

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

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

Отдельно следует поговорить о средствах, обеспечивающих возможность графического представления моделей (как исходных, для последующей компиляции на машину, "текстов" программ). В качестве примера таких средств мы выберем систему КОГНИТРОН [29], так как она позволяет наиболее полно проиллюстрировать наши дальнейшие рассуждения не только с точки зрения пользователя, но и с точки зрения разработчика подобных систем. Так же к данным системам можно отнести и аналоговые ВМ, но они нас будут интересовать по поводу возможности компиляции их схем на цифровую машину.

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

По отношению к параметрическим моделям, все многообразие языков можно разделить на две категории:

Языки, требующие от пользователя строго разделять все уравнения системы (например, ОДУ, РУ и т.д) и задавать их в виде отдельных процедур или операторов.
Языки не требующие (а порой и не предполагающие) строгого отделения друг от друга уравнений системы. Данные языки позволяют графически представлять системы уравнений таким образом, что все уравнения сведены в некую сеть (или граф) операторов, определяющих взаимосвязь переменных состояния модели. К таким формам представления моделей относятся, например, структурные схемы систем управления, схемы для аналоговых ВМ, алгоритмические сетевые модели [29] и т.п.

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

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

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

Более подробно мы рассмотрим данные вопросы при обсуждении алгоритма идентифицирующего планирования вычислений [37,38].

Следует отметить, что для второй категории языков весьма опасным, с нашей точки зрения, является высказывание о том, что некоторые формы представления математических моделей являются фактически описанием алгоритма вычислений, связанного с данной формой. Такое утверждение ограничивает пользователя системы в выборе методов как представления математических моделей, так и вычислений по ним.

Допустим надо решить уравнение

x'' = {k}^2(\alpha {x}' - x);

(1.1)

и мы располагаем системой построения цифровых программных моделей, которая в качестве входной информации воспринимает схемы для аналоговых ВМ. Тогда, считая, что производную x'' мы уже имеем, соединим последовательно два интегратора для получения производной нулевого порядка:

(1.2)

Умножим каждую из полученных производных на соответствующий коэффициент уравнения (1.1).

(1.3)

Затем сложим полученные результаты:

(1.4)

В соответствии с (1.1), выход оператора '–' равен входу первого интегратора.

Заменим теперь интеграторы соответствующими операторами языка алгоритмических сетей [29]:

(1.5)

В результате имеем следующую из возможных схем расчета.

\begin{aligned} x_1[n+1] & = x_1[n] + x_2[n]; \\ x_2[n+1] & = x_2[n] + {k}^2\alpha x_2[n]-{k}^2x_1[n]; \end{aligned}

(1.6)

Данная схема представляет собой метод Эйлера дискретизации ОДУ. Однако, наверное не стоит ограничивать пользователя этим методом. Кроме того, если пользователь набрал схему подобную (1.5) на языке алгоритмических сетей, он может и не задумываться о существовании непрерывного аналога такой схемы. Между тем, возможность воссоздания так называемой виртуальной непрерывной модели может быть интересна, например, для возможности исследования модели способами, относящимися к совершенно другой области математики, в отличие от той, в которой работает автор дискретной модели. Более того мы знаем, как не только применить методы более высокого порядка точности к схеме (1.5), но и как вычислить (не оценить, а именно вычислить) адекватность полученной разностной схемы той исходной (пусть даже и не известной доселе) непрерывной ММ при такого рода преобразованиях.

Процесс создания программной модели

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

Как видно из схемы, приведенной на рис.1.4, применение обычных языков программирования возможно лишь на отдельных этапах работ. Причем их использование вызывает целый ряд проблем, связанных в первую очередь с недостаточной гибкостью, не говоря уже о значительных трудозатратах (с привлечением специалистов в области программирования) при построении программ. Действительно, в процессе создания программной модели часто приходится уточнять, варьировать как исходную ММ, так и технологические пути построения самой программной модели. Ясно, что обычные языки в этом случае не позволяют достичь необходимой гибкости системы построения программных моделей.

Выход здесь может состоять в применении языков моделирования, использование которых может дать значительное упрощение прямого движения к созданию программной модели. Такие языки, как правило, ориентированы на конкретные виды математических моделей, что позволяет создателям таких языков получить оптимальный алгоритм компиляции. Однако, разработчики таких систем зачастую стремятся к полной параметризации системы для того, чтобы процесс задания исходной ММ (для конечного, непрограммирующего пользователя) сводился лишь к заданию ее параметров. Формально математические модели в таких "языках" не используются [12].

Это обстоятельство приводит к тому, что мы опять не в состоянии достичь требуемой универсальности системы поддержки математического моделирования.

Рис. 1.4. Процесс создания программной модели.

Поясним. Отсутствие записи именно математической модели может служить [12] препятствием для применения некоторых математических методов квалиметрии, преобразования моделей и т.д., не говоря уже о том, что на этапе построения программной модели часто требуется вносить изменения в саму ММ, получаемую, как правило, в виде математической записи (вывод уравнений и т.д.), и так как для ее передачи на компиляцию пользователю опять приходится переводить ее на язык выбранной системы моделирования, мы можем говорить о еще одном недостатке таких систем. Кроме того, данный недостаток связан с проблемой выявления элементарных ошибок пользователя, т.е. чем большую технологическую работу выполняет компилятор, тем меньше вероятность появления ошибок в готовой программе. Вопросы, связанные с безошибочностью и надежностью программ требуют отдельного рассмотрения. Здесь мы ограничимся простым примером. Допустим, каждый раз при переводе ОДУ на язык системы моделирования, Вам надо приводить ее к нормальной форме Коши (что в принципе не всегда возможно [31]) вручную, скольких ошибок можно было бы избжать, если бы эту работу могла выполнять сама система моделирования, да еще с выводом исчерпывающей диагностической информации о процессе преобразования.

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

Примером для подражания в этом смысле являются интерпретируемые языки, например, Bash, Perl, Java (™ Sun Microsystems), которые хотя и не являются языками, пригодными для целей моделирования, но для эксплуатации программ требуют только одну программу – интерпретатор или виртуальную машину, который легко выбирается автоматически (при запуске на выполнение) либо средствами ядра операционной системы, либо посредством переменных окружения. Разумеется, мы подразумеваем, что используемые интерпретаторы и виртуальные машины уже портированы на большинство фппаратных платформ.

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

Кроме того, необходимо иметь одну программу, объединяющую в себе необходимые средства блоков (2), (3), (4), и способную строить универсальные по структуре программные модели, которые могут содержать в себе если не все, то многие способы "жизни", присущие различным алгоритмическим моделям.

Ввиду того, что программным моделям могут быть предъявлены различные требования по скорости выполнения и объемам занимаемой памяти ЭВМ, средства блоков (2), (3), (4) разумно распределить на две системы:

Непосредственно компилятор (объединение блоков {1}), готовящий отчуждаемые ПМ.
Отладочная система (объединение блоков {2}), способная "прогонять" модели в режиме интерпретатора и содержащая как можно более полный набор средств блока (4). Кроме того, в нее должны входить методы преобразования и отображения исходных ММ в том или ином удобном для пользователя виде.

Разумеется, необходимо вспомнить о том, что блоки (2) и (3) должны иметь в своем составе достаточное количество средств, которые мы пока условно разобъем на следующие категории.

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

Блоки (5), (6), (7), очевидно, следует отнести на счет операционной среды, осуществляющей различные манипуляции с готовыми программными моделями.

Здесь вступают в силу алгоритмы и программное обеспечение этапа планирования вычислительных экспериментов, а также этапа анализа и интерпретации результатов.

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

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

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

Далее в работе мы, естественно, будем доказывать возможность такой организации ПМ. Пока лишь скажем, что это возможно и вернемся к блокам (5), (6), (7), показанным на рис.1.4.

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

Но коль скоро мы заговорили о языке описания сценариев и о том, что мы целиком и полностью владеем программными моделями, можно поручить среде более сложные задачи (не говоря уже о том, что сам язык описания сценариев должен обладать достаточными возможностями и быть сравним, например, с языком C):

Выявление зависимостей некоторых наблюдаемых величин от параметров модели (например, на основе формализованных алгоритмов аппарата математической статистики).
Исследования поведения модели в спектре внешних воздействий путем многократного запуска и последующего сравнения следов ПМ (например, построение амплитудно-частотных характеристик (АЧХ) исследуемого объекта).
Построение более сложных моделей из отдельных блоков в рамках одного вычислительного эксперимента.
И так далее...

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

Конечно, современные операционные системы еще не готовы к такой (теперь уже действительно объектной в отличие от C++) интерпретации программ. Но мы всегда можем говорить о создании, как виртуальных машин (типа Java), так и виртуальных операционных сред моделирования.

Теперь нам стоит замкнуть полный технологический цикл системного моделирования, при рассмотрении которого мы постараемся более детально обсудить содержание и цели различных этапов моделирования на основе программных моделей.

Обеспечение задач системного моделирования

Фундаментальные задачи [12], требующие рассмотрения процесса моделирования как единого технологического процесса построения, отладки, исследования и эксплуатации моделей, приводят нас к схеме, показанной на рис. 1.5, где основным становится понятие математической модели. Это продиктовано прежде всего тем, что язык математики на данный момент является наиболее универсальным средством, позволяющим не только исследовать окружающий нас мир, но и с успехом может описать способы и методы формализации наших действий по его изучению.

Подход к моделированию на основе теории математических моделей ставит перед разработчиками проблемы, о которых мы упоминали ранее и практически уже условно разделили их на три категории:

Математические.
Технологические.
Программные.

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

Рис. 1.5. Технологическая схема системного моделирования.

Вторая категория связана с необходимостью разработки или применения технологических методов организации как самого процесса моделирования, так и его отдельных этапов. В первую очередь, важность таких методов можно видеть на примере преобразования моделей как с целью алгоритмизации, так и с целью организации взаимодействия с пользователем, направленного на адаптацию системы моделирования к требованиям конкретной предметной области, в которой этот пользователь проводит свои исследования. От степени разработки таких средств во многом зависит и степень интеллекта [30], которым должна обладать система создания программных моделей.

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

Математическая поддержка

Адекватность

Важнейшей задачей моделирования является обеспечение адекватности. К проблеме адекватности сейчас принято относится как к некоторой общей дисциплине, относящейся к предмету рассмотрения фундаментальных наук [12]. Но более структурированный подход состоит в разделении общей проблемы на более мелкие, относящиеся к отдельным этапам построения программных моделей, составляющие, анализ которых может оказаться более доступным широкому кругу разработчиков языков моделирования.

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

Адекватность в понимании соответствия математической модели (по структуре, и динамическим свойствам) исследуемому объекту (адекватность МОДЕЛЬ – ОБЪЕКТ).
Адекватность в понимании соответствия математической модели той алгоритмической, которая ложится в основу создаваемой программной модели. Это касается также преобразований моделей к тому или иному виду для других технологических целей (адекватность МОДЕЛЬ – МОДЕЛЬ).

В данной работе мы будем говорить о математическом аппарате, позволяющем вычислять точные количественные значения адекватности МОДЕЛЬ – МОДЕЛЬ по отношению к методам дискретизации непрерывных динамических систем [39]. Заметим, что в отличие от классической теории погрешностей численных методов данный аппарат пригоден для целей моделирования, так как позволяет вести расчет не только амплитудных погрешностей воспроизведения моделью динамики исследуемого объекта, но и частотных, т.е. позволяет полностью контролировать соответствие характера движения. В настоящее время можно констатировать тот факт, что ни одна система, претендующая на слово "моделирование" в своем названии, не может обойтись без применения данного аппарата. Ценность данного аппарата, с точки зрения построения компиляторов, состоит еще в том, что он может быть формализован до конкретных программных процедур, являющихся универсальными для любых систем ОДУ.

Важно заметить здесь, что система, обладающая средствами точного вычисления показателей адекватности МОДЕЛЬ – МОДЕЛЬ, может избавить коллективы разработчиков от вечных споров на тему "кто виноват"?: разработчики математической модели или программисты и, что существенно в некоторых случаях, помочь исправить ошибки, возникшие на этапе построения исходной для компилятора математической модели.

Пример [4]. В данной работе проводились исследования, связанные с накоплением азота в хвойных деревьях под влиянием выбросов химических предприятий и сельскохозяйственных работ. Авторы исследовали поведение экосистемы на основе следующей системы ОДУ.

\begin{aligned} \frac{dW}{dt} & = (a - bW)N - fW, \\ \frac{dN}{dt} & = (U + qM)\frac{W}{W + \omega} - pfW, \\ \frac{dM}{dt} & = U - \frac{dN}{dt} = U - (U + qM) \frac{W}{W + \omega} + pfW, \\ \frac{dU}{dt} & = c. \end{aligned}

(1.7)

Где, W – биомасса деревьев; N,M – накопленное количество азота в деревьях и почве, соответственно; U – отложение азота (исключение из оборота); a, b, c, f, p, q, \omega – постоянные коэффициенты.

Для скандинавских стран авторы [4] задавали следующие начальные условия и коэффициенты:

\begin{aligned} \: & \: & a & = 18.4; \\ W_0 & = 3000.0; \:\: & b & = 0.000377; \\ N_0 & = 45.0; \: & c & = 1.03; \\ M_0 & = 40.0; \: & f & = 0.15; \\ U_0 & = 3.0; \:\: & p & = 0.008; \\ \: & \: & q & = 0.2; \\ \: & \: & \omega & = 10.0. \\ \end{aligned}

(1.8)

При решении системы (1.7) методом Эйлера с шагом равным 1.0 год, через 120 лет наступала (по мнению авторов [4]) экологическая катастрофа, т.к. решение системы (1.7) из апериодического становилось колебательным и шло "в разнос". Действительно, если решать данную систему методом Рунге-Кутты 4-го порядка мы будем наблюдать "катастрофу", но уже не через 120, а через 170 лет. Если бы авторы были знакомы с Динамической теорией погрешностей численных методов дискретизации ОДУ[39], они могли бы выбрать более точный метод, например, метод 12-го порядка точности с шагом интегрирования 0.5. Этот метод дает устойчивое решение, но только на рубеже 300 лет азота, накопленного в хвое дерева становится больше чем масса самого дерева, что наверное говорит о некорректности выбора исходной ММ. Как говорится, – катастрофа не состоялась, но пожертвования уже собраны.

Данный пример мы привели с целью предостеречь разработчиков компиляторов языков моделирования от подобных ошибок, вызванных недостаточным использованием математики при построении своих систем.

В этой связи нельзя не привести высказывание А.Н.Колмогорова, которое цитирует академик С.В.Емельянов [12]. Приведем и мы его полностью: "Весьма вероятно, что в очень многих случаях разумно изучение реальных явлений вести, избегая промежуточный этап их стилизации в духе представлений математики бесконечного и непрерывного, переходя прямо к дискретным моделям. Особенно это относится к изучению сложно организованных систем, способных перерабатывать информацию. В наиболее развитых таких системах тяготение к дискретности работы вызвано достаточно разъясненными в настоящее время причинами". Да, мы согласны с первым предложением этой фразы, но только в том случае, если имеется точное значение показателей адекватности такого стремительного перехода к дискретной модели. Конечно существуют языки, позволяющие вести описание непрерывных явлений прямо в дискретном виде, например, язык алгоритмических сетей [29] позволяет прямо в графическом виде составлять описание исследуемых явлений, однако он дает вычислительные схемы подобные (1.6) для (1.1) и не более того, а это "катастрофа" подобная той, что описана в [4]. Мы не встречали еще компиляторов, способных предложить аппарат для устранения этих проблем (даже такие пакеты как Mathematica или Mathlab в лучшем случае Вам предложат указать только амплитудную допустимую погрешность интегрирования ОДУ), поэтому последнее предложение фразы А.Н.Колмогорова мы расцениваем так, что "разъясненными в настоящее время причинами" тяготения к дискретности является лишь стремление к простоте, неподкрепленное соответствующим математическим аппаратом.

Стоит также сказать, что иногда даже отсутствие некоторых методов математики может быть компенсировано удачным распределением средств решения проблем и ответственности за их применение по отдельным этапам процесса моделирования.

Чувствительность

К еще одной проблеме математического обеспечения следует отнести методы оценки чувствительности. Мы не будем обсуждать полный спектр проблем, решаемых данными методами, скажем только, что они могут применяться для:

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

Все эти и подобные методы могут обеспечить, в конечном счете, не только формирование достоверных квалиметрических паспортов разрабатываемых моделей, но и в ряде случаев указать на некоторые ошибки, возникшие на этапе построения математической модели.

Специальное математическое обеспечение

Разумно обеспечить в системе моделирования и некоторые специальные алгоритмы, способные поддержать технологические процессы оценки адекватности и чувствительности.

Примером таких алгоритмов может служить формирование (алгоритмическое, в случае линейных моделей, или численное, в случае нелинейных моделей) начальной или текущей матрицы Якоби разрабатываемой модели.

Важным в отношении математического обеспечения системы моделирования является не только более полная поддержка методами, в смысле их количества, но и выбор среди них наиболее универсальных, способных работать с различными формами представления и видами математических моделей.

Преобразования

Еще одной проблемой, требующей математической поддержки, является необходимость преобразований математических, алгоритмических и даже программных моделей, которые в общем случае могут относиться как к преобразованию моделей из одного вида в другой, так и к преобразованиям с целью усложнения, упрощения той или иной модели. Первый вид преобразований связан с непосредственным применением методов математики (напрмер, численные методы дискретизации ОДУ). Здесь не следует забывать и о методах, связанных с синтаксическим анализом исходных текстов моделей, и даже о методах распознавания образов и разводки схем для графических представлений ММ. Второй требует непосредственного участия человека, который должен принимать решения на основе результатов, полученных методами, обеспечивающими информацией, необходимой для принятия таких решений (напрмер, методы оценки чувствительности).

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

Двоичные ресурсы

Поскольку моделирование сложных систем в большинстве случаев заставляет нас идти по пути составления моделей из более простых (и, может быть, более изученных) моделей, являющихся моделями отдельных блоков, входящих в состав исследуемой системы, надо говорить о библиотеках моделей, которые должен иметь в своем распоряжении пользователь. Кроме того, разработчики систем моделирования должны обеспечить возможность наращивания таких библиотек самим пользователем. Нельзя не отметить и необходимость наличия в системах моделирования ресурсов, подобных таблицам коэффициентов методов дискретизации ОДУ, которые можно хранить прямо в двоичном (откомпилированном) виде и подключать к программным моделям на этапе компоновки (как это делается компиляторами обычных языков программирования). Не останавливаясь более на деталях, приведем перечень необходимых, как нам кажется, библиотек, рассмотрение которого связано не только с математическим обеспечением системы, но и с программным.

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

Планирование экспериментов

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

Технологическая поддержка

Технологическая поддержка процесса моделирования основывается на методах математики и по своей сути должна обеспечивать необходимый перечень наших действий по:

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

Наличие методов поддержки тех или иных технологоческих действий во многом определяет структуру общей программной поддержки системы моделирования.

Говоря о технологии системного моделирования следует выделить две важные составляющие [12]:

методологическая составляющая технологии;
прикладные цели и задачи технологии, направленной на получение полезных результатов.

Программная поддержка

Требования к программному обеспечению систем моделирования можно разделить на две основные группы:

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

Первая группа требований достаточно подробно описывается в современной литературе и для средств моделирования в основном сводится к необходимости обеспечения:

простоты и удобства программирования;
удобства ввода-вывода информации (дружественность интерфейса пользователя);
возможности обеспечения наглядности и средств автоматизации в процессе интерпретации результатов расчетов (моделирования);
полноты средств отладки;
полноты библиотек стандартного математического обеспечения;
переносимости с платформы на платформу за счет соблюдения стандартов;
и т.д.

Вторую группу требований следует рассматривать через призму задач системного моделирования и несколько иного (в отличие от обычных операционных систем) представления программной модели. К этим требованиям наверное следует отнести:

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

Искусственный интеллект

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

Данное определение имеет скользкий смысл...[20], – "Кое-что укладывается сегодня в определение ИИ, но как только мы видим работу программы и понимаем задачу, мы уже не думаем о ней, как о ИИ...".

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

Графическое программирование

Приведем высказывание Ф.Брукса из, зачитанного нами до дыр, бестселлера [20]:

"Излюбленной темой докторских диссертаций в программной инженерии является графическое, или визуальное, программирование – применение компьютерной графики в разработке программного обеспечения [7]. Иногда перспективы такого подхода основываются на аналогии с проектированием СБИС, в котором компьютеры играют такую большую роль. Иногда такой подход обосновывается, исходя из того, что блок-схемы являются идеальным материалом при проектировании программ. Имеются мощные средства для создания таких блок-схем.

Ничего убедительного и удивительного из этих попыток пока не вышло, – и я уверен, не выйдет.

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

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

Мы абсолютно согласны, как с первым, так и со вторым обоснованием Ф.Брукса в переложении на математическое моделирование сложных систем. Действительно, разработчики дифференциальных моделей, например, сначала записывают системы ОДУ в текстовой форме, затем приводят их к нормальной форме и после этого пытаются рисовать схемы, подобные (1.4) и (1.5), причем сначала на бумаге и только потом на экране монитора, тратя при этом не мало усилий. Более того, если представить себе внушительные размеры схемы (типа (1.5)) для системы ОДУ, например, 128-го порядка (а это далеко не предел для сложных систем), у исследователей вообще может отпасть желание использовать системы подобные системе КОГНИТРОН [29].

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

Например, анализ схемы [32] представленной на рис.1.6

Рис. 1.6. Структурная схема активной гироскопической системы.

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

\left.\begin{aligned} I_z \ddot{\theta} & + 2H \dot{\beta} = M_z; \: \\ I_{\gamma} \ddot{\beta} & + \mu \dot{\beta} - H \dot{\theta} = M_{\beta}, \: \end{aligned}\right\}

(1.9)

где, M_{\beta} = k_{\theta} + k_{\dot{\theta}}\dot{\theta} – закон управления.

Как правило, в прикладном моделировании сложные системы разбиваются на более простые компоненты подобные (1.9) и, если речь идет о компиляторах языков моделирования, наверное будет лучшим выходом обеспечение возможности различного представления ММ. В идеале программа (АМ) может представляться как набор графических и текстовых моделей, а уж чего будет больше, пользователь решит самостоятельно. Нам в этом смысле нельзя делать никаких предположений о том, чего хочет или не хочет пользователь, наша задача обеспечить его работу как можно более полным набором средств.

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

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

Выводы

Проведенный анализ некоторых методологических вопросов и обзор задач, которые стоят перед разработчиками систем автоматизации, позволяет кратко сформулировать требования к операционным средам и компиляторам языков моделирования.

Разрабатываемые средства моделирования должны иметь развитую программную, технологическую и математическую поддержку. Наиболее выжными требованиями к оболочкам моделирования являются:

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

Сами же ПМ должны удовлетворять большому числу требований, обусловленных постоянным совершенствованием как операционных систем ЭВМ, так и развитием вычислительной математики. Вот некоторые из них:

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

К числу новейших требований к ПМ необходимо отнести следующие:

возможность модели самостоятельно "жить" в среде по заложенному в саму модель алгоритму существования;
возможность ?общения? моделей между собой (динамический обмен данными) в сетке модельного "времени";
прозрачность структуры и управляемость модели со стороны среды ее "обитания" (операционной среды).

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

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

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

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

Данная работа посвящена, главным образом, созданию предпосылок для решения этих задач.

Элементы технологии создания и структура ПМ

Итак – мы определили ряд новейших требований к программным моделям и, как выяснилось, спектр этих требований уже нельзя располагать лишь в одном измерении. Как минимум, число таких измерений должно быть равно трем:

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

Удовлетворение этому пространству требований возможно лишь при наличии определенной структуры ПМ, в которую укладывается наше новое объектное понимание "программ", выполняемых на ЭВМ под управлением, уже не просто операционных систем, а "операционных сред", обеспечивающих взаимодействие ПМ на всех стадиях проведения многомодельных вычислительных экспериментов.

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

Здесь нам может помочь только практика.

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

  dy_1/dt = y_2;
  dy_2/dt = -2 * Nu * y_2 - Omega * Omega * sin( y_1 );

где, символ '*' - операция умножения.

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

Пройдем и мы путь построения простой программной модели для того, чтобы более четко сформулировать задачи, которые будут выступать перед нами как при разработке интерпретатора или компилятора языка, так и при создании более сложных систем автоматизации процесса моделирования. Главным образом мы сосредоточим свое внимание на тех этапах создания ПМ, которые могут и должны быть автоматизированы, не забывая о том, что мы должны избавить исследователя от необходимости длительного изучения, разрабатываемого нами языка описания АМ. Кроме того, мы будем иметь ввиду предстоящие задачи по обеспечению компиляции других видов ММ и возможности представления различных вычислительных алгоритмов, а также о прозрачности ПМ для среды. Словом, мы не будем забывать о пространстве требований к ПМ и о новом объектном подходе.

Постановка задач

В качестве простого примера пути, который проходит исследователь при построении прикладной ПМ, рассмотрим моделирование движения маятника массой m, подвешенного на нерастяжимой невесомой нити длины l, в среде с сопротивлением, пропорциональным скорости. Предположим, что маятник движется в одной вертикальной плоскости (рис. 2.1).

На точку M действуют три силы: ее вес G, реакция нити N и сила сопротивления B, пропорциональная скорости \nu и направленная в противоположную направлению движения сторону:

B = k \frac{ds}{dt},

где, k – коэффициент сопротивления среды, а s – дуговая координата точки M.

Уравнения движения точки M в форме Эйлера имеют вид:

\begin{aligned} m \frac{d^2s}{dt^2} & = G_{\tau} + B_{\tau} = -m g \sin \varphi - k \frac{ds}{dt},\\ m \frac{\nu^2}{l} & = G_n + N_n = -m g \cos \varphi + N. \end{aligned}

(2.1)

За начало отсчета дуговой координаты s примем точку O_1 (рис.2.1), находящуюся в положении равновесия маятника.

Рис. 2.1. Схема действия сил на физический маятник.

Так как s=l\varphi, то

\frac{d^2s}{dt^2} = l \frac{d^2 \varphi}{dt^2}.

Подставляем значение d^2 s / dt^2 в первое уравнение системы (2.1):

ml\frac{d^2 \varphi}{dt^2} + kl\frac{d \varphi}{dt} + mg\sin\varphi = 0.

Разделив обе части уравнения на коэффициент, стоящий при старшей производной, получим:

\frac{d^2 \varphi}{dt^2} + \frac{k}{m}\frac{d \varphi}{dt} + \frac{g}{l}\sin\varphi = 0.

Введем обозначения d/m=2\nu, g/l=\omega^2 и перепишем уравнение в следующем виде.

\ddot{\varphi}+2\nu\dot{\varphi}+\omega^2\sin\varphi=0.

(2.2)

Здесь член 2\nu\dot{\varphi} происходит от сопротивления среды, и \nu называется коэффициентом сопротивления; член \omega^2\sin\varphi происходит от внутренней силы системы, и \omega^2 называется коэффициентом восстановления.

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

Наиболее распространенными являются методы Рунге-Кутты, схему которых мы собираемся рассмотреть.

В качестве примера используем задачу Коши:

\begin{aligned} & \dot{y}(t) = f(t,y(t)), \:\:\:\: t_0\leq t \leq T,\\ & y(t_0) = y_0. \end{aligned}

(2.3)

Численные методы позволяют искать приближенное решение задачи (2.3) лишь в фиксированных точках t_n, n=1,2,\dots,N данного отрезка. Узловые точки t_n возьмем равноотстоящими с шагом h:

t_n=t_0+nh, \:\:\:\: n=1,2,\dots,N, \:\:\:\: h>0, \:\:\:\: N=\left [ \frac{T-t_0}{h} \right ].

Здесь \left [ a \right ] означает целую часть a.

Решение задачи Коши (2.3) равносильно решению интегрального уравнения

y(t)=y_0+\int_{t_0}^{t}f(t,y(t))\:dt, \:\:\:\: t_0\leq t\leq T.

Связь между двумя соседними значениями искомой функции y(t) дает следующее очевидное равенство:

y(t_{n+1})=y(t_n)+\int_{t_n}^{t_{n+1}}\dot{y}(t)\:\:dt

или

y(t_{n+1})=y(t_n)+\Delta y,

где,

\Delta y = \int_{t_n}^{t_{n+1}}f(t,y(y))\:\:dt.

(2.4)

Схема Рунге-Кутты подразумевает поиск приближенного значения \Delta y в виде линейной комбинации:

\Delta y \approx \sum_{i=1}^{s} b_ik_i\:.

(2.5)

Здесь коэффициенты k_i вычисляются последовательно по формулам

\begin{aligned} k_1 & = hf(t,y), \\ k_2 & = hf(t+c_2h, \:\: y+a_{21}k_1), \\ k_3 & = hf(t+c_3h, \:\: y+a_{31}k_1 + a_{32}k_2), \\ \cdots & \:\:\:\:\:\:\:\:\:\:\:\:\:\: \cdots \:\:\:\:\:\:\:\:\:\:\:\: \cdots \\ k_s & = hf(t+c_sh, \:\: y+a_{s1}k_1 + a_{s2}k2 + \cdots + a_{ss-1}k_{s-1}). \end{aligned}

(2.6)

При этом метод называется явным s-стадийным методом Рунге-Кутты. Вещественные параметры c_i, a_{ij}, b_i определяют метод и представляются в виде таблицы Батчера [27]:

\left.\begin{matrix} 0 \\ c_{2} \\ c_{3} \\ \vdots \\ c_{s} \\ \hline \, \end{matrix}\right| \begin{matrix} \: \\ a_{21} \\ a_{31} & a_{32} \\ \vdots & \vdots \\ a_{s1} & a_{s2} & \ldots & a_{ss-1} & \: \\ \hline b_{1} & b_{2} & \ldots & b_{s-1} & b_{s} \\ \end{matrix}\:\:\:\:\:\rightarrow\:\:\:\:\: \begin{matrix} \textbf{c} & \vline & \textbf{A} \\ \hline \, & \vline & \textbf{b}^T \end{matrix}

(2.7)

Здесь \textbf{c} – является вектором абсцисс метода, а \textbf{b} – вектором весовых коэффициентов.

Мы рассмотрели явные методы, т.е. методы, у которых коэффициенты a_{ij} при j\geq i равны нулю.

Методы, у которых не все элементы матрицы \textbf{A}, расположенные на и над главной диагональю равны нулю, называются неявными.

Теперь, обозначив приближенные значения искомой функции y(t) задачи (2.3) в точках t_n как y_n, запишем общую формулу любого (одношагового) метода Рунге-Кутты [27].

y_{n+1}=y_n+h\sum_{i=1}^{s}b_ik_i,

(2.8)

где,

k_i=f(t_n+c_ih, \:\: y_n+h\sum_{j=1}^{s}a_{ij}k_j) \:\:\:\:\: (1\leq i\leq s).

После рассмотрения схемы работы методов Рунге-Кутты мы можем выбрать конкретный метод [27,57] и приступать к численному решению уравнения (2.2).

Для этого надо привести это уравнение к системе двух уравнений первого порядка в нормальной форме Коши, т.е. уравнения системы должны быть разрешены относительно производной.

Это не трудно сделать, введя следующие обозначения:

\begin{aligned} \varphi & = y_1, \\ \dot{\varphi} & = y_2. \end{aligned}

(2.9)

Тогда, естественно, \dot{y}_1=y_2, а величину \dot{y}_2 можно получить из уравнения (2.2):

\dot{y}_2 = -2\nu y_2 - \omega^2 \sin y_1.

Итак, уравнение (2.2) равносильно следующей системе двух уравнений.

\left.\begin{aligned} \dot{y}_1 & = y_2, \\ \dot{y}_2 & = -2\nu y_2 - \omega^2 \sin y_1. \:\: \end{aligned}\right\}

(2.10)

Для начала воспользуемся методом Эйлера:

\begin{matrix} \textbf{0} & \vline & \textbf{0} \\ \hline \, & \vline & \textbf{1} \end{matrix} \:\:\:,

(2.11)

который требует лишь однократного вычисления правых частей системы ОДУ на каждом шаге интегрирования.

Попробуем раскачать пудовую гирю на тросе длиной 7 метров:

  double l = 7.;
  double m = 16.;

задавшись коэффициентом сопротивления среды, например:

  double k = 3.0;

Тогда коэффициент сопротивления \nu мы сможем рассчитать по формуле

  double Nu = k/2.0/m;

а коэффициент восстановления \omega – по формуле

  double Omega = sqrt( g/l );

предварительно объявив переменную g

  double g = 9.08665;

равную ускорению силы тяжести.

Как Вы успели заметить, мы начали записывать наши рассуждения прямо в операторах языка C. Именно таким путем следует любой разработчик программной модели, если ему приходится работать с обычным языком программирования (C, FORTRAN, и т.д.).

Выберем начальные условия:

  double y1, y2;

  y1 = 30.*PI/180.;
  y2 = 0.0;

не забыв перевести величину угла \varphi в радианы.

Инициализация и параметризация модели

Выделить компонент программной модели, который будет выполняться один раз при запуске ПМ для начальной инициализации (например, расчет начальных значений вектора состояния модели). В исходных текстах программ (АМ) организовать данный компонент в виде "ключевой" функции, тело которой будет заполнять пользователь при создании АМ.

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

Шаг интегрирования положим равным единице и объявим переменную для подсчета текущего времени:

  double h = 1.0, time = 0.0;

Откроем цикл, который будет повторять выполнение находящихся в нем операторов, пока переменная time не станет больше или равной 20-и секундам:

  while( time < 20.0 )
  {

в котором будем вести счет времени

    time = time + h;

и интегрировать систему (2.10).

Модельное время

Выделить компонент программной модели, который будет представлять собой структуру модельного времени: начало, конец, шаг (здесь важно не путать шаг модельного времени и шаг основного способа жизни модели, например, метода численного интегрирования в схеме Рунге-Кутты). В исходных текстах программ (АМ) оформить данный компонент в виде "ключевой" структуры, тело которой будет заполнять пользователь при создании АМ.

Компилятор языка моделирования по данной структуре модельного времени организует цикл, в рамках которого будет существовать модель, а именно, принимать возмущающие воздействия, предоставлять телеметрическую информацию о состоянии модели, формировать след модели, естественно, на каждом шаге модельного времени будет осуществляться вызов основного способа жизни модели. В случае дифференциальных моделей, таким способом жизни может являться процедура численного интегрирования систем ОДУ.

Данный цикл будет составлять основу главного сегмента объектного кода ПМ.

Коэффициенты k_i (см.(2.6)) для обеих переменных состояния системы (2.10) будем вычислять по формулам:

    k1 = h * y2;
    k2 = h * (-2.*Nu*y2 - Omega*Omega*sin(y1));

В заключение, нам осталось сообщить переменным y1, y2 приращение, вычисленное на текущем шаге интегрирования, т.к. весовой коэффициент b_1 (см.(2.11)) метода Эйлера равен единице, мы можем смело записать

    y1 = y1 + k1;
    y2 = y2 + k2;

и завершить цикл:

  } /* End of while( time < 20 ) */

Вот практически все. Осталось позаботиться о выводе результатов. Для этого мы приготовили простую программу, которая выводит результаты в виде таблицы в файл с именем "rk1.txt". Вот полный текст этой программы:

#include <stdlib.h>
#include <stdio.h>
#include <math.h>

#define PI 3.14159265358979323846  /* число пи */

char   *output_file_name = "rk1.txt";

FILE   *output_file;

double  g = 9.80665;   /* ускорение силы тяжести (м/с^2)  */
double  l = 7.;        /* длина маятника (м)              */
double  m = 16.;       /* масса маятника (кг)             */
double  k = 3.;        /* коэффициент сопротивления среды */
double  Nu, Omega;


int main( void )
{
  double h = 1.0, time = 0.0; /* шаг интегрирования и время */
  double y1_0, y2_0, y1, y2, k1, k2;

  Nu    = k/(2*m);     /* коэффициент сопротивления  */
  Omega = sqrt( g/l ); /* коэффициент восстановления */

  y1_0 = 30.*PI/180.;  /* начальное значение угла 30 град.    */
  y2_0 = 0.;           /* начальное значение угловой скорости */

  /* открыть файл для записи */
  if( (output_file = fopen( output_file_name, "w+" ) ) == NULL )
  {
     printf("Cannot open file");
  }

  fprintf( output_file, "\n" );
  fprintf( output_file, " +------+---------------------------------+\n" );
  fprintf( output_file, " |      |         Решение системы         |\n" );
  fprintf( output_file, " |      |   дифференциальных уравнений    |\n" );
  fprintf( output_file, " | t, c |          методом Эйлера         |\n" );
  fprintf( output_file, " |      +----------------+----------------+\n" );
  fprintf( output_file, " |      |       y1(t)    |       y2(t)    |\n" );
  fprintf( output_file, " +------+----------------+----------------+\n" );

  y1 = y1_0;
  y2 = y2_0;

  fprintf( output_file, " | %4.1f | %14.6e | %14.6e |\n",
                            time,   y1,      y2          );

  while( time < 20 )
  {
    time = time + h;

    k1 = h*y2;
    k2 = h*(-2.*Nu*y2 - Omega*Omega*sin( y1 ));

    y1 = y1 + k1;
    y2 = y2 + k2;

    /**************************************************
      можно было обойтись без k1 и k2:

      y1 = y1 + h*y2;
      y2 = y2 + h*(-2.*Nu*y2 - Omega*Omega*sin( y1 ));

      но это грубая ошибка !!!!!!!!!!!!!!!!!!!!!!!!!!!
     **************************************************/

    fprintf( output_file, " | %4.1f | %14.6e | %14.6e |\n",
                              time,   y1,      y2          );
  }

  fprintf( output_file, " |      |                |                |\n");
  fprintf( output_file, " +------+----------------+----------------+\n");

  /* закрыть файл */
  fclose( output_file );

  return( 0 ); /* exit SUCCESS */

} /* End of main( void ) */

Результатом работы данной программы будет следующая таблица.

 +------+---------------------------------+
 |      |         Решение системы         |
 |      |   дифференциальных уравнений    |
 | t, c |          методом Эйлера         |
 |      +----------------+----------------+
 |      |       y1(t)    |       y2(t)    |
 +------+----------------+----------------+
 |  0.0 |   5.235988e-01 |   0.000000e+00 |
 |  1.0 |   5.235988e-01 |  -7.004750e-01 |
 |  2.0 |  -1.768762e-01 |  -1.269611e+00 |
 |  3.0 |  -1.446487e+00 |  -7.850542e-01 |
 |  4.0 |  -2.231541e+00 |   7.522831e-01 |
 |  5.0 |  -1.479258e+00 |   1.717329e+00 |
 |  6.0 |   2.380712e-01 |   2.790415e+00 |
 |  7.0 |   3.028486e+00 |   1.936828e+00 |
 |  8.0 |   4.965314e+00 |   1.415554e+00 |
 |  9.0 |   6.380867e+00 |   2.506516e+00 |
 | 10.0 |   8.887383e+00 |   1.899914e+00 |
 | 11.0 |   1.078730e+01 |   8.265337e-01 |
 | 12.0 |   1.161383e+01 |   2.042232e+00 |
 | 13.0 |   1.365606e+01 |   2.800934e+00 |
 | 14.0 |   1.645700e+01 |   1.033839e+00 |
 | 15.0 |   1.749084e+01 |   1.793945e+00 |
 | 16.0 |   1.928478e+01 |   2.827143e+00 |
 | 17.0 |   2.211192e+01 |   1.706394e+00 |
 | 18.0 |   2.381832e+01 |   1.555234e+00 |
 | 19.0 |   2.537355e+01 |   2.618789e+00 |
 | 20.0 |   2.799234e+01 |   1.793654e+00 |
 +------+----------------+----------------+

Построим график этого процесса (рис. 2.2).

Рис. 2.2. Решение системы дифференциальных уравнений (2.10) методом Эйлера.

Как видно из графика приведенного на рис. 2.2, мы получили совершенно неприемлемое решение системы (2.10).

Не стоит искать ошибки в программе, хотя вина за проишедшее полностью лежит на нас: мы выбрали не тот метод, который следовало применять при шаге равном единице h = 1.0 .

Порядок системы (2.10) равен двум:

#define NSYS   2

Выберем теперь четырехэтапный метод Рунге-Кутты:

#define NST    4
double c[NST]     = {0.0, 0.5, 0.5, 1.0};

double A[NST*NST] = {0.0, 0.0, 0.0, 0.0,
                     0.5, 0.0, 0.0, 0.0,
                     0.0, 0.5, 0.0, 0.0,
                     0.0, 0.0, 1.0, 0.0};

double b[NST]     = {0.16666666666666666,
                     0.33333333333333333,
                     0.33333333333333333,
                     0.16666666666666666};

double f[NSYS*2], X[NSYS*NST]; /* вспомогательные массивы */

Таким образом мы определили массивы, содержащие таблицу Батчера четырехэтапного метода Рунге-Кутты:

\left.\begin{matrix} 0 \\ 1/2 \\ 1/2 \\ 1 \\ \hline \, \end{matrix}\right| \begin{matrix} \: \\ 1/2 \\ 0 & 1/2 \\ 0 & 0 & 1 & \: \\ \hline 1/6 & 1/3 & 1/3 & 1/6 \\ \end{matrix}

Для последующей работы нам понадобится массив

double f[NSYS*2];

количество элементов которого в два раза больше чем число уравнений системы (2.10). В первой половине массива f[] мы будем хранить вектор решения системы, т.е. переменные y1 и y2.

Расчет правых частей уравнений системы (2.10) будем производить посредством функции part_right():

void part_right( double f[], int N )
{
  double y1, y2;

  y1 = f[N];
  y2 = f[N+1];

  f[N]   =  y2;
  f[N+1] = -2.*Nu*y2 - Omega*Omega*sin( y1 );
}

которую будет вызывать функция dsmint(), осуществляющая непосредственно интегрирование системы ОДУ. Кроме функции расчета правых частей, параметрами функции dsmint() являются: массив f[], шаг интегрирования h, два числа, определяющие порядок системы (NSYS) и количество стадий (NST) используемого метода, а также сам метод, представленный массивами A[] и b[], которые мы определили выше.

Динамика модели и синтаксический анализ

Выделить компонент программной модели, который будет определять динамику ее поведения согласно исходной ММ. В исходных текстах программ (АМ) организовать данный компонент в виде "ключевой" функции, тело которой будет заполнять пользователь текстом исходной ММ (в виде, подобном (2.10)).

Синтаксические и семантические анализаторы компилятора должны обеспечивать анализ различных видов ММ. В случае дифференциальных моделей это может быть вид, представленный формулой (2.2) или хотя бы (2.10).

Здесь "внешний вид" производных не имеет принципиального значения. Для компилятора их лучше представлять в виде линейной последовательности байт (символов), например, так: dy/dt или y'. Украсить внешний вид уравнений для пользователя можно будет потом, навесив препроцессор (подобный компилятору TEX), который будет осуществлять преобразования формул в простую последовательность символов, например, так \definecolor{dynamics}{RGB}{152,0,18} \color{dynamics} \sqrt{g/a}\to sqrt(g/alpha). Эта тема не будет нами рассматриваться далее, здесь мы лишь предлагаем путь совершенствования интерфейсной части системы моделирования (кстати, редакторы моделей, представленных в графической форме, также должны осуществлять подобные преобразования "текстов" до передачи их непосредственно компилятору).

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

Преобразования моделей и оптимизация кода

Поскольку мы говорим о разных видах ММ, мы не должны забывать о преобразовании моделей из одного вида в другой (см. раздел Преобразования моделей).

В случае дифференциальных моделей, первоочередной задачей будет разработка алгоритма приведения систем ОДУ к нормальной форме (2.10). И, кроме того, обеспечение оптимизации кода, например путем выделения статической части модели и переноса ее в программу инициализации ПМ (см. цель Инициализация модели).

Перед началом цикла интегрирования надо инициировать первую половину массива f[] начальными значениями:

  f[0] = y1_0;
  f[1] = y2_0;

а тело цикла переписать следующим образом

  while( time < 20 )
  {
    time = time + h;

    dsmint( h, f, NSYS, NST );

    y1 = f[0];
    y2 = f[1];

    /*
      Здесь можно записать оператор вывода решения, например,
      fprintf( output_file, " | %4.1f | %14.6e | %14.6e |\n",
                                time,   y1,      y2          );
     */
  }

Полный текст программы приведен на следующем листинге.

#include <stdlib.h>
#include <stdio.h>
#include <math.h>

#define PI 3.14159265358979323846  /* число пи */

char   *output_file_name = "rk4.txt";

FILE   *output_file;

double  g = 9.80665;   /* ускорение силы тяжести (м/с^2)  */
double  l = 7.;        /* длина маятника (м)              */
double  m = 16.;       /* масса маятника (кг)             */
double  k = 3.;        /* коэффициент сопротивления среды */
double  Nu, Omega;

/* функция расчета правых частей */
void part_right( double f[], int N )
{
  double y1, y2;

  y1 = f[N];
  y2 = f[N+1];

  f[N]   =  y2;
  f[N+1] = -2.*Nu*y2 - Omega*Omega*sin( y1 );
}

#define NSYS   2
#define NST    4

/* классический метод Рунге-Кутты */
double c[NST]     = {0.0, 0.5, 0.5, 1.0};

double A[NST*NST] = {0.0, 0.0, 0.0, 0.0,
                     0.5, 0.0, 0.0, 0.0,
                     0.0, 0.5, 0.0, 0.0,
                     0.0, 0.0, 1.0, 0.0};

double b[NST]     = {0.16666666666666666,
                     0.33333333333333333,
                     0.33333333333333333,
                     0.16666666666666666};

double f[NSYS*2], X[NSYS*NST]; /* вспомогательные массивы */

Библиотеки методов

Обеспечить возможность хранения параметров методов вычислительной математики (для дифференциальных моделей это могут быть, например, методы Рунге-Кутты в виде таблиц Батчера (2.7)) в двоичных библиотеках, которые будут компоноваться с готовыми ПМ. Библиотеки по крайней мере должны обеспечивать:

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

Обеспечить пользователю возможность выбора численного метода (по имени) из библиотеки и задания шага схемы (2.8). В случае несоразмерности шагов модельного времени и шага метода, система должна интерполировать решение системы в нужной точке модельного времени для корректной передачи значений.

Данную задачу можно решить путем введения компонента ПМ, описывающего структуру метода. В исходных текстах программ (АМ) это так же можно решить с помощью "ключевой" структуры, тело которой будет заполнять пользователь.

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

/* функция интегрирования ОДУ методами Рунге-Кутты */
void dsmint( double h,
             double f[],
             int    N,
             int    NS )
{
  int i,j,k,l,m;

  for( j = m = 0; j ‹ NS; j++, m++ )
  {
    for( i = 0; i ‹ N; i++ ) f[N+i] = f[i];
    if( j == 0 ) goto point;
    for( k = 0; k < m; k++ )
      for( i = 0, l = k * N; i ‹ N; i++ )
        f[N+i] += A[j*NS+k] * X[l+i]; /* A[j][k] */

point:   part_right( f, N );

     for( i = 0, l = m * N; i ‹ N; i++ ) X[l+i] = f[N+i] * h;
   }

   for( j = 0; j ‹ NS; j++ )
     for( i = 0, l = j * N; i ‹ N; i++ )
       f[i] += b[j] * X[l+i];
}

Основной способ жизни модели

Обеспечить реализацию методов вычислительной математики в непараметризованном виде, т.е. в виде функций принимающих в качестве аргументов:

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

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

Это утверждение касается не только численных методов интегрирования систем ОДУ, далее мы покажем, что такой подход применим и к другим методам, в том числе и к методам интегрирования обычных функций.

int main( void )
{
  double h = 1.0, time = 0.0; /* шаг интегрирования и время */
  double y1_0, y2_0, y1, y2, k1, k2;

  Nu    = k/(2*m);     /* коэффициент сопротивления  */
  Omega = sqrt( g/l ); /* коэффициент восстановления */

  y1_0 = 30.*PI/180.;  /* начальное значение угла 30 град.    */
  y2_0 = 0.;           /* начальное значение угловой скорости */

  /* открыть файл для записи */
  if( (output_file = fopen( output_file_name, "w+" ) ) == NULL )
  {
    printf("Cannot open file");
  }

  fprintf( output_file, "\n" );
  fprintf( output_file, " +------+---------------------------------+\n" );
  fprintf( output_file, " |      |         Решение системы         |\n" );
  fprintf( output_file, " |      |   дифференциальных уравнений    |\n" );
  fprintf( output_file, " |      |      классическим методом       |\n" );
  fprintf( output_file, " | t, c |           Рунге-Кутты           |\n" );
  fprintf( output_file, " |      +----------------+----------------+\n" );
  fprintf( output_file, " |      |       y1(t)    |       y2(t)    |\n" );
  fprintf( output_file, " +------+----------------+----------------+\n" );

  f[0] = y1_0;
  f[1] = y2_0;

  y1 = y1_0;
  y2 = y2_0;

  fprintf( output_file, " | %4.1f | %14.6e | %14.6e |\n",
                            time,   y1,      y2          );

  while( time < 20 )
  {
    time = time + h;

    dsmint( h, f, NSYS, NST );

    y1 = f[0];
    y2 = f[1];

    fprintf( output_file, " | %4.1f | %14.6e | %14.6e |\n",
                              time,   y1,      y2          );

След программной модели

Обеспечить возможность определения структуры следа ПМ. В простейшем случае структурой следа может быть список переменных, предназначенных для вывода в моменты, определяемые шагом модельного времени. В принципе, кроме структуры следа модели должны существовать подобные структуры для переменных, значениями которых модель обменивается со средой и другими моделями во время своей жизни. Именно след нужен главным образом для принятия решений после завершения работы ПМ.

  }

  fprintf( output_file, " |      |                |                |\n");
  fprintf( output_file, " +------+----------------+----------------+\n");

  /* закрыть файл */
  fclose( output_file );

  return( 0 ); /* exit SUCCESS */

} /* End of main( void ) */

Результатом работы этой программы будет файл "rk4.txt" со следующим содержимым.

 +------+---------------------------------+
 |      |         Решение системы         |
 |      |   дифференциальных уравнений    |
 | t, c |      классическим методом       |
 |      |           Рунге-Кутты           |
 |      +----------------+----------------+
 |      |       y1(t)    |      y2(t)     |
 +------+----------------+----------------+
 |  0.0 |   5.235988e-01 |   0.000000e+00 |
 |  1.0 |   2.312406e-01 |  -5.026856e-01 |
 |  2.0 |  -2.539221e-01 |  -3.737134e-01 |
 |  3.0 |  -3.739112e-01 |   1.323398e-01 |
 |  4.0 |  -6.792102e-02 |   4.031494e-01 |
 |  5.0 |   2.537464e-01 |   1.848580e-01 |
 |  6.0 |   2.392014e-01 |  -1.916042e-01 |
 |  7.0 |  -3.256128e-02 |  -2.902620e-01 |
 |  8.0 |  -2.173621e-01 |  -5.344859e-02 |
 |  9.0 |  -1.302916e-01 |   1.965208e-01 |
 | 10.0 |   8.244331e-02 |   1.851334e-01 |
 | 11.0 |   1.648146e-01 |  -2.634568e-02 |
 | 12.0 |   5.152830e-02 |  -1.691045e-01 |
 | 13.0 |  -9.661589e-02 |  -9.990616e-02 |
 | 14.0 |  -1.110089e-01 |   6.536632e-02 |
 | 15.0 |  -1.238437e-03 |   1.279281e-01 |
 | 16.0 |   8.907154e-02 |   3.857462e-02 |
 | 17.0 |   6.476820e-02 |  -7.602526e-02 |
 | 18.0 |  -2.582983e-02 |  -8.571304e-02 |
 | 19.0 |  -7.096438e-02 |   2.991270e-04 |
 | 20.0 |  -2.983477e-02 |   6.967596e-02 |
 +------+----------------+----------------+

Это уже похоже на истину. Однако, нам трудно оценить точность данного решения, так как уравнение (2.2) нельзя проинтегрировать в квадратурах и сравнить точное решение с численным, которое мы только что получили.

Сделаем следующее.

При малых углах отклонения маятника можно положить, что \sin(\varphi)\approx \varphi, следовательно, приняв такое допущение, мы можем переписать уравнение (2.2) в виде:

\ddot{\varphi}+2\nu\dot{\varphi}+\omega^2\varphi=0.

(2.12)

Квалиметрия моделей

Обеспечить систему моделирования средствами квалиметрии моделей. Например, использование аппарата теории чувствительности могло бы обеспечить более доказательную основу для перехода от (2.2) к (2.12), т.е. для принятия решений о необходимости учитывать влияние малых компонентов решения на конечный результат моделирования.

Согласно введенным обозначениям и выбранным нами величинам k = 3.0, l = 7.0 и m = 16.0 имеем

\begin{aligned} \nu & = \frac{k}{2m} & = 0.09375; \\ \omega & = \sqrt{\frac{g}{l}} & = 1.18362. \end{aligned}

Характеристическое уравнение для (2.12) будет выглядеть следующим образом:

r^2+2\nu r+\omega^2=0.

(2.13)

Нетрудно вычислить корни уравнения (2.13):

r_{1,2}=-\nu\pm \sqrt{\nu^2-\omega^2}=-0.09375\pm 1.17989i,

(2.14)

их компоненты представляют собой:

\nu – показатель экспоненты в переходной составляющей решения (2.12) и
\omega_{r}=\sqrt{\nu^2-\omega^2} – собственную круговую частоту колебаний.

Следовательно, решение уравнения (2.12) можно представить формулой

\varphi = Ae^{-\nu t}\sin\left ( \frac{2\pi t}{T}+\varphi_0 \right ),

(2.15)

где, T=\frac{2\pi}{\omega_r} – период затухающих колебаний.

Итак, мы имеем следующие показатели процесса (2.15):

\nu=-0.09375, \:\:\:\:\: \omega_r=1.17989.

(2.16)

Теперь уберем вычисление синуса в функции расчета правых частей нашей программы:

void part_right( double f[], int N )
{
  .   .   .

  f[N+1] = -2.*Nu*y2 - Omega*Omega*y1;
}

и (пересобрав программу) получим новое решение, которое можно сравнивать с (2.15):

 +------+---------------------------------+
 |      |         Решение системы         |
 |      |   дифференциальных уравнений    |
 | t, c |      классическим методом       |
 |      |           Рунге-Кутты           |
 |      +----------------+----------------+
 |      |       y1(t)    |      y2(t)     |
 +------+----------------+----------------+
 |  0.0 |   5.235988e-01 |   0.000000e+00 |
 |  1.0 |   2.214980e-01 |  -5.136458e-01 |
 |  2.0 |  -2.659714e-01 |  -3.671368e-01 |
 |  3.0 |  -3.695952e-01 |   1.538084e-01 |
 |  4.0 |  -4.864812e-02 |   4.074411e-01 |
 |  5.0 |   2.647241e-01 |   1.665888e-01 |
 |  6.0 |   2.286372e-01 |  -2.110920e-01 |
 |  7.0 |  -5.109316e-02 |  -2.858743e-01 |
 |  8.0 |  -2.217925e-01 |  -3.327800e-02 |
 |  9.0 |  -1.171273e-01 |   2.078681e-01 |
 | 10.0 |   9.600776e-02 |   1.755435e-01 |
 | 11.0 |   1.635355e-01 |  -4.297034e-02 |
 | 12.0 |   3.909119e-02 |  -1.729629e-01 |
 | 13.0 |  -1.045776e-01 |  -8.880769e-02 |
 | 14.0 |  -1.064255e-01 |   7.668126e-02 |
 | 15.0 |   8.673544e-03 |   1.267732e-01 |
 | 16.0 |   9.243995e-02 |   2.847569e-02 |
 | 17.0 |   5.904449e-02 |  -8.237539e-02 |
 | 18.0 |  -3.270436e-02 |  -8.195403e-02 |
 | 19.0 |  -7.122184e-02 |   8.173722e-03 |
 | 20.0 |  -2.440547e-02 |   7.225257e-02 |
 +------+----------------+----------------+

По этим данным мы построили график и приблизительно вычислили логарифмический декремент затухания и круговую частоту процесса [39]. Эти вычисления показаны на рис. 2.3.

Нетрудно вычислить и показатель экспоненты переходной составляющей процесса, показаного на рис. 2.3:

\begin{aligned} \omega_{\Gamma} \:& = \:\:\frac{2\pi}{5.46} &=& \:\:\:\:\:\:\:\:\frac{2\times 3.141593}{5.46} &=& \:\:\:1.15077;\\ \nu_{\Gamma} \:& = \:\:\delta \frac{\omega_{\Gamma}}{\pi} &=& \:\:\:\frac{0.24419\times 1.15077}{3.141593} &=& \:\:\:0.08945. \end{aligned}

(2.17)

Вычислим относительные отклонения величин (2.16), (2.17) друг от друга:

\begin{aligned} \delta_{\nu} \:& = \:\:\frac{\nu-\nu_{\Gamma}}{\nu_{\Gamma}} \times 100\% &\approx& \:\: 5\%;\\ \delta_{\omega} \:& = \:\:\frac{\omega_r-\omega_{\Gamma}}{\omega_{\Gamma}} \times 100\% &\approx& \:\: 3\%. \end{aligned}

(2.18)

Адекватность МОДЕЛЬ – МОДЕЛЬ

Обеспечить оценку адекватности получаемых нами ПМ исходным ММ для отладки моделей согласно динамической теории погрешностей численных методов (вне зависимости от того, знаем ли мы аналитически точное решение исходной MM, или нет).

Теперь можно сделать вывод о том, что для первого опыта мы имеем не такой уж плохой результат (относительное рассогласование точного и численного решений (2.12) не превышает пяти процентов).

Рис. 2.3. Примерный график решения уравнения (2.12).

Структура программной модели

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

Объектно-ориентированное моделирование

После того как мы наметили основные цели и постарались определить спектр задач, которые необходимо решить, мы пожем представить обобщенную структуру программной модели. В отличие от системных процессов UNIX, представляемая нами структура, содержит ряд дополнительных сегментов кода и данных. Главным отличием ПМ от обычных процессов является то, что исполнение процесса делится на два этапа.

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

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

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

На рис. B.2 показана приблизительная структура ПМ, а также относительное положение наших взглядов в области машинного моделирования и вычислительной математики.

Рис. B.2. Упрощенная структура машинной модели.

Заметим здесь, что для практически любого термина, применяемого в области моделирования, специалисты всегда имеют несколько различных определений, основой которых служат различные технологии, мы не будем являться исключением, например [11], термину объектно-ориентированное моделирование (OOM) в нашей работе присваивается уже третье или четвертое смысловое значение, однако, несмотря на возможные разногласия, мы не будем выдумывать новые определения и остановимся именно на этом.

В заключение необходимо отметить, что возможность достижения поставленных целей во многом предопределена существованием Динамической теории погрешностей численных методов, которая позволяет не просто оценивать, а именно вычислять показатели адекватности МОДЕЛЬ – МОДЕЛЬ. Разумеется, Динамическая теория охватывает лишь часть всего многообразия видов математических моделей и методов их дискретизации, однако, основной принцип сравнения моделей, примененный в данной теории, в будущем, может быть распространен и на другие виды ММ, что, в свою очередь, даст новый импульс развитию методов математического моделирования как инструмента системного анализа.

ЛИТЕРАТУРА:

Chen, G., B.K.Szymanski. 2001. Component-Based Simulation. In 15th European Simulation Multiconference 2001, PRAGUE, CZECH REPUBLIC, June 6-9, 2001.
Fujimoto, R.M. 1990. Parallel discrete event simulation. Communication of the ACM: 30-53.
Fujimoto, R.M. 1993. Parallel discrete event simulation: Will the field survive? ORSA Journal on Computing: 213-230.
Göran I.Ågren, Pekka Kauppi. NITROGEN DYNAMICS IN EUROPEAN FOREST ECOSYSTEMS: CONSIDERATION REGARDING ANTHROPOGENIC NITROGEN DEPOSITIONS/International Institute for Applied Systems Analysis A-2361 Laxenburg, Austria.
Nicol, D.M. 1997. Parallel discrete event simulation: So who cares? In Proceedings of the 11^th Workshop on Parallel and Distributed Simulation.
Page, E.H. 1999. Beyond speedup: PADS, the LHA and web-based simulation. In Proceedings of the 13^th Workshop on Parallel and Distributed Simulation, 2-9.
Raeder G. A survey ofcurrent graphical programming techniques // Grafton R.B., Ichikawa T. (Eds.). Special Issue on Visual Programming // Computer. 1985. Vol/ 18, N 8. Aug. P. 11-25.
Szymanski, B.K. 1991. Parallel functional language and compilers, Chapter EPL-Parallel Programming with Recurrent Equations. ACM Press.
Thomas J. Pennello, Frank DeRemer, Efficient Computation of LALR(1) Look-Ahead Sets. 615-649. TOPLAS Vol 4, Number 4, October 1982.
Yusupov R.M. The problem of models adequacy in CAD/CAM. International Conference on CAD/CAM, Robotics and Factorics the Future. Proccedings. 1993.
Zeigler, B.P. 1990. Object-oriented simulation with hierarchical, modular models. Academic Press.
Аврамчук Е.Ф., Вавилов А.А., Емельянов С.В. Технология системного моделирования. /Под общ. Ред. С.В. Емельянова и др. – М.: Машиностроение; Берлин: Техник, 1988. – 520с.: ил.
Абгарян К.А. Матричные и асимптотические методы в теории линейных систем. – М.: Наука, 1973.
Ахо А.В., Джонсон С.К., Ульман Д.Д. Determenistic parsing of ambiguous grammars./CACM, August, 1975.
Ахо А.В., Ульман Д.Д. Principles of Compiler Design./Addison – Wesley, 1977.
Бахвалов Н.С. Численные методы. – М.: Наука, 1973. – 631 с.
Белов Ю.А., Диденко В.П. и др./Математическое обеспечение сложного эксперимента. Т.1. Обработка измерений при исследовании сложных систем. – Киев: Наукова думка, 1982. – 304с.
Бронштейн И.Н., Семендяев К.А. Справочник по математике. – М.: Наука, 1964. – 608 с.
Бронштейн И.Н., Семендяев К.А. Справочник по математике для инженеров и учащихся втузов. – 13-е изд. исправленное. – М.: Наука, 1986.
Брукс Ф. Мифический человеко-месяц или как создаются программные системы./Пер. с англ. – СПб.: Символ-Плюс, 1999. – 304 с.: ил.
Бэкус (Backus J.W.). The syntax and semantics of the proposed international algebraic language of the Zurich ACM–GAMM Conference. Proc. International Conf. On Information Processing, UNESCO (1959), 125–132.
Вабищевич П.Н. Численное моделирование. – М.: Изд-во Моск. ун-та, 1993. – 205с.
Видаль П. Нелинейные импульсные системы/Пер. с франц. – М.: Энергия, 1974. – 336 с.
Гехер К. Теория чувствительности и допусков электронных цепей. – М.: Сов. радио, 1973.
Городецкий В.И., Дмитриев А.К., Марков В.М. и др. Элементы теории испытаний и контроля технических систем/Под ред. Р.М.Юсупова. – Л.: Энергия, 1978. – 192с.
Грис Д. Конструирование компиляторов для цифровых вычислительных машин./Пер. с англ. Е.Б.Докшицкой и др. Под ред Ю.М.Баяковского, Вс.С.Штаркмана. – М.: Мир, 1975. – 544с.
Деккер К., Вервер Я. Устойчивость методов Рунге-Кутты для жестких нелинейных дифференциальных уравнений: Пер. с англ. – М.: Мир, 1988.
Захаров И.Г, Постонен С.И, Романьков В.И. Теория проектирования надводных кораблей/Под ред. И.Г.Захарова. Издание ВОЕННО-МОРСКОЙ АКАДЕМИИ им. Н.Г.Кузнецова посв. 300-летию Российского Флота. – СПб.: 1997. – 678с.
Иванищев В.В. Алгоритмическое моделирование: инструментальные средства и модели/Отв. Ред. Иванищев В.В. СПИИРАН Сборник научных трудов. – СПб.: 1992.
Иванищев В.В., Костельцев В.И. Интеллектуальное моделирование и точность вычислений/Высшее военно-морское училище. Сборник научных трудов. Под ред. Р.А. Нелепина. – СПб.: 1998.
Камке Э. Справочник по обыкновенным дифференциальным уравнениям. – М.: Наука, 1971. – 576с.
Каргу Л.И. Системы угловой стабилизации космических аппаратов. – М.: Машиностроение, 1973. – 176 с.
Керниган Б., Ритчи Д. Язык программирования Си/ Пер. с англ. Вик. С. Штаркмана/Под ред. Вс.С. Штаркмана. – М.: Финансы и статистика, 1992. – 272 с.: ил.
Костельцев В.И. Методы исследования чувствительности характеристик гибких производственных систем//Проблемы интегральной автоматизации производства. – Л.: наука, 1988. с. 19-22.
Костельцев В.И. Динамические свойства численных методов интегрирования систем обыкновенных дифференциальных уравнений. Препринт №23. – Л.: ЛИИАН, 1989. 63 с.
Костельцев А.В., Костельцев В.И. Hовый способ построения явных методов дискретизации обыкновенных дифференциальных уравнений/ IV Санкт-Петербургская Международная Конференция "Региональная информатика - 95" ("РИ - 95", Санкт-Петербург, 15 - 18 мая 1995 г.): Труды Конференции. – СПб., 1995 – 200 с.
Костельцев А.В. Идентифицирующий планировщик вычислений/ V Санкт-Петербургская Международная Конференция "Региональная информатика - 96" ("РИ - 96", Санкт-Петербург, 13 - 16 мая 1996 г.): Тезисы докладов. Часть 2. - СПб., 1996 - 167 с.
Костельцев А.В., Костельцев В.И. Технология оценивания и коррекции динамических свойств и характеристик алгоритмических сетевых моделей/ Семинар "Компьютерные системы интеллектуальной поддержки моделирования" на выставке ЛЕНЭКСПО "Мир Компьютеров" 11-15 мая 1999 г. Труды семинара.
Костельцев А.В., Костельцев В.И., Юсупов Р.М. Возмущения структуры и чувствительность математических моделей динамических объектов при их дискретизации/ Теоретические основы и прикладные задачи интеллектуальных информационных технологий/Под ред. Р.М.Юсупова. – СПб.: СПИИРАН, 1998, с.с 79-85.
Костельцев А.В. Построение интерпретаторов и компиляторов. Использование программ bison, byacc, zubr. – СПб.: Наука и техника, 2001. – 224 с.
Левин Л. Методы решения технических задач с использованием аналоговых вычислительных машин/Пер. с англ. Ч.Б. Гуревича, Г.О. Розенталя. Под ред. А.Б.Саввина. – М.: Мир, 1966. – 415с.
Лескин А.А. Алгебраические модели гибких производственных систем. – Л.: Наука, 1986. – 150с.
Ли Т.Г., Адамс Г.Э., Гейнз У.М. Управление процессами с помощью вычислительных машин: Моделирование и оптимизация./Пер. с англ. – М.: Советское радио, 1972. – 312с.
Луговский В.В. Нелинейные задачи мореходности корабля. – Ленинград.: Судостроение, 1966. – 236 с.
Мальцев А.И. Основы линейной алгебры. – М.: Наука, 1970. – 400 с.
Мартин Ф. Моделирование на вычислительных машинах./Пер. с англ. – М.: Советское радио, 1972. – 288с.
Методы теории чувствительности в автоматическом управлении/Под ред. Е.Н.Розенвассера и Р.М. Юсупова. – Л.: Энергия, 1971.
Микишев Г.М., Рабинович Б.И. Динамика тонкостенных конструкций с отсеками, содержащими жидкость. – М.: Машиностроение, 1971. – 564с.
Наур (Naur P. (Ed.)). Revised report on the algorithmic language ALGOL 60, CACM, 6 (Jan. 1963), 1-17. (Русский перевод: Алгоритмический язык АЛГОЛ-60, М., "Мир", 1965.).
Нейлор Т. Машинные имитационные эксперименты с моделями экономических систем./Пер. с англ. Под ред. А.А.Петрова, с предисл. Н.Н.Моисеева. – М.: Мир, 1975. – 502с.
Пешель М. Моделирование сигналов и систем. Пер. с англ./Под ред. Я.П.Хургина. – М.: Мир, 1981. – 302с.
Рихтер Дж. Windows для профессионалов: Программирование для Windows 95 и Windows NT 4 на базе Win32 API/Пер. с англ. - М.: Издательский отдел "Русская Редакция" ТОО "Channel Trading Ltd.", 1997. – 712 с.: ил.
Роджерсон Д. Основы COM/Пер. с англ. – М.: Издательский отдел "Русская Редакция" ТОО "Chanel Trading Ltd.", 1997. – 376 с.: ил.
Розенвассер Е.Н., Юсупов Р.М. Чувствительность систем управления. – М.: Наука, 1981.
Самарский А.А. Теория разностных схем./Учебное пособие. Главная редакция физико-математической литературы. – М.: Наука, 1977. – 656с.
Ту Ю. Современная теория управления./Пер. с англ. Я.Н.Гибадулина. Под ред. В.В.Солодовникова. – М.: Машиностроение, 1971. – 472с.
Холл Дж., Уатт Дж. Современные численные методы решения обыкновенных дифференциальных уравнений/Ред. Дж.Холл и Дж.Уатт:Пер. с англ. – М.: Мир, 1979.
Хорн Р., Джонсон Ч. Матричный анализ/Пер. с англ. – М.: Мир, 1989. – 655 с.
Шауцукова Л.З. Информатика./Учебник для 10-11 классов. – М.: Просвещение, 2000.
Эйкхоф П. Основы идентификации систем управления. Оценивание параметров и состояний/ Пер. с англ. В.А.Лотоцкого, А.С.Манделя/Под ред. Н.С.Райбмана. – М.: Мир, 1975. – 685с.

Вопросы и цели