JP4754993B2 - Fault-tolerant node architecture for distributed systems - Google Patents

Description

  This application claims priority from US Provisional Application Serial No. 60 / 657,011, filed February 28, 205, the entire contents of which are hereby incorporated herein by reference. It is.

  The present invention relates to fault-tolerant node architectures, and more particularly to fault-tolerant node architectures for use in distributed systems.

  Electromechanical braking systems are of increasing interest for use in automobiles. For example, an electromechanical brake system may have a central controller and / or a controller that works with each brake control subsystem located at the corner of the vehicle. The controller can be coupled to a bus (eg, a time-triggered bus or an event-triggered bus) to provide communication between the various controllers. Since such electromechanical braking systems can rely exclusively on electromechanical systems to control the brakes, these systems typically include redundancy and backup. Some systems have a fail-safe or fault-free architecture so that the system can continue to function. However, in these systems, when one of the nodes (ie, the corner controller) is defective and / or stopped, it continues to function at a reduced level of performance.

  Can work with fault tolerance or failure so that the system can continue to function normally or in normal close condition even when one of the nodes is defective and / or shut down It is desirable to provide a distribution system that is Such a fault tolerance system allows the system to continue to function, but offers advantages over failsafe or fail silent systems that function at reduced performance levels. Classical systems require three controllers with a single node to provide sufficient surplus in providing fault tolerance nodes. However, providing three controllers at each node for a large number of systems, such as an automotive control system, can be very costly.

  Accordingly, there is a need for a fault tolerant node architecture for use in a system or controller coupled to a bus. There is a need for a fault-tolerant node architecture that can be used in a distributed system and that takes advantage of the distributed nature of the system to provide a fault-tolerant feature system.

  In one embodiment, the present invention is a fault tolerant node architecture for use in a system or controller coupled to a bus, such as an event triggered bus or a time triggered bus. In particular, in one embodiment, the present invention is a distributed architecture system that includes a plurality of nodes operatively connected together by a bus. Each node comprises a main controller configured to provide data to the bus and actuator, and a management controller configured to provide data to the bus and actuator. Each node is configured such that during normal operation, the primary controller provides data to the actuator to control the actuator and the management controller does not normally provide data to control the actuator to the actuator. If each of the nodes determines that the primary controller is providing inappropriate data, the management controller provides the actuator with data that controls the actuator, and the primary controller provides data that controls the actuator. It is configured not to provide to the actuator.

  The node architecture of the present invention can be implemented in a vehicle 10 having a vehicle body 12, as shown in FIG. The vehicle 10 includes a set of wheels 14 with each wheel 14 disposed at or adjacent to a corner of the vehicle 10. Each wheel 14 may include a brake subsystem 16, such as an electromechanical brake system. Each brake subsystem 16 may include a caliper 18 and a rotor 20 rotatably coupled to associated wheels 14. Each caliper 18 is operatively connected to a motor 22 having an associated motor driver 21. The motor 22 is operable to displace the caliper 18 and engage a brake pad (not shown) disposed thereon with the rotor 20, in a well-known manner for braking and deceleration of the vehicle 10. Can be caused by.

