Motivations and Standards for CAD Data Exchange

Motivations for CAD Data Exchange Standards
CAD companies hid the formats of their data, to encourage a current installation to rely on that one product type Reliance on hand-built translators Started out as drawing transfer (lines, text, layers) Only later were there commercial surface and solid modelers.
Design & Engr. Databases
Exchange Technology at the Time A structured file format

A way to specifiy different types of geometry Separate the geometry type spec from the data
Provide aggregation types to define complex parts
Initial Efforts at Data Eexchange Standards

IGES
IGES test file generated for example translation data translator version IGESOUT-4.01. S0000001 S0000002 S0000003 ,,7HUNNAMED,18HD:\CAD\ARCFACE.IGS,13HIGES-testcase,13HIGESOUT-4.01, G0000001 32,38,6,99,15,7HUNNAMED,1.0,1,4HINCH,32767,3.2767D1, G0000002 13H960711.075755,9.9973665264706D-9,9.9973665264706D0,10HC. Eastman, G0000003 8Hpersonal,6,0; G0000004 100 1 1 1 3 00000000D0000001 100 2 D0000002 108 3 1 1 3 00000000D0000003 108 2 1 D0000004 106 5 1 1 3 00010000D0000005 106 5 12 D0000006 100,0.000,4.9698262032692D0,4.7499999958091D0,3.6872903948943D0, 1P0000001 5.2243589702755D0,5.9290492707671D0,3.7754202693626D0; 1P0000002 108,1.0000000000000D0,1.0000000000000D0,1.0000000000000D0, 3P0000003 3.0000000000000D0,00000005,0.,0.,0.,0.; 3P0000004 106,2,5,7.4866291864961D-2,2.2734243109031D0,6.517093972319D-1, 5P0000005 -1.4687028842991D0,3.9879336363363D0,4.8076924796289D-1, 5P0000006 -2.3711110963092D0,3.1595726143533D0,2.2115384819559D0, 5P0000007 -4.3234341751093D-1,1.2849074958964D0,2.1474359216145D0, 5P0000008 7.4866291864961D-2,2.2734243109031D0,6.517093972319D-1; 5P0000009 S0000003G0000004D0000006P0000009 T0000001 Design & Engr. Databases
TIMELINE
Engineering analysis (ICES, MIT) GM and IBM begin DAC IGES ISO-STEP Calliographic Displays Storage tube displays Color Raster Displays Digital Equip. PDP-11 Internet created (ARPANET) Xerox Alto (first workstation) IBM Personal Computer Silicon Graphics (real-time surface display) Apple Mac II World Wide Web formed
1960
1970
1980
PC-based virtual reality Virtual Reality (SGI) PC solids modeling Wavefront formed (visualization) Autodesk formed
1990
2000
First 3D building model First solid modeler M&S Computing (Intergraph) formed Autotrol formed (overlay drafting) Computervision formed Sutherland's Sketchpad
Motivations for PDES and STEP

1. incorporate new programming language concepts, especially object-oriented programming 2. incorporate formal specifications of the structures defined, using the new recently developed data modeling languages 3. separate the data model from the physical file format 4. support subsets of a total model, allowing clusters of applications to be integrated without the overhead of having to deal with parts of a model irrelevant to a task 5. support alternative physical level implementations, including files, databases and knowledge-based systems 6. incorporate reference models that are common shared subsets of larger standard models
Structure of STEP Technologies
The STEP Parts structure
Mechanical
204-Boundary rep 205-Surface rep 206-Wireframe 213 Numerical control 222-Composite structures 223-Cast parts 224-Mech.features
Processes
231-Process-engr. 233-System engr. 235-Materials specificaiton 239-Life cycle support 240-Machined products
Electronic
211-P-C Assembly 212-Electro-mech. design
Automotive
214- Mech. design
Buildings
230-Structural_steel 225-Explicit_geom IFC 236-Furniture
Process Plant
221-Functional schema 227-physical layout
Ship Building
215-Arrangements 216-Molded forms 217-Piping 218 Structures 226-Ship mech.sys. 234-Ship logs
41- Prod. Descript (measures) 45- Materials
42- Geometry, topology 46- Presentation
43- Representation 47- Tolerances
44- Configuration 48- Form features
INTEGRATED APPLICATION RESOURCES

