Tracing with keys and locks - Patent Review 5594904

What is claimed:

1. A method for efficiently tracing the execution of one or more software application programs running on a computer system having one or more processors, said efficient tracing method comprising the steps of:

creating a plurality of daemons, each of said daemons having a unique identity and comprising computer program instructions including a conditional statement for activating or deactivating said daemon if a lock value embodied in said daemon is found to match an associated key value;

implanting said plurality of daemons in one or more application programs to render the application programs traceable;

generating key values in response to trace commands received from one or more users of said traceable application programs;

storing said generated key values separately from said traceable application programs in the computer system;

activating or deactivating selected daemons to selectively trace the execution of said traceable application programs in response to the retrieval of a key value satisfying the conditional statements within each of said daemons;

generating trace information relating to the operation of said traceable application programs or the conditional occurrence of related events in response to the activation or deactivation of said daemons without interrupting execution of said traceable application programs; and

storing said generated trace information in the computer system.

2. The efficient tracing method of claim 1 wherein said steps of creating a plurality of daemons embodying locks and of implanting said daemons in application programs further comprise the steps of:

generating computer programming instructions to define the nature of the conditional statement within each of said daemons;

inserting each of said generated computer program instructions into selected application programs to render each of the selected application programs traceable;

compiling each of said traceable application programs;

linking each of said compiled traceable application programs to other application programs and to selected library routines; and

loading each of said linked traceable application programs into the memory of the computer system.

3. The efficient tracing method of claim 1 wherein said step of creating a plurality of daemons embodying locks further comprises the steps of:

generating computer programming instructions to define the nature of the conditional statement within each of said daemons;

compiling each of said daemons; and

loading each of said compiled daemons into the memory of the computer system.

4. The efficient tracing method of claim 3 wherein said step of implanting said plurality daemons is further performed by inserting trap calls in application programs, whereby the execution of the application programs on the computer system is temporarily interrupted upon reaching said trap call, and supplanted by the execution of a daemon that is invoked by said trap call, till all the computer instructions comprising the invoked daemon have been executed, whereupon the execution of said traceable application programs is resumed.

5. The efficient tracing method of claim 1 wherein one or more of said plurality of daemons, upon activation, are capable of invoking themselves or other daemons.

6. The efficient tracing method of claim 1 wherein said step of creating a plurality of daemons further comprises:

creating a daemon group, each daemon in said daemon group containing a group lock that permits all of the daemons in said daemon group to be activated by a common key.

7. The efficient tracing method of claim 1 wherein said key values further comprise words of standardized length operable to activate or deactivate selected daemons.

8. The efficient tracing method of claim 1 wherein said key values further comprise a bit pattern whose length is equal to the total number of daemons within the computer system, each bit in said bit pattern being associated with a unique daemon, and being operable to activate or deactivate the associated daemon if it contains the logical value "1".

9. The efficient tracing method of claim 1 wherein said step of generating trace information relates to the detection of errors in the application programs.

10. The efficient tracing method of claim 1 wherein said step of generating trace information relates to the accumulation of usage statistics concerning the application programs.

11. The efficient tracing method of claim 1 wherein said step of generating trace information relates to the monitoring of the health and stability of application programs.

12. A system for efficiently tracing the execution of one or more software application programs running on a computer system having one or more processors, said efficient tracing system comprising:

means for creating a plurality of daemons, each of said daemons having a unique identity and comprising computer program instructions including a conditional statement for activating or deactivating said daemon if a lock value embodied in said daemon is found to match an associated key value;

means for implanting said plurality of daemons in one or more application programs to render the application programs traceable;

means for generating key values in response to trace commands received from one or more users of said traceable application programs;

means for storing said generated key values separately from said traceable application programs in the computer system;

means for activating or deactivating selected daemons to selectively trace the execution of said traceable application programs in response to the retrieval of a key value satisfying the conditional statements within each of said daemons;

means for generating trace information relating to the operation of said traceable application programs or the conditional occurrence of related events in response to the activation or deactivation of said daemons without interrupting execution of said traceable application programs; and

means for storing said generated trace information in the computer system.

13. The efficient tracing system of claim 12 wherein said means for creating a plurality of daemons embodying locks and for implanting said daemons in application programs further comprise:

means for generating computer programming instructions to define the nature of the conditional statement within each of said daemons;

means for inserting each of said generated computer program instructions into selected application programs to render each of the selected application programs traceable;

means for compiling each of said traceable application programs;

means for linking each of said compiled traceable application programs to other application programs and to selected library routines; and

means for loading each of said linked traceable application programs into the memory of the computer system.

14. The efficient tracing system of claim 12 wherein said means for creating a plurality of daemons embodying locks further comprises:

means for generating computer programming instructions to define the nature of the conditional statement within each of said daemons;

