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

[sergsm 4]

1. Согласен, что "среднее время проектирования ТП" - это субъективный показатель. Собственно, уже Тех.Процесс Тех.Процессу - рознь. Время его проектирования - Рознь в квадрате :)

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

Технолог будет смотреть на карту и формировать ТП в своей САПР - это и будет временем проектирования.

2. Время инсталляции мне не кажется так уж малозначительным, минимальные системные требования, согласен - нужны.

3. Максимально возможное число записей в БД системы.

Мне кажется, что этот показатель определяется СУБД, на основе которой формируется БД. Поэтому этот показатель можно упустить.

А потом - в любой СУБД максимально-возможное число записей - астрономическое! Значение в любой СУБД перекроет все заводы вместе взятые.

4. Объем поставляемой в стандартной комплектации БД - согласен, нужно.

Но заполнять базу на предприятиях всё равно приходится.

[Танкист 0]

Коллеги!

Не переливайте из пустого в порожнее!

Связь №1: соответствие САПР задачам ТЕХНОЛОГОВ

САПР ТП должен быть эффективным, надежным средством труда технолога. Любая из САПР ТП подходит по этому критерию. А теперь смотрим Связь №2: соответствие ТЕХНОЛОГОВ возможностям САПР ТП.

И вот здесь начинается самое интересное. Технологи просто НЕ ЖЕЛАЮТ МЕНЯТЬ СТИЛЬ РАБОТЫ, изучать что-либо. Действует только одно - угроза увольнения (и то в случае, если зарплата сносная).

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

САПР ТП, а там совсем другие критерии - явно не длительность инсталляции, число записей БД и т.п. факторы.

[Юрий Боткин 0]

Здравствуйте уважаемые коллеги. Вы затронули очень важную и нужную проблему – разработать номенклатуру характеристик для сравнительной оценки САПР-ТП.

Присоединяюсь и предлагаю обсудить следующие характеристики:

- Метод проектирования (на базе типовых техпроцессов, синтез техпроцесса из элементарных технологических решений);

- Наличие специального языка технологического проектирования и его возможности;

- Состав решаемых задач с указанием степени автоматизации;

- Степень гибкости системы – возможность изменения номенклатуры решаемых задач, процедур технологического проектирования, введение новых объектов в БЗ без корректировки ПО.

Особо хочу отметить вывод, сделанный leo-kaleta 8.04.07, по поводу функциональных модулей. Предлагаю формулировку «Реализация принципа модульного проектирования»

[Max KZK 2]

Как правило, при внедрении САПР ТП на предприятии должна произойти "революция сверху" - инициатива должна быть за руководством.

Вот это правильно. Если конструкторскую САПР можно внедрить методом уговоров, PDM можно, но очень сложно, то САПР ТП даже и пытаться смысла нет.

А дело в том, что САПР ТП наиболее чувствительна к качеству ввода исходных данных.

[VOleg 228]

Прошло 2 месяца ожидания.

Вопрос: автор купил САПР ТП? И какую.

А если нет, то почему?

[буль-буль 0]

Прошло 2 месяца ожидания.

Вопрос: автор купил САПР ТП? И какую.

А если нет, то почему?

По-моему, автор и не планировал что-то покупать))...Материал наверное собирал в виде соц.опроса для научной работы))) никакой практики, сплошная теория)

А критерий выбора всегда один: лишь бы было лучше, чем до этого))

[Вечный Студент 0]

Интересная и популярная была тема, пока по ней танк не прогрохотал. А потом она и вовсе утонула - буль-буль постарался.

Коллеги!

Не переливайте из пустого в порожнее!

Связь №1: соответствие САПР задачам ТЕХНОЛОГОВ

САПР ТП должен быть эффективным, надежным средством труда технолога.

По-моему это г-н Танкист тычет пальцем в небо. Его требование сродни «Корабль должен плавать, а Самолет должен летать». Такое требование может придумать любой участник проекта Дом 2.

Любая из САПР ТП подходит по этому критерию.

Неужели любая? Неужели и Вертикаль подходит? Где там САПР спрятался?

