Transcript Intelligent Vehicle Systems Symposium CAT/RF Simulation Lessons Learned Christopher Mocnik Embedded Simulation Team Email: [email protected] (586) 574-5491/DSN 786-5491 Fax: (586) 574-5008 RDECOM TARDEC Vetronics Technology Area (AMSTA-TR-R, Mailstop 264 Warren,

Intelligent Vehicle Systems Symposium
CAT/RF Simulation Lessons Learned
Christopher Mocnik
Embedded Simulation Team
Email: [email protected]
(586) 574-5491/DSN 786-5491
Fax: (586) 574-5008
RDECOM TARDEC
Vetronics Technology Area
(AMSTA-TR-R, Mailstop 264
Warren, MI 48397-5000
11 June 2003
UNCLASSIFIED
Tank-Automotive Research, Development & Engineering Center
1
Agenda
• Introduction
• Vetronics Technology Test bed (VTT)
• Crew integration and Automation Test bed (CAT) /Robotic Follower (RF)
Overview
• Unmanned Combat Demonstration (UCD) Overview
• Embedded Simulation System Overview
• Lessons Learned
 Schedule and Requirements
 ESS Process Overview
 Distributed Control
 Inter-process Communications
 Unmanned Ground Vehicle (UGV) Process
 Reconnaissance, Surveillance, Target Acquisition (RSTA) and Automatic Target
Recognition (ATR)
 Image Generation
 Scenario Development
 Terrain Database Development
 Hardware Implementation
• Conclusion
2
Introduction
The Embedded Simulation Team from TARDEC, along with DCS
Corp. Successfully designed, developed, and integrated an Embedded
Simulation System (ESS) that supported both the CAT/RF
experiments as well as the Unmanned Combat Demonstration (UCD)
with the Lead Systems Integrator (LSI).
The following presentation will provide some background
information on previous and current programs and then discuss
lessons learned from CAT/RF and UCD development.
3
Background Information
4
Vetronics Technology Test bed (VTT)
• Goal: Improve the war fighting
capability of ground combat vehicle
systems.
• Approach: Develop, integrate and
field test advanced Vetronics
technology for ground combat
vehicles.
 Advanced Crew Station Interface
•
•
•
•
Indirect Vision Driving
Multi-function Displays
Speech Recognition
3-D Audio
 Advanced Electronics Architecture
 Embedded Simulation System
• Modified M2A0 Bradley Fighting
Vehicle used as test platform.
5
Crew integration and Automation Test bed
(CAT)
• Goal: Design an advanced 2-man crew station
for a system < 20 tons incorporating the FCS
fight, carrier, reconnaissance, and C2 of
unmanned systems.
• Approach: Build on VTT technologies and
provide developments for integration into the
FCS demonstrator. Additional capabilities
include:




Robotic Mission Planning and Control
Robotic Assisted Driving
Decision Aids
RSTA Control
• Prove out technology developments using a
FCS class chassis - Interim Armored Vehicle
(IAV) Infantry Carrier Variant (ICV) or
Stryker.
• Enhanced ESS to support Robotic planning
and control, and RSTA operation.
6
Robotic Follower (RF)
• Goal: Develop, integrate and demonstrate the
technologies required to achieve unmanned
follower capabilities for future land combat
vehicles
• Key Requirements:




Dismounted or Mounted Following.
Semi-autonomous perception.
Significant separation times and distances.
Map data and sensor terrain feature
registration.
 Road detection
 On-coming traffic detection.
• H/W & S/W design based on Demo III.
• Chassis:
 Stryker representative of FCS mounted
systems.
 XUV representative of mule system
7
LSI Unmanned Combat Demo (UCD)
ARV-1
RF ATD (w/ COUGAR turret)
RSTA and
Engagement
RSTA and
Engagement
ARV-2
Demo III XUV
Targets
Simulated targets for Maneuver
Real targets for Live-Fire
•Surrogate Platform
• Mobility (~16T)
• Semi Autonomous Nav
• Simulated Objective Capability
• Turret/Weapons
• RSTA
Demonstrating:
• 1:1 Operator to ARV Control
• ARV Engagement
Control Vehicle (CV)
CAT ATD
•Surrogate Platform
• Mobility (~2.5T)
• Semi-Autonomous Nav
• Simulated Objective Capability
• Turret/Weapons
• RSTA
•Surrogate Platform
• Mobility
• Semi-Autonomous Nav
• 2 Crew Stations
• C2
8
Embedded Simulation System (ESS)
MISSION APPLICATIONS
Embedded Training
Mission Rehearsal
Mission Planning
Crew Stations
FCS Class Vehicle
Vehicle and crew
interaction data
Embedded
Simulation
System
SIMULATION BASED ACQUISITION
Simulated Turret
Virtual Lethality
Virtual Sensors
Simulated ATR
Simulated ATT
Simulated C2
VEHICLE SIMULATIONS
Mobility
Survivability
Virtual OPFOR
Virtual Friendlies
Virtual Battlefield
OPERATIONAL APPLICATIONS
Battlefield Visualization
Terrain Registration
Virtual Sensor Coverage
Virtual Lethality Coverage
9
CAT/RF and UCD Simulation Lessons Learned
10
Schedule and Requirements Specification
• Schedule:
 In a perfect world, appropriate development time should be allocated in the
program schedule to adequately design, develop, and fully test systems in order
to meet the customer’s needs.
 The CAT/RF ATD was originally a two year development effort. However, in
order to support the FCS program and meet the FCS milestone B decision, the
amount of available development time was reduced to one year.
 In that time, the ES Team and DCS had to support not only the CAT/RF
simulation requirements, but that of the UCD as well.
• Requirements Specification:
 Requirements specification may be the most important part of any software
engineering process.
• Captures the customer’s needs.
• Basis for system design.
11
Schedule and Requirements Specification
 Firm requirements were difficult to capture and document:
• FCS and LSI unmanned systems concepts were still evolving.
• Physical assets available for demos such as RSTAs, vehicle platforms, weapons
platforms etc. were still being negotiated.
• Results:
 DCS and the ES Team were able to successfully demonstrate an embedded
simulation capability, though many non-critical requirements had to be
dropped.
 Given a finite amount of time, a finite number of human resources, and
“creeping” requirements, trade-offs have to be made in order to meet hard
deadlines.
• Lessons Learned:
 Work closer with internal and external customers to lock base system
requirements as early in the development process as is possible. This will
allow for more effective use of the available time.
12
ESS Process Overview
• Processes functionally
partitioned by the service
they provide.
RSTA Server
CAT Vehicle
SimControl
Manager
AKIT/BKIT ICD
Akit
Interface
UGV
PIU Data
PIU Comm
Object
AAR
• VTT code reused to
largest extent possible,
with new processes for
UGV and RSTA control
added.
Mobility
NIU
World
• Reused processes
modified to incorporate
new functionality
DIS PDU’s
CGFI
OTB
Sight Weapons
• Inter-process
communications
performed through PIU
Comm Object.
13
Distributed Control
• The CAT ESS software expanded on VTT capabilities by adding support for
dynamic control of any unmanned asset (controlled by the ESS) from either of the
crew stations.
• However, the VTT ESS code was designed around control of one ownship vehicle
and therefore was tightly coupled with VTT ownship vehicle states and modes. As a
result, some limitations were present in the CAT implementation. It was not possible
to control two independent battlefield visualization eye-points for example.
Crewstation
1
Vehicle
1
Vehicle
2
Crewstation
2
Vehicle
3
Crewstation
N
Vehicle
M
Embedded
Simulation
• Lesson Learned: A more flexible software
architecture will be needed to be less
dependant on vehicle states and modes.
• In the future it is required to not only
dynamically control unmanned ground
assets, but unmanned air assets as well.
• The notion is to control any asset from any
crew station at any time.
14
ESS Inter-Process Communications
• The PIU Comm Object was an
effective tool for managing interprocess communications.
 Proven and well understood.
 Code Reused from VTT program
• However, an extra “layer” of
management is needed at the A-kit/BKit interface level.
• Lesson Learned: Allowing each
process to write directly to a common
shared memory area with the vehicle
will eliminate the need for an extra
layer of management.
• Will perform trade analysis on the
impact of moving to the WSTAWG
OE for this purpose.
15
ESS UGV Process
• UGV Process Instantiates a UGV object for each UGV under ESS control in the
scenario, and communicates to other processes via PIU Comm Object.
• Plan Object parses incoming UGV mission plans from the vehicle.
(Communicates directly with vehicle via its own socket connection, not through
PIU).
Plan
UGV
UGV
Process
…
…
UGV
Platform
Mobility
UGV
T/A
Sensor
(RSTA
Class)
RSTA
Weapon
Platform
• UGV Object controls
the virtual UGVs
 Interprets UGV
Mission Plans
 Controls when data is
passed to the UGV
Platform Object.
• UGV Platform Object
starts a thread where in
each functional object
is instantiated. Passes
data to each object.
16
ESS UV Process
• Lesson Learned: UGV process performed very well. It was also an object
based design instead of functional based design as was the earlier VTT code.
• If possible, the second phase of the VTI will expand on this design philosophy
with the inclusion of UAVs.
Plan
UGV
UV
Process
…
…
UGV
Platform
Mobility
UGV
T/A
Sensor
…
…
UAV
RSTA
Weapon
Platform
• UGV process may
become Unmanned
Vehicle (UV) process
and instantiate objects
for all unmanned assets.
• Future design efforts
will utilize such
methods as the Unified
Modeling Language to
identify, describe, and
model system
components and
behavior
17
ESS RSTA Architecture
• RSTA architecture utilized one RSTA server video channel to service multiple RSTA
Clients.
 Caused severe lag when serving more than one RSTA client request.
• Lesson Learned: Envisioned RSTA architecture may apply one video channel to each
client. Uses more channels but increases performance.
• Will investigate a trade of dedicated servers and clients versus available video channels.
IG synchronization with
Other channels
RSTA Sim
Server
RSTA Sim
Client
UGV Sim 1
RSTA Sim
Server
RSTA Sim
Client
RSTA Sim
Client
UGV Sim 2
UGV Sim N
Current RSTA Configuration
RSTA Sim
Client
UGV Sim 1
RSTA Sim
Server
RSTA Sim
Server
RSTA Sim
Client
RSTA Sim
Client
UGV Sim 2
UGV Sim N
Future RSTA Configuration
18
ESS Image Generation Architecture
• Currently, each individual output channel is controlled through a master channel. This
concept was carried over from the VTT where switching of the eye-point was very limited
because of the single vehicle environment.
• Lesson Learned: Moving to a distributed IG control approach would solve several
problems (such as RSTA updates) and better supports the notion of a multi-crew
station/vehicle architecture.
• Will also perform trade study to look at other IG alternatives to X-IGTM.
C2
Simulation
C2
Simulation
DIS / HLA
I/F
Perceived
State
DIS / HLA
I/F
Real State
Perceived
State
Real State
IG Manager
Process
“World”
X-IGTM
Slave 1
X-IGTM
Master
X-IGTM
Slave 2
X-IGTM
Slave N
Current IG Configuration
IG
Channel 1
Manager
Channel
Function &
Sync option
IG
Channel 2
Manager
Channel
Function &
Sync option
IG
Channel 1
IG
Channel N
Manager
Channel
Function &
Sync option
IG
Channel 2
IG
Channel N
Future IG Configuration
19
Scenario Development
• Lengthy process involving a number of
factors:
• CAT and UCD employed one master
scenario that was adjusted as needed for a
particular experiment.
 Subject matter experts design the
vignettes. A difficult task as no one has
experience with an FCS soldier/robot
team in combat.
• Originally the intent was to develop a
series of scenarios with each exercising a
different facet of the FCS scout mission.
 Vignettes approved by the user
community.
 SAF users convert vignettes into digital
scenarios.
Scenario – Live Maneuver Exercise
Zone Recon Fort Bliss South
94
L
D
1,2
R
A
2
Lane
s
AA1
R
A
 IG users run through the scenario from
different points of view.
• Dependent on digital terrain database.
17,1
8,19,
20,
21,2
2
R
A
3,4,5
12,13,14,15
,16
Blis
s
Meyer Range Rd
9,10,11
L
D
6,7
• Lesson Learned: Scenario development
is more time consuming than one would
think. Enough time should be budgeted
for the process.
20
Digital Terrain Database Development
• No high-res data was available for Ft. Bliss Texas (desired DTED level 5).
• Fly-overs had to be conducted to capture the elevation data and feature data for the
test site.
 Company needs to be scheduled and flight time over the site authorized.
 Raw data then needs to be converted into DTED like data.
• A trial and error method of finding the right mix of terrain resolution and rendering
performance with the IG may need to be conducted.
 Ft Bliss digital terrain area was roughly 13km x 9km. At 1 meter postings, this is a
large amount of data for the IG to render.
 For CAT, postings were put at 10 meters to get the desired performance.
• Lessons Learned: Depending on the overall quality you desire (resolution of
database, quality of feature data, performance in rendering), digital terrain
database development can also take a large amount of time. At the core of the
virtual world is the terrain database. Without you don’t have a simulation.
Therefore, the appropriate amount of time should also be budgeted for this activity.
21
ESS Hardware Architecture
•
ESS Used Commercial-off-the-shelf (COTS)
hardware.
 Each channel is a RacksaverTM 1U box containing a
TyanTM dual processor (1.6 GHz) motherboard and
a TI 4600 graphics card
 It also contains a National Instruments Field PointTM
unit that can shut down the ESS if temperatures
inside any of the boxes reach a programmable
threshold level.
•
Overall, the hardware performed well. Some
problems were the general size of the embedded box,
coming in at approximately 24”w x 29”d x 17”h.
Initial placement of the box in the vehicle was
difficult.
•
Field Point unit control software was shutting down
the ESS erroneously.
•
Lesson Learned: Will investigate reducing size of
box.
 Hyper-threading is a possibility. This would allow microatx boards to be used.
 Dual video outputs from one graphics card.
•
Will performing trade study to investigate Non-COTS
alternatives
22
Conclusion
• The Embedded Simulation Team and DCS Corp. successfully developed an
embedded simulation system to support both the CAT/RF program and the LSI’s
UCD. Several Conclusions can be drawn from this effort.
 Properly defining system requirements will greatly reduce design and development time
as well as produce a better product.
 Distributing services such as image generation and RSTA operations will increase
performance. It also more closely models the distributed nature of a multi-vehicle,
multi-crew station environment. Loosen dependencies on states and modes.
 Allow enough time for the development of scenarios and digital terrain databases as
these can be time consuming tasks that have a high impact if not done properly.
 Continue to design and develop code using an object based approach and preferably
using such practices as the Unified Modeling Language.
23