Each brake subsystem 16 further includes a remote processor / controller or corner processor / controller 24 located adjacent to or associated with the wheel 14 to control the braking force applied to the wheel 14. Or may be linked. Each corner processor 24 is connected by a main communication bus 28 to a central processor / controller 26 as well as other corner processors 24 or other additional processors or controllers (not shown) to form a larger system. It may be.
Each processor 24, 26 may be any of a wide variety of controllers, microcontrollers, electronic control units (ECUs), processors, chips, logic circuits, etc., or may include them. What is referred to herein as a “processor” is intended to encompass all of these terms and configurations. Each corner and processor 24 can provide signals / commands to the associated motor driver 21. Each motor driver 21 can provide a signal / command to the associated motor driver 21. Each motor driver 21 can convert signals / commands into electrical signals / commands supplied to the associated motor 22 to control the movement and operation of the associated motor 22 / caliper 18.

  The system of FIG. 1 shows a vehicle 10 with an electromechanical brake subsystem 16 disposed on each wheel 14. However, if desired, fewer than all of the wheels 14 (i.e., only two wheels) may be equipped or utilized with an electromechanical brake subsystem. In this case, those other wheels may be equipped with a traditional hydraulic brake subsystem.

  The vehicle 10 may include a main communication bus 29 that can transmit data to and receive data from each of the processors 24, 26. Bus 28 may take any form capable of transferring signals or data, including electrical signals, optical signals, or wireless signals. In addition, the bus includes various technologies in its facilities such as wired, wireless, optical fiber, and combinations thereof, and these technologies can be used. The bus 28 may be or include any of a wide range of communication networks, bus systems or configurations, asynchronous or synchronous communication systems and protocols, and combinations thereof. Can do. Although only a single bus 28 is shown, the bus 28 should have sufficient capacity to provide the requested data transmission and may in fact comprise multiple buses or sub-buses. In this manner, each of the corner processor 24 and / or central processor 26 has the ability to control and / or monitor and / or communicate with other processors 24, 26. .

  The bus 28 can have a variety of configurations or topologies including a star configuration, a ring configuration, or other configurations. Bus 28 may utilize or incorporate an event triggered protocol. In this case, the bus 28 may be, for example, a CAN (controller area network) data bus line or a VAN (vehicle area network) data bus line. As an alternative, the bus 28 may utilize or incorporate a time triggered protocol. In this case, the bus 28 is, for example, a FlexRay (R) data bus, or a TTP / C bus, or a TTCAN bus, or a Titan (R) bus sold by a company in San Diego, California. Either may be sufficient.

  Each of the processors 24, 26 receives data related to various conditions and components of the vehicle 10. For example, FIG. 1 illustrates a plurality of wheel speed sensors 30 with each vehicle sensor 30 positioned adjacent to the wheel 14 and providing its output to the adjacent corner profile 24 associated therewith. FIG. 1 shows a brake pedal sensor 32 configured to determine the displacement of the brake pedal 34 and a handle sensor 36 configured to determine the rotational position of the handle 38. Brake pedal sensor 32 and handle sensor 36 are coupled to the central processor. However, the vehicle / system may include various additional sensors that track various vehicle / system conditions (e.g., vehicle speed, vehicle heading, wheel slip condition, longitudinal and lateral acceleration, yaw angle, etc.) (see FIG. (Not shown) may be included. The various sensors may be directly coupled to each of the processors 24, 26 or a selected processor to provide their output signals. Each processor 24, 26 processes data received from various sensors.

  Each processor 24, 26 is considered a node where input data flows into the node and output data flows out. Each node 24, 26 is required to have a fault tolerance structure or architecture. In addition, the various sensors (ie, sensors 30, 32, 36) and the processors 24, 26 may form or be part of a larger control system 40 having a fault tolerance structure or architecture. it can. The node architecture outlined below may be utilized or incorporated into each of the processors 24, 26 used in the automobile 10. More particularly, it may be utilized or incorporated in the processor 24, 26 of an electromechanical (ie, electric brake) system.

  However, the node architecture disclosed herein may include, for example, a steering (ie, electric steering) processor, an electric throttle processor or system, an active suspension processor or system, or an automated control processor or system, controller or control system. Etc. It should be understood that it may be utilized or incorporated within almost any vehicle processor or system. In addition, the present invention and the node architecture disclosed herein are not necessarily limited to use with processors or controllers utilized in automobiles or automated vehicles. It can be used in any system that utilizes a node, processor or controller that provides an output.

  FIG. 2 schematically illustrates the architecture of a single remote processor or node 24. Each remote processor 24 and optionally central processor 26 may have the same architecture as shown in FIG. The system of FIG. 2 utilizes a dual microcontroller architecture. In this architecture, the nodes 24, 26 comprise a main controller or main hardware 42 and a management controller or management hardware 44. The management controller 44 may have the same processor or processing capability as the main controller 42. In this case, the management controller 44 can run with the same processing algorithm as the main controller 42 or can perform the same calculations as the main controller 42 so that the main controller 42 and the management controller 44 Form a symmetrical shape.

  As an alternative, the nodes 24, 26 preferably have an asymmetric form, in which the management controller 44 has reduced processing power and of the algorithms and calculations performed by the main controller 42. A simplified version can be run. For example, the management controller 44 may be a low-cost microcontroller, or may be in the form of hardware or circuitry such as a field programmable gate array (FPGA), application specific integrated circuit (ASIC), or the like. I can take it. The management controller 44 may be a fairly basic controller that drives the actuator driver 21 so that the communication controller protocol (ie, the management controller 44 can communicate with the bus 28). And basic logic. The management controller 44 should also have an actuator signal interface to provide output and process input.

  Each of the main controller 42 and the management controller 44 is individually connected to the bus 28 by a bus driver or transmitter 46 to be connected. The main controller 42 and the management controller 44 are each provided with or connected to communication controllers 48 and 50, respectively. The communication controller accumulates and stores data provided from the associated main controller 42 or management controller 44. Each communication controller 48, 50 may be physically integrated with its associated main controller 42 or management controller 44. In this case, the communication controllers 48, 50 can be mounted on the same integrated chip as their associated controllers 42, 44, and the communication controllers 48, 50 are considered internal peripheral devices. As an alternative, each communication controller 48, 50 can be physically separated from its associated main controller 42 or management controller 44. In this case, each communication controller 48, 50 can be functionally integrated with its associated main controller 42 or management controller 44.

  As described above, the main controller 42 and / or its communication controller 48 are connected to the associated bus driver 46. The bus driver is connected to the main bus 28. The management controller 44 and / or its communication controller 50 is similarly coupled to an associated bus driver 46 that is coupled to the main bus 28. Each communication controller 48, 50 is connected to the associated bus driver 46 in a well-known manner via a transmit (Tx) line, a receive (Rx) line, and / or a transmit enable (TxEn) line (not shown). May be.

  Each of the main controller 42 and the management controller 44 independently receives data (ie, the amount of movement of the brake pedal 34, the position of the handle 38, the wheels 14 and the speed, etc.) via the bus 28. In addition, the bus 28 has a speed of the vehicle 10, a lateral acceleration of the vehicle, a heading requested by the driver, a braking operation requested by the driver, a slip level of each wheel, a longitudinal and lateral acceleration, and a yaw. Data related to corners etc. can be provided. Also receives data from the associated actuator 22 (ie, motor), actuator driver 21 (ie, motor driver), associated wheel speed sensor 30, or other sensors via associated digital / analog sensor inputs 52, 56. .

  The main controller 42 and the management controller 44 each independently process input data and provide output data or signals. In the electromechanical brake system of FIG. 1, the output of each controller 42, 44 is any one of the wheels 14, and the brake motor 22 applies a braking force to the associated wheel 14 (ie, the brake pedal 34 is applied). It may also be data that determines whether to be acted upon (to match the driver input via, i.e. the requested braking force). Thus, the main controller 42 processes the input and determines whether any action (ie braking action) is required, and what action is required in response to the driver's input. Determine if the type of braking action is required. The main controller 42 provides its output 54 to control the operation of the associated actuator / brake motor 22, which is supplied to the actuator driver 21 / actuator 22 via various logic (described below). Is done. The main controller 42 further provides its output to the other processors 24, 26 to the bus 28 via its communication controller 48 and bus driver 46. The output of data from the main controller 42 and management controller 44 to the actuator 22 and bus 28 may be direct or indirect.

  The main controller 42 includes a driver interface 70 that interfaces with the actuator 22 / actuator driver 21 and processes the sensor input 52. For example, input data provided to driver interface 70 via input line 52 may take the form of voltage and / or current provided to actuator 22 / actuator driver 21, motor position of actuator 22, and the like. The driver interface 70 can provide control data to the actuator 22 / actuator driver 21 via the output line 54 in the form of voltage and / or current to be supplied to the actuator 22 / actuator driver 21.

  The main controller 42 includes an internal processing unit 72 that performs the higher level functions of the main controller 42. For example, the internal processing unit 72 can perform motor driver command calculations, selection calculations, ABS calculations, TCS calculations, etc. for each actuator 22 / actuator driver 21 in the system.

  The management controller 44 can be configured in a manner similar to the main controller 42. The management controller 44 receives input from the bus 28 / bus driver 46 and through its digital / analog input 56 in a manner similar to the main controller 42. If it has sufficient capacity, the management controller 44 processes the input and determines if any braking action is required, and what kind of braking action is required. Determine whether the braking action is required. The output of the management controller 44 is supplied to the bus 28 and output through the output unit or the digital output unit 58. If the management controller 44 is sufficiently basic, the management controller 44 does not necessarily have to calculate what kind of braking action is required, but instead simply performs basic calculations. . These calculations correspond to some of the most important brake control determinants calculated by the main controller 42, or test sequence calculations that are not necessarily part of the brake application algorithm (ie, the function of the management controller 44). Test).

  The management controller 44 can have a driver interface 74 that has the same or similar design as the driver interface 70 of the main controller 42. The management controller 44 may include an internal processing unit 76. In an asymmetric configuration, the internal processing unit 76 has less processing power than the internal processing unit 72 of the main controller 42. In one embodiment, the internal processing unit 76 lacks the ability to perform higher level processing (ie, calculate motor driver commands, ABS calculations, TCS calculations, etc.). In its most basic form, the internal processing unit 76 has sufficient processing power to send consensus commands provided from other nodes in the system to its output 58. However, the internal processing unit 76 can have a range of processing capabilities and can provide any, all or some of the higher level capabilities provided by the main controller 42.

  Each node / corner processor 24 (and its controllers 42, 44) has its function / calculation for its associated wheel 14 / brake subsystem 16 and other wheels 14 / brake subsystem 16 of the vehicle 10. (I.e., determine if brake control is required and, if so, determine how to perform such brake control). As an example, the processors 24 and 26 of FIG. 2 can be considered as the corner processor 24 for the right front wheel 14 of the vehicle 10 of FIG. When receiving input from the bus 28 and / or through the inputs 52, 56, the main controller 42 and possibly the management controller 44 of the node 24, the right front wheel brake subsystem 16, and the other three of the vehicle 10 For the brake subsystem 15, calculate brake control determinants or functions (various other higher level functions).

  As outlined above, the main controller 42 and the management controller 44 provide their data to the bus 28. In this manner, the controllers 42, 44 and the nodes 24, 26 can monitor each other's data and output. In addition, the primary controller 42 and management controller 44 of each node 24, 26 may be directly coupled by a serial peripheral interface (SPI) or other working connection 57, and each management controller 44 is associated with it. All or part of their outputs can be provided to each other so that the main controller 42 can be monitored directly. The reverse mode is also possible.

  Thus, the output information of the controllers 42, 44 may be monitored / verified by each other by either the SPI connection 57 and / or information placed on the bus 28. Considering the information provided on the bus 28 may be more efficient due to the limited bandwidth of the SPI connection 57 as opposed to exchanging information via the SPI connection 57. The management controller 44 can monitor / verify all or part of the output or data of the main controller 42. Similarly, the controllers of the other nodes 24, 26 can monitor / verify all of the output or data of the main controller 42, or only a portion of that output or data.

  As will be described in more detail below, during normal operation, the logic circuitry of node 24 ensures that the output 54 of the main controller 42 exceeds or replaces any output 58 of the management controller 44. Thereby, the main controller 42 controls the operation of the actuator driver 21 / actuator 22. However, during a fault in the main controller 42, the output 58 of the management controller 44 controls or audits the operation of the actuator driver 21 / actuator 22.

