WO2008004330A1 - Système à processeurs multiples - Google Patents

Système à processeurs multiples Download PDF

Info

Publication number
WO2008004330A1
WO2008004330A1 PCT/JP2007/000394 JP2007000394W WO2008004330A1 WO 2008004330 A1 WO2008004330 A1 WO 2008004330A1 JP 2007000394 W JP2007000394 W JP 2007000394W WO 2008004330 A1 WO2008004330 A1 WO 2008004330A1
Authority
WO
WIPO (PCT)
Prior art keywords
processor element
multiprocessor system
processor
failure
priority
Prior art date
Application number
PCT/JP2007/000394
Other languages
English (en)
French (fr)
Inventor
Hiromasa Takahashi
Takashi Chiba
Shunsuke Kamijo
Original Assignee
Fujitsu Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Limited filed Critical Fujitsu Limited
Publication of WO2008004330A1 publication Critical patent/WO2008004330A1/ja

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2028—Failover techniques eliminating a faulty processor or activating a spare
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2035—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant without idle spare hardware
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2051—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant in regular structures

Definitions

  • the present invention relates to a multiprocessor system including a plurality of processor elements, and particularly to a technique for improving the reliability of an embedded multiprocessor system.
  • a server system that requires high reliability, an active processor that executes processing during normal operation, and a standby processor that takes over the processing when a failure occurs in the active processor (for hot standby)
  • the standby processor is powered on during the normal operation of the active processor, but does not perform any substantial processing.
  • Such a server system includes, for example, a plurality of clusters (subsystems including an active processor and a standby processor), a communication path connecting the clusters, a nonvolatile storage system, and monitoring each cluster.
  • a file device that can be shared by all processors is provided using the service processor (SVP) to be controlled. Switching from the active system to the standby system when a failure occurs is automatically performed in a few seconds using the hot standby function.
  • SVP service processor
  • a service processor As a method for detecting a failure in the server system as described above, for example, a configuration in which a hardware failure is detected by incorporating a failure detection circuit in each processor, a service processor (SVP) is used for each processor.
  • a configuration for monitoring the operation is known.
  • the service processor detects a failure in the active system, it changes the software and hardware configuration.
  • Patent Document 4 discloses that in a computer system having a plurality of processors, each processor is equipped with a plurality of OSs, and between the OSs, other OSs A method for monitoring faults is described.
  • Patent Document 5 discloses that when a priority is set in advance for each system in a computer system including a plurality of systems, and a failure is detected in a certain system. Describes a technology that performs reset processing when the time corresponding to the priority of the system has elapsed.
  • An embedded system is an information processing system built in a target device to be controlled, and controls the operation of the device using one or more processors.
  • processors for example, control systems incorporated in aircraft and automobiles.
  • Patent Document 1 Japanese Patent Laid-Open No. 1-991 14
  • Patent Document 2 JP-A-1 _ 2 1 6 4 5 9
  • Patent Document 3 Japanese Patent Laid-Open No. 2_7 1 3 4 7
  • Patent Document 4 Japanese Patent Laid-Open No. 2 0 0 2-2 5 9 1 5 5
  • Patent Document 5 Japanese Patent Laid-Open No. 2 0 0 6 _ 1 1 9 9 2
  • processors used in embedded systems generally have low processing capacity to achieve miniaturization and cost reduction.
  • An object of the present invention is to provide a multiprocessor system that is inexpensive and highly reliable.
  • the multiprocessor system of the present invention comprises a plurality of processor elements, a management means for managing the priority of processing executed by each processor element, a monitoring means for monitoring the state of each processor element, When a failure is detected in the first processor element that is executing the process 1, the process priority information of the management means is referred to, and the second priority that is lower than the first process is referred to. And switching means for causing the second processor element executing the processing to execute the first processing.
  • monitoring means may be provided for each processor element, and each processor element may monitor the state of another processor element. According to this configuration, a dedicated processor for monitoring the state of the processor element is not necessary.
  • a survival information generating means for generating survival information according to a predetermined rule at predetermined time intervals and writing the survival information in a memory area that can be referred to by each processor element.
  • Each processor element may be provided.
  • the monitoring means monitors the state of the reprocessor element by referring to the memory area at a predetermined time interval. According to this configuration, the failure of another processor element can be detected with a simple procedure.
  • FIG. 1 is a diagram for explaining the concept of the present invention.
  • FIG. 2 is a diagram for explaining an embedded system.
  • FIG. 3 is a diagram illustrating a hardware configuration of the multiprocessor system according to the embodiment.
  • FIG. 4 is an example of a dynamic configuration control unit.
  • FIG. 5 is a diagram showing a software configuration of the multiprocessor system of the embodiment.
  • FIG. 6A is an example of an application priority table.
  • FIG. 6B is an example of an updated application priority table.
  • FIG. 7 is an example of a PE status table.
  • FIG. 8 is a flowchart (first embodiment) showing processing of the state manager.
  • FIG. 9 is a flowchart (Example 2) showing processing of the state manager.
  • FIG. 1 is a diagram for explaining the concept of the present invention.
  • PE processor elements
  • the processor elements 1A and 1B each execute a given application (or task).
  • each application is given a priority.
  • processor element 1 A is a processor element (high priority processor element) that executes high-priority processing
  • processor element ⁇ ⁇ ⁇ ⁇ ⁇ 1 B is a processor element (low-level processing) that executes low-priority processing.
  • Priority processor element
  • the storage area 2 holds a PE state table 3 that manages the states of the processor elements 1A and 1B.
  • the storage area 2 is accessible from the processor elements 1A and 1B, and is, for example, the main memory of the processor elements 1A and 1B.
  • the PE status table 3 stores the survival information and self-reported information for each processor element.
  • Each processor element generates survival information and writes it to the PE state table 3 at predetermined time intervals.
  • the “predetermined time interval” is determined according to the time required for detecting a failure of the processor element and the required value of the time for switching the processor element when a failure occurs. It is several milliseconds to several hundred milliseconds. Survival information is generated according to a predetermined rule in each processor element. That is, the period during which the processor element is operating normally is P In E state table 3, the survival information generated by the processor element is updated according to a predetermined rule. On the other hand, if a processor element fails, the survival information corresponding to that processor element in PE state table 3 becomes an inappropriate value. In the following explanation, the operation of generating the survival information and writing it in the storage area 2 is sometimes called “survival notification”.
  • Each processor element checks the status of the other processor elements with reference to the PE status table 3 at predetermined time intervals. In the following explanation, this operation is sometimes called “survival monitoring”. When it is detected that the survival information for a certain processor element in the PE state table is inappropriate, it is determined that the processor element has failed. In addition, if a self-reporting processor element is detected, it is determined that the processor element has failed. Furthermore, when self-reporting is performed via the communication path between PEs, the occurrence of a failure is detected when the self-report signal is received, regardless of the survival monitoring. As described above, in the multiprocessor system of the present invention, when a failure occurs in a certain processor element, the failure is detected by one or more other processor elements.
  • the failed high priority processor element is disconnected from the shared resources of the multiprocessor system and other processor elements. Specifically, for example, access paths such as a memory bus, a communication path between PEs, and an IZO bus are disconnected.
  • the processor element that detects the failure stops the operation of the failed low-priority processor element and resets the low-priority processor element.
  • the failed low-priority processor element is disconnected from the shared resources and other processor elements of the multiprocessor system. Specifically, for example, access paths such as a memory bus, a communication path between PEs, and an IZO bus are disconnected. After this, the application running on the failed low priority processor element is terminated.
  • the processor element that executes the high-priority process fails, the processor that executes the low-priority process.
  • the element takes over and executes the high priority processing. Therefore, high-priority processing continues even if the processor element that executed the high-priority processing fails.
  • This failure recovery function is realized without providing a standby processor element (that is, a processor that does not perform substantial processing while the active processor is operating normally). That is, according to the present invention, a hot standby function is provided substantially without providing a standby processor element.
  • a standby processor element that is, a processor that does not perform substantial processing while the active processor is operating normally. That is, according to the present invention, a hot standby function is provided substantially without providing a standby processor element.
  • the failure recovery and failure recovery speed can be increased through alternative operations. Can be achieved.
  • FIG. 2 is a diagram for explaining an embedded system.
  • the multiprocessor system 11 according to the embodiment of the present invention is not particularly limited, but is used by being incorporated in the control target device 10, for example.
  • the control target device 10 includes a plurality of device elements 12-1 to 12_n.
  • the operations of the device elements 1 2-1 to 1 2 — n are controlled by the multiprocessor system 11 executing a plurality of abrasions in parallel.
  • the multiprocessor system 11 has the functions described with reference to FIG.
  • the multiprocessor system 11 may be configured to display the details of the failure on the display device 13 when a failure occurs in any processor element.
  • FIG. 3 is a diagram illustrating a hardware configuration of the multiprocessor system according to the embodiment.
  • the multiprocessor system of the embodiment is assumed to include four processor elements (P E0 to P E3). In the example shown in FIG. 3, four processor elements are formed on one chip.
  • the multiprocessor system of the present invention may be a multichip type. In this embodiment, it is assumed that the multiprocessor system is incorporated in an automobile safe driving support device.
  • the multiprocessor system of the embodiment includes a processor element (P EO to P E3) 21, a shared memory 22, a nonvolatile memory 23, and a dynamic configuration control unit 24.
  • Processor elements (P E0 to P E3) 2 1 execute applications in parallel with each other.
  • the processor element (P EO) performs forward monitoring processing and the processor element (PE 1).
  • Executes side monitoring processing, processor element (PE2) performs night vision processing, and processor element (PE3) performs driver monitoring processing.
  • the processor elements are connected to each other by a communication path 30 between PEs.
  • the shared memory (external memory) 22 is a storage area accessible from each processor element 21, and stores an OS and an application program.
  • a PE status table 25 and an application priority table 26 are created.
  • the PE state table 25 information indicating the state of each processor element (PE0 to PE3) 21 is written.
  • the application priority table 26 holds information indicating the priority of the application executed by each processor element (PE0 to PE3) 21.
  • the forward monitoring process has the highest priority
  • the side monitoring process has the second highest priority
  • the night vision process has the third highest priority
  • the driver management process has the lowest priority.
  • Each processor element 21 and the shared memory 22 are connected by a crossbar (XB) 27 as a memory bus.
  • XB crossbar
  • a PE state table 25 and an application priority table 26 may be provided in each processor element.
  • the information held by these tables is transmitted / received via the inter-PE communication path 30, for example.
  • the non-volatile memory 23 is a flash memory, for example, and stores various setting values and a configuration control table 28.
  • the configuration control table 28 includes an application priority table 26.
  • Each processor element 21 and the nonvolatile memory 23 are connected by an IZO bus 29.
  • a switch 31 is provided between each processor element 21 and the crossbar 27.
  • a switch 32 is provided between each processor element 21 and the IZO bus 29.
  • each professional Switches 3 3 are respectively provided between the Sessa element 21 and the communication path 30 between the PEs.
  • the dynamic configuration control unit 24 is connected to the communication path 30 between PEs, and in accordance with a command from any processor element, switches 3 1 to 3 3 included in the corresponding processor element are provided. Control. For example, when a failure of the processor element (P E O) is detected, the dynamic configuration control unit 24 controls the switches 31 to 33 of the processor element (P E O) to be turned off. As a result, the failed processor element is separated from the shared resources and other processor elements of the multiprocessor system.
  • FIG. 4 is a diagram showing an example of the dynamic configuration control unit 24.
  • the dynamic configuration control unit 24 receives the control bucket via the communication path 30 between PEs.
  • the control packet addressed to the dynamic configuration control unit 24 includes ID, command, and PE number. “ID” identifies the dynamic configuration control unit 24 as the destination for the control bucket.
  • the command indicates “disconnect”.
  • ⁇ ⁇ ⁇ number ” identifies the failed processor element. This control packet is generated by a processor element that detects a failure of another processor element.
  • the ID holding unit 4 1 holds ID for identifying the dynamic configuration control unit 24.
  • the comparator 42 compares the ID stored in the control bucket ⁇ with the ID stored in the ID holding unit 41. Then, the comparator 42 gives an Enable signal to the input register 43 when the pair of IDs coincide with each other.
  • the command extracted from the control packet and the PE number are written.
  • an enable signal is given from the comparator 42
  • the command and PE number held in the input register 43 are sent to the decoder 44.
  • the decoder 44 analyzes the command and PE number and sends the corresponding control signal to the switch control circuits 45 to 47.
  • the switch control circuit 45 generates a signal for controlling the switch 31 of the processor element corresponding to the PE number stored in the control bucket ⁇ to the OFF state.
  • switch control circuit 46 and 47 generate signals for controlling the switch 32 and 33 of the processor element corresponding to the PE number stored in the control packet to be in the OFF state, respectively.
  • ⁇ number PEO
  • FIG. 5 is a diagram illustrating a software configuration of the multiprocessor system according to the embodiment.
  • a real-time OS runs on each processor element. This real-time OS is assumed to have a communication function between PEs.
  • applications A to D run on the real-time OS.
  • the applications A to D correspond to the forward monitoring process, the side monitoring process, the night vision process, and the driver monitoring process in the example shown in FIG.
  • a state manager (M # 0 to M # 3) is implemented in the multiprocessor system of the embodiment.
  • the state manager (M # 0 to M # 3) performs failure detection processing and failure recovery processing, which will be described in detail later.
  • the forward monitoring process is executed by the processor element (PEO)
  • the side monitoring process is executed by the processor element (PE 1)
  • the night vision process is executed by the processor element.
  • the driver monitoring process is executed by the processor element (PE3).
  • the forward monitoring process has the highest priority
  • the side monitoring process has the second highest priority
  • the night vision process has the third highest priority
  • the driver management process has the lowest priority.
  • Each processor element (PE0 to PE3) executes a state manager program (M # 0 to M # 3). As a result, each processor element (PE0 to PE3) issues a survival notification at a predetermined time interval.
  • the time interval for executing the survival notification is, for example, about several milliseconds to several hundred milliseconds.
  • the survival notification is realized by writing the survival information generated by each processor element (PE0 to PE3) in the PE status table 25.
  • FIG. 7 is an example of the PE status table 25.
  • the PE status table 25 is generated at the same interval as the time when the survival notification is performed.
  • the PE status table at the time table shows the PE status table at the best time T + ta. “T a” corresponds to the time interval at which the survival notification is performed.
  • Survival information is generated in each processor element according to a predetermined rule.
  • Each processor element (PE0 to PE3) has a function to detect its own failure. This function is realized by a check circuit built into each processor element, for example, ECC error of shared memory, It is possible to detect stored memory parity errors, errors associated with execution of illegal instructions, bus parity errors, bus errors, and so on.
  • the processor element When the processor element detects its own failure, it declares the failure. The declaration of a fault is realized by the processor element that detects its own fault writing a fault flag in the PE status table 25. Alternatively, the processor element that detects its own failure may start an exception handling routine and notify other processor elements using the communication path 30 between PEs.
  • Each processor element (PE0 to PE3) performs survival monitoring at a predetermined time interval.
  • the time interval for executing the liveness monitoring may be the same as or different from the time interval of the liveness notification.
  • the time interval between the survival notification and the survival monitoring is the same, and the corresponding survival monitoring is performed at a predetermined timing after the survival notification is executed.
  • each processor element (PE0 to PE3) referring to the PE state table 25, respectively. Specifically, for example, each processor element (PE0 to PE3) reads the latest PE state table and the previous PE state table, and compares the corresponding survival information. At this time, the processor element (PEO) checks the survival information for the processor elements (PE 1 to PE3). Similarly, the processor element (PE 1) checks the survival information for the processor elements (PEO, PE2, PE3), and the processor element (PE2) checks the survival information for the processor elements (PEO, PE 1, PE3). The processor element (PE3) checks the survival information for the processor elements (PE 0 to PE2).
  • the survival information of the processor elements is incremented by “1” from time to time T + ta.
  • the processor elements (PE 1 to PE3) are “normal” It is judged.
  • the survival information of the processor element (PEO) does not change from time to T + ta. In this case, the processor element (PEO) is considered “failed”.
  • the failure of the processor element ⁇ (PEO) is detected by the processor elements (PE 1 to PE3).
  • each processor element refers to the survival information in the PE status table 25, it also refers to the self-reporting information.
  • Self-reporting information basically refers to the latest PE status table.
  • the state of the processor element is checked by comparing the survival information written in two consecutive PE status tables, but it is written in three or more PE status tables.
  • the state of the processor element may be determined based on the existence information.
  • the survival information is generated by incrementing the previous survival information, but the present invention is not limited to this rule. That is, for example, time information generated by a timer included in each processor element may be written in the PE status table 25 for each survival notification timing. Furthermore, if a configuration in which a PE state table 25 is provided in each processor element is introduced, the survival monitoring can be speeded up.
  • Each of the processor elements can detect a failure of the processor element (PEO) by executing the above-described survival monitoring.
  • the processor element (PE1 to PE3) detects a failure of the plug element (PEO)
  • the recovery process basically runs the lowest priority application. It is preferably executed by the executing processor element (here PE3). Therefore, in the following description, the processor element (PE
  • the processor element (PE3) resets the failed processor element (PEO). This stops processor element (PEO) operation.
  • the reset signal is transmitted via the inter-PE communication path 30, for example.
  • the processor element (PE3) generates a control packet and sends it to the dynamic configuration control unit 24.
  • the dynamic configuration control unit 24 controls the switches 31 to 33 included in the processor element (PEO) to be turned off. As a result, the failed processor element (PEO) is disconnected from the crossbar 27, the IZO bus 29, and the communication path 30 between PEs.
  • the processor element (PE3) refers to the application priority table 26, and the priority of the application executed by the processor element (PEO) and the application executed by the processor element (PE3). Compare with the priority of. Here, the priority of the application being executed by the processor element (PE3) is lower. In this case, the processor element (PE3) stops the “driver monitoring process” and executes the “forward monitoring process” executed by the failed processor element (PEO). At this time, the processor element (PE3) designates “forward monitoring process” as the next application to be executed, and then resets itself. As a result, switching of the processor element to execute the application is realized. Alternatively, the processing executed by the processor element (PEO) can be executed by the processor element (PE3) using the task switch mechanism of the real-time OS.
  • the application priority table 26 is stored in the processor element. It is updated to the state shown in Figure 6B by notification from (PE 3) or OS.
  • PE 3 the processor element that has executed the high-priority processing fails
  • the processor element that has executed the low-priority processing takes over and executes the high-priority processing. Therefore, high-priority processing (actually, processing other than the lowest-priority processing) is executed continuously even if a processor element fails, thus realizing a highly reliable multiprocessor system. Is done.
  • the cost of the multiprocessor system can be reduced.
  • FIG. 8 is a flowchart showing the state manager processing.
  • the state manager operates in each processor element.
  • self-assessment shall be made via the communication path 30 between PEs.
  • step S1 a self-failure is checked. For example, its own fault is notified by an interrupt signal (unrecoverable exception) from the check circuit built in the processor element to the state manager. When its own failure is detected, the failure is reported to other processor elements via the communication path 30 between PEs.
  • step S2 the failure declaration from another processor element is checked. When a failure declaration is received from another processor element, the process proceeds to an alternative execution processing routine.
  • Steps S 11 to S 15 are a failure detection processing routine based on survival monitoring.
  • Step S 11 is a process for measuring a predetermined time interval. That is, the failure detection processing routine is executed at predetermined time intervals.
  • a survival notification is executed. As described above, the survival notification is realized by generating the survival information and writing it in the PE status table 25.
  • the PE state table 25 is read.
  • each processor element is compared with the survival information of the latest PE status table and the previous PE status table, and each processor element is normal or has failed. Judge whether or not. As an example, it is determined that a processor element is faulty when a set of compared survival information matches each other. When a failure is detected, the process proceeds to an alternative execution processing routine.
  • Steps S 2 1 to S 2 7 are alternative execution processing routines. This alternative execution processing routine is executed when a failure of another processor element is detected by viability monitoring and when a declaration of failure is received from another processor element.
  • step S 21 a PE number that identifies the failed processor element is detected.
  • step S22 first, the failed processor element is reset and stopped. In addition, disconnect the failed processor element from other processor elements. In this case, a PE number identifying the failed processor element is sent to the dynamic configuration control unit 24. Then, the dynamic configuration control unit 24 controls the switches 31 to 33 included in the failed processor element to be in an off state. As a result, the failed processor element is disconnected from the crossbar, I ZO bus, and the communication path between PEs.
  • step S23 to S24 the application priority table 26 is referenced to confirm the priority of the application executed by the failed processor element. If the priority of the application executed by the failed processor element is the lowest, the process proceeds to step S 27, and if not, the process proceeds to step S 25.
  • step S25 the application executed by the failed processor element is taken over from the failed processor element and executed.
  • step S 26 the application priority table 26 is updated. For example, in the multiprocessor system shown in FIG. When the processor element (PEO) fails, the application priority table 26 is updated from the state shown in FIG. 6A to the state shown in FIG. 6B.
  • PEO processor element
  • the application executed by the failed processor element is not the other processor element. Will be executed.
  • the alternative execution processing routine is, for example, a processor element that executes the lowest priority application or a processor element that has the smallest PE number among the normally operating processor elements. Or by the processor element that first detected the failure. However, if the processor element executing the lowest priority application fails, the alternate execution routine, for example, uses the smallest PE number among the normally operating processor elements. It is executed by the processor element that has it, or the processor element that first detected the failure.
  • failure detection of the first embodiment shown in FIG. 8 is not limited to the configuration including the self-failure detection and the failure detection by the life monitoring.
  • FIG. 9 is a flowchart showing the processing of the state manager according to another embodiment.
  • the failure detection processing routines are the same, but the alternative execution processing routines are different.
  • the flowchart shown in FIG. 9 is an improvement of the flowchart shown in FIG. 8 in consideration of software errors (including program bugs) that occur under special conditions. In other words, software errors that occur under special conditions may not occur after rebooting the processor element. The Therefore, the flowchart shown in Fig. 9 introduces a procedure for rebooting the processor element in which a failure is detected.
  • step S31 the reboot history is referenced to check whether the failed processor element has already been rebooted. If it has not been rebooted, reboot the failed processor element in step S 3 2.
  • step S33 the rebooted processor element re-executes the same application that was executing before the reboot.
  • step S 3 4 the reboot history indicating that a reboot has been performed is written. If the failed processor element has already been rebooted (step S 3 1: Y e s), the process proceeds to step S 2 2.
  • step S35 the processor element that should take over the application that the failed processor element was executing is rebooted, and then the application is executed.
  • the failed processor element re-executes the application that was running before the reboot.
  • the failed processor element executes the lowest priority application being executed by another processor element.
  • the processor element that was executing the application with the lowest priority executes the application that was being executed by the failed processor element before the reboot. According to this procedure, when a fault is detected again in a rebooted processor element, the processor element is It only needs to be disconnected, and no alternative action is required.
  • processor elements when a plurality of memories that can be accessed by each processor element are provided, after stopping a processor element in which a failure related to the memory is detected, Other processor elements may be rebooted using memory other than that determined to be faulty.
  • failure detection of the second embodiment shown in FIG. 9 is not limited to a configuration including self-failure detection and failure detection by survival monitoring.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Hardware Redundancy (AREA)

Description

明 細 書 技術分野
[0001 ] 本発明は、 複数のプロセッサエレメントを備えるマルチプロセッサシステ ムに係わり、 特に、 組込み型マルチプロセッサシステムの信頼性を向上させ る技術に係わる。
背景技術
[0002] 従来より、 高い信頼性を必要とするサーバシステムとして、 正常動作時に 処理を実行する現用系プロセッサ、 及び現用系プロセッサに障害が発生した ときにその処理を引き継ぐ予備系プロセッサ （ホットスタンバイ用プロセッ サ） を備える構成が実用化されている。 ここで、 予備系プロセッサは、 現用 系プロセッサが正常に動作している期間は、 電源は投入されているが、 実質 的な処理は行っていない。 そして、 このようなサーバシステムは、 例えば、 複数のクラスタ （現用系プロセッサおよび予備系プロセッサを含むサブシス テム） を備え、 クラスタ間を接続する通信パス、 不揮発性のストレージシス テム、 各クラスタを監視 Z制御するサービスプロセッサ （S V P ) を利用し て全プロセッサにより共用可能なファイル装置を提供する。 そして、 障害発 生時における現用系から予備系への切替えは、 ホットスタンバイ機能により 、 数秒程度で自動的に行われる。 なお、 ホットスタンバイ機能を提供するサ ーバシステムは、 例えば、 特許文献 1〜3に記載されている。
[0003] 上述のようなサーバシステムにおける故障の検出方法としては、 例えば、 各プロセッサ内に故障検出回路を内蔵することによってハードウエア故障を 検出する構成、 サービスプロセッサ （S V P ) を用いて各プロセッサの動作 を監視する構成が知られている。 この場合、 サービスプロセッサは、 現用系 における故障を検出すると、 ソフトウエアおよびハードウエアの構成を変更 する。 また、 特許文献 4には、 複数のプロセッサを備える計算機システムに おいて、 各プロセッサにそれぞれ複数の O Sを搭載し、 O S間で他の O Sの 故障を監視する方法が記載されている。
[0004] なお、 関連する技術として、 特許文献 5には、 複数の系から構成されるコ ンピュータシステムにおいて各系に対して予め優先度を設定しておき、 ある 系において障害が検出されたときに、 その系の優先度に対応する時間が経過 した時点でリセット処理を行う技術が記載されている。
[0005] ところで、 様々な分野において組込みシステムが広く普及してきている。
組込みシステムは、 制御すべき対象の装置に内蔵される情報処理システムで あって、 1または複数のプロセッサを用いてその装置の動作を制御する。 そ して、 近年では、 高い信頼性を必要とする組込みシステム （例えば、 航空機 や自動車に組み込まれる制御システム等） が要求されている。
[0006] 組込みシステムの信頼性を高める技術としては、 例えば、 3重化されたシ ステムが並列に処理を実行し、 多数決原理に従って最も確からしい処理結果 を選択する構成が知られている。 この構成においては、 特定のシステムが他 の 2つのシステムとは異なる処理結果を繰り返し出力したときに、 その特定 のシステムが切り離される。 また、 他の技術として、 現用系システムの出力 を他のシステムのプロセッサが監視し、 その出力値が予め決められた範囲を 逸脱したときに現用系システムを停止する構成も知られている。
特許文献 1 ：特開平 1 _ 9 9 1 4 1号
特許文献 2：特開平 1 _ 2 1 6 4 5 9号
特許文献 3 :特開平 2 _ 7 1 3 4 7号
特許文献 4：特開 2 0 0 2— 2 5 9 1 5 5号
特許文献 5：特開 2 0 0 6 _ 1 1 9 9 2号
[0007] 組込みシステムの信頼性を高める方法として、 上述したサーバシステムに 適用されている技術を組込みシステムに導入する構成が考えられる。 しかし 、 サーバシステムに適用されている技術においては、 現用系プロセッサの他 に、 正常動作時に実質的に処理を実行しない予備系プロセッサおよび Zまた は各プロセッサを監視するサービスプロセッサを設ける必要がある。 このた め、 この方法を導入すると、 価格の上昇、 実装面積の増加、 消費電力の増加 、 重量の増加を招くこととなり、 組込みシステムとしては不適切である。 ま た、 既存のサーバシステムに適用されているホットスタンバイ機能では、 現 用系から予備系への切替え時間が数秒程度であり、 組込みシステムにおいて 重要なリアルタイム性を保障できないおそれがある。 なお、 制御対象装置の 動作を制御する組込みシステムにおいては、 故障の発生から数ミリ秒 （長く ても、 数百ミリ秒） 以内に復帰処理が要求されることが多い。
[0008] O S間で相互に故障を監視する構成では、 各プロセッサの負荷が重くなリ 、 本来の処理に影響が及ぶおそれがある。 なお、 組込みシステムにおいて使 用されるプロセッサは、 一般に、 小型化 Z低コスト化を実現するためにその 処理能力が低い場合が多い。
[0009] 多数決動作を導入するためにシステムを 3重化する構成では、 リアルタィ ム性は確保できるが、 低コスト化を図ることは困難である。 また、 低コスト 化を図るために 3重化システムを 2重化システムにすると、 故障を検出する ことは可能であるが、 どちらのシステムにおいて故障が発生したのかを判断 できず、 代替動作を行うことができないことがある。
発明の開示
[0010] 本発明の目的は、 低価格で信頼性の高いマルチプロセッサシステムを提供 することである。
本発明のマルチプロセッサシステムは、 複数のプロセッサエレメントを備 える構成であり、 各プロセッサエレメントにより実行される処理の優先度を 管理する管理手段と、 各プロセッサエレメントの状態を監視する監視手段と 、 第 1の処理を実行している第 1のプロセッサエレメントにおいて故障が検 出されたときに、 前記管理手段の処理優先度情報を参照し、 前記第 1の処理 よリも優先度の低い第 2の処理を実行している第 2のプロセッサエレメント に前記第 1の処理を実行させる切替え手段、 を有する。
[0011 ] 上記構成のマルチプロセッサシステムにおいては、 あるプロセッサエレメ ン卜が故障したときに、 その故障したプロセッサエレメントにより実行され ていた処理の優先度が高ければ （あるいは、 その処理の優先度が最低でなけ れば） 、 以降、 その処理は他のプロセッサエレメントにより実行される。 従 つて、 システムの信頼性が向上する。
[0012] 上記マルチプロセッサシステムにおいて、 監視手段を各プロセッサエレメ ン卜にそれぞれ設け、 各プロセッサエレメン卜がそれぞれ他のプロセッサェ レメン卜の状態を監視するようにしてもよい。 この構成によれば、 プロセッ サエレメントの状態を監視するための専用プロセッサは不要である。
[0013] また、 上記マルチプロセッサシステムにおいて、 所定の時間間隔で予め決 められた規則に従って生存情報を生成し、 各プロセッサエレメントが参照可 能なメモリ領域にその生存情報を書き込む生存情報生成手段を各プロセッサ エレメントにそれぞれ設けるようにしてもよい。 この場合、 監視手段は、 所 定の時間間隔で前記メモリ領域を参照することによリプロセッサェレメント の状態を監視する。 この構成によれば、 簡単な手順で他のプロセッサエレメ ン卜の故障を検出することができる。
[0014] このように、 本発明によれば、 低価格で信頼性の高いマルチプロセッサシ ステムを提供することができる。
図面の簡単な説明
[0015] [図 1 ]本発明の概念を説明する図である。
[図 2]組込みシステムについて説明する図である。
[図 3]実施形態のマルチプロセッサシステムのハードウエア構成を示す図であ る。
[図 4]動的構成制御ュニッ卜の実施例である。
[図 5]実施形態のマルチプロセッサシステムのソフトウエア構成を示す図であ る。
[図 6A]アプリケーション優先度テーブルの実施例である。
[図 6B]更新されたアプリケーション優先度テーブルの例である。
[図 7] P E状態テーブルの実施例である。
[図 8]状態マネージャの処理を示すフローチャート （実施例 1 ) である。
[図 9]状態マネージャの処理を示すフローチャート （実施例 2 ) である。 発明を実施するための最良の形態
[0016] 図 1は、 本発明の概念を説明する図である。 なお、 図 1においては、 説明 を簡単にするためにプロセッサエレメント （P E ) を 2つだけ備える構成を 示しているが、 マルチプロセッサシステムを構成するプロセッサエレメン卜 の数は特に限定されるものではない。
[0017] プロセッサエレメント 1 A、 1 Bは、 それぞれ与えられたアプリケーショ ン （または、 タスク） を実行する。 ここで、 各アプリケーションには、 それ ぞれ優先度が設定されている。 図 1に示す例では、 プロセッサエレメント 1 Aにより実行されるアプリケーションの優先度が高く、 プロセッサエレメン 卜 1 Bにより実行されるアプリケーションの優先度が低いものとする。 すな わち、 プロセッサエレメント 1 Aは、 優先度の高い処理を実行するプロセッ サエレメント （高優先プロセッサエレメント） であり、 プロセッサエレメン 卜 1 Bは、 優先度の低い処理を実行するプロセッサエレメント （低優先プロ セッサエレメント） である。
[0018] 記憶領域 2は、 各プロセッサエレメント 1 A、 1 Bの状態を管理する P E 状態テーブル 3を保持する。 ここで、 記憶領域 2は、 各プロセッサエレメン 卜 1 A、 1 Bからアクセス可能であり、 例えば、 プロセッサエレメント 1 A 、 1 Bのメインメモリである。 なお、 P E状態テーブル 3には、 各プロセッ サエレメントについての生存情報および自己申告情報などが格納される。
[0019] 本発明に係るマルチプロセッサシステムの基本動作は、 以下の通りである
( 1 ) 各プロセッサエレメントは、 それぞれ所定の時間間隔ごとに、 生存 情報を生成して P E状態テーブル 3に書き込む。 ここで、 「所定の時間間隔 」 は、 プロセッサエレメントの故障を検出するために要する時間、 および故 障発生時にプロセッサエレメントを切り替えるための時間の要求値に応じて 決定されるものであり、 例えば、 数ミリ秒〜数百ミリ秒である。 また、 生存 情報は、 各プロセッサエレメントにおいて予め決められた規則に従って生成 される。 すなわち、 プロセッサエレメントが正常に動作している期間は、 P E状態テーブル 3において、 そのプロセッサエレメントにより生成される生 存情報は予め決められた規則に従って更新される。 一方、 あるプロセッサェ レメン卜が故障すると、 P E状態テーブル 3において、 そのプロセッサエレ メン卜に対応する生存情報は不適切な値となる。 なお、 以下の説明において 、 生存情報を生成して記憶領域 2に書き込む動作を 「生存通知」 と呼ぶこと がある。
[0020] ( 2 ) 各プロセッサエレメントは、 自己の故障を検出したときには、 その 故障を他のプロセッサエレメントに通知する。 以下の説明では、 この動作の ことを 「自己申告」 と呼ぶものとする。 自己申告は、 自己の故障を検出した プロセッサエレメントが P E状態テーブル 3にその旨を書き込むことにより 実現される。 なお、 自己申告を高速で行う場合には、 プロセッサエレメント 間の通信のために設けられている P E間通信パスを利用して自己申告情報を 他のプロセッサエレメントに送信するようにしてもよい。
[0021 ] ( 3 ) 各プロセッサエレメントは、 それぞれ所定の時間間隔ごとに、 P E 状態テーブル 3を参照し、 他のプロセッサエレメントの状態をチェックする 。 以下の説明では、 この動作のことを 「生存監視」 と呼ぶことがある。 そし て、 P E状態テーブルにおいてあるプロセッサエレメン卜についての生存情 報が不適切であることが検出されると、 そのプロセッサエレメントは故障し ていると判断される。 また、 自己申告をしているプロセッサエレメントが検 出された場合も、 そのプロセッサエレメントは故障していると判断される。 さらに、 P E間通信パスを介して自己申告が行われる場合は、 生存監視とは 無関係に、 自己申告信号を受信した時点で故障の発生が検出される。 このよ うに、 本発明のマルチプロセッサシステムでは、 あるプロセッサエレメント において故障が発生すると、 他の 1または複数のプロセッサエレメントによ リその故障が検出される。
[0022] ( 4 ) 低優先プロセッサエレメントが高優先プロセッサエレメントの故障 を検出した場合は、 以下の動作が行われる。
( 4 - 1 ) 故障を検出したプロセッサエレメントは、 故障した高優先プロセ ッサエレメン卜の動作を停止するとともに、 その高優先プロセッサエレメン 卜をリセッ卜する。
( 4 - 2 ) 故障した高優先プロセッサエレメントは、 マルチプロセッサシス テムの共用資源および他のプロセッサエレメントから切り離される。 具体的 には、 例えば、 メモリバス、 P E間通信パス、 I ZOバス等のアクセスパス が切断される。
( 4 - 3 ) 低優先プロセッサエレメントの動作をいつたん停止した後、 故障 した高優先プロセッサエレメントで実行されていたアプリケーションをその 低優先プロセッサエレメントに実行させる （代替実行） 。
[0023] ( 5 ) 高優先プロセッサエレメントが低優先プロセッサエレメントの故障 を検出した場合は、 以下の動作が行われる。
( 5 - 1 ) 故障を検出したプロセッサエレメントは、 故障した低優先プロセ ッサエレメン卜の動作を停止するとともに、 その低優先プロセッサエレメン 卜をリセッ卜する。
( 5 - 2 ) 故障した低優先プロセッサエレメントは、 マルチプロセッサシス テムの共用資源および他のプロセッサエレメントから切り離される。 具体的 には、 例えば、 メモリバス、 P E間通信パス、 I ZOバス等のアクセスパス が切断される。 この後、 故障した低優先プロセッサエレメントで実行されて いたアプリケーションは終了する。
[0024] このように、 本発明のマルチプロセッサシステムにおいては、 優先度の高 い処理を実行しているプロセッサェレメン卜が故障した場合には、 優先度の 低い処理を実行しているプロセッサエレメントがその高優先処理を引き継い で実行する。 よって、 高優先処理は、 その高優先処理を実行していたプロセ ッサエレメントが故障しても、 継続して実行される。 そして、 この故障回復 機能は、 待機プロセッサエレメント （すなわち、 現用系プロセッサが正常に 動作している期間は、 実質的な処理を行わないプロセッサ） を設けることな く実現される。 すなわち、 本発明によれば、 待機プロセッサエレメントを設 けることなく、 実質的にホットスタンバイ機能が提供される。 [0025] また、 各プロセッサエレメントの状態はそれぞれ他のプロセッサエレメン 卜により監視されるので、 システムの動作を監視するための専用プロセッサ を設ける必要はない。
なお、 LS Iチップ上に形成される記憶領域に P E状態テーブル 3を設け ると共に、 P E間通信パスを介して自己申告を行う構成を導入すれば、 故障 検出および代替動作による故障回復の高速化を図ることができる。
[0026] 図 2は、 組込みシステムについて説明する図である。 本発明の実施形態の マルチプロセッサシステム 1 1は、 特に限定されるものではないが、 例えば 、 制御対象装置 1 0に組み込まれて使用される。 制御対象装置 1 0は、 複数 の装置ェレメント 1 2— 1〜 1 2_nを備える。 そして、 各装置ェレメント 1 2— 1〜 1 2_nの動作は、 マルチプロセッサシステム 1 1が複数のアブ リケーシヨンを並列に実行することにより制御される。 ここで、 マルチプロ セッサシステム 1 1は、 図 1を参照しながら説明した機能を備えている。 な お、 マルチプロセッサシステム 1 1は、 任意のプロセッサエレメントにおい て故障が発生したときに、 その故障内容を表示装置 1 3に表示するようにし てもよい。
[0027] 図 3は、 実施形態のマルチプロセッサシステムのハードウェア構成を示す 図である。 ここでは、 実施形態のマルチプロセッサシステムは、 4個のプロ セッサエレメント （P E0〜P E3) を備えるものとする。 また、 図 3に示 す例では、 4個のプロセッサエレメン卜が 1つのチップ上に形成されている が、 本発明のマルチプロセッサシステムは、 マルチチップ型であってもよい 。 なお、 この実施例では、 マルチプロセッサシステムは、 自動車の安全運転 支援装置に組み込まれているものとする。
[0028] 実施形態のマルチプロセッサシステムは、 プロセッサエレメント （P EO 〜P E3) 2 1、 共有メモリ 22、 不揮発性メモリ 23、 動的構成制御ュニ ッ卜 24を備える。 プロセッサエレメント （P E0〜P E3) 2 1は、 互い に並列にアプリケーションを実行する。 この実施例では、 プロセッサエレメ ント （P EO) は前方監視処理を実行し、 プロセッサエレメント （P E 1 ) は側方監視処理を実行し、 プロセッサエレメント （PE2) はナイトビジョ ン処理を実行し、 プロセッサエレメント （PE3) はドライバー監視処理を 実行するものとする。 また、 プロセッサエレメント間は、 PE間通信パス 3 0により互いに接続されている。
[0029] 共有メモリ （外部メモリ） 22は、 各プロセッサエレメント 21からァク セス可能な記憶領域であり、 O Sおよびアプリケーションプログラムが格納 されている。 また、 共有メモリ 22において、 P E状態テーブル 25および アプリケーション優先度テーブル 26が作成される。 PE状態テーブル 25 は、 各プロセッサエレメント （PE0〜PE3) 21の状態を表す情報が書 き込まれる。 また、 アプリケーション優先度テーブル 26は、 各プロセッサ エレメント （PE0〜PE3) 21により実行されるアプリケーションの優 先度を表す情報を保持する。 この実施例では、 前方監視処理の優先度が最も 高く、 側方監視処理の優先度が 2番目に高く、 ナイトビジョン処理の優先度 が 3番目に高く、 ドライバー管理処理の優先度は最も低いものとする。 なお 、 各プロセッサエレメント 21と共有メモリ 22との間は、 メモリバスとし てのクロスバ （XB) 27により接続されている。
[0030] なお、 各プロセッサエレメント内に PE状態テーブル 25およびアプリケ ーシヨン優先度テーブル 26を設けるようにしてもよい。 この場合、 これら のテーブルにより保持される情報は、 例えば、 PE間通信パス 30を介して 送受信される。
[0031] 不揮発性メモリ 23は、 例えばフラッシュメモリであり、 各種設定値およ び構成制御テーブル 28が格納される。 構成制御テーブル 28は、 アプリケ ーシヨン優先度テーブル 26を含んで構成される。 なお、 各プロセッサエレ メント 21と不揮発性メモリ 23との間は、 I ZOバス 29により接続され ている。
[0032] 各プロセッサエレメント 21とクロスバ 27との間には、 それぞれスイツ チ 31が設けられている。 また、 各プロセッサエレメント 21と IZOバス 29との間には、 それぞれスィッチ 32が設けられている。 さらに、 各プロ セッサエレメント 2 1と P E間通信パス 3 0との間には、 それぞれスィッチ 3 3が設けられている。
[0033] 動的構成制御ユニット 2 4は、 P E間通信パス 3 0に接続されており、 任 意のプロセッサエレメン卜からのコマンドに従って、 対応するプロセッサェ レメン卜が備えるスィッチ 3 1〜3 3を制御する。 例えば、 プロセッサエレ メント （P E O ) の故障が検出されたときは、 動的構成制御ユニット 2 4は 、 そのプロセッサエレメント （P E O ) のスィッチ 3 1〜3 3をオフ状態に 制御する。 これにより、 故障したプロセッサエレメントは、 マルチプロセッ サシステムの共有資源および他のプロセッサエレメントから切り離される。
[0034] 図 4は、 動的構成制御ュニッ卜 2 4の実施例を示す図である。 動的構成制 御ュニッ卜 2 4は、 P E間通信パス 3 0を介して制御バケツ卜を受信する。 動的構成制御ユニット 2 4宛ての制御パケットは、 I D、 コマンド、 P E番 号を含む。 「 I D」 は、 制御バケツ卜の宛先として動的構成制御ュニッ卜 2 4を識別する。 コマンドは 「切断」 を指示する。 Γ Ρ Ε番号」 は、 故障した プロセッサエレメントを識別する。 なお、 この制御パケットは、 他のプロセ ッサエレメントの故障を検出したプロセッサエレメントにより生成される。
[0035] I D保持部 4 1には、 動的構成制御ュニッ卜 2 4を識別する I Dが保持さ れている。 比較器 4 2は、 制御バケツ卜に格納されている I Dと I D保持部 4 1に保持されている I Dとを比較する。 そして、 比較器 4 2は、 それら 1 組の I Dが互いに一致すると、 入力レジスタ 4 3に対して Enab l e信号を与え る。
[0036] 入力レジスタ 4 3には、 制御パケットから抽出されたコマンドおよび P E 番号が書き込まれる。 そして、 比較器 4 2から Enab l e信号が与えられると、 入力レジスタ 4 3に保持されているコマンド及び P E番号はデコーダ 4 4に 送られる。 デコーダ 4 4は、 コマンド及び P E番号を解析し、 対応する制御 信号をスィッチ制御回路 4 5〜 4 7に送る。 スィッチ制御回路 4 5は、 制御 バケツ卜に格納されている P E番号に対応するプロセッサエレメントのスィ ツチ 3 1をオフ状態に制御する信号を生成する。 同様に、 スィッチ制御回路 46、 47は、 それぞれ、 制御パケットに格納されている PE番号に対応す るプロセッサエレメントのスィッチ 32、 33をオフ状態に制御する信号を 生成する。
[0037] 上記構成の動的構成制御ユニット 24は、 例えば、 ΓΡΕ番号 =PEO」 を含む制御パケットを受信すると、 プロセッサエレメント （PEO) が備え るスィッチ 31〜33をオフ状態に制御する信号を生成する。 そうすると、 プロセッサエレメント （PEO) が備えるスィッチ 31〜33はオフ状態に 制御される。 この結果、 プロセッサエレメント （PEO) は、 クロスバ 27 、 1 0バス29、 P E間通信パス 30から切り離される。
[0038] 図 5は、 実施形態のマルチプロセッサシステムのソフトウェア構成を示す 図である。 図 5に示すように、 各プロセッサエレメント上でリアルタイム O Sが動作する。 このリアルタイム OSは、 PE間通信機能を備えているもの とする。 また、 リアルタイム OS上でアプリケーション A〜Dが動作する。 ここで、 アプリケーション A〜Dは、 図 3に示す例では、 それぞれ前方監視 処理、 側方監視処理、 ナイトビジョン処理、 ドライバー監視処理に相当する 。 さらに、 実施形態のマルチプロセッサシステムには、 状態マネージャ （M #0〜M#3) が実装されている。 状態マネージャ （M#0〜M#3) は、 後で詳しく説明するが、 故障検出処理および故障回復処理を実行する。
[0039] 次に、 実施形態のマルチプロセッサシステムの動作を説明する。 なお、 こ こでは、 マルチプロセッサシステムの初期状態において、 前方監視処理がプ 口セッサエレメント （PEO) により実行され、 側方監視処理がプロセッサ エレメント （PE 1 ) により実行され、 ナイトビジョン処理がプロセッサェ レメント （PE2) により実行され、 ドライバー監視処理がプロセッサエレ メント （PE3) により実行されるものとする。 また、 前方監視処理の優先 度が最も高く、 側方監視処理の優先度が 2番目に高く、 ナイトビジョン処理 の優先度が 3番目に高く、 ドライバー管理処理の優先度は最も低いものとす る。 そして、 各アプリケーションの状態を表す情報は、 図 6 Aに示すように 、 アプリケーション優先度テーブル 26に書き込まれている。 [0040] <生存通知 >
各プロセッサエレメント （PE0〜PE3) は、 それぞれ、 状態マネージ ャプログラム （M#0〜M#3) を実行する。 これにより、 各プロセッサェ レメント （PE0〜PE3) は、 所定の時間間隔で生存通知を行う。 生存通 知を実行する時間間隔は、 例えば、 数ミリ秒〜数百ミリ秒程度である。 また 、 生存通知は、 各プロセッサエレメント （PE0〜PE3) によりそれぞれ 生成される生存情報を PE状態テーブル 25に書き込むことにより実現され る。
[0041] 図 7は、 PE状態テーブル 25の実施例である。 PE状態テーブル 25は 、 生存通知が行われる時間間隔と同じ間隔で生成される。 ここで、 時刻丁に おける PE状態テーブルおよい時刻 T+ t aにおける PE状態テーブルを示 している。 なお 「t a」 は、 生存通知が行われる時間間隔に相当する。
[0042] 生存情報は、 各プロセッサエレメントにおいて、 予め決められた規則に従 つて生成される。 生存情報を生成する規則は、 特に限定されるものではない が、 この実施例では 「新たに生成する生存情報 =前回の生存情報 + 1」 であ る。 この場合、 プロセッサエレメントが正常に動作しているものとすると、 時刻 Tにおける生存情報と時刻 T+ t aにおける生存情報との差分は 「1」 になる。 図 7に示す例では、 プロセッサエレメント （PE 1〜PE3) の生 存情報は、 それぞれ 「1」 だけインクリメントされている。 しかし、 故障し たプロセッサエレメントは、 生存通知を行うことができない （或いは、 不適 切な生存情報を生成する） 。 この場合、 時刻 Tにおける生存情報と時刻 T + t aにおける生存情報との差分は 「1」 にはならない。 図 7に示す例では、 プロセッサエレメント （PEO) の生存情報は、 時刻丁〜 T+ t aにおいて 「a」 のまま変化していない。
[0043] <自己申告 >
各プロセッサエレメント （PE0〜PE3) は、 それぞれ、 自己の故障を 検出する機能を備えている。 この機能は、 各プロセッサエレメントに内蔵さ れるチェック回路により実現され、 例えば、 共有メモリの ECCエラー、 内 蔵メモリのパリティエラー、 不正命令の実行に伴うエラー、 バスのパリティ エラー、 バスエラー等を検出することができる。
[0044] プロセッサエレメントは、 自己の故障を検出すると、 その故障を申告する 。 故障の申告は、 自己の故障を検出したプロセッサエレメントが PE状態テ 一ブル 25に故障フラグを書き込むことにより実現される。 あるいは、 自己 の故障を検出したプロセッサエレメン卜が例外処理ルーチンを起動し、 P E 間通信パス 30を利用して他のプロセッサエレメントに通知を行うようにし てもよい。
[0045] <生存監視 >
各プロセッサエレメント （PE0〜PE3) は、 それぞれ、 所定の時間間 隔で生存監視を行う。 生存監視を実行する時間間隔は、 生存通知の時間間隔 と同じであってもよいし、 異なっていてもよい。 この実施例では、 生存通知 および生存監視の時間間隔は互いに同じであり、 生存通知が実行された後の 所定のタイミングで対応する生存監視が行われるものとする。
[0046] 生存監視は、 各プロセッサエレメント （PE0〜PE3) がそれぞれ PE 状態テーブル 25を参照することにより実現される。 具体的には、 たとえば 、 各プロセッサエレメント （PE0〜PE3) は、 最新の PE状態テーブル および 1つ前に生成された P E状態テーブルを読み出し、 対応する生存情報 を比較する。 このとき、 プロセッサエレメント （PEO) は、 プロセッサェ レメント （PE 1〜PE3) について生存情報をチェックする。 同様に、 プ 口セッサエレメント （PE 1 ) はプロセッサエレメント （PEO、 PE2、 PE3) について生存情報をチェックし、 プロセッサエレメント （PE2) はプロセッサエレメント （PEO、 PE 1、 PE3) について生存情報をチ エックし、 プロセッサエレメント （PE3) はプロセッサエレメント （PE 0〜PE2) について生存情報をチェックする。
[0047] 図 7に示す実施例では、 プロセッサエレメント （PE 1〜PE3) の生存 情報は、 時刻丁〜 T+ t aにおいて、 それぞれ 「1」 だけインクリメントさ れている。 この場合、 プロセッサエレメント （PE 1〜PE3) は 「正常」 である判断される。 これに対して、 プロセッサエレメント （PEO) の生存 情報は、 時刻丁〜 T+ t aにおいて変化していない。 この場合、 プロセッサ エレメント （PEO) は 「故障」 と判断される。 なお、 プロセッサエレメン 卜 （PEO) の故障は、 プロセッサエレメント （PE 1〜PE3) によリ検 出される。
[0048] 各プロセッサエレメント （PE0〜PE3) は、 PE状態テーブル 25の 生存情報を参照する際に、 自己申告情報も参照する。 自己申告情報は、 基本 的に、 最新の PE状態テーブルを参照する。
[0049] なお、 上述の例では、 連続する 2つの PE状態テーブルに書き込まれてい る生存情報を比較することよりプロセッサエレメントの状態をチェックして いるが、 3以上の P E状態テーブルに書き込まれている生存情報に基づいて プロセッサエレメントの状態を判断するようにしてもよい。 また、 上述の例 では、 生存情報は前回の生存情報をィンクリメン卜することにより生成され ているが、 本発明はこの規則に限定されるものではない。 即ち、 例えば、 各 プロセッサエレメントがそれぞれ有するタイマが生成する時刻情報を生存通 知タイミング毎に PE状態テーブル 25に書き込むようにしてもよい。 さら に、 各プロセッサエレメント内に PE状態テーブル 25を設ける構成を導入 すれば、 生存監視の高速化を図ることができる。
[0050] <故障の検出および回復 >
図 3に示すマルチプロセッサシステムにおいて、 プロセッサエレメント （ PEO) が故障したものとする。 そうすると、 図 7に示すように、 PE状態 テーブル 25において、 プロセッサエレメント （PEO) の 「生存情報」 は 更新されなくなる。
[0051] プロセッサエレメント （PE 1〜PE3) は、 それぞれ、 上述した生存監 視を実行することにより、 プロセッサエレメント （PEO) の故障を検出す ることができる。 そして、 プロセッサエレメント （PE 1〜PE3) は、 プ 口セッサエレメント （PEO) の故障を検出すると、 下記の回復処理を行う 。 ただし、 回復処理は、 基本的に、 最も優先度の低いアプリケーションを実 行しているプロセッサエレメント （ここでは、 PE3) により実行されるこ とが好ましい。 したがって、 以下の説明では、 プロセッサエレメント （PE
3) によって回復処理が実行されるものとする。
[0052] プロセッサエレメント （PE3) は、 故障したプロセッサエレメント （P EO) をリセットする。 これにより、 プロセッサエレメント （PEO) の動 作は停止する。 ここで、 リセット信号は、 例えば、 PE間通信パス 30を介 して送信される。 また、 プロセッサエレメント （PE3) は、 制御パケット を生成して動的構成制御ュニッ卜 24に送信する。 この制御バケツ卜には、 故障したプロセッサェレメントを識別する情報として ΓΡ E番号 = P E 0」 が格納されている。 そうすると、 動的構成制御ユニット 24は、 プロセッサ エレメント （PEO) が備えるスィッチ 31〜33をオフ状態に制御する。 この結果、 故障したプロセッサエレメント （PEO) は、 クロスバ 27、 I ZOバス 29、 P E間通信パス 30から切り離される。
[0053] 続いて、 プロセッサエレメント （PE3) は、 アプリケーション優先度テ 一ブル 26を参照し、 プロセッサエレメント （PEO) により実行されてい たアプリケーションの優先度とプロセッサエレメント （PE3) が実行して いるアプリケーションの優先度とを比較する。 ここでは、 プロセッサエレメ ント （PE3) が実行しているアプリケーションの優先度の方が低い。 この 場合、 プロセッサエレメント （PE3) は 「ドライバー監視処理」 を停止し 、 故障したプロセッサエレメント （PEO) によって実行されていた 「前方 監視処理」 を実行する。 このとき、 プロセッサエレメント （PE3) は、 次 に実行すべきアプリケーションとして 「前方監視処理」 を指定し、 その後、 自分自身をリセットする。 これにより、 アプリケーションを実行すべきプロ セッサエレメントの切替えが実現される。 あるいは、 リアルタイム OSのタ スクスィッチ機構を利用して、 プロセッサエレメント （PEO) により実行 されていた処理をプロセッサエレメント （PE3) に実行させることも可能 である。
[0054] この後、 アプリケーション優先度テーブル 26は、 プロセッサエレメント ( P E 3 ) または O Sからの通知により、 図 6 Bに示す状態に更新される。 上述のように、 優先度の高い処理を実行していたプロセッサェレメン卜が 故障した場合には、 優先度の低い処理を実行していたプロセッサエレメント がその高優先処理を引き継いで実行する。 したがって、 優先度の高い処理 （ 実際には、 最も優先度の低い処理以外の処理） は、 プロセッサエレメントが 故障しても、 継続して実行されるので、 信頼性の高いマルチプロセッサシス テムが実現される。 また、 待機プロセッサエレメントおよび故障監視のため の専用プロセッサを備える必要がないので、 マルチプロセッサシステムの低 コスト化を図ることができる。
[0055] なお、 生存情報を利用して故障を検出する場合の手順を説明したが、 ある プロセッサエレメントにより申告された故障を他のプロセッサエレメントが 検出した場合も同様の手順でアプリケーションの引継ぎが行われる。
[0056] 図 8は、 状態マネージャの処理を示すフローチャートである。 なお、 状態 マネージャは各プロセッサエレメントにおいてそれぞれ動作する。 また、 こ こでは、 自己申告は、 P E間通信パス 3 0を介して行われるものとする。
[0057] ステップ S 1では、 自分自身の故障をチェックする。 自分自身の故障は、 例えば、 プロセッサエレメントに内蔵されているチェック回路から状態マネ ージャへの割込み信号 （回復不能例外） により通知される。 自分自身の故障 を検出すると、 P E間通信パス 3 0を介して他のプロセッサエレメン卜に対 して故障の申告を行う。 ステップ S 2では、 他のプロセッサエレメントから の故障の申告をチェックする。 そして、 他のプロセッサエレメントから故障 の申告を受信した場合には、 代替実行処理ルーチンに進む。
[0058] ステップ S 1 1〜S 1 5は、 生存監視による故障検出処理ルーチンである 。 ステップ S 1 1は、 所定の時間間隔を計時する処理である。 すなわち、 故 障検出処理ルーチンは、 所定の時間間隔で実行される。 ステップ S 1 2では 、 生存通知が実行される。 生存通知は、 上述したように、 生存情報を生成し て P E状態テーブル 2 5に書き込むことにより実現される。 ステップ S 1 3 では、 P E状態テーブル 2 5を読み出す。 [0059] ステップ S 1 4〜S 1 5では、 各プロセッサエレメントについて最新の P E状態テーブルの生存情報と前回の P E状態テーブルの生存情報と比較し、 各プロセッサエレメントが正常であるのか故障しているのかを判断する。 一 実施例としては、 比較される 1組の生存情報が互いに一致していたときに、 プロセッサエレメントが故障していると判断される。 そして、 故障が検出さ れたときは、 代替実行処理ルーチンに進む。
[0060] ステップ S 2 1〜S 2 7は、 代替実行処理ルーチンである。 この代替実行 処理ルーチンは、 生存監視により他のプロセッサエレメントの故障を検出し たとき、 および他のプロセッサエレメントから故障の申告を受信したときに 実行される。
[0061 ] ステップ S 2 1では、 故障したプロセッサエレメントを識別する P E番号 を検出する。 ステップ S 2 2では、 まず、 故障したプロセッサエレメントを リセットして停止する。 さらに、 その故障したプロセッサエレメントを他の プロセッサエレメントから切り離す。 この場合、 故障したプロセッサエレメ ントを識別する P E番号が動的構成制御ュニッ卜 2 4に送信される。 そうす ると、 動的構成制御ユニット 2 4は、 故障したプロセッサエレメントが備え るスィッチ 3 1〜3 3をオフ状態に制御する。 この結果、 故障したプロセッ サエレメントは、 クロスバ、 I ZOバス、 P E間通信パスから切り離される
[0062] ステップ S 2 3〜S 2 4では、 アプリケーション優先度テーブル 2 6を参 照し、 故障したプロセッサエレメントが実行していたアプリケーションの優 先度を確認する。 そして、 故障したプロセッサエレメントが実行していたァ プリケーシヨンの優先度が最も低かった場合にはステップ S 2 7に進み、 そ うでない場合にはステップ S 2 5に進む。
[0063] ステップ S 2 5では、 故障したプロセッサエレメントにより実行されてい たアプリケーションを、 その故障したプロセッサエレメントから引き継いで 実行する。 そして、 ステップ S 2 6において、 アプリケーション優先度テー ブル 2 6を更新する。 例えば、 図 3に示すマルチプロセッサシステムにおい てプロセッサエレメント （P E O ) が故障した場合には、 アプリケーション 優先度テーブル 2 6は、 図 6 Aに示す状態から図 6 Bに示す状態へ更新され る。
[0064] なお、 故障したプロセッサエレメントが実行していたアプリケーションの 優先度が最も低かった場合には、 そのアプリケーションは他のプロセッサェ レメン卜に引き継がれることはなく、 そのまま終了する。 ただし、 ステップ S 2 7においてアプリケーション優先度テーブル 2 6の更新は行われる。
[0065] このように、 故障したプロセッサエレメントにより実行されていたアプリ ケーションょリも優先度の低いアプリケーションが存在する場合には、 その 故障したプロセッサエレメントにより実行されていたアプリケーションは、 他のプロセッサエレメントに引き継がれて実行される。 なお、 代替実行処理 ルーチンは、 例えば、 最も優先度の低いアプリケーションを実行しているプ 口セッサエレメン卜、 正常に動作しているプロセッサエレメン卜の中で一番 小さい P E番号を持ったプロセッサエレメン卜、 あるいは最初に故障を検出 したプロセッサエレメントにより実行される。 ただし、 最も優先度の低いァ プリケーシヨンを実行しているプロセッサエレメントが故障したときは、 代 替実行処理ルーチンは、 たとえば、 正常に動作しているプロセッサエレメン 卜の中で一番小さい P E番号を持ったプロセッサエレメン卜、 または最初に 故障を検出したプロセッサエレメントにより実行される。
[0066] なお、 図 8に示す実施例 1の故障検出において、 自己故障検出と生存監視 による故障検出とをそれぞれ含む構成に限定されない。
図 9は、 他の実施形態の状態マネージャの処理を示すフローチヤ一卜であ る。 なお、 図 8および図 9に示す手順において、 故障検出処理ルーチンは互 いに同じであるが、 代替実行処理ルーチンは異なっている。
[0067] 図 9に示すフローチャートは、 特殊な条件下で発生するソフトウェアエラ 一 （プログラムのバグを含む） を考慮して、 図 8に示すフローチャートを改良 したものである。 すなわち、 特殊な条件下で発生するソフトウェアエラーは 、 プロセッサエレメントを再ブートすると、 以降、 発生しなくなることがあ る。 そこで、 図 9に示すフローチャートでは、 故障が検出されたプロセッサ ェレメントを再ブー卜する手順が導入されている。
[0068] ステップ S 3 1では、 再ブート履歴を参照し、 故障したプロセッサエレメ ン卜が既に再ブートされているか否かをチェックする。 再ブートされていな ければ、 ステップ S 3 2において、 故障したプロセッサエレメントを再ブー 卜する。 ステップ S 3 3では、 再ブートされたプロセッサエレメントは、 再 ブート前に実行していたアプリケーシヨンと同じアプリケーションを再実行 する。 ステップ S 3 4では、 再ブートを行った旨を表す再ブート履歴に書き 込む。 なお、 故障したプロセッサエレメントが既に再ブートされていた場合 (ステップ S 3 1 ： Y e s ) には、 ステップ S 2 2に進む。
[0069] このように、 図 9に示す手順では、 あるプロセッサエレメントにおいて故 障が検出されると、 そのプロセッサエレメントを再ブートした後に、 アプリ ケーシヨンの実行を再開させる。 この結果、 故障が検出されなくなれば、 い ずれのアプリケーションも停止することなく継続して実行される。 ただし、 再ブー卜してもなお故障が検出されたときは、 ステップ S 2 2以降の処理が 実行される。 このとき、 ステップ S 3 5においては、 故障したプロセッサェ レメン卜が実行していたアプリケーションを引き継ぐべきプロセッサエレメ ン卜が再ブートされ、 その後、 そのアプリケーションが実行される。
[0070] 故障したプロセッサエレメントを再ブートした後のステップ S 3 3におけ るアプリケーションの再実行としては、 下記の 2通りの方法が考えられる。
( 1 ) 故障したプロセッサエレメントは、 再ブート前に実行していたアプリ ケーシヨンを再び実行する。
( 2 ) 故障したプロセッサエレメントは、 他のプロセッサエレメントにより 実行されている最も優先度の低いアプリケーションを実行する。 また、 最も 優先度の低いアプリケーションを実行していたプロセッサエレメントは、 再 ブー卜前にその故障したプロセッサエレメントにより実行されていたアプリ ケーシヨンを実行する。 この手順によれば、 再ブートされたプロセッサエレ メン卜において再び故障が検出されたときは、 そのプロセッサエレメントを 切り離すだけでよく、 代替動作は不要となる。
[0071 ] なお、 実施形態のマルチプロセッサシステムにおいて、 各プロセッサエレ メン卜がアクセス可能な複数のメモリが設けられている場合には、 メモリに 係わる故障が検出されたプロセッサエレメントを停止させた後に、 故障と判 定されたメモリ以外のメモリを使用して他のプロセッサェレメントを再ブー 卜するようにしてもよい。
[0072] なお、 図 9に示す実施例 2の故障検出において、 自己故障検出と生存監視 による故障検出とをそれぞれ含む構成に限定されない。

