the multiprocessor and multibus system shown in fig1 is a schematic representation of an application taking the form of a data switch . the function of a data switch is to receive digital data introduced by transmission lines 10 and to sort and regroup such data into multiprocessor processing means in order to retransmit them over suitable output lines 10 . in a simplified version of the multiprocessor multibus switch , a management bus 11 , a processing bus 12 , and a switching bus 13 can be distinguished . each one of these buses 11 , 12 , 13 corresponds to a processing module each comprising at least one processor 14 , each being optionally associated with a local memory 15 via a local bus 16 . the switching bus 13 further includes a terminal bus coupling module 17 , which , in association with a processor 18 , manages the terminal transmission bus 19 for connection of the send / receive lines 10 . the management bus 11 further includes a system board 20 , the function of which is to supervise the whole multibus multiprocessor system . the buses 11 , 12 , 13 are for example buses of the xbus type ( manufactures by the french company alcatel cit ) which principally carry five types of signal : each bus receives , for example , sixteen processors as a maximum ( master board ), the other locations being able to correspond to physical addresses of slave boards ( for example memory boards ). the buses 11 , 12 , 13 of the different multiprocessor system modules communicate with each other via bus coupling modules 21 connected in pairwise fashion . fig2 illustrates the structure and operation of a pair of bus coupling modules 22 , 23 providing communication between two buses 24 , 25 . several types of bus coupling modules can be envisaged . by way of example , we could mention here coupling modules the operation of which is of the &# 34 ; mailbox &# 34 ; type . the example discussed here corresponds to operation with &# 34 ; address filtering &# 34 ; which simulates a prolongation of the sending bus . each coupling module 22 , 23 includes , firstly , a receiving module 26 2 , 26 3 for data originating from buses 24 , 25 respectively , and , secondly , a module 27 2 , 27 3 for sending over bus 24 , 25 , data received from the remote coupling module 23 , 22 respectively . as a consequence , connection of the two coupling modules 22 , 23 takes place , firstly , between the receiving module 26 2 and the sending module 27 3 ( data transfer from bus 24 to bus 25 ), and , secondly , between the receiving module 26 3 and the sending module 27 2 ( data transfer from bus 25 to bus 24 ). each of the sending modules 26 2 , 26 3 cooperates with a memory 28 2 , 28 3 carrying specific address tables of remote buses . transfer decisions taken by each coupling module 22 , 23 depends on the content of these address tables . furthermore , each sending module 27 2 , 27 3 cooperates with means 29 2 , 29 3 for managing access to bus 24 , 25 . a detailed example of this type of bus coupling module can be found in the french patent document application no . 82 21401 dated dec . 21 , 1982 . fig3 shows the bus access request logic for each ownership processor of the single bus processing modules 11 , 12 , 13 . the access request logic consists , firstly , of an access allocation system 31 , which is synchronous and distributed , using an arbitration process for access requests 30 expressed by the processors , and , secondly , a bus seizure logic 32 connected to the allocation system 31 by a bus seizure enable or inhibit signal 33 as a function of the result of the distributed allocation operation . the allocation system 31 is made up firstly by a bus request logic 34 , formed by a flip - flop ( not shown ) for synchronizing signals with a clock signal of the allocation module 35 &# 39 ; s clock signal , and , secondly , the actual allocation circuit 35 which receives access request 47 from the logic 34 and is responsible for arbitrating access requests and sending the result 33 of arbitration for the associated processor . arbitration is carried out either using a fixed priority or a rotating priority . the sixteen physical master board addresses connected to bus 12 are divided over two groups of 8 addresses , one group of which has priority ( signal gp /). in each of the groups , priority is assigned via priority signals pr1 to pr7 . the signals gp / and pr1 and pr7 are input / output as open collector signals on the main bus 12 . with fixed priority , priorities increase in an order from 0 to 7 , and are each assigned to one processor connected to a physical address on the bus . definition of the next owner or &# 34 ; master &# 34 ; of bus 12 is performed by logic which overwrites the &# 34 ; 1s &# 34 ; on the signals pr : at the end of an allocation cycle , the arbitration &# 34 ; winner &# 34 ; is the one that belongs to the active group gp and which has its pr line active . with rotating priority , the priority locations ( pr0 to pr7 ) are variable through reassignment of the lowest priority to each board that has seized the bus the most recently . the allocation circuit 35 also includes other lines for communication with bus 12 , notably lines for adr identifying the address of the physical location of the access allocation system 35 ; lines gp / and pr1 to pr7 for indicating the current owner of the bus ( used with rotating priority ), a clock signal line ck for synchronizing all the access allocation modules 35 ; and a bus busy line bbsyg /. when a participating processor is designated , following the allocation operation , it transmits this information to the bus seizure logic 32 , using the allocation result signal 33 . this logic 32 supervises bus 12 , and at the end of the current cycle , takes over the bus and sends a signal 36 to the allocation module 35 authorizing a fresh allocation for the next owner of the bus . the bus seizure circuit 32 , on the other hand , sends over bus 12 an address strobe signal indicating an address is currently in cycle or a data strobe signal indicating data currently in cycle , and receives data acknowledgement signals . finally , circuit 32 also sends signals 37 , 38 indicating ownership of the address bus and the data bus . the board also includes a line 39 for putting allocation module 35 out of operation upon a reset command 40 being issued , or following an external inhibiting instruction 41 , for example a disconnection instruction transmitted by the system board 20 . the bus request logic 34 and bus seizure logic 32 also include respective reset lines 42 , 43 . operation and transfer of data in the system according to fig1 is as follows : the transfer cycles are asynchronous , so that the bus is blocked by the board that has control of it or &# 34 ; master &# 34 ; that is making a request until the moment where the board addressed answers . should there be no answer from the destination board , a &# 34 ; watchdog timer &# 34 ; ( not shown ) is started on the &# 34 ; requesting &# 34 ; board leading to release of the bus and change over to error processing . the bus coupling modules 21 analyze the addresses passing on their bus , and after address filtering , open up a path to the remote bus when necessary . thus , processor 14 connected to bus 11 is able to address processor 14 or memory 15 connected to bus 12 . in this case , the operation first of all blocks bus 11 . the coupling module 21 of bus 11 recognizes the address requested and opens up the path towards bus 12 which it seizes and blocks when the latter is not busy . there is then an answer from the destination end and the sending processor then releases the two buses 11 and 12 upon receiving the answer from the destination end . a transfer from bus 11 to bus 13 will require the use of intermediate bus 12 where a pair of specific coupling modules which directly couple bus 11 and bus 13 are absent . the watchdog timers ( not shown ) on each of the processors are given values so as to allow a transfer to be executed which involves cascading of the maximum number of buses concerned by a transfer to the most remote position . as has already been said in the introduction , interference or disturbance in the signals on a bus , either as a result of a fault in the sending circuit or receiving circuit on a board , or originating from a short circuit in a backplane , leads to allocation modules 35 becoming blocked or to blocking of the bus seizure logic 32 of the boards connected to the bus . when blocking occurs at a moment where the code present on the address bus corresponds to the address of a board which is on another bus , blocking can get propagated to other buses via the bus coupling module boards 21 . in the worst case , complete blocking of the whole multibus system can occur . this is the case for example in the switching system shown in fig1 if interference or disturbance takes place at the precise moment where a data transfer is taking place between bus 11 and bus 13 . by a way of example , a permanent setting to zero of the following signals can lead to a disturbance able to be propagated to several adjacent buses . in the category off signals in which disturbance leads to a blocking of allocation modules 35 , the following ones can be noted : the signal indicating block mode transfer ( bus seizure for several cycles ) the following signal disturbance or interference leading to blocking of the bus seizure logic 32 can be noted : the strobe signal indicating existence of an address or data in cycle on the bus : asg / and udsg /; this list of signals is for illustration and not exhaustive . it should be noted that these signals mentioned cause interference when they are permanently set to zero . permanently setting a signal to 1 , corresponding to its idle or non - active state , does not normally propagate disturbance to other buses . unblocking of the system involves the following functions being put into operation : a faulty bus or processor isolation function , with a possible specific processing for repair of the failed unit . the bus decongestion function which is a constitutive element of the present invention consists in sending a specific and single decongestion signal 45 , shown by a bold line in fig3 . preventing other &# 34 ; master &# 34 ; boards connected to the bus 12 from intervening on the bus . these two functionalities are fulfilled by an action firstly , on the bus request logic 34 and , secondly , via the inhibiting module 44 , through acting on the allocation circuit 35 and the bus seizure logic 32 . signal finhal 46 originating from inhibition module 44 is generated in synchronization with the clock signal ck synchronizing all the access allocation systems 35 , and is held during the whole duration of the single decongestion signal 45 . it travels on the same line as the inhibition signal 39 for the allocation module 35 upon an external instruction 40 , 41 . inhibition of the request supplied to allocation module 35 by the request logic 34 ; reset of the internal bistable in allocation module 35 authorizing participation in allocation and transmission of priority signals gp / and pr1 to pr7 to bus 12 ; reset of the flip - flop generating signal bbsyg / supplying the result of arbitration between the access requests , for the processor involved . secondly , the decongestion signal causes a reset of the internal flip - flop of the bus seizure logic 32 generating signals 38 for gaining control of the address and data buses . stated in other terms , as a result of this systematic action on the access management means of each processor on the bus , release of the bus by the current owner of the bus is ensured together with an assurance that the future owner of the bus deactivates its arbitration &# 34 ; winner &# 34 ; result signal , and finally ensures that no allocation module any longer participates in an access request arbitration operation . the procedure employed then makes it possible to restart the requests that where canceled by action on the bus request logic 34 . thus , the decongestion signal 45 , 46 can be considered as a &# 34 ; super priority &# 34 ; signal for the allocation module 35 . the decongestion process hence causes no disturbance either to the software configuration or to possible bus cycles currently running . fig4 illustrates the deblocking procedure which is implemented in the case where a blocking situation involves several buses . the master board 84 connected to bus 81 is at the origin of a blocking condition in a cycle destined for the slave board 85 connected to bus 83 . the three buses 81 , 82 and 83 hence find themselves in a blocked situation . blocking has for example been brought abut by a situation in which the strobe signal indicating existence of an address in cycle asg / is forced to zero on bus 81 ; it gets propagated over bus 82 and bus 83 in the direction of propagation 87 as a result of the fact that the bus coupling modules 86 12 and 86 23 are involved in communication as a result of the situation in which passing addresses are filtered . the master board 88 , or the system board ( not shown ) detects this blocking of the configuration and will immediately adopt measures to isolate the faulty bus by setting the allocation modules for the bus coupling module boards 86 32 , 86 23 , 86 21 and 86 12 , thereby placing the faulty bus 81 in an inhibited or disenabled state . board 88 sends the decongestion signal over bus 83 , which leads to bus release by bus coupling module 86 32 . board 88 next causes the decongestion signal to be sent by bus coupling module 86 32 and destined for bus 82 via the intermediary of coupling module 86 23 ; this allows bus 82 to be released by deblocking of coupling module 86 21 ; board 88 then writes a disenabling bit for the allocation module of bus coupling module 86 21 , in order to isolate the failed bus 81 ; board 88 next brings successively on bus 82 and bus 83 , the decongestions signal in the opposite state ( idle or non - active level ), in order to restart access requests that were inhibited . implementation of the single signal decongestion means is advantageously carried out in a multibus system having bus coupling modules that are equipped with simultaneous reciprocal access request management means ( collision management ) as described below . in effect , in this case , a highly favorable synergy exists between collision management and decongestion management , from the point of view of their similarity both as regards their structural characteristics and the functional characteristics of the corresponding systems . the collision situation can be illustrated with reference to fig4 . when board 84 wishes to reach board 91 it seizes and blocks bus 81 . if at this precise moment , board 90 wishes for its part , to reach a board 89 , it will seize and block bus 82 . the two buses 81 and 82 now being blocked , the coupling modules 86 12 and 86 12 are not able to answer : we have a collision situation . if no specific unblocking device is provided , the system remains in the blocked state until &# 34 ; watchdog timer &# 34 ; signals appear on the master boards 84 and 90 which will switch over to error processing . in order to avoid this problem , a collision signal colg can be provided on the buses . this signal can be issued by each bus coupling module 86 when a collision is detected by the coupling module . in general terms , for each pair of coupling modules , at the time of first configuration initialization , a priority and a non - priority coupling module are defined if collision occurs , the non - priority module is the one which issues signal colg . this signal is received by all the master boards on the corresponding bus , and brings about two actions : it causes the bus to be released by the board which seized it and is blocking it , by acting on the bus control signals . the board is then disenabled and awaits authorization in order to be able to re - seize the bus and finish its cycle ; it prevents the other master boards from seizing the bus by acting on their allocation system . only the coupling module which issues the collision signal is able to seize the bus , and establish a path up to the destination of the cycle considered as having priority . when the path is set up , the coupling module stops sending signal colg , and the other boards are again able to participate in a bus allocation phase , and then have access to the bus as a function of the results of arbitration . a real synergy hence exists between the interbus collision resolution mechanisms and the multibus system deblocking process . it is hence advantages to use the same decongestion signal for implementing the two mechanisms . fig5 is a schematic representation of the functional modules required on the system board in order to manage sending of the single decongestion signal and to provide collision resolution . in order to put this configuration into practice , it is necessary to add , in the system board , in the uts master boards for the buses and in the bus coupling modules , a bistable circuit able to issue the single decongestion signal . this bistable is program - addressable in the private area of the system and uts boards , and in the coupling area of the bus coupling modules . this decongestion / collision bistable is for example set to 1 by a write cycle and then set to 0 by a further write cycle . the issued decongestion signal is active on all the boards that are present on the bus with the exception of the board that issued it . fig6 shows schematically the arrangement used in the case of a pair of bus coupling modules 61 , 62 providing communication between a first bus 63 and a second bus 64 . the mechanism is represented in one single direction , but obviously operates in a symmetrical manner in the other direction . the collision / decongestion bistable 65 in the coupling module 61 causes the decongestion / collision signal 66 to be issued by the bus coupling module 62 associated with it , and hence on the remote bus 64 . fig5 and 7 show schematically the logic modules needing to be provided in the system board on the one hand , and on the other hand in the bus coupling modules respectively , in order to provide management of the single collision / decongestion signal . as shown in fig5 for the system board , an internal signal 51 for commanding sending of a congestion / decongestion signal is provided by software instruction 52 via flip - flop 53 . the single congestion / decongestion signal 55 is sent on the bus via a buffer circuit 54 . in order to acknowledge single collision / decongestion signals 55 &# 39 ;, which are not always sent by the system board , a buffer register 56 provides reception acknowledgement from the bus . the internal signals 51 from the software command to issue the collision / decongestion signal , and signal 57 originating from buffer register 56 handling reception from the bus , are supplied to an enabling circuit 58 supplying a signal 59 which brings about inhibition of the allocation module and of the bus seizure logic of the board when the collision / decongestion signal does not originate from the system board . a configuration of the same type will be found again in the schematic representation in fig7 which corresponds to the collision / decongestion signal acknowledgement logic in a bus coupling module board . the internal collision signal 71 is generated by an external software instruction 72 via flip - flop 73 . the software instruction originates from the remote bus coupling module ( flip - flop 65 of the coupling module 61 in fig6 ). the internal collision signal 71 brings about sending of the collision / decongestion signal 75 on its bus via a buffer register 74 . the bus coupling module will also issue the collision / decongestion signal 75 upon detection of a double simultaneous reciprocal request 70 , when the bus coupling module board is not the priority one . this situation corresponds to detection of an actual collision on the pair of buses during which the non - priority bus coupling module is inhibiting the requesting entity on its bus . moreover , the bus coupling module acknowledges collision / decongestion signals 75 received from the bus which do not always originate from itself the received collision / decongestion signal 75 &# 39 ; passes through buffer register 76 in order to supply an internal signal 77 connected to one of the inputs of an enabling circuit 78 . this circuit 78 supplies at its output a collision signal 79 to the allocation module and the bus seizure logic of the coupling module . the parameters which control sending of signal 79 are as follows : an enabling signal 92 activated either by the decongestion signal upon a software instruction 72 , or by a signal inhibiting acknowledgement of the collision when there is a double reciprocal simultaneous request in the pair of coupling modules ; a signal designed to cause line bbsyg to be released ( next designated owner of the bus ) at the end of block - mode transfer operations ; these two latter signals arrive for example via the line 93 . the latter signal 93 ( acknowledgement of collision on the remote bus ) is necessary in order to cause release of the priority bus coupling module allocation module which was activated by the non - priority bus requesting entity ( this requesting entity having be disenabled , as already mentioned , by the non - priority bus coupling module ).