Perfect is the Enemy of Good Enough

This html article is produced from an uncorrected text file through optical character recognition. Prior to 1940 articles all text has been corrected, but from 1940 to the present most still remain uncorrected.  Artifacts of the scans are misspellings, out-of-context footnotes and sidebars, and other inconsistencies.  Adjacent to each text file is a PDF of the article, which accurately and fully conveys the content as it appeared in the issue.  The uncorrected text files have been included to enhance the searchability of our content, on our site and in search engines, for our membership, the research community and media organizations. We are working now to provide clean text files for the entire collection.

Th

^ne Mk-l Human is the key element in any _c°^mbat system. Tacticians, not theoreti- ^a»s, need to express their requirements ** stay intimately involved in the develop- ^ent of the systems they will be operating.

A scientist and an engineer were put in a room across from a bag of gold. They were told they could have _v the bag when they moved across the room. They ^a 8° as fast as they wanted provided they went no ^^re than half the remaining distance with each move, tj ^{6 Sc}icntist, recognizing the impossibility of the situa- ⁿ’ left the room. The engineer, on the other hand, tlj across the room until he was within arm’s reach of _en °^ag- At this point, he declared that he had gone far b °^u§h for an engineering approximation, grabbed the §> and left.

is f¹¹ ^^evel°piⁿg its weapons, the Navy’s goal frequently tech ^{a s}tate-of-the-art system on the cutting edge of ^noi°gy, rather than a simpler system that is good tai ^to 8^et the job done. The result is that developmen­ts. j_{s a}lw_ay_S halfway finished, and its goals are

^er reached.

and °^W ^ this happen? The advent of high-speed aircraft f_0r ®^uided weapons drastically reduced reaction times and fire ^WeaP^ons to be programmed and controlled. Thus, dj_g ^Cont^r°l systems became weapon control systems, and pro*¹^ ^ComP^uters replaced analog devices and people. The to ^{C£Ss w}°rked well as long as it was confined primarily ^Umber-crunching. The computers were tools providing aid ^L'k^{ate num}f^)ers to support engineers and fast answers to ^aHal ^tact'^ca' decision makers. To achieve this, systems ^eno-^^{Sts ar)}d computer scientists took over the lead from thr ^{neers ar|}d operators. Tactical operators identified the v_I(J^{Cat an}d the desired capabilities while engineers pro­electromechanical equations for operating the weapon. The systems analysts determined what had to be done to complete an engagement. This information was then translated to functional flow diagrams, which in turn became computer algorithms and, finally, computer pro­grams.

Slowly, in response to requirements for even faster re­action times, longer range, and greater firepower, the computers were converted from stand-alone weapon con­trol and decision aids to integrated decision makers. For example, the Navy Tactical Data System (NTDS) became a Combat Direction System (CDS), and the Mk-l 16 Un­derwater Battery Fire Control System is becoming the Antisubmarine Warfare Control System.

Although the goals have changed, the process has not. Working from initial operator-defined requirements, the analysts still decide what has to be done, and the program­mers still write the programs. Modern technology makes it appear that it is simply a matter of providing enough mem­ory and processing capability to do the required task.

Unfortunately, this line of reasoning is flawed:

► The decision maker must account for all possible con­tingencies.

► The unique capabilities of the operators and real-world limitations are not incorporated into the design.

► No one person is in charge to settle arguments or coor­dinate requirements among the sectors.

Dealing With All Possible Contingencies: The ability to handle all possible contingencies has increased the com­plexity of the Navy’s weapon systems. Computer scien­tists have held up artificial intelligence (AI) as the solution to this dilemma. Their efforts in AI are producing “ex­pert” systems. All this means is that a human expert writes down all possible courses of action and the pro­grammers implement them.

An examination of the Tomahawk missile illustrates the problem. The land-attack version is simple. All it needs to- land is a flight path, after which it follows a predetermined

and

each planned to provide the operators, equipment,

complex computer programs while retaining the capal

biW

Checking all these features, both automatic and manual,^

quired product. Lengthy tests must be developed to c

₀vs^r

fld

limited availability of fleet assets, and the need to rep¹

ie^at

testing and simulation. This saves time and money, b^{ut |!}

taking possible actions at incorrect times. Freque

ntiy

ien^s

but'

features provided by the developer, pushes the wrong

ton at the wrong time. Laboratory testers often fail to

In one potential scenario, an already operational mi^s:

sd^e

