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

[AnTe 1]

Прошу прощения, за запоздалый ответ, лучше поздно, чем никогда ;)

Согласно ГОСТ 2.102 спецификация это "Документ, определяющий состав сборочной единицы, комплекса или комплекта". О форме ничего не сказано в определении спецификации.

Действительно, интересный момент. В ГОСТе, описывающем виды конструкторских документов, действительно, не содержится указаний, по поводу их формы. Особенно после последних изменений.

Однако, получается, если сделать вид, что мы абсолютно ничего не знаем о ГОСТ 2.106, в котором конкретизирована и информация, к-ую должна содержать спецификация, и её бумажное представление, то под ней можно подразумевать что угодно, лишь бы состав сборочной единицы был? А есть ли смысл так делать?

Однако, Игорь, Вы правильно продолжаете:

В другом стандарте ГОСТ 2.106 рассказывается как заполнять спецификацию. Опять же не обязательно на бумаге. Да сейчас в бумаге практически никто и не разрабатывает спецификации. ВСЕ делают спецификации в ЭЛЕКТРОННОМ виде. А потом только выводят на бумагу.

Как делают спецификации - вопрос второй, проблема в том, что считать документом. Либо бумагу, либо эл. документ. И определить его форму.

Если я правильно понимаю, именно попытка определения формы СП сделана в ЭСИ. Всё-таки, у нас здесь возникает постоянный разнобой в терминологии: зачастую под ЭСИ понимает ОБДИ, с которой получают отчёты, я предлагаю остановиться на одном определении, которое, по-моему, напрямую следует из ГОСТ 2.053, а именно, изложу своими словами: ЭСИ == СП + дополнительные данные + имеется возможность доступа ко всем полям и - (отминусовать:)) жёсткую форму бумажного отчёта.

последнее явно прописано в комментарии к п. 4.1, "ЭСИ не имеет бумажной формы выполнения"

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

Именно так! Именно поэтому в 53м госте, в п 5.4 чётко описаны требования к электронному документу, которые предполагают доступ к данным из него, в открытом формате, и даже определён этот формат: STEP (ИСО 10303)

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

...

Всё правильно, и в ГОСТ 053 даже дают рекомендации, из каких именно приложений может формироваться ЭСИ ;) из ОБДИ в т.ч. из различных САПР

Форма (бланк) спецификации в электронном виде должна совпадать с формой спецификации и в бумажном виде. Что очень привычно и удобно для работы с документом на производстве.

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

Кстати, огромная просьба, если у кого-нибудь есть замечания по поводу такого интерфейса, - высказать их, не стесняясь в выражениях :)

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

[AnTe 1]

А в целом я согласен, что при изменении ЕСКД следовало сосредоточиться на особенностях электронной формы исполнения спецификации, а не называть ее ЭСИ (то есть не вводить новый вид документа).

А что страшного во введении нового типа документа?

Полагаю, что в ЭСИ дано 'начало' электронному виду СП. Описана форма исполнения, а поля - пишите какие хотите. В упомянутом ГОСТ 2.106 конкретизированы поля, графы, какую информацию в них вписывать. В опредении ЭСИ их нет. Быть может, для начала, их можно подчистую "списать" из ГОСТ 2.106 ? ;)

[brigval 722]

проблема в том, что считать документом. Либо бумагу, либо эл. документ.

Для меня проблемы здесь нет. Надо просто посмотреть, чем один конструкторский документ отличается от другого конструкторского документа и чем конструкторский документ отличается от не конструкторского документа. Глобально.

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

Конструкторский документ - это то что имеет обозначение.

Не важно, в какой форме это что-то (электронная, бумажная, гранитная). Есть обозначеие - есть конструкторский документ. Нет обозначения - нет конструкторского документа.

Когда появляется конструкторский документ? Конструкторский документ в документообороте (и в бумажном и в электронном) появляется как только зарегистрировано его обозначение. Только после того, как повляется обозначение документа, можно производить и операции с документом. Как в бумажном документообороте, так и в электронном.

[brigval 722]

Кстати, огромная просьба, если у кого-нибудь есть замечания по поводу такого интерфейса, - высказать их, не стесняясь в выражениях :)

Замечаний по интерфейсу нет. Так как он очень простой.

Но

1 Содержание - от балды (извините, сами просили не стесняться). Так не бывает.

2 Заголовки разделов не выделены пустыми строками. Это ухудшает читабельность.

3 Весь текст набран в верхнем регистре. Ухудшает читабельность.

