Lotar 101 Overview Current Jan 2009

3,239 views

Published on

An overview of the LOTAR project, its goals, objectives and baseline implementation model.

Published in: Business, Sports
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,239
On SlideShare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
87
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Lotar 101 Overview Current Jan 2009

  1. 1. LOTAR 101 – A Project Overview Overview of LOng Term Archival & Retrieval (LOTAR) of digital product & technical data AEROSPACE INDUSTRIES ASSOCIATION
  2. 2. LOTAR Project on a page The 4 areas addressed by LOTAR…
  3. 3. Project History With the onset of Model Based Definition (MBD) development in January 1997, Rick Zuray, a member from the team was tasked to evaluate and develop a process to address the storage, retention and retrieval of 3D Product Definition produced by MBD methodologies. September 1998 an internal process was developed and accepted by the Certificate Management and the Aircraft Certification Offices of the FAA. The FAA requested that Rick Zuray meet with the Aerospace Industries Association (AIA) and charter a project to write a standard that to address the storage, retention and retrieval of 3D Product Definition Data that would be applicable to all civil aviation across America. The AIA Project was chartered under the Civil Aviation Council (CAC) under the Manufacturing Maintenance & Repair Committee (MMRC) in May 2000. The AIA team was formed and held it’s first meeting in August 2000. The AIA Standard was completed and released as ARP-9034 in Sept 2002. Polyline RP Released Aug 2000 Dec 2002 Jun 08 AIA Team IAQG Dec 2010 Jan 2009 Pilot Activity Jan Formed Charter Oct 07 – May 08 1997 Pilot Activity w/NIST, DS, PTC, UGS Standards Part 120V2 & Part 125V1 Development Sept Sept 2004 Dec 2007 Coord with other Industries AIAG, Jun 2008 Sept 2002 1998 EN9300-Part AIA-ASD Stan AIA-EIDS, Nuclear, NIST, etc. ARP-9034 NAS/EN9300-Part 2, 002 Released LOTAR MoU Released 5 ,7, 100, 110, 115 Ballot
  4. 4. Project History In October 2002 at the International Aerospace Quality Group (IAQG) meeting in Cincinnati OH, Rick was asked to work with Jean-Yves Delaunay and the European LOTAR effort that was being worked under the AECMA-Stan organization at the time and together develop a single set of harmonized standards that addressed the storage, retention and retrieval of 3D Product Definition Data across the entire Aerospace Industry. The Team was chartered in Dec 2002 and was Co-chaired by Rick Zuray , from Boeing and Jean-Yves Delaunay, from Airbus. The International team meets 5 times a year and has developed several parts to the base Standard which will be released under the name EN9300-Part-xx for Europe and NAS 9300-Part-xx for Americas. The standards will be the same context just published under AIA for the Americas and ASD-Stan for Europe for revenue purposes. The standards will be eventually adopted by ISO under a cover sheet. In 2005 AECMA-Stan was changed to ASD-Stan but the processes and documentation practices remain the same. In 2nd quarter 2008 Parts 2, 5, 7, 100, 110 and 115 was sent out for ballot and Part 120 v1 will be ready for ballot in Apr 2009. Polyline RP Released Aug 2000 Dec 2002 Jun 08 AIA Team IAQG Sep 2009 Oct 2008 Pilot Activity Jan Formed Charter Oct 07 – May 08 1997 Pilot Activity w/NIST, DS, PTC, UGS Standards Part 120V2 & Part 125V1 Development Sept Sept 2004 Dec 2007 Coord with other Industries AIAG, Jun 2008 Sept 2002 1998 EN9300-Part AIA-ASD Stan AIA-EIDS, Nuclear, NIST, etc. ARP-9034 NAS/EN9300-Part 2, 002 Released LOTAR MoU Released 5 ,7, 100, 110, 115 Ballot
  5. 5. Harmonization at the regional and International levels between Aerospace Manufacturers and PLM interoperability IAQG ISO TC20 Existing Planned (>2009) LOTAR International International Aerospace LOTAR AIA ASD Stan regional International LOTAR LOTAR association Website (Collaboration) Regional PLM interoperability PDES Inc ProSTEP iViP regional LTDR LOTAR CAX Implem. Forum association PDM Implem. Forum
  6. 6. Participating Companies and Regulatory Agencies Supporting LOTAR Space Division KC Plant
  7. 7. Harmonization at the regional and International levels between Aerospace Manufacturers and PLM interoperability IAQG ISO TC20 Existing Planned (>2008?) LOTAR International Standards NAS9300-xxx EN9300-xxx 9300-series 9300-001 Doc Structure 9300-010 Common Process 9300-100 CAD LTA Fund AIA ASD Stan 9300-002 Bus/Proc Reqs 9300-011 Data Preparation 9300-110 Explicit Geom LOTAR 9300-003 Fund & Concepts 9300-012 Ingest 9300-115 Explicit Assy LOTAR 9300-004 Description Methods 9300-013 Archival Storage 9300-120 Exp Geo & GDT 9300-005 Authent & Verif 9300-014 Retrieval 9300-125 Exp Assy & GDT 9300-006 Fund Architecture 9300-015 Removal 9300-130 Parametric Geo 9300-016 Test Suites 9300-007 Terms & References 9300-135 Parametric Assy 9300-017 Audits 9300-200 PDM series 9300-300 Config Mech PS 9300-400 Electrical 9300-201 xx 9300-301 xx 9300-401 xx PDES Inc ProSTEP iViP LTDR LOTAR CAX Implem. Forum PDM Implem. Forum
  8. 8. LOTAR Objectives Product Definition Data (PDD) creation, storage and distribution has significantly changed in the past 50 years. PDD is the source for “Type Design” as defined by the FAA. Generation 2 Generation 3 Generation 1 The first generation The third generation (2D and 3D: 2D Authority) (3D Only: 3D Authority) (2D only: 2D Authority) methods for PDD method is based on 3D creation were 2D the use of 2D 2D manual board parametric and drawings with relational design in design engineers 3D Model Base and manufacturing Data. The PDD engineers. This information is evolved into a 2D defined only in 3D CAD design method models that contain 3D which allowed the associative GD&T digital creation of and annotation to 2D drawing (without effectively replace a 3D model) The 2D the need for a 2D Drawing is the drawing Model Based Design authority. representation. The (MBD) 3D Model is the authority but low The second generation methods of PDD creation used only CAD end visualization is design methods which was based on use of 3D models and require to support output was both 2D models (drawings) and 3D CAD dataset to various end usages drive CAM/CAI. The 2D Drawing was the authority for most – thus U3D. factory usage with the exception of CAM/CAI.
  9. 9. LOTAR Objectives • For Digital Data, the challenge is that the data is often stored in a proprietary, native format and will most likely be un- interpretable over time. The use of a neutral archiving format safeguards the interpretability of the data for a much longer period of time, perhaps it’s entire retention period. • Archiving data in it’s native form requires periodic migration to the new release (version) and this method quite often leads to data loss and the repair can be costly. A typical technological obsolescence cycle of a CAD generation roll (i.e. CATIA V4 – V5) is 3 – 5 years. • Neutral forms make it easier to migrate the data based on the way that the Application Protocols (AP)s are structured. In addition, their life expectancy (obsolescence cycle) is significantly longer in duration.
  10. 10. LOTAR Requirements • Digital archives mandate that we capture and preserve information in such a way that the information can be accessed and presented at any time in the future. • An obvious challenge for archives of digital information is the limited storage lifetimes due to physical media decay. • Rest of the LOTAR requirements are Documented in EN/NAS 9300-Part002
  11. 11. The Simple Solution
  12. 12. Requirements • However, since hardware and software technologies evolve rapidly and much faster than the media decay, the real challenge lies in the technological obsolescence of the infrastructure that is used to access and present the archived information
  13. 13. Requirements • The obsolescence of storage technology (e.g. magnetic tape) is a significant risk that must be continuously addressed. • Inevitably, storage systems will be replaced, and data integrity must be ensured. • Define criteria and conditions for transferring data from an existing electronic data storage system when a new data storage system is implemented.
  14. 14. Requirements • To achieve the goal of re-instantiating archived information on a future platform, it is not sufficient to merely copy data at the bit level from obsolete to current media but to create “recoverable” archival representations that are infrastructure in-dependent, i.e. open and neutral, to the largest extent possible. Inevitably, storage systems will be replaced, and data integrity must be ensured.
  15. 15. Requirements • Data retention processes are managed and validated. • Media Migration • Data representation migration & translation • Incorporating data into repository • Accessing the data by users. • Interpreting Engineering/Design Intent, Assembly Product Structure, and Instance Location/Orientation. • Understand the effects of technology change and its impact on the data and repository systems. (i.e. Life Cycle Information Planning).
  16. 16. Life Cycle Information Planning • Each responsible company needs to ask the following questions in order to optimize and standardize their data retention process. • Why are we archiving the data? • Business Requirement • Regulatory Requirement • Organizational Requirement
  17. 17. Life Cycle Information Planning Life Cycle Information Planning • What information should we archive? • What is the configuration of the information? • What is the information context? • What is the format of the information and what form does it need to be stored in? • How long do we need to keep the data? • How frequently do we need to access the data? “Life Cycle Information Planning asks the question, how do we retain our product knowledge throughout the life of the product?”
  18. 18. Presentation - Representation • The essential requirements for the presentation of 3D Geometry with associated GD&T that have to be preserved in an OPEN format must enable: • Preservation of all the presentation properties of GD&T and specified annotation • Filtering with annotation plans • Ensure the bi-directional associativity between 3D Geometry and GD&T with specified annotation. • The LOTAR team is recommending the use of STandard the Exchange Product model data (STEP) as the OPEN and stable neutral format to store of geometric and technical data representations
  19. 19. Presentation - Representation • To preserve the exact presentation of 3D with GD&T “as annotation” • (e.g., annotation plane, position of the GD&T, size and colors of GD&T • To preserve the text and figures of GD&T and annotation as text and figures • To preserve the associativity between; • “GD&T”, 3D topology & shape representation and tree structure listing the GD&T • To preserve associated validation properties, ensuring end to end quality assurance of the data.
  20. 20. Product Data Lifecycle The Lifecycle of software & hardware is relatively short compared to the lifecycle of an aircraft. Currently, for CAD S/W versions roll between 6 & 12 months with generations ranging from 3-7 years. This is compared to an aircraft lifecycle of 70+ years Preservation Planning Ingest Repository Access Administration
  21. 21. Data Retention and Archive Model Data Retention and Archive Model • The following three categories distinguish retention periods of data: Short Term: This time frame is within one or two version rolls (i.e. Catia V5 R12 – R13; UGS NX3- NX4) Medium Term: This time frame is within one generation roll (i.e. Catia V4 – V5; UG 18 – NX1) Long Term: This time frame is over multiple generations (i.e. Catia V3 – V7; UG 16 – NX7)
  22. 22. LOTAR Nomenclature The use of CAD 3D mechanical information results in new risks for long term archiving, quite different from those encountered in the past for 2D drawings. The EN9300 standard defines rules and principles to be applied by the manufacturers. It defines, where possible, a mandatory a set of verification rules for the CAD model, based on an open international format, and it defines also validation properties to be created during the ingestion and to be checked during the retrieval process (See part EN9300-005). For CAD information, these verification and validation rules are in most cases based on thresholds, the values of which are not fixed in the standard, since the results are subject to numerical errors in the algorithms of the CAD applications. The EN 9300-100 standard identifies the point where it may be adapted by each manufacturer, according to its own specific processes and products. It is the responsibility of the manufacturer to document and apply the principles, with the appropriate thresholds, according to an analysis based on risk management, as illustrated in figure 6.
  23. 23. LOTAR Nomenclature Legal Requirements Business Requirements Other Certification Product Liability Suppt in Operation Design Reuse Functions to be supported after retrieval Use Cases (UC) Risk Management UC1 UC2 UC3 UC4 UCn Tolerance Tolerance CAD Data Associated Thresholds Thresholds Essential Validation Information to be Report Preserved (i.e. Set of Set of Geometry, Validation Verification Tolerance & Properties Rules Associated annotation, 1) Mandatory: 1) Mandatory: Verification technical data etc. 2) Optional: 2) Optional: Report 9300- Part xx
  24. 24. Open Archive Information System Model Data Retention and Archive model as defined by the LOng Term Archival & Retrieval of digital product & technical data (LOTAR) project co-led by Boeing and Airbus The Open Archive Information System (OAIS) model defines the processes and actors which ingest the data into an archive, and which provide services to consumers of the data, including both query and retrieval. The most subtle area, and possibly the least understood, is the construction of the web of information needed to correctly read the data once it has been retrieved. The LOTAR standard uses the OAIS reference model as a basic framework, providing specific guidance on specialized types of data; initially Mechanical CAD/CAM/CAI and non-geometric meta data. The problem here is not to be sure that the data comes in and out correctly, but that it is being correctly interpreted by the new generation of software. That is, if information is data in context, and the context is the application which interprets the data, then LOTAR looks at information retention. In short, how do we know that the design we look at in twenty years time is the same as the design we look at in our current system? LOTAR makes the assumption that we know what we need to archive. Lifecycle Information Planning asks the question, quot;how do we retain our product knowledge (i.e. Design Intent) throughout the life of the product?quot; This is wider than the OAIS question, quot;what do we need to be able to understand this particular package of data?quot;, rather asks quot;what data about a product should we keep?quot; Although the answer starts with obvious elements such as the design and the configuration, it soon gets into areas such as the preservation of design rationale, the processes by which the product was designed, and the organizational structures that enable those processes to operate.
  25. 25. Open Archive Information System Model Requirements Functional Integration Product Definition Bill of Material Build Definition Support Definition Simulations & Analysis Additional Data Product Data Lifecycle Management types Preservation Planning Producer Descriptive Descriptive Data Queries Info Info Results Management sets Access Ingest Archival Orders Storage Consumer Administration Based on: Other ISO 14721 “Open Archival Information System” Reference Model System” Customers Customer Support Finance Regulatory Agencies Inspectors Mechanics Suppliers (Internal/External)
  26. 26. High Level Data Flow (Proposed Implementation) Preservation Planning Remove per Data Data Archival Data Retention Preparation Ingest Storage Retrieval Period Administration Producer Data Preparation Consumer Data SIP Usage DIP Data Data AIP AIP Ingest Retrieval Remove Archive Archival per Ret. Storage Period Ingest of AIP pre-existing AIP data = Submission Information Package = Archival Information Package SIP = Dissemination Information Package AIP DIP
  27. 27. Lower Level Data Flow Data Preparation flow Start Start Data Prep Ingest Error handling for Data Prep Create Descriptive DC Info (DI) Manual Create VP N Auto Producer Create Initiate Create Select data Preservation data validation for Data Info Quality properties archiving (PDI) process Y|N Y Auto Create VP Create SIP Quality Data Data verification & validation DC = Submission Information Package = Archival Information Package SIP = Dissemination Information Package = Data Content AIP DIP
  28. 28. Data Retention and Archive Model Sean Barker - BAE Digital Signature Retention – Archiving model Auditable Implicit Invariance Not Required LONG TERM ARCHIVAL Legal Reqs Preserve Original Keep Data Available RETENTION Business Reqs Preserve Source Reuse Objectives Short Term Medium Term Retention Period Long Term Detail Level Accurate Approximate Representation Native Representation Derived Representation Format Presentation Standardized Format Stored Form
  29. 29. Data Retention and Archive Model The retention – archival model requirements shown previously lead to four main areas of consideration: Invariance: How important is it to ensure that digital data is not altered. Objectives: Why retaining the digital data is required. Retention Period: The required period of time the data is to be stored. Stored Form: The stored format of the digital data.
  30. 30. Data Retention and Archive Model To ensure that the information has not changed and provide evidential weight that the design intent has not changed, the following categories distinguish Invariance: Auditable: Where validation methods and test suites ensure that information cannot be changed without the change being detected. Implicit: Where the system is designed to prevent changes. The system must supervise activities which would result in changes of the digital data. The supervision, for example, could be realized within a separate write protected vault.
  31. 31. Data Retention and Archive Model For digital data, the challenge is that the data are often stored in a proprietary, native format and will most likely become un-interpretable over time. The objectives for keeping data are distinguished into two major categories: Legal/Certification Requirements: This includes proof of technical documentation that support Government & Regulatory laws. Business Requirements: This includes keeping knowledge of business processes and documentation.
  32. 32. Data Retention and Archive Model Four subcategories describe these objectives in more detail: 1) To preserve the original data (generated by a source system) so that it can be used as evidence of what the configuration of the data was at a particular point in time (i.e. date). This characteristic fits within the subcategory “Legal/Cert Requirement”. 2) To keep the data available to new users over the period in which it is kept. This characteristic fits with the subcategories “Legal/Cert & Business Requirement”
  33. 33. Data Retention and Archive Model Four subcategories describe these objectives in more detail: 3) To be able to preserve the source of the stored data. This characteristic fits with the subcategory “Business Requirement” 4) To be able to reuse the data (i.e. modify the design to meet new requirements). This characteristic fits with the subcategory “Business Requirement”.
  34. 34. Presentation - Representation Representation and Presentation of 3D Geometric shape, tolerance and annotation properties/attributes There is a key distinction between a representation and a presentation of data. In a representation, the computer holds the information/data about the concept. In a presentation the computer transforms the data representation into a human understandable form.
  35. 35. Presentation - Representation Representation and Presentation of 3D Geometric shape, tolerance and annotation properties/attributes The stored form has been divided into three categories: Detail Level: This is the description level of a model. Representation: This describes the different logical forms of data representation. Format: This describes the different physical formats of the data.
  36. 36. Levels of Information Representation Describes the exchange of reusable, associative GD&T information in a STEP file. This information is by itself not visible in the 3D model, but a CAD system importing this file can use the Representation data to re-create the visible GD&T information. The representation approach also aims to pass GD&T / PMI data on to downstream applications, such as CAM via AP238 for example.
  37. 37. Levels of Information Presentation Describes the exchange of GD&T information in a way that is visible for the user in the 3D model. There are four levels of presentation: Full Semantic Unicode symbols & text literal strings w/ext Minimum Semantic Polyline Presentation
  38. 38. Levels of Information Polyline Presentation This captures the information displayed for GD&T “as is”, by breaking down the annotations and symbols into individual lines and arcs. This approach is the only one independent from the Representation, and is not machine-interpretable.
  39. 39. Levels of Information Minimal Semantics Presentation – Adds a minimum set of display information to the Representation data (such as position in 3D space and a reference point on the model). Full Semantics Presentation – Adds all the positioning, styling and other information to the Representation, so that an importing system supporting this capability can fully re- create the GD&T information in the 3D model, by combining the information content from the Representation with the display settings given by the Presentation. Unicode.
  40. 40. Levels of Information Unicode Presentation STEP resource parts provide a number of pre defined symbols that can be used within the context of PMI (ref Unicode-STEP mapping Chart). There are a number of forms of such symbols; the two of most significance are terminator symbols (arrows etc.), dimension symbols and geometric tolerance symbols. For the former, each symbol can be considered as a distinct object which can be handled using the pre defined symbol form. However, while dimension and geometric tolerance symbols could be handled that way – that is not really the optimum way of supporting interoperability between CAD systems and STEP…...
  41. 41. Levels of Information Unicode Presentation cont. The reason for that is that within the CAD systems, the PMI data is typically handled as sets of character strings where the specific tolerance symbols are represented, in a proprietary way, within the string. It is possible to break the strings up and extract the symbols but in doing this the relationship of the tolerance symbols with the rest of the text is completely lost. In particular, the position of a symbol at a specific point within the string is lost. For example This could be handled as a single string within a CAD system but would result in one or two text literals in STEP together with three symbols which are–related only 7.8 – 8.2 2.4 2.8 by virtue of belonging to the same PMI; any sense of order would be lost. A better way of supporting this data which would maintain the wholeness of the data would be to map the whole string as a text literal and to use the Unicode characters to denote the symbols. This maintains the semantic information that the diameter range is 7.8 to 8.2 and the depth range is 2.4 to 2.8.
  42. 42. Presentation - Representation Detail Level: This is the description level of a model. An accurate representation is where data elements are described in the original level of detail, independent of whether they are represented in a native or other format. An approximate representation is where data elements are described in a reduced level of detail than the accurate representation, e.g. where a curved surface is approximated by a set of small, flat faces.
  43. 43. Presentation - Representation Representation: This describes the different logical forms of data representation. • A native representation is that created by and is proprietary to the source system format. • A derived representation is a transformation of the native data, which may be based on a native or standardized format (e.g., a .pdf may be derived from a text document as an alternative representation but the information context remains unaltered). • A presentation is a visualization of data to a user, (e.g., a 2D drawing, a capture or printed sketch of the product data representation).
  44. 44. Presentation - Representation Format: This describes the different physical formats of the data. • A native format is a specific format of data in a syntax which is proprietary and dependent on a specific system or interface. A native format depends directly on the lifecycle (versions, generations) of the related system or interface. • A standardized open format is a format of data in a syntax, which is defined by a broad community, such as ISO, and which is independent of specific system or interface. “Open” means completely and precisely documented in syntax and semantics and is applicable for free. In addition, standardization processes regulates the change processes for the standard.
  45. 45. Data Integrity via V&V Methods Verification & Validation of Preserved/Archived Represented Data • 3D data models are related to their geometric mathematical representation via the specific CAD system’s modeling function/application. • Interpreter (human view) is dependent on a proprietary CAD system to receive a representation of the data. The invariability of this representation has to be guaranteed. • Current testing shows a frequent occurrence of data representation changes by changing the representing CAD system.
  46. 46. Data Integrity via V&V Methods Verification & Validation of Preserved/Archived Represented Data • To assess the usability of the retrieved model the application and comparison of (geometric) validation properties it is the objective of a monitored testing process and system to evaluate practical thresholds in order to guarantee acceptable model quality. • As the accuracy of CAD modeling applications varies the testing processes and systems need to be updated to reflect the evolution of the change.
  47. 47. Data Integrity via V&V Methods Verification & Validation Process • In addition to verification rules the process must describe the tolerance parameters that serve as a threshold for their application in order to identify whether given geometric data can pass a certain rule or not. Applicable tolerance values need to be defined according to the use case and internal tolerance if the originating system and can not be standardized. • Verification methods are defined how to check these quality measures as data quality functions. The main purpose of these functions is to check the consistency and completeness of the (to be) archived geometric information in safeguarding a minimum integrity of the mathematical description.
  48. 48. Data Integrity via V&V Methods Verification & Validation Process • Two levels of data consistency checks can be distinguished. • Geometric information needs to be mathematically consistent, (i.e. all necessary parameters must exist and must have valid values). • Geometric information needs to be expressed according to a data format in a valid way. This does not imply the order of executing the consistency checks – this is rather depending on: • When are the checks to be applied (ingest, retrieval) • What is the subject of the checks (original data, data in a neutral format)
  49. 49. Data Integrity via V&V Methods Validation of explicit geometry at ingest to archive • This could be done directly by the neutral file converter or by a standalone analysis tool which should again create a analysis report file or a database entry with all mandatory and optional attributes for the target neutral model. • The usage of standardized standalone analysis tools and neutral report files supports the modular design of the archiving process. The source and target analysis results have to be compared before the converted neutral file is accepted for archiving.
  50. 50. Data Integrity via V&V Methods Validation of explicit geometry at ingest to archive • This comparison could be done by a comparison tool which will create a resultant analysis file. If the number of solids is equal in both analysis files and if the epsilon values of the validation properties are within the given tolerances, then the conversion was successful and all data should be stored in the Archive File Storage of the Archive Information Package (AIP). • These data are the target and source validation property analysis files, the report file of the comparison, which includes the Preservation Description Information (PDI) and the neutral model.
  51. 51. Approach • To achieve the goal of re-instantiating archived information on a future platform, it is not sufficient to merely copy data at the bit level from obsolete to current media but to create “recoverable” archival representations that are infrastructure in-dependent, i.e. open and neutral, to the largest extent possible. • Data retention processes are managed and validated . • Media Migration • Data representation migration & translation • Incorporating data into repository • Accessing the data by users. • Understand the effects of technology change and its impact on the data and repository systems. (i.e. Preservation Planning)
  52. 52. Approach • Develop an architecture that supports: • Data architecture containing: • Semantic representation • Open and Neutral forms • Data Quality and Validation • Process architecture: • Based on Open Archive Information System (ISO 14721) • ISO 10303 (STEP)
  53. 53. Overview of the NAS/EN 9300 STD approach Data Domain Specific Parts “Conf. Mechanical Product Electrical Analysis Systems CAD Geometry & assemblies Product Structure” Managt. Data Engineering P1xx P3xx P2xx P4xx P5xx P6xx Part 130: Part 135: Part 335 Composite CAD 3D param. CAD 3D param. TDM 3D Conf. Param Conf Mngt geometry assembly structure assy. structure P7xx? Change Mngt. with GD&T & F-F w. GD&T & F-F with GD&T & F-F P&O 2008? DR AF Date... Part 325 T Part 120: Part 125: TDM 3D Conf. CAD 3D explicit CAD 3D (explicit) Project Mngt assy. structure geometry assembly structure RE with GD&T & F-F : Release EN9300 with GD&T & F-F with GD&T & F-F L DR DR DR A A 110: FT FT : In preparation Part 115: Part AF Part 315 T CAD 3D (explicit) CAD 3D TDM 3D Conf. BA explicit geometry assembly structure LL Assembly structure : In ballot OT DR Q2 07? Q2/07? AF T Part 100: Part 300: Part 200: Fundaments & Fundaments & Fundaments & & concepts Q2/07? & concepts & concepts R 2° Part 10: Common Process EL B AL LO R Part 11: Data Preparation EL RE T RE RE RE L L L 1: L Part 2: Part 3: Part Part 4: Part 12: Ingest REL Common Requirements Fundamentals Common Methods RE Part 13: Archival Storage Process (V1) – V2 in ballot and concepts Overview L Q3/06 Part 14: Retrieval REL DR Parts A 7: FT Part 5: Part 6: Part RE Part 15: Removal L Authentication Functional Term and and Verification Architecture Part 16: Test Suites references Basic Parts 2008? Q4/06 Part 17: Audit Q4/06
  54. 54. Priority Stair step of entities to work Planned for Future Construction Development History and Working with Industry Parametrics Standards for Solution Domain specific Domain specific Domain specific (Electric, tubing, (Electric, tubing,(Electric, tubing, Must have to Systems) Systems) Systems) support LTA of Design Intent Composite Ply Composite Ply Composite Ply Composite Ply Information Information Information Information and Layup and Layup and Layup and Layup Geometry Geometry Geometry Geometry Geometry Tolerances Tolerances Tolerances Tolerances Tolerances & annotation & annotation & annotation & annotation & annotation (FT&A) (FT&A) (FT&A) (FT&A) (FT&A) 3D Solid 3D Solid 3D Solid 3D Solid 3D Solid 3D Solid Geometry Geometry Geometry Geometry Geometry Geometry & assembly & assembly & assembly & assembly & assembly & assembly
  55. 55. What are We Doing? Preservation of 3D Explicit Geometry with Associative Dimensions & Tolerances and Form Features Part 110: Preservation of 3D Explicit Geometry (Ref. Part 110 tutorial ) Part 120 V1: Preservation of 3D Explicit Geometry with associative GD&T Part 120 V2: Preservation of 3D Explicit Geometry with associative Form Features
  56. 56. Part 110: Business/Regulatory Requirements for LT Archiving of 3D CAD explicit geometry • Scope • Fundamental & concepts for Long Term Archiving (LTA) of 3D explicit geometry • Business specifications of 3D explicit geometry • Key characteristics of 3D explicit geometry • Use Cases of the archiving system (administration) • Definition of Core Model for explicit geometry
  57. 57. Part 110: Business/Regulatory Requirements for LT Archiving of 3D CAD explicit geometry • Definition of Core Model for explicit geometry • Verification rules and conformance classes of explicit geometry • Validation rules of explicit geometry • Overview of Information Packages (SIP, AIP and DIP) for explicit geometry and associated data flow • Description of Information Packages for the explicit geometry (files and metadata) • Overall description of test cases • Key performance indicators for monitoring
  58. 58. Part 110: Business/Regulatory Requirements for LT Archiving of 3D CAD explicit geometry •SCOPE of Part 1 • Axis and units • Representation • Geometry • Points, Curves, Surfaces • Topology • Vertex, Edges, Solids • Color and layers • Geometrical properties • Attached to geometry • Attached to a “Shape Aspect” / Form Feature • Part Properties
  59. 59. Part 110: Business/Regulatory Requirements for LT Archiving of 3D CAD explicit geometry • Certification • LTA of FAI (First Article Inspection) based on 3D MBD • Legal • Regulatory requirement to store Type design data of the life of the product • Re-use • Business requirement to be able to re-use design data for future derivatives etc. • Support in production operations • Manufacturing based on 3D MBD • Assembly based on 3D MBD • Documentation for Repairs
  60. 60. Part 110: List of Business use cases for LT Archiving of 3D CAD explicit geometry • Classification and definition by disciplines: • Mechanical, • Sheet Metal, • Electrical Harness, • Tubing, • Composites, ... • for each Business requirement: • Certification • Legal • Re-use • Support in production operations • and according to the main OAIS process: • Ingestion through Retrieval & Removal
  61. 61. Part 110, 120 V1 & V2: List of Business use cases for LT Archiving of 3D CAD explicit Geometry L-T-A Certification Support in operation Business requirements Legal aspects Re-use Preservation Preservation Preservation & Retrieval of & Retrieval of & Retrieval of 3D Explicit Geometry 3D Explicit GD&T 3D Explicit FF Context Use Case Use Case Use Case Use Case Use Case Use Case Use Case Use Case Use Case Use Case Use Case Use Case Key Characteristics Core Model Core Model Core Model “Explicit GD&T” “Explicit 3D geometry” “Explicit FF”
  62. 62. Part 110, 120 V1 & V2 Format Requirements for LTA of 3D explicit geometry •The LOTAR recommendation is to use a format based on an open standard, i.e., has to fulfill the following rules: • The data model is fully described according to the state of the art practices . • e.g., object modeling methods using UML or EXPRESS. • The format and the services implementing the data are described explicitly. • e.g., STEP Part21 or XML, SDAI / EXPRESS • The use of the standardized data is free of charge . • e.g., processing of the data is not “controlled” by patents on algorithms. • The updating process of the associated components are described and well accepted by the community of involved parties. • e.g., STEP ISO ballots procedures, OMG and W3C consortiums procedures.
  63. 63. Part 110, 120 V1 & V2: Definition of KC’s AS9100: Key Characteristics (KC): the features of a material or a part whose variation has a significant influence on product fit, performance, service life or manufacturability. AS9103: Key Characteristics for a part, subassembly or system are those selected geometrical, material properties, functional and/or cosmetic features, which are measurable, whose variation control is necessary in meeting Customer requirements and enhancing Customer Satisfaction. Note: Key Characteristics have to be explicitly identified, & described, during “Ingestion” and checked after “Access/Retrieve” entities. Key characteristics are related to the design intent which must be preserved, and to the use cases of Ingestion & Access/Retrieval. Geometric Validation Properties are a subset of Key Characteristics, used for end to end quality control.
  64. 64. Part 120 V1 & V2:Key characteristic entities of geometry and topology • The topological entities of higher level are preserved by validation properties this surface is a high level entity built with low level entities edges and points these wires and vertices are high level entities this solid is a high level entity built with low level entities faces, edges and points
  65. 65. Part 110, 120 V1 & V2: Example of modification of mathematical entities allowable for a KC For example a curve can change if its new model is “equivalent” for the business requirement (E.g., Control the manufacturing of a part, ...) Bezier Bezier Nurbs System 1 LTA Export in STEP System 2 3D modeler Preserved the type of entity of the 3D modeler based on source system based on Bezier curve => Bezier curve entity Nurbs curve The curve entity is a Key Characteristic. Its type is allowable to be changed by an equivalent entity
  66. 66. Part 120 V1 & V2: Preservation of semantic of 3D (geometry, topology) requirements • Capability of characterization – description • Capability of unique identification and preservation of this unique identification • Capability of end to end quality control based on validation properties • Each Key characteristic can be checked by an indicator to be defined • This indicator is measured and its value is compared to an agreed threshold.
  67. 67. Part 120 V1 & V2: Capability of characterization – description of each Key Characteristic • Capability to ensure the preservation of the semantics, and if transformation occurs, shall ensure the capability to control it individually (Through Audits) • If the user has intentionally created a face, the face has to be preserved • This face can be split into smaller faces during a transformation: e.g., 2 faces of a Sphere of CADDS5 => 6 faces of CATIA V5, • The traceability of the transformation has to be ensured and documented • The unique identifiers of the resulting faces has to be related with the unique identifier of the source entity
  68. 68. Part 120 V1 & V2: Key characteristics for mechanical parts • Global key characteristics • Volume of the part • Centre of gravity of the part • Wet Area of the part • Local key characteristics • Volume, Center of gravity, & Wet Area of a solid (If there are several solids in a part) • Center of gravity and wet area of the surface / face • For all « isolated » surfaces / faces, • By user selection for special « functional » surfaces / faces, • Center of gravity and length of an edge / curve • For all « isolated » edges / curves, • By user selection for special « functional » edges / curves, • Explicit conditions of tangency / curvature continuity • TBD
  69. 69. Part 120 V1 & V2: Key characteristics for mechanical parts Native part Building N control points: P1, ... PN, + located on the surface. ++ + + ++ In the CAD system, computation of the distance between Re-imported part Conversion the control points and the surface: : d1 to dN STEP part + SURFACE + Conversion ++ + + ++ Location of P1 to Surface is OK if PN associated d1 to dN < threshold with this surface distance
  70. 70. Examples of Mechanical 3D CAD information 3D parametric with GD&T 3D exact BREP + Form-Features (Results in 3D exact BREP + Form-Features) GD&T -Dimensions - Tolerances Features: Features: - Hole - Hole - Pocket - Pocket - Pad Annotations - Edge Fillet - Dimensions - Geom. Toler. 3D facetted BREP 3D exact BREP Part Body -Manifold solid Open body
  71. 71. Part 110, 120 V1 & V2: Illustration of generations of CAD systems for mechanical design CAD generation technology break 1980 1985 1990 1995 2000 2005 2010 2015 2020 2025 2030 Focus 3D surfaces of Part 110 3D Explicit Solid Focus + Dimensions 3D Explicit Solid Geometry of Part & Tolerances with GD&T (Geometric Dimensions & Tolerances) 120 V1 Focus Hole 3D Explicit Solid Geometry of Part General pocket with GD&T 120 V2 & machining Form Features General_outside_profile Focus Capability to update the of part using construction 3D parametric Geometry Future with Constructio History history / parametric Part
  72. 72. Part 110, 120 V1 & V2: Illustration of generations of CAD systems for mechanical design Explicit With assembly constraints With assembly form features With GD&T
  73. 73. Part II: Part 120 V1 Preservation of 3D Explicit Geometry Dimensioning and Tolerance
  74. 74. Part 120 V1: Available tolerances according to industry standards • Industry standards for 3D with GD&T • ISO 1101 & 16792 • US ASME Y14.5 & Y14.41 • Additional types of tolerances discussed • Average or nominal tolerancing • Specific to company rules
  75. 75. Part 120 V1: Selection of tolerances based on industry standard. FTA module Entities selection, Symbol already chosen then choice of the symbol Standard selection ISO 1101 & 16792 US ASME Y14.5 & Y14.41
  76. 76. Part 120 V1: Associating GD&T with related Features to enable viewer associativity. With FTA or Enovia DMU Viewer The emphasis should be on the data required for the All the associatively not on the on cti capability to highlight. geometrical e sel on entities related ati t no to the annotation An are highlighted (As highlighted) All the annotations Hole + (Semantic) related to the Ho le Tolerancing sel geometrical ec tio entity n (As highlighted)
  77. 77. Part 120 V1: Associating GD&T with related Features to enable viewer associativity. Enabling use of annotation planes to improve the visualisation of GD&T 1 n° n pla on ati t no An An not ati on p lan n °2
  78. 78. Part 120 V1: Requirement for the LT Archiving format like STEP AP214 Archive in LTA format Semantic annotations* and annotation planes must be preserved in LTA format… ... with a viewer (independent of native format) able to read this information. Native CATIA V5 data * Semantic means there is a relation between 3D entities and annotations, usable for other With highlighting Without highlighting tools (inspection software, gaps => usable => not calculator) understandable ! => Need of associativity between GD&T and explicit Form Features
  79. 79. Open Archive Information System Model Requirements Functional Integration Product Definition Bill of Material Build Definition Support Definition Simulations & Analysis Additional Data Product Data Lifecycle Management types Preservation Planning Producer Descriptive Descriptive Data Queries Info Info Results Management sets Access Ingest Archival Orders Storage Consumer Administration Based on: Other ISO 14721 “Open Archival Information System” Reference Model System” Customers Customer Support Finance Regulatory Agencies Inspectors Mechanics Suppliers (Internal/External)
  80. 80. OAIS Model - INGEST Entity This entity provides the services and functions to accept Submission Information Packages (SIPs) from Producers (or from internal elements under Administration control) and prepare the contents for storage and management within the archive. Ingest functions include receiving SIPs, performing quality assurance on SIPs, generating an Archival Information Package (AIP) which complies with the archive’s data formatting and documentation standards, extracting Descriptive Information from the AIPs for inclusion in the archive database, and coordinating updates to Archival Storage and Data Management.
  81. 81. OAIS Model - INGEST Entity The major functions of the OAIS Ingest entity are: Receive Submission, Quality Assurance, Generate AIP, Generate Descriptive Information and Co-ordinate Updates. The functions and information flows comprising the Ingest entity of the OAIS functional model are illustrated in the following diagram.
  82. 82. OAIS Model - INGEST Entity
  83. 83. 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.
  84. 84. OAIS Model - INGEST Entity
  85. 85. 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
  86. 86. OAIS Model - INGEST Entity
  87. 87. 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).
  88. 88. OAIS Model - INGEST Entity
  89. 89. 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.
  90. 90. OAIS Model - INGEST Entity
  91. 91. OAIS Model - Archive Entity The major functions of the OAIS Archive Storage entity are Receive Data, Manage Storage Hierarchy, Replace Media, Error Checking, Disaster Recovery and Provide Data. The functions and information flows comprising the Archive Storage portion of the OAIS functional model are illustrated
  92. 92. OAIS Model - Archive Entity
  93. 93. 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.
  94. 94. OAIS Model - Archive Entity
  95. 95. 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.
  96. 96. OAIS Model - Archive Entity
  97. 97. 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. .
  98. 98. OAIS Model - Archive Entity
  99. 99. 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
  100. 100. OAIS Model - Archive Entity
  101. 101. 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.
  102. 102. OAIS Model - Data Management Entity The major functions of the OAIS Data Management entity are Administer Database, Perform Queries, Generate Reports and Receive Database Updates. The functions and information flows comprising the Data Management entity of the OAIS functional model are illustrated in the following figure
  103. 103. OAIS Model - Data Management Entity
  104. 104. 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
  105. 105. OAIS Model - Data Management Entity
  106. 106. 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
  107. 107. OAIS Model - Data Management Entity
  108. 108. 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
  109. 109. 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
  110. 110. OAIS Model - Data Management Entity
  111. 111. 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
  112. 112. OAIS Model - Data Management Entity
  113. 113. 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.
  114. 114. OAIS Model - Administration Entity
  115. 115. 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
  116. 116. OAIS Model - Administration Entity
  117. 117. 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
  118. 118. OAIS Model - Administration Entity
  119. 119. 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
  120. 120. OAIS Model - Preservation Planning Entity The functions and information flows comprising the Preservation Planning entity of the OAIS functional model are illustrated in the following figure
  121. 121. OAIS Model - Preservation Planning Entity
  122. 122. 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
  123. 123. OAIS Model - Preservation Planning Entity
  124. 124. 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.
  125. 125. OAIS Model - Preservation Planning Entity
  126. 126. 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.
  127. 127. OAIS Model - Access Entity The major functions of the OAIS Access entity are: Coordinate Access Activities, Generate DIP and Deliver Response. The functions and information flows comprising the Access entity of the OAIS functional model are illustrated are illustrated in the following figure
  128. 128. OAIS Model - Access Entity
  129. 129. 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
  130. 130. OAIS Model - Access Entity
  131. 131. 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
  132. 132. References References • ISO-10303 STandard for the Exchange of Product model data (STEP) • ISO-14721 Open Archive Information System (OAIS) reference Model • AIA-ASD Stan LOTAR Process Standards (NAS/EN 9300-xx) • Application Integrated Construct (AIC) AIC-519 Geometric Tolerances
  133. 133. References • GDT RP Recommended Practices for Dimensions, Dimensional & Geometric Tolerances 6th Dec 2006 Recommended Practices for 3D associative text 20th • 3D Text RP April 1999 • Polyline RP Recommended Practices for GD&T Polyline Presentation June 2008 • ASME Y14.5M Geometric Dimensioning & Tolerancing 1994 • ASME Y14.41 Digital Product Definition Data Practices 2003 • ASME Y14.100 Engineering Drawing Practices 2004 • ASME Y14.36M Surface Texture Symbols 1994 • ISO 1101 Geometrical Product Specifications (GPS) 2004 • ISO 16792 Digital Product Definition Data Practices 2004
  134. 134. Contacts Jean-Yves DELAUNAY Rick ZURAY AIA – ASD Stan LOTAR project co-chair AIA – ASD Stan LOTAR project co-chair CAD-PDM Information Interoperability Technical Principal – PDM EMSA – Process Architect Systems Integration Processes & Tools Airbus The Boeing Company Office: (33) (0) 5 -61 -18-31-31 Office: (425) 717-2654 Mobile: (33) (0) 6 -76 -36-50-59 Mobile: (206) 778-6730 Mail to: jean-yves.delaunay@airbus.com Mail to: richard.s.zuray@boeing.com

×