Всем привет!

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

Меня зовут Алла Землянская, я технический специалист отдела внедрения и поддержки САПР компании «Сиссофт». В этой статье я расскажу о четырех основных этапах процесса миграции с Autodesk Civil 3D на nanoCAD GeoniCS.

Первый этап: сбор данных

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

Есть ли в компании утверждённые стандарты и правила проектирования? CAD-стандарт, BIM-стандарт, документация к DWT-шаблонам для Civil 3D, а также другие документы, которые регламентируют правила и результат работы специалистов? Из такого типа документов можно почерпнуть много полезной информации, касающейся специфики использования данных, организации данных, организации совместной работы, требований к итоговым моделям и оформлению чертежей.

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

Может так получиться, что анализ собранных на первом этапе сведений об использовании текущего ПО приведёт к неожиданному результату. Например, вы можете прийти к выводу, что уровень использования Civil 3D окажется далёк от идеала. Конечно, не существует шкалы, на которой условно можно отразить абсолютный 0 и 100% использования функционала, а потом расположить на ней фамилии специалистов – это совершенно нереалистично. И тем не менее есть некие маркеры, позволяющие оценить зрелость и навыки работы в продукте. Быстрые ссылки на данные, коридоры, пользовательские элементы конструкций, собственные DWT-шаблоны, включающие выражения для меток, наборы характеристик и dynamo-скрипты – вот лишь некоторые ориентиры.

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

Давайте подробно разберем, на что стоит опираться при оценке зрелости вашей экосистемы. Начнем с компонентов кастомизации Civil 3D.

Компоненты кастомизации Civil 3D

1. Шаблоны DWT:

• Структура слоёв и настройки слоёв.

• Размерные и текстовые стили, а также стили таблиц – ключевые инструменты оформления, инструменты AutoCAD, которые использует Civil 3D.

• Слои объектов (диалоговое окно «Параметры чертежа») – эта вкладка служит для указания слоев для различных объектов в Civil 3D. Например, можно задать размещение всех трасс в слое ТРАССА, всех участков – в слое УЧАСТКИ и т.д.

• Параметры среды (диалоговое окно «Параметры чертежа») – эта вкладка служит для определения параметров среды (фона) по умолчанию для различных объектов; некоторые из этих параметров влияют на единицы измерения. Эти параметры управляют такими свойствами, как угол, площадь, направление, отметка и т.д.

• Стили объектов, меток и таблиц – настройки внешнего вида объектов, отображения и содержания связанных с ними меток и таблиц.

• Настройки команд – настройки работы команд по умолчанию (установка параметров объектов, запроса свойств, назначение стилей по умолчанию и т.д.). \

• Наборы правил для труб и колодцев – свойства, которые влияют на поведение элементов трубопроводных сетей при их создании, перемещении или редактировании.

• Проверки проектных решений для трассы и профиля – математические формулы, служащие для проверки соответствия геометрии элементов трассы или профиля требованиям проектирования.

• Наборы характеристик – наборы пользовательских свойств, создаваемые вручную или вычисляемые автоматически по формулам.

2. Инструментальные палитры.

3. Каталоги и библиотеки элементов:

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

• Каталоги напорной трубопроводной сети – каждый каталог напорной трубопроводной сети состоит из одной базы данных SQLite.

• Каталоги моделирования коридора – представляют собой библиотеку каталогов, содержащих инструменты, инструментальные палитры и пакеты инструментов.

4. Внешние вспомогательные файлы:

• Набор кодов коридора (.codes).

• Файл критериев проектирования (.xml).

• Файл статей расхода (.csv).

• Файл стандартов кругового перекрёстка (.atj).

• Каталог железнодорожных стрелок (.json).

5. Плагины и dynamo-скрипты.

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