4 Не понятно назначение красного цвета.

[Странник 6]

Знаете в чём реальная сложность автоматического создания спецификации в электронном виде?

Это же самое можно назвать построением правильной ЭСИ.

В том, что такая спецификация (ЭСИ) должна считывать параметры как минимум из 3 типов электронных конструкторских документов (при чём ещё не факт, что все эти документы будут делаться в базовом CAD), да ещё и добавляет собственных!

Итак:

1. Модели

-Модели входящих деталей и подсборок. Каждая из них даёт "Обозначение" и "Наименование".

-Модель собственной сборки. Из неё, кроме выше названных "Обозначения" и "Наименования" нужно заполучить ещё и количество вхождений каждого из дочерних элементов.

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

-Стандартные изделия должны строиться и распознаваться автоматически, а это тоже дело с тонкостями, с точки зрения моделей.

2. Чертежи.

-Дочерних деталей и подсборок. С каждого из них нужно считать используемый формат или группу форматов.

-Собственный сборочный чертёж, из него кроме формата нужно как-то исхитриться считать разбивку на зоны (хотя это и не столь часто востребованно).

3. Всякого рода внешние документы (РР, ТУ, схемы электрические принципиальные и т.д.)

-Форматы.

-Названия разъёмов и контактных групп.

-....

4. Сама ЭСИ (СП).

-Позиции.

-Примечания (то бишь как то надо извернуться и задать дополнительные связи компонентов меж собою и со вне).

При этом сие нагромождение противоречивых и расползающихся тварей должно не только быть устойчивым, но ещё и выполнять дополнительные бонусы и быть удобным для пользователя.

Ой как не зря была создана уже упоминавшаяся тут тема

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

[brigval 722]

Странник

Знаете в чём реальная сложность автоматического создания спецификации в электронном виде?

Реальная сложность в том, что разработчики ориентируются только на тексты стандартов, а не на практику их использования. А второе в тысячу раз важнее.

Перечисленные Вами проблемы решены в моей программе Таип (для Инвентора).

Максимально по ЕСКД. Хотя над программой еще можно и нужно работать.

Конструктор-специалист должен выдать на гора готовую спецификацию по ЕСКД. Со спецификаций будут работать очень много людей в процессе подготовки производства и последующего изготовления изделия. А понятие ЭСИ на данный момент введено декларативно. Никто не знает, что с ним делать. Его можно только обсуждать на многочисленных форумах. Не более того.

быть удобным для пользователя

Я бы поставил это требование на первое место. Только в этом случае можно ожидать поддержку от конструкторов при тестировании программы-спецификации.

[Странник 6]

Странник

...

Конструктор-специалист должен выдать на гора готовую спецификацию по ЕСКД. Со спецификаций будут работать очень много людей в процессе подготовки производства и последующего изготовления изделия. А понятие ЭСИ на данный момент введено декларативно. Никто не знает, что с ним делать. Его можно только обсуждать на многочисленных форумах. Не более того.

...

Как ЭЦМ является аналогом компоновочной прорисовки изделия (подробнейшей!) + дополнительные бонусы, так и ЭСИ является функциональным аналогом спецификации.

ЭЦМ создаёт как бы основу, а далее осуществляется наращивание функционала.

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

Точно так же как и спецификацию выдают в производство и ЭСИ можно импортировать в технологические и управленческие программы посредством html.

Собственно к этому народ и стремится, по крайней мере кого мне приходилось встречать на дороге проектировщика.

[brigval 722]

Собственно к этому народ и стремится, по крайней мере кого мне приходилось встречать на дороге проектировщика.

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

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

[Странник 6]

...

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

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

...

Вот уж никогда бы не подумал что меня примут за программиста, ибо я и есть конструктор, при чём тот, что создаёт изделие целиком. Ещё таковых именуют проектировщиками.

...

На данный момент ЭСИ - надуманное понятие и для работы конструктора не нужна. И спецификацию не подменяет : )

Мне она нужна и таким же как я, хоть нас осталось и не много под этим небом, ибо по ней можно увидеть всё что нужно, и никакой хитренький отраслевик не спрячется.

Точно так же, как именно мне нужен ЭЦМ, как аналог компоновочной прорисовки и абсолютно с ним ассоциативная спецификация.

[DGroot 8]

Как ЭЦМ является аналогом компоновочной прорисовки изделия (подробнейшей!) + дополнительные бонусы, так и ЭСИ является функциональным аналогом спецификации.

