ISO 13209-2:2012

INTERNATIONAL ISO
STANDARD 13209-2
First edition
2012-08-15
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 2012
©  ISO 2012
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 copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2012 – All rights reserved

Contents Page
Foreword . v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 2
3.1 Terms and definitions . 2
3.2 Abbreviated terms . 4
4 Requirements . 5
4.1 General . 5
4.2 Basic principles for requirements definition . 5
4.3 Clustering of requirements. 5
4.4 Requirement priorities . 5
4.5 General format and language aspects . 6
4.6 Test sequence development process support . 7
4.7 Language feature details . 9
4.8 Boundaries . 15
5 Introduction to modelling in UML and XSD . 17
5.1 General aspects . 17
5.2 Class diagrams . 17
5.3 Mapping to the XML Schema Definition language (XSD) . 19
6 OTX principles . 23
6.1 General . 23
6.2 XML format . 23
6.3 Imperative and structured programming paradigm . 24
6.4 Graphical authoring of OTX sequences . 24
6.5 Specification/Realisation concept . 24
6.6 Modular OTX extension concept and OTX-based runtime architecture . 25
6.7 Context concept . 26
6.8 Validities concept . 27
6.9 Signature concept . 30
7 OTX Core data model specification . 31
7.1 General . 31
7.2 High-level overview of the OTX Core data model . 32
7.3 Document root . 33
7.4 Imports. 37
7.5 Global declarations . 38
7.6 Validity terms . 42
7.7 Signatures . 44
7.8 Procedure signatures . 46
7.9 Procedures . 48
7.10 Floating comments . 51
7.11 Parameter declarations . 53
7.12 Local declarations . 55
7.13 Nodes . 56
7.14 Actions. 90
7.15 Terms . 106
7.16 Universal types . 140
Annex A (normative) OTX data types . 162
Annex B (normative) Scope and memory allocation . 166
Annex C (normative) Comprehensive checker rule listing . 168
Annex D (normative) Extension mechanism . 178
Annex E (normative) Schema annotations for exception handling . 181
Annex F (normative) XML Schemas . 182
Bibliography . 205

iv © ISO 2012 – All rights reserved

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 13209-2 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3,
Electrical and electronic equipment.
ISO 13209 consists of the following parts, under the general title Road vehicles — Open Test sequence
eXchange format (OTX):
 Part 1: General information and use cases
 Part 2: Core data model specification and requirements
 Part 3: Standard extensions and requirements
Introduction
Diagnostic test sequences are utilized whenever automotive components or functions with diagnostic abilities
are being diagnosed, tested, reprogrammed or initialised 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.
ISO 13209 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 part of ISO 13209 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.
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 part of ISO 13209 is the most generic and stand-alone part of ISO 13209. In principle, it is also applicable
in other areas for any sequential logic description, even outside the automotive domain. Automotive-specific
features are therefore contained solely in ISO 13209-3.
vi © ISO 2012 – All rights reserved

INTERNATIONAL STANDARD ISO 13209-2:2012(E)

Road vehicles — Open Test sequence eXchange format (OTX) —
Part 2:
Core data model specification and requirements
1 Scope
This part of ISO 13209 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 which composes the first major part of this document.
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 part of ISO 13209 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 to be 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.
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/IEC 10646:2011, Information technology — Universal Coded Character Set (UCS)
ISO 13209-1, Road vehicles — Open Test sequence eXchange format (OTX) — Part 1: General information
and use cases
ISO/IEC 19501:2005, Information technology — Open Distributed Processing — Unified Modeling Language
(UML) Version 1.4.2
ISO 22901 (all parts), Road vehicles — Open diagnostic data exchange (ODX)
IEEE 754:2008, 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
RFC 4122, A Universally Unique IDentifier (UUID) URN Namespace
W3C XSD:2004, W3C Recommendation: XML Schema (all parts)
W3C XML:2008, W3C Extensible Markup Language (XML) 1.0 (Fifth Edition)
W3C XMLNS:2009, W3C Recommendation: Namespaces in XML 1.0 (Third Edition)
W3C XMLBASE:2009, W3C Recommendation: XML Base (Second Edition)
W3C XLink:2010, W3C Recommendation: XML Linking Language (XLink) Version 1.1
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 13209-1 and the following apply.
3.1.1
attribute
a property of a UML class
3.1.2
attribute
named property of an XSD complex type or an XML element
3.1.3
after market
part of the automotive industry concerned with manufacturing, remanufacturing, distribution, retailing, and
installation of all vehicle parts, chemicals, tools, equipment and accessories for light and heavy vehicles, after
the sale of the automobile by the original equipment manufacturer (OEM) to the consumer
3.1.4
after sales
after sales department
department of an automotive OEM that is concerned with the distribution, retailing, servicing, repair and
installation of vehicles of that OEM
3.1.5
constant
identifier of a non-writable memory location
3.1.6
context
environmental circumstances which influence test sequence execution
NOTE 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, etc.), 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.
2 © ISO 2012 – All rights reserved

