Проект по импортозамещению иностранных САПР в крупной нефтегазовой компании

Предпосылки реализации проекта импортозамещения САПР иностранного производства

Ряд предприятий и компаний, особенно нефтедобывающей промышленности, вынуждены были начать рассматривать вопрос импортозамещения программного обеспечения (далее ПО), так как санкции США, Канады, Великобритании постоянно усиливаются и налагают запреты не только на его приобретение и обновление, но и на использование уже имеющегося. Выполнение таких базовых операций, как перераспределение пула лицензий компании Autodesk приводит к необходимости прохождения процедуры экспортного контроля США, что занимает достаточно длительное время и может, в последствии, повлечь отказ в праве использования ПО. Точно так же ситуация обстоит с поставкой всего инженерного программного обеспечения от всех разработчиков из США. Кроме того, отказ ведущих мировых разработчиков инженерного ПО от распространения бессрочных лицензий и перевод заказчиков на временные, приводит к необходимости прохождения авторизационных процедур ежегодно, а иногда и более часто. Эти «авторизационные» процедуры требуют наличия обязательного подключения к сети Интернет, что существенно затруднено во многих Российских компаниях из-за закрытого внешнего периметра.
Первым сигналом для Компании послужила необходимость подписания авторизационных писем, в которых необходимо было гарантировать, что компания не занималась, и не будет заниматься разведкой и добычей углеводородов в условиях Крайнего Севера и на шельфе. Ввиду того, что бизнес не стоит на места а постоянно развивается, Руководство Компаний сочло невозможным подписание таких авторизационных писем, а без них зарубежные разработчики отказываются поставлять лицензии.
Далее был прямой отказ компании Autodesk в поставке обновлений (Subscription Renewal) для «бессрочных» лицензий, а также предупреждение том, что компания Autodesk будет проводить различные аудиты на территории Компании.

Исходя из вышеперечисленного, в нефтегазовой Компании не стали дожидаться наступления момента, когда в проектных подразделениях не смогут использовать программное обеспечение для создания информационных моделей (САПР) от разработчиков из США.
Для минимизации «лицензионных рисков» в Компании был инициирован проект перехода с зарубежных САПР для информационного моделирования, на отечественное ПО Model Studio CS (разработчик компания CSoft Development), причем решили не использовать графическую платформу Autodesk AutoCAD, как предлагалось изначально, а сразу использовать отечественный аналог nanoCAD Plus (разработчик компания Нанософт). На начальном этапе Институт не планировал менять графическую платформу, потому как линейка ПО Model Studio CS на платформе AutoCAD работала стабильнее, и даже была более развита функционально.
Хотелось бы обратить внимание, что было осуществлено не просто внедрение ПО Model Studio CS с «чистого листа», а осуществлялся именно комплексный ПЕРЕХОД с ПО от разработчиков из США по разделам «Технологические схемы», «Трубопроводы», «Металлоконструкции», «Визуализация», «Управление структурой проекта» на аналогичные решения ПО Model Studio CS на графической платформе nanoCAD.
Стоит также отметить, что упоминаемые выше иностранные САПР работали в головном проектном Институте Компании более 10 лет, в течении которых была создана колоссальная база данных элементов, разработан и реализован механизм выпуска ряда отчетных документов в соответствии с требованиями Компании, выполнены работы ро локализации ПО для генерации документации в соответствии с требованиями Российских нормативных документов, а самое главное, были отработаны методики групповой работы пользователей над проектом и получен обширный многолетний опыт работы с иностранными системами информационного моделирования.
Что же послужило финальным толчком к старту процесса импортозамещения? – как ни странно — это экономическая составляющая и финансовая отдача в последующие периоды от внедрения отечественного ПО.
Поэтому, представители Головного Проектного Института (далее Заказчик), а именно им поручили возглавить данный процесс перехода на отечественные САПР со стороны Нефтегазовой Компании, приступили к всестороннему изучению вопроса.

На начальном этапе Заказчик провел анализ рынка отечественного программного обеспечения для информационного моделирования объектов обустройства нефтегазовых месторождений, на основании которого остановил свой выбор на линейке ПО ModelStudio CS. Для более детального ознакомления с ПО, силами Разработчика ПО было проведено вводное дистанционное обучение для инженеров-проектировщиков, после чего был выполнен пилотный проект собственными силами. Хочется отметить, что еще пару-тройку лет назад, практика использования систем дистанционного обучения оставляла желать лучшего, да и программное обеспечение компаний СиСофт и Нанософт достаточно часто «зависало» и «фаталило», поэтому пилотный проект был выполнен с более низким уровнем детализации, чем это можно было сделать на зарубежном ПО.

