Signal Processing System and Method

The present invention relates to digital signal processing, and more particularly to a system and related method for processing digital signals in avionic systems.

With the onset of digital processing in avionics systems, such as airborne radar systems, the mission capabilities of the fighter and surveillance aircraft was radically altered, making it possible to engage and defeat enemy targets at unheard of distances and at unheard of speeds. In the years that followed, the realm of digital processing expanded as new sensors were brought on board the aircraft bringing valuable new information to the pilot. However, as threat technology grew more sophisticated, systems became more complex and more numerous, and pilots found it difficult to make sense of the volume of incoming data. In fact, the pilot became the point of integration for dozens of partially programmable computers attached to a whole array of discrete sensors.

Prior to the present invention, the failure of a component of a system associated with one of the sensors, caused the entire system associated with that sensor to become disabled, resulting in a loss in combat capability. Heretofore, the software for such individual systems was difficult to modify in order to handle the emergence of new or different types of threats. Each addition of a different type of sensor to the aircraft, required an additional dedicated signal processing system. Thus, such prior systems were not only inflexible and difficult to maintain, but also, were rapidly becoming impractical, in that the pilots task was becoming more unmanageable.

One of the advantages of the present invention is the provision a digital signal processing system and related method utilizing a common processor for fusing data from multiple sensors.

Another advantage of the present invention is to provide a digital signal processing system and related method for supporting a plurality of different type sensors that is fault tolerant in the face of failure of components of the system.

A further advantage of the present invention is the provision of a digital signal processing system and related method that is easily programmable to permit changes in the software as new threats emerge or hostile forces develop new tactics.

A still further advantage of the present invention is the provision of a modular signal processing system and related method operable with multiple surface and airborne sensors of different types that permits easy flight line replacement of defective modules, and for easy expansion as new sensor systems are brought on line.

Another advantage of the present invention is the provision of a signal processing system and related method for multiple sensors that minimizes hardware requirements. Objects and other inventions are set forth in part in the description which follows, and, in part will be obvious from the description or may be learned by the practice of the invention. The objects and advantages of the present invention may be realized and attained by means of the instrumentalities and combinations particularly pointed out in the appended claims.

To achieve the objects and in accordance with the purpose of the invention, as embodied and broadly described herein, a digital signal processing system for controlling avionic displays and devices in accordance with processed signals from a plurality of sensors, comprises a plurality of array processor groups. Each group includes bulk memory means for storing sensor received data, signal processing means for processing the stored data, and controller means for handling the storage and processing of the data. Subbus data network means interconnect the bulk memory means, the signal processing means, and control means of each respective array processor group, and also interconnect the plurality of groups in parallel relationship, for storing sensed data in a bulk memory means of a selected group and for processing and transferring the stored and processed data to a selected group in accordance with the control means of a selected one of the array groups. The system further comprises a plurality of individual general purpose digital computers, an input/output module means for receiving and generating instructions to operate the avionic displays and devices; and parallel interface bus means interconnecting each of the genral purpose computers, the input/output module means, and the control means of each array processor group in parallel relationship to one another for generating the signals to operate the display and avionic devices in accordance with the processed signals.

FIG. 1 is a broad schematic block diagram of a signal processing system in accordance with one embodiment of the present invention;

FIG. 2 is a broad schematic block diagram of a signal processing system and method of the present invention illustrating exemplary types of modules that may be used therewith;

FIG. 3 is a schematic block diagram of an array processor group of modules utilized in the system of the present invention;

FIG. 4 is schematic diagram illustrating the flow of information between an array processor group and a general purpose computer in the system and method of the invention;

FIG. 5 is a schematic block diagram of a DP processing module that may be used in the system of FIG. 2;

FIG. 6 is a schematic block diagram of a systolic vector processor module which may be used in the system of FIG. 2;

FIG. 7 is a schematic block diagram of a typical non-volatile memory module that may be utilized in the system of FIG. 1;

FIG. 8 is a schematic block diagram of a typical 1750A general purpose computer utilized in the system and method of the

FIG. 9 is a schematic diagram illustrating the functional subbus data network interconnect of the bulk memory module and the signal processing module of the array processor group of FIG. 3;

FIGS. 10 through 19 are diagrams of different addressing styles for the processor bulk memory of FIG. 3;

FIG. 20 is a flow diagram illustrating an example of application process scheduling in the system of the present invention; and

Referring to the drawings where like reference characters refer to like parts, there is illustrated and described a digital signal processing system for controlling avionic displays and devices in accordance with processed signals from a plurality of sensors. As embodied herein and referring to FIG. 1, a digital signal processing system generally referred to as 30, comprises a high speed setup bus data network 32, which is referred to herein as a subbus or a data network, or at times a subbus data network and a dual parallel interface (PI) bus 34. System 30 includes array processor group modules 38 and 40, VHSIC 1750A general purpose computer modules 42 and 44, a 153B input/output module 46, a user maintenance console interface (UMCI) module 48, a sensors interface module 50, and a video interface module 52.

All of the system modules are connected in parallel to TM bus 36 by respective input/outouts 64 through 71 inclusive for booting and maintenance of the system. Each of modules 42, 44, 46, and 48 has a control input/output 72 through 75 inclusive connected in parallel relationship to dual PI bus 34. Modules 38, 40, 50 and 52, each have a control input/output 76 through 79, inclusive, connected in parallel-relationship to PI bus 34; and also a signal input/output 91 through 94 connected in parallel relationship to high speed subbus data network 32.

In accordance with the invention the system includes parallel interface bus means interconnecting each of the genral purpose computers, the input/output module means, and the control means of each array processor group in parallel relationship to one another for generating the signals to operate the display and avionic devices in accordance with the processed signals. As embodied herein PI bus 34 provides an intermodule, redundant communication path for the transfer of control information and other high level data messages over the above mentioned control input/outputs of the connected modules.

The invention includes subbus data network means interconnecting the bulk memory means, the signal processing means, and control means of each respective array processor group, and interconnecting the plurality of groups in parallel relationship for storing sensed data in a bulk memory means of a selected array group and for processing and transferring the stored and processed data to a selected array group in accordance with the control means of a selected one of the array groups. Preferably, and as herein embodied data network 32 is a high bandwidth, quickly reconfigurable data network for intermodule exchange of signal processing data over the signal input/outputs of the connected modules. This arrangement of the various modules with PI bus 34 and data network 32 implements the needs of radar electro optics, electronic warfare, and segment signal processing wherein the input data rates through sensors interface module 50 are high and the output data comprises both a video display through video interface 52; and narrow band target messages and control commands through input/output module 46. Up to 31 module groups are able to be supported by PI bus protocol so that signal processing systems of up to 10 billion operations per second (BOPS) and up to 80 million instructions per second (MIPS) can be transferred. Data network 32 may take either one of two modular forms depending on the size of the system. For smaller systems, typical of present radar requirements, data network 32 may comprise four 40 Megabyte per second buses. For larger systems the buses are interconnected by an active crossbar network, referred to herein as a WEB, which also transfers data at 40 Megabytes per second per connection. Data network 32 transfers data for coherent vector processing prior to primary thresholding, and PI bus 34 transfers data used in target-space, scalar processing after target detection.

