Представление знаний в СППР СОМТИ

Онтология системы состоит из двух взаимосвязанных онтологий — онтологии предметной области и онтологии задач [Guarino, 1998].

Онтология ПО описывает модель предметной области в виде понятий и отношений между ними (см. рис.2). Базовыми понятиями (классами) онтологии ПО являются: Объект, Нормативно-справочный объект, Состояние, Результат.

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

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

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

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

Результатами работы СППР являются Диагнозы состояния оборудования и подвижных объектов, Рекомендации для ЛПР, Прогнозы изменения состояния объектов, решения транспортных задач (Маршруты движения автотранспорта), скорректированные Графики ремонтов и т. п. Отдельным результатом может быть порожденная исполняемым модулем поддержки принятия решений Задача, в которой, например, более детально анализируется тот или иной объект.

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

Для описания задачи вводится понятие (класс) Задача, имеющий атрибуты «Имя задачи» и «Параметры задачи».

Последний атрибут представляет собой множество пар вида, где Csd — класс онтологии ПО, Lo — список имен объектов класса Csd, для которых должна быть решена данная задача. Если Lo — не задано (пусто), то считается, что задача решается для всех объектов класса Csd.

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

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

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

Атрибут «Входные данные» определяет множество типов (классов) объектов, необходимых для функционирования модуля. Значение атрибута имеет вид, где Cin — множество классов онтологии ПО, Rin — множество отношений онтологии ПО, заданных на классах Cin, Ain — множество ограничений на значения атрибутов объектов классов из Cin. Ограничения Ain служит для фильтрации объектов, для которых необходимо решить задачу. Если модуль реализует задачу, у которой есть параметры, то параметры задачи добавляются к множеству ограничений Ain.

Атрибут «Выходные данные» определяет множество классов, объекты которых могут быть созданы модулем в качестве результатов его работы.

Атрибут «Решатель» задает имя программной системы, которая будет исполнять данный модуль поддержки принятия решений.

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