Lotar 101 Overview Current Jan 2009

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
AIA Team IAQG Dec 2010
Jan 2009
Pilot Activity
Jan
Formed Charter Oct 07 – May 08
1997 Pilot Activity w/NIST, DS, PTC, UGS
Standards
Part 120V2 & Part 125V1
Development

Sept Sept 2004 Dec 2007 Coord with other Industries AIAG,
Jun 2008
Sept 2002
1998 EN9300-Part AIA-ASD Stan AIA-EIDS, Nuclear, NIST, etc.
ARP-9034
NAS/EN9300-Part 2,
002 Released LOTAR MoU
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
AIA Team IAQG Sep 2009
Oct 2008
Pilot Activity
Jan
Formed Charter Oct 07 – May 08
1997 Pilot Activity w/NIST, DS, PTC, UGS
Standards
Part 120V2 & Part 125V1
Development

Sept Sept 2004 Dec 2007 Coord with other Industries AIAG,
Jun 2008
Sept 2002
1998 EN9300-Part AIA-ASD Stan AIA-EIDS, Nuclear, NIST, etc.
ARP-9034
NAS/EN9300-Part 2,
002 Released LOTAR MoU
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
LOTAR
AIA ASD Stan
regional
International
LOTAR LOTAR
association
Website
(Collaboration)
Regional
PLM
interoperability PDES Inc ProSTEP iViP
regional LTDR LOTAR
CAX Implem. Forum
association
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

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

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

LOTAR 9300-003 Fund & Concepts 9300-012 Ingest 9300-115 Explicit Assy

LOTAR
9300-004 Description Methods 9300-013 Archival Storage 9300-120 Exp Geo & GDT

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

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

9300-016 Test Suites
9300-007 Terms & References 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 2 Generation 3
Generation 1
The first generation The third generation
(2D and 3D: 2D Authority) (3D Only: 3D Authority)
(2D only: 2D Authority)
methods for PDD method is based on
3D
creation were 2D the use of
2D
2D
manual board 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
3D
which allowed the 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 drawing
Model Based Design
authority. representation. The
(MBD)
3D Model is the
authority but low
The second generation methods of PDD creation used only CAD
end visualization is
design methods which was based on use of 3D models and
require to support
output was both 2D models (drawings) and 3D CAD dataset to
various end usages
drive CAM/CAI. The 2D Drawing was the authority for most
– thus U3D.
factory usage with the exception of CAM/CAI.

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

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


• 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

• 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
• 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

Other
Certification Product Liability Suppt in Operation Design Reuse

Functions to be supported after retrieval Use Cases (UC)

Risk Management UC1 UC2 UC3 UC4 UCn

Tolerance Tolerance CAD Data
Associated
Thresholds Thresholds Essential
Validation
Information to be
Report
Preserved (i.e.
Set of Set of
Geometry,
Validation Verification
Tolerance &
Properties Rules Associated
annotation,
1) Mandatory: 1) Mandatory: Verification
technical data etc.
2) Optional: 2) Optional: 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, quot;how do we retain our product knowledge (i.e. Design Intent) throughout the life of the product?quot; This is
wider than the OAIS question, quot;what do we need to be able to understand this particular package of data?quot;, rather
asks quot;what data about a product should we keep?quot; 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
Product Data Lifecycle Management
types

Producer Descriptive Descriptive
Data Queries
Info Info
Results
Management sets
Access
Ingest
Archival Orders
Storage
Consumer
Administration
Based on: Other
ISO 14721 “Open Archival Information System” Reference Model
System”
Customers
Customer Support
Finance
Regulatory Agencies
Inspectors
Mechanics
Suppliers (Internal/External)

High Level Data Flow
(Proposed Implementation)

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

Administration
Producer

Data
Preparation
Consumer

Data
SIP
Usage

DIP
Data Data
AIP
AIP
Ingest Retrieval
Remove
Archive

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

= Submission Information Package = Archival Information Package
SIP = Dissemination Information Package
AIP DIP

Lower Level Data Flow

Data Preparation flow
Start Start
Data Prep Ingest

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

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

Create
SIP
Quality
Data

Data
verification
& validation

DC
= Submission Information Package = Archival Information Package
SIP = Dissemination Information Package = Data Content
AIP DIP

Sean Barker - BAE

