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

Интерфейс COM-сервера
Совокупность методов, свойств, перечислений, событий, которые позволяют обращаться к программному модулю, используя упрощенные языки программирования (Visual Basic, Java Script, C#, и пр.). Главное требование к интерфейсу COM-сервера — быть простым — как для понимания, так и в использовании, что бы задача разделения труда между программистами не вызывала затруднений.

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

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


Рис. 1

Чертеж является интеграцией блок-схемы со схемой физической2 принципиальной, т.е. своеобразным гибридом Simulink'а и Multisim'а. Задачу построения модели решает алгоритм, интерпретирующий чертеж и конфигурирующий математическое ядро посредствам соответствующего интерфейса. Листинг 1 демонстрирует перечни методов в версиях интерфейсов, которые мы рассмотрим.

Листинг 1

ISimKernel_v1.createBlock(...);
ISimKernel_v1.createWire(...);
ISimKernel_v1.setBlkParam(...);

ISimKernel_v2.createBlock(...);
ISimKernel_v2.createWire(...);
ISimKernel_v2.setBlkParam(...);

ISimKernel_v3.createRLC(...);
ISimKernel_v3.createBlock(...);
ISimKernel_v3.createWire(...);
ISimKernel_v3.setBlkParam(...);

ISimKernel_v4.createBlock(...);
ISimKernel_v4.createWire(...);
ISimKernel_v4.setBlkParam(...);

Примечание: аргументы методов
интерфейсов разных версий одинаковые 

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

Бросается в глаза совпадение методов. Дело в том, что интерфейс COM-сервера определяет не только имена методов, списки аргументов, ..., но и порядок вызова методов...

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


Рис. 2

Листинг 2

// Сканируем чертеж, обнаруживаем математические блоки, индексируем их,
// и создаем посредствам интерфейса соответствующие объекты (экземпляры
// исполняемого кода) в адресном пространстве математического ядра:
ISimKernel_v1.createBlock(703,0,1,2); // ID: 1; создали генератор нарастающего сигнала
ISimKernel_v1.createBlock(113,1,1,0); // ID: 2; создали синусоидальный преобразователь
ISimKernel_v1.createBlock(805,2,0,4); // ID: 3; создали осциллограф
// Расшифровка аргументов метода createBlock: генератор нарастающего сигнала имеет
// идентификатор класса (функции) в библиотеке математического ядра 703; у него,
// согласно чертежу: входов - 0, выходов - 1 и параметров - 2.

// Сканируем чертеж, обнаруживаем направленные линии связи между математическими
// блоками, и настраиваем передачу аргументов между соответствующими объектами
// (экземплярами исполняемого кода) в адресном пространстве математического ядра:
ISimKernel_v1.createWire(1,1,1,2); // связь между блоками с идентификаторами ID: 1 и 2
ISimKernel_v1.createWire(2,1,1,3); // связь между блоками с идентификаторами ID: 2 и 3
// Расшифровка аргументов метода createWire:
// первый и последний — идентификаторы блоков (генератора сигнала и приёмника);
// второй аргумент — номер выхода генератора; третий аргумент — номер входа приемника.

// Сканируем чертеж, обнаруживаем математические блоки, и, используя их идентификаторы,
// посредствам интерфейса, предаем предустановленные пользователем параметры,
// соответствующим объектам (экземплярам исполняемого кода) в адресном пространстве
// математического ядра:
ISimKernel_v1.setBlkParam(1,1,0);    // 1-ый параметр блока с идентификатором ID: 1
ISimKernel_v1.setBlkParam(1,2,12.6); // 2-ой параметр блока с идентификатором ID: 1
ISimKernel_v1.setBlkParam(3,1,1);    // 1-ый параметр блока с идентификатором ID: 3
ISimKernel_v1.setBlkParam(3,2,4);    // 2-ой параметр блока с идентификатором ID: 3
ISimKernel_v1.setBlkParam(3,3,-800); // 3-ий параметр блока с идентификатором ID: 3
ISimKernel_v1.setBlkParam(3,4,1);    // 4-ый параметр блока с идентификатором ID: 3
// Конец конфигурирующего скрипта. Направленный граф полностью интерпретирован.

Архитектура математических ядер такова, что выделение памяти под экземпляр исполняемого кода математической функции выполняется одновременно с выделением памяти под соответствующие: возвращаемые значения, параметры и указатели на аргументы. Очевиден тот факт, что в случае, если в адресном пространстве ядра, посредствам метода createBlock, не был предварительно создан экземпляр исполняемого кода математической функции, то вызов соответствующих методов createWire и setBlkParam не имеет смысла. Эта особенность является отличительной для упрощенного интерфейса первой версии (ISimKernel_v1).

Зависимость функционирования интерфейса конфигурации от порядка вызова методов не приветствуется. От нее можно избавиться. Для этого реализация методов createBlock, createWire и setBlkParam должна предполагать лишь передачу в адресное пространство математического ядра конфигурирующей информации, а сама конфигурация должна выполняться непосредственно в момент поступления управляющей команды на запуск симуляции. В результате, математическое ядро может само упорядочить последовательность реальных процедур конфигурации. Именно в этом заключено отличие интерфейса второй версии (ISimKernel_v2), от первой.

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

Итак, графическое представление гибридно-графовой модели может быть полностью интерпретировано и преобразовано в конфигурирующий скрипт, но для этого нужна третья версия интерфейса ISimKernel_v3, наследующая вторую и имеющая дополнительный метод createRLC. Рисунок и листинг поясняют детали процедуры. Первая часть скрипта повторяет листинг 2.


Рис. 3

Листинг 3

// Часть конфигурирующего скрипта, сгенерированного с направленного графа:
ISimKernel_v3.createBlock(703,0,1,2); // ID: 1
ISimKernel_v3.createBlock(113,1,1,0); // ID: 2
ISimKernel_v3.createBlock(805,2,0,4); // ID: 3

ISimKernel_v3.createWire(1,1,1,2);
ISimKernel_v3.createWire(2,1,1,3);

ISimKernel_v3.setBlkParam(1,1,0);
ISimKernel_v3.setBlkParam(1,2,12.6);
ISimKernel_v3.setBlkParam(3,1,1);
ISimKernel_v3.setBlkParam(3,2,4);
ISimKernel_v3.setBlkParam(3,3,-800);
ISimKernel_v3.setBlkParam(3,4,1);

// Часть конфигурирующего скрипта, сгенерированного с ненаправленного графа:
ISimKernel_v3.createRLC(1,2,id_E);        // ID: 4
ISimKernel_v3.createRLC(1,2,id_R,5.2e+1); // ID: 5
ISimKernel_v3.createRLC(1,2,id_L,0.1e-2); // ID: 6
// Расшифровка аргументов метода createRLC:
// первый и второй — идентификаторы узлов, между которыми включен RLC-элемент;
// третий — идентификатор субмодели: или R или L или C или E или J-элемента;
// необязательный четвертый аргумент — параметр RLC-элемента.

ISimKernel_v3.createWire(2,1,1,4);
ISimKernel_v3.createWire(6,1,2,3);
// Конец конфигурирующего скрипта. Гибридный граф полностью интерпретирован.

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

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


Рис. 4

Листинг 4

// Часть конфигурирующего скрипта, сгенерированного с направленного графа:
ISimKernel_v3.createBlock(703,0,1,2); // ID: 1
ISimKernel_v3.createBlock(113,1,1,0); // ID: 2
ISimKernel_v3.createBlock(805,2,0,4); // ID: 3

ISimKernel_v4.createWire(1,1,1,2);
ISimKernel_v4.createWire(2,1,1,3);

ISimKernel_v4.setBlkParam(1,1,0);
ISimKernel_v4.setBlkParam(1,2,12.6);
ISimKernel_v4.setBlkParam(3,1,1);
ISimKernel_v4.setBlkParam(3,2,4);
ISimKernel_v4.setBlkParam(3,3,-800);
ISimKernel_v4.setBlkParam(3,4,1);

// Часть конфигурирующего скрипта, сгенерированного с ненаправленного графа:
ISimKernel_v4.createBlock(id_E,1,2,1);    // ID: 4
ISimKernel_v4.createBlock(id_R,0,2,1);    // ID: 5
ISimKernel_v4.createBlock(id_L,0,4,1);    // ID: 6
ISimKernel_v4.createBlock(id_Node,3,0,0); // ID: 7
ISimKernel_v4.createBlock(id_Node,3,0,0); // ID: 8

ISimKernel_v4.createWire(4,1,1,7);
ISimKernel_v4.createWire(4,2,1,8);
ISimKernel_v4.createWire(5,1,2,7);
ISimKernel_v4.createWire(5,2,2,8);
ISimKernel_v4.createWire(6,1,3,7);
ISimKernel_v4.createWire(6,2,3,8);

ISimKernel_v4.setBlkParam(5,1,5.2e+1);
ISimKernel_v4.setBlkParam(6,1,0.1e-2);

// Связи между направленным и ненаправленным графами:
ISimKernel_v4.createWire(2,1,1,4);
ISimKernel_v4.createWire(6,3,2,3);
// Конец конфигурирующего скрипта. Гибридный граф полностью интерпретирован.

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


1) Утверждение является предположением. Его подтверждают многочисленные косвенные признаки и документация некоторых моделирующих программ.

2) Используется термин "схема физическая принципиальная" вместо "схема электрическая принципиальная" с целью распространения излагаемого материала на другие энергетические домены.

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

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

29.01.2006