САПР для проектирования крупных промышленных объектов

    В этой статье я представлю свое видение того, на каком этапе развития находится САПР для проектировании крупных промышленных предприятий сегодня, с какими трудностями приходится сталкиваться при внедрении и какие тенденции намечаются в этой отрасли.
    Немного о своем опыте. За плечами технический вуз, работа инженером-проектировщиком, переквалификация в специалиста САПР, работа программистом на C#, участие во внедрении, поддержке и адаптации комлексной системы трехмерного проектирования «AVEVA PDMS» в 5-ти проектных институтах: 4-х крупнейших проектных институтах в России (проектирование нефте/газо перерабатывающих предприятий и объектов энергетики) и одном на Украине (проектирование объектов энергетики). В общем опыта вполне достаточно, чтобы можно было провести какой-то анализ ситуации.
    Несмотря на то, что в каждой проектной организации есть своя специфика работы и свои, годами выработанные, практики, все таки просматриваются и общие черты:
    1) Во всех проектных институтах сейчас наблюдается повышеный интерес руководства к автоматизации процессов проектирования.
    2) Прошла первая волна автоматизации.
    В этот период происходила автоматизация работы инженеров в отдельных отделах, путем закупки специализированного ПО. При этом, зачастую, обмен информацией между отделами все также проходил в «бумажном» виде. Изолированность отделов друг от друга приводила к возникновению одних из самых дорогостоящих проектных ошибок — коллизиям. Эта проблема решалась внедрением в организациях систем комлексного проектирования, для совместной работы основных проектных отделов в единой 3D модели через сеть (к примеру AVEVA PDMS, Intergraph SmartPlant 3D, Microstation AutoPlant).
    3) Сегодня идет вторая волна автоматизации.
    Анализируется опыт, полученный при внедрении на первом этапе систем комплексного 3D проектирования, и происходит более четкое осознание всей сложности процесса внедрения и поддержки подобного рода систем. В случае неудачного опыта внедрения, происходит вторая попытка, но уже с ПО другого вендора. Внутри организаций, силами штатных программистов, пишутся программы, расширяющие функционал купленных программ в соответствии со спецификой организации. Создаются, опять же своими силами, различные интерфейсы обмена данными между используемым ПО. Внедряются системы электронного проектного документооборота, объединенного с электронным архивом чертежей. Все эти шаги постепенно ведут к переходу на новый способ организации процесса проектирования — проектирование в едином информационном пространстве (ЕИП).
    Необходимо отделить ЕИП организации от ЕИП проектируемого объекта. ЕИП организации не относится к какому либо конкретному проекту и будет существовать даже при их отсутствии.
    К ЕИП уровня организации можно отнести следующие системы:
    1) электронный документооборот компании;
    2) корпоративный портал компании, включающий справочник сотрудников, систему таймменеджмента, систему управления задачами;
    3) электронный архив проектно-сметной документации;
    4) средства информационного взаимодействия сотрудников, включающие программно-технические и организационно-нормативные документы;
    5) служба технической поддержки пользователей (HelpDesk).
    Другое дело — ЕИП проектируемого объекта, в котором накапливается и хранится информация по проекту. Это информационное пространство состоит из следующих компонентов.
    1) 3D модель;
    2) 2D документация;
    3) база данных проекта;
    Распишем более подробно каждый пункт. 3D модель может быть выполнена как в одной программе (PDMS, SmartPlant 3D), так и являться сборкой из 3D моделей различных частей проекта, выполненных в различных программах 3D моделирования (PDMS, продукты от Autodesk, и др.). Собрать целую 3D модель и проверить её на наличие коллизий отлично получается с помощью Autodesk Navisworks. Также возможны более сложные комбинации. Например когда в PDMS загружаются 3D модели, созданные в специализированных программах Inventor, Revit, Civil 3D и др. Сразу скажу, что способов загружать эти модели существует всего два: через Mechanical Equipment Interface или с помощью самописных программ преобразования 3D моделей в набор стандартный примитивов и поверхностей PDMS.
    Перейдем к 2D документации, которая в основном состоит из чертежей и текстовых документов и делится на документы в формате PDF (которые отправляют заказчику) и редактируемые документы (в основном DWG, Word и Excel). Основным принципом организации ЕИП является связанность информации об элементах в проекте. Т.е. если один и тот же объект присутствует в 3D модели, в чертежах и таблице Excel (и/или документе Word), то эти элементы должны быть связаны между собой ссылками. Естественно, что под каждый проект создается система кодировки элементов, обеспечивающая их уникальность в пределах проекта (KKS).
    Так вот, чтобы связать все элементы проекта, необходима третья (и главная) составляющая проектного ЕИП — база данных проекта. Проще всего (на мой взгляд) делать её на основе Microsoft SQL Server. С помощью создания базы данных проекта, достигается возможность синхронизации изменений информации об объекте во всех связанных документах. Из-за того, что в каждой проектной организации используются различные подходы к проектированию, и разное программное обеспечение, на рынке отсутствуют готовые решения, которые одинаково подошли бы всем. Поэтому единственный способ создания ЕИП в проектной организации — сделать ЕИП самим (с помощью штатных программистов).
    Отдельно хочу сказать о командах программистов в отделе САПР. Такие команды (обычно 3-5 человек) сегодня стали неотъемлемой частью отделов САПР. Разнообразие задач у таких команд довольно большое. К наиболее характерным относятся:
    1) автоматизация обмена данными между специализированным ПО (расчетными, сметными и чертежными программами);
    2) автоматизация процесса обмена заданиями между проектными отделами;
    3) кастомизация пользовательских интерфейсов уже установленных программ;
    4) разработка программ получения различных отчетов.
    Для того чтобы процесс разработки не вышел из под контроля а исходный код всегда находился в работоспособном состоянии, следует использовать различные системы для совместной разработки и управления версиями. Поработав с такими системами, как Atlassian Jira + SVN и Team Foundation Server 2012, мой выбор однозначно за TFS, так как система управления проектами и система контроля версии отлично связаны между собой, и все это интегрировано в Visual Studio.
    Немного слов о процессе внедрения систем совместного 3D проектирования. Дело это крайне сложное и длительное, так как вовлекаются все основные проектные отделы организации. Людям приходится изучать новые программные продукты, менять выработанные годами привычки. На своём опыте я убедился, что перемены всегда встречаются большинством сотрудников негативно. Если организация приняла решение осуществить внедрение самостоятельно (без привлечения специалистов, уже имеющих в этом опыт), то вероятность неудачного внедрения, когда были потрачены средства и время и не было достигнуто результата, возрастает. Поэтому при принятии решений о таких глобальных изменених в организации, очень будет уместна народна мудрость: «Семь раз отмерь, один раз отрежь».
    • –5
    • 7.7k
    • 7
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 7

      +1
      Под кат, пожалуйста
        +1
        Если честно то не понятен смысл статьи. Был бы это топик Авева то я понял бы — реклама и вытекающее из этого. А так ничего конкретно. Если бы Вы, например, описали проблемы и решения связанные с получением 2д документации из 3д (так как именно она интересует заказчика ), вставка штампов, генерация спецификаций, передача заданий между отделами, ответы на замечания заказчика и экспертизы ну или еще какой-то этап (а лучше серию поэтапно) то это был бы тру пост. А так скомканный рассказ о 3д проектировании — о котором все говорят, в данной отрасли, но мало кто делает. Но это мое, сугубо лично мнение.
          +1
          Все верно. Это очень общее видение всего процесса внедрения САПР в проектной организации. По поводу конкретики. Получение 2D из 3D — зависит от отдела. Для трубопроводных отделов вполне можно настроить Draft и IsoDraft, с остальными отделами сложнее.
          Генерация спецификаций — лучший способ — это собственные программы на C#, для извлечения данных из базы PDMS и вставки их в нужный шаблон Excel.
          Передача заданий между отделами — довольная сложная тема, так как необходимо для начала согласовать со всеми формат передачи этих заданий (например 3D + чертежи, только 3D, только чертежи либо другие варианты). А затем писать свои реализации на C#.
          Ответы на замечания заказчика — из моего опыта работы с NET Portal-ом могу сказать что при наличии желания, программистов и пару месяцев времени вполне можно довести его до работоспособного состояния.
            0
            Касательно самих программных средств 3D и 2D и так в общем все понятно, закупаются, внедряются и пилятся до состояния необходимой работоспособности, тут нет ничего нового и подходы как правило у всех одинаковы.
            Основная проблема к которой со временем приходят проектные институты это как раз таки создание единого информационного поля проекта, той самой базы данных, где хранится вся информация, о которой Вы писали, как главной части ЕИП. И вот об этом хотелось бы поподробнее, так как сейчас сами стоим на пороге такого решения, но еще нет понимания, как это должно выглядеть.
            Интересен Ваш взгляд на это, исходя из опыта внедрения в различных институтах.
            Ну и было бы действительно интересно почитать о том, про что говорит Zanoza.
              +1
              Извиняюсь если неверно выразился в своем комментарии, я лишь хотел сказать какой, по моему мнению, был бы интересен пост в данных хабах. Те несколько этапов, которые я перечислил это лишь толика от того, что требуется реализовать на пути к 3д проектированию. Вот это и стоит описать, а не перечислить софт, установленный в организации. Хочется увидеть сердце системы и процессы, которые обеспечивают его бесперебойное функционирование. Понять, как Вы пришли к такому решению и чем оно обосновано. В общих чертах, думаю, многие понимают что нужно, а вот посмотреть на решения, к которым пришли другие организации интересно. Да и тем, кто только готовятся к столь серьезному изменению в ведении проектной деятельности — как стать 3-х мерными, была бы полезна серия статей (в одной всего уместить). Но опять же, оговорюсь, это мое мнение.
            0
            Необходимо отделить ЕИП организации от ЕИП проектируемого объекта.
            Есть такой подход, считаю его неверным. Продукты Dassault позволяют создать общее пространство, да и Intergraph. Заказчики ЕИП одной из основных целей ставят повторяемость результатов и возможность повторного использования одних и тех же наработок разными рабочими группами. Когда для каждого нового объекта ЕИП начинают заново разворачивать, это не достигается.

            3D модель
            Цикл работы с 3D моделью для сложных объектов почти всегда включает CAE. А сейчас еще в моде термины 6D и 9D, комплексное описание ЖЦ объекта на стадии проектирования на основе 3D модели. В этом контексте, работа с моделью неотделима от прочих аспектов проектирования: документооборота, цепочки поставок… Рассматривать изолировано ее нельзя, как бы ни хотелось.

            2D документация
            Всегда ставится задача генерировать 2D и 3D автоматически из одного репозитория. Правда, никогда в реальной жизни такого не видел.

            Естественно, что под каждый проект создается система кодировки элементов, обеспечивающая их уникальность в пределах проекта (KKS).
            Это противоестественно, особенно если соглашение о кодировании каждый раз заново делается для типовых проектов (например, АЭС). А некоторые еще и стандарт не соблюдают. И робкие попытки натянуть KKS на ISO 15926 ничем хорошим не заканчиваются.

            необходима третья (и главная) составляющая проектного ЕИП — база данных проекта
            Поздравляю, вы изобрели PLM-систему.
            Ну и далее по тексту — красные тряпки для системных интеграторов: MS SQL, маленькие команды, все делать самим, TFS.
            Имея опыт внедрения больших PDM/PLM решений на платформах SAP и IBM, могу сказать, что решение попробовать все сделать самим, силами штатных разработчиков, может оказаться совсем неплохим :)
              0
              Статья о «САПРе для проектирования крупных промышленных объектов» как минимум должна содержать:
              1. Информацию о преимуществах работы различных САПР с моделями из большого / огромного количества элементов
              2. информацию о возможности одновременной работы в ЕИП большого количества Субподрядчиков, сидящих на разных САПР и на разных системах управления документацией
              3. Информацию о решении проблем с конфиденциальностью
              4. О жизненном цикле объекта, не ограничивающимся проектированием

              Но в любом случае за статью спасибо. Убедился что проблемы внедрения у всех одинаковые :)

              Only users with full accounts can post comments. Log in, please.