Transcript
Page 1: 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

Page 2: Lotar 101 Overview Current Jan 2009

LOTAR Project on a pageLOTAR Project on a page

The 4 areas addressed by LOTAR…

Page 3: Lotar 101 Overview Current Jan 2009

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

Page 4: Lotar 101 Overview Current Jan 2009

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

Page 5: Lotar 101 Overview Current Jan 2009

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

Page 6: Lotar 101 Overview Current Jan 2009

Space Space Division Division

KC Plant

Participating Companies and Regulatory Agencies Participating Companies and Regulatory Agencies Supporting LOTARSupporting LOTAR

Page 7: Lotar 101 Overview Current Jan 2009

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

Page 8: Lotar 101 Overview Current Jan 2009

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)

Page 9: Lotar 101 Overview Current Jan 2009

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.

Page 10: Lotar 101 Overview Current Jan 2009

• 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

Page 11: Lotar 101 Overview Current Jan 2009

The Simple SolutionThe Simple Solution

Page 12: Lotar 101 Overview Current Jan 2009

• 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

Page 13: Lotar 101 Overview Current Jan 2009

• 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

Page 14: Lotar 101 Overview Current Jan 2009

• 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

Page 15: Lotar 101 Overview Current Jan 2009

• 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

Page 16: Lotar 101 Overview Current Jan 2009

• 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

Page 17: Lotar 101 Overview Current Jan 2009

• 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

Page 18: Lotar 101 Overview Current Jan 2009

• 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

Page 19: Lotar 101 Overview Current Jan 2009

• 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

Page 20: Lotar 101 Overview Current Jan 2009

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

Page 21: Lotar 101 Overview Current Jan 2009

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

Page 22: Lotar 101 Overview Current Jan 2009

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.

Page 23: Lotar 101 Overview Current Jan 2009

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

Page 24: Lotar 101 Overview Current Jan 2009

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

Page 25: Lotar 101 Overview Current Jan 2009

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

Page 26: Lotar 101 Overview Current Jan 2009

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

Page 27: Lotar 101 Overview Current Jan 2009

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

Page 28: Lotar 101 Overview Current Jan 2009

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

Page 29: Lotar 101 Overview Current Jan 2009

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

Page 30: Lotar 101 Overview Current Jan 2009

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

Page 31: Lotar 101 Overview Current Jan 2009

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

Page 32: Lotar 101 Overview Current Jan 2009

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

Page 33: Lotar 101 Overview Current Jan 2009

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

Page 34: Lotar 101 Overview Current Jan 2009

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

Page 35: Lotar 101 Overview Current Jan 2009

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

Page 36: Lotar 101 Overview Current Jan 2009

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

Page 37: Lotar 101 Overview Current Jan 2009

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

Page 38: Lotar 101 Overview Current Jan 2009

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

Page 39: Lotar 101 Overview Current Jan 2009

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

Page 40: Lotar 101 Overview Current Jan 2009

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

Page 41: Lotar 101 Overview Current Jan 2009

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

Page 42: Lotar 101 Overview Current Jan 2009

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

Page 43: Lotar 101 Overview Current Jan 2009

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

Page 44: Lotar 101 Overview Current Jan 2009

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

Page 45: Lotar 101 Overview Current Jan 2009

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

Page 46: Lotar 101 Overview Current Jan 2009

• 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

Page 47: Lotar 101 Overview Current Jan 2009

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

Page 48: Lotar 101 Overview Current Jan 2009

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

Page 49: Lotar 101 Overview Current Jan 2009

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

Page 50: Lotar 101 Overview Current Jan 2009

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

Page 51: Lotar 101 Overview Current Jan 2009

• 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

Page 52: Lotar 101 Overview Current Jan 2009

• 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

Page 53: Lotar 101 Overview Current Jan 2009

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

Page 54: Lotar 101 Overview Current Jan 2009

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

Page 55: Lotar 101 Overview Current Jan 2009

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?

Page 56: Lotar 101 Overview Current Jan 2009

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

Page 57: Lotar 101 Overview Current Jan 2009

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

Page 58: Lotar 101 Overview Current Jan 2009

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

Page 59: Lotar 101 Overview Current Jan 2009

• 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

Page 60: Lotar 101 Overview Current Jan 2009

• 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

Page 61: Lotar 101 Overview Current Jan 2009

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

Page 62: Lotar 101 Overview Current Jan 2009

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.

Page 63: Lotar 101 Overview Current Jan 2009

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.

Page 64: Lotar 101 Overview Current Jan 2009

• 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

Page 65: Lotar 101 Overview Current Jan 2009

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

Page 66: Lotar 101 Overview Current Jan 2009

• 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

Page 67: Lotar 101 Overview Current Jan 2009

• 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

Page 68: Lotar 101 Overview Current Jan 2009

• 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

Page 69: Lotar 101 Overview Current Jan 2009

+ ++ +

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

Page 70: Lotar 101 Overview Current Jan 2009

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

