CC BY
104Решетневские чтения. 2014
References 3. Kobus Barnard, Brian Funt, "Investigations into
1. Jobson D. J., Rahman Z., Woodell G. A Properties Multi-Scale Retinex.
and Performanceof a Center/Surround Retinex. 4. Rabiner P., Gould B. Theoryand application
2. ZviDevir, Liliya Tridensky, Dynamic Range ofdigitalsignal processing. M. : Mir, 1978. Compression while Improving the Visual Quality of
Color Images. © Лисица А. С., Алексеев И. С., 2014
УДК 658.51; 629.783; 629.7.012; 004.942
УПРАВЛЕНИЕ СТРУКТУРОЙ ИЗДЕЛИЯ В PLM-СИСТЕМАХ
М. В. Лихачев
ОАО «Информационные спутниковые системы» имени академика М. Ф. Решетнева» Российская Федерация, 662972, г. Железногорск Красноярского края, ул. Ленина, 52
E-mail: lihachev@iss-reshetnev.ru
Описана роль подсистемы управления структурой изделия в моделях данных современных систем управления жизненным циклом изделия. Описаны принципы создания и использования структуры изделия.
Ключевые слова: САПР, структура изделия, АСУТП, управление данными об изделии.
PRODUCT STRUCTURE MANAGEMENT IN PLM SYSTEMS
M. V. Lihachev
JSC "Information Satellite Systems" named after academician M. F. Reshetnev" 52, Lenin str., Zheleznogorsk, Krasnoyarsk region, 662972, Russian Federation E-mail: lihachev@iss-reshetnev.ru
The purpose and primary functions of product structures at modern product lifecycle management systems are described. Basic principles of product structure management, creation and utilization are reviewed.
Keywords: CAD, PLM, PDM, product structure, data model.
Структура данных современной PLM-системы. Концепция цифрового изделия. Совокупность всех данных об изделии, документов, описывающих изделие, хранящихся в информационной системе, называется цифровым изделием.
В первом приближении основной информационной структурой цифрового изделия является древовидная структура изделия, или компонентная структура [2]. Данная структура порождается на этапе конструирования изделия. В терминах ЕСКД - это аналог совокупности всех конструкторских спецификаций. Применение электронной структуры изделия (ЭСИ) или компонентной структуры регламентируется ГОСТ 2.053-2006 [1].
При рассмотрении других этапов жизненного цикла целесообразно использовать другие древовидные структуры (структура требований, функциональная, логическая, структура ЭМИ, технологическая, сервисная и т. п.).
Таким образом, информация в рамках цифрового изделия может быть представлена в виде нескольких древовидных структур, соответствующих разным этапам жизненного цикла, элементы которых связаны горизонтальными связями для обеспечения отслежи-ваемости данных и корректного проведения изменений. Рассмотрим принципы построения данных структур.
Компонентная структура изделия. Потребителем информации, содержащейся в компонентной структуре, являются службы предприятия, ответственные за планирование производства, закупку материалов и комплектующих, а также технологическую подготовку производства и собственно производство. Данные задачи решаются в системах класса ERP/MRP и САПР ТП. Задачей PLM-системы является передача информации о структуре изделия в ERP. Как правило, реализуется двусторонний обмен информацией: в ERP-систему передается информация о структуре изделия и составе материалов и покупных изделий, а назад в PLM-систему передается информация о стоимости и себестоимости деталей и узлов и складских запасах [3]. При этом необходимо обеспечить процесс синхронизации библиотек материалов, комплектующих и пр. между несколькими информационными системами. Для решения данной задачи существует класс программных продуктов MDM (Master Data Management) [4].
Другим важным вопросом является место САПР техпроцессов в информационной системе предприятия. Она может входить как в состав PLM-системы, так и в состав ERP. Единого мнения по этому вопросу в настоящее время не существует.
Данные вопросы заслуживают отдельного детального рассмотрения. В рамках данной статьи ограни-
Программные средства и информационные технологии
чимся утверждением, что основным назначением компонентной структуры является передача данных в системы класса ERP.
Компонентная структура и электронный макет изделия (ЭМИ). Большинство современных механических САПР моделируют изделие в виде набора файлов (деталей и сборочных единиц) как раз в виде древовидной структуры. Однако практика работы показывает, что применение этой структуры в качестве компонентной структуры затруднено. Происходит это по следующим причинам [3]:
- не всегда удобно создавать структуру ЭМИ, соответствующую компонентной структуре изделия в силу особенностей разных САПР;
- нередка ситуация, когда разные узлы одного и того же изделия разрабатываются в разных САПР. В таких случаях компонентная структура изделия может выступать агрегатором информации;
- компонентная структура должна обеспечивать доступ к информации, отсутствующей в ЭМИ: материалы, техпроцессы, процессы согласования и пр.;
- структура изделия содержит не только механические компоненты, а также электронные и радиоизделия, элементы программного кода и пр. Поэтому для разных САПР, применяемых в PLM-системе предприятия, разрабатываются адаптеры, позволяющие синхронизировать данные САПР с элементами компонентной структуры;
- этапы жизненного цикла элемента ЭМИ (3Б-модели, являющейся документом) и элемента компонентной структуры отличаются.
Тем не менее структура ЭМИ все-таки мало отличается от компонентной структуры. Поэтому целесообразна разработка интеграции компонентной структуры и ЭМИ. В PLM-системах предыдущего поколения реализована односторонняя интеграция: формирование компонентной структуры на основе структуры ЭМИ по определенным правилам. В современных системах внедряется двусторонняя интеграция, что позволяет формировать структуру ЭМИ на основе компонентной структуры и таким образом получать некоторые данные об изделии на более ранних этапах его жизненного цикла.
Необходимо отметить, что в силу причин коммерческого характера конкретные САПР не всегда предоставляют возможность интеграции с конкретной PDM/PLM-системой, что вынуждает разработчиков информационной системы предприятия разрабатывать собственные интерфейсы передачи данных.
Компонентная структура и управление модификациями изделия. В случае, когда изделие разрабатывается и производится в нескольких модификациях, PLM-система должна поддерживать вариативную компонентную структуру изделия. Как правило, это реализуется с помощью обобщенной компонентной структуры изделия, содержащей все возможные варианты изделия, и матрицы конфигураций, которая накладывается на обобщенную конфигурацию изделия и формирует структуру конечного изделия на основе предпочтений заказчика и набора правил конфигурирования. Данная модель данных наиболее на-
глядно реализована в автомобильной промышленности.
Система управления данными также должна поддерживать процессы внесения изменений в компонентной структуре на этапе серийного производства изделия. Как правило, для этого реализуется функция актуальности по дате или по серийному номеру изделия. Необходимо отметить, что расширение управления вариантами изделия при позаказном производстве на управление производственными процессами представляет исключительно сложную задачу, которая до сих пор не решена в коммерческих PLM-системах.
Компонентная структура при позаказном производстве. Существуют три модели процессов предприятия, практикующего позаказное производство:
- Engineering to Order (ETO) [5] - изделие разрабатывается каждый раз снова;
- Build to Order (BTO) [6] - изделие разрабатывается путем интеграции существующих модулей и разработки новых;
- Configure to Order (CTO) [7] - изделие комплектуется из универсальных модулей.
Для каждого типа изделия оптимален свой процесс, однако существует стремление предприятий к переходу к процессам BTO и CTO как более экономически эффективным. Применение компонентной структуры позволяет быстро оценивать себестоимость изделия и сроки его разработки на предконтрактном этапе разработки изделия. Это дает существенные преимущества в конкуренции за заказы.
Применение компонентной структуры изделия в модели данных PDM-системы является оптимальным способом представления данных о структуре изделия, позволяющим организовать обмен данными с ERP, предконтрактный анализ стоимости изделия, управление конфигурациями изделия.
Библиографические ссылки
1. ГОСТ 2.053-2006. ЕСКД. Электронная структура изделия. Общие положения.
2. BOM for Dummies: BOM and CAD. URL: http://virtualdutchman.com/2010/03/23/bom-for-dummies-bom-and-cad/.
3. Connecting PLM and ERP (1). URL: http://virtualdutchman.com/2008/07/20/connecting-plm-and-erp-1/.
4. URL: http://www.sdi-solution.ru/index.php/produkty/ pochemu-semantic-pochemu-sejchas.
5. Bill of Materials for Dummies - ETO. URL: http://virtualdutchman.com/2010/01/19/bill-of-materials-for-dummies-eto/.
6. Bill of Materials for Dummies - BTO. URL: http://viitualdutchman.com/2010/02/02/bom-for-dummies-bto/.
7. Bill of Materials for Dummies - CTO. URL: http://virtualdutchman.com/2010/02/14/bom-for-dummies-cto/.
References
1. GOST 2.053-2006. Unified system for design documentation. Product electronic structure. General.
2. BOM for Dummies: BOM and CAD. URL: http://virtualdutchman.com/2010/03/23/bom-for-dummies-bom-and-cad/.
Решетневскуе чтения. 2014
3. Connecting PLM and ERP (1). URL: http://virtualdutchman.com/2008/07/20/connecting-plm-and-erp-1/.
4. URL: http://www.sdi-solution.ru/index.php/ produkty/ pochemu-semantic-pochemu-sejchas.
5. Bill of Materials for Dummies - ETO. URL: http://virtualdutchman.com/2010/01/19/bill-of-materials-for-dummies-eto/.
6. Bill of Materials for Dummies - BTO. URL: http://virtualdutchman.com/2010/02/02/bom-for-dummies-bto/.
7. Bill of Materials for Dummies - CTO. URL: http://virtualdutchman.com/2010/02/14/bom-for-dummies-cto/.
© Лихачев М. В., 2014
УДК 004.42
РАСШИРЕНИЕ ВОЗМОЖНОСТЕЙ ИСПОЛЬЗОВАНИЯ СТАНДАРТНОГО КОМПОНЕНТА DATAGRIDVIEW ПРИ РАЗРАБОТКЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
М. В. Моисеев
Сибирский государственный аэрокосмический университет имени академика М. Ф. Решетнева Российская Федерация, 660014, г. Красноярск, просп. им. газ. «Красноярский рабочий», 31
E-mail: maksimka_moiseev@mail.ru
Рассматриваются вопросы добавления новых возможностей при работе со стандартным компонентом DataGridView в среде разработки MS Visual Studio. Представлены алгоритмы, позволяющие реализовать изначально отсутствующие события и свойства компонента DataGridView.
Ключевые слова: DataGridView, компонент, свойство, событие.
EXPANSION OF POSSIBILITIES OF THE STANDARD COMPONENT DATAGRIDVIEW IN SOFTWARE DEVELOPMENT
M. V. Moiseev
Siberian State Aerospace University named after academician M. F. Reshetnev 31, Krasnoyarsky Rabochy Av., Krasnoyarsk, 660014, Russian Federation E-mail: maksimka_moiseev@mail.ru
The questions on adding new features to work with the standard DataGridView component in development environment of MS Visual Studio are studied. The algorithms to implement initially missing events, and properties of the component DataGridView are developed.
Keywords: DataGridView, component, property, event.
Последнее время в большинстве сред программирования особое внимание уделяется совершенствованию языка программирования и улучшению средств командной разработки. Добавление новых или обновление существующих компонентов часто игнорируют. При этом зачастую при разработке сложных приложений используется большое количество визуальных компонентов, и в большинстве случаев стандартных свойств и событий этих компонентов более чем достаточно. Однако нередки случаи, когда набора стандартных свойств компонента не достаточно для реализации поставленных задач.
С данной проблемой столкнулся и автор статьи при разработке своего приложения, содержащего большое количество форм и используемых компонентов [1; 2]. Одним из важных вопросов при написании программы стала реализация возможности запрета на ввод всех букв и знаков препинания, кроме запятой, что требовалось для избежания ошибок при работе
других модулей. Решить указанную проблему с помощью стандартных событий компонентов не представлялось возможным, что и потребовало подойти к ее решению иначе.
Для рассматриваемого примера был взят компонент DataGridView стандартной палитры компонентов MS Visual Studio. На первых порах его возможностей хватает, он позволяет добавлять шесть видов столбцов, предназначенных для разных целей, и имеет множество свойств и событий, позволяющих реализо-вывать большинство стандартных действий. Но со временем и по мере усложнения разрабатываемого проекта требуются события, которых компонент изначально не предоставляет. Например, есть событие, которое вызывается перед редактированием ячеек и после, но нет события, срабатывающего при нажатии клавиши на клавиатуре, что позволяет запретить ввод некоторых символов, находясь в режиме редактирования ячейки.
