Transcript Wright Flyer Presentation

15413 - Software
Engineering
Introduction - Andrew Gallant
Overview requirements - Stephen Ulrich
Architectural Design & Hardware - Jeremy Degroat
Design
User Interface - Christopher Quirk
Wings, Canard, Rudder and Controls - Ranjit Jose
Environment - Yimin Yang
Interactive Test Program - Danny Lee
Results & lessons learned - Shane Torsell
Wright Flyer
Software Engineering
Introduction and Overview
What are we doing?
How we are doing it?
Why are we doing it that way?
Wright Flyer Project Goals
An interactive, graphical simulation of the
Wright Flyer.
A distributed HLA simulation.
Contextualize Software Engineering
through completion of the first spiral of a
major software project’s development.
Why the Wright Flyer
Project?
HLA was chosen to give the class
experience working with a professionally
developed and documented system.
Parallels projects to produce replicas for
centennial anniversary (AIAA in LA).
A project of sufficient scale to be
instructive in Software Engineering
principles
About the Wright Flyer
The first successful self-propelled,
heavier-than-air aircraft
Three flights before its destruction
Still an amazing piece of aeronautical
engineering
605lbs; 40ft x 20ft x 8ft; 586 ft2 foil
surface
Wind tunnel testing for their airfoils
Wright Flyer
Structure
Functional Requirements
Simulate the historical flights
Display various pieces of flight
information
Show flights from various points of view
Allow a human pilot
Record and playback simulated flights
“Soft” real time performance
Extensibility Requirements
Modular UI interface coding, for future
revisions or replacements.
Allow for multiple flyers, with collision
detection.
Later inclusion of wind tunnel test data.
Landing and take-off capabilities.
Plug and Play pilots (AI, human, script).
Non-Functional
Requirements
Design for later re-use.
Design for maintainable testability.
Design for re-use of others’ code.
Conforming to all HLA requirements
Wright Flyer
Software Engineering
Functional View of the
HLA Architecture
Live
Participants
Support
Utilities
Simulations
Live Player
Interfaces
Interface
Runtime Infrastructure
Federation Management
Declaration Management
Object Management
Ownership Management
Time Management
Data Distribution Management
Hardware Configuration
 Multiple machines with the following specifications:
Intel Pentium II 450 MHz
128 MB RAM
6 GB hard drive
ATI 3D Rage Pro
3Com Fast Etherlink XL 10/100
Apple Multiple Scan 17” monitor
Window NT 4.0 Workstation
Network Configuration
 Network Configuration
Netbar (on-demand hot-swappable internet service
via ethernet)
DHCP
HLA Version and Tools
RTI 1.3v6 (originally 1.3v5)
Based code on IF Spec. 1.3
Tools
OMDT
FMT/FVT/DCT
FEPW (Events)
Rational Rose Case Tool
Design Process
 Simplification of FEDEP
Requirements
Specifications (UML)
SOM/FOM
 OMDT Usage
 Prototype 1 (HLA designed)
“Exploratory”
 Prototype 2
“Evolutionary”
 Formal Test Suite
Federation Rules
 Rule 1: Must have an HLA Federation Object Model
(FOM)
 Rule 2: All object representation must be in the
federates, not in the runtime infrastructure (RTI).
 Rule 3: All exchange of FOM data among federates must
occur via the RTI.
 Rule 4: Federates must interact with the RTI in
accordance with the HLA interface specification.
 Rule 5: An attribute of an instance of an object must be
owned by only one federate at any given time.
Federate Rules
 Rule 6: Have an HLA Simulation Object Model (SOM).
 Rules 7: Be able to update/reflect any attributes of
objects in their SOM and send/receive SOM object
interactions.
 Rule 8: Be able to transfer/accept ownership of
attributes dynamically.
 Rule 9: Be able to vary the conditions under which they
provide updates of attributes of objects.
 Rule 10: Be able to manage local time in a way which
