[go: up one dir, main page]

WO2000055733A1 - Verfahren und anordnung zum überwachen eines programms - Google Patents

Verfahren und anordnung zum überwachen eines programms Download PDF

Info

Publication number
WO2000055733A1
WO2000055733A1 PCT/DE2000/000626 DE0000626W WO0055733A1 WO 2000055733 A1 WO2000055733 A1 WO 2000055733A1 DE 0000626 W DE0000626 W DE 0000626W WO 0055733 A1 WO0055733 A1 WO 0055733A1
Authority
WO
WIPO (PCT)
Prior art keywords
program
message
monitoring
monitoring process
instrumentation
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/DE2000/000626
Other languages
English (en)
French (fr)
Inventor
Kai TÖDTER
Peter Zimmerer
Erwin Reyzl
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Siemens Corp
Original Assignee
Siemens AG
Siemens Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG, Siemens Corp filed Critical Siemens AG
Priority to CA002366977A priority Critical patent/CA2366977A1/en
Priority to IL14530400A priority patent/IL145304A0/xx
Priority to EP00920353A priority patent/EP1163585A1/de
Publication of WO2000055733A1 publication Critical patent/WO2000055733A1/de
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/362—Debugging of software
    • G06F11/3624—Debugging of software by performing operations on the source code, e.g. via a compiler

Definitions

  • 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.
  • brake points special breakpoints
  • This manual measure is extremely cumbersome and time-consuming with a sufficiently large program with numerous sub-programs.
  • 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.
  • 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.
  • 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:
  • the messages are presented.
  • the display is preferably dependent on the time, e.g. m in the form of a message flow diagram
  • 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.
  • 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.
  • 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.
  • the above-described program can also be part of a related program or a function (linked) associated with the program.
  • 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.
  • 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.
  • a recipient (program or process) is waiting for a message. He can only continue when the message has been transmitted by a sender.
  • a process on a different computer tries to start a program.
  • the process waits until processing on the "remote” computer has ended. Normally, the process receives notification of the success or failure of the processing.
  • One process is added to another process. From then on the added process no longer exists.
  • each system is independent and has, for example, its own system clock.
  • 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.
  • 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.
  • Fig.l is a block diagram with logical components for monitoring a program
  • FIG. 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.
  • 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
  • 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,
  • FIG. 2 shows various representations of the mechanisms of a distributed system to be monitored.
  • FIG. 2 is divided into three parts, FIGS. 2A, 2B and 2C.
  • the respective horizontal line denotes the time axis t.
  • FIG. 2A 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.
  • 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.
  • a process 203 sends a message "CLIENT_BEGIN (Call object. Method specified" 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.
  • 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.
  • FIG. 2C 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
  • additional components can be connected to the data bus BUS, e.g. additional memory, data storage (hard disk) or scanner.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Es wird ein Verfahren zur Überwachung eines Programms angegeben, bei dem das Programm um einen Instrumentierungsteil erweitert wird. Der Instrumentierungsteil generiert eine Nachricht und übermittelt diese Nachricht an einen Überwachungsprozess. Der Überwachungsprozess leitet eine vorgegebene Aktion ein.

Description

