EN 15016-4:2023

SLOVENSKI STANDARD
01-september-2023
Železniške naprave - Tehnična dokumentacija - 4. del: Izmenjava podatkov
Railway applications - Technical documents - Part 4: Data exchange
Technische Zeichnungen - Bahnanwendungen - Teil 4: Datenaustausch
Dessins techniques - Applications ferroviaires - Partie 4 : Echange des données
Ta slovenski standard je istoveten z: EN 15016-4:2023
ICS:
01.110 Tehnična dokumentacija za Technical product
izdelke documentation
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
45.020 Železniška tehnika na Railway engineering in
splošno general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN 15016-4
EUROPEAN STANDARD
NORME EUROPÉENNE
June 2023
EUROPÄISCHE NORM
ICS 01.100.01; 35.240.60; 45.020 Supersedes EN 15016-4:2006
English Version
Railway applications - Technical documents - Part 4: Data
exchange
Applications ferroviaires - Documents techniques - Bahnanwendungen - Technische Dokumente - Teil 4:
Partie 4 : Échange des données Datenaustausch
This European Standard was approved by CEN on 7 May 2023.

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
© 2023 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 15016-4:2023 E
worldwide for CEN national Members.

Contents Page
European foreword . 4
Introduction . 5
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Symbols and abbreviated terms . 7
5 Administration of distributed information . 7
5.1 General . 7
5.2 Parties . 7
5.3 Transfer organization . 8
5.3.1 General . 8
5.3.2 Configuration Management . 9
5.3.3 Rules for Data . 9
5.4 Protocol . 9
5.5 Shipment review . 10
6 Data Model . 10
6.1 General . 10
6.1.1 Structure of Data Model . 10
6.1.2 Units . 13
6.1.3 Dates . 14
6.1.4 Languages . 14
6.1.5 Organization identification . 14
6.2 Data tables . 14
6.2.1 General . 14
6.2.2 Shipment (Data Table A) . 15
6.2.3 Shipment additional data (Data Table A1) . 15
6.2.4 Document structure (Data Table B) . 15
6.2.5 Document structure additional data (Data Table B1) . 16
6.2.6 Item structure (Data Table C) . 16
6.2.7 Item structure additional data (Data Table C1) . 16
6.2.8 Item (Data Table D) . 16
6.2.9 Item additional data (Data Table D1) . 17
6.2.10 Item-Document relation (Data Table E) . 17
6.2.11 Document (Data Table F) . 17
6.2.12 Document additional data (Data Table F1) . 17
6.2.13 File (Data Table F2) . 17
6.3 Additional data fields . 17
6.3.1 General . 17
6.3.2 Application . 18
6.3.3 Identifier for additional data . 18
6.3.4 Additional data fields by agreement . 19
6.4 Modular data exchange . 19
6.5 Transfer structure . 19
6.5.1 General . 19
6.5.2 XML . 19
6.5.3 CSV . 20
6.5.4 Checksum . 21
7 Data quality . 21
7.1 General . 21
7.2 Rules Data Table B/B1 . 21
7.3 Rules Data Table C/C1 . 22
7.4 Rules Data Table D/D1 . 22
7.5 Rules Data Table E . 22
7.6 Rules Data Table F/F1/F2 . 23
Annex A (normative) Data tables and related appendices . 24
A.1 General . 24
A.2 Shipment (Data Table A) . 24
A.3 Shipment additional data (Data Table A1) . 26
A.4 Attributes for the Shipment additional data (Appendix A1) . 27
A.5 Document structure (Data Table B) . 28
A.6 Document structure additional data (Data Table B1) . 29
A.7 Attributes for the Document structure additional data (Appendix B1) . 30
A.8 Item structure (Data Table C) . 30
A.9 Item structure additional data (Data Table C1) . 33
A.10 Attributes for the Item structure additional data (Appendix C1) . 34
A.11 Item (Data Table D) . 35
A.12 Item additional data (Data Table D1). 40
A.13 Attributes for the Item additional data (Appendix D1) . 41
A.14 Item-Document relation (Data Table E) . 45
A.15 Document (Data Table F) . 46
A.16 Document additional data (Data Table F1) . 49
A.17 Attributes for the Document additional data (Appendix F1) . 50
A.18 File (Data Table F2) . 52
Annex B (normative) Data schema XSD . 53
Annex C (informative) Legacy data. 71
C.1 Removed tables . 71
C.2 Item type mapping . 72
C.3 Mapping of EN 15016-4:2006 . 72
Annex D (informative) Use Cases . 85
Bibliography . 87
European foreword
This document (EN 15016-4:2023) has been prepared by Technical Committee CEN/TC 256 “Railway
applications”, the secretariat of which is held by DIN.
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 December 2023, and conflicting national standards shall
be withdrawn at the latest by December 2023.
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.
This document supersedes EN 15016-4:2006.
The main changes compared to the previous edition are listed below:
— The scope has been changed to rolling stock because this is the typical application field.
— The data model has been completely revised to simplify the data exchange by focusing on the
necessary data. Data tables for additional data have been introduced to enable a scalable use of the
data model.
— The purpose of the data model is the structured exchange of item data. The same data model now
also supports the structured exchange of technical document data.
— Rules have been specified to ensure and to check the consistency of the data model.
— A detailed application guide has been incorporated to ensure an easy implementation.
— Because the data exchange is handled by data processing systems an example for layout for a table
of documents and an example for entries in a table of documents is superfluous and has therefore
been deleted.
This document is part of the standard series “Railway applications — Technical documents”, which
consists of the following parts:
— EN 15016-1: General principles;
— EN 15016-2: Parts lists;
— EN 15016-3: Handling of modifications of technical documents;
— EN 15016-4: Data exchange.
This document has been prepared under a Standardization Request given to CEN by the European
Commission and the European Free Trade Association.
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 organisations 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
In railway business, the parties require, as part of a contract, bill of material and technical documents. To
support co-operation and effective data exchange of information between customers, suppliers and
partners, it is necessary to have the data exchange precisely defined.
In European directives, the term “Technical Files” is mainly used to summarize types of documents,
drawings, data, reports, etc.
Three main classes of data can be distinguished:
a) technical data and documents;
b) maintenance data and documents;
c) authorization documents, reports, assessments, and safety data.
This document will support the exchange of bill of material and technical documents between two parties.
The aim of this document is to improve cooperation with respect to time, quality, and costs for the whole
railway sector (e.g. railway users, manufacturers, rail system operators, entities in charge of
maintenance).
This document covers exclusively the specification of the data model of the data exchange process
between two parties. Common project management or contractual arrangements aspects like data
content or the handling of change management are not covered.
This document refers to EN, ISO or IEC standards dealing with data fields. In cases where ISO or IEC
standards are not sufficiently precise, this document gives specific details. These additions to EN, ISO and
IEC standards facilitate the exploitation and the administration of the data exchange.
These requirements have been drawn up in order to accommodate:
— the large variety of users;
— ease of transfer of documents;
— any specific series of documentation related to rolling stock.
1 Scope
This document specifies the data exchange of technical documents such as bill of material, technical
drawings and other related technical documents for rolling stock.
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 17343:2020, Railway applications - General terms and definitions
EN 15016-1:2023 , Railway applications - Technical documents - Part 1: General principles
ISO 639-1, Codes for the representation of names of languages — Part 1: Alpha-2 code
3 Terms and definitions
For the purposes of this document, the terms and definitions given in EN 17343:2020, EN 15016-1:2023
and the following 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
item
subject being considered
Note 1 to entry: The item may be an individual part, component, device, functional unit, equipment, subsystem,
or system.
Note 2 to entry: The item may consist of hardware, software or any combination thereof.
[SOURCE: IEC 60050-192:2015, 192-01-01, modified — Note 3 to Note 5 to entry have been deleted, in
Note 2 the term people has been deleted.]
3.2
bill of materials
BOM
documented formal hierarchical tabulation of the physical assemblies, subassemblies, and components
needed to fabricate a product
Note 1 to entry: The BOM consists of items and therefore may include software.
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.378, modified — Note 1 to entry added]

