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

Полный текст

Введение

В настоящее время трубопроводные системы (ТПС) энергетики (тепло-, водо-, нефте-, газоснабжения и др.) представляют собой инженерные сооружения, отличающиеся большими размерами и сложностью. В работах [1, 2] заложены основы теории гидравлических цепей (ТГЦ). Один из основных принципов ТГЦ заключается в том, что разрабатываемые методы и алгоритмы должны допускать применение их для расчёта ТПС различных типов и назначений. Возможность создания таких методов и алгоритмов обусловлена общностью топологических свойств ТПС и законами сохранения массы и энергии. Объектом исследования ТГЦ в основном являются следующие типы ТПС: централизованные теплоснабжающие системы (ТСС), системы холодоснабжения, системы водоснабжения, системы газоснабжения, системы нефтеснабжения.

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

В ИСЭМ СО РАН разрабатываются методические подходы к построению ПО для компьютерного моделирования ТПС. Применение ПО в процессе проектирования требует высокой гибкости его построения, что обусловлено необходимостью моделирования широкого набора оборудования, а также методов и алгоритмов, настраиваемых на конкретную задачу. Знания о различных типах ТПС необходимо сохранить в форме, пригодной для многократного использования при автоматизации построения ПО и управлении вычислительным процессом при решении проектных задач. Для этого необходимо организовать хранение знаний в виде онтологий. В настоящей статье излагается новый подход к построению системы онтологий и приведено описание его составляющих, представлена архитектура программной системы для решения задач проектирования ТПС различных типов и назначений.

1. Постановка задачи

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

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

 

Рисунок 1 – Составляющие моделирования трубопроводных систем

 

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

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

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

Применение онтологий обеспечит получение следующих результатов:

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

2. Обзор литературы

В настоящее время онтологии находят применение в энергетике для описания сложных объектов. В работе [3] рассматривается идея разработки онтологии открытой энергетики для анализа энергетических систем. Исследование в [4] посвящено разработке онтологии, которая содержит описание объектов, относящихся к структурам энергетических сетей и цепочкам спроса и предложения. Предлагаемая онтология описывается с использованием синтаксиса дискрипционной логики, а для её реализации используется язык OWL2. Основным результатом работы [5] является разработка онтологии, которая объединяет основные концепции, необходимые для интерпретации всей доступной информации, связанной с рынками электроэнергии. Особенности применения онтологии как основы для формирования информационных моделей в составе цифровых двойников объектов управления интеллектуальной распределённой энергетики представлены в работе [6]. Онтологическое моделирование при управлении децентрализованными данными в интеллектуальных энергетических системах рассмотрено в статье [7]. В статье [8] описан фрактальный подход к структурированию знаний, активно используемый для разработки онтологического пространства знаний в области энергетики. В статье [9] представлены онтологии, отражающие основные понятия ситуационного управления, включая ситуационный анализ и ситуационное моделирование, а также вариант онтологии ситуации, рассмотренной с позиции исследования проблемы энергетической безопасности.

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

В программной инженерии активно развиваются концепции, в которых модели ПрО рассматриваются как информационные ресурсы, позволяющие автоматически создавать и развивать программные системы (Model-Driven Engineering, MDE) [11]. В статье [12] представлен детальный обзор MDE, в котором даны определения модели, метамодели, языка моделирования, программной платформы и программного продукта. Предметно-ориентированные языки (Domain-Specific Language, DSL) позволяют создавать детальные описания ПрО, которые можно использовать при автоматизации этапов построения ПО [13, 14]. В методологии программной инженерии (Ontology Driven Software Engineering, ODSE) [15, 16] онтология используется на каждом этапе разработки ПО. Использование онтологии на разных этапах отличается по полезности и простоте. В работе [17] показана возможность комплексного использования онтологии. Использование онтологий на всех этапах разработки ПО даёт стратегическое преимущество в расширении обмена и поиске знаний.

В работе [18] предлагается подход к построению ПО для проектирования ТСС на основе концепции MDE. Используются технологии метапрограммирования и знания о ПрО в виде онтологий. Приведено описание программного комплекса СОСНА, разработанного на базе изложенного подхода. Программная система строится в автоматизированном режиме с использованием знаний из онтологической системы на основе программных компонентов, реализующих методы и элементы моделируемой ТСС.

3. Подход к построению онтологий

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

 

