Tiêu chuẩn iso 13209 2 2012

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 d

Terms and definitions

For the purposes of this document, the terms and definitions given in ISO 13209-1 and the following apply

a property of a UML class

named property of an XSD complex type or an XML element

The aftermarket segment of the automotive industry involves the manufacturing, remanufacturing, distribution, retailing, and installation of vehicle parts, chemicals, tools, equipment, and accessories for both light and heavy vehicles This sector operates after the sale of the automobile by the original equipment manufacturer (OEM) to the consumer, ensuring ongoing maintenance and replacement needs are met.

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

OTX test sequences can be customized to adapt to various contextual factors, ensuring precise testing conditions The behavior of these sequences depends on elements such as the specific vehicle attached, including its model and engine type, as well as test application settings like debug mode activation Additionally, environmental factors, such as whether the test is conducted in a manufacturing facility or a service workshop, influence the configuration and execution of the test sequences.

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

OEM automotive company that engineers, manufactures, sells and services vehicles

OTX Core is the most essential and standalone component of the OTX data model, providing the fundamental structure for all OTX documents It includes detailed definitions of necessary control structures such as loops and branches that describe test sequence logic Additionally, OTX Core defines the outer document framework that encapsulates the embedded test sequences, ensuring a comprehensive and organized representation of testing procedures.

The OTX Standard Interface Definition (otxIFD) is a comprehensive set of OTX data types, actions, terms, and signature definitions tailored for specific application areas These definitions are designed separately from the core OTX framework to ensure specialized functionality and compatibility within targeted industries By providing a structured and standardized interface, otxIFD enhances interoperability and facilitates efficient application development and integration within the OTX ecosystem.

OTX Extensions model essential data types, actions, terms, and signatures required for seamless communication across various interfaces These interfaces enable calls to external systems without requiring the client OTX test sequence or runtime to understand their internal behavior By applying the adapter design pattern, the system-side (server-side) interface can remain proprietary, ensuring flexible integration and interoperability.

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

Copyright International Organization for Standardization

Provided by IHS under license with ISO

3.1.18 test sequence test procedure defining a full test

A test sequence is a specific procedure designated as "main" within an OTX document, although not all procedures qualify as test sequences Procedures enable the division of a test sequence into modular components, facilitating better organization and reusability A well-structured collection of commonly used procedures can function as a library, allowing these procedures to be called from any other procedure or test sequence, thereby enhancing efficiency and maintainability.

3.1.19 test procedure procedure stand-alone, parameterisable flow of OTX actions that can be called from other OTX procedures

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

In OTX, the term "variable" collectively refers to document scope variables, local variables, non-constant parameters, and items within non-constant lists, maps, or other complex data structures These variables can be accessed by their identifier, with optional paths into compound data structures, enabling direct access to inner elements Understanding how to address and manipulate these variables is essential for effective data handling and workflow customization within OTX.

Abbreviated terms

IFD Interface Definition (OTX extension)

OTX Open Test sequence eXchange

General

OTX is a static data format, not a software application, so all requirements relate solely to its format features rather than software behavior Any OTX-based software must be capable of reading, writing, and executing valid OTX documents in accordance with these rules However, the specifications do not cover additional requirements or functionality beyond the static format, ensuring clear guidelines for OTX document compliance without addressing software performance or features.

Basic principles for requirements definition

The foundational principles of OTX requirements establish clear guidelines that define the necessary conditions for the OTX data model and format to ensure consistency and compatibility All stakeholders—including system suppliers, OEMs, and tool suppliers involved in diagnostic test procedures—are expected to implement and adhere to these ISO 13209 standards Additionally, the responsibility for the content quality and accuracy of OTX documents lies with the original document creators, emphasizing the importance of reliable and well-maintained information for effective diagnostic processes.

Clustering of requirements

Table 1 provides an overview of the main categories of OTX requirements Each category may have one or more requirements

# Main title of requirement cluster Brief description

1 general format and language requirements

Requirements regarding the general aspects like the chosen programming paradigm, file format (XML), …

2 test sequence development process support

Requirements about different stages in the test procedure authoring 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

Requirement priorities

Each of the following requirements carries a priority-attribute which can be set to SHALL or SHOULD

The requirement represents stakeholder-defined characteristics the absence of which will result in a deficiency that cannot be compensated by other means

Incomplete implementation of a defined characteristic in the data model does not necessarily lead to deficiencies, as other features within the model can be leveraged to compensate or work around this limitation.

General format and language aspects

OTX is designed to facilitate seamless data exchange between diagnostic tools, ensuring a more efficient vehicle diagnostic process By enabling tools to automatically operate on OTX files—for tasks such as importing and exporting OTX-related data—OTX enhances automation and improves overall workflow efficiency in automotive diagnostics.

Description: The OTX format has to be machine-readable to allow a tool to open an existing document for editing, checking, displaying or executing

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

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

Diagnostic applications function as domain-specific computer programs, performing complex computations essential for accurate analysis Currently, there are no known limitations or constraints that restrict OTX's capabilities concerning Turing-completeness, highlighting its ability to handle extensive and intricate processing tasks within the diagnostic domain.

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

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-

OTX is not designed to prioritize user comfort in expressing computational programs, unlike programming languages such as Java, C++, or Delphi Instead, its primary purpose is to ensure the effective, unambiguous transfer of diagnostic application knowledge between various tools and parties involved in the diagnostic process.

Structured programming is a vital subset of procedural programming, a primary paradigm in software development It emphasizes the elimination of GOTO statements to improve code clarity and maintainability By removing GOTO statements, structured programming prevents complex, tangled, and unreadable control flows, making programs easier to understand and less prone to errors—an essential requirement in OTX.

OTX adopts a structured programming approach, permitting only flow control statements such as branch, loop, return, continue, break, and throw to implicitly induce jumps The behavior of these jumps is clearly defined in the prose semantic documentation for each statement Importantly, explicit GOTO statements, which could jump arbitrarily within procedures, are not supported, ensuring a clear and maintainable code structure.

