FprEN 9300-210

SLOVENSKI STANDARD
oSIST prEN 9300-210:2024
01-junij-2024
Aeronavtika - LOTAR - Dolgoročno arhiviranje in iskanje 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: prEN 9300-210
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
oSIST prEN 9300-210:2024 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

oSIST prEN 9300-210:2024
oSIST prEN 9300-210:2024
DRAFT
EUROPEAN STANDARD
prEN 9300-210
NORME EUROPÉENNE
EUROPÄISCHE NORM
May 2024
ICS 01.110; 35.240.30; 49.020
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 CAD 3D et PDM - Partie 210: Produktdokumentationen, wie zum Beispiel von 3D-,
Données de gestion des produits dans une vue " telle CAD- und PDM-Daten - Teil 210:
que conçue " Produktmanagementdaten in einer "As Designed"-
Ansicht
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-210:2024 E
worldwide for CEN national Members.

oSIST prEN 9300-210:2024
prEN 9300-210:2024 (E)
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 Applicability . 6
5 Business Use Cases for Product Management Data in an “as designed” view . 7
6 Explanation of the diagrams . 7
6.1 Reason for diagrams . 7
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 Product Design – Product. 14
10.2 Product Design – Part . 15
10.3 Product Design – System . 15
10.4 Product Design – Breakdown . 16
11 Change Management . 18
12 Documents . 22
13 Access Security . 23
14 Option Effectivity . 24
14.1 Option Effectivity Introduction . 24
14.2 Option Effectivity Definitions . 25
14.3 Option Effectivity Managing Change . 26
15 Effectivity . 29
Annex A (informative) Metadata for Archive Packages . 32
Bibliography . 36

oSIST prEN 9300-210:2024
prEN 9300-210:2024 (E)
European foreword
This document (prEN 9300-210:2024) 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.
oSIST prEN 9300-210:2024
prEN 9300-210:2024 (E)
Introduction
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.
Within the context of EN 9300 series the terms “Shall” and “May” are 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.
— “Includes” means “includes but is not limited to”.
oSIST prEN 9300-210:2024
prEN 9300-210:2024 (E)
1 Scope
1.1 In Scope
From EN 9300-210, from Clause 8 and above, the scope includes:
— Management Information;
— Product Design;
— Change Management;
— Documents;
— Application of PDM-specific metadata (see EN 9300-21);
— Definition of PDM-specific metadata for Archive Information Packages (AIP).
Common Meta Data archive package requirements defined in EN 9300-21.
A visual representation of the scope of this document can be seen in Figure 1.

Figure 1 — Scope of EN 9300-210 As Designed
oSIST prEN 9300-210:2024
prEN 9300-210:2024 (E)
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
1.2 Out of scope
This document does not attempt to describe 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). For
integration of PDM metadata with other domain and common metadata, see EN 9300-21.
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 References
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/
4 Applicability
The scope of EN 9300-210 is the same as that of EN 9300-001.
oSIST prEN 9300-210:2024
prEN 9300-210:2024 (E)
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. In our usage,
we typically will 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, which we call the “from” side, and an
“object” side, which we call the “to” side. Lastly, the diagrams omit cardinality information in the interest
of simplicity. We believe that 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, we use a variant of graph theory called hyper graph theory where
edges are permitted to connect to other edges (but not multiple nodes to multiple nodes).
oSIST prEN 9300-210:2024
prEN 9300-210:2024 (E)
6.2 Attributes
All nodes and edges (items and connections) have attributes. PLM systems are designed to be customized.
Therefore, our team 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”.
oSIST prEN 9300-210:2024
prEN 9300-210:2024 (E)
6.3 Property Sheet Concept
Since these minimum attributes are not sufficient, we use the notion of a “property sheet” 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 could be modelled in our 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 might have multiple sets of properties. The
extra properties might provide attributes for a part that are unique to its part family. For example, a
bolt might additional attributes of head type, length, etc.; whereas a nut may have inner and outer
diameter, lock nut indicator, etc.
— Restricted properties: In this case, properties might 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. might 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 may be synced, along with connections to change items.
oSIST prEN 9300-210:2024
prEN 9300-210:2024 (E)
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, you should be able 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
oSIST prEN 9300-210:2024
prEN 9300-210:2024 (E)
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
requiring certain information security. All require the
about the person to be retained. 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.
Design This represents something in This could 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.
oSIST prEN 9300-210:2024
prEN 9300-210:2024 (E)
Name Description Notes STEP Relationship
Has Company —  From: Company  P4000, “Organization.Id”
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 —  From: Person This may be used for P4000,
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
activity.
Has Location —  From: Person Related to access and P4000, “AddressAssignment”
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.
oSIST prEN 9300-210:2024
prEN 9300-210:2024 (E)
Name Description Notes STEP Relationship
Is Transferred —  From: Company  P4000,
Design Identifier “PersonOrganizationAssignment”
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 To identify who is P4000, “ContractAssignment”
Business responsible for the
Each company has an assignment to
Relationship activity related to the
the same contract. By referencing the
design item for the
—  To: Contract contract, you can see which
duration of the contract.
companies have a business
Indicates the governing
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.
oSIST prEN 9300-210:2024
prEN 9300-210:2024 (E)
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
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.1 Product Design – Product
First is the focus on product:

Figure 5 — Product Focus
oSIST prEN 9300-210:2024
prEN 9300-210:2024 (E)
10.2 Product Design – Part
Second is the focus on part:
Figure 6 — Part Focus
10.3 Product Design – System
Third is the focus on system (an alternative breakdown of a product):

Figure 7 — System Focus
oSIST prEN 9300-210:2024
prEN 9300-210:2024 (E)
10.4 Product Design – Breakdown
This diagram depicts alternative breakdowns or views of the product, which may be full or partial.

Figure 8 — Breakdown Focus
Table 6 — Product Design Nodes/Items
Name Description Notes STEP Relationship
Part Indicates a design item A physical part and its P4000, “Part” and
(not a physical part). connections are detailed in “PartVersion”
EN 9300-230. depending on
implementation (e.g.
how the PDM system
refers to parts and
assemblies).
Product Indicates the final Examples include 787, P4000, “Product Class”
configuration of the item A350, Engine, System, and the
identified as a product by Navigation system, sensor, “ProductConfigurations”
the provider of that bolt, .
product.
Contract See definition in Table 2. See definition in Table 2. See definition in Table 2.
System Relates to the functional,  P4000,
logical, physical “BreakdownElement”
breakdown of a product.
A system performs a
function within the
functional breakdown of
a product. A system is a
formally tested part of
the product.
Breakdown Indicates a kind of Different views of the P4000, “Breakdown” or
breakdown of the structure are common. “BreakdownVersion”
product structure. Examples include: depending on
functional systems and implementation.
subsystems, kitting, MBOM
structures, etc.
Document See Clause 12  P4000, “Document” or
Documents. “DocumentVersion”
depending on
implementation.
oSIST prEN 9300-210:2024
prEN 9300-210:2024 (E)
Table 7 — Product Design Edges/Connections
Name Description Notes STEP Relationship
Has —  From: System or  P4000, “DocumentAssignment”
Requirement Part
—  To: Document
Associates the system
or part with the set of
requirements it shall
meet.
Has —  From: System or  P4000, “DocumentAssignment”
Compliance Part
Results
—  To: Document
Associates the system
or part with its
com
...