Рисунок 2 – Схема процесса автоматизированного построения ПО

 

Иерархическая модель ТПС, описание решаемой проектной задачи и программные компоненты, реализующие методы и модели, интегрируются в контексте моделирования конкретной ТПС. Для автоматизации интеграции модели ТПС используется описание класса моделируемой ТПС из соответствующей этому классу онтологии ТПС. Используемое описание позволяет определить: из каких типовых элементов состоит ТПС данного класса, какими параметрами они обладают, из какого оборудования они строятся. Описание задачи из онтологии задач позволяет определить: какую методику необходимо использовать для решения задачи проектирования, какие методы используются в процессе решения. Описание программных компонентов из онтологии ПО позволяет определить: какие программные компоненты будут использоваться, с помощью каких технологий они реализованы, как обеспечить доступ к этим компонентам. Концепция MDE позволяет выполнить реализацию предлагаемого решения при автоматизации построения ПО для проектирования ТПС.

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

• состав онтологий;
• инструментальные средства реализации онтологий;
• методику построения метаонтологии;
• методику построения онтологий ТПС конкретных классов;
• методику построения онтологий задач;
• методику построения онтологий ПО.

В состав онтологий входят следующие: метаонтология, онтологии ТПС конкретных классов, онтологии проектных задач и онтологии ПО.

Метаонтология вводит единое пространство для создания языка описания прикладных онтологий и содержит описание иерархической структуры построения ТПС.

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

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

Онтологии ПО. Онтология ПО предназначена для хранения знаний, необходимых для автоматизации построения и использования ПО. Эта онтология содержит описание:

• программных компонентов, реализующих методики, методы и алгоритмы;
• программных компонентов, реализующих модели элементов ТПС;
• программных компонентов, предназначенных для решения конкретных классов задач;
• технологий и интерфейсов доступа к программным компонентам.

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

Методика построения метаонтологии включает следующие этапы.

1. Вводится понятие «Тип данных» и определяются конкретные используемые при моделировании ТПС типы данных.
2. Определяются базовый класс «Трубопроводная система», который состоит из «Элементов», обладающих «Атрибутами».
3. Вводятся определения классов «Узлы» и «Ветви», на которые подразделяются «Элементы» ТПС.
4. Вводится определение класса «Параметр», который в ТГЦ соответствует «Атрибуту».
5. Вводится определение класса «Иерархическая модель» ТПС, которая отражает «Структурную конфигурацию» и может быть «Древовидной» или «Кольцевой». «Иерархическая модель» описывает набор «Элементов» конкретной моделируемой ТПС.
6. Вводится определение класса «Проектная задача», обладающего «Входными данными» и «Выходными данными», которые включают в себя «Параметры» элементов моделируемой ТПС.
7. Вводится определение класса «Модель», реализующего один из «Элементов» ТПС.
8. Вводится определение класса «Метод».
9. Вводится определение класса «Методика», которая решает «Проектную задачу» и использует «Метод».
10. Вводится определение класса «Программный компонент», который может реализовать один из следующих классов: «Методика», «Метод» или «Модель» элемента ТПС.

В соответствии с предложенной методикой вводятся базовые понятия ПрО (см. рисунок 3). Концепт «Трубопроводная система» состоит из «Элементов», обладающих «Атрибутами», которые в ТГЦ называются «Параметрами». Для автоматизации работы с параметрами вводится описание их «Типов данных», включающих «Целые числа», «Числа с плавающей точкой», «Текстовые данные» и др. Решаемая «Проектная задача» имеет «Входные данные» и «Выходные данные», включающие «Параметры» элементов моделируемой системы. Для решения «Проектной задачи» используется «Методика», реализованная в «Программном компоненте».

 

Рисунок 3 – Базовые понятия предметной области

 

«Трубопроводная система» состоит из «Элементов», которые подразделяются на «Узлы» и «Ветви» (см. рисунок 4). «Трубопроводная система» представляется «Иерархической моделью», отражающей «Структурную конфигурацию», которая может быть «Древовидной» или «Кольцевой». «Программные компоненты» включают программные реализации «Моделей», соответствующих «Элементам», и «Методов», используемых «Методиками». «Проектные задачи» учитывают «Структурную конфигурацию».

 

Рисунок 4 – Фрагмент метаонтологии теплоснабжающей системы

 

Методика построения онтологии ТПС конкретного типа включает следующие этапы.

