Спецификации

[AnTe 1]

Неверно.

Конструктор всегда делает полную компоновку своего творения, посему если ЭСИ правильно строится с модели, а спецификация с ЭСИ, то для него это уже снятие лишней головной боли.

Для построения спецификации по ЭСИ, необходимо, чтобы как минимум в ЭСИ были прописаны позиции деталей на чертежах. А разве они там будут? :(

Вот пусть и появится в контекстном меню, что появляется при щелчке правой кнопкой мыши по ЭСИ строчка "создать спецификацию".

Нечто подобное уже сейчас реализовано в SWR-PDM.

У нас используется Catia :( сам делать такое начал, но всё равно "что-то здесь не так":)

[AnTe 1]

А вот неожиданный вопрос....

Подскажите, кто знает! Что такое ЭСИ?

По ГОСТ 2.053 - это "Конструкторский документ, содержащий состав сборочной единицы, комплекса или комплекта и иерархические отношения (связи) между его составными частями и другие данные в зависимости от его назначения."

ДЭ (Документ Электронный), по ГОСТ 2.051 - это "Документ, выполненный как структурированный набор данных, создаваемых программно-техническим средством."

По ГОСТам конструкторских документов, каждый документ должен быть завизирован кучей подписей, например, обязательны - разработчик и н.контр.

Но ЭСИ, которую создаю я, и, если я правильно понял, уже созданы на многих предприятиях, - это база данных, с иерархическими связями?!

Два вопроса:

1. ЭСИ на нулевую сборку (автомобиль), и на подсборку (мост) - это два разных документа?

2. Как сохраняется предыдущая версия документа? Всю БД слить на диск (скопировать в другое место)? Либо ГОСТ позволяет, чтобы используемая компьютерная система динамически строила ЭСИ, каждый раз, в зависимости от запроса "версии"?

Убился я уже эти ГОСТы читать, как их понимать? :(

Может, кто-нибудь использовал ЭСИ, как ДОКУМЕНТ, а не как 'удобную' базу данных? Или, хотя бы имеет представление о том, как это сделать?

ps если я ошибся темой, ткните меня, пожалуйста, в нужную!

[sceptic 0]

Два вопроса:

1. ЭСИ на нулевую сборку (автомобиль), и на подсборку (мост) - это два разных документа?

2. Как сохраняется предыдущая версия документа? Всю БД слить на диск (скопировать в другое место)? Либо ГОСТ позволяет, чтобы используемая компьютерная система динамически строила ЭСИ, каждый раз, в зависимости от запроса "версии"?

1.ЭСИ на автомобиль содержит в структуре и подсборку - мост. По-моему, это очевидно.

2.Сохранять, в принципе, можно как угодно и где угодно. И система может строить ЭСИ в зависимости от запроса "версии". И каждая версия может сохраняться отдельно в БД.

Сложнее вопрос из предыдущего поста:

Для построения спецификации по ЭСИ, необходимо, чтобы как минимум в ЭСИ были прописаны позиции деталей на чертежах. А разве они там будут? :(

На него я затрудняюсь ответить. То ли надо на чертеже указывать позиционные обозначения и атрибуты "поз.обозн." составных частей в ЭСИ одинаковые, то ли вообще без них обходиться, то ли без СБ

Но вроде бы необходимость СБ не обсуждается, вопрос только в замене спецификации электронной структурой изделия.

[AnTe 1]

1.ЭСИ на автомобиль содержит в структуре и подсборку - мост. По-моему, это очевидно.

Да, но документ ЭСИ, на подсборку - мост, как отдельный ДОКУМЕНТ, существует?

2.Сохранять, в принципе, можно как угодно и где угодно. И система может строить ЭСИ в зависимости от запроса "версии". И каждая версия может сохраняться отдельно в БД.

А ГОСТы это позволяют делать? Ведь документ - это что-то, ПОДПИСАННОЕ людьми. Это не просто запрос.

То ли надо на чертеже указывать позиционные обозначения и атрибуты "поз.обозн." составных частей в ЭСИ одинаковые, то ли вообще без них обходиться, то ли без СБ

Но вроде бы необходимость СБ не обсуждается, вопрос только в замене спецификации электронной структурой изделия.

а СБ - это что?

[AnTe 1]

Подумал,.. и вопросы про ЭСИ вынес в отдельную тему!

<noindex>http://fsapr2000.ru/index.php?showtopic=22357</noindex>

[Странник 6]

Для построения спецификации по ЭСИ, необходимо, чтобы как минимум в ЭСИ были прописаны позиции деталей на чертежах. А разве они там будут? :(

Непременно должен быть и этот механизм, ИМХО для программиста это не сложно.

[brigval 722]

Спецификация - основной конструкторский документ, при бумажном документообороте.

А что с ней случается, при переходе на электронный?

Ничего с ней не случается. Структура изделия строится на основе основного конструкторского документа - СПЕЦИФИКАЦИИ.

Вот <noindex>пример</noindex>

[VOleg 228]

Ничего с ней не случается. Структура изделия строится на основе основного конструкторского документа - СПЕЦИФИКАЦИИ.

Вот <noindex>пример</noindex>

Я бы уточнил, что спецификация - это и есть структрура изделия. И ее достаточно. Мы просто вводим в базу спецификацию и все. Далее база данных уже не нуждается в дополнительных вводах, двойной работе, дублировании и т.п. и т.д. Она уже просто отвечает на любые вопросы любых работников.

Еще раз уточняю, что у нас конструктора только строят модель изделия в SW и все. Далее другие "чертят" чертежи, вводят СП в базу данных - уже из базы данных печатаются спецификации по ГОСТ (но спецификации уже как элемент базы данных). Все просто. Конструктор даже не подписывает спецификации, а часто, и чертежи - его задача только "идеальная" модель.

[brigval 722]

Я бы уточнил, что спецификация - это и есть структрура изделия. И ее достаточно. Мы просто вводим в базу спецификацию и все. Далее база данных уже не нуждается в дополнительных вводах, двойной работе, дублировании и т.п. и т.д. Она уже просто отвечает на любые вопросы любых работников.

Еще раз уточняю, что у нас конструктора только строят модель изделия в SW и все. Далее другие "чертят" чертежи, вводят СП в базу данных - уже из базы данных печатаются спецификации по ГОСТ (но спецификации уже как элемент базы данных). Все просто. Конструктор даже не подписывает спецификации, а часто, и чертежи - его задача только "идеальная" модель.

Я бы уточнил, что спецификация - это и есть структрура изделия.

Поддерживаю, но не полностью. Спецификация еще включает состав и входимость конструкторской документации (структуру или схему документации), по которой изделие изготавливается, эксплуатируется и ремонтируется.

у нас конструктора только строят модель изделия

У меня конструктора делают модели и автоматом выводят из них готовые спецификации по ЕСКД. В базу данных ничего вручную не заносится.

Программа БрагинДок сама находит все спецификации, обрабатывает их и выводит нужный результат в наглядном виде.

То есть, в системе БрагинДок достигнуто единство: спецификация - это и конструкторский документ и хранилище данных об изделии одновременно. Так сказать, все в одном флаконе (файле).

Естественно, что спецификации могут разрабатываться и автоматизированно и вручную и комбинированным способом. Для БрагинДока способ получения не имеет значения, потому что программа работает только с записями в сп.

Вывод: пользуясь системой БрагинДок можно проектировать в любых САПР. Что и имеет место быть на самом деле.

Но это так. К слову.

[VOleg 228]

У меня конструктора делают модели и автоматом выводят из них готовые спецификации по ЕСКД.

Вот здесь бы поподробнее - как это сделать в Солиде???

А то приходится создавать чертеж с одной СП и это часто вносит путаницу.

У нас СП делают чертежники при создании сборочного чертежа - и частенько плавают позиции - здесь тоже бъемся без стабильного результата.

[DSV 2]

Спецификация - основной конструкторский документ, при бумажном документообороте.

А что с ней случается, при переходе на электронный?

Если вернуться к началу и ответить на поставленный вопрос прямо!

Спецификация как отражение конструкторского состава остается в PDM системе и своей значимости не теряет. Как она визуализируется в принципе не важно. Когда проект завершен, она становится документом, если ее выводить из системы. всякие фалы это ложный путь!

[brigval 722]

Вот здесь бы поподробнее - как это сделать в Солиде???

Подробнее. Я разработал программу для выпуска сп по ЕСКД. Начал делать ее и для Солида. Но поскольку сам в Солиде не работаю, оставил пока это дело.

Программа называется <noindex>Таип</noindex>. Сделана для Инвентора. По функционалу, наверное, не уступит SWR-Спецификации. Хотя я не сравнивал.

Когда проект завершен, она становится документом, если ее выводить из системы. всякие фалы это ложный путь!

Не возражаю. Замечу только, что на копьютере все документы хранятся в виде файлов. Другого не дано.

Поэтому отбрасывать файлы из электронного документооборота не есть правильно.

[AnTe 1]

Ничего с ней не случается. Структура изделия строится на основе основного конструкторского документа - СПЕЦИФИКАЦИИ.

К сожалению, texcel не установилась на моём компьютере, о чём я сообщил в соотв. форум, поэтому выскажу лишь предположения.

Во-первых, 53й ГОСТ рекомендует СП получать автоматизированным способом из ЭСИ, а не наоборот, ну да ладно.

Я уже писал, в теме "ЭСИ", о том, что рассматривал такой вариант - ЭСИ из СП. А у Вас как это реализовано? Вот проект, самолёта :) Тысячи спецификаций, в куче, на основе их, по команде команда формирует пресловутое ОБДИ для изделия? Потом пользователь запросами достаёт нужную информацию, например, лазит по дереву, если нужно? А что при добавлении новой спецификации? База обновляется? А если в СП изменения, т.е. выпущена новая версия СП, - что происходит с базой? Старая ветка удаляется, новая добавляется? Или заново ВЕСЬ самолёт:) перестраивать?

Или никакая ЭСИ не строится, и тысяча спецификаций шерстится КАЖДЫЙ раз, после каждого запроса пользователя?

[askn 0]

К сожалению, texcel не установилась на моём компьютере, о чём я сообщил в соотв. форум, поэтому выскажу лишь предположения.

Во-первых, 53й ГОСТ рекомендует СП получать автоматизированным способом из ЭСИ, а не наоборот, ну да ладно.

Я уже писал, в теме "ЭСИ", о том, что рассматривал такой вариант - ЭСИ из СП. А у Вас как это реализовано? Вот проект, самолёта :) Тысячи спецификаций, в куче, на основе их, по команде команда формирует пресловутое ОБДИ для изделия? Потом пользователь запросами достаёт нужную информацию, например, лазит по дереву, если нужно? А что при добавлении новой спецификации? База обновляется? А если в СП изменения, т.е. выпущена новая версия СП, - что происходит с базой? Старая ветка удаляется, новая добавляется? Или заново ВЕСЬ самолёт:) перестраивать?

