Системы автоматизированного проектирования технологических процессов. Программное обеспечение САПР ТП. (Лекция 3)

1.

Курс лекций к дисциплине
Системы автоматизированного
проектирования
технологических процессов
(САПР ТП)
Лектор, преподаватель:
к.т.н., доцент
Уразбахтина Анжелика Юрьевна
1

2.

Программное обеспечение САПР ТП
Программное обеспечение (ПО) САПР –
совокупность машинных программ и
сопутствующих им эксплуатационных
документов, необходимых для выполнения
автоматизированного проектирования.
Принято разделять ПО на системные среды, и
на общесистемное и прикладное ПО САПР
ТП.
2

3.

В состав системной среды входят: система управления
проектными данными (типа СУБД или PDM);
инструментальные средства разработки и сопровождения
программ; интеллектуальные средства поддержки принятия
проектных и управленческих решений (системы
искусственного интеллекта, экспертные системы).
К общесистемному ПО относят операционные системы (ОС)
используемых ПК и телекоммуникационных вычислительных
сетей. Операционная система – это комплекс программ,
который загружается при включении компьютера. Она
производит диалог с пользователем, осуществляет управление
компьютером, его ресурсами (оперативной памятью, местом на
дисках и т.д.), запускает прикладные программы на
выполнение и т.д.
Прикладное ПО представлено программно-методическими
комплексами и пакетами программ для выполнения проектных
и бизнес процедур.
3

4.

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

5.

Основным недостатком каскадного подхода является
существенное запаздывание с получением результатов.
Согласование результатов с пользователями производится
только в точках, планируемых после завершения каждого
этапа работ, требования к АС «заморожены» в виде
технического задания на все время ее создания. Таким
образом, пользователи могут внести свои замечания
только после того, как работа над системой будет
полностью завершена. В случае неточного изложения
требований или их изменения в течение длительного
периода создания ПО, пользователи получают систему, не
удовлетворяющую их потребностям. Модели (как
функциональные, так и информационные)
автоматизируемого объекта могут устареть одновременно
с их утверждением.
5

6.

Для преодоления перечисленных проблем была предложена
спиральная модель ЖЦ, делающая упор на начальные
этапы ЖЦ: анализ и проектирование. На этих этапах
реализуемость технических решений проверяется путем
создания прототипов. Каждый виток спирали
соответствует созданию фрагмента или версии ПО, на нем
уточняются цели и характеристики проекта, определяется
его качество и планируются работы следующего витка
спирали. Таким образом, углубляются и последовательно
конкретизируются детали проекта, и в результате
выбирается обоснованный вариант, который доводится до
реализации.
Основная проблема спирального цикла определение
момента перехода на следующий этап. Для ее решения
необходимо ввести временные ограничения на каждый из
этапов жизненного цикла.
6

7.

7

8.

В настоящее время, жизненный цикл каждой версии прикладного ПО
включает в себя семь этапов.
• 1. Постановка задачи. Для создания конкурентоспособных продуктов, в
ходе выполнения этого этапа должны быть получены четкие ответы на
следующие вопросы: Что должна делать программа? В чем состоят
реальные проблемы, разрешению которых она должна способствовать?
Что представляют собой входные данные? Какими должны быть
выходные данные? Какими ресурсами располагает проектировщик?
После согласования постановки задачи между исполнителем и заказчиком,
составляется техническое задание (ТЗ). Оформление ТЗ является
необходимым документом в работе по созданию ПО САПР ТП. Ошибки,
допущенные на этом этапе, даже при условии безупречного выполнения
последующих этапов могут привести к тому, что разработанный
программный продукт не будет соответствовать требованиям практики и
сферы его применения.
• 2. Анализ требований. На данном этапе в соответствии с ТЗ выбираются
математические абстракции, строится ММ и определяется метод
решения задачи, позволяющий перейти от исходных данных к
результатам.
8

9.

