Портал GPSS.RU

Юрий Толуев

tolujew@iff.fhg.de


Записки симуляциониста, любящего и уважающего GPSS


 

Вместо введения

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

Работая над данным текстом я не ставлю перед собой задачи сделать подробный анализ современного состояния всего „мира имитационного моделирования“, а лишь пытаюсь выразить словами то, что сегодня видит специалист по моделированию „классических процессов с дискретными событиями“, который взрослел вместе с соответствующими методами и инструментами, применяемыми в этой области имитационного моделирования. Моя „история жизни в моделировании“ тем и характерна, что я делал мои первые модели на Fortran и GPSS, а потом, по мере необходимости, писал модели на Basic и Pascal. Попутно мне пришлось освоить и несколько „блочно-ориентированных“ пакетов моделирования. Язык Basic в форме VBA, также вместе с таблицами MS Excel, я иногда применяю и сейчас. Это сегодня – почти идеальный метод создания моделей для пользователей, которые модели хотят иметь, а симулятор покупать не намерены. Кроме того, иногда пользователи, а особенно на производстве, вообще не хотят знакомиться с симулятором, даже если они его уже и купили: у них на это просто нет ни людей, ни времени, ни желания „опять учиться“. Они хотят оставаться в среде „горячо любимого“ MS Excel и выполнять в этой среде все три фазы работы с готовыми моделями: подготовка данных, прогон модели, анализ и презентация результатов. В последнем проекте, который я сделал для Volkswagen, был применен очень современный симулятор eM-Plant, лицензию на который Volkswagen купил уже нескольких лет назад. Симулятор имеет очень развитую интерфейсную часть: маски для диалогов, Excel-подобные таблицы, диаграммы и плоттеры, автоматическую 2D-анимацию и сравнительно легко создаваемую 3D-анимацию. И, несмотря на все это, заказчик объявил, что желает работать с моделями (и симулятором заодно) как с „черным ящиком“. То есть никакую „имитацию и анимацию“ он вообще на экране видеть не хочет, а хочет только иметь возможность проводить имитационные эксперименты, работая в среде MS Excel. Вот так и пришлось „спрятать“ все окна симулятора на время, пока проводится прогон модели: одно только окно с временем моделирования остается на экране, чтобы пользователь мог видеть „сколько еще осталось ждать“...
 

Что такое „интегрированные модели” и как их сегодня делают?

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

Так в чем же заключается основная особенность моделей процессов с дискретными событиями, которые заказывают и создают сегодня? Если одним словом, то – в их „интеграции“, т.е. тесном взаимодействии с другими компонентами той информационной и/или организационной системы, в рамках которой должны применяться модели. „Голые“, т.е. абсолютно автономные модели создаются довольно редко, даже в случаях, когда проводится „имитационное исследование“ (simulation study), при котором предусматривается передача заказчику только результатов имитационных экспериментов, а не самой модели.

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

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

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

c) заказчику передается „все в полном комплекте“, т.е. „имитационное исследование“, „готовая модель“, симулятор и вся „техника и технология“ создания определенного класса моделей; составной частью имитационного проекта является обучение заказчика, в результате которого он должен научиться работать с симулятором и создавать модели хотя бы для определенного класса систем (иногда - на базе специально созданной для этих целей библиотеки модулей).
Вполне понятно, что трудоемкость и стоимость проекта растет от варианта a к варианту c. Вариант b радикально отличается от варианта a уже потому, что появляется необходимость создавать программы, обеспечивающие слабо подготовленному пользователю возможность уверенно и надежно работать даже со сравнительно сложными моделями. Другими словами, решается задача „защиты от дурака“. В частности, вся диагностика ошибок моделирования должна быть вынесена за пределы симулятора. Модель в этом случае можно считать „плохой“ уже тогда, когда прогон может быть прерван самим симулятором, и сообщение об ошибке поступит именно от него. „Хорошая“ модель должна тщательно проверять создаваемые пользователем варианты исходных данных и начинать моделирование только при условии положительных результатов такой проверки. В крайнем случае, ошибка моделирования должна быть обработана самой моделью, а пользователь должен получить исчерпывающую информацию о том, как он может эту ошибку устранить. Часто проблема надежного ввода исходных данных решается с помощью Excel-таблиц и соответствующих VBA-программ (необходимо предусмотреть всякого рода подсказки, проверки и блокировки).