Или никакая ЭСИ не строится, и тысяча спецификаций шерстится КАЖДЫЙ раз, после каждого запроса пользователя?

Если в информационную систему в дерево будут добавляться файлы "со спецификацией" (по сути, будет сохраняться отчет, то будет дублирование информации в системе), то при внесении изменений в дерево базы за этими сохраненными отчетами придется следить как за документами (в общем-то, они и будут документами), вносить изменения по извещениям.

Дальше вопросы:

1) оно надо - дублировать информацию, делая из отчетов документы, если ВСЕ пользователи информации работают в единой ИС и ее интерфейс даже удобнее картинки спецификации?

2) если какие-то пользователи информации не работают в ИС, значит для них нужно выпускать документы. По ЕСКД. И если они бумажные, то опять же: оно надо - делать файловые копии "со спецификацией", если можно оперативно печатать сам отчет?

[AnTe 1]

Неожиданно форум глюканул.. Ответ с опозданием:)

У меня конструктора делают модели и автоматом выводят из них готовые спецификации по ЕСКД. В базу данных ничего вручную не заносится.

Как я понял, только работая в строго определённой системе.

Для БрагинДока способ получения не имеет значения, потому что программа работает только с записями в сп.

Вывод: пользуясь системой БрагинДок можно проектировать в любых САПР. Что и имеет место быть на самом деле.

