Интеграция Лоцман и 3D систем

[KDA]

Конкретно речь идет о CATIA, но я думаю, ситуация приблизительно одинакова с любой 3D программой. Интеграция CATIA и Лоцман устроена таким образом, что в дерево Лоцмана информация поступает один к одному из дерева построения CATIA, между тем дерево построения CATIA отображает любые компоненты, участвующие в построении модели, в том числе и различные вспомогательные элементы, такие как сварные швы, компоновочные элементы и т.д. Соответственно при получении информации из такой сборки в Лоцман, весь этот мусор лезет в состав изделия, а его там быть не должно. Другая ситуация. Имеется детально проработанная сборка, в составе которой имеются подсборки, сделанные примитивами, т.е. упрощенно, такая подсборка в состав основного изделия должна входить одним элементом, однако в CATIA она также имеет свою ветвь в дереве, состоящую обычно из двух трех компонентов, не имеющих ничего общего с реальными деталями (так делается для упрощения сборки), т.е. элементы построения примитивной подсборки также не должны переходить при интеграции в Лоцман, но они туда идут! Т.е. идет абсолютно все, что есть в дереве построения. И как с этим бороться? Есть ли у кого-нибудь подобный опыт?

[YorikER]

Мы с этим столкнулись практически сразу же, как только попробовали повзрослому эксплуатировать систему ЛОЦМАН-КОМПАС... Проблема не в интеграции... Проблема в идеологии самой работы, которую предлагает АСКОН (кстати и другие IT компании)... В большинстве случаев в смычке PLM-CAD первоисточником информации является состав изделия, сформированный в CAD системе. На наш взгляд это глубоко не рациональный подход... Первоисточником информации должна быть единая PLM система для всей команды разработчиков, а CAD система должна использоваться только для визуализации объектов и оформления документации по изделию. Формировать состав изделия необходимо сразу же в PLM системе из набора уже разработанных объектов, стандартизированных объектов и вновь созданных. Для тех объектов, которых вам необходимо, регистрировать 3D CAD образы и 2D документацию. При таком подходе проблемы с интеграцией фактически сведутся к нулю... Правда ЛОЦМАН в базовой конфигурации для такого режима не приспособлен... Нам пришлось написать свое клиентское приложение и разработать в нем редактор спецификации, работающий напрямую с базой данных ЛОЦМАНа. Но затраты не оказались напрасными, сегодня все подразделение (более 100 человек в конструкторском отделе после всех кризисных сокращений и более 350 на всем предприятии) работают в единой системе с корпоративным справочником стандартных изделий и материалов и сортаментов. реализованных на платформе ЛОЦМАН PLM. Правда если вы это все увидите, то просто не поверите, что это ЛОЦМАН. Меняйте идеологию и у Вас тоже все получится...

[Паша Горбунов]

Мы с этим столкнулись практически сразу же, как только попробовали повзрослому эксплуатировать систему ЛОЦМАН-КОМПАС... Проблема не в интеграции... Проблема в идеологии самой работы, которую предлагает АСКОН (кстати и другие IT компании)... В большинстве случаев в смычке PLM-CAD первоисточником информации является состав изделия, сформированный в CAD системе. На наш взгляд это глубоко не рациональный подход... Первоисточником информации должна быть единая PLM система для всей команды разработчиков, а CAD система должна использоваться только для визуализации объектов и оформления документации по изделию. Формировать состав изделия необходимо сразу же в PLM системе из набора уже разработанных объектов, стандартизированных объектов и вновь созданных. Для тех объектов, которых вам необходимо, регистрировать 3D CAD образы и 2D документацию. При таком подходе проблемы с интеграцией фактически сведутся к нулю... Правда ЛОЦМАН в базовой конфигурации для такого режима не приспособлен...

Юрий Львович, добрый день!
Мне не совсем понятна озвученная идея.

Ведь и в Лоцмане также можно начать с набрасывания дерева состава в самой системе:
создать новую сборку -> создать в ней подсборки (которые раздать по подотделам для проработки) -> включить в дерево состава сформированной сборки подсборки и детали, которые уже разработанны и зарегистрированны в системе.
Затем перейти к формированию 3D-модели сборки и чертежей.
Затем из Лоцмана сформировать, например в компасе спецификацию по данному составу изделия.

В чём отличие предлагаемой Вами схемы от описанной мной?

[YorikER]