Product Model Development Issues:

1. In order to develop a product model, one needs to identify the data that each application uses separately (data model of each alone)
Application 1
Application 2
Product Model Development Issues:

2. For any exchange or integration, there must be some overlap
Application 1
Application 2
What is the extent of the product model; the common intersection, or a repository union? Is the data the same or derivable? Explicitly define the mapping between shared variables and relations. Design & Engr.
Databases
Six parts of STEP Technology

description methods: EXPRESS Language, NIAM and IDEF1x, EXPRESS-G integrated resources generic and application integrated resources: re-usable EXPRESS constructs implementation methods standard data access interface (SDAI)
application protocols Application Reference Model (ARM), defined in: NIAM, IDEF1x, or EXPRESS-G
Application Interpreted Model (AIM): in EXPRESS
physical file fomat or other implementation method (SPF)
DATA MODEL DEFINITION
conformance testing Testing methodology and suites
DATA MODEL USE Design & Engr. Databases





General STEP Implementation Architecture
NIAM, (ARM) IDEF1x, or EXPRESS-G models parser verifier AIC models
mapping tables
(AIM)
building application C or C++ interface ASCII data file maps between EXPRESS data and storage medium
storage medium
110000001101010101 010101000001010100 111100110000101010 101010101100101010 010101010000101111 000101010101100101 011100101010100101 01
EXPRESS model
General STEP Implementation Architecture
NIAM, (ARM) IDEF1x, or EXPRESS-G models parser verifier
mapping tables (AIM)
building application C or C++ interface ASCII data file
storage medium
110000001101010101 010101000001010100 111100110000101010 101010101100101010 010101010000101111 000101010101100101 011100101010100101 01
AIC models
EXPRESS model
maps between EXPRESS data and storage medium
What is a product model?
Example Application domains
structural design package
scheduling
fabrication
Product model schema
Each Product Model provides a set of information constructs that can carry information is its domain of discourse
How are product models organized?
SCHEMA
EXPRESS-G Language EXPRESS Language
Constructs: objects, processes, complex properties
Inheritance structures
Pre-defined Integrated Resource Libraries, in EXPRESS Language
Entities
Relations
Types
EXPRESS Language Overview (Roger Schenck)

1. SCHEMAS The unit of definition is called a SCHEMA. Unless noted otherwise, all names are global to a SCHEMA. There are special mechanisms to cross references across SCHEMAS, but this requires a special syntax in relation to references within the same SCHEMA. SCHEMAS will be defined in detail later. 2. NAMING In general, the convention is followed that all user defined names are lower case, while all reserved words are capitalized. Names may have embedded underbars(_) but no other special characters.
EXPRESS Language Overview (Base Types)

3. BASIC TYPES:
NUMBER, REAL, INTEGER, STRING, LOGICAL, BOOLEAN and BINARY. NUMBER is a generalization of INTEGER and REAL. STRING is a list of characters. LOGICAL can have the values (TRUE, FALSE, UNKNOWN) while BOOLEAN only has (TRUE,FALSE). BINARY is a vector on bit values. Basic types can be used to define higher level types, eg. TYPE area : REAL; TYPE name : STRING; Types also may be used to define attributes within higher level entities, eg. ENTITY part; surface_area : area; END_ENTITY; Design & Engr. Databases
EXPRESS Language Overview (Base Types)

Both STRING and BINARY are variable length vectors. They may have a length that is specified or not. When not specified, the length is variable. When a length is defined, up to that many may be assigned. When the length is specified and appended by FIXED, then all assignments must be of exactly this length. For example: s1 : STRING; s2 : STRING(10); s3 : STRING(10) FIXED; (* variable length string *) (* variable number up to 10 characters*) (* exactly 10 characters *)
Enumeration Types
EXPRESS also has an enumeration type, where the possible values are explicitly defined. For example: TYPE compass_direction = ENUMERATION OF (south, north, east, west ); END_TYPE;
EXPRESS Language Overview (Constructors)

