Как это было: внедрение E³.series в группе КИПиА Проектного Управления ООО «ПО «Киришинефтеоргсинтез»

Денис Семенов

Почему именно система E3.series

Что изменилось после внедрения E3.series

Редактирование/создание собственных форматок листов

Добавление новых типов схем

Создание шаблонов надписей атрибутов

Доработка скриптов WBS

Дополнение графических возможностей Е3.series

О наших планах

ООО «КИНЕФ» (Производственное объединение «Киришинефтеоргсинтез») входит в состав нефтяной компании «Сургутнефтегаз». Это один из крупнейших нефтеперерабатывающих заводов в России. Мощность завода по переработке нефти составляет 19 млн т в год — по данному показателю КИНЕФ занимает третье место по России. А по объему переработанной нефти на протяжении последних лет завод является лидером в нашей стране. Вся выпускаемая продукция отличается высоким качеством и не раз удостаивалась международных наград.
Основа стабильности нашего предприятия — планомерная работа по обновлению производства. За подготовку проектно-сметной документации, касающейся модернизации и технического перевооружения производства, отвечает Проектное Управление. В его составе — 49 работников, из которых 34 — инженеры-конструкторы, выпускающие проекты собственными силами, а остальные отвечают за работу по проектам, выполняемым сторонними организациями, а также за выпуск и хранение проектной документации.

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

Рис. 1. Одно изделие в базе проекта может иметь неограниченное число УГО

Функционирование группы КИПиА Проектного Управления ООО «КИНЕФ» имеет некоторую специфику. Во-первых, проектные работы выполняются ее специалистами только для внутренних служб предприятия. В штате группы состоят четыре инженера-конструктора, каждый из которых выпускает в среднем от двух до четырех проектов в месяц. Как правило, это небольшие проекты (не более 10-15 позиций КИПиА), треть из которых касается замены насосов. Но бывают и крупные проекты по новым объектам «с нуля». Например, один из проектов 2004 года «Узел ввода присадок в дизельное топливо» содержал в части марки АТХ (так называемый полевой КИП) более 100 листов.

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

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

Выбор оборудования определяет служба эксплуатации: «Цех КИПиА» или «Отдел АСУТП» — в зависимости от специфики проекта. Проектные работы выполняются согласно годовому плану, который формируют главные инженеры проектов по заданиям на проектирование, поступающим от цехов-заказчиков за визами руководителей заинтересованных служб. При этом некоторая часть работ — внеплановая, а зачастую и срочная. Разумеется, важные проектные решения принимаются совместно с представителями цеха КИПиА, отдела АСУТП, цеха заказчика и других заинтересованных служб.

До покупки двух лицензий E³.series все оформление документации мы выполняли в AutoCAD 2002/2005. В настоящее время формат DWG является стандартом для Проектного Управления и необходимым требованием ООО «КИНЕФ» к сторонним проектным организациям.

Отметим, что группа КИПиА нашего управления — единственная, куда еще не закупалось специализированное программное обеспечение. В данном случае идея по внедрению E³.series была предложена мною.

Рис. 2. Добавление новых атрибутов, типов надписей и связей между ними

Почему именно система E³.series

На этапе выбора САПР для нашей группы рассматривалось несколько разработок, в том числе и отечественных. Но если говорить об отечественных разработках (точнее, о доступной информации о них), то, на мой взгляд, у них несколько отстает графическая проработка — как интерфейса программ, так и моделей, используемых в процессе работы. Одновременно с этим имеет место некоторая закрытость систем для тонкой настройки и собственной доработки пользователем под свои требования. А перестраивать процесс и собственные стандарты под софт — дело совершенно неблагодарное.

Одним из важных факторов при выборе САПР для нас является доступность сведений о ней, то есть наличие следующих источников информации:

•  интернет-сайт разработчика/поставщика, содержащий подробное описание возможностей САПР: примеры оформления документации в ней, демо-версия программы, «портфолио» (то есть список предприятий, внедривших данную САПР), возможность оценить динамику развития программы (например, частота выхода новых версий, патчей), наличие скачиваемых руководств пользователя и их качество;

