XML Format

Using XML in combination with XSD enables OTX to benefit from the whole strength of the W3C XML recommendation, with its great number of off-the-shelf solutions, its world-wide acceptance and adoption. XML is the file format of choice also because:

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 well-defined task for which a great many number of solutions exist off-the-shelf. Thus, there is no need to implement well-formedness-checkers specifically for OTX.
By modeling the detail correlations of the OTX grammar by using XSD, validity checking can be done by off-the-shelf solutions.
The interpretation of OTX documents in authoring-, checker- and runtime-applications is assisted by off-the-shelf XML parser frameworks; many of them are schema-driven. This avoids implementations of specific low-level OTX parsers.

Exchangeability and Standard Compliance

To ensure the exchangeability and standard compliance OTX documents must be

Valid against the OTX schema (syntax) and the checker rules (semantic)
Complete in terms of the fact that the entire test logic is available in OTX
Target system independent, which means that there must be no dependencies on external systems.

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.
Structured: There are no explicit jumps allowed in OTX. Instead, branches, loops, exception handlers, return, continue, break and throw statements as well as procedure calls define jumps implicitly and in a controlled manner. Therefore, OTX also defines a block structure, as typically found in all languages that follow the structured programming paradigm.

Graphical Authoring

In contrast to other programming languages where programs are usually edited in text-based source code editors, OTX aims at sequence editing using graphical authoring tools. This keeps away the cumbersome and error-prone line-by-line source code editing work from the sequence author, a fact that allows XML to be the preferred file format for OTX – even though XML is often denounced to be too verbose. The complexity of managing the OTX XML code will happen in the background, hidden from the sequence author. On the other hand, the OTX format supports features needed by graphical authoring tools, which are broadly disregarded by source-code edited languages, e.g. explicit specification and realisation compartments in statements, or floating comments that can link to more than one statement, just to mention a few.

Note: A proper OTX Development Environment gives both opportunities to edit OTX code: Graphical designer and text-based code editor. Because both approaches have advantages and disadvantages. EMOTIVE has developed a grammar to express the complete OTX data model in ASCII code called OTL (Open Test Language). Inside the OTL editor, OTX can be edited like in a normal code editor e.g. for Java or C#. The OTL editor is synchronized with the graphical designer so that both approaches can be used without limitations.

Specification/Realisation Concept

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

Specification stage: A test sequence may be described at specification level only. This is helpful for early stages in the test sequence development process, when not all of the details for creating an executable test sequence are known. The specification stage allows the development of test sequences at a prose level, which is human readable, but not fully executable – this means, the overall sequence logic may already be there, but single steps in the sequence are filled by prose only, so a runtime interpreter cannot make use out of it. However, starting from this stage, the test sequence can be continuously broken down by the following stages.
Intermediate stage: OTX also allows intermediate stage test sequences, which occur while transforming a specification stage test sequence towards a realisation stage sequence. Such an intermediate stage test sequence may contain parts that are already fully executable, whereas other parts are still at specification stage. The sequence author uses the human readable information from the specification stage parts and implements those parts following the specification instructions by adding realisation counterparts. At any step in this process, the sequence is validly save-able and exchangeable.
Realisation stage: At this stage, there are no more specification-only parts in the sequence. The sequence is then fully executable. Note that even at this stage, specification parts of the sequence may still be contained, but not without their corresponding realisation. With other words, this coexistence represents an "**Executable specification**".

Modular OTX Extension Concept and OTX-based Runtime Architecture

The OTX data model is structured into a language core and various functional extensions. It is important to note that the OTX Core, as well as the extensions defined by this part of ISO 13209, does only provide syntactical definitions for the elements of test sequences and a functional description of the expected behaviour. The implementation of the runtime behaviour itself is not part of the OTX standard. This is necessary to allow for the needed freedom when implementing OTX runtime components to fit specific use cases. For example, it would be impractical for the OTX standard to define the specific implementation of an HMI library, as the requirements and backend frameworks for HMI functionality will differ for each test environment.

