ISO 22901-1:2008

Road vehicles — Open diagnostic data exchange (ODX) — Part 1: Data model specification

ISO 22901-1:2008 specifies the concept of using a new industry standard diagnostic format to make diagnostic data stream information available to diagnostic tool application manufacturers, in order to simplify the support of the aftermarket automotive service industry. The Open Diagnostic Data Exchange (ODX) modelled diagnostic data are compatible with the software requirements of the Modular Vehicle Communication Interface (MVCI), as specified in ISO 22900-2 and ISO 22900-3. The ODX modelled diagnostic data will enable an MVCI device to communicate with the vehicle Electronic Control Unit(s) (ECU) and interpret the diagnostic data contained in the messages exchanged between the external test equipment and the ECU(s). For ODX compliant external test equipment, no software programming is necessary to convert diagnostic data into technician readable information to be displayed by the tester. The ODX specification contains the data model to describe all diagnostic data of a vehicle and physical ECU, e.g. diagnostic trouble codes, data parameters, identification data, input/output parameters, ECU configuration (variant coding) data and communication parameters. ODX is described in Unified Modelling Language (UML) diagrams and the data exchange format uses Extensible Mark-up Language (XML). The ODX modelled diagnostic data describe: protocol specification for diagnostic communication of ECUs; communication parameters for different protocols and data link layers and for ECU software; ECU programming data (Flash); related vehicle interface description (connectors and pinout); functional description of diagnostic capabilities of a network of ECUs; ECU configuration data (variant coding). The purpose of ISO 22901-1:2008 is to ensure that diagnostic data from any vehicle manufacturer is independent of the testing hardware and protocol software supplied by any test equipment manufacturer.

Véhicules routiers — Échange de données de diagnostic ouvert (ODX) — Partie 1: Spécification de modèle de données

General Information

• Status: Published
• Publication Date: 05-Nov-2008
• ICS: 43.180 - Diagnostic, maintenance and test equipment
• Technical Committee: ISO/TC 22/SC 31 - Data communication
• Drafting Committee: ISO/TC 22/SC 31/WG 5 - Test equipment/Data eXchange Formats
• Current Stage: 9060 - Close of review
• Start Date: 03-Jun-2028

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 22901-1
First edition
2008-11-15

Road vehicles — Open diagnostic data
exchange (ODX) —
Part 1:
Data model specification
Véhicules routiers — Échange de données de diagnostic ouvert
(ODX) —
Partie 1: Spécification de modèle de données




Reference number
ISO 22901-1:2008(E)
©
ISO 2008

---------------------- Page: 1 ----------------------
ISO 22901-1:2008(E)

PDF disclaimer
PDF files may contain embedded typefaces. In accordance with Adobe's licensing policy, such files may be printed or viewed but shall
not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading a PDF file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create the PDF file(s) constituting this document can be found in the General Info relative to
the file(s); the PDF-creation parameters were optimized for printing. Every care has been taken to ensure that the files are suitable for
use by ISO member bodies. In the unlikely event that a problem relating to them is found, please inform the Central Secretariat at the
address given below.

This CD-ROM contains the publication ISO 22901-1:2008 in portable document format (PDF), which can be
viewed using Adobe® Acrobat® Reader.
Adobe and Acrobat are trademarks of Adobe Systems Incorporated.
COPYRIGHT PROTECTED DOCUMENT


©  ISO 2008
All rights reserved. Unless required for installation or otherwise specified, no part of this CD-ROM may be reproduced, stored in a retrieval
system or transmitted in any form or by any means without prior permission from ISO. Requests for permission to reproduce this product
should be addressed to
ISO copyright office • Case postale 56 • CH-1211 Geneva 20 • Switzerland
Internet c
...

INTERNATIONAL ISO
STANDARD 22901-1
First edition
2008-11-15

