Generic-BOM

[김창근]

setAdGroup('220.72.2.46'); var cm_role = "live" var cm_host = "tripod.lycos.com" var cm_taxid = "/memberembedded" var objAdMgr = new AdManager(); objAdMgr.setForcedParam("keyword", "generic+BOM"); if(adChannel != "") { objAdMgr.setForcedParam("google_ad_channel", adChannel); } var strProdSetName = objAdMgr.chooseProductSet(); objAdMgr.renderHeader();

if (objAdMgr.isSlotAvailable("leaderboard")) { objAdMgr.renderSlot("leaderboard") }

objAdMgr.renderFooter();

Product Definition, Generic/precise Bill Of Material
(review of D.H.Brown inc.,"Product vs Process in Design-to-Manufacturing Integration", 1997.)
from dnc's archive release 1: volvo_pdm/libray/Data/Usbomdoc.pdf
since August 30, 1999 last modified September 28, 1999, Released 1

---

1 INTRODUCTION

• Product-centric versus Process-centeric Product Information Management
• Assembly models, product definitions, product structures, and BOM
• Applications to contextualize product representations
• Product representation techniques

2 THE ROLE OF PIM IN MANUFACTURING

2.1 Proudct centric vs. process-centric

Process centric은 업무과정(Business process)를 자체 의미로써 지원하는 Application을 제공하는 반면 Product은 업무과정을 Master data(예 3D CAD Models)와의 상호 Interaction으로 인식한다.

Product-centric은 CAD에서 CAM으로 넘어가는 일련은 제품형상정보 파일의 변경에 중점을 둔다. 아래 그림은 형상정보를 {design, mfg},{level of information sharing & depandancy}(x축), {completeness of product description}(y축) 상에 배열해 놓은 것이다.

제품형상정보 생성 및 변화 순서는 1) conceptual CAD design 2) envelope assembly models 3) envelope model간의 interface와 interface의 형상을 정의하는 assembly-based features 4) detailed component design and assembly modeling 5) 각 part에 대한 feature-level detailing 을 따른다.

Fig 2-1 Conceptual Model of Product Information Domains and the Product-centric Core Geometry Path

Low
| V	Conceptual CAD		planning	scheduling
	Envelope Assembly		costing	inventory control
	Interface Definition, Assembly based Features		kit preparation	assembly sequence
	Detailed Component, Assembly Modeling
	Feature-Level Detailing	NC & CAM Modeling	Shop Floor Fabrication	Physical Assembly
High	Design->				Mfg.
	Moderate->				High

2.2 Process-centric PIM과 특징형상 관리(Feature Management)의 가능성

현재 Product-centric PIM 업체는 여러 설계 과정에서 쓰이는 CAD File을 통합함으로써 Master Solid Model에 적용되는 여러 Interaction을 원활히 통합시키고 있다 (예: 한 Assembly Part에 대한 Digital Mockup, CAE를 위한 형상 CAD File, Rough CAD File을 일반 CAD FIle과 연관관계를 가지고 관리).

업체의 미래 강조분야는 CAD Model을 보다 상세한 수준에서 각부품을 이루는 형상의 특징을 서술하는 특징형상(Feature)과 연결시키는 것이다. 특징형상은 Tool setup과 operation 그리고 조립순서와 방법을 결정할 수 있으므로 설계와 생산간의 통합에 중요한 역할을 한다. 그림 2.1 에서 "Feature-Level Detailing" 과 "NC & CAM Modeling"을 비롯한 Mfg. 쪽 과정이 통합되게 된다.

Feature를 이용한 기능으로써는 "feature-level change management, feature reuse, feature libraries, CAD/CAM interfaces with feature databases" 이며 이로 인한 효과는 "engineering know-how의 이용, change management 개선, 설계와 생산간의 정확한 의사전달, 모호성이 제거된 제품표현(unambiguous product representation)" 이다. 미래의 PIM 시스템은 shop floor에 보다 완벽한 제품형상정보와 설계 intelligence(Feature based representation) 를 제공하므로써 MRP가 전통적으로 Controll했던 Process를 관리할것으로 예상된다.

