Download - Lotar 101 Overview Current Jan 2009
LOTAR 101 LOTAR 101 –– A Project Overview A Project Overview
Overview of LOng Term Overview of LOng Term Archival & Retrieval (LOTAR) Archival & Retrieval (LOTAR) of digital product & technical of digital product & technical
datadata
AEROSPACE INDUSTRIES ASSOCIATION
LOTAR Project on a pageLOTAR Project on a page
The 4 areas addressed by LOTAR…
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.
ProjectProject HistoryHistory
Jan 1997
Sept 1998
Aug 2000 AIA Team Formed
Sept 2002 ARP-9034 Released
Dec 2002 IAQG
Charter
Dec 2007 AIA-ASD Stan LOTAR MoU
Sept 2004 EN9300-Part 002 Released
Jun 2008
NAS/EN9300-Part 2, 5 ,7, 100, 110, 115
Ballot
Jan 2009
Standards Development
Pilot Activity w/NIST, DS, PTC, UGS Part 120V2 & Part 125V1
Coord with other Industries AIAG, AIA-EIDS, Nuclear, NIST, etc.
Pilot Activity Oct 07 – May 08
Polyline RP Released
Jun 08Dec 2010
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.
Jan 1997
Sept 1998
Aug 2000 AIA Team Formed
Sept 2002 ARP-9034 Released
Dec 2002 IAQG
Charter
Dec 2007 AIA-ASD Stan LOTAR MoU
Sept 2004 EN9300-Part 002 Released
Jun 2008
NAS/EN9300-Part 2, 5 ,7, 100, 110, 115
Ballot
Oct 2008
Standards Development
Pilot Activity w/NIST, DS, PTC, UGS Part 120V2 & Part 125V1
Coord with other Industries AIAG, AIA-EIDS, Nuclear, NIST, etc.
Pilot Activity Oct 07 – May 08
Polyline RP Released
Jun 08Sep 2009
ProjectProject HistoryHistory
LOTAR International
AIA LOTAR
ASD StanLOTAR
PDES Inc LTDR
ProSTEP iViP LOTAR
International
Regional
Aerospace regional
association
PLM interoperability
regional association
LOTAR International
Website (Collaboration)
IAQG ISO TC20Existing Planned (>2009)
CAX Implem. Forum
PDM Implem. Forum
Harmonization at the regional and International levelsHarmonization at the regional and International levels between Aerospace Manufacturers and PLM interoperabilitybetween Aerospace Manufacturers and PLM interoperability
Space Space Division Division
KC Plant
Participating Companies and Regulatory Agencies Participating Companies and Regulatory Agencies Supporting LOTARSupporting LOTAR
LOTAR International
AIA LOTAR
ASD StanLOTAR
PDES Inc LTDR
ProSTEP iViP LOTAR
Standards 9300-series
IAQG ISO TC20Existing Planned (>2008?)
CAX Implem. Forum
PDM Implem. Forum
9300-001 Doc Structure
9300-002 Bus/Proc Reqs
9300-003 Fund & Concepts
9300-004 Description Methods
9300-005 Authent & Verif
9300-006 Fund Architecture
9300-007 Terms & References
9300-010 Common Process
9300-011 Data Preparation
9300-012 Ingest
9300-013 Archival Storage
9300-014 Retrieval
9300-015 Removal
9300-016 Test Suites
9300-017 Audits
9300-100 CAD LTA Fund
9300-110 Explicit Geom
9300-115 Explicit Assy
9300-120 Exp Geo & GDT
9300-125 Exp Assy & GDT
9300-130 Parametric Geo
9300-135 Parametric Assy
9300-200 PDM series
9300-201 xx
9300-300 Config Mech PS
9300-301 xx
9300-400 Electrical
9300-401 xx
NAS9300-xxx EN9300-xxx
Harmonization at the regional and International levelsHarmonization at the regional and International levels between Aerospace Manufacturers and PLM interoperabilitybetween Aerospace Manufacturers and PLM interoperability
LOTAR ObjectivesLOTAR ObjectivesProduct 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.
The second generation methods of PDD creation used only CAD design methods which was based on use of 3D models and
output was both 2D models (drawings) and 3D CAD dataset to drive CAM/CAI. The 2D Drawing was the authority for most
factory usage with the exception of CAM/CAI.
The first generation methods for PDD creation were 2D manual board drawings with design engineers and manufacturing engineers. This evolved into a 2D CAD design method which allowed the digital creation of 2D drawing (without a 3D model) The 2D Drawing is the authority.
The third generation method is based on the use of parametric and relational design in 3D Model Base Data. The PDD information is defined only in 3D models that contain associative GD&T and annotation to effectively replace the need for a 2D drawing representation. The 3D Model is the authority but low end visualization is require to support various end usages – thus U3D.
2D2D
3D
Model Based Design (MBD)
3D
Generation 1 (2D only: 2D Authority)
Generation 2 (2D and 3D: 2D Authority)
Generation 3 (3D Only: 3D Authority)
LOTAR ObjectivesLOTAR 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.
• 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
LOTAR RequirementsLOTAR Requirements
The Simple SolutionThe Simple Solution
• 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
RequirementsRequirements
• 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.
RequirementsRequirements
• 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.
RequirementsRequirements
• 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).
RequirementsRequirements
• 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 PlanningLife 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
“Life Cycle Information Planning asks the question, how do we retain our product knowledge throughout the life of the product?”
Life Cycle Information PlanningLife Cycle Information Planning
• 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 Presentation -- RepresentationRepresentation
• 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.
Presentation Presentation -- RepresentationRepresentation
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
Product Data LifecycleProduct Data Lifecycle
Repository
Repository
AccessAdministration
Preservation PlanningIngest
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)
Data Retention and Archive ModelData Retention and Archive Model
LOTAR NomenclatureLOTAR NomenclatureThe 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 NomenclatureLOTAR NomenclatureLegal Requirements
Certification Product Liability
Business Requirements
Suppt in Operation OtherDesign Reuse
Functions to be supported after retrieval Use Cases (UC)
Risk Management UC1 UC2 UC3 UC4 UCn
Tolerance Thresholds
Tolerance Thresholds
Set of Validation Validation PropertiesProperties
1) Mandatory: 2) Optional:
Set of Verification Verification
RulesRules1) Mandatory: 2) Optional:
CAD Data Essential
Information to be Preserved (i.e.
Geometry, Tolerance & annotation,
technical data etc.
Associated Validation
Report
Associated Verification
Report
9300- Part xx
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 anarchive, and which provide services to consumers of the data, including both query and retrieval. The most subtlearea, and possibly the least understood, is the construction of the web of information needed to correctly read thedata once it has been retrieved.
The LOTAR standard uses the OAIS reference model as a basic framework, providing specific guidance onspecialized types of data; initially Mechanical CAD/CAM/CAI and non-geometric meta data. The problem here is notto be sure that the data comes in and out correctly, but that it is being correctly interpreted by the new generationof 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 yearstime 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 thequestion, "how do we retain our product knowledge (i.e. Design Intent) throughout the life of the product?" This iswider than the OAIS question, "what do we need to be able to understand this particular package of data?", ratherasks "what data about a product should we keep?" Although the answer starts with obvious elements such as thedesign and the configuration, it soon gets into areas such as the preservation of design rationale, the processes bywhich the product was designed, and the organizational structures that enable those processes to operate.
Open Archive Information System ModelOpen Archive Information System Model
Product Data Lifecycle ManagementProduct Data Lifecycle Management
RequirementsFunctional Integration
Product DefinitionBill of Material
Build DefinitionSupport Definition
Simulations & Analysis
Customers
Suppliers (Internal/External)Mechanics
InspectorsRegulatory Agencies
FinanceCustomer Support
Producer
Consumer
Preservation Planning
Administration
Data Management
Archival Storage
Access
QueriesResults
sets
Orders
Descriptive Info
Descriptive Info
Other
Additional Data types
Based on:Based on:ISO 14721 ISO 14721 ““Open Archival Information SystemOpen Archival Information System”” Reference ModelReference Model
Ingest
Open Archive Information System ModelOpen Archive Information System Model
High Level Data FlowHigh Level Data Flow (Proposed Implementation)(Proposed Implementation)
Arc
hive
AdministrationAdministration
Preservation PlanningPreservation Planning
Prod
ucer
Con
sum
er
Data Preparation
Data Ingest
Ingest of pre-existing
data
Archival Storage
Data Retrieval
Data Usage
Remove per Ret. Period
SIP
AIP
AIP
AIP
DIP
AIP
SIPSIP AIPAIP DIPDIP= Submission Information Package = Archival Information Package = Dissemination Information Package
Data Preparation
Data Ingest
Archival Storage
Data Retrieval
Remove per Retention
Period
Prod
ucer
Select data for
archiving
Y
Lower Level Data FlowLower Level Data Flow
Start Data Prep
Start Ingest
Initiate data
Quality process
DC
Dat
a Q
ualit
y
Data verification & validation
Error handling for Data Prep
Auto Create
validation properties
Y|N
N
Manual Create VP
Auto Create VP
Create Preservation
Data Info (PDI)
Create SIP
Create Descriptive
Info (DI)
Data Preparation flow
SIPSIP AIPAIP DIPDIP= Submission Information Package = Archival Information Package = Dissemination Information Package DC = Data Content
Retention Retention –– Archiving modelArchiving model
RET
ENTI
ON
LON
G TER
M A
RC
HIVA
L
ObjectivesObjectives
Legal Reqs Preserve Original
Keep Data Available
Preserve Source Business Reqs
Reuse
InvarianceInvariance
Digital SignatureAuditable
Implicit
Not Required
Retention PeriodRetention Period
Short Term
Medium Term
Long Term
Stored FormStored Form
Detail Level
Representation
AccurateApproximate
Native Representation
PresentationStandardized Format
Derived RepresentationFormat
Data Retention and Archive ModelData Retention and Archive ModelSean Barker - BAE
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 ModelData 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 ModelData 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 ModelData Retention and Archive Model
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:
Data Retention and Archive ModelData 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”.
Data Retention and Archive ModelData Retention and Archive Model
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
Presentation Presentation -- RepresentationRepresentation
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.
Representation and Presentation of 3D Geometric shape, tolerance and annotation properties/attributes
Presentation Presentation -- RepresentationRepresentation
Levels of InformationLevels of Information
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.
Representation
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:
Presentation
Full Semantic
Minimum Semantic
Polyline Presentation
Unicode symbols & text literal strings w/ext
Levels of InformationLevels of Information
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.
Polyline Presentation
Levels of InformationLevels 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 InformationLevels of Information
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
Levels of InformationLevels of Information
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 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.
Unicode Presentation cont.
7.8 – 8.2 2.4 – 2.8
Levels of InformationLevels of Information
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 Presentation -- RepresentationRepresentation
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 Presentation -- RepresentationRepresentation
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.
Presentation Presentation -- RepresentationRepresentation
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 MethodsData Integrity via V&V Methods
• 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 of Preserved/Archived Represented Data
Data Integrity via V&V MethodsData 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 MethodsData 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 MethodsData 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 MethodsData 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.
Data Integrity via V&V MethodsData Integrity via V&V Methods
• 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)
ApproachApproach
• 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)
ApproachApproach
Part 1: Common Overview
Part 6: Functional
Architecture
Part 3: Fundamentals and concepts
Part 2: Requirements
(V1) – V2 in ballot
Part 5: Authentication and Verification
Part 110: CAD 3D
explicit geometry
Part 115: CAD 3D (explicit) assembly structure
Part 315 TDM 3D Conf.
Assembly structure
Part 120: CAD 3D explicit
geometry with GD&T & F-F
Part 130: CAD 3D param.
geometry with GD&T & F-F
Part 125: CAD 3D (explicit)
assembly structure with GD&T & F-F
Part 325 TDM 3D Conf. assy. structure
with GD&T & F-F
Part 135: CAD 3D param.
assembly structure w. GD&T & F-F
Part 100: Fundaments &
& concepts
Common Process Parts
CAD Geometry & assemblies Product Managt. Data
“Conf. Mechanical Product Structure”
Electrical Analysis Systems Engineering
Part 200: Fundaments &
& concepts
Part 300: Fundaments &
& concepts
Data Domain Specific Parts
Basic Parts Part 17: AuditPart 16: Test SuitesPart 15: RemovalPart 14: RetrievalPart 13: Archival StoragePart 12: Ingest
Part 11: Data PreparationPart 10: Common Process
P1xx P3xx P2xx P4xx P5xx P6xxPart 335
TDM 3D Conf. Param assy. structure
with GD&T & F-F
Composite
P7xx?Conf Mngt Change Mngt.P&O Date...Project Mngt
RELREL
REL
RELREL
RELREL
RELREL
DRAFT
DRAFTDRAFT
DRAFT
REL : Release EN9300
DRAFT: In preparation
Q4/06
Q3/06
Q2 07? Q2/07?
Q2/07?
: In ballot BALLOT
2° BALLOT
2008?
Part 4: Methods
REL
Part 7: Term and referencesQ4/06
DRAFT
2008?
Overview of the NAS/EN 9300 STD approachOverview of the NAS/EN 9300 STD approach
3D SolidGeometry
& assembly
3D SolidGeometry
& assembly
Geometry Tolerances
& annotation(FT&A)
Geometry Tolerances & annotation
(FT&A)3D Solid
Geometry & assembly
Composite Ply Information and Layup
Geometry Tolerances & annotation
(FT&A)3D Solid
Geometry & assembly
Composite Ply Information and Layup
Domain specific(Electric, tubing,
Systems)
Geometry Tolerances & annotation
(FT&A)3D Solid
Geometry & assembly
Composite Ply Information and Layup
Domain specific(Electric, tubing,
Systems)
Geometry Tolerances & annotation
(FT&A)3D Solid
Geometry & assembly
Composite Ply Information and Layup
Domain specific(Electric, tubing,
Systems)
Construction History and Parametrics
Must have to support LTA of Design Intent
Working with Industry Standards for Solution
Planned for Future Development
Priority Stair step of entities to work Priority Stair step of entities to work
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
What are We Doing?What are We Doing?
Part 110: Business/Regulatory Requirements for LT Part 110: Business/Regulatory Requirements for LT Archiving of 3D CAD explicit geometryArchiving 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 Part 110: Business/Regulatory Requirements for LT Archiving of 3D CAD explicit geometryArchiving 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 Part 110: Business/Regulatory Requirements for LT Archiving of 3D CAD explicit geometryArchiving 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
• 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: Business/Regulatory Requirements 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: List of Business use cases for LT Part 110: List of Business use cases for LT Archiving of 3D CAD explicit geometryArchiving of 3D CAD explicit geometry
L-T-A Business requirements
Use Case
“Explicit 3D geometry”
Core Model Core Model“Explicit GD&T”
Core Model
Certification Support in operation
Use Case Use Case
Key Characteristics
Context
Re-useLegal aspects
Use CaseUse CaseUse Case Use CaseUse CaseUse Case Use CaseUse CaseUse Case
Preservation & Retrieval of 3D Explicit GD&T
Preservation & Retrieval of 3D Explicit Geometry
Preservation & Retrieval of 3D Explicit FF
“Explicit FF”
Part 110, 120 V1 & V2: List of Business use cases for LT Archiving of 3D CAD explicit Geometry
Part 110, 120 V1 & V2 Format Requirements Part 110, 120 V1 & V2 Format Requirements for LTA of 3D explicit geometryfor 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 KCPart 110, 120 V1 & V2: Definition of KC’’s 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.
• 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 120 V1 & V2:Part 120 V1 & V2:Key characteristic entities of geometry Key characteristic entities of geometry and topology and topology
For example a curve can change if its new model is “equivalent” for the business requirement (E.g., Control the manufacturing of a part, ...)
System 13D modeler based on Bezier curve
Bezier
System 23D modeler based on Nurbs curve
Nurbs
LTA Export in STEPPreserved the type of entity of the source system => Bezier curve entity
Bezier
The curve entity is a Key Characteristic.
Its type is allowable to be changed by an equivalent entity
Part 110, 120 V1 & V2:Part 110, 120 V1 & V2:Example of modification of mathematical entities allowable for aExample of modification of mathematical entities allowable for a KCKC
• 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:Part 120 V1 & V2:Preservation of semantic of 3D (geometry, topology) requirementsPreservation of semantic of 3D (geometry, topology) requirements
• 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:Part 120 V1 & V2:Capability of characterization Capability of characterization –– description of each Key Characteristicdescription of each Key Characteristic
• 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:Part 120 V1 & V2:Key characteristics for mechanical partsKey characteristics for mechanical parts
+ ++ +
Building N control points: P1, ... PN, located on the surface.
Native part
STEP part
SURFACE +
Location of P1 to PN associated
with this surface
Re-imported partConversion
In the CAD system, computation of the distance between the control points and the surface: : d1 to dN
Surface is OK if
d1 to dN < threshold distance
Conversion
+
++
+ ++ ++
++
Part 120 V1 & V2:Part 120 V1 & V2:Key characteristics for mechanical partsKey characteristics for mechanical parts
Examples of Examples of Mechanical Mechanical 3D CAD information3D CAD information3D parametric with GD&T
(Results in 3D exact BREP + Form-Features) 3D exact BREP + Form-Features
3D exact BREP 3D facetted BREP
Annotations - Dimensions - Geom. Toler.
Part Body -Manifold solid
Open body
Features: - Hole - Pocket
Features: - Hole - Pocket - Pad - Edge Fillet
GD&T -Dimensions - Tolerances
Part 110, 120 V1 & V2:Part 110, 120 V1 & V2: Illustration of generations of CAD systems for mechanical designIllustration 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
3D Explicit Solid
3D Explicit Solid Geometrywith GD&T
(Geometric Dimensions & Tolerances)
3D Explicit Solid Geometrywith GD&T
& machining Form Features
3D parametric Geometry with Constructio History
+ Dimensions & Tolerances
Hole General pocket
General_outside_profile
Capability to update the part using construction
history / parametric
Focus of
Part 110
Focus of Part 120 V1
Focus of Part 120 V2
Focus of
Future Part
Explicit
With assembly constraints
With assembly form features
With GD&T
Part 110, 120 V1 & V2:Part 110, 120 V1 & V2: Illustration of generations of CAD systems for mechanical designIllustration of generations of CAD systems for mechanical design
Part II: Part 120 V1Part II: Part 120 V1 Preservation of 3D Preservation of 3D Explicit Geometry Explicit Geometry Dimensioning and Dimensioning and
Tolerance Tolerance
• 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: Part 120 V1: Available tolerances according to industry standardsAvailable tolerances according to industry standards
FTA module
Standard selection ISO 1101 & 16792 US ASME Y14.5 & Y14.41
Entities selection, then
choice of the symbol
Symbol already chosen
Part 120 V1:Part 120 V1: Selection of tolerances based on industry standard.Selection of tolerances based on industry standard.
Annotation sel
ection
Hole + (Semantic) Tolerancing
All the geometrical entities related to the annotation are highlighted
(As highlighted)
All the annotations related to the geometrical entity (As highlighted)
With FTA or Enovia DMU Viewer
Hole selection
The emphasis should be on the data required for the
associatively not on the capability to highlight.
Part 120 V1:Part 120 V1: Associating GD&T with related Features to enable viewer associatAssociating GD&T with related Features to enable viewer associativityivity..
Annotation plan n°1
Annotation plan n°2
Enabling use of annotation planes to improve the visualisation of GD&T
Part 120 V1:Part 120 V1: Associating GD&T with related Features to enable viewer associatAssociating GD&T with related Features to enable viewer associativityivity..
Native CATIA V5 data
Part 120 V1: Part 120 V1: Requirement for the LT Archiving format like STEP AP214Requirement 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.
With highlighting => usable
* Semantic means there is a relation between 3D entities and annotations, usable for other tools (inspection software, gaps calculator)
Without highlighting => not
understandable !
=> Need of associativity between GD&T and explicit Form Features
Open Archive Information System ModelOpen Archive Information System Model
Product Data Lifecycle ManagementProduct Data Lifecycle Management
RequirementsFunctional Integration
Product DefinitionBill of Material
Build DefinitionSupport Definition
Simulations & Analysis
Customers
Suppliers (Internal/External)Mechanics
InspectorsRegulatory Agencies
FinanceCustomer Support
Producer
Consumer
Preservation Planning
Administration
Data Management
Archival Storage
Access
QueriesResults
sets
Orders
Descriptive Info
Descriptive Info
Other
Additional Data types
Based on:Based on:ISO 14721 ISO 14721 ““Open Archival Information SystemOpen Archival Information System”” Reference ModelReference Model
Ingest
OAIS Model OAIS Model -- INGEST EntityINGEST 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.
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 - INGEST 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 - Archive 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 - Data Management 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 - Administration 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 - Preservation Planning 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
OAIS Model - Access Entity
• 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
ReferencesReferences
• 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
ReferencesReferences
ContactsContacts
Rick ZURAY AIA – ASD Stan LOTAR project co-chair Technical Principal – PDM Systems Integration Processes & Tools The Boeing Company Office: (425) 717-2654 Mobile: (206) 778-6730 Mail to: [email protected]
Jean-Yves DELAUNAY AIA – ASD Stan LOTAR project co-chair CAD-PDM Information Interoperability EMSA – Process Architect Airbus Office: (33) (0) 5 -61 -18-31-31 Mobile: (33) (0) 6 -76 -36-50-59 Mail to: [email protected]