Visit our web page

1

• A CAD Data Exchange leading company
• Christian Caillet April 2006
• christian.caillet_at_datakit.com

2
DATAKIT the COMPANY1994 - 2006

• 12 years of experience in Data Exchange
• Datakit CAD Data Exchange
• Data conversion between CAD native and standard
  formats
• Development distribution of libraries,
  translators, plug-ins
• 140 translation products, regularly maintained
  and extended
• References in various industrial domains
• Quality Check and Shape Healing
• Worldwide distribution of TransXpert, a product
  by Coretech a powerful tool for CAD data
  healing and customization
• Partnership with OpenCascade to support their
  data exchanges (STEP, Catia V5 ..)

3
Data Exchange withina domain (ex. 3D CAD)

• Several companies, several softwares
• Several formats and types for data
• Several proprietary data formats
• Standards none, one or several
• gt various file formats, various data types
• Existing interfaces produce standard files with
   dialect 
• To exchange between 2 softwares needs to check
• Does the available standard cover the involved
  data types
• Do the both interfaces comply with this coverage
• Otherwise, can we define a (direct) mapping
  between them
• And are there available libraries for data
  accesses
• Otherwise, need for direct access to data files

4
Data Exchange withina domain (ex. 3D CAD)

• The ideal world one standard covers all the
  needs

One common way for any couple - complete
coverage - up-to-date data standard - all
data can be converted
System 1
Standard
System 2
System 3
5
Data Exchange withina domain (ex. 3D CAD)

• The real world several ways, no best one

Several ways, depends on use case - coverage
of data types is variable - availability of
system or interface module to produce file
or read it - data formats evolve in time
(mostly the proprietary files)
System 1
Standard 1
Extension
System 2
Standard 2
System 3
6
Data Exchange withina domain (ex. 3D CAD)

• How to address these concerns
• Rely on common definitions (data types) whenever
  possible
• Complete with specific ones as needed
• gt in order to establish mapping rules based on
  data types
• Exchange between 2 softwares needs to check
• Does the available standard cover the involved
  data types
• Do the both interfaces comply with this coverage
• Otherwise, can we define a (direct) mapping
  between them
• And are there available libraries for data
  accesses
• Otherwise, need for direct access to data files
• gt a constant effort to keep level of last
  versions (of software, of standards), to maximize
  factorization

7
Interoperability betweendomains (ex. 3D CAD,
FEA)

• The problem is similar to the previous one,
• But in an harder form
• Data models and definition rules are different
• gt they are often very specific
• No common standard, need to convert between
  standards too
• Conversion rules often apply, some can be
  automatized, some other cannot (need an
  interactive application)
• Some involvements
• Standards help, by factorizing efforts, but are
  not complete
• Also, following design rules helps automatic
  conversions, but common rules for several domains
  are not easy to define
• BEWARE of data update management

8
Interoperability betweendomains (ex. 3D CAD,
FEA)

• Conversion between data models (types,
  organization)
• Can need interpretation or re-modelling
• Can need simplification (idealization)
• As many times as they are depending models, even
  close
• Some cases can be automatized, others need user
  interaction
• Can be helped by high level data types not
  always available, often not supported by
  standards
• gt constraint for data update management
• Preparation of CAD model for downwards uses
• Not always supported (specially for several uses)
• Mostly not supported by common standards
• () Following rules helps automatic conversions

9
Interoperability betweendomains (ex. 3D CAD,
FEA)

• General concerns are
• Completeness of standards, including their
  implementation for all the involved software
  systems
• Need for direct access for data which fall out of
  standards
• Between domains, constraint of unique source
  model with automatic extraction
• If not possible (often the case), conversion
  process (automatic or interactive) and data
  management
• Standards a help but not a complete solution
• When applicable, they also help archiving
• Provided that upward compatibility is supported
• Otherwise, evolution of a standard means yet
  another conversion

10
DATAKIT Involvements in Data Exchange

• Tools for technical data exchanges ready for
  use
• Between native and/or standard files and models
• Data mappings, algorithmic conversions
• Can be used as stand-alone tools or plug-in
  libraries
• gt actually 140 exchange solutions available
• gt in various domains such as Drawing, 3D CAD
  (geometry, history), Metrology, Machining, View
  meshed models, etc.
• Expertise in data exchanges
• Knowledge and experience in issues and solutions
• Continuous follow-up of existing data models and
  evolutions
• Commitment in the STEP standards (participation
  in forums ..)
• .../...

11
DATAKIT Involvements in Data Exchange

• Some guidelines (indicative)
• Think modular, for easier reuse, update and
  extension
• Firstly rely on data types and organization (data
  models)
• In a given domain, which standard(s) can apply
• Which definitions (added to standards) can be
  factorized
• Rules for data mapping and use of algorithms
• File access libraries as available, or reverse
  engineering
• RD effort (with partnerships) among actual
  topics,
• Shape healing and customization (Trans-Xpert by
  Coretech)
• Tracing of model evolution
• High level data conversion (features, dimensions
  ..) data dictionary, conversion rules between
  features

12
..

• Thank you for your attention
• christian.caillet_at_datakit.com
• our web site http//www.datakit.com