При моделировании исследователь должен быть уверен в корректности модели, в соответствии модели реальному прототипу. Точность математического моделирования зависит от того, насколько хорошо математическая модель отражает свойства объекта. Исследователю важно знать, с какой погрешностью он получает результат, потому что в случае большой погрешности расчет теряет смысл.

На точность моделирования влияют следующие особенности:

■ упрощение модели;

■ ошибки при построении модели;

■ использование элементов с низкой точностью, с линейной аппроксимацией;

■ наличие в модели вырожденных конечных элементов;

■ некорректные связи;

■ некорректные параметры моделей;

■ некорректные свойства элементов;

■ некорректные начальные и граничные условия;

■ погрешности метода расчетов.

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

Верификация модели (model verification) – проверка ее истинности, адекватности. Дословный перевод с английского: verification – это: 1) контроль, проверка; Sync: check, examination; 2) удостоверение, подтверждение (предсказания, сомнения) (а); подтверждение под присягой (б); 3) засвидетельствование. В отношении к дескриптивным моделям верификация модели сводится к сопоставлению результатов расчетов по модели с соответствующими данными действительности – фактами и закономерностями экономического развития. В отношении нормативных (в том числе оптимизационных) моделей положение сложнее: в условиях действующего экономического механизма моделируемый объект подвергается различным управляющим воздействиям, не предусмотренным моделью; надо ставить специальный экономический эксперимент с учетом требований чистоты, т.е. устранения влияния этих воздействий, что представляет собой трудную, во многом еще не решенную задачу.

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

Валидация модели (model validation) – проверка соответствия данных, получаемых в процессе машинной имитации, реальному ходу явлений, для описания которых создана модель. Она производится тогда, когда экспериментатор убедился на предшествующей стадии (верификации) в правильности структуры (логики) модели, и состоит в том, что выходные данные после расчета на компьютере сопоставляются с имеющимися статистическими сведениями о моделируемой системе.

В более общем виде верификация – это подтверждение на основе представления объективных свидетельств того, что установленные требования были выполнены. Если образно, то верификация – процедура сопоставления того, что сделано (или еще пока делается), с тем, что было задумано (предписано) сделать, т.е. сопоставление законченного или промежуточного результата с входными требованиями – "взгляд назад".

Валидация – подтверждение на основе представления объективных свидетельств того, что требования, предназначенные для конкретного использования или применения, выполнены. Образно говоря, валидация – это процедура сопоставления того, что задумано сделать (или еще пока делается), с тем, что необходимо потребителю для конкретного применения, т.е. сопоставление планируемого или промежуточного результата деятельности с текущими выходными требованиями – "взгляд вперед". Дословный перевод с английского: validation – это: 1) ратификация, утверждение, Sync: ratification; 2) легализация, признание законной силы, придание юридической силы.

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

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

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

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

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

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

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

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

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

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

■ точность. Насколько точны результаты работы приложения? Трудно реализуется при модельном подходе; логическая верификация в данном случае будет более эффективна;

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

■ соответствие. Соответствует ли реализованная функция данному стандарту? Стандарт используется как спецификация (источник требований), реализация функции моделируется;

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

Множество атрибутов надежности характеризует способность программного обеспечения поддерживать определенный уровень предоставляемых услуг при данных условиях и в течение заданного промежутка времени:

■ завершенность. Является ли изначально предоставляемый уровень услуг достаточным? Все ли было реализовано? Это свойство по определению не может быть проверено формальным тестированием: на каждую ожидаемую функцию формулируется требование (или множество требований), которое проверяется на модели;

■ устойчивость к ошибкам. Ведет ли себя программа адекватно в случае предоставления заведомо неверных входных данных? Очень неэффективно и громоздко реализуется в модельном подходе, существуют неплохие методы тестирования, решающие эту проблему;

■ устойчивость к окружению (прочность ). Может ли приложение работать нормально в нестандартном или неустойчивом окружении? Применение модельного подхода в данном случае возможно только при наличии возможности моделирования окружения. Однако корректное моделирование стресс-ситуации – весьма нетривиальная задача;