1. Вводится определение класса с названием, соответствующим конкретному типу ТПС.
2. Вводятся определения классов, соответствующих составу «Узлов» для описываемого типа ТПС.
3. Вводятся определения классов, соответствующих составу «Ветвей» для описываемого типа ТПС.
4. Для каждого из классов, определённых на этапах 2 и 3, определяются его «Параметры», для которых указываются «Название», «Тип данных», «Ограничения».
5. Для каждого из классов, определённых на этапах 2 и 3, определяется «Перечень оборудования», используемого при построении определяемого типа ТПС, и описываются его «Характеристики».

Методику построения онтологий ТПС конкретного типа можно показать на примере онтологии ТСС (см. рисунок 5). Эта онтология предназначена для описания построения иерархической модели ТСС и позволяет получить информацию о том, какие типы элементов образуют «Теплоснабжающую систему», какими «Параметрами» обладают «Элементы» и какие «Типы данных» соответствуют «Параметрам». Например, таким элементом является «Источник», обладающий «Напором», «Расходом» и «Геодезической высотой»; «Трубопроводный участок» является «Ветвью» и обладает такими параметрами, как «Потеря напора», «Расход» и «Диаметр».

 

Рисунок 5 – Фрагмент онтологии теплоснабжающей системы

 

Методика построения онтологии проектных задач включает следующие этапы.

1. Вводится определение класса задачи с соответствующим ей названием.
2. Вводится описание «Входных данных» задачи с указанием «Параметров» и их принадлежности конкретным «Элементам» ТПС.
3. Вводится описание «Выходных данных» задачи с указанием «Параметров» и их принадлежности конкретным «Элементам» ТПС.
4. Вводятся определения классов, описывающих «Методики» решения определяемой задачи.
5. Вводятся описания созданных на предыдущем этапе классов, описываются «Методы», используемые каждой из «Методик», и устанавливаются их «Условия применения».
6. Выполнение этапов 1–5 повторяется, пока не будут определены все классы решаемых задач.

На рисунке 6 приведён фрагмент онтологии задач, который содержит описание задачи оптимизации диаметров трубопроводов ТПС. Вводится концепт задачи «Оптимизация диаметров». «Входными данными» для её решения является «Модель ТПС», а «Выходными данными» – «Диаметры трубопроводов». «Модель ТПС» отражает «Структурную конфигурацию», которая определяет «Метод решения» задачи.

 

Рисунок 6 – Фрагмент онтологии задач

 

Методика построения онтологии ПО включает следующие этапы.

1. Вводятся определения классов, соответствующих «Программным компонентам», реализующим «Методики» решения «Проектных задач».
2. Для каждого из определённых на предыдущем этапе классов описываются необходимые для использования соответствующего компонента характеристики: «Версия», «Технология доступа» и «Язык реализации».
3. Вводятся определения классов, соответствующих «Программным компонентам», реализующим «Методы» решения «Проектных задач».
4. Для каждого из определённых на предыдущем этапе классов описываются необходимые для использования соответствующего компонента характеристики: «Версия», «Технология доступа» и «Язык реализации».
5. Реализуется иерархическое описание классов «Модели» ТПС. Для этого исходное множество реализаций «Моделей» разбивается на подмножества в соответствии с типом ТПС.
6. Для каждого из полученных на предыдущем этапе подмножеств выполняется определение соответствующих им классов «Программных компонентов», для каждого из которых задаются «Формула», «Технология доступа» и «Язык реализации».

На рисунке 7 представлен фрагмент онтологии ПО, содержащий описание программных компонентов. «Программные компоненты» включают «Реализации моделей ТПС» и «Реализации методов». «Реализации моделей ТПС» включают реализацию моделей «Стальных трубопроводов». Модель «Стального трубопровода» обладает «Формулой», «Технологией доступа» и «Языком реализации». «Реализации методов» включают реализацию «Линейного программирования» в виде компонента «LpSolve». Этот компонент обладает «Версией», «Технологией доступа» и «Языком реализации».

 

Рисунок 7 – Фрагмент онтологии программного обеспечения

 

4. Практическое применение

