Hardware/software lock secure linkage between algorithmic decision process and critical system function execution

• US 6,612,994 B2
• Filed: 03/08/2001
• Issued: 09/02/2003
• Est. Priority Date: 03/08/2001
• Status: Expired due to Fees

• Current Assignee: Cardiac Pacemakers Incorporated (Boston Scientific Corporation)
• Original Assignee: Cardiac Pacemakers Incorporated (Boston Scientific Corporation)
• Inventors: Buchanan, Bryan, Harrington, Tony, Bocek, Joseph M.
• Primary Examiner(s): WOLFE JR, WILLIS RAY
• Application Number:
  US09/802,321
• Publication Number:
  US 20020128562A1
• Time in Patent Office: 908 Days
• Field of Search: 600/508, 600/509, 600/515, 600/519, 600/521, 600/522, 600/523, 607/4, 607/5, 607/7, 607/9, 607/27, 607/28, 607/30, 607/32, 607/60, 713/200, 709/102, 709/103, 709/107, 709/310, 714/1, 714/2, 714/25
• US Class Current: 600/508
• CPC Class Codes: A61N 1/025 Digital circuitry features of electrotherapy devices, e.g. memory, clocks, processors
• CPC Class Codes: A61N 1/37229 Shape or location of the implanted or external antenna
• CPC Class Codes: A61N 1/3956 Implantable devices for applying electric shocks to the heart, e.g. for cardioversion

Abstract

An improved protection mechanism to protect from unintended execution of critical tasks operates, in one example embodiment, by receiving a request to start a task by a first process. The first process informs a second process of running an algorithm to verify the legitimacy of the received request to determine the need to start the task. The second process stores the information regarding the starting the algorithm by the first process. 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. 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 and the first process starts the task.

Claims

1. A system, comprising:

at least one electrode disposed around a heart to sense cardiac signals and to deliver a high-energy electrical therapy to the heart;

a signal sensing circuit coupled to the at least one electrode to receive and amplify the sensed cardiac signals;

a therapy circuit coupled to the at least one electrode to deliver the high-energy electrical therapy to the heart;

a controller coupled to the signal sensing and the therapy circuits, the controller further comprises;

an analyzer coupled to the sensing circuit to receive sensed cardiac signals and analyze the cardiac signals for the presence of a cardiac arrhythmia, and issue a request to start delivering the high-energy electrical therapy based on an outcome of the analysis;

a first processor coupled to the analyzer, the first processor to receive the request to start delivering the high-energy electrical therapy from the analyzer;

an interprocess token coupled to the first processor, wherein the first processor sets an interprocess token upon receiving the request to start delivering the high-energy electrical therapy;

a second processor coupled to the first processor, the second processor to receive a first message from the first processor about running an algorithm to verify a legitimacy of the received request to start delivering the high-energy electrical therapy, wherein the second processor stores the first message, wherein the first processor starts the algorithm to verify the legitimacy of the request to start delivering the high-energy electrical therapy and sends a second message comprising an outcome of the verification to the second processor, and wherein the second processor enables the start of delivering the high-energy electrical therapy by the first processor based on the outcome of the verification; and

a hardware/software lock coupled to the first processor, wherein the first processor unlocks the hardware/software lock to start delivering the high-energy electrical therapy upon enabling by the second processor and further based on the status of the setting of the interprocess token.

2. A method of preventing an inadvertent actuation of a critical task due to a hardware/software failure, comprising:

receiving a request by a first process to start a critical task;

setting an interprocess token by the first process;

informing a second process by the first process of the starting of an algorithm to verify the legitimacy of the request to start the critical task;

storing information regarding starting an algorithm by the second process;

running the algorithm to verify legitimacy of the request to start the critical task;

the first process informing an outcome of the verification to the second process;

when the outcome of the verification is that the request to start the critical task is not legitimate, running an error checking routine;

when the outcome of the verification is that the request to start the critical task is legitimate, enabling the first process to start the critical task;