■ восстанавливаемость. Может ли приложение продолжать работу после сбоя? Как правило, это свойство явно прописывается в программе и нуждается только в проверке. Может быть проверено как модельной верификацией, так и тестированием.

Множество атрибутов по удобству пользования характеризует трудности при использовании программного обеспечения и их субъективную оценку тем или иным множеством пользователей:

■ понятность. Насколько интуитивно ясен пользовательский интерфейс приложения? Не поддается научной формализации. Несмотря на то что менее формальные правила существуют уже давно, модельная верификация невозможна;

■ обучаемость. Приспосабливается ли приложение к специфике пользователя? Используются алгоритмы искусственного интеллекта, которые могут быть верифицированы, соответственно может быть верифицирован и признак;

■ управляемость. Легко ли управлять работой приложения? Эта область, традиционная для бета-тестирования, в последнее время переходит в руки специалистов по пользовательским интерфейсам.

Множество атрибутов производительности выявляет связь уровня предоставляемых приложением услуг с объемом используемых при этом ресурсов:

■ поведение во времени. Адекватен ли временной график использования ресурсов? В данном случае нужно тестировать реальную систему, а не ее модель (например, для нахождения утечки памяти). Абсолютно не подходит для модельной верификации;

■ использование ресурсов. Эффективно ли используются ресурсы? Имеется направленность на реальную систему, и существуют эффективные методы формального тестирования, которые в основном базируются на смеси сетей Петри и специализированных языков описания моделей верификации, при прогонке которых происходит количественная оценка потенциально используемых ресурсов; максимальное значение дает вполне эффективную оценку, пригодную для большинства реализаций;

■ алгоритмизация. Насколько оптимальны использованные алгоритмы? Классический анализ алгоритмов вместе с формальной их верификацией дает быстрые и точные результаты.

Множество атрибутов поддержки связано с усилиями по внесению определенных изменений в работающее приложение:

■ анализируемость. Насколько легко определить части, нуждающиеся в изменении? Не поддается формализации;

■ изменяемость. Какие усилия требуются для внесения изменений? Не поддается формализации, уровень может быть установлен априори;

■ настраиваемостъ. Можно ли достичь желаемого эффекта без изменения самой программы, изменяя только настройки? Задача решается тестированием в реальных условиях;

■ стабильность. Как ведет себя программа при внесении изменений на лету? Эффективно решается модельной верификацией с помощью недетерминированных параллельных процессов;

■ тестируемость. Насколько легко проверяется работа изменившегося контура? Решается параллельно с тестированием или превентивно явным образом и к верификации отношения практически не имеет.

Множество атрибутов переместимости характеризует способность программного обеспечения быть перенесенным из одного окружения в другое:

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

■ устанавливаемость. Может ли приложение устанавливаться на разные платформы или в разные конфигурации? Как правило, явно задается в спецификации и явно реализуется и в проверке не нуждается;

■ согласованность. Какие стандарты были использованы в приложении? Не нуждается в проверке, однако само соответствие стандартам проверять можно и нужно;

■ заменяемость. Может ли приложение быть использовано так же, как его эквивалент от другого производителя? Зависит ли от списка опций соответствующих приложений, которые могли бы быть или должны были быть реализованы?

Это относится к фазе формулирования требований, поэтому в верификации не участвует.

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

Цель работы – изучить методы проверки соответствия разработанной имитационной модели реальной системе.

В ходе выполнения лабораторной работы студент должен научится проводить верификацию имитационной модели путем построения логической блок-схемы и интерактивного контроля за ходом моделирования при помощи встроенной в специализированный язык GPSS/H программы отладки; проверять правильность построения концептуальной модели в компьютере; проводить валидацию имитационной модели путем сопоставления результатов экспериментов с результатами аналитических расчетов.

Примечание

Предполагается, что студент, знаком с теорией систем массового обслуживания и основами моделирования систем на специализированном языке GPSS/H.

2. Теоретические положения

2.1. Верификация и валидация имитационных моделей

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

