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

[brigval 690]

В таком случае, Вам придется существенно переработать ГОСТовское представление документа спецификации, чтобы эта программа его в дальнейшем понимала. Хотя бы начать с исключения единиц измерения в примечании и принудительное их указание + "Доп зам поз.1 на поз.3" тоже придется писать по-другому. Проще по-моему делать ее в качестве отчета.

Ничего не надо перерабатывать! Записывать надо строго по ЕСКД. Обработать строки, зная правила, не представляет труда.

Проще по-моему делать ее в качестве отчета.

К сожалению, в качестве отчета, спецификацию в общем случе не получить. Спецификация - самостоятельный довольно сложный документ. В нем данные, например, в разделе "Комплекты" появляются ВПЕРВЫЕ. Откуда их можно вставить в отчет, если они нигде до этого не записаны? Извините, pif, это типовая позиция специалиста-программиста, который пока не разобрался что такое спецификация и какую функцию она выполняет при разработке КД, при сдаче в архив, при выдаче КД в производство, при подготовке производства и т.д. и т.п.

Собственно для этого и существуют PLM системы и XTML.

Это ещё зачем?

Должно соответствовать содержание и в соответствующем ЕСКД виде выходить с принтера, а как оно будет на экране монитора смотреться (в рабочем виде) ужели так это принципиально?

P.S. окошко предварительного просмотра и так имеется практически всегда.

1 Для программиста существует еще много чего. Конструктору это ничего не надо знать.

2 Конечно, принципиально! То что конструктор видит ДОКУМЕНТ одинаково на экране и на бумаге, значительно уменшает количество ошибок. Потому что, внутренне конструктору не надо постоянно перестраиваться на другой способ отображнения и адаптироваться к нему. Его мысли заняты другой работой - обдумыванием конструкции (образно говоря), а не разглядыванием разных вариантов отображения документа.

[Странник 6]

...

Спецификация - самостоятельный довольно сложный документ. В нем данные, например, в разделе \\\"Комплекты\\\" появляются ВПЕРВЫЕ. Откуда их можно вставить в отчет, если они нигде до этого не записаны?

...

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

1 Для программиста существует еще много чего. Конструктору это ничего не надо знать.

Допустим, знать НИР у него идёт или ОКР, тем более если серийное производство конструктор таки обязан.

В зависимости от этого ведь изменятся процедуры утверждения КД, внесения изменений, опять же премии будут другие и т.п, это по части PLM.

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

2 Конечно, принципиально! То что конструктор видит ДОКУМЕНТ одинаково на экране и на бумаге, значительно уменшает количество ошибок. Потому что, внутренне конструктору не надо постоянно перестраиваться на другой способ отображнения и адаптироваться к нему. Его мысли заняты другой работой - обдумыванием конструкции (образно говоря), а не разглядыванием разных вариантов отображения документа.

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

Кстати, мороки со спецификацией хватает и при готовом уже сборочном чертеже, в ней много чего надо дописать в примечаниях, типа

Допуск. замен. на поз. 1001.

Примен взамен. поз. 507

Размножать по указанию

[brigval 690]

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

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

Предусмотреть особый тип элемнта ЭСИ, хотя бы ради этого и пришлось таки вручную дополнить полученное с правильного ЭЦМ.

Это уже вариант технической реализации : )

Вручную Вы получите кучу ошибок, при том потоке информации, который уже сейчас проходит через конструкотра и производственника.

[pif 0]

Вручную Вы получите кучу ошибок, при том потоке информации, который уже сейчас проходит через конструкотра и производственника.

То есть Вы хотите сказать, что ошибок будет меньше если вводить ее же в бланке спецификации ЕСКД?

[askn 0]

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

Интерфейс - принадлежность информационной системы, а не документа.

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

[brigval 690]

То есть Вы хотите сказать, что ошибок будет меньше если вводить ее же в бланке спецификации ЕСКД?

Нет, pif, не об этом. Я просто отметил слово "вручную". И больше ничего.

[Странник 6]

...

Вручную Вы получите кучу ошибок, при том потоке информации, который уже сейчас проходит через конструкотра и производственника.

Добавляя к своей ЭСИ ссылку на комплекты, которые не вношу в ЭЦМ?

Ой врядли, к тому же будут же и проверяющие.

[brigval 690]

Интерфейс - принадлежность информационной системы, а не документа.

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

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

[askn 0]

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

Это не более чем ваша трактовка. Древовидная структура является общепринятой. Минимальные интерфейсные требования, кстати, тоже можно стандартизировать.

И заметьте, мы уже переключились с вопроса о документе на вопрос об интерфейсе ИС.

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

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

[brigval 690]

