LOTAR 101 – A Project Overview

Overview of LOng Term

Archival & Retrieval (LOTAR)
of digital product & technical
data

AEROSPACE INDUSTRIES
ASSOCIATION
 LOTAR Project on a page
The 4 areas
addressed by
LOTAR…
 Project History

With the onset of Model Based Definition (MBD) development in January 1997, Rick Zuray, a member
from the team was tasked to evaluate and develop a process to address the storage, retention and
retrieval of 3D Product Definition produced by MBD methodologies.
September 1998 an internal process was developed and accepted by the Certificate Management and
the Aircraft Certification Offices of the FAA. The FAA requested that Rick Zuray meet with the
Aerospace Industries Association (AIA) and charter a project to write a standard that to address the
storage, retention and retrieval of 3D Product Definition Data that would be applicable to all civil
aviation across America. The AIA Project was chartered under the Civil Aviation Council (CAC) under
the Manufacturing Maintenance & Repair Committee (MMRC) in May 2000. The AIA team was formed
and held it’s first meeting in August 2000. The AIA Standard was completed and released as ARP-9034
in Sept 2002.

Polyline RP
Released
Aug 2000 Dec 2002 Jun 08
Jan AIA Team IAQG Pilot Activity Jan 2009 Dec 2010
1997 Formed Charter Oct 07 – May 08 Pilot Activity w/NIST, DS, PTC, UGS
Standards
Development Part 120V2 & Part 125V1

Sept Sept 2002 Sept 2004 Dec 2007 Jun 2008 Coord with other Industries AIAG,
1998 ARP-9034 EN9300-Part AIA-ASD Stan AIA-EIDS, Nuclear, NIST, etc.
002 Released LOTAR MoU NAS/EN9300-Part 2,
Released
5 ,7, 100, 110, 115
Ballot
 Project History

In October 2002 at the International Aerospace Quality Group (IAQG) meeting in Cincinnati OH, Rick was
asked to work with Jean-Yves Delaunay and the European LOTAR effort that was being worked under
the AECMA-Stan organization at the time and together develop a single set of harmonized standards
that addressed the storage, retention and retrieval of 3D Product Definition Data across the entire
Aerospace Industry. The Team was chartered in Dec 2002 and was Co-chaired by Rick Zuray , from
Boeing and Jean-Yves Delaunay, from Airbus. The International team meets 5 times a year and has
developed several parts to the base Standard which will be released under the name EN9300-Part-xx for
Europe and NAS 9300-Part-xx for Americas. The standards will be the same context just published
under AIA for the Americas and ASD-Stan for Europe for revenue purposes. The standards will be
eventually adopted by ISO under a cover sheet. In 2005 AECMA-Stan was changed to ASD-Stan but the
processes and documentation practices remain the same. In 2nd quarter 2008 Parts 2, 5, 7, 100, 110 and
115 was sent out for ballot and Part 120 v1 will be ready for ballot in Apr 2009.
Polyline RP
Released
Aug 2000 Dec 2002 Jun 08
Jan AIA Team IAQG Pilot Activity Oct 2008 Sep 2009
1997 Formed Charter Oct 07 – May 08 Pilot Activity w/NIST, DS, PTC, UGS
Standards
Development Part 120V2 & Part 125V1

Sept Sept 2002 Sept 2004 Dec 2007 Jun 2008 Coord with other Industries AIAG,
1998 ARP-9034 EN9300-Part AIA-ASD Stan AIA-EIDS, Nuclear, NIST, etc.
002 Released LOTAR MoU NAS/EN9300-Part 2,
Released
5 ,7, 100, 110, 115
Ballot
 Harmonization at the regional and International levels
between Aerospace Manufacturers and PLM interoperability
IAQG ISO TC20
Existing Planned (>2009)

LOTAR International
International

Aerospace
regional
AIA LOTAR ASD Stan
association
LOTAR International LOTAR
Website
(Collaboration)
Regional
PLM
interoperability PDES Inc ProSTEP iViP
regional LTDR LOTAR
association CAX Implem. Forum

PDM Implem. Forum

Participating Companies and Regulatory Agencies
Supporting LOTAR

Space
Division

KC Plant
 Harmonization at the regional and International levels
between Aerospace Manufacturers and PLM interoperability

IAQG ISO TC20

Existing Planned (>2008?)
LOTAR International

NAS9300-xxx Standards
9300-series EN9300-xxx
9300-001 Doc Structure 9300-010 Common Process 9300-100 CAD LTA Fund

AIA 9300-002 Bus/Proc Reqs 9300-011 Data Preparation 9300-110 Explicit Geom ASD Stan
LOTAR 9300-003

9300-004
Fund & Concepts

Description Methods
9300-012

9300-013
Ingest

Archival Storage
9300-115

9300-120
Explicit Assy

Exp Geo & GDT LOTAR

9300-005 Authent & Verif 9300-014 Retrieval 9300-125 Exp Assy & GDT

9300-006 Fund Architecture 9300-015 Removal 9300-130 Parametric Geo

9300-007 Terms & References 9300-016 Test Suites 9300-135 Parametric Assy

9300-017 Audits

9300-200 PDM series 9300-300 Config Mech PS 9300-400 Electrical

9300-201 xx 9300-301 xx 9300-401 xx

PDES Inc ProSTEP iViP

LTDR LOTAR
CAX Implem. Forum

PDM Implem. Forum

 LOTAR Objectives
Product Definition Data (PDD) creation, storage and distribution has significantly changed in the past
50 years. PDD is the source for “Type Design” as defined by the FAA.

Generation 1 Generation 2 Generation 3

The first generation (2D only: 2D Authority) (2D and 3D: 2D Authority) (3D Only: 3D Authority) The third generation
methods for PDD method is based on
creation were 2D 3D the use of
2D
manual board 2D parametric and
drawings with relational design in
design engineers 3D Model Base
and manufacturing Data. The PDD
engineers. This information is
evolved into a 2D defined only in 3D
CAD design method models that contain
which allowed the 3D associative GD&T
digital creation of and annotation to
2D drawing (without effectively replace
a 3D model) The 2D the need for a 2D
Drawing is the Model Based Design drawing
authority. (MBD) representation. The
3D Model is the
The second generation methods of PDD creation used only CAD authority but low
design methods which was based on use of 3D models and end visualization is
output was both 2D models (drawings) and 3D CAD dataset to require to support
drive CAM/CAI. The 2D Drawing was the authority for most various end usages
factory usage with the exception of CAM/CAI. – thus U3D.
 LOTAR Objectives
