prEN 9300-205

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 - 205. del: Validacija
strukture izdelka
Aerospace series - LOTAR - LOng Term Archiving and Retrieval of digital technical
product documentation such as 3D, CAD and PDM data - Part 205: Product structure
validation
Luft- und Raumfahrt - LOTAR - Langzeit-Archivierung und -Bereitstellung digitaler
technischer Produktdokumentationen, wie zum Beispiel von 3D-, CAD- und PDM-Daten -
Teil 205: Validierung der Produktstruktur
Ta slovenski standard je istoveten z: prEN 9300-205
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 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 205: Product structure
validation
Luft- und Raumfahrt - LOTAR - Langzeit-Archivierung
und -Bereitstellung digitaler technischer
Produktdokumentationen, wie zum Beispiel von 3D-,
CAD- und PDM-Daten - Teil 205: Validierung der
Produktstruktur
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-205:2025 E
worldwide for CEN national Members.

Contents Page
European foreword . 4
Introduction . 5
1 Scope . 6
1.1 In scope . 6
1.2 Out of scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Node Unique Definition . 7
4.1 General. 7
4.2 Detail Node . 7
4.3 Assembly Node . 7
5 Attribute Validation Properties . 8
5.1 General. 8
5.2 AHashAttributes . 8
5.3 AHash . 8
5.4 BHash and CHash . 9
6 Data Definition . 9
6.1 General. 9
6.2 Text . 9
6.2.1 General. 9
6.2.2 End-Of-Line (CR-LF, LF-CR, LF) . 10
6.3 Integer . 10
6.4 Double . 10
6.4.1 General. 10
6.5 Date and Time Representations . 11
6.5.1 General. 11
6.5.2 Date . 11
6.5.3 Time (UTC) . 11
6.5.4 Date Time (UTC) . 12
6.6 Boolean . 12
7 Hash Identification . 12
7.1 General. 12
7.2 Hash Algorithm . 12
7.2.1 General. 12
7.2.2 SHA-1 . 12
7.3 Hash Specification . 12
8 Example Product Structure with XML . 12
8.1 General. 12
8.2 Detail Node Examples . 14
8.2.1 General. 14
8.2.2 Company Detail . 14
8.2.3 Industry Standard Detail . 16
8.3 Assembly Examples . 17
8.3.1 General . 17
8.3.2 Assembly Examples with a Single Child . 17
8.3.3 Assembly Example with Multiple Children . 20
8.3.4 Assembly Example with Child Positions. 21
8.3.5 MultiValuated Attribute Examples . 24
Annex A (informative) Metadata for Archive Packages . 27
Annex B (informative) Example: SHA-1 specification . 28
Bibliography . 29