Экономическая составляющая вопроса перехода была посчитана и показала свою состоятельность, так как в разрезе 3-5 лет уже проявлялся существенный экономический эффект от экономии на лицензиях, подписках ПО, необходимости обучения специалистов.

Не смотря на все отрицательные моменты, вектор направления на импортозамещение был задан, программное обеспечение, в первом приближении опробовано, протестировано. В результате, было составлено Техническое Задание на доработку программного обеспечения, по которому можно выделить следующие основные части:
• доработка Баз Данных оборудования, изделий и материалов;
• настройка отчетов в соответствии с корпоративными станлартами;
• настройка чертежей (проекций);
• доработка функционала ПО и разработка нового функционала, необходимого Заказчику.

Получив детальное ТЗ специалисты консорциума, в составе компаний: Бюро САПР (входит в состав ГК Русский САПР), CSoft Development и Нанософт, обсудили его и решили, что задача поставлена новая, интересная, в результате решения которой, за 10 месяцев реализовать необходимо выполнить все обозначенные потребности заказчика и осуществить переход на современную отечественную систему информационного моделирования Model Studio на платформе NanoCAD.

Одним из наиболее важных факторов в выборе ПО, на который обратил Заказчик - было то, что программный комплекс ModelStudio CS очень динамично развивается. Заказчик выполнял первичное тестирование ModelStudio на платформе nanoCAD версии 8.5. При этом довольно часто случались «зависания» системы (часть сбоев относились к сбоям графической платформы nanoCAD 8.5). На текущей версии стабильность ПО гораздо выше ввиду того, что используется последняя версия графической платформы nanoCAD Plus 20.Х. Не секрет, что сейчас сбои тоже случаются, но это уже довольно редкие явления, поскольку не существует САПР, где бы сбои отсутствовали вообще, были они в свое время и у ПО от американского разработчика.

За период реализации проекта, при выполнении доработок ПО и внедрения технологии в Проектном Институте произошли существенные изменения и доработки в ModelStudio CS, ряд которых приведена ниже:
• Внедрен новый механизм выполнения воздуховодов. С учетом его реализации, специалисты Бюро САПР производили разработку Базы Данных.
• Была переработана структура Комплексов (Площадки, Здания и Сооружения).
• Был усовершенствован механизм отчетов, который стал позволять делать несколько выборок к одной и той же группе данных, также была реализована возможность сбора подчиненных данных.
• Не так давно был реализован механизм вставки решеток для систем вентиляции. По моему мнению, данный механизм самый удобный среди имеющегося ПО проектирования воздуховодов.
• Разработан новый тип топологии трубопроводной сети – крестовина, ранее таких элементов в ПО не было заложено.
• Была внедрена система идентификации объектов информационной модели.
• А также реализован еще ряд функций, например, инструмент для бесплатного просмотра информационной модели с получением атрибутивных данных элементов.

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

База данных

Технология преобразования

Для того, чтобы начать полноценную работу с программным комплексом ModelStudio необходимо иметь соответствующую элементную базу данных оборудования, изделий и материалов.
Как упоминалось выше, Заказчик более 10 лет работал с программномными комплексами от разработчиков из США. Естественно, что за это время была разработана соответствующая БД элементов.
Изначально, по непонятной причине, в технических требованиях почему-то были представлены требования по переработке БД только труб и опор, без фитингов, арматуры, фланцев, изоляции, элементов вентиляции. Соответственно, без всех перечисленных элементов разработка информационной 3D-модели будет не возможна, а, значит, и будут проблемы с полноценным внедрением ПО. Команда интеграторов ориентировалась же на разработку всех основных элементов (за исключением особо специфичных), основываясь на имеющейся у заказчика БД от ранее используемого комплекса. Уже на этапе знакомства с Техническим Заданием произошел пересмотр перечня разрабатываемых объектов, и разрабатываемый перечень был актуализирован.
По переработке Базы Данных специфического оборудования изначально была обозначена позиция, что переработкой будут заниматься специалисты Заказчика по мере необходимости использования того или иного оборудования в проекте.

