The document discusses graphics standards and the need for data exchange standards when transferring CAD files between different software and hardware platforms. It covers early issues with hardware dependence and the development of device-independent standards like GKS. It also summarizes several important neutral CAD data exchange standards, including DXF, IGES, STEP, and discusses some of their limitations in fully transferring design intent and parametric models. It proposes a macro-parametric approach using standardized modeling commands to improve the exchange of CAD files while maintaining parametric design histories.

1. GRAPHICS STANDARDS
• Introduction
The need for portability of the geometric model among different hardware
platforms has led to the development of device independent graphics.
Simultaneously standards for exchange of drawing database among
software packages have been evolved to facilitate integration of design &
manufacturing operations.
“In the actual source code of the application program, the graphics systems
embedded in the form of subroutine calls. Therefore, software becomes
inevitably device – dependent. If input/output devices change or become
obsolete, its related software becomes obsolete as well unless significant
resources are dedicated to modify such a software. This approach was very
costly to both CAD/CAM vendors as well as users. (1963-1974)

2. Graphics Standardization Needs
Vendor Concerns:
• Application program portability: This avoids hardware
dependence of the program. Eg.: If the program is written for a
DVST display, it can be transported to support a raster display
with minimal effort.
• Picture data Portability: Description and storage of pictures
should be independent of different graphics devices.
• Text Portability: This ensures that text associated with graphics
can be presented in an independent form of hardware.

3. User’s Interest
 Object database Portability: Transporting design and
manufacturing data from one system to another.
In 1974, the GSPC (Graphics Standards Planning Committee)
was formed to address the standards issue.
Here, the graphics system is divided into two parts
1. Kernel (CORE) System: Which is hardware-independent
2. Device Handler/Driver: Which is hardware-dependent
Kernel (CORE) : The Kernel system, therefore acts as a buffer
between the application program and specific hardware to ensure
the independence and portability of the program.

4. Application
Data Structure /
Model
Application
Program
Graphics
System
Input / Output
Device
Kernel
(Core)
System
Device
Handler/
Driver
Without Graphics Standard
Graphics System
A B
With Graphic Standard
At interface A in figure, the application program calls the standard functions and subroutines
provided by the kernel system through what is called language bindings. These functions and
subroutines, intern, call the device handler / driver functions and subroutines at interface B to
complete the task required by the application program. Application and system programmers
also become portable and can move from one system to another. Moreover, if a device
becomes obsolete or a new one is to be supported, only the device handler/driver is to be
written or modified. This is possible because the kernel system works with virtual devices.

5. Standards
1. GKS is an ANSI and ISO standard.
(i) It is device-independent, host-system independent, and
application-independent.
(ii) Supports both 2-D & 3-D data viewing. It interfaces the
application program with graphics support package.
(iii) Text / Annotations: All text or annotations are in a natural
language like English.
(iv) Display management.
The drivers in GKS also include metafile drivers. Metal files
are devices with no graphic capability like a disk unit.

6. 2.PHIGS (Programmer’s Hierarchical Interactive Graphics
System)
It is intended to support high function workstations and their related
CAD/CAM applications. It has dynamic control over the visual appearance
of attributes of primitives in a segment. The PHIGS standard defines a set
of device-independent logical concepts.
The major concepts are:
Logical Input Device, PHIGS Structure, Structure Networks, Structure
Manipulate, Search and enquiry, Structure Transversal and Display, the
name set mechanism, the viewing pipe line, and the PHIGS workstation.

7. 3.VDM (Virtual Device Metafile) defines the functions needed
to describe a picture. Such a description can be stored or
transmitted from one graphics device to another. It functions at
the level just above device drivers. VDM is now called CGM
(Computer Graphics Metafile).
4. VDI (Virtual Device Interface) lies between GKS or PHIGS and the
device handler / driver code (at B in fig.). Thus VDI is the lowest
device independent interface in a graphics system. It shares many
characteristics with CGM. VDI is designed to interface plotters to
GKS or PHIGS. It is not suitable to interface intelligent
workstations. VDI is now called (Computer Graphics Interface).
5. IGES (Initial Graphics Exchange Specification):
Approved in September, 1981 as ANSI standard 414.26m. It
enable this an exchange of model database among CAD/CAM
system.

8. 6. NAPLPS (North American Presentation-Level Protocol Syntax)
was accepted by Canada and ANSI in 1983. It describes text
and graphics in the form of sequence of bytes in ASCII code.

