SIST EN 9300-210:2026

SLOVENSKI STANDARD
01-maj-2026
Aeronavtika - LOTAR - Dolgoročno arhiviranje in pridobivanje digitalne tehnične
dokumentacije, kot so podatki o 3D, CAD in PDM - 210. del: Podatki o
obvladovanju proizvodov v pogledu "kot je bilo zasnovano"
Aerospace series - LOTAR -LOng Term Archiving and Retrieval of digital technical
product documentation such as 3D, CAD and PDM data - Part 210: Product
management data in an "as designed" view
Luft- und Raumfahrt - LOTAR - Langzeit-Archivierung und -Bereitstellung digitaler
technischer Produktdokumentationen, wie zum Beispiel von 3D-, CAD- und PDM-Daten -
Teil 210: Produktmanagementdaten in einer "As Designed"-Ansicht
Série aérospatiale - LOTAR - Archivage Long Terme et récupération des données
techniques produits numériques, telles que CAD 3D et PDM - Partie 210: Données de
gestion des produits dans une vue « telle que conçue »
Ta slovenski standard je istoveten z: EN 9300-210: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-210
EUROPEAN STANDARD
NORME EUROPÉENNE
February 2026
EUROPÄISCHE NORM
ICS 01.110 Supersedes
English Version
Aerospace series - LOTAR -LOng Term Archiving and
Retrieval of digital technical product documentation such
as 3D, CAD and PDM data - Part 210: Product management
data in an "as designed" view
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 210 : Produktdokumentationen, wie zum Beispiel von 3D-,
Données de gestion des produits dans une vue " CAD- und PDM-Daten - Teil 210:
conforme à la conception " Produktmanagementdaten in einer "As Designed"-
Ansicht
This European Standard was approved by CEN on 2 February 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-210:2026 E
worldwide for CEN national Members.

Contents Page
European foreword . 3
Introduction . 4
1 Scope . 5
1.1 In Scope. 5
1.2 Out of Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Acronyms . 7
5 Business Use Cases for Product Management Data in an “as designed” view . 7
6 Explanation of the diagrams . 8
6.1 Reason for diagrams . 8
6.2 Attributes . 8
6.3 Property Sheet Concept . 9
7 A Word on Change. 10
8 Management Information . 10
9 Organization . 13
10 Product Design . 14
10.1 General. 14
10.2 Product Design – Product. 15
10.3 Product Design – Part . 15
10.4 Product Design – System . 15
10.5 Product Design – Breakdown . 16
11 Change Management . 19
12 Documents . 23
13 Access Security . 24
14 Option Effectivity . 25
14.1 Option Effectivity Introduction . 25
14.2 Option Effectivity Definitions . 26
14.3 Option Effectivity Managing Change . 27
15 Effectivity . 30
Annex A (informative) Metadata for Archive Packages . 33
Bibliography . 37

European foreword
This document (EN 9300-210:2026) 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 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 August 2026, and conflicting national standards shall
be withdrawn at the latest by August 2026.
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.
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.
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 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 number EN 9300–xxx. AIA will publish the standard under the number NAS 9300–
xxx. The content in the EN 9300 and NAS 9300 documents will be the same. The differences will be
noted in the reference documentation. For example, EN 9300 Geometric Dimensioning and Tolerancing
will be referenced in ISO 1101 and ISO 16792, and for NAS 9300 the same information will be
referenced in ASME Y 14.5M and ASME Y 14.41. The document formatting, etc., will follow that of the
respective editorial rules of ASD-Stan and AIA.
This document provides the Fundamentals and Concepts and approaches of EN 9300 and referenced
related standards with regard to the AIA-ASD LOTAR International Standards EN 9300-xxx structure.
The EN 9300 top level Standard comprises multiple parts (i.e. −001, −002, −100, −200 etc.) based on
business requirements and domain topic, (Basic Parts, Common Parts, Mechanical, Electrical etc.). This
document is part of the Product Data Management series (EN 9300-2xx), which can be seen in Table 1.
The EN 9300-210 scope is the “as designed” data used for type certification.
1 Scope
1.1 In Scope
From Clause 8 to Clause 15, the scope includes:
— Management Information;
— Product Design;
— Change Management;
— Documents;
— Application of PDM-specific metadata (in accordance with EN 9300-021);
— Definition of PDM-specific metadata for Archive Information Packages (AIP) (Annex A).
Common Meta Data archive package requirements defined in accordance with EN 9300-021.
A visual representation of the scope of this document can be seen in Figure 1. An overview of the
various parts in the EN 9300-200 series is provided in Table 1.