При разработке БД трубопроводов возникла следующая дилемма:
• одной стороны, в базе данных ПО ModelStudio CS имеется БД, идущая в поставке и содержащая определенные объекты трубопроводов и оборудования.
• с другой стороны, у Заказчика имеется собственная БД от американского ПО, которая используется и наиболее приближенная к потребностям Заказчика.
Какую БД брать за основу? Брать БД Model Studio CS и синхронизировать с БД американского ПО, или же брать БД американского производителя и транслировать ее в БД Model Studio? Внимательно проанализировав информацию, мы пришли к выводу, что проще и правильнее будет все-таки взять за основу БД от американского комплекса и ее преобразовать в БД Model Studio.
Хочется обратить внимание на очень важный момент, что вопрос Базы Данных напрямую связан с инструментами генерации отчетных документов. Необходимо сначала сделать БД, а потом уже заниматься настройкой отчетов. При заведении элементов в БД нужно сразу понимать, как они должны выводиться в отчетах и в таком виде их заводить в БД. Иначе может получиться, что когда дело дойдет до отчетов, окажется, что для того, чтобы выполнить требования ТЗ Заказчика информацию нужно завести по-другому, да еще добавить дополнительные поля для разбивки объектов по категориям, а значит, опять в конце работы необходимо будет корректировать БД. Поэтому все описательные поля нужно приводить к тому виду, который необходим пользователю.

Следует отметить, что выгрузить порцию данных по нескольким объектам из БД ModelStudio CS в формат «XLS» для дальнейшей корректировки нельзя. В том числе это связано с архитектурными решениями БД ModelStudio CS– ведь каждый объект может содержать ряд дочерних подобъектов. Поэтому выгрузить один объект можно, а вот выгрузить несколько объектов уже не получится, т.к. они в общем случае могут иметь различную структуру. Да, можно сделать отчет, который выгрузит определенные поля, но затраты на его создание будут существенными. В принципе, производить корректировку можно и без выгрузки, на уровне менеджера БД, но это не так удобно, как на уровне MS Access или MS Excel. А если учесть наличие и необходимость корректировки дочерних объектов, то дело значительно усложняется. Поэтому, обычно применяется следующая технология: первоначальное создание данных производится в файле формата «XLS». Если далее требуется незначительная корректировка, она выполняется в менеджере БД. Если требуется значительная корректировка, то проще отредактировать имеющийся файл формата «XLS» и повторить его загрузку. По факту у нас получилось, что во время разработки БД загрузка осуществлялась довольно часто, информация проверялась, выявлялись ошибки, поэтому мы часто осуществляли загрузку из файлов формата «XLS». В дальнейшем, по завершению работ по наполнению БД и после выполнения пилотного проекта потребности в загрузке файлов формата «XLS» фактически уже не возникло.
Может показаться странным: почему же нельзя выгрузить информацию из БД? - как было отмечено ранее, это обусловлено архитектурными решениями, т.к. система обладает замечательным свойством - может иметь дочерние элементы, которые в ряде случаев позволяют решать определенные задачи, например, вывод в спецификацию дополнительного оборудования. Но опять же, данный фактор вызывает некоторое недоумение только лишь на начальном этапе работы с программным комплексом ModelStudio CS. Спустя некоторое время необходимости в выгрузке информации из БД для ее редактирования практически не возникает, ряд задач можно решить без выгрузки информации.
Так или иначе, но основное направление было выбрано следующее: брать имеющиеся у Заказчика базы американского ПО (формата mdb), превращать их в формат XLS, пригодный для загрузки в ModelStudio CS, затем в менеджере БД ModelStudio создавать шаблонный элемент и через него производить загрузку.

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

Данный фактор значительно усложнил разработку новой БД. Можно было бы брать отдельно каждую БД, по каждому отделу и ее переносить в БД ModelStudio CS– такой подход сильно упростил бы нам ситуацию, но с точки зрения описания материалов – это неправильно, когда один и тот же элемент фигурирует в разных дисциплинах/марках проекта под разными названиями (похожими, но несколько отличающимися). К тому же, если все помещать в единую БД, будет путаница при работе с соответствующими функциями в ПО, например, в подборе элементов (ведь где-то, например, отвод дублируется в 5 экземплярах, а где-то он только в одном, т.к. формулировка по этому отводу всех устраивала).
Поэтому технология работы получилась следующая - мы со своей стороны сводили информацию из разных БД американского ПО в одну, после чего согласовывали с заказчиком номенклатуру и отдельно – формат вывода в спецификацию, стараясь, чтобы он был единым для всех отделов. Сразу нужно отметить, что не везде у проектировщиков получилось прийти к единой формулировке, поэтому окончательное формирование описания в отдельных случаях (они редки, но были) корректировалось на уровне генератора спецификации.
В результате данной работы Заказчик получил не только оттранслированные в Базы Данных, но и провел их нормализацию и актуализацию на текущий момент времени. При самостоятельной реализации, данная работа заняла бы у заказчика несколько человеко-месяцев и привлечения специалистов высокой квалификации.

