- •Основы моделирования систем
- •Введение в дисциплину "Основы моделирования систем"
- •Проблематика, задачи и цели моделирования
- •Технологии функционирования моделирующих программ
- •Обзор и классификация моделирующих программ
- •Решатели моделирующих программ
- •Понятие о структурном и мультидоменном физическом моделировании
- •Идея мультидоменного физического моделирования
- •Введение в технологию моделирования на основе направленных графов
- •Принцип поточного исполнения блок-схем (моделей)
- •Библиотеки блоков графических языков
- •Блоки обладающие эффектом памяти
- •Понятие о начальных условиях модели (Initial Condition)
- •Понятие о параметрах модели
- •Понятие о методах интегрирования
- •Выбор шага симуляции и метода интегрирования
- •Каскадные алгебраические петли
- •Каскодные алгебраические петли
- •Введение в технологию мультидоменного физического моделирования с применением ненаправленных графов
- •Принципы построения графа схемы физической принципиальной
- •Элементы ненаправленного графа
- •Пассивные элементы ненаправленного графа (потребители энергии)
- •Активные элементы ненаправленного графа (источники энергии)
- •Узлы ненаправленного графа
- •Рекомендации к использованию библиотеки элементов
- •Об альтернативном построении графа схемы физической принципиальной
- •Основы построения моделей на базе гибрида из направленных и ненаправленных графов при мультидоменном физическом моделировании
- •Связывание направленных и ненаправленных графов. Особенности условных графических обозначений пограничных элементов
- •Ситуации, требующие соблюдения условно-положительного направления тока энергетической материи для пассивных rlc-элементов
- •Понятие о датчике потенциала – w-элементе
- •Пример гибридно-графовой модели транзисторного усилителя с элементами инкапсуляции графов
- •Обзор методов анализа моделей, систем и сигналов
- •Идентификация моделей
- •Символьный анализ математического описания моделей
- •Частотный анализ моделей и систем
- •Литература
- •Обзор архитектурного построения программ математического моделирования динамических систем Введение
- •Модульная структура программ математического моделирования динамических систем
- •Архитектура математического ядра моделирующих программ с поточной моделью управления
- •Графический интерфейс программ математического моделирования динамических систем
- •Шлюз Visio2SimKernel
- •Xml хранилище модели
- •Литература
- •Что же с тоэ? или о структурном кризисе в методике преподавания блока дисциплин связанных с расчетом цепей преобразования энергий
- •Уровни сложности задач расчета цепей преобразования энергий
- •О том, как программы мультидоменного математического моделирования динамических систем "выкинули на помойку" учебники по теоретическим основам цепей
- •Сценарий изменения методики преподавания "Теоретических основ цепей" и обзор затруднений
Архитектура математического ядра моделирующих программ с поточной моделью управления
Какими бы разными ни были моделирующие программы, вариации архитектуры их математических ядер довольно жестко ограничены возможностями компиляторов языков высокого уровня. Очевидно, что математическое ядро должно поддерживать от 100 до нескольких тысяч математических функций. Безусловно, требуется формализация интерфейса настройки и управления математического ядра, поскольку справиться с таким громадным количеством функций, используя их ручной вызов, невозможно.
Возможности современных версий языка Си++ позволяют решить поставленную задачу следующим образом. Пишется полиморфный классCBlkTemplate с виртуальным методом Calc (см. табл. 1). Его наследуют классы, составляющие библиотеку математических функций. В частности, каждый потомок реализует метод Calc в виде уникальной математической функции. Уточним возможности, которые предоставляет подобная организация библиотеки.
Во первых, от каждого математического класса можно породить любое количество объектов. Это означает, что для обработки повторно встречающихся в модели математических функций будут использованы уникальные экземпляры объектов, каждый из которых будет иметь собственную область памяти для хранения возвращаемых значений Output[k]. В результате не будет наблюдаться "затирание" координат модели.
Во вторых, в силу действующих стандартов для компиляторов языка Си++, объекты порожденные от разных потомков полиморфного класса (CBlkTemplate) будут иметь реализации виртуальной таблицы функций (vtbl) одной размерности. Это означает, что их можно присвоить элементам одного массива MathBlock[i] (см. рис. 3). Что, в свою очередь, открывает возможности для создания автоматизированных процедур обслуживания объектов математического ядра. Так например, процедура исполнения шага симуляции модели в таких программах, как Jigrein, VisSim, Simulink, ПК «МВТУ» может иметь следующий вид:
Листинг 1
for (i=0; i < numBlock; i++) {
MathBlock[i]->Calc();
}
Подобных процедур не много, и, в случае реализации математического ядра в виде COM-сервера, они образуют его интерфейсы (см. табл. 2).
Уделим внимание деталям реализации математического ядра. В табл. 1 приведён список важнейших атрибутов полиморфного класса, которые наследуются всеми его потомками. К ним относятся: массив указателей на аргументы pInput[j], массив возвращаемых функцией результатовOutput[k] и массив параметров функции Param[n]. Размерность массивов задается значениями параметров конструкторов потомков, которые, в свою очередь, передаются им через интерфейс createBlock COM-сервера (см. табл. 2).
Таблица 1 |
Атрибуты полиморфного класса - общего предка всех математических классов |
CBlkTemplate.pInput[j] |
CBlkTemplate.Output[k] |
CBlkTemplate.Param[n] |
CBlkTemplate.Calc() = 0; // virtual |
CBlkTemplate. ... |
В графическом представлении, экземпляры математических объектов – это блоки на блок-схеме (см. нижний фрагмент рис. 3). Наличие у каждого математического объекта массива указателей на аргументы pInput[j] делает возможным (в графическом представлении) их соединение линиями связи в требуемом порядке. Эта операция осуществляется через интерфейс createWire COM-сервера (см. табл. 2). Её результатом является присвоение значения указателя на элемент массива Output[k] одного объекта элементу массива pInput[j] другого объекта (см. цепочку повторяющихся фрагментов на рис. 3). Таким образом, совокупность показанных программных решений делает возможным создание моделей систем из любого требуемого набора математических функций, между которыми возможна любая требуемая схема передачи аргументов.
Рис.
3
В целях ознакомления с интерфейсами математического ядра (COM-сервера) рассмотрим программу на VB, которая создает модель динамической системы и запускает процесс симуляции в пакетном режиме (для расшифровки параметров методов см. табл. 2).
Листинг 2
' Объявляем переменную, как математическое ядро
Private WithEvents Mdl As SimKernel
Private mySmplArr(100) As Double
' Создаём из COM-сервера объект - математическое ядро
Set Mdl = CreateObject("Klinachyov.SimKernel")
' Устанавливаем свойства симуляции модели
Mdl.setSimProp 0, 1, 0.01, 0
' Создаем блоки (математические объекты или функции)
Mdl.createBlock L702, 0, 1, 0 ' inpVector
Mdl.createBlock L101, 2, 1, 2 ' summingJunction
Mdl.createBlock L100, 1, 1, 1 ' gain
Mdl.createBlock L951, 1, 1, 1 ' 1/S
Mdl.createBlock L802, 1, 0, 0 ' outVector
Mdl.createBlock L800, 2, 0, 0 ' export
' Устанавливаем параметры блоков и начальные условия
Mdl.setBlkParam 2, 1, 1
Mdl.setBlkParam 2, 2, -1
Mdl.setBlkParam 3, 1, 4
Mdl.setBlkParam 4, 1, 0
' Создаем связи между блоками (схему передачи аргументов)
Mdl.createWire 1, 1, 1, 2
Mdl.createWire 2, 1, 1, 3
Mdl.createWire 3, 1, 1, 4
Mdl.createWire 4, 1, 2, 2
Mdl.createWire 2, 1, 1, 6
Mdl.createWire 4, 1, 2, 6
Mdl.createWire 4, 1, 1, 5
' Устанавливаем очередность исполнения блоков
Mdl.BildSimFlow
' Это не важно - задаем массив выборок для обработки моделью
For i = 0 To 99
mySmplArr(i) = Sin(i / 7)
Next
' Передаем массив в математическое ядро
Mdl.swapInputOutputSamples mySmplArr
' Запускаем процесс симуляции модели
Mdl.Simulation
' Считываем обработанный моделью массив
Mdl.swapInputOutputSamples mySmplArr
' Запускаем сервер визуализации результатов
' ...
Беглого взгляда на программу достаточно, дабы сделать вывод о том, что процесс создания модели унифицирован (для создания любого математического блока или же любой межблочной связи используется только один соответствующий метод (интерфейс)). Именно жесткая унификация интерфейсов делает возможным создание шлюзов между редакторами векторной графики и математическими ядрами.
Таблица 2 (SimKernel.dll) |
|
|
SimKernel.createBlock(IDLIB, numInp, numOut, numPrm) |
SimKernel.setBlkParam(idBlk, indexPrm, prmValue) |
SimKernel.createWire(O_idBlk, indexOut, indexInp, I_idBlk) |
SimKernel.BildSimFlow() |
SimKernel.SimStep() |
SimKernel.Simulation() |
SimKernel.ResetStates() |
SimKernel.SnapStates() |
SimKernel.swapInputOutputSamples(Array) |
|
SimKernel.ControlPoints.Item(i) |
|
SimKernel.UserBlocks.Item(i) |
UserBlock.onCalc(inpVector, outVector, prmVector) |
UserBlock.onFstStep(inpVector, outVector, prmVector) |
UserBlock.onEndStep(inpVector, outVector, prmVector) |
UserBlock.onPrmSet(prmVector) |
Завершая обзор математического ядра, отметим, что представленные архитектурные решения позволяют решать системы как чисто дифференциальных уравнений (т.е. ядро может быть явным решателем), так и системы алгебро-дифференциальных уравнений (т.е. ядро может быть неявным (итерационным) решателем). Архитектура ядра не препятствует созданию, ставших уже классическими для моделирующих программ, методов частотного анализа [1]. Пользователь может свободно замещать блоки обладающие эффектом памяти (1/S, 1/Z, e-dTs) собственными процедурами, и, в любой момент, может иметь доступ ко всем координатам модели getState.
