Extending Training Capability Through The Use of Embedded Domain-Specific Languages in Training Devi...
This presentation is the property of its rightful owner.
Sponsored Links
1 / 24

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


  • 84 Views
  • Uploaded on
  • Presentation posted in: General

Extending Training Capability Through The Use of Embedded Domain-Specific Languages in Training Devices. John Aughey. 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

Download Presentation

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

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Extending training capability through the use of embedded domain specific languages in training devices

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

John Aughey


Point of this discussion

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


Typical flight training simulator

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


System of systems

System of Systems

Collaboration of many systems


Examples of embedded domain specific languages

Examples of embedded domain-specific languages

Internet Browsers

3-D Modeling

Interactive Content

Spreadsheets


Available scripting languages

Ruby

Perl

Python

ECMAScript

LUA

Smalltalk

Tcl

Ch

RBScript

Guile

Available Scripting Languages

Don’t reinvent the wheel!


Exposed interface

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…


How to embed

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.


Life cycle of embedded dsl

Life cycle of Embedded DSL

  • Improved Requirements Definition

  • Automated Testing

  • Rapid Integration

  • Simplified User Interfaces

  • Extendable Software


Requirements definition

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” {

    …………………

    }

    }


Extending training capability through the use of embedded domain specific languages in training devices

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”

}

}


Conceptual vs functional requirements

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


Example

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


Implementation

Implementation

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


Next software update

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.


Discovered problem

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.


Next software update1

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.


Dsl solution

DSL Solution

  • Expose the following failure triggers to the scripting language

    • Engine fire

    • Loss of rudder control

    • COMM failure

    • HUD failure


Operator program

Operator Program

description “Fail the rudder 10 seconds after wheels-up”

trigger :action => { Failures.trigger :rudder },

:when => { wheels_up_time > 10 }


Engine fire program

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 }


Simplified extendable user interfaces

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


Spot meter lab software

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


Customer extendable software

Customer Extendable Software


  • Login