Арматура

С арматурой ситуация была особо сложной.
БД американского ПО по арматуре, которая использовалась у Заказчика, была не совсем актуальной. Она содержала множество записей, которые либо уже не использовались, либо не содержали полной информации. Кроме этого, как и в случаях с трубопроводными элементами, для разных отделов были разработаны разные базы. И поэтому просто брать текущую БД американского ПО и преобразовывать в формат ModelStudio CS не имело смыла, т.к. требовалась ее актуализация. Поэтому, мы пошли по двухступенчатой схеме. На первом этапе производилось согласование заводов-изготовителей, так как ряд производителей арматуры уже не использовался. На втором этапе силами специалистов Бюро САПР информация по каждому производителю была выгружена из набора MD-файлов, опять же разные отделы использовали разные БД, а, значит, пришлось предварительно объединять информацию, в формат XLS, где были обозначены поля, которые следует актуализировать пользователям. Далее уже со стороны Заказчика информация проверялась, заполнялась и передавалась нам. Мы ее обрабатывали и приводили к виду, доступному для загрузки в БД. Параллельно проходило согласование графического вида арматуры и корректировка графики ее отображения, если была необходимость.
Следует также отметить, что по требованиям проектировщиков Заказчика вывод описания арматуры в спецификации значительно изменился и стал гораздо сложнее. Например, для шаровых кранов потребовалось указывать длину удлинения штока, а для арматуры, применяемой теплотехниками, допустимую температуру. Более того, даже в период выполнения проекта требования Заказчика также корректировались, что приводило к необходимости вносить изменения «на лету».
В результате данной работы Заказчик получил актуализированную Базу Данных для успешного применения в программном комплексе ModelStudio CS.

Разработка графики элементов

Если говорить о разработке графики элементов с использованием параметрического редактора программного комплекса ModelStudio CS, то здесь работы оказалось не так много. Основные элементы в БД имеются (фитинги, трубы, частично опоры). Пришлось выполнить разработку следующих элементов:
• опор, которых не было изначально в БД ModelStudio CS;
• арматуры, так как вся арматура перерабатывалась единообразным образом под требования Заказчика, с определенным отображением типа привода;
• вентиляции, при этом частично графика была взята из БД ModelStudio CS;
• элементов с раструбом (трубы водоснабжения и канализации) – корректировалась графика.

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

Изоляционные материалы

В свое время, при внедрении САПР американского разработчика более 10 лет назад, специалисты Бюро САПР реализовывали расчет объема примененных изоляционных материалов. Расчет в американском ПО проводился на уровне отчетов, т.е. в модели у элементов задавались определенные признаки: код окраски, изоляции, задавалась толщина изоляции, а на уровне отчетов с использованием отдельной таблицы кодов материалов производился расчет материалов.
При переносе изоляционных материалов в Model Studio CS выяснилось, что на данный момент у Заказчика спектр изоляционных материалов значительно расширился. Появились теплоизоляционные сегменты, цилиндры, трубки из каучука и т.п. При этом у каждого изоляционного элемента имеется своя особенность по расчету. Например, при использовании трубок из вспененного каучука по требованию Заказчика необходимо было рассчитать также клей и липкую ленту для проклейки швов. При этом клей надо считать либо в кг, или кв.м, а ленту в метрах. Трубки также могут содержать клей (тогда липкая лента нужна только для поперечных швов), а могут и не содержать. При использовании полуцилиндров и сегментов, дополнительно необходимо закладывать клей, ленту и пряжку.
И здесь встала дилемма: на каком уровне закладывать расчет материалов?
Можно заложить на уровне отчетов, как это было в американском ПО. Но тогда, в связи со значительным увеличением используемых материалов, требуется внедрение соответствующей кодировки, чтобы на основе этой кодировки при формировании спецификации производить соответствующий расчет. При этом расход материала не будет возможным просмотреть в модели, либо же выгрузить другими средствами (вне генератора отчетов).
Другой подход – это задавать подсчет материалов на уровне БД, в виде «работ», как это предполагала технология в ModelStudio CS. В этом случае в БД вносятся изоляционные материалы, и в каждом изоляционном материале заводится формула, по которой производится подсчет необходимого объема. Такой подход получается более прозрачным, так как каждый изоляционный материал может иметь свои расчетные формулы. Но есть и определенный отрицательный момент: в изоляционном материале необходимо тщательно задавать формулу подсчета, учитывая, к какому элементу применен изоляционный материал: арматуре, фланцу, отводу, трубе, заглушке, опоре, оборудованию и т.п. При этом, если вдруг окажется, что в формуле закралась ошибка, а материал уже применен к элементам модели, после того как в БД корректировка будет выполнена, придется данный материал заново применять к объектам разрабатываемой модели, а это не так просто.
Есть еще один нюанс, на который нужно обращать внимание - при использовании такого подхода, он касается опознавательной окраски, которая, например, наносится полосами через 60 метров. Поскольку материал накладывается на каждый объект, в том числе на фитинги, а не целиком на трубопровод (такой подходящей сущности в программе нет), а 60 метров рассчитывается с учетом фитингов, соответственно, на каждый фитинг нужно закладывать пропорциональный объем материала, который потом при расчете приводить к целым величинам. Хотя, учитывая, что расчет в любом случае несет ту или иную погрешность, по согласованию с Заказчиком можно пойти на такие допуски.

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

