TETware for Realtime and Embedded Systems

When testing embedded systems, this model needs to be modified. This is mainly for the following reasons:

• TETware cannot run on the embedded system. All the control operations must be performed on a host system.

• Operating system facilities on the embedded system may be limited. If a test case malfunctions on the embedded system, it may be necessary to reset the system in order to regain control.

Figure 2: Simple TETware Realtime and Embedded System Testing Model

The required modification is accomplished by using TETware’s exec tool facility to run the TETware RT Test Manager on the host system (that is: the system on which TETware runs). The Test Manager acts as an agent for the test case that is running on the embedded system.

TETware RT Test Manager

TETware executes a new instance of the Test Manager each time it executes a test case. The Test Manager performs the following operations:

1. Read information from the test manifest, including information about the arrangement of ICs and TP functions in the test case.
   
2. Use the dynamic test case interface to adapt itself to the IC/TP arrangement described in the test manifest.
   
3. Load the test case onto to embedded system and execute it.
   
4. Open a communication channel to the test case on the embedded system.
   
5. Instruct the TCM on the embedded system to invoke the test case’s startup function, TP functions and cleanup function.
   
6. For each of these functions, enter a service loop, responding to requests from the TCM/API on the embedded system. The loop is terminated when the function returns to the embedded system’s TCM, or when a timeout expires.
   
7. Deliver a TP function’s result to the journal.
   
8. If the TP timed out: Reset the embedded system.
   

TETware RT TCM and API

Each test case that is to run on the embedded system is linked with the TETware RT versions of the C TCM and API library. As in TETware, both single-threaded and thread-safe versions of these components are supplied. A substantial subset of the API functions implemented in TETware Lite is available in the TETware RT version of the API library.

Although the supported API functions are the same, in many cases the implementations are quite different. For example, functions that write information to the execution results file in TETware instead send the information to the Test Manager in TETware RT. When the Test Manager receives this information, it writes the information to the execution results file on the host system.

Manufacturer Specific Subsystems

An interface has been defined which enables TETware RT components to send requests to other hardware and software subsystems. The implementation of the underlying functionality is specific to the hardware and/or software involved, and is implemented by (or on behalf of) the suppliers of these components.

The subsystems are described in more detail below. For additional information please refer to the TETware Realtime and Embedded Systems Extension; Installation, User, Demonstration and Programmers Guide.

Functions that are implemented on the host system are used by the Test Manager, and functions that are implemented on the realtime system are used by the TETware version of the Test Case Manager and API library.

Communication Subsystem

Provides two-way communication between the Test Manager on the host system and the TETware RT TCM/API on the realtime system.

This subsystem consists of two parts; one part on the host system and the other on the realtime system. Each part is responsible for establishing a communication channel to the other part, and for exchanging fixed length message packets over the channel. Typically this subsystem is implemented using TCP/IP (if the realtime system supports it) or a connection between serial ports on each system.

Exec Subsystem

Loads a test case executable on to the realtime system and executes it; and, provides a profile-independent mechanism for test case termination on the realtime system.

This subsystem consists of two parts; one part on the host system and the other on the realtime system.

The part on the host system is responsible for copying a program image file onto the realtime system and executing it. The part on the realtime system is used to terminate a running program, as if exit() has been called by the program.

Reset Subsystem

Resets the realtime system.

This subsystem consists of a single part on the host system. It is responsible for initializing the realtime system to a known state.

The following operations are defined: Soft reset; Hard reset.

Normally the Test Manager requests a soft reset if a test purpose times out, or if it is necessary to interrupt the currently running test purpose for some reason. If the soft reset operation fails, the Test Manager requests a hard reset. This process is analogous to sending a SIGTERM signal to a process running on a UNIX system, followed up by a SIGKILL signal if the process has not terminated within a reasonable time. If only one type of reset is possible for a particular realtime system, then it should be performed in response to both types of reset request.

Products using TETware/RT

The Open Group has the following test suites that provide embedded systems test coverage:

• IEEE POSIX 1003.1-1990 (VSX4-PSE)
  
• IEEE POSIX 1003.1b-1993/1003.1i-1995 Realtime extension (VSRT-PSE)
  
• IEEE Std POSIX 1003.1c-1995 Threads (pthreads) extension (VSTH-PSE)
  
• IEEE POSIX 1003.13-1998 Profile 52 (VSPSE52)
  
• Embedded Linux Test Suites (VSELX)