serge_gorshkov


Сергей Горшков - о бизнесе в сфере ИТ

о семантической интеграции, программировании, управлении...


Previous Entry Share Next Entry
Использование онтологий в симуляционном моделировании
serge_gorshkov
В сборнике трудов II Конгресса БРИКС по computational intelligence вышла моя статья про использование онтологий для реализации систем симуляционного моделирования. Изложу здесь ее основные мысли.

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

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

  • Адекватно построить онтологию метаданных, представляющей описание среды и методики моделирования, в том числе – выбрать методику отражения в ней временнОго аспекта модели, способ представления состояний и событий.

  • Адекватно сконструировать онтологию самой модели.

  • Реализовать исполнение модели, представленной в онтологической форме.

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

  • эффективности (влияния на достижение целей),

  • надежности (устойчивости онтологии к изменениям условий применения модели), и

  • безопасности (отсутствия рисков негативного влияния структуры онтологии на результаты моделирования).

Не претендуя на слишком широкий охват проблемы, мы рассмотрим некоторые конкретные аспекты такого моделирования.
Ключевым вопросом любого моделирования является определение допустимого уровня абстракции, то есть степени упрощения описания элементов модели по сравнению с соответствующими им объектами реального мира. Большая степень упрощения позволяет легче манипулировать элементами модели, но приводит к недостатку осмысленности результата. Число возможных вариантов такого упрощения практически бесконечно, и сводится к:
а) отбору тех особенностей объектов и явлений, которыми можно пренебречь в модели,
б) выбору способа представления в модели тех их аспектов, пренебречь которыми нельзя.

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

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

Разумеется, единственным критерием правильности построенной модели является соответствие ее результатов поведению моделируемой системы и ее элементов в реальном мире. Сформулируем в общем виде простой критерий проверки правильности модели процесса с прагматической точки зрения. Фрагмент реальности и его модель связаны отношениями подобия, через которые выражаются те правила, которые заложены в выбранной методике моделирования. Методика выбирается исходя из приемлемого для наших задач уровня абстракции, по описанному выше принципу.
У моделируемого процесса есть исходное и конечное состояния. При помощи отношений подобия мы можем «отразить» их в модель. Если результат протекания процесса в реальном мире, отраженный в модель, и результат протекания модели процесса в самой модели, будут отличаться не более, чем на устраивающую нас величину погрешности — значит, модель пригодна. На диаграмме это можно показать так:



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

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

Применим этот критерий к частной задаче – оценке и выбору способов отражения временнОго аспекта модели. В симуляционных моделях время всегда дискретно, то есть увеличивается с каждым шагом на определенную небольшую величину. Это приводит к соблазну назвать совокупность характеристик, присущую объекту на том или ином шаге моделирования, его состоянием (разумеется, мы говорим не только об объектах, имеющих пространственную локализацию). Если характеристики неизменны на протяжении нескольких шагов, состояние получает ненулевую длительность. Событием удобно назвать факт перехода объекта из одного состояния в другое.
Одним из способов отражения событий и состояний в модели является их выделение в отдельные объекты в модели – такой подход использует, например, методика моделирования, описанная в стандарте ISO 15926. ВременнАя эволюция объекта описывается последовательностью объектов более низкого уровня – временнЫх частей, связанных определенным отношением с «корневым» объектом.

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

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

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

Таким образом, выделение событий в модели имеет смысл в том случае, если результат моделирования, который нас интересует, состоит в отслеживании этих событий, и выражен в терминах того же контекста, в котором мы определяем события. Иными словами – в том случае, если восприятие и интерпретация событий имеют ценность для пользователя модели. Пользователь всегда, в явной или неявной форме, задает модели вопросы. Если вопрос формулируется как «Когда спускаемый аппарат войдет в атмосферу?» – выделение такого события имеет смысл. Если пользователя интересует только общее время спуска – то не имеет. Из этого рассуждения следует, что не существует способа разделения «объективных», или «физических» событий, и «субъективных».

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

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

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

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

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

  • 1
Ну и остался самый важный вопрос: как проверить правильность выбранной модели, если
1. Вариативность модели не позволяет протестировать нужное количество комбинаций
2. Если модель призвана помочь нам предсказать поведения оригинала в условиях, в которые мы поставить оригинал не можем (себе позволить)? Ну например мы моделируем, что будет при падении Останкинской телебашни. Не можем же мы для проверки правильности модели свалить башню?

Отличный вопрос, спасибо!

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

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

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

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

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

Когда я писал вопрос я, конечно, имел ввиду некоторый ответ:
К примеру упомянутый "макет" - это тоже модель. Но самая удобная модель - это модель математическая. Она удобна тем, что существует в голове и на бумаге и не соответственно не требует больших затрат на построение. У нее есть еще одно важное свойство, существует, придуманная еще древними греками, технология проверки правильности модели, которая называется "доказательство". Вы тут говорите про то, что необязательно в модели все учитывать. Согласен, упрощенно в модели учитываем все что нам известно, а потом отбрасываем лишние элементы модели аккуратно доказывая мизерность их влияния на поведение модели...

Edited at 2015-07-08 06:14 am (UTC)

Ну, я же согласился, что во многих случаях нас подход с прямой практической проверкой не устроит )

Вы говорите, что правильность модели можно доказать логически. Тогда нет разницы, правильность какой модели доказывать - математической, компьютерной или натурной (макета).

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

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

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


  • 1
?

Log in

No account? Create an account