Test procedures are typically viewed as a sequence of commands that must be executed sequentially by a runtime system The imperative programming paradigm aligns perfectly with this concept, making it highly suitable for implementing OTX.

Description: OTX shall only support program structures that can be translated by a compiler into imperative programming languages

The scope of diagnostic applications is extensive, encompassing engineering, production, and after-sales processes These applications interface with a wide variety of devices, server applications, and modules, making it challenging to cover all aspects in the initial release of the standard Additionally, these technologies continue to evolve over time, requiring ongoing updates and adaptations to ensure comprehensive and effective diagnostics.

OTX is designed to be extendable, enabling seamless integration of new technologies used in the diagnostic process This flexibility allows for the incorporation of interfaces from various base technologies into the OTX platform, ensuring adaptability and future-proofing in medical diagnostics.

Test sequence development process support

Core_R09 – Embed non-machine readable content

In situations where diagnostic applications need to be expressed in OTX but the interfaces to certain devices, such as a nut runner, are unavailable, it is advantageous to define the core diagnostic logic within OTX Non-standardized device access can then be documented in plain language or pseudo code This approach allows OTX-compliant tools to import the diagnostic plan, highlighting sections requiring conversion into executable code by a diagnostics engineer.

OTX shall enable the expression of certain parts of a diagnostic application in a non-machine-readable format, ensuring these sections are clearly marked for easy identification This marking allows processes working with OTX files to accurately distinguish and handle the non-machine-readable content, enhancing clarity and interoperability within diagnostic workflows.

Core_R10 – High level test procedure

In a step-wise test procedure design, it may be necessary to specify procedures solely in prose form While high-level descriptions often include skeletal control structures, the detailed implementation aspects—such as loop conditions and specific service names—are typically unknown at the design stage This approach ensures flexibility in defining complex test procedures when full implementation details are yet to be determined.

Description: It shall be possible to describe test procedures at a high level

Core_R11 – Exchange high level test procedure

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

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

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

In test procedures, there are situations where comments are necessary to provide clarification or additional information These comments should be added as free-standing notes that are attached to specific parts of the command flow without being embedded within individual statements They serve as informational nodes, offering guidance without affecting the execution of the test, ensuring that the comments remain separate from the core flow for better readability and maintainability.

A key feature is the ability to add floating comments to a test procedure, enabling users to annotate specific statements, their flow, or sub-flows at any block depth These comments facilitate better understanding and documentation of complex testing processes, consistent with ISO 2012 standards.

Language feature details

OTX supports the declaration of constants, variables, and test procedure parameters, ensuring comprehensive and flexible test configurations Each declaration must include a name and a data type, with optional initialization values and descriptions to enhance clarity This functionality facilitates precise test setup and improves code readability and maintainability.

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

In certain situations, OTX authors need to ensure that the value of an identifier within a test procedure remains unchanged To achieve this, they can mark the identifier as a constant, guaranteeing its immutability throughout its lifetime Using constants helps maintain test integrity and prevents accidental modifications, enhancing reliability in test procedures.

Description: OTX shall support the declaration of constants Constants shall be set with the declaration

To accurately represent identifiers that can change their value during procedure execution, it is essential to designate certain identifiers as variables Variables allow their values to be modified throughout the procedure, enabling new data to be assigned as needed This flexibility is crucial for dynamic programming, ensuring that programs can update and manage data effectively during runtime Properly marking identifiers as variables aligns with best practices in programming and enhances code flexibility and maintainability.

Description: OTX shall support the declaration of variables

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

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

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

OTX supports the declaration of multiple two-way parameters, allowing seamless communication between the caller and the test procedure These two-way parameters are passed from the caller to the test procedure, enabling effective data exchange during testing Any modifications to the value of a two-way parameter can be assigned to variables within the caller's test sequence, enhancing flexibility and control.

NOTE This is the combination of input and output parameters

To enable seamless translation into multiple languages, OTX must be strongly typed, ensuring that each variable maintains its assigned data type throughout its entire lifecycle This strong typing guarantees data consistency and type safety, facilitating reliable internationalization By binding variables to specific data types for their duration, OTX enhances code stability and simplifies localization processes, making multilingual support more efficient and effective.

Description: OTX shall be a strong typed, static checked language

Rationale: To maintain a state during test procedure execution, information needs to be stored in memory

In typed programming languages, it is essential to specify the data type of stored information, such as strings, integers, or maps, to ensure proper handling and interpretation Declaring parameters with explicit data types allows for better code clarity and type safety Marking variables and constants with their corresponding data types facilitates accurate data management and reduces errors during program execution This approach emphasizes the importance of type declaration for reliable and maintainable code development.

Description: OTX shall support a well defined set of data types

Core_R24 – Extension mechanism for data types

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

Core_R25 – Raw memory data type

Description: OTX shall support a raw memory data type

Description: OTX shall support an integer data type

Core_R27 – Floating point data type

Description: OTX shall support a floating point data type

Description: OTX shall support a String data type

Description: OTX shall support a Boolean data type

OTX must support at least one container data type, allowing dynamic addition and removal of elements, with all elements sharing the same data type The container should enable access to its elements efficiently and support recursive declarations, such as containers of containers of integers, ensuring flexible and nested data structures Compliance with these specifications enhances data management capabilities within OTX systems.

OTX supports expressions that can be evaluated at runtime in a well-defined manner, ensuring consistent and reliable results Each expression evaluation produces exactly one return value of a specified data type, maintaining type safety Additionally, these expressions are designed to have no side-effects, meaning they do not alter any data from the test procedure except for assigning the evaluated value to a designated variable This ensures the integrity of the test process is preserved while enabling dynamic evaluation within the testing framework.

NOTE 1 In general, OTX expressions correspond to the term "function" in the mathematical sense

