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


Рис. 1

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

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

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

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

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

К большому сожалению разработчики моделирующих программ при создании своих продуктов не придерживаются современных технологий модуляризации (COM, CORBA) и предпочитают все делать самостоятельно. Их консерватизм в этом отношении создает потенциально неустойчивую ситуацию на рынке. Все представленные на рис. 1 модули могут быть не просто автономными, а уже традиционно считаются независимыми программными продуктами. Ирония в том, что математическое ядро – это наиболее простой и легкий в создании модуль. Совершенно очевидно, что создание полноценного редактора векторной графики подобного Visio или CorelDraw или же движка реляционной базы данных – это задача не для фирмы со штатом из 3..10 человек. Именно усилия, потраченные на решение этих второстепенных задач, разорили далеко не одну компанию, а проигрывают от этого пользователи.

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

Рассмотрим вариант перспективного модульного состава моделирующей программы (см. рис. 2). Даже беглая оценка списочного состава модулей выдает владельца используемых программных технологий – корпорацию Microsoft. Далее мы лишь добавим парочку скриптов и COM-серверов, наиболее важным из которых является математическое ядро.

Итак, в качестве графического интерфейса из двух кандидатов был выбран пакет векторной графики Visio, который чуть более популярен у инженеров, чем у художников. Для управления текстовым хранилищем модели с XML-разметкой был выбран не большой, бесплатно распространяемый, имеющий качественную документацию, и присутствующий на каждой машине с ОС Windows движок реляционной базы данных – COM-сервер (файл msxml*.dll). Выбор последнего вспомогательного компонента – сервера визуализации (объекта MSGraph.Chart программы Excel) не оптимален, не перспективен и определен лишь фактом его широкого распространения на машинах читателей этой статьи. Безусловно, здесь более подойдет инструментарий визуализации практически любой SCADA-системы, а лучше – библиотеки "Mearsurement Studio" for Visual Basic and Visual C++ фирмы National Instruments [9].


Рис. 2