Некоторые аспекты построения комплексной системы автоматизации промышленного проектирования
Механизм обмена информацией и параллельное проектирование
Сохранение состояния среды проектирования
Сохранение дополнительной информации в модели
Создание нестандартных элементов
Под комплексной системой будем понимать такую систему, которая служит для выполнения всех разделов проекта (генплан, технологическое, строительное, электротехническое, сантехническое, КИПиА проектирование) в рамках расположения объектов. Система должна обеспечивать наложение моделей различных разделов проекта для возможности согласования проектных решений. Комплексность системы здесь рассматривается в качестве возможности взаимной увязки информации по расположению оборудования, трасс, сооружений и прочих объектов, а не в смысле координирования информации схем и монтажных моделей.
В последнее время большое внимание уделяется построению комплексных систем проектирования. Работа модулей в комплексе должна быть одним из основных критериев выбора программного обеспечения. Комплексная система, даже если ее модули не обладают большой функциональной насыщенностью, значительно повышает как производительность выполнения, так и качество проектной документации. Можно построить систему, а затем наращивать функциональность отдельных модулей, но обратный процесс является тупиковым: если имеются функционально насыщенные модули, которые не интегрируются в комплексную систему, дальнейшее повышение производительности может осуществляться только разработкой комплексной системы и заменой практически всех модулей.
Ключевым понятием комплексной системы является модель объекта. Для каждого раздела проекта создается как минимум одна модель. Модель выполняется в масштабе 1:1, то есть одна графическая единица электронной модели соответствует одной единице модели проектируемого сооружения (для внутрикорпусных коммуникаций — мм) и отражает основные проектные решения (архитектурная модель — стены, окна двери; технологическая модель — оборудование, площадки).
Обычно под термином «модель» подразумевают модель, выполненную в 3D, однако она может быть создана и в 2D. Выполнение определенных частей проекта в виде 2D-модели может быть обусловлено нецелесообразностью создания 3D-модели. В этом случае она отображает проекцию проектируемого сооружения на определенную отметку.
Чертежи получают на основе моделей методом проецирования определенного вида части модели в заданном масштабе.
Таким образом, комплексная система как минимум должна решать следующие задачи:
• выполнять все разделы проекта;
• обеспечивать простой механизм подключения (в режиме наложения) к любой модели проекта (например, к модели отопления) любых других моделей (технологической, архитектурной, вентиляции, модели межкорпусных коммуникаций и т.д.). Данный механизм подключения необходим для качественного и быстрого согласования проектных решений и предотвращения нестыковок;
• обеспечивать параллельное проектирование. Например, сотрудник, выполняющий часть проекта — отопление, должен видеть обновленную модель, выполненную архитектором, технологом. Причем период обновления моделей должен быть как можно меньшим. Параллельное проектирование позволяет сократить сроки разработки документации, в том числе за счет предварительной, более ранней оценки проектных решений смежников;
• автоматически формировать чертежи (а точнее, спроецированные в видовые окна части модели в заданном масштабе) и динамически их обновлять в случае внесения изменений в модель.
По принципам организации хранения информации все существующие САПР можно разделить на два основных типа:
• системы, сохраняющие графическую информацию проекта в файловой структуре (например, AutoPLANT, Autodesk Architectural Desktop, Autodesk Building Systems, CadWorx PIPE, PlantSpace);
• системы, сохраняющие графическую информацию проекта в централизованном (едином) хранилище базы данных (например, системы PDS, PDMS, PLANT-4D).
Проанализируем данные типы организации САПР на предмет построения на их основе комплексной системы, которая решает сформулированные выше задачи.
Механизм обмена информацией и параллельное проектирование
Для осуществления механизма обмена информацией и параллельной работы необходимо, чтобы САПР каждого раздела проекта выполняла следующие задачи:
• подключала модели, выполненные смежными структурными подразделениями, в качестве ссылочных файлов. Соответственно должны иметься средства для манипулирования слоями ссылочных файлов (включение/отключение, изменение цвета и т.д.) и изменения параметров присоединения ссылки (точки вставки, угла поворота, типа присоединения и т.д.);
• динамически обновляла модель, подключенную как ссылочный файл, для получения смежниками (теми, кто использует данную модель в качестве ссылки для увязки проектных решений) свежей информации, что требуется для параллельного проектирования;
• формируемая модель должна отвечать следующим требованиям:
- элементы должны быть строго структурированы по слоям для возможности отключения ряда объектов ссылочного файла,
- параметры слоев (цвет, тип линий и свойство, определяющее толщину линий) должны быть заданы гибким образом для возможности изменения цвета, толщины, типа линий ссылочного файла.
Если САПР выполняет не все разделы проекта (например, не выполняет генплан), то должно осуществляться подключение ссылочных файлов, реализованных в других САПР, а также формирование файла, который может быть подключен к другой САПР. Оптимальным решением является применение систем, работающих на единой платформе (например, AutoCAD, MicroStation).
Если САПР выполняет все разделы проекта, но замкнута на себе (в основном системы, построенные на базах данных), то значительную сложность представляет процесс внедрения: необходим переход всех структурных подразделений на новую САПР одновременно с отказом от старых наработок.
САПР, хранящая информацию в графическом файле, вышеописанным требованиям удовлетворяет.
САПР, хранящая информацию в базе данных, должна выполнять все разделы проекта либо формировать и динамически обновлять модель в графическом файле, который может быть подключен к другой САПР-системе.
Таким образом, даже в системе, хранящей информацию в базе данных, желательно и даже необходимо обеспечить наличие обновляемой модели в графическом файле.
 |