Core_R32 – Extension mechanism for expressions

Description: It shall be possible to extend the set of expressions by new expression types This shall happen by a well defined extension mechanism

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

Description: OTX shall support dereferencing expressions They shall allow reading data referenced by parameter-, variable- or constant-names

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

Most programming languages typically represent common mathematical functions, such as addition and multiplication, using operators like '+' and '*' However, in OTX, operators are not given special treatment; instead, they are described as functions It is then the responsibility of OTX tools to display these functions as operators when necessary, ensuring consistency and flexibility in how mathematical operations are represented.

Description: OTX shall support the basic functions:

 mathematical: addition, subtraction, multiplication, division, negation, modulo, power

 relations: equality, greater than, less than

To achieve Turing-Completeness in OTX, it is essential to incorporate a set of basic statements with diverse semantics, such as commands and control structures Statements, which are composed of distinct parts, enable the representation of high-level logic; for example, a loop statement includes a condition, typically a logical expression, and a sequence of commands to execute repeatedly Procedure call statements consist of the procedure’s name and a list of parameters, facilitating modular and reusable code execution.

Description: OTX shall support statements

Core_R38– Extension mechanism for statements

Description: It shall be possible to extend the set of statements by new statement types This shall happen by a well defined extension mechanism

Grouping a sequence of statements into blocks is essential for structuring code effectively Blocks can be nested within other blocks recursively, which is crucial for defining the bodies of loops, conditional branches, and other control structures Using blocks also enhances code readability and organization, making complex test procedures easier to understand and maintain Properly leveraging blocks improves both code clarity and overall process management.

Description: It shall be possible to define blocks of statements, recursively

Description: It shall be possible that blocks of statements can be used as statements themselves

Description: OTX shall support an assignment statement for assigning expression values to variables

OTX supports a call statement that enables the invocation of other OTX test procedures using a list of arguments matching the test procedure parameters This call is synchronous, ensuring that the caller waits for the called test procedure to complete before proceeding This functionality enhances test automation by allowing seamless and coordinated execution of multiple test procedures within the OTX framework.

Description: OTX shall support a branch statement, which allows reacting to different conditions

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

Description: OTX shall support a loop statement, which allows executing a block repetitively, as long as a defined condition is met

OTX supports the use of the continue statement to enhance loop control When used within a loop sub-sequence, it immediately stops the current block execution and proceeds to the next iteration, ensuring efficient loop management Outside of a loop context, the continue statement has no effect or meaning.

The OTX supports the use of a break statement, which, when used within a loop, terminates the loop's execution immediately Upon encountering a break, the subsequence stops, and execution continues after the broken loop Outside of loop contexts, the break statement has no effect This feature enhances control flow management within OTX automation, allowing for efficient interruption of loops when necessary.

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

When an exception occurs during test procedure execution, it is essential to have a mechanism to handle the error and continue the process in a controlled manner Implementing exception-monitored blocks within the procedure allows for precise detection and management of unexpected issues Additionally, defining dedicated blocks to handle specific exception types ensures robust and reliable test procedures, maintaining workflow integrity even when errors arise This approach enhances the resilience and efficiency of automated testing processes, ensuring smooth execution despite unforeseen exceptions.

Description: OTX shall support a statement for exception handling The statement shall allow reacting to different exceptions in different ways

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

Rationale: Enable/disable statements according to validity information

Boundaries

Core_B01 – No graphical procedure layout information

Description: It shall be possible to represent a procedure graphically without the need for supporting geometric information in the exchange format

NOTE Meta data may be used to transport such information It is up to the tool where the information is stored, if needed

Rationale: OTX is solely a data format

Description: No requirements on OTX performance exist

Core_B03 – No versioning & configuration management

Rationale: The versioning and configuration of OTX files is a process-dependent aspect of using OTX OTX shall not define or prescribe a process

Description: OTX shall not comprise data model aspects or techniques that relate to document versioning or configuration management of OTX files

Rationale: OTX is solely a data format

Description: OTX shall not be based on any technology that limits its application and distribution or distribution of files that are OTX-compliant by legal restrictions or licensing cost

Core_B05 – No explicit memory management

Description: OTX shall not give the possibility to handle memory management, control garbage collectors or other runtime system tasks which are out of the diagnostic scope

Core_B06 – No exception handling for environment fail

Description: OTX does not need to define exception handling for environment failure If the runtime environment has problems, test sequence execution shall stop

Description: OTX shall not allow variables with global scope

Core_B08 – No string translation utilities

Description: No string translation utilities are required in the core language The language is translation- agnostic

Core_B09 – No unit localization utilities

Description: No unit localization utilities are available in the core language The core language is unit- agnostic

5 Introduction to modelling in UML and XSD

General aspects

The Unified Modeling Language (UML, [ISO/IEC 19501:2005]) provides a formal and unambiguous way to define the OTX data model, enhancing clarity through graphical diagrams Its ability to create multiple views of different aspects of the overall data model offers significant advantages over direct modeling with XML Schema Definition Language (XSD, [W3C XSD:2004]) When combined with advanced UML-to-XSD generation tools, UML becomes a highly effective and powerful method for data modeling.

This section provides a brief introduction to UML, focusing only on aspects essential for understanding the OTX data model It emphasizes the use of class diagrams for OTX modeling and activity diagrams for describing behavioral aspects, highlighting the importance of specific XSD stereotypes to accurately facilitate UML model preparation for XSD generation.

Class diagrams

UML class diagrams provide a graphical way to depict a set of classes and their structural relationships, making complex system architectures easier to understand They feature two main elements: classes with properties that serve as blueprints for object instances, and associations that illustrate the various relationships between classes, such as inheritance or aggregation These diagrams are essential for visualizing object-oriented design and improving communication among development teams.

In the OTX data model, the primary UML modeling element is the class, which represents a group of similar objects Each class can be instantiated multiple times, with every instance referred to as an object This approach allows for efficient modeling of related entities within the system.