4. CONSTRUCTORS In addition to single types, variables and higher level structures can be aggregated into larger groupings. This includes arrays, bags, lists and sets. They are presented in order. ARRAY is used to define a vector of elements of fixed size and these may be concatenated, eg.: matrix : ARRAY[1:4] OF ARRAY[1:4] OF REAL; Both the lower and upper bound must be defined in arrays. lower_bound < upper_bound. BAG is an unordered collection of. like elements. Its lower bound and upper bound may or may not be specified. If the lower bound is specified, there must be at least the lower bound n assigned. If the upper bound is assigned, this a the maximum number of elements. If the bounds are not defined, it is assumed that the bounds are [0:?]. As an example, bag_of_points : BAG[1:?] OF point; means that there must be at least one point in bag_of_points. LIST is an ordered collection of like elements, similar to the ARRAY, but LIST may be variable length. Thus: list_of_points : LIST[0:?] OF points; means that there may any number of points in the list, which remain ordered. Design & Engr. Databases
EXPRESS Language Overview (Select Types)

SET is an unordered collection of like elements. Duplicates are not allowed. SETs may be of fixed size or not. An example might be: set_of_names : SET OF [1:100] OF name; set_of_names must have a membership of at least 1 and not more than 100. 5. SELECT TYPES There is one other type definition, to define a type that may be selected from among a set of types, similar to a UNION type in C. EXPRESS calls this a SELECT TYPE. A SELECT type is a generalization of other types. Some examples follow: TYPE NUMBER = SELECT(REAL,INTEGER); END_TYPE; TYPE connection = SELECT(nail,screw,bolt); END_TYPE; In all cases, the elements of the set selected from must be types and already defined. Types may be used to define higher level types, so that a large number of types may be defined in terms of simpler ones. Notice that the limitation is that all higher level uses of a type have the same domain as the lower level ones, unless rules are used to constrain them. Design & Engr. Databases
EXPRESS-G
<type> <type> <type> <type> <entity>
(ABS)<entity>
: basic type : user defined type : a SELECT type : enumeration type : an ENTITY : ABSTRACT entity : a constrained element : entity from another schema
INV <attribute> (DER) <attribute> (UNIQUE) <attribute>[0:?]
subtype relation regular relation optional relation (ONEOF) constraint on subtype relation from - to inverted relation derived attribute UNIQUE attribute arity of attribute
*<element> <entity>
LEGEND
EXPRESS-G examples
NUMBER, REAL, INTEGER, STRING, LOGICAL, BOOLEAN and BINARY
NUMBER REAL area name INTEGER STRING BINARY
TYPE area : REAL; TYPE name : STRING;
REAL
STRING
surface_area ENTITY part; compass_direction part surface_area : area; orientation: OPTIONAL compass_direction; END_ENTITY;
TYPE compass_direction = ENUMERATION OF (south, north, east, west ); END_TYPE;
compass _direction
EXPRESS Language Overview (Entities)

6. ENTITIES The general object type, that allows definition of unlike elements, is called the ENTITY. The basic ENTITY definition has the format: No distinction between embedded entity and reference ENTITY point; to an entity x,y,z : coordinate; x ref_coord: cartesian_coordinate_system; coordinate END_ENTITY; y z TYPE coordinate: REAL; END_ENTITY; point ref_coord The point is composed of three attributes of type coordinate and a relation with cartesian_coordinate_system. cartesian_ coordinate_ ENTITYs can be inherited or specialized into other ENTITYs. For example: system Parents or children (or both) may define inheritance ENTITY homogeneous_point relations. (They must be consistent.) SUBTYPE OF (point); SUPERTYPE OF (colored_point); w : coordinate; END_ENTITY;
homogeneous _point
ENTITY colored_point w SUBTYPE OF (homogeneous_point); color : enumeration of (red, yellow, blue, green); END_ENTITY;
coordinate Design & Engr. Databases
EXPRESS Language Overview (Derived Attributes)