when the interprocess token is not set, running the error checking routine and clearing the interprocess token by the first process;

when the interprocess token is set, unlocking a hardware/software lock to start the critical task by the first process;

starting the critical task upon unlocking the hardware/software lock; and

clearing the interprocess token after completion of the critical task.

3. A system to prevent inadvertent actuation of a task in the event of a system failure, comprising:

a first processor to receive a request to start a task;

an interprocess token coupled to the first processor, wherein the first processor sets the interprocess token upon receiving the request to start the task;

a second processor coupled to the first processor, the second processor to receive a first message from the first processor about running an algorithm to verify a legitimacy of the received request to start the task, wherein the second processor stores the first message, wherein the first processor starts the algorithm to verify the legitimacy of the request to start the task and sends a second message comprising an outcome of the verification to the second processor, and wherein the second processor enables the start of the task by the first processor based on the outcome of the verification; and

a hardware/software lock, coupled to the first processor, wherein the first processor unlocks the hardware/software lock to start the task upon enabling by the second processor and based on the setting of the interprocess token.

4. The system of claim 3, wherein the first and second processors are microcomputers.

5. The system of claim 3, wherein the system comprises a cardiac rhythm management system.

6. The system of claim 5, further including an error checking routine when the task is not enabled by the second processor.

7. The system of claim 3, further including clearing the interprocess token.

8. The system of claim 3, further including a memory coupled to the first and second processors.

9. The system of claim 8, wherein setting the interprocess token comprises writing to one or more memory locations in the memory.

10. The system of claim 3, wherein the task comprises a critical task.

11. The system of claim 10, wherein the critical task comprises a system critical function.

12. A method comprising:

receiving a request by a first process to start a task;

sending a first message regarding running an algorithm to verify legitimacy of the received request to start the task, the first message sent from the first process to a second process;

recording the first message by the second process;

running the algorithm to verify legitimacy of the request to start the task after sending the first message to the second process;

sending a second message indicating a need to start the task based on an outcome of the verification, the second message sent from the second process to the first process; and

enabling the first process to start the task based on an outcome of checking the receiving of the first message from the first process.

13. The method of claim 12, wherein the system comprises a cardiac rhythm management system.

14. The method of claim 12, wherein the task comprises a critical task.

15. The method of claim 14, wherein the critical task comprises a system critical function.

16. The method of claim 12, further including setting an interprocess token by the first process upon receiving the request to start a task.

17. The method of claim 16, wherein the interprocess token comprises writing to one or more memory locations.

18. The method of claim 17, wherein the first message includes informing the second process of setting the interprocess token by the first process.

19. The method of claim 18, further including recording the setting of the interprocess token by the second process upon receiving information of setting of the interprocess token from the first process.

20. The method of claim 19, wherein the algorithm includes software code to verify the legitimacy of the request to start the task.

21. The method of claim 20, wherein the second message includes requesting permission to start the task based on the outcome of the verification.

22. The method of claim 20, wherein the second message includes an attempt to start the task based on the outcome of the verification.

23. The method of claim 20, wherein the second process enables the start of the task by the first process upon receiving the second message, and based on an outcome of the checking of the status of the interprocess token.

24. The method of claim 20, further including setting a hardware/software lock upon enabling by the second process.

25. The method of claim 24, wherein the setting of the hardware/software lock comprises unlocking of the hardware/software lock to start the task.

26. The method of claim 24, further including clearing the interprocess token after starting the task.

27. The method of claim 24, further comprising:

when the second message indicates the request to start the task is not legitimate, running an error checking routine and clearing the interprocess token;

when the second process does not enable the start of the task by the first process upon checking the status of the interprocess token, running the error checking routine and clearing the interprocess token; and

when the hardware/software lock cannot be unlocked because the interprocess token is not set, running the error checking routine.

28. The method of claim 27, wherein the running the error checking routine comprises running the error checking routine by the first process.