Резюме по базе данных

Означает ли это, что Базу Данных оборудования, изделий и материалов необходимо под каждого Заказчика разрабатывать заново? Но разве то, что получает пользователь в коробке ModelStudio CS от разработчика ПО для работы не годится?
Ситуацию нужно оценивать в каждом конкретном случае индивидуально. Не следует забывать, что заполнение информации в Базе Данных напрямую влияет на формирование заказных спецификаций. Если будут определенные требования по формированию заказных спецификаций, это означает, что необходимо в базе данных производить определенные корректировки. И чем больше требований выдвигается к заказным спецификациям, выводу информации о составных деталях, тем больше и больше придется корректировать БД элементов.
В нашем случае База Данных элементов дорабатывалась непосредственно под Заказчика, так как были строго определенные ТЗ требования по выводу элементов в спецификацию.
С другой стороны, если имеющаяся База Данных позволяет решить проектные задачи, стоящие перед Заказчиком, то и смысла ее перерабатывать нет.
В то же время База Данных по модулю ModelStudio CS «Строительные решения» только дополнялась необходимыми элементами, и кардинально не перерабатывалась. Это обусловлено тем, что у строителей в этом плане ситуация на порядок проще: номенклатура единичных изделий не такая разнообразная, а формы вывода спецификаций все же более стандартизированы, чем заказные спецификации специалистов-технологов и специалистов-инженерных коммуникаций. Поэтому вполне можно обойтись поставляемой разработчиком БД.

Отчеты

Выбор технологии формирования отчетов
Система Model Studio CS обладает широким функционалом настройки отчетов. Отчет можно выводить и в документ MS Word, и в книгу MS Excel, и на лист, то есть непосредственно в dwg-файл, и в xml. При настройке отчетов можно использовать арифметические формулы и различную группировку элементов.
И еще одна очень привлекательная особенность отчетов Model Studio CS – это их связь со «спецификатором», когда имеется возможность предварительно посмотреть как будет выглядеть отчет в табличном виде и, если что-то в нем не так, в том же самом окне можно выбрать сбойные элементы, выяснить причину некорректного отчета, либо переназначить их данными из базы данных.
При работе с американским ПО Заказчик использовал отдельную программу - генератор отчетов, разработанный специалистами Бюро САПР – AutoCOVT. На то был ряд причин. Во-первых, функционал американского ПО не позволял формировать отчеты в соответствии с требованиями Российских стандартов. Во-вторых, как выяснилось, у Заказчика были серьезные требования к отчетам: то дополнительные элементы необходимо расписать, то изоляцию посчитать, то посчитать длину трубопровода со всеми отводами, переходами, тройниками. А при формировании спецификации иметь соответствующую структуру, заголовки первого уровня, например, выравнивать по центру, второго – по левому краю, ряд разделов начинать с новой страницы. Поэтому ранее мы использовали специально разработанную программу AutoCOVT для формирования отчетов. Механизм настройки отчетов в ней заложен не простой, но выполнение подсчета основано на выполнении SQL выражений, механизм настройки открыт, что позволяет сравнительно легко реализовать любой алгоритм подготовки данных к отчету.

