Distributed control system

There is provided a distributed system having a plurality of nodes connected by a network. Each of the nodes includes: a common-parameter-value determining unit for determining a common-parameter-value from values of a parameter (each value being possessed by a corresponding one of the nodes); a common-operation execution unit for executing a common-operation using, as its input, a value of the parameter or the common-parameter-value; a send/receive unit for exchanging, via the network, the parameter values used for the determination of the common-parameter-value and the results of the common-operation execution with the other nodes; and a fault identification unit that compares the common-operation execution results collected from all the nodes and determines that an error occurs if not all the results are the same.

CLAIM OF PRIORITY

The present application claims priority from Japanese patent application serial No. 2007-250410, filed on Sep. 27, 2007, the content of which is hereby incorporated by reference into this application.

FIELD OF THE INVENTION

The present invention relates to high reliability control systems in which multiple devices connected to a network cooperate.

BACKGROUND OF THE INVENTION

A type of control system configuration of is a distributed system. In distributed systems, multiple nodes (such as computers and controllers) cooperate by exchanging messages via a communication network. In such a distributed system, even when part of the system suffers from a fault, a remaining normal part can execute, on behalf the faulty part, tasks for which the faulty part has been responsible. Thus, a highly fault tolerant system can be achieved.

A problem with distributed systems is fault detection. Because nodes operate independently of each other, there can occur a situation in which not all the nodes share the same information on fault occurrences (such as the locations, types, timings thereof). Such information difference between nodes can cause the nodes to operate in contradiction to each other and can incur a system failure. So, in distributed control systems, it is important that all nodes can share the same information on fault occurrences.

A method by which nodes can share the same information on fault occurrences is a mutual node monitoring system. In mutual node fault monitoring methods, all the nodes independently monitor and detect node faults and the fault detection results obtained at all the nodes are exchanged thereamong via a network. Then, each node examines the collected fault detection results and makes a final fault determination. A method for making such final fault determination, for example, is to determine that there occurs a fault when the number of nodes which detects the fault exceeds a predetermined threshold (such as a majority thereof).

In general, such mutual fault monitoring and determination methods have a limitation as expressed by the below equation.
The number of processes ≧3×(the number of identifiable faults)+1  (1)

In other words, at least four nodes need to join a mutual fault monitoring system if any fault identification is to be made. However, some small systems or subsystems may be configured with only three nodes. A technology is discussed which can perform fault identification even for systems with only three nodes (see Non-patent Document 1).

SUMMARY OF THE INVENTION

In Non-patent Document 1, for example, a value of the same variable is inputted to each of three nodes and the outputs from the three nodes are compared. When two of the nodes output the same result and the other node outputs a different result, then the node outputting a different result can be identified to be faulty. However, not all the variable values inputted to the three nodes are always assured to be the same. So, the above method has a problem because if not all the variable values are the same, then naturally not all the corresponding outputs will be the same, and thus the effectiveness of the method is virtually lost.

An object of the invention is to provide a method capable of performing reliable fault identification even for systems with three nodes.

There is provided a distributed system having a plurality of nodes connected by a network, in which each node includes: a common-parameter-value determining unit for determining a common-parameter-value from values of a parameter, each value being possessed by a corresponding one of the nodes; a common-operation execution unit for executing a common-operation using, as its input, a value of the parameter or the common-parameter-value; a send/receive unit for exchanging, via the network, the parameter values used for the determination of the common-parameter-value and the results of the common-operation execution with the other nodes; and a fault identification unit that compares the common-operation execution results collected from all the nodes and determines that an error occurs if not all the results are the same.

The invention can provide a method capable of performing fault identification even for systems with three nodes.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Embodiments of the invention will be described below with reference to the accompanying drawings.

FIG. 1is a block diagram of a distributed system.

The distributed system includes multiple nodes1-1, . . .1-n (n≧3), which are connected to each other via a network6.

Each node is a processing unit that can exchange information with the other nodes via the network, and includes various electronic controls, actuators and their drivers, sensors, etc.

