Pull to refresh

Comments 7

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

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

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

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

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

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

Articles