В рамках проекта перед специалистами Бюро САПР стояла сложная задача определить способ генерации отчетных документов: реализовать ли отчеты штатным функционалом и ставить вопрос по доработке необходимого функционала разработчикам ModelStudio, или же применить к формированию отчетов программу AutoCOVT.
Отказываться от штатного функционала очень не хотелось, но рассмотрев отчеты, которые были реализованы для американского ПО, стало понятно, что текущего функционала Model Studio CS недостаточно и потребуется процедурная обработка информации. Сначала программисты попытались составить мини-ТЗ по доработке механизма отчета ModelStudio СЫ, но стало ясно что:
• в ТЗ от клиента фигурирует только одна строка - сделать отчеты. Предугадать, какие будут требования в этих отчетах практически невозможно. Да, имелись отчеты для американского ПО, которые нужно будет переработать, но была большая вероятность, что хотя и делаем «как было в американском», на самом деле всплывут новые требования, так как прошло уже около 10 лет и ряд требований проектировщиков изменился. По факту так оно и произошло.
• описать разработчику, что конкретно надо сделать, то есть поставить задачу оказалось весьма непросто. Чтобы быть однозначно понятым исполнителем, надо очень тщательно все разжевать, проанализировать, рассмотреть все варианты, а тут всегда есть риск что-то упустить. А при каждой объявившейся потребности ставить вопрос о доработке функционала отчетов ModelStudio CS – этот вариант был неприемлемым, так как бюджет и сроки нужно было оценивать изначально.
Поэтому было принято решение, со стороны ModelStudio CS получать выгрузку информации в виде xml-файла, а далее уже подключать AutoCOVT с возможностью процедурной обработки информации и дальнейшем выводе в отчеты. Предлагаемая технология реализации разработчиком ПО была принята и по договоренности был доработан механизм формирования xml-файла: добавлена возможность после формирования xml и автоматического запуска внешнего приложения, возможность возвращения обратно в систему ModelStudio CS проставленных номеров позиций, если это требовал отчет.

Дочерние элементы
Часто при выполнении проектирования встречается следующая ситуация: в модели вставляется один какой-то объект, например, резервуар, а в спецификацию должны выйти дополнительно брус и уголок. Либо же при вставке пожарного комплекта для пожарного гидранта должны в спецификацию дополнительно выйти головка напорная, переходная и другие элементы. Или же, при вставке одного объекта «выпуска из обвалования», в спецификации должен появиться целый раздел. При этом эти дополнительные элементы в 3D-модели отображать не то что бы не нужно, но даже и вредно, так как это только перегружает модель со всеми вытекающими последствиями.
Такой функционал в американском ПО обычно реализовывали на уровне формирования отчетов - это была единственная возможность. При этом имелась настроечная таблица, где задавался состав дополнительных элементов и соответствие этого состава основному элементу. Если в 3D-модель вставлялся соответствующий основной элемент, то элементы, входящие в состав выводились в спецификацию.
В Model Studio CS объекты имеют иерархическую структуру, а это значит, что у каждого объекта могут быть дочерние подобъекты, которые в свою очередь также могут иметь дочерние объекты. Поэтому задача дополнительных элементов может быть изначально решена на уровне БД и 3D-модели. Единственно, потом нужно будет выполнить соответствующую настройку отчета, так как могут быть различные варианты вывода таких дополнительных элементов: выводить сразу после основного, или же выводить единым списком среди прочих изделий, или же, например, выводить отдельным разделом. И если рассматривать механизм использования дочерних элементов ModelStudio CS, то всегда можно увидеть состав основного объекта, либо на уровне БД, либо непосредственно посмотреть на уровне модели. Поэтому вопросов у проектировщиков, откуда появляются в спецификации дополнительные элементы должно быть на порядок меньше. Также, спецификация по проекту будет выводиться именно в том виде, что была на момент разработки, так как информация по дополнительным элементам также находится в модели.
Основной недостаток такого подхода – это сложность создания дочерних объектов. Создавать и редактировать поля дочерних объектов гораздо более сложно, потому что в числе дочерних объектов есть системные и не системные, и не предназначенные для вывода в спецификацию. Этот момент на начальном этапе работы с ModelStudio CS может сбивать с толку. Соответственно, напрашивается создание отдельного раздела, из которого объекты будут выводиться в спецификацию.

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

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

Настройка чертежей

В отличие от зарубежной САПР, при внедрении ModelStudio CS была проведена довольно емкая работа по настройке проекций. Это обусловлено несколькими моментами.

Проекции

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

В Model Studio CS, в принципе, можно использовать и аналогичную технологию с применением видовых окон, но предпочтительна и рекомендована другая технология – технология генерации проекций. В результате получается плоское отображение, которое при необходимости можно откорректировать средствами графической платформы nanoCAD Plus. Если через 10-15 лет возникнет потребность в корректировке чертежей, это можно будет с легкостью выполнить. В зарубежной системе дело обстояло совершенно иным образом: отредактировать чертежи можно только непосредственно в самой системе и желательно в версии, в которой создавалась модель и чертежи, а по прошествии 10-15 лет, этой системы может уже и не быть, а значит, и редактировать чертежи не получится.