In accordance with the invention, the system has a plurality of array processor groups, each group including bulk memory means for storing sensor received data, signal processing means for processing the stored data, and controller means for handling the storage and processing of the data. As herein embodied, and referring to FIG. 1, array group 38,40 respectively include controller 106, 106', signal processing modules 108, 108' and 109, 109', and processor bulk memory module 110, 110'. It is intended that vector oriented signal processing tasks be carried out on array processor groups 38 and 40, which are each capable of 640 million operations per second (MOPS).

The system of the present invention includes a plurality of individual general purpose digital computers. As herein embodied general purpose processing modules 42 and 44, are well known computers known as 1750A, one of which is provided for redundant backup, are utilized by the system for high level scheduling of the array processor groups 38 and 40, and the tracking of a modest number of targets.

The invention further includes an input/output module means for receiving and generating instructions to operate the avionic displays and devices; and user maintenance console interface module for use during field diagnosis and software development. As herein embodied, a well known input/output device 46, known as a 1553B device, and module 48 is coupled to PI bus 34. Module 48 includes a master clock that operates at 40 MHz which frequency is conventionally divided and inverted for obtaining a clock rate of 20 MHz on subbus 32 and 12.5MHz on P1 bus 34.

Referring to FIG. 2, a digital signaling processing system generally referred to as 112, is shown with additional modules that may be used for systems with special requirements. For example, where surveillance radar is one of the types of sensor inputs, data processing group 114, which may comprise up to sixteen individual 32 bit data processors for handling targets held in track, because, there is the need to track or otherwise process many more targets passing the primary thresholds. A thousand targets held in track is not unusual, with false alarms generating an additional few thousand tracks that are held for only a few scans. Networking further adds to the load by expanding the field of view beyond that of the local sensor. In this application, raw thresholded data is brought from interface 50, over output 93, and data network 32 directly into group 114 over output 116; and off- loading PI bus 34 of primary data crossings over input/output 46 through connection 118. A non-volatile memory module 120, which is used for the storage of executable images and fault logging also may be included.

For applications where unique requirements must be met, system 112 may utilize in addition, a systolic type vector processor 122. Module 122 is a high performance two BOPS programmable module that is most efficient on structured signal processing problems typically found at the front-end of the signal processing chain. The bandwidth of data network 34 permits a module, such as 122 to be incorporated into the system of the present invention.

Referring again to FIG. 1, each one of the similar array processor group modules 38,40 comprises an array processor controller (APC) line replaceable module 106, 106' a signal processing module (SPM) pair 108 and 109, 108' and 109' respectively, and a processor bulk memory module (PBM) 110, 110'. Because module groups 38 and 40 are similar, group 38 will be described in detail in FIG. 3 wherein the controller is in block 106, signal processing module in block 108, processor block memory in block 110, and dta network associated with group 38 in block 32, all as defined by a continuous solid line boundary.

Referring to FIG. 3, APC module 106 is connected to SPM modules 108 and 109 over lines 124, 125, and 126. SPM modules 108 and 109 are connected to PBM module 110, through data network 32 by lines 130. In turn, PBM module 110 is coupled to APC module 108 at connection 127. As embodied herein, array processor controller module 106, which provides embedded control to AP group 38, contains 256K of memory for a distributed operating system, hereinafter described, and local storage. APC module 106 governs the communication between modules 108, 109, 110, and the outside world. Signal Processing modules 108 and 109 provide the high speed processing functions for AP group 38. SPM modules 108 and 109 receive sensor data from data network 32 via PBM module 110 at input/output 91 of the data network, and perform signal processing instructions under the control of APC module 106 on lines 124, 125, and 126. Intermediate results of signal processing from SPM modules 108, and 109 are returned to PBM module 110 for transfer to another functional element of group 38 or to data network 32 at connection 130.

As herein embodied, processor bulk memory module 110 contains 256K of static RAM for storage of input data, partially processed data, or fully processed data ready for output to video interface 52, for example.

Referring again to FIG. 3, APC control module 106 contains two pair of embedded control VHSIC 1750A central processing units 131 and 132, a boot sequencer 133, a console interface 134, and a PI bus interface 136. One CPU 140 of the pair 131, and one CPU 142 of pair 132 are connected by control subbus 144, at times referred to hereinafter C to C bus, in common with boot sequencer 132 and console interface 134. PI bus interface 136 is connected to CPU 132 at line 146. Another of the pair of CPU's 131, referred to as 141 is connected functionally to PBM module 110 by line 127. Another of the pair of CPU's 132, referred to as 143 is connected functionally, and in the present embodiment physically to SPM module 108 and 109 over lines 124 and 125, respectively.

CPU 140 of pair 131, and PCU 142 of pair 132 handle all traffic on PI bus 34 and overall system topology, as well as interpreting messages received, and initiating the appropriate response. CPU 141 of pair 131 controls PBM module 110, and CPU 143 of pair 132 runs an application program that calls signal processing procedures to perform the signal processing tasks. The signal processing procedures themselves execute on the SPE array and operate on data vectors initially supplied from the PBM.

Each of SPM modules 108 and 109 contain eight signal processing elements SPE-0 through SPE-7 for a total of sixteen SPE elements, and a local I/O switch (SPEWEB) 148. Switch 148 also includes a look up table 150 for use by the SPE array. Modules 108 and 109 also each contain a micro-code sequencer 152, a resident memory 154, a memory addresser 156, an indexer 158, a global constant store (GLOK) 160, and a signal instruction controller 162. Each of the SPE portions represented by element SPE-7 contains an 8K by 16 local memory, a 32 word multi-register file 166 (SPE DATA SLICE), an arithmetic logic unit 168, and a multiplier 170 to implement 16 bit integer arithmetic operations at 20MHz. I/O switch 148 is connected to each of SPE's 0-7 by lines 172 of module 108, and connected to module 109 by input/output lines 174 and 175. An I/O switch 149, similar to switch 148, is connected to module 109 by lines 173 and 177. Switches 148 and 149 are connected to each other by lines 181 and 183. Micro-code sequencer 152 is connected to switch 148 at line 176, and local memory 154 is connected via line 178 to switch 148. Addresser 156, indexer 158, store 160, and controller 162 are connected to micro-code sequencer 152, referred to also as a micro instruction counter (MIC) through lines 180,182,184, and 186, respectively.

The SPE's of SPM 108 all operate in parallel under the control of a 64 bit micro-code word resident in the SPM module. The SPE array represents a single instruction, multiple data architecture. Each SPE receives a portion of a large data set and processes it under the direction of common APC controller 106. Local memory addresses in addresser 156 and global constants in module 160 are received from APC 132 over line 124. Local memory in each SPE, represented by block 164 is a single port high speed memory which can execute a read or write operation on every clock cycle. Memory addressing is provided by (MIXR) 156 or may be provided by using a data addressing capability resident in every SPE. Data addressing permits each SPE to calculate a distinct address, with ALU 168 or multiplier 170 generating the address. Also, SPE memory 164 is able to perform conditional memory writes, which are based on the state of a flip-flop (not shown) in the conditional logic associated with ALU 168. The state of the flip-flop may also be complemented to permit the use of an "if" condition; or writing to memory may also be executed under the control of a loop sensitive suppression feature. SPE register file 166 contains thirty-two distinct registers, twenty-eight of which are general purpose. The remaining four registers are dedicated to a unique purpose, such as input/output, global constants memory access, and memory access. Register file 166 has five output ports, namely output ports X and Y reresented by line 190 which are input to multiplier 170, A and B ports 192 input to ALU 168, and autostuff port 172. Register file 166 also has three input ports, also referred to by reference numerals 190, 192, and 172 output from multiplier 170, ALU 168, and SPEWEB 148, respectively. Any register 166 may be accessed by one or all of the five output ports, but only one register may be written for each of the three input ports. The autostuff port is used to manipulate data in the register file without utilizing ALU 168 or multiplier 170 during a macro instruction.

