Product Data Management - система управления инженерными данными о различных сложных технических объектах - организационно-техническая система, обеспечивающая управление всей информацией о них.
PDM-системы включают в себя управление инженерными данными; управление документами; управление информацией о различных сложных технических объектах; управление техническими данными; управление технической информацией; управление изображениями и манипулирование информацией, всесторонне определяющей конкретное изделие.
Основные функциональные возможности PDM-систем охватывают следующие направления:
. управление хранением данных и документами;
. управление процессами и потоками работ;
. управление структурой продукта;
. автоматизация генерации выборок и отчетов;
. механизм авторизации.
С помощью PDM-систем осуществляется отслеживание огромных массивов инженерно-технической информации и данных, необходимых на этапах производства, проектирования или строительства, а также поддержка эксплуатации, сопровождения и утилизации технических изделий. Данные, относящиеся к одному изделию и организованные PDM-системой, называются цифровым макетом. PDM-системы интегрируют информацию любых форматов и типов, предоставляя её пользователям уже в структурированном виде. PDM-системы работают с текстовыми документами, с геометрическими моделями и данными, необходимыми для функционирования автоматических линий, станков с ЧПУ, причём доступ к таким данным осуществляется непосредственно из PDM-системы.
Одной из наиболее важных и необходимых составляющих PDM системы является подсистема (модуль) интеграции с САПР (например - модули интеграции с Autodesk Inventor, SolidWorks, Компас 3D и иными системами). В сочетании с PDM резко возрастает эффективность применения САПР за счёт добавления к этим системам возможностей по хранению версий, проработки альтернативных вариантов, механизмов многопользовательской работы над общей моделью сборки, функциональности по обмену информацией между сотрудниками в реальном времени, автоматического ведения состава изделия и управления доступом на основе иерархии сборочной единицы.
Как правило, требуется передача данных в системы управления предприятием (ERP) и бухгалтерские системы (1С). В зависимости от конкретных задач применяется передача данных напрямую между СУБД, управляемая событиями на сервере приложений. Также широко используется возможность встраивания пользовательских команд в интерфейс клиентского приложения PDM системы. Например, можно выполнить экспорт структуры изделия в XML и передать его в систему технологической подготовки производства. Или, наоборот, из PDM системы обратиться к внешнему справочнику покупных изделий и т.д.
В некоторых PDM системах реализован механизм электронного согласования документов. После присвоения электронному документу статуса "На согласовании", всем необходимым участникам процесса рассылаются уведомления о необходимости принять участие в согласовании с приложенной ссылкой на документ. При этом реализована возможность оставлять пометки и замечания прямо на изображении (так называемая функция "красного карандаша"). Согласовав или оставив предложения по доработке документа, участник процесса проставляет свою электронную подпись.
15.09.2000 Владимир Краюшкин
«PDM - системы управления производственными данными», «PDM - системы управления проектными данными», «PDM - системы управления данными о производственных процессах». Эти и еще множество других «неформальных» определений систем PDM можно встретить в сегодняшней компьютерной литературе. Некоторая размытость определений с одной стороны, и разнообразие применяемых понятий с другой стороны, свидетельствуют о том, что PDM - это развивающийся, многообещающий и интересный сектор рынка промышленных информационных систем.
Среди сотрудников компаний, внедряющих новые информационные технологии в промышленности, гуляет поговорка: «Путь к сердцу руководителя лежит через хороший PDM», а среди директоров ИТ-служб на производстве бытует мнение, что «Хочешь похудеть - купи себе PDM». Разработчики концепций реинжиниринга и системные интеграторы всегда включают в проекты пункты о внедрении PDM, а реальные исполнители внедрения этих систем на производстве - это люди, потерянные для семьи. За десять лет сложилось целое направление в ПО , значение которого еще предстоит оценить.
Этапы большого пути
Первые системы PDM - (Product Data Management) появились в конце 80-х - начале 90-х годов. Их появление было вызвано возрастающими сложностями в области САПР на уровне рабочей группы. Собственно проблемы состояли в том, что для обеспечения эффективной работы над одним сложным изделием группы разработчиков требовалось дополнительное к САПР ПО, которое отслеживало бы состав всех файлов, генерируемых САПР, каталогов внутри группы на предмет их целостности, непротиворечивости и актуальности.
В начале 90-х даже «тяжелые» промышленные САПР уже не рисковали предлагать «встроенные» модули управления совместно используемой проектной информацией, сосредоточившись только на трехмерном твердотельном групповом проектировании сборок. Информационное обеспечение такого рода сборок было выделено в самостоятельную задачу, реализация которой и вызвала к жизни появление систем PDM первого поколения. Как правило, такие PDM имели прямой интерфейс с САПР сборок, встроенную СУБД и генератор отчетов для вывода спецификаций на изделие.
Разработкой PDM первого поколения наиболее плодотворно занимались производители «тяжелых» САПР, которые раньше всех поняли, что успех активного внедрения их основных продуктов требует наличия специального ПО, решающего вопросы взаимной увязки конструкторских данных, надежного хранения наработанного каждым из участников проекта, обеспечения нужного уровня доступа ко всей проектной информации, структурированной в соответствии с конструктивным членением изделия. При таком подходе исходными, «базовыми», данными для работы PDM становились, во-первых, структура изделия (получаемая напрямую из среды параллельного проектирования САПР), во-вторых, структура отношений между участниками проекта (получаемая в ходе выполнения административных задач по адаптации PDM на конкретном подразделении предприятия). В-третьих, дополнительная производственная информация, относящаяся к проекту в целом.
Областью применения систем PDM первого поколения были группы проектировщиков. Основное препятствие, которое устранялось теперь за счет систем PDM - это несогласованность автоматизированной работы группы проектировщиков. Упорядочение, рационализация и координация движения проектной информации внутри группы конструкторов-проектировщиков и достигалось за счет применения систем PDM первого поколения.
К середине 90-х стало ясно, что системы PDM первого поколения успешно решают только задачи информационного обеспечения группы проектировщиков. Для интеграции систем PDM в общий производственный процесс необходимо было уйти от концепции первого поколения, а сами PDM дополнить и расширить. Состав модулей дополнить новой функциональностью, учитывающей не только конструкторские, но и другие аспекты деятельности, в первую очередь - технологические. Необходимо было расширить рамки применимости систем PDM за границы проектных групп, включив в информационный контур управленческие подразделения, технологические и плановые отделы. Характерной задачей PDM второго поколения стало обеспечение управления всеми проектными данными в соответствии с правилами, устанавливаемыми для участников на каждом этапе работ над изделием - задача управления жизненным циклом изделия. В качестве «параллельной» решалась также задача «сотрудничества» с модулями материально-ресурсного планирования производства систем АСУ.
Областью применения систем PDM второго поколения стали группы и подразделения предприятия, непосредственно занятые в процессе производства, а PDM стали претендовать на звание «тяжелых», «промышленных» пакетов. Второе поколение систем PDM позволило расширить информационный обмен, включив в его сферу все подразделения предприятия, автоматизировать некоторые функции принятия решений при продвижении информации об изделии по этапам жизненного цикла, сократить потери на организацию доступа к общему банку данных предприятия для каждого из клиентов системы PDM. Как результат - применение такого рода систем PDM должно было сократить непроизводственные потери, особенно при выполнении работ над образцами новой техники. Характерными представителями второго поколения систем PDM, первыми появившимися на российском рынке, были Optegra от Computervision и IMAN от EDS Unigraphics .
В это же время ведущие системные интеграторы начали активно продвигать идею полного электронного определения изделия - идею тотального охвата всех информационных потоков, касающихся изделия, независимо от того, где, кем и для чего они были произведены. Вдруг выяснилось и стало очевидным фактом совершенно игнорируемое ранее положение - не конструкторы-проектировщики задают структуру изделия, а структура изделия диктуется, пусть и косвенно, составом тактико-технических характеристик разработки. А эта информация, в свою очередь, попадает в ТЗ после анализа «прибыльных» ниш рынка и учета конкретных потребностей заказчиков. Следовательно, уже не конструкторы-разработчики формируют первую версию структуры изделия.
Важный поворотный пункт в эволюции PDM состоит в том, что если раньше информация о структуре изделий формировалась внешними «тяжелыми» САПР (сборки CADDS5, UG, CATIA и т.п.) и экспортировалась в PDM, то теперь формирование структуры изделия («дерева сборки») становится непосредственной задачей самих систем PDM. «Тяжелые» САПР теперь уже становятся получателями, а не производителями, информации о структуре изделия. Результатом нового видения проблемы охвата информационного потока стало значительное ужесточение требований к системам PDM в части платформенной независимости, универсальности, многофункциональности, открытости и дружественности интерфейсов пользователя.
Провозглашенное стремление к тотальному охвату информационных потоков потребовало также со стороны систем PDM более тесной интеграции с ERP-системами: R/3, Baan IV, J.D. Edwards и т.д. Однако стандарта на структуры данных «де юре» для таких систем не существовало, поэтому в качестве рабочего варианта для средств интеграции PDM и ERP были взяты форматы описания состава изделия из R/3 и структура данных STEP для автомобилестроения или авиастроения.
Для первых систем PDM третьего поколения характерны следующие особенности: полная реализация идеологии клиент-сервер, реализация СУБД на базе самых производительных ядер, наличие интерфейса с ERP-системами, вызов клиентских модулей через унифицированный пользовательский графический интерфейс. Базовыми функциональными возможностями систем третьего поколения считаются: контроль структуры изделия, контроль жизненного цикла изделия, контроль версий и «релизов» информационных объектов, генератор спецификаций. Дополнительно решалась задача контроля потока работ каждого конкретного исполнителя. Как результат, применение систем PDM третьего поколения должно было существенно сократить непроизводственные потери не только при выполнении работ над образцами новой техники, но и при организации работ по серийному и мелкосерийному выпуску продукции. К этому поколению принадлежит продукт EPD.Connect , уже нашедший применение в ряде отраслей российской промышленности.
К концу 90-х на рынке систем PDM возникли новые задачи, которые нельзя было решить в системах третьего поколения. Речь идет об электронной коммерции и все более углубляющейся глобализации промышленного производства. Все это требовало появления ПО, учитывающего оптимальный по количеству и рациональный по производительности состав соисполнителей, допустимых для участия в крупном машиностроительном проекте вне зависимости от их реального географического расположения. Теперь центр тяжести в структуризации для систем PDM нового, четвертого поколения перемещался с категории «изделие» на категорию «процесс изготовления и сопровождения изделия». Именно при таком изменении «видения» проблемы достигается реальный прорыв в качестве управления и оперативности его применения. В новых условиях успех фирмы-изготовителя определяется уже не просто способностью быстро «выбросить» на рынок новую модификацию серийного изделия или новое изделие, а тем, как быстро производитель сумеет перестроить свой производственный процесс под многочисленные и разнообразные требования заказчиков, насколько рационально она сможет перестроиться с массового и серийного производства на производство «под заказ». Ясно, что понятие «изделие» при такой методике перестает быть чем-то раз и навсегда заданным, «информационной основой», «структурной базой» PDM, зато на первый план выступают структуры производственных отношений, их изменение и упорядочение в ходе выполнения сформированного портфеля заказов.
В системах PDM четвертого поколения существенно возросли функциональные возможности отслеживания запросов на внесение изменений в модельный ряд управления модификациями и протоколирования-рассылки хода изменений. Реально полноценная организация связей с заказчиками (напрямую или, что чаще всего - через сеть дилеров-поставщиков) возможна только через Internet при помощи Web-технологии. При этом чистая, «классическая», клиент-серверная модель уже перестает работать, необходимо ориентироваться на широкое использование принципов организации среды WEB, особенностей применения Java, HTML и XML для формирования страниц взаимодействия с пользователями системы и т.д. Совокупность всех этих требований приводит к появлению принципиально нового поколения Web-ориентированных систем PDM, которые уже успели «окрестить» как cPDm (collaborative Product Definition management) . От систем ожидается не централизованный характер управления данными (в проекте - один директор, «иерархия» отношений соответствует структуре «классического» унитарного предприятия), а «collaborative» - характер производственных связей, подразумевающий сотрудничество, а не прямое подчинение (в проекте - несколько предприятий, объединяющихся для выполнения одних целей, а в другое время - вольных входить в любые другие производственные союзы, связи и кооперативные объединения). Еще заметим, что «Data» («данные») в новой аббревиатуре заменено на слово «Definition» («определение»), что несомненно отображает широту информационного охвата при работе с изделием. Однако пока будем придерживаться «традиционного» наименования - PDM.
PDM сегодня
Рассмотрим типичный состав и функциональность современной системы PDM. Прежде всего, система должна быть основана на универсальных принципах сетевого взаимодействия (IP-адресация, независимость от физических характеристик среды передачи сигнала, глобальный охват), а ее пользовательский интерфейс должен быть тесно интегрирован со средствами для просмотра Web-страниц. В состав современной системы PDM должны входить модули генерации и сохранения («Vaulting») объектов, их версий и релизов. Само хранение выполняется в системах четвертого поколения независимо от географического расположения сервера базы данных - храниться на нем могут на равных правах как сами объекты, так и ссылки на них (URL, NFS-локализация, сетевой адрес файл-сервера и т.д.). При реальной сетевой реализации идеи «Vaulting» серверов может быть несколько, база данных при этом получается распределенной, а СУБД должна выполнять в полной мере сетевой сервис. Реально СУБД, позволяющие реализовать идею «сетевого распределенного хранилища данных» («Distributed Vault» в зарубежной литературе) представлены пока только семейством Oracle 8i.
Современная система PDM в наиболее полном объеме реализует функции управления составом изделия, структурой всех его составных частей, деталей, узлов и агрегатов. Кроме того, в управляемую структуру должны входить и управляться системой дополнительные структурированные информационные объекты, состав которых отражает все необходимые данные для организации работ по производству самого изделия - структура оснастки, инструментального парка, операций и переходов, технологических приемов.
Современная система PDM управляет и обеспечивает обмен данными о структуре изделия и вносимых в него изменениях, обеспечивает взаимодействие с любыми корпоративными приложениями в рамках определения и управления действий по внесению изменений в изделие, за счет чего упрощаются процессы совершенствования и модификации. Современная система PDM должна обеспечивать создание и поддержку множества взаимозависимых и взаимоувязанных спецификаций изделия (классические BOM, конструкторские, технологические, заказные спецификации, спецификации на покупные изделия, спецификации поставок и т.д.), благодаря чему пользователь получает согласованное представление об изделии на протяжении всего его жизненного цикла.
Современная система PDM должна иметь многоуровневый механизм управления реквизитами-атрибутами, настраиваемый на конкретный состав задач по управлению тем или иным узлом, агрегатом или даже изделием в целом. Современная система PDM в обязательном порядке должна иметь встроенный механизм управления жизненным циклом изделия. В этот механизм должны входить средства ролевого управления любым пользователем системы PDM, средства отображения текущего состояния любого бизнес-объекта в терминах жизненного цикла, средства протоколирования состояний каждого бизнес-объекта, учет всех его состояний и средства администрирования. Для решения задач оперативного управления в системах PDM четвертого поколения обязательно наличие полнофункционального модуля Workflow.
Управление структурой изделия. Средства управления структурой изделия в системах четвертого поколения позволяют создавать и обрабатывать различные виды спецификаций изделия (BOM). Кроме того, нужно иметь возможность вести управление по деталям и узлам, составляющим изделие, а также по относящимся к ним документам (файлам, наборам файлов, адресам в Internet) и специальным производственным характеристикам - атрибутам. Для управления на уровне групп предприятий используется динамическая, содержащая максимально полную информацию об изделии структура, которая отображает все возможные конфигурации изделия. Сервисные функции должны допускать просмотр структуры изделия с любой степенью детализации, раскрывать сборки и получать представление о входящих в ее состав подсборках и деталях:
- Ведение спецификаций.
Спецификация - ассоциативная структура изделия, из которой в соответствии с определенными критериями конфигурации выводится представление сборки. Работая как фильтр, критерии конфигурации определяют, какую версию детали надо вывести. Например, часто специалист по планированию производства хотел бы видеть структуру изделия в зависимости от степени готовности всех ее составных частей к конкретным срокам, а специалист-технолог - в зависимости от применяемых материалов или технологических приемов обработки этих материалов.
- Многоуровневые спецификации.
Для современных PDM систем фактическим стандартом является возможность вывода не менее двух типов спецификаций, а именно иерархической структуры (дерева сборки) и подетального общего списка (список наименований комплектующих). Спецификации первого типа чаще используются в конструкторско-технологических подразделениях, а второго - на сборочных участках и при работе по заказам.
- Многовариантный генератор спецификаций.
Участникам производственного процесса часто необходимо иметь возможность построения спецификаций в зависимости от рода деятельности и профессиональной принадлежности. Например, инженерам-конструкторам важна спецификация, построенная по принципу «как спроектировано», а специалистам планово-производственного отдела по принципу «как запланировано».
- Отслеживание действия внесенных изменений и модификаций.
В системах PDM четвертого поколения одна из типичных функций - это отслеживание того, какая деталь и как применяется в каждой из модификаций конкретного изделия. Эта возможность значительно упрощает процесс постепенного формирования полного электронного определения изделия. В процессе внесения и утверждения изменений в проект предприятие должно учитывать, когда и для каких партий эти изменения уже действуют, а для каких - нет, когда и в каких количествах необходимо производить новые детали. Как правило, должно быть реализовано три типа такой функциональности: отслеживание по календарным срокам, отслеживание по идентификационному номеру изделия и отслеживание по номеру партии. Кроме того, часто на предприятиях авиастроения и судостроения может быть задано отслеживание эффективности внесенных изменений для нескольких разных изделий, в которых используется данная деталь.
- Отслеживание принадлежности к модельному ряду («baseline»).
Такая функциональность позволяет получать на произвольно выбранных этапах жизненного цикла актуальный срез по списку деталей и документов с определением тех из них, которые имеют ключевое значение для структуры изделия. Поскольку с течением времени появляется множество конфигураций структур изделия, данная функция помогает определить те конфигурации, которые представляют для предприятия наибольший интерес.
- Отслеживание ссылок и многоуровневых ссылок на документы.
Такая функциональность обеспечивает ассоциирование любых документов, относящихся к детали, агрегату или изделию, позволяя разработчикам присоединять дополнительную информацию в любом удобном для понимания виде. Примерами ссылочной информации (присоединенных документов) могут служить: готовые спецификации, техническая документация, файлы САПР, мультимедийные файлы и даже ссылки на другие Web-сайты в Internet. Такая методика построения и отслеживания ссылок позволяет собирать все накопленные данные об изделии и обеспечивает создание максимально насыщенной информационной структуры изделия.
- Отслеживание изменений.
Отслеживание изменений позволяет группировать и просматривать в удобном для понимания виде информацию о тех вносимых изменениях, которые приводят к появлению новой версии (модификации) изделия. Пользователь, таким образом, будет знать как о состоянии проведения изменений в смысле структуры изделия и в смысле этапов жизненного цикла, так и о незавершенных изменениях той или иной детали и сможет использовать эту информацию в процессе принятия решений.
- Динамический просмотр иерархически организованной информации («Навигация по структуре изделия»).
Эффективность применения современных систем PDM во многом определяется тем, какие эти системы предоставляют пользователю возможности поиска информации о нужных деталях, просмотра структуры изделия и выполнения необходимых операций над выбранными элементами этой структуры. Лучше всего «принимаются» промышленностью и легче всего «осваиваются» пользователями такие системы PDM, в которых пользователь работает с хорошо знакомым ему графическим интерфейсом (например, Netscape Communicator), который организует иерархическое представление всей информации об изделии и тем самым упрощает переходы от деталей к сборкам и обратно. Когда пользователь выбирает нужную ему деталь на дереве сборки, система PDM автоматически выводит на экран клиентской машины список ссылочных документов и всю необходимую информацию - например, номер детали, данные о ревизии, дату последней модификации, и т.д.
- Сравнение структур изделия.
Пользователь может выбрать любые две структуры изделия, любые две версии, любые два релиза, сравнить их и выявить отличия друг от друга, если таковые существуют на множестве отслеживаемых параметров модели изделия (структурный состав, атрибуты и их значения). Отчет о проведенном сравнении формируется в виде, удобном для браузера системы, например, в виде XML. При сравнении двух ревизий одной и той же структуры изделия требуется обнаружить следующие различия (типичная задача): уменьшилось или увеличилось количество определенных комплектующих, добавился ли ссылочный документ и САПР-модель для ссылочного документа. Интерактивный, динамический механизм сравнения структур незаменим для управления различными версиями изделия. Управление изменениями. В большинстве организаций поэтапная многоступенчатая процедура внесения и утверждения изменений достаточно хорошо отработана и успешно применяется в практике промышленного производства, что является важной предпосылкой к автоматизации этой процедуры на всех ее этапах для всех ее участников. Системы PDM четвертого поколения должны предоставлять универсальное решение, которое обеспечивает контроль за информацией о предполагаемых изменениях.
- Контроль за всей информацией. Средства управления изменениями должны контролировать всю информацию о внесении изменения от момента постановки задачи до полного ее разрешения. Процесс внесения изменения разделяется на этапы: запрос на изменение, изучение причин, повлекших за собой необходимость изменения, предложения альтернативных вариантов, реализация изменения путем формулировки заявки на изменение и выполнение действий по внесению изменения. Решения каждого этапа должны протоколироваться для возможного «отката» и проверки принятых решений.
- Гибкие процессы по внесению изменения. Разные модификации требуют разной степени детализации и задействуют разные этапы общего процесса внесения изменений. Средства управления изменениями в рамках таких требований должны позволять настраивать процесс внесения изменений таким образом, чтобы он включал необходимое для конкретной модификации число шагов и полностью описывал изменение и его последствия.
- Автоматизация потоков заданий («Workflow»). Наиболее полная автоматизация процесса внесения изменений достигается благодаря интеграции средств управления изменениями с функциями управления потоком заданий. Каждый этап процесса внесения изменений может быть представлен как задание потока работ и автоматически передан пользователю или системе, которые отвечают за выполнение этого задания. По завершению выполнения задания система управления потоком заданий продолжит процесс внесения изменений до тех пор, пока не будут завершены все его этапы, и документация по изделию получит статус выпущенной. Для четвертого поколения систем PDM характерно следование рекомендациям и стандартам рабочей группы Workflow Management Coalition.
Визуализация трехмерных сборок и сопутствующей информации:
- Реализация визуального представления любого уровня сложности, вплоть до фотореалистического, а также цифровое макетирование («Mock-Up») сборок любой степени сложности. Для того чтобы визуализация была возможна на любом рабочем месте вне зависимости от технических параметров локального компьютера пользователя, собственно визуализация должна выполняться на специализированном сетевом сервере, а на рабочее место пользователя через сеть будет передаваться только «картинка» результата.
- Динамическая навигация по трехмерной структуре сборки, вне зависимости от конкретной САПР, с помощью которой были созданы входящие в сборку компоненты.
- Автоматизация построения «взрывных» видов, сечений, разрезов сборки, автоматизация построения «кинограммы» сборочных процессов, моделирование в трехмерном виде монтажных операций, сборочных и ремонтных работ, учет пространственных и эргономических ограничений функционирования изделия.
- Реализация методики «виртуального предприятия», при которой трехмерная сборка и производственная инфраструктура анализируются на совместимость для вывода о возможности/целесообразности выпуска именно такого изделия именно этим цехом, именно этого предприятия.
- Мощное средство агрессивной маркетинговой политики - потребитель может «вписать» себя в трехмерную модель будущего изделия с требуемыми характеристиками, «почувствовать» необходимость покупки именно такого изделия у именно такого производителя.
Средства управления составом предприятий-поставщиков комплектующих. Для выпуска изделия с наименьшими затратами и оптимизации взаимодействия с поставщиками необходимо иметь ранжируемую базу данных по комплектующим. Она может быть выполнена на основе «отфильтрованной» информации из PDM-систем самих поставщиков комплектующих, причем принцип отбора информационных компонент и набор общих технических характеристик («реквизитов») задается в «материнской» PDM. Для анализа применимости, надежности и перспективности поставщиков система PDM четвертого поколения должна иметь некоторый сервис ранжирования поставщиков, позволяющий определить в каждом конкретном случае оптимальный состав соисполнителей, субподрядчиков и поставщиков.
Реализация этих и многих других вспомогательных функций в составе систем PDM четвертого поколения приводит к тому, что PDM становится приложением, в наиболее полной мере реализующим новаторские идеи ведения электронного бизнеса, но только теперь уже не только и не столько в сфере продаж потребительских изделий и услуг, сколько в области решений типа B2B.
На пути к пятому поколению
Делать прогнозы - занятие хотя и увлекательное, но неблагодарное: если прогноз сбывается, то становится скучно от того, что все и так было известно, а если не сбывается - обидно от несбывшихся ожиданий. Однако попробуем все-таки посмотреть лет на пять вперед: что там нас ждет, какие системы PDM выглядывают из-за горизонта?
Тенденция к глобализации и разделению труда в рамках транснациональных промышленных структур потребует перехода от «Distributed Vault» к «Globalized Vault» - своего рода «сетевым банкам промышленных знаний». Тенденция эта в первую очередь затронет не очень крупные фирмы, специализирующиеся на поставках комплектующих и стандартизованных изделий. Уже сейчас для ограниченной номенклатуры изделий, действуют доступные через Internet справочники-прейскуранты на крепеж, монтажные изделия, электротехнические и гидравлические стандартизованные компоненты. Уже сейчас число таких компонентов исчисляется сотнями тысяч и пополняется еженедельно. Получив через Internet доступ к такому справочнику, пользователь уточняет свой запрос, выполняет действия по получению более подробного доступа к информации о каждом из запрошенных изделий и, в конце концов, к составлению и оплате заказа поставки нужной номенклатуры в требуемый срок в указанное место на земном шаре.
Тенденция к стандартизации при описании структур изделий должна иметь результатом, видимо, появление единого промышленного стандарта на описание сборки. Возможно, хотя и небесспорно, что основой такого стандарта станут предложения STEP.
Тенденция к распределенным вычислениям в сети и успехи в области Java-программирования снимут вопрос о языковой среде реализации динамических функций систем PDM. Основной барьер для повсеместного использования Java в качестве языка приложений сетевых реализаций систем PDM сейчас - недостаточная скорость исполнения Java-приложений на стороне пользователя. С выпуском специализированной аппаратуры и программ реализации «быстрой Java» положение должно кардинально измениться.
Тенденция к взаимопроникновению современных технологий приведет к тому, что системы PDM станут базовым инструментальным средством для задач CALS (прежде всего в области эксплуатации сложной военной техники), для задач управления качеством (как определено в документах по ISO 9000), для задач управления ресурсами предприятия, для задач включения заказчика в контур управления изготовлением изделия.
Тенденция к упрощению и оптимизации структуры отношений с поставщиками приведет к тесной интеграции систем PDM базового предприятия и предприятий-участников. Отсюда с неизбежностью следует вывод о возможной в будущем унификации и стандартизации базового набора функций для всех новых систем PDM. Скорее всего, унификация и стандартизация будут выполнены в части описания структуры изделия, в части определения структуры «жизненного цикла», в части стандартизации определения Workflow.
Обязательным должен стать принцип «Collaborative product commerce» («CPC»), что можно перевести как «использование Internet-среды для разработки, выпуска и реализации продукции при условии сохранения конкурентоспособности».
Владимир Краюшкин - ведущий специалист компании PTC (Москва).
Литература
1. Н. Дубова. . «Открытые системы», 1996, №3
2. Н. Дубова, И. Островская. . «Открытые системы», 1997, №3
3. В. Абакумов. . «Открытые системы», 1996, № 5
4 В. Краюшкин. Система Optegra - управление производственными данными. «Открытые системы», 1997, №1
5. Н. Пирогова. ? «Открытые системы», 1998, №1
6. http://www.cimdata.com/cPDm_Main.htm
7. В. Клишин, В. Климов, М. Пирогова. . «Открытые системы», 1997, №2, стр.42
Кто есть кто на рынке PDM
За последние два года на рынке PDM произошли существенные изменения структурного характера: слияния нескольких компаний, уход с «поле боя», диверсификация, переквалификация.
| Рис.1 Рынок систем PDM (млн. долл.) |
Понятие о CALS–технологии. Жизненный цикл промышленных изделий. Общее представление об интегрированной информационной среде. Product Data Management как система управления данными об изделии. Общее представление об интегрированной информационной среде.
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
1 . Понятие о CALS - технологии .
CALS-технологии
CALS-технологии (англ. Continuous Acquisition and Life cycle Support - непрерывная информационная поддержка поставок и жизненного цикла) - современный подход к проектированию и производству высокотехнологичной и наукоёмкой продукции, заключающийся в использовании компьютерной техники и современных информационных технологий на всех стадиях жизненного цикла изделия. За счет непрерывной информационной поддержки обеспечиваются единообразные способы управления процессами и взаимодействия всех участников этого цикла: заказчиков продукции, поставщиков/производителей продукции, эксплуатационного и ремонтного персонала. Информационная поддержка реализуется в соответствии с требованиями системы международных стандартов, регламентирующих правила указанного взаимодействия преимущественно посредством электронного обмена данными.
ИПИ (информационная поддержка процессов жизненного цикла изделий) - русскоязычный аналог понятия CALS.
Применение CALS-технологий позволяет существенно сократить объёмы проектных работ, так как описания многих составных частей оборудования, машин и систем, проектировавшихся ранее, хранятся в унифицированных форматах данных сетевых серверов, доступных любому пользователю технологий CALS. Существенно облегчается решение проблем ремонтопригодности, интеграции продукции в различного рода системы и среды, адаптации к меняющимся условиям эксплуатации, специализации проектных организаций и т. п. Предполагается, что успех на рынке сложной технической продукции будет немыслим вне технологий CALS.
Развитие CALS-технологий должно привести к появлению так называемых виртуальных производств, в которых процесс создания спецификаций с информацией для программно управляемого технологического оборудования, достаточной для изготовления изделия, может быть распределён во времени и пространстве между многими организационно-автономными проектными студиями. Среди несомненных достижений CALS-технологий следует отметить лёгкость распространения передовых проектных решений, возможность многократного воспроизведения частей проекта в новых разработках и др.
Построение открытых распределённых автоматизированных систем для проектирования и управления в промышленности составляет основу современных CALS-технологий. Главная проблема их построения - обеспечение единообразного описания и интерпретации данных, независимо от места и времени их получения в общей системе, имеющей масштабы вплоть до глобальных. Структура проектной, технологической и эксплуатационной документации, языки её представления должны быть стандартизированными. Тогда становится реальной успешная работа над общим проектом разных коллективов, разделённых во времени и пространстве и использующих разные CAD/CAM/CAE-системы. Одна и та же конструкторская документация может быть использована многократно в разных проектах, а одна и та же технологическая документация - адаптирована к разным производственным условиям, что позволяет существенно сократить и удешевить общий цикл проектирования и производства. Кроме того, упрощается эксплуатация систем.
Для обеспечения информационной интеграции CALS использует стандарты IGES и STEP в качестве форматов данных. В CALS входят также стандарты электронного обмена данными, электронной технической документации и руководства для усовершенствования процессов. В последние годы работа по созданию национальных CALS-стандартов проводится в России под эгидой ФСТЭК РФ. С этой целью создан Технический Комитет ТК431 «CALS-технологии», силами которого разработан ряд стандартов серии ГОСТ Р ИСО 10303, являющихся аутентичными переводами соответствующих международных стандартов (STEP).
В ряде источников данную аббревиатуру представляют, как Computer Aided Acquisition and Logistic Support. В 1985 году Министерство обороны США объявило планы создания глобальной автоматизированной системы электронного описания всех этапов проектирования, производства и эксплуатации продуктов военного назначения. За прошедшие годы CALS-технология получила широкое развитие в оборонной промышленности и военно-технической инфраструктуре Министерства обороны США. По имеющимся данным это позволило ускорить выполнение НИОКР на 30-40%, уменьшить затраты на закупку военной продукции на 30%, сократить сроки закупки ЗИП на 22%, а также в 9 раз сократить время на корректировку проектов.
Жизненный цикл промышленных изделий
Современные предприятия не смогут выжить во всемирной конкуренции, если не будут выпускать новые продукты лучшего качества, более низкой стоимости и за меньшее время. Поэтому они стремятся использовать огромные возможности памяти компьютеров, их высокое быстродействие и возможности удобного графического интерфейса для того, чтобы автоматизировать и связать друг с другом задачи проектирования и производства, которые раньше были весьма утомительными и не связанными друг с другом. Таким образом, сокращается время и стоимость разработки и выпуска продукции. Для этой цели используются технологии автоматизированного проектирования (computer-aided design - CAD), автоматизированного производства (computer-aided manufacturing - CAM), автоматизированного конструирования (computer-aided engineering - CAE). Чтобы понять значение систем CAD/САМ/САЕ, мы должны рассмотреть различные задачи и операции, которые приходится решать и выполнять в процессе разработки и производства продукта. Все эти задачи, вместе взятые, называются жизненным циклом продукта. Пример жизненного цикла приведен на рисунке 1.
Рисунок 1. Жизненный цикл продукта
Прямоугольники, нарисованные сплошными линиями, представляют два главных процесса, составляющих жизненный цикл продукта: процесс разработки и процесс производства. Процесс разработки начинается с запросов потребителей, которые обслуживаются отделом маркетинга, и заканчивается полным описанием продукта, обычно выполняемым в виде рисунка. Процесс производства начинается с технических требований и заканчивается поставкой готовых изделий.
Операции, относящиеся к процессу разработки, можно разделить на аналитические и синтетические. Как следует из рисунка 1, первичные операции разработки, такие как определение необходимости разработки, формулирование технических требований, анализ осуществимости и сбор важной информации, а также концептуализация разработки, относятся к подпроцессу синтеза. Результатом подпроцесса синтеза является концептуальный проект предполагаемого продукта в форме эскиза или топологического чертежа, отражающего связи различных компонентов продукта. В этой части цикла делаются основные финансовые вложения, необходимые для реализации идеи продукта, а также определяется его функциональность. Большая часть информации, порождаемой и обрабатываемой в рамках подпроцесса синтеза, является качественной, а следовательно, неудобной для компьютерной обработки.
Готовый концептуальный проект анализируется и оптимизируется - это уже подпроцесс анализа. Прежде всего вырабатывается аналитическая модель, поскольку анализируется именно модель, а не сам проект. Несмотря на быстрый рост количества и качества компьютеров, используемых в конструировании, в обозримом будущем отказаться от использования абстракции аналитической модели мы не сможем. Аналитическая модель получается, если из проекта удалить маловажные детали, редуцировать размерности и учесть имеющуюся симметрию. Редукция размерностей, например, подразумевает замена тонкого листа из какого-либо материала на эквивалентную плоскость с атрибутом толщины и т. п. Симметричность геометрии тела и нагрузки, приложенной к нему, позволяет рассматривать в модели лишь часть этого тела. Типичные примеры анализа: анализ напряжений, позволяющий проверить прочность конструкции, контроль столкновений, позволяющий обнаружить возможность столкновений движущихся частей, составляющих механизм, а также кинематический анализ, показывающий, что проектируемое устройство будет совершать ожидаемые движения. Качество результатов, которые могут получены в результате анализа, непосредственно связано с качеством выбранной аналитической модели, которым оно ограничивается.
После завершения проектирования и выбора оптимальных параметров начинается этап оценки проекта. Для этой цели могут изготавливаться прототипы. В конструировании прототипов все большую популярность приобретает новая технология, называемая быстрое прототипирование. Эта технология позволяет конструировать прототип снизу вверх, то есть непосредственно из проекта, поскольку фактически требует только лишь данных о поперечном сечении конструкции. Если оценка проекта на основании прототипа показывает, что проект не удовлетворяет требованиям, описанный выше проект разработки повторяется снова.
Если же оценка проекта оказывается удовлетворительной, начинается подготовка проектной документации. К ней относятся: чертежи, отчеты и списки материалов. Чертежи обычно копируются, а копии передаются на производство.
Как видно из рисунка 1, процесс производства начинается с планирования, которое выполняется на основании полученных на этапе проектирования чертежей, а заканчивается готовым продуктом. Технологическая подготовка производства - это операция, устанавливающая список технологических процессов по изготовлению продукта задающая их параметры. Одновременно выбирается оборудование, на котором будут производиться технологические операции, такие как получение детали нужной формы из заготовки. В результате подготовки производства составляется план выпуска, списки материалов и программы для оборудования. На этом же этапе обрабатываются прочие специфические требования, в частности рассматриваются конструкции зажимов и креплений. Подготовка занимает в процессе производства примерно такое же место, как подпроцесс синтеза в проектировании, требуя значительного человеческого опыта и принятия качественных решений. Такая характеристика подразумевает сложность компьютеризации данного этапа. После завершения технологической подготовки начинается выпуск готового продукта и его проверка на соответствие требованиям. Детали, успешно проходящие контроль качества, собираются вместе, проходят тестирование функциональности, упаковываются, маркируются и отгружаются заказчикам.
2 . Системы управления данными на предприятии (PDM/PLM ).
Системы PLM
Product Lifecycle Management (PLM) - технология управления жизненным циклом изделий. Это решение, которое обеспечивает управление данными и информацией об изделии, а так же всех связанных с изделием процессах на всем жизненном цикле от проектирования и производства до завершения эксплуатации. Информация об объекте, содержащаяся в PLM-cистеме, является цифровым макетом этого объекта.
PLM - это современная бизнес-стратегия, применяемая ведущими производственными предприятиями для сокращения времени вывода на рынок новых продуктов за счет использования передовых средств разработки изделий (CAD/CAE) и подготовки производства (CAM/CAPP/MPM), уменьшения стоимости разработки за счет повторного использования инженерных данных и организации совместной работы распределенных коллективов (PDM).
PLM объединяет в комплексную систему передовые подходы и опорные технологии:
Управление данными об изделии;
Организовать совместный доступ к данным, обеспечивая их постоянную актуальность и целостность;
Контролировать права доступа к данным;
Вносить необходимые изменения во все версии изделия;
Модифицировать спецификацию материалов, конфигурировать варианты изделия;
Коллективные разработки;
Визуализация;
Цифровое производство;
Выбор стратегических поставщиков;
Проверка и управление требованиями;
Управление технологическими процессами;
Управление проектами;
Управление качеством и надежностью;
Интеграция с большинством использующимися ECAD/CAD, корпоративными системами.
Одним из преимуществ решения состоит в его масштабируемости, что позволяет внедрять решение поэтапно, начав с локальной задачи, к примеру, один из возможных вариантов с создания электронного архива, и впоследствии наращивая функциональные модули в зависимости от задач предприятия.
Повышая гибкость и оперативность при реагировании на изменяющиеся вызовы рынка и конкурентной среды, PLM помогает компаниям:
Производить инновационные продукты и услуги;
Сокращать издержки, повышать качество и сокращать сроки выведения продукции на рынок, обеспечивая при этом запланированную прибыль на инвестиции;
Формировать всестороннее взаимодействие с потребителями, поставщиками и бизнес-партнерами в режиме коллективных разработок и постоянного совершенствования.
Сфера применения PLM-решений быстро расширяется, охватывая все больше областей, в которых обмен и целенаправленное использование интеллектуальных активов, связанных с изделием, обеспечивают существенное увеличение прибыльности предприятий.
Системы PDM
Product Data Management (PDM) - система управления данными об изделии. Система PDM является неотъемлемой частью PLM-системы.
Задачи системы PDM: управление хранением данных и документами, управление потоками работ и процессами, управление структурой продукта, автоматизация генерации выборок и отчетов, механизмы авторизации.
Технология PDM реализуется программными решениями, позволяющими сохранять данные об изделии в базах данных. К данным об изделии, прежде всего, относят инженерные данные, такие как CAD-модели и чертежи, цифровые макеты, документированные расчеты, спецификации материалов и т. п.
В PDM-системах обобщены такие технологии, как:
Управление инженерными данными (engineering data management - EDM) ;
Управление документами;
Управление информацией об изделии (product information management - PIM) ;
Управление техническими данными (technical data management - TDM) ;
Управление технической информацией (technical information management - TIM) ;
Управление изображениями и манипулирование информацией, всесторонне определяющей конкретное изделие.
Базовые функциональные возможности PDM-систем охватывают следующие основные направления:
Управление хранением данных и документами;
Управление потоками работ и процессами;
Управление структурой продукта;
Автоматизация генерации выборок и отчетов;
С помощью PDM-систем осуществляется отслеживание больших массивов данных и инженерно-технической информации, необходимых на этапах проектирования, производства или строительства, а также поддержка эксплуатации, сопровождения и утилизации технических изделий. Такие данные, относящиеся к одному изделию и организованные PDM-системой, называются цифровым макетом. PDM-системы интегрируют информацию любых форматов и типов, предоставляя её пользователям уже в структурированном виде (при этом структуризация привязана к особенностям современного промышленного производства). PDM-системы работают не только с текстовыми документами, но и с геометрическими моделями и данными, необходимыми для функционирования автоматических линий, станков с ЧПУ и др., причём доступ к таким данным осуществляется непосредственно из PDM-системы.
С помощью PDM-систем можно создавать отчеты о конфигурации выпускаемых систем, маршрутах прохождения изделий, частях или деталях, а также составлять списки материалов. Все эти документы при необходимости могут отображаться на экране монитора производственной или конструкторской системы из одной и той же БД. Одной из целей PDM-систем и является обеспечение возможности групповой работы над проектом, то есть, просмотра в реальном времени и совместного использования фрагментов общих информационных ресурсов предприятия.
Общее представление об интегрированной информационной среде
управление данные интегрированная информационная среда
Технологии CAD, САМ и САЕ заключаются в автоматизации и повышении эффективности конкретных стадий жизненного цикла продукта. Развиваясь независимо, эти системы еще не до конца реализовали потенциал интеграции проектирования и производства. Для решения этой проблемы была предложена новая технология, получившая название компьютеризованного интегрированного производства (computer-integrated manufacturing - CIM). CIM пытается соединить «островки автоматизации» вместе и превратить их в бесперебойно и эффективно работающую систему. CIM подразумевает использование компьютерной базы данных для более эффективного управления всем предприятием, в частности бухгалтерией, планированием, доставкой и другими задачами, а не только проектированием и производством, которые охватывались системами CAD, САМ и САЕ. CIM часто называют философией бизнеса, а не компьютерной системой.
Сценарий интеграции проектирования и производства посредством общей базы данных
Приведенный ниже сценарий демонстрирует использование систем CAD/CAM/ САЕ в рамках всего жизненного цикла продукта для достижения следующих целей: повышения качества (Q), снижения стоимости (С) и ускорения отгрузки (D). Этот сценарий может показаться несколько упрощенным на фоне современных передовых компьютерных технологий, однако он иллюстрирует направление развития техники. Рассмотрим фазы разработки и производства шкафа для аудиосистемы. Жизненный цикл этого продукта будет похожим на жизненный цикл механической системы или здания, а значит, наш сценарий будет применим и к таким продуктам.
Предположим, что в технических требованиях для разработчика указано, что шкаф должен иметь четыре полки: одну для проигрывателя компакт-дисков, одну для проигрывателя аудиокассет, одну для радиоприемника и одну для хранения ком- пакт-дисков. Вероятно, разработчик сделает множество набросков конструкции, прежде чем придет к какому-либо варианту. На данном этапе он может пользоваться автоматизированной системой разработки рабочих чертежей (если задача решается в двух измерениях) или системой геометрического моделирования (в случае трех измерений). Концептуальный проект может быть отправлен в отдел маркетинга по электронной почте для получения отзыва. Взаимодействие разработчика с отделом маркетинга может происходить и в реальном времени через объединенные в сеть компьютеры. При наличии подходящего оборудования подобное взаимодействие может быть удобным и продуктивным. Информация о готовом концептуальном проекте сохраняется в базе данных. Туда попадают сведения о конфигурации мебели (в нашем случае - вертикальное хранение компонентов аудиосистемы друг над другом), количестве полок, распределении полок по компонентам и тому подобные данные. Другими словами, все особенности проекта, упорядочиваются и помешаются в базу данных с возможностью считывания и изменения в любой последующий момент.
Следующий шаг - определение размеров шкафа. Его габариты должны быть выбраны таким образом, чтобы на каждую полку можно было поставить одну из множества имеющихся на рынке моделей аудиотехники соответствующего класса. Значит, нужно получить сведения об их размерах. Эти сведения можно взять в каталоге или в базе данных производителей или поставщиков. Доступ к базе данных осуществляется аналогично доступу к книгам и их содержимому при подключении к электронной библиотеке. Разработчик может даже скопировать сведения в свою собственную базу данных, если он планирует часто пользоваться ими. Накопление сведений о проекте подобно накоплению форм файлов при работе с текстовыми процессорами. Форма конструкции должна изменяться в соответствии с полученными сведениями.
Затем разработчик должен выбрать материал для шкафа. Он может взять натуральный дуб, сосну, ДСП, сталь или что-нибудь еще. В нашем случае выбор осуществляется интуитивно или исходя из имеющегося у разработчика опыта. Однако в случае продуктов, рассчитанных на работу в жестких условиях, в частности механических устройств, разработчик обязательно учитывает свойства материалов. На этом этапе также полезна база данных, потому что в ней могут быть сохранены свойства множества материалов. Можно воспользоваться даже экспертной системой, которая выберет материал по свойствам, хранящимся в базе данных. Информация о выбранном материале также помещается в базу.
Следующий шаг - определение толщины полок, дверец и боковых стенок. В простейшем случае, который мы рассматриваем, толщина может определяться главным образом эстетическими соображениями. Однако она должна быть по крайней мере достаточной для того, чтобы избежать прогиба под воздействием установленной в шкаф техники. В механических устройствах высокой точности и структурах, рассчитанных на большие нагрузки, такие параметры, как толщина, должны определяться точным расчетом, чтобы избежать деформации. Для расчета деформации структур широко используется метод конечных элементов. Как уже было объяснено, метод конечных элементов применяется к аналитической модели конструкции. В нашем случае аналитическая модель состоит из каркасных сеток, на которые разбивается шкаф, рассматриваемый в приближении листов. Переход к приближению листов может быть выполнен автоматически при помощи алгоритма преобразования к средним осям (medial axis transformation - MAT). Элементы оболочки приближения листов также могут генерироваться автоматически. Параметры нагрузки, которые в нашем случае есть просто веса соответствующих устройств, считываются из базы данных точно так же, как и сведения о размерах. Определяя зависимость прогиба полок от их толщины, разработчик может выбрать подходящее значение этого параметра и сохранить его в базе данных. Этот процесс может быть автоматизирован путем интеграции метода конечных элементов с процедурой оптимизации. Аналогичным образом можно определить толщину боковых стенок и дверец, однако сделать это можно и просто из эстетических соображений.
Затем разработчик выбирает метод сборки полок и боковых стенок. В идеале метод также может быть определен из расчета прочности структуры в целом или при помощи экспертной системы, имеющей сведения о методах сборки.
После завершения этапов концептуализации проекта, его анализа и оптимизации разработчик переходит к работе над проектной документацией, описывающей шкаф с точностью до мельчайших подробностей. Чертежи отдельных деталей (полок, дверец и боковых стенок) изготавливаются в системе разработки рабочих чертежей. На этом этапе разработчик может добавить некоторые эстетические детали, например декоративные элементы на дверцах и боковых стенках. Детальные чертежи помещаются в базу данных для использования в процессе производства.
Изготовление шкафа осуществляется в следующем порядке. Форма каждой детали наносится на необработанный материал (в нашем случае дерево) и вырезается пилой. Количество отходов можно снизить, располагая детали на кусках дерева оптимально. Разработчик может испытывать разные варианты размещения на экране компьютера до тех пор, пока не будет найдена конфигурация с минимальным количеством отходов. Компьютерная программа может помочь в этой работе, рассчитывая количество отходов для каждой конфигурации. Программа более высокого уровня может самостоятельно определить наиболее экономичное размещение деталей на заготовке. В любом случае конечная конфигурация сохраняется в компьютере и используется для расчета траектории движения пилы станка с числовым программным управлением. Более того, программные средства позволяют разработать зажимы и крепления для процедуры выпиливания, а также запрограммировать системы передачи материала. Эти системы могут быть как простыми конвейерами, так и сложными роботами, передающими необработанный материал на распилку и забирающими готовые детали.
Подготовленные детали должны быть собраны вместе. Процесс сборки также может выполняться роботами, которые программируются автоматически на основании описания конечного продукта и его деталей, хранящегося в базе данных. Одновременно проектируются зажимы и крепления для автоматизированной сборки. Наконец, робот может быть запрограммирован на покраску шкафа после сборки. В настоящее время зажимы и крепления для сборки проектируются или выбираются планировщиком процессов, а программирование роботов осуществляется в интерактивном режиме путем перемещения рабочего органа робота вручную.
Общий вид получившегося сценария показан на рис. 2, из которого видно, каким образом база данных позволяет интегрировать системы CAD, САЕ и САМ, что и является конечной целью CIM.
Рисунок 2. Интеграция CAD, CAM, и CAE через базу данных.
Список литературы
1. Ли К. Основы САПР (CAD, CAM, CAE) / К. Ли - СПб. : Питер, 2004. - 560 с. ил.
2. Норенков И. П. Основы автоматизированного проектирования: Учеб. для вузов / И. П. Норенков - 2-е изд., перераб. и доп. - М. : Изд-во МГТУ им. Н. Э. Баумана, 2002. - 336 с.
3.www.irisoft.ru/pdmplm_resenia.html
Размещено на Allbest.ru
...Подобные документы
Определение программы управления корпоративными данными, ее цели и предпосылки внедрения. Обеспечение качества данных. Использование аналитических инструментов на базе технологий Big Data и Smart Data. Фреймворк управления корпоративными данными.
курсовая работа , добавлен 24.08.2017
Анализ современного состояния систем автоматизации управления данными; учет инфраструктуры информационной системы и требования к ресурсам организации. Разработка системы управления данными на базе SharePoint-сайта, программная реализация и внедрение.
диссертация , добавлен 10.11.2011
Разработка информационной системы управления, ориентированной на учет закупленного товара, работу с историческими данными компании и анализ данных для принятия стратегически верных решений. Хранилище данных в 3NF Билла Инмона. Компоненты Data Vault.
дипломная работа , добавлен 22.09.2016
Назначение и цели создания информационной системы. Характеристика объекта автоматизации. Реализация информационной системы "Medic", серверной части приложения. Требования к оперативному запоминающему устройству клиента. Выходные данные программы.
дипломная работа , добавлен 29.06.2011
Необходимость внедрения интегрированной информационной системы с целью повышения эффективности управления процессами. Анализ технологического процесса установки каталитического крекинга КК-1. Разработка концепции построения информационной системы.
дипломная работа , добавлен 09.10.2013
Технология интегрированного информационного пространства и управления данными; программное обеспечение CALS. Этапы жизненного цикла изделий и промышленные автоматизированные системы. Интерактивные электронно-технические руководства, стандарты ISO/IEC.
реферат , добавлен 19.02.2011
Комплексный анализ структуры информационной системы управления персоналом на предприятии. Моделирование информационной системы и расчет задержек запроса менеджера из филиала в области к центральному серверу. Модель оптимизации информационной системы.
курсовая работа , добавлен 18.09.2014
Понятие и структура банка данных. Основные структурные элементы базы данных. Система управления базами данных. Преимущества централизации управления данными. Понятие информационного объекта. Современные технологии, используемые в работе с данными.
курсовая работа , добавлен 02.07.2011
Разработка информационной системы административного управления. Выбор языка и среды программирования. Структура взаимодействия информации. Требования к программно-аппаратному окружению. Создание программы в Delphi и связывание ее с базой данных.
курсовая работа , добавлен 08.10.2015
Рассмотрение основ использования информационных технологий в гостиничном бизнесе. Выбор системы управления базами данных. Описание информационной технологии. Выполнение программной реализации в среде объектно-ориентированного программирования Delphi 7.
Системы автоматизированного проектирования относятся к числу наиболее сложных и наукоемких автоматизированных систем. Наряду с выполнением собственно проектных процедур необходимо автоматизировать также управление проектированием, поскольку сам процесс проектирования становится все более сложным и зачастую приобретает распределенный характер. На крупных и средних предприятиях заметна тенденция к интеграции САПР с АСУП и системами документооборота. Для управления столь сложными интегрированными системами в их составе имеется специальное ПО — системная среда САПР или АС, называемая в настоящее время системой управления проектными данными или системой PDM (Product Data management). Системы более общего характера, связанные с управлением данными на всех этапах жизненного цикла изделий и интеграцией различных промышленных автоматизированных систем, получили название систем управления жизненным циклом изделий или систем информационной поддержки изделий PLM (Product Lifecycle Management).
История систем управления проектными данными непосредственно связана с развитием систем автоматизированного проектирования. Появление системных сред в САПР ознаменовало переход от использования отдельных не связанных друг с другом программ, решающих частные проектные задачи, к применению интегрированной совокупности таких программ.
Интегрирующим компонентом в 70-е г.г. стала единая БД САПР. Однако попытки использовать имевшиеся в то время СУБД не приводили к удовлетворительным результатам в силу разнообразия типов проектных данных, распределенного и параллельного характера процессов проектирования, с одной стороны, и недостаточной развитости баз данных, с другой стороны.
Специализированные СУБД, ориентированные на САПР, были созданы в 80-е годы. Однако они не учитывали или в недостаточной степени удовлетворяли требованиям обеспечения целостности данных, управления потоками проектных работ, многоаспектного доступа пользователей к данным.
И лишь на рубеже 80-90 г.г. появились системы управления проектными данными, названные в то время Framework или системными средами, сначала в САПР электронной промышленности, а позднее и в САПР машиностроения, где они и получили наименование PDM.
На протяжении 90-х годов роль системных сред неуклонно повышалась. Во-первых, из-за роста сложности проектируемых объектов и необходимости сокращать сроки проектирования. Во-вторых, из-за необходимости интеграции систем проектирования с системами управления предприятием и технологическими процессами. Благодаря развитию Internet, Web- и CALS-технологий такая интеграция стала возможной в глобальном масштабе.
Современные системы управления проектными данными называют PDM. Они предназначены для информационного обеспечения проектирования и выполняют следующие основные функции:
- хранение проектных данных и доступ к ним, в том числе ведение распределенных архивов документов, их поиск, редактирование, маршрутизация, создание спецификаций;
- поиск, структурирование и визуализация данных;
- управление конфигурацией изделия, т.е. ведение версий проекта, управление внесением изменений;
- управление проектированием (проектами), обеспечение совместной работы разработчиков над проектом;
- защита информации;
- интеграция данных (поддержка типовых форматов, конвертирование данных).
Основной компонент систем PDM — банк данных (БнД). Он состоит из системы управления базами данных и баз данных (БД). Межпрограммный интерфейс в значительной мере реализуется через информационный обмен с помощью банка данных. PDM отличает легкость доступа к иерархически организованным данным, обслуживание запросов, выдача ответов не только в текстовой, но и в графической форме, привязанной к конструкции изделия. Поскольку взаимодействие внутри группы проектировщиков в основном осуществляется через обмен данными, то в системе PDM часто совмещают функции управления данными и управления параллельным проектированием.
К важнейшим функциям PDM относятся управление проектами и управление конфигураций изделий.
Рассмотрим остальные функции PDM.
В информационных моделях приложений фигурируют сущности (типы данных) и связи между ними. Установление сущностей, их атрибутов, связей и атрибутов связей означает структурирование проектных данных. Структура изделий обычно может быть представлена иерархически, в виде дерева. Иерархическая форма удобна при внесении и отслеживании изменений в модели, например, при добавлении и удалении сущностей, изменениях их атрибутов, введении новых связей. Поэтому одной из первоочередных функций PDM является поддержка интерактивной работы пользователя при создании моделей изделий (процессов), структурирование описаний проектируемых объектов, предъявление пользователю этой иерархической структуры вместе с возможностями навигации по дереву и получению нужной информации по каждой указанной пользователем структурной компоненте.
Например, в системе PDM STEP Suite элементы дерева, представляющего структуру изделия, могут соответствовать сборочным узлам, агрегатам, блокам, отдельным деталям. Навигация по дереву позволяет просматривать относящиеся к структурным единицам документы, геометрические модели, чертежи и другие атрибуты.
В системе PDM, разработанной в свое время фирмой Cadence для своей САПР, была предусмотрена иерархическая организация проектных данных, описывающих проектируемые СБИС (сверхбольшие интегральные схемы), с выделением уровней библиотек, категорий, ячеек, видов. Ячейка — базовый объект, который может иметь несколько различных представлений (видов). Ячейки объединяются в родственные группы — категории, а категории — в библиотеки. Разработчик с помощью системной среды имел доступ к проектным данным, мог создавать свои библиотеки, ячейки, виды.
Интерфейс с пользователем поддерживается визуализацией данных проекта одновременно в нескольких окнах. Для визуализации данных разных аспектов в PDM имеется ряд браузеров. Типичные изображения структуры изделия, создаваемые браузерами, представляются иерархическим списком или графически в виде дерева изделия или его фрагментов. В других окнах могут быть помещены различные виды, такие как 2D чертеж или 3D изображение; описания моделей; принципиальные схемы; атрибуты объекта (исполнитель, номер версии, дата утверждения и т.п.). Иногда для визуализации и редактирования данных в PDM конкретной фирмы привлекаются браузеры и редакторы других изготовителей.
Для примера на рис. 1 показан небольшой фрагмент дерева изделия. Обычно на экране дисплея рядом с названием компонента структуры высвечивается также присвоенный ему код. Выбор любого компонента (узла дерева) позволяет, во-первых, получить в появляющихся окнах требуемую информацию о компоненте. во-вторых, для компонента, являющегося сборкой, раскрыть следующий по иерархии фрагмент, в котором данный компонент будет представлен уже корневым узлом.
Рис. 1. Фрагмент дерева изделия
Целостность данных поддерживается в процессе управления конфигурацией проекта, а также тем, что нельзя одновременно изменять один и тот же объект разным разработчикам, каждый из них должен работать со своей рабочей версией. Другими словами, необходимо обеспечение синхронизации изменения данных, разделяемых многими пользователями.
Для этого выполняется авторизация пользователей и разрабатываются средства ведения многих версий проекта. Во-первых, пользователи подразделяются на классы (администрация системы, руководство проектом и частями проекта, группы исполнителей-проектировщиков) и для каждого класса вводят определенные ограничения, связанные с доступом к разделяемым данным; во-вторых, доступ регламентируется по типам разделяемых данных. Данным могут присваиваться различные значения статуса, например, "правильно", "необходимо перевычисление", "утверждено в качестве окончательного решения" и т.п. Собственно синхронизация выполняется с помощью механизмов типа рандеву или семафоров, рассматриваемых в пособиях по параллельным вычислениям.
Например, каждому пользователю в зависимости от его роли назначается уровень прав доступа. На низшем уровне пользователь может только просматривать данные. На высшем уровне, присваиваемом старшему администратору, допускаются любые модификации данных любого проекта и архивов. В функции лица, являющегося системным администратором, входят упорядочение данных с их распределением по дискам, контроль за правами доступа пользователей, связь с внешними системами (управление импортом-экспортом данных) и др.
Типичная схема разделения рабочего пространства между параллельно работающими пользователями показана на рис. 2.
Рис. 2. Информационные связи разработчиков с зонами базы данных
Следующими важными функциями PDM являются управление документами и документооборотом. Проектная документация характеризуется разноплановостью и большими объемами. В процессе проектирования используют чертежи, конструкторские спецификации или BOM, пояснительные записки, ведомости применяемости изделий, различного рода отчеты и др. Кроме того, в интегрированных автоматизированных системах проектирования и управления в документооборот входит большое число документов, связанных с процедурами маркетинга, снабжения, планирования, администрирования и т.п. .
Важно обеспечить автоматический учет влияния и распространения вносимых в проект изменений на другие части проектной документации.
Для подготовки, хранения и сопровождения необходимых документов, в том числе чертежей и схем, в PDM включают специализированные системы управления документами и системы управления документооборотом или адаптируют полнофункциональные системы делопроизводства, разработанные независимо от конкретных PDM.
Следует отметить, что параллельное проектирование (совмещенное проектирование), интеграция автоматизированных систем проектирования и управления на современных предприятиях возможны только в распределенной среде. Распределенные хранение и обработка информации в большинстве случаев осуществляются на базе применения технологий SOAP, CORBA или DCOM, языков Java и XML. Данные проекта при этом находятся в хранилищах данных, т.е. в нескольких базах распределенного банка данных. Находят применение трехзвенные распределенные системы с уровнями сервер баз данных — сервер приложений — клиенты. Принимаются меры по защите информации, типичные для корпоративных информационных систем. Разработаны рекомендации по внедрению операций с электронными цифровыми подписями.
Интеграция данных на ранних этапах развития PDM связывалась только с организацией сквозного проектирования изделий в рамках конкретной САПР. В настоящее время в связи с развитием CALS-технологий основным содержанием проблемы интеграции стало обеспечение интерфейса САПР с другими автоматизированными системами. Проблема решается с помощью поддержки типовых форматов, например, путем конвертирования данных из общепринятых форматов во внутренние представления конкретных САПР.
В CALS-технологиях взаимодействие систем основано на стандартах STEP, поэтому в ряде PDM имеются конверторы из предложенного в STEP языка Express.
Адаптация САПР к условиям конкретных предприятий может быть осуществлена с помощью языков расширения. Язык расширения — язык программирования, позволяющий адаптировать и настраивать системную среду на выполнение новых проектов. Язык расширения должен обеспечивать доступ к различным компонентам системной среды, объединять возможности базового языка программирования и командного языка, включать средства процедурного программирования. Для большинства языков расширения базовыми являются Lisp или C.
Управление инженерными и проектными данными. PDM - системы.
PDM технология - это технология управления всеми данными об изделии и информационными процессами жизненного цикла изделия. Для реализации PDM технологии существуют специализированные программные средства, называемые PDM системами, то есть системами управления данными об изделии.
В отличии от АСУП, которой управляют информацией о всех ресурсах предприятия, PDM системы направлены на управление на предприятии информацией о продукте. Таким образом, система управление производственной информацией то инструментальное средство, которое помогает администраторам, конструкторам, технологам, инженерам и другим специалистам управлять как данными об изделии, так и процессами разработки изделия на современном производственном предприятии либо на группе предприятий-смежников.
Системы PDM обобщают такие широко известные технологии, как управление инженерными данными EDM, управление документами, управление информаций об изделии PIM, управление техническими данными TDM, управление технологической информацией TIM, управление изображениями и все другие системы, которые так или иначе позволяют манипулировать данными и изображениями.
PDM системы интегрируют информацию любых форматов и типов, поступающую от различных источников, предоставляя её пользователям уже в структурированном виде. Структуризация привязана к особенностям конкретного предприятия.
В системах PDM разнообразие проектных данных поддерживается их классификацией и соответствующим выделением групп с характерным множеством атрибутов. Часто структура изделия представляется в виде дерева. Step suite - элементы дерева могут соответствовать отдельным сборочным узлам или изделия. В PDM системах существуют модули CDO - для подготовки, хранения и сопровождения необходимых документов в системах PDM как правило имеются специализированные системы управления документами и документооборотом. Причем некоторые системы делопроизводства либо интегрированы в САПР, либо имеют средства для управления проектной, в том числе чертежно-конструкторской документацией. Для создания систем управления документооборота - Lotus Notes, Lotus Domino.
Возможности управления чертежно-конструкторской документацией, которая подготовлена в системе AutoCAD, Microstation в Docs Open, CADlink (Documentum Search).
Наряду с информацией PDM системы управляют процессом изготовления изделия. Наряду с данными система PDM управляет и проектом, то есть процессом разработки изделия, при этом контролируя информацию об изделии-продукте, о состоянии объекта, о утверждении вносимых изменений, осуществляя авторизацию и другие операции, которые влияют на данные об изделии и режим доступа к ним конкретного пользователя. Управление процессом проектирования включает в себя большое число действий и условий, поддерживающих параллельную работу многих пользователей над общим проектом, то есть необходимо управление потоком работ, которое выполняется на основе моделей вычислительных процессов. Используются спецификации моделей, принятые в CASE системах, workflow
Часто управление крупными проектами, включающее распределение большого числа работ по времени и между исполнителями, выполняются программами, относящимися к специальной группе систем управления проектами. В эту группу входят:
- программы верхнего уровня - Artemis Project, Primavera Project Planner, Open Plan;
- программы среднего уровня - Time Line, Microsoft Project, Spider Project.
- Можно выделить несколько уровней интеграции PDM системы и других компьютерных приложений, используемых на предприятии:
- Наиболее продвинутым уровнем интеграции является использование на предприятии единой модели данных. Это означает, что все компьютерные системы работают с единой, совместно используемой базой данных.
- Следующий уровень интеграции - прямой доступ к БД, то есть все компьютерные системы имеют свои базы данных, но каждая из них имеет возможность читать и писать данные в базе данных другой системы. Этот способ интеграции встречается на практике - iMan обладает способностью читать и писать данные во внешние базы данных, а также синхронизировать свою БД с внешними в режиме реального времени - T-Flex Docs.
- Наиболее распространенным уровнем интеграции является использование для организации взаимодействия систем прикладных программных интерфейсов.
- Самый простой уровень интеграции - использование файлов для обмена данными между системами. При осуществлении передачи данных от одной системы к другой, первая система будет генерировать файл, содержащий передаваемые данные, а вторая система читать этот файл и получать эти данные. В рамках STEP (ISO-10303).
Существует множество ПП, реализующих функции PDM системы. Большинство из них выполнены по схожим принципам:
· В основе хранилища данных лежит какая-либо коммерческая СУБД;
· Поддержка основных стандартных форматов для обмена данными между системами (STEP \ IGES \ CDM \ DXF);
· Использование различных платформ;
· Поддержка графического интерфейса с пользователем;
· Предоставление доступа к PDM системе через интернет.
В настоящее время существует огромное количество ПП, реализующих функции PDM систем, и ещё больше программных средств, претендующих на название PDM-систем. Тем не менее, можно выделить три основные категории производителей:
- 1 группа - фирмы, перешедшие из области САПР - PTC (Pro/Engineer \ Windhill), IBM (CATIA \ ENOVIA), Unigraphics (Unigraphics \ iMan), SDRC (I-DEAS \ Metaphase), Топ-системы (T-Flex CAD \ T-Flex Docs).
- 2 группа - независимые разработчики PDM систем, которые изначально начали свою работы над PDM (их преимущество в том, что системы этих фирм изначально ориентированы на интеграцию с широким спектром прикладных систем, в том числе и на основе международных стандартов) - CADIM \ EDM, Agile Software \ Agile, Лоцесофт \ PartY, НИЦ CALS логиcтика - STEP Suite,
- 3 группа - фирмы, пришедшие в PDM из других предметных областей - SAPE AG - SAPR R3, BAAN.
