Product data & IT 2004. 4. 30 Lim, Dong-June

1. Product data & IT2004. 4. 30 Lim, Dong-June

2. Content Part I. ArticleWilliam C. Burkett, Product data markup language: a new paradigm for product data exchange and integration, 2001 Part II. Sketch of my idea

3. Computer-Aided Design 33 (2001) 489-500 Product data markup language: a new paradigm for product data exchange and integration William C. Burkett Product data Integration Technologies Incorporated, Suite 540, 100 W Broadway, Long Beach, CA 90802, USA Received 25 October 1999; revised 6 October 2000; accepted 4 December 2000

4. The Challenge Information system technology has long promised to integrate business processes by providing communication channels that seamlessly enable members of a team to exchange data and information. But, … • The Problem consists of: • countless data repositories that are bound to and designed to support specific application, and • the need to provide and integrated, accessible, consistent data in a form useful and meaningful to the personnel supporting the product. In short, the problem is that accurate and meaningful product data is not visible to the personnel that need it.

5. The PDML vision The vision is not a single, integrated virtual product data repository, but rather an environment in which users can: • easily locate and obtain product data that is authoritative, timely and accurate; • view and understand the data without resorting to thesauri or indices, or dictionary; and • import the data into their own application systems with no more difficulty than simply downloading the file and opening it with the application.

6. The Current solutions(prior to 1999) • Approaches that have been pursued include the following: • Point-to-point translators that convert data bound to one system into the data format of a target system. • A shared DB that is used by multiple applications. • Product Data Exchange standard that specify a neutral, application independent data structure used to convey data between applications. • Database federations in which each repository makes its data visible to other databases/applications in the federation and accessible via an API. • Product Data Management and Enterprise Resource Planning applications that ‘throw a net’ over the applications Why don’t these solutions provide the product data visibility needed for the system integration and weapon system support? There are three reasons. • The complexity of application interoperability coupled with the huge variety of platforms and implementations make these solutions (1)point solutions, and (2)expensive solutions • The exchange of bits doesn’t equate to the exchange of meaning • The ever-changing requirements on system use makes points solutions brittle & short-lived

7. PDML* design philosophy • 1. Leverage existing technologies • ISO 10303 as a PDE* technology; • The Internet as an integration platform; • XML as data structuring and encoding language; • PDM systems as an enterprise data management tool. 2. Maintain emphasis on data semantics An important design principle of PDML is the emphasis on the meaning of the data to the users of the data (i.e. the data semantics) PDE: Product data exchange, PDM: Product data management, PDML: Product data markup language

8. Technologies The Web and XML ISO 10303 XML* is “… a simplified subset of SGML … optimized for the web environment, which implies data-processing-oriented (rather than publishing-oriented), and short life span (in fact, usually dynamically generated) information” “… many people nave noticed that XML documents resemble traditional relational and object database data in many ways. Once you have a language for rigorously representing documents, those documents can be treated more like other forms of data.” -Charles Goldfarb The design of PDML has adopted the ‘XML as data’ philosophy in the design of DTDs. XML: eXtensible Markup Language DTD: Document Type Definition

9. Technologies The Web and XML ISO 10303 • There are two parts of STEP* that have been leveraged in PDML • The generic, integrated view (Integrated Resources). • EXPRESS as a data specification language. EXPRESS  XML DTD conversion (ISO10303-28) STEP: STandard for the Exchange of Product model data

10. Table. EXPRESS  XML DTD conversion

11. PDML :product data markup language Not a single data specification, but rather a structure of related specification and tools to deploy and use integrated product data on the Internet. • PDML is composed of the following components: • Seven Application Transaction Sets. • The Integration Schema. • Mapping specification b/w the Application Transactions Sets and the Integration Schema. • The PDML toolkit

12. Figure. Relationship of PDML components

13. PDML :product data markup language Application transaction sets Integration schema Mapping specification & view integration PDML toolkit There are seven Application Transaction Sets defined in PDML:Product Structure, Product Description Documents, Technical Order -4, JEDMICS, MIL-STD-2549 DIP1, MIL-STD-2549 DIP3 MIL-STD-2549 DIP7 The Product Description Document Application Transaction Set is a very simple view intended for document identification and management JEDMICS is the primary system used by DoD for managing technical data. The technical Order -4 is a standard form used by the Engineering Support Authority at Tinker Air Force Base for maintenance and procurements of B52 parts. MIL-STD-2549 is a new DoD (Department of Defense) standard for a Configuration Management Data Interface. This standard defines the data elements, and relationships necessary for the delivery of and access to electronic configuration management data. ‘DIP’s are Data Information Packet that specify a predefined subset or usage of the overall 2549 standard for a particular purpose DIP1: Drawings, Specification, Standard, Software and Software Support Documents DIP2: Product/Asset Configuration DIP7: Engineering Parts List

