summary report - defense technical information center report the second conference on standards for...
TRANSCRIPT
AD-A241 113
II,IA N. II-G
Contract Number N61339-89-C-0043
PM TRADE ;J k-.DARPA t '''
January 15-17, 1990 SEP25 ii;
Summary ReportThe Second Conference on Standardsfor the Interoperability ofDefense SimulationsVolume I!: Attendees List and Viewgraphs
Editors:Karen DanisasBob GlasgowBrian GoldiezBruce McDonaldChris Pinon
This report is infornational and does not express the opinions of PM TRADE or DARPA Ls=r
Institute for Simulation and Training12424 Research Parkway, Suite 300 91-11411Orlando FL 32826 91-11411University of Central Florida
. . - .... i Division of Sponsored Research
IST-CF-90-I
:'- :' 072
PAGESARE
MISSINGIN
ORIGINALDOCUMENT
UNCLA.SSIFIED
SForm Approved
REPORT DOCUMENTATION PAGE OMNo.0704od88
Ia. REPORT SECURITY CLASSIFICATION b ESTRICTIVE NIARK:NGS
Unclassified None2a. SECURITY CLASSIFICATION AUTHORITy 3 DISTRIBUTION, AVAILABILITY OF REPORTN/A Approved for Public Release;
2b. DECLASSIFICATION/ DOWNGRADING SCHEDULE Distribution is Unlimited
N/A4. PERFORMING ORGANIZATION REPORT NUMBER(S) 5 MONITORING COkGANiZATION REPORT NUMBER(S)
IST-CF-90-1 IST-CF-90-1
6a. NAME OF PERFORMING ORGANIZATiCN 6o OFFICE S.-r",1BOL 7a. NAME OF MO-%,TORING ORGANIZATION
Institute for Simulation (If applicable) Project Manager for Training Devices
and Training I........_.6c. ADDRESS (City, State, and ZIP Code) 7b ADDRESS (City. State, and ZIP Code)
12424 Research Parkway, Suite 300 12350 Research Parkway
Orlando, FL 32836 Orlando, FL 32826
8a NAME OF FUNDINGISPONSORiNG 8b. OFFiCE SYMBOL 9 PROCUREMENT iNSTRuMENT IDENTIFICATON NUMBER
ORGANIZATION (if applicable)
DARPA/PM TRADE __ N61339-89-C-0043
8c. ADDRESS (City, State, and ZIP Code) 10. SOURCE OF FUNDING NUMBERS
1400 Wilson Blvd. PROGPAM PROJECT -- TASK WORK UNIT
Arlington, VA 22209 ELVE'T NO. NO. NO. ACCESSION NO.
11. TITLE (Include Security Classification)
Summary Report: The Second Conference on Standards for the Interoperability of Defense
Simulations Volume TI Attendees List and View Graphs---12. PERSONAL AUTHOR(S)
(Edited by), Danisas, Karen; Glasgow, Bob; Goldiez, Brian; McDonald, Bruce; Pinon, Chris13a. TYPE OF REPORT 13b. TIME COVERED 14. DATE OF REPORT (Year, Month, Day) 115. PAGE COUNT
Summary FROM TO 1990, January 15-17 23816. SUPPLEMENTARY NOTATION
17. COSATI CODES 18. SUBJECT TERMS (Continue on reverse if necessary and identify by block number)FIELD GROUP SUB-GROUP Standards, Interoperability of Defense Simulations, Terrain
Databases, Protocols, SIMNET
19. ABSTRACT (Continue on reverse if necessary and identify by block number)This report presents a summary of the activities of the Second Conference of
Standards for the Interoperability of Defense Simulations sponsored by the Defense
Advanced Research Projects Agency (DARPA) and the program Manager for Training
Devices (PM TRADE). The workshop was hosted by the Institute for Simulation and
Training/University of Central Florida (IST/UCF) on 15-17 January, 1990.
This volume of the report contains an attendees list, a copy of the view graphs
used during presentations and a copy of all documents that were submitted at the
conference for the attendee information.
20. DISTRIBUTION /AVAILABILITY OF ABSTRACT 21. ABSTRACT SECURKY CLASSIFICATIONNUNCLASSIFIED/JNLIMITED t ,SAME AS RPT. - DTIC USERS ONCL iS l
22a. NAME OF RESPONSIBLE INDIVIDUAL 22b TELEPHONE (Include Area ode) 12%. OFFICE SYMBOL
i,7 07 - 6A C A, -TN -EDD Form 1473, JUN 86 Previous editions are obsdlere. SECURITY CLASSIFICATION OF THIS PAGE
CONTENTS
Introduction iii
Appendix A: Attendees List A-i
Appendix B: View Graphs of Main Speakers B-i
Appendix C: View Graphs and Documents for NetworkCommunications Working Group BreakoutSessions. C-I
Appendix D: View Graphs and Documents for Terrain
Databases Working Group Breakout Sessions D-I
Appendix E: The SIMNET Tutorial E-I
Appendix F: View Graphs of Concluding Remarks F-i
*3ISrN8PE~-EO
_-, -J u2 ,n /-
~I
a. *
For~L
; ue. /
SUMMARY REPORT
The Second Conference on standardsfor the Interoper&bility of Defense simulations
January 15-17, 1990 Orlando, FL
INTRODUCTION
This report presents a summary of the activities of the SecondConference on Standards for the Interoperability of DefenseSimulations sponsored by the Defense Advanced Research ProjectsAgency (DARPA) and the Program Manager for Training Devices (PMTRADE). The workshop was hosted by the Institute for Simulationand _Tr aning / University of Central Florida (IST/UCF) on 15-17,J-anluary 1990, in Kissimmee, Florida.
--This is the second workshop concerning the development oftechnicaf standards for networking defense simulations. Thesestandards are intended to meet the needs of large scale simulatedengagements systems which are being used increasingly to supportsystem acquisition, test and evaluation, tactical warfaresimulation and training in DoD. The primary'goals of thisworkshop were to provide a forum and discuss issues prior to thedevelopment of a Protocol Data Unit level standard, to capturenetworking requirements and needs, and to exchange ideas and keepinterestedPartiesiomed-on-networking-techo lgy issues. N
The three day workshop focused on two major topic areas:Communication Protocols apd Terrain Databases. The CommunicationProtocols was headed up by Dr. Ron Hofer, ChiEf, ngineering, PMTRADE. This group was mainly concerned with what goes over thewire. The following subgroups dealt with those issbes.
* Interface* Time/Mission Critical* Security* Long Haul/Wide Band* Non visual
The Terrain Databases Working Group was headed up by GeorgeLukes, Director of the Center for Autonomous Technologies, U. S.Army Engineer Topographic Laboratory. This group was mainlyconcerned with how the terrain data is interpreted. Thefollowing subgroups dealt with those issues:
* Correlation* Dynamic Terrain* Unmanned Forces* Interim Terrain Database
iii
In response to comments made at this workshop, a new subgroup isbeing formed to address Human Performance Measures. Thissubgroup will address requirements for recording and assessingstudent performance in the simulators on the network. :%s part ofthis effort, issues concerning instructor interfaces fo:'controlling exercises and evaluating student performance wil'. beaddressed. User inputs about needed capability for networkeJsimulators will be solicited. Mr. Bruce McDonald, Institute forSimulation and Training, will chair this subgroup, and anycomments and suggestions should be directed to him.
This report has been separated into three volumes. Volume Icontains summaries of all presenters' speeches. Volume IIcontains an attendees list, a copy of the view graphs used duringpresentations, and a copy of all documents that were submitted atthe conference for the attendee information. Volume III containsa copy of all position papers received by IST/UCF by 15 February,1990.
APPENDIX A
Attendees List
NATIONAL SECURITY INDUSTRIAL ASSOCIATIONEVENTS REGISTRATION ROSTER
January 15-17, 1990
Attendee Name Company Name
Craig S. Anken Rome Air Development Center
Dr. Richard Astro UCFNorman C. Baillargeon American Systems Corp
Gary E. Baker Naval Space & Waifare Sys. Cmd.Wolfgang Beisenherz Ministry of Defense
Charles J. Benton Technology Systems, Inc.Barbara J. Birks McDonnel Aircraft
Dr. Barry Boehm DARPA
Larry R. Bouterie Digital Equipment Corp
Arnold Bramson General Electric Co.
J. Joseph Brann IBM Corp., SIDKlaus Brueckner SchleifringPerry L. Buchanan Digital Equipment Corp.
Jerry D. Burchfiel BBN Systems & Technologies
J. Cadiz University of Central FloridaDouglas R. Caldwell U.S. Army - ETL
John Callaway R & D Associaties
J. Phil Carley Concurrent Computer Corp
James R. Cooley AAI CorporationLloyd N. Cosby Insitutute for Defense AnalysesAllan Cox British Embassy
Dick Cranston American Systems Corp.
Claude H. Crassous THOMSON CSF Simulators Div.
Steven E. Cunningham Technology Systems, Inc.Dean Curtiss Bendix Test Systems Division
Karen Danisas University of Central Florida
Philip E. Danley Grumman Aerospace Corp.
Dr. James W. Dilie McDonnell Douglas Corp.
Drake Dingeman Systran Corp.
Edmund J. Dotighty Harris Corp.
A-3
Colin Dutton Army School Training SupportJames Evans USAF
Grayden Figart SYSCON CorpDexter Fletcher Institute for Defense AnalysisMark A. Flood U.S. Army Corps. of EngineersRobert E. Frascr, III Perceptronics
Mark D. Frost Booz, Allen & Hamilton Inc.Richard P. Gagan Raytheon Co.
David N. Garnett ETA Technologies
G. Gcorge CAE - Link FlightB. Glaskow University of Central FloridaBrian F. Goldiez Universi!y of* Central FloridaPrrice Gosselin CAE Electonics LTD
Kurt Graffunder Hughes Simulation Systems
Bruce E. Green Nat'l Sec Industrial Assoc.Michael R. Gregary -Tracor Flight Sip. Inc.
Bernard E. Griffiths Air ForceRaymond A. Haeme Booz, Allen & Hamilton Inc.Joseph P. Haller, Jr. Grumman Corp
Christine Hanson ASD/YWB
William T. Harris Naval Training Systems CenterMichael Hayes Perceptronics, Inc.Dr. Ronald C. Hofer Naval Training Systems CenterEric Hoierman Hughes Simulation Systems, Inc.Sam R. Hcllingsworth Hughes Simulation Systems, Inc.Udo Hollaender Wegmann Co.Michael D. Johnson Digital Equipment Corp.Randy L. Johnson Naval Surface Warfare CenterMichael S. Kamrowski Air Force Human Resources Lab.Larry P. Keller ARINC Research CorporationDr. Ron Kerber McDonnell Douglas Corp.R. Klasky University of Central FloridaLTCOL Robert L. Kloeeker Army Joint Warfare Center
Samuel N. Knight CAE-Link CorporationLee Kollmorgen SIMNETRonald W. Krisak ODASD/RA(R&T)
A-4
Jerrold E. Kronenfeld Analytic Sciences Corp.Georges Lavault THOMSON CSFCurtis G. Lawson GTE Gov't SystemsHeinz-Bernd Lotz BUNDESAMT FUR WEHRTECHNIKGeorge E. Lukes U.S. Army Engr. Topographic LabWarren R. MacDiarmid Science Applications, Inc.Daryl R. Mair Digital Equipment Corp.Farid Mamaghan BBN Systems & Tech. Corp. ASDGeorge L. May, III Defense Mapping AgencyDavid R. McKeeby Analysis & Technology, Inc.Larry L. Mengel USAARMCDuncan C. Miller BBN Systems.& Technologies
John Miller Sanders/Lockhead Co.Richard Moon Evans & Sutherland Computer Co.H. Richard Moore E-Systems Garland Div.Phil Morris BBN Systems & Tee. Corp. ASDFranklin I. Moses US Army Research InstituteDr. J. Michael Moshell University of Central FloridaKevin B. Muhm USAETL - GL-TAEugene P. Naccarato Planning Research CorporationThomas M. Nelson McDonnell Douglas Electr. Co.Phil Ness Boeing Co.Raye Norvelle U.S. Army Engr. Topographic LabJames F. O'Bryon ODISDA(A)
Alan B. Oatman BBNLTC Stephen S. Overstreet USA Proj Mgr for Trng DevicesJuan A. Perez U.S. Army - EThDaina Pettit Evans & Sutherland Computer Co.Pascal Peyronnet THOMSON CSF - Simulators Div.C. Pinon University of Central FloridaArthur Pope BBN Systems & Tech. Corp.Leland B. Ransom, III Integration & Human ResourcesDennis W. Rebertus CTA IncorporatedA. Hugh Rodgers McDonnell Douglas Corp.
Ice Rogers OSD
Alfredo A. Romagosa Harris Computer Sys. Div.
A-5
HWu11 C. Romine CAE - Link CorporationRobin M. Roulcau AAI CorporationWilliam J. Rowan Naval Training Systems CenterPaul E. Rubin Computer Sciences Corp.L. Michael Sabo SSDS. Inc.Arun Sankar Hughes Aircraft Co.Steven R. Sarner ASDIYWB.Richard L. Schaffer BBN Sys*tcms & Tech. Corp.William 11. Schelker ASKIDPC TT
Marc Schlackman GTE Gov't SystemsBill W. Scott B-Systems. Inc.Steve S. Seidensticker Lo-icon,lnc. 'Tac./Tr-n.Sys.
Steven L. Shaffer SSDS, Inc.LTC James E. Shiflett (USA) DARPAIISTO
Jerome Shimp Honeywell. Inc
Calvin S. Shoemaker Flashpoint Computer Corp.Stephen Smyth BBN Advanced SimulationKarl A. Spuhl McDonnell Douglas Corp.Steven D. Swaine McDonnell Douglas AircraftLarry Stevens AAI Corporation
Robert Stevens ETA TechnologiesJ. Thompson Univeristy of Central FlorifaRobert N. Thompson ARINC Research CorporationKe-in WV. Tinsley E-Systems. Inc.Tomn Underdown Digital Equipment Corp.Lawrence J. Van Sickle McDonn.11l Douglas -CorpRolland M. Waters BBN Systems & Tech. Corp.James WV. Watson Sparta, Inc.
Barry WV. W~ebb Lockheed Aeronautical SystemsLawrence A. Welsch NISTG. Pete Wever BBN Systems & Tech. Corp. ASDRonald L. Williams ConCurrent Computer Corp.Ronald Wimbcrley Martin Marietta Simul. Sys.LTC Albert Wimmeim PM TradeDavid C. Wood The Mitre Corp.
Christopher E. Wright GE/Simulation & Control Sys. Dept
A-.6
Dr. Michael J. Zyda Naval Postgraduate School
Colin G. Agostinl Tracor Inc.
Robert Alger Ford Aerospace
Carl Arizpe Digital Equipment Co.
Gary Arrasmith Hughes Aircraft Co.
John Bcarfoot MOD UK Army - Army Trng 4
Steven Blumenthal BBN Sys. & Tech Corp.
Frank Calzaretta BBN Sys & Tech Corp
Timothy B. Cunningham Concurrent Computer Corp.
Tony Dalsasso U.S. Air Force
James Dike Harris/GSSD
John Doner Harris Corp.
Dan Eliason BBN
Ron Ewart U.S. Air Force
Andrew Fyke Hughes Aircraft
Tom Gehl IBN
Stewart R. Gibb Naval Air Sys. Command
James H. Hammond Naval Oceanographic & Atmospheric
Res.earch Lab.
Ronald Hendricks CAE-Link
James Hines PRC
Johann Hinrichs Competence Center Information
Clifford Holland NOARL
Douglas I. Holmes Lockhead Aeronautical Sys. Co.
Wendy Hudson Concurrent Computer Co.
John Hukill Martin Marietta Corp.
All Kerecman USAC_-OM
John P. Killackey Hughes Simulation Sys., Inc.
David Lawson McDonnell Douglas Helicopter Co.
Michael Lombardi USADECOM
Bryan Lowe McDonnell Douglas Electronic
Frederick Mangol Information Spectrum Inc.
Francis X. Maginnis The Mitre Corp.
Dennis McBride ISTO DARPA
Bruce McDonald IST
A-7
William Murphy Digital Equipment Corp.Nicholas Palniotto BDM'* International. Inc.James Panagos Boll Beranek & NewmanDave Pfahler Hughes Aircraft Co.Lawrence Redmond GTE Gov't Sys. Commr. Sys.Paula Ridolfi USAF ASDIYWB,Ronald G. Rhoades BDM mIl.- Inc.Warren E. Richeson McDonnel DouglasBruce Robinson Rh & Co.IFord AerospaceJohn Ross SSC Ltd.Mel Sar Harris Corp.Randy Saunders Hughes Simulition Sys., Inc.Ludger Schumann Competence Center InformationSteven Schwalan CAE - LinkJohn Shockley SRI Intl'lRog-cr Sirfit Autometric. Inc.Rosaland Spina General Dynamics Land Sys.Thomas Stanzione BBNTerry Snyder Grumma: Simulationfrraincr
ProductsRichard Socldner Naval Training, Sys. Ctr.Jeffrey Stewart Software Engineering InstituteBarry Tahlor Concurrent Computer Corp.Donald Tedder Simulatin Animation Svcs. of Fl. Inc.David Teichman ECC Int'lGary Teper Information Spectrum. Inc.Ron Toupal Merit TechnologyDavid Tseng Hughes Research Labs.DarrelIl Turner Martin Marietta. Info & Comm. Sys.Richard Weatherly MitreJohn Wang Naval Underwater Sys. Ctr.Haward Wichanskv USA CEMPat Widder McDonnell Douglas HelicopterPatrick Yearick CAE - Link Fit. SimulationJohn Zammit Digzital Equip. Corp.Gerald Zubak Hughes Aricraft Co.
Richard Bouchard Lockhead/Sanders
Jean Pierre Faye Thompson CSF
Umberto Fontanella Agusta SPA Divisione Sistemi
James A. Kane Bolt Beranek & Newman
C. Lavault Thompson - CSE
Matt Narotam Burtek
Raye Norvelle U.S. Army Engr. Topographic
Laboratories
Barbara Osbon General Dynamics Land Sys.
Dennis Pierce ECC Int'l Corp.
Gerd - D. Rehberg Wegmann & Co. GMBH
Robert Richbourg U.S. Military Academy
Glenn Weissinger General Dynamics
Phillip Yoo Digital Equipment Corp.
A-9
APPENDIX B
View Graphs of Main Speakers
0
B-3
- z
B-4
0
V)
C40 0
0 4-
4.-).
00
40--
"C 4-J
0
(4Z4(
0 0 "- 0.4
B-5-
0
ToOral
To C
cir..q
4-j
B-6
w-j
w
LuF
zwz
wwa-n
B-7
0
4-1 C.) 00
00
E 42,0 pL
ci:) C-)
CZ -0
0 4-z c) C' l)4
0 4-A
4-1) W) Itz
tCi:
01~
0 w
B-8
44-
000
Cr o bp cor
• r .,4 ¢I
0 q_0
.04 ["- o -
0 00
C C/)00 0
C*4)
B-90
z 0 • •
a'0 000
-2 o
0 z -. u
iP-
B-10
w >
0 4-
-B-1
00
Ct
0t C40 4-
004--
Ct) ;-o44-
~cC/)0Z
>
0 >
B-I12
~N
00
COO
0.<[ 0 ,.-.0
B-13
Va
C()4'0
0d0,- 4
C- 0 0o
7- C/)-
_ ca
C) 0-5)<v
>i 000
B-14
o< Eu 0
0 0)I.o oE .4
4-4
B-1-
0 0
B-i15
40
co
4C0--0w
-~4-j
Teee-Cu
B-16
CC
a0)
a)co
70 CZ00
B-1
B-18
PEN*
B-19
B-20
0/0
C/t)
00 C/)-
C/) 0-1m 4--
Ct)t
- 0j
Ct)d0 a
- B-
9z~ -q
-QuC
cn r_ 0)ato 5 E
0 <~
on 0 0
*0 ca ~
< . CU 5
B-22.
c~c0
C.
c0
IM- . U-zc
0/ 0 C/
of Z 0~-.~w z)- .,0
cjcd
CI4 .0 T-Z Im Z 9
z .4
B-23
6-
00
o0-1-
ca 0 0
C:: C .. .. - .
~<C.j
B-24
INTEROPERABILITY EXPERIENCE
1. ORGANIZATIONS INVOLVED
2. GOALS
3. NETWORKING CONFIGURATION/DESCRIPTION
4. CONFIGURATION OF EACH NODE(e.g. update rate, synchronous transmission, HAWconfiguration, Visual/Sensor Simulation, TerrainDatabase Source, etc.
5. PERFORMANCE PARAMETERS MEASURED(To include Method and Scope of Measurement).
6. QUALITATIVE RESULTS
B-25
C;/) 00 00
0
co 0r 00
- U0
B-2
z
00
20-0 -
I-In ~ c
Dm 0 acZ
F-- z0F-
B-2 7
z0I-
0 WUJz Z:~
0 F
0 z 0
LL WCOU)Z
< o0
II.-.
B-28
0
0 z z
UZL
Hi 0 i n J LU
ui zU)> FHO
D 00
(.)
B-29
LLJONOC(
0 CT-U)
LL <0z /
(In) Lj -Z C))J
U) t
0-3
I-
LU
W EIin rU ) 0) )
M U . m m ..
U) U) .o c
m -D a ~ En Z5 E~
0) 'a b-1 0) , -)0 r-E.
Q)U En C u - )-0 ~ Z5 00 -
> M a) O 0.~ 0. C 0
00=0 Ur. ) ) C C L cu
a~ f6 Z5q oc
U)~'0 cts - c& Y-~'n u .a,,Q )ci U Co 00
Q) =-E
E Eoa)-D m I00 0w 0 0 0
U).0 >
L-00
U)
C).
B-3 1
z0
I~uj
0 ) LLz (LowU
1~Oz
o z 0
W~(n
0ow 0
00 0
cc .
B-3 2
z 10
O>-IJM >
0- -04 w 0oL 0 w
0w <C) w. LL
0- F- mw'LLJo -J
00
w U) U)
W C-,
B-3 3
LL-J
0z z2 0
xm < z
I-- (nj
00 cF- wL
1j(- 0
z wlL ) n. _
J cn zCCCLF.uIC/
wwwj uj, >o- f >
0 > u 0C/ .
Z U. 0
B-34
z0
I-
cc:
o WULz OZ
o z 0Om Ow U.
0L W~b
00
w CL Z5
C,,z Fo JCf)
F-i C,)
LL - WLL
F- LU-
z.ocr j br
ZrCO C
Fz LM. < 0
00 u0
B-3
d -. I
Q)
0 0(C6ga. v
4-
--0 c
. 0 -
,.- a) a)"L
-0 m Q)a)
E
0 0
cc a) 0 0Q
4-3
a -a>
(DCL
w cn
0 - 3 0LL>r
>/C z m C/
§"* 0 0 0u
co
B-3 7
CI) Cl)
0 zL..U
w wL
F-F (a)0:_~L W 0:0
WJ 0
>J: U) fU
4: 0 3: 0j
cc o00 C L
CLJ U)0My)aCL~ <CIOW) 0 . L
LUFZ-F- L
F-L >/1 0 c -L 3:<
0 cc* 0 F-
1= CJ) - C
cc m
0ccc
co
co-LL
U0
co
cyc
LU
co
ij ci i Co~ cJ
B-T-
LU)zn
<
< w L6
wo CL,
0- 0 0CC W
LU c.~-.
0- >-
0~Q
LUL WZ-
0- w
cc w c
w -U. 0 :i zLo - ii 1-0 M C0LLJc >: n U
0 n-0C-0 -WMX ULU > x z m m
CL LB-40
I H d-
U).
0
4- \30OdIHIV AAVN '~AWV
o0 c~.occc
00U0C) *-J
ccW
UE0
(1)>0~
N LI
cB-4 I
0) -W
LL.
I. 0aU
ejCO
COCoU)i
00 -n
0 0
C 0 o ~ 0-
ii 0 00)
Cc o >%C
cn3
__ Co.0 EImm0& 0/ Ol)
_ C'JE CO
CO" 0 ci0 >%r.
ca0.
0>
0
<o0).0~W r Z E
1n- >-0.
B-4
>14
0 U
00
t) m" W r-a) $4
E.~ v-w401U)5 >
1U4 41a)4 4 ) El
124~B- 53, /
0 C
-,0 .2 W
W~>..- .-
0 0
w 0~0
0 Q
1--
WWD
1.0~ ~~~ ~ E ,WQ :u
Z0 cr >iE a)(
C)) <><
CO 0 0
<, _
F- C)-Y i
-J LLJa -:
0 )
BC4
MR. JAMES O'BRYON
DIRECTOR
LIVE FIRE TESTING
DEFENSE RESEARCH & ENGINEERING
OFFICE OF THE SECRETARY OF DEFENSE
SIMULATION LN WEAPONS DESIGN: A NEED FORDEFENSE-WIDE SIMULATION STANDARDS
SECOND WORKSHOP ON STANDARDS
FOR
INTEROPERABILITY OF DEFENSE SIMULATIONS
KEYNOTE SPEAKER
HYATT CONFERENCE CENTER
ORLANDO, FLORIDA
16 JANUARY 1990
B-45
0U) m z W -W0 lWl 0 wl m 0) 0 oW0 UJ Z - U)
- -w L z w 0LL - wL 0 C
Lu-CC u ) n >. 0 o: I
H0 UJ UDw - 0- 0
~~~ W H ~O
p < wJ J C< W
ui CL~ 0 > Z UF)W ) LU. H
0 U : -Uo. >. ow U <O
w oJ <Hc 0 CL 0j
Li . LU 0 l3z X X z am
F- F- 0 0
-J z < cc <z 0. 0> LL <H/
F- H- H- L -o z LL. M O Z - -
U-0< 00 0F I--J >
C) x H < 0 c 0<Hi HO J C/
LL Z W 0< -W WU Wz
Fn 00 0 0<
HZUB-46
0
c'J
(IC)
CL'
0)) 0C
0
EEU. ~~a E L)C-5=)
cu m
(0 0
U o Cz a
CD 6c)
C) ~ ~ ~ ~ ~ - 7-m 4 m S
a)) ci
.
,0-
F (_
00
C) >,. a) c
000) -0C
0COj
0)/
00_j--
L~j < Lt
0 -j D )
LM :F I-- 8
0~
00
C)0 1
0 0
E cng ~ -0o E =e',j (t< 0
0
CL Ci~ C) CZa(na
_0) C . . C 0 " Co * 4*
0) 2 )
L) .2 CZC CCUo1 co C.
3'. LL 2.
~~Z) -c
Cw w- >)~
-> - I
co cm0 0
zz (M )w r
00 a -0 C l
004 DQ S4") 6 6 --O*M) np -C c
" m V -E c = v)%S cu cn Q)
-a) ~ ~ -6,9 b L
00
Mz zwLaC
z - I
u-0
H ~ Cl) uj
U- U-
000
0-z F-
U)f U
B-50
0 wL
LL. wL(cc wL cn m Fo H- H- Uj HLL C Z F-J
MJ > U) U)w F CC 0cn
LIJ M (50 0>~ Ow%*
o- <J CC HL 0
w ~ 0 L 0 V , )OsUZ J . N W >- Z wL nC 1
U) Hn H- z-C j L
CoO z(n z- < w C- a <LL
of 0~ 0 zJo j U) ZO WOZOL 0L
Wj HJ H Z an > Cn z < LL uo0 0 z 'm Z< J w zS000 0 0o <
<~ Z Z 0- 4L h. L f
~ ~~ . HF- < M <0 0 0 0 0) 0 0 0 0 0
B-51
c0n-
j o Z ZF
CC - < L
w ZD
uj C)
0
B-52
LU0
ui 5MC)Z -j zw 0z 0
0 00xJm m _) C )
L Z LJ H C-J Cl
00 0
(nI F 0 L0~ H 0 Z W0
zz r
F/ - < z i0< Wi C) z w: u HW - ;Z U L F O COzJ CHa-HH < 0
0 - M - C W< a J HLL LL CL ) H J <- W 3 U
B-53
w0'
Vu
0 0
0-
ujw
0-
LI
<I CL)
-zI- WZ
cn
2 1
wU w
I I 0
B- 54
(I)Uw
c,)n
co0n zU WC CC
Q.J U- <jJW U
w/ <0z z 0
LL LLw- 0 L
0 > L1 C)
0 w L
WW 0-II- L im C,
o00
)~B 5-5
- (90
H>- Z
cZ CoZO Co5j0C 0
- 2 F- 0
wU 0 Z 0CC. cc0F-
L . Co)ZLo 0 HZ)LL ~LL C
U.~ z
<HF-H(5H 0
H C/)I wn L
0-l 0-cc6 0 S 0
F- 0
-5
z
w0Cl)
ow p-
LL0 0
COO =w: ; i- Q -
0Ow m l)
(J)LL D l
0
B- 57
0)0%
0) a
L- N
a' 0
O(1) 0
< 0LU C-,
U) NL 0
LU U - i
0 a
>C-LUJ
I--
a)
B-59
DARPA SIMULATION PROGRAM STATUS
OUTLINE
SIMNET TRANSITION
* SITE SCHEDULE (Chart)* ECP/ECO MODS
•SAF 3.XVERSION 6.0 S/W
AIRNET
* RUCKER, 31 JAN 90'o 8 GENERIC HELO & 2 CAS
SIMNET-D
* FAADS (Chart)* BFIT (Chart)
a ACMENET (Chart)* CVCC (Chart)
CONTRACTS
* CLS-PM TRADE* CCTT-PM TRADE
* ADST-DARPA/PM TRADE
B-60
00
LO >
'4-
00
C)
< 0 0
0 'aC
-o W
4- r- Um C 0 a : a 3: u
4- a -o we SL4j LL 4J4--) 0
Cfl>L
C it. m
cu
0)0
CU -
C4-)
0)0
00-u a)u1c0
C L aaD E2403w u0) aC L-
0,0
H0 p
ma'mB3-61
0X : U) U)
_ 0
L I-
E x 0C
L- U0 4-,
00 0 0 cC/)L
Ul) 0) 0 ~ 0 0 ()C0)) 4-0-- J
0LL 0 ) C. 3U) 20
C-)Qx) 0 0 U) cz C 0 E C
Fm. 0C 1-) > 0 0 o: -4-- Cl- 0-
cn < E xa) )J00Zn -0
0LL~1 C) >1c
U o 0 0 . C
E 0 E
E oo- cz(DB-)6=
wi wo ZoCf) 2
R 0 0>0F- U -- a> 0/
0)a a0 00
U. >
E FC1 0 .0 ~ -2 +j 0
C/G) Z CZ. C/)NE. Cl) 00 >=Q
c1 C0) C/0 -_-c 0 C: o-
c 0-0 cz l0
0) U)0) )
0 U& 0 0 <. Ca) Z x-'>1 0C) > 0H4
a (: Ci.Wca~c 0 ,
C,) 03 czU,
0L 0.
z~ > )
CL 0B->
04-a E0 0
Ez CZ 4--,C.) _ 0 c ClZ
0
CL.. +..
0z 0 _)
L- - * -
j'W0 z
WL o -c/) p E~
Z C) -:L) 0/ .0/)C/Wl C1 0LIC)Q
CO) 0c: -C )
0 C
0 00Z cKO COD-Ho00 2)N -- o--~ U)L L Q
0 -
W -, U) L- ()0. 0(
CZIM0 0 f 0 tn00 0~ %-C 0c 0
C: /)U)B460
0
CL
CL
02 CL
00 CLCL~
B-67
I0D
B-68
0I.
lezII
0,le
B-60
UPoo
B-70
-CN
(.) a 'em
u CL)
zUf)a
C/)
B- 71
cn(
0 00
o ED
0 0ZF
0 ~ 0
0 21oV
E
0 h0
B-72
000o C)
Cl)
44__ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
B-73
E00)%
Cl),
c*coa>
o0 r. Cl),
BOWS 0 0 ;
C4
0~ t 0 >
.0 0
00 C >0
- 74
CfU)
0 ) ftC'
0 CD
LUI (I)
z Cu _ Cl)
X x xu
I-C)-uj0
IB-7
0h
B-7
00
LM,
U'4-J
00
0
0 V
0)c 0 -C/ 0l 00 m <
w ) LIw 05
B -
Lh
0 Ul)
o C)0
zc>1)
co) Cf) I
B -81
00
C6C (CD
L0C.00
o a)
Co; a) l-
I.--82
CuC/
L.C) D coWoC 0c.
U.o LU 0LL L- LU Coi <L < 1
E0a
00
0Low
0
-84
C)CN
0
©-.... ... ........... .. .. ......C%
_ _ _ 'I-
CN
,, '3
© cc .ci- - 0 , '
B-85
0
0
LL.
m0as CO) CO 1- C/)
C?~7 L) o 0'7
U CZCac > La ) )C
LM < ~c
B-8
Lm E 0
0 0 C0
C: 0
< C00
!E c,)o 0C * -
0 )CZC 0C/0 E
o- 0i 0Z0 C
> n0)C) o )0 CD-
o C-8)
00
U-
00
C) co
B--
0 0
C:0cE _z
C: 0~0%
C)o: CD)
C _:
U-)
E *~ 0
B-89
cloo
00
.z
B-9
cz~
00
*C0-jc
B-91
C/),
00
.00
Co C
0z Ea)) 0
Co 0
E C:
0z 0
B-92
APPENDIX C
View Graphs and Documents for theNetwork Communications
Working Group Breakout Sessions
'CIO
C/0)
c(0
0C00
4-z
00
H- w
00
cc C-3
Cl)
00
Q)l
0 0E Q
U)) 0
I - -
£24 --
0 _l E>E cu
>2 C 0
:3 0 0co~ 0
co C ) 0 E Q )
4-j 0 :3- a:C) L l) £2
-00a) 2 0 o L,
0t - ' cuU L ;-a ) 0
) 00E4 00 CZ- C 4_ c)
0 CZ0 0£ EQ Q0 %z -+-- 0 Ci)
C/) LL 0 <''
a) a) ~ C-4
U_
0
E 0:
2
'4-
a) 0
o C:(D-0 1.
4-1-
E ) (\E C5 -o
(D C)
*e- ~:D
Q()C-5
COE0
000
E E4-j 0
4-, ~ 4Z
44-'-
.4O- 4wu
E 0z 0oQ0 1 0 I
C/) f.. L . 0 _ -
c0 Ci)
-o0_z Ci
_E. () _ (./) 0w ) :(=D a, U) -0-w C< 0 4--
0 C 0Q ) L0Cz0>CU0Q 00 "D ))> 0)
o~0 00 C))C) 0)
*) <
C- 6
0C)O
_000
-0
cc
0 0
CE 0'0Ec"0 0 0
00
03 E Z 0
0) .- ... 0 i.
-J C)
00
-oz E L)Q0> 0
CC3
E -7
o oO
oo
I.
cz
C- 7
Ea)
0
0 L.
00
Q) C) U).O-o
L- C
(15 0 15-I.
Eo "se' M N 4
Q) C: - -E
0 o0N0 p?~ CZ
-8
EEm4- 0 0z
00
41
Q) Co9- -0 0Y
> o a3coD 00 0 -0 4.J Qz()
0~~ +- _ 0C c)3Lz 0 V 0-ClQ ) CI)
CE5 _0>~ 0 0,a 04- 0
w_ Ci)
.0ai L
C-9)
4--0
czi
0) 'E 00o C
Cl, a)
cn CU) EEE
0 u
00
E CCNO2(CI) -*-- Cl0 c 1) _
C)0 C5 0 0') z _5
ocM~ 0
(90 0 a)- 0
U) ) Cf0 0 c _
0 n_ 0Cl u) W:- CD C) U)(1) '-3 cm w (30.0 0 L 02 0- (
Zo 0 Z Z/*z 00 E
(D cis
0-1
U))
.0~
-o CE 0 E
0o 00
Cl) 0#)0- C)cu
U) 0 00 EO;,E C
o0 CU) 0 co 0)
Co5 0 0L- () (1) C(1) ) 0 - 0
(0 0
_u cui r
cO. EEc
) 0 3 En0 --- - Q o CCo CD o
mi- 0v 00} 0o C
C LQL~ ~
X), :( - 0
W CO ~C011
fl 00z 0
0_
az co.
-a
4)Co z4 ~
E c c~
E~n .-- O
0 -0C E -
0~
-40 Q)C
0)CZ -
1.0c/
44-j
E 0-as -
-E I0
0' 0
U--
C15 12
00
E- (DE0E =3
cz 0 0 0I-' Q)I) (
C) 0 0D 0L0 CCD
0: IA.J C/
cI0Q)0 _
12 ) (D (I) -c z - U
0:E 4 6-0 E
hO L, COCU)0 0 3 c
'D1h. 0 CI D-
a) 00- 00 -IU)U :z
.- ct
a~ 0- ~0a.Na0 -
!E cz u C)ZC) - G) 4- C
U) 0 ~Ci 3-c
U)l 0T
Q) -
U) CIOI)
CZ- 04- U)jU
a0C/) 0 U) C 0-1- > a)C 00 _
U) U)
4 0 a) a) 0 -
~ N U)aE a)-~ 0Z 0z
E - E N: 0~OCZ C -0
Q) c0
CZ) ) =3 C%-w
0 59 oz
LtL~ ~ ~C)14
(D0< 0
00
~CU) CDm
0 0 0
0~ Oo:D1
LL U5 .w Hu z
<~u WJ uj 0
DI- 0. 0 w
M~ C) L)MU 0I- m 0 U.m
LU U
H 0 Ww<JL 0
0 -L0 ' 0
C-1
Long Haul Sub-Group
NINE ISSUES FOR FURTHER DISCUSSION
* Security
* Definition of present protocol and mapping toISO profile.
* Time stamping and latency
* Recommend ISO profile for SIMNET spec.,
evolution to FDDI/ISDN/etc.
* Additional service requirements driven byjoint service doctrinal guidance
* NIST, ITS/NTIA, university contributions tothe evolution
* Consideration of NATO
* C & I testing, and V &V of simulators
* Use of other network assets
* Database to house information and CM
C- 17
Martin Marietta
INTRODUCTION
Real Net was developed in the ALV progra to provide real-time autonomnous vehiclecontrol, sensor data processing, and amificial intelligence progi-arns with a high bandwidth,low latency inter-process communications capability based on a message passing padgin.
The ALY utilizes a real-tine distributed processing architecture featuring Symbolics,WARP, SUN, VICOM and Intel processors. Blending this mixture of heterogeneousprocessors into a real-timne vehicle control system presents a unique set ofnetworkcing/communications requirements including:
*Fixed Time, Low Latency Data Transer*High Bandwidth*Heterogeneous Processor Integration
"-Loal and Distributed Processors and Processes*Flerible Process Allocation and Migration*Low Cost Integrion of New Machines*Point to Point & Selective, Broadcast of Messages*Simple Multi-Lingual Application Interface (LISP, PASCAL,'C', PLM-86)*Commercial-Protocol Compatibility*Flexible Transmission Media Almmnadves (Twin Axial Cable, Fiber Optic
Cable, Ti, 56 KBPS serial, Etherne, etc.)
These requirements are equally germane for a variety of applications including compulrrvision, robotics, rcal-time simulation, etc. Real Net is currently keing used on both theDARPA/,VMC ALV programn and the DARPA/MMC SMART Weapons prograrra
Martin Mariettac- 19
Martin Marietta
Real NetGeorge P. Celvi and Thomas J. Mowbray
Martin Mali=e(303) 977-0830
ABSTRACT
Real Net provides the software tools necessary to construct a distributed processingenvironment which acts as a single "Virtual Machine" for a real-time system. Tnc firstimplementation of Real Net is operational aboard the Autonomous Land Vehicle and withinits Laboratory. Real Net employs an 80 megabit/sec token ring local area network as thefoundatinn for integriting Vioom Digiti. lmat Piumesors, .SUIN-3i%60 workstations,intel 80X86 piocessors, and Symbolics Lisp Machines into a single asynchronous real-time network,
Real Net enables application processes, currently C/UNiX, PLM-86/IRMX, Lisp, andPascal,/Versados to exchange memory objects with other apolication processes locatedanywhere on the distributed local ring network, or on any qateway accessible network.Memory to memory transfers are implemented across the LA to implemnt th-.- addressmethodologies:
• Point to Point (process A- to process B)o Group (process A to processes B, C, D, X. Z, etc.)• Broadcast (procss A to every other process)
Communications processes may reside within the saine processor (intra-processcommunications) 'or on any network accessible host processor (inter-processorcommunications). A single object exchange request may be targeted for any collection ofdistributed Drocesser which reside on the originator's host, or on any cllection of networkaccessible hosts. The-routing of data and delivery occur in a tiansparent manner withrespect to the sending process.
Internet Protocol (IP) dataFram serAces ure providt4 !k Olow network to network dataroudng and intemet addressing. This facility provides for f-at& '.,,- ..d massembly ofdata strep'ms to/from data packets. Adherence to IP packet f*::at, addressing, andprotocol ensures compatibility with commercial gateways and corainn=ications devices.
C-20
Martin Marietts
DETAILED DESCRIPTION
Real Net is a set of communications software 2.i ,ed for a variety of processingarchltectures. It is intended to implement a "Vr essing architec usinga collection of non-homoqeneous-process.s., "4; .' V L "-rual Machine" configu,-ationis file driven and is established at LAN (LXca A-a -. -r-up. Once establishez it maybe selectively modifed Real-Thme (milliseconds).
A complete software specification including module :.xm'tves, data dictionary, and modulepseudo code and logic charts are available through %: Autonomous Land Vehicle (ALV)project. This desciption is a summarized extract . r . docu."tzentation.
VIRTUAL MACHINE CONCEPT
Under the "Virtual Machine" concept, a rea'- ,ne run cycle may be construed as a multi-player game. The players of the game are software processes or tasks, which may resideanywhere on the playing field. The playing field is an absacdon, which may be construedas the total collection of host processors. All play=s may be excuting on the sameprocessor, or be distibuted across a collection of procestrs located on the same networkor on adjacent networks inter-connected by IP gateway devices. The playing field isvariable in nature and may be redefined at any time. An initial- "game" conxfiguration isestablished at sumv-up but may' be modified real-time to add/delete players, or cxp~uid/shrirkthe field of play by re-allocating players to different p "ocessors.
As with any game, certain rules govern the interaction of players on the field of play.These rules exist under the "Virtual I-.%r-hine" concept, and are manifested in the definitionof interfaces between players (process. 4), The interfaces between processes are delineatedin terms of data items (item M#, type, source player, destination players) stored in anInterface Control Document (ICD) file. This file defines the data objects which mayoriginate or terminate at any process. Processes are-mapped onto physical hardware unitswithin the "Virtual Machine" via a Player Host File (player and L/hardware addresses).When processes wish to exchange data items across networks, packets are automaticallyrouted through IP' gateway devices across network boundaries. Paths inter-connectingnetworks are stored in the Gateway- Routing Table (1P to IP address routes).
Under the rules of play, any process may originate a data item for transfer with noknowledge of the actual destination. Real Net will automatically route the data to the properdtstination(s) whether within the same machine, on the same network, or across networksin response to a single application transfer request. Data will automatically be formatted forreceipt at the target ncde(s), (resolving byte swap/word swap contingencies) with non-redundant delivery to one or more process at each node, as defined in the-configurationfiles.
This provides a robust framework for integrating processes into a rea-timfc "'ViitualMachine" environment, Watch dog timers, network management, data recording, andother real-time functions may be added or deleted as necessary by expanding the game toinclude new processes. Since the "Virtual Machine" may be expanded or contracted in real-time, redundant/exception processes may exist in a dormant state and become active as
Martin Marietta
C- 21
Martin Marietta
needed in resonse to conditions deteced by watch dog tirn:, network manaFenent, ordata recording Functions.
he actual tiansfer of objects between proce5eds appears as continuous DMA operationsacross the LAN, with a consistent process interface methodology implemented in theapplications' language, ad resident within the host processor'2 operating systvnframewark (non-operating system implementatdons vre alsosuppormd).
MEMORY RE"'OURCeS
Real Net uses a shared mernory pool for exchanging data to/from applicatior. processes,and for buffering input/output LAN traffic. The resource pool is used for r.;oCation ofstorage for several critical data structures. These structures and their functns axe asfollows:
Input Transaction Assignment Queue - records arrival of data from LAN andcoordinates delivery to target players.
* Output Transaction Ass gnment Queue -- records requests for transfer of dataitems and coordinaesprioritdzed IP datag rn se.r.vice. ContaLas pointer to copyof data item awalting-rasfer.
• Routing Table .. storas requir-d IP and hardware addresses for each item outputby the Individual nod, (Eynthesis of ICD, Player/ost and Gateway Files).
• Input Network Status Log .. contains councers which keep track of iabog-ndLAtN raffic and !tem deUveries (displayed at end of run).
• Output Nezwor' Status Log -- contains counters which record outbound LANtr-ffic and packet refusals/failure (displayed at *nd of run).
, Tnput/Output Buffers - storage areas for data items awaiting delivery to players.
, Poinr f Re-ference Table -- points to Real Net data sructurs (for reference bymul le oft.are layers),
SUPPORTED DATA CLASSES
Two classes of data items are supported under Real-Net:
SRefros data items* Multiple occurrne data itzms
Refresh data items are overwritten whenever a packet artves from the LAN containing datafor that item ID#. Bufferin$ and handshaking prevents inadvertent overwriing of a refreshd ata item O put buffer, while data is being delivered to a target player. On output, anypendig trapsfer for a refresh data item is overvvritten by a-new transfer request. The newdata (for the Old item) retains its place in the prioritized Output Network Assignment
Martin Marietta
C-22
Martin Marletta
Queue. The output item ov-rwitten is recorded in the Output Network Status Log fordisplay upon completion of the real-time run cycle. The number of output buffers allocatedfor a refresh item is two. The number of input buffers allocated for a refresh data item isthe number of target processes within the local host (for the item) plus one.
Multiple occurrence data items are allocated a st;' of revolving buffers. The number ofbuffers is determined by the configuration manager znd storcd in the ICD file. Multipleoccurrence dam item input buffers are recycled following delivery of the item to all targetprocesses within the local host. If all input buffers am full when a new packet containingthe data item arrives thcn the oldest non-busy buffer is recycled, and the over-writerwcorde in the Input Network Status Log.
On output attempts, successive entries are made in the Output Transaction AssignmentQueue for multiple occurrence data items. However, whei all available output buffers arefull, failure sta:us will be retuned to the appi:cation process, and the failure is recorded inthe Output Network Status Log for subsequai! displrv.
Any data type may be defined within a data cls s. Examples of valid data items include:
* ASCII data• Bytes* Words
Long words•Reals* Arrays* Records
Complex data structures
No size limitation is imposed on data items. A special class o data type, Files, areimplemented using file buffers to preven: memory overflows. All other data objects fortrmsfer must be sized so as to fit in available memory.
SOFTWARE
Real Net provides a consistent applioation intrface for inter-processor (across the LAN)and inicr-process (.oca host) co]mmunications. The software architecture is comprised ofthree ral- =e layers:
* Application Interface (F)Data Transport Executive
*LNIF
A fourth major software component, which Is not directly involved in the real-time transferof data, is initdaIzation. Real Ne:'s processing architecture and a functional summary ofthe rrjor software components are surmarized in Figure .
Martin Marietta
C- 23
Martin Marietta
INITIALIZATION
The initialization software provides thrue functional capabilities:
* Configuration Manager" LAN Start-up- Run-time Inizialization (functioning as Inifiaiza-ion Master of Initialization
Slave)
Four disk files control the configuration of the "Virtual Machine" for a real-time run:
" Interface Control Document File -- defines, for each data item,
- item specifics such as size, item priority, etc.- Player (process) sending item
" PlayerfHost File .- defines whdch machine, (via IP address) in the network eachplayer resides
" Gateway File -. defines all gateway addresses and routing information allowingany network ring to access any other ring.
* Destination Player File -- defines Player(s) receiving each data item.
These files are main ined by an operator using the Configuraion Manager Software on aSUN-3 workstaton. (swe Figures 2 and 3). The operator then loads one each of these filesinto a shared memory region using the LAN Start-up software (start up mode). The Run-time Initialization sends to all other nodes in the network, node-specific subsets of the fourconfiguration files.
The Run-time Initialization software (slave mode) following reception of the node.specificsubset configuration file performs the following:
a builds the local muting table
o allocates storage for and initializes locally required input/output buffers
* allocates storage for and initializes the input/output transaction assignmentqueues
• allocates storage for and initializes the network traffic status logs (input andoutput)
• sets up pointer reference table pointers for use by Application IF and DataTransport Executive software in accessing all buffers and queues
Martin Marietta
C-24
Martin Marietta
* Verifies communications with target nodes in routing table via Comm Chcckmessages
* Sets the node Real Net mode to real time run mode
The Initalization software (functioning as initialization master) after broadcasting theconfiguration file subsets to all initialization slaves, also performs the above steps.Successful master/slave initialization is verified through the exchange of a test patternpacket, using the Application Interface Send and Receive calls.
When the network is to be re-configured, (Run-time initialization mode) the operatorsimply loads a new set of configuration files using the LAN Start-up software. The newconfiguration is compared to the current configuration and all affected nods are sent aninitializatdon request. The interrupt handlers on the affected nodes (run-time) change themode back to Run-Time initialization and invoke the Run-time Initialization software,(functioning again as initialization slaves). Applications attempting datatransmission/reception on the affected nodes receive wait status until re-initialization iscomplete. Upon reception of the new mode.specific configuration files at the attachednodes new data structures are created input/output buffers are flushed, and initializationprocessing is verified. The mode is then reset to run mode.
APPLICATION IF
Real Net provides three function calls (accessed as library routines, etc.) which areimplemented in C, Pascal, PLM-86, and Lisp. These function calls are:
* Send (data pointer, item#, status pointer, byte count)
, ecPdve (data pointer, item#, byte count, player identifier, status pointer)
* Status (entry#, item#, query type, Input/output, player identifier)
SE-
Send enables an a plication to request transfer of a data item to another process or group ofprocesses. The destination is not known to the sending process. Parameters furnishedwith the send call define the transfer request to be implemented. The send call verifies thedestination host address of the target process(Es) from the routing table. If any targetprocess is resident within the sender's local machine, then Send calls Inter-MemoryTransfer to copy the data into an appropriate shared memory input buffer for delivery to thetarget process(Es).
If any tarfet process is located on an external host machine, then the transfer request isrecorded in the Output Transaction Assignment Queue for Implementation by the DataTransport Executive. The configuration files contain priority indicators for both itempriority and player priority. A cumulative priority is assigned to each-pending transactionin the output Transaction Assignment Queue. This cumulative priority determines therelative sequence of transfer assignments which the Data Transport Executive will enforce.
Martin Marietta
C-25
A send cal'. retur- the Output Transaction Assignment Qucue entry numbe.r whensuclcessfull W~hen unsuccessfu! a negative. number is-returned indicating the nature of dizfailurt: (i.e., item.' not fo und in routing table, output buffr-01S 0i full, etc.)
A Receive call forces delivery of an input buffer item to a requesting process, when theitemr in question. has not be.'i previously delivered to the requesting player. Delivery masksarm user, to orchestrate non-redundlant delivery of data to individual p layers. Mask valuesfor each receiving player are computed at Run Time Initialization. Up on transfer offa dataitem~r and storage in an input buffer for delivery to target players, the delivery mask is
cped into- the Input Transaction Assignment Queue record, pointing at the input buffer.UOn request for the item by a player, the 1iput Transaction Assignment Queue recorddelivery' mask is compared With the player s-delivery mask. If the item has not beenpreviously delivered to the requesting player, then th-. data is delivered and the InPut-Transaction Assignment Queue -record's delivery mask is decreinented by tie player'smask. This prevents redundant delivery of data to the same player.
When no dzt!iis pendih'- delivemryfor a player' and fiew.ID#, cornbination, a failure status i5return ed. O-Jrzrwis-., suczssfui status is returned and the byte, count field is set to the sizOof the dama objer.: in bytes, and a local Copy of the data buffer is provided to the requestingplaycer.
Whcrn no data is pending delivery for a player and iten MD# combination, a failure status-isreturned. Other-wise, successful status is returned and the byte count field is set to the si.zeof the data object in bytes, and a local copy of the data buffer is provided to the requestingplayer.
Mir's
The application process may request status on pending item deliveries, or on requestedtransfer requests. Status requests are made for either input or output queue status asdisdnir. Ecalls.
When input status is requested for n item number, the call will return as the status value-the number of input buffers pending delivery for dhe player/itemn ID 9, combination. Zerois returned when no items ame pending delivery. The application may subsequently requestreceipt of dat. items until the Indicated amount of deliveries have been made.
Output status may be requested in two ways: by item ID# or by entry number (as returnedin the send call). If output stws is requested by item IDV the n the status field is set to thenumbcr of transactions in the Ouwt, Transaction Assignment Queue (priority sequenced)and implement all pending transfir requests. When implemented as, a server process, theDTE continuously scans the OuTut Transaction Assigniment Queue aund processes transferrequests as they are recorded by other processes. The DTE server checks for higherpriority transfer requests after every packet is ori inated. Higher priority packet requ.-stsare therefore interleaved with lower pri~ority rrans.er requests, NWhn a pnrity-level (0-2
Martin Marietta
C- 26
Martin Marietta
for items, 0-2 for players, cumulative 0-4) transfer requests arevprocessed on a FIFObases. The DTE software is impiemented on a separate SBC for Intel Multibusapplications, similar implementations could be made available for other shared busimplemntations (VNM, VESABUS, etc.).
The DTE provides the following processing functions for each requested outputtransaction:
" Prioritized servcing off transfer requests from multiple processes
" Protocol enforcment for Pronet, IP, and application protools including: checksum generation, packet strulmure deffinition and header construction
*Control of gather DMA operations to assemble output packets inthe L TAN
hardware-IF boar,.d set trasimi.t bufffer
" Control off packet tr-ansfer via LAON IF libry calls
"Display of network status log datm (input and output) at the completion of a real-tim raun cycle
Run Timet initialization Processing:
The DTE suspends scanning of the, Output Transaction Assignment Queue during RunTime Initialization, and resume active processing when the nodes Real Net mnode is reset toreJl cime run. mod..
LAN IF
The LAN IF routines provide an interface library to invoke LAN hardware IF funictionsfrom high levelI application languages. Speciffic functions enabled includ-e:
Hardware Checkout:
* analog and digital loop back testing
*Irx/Out DMA: Routines for using the on board prgrammable DMNA controllerfor moving data to and fromn the- Prone! 80 boards buffers.
*Packet Origination: Routines for introduction of a packet stored in the ProncE80 bazrds transmiz buffer onto the: LAN for delivery at another node, outputmrffic Is recorded in the_ Chput Network Status Log.
*Packet Status: Routines for verifying acceptance or refusal of an originatedpacket by a target noda.
Itrrmpt Handler: Inbound packets cre copied from the LAN and pre-scan-nedby the intemrpt handler as to contents. For; data item 0 (administrative packets
Martin Marietta
C-27
Martin Mariets.
containing commands) approptiate responses are generated- and transmitted tothe Configuration Manager,
For real-time data transfers the address of an available input buffer for the itemis determined, and the data contents of the packet are copied into the data bufferusing the in DMA routine. The receipt is recorded in the Input TransactionAssignment Queue for delivery to the target. player, counters in the InputNetwork Status Log are updated. When the packet received is inappropriate(not item 0 and not an item targeted for this node) the data portion is copied intoa "Junk" buffer.
Run T=e Initialization Processing:
The interrupt handler is always active and provides routines for handling data item 0packets. The.= roudnes enable down load and storage of the configuration files, as well asresponses to Comm Check messages and other required handshake acknowledgements.When real-time data items am received during Run Time Initialization they are copied intothe "junk" buffer.
HARDWARE
The hardware requirements to implement a Real Not system are flexible, and allow fo:mixed t,.dia LANs with disparate bandwidth communications links. Minimal hardwarerequirements include: (non-real time LANS (i.e., Ethernet) can also be integrated into aReal Net system assuming non-deterministic timing attributes'can be tolerated).
(1) A non-contentious/deterministic serial/parallel bus system between nodes ofthe Real Net where:
a) distance between nodes can be > 50 ft.b) # nodes can be > 25C) data rate can b, > 10 megabytes/second
(2) The ability to IT to multiple local bus types, i.e.,
a) UNTBUS/QBUSb) VME busc) Multi busd) Vesabus, etc.
(3) The local bus interfaces have the ability to do DMA in/out of the local busmemory, and that control of the DMA is available directly by'Real Netsoftware drivers, i.e., there are not multiple layers of software between theReal Net software and the actual data movement hardware.
(4) All I/O operations to the local bus/Real Net bus have the ability to beinterrupt driven.
Martin MariettaC- 28
Martin Marietta
The current imolementation of Real Net uses Proteon Inc. Pronet 80 hardware. Thishardware provides interface board, sets for VME Bus, Q Bus, Unibus, PC, Bus Muldbus,and with appropriate adapter boards, virtually all commercial bus architectures, The LANitself is a fault tolerant 80 megabit token ring.Transmission media operations include: (slower data rates may be required for somemedia, but software is not impacted)
0 Piber OpticQ IBM Twinax# Microwave$ Coaxial Cable RF (TI and 56 KBPS serial interfaces)
Each host interface board set provides access to the LAN -for packet origination andreception. An on-board programmable DMA controller chip provides the means forperforming scatter/gather operations, Gather operations are used to strip header data frominbound packets, and copy data segments into appropriate input buffers for subsequentdelivery.
Commercial gateways provide IP routing serices beteen Pronet token ring networks andother commercial IP Networks.
Martin Marietta
C-29
SIMNET LONG HAUL NETWORK (LHN) OVERVIEW
Combat units at geographically dispersed SIMNET sites.can participate in real-time large scale tactical exercises when their respective local area networks(LANs) are connected by a long haul network (LHN). LHN links can be land linesor satellite hook-ups. Each LAi 1 has a small gateway computer that communi-cates with all the other gateways on the LHN. The LHN links and the gatewaysconnect the LANs in a manner that is transparent to the combat vehicle simula-tors, thus making the simulation a single network which requires no change to theSIMNET Protocol.
Distributed Simulation Requirements that all other gateways get all thefor the LHN network information needed by all
the LANs.The basic LEN requirements are the sameas those for the LAIN - high bandwidth, 0 To handle the increased data trafficProtocol Data Unit (PDU) multicasting, from so many.simulators broadcast-negligible delay and variability of eelay - ing over greater distances, the LM-Nbut the increased data traffic over the uses data compression algorithmsgreater distances of the LHN creates some that maximize efficiency of channelspecial considerations: usage and cut down on delay time.
U Bandwidth costs over long distances SIMET LHN Configurationare expensive. On a typical LHN, a local gateway com-
0 While the LAN uses commercial puter communicates through dedicatedoff-the-shelf components, the LIN data lines to all of the remote gatewayis largely a custom-designed net- computers. These, in turn, redistributework. Modifying existing networks the information to the internal LANs viaproved extremely expensive, either in the S34NET Protocol.development or fielding costs. The SIMNET LHN currently uses the
U LJ{N voice communication is han- BBN Butterfly TM parallel processor as itsdied as digitized voice packets gateway computer. The Butterfly pro-through the gateways in place of the vides maximum compatability and code
simple radio network used with the sharing of digital interface signalirngLAN. code, and its parallel nature allows easy
upgrade if gateway or network require-O Land lines are an inherently point- ments increase. Current Butterfly gate-
to-point broadcast medium. While way capacity is 500 vehicles and ninethe LAN suppors direct multicasting land phone lines.between simulators, the LHN must Butterfly is a trademark of Bolt Beranek and New-rely on each gateway to make sure man inc.
1/9/90 BBN Systems & Technologies Corp.
C-31
The current LI-N land link is an AT&T hibitive, the SIMNET L-NT can use highsingle dial-up 56 kilobits/sec phone line bandwidth dedicated satellite channels.supporting 100 vehicles each way. Thisis cost effective since the long distance Conclusionportion of the link is engaged only when a Regardless of the distance between them,connection is made, much like a tele- combat units are now undergoing real-phone. Vehicle capacity increases as time combined arms tactical taining onmore lines are added. Higher bandwidth the same simulated battlefield. The SIM-lines are also available, such as Ti lines NET LRN has advanced in broadcastoperating at 1.544 megabits/sec. routing, in reduction of bandwidth re-
quirements by data compression, and inLand lines are proven to.be reliable and reducing delay through the simulationmaintainable, and they do not suffer from network. These advances mean thatsatellite transmission delay. The advent widely dispersed LANs of combat vehicleof fiber optics means land lines will be- simulators now operate as if they were-acome cheaper and more secure. As land single network. This total training ap-lines become even more efficient, trans- proach does away with the expense ofmission capacity will increase, moving large numbers of men and equip-
ment, yet provides practice in the war-For remote sites, mobile sites, or in situ- fighting skills that up until now couldations where the cost of land lines is pro- only be acheived through actual battle.
© 1989 BBN Systems & Technologies Corp.. All rights reserved.
C-32
TERRESTRIAL WIDEBAND NETWORK (TWBnet) OVERVIEW
The Terrestrial Wideband Network (TWBnet) is a Defense Advanced ResearchProjects Agency (DARPA) - sponsored program that provides cost-effective highbandwidth packet switching betweet various sites throughout the continentalUnited States. The TWBnet also prc ,ides multicasting service (delivering thesame message to multiple receivers), which makes it appropriate for DistributedSimulation applications such as SIMNET. As a result, the TWBnet will be thelong haul network for the March 1990 WARE' exercise, an advanced SIMNETexercise involving 800 simulated combat vehicles communicating in real time.
TWBnet History Spring of 1989, and became the Terres-The Terrestrial Wideband Network trial Wideband Network.evolved out of the Wideband Network, How does the TWBnet work?which started in the late 1970's as a high-speed, satellite-based packet switch net- The TWBnet uses a backbone ofwork. The Wideband Network was the Wideband Packet Switches- (WPS) con-first high-bandwidth network to provide nected by 1.5 megabits/sec. T1 terrestrialtime--division multiple-access (TDMA) lines. Each WPS has one or sever'al gate-service to multiple senders and receivers. ways connected to it, with the gatewaysThe broadcast nature of the satellite links located with the WPS or by other terres-was used to provide multicasting service, trial lines. The gateways are connected
both to hosts and local area networks.The Wideband Network went through The WPS are currently Butterflym paral-several evolutionary changes - new and lel processors, and take traffic from theirfaster parallel processing hardware for the gateways and place it on the T1 back-packet switches, new protocols to provide bone. Time on the backbone is dividedfaster, more reliable and efficient commu- into frames, much like a train is dividednications, and network management sys- into boxcars. Each frame, or box car, istems to provide a more robust network. dedicated to one WPS according to theMany research applications took advan- competing needs of all of the WPS. Atage of the services provided by the sophisticated algorithm for frame reserva-Wideband Network, particularly those tions prevents the collision of frames.needing multicasting or time-sensitive Since the TI lines are full duplex, one sethigh bandwidth delivery: packet speech, of frames runs one way through the back-video and multi-media conferencing, and bone and another independent set runswork with new algorithms for file transfer the other way. In this way, all informa-and interactive computer sessions. ton sent by one WPS gets to all othersAfter more than a decade of service, the without having store-and-forward delays.Wideband Network was transitioned to Butterfly is a trademark of Bolt Beranek and New-use dedicated terrestrial T1 lines in the man Inc.
119/90 BBN Systems & Technologies Corp.
C-33
Requests for bandwidth are done with the directly to the SIM2vNET Etherner. TheStream Transport (ST) protocol. The ST ST gateway will also provide standardprotocol provides the concept of a virtual DoD Internet Protocol service (which al-multicast circuit, allowing the W'PS to re- lows Telnet, FTP, etc.) to each site. Theserve frames in advance for the data. ST gateway will be reading the SIMNETTherefore, with ST there is no delay .while Protocol packets from the local Ether-waiting for the frame reservation process. nets-m, adding an appropriate ST header,
Network monitoring tak~es place both over and handing them to the WPS for trans-mission over the TWBnet.
the TW'Bnet and through the Internet,with the Network Operations Center The sites participating in WAREX 3/90(NOC) located in Cambridge, MA. are Ft. Leavenworth, KS, Ft. Knox, KY,
Ft. Rucker, AL, and SMN'ET-Washing-How is SIMNET using the TWBnet for ton. Developers will be observing fromWAREX 3190? Cambridge, MA. Most of the traffic will
WAREX 3/90 is a multiple-site advanced be coming from the three Forts, with alldistributed simulation exercise. Up to traffic being carried to all sites.800 vehicles (manned simulators and hu-man controlled, computer-generated op-posing forces) will participate at four sites The Terrestrial Wideband Network is anin the continental United States. Up to 12 effective multiple-user carrier. By pro-radio voice channels will be provided viding high-bandwidth, low-delay serv-over the network between the sites. The ice to many users, it lowers the cost tototal traffic for voice and simulation data each user. The effectiveness of its use foris expected to be near 1 megabit/sec. a demanding application wifl be shown by
WAREX 3/90, a SIMNET exercise withEach ST-MNET site participating inWAtEX 3/90 is being provided with an many vehicles operating in real time.
ST gateway which will provide service Ethernet is a-trademark of the Xerox Corporation.
© 1989 BBN Systems & Technologies Corp.. All rights reserved.
C-34
V0CL 0
ml-'
z CL
Cl)
00
co 00 L
o cocl2m0
oC
C-35
LONG HAUL SUBGROUP
David C. WoodThe Mitre Corporpation7525 Colshine DriveMcLean, VA 22102(703)-883-6394
George CelviMartin MariettaP. 0. Box 179Denver, CO 80120(303)977-9848
Steven BlumenthalBBN Systems and Technologies Corporation10 Moulton StreetCambridge, MA 02138(617)873-3197
Colonel Lee RansomHSD Brooks AFBTexas(512)536-3687
Bill RowanNaval Training Systems CenterCode 28112350 Research ParkwayOrlando, FL 32826(407) 380-4591
Ron WilliamsConcurrent Computer Corporation106 Apple StreetM.S. 356Tinton Falls, NJ 07724(201)758-7453
Howard WichanskyUSA CECOMAttn:AMSEL-RD-C3-ACLocal Area Communications DivisionFort Monmouth, NJ 07703
John RossUK (MOD)c/o SSC Ltd38 Quilp DriveChelmof-rdEsson+44-245-441948
Larry RedmondGT" Government SystemsSuite 16001 Tampa City CenterTampa, FL 33630-3277(813)229-5718
C-37
Michael LombardiUSA CECOMAttn: AMSEL-RD-SE-AINFt. Monmouth, NJ 07703(201)532-2029
Robert ThompsonARINC Research Corporation2551 Riva RoadAnnapolis, Maryland 21401
Larry KellerARINC Research Corporation2551 Riva RoadAnnapolis, Maryland 21401(301)266-4780
A]. KerecmanUSA CECOMAMSEL-RD-TCOFort Monmouth, NJ 07703(201)532-3608
Robert StevensETA Technologies5505 Moorehouse RoadSan Diego, CA 92121(619)546-7800
Robert AlgerFord Aerospace1660 Olympic Blvd., #301Walnut Creek, CA 94706
Art PopeBBN Systems and Technologies Corporation10 Moulton StreetCambridge, MA 02138(617)873-2931
Gene WiehagenPM TRADEAMCPM-TND-EC12350 Research ParkwayOrlando, FL 32826(407) 380-4357
Philip DanleyGrumman Aerospace1111 Stewart AvenueBethpage, NY(516)346-6067
C-38
Members of Time/Mission Critical Subgroup
Name, Mailing Address & Phone
J. Joseph Brann, IBM9500 Godwin Dr. 120/026Manassas, VA 22110703-367-2738
John R. Doner, Harris Corp.P.O. Box 91000, 5W/5823Melbourne, FL 32905407-725-3691
Matt Narotam, BurtekP.O. Box 1677Tulsa, OK 74101918-831-2319
Gary Kamsickas, Boeing494 Boeing Blvd., M/S JN-50Huntsville, AL 35824-6402205-461-2164
Hugh C. Romine, CAE-LinkP.O. Box 1237, M5904Binghamton, NY 13902-1237607-721-4993
Steven D. Swaine, McDonnell DouglasP.O. Box 516 Mailcode 0641614St. Louis, MO 63166314-233-2240
Robert Glasgow, IST/UCF12424 Research Pkwy., Suite 300Orlando, FL [email protected]
Jim Watson, Sparta, Inc.4901 Corporate Dr.Huntsville, AL 35805
Gerald Lavault, Thomson-CSFRue Des Malteurius 92222Bagneux FRANCE40840000
Bill Scheiker, USAFASD/ENETWPAFB, OH 45433
C-39
Ed Doughty, Harris Computer SystemsM.S. #1162101 West Cypress CreekFt. Lauderdale, FL 33309
Dennis McBride, DARPA ISTO1400 Wilson Blvd.Arlington, VA 22209202-694-4002
Robert Kloecker, (LTC) USAJoint Warfare CenterHurlburt Fld., FL 32544-5001904-884-6928
Eric T. Hoierman, Hughes Simulation Systems13775 McLearen RoadHerndon, VA 22071703-481-4676
Bernard E. Griffiths, USAFASD/YWEEWPAFB, OH 45433-GJ03
Barry W. Webb, Lockheed Aeronautical Systems86 South Cobb DriveMarietta, GA 30063-0670404-494-6952
Grayton T. Figart, SYSCON CorporationP.O. Box 1480Dahlgren, VA 22448
Gary L. Teper, Information Spectrum, Inc5107 Leesburg PikeFalls Church, VA 22041
Warren Richeson, Combat Simulation & Sys. IntegrationMcDonnell Douglas Helecoptor5000 E. McDowell Rd.Mesa, AZ 85205
Howard Wichansky, US Army CECOMATTN: AMSEL-RD-C3-ACLocal Area Communications DivisionFort Monmouth, NJ 07703
Phillip Yoo, Digital Equipment Corp.4 Results Way MR04-2/C18Marlborough, MA 01752508-467-4437
C-40
Barry Tahlor, Concurrent Computer Corp.1895 Whalt Whitman Rd.Melville, NY 11747
Richard Schaffer, BBN STC33 Moulton St.Cambridge, MA 02136617-873-3317
David Lawson, McDonnell Douglas HelicopterMS 341/C2403000 E. McDowellMesa, AZ 85205
Gary R. George, CAE-LinkMS 655Binghamton, NY 13902-1237
Mel Saiz, Harris GSSD12249 Science Dr.Orlando, FL 32826
Michael Kamrowski, Human Resources Lab.HRL/OTAWilliams AFB, AZ 85240602-988-6561
Dave Powell, McDonnell DouglasP.O. Box 516MS 064 1461St. Louis, MO 63166314-233-8964
I
C-41
APPENDIX D
View Graphs and Documents for theTerrain Databases
Working Group Breakout Sessions
CYi)
0Y 00:momo
IQ)03
CL L-
n-3J
0
2 0
Lzc03
0~0
0D o 0
L2 0 7
0 >0
D-0
U)
E>1'<
CO ) Q)
<0 Ce
Ei 0C~)C-
0z 0 o Ce0
0 C)% )
00L. 0) .
D-5
D0
C,,D
C0 C/ 0
I-) a)) (IU
L..
cz C/)
-E E0 (D 0 0 0
0 0 U)
E ~ ~ ~ +w 0~U ~
0 +- > >1
c- N6 _0 E~~4-0; <
l) U)CZ
*' 0
Zo
D-6
-o
C.C)
o 0
G ce .5;)
0-~cez
U) 4-1 C
C:4-j i 4. 0 .(Z Cle E
00a.... 0)0 .? Q - 0 )
Ec z 0- >1CeU) 0)
CmL E) 4--a 0 C
C: C:
ci) r) c-
CL U) 0) 0l0 Q0 E
o Q 0)0
.- 4-
--
> 0 C
-
a)J00
ci) 04--1 U-co - 4-
cm)T 00
C4I
o ~ )4-- I -
ci
QC ) C U) c
a) c C co w )
CIO0 CZ0 0_~ co)
a) coaZ 4- '4- 4-4
L- c Me c
m 0~
L~i e 00 C/)
(3)~ 0 L- S
C/) E 0 Y0-8
cz,
CoL
Ui)C). ci) ci
(f) < 0
U () cc C)
Co)CD Co
ci)
0 4-~ C/)D- 0- 0
0) 0 0 ..
aC($ a) (n)
mmcz 0) a
cc -' a C /
_L c Z
D~~ C
0 .
1co c cz5 U0
CLE 'N
Ci) z
00
-
Q)l
D- 9
0E4-
C-))0z 0cin
0)Cl) Q) a
0 c
as -n a, E 04- a,
1.. '0
C) 0 4 L
00 *0
E E0 CD
mm~ C, I L.L.. L
D-10 I.
SECOND WORKSHOP ON STANDARDS FOR THEINTEROPERJBILITY OF DEFENSE SIMULATIONS
TERRAIN DATABASE WORKING GROUP
These notes augment the summary briefing charts presented in thefinal session of the Workshop on 17 January 1990 and address thespecific issues identified in the opening session.
1. COORDINATION WITH DM.A
Continuing coordination with the Defense Mapping Agency (DMA) onspecific product requirements is being handled by DOD ServiceLabs/Staff and/or Joint Offices. Area coverage requirements willbe handled primarily through Unified and Specified (U&S) Commands.
Terrain database issues in simulation networking requirecontinuing coordination between P2851, PM-TRADE, ETL, TRADOC TSMand DARPA.
2. INTERIM TERRAIN DATA ASSESSMENT/ITD
ETL is workina with PM-TRADE to investigate ITD related issues inconjunction with P2851 and SIMNET. Coordination among PM-TRADE,ETL, DARPA, P2851 will be necessary for ITD assessment, withadditional support from BBN, IST, and PRC.
3. PROJECT 2851 ECP ASSESSMENT/ITD
See lTD assessment/ITD (Item #2 above).
4. GEODETIC FRAME OF REFERENCE
The Working Group recommended adoption of the DMA World GeodeticSystem (WGS 84).
5. DEVELOPMENT OF CORRELATION PARAMETERS AND METRICS
See Subgroup Chairman Duncan Miller's viewgraphs.
D-11
-=e SUbg,_,Up Ch1airman Pichmrd Mzon 's veqa~s
~.INCREASE SIZE OF GAME -ILOARD
:1eWorking GrouDp reco:nended ,se geocentric Cartesian coordinatesnetwork nrotocc2. to suppo-)rt potenti&--11 global "gaming boards".
S :andard conversior, routines for soldier-machine in-erFaces to-ad-fror geographic coz.rdinntes and MGRS are needed with test datas.s -for validation teszino.
~.SPHE.RICAL EA.RTH MC'DEL (lat/Long)
TWorking Group reccmnedaotino gegaphic coor--nates(latitude/longitude/altitude) for standard Navy and AiJr Forcescoldier-machine interfaces and M2P.S- (UTM7P and UPS) for sadard.'Mr:ny soldier-machine intzerf aces.
Coo*rdinate systems transformation need to preserve relevant:~occaleffects of curved earth (finite distance to horizon) in
computer image generation.
9. DEFINITION OF SOLID MODELING TECHNIQUEWorking Group anticipates use of Project 2851 (P2851) solidmodeling techniques and libraries. P2851 has adopted accnstructive solid geometry (CSG) approach to build StandardSimulator Data Base (SSD3) models. SSDB CSG models aretransformed into polygonal models based upon target IG'sperformance capabilities and distributed in GTDB format.of thissoftware is ongoing; anticipate completion in early February 1990.Slimited number of tran s frmed models wiLl be Included within
GT-DB data sets to be distributed beqrinninc .4n April 1990.
10. DEFINITION OF TEXTURE REPRESENTATION
Project 2851 presently does not include a representation oftexture maps. Proposed engineering change (ECP) currently ineva=luation would add geospecific (photo) and generic texture map,re-resentations. Prcoosed caoabilties are to be fullyv integratedwithA'n the Project 2851 system in mid-19092. Distribution ofsample GTDB's with texture maps would be sched*uled for early 1992.
D-12
11. DISTRIBUTION FORMAT
Working Group recommended adoption of the Project 2851 GTDB as thefuture distribution format. Specification is available now. Twotypes of GTDB are supported: (1) gridded-terrain/vector culture;and (2) polygonal-terrain/vector or polygon culture. GriddedGTDB's are critical to suTport many existing CIG architectures aswell as semi-automated forces (SAF) and hard-copy/soft-copycartographic displays. Polygonal GTDB's are designed to maximizecorrelation between a family of existing and anticipatedheterogeneous CIG architectures. Sample GTDBs to be producedbeginning in April and distributed to ISWG.
12. DATABASE REPOSITORY ORGANIZATION
The Working Group recommended adoption of the proposed Project2851 repositorv at DMA Aerospace Center, St. Louis, MO. Initialoperational capability (IOC) is scheduled for May 1991. Theproposed P2851 facility is to be administered by DMA, managed by atri-service liaison board, and contractor-operated.
13. SEMI-AUTOMATED FORCES (Unmanned Vehicles)
See Sub-Group Chairman Dexter Flecher's viewgraphs.
23 January 1990 George E. Lukes, ChairmanTerrain Database Working Group
D-13
H HCo
> 0~
Clo>i H
o H
00
0o
D-15
N 0zH0
U
00
Pz H
10 0
pu 0 0)zH
E-f n 0U
9 W * %
0N 0
uH 9
N Z
z H 0
00-1
z
z
LiLD
00
CCA,
D-17
GEOCENTRIC COORDINATES
z
XG = (R + h)*COS S5IIXX
YG = R(P I Mccs -P Co *cX
D-18
LOC21~ RECTANGUJLAR COORINIATES
(CARTIES IAN)
0-1
+00(N N
40) 9 +
(N i +
4 1 + + I,4u rj qz 4 -
o -+ ~*~U) U'OC) 4G- U)cC- C'1 4-) ic -U) n c r-~ U4CY
QH 0 c/ Ul)+ L)0 + 0N 9 -
U)'K K U') L) U ZXm) M-5 Ker ) U 9- C)
U) +e H %'K + 0 +i '. H '
u '9-9- U') z '
C) H) +
+ +
H
z
0- 20
14Q 4
4J)
Cl) '4> $4
OJG))G)0 41
_ Y O - 4 $4$
En P4
+ +I +p0
v k 04-4-)
U H O A -i4+ -r 4-c)0 0 4
9- M U) to0) 4J)44
04 044 (() 0 (4+ + H) -q4
H 4I
CY) Y) ) ( 0 d 00
Ii II Y4r
4-)
D- 21
U-)L ')LC X ' X
l + + + rd +(N C14( + C,4 +
CN C(4 r- (N
>4 X >4
oq CdN4+ + + +
N N C1 k N w
0< 4< + +4 +
0+ + + >4 +
D-22<
D-2
r4 LO0
00 co4) LO'W rH 0 CC) 0
Z
- O Cd
Cl) Cd LO LO)
mv C, er) 0
U .~e~ 4) 0 0
L) rq 044 H
c'ILC) 0 H 0
C.)
N0 0
000
E I
D-24
o C) ) C
IX C) OD C
E-1 U))) U
ko mH
D-2
LNTEPIM TER ALN DATA (ITD) FACT SHEET
BACKGROUND
The A.-my, through the Engineer Topographic Laboratorics (USAETL), Digital Concepts and Analysis Center(DCAC), is committed to ensuring that Army's near-term requirements for a tacucal-le~el digital terrain analysisproduct are fulfilled by an acceptable means. During 1988, both USAETL and the Office of the Deputy Chiefof Staff for Intelligence (ODCSLNT), represented Army in discussions with the Defense Mapping Agency (DMA)to provide an interim terrain data (lTD) product to adequately and expediently service Army's near-termrequirements. Subsequenty, DMA committed to producing a volume of ITD to support the operationalrequirement of the Army's Digital Topographic Support System (DTSS). DMA delivered, to Army, draft InterimTerrain Data Prototype Product Specifications in Sep 88, and a prototype data set in Dec 88. The Armyevaluated their suggested approach in terms of the data sets' user-friendliness, and ease of production, andrecommended changes, some of which have already been implemented by DMA
DISCUSSION
During Oct 88, DCAC conducted an in-depth evaluation of the draft ITD product specifications with technicalsupport provided by in-house personnel and DCAC's engineering support services contractor, with commentsfurnished to DMA in a technical report As stated in the draft ITD prototype product specifications, DMAproposes building ITD data sets initially through software conversion of existing Terrain Analysis ProductionSystem (TAPS) data., then by digitizing hardcopy (analog) tactical,'planrurq terrain analysis data bases(T/PTADB's) and fimally by new product generation via the DMA Mk.85 Feature Extraction System (FE/S) usingdata collection software designed for terrain analysis. In December 1988 DMNIA delivered the first 1TD prototypedata set to the Army. DMA produced the prototype throk.gh a conversion of the six (6) 15' x 15' ceNs of DTDgenerated from the (now defunct. TAPS. The TAPS software conversion process included 1,oth data exchangeformat and coding scheme changes.
The majority of the ITD data sets will be produced from existing analog products and will consist of 6 (six)segregated files that represent the TIPTADB terrain feature data themes of surface configuration (slope), surfacedrainage, surface materials (soils), vegetation, transportation and obstacles. For all ITD data sets, terrain elevationdata is provided as DMA Digital Terrain Elevation Data DTED Level 1 (three arc-second data). The 1TDproduct data exchange format is DMA's Standard Linear Format (SLF) and the feature/attribute coding schemeis the DMA Feature File (DMAFF).
The current DMA production schedule for rTD calls for the production of 20 cells in FY89. These 20 cellsinclude 4 cells Fort Hood. Texas (U), I cell Middle East (C), I cell Korea (C), and 14 cells Europe/Germanv(C). DMA began producing these data in Jun 89. The Middle East cell will be a digitized PTADB (1150,000);the other 19 cells will be digitized TTADBs. Based on the current schedule, ITD production for the outyearswill likely be 150 cells (FY90), 180 cells (FY91), 252 cells (FY92), 300 cells (FY93), and 300 cells (FY94).Testing and evaluation of DMA's rTD production system commenced in Apr 89 with the generation of an initial(test) data cell over Germany.
DCAC is currently investigating other ITD and ITD-related issues including Army co-producibility of ITD, datastructure, format and coding scheme conversions, and quahty control software development. DCAC conducteda technical evaluation of the completed ID prototype data set. Participants in the evaluation process were theDTSS contractor and ETL Geographic Systems Laboratory personnel tnat are supporting the DTSS prigram.DCAC and GSL personnel will continue to monitor the ITD production program, DCAC also plans to evaluatea production.-quality ITD cel in the near future.
The points of contact for iTD within the Army are as follows:
ODCSLNT: MA Kurt Hovanec, commercial 202-695-5509, AUTOVON 225-5509USAETL: Mr. Francis Capece, commercial 202-355-2804, AUTOVON 345-2804
Date of last revision: 15 August 1989
D-27
zz.........
... 29.
U,)
0
ic:C
wjz p cEz
(5Z0
'Z 0
w) 0 0i -
-0
D3-30
C
I- za, 0w z-
H 0CL 0 ZCI
M 0w Cz
zU C/)
0 66 CLw L-m 0 <
cc-~J <HIwJ ccF- QFj HH
COH m C
D-31
z0
z < J0 0 M
CH W Z0l (D5
cow -J:0 > H
CLU
zzH 0
W 0).1-uj0 0
0 LU
o 0 jco cc0 0 oj
LL~ Lt HcE 0
0 0 0 C
D-32
+
-- crLI
<cl:0<CL <w w C)LL iOD~ LL OD
< < :DL-0 F
H 0cc 0
0 LL
I- I
II
0
LZ0
U) ~ COLiJ O
DL/ z cE>W&E uHC9H>ZE
0) WL
z~- CEZ Z Z =00~~ .0-C ww _i
O/) _wC Cc 0 Z0i
0~~~~ 0 < o5z F-o
C) o<
cr~D 0 0M
CQ < z < CL -
<1ccC/ 08Cw~j
0: 0
zC!) 0
al0 z
LUCL < LU(Doz <E CCC 2: cc 2: 0LI0 00 < C
0 U Z HH : - w 0 2:
_ LUJ :2gmJ : (o LJU Z ZHMU < 5wZ 0 CEH z> LU
0 D E Z _ 2
< CE 0 0/ <: CCE U 0 CE L
D- 35
4m
D-36
D-36
BBN Systems and Technologies CorporationA i.ar% o; bo ' BeraneK dnc \e%% "ian' n%,
Report No. 7140
TERRAIN REASONING IN THE SIMNET SEMI-AUTOMATEDFORCES SYSTEM
Tbn mz St -:zOn-
October 1989
Presented at the Geo'89 Symposium on Geographical Information Systems for Command zJ Ccatrol,SHAPE Techmical Centre, The Hague. The Netherlands, October 1989.
This research was performed by BBN Systems and Technologies Corporarion under coat3 i numberMDA9, 2.89-C.&600 to Darpa as part of DA.RPA's SLMNET project. The views and conclusions atained inthis document are those of the autbor and should not be interpreted as necessarily represeating ue officialpolicy, either expressed or implied, of DA.RPA, the US Army, or the US Government.
Prepared by:
BBN Systems and Techwn<ogies Corporation10 Moulton StreetCambridge, Massachusetts 02238
D-39
Copyright t 1989 BBN Systems and Technologies Corporation
IB\ Systems and Technologies Corporation Report 'o. -AU
Table of Contents
1. A ...... .......A...bs................................................ D-452. Instouction................................................ D-452. Introduction ........................................ ...................................................................................... D-45
3. Terrain Representation. .............. : ............................................................................................. D-47
3.1. Requirem ents .................................................................................................................. D-47
3.2. Diversified Quadtree Representa ion ............................................................................. D-48
3.3. Perform ance Study ............................................................................ .......... D-51
3.4. Q uadiree Search Algorithm s ......................................................................................... D-51
3.5. SAF Terrain Database ................................................................................................... D-55
I. Te.'rainPrcse-.= :ec ................................................................................................................... D-57
5. Terrain Reasoning .................................................................................................................... D-58
6. Extensions ............................................................................................................................... D-61
7. Conclusion ............................................................................................................................... D-61
S. Acknowledgm ents .................................................................................................... D-61
9. References ................................................................................................................................ D-62
D-41
Report No. 7140 BBN Systems and Technologies Corporation
List of Figures
Figure 1: Levels of Terrain Reasoning.................................................................. D-46
Fi cure 2: Terrain Polygons .............................................................................. D-48
Figure 3: Classical Quadtree............................................................................. D-49
Figture 4: Diversified Quadtree .......................................................................... D-50
Figure 5. Quadtree Memory Requiremens................................................ ............. D-52
Figure 6: Quadtree Leaf .Node Size on Drawing Time................................................. D-52
Fcw Qua&.re , !ndcy DutlicatiO . .................................................................. D-53
Figure 8: Quadtree Drawing Time....................................................................... D-53
Figure 9: Ouadtree Search Techniques.................................................................. D-54
Figure 10: Characteristics of SAP Terrain Databases ................................................. D-55
Figure 11: Network Data Structures ....................................................... .............. D-56
Figure- 12: Area Feature Data Structure .................................................................. D-57
Figure 13: Obstacle Avoidance........................................................................... -5
Figure 14:; Road Route Generation ....................................................................... D-60
Figure 15: Partial Route Generation...................................................................... D-61
D-43
BI;\ S.stems and Technologie, Corporation Report No. 7140
1. Abstract modification so that these dynamic terrain effects areincorporated into the terrain reasoning process.
Terrain reasoning is an important component of mihta:r.mission planning, and must be present in any combat An important component of the terrain reasoningsinuatior, in order to pro,idc rei.suc training. The system is the unit commander operating th,Semi-Automated Forces kSAF) system. xhich is a part workstation. A powerful soldier-machine interfaceof me DARPA SINDET program, is a realume, large allows the results of the terrain reasoning process t, bescale, high resolution, man in the loop combat monitored and modified b' the commander at any time.simulation s)stem, which provides continuous The terrain reasoning s.ystem is not dependant on thesimulatior at aU le. els, from indi- idual vehicles to large commander, but he pro% ides a supervisory componen.',regirnenta1) units. The SAF s)stem contains a terrain to it. He may pro- ide additional collateral informationreasoning component, ^hich pro% ides realism to the to the planning process, such as suspected enemySAF vehiies and assists the SAF unit commander with positions, in order to regenerate a set of routes, or hemisr .on p, nning. This sN stem works at all le',els of the may modify the results of the planning process, such assimt !a.or,. from the individual vehicle level to the moving waypoints along a generated route. He mayhighest eanelon lee,, and incorporates multaple terrain enter battlefield control measures, such as phase linesreasoning applicauons. At the vehicle le, el, the terrain and unit boundaries, %hich are also utilized b% thereasoning system performs local area reasoning, which terrain reasoning process, so that routes stay within
' ,,, fu-.enz defens:',e P:'- ' a .v...-, desicnated sectors and alow. the un: to reare aobstacles, such as water, builaings, and otMer ehcc. parucular loauon at a partlcuiar time. He ma. pero,,_.At the hicher echelon le, els, this system performs these modifications at an, time, so that a mission can bereasoning x th map-lke objects. such as roads. a% enues redirected based on modified terrain reasonin- resu:sof approachn, and n',ers, to support operations like route The terrain representation in tnib system a,,ows trieplaning and coordinated bridge crossings. For mc.. terrain to be displayed and updated rapidl., so themissions, mis system provides seamiess performance at commander can %iew a map of the terrain alone %.hz:: le cs -. .hc s,.c'. For exzmp:;, a-e.nes cf the b.n-as-field czrol The ;u _,-eca.; ..approach and unit boundaries are uulized to generate allows rapid- retrieval of user selected areas of therou es for a unit and its sub-units, then indi%idual terrain, so the commander can magnif\ or scan to avehicles pelorm the local area reasoning as they follow section of the map quickly.those routes. The system interacts with battlefieldenvironment models, including intelligence, electronic 2. Introductioncounter measures (ECf) and meteorological modeis, inorder to proide realistic mission planning. For The SIMNET program, an advanced technologp projectexample, routes generated from just the terrain ma) be sponsored by the Defense Advanced Research Projectsmodifie-d naed on intelligence data. such as known A;'enc. (DARPA) in close cooperation with the Army,.enemy lo.;-.-Lons, or meteorological data, such as poor contains a Semi-Automated Forces (SAY; syste'..mobifity dje to weather conditions. which utilizes a terrain reasoning subsystem. SIMNET
[11, 12] utilizes a large scale network of low-cost, full-A powerfi. terrain representatuon has been de\ eloped to crew tank and aircraft simulators, which allo\ thesupport the terrain reasoning component of SAY. This Army to conduct platoon-. company-,. and battalion.representation is an object-oriented. quadiree based level exercises incorporating all of the tactical. logistic,approach. which allos data objects to be stored in administrative, and communication elements that aredifferent oa,.s at different levels of abstracon. This critical to actual field operations. The SAF system 2. _'-allows r.easoning to be performed quickll. over large allows exercises at the regiment and above levels to beareas of t-ie terrain and then focused in on smaller areas run without requiring large numbers of fully crevwc.dfor more exact reasoning. For example, roads can be simulators. SAF allows a complete battalion to bestered: y,2-. o'- lr-'_ a" ' wes: leve!of Lh', tree. 5- contro!leJ from a wir ge 'orkunton 2an" 15 E""that indiidual vehicles can follow, them and not run off mntegrated into SIMNET, so that, at any level, fu2.:of them. At a higher level. a road network which crewed simulators can take the place of a SAF vehicle.approximates each road as a straight line segment This system operates within the SINET en'ironmen,.between intersecuons can be stored, which can be used where it must exhibit realisuc beha% ior in order tcto quickly find shortest routes over large distances. The engage in combat with manned simulators, and it mus.terrain representation also supports dynamic terrain, so fight to win in that environment.that the exact state of the simulated battlefield can berepresentcd. D n.,m~c terrain albo. .:mulauon obtec.s In order for an, combat simua:ion to I, -e,- c" theto effect the terrain, such as destroy bridges or generate simulation system must be able to reason about te.rain.
n z. rcpr,.cor, pros ,.. ;o: r ,,i;o exp.-rn th.,, raborr.An to th uz2:. ar, ai.:_ '
D-45
Report No. '714P rsB\ Systems and TechnologieS Corpoiration
the terrain through a po%%erful user interface. At the When real world terrain reasoning occurs, many terrainhcart o' anN comba, simulation is a requirement for fa~tors are taken into account. Networks of road andintelligent reasoning over terrain for mission planning. water systems are used to find the best routes betweenThir ran~es fro-rn icr-o-terrain navication and route locations. Cross count.-'% mobility factors based onplanning for individual vehicles (suzh as SINET atributes such as slope, soil type and weather are used
sem-auomaedvehicles or aul'onOMOUS lan4 vehicle in planning unit movements. Visibility factors such assimulations' to mission planning for large units. The hill tops and tree cover, and vulnerability factors, such
c~j'reasc-.g rz es Lak~:t placc a; v a. bnd.-.' anm.>anvons, all play a part in reasonablelevels wvithin the sirnulauicn. as shown in Figure' 1. A,, terrain reasoning. This paper describes some of thethe highest level, human level reasoning using map research into data representation and reasoningobject,,, such, as roads and avenues of approach must techniques performed at BBN, along with thetr testingtakze place. At an intermediate le~el, automated" terrain and use in the SINENET environment, in order toreasconing, using similar map objects, must be provide a real-world solution to semi-automated terrainperformed. At-the lowest level, vehicle level reasoning reasoning.of local terrain, such as soil type covered or terrainslope, must take place.
Unit Commander Terra In- Reasoning Vehicle Behavior
Human Level Reasoning Automated Reasoning Robotic ReasofningSymbolic Terrain Syrr-oc~ic Ter'a- Reo'eseni~atioi Reais:.c Terra;:- RepreserIma:;c7
Representation (Maps) (Otijec*; Orientec, Abslract) (Polygons, Micro-terrain) IMission Planning Mission Planning Mission xectiinTactical Situation Ro,.-e Generation Batlefiteld Eff ects
Tactical Situation
Figure 1Terrain reasonine within a combat simlation is
performed at various levels.
D-46
B TN Svt em and Technologies Corporation Report No. 7140
3. Terrain Representation amount of data necessary in computer memorwhen drawing and during searches, as well as limit
3.1. Requirements the amount of computer storage that is necessary tostore the terrain.
Military terrain reasoning for mission planning isCCral. performed usirz maps of the battl area. Be organized spatia.l} so that specific regiors "f
Terran features are represented as abstract objects %i ith the terrain can be dispia)ed qwckl), without hainzspecific atibute information displaed along wi'h to search the whole terrain database to find a,! M.Ifeature locations. Spatial relationships of these objects objects to draw.are interpreted by the user based on these locations. Forautomated terrain reasoning, the terrain features used Store different representations of the same objectshaxe to be represented similarl. Therefore, the terrain in different ways. so that more fidelilt is displa,edrepresentation is a large factor in the abilit. to reason when it is necessary. For example, when a largeabout the terrain. The representation should have the scale is beir g displayed, roads can be representedfollowing characteristics: by the netwc:k information only, but as the scale of
the display is made smaller, the road width and• Be object oriented, to alloA various classes of road type information could also be displayed.
terrain objects and their relationships to be stored.i... , !szLr ihez"di.ensIez.on-1 =2:. a- . ..
" Support rapid search techniques to aloA high lexel to displa% this elevauon information in a usefulreasoning to be performed in a reasonable time. manner, such as contour lines and ele% ation slices.
This is necessa.- to pro ide as much inf.rmati- ," Be easily expandable, so that new static object the user so that he may verify the results of the
types can be addc.d to it and aio to albow dynamic automated planning or do his own planning if :heterrain to be added and deleted durine runtime. automated planning breaks down.
* Pro, ide connectiitN information along .,ith The object oriented terrain used by the SAF system hassupporting static information, to assist the other requiremets imposed on it because it is used Irreasoning process. For example, distances along conjunction with the SI*MNET Computer Imaz-road segments %,ithin a road network can be added Generator (CIG) runume databases. The CIC's are used,,hen the road network is generated. so that this within the manned simulators to provide a visual sceneinformation %ill not ha'e to be calculated at of the battlefield to the soldiers taking part in the bat,'c.runtime. The SAF vehicles are also seen by these soldiers on the
battlefield through the CIG's, so the placement of the" Support logical operations on area objects since SAF vehicles on the terrain is critical for a realistic
many different area objects can overlap. For simulation. The SAF terrain must correspond exactly toexample, one of the reasoning processes might be the SIM3,NET terrain in specific areas, paricularl.to determine the intersection of a mobilit corridor bridges and water, since, for example, the SIMNETand a minefield in order to find a safe passage to an vehicles will bog down if driven into water. If a unitobjective, commander sends a SAF unit across a bridee. t.
bridge must be at the same location as the bridge in the" Handle different objects in different ways in order SINEKET environment or the SAF vehicles %ill cet
to be most efficient. For example, linear objects stuck in water or appear to dne through -the water.should be stored in some t)pe of networks so that Trees and treehnes are another feature that must betheir connectivity is represented, whereas area represented exactly, since they can be used forobjects should be represented in such a way that concealment. Other features like hills and mobilitthe. gemmetry IS preser, Z. areas ca'n be representea more abstrac.;,, sf.l I'M,. ."
features are not used for vehicle level reasoning, so their" Alloy, the terrain objects to be displayed efficiently exact locations are not as critical to the simulation.
and quickly, since most militar applications ofterrain reasoning require the results to be displaNed The runume terrain database used in the CIG is no-oer a represent-an of the underiaving teramin, suited for either reasoning or drawing. This datats:The terrain should retain Its object oriented consists of a large number of polygons which arestructure %hen displayed. so that the user can optimized to display quickly when used ,ith the CIGinteract with it. hardware in the manned simulators. The terrain
polycons. which have different elevations at each" Be as compazt as possible. This %kill proide more vertex, are used to displa% the underling terrain.
r "- searcl.n dnn te'ra, reaso.C5 n, limit the Terrain obiets. which are made up of large numters of
D-47
Rvpor: \--. 7140 WIN Systemns and Technologies Corporafion
indi-'idua! polheons. are used to dspla% the terra.n. containing a set number of vector endpoints. Allspc ifi. objccts on thLudec in& tcerrain. For exam .- , quadtrees. hovue, er, require a large amount of memcr.roads are represented as a series of road poly gons and are not alxkays optimized for memor' accesses. R-o% erla~d on, thc N,. ab sno n in Fizu% Z. Tres '-! p-a% id a representation tor area featu.res% tha:The indi'.idual runtime obieci ;s are made upc of a large is opLmized for memory access, but is based on
n Jmt . _ p z: %g 5 f ar t " r ea Fi. Z: h z overlappini regions, so some loss ofspatial relation .:cruntime database is broken up into load modules to limit Occurs. Octu-ees r~ arc useful for storage of three.the numnber of po.'- cns that need to be har.d:ed at an , dumensiona: d.,L.. bu: reciujr. exrernei, large arnc ,;-one time by the CIG hardware. This forces objects to be of memory and are quite complex.broken up at these runtime module boundaries.Se..ondly. objects are broken up so that they hie flat on Topographic databases for geographic informationthe undcr!X:nz :er-,an pc %gons. This Jar.-. number of systems are based on levels oil organization for te-ia~nobjezc: polygons make dra ,ng of the terrain objecLu features. One such database [6] utilizes a cartEograprji
zcr% slo%%. Also.. tasor on, these obiects is extremnel" features level and a topological elements level to stcredi"'.cul:bcuetee sn oncio ewe h feature attributes and locations. respectivel,. an-'a
iniida plgoso tesaeo9et spatial clustering lay er to store spatial relationships. 'v,sorting the features according to size and location. Adatabase based on planar suldivision M7 stores regionsas polo-ons; an, linea: leatures. as e-cces. Weizch:z %assigned to the polygon interiors and edges, and areused for terrain navigation. A hybrid data structurebased on quadrees :1' has been pr oposed which.- store.;indices into feature data structures. Vectorrepresentations are used for linear features an-
qudee re usdfo- area fe2ares. A pyrxn;d. wh::-.________is represented by a quadiree, is used to store the spatial
relationships.
Two approaches were considered for the SAT: terr.aindatabase. a unified data structure approach and adiversified data structure approach. The unifieJapproach stores all of the terrain objects in the samedata structure, which is then used for both reasoni ngand drawing. A quadtree- structure was investigated.with the leaf nodes of the tree corresponding to
Figure 2 individual terrain objects. In this approach, each quad isFeature po1> cons. such as this road, are broken down into four new quads until each quad
oserlayed onto underlaying terrain poiycons. completely contains one terrain feature, as can be seenin Figure 3. This approach was tested with a portion ofthe Ft. Knox database and generated 83,4A02 four meter-
3.2. Di% ersified Quadtree Representation quads within an 8 by 8 kilometer area. This approachworked well for certain reasoning operations. like
Various representation schemes and their organization identifying the types of terrain featiures crossed by a%%ere. in'esticated in order to determine an optimal particular route. Using a Symbolics 3675', the systernterrain represent~ation for the SAF system in aczord-ance was able to ide.nfy, all of the terrain features alone a 8'ift the a3-c've cuidelines. Previous 5neuato ofrioee ot . ta eod.Temi ewa;
'arious hierarch,zai spauial da:. represent-tkons wkere! with this approazh %%as that It lacked tie connectionreN ie A ed and evahL,.,ed according to these guidelines, information needed for other reasoning operations, ..eQu:a'r.s !10'. which subdivide the terr.ai.- into areas ra oiwn.As.i a oeae lv odacomaing a singe feature, are usefu! for storage cf area2 the quadiree noebcuetenasa ne iowes.and pnint feat~ures. Techniques exiv for efficient ]eve! were small id meters"-i in order to provide smoth !
ger~~a:r. n,~ earh~n of uadree. M I-tl borders. It also requvred a large amount of memor% toquadtrees can t-e used to store overlapping regions. and s'r hsdtbs.both or. dis a nd durnei iutme.routtaces exist for performing B oolcan operations on ________________
quadtree regioni. Specialized quadtrees have been
FloatingPonAceear.4linear kattIEres. N' ubdsdi~ th teIi inOarararne Buffer, Gene.-a 7.2 Operaunig System.
D-48B
IM\ Ns ,stenn and T cnh'i. Cor;,-ration Report No. l'
A di'ersifici quadJtree representation. Ahjiih is beter can be disnla~cd at a lo%%er fid.lit% Lo speed uodra.%inersuited- for both reasoning and dispiaN. A~as also time. The quadtree structure provides the data
in~~~;tcdfor use w~ithin the SAF system. In this organization to limit the search space to onl% areas ofreprebcntion. each quad contains pointers into data interSL This is especially important %~hen the reasoningst;uctLre1s holdirng the actua! terrain features and each is at the vehicle level, w~here each vehicle needs toleaf no.'e ha., a large fixed ground size, as scnin knov% about the terrain imm;ditelk surrounding it. ThisF.guire 4. iLazh fea:.ir type is stored in a separate data representation alo% s for easy updating becaase o.-,:%structure vuhich is opurmized for that obJect type. die indices of the obiects are stored in the quadu'.Different data structures are used to inde-x into the When ne-, features need to be added or existiazfeature dz..a structures, for determining die spatial features updiated, onlN die indices in the quads need tore.,atuorsh.ps between features. For example, road be changed. Dynamic terrain can also be handled wid.segments are stored in an arra%. with each quad this rep'resentation since the underlavinig data structues.containina pointers into the road segment array,. A road mhich norrnaliN are static structures, car. aibc zintersecucon array is also generated. Aith pointers into dynamic and the quads can be updated in real tame. Th:sthe road segcment array. This array specifies w~here representation also handles the case of overloadin.-itersecucns are lo,aied and whi,.t road segments form within an area of the tern. If the system performarnccthem. Wz~th~s approach, abstract dat-, structures Can is significantly degaded because of too man% featuresbe stored at. higher levels of the quadtree. This allo%%s within a quad, that quad can be broken down into four
ofce:~a dff~e:le-els of fic:- e.. qas hch a teir l be broke -
so tha-. reasoning can be performed quick:% o'er large necessary, until each quad contains a more reason.-c.areas of the terrain and then focused in on smaller areas amount of dama.for moe -,K:!t reaconini:. Also. larce areaz of die terrain
Quad TreeI
Simple Terrain
Fictir; 3The classical quadtee approach divides the terrair,u11111 each quad ncji cntin only a sriinl featur%-.
D-4 9
Report No. 7140 BB'N Symsems and Tech.ologies Corporation
Avenues Mbltof MbltLow Resolution Approach Areas
Terrain
I....................J
* I
I ,,rain
,s IS .S s
Figure IThe diversified quadtree approach allows high level reasoning to be performedon low resolution represcntaoons of terrain. features and high level reasoning to
be performed on high resolution representations of the same features.
D-50
BBN S~stems anc Technologies Corporation Report No. 714A
3.3. Performance Study organization. Figure 7 shows the number of duphcteindices in a leaf filled quadtr for various leaf node
A stud\ was conducted to determine how different sizes. Most feature types shoA a large amount ofparameters of the diversified quadtree affect its duplicauon within smaller leaf nodes. Roads do notpeforr.ane. The two fators in'esugated were nc show much duplicauon because the road segments tendminimum size of the leaf nodes and the method of to be less than 1250 meters long so thai they de netfilling the quadtree. A test database of 50 by 50 cross many quad boundaries. Finally, Figure 8 sho.-kilometers 2 was used for this study. Two methods of the drawing speed at all of the map scales for the t%;fiihng the di~ersified quadtree %ere invesugated. The types of quadtrees, using a leaf node size of 25'Xfirst method, leaf filling, fills only the leaf-nodes of the meters2. The drawing routine uses the quadtree se _-htree \,.h indices into the feature arrays. If a feature is rouunes, so drawing tme can be used as a measXire o:present in more than one quad, the index is duplicated searching efficiency. The fully' populated quadtreei. those quads. The second method, fully populated. draws faster at higher scales, because of the du;z.:.:.-allcws an\ node of the quadtree to contn indces into of ir dices, but the leaf method draws faster at lowerthe feature arrays. In this case, a feature is stored in the scale, because of its better spaual organizauon. At t-esmallest quad that completely contains it, so there is no 1:200,000 map scale, the quadtree is not used fordu-licat.on of indices. The leaf filling method is better drawing, since all of the features are drawn, so bc*.suited for databases which contain smaller features, methods exhibit similar drawing times. A quad node
I-- ,-" - i-"- ci ia-: fea:-es scw V. leaf size of-CS50C meters- vaS ....;. c C'" :.down drawing and searching. There is a trade-off, SAF database because the data sull retain sufficienthowevor. because in the fuLy' populated method the data spaual organizauorn v ith adequate memory usage. Abezom: less spatia!v organized. Features of anv size full' populated Iuadtree was aI chosen. due to th.that cross quad boundaries are moved to higher levels of many large area obJeCt in the database and the fasterthe quadiree. This is particularly severe at the center of drawing i e at the higher scales which tae thethe dambase. because any" feature that crosses the center longest to draw.hnes w :i; resioa at the top of the tree. Therefore, whendrawing or searching a single leaf quad, all the quads" 3.4. Quadtree Search Algorithmsabove it in the tree have to searched for features thatthe b- in that qua . With the leaf filling method, all of Figure 9 shows the three types of quadtree searchthe indices for that leaf quad reside within it so no other algorithms developed for use with the fully populatedsearching needs to be done. quadtree. The first technique shown finds all of the
quad nodes that descend to a parucular leaf node. ThisThe results of the diversified quadtree study are shown rouune is used to find all of the features at a parucuiarin Figures 5 through 8 The effects of quad node leaf location on the database. Startng at the top of the tree,sizz on the szora;e requirements for -the quadtree this rouune traverses the appropriate chdd nodes untu itstucture is shown in Figure 5. The quadtree memor) reaches the leaf node, keeping track of all of the nooesrefers to the memory needed for the quadtree structure traversed. In this way, all nodes that do not have thatitself and the indices contained within the quad nodes, leaf node as a descendant and all sibings of that leafbut not the structures storing the terrain features. A node are eliminated from the search space. The secondquar with. v--, s,.a! leaf nodes requires a large technique finds all of the quad nodes that descena tcamount of memory for this quadtree structure. A more than one quad leaf node. This routine is used forquadtree with large leaf nodes require less memory, but finding all of the features that may be passed through bythe data lose spaual organization. Figure 6 shows the a linear or area object. Starting at the top of theeffects of quad node leaf size on drawine time for a quadree, each node is tested to see if it passes -hrougn.hich and a low map scale, when drawn on a Symbolics the area of interest, which is usually the bounding3675 At the low map scale (1:12.500), drawing time rectangle of the linear or area object. If a quad node icin:rea;.- sli't!, larcr leaf nodes, sin:e more totalUN outside of the test area. it is eliminateo irons, tn,-objects are contained in each quad node as the search space and its descendants are not tested. I aminimum size increases. At the high map scale node is partially or completel within the test area,. it is(-100.000x. drawing time is relauvely constant for the retaned and its descendants are tested. The thercfully populated quadtree, but decreases rapidly as the technique is similar to the first. but is used to finam:nimurn size increases for the leaf filled quadtree. The features that are close to a paricular location on tEhumber of duplicate indices increases as the minimum Pi"ound. This routine is used to find features that may beleaf node size decreases. so obiects are drawn many in neghboring quad nodes of a particular point. Th:more times with smaller leaf nodes. There is no rouune creates a rectangular test area around a locationduplication of indices in the fully populated quadree. so by adding and subtractinc haff a leaf node % idth a2n.Ce.'- I.% Eim: is z;nszn. Tn c lCai f.;d quadtrece draws height to the locauon. The second search aigonmnm isfaster at the low ma- scale due to its better spatial then used to find all of the quad nodes that conr't c,'
D-51
t pr \.. '141) BBN S stemz and Teclinologie, Corpor:airm
16
-- 0- Fuly Populated
: 12 "0E
10
0 2000 4000 6000 8000 10000 12000
Quad Node Leaf Size (meters)
Fie -e 5Smaller quadtree iea noaes generate targer quadtree but pro%de more
spatial orgarization than quadtrees with larger leaf nodes.
80
- 1,00,000 Ful- 10:00,000 Leef
60 - 1:12,500 Full41:12,500 Leaf
40E3:
S 2Cv
0 2 000 4000 6000 8-000 10000 12000
Quad Node Leaf Size (meters)
Ficure 6Lc~ ri%.& s:ze ha: a ~ci : on dra % inc sp 4-AII- lea: fil , -=
qtuadcrees. duc to the duplicnon of indices.
D-52
1B \ S steni and l etchnologies Corporat-on Report \u. -141
29
-0- Rood
-v- PA.'-C- Forest-- Weier Are.
U
.E 10-.
0
C II I i 5
0 2000 40CD0 )0 6000 10Z03 1200C
Quad Node L... Size (meters)
Fi Lr e 7Leaf fille't quadrees contain many duplicate indices at small leja node
sizes.
ec1-
"- Leef f'oGe - ' '
C 2C
I C
... z. .C.. I CC.C,.^,. I 5CC . I -:=..Ccc I !:"=---c 5 ...'e c"
rieD Scale
Fully populated quad.rces provide faster drawing at higher map seL!es.
D-53
Report No. 7140 lIN ',%sienis and Technologies Corporation
that test area If the loca:Ion is close to die center of a locauon i! near the cde of a leaf node, the tcst area willleaf quad node. the test area will be completel) wahin extend into one or more neighbor leaf nodes, so quadthat leaf node, so only quad nodes that descend to that nodes that descend to any of those leafs will be retainedlaf w;l1 be retained in the search space. If, however, the in the search space.
Search Technioue 0,Quad nodes ml des,,end to a singie leaf.
Kz Search Technique #2Quad nodes that descend to multiple leaf nodes.
Kt
,§ 5 Search Technioue #3Quad nodes that are close to a location.
SQuad nodes retained in the search space.
Ficure 9Three quadtree search techniques are used with
the SAF terrain database.
D-54
BI-' Svstems and I echnologies Corporation Report-No. 7140
3.5. SAF Terrain Database The networks are represented as arrays of segmentob)ects and arrays of intersection objects, as shown in
Two databases, whose characteristics are shown in Figure 11. The segment objects are the segments ofFigure 10. haxe been generated fr use widhin the SAF each feature that run between the intersecuons. Eachsystem Both of these databases are based on quad leaf segment object contains a list of points specifying thenode sizes of 2500 meter 2. In order to exenlN di ide the midline endpoints of each leg within ,hat se-ment alcn.nwhole area down to this size, both quadtrees are based with the width of that segment and the total distanceon an overall size of 80 kilometer 2. The memory size along that segment. The intersection objects contain theshown is the amount of disk storage for the quadtree locauon of the intersection along with a list of theand all of the feature objects. The contour lines make up segment identifiers which connect at that intersectiona significant portion of each database, especially Ft. and the identifier of the intersection at the opposite endHunter-Liggett because of the mountainous terrain in of each of those segments. In the SAP system, anthat area. This representation is essentially two intersection occurs where two or more networkdimensional, where eletauon data are stored as contour segments come together or a single segment er.ds. and
the identifiers are simply the indices into the seg-mentlines and area features. Octtrees could have been used to t istore the elevation data, but the memory requirements and intersection arrays. Each feature is represented as aand complexity precluded their use in the current separate network instead of a single network of allsystem. Elevation data necessa,, for actual vehicle linear features. This speeds searching since eachnet, ork can be searched dpr ,Jt,,a,2a:'.placemert on the ground are obtained from the runume~each network to be displayed separately.CIG terrain polygons, so that vehicles will appearcorrectly in the manned simulators. Octtrees may be Bridges are handled as a special case of roads an! ceubed to store thib ele% ation data in future versons of the "iesarhnleas o," ... aeofrc."n"-system. stored within the road network. Each side of a bridge is
considered an intersection, so each bridge is a separateTh.:c -c five classes et teran obects in the sF ~ road segment obiect. These objects have all of the same
tei-ain database. These are networks, area features, informauon as normal road objects, but are idenufied aslinear features, point features, and dynamic terrain. In a bridge segment. This allows more precise roadthe present sstem there are networks of-roads, rivers, following routines to be run when a vehicle is crossir.:and railroads, and area features of water, forest, and soil a bridge, as well as allowing bridges to be identified astype. The linear features consist of treelines and contour targets.lines, and the point features are individual trees an'Tbuildings. Dynamic terrain consists of battlefield The river network consists of an array of w atercontrol measures, such as phase lines and objectives, segments, similar to the road segment array, where eachand minefields. segment is broken up where more than two rivers mee:,
where a river segment meets another network segment.or where the width of the river segment changes. Theiver segment width information is stored along with the
SAF Terrain Databases midhne points. The width informauon is stored as a list'_ _I F:. K- - I F: HIunte-.Li.--e of three values which consist of the w'idths at each end
Aa of Tarru= 75 5Ok- 50 x 50 k~m2 and at the center. These widLhs are useo in mne draw imnNube of Qua75 13605 * 50 2 routine to taper the segments when they' are drawn.Number of Quads 1365" 1365" Also, each water segment is labeled as beine fordable orLeaf N;ode Size 2500 meters- 2500 meters2 unfordable water. The rail network is very similar to theMemory Size 1.6 MBytes 2.1 MBytes road network. Multiple tracks are treated as singleMinimur Elevation 115 meters 0 meters segments with additional width.Maximum Elevation 300 meters 1780 metersCe.oui line Lnte' a: 5 meters 10 mewrs Area features within SAF consist of forests, areas ofContour Memor, Size 1.2 M tes 1.8 MB. tes similar soil type, and bodies of water not represented -n
the river network, such as oceans, lakes and reservoirs.N0 k r These features are represented as objects consisting of
boundary segments and triangles, as can be seen in
Figure 10 Figure 12. The boundary segments are a list of allCharacteristics of the SAP Terrain Databases connected boundary points for each area feature. This
list is used during terrain reasoning. The mangles arcthe minimum number of three sided polygons necessary
D-55
Repo(rt No,. 714(0 BBN Sy stem., and Technologies Corporation
ior dra\v\inc the complete area. These are used by the associated attributes, such as heights of treelines anddra,-king routine to dravx these object quicklN and used ele'aui of contour lines. The contour lines, areb) the terrain reasoning routines for rapid screening, generated from the initial database elevation points,Final',, the area obiec;ts contain attribute information usuaX'\ DMNA D -iED data. They are broken up at qua,'pertinent to that area ob *ict type. For instance, forest node boundaries, since, otherwise, they tend to cover aocJ. .ts, contain attricu~jes about the general type of tree!, large portion of the database. Point features arein that 're.st, as well as pointers into the tree and represented as arrays-.of point objects. where each pointtrecline representations for those objects that are-, ithin ha-, a location and other attributes based on the objce-tthe forest- type, such as type of building or height of a tree.
Locations can either consist of a single point, such asLinear features are represented as arrays of linear the location of a tree, or a list of four points to specify aobj-cts, where each object consists of a point list and rectangular object, such as a building.
0 Segment ID
Briage Segment
Segment Intersection'
I Network SgmentI Network Intersection
N et we r k A t eri euts:t o r n e r e t o
?-e isRcenToeel (Wt3 Segmnt ID I
DisIrnc sectnecr ID 2
Fi cure I1Iwe~okdta sz-uctures consi oi n-,%o.-: seme ra5
and network intersection arrays.
D-56
BB\ Svstem and Technologh.,, Corporation Report No. '140
Dynamic features cons,st of ohiects entered at the 4. Terrain Presentationworksmticm which can be removed or edited. Theseobjects ;can be batLiefield ccn'ro. measures and The SAF ter-ra:n database is an integral part of r-.minefields. In future versions of SIMNET, there will be mission planning prucess. The user is also an integralniu:' m-:. dyninc terra r,, sucn as bi3owr up brdJ,:. pan o f this process and therefore ritst be 3W ""and tank traps. The current SAF terrain representation interact with the terrain database. The terrain must be.% li casil., accept these new features. since each feature displayed quickly and in a form that the user is fam"U.a7is stored in a separate arra%. This array can be with. The SAF system presents the terrain in the samedynamica.l edited, and the resulting index changes form as a militarN map, since that is what a unitmade to ..- quaduee in realtime. commander uses during mission planning. Along m ,th
the terrain features, which are displayed in color, UT.IBatdefie!i control measures consist of avenues of grid lines and a legend are displayed. Routines areapproach objeczu'es, phase lnes, axes of advance, unit provided to change the scale of the map dispay an.2boundari.s, forward lines of troops (FLOT, EFLOT), change the location within the terrain that is beinglines of departure and lines of contact. The dynamic displayed.area fea'ares, such as avenues of approach, arerepresented similarly to stauc area features, and the The diversified quadtree representation used in thedynamrc linear features, such as phase lines and unit terrain reasoning system is used to display, the terrain.bounda:i-s are represented s:mlarlv to static linear This representaton is organized spatial!\ A hich alUt,,teatures. -%. of these features are edi&be. car. Dc it to be displayed quiciy, ,hile sull retaining the objec '
incorporateJ into missions., and used by the mission oriented structures. This is important because the user isrlannmz :-'uunes. Bat'.lfil, control measures can be interacting uith the terrain features on the displa,. suchsa\ ea inL o% erla\ files and reusea at a later date or as selecting roads and bndges, and the seiecuon of ineshared be:,xeen workstations dunng an exercise. terrain objects must be performed in realtime. If a
separate representation was used for display, a........ arc.,.=::. rc~r,:.cZ:',,.cc as ,,i a. oic:..s V ,'h ccnersion rou:., ..,, b nedc ".=t'cn c'. "varmble ,._Iihs, minefield density and mine sensini' itN. representiuons. Two representations would alsoThese ob e.:ts are also editable, but delays have been necessitate larger storage requirements as well asbuilt int, ::,e s)stem to take ino account the tme it contribute more complexity to the system. With tLtakes to .zar or modif, a minefield in the real ,orld. single representation, the same routines that areMinefiel.. can be saNed in overlay files, but they do not optimized for searching during terrain reasoning arecreate ... -. v, hcn Icadc back in. This pre C!.. used during "display, h"cn, als aLos the tc,many c07,es of the same minefield being created in the display faster and with less complexity.SINET environment when overlay files are sharedamong c...erent \workstations. It does allow other During a typical use, the map display is redra-wn qu,ieuorkstat.--.s to display the locations of pre%iously frequentl, so much work went into drawing the terrair,created rranefields, however, as quickly as possible. One effective technique was to
iacorporate a-very efficient clipping algorithm into thesystem [9]. Even though the data are stored spatially in
Area C..,t the quadtree. if part of a quad is being displayed, manyX " A Ae Ae features and portions of features must be chpped by the
Afea ':)getdrawing software. For example, with the SymbolicsA"':" drawing routines, when the data are clipped before6 _m . -' calling the drawing routine, using this efficient clipping
X"
t~x( O'*tX2Y." )
4., 93 (YVIX^ .- algorithm, drawing is improved by up to a factor of 10,(XI i X2 V2 X! V61 especially at lower map scales. This clipping algorithm
g2; x. x6 j;V ' is also used during some terrain reasoning ot-er:e. :.,1 I / limit the number of objects searched. For example. th,
x1. 'V& AttroMAH bounding rectangle of a water segment is used as a-:o preliminary test to see if a route passes through that
et,s - water segment.
Tho quadtree structure provides other advantages fcrfaster drawing. Some features are stored with different
Figure 12 representations at different level of the quadiree. ForArea obiecs contain boundary segments, example, individual trees and treelines are stored at the
tangles, and attbute iformaton, bottom of the tree. but are aggregated into forest areaobjects at higher levels of the tree. At higher map scales
D-57
R,,prt No. -14.'1 BDN Sys:,m, and Technologies Corporation
these forest objets are dravn, and at lower scales the Address the area of obstacle avoidance. Mosttre and treehnes are drawn. The area feature previous systems have looked at areas ofrepresentation also contains a list of pre-computed trafficability, but not specific points within thesetri-ges gen.rated from the boundary polygon ar,,as. An obstacle avoidance component isRoutines that draw polygons with arbitrar, numbers of necessar in the planning system, such that obstaclesijzs first break up the polygons into triangles, and thcr. cruszng and penetration puurnL should be idenafe.dra3-, these triangles. By pre-computing the triangles, and routes adjusted automaticall, to use them. Fortn, S) bnct,h draving routines are 2 to 4 times faster. example. if two areas of high trafficabilit% aredepending on the complexity of the polygon. Network separated by a river, the system should not discountsegments and linear objects are drawn as single pixel theirconnecti'it.. Instead, it should look forwidth lines at higher map scales, but with their true crossing points over that river, either with bridgeswidths at lower scales. Some linear features. like or fording points.treelines, are drawn as a straight line connecting the twoendpoints at higher map scales, but as a line connecting Take into account miitar doctrine. For example,all the points at lower scales Other linear features, such for a river crossing, whether a single bndge can beas contour lines, are simply not drawn at the higher map used or, if available in an area, multiple bridgesscales. For instance, the contour line interval ranges should be used. Also, it should determine thefrom 40 meters at the highest scale (1:200,000) to 5 or tactics that should be used for that river crossing,
. ...... , .+ , lo' , .3. . ,l:6,5. aft,3 bclo,-, . ,.,.' O, ;s ,L. lhie,,W:; !r+o.
Contour lines are also broken up at quad boundaries tolimit the amount of clipping that needs to be done at The terrain reasoning system currently in the SAFlower scalez, sys:em suppors mul:;-level reasoning. At the vehicle
level, local area reasoning is being performed. usingThe map is dis; ayed on an 8 bits per pLxel Symbolics terrain objects in the dv'ersified quadtree and runumecolo- screen The color map space is divided into 3 terrain polygons. The vehicles perform obstacleplanes to limit the amount of redrawing that has to be avoidance on each other and objects on the terrain, suchdone. The terrain plane, which is 3 bits deep, is used to as buildings. Vehicles look ahead to their next routedisplay most of the terrain features. The commander can wa.point and %hen a possible collision is detected, theselect which features to display at any time. so this bounding volume of the obstacle is used to alter theplane is redrawn only when one or more features are route of that vehicle, as shown in Figure 13. The newadde' or deleted from the display. The vehicle plane. ro,:te is then checked for other obstacles. which. ifwhich is 4 bits deep, is used to display the locations of present, are avoided similarly. The terrain immediatelyvehicles on the battlefield This plane also contains the surrounding-the ,ehjcles is examined before obstaclelegend. so tha, it can be displayed or removed quickly avoidance is performed. For example, if the obstaclewithout redrawing the terrain features. Similarly, a one occurs on a bridge. such as a damaged vehicle blockinebit overlay plane is used to display the battlefield the bridge, the moving vehicle will try to go around thecontrol objects. grid lines, and contour lines, so that damaged ore, as long as the new route does not go offthese can also be displayed or removed from the screen the bridge into the water. If this is not possible, thequickly. moving vehicle will look for an alternate route over the
water. This is done by searching for other bridges orS. Terrain Reasoning fording points within-the local area and generaung new
routes to-the other side of the original bridge. If anA terrain reasoning system for military mission alternate -route, which does not go through water. canplanning should have the following characteristics: not be generated, the unit commander is prompted for a
new route." Support mission planning and execution based on
use-suppli.d criteria, such as maximize co~er or Vehile level reasoning also takes place when vehiclestime. are attacking and defending. Intervisibility calculations
are performed which take into account the terrain• Built in such a way as to generate mobility elevation and terrain objects. An attacking vehicle can
corridors for large units as well as specific routes onl, target enemy vehicles that he can see. Defendingfor individua. vehicles, vehicle can use the terrain to conceal themselves. b)
either hiding behind hills, treelines, or buildings. The* Look at terrain features such as elevation, slopes, intervisibilii, routines are probabilistic, so objects like
soil types, trees, and penetration points, and have treelines do not completely conceal a vehicle, butthe abiliiv for collateral and intelligence data to be se.erel% reduce the probability of detection. The uniincorporated into the planning process. such as commander can position the vehicles in his unit to be•,eather, situation and contact reports' just out of detection range from a specific point on the
D-58
BI;N 5\stenw and I echnologies (orporation Report No. 714o
terrain He f.rnt commands these v'eh.,. le to moxe close One of the modifications the unit commander can r'aketo these concaled positions and selects the point to be is to specif, all or part of a route to be a road march.concealed from. The inter. sibity routines then The commander selects a point for his vehicles to ge: ondetermine the exact loauons for all of the vehicles and a road b) choosing a road segment from the map. Hethe. move to them. then selectuc either a- in--ed:ae road "-I or a ;:t:
for his vehicles to get off the road by choosing anotherAt higher echelon lces. the terrain remsoning 'ystem road segment. The terran reasoning s'.stem the.assists the unit commanders v.ith route generation determites the best road route betmeen the t', o roadduring mission planning, using the terrain data vithin points, as demonstrated in Figure 14. This route isthe di'. ersified quadrec. At all le% els, mission routes are usually the shortest distance road route between the tv, cgenerated based, to a large extent, on the terrain. The points, but depends on the type of mission it is to bcunit commanders select the area within which the routes used for. If the objecue of the mission is maximumare to be generated by creating unit bound anes on .he speed. such as an attack mission, the road segment ty.pesterrain. Routes for all vehicles and subordinate units are weighted so that paved roads have an advantagewithin that unit are then generated vithir thoze unit over dirt roads. If the mission objective is stealth. suchboundaries, such that untrafficable terrain is a%oided as a scout mission, dirt roads are veighed to be moreand water is crossed at bridges or fording points. The ad'antageous. Bridges also are weighted so that routesgenerated routes are presented to the urut commander so that do not have to cross them take precedence. Anythat he ma' modif% them to be better suited for the number of consecun,,e road points can be entered to
.-.. .. , .......... .ra: ." in: tune the.road routL..-A'. r,..nb.: of r ma u ,o..t-commander is presented v ih a partial route. vhi ch he be incorporated into a mission route. The road routecan then mod,fy to completion. Whenc.er the unit finder rmmrns a list of road segments m the correct ordorcom.mande is enterine routes m-,ua, or mod:f'.in: a that connect the t'.s road pomts. If the pents d -route, the terrain reasoning system checks "o see if that connect or if the number of alternauve paths gets veryroute, or anN subordinate routes that %'.j oc renerated large, the road finder connec,, tne to points ' afrom that route. cross %k ater xithout the aid of a bridge cross counLry route and warns the commander tha ,or fording point. If any route does, the commander is suitable road route could not be found. The commandernotified so that he can modify that route "o a% oid the can either accept that route segment or undo that pointwater, and put in intermediate points to cenerate a suitabIl.
road route.
I ngmna Route
... -. Bounding Volume
0 • Ognar.gm Waypons
~I1 C New weypwontrL- - - - -e W-'n
I I - -New Route/
~ Single CMstacle
Mlultiple Cstecles
Figure 13The bounding volumes of obstacles are used to generate
routes aound them.
D-59
R port No 7140 BBN Systems and I echnologies Corporation
A part of the route planning process, the commander crossed the bridge, the) get back into formation andc.,n explicitly specif% a bridge to cross along a route. continue the mission.The- system determines the direction to cross the bridgebascd on th- previouz points in the route. The tacuca: An A, search algorithm [13j is used with the roadsituation and collateral information are used to intersection and road segment arrays to find the roaddetermine ho%% that bridge is crossed.-For example, if a roates. This algoridm uses the straight line distancecompany is to cross a bridge and the) are on a road between intermediate points on the route and the-'arch and there are no reports of enemy vehicles in thc destination point as an estimate of the remaining routcarea, the company crossing the bridge will ita in distance to the destination. This estimate is always ancolumn formation as they cross it. If, on the other hand. underestimate of the remaining distance, so that thisthey were not on a road march. can see enemy vehicles, procedure will-always produce opumal routes. Becauseor have reports of enemy vehicles in the are.. the. %,ill the estimate is-an underesumate, however, more-routesdeploy into a defensive posture before crossing the have to be searched to find the opumal route than-if thebridge and crosq it one platoon at a time. When all of estimate was closer to the true distance between thethe platoons and ccmpan. command vehicles hac points. This requires longer time to find the optimal
Destination
1 Intermediate Point Stir-
a Direct Route
Route wi:h Intermed;a:e Point
Figure 14An A* algorithm is used along with the roadnetwork to find road routes between points.
D-60
BIA\ S~sit-niv and T ech nologies Corporation Report No. -1411
rocic. but theso database-s most of the road semn~ 6. Extensionsare fairly s.raight between the intersections. so that theCs.mrates are close to the actual distances. The urr.zs There are a number of extensions planned for the S -%7reqwired for these searches. are quite small. so that. for terrain reasoning system. One area of research i, tocxarrple, ,. road route on the order of 50 kilometerz. can expand the realtime capabilities of the s) stem, in order,.bce enera.- in less than one minute. The A* algor-ithm to obtain more realistic vehicle behavior. espe-c.-alIs also ni;.n-opportunsu%, such tLEi if the situation during combat. For example, moving vehicles %%il:changes d-rzng the generation of a route, this algorithm make better use of terrain for co% er and conceahncrcaln noLtlue uuose chances for thaz route. In the current durnge combat. Another area of research is to incr.:.s-,stem, hzov exer, most route generatLion takes place at the mission p!anning capabilities. As more ccflaz.-3mission p.anrnlng time. Iff the situation changes during infor-mation is added to SIININET, it %;il1 be added to- t',mission execution, the A* algorithm can be reruin to SAF mission planning process. ECM models, such as).ceerater. loc:al routes tor tlhose sub-units affecteod b)y radar and communications jamrning. are curent>', ur.:e,lhe change, in situation. This is illustrated in Figure 15. development for inclusion into SflvtNET. These eficz:During &1,= e.%ecauon of the mission, one of the bridges %% Al have to be taken into account for SAS missions. scaicing Compan% A's route is destroyed, so the A* that vehicles avoid areas of intensive jamming. foralcorithr is rerun for Compan-y A to generate a nev. example. Weather effects v, U1 also ha% e to be tak~e-n Intcroute across the r!-.er. The network representation account. Finaly, the automation of all] of the terrain
'~ .:h~n S~ ~ez~5~tc ithe A' alr7r-;Ehr . So:: e.-,. ~~.~a -- '~.~.:other sear~ .nr- car, be tested in this system. personnel, such as avenue of approach geertin.i
planned for the SAP system. This will remove more- of_______________________________________the mission planning burden from the unit comrmanders.
allowing them to concentrate on the tactical aspects of
0Bj the missions.
-7. Conclusion
The current SAP system contains a powerful te-rairepresentation that provides the terrain reasonnI system rapid access to the terrain features in a realtime.
I large scale. hierarchical. high resolution comba;
in the loop route planning functionality and in future,systems will prov'ide more intelligent mission planning
)A arid execution capabilities. SIWfNET provides an ideal,) / testbed for terrain reasoning research. The state of th z- / terrain can be modeled at many levels of fidelity, and
B ~the vehicles can be provided with various levels oilautonomous behavior. Terrain reasoning systems
A devclooed in this simulated battlefield environmeast c-5,be easily' extended into the real world combatenvironment, since smpwET simulates such a lareportion of the battlefield systems and mcdels and misterrain reasoning systemn utilizes most of them.
- Original Route 8. Acknowliedgments-New Roui~eStpeDoesMrn
_______________The author would like to thankStpeDonsMrifor his suppor and ideas during the design of Ohnssystem and his review and comments of this paper I
Figure IS would also like to thank everyone on) the SAFWhen a bridge is destryed durnge mission dcs elop-ment team for their support during th,
execution, a ne% partial route is generated for de~elopment of this system, especially Joshua Smithi frCompany A. Lhe obstacle avoidance code and Tom Mitchell for the-
user interlace.
D-61
Rt p1,r \v. - 14; PB,\ S.attm , and Technologies Corporjli'w;'
9. References 112) SIMVrU V2 3 Brad:ey Fzphtminr 1'eiSan.,:.n, EBN SystCs andi Tehii
[!] Richard Antony. Representation Issues in the Corporation. Report 6892, August 1988.De.-.. ,a Databs . , . ....,System, U.S. Army Symposium on Artificial [13 Patrick H. ,*inston. Artficial.ntellzence.l;::,.ce Rcsca:h for Ex-'" -, ' , r . -- *, se., P, t1sh;4 CoMpZ'.: Z nBattlefield Environment Proc., November 1988, MA, 19 &. p 113.'79.10T.
r-) Andy Ceranoticz. Stephen Downes-Martin. andMatreen Saffi, S1MNET Semd-Automawed ForcesVcrsion 3 0: Imp.emen;a:ior Isuc., BENSystems and Technologies Corporano, Report6940, October 1988.
(31 Andy Ceranowicz. Stephen Downes-Mardn. andMaureen Saffi, SIMNYET Seii-Automated ForcesVe,'sion 30" A Functiona! Desc,'i,.io.. BB\
6939, March 1989.
[-; Antonin GuEEman, R-Trees: A Dynamic IndexStructure For SEoatial Searching. ACM-SIGMODConference Pro-., April 1984, 47-57.
[5; C. L. Jackins and S. L. Tanimoto. Octtrees andTheir 'Use in Represendng Three-DimensionalOtbezcs. Comrp;.:cr Graphi:s and remaProcessirg, Vol. 1-, 1980, 249-270.
. TerrEnce Kea..z. WilliamPh--. a-,-d Kv;"cIngram, An Integrated Topologic DatabaseDesign for Geographic Information Systems.Phozogrammetric Engineering & RemoteSensing, October 1978, 1399-1402.
[71 Joseph Mitchell. An Algorithmic Approach toSome Problems in Terrain Navigation, ArtificialIntelligence, Vol. 37, 1988, 171-201.
[8) Randal Nelson and Hanan Samet, A ConsistentHierarchical Representation for Vector Data.Computer Graplucs, Vol. 20, August 1986, 197-206.
Tina Nicholl, D. T. Lee, and Robin Nichol. AnEfficient Nek Aleorithm For 2-D Line Cipping:its Development And Analysis, ComputerGraphics. Vol. 21. July 1987, 253-262.
"10: Hanan Samet, The Quadtree and RelatedHierarchical Data Structures. ComputingSurveys, Vol. 16. No. 2, 1984, 187-260.
;l SIMNET MI Abrams Main Battle TankStmzdo:i;:. BEN Svstem.- a-JCorporation, Report 6323, August 198W
D-62
Appendix E
The SIMNET Tutorial
Tutorial on the SIMNET Network and Protocols
Presented January 15, 1990
Art PopeBBN Systems and Technologies Corp.
10 Moulton St.Cambridge, Mass. 02138
617-873-2931Internet: [email protected]
E-3
Protocol Tutorial
• Overview• Everything the simulated world includes* Goals of the SIMNET protocols- Architecture of the distributed simulation- Protocols* Layering of protocols° Distributed simulation concepts• Communicating vehicle appearance• Effect of dead reckoning on network traffic
- • Data communication requirements* Network performance
• Association protocol• Simulation protocol- Data collection protocol* Data representation
* Object type numbering schemeo Elements of communication compatibility
• Future work
. . .. . . .. . . . . . . .. . .. ..- --- - ---.. . . . -i -_-'---".. .. -
Protocol Tutorial ARP - BBN STC - 1114190 - 1
E-5
Overview
" "The SIMNET Network and Protocols",'dated 31 J uly1989
• "Summary of SIMNET Protocol Changes, August 1989 -January 1990"
• requirements: the simulated world
" architecture: networks, layered protocols
" communicating vehicle appearance information
" supporting networks
* survey of protocol interactions• representation of information
• communicaton compatibility
• future work
Protocol Tutorial ARP BBN STC - 1/14/90 - 2
E-6
Ev ig the simulated world includes
* fterrainy tens or hundreds of kilometers on a side
* populated with features: hills, rivers, roads, trees,buildings...
• static - not changing in the course of a simulation- a particular date and time• vehicles that move dynamically and engage in combato supplies of munitions, such as fuel and ammunition- the transfer of munitions from one vehicle to another• weapons fire and its effects upon vehicles- damage to vehicles and vehicle breakdowns- repairs performed by one vehicle on another• radar emissions and detection by radar
Protocol Tutorial ARP - BBN STC - 1114190 - 3
E-7
Goals of the SIMNET prot );s
* a real-time network of hundreds of simui" ensure a consistent view of the simulatec d
* be parsimonious and efficient* allow efficient distribution of computation tasks
* be robust (not error-sensitive; self-correcting, if possible)• easily acommodate new kinds of vehicles,'weapons,
phenomena..." make available information useful for analysis
Protocol Tutorial ARP - BBN STC - 1/14/90 - 4
E-8
Arc ..ure of the distributed simulation
Simula-or -mua Simu a
Site C~n~:' S~ m~aoAB
. Long Hi- Network
a simulator might:
* simulate a single vehicle (e.g., a flight simulator)" simulate a group of vehicles (e.g., Semi-Automated
Forces)* play a role in initializing other simulators (e.g., MCC
system)" give a window into the simulated world (e.g., Plan-View
Display)" make an historical record (e.g., Data Logger)
Protocol Tutorial ARP - BBN STC - 1/14/90 - 5
E-9
Protocols
* three simulator-to-simulator protocols.are definea:
" a simulation protocol for representing the simulatedworld
• a data collection protocol, to support analysis
" an assodation protocol, to convey the other two
Protocol Tutorial ARP - BBN STC 1114190 6
E-10
Layering of protocols
s are defined within the framework-of the OSIe model
Aplcto Layer- Simulation Sublayer
"" Associabio SublayerPresentaton Layer
Session Layer
Transport Layer
Network Layer
Data Link Layer
Physcal Layer
• the association protocol provides common servicesSimulation Data Collection
Protocol Protocol
Assocation Pmtocol
Communication Service
Protocol Tutorial ARP BBN STC - 1/14190 7
E-I I
Distributed simulation con
" an exercise is a joint activity of simulators" it has a simulated world, some participating -.,lators,
and an exercise identifier
• there can be many concurrent but independent exercises
" a simulated world is populated by vehicles
• each vehicle has these static attributes:* which side it is fighting on
" what organizational unit it is allocated to
" what type of vehicle it is
• a unique vehicle identifier
• each vehicle has a dynamic appearance described by:
* where it is, and how it is oriented
" a marking or label (e.g., "Titanic" or "PItLdr/3/C")
* variations on its basic appearance: flames, smoke,dust cloud...
* each vehicle has internal state represented by:
" operational status of various subsystems
* quantities of various munitions on board
• each vehicle's appearance is periodically reported with astate update message
Protocol Tutorial ARP - BBN STC - 1114190 - 8
E-12
C -unicating vehicle appearance
- de oning reduces the need for communication
" va .d reckoning approaches are possible.. no use of dead reckoning- location updated using velocity
- velocity updated using linear acceleration- rotation updated using rate of rotation• velocity updated using rotation
" vehicles are classified, partially according to deadreckoning method
- static class - those that remain stationary* simple class- location- updated using velocity
- tank Class - like simple, but has a turret* discrepancy thresholds determine when state updates
are issued
- any discrete change in appearance (e.g., catching fire)
- transiation by 10% of vehicle's dimension- rotation about any axis by 3 degrees- movement of turret or gun barrel by 3 degrees
I'I
Protocol Tutorial ARP BBN STC 1/14190 - 9
E-13
Effect. of dead reckoning on netwc:- iiffic
dead-reckoning a tank using velocity on,..
C ~Rotaton Threshld
C3-
0
z
I% 10 100%/
Location Threshold (Fradion of Vehice-Dimension)
*dead-reckoning an aircraft using-velocity, linearacceleration, and rate of rotation:
5-
Rotation Threshold 4-2.5084- 50
45 200
3-
0
1% 1%100%O
Location Threshold (Fration of Vehicle Dimension)
Protocol Tutorial ARP -BSN STC - 1/1.190 -10
E-14
r ;ommunication requirements
" Si,' otocols-are application layer protocols" SIV tocols are supported by network layer service
* netwc , must support broadcasting or multicasting ofdatagrams
" datagrams range up to 256 bytes; most are 128 bytes" guaranteed delivery not required; occasional.failurestolerated
* a level of performance determined by the "size" of thesimulation
" various network technologies may be used
" network may be a combination of local-area andlong-haul networks
* Ethernet has been used successfully as a LAN
Protocol Tutorial ARP BBN STC - 1/14190 - 11
E-15
Network performance
" most network traffic is due to vehicle state" network traffic depends on:
" number of vehicles participating* types of vehicles (ground vs. air vehicles)" how vehicles are behaving (stationary. cruising,
jinking...)• ground vehicles (tanks) produce an average of one
update per second
° close-support air vehicles produce an average of six persecond
" each update is communicated as a 128-byte datagram
° each update must be communicated to all simulators in"real time-
* network delay, and delay variance, can be detrimental° how much delay is acceptable depends on application:
" relatively slow-moving ground vehicles can tolerate300 ms
• high-speed aircraft flying in formation cannot
Protocol Tutorial ARP - BBN STC - 1114/90 - 12
E-16
Association protocol
.st- -d composite of certain transport, session, andap. layer services
" eliminates need for separate transport and session layerprotocols
" supports two modes of communication:
" datagram service provides best-effort delivery" transaction service pairs request and response,
provides retransmission* clients are addressed by site number, simulation number" clients belong to multicast groups
Protocol Tutorial ARP BBN STC - 1/14/90 - 13
E-17
Simulation protocol
*activation of vehicles" deactivation of vehicles" vehidle state update" weapons fire" collision between vehidles" transfer of munitions between, vehicles" repairs by one vehicle to another
Protocol Tutorial ARP -BBN STC -1114190 -14
E-1 8
Data collection protocol
status reporting1" event reporting
Protocol Tutorial ARP. -86N STC - 1114190 - 15
E-1 9
Data representation
• formal notation: data representation notation* provides a concise, unambiguous descript..,n of data
element encoding* e.g.,
type ObjectType UnsignedInteger (32)
type MunitionQuantity sequencemunition ObjectType,quantity Float (32)
• aim is to minimize protocol's dependence on machinearchitecture and language
* restrictions on data element alignment and size areenforced
* e.g., a floating point number cccupies 32 or 64 bits* e.g., a 32-bit quantity is aligned on a multiple of 32-bits
Protocol Tutorial ARP - BBN STC 1/14/90 - 16
E-20
Object type numbering schemeir
. Is include vehicles, ammunition, quantities of fuel,oarts...
- a .oject's type must be represented for communication(e.g., M1A1 tank, 155 mm HE shell)
- object type codes are arranged in a hierarchyObject
Vehice Munition Structure
Air Ground Water Detonator ProjectileVehicle Vehicle Vehicle
Fixed-Wing Rotary-Wing
* this scheme, once defined; remains valid as new objectstypes are added
• software can understand something about an objectbased on where its type code places it in the hierarchy
• this allows new types of objects to be introduced withoutdisrupting existing software
.... ... ... ... -- --.. . --- ---. -- -------.... -----.. .. .... . ..... - -
Protocol Tutorial ARP - BBN STC - 1/14/90 17
E-21
Elements of communication comp.-tibiiity
• scope of simulation* what phenomena are part of the simulated world
* architecture* what things are computed where
" the use of dead reckoning
" messages and their contents• what PDUs are used
* what information each PDU contains
* message encoding* how information is represented as bits
• e.g., the use of ANSI/IEEE standard floating pointformat
" underlying network services
• choice of networks for various parts of the internet
" e.g., use of Ethernet-or FDDI
• ongoing internet administration
* the assignment of site and simulator addresses* coordination of exercise identifiers* registration of simulator type codes
• extensions - e.g., to object type numbering scheme
Protocol Tutorial ARP - BBN STC - 1/14/90 18
E-22
Future work
-.sions for additional types of vehicles and simulatorsreckoning algorithms
" using higher-order derivatives of location and rotation* blending in new appearance information
* missiles• transfer of missile simulation from firing simulator* homing on continuously designated targets
* dynamically changing terrain" atmospheric effects, such as smoke and clouds
Protocol Tutorial ARP - BBN STC 1/14/90 - 19
E-23
SIMNET
,/ Long-Haul Networks(between sites) \
Local Area Networks New Generation(on site) 0cCOMDB: Simulators
SIMNET OVERVIEW
SIMulator NETwork (SIMNET) is a U.S. Army/Defense Adyanced Research Pro-jects Agency (DARPA) - sponsored program that provides realistic combinedarms battlefield training for combat vehicle crews. SIMNET is a significant newapproach to- training both large and small combat units. Hundreds of low-cost,full-crew ground vehicle and aircraft snulators at widely dispersed sites arelinked by a common real-rime data communications network. Crews of thesesimulators-can see and interact with each other against accurately scaled oppo-nents on the same realistic battlefield.
119/90 BBN Systems & Technologies Corp.
E-25
SMINET Benefits Combat unit personnel control these ve-hidcles from the consoles of the SIMNETSIMNET allows fully-manrned platoon-, Management, Command, and Control
company-, and bartalion-stze units t (MCC) system. There are also consolesconduct force--on-force engagements for exercise s:,rt-up and close air supportagainst opposing units of similar compo-sition without incuning the costs of trans-porting large numbers of persohnel and Semi-Autom .:-J Forces (armor, mecha-equipment. These engagements include nized infantry, air defense vehicles, hell-the complete range of command and con- copters, fixed-wing aircraft) controlledtrol and combat service support elements by a human coz.arnder. These forcesessential to actual military operations. provide an opponent as realistic as the
manned simulator.. The computer proc-SIMNET is a test bed for future full corn- esses detailed simulations foneach vehi-bined arms joint tactical training projects cle, providing route-following, obstaclesuch as the U.S. Army's proposed Close avoidance, formation-keeping, target ac-Combat Tactical Trainer (CCIT). qisition, etc. The commander monitorsSIM"ET is expandable, and greater num- tht. force's behavior on a Plan View Dis-bers of simulators can share the network play, and can intervene at any time toto increase the scope of the exercise. redirect the activities of a company, pla-
SIMNET is a "simulateb.efore you build" toon, oreven a single vehicle.development model for-new weapons sys- Data collection and analysis systemstens and combat tactics. New ideas can which store the state update messagesbe tested and evaluated in the SIMNET broadcast from all vehicles during the ex-world safer and at less cost than in the ercise. As soon as the exercise is corn-field. pleted, these messages can be replayed
onto the network and the entire exerciseWhat is SIMNET? can be repeated and observed from aboveManned simulators representing the main (on a Plan View Display) or from the par-current combat vehicles: ticipant's level (from the vantage of a
'Stealth' vehicle which can assume the0 M1 Abrams main battle tank role of any other combat vehicle). In ad-U M2/M3 Bradley infantry fighting dition, a powerful set of data extractionvehicle and statistical analysis and plotting tools
can measure and report on individual ve-0 Generic attack helicopters hicle or combat unit performance withinminutes.O Generic fixed- wing close air support HowuDes N
aircraft How DoesSIMNET Work
0 Generic air defense artillery SIMNET is a Distributed Simulation. Nocentral computer-directs the activities of
Automated combat support and combat the various simulation elements. Instead,service support vehicles: each simulator has its-own microcom-
putcr(s)-which talks to each of-the other0! Artllery (self-propelled howitzers simulation elements. As the network ex-and mortars) pands, each new simulator brings with it
O Fuel and ammunition resupply vehi- the computer resources necessary to sup-cles -port its computational requirements.
Adding new simulators does not require0 Maintenance/repair vehicles that the existing ones be modified.
1/9/90 BBN Systems & Technologies Corp.
E-26
Each manned simulator tpically consists work) with automatic error detection.of a host computer, a computer image Ethernet can efficiently handle the simu-generation (CIG) color visual system, and lation traffic of up to 1000 vehicles on auser interface controls. The simulators at single network. Furthermore, LHN linksa given site are conr -_d by an Ether- are easily installed.net." local area ner- CLAN) and com-municate via the SR- -T Protocol. ConclusionEach simulator tram, specially foi- SIANET is currently operational at train-matted information T called Proto-clata nitsmationT catedeh- ing sites in the United States and Europe.col Data Units (PDT_ " that vehi- Simulators can now be linked on a world-cle's location, move d appearance wide network to support large-scale train-in relation to oLher sir. vehicles, ing exercises and the development of newand receives similar data zrom them. doctrine, tactics, and weapons systems.Sites are connected to each other by long Pre-combat simulation training means ahaul network (LW links over land lnes higher probability of success in actualor by satellite. Each LAN has a small battle. The variability of the SMNETgateway computer which efficiently inter-faces with the LHN. battlefield means'that victory-goes to the
side that is able to plan and execute its
Ethernet interfaces are inexpensive, avail- combined arms operations better than itsable from multiple vendors for practically opponent. SIMNET meets the combinedall computer makes, and they support arms training objectives realistically andmulticasting (the simultaneous broadcas: cost-effectiv.iy.of data to multiple simulators on the net- Ethernet is a tra~emark of the Xerox Corporation.
C 1989 BBN Systems & Technologies Corp.. All rights reserved.
E-27
APPENPIP' F
~Graphs of Conclu.ing* Remarks
SECOND WORKSHOP ON STANDARDS FOR THEINCEROPERABILITY OF DEFENSE SIMULATIONS
TERRAIN DATABASE WORKING GkOUP
These notes auarent the summary briefing charts presernbed in the"inal session - ,he Workshop un 17 January 1990 and address thespecific issue entifid in the opening session.
1. COORDINAMION WITH DMA
Continuing .cordinacion wit: the Defense Mapping Age.icy (DIMA) onspecific product requirements is being handled by DC- ServiceLabs/Staff and/or Joint offices. Area coveraae reqt.;remLnts willbe handled primarily 1hrough 'nified and Specified (b&S)Commands. Terrain database issues in simulation networkingrequire continuing coordination between P2851, PM-TRADE, ETL,TRADOC TSM and DARPA.
2. INTERIM TERRAIN DATA ASSESSMENT/ITD
ETL is working with '9M-TRADE to investigate ITD related issues inconjunction with P2851 and SIMNET. Coordination among PM-TRADE,ETL, DARPA, P2851 will be necessary for ITD assessment, withadditional support from BBN, IST, and PRC.
3. PROJECT 2851 ECP ASSESSMETI/ITDSee ITD assessment/ITD (Item *2 above).
4. GEODETIC FRAME OF REFERENCE
The Working Group recommended adoption of the DMA-World GeodeticSystem (WGS 84).
5. DEVELOI '-T OF CORRELATION PARAMETERS AND METRICSSee Subgroup Chairman Duncan Miller's viewgraphs.
6. DYNAMIC TERRAIN FEASIBILITY/METHODOLOGY
See Subgroup Chairman Richard Moon's viewgraphs.
7. INCREASE SIZE OF GA11E BOARD
The Working Group recommended use geocentric Cartesiancoordinates in network protocol to support potentially global"gaming boards". Standard conversion routines forsoldier-machine interfaces to-and-from geographic coordinates andMGRS are needed with test data sets for validation testing.
F-3
8. SPHERICAL EARTH MODEL (Lat/Long)
The Working Group recommended adoption of geographic coordinates(latitude/longitude/altitude) for standard Navy and Air Forcesoldier-machine interfaces and MGRS (UTM and UPS) for standardArmy soldier-machine interfaces. Coordinate systemstransformation need to preserve relevant tactical effects ofcurved earth (finite distance to horizon) in computer imagegeneration.
9. DEFINITION OF SOLID MODELING TECfINIQUE
Working Group anticipates use of Project 2851 (P2851) solidmodeling techniques and libraries. P2851 has adopted aconstructive solid geometry (CSG) approach to build StandardSimulator Data Base (SSDB) models. SSD3 CSG models aretransformed into polygonal models based upon target IG'sperformance capabilities and distributed in GTDB format.of thissoftware is on-going; anticipate completion in early February1990. A limited number of trnsforred models will be includedwithin GTDB data sets to be distributed beginning in April 1990.
10. DEFINITION OF TEXTURE REPRESENTATION
Project 2851 presently does not include a representation oftexture maps. Proposed engineering change (ECP) currently inevaluation would add geospecific (photo) and g;3neric texture maprepresentations. Proposed capabilities are to be fullyintegrated within the Project 2851 system in mid-1992.Distribution of sample GTDB's with texture maps would beschet'uled for early 1992.
11. DISTRIBUTION FORMAT
Working Group recommended adoption of the Project 2851 GTDB asthe future distribution format. Specification is available now.Two types of GTDB are supported: (1) gridded-terrain/vectorculture; and (2) polygonal-terrain/vector or polygon culture.Gridded GTDB's are critical to support many existing CIGarchitectures as well as semi-automated forces (SAF) andhard-cGpy/soft-copy cartographic displays. Polygonal GTDB's aredesigned to maximize correlation between a family of existing andanticipated heterogeneous CIG architectures. Sample GTDBs to beproduced beginning in April and distributed to ISWG.
12. DATABASE REPOSITORY ORGANIZATION
The Working Group recommended adoption of the proposed Project285., repository at DMA% Aerospace Center, St. Louis, MO. Initialoperational capability (IOC) is scheduled for May 1991. Theproposed P2851 facility is to be administered by DMA, managed bya tri-service liaison board, and contractor-operated.
F-4
13. SEMI-AUTOMATED FORCES (Unmanned Vehicles)
See Sub-Group Chairman Dexter Flecher's viewgraphs.
23 January 1990George E. Lukes, ChairmanTerrain Database Working Group
F-5