A Shape Modeling API for STEP Michael J. Pratt, NIST

1
A Shape Modeling API for STEP Michael J.
Pratt, NIST

• Manufacturing DTF, OMG TC Meeting, Philadelphia,
  23 March 1999

2
Overview

• Brief introduction to the STEP standard
• Shape modeling in STEP
• Deficiencies of STEP shape models
• Two approaches to improvement of STEP
• Procedural or history-based shape modeling
• The Parametrics shape modeling API

3
ISO 10303 (STEP)

• An international standard for the exchange of
  product data in electronic form.
• A large and rapidly expanding standard first
  parts released 1994, currently 20 parts.
• Covers a wide range of product types and product
  life-cycle stages.
• Suitable for file exchange or database sharing.

4
Structure of STEP

• Implementable parts of STEP are Application
  Protocols (200-series parts)
• These are based on specializations of a unified
  set of Integrated Resources (40- and 100-series
  parts)
• All data schemas are written in EXPRESS (Part
  11)
• EXPRESS is not object-oriented, but it has some
  key characteristics of object orientation, e.g.
  inheritance

5
Some key STEP IR parts and schemas(incomplete)

• Part 43 Representation structures
• representation_schema

• Part 41 Fundamentals of product description and
  support
• application_context_schema
• product_definition_schema
• product_property_definition_schema
• product_property_representation_schema
• measure schema

• Part 44 Product structure configuration
• product_structure_schema

• Part 42 Geometric and topological representation
  
• geometry_schema
• topology_schema
• geometric_model_schema

• Part 45 Materials
• material_property_definition_schema
• material_property_represenation_schema
• qualified_measure_schema

6
Current Application Protocols

• AP201 Explicit draughting
• AP202 Associative draughting
• AP203 Configuration controlled design
• AP207 Sheet metal die planning and
  design
• AP224 - Mechanical product definition for process
  planning using machining features
• Many more in development, covering different
  life-cycle aspects of a variety of product types

7
Shape Models in STEP

• Wireframe models
• Surface models
• Solid models (B-rep)
• faceted
• simple
• advanced

All are expressed in terms of geometry and (in
some cases) topology.
8
representation
Part 41 product_property_definition_schema
property_definition
A representation is a collection of
representation_items that are related in a
specific representation_context. Representation
is subtyped in APs to tailor it to specific
usages.
Part 41 product_property_representation_schema
Part 43 representation_schema
Part 42 geometry_schema
Part 45 qualified_measure_schema
9
representation_context
Example where ANDOR is useful
geometric_ representation_context
10
Association of geometry
shape_representation a kind of representation
that represents a shape.
11
Overview of the geometry_schema (1)

• Points and directions
• Placements
• Cartesian transformations
• unbounded curves
• line
• conic
• offset curves
• bounded curves
• polyline
• trimmed_curve
• b_spline_curve
• composite_curve

12
Overview of the geometry_schema (2)

• unbounded surfaces
• plane
• conical_surface
• cylindrical_surface
• spherical_surface
• toroidal_surface
• bounded surfaces
• rectangular_trimmed_surface
• curve_bounded_surface
• b_spline_surface
• rectangular_composite_surface

13
Concepts of the geometric_model_schema

• Resource for the description of the shape and
  position of three-dimensional solid objects.
• Includes
• B-rep
• Sweeps as extrusions and revolutions
• Constructive solid geometry (CSG), using Boolean
  operations (union, intersection, difference)
• Boolean operands may include CSG primitives,
  B-reps and swept volumes
• Incomplete shape models such as wireframes and
  geometric sets can also be represented

14
Overview of the geometric_model_schema (1)

• CSG primitives
• sphere
• block
• right_angular_wedge
• torus
• right_angular_cone
• right_circular_cylinder
• half_space_solid
• Boolean operands
• union
• intersection
• difference
• Boolean results

15
Overview of the geometric_model_schema (2)

• Manifold solid b-reps
• Sweeps
• solids of linear extrusion
• solids of revolution
• swept areas (without topology) and swept faces
  (with topology)
• Aggregations of loose geometry
• shells
• wireframes
• geometric sets consisting of points, curves and
  surfaces

16
Product structure from part 44