system launched a missile and did not know it. The sy

•leaf

route to the target. The antishipping version, however, is more complex.

A simple scenario involves an isolated, known target located by external sensors. In this example, the uncer­tainty area is assigned a 7 nautical mile X 10 nautical mile ellipse and the target is moving at 20 knots. The contact report is received by the firing ship 15 minutes after the target is detected. It will take ten more minutes to prepare the attack, and time of flight is 20 minutes. These are not worst-case values, but they still cause the uncertainty area to grow to 37 nautical miles x 40 nautical miles. To cope with this, the analysts have developed several search pat­terns. The system, with operator input, proposes the search pattern that optimizes the chances of target acquisi­tion and kill. Given the high kill probability, the com­manding officer orders the launch. The Tomahawk flies out at a low level with a dogleg to avoid detection and disclosure of the attacker’s location. Upon reaching the attack area, it pops up and begins its search. Thirty sec­onds later, a Soviet surface-to-air missile destroys it.

The Tomahawk had popped up on a search path perpen­dicular to the target line and was cruising at altitude at subsonic speed looking for the enemy ship. This occurred without further restrictions imposed by multiple targets, friendly or neutral units in the area, or coordinating attacks with other firing units. The ability is there to compute all the possible variations of this attack. Also included are several tricks to avoid destruction during the fly-out and attack phases. Yet the search plan development logic did not account for survivability during the search phase of flight. In pursuit of perfect acquisition, a great deal of effort has been spent in developing a capability of ques­tionable value.

Operator Capabilities and Real-World Limitations: In dealing with all possible contingencies, the designer also failed to account for the operator’s capabilities and other equipment available to him that could have significantly reduced the area of uncertainty and provided a more accu­rate attack plan. The computer scientist knows algorithm optimization and the logic that follows, but rarely under­stands engineering, physics, or tactics.

While developing a surface antisubmarine warfare sys­tem, the designer proposed an algorithm that, after ap­proximately an hour of passive tracking and maneuvering, would permit a LAMPS helicopter to be launched, fly to a point, and drop a torpedo. He had all the equations for the fire control solution of an aircraft-carried torpedo. But he had no concept for using lower quality data and vectoring the LAMPS for a magnetic anomaly detection or sono- buoy-based attack that would probably have been over before his passive-only method was ready to recommend launch. His perfect stand-alone solution called for greater accuracy than the planned sensors currently provided, which he paid for in development time and costs. His solu­tion also took longer—which he paid for in casualties— than the results obtainable through the synergistic use of multiple assets.

One Person in Charge: Obtaining the synergistic bene­fits of multiple assets requires someone to be in charge.