Т.е. ЭЦМ используется для получения чертежа, ЭСИ используется для получения СП (и т.п. документов).

Хотя возможны (и реально существуют) обратные варианты когда из чертежа почучают модель, а по данным СП строят структуру.

Так что же первично курица или яйцо? И каждый отвечает на него используя свой опыт и свое видение ситуации в проектировании КД.

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

[DGroot 8]

Как ЭЦМ является аналогом компоновочной прорисовки изделия (подробнейшей!) + дополнительные бонусы, так и ЭСИ является функциональным аналогом спецификации.

Т.е. ЭЦМ используется для получения чертежа, ЭСИ используется для получения СП (и т.п. документов).

Хотя возможны (и реально существуют) обратные варианты, когда из чертежа получают модель, а по данным СП строят структуру.

Теперь посмотрим с другой точки зрения.

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

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

В нашем производстве создание ЭСИ и СП, как документа в электронном виде, содержащего набор структурированных данных о документах и компонентах изделия, получаемых из единой базы данных, шло с почти 10 летним разрывом. При этом, как ни странно, создание ЭСИ (конец 80х годов) опережало создание СП как электронного документа. И авторы создания того и другого были разные и цели, решаемые им, и были разные.

ЭСИ создавались в технологическом отделе (проект АСУПр), для обеспечения решения задач автоматизации подготовки производства. Результатам этой разработки было исключение Ведомости покупных из состава проектируемых КД. В это время сами СП были еще бумажными, и оператор получал из архива бумажные СП и с помощью рук вводил данные из СП в АСУПр. В результате ядром АСУПр стала база данных всех компонентов (материалов, стандартизованных и прочих покупных, использованных в соответствующих СП), когда-либо использованных в проектировании, а также обозначений и наименований деталей и сборок.

Задание на автоматизацию проектирования СП поступило от конструкторов. После создания соответствующей программы перед автором встал вопрос, откуда брать данные. В результате база данных АСУПр и была использована для проектирования СП. Была создана группа информационной поддержки САПр, которая обеспечивает сопровождение (ввод и редактирование) данных в Единой базе данных АСУПр.

Создание электронных СП позволило автоматизировать процесс создание ЭСИ в рамках АСУПр.

Сегодня, в процессе внедрения PLM Windchill, ЭСИ, по сути, были пересозданы и теперь осуществлен новый алгоритм, который обеспечивает обмен данными между ЭСИ в PLM Windchill и ЭСИ в АСУПр. (Хорошо или плохо это положение вещей – это на совести авторов).

Теперь СП должны создаваться как отчет из ЭСИ PLM Windchill и им остается роль сугубо "бумажного" документа, данные которого будут использоваться в процессе визуальной обработки человеком.

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

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

В добавление к определению данному BRIGVAL

Конструкторский документ - это то что имеет обозначение.

я бы добавил следующее.

Конструкторский документ - это документ:

- который создается конструктором для обеспечения задач производства;

- ссылка на который имеется в графе обозначение соответствующих разделов СП;

- на который конструктор оформляет Извещение на изменение.

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

Так что же первично курица или яйцо? И каждый отвечает на него, используя свой опыт и свое видение ситуации в проектировании КД и ТД.

[Странник 6]

Т.е. ЭЦМ используется для получения чертежа, ЭСИ используется для получения СП (и т.п. документов).

Хотя возможны (и реально существуют) обратные варианты когда из чертежа почучают модель, а по данным СП строят структуру.

....

Так что же первично курица или яйцо? И каждый отвечает на него используя свой опыт и свое видение ситуации в проектировании КД.

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

Весь фокус противоречия между СП и ЭСИ в том, что гении-одиночки уходят в прошлое и на малые предприятия, а изделие по сложности сопоставимое хотя бы с автомобилем ныне немыслимо без коллективной работы, то есть без PLM, либо его упрощенного варианта - PDM. Но ведь автоматизировать то легче и быстрее именно малое предприятие, вот и всё, очень и очень просто.

Я не спец по PDM, но могу предложить рассмотреть вариант начинать вводить PDM с новых проектов, не трогая старые.

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

Это цитата отсюда

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

Между тем понятия PDM (PLM) и ЭСИ связаны нераздельно.

В самом деле проектировщику нужна хорошая база данных по изделию, при чём всеобъемлющая и становым хребтом такой базы может быть только ЭСИ. СП же неизбежно становится отражением ЭСИ на бумагу.

