Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
1998-02-18
2001-04-03
Beausoleil, Robert (Department: 2785)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C714S039000, C714S723000
Reexamination Certificate
active
06212653
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field of the Invention
The present invention relates to state driven machines and, in particular, to monitoring state driven machine operation for purposes of trouble-shooting faults, logging events, and post processing of event data for other system operation and maintenance purposes.
2. Description of Related Art
The one or more processes implemented by a system are often designed and represented in a manner well known to those skilled in the art as state driven machines. In this context, a given process may implicate a number of potential states. At each state, the process performs a certain action(s), test(s) or the like, with the result or results therefrom dictating the next state to which the process should transition. There may be more than one transition path into a state, as well as more than one transition path out of a state. Thus, for example, a state “A” may test whether a certain variable matches a predetermined value or a certain signal (or an external action) is received. If yes, the process transitions to state “B”. Otherwise, the process transitions to state “C”. Alternatively, no transition may occur. In each of state “B” or state “C”, another action, test, or the like, occurs resulting perhaps in another transition to yet another state (which may also include a transition back to state “A”).
As these state driven machines become more and more complex, additional instances of faults arise. In some instances, these faults result in the hanging of the process. A hanging scenario refers to a fault where the process enters a certain state and conditions requisite for executing within the state or exiting from the state are never met. For example, the process may enter a state and wait for a certain action that will never arrive in a process situation where that action is needed in order to perform a certain task or move on to another state. If blocks (comprising software units) for the process are state driven, a hanging scenario further refers to a fault where the process enters a certain block in a certain state and the conditions requisite for exiting from the block or its state are never met. When a hanging or other fault occurs, some recovery with continued operation may be possible, but it often becomes necessary to simply restart, reset or reinitialize the system.
Once an occurrence of a fault arises and is recognized, it becomes vitally important to the system operator that the cause of the fault be rapidly discovered and corrected. Sometimes the cause of the fault may be easily discovered in the process of the current state (or block) where the fault occurred. Other times, the fault may be caused at a certain state entered into or at a transition path selected at some point in the distant past (and often times in a completely different block or a completely different process). The cause of faults in such cases is not so easy to ascertain. This is because there may be hundred of possible nodes, and hundreds of possible paths, and associated actions, through which the process passed before the fault manifests itself. All pertinent possible combinations of states and paths and actions must then be examined in order to determine which is the cause. Unfortunately, current technology provides only a snap-shot view (picture) of state driven machine status at the time the fault arises, and this snap-shot view may not provide sufficient information concerning the history of process execution to enable the cause of the fault to be easily determined.
There is a need then for a mechanism to assist in the detection of the cause of a fault in a state driven machine. Preferably, this mechanism should provide sufficient historical information relating to process execution to enable the cause of the fault to be found. The procedure implementing the mechanism should further be capable of running in parallel with normal system operation or execution. Additionally, any captured historical information should be capable of being accessed or retrieved without stopping or staying normal execution of the process.
SUMMARY OF THE INVENTION
A state driven machine is logically sub-divided into a plurality of blocks. Each block includes a sub-set of a total number of processes defining operating states and transition paths for the state driven machine defined process. Plural records (also referred to as individuals) are associated with each block, with each record allocated to a certain one of a plurality of simultaneously supported process executions. A log is maintained on a per process execution basis of certain unique or selected events (such as state transitions and external actions affecting the process) which occur for that execution as it progresses from block to block. Using the information recorded in the log, it is possible to trace back along process execution to identify an origin of a fault in the process implemented by the state driven machine.
In one embodiment of the present invention, the log for a given execution is distributed across the blocks implicated during process execution. Accordingly, each record in a block associated with the process execution logs event information with respect to certain ones of those events occurring during process execution in that block. The given process execution is identified and that identification is shared across each of the records to link the distributed logs together and to their associated process execution. A separate log may further be maintained for each process execution which identifies the particular records maintaining logs that contain event information relating to the process execution.
In another embodiment, a global log for each process execution is maintained. This log stores event information with respect to certain events occurring during a certain process execution, regardless of the block. Again, the given process execution is uniquely identified and that identification is used to distinguish between the global logs maintained for plural simultaneous process executions.
REFERENCES:
patent: 4464543 (1984-08-01), Kline et al.
patent: 4727575 (1988-02-01), Hansen et al.
patent: 5067099 (1991-11-01), McCown et al.
patent: 5128885 (1992-07-01), Janis et al.
patent: 5155842 (1992-10-01), Rubin
patent: 5159685 (1992-10-01), Kung
patent: 5170464 (1992-12-01), Hayes et al.
patent: 5337320 (1994-08-01), Kung
patent: 5379427 (1995-01-01), Hiroshima
patent: 5386464 (1995-01-01), Pruitt
patent: 5428618 (1995-06-01), Ueki et al.
patent: 5434845 (1995-07-01), Miller
patent: 5450439 (1995-09-01), Kato et al.
patent: 5463768 (1995-10-01), Cuddihy et al.
patent: 5533193 (1996-07-01), Roscoe
patent: 5740236 (1998-04-01), Pruitt
patent: 5819094 (1998-10-01), Sato et al.
patent: 5940839 (1999-08-01), Chen et al.
patent: 6009269 (1999-12-01), Burrows et al.
patent: 6041425 (2000-03-01), Kokunishi et al.
Borland,Tools&Utilities Guide,Chapter 5, “Using WinSight” pp. 83-95.
Sun Release 4.1, “User Commands-Trace (1)”, Aug. 8, 1989, pp. 1-2.
Sun Release 4.1, “User Commands-DBX(1)”, Dec. 6, 1989, pp. 1-14.
Ahmed Hanan
Boivin Eric
Prud'Homme Francois
Ragosta Vince
Badesman Scott
Beausoleil Robert
Jenkens & Gilchrist
Telefonaktiebolaget LM Ericsson (publ)
LandOfFree
Logging of events for a state driven machine does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Logging of events for a state driven machine, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Logging of events for a state driven machine will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2495642