A class can encompass an unlimited number of named, typed attributes that define the properties of objects, along with methods that specify the actions these objects can perform Additionally, a class may include a stereotype, which indicates its specialized usage within a specific problem domain This structure enables flexible and targeted object-oriented programming, enhancing code clarity and reusability.

In UML, class properties are referred to as “attributes,” but in XSD, there is a clear distinction between “attribute” and “element” properties To avoid confusion, the term “attribute” will be used to specify class attributes within UML diagrams, while in the context of XSD, it will denote XSD type attributes.

In the OTX data model, classes can be designed as abstract, meaning they cannot be instantiated directly Abstract classes serve as a foundation to share common properties among their child classes, facilitating efficient inheritance relationships By utilizing abstract classes, developers can create a streamlined and organized data structure that promotes code reuse and consistency across related classes This approach enhances the modularity and scalability of the data model, aligning with best practices in object-oriented design.

Figure 1 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 displays the class name, such as "Contact," with abstract classes shown in italics to distinguish them A stereotype like "XSDcomplexType" indicates that this class is mapped to an XSD complex type within the corresponding XML schema, following the stereotypes used in the problem domain XSD.

The second field in the class definition details its attributes, such as "contactId," "name," and "age," with respective data types of string and integer, indicated directly after the labels with a colon Stereotypes like "XSDelement" and "XSDattribute" specify whether attributes like "name" and "age" are mapped as elements or XML attributes, ensuring accurate XML schema representation Understanding these attribute mappings is crucial for designing valid and interoperable XML schemas.

1) For the static OTX data model, methods are irrelevant and are not used

In an XML Schema Definition (XSD), elements such as `contactId` map to specific attributes within a class Each attribute is associated with cardinality information, indicated in square brackets (e.g., [0 1], [1 *], [2]), which specifies how many instances of that attribute can appear in an instance of the class If no cardinality is explicitly provided, a default of [1] is assumed, ensuring at least one occurrence Additionally, attributes may have default values set to define their initial state when omitted in an XML instance.

 There is no third field here – in others contexts it is used for methods which are irrelevant for the OTX data model

Figure 1 — UML representation of a class

By using inheritance relationships, classes can inherit attributes from other classes

In Figure 2, the class BusinessContact is derived from the Contact class, inheriting all its attributes This means BusinessContact includes all features of Contact plus additional specific attributes, such as the company string attribute Contact functions as the parent or super-class, while BusinessContact is the child or sub-class within the inheritance relationship Because the sub-class provides more detailed and specialized information, inheritance relationships are often referred to as “specializations,” highlighting how subclasses extend and refine their parent classes.

Figure 2 — UML representation of inheritance relationship

Inheritance relationships enable the construction of complex inheritance trees of any depth In such trees, a class inherits all attributes from its ancestors, including parent classes, grandparents, and beyond, by traversing the transitive closure of the inheritance hierarchy This hierarchical structure facilitates organized and efficient code reuse, making inheritance a fundamental concept in object-oriented programming.

Mapping to XSD must be approached with understanding that XSD only supports single inheritance, meaning UML models with classes having multiple direct superclasses cannot be accurately represented Despite this limitation, the process of converting UML models to XSD remains straightforward in most cases.

UML diagrams often depict specific aspects or parts of the overall data model, which means some superclass relationships may not be explicitly shown To represent inheritance when a superclass is hidden, a special notation is used, as demonstrated in Figure 3 In this notation, an additional property is displayed to the upper right of the class, such as BusinessContact, indicating its superclass Contact This approach ensures clarity while maintaining a streamlined diagram.

Figure 3 — Alternative UML representation of inheritance relationship

In addition to inheritance relationships, classes can also be connected through aggregation relationships Aggregation occurs when an object of one class is contained within an object of another class, representing a whole-part association This type of relationship is essential for modeling how objects collaborate and share ownership within a system Understanding aggregation is important for designing flexible and maintainable object-oriented software.

An aggregation relationship in the OTX data model is depicted as a line with an unfilled diamond at the containing class's end The relationship end at the contained class typically includes a role name, which helps differentiate objects of the same class within the context of the association Additionally, this role end carries cardinality information, such as "0 1," "1 *," or "2," which specifies the number of instances of the associated class that can be contained within an instance of the containing class.

Figure 4 — UML representation of aggregation relationship

Figure 4 illustrates an example of two classes with aggregation relationships, where a Contact can have two Address objects: one designated as homeAddress and the other as workAddress The cardinalities are "1" for homeAddress and "0 1" for workAddress, meaning a Contact must have exactly one home address and may optionally have a work address This design emphasizes that each Contact is associated with a single, mandatory home address and zero or one work address, clarifying the relationship's semantics.

Mapping to the XML Schema Definition language (XSD)

The OTX target data model is defined using an XML Schema Definition (XSD), which facilitates standardization and data validation This article provides a brief overview of how UML model elements are mapped onto XSD language features, helping readers understand the relationship between UML diagrams and their XML representations While not exhaustive, this summary simplifies the comprehension of OTX examples presented throughout the document, making it easier to implement and interpret the OTX data models effectively.

In the XSD data model implementation, the concept of composition—where an object can only be contained within a single parent—is not applicable This is because XML documents allow element snippets to be repositioned or transferred between different documents, making such restrictions impractical Consequently, the OTX data model employs only aggregation relationships, enabling flexible and reusable data structures.

The article outlines the fundamental rules for mapping, complemented by a UML example that illustrates the concepts clearly It also provides the corresponding XSD output to demonstrate the schema structure Additionally, a valid XML document aligned with the XSD is included to showcase proper implementation These guidelines and examples offer a comprehensive understanding of effective mapping practices, ensuring accurate schema design and data validation.

The following mapping rules apply:

