|Publication number||US6789214 B1|
|Application number||US 09/583,984|
|Publication date||Sep 7, 2004|
|Filing date||May 31, 2000|
|Priority date||Jun 10, 1999|
|Publication number||09583984, 583984, US 6789214 B1, US 6789214B1, US-B1-6789214, US6789214 B1, US6789214B1|
|Inventors||Marie-Antoinette de Bonis-Hamelin, Zoltan Menyhart, Jean-Dominique Sorace|
|Original Assignee||Bull, S.A.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (6), Referenced by (48), Classifications (13), Legal Events (4)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The invention relates to a “warm” process for dynamically reconfiguring an information processing system upon detection of a failure of at least one component.
The invention applies more particularly to multiprocessor systems, and even more particularly to symmetric multiprocessor systems of the “SMP” type.
Within the context of the invention, the term “component” should be considered in its most general sense. It includes hardware components, for example a processor in a system of the aforementioned “SMP” type, as well as software components, for example one of the modules of the operating system.
The term “failure” should also be understood in its most general sense. Naturally, it can refer to malfunctioning components. However, within the context of the invention, it most often refers to one or more components having a high risk of actually malfunctioning.
These are generally situations in which a parameter associated with the operation of one of the components of the system moves above or below a predefined critical threshold. To illustrate the concept, let us take the example of the detection and correction of errors in data recorded in a processor's random access memory. It is normal to record redundant data in addition to the data actually used, and to use an error correction mechanism known by the abbreviation “EEC” (for “Error Correcting Code”). This mechanism uses the redundant data to correct the errors detected. However, one may decide, as a preventative measure, to consider all or part of this random access memory to be malfunctioning if the detected error rate passes a predetermined threshold, and to stop using this memory or memory part.
It is easy to see that the “shutdown” of a component, no matter which one, poses a certain number of problems, and cannot be done without certain precautions. This component essentially constitutes what is known as a computing resource (hardware or software) of the information processing system. First of all, if it is currently running (for example processing a task, if it is a processor) or being used by other components of the system, it cannot be shut down immediately. It is necessary for the current operation to finish, or at least be taken over by other components. If not, serious and irrecoverable errors (data losses, etc.) can occur. It is then necessary to isolate the malfunctioning component from the other parts of the system. Finally, it is most often necessary to reconfigure the system while waiting for the defective component to be repaired and/or replaced.
All these operations, especially the last two, require a shutdown of all or part of the system.
For certain applications using what are called high-availability systems, a halt in operation is unacceptable.
Even outside the field of these specific applications, current requirements tend toward this need for high availability.
From the point of view of the user or the client, the concept of high availability often constitutes a major factor in the choice of a system. It is now common to expect continuous operation, i.e., 24 hours a day, 7 days a week.
Hardware is becoming more and more complex and specialized, accordingly requiring higher reliability in order to obtain at least the same availability and life cycle as in the past, given that current requirements tend to increase. These requirements are most critical for the very high-capacity systems known as “mainframes.”
It follows that new maintenance procedures need to be used: all maintenance interventions must henceforth be planned. The object is to disturb the normal operation of the system as little as possible. In fact, any unplanned maintenance generates extremely high costs and/or losses. These losses and costs naturally have a substantial impact on the user or client's confidence.
More particularly, there is a specific problem relative to the hardware components. It is necessary to replace components that are likely to malfunction, which generally requires a shutdown of the machine. But the machine, in keeping with the aforementioned requirements, must continue to operate, which is clearly incompatible.
Also in the prior art, the proposed solutions have tended to favor the aforementioned high availability. For this reason, so-called “hardware” solutions are used. These solutions generally involve a specific configuration, and may require equally specific software drivers.
These solutions can be categorized as follows:
a connection during operation called a “hot plug”: this involves a subassembly of specialized circuits that makes it possible to isolate, disconnect and replace the so-called malfunctioning components;
a machine architecture called a “cluster,” in which several machines work together: if one of the machines malfunctions, another machine belonging to the set replaces it, taking advantage of the fact that the data are redundant and distributed among these machines; and
a (so-called “multipath”) hardware redundancy, in which two or more components work in parallel: if one of the components malfunctions, the other parallel components take over.
This last variant ensures a “two-out-of-three” redundancy.
All of these solutions have drawbacks:
a connection during operation of the “hot plug” type requires the existence of specialized circuits, which in turn generates increased complexity in the system and a corresponding increase in the cost of production, and the method requires special support from the operating system and cannot be applied to existing systems after the fact;
by nature, a “cluster” of machines is constituted by at least two complete machines: the hardware redundancy is therefore substantial and the need to use a specific operating system for this type of system architecture results in a very high cost; and
hardware redundancy is, a priori, the most expensive of the techniques, since it involves multiplying all of the components constituting the system, or at least the majority of them.
The object of the invention is to eliminate the drawbacks of the processes and devices of the prior art, some of which have just been mentioned.
The subject of the invention is a process that makes it possible to meet the needs that have arisen without having the drawback of the processes and devices according to the prior art, some of which have just been mentioned.
According to the process of the invention, it is no longer specifically necessary to provide some type of hardware redundancy.
For this reason, according to a first important characteristic, the process according to the invention comprises steps that, upon detection of a component failure, allow a temporary “freeze” of the system in a way that may be called “warm” or “on the fly,” i.e. to halt, in an orderly fashion, all of the activities in progress at a so-called coherent break point in the system's operation. This “freeze” consists in a mutual exclusion mechanism.
The term “failure” should be understood in the sense indicated above, i.e., generally an estimated failure risk.
Once this state is obtained, a reconfiguration of the system is then performed. In essence, it becomes possible to perform a dynamic reallocation or a de-allocation of any resource of the system, whether hardware or software: processor, memory, software module (including a part of the operating system), or any other component.
To do this, according to another important characteristic of the invention, specific processes or tasks are implemented, which are run in a non-preemptive and synchronized manner, under the control of one of the so-called master processes or of a component serving as such.
The malfunctioning component is then isolated from the system.
Finally, the operating system of the system is released and the system can once again run normally.
It must be clearly understood that all of the preceding steps are transparent for the operating system, for the user (system administrator, etc.) and also for the user applications. It has also been indicated that the malfunctioning component could be one of the modules of the operating system itself.
In practice, the only constraints that apply are the following:
the execution time must be reasonable, i.e., compatible with the type of application in question and/or the type of machine used (operating speed, basic clock cycle, etc.); and
the degradation in performance that results from the reconfiguration (isolation of the component declared to be malfunctioning) should be imperceptible, or at least not very noticeable.
While the first condition is difficult to achieve, it is possible, according to a variant of the process, at least for certain applications, to divide the process into segments. In other words, it takes place in several successive phases, each phase making it possible to perform part of the global process, until it is completed.
In a preferred variant of the invention, the process is applied to multiprocessor systems, particularly to so-called “SMP” systems, as indicated, and even more particularly to an operating system environment of the “UNIX” (registered trademark) type. But it must be clearly understood that the process of the invention applies to the vast majority of information processing system architectures, as long as certain minimum operating characteristics, which will be specified below, are satisfied.
Hence, the subject of the invention is process for reconfiguring an information processing system comprising components forming hardware and software resources, and running under the control of a given operating system, in which at least one so-called user application is being run, characterized in that it comprises at least the following steps:
a preliminary step consisting of detecting a pre-established failure risk in at least one of said components;
a first step consisting, after said detection of a failure risk, of activating at least one specific program for executing a specific job (J1-J4) under the control of said operating system, in a non-preemptive mode, in order to place said information processing system in a predetermined coherent, so-called “frozen” state, in which each of said user applications currently running is halted in an orderly fashion, and no other application is allowed to be run;
a second step for executing said specific job for reconfiguring said information processing system by performing operations for reallocating and/or de-allocating all or some of said components of this system, in order to prepare for the isolation of each of said components for which said pre-established failure risk has been detected;
a third step consisting of isolating each of said components for which said failure risk has been detected, so that it is no longer recognized by said information processing system and no longer constitutes one of said resources; and
a final step for releasing said information processing system, again allowing its operation and the running of at least one of said user applications.
The invention will now be described in greater detail in reference to the attached drawings, in which:
FIG. 1 schematically illustrates an exemplary symmetric multiprocessor architecture of the so-called “SMP” type;
FIG. 2 is a flow chart illustrating the possible choices in the event of a detection of a malfunctioning element in the architecture of FIG. 1;
FIG. 3 illustrates in greater detail the architecture of FIG. 1 for implementing the dynamic reconfiguration process according to the invention;
FIG. 4 is a diagram illustrating the main steps of the dynamic reconfiguration process according to the invention; and
FIG. 5 schematically illustrates one particular step of this process.
Without in any way limiting the scope of the invention, the description will keep to the framework of the preferred application of the invention unless stated otherwise, i.e., to the case of a so-called “SMP” symmetric multiprocessor system, and to an operating system environment of the “UNIX” type.
FIG. 1 schematically illustrates an architecture of this type. The system 1 represented comprises four processors CPU1 through CPU4.
For the simple purpose of illustrating the process, the component of the system 1 that is likely to malfunction will be considered to be one of the processors CPU1 through CPU4. Also, in order to simplify the drawing, the other normal components of the system 1 (shared memory, mass storage, various peripherals, etc.) are not represented. To facilitate the description, it has also been assumed that the system comprises a centralized device 2 for detecting errors. In practice, the detection of the error risk is performed by the potentially malfunctioning component, a hardware or software component, and not by an external device.
As indicated, the detection of the failure risk of one of the components is generally obtained through the monitoring of pre-established parameters and of the passing of given thresholds associated with these parameters, or through similar processes. The device 2 for detecting malfunctioning components communicates with the operating system 3. Also represented in FIG. 1 is an interrupt controller 4. Usually, interrupt signals of given levels are transmitted to the various processors, depending on the type of task to be performed and depending on the peripheral device (not represented) that initiates it.
Let us assume that the processor CPU3 is detected as being a potentially malfunctioning component by the detection device 2.
FIG. 2 is a flow chart representing the alternatives that may be pursued in this circumstance. In 50, the error detection device emits a specific signal indicating that the processor CPU3 has been declared to be malfunctioning. In 51, the operating system can decide to ignore this warning (“YES” branch), which may result in an undesired stoppage or “crash” of the system 1, in which the CPU3 actually does malfunction and may result in a harmful error and/or irreparable damages (data losses, etc.). If the warning is not ignored (“NO” branch), the action performed in 52 can consist either of a deliberate shutdown of the system 1 (in order to perform a deliberate but unprogrammed maintenance operation) in 53, of a “warm” dynamic reconfiguration in 54. If the system is shut down, it is clear that even if the consequences are, a priori, less serious than in the first alternative considered (ignoring the warning), the availability of the system cannot be guaranteed, precisely because of this shutdown. “Warm” dynamic reconfiguration, on the other hand, directly involves the process according to the invention.
Let us now refer to FIG. 3, which illustrates in greater detail than in FIG. 1, the main elements involved in the “warm” dynamic reconfiguration process according to the invention.
The elements common to FIG. 1 have the same references and will only be described again as necessary.
Since the error detection device 2 has detected a failure of the processor CPU3, the latter, according to an important characteristic of the invention, must be deactivated, in other words, isolated from the system 1.
FIG. 3 represents three major “functions” that characterize the operation of an information processing system, i.e., the operating system “OS” 3, a function that will be described as a software function related to the user tasks 6 currently being processed in one or more processors, and a function that will be described as a hardware function related to the external interruptions generated by one or more interrupt controllers, symbolized by a single device 4. Within the context of the invention, the term “task” should be understood in its most general sense. The terminology used also depends on the environment (operating system) in question. The term “task” specifically includes the following English terms and their French equivalents: “process,” “thread,” “task,” or “job.”
For the processor CPU3 to be effectively deactivated, it is necessary for it to be no longer be involved in any of the above functions, or for it to no longer be accessible to them. This state is symbolized by “X” in FIG. 3. However, this is not the only condition to be fulfilled. It is in fact necessary that no further task be executed by this processor until it has been repaired or replaced. It is also necessary that the current tasks be terminated normally, in order to avoid any abnormal operation and/or data loss. It is also necessary for the current interrupts to be processed normally.
Finally, it is necessary to control what is being executed in the other processors, i.e., in the example described, the processors CPU1, CPU2, and CPU4. In essence, in the multiprocessor system 1, one or more processors, for example the processor CPU1, can request access to the tasks currently being processed in the processor CPU3, or can send it a task to perform or data. This risk is even higher in the case of a multiprocessor system of the “SMP” type, i.e., symmetrical as indicated above. The operating system “OS” 3 does not fully control the distribution of the tasks, precisely because of the overall symmetry of the system.
Also, according to a fundamental characteristic of the process according to the invention, the entire system 1 will be “frozen” and not just the component that is malfunctioning or declared to be so. This “freeze,” however, lasts for only a short time lapse. The qualifier “short” should be understood in relation to the nature of the applications run in the system and to other functional characteristics (speed of the processors, cycle time, etc.). According to another important characteristic, the “freeze” of the system 1 is transparent for a user and for the operating system.
FIG. 4 is a flow chart 6 showing the main steps of the process according to the invention.
In 60, the error detection device 2 detects a failure of the processor CPU3, as described above.
The first step 61, which will hereinafter be called the “control” step, specifically consists of obtaining control over the functions indicated above. To do this, during a first step, each of the processors CPU1 through CPU4 is associated with a specific task. These tasks are executed by specific programs or pieces of software, under the control of the operating system “OS” 3. These specific tasks will be called “jobs,” in this case J1 through J4, and more generally J1 through Jn, if the system includes n processors. It must be noted that one job, J3, is associated with the malfunctioning processor CPU3. According to another characteristic, the jobs are of the non-preemptive type, even if the operating system allows this mode of operation. The work is done in the exclusive mode. The jobs are synchronized with one another and are under the control of a so-called “master” component of the system.
Advantageously, it is one of the specific jobs J1 through J4 that plays this role. The synchronization is generally obtained through a central storage device (not represented), which remains in the shared mode. The synchronization can be performed in any known way, for example by means of a bit mask.
This way, the master job waits until the other jobs have finished executing the actions or tasks that are specific to them. It can also distribute tasks to be completed to the other jobs.
The specific jobs must no longer be interrupted by external interruptions. For this reason, the operating system 3 acts on the interrupt controller 4 (FIG. 3).
Through this mechanism, the operation of the system 1 is completely controlled and the latter, in a predictable and orderly way, is placed in a predetermined state.
This state will make it possible to move to the next step, or reconfiguration step 62. During this step, the specific jobs J1 through J4 “reconfigure” the hardware and software architecture of the system 1, in order to adjust to the failure of the processor CPU3. In practice, this translates into the updating of configuration tables or similar elements, and the reallocation of the resources composing the system 1, with a view to deactivating the processor CPU3.
Step 63 consists in the actual isolation of the malfunctioning processor CPU3. The latter is then no longer recognized by the operating system 3 (FIG. 3). In other words, it no longer appears in the list of available resources.
The last step 64 consists in the release of the operating system 3, which allows the system 1 to run again. The external interruptions can then again be transmitted to the remaining processors CPU1, CPU2 and CPU4, and the tasks 6 can be distributed to these processors.
According to another characteristic of the process of the invention, the specific jobs J1 through J4 “self-destruct,” i.e., spontaneously terminate, no later than during the final step 63 for releasing the operating system 3.
In order for the “warm” dynamic reconfiguration process according to the invention to run correctly, it is necessary for the actual “freeze” of the system to be obtained within a maximum time lapse, as indicated. To do this, it is simply necessary to define a time interval predetermined once and for all, or determined as a function of the applications currently running. This time interval is generally called a “timeout.” This parameter is called at the beginning of step 61, or prior to the initiation of the latter, and compared to a time interval signal delivered by an appropriate clock circuit. It must be noted that not all of the functionalities of the system 1 are “frozen,” even if the system is globally frozen in accordance with the primary characteristic of the process of the invention. The majority of the hardware resources continue to run and remain available. This is especially true of the clock signal generating circuits. It is therefore possible, for example, to use one of the counters of the system, fed by clock signals, to determine whether the operations of steps 61 through 63 are included within the time interval allowed.
If the process is too slow and cannot be completed within this allowed time interval, it is possible, in a variant of the process, to “atomize” it, i.e., to break it down into a series of successive temporary “freeze” phases, interspersed with releases of the operating system. Thus, the system 1 is progressively brought to a state that allows the effective isolation of the malfunctioning component, for example the processor CPU3. This is achieved during the final “freeze” phase, after which the operating system is finally released, the new configuration of the system 1, which excludes the defective component, having been obtained.
Generally, it is necessary to perform additional steps. These steps consist not only of terminating the tasks in progress, as mentioned above, but also of executing the tasks waiting to be processed, particularly in the malfunctioning processor CPU3. Moreover, it is also necessary to process the waiting interrupts. If not, the corresponding tasks would run the risk of being irretrievably lost.
FIG. 5 schematically illustrates one of the additional steps. In a customary and well-known way, the system 1 is associated with queues, represented under the general reference 7, which receive a list of priority tasks to be processed. This generally involves storage devices of the “first in first out” or “FIFO” type. These devices determine the order in which the tasks should be processed. It is therefore necessary to perform an operation that will be called a “purge” of the queue 7, in order to clear it. Moreover, to avoid its being refilled, it is also necessary to inhibit the tasks “at the source.” The system 1 is generally equipped with a device called a “dispatcher” 8 (task scheduler) or similar device, whose role is precisely to distribute the tasks to be processed, specifically taking into account their relative priorities. The device 8 is then acted on in order to obtain the aforementioned inhibiting at the source. This action can be performed under the control of one of the specific jobs. The normal operation of this device 8 is again allowed after the release of the operating system (FIG. 4: step 64) Given that by then the system 1 has been reconfigured and the malfunctioning component (the processor CPU3 in the example described) has been de-allocated, the tasks that could have been sent to it are (re-)directed to one of the valid processors CPU1, CPU2 or CPU4.
As for the external interruptions, again referring to FIG. 3, the operation of the interrupt controller 4 need only be temporarily halted, while allowing the current interruptions to be executed. This operation, symbolized by an “X” at the outputs of the interrupt controller 4, can also be performed under the control of one of the specific jobs. As before, the operation of the interrupt controller 4 will again be allowed and the interrupts will again be handled after the release of the operating system (FIG. 4: step 64). The same condition as before applies: new interrupts can no longer be directed to the processor CPU3, which is no longer known to the operating system 3 and hence to the interrupt controller 4 that is under its control.
To illustrate the concepts, without thereby limiting the scope of the invention in any way, one possible practical exemplary implementation of the “warm” dynamic reconfiguration process just described will now be examined in detail, in the case of a symmetric multiprocessor architecture called “MPC,” and in a “UNIX” (registered trademark) or similar operating system environment.
First, upon detection of a failure of one of the processors (or more precisely when a processor is declared to be malfunctioning in the manner described above), a first command or instruction called “freeze system” will be executed. This command can have the configuration of an interrupt instruction, as indicated below:
an instruction in which “freeze_sytem” is the name given to the latter, “m_fun” is a pointer to a function invoked when the system is effectively “frozen” prior to the expiration of a predetermined time limit “time_out”, “cpu” represents the logical number of the processor to which the “freeze_sytem” command is applied, “time_out” is the aforementioned time limit (generally in milliseconds) for obtaining a mutual exclusion, and “arg” is an argument representing a data structure that will be passed to the function “(m_fun)( )”.
When the system has effectively been “frozen,” the function “m_fun” is executed in a processor by the argument “cpu”. If the time limit “time out” expires, it means that the “freeze_sytem” command has failed. The system is then released unconditionally.
This command ensures:
the preemption and the saving of the contexts of the processes (or “threads”) executing tasks, ensuring the proper functioning of the system;
the inhibiting of the interrupts at the interrupt sources, i.e., the interrupt controllers;
the inhibiting of the clock requests, and
the inhibiting of the so-called “MPC” (MultiProcessor Interrupt) mechanism.
All of the waiting interrupt are executed. The system is said to be in a “coherent state.” All of the current tasks are properly terminated.
The system is said to be “frozen.” The function “m_fun” passed in an argument to the command “freeze_system( )” is then able to take control and execute the task incumbent on it, in a protected manner. This task is dedicated, for example, to the dynamic allocation/deallocation of a processor.
The particular processor that executes this function is arbitrarily called the “freeze master.”
The aforementioned “freeze system” function, executed after the actual obtainment of the latter, can create other tasks, also executed during the “system freeze.” These tasks are called “freeze slaves.” They are executed in the other processors, under the control of the master processor (“freeze master”) and an additional command or instruction that can have the following configuration:
an instruction in which “start_freeze_command” is the name given to the instruction, “s_fun” is a pointer to a “freeze slave” function to be executed, “cpu” represents the logical number of the processor in which the function “s_fun” is executed, and “arg” is a pointer to a data structure of the private type. This data structure establishes the communication protocol between the “freeze master” processor and the “freeze slave” processor or processors, so as to obtain the aforementioned synchronization through the private data structure pointed to by “arg”.
If the time limit “time_out” (see command (1)) has not expired prior to the mutual exclusion of the system, i.e., the “system freeze,” the “freeze master” function has the capability to command one of the “freeze slave” processors to execute the function “s_fun( )”. The latter can, for example, modify the private data of one of the processors of the system, including the one in which the “freeze master” command is executed.
A communication protocol is established between the “freeze master” processor and the “freeze slave” processor or processors, or between the tasks being executed in them, which amounts to the same thing.
When all the commands of the “freeze slave” type have terminated, the “freeze master” processor can also terminate its task. A this instant, the “freeze” on the system can be lifted and the system can return to normal operation.
Through the reading of the above, it is easy to see that the invention achieves the objects set forth.
The warm dynamic reconfiguration process according to the invention does not require any hardware redundancy. The hardware and software architecture of the system remains unchanged. It is simply necessary for the system to have error detection means, either hardware or software, which are provided by most information processing systems. Only the operating system needs to be modified in order to support a limited number of specific instructions, and what have been called “specific jobs.”
It should be clear, however, that the invention is not limited to just the exemplary embodiments explicitly described, particularly in connection with FIGS. 1 through 5.
In particular, the numerical values, for example the number of processors, have been indicated only in order to illustrate the concepts. They essentially depend on the precise application referred to.
It should also be clear that even though particularly well adapted to a so-called “MPC” symmetric multiprocessor system in a “UNIX environment, the invention is not limited to this type of application.
Finally, although the process has been described in detail in the case of a detected malfunctioning processor, the process according to the invention, as indicated above, is in no way limited to this particular application. Furthermore, the components that are malfunctioning, in the sense given to this term, can be hardware or software components. Nor is the process according to the invention limited to just one malfunctioning component.
The number of specific jobs activated depends on the nature of the component or components declared to be malfunctioning. In the case of one or more processors of an SMP system that are declared to be malfunctioning, which case has been the subject of a detailed description in order to give a non-limiting example, a specific job is executed by a processor, under the supervision of one of the jobs, called a master. For other types of components, hardware or software, it may be sufficient to execute only one specific job. In the latter case, the problem of synchronizing the execution of the jobs does not arise.
The process according to the invention can be applied to the architectures of a wide variety of information processing systems. The minimum conditions to be fulfilled are limited in number. It is particularly necessary to be able to control the interrupt sources and to be able to inhibit the tasks in a coherent manner, which most computer systems allow.
While this invention has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, the preferred embodiments of the invention as set forth herein, are intended to be illustrative, not limiting. Various changes may be made without departing from the true spirit and full scope of the invention as set forth herein and defined in the claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US3812468||May 12, 1972||May 21, 1974||Burroughs Corp||Multiprocessing system having means for dynamic redesignation of unit functions|
|US4402045 *||Dec 15, 1980||Aug 30, 1983||U.S. Philips Corporation||Multi-processor computer system|
|US5588112 *||Feb 20, 1996||Dec 24, 1996||Digital Equipment Corporation||DMA controller for memory scrubbing|
|US5953530 *||Nov 25, 1997||Sep 14, 1999||Sun Microsystems, Inc.||Method and apparatus for run-time memory access checking and memory leak detection of a multi-threaded program|
|US6105146 *||Jan 6, 1999||Aug 15, 2000||Compaq Computer Corp.||PCI hot spare capability for failed components|
|EP0472864A2||Jul 6, 1991||Mar 4, 1992||Bridgestone/Firestone, Inc.||Coextrusion apparatus and method using an elastic die for varying the outer profile of a tubular extrudate|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7131030||Apr 14, 2003||Oct 31, 2006||Sun Microsystems, Inc.||Method and system for storing field replaceable unit repair history information|
|US7137020 *||Apr 14, 2003||Nov 14, 2006||Sun Microsystems, Inc.||Method and apparatus for disabling defective components in a computer system|
|US7168007||Apr 14, 2003||Jan 23, 2007||Sun Microsystems, Inc.||Field replaceable unit (FRU) identification system tool|
|US7571352||May 18, 2004||Aug 4, 2009||Siemens Aktiengesellschaft||Aspect based recovery system and method|
|US7640453 *||Dec 29, 2006||Dec 29, 2009||Intel Corporation||Methods and apparatus to change a configuration of a processor system|
|US7715930||Sep 27, 2006||May 11, 2010||Rockwell Automation Technologies, Inc.||Aggregating audit information with field conditions|
|US7716334||Apr 14, 2003||May 11, 2010||Oracle America, Inc.||Computer system with dynamically configurable capacity|
|US7725215||May 4, 2006||May 25, 2010||Honeywell International Inc.||Distributed and recoverable digital control system|
|US7765427||May 4, 2006||Jul 27, 2010||Honeywell International Inc.||Monitoring system and methods for a distributed and recoverable digital control system|
|US7793147||Jul 18, 2006||Sep 7, 2010||Honeywell International Inc.||Methods and systems for providing reconfigurable and recoverable computing resources|
|US7971095||Feb 16, 2005||Jun 28, 2011||Honeywell International Inc.||Fault recovery for real-time, multi-tasking computer system|
|US7996843||Sep 5, 2006||Aug 9, 2011||Qnx Software Systems Gmbh & Co. Kg||Symmetric multi-processor system|
|US8200492 *||Apr 2, 2008||Jun 12, 2012||International Business Machines Corporation||Update technique for speech recognition applications with uninterrupted (24X7) operation|
|US8260492||May 4, 2006||Sep 4, 2012||Honeywell International Inc.||Method and system for redundancy management of distributed and recoverable digital control system|
|US8370224||Sep 27, 2006||Feb 5, 2013||Rockwell Automation Technologies, Inc.||Graphical interface for display of assets in an asset management system|
|US8572626||Aug 4, 2011||Oct 29, 2013||Qnx Software Systems Limited||Symmetric multi-processor system|
|US8645955 *||Jun 12, 2007||Feb 4, 2014||Samsung Electronics Co., Ltd.||Multitasking method and apparatus for reconfigurable array|
|US8819484 *||Oct 7, 2011||Aug 26, 2014||International Business Machines Corporation||Dynamically reconfiguring a primary processor identity within a multi-processor socket server|
|US8868894 *||May 4, 2012||Oct 21, 2014||Xcelemor, Inc.||Computing system with hardware scheduled reconfiguration mechanism and method of operation thereof|
|US9038072 *||Dec 10, 2008||May 19, 2015||Xilinx, Inc.||System and method for hardware-software multitasking on a reconfigurable computing platform|
|US9063639||Dec 12, 2012||Jun 23, 2015||Rockwell Automation Technologies, Inc.||Graphical interface for display of assets in an asset management system|
|US9665433||May 8, 2015||May 30, 2017||Rockwell Automation Technologies, Inc.||Graphical interface for display of assets in an asset management system|
|US20030217043 *||Apr 14, 2003||Nov 20, 2003||Sun Microsystems, Inc.||Method and system for storing field replaceable unit dynamic information using tagged data elements|
|US20030217153 *||Apr 14, 2003||Nov 20, 2003||Sun Microsystems, Inc.||Computer system with dynamically configurable capacity|
|US20030217256 *||Apr 14, 2003||Nov 20, 2003||Sun Microsystems, Inc.||Method and apparatus for disabling defective components in a computer system|
|US20030236998 *||Apr 14, 2003||Dec 25, 2003||Sun Microsystems, Inc.||Method and system for configuring a computer system using field replaceable unit identification information|
|US20040049672 *||Jun 2, 2003||Mar 11, 2004||Vincent Nollet||System and method for hardware-software multitasking on a reconfigurable computing platform|
|US20040078634 *||Apr 14, 2003||Apr 22, 2004||Sun Microsystems, Inc.||Field replaceable unit (FRU) identification system tool|
|US20040153686 *||Apr 14, 2003||Aug 5, 2004||Sun Microsystems, Inc.||Method and system for storing field replaceable unit repair history information|
|US20040250155 *||May 19, 2003||Dec 9, 2004||Stefan Weichselbaum||Aspect based recovery system and method|
|US20040250156 *||May 18, 2004||Dec 9, 2004||Siemens Aktiengesellschaft||Aspect based recovery system and method|
|US20060195751 *||Feb 16, 2005||Aug 31, 2006||Honeywell International Inc.||Fault recovery for real-time, multi-tasking computer system|
|US20070033195 *||May 4, 2006||Feb 8, 2007||Honeywell International Inc.||Monitoring system and methods for a distributed and recoverable digital control system|
|US20070033435 *||May 4, 2006||Feb 8, 2007||Honeywell International Inc.||Method and sytem for redundancy management of distributed and recoverable digital control system|
|US20070130567 *||Sep 5, 2006||Jun 7, 2007||Peter Van Der Veen||Symmetric multi-processor system|
|US20070135975 *||May 4, 2006||Jun 14, 2007||Honeywell International Inc.||Distributed and recoverable digital control system|
|US20070288930 *||Jun 12, 2007||Dec 13, 2007||Samsung Electronics Co., Ltd.||Multitasking method and apparatus for reconfigurable array|
|US20080022151 *||Jul 18, 2006||Jan 24, 2008||Honeywell International Inc.||Methods and systems for providing reconfigurable and recoverable computing resources|
|US20080077512 *||Sep 27, 2006||Mar 27, 2008||Rockwell Automation Technologies, Inc.||Graphical interface for display of assets in an asset management system|
|US20080077617 *||Sep 27, 2006||Mar 27, 2008||Rockwell Automation Technologies, Inc.||Universal, hierarchical layout of assets in a facility|
|US20080126377 *||Sep 27, 2006||May 29, 2008||Rockwell Automation Technologies, Inc.||Aggregating audit information with field conditions|
|US20080162982 *||Dec 29, 2006||Jul 3, 2008||Yufu Li||Methods and apparatus to change a configuration of a processor system|
|US20080183477 *||Apr 2, 2008||Jul 31, 2008||International Business Machines Corporation||Update Technique for Speech Recognition Applications with Uninterrupted (24X7) Operation|
|US20090037302 *||Sep 27, 2006||Feb 5, 2009||Rockwell Automation Technologies, Inc.||Programmatically scheduled verification|
|US20090187756 *||Dec 10, 2008||Jul 23, 2009||Interuniversitair Microelektronica Centrum (Imec)||System and method for hardware-software multitasking on a reconfigurable computing platform|
|US20120284492 *||May 4, 2012||Nov 8, 2012||Xcelemor, Inc.||Computing system with hardware scheduled reconfiguration mechanism and method of operation thereof|
|US20130091380 *||Oct 7, 2011||Apr 11, 2013||International Business Machines Corporation||Dynamically Reconfiguring A Primary Processor Identity Within A Multi-Processor Socket Server|
|WO2013156844A1 *||Apr 18, 2013||Oct 24, 2013||Toyota Jidosha Kabushiki Kaisha||Information processing device, information processing method, and storage medium storing program for executing information processing method|
|U.S. Classification||714/15, 714/E11.015, 714/3|
|Cooperative Classification||G06F11/143, G06F11/1482, G06F11/2028, G06F11/2043, G06F2201/81, G06F11/1438, G06F11/2035|
|European Classification||G06F11/14A8C, G06F11/20P2E|
|May 31, 2000||AS||Assignment|
Owner name: BULL S.A., FRANCE
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DE BONIS-HAMELIN, MARIE-ANTOINETTE;SORACE, JEAN-DOMINIQUE;REEL/FRAME:010839/0241
Effective date: 19990617
|Feb 27, 2008||FPAY||Fee payment|
Year of fee payment: 4
|Feb 24, 2012||FPAY||Fee payment|
Year of fee payment: 8
|Feb 25, 2016||FPAY||Fee payment|
Year of fee payment: 12