The communication controllers 48, 50 for the main controller 42 and the management controller 44 provide outputs (ie, override signals) to the logic circuitry of the nodes 24, 26, and the output of each of the enable pin 60 / disable pin 62 is, for example, It may be a digital output such as a digital signal (high signal) or a digital zero signal (low signal). The output of each enable pin 60 / disable pin 62 is provided to an associated AND operation gate or function block 64, 66 along with the outputs 54, 58 of the associated controller 42, 44. The output of each AND gate 64, 66 is fed to an OR operation gate or functional block 68, which provides its output to the actuator driver 32 / actuator 22. The AND gates 64 and 66 respectively correspond to the first logic function and the second logic function in the claims.

  During normal operation, the output of the enable / disable pin 60 of the main controller 42 is a digital signal or high signal, and the output of the enable / disable pin 60 of the management controller 44 is a digital zero signal or low signal. is there. In this manner, when the output 54 of the main controller 42 is provided to its associated AND gate 64, the output of the AND gate 64 matches the output 54 of the main controller 42. Conversely, when the output 58 of the management controller 44 is provided to its associated AND gate 66, the output of the AND gate 66 is typically a digital zero or low signal.

Next, the outputs of the two AND gates 64 and 66 are supplied to the OR gate 68. During normal operation, the output of the OR gate 68 corresponds to the output of the AND gate 64, and the output of the AND gate corresponds to the output 54 of the main controller 42. In this aspect, during normal operation, the main controller 42 provides commands to the actuator driver 21 and actuator 22 to control their operation. The OR gate 68 corresponds to the third logical function in the claims.