Road vehicles — Open diagnostic data
exchange (ODX) —
Part 1:
Data model specification
Véhicules routiers — Échange de données de diagnostic ouvert
(ODX) —
Partie 1: Spécification de modèle de données




Reference number
ISO 22901-1:2008(E)
©
ISO 2008

---------------------- Page: 1 ----------------------
ISO 22901-1:2008(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.


COPYRIGHT PROTECTED DOCUMENT


©  ISO 2008
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland

ii © ISO 2008 – All rights reserved

---------------------- Page: 2 ----------------------
ISO 22901-1:2008(E)
Contents Page
Foreword .v
Introduction.vi
1 Scope.1
2 Normative references.1
3 Abbreviated terms .2
4 ODX use cases.3
4.1 General .3
4.2 Use case 1: ODX process chain.3
4.3 Use case 2: Cross vehicle platform ECU diagnostic development.4
4.4 Use case 3: Franchise and aftermarket service dealership diagnostic tool support.5
4.5 Architecture of a Modular VCI compliant D-server .6
4.6 ODX benefit examples.6
5 Specification release version information.8
5.1 Specification release version location .8
5.2 Specification release version.8
6 Introduction to and use of Unified Modelling Language (UML).8
6.1 General aspects.8
6.2 Class diagrams .8
6.3 Mapping to XML.12
7 ODX data model.14
7.1 General modelling principles .14
7.2 ODX package .26
7.3 ODX data model for diagnostics.29
7.4 Usage scenarios (diagnostic).183
7.5 ODX data model for ECU memory programming.229
7.6 ECU programming usage scenarios (flash).253
7.7 ECU variant coding usage scenarios .265
7.8 ODX data model for ECU configuration .266
7.9 Function dictionary .276
8 Data model implementation in XML.287
8.1 Classifier.287
8.2 Relationships .295
9 Packaged ODX data (PDX).304
9.1 Overview.304
9.2 Structure of PDX package .305
9.3 Usage scenarios .308
Annex A (normative) Enumerations and pre-defined values .315
Annex B (normative) ODX checker rules.326
Annex C (normative) XML schema.345
Annex D (informative) User-defined formats for flashdata.420
Annex E (informative) Coherent examples for diagnostic services .424
Annex F (informative) ECU-MEM example.464
Annex G (informative) Session security example.472
© ISO 2008 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO 22901-1:2008(E)
Bibliography .485

iv © ISO 2008 – All rights reserved

---------------------- Page: 4 ----------------------
ISO 22901-1:2008(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 22901-1 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3,
Electrical and electronic equipment.
ISO 22901 consists of the following parts, under the general title Road vehicles — Open diagnostic data
exchange (ODX):
⎯ Part 1: Data model specification
The following parts are under preparation:
⎯ Part 2: Emissions-related diagnostic data
© ISO 2008 – All rights reserved v

---------------------- Page: 5 ----------------------
ISO 22901-1:2008(E)
Introduction
The purpose of this part of ISO 22901 is to define the data format for transferring Electronic Control Unit
(ECU) diagnostic and programming data between the system supplier, vehicle manufacturer and service
dealerships and diagnostic tools of different vendors.
In today's automotive industry, an informal description is generally used to document the diagnostic data
stream information of vehicle ECUs. Any user wishing to use the ECU diagnostic data stream documentation
to set up development tools or service diagnostic test equipment needs a manual transformation of this
documentation into a format readable by these tools. This effort will no longer be required if the diagnostic
data stream information is provided in Open Diagnostic Data Exchange (ODX) format and if those tools
support the ODX format.
This part of ISO 22901 includes the data model definition of ECU diagnostic and programming data and the
related vehicle interface description in Unified Modelling Language (UML). This part of ISO 22901 also
includes an implementation by Extensible Mark-up Language (XML) schema in Annex C.
vi © ISO 2008 – All rights reserved

---------------------- Page: 6 ----------------------
INTERNATIONAL STANDARD ISO 22901-1:2008(E)

Road vehicles — Open diagnostic data exchange (ODX) —
Part 1:
Data model specification
1 Scope
This part of ISO 22901 specifies the concept of using a new industry standard diagnostic format to make
diagnostic data stream information available to diagnostic tool application manufacturers, in order to simplify
the support of the aftermarket automotive service industry. The Open Diagnostic Data Exchange (ODX)
modelled diagnostic data are compatible with the software requirements of the Modular Vehicle
Communication Interface (MVCI), as specified in ISO 22900-2 and ISO 22900-3. The ODX modelled
diagnostic data will enable an MVCI device to communicate with the vehicle Electronic Control Unit(s) (ECU)
and interpret the diagnostic data contained in the messages exchanged between the external test equipment
and the ECU(s). For ODX compliant external test equipment, no software programming is necessary to
convert diagnostic data into technician readable information to be displayed by the tester.
The ODX specification contains the data model to describe all diagnostic data of a vehicle and physical ECU,
e.g. diagnostic trouble codes, data parameters, identification data, input/output parameters, ECU configuration
(variant coding) data and communication parameters. ODX is described in Unified Modelling Language (UML)
diagrams and the data exchange format uses Extensible Mark-up Language (XML).
The ODX modelled diagnostic data describe:
⎯ protocol specification for diagnostic communication of ECUs;
⎯ communication parameters for different protocols and data link layers and for ECU software;
⎯ ECU programming data (Flash);
⎯ related vehicle interface description (connectors and pinout);
⎯ functional description of diagnostic capabilities of a network of ECUs;
⎯ ECU configuration data (variant coding).
Figure 1 shows the usage of ODX in the ECU life cycle.
The purpose of this part of ISO 22901 is to ensure that diagnostic data from any vehicle manufacturer is
independent of the testing hardware and protocol software supplied by any test equipment manufacturer.
2 Normative references
The following referenced documents are indispensable for the application 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.
© ISO 2008 – All rights reserved 1

---------------------- Page: 7 ----------------------
ISO 22901-1:2008(E)
ISO 8601, Data elements and interchange formats — Information interchange — Representation of dates and
times
ISO/IEC 8859-1, Information technology — 8-bit single-byte coded graphic character sets — Part 1: Latin
alphabet No. 1
ISO/IEC 8859-2, Information technology — 8-bit single-byte coded graphic character sets — Part 2: Latin
alphabet No. 2
ISO/IEC 10646, Information technology — Universal Multiple-Octet Coded Character Set (UCS)
ISO 22900-2, Road vehicles — Modular vehicle communication interface (MVCI) — Part 2: Diagnostic
protocol data unit application programming interface (D-PDU API)
ISO 22900-3, Road vehicles — Modular vehicle communication interface (MVCI) — Part 3: Diagnostic server
application programming interface (D-Server API)
IEEE 754, Binary floating-point arithmetic
XML Schema — 2, XML Schema Part 2: Datatypes, 2nd Edition, W3C Recommendation, 2004-10-28
ASAM MCD 2, Harmonized Data Objects Version 1.0
3 Abbreviated terms
API Application Programming Interface
ASAM Association for Standardisation of Automation and Measuring Systems
ASCII American Standard for Character Information Interchange
DOP Data Object Property
ECU Electronic Control Unit
GMT Greenwich Mean Time
MCD Measurement, Calibration and Diagnosis
ODX Open Diagnostic Data Exchange
OEM Original Equipment Manufacturer
PDU Protocol Data Unit
PDX Packaged ODX
UML Unified Modelling Language
UTC Coordinated Universal Time
VMM Vehicle Message Matrix
W3C World Wide Web Consortium
XML Extensible Mark-up Language
2 © ISO 2008 – All rights reserved

---------------------- Page: 8 ----------------------
ISO 22901-1:2008(E)
4 ODX use cases
4.1 General
Figure 1 — Usage of ODX data in the ECU life cycle shows the usage of ODX in the ECU life cycle.
Engineering, manufacturing, and service specify communication protocol and data to be implemented in the
ECU. This information will be documented in a structured format utilizing the XML standard and by an
appropriate ODX authoring tool. There is potential to generate ECU software from the ODX file. Furthermore,
the same ODX file is used to setup the diagnostic engineering tools to verify proper communication with the
ECU and to perform functional verification and compliance testing. Once all quality goals are met, the ODX file
may be released to a diagnostic database. Diagnostic information is now available to manufacturing, service,
OEM franchised dealers, and aftermarket service outlets via Intranet and Internet.

Figure 1 — Usage of ODX data in the ECU life cycle
4.2 Use case 1: ODX process chain
Figure 2 shows an example of how ODX data is used in a process chain consisting of three phases, as
described below.
a) Phase A of the development process between vehicle manufacturer and system supplier comprises the
exchange of ODX data to support the development of the diagnostic implementation in the ECU and the
development tools.
b) In phase B of the development process at the vehicle manufacturer, the engineering departments release
the ODX data into a diagnostic database. The manufacturing and service departments use the ODX data
as the basis to setup the End-Of-Line test equipment and service application development tools and
generate service documentation.
c) Phase C of the development process supports the service dealership diagnostic and programming tools.
The service department develops service tool application software based on the ODX data model. The
diagnostic and programming software is now available to all service dealerships.
© ISO 2008 – All rights reserved 3

