WO2000055733A1

WO2000055733A1 - Program monitoring method and device

Info

Publication number: WO2000055733A1
Application number: PCT/DE2000/000626
Authority: WO
Inventors: Kai TÖDTER; Peter Zimmerer; Erwin Reyzl
Original assignee: Siemens Aktiengesellschaft
Priority date: 1999-03-12
Filing date: 2000-03-01
Publication date: 2000-09-21
Also published as: CA2366977A1; IL145304A0; EP1163585A1

Abstract

The invention relates to a method for monitoring a program, wherein the program is extended with an instrumentation part that generates a message and transmits said message to a monitoring process which executes a given action.

Description

description

Method and arrangement for monitoring a program

The invention relates to a method and an arrangement for monitoring a program.

A program is usually monitored by means of special breakpoints (so-called brake points), at which a programmer can view debug information and, if necessary, deduce that the program is malfunctioning. This manual measure is extremely cumbersome and time-consuming with a sufficiently large program with numerous sub-programs. Furthermore, the debug information is mainly evaluated offline, i.e. not at program runtime. If the program is part of a distributed system, clear, manual monitoring can no longer be coordinated.

The object of the invention is to provide a method and an arrangement for monitoring a program, which enables efficient monitoring even at runtime of the program, in particular in a distributed system. Such monitoring is feasible on the basis of the present invention, especially for a large number of programs.

This object is achieved according to the features of the independent claims. Further developments of the invention also result from the dependent claims.

To solve the problem, a method for monitoring a program is specified in which the program is expanded by an instrumentation part. The instrumentation part generates a message and transmits this message to a monitoring process. The monitoring process initiates a specified action. An instrumentation part is a program part or a (program) code (fragment) that is linked to the program to be monitored. This connection can be made by embedding the instrumentation part m the program itself or m a function associated with the program. For example, the program itself can be instrumented at some points, each of which then sends messages to the monitoring process for certain events. At the same time, an output routine of the

Program are instrumented so that, in addition to the normal (ie without instrumentation) output of the program, further expenditure is directed to the monitoring process (instrumentation of the input / output interface of the program).

The monitoring process preferably takes over the coordination of the messages which are transmitted (possibly by numerous distributed) programs. Furthermore, the monitoring process can have various actions that it can trigger or initiate as a result of the messages:

• For example, the messages are presented. The display is preferably dependent on the time, e.g. m in the form of a message flow diagram

(English: Sequence Chart, MSC). Forms of representation as a tree structure or in the form of lists are also conceivable.

• It is also possible to intervene in the course of the program. The instrumentation section was thus able to arrange for a response from the monitoring process to be waited for before the program itself is continued. This answer can be made by a user / programmer or automatically depending on certain specifications (IF-THEN-ELSE construction). The automated one The process can run as a separate subroutine, coordinated by the monitoring process.

• It is also possible that the action corresponds to a control or regulation task. An example would be switching a unit of a technical system on or off as soon as certain requirements have been met or have been reported to the monitoring process.

The advantages of the method presented here are the possibility of monitoring the program during its runtime. The instrumentation ensures that certain events are also reported to the monitoring process in the form of messages during the runtime. There, these messages are collected and processed appropriately. In particular, the monitoring process can use a filter function to ensure that only those messages are displayed or taken into account that actually correspond to the filtered specifications. Furthermore, the possibility of using a distributed system is a decisive advantage. The confusing interaction of many different programs in the distributed system makes troubleshooting difficult. The transmission of messages to the monitoring process of each instrumented (also distributed) program of many different programs, which do not all run on the same computer platform, enables - after suitable filtering and / or processing, e.g. based on a message flow diagram - maintaining an overview, so that tracking of certain actions in the distributed system and the associated troubleshooting are made significantly easier.

It should be noted here that the above-described program can also be part of a related program or a function (linked) associated with the program. Especially advantageous is when a berwachenden with the _above program to associates 'middleware' is instrumented. In this case, a functionality that the program uses can be instrumented centrally. This is particularly advantageous because, for example, not all input / output routines have to be instrumented in the program, but instead the associated routine is instrumented in the middleware. This corresponds exactly to the instrumentation of all I / O routers in the program to be monitored. The actual expansion of the one location in the middleware is extremely economical since the entire program to be monitored does not have to be searched for said routines. The change in