Under preparation. Stage at the time of publication: prEN 15016-1:2023.
4 Symbols and abbreviated terms
OEM original equipment manufacturer
5 Administration of distributed information
5.1 General
This clause describes the organizational and administrative basics of data exchange according to this
document.
Typically, the source of and target to store the exchanged data are:
— PDM (Product Data Management);
— and PLCS (Product Life Cycle Support).
Methods and tooling for retrieving the exchanged data into the receiver repository (like import tool,
required mappings, etc.) are not described in this document.
5.2 Parties
From the origin of the data (OEM) to the final recipient (final customer) there can be a complex chain of
multiple data shipments, in different levels (tiers) along the value chain. Within this chain there are 4
types of parties (2 dynamic and 2 static):
Static - OEM: The original equipment manufacturer of an item/the legal owner of a
document. Only one OEM is possible per item/document.
If this field is empty, this is automatically the Data Supplier.
Static - Final customer: The final recipient of the item/document (e.g. the operator of the
rolling stock).
It is an optional attribute, that can be added between the submissions
and need to be defined by contract.
The final customer is the same for all items/documents of one
shipment.
Dynamic - Data Supplier: The party that supplies the shipment
Item independent shipment information
Dynamic – Data Recipient: The party that receives the submission
Item independent shipment information
Figure 1 shows examples of data shipments between four parties.
Table 1 shows the allocation of the shipment parties to the party types for the examples in Figure 1.
Party 1 is the OEM.
Party 4 the final customer.
Party 2 receives data from the OEM (shipment 1), adds the final customer information.
Party 3 receives the data from Party 2 (shipment 2).
The final customer receives data from Party 3 (shipment 4) including data from Party 2 and the OEM.
The shipment 3 shows a cyclic data exchange between party 2 and 3 with bidirectional shipments.
Key
S Shipment SP Supplier
P Party RP Recipient
OEM Original Equipment Manufacturer
Figure 1 — Examples of shipments
Table 1 — Examples of data shipments
Shipment 1 Shipment 2 Shipment 3 Shipment 4
OEM Party 1 Party 1 Party 1 Party 1
Static
Final Customer - Party 4 Party 4 Party 4
Supplier Party 1 Party 2 Party 3 Party 3
Dynamic
Recipient Party 2 Party 3 Party 2 Party 4
5.3 Transfer organization
5.3.1 General
This exchange method is a snapshot of the contents of the design. There are no requirements about
history of change management (only the valid version of each piece of information is required).
Before exchanging data, the parties should accept the scope of the exchange on each project:
— Data supplier (Organization ID);
— Data recipient (Organization ID);
— Configuration Data (Applicability);
— Technical Scope (components, sub-system, vehicles, unit, etc.);
— Languages of documents;
— Organization for document repository (Directory, media, authorized formats, etc.);
— Planning of submission;
— Identifier for parts (Numbering schemes and unicity rules);
— Common description for items;
— Data review process;
— Request for Change Management.
5.3.2 Configuration Management
The data exchanged here should be classed in as “Design Data” with the following parameters:
— Contract Identification;
— Class of Rolling Stock;
— Sub Class of Rolling Stock (if applicable);
— Effectivity (if applicable).
5.3.3 Rules for Data
This exchange data model is versatile. Extra fields may be added in the provided data tables (see 6.3).
Written rules should be exchanged between parties:
— to agree on the use of data fields with the “importance” values R (recommended) or I (informative),
see 6.2.1;
— to ensure a consistent model on the non-standard requirements.
5.4 Protocol
To track every shipment, besides the data in the Shipment Data Table (see 6.2.2), a handover protocol
(e.g. in pdf format) may be added to it. The format of the exchange protocol can be company specific and
should contain at least the following information if applicable:
— Org ID data Supplier;
— Org ID data Recipient;
— Title of Submission;
— Top Item/ Document in Data Table B/C/D;
— Contract Reference;
— Vehicle reference;
— Date of Snapshot/ data extraction;
— Languages 1, 2, 3;
— Modules included;
— Number of files in Data Table F.
5.5 Shipment review
When the recipient checks and or imports the exchanged data, errors or quality issues can occur. Then a
request for clarification\error correction can be submitted to the data supplier.
Request for clarification (RfC) should contain:
a) Organization identification of data recipient;
b) Request Identification (Unique Identifier of data recipient);
c) Contract identification;
d) Shipment date;
e) Document identification;
f) Document Version;
g) Document Date;
h) Shipment error class;
i) Request Description.
If the data supplier accepts the RfC, the two fields (Organization Identification and Request identification)
should be noted in the new data (if needed) and delivered in the relevant fields (depending on the class
of notification).
Shipment error class shall contain:
1) Import errors;
2) Documents analysis and review;
3) Documents Breakdown analysis and review;
4) Items Breakdown analysis and review;
5) Missing items;
6) Missing Documents;
7) Shipment Consistency in table.
6 Data Model
6.1 General
6.1.1 Structure of Data Model
Starting point for the exchange model is the principle that the design of the rolling stock is represented
by a structured list of items down to its most basic (i.e. lowest level) items necessary to maintain, repair
or overhaul the rolling stock during its complete lifetime. This structured list of items is called the
(engineering) Bill of Materials (BOM). In this document the materials are referred to as items (to not mix
them up with the term material used to define the substance/raw material an item is made of).
In the data model this BOM is represented by a so-called Parent-Child relation. This means that each
record of the BOM consists of a Child and its Parent. If a Parent has more than one Child, then there are
as many records with that Parent as there are Children of that Parent. A Parent needs to have at least one
Child. Each Child thereafter can be the Parent for a deeper level in the structure, until the lowest level in
the structure is reached. So, the top of the structure is always a Parent and the lowest level is always a
Child. Table 2 shows an example of a table with a Parent-Child relation. Figure 2 shows this relation in a
graphical representation.
Table 2 — Example of Parent – Child relations
Parent Child
Train set Rail vehicle 1
Train set Rail vehicle 2
Rail vehicle 1 Bogie 1
Rail vehicle 1 Bogie 2
Rail vehicle 2 Bogie 1
Rail vehicle 2 Bogie 2
Bogie 1 Axle 1
Key
A Assembly RV Rail vehicle
I Item Bo Bogie
TS Train set Ax Axle
Figure 2 — Examples of Parent – Child relations
Each level in the structure shall be specified. This specification consists of features (meta data) and/or
documents that are linked to the item. Each document shall be linked to the item on the level it describes
e.g. the drawing of the complete assembly of the bogie shall be linked to the item for the complete bogie
and the production drawing for the wheelset axle shall be linked to the item for the bare axle (see
Figure 2).
However sometimes there is a need to also exchange document structures. Therefore, the model also
supports this type of exchange.
Not supported is the exchange of combined structures (items and documents in one single structure)
because documents can be linked to an item rather than adding them as a position in the structure.
However, by exchanging both an item structure and one or more document structure(s) and linking the
Parent documents to items, a relation can be built between the item structure and one or more document
structure(s).
The exchange model is designed in such a way that it can enable the supplier of the data to break down
the configuration out of his own data systems into logical data tables and enable the receiver of the data
to rebuild the configuration in his own data systems, without loss of information.
To minimize the amount of repetitive data, the data are split up in several data tables that are linked
through key-field (see Figure 3 and Figure 4).
Key
B Document Structure F Document Data PA Parent
B1 Document structure additional data F1 Additional Document Data CH Child
F2 Files
Figure 3 — Links for document structure