---------------------- Page: 9 ----------------------
ISO 22901-1:2008(E)
The ODX data is the base for all exchange of diagnostic and programming data.

Figure 2 — Example of ODX process chain
4.3 Use case 2: Cross vehicle platform ECU diagnostic development
A vehicle manufacturer implements electronic systems into multiple new vehicle platforms. There is little
variation in the electronic system across the different vehicle platforms. Utilizing the same ECU in many
different vehicle platforms reduces redundant development effort. The majority of design, normal operation,
and diagnostic data of an electronic system can be reused in various vehicles.
Large automotive manufacturer tend to have multiple engineering development centres. Diagnostic data
exchange can be based on the ODX data format to reduce the amount of proofreading of diagnostic data at
different development sites. Establishing an ODX compliant tool chain will avoid re-authoring diagnostic data
into various specific formats at different engineering sites.
4 © ISO 2008 – All rights reserved

---------------------- Page: 10 ----------------------
ISO 22901-1:2008(E)
Figure 3 shows an example of cross vehicle platform ECU diagnostic development between two engineering
sites.

Figure 3 — Example of cross vehicle platform ECU diagnostic development
4.4 Use case 3: Franchise and aftermarket service dealership diagnostic tool support
Figure 4 shows one of many scenarios a vehicle manufacturer may implement to support the service
dealership, franchise and aftermarket. ODX files may be converted into an ODX runtime format for download
to the dealership diagnostic system.
IMPORTANT — The ODX runtime data format may be different between many diagnostic and
programming applications and tools. In such cases, an ODX runtime converter may be used to
support the data conversion to dealership specific test equipment.