6.1 Derived Attributes In addition to explicit attributes, that are assigned values, EXPRESS supports Derived attributes. These are not explicitly loaded as data, but are computed at assignment time from other values carried within an ENTITY. A fairly complex example (not of my style but illustrative) follows. It includes entity constructs that we will get to eventually. Derived attributes are identified by DERIVE: center point ENTITY circle; center ; point; radius distance_ radius : distance_measure; circle measure axis : vector: DERIVE axis area : REAL := pi * radius ** 2; vector END_ENTITY; (DER) area TYPE distance_measure : REAL; Thus the attribute area can be accessed just like other attributes, but is computed when it is accessed. The default scope of attributes accessed within a DERIVE expression is the ENTITY in which the DERIVE expression is located (others can be accessed with paths.).
EXPRESS Language Overview (Constraints)
6.2 Domain Rules Restrictions on the possible values allowed for different attributes can be defined, using EXPRESS domain rules. These are a clause within the ENTITY specification, initiated by WHERE. An example WHERE might be: ENTITY unit_vector; a, b : REAL; c : OPTIONAL REAL; WHERE length1 : a**2 + b**2 + c**2 = 1.0; END_ENTITY; All domain rules, such as length1, are integrity constraints which carry a value of type LOGICAL. When accessed, it supposedly evaluates the expression and returns one of the values TRUE, FALSE or UNKNOWN. UNKNOWN is used when some attributes are missing. The OPTIONAL modifier on the c allows this value to optionally exist or not exist.
EXPRESS Language Overview (Relations)

