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

Содержание:

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

 

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

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

 

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

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


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