Figure 4 — Example of automotive dealership diagnostic tool support
© ISO 2008 – All rights reserved 5

---------------------- Page: 11 ----------------------
ISO 22901-1:2008(E)
4.5 Architecture of a Modular VCI compliant D-server
Figure 5 shows the interfaces of a D-server and the position of ODX in a diagnostic system. The D-server may
use its own internal specific runtime data format. This data can be imported from the ODX using a specific
format converter.

Figure 5 — Architecture of a Modular VCI compliant D-server
4.6 ODX benefit examples
4.6.1 ECU system supplier
The following benefits are applicable to the ECU system supplier:
⎯ automatic configuration of ECU diagnostic data stream & protocol;
⎯ documentation is generated from XML data format (ECU diagnostic content = documentation);
⎯ automatic configuration of development tester to verify ECU diagnostic behaviour;
⎯ XML data format provides machine readable information to import into supplier diagnostic data base;
⎯ generation of source code to configure diagnostic kernel software components.
4.6.2 Vehicle manufacturer engineering
The following benefits are applicable to the vehicle manufacturer engineering:
⎯ reduction of diagnostic data stream authoring effort;
⎯ various development testers can be supported with “single source” data;
⎯ one single file format for import and export into/from diagnostic database.
6 © ISO 2008 – All rights reserved