Верификация — это проверка правильности построения концептуальной модели в компьютере. Она используется при сравнении концептуальной модели с ее компьютерным представлением и отвечает на вопросы: правильно ли модель выполняется на компьютере? Правильно ли представлены входные параметры и логическая структура модели?

Для верификации используют методы:

1. Проверка корректности результатов на «крайние» значения. При этом:

— задают нулевые значения входных параметров модели и анализируют результаты. Если результаты не нулевые, то проверяют и уточняют модель;

— задают значения входных параметров модели, которых не может быть в реальной системе, и по результатам моделирования оценивают правильность реакции модели;

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

2. Аналитический подсчет характеристик и сравнение их с модельными результатами. За длительный прогон вручную подсчитывают использование прибора и сравнивают расчетное значение с результатами моделирования. Но есть характеристики, которые невозможно посчитать аналитически, например, среднее время обслуживания заявки. Тем не менее, параметры в модели взаимосвязаны и проверка одной характеристики повышает доверие (или не доверие) к другим параметрам и модели в целом, даже если точные связи между характеристиками неизвестны и изменяются от прогона к прогону.

3. Построение логической блок-схемы и интерактивный контроль за ходом моделирования при помощи программ отладки. Составляют простую логическую блок-схему для какого-либо узла модели. Например, для одноканальной СМО можно составить блок схему, изображенную.

Затем, используя встроенные в пакеты имитационного моделирования программы отладки проверяют, соответствует ли логика работы модели построенной блок-схеме. При этом используют:

— прогон до определенного времени или события и вывод информации за данный период времени;

— приостановку моделирования по значению текущей величины переменной выделенного компонента модели (очереди, прибора, счетчика, атрибута).

4. Использование имитационного следа. Имитационный след это детальная распечатка изменений модели в течение времени. Его разрабатывают специально для использования в имитационных программах. Он позволяет просматривать величину выбранных переменных в каждый момент приращения времени (от события к событию). При анализе такого имитационного следа можно выявить ошибки и несоответствия модели реальной системе.

5. Документирование модели и проверка лицом не участвующим в разработке модели. Этим методом часто пренебрегают. Но если разработчик модели пишет краткие комментарии в компьютерной модели, проводит определение всех переменных и параметров и делает пометки главных модулей модели, это значительно облегчает кому-либо и самому разработчику модели проверить ее логику.

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

Валидация — проверка является ли модель, допустимым представлением реальной системы. Цель валидации – двойная, во-первых, создать модель, которая представляет поведение реальной системы как можно более полно. Во вторых, увеличить приемлемый уровень достоверности модели, чтобы модель можно было использовать для анализа системы и принятия решений.

Вообще нет общепринятых количественных оценок валидации моделей. Большинство авторов считают, что если отклонение результатов моделирования от показателей реальной системы или определенных другим методом не превышает 7-10%, то модель считается валидной.

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

Валидация - процесс проверки того, что модель является достаточно точным описанием системы для целей конкретного исследования

Валидация имеет смысл только когда определены цели исследования

*Валидация модели существующей системы обычно проще, чем валидация модели проектируемой системы

*Не стоит откладывать валидацию на самый конец работ

*Если старая модель используется с новой целью, то валидацию нужно повторить

Методы валидации концептуальной модели

*Определить цели исследования

*Описать концептуальную модель («Допущения» - “Assumptions”)

*Привлечь экспертов в предметной области к [формальной] проверке концептуальной модели (“face validation” и трассировка)

Методы валидации данных

*Анализ чувствительности результатов моделирования к вариациям входных данных

*Статистические тесты для эмпирических распределений вероятности

*Проверки на непротиворечивость

Методы повышения достоверности

*Постоянное взаимодействие с пользователями, подробное объяснение и согласование предположений, заложенных в модель

*Демонстрация того, что модель валидирована и верифицирована. Независимая валидация, верификация и аккредитация модели

*Дать пользователю возможность самостоятельно выполнять моделирование. Красивая и понятная визуализация результатов

*Репутация разработчиков модели

Понятие события в имитационном моделировании.

Если модель строится с целью изучения причинно-следственных связей, присущих системе, динамику системы целесообразно описывать в терминах событий.