Claims

請求の範囲
[1 ] 複数のプロセッサエレメントを備えるマルチプロセッサシステムであって 各プロセッサエレメントにより実行される処理の優先度を管理する管理手 段と、
各プロセッサエレメントの状態を監視する監視手段と、
第 1の処理を実行している第 1のプロセッサエレメントにおいて故障が検 出されたときに、 前記管理手段の処理優先度情報を参照し、 前記第 1の処理 よリも優先度の低い第 2の処理を実行している第 2のプロセッサエレメント に前記第 1の処理を実行させる切替え手段と、
を有するマルチプロセッサシステム。
[2] 請求項 1に記載のマルチプロセッサシステムであって、
前記監視手段は、 各プロセッサエレメントに設けられ、 それぞれ他のプロ セッサェレメン卜の状態を監視する
ことを特徴とするマルチプロセッサシステム。
[3] 請求項 2に記載のマルチプロセッサシステムであって、
各プロセッサエレメントに設けられ、 それぞれ所定の時間間隔で予め決め られた規則に従って生存情報を生成し、 各プロセッサエレメントが参照可能 なメモリ領域にその生存情報を書き込む生存情報生成手段をさらに備え、 前記監視手段は、 所定の時間間隔で前記メモリ領域を参照することにより プロセッサェレメン卜の状態を監視する
ことを特徴とするマルチプロセッサシステム。
[4] 請求項 3に記載のマルチプロセッサシステムであって、
前記生存情報が書き込まれるメモリ領域が各プロセッサエレメント内にそ れぞれ設けられる
ことを特徴とするマルチプロセッサシステム。
[5] 請求項 1に記載のマルチプロセッサシステムであって、
各プロセッサエレメン卜に設けられ、 当該プロセッサエレメン卜の故障を 検出して他のプロセッサェレメン卜に申告する申告手段をさらに備え、 前記監視手段は、 前記申告手段による申告に基づいてプロセッサエレメン 卜の故障を検出する
ことを特徴とするマルチプロセッサシステム。
[6] 請求項 5に記載のマルチプロセッサシステムであって、
前記申告手段によリ生成される申告データは、 共有メモリを介することな く、 プロセッサエレメント間通信パスを介して送信される
ことを特徴とするマルチプロセッサシステム。
[7] 請求項 5に記載のマルチプロセッサシステムであって、
前記申告手段は、 メモリの E C Cエラー、 メモリまたはバスのパリティェ ラー、 不正な命令の実行、 不正な記憶領域のアクセスを検出したときに、 プ 口セッサエレメン卜の故障を申告する
ことを特徴とするマルチプロセッサシステム。
[8] 請求項 1に記載のマルチプロセッサシステムであって、
前記切替え手段は、 故障が検出された第 1のプロセッサェレメントを停止 し、 その第 1のプロセッサエレメントが実行していた第 1の処理を、 前記第 2のプロセッサエレメン卜に実行させる
ことを特徴とするマルチプロセッサシステム。
[9] 請求項 8に記載のマルチプロセッサシステムであって、
前記第 1のプロセッサエレメントの故障が検出されたときに前記第 2のプ 口セッサエレメントにより実行されていた前記第 2の処理は、 動作中のプロ セッサエレメントにより実行されている複数の処理の中で最も優先度が低い ことを特徴とするマルチプロセッサシステム。
[10] 請求項 1に記載のマルチプロセッサシステムであって、
前記切替え手段は、 故障が検出された第 1のプロセッサェレメン卜が実行 している第 1の処理よリも優先度の低い処理が存在しない場合には、 その第 1のプロセッサエレメントの処理を停止してその第 1の処理を終了する ことを特徴とするマルチプロセッサシステム。
[11 ] 請求項 1に記載のマルチプロセッサシステムであって、
故障が検出された第 1のプロセッサエレメントを再ブー卜する再ブー卜手 段をさらに備える
ことを特徴とするマルチプロセッサシステム。
[12] 請求項 1 1に記載のマルチプロセッサシステムであって、
前記切替え手段は、 前記再ブート手段による再ブートの後に、 前記第 1の 処理を前記第 2のプロセッサエレメントに実行させるとともに、 前記第 2の 処理を前記第 1のプロセッサエレメントに実行させる
ことを特徴とするマルチプロセッサシステム。
[13] 請求項 1に記載のマルチプロセッサシステムであって、
各プロセッサエレメン卜とメモリバスとの間、 各プロセッサエレメン卜と プロセッサエレメント間通信パスとの間、 および各プロセッサエレメントと I ZOバスとの間にそれぞれ設けられるスィッチと、
前記切替え手段からの指示に応じて前記スィッチを制御する構成制御手段 をさらに備える
ことを特徴とするマルチプロセッサシステム。
[14] 請求項 1 3に記載のマルチプロセッサシステムであって、
前記切替え手段から前記構成制御手段への指示は、 前記プロセッサエレメ ント間通信パスを介して送信される
ことを特徴とするマルチプロセッサシステム。
[15] 請求項 1に記載のマルチプロセッサシステムであって、
プロセッサエレメントの故障により停止した処理に係わる情報を表示する 表示手段をさらに備える
ことを特徴とするマルチプロセッサシステム。
[16] 請求項 1に記載のマルチプロセッサシステムであって、
プロセッサエレメントの故障により停止した処理に係わる情報を格納する 不揮発性メモリをさらに備える
ことを特徴とするマルチプロセッサシステム。
[17] 請求項 1に記載のマルチプロセッサシステムであって、
各プロセッサエレメントがアクセス可能な複数のメモリと、
メモリに係わる故障が検出されたプロセッサエレメントを停止させた後に 、 故障と判定されたメモリ以外のメモリを使用して他のプロセッサエレメン トを再ブー卜する再ブー卜手段をさらに備える
ことを特徴とするマルチプロセッサシステム。
[18] 請求項 1に記載のマルチプロセッサシステムであって、
前記監視手段および切替え手段の動作を記述したプログラムを搭載する ことを特徴とするマルチプロセッサシステム。
[19] 複数のプロセッサエレメントを備えるマルチプロセッサシステムにおける 故障発生時の回復方法であって、
各プロセッサエレメン卜の状態を監視し、
第 1の処理を実行している第 1のプロセッサエレメントにおいて故障が検 出されたときに、 前記第 1の処理よりも優先度の低い第 2の処理を実行して いる第 2のプロセッサエレメントに前記第 1の処理を実行させる、
ことを特徴とするマルチプロセッサシステムにおける故障発生時の回復方 法。
PCT/JP2007/000394 2006-07-04 2007-04-11 Système à processeurs multiples WO2008004330A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2006-184874 2006-07-04
JP2006184874A JP2008015704A (ja) 2006-07-04 2006-07-04 マルチプロセッサシステム