При варианте c исполнитель фактически создает себе конкурента. Если результаты проекта оказываются „просто успешными“, то данный заказчик в будущем уже не будет настоящим клиентом исполнителя, а будет решать свои задачи самостоятельно. Если результаты будут „особенно успешными“, у бывшего заказчика может появиться собственная команда симуляционистов, которая выйдет на соответствующий рынок в виде настоящего конкурента.
Вернемся к вопросу об „интеграции“ модели. Даже при варианте a возникает необходимость получить от заказчика исходные данные в виде Excel-таблиц или файлов из соответствующих баз данных. Чаще всего передаются данные о потоках заказов, о производственных программах, о времени выполнения операций, а также всевозможные (иногда и не являющиеся полезными с точки зрения моделирования) данные о технических и людских ресурсах предприятия. Иногда очень подробно отображаются в модели графики рабочих смен: с точностью до минут конкретно для каждого дня недели, со всеми видами „пауз и перерывов“, с указанием точного состава персонала для каждой смены. Если предусматривается 2D-анимация, то, как правило, „план территории объекта” (layout) передается в виде файлов в формате соответствующей CAD-системы. Еще более сложными по структуре и объему становятся данные, если предусматривается создание 3D-анимации. Наряду с файлами из CAD-системы в этом случае в виде графических компонентов могут использоваться, например, комплексные VRML-модели.

При вариантах b и c „интеграция“ становится уже самой настоящей, т.е. реализуется в режиме on line на рабочем месте симуляциониста-аналитика у заказчика. Производится автоматически обновление соответствующих файлов, если в ходе работы предприятия (или в ходе выполнения проектных работ) появляются изменения в данных, используемых моделями в качестве исходных. Иногда вообще не предусматривается создание промежуточных файлов с исходными данными, а обеспечивается возможность прямого обращения модели к соответствующим базам данных.
Задача „интеграции“ может оказаться очень сложной и неудобной для разработчика модели, если у заказчика модель должна будет взаимодействовать с информационной системой или целой системой управления производством, опыта работы с которой у разработчика просто нет (например, с системой SAP R/3 или ее специальным модулем APO - Advanced Planner & Optimizer). В таких случаях, как правило, с заказчиком в самом начале проекта по моделированию надо договариваться о соответствующей поддержке.

В некоторых отраслях промышленности заказчики ушли, по крайней мере, концептуально, по пути „интеграции моделей“ чрезвычайно далеко. В Германии очень „модным“ является термин Digitale Fabrik (оцифрованная фабрика, оцифрованное производство). В автомобильной промышленности принято решение, что к 2005 году вся техническая документация будет приниматься к рассмотрению только при условии, если она будет соответствовать концепции Digitale Fabrik. Главенствующая роль в этой концепции принадлежит 3D-моделям для всех элементов производственного процесса, которые приходят на смену обычным CAD-чертежам. В виде 3D-моделей должны изображаться как все „средства производства“ (оборудование и рабочие места, отдельные цеха и предприятие в целом), так и вся производимая продукция, начиная от „общего вида“ и заканчивая подробной „деталировкой“. Специалисты предприятия должны, в частности, получить возможность наблюдать 3D-анимацию, которая автоматически создается на основании сценария типа „показать, как на рабочем месте A рабочий с категорией B выполняет операцию типа C над узлом D, который является компонентом изделия E“. Ясно также, что демонстрация любых динамических процессов является возможной только под управлением соответствующих имитационных моделей. Надо четко представлять себе, что наряду с традиционными для имитационного моделирования моделями процессов с дискретными событиями существуют кинематические 3D-модели оборудования и рабочих мест, эргономические 3D-модели, модели типа Digital MockUp и др. Современный заказчик в передовой отрасли промышленности хочет получить „все сразу и в комплекте“. Он не очень желает вообще знать, что раньше понималось под термином „имитационное моделирование“. Он ориентируется сегодня на то, что ему предлагают лучшие из Ваших конкурентов-симуляционистов, так как боится проиграть в борьбе с собственными конкурентами.
Особые требования по „интеграции“ возникают, когда заказчик требует, чтобы была обеспечена возможность работы с моделями через Internet или Intranet. Полный диалог с симулятором в таких случаях обеспечить, как правило, не удается, если, конечно, симулятор не был сразу спроектирован как web-oriented. Но с помощью вспомогательных средств в виде Java Applets или ActiveX часто можно дать пользователю возможность, работая с обычным „браузером“, подготавливать, реализовывать и анализировать имитационные эксперименты.

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

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

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

 