• 3. Определение спецификаций. Этот этап можно рассматривать как
формулировку выводов, следующих из предыдущего этапа. Требования к
программе должны быть представлены в виде ряда спецификаций, явно
определяющих рабочие характеристики будущей программы. В число
таких характеристик входят перечень параметров.
• 4. Проектирование. На этом этапе создается структура программы в
соответствии с МО и спецификациями; определяются общие принципы
управления и взаимодействия между различными компонентами
программы. Принято различать логическое и физическое проектирование.
Логическое проектирование, в отличие от физического, не учитывает
особенностей среды, в которой будет выполняться программа
(технические и программные средства компьютера). Логическое
проектирование предполагает детальную проработку последовательности
действий будущей программы, здесь может быть два варианта: либо ПО
создается в виде отдельной программы, либо разрабатывается комплекс
подпрограмм.
• 5. Кодирование. Заключается в переводе на язык программирования
конструкций МО, записанных на языке проектирования, и перенос текстов
программ на электронные носители. Язык программирования может быть
определен в ТЗ, а может выбираться исходя из особенностей конкретной9
разработки.

10.

При кодировании не следует забывать о правилах «хорошего
программирования»: минимум вложенных циклов; использовать
целочисленные данные там, где это можно, потому что действия с
целочисленными данными производятся быстрее, чем с вещественными;
строить логические выражения так, что вычисления прекращаются, если
результат становится очевидным, или располагать выражения по
уменьшению вероятности возникновения логического результата;
сопровождать текст ПО комментариями, но не вводить комментарии внутрь
циклов; разбивать сложные программы на отдельные модули; использовать
уже готовые алгоритмы.
• 6. Тестирование. На этом этапе производится проверка ПО. Известно три
критерия проверки программы на: правильность; эффективность
реализации; вычислительную сложность.
Проверка правильности (адекватности постановке задачи) подтверждает, что
программа делает в точности то, для чего она была предназначена. Как
правило, проверка правильности заключается в разработке и проведении
набора тестов. Кроме того, для определения правильности программы
иногда можно сверить получаемые решения с уже известным решением,
определив относительную погрешность расчета.
10

11.

Проверка сложности, как правило, заключается в
экспериментальном сравнении двух или более программ,
решающих одну и ту же задачу.
Целью сравнения программ по эффективности является отыскание
способа, как заставить правильную программу работать быстрее
или расходовать меньше памяти.
• 7. Сопровождение. Это этап эксплуатации программы. Каким бы
ни было изощренным тестирование программы, к сожалению, в
больших программных комплексах чрезвычайно тяжело
устранить абсолютно все ошибки. Устранение обнаруженных при
эксплуатации ошибок, неудачных проектных решений, «узких
мест» – достигается именно на этом этапе.
Помимо этого, сопровождение может включать в себя организацию
мероприятий по проведению консультаций, обучению
пользователей САПР, снабжение информацией о новых версиях
ПО.
11

12.

Реализация подсистем должна выполняться отдельными
группами специалистов (3-7 человек). Технология
проектирования ПО САПР должна быть поддержана
комплексом согласованных CASE-средств, обеспечивающих
автоматизацию процессов на всех стадиях ЖЦ.
Интегрированная САПР ТП может основываться на программном
комплексе, базирующихся на каком-то основном ПО например,
AutoCAD или Компас. Разработчики такого ПО предлагают
набор программ, которые либо работают в рамках единой
программной среды, либо имеют хорошо отлаженное
взаимодействие между собой. Предприятие разрабатывает
свои собственные приложения, что требует интеграции со
всем комплексом АС предприятия, для этого разработчики ПО
САПР ТП используют специальные механизмы доступа к
внутренним функциям базового ПО.
12

13.

Можно выделить комплекс типовых, относительно самостоятельных
задач, требующих решения основе интеграции:
• Расчёты на прочность. Выполняются либо в специализированных
пакетах, либо в расчётных пакетах общего назначения. Некоторые
пакеты встраиваются в базовую графическую систему либо возможен
обмен 3D моделями через различные форматы обмена данными.
• Обработка спецификаций. Для этих целей могут применяться
специализированные пакеты или электронные таблицы.
Спецификации должны быть представлены в нейтральном формате
в виде форматированного текста, который может обрабатываться
практически любой системой.
• Выпуск чертежей. Обеспечивается базовой графической системой.
• Визуализация. Результаты визуализации используются для подготовки
рекламных материалов, презентаций и других материалов для работы
с клиентами, включая анимационные и панорамные.
13

14.

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

15.