Each node includes a CPU2, a main memory3, a storage4, and an I/F5connected to the network6, and communicates with the other nodes via the network6.

The storage4stores programs for a common-input-value determining unit41, common-operation execution unit42, fault identification unit43, send/receive processing unit44and error counter unit45as well as various data such as fault identification result46.

The CPU2performs processes by loading those programs into the main memory3and executing them. The programs and data as described herein may be prestored in the storage or inputted from a storage medium such as a CD-ROM or downloaded from a different system via a network. In addition, functions performed by the programs may be implemented using dedicated hardware. Hereinbelow, the description will be made as if various processes are performed by such programs. It should be appreciated, however, that they actually are the CPUs that perform such processes.

The network6is a multiplex transmission network, in which a node can simultaneously broadcast the same information to all the other nodes connected to the network.

FIG. 2is a flow chart of a fault identifying procedure.

All the nodes perform the respective fault identifying procedures while synchronously communicating with each other. The synchronization is achieved by communication via the network6.

Initially, at the step210(IS step), the common-input-value determining unit41determines, using all the data (input data) of all the nodes, a common-input-value, which will be used as the input of the common-operation execution (CP) step. Specifically, the send/receive processing units44of all the nodes exchange their own input data with each other, and the common-input-value determining unit of each node determines a value (common-input-value) using the collected input data and a common rule shared by all the nodes. For example, a common-input-value is determined only when all the input data of all the nodes have the same value, and the same value is adopted as the common-input-value. If at least one of the input data is different from the others, no common-input-value may be determined or alternatively the majority-voting of the input data or the average value thereof or the center value of the range thereof may be adopted as the common-input-value. Here, when no common-input-value is determined, the steps after the step220are not carried out. The number of times no common-input-value can be determined may be counted at the error counter unit45and if the counter value exceeds a preset value, the entire system (all the nodes) may be shut down. In this manner, all the nodes will share the same common-input-value. It is preferred to use a parameter varying with time as the input data. For example, the number of communication cycles owned by each node can be used.

In the FlexRay communication protocol for vehicles, the synchronization of the global time (including the communication cycle number) is natively provided by hardware. When the FlexRay communication protocol is employed for the network6and the communication cycle number is used for the common-input-value determining procedure, the CPU burden of executing the common-input-value determining procedure at the step210can be alleviated. Therefore, the CPU power thus saved can be allocated to other processings, or low cost is achieved by employing a lower performance CPU. In a synchronized system such as the one employing the FlexRay protocol, all the nodes natively have the same communication cycle number, thus eliminating the explicit need for exchanging the communication cycle numbers among the nodes.

Next, the common-operation execution unit42inputs the common-input-value obtained at the step210and performs a CP step (step220). The CP procedure is not particularly limited. For example, a simple arithmetic operation (such as [2x+1], where x is a common-input-value) is performed.

If a specific node function needs to be mutually monitored, the function is executed at the CP step at each node. The series of steps ofFIG. 2may be performed for each of various node functions, thereby enabling a plurality of monitor items to be mutually checked. Here, when the same common-input-value can be shared among the plurality of monitor items, the IS step needs not be repeated.

Then, the send/receive processing units44of all nodes exchange the CP results with one another at step230(hereinafter “EXC step”). This enables each node to collect and store the CP results obtained at all nodes including itself.

And then, at step240, the fault identification unit43performs fault identification (ID) and notification procedures. Specifically, the step240examines the CP results collected at the step230and judges whether or not a majority of nodes who join the mutual fault monitoring have the same CP result. When only a minority of nodes have the same CP result, the ID result is not used for any fault identification. When a majority of nodes have the same CP result, the other nodes having a different result are determined to be erroneous. The fault identification result46includes a node fault flag i for indicating the presence of a fault in the node i. And, when the node i is identified to be faulty, the node fault flag i is set for notification. The system application may access such node fault flags as needed. Or alternatively, when a fault is identified, an interrupt may be immediately asserted to the system application, which in response thereto may check the node fault flags for any fault occurrence. The node fault flags are reset prior to the restart of theFIG. 2procedure.