Кто, каким образом и зачем заказывает имитационные модели?

„Идеальной“ представляется ситуация, когда некий „очень грамотный заказчик“ вдруг объявляет „всему миру симуляционистов“, что он желает выполнить работы по моделированию по одной из схем, которые выше были обозначены как a, b и c. „Грамотным“ заказчик является тогда, когда он достаточно адекватно представляет себе все основные аспекты будущей работы:
  • конечные цели проведения работ по моделированию и/или использования созданных моделей;
  • круг задач, которые достаточно корректно могут быть решены путем применения соответствующих методов имитационного моделирования;
  • состав и объем исходных данных, которые надо будет предоставить разработчикам моделей;
  • специальные требования по „интеграции“ моделей, по формам презентации результатов моделирования (в том числе и по анимации) и т.п.;
  • концептуальные и практические возможности применения некоторых конкретных симуляторов;
  • трудоемкость планируемых работ по моделированию, стоимость человеко-дня разработчика моделей и - при наличии необходимости приобретать симулятор - цену, которую заказчику надо будет за него заплатить.

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

„Грамотный“ заказчик часто оказывается достаточно щедрым: он хорошо представляет себе всю сложность предстоящей работы, но при этом также хорошо знает, какую пользу от этой работы получит он сам, и поэтому основными критериями для него становятся сроки выполнения проекта и его качество, а не стоимость. Из-за этих критериев „грамотный“ заказчик часто одновременно является очень „жестким“: он безжалостно „откидывает“ фирму-симуляциониста, если она не может уложиться в предложенные заказчиком рамки по срокам и содержанию проекта. У меня где-то еще хранятся три образца заявок на имитационное моделирование, которые один из заводов Audi летом 1999 года разослал потенциальным исполнителям. Я был и свидетелем того, как группа симуляционистов в Техническом университете г. Хемнитца после подробного обсуждения заявки пришла к заключению, что не уложится в предложенный срок (3 месяца) и написала вежливый отказ. Задание состояло в том, чтобы с помощью моделирования проверить, сможет ли система внутризаводского транспорта обеспечить бесперебойную работу главного сборочного конвейера, доставляя к нему узлы и детали с внутренних складов предприятия. А моделировать со всеми подробностями надо было около 420 рабочих мест...
Таким образом, с „грамотным“ заказчиком легче всего работать в смысле менеджмента, финансов и прочей „дипломатии“. У него, как правило, - ясная и открытая стратегия. Его не надо много „просвещать“ или, тем более, „вешать ему лапшу на уши“, а можно сразу говорить очень предметно обо всех сторонах проекта. В случае успешного завершения проекта у обоих его участников появляется самое настоящее удовлетворение, как правило, переходящее потом в долгосрочное сотрудничество.

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

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

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