Событие представляет собой мгновенное изменение некоторого элемента системы или состояния системы в целом. Событие характеризуется:

Условиями (или законом) возникновения;

Типом, который определяет порядок обработки (дисциплину обслуживания) данного события;

Нулевой длительностью.

События подразделяют на две категории:

События следования, которые управляют инициализацией процессов (или от¬дельных работ внутри процесса);

События изменения состояний (элементов системы или системы в целом).

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

Принципы разработки имитационных моделей.

При разработке имитационных моделей необходимо соблюдать следующие принципы.

Принцип информационной достаточности.

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

Принцип осуществимости.

Создаваемая модель должна обеспечить достижение поставленной цели с вероятностью отличной от нуля и за конечное время. Обычно задают пороговое значение вероятности р0 достижения цели моделирования, выраженное функцией p(t), а также приемлемую границу времени t0 достижения этой цели. Модель считается осуществимой, если одновременно выполняются неравенства p(t) ? p0, t ? t0.

Принцип множественности моделей.

Данный принцип является ключевым. Создаваемая модель должна отражать в первую очередь те свойства реализуемой системы или явления, которые влияют на выбранный показатель эффективности.

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

Принцип агрегирования.

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

Если при исследовании построенных моделей получаются сходные результаты, то исследование успешно завершено. Если результаты различаются, то необходимо либо пересмотреть постановку задачи, либо поставить вопрос об адекватности математических моделей.

Принцип параметризации.

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

Принцип целесообразности.

Необходимо соизмерять точность исходных данных и с результатами, которые нужно получить.

Принцип устойчивости.

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

Принцип адекватности.

Модель должна отражать существенные черты исследуемого явления, при этом не должна сильно упрощать исследуемые процессы.

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

При выполнении ответственных инженерных расчетов численными методами для обоснования корректности расчетных моделей рекомендуется применять процедуру верификации и валидации модели , разработанную и предложенную ведущими мировыми организациями в области инженерных расчетов - NAFEMS (International Association for the Engineering Modelling, Analysis and Simulation Community) и ASME (American Society of Mechanical Engineers).

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

Применительно к данным видам моделей для проверки их адекватности используются подход верификации и валидации . Верификация проводится в области математики, а валидация – в области физики.

Верификация

Как следует из данного определения, процесс верификации позволяет достичь уверенности в корректности численной модели. Процесс верификации модели состоит из двух шагов:

- Верификация программного кода для подтверждения того, что математические модели и алгоритмы численного решения систем уравнений работают корректно;

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

Верификация программного кода

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

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

Верификация вычислений

Второй составляющей процесса верификации является верификация вычислений – определение точности численного решения для заданной дискретизации расчетной области. Численное и аналитическое решения apriori отличаются, поскольку дискретное решение является лишь аппроксимацией аналитического. Поэтому целью верификации вычислений является установление количественного значения погрешности для заданной дискретной модели.

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

Валидация

Ни один из этапов верификации не позволяет определить, насколько выбранные модели адекватны объекту исследования. Оценка соответствия численной модели реальному миру относится к задачам валидации, которая позволяет определить, насколько физические явления и законы, включенные исследователем в расчетную модель, соответствуют постановке исходной задачи и достаточны для получения требуемых решений.

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

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

Также крайне важно, чтобы результаты эксперимента не были бы известны расчетчикам заранее, до получения численного решения. Основная причина этого – убедиться в "предсказательных возможностях" численной модели. Если результаты эксперимента известны расчетчику заранее, что естественным будет желание «настроить» модель на конкретный результат. Это снижает уровень доверия к численной модели.

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

При подготовке статьи использованы материалы сайта www.nafems.org

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

КУРСОВАЯ РАБОТА

По дисциплине « Имитационное моделирование »

На тему: « Валидация и верификация имитационной модели »

Введение

2. Валидация

Заключение

Введение

Качество информации является одним из важнейших параметров для потребителя информации. Оно определяется следующими характеристиками:

Репрезентативность - правильность отбора информации в целях адекватного отражения источника информации.

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

Доступность - простота (или возможность) выполнения процедур получения и преобразования информации.

