prEN 9300-002

SLOVENSKI STANDARD
01-januar-2026
Aeronavtika - LOTAR - Dolgotrajno arhiviranje in iskanje digitalne tehnične
dokumentacije o izdelkih, kot so podatki o 3D, CAD in PDM - 002. del: Zahteve
Aerospace series - LOTAR - LOng Term Archiving and Retrieval of digital technical
product documentation such as 3D, CAD and PDM data - Part 002: Requirements
Luft- und Raumfahrt - LOTAR - Langzeit-Archivierung und -Bereitstellung digitaler
technischer Produktdokumentationen, wie zum Beispiel von 3D-, CAD- und PDM-Daten -
Teil 002: Anforderungen
Ta slovenski standard je istoveten z: prEN 9300-002
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
November 2025
ICS 35.240.60; 49.020; 01.110; 35.240.30 Will supersede EN 9300-002:2018
English Version
Aerospace series - LOTAR - LOng Term Archiving and
Retrieval of digital technical product documentation such
as 3D, CAD and PDM data - Part 002: Requirements
Luft- und Raumfahrt - LOTAR - Langzeit-Archivierung
und -Bereitstellung digitaler technischer
Produktdokumentationen, wie zum Beispiel von 3D-,
CAD- und PDM-Daten - Teil 002: Anforderungen
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
© 2025 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 9300-002:2025 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 Requirements for LOng Term Archiving and Retrieval (LOTAR) . 5
6 General requirements . 7
6.1 General. 7
6.2 Principal requirements . 8
6.3 User acceptance requirements (AC) . 8
6.4 Legal demand requirements (LD) . 9
6.5 Security and integrity requirements (SI) . 9
6.6 Certification and qualification requirements . 11
6.7 Contractual requirements . 11
6.8 Refinement requirements . 11
7 Application of the OAIS reference model . 12
7.1 The open archive information system (OAIS) reference model . 12
7.2 Product data archiving using the OAIS model . 12
7.3 General requirements . 13
7.4 Data preparation (LOTAR) . 13
7.5 Ingest . 14
7.6 Archival storage . 15
7.7 Data management . 16
7.8 Administration . 20
7.9 Preservation planning . 20
7.10 Data access . 22
Annex A (informative) OAIS data flow . 24
Bibliography . 33

European foreword
This document (prEN 9300-002:2025) has been prepared by 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 document is currently submitted to the CEN Enquiry.
This document will supersede EN 9300-002:2018.
This document includes the following significant technical changes with respect to EN 9300-002:2018:
a) document completely revised.
Introduction
This document was prepared jointly by AIA, ASD-STAN, PDES, Inc., and the prostep ivip association.
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 the 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
document 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.
The standards will be published under two different standards organizations using different prefixes.
ASD-STAN will publish the standard under the European Standard (EN), number EN 9300-002. AIA will
publish the standard under the National Aerospace Standard (NAS), number NAS 9300-002. The
content in the EN 9300 series and NAS 9300 series standards will be virtually the same. The differences
will be noted in the reference documentation (i.e. for the EN 9300 series, information on geometric
dimensioning and tolerancing will be referenced in ISO 1101 and ISO 16792, and for the NAS 9300
series, the same information will be referenced in ASME Y14.5 and ASME Y 14.41). The document
formatting etc., will follow that of the respective editorial rules of the European Committee for
Standardization (CEN) and AIA.
This document specifies the requirements for the long-term preservation of digital product and
technical data. The EN 9300 series is a series of separate parts that elucidate various business
requirements, applicable domain specific methodologies and are extensible for future long-term
archiving formats and data management practices.
Within the context of the EN 9300 series, the terms “Shall” and “Should” are to be used per the CEN-
CENELEC Internal Regulations Part 3:2022.
1 Scope
This document specifies business requirements for processes intended to preserve digital data.
NOTE Data are stored and maintained for the purpose of retrievability and usability during the required
archiving period. In addition, for the purpose of some business requirements, data are authentically preserved
and accessed.
This document is intended to allow for different implementations based on a company’s specific
business environment.
This document is not intended to incorporate company specific requirements and does not dictate
specific organizational structures within a company. This document does not specify a design or an
implementation of an archive system. Actual implementations can distribute responsibilities or break
out functionality differently.
This document assumes that all requirements for configuration management of the product data are in
place and therefore are not specifically described in this document.
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 purpose 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
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 requirements shall 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 information on applicability, see EN 9300-001.
5 Requirements for LOng Term Archiving and Retrieval (LOTAR)
This clause discusses the requirements 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.
Many companies are migrating their design processes from using traditional hard-copy drawings and
documents to using digital data. New processes are also needed to archive digital data and preserve
access to it, in compliance with requirements appropriate to this new media. Some industries are
required to archive data for the life of a product, which can exceed 50 years. Over these time periods,
changes in technology impact the ability to retrieve and use product data. Organizations which use
digital product data need strategies and processes that maintain the usability of the data over multiple
generations of technology.
The cost of certain technologies varies over time. As technology ages, the cost of implementation, use,
and maintenance of that technology can provide economic pressure to move to a more current
technology. Newer technology generally provides additional business benefits, which are not reflected
in the figures for a cost and benefits comparison. At some point, regardless of cost, it can become
impractical or even impossible to use or maintain older technology due to lack of materials, equipment,
tools, and support for the technology.
Business requirements dictate the archiving of product data for long periods of time. It is generally not
feasible to maintain a single generation of technology over a period of 50 plus years. Over these time
periods, changes in technology impact the ability to retrieve, reproduce and use product data.
Organizations which use digital product data need strategies and processes that maintain the
reproducibility and usability of the data over multiple generations of technology. The retention periods
of digital data are broken into three categories as managed under a Master Records Retention plan:
a) Short Term — 0 - > 5 years. This includes data that have a short life cycle and has a small impact on
data systems used to manage this data.
b) Medium Term — 6 > 10 years. This time period includes data that have a medium life cycle and has
a minimum impact on the systems used to maintain this data (i.e. S/W Service Pack updates, etc.).
c) Long Term — > 10 years. This time period includes data that have a life cycle that exceeds ten years
and includes a major impact on the systems used to maintain this data (i.e. S/W Version upgrades -
Catia V4 – V5; PDM V1 – V2 etc.).

