SIST EN 9300-003:2026
(Main)Aerospace series - LOTAR - LOng Term Archiving and Retrieval of digital technical product documentation such as 3D, CAD and PDM data - Part 003: Fundamentals and concepts
General Information
- Abstract
This document specifies the fundamentals and concepts for the long-term preservation of digital product and technical data. The EN 9300 series specifies various regulatory and business requirements, applicable domain specific methodologies and are extensible for future long-term archiving formats and data management practices.
- Status
- Published
- Public Enquiry End Date
- 29-Jun-2024
- Publication Date
- 13-Sep-2026
- Technical Committee
- I13 - Imaginarni 13
- Current Stage
- 6060 - National Implementation/Publication (Adopted Project)
- Start Date
- 04-Sep-2026
- Due Date
- 09-Nov-2026
- Completion Date
- 14-Sep-2026
Overview
SIST EN 9300-003:2026 is a key European standard developed to establish the fundamentals and concepts for the long-term archiving and retrieval (LOTAR) of digital technical product documentation. Focusing on aerospace and other complex industries, this standard sets the essential foundation for safely preserving digital product data such as 3D models, CAD drawings, and Product Data Management (PDM) records throughout a product's lifecycle.
As part of the broader EN 9300 series, this document addresses the growing need to adapt data retention, technological, and regulatory practices for digital environments, guaranteeing that critical technical data remains accessible, authentic, and interpretable for certification, legal, and business uses long into the future.
Key Topics
- Long-Term Data Preservation: Outlines requirements for ensuring product and technical data remain unchanged (invariant), readable, and trustworthy over extended periods.
- Invariance of Digital Data: Defines levels of data protection-including auditable, implicit, and non-controlled invariance-to support legal and business needs.
- Retention Periods: Classifies data storage requirements as short-term, medium-term, and long-term, emphasizing the contrast between rapid software evolution and the lengthy lifecycle of aerospace products.
- Product Life Cycle Integration: Aligns archiving practices with all stages of the product lifecycle, from initial concept through design, production, use, support, and retirement.
- Data Representation & Formats: Distinguishes between accurate and approximate representations, machine-readable (representation), and human-readable (presentation) data, and promotes the use of open, standardized formats for information longevity (e.g., STEP/ISO 10303).
- Business & Legal Compliance: Details requirements driven by regulatory, certification, and business considerations for the secure retention and timely retrieval of technical documentation.
Applications
The SIST EN 9300-003:2026 standard delivers practical value by enabling organizations to:
- Ensure Compliance: Meet rigorous certification and legal retention requirements in aerospace, defense, automotive, shipbuilding, and other industries where product documentation must remain valid and traceable for decades.
- Enable Reliable Digital Transformation: Support digital Product Lifecycle Management (PLM) and supply chain integration by standardizing the archiving and retrieval of digital assets such as 3D CAD models, technical drawings, and PDM data.
- Facilitate Product Support and Maintenance: Sustain access to authentic product data for ongoing support, upgrades, audits, and regulatory investigations long after original software and systems may be obsolete.
- Guarantee Data Integrity: Use secure methods such as cryptographic hashes and standardized file formats to maintain data authenticity and safeguard engineering intent.
- Future-Proof Data Reuse: Allow organizations to effectively reuse or adapt historical data for new projects, technology updates, and extended service lives.
Typical users include aerospace manufacturers, system integrators, regulatory authorities, PLM software vendors, and other stakeholders involved in digital product data management.
Related Standards
To implement effective long-term archiving and retrieval strategies, organizations may consider the following related standards:
- EN 9300-007: Provides terminology and definitions for the LOTAR series.
- EN 9300-001: Scope and general principles for the EN 9300 series.
- ISO 10303 (STEP): International standard for the exchange of product model data, key for neutral and open archiving formats.
- ISO/IEC/IEEE 15288: Guidance on system and software engineering life cycle processes.
- EN 9300-005: References methods for authentication and verification of digital product data.
- ISO 14721 (OAIS): Reference model for Open Archival Information Systems, underpinning digital archiving best practices.
Adhering to SIST EN 9300-003:2026 strengthens digital continuity, regulatory compliance, and the integrity of technical product documentation across complex, long-lifecycle industries.
Relations
- Effective Date
- 02-Sep-2026
- Effective Date
- 02-Sep-2026
- Effective Date
- 02-Sep-2026
- Effective Date
- 02-Sep-2026
- Effective Date
- 02-Sep-2026
- Effective Date
- 02-Sep-2026
- Effective Date
- 02-Sep-2026
- Effective Date
- 02-Sep-2026
- Effective Date
- 02-Sep-2026
- Effective Date
- 02-Sep-2026
- Effective Date
- 02-Sep-2026
- Effective Date
- 02-Sep-2026
- Effective Date
- 02-Sep-2026
- Effective Date
- 02-Sep-2026
- Effective Date
- 02-Sep-2026
Get Certified
Connect with accredited certification bodies for this standard

