DE4222774C2 - Method for carrying out at least one test on program modules which can run in parallel on a processor and which exchange time-dependent messages with one another via routines provided in the operating system of the processor - Google Patents

Description

Procedure for performing at least one test on a processor executable in parallel program modules that time-dependent with each other via in the operating system of the Pro routines provided by the processor exchange messages.

The development in the field of computer science is always going on more towards parallel systems. Thereby be there are basically two options Realization. First, the hardware can run in parallel be executed (vector computer, transputer). Doing so the parallelization on the hardware level by suitable Compiler taken into account at the software level / R1 /. This is commonly called small-scale parallelism designated.

Another approach to implementation is parallelism in the huge. It starts in the design phase of the software and forms parallel objects of the real world on paral all units in the software. This parallel one units exist in the operating system used So-called processes or tasks and are independent of the underlying hardware architecture.

The test of parallel running software modules comes in this context, increasingly important. He throws new problems due to time-dependent interprocess communication that is presented in the form of sequence charts can be set, especially in time-critical applications occur.

Test methods previously known from the literature / L1 / be rest on the fact that software modules, for example, instruct  be animals. That means the software to be tested is included an additional piece of special test software code ver see what the program module says about the radio ability of the software. This method has just been related to parallel on a pro processor-executable program modules that are time-dependent with each other via those provided in the processor operating system Exchange routine messages, especially serious ones Disadvantage:

• - The software to be tested is through the instrumentation changed.
• - Because of this change their timing behavior influenced.
• - Through this interference in the software to be tested the relative timing of the processes to each other influences.
• - The filling level of buffers for process messages is being influenced.

In sum, these disadvantages have the following effects: that with the previous test procedures no absolute out say about real-time behavior and the course of the examined Software can be made / L1 /.

In further state of the art / Z1 / is detailed on the peculiarities of parallel processing in terms of time behavior, interrupt handling and process control received.

In / B1 / a monitor for parallel use is presented provides the real-time behavior of the tasks as possible little affected. For this, the monitor is considered too additional task on the level of parallel executable Program modules located and its processor occupancy time controlled by priority assignment in the UNIX operating system.

Procedures that allow exact information about the Real-time behavior of running in parallel on one processor  to make capable program modules are not known.

The object underlying the invention is a procedure for performing tests on a pro processor executable parallel program modules, the time depending on each other in the operating system of the processor scheduled routines exchange messages, specify that does not require any intervention in the programs to be tested change and that during testing statements about compliance real runtime conditions of the individual program modules allowed.

This object is achieved in accordance with the features of patent claim 1 solved.  

Further developments of the invention result from the Subclaims.

Particularly advantageous when using the fiction method is the fact that by starting and Terminate program modules specific test scenarios can be put. It is also advantageous that Messages are changed, suppressed and logged can, including a comparison of a current one Message with a predetermined target message possible is. It is also beneficial that the buffer contents are non-destructive can be read. Still cheap when using the The method according to the invention is that the process country by analyzing the company's queues systems can be observed. Still cheap at Application of the method according to the invention is the deed thing that additional messages are introduced can or buffer contents can be deleted.

The method according to the invention is particularly favorable in connection with operating systems that apply Interrupt handling routines for message out exchange between program modules running in parallel see, since there are no major programming changes stations for the use of the method according to the invention are to be made.

To the software overhead in the operating system if possible to keep it small, it is cheap when using the inventin method according to the test start information directly during interrupt handling for the messages exchange of program modules running in parallel.

For the same reasons, it is convenient to use the inventive method during the test program start of interrupt handling.  

Advantageous when using the method according to the invention it is only interrupts for the test execution Allow input and output, otherwise the saved ones State variables and processor register contents other interrupts changed in an unpredictable manner could become.

It can be favorable when using the invention The stored state variables and Modify processor register contents in a targeted manner in order to Set test scenarios.

To the mistake when using the inventive method Check the treatment by the software to be tested To be able to open additional messages contribute or delete messages.

A particular advantage of the method according to the invention is that by reading the system clock at night exchange of views between the individual program modules very precise statements about the timing of the whole systems are possible when they are processed.

In the following the invention is based on exemplary embodiments play further explained.

Fig. 1 shows the message exchange of parallel ablau fenden program modules.

Fig. 2 shows the integration of a test program in an operating system with interrupt handling.

Fig. 3 illustrates the processes in the exchange of messages between two or more program modules.

In Fig. 1, the time-dependent message exchange between parallel program modules he explains, which is a reason for the use of the inventive method. The following facts are presented there. The sequence chart shows four program modules M1 to M4, of which M1 sends a message N1 to module M2 at any time. A maximum of 50 milliseconds later, the module M3 must also send a message N2 to M2. This in turn sends a message N3 to the module M4 a maximum of 100 milliseconds later. The format and content of each message is specified. TA and TB denote the time conditions that must be met for sending the messages between the program modules running in parallel. TA must be less than 50 milliseconds and TB less than 100 milliseconds.

In previously known test methods by instrumentation the following could happen: For example the module M1 is instrumented. When running the test at Real-time conditions require additional processing introduced test software, for example, more than 50 Milliseconds of processor time. This has the consequence that the message N1 arrives there too late to the module M2. That means TA is greater than 50 milliseconds. So that will the condition of the sequence chart was not met and the software runs incorrectly. Analogous considerations can be used for module M2 and for sending the post Execute N3 on module M4, which then becomes a Failure to observe the time control TB.

