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

[askn 0]

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

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

ИС развиваются по другому пути: по окончании работы для соответствующего объекта уполномоченный пользователь (имеющий соответствующие права доступа) ставит статус "Утвержден".

Этого вполне достаточно.

[suslad 1]

ИС развиваются по другому пути: по окончании работы для соответствующего объекта уполномоченный пользователь (имеющий соответствующие права доступа) ставит статус "Утвержден".

Этого вполне достаточно.

Этого вполне достаточно только в том случае если "уполномоченный пользователь" это владелец и компания не больше дцати человек.

[brigval 722]

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

Вопросов много, а времени не особенно много. Постараюсь пояснить, что я понимаю под кэшированием.

В каждй конкретный момент работа по созданию/обновлению сп конструкторами идет не со всеми сп одновременно, а в общем-то с довольно небольшой частью сп. При первом запуске программа прочитывает все сп и записывет информацию из сп в БД. На это может уйти и много времени. Одновременно программа записывает атрибуты файлов с сп в БД же. Это размер файла, даты создания и последнего обновления, можно контрольную сумму (сейчас не принципиально).

При повторном считывании программа сначала проверяет изменились ли атрибуты файла. Если изменились записывает в БД заново, если нет, берет записи из БД. Скорость обработки информации и предоставления ее пользователю возрастает очень сильно при этом. В принципе, я думаю, можно сделать процесс, который будет выполнять эту работу в фоновом режиме. Тогда получение информации из сп об изделии для пользователя будет вообще мгновенным.

Техничекая реализация здесь не принципиальна. Я поясняю только идею.

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

[Странник 6]

....

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

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

Если использовать указанное здесь

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

то с готовой ЭСИ спецификация строится вообще автоматически.

[brigval 722]

с готовой ЭСИ спецификация строится вообще автоматически.

Осталось вручную набить ЭСИ и получить автоматически с нее спецификацию (Шутка)

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

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

Это не его специальность. Он свое дело сделал: спроектировал изделие и выдал на гора документы.

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

Понятие ЭСИ с моей точки зрения не выдерживает никакой критики. Если это документ, то не ясно куда он входит и как хранится и как подписывается. В отличие от спецификаций, с которыми ВСЕ ясно и понятно. По крайней мере, конструкторам со стажем.

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

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

[Странник 6]

....

Понятие ЭСИ с моей точки зрения не выдерживает никакой критики. Если это документ, то не ясно куда он входит и как хранится и как подписывается. В отличие от спецификаций, с которыми ВСЕ ясно и понятно. По крайней мере, конструкторам со стажем.

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

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

Как раз конструктор со стажем (лет 15 надеюсь таковым ужо считается? ) ЭСИ и построит и ВСЁ по ней поймёт.

Нету пока стандартов на ЭСИ?

Это дело поправимое, были бы только здравый смысл и желание у стандартотворцев.

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

[suslad 1]

Нету пока стандартов на ЭСИ?

Как же нету?

Изменение №8 к ГОСТ 2.102-68 уже включает понятие ЭСИ, а в приложении Б (которого раньше не было) приведен пример ЭСИ -- "ПРИМЕР ПОСТРОЕНИЯ ПОЛНОГО КОМПЛЕКТА ЭЛЕКТРОННЫХ КОНСТРУКТОРСКИХ ДОКУМЕНТОВ НА ОСНОВЕ ЭЛЕКТРОННОЙ СТРУКТУРЫ ИЗДЕЛИЯ (КОМПЛЕКСА)". Если внимательно рассмотреть этот пример -- то это не что иное как древовидное отображение ЭСИ применяемое в большинстве PLM-систем (во всяком случае Windchill именно так и отображает ЭСИ).

И еще добавлю -- чтобы не было споров что первично -- спецификация или ЭСИ.

Выдержка из ГОСТ 2.102-68. Изменение №8.

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

PS Эти изменения внесены еще 2006-м году. В этих изменениях четко прописано и как идентифицировать ДЭ (электронные документы).

[askn 0]

Как же нету?

Изменение №8 к ГОСТ 2.102-68 уже включает понятие ЭСИ, а в приложении Б (которого раньше не было) приведен пример ЭСИ -- "ПРИМЕР ПОСТРОЕНИЯ ПОЛНОГО КОМПЛЕКТА ЭЛЕКТРОННЫХ КОНСТРУКТОРСКИХ ДОКУМЕНТОВ НА ОСНОВЕ ЭЛЕКТРОННОЙ СТРУКТУРЫ ИЗДЕЛИЯ (КОМПЛЕКСА)". Если внимательно рассмотреть этот пример -- то это не что иное как древовидное отображение ЭСИ применяемое в большинстве PLM-систем (во всяком случае Windchill именно так и отображает ЭСИ).

И еще добавлю -- чтобы не было споров что первично -- спецификация или ЭСИ.