Актуальность - зависит от динамики изменения характеристик информации и определяется сохранением ценности информации для пользователя в момент ее использования.

Своевременность - поступление не позже заранее назначенного срока.

Точность - степень близости информации к реальному состоянию источника информации.

Достоверность - свойство информации отражать источник информации с необходимой точностью.

Устойчивость - способность информации реагировать на изменения исходных данных без нарушения необходимой точности.

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

Имитационные модели получают все большее применение в процессе решения задач и принятия решений. В том, что модель и полученные с ее помощью результаты являются верными, в полной мере заинтересованы как разработчики модели, ее пользователи и лица, принимающие решения, так и люди, на которых оказывают влияние решения, принятые на основе данной модели. Эта заинтересованность в первую очередь относится к верификации и валидации модели. Под верификацией чаще всего понимают проверку правильности преобразования концептуальной имитационной модели в программную модель, под валидацией - проверку правильности её поведения и представления концептуальной модели. В Министерстве Обороны США широко применяются имитационные модели. В последние годы Министерство Обороны проявляет интерес к верификации, валидации и концепции, известной как аккредитация (VV&A- Validation, Veryfication and Accreditation). Аккредитация определяется как «официальное засвидетельствование того, что модель, симуляция, или объединение моделей и симуляций является допустимым для использования для определенной цели».

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

По одному из принципов тестирования полное тестирование систем имитационного моделирование невозможно (Balci). Исчерпывающее (полное) тестирование требует тестирования систем имитационного моделирования при всех возможных значениях входных параметров. Комбинации возможных значений входных параметров для систем имитационного моделирования в ходе исполнения программы могут привести к миллионам логических цепочек. Но в силу временных и денежных ограничений тестирование правильности такого большого количества логических цепочек невозможно.

Поэтому можно сказать, что «единственный существующий способ исчерпывающего тестирования - это тестирование до тех пор, пока тестеры не исчерпают все свои силы».

Следовательно, целью тестирования систем имитационного моделирования является увеличение уверенности в правильности системы в той мере, как это диктуется планируемым использованием системы и целями проекта, а не попытка полного тестирования системы имитационного моделирования.

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

верификация валидация имитационный модель

1. Этапы имитационного моделирования

Процесс построения имитационных моделей представляет собой последовательное выполнение этапов имитационного моделирования. Эти этапы процесса моделирования приведены в книге А.Прицкера:

Формулирование проблемы-описание исследуемой проблемы и определение целей исследования.

Разработка модели - логико-математическое описание моделируемой системы в соответствии с формулировкой проблем.

Подготовка данных - идентификация, спецификация данных.

Трансляция модели - перевод модели на язык, приемлемый для используемой ЭВМ

Верификация модели - Установление правильности машинных программ

Валидация модели - оценка требуемой точности и соответствия имитационной модели реальной системе.

Стратегическое и тактическое планирование - определение условии проведения машинного эксперимента с имитационной моделью.

Экспериментирование - прогон имитационной модели на ЭВМ для получения требуемой информации.

Анализ результатов - изучение результатов имеет моделирование для подготовки выводов, для решения проблемы.

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

Рассмотрим более подробно этапы верификации и валидации имитационной модели. Эти этапы связаны с оценкой функционирования имитационной модели. На этапе верификации определяется, соответствует ли запрограммированная модель замыслу разработчика. Установление адекватности имитационной модели выполняется на этапе валидации. Валидация модели обычно выполняется на различных уровнях (например, на уровне входных данных, элементов модели, подсистем и их взаимосвязи). Проверка адекватности модели включает сравнение её структуры со структурой системы, сравнения того, как реализованы элементарные функции и рушения в модели и системе.

Существуют специальные методы валидации (например, путём оценивания чувствительности выходных данных к изменению значений входных), различные парадигмы, подходы и методики. Рассмотрим некоторые из них. Но прежде постараемся дать основные определения, а именно, более подробно рассмотрим различные подходы к валидации, а затем и алгоритм построения валидной модели, предложенный Лоу.

2. Валидация