means for compiling each of said daemons; and

means for loading each of said compiled daemons into the memory of the computer system.

15. The efficient tracing system of claim 14 wherein said means for implanting said plurality daemons further comprises trap calls inserted in application programs, whereby the execution of the application programs on the computer system is temporarily interrupted upon reaching said trap call, and supplanted by the execution of a daemon that is invoked by said trap call, till all the computer instructions comprising the invoked daemon have been executed, whereupon the execution of said traceable application programs is resumed.

16. The efficient tracing system of claim 12 wherein one or more of said plurality of daemons, upon activation, are capable of invoking themselves or other daemons.

17. The efficient tracing system of claim 12 wherein said means for creating a plurality of daemons further comprises:

means for creating a daemon group, each daemon in said daemon group containing a group lock that permits all of the daemons in said daemon group to be activated by a common key.

18. The efficient tracing system of claim 12 wherein said key values further comprise words of standardized length operable to activate or deactivate selected daemons.

19. The efficient tracing system of claim 12 wherein said key values further comprise a bit pattern whose length is equal to the total number of daemons within the computer system, each bit in said bit pattern being associated with a unique daemon, and being operable to activate or deactivate the associated daemon if it contains the logical value "1".

20. The efficient tracing system of claim 12 wherein said step of generating trace information relates to the detection of errors in the application programs.

21. The efficient tracing system of claim 12 wherein said step of generating trace information relates to the accumulation of usage statistics concerning the application programs.

22. The efficient tracing system of claim 12 wherein said step of generating trace information relates to the monitoring of the health and stability of application programs.

Description Submit all comments and votes

BACKGROUND OF THE INVENTION

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by any one of the patent documents or the patent disclosure, as it appears in the patent and trademark office, patent file or records, but otherwise reserves all copyrights whatsoever.

FIELD OF THE INVENTION

The invention relates to a telecommunication network and, more particularly, software for tracing with keys and locks on a telecommunication network.

DESCRIPTION OF RELATED ART

Telephone service today is provided to a multiplicity of customers or telephone subscribers through centralized switching. Referring to FIG. 1, a centralized switching machine in a central office 10 controls the switching of calls to and from local telephone subscribers 12 and communicates with other central offices 10 in the network via inter-office trunks 14. Each central office 10, and the subscribers 12 they serve, are linked to other regions by a toll office 16 via toll-connecting trucks 18 as well known in the industry. The central offices 10 can also be connected to customer dedicated switching equipment, such as for example, private automatic branch exchanges (PABX) 20 either directly by business trunks 22 or indirectly by inter-machine trunks 24. The PABX 20 connects other local telephone subscribers 12 to the network, as well as other user terminals such as, for example, computers 26 and facsimile machines (not shown). Such user terminals can also be connected to the central offices 10. The entire network identified generally at 28 in FIG. 1, or any portion thereof, is only one example of a telecommunications network.

Each switch at a central office 10 and toll office 16 and each PABX is typically a stored program control (SPC) exchange 30 including switching equipment 32 and a processor 34 for controlling the switching equipment 32 as shown in FIG. 2. The SPC exchange 30 is connected to the trunks through the switching equipment 32 which services the user terminals as described above. Each SPC exchange 30 must perform certain functions in handling a simple telephone call. For example, the SPC exchange 30 must monitor and sense that a subscriber desires service when the subscriber's telephone goes off-hook to originate a call. Once the SPC exchange 30 recognizes that an origination has taken place, i.e., detects the off-hook status of a given line, the SPC exchange 30 must connect to the trunks for notifying the subscriber, via a dial tone, for example, that the SPC exchange 30 is ready to receive information from the subscriber, and means for receiving this information. Information, e.g., the called number, is entered by the subscriber using a rotary dial or a touch-tone keypad and is received and recorded at the SPC exchange 30. This information must then be interpreted by the SPC exchange 30 to identify the locale of the called line.

If the called party and the calling party are served by the same central office, e.g., telephone subscribers 12(a) through central office 10(a), the call is an intraoffice call. In such case, a busy test is made of the called line, and if the called line is idle, the called party is alerted, e.g., rung via an audible ring tone. The called line is supervised while awaiting an answer by the called party or abandonment by the calling party. If the called party answers, a speech path is established between the parties. The speech path is then supervised during conversation and is disconnected when one of the parties hangs up and the line goes on-hook.

If, on the other hand, the called party is served by a different central office, e.g., subscribers 12(a) and 12(b) through central offices 10(a) and 10(b), the call is an interoffice call. In this case, a search is made for an idle inter-office trunk 14 to the central office 10(b) which serves the called party or to the toll office 16 which is able to further the progress of the call to the central office 10(b) of the called party. Information about the called number is transmitted from the originating central office 10(a) and received by the toll office 16 which delivers the information to the terminating central office 10(b). If the called party's line is busy, or the call is blocked somewhere in the network, or the necessary interoffice trunks are all busy, the calling party is informed via an audible busy, fast busy or reorder tone.

