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

Содержание:

- Предпосылки реализации проекта

 

Предпосылки реализации проекта

Ряд предприятий и компаний, особенно нефтедобывающей промышленности, вынуждены были начать рассматривать вопрос импортозамещения программного обеспечения (далее ПО), так как санкции США, Канады, Великобритании постоянно усиливаются и налагают запреты не только на его приобретение и обновление, но и на использование уже имеющегося. Выполнение таких базовых операций, как перераспределение пула лицензий компании 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-файла, таким образом, процедура формирования отчета, даже с применением стороннего ПО, будет выполняться по одной кнопке.

 

Не нашли нужную информацию?

Позвоните по телефону +7 (495) 744 00 11 или напишите нам на e-mail: Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в вашем браузере должен быть включен Javascript. ! Наши специалисты ответят на ваши вопросы!


Яндекс.Метрика