Figure 1 — Date retention periods
Development of new aerospace and defence projects increasingly demands the use of digital product
information for in-service support reasons, by the supply chain, and from the customers. The business
requirements described within this document are planned to be applicable for the full aerospace
product life cycle.
This document sums up the main business requirements for long term archiving of digital product data.
In some cases, the authentic preservation of design type information is requested; The EN 9300 series
describes related requirements applicable for this constraint (see also EN 9300-003).
Then, this document describes requirements for standardized processes (and associated technologies)
that ensure product data are retrievable, reproducible, and usable for the required retention period
(Figure 1). The long-term archiving and retrieval process is described in terms of the open archival
information system (OAIS) reference model (see ISO 14721) that provides a conceptual framework for
archive systems.
The long-term archiving and retrieval process is structured into sub-processes for:
Ingest: introducing new material into the archive;
Data management: managing the data and metadata;
Archival storage: managing the physical systems;
Administration: managing the operations of the archive;
Access: retrieving information and providing it to users; and
Preservation planning: planning the evolution of the repositories.
6 General requirements
6.1 General
This document focuses on the requirements of Long-Term Archival and Retrieval of digital Product and
Technical data.
NOTE Regulatory, legal, contractual, and business requirements can apply which can require digital data to
be available for specified periods of time which exceed the typical life cycles of the technologies used at the time
the data are created.
This document sums up the main business requirements for long term archiving of digital product data.
Although these requirements are not in themselves normative, when making data available over an
extended period, it is a fundamental principle that the contextual data needed to interpret the data are
also available. Contextual data includes, but is not limited to:
— file type (e.g. .txt);
— language (e.g. English, German, French, …);
— information model (e.g. ISO 10303 AP242, XML schema, …).
This document uses the OAIS reference to provide comparability with other approaches to keeping
information available. However, OAIS is a standard reference model for comparison, not a standard for
implementation. Consequently, this document defines requirements for processes (and associated
technologies) intended to make data available for the life of a product and does so in terms of the OAIS
model.
In dealing with traditional media, the differences between substantial change and unimportant
“surface” change are generally self-evident. For example, the yellowing of paper over time does not lose
the information contained, whereas the loss of pages of a document does. Archiving processes focus on
the preservation of the medium. For digital product data, the medium is unimportant, but the content
can be corrupted. The subject of the remaining parts of the EN 9300 series is the identification of the
information that shall be preserved and remain uncorrupted if digital product data are to be usable in
the future. The consequent refinement of processes and procedures shall be in place to ensure this.
This document addresses the archiving of digital product data required for product definition, such as
in three-dimensional geometric representations, associated dimensions and tolerances, material
properties, manufacturing data, etc., specification callouts, product structure and configuration control
data, etc. Other parts of the EN 9300 series cover more specifically the long-term archiving of, (e.g.
product and manufacturing information (PMI), composites, electrical systems, product analyses and
product simulation information).
This document also addresses managing the evolution of technologies required to ensure the
availability and usability of the data for the required archiving period.
This document is not intended to incorporate company specific requirements and does not dictate
specific organizational structures within a company. This document does not specify a design or an
implementation of an archive system. Actual implementations may distribute responsibilities or break
out functionality differently.
This document assumes that all requirements for configuration management of the product data are in
place and therefore are not specifically described in this document. If an organization chooses to
implement requirements beyond those outlined in this requirements document, those additional
requirements shall not conflict or negatively impact the requirements contained in this document.
By considering these digital data archiving requirements, organizations can develop a comprehensive
strategy for managing and retaining their digital assets while ensuring compliance, reducing costs, and
improving data accessibility.
6.2 Principal requirements
Within the aerospace industry, a lot of requirements are known for risk mitigation with respect to
certification and legal demands. The following list of requirements are categorized into:
— acceptance (see 7.1);
— legal (see 7.2);
— security (see 7.3);
— certification/qualification (see 7.4);
— contractual (see 7.5).
6.3 User acceptance requirements (AC)
The first requirement category covers users' acceptance of the archive capability through defined use
cases:
Table 1 — Requirements of category “Acceptance”
No. Requirement
AC1 Each document within an electronic archive SHALL be retrievable.
Each document SHALL be provided in a time frame as defined by required use cases (e.g. 3 days
AC2
required by CFR).
The resource requirements for archiving and access SHALL be determined by required use
cases, (e.g. offline storage vs online storage). Procedures SHALL be developed, deployed, and
AC3
audited to verify that retrieval and navigation capabilities are effective and maintained during
addition of new data and deletion of product data.
The data (a copy of the archived data) SHALL be available for dissemination for further use or
manipulation (preservation of the design intent), but possibly with limited functionality with
respect to the original source. (For example, one use case might only be required to visualize
AC4
the model and measure distances between the geometric entities, while another might require
updates to the model, which in turn entails that the original parametric information would need
to be preserved.)
A planned retention period SHALL be provided for archived items (documents/data), i.e. a
length of time after which an item SHALL be removed. An item SHALL be reviewed by
AC5
authorized personnel prior to removal. The Archive system records and provides a report of
items which have been removed from the archive.
6.4 Legal demand requirements (LD)
The second requirement category covers compliance with legal demands. Because of the fact that legal
demands (LD) are not fully described by laws, the following list of requirements covers the known and
expected demands:
Table 2 — Requirements of category “Legal demand”
No. Requirement
The format of archived design data SHALL preserve the ability to verify that a part or product
LD1
conforms to its archived definition.
The users SHALL be enabled to meet the provisions of relevant laws, including changes to those
LD2 laws, regarding data security and protection of data privacy over the life cycle of the archived
items.
The archive processes SHALL be auditable to demonstrate compliance to requirements.
LD3 Records of archived changes SHALL be kept within the archive which enable the ability to
verify compliance to requirements.
All documents in an archive SHALL be tagged according to product security requirements as
LD4
well as export control requirements and proprietary information agreements.
All documents in an archive SHALL be accessible based on access restrictions as provided by
LD5 access control requirements. Certain data have restricted access based on data type. (e.g. export
controlled, privacy information).
6.5 Security and integrity requirements (SI)
The next requirement category covers the various aspects of security and integrity. The first priority for
security and integrity is to retrieve the same content in a document as it was when originally created.
The second priority is that the content of a document is semantically understood in the same way as
when it was created (i.e. preservation of the design intent of the user by the formal description of the
key characteristics of the information to be preserved), measures should be provided which enable
checking of predefined properties (i.e. validation properties based on the essential information) of the
digital product documentation against given quality parameters.
Table 3 — Requirements of category “Security and integrity”
No. Requirement
The archive SHALL prevent the destruction of a document during its scheduled lifetime
S1
(retention period).
Each document SHALL be protected against unauthorized changes while archived. Each
S2
attempt SHALL be logged.
The document retrieved SHALL match search criteria according to a predefined relevant
S3
method.
All actions that change the organization and structure of data within the archives SHALL be
S4 recorded so that it is possible to retrieve of the original contents over the complete retention
period.
No. Requirement
Documentation and data structure (e.g. Product Structure, documents, physical documents, and
S5 product definition models) SHALL be retrievable and reproducible for the retention period
required. This can exceed a period of 50 years.
It is required to provide supporting evidence that the product met the design rules from the
S6 period when the design was archived. This evidence SHALL be provided by related approved
documentation (e.g. product definition and related approval records).
The integrity (ensure information is persistent and unaltered) of data for the period required,
S7
which can exceed a period of 50 years, SHALL be guaranteed.
The risk, expenses and costs arising from change of the archiving system, or its release SHALL
S8
be managed, (e.g. via a cost model).
Electronic archives SHALL be designed to allow migration to new platforms, media, software
S9
versions and components without loss of information.
The information content of the document SHALL not be changed during the archiving, retrieval
S10
and migration processes
Each document should be able to be displayed and represented consistent with the form as
S11
recorded. This ensures the archived data are unchanged.
The processes by which the document is inserted into an archive, migrated or retrieved from
the archive SHALL not delete or remove any document from the archive, and SHALL be
S12
certifiable to this effect Document removal is dictated by a retention schedule and determined
by an archive administrator.
The archive SHALL provide fixity information against each archived document / set of data.
S13
Evidence of security of an archive SHALL also be provided through a certified process.
The archiving system SHALL provide adequate measures when technically feasible to check
predefined properties within the documents which enable that information are understandable
by the Designated Community without the assistance of the information producers.
Furthermore, this requirement SHALL be supported where required by providing links to the
documents describing the correct interpretation of the context and content of an archived
S14
document.
It is required to provide the contextual information (methods, procedures, guidelines, …)
associated with the product information, in order to ensure its correct interpretation after
retrieving
An audit trail for the archiving process is required. This provides ensured information about
S15
the actions of relevant processes and SHALL provide evidence about what occurred.
Collection management is required. i.e. archiving processes which include CAD or PDM data,
S16 documents, etc. Supporting information SHALL be managed within the Archive Information
Packages (AIP).
S17 The archive SHALL record the information about the management of access rights.
All disposals SHALL be documented. It can be a solution to store the metadata of deleted data as
S18
a permanent record. The disposal process shall start after the retention period end.
6.6 Certification and qualification requirements
This category covers further requirements which SHALL be fulfilled for the archiving of type design
documents relevant for certification of a product.
Type certification is the official confirmation of the airworthiness of an aircraft type and the
airworthiness of aeronautical equipment by the authority, (e.g. FAA). Precondition is the submission of
the demonstration of compliance documents according to the type of investigation and the submission
of the type design documentation.
Qualification is the official documented and controlled process (methods and results) of verifying and
declaring conformance with each specification requirement. This is considered as demonstrating fitness
for the purpose as defined by the specification.
NOTE Based on an analysis of certification standards and guidelines, the LOTAR organization concluded that
requirements resulting from certification or qualification can be found in the following list below (not exhaustive):
— Acceptable Means of Compliance (AMC) and Guidance Material to Annex Ib (Part 21 Light) to Commission
Regulation (EU) No 748/2012;
— Code of Federal Requirements Title 14 Chapter I Subchapter C Part 21 (FAR-21);
— European Union Aviation Safety Agency - Commission Regulation (EU) No 748/2012 Part 21 (EASA-21)
6.7 Contractual requirements
This category covers requirements levied by a contract for a specific program or customer which may
further limit or extend requirements for data preservation. For the purposes of this document, the
requirements in Table 1, Table 2, and Table 3 address the potential requirements to be limited, and any
extended requirements imposed by contract are by definition not standard and are not addressed in
this document. Requirements related to archiving are usually delegated to the suppliers and partners
through contracts.
— Acceptance (see 7.1)
— Legal (see 7.2)
— Security (see 7.3)
— Certification and qualification (see 7.4)
6.8 Refinement requirements
The business requirements identify the business functions that the archive SHALL support, however
these give no detailed criteria for assessment as to whether a particular implementation meets those
requirements.
The OAIS reference model (see ISO 14721), provides a reference to compare different archiving
standards, but does not mandate any particular approach to the solution. It has been recognized that
OAIS gives a thorough and effective analysis of the archiving problem and can be used as the starting
point for defining a normative standard.
7 Application of the OAIS reference model
7.1 The open archive information system (OAIS) reference model
The problem of archiving data are not unique to the aerospace industry. In the aeronautics industry, the
Consultative Committee for Space Data Systems (CCSDS) developed the reference model for an open
archival information system (OAIS). This model is a framework for describing archiving systems and
processes. The OAIS model has been the basis of a number of archiving systems in several industries
and is considered a mature model. The OAIS functional model is separated into six functional entities
(Ingest, Archival Storage, Data Management, Administration, Preservation Planning and Access) and
related interfaces (Figure A.1).
The EN 9300 series is described in terms of the OAIS model, and requirements are allocated against the
elements of the OAIS reference model. A brief overview is described in EN 9300-003 and a summary of
the terms used in the model is provided in Annex A. For clarity, a detailed description of the operational
processes is included in the following subclauses (i.e. 7.2 through 7.10).
7.2 Product data archiving using the OAIS model
Product data are created throughout the complete product lifecycle. This data are authorized and
approved through controlled processes. The data for a particular product are archived in the archive for
the required archiving period. Users who require access to the product data can include regulatory
agencies, customers, organizations that support in-service operations, design organizations for updates
and re-use, etc. The use of an OAIS archive for the archiving of data is shown in Figure 2 below.

