Virtual Prototyping with SPEED

Transcription

1 Virtual Prototyping with SPEED Peter Mantica, Chris Lietzke, Jeramiah Zimmermann, Charlie Woodhouse, Dennis Jones ITT Industries Advanced Engineering and Sciences Division

2 Report Documentation Page Form Approved OMB No Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington VA Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number. 1. REPORT DATE 01 OCT TITLE AND SUBTITLE 2. REPORT TYPE N/A 3. DATES COVERED - 5a. CONTRACT NUMBER 5b. GRANT NUMBER 5c. PROGRAM ELEMENT NUMBER 6. AUTHOR(S) 5d. PROJECT NUMBER 5e. TASK NUMBER 5f. WORK UNIT NUMBER 7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) ITT Industries Advanced Engineering and Sciences Division 8. PERFORMING ORGANIZATION REPORT NUMBER 9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR S ACRONYM(S) 12. DISTRIBUTION/AVAILABILITY STATEMENT Approved for public release, distribution unlimited 11. SPONSOR/MONITOR S REPORT NUMBER(S) 13. SUPPLEMENTARY NOTES See also ADM001851, Proceedings of the 2003 Joint Service Scientific Conference on Chemical & Biological Defense Research, November 2003., The original document contains color images. 14. ABSTRACT 15. SUBJECT TERMS 16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF ABSTRACT UU a. REPORT unclassified b. ABSTRACT unclassified c. THIS PAGE unclassified 18. NUMBER OF PAGES 18 19a. NAME OF RESPONSIBLE PERSON Standard Form 298 (Rev. 8-98) Prescribed by ANSI Std Z39-18

3 A Virtual Prototyping System Supports All Phases of the Product Development Cycle Requirements Analysis Concept Development Baseline Design Requirements Trade Studies PDR Requirements CAIV Trade Optimization Validation of design performance CDR Design Validation Final Design HIL testing Subassembly Build & Test Performance Models and Baseline Algorithms Enable a System Concept to be Developed and System Requirements to be Allocated System Performance is Continuously Updated with Higher Fidelity Models. SPS Validation Troubleshooting Troubleshooting Troubleshooting Troubleshooting Mission Planning Subassembly Integration Test Delivery Refurbish & Test Spacecraft Integration On-orbit support Data Trending Optimal Scenario Development SPS Validation SPS Validation Accuracy of Detailed Simulation is Validated During System Test Operational Performance is Monitored and Data Quality Ensured Through Detailed Simulations.

4 Integration of Hardware Models and Algorithms within a Virtual Prototyping System Enables Optimal System Development Information Needs Users Performance Cost Data Collection System Hardware Data Processing System Algorithms Effective Development and Use of an Integrated System Performance Testbed is the Only Method to Ensure Optimal System Development Enables Information Product Driven Development Facilitates Early Selection of Optimal Approach Facilitates in Quickly Lowering Program Risk and Cost

5 SPEED: A Virtual Prototyping System Consisting of Four Capabilities Integrated into a System Environment Hardware Models Scene Generation Simulation Environment Data Exploitation Performance Evaluation Each Capability Must be Addressed and Understood To Allow the Complete Evaluation of the End-to-End Performance of a Sensing System

6 The Object Management Environment is the Foundation of a Seamless Simulation Tools are built as modules contained in dynamic link libraries The entire System is represented by unique functional blocks The attributes of each module define its characteristics. OME provides the infrastructure for the ITT SPEED Toolbox - the System Engineer s tool for system performance evaluation

7 Scene Generation: Physics-based Environmental Modeling Our collection of radiance modeling tools provide the capability to produce accurate, high spectral and spatial resolution simulated radiance datasets We use a variety of environmental scene models and databases Transmission Transmission for various ranges We use fast forward monochromatic and band models as well as line by line high spectral resolution models Wavelength (um) 32000m 4000m 1000m 400m 200m 100m 20m We use the PNNL IR spectral library and HITRAN for gaseous absorption

8 Hardware Modeling: Performance Estimation from Initial Concept to Operations id Cd Detector Rd R3 Cf Rf - + Vout Interface to detailed descriptions of subsystem modules ensure fidelity at the system level. Our sensor models evolve as our design matures in order to provide the most accurate representation of sensor performance needed to support changing system engineering needs Input Blurred Jitter 1/f Noise Strict adherence to module interfaces allows for simple reuse and configuration control. The modular design of our sensor models allow for test points throughout the system.

