AO-1O 075 NAVAL POSTfiAO4JATE SCHOOL MONTEREY CA F/9 15/7MICROCOMPUTER SYSTEM FOR TAROET INORMATION IN THE FIRE SUPPO--ETC(Ul

JUN 81 R J COULTERUCLASSIFIEDhfh

E iEEllEEEEllEElllEElhElllEEIEIIEIIEIIIIIEEEIIIEIIIIEEEEIIIIIEIIIIIIE

NAVAL POSTGRADUATE SCHOOLMonterey, California

1.,-I

*THESISA MICROCOMPUTER SYSTEM FOR TARGET INFORMATION

IN THE FIRE SUPPORT COORDINATION CENTER:A DATA BASE APPROACH

by

Ronald J. Coulter

June, 1981

Thesis Advisor: Lyle A. Cox, Jr

Approved for public release; distribution unlimited.

LAI

11ii-. 4llll~liiiil

SECURITY CLASSIFICATION OF TWIS PA416 t'St DING 10414064________________

REPORTf DOCUMENTATION PAGE trEAD DESPLTRUC ORM

Ii TaU50i. Gov? ACCESSION NO: 1. 4ECIPIENT'S CATALOG WNN

4. TITLE (OD I se Iu oiiOVEREA Microcomputer System for Target Informa- -masters -rhesis

- ion in the Fire Support Coordination une I I 81'sCenter: A Data Base Approach. 11RII 0.REOTUNR

Ronald J./Coulter

9 EFRA~-N&IAINNAME AND ADDRESS 10. PROGRAM IELEMeNT., PUOJECT. TASK

Naval Postgraduate SchoolMonterey, California 93940

11. CONTROLLING OFFICE NAME AND ACDNRESS 12. REPORT DATEINaval Postgraduate SchoolJuo18Monterey, California 93940 Is 5ma NUEOF-WAGES

14. MONITORING AGEN00CY NANE & ADODESI S0 40 'm fte101 Ca"I11R OliEe) IFS. sCURITY CLASS. (of U.g vfteg)

Unclassified

4L. DECLASSIFPIC ATION/ DOWNGRADINGSCM )UlL

16. DISTRInUTION STATEMENT (01*1 AD "e)

Approved for public release; distribution unlimited.

17. OISTRIMUTION STATEMENT (00 the 8608ernd te W00011 #A .A1861 2,It 'n"imut 60 R40001)

1S. SUPPLEMENTARY NOTES

it. KE 9VwoRDS (Co~he g e vereo t O lds to~ aseese, go 140001140 6F Week Rogow)

Microcomputeruser interface, target information, data base,FSCC (fire support coordination center), fire support coordination,Marine Corps, UCSD Pascal, amphibious operations

20. AESTRACT (CamnU. - revee alsk IN 09004aI -W IdOS&f 6V &I& ogw

-his thesis presents the specification, design and implementa-tion of a prototype microcomputer system for the targetinformation section of the Marine Corps fire support coordinationcenter. Currently, the target information section uses a seriesof index cards, handwritten list, acetate covered battle maps andgrease pencils to perform the target information functions.

The thesis examines and analyzes these functions in detail and

DD 1473 EDITION OF INoO is IS OSOLEaTe UnclassifiedS/N812-84-40SE6CURITY CLASSFIATion or TNIs PARE (Whenm beis SRI~e

Cumt?V CL*SSIFICAIGN a. TWO% o"'GI(w"O" nv#* SA#Oftd

$roposes a solution in the form of a system, data base andinteractive user design. The resultant Microcomputer System forTraget Information (MISTI) employs an ALTOS Z-80 microcomputer,the UCSD Pascal operating system, a user friendly interface anddata base technology. It is proposed as an interim system untilthe Marine Integrated Fire and Air Support System (MIFASS)becomes operational.

DD ]EorT%_ 1473 caifie

SA, O10 2-014-6601 SECU1111T CLASSROCAT104 OP TOeS PA63I'U~mGm Dot* 'rotor")

2

Approvel for public release; distribution unlimited.

A Microcomputer System for Tarret Informationin tne Fire Support Coordination Center:

A Data Base Approach

by

Ronald J. CoulterLieutenant Colonel, United States Marine Corps

B.S.,Collere of the Holy Cross, 1964m.A.,Pepperdine University, 1975

Submitted in partial fulfillment of therequirements for the degree of

MASTER OF SCIENCE IN COMPUTER SCIENCE

from tne

NAVAL POSTGRADUATE SCHOOLJune 1981

Author: .

Approved by:

/ Thesis Advisor

- Second Reader

Cnai man, 0prm o omputer Science

Dean of Information and Policy Sciences

3

A PS T.RACT

Tnis thesis presents tne specification, jesI.Zr aftC

i~plementation of a prototype microcomputer system for tne

target information section of tne Yarine Corps fire sl,,pport

zoordination -enter. Currently, te tareet informatin

section uses a series of index cares, ndnwritten lists,

acetate covered battle maps ard erease pencils to pero rm

tne target information functions.

Tte tnesis examines and analyzes taese functions In

detail and proposes a solution in tne form of a sybten, data

base and interactive user fiesign. Tne resultant

OI-rocomputer System for Tarzet Information fMISTI) employs

an ALTOS %-?Z microcomputer, tne UCSD Pascal operating

system, a user friendly interface and data base tecPnnoloey.

It is propose! as an interim system until taE -arine

Inteerated Fire and Air Support Syster. :MIFASVI , tecowes

operational.

TALE OF CONTENTS

A1. THE PROBM..... ..... ..

P. BAC OJND. ..................................... 15

C. INTEGRATE2 FIRE AN AIR SUPPORT SYSTEM •... =

D. NATUJR! OF TEE ?FCBLE1 .19

?. NATURE OF TEE SOLUTION ."........................

II TARGET INFORYATION PROC RES AND EMPLOYENT. ....... 23

A. 1ENERAL............................................. 2

B. DUTIES OF TFE TARGET INFORMATION CFFICE.......?4

C. FUNCTIONS OF THE TARGET INFORMATION 3ECTION .... 25

D. TAPRGET INFrORmATION RECORDS AND FILES............. 27

E. TEE TARGET LIST ............................... 3

F. TAR37ET CLASSIFICATION .......................... 31

G. TARGET PRIORITY .................................. z2

H. THE TARGET BULLETIN .. .......................... 3

1. OPEPATIONS OF TEE TA"ZET INFORMATION S"CTICN...!3

" OPERATIONAL CFARACTERISTICS .................... 36

V SUMmAry ........ 37

III. rE4 DESIGN CONSIDERATIONS.................. o...... 39

A. PRIMART CONSIDERATIONZ ......................... 39

1. 2ariczround ................................. 39

2o Tas its............ ............... ........... 4

P. TF? USER IhTYRFACE ............................. 41

C. USER DESIGN CRITERIA . .. ................ ..

5

D. THE MICROCOMPUTER ENVIRONMENT .................. 4

FUNCTIONS OF THE SYSTEM........................45

1. Primary Functions .......................... 45

2. Displiy Options ............................. li

3. Print Options ............................... 47

F. SUMMARY .................................. 47

17. ST EM DESIGN ....................................... 4 9

A. CONCEPTUAL SYSTEM DESIGN ....................... 49

1. Generality of Approach ..................... 49

2. Data Base Considerations .................... 49

3. Applications Program Considerations ........ 50

B. PRELIMINARY CONSIDERATIONS ..................... 51

C qARDWARE SELECTION ............................. 52

D. PRO' RAMMING LANGUAGE SELECTION ................. 54

E. DATA BASE CONSIDERATIONS ....................... -5

F. USER INTERFACE CONSIDERATIONS .................. 5

G. APPLICATIONS PROGRAM CONSIDERATIONS ............ 54

H. SEC RITT AND INTEGRITT ......................... 51

I. TRANSITION .......... .......................... 53

V. DATA BASE DESIGN .................................... E6

A. FRELIMINART DES IGN PROCESS ..................... 56

1. Data Base Concepts ........... .. o. ....... 56

2. Data Base Terminology ...................... 58

3. File Determination ......................... 59

4. File Performance ......................... 71

5. Arcnltectural Perspective .................... 71

5

5. Typet:, Systems ........................ ...7

F. LQgICAl DATA ASi DESIGN ....................... 74

1. Data Splittine ............................. 74

. Record Lesion . 7b

3. 7oiume and Activity Analysi5 ............... 7?

4. Desig;n Conclusions ......................... L0

C. PYSICAL DATA BASE DESIGN ........................1

1. System Output .............................. =-

2. Index File Design .......................... L

3. Paysical Design Alternatives ............... b

4. Inverted File Design Consic"eratior.s ........ 3:

b. Flat File Array Processing ................. i1

6. Data Base Partitioning ......................

D. 'JTEER CONSIDCRATIONS ........

E. S JMMAP.!.......................................... z

VI. INTERACTIVE INTERFACE DESIGN........................ t

A. g NPRAL ........................................ E

b DESIGN ?RINCILPES ...............................

C. PSTCHOLOGICAL ISSUES .......................... izl

1. Snort-term "emory Consiaerations ........... L

2. Ciosure .....................................

3. User Anxiety ............................... it

4. Control ...................................

- RESPONSE TPi. ... .................. ii6

E. INPUT MODES ................................... i

1. Mode Selection ............................ 1L/4

7

w

2. le n U/orm i i n : c7 E aig .

F. SY6,(A HAi ................................ 1i

'n. APPLICAI'IiN P?,ORA14 i P?... ,A~i;:i ......... 111

. £j:CH NI C.!L C[: ASIfE:F.ATL NS ...................... 117

. SLST . FIN . ....................... I1

"I Iii. CVNCLUSIO 4S A i; R C'C .6 4 Da T I, I ....................

C. ON C ~A SIQ . ............................... ..1

8. RCO M, I ATIONS .............................. . 1e

ikLFk~iNIX A--DATA DICPTON&RI . . . 1 ............ 4

APPET4;I B--I;XAMPLE Ci S7 UJSeR ,TNAFC ............. 1:7

'IBLIDIRAP ............................................. I

1NITIAL LISTRIBUTION LIST. ............................... .

Ii

LISr o dIOJS

1. Exampleo Tar et Card .......................... --t

2. Target Circ File Organization ..................... :e&

3. Tar_-et List Terminology ........................... 41

.. System Zesi-n znvironrent ......................... -/

5. Design or tne Conceptuai 1olel .................... bl

b. Tar.-et Infor'atior System 'esign .................. C

'7. .Merrory Aiiocation ................................. D

. Data Base System krc u .tecture .....................

=. Tareet Inf'ormation Conceptual ?ecori .............. ?0

10. Primary and Seccn-ary Keys ........................ 77

11. Exampie of a Tareet List ...........................

12. Logical q.ecor: Lesign ...................... -'

13. System Ou tpu t ..................................... C

i . Target iiie Inrex ..es.n.. . ............

:h. UCSD fis-al Rni om Access Capaoility ............ -

16. Data 3ase (uery File Loglca± besign ............... C?

17. la In *em ory M a, for Data base 'ueries ............. z'j

I. Example of an inverte: 2ile Lcical Structure .....

1i. a a .ase 4uery File Pnysi-al Lesizn ..............

20. Data Base ?artiticning ........................... t

;1. Exarple ot a Menu ............. ................... - i

2 E ample of an I'rror M essage ...................... 1

'Z3. A-tual Se'-oalary Storaze Usaze ..................

_ _ .., -i

LIT vF AiR_7IATIONS

AA .- Anti-Aircraft Artiliery Target

ARTY ---- Artillery Tarret

ASCII--- American Stanlard Code for Information Intercnange

ASIS--- AMDitious Support Information System

B"A ----- Battle Damage Assessment

CBAT-....Counter Battery Target

CODASTL- Conference on Data Systems Lanzuazes

CP/ ---- Command Program/Monitor; operating system tuiit tyDiettal Research for *,icrocomputers

CRT ----- Catnode Ray Tute

DASC ---- Direct Air Support Center

DBSS---- rata 2ase Managenen: System

PT .. ate-Time Group

FkSC ---- Fire an Air Support Center

FDC ----- Fire Direction Center

FmFM ---- Fleet Marine Force Manual

FORT~--. Fortification, Bunker, Har .ened Site Target

FSC ----- Fire Support Coordinator

FSCC ---- Fire Support Coordination Center

IBM ----- International Business Machines Corporation

IJST ---- Installation, Buildings Target

-ilobyte (1021 bytes)

mATF--- marine Air-Ground Tas Force

10

"IFASS-- marine Integrated Fire and Air Suppcrt Syste-

*AI S ... - iscellaneous Tir_ e r

TACCS-'- irine ?actical Commani and Control Systems

NGF --- Naval Gunfire

NWP ----- Naval 'darrare Putlicatio

C? ------ Otservatlon Post Tar-et

SACC ---- Supportine Arms Coordinatuon Center

SA ------ Surface-to-Air 'issile Target

SEAP ---- Suppression of Enemy Air Defense

TARB T L-- Target Bulletin

TYRR.---- Terrain Tartet (Hilito.D, Road :uneticn. Fieli. e-,-.)

TG --- ---- narzet

TIC-- -- Taroet Information Center (Navy!

TI- ----- Tarzet Information *fficer

TIS ----- Tareet Information Se-tlon ("arine)

UCSD---- i versity of California at San fiego

V-H ---- 7ertIcular Tareet (TrucK, Jeep, atn.)

1ML

AKN dLSID'a2MN TS

The autaor woul, lIre to acxnowledre tne assistance an-A

support of Lt3ol Dcn Sortino, USYIC, Assistant 7ire Support

Coordinator of tae Second Marine ivision, Camp Lejeune,

North Carolina in provilar :urrent information on garzet

information -rocelures an! Capt C. ". ?iller, USIC, o± the

Marine Corps Tactical Software Support Activity (MCTSSAI,

Caip Pendleton, California for providirg timely and detailed

information on ne Marine Intezrated Fire and Air Suppnort

System (MIFASS).

The Ruildance and suzestions provided ty teesis advisor,

Professor Lyle A. Cox, Jr. and first reader, Professor Dusan

Z. Badal are leeply appreciated and tfeir encourazement and

confidence were a constant source of optimism. Capt Je!frey

A. Neufeld, USMC and Cpt A. Ross Strizler, U.S. Ar-y,

provided tecnnical assistance in tne finer points of tae

1JCSD system and thteir assistance prcvet tirely a:- valuat'le.

I. INTRODUCTION

A. THE PROBLEM

More and more of tne applications of modern amphibious

warfare, from real-time combat systems to tne data bases

that control the men, materiel and resources needed to wage

war, have turned to computerized solutions. The products of

te technological explosion nave enabled tne Navy-Marine

Corps amphibious team to do more, to do It faster and to do

it with a degree of efficiency and accuracy previously

unobtainable.

This evolution of modern tecnnoloRy has not yet reacted

the Marine Corps tactical command posts establisted on tte

beachhead. The target information section of the landing

force fire support coordination center (FSC.) plays a

signficant role in tne conduct of effective coordination of

tactical air, artillery and naval gunfire support on targets

of hiRft priority, fet the target information of'ficer ard nis

staff accomplish their Important tasir by zne use of Index

card files, cross-reference files, hand written lists of

targets and colored grease pencils on acetate-covered

tactical maps. Tnis method is time consuminR, slow in

response to inquires about target information, tedious and

difficult to maintain in a current status and does not

provide information in a sufficiently timely and accurate

x~ ~.n-

manner. It is 4:0 year ol tecanology in the age of

computers.

The requirement to automate many of tne functions of tne

tactical command post aas been identified and tne command

post of the future is beine planned for and developed now.

Until it arrives, there is a need to provide an interim

capability to the landint force. An automated solution to

the target information function will simplify t.e task of

tne tarret information section considerably, will provide

rapid, accurate and. timely target information to tne members

of the FSCC, and can be made operational now, five full

years before tae planned introduction of tne computerized

command post.

Tnis thesis contends tnat tne automation of tne target

information function is necessary to improve the operational

capability of tne landing force FSCC and tnat Implementation

of a suitable and effective tareet Information system Is

possible. This tnesis will prove tris contention ty

implementing and designing a working prototype whtich will

increase operational effectiveness immediately as well as

provide a testbel and learning model for the future

automated command post. The prototype will be desiened to

perform all the duties and functions of the target

information section as currently otated in doctrinal

publications. The interim system will hopefully contribute

to the development of the future system and identify aregs

14

of concern and improvement before tne future Marine Corps

system becomes operational.

B. BACKGROUND

An important aspect of ampnibious fire support

coordination (the plannine and execution of tactical air,

artillery and naval gunfire support so that targets are

adequately covered by a suitable weapon or croup or weapons)

Is the function of target information. One of the major

duties of the fire support coordinator, that member of tte

landing force staff responsible for coordination of fire

support, is to ensure that the fire support coordination

center receives and disseminates available target

information to all staff sections and commands requiriaz the

information. He also must worn closely with tne target

information officer and tne commander and his staff in the

selection of targets and assignment of classification and

attack priorities.

Tarret information is the direct application or combat

intelligence to fire support and is a cey to tne proper

employment of supporting arms in conjunction with earh of

the plans of the amphibious operation. Effective fire

support coordination and the planning of amphibious

operations cenerate a continuine requirement for target

acquisition, dissemination, evaluation and recommendation

for attact.

15

To accomplish this important task, tne commander of tne

amphibious task force assigns a target intelligence officer

to the supportine arms coordination center (SACC). This

officer operates tne target information center (TIC) and

works closely with tne air intellience officer, tne landing

force targeting representatives and the supporting arms

coordinator. The commander of the landinr force has a tareet

information officer (TIO) who operates tne target

information section (TIS) as an inteRral part of the landine

force fire support coordination center and a target

Intellirence officer who functions in tne landine force

intelligence center.

The Navy staff uses a computerized target information

system whica is part of tne slpboard Ampnibious Support

Information System (ASIS) and maintains the list of targets

as part of a data base. Target information operations in tne

SACC are thus computerized and, while tne ASIS target system

is not tne most modern of data base systems, it is

efficient, effective and fast. 4hen the functional

responsibility for maintaining targets is passed asnore to

the landine force TIO, the computer system is replaced by an

index card filing system, waica, wnlle effective, is neither

fast nor efficient by comparison. Additionally, the index

card system lends itself to inaccuracies and omissions in

target data, particularly when the information must be

maintained in a timely manner. The tactical requirement for

16

accurate and timely target information is no less critical

or important when the landinw force is on tte beach, yet the

system to accomplisn tlis tasx is antiquated and cumbersome.

The staff of the TIS manually transfers the tareet

information lata contained in the ASIS data base to 5 ty B

inch tarRet cards. After duplicatine thie entire tarret file,

tne TIS must construct a cross reference file to list the

target by grid location and a cross-index file to teep tract

of certain types of targets. In addition to the target

cards, tne TIS also mattes up lists of particular categories

of targets wlich may be of Interest or value to members of

the FSCC.

The TIS obtains 4 ntellizence information from iandine

force and supporting arms agencies, converts this to target

information and enters the Information into the tarret -ard

files. The information is made available to the supporting

arms representatives in the FSCC and, based on the TIO's

recommendations, a decision is made when and tow to attaci a

Darticular tarret. Results of attacks on tarrets, front line

reports and intelligence information are used to refine tne

tarret list and delete or deprioritize those tarets trat

present a diminisned threat to the landing force.

Access to specific information from the tareet list (fcr

example, more than one category of tne cross-index files)

requires pnysically searchin, tnrouefn each list and

constructing sub-lists to determine tne appropriate

1?

information. The constant availability of timely and

accurate tariet information is reulred for tne Ptfective

employment of supporting arms and planning of fire support.

The TIS plays a rey role in providine tnlis information and

the constant process of adding to tne target list, selecting

tareets for attacK and deletine tireets once neutralized is

performed by tne TIS staff using tne target card file.

C. INTEGRATED FIRE AND AIR SUPPORT SrSTE4

One of toe most covplex asvects of modern ampniblouS

warfare is tne control and cooraination of supporting arms

particularly in tne transition of responsinility from the

Navy in ampnibious snips to tne Marine Corps combat units

ashore. The crease pencils, map boards and field ralios that

nave served Marines so well since tne days of Guadalcanal

will, in the future, be eclipsed by the automated system

called the MOarine Integrated Fire and Air Support System

(MIFASS).

MIFASS is part of the Marine Corps Integratea command

and control system called MTACCS (Marine Tacti.al Command

and Control Systems), a collection of eignt major systems

which will give the Marines a capability of exercising

real-time command and control of combat forces In tne

post-19eO time frame. MIFASS is designed to perform tne

functions of the fire support coordination center, (FSCC)

tbe direct air support center (DASC) and, to a degree, the

artillery fire direction center (FDC) at one central

location called tne Fire and Air Support Center (FASC).

It is a distributed processinr system in whi-

microcomputers control interactive display devices, manage

data bases, perform computational tasi.s and drive printers

to provide nard-copy records of messages and operator

decisions. It is currently in full scale engineering

development witn an initial operational capability planned

for the 1986-1987 time frame. MIFASS addresses tne

requirement for target information by proviaine the TIO witn

a digital display device which will have bota a grapnical

representation of the target on a battle map and a video

screen for alpnanumeric display of target information.

D. NATURE OF THE PROBLEM

An automated solution to tne target information function

will not be realizea until tne introduction of tne MIFASS

computers into tne Fleet Marine Forces. Until sucn time as

tte system is delivered, the tareet information function of

tne FSCC is tied to tne current doctrine and tne target card

filing system.

In this report, an interim systems solution to tne

problem of automating the target information function of tte

FSCC is presented. It computerizes those basic functions of

tte TIS in a simple, inexpensive and effective manner. It

simplifies the tasks of the TIS, provides a mechanism for

11

rapid and accurate retrieval of target information and could

irprove the operational capability of tP.e FSCC.

8. NATURE OF THE SOLUTION

The amount of target information tnat needs to be

processed is sufficiently small tnat a mi-rocomputer is tne

rost suitable piece of tardware for implementation. Tte

current versions of microcomputers are very versatile with

efficient operatina systems, various input/output media

including video terminals, inexpensive and relatively

Dortable secondary storawe media (floppy lisKettes and

cassettes), nign level language programming capabilities and

even scaled down versions of lata base manapement svstems.

Tnus, tne tecnnology in nardware as well as software

currently exists in the commercial marketplace and it is

possible that a practical system can result from efficient

and careful design and Implementation.

The design task is broken down into three distinct

parts, each of which Is influenced by tne overall design

cnaracteristics and is individually addressed In separate

cfapters.

The design of tne pnysical and logical data base is

influenced by tne iesire to nave a simple yet sufficiently

informative data model, a rapid, real-time response ard a

restricted, single application system. Te system aesign is

Influenced by tne microcomputer environment wnicn restricts

20

tne user botn in main memory space and lie speed of access

to secondary storaee and. the requirement for an e..eftive

interactive system for a non-sopbisticated user.

The desian of the software to Implement both the data

base and the system is overwhelmingly influenced ty tne

requirement that the system support real-time, interactive

processing of a casual, non-prorarmer. Terred "Yarine

proof" in the vernacular, it reouires a sopnisticated

Interface employing user friendly dlaiogue tecnniques to

ensure that zte operation is simple and efficient. For this

reason, and to facilitate system portability, a

microcom.nuter compatable nicn level procrammine laneuage is

employed in implementation.

In order to better identify the user environment and to

obtain an unierstandine of the functions o" target

information, the next chapter describes tne mission and tfte

current procedures of the tareet information section. It is

i from tnis information that t.e system cnaracteristics were

developed and the desiten based. The information was obtained

from Navy and Marine Corps doctrinal publications as w.ll as

current operatine procedures of a Marine Division target

Information section. Chapters Ill through VI develop in

detail, the reasons for the parameters selentea and the

decisions made in tne design of tne overall system, tne

logical and pnysical data base and the applications

software.

Chapter VII adiresses tne implementation of tte system

ani further implications of system application in the .arine

Corps, as well as tactical employment and interface witn

current ani future systems. Conclusions and recommendations

are included in tne last cnapter.

The source code listine, which has been developed as a

result of this tnesis, nas been publisned as a Naval

Postgraduate Scnool tecnnical report entitled A Prototype

Proeram for Target Information (NPS52-81-07). A data

dictionary an! an example of tae system Interfa:e are

included in tne appendices. A bibllograpny of applicable

references and a list of abbreviations used are also

included.

22

IIIH r. . 1[ Il I

II. TARGET INFORMATION PROCEDURES AND EMPLOYMENT

A. GENERAL

A precise understanding of the auties of tfne target

information officer and procedures used oy the taraet

information section is required before letallel requirements

for an automated target information system can be statel.

This chapter is devoted to that purpose. It discusses ant

examines in detail the doctrinal duties and functions of tqe

target information officer and the current procedures for

executing tnese functions.

The tareet information officer is a member of the 'ire

support coordination center (FSCC). He and nis staff provite

tarret information to the fire support coordinator so that

effective employment of supporting arms is driven tv timely

and accurate target intelligence. He works directly witn tne

artillery representatives, tne air officers and tne naval

gunfire support officers in alseminating appropriate target

information and obtaining surveillance information. Ee

assigns battle damage assessments for attaciked targets and

further refines the target list.

His relationsnip witn both the ampnibious tasK force

target intelligence officer and the landing force target

Intelligence officer is extremely Important since it is from

ttese sources tnat ne obtains the target intelligence wnlcn

generates the target information.

I

B. DUTIES OF THE TARGET INFQRMATION OFFICER

The TIO is a Marine Corps offIcer wno performs nis

duties under the stiff coenizance or tne fire su pport

coordinator (FSC) inl worts closely witn the lan~inz force

oDerations and intellizence sections. The primary aoctrina

publication for tne Marine Corps is Fleet Plarine Forre

Manual (F*'FM) 7-i (Fire Support Cooraination wnicn outlizns

nis duties as follows:

1. Keeping tne FSC and tne other fire supportrepresentatives in the FSCC informed of t e status otargets.

2. Ensurine tnat pertinent tareet intelligence is postedon the FSCC target and/or situation maps.

3. Preparing and maintaining target file cards.

4. Entering target attaci evaluations and surveillanceson the target cards.

5. Supervisine the operation of the tareet in.formationsection (TIS) of tne FSCC.

5. Preparine the landine force list of tarets or tneMarine air-Rround task force (,YAGTF) target list forpromulgation by tne operations officer. The FECC willprovide tarrets, to include their classification andpriorities, wnicn are to be included in thne target list,target bulletins and/or lists of targets.

7. Preparine and releasine target bulletins when controlof tne target list has Deen passel to tne commanderlanding force or when tne MAGTF is engaged in landwarfare.

8. Keeping tne target Intelligence officer advised oftarget Information available througn supporting armssources.

24

C. FUNCTIONS OF THE TARGET INFIRJATIOJ SECT1DN

The funItns of tne TIb are oriente!. to t.e

requirements of tne supportinz arm5 (air, naval eunfire ar(

artillery) in the preparation of fire support plans and tne

comand requirements for target inforiation. Tne TIS uses

all of the available intellirence eatfnerea by the apen-ies

of tne a'nnibious task force and tne landing force. These

azencles include landine torne and ampnibious tasic force

target intelligence sections and inteilipence a6encies of

the supporting arms.

The TIS is responsible for recordine all tarpet

information, analyzing tnis target Information, maintaining

records and mazino recommendations of tarzetb wnlch are

appropriate for attaci. FMFM 7-1 lists tne foilowine

functions of the TIS:

1. Maintaining required target ana situation maps.

2. Maintainin- target cards and tarpet files, in_ ludinzcross-indexel files of' target information.

3. Consolidating, evaluating and displaying targetinformation.

4. Recommending classification and attac& prliorities totne FSC.

5. Collectine trom all azencies and sour-es, anyinformation pertaininR to tne results of attack ontargets bv tne supporting arms.

6. Consolidatine and evaluating results of attacics bytne individual supporting arms and tae metnoas ofattacic, and recommending additional measures tnat appearnecessary from the overall results and analyses.

25

7. Coordinating on all matters witn tne landing f:rcetarget intelIieence officer and the artillery unitintellieence officer for target and counter'ireinformation and correlation of records and files.

S. 'aintaining current counterfire target lists toinclude counter-mortar, counter-battery and SEAr(suppression of enemy air defense) lists and provialngthis information to the supportine arms representativesas well as ensuring dissemination to tne landine forceas a whole.

9. Preparinz and lisseminatine target oulletins(TARB'JL's) after control of tne target list nas teenpassed astore.

i. Maintainine a nuclear and chemical target foiaer toassist in tie selection, evaluation anti pianninR ofattacK by supportinz arms utilizine nuclear anct cfneri-almunitions.

The composition and organization of the TIS varies with

tne FSCC level out typically at tne landing force level it

consists of one officer (TIO) and from one to three enilsted

personnel. Personnel are usually trained in target

intelligence, supporting arms capabilities and limitations,

organization, fire support coordination principles and

communications.

While the functions and duties of tareet information

personnel are letermined by the doctrinal putlications, t".e

actual procedures to accomplish tnese functions will differ

slightly from one organization to another, nowever tnese

variations are minor.

D. TARGET INFORMATION RECORLS AND FILES

The records and files of tareet information consist

primarily of situation maps, target file cards, target lists

and cross-indexing files at tte landing for-e level. Tt! y

are tne tools used to catalogue, analyze ant disseminate

target information.

The tarret map provides a visual referen-e o'-" tarzets

appropriate for attack by supporting arms. The friendly

situation map contains all information pertinent to

supporting arms operations and typically includes

objectives, front lines, fire support control measures, unit

boundaries and unit locations.

The bulk of tfe record ikeeping involves tne target file

card. The file of b by L incn cards contains a separate

target card for each known or suspected target botn by

tareet number and by zrid coordinates. FiRure 1 is an

example of a target car.. Information appearing on t:e

target card includes the followine:

target symbol (conventional Map symbol)tarret numbertarget classificationattack prioritytarmet location (zrid coorilnates)tarRet elevation in metersmap referencetareet descriptionassignment of supporting arms attacK meanssource and date of target informationphotocrapni numoer and erid locationremaris of additional signlficance

27

Security TARGET CARDClassificationTarget Number Map Symbol C- d Coordinates

1A 21S'7 l3( 45 - 76.SoTarget Classification !Elvation

Target Priority Map ';imberiDescription

/IA, CArAY 60AJT Dr5NSE ARTLLCiY IN/rM4hL7700

Assigned to: ( Afir (O " Naval Gunfire ( ) Artillery( ) Other Support Weapons:

Source and Date of InformationAdPT g7~s ij~itjrg 6I .1

Photo Number Photo CoordinatesV P 17- /1wfA * 916- 74.Ao

Remarks:

Trri~' WT H rLv -Z!A,,44gAvo NF$ us4wG A (wo

Security

ClassificationFRONT OF TARGET CARD

SecurityClassification RECORD OF MISSIONSDate/Time r -7 No. Rounds Damage d Damag;iGroup Firing Unit and Type Reported ssess&'

*1 .1

____________________________ L____________ - L 5< * ' - •.:

BACX OF TAR(FT CAP,"

7ue 71Tleofa7j,7- ^ar-

The target cross-index file consists of one card or list

for each type of target (e.g., counter-battery. arnicr, SEAD,

fortification, etc.). Eact card or list typically ircludes

only the tarret number of eacn tareet, it's priority, tne

recommended me tnod of attact ana tne final disposition of

tre tareet.

In a typical amphitious operation, tne landing force

usually operates wita a maximum of approximately 20-600

targets. With a separate target card for eacn target hy

tarret nuMber as well as by arid coordinate and a

cross-index card for tne 10 to 15 target types, the target

file can easily exceed 500 caras. An example of a Mlarine

division target card file organization is illustrated in

figure 2.

ACTIVE TARGETS INACTIVE TARGETS

Figure 2. Target Card File Organization.

29

E. THE TARaET LIST

A semantic distinction must be made between tte target

list" and the "list of tarrets". The "tarret list" is a

collection of targets wnich is maintained ant promulgated by

the senior echelon of command. There is only one tarret

list". It contains targets wnicn are pertinent to tne

landint 2orce as a wnole and wnicn are to oe taken under

attact by supporting arms. A list of targets is maintained

at any echelon of command and includes tnose confirmed,

suspected or possible targets for information and planning

purposes as well as for possible attack by supporting arms.

The "target list" is a subset of the "list of targets".

Subordinate units use the tarret list as their basic

source of targets anc also include targets that nave a

sianificant but specific or "short-life" value to their

operations in their unit list of targets. ks an

illustration, a battalion would only include those tareets

from tne landing force target list wnicn were located in or

adjacent to their zone of action.

Targets can be further describea as active or inactive.

An active tareet is one which is on the tarret list or list

of targets and presents a bonafide current or future enemy

capability to interfere with operations. An inactive tarret

is one wnlcn has been overrun by friendly forces or

destroyed by supportinr arms or has shown no activity for 72

nours and no damage assessment nas been ,ade, although tnese

-0

latter tarets are inactivated witn caution. Te inactive

targets are placed in a deadfile and reactivated it

necessary. Figure 5 depicts tne target list terminology.

ACTIVE TARGETS INACTIVE TARGETS

LIST OF TARGETS

TARGET LIST

Figure 3. Target List Terminology.

F. TARGET CLASSIFICATION

Targets are classified ov tne effect wnicn tneir

existance or elimination may nave on the ampaibious tasK

force and by restrictions imposeA by the commander on tne

attack of certain targets.

The primary doctrinal publication for aTpnibious

warfare, NWP 22-2 (Supportine Arms in Amphibious Operations)

W list tne following target classifications:

Class A...Tareets that threaten snips, aircraft,minesweeping and underwater demolitionsoperations.

Class B...Tareets that threaten assault forces in thesaip-to-shore movement and assault of toebeach .

Class C...Targets thnat threaten or oppose landing forceoperations afterlanding or affect toe abilityof the enemy to continue resistance.

31

Class D...Tareets tnat will not be fired on prior toD-Day.

Class E...Tareets that must not be destroyed (unlessspecific orders for Such destruction areissued by the amp tibious tast force or landineforce commander) eitner because of probablefuture use by our own forces or forhumanitarian reasons. These installations maybe neutralized, harassed or interdicted 14.prior approval is obtained from the commanderimposine the restrictions.

G. TARGET PRIORITY

The target information officer, in coordination witn tne

tareet Intellieence officer, the fire support coordinator

and the supporting arms representatives reviews and

recommends the assiRnment of attacK priority. The t-rret

priority is established to determine the sequence of attact

and/or the effort to be allocited to a eiven tarRet. Tne TIO

establishes the priority based on the target's effect on tqe

accomplishment of the landine force mission and its relative

importance as compared to otner targets.

FI1FM 7-1 lists the followiln tarwet priorities:

Priority I.....Targets capable of preventing tneexecution of the plan of action by thelaniing force and its elements.

Priority II....Targets capable of immediate seriousinterference uitn the plan of action o.f thelandinR force and its elements.

Priority III...Targets capable of ultimate seriousinterference with the plan of action of tnelanding force and its elements.

Priority IV.... Tarrets capable of limited interferencewitth tte plan of action of tne landir.pforce and its elements.

32

H. THE TARGET BULLSTIN

In order to maintain up-to-date target information

records, it is essential that reports of the discovery of

new tarrets ani the analysis of supportinw arms attacKs on

existing targets be reported to the appropriate units. Tne

TIO evaluates and consolidates reports of target information

ani supporting arms battle damage assessment (FDA) and

prepares a tarret bulletin (TARBUL). Upon approval, it is

released to interested commanders of nigner, lower and

adjacent elements of the amphibious tast force.

The TARBL is normally transmitted over existing

teletype or radio circuits and typically adds new tareets to

tne target list (giving tne target number, location,

elevation, priority, classification and description), eives

damage assessment to existing targets wnIcn nave teen

attacied by supportine arms, canceils tarwets from the

target list (relegating tnem to the deadflie) and

reactivates previously cancelled targets. TARBUL's are

serialized and Issued on an as-needed basis.

I. OPERATIONS OF THE TARGET INFORMATION SECTION

While the target information section is neavily involved

in the early phases of the operation, the most important

witn respect to tnis tnesis occurs during the preparation of

the objective, ship-to-snore movement and operations ashore.

33

The target list is Initaily maintained by the SACC

tarret intelligence officer. Tne tareet information is

stored in a data base of the ASIS system and a navy computer

operator woriine in the SACC operational spaces uses tne

QUEST data base query language to access targets and target

information from the data base. Requests for a tarret

listing and for special purpose reports must be composed in

the query lanruare each time. Response to the query is

displayed on a video display unit in the SACC. The report

printouts are available from a printer located in the main

computer spaces.

During tnis period, the TIO is monitoring and

duplicating the target list with the target Cara flies. It

typically is an opportunity for the TIS staff to become very

familiar with the target card file procedures, altnougn it

requires almost a complete duplication of effort between tne

TIC and the TIS.

When the TIS goes ashore with tne landing force FSCC,

they obtain computer printed copies of the latest tareet

list as a backup to tneir card file. Cnanges to tne target

list durine the phasine of the TIS ashore are covered by a

TARBUIL issued by the commander amphibious tast force.

Operations ashore are characterized by constant

refinement of the target list, adding newly acquired targets

and the employment of supporting arms on existing targets.

Vhen target information is received, the target is plotted

34

on the target map, a classification assigned, a target card

prepared and all available information evaluated. A priority

of attack is assigned and a recommendation regarding attacK

by supportine arms is made. The tareet card is then added to

tne target number file, tne grid location file and tne

cross-index file If necessary.

As fire support missions are executed, tne TIS attempts

to expedite the surveillance reports from te available fire

support sources. A 1amage assessment Is made based on tne

reported surveillance. The Information is added to tne tack

of thie target card and tne target is uplated as requirel.

The primary sources of this Information are artillery

forward observers, naval gunfire spotters, forward air

controllers and liaison officers.

New targets are reported to tne landing force TIS from

the tarret Information sections of subordinate units wfto

nave uncovered targets of sufficient importance to be

recommended for inclusion on tfte target list. Targets are

also received from tne target intelligence officer, tne

artillery tareet acquisition battery and acoustic and

seismic sensors. Based on tne accuracy of tnis information

(confirmed, probable, possible or unknown), a determination

is made whether to addt tne target to tne target list, tne

list of targets or the inactive file.

35

J. OPERATIONAL CFARACTERISTICS

The operations of tne TIS focus on two major functions;

the maintenance of the target card file and the erpnical

representation of tne target information on tne target map.

Tne former function appears to lend itself to an effective

automated solution. Tne following items are the significant

recurring requirements for maintenance of tte target card

file:

adding a target to the file

deleting a target from tne file

chtaneinr information about a tareet in tne file

changing tae status of a target (active-inactive)

updating tre cross-index file

The products of tnis maintenance are used by tne TIO and

the staff of tne FSCC for effective fire support

coordination and delivery of supporting arms. An analysis of

these products indicate that the target card file provides

the followine specific capatilities:

provides all target information for a specific target

differentiates between active and inactive tarrets

sorts or catalogues targets oy various parameters (wnicninclude target no., coordirates, classification,priority, tarwet type, supportine arm assiened anttarget accuracy)

provides information upon wtict to base a TARBUL

provides information for production of tne target list

36

Any automated solution wnicn will be of value to tne TIO

must be able to perform tne requirements for mainterance of

the target file quickly and efficiently. It must provide tne

requtred end products (TARBUL, target lists, specific

information about a particular target, etc.) as well as tne

capability of proviline specific tarret information in a

manner and format wnich can best bp utlilzed in tte FSCC.

The solution involves tne manipulation and management of

the information contained on each target card in such a way

that the speed, efficiency and effectiveness of the TIO is

enhanced. Tnis must be done in a simple, easy and

uncomplicated manner and must produce timely and accurate

information.

K. SUMMARY

The organization examinedt in this chapter is for the

landine force target information section (TIS) (typically a

Marine division or a Marine ampaiolous brigade) wricn

constitutes the most important and most heavily staffed

section. The TIS exists at regimental and battalion level as

well, but with less formality. The card file is not is

extensive (due to the fewer number of targets in tne zone of

action of a smaller unit) and the tareet personnel usually

perform tneir functions as an additional ratner tnan a

primary duty. The automated solution, however, is equally

useful for subordinate units of tne landing force in

37

assisting them in tte effective and timely managETent cf

tarret inforvration so that they may effectively errploy tfneir

supporting arms on tne most important targets.

This cnapter has provided a review of tne duties and

functions of tne target Information section, tne tools and

doctrinal procedures of target information and tne

tecnniques of operation. Idditionaiiy, the cnaracteristlcs

of the tarret information tunction which can be automated

nave been ilentifiel anl analyzed. The foliowing cnapter

uses tis analysis to levelop a conceptual framework for ine

design of the target Information system.

38

Ii

III. SYSTEM DESIGN CONSIDERATIONS

A. PRIMARY CONSIDERATIONS

1. Bacteround

Having defined tne current procedures for tte target

information function, the tasi now remains to provide a

satisfactory system design for an automated solution. Tte

design is influenced by two important considerations. Tne

nature of tne data base is both physically small in size and

functionally restrictive in wnat information Is required

from it. This, combined with a requirement for a relatively

ligntweignt, portable and versatile computer, ma~es tne

selection of a microcomputer an obvious and logical cnoice

for nardware. Tnis confines tae solution, nowever, to tne

microcomputer environment which, while it ha5 many desirable

features, imposes a number of major restrictions on tne

design.

The second major influence on the design is tne impat

of numan eneineering on tne user interface. Tne user is a

Marine in the tartet information section of the FSCC and tne

functions ne performs are a Known entity. Tne system must

conform both to his level of tralnine and computer

sopnistication and to tne functions and tasks ne performs.

Tnis requires an interface whlicn is user friendly, extremely

easy to operate, sufficiently sopalsticated to allow tne

~59

user to perform the required functio~ns effectively and

withiout error, and capable of operatine In a reai--Ure,

interactive Mode.

T~us, the solution is confined by two Separate

environments: tne microcomputer environment and tne one

defined by tq2e friendly, sophisticated user interface. Thiey

jointly determine the aata structures, tne control

structures, memory allocition, Interactive COrrplexity and.

the system modular aesign. The system must be designed to

operate effectively within tie restrictions Imposed by tne

microcomputer and the parameters required by tne user

interface. An abstraction of these environments is depicted

in flture 4 below.

Figure 4:. System Desien Environment.

2. Tasks

A key task in the system design Is tne definition of

the usare fictor. This is the description of the system's

processing requirement, I.e., how the data Is utilized ty

40

the system. This leads to a top-down desizn methodology and

tnree i)portant tasis wnicn will determine tne design o: tne

data tase as well as the applications program. These tasKs

are:

1. To identify all processing functions and subdivide

these functions into modules (processes).

2. To determine all of the data that eacn process uses to

perform its desienated function.

3. To adequately describe tae system retrieval

requirements.

B. THE USER INTERFACE

While chapter VI will address in detail tne numan

eneineerine aspects of the user interface, it is Important

to recognize at this point in the development of tne system

that the user is classified as a parametric user. Simply

defined, the parametric user is one Whose system input is in

the form of parameters only. He is not a prozrammer altnouefn

he Tay have programs available that he can use. "'.e is

transaction oriented, puttine information into thre system

and retrieving it from the system, generally requiring a

short response time. The parametric user requires -urrent

and timely data ani rapid ana easy recovery from errors.

In addition to destinine the system to perform the tasxs

and functions of target information, it must be engineered

for the parametric user in order for it to be used

41

effectively ani with a degree of confidence because of its

predictable benavior.

In the design of an interactive system, a very important

consideration is tne appearance of tne system to the user.

Use of the technique cf interaction by anticipation, tna.t

is, anticipatine the lesires of the user and presenting ni,

with a corresponding list of options, allows tne user to

simplify his input by selectine rather thlan spe'ifyinp tne

data. The employmert of menu selection tecnnl.ues and

computer initiated dialogue, important applications of

interaction by anticipation, will be used to provide the

friendly man-macnine Interface.

C. USER DESIGN CRITERIA

A particularly important aspect of tne design is tne

nature of the constraints on the 7oenitive processes of the

user. One constraint is tne amount of information tnat a

person can consider at one time and tfe lenetn of time that

tne information can be retained in snort term memory. Hence,

the inforT.ation available from the system snould be simple

enough to be quickly and easily assimilated.

The system snould also be fast enought so tnat tne user

is not distracted by the loss of information in nis snort

term memory due to a slow response time. The system should

be able to reinforce user memory wnenever required. Tnis

liplies a user initiated request for lelp to wtict the

42

system must reply with tne appropriate information. An

important aspect in iesigning a aelp function is unifor-ity

or the command as well as the expected reply.

A second consiaeration wnict Is important in tne design

of interactive systems is the experience level of the user.

The system snould be able to cater to tte novice user and

effectively direct his input to perform the required tasks.

It is also important for vie system not to ignore tne

experienced user. The interface should be able to adapt to

zne needs and cnaracteristics of its users basect on tae

user's experience.

The interface should also be robust in nature. It snould

respond in an effective and unambiguous manner to any input

and allow the user to recover from simple errors. It should

discourage illegal input and guide the user to tne proper

inputs required. It should provide closure to the user,

i.e., a logical completion to a specific action witnin an

expected period of time. It should limit the user input to

tte necessary data and instructions sufficient to perform

the required tasics.

This is test accomplisned for tne Darametric user ty

interaction by anticipation and a restricted and unambiguous

flow of man-macnine communications. Thus, communications

from the user to tte computer is by discrete selection cf

semantically meaningful options, and from the -omputer to

tte user by tne presentation of information contained in tne

13

nenu selection or iialcgue frames. Tns will allow for rapid

and easy operaticns for tne user and a unity of desizn for

tte lipleientor.

D. THE MICROCOMPUTER ENVIRONMENT

Microcomputers impose a stringent set of restrictions on

tne resources available when implementing or executing a

program. These restrictions include the small size or main

memory, t e lengtny access time and small capacity of

secondary storage and tne low processing rate.

Typically, microcomputers are constructed witn 32 to 6;K

bytes of main memory. When consideration is made for tne

operatine system, tne applications proeram and thqe data

base, it becomes oovious that tney cannot all exist in main

memory at t~e same time and tne partitioning of remory and

the arraneement of seconaary storage will te a Key

consideration in tae system design. Putting all tne data

into Tain memory is not feasible because of its size, yet

putting all the data in secondary storage results in

unacceptable response time.

System response time is important to tne user. Thus.

thiose operations to which he expects a quietK answer must te

performed quictly witn minimal access time. For otner

operations which are lorically time consumine to tfle user

(for example, input of a new target into tne target list',

closure will have to be delayed (withn a :omputer advisory

44

-TessaRe) wnile tne inforr.atlon is processe.. Tne routines nf

tne applications programr rrust be lesigned to optimize tne

accesses to secondary storage, wnicn is tne tottlenecs in

microcomputer systems.

E. FUNCTIONS OF TLH' SYSTEM

From an analysis of t,.e infcrmatlon provided ty te

tartet carl file and =hte functions and duties of tne tar,et

Information section, a number of major functlons ot' tne

system have been identified. From tn.esc functions, syster

output nas been identified, totn in tne form of d!snlay on a

vil.eo terminal and printed nard. copy. These functions and

outputs determine tne a esi n ot tne data tase, tne

applications program and tne overall system.

1. Prliary Functions

The primary functions of the syster involve tne

manipulation and input of target information Into tne proper

storage formats. These functions include:

Ad a target to tne fileDelete a target from tne fileCnante inforrmation about a tarretCnange target status (active/inactive)Copy data base to a backup fileInitialize tne tareet file data baseDisplay certain target InformationPrint certain target information

These last two functions could become very extensive

operations if desired. However, a carefully restrictive

lesien of tne data base model and a desire to limit tre

45

seinantic options of t!e parametric user to certain, systems

define:! operatioms, has reduced thqetr to manarable yet fully

applicable functions.

2. Display Options

The CRT (catnode ray tube) aeviCe will te tne

primary user interface mectanism. Most of tae information

input and extracted froi tne system will te Der'ored via

tte CRT. The interactive queries to tne iata base will

result in the followine display options:

Display a complete target cardDisplay a list of all the active tarRetsDisplay a list of all the inactive targetsDisplay the target listDisplay the information for tfe next TARPULDisplay a list of targets by specific paraneter 's)Display parameter status for the active targets

The parameters indicated above are selected categories

of target information obtained from tne target card wnicn

are the typi'al parameters for special listings and tne

cross-index files. It represents a selection of tnose items

of information wnich can be most effectively utilized by tfte

FSC and the supporting arms representatives in tne FSCC.

These parameters include:

46

Target PriorityTireet ClassificationTarget NumterTarget StatusTareet TypeSupporting Arm AssignedAttacel TargetTarret Information Accuracy4rid Coordinates

5. Print Iptions

Earl copy of tne tareet information is a definite

requireent for operations at any level iSCC. The system

will have the capability to print the tareet list and tne

list of targets. The production of a TARBUL based on tne

transactions with tine data base sine tne last published

TARBUL will provide a significant nelp to tne TIC.

The target listinrs by specifin parameter (fcr example,

a list of all active targets, class C, prioritr II, of

tareet type "SEAr" assizned to artillery) is a requirement

tnat will te applicable to all members of tne FSCC. The

system will also nave the capability to print a -opy ot tne

target card for dissemination to otner azencies as well as

to provile a manual backup in case of power or coputer

failure.

F. SUmART

This chapter alone with the preceedine chapter has

defined tne doctrinal functions of target in'ormatlon,

determined the environment for the automated solution of

tnese functions and presented tne system requirements for

47

this solution. These ctapters form a necessary fouraation

for tne subsequent Cnapters wnch address tne specli

details of tne system and tne data base desi-n. The next

cnapter addresses trne actual system desien and flnlules tfe

nardware ani software selection and a top-down, ioduiar

anproacft. It contains irportant Jecisions cloncernine tne

data base waich are developed in greater letail in cnapter

7.

48

IV. SYSTEM DESIGN

A. CONCEPTUAL SYSTEM DESIGN

1. Generality of Approach

In tating a top-down classic approacm to tne desi-n

or the tareet information system, tte initial desirn does

not consider the restriOtions Imposed Oy tne operating

environment. This is done for two reasons. First, tne

conceptual design presents a simple, traditional, straignt

forward solution which can, in concept, te readily

implemented. Second, it provides tne basis upon which

modification and adjustment may be performed to fit the

simple solution into the restrictive environment. The size

of th e system, tne interface requirements, ana the

restrictive data base view will cause the conceptual aesio:

to be tailored and modified to operate in the selective

environment.

2. Data Base Considerations

The target carl data provides the entities (or

records), attributes and relationships o±" a nata tase

system. The controlling software, the data base management

system (DBMS), would normally contain language facilities

for defining the data base, for manipulating tne lata base

information and for obtainine information fror the data

base. This last facility, tne high level query language,

49

allows tr.e user to manage the information or tne d ata tase

and perform tne required operational functions.

The data base concept enables the user to store the data

In space saving and efficient ways. Redundancy 0f data can

be eliminated and data items deleted wlicn can be impli-itly

derived from otner data items. Tre system allows

-onstruction of different views ot tne lata so tnat

different users can perform different functions on tne same

type of data. Applications programming is simplified since

it only needs to specify parameters to tne DBMS whicn

locates and fetches tne data.

Thus, the design of tne data base portion of tne

'onceptual System will require the construction of the

logical and tne pnysical view of tne Information, definition

of the information in terms of tne data base definition and

manipulation languages and providing a LBVS witn a facility

for auery lantuase translation to operate on t.e data base.

3. &pplications Program Considerations

Tte user environment remains as leflnea, a friendly,

sopnisticated Interactive man-macnine interface. Tne

applications procram must interact witn the user and witn

the DBMS. Tne use of a query language for tne parametric

user would require the user to learn tne data base query

language. Alternatively,a collection of query lanpuage

statements could be imbedded in the applications program and

selected by tne user utilizing tne menu selection interface.

50

These statements would interact iirectly witn tne r3'1S.

A1ditionally, tne tost lanpuaze could be extended to enable

it to pass Information to tne LB!S in tne form o!* a

procedure call.

Tne requirement for menus, nelp functions and system

explanations could be effectively solved by tne use ,f

user-oriented utility modules wfnicn could be accessea ab

needed. Tue basic conceptual system aesign derived from a

top-down view of the target information system tasK is

depicted in figure 5. This basic design will be refined to

fit witnin the solution environment.

QU€ERY IISYSTE INFORMATIUNICAPABI1LITIES 1 I 'DULES

IP UT / 0TJTP UT

k ~~MANAGEMENTDAABSSYSTEM

Firure 5. Desien of the Conceptual Model.

B. PRELIMINARY CONSIDERATIONS FOR SYSTEM DESIGN

Witn the basic framework laid out by the conceptual

model, tne task now becomes one of attempting to insert tnis

51

classic approaca" design into tne restricted anvironment of

tne Ticrocomnutir. This reauires a i Pr. de=ree of

specticitv in order to identify tae tools to be eTployed in

the Implementation and the methodolory of erruloyine those

tools. The target macnine must be identified to precisely

define the microcomputer constraints. The data tas- modal

and Its physical and logical organization must be defzinei,

the applications proeram functions an. tasic flow analysis

must be determined and tne target programming language must

be identified.

C. HARDWARE SELECTION

The selection of the system tardware was driven by tnree

considerations. First, it nad to be a commercially

available, typically configured microcomputer. Sucm

tenerality Is needed if the system was to te transportable

to other microcomputers. In tne searcn for a typical

microcomputer, an eftort was made to avoid the nome or

personal computers wnicn, wile small, easily transportable

and inexpensive, possess neither the processine power nor

tne virtual memory capacity needed for tne system.

The seconl consideration was for a computer tnat

possessed acceptable size and weignt cnaracteristics tor

transportability, had a compact configuration, was generally

ruzeed ftor a com ercIal product and nad sufficient

processing capacity.

52

The third consideration was availability. Tne ALTOS

MCS-8000 is a representative of micro-systems commercially

available, and was selected for use in tris worK. The ALTOS

microcomputer conforms well to tne desired computer

cnaracteristics. LCDR D. L. Smith in .is thesis entitled

Mettod to Evaluate microcomputers for Non-tactical Stipboard

Use cited the ALTOS as one of the top four mi-rocomputer

systems evaluated and found it suitable for use on U.S. Navy

snips.

The ALTOS ACS-8-1 is a single board Z-SO& based

microprocessor with 54K bytes of random access memory and

two Snugart SA-800/801 eignt incn, single side floppy

diskette drives contained within the 16 ty 7 by 17 inch

compartment. It requires a CRT for input/output and supports

120 characters of upper and lower case ASCII with FO

cnaracters per line on a 24 line vileo uisplay. The computer

weighs approximately 35 pounds, nas a forced cooline systen,

utilizes standard 115 volt electric power witn a rattery

backup and operates wthin a temperature range of 32-105

degrees farenneit and a nuility range of 10-9Z percent.

The two floppy diskettes with tne IBM 67: single

density format and tne 64K of main memory gives a total

memory space of 575K bytes. The nign level language support

for tne ALTOS Includes tne CP/M operating system, basic,

FORTRAN, Pascal, PL/I-eO, APL, LISP, COBOL and the Micro

Data Base Systems D.BMS for a microcomputer.

55

_17- 7:7-

D. PROGRAMmIN3 LANGUA'£ SELECTION

The selection of a programminz lancuaze was influenaed

by tnree major considerations. First, tne nardware selected

and the availability of assemblers, interpreters and

compilers to support a programming project on tnis naraware

narrowe tie field consilerably. Second, tnere was a desire

to use a language wnicn is relatively self-explanatory,

self-documenting and transportable. And finally, tne

language would nave to support a robust, user-oriented

interactive program.

Of the available lanzuazes, Pascal was selected for a

number of reasons. It has features wqict mairae it readily

useable for systems and applications propramminR in trat It

is "strongly typed", requiring explicit data declaration. It

forces the data tase to be completely desianed before tne

source program is written.

Pascal's structure encourages modularity as well as

top-down design and implementation. It is a relatively

siiple language and is the basis for tne proposed Department

of Defense standard nlgn order programming language, Ada.

The most popular verrion of Pascal for microcomputer use is

tne University of California at San Diego (UCSD) version

developed by the University's Institute for Information

Systems.

The UCSD (Mini-Microcomputer) Pascal version 1.4b is a

system intended to run on a stand-alone mini or

54

microcomputer. It is nignly macnine independent since it

runs on a pseulo-macnine interpreter. Tne system contains a

compiler, linter, screen oriented editor and an operating

system wnicn are compatible with Z-9 microprocessors tnat

operate under tae Digital Research CP/ operatine system.

Because of tne microcomputer environment, tnere are a

number of differences between tne UCSD Pascal and the

standard version of Pascal as defined by ensen and Wirtn.

Particularly helpful are a number of strine intrinsics,

random access of files by a SEEK command, file nandling

commands and seement procedures. The seement procedure

capability, for example, enaoles the user to segment tne

applications procram into a main prorram and up to six

procedure modules wncn are retrieved from secondary storage

when called. This allows a laree portion of the proeram

object code to reside on dist wnen not needed, taus,

Increasine the size of main memory for computation and

operating system functions.

E. DATA BASE CONSIDERATIONS

The design of tne pnysical and logical iata base is

addressed in detail in tte next chapter and, accoraingly,

this section will aidress only those items of importance to

the system design. In that tae user view of the schema and

tne conceptual view of the scnema are identical, and because

there is no requirement for an integrated data base, tne

55

traditional data models (relational, nierarr.nlal and

networt) will not be employed.

Consideration was given to using existing DBMS systems

for the target information system but they were rejected for

essentially two reasons. First, tne target Information

system is a restrictel, single application data base. It is

sufficiently restricted that a general Durpose,

multi-faceted data base management system is not required.

Second, the use of a DBMS query language was considered both

time consuming and difficult to learn for tne system user

and unnecessarily complicated the interface. This is

especially true because the system is designed to limit the

type of queries allowed on the data base.

By extending the nost language from the applications

program to the data base, data Independence is lost.

However, since tne system will not allow the user to access

the data base in any way other than that specifically

allowed by the system interface design and since tnere is

only one view of the data, tnis does not present a protlem.

The data base will consist of two files. The irst is a

flat, relational model representation witn the target as a

sinele record and the tarret information pertinent to thIat

specific target as the attributes of that record. All of tne

active and inactive tareets will be contained in this main

target file. The second file will be tne data base query

file consisting of the primary and secondary zeys for each

56

target. Tne standard system queries will return information

in the tareet list format and will obtain all tnh necessary

data from the data base query file.

This partition of data base files increases the data

redundancy of tne system since all tne lata in the query

file is duplicated in the main file. However, tnis is done

to Improve tne system response time to user queries by

greatly reducing the disk accesses that would nave been

required to process the main file. This tradeoff is made in

favor of the user interface and at the expense of additional

storaze space and increased proeram complexity.

Tne secondary keys used to process tte target

information queries (priority, classification, type, etc.)

are contained in the in tne data base query file. An index

file containine the addresses of the tarzet records is

constructed in main memory at the beginning of tne program,

thus, eliminatinR the need for a separate record address

file and reducing the number of disK seeks required to

access a record from the main tarret file. lere this not

done, the system would nave to access an address index file

in secondary storaie to obtain the address and then access

tne record in tne main target file in secondary storage to

obtain the record. Having tne index in main memory requires

only one access to the disk, tne access for tne actual

record.

57

The modules or tle applications proRram directly

interface to tne data base files accessing, manipuiatine and

rewriting tie lata as necessary. The system performs data

base operations, not data base management and is an

extension of tne host language.

F. USER INTERFACE CONSIDERATIONS

In the preceding chapter, tne user interface was tefinec

and the eeneral requirements determined. These requirements

are now translated into specific design parameters for tae

tareet information system. Additional discussion of the user

interface and details of tae dialogue tectniques used are

presented in depth in chapter VI.

The user interface is cnaracterized bY four major

attributes:

1. All communications between tne user and tne computer is

through menus, if a simple command is adequate, or tnrough

interactive computer initiated alialozue for more extensive

data entry.

2. Extensive help is available at all times. This nelp

includes explanations of tne options available, tne format

of the required input and examples of tne correct input.

3. The display processing time is as snort as possible to

remain within tbe constraints of snort term memory

retention and logical closure.

58

4. The user Is restricted to the system defined options

for data input and data and information retrLeval. Tnus,

only those procedures defined by the system throueh tne

menus and the dialogues can oe used.

G. APPLICATIONS PROGRAM CONSIDERATIONS

The ietnodology of applications program aes Ion

encompasses three separate but Interrelated areas, earn of

which is continually influenced by tne system aesion

environment. Taese areas are semantic structure design,

syntactic structure design and software design.

In the top-down semantic design stage, tne system goals

were translated into the applications procram coals and tne

system functions and requirements were determined,

categorized and prioritized. The task flow of the system was

analyzed and alternatives developed and compared. The

selection of the most effective solution to eacn of tne

problems posed by the system requirements was expressed as a

functional module. Tnis module was then further broken down

into smaller modules wnicn address particular parts of tne

functional requirement. The data structures and control

structures were then determined whict oest enable these

modules to perform the required functions.

Tne design of the syntactic structures paralleled tnat

of the semantic structures and involved tne determination of

display formats from a comparison of different approacnes to

59

the user interface. In addition to display formats, system

response formats, error dliaRnostics, user aids and help

facilities were also specified.

The software was designed in a top-lown modular fasnion

and best use was made of the facilities of the UCSD Pascal

system segment procedures as well as the structured apprcach

provided by the Pascal laneuaae.

The tareet information system applications program

consists of six major modules. The primary module is the

Interface nodule. It acts as the executive of the program

and controls the interaction of tne user input/output, the

data base operations and the segment procedures.

The remaining modules are segment procedures, that is,

they reside in secondary storare until called into main

memory by a procedure invocation. Upon invocation, tney are

read into main memory and computation continues. When

control is returned to the calling procedure (in tnis case,

the Interface module), the memory space is deallocated. The

UCSD system allows up to six of tnese segment procedures and

permits them to be nested in order to further reduce the

amount of code necessary in memory.

The Initialize module is used wnen the data base system

is initialized and a new tarret file is created. The Query

molule contains the menus and the semantics for the system

queries to the data base query file. It is used only when

target information by specific parameter is desired by the

'60

,I3. A Utility molule contains a number of nouseleepilng

routines for constructinw tne TARBUL, determinint tarret

file status, copying the data Ocse to another disrette,

printine tarret listinrs and other functions.

The Target module is the major segment procedure and is

used for addine, deletinc and cnanine tarrets in the main

target file. It also updates the data base query file and if

necessary, the TARBUL file. The Inform module contains

user-oriented information concerning doctrinal terminology,

systems instructions, version information and tactical

guidelines.

The target information system design is illustrated in

fieure 6. Because much of the desiRn was influenced by tfe

microcomputer constraint, the amount of object code resident

in memory at one time has been minimized. The illustration

in figure 7 snows the expected allocation of secondary and

main memory for the system. (see paces 64 and 65)

H. SECtRITT AND INTEGRITT

Security for the system is essentially

non-discretionary. The system is secure because it is

located in a secure area (the FSCC is usually a restricte.,

controlled access area within a secure perimeter). The

tarirets contained in the list of tarwets are typically

classified confidential and, therefore, tne diskettes would

be considered classified matter. Thus, the usual precautions

61

and practices for tne security of classified material are

sufficient for the system.

As a further safeauard and security feature, tne system

will nave a user password wnich will allow only bonafide

individuals to access the data base of tareets. Input or an

Improper or erroneous password will Keep the user in tne

outer edwe of the Interface module and prevent openine tne

data base index file witnout which, the data cannot be

accessed. The Utility module has a subrcutine which allows

the user to specify his own passwords.

The target information system will reside on an eight

Incn floppy diskette wnich will contain the Pascal operating

system and the object code of tne applications program. The

source code, editor and compiler will be removed from the

diskette to prevent any user from modifying or changing any

part of the system. The user can only cnange the password

and the target Information.

Upon activation of the system, a user advisory messace

will be printed on the CRT screen informing tne user of his

responsibility to safecuard the classified information. All

of the printed output of the system will contain

confidential marines on each pate as required by current

security regulations.

Nuclear and cnemical target information and analysis

will be excluded from the target information system and

processed in accordance with current procedures. This is

62

done primarily because tnese targets require special

techniques for analysis, are typically of a nigner

classification tfan confidential and are of such a decree of

sensitivity tnat special nandlinz is usually required.

I. TRANSITION

A tey element of the system Is the pnysical and logical

desitn of the data base. Since the system is functionally

restrictive, the data base nas been designed to provide

optimal performance to the user. Tlis fas resulted in design

parameters wlicn are explained In deptn in the next cnapter.

The chapter develops some of the important considerations of

data base tecnnology and tne metnodology of data base

selection and file determination. These techniques were used

to design tne logical target information record.

System and environmental requirements Impact

sienificantly on tne pnysical data base desien and a number

of alternatives are presented and evaluated. The pnysical

record design as well as the inverted file indices are

described in detail and provide a justification for tne

system design presented in this chapter.

63

B ATGETZ E (ULITv:'ODUL.& MULU LE I A IRG UU

D A TA -B 6

PASSiURD v.A iIN 1; ATA T A.'UFILE T RG AS EIL

FIILL

Fieure 5. Tarret lntormation System n

04

IA IN 3

Larus et~~~ K

SCO NDCY ~ ORe

Passwom ra5 aL

1 Data za~e

Tar nui ii ie

Di rec to ry

ManTarret

Flizre 7. "em.orv Allocation.

V. DATA BASE DESIGN

A. PRELIM INART DESIGN PROCESS

Before tne design of tne pnysical and tne logical data

base can proceed, tnere are certain ground rules and design

criteria that must be establisned. Data base technolory has

become tiore formalized In tne past ten vears with general

acceptance of three major data models, the relational, the

hierarcnial and the network or CODASTL. The task now becomes

one of determinine the content of the tarret information

data base and waicn of tne major data models is most

appropriate for tie detailed design of the logical and

physical data base.

1. Data Base Concepts

Perhaps the Initial startinr point should be a

definition of tne data base. One of the most often quoted

sources is James Martin's from his Computer Data-base

Organization:

A data base may be defined as a collection ofinterrelated data stored tocetner with as littleredundancy as possiole to serve one or more applicationsin an optimal fasnion; the data are stored so tnat tneyare independent of prorrams which use the data.

It is important to distinguish between a data base

system and a file system. A file system oreanizes the data

storage capability wflcn is provided by the hardware or

operatine system software. The hardware is partitioned into

66

files wnich are associated with a particular user or for a

specific purpose. Operations on one file are done in

isolation from the otner files (or otner users). Tnus, to

access the same information from many similar files may

require as many separate operations as there are files.

A data base system, on the other hand, organizes tne

file storace capability which is provided by the file

system. The relationship between elements or entities of tqe

file are made accessible to the system. The user Rains

access to all of the data because it is now available

throurh relationships to other data. Additionally, different

users can access the same data and snare it.

Access to the iata base is provided by a data lantuare,

a set of operations wnicn permit access to the data that has

been organized by a lata model. Data base manaeement systems

are generally classified by the way they provide access to

the data. A self-contained system provides all the

capabilities and required services by itself, typically,

throuch a query language. Host-based systems carry out the

retrieval and update functions only and leliver tne data on

request to proarams written in the host system laneuare.

Occassionally, tne nost language is extended to operate

directly with the data base, but usually witn a loss of data

independence.

67

2. Data Base Terminology

Eaca of the major data models refers to concepts of

data in slightly different terminology. For example, the

physical record type "target" consisting of target number,

grid location, altitude, priority, classification and

description is called an entity by one model, a segment or a

lozical recorl by another and a tuple by tae tnlird. To avoid

confusion and misunderstanding, a set of terms which are

partially intuitive in nature and eenerally from the

relational model will be used. These terms, their

definitions and an example from tne target information

system are as follows:

Record.....a croup of one or more data items or attributes

which corresponds to a simple record or entity [a

tarret]

attribute.....the smallest unit of data, a data field vita

a certain value [target AA0001 with the "Driority"

attribute nas value IIIJ

Relationship.....the connector between individual records

of the same type or rroups of records of different

types (tne list of targetsj

Relation.....the set of all records of a riven type tthqe

list of targetsJ

K6.

!4m

Degree ..... the number of attributes in a record [for a

record with tareet number, location, priority,

classification and description, the degree of the

record would be 5 1

Cardinality.....tne number of records in a relation [tne

number of tartets in the system]

Domain.....tfte set of all possible values for an attrioute

[priority has domain I, II, III,IY]

Primary tey.....one or more attributes of a record whose

value uniquely identifies the record [target number

AA0045]

Secondary rey.....an attribute wnicn may or may not

uniquely identify the record but which defines a set

on the record (all priority I targets]

Schema.....the structure of the entire data base

Subscneva.....that portion of the schema viewed by a

particular user or group of users

Flat file.....a relation in norm~al form: a sinrle level

record array with only one record type

3. File Determination

The total volume of data in tne target information

system must be viewed witl the objective of splittine it

into smaller units that nay be considered tfle basis for

oreanizine tle data base file. Havine already determined the

system functions from chapters III and IV, the data objects

69

W i" -

and the relationslips to perform these functions must be

determined and organized. The results of tnis organization

will become the criteria for the modular design of the

applications proram.

William House in Data Base Management provides an

excellent metnodoloy for file determination. Data splitttna

separates the system Information into subsets wnich can be

dealt with more or less independently and perhaps made an

independent file of the data base. Record desien determines

the format of the content to appear in eacn record and the

modes of indexine in order to establish the index data that

must be present.

Volume analysis estimates the size of the Individual

record and the size of the record's relation (cardinality).

The pbysical distribution of the number of records in each

file must also be taken into account to determine the space

management requirements. Activity analysis determires the

frequency of reference and estimates tne total activity for

the records of each file. It is this analysis that is

essential to the question of file design and one of tne tey

considerations in the microcomputer environment,

particularly the access bottlenecE to secondary storage.

File design is dependent upon the record structure,

pnysical distribution of the records in tne storage device

and the indexing method employed in referencing the record.

The critical issue for file design is its performance.

70

4. File Performance

There are a number of criteria wt.icn must e?

considered wnen estimating the performance of the file

desin. There will inevitably be a trade off between storage

space and processing speed. Tnere are instances wnen tne

rapidity of access to information in tie data ease is more

Important than saving or optimally utilizing the secondary

storage space. This may mean redundancy of data.

Gio Viedernold in Database Desizn outlines seven

measures of file performance. These parameters were

considered wnen designing tne pnyslcal data base. These

measures of file performance include:

1. Storage required for a record2. Time to fetch an arbitrary record from tne file3. Time to ret the next record within the file4. Time to update by inserting a record into the file5. Time to update by changing a record in the file6. Time for exhaustive readinc of the file7. Time for reorganization of the file

5. Arcpitectural Perspective

The data base system architecture is also an

important consideration. It depicts the natural, conceptual

and physical views of thne data in thne data base. It is tne

key to data independence and gives the DBMS much of its

power and flexibility.

At the most abstract level, tnere is tne external data

base. This is the way in which the user views the data base.

It consists of any number of different perspectives of

Individual users, which are considered Subscnfemas of tte

71

data base. Typically, the subscnemas are more important tnan

an overall view of the external data since they define tne

information environment for a single user or specifin

application.

The external data base maps Into tne conceptual data

base which is the lorical view of the information contained

in the data base. It is tne schema, or combination of all

the subschema expressed in the lorical format of a ata

model. It consists of tne records, relations and

relationships of the data as well as the primary and

secondary kreys used for processing the data base.

The conceptual level maps into tae Internal data base,

which, as tne physical view of tne data, is tne least

abstract level of the architecture. The physical data base

contains the records, files, Indices, invertea files and

record sequences of the data base. &n illustration of t-e

different levels of the data base system arcnitecture is

shown in figure 9.

72

IEWVi External View

DConceptual View

PHYSICAL

DATA IInternal ViewBASE

Figure S. Data Base System krcnitecture.

6. Types of Systems

The discussion so far has mainly considered tne data

base manarement system concepts for the tareet information

system. Given the nature of the target information file and

the system environment, other types of systems bear

consideration. An appropriate alternative to a general

purpose DBMS mitrit be a sinale application system.

A single application data base system establisnes an

operation usine thae available file system facilities and

designs applications programs wnicn interface to tne data

base. A system for the routine processine of data and the

answering of a prespecified and limited class of oueries is

sometimes referred to as an operations system. This type of

system is designated for a precisely defined and limited set

of operations.

73

In a data base manawement system (DBMS), an information

system, tne nature of tne queries will not be pre-definea by

the system and lenrthy searches may be necessary wren a

query is made. Tte capability to process generally stated

aueries is ctaracteristi" of the multi-purpose desirn or the

DBMS and often accounts for its relatively large size and

cost. In an operations system, leninty sear-hes c-n

generally be avoided because tne information Is typically

stored in the form it is needed. The two types of systems

use data bases wnicn are differently structured both

logically and physically.

B. LOGICAL DATA BASE DESIGN

1. Data Splitting

Given the total information in tne tarret

information system, or more precisely, the set of data tnat

represents this information, it is necessary to separate it

into subsets wnlch can be dealt witn more or less

independently.

The information for the system comes from the target

card. All of the information pertinent to tne data base is

on tnat card or can be implied from it. A blocK record of

all of this data pertinent to the system can be visualized

in firure 9.

74

TARGET NUMBER GRID LOCATION ALTITUDE

TARGET TYPE ARM ASSIGNED ACCURACY

ATTACKED? FIRING UNIT PRIORITY

CLASSIFICATION DESCRIPTION DTG ACTIVE

PHOTO NUMBER PHOTO COORDINATES BDA

MAP REFERENCE TARGET LIST? REMARKS

DTG ATTACKED NO.TYPE ROUNDS STATUS

DAMAGE REPORTED DAMAGE ASSESSED SOURCE

Figure 9. Target Information Conceptual Record.

The data can loeically be split into different serments,

for example, description information, surveillance

information, status information and source information, but

a consideration of the user and the conceptual view of the

system is necessary first.

Tnere is only one user, tne target information officer

anl he has only one view of the data, tuat of the target

card. He may use tnat data differently lependine upon the

tactical situation or internal operating procedures but nis

logical view of it has not cnanged. An Integrated data tase

will have many users and many different views of tte data

(one schtema with many subscnfema). The tarret information

data base is not an integrated data base and it tas only one

user and one view of the data, thus, tne schema and the

subscneqa are tne same. The need for data independence

75

(lorical data in tlis case) is no lonzer required for tne

system because the external view is equal to the conceptual

view.

Splittine the tarRet data does not achieve any alded

flexibility, simplicity, independence or efficiency. T.us,

the tartet record can consist of tr.e above 24 attritutes, no

other relationships and be organized as a flat file.

2. Record Desirn

For tals large set of data on target information, a

determination must be made of the format of ttie record and

tne modes of indexing in order to establisn thne index data

that Must be present. Two alternatives were considered, one

with a flat file and a second with multiple records. The

multiple record version merely aded more complexity and

more data to the files with little benefit to the syster

otner tnan it "loored" more like a data base.

The flat file appeared, to be tue simplest :onceptually

ant tne easiest to implement. The data witnin tne record was

ordered in a functional manner for semantic purposes and tne

primary and secondary keys were determined.

There is only one way to uniquely Identify a target and

that is by tne target number. This is primarily dictated by

doctrinal procedures since tne target alpna/numeric

combination determines the orizinatine unit as well as a

specific target. Target grid coordinates may be consiaered

as an additional unique Key, however, a sin-ele map location

76

can be targeted for multiple purposes. Therefore. tne target

number was selected as tne primary Iey for the record.

There are a number of secondary Keys for eacn target but

only a few of these nave a real meaning to the TIO. Those

Keys which will be needed to access certain types of target

information nave been selected as secondary Ieys. It is for

these keys tnat tne queries to tne data base will de

desianed. Tirure 10 illustrates the primary and secondary

Keys of tne target record.

Primary Key Secondary KeysSUPPORTING

1i

TAGTARM PRIORITY

-- TARQLTCLASSIFICATION

,RECORD

Fieure 10. Primary and Secondary Keys.

3. Volume and Activity Anai°'sZ

Estimates must be {,,..e of individual record sizes

Fand tnen of the expected file sizes as well as determining

the frequency of reference ot information in tne data base.

In determining record size, a number of considerations came

into play. Data items which could be derived or implied from

GRID

other data items were deleted. For example, if a tartet nad

a BDA in tne record, it had been attacked oy supporting

arms. If there were no BDA, the tareet had not been

attacied.

Additional attributes were Identified whose reouirements

were implied by other lata items. For example, target type

was made a record attribute (and a secondary key) since the

target description, being text, would nave to be

semantically analyzed in order to reveal all targets of

enemy "artillery".

Attempts were made to reduce tne size of stored data ty

encoding tae domains of attributes. The domain for target

priority is (I, II, III, IV]. To place priority III in the

target record file would take three characters; reduced to a

numerical representation, it tares only one number (3).

Target damage is described by a maximum of eigtt different

words, the largest of wnich is ii cnaracters. This has teen

reduced to a single number from one to eignt.

A data dictionary was developed which listed each

attribute, its domain, data item size and data type (see

appendix A). From tnis document, the size of the record was

determined to be approximately 240 bytes. Since adequate

secondary storaze appeared to be available, a fixed length

record was selected. In addition, since more than one BDA

was expected for a given target, tne record size was

increased to three BDA per target bringing the record size

78

to approximately 370 bytes. With a taximum of 600 tareets in

the system, tne file would occupy appproximately i1O bytes

of secondary storare.

An estimate was made of tne number and type of

references to tee data based on known and anticipated

tactical requirements. Azaln, the desien restrictions on

what tne user could asK of tne data base played an important

consideration. The majority of the information for retrieval

was either an Individual target card or a list of specific

tareets. Return of the tareet card to the user was a sirple

matter for file design, merely retrieve the record from tne

data base and display all of tte information. Thqe retrieval

of specific Information is more complicated.

The specific information about targets is best displayed

as a target list since tnat is the most useful format for

the user. Figure 11 is an example of the format required

from the data base.

79

LIST OF TARGETS

TGT NO CL PRI LOCATION ALT SA DESCRIPTION

&AO021* C 11 34566543 90 AIR 2 T-62 TANKS&AO020 C IT 23055565 W0 NGF 5 INCH COASTAL GUJN&A0056* E IV 67665466 50 NONE 4 SCHOOL BUILDINGS&&0013 A 111 5577412 15 NOXF BUNKERED TRENCHLINEAZ1022 D II 76b5454 110 ARTY BN ASSEMBLY AREA&Z1005* C I 34345656 20 ARTY PLT ZSU 23-4&A0012 3 111 56445456 10 NGF CONCRETE BUNKER

NOTE: * indicates tarzet list

Figure 11. Example of a Target List.

4. Design Conclusions

Because the data base is a single application data

base and is an operations system ratfter than in Information

system, the use of a specific data model was rejected. The

flat file format lends itself to the relational 'rodel ard

tne resultant system approximates tne relational

methodology. The system does qualify as a data base.

However, It Is a very restricted one due to its specific

purpose.

Access to the data base, eiven the limited ,hloice

Imposed upon the user by the system design, was by extending

the host lanrualee ratner than the use of a query ianrulaze or

Imbedded data language. Tfle record designl Incorporates tne

tarret information as one record with one primary and seven

secondary reys for a total of 22 attributes. This monolithic

record is depi,7ted In figure 12.

80

Target Description

TGT NO DESCRIPTION JGRID LOCATION] ALTITUDE jRE PRJKS

Tareet Status Infform~ation

DTG FRING NTYPE DAMAGET CLASSFIATIO SATU

Target Survelace Information

MAP SOURCE DTG ACCURACY PHOTO PHOTOREF 01' TOWT IACTIVE NU11BER COORL

Figure 2.2. Logical Record Design.

C. PHYSICAL DATA BASE DESIGN

1. System Cutput

The system output must be considered tefore

discussinc the Physical data base desirn. These enrt-proiurts

require a certain content, format and response tjre.

Retrieval of Information for the TIO Must be rapid and trte

physical design of the data must facilitate speed, even at

the cost or storace efficiency.

These items of system output nave previously been

ilentified and are depicted schematically in figure 13:

TARGET CARD TARGET LIST

LIST1-3 BY PARAMETER(S)

SYSTEM~OUTPUT

TARGET STATUS OFBULLETIN ITARGET FILE

Firure 16. System Output.

2. Index File Design

The choice of file organization is lependent upon

the record structure, the physical distribution of tr-e

records in tae storage device and tne indexing metnod

employed to reference tVe record. To some deeree, the arroint

of storage space available will influence tne file design as

well. The critical issue is, however, the erficienry of its

performance.

The record is accessed by its primary iey. Tne target

nri'ber, unfortunately, is not always assigned in sequence.

Tauis, there Is no lozical order inherent in the tarret

number altnouga tney could be ordered in numerical sequence

for the sate of order. But there is no consistent order to

warrant the use of bequentlal, indexed sequential, nasned or

binary tree storage schemes. The use of tte dense index

allows us to access tne required target efficiently (with

only 300 targets) as well as insert new targets easily at

82

_a-

the end of the file. While deletion of tarPets would leave

noles in tne storage file, an unnsea target space record

could be maintalned whieh would ieep- track of the toles and

assign newly inserted records in tne available space.

The dense index woull nave to be made on both the tareet

number and tne Rril coordinates, since it is a doctrinal

requirement to be able to sort on botn. Tn UCSD Pascal

implementation makes tnis a muc easier operation witn its

string intrinsics and random access capability c " relative

records. This also allows the index to be stored as a

subscripted array anI enables tne system software features

to do most of tne manipulation. The Index aesian is

illustrated in figure I. It is essentially two arrays each

consistine of tne tarzet number or the Rrid location f or

eacn of tne allowable 300 targets.

Twt no Tet no ........ Tet no Tet no

Rec no 0 Rec no 1 ........ Rec no N Rec no 300

[ arid Grid ........ Gri Grid

Rec no 0 Rec no 1 ........ Rec no N Rec no ZOO

Figure 14. Target File Index Design.

.... MW

The ease of tae UCSD Pascal random access capability is

illustrated in figure 16. Tae SEEK command on tne file na'e

and tne record number provide for a base address and an

offset to tne required target number. TnIs allows for quIcK

and easy access to any target requested by the user.

SEEK Tet no X

TARGET FILE INrEx

Tgt no Tgt no I Tgt no

Rec no Rec no Z Rec no

File name BASE ADDRESS

Record no OFFSET

Rec no RECORD

Rec no RECORD

a Re c n o X RECORD

Rec no RECORD

Figure 15. UCSD Pascal Random Access Capability.

84

3. Ptysical Desirn Alternatives

The file design will permit easy and efficient

access to tae target record. The display of tne target card

is essentially solved by tnis design. Winat remains is tne

accessing of tae important attributes for the target

listines by specific parameter, i.e., the queries from tne

TIO.

The most straient-forward approach is to access all of

tne required data from trie target file. An efficient metnodt

of doint this would be to use multi-linxed lists tnrou~n tfte

appropriate data Items. Header records would provide a

pointer into the file and lins would provide access to each

item of specific data. Thaere are overnead considerations in

this approach, particularly in rearranging tne linirs when

adding or deleting a target.

A major disadvantage to this approach is the estirrated

time it would take to process a query. If all priority I

targets are to be retrieved, the program module must find

the header index and follow the pointer tnrouth the tartet

file until it found eacn of tne priority I targets.

The dist accessine to secondary storare is a bottleneck

in a microcomputer and should be minimized wnenever

possible. The access time to find all priority I, class C,

previously attacked, tang targets could be quite lengtny.

Arranging the file into blocks of five to ten target records

per block would decrease the amount of disk accesses.

85

A second approach would be to use an inverte l'ile

structure (often used in data base systems to improve cirect

access to certain data) for each of the secondary Keys with

a pointer (actual or symbolic) to eacn of the specific

records. An access to the entire inverted file index would

identify by, nave or by location, eacn of tne applicacle

records. Once determined, the records could be retrieved.

To process a target list with multiple parameters, only

the target numbers from the indices need to be read into

mevory and the appropriate intersection made of the common

record attributes. This would entail one seek per Index and

then one seek for each appropriate record. A~ditionla

efficiency is obtaine4 if all the index files are reac into

main memory when the user is going to make accesses to tne

data base. This will reduce the number of disk seeKs

required to access records and is particularly effective for

multi-parameter queries.

There is a bit more efficiency in tne second method,

particularly in accessing data with multiple parameters but

the cost is in use of more secondary storaze for tne

inverted files. With the amount of secondary storage

available (see the estimate in fizue 7), the trade-off

between storage space and processing speed is considered

acceptable.

A third alternative is even more expensive in terms of

secondary storage since it calls for redundancy of target

86

data. A subset of the main target file can be fcrmed to

orovide the data in a more accessible form. The file would

be a separate record extracted from tne main target file and

consist of only tnobe attributes or Items wlich will be

needed for tne target auery and tne resultino output

listing. This would eliminate tne need to access tae main

target file for queries since all tne system queries would

be confined to tqe data base query file. Once tne target

number was identified by tae query mecnanism. the

appropriate target listing information would be obtained

from the file and displayed on tne CRT screen.

This data base query file would nave records of 45 bytes

in length vita a maximum file size (for 300 targets) of

about 14K oytes. Tte logical record is illustrated in figure

16. To access tne data in tnis file, tne Inverted index

files could be usel.

TARGET STATUS GRID ALTUE YPT UMBER LOChTIONALIUEITP I

PRIORITY CLASS SUPT A.i DESCRIPTIONASSIGNED

Figure 16. Data Base Query File Logical Design.

Tne data base query file would be loaded into main

memory each time tne Query module is activated. There is no

requirement twrite the file to secondary storage when the

Query module is deactivated since there will be no changes

87

male to the file. In that tne Query module and tne data tase

query file would be simultaneously located In main memcry,

queries could te quickly and efficiently processed.

This eliminates tne need to access tae disk to perform

queries, therefore greatiy reducine the processine time. T.e

cost, however, is in an additional file in secondary

storare, an array to hold the data base query file in main

memory, redundancy of data and tailoring of tfte data base

ouery file and the Query module to fit into main memory

simultaneously. Th.ere is also tne added ccmpiexity to tfe

prorram when additions, deletions and chanzes are made to

tne ialn file in tnat tnese cnanges must also be reflected

in the data base query file.

Consideration was given to doine, all updates to the data

base query file wnile it was located in main memory since

the array which holds the records is a static data

structure. While it would improve system efficiency and

preclude loadine tne data base query file each time the

module was called, tne cnances of loss of data tarougn a

power surre or a system failure are sufficiently Preat to

eliminate this approacn. The differences between tae two

data files after a lor period of uninterrupted operation

would render tne query capabilities invalid' because of

inconsistent data. The expected :onfizuration of tne

allocation of main memory during data base query operatiors

is shown in figure 17.

88

MEMOR C ALL CAT I ON

Operating Data baseSystemQury File

10 K 14 K

WorkingaSpace

2LA K

Seg:mente nterfaceProcedure Module

10 K 12 K

Figure 17. Main Memory lap For Data Base Queries.

While each of tne above alternatives supports the

loeical desien of the data base, the third alternative is

tne fastest and was selected because of tne user's need forti.mely access to tne data base informatio.. Tne expensive

trade-off in added complexit and redundancy is made in

favor of tne user.

4 . Inverted File Design Considerations

An inversion on tme secondary Ireys would allow tne

system to conduct mulziple-tey Drocessinz of" queries. Earn

of tne secondary keys woula nave a separate inverted file

for each of the values of tneir domain. Tfle index would

contain tne actual pointer to tne appropriate record in tne

data base query file. An example of' an inverted file for tfle

target prioritf attribute is saown in figure 18.

189

ITarget Priority Index

_I1 3 7 14

4l 16 10 8 14-1 13 6 r 17TI

IV12 is

Fieure i. Example of in Inverted File Lozical Structure.

The implementation of tne inverted files could employ a

linKed list of tne target location pointers Dy specific

domain of the attribute. However, this file must be updated

eact time the user adds or deletes a target from tae system

as well as maKes a specific cnanee which will arfet tte

index. For example, a priority I target could be cnan -ed to

a priority IT target after sucCessful attao' by supportine

arms. Tais would necessitate a cnange in tne main target

file, tne data base query file an. tne inverted index for

taret priority (both for priority I and IV) as well as in

input for tae transaction log of tae TARBJL.

This disadvantace combined witi thie complexity of

implementing linzed lists, maintaining multiple inverted

index files and the overhead involved detracts sirnificantly

from tne elegance of using inverted files. A simple,

practical and straicht-forward solution is required.

'90

6. Flat File Array Processing

The data base query file is implementel ab a sinle

dimension array of records so tnat it can be loadea into

main memory. The UCSD Pascal system performs effertive array

processing and tnis feature can be used to perform tne data

base query functions. The method selected for the tarret

information system is array processing of tne flat fi.e.

The Query module prompts the user to select the snecial

criteria for tne target listing. It does tnis by presenting

the user a series of menus from which the secondary Keys and

tneir respective domain attributes can te selected. Once the

attribute is selected, the module processes the array to

determine if the targets in tne array possess this

attribute. Eaca target with tne attribute is flagged and tne

system returns to tne menus for further Key selection. A

domain can be selected only once per list. Tnus, tte system

permits only tne logical "ANDING" of one attribute of tne

domains of the secondary Keys.

Upon selection of another attribute, t.e bystem will

process only tae targets which were flagged oy the previcus

array processine. This will sioniztcantly reduce tne sear.-h

tine and result in increasingly greater refinement of tne

list for each subsequent part of the query. Since there are

only six secondary Keys, tne maximum query size is six items

although the user coull stop snort of that number at any

time in the processing. Wnen tne user stops tne 4uery and

- 91

requests the listing, tnose targets which are flagget are

accessed and written to tne console screen. Wnen tne next

query is initiated, all tne flags are reset.

Two additional desirn features nave been Incorporated to

speed tne array processing. The first feature is tne storage

characteristics of the secondary iceys in the record. Eacft is

stored as a single cnaracter requiring no type conversion

thus, enabling quick ann easy comparisons. The second

feature is in the desiRn of tne query menus.

The menus nave been arranged so tnat tne Most

discriminating indices are presented to the user first.

Tarzet type has a domain of nine values and is presented

first to tne user. Tnus, tne first pass at tne target list

will probably result in tre smallest list of flagged

tareets. This reduces the amount of array processine for tne

remaining portions of the query. For example, if tne system

has 100 tarrets and 92 of tnese are "active" status and 14

are of type tani , tnen the first pass in either case will

be for all 1eO tareets. If status was the first part of the

query tnen the next search would be through 82 active

tarrets until the "tang" tareets were found. However, it

type was the first part of the query, only 14 recoras of

type tanic would nave to be searched to find the active

targets. The first search processed 182 targets, the secon- ,

usine the least-list principle, processed only 114 tarrets.

92

The ptysical design of the data base query file Is snowr.

In fizure 19.

QUERY IrEMS TEXT

FT C SA P A S Tgt no Alt Dec ri

F...~~ .Fa ... .PriorityT....Type A....AccuracyC... .Class S .... .Status

SA...Supporting Arm

Figure 19. Data Base Query File Pnysical Design.

5. Data Base Partitioning

In addition to ttie main target file and tte data

base query file addressed above, tne functions of tfle 5ystarn

require additional file considerations. In particular, tnere

is the requirement to produce a TARBUL onen requested by zt2e

TIO. The system must retain in d separate file, aii tne

Information that Is appropriate for tne TARBUL. Typically,

this Information consists of targets added to or deleted

f rom the tareet list, cfanzes to tarwets on tfle targ-et list

and sirnificant BD& on attackced targets. The Target module

or the applications proeram extracts and formats tfle

appropriate Information for tne TARBUL file In conjunction

with normal processinR.

93

A securitT feature of tne system is a user aefined

Dassword which allows entry into thie program only when t e

proper passoord nas been received. In order to provide for

tne retention of passwords between uses of tne system, a

small file was constructed wnicn contained tne user

password. A procedure of the system allows this password to

be written to the diskette and retrieved ahen tne system is

activated.

There is a requirement to provide tne user witn i file

status report on a periodic basis. It is essentially a

statistical breakdown giving the number of active targets,

inactive targets and targets on tne target list as well as a

count of the targets in eacn attribute by domain. A separate

file could be kept for tnis information, but to decrease

complexity ana storage requirements for tte system, a

routine from tne Utility module is used to accumulate

statistics from the data base query file and display tae

information to tne CRT screen wnen reauested by the u er.

Once again, having tne data base query file in mair, -i eory

will reduce the -omputation time needed for this process.

The data base is, thus, partitioned into two daa tase

files (one a suoset of the other) and two utility files, the

T&RBUL file and the password file. They must snare secondary

storaze space with routines of the operatine system and the

applications program object code. Tne partitioning of tne

data base is depicted in fieure 2C.

f T04' ' ,T..

TARGET L : FILEFILE

DATA BASEQUERY PASSWORDFILE FILE

Fiqure 2Z. Data Base Partitionin.

D. OTHER CONSIDERATIONS

In considerine inverted files, it was determined that

some record attributes aid not yield a suff iciently

discriminatine index. For example, the data item status

yielded a poor index since only two values are possicle,

active and inactive. In an effort to establisn ore

discri'iinatory indices and at tne same time reduce tne

pnysical size of tne data items in a record, index itemT!s

were combined and compressed in a coded form. Tarpet 5tatus

was enlarged to encompass the target list index and tne

tareet attacKed index. The combinine of these three indices,

each witn aomains of value two, yields one index with a

valid domain of six values. The newly formed inder is as

f'llows:

95

AO-AID4 075 NAVAL POSTGRADUATE SCHOOL MONTEREY CA F/6 15/7MICROCOUTER SYSTEM FOR TARGET INFORMATION IN THE FIRE SUPPO--ETC(U)

JN 51 R J COtLTERUNCLASSIFIE.D NL2 IIIIIIIIIIIEI~llllllEEEEIIEEIIIIIIEEIIEIIEIIIIIII±

ACTIVE TARGET ON TAR"ETCODE TARGET TGT LIST? ATTACKED?

1 yes yes yes2 yes yes no3 yes no yes_ yes no no

5 no -- yes6 no -- no

The data dictionary, wnlcn w.s developed in response to

the volume analysis of tne data case record, addresses each

attribute separately by name, data type, phySical Size,

logical size and lists the domain waere appropriate.

Specifics about the tareet record and the query record are

listed as well as a determination of the pnysical record

size. All tne data in tae record Is in ASCII character

format; even Items sucn as tne grid location and altitude,

whqich1 are actually interer values, are stored as characters.

Conversion, wnen necessary, is performed tv tne applications

program.

E. SUMMAR!

The primary consideration in tne design of tne :ata pase

das ease of use and speed for tfe user in tne microcorputer

environment. This consideration overrides tne inefficiencies

or a dual data base record. Moreover, tne complexity of tre

processing requirements is invisible to tne user. He is

concerned only with fast retrieval of certain types ot

information. As tne casual user, ne Is not concerned wits

nl h level query lantuares and their use. Rather, he

96

requires a iacaiine tnat will serve nis needs and not tne

other way around.

E. F. Cod, in nis 174 article Seven Steps to

Rendezvous with the Casual User state thnat I is projeted

tnat, by tne turn of tne century, tne majority of' data tase

manawement systems will be oriented toward tre easiual user

A system wnicn will be able to pertorm its function quiCKLy,

easily and accurately durlne tne intensity of combat

operations will be tne one tnat is specifically desisnea to

conform to tne user's environment. Tnis system was iesigned

with this principle in mind.

The following cnapter describes the important

considerations of thne user interface and the methoaolory

employed in maKing tnis interface an effective one. It

considers the psycholoeical issues wnicn affect tre

man-macnine interface as well as the modes of' user input and

computer initiated dialogue. These are tne tecnniques waicn

enable tne target information system to conrorm to tne

user s environment.

71. INE.ACIIVT INTEiFAC DiSIN

A. GENERAL

One of tne major iesiza teatures ot' ne tareet

information system is tnat it proville a trienaly yet

sapaisticate:1 user interface. It snoul. oe sufficiently

sconisticated to perform all of tne reuuirea functions

simply and efficiently witn only a mrnimum of interaction

from tne user. The environment must be a trrienly one,

allowing tne user to recover gracefully ani witn mininur"

effort from error, ruiline tne correct input and1 providine

tne user witn assistance or information wnen needed.

Tbe user is a Marine, trained in tne conduct of

supporting arms operations in a comoat environment. He is a

parametric user, a cisual operator of a corputina macnine.

witn no computer trainine ana a limited capac-liity nf

operatine a computer. Tne system must De buiticientiy bi'pie

for tanis user to learn to operate it effectively in a

minimum of time and witn a minimum of effort. It must

Inspire nis conflaence, simplify nis tasj, increase nis

effectiveness, reduce or eliminate any computer anxiety

and, most importantly, enable qim to accurately ana QuiCKly

carry out nis mission.

This chapter outlines tie desien criteria and tecnniaues

used in determining tne quality of tne man-macnine

9 t

interfice. Tnese criteria were eTployeq in tne desien or tne

applications propram ar constitute its rasic -rd.iewors. The

'ysten" etivenes , -an only ce meaibre.1 Dy now wel± tne

interface Detween tae man ana tne macnine nas succeeaea.

Jaires Martin, in nis Design of 'an-Computer Dialogue

descriced the psycnoiogicai impact of tne interactive

interface en tae user as follows:

It adas become incredsiniy realizea that manyInformation processing operations are best carriei outnot by machine alone, nor oy imn alone, but ty ajudicious comoination of man and macnine... A Key tosuccess in many real time operations lies in tn-recognition of machine limitation and tne oul.iaine intotne system of appropriate numan capacilities.

B. DESIGN PRINCIPLES

Tnere are four oasic principles used in tne caesien o'

tne user interface. First, it must De self-eydlanatcry. The

user must be able to ube tae system witnout reverence to -n

external source. This implies taat tne system guice an!

direct tte user in te execution or flis tabc rezardles5 o.'

nis level of expertise. This requires simplicity, ease of

use, and elimination of system railure. Second, tne system

must be self-nelping. Whenever tne user wants or reouires

flelp or assistance, tne system ru)t responi. It bnouia

tlentify tne improper input, guide tne user to tne urcper

input requirel and provide an example of' tne :!crrect input

wren appropriate. Accorlingly, arror messages must re

explanatory anI the system must respond to every input.

99

Tne tnira principle is a requirement :or a simple

interface wita tne user. The system must respona in a tireiy

fashion to input wnicn is snort, simple an obvious to trne

user. The processing complexity must be invisiole to tne

user for every procedure or tne system. Tney snoul all

appear to be a straignt-forwart ant simple tast.

Tne fourth principle, previously mentionel in CnaDter

III, is interaction by anticipation, tnat is, anticipating

tne desires ot tne user and preseraine nim witn a

corresponding list of options. THUs, tne system can avoid

tne problems of employine error aiarnostic and advisory

messages. 3nln tnose actions tnat are leRitimate are

presented for user selection. Input or any of tne lispiayea

actions will result in a syntactically correct commana ann

allows furtner processing. Input of an action otner tnan tne

legitimate one resuits in a simple user aavisory ressace ana

onviatps tne n~ed ior elaborate diarnosti-s. Tne rost -omimor

type of dialogue tnat uses interaction Dy anticipation is

renu selection and to a lesser legree, form tiling. ' enu

selection allows tae user to select tne iesirea option

ratner tnan requiring nim to specify tnat option.

C. PSYCHOLOGICAL ISSUES

1. Snort-Term Memory Consiaerations

Our saort-terrr memory aolds interpreted units of

information for up to 5 seconas oefore it fades away. Witn

zontinuet exposure to tne sare type of izf ormaticn,

snort-term -iemory retentioa cdn -e improves out essentialiv,

we are able to retain only a lifmited amount ot informaticn

at one tine. 'eorge Miller's classic paper in 19td. Tne

Magical Number Seven--Plus or I.irut Two, descroel

experiments wnlcn sueeste! that tne snort-term memory was

linited to a perception of -oout seven units. For terminai

interaction, tnis implies tnat tre processing capacity of an

individual is limitel to only a few items and tnat it should

be taien into consiaeration when designing menu formats.

They snoull be simple, semantically meanineful, arranged in

a logical progression (to tne user...not tne programmer) and

brief.

2. Closure

Tnere is great psycnological relief to snort-ter

memory wnen information no longer needs to oe retained. This

produces a powerfui desire to complete a tas witnin tne

snort-term Temory span, reluce tne memory ioal and rain t"e

psycnological relief . CLosure is tne ccmpletion of a tasic

leadine to this relief. The user expects to exoerien-e

closurP after completirg an activitv. Anydelay in acaieving

closure or the interruption of this process is frustratine.

The pressure for closure implies tnat tne user

(particularly, the novice or parametric user) will prefer

multiple small operations ratner tnan one large, complex

one. In system desiRn, this surrests tnat intera'-tions re

ae:inei in sections or iogical serments so tnat COr",letion

cin ve ottainel ani information released. All actions cf tne

user snoula be responded to in a positive manner oy tne

system.

3. User Anxiety

The user attitude toward tne computer can impact

upon nis learnine ana perrormance witn tne sys5tem. Cor-uter

anxiety, generatea oy fear of failure, may reduce tne

user's snort-trem memory capacity and innicit nib

performance. The system snoula put the user at ease out

witrout Deine patronizine, obvious or cute. Tne user will

respond better if tne instructions are clear, iinab ieuous,

expressed in familiar terms and easy to follow. Constructive

advisory messages ana positive reinforceent are prefere! to

tnreatenin_, condemnlne or meanineless error iesazes.

Please reenter your cnoice is more user friendly, less

intimidatine and more effective tnan 1al entry-error 21

Tne target information system nas been .esigred to provide a

-omfortable, nelpful and rriendly environrent.

4. Control

A Iriving fcrce in numan nature is tne aesire tc

control. In using computers, tne novice is pertectly willing

to follow tie computer's instructions ana accept tne

computer as the controlling arent in tne interaction. As nis

level of experience increases, tae user may resent tie

computer's aominance and may looK at tne computer only as a

t oo. Tn'us tne ystem snouia ne aesiene(1 to ernance tne

user control or at ieast tne appearance cf user ccrtroi.

Properly rormattea 'ieau , acavi so ry -iei sages ana error

m.iagnostics can give tae user tne impression tnat ne is ir

complete control of tne situation. T.e menu allows ni- to

mare decisions on input parameters as weii as selectin;

tii':'erent tunctions.

D. .ktSCNSS TI:09

A simple ±imit or. response time, tae time it taxes 'olr

tne system to respond to a com ana, is desirable -or

e:fective man-macnine inter'ace. An acceptdole response th~e

is a funrtion ol tne type of or.man a an t.ne user's

expectatiZn of wnat a reasonable response time is. For some

operations, ne is content to let tne macniae Trun-n away tut

for otners, ne expects an nlnmealate response. Tne timeiiness

ot' response to tarzet information queries was tne pri.Tary

factor for tne design of tne auual cata nase.

In normal conversation, tne user's expectancy o! a

response is witnin aoout two seconds. A LdcK o' response

witnin four seconds would be an unr.aturai Dreai in tne

conversation. In stuales of man-macnine Interface. a

response witnin two seconds nas been slown to constitute in

iportant anc reasonable bounadry in tne ef'f'ectiveness of'

feedDacc. Errors must be responaea to within two tc fcur

seconds so tnat tne closure oerioa is rorcea at tne

1. kX

appropriate time. iaie Sys tem1 initalizatior a Y ce

IcceptabJle to t n - user w t::ir ." 5eoa . e expetS5 to

access tne next menu or to receive input nIE~p aicsL

instantly. 4nen tie aeiiy is expectaa to exceel tne two

secona parameter, tne systemn snoula ac~rnowieage tne conrnanL

ani Inatcate tnat proz:essinz is underway (ant perloai 7aiiy

reinforce tais untni tne process is compiete,,. Tais ensures

tna t tne user &nows iis, ccmnmanl qias teen acr eptel ana tne

mnacaine is processing tne request ratner tnan. otservinz a

Dianic screen and wonlering wnat to to next.

i.INPUJT !MODES

1. M ote Selection

A.Monr tne dlitr ereaL types of interactive liaiozues

consitered, computer initiated, to rm i i i1n o a me,",u

selection were aetermined! to oe tae most appropriate for tn-e

F o~~a ram e tr I user ant tft e !3p e II'! T application of tareet

Information. A combination of tnese taree metnots proviaes

f lexi ii ty, ease of use, _-imo.icity and. coverh a com'plete

range of tne system lunctions.

0 '76The computer initiatea diaiogue, '#inere tne user responis

to tne co-nputer, nas tne aavdfltdge or- requiring very iittie

training for tae user to operate tn-e sy,,stem. However, zne

dialogue can oe ratner lene-tny, tae systen! can te ratner

slow to respond ant tnere Is a loss of fleIxility in tne

sequence of tfte l.iaioeue. 'Athe form filiine tecflnique, wnere

10:

tne user f±lls out tor m on a visual aisplay aevice, is

straiznt fcwrd ±'or tne operator in tnat a1 re needs to ao

is provide tne appropriate in'ornation. Error aiaenosis must

be imediate to be effective anc. cursor manipulatien Tust re

considered.

Menu selection, where tne user seiects an appropriate

.esponse to a number of cnoices, reouireb litle or no user

trainine ana nas tne aavantage taat tne user may oe in:ormea

about tne full range of tae system features. A simzie exi t

from tne menu sequence and tae opportunity to return to

previous menus enables tne user to achieve flexicility to

navigate tnrougn tne system. Tae ±imitea numoer of cnoices

on any particular frame and tne information about tne

sequence of frames wcicn leads to tne current one proviae a

narrow context witnin waicn it is easy to aesign effective

user aids and error ressaees.

Menu selection is a form o' computer initiated diaiogue

since it is asrine cne user a question and DroviniI~e a

limited set of valid answers. Tne user determines Dne

appropriate input and the system respon. witn tne answer or

anotner menu. Tnis contributes to tae ease of use o: tne

system and tne untrained user can tDeccme proricient in a

very snort time. Tae tecnnique does run tne risx of± oei:e

too slow and tedious out it can be speeded up by a nivn

speed terminal and i!it access to menus. Fieure -, is an

example of a menu from tne target information system.

L1 -*b

Appendix B -ontains a Tore Ietaiied exirnpie o: tne type 0!

interactive interf'aue tnat tne user oi tne s.sttrn wouia usee.

It snows tne menus and tne iavisory !-essa-es tnaL tne user

,ouid encounter wnLe usinR tne uer:r moaule to Per:orm

target queries on tae aata Odse query ±iie.

ENTER TARGET PRIORITY*.... ... . .. . . . . . . . . . . . . . .

The options are:

1. 11,;. II1

5. Return to Previous -enu

PLEASE ENTER OPTION NUMBER AND PRESS RETURN

Figure 21. Example ot a "enu.

2. Menu/Form Fiiline Formattinz

Tne computer initiated dialogue will always require

an action from tne user. The options presented to tne user

cenerailly include continulnr processine, exitin, ottainirn

nelp and acnieving closure. Even improper input will De

responded to in an effective, immediate manner. Desien of"

tne formats for the dialogue will ensure that tne range of

options provided to tne user will meet tnese prerequisites.

1 'us6

Tne Tanner in wnlcn tne aata Is formatted can affect tne

efficiency of tfe operator by influencing botr nls Sped and

nis error rate. A poorly formatted dialovLe can -ause

bewilaerment, anxiety ani Improper iaput. James Martin 1r

nis book, Design of "in-Comout-r Dialogue. lists toelve

rriteria for tne design of menu an form filling screen

formats. These criteria were used in tne d si a n

impiementation or th~e target infirmatlon system:

1. Display a Straii amount of infor-nation it one tire

2. Do not incluie unwante,/unneeded information

6. Have one idea per display

1. The operator response should be sncrt

5. The computer snoula always respcnd to tne operatcr

5. Use formats desioned for clarity

7. Strive for similarity \position, formiat, terms)

n. Avoid difficult words or cnaracters

9. Provide an easy means for correction

10. 'ake instructicns to tne operatcr stand ou t

11. Clean up tfne screen when possibl

12. "a.ce it easy for the operator to ask for nelp

S. E. Enle and R. E. Grana it. tneir .or, Guielirns

for Man/Display Interface, 7ention many lifferert anf. useful

teonniques for improvizn tne interactive dialoeup ,nd tn=

user input. Some of the more important oiats u.ed :r the

desian o: tfe taroet infcrmation systrr are parapnased in

127

tne foliowing list:

Avoia abtreoiations dal contracticns

.3e consistent in use aia meinina or tecnz-al w*crls

Use examples to suppienen: :nstructions

Be consistent in preseztlan identical/similar data

,se numbers wnen llstln7 selectatle items

Place most prooacLe items at tno top 7f tne Tezu

Standardize screen or2anization and rorrat

Give user lirections before tne list of cznoles

User input snoul1 be Cept to a minimur

Present data in a recoenizatle order

Avoid verbosity ana wordiness

F. ERROR HANDLING

Well designed aiagnostics and error messazes can gt:ie

the user to enter tne correct ccmmands. Jtern the system,

pronpts tne user tnat an error nas occurea, It snould ailw

for error correction ileaiately. in tte renu selection

dialoeues, tne range of options is predetermined r'r tne

system and only a valid input will result in tne apprcpriate

closure. Invalid inputs can be .easily deterrrine! an1

appropriate guidance provided to the user in t-e error

messace to obtain the proper input.

Form filling d1alogue can cnecz the field lentn ana

field type (for example, d grid location woull cnslst rf

eient numbers ana any otner input would be invalid). Error

1011IZ8 I

,essages must inlicate tne nature cf t.e errcr ana now tc

reover frcr" the error -in en appropriat *. re sys.e- snc,_:l

respond witn an example of tae proper input. Figure 22 belcw

is an example o f an error mes ace frorr "ne arget

information sys tem,:

ENTER TARGET NUMBER

The proper for-nat for a target rumcerconsists of 2 letters followed by4: numbers, for ezample, AA9Z57.Please reenter your daa.

ENTER rARGET NUMBER

Fieure 22. Example of an Error ' essize.

'1 & central problem in analinz errors is :n proviIr,! :ne

user witn tne ri t ind of inforration. Even exnerierc-=.

users occassionally re4ulre assistance in some portion cf

tne system. Accordinely, a user nelp fun-tion has teen

desizned to complement the dialogue and provide tne user

with additional detailed but concibe Inforration on te

appropriate input. In soome cases, tnis function is til:

rient into the ranRe of options of the renu, hiowever, at .

time the user can receive neip or more information V s1m!vy

109

typing a ?. Wnen tae systsim is niot su'UIcien*1Y

5b21f-exDlinatory. it is deiz1~ed t~ 0 e 6elt-rne1pn 4'. t

appropriate and -,ean~i gf ul ins t ructi ons ai vi sz me s scigE

an:i error 7essazes.

.A.P I!TE I?. NA TI U PH GAN

Bised on tli desi ?n criterii olitlne! i: napt-rb A.

a 71 , tne targe t .nf orma tior sys tem. Id3 a , (

df tested. Eact m!oaule was codei inceenuiently o!, tne ctner

a: tested i its own envircnment. Siar t ntI?

interface *a5 Taintained between eacr 7cdule an 71' aI tr.

f ir st part otf eaca ,C4Uie Co~fed. After tne irterface was In

:).ace andi oorring, tfle module was f."led out to perforr~ r e

sys tei functions. After eacn ,nodvie was testedt an-, d~etlu-ee

independently, it was in.-orporated into tft syst2- *n?

additional testing anA tiebugei.ng t,-os Llace. Tne rect rjoiiuie

was tnien co~ie! after tnie syste- ias ±unnticning proe"iy.

The Interface moaule i.s t.e 9main s -rst em' pr gra n 4

contains tae giotal aataL structures an: tne syst-rn r~.':t

routines sucn as c'earine tne screen, s5i>ping ileb. a,-

pr in t in error mes sa g It Mlaks 5a ca.Ls to tn n

Drocedures from a rdbter nenu. Anotaer prl.mary -i c t 1n c f

tnis nmod ule i s to nuiia tap aairess mrt c:, tne recoras -t

tne start of" eaca siessioa and to cden tne system .4ata f14'41,.

Tt is Tio Cule coipied t o 6100 oyties cf o ,'c t c oae ancn .

four KC less tn-an oripirally expected.

Tn e first of' tne segment routines is tne Ifor-, rccuie.

T nis molule contains Sys te-) operatine I ns ruc I o,

1octrinal eDilanations of target i nfarmato.n ter-s, wret

analysis uiielifles, sp'urlty re4uirem.p.'ts a. ex;-p.1es cf

o fora ts ubel ia tae syster. It 41 asi:aliy all text aI

serves to inform tne user of tft.e cipaoilities of tne systen.

Tne moiule compiie.S to 17,'Z; bytes of object coie.

The initialize module s Iesignei to erase tne ciurrent

data files and completely reirli :ilize tne s,.st?-. I:

performs no otner function for tre system. it 4uilis tne

data riles to trhe reauired size and fills t.e 'ile with

erpty records. It compiles to 2500 bytes of ooject cole.

The third seemeat procedure is tne Targ et rrCoule. I"

contains suo-modules for aadinz a tar-et, deleting a target,

ctantin current tareet information, lisplayinz a target arA

allin g a BDA to tne target recor.. Yajor dif fic:ltles were

encountered in loadine tni: very laree rmolule and its

involved user interface into iain memory witn tae operati:n

system code and tfne sybtem Interftae moaule. 1::1al

compilation of tne moaule was to 35,40Z tytes. Tne ain

Droblem was tne arrount of text that tnle user interface wes

consuTling. One screen frame of user inforrlDalon "acvi srles,

explanations, et:.) usually tooK 1zX' bytes of otject Cole.

Tne expense of so mucn text in the code was mucn too reat

for this nodule.

Conseouently, a decision was made to reduce tr.e size of

tne module byr putting most of tne text in separate text

files on the diskette and retrievinz these -i fo ror,

112

secondarstroe wt caiiea ,v tne cor::. Tn:: Dri u CE:.

message on tn1e screen (autacu,;I tne user nouia not reac as

last as tqe output'" and secoca, tne A-4sicette now corntainel

nunerous text flies in addit~cn to tae coc~e ani data fiir-s

snown in flpure 7.

Since tae Pascal systam usea four tlic45 of 512 oytes

eiazft for a text f'ile no matter nlow sm~all thle file was ,

54 text files tOOtf approximiately 110 K bytes if seconcaryv

storaee. This caused tte system to erploy tne seconrd A LT -wS

disik drive, waicn nad not teen used zreviouslv. Trne

resultant reconfizuratioro of Vie seconiary storaec

allocation Is snow: in tigure '23. Certain menus and

recurrine -nessaees were retainel in tne tart modul= to

speed tne processing and decrease user wait tlie.

Tne use ct tne text files and tne reorearnlzition ci* tn'e

BDI routine into a separate segment procedure (ca.lec: tv tne

Target segment procedure), r e duc ed temul to 1.''

bytes of' otject coae (19,3vZ cytes wrer. t-e B-A -;r~cecLre 11s

called). Tais provea a satisffactory soiution witnout a

sienificant design cnar.ge. Tne direct access capatilit-f If

tne Pascal system provel b-otn accurate an, fast oitn' nc

apparent wait in tne process time tetween d reQiuebt :'r a

A record and a reply to tie CRT.

113

Query Til15 K l?

Tarbul Fi I :

Passe orl se

J.i rectory

Pr o iram xt j e,: CotIeF

72 'K

Di re- tory

P-Ascal O/S

iu r c e3. A-'tUal Se-oniiry Storize Ubee

114

T.e last module irdlementel was tne Cuery oliule. It

emplovea soie of the Tenu text files usea by tne Tirest

moiule, thus le~rcasinR its code size. and provel Pa1ier to

implement tnan expected. Waile tne Querr selection is

Iimited to the loeical ANDING" of elements of tne loniins

of tne recora, the array Drocessine proved to te very ripid

and well oitnin tne two second time response paramEtzrs.

Loadinz of tne data wase query file was 5tralont forwara and

cnanges in tie main record, perfor-ed in tte target Todu1e,

were being correctly reflectea in the data tase query file.

Wnile initial evaluation of tte ,oaule proved satisfactory.

it is felt that system improvement could oe ootainec ty

designing an interface and an algoritnm whiCv. allowed botS

logical "AN1lING" and "ORIN " of attritutes. Tnis se.rne t

procedure compiles to E200 oytes of otject cor9.

The final seement procedure. tne Utility rroaule, nas not

veen completely implemente d due to programming tie

constraints. Eowever, tfe complete user interfa-e is In

place and operational and gives tae user tae i7pr ssion t-at

tne system is operatine. Tne erase file runction is

operational and wor:s effectively. Th.e follcwing functions

nave not oeen implemented: cnaneine the passwort krequires

esian of the password recora as well as implementation),

copyinr tfte data base query and tareet files to a Oac-&up

alsiette, operations on tne TARBUL--aisplayinor, renumberine,

Drintine and reinitiatina (tnis also requires iesipn of tne

115

V ...... ".. .... ... . ..."" "

TARBUI recora), printing tareet cards and lists ar., trle

-c'putation ind display o t a le file statisti -. Te

current size of tne mocule is 1:,3Z( cvtes. As ±unctions are

mined and tr.e size increises, much of tne user interfice can,

be transfered to text files to iceeD tne size of tne Toauie

at an acceptable level.

The entire proerar compiles to 72 K of ocject coae, fio

of wnicn is contained in segment procedures. T'.e syste

source code, wnicn is c3ntainem in Lne Naval Pottrad.iate

Scaool tecanical report entitled A Prototype Prcgr-m for

Target Information (NP52-E1-07). is over 52Ox: lines ionz.

Iritial testing and implementation was dore with a target

list size o? 100 tareets and later expanded to tre required

400 target Taximum. It has been debuggea for execution and

tested for operational accuracy. dnile initial resuit- are

very satisfying and tne system proves fast ana accurate,

extensive testine to include field. testine would te rpuuirea

before tne system could tecome operational. Adaitionelly,

tne Utility module would ftave to oe completed.

Tnere are two main conzerns in testinO7 tne syste".

First, that it meets the requi rem-en ts of t'e target

information section and effectively accomplisnes its

purpose.. .tae autor.a tion of tne target inform aticn

functions, and second, tnat tne user Interface is as

effective as it proports to te. Tnis will require extensivre

testine ana valildation as well as operational testine and

1165

evaluation in appropriate tactical commana post exercises

wnich employ the division or tne MAB fire support

coordination center.

B. TECHNICL CONSIDERATIONS

The Pascal prcgrar listed in tne tecnnical report is

transportable to otner UCSD Pascal systems at. wi n

modification frandom access, segment procedures, stri:is5 t

any Pascal system. Certain aspects of tne prcora.m were

iplemented to conform to tne Datamedia Elite 25CO viaeo

ter'inal. This terminal nas EO characters per line with 24

lines of display with full upper and lower case ASCII

operating at a data rate of 9bOO baud. It has a 1R20

cnaracter screen capacity, an alpnanumeric Ireytoara and

display arid botn synchronous ana asynchironous interface.

Some of tne =pecial cnaracters used in the proeram include:

ASCII Decimal Func'tion

so14 blink field onCAN 24 olin field c-oBEL 7 bell/oeeperIs 29 roll fielc onUS 31 clear screen

It is reco~nized that the desizn and i-plementation is

tased on tne ALTCS ACS 3 -1 co"puer. Advances in

microcomputer tectnolopy will invariably rodif'y te

environ-ient for waicn tne prototype was desivned. The

addition of' nard disi& capabilities to rmriocor-puter syste-5

117

wiil increase tne secontary storage sp~ace as weii as trne

processing speed now availatio witn. flop;;y iis~xettes.

current svstell can Cartar._'y function effectively-I in sucz a

new environmnt but tn'e possloi.L~ties of redlesi. n srcould 1.e

considiered If tfle i crease in eficiew-y is warranted an4.

tne timne span between a new inlementattin ar tne

Introducti on of '!IFASS is suf f ciently I0-4.

Since trne UCSD ?ascai is avaliatle 3n so mary system

witri tne proper setup routines tie syster J.5 suff~riently

portable proviied tr.e 5econiary storaze :apatility i5

dVaAiatle. Tnae source c o e is compuila=tle Or personal

comiputers sucn as tne Ap. le 11 wt.en tfte Pascal systeT card

is included w! tn a 54. K ~e mo rv altnougn t ..e si ze o f

secondary s to rage (tne Apple uses a 5 1/4 !ncn mI-t'lc;ty

dis~ette) will dictate a reali~net of files and a f2_rr.er

partitionirg of system software.

C. TACTICAL CONSIDERATIONS

Tn er e are a numter of ccnsiaerations wp~ict Involve tai

tactical andi operatioral aspe,7ts of' tarzet inforrration

bear consideration bu wrii are tey'onc: tre scope 0of ,2 is

tnesis. Tte first of tnese is tne surviva~tlity of tn-.s ALT 'S

and. related equipment in tne field. Special nanq,4,7 arnd

care Is required of eacn Item as well as tne systen ani

target disirettes. Specific instriuctions for tne user in .ae

maintpnance and nandling of tne system m ustIL be aeterrinea

anr. I romulp-ated to0 t e 11S e. A iclito naI 1v, c'r

re 4 uire-nects and tne resultant equ~pient o ai fIC iti t 13

.jus tments needed to opera te in a f'Iold e lvir!nrroflt -1.5 t e

:onsi±e red.

Tn e acouisltiol an!. use of tris eq4ulpment rna:y te cause

to examine trie tabies o. oran~zatjon to aetercr-Ine tne

proper staffing of tne t a reet in±'zr7ation se.-Icr !:rc a

reduction of personnel seerns ratn.er z s y to acnizve.

Allitionally, a re t no d of transfering! data frrt:e Navy

ASIS computer to tas system -nicroccrfluuter sn.ouit te

investizate. and a.dressed since :rarsferifle t~'e data

electroniCally' betieefl tae two sys temS i s prefferatIe t

.ranually tran5ferifz ;ne lata into tne ri:rocorrputer syste'.

Concept of emnploym-ent of the sy'stem, aboard snipD kin SAU'Z or

iI 1and i aL f orce spa,:es T u -st i 5c te !e zer7:il n-rdaI

pronulgat ea.

Once a,.'o p tet a na func t Ion al , i cg ra nie n)iins mus t tr

ie te rilined f or a t .ans Ititon a ro -n t ie sy s tem t o t -.e FIAS S

systemi. Thiese, of course, are lo.',ally pen~razte! reatuirpren-s

and can te addressed In tne future. It is antli~atei .nte

>IIFASS will require extensive cperitor t r a i necr 1 n

becomes operational wnereas tne microcomputer p~otot-!rpe

systemn reouires only user familiarizationl. It s s: i Ta t i.

tnat tne user can become proficient witfl tflis system after a

one tour familiarization period.

Tne reaire!enL5 ior Taln.tainj.n a Lrair.n.'aJ cis± t o

tarzets, walie currentiy soivacie dit.n com;uter ~alC

w i I continue t~ 3 .e ac -oo 1 isi ed *y tnp_ ubs2 c* ta--i-21

c at t Ie ap s covered witn acetate ov e r.1a:! arerE 1 tr:

situation dlictdtes. Tais systei nakces no atteTpt ic a:: ress

tfle erapic iz~ splay of tar?et5. It is f'elt trit t~'e :s2.

capabilities ct tae 'PFASS syste- wii1 e 1u I suis'y

tne requirfaments wflen tne systen is introili-el in tc F.,

fleet.

D. STSTE1 REFINZE1NTS

'mile tne system meets all tne re~uirement,, lientlfiea

f cr trie target inf ormation section, tnere are a r U -1.er o f

refinements to tne program wnicn. couict te inpiaeretec in a

later version of tie prototype wn,,cn would e~tanlce ta:-

system, performanlce and provtide ad.~itiorna i anailities to

tne TIO. Trnese include tne foillowiniz:L1. ExpandiflR tne size o±f tn e tir--t file teyon- tt.e

Current 30 tareet maximum it' tne tactizal :3ons'derat1Cns

of future battle scenarios dictate.

2. Lortcai OhRING" a n 1 AN rI N G f record a::u

domans1i tne uery mciule to proviie a :rorc r=2.rel

selectivity of tne special target ilsts.

3. Inclusion of a uti.lity routine in tne query -cduie tc

print tr-e tarzet list ottained as a result of tfle qiery.

';-. .IIcw "e user to specify 'itu-e et, yinc .r

-eters andi nav!? tne s5teT !ca--rt tne l-at3 tc -f-.ters.

5. Find tne nunber and aesignatil'ns of tar!ets wit --

certain ralius or Ii5stance ot' another t arzet ("cor za,1

a class ' tar.et) or a vno n ,rld ref ern.ce poIn t

5. Provide a routine for _in- :raclc Of the neyt

available target nurmrer fron tne FSCO DiocC ft" rtargt

nurbers.

7. "odi fl cat ion of tae S SD Pa sca o;erat i=n s'; t e

conmand prompt to allow t..e user oily cre Ci o:

option, I. e., to run tne system .roe-ram and tne

filer subroutine 'ro-r ris environ7ent.

:. Plotting of artillery firinz an!ts arA naval n'fn. r-e

suport statior.s t o determine automratically, w nic, tar ets

are witnin tne effective ra,e )f specific s.~p orU:2

a rs.

9. Reduction ox 'odlnz ty ir.roveI aleorir-, and

sutroutines.

i . Provide operator trai-ine ail yster r..:-_.

1nanuals for tne system.

121

.

'TIII CQ;NCLJSln'%S AND CO:Ar.X

A A. ONCL'S I ON

-ffesctiveness of* ttle fre su;:ort cocrainatio. c:tr 4CU-1-1

re inri vea . y L~ae ~Uotir 0f 'n- n01 L- t d Lsa :'I~at ~

fun.-ticn. Furtac:z, it appears tnat t:ie j-se ' :

i.-rlemnentati on of a suita tie a ef:e c -,ive s ys ,err

possie now, five full years before tne 1: rozurtlor. oft tae

,1IFASS coi'nuter system into tne Fleet Marine Forcez.

Tfte tnesis aas presentem. one suca, design us _4n~g aIA

base approac-'I on a typic3lly -onieured, -o7rrer-illy

availla tie ',iicrocomputer wi tn a user irter'ace s;cit'ical--t

desioned f or tne >Xerine per! or!Ti.: tte tareet infvormation

functions in an operational envlronmient. N n e v a I-;at z. o f

t.ne i rrpl eme n t e prototype 'AIzrocomputer Sy t' o. Tr-et

Informiation (mISTI) nas aeterm'ined tnat tria rec;uir~eets ar.;

speA6itications for tPte system as iescrinea irn 1it:s

and I II nave been re t and tnat tr. r em a'IOrer~tcs

effectively anl efficiently.

Tne basic soundlness of tne iesien is reie~e ~a ~ct

t',e operatiocal ef'±ect~veness of tae prototyp;e izn tn.e laci

of si.qniricant cnanzes or m-oIiiications neeId'i to Tnet tr.e

stated system. reqUirements. 'ne wor-71ig prctotyp=e, .f

e"u1oyert in an FSCC in it : o'reSa't SZta te' O, -oi ~e f! a Le ly

in~crease tr.e o~erati6onai effectiven2-s o±. tne tdr:.:e,

-. RECO% iNEAN CNS

Tno vcesign ant. imrplernenta tion nas reen snocr. to be sc,.nl

arni, based on tne overved effectiveness of' t i jr Ct1 0ty P

pro-ram , tne f o iiowing recn-rrEn.at 1 ons are mace:

I. Tnat tle impierr-rtation. of tt~e protot.yrz 7roo-ut-

Syste r for Target Inforn'ation (~STI 1 ce c o -,i n --,e~ a 1

accordiance oit.n tne lesion criteria ou~ii:=- P.ereir. an-I

tne system refinenents d2.scussed In cnazter ill.

~.Tna; tne resultant syster be .es-tea a r.! e v a i at ?d i t

seiectea Ma ri ne Corps co TITanI1" t 0 ae t Eriia e LtS

effectiveness in actual tactical operations.

3. ITnat tne Marine Corps adopt tne XIcrocomputer System

t'o r Ta r-e t I nf orma t ion (M IST I)c an jn ,e r i7 Ca Sis 5 !t 11

tne introluction of* tae v IFAS system.

*14. Ttat appropriate naziwar,7 anti softw'are op -Lrcvi:ea tc

tre tn-ree Marine rivision *ire )uDjor. oriai.-

centers in, order to employ tais syster .

o. T.a t tfle Marine Corps Tactical Sof t~hare D-)o r t

A ct iv ityv (YmCTSSA) eva llate tne YIcrocomputer Svster tor

Tarret Information (' ISTI) as a teb16t eI o~l fo r tone

software interface criteria of to.e target 1inforTr.ation

portion of' t!ne MIFASS system.

1 ?_3

AF FE N DI I A 0 ZA TA 1"1'CI1 N A Y

R~ecord.s: 2

Re,7or. Tar,

s t itus

~epea t i n# Rroups : PB"'A G s ! r, ve I Ia c, a ninc/type ro-ins, ~.veass~ss-

Deeree: 22

A~~~ ~~ tv t otesiviL:29 tes r esic r-- 32o

VAi.ue Set size: 151

necord: TarR=e t ;ery

Primraryv <.ey: target nLTIer

Retzievai !cey: target rumut-z

Repeatina? jroup,: nole

Ca rd IndIi ty:

Degree:

Attribute list: Tar!3at Racor anTr:- uz~ ,-~

Cretnu-icer 2 cnir, 4- Irt cz r AA I:-Zz9Y

IADesc ri ;ticn 4--i Cr C~ -1 Ca 1S~'~:nay,

Pe~iarc 4na r 1 car

F . 3

assi;vae 4, car ICar Al"11

'trriity Uni t 6 CII, I . 17arS

No.types rons10c I :, r 5.M21NY7

D-aae assessel 11. cnar 1. criar

Di-?ar reportel 11 niar na zr

iaatd~ea, d-?stroyea,

ur.nowl, unot'servped,

:Id I'd a Sa

>p re ere I 2z a n. cra-

Source of t4t 'r 20 on ar s ri

r ' " t co r i a e ntrn1

M~CtV~e t.1m~ 7 z ir .

73rret icurev cnua 1 Cr '-cssi

1 26

*1,-

APPENDIX B - EXAMPLE OF SYSTEM USER INTERFACE

This appendix illustrates tne menu selection format of

tne user interface explained in detail in tne preceedine

chapters. It simulates the user operating thqe query module

and formine a list of targets for a special listing. Tne

fire support coordinator nas asked tfne target information

officer for a list of tarrets whicn are to be considered in

the formulation of a flat suppression fire plan prior to tne

calline of close air support aircraft on an important

landing force target.

Essentially, the list must include all targets from the

followine cateories:

Type .............. SEAD targets

Classification....all classes

Priority .......... I

Status ............ active targets

Accuracy .......... all cateeories

Supporting arm .... artillery

The example simulates the user interface of actual

system operation to complete tnis query as specifiel above.

Each pace represents a separate frame observed by the user

on tne CRT screen.

12?

SECIAL TARGET LISTINGS.............................................................................

The options are:

1. Form a special target listing2. Continue to process3. Write ttie special list to the screen4. Information atout tnls procedure5. Return to previous menu

PLEASE ENTER OPTION NUMBER

Tte user enters option 1

128

Categories for Special Listing

The listing can contain 6 Items from tne below menu:

1. Target type2. Classification3. Supporting arm assignet4. Priority5. Accuracy6. StatusP. Process Information

Special list currently contains 0 targets.Please start a new listine.

PLEASE ENTER OPTION NUMBER

User enters option 1 to select trle target type

.12

ENTER TARGET TYPE

The options are:

1. Tank2. SEAD tarwet3. Installation4. Counter Battery5. Observation Post6. Terrain7. Venicles8. Fortifications9. Miscellaneous

PLEASE ENTER OPTION NUMBER

User enters a 2 for tne SEAD targets

1.30

Categories for Special Listing... o ... ...oo.............. ........... o ** o*C o * ** ooo

Tie listing can contain 5 items from tne below menu:

1. Target type Already TaKen2. Classification3. Supporting arm assignedO. Priority5. Accuracy6. StatusP. Process information

Special list currently contains 42 targets.

PLEASE ENTER OPTION NUMBER

User enters option 3 to select the supportine arm

131

ENTER SUPPORTING ARM ASSIGNED TO TARGET

The options are:

1. ARTY2. NGF3. AIR4. AIR, ARTY5. AIR, NGF6. ARTY, NGF7. AIR, ARTY, NGF8. Other9. None

PLEASE ENTER OPTION NUMBER

User enters option 1 to select artillery

132

Categories for Special Listing

Tne listing can contain 4 items from tne below nenu:

1. Tarret type Already Taken2. Classification3. Supporting arm assigned Already Taken4. Priority5. Accuracy6. StatusP. Process information

Special list currently contains 29 targets.

PLEASE ENTER OPTION NUMBER

User enters option 4 to select tne target priority

133

ENTER TARGET PRIORITY

Th e options are:

1. I. II

3. I14. IV

PLEASE ENTER OPTION NUMER==

User selects option I for priorlty I targets

134

Categories for Special Listing.. . . . .... ..... .... .... ...... .. .V*** . .....* **

Tne listing can contain 3 items from tne oelow menu:

1. Target type Already Taken2. Classificatioa3. Supporting arm assigned Already Taken4. Priority Already Taken5. Accura:y6. StatusP. Process Information

Special list currently contains 16 targets.

PLEASE ENTER OPTION NUMBER

User enters option 6 to select tfn tareet status

135

ENTER TARGET STATUS --ACTIVITY

The options are:

1. Active2. Inactive

PLEASE ENTER OPTION NUMBER AND PRESS RETURN

.I

User selects option 1 for active targets

1 36

Caterories for Special Listine

The listing can contain 2 items from the below menu:

1. Target type Already Taken2. Classification3. Supportine arm assirned Already TaKen4. Priority Already Taken5. Accuracy6. Status Already TaKenP. Process information

Special list currently contains 10 targets.

PLEASE ENTER OPTION NUMBER

User ftas completed the query and now elects toprocess the list of 10 tareets

137

~~~~~.4.

SPECIAL TARGET LISTINGS.. .. . . e . . .~ . . .. . . **e*eS*... . . . . . .......

The options are:

1. Form a spe'!ial tarret listine2. Continue to process3. Write the special list to the screen4. Information about tnis procedure5. Return to previous menu

PLEASE ENTER OPTION NUMBER

The user selects option 3 to disDlay tne listing

139

SPECIAL TARGET LISTING

Cateuories: SEAD ACTIVE Pri I ARTYTGT NO CL PRI LOCATION ALT SA DESCRIPTION

AA0046* A I 35647582 100 ARTY 2 ZSU-23 PLT

Aka057* C I 35452353 60 ARTY SA-6 CLUSTER

AA0078 A I 35467787 50 ARTY 12.5 AAA SITEAA0156* A I 35667746 120 ARTY S-60 PLT IN OPENAA0122* D I 35334563 25 ARTY S&-9 PLT IN TREESAA0144* B I 35674564 50 ARTY 14.5 AAA SITEA&0167 A I 3b455234 100 ARTY ZU-23 AAA CLUSTERNAW023* D I 34556867 20 ARTY 120 MM AAA CANNONA&018 C I 34557890 150 ARTY SA-8 IN BUNKERSAA194* A I 360L7546 45 ARTY S-60 AAA CLUSTER

NOTE: * indicates tarRet list

PLEASE PRESS RETURN TO CONTINUE

The user presses RETURN to continue

139 _ j

SPECIAL TARGET LISTINGS

Vie options are:

1. Form a special target listine2. Continue to process3. Write tne special list to tne screen4. Information about thlis procedure5. Return to previous menu

PLEASE ENTER OPTION NUMBER

Tne user begins a new query or returns to tne main menu

BIBLIOGRAPHY

Bowles, K. L., Microcomputer Problem Solving Using Pascal,Sprinier-Varlae, 1977.

Chamberlain, R. "., Conventions for Interactive ComputerProrrams, Interfaces, Nov 1975.

Chapman, J. A., Logical Data Base Design for Relational DataBase Systems, Masters Thesis, Naval Postgraduate Scnool,1978.

Clautero, R. M., Generalized Appreacn for Evaluating DataBase Orranization and Indexing metrods, Masters Thesis,Naval Postgraduate School, 197h.

Codd, E. F., Seven Steps to Rendezvous with tne Casual User,Proceedings of tne IFIP TC-2 Worring conference on DBMS,North Holland-Amsterdam, 1974.

Conrad, M., Pascal-A High-level Laneuaze for Micros andMinis, Data.mation, July 1979.

Coulter, R, J., A Prototype Program for Target Information,Technical Report NPS52-81-907, Naval Postgraduate Scnool,June 1981.

Date, C. J., An Introduction to Database Systems, 2ndEdition, Addison-Wesley Publishing Company, 1977.

Dahmte, M., The Altos ACS 8000 Sinle Board Computer, PyteMagazine, McGraw Hill, v. 5, no. 11, Nov 1990.

Dobie, R. B., Information Storage and Retrival System: ADBMS for a Microcomputer, Masters Tnesis, Naval PostgradvateSchool, 1975.

Enle, S. E. and Granda, R. E., Guidelines for Man/DisplayInterface, IBM Technical Report, 1975.

Fleet Combat Direction System Support Activity San Dioeo,Quest System: Program Operator Manual ASIS, 1974.

Fleet Marine Force Manual (FMFM) 7-1, United States MarineCorps, Fire Support Coordination, United States GovernmentPrinting ufrice, 1;7.

141

I

Gawle, M., Koenler, G., and Whinston, A., Data Base Systemsand M1oro-Computers: An Overview, Purdue University, August,1979.

Grogon, P., Prowramm.ng in Pascal, Addison-Wesley, 1Y7L.

House, V. C., Data Base Management, Petrocelli Boors, 1974.

Institute for Information Systems, University of SoutnernCalifornia at San Dieso, UCSD (Mini-Micro Computerl Pasral,Release Version 1.4, 13-7.

Jensen, K. and Wirtn, N., Pascal: User Manual ant Report,2ni ed., Springer-Verlaa, 1974.

Kann, B. K., A Metnod for Describing Information Reauiret byth-e Database Desipn Process, Proceedings of SIGMOND, ACM,1976.

Kennedy, T. C. S., The Design of Interactive Procedures forMan-Machine Communication, International Journal ofMan-Macnine Studies, 1974.

Kroenke, D., Database Processing, Science ResearchAssociates, Inc., 1977.

Lewis, T. G. and Smitn, M. Z., Applying Data Structures,Hougnton MIfflln Company, 1976.

Headquarters, Unites States Marine Corps, Marine TacticalCommand and Control S ,stems (MTACCS) Master Plan,Wasnington, JD. C., October 9,79.

Marine Corps Tactical Systems Support AztIvlty (MCTSSA),Marine Integrated Fire and Air Support System (MIFASS)Specifications, ELEX-M-296C, 1980.

Martin, j., Desien of Man-Computer Dialoeue, Prenti! e Hall,1973.

Martin, J., Computer Data-Base Organization, Prentice Fall,1975.

Naval Warfare Publication (NWP 22-2), Department of theNavy, Suiportin, Arms in Ampnibious Operations, NavalWarfare Publications, 1973.

142

Ramsey, H. R., Atwood, I.E., and Kirsntaum, P.J., ACritically Annotated Bibliograpny of tne Literature on Human-Factors in Computer Science, Scientific Applications Inc.,1978.

Ross, R.G., Data Base Systeis: Design, Implementation andManacement, AMACOM, 1978.

Senan, A., and Sinombing, T. M., Datatase Management Systemfor ,qitrocomputers, masters Thesis, Naval Postgraduateschoo1, 1979.

Snnelderman, B., Improving tne Human Factors ks.ect ifDatabase Interactions, Au Transactions on Data BaseSystems, 1978.

Snneiderman, B., Software Psychology: Human Factors inComputer and Information Systems, Winthrop Publi-ationsInc., 1980.

Slesser,R. M., One County's Experience wtth Data Base,Department of Defense Computer Institute Selected ComputerArticles, 1980.

Smitl, D. L., Methiod to Evaluate Microcomputers forNon-tactical Shipboard UIse, "asters Tnesis, NavalPostaraduate School, 1979.

Smitn, L. B., The Use of Interactive Grapnics to SolveNumerical Problems, Communications or tne ACM, 1970.

Snodgrass, R., A Sopnisticated Microcomputer User Interface,Procedings of tne Thilr Symposium on Small Systems, 19FO.

Tsicnritzis, D. C. and Locnovswy, F. H., rata BaseManagement Systems, Academic Press, Inc., 1977.

Uliman, J. D., Principles of Data Base Systems. ComputerSciezrce Press, 1980.

Weiderhold, G., Database Desien, Mc raw-Hill, 1977.

143

1. r .. .

-4avai peo -az a 5 r.:o

-onterey, C S L 3rn - *a -Cc- 7. -a£5 3 all£ n. .;e< -, ,-. a ,

C TCI r. e 7

v -'T~ - .

Au:: , 3ur. c-' ti:=.- r'~A t F i c

.r n-

tz a r e .-

.. u I, c'

1: . - .. --

t y~..

SC s t -x

. aoa, :isE2.J -a I

3 r c m I, C=~ i ZkI5