Figure 2 — Product data archiving using the OAIS model
In order to meet the anticipated requirements of the consumers, the key characteristics of the data
SHALL be identified. For example, for the automatic machining of a mechanical part, it is necessary to
archive the shape of the part together with associated tolerance information - these are the key
characteristics - whereas the loss of the part description would not affect the machining.
The detailed parts of the EN 9300 series (EN 9300-100 and above) identify one or more required uses
of an item of product data, the key characteristics derived from that requirement, the data elements that
support those key characteristics, and supporting verification and validation data needed to
demonstrate that the information is not compromised.
7.3 General requirements
The general requirements are specified in Table 4:
Table 4 — LOTAR general requirements
No. Requirement
GR1 System Preparation: There SHALL be a process in place to ensure that the Archiving System is
ready to accept submissions of information for being archived. The process SHALL include the
analysis of anticipated user requirements, and the definition of the Submission Information
Packages (SIP) used to support those requirements, including the definition of verification and
validation criteria.
GR2 Identification of Preservation Use Cases: The Producer and the Archive identify and
document the use cases that the Archive is intended to serve. Each use case SHALL define the
data needed to support the use case, and the reasons for keeping the data available, and define
and document the SIP content requirements needed to support each use case.
GR3 Categorization of digital product data to archive: For each category, the Producer and the
Archive SHALL define the digital product data to be preserved according to its key
characteristics. For example, for design and manufacturing of mechanical parts, a key
characteristic is the shape of the part. The EN 9300 series describes the key characteristics for
major types of digital product data. Additional categories may be defined by each company,
according to its specific needs.
GR4 Specification of the Descriptive Information of the SIP: The Descriptive information is used
to identify and locate the data provided through a SIP, and this Descriptive information SHALL
be the basis for the meta data of the archive system. The Descriptive Information for the source
information SHALL be specified and agreed by the Producer and the Archive.
GR5 Description of the quality control criteria: The Producer and Consumer SHALL identify the
quality control criteria that the data in each SIP SHALL meet, in order to ensure that the key
characteristics are present and can be verified.
GR6 Description of the derivation procedures for the SIP: If the Archive has to process the SIP to
generate derived representations, the process SHALL be documented and validated by the
Producer and the Archive during the system preparation phase and SHALL guarantee that the
key characteristics are preserved.
GR7 Quality Management System: The Archive SHALL follow a QMS in accordance with current
standards (e.g. ISO 9001, EN 9100 and AS 9100, etc.)
7.4 Data preparation (LOTAR)
Data preparation covers the phase of preparation for submission. The functions and information flows
comprising Data Preparation are illustrated in Figure A.1.
This leads to the detailed requirements in Table 5:
Table 5 — LOTAR requirements of category “Data preparation”
No. Requirement
Preparation of the Descriptive Information associated to each source product
D1 information: The Descriptive Information SHALL be prepared for each SIP. This Descriptive
Information has to be consistent with its related source product information.
Preparation of the verification information for each SIP: The Producer SHALL check the
D2 data submitted against the agreed quality rules data for the SIP. The verification report of each
product information has to be created and input to the Ingestion process of the Archive.
Preparation of the validation information associated to each source product
information: When technically feasible, the Producer SHALL check the quality control criteria
D3 (e.g. validation properties) of the information to be preserved. The validation report of each
product information has to be created, as associated input to the Ingestion process of the
Archive.
7.5 Ingest
The major functions of the OAIS Ingest entity are: Receive Submission, Quality Assurance, Generate AIP,
Generate Descriptive Information and Coordinate Updates. The functions and information flows
comprising the Ingest entity of the OAIS functional model are illustrated in Figure A.2.
This leads to the detailed requirements in Table 6:
Table 6 — OAIS requirements of category “Ingest”
No. Requirement
Approval Prior to Release: The identification of the approver(s) and evidence documenting
IN1 the approval SHALL be associated with the released product data, such as an electronic
signature.
Error Detection Methods: When the Quality Assurance process validates the SIP, an error
IN2 detection method, such as a checksum or cyclic redundancy check, SHALL be used. The error
detection data SHALL be associated with the AIP
Periodic Translation Audit: If the Generate AIP process translates the representation of the
product data, e.g. from a native representation into a neutral representation, a periodic
IN3
examination SHALL review the translation process to ensure that AIP accurately represents the
product data.
Content Modifications and Updates: If a Producer needs to modify the content of an archived
object, the archive SHALL require them to obtain a copy of the object through the Access
function. The Producer SHALL then modify the content and resubmit the object through the
IN4 Ingest function. This ensures the original object is maintained and the change history is
captured. In this case, the Ingest function SHALL capture how the content was changed from
the original; The identifier of the new object is changed (identifier, versions, iterations, .), in
comparison with the identification elements of the initial archived object.
Rights: Product data can be covered by rights that SHALL be protected. Measures SHALL be
provided to allow marking of information as proprietary information and its management
IN5 within the archiving system. Information regarding rights SHALL be associated with the
product data to ensure that during the Access function the information is appropriately marked
to provide the protection warranted by such product data.
7.6 Archival storage
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 in Figure A.3.
This leads to the detailed requirements in Table 7:
Table 7 — OAIS requirements of category “Archival storage”
No. Requirement
AS1 Notification of Storage Status: When a storage submission is complete, notification of the
storage completion SHALL be sent to the submitter.
AS2 Operational Statistics: Operational statistics of the storage media, available capacity and
usage SHALL be kept in order to monitor and adjust archive capabilities.
AS3 Archive Maintenance: The ability to reproduce the stored product data SHALL be
maintained over time. This includes auditing the archive to detect media degradation and
data corruption and migrating data to new storage media and operating/file systems when
necessary. Any of these changes have to be logged and documented.
AS4 Error Checking: Error checks SHALL be performed during transfers to ensure that
corruption is detected and addressed.
AS5 Auditing Requirements: Auditing is part of the Error Checking sub-function. Each
organization SHALL put in place policies on how often these audits need to be performed
based on their technology and business situation.
AS6 Auditing for Data Integrity Errors: An audit of the data stored in the archive SHALL be
performed periodically to ensure that the data in the archive has been maintained and has
not been corrupted or changed without authorization. During the periodic audit, the error
detection mechanism SHALL be calculated on the current data and compared with the value
recorded at the time the data was ingested into the archive. Discrepancies between these
two values indicate a data integrity problem.
AS7 Representative Sampling: During a periodic archive audit, a representative sample of the
data SHALL be checked for data integrity discrepancies.
AS8 Corrective Action Plans: For each discrepancy identified in an audit, a corrective action
plan SHALL be developed, reported and tracked.
AS9 Audit Reporting: Audit results SHALL be reported to the responsible persons or
organizations in accordance with internal auditing processes.
AS10 Documented Testing Procedures: All test scenarios and/or scripts used in the periodic
audits SHALL be documented and validated before use. These documents SHALL be
managed and configuration controlled.
No. Requirement
AS11 Disaster Recovery: The Disaster Recovery process SHALL include a plan and process to
ensure that appropriate information systems and data are available when needed after a
natural or human disaster. The plan and process SHALL address the following requirements:
Back-up: Data records SHALL be backed up.
Offsite Facilities: Back-up data SHALL be stored at a company-authorized separate and
secure facility.
Validation: Disaster re
...