Кстати, мороки со спецификацией хватает и при готовом уже сборочном чертеже, в ней много чего надо дописать в примечаниях, типа

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

Кстати, "Размножать по указанию" должно вставляться автоматом для листов утверждения (ЛУ) при вставлении этих ЛУ в спецификацию программно.

Это не более чем ваша трактовка. Древовидная структура является общепринятой.

И заметьте, мы уже переключились с вопроса о документе на вопрос об интерфейсе ИС.

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

Если древовидная структура общепринята, тогда предложите вариант спецификации в дереве, когда есть производственно-технологичесие варианты по ГОСТ 2.109.

Хотелось бы услышать Ваше решение на основе дерева. В ЕСКД, в стандартном бланке спецификации, эти правила есть и все их понимают одинаково, а у Вас?

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

Поэтому, я думаю, мы не сильно отклонились от темы.

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

Целиком и полностью поддерживаю...

[brigval 690]

Ой врядли, к тому же будут же и проверяющие.

Я был свидетелем факта, когда разработчик в графе "Рараб." основной надписи, молодая девчонка, написала свою фамилию транслитом.

Ни один из проверяющих не увидел этого. В том числе и нормоконтроль. Хотя все ставили свои подписи-даты в основной надписи рядом же.

Это было не в электронном виде, а на бумаге, в теперь уже далеких 80-х.

[Странник 6]

Я был свидетелем факта, когда разработчик в графе "Рараб." основной надписи, молодая девчонка, написала свою фамилию транслитом.

Ни один из проверяющих не увидел этого. В том числе и нормоконтроль. Хотя все ставили свои подписи-даты в основной надписи рядом же.

Это было не в электронном виде, а на бумаге, в теперь уже далеких 80-х.

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

Эту девочку в конце концов таки ведь поставили буквою Zю, или надпись сия и до сих пор жива?

[brigval 690]

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

Эту девочку в конце концов таки ведь поставили буквою Zю, или надпись сия и до сих пор жива?

Да так вспомнилось. Для разрядки написал. Что с чертежом и девочкой не знаю. Там не работаю. Да и давно это было.

[Странник 6]

Да так вспомнилось. Для разрядки написал. Что с чертежом и девочкой не знаю. Там не работаю. Да и давно это было.

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

[brigval 690]

Я спрашивал:

Если древовидная структура общепринята, тогда предложите вариант спецификации в дереве, когда есть производственно-технологичесие варианты по ГОСТ 2.109.

Хотелось бы услышать Ваше решение на основе дерева. В ЕСКД, в стандартном бланке спецификации, эти правила есть и все их понимают одинаково, а у Вас?

askn, вопрос этот риторический и я не жду на него ответа. У меня есть три варианта. Не реализованных. Мне пока хватаит.

Спецификацию можно и нужно показывать в виде дерева. Но только не спецификацию как ДОКУМЕНТ. Согласно определению спецификации, она отображает состав [и структуру] ИЗДЕЛИЯ. А если посмотреть правила ее заполнения, то можно увидеть, что спецификация содержит в себе так же состав и структуру комплекта конструкторских ДОКУМЕНТОВ (КД).

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

В электронный документооборот (PDM) можно включить Документы, то есть, дерево Документов (схему КД). Документы и схема КД и должны быть предметом рассмотрения системы документооборота. А Изделие и все что с ним связано не должно быть предметом ДОКУМЕНТОоборота. В этом случае все становится на свои места. Может быть надо делать, но самостоятельную, и систему ИЗДЕЛИЕоборота. Не знаю пока. Смешивание программистами (да и начинающие конструкторы этим грешат) понятий ДОКУМЕНТА и ИЗДЕЛИЯ при работе со спецификацией, а и в ЕСКД нет четкой границы, порождает много трат сил и времени на мертворожденные идеи. На мой взгляд.

[askn 0]

Я спрашивал:

askn, вопрос этот риторический и я не жду на него ответа. У меня есть три варианта. Не реализованных. Мне пока хватаит.

Спецификацию можно и нужно показывать в виде дерева. Но только не спецификацию как ДОКУМЕНТ. Согласно определению спецификации, она отображает состав [и структуру] ИЗДЕЛИЯ. А если посмотреть правила ее заполнения, то можно увидеть, что спецификация содержит в себе так же состав и структуру комплекта конструкторских ДОКУМЕНТОВ (КД).

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