• For Digital Data, the challenge is that the data is often stored
in a proprietary, native format and will most likely be un-
interpretable over time. The use of a neutral archiving format
safeguards the interpretability of the data for a much longer
period of time, perhaps it’s entire retention period.
•
Archiving data in it’s native form requires periodic migration to
the new release (version) and this method quite often leads to
data loss and the repair can be costly. A typical technological
obsolescence cycle of a CAD generation roll (i.e. CATIA V4 –
V5) is 3 – 5 years.
•
Neutral forms make it easier to migrate the data based on the
way that the Application Protocols (AP)s are structured. In
addition, their life expectancy (obsolescence cycle) is
significantly longer in duration.
 LOTAR Requirements

• Digital archives mandate that we capture and

preserve information in such a way that the
information can be accessed and presented
at any time in the future.

• An obvious challenge for archives of digital

information is the limited storage lifetimes due
to physical media decay.

• Rest of the LOTAR requirements are

Documented in EN/NAS 9300-Part002
The Simple Solution
 Requirements

• However, since hardware and software

technologies evolve rapidly and much faster
than the media decay, the real challenge lies
in the technological obsolescence of the
infrastructure that is used to access and
present the archived information
 Requirements

• The obsolescence of storage technology (e.g.

magnetic tape) is a significant risk that must be
continuously addressed.
• Inevitably, storage systems will be replaced, and
data integrity must be ensured.
• Define criteria and conditions for transferring
data from an existing electronic data storage
system when a new data storage system is
implemented.
 Requirements

• To achieve the goal of re-instantiating archived

information on a future platform, it is not
sufficient to merely copy data at the bit level
from obsolete to current media but to create
“recoverable” archival representations that are
infrastructure in-dependent, i.e. open and
neutral, to the largest extent possible. Inevitably,
storage systems will be replaced, and data
integrity must be ensured.
 Requirements
• Data retention processes are managed and
validated.
• Media Migration
• Data representation migration & translation
• Incorporating data into repository
• Accessing the data by users.
• Interpreting Engineering/Design Intent, Assembly
Product Structure, and Instance Location/Orientation.
• Understand the effects of technology change and its
impact on the data and repository systems. (i.e. Life
Cycle Information Planning).
 Life Cycle Information Planning
• Each responsible company needs to ask the
following questions in order to optimize and
standardize their data retention process.
• Why are we archiving the data?
• Business Requirement
• Regulatory Requirement
• Organizational Requirement
 Life Cycle Information Planning
Life Cycle Information Planning

• What information should we archive?

• What is the configuration of the information?
• What is the information context?
• What is the format of the information and what
form does it need to be stored in?
• How long do we need to keep the data?
• How frequently do we need to access the data?
“Life Cycle Information Planning asks the question, how do
we retain our product knowledge throughout the life of the
product?”
 Presentation - Representation
• The essential requirements for the presentation
of 3D Geometry with associated GD&T that have
to be preserved in an OPEN format must enable:
• Preservation of all the presentation properties of
GD&T and specified annotation
• Filtering with annotation plans
• Ensure the bi-directional associativity between
3D Geometry and GD&T with specified
annotation.
• The LOTAR team is recommending the use of
STandard the Exchange Product model data
(STEP) as the OPEN and stable neutral format
to store of geometric and technical data
representations
 Presentation - Representation
• To preserve the exact presentation of 3D with GD&T
“as annotation”
• (e.g., annotation plane, position of the GD&T, size
and colors of GD&T
• To preserve the text and figures of GD&T and
annotation as text and figures
• To preserve the associativity between;
• “GD&T”, 3D topology & shape representation and
tree structure listing the GD&T
• To preserve associated validation properties,
ensuring end to end quality assurance of the data.
 Product Data Lifecycle
The Lifecycle of software & hardware is relatively short compared to the
lifecycle of an aircraft. Currently, for CAD S/W versions roll between 6 &
12 months with generations ranging from 3-7 years. This is compared to
an aircraft lifecycle of 70+ years
Preservation Planning
Ingest

Repository

Access
Administration
Data Retention and Archive Model
Data Retention and Archive Model
• The following three categories distinguish retention
periods of data:
Short Term: This time frame is within one or two
version rolls (i.e. Catia V5 R12 – R13; UGS NX3-
NX4)

Medium Term: This time frame is within one

generation roll (i.e. Catia V4 – V5; UG 18 – NX1)

Long Term: This time frame is over multiple

generations (i.e. Catia V3 – V7; UG 16 – NX7)
 LOTAR Nomenclature
The use of CAD 3D mechanical information results in new risks for long term
archiving, quite different from those encountered in the past for 2D drawings.
The EN9300 standard defines rules and principles to be applied by the
manufacturers. It defines, where possible, a mandatory a set of verification
rules for the CAD model, based on an open international format, and it defines
also validation properties to be created during the ingestion and to be checked
during the retrieval process (See part EN9300-005).
For CAD information, these verification and validation rules are in most cases
based on thresholds, the values of which are not fixed in the standard, since
the results are subject to numerical errors in the algorithms of the CAD
applications. The EN 9300-100 standard identifies the point where it may be
adapted by each manufacturer, according to its own specific processes and
products. It is the responsibility of the manufacturer to document and apply
the principles, with the appropriate thresholds, according to an analysis based
on risk management, as illustrated in figure 6.
 LOTAR Nomenclature
Legal Requirements Business Requirements

Certification Product Liability Suppt in Operation Design Reuse Other

Functions to be supported after retrieval Use Cases (UC)

Risk Management UC1 UC2 UC3 UC4 UCn

Tolerance Tolerance CAD Data

Thresholds Thresholds Associated
Essential
Validation
Information to be
Report
Set of Set of Preserved (i.e.
Validation Verification Geometry,
Properties Rules Tolerance &
Associated
1) Mandatory: 1) Mandatory: annotation,
Verification
2) Optional: 2) Optional: technical data etc.
Report

9300-
Part xx
Open Archive Information System Model
Data Retention and Archive model as defined by the LOng
Term Archival & Retrieval of digital product & technical
data (LOTAR) project co-led by Boeing and Airbus
The Open Archive Information System (OAIS) model defines the processes and actors which ingest the data into an
archive, and which provide services to consumers of the data, including both query and retrieval. The most subtle
area, and possibly the least understood, is the construction of the web of information needed to correctly read the
data once it has been retrieved.

