Технические требования для покупки САПР ТП

[PeterShilnikov 1]

Думаю, что это проще делать без PDM-блокнотика, если файл называть по принципу ОБОЗНАЧЕНИЕ+НАИМЕНОВАНИЕ, как в обычной спецификации.

Нужно учитывать еще то, что помимо обозначения и наименования у изделия есть еще версия, а документ, описывающий изделие, может быть не один, и разные документы могут относиться к разным предметным областям и/или разным этапам ЖЦИ, ну, если проще, то иметь разные уровни проработки.

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

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

[leo-kaleta 0]

Нужно учитывать еще то, что помимо обозначения и наименования у изделия есть еще версия, а документ, описывающий изделие, может быть не один, и разные документы могут относиться к разным предметным областям и/или разным этапам ЖЦИ, ну, если проще, то иметь разные уровни проработки.

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

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

А если обозначение построить так. Например, есть изделие - "Бак накопительный". Обозначим его как "БН-01А.00.000 Бак накопительный". "БН" - первые буквы этого типа изделий. "01" - для эволюционных изменений (можно менять до 99), "А"(можно менять до "Я") - для революционных изменений. Далее "00" - для основных узлов. Подсборки можно обозначать - "00.100"..."00.900", чевёртый уровень дерева обозначений для мелких подсборок. Последняя цифра обозначения - нолик ..."..10",..."...90". На пятом уровне - детали. Последняя цифра не должна быть нулём. Если мы аннулируем (или ограничиваем) деталь или узел - изменённому объекту присваиваем другое обозначение, добавляем через чёрточку "- 01"...и т.д.

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

[PeterShilnikov 1]

А если обозначение построить так. Например, есть изделие - "Бак накопительный". Обозначим его как "БН-01А.00.000 Бак накопительный". "БН" - первые буквы этого типа изделий. "01" - для эволюционных изменений (можно менять до 99), "А"(можно менять до "Я") - для революционных изменений. Далее "00" - для основных узлов. Подсборки можно обозначать - "00.100"..."00.900", чевёртый уровень дерева обозначений для мелких подсборок. Последняя цифра обозначения - нолик ..."..10",..."...90". На пятом уровне - детали. Последняя цифра не должна быть нулём. Если мы аннулируем (или ограничиваем) деталь или узел - изменённому объекту присваиваем другое обозначение, добавляем через чёрточку "- 01"...и т.д.

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

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

[leo-kaleta 0]

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

Знаком с разными системами обозначений, которые применяются на предприятиях. Больше всех нравится вот эта - пятиуровневая. Кстати о замечательных свойствах числа 5 (в плане идеальной организации дела) можно почитать <noindex>здесь</noindex>.

[PeterShilnikov 1]

нравится вот эта - пятиуровневая

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

[leo-kaleta 0]

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

Если не хватает 9-ти цифр на каком-то уровне, можно применить буквы. Например, из английского алфавита. Там 26 букв. Выкинем "O" и "I", потому что похожи на цифры. Остаётся 24 буквы. 24+9=33 символа. 33 в пятой степени это 39 миллионов 135 тысяч 393. Такого количества обозначений вполне хватит, чтобы спроектировать любой авианосец со всеми входящими деталями, узлами, сборочными единицами и прочее, включая палубную авиацию и корабли сопровождения.

[PeterShilnikov 1]

Если не хватает 9-ти цифр на каком-то уровне, можно применить буквы. Например, из английского алфавита. Там 26 букв. Выкинем "O" и "I", потому что похожи на цифры. Остаётся 24 буквы. 24+9=33 символа. 33 в пятой степени это 39 миллионов 135 тысяч 393. Такого количества обозначений вполне хватит, чтобы спроектировать любой авианосец со всеми входящими деталями, узлами, сборочными единицами и прочее, включая палубную авиацию и корабли сопровождения.

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

[leo-kaleta 0]

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