Publications (1)

Publication Number Publication Date
WO2008004330A1 true WO2008004330A1 (fr) 2008-01-10

Family

ID=38894305

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2007/000394 WO2008004330A1 (fr) 2006-07-04 2007-04-11 Système à processeurs multiples

Country Status (2)

Country Link
JP (1) JP2008015704A (ja)
WO (1) WO2008004330A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011065521A (ja) * 2009-09-18 2011-03-31 Nec Computertechno Ltd 多重化サービスプロセッサ、多重化サービスプロセッサの障害処理方法、およびプログラム

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5227637B2 (ja) * 2008-03-31 2013-07-03 富士通エフ・アイ・ピー株式会社 分散制御方法
DE102008028573A1 (de) * 2008-06-16 2009-12-31 Nordex Energy Gmbh Verfahren zur Steuerung eines Windparks
DE102008028568A1 (de) * 2008-06-16 2009-12-31 Nordex Energy Gmbh Verfahren zur Steuerung einer Windenergieanlage
JP2013225208A (ja) * 2012-04-20 2013-10-31 Toyota Motor Corp 情報処理装置、情報処理方法、及びプログラム

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6350739B2 (ja) * 1981-07-13 1988-10-11 Hitachi Ltd
JPH05204689A (ja) * 1992-01-30 1993-08-13 Toshiba Corp 制御装置
JPH11184825A (ja) * 1997-12-19 1999-07-09 Mitsubishi Electric Corp クラスタシステム
JP3296378B2 (ja) * 1993-08-27 2002-06-24 株式会社東芝 コンピュータバックアップシステム
JP3294741B2 (ja) * 1995-08-23 2002-06-24 富士通株式会社 自己修復装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6350739B2 (ja) * 1981-07-13 1988-10-11 Hitachi Ltd
JPH05204689A (ja) * 1992-01-30 1993-08-13 Toshiba Corp 制御装置
JP3296378B2 (ja) * 1993-08-27 2002-06-24 株式会社東芝 コンピュータバックアップシステム
JP3294741B2 (ja) * 1995-08-23 2002-06-24 富士通株式会社 自己修復装置
JPH11184825A (ja) * 1997-12-19 1999-07-09 Mitsubishi Electric Corp クラスタシステム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011065521A (ja) * 2009-09-18 2011-03-31 Nec Computertechno Ltd 多重化サービスプロセッサ、多重化サービスプロセッサの障害処理方法、およびプログラム