Beschreibung
Verfahren und Anordnung zum Überwachen eines Programms
Die Erfindung betrifft ein Verfahren und eine Anordnung zum Überwachen eines Programms .
Eine Überwachung eines Programms erfolgt üblicherweise mittels spezieller Haltepunkte (sog. Brakepomts) , an denen ein Programmierer Debuginformationen einsehen und gegebenenfalls auf eine Fehlfunktionalitat des Programms ruckschließen kann. Diese handische Maßnahme ist bei einem hinreichend großen Programm mit zahlreichen Unterprogrammen äußerst umständlich und zeitraubend. Weiterhin erfolgt eine Auswertung der Debuginformation hauptsachlich offline, also nicht zur Laufzeit des Programms. Ist das Programm Teil eines verteilten Systems ist eine übersichtliche handische Überwachung nicht mehr koordinierbar.
Die Aufgabe der Erfindung besteht darin, ein Verfahren und eine Anordnung zur Überwachung eines Programms anzugeben, das bzw. die auch zur Laufzeit des Programms, insbesondere m einem verteilten System, eine effiziente Überwachung ermöglicht. Gerade für eine Vielzahl von Programmen ist eine derartige Überwachung anhand vorliegender Erfindung machbar.
Diese Aufgabe wird gemäß den Merkmalen der unabhängigen Patentansprüche gelost. Weiterbildungen der Erfindung ergeben sich auch aus den abhangigen Ansprüchen.
Zur Losung der Aufgabe wird ein Verfahren zur Überwachung eines Programms angegeben, bei dem das Programm um einen Instrumentierungsteil erweitert wird. Der Instrumentierungsteil generiert eine Nachricht und übermittelt diese Nachricht an einen Uberwachungsprozeß . Der Uberwachungsprozeß leitet eine vorgegebene Aktion ein. Ein Instrumentierungsteil ist ein Programmteil oder ein (Programm-) Code (fragment) , das mit dem zu überwachenden Programm verbunden wird. Diese Verbindung kann dadurch erfolgen, daß der Instrumentierungsteil m das Programm selbst oder m eine mit dem Programm assoziierte Funktion eingebettet wird. Beispielsweise kann das Programm selbst an einigen Stellen instrumentiert werden, deren jede dann an den Uberwachungsprozeß bei bestimmten Ereignissen Nachrichten schickt. Gleichzeitig konnte eine Ausgaberoutine des
Programms instrumentiert werden, so daß zusatzlich zur normalen (also ohne Instrumentierung) Ausgabe des Programms weitere Ausgaben an den Uberwachungsprozeß geleitet werden (Instrumentieren der Eιn-/Ausgabeschnιttstelle des Programms) .
Der Uberwachungsprozeß übernimmt vorzugsweise die Koordination der Nachrichten die (ggf. von zahlreichen verteilten) Programmen ubersandt werden. Ferner kann der Uberwachungsprozeß über verschiedene Aktionen verfugen, die er als Folge der Nachrichten auslosen bzw. einleiten kann:
• So können z.B. die Nachrichten dargestellt werden. Die Darstellung erfolgt vorzugsweise abhangig von der Zeit, z.B. m Form eines Nachrichtenflußdiagramms
(engl.: Message Sequence Chart, MSC) . Auch Darstellungsformen als Baumstruktur oder m Form von Listen sind denkbar.
• Weiters ist ein Eingriff m den Ablauf des Programms möglich. So konnte der Instrumentierungsteil veranlassen, daß erst auf eine Antwort von dem Uberwachungsprozeß zu warten ist, ehe das Programm selbst fortgesetzt wird. Diese Antwort kann von einem Benutzer/Programmierer vorgenommen werden oder automatisch abhangig von bestimmten Vorgaben erfolgen (IF-THEN-ELSE-Konstruktion) . Der automatisierte Ablauf kann als eigenes Unterprogramm, koordiniert durch den Uberwachungsprozeß, ablaufen.
• Auch ist es möglich, daß die Aktion einer Steuerungs- oder Regelungsaufgabe entspricht. Ein Beispiel wäre ein Zu- bzw. Abschalten einer Einheit eines technischen Systems, sobald bestimmte Vorgaben erfüllt sind bzw. an den Uberwachungsprozeß gemeldet wurden.
Vorteile des hier vorgestellten Verfahrens sind die Möglichkeit der Überwachung des Programms zu seiner Laufzeit. Durch die Instrumentierung ist sichergestellt, daß auch wahrend der Laufzeit bestimmte Ereignisse in Form von Nachrichten an den Uberwachungsprozeß gemeldet werden. Dort werden diese Nachrichten gesammelt und geeignet aufbereitet. Insbesondere kann der Uberwachungsprozeß anhand einer Filterfunktion sicherstellen, daß nur diejenigen Nachrichten dargestellt oder berücksichtigt werden, die auch tatsachlich den gefilterten Vorgaben entsprechen. Weiterhin ist die Emsatzmoglichkeit m einem verteilten System ein entscheidender Vorteil. Die unübersichtliche Interaktion vieler verschiedener Programme m dem verteilten System macnt eine Fehlersuche schwierig. Die Übermittlung von Nachrichten an den Uberwachungsprozeß von jedem instrumentierten (auch verteilten) Programm vieler verschiedener Programme, die nicht alle auf derselben Rechnerplattform ablaufen, ermöglicht - nach geeigneter Filterung und/oder Aufbereitung, z.B. anhand eines Nachrichtenflußdiagramms - die Wahrung einer Übersicht, so daß eine Verfolgung bestimmter Aktion m dem verteilten System und die damit verbundene Fehlersuche deutlich erleichtert werden.
Hierbei sei angemerkt, daß oben beschriebenes Programm durchaus auch je ein Teil eines zusammenhangendes Programms oder eine mit dem Programm verknüpfte (assoziierte) Funktion sein kann. Besonders von Vorteil ist es, wenn eine mit dem zu überwachenden Programm assoziierte 'Middleware' instrumentiert wird. In diesem Fall kann zentral eine Funktionalität, derer sich das Programm bedient, instrumentiert werden. Dies ist gerade deshalb von herausragendem Vorteil, weil so bspw. nicht alle Ein-/Ausgaberoutinen m dem Programm instrumentiert werden müssen, sondern statt dessen die eine zugehörige Routine in der Middleware instrumentiert wird. Dies entspricht gerade der Instrumentierung aller Em-/Ausgaberoutmen m dem zu überwachenden Programm. Die tatsachliche Erweiterung der einen Stelle m der Middleware ist äußerst ökonomisch, da nicht das ganze zu überwachende Programm nach besagten Routinen durchsucht werden muß. Die Änderung der
Instrumentierung kann zentral an einer Stelle für alle betroffenen Routinen erfolgen (Kapselung der Schnittstelle) . Ferner ist diese Art der Instrumentierung sehr flexibel und erweiterbar. Ändert sich das zu überwachende Programm, ist die Instrumentierung für das nächste zu überwachende Programm hinsichtlich der betroffenen Routinen (hier als Beispiel die Eιn-/Ausgaberoutmen) bereits fertiggestellt.
Insbesondere werden m einem verteilten System, also m einem System, das mehrere Rechner aufweist, die über ein Netzwerk miteinander verbunden sind, die folgenden Mechanismen m dem Programm überwacht:
• Nachrichtenübermittlung (engl.: message passmg, task to task) :
Ein Empfanger (Programm oder Prozeß) wartet auf eine Nachricht. Er kann erst weitermachen, wenn die Nachricht von einem Sender übermittelt worden ist.
• Remote Procedure Call (RPC) :
Beispielsweise versucht ein Prozeß auf einem anderen Rechner ("remote") ein Programm zu starten. Der Prozeß wartet solange, bis auf dem "remote"-Rechner die Bearbeitung beendet ist. Im Normalfall erhalt der Prozeß eine Benachrichtung über Erfolg oder Mißerfolg der Bearbeitung.
• Kontrollfluß (engl.: task join) :
Ein Prozeß wird einem anderen Prozeß hinzugefugt. Der hinzugefugte Prozeß ist von da an nicht langer existent .
Liegt ein verteiltes System vor, das aus mehreren Rechnern besteht, so ist jedes System für sich eigenständig und verfugt z.B. über eine eigene Systemuhr. Um eine semantische Korrektheit sicherzustellen ist es wichtig, Plausibilitat, z.B. den Zeitstempel der jeweiligen Nachrichten, zu überprüfen. Jede verschickte Nachricht erhalt insbesondere einen Zeltstempel, der zur Synchronisation einsetzbar ist. So kann es vorkommen, daß die Übermittlung einer Nachricht eine bestimmte Zeitdauer benotigt und bei der Darstellung m dem Uberwachungsprozeß bei mehreren Nachrichten die zeitliche Abfolge geklart werden muß. Gehen die Systemuhren der einzelnen Systeme nicht gleich (wovon m der Regel auszugehen ist), so wird von dem Uberwachungsprozeß die richtige zeitliche Abfolge der gesendeten Nachrichten bestimmt. Dies geschieht insbesondere mittels einer Heuristik, die überprüft, ob eine Annahme korrekt ist oder nicht. Ist dies der Fall, so wird die zuletzt ermittelte zeitliche Abfolge übernommen, im anderen Fall wird eine nächste Annahme überprüft. Die Überprüfung basiert auf einer Semantik der Nachrichten: So kann eine Antwort nicht vor einer Anfrage eingehen. Dies laßt Rückschlüsse auf die Verhaltnisse der beiden mvolvierten Systemuhren zu. Es wird ein zeitlicher Offset bestimmt, der eine Plausibilitat der Systemuhren erfüllt. Der Offset kann angepaßt werden, sobald eine weitere Systemuhr mit einem Bezug zu mindestens einer der beiden bestimmten Systemuhren berücksichtigt werden muß. Das oben beschriebene Verfahren ist bevαrzugt einsetzbar zum Testen, Steuern und Warten des Programms bzw. eines mit dem Programm assoziierten technischen Systems.
Auch wird zur Losung der Aufgabe eine Anordnung zum Überwachen eines Programms angegeben, bei der eine Prozessoreinheit vorgesehen ist, die derart eingerichtet ist, daß a) das Programm um einen Instrumentierungsteil erweiterbar ist; b) der Instrumentierungsteil eine Nachricht generiert und an einen Uberwachungsprozeß übermittelt; c) der Uberwachungsprozeß eine Aktion auslost.
Diese Anordnung ist insbesondere geeignet zur Durchfuhrung des erfmdungsgemaßen Verfahrens oder einer seiner vorstehend erläuterten Weiterbildungen.
Ausfuhrungsbeispiele der Erfindung werden nachfolgend anhand der Zeichnung dargestellt und erläutert.
Es zeigen
Fig.l ein Blockdiagramm mit logischen Komponenten zum Überwachen eines Programms;
Fig.2 verschiedene Darstellungen von zu überwachenden Mechanismen eines verteilten Systems;
Fig.3 eine Prozessoreinheit.
Fig.l zeigt ein Blockdiagramm mit logischen Komponenten zum Überwachen eines Programms. Das zu überwachende Programm 101 ist mit einer Filterfunktionalitat 102 und einer
Instrumentierung 103 versehen. Der oben vielfach erwähnte Uberwachungsprozeß umfaßt die Blocke Ereignisgenerator 104 (engl.: "Event Generator"), Ereignismanager 109 (engl.: "Event Manager") und die verschiedenen Darstellungsmoglichkeiten 115 bis 120 (engl.: "Views").
Der Ereignisgenerator 104 enthalt einen Parser 105, zwei Nachπchtenschnittstellen 106 und 107 und eine Datei 108) . Der Ereignismanager 109 umfaßt eine Verbindungseinheit 110 (engl.: "Merger"), eine Ereignisliste 111 (engl.: "Trace Event List"), ein Filteremheit 112 und eine gefilterte Liste 113. Eine Auswahl des jeweiligen Eintrags innerhalb der gefilterten Liste 113 erfolgt über eine Navigationseinheit 114 (engl. : "Stepper") .
Die Filterfunktionalitat 102 ist vorgesehen zur Selektion bestimmter für die jeweilige Anwendung interessierender
Instrumentierungsteile der Instrumentation 103. Das Ergebnis der Instrumentierung, die Nachrichten, werden an eine Kommunikationsschnittstelle "Socket" 107 übermittelt oder m eine Datei 108 geschrieben. Die eingehenden Nachrichten werden dem Parser 105 aufbereitet und an die
Verbindungseinheit 110 übermittelt. Dort werden die vom Parser 105 erhaltenen Eintrage der Nachrichten m einer Liste 111 abgelegt. Insbesondere erfolgt hier auch die semantische Überprüfung der den Nachrichten anhaftenden Zeltstempel. Optional erfolgt Block 112 eine Filterung aller von der Verbindungseinheit 110 der Liste 111 abgelegten Nachrichten nach bestimmten Vorgaben. Das Ergebnis ist die gefilterte Liste 113, deren Eintrage mittels Navigationseinheit 114 auswahlbar sind.
Die Navigationseinheit 114 dient als Interaktionsmedium für den Benutzer. Dort können Eingaben erfolgen, die über die Kommunikationsschnittstelle 106 des Ereignisgenerators 104 an den instrumentierten Programmteil 103 weitergeleitet werden. Insbesondere ist durch diese Interaktion ein Zusammenspiel von Programm und Instrumentierung möglich. Die Interaktion kann durch Eingabe des Benutzers oder alternativ über eine Vorschrift nach dem Schema "immer wenn ... dann ..." erfolgen. Weiterhin kann eine Aktion 121 durchgeführt werden, die ausgehend von dem Uberwachungsprozeß zu einer externen Steuerung oder einem sonstigen externen Eingriff fuhrt.
Die gefilterte Liste 113 kann m unterschiedlichen Darstellungen 115 bis 120 aufbereitet werden. Die Daten der gefilterten Liste 113 können dargestellt werden als
• Liste (Block 115) ,
• hierarchisch sortierte Ansicht (z.B. nach Rechnern oder Struktur von Programmen und Prozessen, Block 116), • Nachrichtenflußdiagramm (MSC, Block 117), wobei eine vorgegebene Gruppierung berücksichtigt werden kann,
• detaillierte Ansicht (zu jeder Nachricht gibt es eine Reihe von Informationen betreffend Sender, Empfanger, Zeltstempel, Nachrichtenmhalt, etc.; Block 118), • Liste der vom Benutzer durchgeführten Eingaben (Block 119) ,
• Testreport (Block 120) .
Aus Fig.2 gehen verschiedene Darstellungen von zu überwachenden Mechanismen eines verteilten Systems hervor.
Fig.2 ist dazu dreigeteilt m die Figuren 2A, 2B und 2C. Die jeweilige horizontale Linie bezeichnet die Zeitachse t.
In Fιg.2A ist die Nachrichtenübermittlung dargestellt. Ein Sender 201 setzt zu einem Zeitpunkt tl eine Nachricht ab, die zu einem Zeitpunkt t2 bei einem Empfanger 202 ankommt. Bereits zu einem Zeitpunkt t3 hat der Empfanger 203 damit begonnen auf diese Nachricht zu warten. Bis zu dem Zeitpunkt t2 hat er gewartet, jetzt setzt der Empfanger 202 die Arbeit fort. Fig.2B zeigt den Mechanismus "Remote Procedure Call, RPC". Zu einem Zeitpunkt t4 setzt ein Prozeß 203 an einen Adressaten 204 eine Meldung "CLIENT_BEGIN (Call object . ethod ( ... ) " ab. Diese Nachricht kommt zu einem Zeitpunkt t5 bei dem Adressaten 204 an, der vorzugsweise eine eigener Rechner, fern von dem Rechner auf dem der Prozeß 203 abläuft, ist. Der Adressat 204 veranlaßt zu diesem Zeitpunkt t5 mit dem Befehl "SERVER_BEGIN" die Ausführung des übermittelten Kommandos. Zu einem Zeitpunkt t6 ist die Ausführung bei Adressaten 204 beendet, die Arbeit wird eingestellt ( "SERVER_END" ) und das Ergebnis "res" an den Prozeß 203 zurückgeschickt ("Return res=obj .meth (...)") . Zu einem Zeitpunkt t7 kommt das Ergebnis bei dem Prozeß 203 an, der RPC wird mit dem Befehl "CLIENT_END" beendet. Der Prozeß hat von t4 bis t7 gewartet und setzt jetzt mit dem auf dem Adressaten 204 ermittelten Ergebnis "res" seine Bearbeitung fort.
Ein Beispiel für einen Kontrollfluß ist in Fig.2C dargestellt. Dabei sollen zwei Prozesse miteinander verbunden werden ("Task Join") . Zu einem Zeitpunkt t8 wird von einem
Prozeß Taskl 205 ein Kommando "JOIN_REQUEST" zu einem Prozeß Task2 206 geschickt. Dort angekommen, bewirkt zu einem Zeitpunkt t9 ein Kommando "JOIN_START" , daß bis zu einem Zeitpunkt tlO der Prozeß Task2 206 die Verknüpfung mit dem Prozeß Taskl 205 durchführt. Zu dem Zeitpunkt tlO erfolgt mit dem Kommando "JOIN_DONE" eine Rückkehr zu dem Prozeß Taskl 205, der zu einem Zeitpunkt tll mit einem Kommando "JOIN END" die Arbeit wiederaufnimmt. Der Prozeß Taskl 205 hat von t8 bis tll gewartet, der Prozeß Task2 206 ist nach tlO beendet.
Die Figuren 2A, 2B und 2C veranschaulichen unterschiedliche Mechanismen, die in einem verteilten System beobachtet werden können, um einen Überblick über die Interaktion von verteilt ablaufenden Programmen und Prozessen zu erhalten. Gerade bei der Fehlersuche oder bei Wartungsarbeiten ist es von unschätzbarem Vorteil, an der interprozessualen Schnittstelle Aktionen mitverfolgen zu können. In Fig.3 ist eine Prozessoreinheit PRZE dargestellt. Die Prozessoreinheit PRZE umfaßt einen Prozessor CPU, einen Speicher SPE und eine Input/Output-Schnittstelle IOS, die über ein Interface IFC auf unterschiedliche Art und Weise genutzt wird: Über eine Grafikschnittstelle wird eine Ausgabe auf einem Monitor MON sichtbar und/oder auf einem Drucker PRT ausgegeben. Eine Eingabe erfolgt über eine Maus MAS oder eine Tastatur TAST. Auch verfügt die Prozessoreinheit PRZE über einen Datenbus BUS, der die Verbindung von einem Speicher
MEM, dem Prozessor CPU und der Input/Output-Schnittstelle IOS gewährleistet. Weiterhin sind an den Datenbus BUS zusätzliche Komponenten anschließbar, z.B. zusätzlicher Speicher, Datenspeicher (Festplatte) oder Scanner.