The work to be performed by the SPC exchange 30 falls into two main categories: (1) the routine scanning of user terminals to detect changes, and (2) the complex analysis and diagnostics requiring high computing capacity and large volumes of data. An example of the first category is the checking performed to see if a subscriber 12 has lifted his handset off the telephone. This is done several times every second. Examples of the second category include the selection of ongoing routes or various traffic measurements. As indicated by the examples, the SPC exchange 30 is designed to be responsive to certain events which can be either external, e.g., when a subscriber lifts his handset off-hook, or internal, e.g., instruction steps in the software of the processor 34. The processor's 34 software performs many tasks, including those identified above, which are initiated by a software signal or software message, i.e., a software instruction including relevant data unique to the task. Software signals or software messages can be traced as part of the diagnostics being performed by the SPC exchange 30. When an individual orders the tracing of a software signal, the signal including its data is stored every time the signal is sent for later analysis. Obviously, signal tracing over a long period of time must be avoided, especially during heavy traffic on the telecommunication network, to avoid overloading the capacity of the system.

Thus, a telecommunication network conducts many concurrent tasks in response to events by executing thousands of software instructions on a number of different processors, such as the processor 30 shown in FIG. 2, and storing thousands of software signals by signal tracing in order to detect faults in or debug the software. Because the traffic of the telecommunication network is persistent it requires a "continuous-processing" capability, i.e., the processors 34 cannot be shut down for any reason. As such, this continuous-processing system requires unique fault detection and debugging techniques. Techniques useful for other systems do not work in a telecommunication network. For example U.S. Pat. No. 4,937,864 granted on Jun. 26, 1990, discloses certain debugging techniques used for locating faults in a copier machine. However, this method can only be used when the copier is shut down and, therefore, would not work in a telecommunication network. Normal fault detection and debugging techniques are not suitable for use in a telecommunications network.

Even current tracing systems can be useless for detecting certain categories of faults. Current systems are not sensitive enough to detect a small number of instructions being executed on a processor because the tracing system cannot address certain short-lived threads of instructions between signals. When the fault causes a failure that occurs after a large number of instructions are executed, the same system is too sensitive because it needs to store a long-lasting thread of instructions which exceed the capacity of an SPC exchange. The method and system of the present invention overcome these and other disadvantages and provide enhanced tracing enabling examination of short-lived threads, while at the same-time analyzing long-lasting threads containing a large volume of tracing information with little loss of storage capacity by selectively storing such information.

SUMMARY OF THE INVENTION

In one aspect, the invention relates to discarding irrelevant tracing information to reduce the amount of storage required. Because the storage requirements are reduced, it is possible to view all messages in a trace-thread and the execution of a dedicated program sequence showing the connection between the high-level, application software and the low-level, operating software to solve difficult problems.

This also overcomes the problems associated with many users conducting traces simultaneously. Many users can conduct traces over many different processors without disturbing each other. The invention can also be used to invoke break points for a source-code debugger. The invention could be used to debug a trace-thread at the first phase of the integration test, or to use the trace mechanisms to detect particular events related to certain failures, or identify faults located between high-level and low-level programs.

In another more specific aspect, the invention relates to a method and apparatus for detecting events occurring in a telecommunications network is disclosed which comprises stored program control (SPC) exchanges, each SPC exchange comprising a switch and processors for executing software programs to control the switch. Code sequences, or daemons, are implanted in selected portions of the software programs, each code sequence including a conditional statement responsive to certain events and at least one activity resulting from the detection of a certain event satisfying the conditional statement. A lock value is assigned to each of the code sequences, each lock value uniquely identifies the corresponding code sequences and operates to activate the processor for executing the code sequence. A key value is compared to each lock value for selectively activating the processor to execute the code sequence when the key value equals the lock value. The processor executes the activity specified in the code sequence if the detected event satisfies the conditional statement and continues execution of the software program whereby continuous-processing in the SPC exchange is maintained.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more detailed understanding of the present invention and for further objects and advantages thereof, reference can now be made to the following description taken in conjunction with the accompanying drawings, in which:

FIG. 1 is schematic illustration of a telecommunications network including private and local exchanges on which the present invention can be practiced;

FIG. 2 is a schematic illustration of an SPC exchange comprising a switch and processors as used in the telecommunications network of FIG. 1;

FIG. 2A is a schematic representation of a first embodiment of the SPC exchange shown in FIG. 2;

FIG. 2B is a schematic representation of a second embodiment of the SPC exchange shown in FIG. 2;

FIG. 3A is a block diagram showing the software executed on the processors of the SPC exchange shown in FIG. 2B;

