Surgery – Diagnostic testing – Cardiovascular
Reexamination Certificate
2001-03-08
2003-09-02
Wolfe, Willis R. (Department: 3747)
Surgery
Diagnostic testing
Cardiovascular
Reexamination Certificate
active
06612994
ABSTRACT:
TECHNICAL FIELD
The present invention relates generally to protection mechanisms for execution of system critical functions, and more particularly protection mechanisms for execution of system critical functions in a cardiac rhythm management system.
TECHNICAL BACKGROUND
Given the broad spectrum of usage of microcomputers in controlling subsystems of mission critical systems, it is of utmost importance that the interface between the microcomputers and system elements implementing critical functions remain safe during fault conditions within the microcomputer. Such fault conditions may occur in either hardware or software part of the microcomputers. One such example is an unintended execution of otherwise normal software code due to incorrect state information such as program counter value, corrupt stack pointer or stack contents.
One class of mission critical systems is implantable cardiac rhythm management systems, in which electrical therapy is delivered to the heart. The same therapy sequences that are life sustaining may be life threatening if delivered with inappropriate timing. The decision to deliver electrical therapy generally involves the execution of complex algorithms that must be correctly executed to insure the appropriateness of delivered therapy. In the event of fault conditions that compromise the ability of the system to correctly execute such an algorithm, it is critical that inappropriate therapy be blocked, and that the system operation be restored as quickly as possible.
Generally hardware and software locks are used to protect such system critical functions from inadvertent actuation. It is generally desired that such protection mechanisms be effective and efficient in requiring minimum hardware and software to provide satisfactory protection. Furthermore, it is desirable that the latency to actuation be well controlled and that the interval of time during which a critical task is accessible be short and well defined. Protection mechanisms that are effective in preventing unintended unlocking of actuation due to random processor actions are straightforward. They are generally a unique, necessary, and sufficient sequence of a software code (interacting with hardware), which is sufficiently unlikely to have been replicated either by localized or by non-localized random processor action.
Generally the method employed by mechanisms protecting against inappropriate therapy activation involves providing some degree of complexity in the interface to the hardware that activates the therapy. This can be illustrated, for example, with an interface to a microcomputer, that requires more than one bit be set in the input/output space before activation of the critical therapy can occur. Requiring a specific order or time sequence for setting the bits further restricts possible inadvertent activation, as does placing the bits at different input/output locations. With an interface of sufficient complexity, it is extremely unlikely that random activations of the interface by a malfunctioning subsystem or subsystems will result in therapy delivery.
This protection mechanism can generally be enhanced by placing a time limit on unlocking an actuation of a particular critical task, such that the likelihood of random actuation of that task in combination with the specific code to unlock that task within the requisite time period is even more unlikely. It is important to note that there is a limit to the efficacy of a software code sequence in preventing unintended random unlocking of actuation. To illustrate, assume that the unlocking software sequence is sufficiently improbable that only one occurrence of it exists in a device memory, and that occurrence is an intended key that unlocks the critical task. Further assume that this code fragment is protected from being “run over” by a runaway processor and/or by software reset opcodes that precede it in memory. Under these assumptions, the only single random event that can cause execution of the fragment is if the instruction pointer is somehow pointed exactly at unlocking. This is not altogether an improbable event though the probability of its occurring is generally on the order of 2
−16
or greater. Generally, however, such hardware locks are fairly easy to circumvent and by themselves afford little to no protection against unintended execution. Therefore, there is a need for an improved mechanism to protect from an unintended execution of critical tasks.
SUMMARY OF THE INVENTION
According to one aspect of the present subject matter, a request to start a task is received by a first process. Then the first process informs a second process of running an algorithm to verify the legitimacy of the received request, determining the actual need to start the task. Then the second process stores the information regarding the starting of the algorithm by the first process. Then the first process runs the algorithm to verify the legitimacy of the received request, and conveys an outcome of the verification to the second process. Then the second process enables the start of the task by the first process based on the outcome of the verification and a checking of the stored information. Then the first process starts the task. In one embodiment the first process sets an interprocess token upon receiving the request to start the task. In another embodiment the first process unlocks a hardware/software lock upon enabling by the second process to start the task.
These and other embodiments, aspects, advantages, and features of the present invention will be set forth in part in the description which follows, and in part will become apparent to those skilled in the art by reference to the following description of the invention and referenced drawings or by practice of the invention. The aspects, advantages, and features of the invention are realized and attained by means of the instrumentalities, procedures, and combinations particularly pointed out in the appended claims and their equivalents.
REFERENCES:
patent: 4323966 (1982-04-01), Whiteside et al.
patent: 4476869 (1984-10-01), Bihn
patent: 5113869 (1992-05-01), Nappholz et al.
patent: 5571142 (1996-11-01), Brown et al.
patent: 5660183 (1997-08-01), Chiang et al.
patent: 6021492 (2000-02-01), May
patent: 6266555 (2001-07-01), Werner et al.
patent: 1102155 (2000-05-01), None
Bocek Joseph M.
Buchanan Bryan
Harrington Tony
Cardiac Pacemakers Inc.
Wolfe Willis R.
LandOfFree
Hardware/software lock secure linkage between algorithmic... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Hardware/software lock secure linkage between algorithmic..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Hardware/software lock secure linkage between algorithmic... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3006599