Extending Training Capability Through The Use of Embedded Domain-Specific Languages in Training Devices

1. Extending Training Capability Through The Use of Embedded Domain-Specific Languages in Training Devices John Aughey

2. Point of this discussion • Incorporate a scripting language into all software • Leverage that embedded scripting language during development • Expose that language to the end user • Allow end users to use this language to extend and enhance usability

3. Interface Interface Interface Interface Internal Interfaces Interface Interface Typical Flight Training Simulator Instructor/Operator Station Crew Station Real-Time Host Tactical Environment Threat Stations Brief/Debrief System Visual System

4. System of Systems Collaboration of many systems

5. Examples of embedded domain-specific languages Internet Browsers 3-D Modeling Interactive Content Spreadsheets

7. Ruby Perl Python ECMAScript LUA Smalltalk Tcl Ch RBScript Guile Available Scripting Languages Don’t reinvent the wheel!

8. Exposed Interface Readable, approachable language • aircraft.digital_inputs[FLAPS] = 2; • threat_environment->addThreat(new ThreatAircraft(MIG_29, aircraft.altitude, position_offset(aircraft.latitude,aircraft.longitude,aircraft.bearing,3*MILES_TO_FEET))); • aircraft.extend_flaps • create_threat “MIG29”, :distance => 3.miles In contrast to…

9. Frame-based Top-of-loop SCRIPT(begin) Computation SCRIPT(end) Loop Event Based Mouse Clicks Button Presses Weapons Launch Entity Damage Entity Interaction How to Embed Application includes “hooks” where the scripting language can control the application.

10. Life cycle of Embedded DSL • Improved Requirements Definition • Automated Testing • Rapid Integration • Simplified User Interfaces • Extendable Software

11. Requirements Definition • The gear shall not extend above 10,000 feet DSL specification context “The aircraft above 10,000 feet” { setup { ………………… } specify “should not allow gear to extend” { ………………… } }

12. context “The aircraft above 10,000 feet" { setup { initial_conditions :altitude => 10000.feet } specify “should not allow gear to extend" { aircraft.lower_gear aircraft.gear_should_be “up” } specify “should not allow flaps to extend" { aircraft.extend_flaps aircraft.flaps_should_be “retracted” } }

13. Conceptual vs Functional Requirements • Functional Requirements have a measurable behavior • Conceptual Requirements are difficult to define concretely • User Interface Interaction • Incomplete Understanding of use case • Results in over defined or ill-defined requirements

14. Example • The operator software must provide a way to induce the following failure conditions: • Engine fire • Loss of rudder control • COMM failure • HUD failure • Defined by curriculum

15. Implementation Provide the operator a menu with a list of these failures, and a button to induce the selected failure

16. Next software update • New requirement • Define a conditional value into the failure menu to avoid needing to monitor the altitude indicator manually. Other failures might need different conditionals for altitude, airspeed, orientation, flight time, and so on. • All of these different possible conditions are added to the requirement in lengthy detail.

17. Discovered problem In practice, however, the operator soon discovers the failure event triggers too fast, because the instant the altitude hits 20,000 feet, the engine fire failure triggers. The training need is really engine failure at level flight, so the failure really needs to happen as a result of two conditions being met, a given altitude and a given rate of climb.

18. Next software update • New Requirement • All failure conditions must have an operator defined conditional statement. Once the entire conditional statement is satisfied, the failure will occur. At least 10 different conditional statements must be definable by the operator for each failure condition with the option to chain the statements together with AND or OR logic operators. At least 16 failure conditions can be ready to be triggered at any point in the training scenario.

19. DSL Solution • Expose the following failure triggers to the scripting language • Engine fire • Loss of rudder control • COMM failure • HUD failure

20. Operator Program description “Fail the rudder 10 seconds after wheels-up” trigger :action => { Failures.trigger :rudder }, :when => { wheels_up_time > 10 }

21. Engine Fire Program description “Trigger an engine fire once the aircraft reaches 20000 feet” trigger :action => { Failures.trigger :engine_fire_left }, :when => { altitude > 20000.feet and rate_of_climb < 10.feet.per.second }

22. Simplified/Extendable User Interfaces Push “decision making” out to the scripting language • Native code • Processor intensive computation • Graphics/Rendering • Device interaction • Scripting code • What, where, when, why

23. Spot Meter Lab Software when_created do open_log_file "gammameasurements" set_intensity 0 set_time_of_day “midnight” set_test_pattern "rectangle" set_testpattern_size 4.0 drop_readings 20 end for_each_reading do write_log intensity,measured_intensity increment_intensity_by 4 drop_readings 4 end

24. Customer Extendable Software