The LOTAR standard uses the OAIS reference model as a basic framework, providing specific guidance on
specialized types of data; initially Mechanical CAD/CAM/CAI and non-geometric meta data. The problem here is not
to be sure that the data comes in and out correctly, but that it is being correctly interpreted by the new generation
of software. That is, if information is data in context, and the context is the application which interprets the data,
then LOTAR looks at information retention. In short, how do we know that the design we look at in twenty years
time is the same as the design we look at in our current system?

LOTAR makes the assumption that we know what we need to archive. Lifecycle Information Planning asks the
question, "how do we retain our product knowledge (i.e. Design Intent) throughout the life of the product?" This is
wider than the OAIS question, "what do we need to be able to understand this particular package of data?", rather
asks "what data about a product should we keep?" Although the answer starts with obvious elements such as the
design and the configuration, it soon gets into areas such as the preservation of design rationale, the processes by
which the product was designed, and the organizational structures that enable those processes to operate.
Open Archive Information System Model
Requirements
Functional Integration
Product Definition
Bill of Material
Build Definition
Support Definition
Simulations & Analysis
Additional Data
types Product Data Lifecycle Management
Preservation Planning
Producer Descriptive
Info Data
Descriptive
Info Queries
Results
Management sets
Ingest Access
Archival Orders
Storage

Administration
Consumer
Based on: Other
ISO 14721 “Open Archival Information System”
System” Reference Model
Customers
Customer Support
Finance
Regulatory Agencies
Inspectors
Mechanics
Suppliers (Internal/External)
 High Level Data Flow
(Proposed Implementation)

Preservation Planning
Remove per
Data Data Archival Data Retention
Preparation Ingest Storage Retrieval
Period

Administration
Producer

Data
Preparation
Consumer

SIP Data
Usage

DIP
Data Data
AIP
Ingest AIP
Retrieval
Remove
Archive

Archival
Storage per Ret.
Period
Ingest of
AIP
pre-existing AIP
data

SIP = Submission Information Package AIP = Archival Information Package DIP = Dissemination Information Package
 Lower Level Data Flow

Start
Data Prep
Data Preparation flow Start
Ingest

Error
handling for
Data Prep
Create
Descriptive
DC Info (DI)
Manual
Create VP
N
Auto
Producer

Initiate Create
Select data Create
data Preservation
for validation
Quality Data Info
archiving properties
process (PDI)
Y|N
Y
Auto
Create VP

Create
SIP
Quality
Data

Data
verification
& validation

SIP = Submission Information Package AIP = Archival Information Package = Dissemination Information Package DC = Data Content
DIP
 Data Retention and Archive Model
Sean Barker - BAE

Digital Signature
Retention – Archiving
Auditable model
Implicit
Invariance Not Required

LONG TERM ARCHIVAL

Legal Reqs Preserve Original
Keep Data Available
RETENTION

Business Reqs
Preserve Source
Reuse
Objectives
Short Term
Medium Term
Retention Period Long Term

Detail Level Accurate

Approximate
Native Representation Representation
Derived Representation
Format Presentation
Stored Form Standardized Format
 Data Retention and Archive Model
The retention – archival model requirements shown
previously lead to four main areas of consideration:

Invariance: How important is it

to ensure that digital data is not
altered.
Objectives: Why retaining the
digital data is required.

Retention Period: The required

period of time the data is to be stored.

Stored Form: The stored format of the digital data.

 Data Retention and Archive Model
To ensure that the information has not changed and
provide evidential weight that the design intent has not
changed, the following categories distinguish
Invariance:

Auditable: Where validation methods and test

suites ensure that information cannot be changed
without the change being detected.
Implicit: Where the system is designed to prevent
changes. The system must supervise activities
which would result in changes of the digital data.
The supervision, for example, could be realized
within a separate write protected vault.
 Data Retention and Archive Model
For digital data, the challenge is that the data are often
stored in a proprietary, native format and will most likely
become un-interpretable over time. The objectives for
keeping data are distinguished into two major
categories:

Legal/Certification Requirements: This includes

proof of technical documentation that support
Government & Regulatory laws.
Business Requirements: This includes keeping
knowledge of business processes and
documentation.
 Data Retention and Archive Model
Four subcategories describe these objectives in more detail:

1) To preserve the original

data (generated by a source
system) so that it can be used
as evidence of what the
configuration of the data was
at a particular point in time
(i.e. date). This characteristic
fits within the subcategory
“Legal/Cert Requirement”.

2) To keep the data available

to new users over the period
in which it is kept. This
characteristic fits with the
subcategories “Legal/Cert
& Business Requirement”
 Data Retention and Archive Model
Four subcategories describe these objectives in more detail:

3) To be able to preserve
the source of the stored data.
This characteristic fits with
the subcategory “Business
Requirement”

4) To be able to reuse the

data (i.e. modify the design
to meet new requirements).
This characteristic fits with
the subcategory “Business
Requirement”.
 Presentation - Representation
Representation and Presentation of 3D Geometric
shape, tolerance and annotation properties/attributes

There is a key distinction between a representation

and a presentation of data.

In a representation, the computer holds the

information/data about the concept.

In a presentation the computer transforms the data

representation into a human understandable form.
 Presentation - Representation
Representation and Presentation of 3D Geometric
shape, tolerance and annotation properties/attributes
The stored form has been divided into three
categories:
Detail Level: This is the description level of a
model.

Representation: This describes the different

logical forms of data representation.

Format: This describes the different physical

formats of the data.
 Levels of Information
Representation

Describes the exchange of reusable, associative GD&T

information in a STEP file. This information is by itself not
visible in the 3D model, but a CAD system importing this file
can use the Representation data to re-create the visible GD&T
information. The representation approach also aims to pass
GD&T / PMI data on to downstream applications, such as CAM
via AP238 for example.
 Levels of Information
Presentation

Describes the exchange of GD&T information in a way that is

visible for the user in the 3D model. There are four levels of
presentation:

Full
Semantic
Unicode symbols
& text literal strings w/ext

Minimum Semantic

Polyline Presentation
 Levels of Information
Polyline Presentation

This captures the information displayed for GD&T “as is”, by

breaking down the annotations and symbols into individual
lines and arcs. This approach is the only one independent from
the Representation, and is not machine-interpretable.
 Levels of Information
Minimal Semantics Presentation – Adds a minimum set
of display information to the Representation data (such as
position in 3D space and a reference point on the model).

Full Semantics Presentation – Adds all the positioning,

styling and other information to the Representation, so that
an importing system supporting this capability can fully re-
create the GD&T information in the 3D model, by
combining the information content from the Representation
with the display settings given by the Presentation.
Unicode.
 Levels of Information