Выдержка из ГОСТ 2.102-68. Изменение №8.

PS Эти изменения внесены еще 2006-м году. В этих изменениях четко прописано и как идентифицировать ДЭ (электронные документы).

Вынужден констатировать, что большинство участников форума упорно продолжают смешивать понятия ЭСИ и ОБДИ (информационная система предприятия).

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

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

Стандартизированный ЕСКД электронный документ должен отвечать ряду требований, к которым относятся:

1) файловый формат;

2) строго определенный набор реквизитов, в частности - ЭЦП;

3) содержательная часть, соответствующая виду документа.

Поэтому "скрин с экрана" не может служить примером ЭСИ, в лучшем случае - некоторое внешнее отображение ее содержательной части. Внешнее отображение ОБДИ очень похоже (можно даже сказать - одно и то же). Но это не значит, что одно и то же - ЭСИ и ОБДИ.

Аргументы:

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

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

3) задачи обмена информацией между пользователями одной информационной системы и обмена информацией между разными информационными системами - это РАЗНЫЕ задачи. Назначение ЭСИ - в решении второй задачи, а не первой.

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

[brigval 722]

Когда программисты поймут, что конструкторская спецификация это никакой НЕ отчет, а САМОСТОЯТЕЛЬНЫЙ и довольно сложный конструкторский документ, они станут на голову выше в понимании предметной области, для которой хотят внедрить автоматизацию. И у них все начнет получаться.

[pif 0]

Не могли бы Вы привести аналог документа спецификации в западной системе подготовки КД?

[suslad 1]

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

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

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

Когда программисты поймут, что конструкторская спецификация это никакой НЕ отчет, а САМОСТОЯТЕЛЬНЫЙ и довольно сложный конструкторский документ, они станут на голову выше в понимании предметной области, для которой хотят внедрить автоматизацию. И у них все начнет получаться.

Вы же ратовали за ЕСКД и ГОСТы. Так в чем проблема? Я же привел выдержку из ГОСТа на счет ЭСИ. Причем здесь программисты?

Не могли бы Вы привести аналог документа спецификации в западной системе подготовки КД?

BOM -- Bill Of Material

[pif 0]

BOM -- Bill Of Material

А электронная структура изделия у них есть? Как документ?

[Странник 6]

Когда программисты поймут, что конструкторская спецификация это никакой НЕ отчет, а САМОСТОЯТЕЛЬНЫЙ и довольно сложный конструкторский документ, они станут на голову выше в понимании предметной области, для которой хотят внедрить автоматизацию. И у них все начнет получаться.

Только тогда, когда начнут слушать и делать то, что надо конструкторам.

А по сути ЭСИ выполняет теж самые функции что и спецификация + удобный поиск.

Кстати, вот обещаные скрины.

[askn 0]

Когда программисты поймут, что конструкторская спецификация это никакой НЕ отчет, а САМОСТОЯТЕЛЬНЫЙ и довольно сложный конструкторский документ, они станут на голову выше в понимании предметной области, для которой хотят внедрить автоматизацию. И у них все начнет получаться.

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

В соответствии с ЕСКД и то, и другое - самостоятельные конструкторские документы, просто взаимозаменяемые.

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

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

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

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

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

[pif 0]

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

Скорее в обмене файлами, в которых представлен состав изделия. По сути дали добро делать BOMы на уровне стандарта и не заморачиваться с табличным их оформлением.

[askn 0]

..ОБДИ это помойка в которой помимо всех ЭСИ, разработанных на предприятии, храниться еще куча всякого хлама.

Это говорит исключительно об организации работ в тех ИС, с которыми вы встречались.

Для того, чтобы это исправилось, нужно:

1) желание (прежде всего - руководства);

2) инженерный подход к созданию и документирование организации работ в ИС (СТП).

Остальное приложится.

Я уже писал в одном из прошлых постов, что действительно ИС в России по большому счету развиты слабо. Но тенденции и темпы обнадеживают.

BOM -- Bill Of Material

В нем нет раздела "Документация", так что на аналог спецификации он не тянет.

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

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

[brigval 722]

Касательно спецификации - толком ЕСКД определяет исключительно бумажную ее форму.

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

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

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

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

[pif 0]

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

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

[Странник 6]

....

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

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

...

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

....

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

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

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

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

[askn 0]

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

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

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

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

Я нигде не говорил, что спецификации заполняют "в бумаге". Я говорил, что по ЕСКД документом она становится, когда выведена в бумажной форме и снабжена всеми ревизитами (проведена по всем службам).

Касательно электронного вида - вопрос скользкий, так как ни в одном стандарте ЕСКД не определен файловый формат текстовых документов. Зато в одном ГОСТе (не помню номера) о документах на магнитных (их еще кто-то использует?) носителях данных указано требование об использовании символьной кодовой таблицы КОИ7.

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

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