Digital Signature
Retention – Archiving model
Auditable
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
Representation
Native Representation
Derived Representation
Format Presentation
Standardized Format
Stored Form

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.

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.

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.

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”

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”.

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.

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.

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

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.

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.

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…...

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
one or two text literals in STEP together with three symbols which are–related only
7.8 – 8.2 2.4 2.8

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.

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.

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).

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.

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.

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.

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)

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.

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
“Conf. Mechanical Product Electrical Analysis Systems
CAD Geometry & assemblies
Product Structure” Managt. Data Engineering
P1xx P3xx P2xx P4xx P5xx P6xx
Part 130: Part 135: Part 335
Composite
CAD 3D param. CAD 3D param. TDM 3D Conf. Param
Conf Mngt
geometry assembly structure assy. structure
P7xx?
Change Mngt.
with GD&T & F-F w. GD&T & F-F with GD&T & F-F
P&O
2008? DR
AF
Date...
Part 325
T
Part 120: Part 125:
TDM 3D Conf.
CAD 3D explicit CAD 3D (explicit) Project Mngt
assy. structure
geometry assembly structure
RE
with GD&T & F-F : Release EN9300
with GD&T & F-F with GD&T & F-F L
DR DR
DR
A A
110: FT FT : In preparation
Part 115:
Part AF
Part 315 T
CAD 3D (explicit)
CAD 3D TDM 3D Conf. BA
explicit geometry assembly structure LL
Assembly structure : In ballot
OT
DR
Q2 07? Q2/07?
AF
T
Part 100: Part 300: Part 200:
Fundaments & Fundaments & Fundaments &
& concepts Q2/07? & concepts & concepts
R
2°
Part 10: Common Process EL
B AL
LO R
Part 11: Data Preparation EL
RE
T RE RE
RE L
L L
1: L Part 2: Part 3:
Part Part 4:
Part 12: Ingest REL Common
Requirements Fundamentals
Common Methods
RE
Part 13: Archival Storage Process
(V1) – V2 in ballot and concepts
Overview L
Q3/06
Part 14: Retrieval REL
DR
Parts
A
7: FT
Part 5: Part 6: Part RE
Part 15: Removal L
Authentication Functional Term and
and Verification Architecture Part 16: Test Suites
references
Basic Parts
2008? Q4/06 Part 17: Audit
Q4/06

Priority Stair step of entities to work

Planned for Future Construction
Development History and
Working with Industry
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


• 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


•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

• 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

• 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

L-T-A
Certification Support in operation

Business requirements
Legal aspects Re-use

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

Context Use Case Use Case Use Case
Use Case Use Case Use Case

Key
Characteristics

Core Model Core Model Core Model
“Explicit GD&T”
“Explicit 3D geometry” “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
Re-imported part
Conversion the control points
and the surface:
: d1 to dN
STEP part
+
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 3D exact BREP + Form-Features
(Results in 3D exact BREP + Form-Features)

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

3D facetted BREP
3D exact 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

Focus
3D surfaces
of
Part
110
3D Explicit Solid

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

Focus
Capability to update the
of part using construction
3D parametric Geometry
Future
with Constructio History 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
All the
associatively not on the on
cti
capability to highlight. geometrical
e
sel
on entities related
ati
t
no to the annotation
An are highlighted
(As highlighted)

All the
annotations
Hole + (Semantic) related to the
Ho
le
Tolerancing 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
1
n°
n
pla
on
ati
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

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.


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.


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.


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


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).


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 - 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


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.


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.


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. .


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


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


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


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


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


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


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


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


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


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


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


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


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.


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


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


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
Recommended Practices for 3D associative text 20th
• 3D Text RP
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

Jean-Yves DELAUNAY
Rick ZURAY
AIA – ASD Stan LOTAR project co-chair
AIA – ASD Stan LOTAR project co-chair
CAD-PDM Information Interoperability
Technical Principal – PDM
EMSA – Process Architect
Systems Integration Processes & Tools
Airbus
The Boeing Company
Office: (33) (0) 5 -61 -18-31-31
Office: (425) 717-2654
Mobile: (33) (0) 6 -76 -36-50-59
Mobile: (206) 778-6730
Mail to: jean-yves.delaunay@airbus.com
Mail to: richard.s.zuray@boeing.com

Lotar 101 Overview Current Jan 2009

Recommandé

Recommandé

Contenu connexe

Similaire à Lotar 101 Overview Current Jan 2009

Similaire à Lotar 101 Overview Current Jan 2009 (11)

Dernier

Dernier (20)

Lotar 101 Overview Current Jan 2009