Отказавшись от средств автоматизации, используемых в этих системах? Или СП, полученные, скажем, в Mechanics, система тоже схавает?

Если я правильно понял, БрагинДок - это документооборот, который, по определению, к используемому САПР имеет весьма опосредованное отношение....?

Если вернуться к началу и ответить на поставленный вопрос прямо!

Спецификация как отражение конструкторского состава остается в PDM системе и своей значимости не теряет. Как она визуализируется в принципе не важно. Когда проект завершен, она становится документом, если ее выводить из системы. всякие фалы это ложный путь!

Пожалуй, вопрос заключается в том, каким образом превратить запрос в PDM, в ЭЛЕКТРОННЫЙ ДОКУМЕНТ.

[AnTe 1]

1) оно надо - дублировать информацию, делая из отчетов документы, если ВСЕ пользователи информации работают в единой ИС и ее интерфейс даже удобнее картинки спецификации?

Полагаю, ответ будет "оно не надо". Именно поэтому основное направление - отказ от СП, как отчёта-документа, в виде "для бумаги".

Но! Взамен нужно предложить ДЭ (электронный документ), под названием ЭСИ, который и будут заверять своими подписями участники процесса!

А если возникает вопрос, "нужны ли конструкторские документы", то, думаю, ответ на него очевиден....? Или не совсем?..

