老外提供的PPT模板Mocnik

1、1,CAT/RF Simulation Lessons Learned,Intelligent Vehicle Systems Symposium,Christopher Mocnik,Embedded Simulation Team,Tank-Automotive Research, Development & Engineering Center,UNCLASSIFIED,Email: (586) 574-5491/DSN 786-5491 Fax: (586) 574-5008,RDECOM TARDEC Vetronics Technolog

2、y Area (AMSTA-TR-R, Mailstop 264 Warren, MI 48397-5000,11 June 2003,2,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 Sched

3、ule 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

4、Implementation Conclusion,Agenda,3,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 L

5、ead 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.,4,Background Information,5,Vetronics Technology Test bed (VTT),Goal: Improve the war fighting capabilit

6、y 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

7、 System Modified M2A0 Bradley Fighting Vehicle used as test platform.,6,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 technologie

8、s 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

9、 Variant (ICV) or Stryker. Enhanced ESS to support Robotic planning and control, and RSTA operation.,7,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 Mo

10、unted 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 mul

11、e system,8,Demonstrating: 1:1 Operator to ARV Control ARV Engagement,LSI Unmanned Combat Demo (UCD),ARV-2,Demo III XUV,Targets,Simulated targets for Maneuver,Real targets for Live-Fire,ARV-1,RF ATD (w/ COUGAR turret),Control Vehicle (CV),CAT ATD,RSTA and,Engagement,RSTA and,Engagement,Surrogate Plat

12、form Mobility (16T) Semi Autonomous Nav Simulated Objective Capability Turret/Weapons RSTA,Surrogate Platform Mobility (2.5T) Semi-Autonomous Nav Simulated Objective Capability Turret/Weapons RSTA,Surrogate Platform Mobility Semi-Autonomous Nav 2 Crew Stations C2,9,Embedded Simulation System (ESS),V

13、ehicle and crew interaction data,Embedded Simulation System,Crew Stations,FCS Class Vehicle,Simulated Turret Virtual Lethality Virtual Sensors Simulated ATR Simulated ATT Simulated C2,SIMULATION BASED ACQUISITION,VEHICLE SIMULATIONS,Mobility Survivability Virtual OPFOR Virtual Friendlies,OPERATIONAL

14、 APPLICATIONS,Battlefield Visualization Terrain Registration Virtual Sensor Coverage Virtual Lethality Coverage,MISSION APPLICATIONS,Embedded Training Mission Rehearsal Mission Planning,10,CAT/RF and UCD Simulation Lessons Learned,11,Schedule and Requirements Specification,Schedule: In a perfect wor

15、ld, appropriate development time should be allocated in the program schedule to adequately design, develop, and fully test systems in order to meet the customers needs. The CAT/RF ATD was originally a two year development effort. However, in order to support the FCS program and meet the FCS mileston

16、e 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 soft

17、ware engineering process. Captures the customers needs. Basis for system design.,12,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

18、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 “creepi

19、ng” 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.,13,Proces

20、ses functionally partitioned by the service they provide. VTT code reused to largest extent possible, with new processes for UGV and RSTA control added. Reused processes modified to incorporate new functionality Inter-process communications performed through PIU Comm Object.,ESS Process Overview,14,

21、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 w

22、ith 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.,Lesson Learned: A more flexible software architecture will be needed to be less dependant o

23、n 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.,15,ESS Inter-Process Communications,The PIU Comm Object was an effective tool for ma

24、naging inter-process communications. Proven and well understood. Code Reused from VTT program However, an extra “layer” of management is needed at the A-kit/B-Kit interface level. Lesson Learned: Allowing each process to write directly to a common shared memory area with the vehicle will eliminate t

25、he need for an extra layer of management. Will perform trade analysis on the impact of moving to the WSTAWG OE for this purpose.,16,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 Obje

26、ct parses incoming UGV mission plans from the vehicle. (Communicates directly with vehicle via its own socket connection, not through PIU).,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 w

27、here in each functional object is instantiated. Passes data to each object.,17,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 th

28、is design philosophy with the inclusion of UAVs.,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,18,E

29、SS 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

30、performance. Will investigate a trade of dedicated servers and clients versus available video channels.,RSTA Sim Server,UGV Sim 1,UGV Sim 2,UGV Sim N,RSTA Sim Client,RSTA Sim Client,RSTA Sim Client,RSTA Sim Server,RSTA Sim Server,Current RSTA Configuration,Future RSTA Configuration,19,ESS Image Gene

31、ration 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 wo

32、uld 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.,Current IG Configuration,Future IG Configuration,20,Scenario Development,CAT and UCD employed one m

33、aster scenario that was adjusted as needed for a particular experiment. Originally the intent was to develop a series of scenarios with each exercising a different facet of the FCS scout mission.,Lengthy process involving a number of factors: Subject matter experts design the vignettes. A difficult

34、task as no one has experience with an FCS soldier/robot team in combat. Vignettes approved by the user community. SAF users convert vignettes into digital scenarios. IG users run through the scenario from different points of view. Dependent on digital terrain database. Lesson Learned: Scenario devel

35、opment is more time consuming than one would think. Enough time should be budgeted for the process.,21,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

36、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

37、 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 i

38、n 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 dont have a simulation. Therefore, the appropriate amount of time should also be budgeted for this activity.,22,ESS Hardware Architecture,ESS

39、 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