We propose a 'self-describing' Casting Data Markup Language (CDML) to .... language employed for this purpose is HTML (Hyper Text Markup Language).
AFS Transactions 02-078 Page 1 of 16
Casting Data Markup Language for Web-based Collaborative Engineering B. Ravi Indian Institute of Technology, Bombay M.M. Akarte SGGS College of Engineering and Technology, Nanded Copyright 2002 American Foundry Society
ABSTRACT We propose a ‘self-describing’ Casting Data Markup Language (CDML) to model the essential information exchanged between product, tooling and foundry engineers, based on the rapidly emerging web-friendly XML (eXtensible Markup Language) standard. The CDML comprises a hierarchical tree with 270 nodes (representing metal composition, gating design, etc.), each linked to a relevant data file that may in turn have hyperlinks to image and model files. A systematic approach to integrate libraries (such as cast metals, processes and tooling elements) and functions (for example, castability analysis and cost estimation) with the CDML structure is also proposed. A prototype system has been implemented and a few functions have been developed to demonstrate the applications and benefits of web-based collaborative engineering of cast products. The system enables an engineer to initiate a casting project from a CDML template, select the appropriate metal or process from the library, edit the product requirements, specify other members of the project team and save the data in a secure on-line folder. The team members can access and modify the relevant data from any location worldwide. This ensures availability of the latest information, allows early identification and fixing of manufacturability problems, and enables team members to plan their activities concurrently.
INTRODUCTION It is well known that at the production stage quality problems are easily detected but difficult to eliminate. On the other hand, at the conceptual stage the problems are difficult to predict but most of them can be easily prevented by minor design modifications. The benefit to cost ratio of early design modifications has been shown to be several magnitudes higher than modifications at the production stage (Gustafson, 1999). There can be three levels of approaches to improve a product design for manufacturability or DFM (Figure 1). The first level involves submitting a product design (just before freezing the drawings) to manufacturing engineers for feedback. However, several iterations may be required before optimizing functional requirements and manufacturability. In the second level, toolmakers and manufacturing engineers are a part of the design team and are involved right from the conceptual stages, which also helps in concurrent engineering of their respective activities. The success of this approach depends of the amount of time committed by the team members, which is limited owing to their own (departmental) responsibilities. The third level involves the application of DFM techniques such as illustrated guidelines, cost estimation and process simulation to evaluate the design and share the results over a digital network with team members, who can point out any inconsistencies or oversights with little effort. The volume of information increases with the levels. The first level may require only the product drawing and basic information about the metal, quality and production requirements. Information for the second level includes functional requirements, materials, tooling elements, process plan and inspection procedures, as well as the details of team members involved in the project. The third level will include the results of various analysis procedures (such as cost or value analysis and process simulation) in addition to the above. For effective collaborative engineering, project team members must have access to the latest version of the relevant information and should be able to communicate any modifications to other members in real time. This is possible only by adopting a systematic approach based on digital technology for product data representation, management and exchange. The latest standards and technologies for exchange of information between casting project team members to enable collaborative engineering are briefly reviewed next, before presenting our proposed approach.
AFS Transactions 02-078 Page 2 of 16
Fig. 1 Three approaches to improve a product design for manufacturability.
RELATED WORK: STEP, PDM AND XML STANDARD FOR EXCHANGE OF PRODUCT MODEL DATA (STEP) The STEP is an ISO 10303 project to develop the mechanism for representing and exchanging the data of a computerized product model in a neutral format (Radack, 1997). Important goals of STEP include support for geometric as well as nongeometric data of the product, and facilitating uniform product representation for information sharing among team members irrespective of platforms (Loffredo, 2001). The standard defines Application Protocols (APs) for domain-specific information requirements. A draft of STEP application protocol for the casting industry (AP223) has been developed by Concurrent Technologies Corporation and includes the following: • • • • •
Casting design information such as geometry, tolerance, material, tests required, physical and mechanical properties. Process information including melting, treating and pouring of molten metal, shot blasting, inspection and defects. Specifications and design information for tooling elements such as patterns, cores, risers, dies and die assembly. Processing information related to the production of tooling elements. Input to and output from casting process simulation software.
The proposed standard, when finalized and adopted by the industry, will facilitate information exchange between the customer and foundry, within the foundry, and between foundry and its suppliers, yielding the following benefits: • • • • •
Ease of file transfer between foundry and its customers and suppliers. Consistency in part drawing and integration with other software. Promote computer-aided casting such as mold and die design and simulation. Improved automation and computer control of production process. Reduction in lead-time for the approval of first sample casting.
PRODUCT DATA MANAGEMENT (PDM) PDM is the technology to manage and control all types of information related to a product required by different processes in its life cycle (Miller, 1995). A typical PDM system comprises an electronic vault (repository for product related data, that could be located on a single server or distributed across several platforms) and programs for handling the following tasks (Gascoigne, 2001):
AFS Transactions 02-078 Page 3 of 16
• • • • • • • •
Product structure management: Maintaining the part list, bill of material and part definition Document management: Storage and retrieval of files containing product information Communication management: Information transfer and events notification, mainly through e-mail Data transport: Tracking data locations and moving data from one location or application to another Data translation: Exchanging files (importing and exporting) in the proper format Workflow and process management: Specifies process definition or who approves what and when Parts management: Provides information on standard components and facilitates re-use of designs Release management: Provides security and control, establish data relationship
Several PDM systems are commercially available today. This includes Metaphase, Sherpa and Windchill among others (Kempfer, 1998). These are associated with significant benefits (Miller, 1997). For example, IBM reported 70% reduction in non-value process time for engineering changes, 35% productivity improvement in part selection and lowering of excess inventory, scrap and rework. The Boeing Commercial Airplane Group used PDM to keep track of three millions parts in each aircraft, achieving 99.7% accurate information. The following drawbacks however, have limited the widespread application of PDM systems (Liu, 2001): • • •
Implementation effort: Most of current PDM systems are complex, pre-configured and off-the shelf kind, based on the product structure or bill of material (Gain, 1996). Implementing it according to the organizational requirements may take months before complete deployment. User interface: Each PDM system has its own unique user interface and requires considerable training and practice by the end users. Increased functionality and complexity of the latest systems may have further hindered the penetration of PDM systems. Lack of global access: Most PDM systems are effective only for inter-organizational data exchange and cannot cater to the needs of multinational organizations or multi-organization projects, in which team members are spread across the world.
EXTENSIBLE MARKUP LANGUAGE (XML) The Internet offers a powerful and inexpensive way to publish and access information worldwide. The most common language employed for this purpose is HTML (Hyper Text Markup Language). The HTML is useful for formatting the content for display purpose, but can not be ‘understood’ by computer programs for higher level purposes (such as calculations based on data in a web page). To overcome this limitation, the World Wide Web Consortium (W3C) has come up with XML for eXtensible Markup Language (World Wide Web Consortium, 2000). The XML is a meta-language – a language for describing other languages. It is platform-independent and permits definition of domain-specific tags that allow the data to become self-describing. The XML documents can be processed using the Document Object Model specified by W3C. Other features include the following. • • • • • •
Open standard: XML is recommended by the W3C and is not the proprietary development of any single organization. Modular: XML separates the logic of document data representation and presentation. Structured: For example, start and end tag must match, and all elements must be properly nested. Processing: XML documents can be easily processed by computer programs, including web browsers. Compatibility: It is based on existing web technologies (such as HTTP and URL). Extensible: XML documents are self-explanatory, easy to create and modify, and easily interpreted by others.
A few XML-based applications are currently being developed. For example, Material and Property Data Markup Language (MatML) is being developed by the NIST (National Institute of Standards and Technology), USA. A portion of the MatML structure is shown here (MatML, 2001).
0
AFS Transactions 02-078 Page 4 of 16
K
3
As seen from the above discussion, STEP-AP223 offers a comprehensive standard for describing casting data, but is yet to be finalized and adopted by the industry. On the other hand, the current PDM systems are mainly developed around the bill of materials concept (none of these are reported to handle detailed casting data) and may require several months to customize for a particular organization. Further, the current PDM systems are mainly designed for information exchange within an organization; there is no direct support for team members spread across the world. The development of web browsers (that have a uniform, platform-independent user interface) and XML (a self-describing language that is compatible with existing web technologies), is fuelling the development of a new generation of web-enabled PDM systems (Liu, 2001). To take advantage of these developments for the casting industry, we need an XML compatible standard for defining the casting data. The foundation for the current investigation was laid in 1995, when the authors carried out an exercise to identify essential information exchanged between product designers, tool makers and foundry engineers, as well as the software programs used by them. The casting information was modeled as an object-oriented hierarchical tree structure and an MS-DOS based casting information management system (CIMS) was implemented to browse and edit the information (Ravi, 1996). The structure was further improved and adopted to seamlessly integrate a suite of Windows-based casting applications, ranging from part castability analysis and cored feature identification to gating/feeding design and process simulation (Ravi, 1999). The current investigation takes the work further, by completely redesigning the information structure to make it web-friendly and facilitate collaborative engineering between casting life-cycle engineers.
CASTING DATA MARKUP LANGUAGE (CDML) The CDML has been developed with the following objectives: 1. 2. 3. 4. 5. 6.
Enable a modular and systematic approach to casting product data management. Capture essential information exchanged between product, tooling and foundry engineers. Provide a structure for linking image and solid model files. Facilitate quick searching and identification of any desired item of information. Enable linking libraries of alternative options as well as design/analysis functions. Easily extensible by including additional information, without affecting existing functions.
The proposed CDML structure comprises a tree and several data blocks. The CDML tree represents the hierarchical (parentchild-grandchild) relationship between different data blocks, represented by nodes in the CDML tree. The data block files are linked to the tree through an indexing scheme. Other files, containing images and solid models are hyper-linked to the respective data blocks. A complete set of files including CDML tree, data blocks, images and solid models defines the casting project database for a given product. A new casting project can be initiated starting from a default database. A library of alternative options (for the data blocks) and application programs are also linked to the CDML structure. The various elements of the CDML structure are briefly described next (Figure 2). CDML TREE The CDML tree is stored in a file called CDML_TREE.XML. The top node in the tree is called PROJECT and has nine child nodes: ADMIN, PRODUCT, MATERIAL, TOOLING, PROCESS, EQUIPMENT, QUALITY, SCHEDULE and OTHER. Each of these in turn has child nodes (grandchildren of the top node). For example, ADMIN has child nodes called ORDER, OEM, TOOLMAKER, FOUNDRY, SUPPLIERS, LEADTIME, COSTING and TEAM_MEMBERS. Similarly FOUNDRY has further child nodes called ADDRESS, CAPABILITY, FACILITY and OTHER. The nodes of the CDML tree are coded as CDXXX where XXX is an integer between 001 and 999. To facilitate future expansion of the tree without disturbing the index numbers of all current nodes, 100 nodes are reserved for each child (including its child nodes) of PROJECT. Thus nodes 100-199 are reserved for the ADMIN group, 200-299 for PRODUCT, 300-399 for MATERIAL, etc. The complete CDML tree along with the indexing scheme is listed in Appendix A.
AFS Transactions 02-078 Page 5 of 16
Fig. 2 The schematic structure of Casting Data Markup Language (CDML)
CDML DATA BLOCKS There are a total of 270 data blocks, each stored in a separate file with the name same as the corresponding node in the CDML tree with extension XML. For example, the administrative data represented by the ADMIN node (indexed as CD100) in the CDML tree is stored in the file CD100.XML. Each data block comprises several pairs of field names (with unit, if any) and their values. Some fields are common to all data blocks; this includes VERSION, NAME, FILE, DATE, TIME, MODEL and IMAGE. The field NAME stores the name of the data block and FILE stores the name of the file in which the data is stored, whereas DATE and TIME store the date and time of its creation or last update. The fields MODEL and IMAGE contain the names of relevant files that are linked to the data block. Some of the data blocks can be duplicated to create multiple instances (for example, TEAM_MEMBER-1 can be duplicated to get TEAM_MEMBER -2, TEAM_MEMBER -3, etc.). Such blocks are referred to as siblings. The default CDML project stores only one template node (and the corresponding data block file) for siblings. The information in the CDML tree and data blocks is stored as per the XML standard version 1.0. For each field in the data blocks, starting and ending tags have been defined, and the corresponding value is stored between the two tags. Units (if any) are attached to the starting tag. The following examples illustrate two fields in the ADMIN data block.
3.5 1250
The size of a data file depends on the number of fields. A typical data block has 20-30 fields and occupies 2-4 KB space. All the data blocks together contain over 3000 fields (and their values). It is possible to add new nodes in the CDML tree or new fields in a data block in later versions of the CDML. A sample data block (containing information about product requirements) is listed in Appendix B.
AFS Transactions 02-078 Page 6 of 16
IMAGE AND MODEL DISPLAY Each data block may contain optional hyperlinks to image and solid model files. The file extension indicates the file format. For example, BMP, GIF and JPEG extensions are normally used for images, whereas DXF, IGES, STEP and STL are common formats for solid models. If an image file is hyperlinked, then the corresponding image file can be automatically downloaded and displayed by the browser. Since the browsers can not display solid models directly, we have developed a Java program (which is automatically downloaded) for displaying the linked solid model file. CDML-BASED LIBRARIES A library offers alternative options for the set of field values in a data block. The library database contains several data block files corresponding to a particular CDML data block. Any of these can be selected and its values copied to the corresponding data block in the current project. The library facility enables options for tooling elements, cast metals, process characteristics, suppliers, and other useful items. Selection and automatic copying eliminates manual input (and thereby the possibility of human errors), and helps in maintaining the complete data for each project in a separate folder. Each option in the library is stored either in a single data block (for example, for mold dimensions) or sets of data blocks (as in the case of metals: one block each for standards, physical properties, mechanical properties, etc.). The files containing the library data blocks are named after the respective CDML data block and the option number. For example, the casting metal data block is given by CD310.XML and the corresponding library options are stored in CD310_LIB101.XML, CD310_LIB102.XML, etc. A separate file LIBRARY.XML stores the list of all library options available for various CDML data blocks. Each option can be given a descriptive label for displaying during the selection procedure. If a large number of options are available, they can be segregated in different groups, and each group can be given a descriptive label. A portion of the library file showing the options for cast metals is given in Appendix C. CDML-BASED FUNCTIONS We have developed a novel approach to link functions with the CDML, that makes the functions modular and contextsensitive, and eliminates the clutter (pull down menus, icons, buttons, floating dialogue boxes, etc.) otherwise associated with most CAD/CAM applications. The functions are coded using Java, PHP or any other suitable language. The code for each function is stored in a separate file. These files are ‘registered’ and linked to the most relevant data blocks through the FUNCTIONS.XML file. A portion of this file is listed in Appendix D. There are two types of functions: general and context-sensitive. General functions are common to all data blocks and are always visible to the user. These include update, link, clone and delete. The update function is useful for backing up the current data block in a central server (useful after modifying the field values so that they become visible to other users also). The link function is for uploading an image or solid model file to the server and linking it to the current data block. The clone and delete functions are for duplicating and deleting the current data block, if it is of sibling type. The context-sensitive functions are block-specific. For example, the cast metal selection function is linked only to the CASTING MATERIAL block and the cost estimation function is linked to the COSTING data block. Unlike conventional programs, in which the user executes the function first and then views the results, in our approach the user views the block of results first and then computes or updates them using the function that appears at that instant only. IMPLEMENTATION AND EXAMPLE We have implemented the CDML and an Interface program for creating, viewing, modifying and exchanging casting project data over the Internet. The system can be accessed at www.metalcastingworld.com/intercast/cdml. It has been developed for standard web-browsers, such as Microsoft Internet Explorer and Netscape Navigator, providing the following benefits: • • • •
The standard web browsers eliminate the need for special client software on each machine. They work on a range of hardware platforms and operating systems with a uniform look and feel. They are universally available and inexpensive (if not free). Most users are likely to be familiar with web browsers and may not require any training.
AFS Transactions 02-078 Page 7 of 16
The CDML Interface has been developed using JavaScript and embedded in the main page of the CDML projects. It is automatically downloaded and executed when the user views the main page of CDML using his web browser. The Interface displays the CDML tree, data block, the relevant image and function list. The standard XML-DOM (Document Object Modeling) functions have been employed for accessing the CDML tree and data blocks whereas HTML (Hyper Text Markup Language) is used for displaying the content. Various windows of the interface are described here (Figure 3). 1. 2. 3. 4.
Tree window: Displays the CDML tree, the nodes of which can be clicked to expand or collapse the tree. Data window: Displays and allows the user to edit the data block corresponding to the selected node. Main display window: Displays 2D images, 3D models and the results of the application programs. Function window: Shows general and context-sensitive functions (those linked to the current data block).
Fig. 3 The CDML interface showing the tree, data block, solid model and functions.
Fig. 4 The library function displays the options for cast metal.
AFS Transactions 02-078 Page 8 of 16
To illustrate the application of CDML, a sample session of cast metal selection is described here. Step 1 (Figure 3): The user starts a new project from a default CDML template. The CDML Interface loads and displays the tree. The user can click any node to view its data block as well as expand the node into its child nodes, if any. Clicking the PRODUCT node and then the Display_Model function automatically downloads the part model and displays it in the main window. The model can be rotated, zoomed and panned. Step 2 (Figure 4): The user browses through the CDML tree and selects the node corresponding to the CASTING MATERIAL. Its data block is immediately displayed in the data window. Clicking the Library function displays the list of ferrous and non-ferrous metals. The user selects ductile iron family, and the various options are displayed. The user can select an option, view its properties and copy the values to the current project. Step 3 (Figure 5): Clicking the Material_Selection function brings up two utilities. The first utility allows the user to specify a standard and view the equivalent standards for the metal. The second utility short-lists the metals that have properties closest to the product requirements. Step 4: The user clicks the Update function to save the data to the server. Any other user accessing the same database will also be able to view the latest data now. Basic security measures have been provided (mainly a project-specific login name and password) to prevent unauthorized users from accessing the database of a particular casting project team.
Fig. 5 The material selection function displaying equivalent standards.
OTHER APPLICATIONS AND FUTURE The CDML has been designed to be easily extensible in the following ways: • • • • •
Addition of new fields in any existing data block Provision for adding new nodes and corresponding data blocks Addition of new functions and libraries without modifying the tree or data blocks Restructuring the tree (rearranging the nodes) without affecting current applications Adding new types of hyperlinks (attached files)
Since the functions are modular and essentially operate as ‘black-boxes’ (taking their inputs from one or more data blocks and putting the results back into one or more data blocks), anyone can develop an application and link to the CDML simply
AFS Transactions 02-078 Page 9 of 16
by ‘registering’ the function in the FUNCTIONS.XML file. A few examples of applications include casting cost estimation, furnace charge calculation, material and process selection, process planning and scheduling, quality control and defects analysis. As more bandwidth becomes available, more complex functions, including casting process simulation may be developed and made available over the web. Managing the casting projects on the web will not only bring the design and manufacturing engineers closer, but also encourage entirely new approaches to trouble shooting and knowledge management. For example, a casting expert (located in another city) can be provided access to the casting project data for study and recommending measures to improve the quality assurance. New software tools can be developed to study the profiles of several projects carried out by a particular firm, identify the core capability of the firm and automatically seek out similar projects from potential clients, including from business-to-business electronic commerce web sites. CONCLUSION This investigation is motivated by the need for collaboration between casting life-cycle engineers (mainly product, tooling and foundry engineers) to optimize the functional and manufacturability requirements and to evolve their respective plans in parallel, thereby significantly reducing the total costs, lead-time and quality problems. The Internet offers an inexpensive and ubiquitous platform for developing a collaborative engineering system for the casting domain. This however, requires a systematic and web-friendly scheme for defining and storing the casting information. The proposed Casting Data Markup Language (CDML) aims to fill this gap. The CDML captures the essential information exchanged between product, tooling and foundry engineers, and enables linking other files, libraries and application programs to the structure. It can be easily extended to include and manage new data items in future. The prototype system for initiating, modifying, storing and exchanging the casting project data on the web demonstrates the ease of use, applications and benefits of such an approach. This will encourage the community of casting software developers to create CDML compatible programs that work seamlessly with each other on the web, eliminating the need for manual input and customized data translators. Eventually, CAD/CAM applications will become accessible to all potential users, irrespective of their size or location. ACKNOWLEDGEMENTS The authors wish to acknowledge the assistance of G. Brijulal for developing the cast metal databases and Jayesh Gokhale for the solid model display algorithm; both Masters students in the Department of Mechanical Engineering at IIT Bombay.
Gain, P. R., “New generation of PDM emerges,” Computer-Aided Engineering, Vol 15, No 11, pp 52-58 (1996). Gascoigne Bill, “PDM: The essential technology for concurrent engineering,” http://www.pdmic.com/articles/artetfce.html (2001). Gustafson, “Rapid prototyping a tool for casting design and verification,” Modern Casting, Vol 89, No 3, pp 44-47 (1999). Kempfer Lisa, “Managing engineering data locally,” Computer-Aided Engineering, Vol 17, No 6 (1998). Liu, D. T., Xu, W., “A review of web-based product data management systems,” Computers in Industry, Vol 44, pp 251262 (2001). Loffredo David, “Fundamentals of STEP implementation,” STEP Tools Inc, New York, http://www.steptools.com/library/fundimpl.pdf (2001). MatML, “XML for materials property data,” http://www.ceramics.nist.gov/matml/matml.htm (2001). Miller, E., “PDM today,” Computer-Aided Engineering, Vol 14, No 2, pp 32-40 (1995). Miller, Ed., “Where PDM pays off,” Computer-Aided Engineering, Vol 16, No 10, pp 92 (1997). Radack, G. M., Wang, C. Y., Paul, A. J., and Sigworth, G. K., “New STEP standard streamlines exchange of casting design data,” Modern casting, Vol 87, No 4, pp 40-42 (1997). Ravi, B., Akarte, M. M., “Casting Information Management,” Transactions of the AFS, Vol. 104, pp. 217-223 (1996). Ravi, B., Creese, R. C., and Ramesh D., “Design for Casting – A New Paradigm to Prevent Potential Problems,” Transactions of the AFS, Vol 109, (1999). World Wide Web Consortium, http://www.w3.org/XML, (2000)