А теперь смотрим Связь №2: соответствие ТЕХНОЛОГОВ возможностям САПР ТП.

И вот здесь начинается самое интересное. Технологи просто НЕ ЖЕЛАЮТ МЕНЯТЬ СТИЛЬ РАБОТЫ, изучать что-либо. Действует только одно - угроза увольнения (и то в случае, если зарплата сносная).

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

Пустозвонство абсолютно не по теме. Здесь обсуждаются не Какими должны быть технологи, а Какими должны быть САПР ТП.

Вывод - танкист прогрохотал, ни одного требования не предложил, но тему укатал.

[VOleg 228]

Интересная и популярная была тема, пока по ней танк не прогрохотал. А потом она и вовсе утонула - буль-буль постарался

Танки тут ни причем.

Если мне нужна САПР, то она у меня есть и всегда была. Первая САПР в 1983 году состояла из картотеки в моем верхнем ящике, потом Искра-226 с 8 дюймовыми дискетами - все технологи моего бюро имели по нескольку дискет ...... сейчас FoxPro 9...

На ее основе сейчас работает САУ предприятия.

Видимо, просто все получили ответы и остались довольны. Или предприятие закрылось.

[leo-kaleta 0]

Или предприятие закрылось.

Или автор умер. Пожалуйста прочитайте первое сообщение этой темы. Жду от Вас здесь что-нибудь полезного, информативного, а не домыслов о том, да о сём...

[Вечный Студент 0]

Если мне нужна САПР, то она у меня есть и всегда была...

В этой теме обуждается не "у кого какая САПР ТП есть" - для этого есть другая тема на этом форуме. Здесь народ хотел определиться с требованиями к САПР-ТП.

[Вечный Студент 0]

Вот это правильно. Если конструкторскую САПР можно внедрить методом уговоров, PDM можно, но очень сложно, то САПР ТП даже и пытаться смысла нет.

А дело в том, что САПР ТП наиболее чувствительна к качеству ввода исходных данных.

Дорогой комбайнер-теоретик, откуда такие выводы? В жизни мы видим все с точностью до наоборот!

САПР ТП реально существуют уже почти 40 лет. Конструкторские САПР, если не считать системы расчета на прочность, появились чуть более 10 лет назад. А реально, не на бумаге, внедренных PDM - единицы. Так кого надо палкой гонять?

К качеству исходных данных чувствительна любая САПР. Если не чуствительна, то это не САПР. Пока еще ни кому не удалось автоматизировать бардак.

[Юрий Боткин 0]

Дорогой комбайнер-теоретик, откуда такие выводы? В жизни мы видим все с точностью до наоборот!

САПР ТП реально существуют уже почти 40 лет. Конструкторские САПР, если не считать системы расчета на прочность, появились чуть более 10 лет назад. А реально, не на бумаге, внедренных PDM - единицы. Так кого надо палкой гонять?

К качеству исходных данных чувствительна любая САПР. Если не чуствительна, то это не САПР. Пока еще ни кому не удалось автоматизировать бардак.

Поддерживаю мнение Вечного Студента (Не тот ли это Студент, который отметился на форуме pcweek?).

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

[TBC 400]

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

Это наверное в СССР, а в мире:

Айвен Сазерленд (англ. Ivan Sutherland, род. 16 мая 1938) — пионер компьютерной графики, создал первый интерактивный графический пакет «Sketchpad», прообраз будущих САПР. Одновременно впервые применил объектно-ориентированный подход к программированию. Лауреат премии Тьюринга.

[Юрий Боткин 0]

Это наверное в СССР, а в мире:

А в мире (в смысле – на западе) подлинных технологических САПР как не было, так и нет. В этой области они отстали от нас навсегда.

Не знаю, кого Вы цитировали:

Айве Сазерленд (англ. Ivan Sutherland, род. 16 мая 1938) — пионер компьютерной графики, создал первый интерактивный графический пакет «Sketchpad», прообраз будущих САПР. Одновременно впервые применил объектно-ориентированный подход к программированию. Лауреат премии Тьюринга.

Может быть это весьма достойный человек, но я с ним не согласен.