3.1.7
engineering
engineering department
department of an automotive OEM which is concerned with the design, development, integration and testing
of vehicles of that OEM
3.1.8
expression
syntactical construct which describes a specific computation with a set of arguments and a single return value
3.1.9
identification routine
method or software by which a diagnostic application identifies contextual information
3.1.10
manufacturing
manufacturing department
department of an automotive OEM which is concerned with the production and end-of-line testing of vehicles
of that OEM
3.1.11
original equipment manufacturer
OEM
automotive company that engineers, manufactures, sells and services vehicles
3.1.12
OTX Core
most generic and stand-alone part of the overall OTX data model which describes the basic structure
underlying every OTX document and comprises detailed data model definitions of all required control
structures (loops, branches, …) by which test sequence logic is described, but also definitions of the outer,
enveloping document structure in which test sequence logic is embedded
3.1.13
OTX Extension
OTX Standard Interface Definition
otxIFD
set of OTX data type-, action-, term- and signature-definitions that are tailored for a specific area of application
and that are defined aside of the OTX Core
NOTE OTX Extensions model the data types, actions, terms and signatures needed for communication through
diverse interfaces. By using these interfaces, calls can be performed to external systems whose internal behaviour does
not have to be known to the (client) OTX test sequence/runtime. The system-side interface (server-side) can be
proprietary because the adapter design pattern is applied.
3.1.14
procedure signature
description of the interface of an OTX procedure
3.1.15
reference
value which refers to data in memory
3.1.16
session
instance of test sequence execution
3.1.17
term
value described by and computed from an expression
3.1.18
test sequence
test procedure defining a full test
NOTE A test sequence is a procedure also, 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.19
test procedure
procedure
stand-alone, parameterisable flow of OTX actions that can be called from other OTX procedures
3.1.20
validity
Boolean context variable, global Boolean constant or a named Boolean expression used for activat-
ing/deactivating parts of the OTX test sequences according to the current context situation
NOTE 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.21
variable
identifier of a writable memory location
NOTE 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 Abbreviated 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 Modeling Language
XML Extensible Markup Language
XSD XML Schema Definition
4 © ISO 2012 – All rights reserved

4 Requirements
4.1 General
Since OTX is merely a static data format and not a software application, it has to be kept in mind that all
following requirements are related to static format features and not to the behaviour of any OTX based
software product. As a matter of course, all such products are indirectly affected by the requirements given
here in so far 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
specification.
4.2 Basic principles for requirements definition
Basic principles have been established as a guideline to define the OTX requirements:
a) OTX requirements specify the conditions that the OTX data model and format shall satisfy.
b) All stakeholders (System Suppliers, OEMs, Tool Suppliers), which offer diagnostic test procedures are
expected to implement and follow the requirements of this part of ISO 13209.
c) The content of OTX documents and the quality of the information is the responsibility of the originator.
4.3 Clustering of requirements
Table 1 provides an overview of the main categories of OTX requirements. Each category may have one or
more requirements.
Table 1 — Main requirements clustering
# Main title of requirement cluster Brief description
1 general format and language Requirements regarding the general aspects like the chosen programming
requirements paradigm, file format (XML), …
2 test sequence development Requirements about different stages in the test procedure authoring
process support process, outlining human-readable (documentation) vs. machine-readable
(execution) test procedures.
3 language feature details Requirements concerning details like declarations, data types, expressions,
statements, etc.
4 boundaries Features that should NOT be part of OTX

4.4 Requirement priorities
Each of the following requirements 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 requirement 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 General 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: The OTX format has to 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 standard 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 unambiguously defined syntax and
semantics.
Description: All OTX elements have to be defined clearly (syntax + semantics). For the syntax definition,
XML Schema shall be used. For the behavioural/semantics specification, a prose description shall exist.
Core_R04 – Universal language
Priority: SHALL
Rationale: Diagnostic applications can be seen as domain specific computer programs. These require
complex computations and no limits are known or foreseen today that allow OTX to be restricted with respect
to Turing-completeness.
Description: OTX shall have the ability to solve any computable problem. (Turing-Completeness)
NOTE 1 Legacy sequences can (theoretically) be transformed to OTX and back, if the legacy sequence format and
OTX are Turing-complete.
Core_R05 – Minimal language
Priority: SHOULD
Rationale: Fulfilment of this requirement reduces the implementation effort necessary to integrate OTX into
tools and is thus a very relevant market-driving factor for OTX.
Description: OTX should be defined with the minimal set of language elements necessary to reach Turing-
Completeness.
6 © ISO 2012 – All rights reserved

