《老外提供的PPT模板Mocnik.ppt》由会员分享，可在线阅读，更多相关《老外提供的PPT模板Mocnik.ppt（23页珍藏版）》请在三一办公上搜索。
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-5491Fax:(586)574-5008,RDECOM TARDECVetronics Technology Area(AMSTA-TR-R,Mailstop 264W
2、arren,MI 48397-5000,11 June 2003,2,IntroductionVetronics Technology Test bed(VTT)Crew integration and Automation Test bed(CAT)/Robotic Follower(RF)OverviewUnmanned Combat Demonstration(UCD)OverviewEmbedded Simulation System OverviewLessons LearnedSchedule and RequirementsESS Process OverviewDistribu
3、ted ControlInter-process CommunicationsUnmanned Ground Vehicle(UGV)ProcessReconnaissance,Surveillance,Target Acquisition(RSTA)and Automatic Target Recognition(ATR)Image GenerationScenario DevelopmentTerrain Database DevelopmentHardware ImplementationConclusion,Agenda,3,Introduction,The Embedded Simu
4、lation 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
5、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 capability of ground combat vehicle systems.Approach:Develop,integrate and field test
6、advanced Vetronics technology for ground combat vehicles.Advanced Crew Station InterfaceIndirect Vision DrivingMulti-function DisplaysSpeech Recognition3-D AudioAdvanced Electronics ArchitectureEmbedded Simulation SystemModified M2A0 Bradley Fighting Vehicle used as test platform.,6,Crew integration
7、 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 in
8、clude:Robotic Mission Planning and ControlRobotic Assisted DrivingDecision AidsRSTA ControlProve 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.,7,Roboti
9、c Follower(RF),Goal:Develop,integrate and demonstrate the technologies required to achieve unmanned follower capabilities for future land combat vehiclesKey Requirements:Dismounted or Mounted Following.Semi-autonomous perception.Significant separation times and distances.Map data and sensor terrain
10、feature registration.Road detectionOn-coming traffic detection.H/W&S/W design based on Demo III.Chassis:Stryker representative of FCS mounted systems.XUV representative of mule system,8,Demonstrating:1:1 Operator to ARV Control ARV Engagement,LSI Unmanned Combat Demo(UCD),ARV-2,Demo III XUV,Targets,
11、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 Platform Mobility(16T)Semi Autonomous Nav Simulated Objective Capability Turret/Weapons RSTA,Surrogate Platform Mobility(2.5T)Semi-Aut
12、onomous Nav Simulated Objective Capability Turret/Weapons RSTA,Surrogate Platform Mobility Semi-Autonomous Nav 2 Crew Stations C2,9,Embedded Simulation System(ESS),Vehicle and crew interaction data,Embedded Simulation System,Crew Stations,FCS Class Vehicle,Simulated Turret Virtual Lethality Virtual
13、Sensors Simulated ATR Simulated ATT Simulated C2,SIMULATION BASED ACQUISITION,VEHICLE SIMULATIONS,MobilitySurvivabilityVirtual OPFORVirtual Friendlies,OPERATIONAL APPLICATIONS,Battlefield VisualizationTerrain RegistrationVirtual Sensor CoverageVirtual Lethality Coverage,MISSION APPLICATIONS,Embedded
14、 TrainingMission RehearsalMission Planning,10,CAT/RF and UCD Simulation Lessons Learned,11,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
15、 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 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 simu
16、lation 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 customers needs.Basis for system design.,12,Schedule and Requirements Specification,Firm requirements were difficult t
17、o 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,t
18、hough 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 requiremen
19、ts as early in the development process as is possible.This will allow for more effective use of the available time.,13,Processes 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
20、 to incorporate new functionalityInter-process communications performed through PIU Comm Object.,ESS Process Overview,14,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 sta
21、tions.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 e
22、ye-points for example.,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
23、crew station at any time.,15,ESS Inter-Process Communications,The PIU Comm Object was an effective tool for managing inter-process communications.Proven and well understood.Code Reused from VTT programHowever,an extra“layer”of management is needed at the A-kit/B-Kit interface level.Lesson Learned:Al
24、lowing 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.,16,ESS UGV Process,UGV Process Instantiates a UGV object for each UGV
25、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).,UGV Object controls the virtual UGVsInterprets UGV Mission Plan
26、sControls 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.,17,ESS UV Process,Lesson Learned:UGV process performed very well.It was also an object based design instead of functional based des
27、ign 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.,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
28、Modeling Language to identify,describe,and model system components and behavior,18,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 architect
29、ure 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.,RSTA SimServer,UGV Sim 1,UGV Sim 2,UGV Sim N,RSTA SimClient,RSTA SimClient,RSTA SimClient,RSTA SimServer,RSTA SimServ
30、er,Current RSTA Configuration,Future RSTA Configuration,19,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 envi
31、ronment.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.,Current IG Configuration,Future I
32、G Configuration,20,Scenario Development,CAT and UCD employed one master 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 f
33、actors:Subject matter experts design the vignettes.A difficult 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
34、on digital terrain database.Lesson Learned:Scenario development 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
35、 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
36、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 databa
37、se,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 dont have a simulation.Therefore,the appropriate amount of time should also be budgeted for this activit
38、y.,22,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 temperature
39、s 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 shu
40、tting down the ESS erroneously.Lesson Learned:Will investigate reducing size of box.Hyper-threading is a possibility.This would allow micro-atx boards to be used.Dual video outputs from one graphics card.Will performing trade study to investigate Non-COTS alternatives,23,Conclusion,The Embedded Simu
41、lation Team and DCS Corp.successfully developed an embedded simulation system to support both the CAT/RF program and the LSIs 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 produc
42、t.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.,