Павел, добрый день... Да Вы правы в ЛОЦМАН-Клиенте есть такая возможность... Я, видимо некорректно ответил, скорее не полно... Просто мы пошли по пути интеграции ЛОЦМАН -> CAD, а не наоборот... А по поводу ЛОЦМАН-Клиента... Да простят меня авторы, но он в принципе не приспособлен для работы конструктора... Более всего он годится для работы Администратора... Мы столкнулись с человеческим фактором: деревянное представление информации шокирует обычного юзверя-конструктора... Руки сами тянутся к Компасу, где просто шикарно реализована спецификация по ЕСКД! В результате конструктор сам тянется к обратной интеграции, что приводит к моментам, описанным уважаемым KDA. Говорю об этом как бывший начальник конструкторского бюро, возрастной состав которого колебался от 23 до 65 лет... Кроме этого (я уже много об этом писал) базовая информационная модель конструкторской подготовки производства предложенная АСКОНом весьма далека от реальности... Достаточно привести хотя бы два примера: атрибут Обозначение не может являться ключевым атрибутом объекта и в базовой модели АСКОНа отсутствовало такое понятие, как сборочная единица - стандартное или прочее изделие в спецификации (не знаю как в последних версиях)... Переломить ситуацию я смог, только изменив структуру информации и после того, как было написано собственное клиентское приложение, в котором была реализована идея редактора конструкторской спецификации (в многооконном режиме) непосредственно в системе ЛОЦМАН. Чтобы не быть голословным сообщу следующее... На сайте www.infnt.ru выставлен проект Visual Loodsman (я о нем уже где-то писал)... Подробности идеи на сайте... Там же выставлена бета-версия системы и демонстрационный пример кострукторской базы данных... Пример далек от совершенства... Работа над ним постоянно ведется... Еще не все процедуры-интеграторы разработаны... В ближайшие дни я выставлю обновление, в котором будет пример с указанным выше редактром конструкторской спецификации в системе Visual Loodsman... Вы сможете реально все посмотреть по какому пути мы пошли... Интересно услышать мнение... С уважением...

[Паша Горбунов]

А по поводу ЛОЦМАН-Клиента... Да простят меня авторы, но он в принципе не приспособлен для работы конструктора... Более всего он годится для работы Администратора... Мы столкнулись с человеческим фактором: деревянное представление информации шокирует обычного юзверя-конструктора...

Лоцман-клиент действительно несколько, скажем так,  муторен в работе. С этим я с Вами соглашусь. Но, как практик стандартного Лоцмана, соглашусь не по тем пунктам, которые Вы выбрали в качестве примеров. ))

Немного поясню, чтобы прояснить ситуацию:

Руки сами тянутся к Компасу, где просто шикарно реализована спецификация по ЕСКД! В результате конструктор сам тянется к обратной интеграции, что приводит к моментам, описанным уважаемым KDA. Говорю об этом как бывший начальник конструкторского бюро, возрастной состав которого колебался от 23 до 65 лет...

Работа со спецификацией: здесь сейчас ситуация нормальная (я не знаю как было ранее, работаю в Лоцмане только начиная в версии 8.5). Дерево можно сформировать в Лоцмане любым способом: создать его руками в Лоцмане, автоматически получить его из трехмерки (тоже нормально, но лучше вносить каждую сборочку отдельно) или из спецификации (самый, скажем так, проблемный способ). Окончательную спецификацию Лоцман без нареканий рисует в Компасе, используя созданное дерево состава.

Кроме этого (я уже много об этом писал) базовая информационная модель конструкторской подготовки производства предложенная АСКОНом весьма далека от реальности...
Достаточно привести хотя бы два примера: атрибут Обозначение не может являться ключевым атрибутом объекта

Ой, здесь не понял Вашу мысль. Если есть возможность и время, поясните, пожалуйста. Мне кажется это вполне логичным и верным.

и в базовой модели АСКОНа отсутствовало такое понятие, как сборочная единица - стандартное или прочее изделие в спецификации (не знаю как в последних версиях)...

Сейчас есть такая возможность. Атрибут "раздел спецификации" для сборки можнго выбрать любым. Это правило касается не только сборки и оно настраивается в Лоцман-конфигутароре.

Переломить ситуацию я смог, только изменив структуру информации и после того, как было написано собственное клиентское приложение, в котором была реализована идея редактора конструкторской спецификации (в многооконном режиме) непосредственно в системе ЛОЦМАН.
В ближайшие дни я выставлю обновление, в котором будет пример с указанным выше редактром конструкторской спецификации в системе Visual Loodsman... Вы сможете реально все посмотреть по какому пути мы пошли... Интересно услышать мнение... С уважением...

Обязательно посмотрю Вашу разработку.

[YorikER]

Кроме этого (я уже много об этом писал) базовая информационная модель конструкторской подготовки производства предложенная АСКОНом весьма далека от реальности...
Достаточно привести хотя бы два примера: атрибут Обозначение не может являться ключевым атрибутом объекта