NOTE 2 OTX should not be designed for comfort of expressing computational programs (as are programming
languages like Java, C++ or Delphi), but rather for effectiveness of transporting diagnostic application knowledge
unambiguously between different tools/parties in the diagnostic process.
Core_R06 – Structured programming approach
Priority: SHALL
Rationale: Structured programming can be seen as a subset or sub discipline of procedural programming,
one of the major programming paradigms. It removes reliance on the GOTO statement for controlling the flow
of a program. Using GOTO statements in programming often leads to a complex, tangled and unreadable
control structure, which is clearly not desired in OTX.
Description: OTX shall follow the structured programming approach. Only flow control statements branch,
loop return, continue, break and throw may implicitly induce jumps. The behaviour of these jumps shall be well
defined in the prose semantic documentation of each of these statements. An explicit GOTO statement which
allows to jump anywhere in the procedure shall not be supported
Core_R07 – Imperative structure
Priority: SHALL
Rationale: Test procedures are usually considered as a procedure of commands that need to be executed
one after one by a runtime system. Since the imperative programming paradigm matches exactly for this
concept, it is well suited for OTX.
Description: OTX shall only support program structures that can be translated by a compiler into imperative
programming languages.
Core_R08 – Extensibility
Priority: SHALL
Rationale: The scope of diagnostic applications in the diagnostic process is wide. Engineering, Production
and After Sales applications interface numerous and diverse devices, server applications and modules, which
cannot be completely addressed with the first release of the standard and which evolve over time.
Description: OTX shall be extendable to integrate means to access new technology employed within the
diagnostic process. It shall be possible to integrate interfaces of various base technologies into OTX.
4.6 Test sequence development process support
Core_R09 – Embed non-machine readable content
Priority: SHALL
Rationale: Use cases will occur where diagnostic applications shall be expressed in OTX but e.g. the
interfaces to all used devices are not available (e.g. how to communicate to a nut runner). In this case it would
be preferable to express the diagnostic application in OTX and express the non-standardized device access in
prose or in pseudo code. An OTX-compliant tool could then import such a file and mark the parts of the
diagnostic application that need to be replaced with executable content by a diagnostics engineer.
Description: OTX shall provide means to express parts of a diagnostic application in a non-machine readable
format. This non-machine readable content shall be clearly marked so that processes operating on OTX files
can identify it.
Core_R10 – High level test procedure
Priority: SHALL
Rationale: In a step-wise test procedure design process, it might become necessary to specify procedures in
prose-form only. Skeletal control structures might already be part if this high-level description, but the details
of implementation might not be known at design time (loop conditions, exact service names …).
Description: It shall be possible to describe test procedures at a high level.
Core_R11 – Exchange high level test procedure
Priority: SHALL
Rationale: A test procedure specified in prose-form only shall nevertheless pose a valid OTX document, even
though it is not executable.
Description: It shall be possible to exchange a high-level test plan using a plain text description.
Core_R12 – Exchange a fully functional test procedure
Priority: SHALL
Rationale: A test procedure containing no prose-form, but only implementation details shall nevertheless
pose a valid OTX document, even though it is not easily human-readable.
Description: It shall be possible to mix high-level description and implementation details on the same
procedure.
Core_R13 – Exchange an intermediate stage test procedure
Priority: SHALL
Rationale: A test procedure containing a mix of prose and fully implemented parts shall nevertheless pose a
valid OTX document.
Description: It shall be possible to mix high-level description and implementation details on the same
procedure.
Core_R14 – Floating comments
Priority: SHALL
Rationale: Situations will occur where comments are needed that can be freely attached to parts of the flow of
commands in a test procedure. Such comments shall not be locally bound or contained within single
statements; they shall be defined aside from the flow and only point to parts of it. Comments are purely
informational nodes that shall not be relevant for execution of a test procedure.
Description: It shall be possible add floating comments to a test procedure that can refer to one or more
statements its flow or its sub-flows at any block depth.
8 © ISO 2012 – All rights reserved

