Безбумажная технология - контроль документов в электронном виде

[Николай Н]

Если у вас есть опыт работы с 3Д-сборками как с подлинниками, и вы знаете ответы на эти вопросы, пожалуйста, поделитесь.

Дополнение: знаю одну методу, связанную с сохранением 3Д в нередактируемые форматы, но назвать ее хорошим решением не могу, т.к. с "живой" сборкой людям еще работать надо (оснастка, ЧПУ)

[DGroot]

Все же, я не понял вот какую вещь: если вы при повторном согласовании прошли мимо кого-то, то получается его подписи уже не будет (она "слетела" после исправлении документа). Так? Допускаю, что я чего-то недопонимаю.

В своих рассуждениях я отталкиваюсь от тех знаний который приобретаю осваивая PLM Windchill и полагая что основные функциональные принципы тождественны во всех PDM (PLM) системах.
Т.к после каждой доработки документа образуется его итерация, то каждая очередная итерация может (должна) располагать своим набором ЭЦП. Таким образом задача системы заключается в том, чтобы в итоговом перечне полученных при согласовании ЭЦП значилась суммарное множество подписей. Т.е. если кто-то подписывал не единожды , то система должна оставить в итоговом отчете лишь его последнюю по дате подпись.

Про параметрический САПР, я имел в виду попытки работать с 3Д-сборками как с подлинниками.
Ну, например такая "трудноразбираемая" ситуация - я удалил отверстие, на которое соседи уже запараметризовали свои детали/сборки, и потом заново создал такое же. Внешне все хорошо, но САПР не пропускает без перестроения, а следовательно, без потери подписей сборки и смежных деталей.

И следовательно без выпуска очередных извещений об изменении этих сборки и смежных деталей не обойтись?
К сожалению, как раз этот процесс нами пока наименее изучен, т.к. оформление электронных моделей сборок при участии "родной" для PRoE  PDM  системы Windchill (ради ProE ее собственно и покупали) стало камнем преткновения.
Отдельные попытки создания ЭСБ имеют место, но они непоказательны. Полагаю что дополнительную информацию по данному вопросу возможно получить не только на этом форуме, но и на http://www.sapr2k.ru/index.php?showforum=20
Загляните обязательно на "Все вопросы о PDM". Тут как раз затрагиваются проблемы работы под PDM (PLM).

Или вот еще вопрос - в "обычной" жизни, подписывая сборочный чертеж, я подписываю именно то что вижу - чертеж. А что я подписываю в мире 3Д-сборок? Лишь совокупность ссылок на входящие детали? Хорошо ли это? Может быть. Не знаю.

Почитайте ГОСТ 2.111 "Нормоконтроль" с последними изменениями http://www.dbases.ru/cgi-bin/catalog/catalog.cgi?i=5650&l=
В таблице 1 указано что проверяется у электронных моделей. Это общие требования. А частные могут быть Вами изложены в собственных СТП. Главное - это понимание, что есть нечто, что должно контролироваться, т.к. может негативно сказаться на неких технологических процессах ( в т.ч. и на документообороте), а также на качестве изделия в целом. Ведь возможна и работа только с моделями (без чертежей). О таких примерах писали на
http://www.sapr2k.ru/index.php
Еще почитайте ГОСТ 2.102 http://www.dbases.ru/cgi-bin/catalog/catalog.cgi?i=5486&l=
Тут тоже есть соображения по поводу моделей

Дополнение: знаю одну методу, связанную с сохранением 3Д в нередактируемые форматы, но назвать ее хорошим решением не могу, т.к. с "живой" сборкой людям еще работать надо (оснастка, ЧПУ).

    Вы совершенно правы. При таком раскладе теряется основной смысл создания электронной модели.