•  интернет-форумы с отзывами специалистов о той или иной САПР (в том числе о качестве службы поддержки пользователей и о недоработках программы);

•  публикации в специализированных журналах;

•  выставки и семинары по конкретным САПР. К сожалению, в подобных выставках редко представлен полный спектр поставщиков и разработчиков для интересующего вас сектора программного обеспечения. Да и трудно за время выставки оценить программу, и уж точно там не услышишь обо всех минусах и подводных камнях интересующей вас разработки;

•  возможность пройти курс обучения по интересующему продукту.

В случае системы E³.series многое из вышеприведенного перечня было на должном уровне. Кроме того, на мой взгляд, у этой САПР, в сравнении с другими иностранными разработками, более полный спектр возможностей для разработки проектов нужного нам масштаба.

Но ключевыми аргументами, повлиявшими на выбор именно системы E³.series, были:

•  возможность автотрассировки при компоновке шкафов (те, кто занимался этим вручную, высоко оценит наличие такого функционала);

•  доступ к проекту и к формированию проектной документации с помощью скриптов WBS (Windows Based Script);

•  адекватный импорт/экспорт в другие графические, чертежные системы.

Переход на E³.series не был для нашей группы КИПиА особенно болезненным, чему способствовало обучение в компании ПОИНТ. Период наполнения базы собственных изделий и связанной с этим активной переписки со службой поддержки я считаю неизбежным, да он и не был продолжительным (один-два месяца).

А вот с доработкой стандартных скриптов, идущих в поставке системы E³.series, нам повезло, так как у меня уже имелся опыт программирования в разных средах и WBS — не самая сложная из них. Подчеркну еще раз: без доработки скриптов автоматизацию проектирования можно было бы считать неполной, а в штате нашего управления нет специалиста, которому можно поручить настройку и оптимизацию программ «под себя» (в том числе доработку скриптов для какого-либо программного продукта).

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

Что изменилось после внедрения E³.series

После завершения периода формирования базы изделий у нас объективно улучшилось качество проектов и уменьшилось время их оформления. Если отдельно говорить о качестве проектирования, то я прежде всего имею в виду, что при работе в среде E³.series трудно что-либо потерять или забыть — благодаря очень хорошей наглядности и детальности представления информации об изделиях в проекте, а также жесткой связи между всеми моделями, цепями и пр. Например, изделия LSAL и LSAH размещены на разных схемах, причем на каждой из них — в заданном виде (УГО), обусловленном типом схемы (рис. 1). Все эти четыре УГО связаны друг с другом (это видно в окне проекта), а редактирование одной из схем автоматически отразится на остальных.

Так что на практике если мне нужно кому-то передать на рассмотрение чертеж, созданный в E³.series, то его приходится либо конвертировать в DWG- или PDF-формат, в зависимости от программного обеспечения, установленного у адресата, либо пересылать E3.viewer — просмотрщик проектов Е3.series через систему файлообмена (ftp или сетевые папки). Как правило, пользоваться приходится именно файлообменом (если есть такая возможность), поскольку размер E3.viewer составляет 40 Mбайт, что делает проблематичной его пересылку по обычной электронной почте. Что касается сторонних организаций, то все общение с ними осуществляется или через бумагу, или в формате Active PDF, в котором сохраняется структура проекта и поддерживаются активными все имеющиеся в проекте ссылки.

Далее описываются основные этапы настройки приобретенной Е3.series под наши требования.

Редактирование/создание собственных форматок листов

Здесь очень пригодилась возможность импорта в E3 из DWG/DXF, так как все наши прежние наработки были в этом формате. К импорту DWG/DXF у нас есть пара замечаний, касающихся импорта текста, но они несущественны.

Далее нужно было добавить специфические типы надписей для основной надписи форматок, которых не было в стандартном наборе E³.series, а также поставить им в соответствие атрибуты (в данном случае — с такими же именами), предварительно созданные для параметров проекта (рис. 2).

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