Unicode Presentation
STEP resource parts provide a number of pre defined symbols that can be
used within the context of PMI (ref Unicode-STEP mapping Chart). There
are a number of forms of such symbols; the two of most significance are
terminator symbols (arrows etc.), dimension symbols and geometric
tolerance symbols. For the former, each symbol can be considered as a
distinct object which can be handled using the pre defined symbol form.
However, while dimension and geometric tolerance symbols could be
handled that way – that is not really the optimum way of supporting
interoperability between CAD systems and STEP…...
 Levels of Information
Unicode Presentation cont.
The reason for that is that within the CAD systems, the PMI data is typically handled
as sets of character strings where the specific tolerance symbols are represented, in
a proprietary way, within the string. It is possible to break the strings up and extract
the symbols but in doing this the relationship of the tolerance symbols with the rest
of the text is completely lost. In particular, the position of a symbol at a specific
point within the string is lost. For example

This could be handled as a single string within a CAD system but would result in
7.8 – 8.2 2.4 – 2.8
one or two text literals in STEP together with three symbols which are related only
by virtue of belonging to the same PMI; any sense of order would be lost.

A better way of supporting this data which would maintain the wholeness of the data
would be to map the whole string as a text literal and to use the Unicode characters
to denote the symbols. This maintains the semantic information that the diameter
range is 7.8 to 8.2 and the depth range is 2.4 to 2.8.
 Presentation - Representation
Detail Level: This is the description level of a model.

An accurate representation is where data elements

are described in the original level of detail,
independent of whether they are represented in a
native or other format.

An approximate representation is where data

elements are described in a reduced level of detail
than the accurate representation, e.g. where a
curved surface is approximated by a set of small, flat
faces.
 Presentation - Representation
Representation: This describes the different logical
forms of data representation.
• A native representation is that created by and is
proprietary to the source system format.
• A derived representation is a transformation of the
native data, which may be based on a native or
standardized format (e.g., a .pdf may be derived from a
text document as an alternative representation but the
information context remains unaltered).
• A presentation is a visualization of data to a user, (e.g.,
a 2D drawing, a capture or printed sketch of the product
data representation).
 Presentation - Representation
Format: This describes the different physical formats
of the data.
• A native format is a specific format of data in a syntax
which is proprietary and dependent on a specific system
or interface. A native format depends directly on the
lifecycle (versions, generations) of the related system or
interface.
• A standardized open format is a format of data in a
syntax, which is defined by a broad community, such as
ISO, and which is independent of specific system or
interface. “Open” means completely and precisely
documented in syntax and semantics and is applicable
for free. In addition, standardization processes
regulates the change processes for the standard.
 Data Integrity via V&V Methods
Verification & Validation of Preserved/Archived
Represented Data
• 3D data models are related to their geometric
mathematical representation via the specific CAD
system’s modeling function/application.
• Interpreter (human view) is dependent on a
proprietary CAD system to receive a representation
of the data. The invariability of this representation
has to be guaranteed.
• Current testing shows a frequent occurrence of
data representation changes by changing the
representing CAD system.
 Data Integrity via V&V Methods
Verification & Validation of Preserved/Archived
Represented Data
• To assess the usability of the retrieved model the
application and comparison of (geometric)
validation properties it is the objective of a
monitored testing process and system to
evaluate practical thresholds in order to
guarantee acceptable model quality.

• As the accuracy of CAD modeling applications

varies the testing processes and systems need to
be updated to reflect the evolution of the change.
 Data Integrity via V&V Methods
Verification & Validation Process
• In addition to verification rules the process must describe
the tolerance parameters that serve as a threshold for
their application in order to identify whether given
geometric data can pass a certain rule or not. Applicable
tolerance values need to be defined according to the use
case and internal tolerance if the originating system and
can not be standardized.

• Verification methods are defined how to check these

quality measures as data quality functions. The main
purpose of these functions is to check the consistency
and completeness of the (to be) archived geometric
information in safeguarding a minimum integrity of the
mathematical description.
 Data Integrity via V&V Methods
Verification & Validation Process
• Two levels of data consistency checks can be
distinguished.
• Geometric information needs to be mathematically
consistent, (i.e. all necessary parameters must exist and
must have valid values).
• Geometric information needs to be expressed according
to a data format in a valid way. This does not imply the
order of executing the consistency checks – this is rather
depending on:
• When are the checks to be applied (ingest, retrieval)
• What is the subject of the checks (original data, data in a neutral
format)
 Data Integrity via V&V Methods
Validation of explicit geometry at ingest to archive
• This could be done directly by the neutral file
converter or by a standalone analysis tool which
should again create a analysis report file or a
database entry with all mandatory and optional
attributes for the target neutral model.

• The usage of standardized standalone analysis

tools and neutral report files supports the
modular design of the archiving process. The
source and target analysis results have to be
compared before the converted neutral file is
accepted for archiving.
 Data Integrity via V&V Methods
Validation of explicit geometry at ingest to archive
• This comparison could be done by a comparison tool
which will create a resultant analysis file. If the number of
solids is equal in both analysis files and if the epsilon
values of the validation properties are within the given
tolerances, then the conversion was successful and all
data should be stored in the Archive File Storage of the
Archive Information Package (AIP).

• These data are the target and source validation property

analysis files, the report file of the comparison, which
includes the Preservation Description Information (PDI)
and the neutral model.
 Approach
• To achieve the goal of re-instantiating archived information on
a future platform, it is not sufficient to merely copy data at the
bit level from obsolete to current media but to create
“recoverable” archival representations that are infrastructure
in-dependent, i.e. open and neutral, to the largest extent
possible.
• Data retention processes are managed and validated .
• Media Migration
• Data representation migration & translation
• Incorporating data into repository
• Accessing the data by users.
• Understand the effects of technology change and its impact on
the data and repository systems. (i.e. Preservation Planning)
 Approach

• Develop an architecture that supports:

• Data architecture containing:
• Semantic representation
• Open and Neutral forms
• Data Quality and Validation
• Process architecture:
• Based on Open Archive Information
System (ISO 14721)
• ISO 10303 (STEP)
 Overview of the NAS/EN 9300 STD approach