В Model Studio CS при настройке проекций можно задать множество параметров, в том числе систему слоев, цветов, весов и типов линий. Например, можно сделать, чтобы арматура отображалась тонкими линиями, в то время как сам трубопровод – толстыми линиями. В зарубежной системе для этого приходилось элементы разносить по слоям, т.е. на каждую линию приходилось создавать порядка 5-7 слоев, в том числе, чтобы, например, арматура и трубопровод размещались по разным слоям с различными толщинами линий. Здесь же данная задача решается через настройки проекции: в настройках веса линии можно использовать формулу, которая будет анализировать тип элемента и соответственно, возвращать требуемый вес линии.

Аналогично дело обстоит и с подземными трубопроводами. В зарубежной системе проектировщики самостоятельно задавали признак того, является ли трубопровод подземным. Если он являлся подземным, ему присваивался соответствующий цвет и на печати он выходил пунктиром. В Model Studio CS сама программа, во-первых, знает находится ли объект над землей или под землей. Во-вторых, на основе этой информации при генерации можно задать соответствующий тип линии.

В Model Studio CS при генерации проекций можно также задавать условные обозначения. Например, отобразить трубу в виде одной линии, если ее диаметр менее определенной величины. Или, например, отобразить опору условным обозначением. Дело в том, что если сделать проекцию с 3D-модели «как есть», то опора окажется под трубой и не будет видна на чертежах. В зарубежном ПО для решения этой проблемы приходилось опоры рисовать в двух слоях: один слой был предназначен для отображения опоры в модели, другой – для условного обозначения в чертежах. В Model Studio CS данную задачу можно решить двумя способами:

либо сделать УГО опоры и при формировании проекции выполнять замену на УГО.
либо использовать механизм LOD. Данный механизм позволяет иметь несколько степеней отображения деталей. Например, при уровне 500 можно иметь отображение арматуры, приближенное к реальности, а при уровне 100 – условное отображение в виде «бабочки», которое используется в чертежах.

Соответственно, в зависимости от потребности Заказчика можно использовать тот или иной способ реализации.

В Model Studio CS имеется прекрасный механизм вставки автоматических аннотаций. Т.е. при формировании проекции можно сделать так, чтобы различные выноски вставились автоматически. Да, разнести их вручную, скорее всего, придется, но выноски уже будут проставлены. Соответственно, необходимо затратить определенное время на настройку данных выносок. Не все можно сделать, например, хотя и размеры заявлены, и для простейших ситуаций они работают, но, например, для сложного монтажного чертежа корректно проставить размеры может только проектировщик. Автоматически проставить позиции опор, позиции всех элементов, номера линий, высотные отметки – это вполне реально.

Аксонометрические схемы

Кроме формирования планов в Model Studio CS имеется возможность формирования и «изометричек» подобно Isogen и аксонометрических схем. В нашем проекте Заказчика изометрические чертежи не интересуют, а вот «аксонометрички» по разделам ВК, ОВ, НВК, ТС применяются. При формировании схем основной вопрос уделяется разработкам соответствующих УГО: в этом режиме трубопроводы рисуются в одну линию, а вместо других объектов ставятся УГО. Поэтому требуется разработка этих УГО. Именно по этому пути мы пошли в данном случае, поэтому на настройку схем и разработку УГО было затрачено определенное время. Да, в отличие от других систем Model Studio CS позволяет формировать аксонометрические схемы, к которым привыкли специалисты ОВ и ВК. Но тут сразу надо отметить, что схемы рисуются в масштабе. Проектировщики, хотя и ссылаются на ГОСТ (а он регламентирует определенный масштаб схемы), но как правило, игнорируют требование о масштабе, т.к. в масштабе схемы получаются нечитаемыми, соответственно схемы рисуются так, чтобы их было отчетливо видно. Поэтому сформированные схемы нуждаются в определенной корректировке.

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

Продольные профили

В Model Studio CS, в отличие от других систем имеется функционал формирования продольных профилей, приближенный к требованиям наших ГОСТ и работает он довольно неплохо.

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