The picture comprises an overview of the standard extensions specified in part 3 of the standard (ISO 13209-3). The following specification of the OTX Core data model touches the extensions only by defining extension interfaces which serve as hooks for the respective extensions. Otherwise, the Core is fully stand-alone.

This separation of OTX structure (intent) and runtime implementation (execution) will allow for OTX to be used as a test sequence exchange format that can be deployed throughout an entire organization, or even across company boundaries. The picture illustrates the architecture of an OTX runtime tester application. The OTX Subsystem that is part of the tester application is interpreting OTX sequences which make use of OTX core data model constructs, as well as of various extension interfaces (HMI, Environment-specifics, vehicle communications and other proprietary functionality).

The actual runtime system implementation knows how to map e.g. an HMI extension action within an OTX sequence to the GUI framework that is used by the tester application. For example, an after-sales application might map an OTX "ChoiceDialog" construct to a Java Swing dialog entity that allows interaction with the workshop mechanic. The same OTX sequence could also be executed on a manufacturing station, where the tester application implementation would map the "ChoiceDialog" construct to a state machine connected to manufacturing line measurement equipment instead of a GUI interface.

Note: The modular runtime architecture approach is completely covered into the so called OTX Mapping.

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 prescribe a set of context items which must be supplied by every conforming application. Also, OTX does not make any assumptions or rules about the method by which a diagnostic application should identify particular context items (such methods are henceforth called identification routines). Instead, OTX only specifies how context-dependent OTX documents must declare the particular context items which they require. It is the task of the diagnostic application to connect each context declaration of an OTX document to the specific identification routines yielding the respective context item.

The picture shows a conceptional example of a mapping between context declarations defined by an OTX document and identification routines of a diagnostic application. The implementation of the mapping itself is not specified by this part of ISO 13209. Diagnostic applications are free to implement an appropriate mapping mechanism, see OTX Mapping. Furthermore, the identification routines can be implemented in any programming language appropriate for the respective diagnostic applications. Therefore it is also possible to use OTX again for implementing identification routines. Diagnostic applications should also provide a mechanism which allows for OTX authors to integrate context-dependent OTX documents into the application by adjusting the mapping and adding new identification routines.

From the perspective of an OTX test sequence, contextual information is treated like static information. Contextual information can not simply be set by an OTX test sequence – if this would be possible, a test sequence would be able to set e.g. the engine-type information of the currently diagnosed vehicle to "Diesel", despite the fact that the concrete vehicle is gasoline driven. Consequently, OTX test sequences is only be able to read contextual information by indirectly utilising the identification routines provided by the diagnostic application.

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: Since OTX documents declare each context item they require explicitly and in a well-defined place, using an OTX sequence originating from a foreign diagnostic application only requires an adjustment of the mapping between context declarations and identification routines (and possibly the implementation of new identification routines). In this way a context-dependent OTX document can be "docked" to heterogeneous diagnostic applications.
Cooperation: By agreeing upon an OTX-file or a set of OTX-files declaring commonly used context data, two or more parties can improve their cooperation concerning OTX test sequence development.
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

Based on the context concept described above, OTX offers the validities concept which allows for configuring test sequences for varying runtime contexts. The behaviour of such a configured test sequence changes according to the context it is running in. An OTX author can use this to configure and prepare generic purpose test sequences for different scenarios. At runtime, the test sequence adapts its behaviour according to the configuration.

To achieve this ability, an OTX author first needs to define validities: A validity is either a Boolean context item, a Boolean constant or a compound logical expression (called validity term) which combines different context items and/or global constants. The OTX author may use the declared validities for marking parts of his test sequence to be valid only if a connected validity is true at runtime. An invalid part will not be executed at runtime – like this, the author can activate and deactivate parts of the sequence in a context-driven manner.