Also Published As

Publication number Publication date
JP2008015704A (ja) 2008-01-24

Similar Documents

Publication Publication Date Title
JP6530774B2 (ja) ハードウェア障害回復システム
JP2552651B2 (ja) 再構成可能なデュアル・プロセッサ・システム
US7426657B2 (en) System and method for predictive processor failure recovery
US8713350B2 (en) Handling errors in a data processing system
JP7351933B2 (ja) エラーリカバリ方法及び装置
US8667315B2 (en) Synchronization control apparatus, information processing apparatus, and synchronization management method for managing synchronization between a first processor and a second processor
US20140089732A1 (en) Thread sparing between cores in a multi-threaded processor
US20170147422A1 (en) External software fault detection system for distributed multi-cpu architecture
KR101581608B1 (ko) 프로세서 시스템
JP3301992B2 (ja) 電源故障対策を備えたコンピュータシステム及びその動作方法
WO2008004330A1 (fr) Système à processeurs multiples
CN110865900A (zh) 增强嵌入式系统健壮性的一种方法
US10108469B2 (en) Microcomputer and microcomputer system
US10360115B2 (en) Monitoring device, fault-tolerant system, and control method
CN115617550A (zh) 处理设备、控制单元、电子设备、方法和计算机程序
JPH09251443A (ja) 情報処理システムのプロセッサ障害回復処理方法
US20090172231A1 (en) Data processing device and bus access control method therein
WO2014112039A1 (ja) 情報処理装置、情報処理装置制御方法及び情報処理装置制御プログラム
JP3365282B2 (ja) クラスタ接続マルチｃｐｕシステムのｃｐｕデグレード方式
US7523358B2 (en) Hardware error control method in an instruction control apparatus having an instruction processing suspension unit
CN108415788B (zh) 用于对无响应处理电路作出响应的数据处理设备和方法
US11099838B1 (en) Method and system for recovery for custom integrated circuit
JP2002318643A (ja) 情報処理装置
JPS6077252A (ja) 入出力制御装置
JP2000194677A (ja) 交代プロセッサを備えた情報処理装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07737051

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

NENP Non-entry into the national phase

Ref country code: RU

122 Ep: pct application non-entry in european phase

Ref document number: 07737051

Country of ref document: EP

Kind code of ref document: A1