Claims

Patentansprüche
1. Verfahren zum Überwachen eines Programms, a) bei dem das Programm um einen Instrumentierungsteil erweitert wird; b) bei dem der Instrumentierungsteil eine Nachricht generiert und an einen Überwachungsprozeß übermittelt; c) bei dem der Überwachungsprozeß eine Aktion auslöst.
2. Verfahren nach Anspruch 1, bei dem die Aktion eine der folgenden Möglichkeiten umfaßt : d) Darstellung der Nachricht; e) Eingriff in den Ablauf des Programms; f) Steuerung und/oder Regelung einer mit dem Programm assoziierten Einheit.
3. Verfahren nach Anspruch 1 oder 2, bei dem der Instrumentierungsteil nach Übermittlung der Nachricht auf eine Antwort, die von dem Überwachungsprozeß erzeugt wird, wartet.
4. Verfahren nach Anspruch 3, bei dem die Antwort nach Eingabe eines Benutzers oder durch einen automatisierten Ablauf erstellt wird.
5. Verfahren nach einem der vorhergehenden Ansprüche, bei dem mehrere Nachrichten dargestellt werden als Liste, Baumdiagramm oder als ein Nachrichtenflußdiagramme (Message Sequence Chart, MSC) .
6. Verfahren nach einem der vorhergehenden Ansprüche, bei dem das Programm ein Teil eines größeren Programms ist .
. Verfahren nach einem der vorhergehenden Ansprüche, bei dem eine mit dem Programm assoziierte Funktion instrumentiert wird.
8. Verfahren nach einem der vorhergehenden Ansprüche, bei dem eine mit dem Programm assoziierte Middleware instrumentiert wird.
9. Verfahren nach einem der vorhergehenden Ansprüche, bei dem mindestens einer der folgenden Mechanismen überwacht wird: g) Remote Procedure Call (RPCs) , h) Nachrichtenübermittlung, l) Kontrollfluß.
10. Verfahren nach einem der vorhergehenden Ansprüche, bei dem mehrere Programm in einem verteilten System oder em Programm, das über das System verteilt ist, überwacht wird.
11. Verfahren nach Anspruch 10, bei dem eine Überprüfung einer semantischen Korrektheit mittels vorgegebener Heuristiken erfolgt.
12. Verfahren nach einem der vorhergehenden Ansprüche zum Testen, Steuern oder Warten eines technischen Systems .
13. Anordnung zum Überwachen eines Programms, bei der eine Prozessoreinheit vorgesehen ist, die derart eingerichtet ist, daß j) das Programm um einen Instrumentierungsteil erweiterbar ist; k) der Instrumentierungsteil eine Nachricht generiert und an einen Uberwachungsprozeß übermittelt; 1) der Uberwachungsprozeß eine Aktion auslost.
PCT/DE2000/000626 1999-03-12 2000-03-01 Verfahren und anordnung zum überwachen eines programms Ceased WO2000055733A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CA002366977A CA2366977A1 (en) 1999-03-12 2000-03-01 Method and arrangement for monitoring a program
IL14530400A IL145304A0 (en) 1999-03-12 2000-03-01 Program monitoring method and device
EP00920353A EP1163585A1 (de) 1999-03-12 2000-03-01 Verfahren und anordnung zum überwachen eines programms

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE19911127.8 1999-03-12
DE19911127 1999-03-12