By the series of steps described above, a highly reliable fault identification method is achieved, and also the same information on fault occurrences is shared between nodes.

FIG. 3illustrates relationship between communication cycles and the steps ofFIG. 2.

During the first time span310of the communication cycle “a”, exchange of the input data between nodes (part of the IS step) is performed. During the latter time span320of the cycle “a”, determination of the common-input-value (also part of the IS step) and the CP step using the common-input-value are performed. During the first time span330of the communication cycle (a+1), the EXC step is performed. During the latter time span340of the communication cycle (a+1), the ID and notification step is performed. By these steps during these two cycles, an error for the cycle “a” is determined. Thus, the fault identification by the steps ofFIG. 2typically requires two communication cycles.

The steps ofFIG. 2may be pipelined as shown inFIG. 4. That is, the input data exchange (part of the IS step) for the data possessed at the cycle (a+1) and the EXC step for the CP results obtained at the cycle “a” are simultaneously performed in the same send/receive operation during the cycle (a+1). And, the determination of the common-input-value (part of the IS step) for the input data exchanged at the cycle (a+1), the CP step for the common-input-value determined at the cycle (a+1) and the ID step for the CP results exchanged at the cycle (a+1) are continuously performed during the cycle (a+1). Thereby, an ID result can be obtained each communication cycle. Here, the common-input-value used for the CP step at the cycle “a” may be determined at the end of the cycle (a−1). In addition, the send/receive processing unit44may add other data such as control data to the above-described send data relating to the mutual node monitoring procedure.

When the fault identification unit43determines an error for a monitor item of a node, the corresponding error count may be incremented instead of immediately setting the corresponding node fault flag. That is, the node fault flag for a monitor item of a node is not set until the corresponding error count exceeds a preset threshold. When the fault identification unit43determines that no error occurs for a monitor item of a node, the corresponding error count may be decremented or reset. A procedure employed is prebuilt in an appropriate software or prewritten in an appropriate configuration file or the like. Alternatively, the error counter may be operated so that the error count for a node is decremented or reset only when there is no error for all monitor items of the node.

FIG. 5illustrates an exemplary application of the mutual node monitoring procedure.

In this example, the mutual node monitoring steps are pipelined. The communication cycle number is used as the input data and an arithmetic operation ([2×“communication cycle number”]+1) is performed at the CP step.

At the slots1,2and3of the communication cycle1, the nodes1,2and3sequentially send the respective input data (cycle numbers for the cycle1) along with the respective CP results obtained at the previous cycle (501-1,502-1and503-1). And each node receives the data sent from the other nodes. Since the current cycle number is “1”, the cycle number sent from each node is “1”. And, since the common-input-value for the previous cycle is “0” and 2×“0”+1=1, the CP result sent from each node is “1”.

In each CP result table (511-1,512-1and513-1), all the CP results of all the nodes for the cycle0have the same value; so, each node determines at the ID step that no node error occurs at the cycle0. As a result, all the values of each ID result table (521-1,522-1and523-1) are “0” indicating that there is no error. Also, all the values of each error counter (531-1,532-1and533-1) and all the values of each node fault flag table (541-1,542-1and543-1) remain unchanged.

Next, the common-input-value for the cycle1is determined. In this example, when at least two input data have the same value, the value is adopted as the common-input-value. Since all the input data for the cycle1are “1”, the common-input-value is determined to be “1”.

Then, the CP step for the common-input-value determined at the cycle1is performed, obtaining a result of “3”. In this example, as shown, a CPU failure occurs at the node3after the sending operations of all the nodes during the cycle1and succeeding cycles. This disturbs the CP step of the node3during each cycle.