Однако даже с учётом ориентации на российского пользователя невозможно предусмотреть все ситуации и создать продукт, который в базовой комплектации удовлетворял бы всем требованиям всех заказчиков. Поэтому в nanoCAD GeoniCS, разумеется, существует возможность настройки и адаптации стилей объектов и аннотаций. Давайте разберем, что же в nanoCAD GeoniCS можно настроить и адаптировать.

Компоненты кастомизации nanoCAD GeoniCS

1. Шаблоны DWT:

• Структура слоёв и настройки слоёв.

• Размерные и текстовые стили, а также стили таблиц – ключевые инструменты оформления, инструменты Платформы nanoCAD, которые использует GeoniCS.

• Стили объектов, меток и ведомостей – настройки отображения объектов, подписей к ним и связанных с ними таблиц.

• Наборы правил для труб и колодцев – индивидуальные параметры определенного типа сетей.

• Контроль нарушений по трассе – критерии проверки элементов плана и профиля.

• Реестр семантических показателей и объектные данные – целые, вещественные, логические и текстовые свойства, которые затем можно использовать в выражениях для подписей и ведомостей.

2. Инструментальные палитры.

3. Каталоги и библиотеки элементов:

• Базы данных оборудования для сетей (.mdb).

• Библиотека элементов конструкции.

• Библиотека шаблонов трасс.

4.  Внешние вспомогательные файлы:

• Файлы правил сетей (.cfg).

• Файлы с настройками объектов (.ini).

5. Плагины и скрипты.

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

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

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

Второй этап: составление схемы соответствия

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

«Схема соответствия» в случае пары программных продуктов nanoCAD GeoniCS и Civil 3D – это скорее не технический термин, а общее организационное понятие. На момент написания этого материала нам не удалось найти общедоступной информации об использовании, например, XML-схем или какого-то другого формата для передачи настроек стилей объектов и подписей (меток) между этими продуктами.

Поэтому под схемой соответствия стоит понимать в общем случае некую таблицу, в которой элементу кастомизации текущего рабочего процесса в Civil 3D ставится в соответствие элемент кастомизации рабочего процесса в nanoCAD GeoniCS. Этот условный «маппинг» поможет в первую очередь команде, которая будет осуществлять этот важный для компании процесс смены платформы. Во-вторых, эта схема на первых порах может пригодиться и пользователям.

Например, вот так выглядят настройки для объекта Трасса, который в обоих программных продуктах называется одинаково. Местонахождение настроек в Civil 3D такое: Область инструментов – вкладка Параметры, для nanoCAD GeoniCS путь к настройкам: Проводник чертежа – вкладка Установки.

Таблица соответствия групп настроек может выглядеть следующим образом:

Каждый узел, представленный пиктограммой папки, содержит внутри списки стилей, а для меток (подписей) и таблиц (ведомостей) ещё и списки выражений. Детальная настройка выполняется как раз на этом следующем уровне с помощью специальных диалоговых окон. В Civil 3D оно называется Редактор стиля, в nanoCAD GeoniCS – Компоновщик стиля.

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

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

В приведённом выше примере инструменты для выполнения настроек довольно похожи. Рассмотрим другую ситуацию, когда они существенно различаются. Снова обратимся к настройкам трассы. В своде правил 34.13330.2021 Автомобильные дороги, устанавливающем нормы проектирования автомобильных дорог общего пользования вне границ населенных пунктов, приводятся основные технические требования, в том числе параметры элементов плана и продольного профиля дороги. При проектировании трасс автомобильных дорог в Civil 3D и nanoCAD GeoniCS есть возможность установить автоматическую проверку критериев проектирования, но они организованы по-разному.

В Civil 3D это выражения для разных элементов, которые затем объединяются в наборы, например, для проверки дорог разных категорий. Соответственно, в Области инструментов это выглядит как заполненный узел Наборы проверок и отдельные папки проверок для прямых, кривых, клотоид и др.

В nanoCAD GeoniCS проверка создаётся не через выражения, а через выбор опций и ввод значений в диалоговом окне Стиль отображения нарушения трассы на вкладках Контроль плана и Контроль профиля.

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

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

