prEN 9300-003

SLOVENSKI STANDARD
01-junij-2024
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: prEN 9300-003
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.

DRAFT
EUROPEAN STANDARD
NORME EUROPÉENNE
EUROPÄISCHE NORM
May 2024
ICS 01.110; 35.240.30; 49.020 Will supersede 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 - Langzeit-Archivierung
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 draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee ASD-
STAN.
If this draft becomes a European Standard, 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.

This draft European Standard was established by CEN 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.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.

Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without
notice and shall not be referred to as a European Standard.

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
© 2024 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 9300-003:2024 E
worldwide for CEN national Members.

Contents Page
European foreword . 3
Introduction . 4
1 Scope . 5
2 Normative references . 5
3 Terms and definitions . 5
4 Applicability . 5
5 Fundamentals for LOng-Term Archiving and Retrieval (LOTAR) . 5
5.1 General. 5
5.2 Invariance . 6
5.2.1 General. 6
5.2.2 Requirements for preserving digital data . 7
5.2.3 Retention period for storing digital data . 7
5.3 The product life cycle . 7
5.4 Stored form of product data . 9
5.4.1 General. 9
5.4.2 Detail level . 9
5.4.3 Representation vs presentation . 9
5.4.4 Format . 10
6 Archiving of digital product data . 10
6.1 Product information model and product model . 10
6.1.1 General. 10
6.1.2 Business application . 11
6.2 Long-term archiving and retention of product models . 11
6.2.1 General. 11
6.2.2 Identifying product data. 13
6.2.3 Business requirements and use cases for archival . 14
7 Fundamental concepts of long-term archival and retrieval of digital data . 15
7.1 General. 15
7.2 Introduction to Open Archive Information System (OAIS) – ISO 14721 . 15
ISO 10303 Standard for the Exchange of Product model data (STEP) . 17
8 Data descriptions . 17
8.1 Overview . 17
8.2 Data . 18
8.2.1 Archiving digital product information vs. archiving physical documents . 18
8.2.2 Data content . 19
8.2.3 Data quality assurance . 21
8.3 Mapping approach onto physical data representation . 24
8.4 Fundamentals for testing the LOTAR process and components . 25
8.4.1 General. 25
8.4.2 VP: Validation Properties . 26
Bibliography . 27

European foreword
This document (prEN 9300-003:2024) has been prepared jointly by AIA, ASD-STAN, PDES, Inc., AFNeT
and the prostep ivip Association.
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 document is currently submitted to the CEN Enquiry.
This document will supersede EN 9300-003:2012.
EN 9300-003:2012:
—
Introduction
The AFNeT association is an international non-profit association in Europe and has operated for more
than 30 years as a multi-sectoral “Think Tank” articulated with a “Do Tank”, with digital transformation
projects or standardization projects in many industries. These activities have led to the emergence of a
network of recognized and highly skilled actors from the manufacturing industry, IT businesses, and
research companies. Its members represent leading industrial companies, SMEs, French governmental
agencies, software vendors, universities, and research organizations. AFNeT has conducted voluntary
and innovative actions in order to develop competitiveness and innovation in industry by setting up
collaboration projects or programs in the industrial sectors (e.g. Aerospace and Defence, Automotive,
Rail, Shipbuilding, Nuclear, Energy) to enable the digital thread for the extended enterprise processes
such as Product Lifecycle Management, Supply-Chain Management, Manufacturing, Maintenance and
Operations, Integrated Logistics Support, and Identification. AFNet promotes the development, testing
and usage of a set of coherent international standards for supporting these activities, especially in the
PLM and the SCM domains.
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 ISO 10303, 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 Clause 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 Scope
This document specifies the fundamentals and concepts for the long-term preservation of digital
product and technical data. EN 9300 is a series of separate standard parts that elucidate various
regulatory and business requirements, applicable domain specific methodologies and are extensible for
future long-term archiving formats and data management practices.
EN 9300-003 will focus on the fundamentals and concepts of long-term archival and retrieval of digital
product and technical data.
2 Normative 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
3 Terms 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 Applicability
EN 9300 is a series of standards for 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 FprEN 9300-001.
5 Fundamentals for LOng-Term Archiving and Retrieval (LOTAR)
5.1 General
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 EN 9300. See Figure 1.

Published as ASD-STAN Standard at the date of publication of this document, available at: https://www.asd-
stan.org/.
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 Invariance
5.2.1 General
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, e.g. by 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. The system 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 Requirements 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. EN 9300 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 may 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 Retention 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 may 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 The 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:
1. represent major life cycle periods of the product’s evolution;
2. relate to the state of the system description or the system itself;
3. describe major progress and achievement of milestones;
4. 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 Tables 1 and 2).
Table 1 — Examples of life cycle stages
Stage Process objectives within stage
Concept — Specify stakeholder needs, goals, and objectives
— Explore solution feasibility
— Specify solution space, if feasible
— Evaluate technology readiness and associated risk
Development — Specify/refine system level requirements
— Specify/refine high-level architecture
— Specify/refine requirements decomposition
— Specify/refine complete system architecture
— Implement initial system
— Integrate, verify, and validate initial system
Production — Produce system
— Inspect/verify production system
a
Utilization — Deploy and operate system
a
Support — Sustained system capabilities
Retirement — Support archival or disposal of system
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.
Table 2 — Comparison of life cycle stages and NASA life cycle phases
Retirement
Concept stage Development stage Production stage Utilization
Support stage
stage
Pre-
Formulation Implementation
formulation
Pre-phase A: Phase A: Phase B: Phase C: Phase D: Phase E: Phase F:
Concept Concept- Prelim Final design System Operations Closeout
Studies tech design-tech and Integration and
development development fabrication and Test, Sustainment
Launch
5.4 Stored form of product data
5.4.1 General
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 Detail 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 Representation 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 Format
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. 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 may or may
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 may be archived
in parallel in a standard representation such as ISO 10303-xxx (STEP), which is openly documented,
and which may be stable for a much longer period than native formats.
6 Archiving of digital product data
6.1 Product information model and product model
6.1.1 General
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:
o 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;
o 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 subclause 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:
o 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);
o 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:
o 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 (Component Off The Shelf) application;
o in the context of certification and legal requirements, the original product model 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 Business 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 EN 9300 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 Long-term archiving and retention of product models
6.2.1 General
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 may 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:
— 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;
— an accurate representation is retained. An approximate representation may 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 Identifying 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 Business 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 EN 9300 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 in the EN 9300-1xx and 2xx series).
Figure 4 — Distinction of business requirements, business cases and use cases
7 Fundamental concepts of long-term archival and retrieval of digital data
7.1 General
To fulfil the scope for long-term archiving described in this document, EN 9300 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 may 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 may be
possible with other sectors such as the automotive or shipbuilding industries.
7.2 Introduction 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:
o negotiates and accepts appropriate information from information producers;
o obtain sufficient control of the information to ensure long term preservation;
o determine the scope of the designated community;
o ensure the information is understandable by the designated community without the assistance
of the information producers;
o 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;
o 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 parts 010-015. For more
information on the OAIS reference model, review ISO 14721.
7.3 ISO 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 we feel that 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 Da
...