Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
7, COMPUTERS, STEERING, AND BEAM POINTING Preceding sections discuss the radiation intensity at nearby points on the ground that can result from normal operation of the PAVE PAWS radar and the effects on that intensity that might result from possible degra- dations in.antenna performance. Key to the discussion was the assump- tion that at ground level only sidelobe energy is received. This section evaluates those features of the antenna's control system that assure that the main beam is never directed below 3° elevation and therefore that points of public access are not exposed to energy other than that from sidelobes. Primary control of the pulse-by-pulse operation of the PAVE PAWS radar resides in a CYBER-l74 computer^ The basic functions performed are to schedule radar pulses, to process data returned from the re- ceived echoes, to detect, track, and classify targets, to determine launch and impact points, to operate displays and alarms and to main- tain checks on status and operability of the radar and computer. There are two CYBER-l74 computers on site. One operates on-line, the other is available as a spare should the on-line computer require maintenance. The radar is under detailed control of its own radar controller, a MODCOMP IV general-purpose computer. The basic functions performed are: to receive beam-steering and pulse schedules from the CYBER-l74, to convert these into steering commands and commands to the receiver- exciter, to do or to control signal processing on radar returns, to re- port processed returns to the CYBER-l74, and to conduct and report on performance monitoring tests. A spare MODCOMP IV will take over auto- matically if the on-line unit goes out of service. Steering directions for each pulse to be transmitted are generated in the CYBER-l74. Directions for a search pulse along the 3° elevation line are simply read from a table that describes all l20 possible search positions.. Other pulses--those scheduled for tracking targets, for example--are steered to directions that may be computed from current track files or satellite catalogs, etc. Steering directions are computed as sin a, sin B, each expressed to 60 binary places, where a is the angle of rotation about the column direction, and g the angle of ro- tation about the row direction, that would be required to bring the beam from its desired position into coincidence with the vector normal to the array face (boresight). By a direct geometrical calculation, the 33
34 pair sin a, sin B is tested in the CYBER-l74 to verify (a) that the beam elevation lies at least 3° above horizontal, (b) that the beam azimuth is within 6l° of the azimuth of boresight, and (c) that the beam is within 65° of the array normal. If a steering direction fails any one of these tests, the pulse for which it was generated is not sche- duled, and no instruction goes out to the radar controller. This same geometrical test indicates when a target in track will have to be trans- ferred from the coverage of one face to that of the other. A steering order that passes the coverage test in the CYBER-l74 is rounded to l6 binary places and issued to the radar controller. The radar controller computes the amounts by which, from row to row, and from column to column, the. phase is to be incremented to create the desired beam direction. The row increment (RWI) and column incre- ment (CL1), each to l6 binary places, are then transferred to a separate beam steering unit--a special purpose digital computer. This computer verifies that the increments RWI and GLI describe a permissible beam position. This is done by consulting a table stored in a permanently wired ("burned in") read-only memory. .The beam steering unit rejects an illegal command and reports a fault. If the command is legal, the beam steering unit computes, for each row or column, a desired phase shift. For the ntn row (or column) the desired shift is n x (RWI) (or n x (CLI)), plus a correction to improve the randomization of phase errors after rounding. Row and column commands to six binary places are summed in each transmitting module, the sum is rounded to four places to command the four quantized increments of phase shift in that module. A spare beam steering unit takes over automatically if the on-line unit becomes inoperative. In the programs of the CYBER-l74 and the radar controller and in the hardware of both of these computers, as well as in the beam steering unit, there are self-testing and error-sensing features of many kinds. In particular, programs in the radar controller subject the beam steering unit to tests during each resource interval that is reserved for tests (one in eighteen)- Among the functions tested is the response to steering commands, both those that are out of coverage limits, as well as those that are legal. Failure to recognize an illegal command as being il- legal is reported as a radar fault, and the faulty beam steering unit is taken out of service. Other incorrect responses are treated similarly. During the course of a few minutes, both legal and illegal commands lying near.the boundary of coverage and exploring that boundary, are tested. .These tests of the beam steering unit also detect malfunctions that could distort the beam severely, therefore protecting the integrity of the beam quite independently of the periodic subarray tests described in Section 4. In this section the panel has so far discussed features of the pointing and control of the transmitting beam that en,sure that areas outside of the desired zone of coverage are not illuminated. There are also protections against letting the beam dwell too long in one position ("spotlighting") even when that position lies within the zone of coverage. The operation of these protective features has the effect of warning against, or of preventing, a condition in which some
35 nearby point on the ground is exposed on every pulse to a worst-case sidelobe. Even such a condition would, in general, create exposures no greater than those shown in the last line of Table III. When under control of the CYBER-l74,. the radar controller will not permit seventeen consecutive pulses to go out in the same direc- tion. If sixteen have already been transmitted in a given direction, the seventeenth is inhibited. The event is reported as a minor radar fault and is entered in the running status report. Instructions can be entered manually into the radar controller, directing the beam to "spotlight" in a chosen direction. Such, manual steering is used for test purposes and for special search operations- Beam steering orders from this manual source are tested in the radar controller for compliance with scan limits. The scan limits used for a manually ordered spotlighted beam reject any beam directed below 6° elevation. These steering commands are again tested (just as are all others) in the beam steering unit (i.e», against the 3° horizon limit). The CYBER-l74 and the radar controller are general purpose digi- tal computers totally slave to the programs written into them. The writing of these programs to achieve the designer's intent and the testing of them are critical steps in the process of creating a functioning radar system out of an assemblage of hardware. The beam steering unit is also a digital computer. Its program is in large measure embodied in its wiring diagram or hardware con- figuration. This fact does not diminish the criticality of careful design and test. The functions of the beam steering unit are, however, repetitive and comparatively simple. In particular, proper design and operation can be verified by a small battery of simple tests. Those performed automatically during every eighteenth resource interval suffice to verify operability. Tactical software residing in the CYBER-l74 and the radar control software in the radar controller are independent of each other and are written by different organizations. The processes of writing and testing are governed by military specifications. Both suites of software are built using methods and controls designed to assure that only software of a known, tested, and approved configuration is used at site. These development methods are as good as any available at the present time. They do not, of course, totally preclude the possibility of erroneous operation at the site. As indicated by the discussion above, the software and hardware are so configured that the possibility of an event such as the pointing of a beam below 3° in elevation is virtually excluded. All beam steering orders emanating from the tac- tical software are subject to two separate checks against the scan limits in two distinct computers by distinct processes. One check resides in software, the other in a hard-wired table of numbers. Unless these checks are satisfied, transmission is prevented. Suitable alarms and displays are provided to indicate out-of-limits commands, and the hard- ware verification circuits in the beam-steering unit are tested every few seconds to verify correct functioning of these interlock circuits themsel\3s. Thus, when the radar is operational, at least two nearly
36 simultaneous failures would have to occur before the beam elevation could go below 3°. Also, in maintenance testing, two nearly simul- taneous failures, accompanied by an incorrect manual action, would have to occur. In either case, one of the failures would have to be a hardware failure, and the other would have to be a software error in a different part of the system. With this arrangement, there is essentially no likelihood of such an event happening by chance or inadvertence, and it is difficult to see how it could be caused intentionally by any one individual, no matter how highly skilled. It appears that the radar beam could be pointed below 3° only by concerted specific, carefully planned software and hardware modifications made by at least two people working in concert,. Such an action would consti- tute a partial redesign of PAVE PAWS. Testing of the software for PAVE PAWS during the process of devel- opment includes testing of the computer systems against a radar simu- lator that can simulate, from the point of view of the computer, an actual tactical environment. The tests used include traffic loads (number of targets) up to l50 percent of the design load. Simulation programs are also provided in the software used on site, to be used for training, and for systems test. Experience in other systems has shown that such simulations are highly effective, not only in ferreting out possible errors in software (i.e., departures from design intent) but also in verifying that the design responds properly to those pro- blems and off-design conditions that a real environment can give rise to.
