OTX serves as a high-level domain-specific language, which is particularly designed for graphical notation and editing.
OTX follows the paradigm of imperative, structured programming. OTX procedures determine sequences of commands for the computer to carry out (Imperative). No explicit jumps are allowed in OTX. However, there are branches, loops, exception handlers, return, continue, break and throw statements as well as procedure calls to define jumps implicitly and in a controlled manner. As a result, OTX also defines a block structure, as typically found in all languages following the structured programming paradigm.
In contrast to other programming languages where programs are mostly edited in text-based source code editors, OTX aims at sequence editing by graphical authoring tools. The intended author of OTX is an engineer with good knowledge about the technical background of the sequence. On the other hand, the normal author is not a software developer. Consequently, OTX is a procedural and not an object orientated programming language.
The OTX format provides explicit support for a three-stage development of test sequences.
Sometimes, a test sequence is described at specification level only. This is useful for early stages in the development process of test sequences, when the author does not know all the details for creating an executable test sequence. At this stage, the development of test sequences is at a prose level, which is human readable, but not fully executable. In other words, the general sequence logic may already be there, but single steps of the sequence are only filled by prose, so a runtime interpreter cannot use it to run. Nevertheless, after this stage, the test sequence can be continuously broken down by the next stages.
At the intermediate stage, the test sequences are also allowed in OTX, and this type of test sequences exist while upgrading a specification stage test sequence to a realization stage sequence. In an intermediate stage, test sequence may comprise parts that are already fully executable, while other parts are still at specification stage. Using the human readable information and instructions from the specification stage of some parts, the sequence author can implement them by adding realization for counter-parts.
At this stage, no more specification-only parts remain in the sequence. All the parts in the sequence are executable then. Even at this stage, the sequence may still contain specification parts, but those parts must have the corresponding realization. With other words, this coexistence serves as an "executable specification". At any step in this process, the sequence is validly save able and exchangeable.
Modular OTX extension concept and OTX-based runtime architecture
The structure of OTX data model consists of a language core and different functional extensions. It is important to note that the OTX Core, also the extensions defined in this standard, does merely supply syntactical definitions for the elements of test sequences and a functional description of the expected behaviour. The standard does not involve the implementation of the runtime behaviour. There should be necessary freedom when implementing OTX runtime components to conform particular use cases. For instance, it would be impractical for the OTX standard to determine the specific implementation of an HMI library because the requirements and backend frameworks for HMI functionality will differ for each test environment.
The Figure contains an overview of the standard extensions specified in ISO 13209-3. The next specification of the OTX Core data model touches the extensions only by defining extension interfaces, which represent hooks for the respective extensions. Otherwise, the Core is fully stand-alone executable.
By the separation of OTX structure (intent) and runtime implementation (execution), OTX can be used as a test sequence exchange format, which can be deployed throughout an entire organization, or even beyond company boundaries. THe Figure shows the architecture of an OTX runtime diagnostic application. The OTX-Runtime part of the diagnostic application is executing OTX sequences, which utilize OTX core data model constructs, as well as of various extensions interfaces (HMI, Environment-specifics, vehicle communications and other proprietary functionality).
The real runtime system implementation knows how to map e.g. a HMI extension action in an OTX sequence to the GUI framework, which is used by the test application. For instance, an after-sales application might map an OTX “Choice-Dialog” action to a Java Swing dialog entity which allows interaction with the workshop mechanic. The same OTX sequence may also be executed on a manufacturing station, where the diagnostic application implementation would map the “Choice-Dialog” action to a state machine connected to manufacturing line measurement device instead of a GUI interface.
To be continued ...