ISO 13209-2:2022

INTERNATIONAL ISO
STANDARD 13209-2
Second edition
2022-07
Road vehicles — Open Test sequence
eXchange format (OTX) —
Part 2:
Core data model specification and
requirements
Véhicules routiers — Format public d'échange de séquence-tests
(OTX) —
Partie 2: Exigences et spécifications du modèle de données central
Reference number
© ISO 2022
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword . vi
Introduction .vii
1 S c op e . 1
2 Nor m at i ve r ef er enc e s . 1
3 T erms, definitions and abbreviated terms . 2
3.1 T erms and definitions . 2
3 . 2 A bbr e v i at e d t er m s . 3
4 Requirements and recommendations . 4
4.1 General . 4
4.2 B asic principles for requirements and recommendations definition . 4
4.3 C lustering of requirements and recommendations . 4
4 .4 E nt r ie s pr ior it ie s . 4
4.5 G eneral format and language aspects . 5
4.6 T est sequence development process support . 6
4.7 L anguage feature details . 7
4 .7.1 D e c l a r at ion s . . 7
4.7.2 D ata types . 8
4.7.3 E xpressions . 9
4 . 8 B ou nd a r ie s . 12
5 I ntroduction to modelling in UML and XSD .14
5.1 G eneral aspects . 14
5 . 2 C la ss d i a g r a m s . 14
5.2.1 G eneral . 14
5 . 2 . 2 C la ss . 14
5 . 2 . 3 I n her it a nc e r el at ion sh ip s . 15
5 . 2 .4 A g g r e g at ion r el at ion sh ip s . 16
5.3 M apping to the XML Schema Definition language (XSD) . 16
5.3.1 General . 16
5 . 3 . 2 M appi n g r u le s. 17
5.3.3 Full mapping example . . 17
6 O T X pr i nc iple s .20
6.1 General . 20
6 . 2 X M L f or m at . 20
6.3 I mperative and structured programming paradigm . 21
6.4 G raphical authoring of OTX sequences . 21
6.5 Specification/realisation concept . 21
6.6 M odular OTX extension concept and OTX-based runtime architecture . 21
6.7 C ontext concept .23
6 . 8 Va l id it ie s c onc ep t . 24
6 .9 Si g n at u r e c onc ep t . 27
7 O TX core data model specification .28
7.1 G eneral .28
7.2 H igh-level overview of the OTX core data model .29
7. 3 D o c u ment r o ot . 30
7. 3 .1 D e s c r ip t ion . 30
7.3.2 S yntax . . 31
7. 3 . 3 Sema nt ic s . 31
7.3.4 Example .34
7.4 I mp or t s . 35
7.4 .1 D e s c r ip t ion . 35
7.4.2 Syntax . . 35
7.4 . 3 Sema nt ic s . 35
iii
7.4.4 Example .36
7.5 Global declarations . 36
7. 5 .1 D e s c r ip t ion . 36
7.5.2 S yntax . .36
7. 5 . 3 Sema nt ic s . 37
7.5.4 Example .40
7.6 V alidity terms . 41
7. 6 .1 D e s c r ip t ion . 41
7.6.2 Syntax . . 41
7. 6 . 3 Sema nt ic s . 42
7.6.4 Example . 43
7.7 Si g n at u r e s . 43
7.7.1 D e s c r ip t ion . 43
7.7.2 S yntax . . 43
7.7. 3 S em a nt ic s .44
7. 8 P r o c e du r e s i g n at u r e s . 45
7. 8 .1 D e s c r ip t ion . 45
7.8.2 S yntax . . 45
7. 8 . 3 Sema nt ic s . 45
7.8.4 Example . 45
7.9 P r o c e du r e s . 47
7.9.1 D e s c r ip t ion . 47
7.9.2 Syntax . . 47
7.9. 3 Sema nt ic s . 47
7.9.4 Example .50
7.10 F lo at i n g c om ment s .50
7.10 .1 D e s c r ip t ion . 50
7.10.2 Syntax . .50
7.10 . 3 Sema nt ic s . 51
7.10.4 Example . 51
7.11 P a r a me t er de c l a r at ion s . 52
7.11.1 D e s c r ip t ion . 52
7.11.2 S yntax . . 52
7.11. 3 Sema nt ic s . 53
7.11.4 Example .54
7.12 L o c a l de c l a r at ion s.54
7.12 .1 D e s c r ip t ion .54
7.12.2 S yntax . .54
7.12 . 3 S em a nt ic s . 55
7.12.4 Example . 55
7.13 No de s .56
7.13 .1 O ver v iew .56
7.13 . 2 No de . 57
7.13 . 3 Ac t ion no de.58
7.13 .4 C omp ou nd no de s . 62
7.13 . 5 E nd no de s .84
7.14 Ac t ion s . 91
7.14 .1 O ver v iew . 91
7.14.2 Syntax . 91
7.14.3 General considerations . 92
7.14 .4 A s s i g n ment . 92
7.14 . 5 P r o c e du r eC a l l . 92
7.14.6 ByteFieldModifiers .98
7.14.7 ListModifiers . 101
7.14.8 MapModifiers .104
7.15 Ter m s.106
7.15 .1 O ver v iew .106
7.15 . 2 L it er a l t er m s .107
iv
7.15 . 3 D er ef er enc i n g t er m s .112
7.15 .4 C r e at ion t er m s . 114
7.15 . 5 C onver s ion t er m s . 117
7.15.6 Integer conversion terms .121
7.15 .7 L og ic op er at ion s .124
7.15 . 8 R el at ion a l op er at ion s .126
7.15 .9 M at hem at ic a l op er at ion s .129
7.15.10 ByteField operations .133
7.15 .11 L i s t-r el at e d t er m s .136
7.15 .12 M ap -r el at e d t er m s .137
7.15.13 Exception-related terms .139
7.15.14 V alidity concept related terms .140
7.16 U niversal types . 141
7.16 .1 O ver v iew . 141
7.16 . 2 P ac k a g eNa me . 141
7.16.3 OtxName and OtxLink . 142
7.16.4 NamedAndSpecified . 143
7.16 . 5 Me t a Dat a . 145
7.16 . 6 Va r i able ac c e s s . 147
7.16 .7 D e c l a r at ion s . .149
7.16.8 Visibility .162
7.16 .9 F low . 162
Annex A (normative) OTX data types . 165
Annex B (normative) Scope and memory allocation .170
Annex C (normative) Comprehensive checker rule listing . 172
Annex D (normative) Extension mechanism . 185
Annex E (normative) Schema annotations .188
Annex F (informative) OTX home and URI recommendation . 190
Bibliography .191
v
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.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
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. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/
iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 31,
Data communication.
This second edition cancels and replaces the first edition (ISO 13209-2:2012), which has been
technically revised.
The main changes are as follows:
— introduction of new extension interfaces, e.g. for procedure realisations, compound nodes, and
NamedAndSpecified;
— made ForEachLoop more convenient;
— new terms added (e.g. RoundToNearest);
— introduction of MutexLock;
— added new checker rules;
— deprecated TerminateLanes node.
A list of all parts in the ISO 13209 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
vi
Introduction
Diagnostic test sequences are utilized whenever automotive components or functions with diagnostic
abilities are being diagnosed, tested, reprogrammed or initialized by off-board test equipment. Test
sequences define the succession of interactions between the user (i.e. workshop or assembly line staff),
the diagnostic application (the test equipment) and the vehicle communication interface as well as
any calculations and decisions that have to be carried out. Test sequences provide a means to define
interactive, guided diagnostics or similar test logic.
Today, the automotive industry mainly relies on paper documentation and/or proprietary authoring
environmments to document and to implement such test sequences for a specific test application.
An author who is setting up engineering, assembly line or service diagnostic test applications needs
to implement the required test sequences manually, supported by non-uniform test sequence
documentation, most likely using different authoring applications and formats for each specific test
application. This redundant effort can be greatly reduced if processes and tools support the OTX
concept.
The ISO 13209 series proposes an open and standardized format for the human- and machine-readable
description of diagnostic test sequences. The format supports the requirements of transferring
diagnostic test sequence logic uniformly between electronic system suppliers, vehicle manufacturers
and service dealerships/repair shops.
This document represents the requirements and technical specification for the fundament of the OTX
format, namely the “OTX core”. The core describes the basic structure underlying every OTX document.
This comprises detailed data model definitions of all required control structures by which test
sequence logic is described, but also definitions of the outer, enveloping document structure in which
test sequence logic is embedded. To achieve extensibility the core also contains well-defined extension
points that allow a separate definition of additional OTX features—without the need to change the core
data model.
[2]
ISO 13209-3 extends the core by a set of additional features, using of the core extension mechanism
(which may also be applied for proprietary extensions).
This document is the most generic and stand-alone part of the ISO 13209 series. In principle, it is also
applicable in other areas for any sequential logic description, even outside the automotive domain.
[2]
Automotive-specific features are, therefore, contained solely in ISO 13209-3 .
vii
INTERNATIONAL STANDARD ISO 13209-2:2022(E)
Road vehicles — Open Test sequence eXchange format
(OTX) —
Part 2:
Core data model specification and requirements
1 S cope
This document defines the OTX core requirements and data model specifications.
The requirements are derived from the use cases described in ISO 13209-1. They are listed in the
requirements section.
The data model specification aims at an exhaustive definition of all OTX core features implemented to
satisfy the core requirements. Since OTX is designed for describing test sequences, which themselves
represent a kind of program, the core data model follows the basic concepts common to most
programming languages.
Thus, this document establishes rules for syntactical entities like parameterised procedures, constant
and variable declarations, data types, basic arithmetic, logic and string operations, flow control
statements like loop, branch or return, simple statements like assignment or procedure call as well as
exception handling mechanisms. Each of these syntactical entities is accompanied by semantic rules
which determine how OTX documents are interpreted. The syntax rules are provided by UML class
diagrams and XML schemas, whereas the semantics are given by UML activity diagrams and prose
definitions.
With respect to documentation use cases, special attention is paid to defining a specification/realisation
concept (which allows for “hybrid” test sequences: human readable test sequences that are at the same
time machine-readable) and so-called floating comments (which can refer to more than one node of the
sequence).
The core data model does not define any statements, expressions or data types that are dependent on a
specific area of application.
For the convenience of the user, the ISO 13209-2 OTX XML schema definition file (XSD) is published
alongside this document.
2 Normat ive 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.
ISO 13209-1, Road vehicles — Open Test sequence eXchange format (OTX) — Part 1: General information
and use cases
ISO 22901 (all parts), Road vehicles — Open diagnostic data exchange (ODX)
IEEE 754:2019, IEEE Standard for Floating-Point Arithmetic
RFC 2045, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
RFC 2046, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
W3C XSD (all parts):2012, W3C Recommendation: W3C XML Schema Definition Language (XSD) 1.1
W3C XML: 2008, W3C Recommendation: Extensible Markup Language (XML) 1.0
W3C XLink: 2010, W3C Recommendation: XML Linking Language (XLink) Version 1.1
3 T erms, definitions and abbreviated terms
3.1 T erms and definitions
For the purposes of this document, the terms and definitions given in ISO 13209-1 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.1
attribute
property of a UML class
3.1.2
attribute
named property of an XSD complex type or an XML element
3.1.3
constant
identifier of a non-writable memory location
3.1.4
context
environmental circumstances which influence test sequence (3.1.11) execution
Note 1 to entry: OTX test sequences can be configured to behave differently according to different context
situations. Contextual information depends on factors such as the particular vehicle that is currently attached to
the test application (e.g. the current vehicle's model type, the engine type), on the test application settings (e.g. a
setting controlling whether the test sequence shall run in debug mode) or on other factors such as whether the
test sequence is running in a manufacturing or a service workshop environment, etc.
3.1.5
expression
syntactical construct which describes a specific computation with a set of arguments and a single
return value
3.1.6
identification routine
method or software by which a diagnostic application identifies contextual information
3.1.7
procedure signature
description of the interface of an OTX procedure
3.1.8
reference
value which refers to data in memory
3.1.9
session
instance of test sequence (3.1.11) execution
3.1.10
term
value described by and computed from an expression (3.1.5)
3.1.11
test sequence
test procedure (3.1.12) defining a full test
Note 1 to entry: A test sequence is also a procedure, but not all procedures are test sequences. In an OTX document,
the procedure representing a test sequence shall be named “main”. By using procedures, a test sequence may be
split into several procedure modules. An adequately assembled set of frequently needed procedures may serve as
a library which provides procedures that can be called from any other (client) procedure or test sequence.
3.1.12
test procedure
procedure
stand-alone, parameterisable flow of OTX actions that can be called from other OTX procedures
3.1.13
validity
named Boolean expression (3.1.5) used for activating/deactivating parts of the OTX test sequences
(3.1.11) according to the current context (3.1.4) situation
Note 1 to entry: Parts of OTX test sequences which are marked with a validity name shall be executed only if the
associated Boolean expression is true according to the current context situation.
3.1.14
variable
identifier of a writable memory location
Note 1 to entry: The term “variable” is used as a collective term for document scope variables, local variables,
non-constant parameters and also items in non-constant lists or maps or other compound data structures. In
OTX, these can be addressed by giving the identifier of the variable or parameter, optionally accompanied by a
path into compound data structures which allows the inner parts of variables or parameters to be addressed.
3.2 A bbreviated terms
API Application Programming Interface
IFD Interface Definition (OTX extension)
JRE Java Runtime Environment
NOP No Operation Performed
OEM Original Equipment Manufacturer
OTX Open Test sequence eXchange
UML Unified Modelling Language
XML Extensible Markup Language
XSD XML Schema Definition
4 R equirements and recommendations
4.1 General
Since OTX is merely a static data format and not a software application, it shall be kept in mind that all
of the following entries (requirements or recommendations) are related to static format features and
not to the behaviour of any OTX-based software product. All such products are indirectly affected by
the requirements or recommendations given in this document considering that they shall be able to
write, read or execute valid OTX documents according to the rules given in this document. Aside from
that, requirements towards any such product are not in the scope of this document.
4.2 Basic principles fo r requirements and recommendations definition
Basic principles have been established as a guideline to define the OTX requirements or
recommendations:
— OTX requirements or recommendations specify the conditions that the OTX data model and format
shall satisfy,
— all stakeholders (system suppliers, OEMs, tool suppliers), which offer diagnostic test procedures are
expected to implement and follow the requirements of this document,
— the content of OTX documents and the quality of the information is the responsibility of the
originator,
— the runtime system defines an OTX home directory. It is the entry directory for all relative file and
directory access (see Annex F).
4.3 Clust ering of requirements and recommendations
Table 1 provides an overview of the main categories of OTX requirements or recommendations. Each
category may have one or more entries.
Table 1 — Main requirements clustering
# Main title of requirement clus- Brief description
ter
1 General format and language Requirements or recommendations regarding the general aspects like
requirements the chosen programming paradigm, file format (XML), etc.
2 Test sequence development pro- Requirements or recommendations about different stages in the test
cess support procedure authoring process, outlining human-readable (documenta-
tion) versus machine-readable (execution) test procedures
3 Language feature details Requirements or recommendations concerning details like declara-
tions, data types, expressions, statements, etc.
4 Boundaries Features that should not be part of OTX
4.4 Entries priorities
Each of the following requirements and recommendations carries a priority-attribute which can be set
to SHALL or SHOULD.
— SHALL:
The requirement represents stakeholder-defined characteristics, the absence of which will result in
a deficiency that cannot be compensated by other means.
— SHOULD:
If the recommendation-defined characteristic is not or not fully implemented in the data model, it
does not result in a deficiency, because other features in the data model can be used to circumvent
this.
4.5 Gener al format and language aspects
Core_R01 – Machine readable format
Priority: SHALL
Rationale: The focus of OTX is on the exchange of data between tools in the vehicle diagnostic process.
To leverage highest efficiency, the tools shall be able to operate automatically on OTX files (e.g. for
importing and exporting of OTX-relevant data).
Description: OTX format shall be machine-readable to allow a tool to open an existing document for
editing, checking, displaying or executing.
Core_R02 – Platform independence
Priority: SHALL
Rationale: If OTX would bind to specific hardware, operating system or application, its potential usages
are diminished and applicability of the ISO 13209 series is decreased.
Description: OTX shall not be dependent on any specific hardware or software platform. OTX shall not
be bound to any particular hardware, operating system or application.
Core_R03 – Well-defined syntax and semantics
Priority: SHALL
Rationale: OTX shall be a machine-readable data format. This implies an unamb
...