Road vehicles — Open Test sequence eXchange format (OTX) — Part 2: Core data model specification and requirements

ISO 13209-2:2012 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 that composes the first major part of ISO 13209-2:2012. 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. ISO 13209-2:2012 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.

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

General Information

Status
Withdrawn
Publication Date
02-Aug-2012
Current Stage
9599 - Withdrawal of International Standard
Completion Date
26-Jul-2022
Ref Project

Relations

Buy Standard

Standard
ISO 13209-2:2012 - Road vehicles -- Open Test sequence eXchange format (OTX)
English language
205 pages
sale 15% off
Preview
sale 15% off
Preview
Standard
ISO 13209-2:2012 - Road vehicles -- Open Test sequence eXchange format (OTX)
English language
205 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)

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 13209-2:2012(E)
©
ISO 2012

---------------------- Page: 1 ----------------------
ISO 13209-2:2012(E)


This CD-ROM contains:
1) the publication ISO 13209-2:2012 in portable document format (PDF), which can be viewed using
Adobe® Acrobat® Reader;
2) the 13209-2 OTX XML schema definition file (see ISO 13209-2:2012, Annex F).
Adobe and Acrobat are trademarks of Adobe Systems Incorporated.


COPYRIGHT PROTECTED DOCUMENT


©  ISO 2012
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 copyright@iso.org
Reproduction may be subject to royalty payments or a licensing agreement.
Violators may be prosecuted.
Published in Switzerland

ii © ISO 2012 – All rights reserved

---------------------- Page: 2 ----------------------
ISO 13209-2:2012(E)
Installation
If this publication has been packaged as a zipped file, do NOT open the file from the CD-ROM, but copy it to
the de
...

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 13209-2:2012(E)
©
ISO 2012

---------------------- Page: 1 ----------------------
ISO 13209-2:2012(E)

COPYRIGHT PROTECTED DOCUMENT


©  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

---------------------- Page: 2 ----------------------
ISO 13209-2:2012(E)
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
© ISO 2012 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO 13209-2:2012(E)
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

---------------------- Page: 4 ----------------------
ISO 13209-2:2012(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 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
© ISO 2012 – All rights reserved v

---------------------- Page: 5 ----------------------
ISO 13209-2:2012(E)
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

---------------------- Page: 6 ----------------------
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
© ISO 2012 – All rights reserved 1

---------------------- Page: 7 ----------------------
ISO 13209-2:2012(E)
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

---------------------- Page: 8 ----------------------
ISO 13209-2:2012(E)
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
© ISO 2012 – All rights reserved 3

---------------------- Page: 9 ----------------------
ISO 13209-2:2012(E)
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

---------------------- Page: 10 ----------------------
ISO 13209-2:2012(E)
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.
© ISO 2012 – All rights reserved 5

---------------------- Page: 11 ----------------------
ISO 13209-2:2012(E)
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

---------------------- Page: 12 ----------------------
ISO 13209-2:2012(E)
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
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.