4.7 Language feature details
4.7.1 Declarations
Core_R15 – Declarations
Priority: SHALL
Description: OTX has to support the declaration of constants and variables as well as test procedure
parameters. A declaration shall contain a name, a data type, an optional initialisation value and an optional
description.
Core_R16 – Initialisation
Priority: SHALL
Rationale: It shall be possible to set the initial value for an identifier to a value other than the default.
Description: OTX shall support the optional initialisation of declared identifiers.
Core_R17 – Constant declarations
Priority: SHALL
Rationale: There will be cases when an OTX author wants to guarantee that the value of an identifier in the
test procedure can not be changed. Therefore the author needs to have a means to mark an identifier as a
constant. The value of a constant is not allowed to change during the lifetime of the constant.
Description: OTX shall support the declaration of constants. Constants shall be set with the declaration
(initialisation is mandatory).
Core_R18 – Variable declaration
Priority: SHALL
Rationale: In order to reflect the fact that an identifier can change its value during procedure execution, a
means for marking identifiers as variables is needed. The value of a variable is allowed to change during
procedure execution; new values can be assigned to it.
Description: OTX shall support the declaration of variables.
Core_R19 – Input parameter declarations
Priority: SHALL
Rationale: When a test procedure is called, it will occur that information needs to be passed to the called
procedure.
Description: OTX shall support declaration of any number of input parameters that are passed to the test
procedure from the caller.
Core_R20 – Output parameter declarations
Priority: SHALL
Rationale: When a test procedure is called, it will occur that information needs be retrieved from the called
procedure, after it has executed.
Description: OTX shall support declaration of any number of output parameters. Output parameters shall be
assignable to variables in the calling test procedure.
Core_R21 – Two-way parameter declarations
Priority: SHOULD
Rationale: There are situations when a variable reference shall be passed to a called test sequence, so that
any modifications will be visible to the caller also.
Description: OTX should support declaration of any number of two-way parameters. Any declared two-way
parameter is passed from the caller to the test procedure. Any changes of the value of a two-way parameter
can be assigned to variables of the caller test sequence.
NOTE This is the combination of input and output parameters.
4.7.2 Data types
Core_R22 – Strong typing
Priority: SHALL
Rationale: In order to have the possibility to translate into various other languages, OTX shall be strong
typed. This means, the binding of a variable to a data type persists during the variables whole lifetime.
Description: OTX shall be a strong typed, static checked language.
Core_R23 – Data types
Priority: SHALL
Rationale: To maintain a state during test procedure execution, information needs to be stored in memory.
Since the type and the structure of the stored information needs to be known for a typed language (be it a
string, an integer or a map …) declared parameters, it shall be possible to mark variables and constants with
the corresponding data type.
Description: OTX shall support a well defined set of data types.
Core_R24 – Extension mechanism for data types
Priority: SHALL
Rationale: There will be situations when the predefined set of data types will not be sufficient. Therefore, OTX
shall be extensible by new data types.
Description: It shall be possible to extend the set of data types by new data types. This shall happen by a
well defined extension mechanism.
10 © ISO 2012 – All rights reserved

Core_R25 – Raw memory data type
Priority: SHALL
Description: OTX shall support a raw memory data type.
Core_R26 – Integer data type
Priority: SHALL
Description: OTX shall support an integer data type.
Core_R27 – Floating point data type
Priority: SHALL
Description: OTX shall support a floating point data type.
Core_R28 – String data type
Priority: SHALL
Description: OTX shall support a String data type.
Core_R29 – Boolean data type
Priority: SHALL
Description: OTX shall support a Boolean data type.
Core_R30 – Container data type
Priority: SHALL
Description: OTX shall support at least one container data type. It shall be possible to access, dynamically
add and remove elements in the container. The elements in the container shall all be of the same data type.
Recursive declaration shall be possible (e.g. Container of Containers of Integers).
4.7.3 Expressions
Core_R31 – Expressions
Priority: SHALL
Description: OTX shall support expressions. At runtime, it shall be possible to evaluate such an expression in
a well defined way. After evaluation, it has exactly one return value of a defined data type and shall not have
any side-effects. This means, no data from the test procedure is allowed to be changed by evaluation of the
expression but the variable where the evaluated value will be assigned to.
NOTE 1 In general, OTX expressions correspond to the term "function" in the mathematical sense.
Core_R32 – Extension mechanism for expressions
Priority: SHALL
Description: It shall be possible to extend the set of expressions by new expression types. This shall happen
by a well defined extension mechanism.
Core_R33 – Literal expressions
Priority: SHALL
Description: OTX shall support literal expressions defined for each simple data type and for collection types
(lists, maps …). The literal shall represent the value of the literal expression directly.
Core_R34 – Dereferencing expressions
Priority: SHALL
Description: OTX shall support dereferencing expressions. They shall allow reading data referenced by
parameter-, variable- or constant-names.
Core_R35 – Combined expressions: functions
Priority: SHALL
Rationale: Allow creation of higher level expressions (functions) that contain other expressions as arguments.
The evaluation shall happen recursively.
Description: OTX shall support a well defined set of functions.
NOTE 2 Most programming languages describe very frequently used mostly mathematical functions by operators (+
for add(a,b), * for multiply(a,b) …) There shall be no special treatment of operators in OTX; they shall rather be described
like functions. It is the task of OTX tools to show them as operators, if needed.
Core_R36 – Basic function set
Priority: SHALL
Description: OTX shall support the basic functions:
 mathematical: addition, subtraction, multiplication, division, negation, modulo, power
 bitwise: conjunction, disjunction, negation
 relations: equality, greater than, less than
 logical: conjunction, disjunction, negation
 string: concatenation