Процесс создания новой техники по определению версионно-итерационен, к тому же с большой долей вносимых человеческими амбициями ошибок. Иначе сказать, неизбежны сбои, отказы, брак и прочие неприятности по факту которых будет "разбор полётов" и чем быстрее и точнее удастся вычислить "откуда ножки растут" - тем лучше.

Отсюда, кстати сказать и быстрорастущие требования к качеству моделировщка, PLM, CAE и так далее, стоит только сделать первый шаг.

[ExtraRight 2]

Весёлость ещё в том, что с понятием PDM (PLM) сейчас нераздельно связывают не одну ЭСИ, а множество связанных: Requirements Structure (это не совсем ЭСИ, но без неё не обходится), Fuctional Structure, Feasibility BOM, As-Planned, CAD или DMU Structure, Engineering BOM, Manufacturing BOM, Plant BOM, As-Maintained. Может ещё чего забыл

[DGroot 8]

Requirements Structure (это не совсем ЭСИ, но без неё не обходится), Fuctional Structure, Feasibility BOM, As-Planned, CAD или DMU Structure, Engineering BOM, Manufacturing BOM, Plant BOM, As-Maintained. Может ещё чего забыл

Вау (извените вырвалось), и что к чему и почему, и кто все это будет создавать???

Тут одно из двух, или жить по принципу "Мы вырубим все оазисы, что они не загораживали от нас пустыню, которую нам еще предстоит засадить деревьями", либо "Лучшее враг хорошего" и не

пыться на бегу менять собственную кожу, при этом попутно ощущущая недостаток энергии для реализации желаемого.

[Странник 6]

Вау (извените вырвалось), и что к чему и почему, и кто все это будет создавать???

Тут одно из двух, или жить по принципу "Мы вырубим все оазисы, что они не загораживали от нас пустыню, которую нам еще предстоит засадить деревьями", либо "Лучшее враг хорошего" и не

пыться на бегу менять собственную кожу, при этом попутно ощущущая недостаток энергии для реализации желаемого.

ИМХО, тем более актуальна вот эта тема

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

А множественность всяких структур действительно напрашивается, или одна огромная, но с удобными фильтрами для спецов каждого из существующих направлений технической деятельности

[ExtraRight 2]

Вау (извените вырвалось), и что к чему и почему, и кто все это будет создавать???

Тут одно из двух, или жить по принципу "Мы вырубим все оазисы, что они не загораживали от нас пустыню, которую нам еще предстоит засадить деревьями", либо "Лучшее враг хорошего" и не

пыться на бегу менять собственную кожу, при этом попутно ощущущая недостаток энергии для реализации желаемого.

Всё перечисленное создаётся как обычная мировая практика для таких изделий как автомобиль или самолёт

[Странник 6]

Всё перечисленное создаётся как обычная мировая практика для таких изделий как автомобиль или самолёт

А скринчик для иллюстрации можно подцепить?

Допустим, на функциональную стуктуру, пожалуйста.

[sceptic 0]

Господа-товарисчи! Не кажется ли вам, что тема вырождается? Было интересно сначала на нее заглядывать, а теперь скучно.

Выскажу напоследок свою точку зрения по обсуждаемым вопросам:

1. Классическая спецификация (в бумажном или электронном виде - неважно) в российских условиях еще долго будет востребована.

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

3. Электронный документ вообще (в смысле PDM и PLM) просто необходимо унифицировать, иначе скоро мы разучимся понимать друг друга и будет что-то типа Вавилонской башни. Кто и как будет этим заниматься - вопрос открытый, у меня пока нет вариантов.

[DGroot 8]

1. Классическая спецификация (в бумажном или электронном виде - неважно) в российских условиях еще долго будет востребована.

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

3. Электронный документ вообще (в смысле PDM и PLM) просто необходимо унифицировать, иначе скоро мы разучимся понимать друг друга и будет что-то типа Вавилонской башни. Кто и как будет этим заниматься - вопрос открытый, у меня пока нет вариантов.

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

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

По п.3 - это новая тема для обсуждения ??? Потытка ответа на него в ГОСТ 2.051-2006.

sceptic, уточните, что Вы имели в виду. Задайте вектор обсуждения.

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

[brigval 722]

AnTe

Кстати, огромная просьба, если у кого-нибудь есть замечания по поводу такого интерфейса, - высказать их, не стесняясь в выражениях :)

Хотелось бы услышать коментарий на мои замечания. О том я написал или не о том?

Приведенная спецификация получается (или будет получаться) из какого-то САПРа или из записей в БД?. Если не сектрет, какая решается задача?