CC BY
20
УДК 004.31
ЕДИНАЯ ИНФОРМАЦИОННАЯ СРЕДА ПРОЕКТИРОВАНИЯ ОБЪЕКТОВ ТЕПЛОЭНЕРГЕТИКИ
Кроль Т.Я., канд. техн. наук, Ильичев Н.Б., канд. техн. наук, Крылов М.В., асп.
Рассматривается технология организации единой проектной базы данных при проектировании сложных электротехнических объектов. Приводится математическая модель базы и ее декомпозиция до уровня основных подмоделей.
Процесс проектирования и последующего сопровождения электростанций очень емкий, и по времени и по затратам. В условиях конкуренции между проектными организациями существенно возрастают требования к снижению сроков и повышению качества проектирования, кроме того, сам процесс проектирования оказывается неразрывно связанным с окружающими его денежными, материальными и информационными потоками (оплата работ, приобретение оборудования, процессы опережающего монтажа, изменение нормативно-справочной и номенклатурной базы). Следовательно, информационная технология, поддерживающая процесс проектирования электротехнических объектов должна охватывать весь процесс проектирования, включая такие его аспекты, как единое информационное пространство для проектирующих систем, документооборот процесса проектирования, график выполнения проектных работ, оборудование проекта, нормативно-справочную и номенклатурную информацию.
Многочисленные попытки разработать единую систему, обеспечивающую охват всего процесса проектирования, не завершились успехом по причинам заведомой громоздкости таких систем и необходимости объединения в них лучших прикладных функций узко-ориентированных САПР (расчет токов короткого замыкания и уставок защитных аппаратов, оптимальная раскладка кабелей, расчеты трубопроводных систем и т.п.).
Существующие на рынке PDM системы имеют успешное внедрение при машиностроительном проектировании, но при проектировании сложных промышленных объектов пока еще не создано системы, полностью удовлетворяющей потребности проектных организаций. В настоящее время на каждом этапе проектирования, в основном, используется своя САПР или расчетная система. Этот факт порождает ряд проблем, связанных с отсутствием единого информационного пространства проекта:
• отсутствие цельного представления о процессе проектирования (степени готовности, текущем состоянии, актуальности проектных документов, смете проекта и ее исполнени и т. п .);
• невозможность анализа всей совокупности проектной информации (например, получение совокупного количества оборудования данного типа, в том случае если описание оборудования порождается несколькими САПР);
• сложность принятия унифицированных решений и уменьшения номенклатуры покупных изделий.
Это не может не сказаться на эффективности процесса проектирования. Под эффективностью в данном случае понимаются: трудозатраты; временной фактор; корректность данных; человеческие и машинные ошибки. Следовательно, неизбежным становится объединение различных САПР.
Первый способ - так называемая последовательная интеграция Систем в единую цепочку проектирования и сопровождения (рис. 1).
Система 1 Система 2 ь ь Система N
-Р 4- *- "' —
Рис.1
В основном интеграция сводится к передаче информации между САПР с определенной периодичностью по определенному событию или, чаще всего, по команде проектировщика, который должен определить степень готовности информации к передаче.
При этом достигается «сквозная» автоматизация процесса проектирования без повторного ввода данных, но не решаются перечисленные выше проблемы.
Кроме того, с течением времени некоторые САПР могут заменяться или удаляться, а также могут возникать новые проектирующие системы и их версии. В этих случаях инвестиции, потраченные на процесс интеграции, пропадают и приходится идти на новые затраты времени и ресурсов. Выполнять работу по объединению САПР приходится в жестких временных рамках, в условиях промышленного функционирования систем, что чаще всего приводит к созданию частных решений по каждому направлению. При этом растет число «заплаточных» решений и, что особенно неприятно, существенно растут трудозатраты по поддержке модулей в работоспособном состоянии при их изменении. В этой ситуации проектным организациям приходится создавать |Т-службы, зачастую соизмеримые по количеству сотрудников с основным персоналом.
Существуют еще и дополнительные сложности:
• САПР могут функционировать на разных программно-аппаратных платформах (операционная система, СУБД). В связи с этим возникают проблемы межплатформенного взаимодействия.
• САПР зачастую реализованы в различных архитектурах («файл-сервер», «клиент-сервер»). Это приводит к необходимости применять различные технологии доступа к данным.
• САПР нередко содержат одинаковые информационные объекты, выполненные в различных логических структурах. Например, представления о параметрах электротехнического оборудования в разных системах значительно различаются.
В связи с вышеизложенным предлагается использование параллельной модели, соответствующей принципам СА1_Э/ИПИ технологии (рис. 2). В этом случае обмен информацией происходит не напрямую между САПР, а через единую базу данных проекта (ПБД). Таким образом, создается единая информационная среда проектирования, обеспечивающая решение обозначенных выше проблем и возможность замены САПР без разрушения процесса проектирования в целом.
Рис. 2
Единая информационная среда проектирования должна быть основой для хранения информации: об объекте проектирования; проектной документации; используемом оборудовании; плане и состоянии исполнения проекта; структуре проектной организации и персональной ответственности проектировщиков и т.п.
В данной статье описывается модель единой информационной среды проектирования объектов энергетики (ПБД), отвечающая поставленным задачам (рис. 3):
Мпбд =\Моп и мк и МПр и Моб и мд0 и М(
( 1 )
^СистемаГ^ ^Система2^
С
Сси™^
Система синхронизации данных
----Ж
3
П Б Д
Рис. 3
Каждая модель, входящая в состав Мпбд, обеспечивает работу определенной группы данных. Рассмотрим модели подробнее.
Модель Моп (2) описывает объект проектирования с точки зрения следующей иерархии: для каждого объекта может быть разработано несколько проектов, охватывающих создание зданий и сооружений; у зданий есть строительные элементы и помещения, которые обладают такими свойствами как пожаробезопасность, взрыво-безопасность и т.д.:
Моп = f (ОЬьР,Б,Я ),
(2)
где ОЬ - описание объекта проектирования;
Р - проекты в рамках объекта проектирования;
В - здания и сооружения объекта;
Р - помещения внутри комплексных сооружений.
Модель Мк формализует представление об организационной структуре (отделах и подотделах) проектной организации, персональном составе сотрудников и занимаемых ими должностях. Таким образом осуществляется связь между проектной информацией и ответственными за нее сотрудниками организации:
Мк = f (8,РЬ,Б),
(3)
Исходя из сложности и объема, модель разделена на следующие составляющие:
модель объекта проектирования (Моп); модель кадрового состава проектной организации (Мк);
модель структуры проекта (Мпр); модель учета каталогов оборудования (в связке с проектами) (Моб);
модель связанного с проектом документооборота
(Мдо);
модель синхронизации с Системами проектирования (Мсс).
Модель синхронизации с Системами проектирования должна являться объектом отдельного рассмотрения, т.к. она не зависит от внутренней структуры хранения данных в ПБД. Однако Мсс имеет унифицированные точки соприкосновения с ядром Мпбд для того, чтобы при изменении структуры хранения данных или методов синхронизации сохранялось взаимодействие систем и работоспособность процесса проектирования.
где Э - структура организации (отделы и подотделы);
РИ - список физических лиц организации;
О - распределение сотрудников по должностям.
Учет проектных документов ведется по следующей схеме. Начальная точка - проект. Проект состоит из Блоков проекта - это привязанные к Генплану части проектируемого объекта. В каждом блоке находится группа зданий и сооружений, внутри каждого из которых ведутся работы по проектированию. В ходе выполнения каждой проектной работы (этапа проекта) формируется пакет документов (чертежей, спецификаций, пояснительных записок и т.п.).
Математически эти зависимости могут быть представлены моделью Мпр:
Мпр = f (Р, И, Бг) ,
(4)
где Р - проект;
и - блоки проекта (функциональные блоки, разбивка по генплану);
РР - разделы проекта (разбивка по специальностям внутри организации); Е - подрядчики и субподрядчики; W - комплекты чертежей (разбивка разделов проекта по подрядчикам и плану работ); Ог - чертежи.
Модель документооборота Мдо включает в себя описание взаимосвязей всех проектных (от проекта до чертежа) и сопроводительных документов (письма). Состояние каждого документа описывается его статусом (разрабатывается, разработан, согласован). Предусмотрена схема формального описания допустимого порядка следования статусов. Например, после статуса "отправлен на согласование" может следовать статус "согласован" или статус "требуется переделка". А статус "согласован" может следовать только за статусом "отправлен на согласование", но не может следовать за статусом "разработан". Переход проектных документов из одного состояния в другое происходит на базе сопроводитель-
ных документов (писем), электронный вид этих документов также помещается в базу данных. Каждый документ может быть помечен как взятый конкретным пользователем для изменения, измененный вариант опять должен быть помещен в базу. Таким образом в базе хранится история изменений документов. Все эти моменты упрощенно представлены формулой ( 5 )
Мдо = f (Sw,Sd,L,Sl),
( 5 )
где Sw - статусы комплектов чертежей;
Эс1 - статусы чертежей;
I_ - сопроводительные письма;
Sl - статусы сопроводительных писем.
Традиционный подход к решению проблемы хранения и учета оборудования предполагает хранение информации о каждом из видов оборудования в отдельной таблице, структура которой определяется набором параметров конкретного оборудования. Т.е. информация о моторах хранится в таблице моторов, о кабелях - в таблице кабелей, о нагревателях - в таблице нагревателей и т.д. Структура подобной базы данных получается «узкоспециализированной» и порождает ряд проблем:
• для добавления нового типа (класса) оборудования необходимо менять структуру базы данных;
• при изменении набора параметров данного класса оборудования также необходимо менять структуру базы данных;
• возникают сложности при составлении отчетов и спецификаций;
• при изменении состава или параметров оборудования появляется необходимость перепрограммировать разработанные приложения, отчеты, запросы и спецификации.
В связи с вышеизложенным была предложена иная схема хранения устройств, использующихся в объекте проектирования, и их характеристик. Описание оборудования в этой схеме предполагается хранить в одной таблице, а параметры устройств помещать в связанные сущности базы данных. Это обеспечит универсальность системы и позволит упростить операции по выбору и вводу устройств в систему.
Основой этой схемы является модель Моб, формализующая описание оборудования и его параметров. Учет оборудования можно представить следующей схемой:
М0б = {пм0 и ПМП
U пмпар}
( 6 )
Справочник параметров оборудования содержит список всех возможных названий и описаний характеристик устройств, хранимых в системе (например, цвет, размер, мощность, координаты на чертеже и т.д.).
Каждый из параметров может быть отнесен к одному из следующих типов:
• текстовый;
• числовой;
• из справочника.
В специальном справочнике хранится всеобъемлющий перечень значений параметров (белый цвет, зеленый цвет, 220В, 380В, переменный ток, постоянный ток и т.п.), который фильтруется по конкретной группе значений, например отбираются только возможные варианты цветов или только возможные варианты напряжений.
Представим схему описания параметров (характеристик оборудования) в виде формулы
ПМ = f (Par, Ed, T, PClass, PVal),
( 7 )
где Par - каталог названий параметров;
Ed - единица измерения параметра;
T - тип параметра (число, текст, из справочника);
PClass - класс значений параметра (если тип - из
справочника);
PVal - список значений параметра (если тип - из
справочника).
В модели учтено, что конкретное оборудование может быть «потребителем» (потреблять электрическую, тепловую и др. энергии), а также быть «измерением» (измерять ток, напряжение, мощность и т.д.).
«Потребителям» присущ собственный набор параметров (pARcons):
• что потребляет;
• объем потребления;
• и т. д.
Свой набор параметров может быть и для «измерений» (PARmeas):
• диапазон измерений;
• точность;
• и т. д.
Соответственно, оборудование объекта проектирования имеет набор параметров (PARo^)
PARob = {PARciass U PARmeas U PAR,
}
cons f>
(8)
где ПМпар -модель учета параметров (характеристик) оборудования ;
ПМо -модель учета экземпляров оборудования;
ПМто -модель учета типового оборудования.
Для того чтобы определить, какие конкретно параметры могут и должны быть у конкретного оборудования, предусматривается следующий алгоритм настройки.
Все оборудование разделяется на классы. Классы оборудования (электромотор, кабель, арматура, датчик и т.д.) используются для определения набора параметров оборудования, принадлежащего к данному классу (PARclass). Для класса электродвигателей задается набор: ток, мощность, момент; для класса кабелей - количество жил, длина, сечение и т.д. Получился аналог «узкоспециализированным» таблицам в традиционной схеме с тем отличием, что добавлять новые классы устройств и менять набор параметров теперь можно пользователю без изменения структуры базы данных.
где PARc|ass - параметры, относящиеся к данному классу оборудования; PARmeas - параметры, относящиеся к
данному классу (данным классам) потребителей; PARcons - параметры, относящиеся к данному классу
(данным классам) измерений.
Для облегчения учета оборудования с одинаковым набором характеристик (параметров) в подсистему оборудования введена функция хранения типовых устройств, т.е. хранится информация не просто об асинхронном электродвигателе, а об асинхронном электродвигателе типа 4А160 ярославского завода. Структура описания типовых устройств аналогична структуре описания оборудования и связана с теми же алгоритмами настройки.
Проект электротехнического устройства предусматривает разработку различных (электрических, информационных, логических) связей между оборудованием, которые можно представить в виде набора из трех устройств:
• оборудование-начало связи;
• оборудование-конец связи;
• оборудование-связь.
Модели экземпляра оборудования ПМо и типового оборудования ПМто можно представить:
ПМ о = f (О, VPar, Link, Class, Meas, Cons ); (8 ) ПМто = f(0T, VParT, LinkT, Class, Mea%, ConsT) (9)
где индекс Т - номенклатурные списки; O - оборудование;
VPar - значения параметров (ссылаются на справочник «Название»);
Link - связи между оборудованием;
Class - принадлежность классу оборудования;
Meas - список измерений, проводимых прилагатель-
но к оборудованию;
Cons - вид энергии, потребляемой оборудованием.
Таким образом, модель Моб представляет собой универсальное описание оборудования в проекте, его параметров и взаимосвязей.
А модель ПБД в целом может являться основой создания единой среды проектирования, обеспечивающей высокий уровень интеграции проектных данных и необходимый уровень информационной открытости системы (возможность добавления новых видов оборудования, новых параметров оборудования, новых схем вложенности оборудования, новых схем движения документов и т.п.).
Литература
1. Д. Мейер. Теория реляционных баз данных: Пер. с англ. - М.: Мир, 1987. - 608 с.
2. Разработка информационно-управляющих систем WWW-WorkFlow в инструментальной среде РДРИУС / Т.Я. Кроль, Е.Р. Пантелеев, Е.А. Бабасин и др. Образовательные технологии: Межвуз. сб. науч. тр. Вып.7. - Воронеж: ВГПУ, 2001. - С.172-178.
3. Кроль Т.Я., Пантелеев Е.Р. Технология разработки и эксплуатации корпоративных информационно-управляющих систем в среде РДйИУС. Конструкторско-технологическая информатика - 2000: Тр. IV международного конгресса. - Москва, СТАНКИН, 2000. - Т.1. - С. 307-308.
4. Модин А.А. и др. Справочник разработчика АСУ. - 2-е изд., перераб. и доп. - М.: Экономика, 1978. - 583 с.
5. Чумаков В. Анализ + проектирование + разработка прототипа прикладной системы с помощью Designer/2000 // Русское издание Oracle Magazine. - 1997. - № 3(5).