У нас пока действует метод сохранения в архиве "фотографий" в формате PDF сборочных чертежей, получаемых из ProE.
(уже 10 лет). И это очень опасно, т.к. риски, связанные с локальным хранением ранее созданных моделей стали столь велики, а вероятность их потери так велика, что предпринимаются чрезвычайные меры по их спасению всеми доступными способами. Пока разрешено сдавать в архив только модели деталей.
    Наше СТП устанавливает следующее
    Модель детали (ЭМД) и модель сборочной единицы (ЭМСЕ) могут быть выполнены в виде самостоятельных документов или входить составными частями в ДЭ (чертеж детали, сборочный чертеж, документ "Данные проектирования".
ЭМД (ЭМСЕ), как составная часть ДЭ, может быть выполнена:
   - в виде данных, параметрически связанных с чертежом детали (сборочной единицы) и являться его составной частью (ЭМД, спроектированная в САПР ProEngineer);
  - в одном или нескольких отдельных графических слоях файла, содержащего чертеж детали (ЭМД, спроектированная в CorelDraw );
  - в виде базы данных проекта в составе документа "Данные проектирования" (электронная топология печатной платы спроектированная в САПР PCAD или ORCAD.
    Чертеж детали и сборочной единицы, должен соответствовать требованиям ГОСТ 2.109, а также содержать все необходимые требования, выполнение которых должно обеспечивать изготовление и контроль детали.
    Для обеспечения изготовления деталей, получаемых методами фотохимического нанесения изображений, контактной печати или иными аналогичными методами, в технических требованиях на чертеже детали, ссылки на шрифт, размеры шрифта, расположение надписей и т.п. не приводят, а приводят запись по типу: "Не указанные размеры изображений (линий, надписей) и их взаимное расположение должны соответствовать графике электронной модели детали".
    Требования к ЭМД и ЭМСЕ устанавливаются по согласованию с технологическим подразделением.
    Выполнение требований к разработке ЭМД и ЭМСЕ является обязательным.

[Николай Н]

Почитайте ГОСТ 2.111 "Нормоконтроль"
Еще почитайте ГОСТ 2.102

Для начала, 2.102, по моему, содержит неверное определение 3Д-сборки. Цитата: "Документ, содержащий ... модели составных частей". Разьве это так?
А 2.111 тоже по-моему мало что проясняет, скорее наоборот.
Согласно ему, при проверке моделей проверяется "соответствие чертежей, получаемых из модели, стандартам ЕСКД". Два вопроса:
1.Причем здесь чертежи, ведь проверяем мы Модель? Получается довольно косвенный способ проверки, и даже несколько странный, если мы работаем вообще без чертежей.
2. Прочитав это, можно подумать, что нормоконтролер должен сам сделать чертеж с модели (+ оформить его), чтобы проверить его на соответствие ЕСКД. Так что-ли? Ладно, идем "как надо". Конструктор предьявляет модель и чертеж. Каковы действия нормоконтролера? Согласно ГОСТ, это лишь проверить "соответствие чертежей стандартам ЕСКД". Как он может проверить, что (а) чертеж вообще получен с модели, и (б) что он ей соответствует? Да, с момента получения 2Д с 3Д у нас есть ссылки, но ведь с этого момента 2Д изменялось.
То же самое можно сказать и про ЭСИ со спецификациями.
Подчеркну еще вот какую мысль: Почему собственно правильность информации первичной проверяется по информации вторичной? Ведь вторичная определяется инструментом (!) ее получения. Т.е. кривой формирователь спецификации еще не говорит о кривизне самой ЭСИ. А отсутствие в каком-то 2Д-САПР правильного обозначения какого-нибудь отклонения от плоскостности по ЕСКД еще не говорит о кривизне 3Д-модели.
Вот такие соображения.
Вы все еще верите в электронный документооборот в соответствие с ЕСКД?

[YorikER]

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

[tramp_m]

Благодарю Вас Yoriker согласен. А по отношению к ЕСКД и всей стандартизации - просто эта вещь требует оооочень внимательного рассмотрения, для которого не хватает в наше летящее, правда не понятно за чем, время.
  В ранних топиках я уже писал, о необходимости  разработки интерфейса САПР  для более корректного функционирования процесса проектирования - безбумажной технологии и в конце концов и у фискалов, которые рвутся всё контролировать, вплоть до  творческого процесса останется несколько шансов кое-что увидеть.
Ну а поскольку у некоторых участников форума появилось желание обсудить проблемы  и принципы построения САПР как безбумажной технологии, то предлагаю начать с обсуждения правил построения алгоритма такой системы исходя из тематики форума. Ну придать более практичное направление обсуждению.

[YorikER]

Это отдельная тема... И на мой взгляд нельзя отрывать систему САПр от единого информационного пространства предприятия, т.к. очень многие объекты САПр неразрывно связаны с другими блоками. В беседах с АСКОНОМ я не раз отмечал, что представленный ими на рынке функционал слишком похож на лоскутное одеяло разных по структуре содержимого болков, исскуственно сшитых, как нитками, весьма спорнымми интеграционными механизмами. Именно в интеграционных процессах и возникают противоречия с реалиями и всех пользователей продуктов АСКОН. К примеру вопрос: почему справочник материалов реализован не на платформе ЛОЦМАН, а как отдельная разработка на базе SQL? ведь объекты этой базы данных - это объекты бизнес-процессов материально-технического снабжения и технической подготовки производства. Почему Вертикаль также отдельное приложение со своими заморочками и только сохраняет свой результат в ЛОЦМАНе, а не создан на платформе ЛОЦМАНа. Ведь любой технологический процесс, операция, переход, инструмент, приспособление и т.д. - это объекты материального производства... Мы довольно-таки быстро отсказались от такого подхода и реализовали все эти задачи на платформе ядра ЛОЦМАНа. Не могу похвастаться 100%-ным успехом, к сожалению мешает "человеческий фактор", но разработки есть... В качестве старта для обсуждения могу высказать свое мнение: единое информационное пространство предприятия базируется на "трех китах": информационная модель предприятия, информационная модель изделия и информационная модель бизнес-процессов (см. рисунок). На рисунке отображена зона наиболее удачного внедрения ЛОЦМАНа, как единого ядра, на базе которого могут строится все модули...

[tramp_m]

Как я уже ранее писал в других топиках    САПР – есть именно то, что объединяет другие блоки в единую систему. Объединяет все лоскуты в единое одеяло. Информационная система предприятия, это прежде всего единая база данных состоящая из трех разделов 1.графического 
2 текстового
3 фактографического
       САПР  организовывает информационный обмен между разделами базы данных.
Единая  информационная система предприятия это и есть  САПР да вы правы.
Только,  вы немного не верно расставили приоритеты.
Если начать с нуля как точка отсчета.
1 Идея
2 эскиз разработки
3 маркетинг
4 конструкторская подготовка
5 технологическая подготовка
6 административные задачи
7 предпроизводственная стадия
8 организационно-экономическая подготовка
9 производство
10 Реализация (продажа продукта производства)
Предлагаю обсудить для начала состав базы данных по пунктам.

[Askh]

На мой взгляд САПР является частью ЕИП

[YorikER]

Предприятия бывают разные, соответственно и структура информационного пространства должна быть разная... Очень приятно, что САПр выделенно такое внимание, но на мой взкгяд, уважаемый tramp_m вы погорячились... Все таки САПР - это составляющая единого информационного пространства... Другой вопрос, если предприятия является проектным (т.е. проект является определяющим бизнес-процессом) то действительно САПр может играть большую роль в общей системе...
Теперь насчет порядка бизнес-процессов... Идея никогда не возникает сама по себе... Для того, чтобы что-то родить, необходимо изучить потребности рынка... Что же что-то такое сделать, чтобы что-то продать... Этот процесс и есть маркетинг... Теперь там где проект играет определяющую роль, между маркетингом и конструкторской подготовкой производства можно выделить отдельный идеологический процесс, где идеи (или задания маркетинга) превращаются в проект изделия, и только потом, когда проект изделия прошел все согласования с рынком, запускается чисто конструкторская подготовка производства... По-моему так... Ну а если стартовать, то на мой взгляд необходимо начинать со структуры предприятия (подразделения, рабочие места, рабочие папки, штатное расписание, кадры, зоны ответственности и доступа и т.д.), ведь в любом документе присутствует ФИО автора и обозначение подразделения... Затем структура изделия, причем начинать с переписки: запросы заказчиков, запросные листы, договор, ведомость поставки, заказ, отгрузочный комплект, конструкторский состав изделия, PLM состав изделия и т.д.

[tramp_m]

«Предприятия бывают разные, соответственно и структура информационного пространства должна быть разная...»  точно так уважаемый Yoriker и поэтому как я уже писал в других топиках САПР-система автоматизированного проектирования, ведения работ, вещь сугубо индивидуальная для каждого предприятия со своим частным интерфейсом САПРа. Именно она объединяет в единое информационное пространство  предприятие. И не важно какое это предприятие, проектное или производственное, отличие только в том, какие конструкторские разработки осуществляет предприятие (разработку КД на город, поселок, дом, завод, цех, участок, изделие, технологическую оснастку  или еще на что), а важно какая выходит продукция. Именно в этом и будет различие САПРов.
А на счет «порядка бизнес-процессов...» позвольте не согласиться идея (ноу-хау и прошу не путать заказ на разработку мелких не принципиальных модернизаций, изменений и т.п. и т.д.) возникает сама по себе, чтобы её поняли её оформляют КД и может быть не один раз пока не поймет инвестор. После этого проводят маркетинговые (изучение потребности рынка...) исследования. Творческий процесс не подчиняется плановому регулированию, скорее всего наоборот, где начинается диктат, творческий процесс угасает. А то получается, что у нас на сегодя запланировано 10 подвигов – ну как у Барона Мюнхаузена. Или давайте посчитаем, то что собственно ещё и не спроектировали и не произвели, так что ли. Нет уж позвольте с вами не согласиться.
  Ну а если стартовать, то с «размера» предприятия  (кол-во работников) и сферы деятельности – проектное или производственное
серийности продукции.
Хотя бы так для начала.

[sulyco]

Трамп, вы немного зациклились на САПРе. Она, конечно, важная часть (зачастую даже очень) в обеспечении жизненного цикла изделия, но отнюдь не всегда определяющая и необходимая. Масса предприятий работают без САПР и не  планируют её внедрение.
Пррошу прощения за офф-топ.

[YorikER]

Да в общем-то я и не собираюсь спорить, уважаемый tramp_m... Если Вы так видите свое информационное поле, то пожалуйста стройте его так как считаете нужным. Я вижу свое поле деятельности так и строю его в соответствии со своим пониманием... На сайте www.infnt.ru более подробно все описано... Сейчас уже запущен новый проект: Visual Loodsman... Для него пишется учебное пособие (входит в дистрибутив), в нем будет описан процесс моделирования информационного пространства предприятия, будет представлена демонстрационная база данных... В ней отражу свои мысли более подробно... Импонирует Ваша уверенность, наверное она на чем-то обоснована... Хотя мне кажется, что насчет САПр Вы поторопились... С уважением...

[tramp_m]

Точно уважаемый sulyco и масса предприятий работают без САПР за кукльманом или на не системных АРМ (автоматизированных рабочих местах ) с разными базами данных для них и барахтаются в поисках ранее оформленной информации в куче файлов с оригинальными именами, которые ооочень проблематично вспомнить, где они находятся, и какое отношение они имеют к определенной теме и заказчику.
Да, я немного зациклился на САПРе признаю, но своё мнение высказал .И всё таки  Вам по теме может быть есть что сказать и не только для меня?

[tramp_m]

Уважаемый Yoriker ценю Ваш опыт и успехи в моделирования информационного пространства предприятия. Успехов в новом проекте Visual Loodsman...  Желаю удачи в гармоничной интеграции ПО с графической, текстовой и фактографической
базой данных КОМПАС в будущем