Добавление новых типов схем

Далее мы дополнили стандартный набор типов схем системы E³.series собственными, применяемыми для проектирования «полевого» КИПиА (рис. 3). Пиктограммы (файлы *.ico) были нарисованы в простейшем редакторе иконок. Теперь любому изделию можно добавить дополнительную модель (УГО) для отображения на схеме соответствующего типа (рис. 4). В результате у нас используется четыре различных УГО для четырех типов схем.

Рис. 3. Типы схем не ограничены стандартным набором

Создание шаблонов надписей атрибутов

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

 .

 

Рис. 4. Размещение новых моделей на добавленных типах схем

 

Для этого на основе существующих шаблонов надписей атрибутов мы создали свои и сделали их шаблонами по умолчанию при создании цепей:

Доработка скриптов WBS

Доработкой это можно назвать условно, поскольку конечный листинг скрипта для формирования спецификаций марки АТХ был в несколько раз больше, чем исходный, идущий в стандартной поставке E³.series. Именно листинг, так как WBS — язык интерпретируемый, а не компилируемый и соответственно имеет довольно простой синтаксис. Обрабатывает эти скрипты система Windows, а точнее файл wscript.exe, находящийся в системной папке Windows. Руководства по созданию и использованию WBS можно найти на сайте Microsoft, правда только на английском языке. По специфическим операторам E³.series для WBS в поставке системы E³.series имеется help, но опять же на английском.

В упрощенном виде скрипт WBS для формирования спецификаций в E³.series выглядит следующим образом:

…

служебные заголовки

…

y_min = 73 ‘ нижний предел (мм) для вывода строк спецификации

y_max= 241’ верхний предел (мм) для вывода строк спецификации

y_space = 8 ‘ шаг по оси y для вывода строк спецификации

x_column1 = 28’ координата по оси x для вывода в первый столбец спецификации (“Позиция”)

x_column2 = 42’ координата по оси x для вывода во второй столбец спецификации (“Наименование и техническая характеристика”)

x_column7 = 334’ координата по оси x для вывода в седьмой столбец спецификации (“Количество”)

….

Sheet.Create 0, sheet_name & sheet_number, “A3_sp_1_kinef”, ContentsId, 0 ‘ создать лист в проекте с именем шаблона(форматки) A3_sp_1_kinef

y = y_max; y — текущая позиция по оси y

For n = 1 to Job.GetAllDeviceCount ‘ цикл от 1 до «количество изделий в проекте»

Graph.CreateText ContentsId, n, x_column1, y ‘ создать текст с порядковым номером изделия

Graph.CreateText ContentsId, Cmp.GetAttributeValue(«Description»), x_column2, y ‘ создать текст с описанием изделия

Graph.CreateText ContentsId, quantity, x_column7, y ‘создать текст с «количеством» (подсчет количества изделий данного типа формируется отдельным циклом )’

y = y — y_space; смещение текущей позиции на величину шага

If y < y_min then ‘ проверки, достигнут ли нижний предел, и если да, то создается новый лист с именем шаблона (форматки) A3_sp_2_kinef и текущая позиция по y «возвращается» в y_max

Sheet.Create 0, sheet_name & sheet_number, “A3_sp_2_kinef”, ContentsId, 0

y = y_max

….

Endif

Next ‘ операторная «скобка» для For

…..

WScript.Quit’ завершение работы скрипта

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

•  «Приборы и средства автоматизации» — все изделия, имеющие непустой атрибут «Технологическая позиция»;

•  «Материалы и монтажные изделия» — все изделия, относящиеся к классу базы данных «Монтажные изделия»;

•  «Кабели и провода» — все изделия, относящиеся к классу базы данных «Кабели и провода»;

•  все остальные изделия, не вошедшие в предыдущие три раздела.