Итак, валидация - это процесс определения того, является ли имитационная модель точным представлением данной системы для конкретной задачи. Существует несколько точек зрения на валидацию:

Валидная модель может быть использована для принятия решений, сходных с теми, которые были бы приняты на реальной и недорогой системе.

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

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

Имитационная модель всегда должна разрабатываться для конкретного набора задач. Фактически модель, валидная для одной задачи, может не быть валидной для другой задачи.

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

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

Имитационная модель и результаты ее выполнения надежны, если лицо, принимающее решение и другие ведущие специалисты проекта приняли ее как «точная».

Заметим, что надежная модель не всегда является валидной, и наоборот, валидная модель не всегда является надежной. Для упрощения установления надежности модели необходимо следующее:

Понимание и принятие принимающим решение лицом допущений модели.

Демонстрация того, что была осуществлена валидация и верификация модели (то есть того, что программа отлажена).

Вовлеченность и ответственность за проект лица, принимающего решения.

Репутация "84разработчиковЃE модели.

Убедительная анимация.

3. Подход к управлению успешным исследованием системы методами имитационного моделирования

На рис. представлены этапы построения имитационной модели (они уже были приведены ранее). Далее более подробно рассматриваются рекомендации А. Лоу по проведению каждого из этапов. Приведённая ниже информация используется А. Лоу при чтении курса лекций.

Этапы исследования имитационной модели

Шаг 1. Формулировка задачи

* Задача формулируется лицом, принимающим решение

Задача может быть сформулирована нечетко либо только на качественном уровне.

Обычно задача формулируется итеративно.

* Организационное совещание таких проектов возглавляются руководителем проекта, в присутствие аналитика в области имитационного моделирования и эксперта в данной предметной области. На собрании обсуждаются следующие положения:

Общие цели исследования.

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

Критерии качества, используемые для определения эффективности различных конфигураций системы.

Размеры системы.

Моделируемая конфигурация системы.

Изучаемый временной кадр и необходимый ресурсы (люди, компьютеры и т.д.)

Шаг 2. Сбор данных и создание концептуальной модели

* Сбор информации о макете системы и способе эксплуатации.

* Сбор данных для определения параметров модели и распределении вероятностей (например, для времени отказов и времени восстановления машины).

* Документация допущений модели, алгоритмов, краткое изложение данных на письменной концептуальной модели.

* Уровень детализации модели должен зависеть от следующего:

Цели проекта

Критерий решения задачи

Доступность данных

Технические ограничения

Мнения экспертов в данной предметной области

Временные и финансовые ограничения

Между моделью и системой не должно быть соотношения один-к-одному.

Степень достоверности.

Сбор данных о рабочих характеристиках (выходных) на основе существующей системы (если таковая существует) для последующей валидации модели на шаге 5.

Шаг 3. Определение валидности концептуальной модели

* Структурированный просмотр концептуальной модели в присутствии руководителя проекта, аналитика и эксперта. Этот просмотр называется валидацией концептуальной модели.

* Если в концептуальной модели выявлены ошибки или упущения, которые есть практически всегда, то до того как приступить к этапу программирования необходимо обновить модель.

Шаг 4. Программирование модели

* Программирование модели на коммерческих пакетах для имитационного моделирования или на универсальных языках программирования (например, С, С++ или Java).

* Проверка (откладка) программы.

Шаг 5. Определение валидности запрограммированной модели

* При наличии реальной системы необходимо сравнить выходные данные имитационной модели с соответствующими выходными данными реальной модели (см. шаг 2). Этот процесс называется валидацией результатов.

* Независимо от того, существует ли реальная система или нет, аналитик по имитационному моделированию и эксперт в данной предметной области должны просмотреть результаты моделирования на корректность. Если результаты согласуются с тем, какими они должны быть в реальной системе, то говорят, что имитационная модель имеет внешнюю (лицевую) валидность.

* Для определения параметров модели, более всего влияющих на критерии качества, необходимо произвести анализ чувствительности. Полученные параметры требуют более тщательного моделирования.

Шаг 6. Проектирование, управление и анализ экспериментов

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

* Проанализировать результаты и решить, нужны ли дополнительные эксперименты.