---------------------- Page: 12 ----------------------
ISO 22901-1:2008(E)
4.6.3 Vehicle manufacturer production
The following benefits are applicable to the vehicle manufacturer production:
⎯ reduced effort for diagnostic data verification, because verification needs to be performed only once;
⎯ reuse of verified diagnostic data;
⎯ fewer errors because of fewer manual process steps;
⎯ end-of-line tester uses the same diagnostic data as engineering diagnostic tester.
4.6.4 Vehicle manufacturer service department and dealerships
The following benefits are applicable to the vehicle manufacturer service department and dealerships:
⎯ more convenient reuse of verified diagnostic data;
⎯ less cost to distribute diagnostic data;
⎯ “pull” (via Intranet/Internet) diagnostic data (e.g. from a portal into a D-server) versus “push” (e.g. send
CD ROMs);
⎯ one single file format for various diagnostic service systems.
4.6.5 Test equipment manufacturer
The following benefits are applicable to the test equipment manufacturer:
⎯ less effort needed to implement high quality scan tool software by using a generic data driven approach;
⎯ focus on “rich diagnostic application(s)” versus bits & bytes;
⎯ more convenient reuse of vehicle manufacturer verified diagnostic data.
4.6.6 Franchise and aftermarket dealerships
The following benefits are applicable to the franchise and aftermarket dealerships:
⎯ more convenient reuse of vehicle manufacturer verified diagnostic data;
⎯ tester configuration by data download instead of by software modification;
⎯ download on demand versus buying tester software update upfront.
4.6.7 Legal authorities
The following benefits are applicable to the legal authorities:
⎯ standardized description format for enhanced diagnostic data documentation (e.g. DTCs, PIDs);
⎯ enables road-side scan tools and I&M (inspection and maintenance) tools to be vehicle manufacturer
independent;
⎯ fulfils requirement of making enhanced diagnostic data available to independent aftermarket.
© ISO 2008 – All rights reserved 7

---------------------- Page: 13 ----------------------
ISO 22901-1:2008(E)
5 Specification release version information
5.1 Specification release version location
The release version of the ODX standard can be obtained from every ODX file instance. It is contained in the
MODEL-VERSION element.
VERSION="2.2.0">

5.2 Specification release version
The specification release version of this part of ISO 22901 is: 2.2.0.
6 Introduction to and use of Unified Modelling Language (UML)
6.1 General aspects
Unified Modelling Language (UML) is used to define the ODX data model formally and unambiguously. It
enhances readability by graphical data model diagrams.
A short introduction to UML is given in this clause. Only those aspects of UML are described that are used in
the ODX data model. Specifically, from the large set of available UML diagrams, class diagrams are only
applied for data modelling.
6.2 Class diagrams
6.2.1 Class
The central modelling element in UML is a class. A class represents a set of similar objects. Generally
speaking, a class can be instantiated many times. Every instance of a class is called an object. A class has
attributes (defining the properties of these objects) and methods (defining the actions an object can perform).
For ODX, methods are irrelevant and are not used.

Figure 6 — UML representation of class
Figure 6 shows the representation of a class and its attributes in UML notation. A class is symbolized by a
rectangle having up to three fields. The top field contains the name of the class, e.g. PERSON. The second
field contains the attributes of the class, e.g. NAME, AGE, PROFESSION, and ID. Methods are defined in an
optional third field. The attribute field is not always displayed in the ODX data model diagrams. Since the
method-field is unused in the ODX data model, it is never displayed.
Attributes consist of the attribute name, e.g. NAME, followed by the attribute’s cardinality, e.g. [1] or [0.1] and
the attribute type, e.g. String. Furthermore, a default value for the attribute may be specified. Such a default
value follows the type descriptor of the attribute and is separated from it by the symbol “=”.
8 © ISO 2008 – All rights reserved