12 © ISO 2012 – All rights reserved

Core_R37 – Statements
Priority: SHALL
Rationale: Statements are needed to represent single commands or higher-level control structures in a
procedure. In order to achieve Turing-Completeness, a set of basic statements with different semantics has to
be part of OTX. Statements are made up out of distinct parts, e.g. in a loop statement, parts are a condition
which is a logic expression, and a sub-sequence of commands. A procedure call statement consists of other
parts, namely the called procedures name and a list of parameters.
Description: OTX shall support statements.
Core_R38– Extension mechanism for statements
Priority: SHALL
Description: It shall be possible to extend the set of statements by new statement types. This shall happen
by a well defined extension mechanism.
Core_R39 – Blocks of statements
Priority: SHALL
Rationale: Situations will often occur that a sequence of statements needs to be grouped together. The
sequence of grouped statements builds a block. There may also be blocks in blocks recursively. Blocks are
needed for defining the body of a loop, branch case, etc., but also for simply providing a better overview in a
test procedure.
Description: It shall be possible to define blocks of statements, recursively.
Core_R40 – Block statement
Priority: SHALL
Description: It shall be possible that blocks of statements can be used as statements themselves.
Core_R41 – Assignment statement
Priority: SHALL
Description: OTX shall support an assignment statement for assigning expression values to variables.
Core_R42 – Call procedure statement
Priority: SHALL
Description: OTX shall support a call statement for calling other OTX test procedures with a list of arguments
that correspond to the test procedure parameter list. The call shall be synchronous, i.e. the caller shall wait
until the called test procedure returns.
Core_R43 – Branch statement
Priority: SHALL
Description: OTX shall support a branch statement, which allows reacting to different conditions.
Core_R44 – Parallelisation statement
Priority: SHALL
Description: OTX shall support a parallelisation statement, which allows executing two or more blocks at the
same time. The sub-sequences shall be embedded within the parallelisation statement.
Core_R45 – Loop statement
Priority: SHALL
Description: OTX shall support a loop statement, which allows executing a block repetitively, as long as a
defined condition is met.
Core_R46 – Continue statement
Priority: SHALL
Description: OTX shall support a continue statement. If used within a loop sub-sequence, this shall stop
block execution immediately and induce the next iteration. Outside of a loop, it shall have no meaning.
Core_R47 – Break statement
Priority: SHALL
Description: OTX shall support a break statement. If used within a loop block, this shall force the sub-
sequence execution to stop immediately. The outer block shall then be continued at the statement right after
the broken loop. Outside of a loop, it shall have no meaning.
Core_R48 – Return statement
Priority: SHALL
Description: OTX shall support a return statement. This shall force the execution of the running test
procedure to stop immediately and pass control to the caller.
Core_R49 – Exception handler statement
Priority: SHALL
Rationale: When an exception occurs during test procedure execution, a means is needed to treat such an
exception so that execution may still be continued in a controlled manner. It should be possible to define
exception-monitored blocks in the procedure, and also to define blocks dedicated to handle a particular
exception type.
Description: OTX shall support a statement for exception handling. The statement shall allow reacting to
different exceptions in different ways.
14 © ISO 2012 – All rights reserved

Core_R50 – Throw statement
Priority: SHALL
Rationale: Under certain circumstances it is necessary to throw exceptions intentionally.
Description: There shall be a throw statement that allows throwing an exception of a particular type.
Core_R51 – Validity information for statements
Priority: SHALL
Rationale: Enable/disable statements according to validity information.
Description: There shall be a well-defined means to add validity information to any statement in OTX
procedures. The validity information defines under which predefined context conditions
...