Если бы вместо "прообраз будущих САПР" он сказал "прообраз будущих CAD", то это было бы корректно, но не имело бы отношения к нашей теме.

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

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

Когда я 30 с лишним лет назад внедрял свою первую технологическую САПР, мы и не мечтали о графике. На входе в систему были перфокарты, а на выходе - машинограммы с АЦПУ. Но САПРы уже были! Причем я не был пионером в этом деле. Мой наставник – А.С. Старец внедрил свою систему, когда еще и аббревиатуры САПР не было.

Проектирование вообще - это не обязательно графическое проектирование.

САПР – это не CAD, это более широкое понятие.

С другой стороны не всякий CAD может претендовать на звание САПР.

[leo-kaleta 0]

Что касается требований:

1. Однозначный шрифт - идея "перечёркнутый ноль".

2. Должна быть разница между латиницей и кириллицей. Я, кстати, не возражаю против разного цвета. Можно сам шрифт не трогать.

Ну это по своей сути одно и то же, с той лиш разницей, что 1-й пункт уже реализован в некоторых шрифтах немного по другому (например в Times new roman буква O заметно шире нуля 0). В принципе эту задачу решит вам любой студент, воспользовавшись редактором шрифтов.

О ШРИФТАХ.

Предлагаю вниманию читателей форума свой вариант однозначного шрифта. Латиница отличается от кириллицы дополнительной вертикальной чертой. А цифры что-то не очень получились. В прикреплённом файле содержится программа, позволяющая увидеть шрифт и исправить (если есть желание). Жду конструктивную критику (замечания, предложения). Неплохо услышать мнения об имеющихся шрифтах. Если у кого-то есть свой шрифт, сделанный, например, в FontLab Studio 5.0, то прошу рассказать об идеях на которых он построен. Заранее благодарю за помощь.

SimplEdit.zip

[leo-kaleta 0]

Решил добавить в тему ещё одно требование : "Технологический процесс должен иметь указатель, соответствующий следующим рисункам ->см. файл "Указатель техпроцесса".

Указатель_техпроцесса.zip

[rudoy 0]

Если тема еще не "выдохлась" в связи с кризисом, предлагаю просмотреть по адресу proectt@yandex.ru (пароль- proect) вложенные материалы и высказать о них автору.

[leo-kaleta 0]

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

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

Обращаю внимание читателей на то, что некоторые идеи давно известны и реализованы в других программах. Однако важна КОМПОЗИЦИЯ. В нашем алфавите всего 33 буквы, однако из этих букв можно создать любой текст.

Основной целью создания программы было удобство малоподготовленного пользователя. Для обеспечения этой цели реализовано следующее:

1. При подготовке технической документации используются следующие виды информации - текстовые записи, технические рисунки, таблицы, графики, формулы. При подготовке технологий используются технологические карты, которые включают в себя ГИБКИЕ ТАБЛИЦЫ и ЭСКИЗЫ. В отличие от обычных таблиц ГИБКИЕ ТАБЛИЦЫ имеют не одну, а много шапок, каждая из которых маркируется - буквы "Р", "О", "М" и т.д. Эта чрезвычайно мощная система ввода информации, предусмотренная нашим ГОСТом, позволяет в нужном месте вводить табличную запись нужного формата. Это уникальная возможность позволяет сочетать формообразущие свойства информационного объекта "ТАБЛИЦА" и свойство "многовариантность" информационного объекта "ТЕКСТ". Графическая информация ЭСКИЗОВ умножает мощность документа. Получается, что "технологические карты" включают в себя возможность одновременного ввода "текстовых записей", "таблиц" и "рисунков".

Поэтому первое ТТ - "Технологический редактор должен обеспечивать возможность ввода в технологическую карту на очередную позицию стандартной технологической записи типа "Р", "О", "М" и др. или технологического эскиза".