Instrumentation can be done in one place for all affected routines (encapsulation of the interface). Furthermore, this type of instrumentation is very flexible and expandable. If the program to be monitored changes, the instrumentation for the next program to be monitored with regard to the routines concerned (here as an example the input / output routines) has already been completed.

In particular, the following mechanisms are monitored in the program in a distributed system, that is to say in a system which has a plurality of computers which are connected to one another via a network:

• Message transmission (task to task):

A recipient (program or process) is waiting for a message. He can only continue when the message has been transmitted by a sender.

Remote Procedure Call (RPC):

For example, a process on a different computer ("remote") tries to start a program. The The process waits until processing on the "remote" computer has ended. Normally, the process receives notification of the success or failure of the processing.

• Control flow (task join):

One process is added to another process. From then on the added process no longer exists.

If there is a distributed system that consists of several computers, each system is independent and has, for example, its own system clock. In order to ensure semantic correctness, it is important to check plausibility, eg the time stamp of the respective messages. Each sent message receives a tent stamp in particular, which can be used for synchronization. So it can happen that the transmission of a message requires a certain period of time and the time sequence must be clarified when displaying the monitoring process for several messages. If the system clocks of the individual systems do not go the same (which is generally to be assumed), the monitoring process determines the correct chronological order of the messages sent. This is done in particular by means of a heuristic that checks whether an assumption is correct or not. If this is the case, the last determined time sequence is adopted, in the other case a next assumption is checked. The check is based on the semantics of the messages: This means that a reply cannot be received before a request. This allows conclusions to be drawn about the relationships between the two system clocks involved. A time offset is determined which fulfills the plausibility of the system clocks. The offset can be adjusted as soon as another system clock with reference to at least one of the two specific system clocks has to be taken into account. The method described above can preferably be used for testing, controlling and maintaining the program or a technical system associated with the program.

An arrangement for monitoring a program is also specified for solving the task, in which a processor unit is provided which is set up in such a way that a) the program can be expanded by an instrumentation part; b) the instrumentation part generates a message and transmits it to a monitoring process; c) the monitoring process triggers an action.

This arrangement is particularly suitable for carrying out the method according to the invention or one of its developments explained above.

Exemplary embodiments of the invention are illustrated and explained below with reference to the drawing.

Show it

Fig.l is a block diagram with logical components for monitoring a program;

2 shows various representations of mechanisms to be monitored in a distributed system;

3 shows a processor unit.

Fig.l shows a block diagram with logical components for monitoring a program. The program 101 to be monitored has a filter functionality 102 and a

Instrumentation 103 provided. The monitoring process mentioned many times above includes the block event generator 104 (Event Generator "), Event Manager 109 (" Event Manager ") and the various display options 115 to 120 (" Views ").

The event generator 104 contains a parser 105, two night interfaces 106 and 107 and a file 108). The event manager 109 comprises a connection unit 110, an event list 111, a filter unit 112 and a filtered list 113. The respective entry within the filtered list 113 is selected via a navigation unit 114 ("Stepper").

The filter functionality 102 is provided for the selection of certain ones of interest for the respective application

Instrumentation parts of the instrumentation 103. The result of the instrumentation, the messages, are transmitted to a communication interface “socket” 107 or a file 108 is written. The incoming messages are processed by the parser 105 and sent to the

Connection unit 110 transmitted. The entries of the messages received by the parser 105 are stored there in a list 111. In particular, the semantic check of the tent stamps attached to the messages is also carried out here. Block 112 optionally filters all messages stored by the connection unit 110 of the list 111 according to certain specifications. The result is the filtered list 113, the entries of which can be selected using the navigation unit 114.

The navigation unit 114 serves as an interaction medium for the user. Entries can be made there, which are forwarded to the instrumented program part 103 via the communication interface 106 of the event generator 104. In particular, this interaction enables an interplay of program and instrumentation. The interaction can take place by inputting the user or alternatively via a regulation according to the scheme "whenever ... then ...". Furthermore, an action 121 can be carried out, which leads to an external control or another external intervention based on the monitoring process.

The filtered list 113 can be prepared in m different representations 115 to 120. The data of the filtered list 113 can be represented as

List (block 115),

Hierarchically sorted view (e.g. according to computers or structure of programs and processes, block 116), message flow diagram (MSC, block 117), whereby a predetermined grouping can be taken into account,