6.3 Defining Many-to-Many Relations Most languages allow a user to define a relation in one direction, but not both. This makes the definition of many-to-many relations difficult. EXPRESS solves this problem by providing the INVERSE clause. We use the polygon example: ENTITY line; pt1 : point; pt2 : point; WHERE not_concident : (SELF\pt1.x<>SELF\pt2.x) OR (SELF\pt1.y<>SELF\pt2.y) OR (SELF\pt1.z<>SELF\pt2.z); INVERSE loops : SET [0:2] OF polygon FOR edges; END_ENTITY;
ENTITY closed_polygon; edges : LIST [2:?] OF lines; WHERE 2_connected : (* check that all of the line's endpoints are all two-connected *) END_ENTITY; Design & Engr. Databases
EXPRESS Language Overview (Inheritence Constraints)

7. SUPERTYPE CONSTRAINTS In the general case, when SUBTYPEs are defined of a SUPERTYPE, they may be responding to a variety of conditions. A person, for example may be specialized into male and female. In this case, it is not usually possible for an instance to be both of these types. On the other hand, a room may have SUBTYPEs of west_direct, east_directed, south_directed and north_directed. A particular room instance may be both east_directed and south_directed.
To make these different cases explicit, EXPRESS provides constraints for the SUBTYPE clause. They are: ONEOF -- defines that the following set of SUBTYPEs are mutually exclusive. An instance may be of only one SUBTYPE. AND -- defines that the following set of SUBTYPEs are always included in all instances of the SUPERTYPE. ANDOR -- defines that there is no rule and that the SUBTYPEs may be defined into instances or not.
EXPRESS Language Overview (Inheritence Constraints)

7. 1. SUPERTYPE CONSTRAINTS (Example) ENTITY power_part SUPERTYPE OF (ONEOF(fluid_powered,electrical_powered,powerless)); ... END_ENTITY; ENTITY handling_part SUPERTYPE OF (ONEOF(air_handling,liquid_handling,communication)); ... END_ENTITY; ENTITY mechanical_part SUPERTYPE OF (AND (power_part,handling_part)); ... END_ENTITY;
EXPRESS Language Overview (Example)

SCHEMA example; TYPE date = ARRAY [1:3] OF INTEGER; END_TYPE; FUNCTION years(d : date) : INTEGER; (* computes an age to the current date from d *) END_FUNCTION; TYPE hair_type = ENUMERATION OF (brown, black, blonde, redhead, gray, white, bald); END_TYPE; ENTITY female SUBTYPE OF (person); husband : OPTIONAL male; maiden_name : OPTIONAL STRING; WHERE WI : (exists(maiden_name) AND EXISTS(husband)) OR NOT EXISTS(maiden_name); END_ENTITY;
ENTITY male; SUBTYPE OF (person); wife : OPTIONAL female; END_ENTITY;

END_SCHEMA;
ENTITY person SUPERTYPE OF (ONEOF(male, female)); first_name : STRING; last_name : STRING; nickname : OPTIONAL STRING; birth_date : date; children : SET [0 : ?] OF person; DERIVE age : INTEGER := years(birth_date); INVERSE parents : SET [0 : 2] OF person FOR children; END_ENTITY;
EXPRESS-G (Family Model)

hair_color children s[0:?] INV parents s[0:2] birth_date first_name person last_name nickname (DER) age (ONEOF) *husband *male *wife *female *maiden_name *INTEGER STRING date hair_type array[1:3] INTEGER
STRING

Motivations and Standards for CAD Data Exchange

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Motivations and Standards for CAD Data Exchange

Transféré par

Droits d'auteur :

Formats disponibles

Motivations for CAD Data Exchange Standards

Design & Engr. Databases

Exchange Technology at the Time A structured file format

Provide aggregation types to define complex parts

Design & Engr. Databases

Initial Efforts at Data Eexchange Standards

Design & Engr. Databases

Motivations for PDES and STEP

Structure of STEP Technologies

The STEP Parts structure

Design & Engr. Databases

41- Prod. Descript (measures) 45- Materials

42- Geometry, topology 46- Presentation

43- Representation 47- Tolerances

44- Configuration 48- Form features

INTEGRATED APPLICATION RESOURCES

Product Model Development Issues:

Design & Engr. Databases

Product Model Development Issues:

Six parts of STEP Technology

Application Interpreted Model (AIM): in EXPRESS

physical file fomat or other implementation method (SPF)

DATA MODEL DEFINITION

conformance testing Testing methodology and suites

DATA MODEL USE Design & Engr. Databases

Six parts of STEP Technology

Application Interpreted Model (AIM): in EXPRESS

physical file fomat or other implementation method (SPF)

DATA MODEL DEFINITION

conformance testing Testing methodology and suites

DATA MODEL USE Design & Engr. Databases

Six parts of STEP Technology

Application Interpreted Model (AIM): in EXPRESS

physical file fomat or other implementation method (SPF)

DATA MODEL DEFINITION

conformance testing Testing methodology and suites

DATA MODEL USE Design & Engr. Databases

Six parts of STEP Technology

Application Interpreted Model (AIM): in EXPRESS

physical file fomat or other implementation method (SPF)

DATA MODEL DEFINITION

conformance testing Testing methodology and suites

DATA MODEL USE Design & Engr. Databases

Six parts of STEP Technology

Application Interpreted Model (AIM): in EXPRESS

physical file fomat or other implementation method (SPF)

DATA MODEL DEFINITION

conformance testing Testing methodology and suites

DATA MODEL USE Design & Engr. Databases

Six parts of STEP Technology

Application Interpreted Model (AIM): in EXPRESS

physical file fomat or other implementation method (SPF)

DATA MODEL DEFINITION

conformance testing Testing methodology and suites

DATA MODEL USE Design & Engr. Databases

General STEP Implementation Architecture

NIAM, (ARM) IDEF1x, or EXPRESS-G models parser verifier AIC models

Design & Engr. Databases

General STEP Implementation Architecture

NIAM, (ARM) IDEF1x, or EXPRESS-G models parser verifier

mapping tables (AIM)

building application C or C++ interface ASCII data file