Третий этап: миграция данных

До этого момента мы говорили о схожих подходах, которые используются в Civil 3D и nanoCAD GeoniCS в части работы с объектами и управления стилями элементов. Однако между продуктами есть и существенные различия. Одно из таких важных различий в том, как хранятся данные объектов в проекте. В Civil 3D все интеллектуальные объекты хранятся непосредственно в чертеже DWG, а в nanoCAD GeoniCS вся связанная с геоточками, поверхностями, сетями, трассами и их подчинёнными объектами, и профилями информация хранится в проекте в виде бинарных файлов быстрого доступа.

Планируя переход с Civil 3D на nanoCAD GeoniCS, специалистам, которые будут ответственны за техническую часть мероприятия, следует изучить концепцию работы с проектами в nanoCAD GeoniCS – без неё невозможно организовать эффективную работу со специальными объектами nanoCAD GeoniCS.

Основным форматом для переноса данных является LandXML, он хорошо подходит для передачи данных о геообъектах. Команда экспорта во внешний файл XML в Civil 3D позволяет экспортировать информацию о следующих объектах.

Импорт из файла LandXML в nanoCAD GeoniCS позволяет получить в проекте следующие объекты:

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

Точки съёмки могут быть переданы через формат баз данных .mdb либо через внешние текстовые данные. Инструменты настройки формата экспорта-импорта в Civil 3D и nanoCAD GeoniCS очень схожи, поэтому обмен через текстовые файлы координат или электронную таблицу может быть настроен довольно безболезненно. Далее точки съёмки (либо проектные) уже станут объектами-геонами и будут храниться в БД проекта nanoCAD GeoniCS, что является более гибким, продвинутым и безопасным способом хранения данных по сравнению с тем, чтобы сохранять точки внутри чертежа DWG.

Также при планировании перехода следует учесть, что разработчики Платформы nanoCAD, на которой базируется nanoCAD GeoniCS, существенно облегчили жизнь пользователям и реализовали поддержку объектов Civil 3D напрямую через модуль «Топоплан» для Платформы nanoCAD. Благодаря ему у инженера есть возможность быстро воспользоваться результатами работы, выполненной в Civil 3D. Например, если открыть в nanoCAD GeoniCS файл DWG, созданный в Civil 3D и содержащий TIN-поверхность, то будет не только корректно распознан объект, но и появится доступ к основным свойствам поверхности, которые могут понадобиться проектировщику: диапазон отметок, площадь в 2D/3D (без возможности редактировать). Также будет доступно изменение стиля поверхности (стили придут из Civil 3D). Вдобавок к этому в панели свойств можно управлять видимостью элементов поверхности: рёбер, горизонталей, точек, границ и т.д. Такого функционала, кстати, нет даже в самом Civil 3D.

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

Четвёртый этап: создание комфортных условий для пользователей

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

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

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

Вы уже готовы к миграции на nanoCAD GeoniCS?

Итак, мы разобрались, что nanoCAD GeoniCS – подходящее решение для миграции с Civil 3D. Он обладает широкими возможностями базовой САПР, а также специализированным инструментарием для работы с динамическими интеллектуальными объектами.

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

Переход с Civil 3D на nanoCAD GeoniCS – вполне посильная задача и может быть системно реализована в четыре этапа:

• сбор данных;

• составление схемы соответствия;

• миграция данных;

• последующая техподдержка пользователей.

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

Переход на новую платформу проектирования позволит компании не просто восстановить процессы, налаженные ранее с помощью технологий Autodesk, но и двигаться дальше, используя преимущества и уникальный инструментарий nanoCAD GeoniCS и Платформы nanoCAD. Если у вас остались вопросы или вы еще не решили, как будет происходить процесс миграции ваших проектов, пишите в комментариях. Готова разбираться вместе с вами!