Смена платформы проектирования не бывает простой. Сложность этого процесса зависит от огромного количества факторов: размера организации, количества подразделений и специалистов, типа проектов, уровня BIM-зрелости компании; того, насколько полно и качественно описаны бизнес-процессы, какова компетенция ИТ-команды и мотивация сотрудников, насколько глубоко они знают текущее ПО, высок ли уровень его кастомизации и интегрированности с другими системами предприятия и так далее.
Меня зовут Алла Землянская, я технический специалист отдела внедрения и поддержки САПР компании «Системный софт», премьер- и фокус-партнера «Нанософт» по направлениям «Конструкции» и «Машиностроение» В этой статье я расскажу о четырех основных этапах процесса миграции с Autodesk Civil 3D на nanoCAD GeoniCS (рис. 1).
Первый этап: сбор данных
Первое, с чего стоит начать, – это сбор данных (рис. 2). Вы должны хорошо представлять, как именно и специалистами каких отделов используется Civil 3D. Какие основные задачи они решают в повседневном режиме, какие исходные данные используют, что получают на выходе.
Есть ли в компании утвержденные стандарты и правила проектирования? CAD-стандарт, BIM-стандарт, документация к DWT-шаблонам для Civil 3D, а также другие документы, которые регламентируют правила и результат работы специалистов? Из таких документов можно почерпнуть много полезной информации, касающейся специфики использования данных, их организации, порядка совместной работы, требований к итоговым моделям и оформлению чертежей.
Так как речь идет о совершенно конкретном переходе с одного программного продукта на другой, предполагается, что функциональный анализ в том или ином виде уже был проведен и представление о функциональных возможностях ПО сформировано. Основываясь на этом знании, можно сопоставлять рабочие процессы в Civil 3D и nanoCAD GeoniCS – не с точки зрения преимуществ и возможностей, а в целях поиска адекватного соответствия инструментов (рис. 3).
Может так случиться, что анализ собранных на первом этапе сведений об использовании текущего ПО приведет к неожиданному результату. Например, вы придете к выводу, что уровень использования Civil 3D далек от идеала. Конечно, не существует шкалы, на которой процент использования функционала можно было бы отразить в интервале от нуля до ста, а затем разместить на этой шкале фамилии специалистов – такое совершенно нереалистично. И тем не менее есть некие маркеры, позволяющие оценить зрелость и навыки работы в продукте. Быстрые ссылки на данные, коридоры, пользовательские элементы конструкций, собственные 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
1. Шаблоны DWT.
● Структура слоев и настройки слоев.
● Размерные и текстовые стили, а также стили таблиц – ключевые инструменты оформления; инструменты Платформы nanoCAD, которые использует GeoniCS.
● Стили объектов, меток и ведомостей – настройки отображения объектов, подписей к ним и связанных с ними таблиц.
● Наборы правил для труб и колодцев – индивидуальные параметры определенного типа сетей.
● Контроль нарушений по трассе – критерии проверки элементов плана и профиля.
● Реестр семантических показателей и объектные данные – целые, вещественные, логические и текстовые свойства, которые можно затем использовать в выражениях для подписей и ведомостей.
2. Инструментальные палитры.
3. Каталоги и библиотеки элементов.
● Базы данных оборудования для сетей (.mdb).
● Библиотека элементов конструкции.
● Библиотека шаблонов трасс.
4. Внешние вспомогательные файлы.
● Файлы правил сетей (.cfg).
● Файлы с настройками объектов (.ini).
5. Плагины и скрипты.
Глобально системы очень схожи, но существенно различаются в деталях. Именно эти детали делают неосуществимым программный маппинг настроек. Хорошая же новость в том, что, проанализировав все элементы кастомизации (рис. 4) для Civil 3D и в целом проделав эту работу для одного ПО, для другой платформы BIM-команда справится с такой задачей в более короткие сроки.
Здесь очень важно избежать ловушки поиска «аналога»: не нужно фокусироваться на том, чтобы найти идентичный рабочий процесс или тратить неоправданно много усилий, чтобы добиться от разработчика изменений в архитектуре ПО или данных. Эффективнее будет вложить силы команды в кастомизацию новой платформы для проектирования на основе опыта настройки предыдущей платформы.
Также по итогам первого этапа вы сможете составить оптимальную спецификацию рабочих мест. GeoniCS имеет модульную систему с разделением по функционалу, что дает возможность гибко подобрать набор модулей и не переплачивать за неиспользуемые инструменты.
Второй этап: составление схемы соответствия
Следующий этап – это анализ сведений, полученных на первом шаге, приоритезация задач и составление схемы соответствия стилей и настроек объектов.
«Схема соответствия» в случае пары программных продуктов nanoCAD GeoniCS и Civil 3D – это скорее не технический термин, а общее организационное понятие. На момент написания этого материала нам не удалось найти общедоступной информации об использовании, например, XML-схем или какого-то другого формата для передачи настроек стилей объектов и подписей (меток) между этими продуктами.
Поэтому в общем случае под схемой соответствия стоит понимать некую таблицу, в которой элементу кастомизации текущего рабочего процесса в Civil 3D ставится в соответствие элемент кастомизации рабочего процесса в nanoCAD GeoniCS. Этот условный «маппинг» в первую очередь поможет команде, которая будет осуществлять важный для компании процесс смены платформы. Во-вторых, эта схема на первых порах может пригодиться и пользователям.
Например, вот так выглядят настройки для объекта «Трасса» (рис. 5), который в обоих программных продуктах называется одинаково. Местонахождение настроек в Civil 3D такое: Область инструментов Ò вкладка Параметры. Путь к настройкам в nanoCAD GeoniCS: Проводник чертежа Ò вкладка Установки.
Таблица соответствия групп настроек может выглядеть так, как показано на рис. 6.
Каждый узел, представленный пиктограммой папки, содержит внутри списки стилей, а для меток (подписей) и таблиц (ведомостей) еще и списки выражений. Детальная настройка выполняется как раз на этом следующем уровне с помощью специальных диалоговых окон. В Civil 3D такое окно называется Редактор стиля (рис. 7), а в nanoCAD GeoniCS – Компоновщик стиля (рис. 8).
Они имеют практически идентичную структуру вкладок и позволяют настроить внешний вид и поведение элемента до мельчайших деталей. Более того, механизм для записи свойств метки в краткую формулу тоже максимально схож. Сравните, как записаны параметры для значения пикета (рис. 9).
Но при этом формулы не идентичны, что, как мне представляется, исключает возможность автоматически перенести настройки. Но, повторюсь, если пользователи однажды уже прошли этот путь, выполняя настройку шаблонов для одного продукта, воспроизвести настройки в другой платформе, очевидно, будет быстрее и проще, так как известны принципы.
В приведенном выше примере инструменты выполнения настроек довольно похожи. Рассмотрим другую ситуацию, когда они существенно различаются. Снова обратимся к настройкам трассы. В своде правил 34.13330.2021 Автомобильные дороги, устанавливающем нормы проектирования автомобильных дорог общего пользования вне границ населенных пунктов, приводятся основные технические требования, в том числе параметры элементов плана и продольного профиля дороги. При проектировании трасс автомобильных дорог в Civil 3D и nanoCAD GeoniCS есть возможность установить автоматическую проверку критериев проектирования, но организованы они по-разному.
В Civil 3D это выражения для разных элементов, которые затем объединяются в наборы, – например, для проверки дорог разных категорий. Соответственно, в области инструментов это выглядит как заполненный узел Наборы проверок проекта и отдельные папки проверок для прямых, кривых, клотоид и др. (рис. 10).
В nanoCAD GeoniCS проверка создается не через выражения, а через выбор опций и ввод значений в диалоговом окне Стиль отображения нарушений трассы на вкладках Контроль плана и Контроль профиля (рис. 11).
Соответственно, в Проводнике чертежа это будут именованные стили, без дополнительных сущностей в виде выражений (рис. 12).
Подводя итог, можно сказать, что чем более подробной документацией касательно стандартов предприятия и используемых шаблонов чертежей обладает организация, тем быстрее будет составлен план перехода, определены приоритеты разработки шаблонов по разделам и необходимый для этого временной ресурс.
Третий этап: миграция данных
До этого момента мы говорили о схожих подходах, которые используются в Civil 3D и nanoCAD GeoniCS в части работы с объектами и управления стилями элементов. Однако между продуктами есть и существенные различия. Одно из таких различий касается хранения данных объектов в проекте. В Civil 3D все интеллектуальные объекты хранятся непосредственно в чертеже .dwg, а в nanoCAD GeoniCS вся информация, связанная с геоточками, поверхностями, сетями, трассами и их подчиненными объектами профилями, хранится в проекте как бинарные файлы быстрого доступа.
Планируя переход с Civil 3D на nanoCAD GeoniCS, специалистам, которые будут ответственны за техническую часть мероприятия, следует изучить концепцию работы с проектами в nanoCAD GeoniCS – без нее невозможно организовать эффективную работу со специальными объектами nanoCAD GeoniCS.
Основным форматом для переноса данных является LandXML, он хорошо подходит для передачи данных о геообъектах. В Civil 3D команда экспорта во внешний файл XML позволяет экспортировать информацию об объектах, представленных на рис. 13.
Импорт из файла LandXML в nanoCAD GeoniCS позволяет получить в проекте объекты, показанные на рис. 14.
Передача данных о геометрии объектов происходит с высокой точностью и без потерь. После импорта из LandXML объекты появятся в системных папках проекта nanoCAD GeoniCS и будут доступны через Проводник проекта. С ними можно полноценно работать, как если бы эти объекты были изначально созданы в nanoCAD GeoniCS.
Точки съемки могут быть переданы через формат баз данных .mdb либо через внешние текстовые данные. Инструменты настройки формата экспорта-импорта в Civil 3D и nanoCAD GeoniCS очень схожи, поэтому обмен через текстовые файлы координат или электронную таблицу может быть настроен довольно безболезненно. Далее точки съемки (либо проектные) уже станут обектами-геонами и будут храниться в БД проекта nanoCAD GeoniCS, что является более гибким, продвинутым и безопасным способом хранения данных по сравнению с тем чтобы сохранять точки внутри dwg-чертежа.
Также при планировании перехода следует учесть, что разработчики Платформы nanoCAD, на которой базируется nanoCAD GeoniCS, существенно облегчили жизнь пользователям и реализовали поддержку объектов Civil 3D напрямую через модуль «Топоплан» для Платформы nanoCAD. Благодаря ему у инженера есть возможность быстро воспользоваться результатами работы, выполненной в Civil 3D. Например, если при наличии модуля «Топоплан» Платформы nanoCAD открыть в nanoCAD GeoniCS dwg-файл, созданный в Civil 3D и содержащий TIN-поверхность (рис. 15), то объект будет не только корректно распознан, но и будут доступны основные свойства поверхности, которые могут быть нужны проектировщику: диапазон отметок, площадь в 2D/3D (без возможности редактировать). Также будет доступно изменение стиля поверхности (стили придут из Civil 3D). Вдобавок к этому в панели свойств можно управлять видимостью элементов поверхности: рёбер, горизонталей, точек, границ и т.д. Такого функционала, кстати, нет даже в самом Civil 3D.
Однако при таком способе передачи данных объекты не будут добавлены в проект, а значит их функциональность ограничена. Впрочем, в зависимости от рабочего процесса, возможно, что в ряде случаев этого будет достаточно.
Четвертый этап: создание комфортных условий для пользователей
В завершение хочу напомнить, что, спланировав и продумав всю техническую сторону вопроса, нельзя забывать о том, что работать со всеми этими схемами, документами, правилами и регламентами в конечном счете будут люди. Поэтому, создавая технологию, всегда держите в голове интересы пользователей. Если оставить их один на один со сложной технической информацией, велик риск, что люди будут сопротивляться, саботировать переход, а где-то могут просто не справиться. Предотвратить эти проблемы поможет обучение. На всех предыдущих этапах нужно задаваться мыслью, а как мы научим этому наших пользователей…
Успех такого сложного и большого процесса будет во многом зависеть от того, насколько грамотно организована поддержка проектных групп. Пользователи должны четко знать, где искать информацию, должна существовать удобная база знаний, благо платформ для построения такой системы сейчас множество.
Сведения в базе знаний должны быть проиндексированы, поиск информации – не вызывать затруднений; если же не получилось найти, то под рукой всегда должны быть контакты команды техподдержки. И этот ресурс тоже надо закладывать при планировании перехода с одной платформы проектирования на другую.
Вы уже готовы к миграции на nanoCAD GeoniCS?
Итак, мы разобрались, что nanoCAD GeoniCS – подходящее решение для миграции с Civil 3D. Программа обладает широкими возможностями базовой САПР, а также специализированным инструментарием для работы с динамическими интеллектуальными объектами.
Первоочередная задача при планировании миграции – формирование команды, отвечающей за этот процесс, и распределение ролей между ее участниками.
Переход с Civil 3D на nanoCAD GeoniCS – дело вполне посильное, которое может быть системно реализовано в четыре этапа:
· сбор данных;
· составление схемы соответствия;
· миграция данных;
· последующая техподдержка пользователей.
Весь путь миграции можно пройти самостоятельно или привлечь на помощь интегратора, имеющего большой опыт в реализации подобных проектов.
Переход на новую платформу проектирования позволит компании не просто восстановить процессы, ранее налаженные с помощью технологий Autodesk, но и двигаться дальше, используя преимущества и уникальный инструментарий nanoCAD GeoniCS и Платформы nanoCAD.
Алла Землянская,
технический специалист
отдела внедрения и поддержки САПР
компании «Системный софт»