At the cycle2, similarly to the cycle1, the nodes1-3send the respective cycle numbers for the cycle2along with the respective CP results obtained at the cycle1. Here, all the cycle numbers sent from all the nodes (in501-2,502-2and503-2) are “2”. For the CP results, those sent from the nodes1and2(in501-2and502-2) are “3”, while that sent from the node3(in503-2) is “0” due to the CPU failure. Thus, in each CP result table (511-2,512-2and513-2), the CP result by the node3is different from the others; so, each node determines at the ID step that an error occurs in the node3. So, the third bit of each ID result table (521-2,522-2and523-3) is “1” indicating that there exists an error, while the other bits are “0”. Accordingly, the corresponding error count (the third bit) in each error counter (531-2,532-2and533-2) is incremented to “1”. However, each node fault flag table (541-2,542-2and543-2) still remains unchanged.

Similarly to the cycle2, also at the cycles3and4, the ID step determines that the node3has an error. Thus, in each node, the error count for the node3is incremented twice and becomes “3” after the ID step of the cycle4(531-4,532-4and533-4). When the threshold error count for notifying a fault occurrence is preset at “3”, the above error count exceeds the threshold. So, after the ID step at the cycle4, the flag for the node3in each node fault flag table is set to “1” (see the third bit in each of541-4,542-4and543-4) and the system application is notified of the fault occurrence at the node3. In the manner described above, a highly reliable fault identification method is achieved, and also the same information on fault occurrences is shared between nodes.

Besides theFIG. 2procedure, fault identification by mutual node monitoring can also be achieved by a procedure shown inFIG. 6. Similarly to theFIG. 2procedure, theFIG. 6procedure is performed with all nodes synchronized with one another. While the mutual monitoring procedure ofFIG. 2is effective in identifying faults in sending nodes, that ofFIG. 6is effective in identifying faults in receiving nodes as well as faults in sending nodes. The procedure shown inFIG. 6will be described below.

After steps610-630(similar to the steps210-230ofFIG. 2), the fault identification unit43performs the ID step (step640). Unlike the step240ofFIG. 2, the step640does not perform any notification. That is, the ID result obtained at the step640is not used for operating the error counter or node fault flag table.

Next, the send/receive processing units44of all nodes exchange the ID results with one another at step650(hereinafter “EXC2step”). This enables each node to collect and store the ID results obtained at all nodes including itself.

Then, the fault identification unit43performs fault identification (hereinafter ID2) and notification (step660). Specifically, the step660examines the ID results collected at the step650and judges whether or not a majority of nodes who join the mutual fault monitoring have the same ID result. When only a minority of nodes have the same ID result, the ID2result is not used for any fault identification. When a majority of nodes have the same ID result, the other nodes having a different result are determined to be erroneous. The fault identification result46includes a node fault flag i for indicating the presence of a fault in the node i. And, when the node i is identified to be faulty, the node fault flag i is set for notification. The procedure of this embodiment for notifying the system application of fault occurrences and resetting the fault flags is similar to that described inFIG. 2

As described above, when a node reports an ID result (for a monitor item of a node i) different from the others at an ID2step, the node reporting a different result is determined to suffer from a reception error. More exactly, when a majority of nodes have the same ID result, the other nodes reporting a different result are determined to have a reception error. In other words, when although the ID step of the cycle “a” judges that a node has no error, the ID2step of the cycle (a+1) judges that the node has an error, the node is determined to suffer from a reception error.

By contrast, when at an ID2step, a majority of nodes have the same ID result indicating that there occurs an error in a sending node, the sending node is determined to have an error. In this case, also, the corresponding error count and node fault flag is similarly operated. In this manner as described above, a highly reliable method capable of identifying both faults in sending nodes and those in receiving nodes is achieved, and also the same information on fault occurrences can be shared between nodes.

TheFIG. 6fault identification (including the ID2step) requires one more extra communication cycle for performing the EXC2and ID2steps in addition to the two cycles shown inFIG. 3. So, it typically requires three cycles in total. However, the number of communication cycles required for completing an ID2step depends on the timing at which the error occurs. For example, when a reception error occurs at an EXC step, two cycles are needed for performing the ID2step.