Data Domain Specific Parts
CAD Geometry & assemblies “Conf. Mechanical Product Electrical Analysis Systems
Product Structure” Managt. Data Engineering
P1xx P3xx P2xx P4xx P5xx P6xx
Part 130: Part 135: Part 335
CAD 3D param. CAD 3D param. TDM 3D Conf. Param Composite
geometry assembly structure assy. structure Conf Mngt
with GD&T & F-F w. GD&T & F-F with GD&T & F-F Change Mngt. P7xx?
2008? DR P&O
AF
Part 120: T Part 125: Part 325 Date...
CAD 3D explicit CAD 3D (explicit) TDM 3D Conf. Project Mngt
geometry assembly structure assy. structure
RE
with GD&T & F-F with GD&T & F-F with GD&T & F-F L : Release EN9300
DR DR
A A DR
Part 110: FT Part 115: FT
Part 315 AF
T
: In preparation
CAD 3D CAD 3D (explicit) TDM 3D Conf. BA
explicit geometry assembly structure Assembly structure LL
OT : In ballot
DR
Q2 07? AF Q2/07?
Part 100: T Part 300: Part 200:
Fundaments & Fundaments & Fundaments &
& concepts Q2/07? & concepts & concepts
2° R
B AL Part 10: Common Process EL
LO R
RE
T RE
L
RE
L
RE
L Part 11: Data Preparation EL
Part 1: L Part 2: Part 3: Part 4:
Part 12: Ingest REL Common
Common Requirements Fundamentals Methods
Part 13: Archival Storage RE
Overview (V1) – V2 in ballot and concepts L Process
Q3/06
DR
A Part 14: Retrieval REL Parts
Part 5: Part 6: Part 7: FT RE
Authentication Functional Term and Part 15: Removal L

and Verification Architecture references Part 16: Test Suites

Q4/06 2008? Q4/06 Basic Parts Part 17: Audit
Priority Stair step of entities to work

Planned for Future Construction

Working with Industry Development History and
Parametrics
Standards for Solution
Domain specific Domain specific Domain specific
(Electric, tubing, (Electric, tubing,(Electric, tubing,
Must have to
Systems) Systems) Systems)
support LTA of
Design Intent Composite Ply Composite Ply Composite Ply Composite Ply
Information Information Information Information
and Layup and Layup and Layup and Layup
Geometry Geometry Geometry Geometry Geometry
Tolerances Tolerances Tolerances Tolerances Tolerances
& annotation & annotation & annotation & annotation & annotation
(FT&A) (FT&A) (FT&A) (FT&A) (FT&A)
3D Solid 3D Solid 3D Solid 3D Solid 3D Solid 3D Solid
Geometry Geometry Geometry Geometry Geometry Geometry
& assembly & assembly & assembly & assembly & assembly & assembly
 What are We Doing?
Preservation of 3D Explicit Geometry with Associative
Dimensions & Tolerances and Form Features
Part 110: Preservation of 3D Explicit
Geometry (Ref. Part 110 tutorial )

Part 120 V1: Preservation of 3D Explicit Geometry

with associative GD&T

Part 120 V2: Preservation of 3D Explicit Geometry

with associative Form Features
Part 110: Business/Regulatory Requirements for LT
Archiving of 3D CAD explicit geometry

• Scope
• Fundamental & concepts for Long Term
Archiving (LTA) of 3D explicit geometry

• Business specifications of 3D explicit geometry

• Key characteristics of 3D explicit geometry

• Use Cases of the archiving system

(administration)

• Definition of Core Model for explicit geometry

Part 110: Business/Regulatory Requirements for LT
Archiving of 3D CAD explicit geometry

• Definition of Core Model for explicit geometry

• Verification rules and conformance classes of
explicit geometry
• Validation rules of explicit geometry
• Overview of Information Packages (SIP, AIP
and DIP) for explicit geometry and associated
data flow
• Description of Information Packages for the
explicit geometry
(files and metadata)
• Overall description of test cases
• Key performance indicators for monitoring
 Part 110: Business/Regulatory Requirements for LT
Archiving of 3D CAD explicit geometry

•SCOPE of Part 1
• Axis and units
• Representation
• Geometry
• Points, Curves, Surfaces
• Topology
• Vertex, Edges, Solids
• Color and layers
• Geometrical properties
• Attached to geometry
• Attached to a “Shape Aspect” / Form Feature
• Part Properties
 Part 110: Business/Regulatory Requirements for LT
Archiving of 3D CAD explicit geometry
• Certification
• LTA of FAI (First Article Inspection) based on 3D MBD
• Legal
• Regulatory requirement to store Type design data of the
life of the product
• Re-use
• Business requirement to be able to re-use design data for
future derivatives etc.
• Support in production operations
• Manufacturing based on 3D MBD
• Assembly based on 3D MBD
• Documentation for Repairs
 Part 110: List of Business use cases for LT
Archiving of 3D CAD explicit geometry

• Classification and definition by disciplines:

• Mechanical,
• Sheet Metal,
• Electrical Harness,
• Tubing,
• Composites, ...
• for each Business requirement:
• Certification
• Legal
• Re-use
• Support in production operations
• and according to the main OAIS process:
• Ingestion through Retrieval & Removal
Part 110, 120 V1 & V2: List of Business use cases for LT
Archiving of 3D CAD explicit Geometry

Certification L-T-A Support in operation

Legal aspects Business requirements Re-use

Preservation Preservation Preservation

& Retrieval of & Retrieval of & Retrieval of
3D Explicit Geometry 3D Explicit GD&T 3D Explicit FF

Context Use
UseCase
Case Use
UseCase
Case Use
UseCase
Case
Use
UseCase
Case Use
UseCase
Case Use
UseCase
Case

Key
Characteristics

Core Model Core Model Core Model

“Explicit 3D geometry” “Explicit GD&T” “Explicit FF”
Part 110, 120 V1 & V2 Format Requirements
for LTA of 3D explicit geometry

•The LOTAR recommendation is to use a format based on

an open standard, i.e., has to fulfill the following rules:
• The data model is fully described according to the state
of the art practices .
• e.g., object modeling methods using UML or EXPRESS.
• The format and the services implementing the data are described
explicitly.
• e.g., STEP Part21 or XML, SDAI / EXPRESS
• The use of the standardized data is free of charge .
• e.g., processing of the data is not “controlled” by patents on
algorithms.
• The updating process of the associated components are described
and well accepted by the community of involved parties.
• e.g., STEP ISO ballots procedures, OMG and W3C consortiums
procedures.
 Part 110, 120 V1 & V2: Definition of KC’s

AS9100:
Key Characteristics (KC): the features of a material or a part whose variation has a
significant influence on product fit, performance, service life or manufacturability.

AS9103:
Key Characteristics for a part, subassembly or system
are those selected geometrical, material properties, functional and/or cosmetic
features, which are measurable, whose variation control is necessary in meeting
Customer requirements and enhancing Customer Satisfaction.