Detailed view (for each message there is a range of information relating to the sender, recipient, tent stamp, message content, etc .; block 118), • list of the entries made by the user (block 119),

• Test report (block 120).

2 shows various representations of the mechanisms of a distributed system to be monitored.

For this purpose, FIG. 2 is divided into three parts, FIGS. 2A, 2B and 2C. The respective horizontal line denotes the time axis t.

The message transmission is shown in FIG. 2A. A transmitter 201 issues a message at a time t1, which arrives at a receiver 202 at a time t2. At a time t3, the receiver 203 has already started to wait for this message. He waited until time t2, now the receiver 202 continues the work. Fig. 2B shows the "Remote Procedure Call, RPC" mechanism. At a time t4, a process 203 sends a message "CLIENT_BEGIN (Call object. Method (...)" to an addressee 204. This message arrives at the addressee 204 at a time t5, which is preferably a separate computer, far from is the computer on which process 203 is running. At this point in time t5, addressee 204 initiates the execution of the transmitted command with the command "SERVER_BEGIN"") and the result" res "sent back to process 203 (" Return res = obj .meth (...) "). At a time t7, the result arrives at process 203, the RPC is issued with the command" CLIENT_END "The process has waited from t4 to t7 and now continues its processing with the result" res "determined on the addressee 204.

An example of a control flow is shown in Figure 2C. Two processes are to be linked together ("task join"). At a time t8 a

Process Taskl 205 a command "JOIN_REQUEST" sent to a process Task2 206. Once there, at a time t9, a command "JOIN_START" causes process Task2 206 to link with process Taskl 205 up to time t10. At time t10, the "JOIN_DONE" command returns to the process Taskl 205, which resumes work at a time t11 with a "JOIN END" command. The process Taskl 205 has waited from t8 to tll, the process task2 206 has ended after t10.

FIGS. 2A, 2B and 2C illustrate different mechanisms that can be observed in a distributed system in order to obtain an overview of the interaction of distributed programs and processes. When troubleshooting or performing maintenance work, it is an invaluable advantage to be able to track actions at the interprocess interface. A processor unit PRZE is shown in FIG. The processor unit PRZE comprises a processor CPU, a memory SPE and an input / output interface IOS, which is used in different ways via an interface IFC: an output is visible on a monitor MON and / or on a printer via a graphic interface PRT issued. An entry is made using a mouse MAS or a keyboard TAST. The processor unit PRZE also has a data bus BUS, which connects a memory

MEM, the processor CPU and the input / output interface IOS guaranteed. Furthermore, additional components can be connected to the data bus BUS, e.g. additional memory, data storage (hard disk) or scanner.

Claims

claims

1. Procedure for monitoring a program, a) in which the program is expanded by an instrumentation part; b) in which the instrumentation part generates a message and transmits it to a monitoring process; c) in which the monitoring process triggers an action.

2. The method of claim 1, wherein the action comprises one of the following: d) displaying the message; e) intervention in the running of the program; f) Control and / or regulation of a unit associated with the program.

3. The method according to claim 1 or 2, wherein the instrumentation part waits for a response generated by the monitoring process after the message has been transmitted.

4. The method of claim 3, wherein the response is created after input from a user or by an automated process.

5. The method according to any one of the preceding claims, in which a plurality of messages are displayed as a list, tree diagram or as a message flow diagram (Message Sequence Chart, MSC).

6. The method according to any one of the preceding claims, wherein the program is part of a larger program.

. Method according to one of the preceding claims, in which a function associated with the program is instrumented.

8. The method according to any one of the preceding claims, in which a middleware associated with the program is instrumented.

9. The method according to any one of the preceding claims, in which at least one of the following mechanisms is monitored: g) remote procedure call (RPCs), h) message transmission, l) control flow.

10. The method according to any one of the preceding claims, wherein a plurality of programs in a distributed system or a program that is distributed over the system is monitored.

11. The method according to claim 10, in which a check of a semantic correctness is carried out by means of predetermined heuristics.

12. The method according to any one of the preceding claims for testing, controlling or maintaining a technical system.

13. Arrangement for monitoring a program, in which a processor unit is provided which is set up in such a way that j) the program can be expanded by an instrumentation part; k) the instrumentation part generates a message and transmits it to a monitoring process; 1) the monitoring process triggers an action.