|
Формирование чертежей
Модель предназначена главным образом для облегчения процесса обмена информацией между проектировщиками на этапе проектирования. Конечно, модель может и должна применяться на последующих этапах жизненного цикла сооружений — при строительстве и эксплуатации, но для заказчиков в первую очередь необходимы чертежи.
Формирование чертежа должно происходить по следующей схеме:
• из набора файлов моделей, являющихся ссылочными файлами по отношению к чертежу формируется необходимая информация (например, подключается архитектурная 3D-модель, а также в зависимости от структурного подразделения — технологическая, сантехническая, электротехническая и прочие модели);
• выполняется проецирование данной информации в заданном виде и масштабе в видовые окна чертежа;
• исключается лишняя (для оформления чертежа) информация методом выключения ненужных слоев;
• переопределяется толщина линий объектов ссылочных файлов методом установки соответствующих свойств слоев;
• происходит окончательное оформление чертежа.
Такой механизм позволяет:
• формировать чертежи на ранней стадии (когда модели еще не готовы), что необходимо как для предварительной оценки расположения информации по листам, так и для обеспечения возможности распечатать чертеж любой степени готовности. При доработке модели изменения также будут происходить и в чертежах (см. следующий пункт).
• не производить повторную генерацию и дальнейшее повторное оформление чертежа, так как при внесении изменений в модель они будут отражены на чертеже (поскольку модели подключены как ссылочные файлы). Таким образом, устранение ошибок, внесение изменений в модели при сформированных чертежах не приводит к значительным трудозатратам по переоформлению документации, что особенно актуально на заключительных стадиях формирования документации.
Формирование и оформление чертежей должно осуществляться графическими средствами (AutoCAD, MicroStation и пр.), так как с этой задачей лучше всего справляются именно системы, хранящие информацию в графических файлах. Системы, хранящие информацию проекта в базе данных, для оформления документации наименее пригодны.
Следовательно, для работы вышеописанной схемы необходимо наличие файла модели, сохраненного в одном из стандартных форматов графической системы, так как САПР формирования чертежей не может ссылаться на модели, хранящиеся в базе данных.
|
|
Сохранение состояния среды проектирования
Немаловажным фактором является запоминание состояния среды проектирования. Под состоянием среды проектирования здесь понимается: состояние привязок, параметры шага, сетки, координат, состояние слоев (как текущего файла, так и ссылочных файлов), видов, наличие нескольких сохраненных видов и пр. Сохранение настроек только на один сеанс приводит к таким отрицательным последствиям:
• пользователи будут раздражаться из-за постоянного выполнения лишних операций;
• произойдет увеличение сроков выпуска проектной документации: представьте, что при каждом сеансе необходимо как минимум заново устанавливать состояния ста слоев.
В этом плане наилучшими являются системы, хранящие информацию в графическом файле (системы на базе AutoCAD, MicroStation и пр.), так как при этом гарантируется 100% сохранение состояния среды проектирования.
Системы, хранящие информацию проекта в базе данных, менее приспособлены к сохранению состояния среды проектирования, особенно если система может работать с различными платформами, а среды платформ различаются. В принципе, всю информацию о среде проектирования можно хранить в базе данных, но поскольку хранение не является «родным», необходимо осторожно подходить к таким системам: они могут сохранять не все необходимые параметры (например, может отсутствовать сохранение состояния слоев ссылочных файлов).
|
|
Сохранение дополнительной информации в модели
Следующий фактор, который мы рассмотрим, — сохранение дополнительной информации в модели. Если проектирование осуществляется в 2D, то в модели обоснованно как давать обозначение (идентификаторы) элементов, так и проставлять размеры. Если проектирование выполняется в 3D, в модели желательно вносить временную дополнительную информацию, которая способствует идентификации элементов и более быстрому считыванию информации пользователем. Такими элементами могут быть: позиции (оборудования, арматуры, номера помещений), основные размеры и пр.
Для идентификации элементов немаловажную роль играет нанесение позиций (идентификаторов) в модели. Конечно, можно вызвать свойства элемента и прочитать позицию, но во-первых, для этого необходимо дополнительное время, а во-вторых, при просмотре свойств, например, седьмого элемента можно забыть свойства первого.
Аналогично обстоит дело и с нанесением размеров: поскольку запомнить все размеры невозможно, то при необходимости узнать размер требуется изменить его, на что опять же уходит время. Поэтому простановка основных, наиболее часто используемых размеров сокращает сроки получения размера пользователем и является обоснованной.
Системы, хранящие информацию в графических файлах (на базе AutoCAD, MicroStation и пр.), однозначно позволяют выполнять и динамически изменять подобную вспомогательную информацию.
Системы, хранящие информацию в базе данных, могут не предусматривать выполнения подобных элементов или налагать определенные ограничения.
|
|
Создание нестандартных элементов
Иногда необходимо реализовать в модели нестандартные элементы, которые данная САПР не способна создать, или же элементы, отсутствующие в графической базе данных, а добавление элементов в базу требует времени, которого на момент формирования модели нет.
Если САПР построена на платформе, хранящей информацию в графическом файле, то нестандартные элементы можно выполнить средствами графической платформы. Возможно, они не будут интеллектуальными и к ним нельзя будет подсоединить атрибутивную информацию, но по крайней мере они будут выполнены и, следовательно, адекватно отобразятся на чертеже.
Системы, хранящие проектную информацию в базе данных, могут решать данную проблему одним из следующих методов:
• с помощью мощного создателя компонентов позволять пользователю строить любые графические элементы, что приближает данную САПР к векторной графической системе;
• нестандартные элементы выполнять отдельным файлом модели с использованием графической платформы и подключать его к основной модели как ссылочный файл. В этом случае САПР должна обеспечить полноценное подсоединение ссылочных файлов, выполненных в формате графической платформы.
|
|
Выводы
Таким образом, САПР должна в обязательном порядке формировать графический файл модели, синхронизированный с базой данных. Более того, таких файлов моделей на один корпус в некоторых случаях должно быть несколько, так как в противном случае при насыщенной модели корпуса задержки по времени при подключении всей модели и работе с ней могут оказаться неприемлемыми.
САПР, которые хранят информацию в графических файлах, этому требованию полностью удовлетворяют. Атрибутивная информация в этом случае может храниться непосредственно в графическом файле (Autodesk Building Systems, Autodesk Architectural Desktop), отдельными файлами баз данных (AutoPLANT) или в единой базе данных (CADWorx PIPE).
Одним из неудобств на первый взгляд может показаться фрагментация проекта по файлам. Однако при более детальном рассмотрении данная особенность недостатком не является, и вот почему:
• выполнение различных частей проекта в одном файле нецелесообразно;
• как уже было сказано, фрагментация модели одного раздела проекта в некоторых случаях необходима для уменьшения насыщенности подключаемых частей моделей и соответственно для ускорения работы. К тому же собрать модель из частей намного проще, чем разделить цельную модель на части;
• для формирования цельной модели из частей предназначен механизм ссылочных файлов.
САПР, которые хранят информацию в базе данных, либо не имеют файла модели, либо файл модели вторичен. К выбору САПР данного типа нужно относиться очень серьезно: для полноценного комплексного проектирования САПР должна четко синхронизировать графический файл модели и отвечать следующим требованиям:
• полноценно подключать ссылочные файлы;
• структурировать информацию по слоям, иметь особые настройки по типам линий, цветам объектов, а также по свойствам, определяющим толщину линий, — все это необходимо для полноценного оперирования моделью как ссылочным файлом со стороны смежника;
• формировать чертежи с возможностью динамического обновления информации в случае изменения модели;
• позволять создавать нестандартные элементы и сохранять вспомогательную информацию;
• сохранять среду проектирования.
Итак, при комплексной автоматизации промышленного проектирования более предпочтительными являются САПР, которые хранят графическую информацию в графических файлах: AutoPLANT, Autodesk Architectural Desktop, Autodesk Building Systems.
|
|