Consider the example test sequence to the left of picture above. This sequence does not use validities. It is designed to do the following:

If the diagnostic application's runtime system is in debug mode, it shall write a log message.
The battery voltage of a vehicle shall be measured. According to the type of vehicle under test (a vintage model, a modern model or neither of these, e.g. a bicycle), this has to happen in different ways:
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).
3. It is some other type of vehicle with no battery; nothing can be measured.
If the measured voltage is too low, a message "voltage low" shall be shown, otherwise "voltage OK".

The test sequence to the right of picture above does (superficially) the same, but it uses validities in every place where context-dependent decisions are taken:

The step "WriteLogMessage" is marked to be valid for "DEBUG_MODE" only. It will be inactive if the Boolean value of the context item "DEBUG_MODE" is false.
The step for measuring the voltage comes in two different flavours: One is valid only for "isVintageModel", the other only for "isModernModel". If none is valid, no action is specified (there is some other type of vehicle). The validities "isVintageModel" and "isModernModel" are validity terms analyzing the current value of the "MODEL" context item.
The voltage value is dynamic: It is neither predictable at authoring time nor depending on the context. It is only known at runtime. It is not a configuration. That is why validities are not used here.

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 controls the flow implicitly regarding context, not explicitly by normal dynamic branch conditions. This fact is also reflected in the more compact way of representation, the "pure" test sequence logic becomes more apparent.
Sets of commonly used validities can be stored separately, in a central place. This avoids a lot of redundancy, since authors can reuse preconfigured validities for their test sequences. This also improves maintainability.
Filtering: OTX authoring system may allow the author to configure certain context situations in a simulated environment. This produces very compact views of test sequences for a given context (mask steps that are not valid).
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.

Signature Concept

The OTX signature concept is designed to support dynamic linking:

The concept allows for defining prototype procedures called signatures. A signature is like a procedure but without program content (implementation); it consists only of a name, a set of parameter declarations and a prose specification. Procedures that implement a signature contain the same set of parameters like the signature and they have to implement a program that accomplishes the task that was specified in prose in the signature. Hence, a signature defines an interface which implementing procedures have to obey. If this precondition is met, implementing procedures can be called indirectly via a signature – the caller only needs to know the parameters and the specification of the signature, the caller does not need to know implementation details which are hidden in the implementing procedures (in simple words: "I want you to accomplish this, but I don't care how you accomplish it").

Signatures are especially suited for cases where a task has to be carried out differently depending on the context, but superficially it is still the same task. The variant in which the task is carried out is chosen dynamically at runtime, when the context becomes known. At authoring time, this is left open. This allows writing generic test sequences that do not need to be changed as long as used interfaces (the called signatures) do not change.

The signature concept is closely linked to the validities concept (see above). Consider the example in picture. The generic procedure "Voltage_Test" needs to read the current battery voltage of a vehicle. In the example, there are two kinds of vehicles: A vintage model where the voltage needs to be measured manually by a mechanic and a modern model where the voltage can be read automatically by electronic test equipment. Since the author of the generic procedure does not know how to actually measure the voltage in the different cases, he leaves the work up to colleagues who implement the signature "ReadBatteryVoltage" that he provides. The output are two procedures, "Manual_ReadVoltage" which works for the vintage model, and "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 advantage of this approach is that the generic procedure is stable; it does not have to be changed even if there is a new context situation to be considered (e.g. a new high voltage battery which requires a third variant of voltage reading). This improves maintainability and long-time availability of generic test sequences. Also, this supports cases where test sequence modules are developed by more than one party; the signature concept is a way to define clear and formal interfaces between these distributed parties.

Since the signature concept is dynamic (the effective procedure that will be carried out is in general not known until runtime), special arrangements in the OTX runtime application are required. The indirection via the signature to the actually called procedure has to be resolved. For this task a mapping is needed which allows looking up a valid procedure implementing a given signature. Details on this topic are specified in the ProcedureCall action.

Table of Contents