9 Data Exploitation: Extracting Useful Information from the Data Online DIAL Observation Estimated Gas Concentration Length Offline DIAL Observation Data product algorithms are the bridge between user requirements and the engineering specifications of the data source

10 Performance Analysis and Evaluation: Closing the Loop to Lead to Improved Systems Threshold Margin (%) NEdN (mw/m^2/sr/cm-1) Hardware surface-650 and Cost Requirements/Constraints are Linked to System Performance Through Parametric Curves. 5% FAR 1% FAR 0.5% FAR 0.1% FAR Detailed evaluation of system simulation and test results provide the information feedback necessary to optimize system design Easy to Use Tools Allow Real-Time Analysis by Systems Engineers and Analysts Probability of Detection Agent Concentration Length (mg/m^2)

11 SPEED System Development Architecture is Grounded in Object-Oriented Oriented Design CSF, being based on C++, is intrinsically object-oriented. Object-oriented programming represents a different paradigm from conventional function programming. Object-oriented architectures are meant to do the following: Mimic the way a systems engineer may draw a block diagram of a system. Mimic the way the physical phenomena occur within the system. Object-oriented architectures encapsulate functionality. Interfaces between modules require strict definition. The method that a module uses to perform a task is not important; it is only important the inputs and outputs of the task be well-defined. An object-oriented module is called a class.

12 SPEED Supports Code Reuse Through its Hierarchical Architecture and Inheritance A hierarchical architecture, in the object-oriented sense, allows one to reuse code by allowing new modules to inherit the behaviors of high level modules. Filter Butterworth Filter A Booch diagram for Filters Bessel Filter For example, a filter has essentially the same code, no matter what type the filter is, except that the parameters may vary slightly, and the impulse response function will vary. A generic filter can be defined with these generic behaviors. A Butterworth or Bessel filter can then be made by overriding the impulse response function and adding a couple of new parameters; thus, the specialized filters inherit their general behavior from a base class.

13 SPEED Evolves and Matures With the Program to Best Support Program/Design Decisions CUSTOMER/USER REQUIREMENT Utility vs. Concept(s) Trades What ifs Utility vs. Design Trades Design Performance Utility vs. Scenarios As-Built Performance Concept/Design Development Detailed Design Build and Test PDR CDR Delivery SPEED I SPEED II SPEED III Pieces of the Puzzle Change to Increase Capability/ Meet Changing Needs over Time SPEED PROCESS Increasing Accuracy Increasing Fidelity

14 SPEED Can Integrate Multiple Execution Models Within Single Systems The execution model is the part of a simulation or model which dictates in what order simulation modules are run. This is an important task in object-oriented code. An event-based execution model allows execution of modules in order given by a global event calendar. Individual class instantiations (objects) are responsible for scheduling themselves to run at the appropriate times on the event calendar. An event-based execution model is similar to that used in SPICE, where a global time variable keys each component how to respond. A subject-observer model uses an intermediate container class to collect data and notify other classes when the data has been updated. Subject-observer architecture is similar to that supported in Khoros Cantata for digital image processing. Data flows from one process to the next.

15 Event-based Execution is Driven By Simulation Time and Priority Scheduled on the Event Calendar A global event calendar is kept with all modules and when to execute them. A class will schedule when it needs to run on startup of the simulation. Class Run in 5 sec Event Calendar The class can then schedule itself to run again as needed. This behavior is indicative of components which have a time constant or rate of response, such as electronic components. Class Run in 2 sec

16 Subject-Observer Execution is an Implementation of a Query/Update Model A class which executes on startup, an initializer, dumps output information into a container class. The container class then notifies all of its observers that new data is available The observers can then query to see if the available data is needed and request it if so desired. Initializer Container Class (Subject) Observer Observer Observer

17 CASE 2: Remote Sensing Product Simulator - A Realization of SPEED Architecture design allows for System development of active and passive, visible to infrared, ground or air based sensors product simulator Object-oriented design promotes code reuse and provides the plug-n-play capability process radiative tx scene generator receiver platform sensor product generator calibration performance evaluator statistical moments confidence intervals Well defined data interfaces allow seamless transfer of data between modules turbulence photon source optics geolocation speckle detector inversion source platform

18 Differential Absorption LIDAR Simulation Simulation of HF effluent plume at 4039 cm -1 gas absorption gas concen-length emissivity

19 Retrieval of HF Concentration Length using DIAL Online Return Truth HF Offline Return Estimated HF Water clouds