Page 71: Lotar 101 Overview Current Jan 2009

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

Page 72: Lotar 101 Overview Current Jan 2009

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

Page 73: Lotar 101 Overview Current Jan 2009

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

Page 74: Lotar 101 Overview Current Jan 2009

• 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

Page 75: Lotar 101 Overview Current Jan 2009

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.

Page 76: Lotar 101 Overview Current Jan 2009

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

Page 77: Lotar 101 Overview Current Jan 2009

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

Page 78: Lotar 101 Overview Current Jan 2009

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

Page 79: Lotar 101 Overview Current Jan 2009

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

Page 80: Lotar 101 Overview Current Jan 2009

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.

Page 81: Lotar 101 Overview Current Jan 2009

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

Page 82: Lotar 101 Overview Current Jan 2009

OAIS Model - INGEST Entity

Page 83: Lotar 101 Overview Current Jan 2009

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

Page 84: Lotar 101 Overview Current Jan 2009

OAIS Model - INGEST Entity

Page 85: Lotar 101 Overview Current Jan 2009

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

Page 86: Lotar 101 Overview Current Jan 2009

OAIS Model - INGEST Entity

Page 87: Lotar 101 Overview Current Jan 2009

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

Page 88: Lotar 101 Overview Current Jan 2009

OAIS Model - INGEST Entity

Page 89: Lotar 101 Overview Current Jan 2009

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

Page 90: Lotar 101 Overview Current Jan 2009

OAIS Model - INGEST Entity

Page 91: Lotar 101 Overview Current Jan 2009

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

Page 92: Lotar 101 Overview Current Jan 2009

OAIS Model - Archive Entity

Page 93: Lotar 101 Overview Current Jan 2009

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

Page 94: Lotar 101 Overview Current Jan 2009

OAIS Model - Archive Entity

Page 95: Lotar 101 Overview Current Jan 2009

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

Page 96: Lotar 101 Overview Current Jan 2009

OAIS Model - Archive Entity

Page 97: Lotar 101 Overview Current Jan 2009

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

Page 98: Lotar 101 Overview Current Jan 2009

OAIS Model - Archive Entity

Page 99: Lotar 101 Overview Current Jan 2009

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

Page 100: Lotar 101 Overview Current Jan 2009

OAIS Model - Archive Entity

Page 101: Lotar 101 Overview Current Jan 2009

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

Page 102: Lotar 101 Overview Current Jan 2009

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

Page 103: Lotar 101 Overview Current Jan 2009

OAIS Model - Data Management Entity

Page 104: Lotar 101 Overview Current Jan 2009

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

Page 105: Lotar 101 Overview Current Jan 2009

OAIS Model - Data Management Entity

Page 106: Lotar 101 Overview Current Jan 2009

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

Page 107: Lotar 101 Overview Current Jan 2009

OAIS Model - Data Management Entity

Page 108: Lotar 101 Overview Current Jan 2009

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

Page 109: Lotar 101 Overview Current Jan 2009

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

Page 110: Lotar 101 Overview Current Jan 2009

OAIS Model - Data Management Entity

Page 111: Lotar 101 Overview Current Jan 2009

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

Page 112: Lotar 101 Overview Current Jan 2009

OAIS Model - Data Management Entity

Page 113: Lotar 101 Overview Current Jan 2009

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

Page 114: Lotar 101 Overview Current Jan 2009

OAIS Model - Administration Entity

Page 115: Lotar 101 Overview Current Jan 2009

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

Page 116: Lotar 101 Overview Current Jan 2009

OAIS Model - Administration Entity

Page 117: Lotar 101 Overview Current Jan 2009

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

Page 118: Lotar 101 Overview Current Jan 2009

OAIS Model - Administration Entity

Page 119: Lotar 101 Overview Current Jan 2009

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

Page 120: Lotar 101 Overview Current Jan 2009

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

Page 121: Lotar 101 Overview Current Jan 2009

OAIS Model - Preservation Planning Entity

Page 122: Lotar 101 Overview Current Jan 2009

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

Page 123: Lotar 101 Overview Current Jan 2009

OAIS Model - Preservation Planning Entity

Page 124: Lotar 101 Overview Current Jan 2009

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

Page 125: Lotar 101 Overview Current Jan 2009

OAIS Model - Preservation Planning Entity

Page 126: Lotar 101 Overview Current Jan 2009

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

Page 127: Lotar 101 Overview Current Jan 2009

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

Page 128: Lotar 101 Overview Current Jan 2009

OAIS Model - Access Entity

Page 129: Lotar 101 Overview Current Jan 2009

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

Page 130: Lotar 101 Overview Current Jan 2009

OAIS Model - Access Entity

Page 131: Lotar 101 Overview Current Jan 2009

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

Page 132: Lotar 101 Overview Current Jan 2009

• 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

Page 133: Lotar 101 Overview Current Jan 2009

• 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

Page 134: Lotar 101 Overview Current Jan 2009

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]


Top Related