Что такое „интегрированные модели” и как их сегодня делают?
 
Говоря о „моделях процессов с дискретными событиями“ я буду иметь в виду „классические“ объекты моделирования, т.е. производственные, транспортные, складские и прочие „логистические“ системы. Конечно, при этом надо учитывать и тот факт, что в 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 часто можно дать пользователю возможность, работая с обычным „браузером“, подготавливать, реализовывать и анализировать имитационные эксперименты.

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

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

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

 
назад

вперед