현재 EDS/UG IMAN이 해당 feature management에 대한 가장 가까운 가능성을 제공한다. 하지만 feature based engineering change 기능이나 document management 기능은 아직 어는 CAD 업체도 제공하지 못한다.

2.3 PIM의 주요 추구 기능

Feature management는 장기적으로 추구하는 기능인 방면 PIM의 당면한 추구 기능은 설계에서 생산으로 진행되는 동안 제품표현의 변화를 관리하는 것이다. 특히 설계에서 생산으로 전달되는 정보는

• Geometry domain (geometry-centered product modeling domain)
• product definition/BOM domain (manufacturing operations domain)

의 두가지 종류의 제품표현으로 전달된다. 특히 Product definition/BOM 은 일정계획, 구매등 CAD 와는 다른 application을 지원한다.

2.4 Product-centric PIM의 오류

현재의 product 중심의 PIM은 geometry domain의 정보가 쉽게 operational 한 domain으로 interface 될것으로 생각하나 제품표현 방식을 바꾸어야 하므로 쉽지 않은 Interface이다. Product-centeric PIM이 설계와 생산의 geometry 와 operation domain의 Interface를 쉽게 생각하는 데는 아래와 같은 이유가 있다.

• feature based solid model의 제품표현(product represention)의 전부이다.
• Rule based integration이 product definition 과 precise BOM의 방법적 완성 요구를 대체한다.
• 기존의 문서중심의 설계변경을 그대로 자동화하고 Digital 화 할 경우
• PIM 업체의 product definition 과정에 대한 부족한 이해

2.5 The Product Definition/Bill Of Material 해법

Geometry 와 Mfg Process 와의 Integration(CAD와 ERP Integration)은 Product Definition 과 BOM 관리라는 Process들을 이용하여 구현할 수 있다. 이 Process 를 지원하는 Application들은 다음과 같은 5가지 종류의 Product Representation을 지원해야 한다.

• Engineering Solutions
• Requirements and Functional Descriptions
• Product Definitions
• Generic Bills of Materials
• Precise bill of materials

Process-centric 접근법의 요점은 geometry에 관계된 application 도 product definition이나 BOM과 같은 하나의 Business process로 보는 것이다.

최근까지 Product-centric PIM 업체는 Product Definition과 BOM을 완전히 지원하지 못하고 있다. 그러나 설계변경을 지원하는 Process 가 점차로 지원되어 설계와 생산을 통합하고 있다. 하지만

• precise BOM 과 product definition의 구별 부족
• 너무 높은 수준의 설계변경 Application
• BOM을 generic structure와 relationship에 대한 단순한 query로 치부

하는 문제점을 가지고 있다. 이는 Design/Manufacturing을 어렵게 하고 있다.

3. Product Representation의 5가지 범주

3.1 The Precise Bills Of Materials

Precise BOM은 아래 와 같은 Indented 된 Part List 이다. Precise의 의미는 제품 Instance에 실제적용된 BOM 이라는 의미를 가진다. Precise BOM은 뒤에 설명될 Generic BOM에 Effectivity가 적용된 결과로 생성되며, 제품의 사양에 대한 모든 의사결정이 내려졌음을 뜻한다. HEADER의 Product Family는 같은 Architecture 나 Platform을 사용하는 제품집합, Product Name은 같은 기능을 하는 제품의 집합, 그리고 Build Series는 한개 혹은 다수의 고객에게 인도가능한 제품을 뜻한다.

Precise BOM을 관리하는 Application에서 중요한 개념은 첫째 Precise BOM은 현재 진행중인 생산의 기초 정보를 제공한다. 둘째, 생산 의사결정의 변경에 대한 기준정보를 제시한다. 즉 Precise BOM의 변경은 비용을 요구하는 설계변경을 생성하며 Release 된 후의 설계변경은 많은 비용이 든다.

HEADER
Product Family : Ship Engine
Product Name : MARINE150H
Build Series : 134

lev	part	description	supplier	cost	qty
1	14500012	Engine Assy	Hyundae	10	1
2	14500013	Engine Body	Dong Sung	7	1
2	14500014	Engine Mount	Hwa	3	4

3.1.1 Change Management: An Integral Function of Precise BOM

Precise BOM을 변경시키기를 원할때 다음과 같은 내용을 알고 있어야 한다.