Note: Key Characteristics have to be explicitly identified, & described, during

“Ingestion” and checked after “Access/Retrieve” entities.
Key characteristics are related to the design intent which must be preserved,
and to the use cases of Ingestion & Access/Retrieval.

Geometric Validation Properties are a subset of Key Characteristics,

used for end to end quality control.
 Part 120 V1 & V2:Key characteristic entities of geometry
and topology
• The topological entities of higher level are preserved by validation properties

this surface is a high level

entity built with low level
entities edges and points

these wires and vertices are

high level entities

this solid is a high level

entity built with low level
entities faces, edges and
points
Part 110, 120 V1 & V2:
Example of modification of mathematical entities allowable for a KC

For example a curve can change if its new model is “equivalent” for the
business requirement (E.g., Control the manufacturing of a part, ...)

Bezier Bezier Nurbs

System 1 LTA Export in STEP System 2

3D modeler Preserved the type of entity of the 3D modeler
based on source system based on
Bezier curve => Bezier curve entity Nurbs curve

The curve entity is a Key Characteristic.

Its type is allowable to be changed by an equivalent entity
 Part 120 V1 & V2:
Preservation of semantic of 3D (geometry, topology) requirements

• Capability of characterization – description

• Capability of unique identification and preservation of

this unique identification

• Capability of end to end quality control based on

validation properties
• Each Key characteristic can be checked by an
indicator to be defined
• This indicator is measured and its value is compared
to an agreed threshold.
 Part 120 V1 & V2:
Capability of characterization – description of each Key Characteristic

• Capability to ensure the preservation of the semantics, and

if transformation occurs, shall ensure the capability to
control it individually (Through Audits)
• If the user has intentionally created a face, the face has
to be preserved
• This face can be split into smaller faces during a
transformation:
e.g., 2 faces of a Sphere of CADDS5 => 6 faces of
CATIA V5,
• The traceability of the transformation has to be ensured
and documented
• The unique identifiers of the resulting faces has to be
related with the unique identifier of the source entity
Part 120 V1 & V2:
Key characteristics for mechanical parts

• Global key characteristics

• Volume of the part
• Centre of gravity of the part
• Wet Area of the part
• Local key characteristics
• Volume, Center of gravity, & Wet Area of a solid
(If there are several solids in a part)
• Center of gravity and wet area of the surface / face
• For all « isolated » surfaces / faces,
• By user selection for special « functional » surfaces / faces,
• Center of gravity and length of an edge / curve
• For all « isolated » edges / curves,
• By user selection for special « functional » edges / curves,
• Explicit conditions of tangency / curvature continuity
• TBD
Part 120 V1 & V2:
Key characteristics for mechanical parts
Native part
Building N control points:
P1, ... PN,
+ located on the surface.
+ + +
+
+ +

In the CAD system,

computation of
the distance between
Conversion Re-imported part the control points
and the surface:
STEP part : d1 to dN
SURFACE + Conversion +
+ + +
+
Location of P1 to + + Surface is OK if
PN associated
d1 to dN < threshold
with this surface
distance
 Examples of Mechanical 3D CAD information
3D parametric with GD&T
(Results in 3D exact BREP + Form-Features)
3D exact BREP + Form-Features

GD&T
-Dimensions
- Tolerances
Features: Features:
- Hole - Hole
- Pocket - Pocket
- Pad
Annotations - Edge Fillet
- Dimensions
- Geom. Toler.

3D exact BREP 3D facetted BREP

Part Body
-Manifold solid

Open body
 Part 110, 120 V1 & V2:
Illustration of generations of CAD systems for mechanical design
CAD generation technology break 1980 1985 1990 1995 2000 2005 2010 2015 2020 2025 2030

3D surfaces Focus
of
Part
110
3D Explicit Solid

3D Explicit Solid Geometry

Focus + Dimensions
with GD&T of Part & Tolerances
(Geometric Dimensions & Tolerances)
120 V1
Focus
3D Explicit Solid Geometry Hole
with GD&T of Part General pocket
& machining Form Features 120 V2 General_outside_profile

Focus
Capability to update the
3D parametric Geometry of part using construction
with Constructio History Future history / parametric
Part
Part 110, 120 V1 & V2:
Illustration of generations of CAD systems for mechanical design
Explicit

With assembly constraints

With assembly form features

With GD&T
Part II: Part 120 V1
Preservation of 3D
Explicit Geometry
Dimensioning and
Tolerance
Part 120 V1:
Available tolerances according to industry standards

• Industry standards for 3D with GD&T

• ISO 1101 & 16792
• US ASME Y14.5 & Y14.41
• Additional types of tolerances discussed
• Average or nominal tolerancing
• Specific to company rules
Part 120 V1:
Selection of tolerances based on industry standard.

FTA module

Entities selection, Symbol already chosen

then
choice of the symbol
Standard selection
ISO 1101 & 16792
US ASME Y14.5 & Y14.41
 Part 120 V1:
Associating GD&T with related Features to enable viewer associativity.

With FTA or Enovia DMU Viewer

The emphasis should be on the
data required for the
associatively not on the n All the
capability to highlight. ct io
e geometrical
sel
ation entities related
t
no to the annotation
An are highlighted
(As highlighted)

All the
annotations
Hole + (Semantic) Ho related to the
Tolerancing le
sel geometrical
ec
tio entity
n
(As highlighted)
Part 120 V1:
Associating GD&T with related Features to enable viewer associativity.

Enabling use of annotation planes to

improve the visualisation of GD&T
n°1
n
pla
ation
t
no
An

An
not
ati
on
p lan
n °2
Part 120 V1:
Requirement for the LT Archiving format like STEP AP214

Archive in LTA format

Semantic annotations* and

annotation planes must be
preserved in LTA format…
... with a viewer (independent
of native format) able to read
this information.

Native CATIA V5 data

* Semantic means there is a

relation between 3D entities and
annotations, usable for other With highlighting Without highlighting
tools (inspection software, gaps => usable => not
calculator) understandable !

=> Need of associativity between GD&T and explicit Form Features

 Open Archive Information System Model
Requirements
Functional Integration
Product Definition
Bill of Material
Build Definition
Support Definition
Simulations & Analysis
Additional Data
types Product Data Lifecycle Management
Preservation Planning
Producer Descriptive
Info Data
Descriptive
Info Queries
Results
Management sets
Ingest Access
Archival Orders
Storage

