15413 - Software Engineering

transcript

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

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

UI Specifications

Passive viewer, active pilot interfaceDistributed HLA objects

Environment Multiple Flyers

Swappable and extendable (strict adherence to an API)

Class Associations

RTIamb

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

MakeNewFlyer()

registerObjectInstancediscoverObjectInstance

Creating Flyer

UI Control

Destroying Flyer

DestroyFlyer()

deleteObjectInstanceremoveObjectInstance

UI Control

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)

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,

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.

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

FederateClient 1

TCP/IPmessageexchange

TCP/IP

TCP/IPAPI

ITP-TCP/IP TCP/IPAPI

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.

15413 - Software Engineering

Documents