Fig. 2 shows an example of a structure showing how a test program for the novel process in an operating system that provides for the exchange of messages interrupt handling can be integrated.

Program modules M1 capable of running in parallel are shown to MN, the interrupt handler IH, and the individual pro Buffer B1 to BN assigned to the gram modules.  

In FIG. 2, the following facts are illustrated: The parallel executable modules exchange in normal operation messages from by rupt-treatment via the interrupt handler IH of the operating system a specific message Inter cause. The interrupt handler for message handling then accesses the individual buffer contents and transmits messages from the buffer of the transmitter module to the buffer of the receiver module. It is important to recognize from Fig. 2 that the test program is an integral part of the operating system. During normal operation, the interrupt handler IH transparently accesses the individual buffers B1 to BN through the test program TP.

However, if the operator tests the individual programs module is desired, he initiates the test program by monitoring the send and receive addresses in the messages sent, in the program to be tested modules to become active. This happens, for example in that the test program to be monitored modules are published in lists. With the test pro gram can then test scenarios by starting and exiting of processes, for example. Farther messages can be logged, changed, suppressed or be added. Another way to test offers itself in the non-destructive reading of the buffer contents B1 to BN. In addition, the stopped system clock be read. There is also the possibility of observing the process landscape, which through the program modules running here is represented by Analysis of the operating system queues. In addition can by adding messages and deleting Buffer content processes can be simulated. For example can send messages from not yet realized program modules are generated.  

This makes it possible to use the test program to make absolute statements about the real-time behavior and the sequence of the examined program modules M1 to MN. From Fig. 2 it can also be clearly seen that the test program TP is not part of the parallel program modules M1 to MN. In its capacity to belong to the operating system, it has no influence on the timing of the program modules.

In Fig. 3, an exemplary embodiment of the inventive method based on the message exchange between a program module M1 and M2 is illustrated. There is a program module M1 that wants to send a message N1 to M2.

He initiates this with a send interrupt to the inter rupt handler IH of the operating system. The interrupt handler In this case, the sending process sees a backup of the relevant memory for all program modules and for state variables required for their operation. This Step is carried out. In this case the rele vanten memory the processor register. Only then is it done a query "Test?". If no test is done interrupt processing continues to see one Access to buffer B1 for program module M1 before and transfers the message N1 contained there to the Buffer B2 for module M2. Then the previous ones stored variables and memory contents again load and normal operation is started again.

If it is found during the test query that a Calling the test program is desired, the test program started and the operating system clock stopped. Various inputs and outputs can then be used in the test program be carried out to conduct a test required are.  

After the end of the test program, it will be returned to it Place branches in the process that result from a test query "No" results.

The designations for the buffers shown in FIG. 3 can be found in FIG. 2, since this is a special version of FIG. 2. With Fig. 3 shall be made clear clear once more that the test program TP is not a module which is running in parallel with the other modules M1 to MN, but an integral part of the operating system.

Here the test program TP is, for example, via the Interrupt handling in the operating system for the Exchange of messages between the Program modules is provided, called. So achieved one has a clean separation between the flow of the individual NEN program modules in parallel or normal operation and between the execution of the test program for test operation. Thus, the execution of the test program has no matter how long it lasts, no temporal effects on the Ab run of the program modules under real time conditions.

literature

/ L1 / Liggesmeyer, Peter
Module test and module verification: state of the art, Mannheim; Vienna; Zurich BI-Wiss.-Verl., 1990 (Applied Computer Science; Vol. 4) ISBN 3-411-14361-4
/ R1 / Raebel, G.
A vectorizing Pascal compiler in: Computer Science in Practice: Aspects of its Industrial Use / ed. by H. Schwärtzel Springer-Verl. Berlin Heidelberg New York 1986 ISBN 3-540-17054-5
/ B1 / BÖFFGEN Rudolf, debugging real-time applications, in: Design & Elektronik 17 from August 13, 91, Sn. 59, 60
/ Z1 / ZILKER Michael, practice of multitasking, Franzis-Verlag, Munich, 1987

Claims (6)

1. Method for carrying out at least one test on program modules which can run in parallel on a processor and which exchange time-dependent messages with one another via routines provided in the processor's operating system,

• a) in which the messages (N) exchanged by the program modules (M1... MN) are monitored by the operating system at least with regard to the transmitter and / or receiver module (M1... MN),
• b) and during an interruption handling provided for the message exchange, if a module to be tested (M1... MN) sends a message (N) and / or is sent to it, the test is carried out.

2. The method according to claim 1,

• a) in which the processor's system clock is stopped during the test,
• b) where only inputs and outputs are allowed during the test,
• c) and in which a test program is started as a test, with which inputs and outputs required for a test are carried out.

3. The method according to any one of claims 1 to 2, in which all interruption treatments for the test execution of the processor other than the I / O interrupt handlers be blocked. 4. The method according to any one of claims 1 to 3, in which before the end of the interrupt handling for the message exchange status variables changed by test inputs and Processor register contents are loaded. 5. The method according to any one of claims 1 to 4, with additional messages (N) during the test brought or messages (N) are deleted.   6. The method according to any one of claims 1 to 5, in which to determine the runtime of individual program modules (M) stopped system clock is read.