Administration
Consumer
Based on: Other
ISO 14721 “Open Archival Information System”
System” Reference Model
Customers
Customer Support
Finance
Regulatory Agencies
Inspectors
Mechanics
Suppliers (Internal/External)
 OAIS Model - INGEST Entity

This entity provides the services and functions to

accept Submission Information Packages (SIPs) from
Producers (or from internal elements under
Administration control) and prepare the contents for
storage and management within the archive. Ingest
functions include receiving SIPs, performing quality
assurance on SIPs, generating an Archival Information
Package (AIP) which complies with the archive’s data
formatting and documentation standards, extracting
Descriptive Information from the AIPs for inclusion in
the archive database, and coordinating updates to
Archival Storage and Data Management.
 OAIS Model - INGEST Entity

The major functions of the OAIS Ingest entity

are: Receive Submission, Quality Assurance,
Generate AIP, Generate Descriptive Information
and Co-ordinate Updates. The functions and
information flows comprising the Ingest entity
of the OAIS functional model are illustrated in
the following diagram.
OAIS Model - INGEST Entity
 OAIS Model - INGEST Entity

The Receive Submission function provides the

appropriate storage capability or devices to receive a
SIP from the Producer (or from Administration). The
Receive Submission function may represent a legal
transfer of custody for the Content Information in the
SIP, and may require that special access controls be
placed on the contents. This function provides a
confirmation of receipt of a SIP to the Producer, which
may include a request to resubmit a SIP in the case of
errors resulting from the SIP submission.
OAIS Model - INGEST Entity
 OAIS Model - INGEST Entity

The Quality Assurance function validates (QA results)

the successful transfer of the SIP to the staging area.
For digital submissions, these mechanisms might
include Cyclic Redundancy Checks (CRCs) or
checksums associated with each data file, or the use of
system log files to record and identify any file transfer
or media read/write errors.
The Generate AIP function transforms one or more SIPs
into one or more AIPs that conform to the archive’s data
formatting and documentation standards. This may
involve file format conversions, data representation
conversions or reorganization of the content
information in the SIPs
OAIS Model - INGEST Entity
 OAIS Model - INGEST Entity

The Generate Descriptive Information function extracts

Descriptive Information from the AIPs and collects
Descriptive Information from other sources to provide
to Coordinate Updates, and ultimately Data
Management. This includes metadata to support
searching and retrieving AIPs (e.g., who, what, when,
where, why).
OAIS Model - INGEST Entity
 OAIS Model - INGEST Entity

The Coordinate Updates function is responsible for

transferring the AIPs to Archival Storage and the
Descriptive Information to Data Management. Transfer
of the AIP includes a storage request and may represent
an electronic, physical, or a virtual (i.e., data stays in
place) transfer. The Coordinate Updates function also
incorporates the storage identification information into
the Descriptive Information for the AIP and transfers it
to the Data Management entity along with a database
update request.
OAIS Model - INGEST Entity
 OAIS Model - Archive Entity

The major functions of the OAIS Archive

Storage entity are Receive Data, Manage
Storage Hierarchy, Replace Media, Error
Checking, Disaster Recovery and Provide Data.
The functions and information flows comprising
the Archive Storage portion of the OAIS
functional model are illustrated
OAIS Model - Archive Entity
 OAIS Model - Archive Entity

The Receive Data function receives a storage

request along with the associated AIP from the
Ingest function and moves the AIP to
permanent storage within the archive. This
function will select the media type, prepare the
devices or volumes, and perform the physical
transfer to the Archival Storage volumes. When
the transfer is complete, the Receive Data
function sends a storage confirmation message
to the Ingest function.
OAIS Model - Archive Entity
 OAIS Model - Archive Entity

The Manage Storage Hierarchy function

positions the contents of the AIPs on the
appropriate media, conforms to special levels of
service, provides the appropriate level of
protection and ensures that AIPs are not
corrupted during transfers. This function also
provides operational statistics to the
Administration function regarding the inventory
of media, available storage capacity, and usage
statistics.
OAIS Model - Archive Entity
 OAIS Model - Archive Entity

The Replace Media function provides the capability to

reproduce the AIPs over time. This would include
migrating to new storage media and using new
operating or file systems.
The Error Checking function provides statistically
acceptable assurance that no components of the AIP
are corrupted during any internal Archival Storage data
transfer. This function requires that archive system
components provide error notification to standard error
logs that are checked by the Archival Storage staff. The
storage facility procedures provide for random
verification of the integrity of data objects using CRCs
or some other error checking mechanism. .
OAIS Model - Archive Entity
 OAIS Model - Archive Entity

The Disaster Recovery function provides a

mechanism for duplicating the digital contents
of the archive collection and storing the
duplicate in a physically separate facility. This
is typically accomplished by copying the
archive contents to some form of removable
storage, but may also be performed by
hardware or network data transfers
OAIS Model - Archive Entity
 OAIS Model - Archive Entity

The Provide Data function provides copies of

stored AIPs to the Access function. This
function receives an AIP request and provides
the data on the requested media type or
transfers them to a staging area. It also sends a
notice of data transfer to the Access function
when the order is complete.
 OAIS Model - Data Management Entity

The major functions of the OAIS Data

Management entity are Administer Database,
Perform Queries, Generate Reports and Receive
Database Updates. The functions and
information flows comprising the Data
Management entity of the OAIS functional
model are illustrated in the following figure
OAIS Model - Data Management Entity
 OAIS Model - Data Management Entity

The Administer Database function is responsible for

maintaining the integrity of the Data Management
database, which contains both Descriptive Information and
system information. Descriptive Information identifies and
describes the archive holdings, and system information is
used to support archive operations. The Administer
Database function is responsible for creating any schema
or table definitions required to support Data Management
functions; for providing the capability to create, maintain
and access customized user views of the contents of this
storage; and for providing internal validation (e.g.,
referential integrity) of the contents of the database. The
Administer Database function is carried out in accordance
with policies received from Administration
OAIS Model - Data Management Entity
 OAIS Model - Data Management Entity

The Perform Queries function receives a query request

from Access and executes the query to generate a result
set that is transmitted to the requester.
The Generate Report function receives a report request
from Ingest, Access or Administration and executes any
queries or other processes necessary to generate the
report that it supplies to the requester. Typical reports
might include summaries of archive holdings by category,
or usage statistics for accesses to archive holdings. It may
also receive a report request from Access and provides
descriptive information for a specific AIP
OAIS Model - Data Management Entity
 OAIS Model - Data Management Entity

The Receive Database Updates function adds, modifies or