Key
C Item Structure E Item - Document relation PA Parent
C1 Item structure additional data F Document Data CH Child
D Item Data F1 Additional Document Data
D1 Additional item Data F2 Files
Figure 4 — Links for item structure
Also, extra attributes can be added to the different objects in the different data tables by means of
additional data tables, linked to each main data table (e.g. Table A.2 (Data Table A1) with additional
attributes for Table A.1 (Data Table A)).
In 6.2 all the separate data tables are described in detail.
6.1.2 Units
Basic units and their multiples for unit attributes are listed in Table 3.
If different units are required/used, these needs to be converted into/from the ones in the table in the
import/export interface.
Table 3 — Basic Units and Multiples
Basic unit (short form) Valid Multiples [m – milli; c – centi ; k – kilo]
gram (g) mg; g; kg
meter (m) mm; cm; m; km
litre (l) ml; cl; l
2 2 2 2
square meter (m ) mm ; cm ; m
3 3 3 3
cubic meter (m ) mm ; cm ; m
piece (pcs) pcs
6.1.3 Dates
Descriptions of the different date attributes are listed in Table 4.
Table 4 — Description of date attributes
Date Description
Prepared Date Date of the preparation of the document revision
Checked Date Date of the review of the document revision (if more than one reviewer is
available, the most significant one needs to be chosen)
Approved Date Date of the content approval of the document revision
Revision Date Date from which on the document revision is applicable and the previous
revision becomes invalid. This is the only date that is kept for each party.
6.1.4 Languages
The data model can carry up to 3 languages for metadata defined in Table A.1 (Data Table A). Files and
additional data can be added in languages different from the defined ones. All language codes shall consist
of 2 digits according to ISO 639-1.
6.1.5 Organization identification
Each party, as defined in 5.2, shall be identified by an organization identification (ORID) in the different
data tables. By means of these ORID it is possible to combine the data of several companies within a
consortium without the need to use a new ITEM number from the company that is merging all the data
into one shipment. In the shipment table (Data Table A) only the organization identification of the
responsible data supplier for the data exchange within the consortium is specified (SHORIDSUP).
6.2 Data tables
6.2.1 General
Each data table describes the fields used to define the data of that data table. To describe these fields each
data table has the same structure with several columns (see Table 5).
Table 5 — Structure of data tables
Column Description
Field number Number to identify a data field within a certain data table
Key field Indicator for the fields that are used as key-field to uniquely identify a
record in the data table
Field identifier Coding to uniquely identify a field
Field name Short description of the field in the English language
Data type Coding for the data type of a field:
C = alphanumerical, D = date and/or time, N = decimal, I = integer
Data length Maximum length of the data in number of characters
Value space/pattern Description of the value pattern of the data
Value source Source for the value space/pattern
Language dependent Indicator for language dependency of the data field
Y = Yes, N = No
Importance Indicator for the importance of a data field:
C = compulsory, R = recommended, I = informative
Remark additional information to explain the use of the data field if necessary
All data tables and their details can be found in Annex A.
6.2.2 Shipment (Data Table A)
This data table contains the delivery statistics for each data delivery. Purpose is to enable the receiver to
check the completeness of the data.
For each shipment there is only one record in Table A.1 (Data Table A) with only one data supplier (the
data supplier that is responsible for the shipment, other data suppliers however can be used in the
different data tables, see 6.1.5), one data recipient (party receiving the shipment) and one final customer.
The parties in the data exchange are defined in 5.2. For details, see Table A.1.
6.2.3 Shipment additional data (Data Table A1)
This data table is used to specify additional attributes for the shipment information in Data Table A. Each
record in this data table consists only of one attribute. For each shipment there can be several records in
this data Table (1:n relation with Table A.1 (Data Table A)). The data are linked to Data Table A by the
Shipment Date (SHDAT). For details, see Table A.2.
In the related Appendix A1 (for details, see Table A.3) some possible attributes are described. Besides
these attributes this data table also gives the possibility to add more attributes that are part of the
contract between supplier and customer.
6.2.4 Document structure (Data Table B)
This data table contains the information to build a document structure. It is based on the Parent-Child
structure as explained in 6.1.1. To uniquely identify the Parent and Child in the structure they are
identified by their ORID, ID and Revision. Each record also contains information that is specific to that
position in the structure (Position number and designation code). For details, see Table A.4.
This is in contrast to the information that is specific for the document itself, which can be found in
Table A.14 (Data Table F) and Table A.15 (Data Table F1).
It is possible to exchange separate structures in one shipment in Data Table B. In that case all the top
nodes of the different structures need to be defined in Table A.2 (Data Table A1: Shipment additional
data) by means of the top node attribute in Appendix A1 (for details, see Table A.3).
6.2.5 Document structure additional data (Data Table B1)
This data table is used to specify additional attributes for document structures. It is intended for
attributes that are only valid for certain documents structure records. Each record in this data table
consists only of one attribute. For each document structure record there can be several records in this
data Table (1:n relation with Table A.4 (Data Table B)). The data are linked to Data Table B by the Parent
ORID, ID, the Revision and the Child Position number. For details, see Table A.5.
In the related Appendix B1 some possible attributes are described (for details, see Table A.6). Besides
these attributes this data table also gives the possibility to add more attributes that are part of the
contract between supplier and customer.
6.2.6 Item structure (Data Table C)
This data table contains the information to build the Bill of Materials (BOM, actually: the bill of items
within the terminology of this document). It is also based on the Parent-Child relation. To uniquely
identify the Parent and Child in the structure they are identified by their ORID, ID and Revision. At a
certain level, the list of subordinated children is also often referred to as the parts list for an assembly
(the parent). Each record also contains information that is specific to that position in the structure (e.g.
Position number or designation code). This in contrast to the information that is specific for the part itself,
which can be found in Table A.10 (Data Table D) and Table A.11 (Data Table D1).
Normally within a parts list, the position number is unique. However, in case of an interchangeable part,
these parts can have the same position number within the Parent-Child relation (parts list).
Interchangeable parts are parts that are, for practical purposes, identical. They are made to specifications
that ensure that they are so nearly identical that they will fit into any assembly (Parent) of the same type.
One such part can freely replace another, without any custom fitting (Form Fit Function equally). For
details, see Table A.7.
It is possible to exchange separate structures in one shipment in Table A.7 (Data Table C). In that case, all
the top nodes of the different structures need to be defined in the Table A.2 (Data Table A1) (Shipment
additional data) by means of the top node attribute in Appendix A1. For details, see Table A.3.
6.2.7 Item structure additional data (Data Table C1)
This data table is used to specify additional attributes for item structures. It is intended for attributes that
are only valid for certain item structure records. Each record in this data table consists only of one
attribute. For each item structure record there can be several records in this data Table (1:n relation with
Table A.7 (Data Table C)). The data are linked to Data Table C by the Parent ORID, ID, the Revision and
the Child Position number. For details, see Table A.8.
In the related Appendix C1 (for details, see Table A.9) some possible attributes are described. Besides
these attributes this data table also gives the possibility to add more attributes that are part of the
contract between supplier and customer.
6.2.8 Item (Data Table D)
This data table contains all the relevant metadata for each item that is used in the item structure
(Data Table C). Purpose of the metadata are to uniquely identify and specify an item. Each item revision
can only have one occurrence in the data table. Furthermore, each item revision in this table should have
at least one occurrence in the BOM (Data Table C). For details, see Table A.10.
An important field in this data table is the Item Type (field 18). The value in this field determines for some
attributes in this data table if they are compulsory and also for some additional attributes from
Appendix D1 (for details see Table A.12) if they are compulsory to be filled in in the Data Table D1 (Item
addition data).
6.2.9 Item additional data (Data Table D1)
This data table is used to specify additional attributes for items. It is intended for attributes that are only
valid for certain items. Each record in this data table consists only of one attribute. For each item therefor
there can be several records in this data Table (1:n relation with Table A.10 (Data Table D)). The data are
linked to Data Table D by the ORID, ID and revision of the item. For details, see Table A.11.
Some attributes are mandatory for certain types of items, based on the item type for the item (ITTY in
Data Table D). In the related Appendix D1 (for details see Table A.12) the relation between the item type
and the mandatory attributes can be found.
Besides the attributes of Table A.12 (Appendix D1) this data table also gives the possibility to add more
attributes that are part of the contract between supplier and customer.
6.2.10 Item-Document relation (Data Table E)
This data table links the documents of Table A.14 (Data Table F) to the items of Table A.10 (Data Table D).
The document and the item are identified by their ORID, ID and Revision. For details, see Table A.13.
6.2.11 Document (Data Table F)
This data table contains all the relevant metadata for each document that is used in the document
structure (Data Table B) or the Item-Document relation (Data Table E). This metadata should be
consistent with the information on the physical drawings as specified in EN 15016-1 . Purpose of the
metadata are to uniquely identify and specify the document. Each document shall only have one
occurrence in Table A.14 (Data Table F). Furthermore, each document in this data table should have at
least one occurrence in the document structure (n:1 relation to Table A.4 (Data Table B)) or item-
document relation (n:1 relation to Table A.13 (Data Table E)). For details, see Table A.14.
6.2.12 Document additional data (Data Table F1)
This data table is used to specify additional attributes for documents. It is intended for attributes that are
only valid for certain documents. Each record in this data table consists only of one attribute. For each
item therefor there can be several records in this data Table (1:n relation with Table A.14 (Data Table F)).
The data are linked to Data Table F by the ORID, ID and Revision of the document. For details, see
Table A.15.
In Appendix F1 (for details see Table A.16) some possible attributes are described. Besides these
attributes this data table also gives the possibility to add more attributes that are part of the contract
between supplier and customer.
6.2.13 File (Data Table F2)
This data table contains all the information to specify the physical files for the documents defined in
Table A.14 (Data Table F). The relation to Data Table F is made by the ORID, ID and Revision of the
document. It is a 1:n relation as there can be more files (e.g. several languages or file types) linked to one
document. For
...