• 설계변경 내용 및 의미
• 다른 제품에 영향, 다른 Precise BOM
• 설계변경 요인이 된 문제와 설계변경의 관계
• 언제 설계변경이 적용되어야 하는지

그러므로 각 Precise BOM의 정확한 표현은 설계변경을 위해 꼭 필요한 기능이다.

생산에 적용되는 Precise BOM 변경의 영향은 광범위하므로 전체 조직에서 설계변경 의사결정에 필요한 정보를 얻는것이 중요하다.이 정보는 설계변경을 할것인가, 어떤 종류의 설계변경을 받아들일 것인가등을 결정한다. 그러므로 설계변경에는 필요한 승인을 얻기위한 자세한 Workflow Control이 필요하다. 설계변경은 PIM에서 실제로 Workflow 기능이 필요한 유일한 부분이기도 하다.

설계변경 관리 시스템은 다양한 방식이나 독창적인 방식보다는 정확한 승인과 변경의 의미를 알기 위하여 Strict 한 프로세스를 지켜야 한다. 아울러 다음과 같은 기능이 필요하나 현재 구현되고 있지 못하다.

• Traceability와 Auditing기능 : 설계변경 결과에 따라 실재 행동에 들어가기 전에 설계변경과정을 확인할 수 있는 기능이 필요
• 동시설변관리 : 한 Item에 대한 다수의 설계변경 요구를 관리할 수 있는 기능, 다수 souce에서 나오는 Problem report와 설계변경 요청을 처리하는 기능

설계변경은 Supplier-chain과 관련이 많다. 이를 위해서 Groupware와 Web 기술이 사용되고 있다. 예로 Agile Software에서는 Java와 Web Browser를 이용한 설계변경 Client를 개발했다.

3.1.2 Generic Production Definition and Precise Bills of Materials

Precise BOM은 주어진 제품의 기능을 구현하기 위하여 어떤 부품들이 조합되어야 하는가를 결정할수 있는 규칙에서 특정한 선택에 의하여 생성된다. 이러한 지식이 구체화 되었을 때 이를 Generic BOM 이라고 할 수 있다. 하지만 이 지식은 일반적으로 도면이나, 설계자의 Spreadsheet 혹은 경험에 흩어져 있다. Generic BOM은 어떻게 Recise BOM이 구성되는지를 완전히 표현하고 있어야한다.

---

Generic Bill of Material: A set of rules describing which parts can be used together to perform a given product function. (a kind of design intelligence)

---

많은 경우 Generic BOM은 MRP나 Sales Configurator에 정의하여 놓은 경우가 많다. 이는 초도 제품이 생성되고 제조나 판매에서 설계의 개념을 재해석하여 Generic BOM을 생성하는 경우이다. 즉 Sale BOM을 제품이 설계 시험제조가 끝난후에 생성하는 것이다. 이 방법은 우선 Error와 중복, 그리고 제품 Moudule화 Rule을 만드는 것이 아닌 단순한 product package를 만드는 것등이 단점이 될수 있다. 두번째 문제의 의미는 고객이 조금 다른 사양을 요구할 경우 이를 즉시 대응할 수 없다는 점이다(이를 극복하는 방법이 뒤에 나옴).

최근은 Generic BOM (설계지식)을 초기부터 구체화시키는 방향을 지향하고 있다. 즉 설계자들이 하위 부품을 설계할 때부터 해당 부품이 어떤 조건에서 어떤 부품과 결합할 수 있는지에 대한 지식을 정의 하도록 하고 있다. 물론 이에 대한 설계자의 Validation을 포함한다. 이렇게 먼저 Rule을 정의하고 Validate 하면 사용자의 요구에 대한 즉각적 대응이 가능해진다.

현재 IBM와 EDS/Unigraphics가 generic BOM mgt에 우수한 기능을 가지고 있다(1997).

3.1.3 The Role of Effectivity

---

Effectivity: a property that controls when a change of production data may be used in production.

---