Publications (1)

Publication Number Publication Date
WO2000055733A1 true WO2000055733A1 (de) 2000-09-21

Family

ID=7900787

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2000/000626 Ceased WO2000055733A1 (de) 1999-03-12 2000-03-01 Verfahren und anordnung zum überwachen eines programms

Country Status (4)

Country Link
EP (1) EP1163585A1 (de)
CA (1) CA2366977A1 (de)
IL (1) IL145304A0 (de)
WO (1) WO2000055733A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10118502C1 (de) * 2001-04-12 2002-08-08 Siemens Ag Verfahren zur Erfassung und Aufzeichnung von Systeminformationen und Abläufen in verteilten nebenläufigen komponentenbasierten Softwaresystemen
DE102015117949A1 (de) * 2015-10-21 2017-04-27 Sontheim Industrie Elektronik GmbH Verfahren zur Verfolgung des Verlaufes in einem verteilten System

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0470322A1 (de) * 1990-08-07 1992-02-12 BULL HN INFORMATION SYSTEMS ITALIA S.p.A. Nachrichtenorientierte Fehlerbeseitigungsverfahren
US5307498A (en) * 1992-12-04 1994-04-26 International Business Machines Corporation Automated method for adding hooks to software
US5371746A (en) * 1991-05-31 1994-12-06 Fuji Xerox Co., Ltd. Program debugging system for a distributed data processing system
US5790858A (en) * 1994-06-30 1998-08-04 Microsoft Corporation Method and system for selecting instrumentation points in a computer program

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0470322A1 (de) * 1990-08-07 1992-02-12 BULL HN INFORMATION SYSTEMS ITALIA S.p.A. Nachrichtenorientierte Fehlerbeseitigungsverfahren
US5371746A (en) * 1991-05-31 1994-12-06 Fuji Xerox Co., Ltd. Program debugging system for a distributed data processing system
US5307498A (en) * 1992-12-04 1994-04-26 International Business Machines Corporation Automated method for adding hooks to software
US5790858A (en) * 1994-06-30 1998-08-04 Microsoft Corporation Method and system for selecting instrumentation points in a computer program

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10118502C1 (de) * 2001-04-12 2002-08-08 Siemens Ag Verfahren zur Erfassung und Aufzeichnung von Systeminformationen und Abläufen in verteilten nebenläufigen komponentenbasierten Softwaresystemen
US7665066B2 (en) 2001-04-12 2010-02-16 Siemens Aktiengesellschaft Method for determining and recording system information and function in distributed parallel component based software systems
DE102015117949A1 (de) * 2015-10-21 2017-04-27 Sontheim Industrie Elektronik GmbH Verfahren zur Verfolgung des Verlaufes in einem verteilten System