Шаг 7. Документирование и представление результатов моделирования

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

* Для повышения надежности модели окончательное представление исследования должно включать в себя анимацию и описание обсуждений процесса построения/валидации модели.

Заключение

Необходима валидация всех имитационных моделей, иначе решения, принятые на основе этих моделей, будут неверными. Ниже приводятся наиболее важные идей разработки валидных и надежных моделей:

Точная формулировка проблемы.

Проведение интервью с экспертами в данной предметной области.

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

Разработки письменной концептуальной модели.

Структурированный просмотр концептуальной модели. Если не существует реальной системы, то это может быть единственным методом валидации.

Применение анализа чувствительности для определения наиболее важных (существенных) параметров системы.

Использование теста Тьюринга для сравнения выходных данных модели и системы.

Проверка результатов работы системы и анимации на корректность.

Список использованной литературы

1. Лоу, А. Имитационное моделирование / А. Лоу, В. Кельтон. - СПб. : Питер, 2004.

2. Рыжиков, Ю.И. Имитационное моделирование. Теория и технологии / Ю.И. Рыжиков. - СПб: Корона принт, 2004.

3. Советов, Б.Я. Моделирование систем: практикум / Б.Я. Советов, С.А. Яковлев. - М. : Высш. шк., 2005.

4. Шрайбер, Т. Дж. Моделирование на GPSS/ Т.Дж. Шрайбер. - М.: Машиностроение, 1980.

5. Харин Ю.С. Основы имитационного и статистического моделирования. Учебное пособие/ Ю.С. Харин, В.И. Малюгин, В.П.Кирлица и др. - Мн.:Дизайн ПРО, 1997.

6. Кудрявцев Е.М. GPSS World. Основы имитационного моделирования различных систем/ Е.М. Кудрявцев. - М.: ДМК, 2004.

7. Максимей И.В. Имитационное моделирование на ЭВМ/ И.В. Максимей. - М.: Радио и связь, 1988.

8. Методические требования к содержанию и оформлению курсовых работ/ Л.П. Харлап, Е.М. Сибогатова. - Гомель, БТЭУ, 2004. (мет. №1365)

9. Лабораторный практикум по имитационному моделированию /Еськова О.И. - размноженные материалы в кааб 3-35.

Размещено на Allbest.ru

Подобные документы

Создание математической модели системы массового обслуживания на примере банка. Разработка имитационной модели на языке программирования С++. Блок-схема программы, перевод модели на язык программирования. Верификация и валидация имитационной модели.

курсовая работа , добавлен 01.06.2015


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

шпаргалка , добавлен 02.10.2013


Разработка имитационной модели "Перекресток" для анализа бизнес-процессов предприятия и принятия решения в сложных условиях. Алгоритм построения имитационной модели на основе CASE-средств. Обзор программного обеспечения для имитационного моделирования.

дипломная работа , добавлен 22.11.2015


Ознакомление с современными концепциями построения моделирующих систем. Характеристика основных приемов имитационного моделирования. Перевод алгоритма на язык программирования. Понятие и этапы верификации: установления правильности машинной программы.

курсовая работа , добавлен 30.03.2011


Процесс моделирования имитационной модели функционирования класса персональных компьютеров на языке GPSS World. Поиск линейной зависимости и оценка полученного уравнения. Отчет по результатам работы имитационной модели. Листинг разработанной программы.

курсовая работа , добавлен 07.09.2012


Понятие компьютерной модели и преимущества компьютерного моделирования. Процесс построения имитационной модели. История создания системы GPSS World. Анализ задачи по прохождению турникета на стадион посредством языка имитационного моделирования GPSS.

курсовая работа , добавлен 11.01.2012


Основы технологии моделирования Arena. Построение простой имитационной модели. Моделирование работы системы обслуживания покупателей на кассе супермаркета. Построение модели IDEF3. Анализ результатов имитационного моделирования и аналитического решения.

курсовая работа , добавлен 24.03.2012


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

курсовая работа , добавлен 29.04.2014


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

курсовая работа , добавлен 25.06.2011


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