2) если какие-то пользователи информации не работают в ИС, значит для них нужно выпускать документы. По ЕСКД. И если они бумажные, то опять же: оно надо - делать файловые копии "со спецификацией", если можно оперативно печатать сам отчет?

В ГОСТ 2.051, про ДЭ, разделяют внутреннее и внешнее представление ДЭ, если я правильно понял, то отчёт, полученный в любой форме, содержащий всю необходимую информацию, будет твёрдой копией документа. И не важно, файл это, или бумага. Осталось её только заверить ответственным за изготовление копий лицом.

[brigval 722]

Во-первых, 53й ГОСТ рекомендует СП получать автоматизированным способом из ЭСИ, а не наоборот, ну да ладно.

По моей информации разрабатывали эти ГОСТы чистые программеры, которые и спецификацию до этого в глаза не видели. Что они могут написать?

Те люди, которые с ними работают, начинают их убеждать, что основой должна быть сп, а не наоборот. Как это и предусматривает ЕСКД.

Что из этого выйдет я не знаю.

Вот проект, самолёта

Я такими категориями не мыслю. Спецификации в системе БрагинДок пока считываются каждый раз заново.

Если их будет много и объем будет большой надо будет подумать о кэшировании. Как это сделать я примерно представляю.

Но в любом случае вся информация будет браться из сп, в том числе и сама ЭСИ.

А что при добавлении новой спецификации? База обновляется? А если в СП изменения, т.е. выпущена новая версия СП, - что происходит с базой? Старая ветка удаляется, новая добавляется? Или заново ВЕСЬ самолёт:) перестраивать?

Или никакая ЭСИ не строится, и тысяча спецификаций шерстится КАЖДЫЙ раз, после каждого запроса пользователя?

При добавлении новой сп она автоматически берется на учет. И занимает свое место в структуре КД.

Если есть изменения в процессе разработки, то о версиях можно не очень беспокоиться.

При разработке КД всегда улучшается. Конструкторы, как правило не оперируют понятем версия. С версиями работают программисты.

Изменения учтенной КД (сданной в архив) происходят по ИИ. Там тоже порядок.

В принципе, скачайте <noindex>это</noindex>. Там вы найдете ответы на многие вопросы.

Система для не больших организаций. 5-15 проектировщиков.

Так как вопросы прав доступа и скорости работы в ней решаются пока очень простыми способами.

Надеюсь, программа Texcel установилась?

Как я понял, только работая в строго определённой системе.

Конечно. Без правил никуда.

Отказавшись от средств автоматизации, используемых в этих системах? Или СП, полученные, скажем, в Mechanics, система тоже схавает?

Запросто. Если Мехникс будет выводить сп по правилам Texcel

Если я правильно понял, БрагинДок - это документооборот, который, по определению, к используемому САПР имеет весьма опосредованное отношение....?

БрагинДок позволяет работать с любым САПРом на оговоренных заранее условиях.

Я сейчас использую Инвентор, Автокад, Ворд, Ексель. На одном из предприятий чертежи разрабатвают в Компасе.

Про Солид я говорил.

БрагинДок обрабатывает данные созданных в других системах сп, выведенных в Excel. Поэтому, БрагинДоку не важно в какой системе идет проектирование. Я думаю, что это достоинство системы.

Пожалуй, вопрос заключается в том, каким образом превратить запрос в PDM, в ЭЛЕКТРОННЫЙ ДОКУМЕНТ.

Если это ко мне, то я не не в курсе.

[askn 0]

Полагаю, ответ будет "оно не надо". Именно поэтому основное направление - отказ от СП, как отчёта-документа, в виде "для бумаги".

Но! Взамен нужно предложить ДЭ (электронный документ), под названием ЭСИ, который и будут заверять своими подписями участники процесса!

А если возникает вопрос, "нужны ли конструкторские документы", то, думаю, ответ на него очевиден....? Или не совсем?..

В ГОСТ 2.051, про ДЭ, разделяют внутреннее и внешнее представление ДЭ, если я правильно понял, то отчёт, полученный в любой форме, содержащий всю необходимую информацию, будет твёрдой копией документа. И не важно, файл это, или бумага. Осталось её только заверить ответственным за изготовление копий лицом.

Я уже писал в прошлых постах, что документы следует порождать тогда, когда они нужны. В данном контексте спецификации или ЭСИ могут быть нужны только в 2 случаях - для передачи на сторону (пользователям информации, не имеющим доступа к исходной ИС) и в долговременный архив.