will allow them to coordinate data exchange with other
members of a federation.
Federation Management
Services
Federation Life Cycle functionality
create/destroy
join/resign
Federation Synchronization
Pause/Unpause (eventually)
Did not use Save/Restore functionality
Rumored save/restore failures in 1.3v5
Declaration Management
Services
Used the full range of declaration
management services
Attribute Publication/Subscription
Interaction Publication/Subscription
Object Management
Services
Registering, Discovering, and Deleting
Flyer instances
Updating/Reflecting
Interactions
simply send/receive
Ownership Management
Services
Ownership of the Pilot attribute can be
passed between multiple UI’s or Scripts to
allow various testing and manipulation.
Most other ownership situations resolved
by way of interactions.
Time Management
Services
Deemed non-critical.
RTI bus well-managed enough to handle our
requirements.
Close enough to real-time.
An early extension, however.
Handled play-back from the scripts group.
Data Distribution
Management
Was not used for the sake of simplicity.
Instead, use of Pilot and Flyer ids
instantiated.
Would be applied for any further work, to
reduce ambassador “spamming”.
Wright Flyer
Software Engineering
UI Specifications
Passive viewer, active pilot interface
Distributed HLA objects
Environment
Multiple Flyers
Swappable and extendable (strict
adherence to an API)
Class Associations
Environment
Cache
UIamb
FlyerView
FlyerStatus
RTI
Dialogs
Menus
Toolbars
RTIamb
•UI/HLA communications
Task
HLA call
Requesting Flyer
Creation, Deletion
Discovering Flyer
Creation, Deletion
Controlling Flyer
MakeNewFlyer(),
DestroyFlyer()
discoverObjectInstance,
deleteObjectInstance
MoveHipSaddle(),
MoveCanardControl()
Creating Flyer
RTI
MakeNewFlyer()
discoverObjectInstance
UI
registerObjectInstance
Flyer
Control
Destroying Flyer
RTI
DestroyFlyer()
UI
removeObjectInstance
Flyer
Control
deleteObjectInstance
Controlling a Flyer
RTI
MoveHipSaddle()
UI
Control
reflectAttributeValues
Flyer
updateAttributeValues
•UI/HLA comms (cont.)
Task
HLA call
Select Environment
GetFileList(), ChooseFile(),
UseRandom...()
Recording a script
StartRecording(),
StopRecording()
Playing back a script
StartPlayback()
Regain Flyer control from
script
RelinquishFlyerControl(),
FlyerControlRelinquished()
UI Technical Challenges
Dealing with multiple flyers
Ensuring a one-to-one relationship from
pilot to flyer
Defining our views in a general manner
Where we are
Things that work now:
Creating, joining, resigning, destroying
FedEx.
Requesting creation, destruction of a flyer
Notification of flyer creation, destruction
Controlling flyer
Reflecting position/orientation updates
Spot Flyer View
View Parameters
Wingman view:
lookAt relative to Flyer,
lookFrom relative to Flyer
Spot view:
lookAt relative to Flyer,
lookFrom relative to Ground
Pilot view:
lookAt relative to Flyer,
lookFrom relative to Flyer
Constant view:
lookAt relative to Ground,
lookFrom relative to Ground
Other Views
Radar View (not shown):
lookAt relative to Ground,
lookFrom relative to Ground
(just really high up)
Debug view:
For internal debugging info,
with logging levels
Wright Flyer
Software Engineering
Control Interactions
UI Interaction
Creation and Destruction of the Flyer.
Control of Hip Saddle and Canard Control.
Flyer Movement Calculations
Calculates movement of entire Flyer from pieces.
Environment
Request environment information
Wind, Air Pressure, Temperature, Elevation
Published Attributes
Flight State
Control Class Hierarchy
WFFederate
RTI:RTIambassador
FlightState
Engine
WCR
Flyer
WF Fed Ambassador
Component
PhysicalPilot
ControlObject
HipSaddle
CanardControl
Wing/Canard/Rudder Group
Simulate Individual Flyer Pieces
No direct HLA involvement.
Passive, methods called by Control Group.
Objects We Simulate
Airfoils
Engine
Physical Pilot
Strict Hierarchy of Parts
Assemblies to contain related airfoils.
Wright Flyer Physical Layout
Flyer Hierarchy
Rudder Assembly
Canard Assembly
Rudders
Canards
Wing Assemblies
Wings
Physical Simulation
Airfoil Lift/Drag Simulation
Simulated by the use of Force Vectors.
Based on historically valid equations using angle of
attack.
Lack of data forces some estimation of physical
constants.
Engine/Physical Pilot Simulation
Simple Lift and Drag calculations.
Simulation of Other Pieces of Flyer
Lift and Drag not simulated (control wires, structure,
etc.)
15-413 Software
Engineering
Responsibilities
Environment
Generate, maintain and publish the map data
Generate, maintain and publish the weather
data
Scripts
Provide mechanisms to record and playback
a given simulation
Environment
Map Data
Provide an elevation map representing the
simulation area.
Provide terrain features that appear in the
simulation area.
Weather Data
Provide predefined and randomly
generated wind, temperature, precipitation,
and pressure for the simulation.
Scripts
Record/Playback
Record the user control inputs, and weather
changes during the simulation.
Playback the recorded user control inputs,
and weather changes.
Wright Flyer
Software Engineering
Interactive Test Program (ITP)
 Fulfills requirement to design for maintainability
& testability
 Complements DMSO provided tools
 Allows easy execution of federation
 Captures data in distributed environment
(generic tool)
 Provides centralized debugging information store
 Customizes data display for special purposes
 Operates independently of RTI (minimal
interference)
 Allows automatic regression test with
scripting/replay
ITP Communication
network environment (Netbar - dynamic IP)
ITP
Integrated UI
TCP/IP
message
exchange
ITP-TCP/IP
TCP/IP
RTI
message
exchange
TCP/IP Federate RTI
API Client 1 API
TCP/IP Federate RTI
API Client N API
ITP-RTI
RTI BUS
Wright Flyer
Software Engineering
Results
Prototype I
Communication between federates on
different machines over the LAN by sending
interactions.
Prototype II
Object instantiation and registration with
attribute updates and reflections.
3D Wright Flyer model simulation using
OpenGL calls.
Results (cont.)
Network Performance
RTI 1.3v6 performed well in a slow network
~5,000 interactions sent & received per sec.
4 of the 6 services were used.
Results (cont.)
Code Freeze on 4/28/99 at 10 pm
Each federate working individually
Integration of UI and Control
Environment still external
ITP
Wright Flyer flying
Lessons Learned
Technical/HLA
Identical Configurations on participating
machines.
Same .fed and .rid files.
Same RTI_MESSAGE_VERSION and RTI versions.
HLA Education
Programmer’s Guide (General overview)
Interface Specifications (Services specifications)
HLA C++ API (Services details)
Lessons Learned (cont.)
Prototypes, Prototypes, & Prototypes.
Using prototypes to understand and explore
the capabilities of HLA.
Problematic issues identified early on.
More accurate estimate metrics on time
delivery.
Stepping stone (Prototype II) for final
system.
Prototype I should have been implemented
much earlier in the class.
Lessons Learned (cont.)
HLA specialists were clearly needed, but it
probably would have been better to have
integrated the HLA and Architecture teams.
Where federates were developed by more than
one team, communication and functionality
partitioning was not obvious.
Design issues needed to be surfaced and resolved
more quickly.
The Wright Flyer consists of WCR & Controls groups.
Inter-group communication is very important.