Эпитеты типа „предметно и честно“ или „моральное право“ применяю в области имитационного моделирования не только я. Мне известно о том, что в немецкоязычном обществе симуляционистов ASIM (Arbeitsgemeinschaft Simulation - http://www.asim-gi.org) уже делаются попытки разработать „Моральный кодекс строителя моделей“. Все ведь понимают, что имитационные модели радикально отличаются от любого другого software, для которого можно написать довольно точную спецификацию и который после завершения разработки можно будет „более-менее проверить“. Полноценность реализации очень многих свойств модели, а особенно большой и/или сложной модели, полностью зависит от квалификации и честности симуляциониста, и она чаще всего не может быть проверена досконально. Элементом „нечестности“ является уже даже неадекватная оценка симуляционистом собственной квалификации, когда он, например, берется за решение серьезной задачи статистического моделирования, имея очень смутное представление о понятии „доверительный интервал“. Ну что можно поделать, если статистика не нравится человеку уже со студенческих лет?!

Несколько слов по поводу того, „зачем“ заказывают имитационные модели. Конечно, остаются в силе все высказывания о функциях моделей, которые изложены в известной книге Роберта Шеннона (Имитационное моделирование систем - искусство и наука. – „Мир“, Москва, 1978, стр. 16-19). Это значит, что далеко не всегда модель необходима только как „источник чисел“, на базе которых принимаются решения по поводу конкретных прикладных проблем. Более того, надо пытаться в каждом случае ведения переговоров с заказчиком выяснить (а потом и выразить словами, но не всегда - в тексте договора) истинные мотивы, которые подвигли его на развертывание работ по моделированию, в то время как собственные мотивы исполнителя ему самому, как правило, известны. Ниже я предлагаю список возможных вариантов „мотивации“ работ по моделированию со стороны заказчика, который, конечно, не претендует на какую-то полноту:

  • заказчик заведомо доверяет „числам“, которые он получит от модели после ее верификации и валидации, и верит в то, что с помощью модели можно будет ответить на уже поставленные им конкретные вопросы: оценить работоспособность и/или показатели функционирования проектируемой системы, сравнить конкурирующие варианты проекта и т.п.;
  • заказчик совсем не собирается доверять тем „числам“, которые он получит от модели; он заведомо готов скрыть, подправить в свою пользу или вовсе проигнорировать результаты моделирования, так как на самом деле уже принял все необходимые проектные решения путем проведения обычных проектных расчетов или просто на основании конъюнктурных соображений; имитационное моделирование нужно ему лишь как „явление“, сопровождающее его проектирование и/или принятие решений и свидетельствующее о высоком уровне проводимых им работ (иногда - и с целью повышения своей конкурентоспособности);
  • об использовании „чисел“ в проекте речь не идет вообще; модель нужна лишь в форме „анимационного фильма“, который выполняет роль рекламного средства; заказчик с помощью такой модели может рекламировать „уровень и стиль“ своей проектной работы (если он - проектировщик) или „уровень и стиль“ управления своим объектом „на базе моделей“ (если он – предприятие); „красивая модель“ на большом экране должна работать, прежде всего, в кабинете начальника или, например, на выставке;
  • работы по моделированию нужны заказчику для „воспитания“ собственных сотрудников или оказания психологического давления на других исполнителей; он может сказать работнику, указывая на продукт, полученный от симуляциониста: „Вот так надо сегодня работать! Не можешь - уволю...“; аналогичная ситуация - в отношениях с уже имеющимся или потенциальным исполнителем: „Если ТАК не можешь работать, снижай цену проекта!“;
  • заказчик желает по-настоящему проверить как сам метод имитационного моделирования, так и исполнителя, который вызвался применить этот метод „с пользой для дела заказчика“; заказчик предлагает решить задачу с помощью моделирования, будучи уверенным в том, что „правильное“ решение этой задачи ему уже известно; далеко не всегда заказчик желает успеха симуляционисту, а, движимый собственным честолюбием, хочет показать последнему, что тот совсем „не умнее“ его, хотя и владеет методом, который ему самому недоступен (весьма интересным образом может развиться ситуация, если решение, найденное симуляционистом, оказывается „более правильным“); в случае общего положительного настроя заказчика после успешной проверки может начаться и настоящее сотрудничество.

Мотивы исполнителя оказываются на этом фоне довольно банальными: в конечном итоге он хочет просто „заработать деньги“. Конечно, иногда он хочет при этом продемонстрировать свой профессиональный уровень и/или преимущества своего симулятора. И общественное признание в академическом мире ему не повредит. Но все это – „лирика“, если речь идет о нормальных рыночных отношениях. Самое важное место на визитной карточке симуляциониста (в том числе, и на интернетовском сайте) – список „солидных“ фирм, которые являются его клиентами, а еще лучше – постоянными клиентами.

 

Кто и каким образом делает имитационные модели?

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

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

К сожалению, надо отметить, что студенты-информатики, которые активно и с охотой изучают программирование, именно математику весьма успешно умудряются игнорировать. Конкретные разделы математики знают значительно лучше студенты традиционных инженерных специальностей: электрики, связисты, механики. Если такой студент хотя бы „не боится“ программирования и уже знает сам компьютер, из него значительно легче будет сделать симуляциониста, чем из программиста. Более того, если задачи моделирования имеют отношение к его основной профессиональной области, то „студент-инженер“ проявит значительно больше самостоятельности, прежде всего, на этапе разработки концептуальной модели. Хорошему инженеру легче освоить программирование в объеме, необходимом для моделирования, чем программисту „вырасти“ до инженера. И желание моделировать легче вызвать у инженера, так как он может увидеть в этом виде программирования эффективный способ решения хорошо знакомых ему задач.

Мое субъективное представление состоит в том, что около 20% студентов инженерных специальностей способны „дойти“ до самостоятельного программирования, а примерно половина из них может активно применять категории моделирования процессов с дискретными событиями, т.е. самостоятельно создавать имитационные модели не только „из кубиков“, но и путем написания собственных текстов, например, на GPSS. Результат весьма неплохой: каждый десятый – потенциальный симуляционист! Я не случайно начал говорить сразу о „студенческом народе“, думая о том, кто сегодня способен создавать имитационные модели. Симуляциониста сегодня легче „воспитать с пеленок“, чем найти „готовенького“. Эта ситуация имеет место во всех странах, где в вузах преподаются общие основы имитационного моделирования. В странах, где соответствующие учебные предметы получили большое распространение, создаются хорошие предпосылки для систематического использования этого метода в соответствующих видах инженерной деятельности. Но и там профессиональных симуляционистов готовят лишь очень немногочисленные кафедры, на которых традиционно существуют соответствующие школы.

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

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

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

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

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

  • Law, A. M. and W. D. Kelton. Simulation Modeling and Analysis. Second Edition, New York: McGraw-Hill, 1991.
  • Banks, J., J. S. Carson, II and B. L. Nelson. Discrete-Event System Simulation. 2nd ed., Prentice Hall, Upper Saddle River, New Jersey, 1996.
  • Handbook of Simulation. Ed. J. Banks, New York: John Wiley & Sons, 1998.

Третья книга-справочник написана на основании работ, которые в разные годы и даже многократно публиковались в материалах Зимней конференции по имитационному моделированию (Winter Simulation Conference), которая в течение многих лет ежегодно проводится в декабре месяце в одном из городов США, причем регулярно – в Вашингтоне. Эта конференция признана как главный форум симуляционистов всего мира. В некоторые годы число участников конференции превышало тысячу человек. Конечно, симуляционист-эксперт должен „подпитывать“ себя знаниями о современных достижениях и тенденциях в области моделирования, хотя бы ежегодно знакомясь с материалами Зимней конференции.
Делеко не всегда модели создаются на основе отношений „заказчик-исполнитель“, т.е. как продукты, за которые кто-то сразу платит деньги. Однако, в каждой ситуации, когда создается модель, можно найти ответы на два вопроса: „Кто и зачем создает модель?“ и „Кто является арбитром, оценивающим свойства модели?“. Можно попытаться привести примеры типичных ситуаций, в которых создаются имитационные модели и которые не определяются непосредственным присутствием в этих ситуациях некого „заказчика“:

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

Остается только отметить, что в качестве „фирмы-симуляциониста“ на соответствующем рынке услуг может выступать:

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

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

 

С помощью каких средств делают имитационные модели?

Я не ставлю здесь задачи сделать еще один обзор программных продуктов, применяемых сегодня в мире для разработки имитационных моделей, хотя сам я читаю такие обзоры с большим интересом. Много полезной информации о свойствах современных систем моделирования можно найти в статье Наталии Лычкиной (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), часто включающие в себя и организацию интерфейса пользователя, частично обсуждались уже в предыдущих разделах данного текста.

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

 

О некоторых ценах и сроках

Говоря о ценах, я имею в виду цены на рынке симуляторов и цены, которые заказчики выплачивают фирмам-симуляционистам за разработку проектов. Начнем с симуляторов. Для симуляторов, ориентированных на „языки“, такие как GPSS, цена лежит в пределах от 3 до 6 тыс. USD. Для учебных заведений такие симуляторы предлагаются ценой от 500 USD. Известны также „студенческие версии“, которые предлагаются за 100 USD или даже бесплатно. Как правило, в них очень существенно ограничены размерности создаваемых моделей, но сохранены все основные функции симулятора.
Цены на пакеты имитационного моделирования лежат в пределах от 20 до 50 тыс. USD. При продаже множественных лицензий существует гибкая шкала цен. Бывает также, что предлагаются различные типы лицензий, отличающиеся ценой в несколько раз:
  • Development License
  • Application License
  • Runtime License
  • Simulation License
  • Educational (Academic) License
  • Student License

У „дорогих“ пакетов цена даже на Student License не опускается ниже 500 USD, а для учебных заведений цена лицензии лишь иногда опускается до 5 тыс. USD. Конечно, фирма-симуляционист должна ориентироваться сразу на приобретение нескольких лицензий типа Development License. Ограничение доступа к симулятору обеспечивается с помощью Security Key или Floating Licenses, обращение к которым происходит через Internet. Часто оказывается очень целесообразным приобрести вместе с „базовым симулятором“ дополнительные программы (интерфейсы, графику, оптимизацию и т.п.), а также специализированные библиотеки модулей для моделирования определенных типов систем (монтажных участков, автоматизированных складов, транспортных систем и т.п.). В этом случае цена покупки легко может подняться до 80 тыс. USD.

Цены на проведение работ есть смысл рассматривать совместно с соответствующими сроками. В Центральной Европе существует представление, что один человеко-день работы „приличной“ фирмы-симуляциониста или консалтинговой фирмы должен стоить заказчику около 800 USD. Тогда получается, что „средний“ проект, который продолжается 2 месяца (40 рабочих дней) и выполняется силами двух работников, будет стоить заказчику 64 тыс. USD. Конечно, стороны могут и „торговаться“, но цена на такой проект вряд ли опустится ниже 50 тыс. USD. Это совсем не значит, что симулятор окупится уже одним таким проектом: только на зарплату этим двум работникам фирма-симуляционист на Западе потратит за это время не менее 24 тыс. USD, конечно, с учетом налогов.

Следует различать такие виды сроков:

a) сроки разработки проектов, которые стараются диктовать „грамотные“ заказчики;