European foreword
This document (prEN 9300-205: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.
Introduction
This document is intended to clearly describe the recommendations of the LOTAR PLM Team as it
pertains to product structure validation. The document includes the outcomes of the research contracted
by the LOTAR PLM team. As an example of implementation this document is referenced by the
recommended practices developed by the MBx Implementor Forum (PDM-IF) “Recommended Practices
for STEP AP242 Domain Model XML Product & Assembly Structure”.
The LOTAR team is an international working group jointly hosted by ASD-Stan and the ProSTEP iVIP
Association in Europe, and PDES Inc, and AIA in the US. Its aim is to develop a standard de-signed to
provide the capability to store digital product information in a standard neutral form that can be read
and reused throughout its lifecycle, independent of changes in the IT application environment originally
used to create it. The multi-part standard EN/NAS 9300 covers both the information content and the
processes required to ingest, store, administer, manage and access the information.
The scope of this technical report refers to LOTAR Part 2xx.
It is recognized in LOTAR PLM that configured Product Structures are the key to successful archive and
retrieval of PDM data. These product structures shall be maintained precisely and a proof that this has
been accomplished is required. Product structures can only be reused if the exact product structure
content is known to represent the required structure.
The attribute “validation property” is used to make sure that the part attributes loaded into the second
PDM (or archive) are the same as the ones extracted from the original PDM (or archive). This validation
property is also used to validate that the node represents a re-usable structure. Often nodes will have
similar names in the archive (Part Number), but are archived for different purposes (ex: Reference
Structure which includes configuration, Manufacturing, Conformity, Design and Construction, Usage,
etc.). Typically, a structure stored for the function of Reference Data are very different from the one stored
for Design and Construction. Each node may also contain different attributes as well depending on
function.
This document defines a method to validate a product structure using hashes of attributes and
hierarchical relationships. The examples in this document are all XML. The algorithm described in this
document will work in any format but the attribute representations will need to be adjusted accordingly.
1 Scope
1.1 In scope
This document defines a Recommended Practice for Product Structure validation. The objective is to
validate the product structure of data ingested, extracted or re-used by the archive.
This document defines a method to uniquely identify each node in the product structure and to uniquely
define the structure of each assembly node.
1.2 Out of scope
This document will not provide validation properties for documents; CAD or other.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purpose of this document, the following terms and definitions 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/
3.1
detail node
any part defined in the product structure that has no children specified
3.2
assembly node
any part defined in the product structure that has children (detail or assembly node) specified
3.3
hash value
hexadecimal string created by a standard cryptographic algorithm
Note 1 to entry: The SHA-1 algorithm is what is referenced in this document. Other Industry Standard hash
mechanisms may be used in place of SHA-1.
Note 2 to entry: This hash provides a unique signature that is altered if any of the referenced data differs.
Uniqueness is the goal of this hash signature, not encryption.
3.4
AHash attributes
list of attributes whose values are concatenated and passed into the hash algorithm to generate a hash
value
3.5
CPAH
string which results from running the hash algorithm against the concatenated values of the AHash
attributes
3.6
AHash value
hash value that will be stored in the XML for each part to validate the package on extract
Note 1 to entry: The AHash value of a Detail node is equivalent to the CPAH. The AHash value of an Assembly is
calculated from the CPAH of the Assembly and the unique identifiers and quantities of its children as explained in
5.2.
4 Node Unique Definition
4.1 General
Structures are made up of two types of Nodes: Detail and Assembly.

Figure 1 — Sample product structure
4.2 Detail Node
A Detail Node is defined as any node in the structure that does not have any children in the structure.
Detail Nodes may contain a different set of attributes depending on the type or classification of Detail
part. For instance, details whose type design data are owned by the Company will likely contain many
more significant attributes than Details that represent Industry Standard parts.
Inseparable assemblies and purchased assemblies with no defined product structure would also be
considered detail nodes since the PDM system would not break them down any further.
Detail Nodes can reference files, CAD or otherwise. This reference is not included in this validation
property.
Examples in Figure 1: [2,3] and all [3,x].
4.3 Assembly Node
An Assembly Node is defined as a node that is dependent on other nodes (children).
An Assembly node may have attributes of its own.
Assembly Nodes can reference files, CAD or otherwise. This reference is not included in this validation
property. The referenced files have an independent hash as defined in 5.3.
Examples in Figure 1: [1,1], [2,1], [2,2].
5 Attribute Validation Properties
5.1 General
A list of attributes used to generate the unique attribute hash shall be defined. Typically this includes all
critical attributes for the function that the data are being archived.
The included attributes are concatenated in a specific order as defined by the AHashAttributes element
and then converted to a hash signature using an industry standard algorithm. The algorithm used should
be specified in the metadata section describing the Archive Package (header) see Annex A.
It is recommended that the validation property be stored outside the data package for use when
determining re-use of data in the archive or PDM.

Figure 2 — Example part validation XML-format
5.2 AHashAttributes
AHashAttributes is a list of the attributes that have their values included in the AHash calculation.
This is a subset of the attributes in the part XML files.
The AHash attribute list is defined within the validation section as shown in Figure 2. This element
defines the list of items to be concatenated and the order of the concatenation. It is not the formula,
meaning that the field separator is not included in the actual concatenation and neither is the format.
Each attribute is assumed to be a string (Text) by default. Deviation from that default can be defined by
leveraging the “format” specification with each attribute as shown in Clause 8.
5.3 AHash
AHash is the hash value of the node based on the attributes defined by the AHashAttributes value and the
unique identifier for and quantity of its direct children.
The AHash value is calculated using a two-step process.
Step 1: Current Part Attribute Hash (CPAH)
The value is calculated by concatenating all the attribute values listed in the AHashAttributes values and
then applying the specified hash algorithm to that resultant string. The values shall be in the order of
concatenation as specified by the AHashAttributes element.
The AHash of a detail node is equal to the CPAH of the object.
Step 2: Assembly AHash
The AHash of an assembly is the CPAH of the assembly concatenated with a unique key for each distinct
direct child part and its quantity and then processed through the specified hash algorithm. Each value is
separated by a colon. The unique key for the part can be any combination of recognizable attributes which
provide enough information to uniquely identify that part, such as Part Number and Part Revision or Part
ID and Part Revision. The child information in the concatenated string should be in alphanumeric order
based on the unique key of each child.
The child AHash values are concatenated in alphanumeric order.
CPAH:Child1_ID:Child1_Rev:Child1_Qty:Child2_ID:Child2_Rev:Child2_Qty
qty# is a number.
Figure 3 — Assembly hash formula
5.4 BHash and CHash
The validation section also contains hash signatures of any files that need to be intrinsically tied to the
object. In the example in Figure 2, BHash is used to provide a SHA512 signature of a PDF file of the BOM
associated to the part and CHash is used to provide a SHA512 signature of the CAD file associated to the
part. The files to validate will be site specific. Their names may be referenced in the attribute section in
the XML or called out explicitly in the validation section.
The SHA512 algorithm is used for files rather than SHA1 due to its greater length but any industry
standard algorithm that ensures file uniqueness may be used and should be specified in the appropriate
section of the validation properties as shown in Figure 2.
6 Data Definition
6.1 General
The following data types are used to extend the AHashAttributes beyond the text format.
Data that has a semantic meaning other than simple text can be stored in multiple formats for differing
reasons. To clarify the calculation all semantic data formats will be converted to simple text formats based
on the following rules. The data does not need to be stored in this format; this is only required for
calculation of the validation property.
All data should be encoded as UTF-8.
Time and DateTime values should be represented in UTC for purposes of elements that are included in
the AHash attributes. Local time may be used in the XML for elements that are not included in the AHash
calculation. Using local time in the AHash calculation would be very difficult to support validation across
multiple sites.
6.2 Text
6.2.1 General
Encode as stored. This would include all string and integer elements.
6.2.2 End-Of-Line (CR-LF, LF-CR, LF)
There is a wide variety of methodologies in applications for defining the end of line. A consistent format
should be used to represent the end of line character(s) for purposes of calculating the hash used for
validation.
ISO specifies in ASCII that you can use either CR-LF or just LF. The W3C organization specifies in End-Of-
Line Handling (https://www.w3.org/TR/xml/#sec-line-ends) of Extensible Markup Language (XML) 1.0
(Fifth Edition), section 2.11:
To simplify the tasks of applications, the XML processor shall behave as if it normalized all line breaks in
external parsed entities (including the document entity) on input, before parsing, by translating both the
two-character sequence #xD #xA and any #xD that is not followed by #xA to a single #xA character.
Both #xA and 0x0A are representations of LF. As indicated above any use of the following encodings in
data should be converted to LF for purposes of calculating the validation property. Each implementation
of this specification will need to adjust the End of Line representation in the XML into the application
specific requirements upon loading.
Table 1 — End of line characters
Type Description ASCII HEX ISO 10646-1 [Unicode]
LF Line Feed 0x0A U+000A
VT Vertical Tab 0x0B U+000B
FF Form Feed 0x0C U+000C
CR Carriage Return 0x0D U+000D
CR-LF  0x0D then 0x0A U+000D then U+000A
LF-CR  0x0A then 0x0D U+000A then U+000D
NEL New Line  U+0085
LS Line Separator  U+2028
PS Paragraph Separator  U+2029
Values other than LF are converted for calculation of the validation property and should be evaluated for
interpretation by the end point systems. The validation property is not intended to resolve the meaning
of the data, only the consistency.
6.3 Integer
This value is calculated identical to text, and therefore should not be included in the attribute definition.
6.4 Double
6.4.1 General
For purposes of the validation property use the following format:
[-]x.xxxxxxe[-]xxx
Zero should simply be represented as 0.
The first non zero digit should be to the left of the decimal.
Remove trailing zeros.
Remove a trailing decimal.
Remove leading zeros from the exponent.
When the exponent is zero remove the exponent portion altogether.
The negative symbol is only included when required, positive signs are always suppressed.
Validation Representation Examples: −1e4, 1.43233e12, 1.278e-3, 1.2e1, 0, 3.4e1, 1.75.
NOTE When the precision required is beyond the normal default precision of the programming language used
to convert double values to strings such as CAD part position matrices, the validation process might need to be
defined separately and not included in the AHASH calculation. See ISO 10303 for CAD validation properties.
For representation in the XML follow the Double definition in of XML Schema Part 2, section 3.2.5:
Datatypes Second Edition (https://www.w3.org/TR/xmlschema-2/).
XML Representation Examples: −1e4, −1000, 123.56, −11.2786 1.2, 0, 0.0.
Format Name: Double.
6.5 Date and Time Representations
6.5.1 General
Dates and times should be converted to ISO 8601 format for storage in the XML. Further, the Time and
Date Time formats should be converted to UTC prior to calculation of the validation property.
The formats listed below use the following definitions:
YYYY = four-digit year
MM = two-digit month (eg 03 = March)
DD = two-digit day of the month (01 through 31)
T = a set character indicating the start of the time element
hh = two digits of an hour (00 through 23, AM/PM not included)
mm = two digits of a minute (00 through 59)
ss = two digits of a second (00 through 59)
mmm = three digits of a millisecond (000 through 999)
TZD = time zone designator (Z or +hh:mm or -hh:mm), the + or - values indicate how far ahead
or behind a time zone is from the UTC (Coordinated Universal Time) zone.
Z is the Time Zone Designation for UTC (Zulu).
6.5.2 Date
YYYY-MM-DD
Example: 2013-02-05 corresponds to February 5th, 2013
Format Name: UTCDate
6.5.3 Time (UTC)
hh:mm:ss.[mmm]TZD
Milliseconds may be dropped if not required in definition.
Example: 13:15:30Z corresponds to 1:15:30 pm UTC (Zulu).
Format Name: UTCTime
6.5.4 Date Time (UTC)
YYYY-MM-DDThh:mm:ss[.mmm]TZD
Milliseconds may be dropped if not required in definition.
2013-02-05T13:15:30Z corresponds to Feburary 5th, 2013 at 1:15:30pm UTC (Zulu)
Format Name: UTCDateTime
6.6 Boolean
Boolean values may be stored in the XML as True/False but should be converted to simple text when
concatenated as part of the CPAH/AHASH strings for purposes of generating the HASH values in a manner
consistent with the handling of integers in 6.2.
7 Hash Identification
7.1 General
In order to calculate and validate the hash values consistently certain information shall be provided along
with the hash signature.
7.2 Hash Algorithm
7.2.1 General
A hash value shall be calculated using a standard cryptographic algorithm to generate a unique signature
(or finger print) for a node. The hash value is not intended to encrypt the data, so the fact that the value
is predictable is not relevant.
7.2.2 SHA-1
SHA-1 is used in calculations of the validation property examples in this document, although any industry
standard algorithm that can generate a key to satisfy the requirements for uniqueness may be used. The
standard shall be clearly identified in the validation section such that the consumers of the data can
regenerate the hash after loading to validate that the data are consistent with the intent of the archive
(e.g. SHA1).
All characters in the calculated hash value shall be uppercase.
7.3 Hash Specification
The specification used to dictate the calculation of the hash value shall also be included. This may be a
reference to a particular revision of this document, or it may be a company specific document which
provides the recipe for calculation. The company specification may simply reference this LOTAR
specification with an
...