---------------------- Page: 14 ----------------------
ISO 22901-1:2008(E)
UML attributes specified with the <> stereotype in front of their name are implemented as XML attributes
of XML elements. UML attributes without this stereotype are implement as XML sub-elements of XML
elements.
Throughout the ODX data model, class names and attribute names are written in capital letters.
6.2.2 Inheritance relationships
Classes can inherit attributes from other classes. In Figure 7, a new class SCHOOLKID is derived from the
class PERSON. This means that implicitly the class SCHOOLKID has all the same attributes as PERSON
plus those that are defined specifically for the new class SCHOOLKID, e.g. GRADE. PERSON is called the
parent or super class; SCHOOLKID is called the child or subclass of the inheritance relationship. Because the
subclass adds more detail to the super class and is thus more specific, inheritance relationships are often
called “specializations”.
Inheritance relationships can be used to build inheritance trees of arbitrary depth. A class in such a tree
inherits all attributes from those classes in the transitive closure of all ancestors (parents, grandparents, etc.)
in the inheritance tree.

Figure 7 — UML representation of inheritance relationship
6.2.3 Aggregation and composition relationships
Besides the inheritance relationship, a pair of classes may also have an aggregation or a composition
relationship. Aggregation or composition relationships are used if an object of one class is contained in an
object of another class. They are drawn as a line with a diamond at the end of the containing class. A
composition relationship’s diamond is filled; an aggregation’s diamond is not.
The difference between these two kinds of relationships is as follows:
a) the contained element in a composition relationship is a part of the containing element;
b) if the containing element is deleted, the contained element no longer exists.
Therefore, composition means an object may only be contained in one other object. An aggregation
relationship is one of shared objects. This means that multiple objects may aggregate the same object.
1)
Consequently, an aggregated object still exists, even if the aggregating object is deleted .

1) In the special case where the data model is implemented in XML (see below), aggregation and composition
relationships are both mapped onto a sub element relationship between the two model elements. However, the UML
semantics guide prohibits multiple classes from having a composition relationship to the same class. Therefore,
aggregation relationships are used instead, even though the implementation in XML does not differ.
© ISO 2008 – All rights reserved 9

---------------------- Page: 15 ----------------------
ISO 22901-1:2008(E)
Figure 8 gives an example of three classes with composition and aggregation relationships defined. A
PERSON may have two feet (two objects of type FOOT). A foot is generally an integral part of its owner.
Therefore, a composition relationship is used. If the PERSON no longer exists, nor do the feet. By contrast, a
PERSON may also have a lot of COATs. However, a COAT may generally be used by multiple PERSONs
and its life-cycle is generally independent of the life-cycle of its wearers. Consequently, the relationship
between a PERSON and a COAT is modelled as an aggregation relationship.
Composition relationships may carry cardinalities, as shown in Figure 8. The following cardinalities are
common in UML:
⎯ 1 exactly one (mandatory);
⎯ 0.1 zero or one (optional);
⎯ 1.* one or more;
⎯ 0.* or * zero or more.
More specific cardinalities may be specified, e.g. 5 or 2.8.
Cardinalities are read as follows: To specify how many objects of class PERSON are related to one object of
class FOOT, the cardinality at the PERSON end of the relationship is use. Vice versa the cardinality at the
FOOT end of the relationship is used. This yields the following result: one object of class FOOT may be
related to exactly one object of class PERSON (a foot always belongs to one and only one person) and one
object of class PERSON shall be related to exactly two objects of class FOOT (a person usually has two feet).

Figure 8 — UML representation of composition and aggregation relationships
6.2.4 Associa
...