14. PDML :product data markup language Application transaction sets Integration schema Mapping specification & view integration PDML toolkit The Integration Schema is an EXPRESS schema that is based on the STEP Integrated Resource. Unlike STEP, data is not exchanged using this neutral view, but rather using the external views. When and integrated, cross-application view of product data is needed, data is extracted from the appropriate systems using their Application Transaction Sets, integrated Schema, and then converted back to a specific Application Transaction Set view The Integration Schema is not intended to be directly used for product data exchange. Rather, it is more appropriate to consider it a temporary neutral form for integration and view translation.

15. Figure. Small subset of integration schema

16. PDML :product data markup language Application transaction sets Integration schema Mapping specification & view integration PDML toolkit As a view, the Application Transaction Sets can be considered as a particular interpretation of the Integration Schema. This interpretation is formally specified by a Mapping Specification Mapping is more than conversion between data structures. It encompasses the interpretation of data based on contextual values, a value from a single field doesn’t always mean exactly the same thing. (though it always generally means the same thing.) The PDML Toolkit ‘internalizes’ and uses the Mapping Specification to drive the conversion of XML data to/from the Integration Schema format.

17. PDML :product data markup language Application transaction sets Integration schema Mapping specification & view integration PDML toolkit The PDML Application Transaction Sets can be used directly by application system for viewing and exchanging product data. The integration performed in the Toolkit is driven by the mapping specifications. The intent of PDML is for users to interact only with the Application Transaction Set views of the data; the neutral model is hidden by the mapping specification and conversion software.

18. Why is PDML different? Mainstream pursuits of standardization of XML vocabularies and DTDs focus their efforts on the definition of the definition of the elements of their vocabulary, within their own particular usage community! However, experience with data exchange standards such as STEP show that such solutions are not • portable. • usable or useful (or not very usable/useful) outside the usage community that defined it. • integrated with other vocabularies

19. Sketch of my idea

20. Starting point: a motivation • Some of the characteristics that make product development challenging are: • Trade-off • Dynamics • Details • Time pressure • Economics Karl T. Ulrich, Steven D. Epinger, Product design And Development 3rd edition, p6,McGrawHill, 2004

21. Table. The generic product development process Karl T. Ulrich, Steven D. Epinger, Product design And Development 3rd edition, p15,McGrawHill, 2004

22. Figure. Concept development phase Karl T. Ulrich, Steven D. Epinger, Product design And Development 3rd edition, p16,McGrawHill, 2004

23. General Web Services Scenario 시나리오: 철강자재를 구매하려는 자재부 김 대리 고급 공장기계를 생산하는 A회사에 다니는 김 대리. 김 대리의 가장 큰 임무는 좋은 철강자재를 싼 가격에 구매하는 것이다. 몇 년 전에 B2B 마켓플레이스라는 것이 나와서 업무하는 데 꽤나 도움이 될 줄 알았건만 송장 발송에서부터 회사 사이에서 처리해야 할 문서도 너무 많고, 온라인이라는 것이 무색하다는 생각 뿐이다. 최근에 철강자재 구매와 관련한 웹 서비스를 이용할 기회가 있어서 이를 이용해보니 원하는 조건과 가격대를 모두 비교해서 구매를 수행할 뿐만 아니라, 각종 문서의 처리가지 웹을 통해서 완벽하게 처리해주는 것이 아닌가? ‘사장님이 이 사실을 아시면 큰일인데…” 김 대리의 고민이 또 다시 시작된다. 정지훈, 웹 서비스, p35, 한빛미디어, 2002

24. I .Define documents II .Define process Sketch e-Doc Vendor 1 Web Service framework Vendor 2 Product development team ……. Vendor n III .Develop a program, which is used to illustrate overall concept

25. Related researches • Hongbo Lana, Yucheng Ding, Jun Hong, Hailiang Huang, Bingheng Lu, A web-based manufacturing service system, 2003 • Woerner and Woern, Distributed and Secure Co-operative Engineering in Virtual Plant Production, 2002

26. Future work If this topic is not bad, • More paper survey, (esp. in ‘collaboration’ field) • More understanding of IT technologiesWeb Services, XML, …