Browse Prior Art Database

A METHOD FOR DIAGNOSING AND DEBUGGING CRASHED MEDICAL SYSTEMS/WORKSTATIONS LIVE AND REMOTELY

IP.com Disclosure Number: IPCOM000052786D
Publication Date: 2005-Feb-11
Document File: 7 page(s) / 122K

Publishing Venue

The IP.com Prior Art Database

Related People

Sankaralingam Ramraj: INVENTOR [+3]

Abstract

A medical system or workstation typically contains basic computer components such as CPU, hard disk, network interface, I/O peripherals, memory, DSPs, and video controller. Normally, we are able to access the medical system remotely using various methods such as Internet/intranet connections, PC anywhere solutions, Remote Access methods, dial-up connections, or network management station. However, when a system component behaves in an anomalous manner, the system may fail to respond to remote services. For example, the operating system might have halted due to an illegal memory access. Typically, the only recourse available to the user is to power down the system and attempt to restart the system from the powered-down state. Importantly, data that has not been saved from volatile memory to hard disk or non-volatile memory will be permanently lost when the power is removed. Some operating systems display an information screen first before halting; in these systems, the only recourse is to power down the system, or operate a processor-reset button. Current method of diagnosing is to capture the display using video scanner and to send the printout/information for further processing. In any case, it is currently not possible to diagnose or to debug such system live or remotely. To be able to do so is obviously advantageous since much valuable information can only be detected while the system is in its failure state.

This text was extracted from a Microsoft Word document.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 30% of the total text.

Our Docket No.:  2005J01763            

Title:  A METHOD FOR DIAGNOSING AND DEBUGGING

CRASHED MEDICAL SYSTEMS/WORKSTATIONS LIVE AND REMOTELY

Inventor(s):  Sankaralingam Ramraj, Jerry Roelke, Grant Fash III

Sankaralingam Ramraj, Jerry Roelke, Grant Fash

Current Problems:

A medical system or workstation typically contains basic computer components such as CPU, hard disk, network interface, I/O peripherals, memory, DSPs, and video controller. Normally, we are able to access the medical system remotely using various methods such as Internet/intranet connections, PC anywhere solutions, Remote Access methods, dial-up connections, or network management station. However, when a system component behaves in an anomalous manner, the system may fail to respond to remote services. For example, the operating system might have halted due to an illegal memory access. Typically, the only recourse available to the user is to power down the system and attempt to restart the system from the powered-down state. Importantly, data that has not been saved from volatile memory to hard disk or non-volatile memory will be permanently lost when the power is removed. Some operating systems display an information screen first before halting; in these systems, the only recourse is to power down the system, or operate a processor-reset button. Current method of diagnosing is to capture the display using video scanner and to send the printout/information for further processing.  In any case, it is currently not possible to diagnose or to debug such system live or remotely.  To be able to do so is obviously advantageous since much valuable information can only be detected while the system is in its failure state.

Proposed Solution:

Pentium-4 and similar processors are capable of running different operating modes such as real mode, protected mode, virtual-8086 mode, and system management mode. Processor includes system management mode that executes independently of the operating system software. System management mode provides special purpose functionality at a system level including power management, security management and system hardware control.

Processor invokes a system management mode (SMM) when a system management interrupt (SMI) is received. The interrupt handler associated with the SMI causes the processor to save the current state (i.e., the processor’s current context) and switch to an operating environment having a separate address space in a protected area of memory known as system management RAM (SMRAM). While in SMM, the processor executes code and stores data in SMRAM memory space, and may perform various operations, such as, for example, power management, system hardware control, execution of proprietary code, etc. SMM code may be stored in Read Only Memory (ROM). When SMM has completed its programmed functionality, a resume (RSM) instruction may be executed to reload the previously saved processor context and “resume” execution of the interrupted app...