ALU 168 contains the necessary logic to implement many different signal processing algorithms. The major elements (not shown) include a core arithmentic logic unit, a barrel shifter, a Q circuit, and the conditional logic circuit, the function of which was previouly mentioned.

The core arithmetic logic unit provides all the standard functions, namely, add, subtract, and, or, etc. Output of ALU 168 may also be scaled by a factor of two for some arithmetic operations without having to use the barrel shifter. The barrel shifter implements one clock N bit logical, algebraic, or circular shifts for single precision data. Double precision shifts are performed in two clock cycles. The Q register contains the number of positions to shift the operand, where zero is interpreted as no shifting, a positive number implies a left shift, and a negative number implies a right shift. Multiplier array 170 supports a pipelined sixteen bit by sixteen bit integer multiplication in a single clock time. Double precision multiplications are supported at a lower clock rate without the need for any external summation of the partial products. The throughput rates for multiplier precision are as follows: (a) sixteen by sixteen -one clock- (b) sixteen by thirty-two -two clocks- (c)thirty-two by thirty-two--four clocks--(d) sixteen N by sixteen -N clocks-(e) sixteen N by sixteen M --(N+1)M clocks. Examples (a) and (b) above assume that only sixteen and thirty-two bits of the product are required. If the entire product is required, then an additional clock time should be added per sixteen bit word. Example (d) can be performed entirely within the multiplier. However (e) requires partial product summation support from the ALU for (N+1)M clock cycles. The output of the multipier is passed through a barrel shifter which is used for scaling the products. Products may be scaled by a factor of 2 to the nth power where N is any whole integer from zero to forty-eight. Additional functions supported by multiplier 170 include single precision addition, single precision subtraction, single precision absolute value, and pass data mode.

As will be described in more detail in connection with the description of high speed data network 32, I/O switch (SPEWEB) 148 provides four different I/O operations, namely, (1) SPE to SPE transfers, (2) SPE to PBM/PBM to SPE transfers, (3) SPE to APC/APC to SPE transfers, and (4) SPE table lookups. Three different kinds of operation of (1) above include broadcast transfers where one SPE is selected to provide data to all other SPE,s; adjacent SPE transfers wherein data is exchanged between adjacent SPEs in either a clockwise and counterclockwise direction; amd order table transfers wherein a table stored in 148 are used to implement any type of SPE to SPE transfer, including both broadcast and adjacent types. Broadcast and adjacent transfers are carried out at a 10MHz rate, while order table transfers are performed at a 5MHz rate, i.e., each SPE can source and sink a data word every four clocks. SPE to PBM/PBM to SPE transfers are routed through switch 148. Any SPE can either send or receive data from any PBM bulk memory element, hereinafter described. The SPM to PBM interconnection logic supports a 5MHz data rate per SPE. SPE to APC/APC to SPE transfers provide flexibility in the general SPE I/O area. They are useful for sending small amounts of processed data back to the controller 106 for further processing, or for sending the results back to the next higher level controller, or for making program flow decisions in APC module 106 based upon processed data. APC to SPE transfers are useful for downloading a unique data value into each SPE as opposed to the capabilities provided by global constants memory indexer 158. However, indexer 158 has double buffering. Lookup table transfers from 150 are used to generate complex transcendental functions, division algorithms, or any other functions not readily implemented by ALU168 or multiplier 170. In the lookup transfer type, each SPE calculates and sends a unique value to table 150 and receives back the additional value. Two physically separate tables 150 are provided in each SPM 108 to speed up the lookup process, which may be performed at a 5MHz rate per SPE.

PBM module 110 contains eight bulk memory elements BME-1 through BME-8 and a local I/O switch (PBMWEB) 194. Each of the BME elements represented by BME-8 contains a random access (RAM) memory 198 and an indexer (SPIXR) 199. Module 110 also comprises a micro-code sequencer, a memory addresser, and an indexer, similar to module 108, all referred to at block 196. A resident memory is referred to at block 200. PBM module further comprises a memory (CASMEM) 204, a controller interface unit (ASIU) 206, an arbiter 208, and an arbiter memory 210. Functionally, PBM module has associated therewith controller 131, which in the present embodiment is physically located on APC module 106.

BME's 1-8 are connected in parallel to I/O switch (PBMWEB) 194 by lines 212. Switch 194 is connected to microcode controller 196 by line 214. In turn BME's 1-8 are connected in parallel to controller 196 by lines 216. Local memory 200 is connected to controller 196 by lines 218 and 219; amd ASIU 206 is connected to micro-code controller 196 and arbiter 208 by line 220.

Functionally, PBM comprises one pair of fully compliant MIL-STD- 1750A CPU's 131 with 32K.times.16 of shared memory, and a dedicated hardware unit within dashed lines 222 that allows the CPU's to direct the array of eight bulk memory elements BME-1 thru BME-8. I/O channels 212 of PBMWEB switch 194 permits access of the BME's to the outside world. In the present embodiment, the CPU,s 131 and hardware unit 222 are physically located on APC module 106. CPU 140 of pair 131 is used primarily to accept requests for PBM 110 services from PI bus 34. CPU 141 of pair 131 services each data request by setting up the resources of lower level hardware. An alternate form of an I/O data request is provided primarily for inter-processor communications wherein control words are sent to CPU 140 over subbus 144, instead of PI bus 34. PBM microcode controller 196 consists of a controller and a 4.times.4 microcode memory. The microcode memory holds a fixed set of PBM input/output instructions that are parameterized and called from controller 141 of pair 131.

RAM 198 of each BME 1-8 may be a 32K.times.16K static memory with a cycle rate of 20MHz, or a 128K.times.16K dynamic RAM (with error detection and correction) with a clock rate of 5MHz. Indexer (SPIXR) 199, which generates addresses and provides input/output data for RAM 198, can provide linear, interval, PST addressing, and provide for 16 bit and 32 bit data addressing. Indexer 199 also provides all the necessary input/output capability for RAM 198, including error detection in the dynamic RAM version.

Input/output switch 194 is a full crosspoint switch that couples the eight elements BME 1-8 to any subset of eight external input/output ports in order that ay user on any set of input/output ports has access to the entire address space of processor bulk memory 110. Switch 194 also performs the data formatting required by the PBM. Switch 194 connects to a standard interface device 230 to talk to data network 32 over input/outputs 91. Data network 32 provides the necessary handshaking and buffering to coordinate individual data transfers. The configuration of high speed interconnect switches 149, 194, 230, and 231 is system dependent, but always consists of a set of switching elements referred to as SIWEBSs. The creation of a path through the data network may be described as a set of standard SIWEB controls. Once SIWEB controls are established, data network 32 protocols are used to transfer the data.