9. CONTENTS
• Need For Data Exchange
• Problems In Data
Exchange
• Data Translation
– Direct Translator
– Standard Kernel Model
– Neutral CAD Standard
• DXF
• IGES
• STEP
• STEP Architecture
• Failure Of STEP For
Exchange Of Design Intent
– Methods Of Improving Data
Exchange
– Macro Parametric Approach
• Conclusion

10. Need For Data Exchange
• Design Modification
• Tool design
• NC Machining
• Finite Element Analysis
• Digital Mock Up

11. Problems In Data Exchange
• Feature, History & parametric Information
• Difference In System Functionality
• Design conventions

12. Data Translation
• DIRECT TRANSLATOR
• STANDARD KERNEL MODELS
• INTERNATIONAL STANDARDS

13. Direct translators
• Features
1. CAD file reader
2. Ability to read several
different formats of
CAD file
3. Exchange of geometry
• Problems
1. Expensive
2. As the no. of CAD
system increases, the
no. of converters
increases
To slide 5

14. Standard kernel model
• Features
1. Used in multiple systems;
both high- end and mid-
range
2. Can produce Machine
independent File
• .sat file
• .xmt file
1. File written by one system
is readable by another
system based on same
kernel
• Problems
1. Special entities are not
supported by .sat and .xmt
files
2. Pro-E,Catia and Ideas are
not based on .sat or .xmt
To slide 5

15. International/Neutral CAD Standards
Popular Standards In Mechanical Field
• DXF
• IGES
• STEP

16. DXF
• FEATURES
1. Easy to interpret
though a long file
2. Translate 2-D data
• PROBLEMS
1. Limited to software like
Auto-Cad and Auto
desk inventor

17. IGES
• FEATURES
1. Extensive entity
mapping
2. Digital
Representation and
communication of
product data
• PROBLEMS
1. Solid object translated into
wire frame model by the
receiving end.
2. Causes user to spend more
time on receiving End.
3. Data loss while mapping

18. STEP – ISO10303
• Advantages Of STEP Over Other Standards
1. Unlike IGES, this method transfers the solid body at the receiving end.
2. As the CAD models get more complex this feature plays an important
role at the hands of the receiving end.
3. The long-range advantage is that STEP provides support for complete
product life-cycle data exchange including design, manufacturing,
application, maintenance and disposal.
4. This aspect of STEP makes the standard suitable, not just for IGES-style
data exchanges, but also for implementing an integrated product
information database that is accessible and usable to all the
organizations and individuals involved in supporting a product over its
life.

19. STEP Architecture
The STEP architecture includes:
• An information modeling language (EXPRESS)
• Data schemes including attributes such as geometry,
topology, feature and tolerance
• Application interface called Standard Data Access Interface
(SDAI) which is a standard interface to enable applications to
access and manipulate STEP data

20. STEP Architecture……
• STEP data base has the following forms:
• Working from a file, usually in binary format, that can
be shared by multiple systems.
• Shared data base ,involving object oriented data base
management system.

21. Failure Of STEP For Exchange Of Design
Intent
• Conceptual Mismatch
• Capability Mismatch
• Accuracy Mismatch
The most important core capabilities of current CAD systems
that are not covered by STEP are those concerned with
parameterization, geometric constraints, design features,
and model construction history .

22. Methods Of Improving Data Exchange - By
Feature and History translation
Feature and history file conversion is one in which all of original
geometry and geometric features of the model in a source CAD
system file are re-created by the the CAD application in a specified
target software application.
The advantages of feature and history file translations include
• Fully modifiable features and entities are easier to work with.
• Smaller and more efficient files.
• The ability to share CAD files across an organization or across an
industry, regardless of the types of CAD systems being used by the
parties sharing the files.

23. Macro-Parametric Approach for Exchange
of Design Intent
STEP cannot represent design parameters,
constraints, and features. To solve these
problems, it is necessary to define a new STEP
schema to solve this problem. The schema
should include the history-based model, which
is the parametric method adopted by
commercial CAD systems.

24. Concept of Macro-Parametric Approach
In this approach, CAD models are exchanged in the form of macro files.
The macro file contains the history of user commands, which define a
high-level dynamic interface, is recorded in a macro file, and the
macro file is used for the static model exchanges which are used in the
modeling phase.
To exchange CAD models using the macro-parametric approach, the
modeling commands of several commercial CAD systems are analyzed.
Those commands are classified and a set of standard modeling commands
have been defined. Mapping relations between the standard modeling
commands and the native modeling commands of commercial CAD
systems are defined.

25. Standard Modelling Commands
Grouping of standard modeling
commands
Classification of standard modeling
commands