Also Published As

Publication number Publication date
IL145304A0 (en) 2002-06-30
EP1163585A1 (de) 2001-12-19
CA2366977A1 (en) 2000-09-21

Similar Documents

Publication Publication Date Title
DE69518745T2 (de) Überwachungs- und steuerungsvorrichtung und -verfahren für programme mit einem netzwerk
DE102006021830B4 (de) System und Verfahren zur zeitgesteuerten Programmausführung
DE69712678T2 (de) Verfahren zur Echtzeitüberwachung eines Rechnersystems zu seiner Verwaltung und Hilfe zu seiner Wartung während seiner Betriebsbereitschaft
DE69232255T2 (de) Verfahren und System zum Steuern des Ablaufs eines Anwenderprogramms
EP1110127B1 (de) Informations-, bedien- und/oder beobachtungssystem mit modellbasierter benutzeroberfläche und verfahren zum modellbasierten bedienen und/oder beobachten
DE10308725A1 (de) System und Verfahren zum Verwalten und zum Austausch von Daten eines technischen Projektes, einer technischen Anlage sowie einzelner Anlagenkomponenten
LU93299B1 (de) Ablaufsteuerung von Programmmodulen
DE19617976A1 (de) Kommunikationssystem mit Mitteln zum Austausch von Softwareprozessen
DE10118502C1 (de) Verfahren zur Erfassung und Aufzeichnung von Systeminformationen und Abläufen in verteilten nebenläufigen komponentenbasierten Softwaresystemen
DE112013007637T5 (de) Systementwicklungs-Unterstützungsvorrichtung
WO2020200877A1 (de) Generierung und verteilung von konfigurations-datenstrukturen für steuerungssysteme
WO2000055733A1 (de) Verfahren und anordnung zum überwachen eines programms
WO2008148238A1 (de) Fernbedienung eines browser-programms
WO2006094827A2 (de) Testvorrichtung zur überprüfung einer stapelverarbeitung
DE10230883A1 (de) Automatische Auswertung von Eigenschaften eines Systems auf Basis von Ablaufprotokollen
Schäfer et al. SAP solution manager
DE102008048862A1 (de) Testmodul und Verfahren zum Testen einer O/R-Abbildungs-Middleware
EP1636960B1 (de) Automatisierungssystem mit vereinfachter diagnose und fehlerbehebung
EP1675045A1 (de) Austausch von Beschreibungsdaten zwischen Projekten mit Hilfe von Inter-Project-Interfaces
DE19818041A9 (de) Verfahren zur Erzeugung einer Oberfläche zum Bedienen und Beobachten von Leitsystemen
EP0708941A1 (de) Verfahren zum test eines objektorientierten programms
WO2007147375A1 (de) Verfahren zum betrieb eines automatisierungsgeräts, automatisierungsgerät und automatisierungssystem mit einem solchen automatisierungsgerät
DE10313589A1 (de) Verfahren und Vorrichtung zum Modifizieren von modular aufgebauten Nachrichten
DE102016121542A1 (de) Ablaufsteuerung von Programmmodulen
WO2003003247A2 (de) Integriertes dokumentationssystem mit zeitindiziertem relationalem datenbanksystem

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CA IL US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2000920353

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2366977

Country of ref document: CA

Kind code of ref document: A

WWP Wipo information: published in national office

Ref document number: 2000920353

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 2000920353

Country of ref document: EP