SPE array SPE 0-7 works in conjunction with PBM 110 which serves to buffer data that SPE's are to process. PBM 110 may consist either of 256K word of static random access memory assuming 8K.times.8 SRAMs or of 1 Mword (assuming 32.times.8 SRAMs) for buffering data including data from other processors. It communicates with SPE arrays over high speed data network 32, and with its own CPU controller 128, can simultaneously service several users; that is, an SPE array, sensor, or other processor, up to a 160 MHz 16-bit word rate capacity.

Array processor 38 is fully programmable at all levels. A main user application program executes on APC 132. The user program sends controls to PBM 110 so that it can collect a data set from a sensor or other processor for processing. The application program then executes a series of procedure calls to SPE array processing procedures, or to PBM input/output procedures to accomplish signal processing tasks.

Reference is made to Appendix G, pages 1 and 2 which lists algorithms that may reside in the signal processing instruction library of the array processor group which are common to and exemplifies a plurality of sensors, such as radar and electronic warfare.

SPE processing procedures may be drawn from a standard library, or custom coded by the user; PBM input/output procedures are standard for all users and are provided in a standard library of signal processing instructions. In addition to supplying data vectors for the SPE array, PBM 110 can also be used to store intermediate results from the SPE array, or to transfer data to another functional element in the group or to data network 32.

For a more detailed understanding of the distributed operating system DOS for PBM 110 reference is made to Appendix A pages A1 through A22 wherein PBMC-A refers to CPU 140 and PBMC-B refers to CPU 141 of FIG. 3.

This Appendix A outlines the commands that invoke the use of the PBM and devices on the C to C subbus 144.

FIGS. 10 through 19, which are self explanatory, illustrate the different addressing styles available to access a PBM file. The PBM's file dimensions are twelve rows by eight columns of data elements. Each data element may contain from one to sixteen words. Single real data take up one word and quad floating point data take up to sixteen words per matrix element. Although FIGS. 10 through 19 illustrate a four SPE system, such a configuration is selected merely for illustrative purposes.

The user interface makes use of the PBM similar to disk usage in a mainframe system. At the lowest level of data specification is the (data) file, which is comprised of X rows and Y columns. An example of a PBM file is presented in FIG. 10. Files are grouped into volumes. A volume of files defined as those files that will always be on the same PBM. Therefore, each PBM will contain at least one volume but not more than N volumes, where N is the number of PBM files. Due to the bookkeeping PBM DOS must perform, the fewer volumes in a system, the more efficient PBM DOS will be.

Files stored in the PBM in one of a variety of formats, referred to as "File Storage Styles." The styles can be grouped into two categories: Formatted and Unformatted. Unformatted files are those files whose internal data structure is dictated by the user. PBM DOS only sees these files as occupying a certain number of rows and columns in the PBM. Formatted files, on the other hand, have their content structure dictated by PBM DOS. These files are distributed throughout the PBM to provide special addressing capabilities initiated by PBM DOS through a macro call. The storage styles define how a file may be accessed and by whom. When single external elements are referred to as the accessing elements, the reference is to either the PBM Controller 131 (PBMC) or system elements on the Data Subbus such as the Input Buffer and Output Buffer. When multiple elements are described as the accessing elements, the reference is to a multi-element PBM or a multi-element SPE Array. With this information in mind, the file storage styles are:

*Unformatted

Global--The file is stored in one BME of the PBM. The file may be accessed by any of the SPEs.

Local--The file is stored as an extension of each SPE's local memory. Each BME's portion may be accessed only by that BME;s associated SPE.

*Formatted

Row Conversion--The file is stored throughout the PBM such that single external elements may access this file by rows only.

Column Conversion--The file is stored throughout the such that single external elements and multiple elements may access this by columns only.

Row or Column Access--The file is stored throughout the PBM such that multiple elements may access it by either row or column.

Several different methods of transferring data to and from files exist. The different methods of transferring data are referred to as "Addressing Styles." A description of each type of addressing style follows.