При этом список атрибутов для изделия в проекте был основательно расширен с целью вывода дополнительных характеристик в спецификацию. Все изделия проекта сортировались операторами скрипта в соответствующие разделы (массивы). Процедура вывода раздела «Приборы и средства автоматизации» получилась самой объемной, поскольку она предусматривала вывод множества описаний изделия: до шести строк технических описаний, специфические характеристики для позиции КИП — уставки сигнализации и блокировок «LL», «L2», «L», «H», «H2», «HH», «Технологическая позиция», «Место установки», «Измеряемая среда», «Максимальное давление среды», «Максимальная температура среды».

Рис. 5. Реализация «Плана трасс» в E³.series

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

Рис. 6. Схема подключения приборов КИПиА

Для вывода раздела «Кабели и провода» возникла необходимость ввести атрибут «Длина кабеля для спецификации». Это связано с тем, что автоматический подсчет длины проводников в Е3.series идет только при трассировке шкафов/панелей на специальном чертеже компоновки. Поэтому «План трасс» в Е3.series — это большей частью графика. Есть, правда, у нас идея попробовать реализовать «Планы трасс» на чертеже компоновки (в соответствующем масштабе) и автоматизировать тем самым учет длин кабелей, но пока это только идея.

Сейчас же при прорисовке плана трасс нас очень выручает существующий генплан нашего предприятия, части которого в формате DWG импортируются в E³.series, где и дорисовываются новыми трассами и позициями КИП. А для более качественного отображения изделий иногда применяется следующая технология: габаритный чертеж в формате PDF, имеющийся в документации к изделию, -> габаритный чертеж в DWG -> масштабирование в AutoCAD -> импорт в E³.series.

Дополнение графических возможностей Е3.series

Из наших собственных изобретений для работы в Е3.series можно также выделить следующие:

1. Модели (УГО) изделий для плана трасс (рис. 5). В данном примере:

 — это УГО изделия «Короб КИП 100x100x2000» в масштабе 1:200. Аналогично

 — это УГО изделия «Металлорукав РЗ-Ц-П-25».

Укажем, что длина каждого металлорукава задается через атрибут изделия в проекте — «Длина монтажного изделия». Это необходимо для учета при формировании спецификации соответствующим скриптом, тогда как на самом графическом символе названный атрибут никак не сказывается.

2. «Невидимые» изделия для чертежей компоновки. На практике нередко имеет место ситуация, когда необходимо сделать трассировку проводов или кабелей в таких местах, где установка короба невозможна (например, в случае перехода на дверь шкафа). На практике это реализуется в виде жгутовых связок. Но поскольку автотрассировка в Е³.series работает только по схеме «Вывод изделия» -> «Короб» (или сеть соединенных коробов) -> «Вывод изделия», то подобную трассировку мы реализовали с помощью так называемого «невидимого» короба, имеющего два отличия от остальных изделий: вся его графика находится на невидимом слое и изделие имеет в проекте атрибут «Не выводить в спецификации», который учитывается скриптами, генерирующими перечень изделий в шкафу и спецификацию.

Рис. 7. Пример модернизации существующего шкафа

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

О наших планах

Уже сегодня имеющиеся (в том числе дополненные нами) функциональные возможности E³.series позволяют группе КИПиА быстро и качественно выполнять довольно сложные и объемные проекты (рис. 6 и 7). Тем не менее наша цель — дальнейшее совершенствование функционала этой САПР.

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

Кроме того, мы знаем о наработках других пользователей по «подключению» E³.series к ERP-системам предприятий или, в более простом варианте, связи E³.series с базой данных  склада/отдела снабжения, которая может быть реализована практически на любой платформе, начиная от «1С» и вплоть до SAP/R3. Естественно, мы учитываем такую возможность при планировании дальнейшего развития технологии разработки проектов.

Денис Семенов Руководитель группы КИПиА Проектного Управления ООО «ПО «Киришинефтеоргсинтез». Дополнительная информация (образование, профессиональная квалификация и др.) — на сайте www.sdb.name.

САПР и графика 12`2006