In XML Schema Definition (XSD), a class is mapped to a complex type with sequence content by default, emphasizing that the order of elements within the sequence is significant When the class's stereotype is not "XSD complexType," the same mapping principles are applied, with modifications explained where necessary This ensures that the structure and data integrity of the XML are maintained according to the specified schema rules.

Attributes in a UML class are mapped onto attributes of the XSD complex type when the "XSDattribute" stereotype is applied to the UML attribute The cardinality specified for the attribute determines its XSD usage, with a cardinality of [1] indicating use="required" and [0 1] indicating use="optional." If no cardinality is specified, the default setting of use="optional" is assumed, ensuring proper validation and data integrity in XML schemas.

When the "XSDelement" stereotype is defined, class attributes are mapped onto sub-elements of the XSD complex type The attribute's cardinality is reflected in the sub-element's properties, using minOccurs and maxOccurs attributes For example, a cardinality of [1 *] translates to minOccurs="1" and maxOccurs="unbounded." If no cardinality is specified, the default settings of minOccurs="1" and maxOccurs="1" are applied, ensuring proper schema validation.

 Classes connected to another class via an aggregation relationship are mapped onto sub elements in the corresponding XSD complex type of the containing class by the following rules: The role names at the aggregation (contained end) are mapped onto the sub element name property The name of a contained class is the type property of the corresponding sub element The cardinality of an aggregation (contained end) is mapped to the cardinality of the sub element (XSD element properties minOccurs, maxOccurs)

 An inheritance relationship between a super-class Super and a child class Child is mapped onto the

The XSD extension base property of the complex type Child, such as base="Super," indicates inheritance in XML Schema However, XSD supports only single inheritance, making it impossible to correctly map multiple inheritance (more than one super-class) to XSD This limitation affects how complex type hierarchies are represented in XML Schema definitions.

 An abstract marked class is mapped to a XSD complex type with the property abstract="true"

Throughout the document some other stereotypes are used that have not been explained within this section These include the following:

 ôXSDsequenceằ, ôXSDchoiceằ, ôXSDallằ, these are stereotypes for classes representing an XSD sequence, choice or all content-model separately or outside of a XSD complex type;

 ôXSDsimpleTypeằ to make a class represent a simple content type, e.g classes derived from string, integer, etc.;

 ôXSDtopLevelElementằ, this makes a class represent a document root element (Only used once in the OTX data model for the element definition itself

Consider the example UML data model "Directory" depicted in Figure 5 The example model is designed for describing the structure of XML documents representing a contact-directory

Figure 5 — Mapping example: "Directory" UML model

The translation of the UML to XML happens like this:

The foundational element of each document should be the tag, serving as the top-level container This element is based on the Directory class, allowing an unlimited number of elements to be nested within it Properly structuring your XML with a root and multiple entries ensures compliance with schema standards and enhances data organization.

 The elements are of Contact type, so each of them has an attribute contactId and the elements , (optional), and (optional)

 Simple type elements like (of xsd:string type) or (of xsd:integer type) are described implicitly within the aggregating Contact class

 Features that are complex themselves, like the (of Address type), are described explicitly by an own Address class, which is connected to Contact by an aggregation relation 3)

 The elements and have simple string sub elements and

This modeling approach serves as a guideline rather than a strict requirement, as alternative methods—such as adding "homeAddress" and "workAddress" attributes directly to the "Contact" class—could achieve the same XSD/XML results However, explicitly modeling containment relations with aggregation diagrams improves clarity and overview, especially in larger UML diagrams.

In UML, countries are typically represented as simple strings; however, the model in this article demonstrates an alternative approach by illustrating inheritance relationships (see Figure 3) This example showcases how countries can be modeled to reflect inheritance hierarchies, providing a clearer understanding of UML's capabilities beyond basic string representation.

An XSD model can be generated from a UML model following specific mapping rules, as demonstrated in the provided XSD source code This resulting XSD enables validation of XML documents, such as contact directories, ensuring they conform to the defined contact-directory schema.

EXAMPLE Schema "directory.xsd" derived from the "Directory" UML model

In XML Schema Definition (XSD), elements such as Directory, Contact, BusinessContact, and Address are organized within tags, ensuring a specific order of elements Aside from , XSD also introduces two additional complex content types: and , which allow for different element arrangements In UML diagrams, the default content type generated by the schema tools is , and only in specific cases where or are applicable will this be explicitly indicated in the specifications Understanding these content types is crucial for designing flexible XML schemas that accurately model data structures.

An XML instance document according to the XSD is given below

EXAMPLE XML document "contacts.xml" showing some directory entries according to the "directory.xsd" schema

The xsi:type attribute is crucial when an element's underlying complex type can vary among a set of child types, as it specifies the exact type used For instance, in the example XML, a Contact element is cast to the child class BusinessContact using this attribute Proper use of xsi:type ensures accurate data representation and compatibility in XML documents.

The OTX data model utilizes the xsi:type attribute to facilitate future extensions, especially when the specific names of these extensions are unknown during the initial core data model development This approach ensures flexibility and adaptability, allowing the data model to accommodate additional data types seamlessly as extensions are introduced Implementing xsi:type supports scalable and extensible data modeling, making it a crucial feature for evolving systems.

General

OTX represents a high-level domain-specific language which is especially designed for graphical notation and editing

The syntax of the language is established through the UML data model and its corresponding XML schema, ensuring clear structural guidelines The semantics, or meaning, are defined within this document, providing comprehensive explanations of how the language functions This overview also outlines the key principles that guide OTX, fostering consistency and clarity in its application.

XML format

Using XML in combination with XSD allows OTX to leverage the full power of the W3C XML recommendation [W3C XML:2008], benefiting from extensive off-the-shelf solutions and widespread global adoption XML is the preferred file format due to its flexibility, interoperability, and robust validation capabilities, making it ideal for standards compliance and seamless data exchange Embracing XML and XSD ensures that OTX can efficiently integrate with existing systems and future-proof its data handling processes.

 XML is designed to represent hierarchically structured information, which applies especially for test sequences

 The basic XML rules for well-formedness eliminate the need for defining an own set of such basic grammar rules specific for OTX