• Product_structure_schema
• focuses on a definition of product structure as a
  hierarchical multilevel decomposition into
  constituents and subconstituents.
• This needs to be supplemented by further
  information on inter-part liaisons, kinematic
  degrees of freedom, tolerance data etc. A new
  resource for this purpose is under development

17
Static and Dynamic Models

• Current STEP shape models are static,
  representing snapshots of a product at some
  moment in time.
• Static models are hard to edit following a model
  transfer they carry no design intent.
• Modern CAD systems generate models with some
  dynamic behaviour this prescribes the way they
  act when modified.
• Currently, the dynamic information gets lost in a
  STEP transfer.

18
Extensions to STEP

• ISO TC184/ SC4/ WG12 Parametrics group working to
  extend STEP to handle dynamic models
• ISO standardization process is inherently slow,
  but hope to have first extensions in place by
  Year 2001
• The enhanced assembly modeling work mentioned
  earlier is based in the same group

19
Two Types of Dynamic Models

• Explicit (STEP-type) models, augmented by
  additional information
• parametrization
• geometric constraints
• features
• Procedural or history-based models

Many native CAD models are hybrids
20
Augmented Explicit Model

• B-rep model supplemented by
• parametrized dimensions
• allows family-of-parts definition
• dimensions may be made to depend on other,
  non-geometric, parameters
• geometric constraints between constructional
  elements
• parallelism
• perpendicularity
• tangency,
• symmetry, etc.
• Features (with parametrization constraints)
• Sometimes called a variational model

21
Parametrization and Constraints

• Parametrization expresses design freedom - what
  can be changed for design optimization

• Constraints express design restraint - what must
  remain fixed to preserve design functionality

Both types of information specify behavior in the
receiving system. STEP cannot currently capture
either of them
22
Editing with Design Intent
Fixed vertical dimensions, free horizontal, fixed
angles
23
Editing without Design Intent
Connectivity conserved, no other constraints
24
New STEP Resource (1)

• Mechanism for associating parameters with model
  dimensions and other quantities
• Allows for capture of mathematical relations
  between parameters
• Mechanism for associating geometric constraints
  with elements of explicit model
• Well advanced scheduled for IS by year 2001

25
History-based Models (1)

• Defined as sequences of constructional operations
• In the purest approach, no explicit faces, edges,
  vertices
• Hybrid models (supported by most CAD systems) may
  also involve explicit entities
• e.g. (procedural) sweep operation on explicitly
  defined 2D profile

26
History-based Models (2)

• Currently, STEP appears to provide a limited
  history- based modeling capability
• constructive solid geometry (CSG)
• swept shapes
• offsets
• The STEP list omits many procedural capabilities
  of modern CAD systems
• Current STEP definitions are really descriptive,
  not procedural they carry no behavioral
  semantics

27
History-based Models (3)

• Limitations of STEP for representing
  history-based models gt
• Need to define a standardized set of
  constructional operations
• Also need standardized query operations
• Implication requirement for a complete
  standardized API in STEP

28
History-based Models (4)

• Exchange of history-based model may help to
  overcome the geometric accuracy problem
  currently encountered in STEP exchanges
• Model is regenerated in the receiving system from
  constructional history, which is less subject to
  inaccuracy than a current STEP file
• It is thought that history-based representations
  may also provide a stable form of archival
  storage for CAD models

29
Technical Challenges in History-based Model
Representation

• Design of standardized API
• Persistent naming
• Indirect references

30
Design of Standardized API (1)

• Granularity problem high-level vs.
  low-level constructional operations
• Interface style entity-based vs.
  procedure-based approach
• Survey of existing proposals already complete
• ISO 13584-31 (Parts Library Geometric Programming
  Interface)
• CAM-I Applications Interface Specification (AIS)
• OLE for Design and Modeling
• university and other less formal proposals...

31
Design of Standardized API (2)

• Existing proposals surveyed in document N106 from
  ISO TC184/SC4/WG12
• CAM-I AIS is closest fit to STEP requirements
• object-oriented
• based on STEP Part 42 conceptual model
• constructional and query operations
• procedure-based rather than entity-based approach
  (in conformance with recommendations in ISO/IEC
  directives for standardized APIs)