deletes information in the Data Management persistent
storage. The main sources of updates are Ingest, which
provides Descriptive Information for the new AIPs, and
Administration, which provides system updates and
review updates. Review updates are generated by periodic
reviewing and updating of information values (e.g., contact
names, and addresses). The Receive Database Updates
function provides regular reports to Administration
summarizing the status of updates to the database, and
also sends a database update response to Ingest
 OAIS Model - Data Management Entity

The major functions of the OAIS Administration

entity are: Negotiate Submission Agreement,
Audit Submission, Archival Information Update,
Activate Requests, Customer Service, Manage
System Configuration, Establish Standards and
Policies, and Physical Access Control. These
functions and their information flows are
illustrated
OAIS Model - Data Management Entity
 OAIS Model - Data Management Entity

The Negotiate Submission Agreement function

negotiates appropriate agreements with data
Producers, utilizing archival and submission
templates as well as advice provided by the
Preservation Planning entity, to support the
archive ingestion requirements. Additionally, the
function supports the Audit Submission function
as part of the submission approval process
OAIS Model - Data Management Entity
 OAIS Model - Data Management Entity

The Audit Submission function verifies that the quality of

the data submissions meets the specifications of the
Submission Agreement and shares the audit reports with
the Ingest Function and the data Producers.
The Administration entity’s Archive Information Update
function updates the content requirements of the archive.
It receives change requests from the Manage System
Configuration function and disseminates updates through
the Access entity, updating the contents of the resulting
DIPs and resubmitting them to the Ingest entity as SIPs.
OAIS Model - Administration Entity
 OAIS Model - Administration Entity

The Activate Requests function compares the

record of event-driven data requests to determine
if all the needed data is available. If the data is
available, a dissemination request is sent to the
Access entity.

The Customer Service function maintains

customer accounts related to use of the archive
system resources
OAIS Model - Administration Entity
 OAIS Model - Administration Entity

The Manage System Configuration function

continuously monitors the operation of the
archive system. It develops archive configuration
change strategies based operational usage and
performance inputs from the Preservation
Planning, Archival Storage, and Data Management
entities and controls the changes in a manner that
supports archive integrity though all phases of the
archive life cycle. When these changes require
archive policy evolution, requests are also sent to
the Establish Standards and Policy function
OAIS Model - Administration Entity
 OAIS Model - Administration Entity

The Establish Standards and Policy function

creates and maintains the archive system’s
documentation standards, procedures and
policies based on the inputs and needs of the
other functions and entities. For example, this
function will develop the security policies that are
addressed by disaster recovery plans and the
restriction mechanisms developed by the Physical
Access Control function
 OAIS Model - Preservation Planning Entity

The functions and information flows comprising

the Preservation Planning entity of the OAIS
functional model are illustrated in the following
figure
OAIS Model - Preservation Planning Entity
 OAIS Model - Preservation Planning Entity

The Monitor Designated Community function interacts with

archive Consumers and Producers to track changes in
their service requirements and available product
technologies.
The Monitor Technology function is responsible for
tracking emerging digital technologies, information
standards and computing platforms (i.e., hardware and
software) to identify technologies that could cause
obsolescence in the archive's computing environment and
prevent access to some of the archives current holdings
OAIS Model - Preservation Planning Entity
 OAIS Model - Preservation Planning Entity

The Develop Preservation Strategies and

Standards function is responsible for developing
and recommending strategies and standards to
enable the archive to better anticipate future
changes in the Designated Community service
requirements or technology trends that would
require migration of some current archive
holdings or new submissions.
OAIS Model - Preservation Planning Entity
 OAIS Model - Preservation Planning Entity

The Develop Packaging Designs and Migration

Plans function develops new information package
designs and detailed migration plans and
prototypes, to implement Administration policies
and directives.
 OAIS Model - Access Entity

The major functions of the OAIS Access entity

are: Coordinate Access Activities, Generate DIP
and Deliver Response. The functions and
information flows comprising the Access entity of
the OAIS functional model are illustrated are
illustrated in the following figure
OAIS Model - Access Entity
 OAIS Model - Access Entity

The Coordinate Access Activities function provides a

single user interface to the information holdings of the
archive. Three categories of Consumer requests are
distinguished: query requests, which are executed in Data
Management and return immediate result sets for
presentation to the user; report requests, which may
require a number of queries and produce formatted reports
for delivery to the Consumer; and orders, which may
access either or both Data Management and Archival
Storage to prepare a formal Dissemination Information
Package (DIP) for on- or off-line delivery
OAIS Model - Access Entity
 OAIS Model - Access Entity

The Generate DIP function accepts a dissemination

request, retrieves the AIP from Archival Storage, and
moves a copy of the data to a staging area for further
processing. This function also transmits a report request
to Data Management to obtain Descriptive Information
needed for the DIP. This function places the completed
DIP response in the staging area and notifies the
Coordinate Access Activities function that the DIP is ready
for delivery.
The Deliver Response function handles deliveries of
responses (DIPs, result sets, reports and assistance) to
Consumers
 References

References
• ISO-10303 STandard for the Exchange of
Product model data (STEP)
• ISO-14721 Open Archive Information System
(OAIS) reference Model
• AIA-ASD Stan LOTAR Process Standards
(NAS/EN 9300-xx)
• Application Integrated Construct (AIC) AIC-519
Geometric Tolerances
 References

• GDT RP Recommended Practices for Dimensions,

Dimensional & Geometric Tolerances 6th Dec 2006
• 3D Text RP Recommended Practices for 3D associative text 20th
April 1999
• Polyline RP Recommended Practices for GD&T Polyline
Presentation June 2008
• ASME Y14.5M Geometric Dimensioning & Tolerancing 1994
• ASME Y14.41 Digital Product Definition Data Practices 2003
• ASME Y14.100 Engineering Drawing Practices 2004
• ASME Y14.36M Surface Texture Symbols 1994
• ISO 1101 Geometrical Product Specifications (GPS) 2004
• ISO 16792 Digital Product Definition Data Practices 2004
 Contacts

Rick ZURAY Jean-Yves DELAUNAY

AIA – ASD Stan LOTAR project co-chair AIA – ASD Stan LOTAR project co-chair
Technical Principal – PDM CAD-PDM Information Interoperability
Systems Integration Processes & Tools EMSA – Process Architect
The Boeing Company Airbus
Office: (425) 717-2654 Office: (33) (0) 5 -61 -18-31-31
Mobile: (206) 778-6730 Mobile: (33) (0) 6 -76 -36-50-59
Mail to: [email protected] Mail to: [email protected]