170 likes | 296 Views
Reusing Vehicle Simulation Software – Mission Impossible?. Mr. Gary Green Institute for Simulation and Training, University of Central Florida. The Cast. Tank-Automotive Research, Development & Engineering Center (TARDEC) Vetronics Technology
E N D
Reusing Vehicle Simulation Software – Mission Impossible? Mr. Gary Green Institute for Simulation and Training, University of Central Florida
The Cast • Tank-Automotive Research, Development & Engineering Center (TARDEC) Vetronics Technology • Researching vehicle workload issues using man-in-the-loop simulation technology that could be embedded into close combat vehicles • Developed the Vetronics Technology Testbed (VTT) embedded simulation system (ESS) for vehicle crewstations that simulates sensors, weapons and robotic vehicles, provides interface for the soldier to interact with these simulated systems • Currently working Crew integration and Automation Testbed (CAT) Advanced Technology Demonstration (ATD) to demonstrate a multi-mission capable two-man crewstation platform concept in a C-130-transportable chassis supporting the Army's objective force
The Cast (Cont) • US Army Research Development and Engineering Command (RDECOM) Simulation Technology Center (STC) • In parallel with TARDEC, STC is researching man-in-the-loop simulation technology that could be embedded into close combat vehicles for training and mission rehearsal • Currently working Embedded Combined Arms Team Training and Mission Rehearsal (ECATT/MR) Science and Technology Objective (STO) to pursue embedded simulation technologies for training and mission rehearsal for FCS platforms • STO developed Embedded Training/Mission Rehearsal (ET/MR) Testbed to integrate and demonstrate STO technologies
The Cast (Cont) • Institute for Simulation and Training (IST), University of Central Florida (UCF) • Under contract to STC for STO research, IST tasked to: • Build ET/MR Testbed • Adapt TARDEC’s VTT ESS for Testbed use • Integrate STO technologies into Testbed • Track CAT ATD changes to ESS and adapt new functionality for Testbed use as appropriate • Testbed patterned after the CAT ATD crewstations • Less fidelity & capability as it serves a different purpose and is not intended for an actual vehicle • Consists of two, low cost, reconfigurable, man-in-the-loop crewstation simulators representing crew positions in FCS platforms.
The Cast (Cont) • Vetronics Technology Testbed (VTT) Embedded Simulation System (ESS) Legend B-Kit – Embedded Simulation System A-Kit – Vehicle Systems DIS – Distributed Interactive Simulation PDU – Protocol Data Unit ICD – Interface Control Document
IST’s Mission • With a staff of one full-time and one part-time programmer, adapt ~140,000 lines of vehicle simulation code to a significantly different environment in about 8 months • If unsuccessful in accomplishing this mission, the command will ……. well, you know the rest of that story
The Plot (Adapting VTT to Testbed Use) • First Task - Understand VTT software and internal dependencies • Structured into components, but not object oriented • PIU is heart of VTT – everything goes through PIU • Used minimal version of PIU (PIUMinimal) to learn operation of system • Expanded to full system and examined functionality • Ran simple experiments such as Ownship Mobility to verify understanding of the code • Updated VTT to newest Linux (Red Hat 7.3), modified libraries and API calls as required
The Plot (Cont) (Adapting VTT to Testbed Use) • Next Task - Identify VTT functionality needed to meet ET/MR Testbed objectives, implement scaled down VTT • Goal - Establish basic capability to move Ownship, use weapons systems and destroy DIS-generated entities • Prioritized functionality, focused on priority packages until each function worked as expected • Started with Mobility and World • Next, added AKitInterface, put DIS packets on the network via NIU • Established vehicle simulation • Demonstrated a working simulator • C2 and Simcontrol Manager were not implemented in Testbed because of resource constraints, Vulnerability not used because of OpenGVS licensing issue
The Plot (Cont) (Adapting VTT to Testbed Use) • Vehicle vs. No Vehicle • VTT designed to operate on vehicle - Testbed vehicle had to be simulated • TARDEC provided TestGUI to simulate vehicle output and an ICD detailing messages between VTT ESS and vehicle • IST used TestGUI and ICD to develop a simulated Testbed vehicle • Ported TestGUI from SGI to Linux, converted from licensed widget set to open source • Implemented off-the-shelf yoke and pedals for Testbed crewstation control • Adapted simulation data to represent graphic display of tachometer, speedometer, GPS location, etc., added fuel level, target lists, selections for transmission, ammo
The Plot (Cont) (Adapting VTT to Testbed Use) Tactical Situation Display • VTT software drop did not contain vehicle-resident code, requiring IST to “fill in the gaps” for Testbed • Key software such as Map Server and Graphic User Interface (GUI) are vehicle resident, not part of VTT, run on VXWORKS • Map Server provides 2D terrain visualization to crewstations for mission planning and situational awareness • GUI used by TARDEC’s Soldier Machine Interface (SMI) for crew interaction with the simulation • For Testbed simulated vehicle • Used Plan View Display from OneSAF Testbed as 2D map representation • Built a Testbed SMI for touchscreen display interaction with simulated vehicle using CAT SMI design as model and ICD messages
Sub-Plots (Cont) (Extensions to the VTT Code) • Unmanned Vehicles • Testbed required interface for robotic control but VTT had none • Added by CAT ATD but was closely coupled with vehicle • Testbed using robotic Operator Control Unit (OCU) from STC’s Advanced Robotic Simulation STO • Also needed a crewstation display for robotic vehicle status • Developed scaled down version of CAT “UVStatus” robotic control SMI to provide current status of Ownship unmanned vehicles • Permits visualization of sensor imagery, switching between deployed asset views, zoom, daylight or IR views • Robotics was first completely new integration with PIU as no component could be leveraged
Sub-Plots (Extensions to the VTT Code) • Audio System • Testbed required spatial sound • VTT ESS had some high-level audio code but it was not fully implemented • Most event data and positional data already available from VTT • IST completed VTT audio system for Testbed • Added an entity class to track entity location relative to listener, and hierarchy of sound sources (instantaneous, continuous) • Created an algorithm to determine which entity sounds to render if number of sounds exceeds audio card capability • Priority to Ownship sounds, closest live entities • Added OpenAL audio and CCTT sound libraries • Provided audio system back to TARDEC
Sub-Plots (Extensions to the VTT Code) • Testbed desired better visual performance than basic VTT offered • VTT controlled Image Generator (IG) indirectly via DIS • IST reworked World component so that IG could be controlled directly by host processes and moved drawing process to separate host • Provided dramatic improvement in frame rate performance, decreased display latency • Single host frame rate ~ 25fps • Multi-host frame rate ~ 40 fps
Lessons Learned • Licensed products increase difficulty of reuse • Licensed widget sets and graphics tools both caused considerable effort to migrate to open source tools • Single-host architecture is not always better • Moving to multi-host provided much better graphic performance • Also provided room for future growth • PIU is difficult to maintain, not conducive to reuse • Dependencies among components make changes difficult • New function requires 11 steps to implement • Each new PIU message type requires 16 steps
The End • To answer basic question, “No, it is not mission impossible to reuse vehicle simulation software” • Embedded simulation system built from VTT code is functional and running in crewstations of ET/MR Testbed • But the task was not easy • Adapting a large, complex software package to a different task is meticulous, time consuming and labor intensive • However, it can also be a very cost effective use of resources when the new purpose is close to the original one • ET/MR Testbed functionality is much greater having used VTT than it would have been if developed from scratch with the same resources
The Sequel • STC is leveraging CAT developments for ECATT/MR STO • New vehicle and weapons models and RSTA components are of interest • Planning experiments for STO products on CAT vehicle • TARDEC has expressed interest in ECATT/MR STO research products for CAT ATD • Integration of situational awareness between dismounted infantry and their Infantry Carrier Vehicle • Intelligent tutoring for robotic control operators • Adapting Force XXI Battle Command Brigade and Below (FBCB2) to control SAF • Bottom Line – Sharing research products is good business and is continuing
CREDITS RDECOM PI Henry Marshall TARDEC PI Paul Bounker IST PI Gary Green Lead Engineer Mike Dolezal Software Engineer Dean Reed Hardware Engineer Eugenio Diaz Graduate Research Associate Andrew Houchin VTT ESS Self