• needs extension to handle parametrization,
  geometric constraints and features

32
Design of Standardized API (3)

• The CAM-I AIS was designed as a general-purpose
  interface to a geometric modeling (CAD) system,
  allowing standardized linking of application
  systems and two-way information transfer in
  conversational mode
• The STEP requirement for the exchange of
  history-based shape models leads to an interface
  with almost identical characteristics. The STEP
  API will therefore serve a wide variety of
  purposes beyond pure data exchange.

33
CAM-I Applications Interface Specification (1)

• Defined in CAM-I report R-94-PM-01
• Has spent period as ANSI Draft Standard for Trial
  Use, and been updated following user feedback
• Language-independent version and C binding are
  provided

34
CAM-I Applications Interface Specification (2)

• STEP Part 42 entities treated as objects
• Part 42 inheritance properties utilized
• Methods defined upon geometrical, topological and
  geometric_model objects
• Needs extension to cover parametrization,
  constraint and feature entities being defined in
  Parametrics extensions of STEP

35
STEP Parametrics API Specification

• Will provide superset of AIS capabilities
• Major work not yet started, but decision has been
  taken on manner of specification of the methods
  provided
• Language-independent representation of these will
  be in the form of EXPRESS function headers, to
  conform with existing STEP representations. This
  happens to make the language-independent forms
  look like C functions, but that is coincidental

36
STEP API Specification Examples (1)

• line_create_2points (P1,P2)
• input P1,P2 point identifiers
• output identifier of unbounded line
• cylinder_create (A,H,R)
• input A axis-placement identifier, H,R real
  numbers
• output identifier of new cylinder solid

37
STEP API Specification Examples (2)

• fillet_solid_model_fixedradius (S,E,R)
• input S a solid model identifier, E a set of
  edges of the model, R real number (fillet
  radius)
• output modified solid model with rounded edges
• Face_enquire_vertices (F)
• input F face identifier
• output list of vertices of specified face

38
Persistent Naming (1)

• Probably the most difficult problem most CAD
  vendors only have partial solutions
• Topic not addressed in any previous interface
  proposals
• Survey of published proposals by Hoffmann,
  Kripac, Shapiro etc. (in progress)

39
Persistent Naming (2)

• Essential nature of problem CAD system has to
  identify corresponding elements in original and
  edited model to ensure intuitive behavior
• the elements concerned are often those picked
  from the CAD screen by the designer
• most systems delete the original explicit model,
  edit the history model and generate a new
  explicit model
• correspondences between old and new model
  elements are needed to ensure that edits have the
  expected results. They are sometimes hard to
  establish, especially when topology changes occur

40
Persistent Naming (3)
MASTER
GUI
Generate
History model
Display model
Edit
Regenerate
Revised history model
Revised display model
STEP currently transfers the display model. The
basic history model provides no references to its
constituents.
41
Persistent Naming (4) Example
System has mis-identified edge to be rounded
after edit
42
Indirect References

• A generalization of the persistent naming problem
• We need to be able to reference
• elements of parts defined in a parts library
• elements of instanced parts or assemblies
• elements used as datums in part construction but
  which have possibly been deleted by subsequent
  modeling operations

43
Indirect reference example
Dimensional constraint
Constraint applied between points that are then
deleted
44
New STEP Resource (2)

• Object-oriented API for history-based modeling
• Mechanism for persistent naming and indirect
  referencing
• Interoperable with STEP explicit modeling
  capability
• Work currently at an early stage aiming for
  completion by Year 2002

45
Features

• Some STEP APs define application features
• No basic STEP resource for feature definition,
  however
• Features should be defined using parametrization
  and constraints
• Work on a new STEP features resource will start
  when parametrization/constraint capability
  complete

46
Conclusions

• ISO TC184/SC4/WG12 Parametrics Group is extending
  STEP for the exchange of dynamic models
• aiming to standardize parametrization and
  geometric constraints for explicit models by 2001
• aiming to standardize history-based API by 2002
• assembly representation is also being enhanced
• work on features will start shortly
• The API for construction history will also serve
  as a general-purpose API for interfacing
  application programs to CAD modeling systems

47
Acknowledgement

• Wolfgang Haas, of Haaspartner, Germany, for some
  basic STEP material