Кроме приведённых выше количественных характеристик, большое значение имеют качественные показатели сложности объекта автоматизации:
неопределенность: трудно предсказать изменения спроса и предложения
событийность: часто случаются события, требующие оперативного изменения планов, решений в реальном масщтабе времени
ситуативность: решение надо принимать по ситуации.
многофакторность: много разных критериев, предпочтений и ограничений.
высокая связность: принятие оперативного решения на одном участке (станции) требует учёта принятых или планируемых решений на связанных участках (станциях) и вызывает изменение решений многих других.
индивидуальность: участники требуют все более индивидуального подхода.
конфликты: все больше участников с противоречивыми интересами.
трудоемкость: слишком много опций, чтобы просчитать последствия.
оперативность: требуется высокая оперативность принятия решений.
Эти особенности требуют новых современных стратегических подходов, методов и средств автоматизации производственной деятельности и обеспечения поддержки принятия решений в реальном времени.
KPI’s системы
Эффективность функционирования мультиагентной системы динамического планирования движения пассажирских поездов оценивается на основе KPI's.
Рассмотрим KPI DEVT – минимальное суммарное отклонение фактического времени (planned time) начала и окончания выполнения задачи от запланированного времени (demanded time) по всем блок-участкам (перегонам). Данный KPI позволяет оценить отклонение поезда от графика на всем маршруте движения. Введем следующие обозначения для Задачи на блок-участке (Рисунок 1.41):
TDS – запланированное время старта,
TDF – запланированное время окончания,
TPS – фактическое время старта,
TPF – фактическое время окончания,
N – количество блок-участков (перегонов).
Рисунок 1.41 – Запланированное и фактическое время выполнения задачи
KPI DEVT вычисляется по формуле (1):
|
(1)
|
Выводы и предложения по результатам проведенных анализа и исследований
Разработанные в данном подразделе спецификация программной модели, описание бизнес-процессов, а также предварительные требования по расчету KPI работы мультиагентных планировщиков служат основой для создания Экспериментального образца и составления Технического задания.
Разработка экспериментального образца системы, позволяющего осуществлять адаптивное динамическое планирование в рамках одного модуля планирования
В данном подразделе приводится описание структуры Экспериментально образца (ЭО), планируемого к разработке на базе программной модели управления движением поездов.
Описание структуры и принципов работы модуля планирования
Компоненты модуля планирования экспериментального образца
Для построения модуля мультиагентной обработки данных разработчики могут применять готовые компоненты, входящие в состав общей онтологии. Компоненты организованы в несколько групп (пространств имен), которые имеют разную степень специализации: от базовых компонент, имеющих самое общее назначение по обработке данных, до компонент, специализированных для создания модулей планирования мобильных ресурсов и поддерживающих некую стандартную реализацию логики переговоров для выработки эффективной последовательности выполнения поездок. Общая структура базовой платформы представлена на Рисунке 1.42.
Рисунок 1.42 Общая структура базовая платформа
Мультиагентное ядро обработки данных
Базовое ядро платформы включает все предметно-независимые компоненты, которые могут быть использованы для построения мультиагентной системы, решающей любую задачу обработки данных.
Базовые классы и интерфейсы
IAgent – базовый интерфейс агента, работающего в мультиагентной среде и имеющего определенную внутреннюю цель. Логика достижения результата заложена в реализации метода Process(), который вызывается диспетчером в ходе решения общей задачи. Интерфейс также объявляет методы для получения и отправления сообщений. В рамках метода Process() агент должен выполнить один неделимый шаг обработки. При этом в результате он может изменить общую сцену (значения свойств объектов и связи между ними) и послать сообщения другим участникам переговоров.
IObject – базовый интерфейс объекта сцены. Все объекты сцены должны быть привязаны к одной определенной сцене и могут иметь несколько ассоциированных с ними агентов. На практике, часто конкретная реализация объекта реализует как интерфейс IObject, так и IAgent.
IDispatcher – базовый интерфейс диспетчера агентов. Диспетчер обеспечивает порядок и своевременность передачи управления различным агентам, работающим с общей сценой. Конкретная реализация диспетчера может обеспечивать работу агентов в одном или нескольких потоках. Для управления процессом обработки данных диспетчер имеет методы для запуска и остановки обработки. Кроме того, можно явно добавить или удалить агентов из списка диспетчеризации.
IScene – базовый интерфейс для доступа к сцене. Класс, реализующий этот интерфейс предоставляет списки всех объектов сцены, отвечает за подсчет показателей эффективности сцены и за сопоставление агентов объектам сцены. Базовый интерфейс требует наличия, как минимум, функции расчета общего показателя эффективности текущего решения, хранящегося в сцене. На основании динамики этого показателя определяется, улучшилось ли решение, и можно ли передавать его пользователям (или другим модулям). Модули базовой платформы представлены на рисунке 1.43.
Рисунок 1.43 - Модули базовой платформы
Диспетчер мультиагентной среды
В базовом ядре также объявлены простые классы, реализующие указанные выше интерфейсы. Данные классы можно использовать, как базовый вариант для решения простых задач.
Dispatcher – простая реализация интерфейсов IDispatcher и IScene, обеспечивающая загрузку агентов, диспетчеризацию в одном потоке, передачу сообщений на сохранение данных каждый раз при росте основного показателя эффективности. Общая схема работы данной реализации диспетчера представлена ниже на Рисунке 1.44.
Рисунок 1.44 – Алгоритм работы диспетчера
Agent – класс абстрактной активной сущности, которая выступает одновременно в роли объекта и агента и имеет стандартный вид логики, состоящий из восприятия ситуации, определения вариантов действий, оценки различных вариантов и выстраивания их в последовательность шагов, отработки первого шага, определения конфликтных интересов и отправки предложений о разрешении конфликта.
Рисунок 1.45 – Алгоритм работы класса IAgent
После завершения указанной последовательности действий агент передает управление диспетчеру. Если к моменту повторного получения управления ситуация изменилась, то агент переоценивает свои опции и формирует из них новый план действий. В базовой реализации не предусмотрено отдельных шагов, связанных с отслеживанием этапа переговоров, эта логика входит в шаг восприятия ситуации и может быть переопределена в наследниках от базового агента.
Описание взаимодействия с мультиагентным ядром
Для использования любой конкретной реализации модуля мультиагентной обработки данных, построенного на мультиагентном ядре, необходимо сначала создать компоненты ядра:
экземпляр конкретной реализации интерфейса IScene. Это может быть либо наследник от BasicDispatcher, который входит в состав платформы, либо более высокоуровневая реализация.
экземпляр конкретной реализации IDispatcher. BasicDispatcher реализует также этот интерфейс.
экземпляр IObjectFactory. Конкретная реализация не входит в состав базовой платформы.
После того, как компоненты созданы и связаны между собой, в сцену необходимо передать весь набор взаимосвязанных объектов, представляющих собой рабочие данные для обработки. При передаче их в сцену, автоматически генерируются агенты активных сущностей.
После подготовки сцены можно запустить мультиагентную обработку (Рисунок 1.46).
Рисунок 1.46 – Алгоритм работы объекта IScene
Мультиагентное ядро непрерывно обрабатывает объекты сцены, создает и изменяет выходной результат. В любой момент времени (обычно, это делается периодически, в цикле) можно обратиться к сцене, проверить, насколько улучшился результат, и принять либо не принять его. Затем можно сформировать набор встречных изменений во входных данных. Это могут быть как изменения, пришедшие извне, так и изменения, сформированные в ответ на полученный результат, чтобы его скорректировать. Если сформированный набор изменений предполагает немедленную реакцию системы, то необходимо, до передачи их в мультиагентное ядро, описать результат «по умолчанию», непосредственно изменив объекты сцены, или создав новые объекты. Затем общий набор изменений, включая результат «по умолчанию» передаются в сцену.
Рисунок 1.47 – Алгоритм учета изменений
Мультиагентное ядро планирования
Ядро мультиагентного планирования является расширением мультиагентного ядра обработки данных и содержит интерфейсы и базовые классы, специализированные для задач построения расписаний.
Базовые интерфейсы для описания задач планирования
Для описания задачи планирования применяется несколько основных понятий, отражающих ее постановку, начальные условия и результат.
IDemand – объект предметной области, описывающий, что необходимо запланировать. Это может быть описание задачи, требование о выпуске продукции к определенному сроку, строка в расписании, задающая планируемое время прибытия или отправления транспорта. Требования могут иметь подтребования. Так, задача доставки груза «разворачивается» в набор задач о погрузке, транспортировке и разгрузке.
IOperation – элементарное требование, задача, которая должна быть непосредственно запланирована в виде конкретных временных отношений (расписания). В отличие от более абстрактного IDemand, который может удовлетворяться косвенно, через подтребования.
IResource – объект предметной области, описывающий свойства конкретного физического объекта, который участвует в выполнении операций, которые мы планируем.
ITemporaryRelation – временное отношение между ресурсами, описывающее, как ресурсы взаимосвязаны (или будут взаимосвязаны) на определенном промежутке времени и какие действия они выполняют. Эта сущность также применяется для описания фактической ситуации, фактически выполнявшихся задач и отношений между объектами в реальном мире.
Общее описание структуры планировщика представлена на Рисунке 1.48.
Рисунок 1.48 - Общее описание структуры планировщика
Интерфейсы, примеры интерфейсов, реализованных на основе алгоритма разрешения конфликтов по всему расписанию
Разрабатываемый в рамках проекта экспериментальный образец должен обеспечивать удобное взаимодействие с пользователем, показывать вновь поступающие события и текущее расписание работ, а также фактическое состояние работ. Интерфейс должен поддерживать простой и доступный ввод плановых значений движения транспорта, поддержку возможности внесения фактических данных (не совпадающих с плановыми), показывать прогресс планирования и результаты планирования (значения KPI позволяющие определить какой из вариантов лучше и почему). Основным интерфейсом отражающим выходные данные должны стать графики движения транспорта, с возможностью отображения окон.
Получаемые решения должны поддерживать возможность быть согласованными и санкционированными, либо должны быть отправлены на доработку пользователем, выступающим в роли диспетчера. В ходе работы экспериментального образца необходимо предусмотреть интерфейс, позволяющий изменять критерии планирования (например приоритет).
Ниже показаны примеры выходных интерфейсов в качестве графиков движения, при отработке сценариев планирования и решения конфликтов:
два поезда с одинаковыми приоритетами и одинаковой скоростью движения
На Рисунке 1.49, Рисунке 1.50 показано, что разрешение конфликта для данного сценария выполняется за счет задержки одного из поездов, график движения которого изображен синим цветом, на станции.
Рисунок 1.49 – График движения поездов до разрешения конфликта
Рисунок 1.50 – График движения поездов после разрешения конфликта
Три поезда с одинаковыми приоритетами и одинаковой скоростью движения
На Рисунке 1.51, Рисунке 1.52 показано, что разрешение конфликта для данного сценария выполняется за счет задержек поезда, график движения которого изображен синим цветом, на блок-участках, и пропуска остальных поездов, а также за счет уменьшения интервала движения между поездами, графики которых изображены красным и зеленым цветом, на отдельных блок-участках.
Рисунок 1.51 – График движения поездов до разрешения конфликта
Рисунок 1.52 – График движения поездов после разрешения конфликта
два поезда, один из которых имеет более высокий приоритет и большую скорость движения
На Рисунке 1.53, Рисунке 1.54 показано, что разрешение конфликта для данного сценария выполняется за счет задержки низкоприоритетного поезда на станции и пропуска более высокоприоритетного поезда.
Рисунок 1.53 – График движения поездов до разрешения конфликта
Рисунок 1.54 – График движения поездов после разрешения конфликта
Выводы и предложения по результатам проведенных анализа и исследований
Основная задача ЭО – обеспечение гибкого и эффективного перепланирования расписания железнодорожного транспорта в реальном времени с учетом приоритетного движения высокоскоростных поездов при возникновении незапланированных событий. При этом экспериментальный образец должен иметь возможность функционирования как адаптивная р2р сеть модулей, по крайней мере, 2х модулей интеллектуальных планировщиков (например, модуль планирования высокоскоростного ЖД транспорта и модуль управления ремонтными работами).
В рамках выполнения этапа №1 по ГК, были выполнены работы по созданию экспериментального образца, в том числе созданы классы объектов необходимых для успешного выполнения функций планирования. Большинство классов описано в подразделе №1.5 «Разработка программного мультиагентного подхода к построению процессов управления ЖД ресурсами» в виде онтологии. Помимо классов описаны и формализованы интерфейсы реализуемые данными классами. Описанные интерфейсы и классы положены в основу мультиагентного модуля планирования.
ЭТАП 2. Экспериментальные исследования поставленных перед НИР задач
Разработка частного технического задания на создание экспериментального образца по ГОСТ 34.602-89.
Для создания экспериментального образца прототипа интеллектуальной системы для согласованного адаптивного планирования и связанного изменения планов движения поездов для минимизации отклонения высокоскоростных поездов класса «Сапсан» от графика движения под влиянием непредвиденных внешних событий было создано частное техническое задание (ЧТЗ). ЧТЗ представлено отдельным документом отчетной документации по НИР.
Разработка структуры онтологии инфраструктуры РЖД, включая базовые классы, концепты, отношения, свойства и атрибуты инфраструктуры РЖД, используемые в процессе планирования, для настройки на конкретные примеры применения
Для описания знаний, необходимых агентам, входящим в состав МАС, используется онтологический подход, согласно которому знания должны быть отделены от программного кода системы и должны храниться в онтологии, представляющей собой сеть понятий и отношений предметной области.
Онтологический подход к описанию знаний предметной области
Существует множество определений онтологии, наиболее широко используемым является следующее: «Онтология – это явная спецификация концептуализации» [1]. Здесь концептуализация означает абстрактное представление предметной области. Распространено также определение: «Онтология – общее понимание некоторой области интереса» [2].
Онтология – это формализованные концептуальные знания о предметной области, представленные в форме, допускающей компьютерную обработку и используемые при принятии решений. Концептуальность знаний онтологии означает, что эти знаний формулируются в терминах основных концептов (наиболее общих понятий и отношений), описывающих фрагменты окружающего мира.
Концептуальность знаний онтологии означает, что эти знания формулируются в терминах основных понятий и отношений, описывающих фрагменты окружающего мира.
Онтологии используются в качестве основы базы знаний об основных понятиях предметной области и связях между ними, этим обеспечивается единство терминологии и предоставляется возможность расширения знаний системы в случае появления новых концептов и связей, а также появляется возможность формально специфицировать ситуации в реальности.
Краткий сравнительный анализ баз знаний против баз данных представлен на Рисунке 2.1.
Онтология – это попытка всеобъемлющей и детальной формализации некоторой области знаний с помощью концептуальной схемы. Обычно такая схема состоит из структуры данных, содержащей все релевантные классы объектов, их связи и правила (теоремы, ограничения), принятые в этой области. Этот термин в информатике является производным от древнего философского понятия «онтология». Термин «онтология» используется как для обозначения базы знаний в целом, содержащей описания данных с помощью некоторой концептуальной схемы, так и для обозначения собственно концептуальной схемы, при этом оперативная информация, отражающая текущее состояние объектов, специфицированных с помощью концептов и отношений, выделяется в так называемую «сцену».
В настоящее время онтологии все шире применяются для описания предметных областей и решения сложных задач моделирования, поддержки принятия решений, извлечения знаний и построения мультиагентных систем, при этом размер и сложность онтологий и баз знаний постоянно возрастают. Как правило, для создания таких сложных баз знаний требуется совместная работа нескольких экспертов.
Рассмотрим требования к системе коллективной разработки онтологий, которая обеспечивала бы эффективную формализацию, проверку и использование знаний:
контроль и разрешение противоречащих изменений знания;
обнаружение и устранение ошибок;
обнаружение и устранение избыточности онтологий, генерализация знаний;
нотификация пользователей об изменения в онтологии;
независимость и переносимость отдельных частей онтологий;
распределённость знаний, физическое независимое хранение различных частей онтологий;
протоколирование изменений;
Рисунок 2.1 – Сравнительный анализ баз знаний и баз данных
поддержка историчности, т.е. возможность возврата на предыдущее состояние базы знаний;
устойчивость и надежность хранилища онтологии и базы знаний;
поддержка многопользовательского режима работы с онтологиями в условиях распределённых и неоднородных пользователей: различное географическое положение, различные платформы (Microsoft Win-dows, Linux, MacOS и т.д.);
обеспечение необходимой производительности в случае параллельной работы многих пользователей;
безопасность знаний от несертифицированного доступа;
разделение прав пользователей при работе с базой знаний на уровне онтологий, элементов онтологий, операций над онтологией (просмотр, редактирования, удаление).
В настоящее время для создания и поддержки онтологий существует целый ряд инструментов, которые помимо общих функций редактирования и просмотра выполняют поддержку документирования онтологий, импорт и экспорт онтологий разных форматов и языков, поддержку графического редактирования, управление библиотеками онтологий и т.д. Рассмотрим наиболее известные инструменты инженерии онтологий.
Система Ontolingua была разработана в KSL (Knowledge Systems Laboratory) Стенфордского университета и стала первым инструментом онтологий. Она состоит из сервера и языка представления знаний. Сервер Ontolingua организован в виде набора онтологий, относящихся к Web-приложениям, которые надстраиваются над системой представления знаний Ontolingua. Редактор онтологий – наиболее важное приложение сервера Ontolingua является Web-приложением на основе форм HTML. Кроме редактора онтологий Сервер Ontolingua включает Webster (получение определений концептов), сервер OKBC (доступ к онтологиям Ontolingua по протоколу OKBC) и Chimaera (анализ, объединение, интегрирование онтологий). Все приложения, кроме сервера OKBC, реализованы на основе форм HTML. Система представления знаний реализована на Lisp. Сервер Ontolingua также предоставляет архив онтологий, включающий большое количество онтологий различных предметных областей, что позволяет создавать онтологии из уже существующих. Сервер поддерживает совместную разработку онтологии нескольким пользователям, для чего используются понятия пользователей и групп. Система включает графический браузер, позволяющий просмотреть иерархию концептов, включая экземпляры. Ontolingua обеспечивает использование принципа множественного наследования и богатый набор примитивов. Сохраненные на сервере онтологии могут быть преобразованы в различные форматы для использования другими приложениями, а также импортированы из ряда языков в язык Ontolingua.
Protégé – локальная Java программа, разработанная группой медицинской информатики Стенфордского университета. Программа предназначена для построения (создания, редактирования и просмотра) онтологий моделей прикладной области. Её первоначальная цель – помочь разработчикам программного обеспечения в создании и поддержке явных моделей предметной области и включение этих моделей непосредственно в программный код. Protégé включает редактор онтологий, позволяющий проектировать онтологии разворачивая иерархическую структуру абстрактных или конкретных классов и слотов. Структура онтологии сделана аналогично иерархической структуре каталога. На основе сформированной онтологии, Protégé может генерировать формы получения знаний для введения экземпляров классов и подклассов. Инструмент имеет графический интерфейс удобный для использования неопытными пользователями, снабжен справками и примерами. Protégé основан на фреймовой модели представления знания OKBC (Open Knowledge Base Connectivity) и снабжен рядом плагинов, что позволяет его адаптировать для редактирования моделей в разных форматах (стандартный текстовый, базы данных JDBC, UML, языков XML, XOL, SHOE, RDF и RDFS, DAML+OIL, OWL).
OntoEdit первоначально был разработан в институте AIFB, Университета Karlsruhe (сейчас коммерциализован Ontoprise GmbH) выполняет проверку, просмотр, кодирование и модификацию онтологий. В настоящее время OntoEdit поддерживает языки представления: FLogic, включая машину вывода, OIL, расширение RDFS и внутреннюю, основанную на XML, сериализацию модели онтологии используя OXML. К достоинствам инструмента можно отнести удобство использования; разработку онтологии под руководством методологии и с помощью процесса логического вывода; разработку аксиом; расширяемую структуру посредством плагинов, а также очень хорошую документацию. Так же как и Protégé, OntoEdit – автономное Java–приложение, которое можно локально установить на компьютере, но его коды закрыты. Архитектура OntoEdit подобна Protégé. Существует две версии OntoEdit: свободно распространяемая OntoEdit Free и лицензированная OntoEdit Professional. Естественно, что OntoEdit Professional имеет более широкий набор функций и возможностей (например, машину вывода, графический инструмент запросов, больше модулей экспорта и импорта, графический редактор правил, поддержка формата баз данных JDBC и т.д.).
OilEd – автономный графический редактор онтологий, разработан в Манчестерском университете в рамках европейского IST проекта On-To-Knowledge. Инструмент основан на языке OIL (сейчас адаптирован для DAML+OIL, в перспективе – OWL), который сочетает в себе фреймовую структуру и выразительность дескриптивной логики c сервисами рассуждения. Что позволило обеспечить понятный и интуитивный стиль интерфейса пользователя и преимущества поддержки рассуждения (обнаружение логически противоречивых классов и скрытых отношений подкласса). Из недостатков можно выделить отсутствие поддержки экземпляров.
WebOnto разработан для Tadzebao – инструмента исследования онтологий и предназначен для поддержки совместного просмотра, создания и редактирования онтологий. Его цели – простота использования, предоставление средств масштабирования для построения больших онтологий. Для моделирования онтологий WebOnto использует язык OCML (Operational Conceptual Modeling Language). В WebOnto пользователь может создавать структуры, включая классы с множественным наследованием, что можно выполнять графически. Инструмент проверяет вновь вводимые данные контролем целостности кода OCML. Инструмент имеет ряд полезных особенностей: сохранение структурных диаграмм, раздельный просмотр отношений, классов, правил и т.д. Другие возможности включают совместную работу нескольких пользователей над онтологией, использование диаграмм, функций передачи и приёма и др.
KADS22 – инструмент поддержки проектирования моделей знаний согласно методологии CommonKADS. Онтологии составляют часть таких моделей знаний (другая часть - модели вывода). Модели CommonKADS определены в CML (Conceptual Modeling Language). KADS22 – интерактивный графический интерфейс для CML со следующими функциональными возможностями: синтаксический анализ файлов CML, печать, просмотр гипертекста, поиск, генерация глоссария и генерация HTML.
Онтологический базис, способы представления онтологии
Онтологии могут представляться различным образом:
фреймы
продукции
семантические сети
В разрабатываемой системе предлагается использовать семантические сети, которые образуются классами понятий и отношений, играющих роль связей. В онтологиях (по Аристотелю) можно выделить особые подклассы понятий:
объекты - сущности, характеризуемые состояниями
процессы – изменения состояний объектов
отношения – позволяют конструировать новые объекты
свойства – отражают способность объектов вступать во взаимодействие
атрибуты – позволяют качественно или количественно характеризовать свойства
Примеры классов понятий и отношений:
классы понятий: «Транспортное средство», «Поезд», «Вагон», «Бригада», «Груз»
примеры свойств: Цистерна «Может перевозить» нефть
примеры процессов: «Груз доставляется вагоном потребителю», «Вагоны формируют поезд»
примеры отношений: Груз «находиться» на поезде, груз «забронировал» вагон
примеры атрибутов поезда: «Плановая дата отбытия», «Длительность движения», «Станция назначения», «Скорость движения».
В упрощенном виде фрагмент онтологии РЖД, показывающий примеры используемых понятий и отношений, показан на Рисунке 2.2.
Рисунок 2.2 – Упрощенный фрагмент онтологии РЖД
Для удобства работы с онтологиями выделяют триаду «онтология-модель-сцена»:
онтология описывает понятия и отношения (как толковый словарь), необходимые для описания моделей объектов предметной области РЖД (станций, локомотивов, вагонов и т.д.).
модель описывает устойчивые комбинации понятий и отношений (часть которых для удобства работы конкретизирована, например, модель станции), упрощающие создание формализованных описаний сцен и ситуаций на конкретных станциях.
сцена описывает экземпляры понятий и отношений в заданный момент времени (как набор фактов) необходимые для описания «фотографии» ситуации на каждой конкретной станции с заданным уровнем подробности (включая текущее состояние объектов) в каждый момент времени.
На Рисунке 2.3 показана взаимосвязь между понятиями «онтология предметной области» – «модель проекта» – «сцена».
Рисунок 2.3 – Взаимосвязь между понятиями «онтология предметной области» – «модель проекта» – «сцена»
С использованием онтологии можно специфицировать конкретные факты и строить модели описания ситуаций (сцен) для работы агентов.
Преимущества применения онтологий для управления ресурсами РЖД:
возможности и потребности РЖД постоянно меняются: вводятся новые станции, меняется парк вагонов и локомотивов и т.д. Использование онтологий позволяет минимизировать затраты на внесение таких изменений;
описав отдельными онтологиями (концептами и отношениями) предметные области РЖД, получаем возможность использовать их для построения моделей подразделений РЖД в их конкретных конфигурациях и отражать их состояние сценами («моментальными фотографиями» экземпляров объектов и отношений);
такой подход позволит отделить знания об объектах и их связях от программного кода системы и пополнять описания мира подразделений РЖД по мере необходимости, без перепрограммирования системы в каждом случае, например в следующем случае:
Предположим, что планируется ввести класс локомотивов, который требует новых запчастей и ремонтов, расходных материалов и т.д. Для этого необходимо ввести в онтологию новый объект и описать, что этот класс локомотивов требует (через специальное отношение «нуждается-в») указанных видов ремонта и запчастей, причем следует образовать базовые подклассы данного отношения, для которых можно задавать, какие ресурсы и в каком количестве нужны для планового ремонта (работники, детали), с какой регулярностью проводятся ремонты и т.д.
Тогда агент нового локомотива сможет прочитать из онтологии конкретную специфику потребностей данной машины, создаст под них связанных агентов, которые будут планировать и поставлять необходимые ресурсы к нужному сроку.
В этом случае придется допрограммировать систему только в случае возникновения непредвиденных ранее новых подклассов данного отношения, причем после такого дополнительного введения соответствующее отношение пополнит общую библиотеку отношений и станет доступным для всех подобных ситуаций.
С использованием онтологии можно специфицировать конкретные факты и строить модели описания ситуаций для работы агентов
Сцены используются для представления и обработки оперативной информации о ситуациях, являясь «фотографией» («зеркалом») реальности, что позволяет системе иметь в любой момент времени формализованное описание ситуации в выбранном фрагменте реальности, используемой для принятия решений агентами.
Онтология включает машинно-интерпретируемые формулировки основных понятий предметной области и отношения между ними.
Для представления онтологии и сцен используется семантическая сеть, которая состоит узлов и упорядоченных отношений (связей), соединяющих эти узлы. Узлы выражают понятия или предположения, а связи описывают взаимоотношения между этими узлами.
Использование онтологий, моделей и сцен нужно, прежде всего, для того, чтобы стало возможным формализовывать, специфицировать, накапливать, изменять знания, используемые при автоматизированном принятии решений. Действительно, многие объекты и связи между ними, а также списки свойств и атрибутов в процессе работы постоянно меняются и можно предложить описывать предметные области отдельными онтологиями, которые потом использовать для построения моделей в конкретных конфигурациях, и отражать состояние реальности сценами («моментальными фотографиями») объектов и отношений с нужным уровнем детальности.
Это позволит отделить знаний об объектах и их связях от программного кода системы и пополнять описания мира автоматизируемого объекта по мере необходимости, без перепрограммирования системы в случае изменений, и использовать эти знания для описания ситуаций.
Структура онтологии инфраструктуры РЖД
Базовые классы
Ниже приведено описание структуры онтологии инфраструктуры РД, представляющее собой формализованное описание предметной области в виде классов.
Разработана структура онтологии для описания основных концептов и отношений предметной области, концепт характеризуется свойствами (атрибутами).
Направление – концепт описывает направление железной дороги.
Атрибуты:
начальный пункт,
конечный пункт,
протяженность,
количество путей,
движение поездов.
Движение поездов – концепт описывает поезда, проходящие по направлению железной дороги.
Атрибуты:
тип поезда,
количество поездов в сутки.
Путь |
