------шпоры_ПССАПР. Понятие проектирования Техническая система
 Скачать 203.32 Kb.
|
|
Action Macros Action Macros впервые появились в AutoCAD 2009. Пользователь выполняет последовательность команд, которая записывается с помощью инструмента Action Recorder. Записанный макрос можно отредактировать и сохранить, а впоследствии перенести на панель инструментов, либо запускать из специального меню. Menu Macros Пользователь имеет возможность создавать собственные кнопки, с помощью которых можно вызывать заранее записанные по определённым правилам серии команд (макросы). В состав макросов можно включать выражения, написанные на языках DIESEL и AutoLISP. DIESEL DIESEL (Direct Interprietively Evaluated String Expression Language) — язык оперирования строками с небольшим количеством функций (всего 28 функций). Он позволяет формировать строки, которые должны иметь переменный текст, зависящий от каких-либо условий. Результат выводится в виде строки, которая интерпретируется системой AutoCAD как команда. Visual LISP Visual LISP — среда разработки приложений на языке AutoLISP. Иногда под названием Visual LISP подразумевают язык AutoLISP дополненный расширениями ActiveX. Среда разработки содержит язык AutoLISP и язык DCL, а также позволяет создавать приложения, состоящие из нескольких программ. Несмотря на название, Visual LISP не является средой визуального программирования. AutoLISP AutoLISP — диалект языка Лисп, обеспечивающий широкие возможности для автоматизации работы в AutoCAD. AutoLISP — самый старый из внутренних языков программирования AutoCAD,. В AutoLISP реализовано тесное взаимодействие с командной строкой, что способствовало его популяризации среди инженеров, работающих с AutoCAD. Архитектура и характеристики современных САПР: Autodesk Inventor Autodesk Inventor — 3D САПР для создания и изучения поведения цифровых прототипов изделий и деталей компании Autodesk. Используется в основном в машиностроении. В комплект входит несколько продуктов: Autodesk Inventor Suite, Autodesk Inventor Routed Systems Suite (проектирование кабельных и трубопроводных систем, в том числе для разводки сложных участков трубопроводов, электрических кабелей и проводов), Autodesk Inventor Simulation Suite (средства моделирования движения и анализа нагрузок, которые упрощают изучение поведения изделия в реальных условиях ещё на стадии проектирования). SolidWorks - система автоматизированного проектирования, инженерного анализа и подготовки производства изделий любой сложности и назначения. SolidWorks является ядром интегрированного комплекса автоматизации предприятия, с помощью которого осуществляется поддержка жизненного цикла изделия в соответствии с концепцией CALS-технологий, включая двунаправленный обмен данными с другими Windows-приложениями и создание интерактивной документации. В зависимости от класса решаемых задач заказчикам предлагается три базовых конфигурации системы: SolidWorks, SolidWorks Professional и SolidWorks Premium. Архитектура и характеристики современных САПР: ANSYS ANSYS — универсальная программная система конечно-элементного (МКЭ) анализа, существующая и развивающаяся на протяжении последних 30 лет, является довольно популярной у специалистов в области компьютерного инжиниринга (CAE, Computer-Aided Engineering) и КЭ решения линейных и нелинейных, стационарных и нестационарных пространственных задач механики деформируемого твёрдого тела и механики конструкций (включая нестационарные геометрически и физически нелинейные задачи контактного взаимодействия элементов конструкций), задач механики жидкости и газа, теплопередачи и теплообмена, электродинамики, акустики, а также механики связанных полей. Моделирование и анализ в некоторых областях промышленности позволяет избежать дорогостоящих и длительных циклов разработки типа «проектирование — изготовление — испытания». Система работает на основе геометрического ядра Parasolid. Способы интеграции приложений Универсального способа интеграции приложений не существует. Передача файла. Взаимодействие между приложениями осуществляется с помощью файлов, в которые помещаются общие данные. Общая база данных. Взаимодействие между приложениями осуществляется с помощью базы данных, в которой сохраняется общая информация. Удаленный вызов процедуры. Взаимодействие между приложениями осуществляется с помощью удаленного вызова процедур, использующихся для выполнения действий или обмена данными. Обмен сообщениями. Взаимодействие между приложениями осуществляется с помощью системы обмена сообщениями, которые используются для обмена данными и выполнения действий. Существует способ, оптимальный в рамках конкретного интеграционного сценария. Каждый стиль интеграции имеет свои преимущества и недостатки. Интеграционное решение может основываться на использовании нескольких различных стилей. Способы интеграции приложений: передача файла, общая база данных Файлы— это универсальный механизм хранения данных, встроенный в любую операционную систему и поддерживающийся любым языком программирования. Таким образом, один из самых простых способов интеграции приложений может быть основан на использовании файлов. Одним из наиболее важных решений является выбор общего формата файлов. До недавнего времени наиболее распространенным стандартным форматом файлов считался простой текстовый файл. Современные интеграционные решения основываются на использовании формата XML. Приложение, которому требуется передать данные другому приложению, сохраняет их в файле. Ответственность за преобразование форматов файлов ложится на плечи разработчиков интеграционного решения. Частота создания файлов зависит от характера бизнес-логики компании. Наиболее существенное преимущество файлов заключается в том, что разработчики интеграционного решения не нуждаются в дополнительных сведениях о внутренней реализации интегрируемых приложений. Основная задача интеграторов заключается в преобразовании форматов файлов (если это необходимо). Более частый обмен данными согласованного формата обеспечивает общая база данных. Общая база данных обеспечивает согласованность хранящейся в ней информации. Все попытки изменения одного и того же фрагмента данных из нескольких различных источников будут пресекаться администратором транзакций базы данных. Наличие общей базы данных устраняет проблему семантического диссонанса. Все вопросы, связанные с интерпретацией данных, могут быть сняты на этапах проектирования и реализации интеграционного решения. Одной из наибольших трудностей, присущих рассматриваемому стилю интеграции, является разработка схемы общей базы данных. Создание унифицированной схемы данных, удовлетворяющей требованиям нескольких различных приложений, связано со сложностями как технического, так и политического характера. Если применение унифицированной схемы данных приведет к снижению производительности критически важного приложения, руководство компании может настоять на необходимости пересмотра интеграционного проекта. Еще одним камнем преткновения для реализации общей базы данных является коммерческое ПО. Большинство коммерческих приложений работает только со встроенной схемой данных, возможность адаптации которой зачастую оставляет желать лучшего. Усложняет задачу также тот факт, что создатели коммерческого ПО склонны изменять схему данных с каждой новой версией своих продуктов. Способы интеграции приложений: удаленный вызов процедуры, обмен сообщениями. Передача файла и общая база данных позволяют приложениям получить доступ к общим данным, но не к общей функциональности. Удаленный вызов процедуры устраняет этот недостаток за счет сильного связывания интегрируемых приложений. Зачастую же задача интеграции заключается в обеспечении своевременного обмена данными между слабосвязанными приложениями. Оптимальное решение должно обладать характеристиками передачи файла, обеспечивая частый, асинхронный обмен малыми порциями данных с уведомлением получателя и механизмом повторной передачи. В отличие от общей базы данных сведения о представлении и хранении информации должны быть скрыты от интегрируемых приложений. Кроме того, приложение должно иметь возможность удаленного вызова процедуры другого приложения с гарантированным отсутствием сбоя. Используйте обмен сообщениями для быстрой, мгновенной, надежной и асинхронной передачи данных изменяемого формата. Асинхронный обмен сообщениями устраняет большинство недостатков распределенных систем. Для передачи сообщения не требуется одновременной доступности отправителя и получателя. Более того, сам факт асинхронного обмена данными побуждает разработчиков к созданию компонентов, не требующих частого удаленного взаимодействия. Подобно передаче файла система обмена сообщениями обеспечивает слабое связывание объединяемых приложений. Сообщения могут быть преобразованы во время передачи без уведомления отправителя или получателя. Слабое связывание позволяет разработчикам использовать различные способы доставки сообщений: широковещательную рассылку всем получателям, маршрутизацию сообщений одному получателю или их группе и т.п. Необходимость преобразования данных обусловлена наличием у приложений различных концептуальных моделей, т.е. семантическим диссонансом. В отличие от общей базы данных, обмен сообщениями не предполагает использования специальных средств для его устранения. Это связано с тем, что семантический диссонанс неизбежно возникает при добавлении к интеграционному решению новых приложений (например, в результате слияния информационных систем компаний). Частый обмен небольшими порциями данных создает предпосылки для использования приложениями общей функциональности. Если получение сообщения о размещении нового заказа требует выполнения некоторых действий, они могут быть инициированы путем отправки специальных сообщений. Несмотря на то что скорость подобного взаимодействия ниже, чем при использовании удаленного вызова процедуры, вызывающей стороне не приходится ждать ответа на отправленное сообщение. На самом деле обмен сообщениями не такой уж и медленный— достаточно большое число систем обмена сообщениями используются финансовыми организациями для обработки тысяч котировок акций в секунду. Интеграция CAD и САМ Автоматизация производства обеспечивается соответствующим программным обеспечением (САМ software). Таких программных продуктов существует достаточно много. Многие производители коммерческих систем CAD и САМ преувеличивают выгоды от их использования. Реальный выигрыш от этих систем гораздо меньше рекламируемого из-за низкой степени их интеграции. Для повышения производительности и обеспечения выживания на глобальных рынках с постоянно возрастающей конкуренцией необходимо улучшение интеграции. Первоочередной задачей является полная автоматизация технологической подготовки производства, потому что эта фаза связывает проектирование и производство. Именно подготовка производства стала основным препятствием. Производственный цикл детали Под дискретным производством понимается изготовление продукта, проходящего через конечное число технологических и сборочных операций. Непрерывное производство подразумевает изготовление продукта, претерпевающего непрерывные изменения, например в ходе химических реакций, в результате которых заготовка преобразуется в готовую деталь.. Когда готовый проект передастся в производственный отдел, инженер-технолог преобразует описание деталей и устройств в технологические инструкции. Эти инструкции подробно описывают процессы, необходимые для превращения необработанных заготовок в готовые детали, а также последующие операции сборки этих деталей в конечный продукт. Процедура, таким образом, заключается в сопоставлении требований к деталям и имеющихся производственных мощностей. Инженер-технолог должен интерпретировать инженерно-техническую документацию, принимать решения о том, как разрезать листы и собирать детали, определять порядок выполнения операций, выбирать инструмент, станки и крепеж и решать другие подобные задачи. Эта задача значительно упрощается, если у инженера уже есть готовый план для аналогичного продукта. Поэтому похожие детали обычно группируются в семейства, что позволяет использовать концепцию групповой обработки. После завершения фазы технологической подготовки начинается реальное производство детали в соответствии с инструкциями, подготовленными на предыдущем этапе. Если для обработки детали используются станки с ЧПУ, оператор станка должен написать соответствующую программу. Существует множество программных средств, позволяющих создать программу для станка с ЧПУ непосредственно по базе данных системы автоматизированного проектирования. Готовые детали проверяются в соответствии с разработанными стандартами качества. Прошедшие проверку детали собираются, упаковываются, помечаются и отправляются заказчикам. Таким образом, интерфейсом между проектированием и производством оказывается технологическая подготовка. Интеграция средств проектирования и производства не будет завершена до тех пор, пока технологическая подготовка не будет автоматизирована. Стандарты обмена данными между САПР Когда две или более CAD/CAM/CAE-системы объединяются и связываются в единое приложение для совместного использования данных, часто возникает проблема обмена данными. Фактически всегда имеется потребность связать воедино несколько систем либо внутри одной организации, либо внешне, как в случае со смежниками или поставщиками компонентов. Для решения этой коммуникационной проблемы необходима возможность преобразовывать данные технических требований одной системы в форму, понятную для других систем, и наоборот. Различные CAD/CAM/CAE-системы хранят данные технических требований в структурах разного вида, поэтому для переноса данных необходимо преобразовать данные технических требований одной системы в формат другой системы, еще один конвертор необходим для переноса данных между двумя системами в противоположном направлении. Следовательно, для каждой пары систем необходимо иметь два конвертора. Если у нас есть п различных систем, нам необходимо разработать п(п - 1) конверторов, поскольку количество пар систем равно п(п - 1)/2. Например, для обмена данными между 10 системами придется разработать 90 конверторов. Таким образом, метод прямого конвертирования непрактичен, так как требует разработки слишком большого количества конверторов при необходимости работать со множеством систем.  Однако обмен данными можно обеспечить, введя нейтральную структуру базы данных, называемую нейтральным файлом, которая была бы независима от существующих САПР. Эта структура будет действовать как промежуточная точка коммуникации между различными структурами баз данных САПР. Таким образом, в каждой системе будет своя пара конверторов для экспорта и импорта данных в этот нейтральный формат. Рассмотрим три типичных формата нейтрального файла: IGES (Initial Graphics Exchange Specification — первоначальная спецификация обмена графическими данными), DXF (Drawing interchange Format — формат обмена чертежами) и STEP (STandard for Exchange of Product model data — стандарт обмена данными о модели продукта). В настоящее время IGES является самым популярным форматом нейтрального файла, а формат DXF используется главным образом для обмена данными чертежей. STEP — это стандартный формат данных, используемый для хранения полной информации обо всем жизненном цикле продукта, включая проектирование, анализ, производство, контроль качества, испытания и обслуживание помимо обычных данных технических требований. В настоящее время CAD-системы, перешли к формату STEP. Форматы IGES, DXF, STEP Описание формата IGES версии 1.0, опубликованное в январе 1980 г. В 1981 г. оно было принято Американским Национальным институтом стандартов (ANSI) в качестве стандарта. IGES был первым стандартным форматом обмена данными, разработанным для нужд передачи данных технических требований между различными САПР. Ранние версии IGES были неявным образом ориентированы на CAD/CAM-системы 1970 -х и начала 1980-х гг., то есть главным образом на обмен чертежами. В более поздних версиях спектр типов данных, подлежащих обмену, был расширен. Формат DXF (Drawing interchange Format — формат обмена чертежами) изначально разрабатывался для того, чтобы предоставить пользователям гибкость в управлении данными и преобразовании чертежей программы AutoCAD в форматы файлов, которые могли читаться и использоваться другими САПР. Из-за популярности AutoCAD формат DXF стал фактическим стандартом обмена файлами CAD-чертежей почти для всех САПР. На самом деле почти в каждой из появляющихся новых САПР имеется транслятор в формат DXF и обратно. DXF-файл — это текстовый ASCII-файл, состоящий из пяти разделов: Header (Заголовок), Table (Таблица), Block (Блок), Entity (Элемент) и Terminate (Конец). В разделе Header описывается среда AutoCAD, в которой был создан DXF-файл. В разделе Table содержится информация о типах линий, слоях, стилях текста и видах, которые могут быть определены на чертеже. В разделе Block содержится список графических элементов, определенных как группа. Конкретные данные по каждому элементу хранятся в соответствующем разделе Entity, который следует сразу за разделом Block. Раздел Entity — это главный раздел DXF- файла, в котором описываются все элементы, присутствующие на чертеже. Форматы IGES и DXF были разработаны для обмена данными технических требований, а не данными о продукте. Под данными о продукте мы понимаем данные, относящиеся ко всему жизненному циклу продукт. PDES (Product Data Exchange Specification — спецификация для обмена данными о продуктах). Целью PDES было устранить потребность в инженерных чертежах и других бумажных документах при обмене информацией о различных фазах жизненного цикла продукта между сходными или различающимися САПР. В основе разработки STEP лежат следующие принципы. Стандарт STEP должен ориентироваться на данные о продукте, которые включают информацию обо всем жизненном цикле продукта: проектировании, производстве, контроле качества, испытании и поддержке. В структурах данных STEP информация, относящаяся к приложению, должна храниться в модуле уровня приложения, отдельно от общей информации о форме. Благодаря такому подходу структура данных сможет поддерживать широкий спектр приложений, избегая при этом избыточности в общей структуре данных. Для определения структуры данных должен использоваться формальный язык. Спецификации IGES и DXF описывают формат физического файла, в котором хранятся все геометрические и прочие данные. В STEP данные описываются на языке EXPRESS, а затем результат преобразовывается в физический файл. Таким образом можно избежать неоднозначностей при интерпретации данных о продукте, извлеченных из файла. Использование механизмов OLE и COM в САПР COM (Component Object Model) OLE (Object Linking and Embedding) Говоря об обмене данными между различными CAD/CAM/CAE-системами, мы обычно подразумеваем широко используемый механизм экспорта/импорта из формата хранения данных одной системы в формат хранения данных другой. Все это выполняется на файловом уровне и нередко приводит к частичной потере данных из-за их некорректной интерпретации. Связано это с тем, что разработчики программ преобразования данных из одного формата в другой зачастую лишены возможности взаимодействия с создателями данного формата и не имеют полной информации по его структуре. В качестве альтернативы ряд компаний предлагает так называемый прямой интерфейс между приложениями, при котором данные опять же передаются из одного формата в другой. По сути, это то же самое, только реализовано совместными усилиями разработчиков соответствующих форматов и позволяет практически полностью устранить потерю конвертируемых данных. В то же время системы постоянно развиваются, их форматы хранения данных претерпевают различные модификации, требуя внесения соответствующих изменений и в интерфейсы обмена данными. Это приводит к необходимости постоянного привлечения специалистов для поддержки обмена данными между приложениями. Пользователи программного обеспечения Microsoft Office с технологией Object Embedding and Linking (OLE) — внедрение и связывание объектов — работают уже давно. Первоначально она обозначала возможность внедрения документа, созданного в одном приложении, в документ, созданный в другом приложении. Хорошим примером этому могут послужить таблицы Excel в документах Word. Изначальная концепция OLE изменялась со временем и в итоге была заменена идеей модели объектных компонентов (Component Object Model — COM). COM представляет собой глобальный интерфейс для создания программных компонентов, которые можно совместить с другими компонентами в любом сочетании. Особенностью COM-объектов является то, что они существуют в пределах одного компьютера. Следующим шагом стало появление Distributed Common Object Model (DCOM), которые, по сути своей, практически ничем не отличаются от COM-объектов, за исключением того, что существуют и взаимодействуют друг с другом они не только в пределах одного компьютера, но и в компьютерной сети. Здесь мы уже имеем распределенную объектную модель, когда множество взаимодействующих друг с другом объектов находятся на разных рабочих местах, объединенных сетью. OLE for D&M (в литературе можно встретить обозначение OLE4DM) — это один из аспектов распределенной модели, когда предлагается набор стандартных интерфейсов для обмена и управления данными между трехмерными CAD-, CAM- и CAE-систем. Эта технология нацелена на предоставление прямого доступа одной системы к данным математической модели другой системы, минуя файловый обмен. OLE for D&M поддерживает клиент-серверную технологию и выступает одним из эффективных средств интеграции отдельных Windows-приложений в единый комплекс. Если приложение поддерживает этот интерфейс, оно легко интегрируется с другой системой. |