Достаточно долго выпускал документацию с длинными обозначениями. А потом столкнулся с пятиуровневой системой. Всё познаётся в сравнении. Длинные обозначения очень неудобны для всех. В производстве обозначение применяется много раз и когда его длина неоптимальна, то всем плохо. Лишние символы, лишнее время, лишние затраты на писанину, печатание и говорильню. Если Ваше изделие - не авианосец, то вполне можно обойтись без латинских символов в пятиуровневой системе. Изделие можно разбить на 99 основных узлов. Основные узлы могут включать до 900 деталей. Крупные подсборки могут включать до 90 деталей. Мелкие подсборки до 9 деталей. Это много. Не будем забывать о том, что <noindex>народная мудрость</noindex> говорит нам - "число семь - это синоним слова "много". Символов в обозначении не должно быть много. Число уровней дерева обозначений должно быть меньше 7. Оптимально - 5.

Насчёт разделителей. В обозначении БН-01А.00.000 точка чисто условно отделяет основные узлы от остального дерева. Разделителей нет, они просто подразумеваются.

[leo-kaleta 0]

Для модуля технологического автоконтроля чертежей.

Количество отверстий.

Комментарий: В чертежах часто встречаются надписи в размерах: "3 отв.", "4 паза" и т.д. Это число не всегда бывает правильным.

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

[leo-kaleta 0]

Группа технологов.

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

[Елена 116]

По посту 210 - это задачи WorkFlow, раньше у нас называлось -контроль исполнительской дисциплины (АСКИД - автоматизированная система контроля исполнительской дисциплины). Подобные функции у Project (управление проектом).

[leo-kaleta 0]

По посту 210 - это задачи WorkFlow, раньше у нас называлось -контроль исполнительской дисциплины (АСКИД - автоматизированная система контроля исполнительской дисциплины). Подобные функции у Project (управление проектом).

В связи с тем, что я не знаю, что такое WorkFlow и т.д... совершенно ничего не понял. Пожалуйста, проведите краткий ликбез. Заранее благодарен за расшифровку этих терминов и краткое описание этого ПО.

[Елена 116]

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

Хотя, конечно можно в задании указать перечень оборудования. Оборудование, геометрия и ТТ - предполагают технологию.

[leo-kaleta 0]

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

Хотя, конечно можно в задании указать перечень оборудования. Оборудование, геометрия и ТТ - предполагают технологию.

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

[Елена 116]

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

[VOleg 228]

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

Это в Инвенторе вместо "Т.конр." стоит "технолог", что не верно, т.к. технологический контроль может провести и инженер по подготовке производства при наличии Отдела по подготовке производства. А вот "сметчика" ни на одном предприятии, где я работал, нет... извините...

[leo-kaleta 0]

Это в Инвенторе вместо "Т.конр." стоит "технолог", что не верно, т.к. технологический контроль может провести и инженер по подготовке производства при наличии Отдела по подготовке производства. А вот "сметчика" ни на одном предприятии, где я работал, нет... извините...

А для ДЕЛА (для проекта) что лучше - когда его СОЗДАЮТ (по-английски "create", наш термин - "креатор") одновременно три специалиста - конструктор, технолог, экономист ИЛИ назначается один ответственный разработчик, а его проверяет большой коллектив контролёров, каждый из которых несёт 1...5% ответственности за проект? И насчёт сметчика. Как быть с пословицей: "Деньги счёт любят?"

[VOleg 228]

А для ДЕЛА (для проекта) что лучше - когда его СОЗДАЮТ (по-английски "create", наш термин - "креатор") одновременно три специалиста - конструктор, технолог, экономист ИЛИ назначается один ответственный разработчик, а его проверяет большой коллектив контролёров, каждый из которых несёт 1...5% ответственности за проект? И насчёт сметчика. Как быть с пословицей: "Деньги счёт любят?"

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

[leo-kaleta 0]

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

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

[VOleg 228]

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

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