Checking XML documents for well-formedness is a straightforward task with numerous off-the-shelf solutions available, eliminating the need to develop custom well-formedness checkers specifically for OTX.

 By modelling the detail correlations of the OTX grammar by using XSD, validity checking can be done by off-the-shelf solutions

Off-the-shelf XML parser frameworks, many schema-driven, facilitate the interpretation of OTX documents across authoring, checker, and runtime applications These tools streamline development by eliminating the need for implementing specialized low-level OTX parsers, ensuring efficient and accurate processing of OTX files.

Imperative and structured programming paradigm

OTX follows the paradigm of imperative, structured programming:

 Imperative: OTX procedures define sequences of commands for the computer to perform

OTX enforces structured programming by eliminating explicit jumps, instead relying on branches, loops, exception handlers, return, continue, break, throw statements, and procedure calls to control flow implicitly This approach ensures that all jumps are well-defined and managed in a controlled manner Consequently, OTX incorporates a clear block structure, similar to other structured programming languages, to promote code readability and maintainability.

Graphical authoring of OTX sequences

OTX revolutionizes sequence editing by utilizing graphical authoring tools instead of traditional text-based source code editors, reducing errors and simplifying the development process Its reliance on XML as the file format, despite concerns over verbosity, allows complex code management to occur seamlessly in the background, insulating the user from technical intricacies The OTX format supports advanced features suited for graphical authoring, such as explicit specification compartments, realization sections, and floating comments that can link to multiple statements—features often overlooked by source-code driven languages.

Specification/Realisation concept

The OTX format offers explicit support for a three-stage development of test sequences

The specification stage involves describing a test sequence at a high-level, human-readable prose format, making it ideal for early development phases when detailed executable steps are not yet defined This stage enables the creation of an overall sequence logic without requiring fully detailed instructions that a runtime interpreter can execute By establishing the test sequence at this level, it provides a foundation that can be progressively refined and broken down in subsequent stages, streamlining the development process.

OTX supports intermediate stage test sequences, enabling testing during the transition from specification to realization These sequences include fully executable parts and segments still in the specification stage, allowing seamless progress Sequence authors utilize human-readable specification information to implement parts by adding realization counterparts, ensuring the sequence remains valid, saveable, and exchangeable at any point in the development process.

During the Realisation stage, the sequence is fully executable with no remaining specification-only parts, although specification components may still exist alongside their corresponding realisation This coexistence signifies an “executable specification,” indicating that the sequence is now ready for implementation without pending specifications.

Modular OTX extension concept and OTX-based runtime architecture

The OTX data model is organized into a core language and various functional extensions, providing syntactical definitions for test sequences and a functional description of expected behavior However, the standard does not specify the implementation of runtime behavior, allowing flexibility for different use cases For instance, defining specific HMI library implementations is impractical within the OTX standard, as HMI requirements and backend frameworks vary across test environments.

Figure 6 — OTX-based runtime architecture

Figure 6 provides an overview of the standard extensions outlined in [ISO 13209-3] The OTX Core data model primarily defines extension interfaces as hooks for various extensions, ensuring seamless integration Importantly, the Core remains fully stand-alone, offering a robust foundation independent of the extensions.

Separating the OTX structure (intent) from its runtime implementation (execution) enables OTX to serve as a standardized test sequence exchange format across entire organizations or even between different companies The architecture of an OTX runtime diagnostic application, as shown in Figure 6, highlights how the OTX subsystem interprets sequences built on core data model constructs and extension interfaces such as HMI, environment-specific modules, vehicle communication systems, and proprietary functionalities.

The runtime system effectively maps OTX extension actions, such as a ‘ChoiceDialog’, to appropriate interface components based on the application context For instance, in an after-sales diagnostic application, the ‘ChoiceDialog’ is represented as a Java Swing dialog that enables interaction with the workshop mechanic Conversely, when executed on a manufacturing station, the same OTX sequence is mapped to a state machine linked to manufacturing line measurement equipment, ensuring seamless operation across different environments.

Context concept

Diagnostic test sequences require a technique for getting access to a diversity of contextual information Such information can be e.g vehicle related, diagnostic application related, user related or application area related

A few instances of contextual information are mentioned here:

 Vehicle related: E.g data about the currently diagnosed vehicle's model, vendor, identification number, engine-type or other identification data concerning the physical and electronical vehicle configuration

 Diagnostic application related: E.g application version, name, used vehicle communication interface type or version or also diverse settings of the application

 User related: E.g login name, idle time, user access rights, etc

 Application area related: e.g information about the location where the test sequences are applied, to make the difference e.g between manufacturing, engineering or workshop appliance

In general, contextual information may be required by heterogeneous subsystems of a diagnostic application Concerning OTX, only the provision of contextual information to the OTX subsystem is considered

OTX does not specify a fixed list of context items that every conforming application must provide Instead, it leaves the method of identifying context items—referred to as identification routines—up to the application developer OTX's role is to define how context-dependent documents declare their required context items, ensuring clarity and interoperability It is then the responsibility of the diagnostic application to link each declared context item to the appropriate identification routines that supply the specific data.

Figure 7 illustrates a conceptual mapping between context declarations in an OTX document and the identification routines of a diagnostic application The ISO 13209 standard does not specify how this mapping should be implemented, allowing diagnostic applications to adopt suitable mechanisms for their needs Identification routines can be developed in any programming language appropriate for the specific diagnostic application, including using OTX itself Additionally, diagnostic applications should provide a flexible mechanism for OTX authors to incorporate context-dependent OTX documents by adjusting mappings and adding new identification routines.