Основными составляющими разрабатываемой программной платформы являются следующие: компоненты, управляющие работой других программных компонентов; компоненты, реализующие математические методы и алгоритмы; компоненты для доступа к базам данных; онтологии (метаонтология, онтологии конкретных типов ТПС, онтологии ПО, онтологии задач). Java является основным языком программирования для реализации платформы. Отдельные программные компоненты могут быть реализованы на языках C/C++, Fortran, Python и др. Для хранения онтологий используется предметно-ориентированный язык, разработанный на основе языка описания данных XML.

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

 

Рисунок 8 – Архитектура многопользовательской сетевой программной системы

 

Основные подсистемы разрабатываемой программной системы.

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

Использование онтологий при решении конкретной проектной задачи рассмотрено на примере оптимизации диаметров трубопроводов ТСС.

На основе онтологии ТСС автоматически определяется: из каких элементов состоит моделируемая система (см. рисунок 5); какие данные по её параметрам необходимо загрузить из базы данных. После загрузки данных автоматически строится иерархическая модель ТСС. По описанию решаемой задачи из онтологии задач определяется необходимая для использования методика. По описанию методики устанавливается связь между структурной конфигурацией ТСС и необходимым для решения задачи методом (см. рисунок 6). Далее загружается описание необходимых программных компонентов из онтологии ПО (см. рисунок 7), на основе которого определяются необходимые программные компоненты (реализации методики, методов и моделей элементов) и автоматически интегрируются в программную систему. После построения вычислительной подсистемы организуется вычислительный процесс решения прикладной задачи (см. рисунок 1).

Заключение

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

Об авторах

Валерий Алексеевич Стенников

Институт систем энергетики им. Л.А. Мелентьева Сибирского отделения РАН (ИСЭМ СО РАН)

Email: sva@isem.irk.ru
ORCID iD: 0000-0001-6219-0354
Scopus Author ID: 6508326526

1954 г. рождения, доктор технических наук (2002 г.), профессор. Академик РАН (2022 г.). Окончил Иркутский политехнический институт. Специалист в области теоретических основ, моделирования, расчёта, оптимизации, управления развитием и функционированием систем энергетики, автор более 250 научных работ, из них 14 монографий. Заслуженный деятель науки Российской Федерации (2011 г.). Лауреат Премии Правительства РФ в области науки и техники (2016 г.).

Россия, Иркутск

Евгений Алексеевич Барахтенко

Институт систем энергетики им. Л.А. Мелентьева Сибирского отделения РАН (ИСЭМ СО РАН)

Автор, ответственный за переписку.
Email: barakhtenko@isem.irk.ru
Scopus Author ID: 55229371000
ResearcherId: Q-7173-2016

 1982 г. рождения. Окончил Иркутский государственный технический университете в 2005 г., к.т.н. (2011). Старший научный сотрудник ИСЭМ СО РАН. Лауреат Премии Правительства РФ в области науки и техники для молодых ученых (2016 г.). Область научных интересов: математические модели и методы управления развитием трубопроводных систем энергетики и интегрированных энергетических систем, цифровое проектирование. Автор и соавтор более 150 научных работ.

Россия, Иркутск

Дмитрий Витальевич Соколов

Институт систем энергетики им. Л.А. Мелентьева Сибирского отделения РАН (ИСЭМ СО РАН)

Email: sokolov_dv@isem.irk.ru
Scopus Author ID: 57190607698
ResearcherId: K-6737-2018

1984 г. рождения. Окончил Иркутский государственный аграрный университет имени А.А. Ежевского в 2008 г. по спец. «Прикладная информатика (в экономике)», к.т.н. (2013), с.н.с. ИСЭМ СО РАН. Лауреат Премии Правительства РФ в области науки и техники для молодых ученых (2016 г.). В списке научных трудов более 100 работ в области разработки алгоритмов оптимизации трубопроводных систем и автоматизации программирования.

Россия, Иркутск

Глеб Сергеевич Майоров

Институт систем энергетики им. Л.А. Мелентьева Сибирского отделения РАН (ИСЭМ СО РАН)

Email: mayorovgs@isem.irk.ru
ORCID iD: 0000-0002-7405-1965
Scopus Author ID: 57211071672

1994 г. рождения. Окончил Иркутский национальный исследовательский технический университет в 2018 г., м.н.с. ИСЭМ СО РАН. Область научных интересов: интегрированные энергетические системы и методы для решения задач их проектирования, мультиагентный подход и его применение. В списке научных трудов более 20 работ.

Россия, Иркутск

Список литературы

Дополнительные файлы