FIG. 3B is a pictorial representation of the software for execution on the processors shown in FIG. 3A including a trace-tool in accordance with the invention;

FIG. 4 is a pictorial representation of a lock and key technique used by the trace-tool of FIG. 3B for thread-tracing in accordance with the invention;

FIG. 5 is a schematic representation of the PABX exchange network of FIG. 1 showing processes used for a phone call in accordance with the invention;

FIG. 6 is a schematic representation of trace-threads propagating through processes being executed on an exchange similar to that disclosed in FIG. 2B;

FIG. 7 is a schematic representation of another set of trace-threads propagating through processes being executed on an exchange similar to that disclosed in FIG. 2B;

FIG. 8 is a schematic representation of yet another set of trace-threads propagating through processes being executed on an exchange similar to that disclosed in FIG. 2B;

FIG. 9 is a schematic representation of any portion of the network of FIG. 1 showing processes used for a phone call in accordance with the invention;

FIG. 10 is a schematic representation of the access, service and traffic control processes of FIG. 9 for handling two phone calls in accordance with the invention;

FIG. 11 is a schematic representation of the access process of FIG. 9 connected to a simple device processor in accordance with the invention;

FIG. 12 is a flow chart showing a process for creating a pre-runtime daemon in accordance with the invention;

FIG. 13 is a flow chart showing a process for creating a runtime daemon in accordance with the invention;

FIG. 14 is a pictorial representation of the program memory in a processor showing the execution of the runtime daemon created in FIG. 13;

FIG. 15 is a pictorial representation of the word method for a single trace;

FIG. 16 is a pictorial representation of the word method for multiple traces;

FIG. 17 is a flow chart showing the key-lock code for the word method shown in FIG. 15;

FIG. 18 is a flow chart showing the key-lock code for the word method shown in FIG. 16;

FIG. 19 is a pictorial representation of the bit method for a single trace;

FIG. 20 is a pictorial representation of the bit method for multiple tracers;

FIG. 21 is a flow chart showing the key-lock code for the bit vector method shown in FIG. 19; and

FIG. 22 is a flow chart showing the key-lock code for the bit vector method shown in FIG. 20.

DETAILED DESCRIPTION

Referring generally to FIGS. 2 and 2A, the SPC exchange 30 can be, for example, the type manufactured by Telefonaktiebolaget L M Ericsson (hereinafter "Ericsson") and referred to as the AXE exchange. The processor 34 of an AXE is shown in more detail in FIG. 2A as comprising one central processor (CP) 35 connected to a plurality of regional processors (RP) 36 communicating with the switching equipment 32. Each regional processor (RP) 36 and the central processor (CP) 35 includes a central processing unit (CPU) and memory (STR). The regional processors (RP) 36 assist the central processor (CP) 35 in performing routine tasks occurring in the SPC exchange 30. All decisions, however, are made by the central processor (CP) 35. This hierarchic structure is described in more detail in a book titled "Getting to Know AXE," EN/LZT 101 548 R2A, published by Ericsson, and incorporated herein by reference. However, the SPC exchange 30 also can be one having a plurality of processors 34 in a distributed, rather than a hierarchic, structure such as the one shown generally at 37 in FIG. 2B comprising common-pool processors (CPP) 38 and dedicated device processor (DP) 39 all communicating directly with the switching equipment 32.

Each common-pooled processor (CPP) 38 and device processor (DP) 39 has its own CPU and STR, and all of them communicate with each other through the switch 32. All of the common-pooled processors (CPP) 38 are of equal importance in the telecommunication network. In such a distributed system, software applications 40-42 (FIG. 3A) are built on a common operating system 43 loaded on top of the processors 37, all of which appear to the operating system 43 as having the same memory core 44. Different applications will require different processors, but they will all run on the same operating system 43. Execution of all applications 40-42 are carried out within a number of different processes (not shown) stored for running on the processors 37. Thus, a process is an environment for executing an application program. For example, the execution of the application 40 might require several processes which cooperate as their functionality is distributed over several processors. Typically, thousands of processes will be running simultaneously on each processor 38, 39.

Referring more specifically to FIG. 3B, the application 40 running on the operating system 43 communicates with the runtime part of the core 44, i.e., the kernel 45, when executing in a process. Thus, the kernel 45 controls the execution of the processes during runtime. All events of interest during the execution of an application are monitored by a trace tool 47 which is a subprogram in the operating system 43 and the kernel 45. The detection of events is made possible by the insertion of code sequences, i.e., daemons 46, at any level in the software as shown by the small circles distributed through the application 40, operating system 43, and the kernel 45. The daemons 46 are located at certain addresses in the code where analysis is required, and always include a predefined set of filter conditions and corresponding actions. An example of such a daemon is as follows:

______________________________________