Если этого нет - то нет причин дублировать информацию в ИС, оформляя ее по правилам (ГОСТам), для самой ИС и ее пользователей не нужным.

[AnTe 1]

Я уже писал в прошлых постах, что документы следует порождать тогда, когда они нужны. В данном контексте спецификации или ЭСИ могут быть нужны только в 2 случаях - для передачи на сторону (пользователям информации, не имеющим доступа к исходной ИС) и в долговременный архив.

Если этого нет - то нет причин дублировать информацию в ИС, оформляя ее по правилам (ГОСТам), для самой ИС и ее пользователей не нужным.

по ГОСТам, по СТП, но работу, результат, ведь должен кто-то, закончив, ПОДПИСАТЬ? Даже если этим результатом пользуются не на стороне.

Вот и появляется понятие документа...

[AnTe 1]

По моей информации разрабатывали эти ГОСТы чистые программеры, которые и спецификацию до этого в глаза не видели. Что они могут написать?

Те люди, которые с ними работают, начинают их убеждать, что основой должна быть сп, а не наоборот. Как это и предусматривает ЕСКД.

Что из этого выйдет я не знаю.

Скорее всего, ничего, потому что, по моему мнению, ЕСКД на ДЭ должны создавать те, кто понимает, что такое ДЭ, и как это возможно технически реализовать... Понятно, что стандарты "сырые", но, по-моему, путь взят правильно.

Я такими категориями не мыслю. Спецификации в системе БрагинДок пока считываются каждый раз заново.

Если их будет много и объем будет большой надо будет подумать о кэшировании. Как это сделать я примерно представляю.

Но в любом случае вся информация будет браться из сп, в том числе и сама ЭСИ.

Честно говоря, я не совсем понимаю, что в данном случае понимается под "кэшированием", однако, я с трудом представляю, каким образом информация по мало-мальски крупному изделию сможет браться из набора СП.

Попробую пояснить. ЭСИ предназначена для представления информации о составе, иерархии изделия, вариантов состава, различной информации по нему, и пр, что-то подобное даже в 53м ГОСТе написали. Кстати, по-моему, тем самым внеся полную путаницу, превратив определение ЭСИ в определение ОБДИ, из которого, по их же рекомендациям, должа получаться ЭСИ.

т.о. под ЭСИ имеется в виду информационная система, по крайней мере, подразумевается существование такой системы на предприятии (её назвали ОБДИ). Я не представляю, как это можно реализовать без использования баз данных. Каким образом пользователь сможет получать информацию обо всех изделиях? Каждый раз перебирая тысячи и тысячи спецификаций? А по сети?? Перебирать эти СП будет серверная часть? Клиентской уж подобное точно доверять не стоит - сразу вся сетка повиснет.

Технологии доступа к большим массивам данных прекрасно реализованы в различных СУБД, изобретать велосипед смысла нет, тем более, что вряд ли полученный в результате самокат далеко уедет :(. А отсюда следует, что наиболее логичный путь - держать структуру изделия в БАЗЕ ДАННЫХ. Как туда попадёт информация - вопрос отдельный, быть может, с временно созданного документа СП (это мой путь, кстати). А если структура в БД уже имеется - вполне логично получить из неё ЭСИ (или эта БД уже называется ЭСИ, не понятно). Или даже СП, отчётом.

По всей видимости, с учётом Вашего замечания по поводу ограничений вашей программы, для Вас все эти рассуждения относятся больше к теории (правильно ли написаны ГОСТы).

А для меня - реальность (пользователей в сотни раз больше)

Запросто. Если Мехникс будет выводить сп по правилам Texcel

БрагинДок позволяет работать с любым САПРом на оговоренных заранее условиях.

Я сейчас использую Инвентор, Автокад, Ворд, Ексель. На одном из предприятий чертежи разрабатвают в Компасе.

Про Солид я говорил.

БрагинДок обрабатывает данные созданных в других системах сп, выведенных в Excel.

В определённом формате?

Поэтому, БрагинДоку не важно в какой системе идет проектирование. Я думаю, что это достоинство системы.

Открытый формат файлов - всегда достоинство системы. Но, если спецификации формата нет - то его открытость под вопросом. :(

ps у меня texcel не заработал, поэтому судить о простоте формата файла СП, используемым БрагинДок, (простоте настолько, что не нуждается в отдельном описании) я не могу, поэтому, может и ошибаюсь.

Изменено 25 июня 2008 пользователем AnTe