Although the above description is made for node faults, the invention can also be applied to network faults. For example, when the network6is configured with multiple lines, the data exchange and ID step of the mutual node monitoring procedure ofFIG. 2or6may be performed for each network line and then the results for all the network lines may be compared. In this case, when all the fault identification results for all the network lines show that an error occurs in a node, it is determined that the error really occurs in the node. If not, it is determined that the error occurs in a network line for which a different result is obtained.

TheFIG. 6procedure may be pipelined similarly to that described inFIG. 7. That is, the data exchange of the IS step for the input data of the cycle (a+2), the EXC step for the CP results obtained at the cycle (a+1) and the EXC2step for the ID results obtained at the cycle (a+1) are simultaneously performed in the same send/receive operation during the cycle (a+2). And, the common-input-value determination of the IS step and the CP step for the input data of the cycle (a+2), the ID step for the CP results exchanged at the cycle (a+2) and the ID2step for the ID results exchanged at the cycle (a+2) are continuously performed during the cycle (a+2). Thereby, an ID2result can be obtained each communication cycle.

A specific operation of the fault identification according to the flow chart ofFIG. 6will be described below with reference toFIG. 8. In this example, the mutual node-fault monitoring steps are pipelined. And, the CP step and the input data used for the CP procedure are similar to those described inFIG. 5.

At the slots1,2and3of the communication cycle1, the nodes1,2and3sequentially send the respective input data (cycle numbers of the cycle1) along with the respective CP and ID results obtained at the previous cycle (801-1,802-1and803-1). And each node receives those send data sent from the other nodes. Since the current cycle number is “1”, the cycle number sent from each node is “1”. And, since the common-input-value for the previous cycle is “0” and 2×“0”+1=1, the CP result sent from each node is “1”.

At the ID step, each node examines the collected CP results (811-1,812-1and813-1). The node1experiences a reception failure at the slot2; therefore, at the node1, the CP result sent from the node2is not “1” but “0” (811-1). Thus, although actually a reception error occurs at the node1at the cycle1, only the node1judges that an error occurs in the node2at the cycle0(i.e., the second bit of the table821-1is “1”). However, the nodes2and3judge that no node error occurs at the cycle0(i.e., all the bits in the tables822-1and823-1are “0”). At this point, all the error counters (851-1,852-1and853-1) and all the node fault flag tables (861-1,862-1and863-1) remain unchanged.

Next, the common-input-value for the cycle1is determined. This step is similar to that described inFIG. 5and a common-input-value of “1” is obtained. Then, the CP step for the cycle1is performed using this common-input-value, obtaining a result of “3”.

As shown in the send data801-2,802-2and803-2, at the cycle2, similarly to the cycle1, the nodes1-3send the respective cycle numbers of the cycle2(all of them are “2”), the respective CP results obtained at the cycle1(all of them are “3”) and the respective ID results (821-2,822-2and823-2) for the input data of the cycle0. Here, the ID results in the send data802-2and803-2(respectively of the nodes2and3) are both “0, 0, 0”. However, the node1has experienced a reception failure at the cycle1; therefore, the ID result in the send data801-2of the node1is “0, 1, 0”. So, the ID2step of each node determines that an error occurs at the node1during the cycle0since only the node1has a different ID result (see831-2,832-2and833-2). As a result, the first bit of each of the ID2result tables841-2,842-2and843-2is set at “1” indicating that an error occurs at the node1, and, at each node, the error count for the node1is incremented to “1” (851-2,852-2and853-2). At this point, however, all the node fault flag tables remain unchanged (see861-2,862-2and863-2).

Similarly to the cycle1, also during the cycles2and3, the node1experiences a reception failure at the slot2, and the ID step of the node1judges that the node2is erroneous. And, similarly to the cycle2, also during the cycles3and4, the ID2step of each node determines that an error occurs at the node1. As a result, in each node, the error count for the node1is incremented twice and becomes “3” after the ID2step of the cycle4(see851-4,852-4and853-4). When the threshold error count for notifying a fault occurrence is preset at “3”, the above error count exceeds this threshold. So, after the ID2step at the cycle4, the flag for the node1in each node fault flag table is set to “1” (see the first bit in each of861-4,862-4and863-4) and the system application is notified of the fault occurrence at the node1.