Linear addressing may only be used on files of LOCAL or GLOBAL storage style. The `Row Or Column` parameter defines the transfer to be either a row transfer or a column transfer. Linear addressing begins accessing at the point defined by the `Initial Row Or Column` and `Initial Row Or Column Element` parameters, accessing data elementts "Increment` elements apart. The transfer is complete when either the "Number Of Rows Or Columns` or `Number Of Matrix Elements` are transferred (only one of which may be specified). Examples of how to access a file with Linear addressing are shown in FIGS. 11, 12 13, and 14 herein.

Interval addressing may only be used on files of LOCAL or GLOBAL storage style. The `Row Or Column` parameter defines the transfer to be either a row transfer or a column transfer. Interval addressing begins accessing at the point defined by the `Initial Row Or Column` and `Initial Row Or Column Element` parameters, accessing data elements `Increment` apart for `Interval` data elements, at which time the addressing increments by `Alternate Increment.` The transfer is complete when either the `Number Of Rows Or Columns` or `Number Of Matrix Elements` are transferred (only one of which may be specified). Examples of how to access a file with Interval addressing are shown in FIGS. 11, 12, 13, 14, and 15 herein.

PST addressing may only be used on files of LOCAL or GLOBAL storage style. PST addressing is comprised of two set-up transfers and then the data transfer. The first set-up transfer is a PBM to SPE Array transfer that gives the SPE Array portions of pulse vectors. This transfer will probably be accomplished via Interval addressing. After executing a sort algorithm on these pulse vector portions, the SPE Array writes information back to the PBM that links the pulse vectors together as a linked list as the second set-up transfer, again probably through Interval addressing. Finally, the actual PST data transfer may occur upon request from the SPE Array. The PBM will broadcast to all SPEs data words beginning at `Start Address`+`Offset To First Word.` `Words Per Record To Fetch` are transmitted before the `Offset To Link` is implemented to determine the next record's location. When the Link field is equal to the `End Of Data Value,` the transfer is complete. An example of how to access a file with PST addressing is shown in FIG. 16.

By Row addressing may only be used on files of ROW.sub.-- CONVERSION or ROW.sub.-- COL.sub.-- ACCESS storage style. This addressing style provides few options. By Row addressing begins accessing at the point defined by the `Initial Row Or Column` and `Initial Row Or Column Element` parameters, accessing either `Number Of Rows Or Columns` or a contiguous `Number Of Matrix Elements` (only one of which may be specified). Examples of how to access a file with By Row addressing are shown in FIGS. 11 and 12.

By Column addressing may only be used on files of COL.sub.-- CONVERSION or ROW.sub.-- COL.sub.-- ACCESS storage style. This addressing style provides few options. By Column addressing begins accessing at the point defined by the `Initial Row Or Column` and `Initial Row Or Column Element` parameters, accessing either `Number Of Rows Or Columns` or a contiguous `Number Of Matrix Elements` (only one of which may be specified). An example of how to access a file with By Column addressing is shown in FIG. 14.

By Segmented Row addressing may only be used on files of ROW.sub.-- COL.sub.-- ACCESS storage style. This addressing style provides few options. By Segmented Column addressing begins accessing at the `Row Or Column` parameter, accessing `Number Of Rows Or Columns` columns. An example of how to access a file with Segmented Column addressing is shown in FIG. 18.

By Partial Row addressing may only be used on filed of ROW.sub.-- COL.sub.-- ACCESS storage style. By Partial Row addressing begins accessing at the point defined by the `Initial Row Or Column` and `Initial Row Or Column Element` parameters. The transfer accesses the `Number Of Matrix Elements` per row, skipping `Column Delta` elements between each element access. The transfer completes when `Number Of Rows Or Columns` rows have been traversed in this manner. An example of how to access a file with Partial Row addressing is shown in FIG. 19.

PBM Lookup addressing may only be used on files of LOCAL storage style. This type of transfer occurs when the SPEs use the PBM as a lookup table, thus the SPE Array will provide the necessary addressing parameters to perform the lookup. PMB Lookups may result in data flow from the PBM to the SPE Array in the case of a Lookup Table Read, or in data flow from the SPE Array to the PBM in the case of a Lookup Table Write. PBM DOS becomes involved because PBM DOS must know that the PBM is being accessed and set up the PBM for the data transfer. The lookup completes when `Element Count` matrix elements have been transferred.

Copy addressing may only be used on any file for PBM to PBM transfers only. The `Row Or Column` parameter defines the transfer to be either a row transfer or a column transfer. Copy addressing begins accessing at the point defined by the `Initial Row Or Column` and `Initial Row Or Column Element` parameters, accessing data elements in a contiguous manner until `Number Of Rows Or Columns` or `Number Of Matrix Elements` are transferred. Copy addressing accesses a file the same way as Linear addressing with `Increment` set to 1, An axample of this type of Linear addressing transfer is shown in FIG. 11.

Again, in PBM-related transfers, a single element may be one BME, one SPE, the PBMC or an external device, and multiple elements may be a PBM (multiple BMEs) or an SPE Array (multiple SPEs). The terminology for a legal transfer as follows:

SS to SD=Single source to single destination. A transfer of data from one element to another, e.g., one BME to one SPE.

SS to MD=Single source to multiple destinations. A transfer of data from one element to multiple elements, e.g., an external device to the PBM.

MS to SD=Multiple source to single destination. A transfer from multiple elements to a single destination, e.g., the PBM to an external device.

MS to MD=Multiple source to multiple destinations. A transfer from multiple elements to multiple destinations, e.g., the PBM to the SPE Array.

In summary, and referring to FIG. 4 therein the sytem of the present invention provides for data flow as represented by the double lined arrows of FIG. 4 therein. As represented by arrow A, data information from multiple sensor input 50 flows through subbus data network 32 for processing by array processor group 38,40 where the data is processed. The processed or partially processed data, representative of target reports or other post detection information, for example, is transferred from the AP group over PI bus 34 to general purpose computer 1750A 42,44, as represented by arrow B. Computer 42,44 in response to information over arrow B and mode commands over arrow C from I/O module 46, processes and transfers over PI bus 34 signal processing mode commands to AP group 38,40 as represented by arrow D. Control and narrow band data flows into and out of module 46 as represented by arrow E.

For a more detailed description of DP module 114, discussed in connection with FIG. 2, reference is made to FIG. 5. wherein data processing group module 114 comprises a set of 32- bit processor modules 240, 242, 244, and 246, which are interconnected as a transparent multi-processor subsystem by a oair of 32- bit buses 248. Data processing group 56 also includes global RAM modules 250 and 252, connected to buses 248, and an input/output module 254 coupled to one of the buses 248. In the preferred embodiment, there are up to 16 processor modules 240, 242, 244, 246, 248, connected in parallel to interface bus 34 by lines such as 86. Input/output module 254 is connected to data network 32 over line 93. Each processor is a single board computer with 512K bytes of RAM, 128K bytes of PROM, two serial input/outputs such as 256 and 258, and programmable timers (not shown). Each of the processors may be similar to the conventional 32- bit processor manufactured and sold as Model 60820 by Motorola, which can handle 2.5 million instructions per second at a 16MHz clock rate. This group of data processing modules is for demanding data processing applications, such as target extraction, sensor control, sensor networking, sensor fusion, and tracking. These data processing applications may be contrasted with typical radar signal processing, in that the execution stream is not able to be vectored, the algorithms contain many conditional tests and branches on tests, and the program flow is highly dependent on the various values of the input data.

Processor modules 240, 242, 244, and 246 within group 114 are interconnected by multiple buses as a tightly coupled, shared memory multiprocessor. Group 114 is modularly expandable from one processor module to sixteen processor modules, plus another sixteen modules of global memory or input/output, as required. Each processor and global module within group 114 supports communication over at least two buses 248. Buses are typically in use simultaneously. However, in the unlikely event a bus fails, all accesses can be routed over the remaining bus. Intercommunication buses are clocked at 20MHz, with the peak single word communication rate being about 6.7 million accesses per second per bus 248.

Large groups of more than eight processors, such as 240, may be served by a four bus intercommunication network having an aggregate single word communication rate of about 26.8 million accesses per second or in other words 107 million bytes per second. Even applications having the four bus network, no physical module need support more than two intercommunication buses. The shared memory paradigm as shown in FIG. 6 is still an accurate programmers model for a four bus network, because application programmers need not be aware of the number of buses. All arbitration and low level coordination is performed in hardware.

Applications for the data processing group 114 are as are the other application programs herein, programmed in ADA. Intra-group task scheduling is performed by a multi-tasking, multi-processing operating system that can dynamically or statically allocate tasks to physical processors. The application programmer need not be aware of which physical processing module is to actually execute the task. Thus, the operating systems task allocation procedure is also said to be transparent. In the event processor modules such as 240 have special resources; for example, the PI-Bus is connected to a particular processor module, tasks needing the special resource can be declared local and will always run on the selected processing module.

Systolic vector processor module 114, which was discussed in connection with the description of FIG. 2 is described in more detail in connection with FIG. 6 wherein processor 122 comprises a RAM 260 for storing data, a RAM 262 for storing constants, twelve complex arithmetic units (CAU) refered to at 264, and four memory address generators (MAG CAU) referred to at 266. There is also provided a program memory 268 and a systolic array control 270.

RAM 262 is connected to provide constants to CAU's 264 over lines 272; and RAM 260 provides input data to the CAU's over lines 274 and receives data from the CAU's over lines 276. Complex arithmetic units 264 are interconnected in a two dimensional array of single chip systolic elements for the completion of full five stages of processing before the data must enter memory 260 or be recycled again over lines 274 through the array of systolic units 264. Single chip systolic element 264, which is the heart of the systolic vector processor, supports a throughput of 150 million operations per second at a clock rate of 30MHz.

As shown in FIG. 6, the CAU,s serve not only as the arithmetic systolic elements, but also as the memory address generators for for data RAM 260, Constants RAM 262, and program memory 268. Module 58 performs arithmetic in a variety of computational forms, including integer computation in any multiple of sixteen bits and single or double precision floating point. At 30MHz module 58 can sustain 2.4 billion operations per second, 180 million complex operations per second, or 288 million floating point operations per second. These different formats can be intermixed clock to clock because all microcode is stored on chip in a micro instruction store.

The systolic vector processor is particularly suitable for signal processing that includes pulse compression, adaptive beam forming, FFT's, and multi-dimensional filtering and correlation.

Memory module 120, which was referred to in connection with the discussion of the system of FIG. 2 is shown in more detail in FIG. 7 wherein module 120 may provide 2,048K words of program storage for the entire signal processing system; and preferably includes memory stores 280, 282, and 284, with corresponding indexers 286, 288, and 290; and asynchronous interface unit 292. Memory 120 may be used for initial program downloading at power up, and for dynamic program overlays during system operation. Unit 292 receives requests from PI-bus 34, which transmits address requests over line 294 to indexers 286, 288, and 290. Storage 280, 282, or 284, as the case may be transmits and receives data on lines 296, 298, or 300, at the proper address selected by information on lines 302, 304, or 306.

Referring to FIG. 8, there is illustrated schematically well known 1750A computer 42, 44, which includes a memory management unit 310, a central processing unit 312, a memory 314, and a bus interface unit 316. Modules 42,44 provide data processing functions, for both the processing system and for partially or fully processed signals; and also provides executive functions for the distributed operating system hereinafter discussed. Modules 42,44 interface to PI-bus 34 to pass data and control messages between the modules 42, 44, and other modules including AP group modules 38,40 coupled to the PI-bus. Computers 42,44 have a 12.5MHz transfer rate,labelled addressing, thirty-two module capability, and a fault tolerant design that includes bus level redundancy, control signal redundancy, and parity.

Referring again to FIG. 1, high speed data network referred to at 32 for interconnecting the signal processing inputs and outputs of the system modules therein, is shown in more detail in FIG. 3 in connection with group 38. The data network may be considered to include for each module or module group one or more WEBs, which are input/output switches for creating data paths. Associated with processsot bulk memory 110 of array processor 38 of FIG. 3 is a "local" PBMWEB 194 and a subbus interface (SI) WEB 230. An asynchronous interface unit (ASIU) is coupled to SIWEB 230. As previously mentioned in the present embodiment of the invention, the signal processing modules, such as 108 109, include local SPEWEBs 148 and 149, respectively that are coupled to subbus data network switch SIWEB 231. Asynchronous interface units ASIU 233 and 237 interconnect SIWEBs 230 and 231 at lines 120.

Data network 32 in the present system performs the function of signal processing data transfer wherein blocks of data to be processed are transferred from one element of an array, such as SPE, BME, for example. This is a critical data network application and it is measured by the maximum rate at which blocks of words can be moved into or out of an elemental array. This rate is the product of the word rate of each bus times the number of buses used. Thus, it is advantageous to keep the number of input/outputs small, so that the available number of input/outputs can support as many buses as possible. For sixteen bits of data the subbus requires only two control bits per input/output port plus one bit for a clock if it is necessary to cross an asynchronous boundary.

Data network 32 may also provide internal control of a particular module. Each module has at least one CPU that controls the SPE's or the BME's, for example. In the SPE array, for example, one of the controllers 152 sets up each macroinstruction execution by giving the SPE's the initial microcode address, instructing the number of times to repeat the loops in the microcode, what initial scratch memory addresses and increments to use, etc. Such setup operations require outputting small quantities of data to each of several different ports; and consequently the agility of the bus is more important than its ability to transfer large contiguous blocks of data at maximum speed. Since there is normally only one bus master, the time required to resolve bus contention (hereinafter described) is unimportant for setup transfers.

Data network 32 may also provide controller to controller transfers. Since many controllers are connected to a common bus, they must contend to get control of a bus each time the controllers send a message. Here, bus contention time is critical, agility is unimportant, and the data transfer rate is usually less important because most messages are short. It is also important that the system has the capability to connect as many ports as possible to a common bus.

In the system of the present invention, the clock rate of most of the circuitry is 20MHZ and the individual board pairs are numerous. Thus, for reliability the maximum acceptable synchronous domain is preferably four board pairs. Thus, many ASIUs are used to cross the asynchronous boundaries between the domains. Since there are physical limits on the length of a bus, and the number of ports connected to it, and such limits are particularly inconvenient for controller to controller transfers, the data network is configured for constructing a large logical bus from several smaller physical buses that are interconnected by active couplers. Thus, different subsets of physical buses can also be

Subbus data network 32 uses several logical building blocks implemented in two forms of well known configurable gate arrays (CGA). One CGA is a three bit slice of an 18 bit Subbus Interface WEB (SIWEB) hereinbefore mentioned; and the other CGA is the previously mentioned Asynchronous Subbus Interface Unit (ASIU) which has several different modes for serving as an asynchronous interface between two subbuses, a coupler between two subbuses, an interface between the internal circuitry of a CPU and a subbus, or a transmogrifier that translates a fully fledged subbus to any of several simpler subsets of the subbus interface that slaves can talk to.

The subbus is a bidirectional sixteen bit data bus that can connect multiple ports. Each physical subbus can support a maximum of about eight ports before clock waveform degradation sets in, but in the data network of the system of the present invention the physical subbuses may be connected together using either SIWEB's or ASIU couplers to make a logical bus of arbitrary length with an arbitrary number of ports up to the logical limit of 16,383 ports.

The SIWEB is the primary means of interconnecting subbuses. In the present embodiment of the invention, it has up to sixteen subbus ports, and can interconnect the ports, such as the inputs and outputs of SIWEB 230 of FIG. 3, for example. It can connect a subbus on any one port to a subbus on any other port, or can connect several subbus ports together to form a single logical subbus. The SIWEB can simultaneously and independently support several such connection groups provided each group uses a different set of subbus ports. An ASIU may also be referred to herein as a CASIU when it has a control function. One of the operating modes of the ASIU is the coupler mode where it functions in a manner similar to a two port SIWEB, with the exception that the two ports can be running at different clock rates, whereas in the SIWEB all ports must run synchronously. The ASIU also operates in several converter modes that converts the full fledged subbus interface to a simpler form to facilitate interfacing with other circuitry. The ASIU can permit the controller CPU to talk to many different parts of the array of SPE's (see FIG. 3). Another subbus converter mode of the ASIU includes a memory that can store set up sequences for up to eight slaves, and pass the sequences along in an independent interleaved fashion.

Referring to FIG. 10, there is illustrated the interconnection of a PBM and SPM through the data network similar to FIG. 3. SPM array 108 is connected to PBM array 110 through four 20MHz buses with four 20MHz buses 91 available for connection to other modules of the system, such as AP group 40 or DP group 114, for example. C to C bus 144 allows the control CPU's of each pair to talk to each other and to other devices in the system.

PI-bus 34 is a well known military standard linear multi-drop, synchronous bus which supports digital communications between up to 32 distributed operating system elements residing on a single backplane. The PI-bus system of the system of the present invention uses the sixteen bit error detection option and relies on a redundant bus for fault tolerance in the corresponding portion of the system. The PI-bus uses a master-slave communication protocol which allows the bus master to read data from one slave or write data to any number of slaves in a single message sequence. Messages may be routed to particular modules using either physical or logical addressing.

Reference is made to Appendix C pages C1 through C44 herein for a more detailed understanding of PI bus interface.

Subbus data network 32 supports transfers between array processing groups containing one, two, four, eight, or sixteen elements through pipelines of one, two, or four subbuses; for data types having from one to sixteen words per datum. A real single precision datum (SP) has one sixteen bit word; a complex double precision word (DP) has four sixteen bit words, floating point (FP) has four words per datum, etc. While subbus network 32 supports any combination of the above possibilities, the elemental arrays, such as SPE and BME may not. The SPE array, for example, cannot talk through a four bus pipe when the number of SPE's in the array is less than four, nor through a two bus pipe when the number of SPE's is less than two. For applications where the ASIU's support synchronized input/output transfers to local WEBs to keep the gate count down, there are restrictions as to what groups of ports in two or four bus pipes to form a pipe. This implies that the ASIU,s must coordinate their input/output to the local WEB,s through the SIWEBs which means that the ASIU,s must know what other ASIU,s are in the pipeline. In a one bus pipe, there are no restrictions. For a two bus pipe, one of the buses must be physical port N, where N is even, and the other must be N+1. For a four bus pipe, which is illustrated herein, one of the buses must be physical port N where N is a multiple of four, and the others must be N+1, N+2, and N+3. For a more detailed understanding of the data format for the subbus data network in the system of the present invention, reference is made to Appendix B herein, which consists of pages (1) through (5) inclusive. For a more detailed understanding of the operating codes for subbus data network 32, reference is made to Appendix D herein, which consists of pages D1 through D45 inclusive.

The DOS, in the system of the present invention, provides four functions; namely, process scheduling, communications, fault tolerance, and input handling. DOS resides in each of of the 1750A CPU modules, such as 42 and 44 of FIGS. 1 and 2, and 131 and 132 of FIG. 3, for example. Although DOS does not reside in modules other than the 1750A, it controls the operation of and interfaces with other modules across PI bus 34. In the present embodiment DOS uses the well known MIL-STD-1815A ADA Programming Language and MIL-STD 1750A Instruction Set Architecture.

Each of the above four functions plays an important role in the control of the system and the application processes. An application process is an ADA main procedure designed by the application programmer and scheduled by DOS on the above mentioned processor modules. A process is limited to one address state. Processes that are grouped together to be executed on the same processor are known as a family. A process may be mapped to a particular process family at the time of the processes definition.

Process scheduling function is a term embracing the scheduling and synchroniztion of application processes, sometimes referred to as tasks, which perform the actual functions of the embedded application. The process scheduling function permits process definition, process allocation, process scheduling, process execution, and process synchronization using semaphores and events. Process definition provides the applications programmer with the ability to define processes within a processor module based on a set of attributes. Process allocation designates on which processor module each process is to be executed. Process scheduling determines which process is currently active on each local processor module. This scheduling performs the operation necessary for causing a process to change state from one of five process states to another. The five process states are as follows: undefined, dormant, waiting, ready, and active. Process execution performs the operations necessary to set up a process for execution, execute the process, and clean up the process after execution. There is a set of semaphores and events that are available to each processor module. These are accessible by all processor modulus within a group, and global to the system. Semaphores, which have a one to one relationship are implemented using a counter which is incremented by a call to Signal and decremented by each call to Wait/Waits. A process may signal a semaphore many times before any process waits on it, so that when a processor later waits on it, the wait is immediately satisfied and the semaphore decremented. Local semaphores may only be signalled and waited on within a CPU, while global semaphores may be signalled from any CPU but only may be waited on by processes within the family associated with the semaphore where it was defined. The maximum value a semaphore may be incremented is a value determined during definition. Events, which have a one to many relationship, when signalled can cause more than one process to have its Wait(s) satisfied. Additionally there must be a process currently waiting on an event in order for the signalling of that event to produce any effect. If an event is signalled and there is no process currently waiting on the event, nothing will happen. Unlike semaphores, events have no memory, and are included in DOS for accomodating the scheduling of processes, which must occur at the moment of some external or data driven event. If an event occurs and a process is ready to handle processing of the event; that is, it is waiting on the event, it becomes unblocked for that invoking condition, otherwise the event will pass and no processing will occur. The existence of two CPU's 142 and 143 within controller 106 has caused specific differences in the function of DOS and the scheduling of processes. Controller 106 does not use the same dispatcher that general processor 42,44 employs. The DOS functions run on CPU 142 while application software runs on CPU 143. The controlling portion of the general processor 42,43 dispatcher is located on CPU 143 since the dispatcher implementation of controlling a process on the same CPU does not work when the dispatcher is on CPU 142 and it wants to give control of CPU 143 to an application process. The dispatcher in CPU 142 places information concerning the process to control to a shared area of memory, and then interrupts CPU 143 through XIO. CPU 143 has an interrupt handler which takes this information and performs dispatch to the appropriate application process. Both 142 and 143 execute concurrently. By utilizing the shared memory of both CPU's for passing parameters. CPU 143 can continue executing code immediately following the CPU output call while CPU 142 is performing the CPu output. This is not possible in a single CPU configuration.

The communications function allows for the reading and writing of data between two modules in system 30 and between a module in the system 30 and an outside entity, such as a receiver, transmitter, etc. via the PI bus. The application process that requires communications service shall be called the requesting process, and the process at the other end is called the remote process. All PI bus communications are carried out between two PI bus labels, the requesting PI bus label and the remote PI bus label. The logical addressing, which is enforced by this use of PI bus labels, enhances flexibility in application software location. A data transfer can be performed between label A and label B whether or not the data source are on the same or different CPU's. This flexibility of the location of the application software is enhanced through usage of process families, which are associated with PI bus logical module identifiers. PI bus 34 logical module identifiers allow one transfer to go to one or more physical modules. Logical module identifiers forty-four to two hundred fifty-four are available when assigning logical module ids to families, or any other purpose. For the sake of efficiency, DOS's sysgen package requests a number in the aforementioned range to be chosen as the Max.sub.-- Single.sub.-- Slave.sub.-- Logical.sub.-- Id. Any logical id below this value is interpreted as having one destination only. Any other ids are interpreted as potentially existing on multiple processors. A transfer which is made to a logical identifiers is interpreted as a single slave logical identifiers, and resides on the same processor as the requesting process. DOS performs the intra-CPU copy and does not have to go out on the PI bus. DOS communications also provides for determining with the use of a semaphore when a transfer completes. When the transfer completes DOS signals an optional transfer parameter. The requestor can wait on the semaphore until the transfer finishes, at which point the requestor is again ready to run. If it is required that the requestor be informed of the results of the transfer, an address is passed to the DOS for storing the result of the completed transfer. The potential results of a transfer are Success, Failure, and Busy. The user determines that the address passed to DOS is a valid address when transfer is completed. At the time of the transfer request, due to PI bus loading, the address for storing the transfer results are unknown. Since both status and semaphore parameters are optional, specifying one does not require specifying the other. For transfers that do not complete successfully, DOS may be told to Retry through an optional parameter. In the event of a busy or error response, the transfer is requeued at its priority and retried if the Retry parameter is set to True, which it is by default. The number of times a transfer may be retried is specified in the DOS sysgen package. Any time a label is accessed (written to or read from) after association with a semaphore, the label is made Busy to the PI bus. This Busy state persists until the request is made that the Busy bit be cleared via a call to the DOS procedure Modify.sub.-- Label.sub.-- Table. Through this semaphore association, it is assured that the data being processed is not overwritten from the PI bus until the proper time for updating. By not associating a semaphore with a label, the data buffer can be updated at any time without the users or DOS's knowledge. The user can request DOS to make the label Busy during the critical access time, which prevents the PI bus from destroying the user while in the middle of accessing data buffer. The user may clear the Busy bit when finished accessing the data buffer. Another option is to make the label on the PI bus inactive during the critical time and then activating the label when finished.

The Fault Tolerance function responds to fault indications and status requests. It also monitors the health of the PI bus, interconnecting buses, and the loss of a processor module. Upon notification of a failure this function determines the most suitable reconfiguration of the system to compensate for the failed resources. If sufficient spare resources are available to support the current processing requirements, Fault Tolerance function performs the reconfiguration and informs the System Executive Software (SES) of the systems new status. If sufficient resources are not available to support the current processing requirements, Fault Tolerance informs the SES of the degraded nature of the system. The application programs provide a Self-Test program that is scheduled by DOS to continuously monitor the integrity of the processor module on which it is executing at a rate chosen by the applications program. Only confirmed faults are reported to the Fault Tolerance function for logging and potential reconfiguration. For situations where a processor module fails completely or becomes disconnected from the PI bus, the SELF Test function, of course, is unable to notify the CME of its failure; thus, Fault Tolerance function provides for periodically broadcasting a heartbeat report from each processor module to reassure the other modules of the continued existence of the rest of the processors. Several processor modules keep timers on these heartbeat reports; and when a timer expires with no report from a processor module, the delinquent processor module is presumed completely failed or disconnected and the fault logged, and reconfiguration initiated. Upon declaration of a faulty module, a suitable spare module is sought. If one is found, the processes executing on the faulty spare are defined and started on the spare processor module by the previously mentioned Processor Scheduling function and restarted. Process scheduling is also directed to execute Built-In-Test on the faulty processor module to further isolate the fault, and determine if it was due to a transient condition or a true fault. If BIT passes, the fault is assumed to be transient and the faulty module is returned to the system as a spare. If the BIT fails, of course, the faulty module is taken off line. If the number of transient faults exceed a predetermined threshold, the processor module is taken off line permanently; and the condition logged.

If a spare processor module is unavailable in the system, it is determined if the processes required in the current application software load can be redistributed over the remaining healthy processor modules. If not, the SES is notified of the current status; and the SES may request degraded processing modes to be executed. Since the DOS does not determine how much bad data has propogated through the system as a result of a module failure, the applications programs decide how to respond after a reconfiguration. For example, the present mode may be terminated, or the system may back up to some predetermined point when critical data was stored, or the system may continue execution with bad data. Input/output timeout conditions may also indicate that a processor is faulty. If a process waits longer than an amount of time referred to as the Deadline Time, specified for triggering data or an event, Process scheduling alerts Fault Tolerance of the problem. Fault Tolerance attempts to determine if the timeout was caused by a hardware failure, in which case it shall respond to the failure.

The processing required for the Input Handler function includes Interrupt Handling, Interrupt Assignments, and Hardware status forwarding. When an interrupt occurs, the Input Handler function determines the meaning of the interrupt. If appropriate for the interrupt, the Input Handler function signals the appropriate event or semaphore (if assigned) by calling a procedure of the Process Scheduling function. If appropriate for the interrupt, the Input Handler function forwards the message associated with the interrupt to either the Process Scheduling function, the Fault Tolerance function or the Communications function. Process Scheduling function allows for the assignments of semaphores/events to the spare interrupts. When the interrrupt occurs, the Input Handler function signals the semaphore/event to the Process Scheduling function. The status of system 30's hardware, such as processor modules, I/O devices, and buses, is forwarded by the Input Handler function to the Fault Tolerant function.

An application process is an entity scheduled by DOS on a processor module and implemented as a main Ada procedure. Each process is compiled and linked separately using a Ada 1750A compiler and linker. The maximum number of processes in a system is a DOS sysgen parameter. One application process exists per address state, limiting the size of the processor in the following manner. An address state contains 64K of code address space and 64K of data address space. To minimize PI bus traffic from process communication, processes that interact frequently should be placed on the same processor. This is accomplished by putting the processes in the same family. A process must be in a family even if it is the only process in the family; and a process may belong to more than one family. When a processor failure occurs requiring process relocation, all processes in a family must be located on a common processor. For each family there is a family initialization executive and a family shutdown executive for starting up and deleting a family, respectively. The family initialization executive defines local environment for the family, such as processes in the family, PI bus labels for data buffers in family processes, and semaphores local to the family processes

System Executive Software (SES), a user written Ada procedure, is the highest level of control in the system. The SES tells DOS which application processes to execute at any point in time, and tailors control of the system to the particular application at hand. Additionally, SES is the final authority in deciding how to reconfigure the system if the DOS is unable to handle a failure that has occurred. In this instance, the DOS would tell the SES that it cannot handle the currently requested set of processes and ask for further instrucions. First, the SES defines the family initialization executive processes and the global semaphores. The family initialization processes then execute because they are a higher priority than the SES. A variable is set when the processs stops, causing the SES to define the family shutdown executives, delete the global semaphores after the family shutdown executives on other processors have completed executing, and finally delete itself.

Reference is made to Appendix E, pages E1 through E27 attached herein for a more detailed description of DOS including the various calls that are available to the programmer through the user interface. The following are listed for each call: Inputs, Outputs, Exceptions, Parameter Descriptions, and Examples. Some of the inputs of the system calls are Ada records. In these instances, the components of the records are listed.

As previously mentioned all of the applications code is written in Ada and resides and executes on the 1750A CPU modules 140 and 142, and 42, 44 of the system. The applications software consists of a number of processes which interact with each other and are distributed between the two modules. The DOS functionalities demonstrated by the applications processes are: (a) code executing on a 1750A CPU, (b) multiple processes on separate CPU's operating asynchronously using DOS process scheduling facilities, heretofore mentioned, for process synchronization, (c) processes communicating on one processor, such as 38 for example, (d) processes communicating across processors via PI bus 34, such as 38 and 40 for example, (e) preemption of processes, and (f) atomic process capabilities. Reference is made to the flow diagram of FIG. 20, wherein the individual circles referenced as 38 and 42 for example represent different modules in the system such as array processor group 38 and GP processor 42. The numerals 1 through 9 inclusive each represent a different application process residing in a respective one of the modules. For example processes 1, 2, 3, 8 and 9 may represent a family of processes and reside in a single CPU of a module; while processes 4, 5, 6 and 7 represent another family of processes residing in a different module. The dashed lines labeled S2, S4 through S13 and S21 represent semaphores or events; while the solid lines represent the flow of data referenced D1 through D4, and D4 through D9, D11, D12, D19 and D20. In operation, process 4 awaits semaphore S5 for transferring data D19 internally in the same processor. Process 5, for example, residing in module 42 awaits the arrival of semaphore S11 for transferring data D7 to another processor 38. From the preceding exemplary explanation, it is considered that the transfer of the remaining data in response to the semaphores is evident. For a more detailed understanding of the capabilities of the DOS system of the present invention, reference is made to Appendix H, pages H1 to H62 herein, which includes a series of tables that summarize application process definition information, semaphore and event information, and data buffer information.

Reference is also made to Appendix F, pages F1 through F20 attached herein for a more detailed description of the User Interface (UIF) package specification of DOS.

It will be apparent to those skilled in the art that various modifications and variations can be made in the system of the present invention without departing from the spirit or scope of the invention. Thus, it is intended that the present invention cover the modifications and variations provided they come within the scope of the appended claims and their equivalents. ##SPC1##