OCTOBER 1981 LIDS-R-1157
SYSTEMS ARCHITECTURE AND EVALUATION
Edited By Michael Athans Wilbur B. Davenport, Jr. Elizabeth R. Ducot Robert R. Tenney
Proceedings of the Fourth MIT/ONR Workshop on Distributed Information and Decision Systems Motivated by Command-Control-Communications (C 3) Problems
Volume II
June 15 - June 26, 1981 San Diego, California
ONR Contract No. N00014-77-C-0532 PREFACE
This volume is one of a series of four reports containing contri- butions from the speakers at the fourth MIT/ONR Workshop on Distributed Information and Decision Systems Motivated by Command-Control-Communication
(C3 ) Problems. Held from June 15 through June 26, 1981 in San Diego, California, the Workshop was supported by the Office of Naval Research under contract ONR/N00014-77-C-0532 with MIT.
The purpose of this annual Workshop is to encourage informal inter- actions between university, government, and industry researchers on basic
issues in future military command and control problems. It is felt that the inherent complexity of the C 3 system requires novel and imaginative thinking, theoretical advances and the development of new basic methodol- ogies in order to arrive at realistic, reliable and cost-effective de-
signs for future C3 systems. Toward these objectives, the speakers, in presenting current and future needs and work in progress, addressed the
following broad topics:
1) Surveillance and Target Tracking
2) Systems Architecture and Evaluation
3) Communication, Data Bases & Decision Support
4) C 3 Theory
In addition to the Workshop speakers and participants, we would
like to thank Dr. Stuart Brodsky of the Office of Naval Research, and Ms. Barbara Peacock-Coady and Ms. Lisa Babine of the MIT Laboratory for
Information and Decision Systems for their help in making the Workshop a success.
Cambridge, Massachusetts MichaeZ Athans October 1981 Wilbur B. Davenport, Jr. Elizabeth R. Ducot Robert R. Tenney
-1- SYSTEM ARCHITECTURE AND EVALUATION
FOREWORD ...... iv
3 C I SYSTEMS EVALUATION PROGRAM Dr. Stuart H. Starr ...... 1
C SYSTEM RESEARCH AND EVALUATION: A SURVEY AND ANALYSIS Dr. David S. AZberts ...... 21
THE INTELLIGENCE ANALYST PROBLEM Dr. Daniel Schutzer ...... 31
DERIVATION OF AN INFORMATION PROCESSING SYSTEMS (C /MIS) --ARCHITECTURAL MODEL -- A MARINE CORPS PERSPECTIVE Lieutenant CoZoneZ James V. Bronson ...... 67
A CONCEPTUAL CONTROL MODEL FOR DISCUSSING COMBAT DIRECTION SYSTEM (C2). ARCHITECTURAL ISSUES Dr. Timothy Kraft and Mr. Thomas Murphy ...... 93
EVALUATING THE UTILITY OF JINTACCS MESSAGES Captain John S. Morrison ...... 109
FIRE SUPPORT CONTROL AT THE FIGHTING LEVEL Mr. Barry L. Reichard ...... 131
A PRACTICAL APPLICATION OF MAU IN PROGRAM DEVELOPMENT Major James R. Hughes ...... 165
HIERARCHICAL VALUE ASSESSMENT IN A TASK FORCE DECISION ENVIRONMENT Dr. Ami ArbeZ ...... 191
-ii- OVER-THE-HORIZON, DETECTION, CLASSIFICATION AND TARGETING (OTH/DC&T) SYSTEM CONCEPT SELECTION USING FUNCTIONAL FLOW DIAGRAMS Dr. GZenn E. Mitzel ...... 211
A SYSTEMS APPROACH TO COMMAND, CONTROL AND COMMUNICATIONS SYSTEM DESIGN Dr. Jay K. Beam and Mr. George D. HaZuschynsky ...... 227
MEASURES OF EFFECTIVENESS AND PERFORMANCE FOR YEAR 2000 TACTICAL C3 SYSTEMS
Dr. Djimitri Wiggert ...... 243
AN END USER FACILITY (EUF) FOR COMMAND, CONTROL, AND COMMUNICATIONS (C3 ) Drs. Jan D. Wald and Sam R. HoZZllingsworth ...... 261 SYSTEM ARCHITECTURE AND EVALUATION
FOREWORD
While the other three volumes of these proceedings deal with theorectical or algorithmic aspects of C , the papers of this volume address the more realistic, and clearly quite important, issue of structuring a C3 system to maximize its abilities to support a military mission. The design of
C 3 systems involves both (a) the conception of functional organizations which deliver the right information to the right decision makers at the right time, and (b) the evaluation of those organizations in terms of overall mission effectiveness, not specific performance characteristics of individual elements. The emphasis in C 3 design must be to make the
symphony as a whole sound good, not to require virtuoso performances from each player in isolation.
The papers in this section are grouped according to four major themes: 3 overview and general perspective (1-4), discussions of existing C systems
(5-7), evaluation of hierarchically structured systems (8-9), and frame- works for C3 design based on functional decomposition and analysis (10-13). This organization reflects both the variety of perspectives one can take, 3 and the lack of a unified, consistant framework in which C architecture can be considered.
Of the first group, Starr and AZberts provide broad overviews of on- going programs in this area. In contrast, Schutzer and Bronson describe conceptual frameworks for addressing some generic C issues motivated by intelligence analysis and Marine Corps applications, Kraft-Murphy leads
the transition to specific problems in a discussion of the Navyts Advanced Combat Direction System architecture, and Morrison and Reichard discuss the
utility and content of information communicated in Air Force and Army appli- cations.
On the evaluation side, one needs a methodology for relating the per- formance of elementary equipment modules, as measured by their engineering
-iv- specifications, to the overall mission effectiveness. Hughes gives a case study of one such methodology; Arbel discusses some of the theoreti- cal issues encountered in such analyses. Finally, several papers from the nascent effort at Johns-Hopkins (APL) (Mitzel, Beam-HaZuschynsky,
Wiggert) and HoneyweZZ (Waid) bring these same issues to bear on design problems.
_V_ C I SYSTEMS EVALUATION PROGRAM
BY
Stuart H. Starr The Pentagon Washington, DC 20301
1 C I SYSTEMS EVALUATION PROGRAM
by
Dr. Stuart H. Starr
ABSTRACT
The accompanying annotated briefing describes the objectives of the Systems Evaluation directorate in C3 I. The presentation summa- rizes the goals of the office, describing on-going initiatives, and identifying major problem areas that require additional work. C -
03 o E
-- OE LU 0
3~ C CZ
0 0N Et0. *) * -
03 0..
~0~ . ll·l i~-~na~~--.~..4. in
a~~~~~~
co cO _r " - .3- 'Ca ._- (3JW4j(n~~~~~~~~~~~~C~ 4-)*--w E ,'' ¢- --~0 a) -n E 0r, 4.) - L'n S- c.) a) a) C toM-c C-iS04- -o E -~ = >-,~ ~ ' ~ -~S. ~~~~-r :o 0 - E X '-- ' r- co CN - c 3-> 0C 0-- J n 0 P C CZ0U- C) 0 C -J C M S. S. .4-) C C) ( CL.C a lCD0) 0ea -, E4 C) 4.0...-0 Eu- * 4. /). '40 Eu-- C C i LUC 03 EC 0-,-·0 -1 .a- n . c- .C C C C) *3 - OSmC W? 4 . ' V 0-*, E CC)2 c- ·r C) 'r0E 4-V) 4-'c C 4-) S. a o 4S 0 W C COCS- (0 inC 4-' *r-C- *ra.04Ca)(0- .- O C a) .- C u- *- 4-) j .C) 0 CD . -0 4-) C i - S- ( N C400 M W '>-p'C' 0)r
C) a) 4-)S. 4)< C) .9-)C) C)aa~ · C) S. *r CS.O4Jn C ~ 42~ S 0 C C0 *'-4-'C S. 0)0 C 4 -S(0- E- C 0- 4- CD *3 4to ( ) IC 0 4. i n 0 -r 0 0 - ) .- 4-OJc)E 0 (0 OC C:: 4-- I. 0 C LUi. .9-)C)>0,..C 4.) *' C) 0. - 0 c -+-, --= ~~~~~~~~~~~) ~ 0 C 4 404cL) 4- - 0C -) ~ci -i-) U S E aC)E 4- ,O LS.~ C)u u- aC) 0i V) E( ~O C(4 4.) * u- C)0 COCL.)CO- o C- CZ M0O E I>Sco . .o E C2L 0 C0 0EL toa)(0- 4- c - 4- C ' e(0 iL U 0 C L.CE 4- S. *.~ ,-----.3--'-~ QJ0. O~I. C) (to.n Eu-in *.-~~~~+ > a) 0S- * 0 (0 2 '~-0)0 2'C00 5-0 - Ct S. in CO 00 O OC 0 0 0 0C)S..e4. E C) 4c( 0. in) >4- -C (0 in (0 0 2 m C) inin 0)0) C) C)0VE C 4-) C) S. 5.. 4- C S.. S. 4.- C4 0)0 r-. CO 0~ ( E E S.C in C) 4-) C C) .Ca -C) . -. v )4C >.,4-C ) _) C n C: ' 0 0 ~ N 4-S. 3- in C C (L - C 0 a- S -O' C - e-4, C' > (- 4.- C> C u-C~~~~~)(04-i~~~~~~~~~" in 0 in C)0 WO~~~~~~~~~(V..C-4- 0- C "-- ',i 0 O ~(' (0 C0 C4)-CL u'> 4 " .- C) (0 (3J(0 CDE>0 C C) - C-) .. . oC- C. .0a , E.!~a 4-).-S0 -a 4--) .- . 'S-C 4- U to= C ctl n - 00 CZ 0 (n 0U .- V C) . 2 - S. *- (- C) ) MV) C-C04-. 0 0 4- ( LC)in>- Ccn - i n E 0 4- 44..4..) -: .4-) to-0 4-c 00- M , cn U0r OCn 4- * o toJ . C S 0 o C0 a) 4- a) 0. 0 o 0 0 ) CC U) Ca * 5.0 >)~ C U 0 0- > C> C) 4-).r--4-) toCc a-C (0)in 0 >.=, - inv 3 2 S. > v E.. 44( .. i C> 4- C E CS->., E- -4- ) 4.) 4.) +-C 4-)c 4--¢,'~o -0C -~cncMC -~.) ,-o -, -Eco1 1..o0O- =~a o *uc) '' L4.),- *--u - cnr 4-.4- C)UC 0S.- CCto v~o -= -. ) M . - 0 C-.) * . C) .- ,- *. .0.J- 0 0- '. QJ- S. *- S 4-(- S. t oin- > 4) $.,-(0 S. (A - -0 C 0.L Cc 4) 0 0r c NnrOco . 0-to 0CA (0 S S inc V) ( 4-- 4) .- ~ C to Ln C - ., . C-) to CS- r S- 4- O . -- 4- 4-.9) )) ,- a a) o 4- 0-n~ i~ c~cO 0 tooo C.0- S..- L - = 0"0 C_ ) 4- C) S- 0) co '" 0 0 - G. - tv 4 LC) C, >> in O. .0 '.- 0/ 'rC .C ' . q- ¢ >a a 0 2 ¢, ,-, ',-- t4 5J ¢ '0 0 SJ.. >. C) ',-S- ~ S.- 0 4. (n 4 - M" U 0 Ct 4-:4-s 4.) ¢ Q "1CJ C 4-) 0 a) =C ) 4-) 0 C) 0-0 0-a- CD C) to U-. > U-L) S-.> CC 4-) CC U S-. C) n OUC) a I*a- ea C) L c-C -- ci -C in - C) C)~~~~~~~ S.- L- ~~~~~-1 S- 4-)> *= .4-) S- tO 0 in C),- 4-) O. .)00- u- -)C- (uo a-.) int 0 *Y (-o 4) a S. --S > 0.0 Cc4-' EO a) ro C( S.- -o C S. C) 1- * C)4-)L) 5..- Cu- .CUCS *C) in 0~~C--0 V0 0U.) C) 4--) - 4-u * a) 4.C) . i L~O~n C(0i n - h *3aC) C C) S- in4- OC S-> Q) 0) (0a 0 f-. 0 0 -C in .0 =E (024- (00 4-)ac ) Cu S- u U-04--)CQ > 0) C) *- U C C0 .e)0) 0)U A u- > 3- 4/ C) S- 4.) = 04-'U 0 C) S-> S- S.a- S- C 0,0C)i S. C) Sa. 0· - 4- 0 00 0 S. i SS- S- ,-0 0 .Cu- 0-e 4-> o o 4)4 4- 4- 4. i n Mu-n 0 C /) 0 ( - inC (0 - ) C Ci(L ) N c0 (- 0 *E 4- C) 0 0 0n4-) ,c 0 C ar --- CD)0 C)0 a)C) 0 OaCCO e) C) -C 4--) U C .,- c)04-) I- C)C C)C a) C) -- S- 4..) 4)C )e -. C 0 M 4- S-o C C C- C 0- .3- E 4- ( SM 4i S.- E E 4- C C)EC)PC C) * a0 00-S. C)-wC C) 02E (UE C)) C?) C . a--o-Co C oC0 "D C COO . 0 -CO -CO C- >-, C UC
C) ) 4-) e- U CD S. S.-a ~ C) a -) 0 uP3 00 r- 0 E C) C) (0 -C0 a- 0) 0- C 422 in a> .C r .C ( C 4-) L 4-) 0 Jn1L >t
cca 3 ccE v, r >~~~~ 0 o~E L E cc
0m mr'
au ) D) Za 0 " cD EDX -( - EoE o n o - ' 0 a) ~IIQ> a
0
a)( V~l r' - .a >0 E c0- a)Q
c-E Q v -0 CI-D 0 P 4-) LI, "4 ), C:) U~ uT: I C) *-V*.-'U ,- ,' C ::' . , 4CJr.-- ,-c4- )- C 4-O 4 q L., - ,-) .: tr-- E coD O IZ rL,·I F, a,: wL S- > Q - V ro M-' 4-) C) C1) C-' *- i tot-toM E W C) a.~ C C -4Z 4S. 1- a (A CC) %- to ' L~~0 C) '-2 -CU to*C)M - C) " - 4 S.. ~-C( >q-4- a) ' 0 00 ro. -- > L-,- ro *-, -~/";C) C' -r . .;.C r q-- i/ O -EV?)LI,(.f~ r- · U U'; O0 to ', C) a)n ,-->, S.. I ,>a> . - (, - ~ 4. "- CC0 M > ."-U -0r* rC4 u) C C) E WO.CU 4--,rC) 0C'() M 4-- "CD CL' C) - - U " 0M') >C4- -o s- C·C) C C a) 4- 4.~ C) 4-'C) S- C)S-o/S- C) McrOo c co ;E 0 4--'4 C: Ci-,--) rOOt - totto ro 0; > 4-> C) O--' , - to - 4-4-.-C 4-5.,-E - S-- ".%-. = U O 0--4-: ' v 04- U.0tC) 4- .raS- oc -'r-L "-, 4- .1- .CCC) E to C *r0-VC w / LL. 0 C)O tCL~~S...C v, t o r ·r r-4- ) NS ~ 4~ V L)- 5E .U C) .. - -', X c r- 4--.C -)-4- 4 4)-,- O co CD).) W C), , S.- C)~ - - 4-) =,- *-,- -- S4-- - ,-,- - X4 QW . 4 to l.- ~., ; o)U 4-' C C-0"C V'" . 'CV-I,-a J,,ao4 a C c0 ' , 4- C) M)rOtO C-O - ·,- - C-C S-- - C), - v(. C 4- S.- q-4- L " O t4-, C) '"- >-> S. S- C C .-C) rCI* ) L-,-, Oq-- O0 · 4-) -C U~ cr c0'" rL') "- e) a-) c. a) E S- -O r 4-M ,- > C) ~ L) E W > 4- CC) aC E =CC En CL C -C- U C: S- I': (2,-"-4 - 0 eC; C)-.C)1) . C) VD OI ) o 3 C). 4-C Da-C' C) 4-) "> co E 5.- '- 0COO E 4-. 4-.. C) .- 4- --- S.-C)-S- 0 (J 4-.r) S- E .-- r-- 0 C·~ C' Ur 04-c/ c>oo,Lt->t) ·. t +)LEC~d~c)5 = CO U ' O.,U u L.O C 4..4.-I > M~3 X > ro ' 0 Ca E 4- L CDU to aC S-- L,-4- U- t 0' a) ., U 4 -- rU- q-L 4-' C C) '0- C 5C)C)aC) S . E '"Sto; DC) , I a V C Co ... c) ,' '-.-,4-.--u 4 ', C- c- " O ,U,0 CC U S..r 4-) 4 C'- C,-4-"4C) PE ..- -r- 4--,' LI) V.*e- 0 > ~vuC)C ) C 0'r3 -COO O o `r C, ) CCD 4- ) ·4- a- E E C)C) O rU-U 4.Ž 4--,- , --1 S-.. C) co C)- W C 4)4 L. V'C Z -4- to U 4-- C. da L ~~~~~~~~-- 4-aUa a ccc " LWcc~t a) L. 0 M a) S- a) O V EO - to-U/ *Ct ~CkaLOtoC) 5.-· LC- toa- v,-0 k '- .4 -,--C CO )44-E-.O-E OS )"O S ;'oV O E r 4- C- .~OC)C)C 'r-Z >> > *- LU-)J v0- --0 - 43-)-c ,~ 0 C ~.+--,~o S- .4- C C- Q-- . : E "CC. a%-> 0 0' 0--5- S(1- -L"t ~10)SC1- *C) t) VA-C 0C) (-r4-.- .C-.-Z >- " -F- C 4- C' I 0 4-aC >, (/)c C4- 4 I- ;t CO4-4- 4-co 0.- ~O Y) .- C) C)M C) 0 u) - 0 0C 4T tz- )Uto 0 C) - UC: O a-. u- :C-m.~ · C .)S:.S. L- , t ' --t- ,S- t .1 - to 0 ~cy,- C OU * r -CO ~ -CS-CC)4 0-0a 0 "4- 0 ; 0 U 0 ==aC:EC)C) - 4'- C- O J 4-4-' C- ~ C:u~ C) , - rU% 4-'CCL ~C ~ ~ ~~,'(.C),9 ~0SEC . E 5C-t(U )L)! ..r '.,o '- -,C-C-- f-a),- C)4-,V4- 0 (,---4 SCcoc c-o) .c-- r'r- t *l Ln C C) . 1-VO 0 4U S - C) 4-4- V) OEL)t 1-r I-- S X S.U ( .4- *- L/) r-A~t "V "C * VL/4 S. L) 0 .0 - C)S.- 4-' C) 0 l~>a LOL') LOY )4-C>
a- C)tCL) C- .C) . L. I-C) / to C 0 A LI).-0> L-) C a- U 4-) a. S.- V0 '--) 4'-- 4- 4-) to C: ) 4 0Cr C4-1 * - 0L C- " a*C) S 0)toC) to0 C 0 > -E C C) ~~~~C) V-C ~~~ CC)C)4-'"wW3 ~~~~~.'VC.)>,L/CD >,C toC CC) S.- 4-' 4-) ~ V- 4- )Cto 4j-'4' CD (n/S- 4.4--)4 U C) -o f-- C) () .,-UCto ( " C, O V,)- - · - E r- *: 0 to-- - CO 4-,-- >C S- C C-4- - )C)S- -.vc )c )u 0 C LI) ~y>> > 0C' to U)0 -0 Ot-,0M 4V O o.CL.. Mo " ~ , o5oS -S ·1.-- C) 5- .- --ts >S...c\J 0Uc "LI) S-a) 4- ao L/ CfO CA S-. - 0 M o L _ r-4-) 4- 4- n. ,0-- O C .- = -P 0 · 0 - -, CC.rC C: $.- = _j 4-) r.l C' C- 0 C 4-4 ~ u,- a1)-0 a' 0 ;q M L. 0-,-- ra C) -r.- n z:~0 C: .j U) 4- 4- C)C S- to CV-. 0 .,- O -4- >r rUU-S.> c (C) 0 4 4 E CO: t .- O- -,O -- ' 0 C r o 4-Cc,: rz L 4'" · >,, S... ~ 4-) oC)Ca)a0- 4-0 Qa-.,> M Ln -C-U " to -,\*r -- L > 0 >~ S - 4-~ r· u~ (D- ~ O. 4-~ E~ 4-~ r~ >r Mu '4-,- .,- E U S-a> ) O S.-. C ...:C=C u)( O ''-- 4-0- O,- ~ r-- .,- 4: = O4- - C)O CC J 4. , 4-)- co '-4~ ar C.C ' -U 1-o ~C M- - 4.~C -0VV')Ln 4-) cULLI U = 'a- - 0-() C0j 4-r U 4-> C) 4. rO cor--- . , - =- --j LC-C rU)C)C) ce rr CtU o O, a) > --F a C)4-) 0- 4C L.-V > 5 .O >.---a- . o U. $>M- a C) '04-0 4- i V ' 4-.t4--) u ¶-, _C: C :' -a- CZ C NC4 S- C 4-0 S.- 0- -C P C)O - : M U CO " *--Vt LI) C)' t)C)W4- "~0 - L) 0 C: ~ 4- M 4-) o -0V4-.(L.) rO= C)C - S.-- S X LU O Cu9 9.V ,'S-V3 cM · uo 5 C)-- CrC O 0)t 4-: (C) 05- 0 -~ M 4-> 4--)-4- 0 5 .- " ).0Q XNJ 4-) 4-) q-C)Cr4- C t)=(o'>toC- - o S- S- 0 .C)n,- E O - 0) 4 - C -0 4-.- - UU-- 4- U 4 -- O S-EC : 1-'I 4-C -- 0 0o ' ,t4-+ E -'C)-- 4 .-- 4 uU a S-. 4-,-- U )LnS - E ) CJ C C t o 4--,--,-CC)t'C uC 4.- u J
.0 C) C) *r- S4-.L >F= 4-) to EV C) G V4-'U--- o C) 5.- 1V 0E= C 4-' 0- V5.5C , j4-')0 4- C U E ZZ Mtoo> *>_ £:: 0 z CU - .. E , / ) O. XE N. E o O °- - > 4) Z c n E 1 o g: - I v, CO Ca c DQ ~~~~'O Z,Z 0~~~~~~~L CZ *a0~~~c L 0 >Na .- ' -oc _n° <7m¢) a)O°) _jIj z II 0o .~~~Q~~~ a), o O"'' cb ao. , ~-r o" CD~~ ~~.om.~_r~' . ~~II cc~ ~_~C CI'.,.. 4) a-- C) c- S 4r-) L 3 C) 4 S 0Q 4 O 4 t- S - O a - m o - C S- .- aC) 's O t 4, t- 0 4- U O a : 'C '.ro *0 S-- to m cn . r Oco 0 C4-)E > 4-),r- - I^C) 4' ) LU 4,O 0 S ) 0 -=O 4- 4-) 0- L o*_o (A V.0 C) *.G O 4-) C S - C) C Q e cv , o C) to *- C.5- a)C o0 O r C Q) t o 4-) 3 4- *_ *W*_ 4 0 C ) to t LeO > t S... CL a)rQ 0r C-C)n 5 r *_ C a U a) .C C e, C t E ro * . .- C 4-U 4- O 'r 0 0 oC.) 0 0.O~ C)5- .9.- U C)C) ~ ~ ~ ~ ~~ V CC 0 c- Co 0 C .R . - O 0 0) ~ Com * , n < 00C) H 0 ~~DV C 0 C)4-co C O C4 C- m 4 > n C)) c-r- - ' C) 0 Co E 4. .- S-' ICvr) i, ~ L)UC Q(~WC~--CatE E ~ >1r ~ ) COaW O' O~- 0t-- Or 3 q- . (1 ~- ~J -~ ::i-,--- ~ '"" E a-r ·)-.r~ ..r~--"~ (~ ~J +o 0 - a0-' 4-4- N )'-3:, CO a)> r > ( C) >C) C)>C)CC ) _ := 4- -: 4-C)C -- ' E0na C-_ 4-- -~>Cn 'nto 4AL- CA-C) .- CD 4- '' - 4Jr - 0 4-r-00C,4 N -- r 0OX .._. 0 4--n - --m--) co 4 Cm0 >Mr +jc 40) C) ) - CO co C0Z r :>0 ~ S- 4-I0-CC-Iac"'4 4l '-I-t C) '- - 4jECa ~ O,~,C ~J 4-'A' : ~ 4 O.. - E j 0 0 C c- C- C P)l- 4)a) J: 3 OE 0)a~---C) r L5co 4Ln -CCC co CC-3-S.-I~O a S- r >I * r-.r0A4- tM 4-- 0), S-- N C S 00 CO-'r = 0 C t > C) - L 4--C-) I--C 00 U- CL ) -- --a)-C 0C * r- 3a C)C)F00 )tr C C + 0Zi eC C4- 0)> ) 2 +-'S 0)0 Ur-" coA-- raC)0 4000 C. rLW-Qz oE4- ..C -4-~ 0-I C *r--rC. C) r 00-LnO 0j E >t -- i 0)iaX H- 0)a0 iLQ0-.4-·r CC0) r-.r a Or-EL)C.)CA*.C0 a-t 4 UO C4 =a ) E U CAW ~-~CA0)0Oil3 a nL a a>.4-~-' a-r a):RC r~~~~o·A.-S-C) 0 YE c tn~ C - -- U) 4-C 04-'3 C0)0-~~~-0a 0-4-t C) 5-L L>-C 0)rC4 20- o C40 vc- 0)r3 C C {cs ,- 0 S.- O C -_-'10 C_ Lm4- C))C-0QCAU L r-,--raX Ca - 0-4C)-C)(V' 0 : Lno- 0 -: > D c 4- 40-)c n M'-(-'-E > :(L ::: : C '- S 4r E- r-- -c-a ) S- 'C) S -'-' co a) 0 -C C)JS . 0 . -- E) 4 CD - C4--' C:= · o cE-0-'= - 4v-- --E.C 0J4 -- .-'") --S' C)CLJo-'4-J O L ), 4-C O)-:) V5S_- = O u > u m m',-- m u :-- $ S- r"4-.. '0 S.- Or S.-00i C- -~ DS--)-f-O.(0 &-0) * 4V()0) S- C-) 4r-- L C) 4-)4- 0)(0"r-t 4-·0)4-'~4-C00-0C C O0C M 4-Wc > a -4-33~L5~em 4 O-0rc, Cra - t= -- > r 0 a '- E OC') -- *F-S C)S..+ 4 4-Ja E .rC) 3 a c4- rW S- 0 0 C)0 * C7,.4=C cA0O C) C.-0 .. -a C· O O -O O -4 - E 5 O - 4 '.C Z: -- - t- O UJ 0)4- - - '~- C>r-+-'= -~04)CO qJa~ Na -aJCO MSL - M 2 ) c~ S.C) -0S- 4- - 4.0)~ U C) 0 A04CE -C c: r . , )C . S-- c -.- :CCC 0 cI~ 40C - uEe rC5*~0 am :0CL 0~ C o r--O V -'- +5.-C a C: 0 4- L-04-)-~4-- 4-') 0 4-, 5- 04--00r0'r ·aC' ~~- o O·0 r ULC-no0 M r.. 0 ..C) et ~u. -CO 4-.' - ~ 'C] a4- C2. -- 'OJ:Z--- -- 4-t/ E O Ot/ > - C- .C. - 4- Eoa CO)-a L OC,0- iC) E 0 ~·r -4) UF-. ~OJ =,0 >~r'.~n4-) cE 4-O ~' 4~ O -CUj'C- 4-'.r- c -0 EL. (a>4-' O - to - COe- CZ 0 - .: -'-:C) ;Z-~ Co "-0.'C 4--) C O O . L) C) . C) S- -r-E r0)· > +- rC= -$..·Cr - n ":.4- 0 ICC > CO .C.- -rQ-:-; to--O Ca 5/ l O 0- 4-. 4 a C a) 0 C CAou 4-' a0 M L F"~~e a uaQ1 0a c,0 Ca~~ 2 y cl -- C,1J 0)a)-0 >'0D 0 C) C) fE ~ CZ-'0- - . U -C -: C ' Cp- >C.. ~ > 4_0 ro C' 5 - 4-r C 0' 5 OCA "--rO tC r--> S- 4- a) 0) 4-~ $0-C C00) CI)SC .. vr 4- U COO U CD0) - t Of4-4-'S-0-C0 C) ) = U 4-E P -- CA 0 S- 0 r-- /-ureS-.C 0 CE -E -- =_ CA · , r,- - M 'C) 'C - r C) - - , 4- S Er : C0 4-. C. 0C-) C-)O,-- E U a U o 0C-).CE 0) C) - ES- at0)0tn <0.0) -r- tCnU *r- C0) E C S-Ln0C)C S-)C)r-S C-C Q) 0 C:0 f0.) a - 4-CA5)0nu 4 >r- 0> CAt- r-0 0+ C 0) Ž. . Q 1rf CA v) O t0 4'A C C)- 4*-- r- ; ' >0)C) C) o-0c c C.C S M->~ Ln~~M ~ )L- (A> 4- "0) 0-4-)a +-''n . CZ->C)tn C e)C5.rt )P - tn a)tn0) n-- )-n (V a ' rt . -C)CC)u a -.L)> -a) qt - o5 ~0)- 0-> 4-- CCAC0)-4'C a P>) C) tn C) 0) al0 Cj *, S- (0CA 05-1 r 0C4-r -+r-"5-Z·' C' aCc Co 4-·c-rrJV~-- 0 rS-c>C 0 Z .r~L v S- 40C- E 0 -e4Ztn, ra) --. %--U ) --C) -- S- S-- · S..0ro ea-C L--4-C - Ero. C)-) C) C)0-4-- ( 4-0 0 oC >, -oE -C 04--4-0 0) 5- 0) ~- I I I I- 11 -- 0 0 o0 - E X en- .. 0- , - 0 0. I.. o I 0 I'i-0 o 12 S-' C cn C CS) C ~~~~~~~~~~~~C).u ~) - C C 4 C) S-4-> r- UC ) O C ) LI) ~~~~~~--C C(An C) C)4-)rI- ::S- . S.- Ln S.- *- - C 4-~~~~~C.) 4->,S.- .OE r 0 ~ fO4-> - - =C U Cn O c4-' LIC O .r-I C) ' -C -=- 4-J O C)C L'I) r--~O -' C) 'L0 P-r- .- - (A) C C) C) ' E CC CC.C. *-- ai C 4- "0 --, C ~ 'U 0 .- -0 -- C.) 0 5.4-'~~ S... C) 4-S.. V- (.D-r-C- -/ ~C CC .r- 4 : (D C..P'0 C)J 0 4-j 0CI > 0 0 4- oM4-C)W-o.C-C: -C a L(A CU 4-00 --- 0S- , L") 0 --C C )F-4--' Li C-) C -= A S.c-.a ~J~ O C) - C)) C-0) C C ) ' - L - L. - C C) C) 5500 , O) r-C'aC)· C)Ca) 4-'C ES - L C/ *') e) C a CE u' , -. -- L -f..) 4- - r r- ar4-S.- > tOL')- C o '' u 0 -cOc " C S- Oa) .C L)C. r.~L I) .COEH F- C).,- C ) '-I 4- C C - r~. : : CC)4- U-.- . C. i 4- ,--.- .4-- C) C) C)L ,- )n S.-a > . CC) , - U C - - C . L) LU -. - U U , -> 4-C )4-/--C C) 4-) C)- 4 C Ln C:C S.- w 4-JC.CL LI c0.o S- ,- * p 00: -P '""~EC (A0),'--C) -C C 4-. 0 PUDEI C4))-- -4-' ) CO r -r-.-- - C co 4-'a 0C) 4 0r C) C) Ur LI) O0C) u S.-S U 4--'r CO C) L) -'-- aC) 00)4-' L vU)S.- C 00\ mC 4-C W 0 - C C' r" 4-,-,"0 q - 4-qC) C r- C - S.- 4-' C) C C _ -- E 0 'C)- rS.-- C- ("'- -.U , -C) -. -r 4,r' C ,4-..IA' : "' C ri u0 cn-L >, -- r -- L) 4 C) ·- U 4- C:-,- C))- -- =U C W -I --' C) C ) 0ca 4-C4- 4-S-> E , -r LI (C4-'5- C --C C OmCV)·~ I- . C= ) ) 0 >0=C: C -'-- > 4- 3 CL.)r 4--L - + C.- 4-)U > E 4-C) CC0- 0C) C 04- c-,- 0C C:)- coC)-: -C) S C 5. C C) 0-P- - C)C) 4-0 CO4 -J C O4 E0 4- 0 . 4-' - 4-0· r1= 55 a~~~0E~~~~~ c~ouS.ES. ,v a,i i C 05E~c '- 0 5' E -)- C./o ro 'P 4-' M L C) 4-'C)D 3r-.C 4-'C0 C-I-- C~ .r-r-C/LIC >I) ', S..CC IC))CL- t-4-)4- C LI C) CC' -rOrn4kcc . C C)00C c 400,r U)CLC)>r E LI)4-Vt (*OC)C.4 -'LI c4-o )> c EEl.&-C c -- -.rI Cr- r IC *r- LI),~e cC.C S-.. aL)L C5."C- w CE U -~-- S.-'-I ' X 0 0C),E'-CI C 0i r-- - 4-4 0-( 0 0 C) C0 a-4-' C) (A 4-,) 4 C) ) afL) L) C 0CL) 0C)0 v( C C C) LI) r C ) C'l c ) V *' 0 LI) C C 4-EC) 4-- L 4-r-'-C q--La r' C4-'rE C C)4 S.. C'-S C L)O 4I) C. CC)CC))CD .0 ' Ln - 0.LI C)a> ) C C) C)) - CJ -P-CCayc / aC C O 4-'0'- ,C), 0S.. 'c0' 4-,C LI)c 4-' o~ * ~C ,.- ~ a4)) 00CE- a aE0LIC) CO, -- O 3 0'CE-~0 4-'SU )" L.Cr CO. C C.- - rb~a a O CT,T- S-0 3 U rxa)E a .CCc-.- Q)'r V,to- ~~-2= A C 4 - 'n C) C 4- c:O-~J ~J O ~ O-- (C 4) C C). 0C)4-'LS(Aa)- cc~~~~ 4 C) ) C) Co) u {1 ' - 40- 4' C) 4/-C)S- > *' C C . S..l C 4-C-) O~I- ·C.O uC)-r-) I)C) L-4 -rcj0 > C)- *· V,~cL) 4-'C)Caj 0C) C. C 4-' 4-' LI) C a4-'4-)0. >CC) C4 aC 4--) LCn -- C0C)0 LC) 4 j C) -4 0- LI) "0*C) (A,.rC)4.' C)C)eC)>-,C 00 _ ~ c)4-' C S-'C C C C) r- -.O) C) 4--- 'C S.-0 C -'-- E - 4-'0C--r · ar -La LI)-- C C C)to C) 0- E C 4o Cn . 0ccv * Y-a,0C CC C XCC.CuC4-~C> .-HC-a P E CCCoa 5- ) S- C C LC)3-) o C 0 0, C)· r UOSO O Vt~~~~~~~~~4-r-cCCC' C) C)aCu 3aa oS - u a a c + wo C~-T.0 : -C):- C)C)4 44 U0 C) -CO - 0 4-' C) 00 C4 C:>r C- C) C E CxC) C,--,4000 ~~~~~~~~~rCM EJfo:>_E4-C 4 -I .3 0 -C.0A CZ0 ~ =- CL ) o S) - alS- L-M - C' 04 C -0 0 ) 0 5 C 4-'CC C - 0 I 'l O ' C)" C: )C*'-- 00~ 4--C r- E C· C S- 4NC/- U J 4-CC)::: C:-- S - S. .r-") Cv U o 4-)' CC Cr C) I) ' - - 4 E-> r-· 4CAC)ar L '0-C) C 4-) 4 c-'tD 4J- ) > - C ~-- . u~, u~ '0'r 4-)U- t C) ~- ~-a C) . --~ U -- Q S.. Ln tn Ln 4-' 0 Er O? Lv,·rE -C~c, o ~--v,C a rS - C C) C) COC- ,C 0--C- _ CZ)- 0'--r-uCC 4-) C J 4-- C O0 4uw0 4--a v- CD C)C)- - C 4 jza,-C) (n - S-C) C)S- C) P S--13 ~O -r-r-- ~ J--~c: 0 03--Z: h "CO.r0 4-'~~------4-)M ' 0 4--~ 0~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~- -C- . C~ S-,- N-- C) C i3 F~~~~~L)Q)r~~~~ O Fill 1 3,ac r n Ecn L ·r v, ·r 5 raYa, YB .at~~~~~~~~~~4-) Cn E 0) >C ,) >) om en4-) > QC 0D 00 O -o-oIELE ,> L CCWZ o. _oW0N I P.en -o I l C EC Cc E C1 o.~ o ·e -I I ! 14 U O C)~~~~~~~1 4.) C).C~~~.r4-' I) L) I LI) -C4-) - 4-)r03 - 4-·. E 4-) Ln M a C W3E C) CD C LI) ~~~~~~~~=4-) -0C) - 4C) 4-' 'A0 - 'J r-''~U a4-/E - 4' i. 0 L) Li or Eo Cv) ".I. ).. .I)> > 0 I:C:> 4-) 4-. - C) 4- co C: S.. n >,--, r-- u .r- V)0 X 4- 4-. - ) -U= . r- ---c re).Z c-- ~ Ca) L) 4- U Vi H-'- . r-QL) i...-_LI C-4 >- U- 4-- C)J o rC>,rc - 0 C - )0 U.-. a .C)0 0 C cL-"r C) ·S- 0-- CL0 .C)C CJ a)> >" :" c-C } U -'M .-CS -I 4-,c 4- E: ' Z C) -0 LOU. ro C) 4-) 4- 4. (0 oc C) w 0 C)~ 4-0 5-0 0 co C) 4-L c S. . Ec)4-C) Ci co -- C- S.-c S-. S.a . - 4 S. - -- 0S- S.- r- C) * C)O4-a C 5 U C0 0. :: 4- C) C) M - O j-).4.-.) .- a,-'- ro -C4- )OLLnS.- 4--C 4.' 4. 0u S-.. C)o0-EV S.-C) O 4-'> (e .CE4'C)C S- - 4.-- ( SC.- C C) . C) C) .4-) M)_ .:C C) 0. Uo 4-' c *-- ' -> C)4- C) >:, F- 4: m L C C) > .. Co M r C) ' loS.- L ?re C:: .,--L IS - .,0U : c- - C * C) C * L .- N4-- C - 0CC- 5 C C- coLI) O CCDO (D ,--- coU - ;= tnC: . - C)r nC-OO- C > '4, -.' 4-.' 00 L) I) C- O 4 L C)L4e-U>, + .' L C C) 0 SM-.. r--. S. C) - I O,4- . U ) C -~-- r- 0 " C. LI) U 0) 4-C~ C) )r.2.CrU CC r- (0 C r C) C aC · ~ " c-C) - CS.,- Oq- S .. I C -- 4- 4,- 4 c rO,,,'"(r-.-- CC4O -- : I- 4C . C)L.,- Lin 4-- 0- C. 0 .5- 0:D--0.-::J ~J :~ C ou =C C)O c4;= - C) 0 C· C) *-r- -) >0 c) ro - c C) .U 4-- a - r .~ (- r U - ' G-0 .- -, a-) 0 Ua a OCr-- r ' -r j C).-O a C/=-C) - L C):C 4--) C) CZ--C) ) )V C)-L Cc I 4- S-- co --D -- ·-- .>-C - = C 4, -. 4-'·~ r- ~ 0C 54'---uC. .--. >.. ra 5a ~,a rIU4'). v C - (0 4-).C0.CC)Lt)44. C)>V C)4-.) 4--LI. r- LIC C 4.. 0- 4->."OC) >' * .. LI) .C) ) 0 C 3 > = E C) i 4- > Ln r o > C C E 4-) 4-) COa C) C S.L I) C > L) C) ..0 E.. C) C4 - )c C tOQ) r - E-- E >- ' E r U C >. C) 0 LI)C S..I 0)C0 - 0 WLI 4-"-OC r 0 C) *J LO r O O4--l C ) -c- r- U U O U.- 0 ) U 0 0.4..' C)5LIC > C)C a coLI. N C Qc) a C4-4 c C) C C) Co U>-)0 r-C4-.0 = > E -- co C)) L LI- 0 9 C) tr·- C X C- C-0.C)5-- -- 4 4-= to - 4 . C 4-) C)E C) 4C) U 4C- C -C 0 C) C) .4- =4- 0 4=-= C)4-) C- > C 4-> .C .C > VI)C uO 1u C O ( LI (0jI--) *t-00 O 0C 4-5LI) 4-)S-C)4 4-O 4- .LI-5 > LI ,-. 0. COCOO4-'.O 4 USorC 0 E 40- ) 0 0 (AU) 4-.r .r-0)E04- ai- 4.- S- U 0 0(0" 0 r- .4-)C)ctS...4-'S- M c4-', S -4.. Ca 4- Ca, (0=3~~ 4~-~ COCUv,~ 0)-U5- ~ ~ ~>L) ~ ~CC 0 r oa a~1C)>L.-~ LS-n 0 C) 4- E 4- 0) O,COa C0E -- Ln r-O0.0='-4-' .. CCOCC) 4- coLI) - C) L 5aL-C 4. C)r- .- O a) cS C)4 C .- a) (04. LI o a0CC 0-C) \,r-,>, C--.L)tC > = C -::C 4-0C) CU S-E.CC\)J OL)-) 4. 0-O>)c S-. > r S) E C4-)L 4 0C)I C 4--) CO C) E C).L S.- >r 4--) (0 > C) .E L).CLI a4~' t9 C CC5aa) u-L C) LI LIa) C)e C E S- C EUC( 0C) M 4-'0 -C- C CC C) 4- 5- -M )5 )0*vCO S-. UC M -C) 4.. 4. - 4-) * 0 .0 S- -4..C0L) M. LAC) C C( r) .4--'0U C C 4JU,. C .C .ea 4.) LI) C CO 4-- 5 * C) 4-) Ct 0 0-ca Ii CD c -- v, rMC- S.- . LI S.- ;- > ~ )C), -C ) 4. 4i -r U C 0 C) C)C) CU to C-0 cS. - C)S . I-I C uS L. 0-C 4- > . 5 S.- ) C C))L -I-' S.- 4-') 0 - "C L +-a-)-- 4--U 'a0 1 CA S.. (0 -t " 4-)L/COL')t C(0 4.'5L/) wCC 4, - t C) 4i 0 C) ~O) 'r, Cr-EC) a CU -'-' 0 ck r· p-COWa 0. LI)an. 0) S.. CJC I)Cr-E- 0 C)C COC . QLI) 4-') C) C LI) CL .0 .~5-CM0CO C\J4-- CC) 0 4. ) 0 C) 04-' O4- 00C)S-0 4.' U'U4j-' U 0 0 QJ0. -C - t nI) ()u 4-'r- 4- ro ( 4CAU)0. 5tMC) C. .0 Uou tn) >rz. -E 0-C UO tn0 C ) . 0o LI 4--'- 0 C)04- S.-U a S- C=tI 4- >4-> C) 0. U CLu u 0 tI) k o ro C4 M0 4- av) ? trI) · r~~~~~~~~~~~~~~~~~ S.. LI 0, - a C) P~ I tO~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-t( 0 .. * C) .4..)4- S- ·~-= n tn 0 r- e- C) C- S.. C)C .0 S-. > > 15 Nam"~~~~~~~~~~~~~~~~ A, 4~ .*= ~~ I ' . ~~ .* ~~~~~~~~~-- cn u~~L ¢ 1.~.'~>::,~rI~.$z :-~::~:-'.<,::.~:~..,::~:-.~'> ,· c- ".-5 c · 6~O < = -L C fL. LLI .~..-...... : 4 ...... ~..: CD ... ;.... LU ..~5,·-· : LU C' '' n · -r~~~~~~~~~C. ~:;- ·.:..~·" · · *.:....:.;.:~:.:. ::;:....'~~~--~5 :': x:.:¥..~... z Lu L t r. t .. .. '.. U. W . . Z .... ;i~~~:~:?~?;.:;i:::,:.$;! :.:::.:';`:!':~-.;:;dZ1~~~~~~~~~Y ~ · 7 -.:`.. O:' ' e . z ~c c c~ ~- LLJ ~~~~~~~--"-' ~...,~;.:..~.:,X:::.:-;., : >--: i- -._.-~ c~'; ~ !. ,, ~~, ';J ·..·.~; .~;."- :.,:~..~>:- ... :. .::?- '*" L -J~~ ~ ~a·:~ ....m;Z:·:~ W~~~~~~~~~~~~...... CO.4 ar -rwo Mcc ~ Jc . CJ:..'.~.. 'W,--; .' - ,...--' .- 1 6~~~,; .. ' ' .- 1 ·cSLCD a~~au c Q~~-·-c C. ·4.9 'rr~~e : ~~~~:3 · : H: ..LL;- cn~~~~~~~' I~~~u '....'.. " : ~:::.~.:5 .*..~iw - = t ~~~~~~~~~~~~,,-. . .,;~ cb · a.E ., ~~~~ - w· ;~':·' ' ...... -.....I ~ 1-,: .... ' ...... ii~·a LLI O ~~" LU e rLL -J~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~. ·-~c~:~, ·.. . . ·~~~~~~~~~~~~~~~~~~~~~~:. ~,~...:,~.~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-·...... ~~~~~. . . ~ ~ ~ ~ : ....i.' LU· ·C.3~~~~~~~·· ~I·F ;:'~::.:::.':.:.:' '; .:':! :;:-::~:,,c, 'I" :- ·~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~- .. ::' :.:": '··~' .''·-,.:A4; ?:.' .·~: . ..;:': ~:';:"*; :i' "": ~ LLIN .: l::'~: ' .... ======··:.:.-.======. ,...~,,~,. : . ¢ ,~.::?.!i.:~: ~ ~ --;.:O~.g .q,-:-~:':,: ,~...c: ~ :, ....~ . .:.-.:.~.,::· ::s.:..- ~,:- ',::~ I, '~.., Z :"-·:.:'.:.,: ::.'-;..';'i·.i~· '::::;; j. .:"":.'"..'.1.-i,'',. "'. . ") ::-,:":.".·.:::::'\·:-:·:~: :.· ':i:F: '~.~ '16· a,~~~~~~~~~~~~U C) -.-- ~~~ ~~~~~~~~~~~~~~~~~~C)C3) · p --*r-_ 4-) C) 4-' 0- 4~ - .r-r-3 QJ OJ - a '0 M C) 4-C 4-> > C)C)M > > C .-- r- C) C~f- 'At-n C~r-*r-'C)-,'-)-_- - - -. (3C ~ , r4.) = *--) 4-3 ) 0 Co L0 4-) aa> *r3 Y >-,4-~~~~ r·r0 CS- cn r· SMt 'I-, C- r-tn (nS.-.) >- C- C) - 'OCO>(I 4-)uM E CJ*- (CS ]. ~:C: O 4JO) ·J~- (4J 4J co=~ C)S-' =- C-oU 0 CT4o" E) r--UD o S- C) r- )-qOE- .C3 C 0 .- O S.4S.4,-- 4-' CD C o- C)CSnC CU ,~--U-L- n 4-), 0.-S-rL))L00 C) >-,C OmC C= S- C) - C) 0Q>) -00 C)Ln C) C:a.CO) S-M - ) ciC--) C c 4-U _ B:Ln·--. u _~ C) )0 >a 4J-> nS-O- = S .,- c- r 4-r ---3 t S- r- O r S.) , c--, 3 O (D,-a, a W. U -~J 4. · .li-- O Ot - . c- r ,- O 4~ -.C)a ~4-.C)C. ' -i4-'Er30. OC'- S" C-CO ' -0'Oo C)-*)J 4-)C)" L .C O 0 - * ) t -C)-.-r-ci to,--,--- C: S-r qE .r- COC) 0S-ACL> E--r-- 00(nC e C, x5- a +r: C)O v, C)Z U- *r-- CrMC-co o a) 4 CE -_ -'S-.C) C)(a O C)0) M M. C-445 -,- rCS- '- O-C S.-U-S- :- .S. C >. 4-'- 2 M E C: MCC) CO ci)C~~~~~~~~t~~~Or-O r-r0-' ' ,'- ~~~~oQC-0coM 4CM aC', r S.-C)0)r·- ·e~4- VCO0 C) 4 C) 4Ma n LE, 0Cr-Lm-'C' ,, 4----4- 00 04-'- "' C r . U,- E--C.)'-C) O S- CM 4--QC )-UX,'Co M .4)QC-"O -. .- *-> 4- -.nU0- 4LSS 4- j I- A - ,4----" "- ,-U .r"5.~ L S-C-rC)F_O' r rS - 4-- . M ,--C -0 -- > M 0)C C ) CO C < C)CC u tn qn'C-- i4- 4-·- C)4-" C C C- 0') C)4-'~~~~ C H-C C.5- =S- C))C C "0QC 'F- 0:C)CC-) tT4C C)C'L EO Ec -0r U - 4MC C C ) )0r- r-M- 0 C C) .- r-o 4 C _O4-''CEC E 4- r 4--)cc-- /-- ,r-* 5J 0 0 C:: e-0 CS- Uc) M M) .i- - 4 S- C ','-CC 2 0- 0cM Ca .) - U- '4- CD' ,- u I- CL -4--CC) 0 r-_C E UC)- LOE ,L -4 4-)O) : *ae) - -S- 0 0n a-l C)r--0.) M 0~CC) S r- r-- C) 4- CX - C- *r C)~ t.J1)C U-~i-CC .-u.-- X 4-) C,- *v-~ SZF · C0*r E1)(- -C -'. a-C0Ca k,LO C)) C) 4-i)coC- e E,)S-0 .aC ~~ ~ 04-:S.. *C: IA*' : : 0rt4-, >l ·C)C a--4--. C) (0 0 QC)r00XU , r OC · ci .i CO C u 4-' LiU C) Li) =) C) U C)C C2(C S. u 14-'-) = ,O--C S-1C 4- M- a -P L 4-' > U,r-C) = ' - C U C*r- a C co 0 C),M :> c)v M> Ur- 40C -C)0 E C)O.rS- - O)-r->' C ) MO a) S -: co : CC: a;='- C+-C C C.e C) = C~oP O'C 'a -r-E Et 3 4aU 4C--cPr- Vt - Vt0 C E 4J 0H = C- · 4-.0 - .- S- C) 4..C o -4.) P c 4.0C104LO CDCC-C(A)0 >C C 7-,--W > C : r -~~ r- C J CW : r- S-.r-0 C: U C -- 4S-.- O-'r* 0 r 5. IC S.a --,= U E C) (A-. . > C ) CZ C)04CrC O U X - JtoC C ()rC4OCC) V r -a) 0 4 beM- 0iC> C-~ ' 0E+'1 S e) )4-'4-aCCto .-/aC-4-L -- .C II.- +-la=- C-- 0)CS-.r-C4- aC S- S~-0) v 4-Y .-IS ._C) IS- 4-0C--'. SM-- UC -- :) LO C S-U 45.-'r-j E M0 0S- ' O 0O- Ve 4C0 -: C) -c 'CC) *r4-23 )0EC - C a aC)' c 4C 0-0 V- 04'CL'- n a: , >,-" f- MLMta) f-0 -.-L -: '-'- 0 - u ' Q) - C,.--r--I- C. >1 E OE ~ C0 11i 4_ v 4-)O00) Lnr,-C '4-- 0 C )- = 4- 4-0 C L) 4- M -- 3 c-V ·2r-- · :a: -- I4'4-'E( 0)0 4r4 - 0 -.- t C - > L-n c )0C.- ---CC - C4 -' r-> C-- 4- 0 C)- O 0 LnS- 4-~ .r- 0C~')C)0E CV E4-.--4C-> 0(00 (D(S-4 0~4 MC-)n)4- M CO(0CCLnr4-) C) 4-'U 0 0 4E C) C) >0 4- C Ln aC) CA --) CO 4 a O 4 ·O4 S0 CS--' M -Ona4- ' '-'- 0 · '"+-C0~ C---:.r-.0-.-SC ~ O CSE -V4 4. 0-C -> >-: 4-Pr-c)O-> 4-, > 4-) S-CE/ 0-I 4-) - ) 41>S.-.~CIZM - O= 4-C 4C NUrO ) 4Z0L I - 4--'4 _- EL 00r-C)(M=m. -4 _ M S- (t~ C)C))S.C)4'- C J C)C 4': -iaLi- C 0 0)C) 0) U)-CM4- a S--r- > CS ' ( C '0 --a U0 ,'-- Lw .- C C - 4'-. 00 COC- : C- 4E -- C-) U- . S-C) S- CZ 0 4-- S- -0 , r0 .- .-E Q) C) Maa 0 C)) ·ha 0 4-C LZ~~~~~~~~~~O: > C;- -0 4-J S- 4- cc+j c U r- .?- C) 0 C-' O -0 . a E~ cn 4-cr In W E C C) C) > u cA 4- L) C) tO W V W S.- W 4L' ) > 0)Oa 4-'=C 4- 0 t 4-) .- Om au L - M S-17 V a ) > = ti C co = -C O0 · >I) 5.- C~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 00S (04-'-~ C 0)a 17 () U, . _~Cl, a) 0 0 DLL ~~~~~ o w~C-o~ ~oC . ~~~~~- r= l3 xs>) Sm C·Z cn >, E _~.-- 0 ^- a> _cs 0 V !.>o9 0 o:- O oN I CII c U >00 0 CD0 CZ>0 aoo000 .a) o o 00w .5 c- O · ro~~~~~~~~~~~~~~~~~~ · 4-' -> S- O ( C') cr. - o a) C* 4 - m" · ' (-- D. -- 0> 0 .O o n O c" a. - - CO -) 0E :0- (1 : r 4- CO E r>04- a- $-4 C t 3~- t -- - W < Qd v, aJ aB C E 0 4-3-t > 2r . - O >- a * ,-- o .W - N ' . - x 4 a) C= C- a4 a) * * 00o a *r C.C *r0)C aC)(aC,-- A L.) 4- O ,> ~> r., >(oJu ~: ~ U r C)C Ca a tn C)o : rna r ba') *"r -* -- > s I) cm. E a: L -f *U5--r- ( U *- aQ a) ru 9 u E 4- > - -3 > S- > 0 >aC , 4-) C,t a, - L - E a0) ' , -= t" a.V =E (_3 C F.-C- SOw - W - Q a) --O - - E'- o : > 4 - .r > S, - a, u)- -- 4-)-. avQ) 3 $4 Co A 3 *CUt a( *_ -.-L -N a-C.) aJ E r- 0 0 3 > 3 a4-): r4 *_- - - - - C Q *_Z -- --L S- a) . 0a 4C Vt ' ',-'0 C 4 N * _- *- a. to nU ' * (2J EU-r- ~'O - - O -. '-: a - *r E 4-2 O ·*- - o( 3 *A E *_4 a: r4 m av* ~ E-2C s. Ca4c >4- U o ' O >t *-. s--- - * - o '·r- o00 CII- U L co- co *_ + (n ^) 4L- *_4 - ) C > o ti-0*+CD u- = *tav, u)- O C.w ro > 3S ·t 0 OOW 2 4-34CO0 0 0 L) 4- at- 4-) C)C ' EoP-) o-.- O o v .C) .~< OS- t0 CWo 0 :- L)o O O c,Ca ven- 'CC~ ~ L E_4- 4-) = o 0 =-0 4-o -0 =o C 4-) o O aC) 4 -.- * CD o -r- .r- a · - :: - *-UJ' v, -C= 43 V)Er ~- ^ v a,to J ' a) ES - 4- ) t S-Q E 0 0 -'C - 4 *r -a ON S . S- CO^ -U U r* aWO ar LL a ' >4--C)C C C co CO r - C^ 00 O S> .- m -a >, 0O mr - O -r (r - m - (A 4 )r 4- - 4-) -o CZ t a 4-o > C * C 4-)' u = (nA 0 .- 0 C 0 o C) a) aJr C Q) ..J. a 0- = L-) O .5- - co 0 *r> > ( r 4- *r4-_ a0 > r - -- - 3 .E0 O Q S 4-) L t 4r -- -) U o -v CO a) SW W2 -* *0 $- r o ^ ac00 ; *_ * Q 4.. C CSQ v (, c c)o . .. * 4 S.- -C-C C A ~r-C 4( 0 ) U 0 * S- a O 3 a s) L 4 C 4-- A-- E- > S. co) 4 Eo C4-' 7S- C O-co 0 - _ 4- Or *_ 0O * oU ra o4- - Po C)O Uq = * _ 0CD O IC *--a co m S v-2C LOo 4EavCU t--:s- 4- 0 0---> -- (u a) a O * ) C) r) a Sv ; n C Sn 3 4- S:1) ' C) 4r* rCC E a) (1 C E Cn c 19 C- CL 4o-' (.C, CL _1E _ > _ C' <) (f .) _ E -, c 0 J -..--_ . E I I *- 0 20 C SYSTEM RESEARCH AND EVALUATION: A SURVEY AND ANALYSIS BY David S. AZberts The MITRE Corporation 1820 DoZZey Madison BZlvd. McLean, Virginia 22102 21 C SYSTEM RESEARCH AND EVALUATION: A SURVEY AND ANALYSIS ABSTRACT The Assistant Secretary of Defense (C3I) has, during the past year, established a new Directorate in his organization to develop and implement DoD-wide initiatives related to the quantitative analysis and evaluation of C3 systems. As initial steps in the development of this program, MITRE has conducted a survey and analysis of selected DoD-sponsored systems re- search and evaluation activities and established a C3 Systems Research and Evaluation Library. The Abstract and Executive Summary for both documents on which this presentation are based are attached. Readers may obtain these documents by contacting the following individuals: For: C Systems Research and Evaluation: Survey & Analysis John Gasparotti The MITRE Corporation M. S. W354 1820 Dolley Madison Boulevard McLean, VA 22102 For: C Systems Research and Evaluation Library D. W. Hodge The MITRE Corporation M.S. W375 1820 Dolley Madison Boulevard McLean, VA 22102 22 TITLE: C3Systems Research and Evaluation Library AUTHOR: Diana W. Hodge DOCUMENT NO: MTR 80W00357 ABSTRACT: This document describes the C3I Research and Evaluation Library, a computer aided data storage and retrieval system which includes a data base containing C 3 I related documents. It provides: (1) an overview of the method for categorizing and assigning identified codes to each document in the data base; (2) instructions for using the C3 I Library's data retrieval system which locates documents and prints out pertinent document information; (3) appendices containing indices for manual document retrieval when a computer is unavailable to the user; and (4) a biblio raphy of the documents acquired in support of the C I research and evaluation project. 23 Executive Summary The Command, Control, Communications, and Intel- compact form in Table I (Code Reference Sheet). The ligence (C31) Research and Evaluation Library is a data classification system for coding each document computer-aided data storage and retrieval system. The entry is explained in the section entitled "Data library was created in support of MITRE's C31 Systems Classification." Research and Evaluation Project sponsored by the In addition to providing the capability of selecting Office of the Assistant Secretary of Defense, OASD document entries by subject area code, the data (C31). This document is intended as a guide to under- retrieval system is planned to have provisions for standing the system of categories used to retrieve searching by title, author, corporate author, document document information that is of interest for specific number, sponsor, date, point-of-contact, and purposes, and as a user's manual containing proce- keywords such as subjects and names, or any other dures for using the C3I Library's data retrieval, review, information contained in the entry, including the docu- and print capabilities. ment abstract. Again, this is done in a simple English Each document entry in the library has its title, format generally by entering instructions to search for document number, date, security classification, au- the item of information sought thor(s), corporate author, sponsor, agency, and point- For those readers without access to the computer of-contact identified. In addition, the content of the based retrieval system, three appendices are provided. document has been categorized by codes indicating Appendix A is an "Index for Document Retrieval by the subject activity, mission area addressed, service Categories" in which all documents are listed by entry agency concerned, purpose or anticipated use for the number. For each entry, the applicable categories and activity or methodology presented, its place in the codes are indicated. By searching along any category spectrum of research and evaluation techniques, the row(s), the entries corresponding to that category or C31 system component(s) discussed, the methods of combination of categories may be found. Appendix B evaluation used or presented, and the current status of is an "Index for Document Retrieval by Authors" the subject activity as of the date of the document. where document entries are sorted by individual au- These codes may be used to select those documents in thor. The entries themselves are found in Appendix C, the library relating to any subject area or combination "Bibliography of All Document Data Entries." There, of subject areas of interest. Each document entry also computer printouts of the entry data for each docu- contains a short abstract to provide the user further ment in the library are reproduced in entry number insight as to its suitability for his particular purpose. order. By this means, the entry data (including ab- The document identification information is stored in stracts) for any documents located by a search using an interactive data storage and retrieval system using the index may be examined to determine if the the IBM System/370 MITRE computer. User access to document itself is applicable to the researcher's needs the system will be established in January 1981. Docu- and to identify it and its source. Both the category ment entries relating to a specific area of interest may index and the bibliography are in entry number order be retrieved by entering the appropriate identifier so that new entries may be added as additional code, or combination of codes, so that entries corre- documents are received and processed into the sponding to those categories will be selected and system. displayed on the computer terminal and/or printed. The C31 Library at present contains enough docu- This selection process is simple: the user responds to ment entries to show its abilities but is by no means all- clear English language instructions and options offered inclusive. Readers are invited to submit appropriate by the program. No knowledge of computers or the documents for inclusion in the library by completing data retrieval system is required beyond that of the the form at the end of this document appropriate code numbers, which are supplied in 24 TITLE: C3 Systems Research and Evaluation: Survey and Analysis AUTHOR: John Gasparotti (Principal Author), Diana Hodge DOCUMENT NO: MTR 80W00356 ABSTRACT: This document contains the results of a survey of activities and organizations engaged in research and evaluation of command, control, and communications (C3) systems. The distribution of such activities among the services and agencies of the Department of Defense is examined, as well as the relationships and connectivity of activities and organizations. Prin- cipal areas of interest include how the activities contribute to research in C 3 theory, assessment, and development; as well as methods and measures being used to evaluate C 3 systems. Finally, the activities are examined as to their contribution to the overall DoD wide program of C3 systems research and evaluation. Positive attributes and initiatives as well as areas of concern are concluded. 25 cd - = o W O- CV321 ) at CDh a04 C · h M m C C E0 U5 ( c C >) ). g)O $( ) > L bD C r r 44 O Z 3r 'ii; ho O ed ru~~ ~co 5 C C M 0 ) (a ' ~~SO;.ECC r" V~N 4 J , r.., (L Q, .--o t , +" E Z O - Q~~~~ ~r mrOE ~eO-Z O E c ro~ct 'F;I ~~ ~~ 'a o M O cl-044 i t m 4 E +j 0 O 4.4 9 E bc o " , OOE~~~~~~~~~~~~~~~-O9.+ - ed0 5 +J MEC bo0 0 0 Z 4., r ,C ·~~O C~~A (M C +j > E +j o +.a) 0 +5 ~: .- O CO ) a O a clc~~~~~,,o~~~ +jCS -i d wr-3, o O = E C . O O tQ O 05 E r 4- O44 0 O O 3C 3*bb ad C 0 +-''tl0_ aJ at C1 O)~~~~~~~~~~~~~~~~~~~~~~~~C a ;:· a tn~r012*J O A COla 'a 0 Cc o , r c C , C 05 aEEcad 0 CZ~~ 0 C)V . a) S v, E v C cdD O D. h~~~~~~~~~~~~~~~~~~~~~~~~~ E ° 4,0 0 >O O· &-0 ·- r me $ u e~~~~ E EI~~·3 ~- 4-i0 ~.~ O' E 0 0 =( ., E.m E1 co ~0~o. +j~~~:-0,.. Q~~~'I0 3 ~~~04- 0 0 0 a=a ,., ~E~7lifi Q, ad ~cd~CI O LO· aO c CA C 0 a0 4- 4 O03 o +jO .oo E .-w-OJ c, ~ = o~~~~o~~ .- N' O "'~~~~~o4, ~~V10... e ,.. 0OC 0 O 0 C9CL0 . 0 4 Ii 0C O>> a 0 0 0 >.. =~~ =.~~~~~ P-U ,4' 0-4E~~ C~~I)co OCs ~" =m 04;1,>v.C to -.-.~~~, 0 4 o v~ V.0M E., E 4-j 4-5 E:, 4 X, 0as EcuCC 4 4 0M O 3 .- ·.4 Pa 'a.- C)cd 0, Q 0 E co~hC , c ad C 0 Q) 4 -- Q) +5 C(3Q) C1 0 C'..4 Q> ). co ) 0 0 4c5 > co : 0>) r . a, a cb a) r,~~~~~~~XC r . W 0 O' L~~~~~~~~~~~~C"~~~+;)" eE U? 4 O-6 4 J M()bl L 0 r/3~~> 0 0) 0) O - + t- % as ro X CY %4 0 3 C h ~w·r ~ d ~a) C ~ O co O L, 3 M E w~~~·I )E ~Q O .6 E. M c > c 4-J c = E C 0 M >,edCl v O 0 r. 4-0 O 4ed O C E w co +5 3 O w IC E *r 11CL 0 0-4 0 c > O C) E V. 4- C t-, O 0 m 0 bDS. o At O ) r ., --I . 9.D , > CL p Br b~ E C ed~~~ E 0 c o , +a m -J co: ) E > m mP A~c C) ;,0) .- ~Z co O > +j 0 Mto 0>O "~ 0 I - Ce m 0r~c C c~ 3 cu r a c ~ s o0 a 0 c: >1 ~r a 0 E >' t "Se,~~~~c, _ n a, e Mao O Q~ C26 > ~ ~~~~, .) &,, ,. ='o >., 0, 4- .~ .... 4~~~~~~~~ ,., .., C-S b .)I 8cE la a' S W. r-~ ~ ~ 4 "C'' "~~~~~~~~~~~~~~~~~~~~~~~~~~-' Oq '1q- . " " 0 C0 c: .. >~ ,,, = -- 4 ., 0 - ' ,.~-- m - mZ D.~~~ ,,.-.. (Z~~~~~~.f~E) to E'~04 > - COv-- cz,-. ~.. ~ ~ub Z~D- . - V.' '+"C ) -lid *- ~ .... ~So~ ~~~~~~ C W==~e~ : ~ = 4-a Z O O0 bb ,~=~ ~ ~~~~= ~ _-4r a4 0 0 C 0 0 Z 41 4-0 E - z > Q~. .~ " > O . " '~ ~ 0 a~~~~~~~4-a~ r 0 4-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~,- r.~ s_0~ ~~ 4- , (~~~~~~~~~~~~~~~~~~ -4,-4 la=- ~ ,,-J~8 V C CL~~~~~~~~~~~~ .,.. 4 0 .- Ij E IZ ~~~~~~~~~~~~~~~~~~~~~~~W ~ ~ O.'-,~. t~ o4 •--'•l~~~~~~~~~~~~~~~)Eo o 1 0 , ._a( t 0 .. W0 O M - 0 M W E - C)- : 4-1EPE E E nv.2Z7 4.0 -'~~~~~~~~~~~~~~~~~~-q f~~~~~~~~~~~~~~~~~~~~.,'-. Q - 0'D~,. > t,-~ 4D r.,l="-'~~ M 4,.. 0 ~~~~~~~ rn~~~~~~laWr ~ 4 -.d_CO .,,. O 4a .4 > .- ~~~~~~ %_4 > o 0~~,, 0 CO 0 · 0 0 c~'~~~~~~~~~~,~rn~ ~~ "-~~~~~~r 0' 0 C -~ "~~~~~~~~~~~~~qO~~~~~~~~~~~~~~~~~~~~~~~~~~~~~wq b. V 0 4)E v.atomb ....~~~~~~~~~~b b.b- 0~~~~~~~- Wn C= 4~~~~~~~~~~~~~.__CCi t 0 ~.. 4-i I. _- r4. ~,,.~~~~~~~~~~~~~~~~~~~~~~~~~4,. InbD = co co_,.,'" m.- = ;3~~~~~~~~~~~~ C'::-E 4-40 W0 - - Cs o W W . 0 .C W g4-0 4 -4-- 7 '" w E E' ot'E bO C ~~~~~~~~~~~.- v c + 0r.W . V 0 C ·~~~~~~~~~~~ 0 u ~ ~rn~ E bDr~~~~.~,4-'- ~~ ~ ~ ~ ~ >'~ E .'-4 ri, -- E 44 a_00. n=td 0 m Wa0. .0 cCd~ ... >,--~ Q);Q C:.d mcorn 0 e.0 -4 0 e~~~~~~~~~~~~~~J,J cot . .- W , 0 0 ~~0 4-- W 4 - J r n W W ~-~ cd 0C.0 - X W 0= bD w 0 , (DC00: 0~~~~~r E~~~~~~~~~~~~~~~~~~~~~~.9. ~ I 0 C 0 C)-Cl D 0_ W ' 0 'a "' W" >~ 4- 4).- 0V~W r~~E, ~~~~~~4,-.0C-4 ~~~~~~~~~~~~-, -_ . . : ,- W f. > C > t~~. ,, cov w .14 W~ ~ ~ ~~E o d to E E W 40,E 0 E_8 o S 0>> C 0 .A E 0 .- Yo0X o U -44 C E UC rn 4) r .'0 4) - 4_) r_ .8 0. 0 > .:w ,- ..>I..J >w- - C In rwo 4_ Cz >, 45 * E=; a, v *awo EY¢- 4- > co a tDSX En "- ¢-W Cow >It to °>trC °. c °: ,-4 lz (1 t ,wr X 0 n ° ° ° - 0 0 = E° vX._ , 2 rbo ·*j bD ) _SWc la bD*_ Sj R0-jwE4-, v 4)<,QcOC: ¢' ',u O -O 4). o- t..c:.~~ a)-)0 o~~~C 1- · 0.0>4.29 . 4-4+.a bn '.I r- ra 4- 30 THE INTELLIGENCE ANALYST PROBLEM BY Daniel Schutzer Chief of Naval Operations Naval Intelligence NOP 009T Washington DC 20350 31 LUO - - I-, wUF~L ~w U-U CLw 32 F < .- ,~~ >0 F- -,E CD cn/ k o _ t ~~z 0 9 < ~> 0 WN O ~LL 32 The Intelligence Analyst Problem - Dr. Daniel Schutzer 1. The intelligence analysts job is to provide information of military significance to the decision maker regarding the enemies movements, capabilities, plans and intentions. The decision maker ,should not be overwhelmed with all manner of minutiae regarding the enemy. Rather his attention should be focussed on key items of interest. Key items validate, amplify, or cast in doubt pre- vailing hypothesis concerning the enemy. They reveal enemy strengths and vulnerabilities which may be exploited or countered. They represent information that cause the decision maker to take actions. The intelligence analyst derives his knowledge from informa- tion collected from uncooperative sources. He predicts future enemy plans and capabilities from scant, incomplete information concerning past historical patterns and current activity and plans. 33 2. Over the past decade three changes have occurred that both complicate and add importance to the intelligence analysts function. The relative military strength of our adversary has increased dramatically both in quality and quantity. Our technological leadership has eroded to the point that in many areas other countries not only equal our capability but exceed it. Finally, the nature of warfare has increased orders of magnitude in its tempo and sophistication. Warfare has become faster paced. Today's weapons are more lethal and more capable. These weapons are equipped with a bewildering array of sophisticated sensors, alternate modes of operation, and countermeasures to confuse and defeat the enemy. They strike and faint rapidly given their opponent little time to react and counter. This all makes it more critical than ever for our decision makers to be armed with good timely intelligence. But, at the same time, this intelligence task of compiling and providing quality intel- ligence has become much more difficult. The enemy doesn't merely mirror our capabilities and tactics. On many fronts he leads and innovates. The situation is not static, it is changing with increasing frequency. To further complicate the problem, the enemy is quite adapt at playing the information war. He both denies us key information and deceives us with false information. To overcome these difficulties, we build ever more capable information collection systems. And, our "take" of data increases both in detail and quantity. But, to a great extent, this further compounds the problem. Data comes in by the bucketful, but, it comes uncorrelated with important gaps and flaws. And, the analysts burden of compiling, relating, processing, and reducing this collected data to timely, useful intelligence increases in magnitude. Currently, this task is man-power intensive, strongly dependent upon the skill and insight of the individual analyst. It is analogous to how the great Sherlock Holmes succeeds in piecing together seemingly disconnected clues to solve a mystery. This talk argues that there is a systematic methodology under- lying the intelligence analyst task. And, that once found and made explicit, this systematic methodology will both enable the analyst to do his job better and will allow for automation to relieve the analyst of much of his workload in more fundamental ways than would otherwise be .possible. So long as the intelligence analysts task remains highly individualistic and unsystematized, automation can only minimially alleviate the analysts workload. It can only be used to aid him 34 in his secondary activities such as editing, producing, and deliver- ing messages and reports, displaying and producing pictures and graphics, storing and retrieving data, and the like. It is believed that the introduction of a systematic methodology will enable automation to be more directly applied to the primary activities of the intelligence analysts, resulting in much greater gains in analyst productivity. 35 LUA DaW 0 ~~- 00 -C W L3 LU ... ~0 C w LU LII L-- LF 0 I- O Aml AVk CO 00~ ~J _c0 0 0 0 ' 0 36 3. I submit that the intelligence process can be modelled as shown in this viewgraph. Data is collected, transformed and interpreted in terms of one or more hypotheses that the analyst has consciously or unconsciously formulated with respect to the enemy actions and intentions which he is concerned. The collected data is used to confirm, refine, and update his ,current prevailing hypotheses; to select among several competing hypotheses; and/or to formulate new hypotheses. These hypotheses are then projected and extrapolated to evaluate and interpret future collected data. Once a hypothesis is formed a drastic reduction of data can take place prior to any significant-processing. Only data items directly relevant to the hypothesized models need to be analyzed and retained. All other data elements can be filtered out. It is the thesis of this talk that, in the case of the intelligence analyst problem, the only relevant data elements are those that are needed to maintain the five knowledge base data models shown: Sensor, situation, event history, timeline- interaction, organization. 37 I- OU kO z 0 bw kk0 Z · 308 . ... Ibi Z ~33 Z3 ~.n L------, 0______4. These knowledge base models are related or linked to one another. The major data elements and their various interdependencies are illustrated in this viewgraph. These dependencies can be used to crosscheck and verify a data element entry. They will often times suggest what value a currently unobserved data element should possess. The specifics of these five data models, their data elements, ,and their interdependencies form, in essence, an explicit repre- sentation of an analysts hypothesis. It should be noted. that although this viewgraph emphasizes the enemys military warfighting capability, the same approach can be taken to understand and project the enemies science and technology capabilities of their R&D establishment or a civil terrorist organization. 39 P- 3: W F E '. > Di. 3%9-- ., "~- IP~ , ·y·-I ^ g3mICA OI~I~ le< l~Ja h4<_J m F 4 O ! ;~'::,' ~ '=" ~ ~ .l ~ . . . ~, -2 : ~1, 6 E '~. ~ ~' ,, I l ~ F F'i ' Q g_<. *...U:_.A.,_._....z 40 ~~~~~~~~~~~~~~~~~~~. ~': j * * t- X------o_ P i~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~i 116-~ L: i .'~ Q' s , '" . . . . W ~~~~~uiWoC"- .. o sail~~~~~~~~~~~~a ihj~3 U Q~ B p~LU jr~~~~~~~~~~i~ ~ 4 ~~~~~~~~~~~~~~',, -,-~. ,:,.,-_ l l :O--z-'" -,,'~-.-. . , -' s ...... I. 7? Z Z... ~ ' \ Nwi" ...... / - ~ ~,' '~ ; , ·. ' :3 <>1i~F: U3 \ -k aLn=>4Xv 5. To illustrate let us consider the case of a strike mission against ships either in transit or at port. For this example we will concentrate on the operational aspects peculiar to the mission: Namely, the organization and the timeline - interaction models and their major data elements shown here. Once these two models are established, the sensor model and the event history model are determined by the detailed physical characteristics and capabilities of the sensors and platforms involved. The current situation is scenario-dependent and will not be discussed here. 41 - i LUisl~00 n0 4 42 6. For the strike example it is assuemd that there are only three organizational levels involved. Namely Fleet, Flotilla, and unit level. And, three type units are involved: Submarine, aircraft and ASW surface ship. 43 LU W O0 ~'?~" ~ W- " W -SU Iq e ...... 7. A nominal operational sequence for the strike mission example is illustrated here. The mission is broken down into its component functions. These functions are related to one another in terms of their interdependencies and their relative ordering with respect to time. It should be noted here that this example is purely illustra- tive in nature. The functions shown are not necessarily inclusive or in sufficient detail. The nominal times cannot be substantiated or validated. It should be noted that the nominal times assigned to a particular function are not necessarily a single valued constant quantity. They may be more properly represented by a random variable or a permissible range. Finally, although illustrated in a flow chart format, this same information can be readily repre- sented in a table format more adoptable to computer storage and retrieval. 45 ! - X E n · " egyq I t W et-B - 1 5" 0 -d ,Q L. ..U LU iomui L _ 0Ff- IX )OII '.~~~~~~~~~~~~Cs Il~ 1 a - ' tJ - -Z. CD , C: ~~~bWLJ Q LM I '"'"'" " I~ Lo~~~o~ W ~ 0 0 'Lu~~~~dc LLJ a .2"~~~~~~D. . !:~ -> l- , 4~~~ [-~,I< m !. a ,..w 0<~ ~La L O i~~~~~~~~~~~~~~~~~~~~~~u (~~~~~~~~~~~~~~~~~~~~~~(LU~~!.~0 6~~~4,-O~r 9 tt i .I w iu- ~'ZZ.~ - ( Z LULL CqIh~i L"" I IL3 ,C') . .- e L) .. u LL- LLJ C l Cn W uiWr P~ trCL k CT LdlL 46 8. Once, broken down to its component functions as indicated in the previous viewgraph, these functions may be allocated among the various organizational elements and units. One such functional allocation is illustrated here. 47 - 181 x X x -9 X XX X X 0 '~x XXX X X 48 9. This next data element deals with a very significant issue. It is assumed that any organizational entity assigned a function to perform has associated with that assigned function an objective. This objective may only be implicit. But even if the executing organization is not consciously aware of it, it unconsciously bases its response and approach to the execution of its assigned task to some underlying objectives. Implied in this association of an objective with an assigned function is the belief that the behavior of that organizational element in the execution of its assigned task can be represented by an appropriative normative optimizer or satisfier process. This process includes the interaction or output response of the organization to its inputs. An example of such a set of objectives for the strike mission is shown in this viewgraph. In real life, these objectives may only be approximated by a more practical or expeditiously implementable normative process. In the interest of simplicity or time, or conservation of resources, the actual process may only seek an adequate solution from out of an acceptable set as opposed to a single optimum solution. In fact, the selection of a specific solution from the acceptable solution set may be best represented by a random process (e.g. some statistic game theoretic solutions.) 49 i-~.o ~~L ; [ .MJ.. 0 ,0 tX j mj -- I·I£-m II!U W . > - ^, , -,. 50 L11A . Q1 ______12E~~~~g·~ a L~o .S__ , .... laO J3 0 K W:- v . ,4 U X LU~"~·a ~~~rw ie ~t~9 CY)O 10 C^YL) 5 0 e 3 ~ 10. The interaction model represents for each organizational element: Its memory or knowledge base; its assigned functions; and, for each assigned function, the required inputs and applicable responses. Clearly, the normative process for an organizational element can be derived from its assigned functions, their associated objectives and their interaction model. The next three viewgraphs illustrate examples of an inter- active model for the Fleet Headquarters, Submarine Flotilla and submarine organizational entities for the strike example. 51 0 m w rz o . H.. w >, J . < 0 ,, -- I - U .L, 2m y __ _ LU a i I O i 12 - I|. , ' -- L5J| o-- F 2 1 - 1Ho:~ I ' #A ,t ...... ~-'-0 0 w ,-- 0a : ? | -uJ O X52 J ~_ ~ ~'. H I -J 00- L a ic:. -J ."-' LLI I.~ ,.O)i U_ 5oh _ ' T _ __._ _ mo o W3 U ;, -. .U I-,~¢ Lu L 1 00 .i j; VwI¢'0 I 0 4 ri~~~~i~~~gI:0 0 ~~~aa~~ ______t L C:: Lq:bdm 0 U0 u4 IC) c~~~~~~~~~~~~~~~O~ ~ ~ ~ ~ ~ e ~,Jk,~,,~ - . LLS U';. L. '· ~, i , O I ~~~~C) >~~~~I I...... ~ii ~ !i :) ...... ~ ~ z: d~~C Lu < , A ~~~~~~~~~53OwU , ~9 0 III ~Illl I I Illl dlI1,%I In Ill]Ill L~g jmlnil~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~dk1 , ~ iifrw~ -Jet ur ~~b~I ::~~ r~a b5 i iii iii iiiii i i i i i ii i iii i" !.- ] 1 i i i -E~k- B CL.I-d ~Ic I , ~I ,L 11^ ~ ZP- - 0"f CiCO ( I r:tfl 00,, .9d > -l B -0 f~L54 _ I_ as- _ _ t~II~ L OLU X -I-*. C4 ) O2: J co ~ 11. Now let us explore how application of this systematic methodology to the intelligence analyst process might lead to more effective aids. I believe that this methodology aids the analyst by more consciously arranging his knowledge base in a formal explicit representation such as the five data models suggested in this talk (i.e.; sensor, current situation, event, timeline/interaction, organization). By adding such discipline to the process we make more evident to the analyst what his hypotheses are. This should help to focus his attention and to make ·more apparent which are the data items most deserving of his attention. This structure should make more obvious where the important gaps and inconsistencies in his knowledge base remain. It should highlight where the important collection requirements are. Explicit representation of this process should make possible a more comprehensive approach to automation and the introduction of analyst aids than would otherwise be possible. A great deal more of the data reduction and evaluation tasks can now be automated. We know how to transform and associate the data with respect to the specific knowledge base models. A great deal of irrelevant and/or redundant data can be recognized automatically and filtered out reducing the information overload/ saturation currently experienced by the analysts while minimizing the likelihood that key data will be overlooked. Another benefit is that once formulated and stored in a computer, an alternative hypothesis will not be forgotten or overlooked. A computer will not forget. All viable hypothesis will be continually stored, updated, and compared as to applicability. Furthermore, a computer is free of any human bias. It has no favorite hypothesis. If a secondary hypothesis suddenly becomes a primary candidate based upon new data, this unexpected change will be caught and brought to the attention of the analyst. Likewise, if a favorite hypothesis begins to lose its viability as the result of new data and changing situations, this unhappy fact will also be persistently pointed out to the analyst. Examples of how this methodology may be applied to aid the analyst process is illustrated with three generic examples. 55 LLj 1,:-~~1 2© 0 W-J~~A W L LU ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:1, I~~ :~!~~ds IJ- CA ~ mi I3 AMA~~ mmm-ii 56 a ~Mai LU~~~~mi mi miUI =Sip~rt r ~i ;i LIC9~~LI. W giBM I~~~i M p t)--j k ~ 56 12. In example 1, it can be shown that the functional allocations can be derived from complete knowledge of the organizational structure, the organizational objectives and their interactions. Knowledge of this data and the actual communications, sensors, and weapons systems technology employed determine the operational sequence timeline. Thus starting with complete knowledge of the organizational structures, objectives and interactions, a hypotheses can be completely substantiated. Other known data model elements can be used to check consistency and validity. 57 r- _i I·- ~a i 8e X (6 Itv8 i. 3P- k g> > d I-3 ' I. - _ 58 13. Complete knowledge of the organizational structure, inter- actions and the operational sequence timeline is not sufficient to uniquely define the remaining two knowledge base data models; functional allocation and objectives. Consequently candidate functional allocations and objectives must be hypothesized and tested against past historical patterns and future data collec- tions. Automation will allow the analyst to handle more hypo- theses than he could manually but certainly it still will not be possible to exhaustively enumerate, store and test all feasible hypotheses. It will be necessary to choose and select only a subset of the universe of feasible hypothesis candidaotes. The heuristics associated with-the analysts expert knowledge base can come into play here as rules, strategies or procedures for selecting, pruning, and rejecting among the set of feasible hypotheses. Based upon a given hypothesis many of the existing gaps in the data models elements can be filled. Concurrently, known data models elements can be filled. Concurrently, known data model elements can be corsschecked for consistency and validity to rank and evaluate the likelihood of a candidate hypothesis or to identify the possi- bility of purposely inserted false deceptive information by the enemy. 59 : WW 0< Z gMz ...... '' U9,...... W X a 9 " 2 < [ Fb n nj$S0t! . , 41 F W lL;. f% @>.S 60. 6)EU362 I-c3 " 9~~~~~-p1~~~- · -~~~~~·6~ ~~~ 14. Example 3 is the most general and representative of the three cases. In this example, all of the knowledge base data models are understood partially, none completely. This case can be handled through an adaption of the methodology just previously discussed for example 2. The recommended steps are illustrated in this viewgraph. General interactions of this procedure for a given set of collected data may prove useful. 61 15. This viewgraph provides the caution that the collected data used to develop and refine our knowledge base is noisy, incomplete and random. Not only are the input and output observations fundamentally noisy, but false signals may be injected into the process. Further, one should be reminded that the decision model used as part of our knowledge bases hypothesis is based upon an assumed normative process. The outputs observed are the results of an actual instance of a specific real life decision maker. Accordingly, a hypothesized decision model must by its nature be somewhat fuzzy. The actual decision process will be somewhat unpredictable due to the individuality of the decision maker involved. Further, as discussed earlier, the decision maker may choose to work with acceptable ranges or values of the parameter and-not with specific values. In this case, the actual rules and optimizing strategy themselves are inherently fuzzy. This suggests that the pro- cessing and matching of collected data to the hypothesized knowledge base and the subsequent updating and verification of this knowledge base is best approached through statistical means; e.g., statistical confidences, estimations, and clustering analyses. 63 16. In summary, it is felt that there is a systematic methodology underlying the intelligence analyst process. That the explicit delineation of that process identifies a set of tools for the analysts that will assist him in a most fundamental way allowing for signi- ficant advances in both his productivity and in the quality of his output. And, that these tools may be represented by the areas indicated in the viewgraph: Candidate hypothesis optimization models and techniques that relate the knowledge base data models; Storage maintenance and representation of the multiple hypotheses data models; Candidate hypothesis selection heuristics; Candidate hypothesis search and pruning aids; Statistical estimation, clustering and pattern matching aids. 65 DERIVATION OF AN INFORMATION PROCESSING SYSTEM (C /MIS) ARCHITECTURAL MODEL A MARINE CORPS PERSPECTIVE BY Lieutenant Colonel James V. Bronson United Stated Marine Corps MCLNO Code 033 Naval Ocean Systems Center San Diego, California 92Z52 67 INTRODUCTION This paper proposes a generalized command support system (CSS) reference architecture for military information processing systems. The proposed architecture is derived for the most part in the paper from basic definitions. U. S. Marine Corps and Joint Chiefs of Staff (JCS) documents are used as sources and examples because of the background of the author. Other service publications could be applied instead. The underlying premise is that there is an abundance of documented structure for describing the process of command and its support. The difficulty is in establishing the availability of the resources and translating them into hardware/software entities. A reference architecture has multiple uses. First of all, at a concep- tual level, it would describe the totality of information processing needs - or as close to it as we can achieve. This becomes especially important as the command, control and communications systems (C3) and management information systems (MIS) come together in terms of requirements for timeliness and information content. C3 systems have dealt with weapons direction and perishable information. MIS were batch processed, - not so time critical and seldom interactive. Force status, for example, usually determined by logis- tics considerations stated in the MIS becomes critical for the planning functions of the C3 system. A reference architecture has utility as a management tool. As systems are specified, managers require a vehicle for displaying the bounds of their charters, responsibility, and authority. Likewise, there is a need for a reference in assigning tasks to subordinates and describing interfaces. A good example is the need to state the responsibility for budgeting to meet particular interfaces. In summary, the reference architecture provides a method for audit to insure that all costs are recognized in considering the process of command. At least, inclusions and omissions will be intentional. A reference architecture has utility for training. It provides an aggregate view of the information and processing facilities which a commander must have. It provides a means for describing the scope of the information used by the commander to potential commanders. Likewise, non-military managers building military systems must occasionally be educated in the process of military command. Their management of resource allocation might well benefit from a managerial structure paralleling command organization and partitions. Engineering staff working on military systems should be trained or educated in the process of command. The messages the systems process and the processing algorithms derive from the process of command, so a good background will be most helpful. A reference architecture will support system specification and engine- ering. It facilitates bounding the hardware/software assemblage. Relation- ships to other systems are obvious at any level of detail required. Proces- sing within the system can be related to the functions of command. This paper attempts to differ from many others on C3 in that it takes the acknowledged defintions such as "command" and "staff" and uses them as the basis further processing of the CSS problem. Command is treated as the 68 process of managing the production of armed force as a commodity. The management is a flow through the steps of planning, organization, coordin- ating, directing and controlling. These are common processes. Particular emphasis is given to definitions which avoid the use of the word being defined in the supporting definitions, some of which will be used as examples. An information processing system model is used to more completely depict the command processes and its workload. Staff functions are developed as the military technique for a work breakdown structure so that the workload can be assigned to multiple workers. Around the clock functional continuity is provided by centers in those areas for which standard processes can be defined. Centrals are introduced as hardware/software aids in the centers. Finally, the layered architecture is presented as a basis for describing specific interfaces to be addressed in creations of centrals. These seven building blocks are used in creating the reference architec- ture, sometimes called a model for simplicity. These are in a list format. 1i. The commander and command 2. Processes of command 3. An Information Processing System Model 4. The Staff and Its Functions 5. Operating Centers 6. Centrals 7. Inputs and Outputs In summary, the commander's processes are used by staff functional sections which are required to perform the volume of work. These staff sections in turn create centers for continuity of operations. Centrals are acquired to support accuracy, timeliness and cognition of information. Interface definition is required to insure that the staff sections, centers, centrals perform adequately in parallel and serial processes. An example uses the derived reference architecture as the basis for describing and comparing some aspects of the Tactical Flag Command Center (Navy) and the Combat Operations Center/Tactical Air Command Center (Marine Corps). Conclusions finish the paper. THE DERIVATION Since we are dealing with a reference architecture, what is an archi- tecture? 69 An architecture is the specification of the relationships between the parts of a system. The introduction called out the major elements. This section will attempt to deal with the details. Building Block I - The Commander and Command The first building block is the concept of the commander and command. Command rests in an individual who is the commander. The following descrip- tion is extracted from Fleet Marine Force Manual (FMFM) 3-1 - Command and Staff Action.2 COMMANDER "The commander alone is responsible for everything that his unit does or fails to do and must be given commensurate authority. He cannot delegate his responsibility, or any part of it, although he may delegate portions of his authority. In discharging his respon- sibility, the commander issues orders to subordinate units through the chain of command which descends directly from him to his immediate subordinate commanders, whom he holds responsible for everything that their units do or fail to do. The commander issues orders and instructions to his staff through staff channels." This description clearly describes a need for a "hands-on" manager. The Dictionary of Military and Associated Terms, JCS Pub 1, provides a more managerial text in the first of the four sub-paragraphs. The entire definition is provided for completeness. "COMMAND - (DOD, IADB) 1. The authority which a commander in the military service lawfully exercises over his subordinates by virtue of rank or assignment. Command includes the authority and responsibility for effectively using available resources and for planning the employment of, organizing, directing, coordinating and controlling military forces for the accomplishment of assigned missions. It also includes responsibility for health, welfare, morale, and discipline of assigned personnel. 2. An order given by a commander; that is, the will of the commander expressed for the purpose of bringing about a particular action. 3. A unit or units, an organization, or an area under the command of one individual. 4. To dominate by a field of weapon or fire or by observation from a superior position. See also AIR COMMAND; AREA COMMAND; BASE COMMAND." (Author's underlining) 70 Note that two of the four definitions are particularly germane to an architectural presentation. Definition 1 specifies responsibility and authority. It further addresses managerial concepts of planning, organizing, coordinating, controlling and directing. No additional amplification or definition of these concepts is provided anywhere in the dictionary. This deficiency must be addressed in this paper. "Employment of" encompasses the entire military art and science and is too aggregate to afford guidance. It is the object of the other five processes. Definition 3 talks to units: Units have capabilities as described in their Table of Organization and Table of Equipment (T/O and T/E) to create armed force. The T/O provides rank and skills of personnel required to accomplish the unit mission. The T/E provides the hardware to accomplish the unit mission. T/O skills are related specific- ally to T/E hardware. Several definitions associated with command are presented here to flesh out the picture. Comments are provided as to the utility of these definitions in creating a collectively exhaustive and mutually exclusive reference architecture. "CONTROL - (DOD, NATO, CENTO, IADB) 1. Authority which may be less than full command exercised by a commander over part of the activities of subordinate or other organizations. 2. In mapping, charting and photogrammetry, a collective term for a system of marks or objects on the earth or on a map or a photograph, whose positions or elevations or both, have been or will be determined. (DOD, IADB) 3. Physical or psychological pressures exerted with the intent to assure that an agent or group will respond as directed. 4. An indicator governing the distribution and use of documents, information, or material. Such indicators are the subject of intelligence community agreement and are specifically defined in appropriate regulations. See also administrative control; operational command." Commentary on Control. Control is interesting because the cited defini- tion (part 1) described in JCS Pub. 1 is a subset of command. Paragraphs 2, 3 and 4 are not relevant to this paper. Note that a senior headquarters can assign the control authority to direct a unit to another of its subordinates at any intermediate level. Hence we use the term command and control to denote that in the organizational sense, the JCS Pub. I attributes are met and likewise the unit or capability in question has not been meted out to another headquarters for direction. However, it can be argued that the JCS Pub. 1 use of control in the definition of command is more related to providing armed force in accordance with the plan or directive. Another view of control might state that the limiting factor is at the staff agency. For example, control functions related to maneuver are dele- gated to the Operations Staff and not to other staff sections. 71 "COMMAND AND CONTROL - (DOD IADB) The exercise of authority and direction by a properly designated commander over assigned forces in the accomplishment of his mission. Command and control functions are performed through an arrangement of personnel, equipment, com- munications, facilities, and procedures which are employed by a commander in planning, directing, coordinating, and controlling forces and operations in the accomplishment of his mission." Commentary on Command and Control. This definition of command and control uses four of the five functions of command (omitting organizing). Note that "Direction" is used as synonymous with control. "Control" is used in both the item to be defined and the definition. "COMMAND AND CONTROL SYSTEM - (DOD IADB) The facilities, equipment, communications, procedures and personnel essential to a commander for planning, directing and controlling operations of assigned forces pursuant to the missions assigned." Commentary on Command and Control System. The concept portrayed herein does not address the command functions of organizing and coordinating. Additionally, "control" again appears on both sides of the definition equa- tion. Building Block 2 - The Commander's Processes Further definition of the managerial processes (responsibilities) is essential to development of an architectural concept. These are derived from The Theory and Management of Systems, by Johnson, Kast and Rosenzweig. Plan is a predetermined course of action. It: Involves the future Involves action Has an element of personal organizational identification or causa- tion. Organize means to array material, energy and information to support achievement of organizational goals. (Every human is a source of energy and information processing.) Direct means to mobilize the flows of resources (material, energy and information) to achieve organizational objectives. Coordinate means to orchestrate the direction of resource flow to maximize the effect, but with cost considerations. It requires optimal resource selection, schedule integration and conflict avoidance. The object is to achieve mission objectives with least resource consumption. 72 Control is defined here as a system element containing a plan to achieve an objective. The elements consist of a controlled characteristic or condi- tion, comparison of the state of the characteristic with the projected state in the plan, and a mechanism capable of the required corrections. The fine distinction between control and coordination can be demonstrated by the idea that coordination involves only friendly forces without a direc- tive relationship at that echelon. Control, on the other hand, must account for and adjust to the entire environmental condition or state. It is based on the comparison of measured characteristic state with predicted state. Commentary on Control. It should be noted here that the common interpre- tations of the terms "control" and "authority to direct" are virtually synonymous, hence have little utility as the basis for decomposing and examining the architectural definition problem. TRANSFORM o (~SOURCE or SINK x _· o t PROCESSING L FEEDBACK CONTROL CLOSED LOOP (nSOURCE otutt (Hi OPEN LOOP Hereafter, control includes considerations of information exchange capabili- ties, and the plan. It is a closed loop system. "Direct" or "Direction" means authority to order and the process of doing so; i.e., an open loop system, and one way in the time interval of interest. The military application of control concepts will bear further amplifica- tion. In the tactical sense, control has two subsets. The first is a straightforward comparison of resource commitment (direction) to the projected time line of the plan (schedule). Examples of these are troop maneuver or preplanned fires. The alternative to this is a review of the validity of the plan in light of the current situation. Execution of the order may be retarded by intense environmental action, natural or hostile. Flows or resources have to be adjusted, e.g., on-call fires or counter-attacks. On the other hand, if objectives are achieved at rates greater than initial assump- tions would support, overall plan and schedule adjustments are required to seize opportunities. Thus, the dynamics of military operations require constant cycling of all five command functions to maintain equilibrium with the environment in the operating area. Likewise tactical control, in the systems sense, is the most challenging aspect of the command function. This latter concept of control becomes particularly important in the light of the idea that the armed forces of the hostile are likewise attempting to achieve 73 their national objectives by eliminating or neutralizing the capabilities of our side. It is apparent that feedback loops are a critical aspect of the control exercised by the commander. It does him or the nation little good to exercise absolute "direction" or open loop control if he is "out-generaled" and his armed forces are destroyed. In this context, he is constantly sensing his environment to determine whether progress is according to his plan. The commander's corrective mechanisms are applied once he determines that progress has varied out of planned tolerances. These include priority for supporting fires, committing the reserve, or presence of the commander, or he can change the plan to be more consistent with current perception of environment. These feedback loops are the most valuable part of the C3 system. If the telecommunications capability is very good, i.e., reliable, adequate capa- bility, secure, planning need not be so thorough and command can respond to a highly fluid situation. On the other extreme, inadequate telecommuncations require intensive prior planning and the ability to describe options and alternatives with minimum information exchange, i.e., red smoke or a yellow star cluster. Mission type orders such as the Civil War directive, "Move to the sound of the shooting," become most important. Trust in subordinates becomes critical and failure at a subordinate echelon can be crucial since the senior headquarters does not have essential timely information on which to base exploitation, reinforcement or counterattack. These polarized situations dictated by the communications capability have been characterized as open loop or closed loop. The real world will be some hybrid of the two. The viability of the telecommunications system is perhaps the most crucial assumption of the C3 system design process. Interim Recapitulation A concept for an architectural model has been stated. Additionally, the processes of command have been presented with emphasis on the individual responsibility and his management in the process of executing the responsi- bility. Control has been heavily emphasized. Building Block 3 - An Information Processing System The next building block is the model of an information processing system. A model is essential to considering the actions described in the definition as a process. The most generic type of this is simply input-process-output. A more tailored model has been proposed by Dr. Thomas Rona in a paper presented at the Second C3 Symposium sponsored by the Navy at Monterey in July 1979.5 An extract from his paper follows as the description of the IPS model for this paper. Note that links to the stimulus and effector sets are usually included (telecommunications). This model was selected because it separates the trans- form operator from the transform logic. The capability of the operator limits the overall result of the logic. 74 "GENERAL The command and control system is seen basically as a logical mechanism to transform a stimulus set into an effect set. The main components of the model are (1) the stimulus set, together with the associated references; (2) the transform operator; (3) the effect set; and (4) the transform logic that prescribes the action of the transform operator. The model also comprises the stimulus and effector links that tie these elements together but do not them- selves introduce significant logical transformations into the process. In this formulation, all the information that is legiti- mately (i.e., according to the intent of the system designer) brought directly or indirectly to the attention of the commander* enters via the stimulus route. All the C3 system effects chosen by the commander exit via the effect or effector route. For the sake of completeness, and relevance to C3/MIS, we should keep in mind that the transform logic must be connected with the mission objectives, which comprise combat objectives of weapon systems supported by the C3 system, and also with the combat objectives, if any, directly associated with the C3 system and its connected interfaces." (See Figure 1) This model can be modified with specifics, again referring to available procedure. The format for an operation plan/order is cited. FMFM 3-1 calls for major paragraphs (sections) for Situation, Mission, Execution, Administra- tion and Logistics, and Command and Signal. The Situation paragraph describes the friendly and enemy situation, including intelligence, as seen by the issuing authority. The Mission is the tasking to the commander by the issuing authority. Execution states the commander's concept and tasks his subordi- nates. Administration and Logistics (A&L) includes personnel and support considerations. Command and Signal (C&S) establishes key relationships and establishes processes for communications. The Commander must accept and apply the four paragraphs about which he can do nothing, (i.e., Situation, Mission, A&L and C&S) process them, and create direction which is conveyed in the following situation, execution, and amplified A&L and C&S paragraphs. The transform logic the commander applies is described in his managerial functions of planning, organizing, coordinating, directing, and controlling (POCDC). The transform logic likewise applies technical considerations such as weapons pointing calculations or aircraft corridor coordinates (commodity unique). (See Figure 2) *Unless otherwise specified, this term refers to the individual responsible for the C3 system operation. 75 v w w w 0 M.~~~~C O v,9 w ~0 ~~~~~~~L U S Lzz J~~~~~~~~~w -i QI ~ ,, U .m;~~~~~~~~~UI LL L n,,:D HAO~ Qt~~n 61- J V)V z LL~~~~~~~~~~~~~~~~~~~~.,.ZL- :·~; · ' '' w u u c cc cc 00 CL. _ , I w w 3 we~~~~w Jcc, 1 be ~ ~ cn7 v,~~~~c S ~ ~ ~~~CCUJ 76~ o0 Stimulus TRANSFORM Orders 0 T OPERATOR T H Situation Situation H E Mission (Human Mind)j Execution E R Admin & Log Admin & Log R Command & Sig Command & Sig S Weapons Sys S Y Transform Logic (POCDC) Y S S T Planning T E Organizing E M Coordinating M S Directing S Controlling Commodity Unique Figure 2. The commander, knowing that he has responsibility and a prescribed set of managerial processes, then creates appropriate responses to either subordinate commands or available weapons systems. Building Block 4 - The Staff Thus far, the commander has been presented as managing his war by himself. The 24-hour-a-day tempo and massive information flow associated with war require support. The military provides this in the form of a staff. A brief description of the staff is presented here; extracted from FMFM 3-1. "GENERAL. - - The staff of a unit consists of those officers who assist and advise the commander. Functions common to all staff officers include providing information and advice, making estimates, making recommendations, preparing plans and orders, advising other staffs and subordinate commands of the commander's plans and policies, and supervising the execution of plans and orders. The commander and his staff should be considered as a single entity. However, no staff officer has any authority in his capacity as a staff officer over any subordinate unit of the command. "STAFF ORGANIZATION (1) Executive or General Staff. - - The manifold duties which the commander is required to perform in the exercise of command are grouped into six broad functional areas as a basis for the organization of the general or executive staff. These areas are: 77 (a) Personnel (b) Intelligence (c) Operations and training (d) Logistics (e) Civil affairs (when authorized) (f) Financial Management" The following diagram displays the concept of the model being applied across five* functional areas created by the staff organization. The comman- der begins to spread the work load to accommodate the level of detail and a natural breakdown of the information to be processed. Each staff section applies the POCDC transform logic to its functional area on behalf of the commander. The result of this application appears in annexes and appendices to operational plans, orders and as Standing Operating Procedures. (See Figure 3.) Building Block 5 - Centers Over the years, military organizations have evolved the "center." Centers are special in that they focus on a narrower span of activity but handle it with as much detail as required. There is no lower level of organizational addressal of an operational problem. Some centers have representatives from several commands in process of coordinating their activities. Others operate on a 24-hour/day basis with a high level of specialization. In nearly all cases, they perform routine tasks on informa- tion which can be specified in advance. This is not to say that the processes are not life and death or critical. In fact, the "dispatcher level" of work of managing the production of armed force is performed in the centers. As an example of the wide range of centers in use in military organiza- tions, the following list has been extracted from FMFM 10-1, Communications. 6 Each of these can be mapped to the sponsorship of a particular staff agency. Each can apply the IPS model as a describer of its processes. The transform logic of POCDC applies, focused on short term operations. The type of infor- mation processes is identified to a large degree by the names of functional radio nets entered by a particular center. It should be noted that there are no centers associated with tactical personnel operations. This does not preclude establishment of one, if circumstances require. Additionally, the overwhelming number of these centers are associated with operations. They are not all located at all echelons, but are associated with maneuver, supporting arms, aviation, logistics and communications. A structure (architectural model) displaying the coherent array of all centers is helpful. *Civil Affairs is deleted in view of its "as authorized" nature. 78 \ ~~~ E E ~ \ HQ C A4 o to H LL: v?~~~~~~~~0 C Z~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Z a:vC S z ~~~~~~~~~iC~$48"- Fe~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~a;;L O~~~~~~~ jj 79UcC Z Z f~~~~~~: L;L! aC 1 cl Oe N + I C C ~ L .cj~QHO_ _ _ 79 CENTERS (from FMFM 10-1) STAFF SECTION a. Landing Force Control Agencies (1) Combat Operations Center (COC) Operations (2) Fire Support Coordination Center (FSCC) Operations (3) Fire Direction Center (FDC) Operations (4) Tactical Air Command Center (TACC) Operations (5) Tactical Air Direction Center (TADC) Operations (6) Tactical Air Operations Center (TAOC) Operations (7) AntiAircraft Operation Center (AAOC) Operations (8) Battery Control Center (BCC) Operations (9) Direct Air Support Center (DASC) Operations (10) Logistics Support Coordination Center (LSCC) Logistics (11) Signal Intelligence/Electronic Warfare Intelligence Coordination Center (12) Tactical Surveillance Center (TSC) Intelligence b. Amphibious Control Agencies (1) Supporting Arms Coordination Center (SACC) Operations (2) Tactical Air Control Center (Afloat) Operations (TACC (Afloat)) (3) Force AntiAir Warfare Center (FAAWC) Operations (4) Helicopter Direction Center Operations (5) Tactical-Logistical Control Group (TAC-LOG) Operations/Logistics (6) Helicopter Logistics Support Center (HLSC) Logistics (7) Navy Control Organization Operations 80 CENTERS (from FMFM 10-1) (Continued) STAFF SECTION c. Communications Control Agencies Operations (1) Communications Control (COMMCON) (a) System Control (SYSCOM) Operations (b) Technical Control (TECHCON) Operations (c) Communication Center (COMMCEN) Operations (d) Switching Center (SWECEN) Operations (e) Special Security Communication Center Intel (SSCOMMCEN) To this point, the concept of information processing for command support has become more and more structured. The commander applies an IPS model to his processes, a staff is established for work distribution functional specialization, but using command processes, then centers are established to support around-the-clock operations on particular types of information. At no point has the necessity for automation been established. The work can be accomplished manually and has been traditionally (See Figure 4.) Building Block 6 - The Central The computer supported center will change the process of command sub- stantially. A central is the collection of facilities (hardware and software) necessary to support a center. The computer operates on binary states, hence everything which has been happily handled (albeit loosely) by the human senses and intellect now has to be converted to a stream of ones and zeroes, the processing of which must be very explicitly and precisely defined. In the IPS model, the stimulus set takes the form of digital messages representing the situation mission, A&L or C&S, or environment. These may be received over telecommunications lines or operator input. The transform operator is a digital computer, the transform logic is in the computer program. The effector set may be a digital stream to another system or hard copy for human use. The central operates exclusive of the communication system, except for system control message exchange. This relates to level 4 through 7 of the reference model described as Building Block 7. It is safe to say that no central will be able to meet all military information processing needs. However, the high degree of assistance provided will allow the humans in the center to focus on the aspects they handle best, i.e., poorly defined. 81 V)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~0 oC z i Q~~~~~ t4tL Z8cZ ° P4 82 Building Block 7 - The Inputs and Outputs The last major building block for a generalized architecture is the Draft International Standards Organization (ISO) Reference Model of Open Systems Interconnection. "Open Systems Interconnection refers to standards for the exchange of information among terminal devices, computers, people, networks, processes, etc., that are 'open' to one another for this purpose by virtue of their mutual use of the applicable standards." This concept is important to an architecture because it allows expansion in a controlled manner. The inter- faces of any number of system elements can be described. This is a seven- layered protocol which is summarized as follows: o Level 1, physical control, concerns the actual means of bit trans- mission across a physical medium. o Level 2, link control, enables logical sequences of messages to be exchanged reliably across a single physical data link. o Level 3, network control, provides logical channels capable of reliably transferring information between two endpoints in a single communication network. o Level 4, transport end-to-end control, provides reliable endpoint-to- endpoint transport of messages across an arbitrary topological configuration through several interconnected networks. These lower levels are collectively referred to as the transport service, and the Level 4 interface (between the fourth and fifth layer) is called the transport service interface. It represents a well defined interface that may be established between a communications carrier (provider of transport service) and a data processor (user of transport service). o Level 5, session control, provides sessions or high-level connections supporting the dialog between pairs of workstation processes. o Level 6, presentation control, provides required format transforma- tions of information being transferred. o Level 7, application, is the level of the work station process itself. This reference model is critical to adequately describing the relationships between elements in the CSS. Examples of these might be data entry devices, data communications equipments and computers themselves. It is likewise of use in describing non-automated systems; a new system user has an initial idea of where to look for particular types of information. This model establishes the reference for describing in detail the stimuli (Situation, Mission, Environment, A&L and C&S) and effector (Execution). 83 Through its use, CSS can be built for various echelons of command and various commodities such as aviation, maneuver, or artillery. The transform logic will be dependent on the command being supported in terms of the specifics of operations on particular data fields. Interoperability can be traced to a particular reference level and function being supported. The thread of this paper has begun with the commander who is responsible for the achievements of his unit. Management of the processes of application of armed force goes through the processes of planning, organizing, coordin- ating, directing and controlling. A conceptual model of the information processing system to support command is presented. The model uses the command management process of planning, etc., together with commodity algorithms as the basis of its transform logic. These later are shaped by the commodity being managed, i.e., manpower, fire support, aviation, logistics, communica- tions. The commander creates a staff to manage functional areas and break down the workload. Each staff section applies the model to its processes for a particular area. Staff sections sponsor centers for around-the-clock operations in specified operational areas. They perform planning, organizing, coordinating, directing and controlling for the command on more structured inputs over a narrower time interval for response and planning. This con- tinuous sharpening of focus on detail leads to the central which operates on digital formats, using a computer for the transform operator and a computer program to describe and convey the transform logic. The structure for describing relationships of centrals is described via an ISO Standard for Open System Interconnection. It should be noted that this architectural model is independent of hierarchical position and commodity area. It focuses on the commander, his functions, and the information necessary to support them. It is infinitely expandable by adding slices and addressing the points of interoperability. An Example A recent opportunity to demonstrate the use of a reference architecture occurred during an exchange of ideas between Navy and Marine Corps members on the subject of the Tactical Flag Command Center (TFCC). Nominally, the Marine Corps interface to the TFCC would be accommodated by the Combat Operations Center (COC) or Tactical Air Command Center (TACC) located at the Commander Landing Force (CLF) Headquarters. The discussion revolved around the poten- tial interoperability of these Navy and Marine Corps centers. The reference architecture provided the basis for the individual being briefed to rapidly assimilate and evaluate systems in question. Required elements of the C3 system are known in advance. The issue then becomes how the systems being described relate to the reference as a basis for comparing the TFCC and COC/TACC. The next few paragraphs provide a thumbnail sketch of the TFCC and COC/TACC. Summary information only is provided since the purpose of the presentation is an example of a generic architecture being used as the basis of system comparison. Using an unclassified article from Surface Warfare 84 \ ! r C S 4 t rrn~ u te3 ~-t3 en c lu C U n& .Z b ) 3;C 1 t 3 O;O OH 4 * - W ~LL 0): IW f .i rut -rq 8 8 L) C- C 4 W L)91~~~~~C W 85 January 1981 "Tactical Flag Command Center" as a simplified source, the following TFCC capabilities are listed: o Special intelligence presentation o Navy Tactical Data System presentation o Dead Reckoning Trace o Access to ship communications and display capabilities such as telephone, television and radio through a central console o Manual back-up The second phase of the TFCC program will be a central derived from the AN/USQ-81 designated the Flag Data Display System (FDDS). Capabilities of the FDDS will include: o All source integrated tactical situation display of air, surface and sub-surface data o Display overlays (to enhance cognition) o Detailed track information o Technical characteristics data base o Staff Planning and data manipulation aids The COC is currently a manual capability using overlaid maps, status boards, and supported by voice and teletype communications. The TACC has a computer supported display capability for real time display of aircraft tracks and status. It is NTDS compatible. The planning function is manually supported with access to voice and teletype communications. The COC/TACC will be upgraded with the addition of the Tactical Combat Operations (TCO) System in the post-1985 timeframe. TCO will use the hardware suite being built for the Marine Integrated Fire and Air Support System (MIFASS). The hardware/software assembly (central) will support: o Planning o Intelligence processing o Real time situation display o NTDS interface (via the Tactical Data Communications System) o Message Processing o Data Base management 86 o Mission Statement Processing The first face of the architecture is command processes. The inputs on which both centers focus in the situation through intelligence displays and friendly status. These are operational centers and do not seem to focus on Administration and Logistics (A&L) and Command and Signal (C&S). The use of a generic architecture raises the question of the adequacy of addressing these issues. This applies particularly to Command Relationships. Command rela- tionship confusion impacted the attempt to rescue the hostages in Iran.9 Using the architecture, the transform operators can be anticipated and described. The current TFCC, COC and TACC capabilities have limited computer support, primarily through NTDS based systems, including those USMC capabili- ties compatible with NTDS. Future capabilities will include the AN/USQ-81(V) for the Navy and the TCO system of the Marines built around hardware developed for the Marine Integrated Fire and Air Support System (MIFASS). Both are being procured with an eye toward supportable densities within the service. Transform logic is classified as Planning, Organizing, Coordinating, Directing and Controlling and Commodity Unique. The TFCC description does not address these functions discretely. Inspection of the previously provided list establishes that TFCC addresses features of the display capability. Planning aid is described as a capability of the FDDS. There is no require- ment to address these functions explicitly. However, since the functions of command are stated in JCS Pub. 1, it would be nice if they were used as the basis for describing command system features. 10 Similarly, the TCO system is described in the MTACCS Master Plan as supporting planning, directing and monitoring operational and intelligence information. Again, the processes spelled out by the definition of command are not addressed explicitly. The TFCC description does not address system output requirements - execution or mission statements to subordinates, A&L and C&S. (NOTE: These are probably covered adequately in system documentation but not explicitly presented in the write-up.) The summary TCO description does address the need to issue directives, but omits A&L and C&S. Again, in review of a system, an a priori reference architecture can properly serve to raise the question of how critical areas are implemented. Turning to the top face of the prism which the reference model resembles, we see the staff functions in terms of the 1, 2, 3, 4 of the General Staff. The TFCC does not incorporate this construction of personnel, intelligence, operations and logistics functions. If the structure of the model were applied, TFCC would address many of the intelligence and operations functions (G-2/G-3). The definition of the relationship of the TFCC to the Composite Warfare Commander functions would be helpful. A highly integrated (G-2/G-3) statement could be anticipated. COC/TACC functions can be mapped more directly to the intelligence and operations sections since the Marines use a General Staff organization. 87 However, looking at either TFCC or COC/TACC now concentrated in the G-2/G-3 elements of the architecture, it is reasonable to examine them more specifically for treatment of input-process-output. Status information is processed as input for planning, coordinating and directing (From describing documents). These are the results of messages specified in the operations order. There are several sets of formats such as rainform or JOPS. The exact processing associated with planning, organizing, coor- dinating, directing and controlling is not clearly defined. This gap is covered in the unique processes of staff personnel. Finally, the expected outputs are identifiable and can be related to Execution assignment, A&L and C&S, in general operation order format. The question the architecture raises for both the Navy and Marine Corps is the concept of control as a closed loop process. Implicit in the descrip- tions are control loop processes but the lack of explicit addressal in this context is bothersome. Within the construction of the staff, it is feasible to demonstrate TFCC and COC/TACC as operating at the center level. Information used and functions performed are routinized and highly structured. (However, the names give this away in advance.) The AN/TSQ-81(V) and TCO system are likewise identifiable as the centrals, which are hardware and software having a physical measurable identity. Use of a generic C3 architecture has provided a reference for looking at two specific capabilities in an organized manner. Both have been shown to be strong in situation display, focused on the stimulus-response but without an underlying control loop theory. Finally, the third dimension of our system level discussion of TFCC and COC/TACC can be addressed in terms of the Draft ISO Reference Model for Open Systems Interconnection. Both centers cross all seven reference model layers. TFCC at the physical control level terminates voice circuits as does the COC/TACC. Computers and peripherals are cable linked with cable termination pins identified and described by military standard interfaces. Link control addresses COMSEC among other attributes such as ringing schemes. There will be some voice compatibility between Navy and Marine systems. However, because of a Navy orientation to 2400 bps/3 kHz circuits, and Marine use of 16 kbs/25 kHz circuits, these will be at a minimum. Network control is the point at which some more incompatibilities emerge. TCO is oriented to being serviced by a multi-channel switched system. It will have some NTDS interoperability via the TACS/TADS JINTACCS programs. FDDS has a narrow band satellite focus. Transport end-to-end control can be manually addressed via DCA protocols. However, on-line interfaces are incompatible as at the level of communications to computer interface. TFCC is bounded by the Navy 2400 bps architecture. TCO is focused on the TRI TAC 16 kbs architecture. It is not designed for full period narrowband satellite terminations. The reference architecture allows rapid focusing on a potential incompatibility and its nature. However, for demonstration purposes, the review of the ISO Standard will be continued and applied to the TFCC and COC/TACC. The next level is that of 88 session control. Systems have to be interoperable in that each can decode, process and output the messages exchanged with the other. It is at this point that content and function become associated with the command process abstrac- tions of input (situation, mission, environment, A&L and C&S) processes - (plan, organize, coordinate, direct, control, commodity unique) - output (execution, A&L and C&S). Interoperability standards are now being written to support this require- ment. TCO will use JINTACCS standards. To the degree that the AN/TSQ 81(V) incorporates these standards, there could be interoperability on selected links. Session control also addresses the process of coordinating information exchanges between work stations. My interpretation of this process: half duplex or simplex. The system might be fully synchronous or interrogate/ respond. It seems that many of the packet data exchange network control approaches such as aloha, star or ring could be attributed to this level, since the frequency of information exchange would drive the session tempo. If the exchange rate is high enough, however, the session control would be dealing with a need for virtual total connectivity and this coordination function would be more properly associated with transport end-to-end control. Presentation control requires format transformations. This is the processing interface between the user and session control. The operator requires a human language syntax and adequate graphics. The computer system prefers bit oriented messages and process for minimum storage and simplified instruction handling. Hence, at this level, the human-to-binary interface must be made. Standardized transform codes are not frequently mentioned in the litera- ture. Examples of this might be operators associated with plan or direct. "Plan" might use operators related to time and place. "Direct" might use operators related to word processing and other message handling functions. The conditional tense is used here to emphasize the currently unstructured aspects of programming language features related to abstract definitions. A compiler syntax for these architectural abstractions would have value. Artificial intelligence may be a solution. The Application must support virtual transparency between users. In the real world, this is accomplished by restricted menu and symbol sets and training operators up to that standard. Both presentation control and the application layer for TFCC and COC/TACC might have conceptual interoperability on the basis of standard symbology and prompting menus. This coordination has not been affected. In summary, the reference architecture has been used as a basis for very broad description discussion of two capabilities. Its use supported rapid focus on similar functions, yet virtual incompatibility with specific excep- tion. 89 CONCLUSIONS The definition of command by itself provides the basis for a generic C3 architecture. The remainder flows from the processes of command, functions of the staff supporting a work breakdown structure and the standards for de- scribing interfaces. On this basis, C3 systems should be designated command support systems, since control is only one of five processes of command. C3I is likewise inappropriate, since intelligence is only one of five major staff functions. Both observations are based on use of basic definitions. Other basic definitions associated with command lead to confusion, since they include the term being defined in the definition. A rework of the Dictionary of Military and Associated Terms might be in order to insure a clear understanding of its processes and functions. That which is being controlled should be identified. The military has an abundance of existing reference material describing its processes. This material should be adhered to more in defining centrals for command support. The reference model for open system interconnection is a useful and viable tool for describing systems and their relationship to other systems. An area which could use more work is definition of a language syntax asso- ciated with planning, organizing, coordinating, directing and controlling. This may well be fundamental to implementation of interoperability at the presentation control layer. Input and output message forms are straight- forward; the transform logic standards will be more difficult. The example demonstrated that exposition and review of concepts and systems is expedited and enhanced by knowledge of the subject matter beyond that immediately being addressed. The definition of command support systems or C3 reference model is too critical to be left in the "too hard" basket. SUMMARY Just as knowledge of what an automobile looks like enhances a rapid grasp of its features, we need a similar simple acceptable model of our command system. 90 REFERENCES 1. Cypser, R.J. Communications Architecture for Distributed Systems, Addison-Wesley Publishing Company 1978 2. Fleet Marine Force Manual (FMFM) 3-1, Command and Staff Action P1 3. JCS Pub 1, The Dictionary of Military and Associated Terms P. 85 4. Johnson, Kast and Rosenzweig The Theory and Management of Systems PP 15-16 5. Rona, Thomas Generalized Countermeasure Concepts in C3I 1979 6. Fleet Marine Force Manual (FMFM) 10-1, Communications Section 3 7. American National Standards Institute Data Processing - Open Systems Interconnections 7498 8. Surface Warfare, Tactical Flag Command Center January 1981 PP 8-9 9. Aviation Week & Space Technology Group Analyzes Reasons for Failure Sept 15, 22, 29, 1980 10. Marine Tactical Command and Control System Master Plan 24 Apr 1981 PP 2-24 91 92 A CONCEPTUAL CONTROL MODEL FOR DISCUSSING COMBAT DIRECTION SYSTEM (C ) ARCHITECTURAL ISSUES BY Timothy Kraft Comptek Research Inc. 10731 Treena Street Suite 200 San Diego, California 92131 and Thomas Murphy NAVSEA 61Yll National Center Bdlg. 2 Washington, DC 20360 93 A CONCEPTUAL CONTROL MODEL FOR DISCUSSING COMBAT DIRECTION SYSTEM (C2) ARCHITECTURAL ISSUES Timothy Kraft Comptek Research, Inc. 10731 Treena Street, Suite 200 San Diego, CA 92131 (714) 566-3831 Thomas Murphy NAVSEA 61Yll National Center Bldg. 2 Washington, DC 20360 Abstract This paper presents a conceptual model of a ship's combat system developed for the Advanced Combat Direction System program. It provides the fundamental relationships of combat direction to command, control and communications and to the sensor and weapon elements of the combat system important to top level CDS architectural and design considerations. The conceptual model goes beyond current Navy Command and Control design which attempts to federate the CS into separate elements to present a layered control model which satisfies a hierarchy of response requirements. This control model is shown to be consistent with both the requirement for simultaneous and independent multiwarfare control and the CNO NTDS Function Allocation Study. The implications of this model upon combat direction system architecture are fin- ally stated as they apply to the management and technical development of future advanced combat systems. Paper presented at the ONR Workshop on C3, San Diego, CA, June 1981. 94 1. Introduction The increasing complexity of modern combat systems has widened the develop- ment gap between high-level requirements and the establishment of the operational baseline of hardware and software components with supporting documentation. The ship's combat direction system (CDS), which must interface with many of the combat system and command, control, communications, and intelligence (C3 I) components, reflects much of the complexity in evolving combat system design. (Section 2 describes the ACDS/C3 relationship further.) With complexity come expanded require- ments for technical expertise and a concomitant increase in management bureau- cracy to coordinate the many activities. Because Naval Tactical Data Systems (NTDS) were the first shipboard computer systems and have evolved into the primary component of shipboard command and control support, the NTDS community is well aware of the technical and management problems associated with complex systems ( 6). One proposed solution has been to further partition the CDS into federated components that can be developed and managed as separate elements (5). This, how- ever, only partially addresses the issue of complexity. Any strict partitioning without an overall systems approach would ultimately compromise the CDS's ability to support Command because of the large number of interactions among element managers that would be required to support the design of a CDS. Also, due to the expanding scope of Command's concern, and the range of possible responses to counter threats in highly complex and dynamic tactical environments, the respon- sibilities of Command can be expected to increase rather than diminish. If the scope of authority is well defined and meets the contingencies of the current tactical situation, the ship's command authority will delegate authority to lower echelons in the ship's command hierarchy. The delegation of authority cannot be dictated by system design; rather, for the reasons delineated above, CDS must be responsive to Command over the entire spectrum of tactical contingencies and support a flexible scheme for dispatching Command's responsibilities. The ACDS systems engineering approach incorporates a top-down structured methodology to provide decomposition of system complexity into simpler subsystem components, and to incorporate a large number of objectives within a unified system design. This approach places increased emphasis upon front-end analysis with systems engineering to provide sound CDS designs, as well as to anticipate and resolve issues early in the development process. To support this, a highly formalized systems engineering approach, which includes personnel, hardware, and software requirements as the integral parts of the CDS architecture, has been defined. Planning within the ACDS Project is directed primarily toward advanced development of combat direction systems. However, the planning does consider CDS interaction relative to other major design elements of C3 I, sensors, and weapon systems. Therefore, because the common interacting element is the CDS, it is important to understand the pivotal role of CDS in combat system design and interoperability before defining the CDS architecture. The CDS critical role in combat system interoperability and design is demonstrated in Figure 1. The following sections present a conceptual control model of a ship's combat system which reflects current capabilities while anticipating advanced develop- ments. A similar activity was directed by Chief of Naval Operations to investi- gate the appropriate allocation of combat system functions to NTDS (3). The study group representing various Naval branches of engineering, material and operations formulated a similar conceptual model. Both studies draw heavily upon operational experience and anticipated technological trends to generalize a 95 generic structure of command and control systems. Furthermore, both approaches combine both man and support systems in an integrated system definition of C3 . The conceptual model presented here goes beyond the CNO function allocation study to discuss how control is structured within a combat system. It addresses the problems that arise in the delegation of authority within a distributed ship's structure. Therefore the two models complement one another with CNO study allo- cating functions within the combat system, and the ACDS model defining the control interactions within the combat system. Sections 2 and 3 describe the relation- ships of combat direction to C3 I and other combat system elements. Section 4 presents how the conceptual control model addresses the issue of delegation of authority and the resulting command and control structure required to support multiwarfare (AAW, ASW, ASUW) engagement. Section 5 summarizes the implications of the model. C31 \C OMBAT/ Figure 1. CDS, One of the Four Major Elements of Navy Systems Design 96 2. ACDS/C 3 Relationships The C3 network is supported at various levels by intelligence gathering and environmental support centers which provide operational command with the required information to support mission planning. This entire network is referred to as command, control, communications, and intelligence (C3I). The CDS is the "effector" node of the C3 network - directing the weapon and sensor assets of ownship, battle group, and/or supporting battle force command and control. The relationship of CDS to the Navy C° structure is illustrated in Figure 2. Figure 3 gives the rela- tionship of the various command and control nodes and the inter/intra Battle Force Combat Direction Networks. KEY: COMMAND NET rt \TFCC NET / ,,,AIR\ -.- SHIP NET NCA t" SHIP -SHIPNET TYPICAL FLEET] NCCS SIMILAR ASHORE FLEET COMMAND COMMAND CENTERS CENTER (FCCs FOR CINCLANT (CINCPAC) &CINCEUR) MBATTTYPICA INFORMATION SHIP TYPICAL INDIVIDUAL COMBAT SYSTEM (SHIP PLATFORM) T COS SENSORS WEAPONS * COMMUNICATIONS * OTHER SYSTEMS Figure 2. CDS Relationship to Navy C3 The CDS will perform the following roles within the C3I network: a. It will operate in conjunction with the Tactical Flag Command Center (TFCC) and other CDSs as part of a distributed Battle Force Combat Direction System. b. It will operate in conjunction with other CDSs either as a participating unit or as a commanding unit of a multiunit battle group responsible for execution of some aspect of the battle force mission. c. It will direct the elements of its ownship combat system, including air 97 platforms in close control, to support the battle force in simultaneous and indepen- dent engagement within all warfare areas. GLOBAL COMMUNICATION INTRA-SHIP COMMUNICATIOC N -NT ; SFLEET system (nottobecofusedwit a n r s COMMUNICATIONrtS DCDe rlTFeCCS F t-LEET TFCC CDS 'NTER-CENTER COMMUNICATIONS COMiUNICATIONS INWER-SH INTER- BATTLE ( A ~CDS BATTLE CS BATTLE CDS )FORCE GOUP CDS Figure 3. Inter/Intra-Comunmication Networks and Command and Control Nodes The distinction between battle force and battle group is the degree to which multiple units are coupled into one system. At the force and group level, no one system (not to be confused with a human) is responsible for the entire combat direction of the force or group. Instead, multiple systems distributed among the participating units data linking with each otherthe make up battle force or group CDS. These real-time systems are linked by Tactical Digital Link (TADIL) and voice communication networks. The functions performed by the CDSs as part of the Battle Force/Group Combat Direction System is illustrated in Figure 4. The TADIL communication networks can be thought of as the "data bus" interconnecting the CDS and TFCC as shown in Figure 5. Within C3I, intelligence is gathered and plans are formulated and propagated down the command hierarchy. At each level of planning, the plan is expanded until a detailed engagement plan is formulated by all participating units. If, in the execution of a mission plan, a great deal of interaction and coordination among distributed systems will be required, then the group is to be considered closely coupled. On the other hand, if portions of the battle force plan are delegated to closely coupled battle groups whose only requirement is to provide timely status reports concerning the execution of responsibilities, then the battle force 98 is said to be loosely coupled. The spectrum from a loosely coupled to a closely coupled multiunit cdistributed system is dependent upon the information band width and accessibility of the communications network. The deployment of JTIDS Phase II and the development of TADIL J, which will exploit the information bandwidth and access capabilities of JTIDS, will greatly expand the opportunities for closely coupled multiunit responses and, in turn, increase the effectiveness of the battle group. The CDS will be required to support the entire spectrum of multiunit res- ponses, either as a participating unit or command unit supporting one or more force commanders of the battle force management hierarchy (CWC concept). BATTLE FORCE AIR TACTICAL DATA THREAT IDENTIFICATION SYSTEM (ATOS) WEAPONS ASSIGNMENT AIR - b ICONTROL BATTLE FORCE -~~CO°A~~~~MPORF°RSIT~E/ ~SURVEILLANCE COMPOSITE INTEGRATION WARFARE NTEGRATN COMMANDER SUPPO ;:FBATTLE FORCE s ~ TRACK MANAGEMENT - ON SHIP r .Lz · SENSORS OWNSHIP \ COMMAND SUPPORT a dc~i~-c? Fgur . COS WoEAPONS _ teCDS MULTI-UNIT BATTLE GROUP g r ; D COORDINATION WARFARE <\ ~/ X ~C~OORDINATION sad~~-~~~g-~~L G-~~~~ /il-:·REAL-TIME E a - /3i12 SURVEILLANCE |.~ 2 ~_m INFORMATION IT.1 j -EXCHANGE Figure 4. CDS - The Key to Effective Intra-Battle Force Integration Having a number of CDSs capable of flexible multiunit configuration greatly enhances the capabilities of the Composite Warfare Commanders (CWC) and increases the survivability of the battle force by permitting distribution of battle force command authority to meet the contingencies of the tactical environment. The elimination or disruption of any unit can be effectively countered by the reconfi- guration of the remaining units. 99 The CDS capability to be responsive to the mid- and long-term C3I environment consists of providing multiple levels of automation support commensurate with crucial Command response time requirements. The long-range goal is to provide a continually leading technology base of design concepts for CDS engineering develop- ments. The systematic approach to CDS R&D will encourage optimal usage of combat system resources for mission needs as opposed to the after-the-fact "crisis" interfacing currently employed. In this manner, CDS development can be responsive to constantly changing combat system requirements and can facilitate optimal sys- tem integration. Finally, it can protect the multibillion dollar investment in deployed combat direction systems from technological and/or threat-imposed obsolescence. COMMAND INTER BATTLE FORCE COMMUNICATIONS a COMMUNICATIONS MTa \ INFORMATION t i a mj SUPPORT TFCC SUPPORT CENTER DIRECTION SYSTEM (aR ~VOICE AN SE/OR SEN SYS TAIL SYSTEM NFORMATION 8US INFORMATION \ \ ' i INfORMATION SUPPORT ] SUPPORT CENTER CDS \ CDS WEAPON SENSOR SYSTEM SYSTEM S ST SHIPS COMBAT Figure 5. Battle Force (Group) Combat Direction System ACDS is concerned with an approach to CDS design thaj allows the development of a family of CDSs and facilitates the use of standard C building blocks (hard- ware and software). This emphasizes the need for an approach which permits con- tinual and evolutionary shipboard CDS upgrades. It is necessary that the CDS si- multaneously and individually support single and multiunit engagements in all major mission areas supported by the (AAW, ASW, ASU, AMPH and Strike), with increased emphasis upon offensive operations. 100 This is in contrast to the force and self-defense measures which stress anti-air warfare (AAW); in particular, anti-ship missile defense (ASMD). It is important that ACDS provide the Combat System Architect with a unified CDS appraisal which includes all aspects of combat direction as part of the C I network. 3. ACDS/Combat System Relationships The ACDS will operate within a tiered combat system architecture. The layer- ing of the combat system (CS) is the result of current technology-driven evolu- tionary trends, with many combat system functions being embedded in the various subsystems. A new CDS architecture will be required to account for technological advances in sensors, weapons, and communications which have greatly increased the degree of automation within the combat system. The increased data processing load and the growing complexity and sophistication of the expected threats and missions, coupled with requirements for faster engagement responses, have necessitated complete redefinition of the scope and function of the CDS. The CDS architecture will be defined within the context of a conceptural con- trol model of a combat system. The conceptual model must address the following fundamental considerations: a. What is the relationship of Command (CO/TAO) to the ship's total CS? b. What is the function of a CDS and its relationship to the other elements of the CS? c. Are there technological constraints that define the form of ship's CS independent of fiscal constraints? The control model described herein presents the conceptual control structure (vs. a functional structure provided by the CNO functional allocation study) of a generic combat system. An actual system could be far more complicated; however, the salient features of a combat system structure are summarized to provide an overall framework for discussion of combat direction system architecture. The major conceptual functional groups of the combat system are: $ Multisource Surveillance Function (MSSF) consisting of all functions within the CS that support the search, detection, and identification of targets in the tactical environment, including sensors and information sources. * Multiwarfare Engagement Function (MWEF) consisting of all functions within the CS that directly control engagement of targets within the tactical environment, including deployment of weapons platforms and hard and soft weapons. *Multiunit Command and Control Function (MUC2F) consisting of all functions within the CS that support the planning, assessment, coordination, and control of the combat system resources, including communications among multiple units and propagation of information throughout the system or network. These functional groups do not partition the operational functions of a combat system. In fact, there is a great deal of overlap, with many functions being cate- 101 gorized within two or three elements. It is this ambiguity in allocating functions that makes these functional groups inappropriate as submodels of the combat system. However, they do reflect the basic sensor/director/effector cybernetic pattern which is found duplicated on minor and major scales throughout the combat system architecture. The combat system is characterized by a complex data processing and control network with a layering of functions. Control is distributed throughout the system rather than being exercised by one control director. The objectives of tiered distributed control and, in turn, the integration of sensor/director/effector include (4): * The reduction of information bandwidth as information propagates away from the sensor, reducing measurement error and compacting information content. * The reduction of the response time for the engagement function, once a stimulus has been received by the surveillance function. The layering of the response within a combat system can be characterized by the following: 0. Reflexive response: The reaction is immediate, based upon wide bandwidth (or immediate) information. 1. Considered response: The reaction is protracted in time, requiring a coordinated set of actions to achieve an objective. 2. Creative response: The capability to create and assess plans, initiate and change tactics, improvise, and adapt to unexpected contingencies. 3. Coordinated multiunit response: The capability of multiple independent units to organize and coordinate their responses to achieve a battle group (closely coupled) or battle force (loosely coupled) objective. In the "reflexive" mode, the response is based upon immediate data with little predictive capacity. The "considered response" requires a more correlated picture to be able to predict actions over the period of time of the response. The "creative response" requires the correlated picture, the identification of relations within that picture, and the stability to be able to assess plans and objectives over a long period of time. The "coordinated multiunit response" requires a tactical picture of the area of concern for the battle group or battle force, and a predic- tive capacity which supports plans that extend hours or days into the future. The results from this layering of response is a parallel tiering of data processing to support the information content requirements of each level. The tiers are: 0. Tier 0 processing: Processes the initial signal to form a contact that is valid for only the time of measurement. 1. Tier 1 processin : Correlates contacts from one or more sensors to form tracks representing a correlated set of data. 2. Tier 2 processing: Forms the tactical picture from Tier 1 tracks and other external Tier 2 sources to represent the platforms and the inter- relationships among platforms in the tactical environment. 3. External Tier 2 processing: The collating and management of information distributed among multiple unit data bases so that a consistent battle force/battle group wide picture emerges. 102 Each tier represents a reduction of required information bandwidth to transmit the same information content and the extraction of higher order patterns. Once the Tier 2 tactical picture has been formed, the information content may still be so great that only selected subsets of the data may be displayed or transmitted among units. This will mean further extraction of patterns and initiation of plans and goals based upon these patterns. Within an actual combat system there are many levels of control. The concep- tual model categorizes five levels of control corresponding to each combat system response: 0. Analog (reflexive response): The actual control signal required to imple- ment a specific action, and which is modulated by parametric and mode control selections. 1. Parametric (considered response): The selection of a mode represents a domain of parametric control inputs. The selection of specific parametric control values is performed to optimize the appropriate response to external stimuli. 2. Mode (creative response): Doctrine translated into a well-defined control matrix which restricts the modes of operation of the combat system to a set of predictable responses in support of mission objectives. 3a. Doctrine (closely coupled multiunit coordinated response): Battle Force Mission Objectives and Rules of Engagement translated into battle group mission plans, and doctrines which further subdivide the mission goals into subgoals. 3b. Rules of Engagement (loosely coupled multiunit coordinated response): The repository of all commands adhered to by each platform from which coopera- tive response can be formulated to satisfy battle force mission objectives. The final conceptual element is the ships Battle Management Organization. The CNO NTDS Functional Allocation Study group defined a generic operator hierarchy which encompasses all specific operator hierarchies in the fleet. There are four levels within the command structure as follows: O. Action Implementers: Operators who perform manual tasks within the sensor and effector subsystems and are outside of the command action direction system (CADS). 1. Action Transformer: Operators who provide details required to implement an action and keep action selectors apprised of the outcome of an action. 2. Action Selector: Operators who recognize the need for an action; define options and select the appropriate response; and disseminate directives to action transformers. 3. Action Authority: Command who ensures that actions selected are consistent with other actions; constraints imposed by higher authority; and broader force objectives. 103 The above Battle Management Organization overlaps the conceptual tiered combat system at the interfaces. That is, the "action implementors" perform Tier 0 and Tier 1 control tasks; "action selectors", Tier 1 and 2 control tasks; "action selectors", Tier 2 and coordination control tasks; and "action authority", coordination control tasks and mission planning (figure 6). The action authority or command is responsible for the direction of the combat system. Since the conceptual control model presented here allocates functions according to response, and the CNO study allocates functions according to the combat action decision maker information requirements, the allocation here of combat action decision makers to combat action responses provides the isomorphism of functions defined within each model. The conceptual model of a combat system presented here (Figure 7) addresses the combat system information network without considering the physical allocation of functions to hardware, or the interaction between software elements. As can be seen in Figure 7, the primary areas of concern to the CDS program are supporting Command in battle group mission planning and deployment, and multisource/multiwarfare planning and engagement; not the specific execution of engagement orders and the like. The CDS as a system component of a distributed Battle Force CDS will also perform functions to support Tactical Flag and other participating units in Battle CADS \ ACTION AUTHORITY * ENSURES THAT ACTIONS SELECTED ARE CONSISTENT WITH LOOSELY - OTHER ACTIONS. COUPLED - CONSTRAINTS IMPOSED BY COORDINATED HIGHER AUTHORITY. A- BROADER FORCE OBJECTIVES CLOSELY COUPLED ACTION SELECTOR COORDINATED * RECOGNIZES THE NEED FOR AN ACTION * DEFINES OPTIONS AND SELECTS THE APPROPRIATE RESPONSE. CREATIVE * DISSEMINATES DIRECTIVES. ACTION TRANSFORMER * KEEPS THE ACTION SELECTOR CONSIDERED APPRISED OF THE PROGRESS OUTCOME OF AN ACTION. * PROVIDES DETAILS REQUIRED TO IMPLEMENT AN ACTION. REFLEXIVE Figure 6. The relationship of the Combat Action Decision Makers to the Tiered Conceptual Control Model within a Combat Action Direction System (CADS). 104 _SSf MUC MWEF LOOSEr CO.JPLED _&' ' / *^Ctl~~~i.~ *~ C*t \ ?ACTIC&[ SIT"J1TIOh COORDINATED EPui,~'LS.- - - Ti -COUP-' COOROINATED ?&C?..&~$STu&T0~ .|X , 'C; L'I:-ICL: lur*··. _ _ -_NIT i i I C_ I ESPO.SE _. _v_ _I _OR__ .ATORS '. A, C.~ - F..... L ' C...... S.SfSS3 COORDVINTORS ":..,sou)ct 1 u~w.,/,~...... ,,,~',,w,,,,,.';,, ,.-~,: &o.ssss,,..,".c " [ RTOCESSR VC11CA. ODE CREATIVE 'ri~~~~~~~~~~~~~~~~~~~~~a~~~~C 2' R.SPOESE PROCES ,ONSE SENSOR OIAC,.oo. EFECTO, R Figure 7. Conceptual Model of a Combat System Force Track Management, and will provide composite warfare commander support including propagation and response to Force Command orders. The other combat system elements (Tier 0 and Tier 1) integrate sensor and weapon capabilities to: * increase the reflexive response effectiveness within well-defined situations, or * increase the considered response options with predictable results. 4. Delegation of Authority The issue of the role of Command within the combat system centers upon variant interpretations of the AIE Doyle directive (2) for combat system design; in particular, Command's delegation of authority in multiwarfare environments. The salient issue in the delegation of authority is defining the degree of centralization required for Command to exercise direction. The ADM Doyle concept directs the delegation of authority down the ship's organizational echelon closer to the sensors and weapons and the implementation of commands. This achieves a decrease in response time and in the load upon Command. This delegation of authority requires that the criteria for exercising control be specific and well defined, and that the scope be limited. It also requires that Command be given information with which to assess plans and the implementation of delegated authority. Strict delegation 105 of authority decreases Command's capability to "retain overall control over the ship's total combat system". Such strict delegation limits Command's capacity to direct the combat system and, therefore, does not satisfy the intent of the Doyle directive. The conceptual combat system model permits simultaneous and independent action for combatants and warfare areas within a well-defined control hierarchy structure in which Command exercises broad positive control. Table 1 summarizes the above three approaches. TABLE 1 ACDS Conceptual Combat System Model Design CONCEPTUAL CURRENT MODEL INTERPRETATION A. Simultaneous or Tiered Federated Partitioned Combat Independent Action in All Combat System Design System Design Warfare Mission Areas B. Delegation of Mission Management Delegation of Authority Authority Including the Delegation of Authority Fixed by Design Detailed Conduct of Defined by ROE and Engagements Doctrine C. Command Must Multiware Opera- Control Intervention Retain Overall Control tional Environment. as well as Negation Over the Ship's Total Command Exercises when Necessary Combat System Broad Positive Control 5. Summary and Conclusions The layered combat system responds to the tactical environment within a hier- archical control structure that provides sensory interactive, goal-directed behavior; i.e., combines the mission and warfare area commands and objectives with the sensor data from ownship and offboard sensors to form the appropriate response to the tactical environment. Such control structures have been the topic of extensive investigation in the area of brain modeling and robotics. Dr. Albus' control system theory approach ( 1) provides a framework most analogous to the control structure of command and control systems. In summary, Albus states that the sophistication of response and the complexity of behavior resulting from a control hierarchy depends upon: 106 · The number of levels in the control hierarchy. · The number of feedback variables that enter each level. · The sophistication of the control function that resides at each level. * The sophistication of the sensor processing systems that extract feedback variables for use by the various control functions. Advanced combat systems must provide sufficient sophistication with respect to the spectrum of responses supported so as to increase the number of options that a potential adversary must account for in planning a tactical action and to defeat his capability to predict responses and achieve an element of surprise. On the other hand, advanced combat direction systems must provide command the capability to restrict the control options within the combat system so as to achieve specific objectives with some degree of certainty of success. As the ship's command and control structure becomes more dependent upon automation to achieve its objectives, these system requirements will become increasely evident to the combat system designer. It is not the purpose of CDS design to model or imitate the human brain. However, such paradigms do provide guidance which should not be ignored within an overall command and control architecture ( 7). Ultimately this conceptual model will be used to define an overall combat system architecture which shall be adaptive to changes in threats and capabilities and permit the continual preplanned improvement of system design. The authors would like to thank Dr. Michael Kovacich of Comptek Research, Inc. for his initial insights at the conception of this project which were invaluable in directing the outcome of the final model. Also the diligent efforts Ms. Mary Carlson and Ms. Darla Carson in preparing the manuscript and presentation are much appreciated. 107 References 1. Albus, J., "A Model of the Brain for Robot Control" Parts 1-4, Byte. Byte Publications, Inc. (June-September 1979). 2. Doyle, Admiral, "(CNO Surface Ship Combat System Operational Philosophy" SER 03/702528, (5 Nov 1976). 3. "Final Report of the CNO NTDS Functional Allocation Study Group", (20 February 1981). 4. Kraft, T. and White, D., "Unified Sensor Control: Tier II Control Approach", Comptek Report: M3352-3-3 (December 1978). 5. "MODFCS Architectural Baseline: A Combat System Architecture", NSWC Dahlgren (15 January 1980). 6. NAVSEA 0967-LP-027-8602, Advanced Combat Direction System Design Program Plan, Volume 1 (June 1981). 7. STS Data Management System Design, Charles Stark Draper Laboratory, MIT, (June 1970). 108 EVALUATING THE UTILITY OF JINTACCS MESSAGES BY Captain John S. Morrison United STates Air Force TacticaZ Air Forces Interoperability Group Langley Air Force Base Virginia 109 ABSTRACT The program for Joint Interoperability of Tactical Command and Control Systems (JINTACCS) is defining message standards and operational procedures needed to improve joint command and control. Within the Air Force, the Tactical Air Forces Interoperability Group (TAFIG) is using both quantitative and qualitative methods to evaluate the effectiveness of JINTACCS within the context of a joint exercise. The methods are based on a conceptual model of factors important to military decision making. 110 But don't you see that the whole trouble lies here. In words , words . .. And how can we ever come to an understanding if I put in the words I utter the sense and value of things as I see them, while you who listen to me must inevitably translate them according to the conception of things each one of you has within himself. We think we understand each other, but we never really do [Ref. 1]. - Luigi Pirandello I. INTRODUCTION A. THE LANGUAGE OF BATTLE On the tactical battlefield, the cost of misunderstanding can be very high. The grammer, syntax, and meaning of commands must be communicated with a high degree of precision in order to effectively coordinate the use of people, weapons, and resources. By its very nature, the battlefield is a source of ambiguity. Words, procedures, and actions are often transformed in unpredictable ways, and are especially susceptible to noise injected at the joint interface. The Joint Chiefs of Staff recognized the importance of cross-service communication when they established the program for Joint Interoperability of Tactical Command and Control Systems (JINTACCS) in 1971. At the time, services and agencies were not interoperating. Each service had its own message standards and its own terminology. Joint interfaces and information exchanges were not clearly defined. The language of battle was rife with ambiguity. B. THE LANGUAGE OF JINTACCS The JINTACCS program was established in order to develop standards and procedures for a more effective exchange of information within the joint task force. These standards and procedures include: 1. Message standards which are designed to be man and machine readable. 2. A Message Element Dictionary, to insure that information is understood by all players. 3. Interface operating procedures, to insure that the right messages go to the right people at the right time over the right communications. 4. Data standards, to insure that machines and 111 communications work together. JINTACCS is the new language of battle. It is a synthetic language containing syntactic, semantic and procedural components. It was developed by operational experts, engineers, and joint committees. It has been (and will continue to be) tested both in laboratory and field environments, in order to determine its acceptability as a standard for human-human, human-machine, and machine-machine information exchange. JINTACCS standards address a hierarchy of information levels. The most primitive information element is the character. Special characters, for example, mark the beginning and end of "fields" and "sets." This level of information is probably more important for machines than for humans. At the next level, groups of characters form key words, and convey meaning. Key words are entered into a message according to the rules for "fields"; semantically related fields are combined to form "sets"; sets are combined to form messages. Finally, groups of logically related messages form "strings." Although the "grammar" of JINTACCS is more structured than what most message preparers are familiar with, it is also more consistent. Figure 1 shows an example of an existing message standard, while Figure 2 shows the same data formatted as a JINTACCS message. To the extent that existing messages rely on abbreviations, codes, and acronyms, the degree of readability is roughly comparable. It should be noted that the JINTACCS standard does permit free format entries, but the standard attempts to capture as much significant data as possible in the "structured" portion of the message. There are two reasons for this. First, of course, formatting makes it easier for machines to process the data. Equally important, the "logic" of the message demands that critical information, if available, must be included. While JINTACCS can be viewed as a linguistic problem, it is also useful to view it as a communications engineering problem. Weaver [Ref 23 distinguished between three levels of communications analysis. Level A deals with the accuracy with which symbols of communication can be transmitted. (The technical problem.) Level B deals with the precision with which the transmitted signals convey meaning. (The semantic problem.) Level C deals with how effectively the received meaning affects conduct in the desired way. (The effectiveness problem.) The mathematical theory of communication [ Ref 33 deals only with Level A, while JINTACCS cuts across all three levels of communication. New tools must therefore be forged in order to properly evaluate JINTACCS. Figure 3 shows the relationship between JINTACCS, linguistic analysis [Ref 33, and communications engineering. On the linguistic side, we can view JINTACCS in terms of 112 ELui b ru X ~~ ~~ui cm <:z cnF cz CY cl Z ~~~~~~~~~~~~cCU· ~~~~~r- CD .. o x cnEl LLI ~i z zCD a) LU x CM _ LL LL. cm E C _° C= o a!= e ^ CJ~~~~c'L = S-')F oY4 NXF C _ L C D CM _ CZ F.. JIO cm 0 C= C5I F1 qCr C~3 I: iO CL x U·I C rd· wU-C U~L to C: =LJt to zL e LnGL S C~~~~~~.JC n C C L C) z X O cm a e z o I~~~~11 r LLJ~~~~Q C-- .- _ 1I- CCX, ~U.,- 1 .. J CM Z ¢. _C CD a CMW C== G <- CIO cm C,.3CID ~ UJ " U.CM r' t~~~~~~~.,~ l_. _ LO U~~~~~~l~ ~ I-CD, D C CD,:: ° O- -. J cr.. i~~~~~jI.ur ry11I r~ cnc n Q= =L_z Z~ zi C/j~~~~~~~~~~~~~~~IC...-. . " ~ CDC ujM U, CV CM C r=C C= Irl C LU w w T C-4 c L C, X n mCD CVTtI) J I =1C1C r)~ I, U114 "competence" (How much do operators know about JINTACCS?), "performance" (How well do operators use JINTACCS?), "'grammaticalness" (Are there any inconsistencies in the rules that specify the well-formed strings of minimal syntactically functioning units (formatives), and assign structural information to those strings?), punctuation, and spelling. Interface operating procedures can be viewed as a metalanguage dealing with messages (Fig. 4); the messages themselves form another linguistic level with distinct rules for well-formedness; the character set represents the lowest linguistic level. On the communications engineering side, we can view the effectiveness problem in terms of interface operating procedures, the semantic problem in terms of message information content, and the technical problem in terms of the message character content. Very broadly, the communications engineering aspect of JINTACCS deals with the rational determination of capacities and boundary conditions, while linguistic analysis empirically measures the well-formedness and appropriateness of messages and message strings. We must view both faces of JINTACCS in order to see the whole picture. D. THE JINTACCS APPROACH In order to make testing manageable, JINTACCS has been divided into five segments: intelligence, air operations, operations control, fire support, and amphibious. Each segment is evaluated in two phases: compatibility/interoperability testing, and the operational effectiveness demonstration. Compatibility/interoperability testing evaluates JINTACCS in a controlled laboratory environment, using representative operational facilities and commercial communications channels. The "compatibility" portion of the test evaluates the ability of systems to exchange information; the "interoperability" portion of the test evaluates the ability of operational facilities to use the information. Testing is geographically decentralized, with the principal USAF test unit located at Langley AFB, Virginia; the Navy test unit is here at San Diego, California; the Marine Corps facility is at Camp Pendleton, California; and the NSA test unit is at Fort Meade, Maryland. The Army test unit, and the Joint Interface Test Force are located at Fort Monmouth, New Jersey. After compatibility and interoperability have been tested, and JINTACCS standards have been modified to accomodate improvements recommended by the services and agencies, the JINTACCS segment is turned over to CINCLANT for an operational effectiveness demonstration (OED). The OED, which takes place within the context of a SOLID SHIELD exercise using full-up facilities, insures that the developed standards work in a tactical environment. The OED demonstrates JINTACCS compatibility with current tactical communications, and further refines messages and operational 115 H .O~~~~~~~~~~~~~~~0 zZ Q)m '~ Z 0 Z~~~~~~~~~, o a) 0) 0O m L o .0r I II mC H .u3-1a a) P4-J '- . 0 vd O00)3 4 H 1-i Q.. zH- 0) H 4i 0 0 CDO ~ ~ o ~ oo 4-o r= tiU 4--4~- ~ 0, -- ~0 .~) 0- 02 0 -0 Il v~~,- H I . .,to 0)02 I - 0 ,--I ~ ¢) '~ - a)- 02 0:2!I--IED H a)02~~) ~~~~~~~~ 0. 0 0 -H- P4 ED O" I:) Er) t, a) -- HD( O ~ tDJ0t3.,0 2 0:3.,0 20. O I 4-i :.~r.3~O:: c t: 0 b00 0 L9 r. -H a1) 0 bO 4-l0)P a) 4-i -<-*H4-i0-,H ~ 0 4-J 4-i C.) H 4-i d 4-W H -4 CZ.0. H MO 4 0 C cE 00 'En u 'Uar0)0 aC) 0 03.. 4-L02uH 001 0 .l-J020a ) 02a o) to c00 O4-J H V. Q)H (a) tr PcIC C 0 to cd0E 0 0 0 4-JH- H u b002t 02COo co-- rz co C) P ) L - co 00 a rd 0) Ef) i · E 0. C.) a) 0 4. -H co 4-4d 0coaCHa) a) PH Uc a) CI. 02~~~~~U2< ) E) i Q) C,. aao tb ~~ ~0bo a) to C) la CO) 0 U C. ) 4- i40 FI I to I4-4 0-4I kObo co a)Ito~0 4 a)I 41 C02L 4 *Hn 04C-- 3 U02 04 a) 4 S a) 12- 020 En 02Q 4-4 0 - Qfl024- V 0 H01 w ) . 4 -4 4 UC'-.ai t-L In U)4.JHHC4J 0) H1H4 -J (10 0 H< r0HC 0)CD I -H a)0) 'C '04-i a)4 -H 10)) P-0 t)- a -40H z 014- 02 0)4 r0-q 4-0. 4JO L) ci$40 L) ()bO L)10 -0 H 4JiL24iII l i d0 0) V4 0 .-) W :2Ha) to.0 02HUr I- 0204v 0) .L)a4 O>P H0)b 4- a CZ-q ~4liI- tk CZ OC.- C 1-4C4 002 a, .H02a~~~~~~~~~ca)0 Pcco c )t E5-q 0)0 H I0H0Cr rl m c HO, a)4( H0 2- 02H02 la. -40)aw U 0 (L) U ) CO a)L) (1Plv-4 0 4)I0to A4 HO. E)H Cd020)v0)0a P a) 4 00)-12 0 L)-Hwa) 2 Ui I02U UU~)0CIOH CO c z 0 44 m Cw CH )H rea 4 02 ~ I.- CH 0 4)4 P OZLU L2L0. EnHP4 l1 01H0HI0 h IHp0 )a) C.l H i' a)d c a) 4&C).I.JJJ. .o 0i4 H404Pi0 0) l. L) --4 eq H~H 3(1) a0)00 - E 1i H02a)·ri= e 0) H,a ca H CC 0. Ua C-) 4- 0.0 0)0. c4 E 0 k P L) 1163 2c 0 U0O Z3 H 0)la0 rH0 UUo ko.: u a) O) 04..U0-4-i0)II0 U C lr) a) 0l U F 0 0 -H cc 6~~~~11 *o1 i : --:a o co 0 ) ~ U) ,.D>.r 4. 4- C -H j4-1 z r o3> 4iU) :>- H m m m _ C. U0 U) a) a0 CO -rO 0 0 L) O -a - U) 4CJ4 a|cl/ UI aU 4-3 CU) ) s0 U )U ^ ) O E\ J CO = Or 4- U)( ^ CO b:4U) - la, ri\ ~ i\~~~ U~ =(~U L) 117 procedures. JINTACCS is an ambitious program which is essential to the success of future joint task force efforts, but it is not without risk. Since JINTACCS redefines the very fabric of tactical command and control, a scientific and methodical approach is needed to evaluate the effectiveness of JINTACCS, isolate problem areas, and insure that the program is on target. Such an approach must be based on a conceptual model of military decisionmaking, and factors important to such decisionmaking. This paper reports on JINTACCS message evaluation methods developed by the Tactical Air Forces Interoperability Group (TAFIG), at Langley Air Force Base, Virginia. The methods are being used to analyze the results of the JINTACCS intelligence OED, which occurred in May of this year. 118 II. INFORMATION BASED DECISIONS A. GEDENKEN EXPERIMENT Consider the following "thought" experiment: A decisionmaker sits in command post A, waiting to receive messages of a particular type from command post B. Under the first scenario, all received messages contain "old" information which is no longer relevant to the decisionmaker's task. As a result, no decisons are made, based on the messages. Under the second scenario, the messages do not individually call for action, but collectively point to a possible environmental state which could necessitate action. After a certain point, a pattern emerges, and the decisionmaker makes a decision about the true state of the environment. Under the third scenario, each message contains data which clearly indicate that an immediate response is appropriate. Decisions are made immediately after messages are received and processed. Regardless of how we define "decision" in the above experiment, if decisions are based on information acquired from messages, and if the message preparer at command post B had key data to communicate, it is clear that message preparation, transmission and processing times place an upper limit on the "rate" at which decisions can be made (Fig. 5, Dk ). Another conclusion which can be drawn from an analysis of the experiment is that the actual point in time that a decision may be made is partially determined by message content. For example, the content of a particular message could figure into a decision at some future time, after additional data is acquired (Fig. 5, Dj). Alternatively, the content of the message could be useless for decisionmaking purposes, and no decision would ever be made based on the message. This latter possibiity represents the lower bound of the decision rate (Fig. 5, Di). A third conclusion from the experiment is that the messages provide a "schema" for information, independent of the information itself. The value of the message (which is distinct from the value of the information content) is partially determined by how well the message conveys information critical to the decisionmaker's job, if and when such information is available. Fourthly, if the message is garbled, or if the accuracy of the information is suspect, then the decisionmaker may have to integrate data over several messages before arriving 119 4 a) - I - aco) U + coa) 4(H ~/ oD U6C 4Jn J ( 4) OU 0 3) 0 Cau o 0 CL-*. H0 Q0 CU O.a)4C c i (I" o a) U 4- *H-VU a o v cnr.) 4J 4oJ U" -) *a) ·r 0O v 14)C. - 4-4 4 KzL-Ul-Z x.ZQfl1 - vfr 120 at a conclusion. Garbling is a function of both channel noise and human error; the degree to which the information content of a message represents ground truth is determined by the ability of sensors to resolve the environment, and by the ability of humans to form accurate judgements. EB. DECISIONMAKING CAPACITY OF A MESSAGE For purposes of making operational decisions, the message field is the basic unit of information. We assume that if a field is critical to the operation, is syntactically correct, and contains accurate information, then it may be used as a basis for making reasonable decisions (Fig. 6). The number of such fields in a message is given by: D = HA-I Where H = critical fields in a message A = proportion of syntactically correct fields I = proportion of fields containing accurate information Intuitively, it would seem that the number of usable fields in a message would influence the number and quality of decisions that could be made, based on that message. This hypothesized relationship between semantic components and decisions parallels a relationship, found at the technical. level, between information and control: The degree of control of a system is proportional to the logarithm of information in the system [ Ref. 53. While the "bit" is an appropriate unit of measure for information at Weaver's "Level A," it is less appropriate for levels "B" and "C," and will therefore not be used. The usable fields in a message may be weighted for each operational facility or function, depending on what proportion of the total critical information requirement is satisfied by a single, usable field C Fig. 73. For example, if, looking across all messages, the critical information needs of an operational function can be satisfied by 100 message fields, then each usable field would contribute 1/100 of the total requirement. We assume that a message type which is capable of contributing 65/100 of the total critical information requirement is more valuable than a message type capable of contributing only 3/100 of the total. The weighted number of usable fields in a message is found by N = H*A*I / F Where F = Total number of fields critical for an operational facility. 121 ri) a4 co COC4-J" Ct 7- C.) Ei lq · ·,--Irl ,.- - H 4-i .a 4r4C) MCZ d .1I4 r4 rxa) C)(d C~ k .H F cor. d. ) D 4-4. C.) ·) ~', 4.Ja~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~()440~ ',- . Upa Q-er1 CCO .u , , 4~ ,0S U) co : -)C n* -i 00~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~. I0 4-i CO Cl Q) Q)~~~~~~~~~~~~~~~~~~~~~~ 4-i E~ C)a rl~t (o , ,-p·r k,,0 ror. a) a)3 k=~~~~~~~~~~~~~~~~~~~~~(.) au C U) C) '0 C 4-i *-4 ) (a) -hC r 4 p E c a) ,---1 r.u o.4-i ) .uca) ,--co 0a~~~~~~ k km -t~~~~~~~~~~~~~~~oX ~~~~a) 44 Co 4-4 oC En4-i r-4q co a) O~~~~~~~~~~~a)-. ) c ieid ri) co 0 0 0 ~~~~~~~~~~~~~~~~~~~~~~~~0El)4-l 4-IQ0 ,,:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~,.o.,a . ·: r-4at( rl'0,.-i j 4-i to0 *E4i0H ·t'*Ca~Fc *H co ) Cd CtI:$C da) c4 HC dO C P~~~ ~u,.4in,..i ~~~~~~~~~~~~0co 1:C) j. *1.) a, b-to '0 CZ a1) a) O · p~~~~b ·· P· I~c o 3· o o -o-4 03 4-. I4-4 4-i Q) 4-i CO a) C-' ·rQ )C)co ''4- 4-Ico -Cl a1)o PC) r-4co Ci) ri (d 4-i a) cta a) Cd r= P 4> C) · c-o,W 0 a ) ·i··· 22··t·,· t ~~co4-i pd .H ~~~~~~~~~~~~~~~~~~~~~~0CZ p -H -H 4i (1~~~~~~~~~~~~~~~~~~~~~~~~~~)-H SCd 4-i 4-) cdoCd 0 0 cd E 4-~~~~~~~~~~~~~~~~~~~~~5L4-H C) 4-4 · ,~· · ·~··~···:0 a( ) 4C) CZ 44.r tO H CZ r-I 4-ir '04-i a a) roco CdO a)4-i a) EnCa) C) 4.i~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*H- 0 En C) a) h.O C)< Zb · O<:'..0Ct 0) CZ - cI 0 -H coH )n k U)Cd C *H a~~~~~~~~~~4-i ~a) CO ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~)0 4-J -40 4-4 4.J-- co * '0 0 o )0 U* -rq0 CO C.. -H4- 4-i 4-J -4Cd 4-iCO, '0 Cd u =$ > Cd r a) co p a) ' 4-4 H at r(to Ejcb~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~lvrl~4J04 mu c -q01O4 d~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3 at*0 kV~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~44U)3 CO r-0 H4-0 122 ) OC o 0) laUc)c * C u) I bo LOC CV c(0 qH t~~~~~~~~3 -HC I···= ' r~~~~~~~~~~r~~~~ v,~~~~~~~-J~-4 · LII~~~~~~~~~~ 0 - s-i~~·r · · ~~~~~~=~~~~~~~~~~~~~~~··~ ~ ~ ~· ~ ~ ~ ~ a)0 ;i~~~i·5, C .C·L··~~~~~~~I·:~ ~ ~ -4C 4J ,14 -H (120 4J0)~~~~~~~~~~~~~~~~~~~~~~~~a VH ~~~-a0)~~ 0 w-4~ 5-I ~~ ~ ~ 0J r4 b~~~~~Ow0 r4 5-4 0=H (V~~~~~~r 123~ ~~ ~ ~ 0 0 u o The result can be broadened to provide a measure of "usefulness" extending across all operational facilities and functions. Let F' be the number of elements in the set of all message fields which are critical to one or more operational functions; let H' be the number of elements in the subset of F' formed by fields contained in message type Q; let A' be the average syntactical accuracy of the message across all operational facilities; and let I' be the average accuracy of the message information content across all operational facilities. Then the proportion of the total information needs of the C3I system satisfied by message Q is given by N' = H ' A' · I' / F" The expected maximum rate, Bq, at which messages of type Q can communicate critical information from the message originator to the decisionmaker depends on the sum of the average message preparation, transmission and processing times (Tm, Tt, and Tp, respectively): 1 Eq = Tm + Tt + Tp If the terms in the denominator are all zero, then theoretically, information could be communicated at an infinitely fast rate. If the sum of terms in the denominator is effectively infinite (for example, if the total message delay exceeds the length of the military operation under consideration), then no decision could ever be made, based on that message. The absolute rate at which information can be communicated is less important than the communication rate relative to the pace of the operational environment. There is a difference between "decision time" and "time by the clock." This difference can be taken into account by differentially weighting time delays for different operational functions, and for different messages. For example, if a reconnaissance wing operations center (WOC-R) must transmit the mission report (MISREP) within 60 minutes of aircraft engine shutdown time, and if the message is sent via immediate precedence (required delivery time less than 60 minutes), and if the goal at the Tactical Air Control Center (TACC) is to process the MISREP (update the data base) within 30 minutes of message receipt, then the maximum recommended delay for communicating information from the WOC-R to the TACC is 150 minutes. The "weight" given each minute of observed delay would be 1/150. That is, one minute equals 1/150 of "decision time." The ratio of allowed communication time to observed 124 10 C~ % = =m go 0 la as *s *\ as 's o n 4 1 vH a, 10 Ofl ~r _4i . a C) O O OO' 0 to / ) o Enr .- \ ¢H F=JJ ZO 04 O O O O O O O O cnUo ) a- :>~nD4°- %f -zCj I . 0 ~ CJ, I C j C O.. C.0 0 Cc - , -A- O. \ 0/ 0 0 - C 4-J a, I oe-)lr °,- I° I° °C I ~( to O ,-4 ,-t ,-4 CO O CD 44E0 Co$ a ° j)Lf..4 '-40 Z 0 'iii0 0- 0 v-I .00I 00 0 0 C400 0 -= 0)... 0 C-I , - I 'I -t 0 c .u - ) I:4-0 ) OH 0·- 4 C 4Jr4 0l q25r, ) 94 ur. ) c en I ( I r Lnr a r( I a to U, U, toCY QI 0) u U)- c- Z a ..... , : cJU cJ. H H V--J-i v- I C tJ '.0 0) 0 ) )- 4 U20a rl I re I a i a I a I a I VNc7 It4~ ).. 04 0P40) communicaton time gives the rate of communication with respect to the pace of the operational environment. Using the above results, a figure of merit (FOM) can be derived for each type of JINTACCS message. This FOM is a composite of certain measures of effectiveness which (intuitively) relate to the usefulness of the message as a decisionmaking tool. For a given type of message, Q H' fm + tP1 +r FOM (Q) = - A ' I' F L Tm + Tt + Tp Where rm, 7ft, and rp are the time goals for message preparation, transmission and processing, respectively. The FOM is the weighted product of usable fields and Bq. It can be interpreted as the theoretical proportion of total critical information needs satisfied per weighted unit of time. I II. EXERIMENTAL METHODS An operational exercise using JINTACCS can be viewed as a linguistic experiment. Training sessions prior to the exercise establish operator competence; measurements taken during the exercise can be used to determine operator performance; subjective questionnaires and structured interviews can be used to evaluate the acceptability of JINTACCS, as viewed by operators who must read it or write it. Figure 9 shows the three dimensional collection space for JINTACCS-related observations, which is being used to evaluate the results of a recent joint exercise. The vertical dimension represents different operational facilities which exchange information. The horizontal dimension represents the variety of messages to be evaluated. The third dimension represents observations collected over time. A single cell in the three dimensional block represents a particular occurrence of a particular type of message generated by a particular operational facility (OPFAC). Analysis of variance (ANOVA) will be applied to time and error data collected during the exercise, in order to highlight those results which could not reasonably be attributed to chance. ANOVA will also allow us to trace the source of a statistically significant result (OPFAC vs message). IV. CONCLUSIOUNS We do not expect to have the complete results in from the joint exercise until the end of this calendar year. However, 126 A-7 127 we have nearly completed our analysis of critical information requirements, and we anticipate that several proposals to change the JINTACCS standard will be submitted as a direct result of this analytical effort. The JINTACCS standard will not go away, but it will continue to evolve to meet the needs of the services and agencies. The Tactical Air Forces Interoperability Group is contributing to this process by developing a quantitative approach to C3I. 128 IBL I OGRAPHY 1. Luigi Pirandello. Nake Masks, "Six Characters in Search of an Author" (New York: E. P. Dutton & Co., Inc., 1952), p. 221. 2. Warren Weaver. "Recent Contributions to the Mathematical Theory of Communication," bThe athematical T.heor nf Communicatioro (Urbana: The University Of Illinois Press, 1969), p. 4. 3. Noam Chomsky. Aspects of the Theory -o_ Svntax (Cambridge: The M.I.T. Press, 1965) 4. Appendix 5 to Annex Y to AFLANT JINTACCS Intelligence OED Plan (u), AFLANT Supplemental Data Collection and Analysis. HQ USAF Forces Atlantic Command, Langley Air Force Base, Virginia 23665. 15 January 1981. 5. W. F. Duckworth, A. E. Gear and A. G. Lockett. _ t.tid to Operational Research (London: Chapman and Hall, 1977), p. 190. 129 130 FIRE SUPPORT CONTROL AT THE FIGHTING LEVEL BY Barry L. Reichard United States Army BaZllistic Research Laboratory ATTN: DRAR-BLB Aberdeen Proving Ground, Maryland 21014 131 Fire Support Control at the Fighting Level Barry L. Reichard U.S. Army Ballistic Research Laboratory May 1981 . 'INTRODUCTION A strong National Defense capability depends upon the ability of our US Army to respond to any type threat in any theater in the world. One of the most demanding missions is fighting against a mechanized threat where greatly increased mobility and lethality combined with the possibility of fighting outnumbered will result in an inten- sity of battle never experienced on previous battlefields. The Yom Kippur War was a sample of the kind of intensity of battle that can occur on the modern mechanized battlefield. The objective of the US Army, however, remains unchanged - to win the land battle. Doing this on the modern battlefield, especially when outnumbered, will require the skillful orchestration of combined arms teams to concentrate combat power where and when it is needed most. On this dynamic battlefield, where com- mand communication lines may be cut off intermittently, the battle must be fought and combat power must be applied by Captains and their companies, batteries, and troops under the general direction and control of brigade and battalion commanders (while higher levels of command should focus on concentrating the forces at the right time and place). Since a principal component of combat power is the firepower pro- vided by the fire support system (Figure 1), the ability to plan, coordinate, and exe- cute fire support at the fighting level must be a critical area of concern for US Army Research, Development, and Acquisition. As evidenced by Figure 1, the fire support system is quite complex in that it con- sists of many parts with a wide variety of capabilities and operations, is widely distri- buted geographically over the battlefield, and has elements at all command levels and some from other services. Surprisingly, a little known fact (to nonartillery-men) is that the field artillery is responsible for integrating all fire support into combined arms operations as well as providing one form of fire support. In fact, it is because of the current field artillery organization and command structure that the lowest level at which integrated fire support for the fighting elements can be examined is the maneuver brigade. Normally, an artillery battalion (bn) assigned the tactical mission of direct support (DS) is used to provide fire support coordination assets and artillery firepower to a maneuver brigade (bde). (Depending on assets available and the tactical situation, another artillery battalion may be assigned the tactical mission of reinforcing to aug- ment the fires of the DS bn.) A DS bn is still under the command of the next higher artillery force headquarters (HQ), division artillery (DIVARTY), but answers calls for fire in priority from the supported unit, DS bn forward observers (FOs) and target 132 acquisition means (e.g., radars and air observers), and last from higher force artillery HQ; i.e., a DS unit is the on-call artillery firepower for the supported maneuver bri- gade. If the brigade needs more fire support than that already available organically or through artillery fire support facilities, additional fire can be requested from DIVARTY which for a mechanized infantry or Lrmor division, includes two additional DS bns (for other maneuver bdes in the division), one general support (GS) bn, and a number (perhaps three) of battalions attached from corps in the form of an artillery brigade. The counterfire mission (attack of enemy indirect fire systems) is largely accomplished by DIVARTY and the attached artillery bde, wheres close (fire) support (attack of "close" enemy troops, weapons, or positions that threaten the force) is usu- ally provided or arranged by DS artillery or organic mortars in support of maneuver brigades, the fighting elements. The fire support control facilities in a type mechanized infai-try brigde are dep- icted in Figure 2. Fire support control is defined here to mean all operations necessary to cause the right fire support effect to reach the right destinati"n at the right time, which therefore includes what is now called fire support planning and coordination and fire direction as well as control of devices to guide munitions to the target, e.g., laser designators. Fire support planning is the continuous process of analyzing, allocating, and scheduling fire support Fire support coordination is the process of implementing that plan and managing fire support assets. Fire direction (FD) is the employment or execution of fire support firepower and can be either tactical or tIhnical. Tactical fire direction is the selection of targets to be attacked, choice of fire Support units to fire, selection of the best ammunition, and (with TACFIRE) corside-tion of fire support coordination measures. Technical fire direction is the conversion of calls for fire sup- port (target location and type) into fire commands (aiming data) a as some think of it - solving the gunnery problem. In the brigade area (Figure 2), artillery fire direction is performed at the DS bn fire direction center (FDC) and at each of the battalion's batteriyDCs A, B, and C. Both 81mm and 107mm (4.2 inch) mortars are organic to man-euer units - an 81mm section of three weapons to each rifle company and a 107mrm pla1-on of four weapons to both mechanized infantry and tank battalions. Mortar FDCs are commanded by the maneuver unit commander, but the artillery fire support coordinaiors (FSCOORD) are responsible for integrating mortars into the fire support p!an Ez for advising the maneuver con.mander on their use. As with artillery FDCs, th establishment and operation of fire support planning and coordination facilities are t-e responsibility of and the mabrity of personnel and equipment are provided by'hl field artillery. At each echelon from corps to company, a FSCOORD is responsi-_'- to the supported force commander for inte:r-ating all fire support means into the -e ssuport plan and for advising the force commander on how to implement fire suppct. The FSCOORD is either the commander of the supporting artillery unit or a reprR-.ntatrve thereof. In the illustrated br-i]-de area, the bde FSCOORD is the CS art-iery bn com- mander, usually a LTC. The bde fire support planning and coOr-nation facility, the fire support element (FSE), is operated by the bde fire support offetr (FSO, a MAAJ), the FSCOORD's full-tirme representative, and three enlisted men, and it works in 133 coordination with the bn FSEs (whose FSOs are supervised by the bde FSO), with the DS bn FDC, and with the main and tactical FSEs at the division command post (CP). At brigade and every level from battalion to corps, representatives of other fire sup- port means are made available to the FSCOORD as shown in Figure 3. The bn FSO (a CPT) is the FSCOORD at the maneuver battalion level, and like the bde FSO, he is the principal advisor to the force commander (maneuver battalion commander in this case) on all fire support matters, recommends allocation of fire support, prepares fire plans, performs target analysis functions, and monitors requests for fire support. The bn FSE must coordinate its work with the fire support teams (FISTs), which are supervised by the bn FSO, other bn FSEs, the bde FSE, and the DS bn FDC. At the company (co) level, the FIST is the fire support organization. The FIST concept was recommended by the Close Support Study Group in 1975 to optimize observed fire support, and subsequent to Department of Army approval in 1977, has been phased into the force structure. Simply stated, the FIST concept combined the mortar and artillery FO organizations, called for new equipment like tracked armored personnel carriers (for FISTs working with mechanized units) and additional radios, and provided for training under a common military operational specialty (MOS). A "type" mechanized rifle company FIST includes three 2-man platoon FOs as well as a HQ manned by the FIST chief (a LT) and two enlisted men. Tank company FISTs do not have these platoon FOs or 81mm mortar sections. (If one of the maneuver bns in the mechanized infantry bde is a tank bn or if there is a mix of mechanized rifle and tank companies, the platoon FOs and 81mm mortar FDCs would be deleted in Figure 2.). With the FIST concept, the additional role of fire support planning and coordina- tion has been added to the traditional FO role - target acquisition and adjust-fire "sen- sor." The FIST chief (CH) is the company commander's FSCOORD as well as the primary FO for the company. The FIST, under the supervision of the CH, is respon- sible for locating targets and requesting and adjusting fire on them, planning and coor- dinating fire support, reporting battlefield intelligence, and at times, locally controlling other fire support measures such as close air support. 11. FIRE SUPPORT CONTROL - FUTURE Tn the future, fire support control development till be impacted by and in turn will impact the majr rethinking of time-honored artillery organizations, operations, and doctrine as the Army enters the high-technology automatic data processing (ADP) wvorld. The new Flre Support Team (FIST) organization concept, for example, is already bEing implemented. This combination of the artillery and maneuver-unit mor- tar observers has raised the fire support control issue of twhether the FIST chief can be both the primary observer and the comnpany-level fire support coordinalor (FzSCOORD) and has generated a nerw fire support control materiel requirement for a spcia FIST Digital IMessaSte Device (DMIND) to permit the monitoring, editing, and automatic retransmission of data commnlunictions. One result of the Division Restruc- ture Study (DRS) of 1976 is that the direct support artillery battery size will increase 134 from six to eight guns that will normally operate as two four-gun elements, both with fire direction capability. Fire support control for the DRS battalion fire direction center (FDC) will then involve interaction with six instead of three (for a 3-btry bn) subordinate fire-unit FDCs, each of which will have a Battery Computer System when it is fielded. The Division 86 Study organization, when implemented, will also have a serious impact on the fire support control system in that ten maneuver battalions instead of nine in a heavy division and four companies instead of three must be ser- viced by the fire support system. The combined-arms Close Support Study Group IT (CSSGII) recognized that in the new Tactical Fire Direction System (TACFIRE) data world, there was an opera- tional need for not only the FIST DIMD but for a functionally similar device for the battalion (bn) fire support elements (ESEs) in the maneuver brigade area. (The need for such devices will be especially critical when the mortar FDCs receive the Mortar Fire Control Calculators (NlFCC), which operate in the data world.) Such data dev- ices offer the promise of real- time fire support coordination as opposed to silence-is- consent. For example, as shown in Figure 4, the FIST DMD (at FIST HQ) can serve as a data communication switch, a decision node controlled either actively by the operator or automatically as preprogrammed, to direct a FO generated fire request either to the organic company mortars or to the bn FSE for a higher level of fire sup- port depending on the tactical situation, target type, or other criteria. With a new data device in the bn FSE, the organic bn mortars or higher fire support means can be selected at this decision node. In consideration of future Field Artillery Tactical Data System (FATDS) require- ments, the TACFIRE TRADOC System Management Office (TShMO) continued this preferred centralized control scheme (which is actually a distributed processing sys- tem) to the bde FSE At this point, service of the fire request could be allocated to fire support means represented in the bde FSE, e.g., close air support (CAS) sorties or naval gun fire (NGF), or could be passed on to the direct support (DS) field artillery bn I-DC, which in turn could select the appropriate battery or batteries or perhaps request a reinforcing battalion to fire the mission. To remove the target intelligence load on the bn FDC, the TACFiRE-TSMO also added a new element in the bde-area picture - the target integration center (TIC). Interfaced to the Firefinder radars, Remotely Piloted Vehicles (RPVs), and other new-technology target acquisition dev- ices, the TIC with ,ADP aids can convert voluminous target intelligence data to confirmed target.data for insertion into the active fire support control 'circuit" - and thereby reduce the data load on that circuit and the brigade-area fire support control system. The fire request routing depicted in Figure 4 raises many issues, but the primary one undoubtedly is responsriveness. The need for the flexibility, i.e., the capability to short-circuit the preferred centralized scheme (for incresed responsiveness), was rccognized by the CSSG TI. The data communications needline as tabulated in tihe CSSG It report, shows the desire for full fIexibility - to be able to operate optionaUly with successively lorwe.r levels of centralization (Fi'ure 5) and even fully decentralized control where the FO can direct his fire request to any fire support control element 135 from the FIST HQ to the bn FDC (Figure 6). As indicated in Figure 6, it may even be desirable to permit, under some circumstances, the FO to deal directly with a preal- located weapon system for maximum responsiveness. The need for responsiveness is obvious, but there will also be crucial times when the force commander needs to be in full (centralized) control of the fire support forces, e.g., final-protective-fire massing and special tactical counter-force interdiction. If the preferred control system is designed and developed appropriately, all lower levels of control will be possible from a materiel standpoint, and commanders will have the option of selecting the most appropriate one for a particular tactical situation. Continuing with the rethinking of fire support control, a recent Field Artillery School draft doctrinal paper presents a potential generalized philosophy for fire support control in the 1985-2000 time frame. Citing the volume of targets that will be gen- erated by new target acquisition devices (in one scenario simulation, an average of 1586 target complexes are acquired in one DS area in 24 hours) and the potential shrinking numbers of friendly weapon systems (together with growing numbers of enemy weapon systems), the paper recognizes that fire support assets must be time shared. The current approach to this problem has been face-to-face and voice corn- munications and the use of ADP to automate manual procedures. The paper, how- ever, presents a force design that will allow maximum exploitation of ADP technol- ogy, which is still growing at a rapid pace, and the emerging automatic data distribu- tion technology. Tn this concept force design, the fewest possible weapons (1 to 4 recommended) are organized into a fire unit (FU) that has its own technical fire direction and positioning/pointing sysaem (probably on each weapon). Back-up technical fire direc- tion could be performed by a handheld calculator, or an adjacent weapon. The weapons in the FU would be dispersed and perhaps perform single-weapon missions with a gun-and-run tactic. Gun and run (or shoot and scoot) presents the toughest control problem and nearly the same on-board fire support control is needed for widely dispersed or gun and run tactics; therefore, gun and run should be pursued - if the system is designed for gun and run, all lower flexibility options are possible, including massed fire. The weapon(s) in a FU should operate within a 3-km position extent and use "hide" areas for resupply. (However, a single hide area for many weapons may be detectable by the enemy.) Location and weapon status would automatically-be transmitted to the battery that will be discussed below. For higher-level fire support control FUs would be organized into a battery, which would have a stable organization in peacetime, but would be task organized awhen committed to combat. As shown in Figure 7, the battery is divided into tvo main parts: the battery trains element and the operations (OPS) element. The OPS element is normally located at the maneuver bn command post (CP) to expedite the intearation of fire support and maneuver fires. In lieu of the traditional btry FDC, the OPS element performs fire support planning and coordination and tactical fire direc- tion, coordinates FLI movements, and also serves as a back-up technical fire direction system for subordinate FUs. The btry trains element is the principal ammunition and fuel resupply source for the FUs; the element also provides mess, maintenance, 136 battlefield recovery, and other logistic services. The ADP hardware at the btry trains HQ, which normally is used to coordinate, monitor, and direct logistics support, should be identical to the OPS ADP system so that the trains ADP system can serve as a back-up OPS unit. For force control, conceptual batteries are organized into battalions, which also should be task organized in combat. The battalion, like the battery, is divided into an OPS and a trains element. The OPS element would be located at the bde CP, would provide tactical control of the batteries, and also would serve as the artillery sensor integration and target center for the bde command element. The bn trains element would perform administrative and personnel services, but the principal logistics role would be to coordinate outside logistics support for the battalion. The conceptual DIVARTY and corps artillery units would provide neither administrative nor logistics support but rely on the supported force for this. The DIVARTY and corps units would have OPS elements at both main and alternate CPs. The OPS units would recommend task organization of subordinate forces, also serve as artillery sensor integration and target centers, and perform nuclear and chemical fire planning for the supported force. A comparison of the current and proposed force design concept is provided in Figure 8. Recent Enhanced Self-Propelled Artillery Weapon System (ESPAWS) analyses (at BRL and ANMSAA) indicated that new-technology materiel concepts may permit and require significant changes in artillery organizations and operations. Assuming FOs request fire from the DS btry FDC and then deal directly with a single gun (with perfect C3), using a generic autonomous gun concept (single-gun missions with gun and run) with fire-and-forget munitions for DS, and using fire-and-forget rockets or 8-inch munitions in general support (GS), the analysts showved that two battalions of such weapon systems could support a division force significantly better than the more standard seven battalions of existing weapons in terms of point targets (APCs, tanks, and artillery weapons) killed in a mechanized threat. This does not mean that the division-slice force should be reduced to two battalions, but that with new materiel and operations concepts, it is possible to have artillery force reserves for nonlethal roles, interdiction, and massive suppression - if the fire support control system can accomplish this kind of diversified application of artillery firepower (and other fire sup- port means). Regarding materiel, the AD)P technology "dish" is overflowing. General require- ments for the concept force design described earlier are summarized in Figure 9: dis- tributed common data base, software with interactive query language and the flexibiity for personal programming and "what if" war gamining, and common hard-are with graphics displays and tailored hard-copy ouriput formats. The technology either exists or is emerging to meet these requirements. Micro-computers are getting smaller and smaller but yet more powerful and equally affordable. Large, flat display systems and voica recognition te-.hnologies are emerging . Artificial intelligence, gaming theory, and distributed decision process-s research can be applied in the software to aid in put- ting the "man in the loop" without critically degrading responsiveness. At least t-wo alternative automatic data distribution systems (ADDS) are under development: an 137 enhancement of the developmental Position Location Reporting System (PLRS), a time division multiple access (TDMA) system, under the control of a centralized com- puter, with a finite number of unique 'slots" for data transmission, and (2) the Packet Radio, an experimental system that "marries" a radio and a microcomputer, forms data communications into "packets," and automatically distributes them. To exploit new ADP technology and to meet future user needs, an Advanced Field Artillery Tactical Data System Program Plan has been developed. This modular "product improvement" plan will permit sequential performance improvements so that the utility of the current hardware and field capability over the next 15-year period will be maximized. Moreover, with this approach the system software can be built upon and refined as opposed to a new start. The improvements will be developed in three discrete steps: (1) development of a new communications control system (CCS), which will be programmable to handle a variety of message structures and all com- munications systems to include dedicated ADDS radios, (2) development of new remote terminals, which will employ interactive graphics and provide distributed pro- cessing and data bases, and (3) development of new, smaller, simpler to operate sub- systems for the TACFIRE FDC computer group. 111. FIRE SUPPORT CONTROL TEST BEDS F:ELBAT-8 & ACE Recent battle simulation analyses and field experiences have shown that fire sup- port contrgi (or as it is usually referenced, artillery command, control, and communi- cations, C ) is the key to improved fire support effectiveness and survivability. New fire support control doctrine and evolving user requirements are indicating the need for both fully centralized and fully decentralized control of fire support and all levels in betuween, so that control can be quickly tailored to tactical needs. With the automatic data processing (ADP) technology and concepts "dish" overflowing, the fire support control development problem can be compared to "boarding a speeding (technology) train" (in the context of an 8 to 10 year materiel development and acquisition cycle). Test beds like the periodic HELBAT (Human Engineering Laboratory Battalion Artil!ery Test) field exercise can help in this problem area by providing a "vehicle" for he development and evaluation of alternative total oDerating system concepts and pro- cedures. In light of the above introduction, it is no surprise that the main thrust of HETLBAT 8 will be C 3 as indicated by the priority list (Figure 10), which was gen- erated by the Field Artillery School at Ft. Sill. Further, with new doctrinal concepts like spread-battery emplacement, split 8-gun battery, and gun-and-run, there is a need to evaluate new tactical fire direction concepts at the battery level and automated posi- tioning, pointing, and technical fire direction control on board the weapon. W5¥ith the rapidly increasing need for and the difficulty of distributing data on the battlefield, as evidenced in IR--BAT 7, there is a need to evaluate data distribution concepts and w\vavs to reduce the data load such as use of the targiet inte.ration center (TIC), which will convert the great magnitude of intelligence data to a smaller volume of conrfirrmed 133 target data. With reference to line-of-sight (LOS) limitations experienced with for- ward observer (FO) vehicles in past HELBATs, concepts for increasing the observa- tion capability from the fire support team (FIST) vehicle as well as air observer capa- bilities are to be evaluated. Since nuclear, biological, and chemical (NBC) protection is also a priority item, particular attention will be given to this area including, if possi- ble, the incorporation of NBC protection on some of the hardware concepts fabricated or modified for HELBAT 8. New technology concepts to be evaluated in a fire support control system context should be compared with the newly fielded Tactical Fire Direction (TACFIRE) system as a baseline. The exercise should therefore be, at a minimum, in the context of a maneuver brigade-area since this is currently the lowest level of TACFIRE tactical fire direction and the smallest integral fire support control area (see Figure 2). This will require the following type "players" in the exercise: FOs, FIST HQs, battalion (bn) and brigade (bde) fire support elements (FSEs), battery (btry) and bn fire direction centers (FDCs), weapons, and perhaps company (co) and bn mortar FDCs. Consider- ing this complexity and the high-technology experimental equipment involved, HEL- BAT 8 will be quite an ambitious undertaking for a one-time 6-week exercise. To insure maximum usefulness and lasting significance, the exercise must be planned in as much detail as possible and be approached and followed with a set of integrated efforts as shown in Figure 11. One of the first efforts will be the development of a fire support control simulator (a computer-based laboratory test bed), called the Artillery Control Experiment (ACE), to aid in the planning of HELBAT 8 and subsequently to serve as a continu- ally available tool for the development and evaluation of fire support control technol- ogy, materiel, organizations, and operations. With ACE, fire support control problems can be identified, analyzed, and defined in a series of alternative system and scenario contexts, which will be quite helpful in generating and evaluating experiment designs for HIFLBAT 8. Further, hardware, software, and "skinware" (human interface) tech- nology and system concept opportunities can be explored without building complete dedicated hardware. Perhaps most importantly, ACE can be used to investigate the application of key research areas (such as artificial intelligence, gaming theory, and dis- tributed decision processes) to the tough problem of fire support control automation. As well as providing a much needed tool for user development and evaluation of alter- native organization and opzration concepts, ACE may also be used as an automated command-post-exercise (CPX) trainer. General examples of possible ACE investiga- tion areas include: computer assists at decision nodes, improvement of man-machine internaces (e.g., natural and query languages), "intelligent" filtering of information presented to fire support officers (FSOs), and short-hand graphics for responsive, simplified operations. More specifically as described in Figure 12; ACE is an interactive, real-time, multi-player fire support control simulator. Initially it will be developed on an in- house computer system (a Ballistic Research Laboratory PDP 11/70 with UNIX operat- ing sofrtwar), but wherever possible, a common programming language (such as FORTRAN) will be used to facilitate the ease of ex-porting ACE or parts thereof to 139 other organizations. ACE will be able to both accommodate and simulate tactical fire support control materiel, e.g., the TACFIRE Digital Message Device (DMD). Through simulation, tactical equipment availability problems can be avoided; "what if" changes can easily be incorporated and evaluated; and training spin-offs are possible. Through the accommodation of actual equipment, the time-consuming development of simulator programs can be avoided; hybrid mixes of actual and simulated concep- tual equipment are possible; and automatic scenario-loaded testing could be per- formed. To tie all the system components (actual and simulated) together, i.e., to model the network and to characterize realistic communications queues and delays and simulate full-force scenario loads, a supervisory ACE program is being developed. ACE has been established as a major effort and to effect integration, ACE per- sonnel are actively involved in major HELBAT-8 planning meetings. Production DMDs have teeii Tcquired anid a "DMDM emiltoi pri-gi-amh is heail; conripleled. The FIST DMD emulator and ACE supervisory programs are currently being written. Bat- tery Computer System (BCS) software and hardware documentation has been acquired, and a BCS simulator program is being developed to simulate input and out- put queues, queue management, message interpretation and generation, and functional time delays such as processing time and operation and polling of the gun display units (GDUs). When operating equipment can be made available, an actual BCS wiil be interfaced to ACE to develop a BCS operator training plan for HELBAT 8 and to run some planned I-ELBAT-8 mission profiles. An example of the output of the DMD emulator is shown in Figure 13. Once the DMD program is called up, the commercial-terminal CRT (cathode ray tube) display provides keyboard responses identical to those of an actual DMD. The figure shows the DM1) status display as filled out interactively by the operator and shows the movable cursor at the keyboard bell volume position. In the near future, ACE personnel will interface an actual DMD to the computer system and will work with Field Artillery School personnel to develop initial scenario and experiment designs and with Army Communications-Electronics Command per- sonnel to develop simplified communications characterization algorithms. Under the auspices of the Technical Cooperation Program, Subgroup W Action Group 6 (TTCP WAG-6), ACE researchers are working with United Kingdom researchers who have developed the Computer Aided Staff Trainer (a voice communications command-post simulator) to share knowledge gained in this common work area and to identify polen- tial cooperative efforts for the future. Further ahead, a fire support control sympo- sium may be co-sponsored with the Army Research Office to bring the best thinking of the other services, industry, and universities to bear on fire support control prob- lems. In general, the planned order of ACE work will begin, as described above, with the most basic fire support control ele1ments and continue with the building of higher- level brigade-area elements. The first integrated ACE fire support control system will include the following elements: FO DM1D, FIST D*ND, Battery Computer Systemn (ECS), and weapon system interfaces as shown in Figure 14. This system will provide a reserch tool to begin the study of battery-level technical fire direction issue areas, 140 such as on-board gunnery computers, and some maneuver company-level tactical fire support control issues, such as fire support coordination versus primary FO roles for the FIST chief. Once this first system is operating, the increasingly complex bn and bde FSEs or operations centers must be added to the ACE simulator to address higher-level tactical fire support control issues. Concurrent with the running of ACE system exercises during the summer of '81, another pre-HELBAT-8 effort, the subset evaluations, will begin (at the Human Engineering Laboratory). In this effort candidate subsystems and interfaces will be evaluated and further developed for integration into HELBAT 8, which is now scheduled for the fall of '81. As of this writing candidate DARCOM, TRADOC, and private company systems described below are being considered and in many cases are already being tailored for inclusion in the HELBAT-8 exercise. These systems can be grouped into three basic functional areas: target acquisition, fire support control in the brigade area, and firing battery operations. The HELBAT-8 target acquisition candidates are depicted in Figure 15. As in previous HELBATs, dismounted platoon FOs will operate from terrain vantage points with various laser range-finder (LRF) devices. These will probably include the tripod-mounted Ground Laser Locator Designator (GLLD) and the Marine Corps laser locator designator, the Modular Universal Laser Equipment (MULE), both with automatic data links to the DMD and with developmental or experimental north-finder modules for azimuth reference. Other prototype tripod-mounted LRFs and the soon- to-be-fielded handheld LRF may also be included in the exercise for comparison. The Interim FIST vehicle with a pintle-mounted GLLD (on a standard M113A1 APC) will also be included as an acquisition device with a key issue being line-of-sight (LOS) observation capability from positions accessible by the vehicle. To further address this issue, an experimental telescoping mast-mounted target acquisition/designating system (TADS) is being specifically modified.for inclusion. As requested in the HELBAT-8 priorities (Figure 10), airborne observers will also be included; some will be equipped with stabilized TADS if available. Under the auspices of JTCP VWAG-6, the participa- tion of a tethered observation platform was discussed with a Canadian company, but because of scheduling problems, will not be available in the HELBAT-8 time frame. An experimental computer-based radar netting system was demonstrated at Ft. Sill during early FY 81. This system was capable of automatically analyzing and integrating target intelligence data, from Firefinder (counterfire) radars and ground- based and airborne moving target indicators (MTI) radars, to form confirmed target data lists. Although this system does not (at this time at least) integrate all the brigade-area target acquisition systems, it is an existing hardware concept that could be used to investigate the full brigade-area target integration center (ETC) concept in HELBAT 8 and wveas therefore pursued as a candidate for the exercise. Because of the prohibitive costs involved, this system -will not be available for HELBAT 8; however, tactical scenario-related data message loads may be developed for more fully exercising bde and bn FSEs. This could be acromplished by inserting time-ordered messages into the data communications system using standard DMDs. 141 New concept fire support control candidates for HELBAT 8 are depicted in Figure 16. Target acquisition elements such as pit FOs and the FIST HQ wvill be interfaced to the fire support control system through "super" DMDs that will be especially modified for HELBAT 8 to permit alternative operation on wire line, standard push-to-talk radios, or automatic data distribution system (ADDS) radios. These super DMDs will also incorporate the HELBAT-7 modifications, automatic polar-to-grid conversion and time-tag capability, and will be used by the other target acquisition candidates for data communications with one or more (multiple addressees) of the decision nodes in the brigade-area fire support control system (FIST HQ, bn FSE, bde FSE, btry or bn FDC), depending on the type mission that is being conducted at the time. Experi- mental commercial-hardware Packet (ADDS) radios, which will be mounted in environmentally controlled cases for ruggedization in the HELBAT field exercise, will be the primary communications means in the brigade-area system depicted in Figure 16. Although the Packet radios are not yet militarized and may not be the first ADDS radios to be fielded, in the HELBAT-8 time frame they are the only ADDS radios available to demonstrate dedicated high-technology data communication - the crucial key to reliable and responsive data-world fire support control and more specifically here, to the successful operation of the new-concept HELBAT-8 brigade-area system. For the first time in any IHELBAT exercise, the full fire support control spectrum will be p!ayed: fire support planning, fire support coordination, and tactical and techni- cal fire direction. As shown in Figure 16, the players include both a bn and a br1 FSE, a btry and a bn FDC, and technical fire direction on the guns. In the HELBAT exercise, both the bn and bde FSEs will be equipped with (industry-conceived) experi- mental smart, (flat-panel display) graphics terminals that will be programmed to automatically perform some fire support planning and coordination functions and will automatically monitor and display (with military symbols) standard TACFIRE mes- sages. A standard TACI1RE battalion computer center will be included as the bn FDC and it, like the other players, will be able to alternatively operate on the ADDS radios as well as on standard push-to-talk radios. At the btry FDC, graphics peri- pherals in the form of a printer and a plotter will be added to the FDC computer, and new softrare will be developed and used to permit the evaluation of limited tactical fire direction at the battery level. An existing experimental digitized terrain analysis system may also be interfaced to the battery FDC computer. The btry FDC will be set-up and operated in a tracked vehicle with active NBC protection. This vehicle will be based on the armored ammunition resupply vehicle (ARV) concept that was fabri- cated on a. M109 howitzer chassis for HELBAT-7; the use of an ARV vehicle will afford the FDC a nonunique signature in the battery area. The weapon systems, which will be included in the new concept brigade-area firing blattery, are described in detail in Figure 17. Building on lessons learned with Howitzer Test Beds (HYBs) 1 and 2 in IHWIBAT 7, HTB 3 and 4 are currently being designed and fabricated as follow-on efforts. Both new howitzers will incorporate ADDS radio automatic data links, on-board technical fire direction computers, gyro systems for local self-survey and pointing reference, and gunner display units (GDUs) and chie.f-of-sectjon display units (CSUs). Hf-1B 3 will be a fully integrated systlmn using a gimlbatled gyro sysLem and servos to permit even automatic laying (aiming) of 142 the gun tube, while HTB 4 will incorporate hardware that has been developed for other applications. HTB 4 will utilize (trunnion mounted) strapdown gyro hardware that was developed for the Advanced Attack Helicopter and the FIST DMD hardware reprogrammed to perform modified point-mass gunnery as well as the standard TACFIRE data message terminal function. Both HTB 3 and 4 will use automatic feed- back from ballistics and fire control error sensors to investigate methods of improving predicted fire, and both will also be interfaced to the new prototype armored ARVs. A wire-line or radio data link between the howitzer and the ARV will be used for communications, and the ARV auxiliary power unit (APU) can supply electrical power to the howitzer as a redundancy option. A summary of the ACE-i and the HiELBAT-8 plans is depicted in Figure 18. Note that a complete standard TACFIRE brigade-area system (including the Variable Format Message Entry Device (VFMIIED) for the bn and bde FSEs) will be operated in HELBAT 8 to collect common baseline data against which the performance of the new concept brigade-area can be compared. Both the bde FSE and bn FDC will alterna- tively serve as standard and new-concept elements. Although the FIST chief and bn FSO may be separated from their respective HQs or element, this communications complication will not be played as indicated by Xs. Although not discussed above, the following equipment will also be included in HELBAT 8: Marine Corps Digital Com- munication Terminals (DOTs, a digital data terminal with graphics) and Mortar Fire Control Calculators (MFCC, a data-communications mortar gunnery computer). The Fie'd Artillery M\Veteorological Acquisition System (FAMAS, a developmental system that can automatically update ballistics met in TACTIRE) was pursued for inclusion in HEiBAT 8, but could not bs made available; met, however, will be provided via data communications (from a V.EMED) for HELBAT 8. Under the auspices of TIfCP WAG-6, various international hardware candidates for H-ELBAT 8 were discussed, but for various reasons, none could be made available; however, UK representatives will participate in the exercise and a CA officer will work with the HELBAT Working Group from May until December 1981. 143 cit: zo c~c ad +~~~~~~~~ X~~~~~ o~~~~~~il o U ~, 144 ilXU ?V4 z~ - l- j~0 0 0 00 0 0 0 4 - I II I - 145 I,~a l dr · U o0>;> > d 00~~0 0 0 0 0 00 o0~r Qw rO C,,~~~~~~~~o 4-40 Cd~1- la 1 cd O 'O "O 0 f1 ©i 0I 1-44 r\ kcn rP1~~~~~~~~~~~~~~~~~~~.5-c 4-a I~~~~~~~~~~~~~~~~~~~~~~~~~~~4-t--4 ~~~~o · - 0 P...~. (9~~~~0. o O -o 6O 0 cd0 t-~~~~~~ t-4 - ~ ~~4Qcn H q 4 JO k 0 0 Cd 1-Il CdQ1 T4 l O ooi- CJ21- 4 F4146 cnc cn 0 fT v , :O j 0)0 Cd) 146~~~~~~~~~~~_ Q Q L] L.. co BcoO lr7 tie 147 -ALL~~~~L L )t~~~~~~~~~~~~~~~~~~~~~~~~~~~~hl 'Al L rL. '-a C , '?~~U It. rjo t, 0 0 o c l~lLL8 C-·i~~~~~~~~~~~~~~~~~~~~~~~~~f~~ ~ ~ ~~~CI-·l~~~~~~~~~4 14i8i 0 ~1 V*I' m C.2 - Z ,-~~~~~azS~ o o o t a rdIdYaa 149 I~~Xdz u~~14 ~~ c4 ~~~~~=I m > CD Cam co2 C3 CD r-4 ' LU CD cnt~[' "'1 IL, :P- L our~ ~n 1 50 C3 X~Z 3 ui uJ X WJ:~ nr C3 elL jT/3 n7 f= uj m) ;o _;I -DCC C) - CYCa Ca Z~~~~n . LL · )1 E4 LL DCi l: LL CLC3 cn Cf tj ,i, ~~i uru h , Ca cr- cx - LLJ L ( 2C C C3ma < C3 C ' U. _ '- -' z~= ° UfCDI fim o~~~~~~~wC3Cam C LUJ S C3~~ ~ ~ ~ ~ ~ 3 d Ct C)~~~C ~~""~" CS~~r~~ia= c39= cc ui Zcld C- -j 3 - 3 · ~ U cr- <~~~~--Ll a C~~ Ca LU o U- LL. c) cr c-3 cr Ca c co uJ V) JL cr c )--->-# b, d·~~ cm En en t Li- a CQ = CV U- 151 LU ylf cn ~L~l 1- - 0 > LU =llfcxz3; )~Ta t'f C) ~· VC -~ ~ QeI Lii 0.C:) ~LU0 WLE =3 = 3LU CDC= V ess; 2 ~ CCU1 C: cj c1c5 (4: U. 5 LLI C1 tC- tl ~-· U u, : e LU 1-a.= u C3 I ~~~ e~ Llu, ut X l2I a: :ctXnX=m C:) Lu :3 C _ ea 1 1 a: Z| zZ Q=~~~~~04C) F o ~ ~ b Q oci 152 C, ~0 I Z u _C)I PLU w J t *=< 15153'e Z @ LU z~~~il> W : ' < I W W W~15 ~4 H~~~~~~~- H~~~~ r-4 0.q .C 0CJ Cd~~~~~~~~~~~~o cn 0 E E-., ~ )2 5Z 1 2 00G 00 ~ ~f_ Qmm O~~~~~~~O 3 O 154 0 ca 4 -~ h a~, 155 tp~~M za0 ~ ~I ' r~i~ caaP4gOO 1551 6 C 4-J :.J * . c . ;:: .n a c\Ja I ~ rcog -I~o r' G,) uarwm to n I I :4E t3 D-xxx., 156 BI~~~~~i SI~~ *1l I-, a I~~~~~~~~~~~~~~~~~~~~~~~P UCl 0 IA . *·Y~Et S: it VIU P4~~~~~~P 9.4K 157 LU uJ~~~~~I E> 2 Mi~~~~~~i 2 U 1B~~~~~~~~~~~~~a~~z158~1OU ' \- Q 0~~~0u~~~~~~~~~~~~~~~~~~a.. > . UnUZ ~~i0~ 0 LM M LLzIUJ LL Ii Ega- [# Licr C a~~~~~~- - a F- W X a1 aO .1 z~~~~~U799 P LU a: _ w (I~ X- 61 58I- ~~Ze 07ce a~~~~15 U ~~~:o. i -~:zc r~)-I~ ~ ~ ~ ~ ~ ~ ~ ~ r- HQU~ ~~~~~O 0 V .. oz mz Q --. z ._.k¢ ;;J. CI) 0~~~~~~ 0 < LL~~~~~~~~~~~~~~~~~~~~J · L 159 U,~~ ~ c- ~ ~~~C IL'~~~~~~~~~~~~~~~~~~~~-71 crc cn r~~~~~~~~~~~~( LL~~~~~~~~~~~~~~~-/.- L <-. LU ~ ~ ~ ~ U ui 0>-~~~~~~~~~. er~r,_) ~~~I(~_~ ~ ~ t ~- ~~ ~ ~ ~ !~ U . ;3r- E-r~~~~~~~~~~~~~~~~~~~~~~~~~~~~~_C - cc ~ CC CL 0~-r I I C13 < ( i ~~~~-o~~~~~-C 0> z C~~~~~ Mw -t ~ ~ ~ ~ ~ C ~~--I ~ arO C15 Z -'B. B I B = = -- u.Iw crwN : Z :3LOE O on a- t -U L c0c _ 4coFi_ l U 1 w Ca3- k >t - a O: ts1 UJa. dut D I , ,. oo . u~ (n 1~EE 160 0 Cf) z LOL P fLi 0 0 2nLL > - -4 _ / e LLWS 1 Lr l 44( (p(1- .- U Lt e, 0a·a ~~0 a 0 0 0Q~ Bibliography 1. Oerations, Department of Army (DA) Field Manual (FM) 100-5, 1 July 1976. 2. Fire Support in Combined Arms Operations. DA FM 6-20, 30 Sept 1977. 3. Field Artillery Cannon Gunnery. DA FM 6-40, ~Nov 1978. 4. "Close Support Study Group 11 (CSSG 11) Final Report," US Army Field Artillety School ACN 57393, 1 Feb 1980. 5. Field Artillery Cannon Gunnery, DA FM 6-40, 5 Oct 1967. 6. "Guide for Fire Direction Operations," US Army Field Artillery School (USAFAS) Gunnery Depart- ment, May 1978. 7. William J. Dousa, Jr. aod Cary L. Horley, "The Roles of Laser Syslems in Artillery Use" US Army Human Engineering Laboratory (USAHEL) Technical Memorandum (TM) 9-78, Apr 1978, (Conf.). 8. William J. Dousa, Jr., "A Surmmary of Capabilities of Artillery For-ard Observers Equipped with Laser Rangefinders," USAHEL TM 9-80, May 1980. 9. Tactical Fire Direction Svsiem. DA Training Circular (TC) 6-1, 15 July 1977. 10. "TACFIRE Reference No-e," US Army Field Artillery School Reference Noie (RN) FC--AA, Dec 1976. 11. Edward D. Ray, "TACFIRE - A Quantumrn Leap in FA Data Processing," Field Artillery Journal, VoL 47, No. 3, May-Jun 1979. 12. Unpublished data from INLAJ L. Morris, TACFJIRE-TSM Office, USAFAS, 23 Apr 1980. 13. "User Ealuation of the Tactical Fire DLiection System AN/PSGIO (TACFIRE)," distribued by USAFAS TACEIRE-TSM1 OErhe Letter of Transmittal, 2 Oct 1979. 162 14. Cannon-Lanched Guided Proictile Reaction Time VieTraph presented by Edwzrd Smauch, Army Maleriel System Analysis Activity, at Third Artillery System Engineering Working Group In-Process Review, 1 Aug 1979. 15. R. B. Pengelley, "HIE_13AT - The Way to Tomorrow's Artillery," Inlernational Derenrce Review, Jan 1980. 16. Thomas E. Kinney, Jr. and Michael G. Golden, "HELBAT-7 Sublest - Ammunition Handling Study", USAHEL TM 4-81, 1Mar 1981. 17. Michael G. Golden and Frank R. Paragallo, "HELBAT-7 Subtest - Howitzer Emplacement and Fie Control Accuracy Study," USAHEL TM 15-80, Aug 1980. 18. Barry L. Reichard and LT Sam Chamberlain "FIST Vehicle and Associated Equipment - Prelim- inary Hardware Evaluation Comments," US Army Ballistic Research Laboratory Paper, Mar 1979. 19. "A Report on DRS," by LTC Homer J. Gibbs, Field Artillery Journal, Vol. 46, No. 3, May-Jun 1978. 20. "3x8 Direct Support Field Artillery Bantalion - Armored and Mechanized Infanury Division - Organ- ization ard Operational Concept," US Army Field Artillery School Document, Apr 1980. 21. Discussion with MAJ David Scott, TACFIRE-TSM Office, USAFAS, 23 Apr 1980. 22. "Command and Control of Surface to Surface Artillery (1°86-2000)," USAFAS Draft Concept Pa- per, 25 Jun 80. 163 164 A PRACTICAL APPLICATION OF MAU IN PROGRAM DEVELOPMENT BY Major James R. Hughes United States Marine Corps Concepts, Doctrine, and Studies Development Center Quantico, Virginia 22134 165 INTRODUCTION: Recently, the Systems Analysis Branch at the Marine Corps Development Center analyzed the Soviet threat employing the Multi-Attribute Utility Model. The Soviet force consisted of a Motorized Rifle Division. The purpose of the analysis was to identify the critical intelligence parameters required for documentation to support acquisition of a Mobile Protected Weapons Systems (MPWS). The analysis enclosed herein includes: o Application of the Multi-Attribute Utility Model. o Identification of general attributes important to the success of the MRD. o Utility curves (Appendix C). o Identification of attributes desired in the MPWS for countering the identified threat. 166 METHODOLOGY: The analysis applied the Multi-Attribute Utility Model to identify the weapon systems/equipment which an MRD commander would emphasize during Offensive Combat Operations. The salient attributes were initially identified during a brainstorming session. The group included intelligence experts from within the Marine Corps Development Center. In the application of the Multi-Attribute Utility Model, a problem is decomposed into clearly defined components in which all options, outcomes, values and possibilities are depicted. Quantification in the form of the value for each possible outcome and the probability of those values being realized can be in terms of objective information or in the form of quantitative expressions of the subjective judgments of experts. Beyond its primary role of serving as a method for the logical solution of complex decision problems, multi-attribute utility analysis has additional advantages as well. The formal structure of the analysis makes clear all the elements, their relationships, and their associated weights that have been considered in a decision problem. If only because the Multi-Attribute Utility Model is explicit, it can serve an important role in facilitating communciation among those involved in the decision process. With a decision problem structured in this type of analytic framework, it is an easy matter to identify the location, extent and importance of any areas of disagreement, and to determine whether such disagreements have any material impact on the indicated decision. In addition, should there be any change in the circumstances bearing upon a given decision problem, it is fairly straight-forward to reenter the existing problem structure to change values or to add or remove problem dimensions as required. It should be emphasized that in no sense does this analytical approach replace decision makers with arithmetic or change the role of wise human judgment in decision making. Rather, it provides an orderly and more easily understood structure that helps to aggregate the wisdom of experts on the many 167 topics that may be needed to make a decision and it supports the skilled decision maker by providing him with logically sound techniques to support, supplement and ensure the internal consistency of his/her judgments. The complex decision problems confronted in any developmental program can be difficult to resolve for a variety of reasons. Frequently, options are not clearly defined, the results that might be achieved by opting for one choice over another may be highly uncertain, and it is often difficult to determine relative preferences for the possible decision outcomes. Certainly, almost everyone has encountered decision problems characterized by such uncertainty. Usually, the reaction is either to devote more thought to the circumstances than would normally be afforded, or to resort to various devices to help sort out the decision such as listing pros and cons for each option, rank ordering preferences, listing the things that could go wrong, and so on. In either case, whether through extended contemplation of the problem or through recourse to more explicit written aids, the person with the problem, the decision maker, attempts to lend structure to the problem to reduce it to a more explicit tractible form. In a much more systematic and formal way, that is exactly what multi-attribute utility analysis helps to do. Initially, in this application, the breadth of the threat was deduced. After extensive discussion the threat was conceptualized as follows: o Potential adversaries will take advantage of the availability of sophisticated, highly-effective and highly mobile weaponry in all levels of conflict. o A common characteristic of all potential adversaries is their near- total dependence upon the USSR for the material means of conducting war. o As with all Soviet military doctrine, the principles of defense against amphibious assault have as their goal, the creation of conditions which will allow the Soviet commander to initiate decisive action while denying the landing force commander the same capability. In futherance of their goal, the Soviet defense is based upon high- 168 intensity mobile operations using large numbers of tanks and armored fighting vehicles, extensive use of supporting arms and tactical aviation, and echeloned, defense-in-depth deployed in an integrated combined arms concept. o As an outgrowth of this concept of defense, certain Soviet weapons systems will be of particular concern. The mobility, firepower, and protection offered by tanks and armored fighting vehicles will afford the Soviet commander a decided advantage against Marine landing forces as they are presently equipped. This capability will be greatly enhanced by the introduction of the T- 72 and T-80 series tanks, with their vastly improved armor protection, power plants, armament and fire control systems. More than 200 such tanks will be encountered in a representative motorized rifle division, the primary tactical element against amphibious assault. Infantry mobility and fighting capability will also increase with the introduction of improved armored fighting vehicles of the BMP, BMD, BTR family, more than 400 of which will be encountered in the motorized rifle division. o In addition, infantry in prepared defensive fortifications, will also confront both waterborne and helicopterborne assault elements. o The Soviet commander will also enjoy an increased capability to employ air and artillery delivered ordnance against the landing force. Tactical aviation will expand dramatically with the widespread use of attack helicopters such as the HIP and HIND. Artillery will increase both in numbers and mobility with the self-propelled 122mm and 152mm gun/howitzer playing an expanded role. 169 The general conceptual attributes which contribute to the success of the MRD are: o Offensive Combat Operation o Defensive Combat Operation Although an MAUA was conducted for each only the former will be presented here. 170 The MRD in Offensive Combat The three types of offensive action are: o Meeting engagement o Breakthrough o Pursuit Meeting engagement The meeting engagement, i.e., the collision of two opposing forces, is stressed more in Soviet military writings than any other form of offensive action. Because of the fluid nature of modern war, the Soviets believe that the meeting engagement will occur more often than any other type of combat action. Meeting engagements are characterized by action to sieze and maintain the initiative; the development of combat on a wide front with freedom of maneuver and the presence of open flanks; rapid deployment of troops, chiefly from columns; mobile, high speed combat, and often incomplete intelligence on enemy forces. The Soviets believe that it is both possible and necessary to anticipate meeting engagements; that through various intelligence gathering means they will be prepared for and will aggressively seek out such engagements. The Breakthrough The classic breakthrough operation is a frontal assault against a well- prepared defensive position, using a large amount of artillery and maneuver elements on a narrow front. The breakthough may also loccur against a hasty defense. Against each type of defense, the Soviets envision a swift and deep envelopment, the bypassing of stubborn pockets of resistance, decisive meeting engagements with advancing enemy reserves, continuation of the attack, and the subsequent destruction of enemy strong points by second echelon units. Breakthroughs may be accomplished in short periods of time due to nuclear strikes and the increased lethality of conventional weapons. Successfully conducted meeting engagements and breakthroughs result in the pursuit and ultimate destruction of the enemy's forces. 171 The Pursuit Operation Pursuit operations are highly mobile in nature and are best conducted on a wide front along parallel routes. It involves both frontal attacks and envelopment to cut off and destroy enemy forces. Pursuit operations are made more effective by the use of tactical heliborne and airborne forces, which occupy and defend locations in the enemy's rear and otherwise disorganize and delay his retrograde movement. The Soviets stress that the pursuit is to begin immediately upon the initiative of the commander who discovers the retreat. "Maneuver" is defined in Soviet military literature as the movement of a force into a favorable position in relation to the enemy, from which it can launch an effective attack. The Soviets mention two basic forms of maneuver, the frontal attack and the envelopment; but favor the latter which may be shallow or deep, depending on the size of the unit executing it. Should the enemy not have an assailable flank, a frontal attack would be used. A frontal assault may occur on a wide or narrow front with or without heavy fire support. Tank heavy second echelon forces attempt to exploit any rupture in the enemy position. Under favorable conditions, however, the Soviets would attempt air envelopment, possibly in conjunction with a frontal attack to pin down enemy forces. Envelopment is the preferred method of maneuver in the meeting engagement and is used from platoon level up. Accordingly, mobility, and those attributes which contribute to mobility are heavily weighted in offensive operations. In fact, mobility composes .43% of an MRDs offensive capability. Conclusions o The MRD relies on speed and those attributes which contribute to speed. o The HIND, TANKS, BMP and self-propelled artillery are the greatest contributing factors in the offensive capability of the MRD. o If concentrated efforts are made to constrain the speed with which an MRD moves, maneuver and flexibility will also be affected. 172 Firepower in the Offense Artillery fires in support of offensive operations are subdivided into three sequences or phases. o Preparation fires, centrally planned and executed are normally 30 to 60 minutes in duration and immediately precede the attack by motorized rifle and tank forces. The preparation includes conventional artillery fires and air preparation and many include strikes of rockets and missiles. The artillery preparation normally is initiated with a powerful, surprise fire onslaught of all the artillery and mortars against strong points in the main battle area and simultaneously against U.S. artillery and mortars, dug in tanks and antitank guided missiles, command posts, radars and reserve forces in the immediate defensive positions. A second powerful fire onslaught, with the main mass of fire concentrated on artillery and mortar batteries, command posts and strongpoints, is timed to coinside with the attack of the motorized rifle and tank forces. o Fires supporting the attack consist of scheduled and on-call fires in support of the motorized rifle and tank forces. As attacking forces near U.S. positions, the preparation fires are shifted, and fires in support of the attack commences. Opposing force artillery doctrine requires continuous support of the attacking force with artillery and airstrikes, right up to the accomplishment of the combat mission. This technique insures the constant neutralization or destruction of the U.S. force by concentrated fire. o Fires through the depth of the U.S. defense are planned to give uninterrupted fire support during the neutralization of successive and final objection. Displacements of artillery normally are required during this sequence and are made so that not more than one-third of the supporting artillery is out of action at any given time. When the attacking motorized rifle and tank units have advanced so far as the U.S. regimental/brigade reserve and main artillery positions, control of artillery is decentralized and the artillery groups revert to the control of the supported regiment or division commanders. 173 Conclusions: o Firepower is the key to successfully conducting offensive operations employing an MRD. o The Tanks, BMP, HIP and HIND and self-propelled artillery provide the bulk of the MRDs firepower capability. o Firepower in the offense contributes .48% of the total combat power of the MRD. o Priority of targeting should go to the self-propelled artillery and aviation in order to denude the BMP and TANK of their supporting fires. In conclusion, the MAUA provides an effective method for evaluating the deficiencies of a systems mix in relation to the threat. As a result, by conducting the MAUA, the requirements for the MPWS were more easily recognizable. Additionally, the specific attributes desired in the system were more easily defined and placed in this proper relationship to one another. The multi-attribute utility approach described herein has a number of advantages. First, it permits an individual who is an expert in a particular area of expertise to narrow his judgment, rather than making an overall judgment of worth, which may fall outside his area of expertise. Second, disaggregating the judgments of individual experts provides an explicit trail leading from measures of system performance to measures of benefit or utility. The judgments are public rather than private and are subjected to screening. Appendix (C) demonstrates the same resultant utility curves from the MAUA conducted in conjunction with the threat assessment for the MPWS. These curves demonstrate some of the attributes desired in an MPWS. It should be noted that C3 was not considered to be an important attribute because of the fast moving environment within which MPWS will function. By the time the enemy knows where you are, you are no longer there. Therefore, communication security plays a smaller role. 174 APPENDICES 175 APPENDIX A 176 Important Attributes to be considered for MPWS as a result of the MAUA: o MPWS must be transportable by CH-53E helicopter. o MPWS must be strategically and tactically air transportable. o MPWS must have amphibious shipping compatibility. o MPWS must have a fording capability. o MPWS must have an NBC defense over-pressure capability. o MPWS must be capable of being transported behind enemy forward elements in order to disrupt or delay attack of the second echelon of a motorized rifle division. o MPWS must be capable of providing forward, rearward, and flank security for an armor equipped force. o MPWS must be capable of conducting advance force operations in order to cause premature and misdirected commitments of enemy main forces and/or to disrupt/interdict enemy lines of communications, main supply routes, and command and control facilities. o MPWS must be capable of providing assault support and anti-armor protection to an infantry unit operating within an extended tactical area of responsibility. o MPWS must contribute to speed mobility and flexibility. 177 APPENDIX B 178 U) w CC LIO v,~~~~~~T ',' U----.- - coHCC 0 O cr) " v -CO 0 cr Z) C/) ~L: o o C LIoo I~! ~ ~ ~ ~~~~~~ co co ~C-rL oLUm)~~UU m?Z ~~~~~~~~~~ W r I C0 2 - U: W0 F- ro U, co ~.LU I - i . ' 2 Hrnc- n: 0r~> ~z- O 0 ccc~- - <.. ~1' < Z ~~~~~~~~~~-rI0 H c Q~~~~~~~~~>Z- I u, o LL~~~~~~~2 _~~~~~L> z,~~~~~~~~~~~~~~~~r, Lij t (N (- j 9 < 020 2 coU)< -, U) -) o~~~~~~~~~~c. I--, CN N rn- n IL toC/ C < cr c F-v0UC,),2 E F--~~ O ~~ ~ ~~~~~~~~~~~~~~~~~~mF- o, v, O~~~-(j F-ccLO co U to < " NN CD 179 z c o I -z cc -< m >r .J' a co~E -, w w O. ! .r'~- Q L_.--- . :: I Eo m L X t I > < B 0CaC 0_. 0 m < ..j> r' ow -Jto 180 !--H- w C- N 18 APPENDIX C 181 I. The following utility curves were developed subjectively using MAUA and reflect the consensus of the operational community as opposed to the analytical community. A. Firepower considerations include lethality, accuracy, target acquisition, servicing rate and stowed kills. (1) Lethality is measured in terms of probability of kill given a hit, or P(K/H). Lethality is considered against tanks, light armor, materiel, personnel, and helicopters. In all cases, this lethality can be achieved with any weapon system on board the MPWS (gun, missile, or other). (a) Lethality Against Tanks - Considers the T72 tank as the worst case target. A kill can be either a mobility or a firepower kill (M or F kill) which requires more than 24 hours to repair. Probabilities for P(K/H) assume a cardioid distribution and single shot or burst per trigger pull. 2KM is the most likely range, but better standoff is preferred (4KM). At 4KM, P(K/H) is terrain limited rather than vehicle limited. UTILrT - L t t11-1 tI I I I I I X]t - 1tllrr /lY_ . _ __ Hi VslX I _ I 182 (b) Lethality Against Light Armor - A high probability of kill given a hit is important to eliminate the light armor threat. This will enable other antitank weapon systems to concentrate on tanks. A kill can be either a mobility or a firepower kill (M or F kill) which requires more than 24 hours to repair. BMP is the expected target; cardioid distribution is used; BMP threat is severe at 2KM and more limited at 4KM; therefore, the curve for 2KM rises very steeply at higher probabilities. MPWS must achieve P(K/H) of .4 at 2KM, .2 at 3KM, and :1 at 4KM or it has little value. ! J I 1 } I ) ] j i t I I s _ _ _~J~j] _ ] ]t _ _ I 1 I MC It _ _t_ 1 t X XI I l '! r13t3 -A 133 Lethality Against Materiel Targets - Materiel targets can include 8" reinforced (horizontal and vertical) concrete at 3000PSI strength; 16' x 12' wall; bunkers can include 6" x 6" bolted; 2' sand on roof; 4' enclosure; 7' sand (outside to 1st timber); 18" bunker and sand above ground. Bunkers and bunker type targets are important in infantry support in places in which tanks have difficulty trafficking (for safety or other reasons, such as MOBA). Bunkers are the most demanding target in MOBA. The utility is a function of percent of basic load required to achieve a catastrophic kill (render unusable) at 2KM. Utility drops very rapidly if it takes more than 3% of the basic load, and not much utility is gained if more than 10% is required. If the percent of load is high, MPWS will need to resupply too frequently. MO I2.Ea 1-G... :TR(IKI) ) } NL I I IIl) I II1 I]ENt Klt I11an tl PC IC CA tllt lkSTLtYILL A M lIRIlt AP-El 51 2.tX ' 184 (d) Lethality Against Personnel Targets - The measure of effectiveness here is the ability to kill or suppress personnel with a probability of .8 as a function of range. Most of the benefit is gained at a range of 1000 to 1500 meters with 80% of the utility achieved by 2000 meters. I :, :j jjIj.c 135 (e) Stationary MPWS - Moving Target - A fixed range of 2000 meters was used, and the target was assumed to move at 20KM/HR crossing speed (12.4MPH). This parameter is an indicator of how well the fire control plus main gun performs. There is no value if the MPWS cannot achieve P(H) of at least .3. T_ [Tt EI. I II 2. -1 .Q _I I t l .I i l -F 1 .36.2 . . . .7 136 () Moving MPWS - Stationary Target - This assumes that MPWS is moving at 20KM/HR., (12.4MPH), and line of sight is constant. A range of 2000M is assumed. A large increase in utility occurs if P(H) can be pushed beyond .3. r~ll, 187 (g) Accuracy of the Secondary Fire Control System - The utility curve assumes line of sight, perfect environment, and a stationary target at 2000 meters. The secondary system can be less accurate than the primary system but still must achieve P(H) = .4 to have any value. FC"1d- I ~ f Fr IXI* 1 Xo|7 .4 .A .X .I .1I 1.0 PaC (h) Lethality Against Helicopters - The curves assume a hovering helicopter has been acquired at 4000 meter standoff range, and MPWS is stationary. Lethality includes kill or suppression. In this case, probability of kill equals probability of hit. The curve starts to rise more rapidly if P(K) of at least .5 is achieved. O S· -t i ..1 I 1 1 1 t ttJ_ i-T- r r X1 111 I iI tI ~ ': -- : t II I , j i ---'"T]r~ _ .it / ~ i - i o .1 .2 .3 .4 .s .t .7 .I .! 1.0 189 190 HIERARCHICAL VALUE ASSESSMENT IN A TASK FORCE DECISION ENVIRONMENT BY Ami Arbel Advanced Information & Decision Systems 201 San Antonio CirclZe, Suite 286 Mountain View, California 94040 191 Hierarchical Value Assessment in a Task Force Decision Environment By Ami Arbel Advance-d Information & Decision Systems 201 San Antonio Circle, Suite 286 Mountain View, California 94040 ABSTRACT This paper presents a new approach towards the derivation of a value function to be used in decision problems faced by the CTF and his staff. This value function is task-dependent and may vary from one decision environment to another. This specifity is what distinguishes this approach from others where *the value function is developed external to the decision problem. 192 1. INTRODUCTION. Decision problems at the task force commander (CTF) level involve issues that are complex and, at times, critical. This complexity together with complicating factors such as time pressure and stress associated with this decision environment may degrade the quality of the decision process itself. This general background motivates the effort directed toward develop- ing decision aids for the CTF and his staff. . Decision'aids developed thus far resulted in models describing re- curring situations such as emission control and transit planning, as well as structuring aids for general decision problems. The problems considered in the second class are those that can be addressed and solved through a decision tree formulation. Such decision problems are solved after developing the structure appropriate to the problem itself. This structure starts with a general iden- tification of cause and effect (influence diagrams) which leads to a decision tree description. Next, probabilities have to be assessed for the various events described. Last, by assigning certain values to anticipated events, a preferred course of action can be prescribed. The question of "value" is addressed through the concept of utility. This results in a number being assigned to outcomes that permits their evaluation. This utility function is assessed by' talking with the CTF and members of his staff, and used as a true representative of their choice-making attitude, when- ever a choice has to be made in the decision process. This utility, or value function, is supplied as input to the process and used in various decision prob- lems. In considering various decision making scenarios it is easy to see the deficiencies of this approach of supplying a value function external to the decision problem. As an example, consider the value associated with two types of airplanes, say an F-14 and an A-7. One may be tempted to compare firepower, speed, and general sophistication and conclude that the F-14 is, say, four times as valuable as the A-7. While this conclusion may hold true in most 193 situations, it should not be accepted as the universal value assessment. This is so because there may be certain missions (e.g., tactical air strikes) for which the A-7 will be far more valuable than the F-14. This paper presents an approach towards value assessment in the task force decision environment. The approach organizes the value problem into an hierarchy that considers all the factors that are relevent to the value question. The end result of this hierarchical value assessment approach is a task-dependent value function (rather than an external input). The structure of this paper is as follows. Section 2 considers the general task force decision evnironment. Section 3 presents the analytical foundations of the approach. Section 4 presents the specific steps involved in establishing a value function, and Section 5 presents a summary. 2. A TASK FORCE DECISION ENVIRONMENT The Naval task force decision environment described in reference [1] highlights the fact that decision processes followed by task force commanders vary from one CTF to another. In very simple decision problems the decision may just be a snap judgement with no structured process (even though it obviously draws on the CTF's past experience). In other simple, yet routine, decision problems an old operational order can be used as a guideline in drafting a new one to meet the particular situation at hand. General guidelines for decision making in more complex situations are offer- ed in various naval publications. 194 In complex, nonroutine, decision situations the approaches mentioned above cannot be relied upon in formulating a course of action. Even the avail- ability of naval publications like NWP-11,and others, cannot be relied upon as a sole source of aid in these complex situations. The reasons for this are simple. When under time pressure it is likely to ignore some factors or options and settle on a picture of a limited scope (optimizing vs. satisficing). Also, in these cases we have what is known as "judgement by availability" [2]. When under time pressure and in a generally stressful environment decison making and judgement ability will be greatly degraded. These factors are the general moti- vation for developing operational decision aids to be used by the CTF and his staff in these situations. The main responsibility of the CTF is in formulating and executing a plan of action called upon to meet a certain perceived situation. This decision environment is described in Figure 2.1. The decision aid depicted in Figure 2.1 interacts with the CTF and members of his staff to elicit inputs that will allow the formulation of a plan which is the end product of this particular decision process. The basic elements'of this process are discussed below. The perceived mission and its environment (time pressure, criticality, past experience, etc.) are major factors affecting the decision and judgement qualities of the CTF and his staff. This particular block is drawn in broken lines in Figure 2.1 to indicate that it is not an explicit element of the pro- cess but it does contribute to the overall quality (or lack) of the decision process. The interaction between the decision aid and the CTF and his staff is done as follows. The CTF defines the general decision problem to be considered (choice among options, priority assessment, planning, resource allocation, etc.). The decision aid, through prompts and queries, elicits various inputs from the CTF and his staff in the form of requests for judgement. The prompts and quer- ies in a well designed aid, will follow a logical sequence that is particular to the decision problem stated initially by the CTF. For example, in the case of a choice among options, one may be interested in developing a decision tree description of the system. The decision aid should follow a sequence of quer- ies directed toward eliciting, in an interactive step-by-step manner, the particular structure as envisioned by the CTF. Attempts toward this kind of com- 195 PERCEIVED MISSION AND ITS ENVIRONMENT ' \ / \ / CTF AND STAFF Ctel 196 PLAN puter aided structuring of decision problems have been reported in [3] and [4]. The result of the effort in this stage is a "model" that attempts to describe the situation faced by the CTF. The particular model developed may vary, and may include submodels such as decision trees, strike outcome calculator, EMCON, etc. The development of a model, detailed as it may be, does not lead immediate- ly to a plan of action. The reason for this is because the situations described in the model are evaluated according to some value scale. Utility theory was developed and successfully applied in many decision problems. Military situa- tions offer a class of problems where a value scale (i.e., a utility function) cannot be developed "off-line" in a manner disjoint from the problem under con- sideration. For example, in considering short-range operations (e.g., defense of main body of task force) an F-14 may prove to be of much higher value than an A-7. In contrast, in considering an air strike this value assessment may reverse itself. This simple example demonstrates the need for a value model to be used in conjunction with the model in deriving the plan of action. The plan of action which is the end product of this process is directed toward solving the problem faced by the CTF. Specifically, this may include types and sequences of military actions, force compositions, and resource allo- cation (e.g., equipment, personnel, supplies, etc.). The approach taken here toward the development of a value model is through the development of hierarchical value assessment schemes that are task- oriented. The value model can then be incorporated into, for example, a de- cision structuring process (such as reported in [4]) to yield an integrated, robust, decision aid. The technical foundations of the proposed approach are detailed in the next section. 197 3. HIERARCHICAL PRIORITY ASSESSMENT The hierarchical value assessment scheme presented here is based on Saaty's approach to hierarchical decision problems [5]. The basics of this approach will be reviewed here and will be used in a naval decision problem in the next section. The Analytic Hierarchy Process is an approach recently introduced by Saaty [5]. In this approach, the decision problem is decomposed into levels containing objects with similar attributes (e.g., a level describing object- ives and a level describing policies designed to meet these objectives). The approach is directed toward assigning priorities for each member in a partic- ular level. In particular, one is interested in ways to propagate the prior- ities of each level throughout the hierarchy to establish priorities in a part- icular level of interest. Consider, for example, the situation described in Figure 3.1. LEVEL I: OVERALL GOAL GOAL LEVEL II: OBJECTIVE #1 OBJECTIVE #2 OBJECTIVES LEVEL III: POLICY #1 POLICY #2 'POLICY #3 POLICJES. Figure 3.1 Hierarchical Policy Evaluation 198 The decision maker has to evaluate the relative importance (prior- ities) of the 3 policies under consideration; this, in turn, will help him later on in allocating resources to implement these policies. The policies themselves are designed to meet certain objectives (2 in this particular case) that contribute to the overall goal the decision maker is trying to attain. In constructing hierarchical structures other than the one shown in Figure 3.1, the following guidelines should be remembered: 1. The number of levels used in a particular hierarchy is not fixed and should be chosen to reflect the particular problem at hand. 2. The order of the levels should be one that reflects a logical causal relationship between adjacent levels. 3. The number of members in a particular level should be chosen to describe the level in adequate detail. The points mentioned above indicate that the construction of a particu- lar hierarchy is not a process that follows-rigid rules but rather adapts itself to the situation at hand. Deriving the actual priorities of members in each level is done through a pairwise comparison between each member of the level, relative to a member of the adjacent upper level. Let-us start the technical discussion by demonstrating the derivation of priorities among a set of activities. For illustration purposes, let us con- sider 3 activities denoted by Ai , i-1, 2, 3. We will compare the contribution of these activities to a certain objective. This comparison will be carried out pairwise and the result of the comparison will yield the relative weight, wi, of the activities under consideration. This pairwise comparison can be summarized in a comparison matrix A given by 199 Wl/wl Wl/w 2 Wl/w3 A = W 2 /wl W2/w2 W2/w3 (3.1) W 3 /wl W3/w2 W3/w3 The information displayed in this matrix is interpreted as follows: every element, aij, of the matrix A shows the relative contribution to the objective of the i-th activity compared to the j-th activity, i.e., a A 'i l This definition indicates that 1 aij aji (3.3) which results in the matrix A being a reciprocal matrix; note also that the diagonal of the matrix A in (3.1.) is l's. Going back, for a moment, to Figure 3.1, one can construct a comparison matrix that shows how each of the 3 policies contribute, say, to objective #1. Every element of this matrix can be obtained from this line of 'questioning: "Consider, for example, policy #1. and policy #2; which · one contributes more toward objective #1 and what is the strength of this contribution?" Whenever the ij-th element of the matrix is filled out, the ji-th position is automatically filled out by its reciprocal value. To actually recover the weights, wi, themselves rather than their ratios that are given in (3.1) we proceed as follows. Note that Aw - nw (3.4) Hence, a comparison matrix as given in (3.1) has (n-l) of its eigenvalues at the origin and the n-th eigenvalue is equal to the dimension of the matrix A, i.e., the number of activities compared (3 in our example). 200 Since --n is the largest eigenvalue, we conclude that the vector of priorities, w, is obtained from (3.4) and is simply given as the eigenvector of the matrix A corresponding to the largest eigenvalue X =n. Since we max are interested in a relative ordering, this eigenvector is normalized so that its components sum up to one. There are 2 questions to be asked at this point: 1. How does one quantify his judgement as to the "strength of contribution" of a certain activity? 2. How does one define consistency in this judgement elicitation process? These questions will be discussed briefly in the remainder of this section. The comparison process elicits qualitative judgemental statements that indicate the strength of the decision makers preference in the particular com- parison made. In order to translate these qualitative statements into numbers to be manipulated to establish the required priorities, a reliable scale has to be established. Much work has been done on the subject of scales in pre- ference statements (see, e.g., [5], and the references therein), we will not repeat here the arguments that lead to the employment of a particular scale; instead, we will present a scale reported in [5] that we find to be useful for our purpose. This scale is shown in table 3.1. When using this scale, one replaces a qualitative comparison statement with the appropriate quantifier. For example, if policy #1 is weakly pre- ferred to policy #2 as fat as achieving objective #1, then a12=3 (and by re- ciprocity a2=1/3).1 Performing the complete pairwise comparison of all 3 policies relative to achieving objective #1 will result in a 3x3 matrix whose (normalized) eigenvector yields the importance of the 3 policies relative to objective #1. In comparing activities, it is expected that if activity Al is preferred to A2, and A2 is preferred to A3 then Al should be preferred to A3. In employ- ing a numerical scale one expects to see consistency maintained throughout the comparison process. Mathematically, consistency is defined as 201 Table 3.1 Comparison Scale Intensity of Importance Definition Explanation 1 Equal importance Two activities contribute equally to the objective 3 Weak importance of Experience and judgement one.over another slightly favor one activity over another 5 Essential or strong Experience and judgement importance strongly favor one activity over another 7 Very strong or demon- An activity is favored very strated importance strongly over another; its dominance demonstrated in practice 9 Absolute importance The evidence favoring one activity over another is of the highest possible order of affirmation 2,4,6,8 Intermediate values When compromise is needed between adjacent scale values Reciprocals of above If activity i has one A reasonable assumption nonzero of the above nonzero numbers assigned to it when compared with act- ivity j, then j' has the reciprocal value when compared with i aij = aik a Vi,j,k 1,2,....,n} {C (3.5) This definition is simple to understand when one recalls (3.2), namely w a ij = wji then, if one has already established the relative strength of activity i.com- pared to the k-th, and the k-th compared to the j-th activity, then this should also yield the comparison of the i-th to the j-th activity; namely aik ak A i Wk wi A ai (3.6) j twj wj When the nxn matrix A in (3.1) is consistent its largest eigenvalue is equal to its dimension, i.e., X =n. . max 202 When the matrix A is not consistent, i.e., equation (3.5) does not hold for some elements, one can show that the largest eigenvalue of A is always greater than n, i.e., X > n (3.7) max And the priority vector is obtained by solving the following eigenvector problem for w Aw i w (3.8) Xmax One can define a consistency index by nmax-n C.I = n-1 (3.9) in the consistent case, C.I = 0. Further details of this subject can be found in [5] and will not be repeated here. 4. VALUE ASSESSMENT The approach described in the previous section for priority assessment can be adapted to the problem of value assessment. This is accomplished by constructing an hierarchy that describes the various factors affecting the task force mission goal. Typically, such an hierarchy will have various levels, whose specific description is part of the value assessment process. These levels may include the following: * Task force mission goal (the apex of the hierarchy) * Scenarios * Major task force objectives * Evaluation yardsticks * Operational options * Components of value function. This particular hierarcy is depicted in Figure 4.1. The specific detail associated with each level may be different from mission to mission which, in turn, may result in a different prioritization of the elements. The bottom level of the hierarchy includes those elements whose relative importance the CTF has to evaluate in certain situations. 203 SCENARIOS MAJOR OBJECTIVES EVALUATION YARDSTICKS OPERATIONAL OPTIONS COMPONENTS OF VALUE FUNCTION Figure 4.1 Hierarchical Value Assessment 204 For example, in considering an air strike against some enemy land tar- gets the CTG (through outcome strike calculators or judgement) may anticipate certain losses in, say, F-14 and A-7 airplanes. The particular plan to be chosen and implemented will be the one that, in addition to achieving the mission will also minimize the expected loss. This last objective requires the availability of a value scale that will allow the relative importance of the F-14 or A-7 relative to the overall task force mission goal. A form of a value function to be considered is a lineart relation given by n V = w x w+ x2 2 +...+wnxnx Wi=l (4.1) i=1 where Wi = relative importance of i-th value component Xi - i-th value component. In the particular example mentioned above, this value function may look like v = -w 1 x1 - w 2 x2 (4.2) where xl - number of expected F-14 losses X2 number of expected A-7 losses w 1, w2 = relative importance of F-14 and A-7 In a particular situation the CTF may consider the F-14 three times more important to.his overall mission than the A-7; this will result in his value function having the form V -0.75x1 -0.25x 1 (4.3) Then, whenever the particular loss assessment is supplied (i.e., values for x1 and x2 ) one has a particular value number associated with-the specific sit- uation being evaluated. Other forms may also be considered, see, e.g., [6]. 205 The value assessment method to be developed here is directed toward obtaining the weights, wi, associated with the components of the value function described in (4.1). These weights are going to be the priorities associated with the elements of the bottom level of the hierarchy described in Figure 4.1. The specific levels described in Figure 4.1 may have different members, in different situations. An aid in specifying these levels may be provided through a "Value Component Template" 'such as the one described in Table 4.1. The list of items considered in each category should not be taken to beall-inclusive. This list may be offered to the CTF and his staff as a suggestion for consider- ation. They may check off those items found relevant to the particular situa- tion at hand and, when necessary, may include other elements worth considering. After checking off those elements relevant to the specific problem at hand, one may arrive at the value hierarchy described in Figure 4.2. The end result of this analysis will be the relative importance associated with the components of the value function; in the case of Figure 4.2, these components include F-14, A-7-, DDG and a CV. The knowledge gleaned from this process can then be used in assessing various courses of action. 5. SUMMARY This paper presented a new approach towards the derivation of a value function to be used in decision problems faced by the CTF and his staff.. This value function is task-dependent and may vary from one decision environment to another. This specifity is what distinguishes this approach from others where the value function is developed external to the decision problem. The actual derivation of the value function is through an hierarchical value assessment that allows the consideration of all factors relevant to the value issue. This process, in addition to structuring the value function, also indicates priorities associated with various factors. These priorities assoc- iated with intermediate level are useful in their own right. They can be used in the planning' stage to identify factors most important to the task force mission goal. 206 Table 4.1 Value Components Template (Preliminary) * POLITICAL CONDITION c, o _ PHYSICAL ENVIRONMENT wILl Co o · 0 OPERATIONS o 0 - SURVIVAL < WI 2 -~ : · TRAINING/READINESS 0 z c -0 LIVES I MORALE I--- - * EQUIPMENT 'PEER EVALUATION M cn I TIME SCHEDULE -J AIR STRIKE * SHOW OF FLAG z co o 0z * NAVAL BLOCKADE S SPECIAL FORCES WI · * AMPHIBIOUS * INTELLIGENCE wo 0 0Zu $ TYPES OF AIRPLANES * SPECIAL EQUIPMENT 0 un I TYPES OF SHIPS I PERSONNEL Z = W L. z U 207 -v~~~~~~~~~~~~,-4 o O o 0w~~~~* Lf) 0 I- I < o A .,4 v . . o Q C okoE C)Jo e ee LAt~~~~~~.--Jr-l v, 0 w 2 Qii C0 C1:l, '~ i:~ I:~ . O.Cl:: r,, .. tO .' O':3) REFERENCES 1. J.R. Payne, et al, "The Naval Task Force Decision Environment", Final Report NWRC-TR-8, Stanford Research Institute, Sept. 1977. 2. P. Slovic, B. Fischoff and S. Lichtenstein, "Behavioral Decision Theory", Ann. Review of Psychology, Vol. 38, 1977, pp. 1-39. 3. A. Leal, "An Interactive Program for Conversational Elicitation of Decision Structures", Ph.D. dissertation, UCLA, 1976. 4. M.W. Merkhofer, et al, "A Computer-Aided Decision Structuring Process", Final Report, SRI International, June 1979. 5. T.L. Saaty, "A Scaling Method for Priorities in Hierarchical Structures", Journal of Mathematical Psychology, Vol. 15, No. 3, June 1977, pp. 234-281. 6. R.L. Keeney and H. Raiffa, Decision with Multiple Objectives, John Wiley, 1976. 209 210 OVER-THE-HORIZON, DETECTION, CLASSIFICATION AND TARGETING (OTH/DC&T) SYSTEMS CONCEPT SELECTION USING FUNCTIONAL FLOW DIAGRAMS BY Glenn E. MitzeZ The Johns Hopkins University The Applied Physics Laboratory Johns Hopkins Road Laurel, MaryZand 20810 This work was supported by the Naval EZectronics Systems Command under Task ZN90 of Contract N00024-78-C-5384 with the Department of the Navy. 211 OTH/DC&T SYSTEM CONCEPT SELECTION USING FUNCTIONAL FLOW DIAGRAMS ABSTRACT - In comparing various conceptual. configurations for the U.S. Navy's future over-the-horizon/detection, classification, and targeting (OTH/DC&T) system, we have taken a new look at some old techniques in graphical analyses. The responsiveness of various candidate concepts was measured by (so-named) functional flow diagrams. Functional flow diagrams are a slight adaptation and simplification of the diagrams used in the Graphical Evaluation and Review Technique (GERT). Functional flow diagrams depict the sequence of functions required to perform an overall task. By assigning a probability of completion and distribution of time for completion to each function in the diagram, the overall probability of completion is obtained. We review Monte Carlo methods for obtaining-the overall results° In the process, we present some new results for confidence intervals on the probability of completion versus time. The techniques have broad applicability to analysis of any system concept where the time-sensitive probability of completing a well-defined task is of interest. The techniques are especially useful for performing system tradeoffs and comparisons at a highly macroscopic level. We apply the analysis techniques to compare "centralized" and "decentralized' OTH/DC&T system concepts. The concepts are compared in four ways by taking combinations of the OTH/DC&T mission to missile launch only or to recognized enemy neutralization and simulations where hardware elements of the OTH/DC&T system were either "perfect" or "realistic." The decentralized concepts were better in all comparisons, except the "perfect" system in mission to launch only where the concepts were indistinguishable. 1. INTRODUCTION Military, government, and industrial planners are often faced with the problem of choosing among several proposed system concepts to solve a particular problem. Time and resources often will not allow a detailed analysis, let alone construction of system prototypes of each concept, so decisions must be made on the basis of techniques applicable at a much higher level. Such is the case with the design of an over-the-horizon/detection, classification, and targeting (OTH/DC&T) system that satisfies the U.S. Navy's need for a worldwide communications and data processing system to support weapon firing from ships against targets beyond the range of on-board sensors. 212 Quantitative analysis of candidate OTH/DC&T system.concepts has relied on a representation of the response of the system to new potential threats in terms of so-called "functional flow diagrams" that depict the targeting functions and the sequence in which they occur. Use of these diagrams is similar to the Program Evaluation and Review Technique (PERT) developed by the Navy's Special Projects Office in the late 1950's and the Graphical Evaluation and Review Technique (GERT), a refinement of PERT developed in the mid-1960's [1]. Functional flow diagrams have been drawn to depict the performance of various candidate OTH/DC&T system concepts in a selected scenario. By making appropriate assignments of the probability of completion and the distribution of time for completion to individual boxes in the functional flow diagrams, the probability of overall mission completion versus time has been computed in each case. This has provided the basis for quantitative comparison of candidate concepts. Section 2 defines functional flow diagrams explicitly. Section 3 discusses Monte Carlo techniques for estimating overall-system performance and presents some original work on confidence intervals for the overall probability of task completion versus time. Section 4 shows the comparison of a "centralized" versus a "distributed" OTH/DC&T system concept using functional flow diagrams. 2. FUNCTIONAL FLOW DIAGRAMS Functional flow diagrams are simple representations of the sequence of functions required to perform some overall task. The diagrams consist of two types of boxes: a. Functional boxes, and b. Branching boxes; and three types of connectors: a. AND, b. OR, and c. EXOR. Each functional box (drawn as a rectangle) is characterized mathematically in two ways: a. The probability of eventual completion, and b. The cumulative distribution function (cdf) or, equivalently, the probability density function (pdf) of completion time (given completion). 213 The input line to each box indicates the function(s) that must be complete before the function can be initiated. An output line from each box indicates the function(s) that can be initiated only after completion of the function denoted by the box. Each branching box (drawn as a diamond) indicates a decision that influences the subsequent functional flow. The questions in the decision boxes are stated in such a way that they an be answered Yes or No. The branching boxes are, therefore, characterized in one way: the probability of Yes branching or of No branching. Each connector box is represented by a circle, and it has two inputs and one output line. The AND connector indicates that all operations from both input lines must be complete before initiating operations on the output line. The OR connector indicates that the completion of either operation from the input lines is sufficient to initiate operations on the output line. The EXOR connector is the same as the OR except that only one of the input lines is active at any given moment due to earlier branching decisions. In addition, boxes must be included in the diagram to indicate the start and finish of the overall task. A sample diagram depicting a simple generalized task of neutralizing a target using the OTH/DC&T system is shown in Fig. 1. The mathematical objective in drawing a functional flow diagramn is to derive the time-dependent probability of completing the overall task which the diagram represents, P(t), from the characteristics of the constituent boxes in the diagram. The time-dependent completion probability of overall task completion by the time t (with the start of the first function in the diagram defined as t = 0) can be written as P(t) = p F(t) , (1) where p is the probability of eventual completion of the overall task and F(t) is the cdf of the overall completion time, given eventual completion. 3. MONTE CARLO TECHNIQUES The overall probability of completion and distribution of time for completion of a task defined by a functional flow diagram can be computed by analytical techniques [1,2]. However, often the diagrams are too complex to conveniently manipulate the formulas or the data too scarce to support identification of particular analytical forms for the completion time pdf's. In the Monte Carlo technique, a large number of sample runs through the diagram are made. As each functional box is encountered in the diagram, random numbers are generated to decide (according to the assumed probability) whether the function is completed and, if so, to add an appropriate delay based on the assigned distribution of time to complete the function. At branching boxes, a single random number is drawn to decide (according to the assumed probability) which branch is to be taken. The results for all the runs are accumulated and used to compute the fraction of successful overall runs through the entire diagram and the histogram of completion times for the successful runs. 214 START (Acquisition of Initial Data) RECOGNITION LOCATI ON CLASSIFICATION CONTACT TRACKING EVALUATION EANOD YES iS NO CU\ I\ENGAGEMENT B NSOR L ANALYSIS ADDITIONAL AND EMPLOYMENT DATA [ CONTROL DAMAGE ASSESSMENT NO YES STOP (Mission Complete) Fig. 1 Generalized OTH/DC&T functional flow diagram. 215 From the results of the Monte Carlo runs, the probability of overall task completion versus time P(t), as defined by Eq. 1, must be estimated. The quantity on the left-hand side of Eq. 1 can be estimated by separately estimating the overall probability of task completion, p, and the cumulative distribution function of completion time (given completion), F(t), appearing on the right-hand side of Eq. 1. The estimate of P(t) is then the product of the two estimates, P(t) = p F(t) , (2) where p and F(t) are estimators for p and F(t), respectively, and P(t) is the derived estimator for P(t). If N Monte Carlo runs are made through the diagram, success or failure in the completion of each run can be represented by a binominally distributed random variable = (with probability p), if the ith run is completed 0 (with probability 1 - p), if the ith run is not completed (i = 1,.....,N).-(3) An estimator for overall probability of completion is p= N ,(4) a form that will be useful in deriving associated confidence intervals. If, on any given set of N runs, exactly M successes occur, then there are M samples of completion time that can be represented by T. = completion time on jth completed run (j = l,...,M) (5) An estimator for the cumulative distribution function is F(t) = M(t)/M , (6) where M(t) is the number of times T. does not exceed t. Some assessment of the accuracy of these estimators is required as a function of sample size. The accuracy can be assessed in terms of confidence intervals that encompass the actual quantities with a known probability [3,4]. 216 Confidence Interval on p Confidence intervals for p are typically based on either the precise binomial distribution of p (assuming independent runs) [5, pp. 273-285] or on a Gaussian approximation of the distribution of p. The binomial approach has the disadvantages that it is difficult to compute and gives little insight into what sample sizes are required to achieve a desired accuracy in the estimate of p. The random variable X ~(~p- ~p~) /e VP~~~~(7) (l~p^~) converges (with increasing N in distribution) to a Gaussian random variable with mean 0 and variance 1 [6, pp. 152-156]. This permits us to say that the (random) interval p rN_ -P ,+/y (8) where C is V times the inverse error function (i.e., erf(Cy/i) = Y) y Y contains the true parameter p with probability Y. Because the true parameter p must lie in the interval [0,1], the probability is also y that the (random) interval [max (0, P _ m(1-))(1 + - CY) (9) contains p. The normality approximation is said [6, p. 141] to be good for values of N and p satisfying Np(l-p) > 20. Confidence Interval on F(t) An exact confidence interval for F(t) can be computed by using the distribution of the Kolmogorov statistic DM = supfF(t) - F(t) I . (10) t Kolmogorov [7] showed that the cumulative distribution function of D does not depend on the distribution F(t), which is unknown and assumed to be continuous. The exact distribution of DM can be computed by assuming that F(t) represents a random variable uniformly distributed between 0 and 1 [8]. Kolmogorov showed that for large M the distribution of DM tends toward 217 -i ) 2 2 Prob{DM < x} = ( exp(--2Mi x ). (11) i=-O0 (Birnbaum [8) indicates that the agreement is good with M = 80.) Tabulations of Eq. 11 can be found in [5, p. 440]. Sample values of hv x = x required to achieve a selected probability Y are as follows: Y BY 0.80 1.07 0.90 1.22 0.99 1.63 (12) Using these results, a 100y percent confidence interval for F(t) can be computed, namely [M) - X+/ F ( ). X // (13) By Eqs. 10 and 11 the interval in Eq. 13 contains F(t), for all values of t, with probability Y. Since 0 -< F(t) < 1, for all t the interval (max(O, F(t) - A /iM) , min(l, F(t) + X/ /i)] (14) has the exact same probability of containing F(t) for all values of t as does the interval in Eq. 13. Confidence Interval on P(t) An exact confidence interval for P(t) is difficult to obtain, since that would involve deriving the distribution of P(t) in Eq. 2. The distribution of a product of random variables is in itself difficult, but the distribution of F(t) is not even available. However, it is possible to derive an interval which contains P(t) with at least a specified probability, from the confidence intervals for p and F(t) [9]. The approach is to observe that if the event where p falls in the confidence interval of Eq. 9 is independent of the event where F(t) falls in the confidence interval of Eq. 14 for all vales of t (in the sample space consisting of the Cartesian product of the two underlying sample spaces), 218 the probability of P(t) falling in the interval formed by multiplying the lower and upper end points, respectively, of Eqs. 9 and 14 is at least the product of the confidences associated with the individual intervals. This is true because the event where P(t) falls in max (O. p - £ ) max (0, F(t) - X/) min 1l, E) min (1, F(t) - (15) contains the intersection of the two events described above (where a and B are the probabilities that p and F(t) are contained in their respective confidence intervals). Therefore, the probability that P(t) falls in Eq. 15 is at least ac. It is clear that Eq. 15 could be used to generate many different intervals having the same minimum probability (i.e., ac) of containing P(t) for all vales of t, by choosing various combinations of a and ~ for which the product is fixed. It is interesting to ask whether one of these choices results in a significantly more narrow interval than others. Optimal choices for a and B which minimize the maximum width of the confidence interval are discussed in [9], and summarized below. 0.88600, 0.90297 for 80% confidence a, ~=-0.94425, 0.95314 for 90% confidence (0.99470, 0.99531 for 99% confidence (16) The maximum width of the confidence interval obtained by making these choices will not exceed the bounds I4.0404//ifor 80% confidence 4.6530/ViY for 90% confidence 6.2662//M for 99% confidence, (17) where M is the total number of completed runs. 219 As an example, Monte Carlo runs have been made through the sample diagram shown in Fig. i. All functional boxes were assumed to have a probability of completion of 0.95 and an exponential distribution of completion time with mean 1.00, and all branching boxes were assumed to have a probability of YES branching of 0.50. When enough Monte Carlo runs are made to obtain 10,000 completions, the probability of completion is estimated to be p = 10,000/25,268 - 0.39576 . (18) The associated 90% confidence interval as computed by Eq. 9 is [0.39068, 0.40084] , (19) which encompasses the analytically derived value of 0.3952. The cdf as estimated by Eq. 6 has an untruncated 90% confidence interval defined by P(t) + 1.22//10,000 = F(t) + 0.01222. A 90% confidence interval for P(t) using Eq. 15 and choosing a and B according to Eq. 16 is given by [0.38987 max (O,F(t) - 0.0137) 0.40165 min (l,F(t) + 0.0137)] . (20) This confidence interval is plotted in Fig. 2 with a superimposed plot of the analytical expression derived using the techniques described in references [1] and [2]. The histogram of mission completion time is shown in Fig. 3 with a superimposed plot of the analytically derived pdf. The pseudo-confidence interval on P(t), given by (15), is used in [9] to address the important question of sample sizes required for selected accuracies in the estimation of P(t). To obtain estimates of P(t) via Eq. 2 that are within p of the true value for all t, the required number of completed runs is approximately 4.081.2/p 2 for 80% minimum confidence 5.4126/p 2 for 90% minimum confidence 9.8163/p2 for 99% minimum confidence . (21) 220 0.5 0.4 - so < i. 0.3 0 4,_ 00.2 0 0. 1 Confidence interval ...._Analytical expression 0 10 20 30 40 50 60 Time (arbitrary units) Fig. 2 Confidence interval on probability of completion versus time from Monte Cario runs (with superimposed plot of analytical expression). 221 0.1 -I- I I I 1000 0.08 Note: -800 f. `. bin width - 1.00 o 1 g total sample size = 10,000 > -0_ - 6400 0 10 20 30 40 50 60 Time (arbitrary units) Fig. 3 Histogram of completion time (with superimposed plot of analytical pdf) for generalized OTH/DC&T functional flow diagram. 222 5. COMPARISON OF OTH CONCEPTS The above techniques have been applied to the evaluation of system concepts of OTH weapon targeting. The major problem to be solved by an OTH targeting system is to acquire targeting data from several sensors that are remote from the firing platform, to correlate targeting data from the several sensors, and deliver that data to the firing platform on a timely basis. The two concepts of accomplishing this are characterized by the terms "fully distributed" and "centralized." In the fully distributed concept, contact data from each sensor are distributed directly from the sensor to all system users, including firing platforms. Upon receipt, the data are correlated, tracks are developed, targets are identified from any background ships present, and a projected target position is provided to the missile fire control system. In the centralized concept, contact data from sensors are delivered to a centralized point in the targeting system. There, the data are correlated, tracks are developed, targets and background are identified, and the correlated tracks are then passed to the firing platform so as to develop a fire control solution. For each of the concepts, a functional flow diagram with assumred performance characteristics for each function was developed [10]. The results are shown in Fig. 4. The diagrams were drawn to simulate a simple scenario exercising several levels of command for both sensor and weapon control. The diagrams can be found in [10] and contained about 200 boxes and branches, as opposed to the 13 in Fig. 1, but generally followed the sequence shown in the figure. Two sets of performance characteristics were developed. The first corresponded to realistic performance. The second set simulated perfect performance of those elements of the overall mission which were performed by OTH/DC&T system hardware (e.g., data processing). Specifically, in the second set of performance characteristics subfunctions not performed by weapons, sensors, platforms, commanders and external communications were assigned probability 1 of completion and zero time for completion. This was a means of exposing conceptual differences induced by entities more or less outside the control of the OTH/DC&T system designer. Two types of missions were considered. The first included only the launch of the first missile, corresponding to the "Weapons Employment" box in Fig. 1, and stopped at that point. The second included, beyond this, damage assessment, and retargeting, if necessary, as many times as it took to achieve a hit and correctly assess it as such. With the two performance characteristics sets and two types of missions there were four bases for comparing the systems concepts. Monte Carlo results for all four are shown in Fig. 4. 223 100 i/ / ' ,// I '; , , .:...... 90 E.... 5o60s 1// / ' \50, 0 40' mO40!~ C//j/L~ ~ ~ ~ ~ ' Note: 90% confidence interval P ~/ / . width. :have less than 0.04653 20 -- Fully distributed ------\- Centralized /",/'J:iiii!::?:i . } _ Mission to launch only, perfect system , //; / * i:/X(two curves in distinguishable) 10 '/////7//\\,,/'":':'"::.."-- \:\.....,.. Mission to launch only, realistic system . /::¥:::::::::.Complete mission, perfect system /\\\\\\\\ Complete mission, realistic system 0 X 0 250 500 750 1000 1250 Time (arbitrary units) Fig. 4 Comparison of time-dependent mission completion probability for fully distributed versus centralized OTH/DC&T system concepts. 224 In three of the four combinations (the perfect system to launch only is the exception) the two concepts are clearly distinguishable. The 90% confidence level intervals are not drawn but have width less than 0.0465 and the difference in the curves for the two concepts are typically much larger. Furthermore, the fully distributed concept is superior in all three cases. We conclude from this that the "fully distributed" concept should be selected over the centralized concept and this conclusion is unaltered by the quality of performance of OTH/DC&T system elements which are under the designers' control or by considering damage assessment and retargeting functions beyond the initial firing of an OTH weapon. In the actual study, 26 candidate system concepts were identified and compared [11]. The "fully distributed" and "centralized" concepts discussed in this report are the two extremes in that set. When the quantitative analyses were combined with qualitative analyses and operational considerations which we have not discussed in this report, a modified version of the "fully distributed" concept was selected. 6. CONCLUSIONS Functional flow diagrams provide a useful comparative system analysis technique in those instances where timeliness and reliability are important system considerations. The technique can provide some valuable insights into system behavior. An interesting extension of this work would be to cost-effectiveness analyses. Quite a bit of research in reliability has been devoted to finding optimal distributions of available funds among unreliable subsystems [12]. If the characteristics of the boxes in a functional flow diagram are related to cost, the potential exists for optimizing the completion probability curve (in some sense) over various distributions of the total funds to the individual boxes. Another extension would be in comparative analysis of enemy capabilities. 225 REFERENCES 1. Gary E. Whitehouse, Systems Analysis and Design Using Network Techniques. Englewood Cliffs, N. J.: Prentice-Hall, Inc., 1973. 2. G. E. Mitzel, "Documentation of Techniques for Evaluating Measures of Value for OTH/DC&T Concepts," The Johns Hopkins University Applied Physics Laboratory memorandum F4A-78-279, 18 August 1978. 3. Richard M. Van Slyke, "Monte Carlo Methods and the PERT Problem," Operations Research, Vol. III, September 1963, pp. 839-860. 4. P. J. Witzke, "Techniques for Statistical Analysis of Data Produced by Monte Carlo Runs," The Johns Hopkins University Applied Physics Laboratory memorandum F4A-79-128, 12 June 1979. 5. D. B. Owen, Handbook of Statistical Tables. Reading, Mass.: Addison- Wesley, 1962. 6. George G. Roussas, A First Course in Mathematical Statistics. Reading, Mass.: Addison-Wesley, 1973. 7. A. Kolmogorov, "Sulla determinazione empirica di una legge di una legge di distribuzione," Giornale delle' Instituto Italiano delgi attuari, Vol. 4, 1933, pp. 83-91. 8. Z. W. Birnbaum, "Numerical Tabulation of the Distribution of Kolmogorov's Statistic for Finite Sample Size," Annals of Mathematical Statistics, Vol. 47, pp. 425-441. 9. P. J. Witzke, "Analysis of Confidence Intervals for Probability of Mission Completion, P(t) = p G(t)," The Johns Hopkins University Applied Physics Laboratory memorandum F4A-79-275, 19 July 1979. 10. G. E. Mitzel, "Qualitative Analysis of OTH/DC&T System Concepts (U)," (Confidential) The Johns Hopkins University Applied Physics Laboratory memorandum F4A-79-283, 30 July 1979. 11. The Johns Hopkins University Applied Physics Laboratory, "OTH/DC&T Engineering Analysis - System Concept Development (U)", (Confidential) report FS-79-057, December 1979. 12. Frank A. Tillman, Ching-Lai Bwang, Way Kue, "Optimization Techniques for System Reliability with Redundancy - A Review," IEEE Transactions on Reliability, Vol. R-26, No. 3, August, 1977, pp. 148-155. 226 A SYSTEMS APPROACH TO COMMAND, CONTROL AND COMMUNICATIONS SYSTEM DESIGN BY Jay K. Beam George D. HaZushynsky The Johns Hopkins University Applied Physics Laboratory Johns Hopkins Road Laurel, Maryland 20810 This work was supported by the NavaZ EZectronic Systems Command under Task C2AO of Contract N00024-81-C-5301 with the Department of the Navy. 227 A SYSTEMS APPROACH TO COMMAND, CONTROL AND COMMUNICATIONS SYSTEM DESIGN ABSTRACT This paper presents the results of recent efforts by The Johns Hopkins University Applied Physics Laboratory (JHU/APL) to define a future Command, Control and Communications (C3) system concept that can be used as a basis for developing a long-range C3 system plan. C3 system structures that could serve as a basis for future system design are identified. Research for the technical approach described included: a) reviewing available Office of the Chief of Naval Operations (OPNAV) requirements, and b) conducting a series of wargames set in the 1985-2000 time frame to further define future system require- ments and to establish a C3 concept. Based on these wargames, a C2 functional process has been developed that can be performed at each Navy command level. This functional process is defined and expanded to include representative levels of the Navy command structure, showing the relationship between command levels and the activities that require functional interaction. Functions that define the C2 process are grouped into functional areas. The relationship of these functional areas is defined in terms of information flow and command and coordi- nation connectivity. Top-level functions and some lower-level functions associated with each area are identified, discussed, and defined to more fully convey the generic, functional relation- ship of the C2 groups. After the C2 process is defined at a specific command level, characteristics of a C3 system are identified. Alternative C2 structures are then defined that would satisfy system character- istics, using the functional model as a building block. 223 I. INTRODUCTION A development of Navy Command and Control Systems has been underway for many years. Most efforts have been directed toward either a specific command level capability [such as the Tactical Flag Command Center (TFCC) for an at-sea Battle Group Commander] or ful- filling the need for a commander whose principal role addresses a func- tional aspect of naval warfare, such as the Anti-Submarine Warfare Centers Command and Control System (ASWCCCS). One outgrowth of these efforts has been the prolifer- ation of systems or capabilities directed toward fulfilling the needs of specific commanders, but ignoring the overall needs of a Navy C2 system. Therefore, the C0 Project Office of the Naval Electronic Systems Command (PME-108) requested JHU/APL to under- take a multiyear program to define a circa-2000 C2 system concept for tactical warfare. The ultimate objective was to provide the Navy with sufficient information to establish a plan that: a) could build upon existent Navy C2 capabilities in an evolutionary manner, and b) allow them to achieve a fully capable system that would satisfy future naval needs. Figure 1 shows the general approach taken by JHU/APL to complete the task. A baseline C 3 system was defined that iden- tified a planned Navy C3 capability, programmed to be available by 1980. This baseline system was examined in a series of wargames conducted at JHU/APL, which included consideration of the projected threat to the baseline C 3 system. Out of this wargame experience comes a C 3 system concept and requirements from which one is able to identify the functions that a C3 system must perform. Once a concept has been developed, the functions that a C 3 system must perform can be determined and, by coupling these functions with system requirements, it is possible to define a set of systems that perform the functions and satisfy system requirements. From this set, a particular system configuration can be selected and described. The C3 engineering development is still in progress, and a future C3 system has been described in a Type A System Specification format, shown in Figure 1. My objective, here, is to: a) concentrate on the development of a C3 process or concept, b) translate that process into a functional representation of the C 3 system, and c) present some of the considerations involved in defining a C3 system. 229 PROJECTED C3 THREAT 3 3 BASELINE ---- C WARGAMES C CONCEPT C3 SYSTEM & ANALYSIS C3 SYSTEM . C3 FUNCTIONAL REQUIREMENTS DESCRIPTION' C3 SYSTEM 1 DEFINITION C3 SYSTEM DESCRIPTION 'TRANSITION TECHNOLOGY PLAN PROJECTIONS Figure 1 C3 System Engineering Development Project General Approach II. THE C3 PROCESS Early wargame efforts at JHU/APL revealed that is was difficult, if not impossible, to examine various aspects of C2 in an analytical manner. Consequently, there was a need to define C2 as a process or model to be able to treat the various aspects of C2 in a systematic manner. The process, shown in Figure 2, resulted from this need, and was a combined effort of several Laboratory members. 230 ENVIRONMENT V E NVIRN COMMAND FUNCTIONS . | COMMAND SUPPORT FUNCTIONS COMN UT -SENSE PROCESS CE E DELEGATE I i T CONTROL DIRECT DATA INFORMATION COMMANDS Figure 2 A Model of the C2 Process At any command level, friendly, neutral, and hostile events that occur in an environment are perceived by sensors such as satellites, radio receivers, radars, sonars, and eyesight. These events are conveyed horizontally to manual- and computer- processing subsystems where they are internally labeled and, if possible, correlated with other events. These functions could, in theory, be performed nearly automatically by the application of computer and micro-processor technology. The man-machine in- terface clearly occurs at the evaluate function. These four func- tions (sense, process, classify, and evaluate) categorize the com- mand support functions. The model indicates that sensor data are converted to information as they flow laterally through the C2 process. The model illustrates the overlap between the command support and the command functions in recognition of the fact that the commander's staff, as well as designated evaluators, evaluate information sets and recommend courses of action. Command support functions involve the collection, correlation, evaluation, interpretation and organization of data and information to produce a reduced information set for command decisions. Command functions, in contrast, comprise the decision- making and force management that direct the actions of subordinates. Planning or doctrine acts as a filter to reduce the decision-making burden on the commander. Anticipated events can be planned for, and appropriate responses can be promulgated by Oper- ation Order (OPORDERs), contingency plans, and rules of engagements. Events that cannot be covered by prebattle planning require the commander's attention. He must select a course of action and, after deciding what response is appropriate, he has three options for implementing his decision: a) he may choose to delegate authority in response to a subordinate commander's request, provided the 231 task can be clearly defined. (Given that the subordinate commander has operational control of necessary resources, he is perceived by his senior commander to be qualified for the task, and the senior commander has the means to monitor the actions of the sub- ordinate); b) the senior commander may decide to direct a sub- ordinate commander to carry out a specified course of action; or c) the senior commander may decide to exercise direct control of an act performed by a subordinate commander, as in crisis manage- ment. However the selected course of action is implemented, it impacts the environment, generating events and responses to the events, which are then sensed, processed, etc. Clearly, C2 is shown to be a closed-loop process. When we expand the C2 model vertically to encompass representative echelons of command, as shown in Figure 3, commu- nications are required and the model is expanded to encompass the C3 process. The overlapping environments for the three command levels are shown on the left, indicating the differing focus of each command level. The solid lines indicate the domains of knowledge, while the dashed-lines indicate that the domain of interest of the higher command levels encompasses those of the lower command levels. The mismatch between the solid and dashed- lines is intended to reflect present experience where, for a number of reasons (such as radio silence to avoid alerting the enemy), a subordinate commander may know more about certain events than his senior. The model shows a future need to exchange data at the processor level in addition to the traditional links for informa- tion exchange among evaluators. The evaluator not only correlates and interprets information processed horizontally, but also may correlate information received from other levels provided the communications link is feasible and the value of communicating outweighs possible penalties. Also, the model shows the connectivity with higher command levels [such as National Command Authority (NCA)] as the establishment of doctrine promulgated in OPORDERs, etc. These instructions become a part of the planning function, and those events processed horizontally which can, by doctrine, be delegated to a lower command level are sent to the evaluate function to be correlated and ranked with information derived horizontally at that command echelon. Out of the act and monitor box, actions that can be delegated modify the doctrinal filter function at a subordinate command level. Actions that a senior commander directs a subor- dinate commander to take either limit or expand the courses of action available to the subordinate commander. Actions that a senior commander opts to control directly affect the actions per- formed at the selected subordinate command level. 232 The process shown in Figure 3 was examined in a series of wargames conducted at JHU/APL to expose it to an operational environment and to test the logic of the C2 operations under var- ious warfare roles the U.S. Navy would be expected to encounter. As a result of this examination, the functions that a C2 system would be expected to perform were identified and grouped into six functional areas: Command, Communication Management, Sensor Man- agement, Engagement Management, Information Management, and C2 System Management. Additionally, these functional area groupings provide a basis for development of functional relationships within and between command levels and provide a means for the representa- tion of a generic C2 system architecture. This starting point for development of a system is defined by the functions (and their structure) present at each Navy command level examined: Fleet Commander-in-Chief (FLTCINC), Numbered Fleet, Battle Force/Battle Group, Unit, and Platform. These functional areas and the connectivities between areas define the structure present at each command level of the C3 system. This structure is illustrated in Figure 4, which shows the six functional areas and the functional connectivities between these areas at each command level. DOCTRINE ENVIRONMENT 7DTCI.NC _ CDR SENSE PROCESS CLASSIFY EVALUATE PLAN DECIDE ACAND rtI X WH--i-='-- ( _ ; I .` ! - .... UNIT OCDR . INFORMATION -.- COMMANDS Figure 3 The C3 Process 233 ENGAGEMENT MANAGEMENT I M c N A SENSOR O A MANAGEMENT R G M ME . .. _ ----- M AM T E COMMUNICATIONS A I ._-N MANAGEMENT N O T N N C2 SYSTEM MANAGEMENT FUNCTIONAL CONNECTIVITIES COMMAND AND COORDINATION - INFORMATION Figure 4 Basic C3 Structure There are two functional connectivities illustrated in Figure 4: Information Connectivity and Command and Coordina- tion Connectivity. Information Connectivity is a two-way infor- mation flow connecting each functional area with Information Management. This connectivity provides for the transfer of data and information to support the functional areas, allows an infor- mation base to be maintained and its contents disseminated. The command portion of the Command and Coordination Connectivity allows the commander to exercise his authority within the command level and direct the functional areas. Also, it allows the func- tional areas to respond to this direction. The coordination por- tion allows the Engagement, Sensor, Communications, and C2 System Management functional areas to coordinate their activities within the constraints established by the commander so that direct command intervention will not be required. 234 Figure 4 represents a generic building block of the C3 system design alternatives. It is a representation of the func- tions, structure, and connectivities present at each command level. With these determined, candidate design alternatives for the C3 system may be described in terms of the connectivities between functional areas at different command levels and the interfaces with external commands and information sources. III. SYSTEM DESIGN ALTERNATIVES Integration of our generic building block into the Navy command structure is shown in Figure 5. It now becomes clear that the design alternatives for a C3 system can be defined by the man- ner in which the: various functional areas at each command level are interconnected, information sources and information manage- ment is interfaced, and external interfaces (JOINT/Allied Command and Combat Systems) are connected to the C3 systems. A tabulation of these various features and the options associated with each feature is shown in Table 1. Each design feature has one or more possible options that may be examined in constructing design alter- natives. These options were identified by considering extremes of the features and a reasonable set between these extremes. The selection of specific options was influenced by JHU/APL wargame experience, analytical judgement, and the type of naval operations the system must support. These options are subject to a number of constraints that should reduce the possible options. These con- straints, and their rationale, are identified in the following paragraphs. a. The connectivity between command functional areas and with the NCA and Joint Commands must provide for an adaptive hybrid system as defined by the C3 Concept Description. b. Command functional area connectivities to other command levels are restricted to command functional areas only. This is necessary to avoid ambiguous control of forces and assets. c. The Allied Command interface occurs no lower than the Battle Force/Battle Group (BF/BG) level. Naval operational protocol requires liaison to occur with the Officer-in-Tactical Command (OTC); however, liaison may subsequently be delegated. d. Information sources shall always interface with the Information Management areas at their command level. This represents normal naval operations where elements under the oper- ational control of a particular commander provide information to that command level. 235 INFORMATION 3 EXTERNAL COMMAND LEVEL SOURCES C STRUCTURE INTERFACES V ENGAGEMENT MANAGEMENT I M I I i i 1 NCA/JOINT N SENSOR COMMAND FLEET CINC NATIONAL &NAVYM G M TE M A A T 6 TMANAGEMENT | ALLIED I M COMMAND OT 2 - MANAGEMENTCSYSTEM V V ENGAGEMENT MANAGEMENT I M NUMBERED 0 A MANAGEMENT 0 FLEET FLEE &ALLED MER G M AM m A TET E - COMMUNICATIONS N tNN I MANAGEMENT I OT 2 CSYSTEM MANAGEMENT I I P N SENSOR C BATTLE FORCE/ I IA MANAGEMENT 0 BATTLE GROUP BF/BG ME M AM A E COMMUNICATIONS N IN MANAGEMENT MANAGEMENT ENGAGEMENT IM NA FN SENSOR C O A MANAGEMENT 0 UNIT Ra M T E - COMMUNICATIONS N I MANAGEMENT CaSYSTEM MANAGEMENT ENGAGEMENT - MANAGEMENT PN SENSOR C O A MANAGEMENT 0 PLATFORM PLATFORM G M M SYSTEMS A M A ' I N MNAGEMENT OT MANAGEMENT 3 Figure 5 C Functions Related to Command Levels 236 Table 1 Design Features and Options Features Options Command Connectivity Adaptive Hybrid NCA/Joint/Allied Command NCA/Joint: Adaptive Hybrid Interface Allied: To BF/BG and Higher Levels Information Source to Information Centralized: Numbered Fleet Management Area Interface Centralized: BF/BG Same Level Dissemination Limited Downward Dissemination Parallel Downward Dissemination Full Dissemination Information Management Area Centralized: Numbered Fleet Connectivity Centralized: BF/BG Hierarchical Parallel Combined Parallel-Hierarchical Indirect Asset Management Functional Hierarchical Area Connectivity Parallel Mixed Indirect Combat System Interface Platform Level BF/BG and Lower Levels Single Level Other Than Platform e. The connectivities for the functional areas of Sensor, Communications, Engagement, and C2 System Management to other command levels are only to functional areas of the same type (e.g., Sensor to Sensor or Engagement to Engagement) to main- tain the integrity of the functional areas as demonstrated by war- game simulation and to prevent disruption of internal command-level protocols. 237 The design alternative shown in Figure 6 is appro- priate for C2 of forces that are essentially self-contained; e.g.., combat systems require only information that is available from information sources (sensors) that are actually resident on the platform, and the exchange of information is only required between adjacent levels of command. On the other hand, Figure 7 is representative of the case where there is a need for informa- tion derived at any command level to be available to the combat system on a particular platform and, indeed, it is even possible that the control of a combat system may be vested in a command that is not resident on the platform. These system capability "extremes represent only two of the some 80 systems designs considered in the JHU/APL work for the Navy. In summary, a systematic approach has proven useful in identifying the various options available for defining a C2 system for the Navy. JHU/APL has selected and recommended a system design that will support the application of Naval power in future years. The design allows development of the required capability in an evolutionary manner either through the consider- ation of the needs of individual command levels (such as a plat- form or a fleet) within the defined C3 system structure or through development of elements of the system on a functional basis (such as information management or combat system control). Either approach leads ultimately to the desired C3 capability and pro- vides a means by which the impact of future combat and sensor systems can incorporate C3 requirements. The authors wish to particularly acknowledge Ms. Carol Fox and Mr. Gerald Preziotti of JHU/APL whose efforts over the past several years have made this paper possible. 238 INFORMATION 3 EXTERNAL COMMAND LEVEL SOURCES C STRUCTURE INTERFACES ENGAGEMENT MANACGEMEN -I : I -f .NCA;JOINT r NoNA . -- C COMMAND 0 A 0AAEM~ FLEETCINC 7NATIONAL&NAVY G M E TF.-r....o.ATONL AM i,1 ALLIED N COMMAND C'SYSTEM _ j .6.|.U.ANAGEMENT ~~~~F ~~~~~I ?-- , - - ENGAGEMENT"I MANAGEMENT IM FN C NUMBERED M FLEET LEE TW&ALLIEDMG I E COMMUNICATIONS N I NT !IMANAGEMENT / _ 0T 4E _ ENT SEN'SOR C.T BATTLE FORCEI I_.AGEENT / _ M- } _ 4 BATTLE GROUP BFIBG tE M TE + _MWNGt*N A I. UNI T R G = =M -;;GUENT Il l *.,,.~.o,, Y L ET 1,A '"'~~~~~~~~~~-I 'fMM° _|[""' I^TON- "1MD" |'" -i;'L J*Y MANAGEMENTL I I"AT'A~~~~~~I SENSOR ~1~r 0 AN~~~~~~~~~AM - oFN '7MANAGEMENTICATIONS 2 SYSTEMC p MANAGEMENT PLATFORM PLATFORMRC AMM E A SYSTEMS F TE NOMNCIIN MANAGEMENT,C2 "ST.- ~FROM SENSOR MANAGEMENT_~~~~ AT SAME COMMAND . LEVEL. ~ ~~~~~~~~~~. .GMN I Figure 6 Design Alternative 1 239 EXTERNAL INFORMATION 3 COMMAND LEVEL SOURCES C STRUCTURE INTERFACES r 1 ENGAGEMENT MANAGEMENT NCAJOINT ' FoN^ OR COMMAND FLEET CINC NATIONAL &NAVY -I R M COMNCAIN A ~~~~~~~NUAMBEE NE M TTE OHlNCI1N N ALLIED ' N COMMAND O T _ _ C2 SYSTEM 4 MANAGEMENT M~~~~~ __F _I EGGMENTR |I I NUMBERED o A - ANAG_ ENT FLEET FLEET&ALLIED - RE M BATTLE~~~~~~~~~~~~~~~~~FOR N "0--o 1,.~,~E,.E BATTLE GROUP BF/BG t - t_ i IC AI~S *~~~~~-11 ME - T_._ U--- ,~~~~._.L- I I T~~~~~~=-,,,EMINTa o. 240 WHEN TASKED , ,. ,, A , I. _ ; ~~---,,_ I IASr~~~~ m N.CATIClfONS - ". . T" m~~~~~~~~~~~~~~~~~~~~~~~~~~' M~~~~~ c ATMF N J'SNSOR A TEM COUm.IU"..AION$ L _" R.°FN| G~ ~- I,,,,,M,,A,;,"SoN T MO UNIT BATTLEFOCE ~iT l_ I |-- MANCMT|' C8-T PLBATFORE~ ~ GU ~ PAFOM " E m T E CO4. IOWU N OT * ~~~~~~~~~~~~~~FROMAT SAME COMMANDSENSOR LEVEL MANAGEMENT 0 A MENT 0T M MS NA FROM ATSAMESNSOR OMMANANAGEENT LEVE PLATFORM Figre 7 Design lternative 240M Figure 7 Design Alternative 2 BIBLIOGRAPHY 1. The Johns Hopkins University Applied Physics Laboratory Confidential Report 5S-78-088, dated March 1978, "Command, Control, and Communica- tion (C ) Requirements and System Concept CIRCA 2000" (U). 2. The Johns Hopkins University Applied Physics Laboratory Secret Report FS-78-179, dated July 1978, "C3 Concept Analysis: Phase I Gaining Results" (U). 3. The Johns Hopkins University Applied Physics Laboratory Unclassified Report FS-78-276, dated November 1978, "Future C3 Concepts." 4. The Johns Hopkins University Applied Physics Laboratory Unclassified Report FS-79-022, dated January 1979, "YEAR 2000 C3 Concept Briefing" (U). 5. The Johns Hopkins University Applied Physics Laboratory Confidential Report FS-79-016, dated December 1979, "C3 Concept Analysis: Phase II Gaining Results" (U). 6. The Johns Hopkins University Applied Physics Laboratory Confidential Report FS-80-075, dated April 1980, "C 3 System Engineering Develop- ment, Phase III War Game Report" (U). 7. The Johns Hopkins University Applied Physics Laboratory Confidential Report FS-80-078, dated August 1980, "C3 System Engineering Develop- ment - Functional Description" (U). 8. The Johns Hopkins University Applied Physics Laboratory Secret Report FS-80-255, dated October 1980, "C3 System Engineering Development - Future System Definition" (U). 241 242 MEASURES OF EFFECTIVENESS AND PERFORMANCE FOR YEAR 2000 TACTICAL C 3 SYSTEMS BY Djimitri Wiggert The Johns Hopkins University Applied Physics Laboratory Johns Hopkins Road Laurel, MaryZand 20810 This work was supported by the Naval Electronic Systems Command under Task C2AO of Contract N00024-81-C-5301 with the Department of the Navy. 243 ABSTRACT After pointing out the wide variety of terminology now in use, this paper offers definitions for three classes of system measures: Measures of Effectiveness (MOEs), Measures of Performance (MOPs), and Measures of Merit (MOMs). Issues which influence the types of MOEs, MOPs, and MOMs chosen for an application are discussed, and a rational method is presented for choosing specific measures for any given application. Finally, the use of the method is illustrated by describing its application to the problem of choosing a system design for a Navy tactical C3 system for the year 2000 and then describing this system at a Type-A Specification level, 244 MEASURES OF EFFECTIVENESS AND PERFORMANCE FOR YEAR 2000 TACTICAL C3 SYSTEMS 1. Introduction The quantitative assessment of a C3 system at any stage of its development is still very much an art, rather than a science. This situation is the result of several factors. First, there is no uniform terminology currently in use. Concepts such as measure of effectiveness, measure of performance, measure of military worth, measure of merit, and others have different meanings and different interrelationships in the hands of different authors. Second, there is frequently a lack of a usable quantitative definition of a measure, making evaluation difficult. This problem is subsumed under another, namely, there does not seem to be any widely used, rational procedure for selecting measures which are suitable to the particular assessment task, are internally consistent as a set, and can be evaluated with reasonable ease. This paper addresses each of these issues. A plea is made for adoption of uniform terminology as a necessary prerequisite for the emergence of C3 system assessment as an engineering discipline and for meaningful and easy exchange of information among workers in this discipline. A set of attributes is presented which can be applied in selecting a set of measures for a given situation. Finally, application of these attributes is described for two stages in the development of a tactical C3 system for the U.S. Navy in the year 2000 time frame. 2, Terminology A great variation in terminology is apparent from the literature. The most widely used term seems to be "measures of effectiveness". This term, unfortunately, means different things to different people. It is often used as a "blanket" term to include a spectrum of levels ranging from various aspects of mission effectiveness (e.g., kill ratio) to system and subsystem performance (bit error rate, target acquisition probability, availability) to aspects of procurement and logistics (technical risk, transportability, interoperability). Such a range of levels occurs, for example, in References 1-3. In Reference 4, Wohl, Gootkind, and D'Angelo use the term "measure of merit" in a similar, all-encompassing manner, These authors do, however, take pains to distinguish between system ,effectiveness from the commander's point of view and system performance from an engineering point of view. This same distinction is made by Welch [Reference 6], Van Trees [Reference 7], and Alberts [Reference 8], among others. 245 In this paper, the distinctions made in References 4, 6, 7, and 8 are applied. The terminology is probably closest in spirit to that of Welch [Reference 6]. The classes of measures to be used here will be measures of effectiveness (MOEs), measures of performance (MOPs), and. measures of merit (MOMs). MOEs will be restricted to those measures which relate to mission effectiveness, i.e., the commander's viewpoint. Examples are: probability of mission success, ratio of Red losses to Blue losses, probability of survival of a specified level of platform capability, and system flexibility. MOPs will refer to quantities which are generally of greatest interest to the engineer. Examples include the aforementioned bit error rate and target acquisition probability, along with reliability, maintainability, availability, mean time between failures (MTBF), mean time to repair (MTTR), communication system or processor throughput rate, and accuracy and timeliness of sensor data. The third category of measures, MOMs will be used here to encompass those system attributes which are neither MOEs nor MOPs but which are nonetheless of equal interest from the overall standpoint of system acquisition and use. MOMs could include all aspects of cost (development, production, spares, etc.), technological risk, interoperability, compatibility, power consumption, and projected obsolescence. Note that this usage of the term MOM is a departure from the usage in Reference 4, The terminology adopted here has proven useful in the evaluations to be described in Section 4. In many applications of MOEs/MOPs/MOMs, it is necessary to make a choice between qualitative and quantitative measures, and between relative and absolute measures. The first choice is a function of the amount of quantitative information available about the system in question, while the second choice will depend largely on the ability to evaluate the measures on an absolute scale and possibly on the existence of absolute standards of effectiveness or performance. It is clear that there are gray areas between MOEs and MOMs, i,e,, there are measures which could be viewed as belonging to either class. This fact, and the terminology adopted in this paper, serve to underline the need for a uniform terminology. 3, A Method of Selecting a Set of Measures Another fact which emerges from consideration of the examples of MOEs and MOPs given in Section 2 is the existence of hierarchies, both within and between these two types of measures. For example, mission effectiveness could be considered a top-level MOE, supported by MOEs flexibility, survivability, and commonality of tactical picture. These MOEs, in turn, depend on MOPs such as throughput rate, bit error rate, AJ margin, and physical hardness. Thus, it should be possible to evaluate measures at any level in a bottom-up manner. 246 ------~-1-~_____ It is perfectly acceptable that measures at one level support more than one measure at a higher level or are supported by more than one measure at a lower level. This situation is illustrated in Figure 1. What is undesirable is that MOEs at any given level be closely coupled or, worse yet, that an MOE (or MOP) at one level partially supports another MOE (or MOP) at the same level. A basic criterion for acceptability of a measure (MOE, MOP, or MOM) in a given evaluation situation is that the measure be relevant to the evaluation being performed, For example, in the system design alternative selection process described in Section 4, the use of bit error rate would have been totally inappropriate, as would cost, Mutual independence and relevance are just two of seven attributes which were found to be extremely useful in selecting an appropriate set of measures. The complete set, along with definitions of the attributes, is shown in Table 1. An important advantage of these attributes is that they can be applied in sequence, so that the set as a whole acts as a series of "filters" on an original set of candidate MOEs/MOPs/MOMs. Attributes 1 through 5 are considered essential for any set of measures, while attributes 6 and 7 are desirable but not vital, and, in fact, might not necessarily apply to the process of selecting measures in some situations. The definitions will become more meaningful once the applications in Section 4 have been discussed. 4. Applications of MOE/MOP/MOM Selection Process The first application involved the selection of a single Navy tactical C3 system design alternative from among twelve possible alternatives, The alternatives and the process leading to their formulation are described in detail in Reference 9 and summarized in Reference 10. The problem was to determine the optimum set of connectivities for the flow of command, coordination, and information among an agreed- upon set of basic tactical C3 functional areas at each of five command echelons, and between these functional areas and several external functions and systems (NCA, Allied commands, information sources, and combat systems). The conceptual relationship among these entities is shown in Figure 2, This situation differed from most MOE/MOP applications in that implementation could not even be guessed at. For example, it was beyond the scope of the problem to consider information exchange or processing rates, or even propagation media. Thus, any measures chosen had to be independent of any particular system implementation and set of physical measurement techniques, in addition to possessing the seven attributes listed in Table 1. It is clear that the measures should be qualitative rather than quantitative, and relative rather than absolute. The filtering process described in Section 3 was applied to a list of nearly forty MOEs/MOPs/MOMs which had been compiled from a variety of sources, including Reference 1. There were still nearly twenty survivors at this point, so further analysis 247 LEVEL 1 MOE (1,1) MOE (1,2) MOE (1,3) LEVEL 2 MOE (2,1) MOE (2,2) FIGURE 1 HIERARCHY OF MOEs 248 TABLE 1 ATTRIBUTES OF AN IDEAL SET OF MEASURES Number Name Definition Importance as a measure General value as a criterion in selecting or evaluating system concept, architecture, or implementation; i.e., what one would like to be able to use as a measure if at all possible. 2 Applicability to present Relevance to the selection or situation evaluation actually being made. 3 Independence of other Lack of dependence on or coupling measures with other measures to be applied at same time at the given level. 4 Ease of quantification Degree to which the measure can be defined and specified in quantitative terms. 5 Ease of evaluation Ease with which values of the measure can actually be determined for this application (e.g., by consensus, judgment, simulation, field measurement). 6 Independence of scenario Freedom from the impact of the choice of a scenario on the outcome of the application of the measure. 7 Independence of technology Freedom from the impact which technology might have on the outcome of the application of the measure. 249 ul ~ z z r -z Z o< w! ' 0 < 10 < , l ,, . , Lu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~'7,::' .-~~~~~~- U r..c I-.,m)c/ w C: OZ fl+ " Zf+ . J 4 ;§fi + Z . r X s . r |t| fi ), t O ; 32 .. I&IZC ~~~~~~~~~~~~~~~~~~~~~~~~~Eii LiL CLO _z£ l~ Z t L t Ll~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Lot ii E~~~~~r<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~4 z I5, LLJ I i~~~~~~~~~~~~~~~~~~~~,- =5·~7_rz ~~~~~~~ ,,F--4 i l O ~~ ~ ~ ~~ ~ ~ ~ ~ ~ ~ I z rI r~~~~~z~n::3 250~~~~~~~~ 'iu tocr' ~ _) EI L Y) L IIE " Ir I 5 IYE)o I t o l i , io III ' I t t ' I F C 25 LL~~~~~~~~~~~~~~~~~~~L < cc w LLJ~~~~~~~~~~~~~~~~~~~~wr ui LL~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~C,L j LLI Lu F- F- <~~~~~~~~cu =2 < _ LLLL 2 no m CL~~~~~~~~~~~~~~~L:UIL LL~~~~~~~~~ 3 - _~*u~~ Cdi ~ iIIr~ ~~ ,~ ,,u~ur~ _ ~ ~ ~ ~ ~ u'-O~i-i 250~~~~~~~~~~~aIi r i tIr r · rIa: 3 L UJ tL was necessary. The final result was a rather broadly defined set of four MOEs (or system selection criteria, in the context of the problem). These measures, their working definitions, and relative weights are given in Table 2, At this point, standard procedures were employed to evaluate the various connectivity options: a weight was assigned to each of the MOEs and a qualitative, three-level (-, 0, +) rating scheme was applied to rate each option relative to each of the others. As an example of the way in which the options were evaluated with the use of the MOEs, consider the MOE, Performance, applied to the connectivity of the Information Management functional areas of Figure 2. Parallel connectivity of Information Management areas allows all Information Management areas to share the same integrated tactical picture without loss of timeliness or accuracy. For this reason, the parallel option was scored with a plus. The hierarchical connectivity may result in the greatest loss of timeliness and accuracy because as many as three intervening nodes may operate on the information, The two centralized connectivities, in which the numbered fleet (NF) ashore or battle force/ battle group (BF/BG) afloat collects, processes, and then distributes processed information to all echelons, are only slightly more effective than hierarchical connectivity, but were scored as possessing medial capability. The results just stated were entered in the appropriate boxes (shown with heavy border) in Table 3. Overall results are summarized numerically in Table 3 and pictorially in Figure 3, which show that the best options for the four design features were determined to be the following: * Parallel downward distribution of the information source to Information Management area interface. e Parallel connectivity between the Information Management areas. * Hierarchical connectivity between the asset management functional areas, e Combat system interface at the Platform, Unit, and Battle Group command levels, In the second application of the MOE/MOP/MOM selection process, ,the system design alternative selected with the use of the MOEs described in the preceding paragraphs has been carried into the system description stage (Reference 11) by means of a modified Type A specification, which describes in a high-level manner the system effectiveness models and system performance measures (i.e., MOEs/MOPs/MOMs) which should be provided and applied by an implementing contractor and by the Navy. There will be two time-phased stages, each with its own MOE/MOP/MOM requirements: 251 TABLE 2 TACTICAL C3 SYSTEM DESIGN SELECTION CRITERIA Criterion Definition Weight Performance The capability of an option associated with a 3 particular feature to provide timely, accurate, and adequate information to, or effective coordination with, appropriate elements of the system. Survivability The capability of an option to perform its 3 indicated functions (with minimal degradation) when the loss of one or more nodes or links occurs. Flexibility The capability of an option to operate in the 2 mode of other options associated with that feature, if so required. Support The capability of an option associated with a 1 feature to operate with minimal demands on communications and/or processing support. 252 + + + + LAJ~~~~~~~~~~~~. 0c o a a . + I* a F~~~~~~~~~~~~i-~~ --.4 0. ooC - '4 . . .+40'40 0. 4 i o + CD +I CDZ C ~~ ) c~~~~~~~~~~~~~~~~~~~~a, k~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ LLI)2: VU (..0 CY') CY) LL or * I h r \c', 0-4 -4 -4 C) .0~~~~~~~~~~~~~~~~~ cj LiJ fL ~ 7 '. 0)L 0o 0 1 + I I - I-I r IT·I m o. C>CC!, cv, o t L/*) ~ -40 . ~.a.. .C4 7 00 0 4+ a a C C)~ ~ ~ C)> ~ 0M e : 4-4 U) £1)-4 , 4 CI:~~~~~~~~~~~~~~~~+ o 1.4a Co 0 0 C') C') 03 0 Z uc' o w col 4 co 9 cT cr)( a.'-4 a 1 + C+4 0, C 4)a oa ~ ooa+ +a a+ -4 u 0. C'i z C- - -- 4J Z c3(3 cO a..o 0100 o~C)$~ - r0 e e 0 004) N1 NJ Ci4.J *0i2 4) ~ 0'4 0 0 .C..- .--. 000 0 -a. . . C . .444) ~1.5C 44r~ 4)44C 04 -44 44 L, 0 aa .OZ C a Itc 4 0 I;o rl '-' O L a. C)U -~ Cfl 0 0 ~~~~~~~~~~~~L eeL L 0.o O L. 00~ ~ ~ 00 a30 1~ 4)0 .04) 00a..· 0 .0 oss ar ;k K 253 IN FOP,.ATION COMMAND LEVEL SOURCES 3 C STRUCTURE 3 EXTERNAL C STRUCT~URE~ ~INTERFACES ~r------~r-, MCANAGEMENT ... ol C FLEET CINC NATIONAL &NAVY ;e~ I IDV~ERETf l F i _ Ci'UIA-iT D FEET AED I',~~~~~~~~~~~~~~~~~~~~~~~T , .C-IiC oAANAGE " ..T TNT1 S A LE MANAGEMENT ~~~254~~. FLEI E T 0 IFNO CO ~'~ "'~'-J'N l C AT I NT R LE X {i~~~~~,TN ;G E EINS TA _ .- CE...T IA -3 C 5 EGFIGURE N;NTE T- I f-- 0A N C 2 T --q A t PLATFORCE SELECTEDP AL-|ORM i 254-iGC~fTDESIGNALTFORMNPATIVEO : Y*SIC(U(*I~~~~2S CO-_AT (1) System design, during which models of various implemen- tations of the system will be subjected to tradeoff studies and evaluation. (2) System implementation [including technical evaluation (TECHEVAL), operational evaluation (OPEVAL), and fielded systems], during which exercises and evaluations of designated portions of the actual C system will be conducted. At this stage, only proposed measures exist, with the stated option for the contractor to add or delete measures and/or redefine one or more measures. Table 4 lists measures which can be applied at the system design stage, with tentative quantitative definitions. Note that the MOPs covertness, spoof resistance, and AJ capability are stated as supporting the higher-level MOPs flexibility, survivability, and timeliness. Note also that the latter might be argued to be MOEs rather than MOPs. Finally, observe that the last two items in Table 4 illustrate the concept of MOM as defined in this paper. Table 5 lists five MOPs which could be applied by a system evaluator (e.g,, engineer, commander) during prototype system tests, system evaluations, or field exercises. Because of the desire to maximize flexibility of approach at this stage, the MOPs in Table 5 violate in some instances the attribute requirements stated in Table 1. 5, Summary and Conclusions This paper has pointed out the diversity of terminology presently in use for evaluating C3 systems at various stages in their evolution. It is hoped that the MOE community will move toward the adoption of a uniform set of definitions for the various classes and levels of system measures which must be used. For the C3 system design evaluation discussed in this paper, three types of measures were defined: measures of effectiveness (MOEs), performance (MOPs), and merit (MOMs). MOEs were defined to address operational or mission level effectiveness; MOPs refer to engineering and logistics-related performance parameters; and MOMs are all other measures (e.g., cost, risk, interoperability, etc.). Measures were further categorized as to being quantitative or qualitative, and relative or absolute, The possible hierarchical nature of a set of MOEs and MOPs was discussed, particularly the use of lower-level measures to evaluate higher-level ones. A key result is the development of a set of seven attributes which can be applied sequentially to a candidate set of MOEs/MOPs to produce a useful and usable set. Two applications of this MOE selection process were presented. These applications involved two successive stages in the development of a Year 2000 Navy tactical C3 system. These applications clearly illustrate the impact on choice and evaluation of MOEs of the degree of detail of the available implementation data. In the first stage, a system design 255 TABLE 4 SYSTEM DESIGN CAPABILITY MEASURES Capability Measure I Definition Mission Effectiveness MOE Degree to which mission objectives are accomplished in the required time frame, measured in terms of friendly-to- enemy loss ratio, time to respond to threat, etc. Flexibility MOP Ease of reconfiguring to another con- nectivity, capability level, and/or command structure when commanded to do so. (Includes number of usable al- ternate structures and speed of reconfiguring.) Survivability MOP Probability that system will perform at a specified level when subjected to a specified threat (including partial destruction). Timeliness MOP Time delay within the C3 System in transferring and processing data, commands, and coordination information. Covertness MOP Fraction of communication that cannot be intercepted outside a specified envelope (supports survivability MOP). Spoof Resistance MOP Fraction of spoofing data rejected (supports survivability MOP). Anti-Jamming (AJ) MOP Fraction of links disrupted as func- Capability tion of jammer-to-signal ratio (J/S) and jamming strategy (supports flexi- bility, survivability, and timeliness MOPs). Ease of Implementation MOM Portion of the C System already in place or which can be implemented with off-the-shelf or easily developed hardware or software. Growth MOM Fraction of the C3 System that can be augmented or improved by simple changes or additions to its structure at that time. 256 TABLE 5 SYSTEM PERFORMANCE MEASURES Measure Definition Corrnnality of Tactical Picture Correlation between targeting data tracks and between background shipping tracks held in common by two data bases (afloat and/or ashore). Quality of Information Base Accuracy and timeliness of information base, including (but not limited to) coverage radius, maximum time late, radius of uncertainty, reporting interval, number of reports per track, and own and enemy status and plans. Connectivity Fraction of node pairs which can communi- cate at or above some set of performance levels [e.g., bit error rate (BER), throughput]. Availability Fraction of the time a system, subsystem, or component performs when called upon at or above some performance level. Reliability Fraction of the-time a system, subsystem, or component satisfactorily performs throughout a mission when it successfully began the mission. Flexibility Ease of reconfiguring to another connec- tivity, capability level, and/or command structure when commanded to do so. (In- cludes number of usable alternate struc- tures and speed of reconfiguring.) Covertness Fraction of communication which cannot be intercepted outside a specified envelope. *Spoof Resistance Fraction of spoofing data rejected. AJ Capability Fraction of links disrupted as function of J/S and jamming strategy. 257 alternative had to be selected. The total lack of implementation information forced the choice of broad, qualitative MOEs which were evaluated On a relative basis. The second stage involved the preliminary recommendation of MOEs, MOPs, and MOMs to be used by designers, implementers, and commanders to evaluate simulation results, prototypes, and fielded systems. 258 REFERENCES 1. "Architecture for Tactical Switched Communication Systems - Annex E (II), Methodology for Design and Analysis", TRI-TAC Office, Fort Monmouth, NJ, Draft dated 12 May 1981. 2. "Command, Control and Communications (C3) Measures of Effecitveness (MOE) Handbook", Interim Draft, Naval Electronic Systems Command, PME-108, Washington, D.C., 30 June 1980. 3. "Measures of Effectiveness and Analysis Tools for the Combat System Architecture Program in the Area of Command Control and Communications", Progress Report dated June 24, 1979, prepared by Systems Exploration, Inc., San Diego, CA, for Naval Ocean Systems Center, San Diego, CA, under Contract No. N00123-76-C-0787. 4. J. G. Wohl, D. Gootkind, and H. D'Angelo, "Measures of Merit for Command and Control", MTR-8217, The MITRE Corporation, Bedford, MA, 15 June 1981. 5. "Proceedings for Quantitative Assessment of Utility of Command and Control Systems", MTR-80W00025, The MITRE Corporation, McLean, VA, January 1980. 6. J. A, Welch, Jr., MG, USAF, "State-of-the-Art of C2 Assessment", in MTR-80W00025 (Reference 5). 7. H. L. Van Trees, "Keynote Address - Conference Workshop on Quantitative Assessment of the Utility of Command and Control Systems", in MTR-80W00025 (Reference 5). 8. D. S. Alberts, "C2 I Assessment", in MTR-80W00025 (Reference 5). 9. "Command, Control, and Communications (C3) System Engineering Development --- Future System Definition", Report FS-80-255 (SECRET), The Johns Hopkins University Applied Physics Laboratory, Laurel, MD, October, 1980. 10, J. K. Beam and G. D. Halushynsky, "A Systems Approach to C3 System Design", Fourth MIT/ONR Workshop on C3 Systems, San Diego, CA, 26 June 1981. 11. "Command, Control, and Communications (C3) System Engineering Development -- YR 2000 System Description (Type A Specification)", Report FS-81-070 (SECRET), The Johns Hopkins University Applied Physics Laboratory, Laurel, MD, April, 1981. 259 260 AN END USER FACILITY (EUF) FOR COMMAND, CONTROL, AND COMMUNICATIONS (C ) BY Jan D. WaZd Sam R. HoZZingsworth HoneyweZll Systems and Research Center 2600 Ridgway Parkway Minneapolis, Minnesota 55413 261 AN END USER FACILITY (EUF) FOR COMMAND, CONTROL, AND COMMUNICATIONS (C3) Jan D. Wald and Sam R. Hollingsworth Honeywell Systems and Research Center Minneapolis, Minnesota This paper was prepared for presentation at the fourth annual MIT/ONR workshop on command, control, and communications (San Diego, 15-26 June 1981). The purpose of the paper is to outline the following: C3 problems facing tactical commanders * Shortcomings of current C3 systems o Functional characteristics of an End User Facility for C3 operations * Steps required in the development of a C3 EUF The content of the paper is based in part on experience gained in a variety of DoD contracts and Honeywell Internal Research and Development (IR&D) projects. Preparation of the paper was supported by IR&D funds. The paper reports on an ongoing project at the Systems and Research Center aimed at developing a C3 system that supports the needs of commanders and command staffs. We are now in the requirements definition phase of the effort. The thrust of this work is to utilize tools developed from two branches of Artificial Intelligence: Cognitive science and knowledge engineering. Cog- nitive science draws on principles and techniques from computer science, psychology, linguistics, philosophy, and education. Its emphasis is on explaining intelligent activities through investigation of human cognitive processes-- such as memory, attention, perception, and reasoning--so that they can be put to use in computer applications. Knowledge engineering focuses upon achieving expert level performance first by modeling the necessary commander functions according to principles of cognitive science, and then determining where sub- ject matter expertise is appropriate and supplying it. Using principles of knowledge engineering, a user supportive EUF can be developed. We believe tools from these areas of Artificial Intelligence are necessary for building the kind of EUF which meets the requirements of the C3 environment. NATURE OF THE PROBLEM Tactical commanders and their staffs must be prepared to function effectively under adverse, high-stress conditions. Several factors have a major impact on the environment of command staffs: 262 e High event rates - High force densities - High movement rates * Increasing complexity of combat systems - Proliferation of sensor, weapon, communication, and data processing systems - Expanded capabilities of combat systems * Reduced permissible reaction times * Interoperability problems e Disruption and deception by an increasingly capable adversary * Personnel problems - Increasing skill requirements - Decreasing availability of skilled personnel o Doctrinal turbulence All indications are that these factors will induce progressively more stress in the future. In view of these trends, a move toward automating C3 functions is mandatory and has been undertaken with mixed success in some areas. The Army's Tactical Fire Direction System (TACFIRE) and Tactical Operations System (formerly TOS, now SIGMA),and the Air Force's 485L program to automate Tactical Air Control Center (TACC) are notable examples. Although such systems were intended to expedite C3 operations, they tended in some respects to have the opposite effect. The difficulties may be categorized into two major areas: (1) Hardware/Software problems and (2) User-System interface problems. Examples of significant hardware/software problems are: * Information processing capacity limitations - Quantity and rate limitations - Timelines and accuracy limitations * Information fusion/correlation problems 263 e Data base management problems - Access by multiple users - Retention of current situation and historical trends - Deletion of obsolete information e Information flow problems (related to interoperability problems) e Rigid processing algorithms (related to doctrinal turbulence problems) Recent technological advances are reducing the severity of the hardware/software problems, but a variety of user-system interface problems continue to plague automated C3 systems: e Display complexity * Dialog complexity a Procedural rigidity a Lack of user confidence in the quality of system performance * Inappropriate allocation of functions to user and system - Presentation of data vs. information - Excessive user memory requirements - -Inadequate planning, decision support, and communication functions 9 Need for a trained intermediary (operator) between end user and system Many of the user-system interface problems have arisen because of a historical need to hoard memory and processing resources when designing computer systems. System designers have typically reduced the computer's burden by requiring system operators to memorize complex codes, abbreviations, and procedures, and by reducing operator prompts and error messages to a terse minimum. Sophisticated dialog systems, displays, and input devices have typically been considered "cosmetic" features that can be dispensed within the competition for budgetary and hardware/software resources. Experience has shown, however, that system effectiveness can be seriously compromised when user functions are inadequately supported. The need for user-friendly computer systems is becoming increasingly well recognized, both for commercial and for military applications. Moreover, technological breakthroughs are simultaneously increasing the capabilities and 264 reducing the cost of hardware/software modules needed for explotating advanced techniques for user-system interaction. In light of these developments, we have begun the process of defining the required functional capabilities of an automated system to support C3 operations. APPROACH TO SOLUTION OF THE PROBLEM Our approach has been to assume that a generic EUF for C3 operations can be defined and implemented, and that it can significantly improve the force effectiveness of combat systems. Our long-range objective is to design and test an EUF for C3 and, ultimately, to tailor the concept to specific C3 domains. Before discussing the steps comprising this plan, the following paragraphs describe the general concept of an EUF and the general design goals we are working toward. Characteristics of an End User Facility An EUF is an automated workstation designed specifically to support end users. The support offered by the facility comes from two sources: (1) Its ability to automate the information management functions necessary to satisfy the information requirements of users, and (2) its ability to provide an interface that is natural to use for a wide range of potential users who may differ from one another in terms of their level of computer sophistication, their personalities, or their styles of interacting with a computer system. An EUF uses a user-friendly front end to interact with users. A natural language interface can potentially be included to facilitate a large class of user-system transactions. To meet a user's information requirements, an EUF relies on well defined data bases and supplementary facilities such as knowledge bases and knowledge based reasoning. Such facilities include the capability necessary to access, assess, and interpret information from the domain. They may interpret situational data, for example, or they may support decision and planning aids for the user. The ability to handle a variety of users and their individual styles for inter- acting with a computer system also is built into an EUF. EUFs are designed to interpret the requests of users and to provide an interface that is both con- sistent and compatible with their expectations. EUFs also permit user programmability so that ad hoc information needs can be met. Scope and Objectives The EUF we have in mind should be capable of supporting the C3 needs of an Army division-level commander and staff or equivalent in the Air Force or Navy. That command level was chosen because it represents a reasonable balance between the long-range planning functions of higher echelons and the more immediate 265 battle management functions of lower echelons. Our prior experience predisposes us to think in terms of C3 problems for land combat operations, but we fully intend to address air and sea operations as well. Our design goals are as follows: a The EUF can be operated directly by the commander and his staff. Specially trained operators will not be required to serve as intermediaries between the users and the system. e The EUF will augment a variety of command functions. It will make integrated information available to the users, and it will take coordinated actions in response to command directives. a The EUF will impose no training requirements or workload on the users. e The users will be able to devote 100% of their attention to tactical problems, and 0% to the operation of the EUF. X The EUF will be designed to promote user acceptance. The command level we have chosen and the design goals listed above make our problem challenging, perhaps intractable, but we believe that significant progress toward the objectives is currently feasible. The potential payoff of even partial success appears to be enormous. Payoffs of an EUF We have not performed a cost-benefit analysis of an EUF in any C3 domain, but a well designed EUF would seem to be capable of improving the cost-effectiveness of combat operations in at least the following ways: e Improving the ability of the commander and staff to see the battle and mobilize resources * Reducing Che degree of equipment-specific training required for per- forming C operations * Reducing the size requirements for command staffs e Reducing the skill level requirements for command staffs These and related payoffs need to be verified, but significant performance improvements and/or cost reduction in each area appears to be attainable. 266 STEPS TO THE SOLUTION The remainder of the paper outlines the steps we intend to follow in developing an EUF for C3 , provides examples of C3 functions that should be supported by the EUF, and illustrates what we believe to be the important features and capabilities of such a facility. Steps toward Developing an EUF for C3 Our development plan fog the EUF is broken into two major parts. The first is to develop a generalized C EUF concept and an EUF simulator to test the concept. The second component is to apply the EUF concept to specific C3 domains. The first phase is a research and development program designed to develop and test the basic EUF concept. The steps that are being taken toward developing the C3 EUF concept are: e Analyze C3 functions: Requirements Definition * Distribute C3 functions between user and EUF: Initial design of the EUF Simulator * Develop user-EUF interface: Detailed Design of the EUF Simulator a Test and evaluate the EUF concept * Modify and retest the concept The product of this program will be a design for a prototype C3 EUF. Analyze C3 Functions: Requirements Definition--The purpose of the C3 functional analysis is to develop a conceptual model of the environment in which the system is to be placed. The Todel will characterize the information requirements associated with each C" function. To be effective, these requirements will be specified in a manner that is independent of the: present way of doing business. The independence comes from detailing what information is necessary without describing in the process the present procedures for obtaining or using the information. The product of the functional analysis is a requirements definition which describes the functions that must be performed, the data items, and time factors associated with each C function. Distribute C3 Functions--The purpose of distributing C3 functions between the user and the EUF is to begin to develop a top-level design of the EUF. This step is necessary to ensure that the EUF simulator is a good research and development tool. 267 Distribution takes place only after a model of command functions is developed. This modeling begins with the description of the information needs of commanders as defined during the functional analysis. The knowledge and skills required for commanders are identified. Based on this model a support plan is devised and a division of labor is proposed. Some of the activities commanders or their staffs perform now are assigned to the EUF, others are not. In all cases, the proposed division of labor should ensure that the eventual users of the EUF will be free to devote 100% of their time and attention to command functions. Based on the actual distribution of functions, support facilities and other sub- systems will be identified. Those that require subject matter expertise or other kinds of intelligence will be determined at this time. An initial design of each will be developed. Design and Develop EUF Simulator--Based on the distribution of functions and the initial EUF design, the EUF simulator will be designed and developed. The user-EUF interface will be developed in detail. A driver scenario will be simulated with sufficient fidelity to provide realistic test conditions. The design of the interface must hide the system-related functions from the user. The intelligent systems to provide this capability will be developed. They must be able to handle ad hoc queries and alternaitve methods for accessing informa- tion. This will guarantee that the EUF will be able to handle individual differences among users. Test EUF Concept--The purpose of this step is to test the distribution of functions and the interface design. A test plan will be developed, followed by the formulation of a scenario depicting a generic C3 situation. We will use realistic models of weapon and sensor systems, troop movements, tactics, and doctrine. Finally, empirical performance data will be collected and analyzed. - In light of the findings of the studies, the EUF concept will be modified as necessary. The process will be repeated until design changes do not influence performance. The second phase of this project is to develop an operational EUF, and to test it in the field. Examples of C3 Functions Table 1 lists a set of major C3 functions and the subfunctions comprising each one. Each subfunction can be further subdivided into a hierarchicial set of lower level subfunctions. Although the functions are listed separately in the table, it is clear that they must be performed in an iterative, tightly inter- woven fashion. Most of the functions and subfunctions listed in the table are currently performed manually by large command staffs. In the Army division-level context, for example, the G2 staff is responsible for employing the intelligence 268 TABLE 1. EXAMPLES OF C3 FUNCTIONS Major Functions Subfunctions 1. Know own situation - . Establish standing requests for information * Receive situation reports * Request missing reports * Initiate special requests for information * Process unsolicited reports * Determine own strengthsi weaknesses, and capabilities 2. Know enemy situation * Establish standing requests for information * Receive situation reports * Request missing reports * Initiate special requests for information * Process unsoliciated reports a Determine enemy strengths, weaknesses, and capabilities 3. Plan operations * Identify discrepancies between actual and desired states of the world * Develop plan * Test the plan o Modify the plan if necessary and test again 4. Conduct operations e Generate orders * Distribute orders * Monitor own and enemy situations * Modify plan if necessary, and test modi fi cati ons * Generate and distribute modified orders * Continue monitoring operations and update plans as necessary 269 assets required for seeing the enemy (i,e., knowing the enemy situation). The G3 staff is tasked with knowing the strengths, capabilities, and current status of own forces, planning operations, and conducting operations. Similar functions are performed by Air Force and Navy command staffs. The following paragraphs summarize the major functions listed in Table 1. Know Own Situation--In order to develop a picture of the current status of own forces, the command staff must receive and process situation reports from sub- ordinate units. Most reports will be received on a routine basis according to standing operating procedures (SOPs) established by the commander. The number of reports requested by SOPs should be sufficient to produce a data base that is reasonably detailed and up to date. The number of reports requested should be held to a reasonable level to, prevent overloading the staff (at either the sending or receiving end) or communication channels. Emission control con- siderations may reduce the permissible message traffic to well below the desired level. In addition to processing preplanned reports the command staff must perform' several related functions. The reports should be surveyed to insure that all expected reports have arrived, and any missing reports should be sought, Special information not covered by the SOPs may also be required on occasion, In this case the sources of the information must be identified and the requests for the information must be formulated and distributed. The command staff should also be responsive to unsolicited situation reports, particularly emergency reports. The situation reports must be consolidated into a summary form that characterizes the current status of friendly units and highlights their strengths, weaknesses, and capabilities. A graphic representation of unit locations is probably the most effective way of presenting status information in a form that is useful for supporting command decisions. Other status information such as supply level and personnel level for each unit are perhaps more appropriately displayed in tabular format. The grease pencil is the most common device for conveying these types of information to the commander although computer driven displays have been developed for some applications. Know Enemy Situation--At the subfunction level in Table 1 the steps involved in characterizing the enemy situation are identical to those discussed above, At a more detailed level, however, the process is substantially different because it involves obtaining information about a noncooperative adversary. The first major problem in attempting to learn the enemy situation is to decide which intelligence assets to employ. This decision involves detailed knowledge of the availability and capabilities of the sensor systems and other sources of intelligence. In addition, emission control considerations and the very real probability that a sensor system will be destroyed when it is used attach a potentially high price to the deployment of many of the most valuable active sensor systems. Passive systems are less vulnerable to this threat, but they 270 also tend to produce data that are more difficult to interpret and evaluate. The commander must weigh these factors against the expected value of the information. Once information requirements have been defined and intelligence resources have been selected, SOPs and special requests for information can be generated and distributed. The information obtained from different sources varies dramatically in terms of reliability, timeliness, position location accuracy, and type of data available concerning each enemy unit or movement. These differences combine to make the task of filtering, correlating, and interpreting multisource data difficult and time consuming. Some progress has been made in automating the multisource correlation problem *(e.g., with TACFIRE and as discussed at other sessions in this conference), but the process remains largely manual in most command centers. Plan Operations--The commander's goal in planning an operation is to achieve the objectives established by higher command, and to expend minimum resources during the operation. Planning is a complex activity that involves deciding which forces to mobilize, how to mass them against enemy weaknesses, how to follow through, and how to provide logistics support to the fighting units. In addition-, contingency plans need to be developed. In order to develop a plan the commander must exercise a model of combat events. The model is often cast in the form of an if-then monologue: "If I do this, then my adversary will do that and the consequences will be..." The commander then tests a number of options until one is discovered that yields a satisfactory expected outcome. That option becomes the plan. Most such exploratory models are cognitive models. They exist within the commander and have been developed on the basis of training and experience. Cognitive models are often extremely powerful, but they are also subject to severe memory and processing constraints and potentially inappropriate biases. Some work toward computerizing such gaming models has been accomplished. One notable example is the Tactical Operations Movement Model under development by the Army Research Institute, but we are aware of no currently fielded C3 systems that allow commanders to extrapolate into the future from hypothetical decision points. Conduct Operations--After a plan has been devised and tested, it must be put into action. Specific orders must be generated and distributed to the combat and support untis. The purpose of monitoring own and enemy situations must continue throughout an operation. Contingency plans may need to be activated if conditions warrant, or new plans may need to be developed and tested. Any change in plans must be accompanied by the generation and distribution of new orders. 271 The generation of orders is typically performed manually at present. Once generated, the orders are distributed on paper, digitally or by voice over wire or radio, or in face-to-face meetings. There have been some attempts to automate these processes, but such automation is currently not common. Examples of EUF Requirements Requirements for an EUF for C3 consist of descriptions of the capabilities that a stand-alone hardware/software system must have. These requirements, because of our design goals, will be associated both with the functionality necessary for information as well as user support. There is some redundancy in the description of the requirements that follow. This is for purpose of exposition only. The examples chosen for elaboration are: * Situation assessment * Decision making and planning * Data base management * User interface They represent in a preliminary way the functionality we envision for the EUF. Only the completed requirements definition, however, can determine the final and definitive set of requirements. Situation Assessments To know own and enemy situations, the EUF must be able to synthesize and corre- late information reports, intelligence reports, etc. For this to be done effectively, a knowledge base and reasoning capability that can exptract relevant informaion, produce reliable summaries, and make appropriate in- fluences about the state-of-the-world must be available. If the user wants information that for some reason as yet cannot be obtained, the user should be able to program the EUF to obtain it. The EUF must also be able to explain the reasoning behind its assessments. This requires rules of reasoning and an explanation capability. Because graphic representations may be more meaningful to commanders than textual, a text-to-graphics paraphrasing capability may also be necessary. Providing these summaries and translating from the internal representation of text to graphics requires a sophisticated translation ability. A natural language understanding capability may be necessary in order to provide this functionality. 272 The symbology for the EUF graphic system may look more like an arcade game than like the graphics of present C3 systems. The design goal is that the user be placed in non-threatening and familiar circumstances. Using animation, real- world imagery, or other arcade-like facilities may supply this friendly and supportive _environment. Decision Making and Planning To plan and conduct operations adequately, the EUF must support the decision making and planning functions of the commander and staff. This support should be able to supply, given a proposed plan, forward looking, realistic projections of the state-of-the-world. This support should be reality based to the fullest extent possible. The support facilities must be knowledge based. They must be able to know the current state of the operational environment, own and enemy doctrine, and the capabilities of sensor, weapons, communications, and transportation systems. The facilities must be able to use this information intelligently to plan and support the commander and staff. The recommendations made by the EUF should be based on subject matter expertise. They should be able to support the user in all phases of decision making and planning: problem formulation, alternative generation, alternative evaluation, and alternative selection. The decision and planning facilities should be able to explain their choice of selection. The explanation should provide the rationale the system used in making the selection and, if asked by the user, the system should explain why other choices were not selected. More detailed explanations should be available if less detailed ones fail to convince the user. The user should also be able to modify the criteria used by the EUF, thus allowing the commander to fine tune the system to meet specific operational and environmental requirements. Data Base Management An EUF may have an increadibly large quantity of data/information at its disposal. A means to organize this data base so that it is useful and timely is essential. To handle the information requirements of commanders, the EUF must include an intelligent information retrieval system. The system should include a high level query language to access the needed information quickly while minimizing user workload. It must also be able to organize and reorganize its memory so that it learns about its world and becomes, over time, a better resource for the user. The system also must be able to use intelligent heuristics for searching its memory. Ad hoc information requests can be satisfied this way. Also the utility of the data base lasts longer and is more flexible. Access paths not specified during initial data base design can be constructed and the information obtained. Without intelligent heuristics this would not be possible. 273 User Interface The user interface should be easy to use, provide a consistent view of the EUF's functionality, and be compatible with the user's expectations. There should be a convenient and efficient form of dialog. The dialog should be natural language oriented. A full-blown natural language understanding system may not be required. A menu-select or fill-in-the-blank entry format may be sufficient. However, the interface system should incorporate features that make the formulation of complex queries and user programmability easy and natural. The interface should be multi-modal. Design features that may be appropriate are: o Automatic voice recognition and synthesis 9 An alphanumeric keyboard and display * Special function keys * Graphics capability Human factors design guidelines should be followed to minimize workload and maximize operational effectiveness. The display modes used must be powerful enough to produce the natural, supportive environment the EUF requires. Real time information management is essential whether textual or graphic. In a gaming situation or during situation assessment, time compression is a useful tool. In some cases, a display such as would appear in a process control environment may be more useful than text. This is another instance when an arcade-like environment may be most appropriate. CONCLUSIONS In summary, we are in the initial stages of an IR&D program to develop an EUF to support the needs of commanders and their staffs. The system will employ techniques from the domains of artificial intelligence and knowledge engineering to support tactical data acquisition and analysis, planning, and force manage- ment functions. Advanced automation and human factors techniques will be used to transfer as much of the workload from the commander and staff to the system as possible, thus allowing the users to focus their attention on the developing tactical situation rather than equipment operation per se. We anticipate that the successful development and fielding of an EUF for C3 would yield a significant payoff in terms of increased combat effectiveness of C3 systems. 274 APPENDIX FOURTH MIT/ONR WORKSHOP ON DISTRIBUTED INFORMATION AND DECISION SYSTEMS MOTIVATED BY COMMAND-CONTROL-COMMUNICATIONS (C ) PROBLEMS June 15, 1981 through June 26, 1981 San Diego, California List of Attendees Table of Contents Volumes I-IV 275 MIT/ONR WORKSHOP OF DISTRIBUTED INFORMATION AND DECISION SYSTEMS MOTIVATED BY COMMAND-CONTROL-COMMUNICATIONS (C3 ) PROBLEMS JUNE 15, 1981 - JUNE 26, 1981 ATTENDEES David S. AZberts Vidyadhana Raj AviZZa Special Asst. to Vice President Electronics Engineer & General Manager Naval Ocean Systems Center The MITRE Corporation Code 8241 1820 Dolley Madison Blvd. San Diego, CA 92152 McLean, VA 22102 Tel: (714) 225-6258 Tel: (703) 827-6528 Dennis J. Baker GZen AlZgaier Research Staff Electronics Engineer Naval Research Laboratory Naval Ocean Systems Center Code 7558 Code 8242 Washington DC 20375 San Diego, CA 92152 Tel: (202) 767-2586 Tel: (714) 225-7777 Alan R. Barnum Ami Arbel Technical Director Senior Research Engineer Information Sciences Division Advanced Information & Decision Systems Rome Air Development Center 201 San Antonio Circle #201 Griffiss AFB, NY 13441 Mountain View, CA 94040 Tel: (315) 330-2204 Tel: (415) 941-3912 Jay K. Beam Michael A thans Senior Engineer Professor of Electrical Engineering Johns Hopkins University & Computer Science Applied Physics Laboratory Laboratory for Information and Johns Hopkins Road Decision Systems Laurel, MD 20810 Massachusetts Institute of Technology Tel: (301) 953-7100 x3265 Room 35-406 Cambridge, MA 02139 Tel: (617) 253-6173 Robert Bechtel Scientist Naval Ocean Systems Center DanielZ A. Atkinson Code 8242 Executive Analyst San Diego, CA 92152 CTEC, Inc. Tel: (714) 225-7778 7777 Leesburg Pike Falls Church, VA 22043 Tel: (703) 827-2769 276 ATTENDEES C3 CONFERENCE PAGE TWO VitaZius Benokraitis Alfred Brandstein Mathematician Systems Analysis Branch US ARMY Material Systems Analysis CDSA MCDEC USMC ATTN: DRXSY - AAG Quantico, VA 22134 Aberdeen Proving Ground, MD 21005 Tel: (703) 640-3236 Tel: (301) 278-3476 James V. Bronson Lieutenant Colonel USMC Patricia A. BiZZllings ey Naval Ocean Systems Center Research Psychologist MCLNO Code 033 Navy Personnel R&D Center San Diego, CA 92152 Code 17 Tel: (714) 225-2383 San Diego, CA 92152 Tel: (714) 225-2081 Rudolph C. Brown, Sr. Westinghouse Electric Corporation WiZZiam B. Bohan P. 0. 746 Operations Research Analyst MS - 434 Naval Ocean Systems Center Baltimore, MD 21203 Code 722 Tel: San Diego, CA 92152 Tel: (714) 225-7778 Thomas G. Bugenhagen Group Supervisor James Bond Applied Physics Laboratory Senior Scientist Johns Hopkins University Naval Ocean Systems Center Johns Hopkins Road Code 721 Laurel, MD 20810 San Diego, CA 92152 Tel: (301) 953-7100 Tel: (714) 225-2384 James R. CaZZllan PauZ L. Bongiovanni Research Psychologist Research Engineer Navy Personnel R&D Center Naval Underwater Systems Center Code 302 Code 3521 Bldg. 1171-2 San Diego, CA 92152 Newport, RI 02840 Tel: (714) 225-2081 Tel: (401) 841-4872 David Castanon Christopher Bowman Research Associate Member, Technical Staff Laboratory for Information and VERAC, Inc. Decision Systems 10975 Torreyana Road Massachusetts Institute of Suite 300 Technology San Diego, CA 92121 Room 35-331 Tel: (714) 457-5550 Caibridge, MA 02139 277 Tel: (617) 253-2125 ATTENDEES C3 CONFERENCE PAGE THREE S. I. Chou Robin DiZZllard Engineer Mathematician Naval Ocean Systems Center Naval Ocean Systems Center Code 713B Code 824 San Diego, CA 92152 San Diego, CA 92152 Tel: (714) 225-2391 Tel: (714) 225-7778 Gerald A. CZapp EZizabeth R. Ducot Physicist Research Staff Naval Ocean Systems Center Laboratory for Information and Code 8105 Decision Systems San Diego, CA 92152 Massachusetts Institute of Tel: (714) 225-2044 Technology Room 35-410 Cambridge, MA 02139 DougZas Cochran Tel: (617) 253-7277 Scientist Bolt Beranek & Newman Inc. DonaZd R. Edmonds 50 Moulton Street Group Leader Cambridge, MA 02138 MITRE Corporation Tel: (415) 968-9061 1820 Dolley Madison Blvd. McLean, VA 22102 Tel: (702) 827-6808 A. Brinton Cooper, III Chief, C3 Analysis US ARMY Material Systems Analysis Martin Einhorn ATTN: DRXSY-CC Scientist Aberdeen Proving Ground, MD 21005 Systems Development Corporation Tel: (301) 278-5478 4025 Hancock Street San Diego, CA 92110 Tel: (714) 225-1980 David E. Corman Engineer Jonhs Hopkins University Leon Ekchian Applied Physics Laboratory Graduate Student Johns Hopkins Road Laboratory for Information and Laurel, MD 20810 Decision Systems Tel: (301) 953-7100 x521 Massachusetts Institute of Technology Room 35-409 WiZbur B. Davenport, Jr. Cambrdige, MA 02139 Professor of Communications Sciences Tel: (617) 253-5992 & Engineering Laboratory for Information and Thomas Fortmann Decision Systems Senior Scientist Massachusetts Institute of Technology Bolt, Beranek & Newman, Inc. Room 35-214 50 Moulton Street Cambridge, MA 02139 Cambridge, MA 02138 Tel: (617) 253-2150 Tel2 (617) 497-3521 278 ATTENDEES C 3 CONFERENCE PAGE FOUR Clarence J. Funk Peter P. Groumpos Scientist Professor of Electrical Eng. Naval Ocean Systems Center Cleveland State University Code 7211, Bldg. 146 Cleveland, OH 44115 San Diego, CA 92152 Tel: (216) 687-2592 Tel: (714) 225-2386 George D. Halushynsky Mario Gerla Member of Senior Staff Professor of Electrical Engineering Johns Hopkins University & Computer Science Applied Physics Laboratory University of California Johns Hopkins Road Los Angeles Laurel, MD 20810 Boelter Hall 3732H Tel: (301) 953-7100 x2714 Los Angeles, CA 90024 Tel: (213) 825-4367 Scott Harmon Donald T. GiZes, Jr. Electronics Engineer Technical Group Naval Ocean Systems Center The MITRE Corproation Code 8321 1820 Dolley Madison Bldv. San Diego, CA 92152 McLean, VA 22102 Tel: (714) 225-2083 Tel: (703) 827-6311 David Haut Irwin R. Goodman Research Staff Scientist Naval Ocean Systems Center Naval Ocean Systems Center Code 722 Code 7232 San Diego, CA 92152 Bayside Bldg. 128 Room 122 Tel: (714) 225-2014 San Diego, CA 92152 Tel: (714) 225-2718 C. W. HeZlstrom Professor of Electrical Eng. Frank Greitzer. & Computer Science Research Psychologist University of California, Navy Personnel R&D Center San Diego San Diego, CA 92152 La Jolla, CA 92093 Tel: (714) 225-2081 Tel; (714) 452-3816 Leonard S. Gross Ray L. Hershman Member of Technical Staff Research Psychologist VERAC, Inc. Navy Personnel R&D Center 10975 Torreyana Road Code P305 Suite 300 San Diego, CA 92152 San Diego, CA 92121 Tel: (714) 225-2081 Tel: (714) 457-5550 279 ATTENDEES C 3 CONFERENCE PAGE FIVE Sam R. HoZllingsworth CarroZll K. Johnson Senior Research Scientist Visiting Scientist Honeywell Systems & Research Center Naval Research Laboratory 2600 Ridgway Parkway Code 7510 Minneapolis, MN 55413 Washington DC 20375 Tel: (612) 378-4125 Tel: (202) 767-2110 Kuan-Tsae Huang Jesse Kasler Graduate Student Electronics Engineer Laboratory for Information and Naval Ocean Systems Center Decision Systems Code 9258, Bldg. 33 Massachusetts Institute of Technology San Diego, CA 92152 Room 35-329 Tel: (714) 225-2752 Cambridge, MA 02139 Tel: (617) 253- Richard T. KeZZlley Research Psychologist James R. Hughes Navy Personnel R&D Center Major, USMC Code 17 (Command Systems) Concepts, Doctrine, and Studies San Diego, CA 92152 Development Center Tel: (714) 225-2081 Marine Corps Development & Education Quantico, VA 22134 Tel: (703) 640-3235 David KZeinman Professor of Electrical Eng. & Computer Science University of Connecticut Kent S. HuZZ Box U-157 Commander, USN Storrs, CT 06268 Deputy Director, Tel: (203) 486-3066 Mathematical & Information Sciences Office of Naval Research Code 430B Robert C. KoZb 800 N. Quincy Head Tactical Command Arlington, VA 22217 & Control Division Tel: (202) 696-4319 Naval Ocean Systems Center Code 824 San Diego, CA 92152 CaroZyn Hutchinson Tel: (714) 225-2753 Systems Engineer Comptek Research Inc. 10731 Treena Street MichaeZ Kovacich Suite 200 Systems Engineer San Diego, CA 92131 Comptek Research Inc. Tel: (714) 566-3831 Mare Island Department P.O. Box 2194 Vallejo, CA 94592 Tel: (707) 552-3538 280 ATTENDEES C3 CONFERENCE PAGE SIX Timothy Kraft AZexander H. Levis Systems Engineer Senior Research Scientist Comptek Research, Inc. Laboratory for Information and 10731 Treena Street Decision Systems Suite 200 Massachusetts Institute of San Diego, CA 92131 Technology Tel: (714) 566-3831 Room 35-410 Cambridge, MA 02139 Tel: (617) 253-7262 Manfred Kraft Diplom-Informatiker Victor O.-K. Li Hochschule der Bundeswehr Professor of Electrical Eng, Fachbereich Informatik & Systems Werner-Heissenbergweg 39 PHE 8014 Neubiberg, West Germany University of Southern California Tel: (0049) 6004-3351 Los Angeles, CA 90007 Tel: (213) 743-5543 Leslie Kramer Senior Engineer Glenn R. Linsenmayer ALPHATECH, Inc. Westinghouse Electric Corporation 3 New England Executive Park P. O. Box 746 - M.S. 434 Burlington, MA 01803 Baltimore, MD 21203 Tel: (617) 273-3388 Tel: (301) 765-2243 Ronald W. Larsen' Pan-Tai Liu Division Head Professor of Mathematics Naval Ocean Systems Center University of Rhode Island Code 721 Kingston, RI 02881 San Diego, CA 92152 Tel: (401) 792-1000 Tel: (714) 225-2384 Robin Magonet-Neray Joel S. Lawson, Jr. Graduate Student Chief Scientist C31 Laboratory for Information and Naval Electronic Systems Command Decision Systems Washington DC 20360 Massachusetts Institute of Tel: (202) 692-6410 Technology Room 35-403 Cambridge, MA 02139 Tel: 617) 253-2163 Dan Leonard Electronics Engineer Naval Ocean Systems Center Kevin MaZZoy Code 8105 SCICON Consultancy San Diego, CA 92152 Sanderson House Tel: (714) 225-7093 49, Berners Street London W1P 4AQ, United Kingdom Tel: (01) 580-5599 281 ATTENDEES C3 CONFERENCE PAGE SEVEN Dennis C. McCaZZ Charles L. Morefield Mathematician Board Chairman Naval Ocean Systems Center VERAC, Inc. Code 8242 10975 Torreyana Road San Diego, CA 92152 Suite 300 Tel: (714) 225-7778 San Diego, CA 92121 Tel: (714) 457-5550 Marvin Medina Scientist Peter Morgan Naval Ocean Systems Center SCICON Consultancy San Diego, CA 92152 49-57, Berners Street Tel: (714) 225-2772 London W1P 4AQ, United Kingdom Tel: (01) 580-5599 Michael Melich Head, Command Information John S. Morrison Systems Laboratory Captain, USAF Naval Research Laboratory TAFIG/IICJ Code 7577 Langeley AFB, VA 23665 Washington DC 20375 Tel: (804) 764-4975 Tel: (202) 767-3959 MichaeZ S. Murphy John MeZviZle Member of Technical Staff Naval Ocean Systems Center VERAC, Inc. Code 6322 10975 Torreyana Road San Diego, CA 92152 Suite 300 Tel: (714) 225-7459 San Diego, CA 92121 Tel: (714) 357-5550 Glenn E. MitzeZ Engineer Jim Pack Johns Hopkins University Naval Ocean Systems Center Applied Physics Laboratory Code 6322 Johns Hopkins Road San Diego, CA 92152 Laurel, MD 20810 Tel: (714) 225-7459 Tel: (301) 953-7100 x2638 Bruce Patyk Michael H. Moore Naval Ocean Systems Center Senior Control System Engineer Code 9258, Bldg. 33 Systems Development Corporation San Diego, CA 92152 4025 Hancock Street Tel: (714) 225-2752 San Diego, CA 92037 Tel: (714) 225-1980 282 ATTENDEES C CONFERENCE PAGE EIGHT RoZand Payne Barry L. Reichard Vice President Field Artillery Coordinator Advanced Information & Decision Systems US Army Ballistic Research 201 San Antonio Circle #286 Laboratory Mountain View, CA 94040 ATTN: DRDAR-BLB Tel: (415) 941-3912 Aberdeen Proving Ground, MD 21014 Tel: (301) 278-3467 Anastassios Perakis Graduate Student David Rennels Ocean Engineering Professor of Computer Science Massachusetts Institute of Technology University of California, LA Room 5-426 3732 Boelter Hall Cambridge, MA 02139 Los Angeles, CA 90024 Tel: (617) 253-6762 Tel: (213) 825-2660 Lloyd S. Peters Thomas P. Rona Associate Director Staff Scientist Center for Defense Analysis Boeing Aerosapce Company SRI International MS 84-56 EJ352 P. O. Box 3999 333 Ravenswood Avenue Seattle, WA 98124 Menlo Park, CA 94025 Tel: (206) 773-2435 Tel: (415) 859-3650 Nils R. Sande ZZ, Jr. HariZaos N. Psaraftis President & Treasurer Professor of Marine Systems ALPHATECH, Inc. Massachusetts Institute of Technology 3 New England Executive Park Room 5-213 Burlington, MA 01803 Cambridge, MA 02139 Tel: (617) 273-3388 Tel: (617) 253-7639 DanieZ Schutzer Paul M. Reeves Technical Director Electronics Engineer Naval Intelligence Naval Ocean Systems Center Chief of Naval Operations Code 632 NOP 009T San Diego, CA 92152 Washington DC 20350 Tel: (714) 225-2365 Tel: (202) 697-3299 283 ATTENDEES C3 CONFERENCE PAGE NINE Adrian SegaZZll T. Tao Professor of Electrical Engineering Professor Technion IIT Naval Postgraduate School Haifa, Israel Code 62 TV Tel: (617) 253-2533 Monterey, CA 93940 Tel: (408) 646-2393 or 2421 Prodip Sen H. Gregory Tornatore Polysystems Analysis Corporation Johns Hokpins University P. O. Box 846 Applied Physics Laboratory Huntington, NY 11743 Johns Hopkins Road Tel: (516) 427-9888 Laurel, MD 20810 Tel: (301) 953-7100 x2978 HarZan Sexton Naval Ocean Systems Center Edison Tse Code 6322 Professor of Engineering San Diego, CA 92152 Economic Systems Tel: (714) 225-2502 Stanford University Stanford, CA 94305 Tel: (415) 497-2300 Mark J. Shensa Naval Ocean Systems Center Code 6322 E. B. TurnstaZZll San Diego, CA 92152 Head, Ocean Surveillance Tel: (714) 225-2349 or 2501 Systems Department Naval Ocean Systems Center Code 72 J. R. Simpson San Diego, CA 92152 Office of Naval Research Tel: (714) 225-7900 800 N. Quincy Arlington, VA 22217 Tel: (202) 696-4321 Lena Valavani Research Scientist Laboratory for Information and Stuart H. Starr Decision Systems Director Systems Evaluation Massachusetts Institute of The Pentagon Technology DUSD (C31), OSD Room 35-437 Room 3E182 Cambridge, MA 02139 Washington DC 20301 Tel: (617) 253-2157 Tel: (202) 695-9229 284 ATTENDEES C CONFERENCE PAGE TEN ManieZ Vineberg Richard P. Wishner Electronics Engineer President Naval Ocean Systems Center Advanced Information & Decision Code 9258 Systems San Diego, CA 92152 201 San Anotnio Circle Tel: 714) 225-2752 Suite 286 Mountain View, CA 94040 Tel: (415) 941-3912 Joseph H. Wack Advisory Staff Westinghouse Electric Corporation Joseph G. WohZ P. O. Box 746 MS-237 V. P. Research & Development Baltimore, MD 21203 ALPHATECH, Inc. Tel: (301) 765-3098 3 New England Executive Park Burlington, MA 01803 Tel: (617) 273-3388 Jan D. Wald Senior Research Scientist Honeywell Inc. John M. Wosencraft Systems & Research Center Head of C3 Curriculum MN 17-2307 Naval Postgraduate School P. O. Box 312 Code 74 Minneapolis, MN 55440 Monterey, CA 93940 Tel: (612) 378-5018 Tel: (408) 646-2535 Bruce K. Walker Lofti A. Zadeh Professor of Systems Engineering Professor of Computer Science Case Western Reserve University University of California Cleveland, OH 44106 Berkeley, CA 94720 Tel: (216) 368-4053 Tel: (415) 526-2569 David White Advanced Technology, Inc. 2120 San Diego Avenue Suite 105 San Diego, CA 92110 Tel: (714) 981-9883 Jeffrey E. WieseLthier Naval Research Laboratory Code 7521 Washington DC 20375 Tel: (202) 767-2586 285 SURVEILLANCE AND TARGET TRACKING FOREWORD ...... DATA DEPENDENT ISSUES IN SURVEILLANCE PRODUCT INTEGRATION Dr. Daniel A. Atkinson ...... MEMORY DETECTION MODELS FOR PHASE-RANDOM OCEAN ACOUSTIC FLUCTUATIONS Professor Harilaos N. Psaraftis, Mr. Anatassios Perakis, and Professor Peter N. MikhaheZvsky ...... DETECTION TRESHOLDS FOR MULTI-TARGET TRACKING IN CLUTTER Dr. Thomas Fortmann,Professor Yaakov Bar-ShaZom, and Dr. MoZZy Scheffe ...... MULTISENSOR MULTITARGET TRACKING FOR INTERNETTED FIGHTERS Dr. Christopher L. Bowman ...... MARCY: A DATA CLUSTERING AND FUSION ALGORITHM FOR MULTI-TARGET TRACKING IN OCEAN SURVEILLANCE Dr. Michael H. Moore ...... AN APOSTERIORI APPROACH TO THE MULTISENSOR CORRELATION OF DISSIMILAR SOURCES Dr. MichaeZ M. Kovacich ...... A UNIFIED VIEW OF MULTI-OBJECT TRACKING Drs. Krishna R. Pattipati, Nils R. SandeZZ, Jr., and Leslie C. Kramer ...... OVERVIEW OF SURVEILLANCE RESEARCH AT M.I.T. Professor Robert R. Tenney ...... A DIFFERENTIAL GAME APPROACH TO DETERMINE PASSIVE TRACKING MANEUVERS Dr. PauZ L. Bongiovanni and Professor Pan-T. Liu ...... 286 DESCRIPTION OF AND RESULTS FROM A SURFACE OCEAN SURVEILLANCE SIMULATION Drs. Thomas G. Bugenhagen, Bruce Bundsen, and Lane B. Carpenter ...... AN OTH SURVEILLANCE CONCEPT Drs. LesZie C. Kramer and Nils R. SandeZZ, Jr ...... APPLICATION OF AI METHODOLOGIES TO THE OCEAN SURVEILLANCE PROBLEM Drs. Leonard S. Gross, MichaeZ S. Murphy, and CharZes L. Morefield ...... A PLATFORM-TRACK ASSOCIATION PRODUCTION SUBSYSTEM Ms. Robin DiZZllard ...... 287 II SYSTEM ARCHITECTURE AND EVALUATION FOREWORD ...... C I SYSTEMS EVALUATION PROGRAM Dr. Stuart H. Starr ...... C SYSTEM RESEARCH AND EVALUATION: A SURVEY AND ANALYSIS Dr. David S. AZberts ...... THE INTELLIGENCE ANALYST PROBLEM Dr. DanieZ Schutzer ...... DERIVATION OF AN INFORMATION PROCESSING SYSTEMS (C3/MIS) --ARCHITECTURAL MODEL -- A MARINE CORPS PERSPECTIVE Lieutenant CoZoneZ James V. Bronson ...... A CONCEPTUAL CONTROL MODEL FOR DISCUSSING COMBAT DIRECTION SYSTEM (C2 ) ARCHITECTURAL ISSUES Dr. Timothy Kraft and Mr. Thomas Murphy ...... EVALUATING THE UTILITY OF JINTACCS MESSAGES Captain John S. Morrison ...... FIRE SUPPORT CONTROL AT THE FIGHTING LEVEL Mr. Barry L. Reichard ...... A PRACTICAL APPLICATION OF MAU IN PROGRAM DEVELOPMENT Major James R. Hughes ...... HIERARCHICAL VALUE ASSESSMENT IN A TASK FORCE DECISION ENVIRONMENT Dr. Ami ArbeZ ...... 288 OVER-THE-HORIZON, DETECTION, CLASSIFICATION AND TARGETING (OTH/DC&T) SYSTEM CONCEPT SELECTION USING FUNCTIONAL FLOW DIAGRAMS Dr. GZenn E. MitzeZ ...... A SYSTEMS APPROACH TO COMMAND, CONTROL AND COMMUNICATIONS SYSTEM DESIGN Dr. Jay K. Beam and Mr. George D. Haluschynsky ...... MEASURES OF EFFECTIVENESS AND PERFORMANCE FOR YEAR 2000 TACTICAL C3 SYSTEMS Dr. Djimitri Wiggert ...... AN END USER FACILITY (EUF) FOR COMMAND, CONTROL, AND COMMUNICATIONS (C3 ) Drs. Jan D. Wald and Sam R. Hollingsworth ...... 289 COMMUNICATION, DATA BASES & DECISION SUPPORT FOREWORD ...... RELIABLE BROADCAST ALGORITHMS IN COMMUNICATIONS NETWORK Professor Adrian SegaZZ ...... THE HF INTRA TASK FORCE COMMUNICATION NETWORK DESIGN STUDY Drs. Dennis Baker, Jeffrey E. Wieseithier, and Anthony Ephremides ...... FAIRNESS IN FLOW CONTROLLED NETWORKS Professors Mario GerZa and Mark Staskaukas ...... PERFORMANCE MODELS OF DISTRIBUTED DATABASE Professor Victor O.-K. Li ...... ISSUES IN DATABASE MANAGEMENT SYSTEM COMMUNICATION Mr. Kuan-Tase Huang and Professor Wilbur B. Davenport, Jr.. MEASUREMENT OF INTER-NODAL DATA BASE COMMONALITY Dr. David E. Corman ...... MULTITERMINAL RELIABILITY ANALYSIS OF DISTRIBUTED PROCESSING SYSTEMS Professors Aksenti Grnarov and Mario GerZa ...... FAULT TOLERANCE IMPLEMENTATION ISSUES USING CONTEMPORARY TECHNOLOGY Professor David RenneZs ...... APPLICATION OF CURRENT AI TECHNOLOGIES TO C2 Dr. Robert Bechtal ...... 290 A PROTOCOL LEARNING SYSTEM FOR CAPTURING DECISION-MAKER LOGIC Dr. Robert BechtaZ ...... ON USING THE AVAILABLE GENERAL-PURPOSE EXPERT-SYSTEMS PROGRAMS Dr. Carroll K. Johnson ...... 291 IV C THEORY FOREWORD ...... RATE OF CHANGE OF UNCERTAINTY AS AN INDICATOR OF COMMAND AND CONTROL EFFECTIVENESS Mr. Joseph G. WohZ ...... THE ROLE OF TIME IN A COMMAND CONTROL SYSTEM Dr. Joel S. Lawson, Jr ...... GAMES WITH UNCERTAIN MODELS Dr. David Castanon ...... INFORMATION PROCESSING IN MAN-MACHINE SYSTEMS Dr. Prodip Sen and Professor Rudolph F. Drenick ...... MODELING THE INTERACTING DECISION MAKER WITH BOUND RATIONALITY Mr. Kevin L. Boettcher and Dr. Alexander H. Levis ...... DECISION AIDING -- AN ANALYTIC AND EXPERIMENTAL STUDY IN A MULTI-TASK SELECTION PARADIGM Professor David L. Kleiman and Drs. Eric P. Soulsby, and Krishna R. Pattipati ...... FUZZY PROBABILITIES AND THEIR ROLE IN DECISION ANALYSIS Professor Lotfi A. Zadeh ...... COMMAND, CONTROL AND COMMUNICATIONS (C3 ) SYSTEMS MODEL AND MEASURES OF EFFECTIVENESS (MOE's) Drs. Scot Harmon and Robert Brandenburg ...... THE EXPERT TEAM OF EXPERTS APPROACH TO C ORGANIZATIONS Professor Michael Athans ...... 292 A CASE STUDY OF DISTRIBUTED DECISION MAKING Professor Robert R. Tenney ...... ANALYSIS OF NAVAL COMMAND STRUCTURES Drs. John R. DeZaney, NilZs R. SandeZZ, Jr., Leslie C. Kramer, and Professors Robert R. Tenney and Michael Athans ...... MODELING OF AIR FORCE COMMAND AND CONTROL SYSTEMS Dr. Gregory S. Lauer, Professor Robert R. Tenney, and Dr. Nils R. SandeZZ, Jr ...... A FRAMEWORK FOR THE DESIGN OF SURVIVABLE DISTRIBUTED SYSTEM -- PART I: COMMUNICATION SYSTEMS Professors Marc Buchner and Victor Matula: presented by Professor Kenneth Loparo ...... A FRAMEWORK FOR THE DESIGN OF SURVIVABLE DISTRIBUTED SYSTEMS -- PART II: CONTROL AND INFORMATION STRUCTURE Professors Kenneth Loparo, Bruce Walker and Bruce Griffiths .. CONTROL SYSTEM FUNCTIONALIZATION OF C- SYSTEMS VIA TWO-LEVEL DYNAMICAL HIERARCHICAL SYSTEMS (DYHIS) Professor Peter P. Groumpos ...... SEQUENTIAL LINEAR OPTIMIZATION & THE REDISTRIBUTION OF ASSETS Lt. CoZoneZ Anthony Feit and Professor John M. Wozencraft .... C AND WAR GAMES -- A NEW APPROACH Dr. Alfred G. Brandstein ...... 293