BSI Group
BSI (British Standards Institution) is the business standards company that helps organizations make excellence a habit.

Bureau Veritas
Bureau Veritas is a world leader in laboratory testing, inspection and certification services.

DNV
DNV is an independent assurance and risk management provider.
Sponsored listings
Frequently Asked Questions
SIST EN 9300-003:2026 is a standard published by the Slovenian Institute for Standardization (SIST). Its full title is "Aerospace series - LOTAR - LOng Term Archiving and Retrieval of digital technical product documentation such as 3D, CAD and PDM data - Part 003: Fundamentals and concepts". This standard covers: This document specifies the fundamentals and concepts for the long-term preservation of digital product and technical data. The EN 9300 series specifies various regulatory and business requirements, applicable domain specific methodologies and are extensible for future long-term archiving formats and data management practices.
This document specifies the fundamentals and concepts for the long-term preservation of digital product and technical data. The EN 9300 series specifies various regulatory and business requirements, applicable domain specific methodologies and are extensible for future long-term archiving formats and data management practices.
SIST EN 9300-003:2026 is classified under the following ICS (International Classification for Standards) categories: 01.110 - Technical product documentation; 35.240.30 - IT applications in information, documentation and publishing; 49.020 - Aircraft and space vehicles in general. The ICS classification helps identify the subject area and facilitates finding related standards.
SIST EN 9300-003:2026 has the following relationships with other standards: It is inter standard links to SIST EN 9300-115:2018, SIST EN 9300-005:2017, SIST EN 9300-014:2014, SIST EN 9300-007:2025, SIST EN 9300-125:2024, SIST EN 9300-100:2018, SIST EN 9300-013:2014, SIST EN 9300-110:2018, SIST EN 9300-200:2018, SIST EN 9300-011:2014, SIST EN 9300-002:2018, SIST EN 9300-121:2024, SIST EN 9300-007:2017, SIST EN 9130:2020, SIST EN 9300-100:2026. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
SIST EN 9300-003:2026 is available in PDF format for immediate download after purchase. The document can be added to your cart and obtained through the secure checkout process. Digital delivery ensures instant access to the complete standard document.
Standards Content (Sample)
SLOVENSKI STANDARD
01-oktober-2026
Aeronavtika - LOTAR - Dolgotrajno arhiviranje in iskanje digitalne tehnične
dokumentacije o izdelkih, kot so podatki o 3D, CAD in PDM - 003. del: Osnove in
pojmi
Aerospace series - LOTAR - LOng Term Archiving and Retrieval of digital technical
product documentation such as 3D, CAD and PDM data - Part 003: Fundamentals and
concepts
Luft- und Raumfahrt - LOTAR - Langzeit-Archivierung und -Bereitstellung digitaler
technischer Produktdokumentationen, wie zum Beispiel von 3D-, CAD- und PDM-Daten -
Teil 003: Grundlagen and Konzepte
Série aérospatiale - LOTAR - Archivage long terme et récupération des données
techniques produits numériques telles que CAO, 3D et PDM - Partie 003 :
Fondamentaux et concepts
Ta slovenski standard je istoveten z: EN 9300-003:2026
ICS:
01.110 Tehnična dokumentacija za Technical product
izdelke documentation
35.240.30 Uporabniške rešitve IT v IT applications in information,
informatiki, dokumentiranju in documentation and
založništvu publishing
49.020 Letala in vesoljska vozila na Aircraft and space vehicles in
splošno general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
EN 9300-003
EUROPEAN STANDARD
NORME EUROPÉENNE
August 2026
EUROPÄISCHE NORM
ICS 35.240.30 Supersedes EN 9300-003:2012
English Version
Aerospace series - LOTAR - LOng Term Archiving and
Retrieval of digital technical product documentation such
as 3D, CAD and PDM data - Part 003: Fundamentals and
concepts
Série aérospatiale - LOTAR - Archivage long terme et Luft- und Raumfahrt - LOTAR - Langzeitarchivierung
récupération des données techniques produits und -bereitstellung digitaler technischer
numériques telles que CAO, 3D et PDM - Partie 003 : Produktdokumentationen wie zum Beispiel von 3D-,
Fondamentaux et concepts CAD- und PDM-Daten - Teil 003: Grundlagen and
Konzepte
This European Standard was approved by CEN on 12 July 2026.
CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2026 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 9300-003:2026 E
worldwide for CEN national Members.
Contents Page
1BEuropean foreword . 3
2BIntroduction . 4
1 5BScope . 5
2 6BNormative references . 5
3 7BTerms and definitions . 5
4 8BApplicability . 5
5 9BFundamentals for LOng-Term Archiving and Retrieval (LOTAR) . 5
5.1 13BGeneral. 5
5.2 14BInvariance . 6
5.2.1 26BGeneral. 6
5.2.2 27BRequirements for preserving digital data . 7
5.2.3 28BRetention period for storing digital data . 7
5.3 15BThe product life cycle . 7
5.4 16BStored form of product data . 9
5.4.1 29BGeneral. 9
5.4.2 30BDetail level . 9
5.4.3 31BRepresentation vs presentation . 9
5.4.4 32BFormat . 10
6 10BArchiving of digital product data . 10
6.1 17BProduct information model and product model . 10
6.1.1 33BGeneral. 10
6.1.2 34BBusiness application . 11
6.2 18BLong-term archiving and retention of product models . 12
6.2.1 35BGeneral. 12
6.2.2 36BIdentifying product data. 13
6.2.3 37BBusiness requirements and use cases for archival . 14
7 11BFundamental concepts of long-term archival and retrieval of digital data . 15
7.1 19BGeneral. 15
7.2 20BIntroduction to open archive information system (OAIS) – ISO 14721 . 15
7.3 21BISO 10303 Standard for the exchange of product model data (STEP) . 17
8 12BData descriptions . 17
8.1 22BOverview . 17
8.2 23BData . 18
8.2.1 38BArchiving digital product information vs. archiving physical documents . 18
8.2.2 39BData content . 19
8.2.3 40BData quality assurance . 21
8.3 24BMapping approach onto physical data representation . 24
8.4 25BFundamentals for testing the LOTAR process and components . 25
8.4.1 41BGeneral. 25
8.4.2 42BVP: Validation properties. 25
0BBibliography . 27
1BEuropean foreword
This document (EN 9300-003:2026) has been prepared ASD-STAN.
After enquiries and votes carried out in accordance with the rules of this Association, this document has
received the approval of the National Associations and the Official Services of the member countries of
ASD-STAN, prior to its presentation to CEN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by February 2027, and conflicting national standards shall
be withdrawn at the latest by February 2027.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document supersedes EN 9300-003:2012.
EN 9300-003:2012:
— document editorially revised.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
According to the CEN-CENELEC Internal Regulations, the national standards organizations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia,
Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland,
Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North
Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and the United
Kingdom.
2BIntroduction
The prostep ivip Association is an international non-profit association in Europe. For establishing
leadership in IT-based engineering it offers a moderated platform to its nearly 200 members from leading
industries, system vendors and research institutions. Its product and process data standardization
activities at European and worldwide levels are well known and accepted. The prostep ivip Association
sees this document and the related parts as a milestone of product data technology.
PDES, Inc. is an international non-profit association in USA. The mission of PDES, Inc. is to accelerate the
development and implementation of the ISO 10303 series, enabling enterprise integration and PLM
interoperability for member companies. PDES, Inc. gathers members from leading manufacturers,
national government agencies, PLM vendors and research organizations. PDES, Inc. supports this
standard as an industry resource to sustain the interoperability of digital product information, ensuring
and maintaining authentic longevity throughout their product lifecycle.
Readers of this document should note that all standards undergo periodic revisions and that any
reference made herein to any other standard implies its latest edition, unless otherwise stated.
Within the context of the EN 9300 series the terms “shall” and “should” are to be used per the TOC-2 NAS
Style Guide_2021 Clauses 3.1 and 3.2:
— “shall” is to be used in an imperative sense. All requirements will be prefaced with a “shall” statement
denoting mandatory compliance;
— “should” is to be used to indicate a recommendation. All non-mandatory requirements or statements
will be prefaced with a “should” statement denoting non-mandatory action;
— “includes” means “includes but is not limited to”.
1 5BScope
This document specifies the fundamentals and concepts for the long-term preservation of digital product
and technical data. The EN 9300 series specifies various regulatory and business requirements,
applicable domain specific methodologies that are extensible for future long-term archiving formats and
data management practices.
2 6BNormative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
EN 9300-007, Aerospace series — LOTAR — LOng Term Archiving and Retrieval of digital technical product
documentation such as 3D, CAD and PDM data — Part 007: Terms and definitions
ISO 14721, Space Data System Practices — Reference model for an open archival information system (OAIS)
3 7BTerms and definitions
For the purposes of this document, the terms and definitions given in EN 9300-007 apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp/
— IEC Electropedia: available at https://www.electropedia.org/
4 8BApplicability
The EN 9300 series is applicable to long-term archiving and retrieval of model-based product data.
Since technical product documentation, such as design documents, are generated, exchanged, and used
digitally, architecture, technology, processes, data formats, rules and regulations need to be adapted to
enable digital retention and long-term archiving. The EN 9300 series closes this gap as a standard for
long-term archival and retrieval of model-based product data.
For further explanation on applicability of this document and its series, see EN 9300-001.
5 9BFundamentals for LOng-Term Archiving and Retrieval (LOTAR)
5.1 13BGeneral
This clause discusses the fundamentals and concepts applicable to the long-term archiving and retrieval
of digital product and technical data domain. It provides detailed clarification of these concepts into a
context beyond basic definitions defined in EN 9300-007.
Various user communities such as aerospace and defence, automotive or shipbuilding demonstrate
specific needs for long-term archiving and retrieval of their product and technical data. This is noted in
their diverse retention and archival requirements as well as various data management processes.
This clause explains the major differences of the terms “retention” and “archival” and their relation to the
scope of the EN 9300 series. See Figure 1.
Figure 1 — Archival — Storage and retention
Companies within various industries need to keep data and records to fulfil, certification, legal and
business requirements. For most modern applications, this data is digital. These requirements fall under
four main categories regarding the retention of digital data:
invariance: how important is it to ensure that digital data is not altered;
requirements: why and for which cases preservation of digital data is required or not;
retention period: the required length of time for retaining digital data;
stored form: the stored format of the digital data.
The following subclauses describe these four categories and are the foundation for this document.
5.2 14BInvariance
5.2.1 26BGeneral
Invariance covers the need to ensure that the information has not changed over time and thus provide
evidential weight that the design intent has not changed.
Three sub-categories further clarify invariance:
— auditable – where validation methods and test suites ensure that information cannot be changed
without the change being detected;
An example of validation methods and test suites in the auditable subcategory includes the
comparison of stored secure hash algorithm (SHA) checksums of the record before and after
archiving – (refer to EN 9300-005 “Authentication and Verification”, ISO 16363).
— implicit – where the system is designed to prevent changes;
A system under the implicit subcategory shall supervise activities which would result in changes of
the digital data. The supervision, for example, could be realized within a separate write-protected
vault; e.g. write-once, read-many (WORM). The proof of “no change” is shown by an absence of
change having been recorded and by showing that the system itself is reliable.
— not required – where changes to data are not explicitly controlled.
Of the three, auditable invariance is the strongest, and is likely to be the most suitable where the
information is used in legal proceedings.
For long-term archiving and retrieval, invariance is mandatory to meet business, certification, and legal
requirements.
5.2.2 27BRequirements for preserving digital data
For digital data, the challenge is that the data are often stored in a proprietary, native format and will
most likely become non-interpretable after a certain amount of time. The use of a neutral archiving data
format safeguards the interpretability of the stored data for a much longer time, perhaps for the entire
retention period. The EN 9300 series recommends the use of standard formats for long-term archiving
rather than native formats, accompanied by regular and frequent migrations of storage media and, if
necessary, of data format. The use of secure archiving and retrieval processes ensures the data readability
and integrity within current and future systems. This includes the use of secure hash algorithms (SHA)
to ensure that archived data have not been altered over time. Such algorithms might need to be renewed
over time with a standardized procedure, when cryptographic technologies used become unsecure
(e.g. SHA1 replacement by SHA2). The main requirement is that the engineering or design intent is
preserved not necessarily the ones (1) and zeros (0).
5.2.3 28BRetention period for storing digital data
The life cycle of software and hardware is relatively short compared to the life cycle of aerospace and
shipbuilding. The life cycle of digital data can be described in terms of software versions and generations.
The release of a new software version within a generation in general alters only a small part of the
functionalities of the software without affecting the data format or data model. A generation change
occurs when the software used changes substantially, for example, to a new architecture and data model.
The change of a generation can result even in completely new data formats or eventually drop of support
of older data formats.
Currently, for CAD software, the period between versions is of the order of 6 months to 12 months, while
between generations is of the order of 4 years to 7 years. This should be compared to an aircraft or ship
life cycle which includes the life of individual product or program.
This leads to the following definitions:
short-term within one or two versions 0–5 years;
medium-term within one generation 6–10 years;
long-term over multiple generations ≥11 years.
5.3 15BThe product life cycle
The following excerpts from ISO/IEC/IEEE 15288 assist in providing a working understanding of life
cycle phases for the purpose of this document.
— Life cycle model: a framework of processes and activities concerned with the product life cycle that
is organized into stages. The life cycle models consider both the business and the technical needs of
all stakeholders. The stages are organized to provide a common reference for communication and
understanding.
— Stage: a period within the life cycle of an entity that relates to the state of its description or realization.
Stages within a system life cycle, alternatively referred to as “phases”, provide at least the following
benefits:
— represent major life cycle periods of the product’s evolution;
— relate to the state of the system description or the system itself;
— describe major progress and achievement of milestones;
— give rise to the primary decision gates of the development or product life cycle.
Life cycle models vary dramatically across system types and institutional practices, and no single list of
stages will encompass all models. The following list of generic stages provides a suitable foundation for
representing life cycle models used throughout industry, government, or defence (see Table 1 and
Table 2).
3BTable 1 — Examples of life cycle stages
Stage Process objectives within stage
— Specify stakeholder needs, goals, and objectives;
Concept
— explore solution feasibility;
— specify solution space, if feasible;
— evaluate technology readiness and associated risk.
— specify/refine system level requirements;
Development
— specify/refine high-level architecture;
— specify/refine requirements decomposition;
— specify/refine complete system architecture;
— implement initial system;
— integrate, verify, and validate initial system;
— produce system;
Production
— inspect/verify production system.
— Deploy and operate system.
a
Utilization
a — Sustained system capabilities.
Support
Stage Process objectives within stage
— Support archival or disposal of system.
Retirement
a
Utilization and support stages often run in parallel.
These generic stages can map to other life cycle models appropriate to the system type or institutional
practices. For instance, the following diagram shows a mapping between the generic definitions and the
life cycle phases specified by the NASA systems engineering process.
4BTable 2 — Comparison of life cycle stages and NASA life cycle phases
Utilization
Retirement
Concept stage Development stage Production stage
Support
stage
stage
Pre-
Formulation Implementation
formulation
Pre-phase A: Phase A: Phase B: Phase C: Phase D: Phase E: Phase F:
Concept Concept-tech Prelim Final design System Operations Closeout
studies development design-tech and integration and
development fabrication and test, sustainment
Launch
5.4 16BStored form of product data
5.4.1 29BGeneral
Stored form has been divided into three main subcategories:
— detail level: the description level of model;
— representation and presentation: describing the different logical forms of data representation and
presentation;
— format: describing the different physical formats of the data.
5.4.2 30BDetail level
— 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 lower level of detail than
the ac-curate representation, e.g. where a curved surface is approximated by a set of small, flat faces.
5.4.3 31BRepresentation vs presentation
A key distinction exists between representation and presentation of digital data. Within the
representation of digital data, the data is “machine readable” i.e. the computer holds the information
about the concept. However, in the presentation of digital data, the data is “human readable” in that the
computer holds a form in which its appearance is understandable to a human.
For example, the representation of a linear dimension includes all of the information needed to
understand the specification (e.g. the type of dimension, between which features it is defined), without
any of the graphic components such as dimension lines and extension lines, their direction, arrowheads,
and the dimension value.
Presentation relates to elements that are visible in the display of a 3D model and are either located
(positioned) in 3D space, i.e. they rotate and move with the model, or in a fixed 2D plane. Elements of
Presentation can typically be styled (e.g. coloured), organized (e.g. in specific views), and associated with
other elements of the model. Presented types of data typically are geometry (e.g. 3D shapes, surfaces,
curves, points) and characters (e.g. letters, numbers, symbols).
5.4.4 32BFormat
The format of data is a key driver for the level of accessibility as well as for how easy to use and how
reliable to retain information over time. For the core models data, representations and formats used shall
be open and standardized. “Open” means completely and precisely documented in syntax and semantics
and shall be applicable for minimal cast (e.g. series of ISO 10303 (STEP) is available for no more than the
publication costs). Standardization ensures the common understanding by the designated community
and public availability and stability over many years. Standardization processes ensure regulated change
processes.
Two main categories can be distinguished:
— a native format is a specific format of data in a syntax which is proprietary and dependent on a specific
system or interface with specific capabilities. A native format depends directly on the life cycle
(versions, generations) of the related system or interface and its functionalities;
— a standardized open neutral format is a format of data in a syntax, which is defined by a broad
community, such as by 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 regulate the change processes for the standard. It might or might not
provide the same level of functionality and data features to the users.
The motivation for including the accurate and approximate representation is that both can be archived
in parallel in a standard representation such as ISO 10303-XXX (STEP), which is openly documented, and
which can be stable for a much longer period than native formats.
6 10BArchiving of digital product data
6.1 17BProduct information model and product model
6.1.1 33BGeneral
With regards to the terms product information model and product model, which are defined in
EN 9300-007, it is important to further specify their context and use within a long-term archival and
retrieval system:
— the product information model represents an information model which provides an abstract
description of facts, concepts, and instructions about a product:
— such model can be e.g. the STEP application reference model (ARM) or STEP application
interpreted model (AIM)/module interpreted model (MIM) per ISO 10303-11;
— within the boundaries of long-term archival and retrieval of digital product and technical data it
is important to ensure that the product information model utilized sufficiently considers the four
main considerations presented in 5.1 and provides the minimum capabilities needed to fulfil legal
and business requirements;
— the product model represents an occurrence of a product information model for a particular product,
e.g. the geometric model of a part:
— product models can be further distinguished with regards to their persistence into (1) dynamic
or temporary product model (e.g. in internal memory of a computer) and (2) static product model
(e.g. in form of a file or as a database on permanent storage media);
— product models can be consulted and queried via applications only via the loading of the static
form of the product model into the dynamic form in memory of the same product model;
— additionally, there are different usages of a product model, optimized for different functions and
users’ intents. The EN 9300 series distinguishes:
— the working form product model, which is used for creation and modification by the native
application; it corresponds generally to the design stage of the product model; this working form
is often in the native format of the COTS (commercial off the shelf) application;
— in the context of certification and legal requirements, the original product model, which can be
stored in a native or standardized format as an authorized source to use. From the authorized
source copies are derived for downstream use.
Based on the above definitions, it is recommended that for the long-term archival and retrieval of the
original and accurate product models be in a static standardized product information model and stored
in an open format such as STEP. These product models, after retrieval, will be loaded in applications as
temporary dynamic forms, enabling the check of validation properties and specified operations
(e.g. consultation).
6.1.2 34BBusiness application
Product models are generated by the user inside business application, which are a piece of software
intended for the creation and modification of such models. That shall be converted in a standardized
product model for long-term archiving. Examples of business applications relevant for CAD product
models are: NX, Catia V5, CREO and others. Other examples of business applications relevant for PDM
Product models are: Teamcenter, Enovia, Windchill, and again others for domains such as MBSE.
In the scope of the EN 9300 series are also other types of business applications which allow processing
the product model according to a dedicated purpose beyond creation and modification. This purpose can
be:
— the visualization with possible 3D measurement;
— a type of simulation (e.g. FEA, CFD, aerodynamics);
— NC programming for manufacturing;
— CMM programming for quality verification and validation.
This shows that business applications provide a set of functions to cover a certain range of use cases for
processing of product models as illustrated in Figure 2.
6.2 18BLong-term archiving and retention of product models
6.2.1 35BGeneral
The starting point of the long-term archiving activity for a special type of product model is the description
of use cases that the retrieved product model will support. Some use cases for long-term archiving of 3D
definition models will result in visualization of information. Other use cases for long-term archiving of
finite element analysis models can result in replaying the simulation, in order to demonstrate that the
sub-assembly support the associated use cases.
The objectives for keeping the data are distinguished into two major requirement subcategories (see
Figure 2):
— legal requirements/certification requirements, such as proof of technical documentation for actions
in law;
— business requirements, such as keeping knowledge.
Figure 2 — Legal and business requirements
Within the two subcategories, this document offers four characteristics which describe the objectives in
more detail:
— to preserve the original data (generated by a source system) so that it can be used as evidence of what
data was at a particular date. This characteristic fits with the subcategory ʻlegal requirement’;
— to keep data available to new users over the period for which it is kept. This characteristic fits with
the subcategories ‘legal requirement’ and ‘business requirement’;
— to be able to preserve the source of the kept data. This characteristic fits with the subcategory
‘business requirement’;
— to be able to reuse the data, for example, by modifying design data to meet new requirements.
This characteristic fits with the subcategory ‘business requirement’.
As per definition in EN 9300-007, long-term archiving is understood as “storage of a copy of data in an
appropriate way for record, certification and legal purposes.”
The data will be preserved and kept available for a use within the archive and possibly for further re-use.
With certified conversion processes, the native data representation generated by the source system can
be converted into a representation which is appropriate for long term archiving. To fulfil legal and
certification requirements, the stored form can be an accurate or approximate representation of the
source:
— integrity shall be ensured by a secure hash algorithm;
— the data is retained over the long term;
— invariance is mandatory;
— business, legal and certification requirements are covered.
As per EN 9300-007, the term “retention” is “storage of data for reuse at a later date”.
The data are usually kept in their original source system and possible backed up in an approach to secure
them from data loss.
According to definitions of previous clauses, the scope of the EN 9300 series can be described as follows:
— specifying the reasons for archiving of digital data include business and certification as well as legal
requirements, keeping data available for reuse and preserving the original information;
— specifying good practice so that an accurate representation is retained.
An approximate representation can be retained as a means of validating the geometry of files recovered
from storage. Keeping the native representation is relevant only for short and medium terms. A
visualization (a presentation) supports the retrieval process and is optional.
6.2.2 36BIdentifying product data
Boundaries between stages are often soft, and activities associated with a given stage can bleed over into
adjacent stages. This is particularly true for large systems, where development within a particular
subsystem or feature leads or lags other areas of the system. Although these cross-stage activities occur
often, organizations govern transitions between stages using “gate reviews” designed to evaluate the
completeness of a particular stage before formally transitioning to the next (see Figure 3).
The frequency of gate reviews between stages can vary between life cycle models, but there are generally
at least two. The first evaluates the completeness of the design prior to its implementation or entry to
production. The second is the acceptance of the system by the system stakeholders before its transition
into operation. Entry into a gate review requires that specific life-cycle artefacts, such as operational
concepts, requirements and design specifications, be of sufficient maturity to support the evaluation of
readiness prior to the transition into the next phase. Collectively, these comprise the “gate review
entrance criteria.” The “gate review exit criteria” specifies the manner in which the review evaluates
these artefacts and ensures they meet the specified maturity/completeness. This includes resolution of
any discrepancies, deficiencies, or other action items developed during the review.
Historically, gate reviews are heavily dependent on documentation artefacts, but an enterprise should
leverage MBSE technologies to provide alternate means to support gate reviews. Some examples include:
a) model diagrams providing information otherwise collated into document tables;
b) table views generated within the modelling environment; or
c) documents auto-generated directly from the model using export templates.
A generic view product data using, MBSE data as an example, is generally organized around the systems
models represented by the following product structure views:
— as designed: the approved design (under revision control). Differs from an “in development” status
which limits use to the “as planned” baseline;
— as planned: the manufacturing product structure. Differs from the “as designed” baseline by only
including elements within a designated configuration (i.e. resolved), possibly reorganized for a
manufacturing sequence with consumables added;
— as built (embodiment): the configuration of a product instance after completion of build per the
“as planned” baseline as reflected in records of completed work. It differs from “as planned” baseline
due to resolution of nonconformance items and other exceptions reflected in the records of
completed work which comprise the “as built” baseline;
— as maintained: the configuration of a product instance as repairs and modifications are incorporated
over its lifecycle as reflected in records of completed work. Depending on organization and the use
case, “as maintained” can also be defined as design data available for incorporation into units in the
future, or during operation, but another organization is responsible for completing incorporation (e.g.
airline).
For each product lifecycle view, one or more use cases shall be specified, showing how to use the data.
The complete set of data to be archived depends on each use case and the reasons for archival. Each use
case has its own mandatory, conditional, and optional data.
Figure 3 — Life cycle view of product data
6.2.3 37BBusiness requirements and use cases for archival
The starting point for an archival procedure is the business case for archiving information. This is
elaborated through a series of use cases for which one or more core data models are specified. These core
models capture the information required by the business case (see Figure 4).
Process views are given for data preparation, ingest, archival storage and retrieval. The validation steps
and methods are clearly specified in ISO 14721. The validation steps and methods for drafting process
views laid out in the relevant parts of the EN 9300 series are considered normative.
The definition of data formats and their associated description methods facilitates ensuring the integrity
of the transformations between the source system, the archive, and the consumer system. To ensure the
integrity of data after conversion, data content, data quality, and validation properties are specified
(parts -1XX and -2XX in the EN 9300 series).
Figure 4 — Distinction of business requirements, business cases and use cases
7 11BFundamental concepts of long-term archival and retrieval of digital data
7.1 19BGeneral
To fulfil the scope for long-term archiving described in this document, the EN 9300 series is based on
international standards. The use of international standards raises the level of acceptance for the
designated community, and the level of interoperability between systems and data formats. The use of
standards improves the length of time the data can be kept, simplifies the definition of processes, system
architecture and implementation, as well as reduces costs by modularization and component re-use
based on standardized interfaces. The EN 9300 series already have the objective of harmonizing
requirements and approaches with the international aerospace community, which includes North and
South Americas, Europe and sections of Asia. By adapting ISO 14721, further harmonization can be
possible with other sectors such as the automotive or shipbuilding industries.
7.2 20BIntroduction to open archive information system (OAIS) – ISO 14721
LOTAR International decided to adopt ISO 14721 as a foundational framework that describes data
management and preservation functions and their relationships among entities in an archive
environment. (see Figure 5).
Figure 5 — ISO 14721 Open archive information model
— An OAIS-type archive is expected to meet certain minimum responsibilities:
— negotiates and accepts appropriate information from information producers;
— obtain sufficient control of the information to ensure long term preservation;
— determine the scope of the designated community;
— ensure the information is understandable by the designated community without the assistance of
the information producers;
— follow documented policies and procedures to ensure the information is preserved against
reasonable contingencies, and to enable the information to be disseminated as authenticated
copies of the original;
— make the information available to the designated community.
The OAIS model details a conceptual design for an archive, from data preparation, data storage, data
management throughout its lifecycle to verification and accessing the data from the archive. The model
includes primary components and their associated functions and relationships, to support customer
requirements.
OAIS focuses on five main process modules:
— preservation planning;
— data management;
— access;
— ingest;
— administration.
These five process modules are described in more detail in EN 9300-010 to EN 9300-015. For more
information on the OAIS reference model, review ISO 14721.
7.3 21BISO 10303 Standard for the exchange of product model data (STEP)
LOTAR International decided to initially adopt ISO 10303 STEP as a foundational framework that
describes data exchange, interoperability, and long-term storage and their relationships among entities
in a model-based environment. The major deciding factor that led us to choosing STEP initially is the fact
that it has a long successful track record of exchanging data across multiple CAD/CAM platforms. There
are other data exchange platforms that have emerged since then and can certainly be used, however, for
use with a LOTAR system those options are limited.
ISO 10303 is an international standard for the computer sensible representation and exchange of product
data. The objective is to provide a mechanism capable of describing product data throughout the lifecycle
of a product, independent of any particular system. The nature of this description makes it suitable not
only for file exchange, but also as a basis for implementing and sharing product databases and archiving.
8 12BData descriptions
8.1 22BOverview
The fundamentals of this document aim to ensure the integrity of data and the authenticity of the
associated provenance information.
To ensure the integrity of data after conversion, data content, data quality and validation properties are
specified in specific parts of the EN 9300 series (see Figure 6).
Figure 6 — LOTAR domain specific parts and STEP
The definition of data formats an
...



