15413 - Software Engineering
Introduction - Andrew GallantOverview requirements - Stephen UlrichArchitectural Design & Hardware - Jeremy DegroatDesign
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 FlyerSoftware 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 destructionStill an amazing piece of aeronautical
engineering605lbs; 40ft x 20ft x 8ft; 586 ft2 foil
surface Wind tunnel testing for their airfoils
Wright FlyerStructure
Functional Requirements
Simulate the historical flightsDisplay various pieces of flight
informationShow flights from various points of
viewAllow a human pilotRecord 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 FlyerSoftware Engineering
Functional View of the HLA Architecture
LiveParticipants
Support Utilities
Interface
Live PlayerInterfaces
Runtime Infrastructure
Simulations
Federation Management Declaration ManagementObject Management Ownership ManagementTime 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.3Tools
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.
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.
Federate Rules
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/SubscriptionInteraction Publication/Subscription
Object Management Services
Registering, Discovering, and Deleting Flyer instances
Updating/ReflectingInteractions
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 FlyerSoftware Engineering
UI Specifications
Passive viewer, active pilot interfaceDistributed HLA objects
Environment Multiple Flyers
Swappable and extendable (strict adherence to an API)
RTI
Class Associations
RTIamb
UIamb
FlyerStatus
EnvironmentCache
FlyerView
DialogsMenus
Toolbars
•UI/HLA communications
Task HLA callRequesting FlyerCreation, Deletion
MakeNewFlyer(),DestroyFlyer()
Discovering FlyerCreation, Deletion
discoverObjectInstance,deleteObjectInstance
Controlling Flyer MoveHipSaddle(),MoveCanardControl()
UI Control
RTI
Flyer
MakeNewFlyer()
registerObjectInstancediscoverObjectInstance
Creating Flyer
UI Control
RTI
Flyer
Destroying Flyer
DestroyFlyer()
deleteObjectInstanceremoveObjectInstance
UI Control
RTI
Flyer
MoveHipSaddle()
updateAttributeValuesreflectAttributeValues
Controlling a Flyer
•UI/HLA comms (cont.)
Task HLA callSelect Environment GetFileList(), ChooseFile(),
UseRandom...()
Recording a script StartRecording(),StopRecording()
Playing back a script StartPlayback()
Regain Flyer control fromscript
RelinquishFlyerControl(),FlyerControlRelinquished()
UI Technical Challenges
Dealing with multiple flyersEnsuring a one-to-one relationship
from pilot to flyerDefining 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
Pilot view:lookAt relative to Flyer,lookFrom relative to Flyer
Constant view:lookAt relative to Ground,lookFrom relative to Ground
Wingman view:lookAt relative to Flyer,lookFrom relative to Flyer
Spot view:lookAt relative to Flyer,lookFrom relative to Ground
Other Views
Debug view:For internal debugging info,with logging levels
Radar View (not shown):lookAt relative to Ground,lookFrom relative to Ground(just really high up)
Wright FlyerSoftware 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
WFFederate
RTI:RTIambassador Flyer WF Fed Ambassador
FlightState Component ControlObject
Engine WCR PhysicalPilot HipSaddle CanardControl
Control Class Hierarchy
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 Wing Assemblies
Rudders Canards 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 dataScripts
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 FlyerSoftware 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
RTImessageexchange
RTI BUS
RTIAPI
ITP-RTIRTIAPI
ITP Communicationnetwork environment (Netbar - dynamic IP)
Integrated UI
FederateClient N
ITP
FederateClient 1
TCP/IPmessageexchange
TCP/IP
TCP/IPAPI
ITP-TCP/IP TCP/IPAPI
Wright FlyerSoftware 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 EducationProgrammer’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.