In OTX test sequences, contextual information is considered static and cannot be directly set within the test Allowing direct setting would enable a test sequence to inaccurately specify vehicle details, such as assigning "Diesel" engine type to a gasoline vehicle Therefore, OTX test sequences are designed only to read contextual information indirectly through the identification routines provided by the diagnostic application, ensuring accurate and reliable diagnostics.

Figure 7 — Mapping context declarations to identification routines

The OTX context concept has several advantages:

 Transparency: Working with context data is almost similar to working with global constants for OTX authors

 Compatibility: Integrating OTX into existing diagnostic applications does not require a change of the original context identification/management strategy of the application or the diagnostic session management, etc

Exchangeability in OTX is ensured by explicitly declaring each context item in a well-defined manner, facilitating seamless integration across different diagnostic applications By adjusting the mapping between context declarations and identification routines—or implementing new routines—an OTX sequence from a foreign diagnostic system can be efficiently reused This approach enables context-dependent OTX documents to be easily adapted and exchanged, promoting interoperability and flexibility in diagnostic workflows.

"docked" to heterogeneous diagnostic applications

Effective cooperation in OTX test sequence development is achieved by establishing an agreed-upon OTX file or a set of OTX files that declare commonly used context data This shared framework enhances collaboration between multiple parties, ensuring consistency and efficiency in developing OTX test sequences.

 Simulation: Various context situations can be simulated by e.g feeding simulated data to identification routines

 Aside from the above topics, the context concept is crucial for the validities concept which is described in the following.

Validities concept

OTX introduces the concept of validities, enabling the configuration of test sequences tailored to dynamic runtime contexts These test sequences adapt their behavior based on the current environment, allowing for flexible and scenario-specific testing OTX authors can create versatile, generic test sequences that automatically adjust during execution, ensuring accurate testing across various scenarios and improving testing efficiency.

To effectively control test sequences, an OTX author must define validities, which include Boolean context items, Boolean constants, or compound logical expressions known as validity terms that combine various context items and global constants These validities enable the author to mark specific parts of the test sequence as valid only when certain conditions are true at runtime By doing so, invalid sections are skipped during execution, allowing for dynamic activation and deactivation of sequence parts based on context Utilizing validities enhances test sequence flexibility, making runtime testing more efficient and adaptive.

Figure 8 — Validities concept, example of use

The example test sequence in Figure 8 illustrates a process that does not utilize validities, focusing instead on specific actions In debug mode, the diagnostic application's runtime system logs a message for troubleshooting purposes Additionally, the sequence involves measuring the vehicle's battery voltage, with measurement methods varying based on the vehicle type—such as vintage cars, modern vehicles, or non-motorized modes like bicycles This tailored approach ensures accurate diagnostics across different vehicle categories.

1) Vintage model: The voltage has to be measured and entered into the system manually

2) Modern model: The voltage can be queried automatically (by using a diagnostic service)

This section addresses vehicles that lack batteries, making measurements impossible If the voltage measurement is too low, a "voltage low" alert will be displayed; otherwise, the system will show "voltage OK," ensuring clear communication of the vehicle’s electrical status.

The test sequence in Figure 8 demonstrates context-dependent decision-making by applying validity conditions at each decision point For example, the "WriteLogMessage" step executes only when the "DEBUG_MODE" context item is true, ensuring logging occurs solely during debugging Voltage measurement varies based on vehicle model: one approach is valid only for "isVintageModel," another only for "isModernModel," allowing tailored actions for different vehicle types If none of these validity conditions are met, no action is performed, indicating an unsupported vehicle model Since the voltage value is dynamic and only available at runtime, it is not preconfigured and therefore does not utilize validity conditions, emphasizing real-time data handling in the test sequence.

The context items "MODEL" and "DEBUG_MODE", and the validity terms "isModernModel" and

"isVintageModel" can be defined e.g in a central document and be reused by all OTX authors who want to configure their test sequences towards the same context situations

The advantages of this approach are obvious:

 A distinction is drawn between decisions based on static context data (e.g enumerations of expected context values known at authoring time) and dynamic data (which is computed at runtime)

Validity information manages the flow implicitly by considering context rather than relying on explicit dynamic branch conditions This approach results in a more compact representation, making the "pure" test sequence logic clearer and more apparent.

Storing sets of commonly used validities centrally streamlines the creation of test sequences by reducing redundancy, as authors can easily reuse preconfigured validities This approach enhances maintainability and ensures consistency across testing processes, making it a highly efficient solution for managing validities in test development.

The OTX authoring system enables users to configure specific contextual scenarios within a simulated environment, allowing for precise testing and validation By filtering out invalid steps and irrelevant data, it produces compact, streamlined views of test sequences tailored to particular contexts This functionality enhances testing efficiency and accuracy, ensuring that only relevant test cases are executed and analyzed.

 Filtered test sequences may be extracted and/or exported This results in test sequences which are tailored for a specific context

 Enables the signature concept which is described later in this document

Figure 9 illustrates the filtering of test sequences based on simulated contexts, highlighting the impact of debug mode settings When debug mode is enabled in the left context, the model represents a vintage car, emphasizing traditional features Conversely, in the right context where debug mode is disabled, the model depicts a modern car, reflecting recent technological advancements These results demonstrate how context and debug configurations influence model representation, providing valuable insights for optimizing image filtering processes in automotive AI applications.

In real-world test sequences, the concept of validity plays a crucial role in configuring and optimizing processes across various applications It can be used to tailor sequences for different vehicle types, ECU variants, and vehicle configuration codes, ensuring precise testing and calibration Additionally, validity is essential for adapting test procedures to different operating systems and application areas such as repair workshops and assembly lines, enhancing efficiency and accuracy in automotive testing and manufacturing environments.

Especially concerning graphical OTX authoring environments, the validity concept supports the compact and at the same time flexible representation of test sequences

Signature concept

The OTX signature concept is designed to support dynamic linking:

A signature defines a prototype procedure with a name, parameter declarations, and a prose specification, but without implementation content Procedures that implement this signature must have the same parameters and develop a program that fulfills the specified task Essentially, a signature establishes an interface that implementing procedures must follow, enabling indirect calls based on the signature This approach allows callers to invoke procedures using only parameter and specification details, without needing to know the underlying implementation—embodying the principle of "I want you to accomplish this, but I don't care how you do it."

Signatures are ideal for scenarios where a task must be performed differently based on the context, even if the core task remains the same They enable dynamic selection of the task variant at runtime once the context is known, offering flexibility during execution This approach leaves the specific implementation open during authoring, allowing the creation of generic test sequences that do not require modification as long as the used interfaces or signatures remain unchanged.

The concept of signatures is closely related to validity, illustrating how generic procedures adapt to different contexts For example, the "Voltage_Test" procedure needs to read a vehicle's battery voltage, but the method varies between vehicle types In vintage models, a mechanic must manually measure the voltage, while modern vehicles use electronic test equipment for automatic readings Since the author of "Voltage_Test" doesn't specify the measurement method, he delegates this task to colleagues who implement the signature "ReadBatteryVoltage." This results in two procedures: "Manual_ReadVoltage" for vintage models and an automated process for modern vehicles, demonstrating how signatures enable flexible, context-dependent method implementation.

"Auto_ReadVoltage" which works for the modern model Both procedures obey to the signature, they do the same job (returning the voltage) by different means

At runtime, the procedure call is redirected dynamically to the implementing procedure which is valid with respect to the current context (validities "isVintageModel" or "isModernModel")

The key advantage of this approach is its stability, as the generic procedure remains unchanged even when new context situations arise, such as the introduction of a high-voltage battery requiring an additional voltage reading variant This ensures enhanced maintainability and long-term availability of generic test sequences Additionally, the signature concept facilitates collaboration among multiple parties by providing clear and formal interfaces between distributed development teams, supporting modular and scalable test sequence development.

In dynamic signature concepts, the specific procedure to be executed is determined at runtime, requiring special arrangements within the OTX runtime application To handle this, an indirection via the signature must be resolved by implementing a mapping that allows for the lookup of a valid procedure corresponding to a given signature Detailed information about this process is provided in section 7.14.5, which covers the ProcedureCall action, ensuring proper execution of dynamically determined procedures.

7 OTX Core data model specification

General

The following represents the full data model specification of the OTX Core, data model version "1.0.0"

Each OTX feature is accompanied by comprehensive syntax and semantic definitions The syntax definition precisely specifies the exact XML structure required for the feature, ensuring correct implementation Conversely, the semantics definition clarifies how the feature should be interpreted by OTX runtime systems and graphical authoring tools, facilitating consistent understanding and functionality across platforms.

The specification provides a hierarchical description of the data model, beginning from the root element and progressing downward through the document structure It emphasizes clarity in representing the hierarchical relationships from top to bottom Commonly used features across multiple parts of the structure are detailed in section 7.16, ensuring consistency and comprehensive understanding of shared elements within the model.

The OTX Core data model specification is accompanied by additional normative information given in the annexes:

 Annex A specifies the OTX data types

 Annex B specifies the runtime behaviour concerning scope and memory allocation of OTX constants and variables

Annex C provides a comprehensive list of all checker rules necessary to validate OTX documents These rules address constraints that cannot be enforced through XSD validation alone To ensure full compliance, additional checker applications are required to verify these specific constraints, enhancing the overall validation process.

Annex D outlines the extensibility of the OTX Core data model, allowing for the addition of new features through OTX extensions These extensions enhance the format's capabilities while adhering to well-defined extension rules Following these guidelines ensures the development of correct and compatible OTX extensions, facilitating seamless integration and scalability within the threat intelligence framework.

 Annex E describes the special schema annotations for exceptions

 Annex F contains the XML Schema definition for the OTX standard.

High-level overview of the OTX Core data model

Figure 11 provides a high-level overview of the OTX Core data model, illustrating the essential structure of OTX documents by highlighting a subset of types, attributes, and relationships Although it presents only a simplified view, it effectively conveys the core concepts of the overall model Detailed explanations are provided in later sections, but this overview offers a quick understanding of the foundational elements of the OTX Core data model.

OTX documents begin with header information, including the document name, meta-data, imports, and global scope details such as global declarations and validities These are followed by a list of OTX procedures and their corresponding procedure signatures, providing a comprehensive structure for the document Note that not all properties are depicted in the diagram for brevity.

Validities are named Boolean terms which can be used for configuring context-dependant procedure behaviour

A procedure consists of a procedure name, a specification, and a realization section that defines the procedure's concept as outlined in section 6.5 The realization section includes parameter and local variable declarations, along with a flow of nodes that represent the procedure's logic Additionally, it may incorporate comments linked to specific points within the flow to enhance understanding and maintainability.

In a procedure parameters declaration block, in-, out-, and inout-parameters can be defined, while local variables and constants are declared separately in the declarations block Each declaration—whether parameter, constant, or variable—is assigned a data type selected from a set of OTX data types Semantically, all declared identifiers are accessible across all nodes within the procedure flow, ensuring consistent visibility and data management throughout the process.

The core of every procedure is its flow element, which comprises a list of nodes executed sequentially These nodes include simple types, such as Action, Return, Continue, Break, Throw, and TerminateLanes, as well as compound nodes like Group, Loop, Branch, Parallel, MutexGroup, and Handler, which can embed other flows OTX flows are similar to blocks used in many programming languages, providing a structured approach to process control.

Figure 11 — High-level overview of the OTX Core data model

Tiêu đề	Road Vehicles — Open Test Sequence Exchange Format (OTX) — Part 2: Core Data Model Specification And Requirements
Trường học	International Organization for Standardization
Chuyên ngành	Standardization
Thể loại	Tiêu chuẩn
Năm xuất bản	2012
Thành phố	Geneva

Định dạng
Số trang	212
Dung lượng	5,17 MB