b) сроки разработки проектов, которые стараются предлагать фирмы-симуляционисты;

c) фактические сроки разработки проектов.

„Грамотные“ заказчики, действительно заинтересованные в результатах моделирования, редко предполагают, что проект по имитационному моделированию может продолжаться более трех месяцев. В принципе, у них есть основания так считать, так как на интеллектуальную часть даже сравнительно большого проекта, т.е. на уточнение постановки задачи и разработку концептуальной модели, симуляционист-эксперт тратит лишь несколько дней. А в дальнейшем темпы разработки проекта должны быть обеспечены за счет правильной организации работ, т.е. чисто „технологическими“ методами. Считается, что почти половина времени может быть потрачена на обеспечение моделей требуемыми исходными данными, а сами работы по программированию моделей занимают 25-30% от общего времени проекта. Иногда „жесткий“ заказчик просто организует „тендер“ с условиями: срок – 3 месяца и цена – не более 100 тыс. USD.

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

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

 

Вместо заключения

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

Одно из последних впечатлений из реальной жизни: на Промышленной ярмарке в Ганновере в апреле 2002 года один из больших центральных павильонов имел тематическое название „Логистика“. На стендах почти всех крупных фирм были установлены проекторы, которые на больших экранах показывали фильмы, рассказывающие о применении соответствующей техники и технологии. Я с радостью смотрел на эти „экспонаты“, так как почти все фильмы были красочными 3D-анимациями, созданными на базе имитационных моделей. Павильон „Логистика“ превратился для меня в павильон „Имитационное моделирование“!

Распечатано с портала GPSS.RU
(c) Юрий Толуев, 2002 г.