In the manner described above, a highly reliable fault identification method is achieved, and also the same information on fault occurrences is shared between nodes. Although not described, identification of faults in sending nodes and sharing of the same information on such fault occurrences between nodes can also be achieved by the ID2procedure of this embodiment similarly to the first embodiment. For example, a fault in a sending node as shown inFIG. 5can be identified by using the steps ofFIG. 6as follows: At the cycle3, the nodes send the respective ID results (521-1,522-2and523-2) obtained at the cycle2, and all the ID results are “0, 0, 1”. As a result, the ID2step of each node determines that there occurs an error in the sending node3and the corresponding error count for the node3is incremented.

Here, the error counter unit45may have two types of error counters, one for errors in sending nodes and the other for errors in receiving nodes, and the system application may be notified of fault occurrences in such a manner that it can discriminate the error types.

FIG. 9is a block diagram of a distributed system. This system differs from theFIG. 1system only in that the common-input-value determining unit51of each node is connected to an input unit900via a communication line910. As for the configuration of the communication line910, each node may be provided with a dedicated line such as a serial cable or all nodes may be connected via a single network.

The input unit900generates an input datum used for the mutual node monitoring procedure ofFIG. 2or6, and delivers it to the common-input-value determining units51. The input datum is generated from a sensor output signal or the like. Using all the input data received by all nodes or values processed therefrom at all nodes, the common-input-value determining unit51of each node provides a common-input-value by the IS procedure.

With theFIG. 9configuration, the nodes can mutually monitor one another in a similar manner to that described inFIG. 2or6; in addition, normal nodes can acquire a normal datum (such as a sensor output signal) from the input unit900and also can determine a common-input-value when the number of abnormal nodes is small. So, when a plurality of nodes have a control and processing function for calculating various signals such as control signals and motor current command signals using, as its input, the data from the input unit900, such function can be maintained even if a node fault occurs as long as at least one of the nodes with such function remains normal.

Such a control and processing function may be used for the CP procedure. In this case, the mutual node monitoring of this embodiment can be carried out by modifying the flow charts ofFIGS. 2 and 6to the flow charts ofFIGS. 10 and 12, respectively.

FIG. 10is a flow chart illustrating the steps of a mutual node monitoring procedure.

At the step1010(IR step), the common-input-value determining unit51of each node receives an input datum from the input unit900. Next, at the step1020(CP′ step), the common-operation execution unit52executes a common-operation using the input datum received at the step1010instead of a common-input-value. The common-operation is the same as that used in the step220ofFIG. 2. Then, at the step1030, all the send/receive processing units54exchange the input data received at the step1010and the CP′ results obtained at the step1020with one another. This enables each node to collect and store all the input data and CP′ results obtained at all nodes including itself. Thus, inFIG. 10, the input data exchange of the step210(IS step) ofFIG. 2and the step230(EXC step) ofFIG. 2can be performed simultaneously, thereby reducing the number of procedural steps required for performing the mutual node monitoring.

Then, the step1040(II step) examines whether any common-input-value can be determined based on all the input data collected from all nodes at the step1030. The condition under which any common-input-value can be determined is the same as that used in the step210. The flow then proceeds to the step240, thereby completing the procedure.

As described above, by theFIG. 10procedure, the number of procedural steps required for performing the mutual node monitoring can be reduced compared to theFIG. 2procedure while providing a comparable effect.

FIG. 11illustrates relationship between communication cycles and the mutual node monitoring procedure ofFIG. 10. The first time span1110of the communication cycle “a” performs the IR and CP′ steps. These steps may be performed at the end of the previous cycle. During the second time span1120of the cycle “a”, the input data and CP′ results of all nodes are exchanged with one another (EXC′ step). During the last time span1130of the cycle “a”, the II step and the ID and notification step are performed. Thus, each fault identification (ID) according to theFIG. 10procedure typically requires one communication cycle.