Ой, здесь не понял Вашу мысль. Если есть возможность и время, поясните, пожалуйста. Мне кажется это вполне логичным и верным.

Как говорится: это было давно и не правда... Попробую вспомнить проблемы, действительно ЛОЦМАН уже далеко шагнул вперед, на и наши вопросы не прошли для разработчиков даром... Просто мы рванули в самостоятельное направление развития и нисколько не жалеем...
1. В спецификации есть детали БЧ (без чертежа). Как обеспечить уникальность и исключить дублирование одинаковых по сути объектов если нет обозначения...
2. В разделе стандартные изделия (если я правильно все помню) ключевым был атрибут Наименование, т.к. обозначения вроде у стандартных изделий нет... В нашей технической подготовке производства используется огромное количество стандартизированных изделий собственного производства, у которых есть обозначение, причем часто при одинаковых наименованиях... Перейти в данном разделе на ключ по обозначению также нереально, используются объекты чисто стандартные без обозначений... Влипли сразу же...
3. Еще один финт ушами, связанный с нашим производством... Существуют стандартные изделия с одинаковым обозначением, но различающиеся наименованием: пример косынки металлоконструкций - обозначение одно, различаются длиной, длина записывается в наименовании...
4. Когда вы только начинаете проектировать, у вас еще нет обозначений объектов, занимать штатное обозначение еще рано, т.к. еще неизвестно пойдет ли эта проработка в производство или останется заделом в базе данных, как здесь быть?
5. И т.д....
Это малая часть проблем с уникальной идентификацией объектов спецификации... Большую часть я уже не помню... В конце концов после долгих рассуждений мы приняли следующее решение, которое нам очень помогло... Во всех объектах спецификации мы выделии отдельный атрибут Шифр, который не входит в видимую часть спецификации. Для всех разделов алгоритм его формирования одинаковый: Обозначение + Наименование через пробел. Связка этих двух атрибутов в нашей технической подготовке производства однозначно идентифицировала объект проектирования... При создании нового объекта шифр формировался автоматически, что-то напоминающее GUID... При заполнении (или редактировании) указанных выше атрибутов включался алгоритм, о которм написано выше, и объект идентифицировался в базе данных однозначно... После трех лет интенсивной работы отдела в ЛОЦМАНЕ (100...200 человек) сейчас количество объектов базы данных превышает 272000... И не разу проблем с идентификацией не возникло...

[YorikER]

Теперь на счет атрибута Раздел спецификации для сборок... Назначить этот атрибут любым в ЛОЦМАНЕ и раньше не было проблем, а вот как сделать так, чтобы при интеграции (или получения информации) из 3DCAD в ЛОЦМАН создавался объект сборочная единица с нужным разделом... Сборки однозначно попадали в раздел Сборочные единицы... После изменения системы идентификации ИНТЕГРАТОР отазался с нами работать... Настроить его у нас не получилось... Морочить голову в КОМПАСе с атрибутом Раздел спецификации тоже не очень веселая задача... Слишком много системных изменений от базовой модели нам пришлось сделать... Когда освоили API сервера приложений ЛОЦМАНа все проблемы просто отпали, т.к. мы все взяли под свой контроль и решали так как нам было нужно...
Кроме этого есть еще один системный вопрос к АСКОНу... Почему справочники материалов и сортаментов и стандартных изделий сделаны как отдельные приложения, а не разработаны на платформе ЛОЦМАН... Ведь все компоненты указанных справочников являются объектами бизнес-процесса материално-технического снабжения и объектами жизненного цикла изделия (PLM)? Нас не устроил такой подход, и мы все реализовали на платформе ЛОЦМАН...
Тема очень объемная о ней много можно говорить... Подходы у всех разные и все имеют право на жизнь... Мы пошли по пути создания на платформе ЛОЦМАН корпоративной системы технической подготовки производства... Есть успехи, есть неудачи... Огромное влияние имеет человеческий фактор... Но учитывая, что мы полностью контролируем процесс, мы отвечаем сами за себя... Сейчас у нас к АСКОНу вопросов фактически нет... Спасибо им за джина, которого они просто так выпустили из бутылки... Мне иногда кажется, что разработчики сами еще не поняли, какую разработку они выпустили в свет... Пять баллов с плюсом!!!

[Паша Горбунов]

Что ж, Юрий ЛЬвович, удачи.
Продукты расходятся в различные стороны. Но это и хорошо. В их, скажем так немного пафосно, диалектическом противоречии и идейном взаимообмене  и заложено дальнейшее развитие.