위의 정의와 같이 Effectivity는 언제 설계변경이 실 생산에 적용되는가를 표시하는 정보이다. 하지만 Effectivity는 같은 종류의 Effectivity가 있는 BOM을 추출하므로써 Generic BOM에서 Precise BOM을 생성시키는 보다 일반적인 역할을 하기도 한다. 이 방법은 제품을 구성할 수 있는 모든 제품구조를 하나의 복잡한 BOM으로 생성한 후 특정 Effectivity(예 호기수를 나타내는 Range Effectivity)를 적용하므로써 해당 호기수에 대한 Precise BOM을 추출할 수 있다. 예로 해당 Effectivity는 고객 주문 번호가 될수 있으며 해당 주문번호를 적용하므로써 해당 제품의 Precise BOM을 Generic BOM에서 도출할 수 있다. 하지만 이 방법은 매우 많은 작업을 필요로 하며 Variant/Option/Feature를 기능이 있을 경우 불필요하다.

만일 제품이 매우 당양한 사양을 가지고 있으며 한 사양의 생산수량이 극히 적을 경우 설계변경이 Generic BOM에 적용되어야 한다. Precise BOM에 설계변경을 적용할 경우 이미 Generic BOM 이 변경되어 의미가 없어지는 경우이다. 하지만 현재 어떤 PIM 시스템도 이를 지원하지 못하고 있으며 단지 사용자가 선택할 수 있는 복잡한 제품구조를 제공할 뿐이다. 사용자는 주어진 구조중에 필요한 것을 선택하고 Where used operation을 사용하여 설계변경의 영향을 고려하게 된다. 하지만 Sytem이 BOM Context Level의 정보를 제공하지 못하므로 특정 부품이 사용된 Precise BOM이나 혹은 영향을 미칠 Generic BOM의 Rule을 확인할 수 없다.

3.2 Product Definitions

---

Product Definition: a full description of a product, a complete product technical package

---

Product Definition은 제품에 대한 모든 기술을 포함한다. 예로 관련 문서, 사진, 개념 그림, tool path, mold, 또는 Casting Modeling 등을 포함한다. 이와 같이 Product Defintion은 매우 광범위한 자료를 포함하므로로 제품을 보는 다양한 시각(사용자의 시각)에 따라 다른 Context로 보여줄 수 있어야 한다.

3.2.1 Mapping from Simple Definitions to Generic Bills of Materials

어떻게 Product Definition을 Generic BOM과 Mapping 시키는가가 중요한 문제이며 아직 해결되지 않고 있다. 7 가지 의문점을 제시

3.2.1 The Opportunity of Interface Management

위의 많은 문제점은 Interface Management 개념을 이용하여 해결할 수 있다. Interface Management는 제품을 조립품과 하위 부품의 계층관계로 보지 않고 하나의 Part는 전체 Product와 Interface를 가지는 Module로 본다. Interface Management는 추후 Product Representation에 주요한 역할을 하리라 예상된다.

Interface Management : Frederick Erens of Eindhoven University of Technology (Netherlands), Dan Whitney of MIT, Christoph Hoffmann of Purdue University, as part of Open CAD Architecture for Interoperability (OCAI) Initiative.

3.3 Capturing The Engineer's Perspective

Product Definition은 두가지 Domain을 가지고 있다:

• A description of functional requirements
• a set of engineering or technical solutions

3.4 Supplying Functional Requirements towards Product Definition

Functional Requirements는 주요 부품(Core Componets)와 해당 요구기능 및 Performance 그리고 대응 Engineering Solutions을 Mapping 시킴으로써 초기 Product Definition을 생성한다.

현재 Invention Machine 사의 Tech Manager가 Systemtic 하게 Functional Spec을 관리할 수 있도록 해주고 있다.

3.5 Challenge of Multiple Product Representations

Product Definition은 개발 단계에 따라 다른 Context로 보여주어야 하며 이를 위한 Change Management가 필요하다. 일부 이러한 Context의 변화는 협동과 동시공학에 위배된다고 반대하나 필요한 것은 협동에 참여한 각 전문가가 각자의 Context로 일관성을 유지하며 변화시킬 수 있는 기능이 필요하다.

Reference Sites

• Agile Software for Engineering Change
• Invention Machine for Functional Specification
• Open CAD Architecture for Interoperability (OCAI)
• Matra Datavision's Design Manager for Product Definition

---

Knowledge and Engineering Databases (c) copyright Namchul Do, 1999