Необходимо отметить, что на настройку профилей требуется значительное время. Здесь требуется и разработка УГО элементов подвала (особенно, если отображать схему) и разработка УГО элементов на линии профиля и разработка УГО высотных отметок. Поначалу на предварительную настройку одного профиля у опытного специалиста уходило порядка одной человеко-недели: подземная прокладка, надземная прокладка, разделы НВК, ТС, ГСН – каждая из позиций имеет свои нюансы, свои настройки. В дальнейшем трудозатраты получились порядка 1-3 недели на профиль, в зависимости от его сложности, очень много времени уходит на согласование результата с Заказчиком. Поэтому, если Заказчику требуется настройка продольных профилей, следует закладывать довольно много трудозатрат на данную работу.

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

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

В качестве резюме, хочется отметить, что специалистам Бюро САПР удалось практически на 100% решить требования Заказчика по автоматизации оформления профилей, однако, при внедрении комплекса Model Studio CS следует закладывать существенное время на настройку проекций, профилей, «аксонометричек» в зависимости от потребностей Заказчика.

Разработка дополнительного функционала

В рамках реализации проекта разработчиком также было выполнена разработка дополнительного функционала:

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

Приемка результатов работ и выполнение пилотного проекта по тестированию настроек

Осуществлять приемку адаптированной системы Model Studio CS было решено посредством реализации двух пилотных проектов, которые наиболее характерны для Заказчика. Моделирование при этом выполнялось не в полном объеме, так как основной целью было тестирование наработок, вовлечение в использование Model Studio CS основных участников проектного процесса, а не выполнение крупномасштабного проекта в полном объеме.

Перед выполнением пилотного проекта База Данных не содержала все требуемые элементы, так как БД для оборудования не разрабатывалась в рамках проекта адаптации. Поэтому IT-специалисты занимались отработкой технологии и освоения инструментов для заведения новых элементов в БД. Оборудование из зарубежного ПО преобразовывалось довольно легко. С использованием соответствующих команд оборудование превращалось в твердотельную модель, после чего эта модель преобразовывалась в оборудование Model Studio CS и, при необходимости, к нему добавлялись штуцера. Такой подход хорош, если далее не предполагается корректировка геометрических размеров оборудования. Если же нужен целый ряд однотипного оборудования, то гораздо эффективнее создать параметрическое оборудование. Но его нужно создавать с нуля посредством функционала параметрического редактора, что занимает больше времени.

Как бы серьезно ни тестировались предоставляемые компоненты решения в отдельности - БД, отчеты, проекции и пр. - наилучшей проверкой является выполнение проекта, приближенного к реальности. В нашем случае реализация пилотного проекта выявила следующие тонкости и нюансы:

Были проработаны различные варианты подгрузки земли. Дело в том, что землю разрабатывают специалисты генплана в своем ПО. При этом они работают в метрах и в определенной системе координат. Основным и главным вопросом было – как обеспечить работу специалиста генплана в случае внесения изменений: действия по внесению изменений должны быть сравнительно простыми, быстрыми, но обеспечивать актуальность информации у специалистов смежных специальностей. Наилучшим образом оправдала себя методика, когда создается чистый файл, в него подключается в качестве ссылочного файла земля, устанавливается требуемый масштаб ссылки, при необходимости ссылка перемещается таким образом, чтобы начало сетки осей имело нулевые координаты. На счет нулевых координат вопрос спорный. Система Model Studio позволяет выполнять генплан в различных системах координат: местной, локальной, государственной.
Тяжелые элементы графики, типа профнастила, армирования должны быть выполнены отдельными файлами и отдельными разделами проекта. Дело в том, что отображение профнастила и армирование необходимо фактически только в комплексной 3D модели, которая формируется на уровне компонента системы CADLib Модель и Архив, а также, возможно, на чертежах строителя. Но в других разделах проекта плоскости должны быть упрощенными, иначе производительность системы при подключении разделов проекта резко падает. Например, стены, на которые накладывается профнастил, это отдельный файл, а сам наложенный профнастил должен быть выполнен другим отдельным файлом. Аналогично общее отображение фундамента – это отдельный файл, который нужен другим участникам проектирования, а вот армирование – это уже отдельный файл, который не должен подгружаться к смежным разделам, по крайней мере по умолчанию.

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

Конечно, можно объекты выполнять и в одном файле, главное, чтобы разделы проекта были разные. Но при этом следить за текущими настройками будет гораздо сложнее, поэтому значительно проще выполнять такие объекты отдельными файлами.

Еще одним недостатком оказалось отсутствие возможности сопряжения стен в строительной части без дополнительной соединительной линии. На данный момент этот вопрос находится в стадии решения на стороне разработчика.

Результаты проекта импортозамещения

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

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

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

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

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

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