Информационное обеспечение
это информация необходимая для выполнения процесса проектирования, представленная в удобной
для обработки на ПК форме. Создание информационного обеспечения требует разработки баз
данных (БД) и баз знаний (БЗ) .
БД – структурированная совокупность взаимосвязанных данных, используемых более чем одним
пользователем или программным модулем. База данных – совокупность структурированных
данных, используемых многими прикладными программами и хранящихся с минимальной
избыточностью.
По типу принятой модели данных различают БД реляционные, сетевые, иерархические. Реляционные
БД – совокупность таблиц, связываемых отношениями. Сетевая БД имеет структуру данных в
виде графа, вершины которого соответствуют записям, а ребра – связям между записями.
Иерархическая структура БД представляется в виде дерева отношений «предок-потомок». Примером
иерархической модели может служить база данных составных частей:
• найти конкретный компоновочный узел;
• перейти «вниз» к составляющим узел деталям;
• перейти «вверх» к сборке.
Таким образом, для чтения данных из иерархической БД требуется перемещение по записям, за один
раз переходя на одну запись вверх, вниз или в сторону. Достоинства таких БД: простота модели
для понимания, использование отношений «предок-потомок», быстродействие.
Сетевые БД – улучшенная иерархическая модель, когда одна запись может участвовать в нескольких
отношениях «предок-потомок». Достоинства: гибкость, стандартизация, быстродействие.
15

16.

Удобное средство для работы с электронными таблицами (реляционными БД) – Microsoft
Excel, его часто используют в базовом ПО САПР.
Различают БД универсальные (проектно-независимые) и специализированные (проектнозависимые).
• Минимальный состав БД для САПР ТП (проектно-зависимая информация):
• конструкторские материалы;
• паспортные данные станков и др. оборудовании;
• типовые ТП (ТО, переходы);
• нормативы времени;
• инструменты (режущий, мерительный, вспомогательный);
• сборочные единицы (комплектующие детали, узлы);
• технологическая оснастка;
• ГОСТы, нормали;
• режимы резания.
Данными в процессе проектирования и работы САПР необходимо управлять:
осуществлять поиск, группировать данные, корректировать и пр. Система управления
базой данных (СУБД) – программный комплекс, обеспечивающий создание структуры,
ввод, модификацию, удаление и поиск данных.
Иногда используется понятие банка данных (БнД), под которым понимается совокупность
БД и СУБД.
Самой распространенной в настоящее время является СУБД Microsoft Access пакета 16

17.

При создании любой БД разрабатывается модель данных. При этом интересующая пользователей БД
информация существует в двух представлениях:
• Логическое представление данных.
• Физическое представление данных на носителе информации.
• Логическое представление отражает структуру данных. Модель не содержит конкретных
значений. Она только описывает их структуру. В дальнейшем структура остается неизменной, а
данные могут меняться при вводе и редактировании информации в БД.
Для определения модели используются следующие понятия:
• объект;
• атрибут;
• экземпляр;
• ключ.
Объект представляет собой то, о чем накапливается информация в БД, например «сверло», «зенкер»,
«резец» и т.д.
Атрибуты – это интересующие пользователя характеристики объекта. Например, для объекта «сверло»
- это «обозначение», «диаметр», «длина общая» и т.д.
Экземпляр объекта – совокупность значений атрибутов, описывающих конкретную его реализацию. В
нашем случае это строка таблицы.
Ключ – это атрибут, значение которого однозначно определяет экземпляр. Так в БД по сверлам ключом
может служить атрибут «обозначение», т.к. значение этого атрибута не дублируется ни в одной
строке (экземпляре).
Другие атрибуты не могут быть ключом, потому что могут принимать одинаковые значения для
разных экземпляров. Например, вполне возможны два сверла с одинаковой длиной, хотя и разного
исполнения.
17

18.

К средствам организации данных в информационном обеспечении
относятся:
• система классификации и кодирования информации;
• система ведения информационных массивов (входные формы и
таблицы, оперативные документы на изменение информации;
• методические инструментальные материалы для «системного
персонала» (службы администрации).
Системы классификации обычно создаются на базе известных
классификаторов:
• «Общесоюзного классификатора промышленной и
сельскохозяйственной продукции (ОКП)»;
• «Технологического классификатора деталей машиностроения и
приборостроения».
В качестве кода для группы оборудования могут быть использованы
кодовые обозначения по классификатору ЕСКД.
При кодировании наименования содержания ТП обработки
целесообразно использовать ГОСТ 3.1702-79 и ТП сборки - ГОСТ
18
3.1703-79

19.

19

20.

20

21.

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

22.

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