As described above, the management controller 44 monitors the output of the associated main controller 42. In addition, other corner processors 24 and / or central processor 26 monitor the output of main controller 42. The management controller 44 and / or other processors 24, 26 collectively determine whether the main controller 42 is malfunctioning or functioning normally. For example, when the processor 24 in FIG. 2 is a processor for the right front wheel of the vehicle 10 in FIG. 1, the associated management controller 44 and other main controllers 42 and management controllers 44 in the other nodes 24 and 26 are , All participate in the determination process including whether or not the main controller 42 of the right front node is malfunctioning. This determination may include consideration of various other factors including the output of the main controller 42, the timing of the output of the main controller 42, and the health status (SOH) of the main controller 42.

  The SOH is a bit of information related to the functional state of the controllers 42 and 44. The default for the SOH data field for the main controller 42 is “OK”. During normal processing operation, the main controller 42 may be required to toggle a set of bits in a predetermined manner. If the main controller 42 does not toggle the bit in the desired manner, the SOH bit for the main controller 42 may be switched to “NOK” or “non-OK”. Thus, the main controller 42 may be essentially required to complete a diagnostic test or perform a test set calculation to maintain its “OK” SOH state.

  The timing of the output of the main controller 42 under consideration is also monitored and attention can be paid. For example, the main controller 42 may have an expected timing pattern associated with the timing or manner in which the controller 42 is expected to provide data on the bus 28. If the controller 42 deviates sufficiently from its expected timing pattern, this can be interpreted as evidence of the controller 42's defective operation.

  In the extreme case associated with the expected timing pattern, the controller 42 may become dysfunctional to the extent that it provides a constant flow of meaningless data on the bus 28. The management controller 44 (or other nodes 24, 26) quickly determines that the primary controller 42 is malfunctioning due to the length of the data flow provided by the primary controller 42 to the bus 28. be able to. It may be particularly important to shut down a malfunctioning main controller 42 that provides a constant flow of bad data. This malfunctioning controller may essentially monopolize the bus 29 and may prevent other controllers and components from communicating via the bus 28. In this sense, the system 40 monitors data in both the time domain and the value domain to determine the good / bad status of the main controller 42.

  As noted above, the data value, data timing, and SOH are among several factors that may be considered by other processors and nodes to collectively determine whether the primary controller 42 is malfunctioning. Equivalent to. If the management controller 44 has sufficient processing capability, the management controller 44 can participate in determining the state of the main controller 42. The management controller 44 and / or other nodes 24, 26 associated with the malfunction / normal state of the primary controller 42 collectively determine whether the primary controller 42 is malfunctioning or functioning normally. May be selected for determination. Thus, in order to be able to provide a meaningful selection process, at least two other components (ie, the associated management controller 44 and other nodes 24, 26 and their individual controllers 42, A combination of two components from a group such as 44) should be available to participate in the selection process.

  If the system 40 determines that the primary controller 42 for a given node is malfunctioning or outputs invalid or inappropriate data, the system 40 will stop or disable the primary controller 42. In particular, the main controller 42 can be prevented from providing data to its associated actuator driver 21 / actuator 22. A process for ignoring control data provided by controller 42 to bus 28 may be employed. In order to stop or invalidate the data provided to the actuator driver 21 / actuator 22 with which the non-functional controller 42 is associated, when the main controller 42 is determined to be malfunctioning, The position / output of the disable pin 60 is switched to a low signal. The position of the pin 60 is switched by a hardware selection input in the communication controller 48 received from the other nodes 24 and 26 transmitted via the bus 28. At the same time, the position / output of the enable / disable pin 62 of the associated management controller 44 is switched to a high signal by an input via the bus 28.

  In this case, the output of the AND gate 64 associated with the main controller 42 is a digital zero or low signal, and the output of the AND gate 66 associated with the management controller 44 matches the output 58 of the management controller 44. The output of the OR gate 68 supplied to the actuator driver 21 / actuator 22 matches the output 58 of the management controller 44. Thus, in this “invalid” state of nodes 24, 26, management controller 44 controls the operation of actuator driver 21 / actuator 22 or provides a signal to actuator driver 21 / actuator 22.

  To determine the command to be provided to actuator driver 21 / actuator 22 via output 58, system 40 polls the other nodes 24, 26 for selection on the command. If the management controller 44 has sufficient processing capabilities, the management controller 44 can participate in the selection process. Once the system 40 / management controller 44 has determined that an appropriate output is provided to its associated actuator driver 21 / actuator 22, the management controller 44 may provide the actuator driver 21 / actuator via its output 58. 22 provides instructions. As described above, the logical structure of nodes 24 and 26 ensures that output 58 is sent through AND gate 66 and OR gate 68 to actuator driver 21 / actuator 22. Thus, during the outage of the main controller 42, the management controller 44 can essentially function as a “gateway” to send agreement control data to the actuator driver 21 / actuator 22. This state of main controller 42 being stopped or disabled continues as long as system 40 determines that main controller 42 is not outputting valid data.

  The process described above can be used to prevent a defective primary controller 42 from providing output to the actuator driver 21 / actuator 22. In addition, communication between the main controller 42 and the bus 28 can be stopped when desired by the bus guardian. The function of the bus guardian can be implemented by the management controller 44, the coprocessor of either the main controller 42 or the management controller 44, the bus driver 46, an independent ASIC, a centralized star coupler bus guardian, or the like.

  The process outlined above includes the steps of monitoring the output of the main controller 42 and disabling the output of the output controller 42 when it is determined that the main controller 42 is malfunctioning. In addition, the output of the management controller 44 can be monitored if desired. In order to allow monitoring of the management controller 44, the management controller 44 can provide some of its outputs to the bus 29 for validation by the system 40. In particular, the bus 28 may provide basic control information to the management controller 44, such as the required braking force (ie, as determined by the other three processors 24).

  The management controller 44 and in particular its internal processing unit 76 can have a small part of the algorithm or programmed code that can process the braking force data, and the braking force data is sent to the actuator driver 21 / actuator 22. Control data (that is, the number of revolutions of the electric motor 22 required to match the braking force data). The management controller 44 may provide the output of this algorithm on the bus 28 so that the processors at the other nodes 24, 26 can examine and verify the output of the management controller 44.

  If the management controller 44 of a given node 24, 26 is determined to be malfunctioning during a disabled state by the system 40, both the primary controller 42 and management controller 44 of the single node 24, 26 are malfunctioning. (Ie, a second level failure has occurred). In this case, the nodes 24, 26 may be stopped or operated in a fail-safe or fail-silent manner. For example, the output of enable / disable pin 62 of management controller 44 can be switched to a low signal while enable / disable pin 62 of main controller 42 is maintained at a low signal. These steps ensure that the nodes 24,26 are essential while ensuring that the defective nodes 24,26 do not interfere with the functions of the remaining nodes 24,26 so that the system 40 remains functional. Stop.

  If desired, monitor the output of the management controller 44 and stop the management controller 44 even when the nodes 24, 26 are not in the disabled mode (ie, when the main controller 42 is operating normally). You may be able to do that.

  In the same manner as for the main controller 42 described above, the bus communication accuracy of the management controller 44 may be evaluated by the functionality of the bus guardian. The bus guardian functionality for the management controller 44 may be implemented by either the main controller 42 or a coprocessor of the management controller 44, a bus driver 46, an independent ASIC, a centralized star coupler bus guardian, or the like.

  In the system 40 shown in FIG. 1, there are at least four separate nodes (four remote processors 24) and a fifth node in the form of an alternative central processor 26. Thus, even if one or more of the nodes 24, 26 fail completely, the system 40 can still function in some meaningful way. In other words, the distribution cluster can always be determined via multiple selections on the three processors 24, 26, thus providing accurate data to the actuator driver 21 / actuator 22 even in the case of a fault. be able to. Thus, a minimum of three nodes can be required for the fault tolerance architecture.

  In this aspect, a complete failure action distribution system 40 is provided that provides complete service in the event of a fault. In addition, the failure operation system of the present invention can be implemented in a relatively cost effective manner by simply adding the management controller 44 to an existing system that already includes the main controller 42 and the actuator 22. As described above, since the management controller 42 can be a relatively basic component such as a circuit or hardware, the cost added by the management controller 42 can be greatly reduced.

  The example described above focuses on the primary controller 42 and management controller 44 of a single node 24 (eg, the right front node of FIG. 1), but the remaining nodes 24, 26 have a structure similar to that of FIG. It should be understood that the primary controller 42 and management controller 44 of these nodes may be monitored and / or disabled. In addition, the main controller 42 and management controller 44 of the nodes 24, 26 of FIG. 2 participate in the selection process to determine the status of the controllers 42, 44 of the other nodes, and one of these controllers 42, 44 is Provide their control output to aid operation when stopped.

  The bus interface provided by each node 24, 26 in FIG. 2 is a dual interface in that each of the main controller 42 and the management controller 44 has independent access to the main bus 28. However, a single bus interface may be utilized if desired. In addition, as described above, the architecture of the present invention can be used with either a time-triggered protocol bus or an event-triggered protocol bus. When using a time-triggered protocol bus, the architecture of the present invention can be implemented relatively easily because the different nodes are inherently synchronized. When the architecture of the present invention is to be utilized on an event triggered protocol bus, the time synchronization algorithm causes each node / controller to provide data at a predetermined time to at least somewhat synchronize the bus system. Can be implemented.

  The architecture of the present invention can provide communication through other channels of the bus to achieve communication if one channel of the bus fails. In addition, the functionality of the enable / disable pin and its associated logic can be implemented using the co-processor of the associated main controller and / or management controller. As an alternative, the enable / disable function can be implemented as part of an intelligent bus driver or as an independent ASIC. For each main controller 42 or management controller 44, enable / disable functions and bus guardian functionality can be implemented with intelligent bus drivers or independent ASICs. The configuration of the logical structure, including AND gates 64, 66 and OR gate 68, can be modified as desired, but still provide the same overall functionality as the logical structure disclosed herein.

  Although the present invention has been described in detail with reference to preferred embodiments, it is obvious that modifications and variations of the present invention can be made without departing from the scope of the invention.