В электронный документооборот (PDM) можно включить Документы, то есть, дерево Документов (схему КД). Документы и схема КД и должны быть предметом рассмотрения системы документооборота. А Изделие и все что с ним связано не должно быть предметом ДОКУМЕНТОоборота. В этом случае все становится на свои места. Может быть надо делать, но самостоятельную, и систему ИЗДЕЛИЕоборота. Не знаю пока. Смешивание программистами (да и начинающие конструкторы этим грешат) понятий ДОКУМЕНТА и ИЗДЕЛИЯ при работе со спецификацией, а и в ЕСКД нет четкой границы, порождает много трат сил и времени на мертворожденные идеи. На мой взгляд.

Соглашусь с наличием неопределенности. Из той же темы - различие между PDM и PLM.

У меня по этому поводу такие соображения:

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

Эти документы - не обязательно чертежи или спецификации; к примеру, для отечественных электроэлементов это ТУ, для высокоунифицированных комплектующих - вообще стандарты. Более того, физически этого документа может и не быть вообще. Например, в спецификации можно сделать базовую ссылку на спецификацию подсборки, типа АБВГ.123123.001, тогда как в действительности будут только спецификации на исполнения этой подсборки - АБВГ.123123.001-01, АБВГ.123123.001-02 и т. д. То есть, с точки зрения работоспособности конструкции все равно, которое из исполнений будет использовано, т. к. они взаимозаменяемы.

Вот управление этими делами - задача PDM.

А область действия PLM начинается потом - в идентификации конкретного физического состава каждой изготавливаемой единицы изделия (это, собственно, уже и есть ИЗДЕЛИЕ). Причем в зависимости от поставленных целей эта идентификация может детализироваться вплоть до уникальных серийных (заводских) номеров и не только на стадии изготовления, но и далее - при сопровождении (ремонтах и модернизациях) у потребителя. И замечу, что необходимый уровень детализации в PLM - задача экономическая, а не инженерная.

[brigval 690]

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

Для меня в понятии Изделие нет неопределенности. Изделие, это все то, что подлежит изготовлению на производстве. То есть, изделие - это физическая реальность. И больше ничего.

Когда мы ведем речь об изделиях записанных в спецификациях, мы оперируем не изделями и НЕ их основными конструкторские документами. Мы оперируем ОБОЗНАЧЕНИЯМИ изделий. Вот здесь вся собака и зарыта!

Сейчас поясню.

Обозначение в графе "Обозначение" имеет ДВА смысла.

1 - это обозначение документа. Любого. Основного или неосновного.

2 - это ОБОЗНАЧЕНИЕ ИЗДЕЛИЯ, если это обозначение записано в разделах "Комплексы", "Сборочные единицы", "Детали" и "Комплекты". Причем ударение на каждом слове. Это, во-первых, ОБОЗНАЧЕНИЕ, а во-вторых, обозначение ИЗДЕЛИЯ. Это обозначение изделия, а не основного конструкторского документа.

И о чем идет речь (об обозначении документа или обозначении изделия) в каждом конкретном случае можно понять только из контекста разговора!

Например, если я нахожусь в КБ и говорю принесите мне "...обозначение..." такое-то, мне принесут Документ. А если я нахожусь в цехе, где делают изделия и прошу принести "...обозначение..." мне принесут само Изделие.

Очень часто в спецификации обозначение изделия совпадает с обозначением основного документа. Это и вносит путаницу для непосвященных. Действительно, если мы пишем формат, то это формат чего. Конечно документа. А если мы пишем количество? То количество чего? Документов? ведь в строке записан документ?! Нет, мы пишем количество изделий с обозначением в графе "Обозначение"! Запись одна, а под ней понимаются разные вещи. В одних графах под этой записю понимается обозначение Документа, и тут же, в других графах под этой же самой записю понимается обозначение Изделия!

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

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

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

[askn 0]

.. Это и вносит путаницу для непосвященных..

Ну, в общем - да. Но я бы назвал это недостатком ЕСКД - стандартизация как раз и служит для устранения путаницы.

[brigval 690]

Ну, в общем - да. Но я бы назвал это недостатком ЕСКД - стандартизация как раз и служит для устранения путаницы.

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

[DGroot 8]

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

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

Нужно четко понимать назначение каждого из конструкторских документов и тогда все становится на свои места.

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

ЭСИ должна формироваться так, чтобы из нее можно было получить автоматизированным способом в формате отчета : СП, ВС, ВД, ВИ, ДП, ПТ, ЭП, ЗИ и др.

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

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

Кому и где нужны иерархические связи - ответ на этот вопрос и определит назначение ЭСИ.

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

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

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

Для тех кому это может быть интересно - система автоматической технологической подготовки производства на основе PLM Winchill (подрыв под нашу АСУПр).

<noindex>http://www.pts-russia.com/products/tech_wind.htm</noindex>

и генератор спецификаций

<noindex>http://www.pts-russia.com/products/spec_gen.htm</noindex>

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