С помощью каких средств делают имитационные модели?
 
Я не ставлю здесь задачи сделать еще один обзор программных продуктов, применяемых сегодня в мире для разработки имитационных моделей, хотя сам я читаю такие обзоры с большим интересом. Много полезной информации о свойствах современных систем моделирования можно найти в статье Наталии Лычкиной (www.gpss.ru) или в статье автора J. J. Swain, на которую г-жа Лычкина ссылается. Также и на Winter Simulation Conference существует традиция публиковать подробный обзор коммерческих продуктов для имитационного моделирования. Надо, правда, заметить, что статистические данные о применении различных продуктов никогда не могут быть точными, так как „на местах“, то есть там, где делаются модели, не существует никакой „строгой отчетности“ о применяемых средствах. Кроме того, имеют место существенные отклонения от „средней статистики“, которые определяются традициями и тенденциями, характерными для отдельных стран и регионов. Но, несмотря на это, наиболее часто публикуемый список „первой десятки“ языков и пакетов, применяемых для моделирования производственных и логистических систем, можно считать вполне достоверным. Из языков моделирования в этот список включается, как правило, только GPSS (в виде продукта GPSS/H), но иногда еще и SIMULA. Оба языка, прежде всего, „вросли“ в учебные процессы некоторых университетов и оба они являются „родоначальниками“: GPSS – чрезвычайно простой, ориентированной на потоки транзактов философии моделирования, а SIMULA – непростой, но очень „многообещающей“ программисту объектно-ориентированной философии. Очень интересным и современным является язык SLX для создания „быстрых моделей“, который, правда, нынешнее поколение „ленивых программистов“ дружно игнорирует. Из пакетов, только в алфавитном порядке, я бы отметил Arena, AutoMod, Extend, ProModel, QUEST, SIMFACTORY II.5, SIMPLE++ (eM-Plant), Taylor ED и WITNESS.

Оценку важнейших „потребительских качеств“ пакета для имитационного моделирования можно получить, ответив на вопросы:
  1. Как поддерживается (облегчается и ускоряется) работа программиста на этапах создания и отладки модели?
  2. Каким образом программист сможет продемонстрировать „представителю заказчика“ работающую модель и убедить его в ее адекватности?
  3. Позволит ли быстродействие симулятора проводить такие эксперименты с моделями, для которых эти модели и создаются?
  4. Возникнут ли проблемы, если модель надо будет интегрировать в информационную систему заказчика в такой степени, как он того пожелает сегодня, а, может быть, и завтра?

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

Оценивая качество 1, пользователь должен понять, в какой степени в симуляторе реализованы способы построения модели, которые в тексте Наталии Лычкиной названы как „путем программирования“ и „в идеографическом режиме“. Первый способ предполагает написание текстов программ на „встроенном“ языке симулятора, а второй позволяет первоначально создавать модель в виде 2D- или 3D-структуры из заранее подготовленных графических компонентов, работая в режиме Drag&Drop. Именно второй способ очень эффективно поддерживается в большинстве современных симуляторов, так как именно он делает симулятор привлекательным продуктом и создает иллюзию того, что „моделирование – это очень просто“. Примитивная модель „работает“ уже через несколько секунд после начала работы над ней (иногда даже не нужно изменять численные значения параметров компонентов, которые предлагаются „по умолчанию“) и демонстрирует при этом 2D- или 3D-анимацию. Этот режим очень удобен и для профессионального симуляциониста, так как позволяет ему быстро создавать „скелет“ модели. Однако „нормальной“ считается ситуация, когда после 10 минут манипуляции „мышкой“ программист будет 10 часов писать и отлаживать тексты программ, которые придадут модели все желаемые им свойства. „Хорошим“ можно считать симулятор, который является, прежде всего, объектно-ориентированным и позволяет программисту легко создавать любые адекватные решаемой им задаче классы статических и динамических объектов. Попробуйте на GPSS реализовать обычную иерархическую структуру груза, которая, например, позволяет узнать, какой цвет имеет одна из трикотажных маек, которая в настоящий момент „едет“ в железнодорожном вагоне! Например, на „встроенном“ языке симулятора eM-Plant такое обращение к атрибуту динамического компонента будет иметь вполне „естественный“ вид:

poezd(25).vagon(3).konteiner(5).poddon(1).korobka(33).izdelie(4).cvet

Качества симулятора 2 - 4 представляются вполне понятными и не требуют, на мой взгляд, развернутого комментария. В пункте 2 имеются в виду те возможности, которые симулятор предоставляет, прежде всего, для создания анимации. Часто 2D-анимация создается автоматически уже при составлении структуры модели, но остается весьма примитивной, например, без демонстрации непрерывного движения динамических компонентов. Для ее улучшения или „перевода“ в 3D-анимацию требуются некоторые дополнительные усилия со стороны программиста, которые и надо оценивать при выборе симулятора. Вопрос о быстродействии модели (пункт 3) иногда является просто решающим. Если мне известно, что один день работы исследуемой системы может быть промоделирован за 1 минуту машинного времени, я смогу сделать прикидочные расчеты и сообщить заказчику, что для реализации представленного им плана анализа вариантов организации его системы путем прямого перебора понадобится около 500 часов машинного времени. Что будем делать? Уменьшать „амбиции“, кодировать модель на Pascal или покупать (арендовать) „суперкомпьютер“? Вопросы интеграции моделей (пункт 4), часто включающие в себя и организацию интерфейса пользователя, частично обсуждались уже в предыдущих разделах данного текста.

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

 
назад

вперед