He must ensure that duplication is avoided and no gaps ar^e left—problems that even perfect subsystems can cause. Iⁿ the late 1970s, the gunnery, ASW, and over-the-horizon- targeting (OTH-T) communities were designing the sys­tems they would provide for the first major Spruance (P®' 963)-class upgrade. Each quickly identified a need f°^{r a} surface or a surf ace/subsurf ace warfare coordinator, an computers to support this requirement. Luckily, someone identified early on that there was already an NTDS ope^ra tor doing this job and, almost as important, that there was no room in the combat information center for all the extr^a consoles.

This particular evolution provided gaps as well as ove^f' laps. The towed-array developers could see no utility >ⁿ passing hostile surface contacts to the fire control system From the ASW point of view, it tied up limited track fd^£S with useless data. On the other hand, the OTH-T cornrnn nity was faced with a long-range missile but medium range electronic warfare (EW) sensors looking for targ^ets under electronic emission control (EmCon) condition^ They had no idea that long-range acoustic data was aval able. By requiring the surface contact data to pass to t ¹ fire control system, and from there to the CDS, valuau data was made available to contribute to the solving of¹ OTH-T problem.

In the area of evaluation and exchange of data, the cap^a bilities of today’s systems still rely mostly on human juuf ment. This creates a need for tight interface protocols a for operator intervention at all points in the engagemeⁿ|;

extremely difficult. This search for the perfect blend man and machine is a major factor in the ever-increasi & time between recognizing the need and providing the m

all contingencies. The complexity of the tests, the cost a tests drives the developers to rely heavily on laborat⁰¹^ frequently has two drawbacks:

► The developers fail to test illogically.

► The exact shipboard configuration is not used.

Illogical Testing: This type of testing is conducted W called Murphy testing, the goal is to find out what happ¹ ^ when the young sailor, baffled by the wide assortment

test

results illogically during the development stage beca they work so closely with the designers. When proble crop up, they tend to note them, work around them, ^a ^ proceed with the test. This procedure becomes routine- the problem is finally fixed, it frequently turns out to masking another problem. Also, testing all the log^lC‘ paths leaves little time to test illogical ones.

ste¹¹¹ looked for the firing order signal and then the rail

iab^tory          .

_Co °^ratory system worked fine, the test ship, with two ti_Iai^s°*^es> failed repeatedly. The ship spent a great deal of ^trying to convince the developers at the laboratory ^lhe ^S°^mething was wrong with the system and not with termors. The laboratory finally reconfigured its sys- tim-*° ^ernpl°y two consoles and quickly discovered the Problem.

the ? ^^Urther reduce the possibility of problems caused by sit_e. ^oratory, the Navy has developed integration test ^s I°r the Oliver Hazard Perry (FFG-7), Ticonderoga

to indicate missile launch. Both signals were held ^.^a short period to allow other events to occur, after In h'^{1 l}*^{le s}y^stem evaluated the status of the missile firing. _a ^lllis particular instance, the test “rail-clear” button was ^c,dently pressed just prior to the time the firing key was ^Sed. As a result, the missile fired but the hold period Ptfed before the system was ready to process it. The _c ^Cttl evaluated the firing as incomplete and stopped pro- ^s,rig the engagement, which wasted the missile. The raj?^^ners h^acl not foreseen the illogical possibility that the ^cIear signal could be received before the missile was °^rdered launched.

Jtyboard Configurations: Illogical testing is possible u ^lfl the laboratory environment, but using the ship- _e ^ ^configuration frequently is not. The laboratory gen- y has functional equivalents because of the need for ^an₍f^ns*^Ve data extraction and reconfiguration capabilities ^ fact that the equipment used is the developmental Ian ^^{rom w}h*^ch production units are copied. To use a ₀ d'hased test site for proof-of-concept and initial devel- _l|_le^ment is valid. But a system cannot move directly from ^ab to operational use.

_ac(:^his concept fails because of the intricate timing inter- pro°^{n rea}* ^un*^{ts as} °PP^osed to the nominal responses W_e^Vlded by laboratory simulators. As an example, a t₀ ^aP°ⁿ control system under development was designed lat}^{USe tWo} consoles. Yet only one was available at the mw.. because of production limitations. While the (CG-47), and Arleigh Burke (DDG-51) classes. They built a physical mock-up of the major combat system spaces at these sites. Enlisted personnel man the mock-ups, which the developers can monitor while they operate the combat system. The benefit is that they can carry out many runs under controlled or semicontrolled conditions, and they can note problems in the developmental, not the opera­tional, cycle. At the FFG-7 site, a problem occurred that stopped one of the CDS computers. The weapons control officer (WCO) had to have three Harpoon missiles in flight. At the same time the air tactical control officer had to request that the LAMPS shipboard computer update the LAMPS-III position and repeat the request before the first update finished. The ASW officer had to examine his con­tacts simultaneously by computer sequencing. If the WCO now launched an off-axis, and not a direct Harpoon shot, the computer would stop. The problem, which was the result of the interaction of four independently developed computer programs, would have been untraceable at any other location.

To reduce the number of problems once the system reaches the fleet and to meet the desired goal of a perfect combat system, the Navy needs to get the people, the tac­tical end-users of the provided equipment, back into the process. Three steps would go a long way toward meeting this goal:

► Get more participation from users during the develop­ment process.

► Keep developers more aware of the tactical situation.

► Strengthen the combat system (as opposed to weapon system) engineering concept.

Participation from the Users: This is vital. Since devel­opers are pursuing such a high level of automation, they are fixing tactical options in the computer programs. This limits what the end user can do, and these decisions are frequently made without the user’s input. Several proce­dures could ease this situation. One would be to nominate several fleet units that will ultimately use the systems as participating members of the development team. They would participate from the beginning of the project through selection of the test unit. They would review the function design documents (Program Performance Speci­fications, Interface Design Specifications, etc.) and attend appropriate design review meetings.

Since this participation may be difficult to achieve with the operational requirements these units face, the various tactical training commands (Fleet ASW Schools, Fleet Training Group, Surface Warfare Officers School, Subma­rine School, Navy Fighter Weapons School, etc.) could fulfill this role. The initiative by the Surface Warfare De­velopment Group in the area is promising, but its assets are limited and its current focus is principally on single

surface ship tactics with some battle group considerations. The tactical community must be brought in at the outset and kept actively involved in the preliminary design as well as the final testing. Given the long lead time of to­day’s systems, it is no longer acceptable to receive user requirements, then five to ten years later, hand a system over to the fleet operators and tell them to figure out how it works.

Keeping Developers Current: Keeping the developers current with the tactical situation goes hand in hand with active fleet participation. This means getting them to sea. With today’s career path, a weapon/combat system engi­neering duty officer (EDO) conceivably will not see a ship tour after his lieutenant/division officer tour. This hardly provides the broad scope needed to understand fleet opera­tions ten years later as a junior program manager or when leading the system design area of a major program. Unre­stricted line material professionals (MPs) are better off but still are not current when they are selected several years later to manage major programs. The Navy needs middle- grade billets in which fleet experience can be obtained while using the EDO/MP expertise. There currently are no middle-grade at-sea billets for combat systems EDOs. The last was combat system officer in the recently decommis­sioned USS Norton Sound (AVM-1). Filling a billet such as a combat system maintenance officer on a Ticonderoga- class cruiser would make use of the EDO’s expertise and provide him with valuable insight into the difficulties and realities of managing the tactical situation. Similarly, bil­lets such as surface operations or combat systems officer on cruiser and carrier group staffs would benefit both the staff and the MP assigned to fill it.

Even if long-term billets cannot be assigned to combat system EDOs and MPs, ample opportunities exist to return them to sea for short, useful periods. Two- to four-month assignments to deployed units would provide extra man­power and focus experience on the critical time frame. In the short term, EDOs and MPs could act as umpires for fleet exercises and similar events.

Strengthen Combat Systems: Finally, alert program managers must guide combat systems design from the top down. The development of the Space and Warfare Com­mand is a big step in this direction. A major initiative of this command is battle group engineering. For the first time, this will attempt to identify how the battle group operates so that needs and limitations can be translated across warfare communities to develop the systems coop­eratively that will support the battle group operators.

In conjunction with the development of the battle group combat system, the Navy needs to move to a generic ship combat system and away from the “class” concept. For instance, the Ticonderoga, Spruance, Kidd (DDG-993),

Integration test sites, such as this one for the Oliver Hazard Perry (FFG-7) class, are one way to reduce labora­tory-induced difficulties. They allow designers to isolate problems during the developmental cycle, precluding costly failures during the operational cycle.

snd'r¹ '' ^^xceP* *^^e Spruance (DD-963) class 2. Except Virginia (CGN-38) class 3. Except Mk-41 vertical launch system (VLSI-equipped ships of the Spruance ^lc°nderoga classes 4. Except the Spruance class and CGs 47-51 5. Except the Ticonderoga class

Tabl_e 2

Combat System Differences

4 I ■ Except for CGs 47—51 (Mk-26 Launcher) 2. For ships not equipped with Mk-41 3. For ships with the Mk-41 vertical launch system ^r®^,n,a class only

'^Qlifornia

(CGN-36), and Virginia (CGN-38) classes are

minor variations of one combat system (see Tables

Va_r^a^°^{n or} ^^{re contr}°l system has an expert for each class Hot'³”¹- This is preferable to no one doing the job, but it is

u!i,? ^{best s}y^stem-

d_e; m top-down battle group design, weapon system

^^erely _____ __________  _ ____________ ^........ ^_________

i„^a^ 2). Despite this commonality, almost every element ■H- ^e system is in some way unique to its particular class. _sjjj^,s 'ⁿ turn is paralleled by the design organization. Each 4 class has its own combat system engineer, concerned *J>°w the elements on his ship work together, and each

r_e| 'l?^ners will know what is expected of their systems in k_no ^l0n other systems. Equally important, they will •he fi ^{Wbat not 10} build. With better defined bounds and d_ev ^exibility allowed by computer programs, they can h_0vv^e °P generic interfaces. They would need to determine many basic weapons a new ship needs, account for ^sP^ecial weapons, and build a hull to carry them. Al- V/j j 't sounds simplistic, it is achievable. During World bjjtti ’ destroyers, destroyer escorts, aircraft carriers, and ^eships were built this way. They all used five-inch, ted¹¹¹¹¹¹' ’ ^anc* 20-mm. guns. The destroyers were also fit- g_0{ ^.'tlt torpedoes and ASW weapons, and the battleships d_ec-j!§8er main batteries. But the ship was designed by ^lng how many weapons it would get, not by what

weapons might work with other weapons.

An additional benefit of this approach is that the ship would regain the ability to locally load, aim, and fire weapons. In their search for the perfect solution, the de­signers are building weapons that cannot work without their complex, integrated, centrally located computers. World War II is filled with stories of ships heavily dam­aged but still firing their weapons effectively. Today’s ships, as so clearly evidenced by the USS Stark (FFG-31), can be put out of action by a single hit in the computer room. The designers have produced a reliable, maintain­able system with redundancy and graceful degradation in the event of casualties. But their concept of a casualty is the loss of a piece of equipment because of inherent, pre­dictable, periodic failure through use. The operators know that equipment casualties are measured in terms of com­partments destroyed by battle damage. The developers need to accept this fact and provide weapon systems that continue to function when cut off from central control sys­tems of the sensor. They need to provide a modular system that works better as part of the larger system but that con­tinues to function at reduced capacity, using the operator for control.

The drive for weapon systems perfection has driven the Navy away from this flexible approach. The result is ex-

The Stark's burned-out CIC consoles offer mute testimony that today’s combatant can suffer a “mission kill” from a single hit in her computer complex. Searching for the perfect solution, designers too often come up with weap­ons that cannot function without complex, integrated, centrally located computers.

tremely complex, costly, multiversion systems that take forever to develop and baffle the fleet when they are intro­duced. What is needed is firm application of the KISS

Arming the Software Warrior

^ hether they are called §^ls, CDC (combat direction nter), TWCS (Tomahawk _(T^eaPon Control System), TFCC ^^achcal Flag Control Center), batti^{0rne ot}her acronym, Navy

Management systems are

Port ^ ^a'^{one or} quietly in sup ^a battle group, cannot

°attl_e

for^ ^{111081 heavi|}y by surface „ .^es- The systems fight many ^ against many other units ^sen$ ^{VC extens}'^ve manning,

„ . °r, and communications re- ^erm'^CrnentS' ^he submarine, op-

_Sq the communications expo- g_et) ^,0 Participate fully and is _are^eral*y focusing on a limited _aj_r^{a ar,}d number of targets. The itiili • ^are i^ntensely involved in f_a ^v,hual combat and are, in l_au ’ ^s°nie of the projectiles q^^nched by the battle manage- _Craj. ^system. Even on board air- •he ^Carri^ers, the operators in ^rect'^COnibat information (or di- s_Urf'^0tl) center come from the th_e ^{aCe C0|}ntnunity rather than e_S( ^av'^ation one. With the wid- fq_Ce^Variety to choose from, and it, tyith budget cuts and an \y_arj?^as'ⁿg threat, the surface itiin ^{316 comm}unity must deter- atatv ^{t0 c}i° ^w'th battle C(j_s. §^ernent systems, how to ^train°^rT'i^{Ze t}b^em’ ^anci how to ej_e effectively to become profi- I 'n their use.

Che days of knighthood, the ci_en ^l0r developed his profi- ^and ^l'^y ‘hrough service as a page ^|e_arn^Sq_f,^Ulre- ^{As a} P^a8^e’ he be_c, ^ed the rules of behavior and ^dlTle acquainted with his leader’s weapons. As a squire, he improved his weapon skills and accompanied his leader to battle. Finally, having proved himself, he was knighted. The submarine and air communities have held true to the warrior cycle. The division officer fa­miliarizes himself with his air­craft or submarine. As a depart­ment head, he will use the same or nearly the same equipment but will be called on as an expe­rienced warrior to lead and train others in battle. As executive officer, the warrior is groomed for command, again in virtually the same suit of armor he put on as a division officer. Finally, fully qualified, he is given his own command of a system he has grown up with for 15 years.

The surface warrior is not given this opportunity to train and grow. Frequently, he is not even assigned to a battle man­agement-equipped ship until he is in his second department head tour on board a major combat­ant. Fie does not have time to become proficient. He must struggle to survive by relying on the system’s basic capabilities.

To overcome this lack of skill, the surface community must take three steps:

► Provide consistency in the career path.

► Control the variety of weapons.

► Improve the developer’s ex­planation of battle management system capabilities to the user.

The surface community has taken the first step in providing a more consistent career path by designating engineering and combat systems/operations paths at the department head level.

But it needs to start earlier and follow through to the command level. It is well and good to de­tail an officer on the combat systems/operations path, but what does it really mean? As a department head, he serves as combat systems officer on a frigate and then as an operations officer on a large amphibious ship. His executive officer tour is in a cruiser and then he com­mands a destroyer. He has gone from antisubmarine warfare to amphibious operations to antiair warfare (AAW) and back to ASW and has not mastered any of these warfare areas. To achieve proficiency, he must maintain consistency. It is possi­ble to do so. Table 1 shows ca­reer progressions for an engi- neering/amphibious ship, an ASW/escort, and an AAW/strike warfare/battle group specialist. These paths would provide a consistent progression in a prin­cipal warfare area while allow­ing the opportunity to gain expe­rience in the others. This would be particularly true for billets on the destroyers and guided-missile destroyers that can be assigned to either combatant group.

Initiating this career path has its drawbacks as well as its ben­efits. In particular, the officer must select his career path much earlier, during or before the first division officer tour. This early

(keep it simple, stupid) principle. The Navy should go back to using its computers for number-crunching, for handling large quantities of tracks, and for processing sen­sor data. Let the tacticians, not the theoreticians, say what they need and keep them intimately involved in develop­ing it. In so doing, the Navy needs to reaffirm that for many years to come the key element in any system is the Mk-1 Human. His capabilities, using partial data to make a judgment, anticipating an action, operating in harsh en­vironments, and without power, must be fully exploited.

Commander Johns is currently officer-in-charge of the FFG-7-cl®* Combat System Test Center. Selected as EDO, he graduated from ¹ Naval Postgraduate School in 1982 with a master’s degree in weap⁰ systems engineering. His next tour was at the Naval Ship Weapon Sy^s terns Engineering Station as a Terrier Combat Systems Ships Quahtic tion Trials Officer-in-Charge, USS Norton Sound Aegis/Vertical Launc System (VLS)/Tomahawk Project Officer, and the Spruance VLS i^nsta lation planning officer. Commander Johns also served a tour in the Coit^ bat Systems Department at the Naval Surface Weapons Center Dahlgren, Virginia. Prior to that tour, he served tours as Boilers Off*⁶® Main Propulsion Assistant and ASW officer in the USS Hoel (DDG-‘-

selection forces a heavier burden on command and recruiting to identify abilities earlier and to allow flexibility in obtaining training early in an officer’s ca­reer. The aviation community already employs this type of se­lection. Early in flight training, a choice is made among helicop­ter, multiengine, and jet aircraft. After earning their wings, the pilots are further specialized into the various communities (attack, patrol, ASW, etc.) with little expectation of changing. In the past, surface officers optimally served in all three departments throughout their careers. How­ever, the transfer between battle group and support/amphibious ships began rather recently to enhance the concept of a single surface community. This “new” career path would return to a previous concept that served the Navy well.

To support this concept, the surface fleets would have to undergo a minor reorganization as well. This would basically require expansion of the tac- tical/administrative squadron practice currently in use. The tactical squadrons would merely specialize into escort and battle group squadrons.

With better defined roles for the ships, their battle manage­ment systems can also be more effectively planned. The major combatant combat system would obviously serve as an excellent basis for the battle group ships. Similarly, the Oliver Hazard Perry (FFG-7) battle manage­ment system would serve as the basis for the escorts. It is rela­tively small and optimized for

other steps. With today’s meth­ods, the warrior cannot use the system improvements, because the descriptions are buried in the documentation. He is not famil' iar enough with them to recog­nize them, and, at any rate, does not have time to read them. A weapon thus lost in paperwork is as worthless as one dropped over the side.

An equipment installer would not think of putting a new sys­tem on board a ship without a complete set of technical and operating manuals. Computer programs can change the opera­tional characteristics and capabn' ities as much as an equipment change can. These changes may be subtle in their implementa­tion, but they have a significant

minimum manning in light to moderate AAW/antisurface war­fare threat levels, but fully capa­ble of conducting ASW opera­tions. Figure 1 shows how the FFG-7 battle management sys­tem could be readily adapted to support the Knox (FF-1052) class. It would be an outstanding candidate for the class that re­places them. This consolidation of systems would serve two goals. It would limit the devel­opers while giving them a more clearly defined set of require­ments and would provide stabil­ity to the users as they progress toward command.

The improvement in transfer­ring the knowledge of the weapon from the developer to the warrior must accompany the

Table 1 Proposed Surface Career Paths