FIG. 12is a flow chart of another mutual node monitoring procedure.

TheFIG. 12procedure is a combination of theFIG. 10procedure andFIG. 6procedure, in which the steps1010-1040are first performed and then the steps640-660are performed. Similarly to theFIG. 10procedure, theFIG. 12procedure can reduce the number of procedural steps required for performing the mutual node monitoring compared to theFIG. 6procedure while providing a comparable effect.

TheFIG. 12fault identification (including the ID2step) requires one more extra communication cycle for performing the EXC2and ID2steps in addition to the single cycle shown inFIG. 11. So, it typically requires two cycles in total.

TheFIG. 12procedure may be pipelined similarly to that described inFIG. 13. That is, the EXC′ step for the CP′ results obtained at the cycle (a+1) and the EXC2step for the ID results obtained at the cycle “a” are simultaneously performed in the same send/receive operation during the cycle (a+1). And, the IR and CP′ steps for the input datum received at the cycle (a+1), the II step for the input data exchanged at the cycle (a+1), the ID step for the CP′ results exchanged at the cycle (a+1) and the ID2step for the ID results exchanged at the cycle (a+1) are continuously performed during the cycle (a+1). Thereby, an ID2result can be obtained each communication cycle.

A BBW (Brake By Wire) control system used in a vehicle utilizing the mutual node monitoring procedure ofFIG. 10or12and having theFIG. 9configuration will be described below.

The detailed system configuration is as follows: FlexRay is used as the communication protocol for the network6, and ECU (Electric Control Unit) nodes1,2and3are connected to the FlexRay network. To each of the ECUs1and2is connected, via a current controlling inverter, a steering motor, which actuates the front axle to change the steering angle. The ECU3calculates target values for the front wheel steering angles from various parameters such as the steered angle of the steering wheel and the vehicle speed, and also calculates current command values for the steering motors of the ECUs1and2by using, in addition to such parameters as described above, the difference between the target values and the actual steering angles. The calculated current command values are sent, via the network6, to the ECUs1and2, which in turn control the respective steering motors based on the command values.

The vehicle speed is measured using a vehicle speed sensor and is transmitted to the ECU3via a CAN (Controller Area Network). The ECU3receives actual values of the front wheel steering angles from the ECUs1and2via the network6, and uses them to calculate current command values for the steering motors.

The steered angle of the steering wheel is measured using a resolver and transmitted to the common-input-value determining units41-1to41-3of the ECUs via the communication line910. The steered angle of the steering wheel is used as the input data for the mutual node monitoring procedure. And, the backup steering control of the system is used as the common-operation for the CP procedure. The backup control is a simple control calculation which calculates target values for the front wheel steering angles using only the steered angle of the steering wheel and calculates current command values for the steering motors using only the differences between the target values and the current steering angles.

When the control application confirms by the mutual node monitoring procedure that all ECUs are normal, the ECUs1and2control the respective steering motors based on the current command values sent from the ECU3. When the mutual node monitoring procedure notifies the control application (by setting the node fault flag for the ECU3) that the ECU3suffers from a fault, the ECUs1and2control the currents of the respective steering motors by using their own backup controls. When the mutual node monitoring procedure identifies a fault in the ECU1, the ECU3calculates a greater-than-normal current command value for the steering motor of the ECU2and transmits it to the ECU2so that the front axle can be actuated by the steering motor of the ECU2alone.

In this manner, the steering control can be continued even when a fault occurs in the ECUs. By using such a combination of the mutual node monitoring procedure and a backup control, a robust control system can be constructed.

INDUSTRIAL APPLICABILITY

Distributed control systems are used in a wide variety of industrial fields such as vehicles, construction machines and FA (Factory Automation). By applying the present invention to such a distributed control system, high system reliability can be achieved. Further, the invention can be implemented without the need of extra devices such as a monitoring node; thus, a highly reliable system is provided at low cost.