Проблемы построения САПР для части «Автоматизация технологических процессов»

Владимир Якубовский, инженер, г.Краснодар

В статье рассматривается ситуация с разработкой рабочей документации комплектов марки «А» в соответствии с ГОСТ 21.408-2013, а также основные проблемы при разработке без использования специализированных САПР. Дано краткое описание направления развития существующих САПР и их проблем. Кроме того, определен вариант построения специализированной САПР с минимизацией недостатков в существующих системах.

Нормативная база и ситуация с документацией без САПР

В настоящее время единственным специализированным документом, регламентирующим рабочую документацию в части автоматизации процессов, является только ГОСТ 21.408­2013. ГОСТ 34.201­89 относится к документации на системы автоматизации в целом, то есть к разработке АСУ, конструкторской документации на элементы верхнего уровня (шкафы управления и т.д.) и программного обеспечения, однако документация для строительства разрабатывается только по требованиям ГОСТ 21.408­2013 с соблюдением общих требований к оформлению по ГОСТ Р 21.1101­2013.

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

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

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

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

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

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

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

Требования к документации

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

• документация должна содержать не меньше информации, чем необходимо для выполнения строительно­монтажных работ (больше можно, но это излишние усложнения);
• документация не должна содержать повторов информации в различных видах — дублирование информации часто приводит к разночтениям в плане как понимания, так и внесения изменений;
• документация должна максимально использовать общепринятые (оговоренные различными нормативными документами) методы и способы выполнения монтажных работ c целью минимизации дополнительной детализации узлов и блоков;
• если необходимо более детальное отображение отдельных фрагментов, желательно выполнять эту процедуру в отдельных уточняющих чертежах. Уровень проработки всех узлов в пределах чертежа должен быть близким.

Подход к организации работы в существующих САПР

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

Наблюдаются два кардинально различающихся подхода к построению САПР.

Система первого типа: имитация последовательности действий проектировщика без использования САПР. При этом система в основном помогает «рисовать» некоторые элементы и собирает «мусор» за разработчиком (считает мелкие элементы, материалы и пр.).

Система второго типа: составление «виртуальной модели» документации набором некоторых элементов из базы.

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

Недостатком же систем второго типа является постоянно расширяемая база знаний, за полнотой наполнения которой становится сложно уследить.

Наиболее перспективным направлением разработки собственной системы САПР нам представляется вариант номер два с некоторыми дополнениями.

Критерии (требования) к разрабатываемой системе

Нами приняты следующие критерии системы:

• использование стандартизированных (типовых) элементов;
• возможность входа в систему на любом этапе разработки (система должна состоять из нескольких функционально законченных элементов, информация между которыми передается через унифицированные формы);
• масштабируемость детализации проработки (от упрощенной — при недостатке входной информации либо при заниженных требованиях, к увеличению детализации по мере поступления дополнительных данных);
• разработка правил маркировки/нумерации элементов с целью автоматизации данной части работы с выведением нумерации за пределы ответственности пользователя. В идеале при внесении любого элемента в базу проекта все индексы назначаются автоматически.

Далее приведенные критерии рассматриваются более подробно.

Использование стандартизированных (типовых) элементов

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

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

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

Возможность входа в систему на любом этапе разработки

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

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

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

Масштабируемость детализации

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

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

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

Разработка правил маркировки/нумерации элементов

В настоящее время какие­либо общепринятые принципы маркировки элементов отсутствуют либо находятся в зачаточном состоянии, частично основываясь на некоторых «общепринятых» правилах. Если где­нибудь и существуют жесткие требования — то автору такие случаи неизвестны.

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

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

Выводы

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