Figure 1 — Scope of EN 9300-210 As Designed
Table 1 — EN 9300 Part 200 series
Data domain specific part Document Number
Product Management Data in an as designed view EN 9300-210
Product Management Data in an as delivered/maintained view EN 9300-230
Product Management Data In-development (including
EN 9300-240
preliminary design review, critical design review, FAI, etc.)
Change documentation EN 9300-250
This document does not attempt to specify how to create an OAIS/LOTAR information package. Nor
does it address common issues in the archive domain, such as: snapshot vs. incremental archival
methods (which are determined as part of the implementation of an archive system), or package-to-
package linkages (Meta Data WG) or how to identify metadata for an archival package (Meta Data WG).
Integration of PDM metadata with other domain and common metadata will be in EN 9300-021.
The scope of EN 9300-210 is same as the EN 9300-001.
1.2 Out of Scope
This document does not attempt to specify how to create an OAIS/LOTAR information package. Nor
does it address common issues in the archive domain, such as: snapshot vs. incremental archival
methods (which are determined as part of the implementation of an archive system), or package-to-
package linkages (Meta Data WG) or how to identify metadata for an archival package (Meta Data WG).
Integration of PDM metadata with other domain and common metadata will be in EN 9300-021.
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, definitions and abbreviations 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/
Within the context of EN 9300 series the terms “Shall” and “May” shall be used per the US. Code of
Federal Regulations (CFR) Title 14 Aeronautics and Space, Chapter 1, Federal Aviation Administration
(FAA), Department of Transportation (DoT), Part 1, Definitions, and abbreviations, paragraph 1.3:
— “shall” is used in an imperative sense;
— “may” is used in a permissive sense to state authority or permission to do the act prescribed, and
the words “no person may…” or “a person may not…” means that no person is required, authorized,
or permitted to do the act prescribed;
— “includes” means “includes but is not limited to”.
4 Acronyms
For the purposes of this document, the following acronyms apply:
AIA Aerospace Industries Association
AIP archive information packages
ASD-STAN Association of Aerospace and Defence Industries of Europe – Standardization
BOM bill of materials
CAD computer-aided design
CAGE Commercial and Government Entity
CFR Code of Federal Regulations
DOT Department of Transportation
DUNS Data Universal Numbering System
ECCN export control classification number
FAA Federal Aviation Administration
FAI first article inspection
GDPR General Data Protection Regulation
IEC International Electrotechnical Commission
ISO International Organization for Standardization
ITAR International Traffic in Arms Regulations
LOTAR Long Term Archiving and Retrieval
MBOM manufacturing bill of materials
5 Business Use Cases for Product Management Data in an “as designed” view
The scenarios and use cases used to support EN 9300-210 include:
— S1 – Evidence of the baseline for verification, certification, or product liability:
— UC1.1 – Long term archiving of Type Design Configuration (certification);
— UC1.2 – Acquisition/divestiture resulting in transfer of Product Definition Data and Type Design
Data;
— UC1.3 – Verification of design compliance to requirements;
— UC1.4 – Ability to retrieve the design and verification data for the purpose of determining root
cause as part of an investigation involving product liability;
— UC1.5 – To support delivery of Type Design Configuration data to a customer;
— UC1.6 – Transfer of Ownership;
— UC1.7 – Change to Design;
— S2 – Reuse of design data as a starting baseline for design changes:
— UC2.1 – Changes to Product Definition Data resulting in a major or minor change to the Type
Design Data;
— UC2.2 – To support the modification of existing product (e.g. for spares purposes).
6 Explanation of the diagrams
6.1 Reason for diagrams
There is a diversity of Product Lifecycle Management (PLM) systems. This diversity reflects the
differences in terms and processes used to manage products. This document uses a simple
diagramming technique to supplement the textual content that is easy to understand and can be created
with presentation or drawing tools, which does not require expertise in formal modelling language.
The diagrams are based on graph theory and employ only two constructs: nodes and edges. This
document shall use the terms items and connections for nodes and edges, respectively. The term “item”
is a generic term for the object being represented (e.g. Design Item can be a CAD file, part, assembly,
etc.). Edges (connections) are directional; generally representing the connection in natural language.
This graph form is known as a “directed property graph”.
For example: “has part”. Thus a connection has “subject” side (the “from” side), and an “object” side (the
“to” side). Lastly, the diagrams omit cardinality information in the interest of simplicity. Cardinality can
easily be added once formal STEP models are developed. Individual diagrams are simplified so that they
focus on their particular subject and will not show all potential relationships.
NOTE In order to keep the diagrams concise, a variant of graph theory called hyper graph theory is used
where edges are permitted to connect to other edges (but not multiple nodes to multiple nodes).
6.2 Attributes
All nodes and edges (items and connections) have attributes. PLM systems are designed to be
customized. Therefore, this document mostly focuses on the minimum attribution.
The minimum attribution (Meta Data) for an item can include:
— type: the kind of thing the data item represents. For example, a person, a part, a product, a
document;
— name: the name or identifier (e.g. part number) assigned to the data and physical part as a unique
identifier (used for human readable consumption) and is different from the system generated
identifier for the object in the system;
— revision: the revision of the item as it undergoes changes;
— object ID: the internal (system) identity of the item that is unique within the system;
NOTE Typically, the triplet (type, name, revision) is also unique in a PLM system.
— timestamps: creation and modification;
— references to persons or systems acting as creator, modifier, and “owner”;
— status of item: especially whether it is (was) approved;
— description: an item often has a description, such as a title for a drawing item, or nomenclature for a
part item.
The minimum attribution for a connection is:
— the ID of the connection itself;
— the type of the connection itself;
— the ID of the FROM item;
— the ID of the TO item;
— the change management effectivity timestamps:
— Start: the date the connection was approved for use;
— Stop: the date the connection was deprecated for use;
— the change management effectivity authorizations:
— Start Authority: reference to the change document approving this connection;
— Stop Authority: reference to the change document deprecating this connection;
— timestamps: creation and modification;
— references to persons or systems acting as creator, modifier, and “owner”.
6.3 Property Sheet Concept
Since these minimum attributes are not sufficient, the notion of a “property sheet” is used which is a
container for the custom or PLM system-specific data that is needed. The name “property sheet” is
intended to convey a simple enumeration of attribute names, values, data types (string, Boolean,
number, date, etc.), and unit of measure. Such a set of properties shall be modelled in the diagrams as a
node with an edge named “has property” connecting it to an item or connection having the properties.
But that needlessly complicates the diagrams, since virtually any item or connection will have custom
properties. The Property Sheet concept can also be used to achieve other goals of a PLM system:
— Ad hoc properties: In this case, an item or connection can have multiple sets of properties. The extra
properties can provide attributes for a part that are unique to its part family. For example, a bolt can
have additional attributes of head type, length, etc.; whereas a nut can have inner and outer
diameter, lock nut indicator, etc.;
— Restricted properties: In this case, properties can be segregated when the values may be export
controlled or are proprietary information;
— Value added properties: during the lifecycle of the part, extra attributes, such as supplier, cost, plant,
etc. can be added by downstream business functions.
Figure 2 shows a visual depiction of the property sheet concept:
Figure 2 — Property sheet concept
A property sheet can be viewed a special kind of item with a type indicating the sort of properties it
contains. Since most systems do not actually model properties this way, the revisions of its base item
type and the properties can be synced, along with connections to change items.
7 A Word on Change
In general, PLM systems retain the complete history for a design. Changes to the data are stored and
identified. Individual elements are identified, such as part number, document number; and versions of
those elements are identified, e.g. rev A, B, or version 1.1, 1.2, etc.
— All released versions are retained.
— Every change is auditable (why, who, what, and when).
— Ideally, it should be possible to query the state of the PLM system at any time in the past and see:
— what was current and approved at that time;
— what was proposed or pending at that time;
— relationships between versions (e.g. in a branch and merge scheme typically used for software)
at a point in time.
In the following clauses, the reader will see statements to the effect that these objects are subject to
change control. Change is a fundamental aspect of PLM and permeates all aspects of product data.
8 Management Information
This clause shows the nodes/items and edges/connections within Management Information, seen in
Figure 3. Table 2 and Table 3 explain in detail the items/nodes and edges/connections, respectively.
Figure 3 — Management information
Table 2 — Management Information Nodes/Items
Name Description Notes STEP Relationship
Company The legal entity of the company. Generally, the nationality or P4000, “Organization”
country of incorporation is
key information for access
security.
Person Represents a person who has In some countries the place P4000, “Person”
approved, performed work, etc. of birth is required for access
needing certain information security. All require the
about the person. citizenship for access
security (for national export
control regulations).
Company The identifier of the legal entity This is generally represented P4000, “Organization.Id”
Identifier where work was performed. by a CAGE code and includes
street address and other
contact information.
Sometimes a DUNS number
is also used.
Role Represents the role of the For example: author, P4000,
person having signature engineer, checker, etc. “PersonOrganizationAssignment.
responsibility of a design item. Role”
Contract A business arrangement for the Contracts may concern the P4000, “Contract”
supply of goods or services. design of part version
objects, the delivery of
drawing objects, or the
execution of activity objects.
Name Description Notes STEP Relationship
Design This represents something in This shall be either an item P4000, e.g. “Part”, “Document”,
Item the Type Design that can be that represents a thing (like more in P4000
owned and changed. a drawing) or a connection
(like “has part”).
Table 3 — Management Information Edges/Connections
Name Description Notes STEP Relationship
Has Company — From: Company Laws governing this P4000, “OrganizationRelationship”
relationship vary from
— To: Company
country to country.
Indicates a legal
subsidiary relationship.
Has Business — From: Company Such relationships always P4000, “OrganizationRelationship”
Relationship have non-disclosure or
— To: Company
proprietary information
Indicates a partnership,
agreements which may be
supplier, etc.
used in access security. In
relationship between
some cases, there are
two legal entities.
contracts between the
companies.
Has Company P4000, “Organization.Id”
— From: Company
Identifier
— To: Company
Identifier
—
Indicates the locations
of a company or legal
entity.
Is Employer Of — From: Company The nationality of the P4000, “PersonInOrganization”
company may be used in
— To: Person
access security; perhaps
Indicates
overriding nationality of
employer/employee
the person. There may be
relationship.
layers of organization
between the Company
and Person. See Figure 4.
Is Manager Of This may be used for P4000,
— From: Person
certain approvals where “PersonInOrganizationRelationship”
— To: Person
one-over-one signoffs are
Indicates supervisory
required.
relationship.
Has — From: Person There may be layers of P4000,
Responsibility organization with “PersonOrganizationAssignment”
— To: a Design Item
responsibility for the
Indicates responsible
Design Item between the
persons in a design
Person and the Design
activity.
Item. See Figure 4.
Has Role — From: Has P4000,
Responsibility “PersonOrganizationAssignment.Role”
—
— To: Role
Indicate the role of the
person in the design
Name Description Notes STEP Relationship
activity.
Has Location Related to access and P4000, “AddressAssignment”
— From: Person
export controls.
— To: Company
Identifier
Indicates the physical
work location of the
person (employee).
Is Original — From: Company This value is never P4000,
Design Identifier altered, even when the “PersonOrganizationAssignment”
Activity ownership of the design with value Role set to “original
— To: a Design Item
item is sold or owner”
Indicates who created
transferred.
the design item
originally.
Is Transferred
P4000,
— From: Company
Design “PersonOrganizationAssignment”
Identifier
Activity with value Role set to “current
— To: a Design Item
owner”
—
Indicates the current
owner of a design item
if it has been sold or
transferred.
Has Contract — From: Has Business To identify who is P4000, “ContractAssignment”
Relationship responsible for the
Each company has an assignment to
activity related to the
the same contract. The contract
— To: Contract
design item for the
reference shows which companies
Indicates the governing
duration of the contract.
have a business relationship.
documentation
between two
companies.
9 Organization
Here is the diagram for “organization” which defines responsibilities within a company which may also
be necessary to model:
Figure 4 — Organization
Table 4 and Table 5 explain in detail the nodes/items and edges/connections, respectively.
Table 4 — Organization Nodes/Items
Name Description Notes STEP Relationship
Organization The name of an May also include the P4000, “Organization”
organization within a functional responsibility of
company. the organization.
Table 5 — Organization Edges/Connections
Name Description Notes STEP Relationship
Has — From: Company P4000, “OrganizationRelationship”
Organization
— To: Organization
—
Indicates which
company has the named
organization.
Is in — From: Person P4000, “PersonInOrganization”
Organization
— To: Organization
—
Indicates in which
organization a person
works.
Has — From: Organization P4000,
Responsibility “PersonOrganizationAssignment”
— To: a Design Item
with value Role set to “creator”
—
Indicates which
organization owns or
created a design item.
10 Product Design
10.1 General
This clause shows the nodes/items and edges/connections within Product Design at the product-level
(Figure 5), part-level (Figure 6), and system-level (Figure 7).
There is also a diagram for alternate breakdown (or views) of a product seen in Figure 8.
Table 6 and Table 7 explain in detail the nodes/items and edges/connections, respectively.
10.2 Product Design – Product
First is the focus on product:

Figure 5 — Product Focus
10.3 Product Design – Part
Second is the focus on part:
Figure 6 — Part Focus
10.4 Product Design – System
Third is the focus on system (an alternative breakdown of a product):
...