2. Любой серьёзный технический документ имеет форму, предусмотренную тем или иным ГОСТом. Это связано с острой необходимостью обеспечить защиту жизни и здоровья людей, работающих с техникой и пользующихся продукцией, произведённой на данном оборудовании. Поэтому документ имеет много ОТФОРМАТИРОВАННЫХ листов. С другой стороны, для повышения качества документа остро необходимо, чтобы технолог видел своё "произведение" целым, не раздробленным на листы, с возможностью гибко переставлять части технологии с места на место, удалять и добавлять их. Для реализации этих противоречащих друг требований - "Необходимо обеспечить текущую работу технолога на динамическом рулоне. На этапе окончательного создания технологического проекта рулон надо автоматически дробить на листы, обеспечивая их оформление в соответствии с выбранным набором стандартных технологических записей".

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

[\<C0RB@>/ 0]

Здравствуйте leo-kaleta!

Созданная вами тема очень любопытна с точки зрения моей диссертации.

Расскажу немного о себе. Я магистрант 2 курса Нижегородского ВУЗа. Год назад назрел вопрос о теме моей диссертации и после мучительных раздумий была принята тема "Оценка и сравнение программных средств ТПП ". Хоть я и дилетант и не обладаю богатым производственным опытом, зато обладаю богатым воображением и очень хорошим фундаментальным образованием полученным в этом ВУЗе. Так вот что хочется сказать, за год была проделана тяжеленная работа о которой даже вспоминать не хочется) Результатом работы стало изучение и освоение 11 программных средств (ПС) ТПП. Мною создана методика сравнения данных средств, и составлен их рейтинг, а также выялены напрааления их развития. Но требования которые я предъялял к этим ПС масштабней чем те которые предъяляете вы. Вот эти требования:

1. Уровень специализации - это объем задач решаемые ПС. Можно сазать так чем лучше специалист тем больше количество задач он может решать.

2. Уровень автоматизации принятия решений, а именно сколько задач система может решить сама без участия человека.

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

4. Урофень эффективности интерфейса. Тоже важный фактор т.к. именно от интерфейса зависит скорость освоение ПС, наглядность, понятность и многое дугое.

Часть требований прозвучавшие в этом форуме входят состав моих требований. Думаю что перечень требований будет и должен развиваться.

Желаю дальнейшего развития вашей темы! Удачи вам в ваших начинаниях!

Изменено 12 апреля 2009 пользователем \<C0RB@>/

[leo-kaleta 0]

Здравствуйте leo-kaleta!

Созданная вами тема очень любопытна с точки зрения моей диссертации.

Расскажу немного о себе. Я магистрант 2 курса Нижегородского ВУЗа. Год назад назрел вопрос о теме моей диссертации и после мучительных раздумий была принята тема "Оценка и сравнение программных средств ТПП ". Хоть я и дилетант и не обладаю богатым производственным опытом, зато обладаю богатым воображением и очень хорошим фундаментальным образованием полученным в этом ВУЗе. Так вот что хочется сказать, за год была проделана тяжеленная работа о которой даже вспоминать не хочется) Результатом работы стало изучение и освоение 11 программных средств (ПС) ТПП. Мною создана методика сравнения данных средств, и составлен их рейтинг, а также выялены напрааления их развития. Но требования которые я предъялял к этим ПС масштабней чем те которые предъяляете вы. Вот эти требования:

1. Уровень специализации - это объем задач решаемые ПС. Можно сазать так чем лучше специалист тем больше количество задач он может решать.

2. Уровень автоматизации принятия решений, а именно сколько задач система может решить сама без участия человека.

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

4. Урофень эффективности интерфейса. Тоже важный фактор т.к. именно от интерфейса зависит скорость освоение ПС, наглядность, понятность и многое дугое.

Часть требований прозвучавшие в этом форуме входят состав моих требований. Думаю что перечень требований будет и должен развиваться.

Желаю дальнейшего развития вашей темы! Удачи вам в ваших начинаниях!

Большое Вам спасибо за Вашу работу! Писал в этой теме и продолжаю считать, что трудоёмкость вопроса "весит" не одну диссертацию. На этом материале вполне можно защить даже докторскую. Но ОЧЕНЬ много работы. Хотелось бы после защиты получить ссылки или копию (конечно же не бесплатно). У меня на эту тему опубликовано 4 научных статьи. Постепенно буду выкладывать фрагменты + "новьё", то что приходит в голову.