FIG. 1 is a schematic representation of an automobile using various controllers. FIG. 2 is a schematic representation of the various components that form a single node of the fault tolerance system of the present invention.

Claims (13)

A distributed architecture system for controlling a plurality of actuators,
A plurality of nodes each having a primary controller (42) operatively connected to one of the actuators, each having a primary controller (42) in communication with the associated actuator to provide commands to the associated actuator. Each of the main controllers monitors each other to determine whether the main controller of another node is malfunctioning, and each other node other than the other node is the other node determined to be malfunctioning The plurality of nodes taking the steps of deactivating or disabling the primary controller of
A bus that electrically interconnects the primary controllers (42) of the plurality of nodes to establish communication between the primary controllers (42), the primary controllers (42) being able to monitor each other. makes it possible to the the other nodes that are determined to be malfunctioning by each node other than the node key controller (42) stopped or disabled on each node other than said other nodes, bus And comprising
In order for each node to provide commands to the cooperating actuators from other main controllers (42) of other nodes in response to the cooperating main controller (42) being stopped or disabled. A distributed architecture system comprising a management controller (44) functionally provided in parallel with a cooperating main controller between the node and the cooperating actuator of the node . The determination of one of the main controller of the node (42) is dysfunctional, by the major controller of the management controller (44) and another node for linking nodes that work is carried out collectively claim 1 Distributed architecture system as described in.   The cooperating primary controller (42) and management controller (44) so that the management controller (44) monitors the primary controller (42) to determine whether the primary controller (42) is malfunctioning. 3. The distribution of claim 2, further comprising a serial peripheral interface connection between the primary controller (42) and at least one management controller (44) of the node to directly establish a linkage between Architecture system. The distributed architecture system of claim 1, wherein the primary controller (42) is configured to determine a command to be provided to an actuator of a node having a primary controller that is stopped or disabled . The distributed architecture system of claim 4, wherein at least one of the management controllers (44) is configured to determine a command to be provided to an actuator of a node having a primary controller that is stopped or disabled. .   The distributed architecture system of claim 1, wherein the primary controller and management controller of each node provide an override output when the primary controller is determined to be malfunctioning.   The override output and the command from the cooperating main controller are sent to a first logic function, and the override output and the command output by the management controller are sent to a second logic function. The described distributed architecture system.   The distributed architecture system of claim 7, wherein the first logic function and the second logic function are both AND functions.   9. The distributed architecture system of claim 8, wherein outputs of both the first logic function and the second logic function are sent to a third logic function.   The distributed architecture system according to claim 9, wherein the third logic function is an OR function.   The distributed architecture system of claim 10, wherein the output of the third logic function is sent to a cooperating actuator.   The distributed architecture system of claim 1, wherein the system is an anti-lock braking system (ABS) and each actuator is a brake motor driver that drives a brake motor.   The distributed architecture system of claim 12, further comprising an automobile body having a plurality of wheels, wherein each of the nodes is associated with one of the wheels.

Images