1 / 66

15413 - Software Engineering

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

cyrah
Download Presentation

15413 - Software Engineering

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Wright FlyerSoftware Engineering

  3. Introduction and Overview • What are we doing? • How we are doing it? • Why are we doing it that way?

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

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

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

  7. Wright FlyerStructure

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

  9. 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).

  10. Non-Functional Requirements • Design for later re-use. • Design for maintainable testability. • Design for re-use of others’ code. • Conforming to all HLA requirements

  11. Wright FlyerSoftware Engineering

  12. Live Participants Simulations Live Player Interfaces Support Utilities Interface Runtime Infrastructure Federation Management Declaration Management Object Management Ownership Management Time Management Data Distribution Management Functional View of the HLA Architecture

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

  14. Network Configuration • Network Configuration • Netbar (on-demand hot-swappable internet service via ethernet) • DHCP

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

  16. Design Process • Simplification of FEDEP • Requirements • Specifications (UML) • SOM/FOM • OMDT Usage • Prototype 1 (HLA designed) • “Exploratory” • Prototype 2 • “Evolutionary” • Formal Test Suite

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

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

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

  20. Declaration Management Services • Used the full range of declaration management services • Attribute Publication/Subscription • Interaction Publication/Subscription

  21. Object Management Services • Registering, Discovering, and Deleting Flyer instances • Updating/Reflecting • Interactions • simply send/receive

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

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

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

  25. Wright FlyerSoftware Engineering

  26. UI Specifications • Passive viewer, active pilot interface • Distributed HLA objects • Environment • Multiple Flyers • Swappable and extendable (strict adherence to an API)

  27. Class Associations RTI FlyerView Environment Cache UIamb FlyerStatus RTIamb Dialogs Menus Toolbars

  28. UI/HLA communications

  29. Creating Flyer RTI UI Control MakeNewFlyer() Flyer discoverObjectInstance registerObjectInstance

  30. Destroying Flyer RTI UI Control DestroyFlyer() Flyer removeObjectInstance deleteObjectInstance

  31. Controlling a Flyer RTI UI Control MoveHipSaddle() Flyer reflectAttributeValues updateAttributeValues

  32. UI/HLA comms (cont.)

  33. UI Technical Challenges • Dealing with multiple flyers • Ensuring a one-to-one relationship from pilot to flyer • Defining our views in a general manner

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

  35. Spot Flyer View

  36. View Parameters Wingman view: lookAt relative to Flyer, lookFrom relative to Flyer Pilot view: lookAt relative to Flyer, lookFrom relative to Flyer Spot view: lookAt relative to Flyer, lookFrom relative to Ground Constant view: lookAt relative to Ground, lookFrom relative to Ground

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

  38. Wright FlyerSoftware Engineering

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

  40. WFFederate RTI:RTIambassador Flyer WF Fed Ambassador FlightState Component ControlObject Engine WCR PhysicalPilot HipSaddle CanardControl Control Class Hierarchy

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

  42. Wright Flyer Physical Layout Flyer Hierarchy Rudder Assembly Canard Assembly Wing Assemblies Rudders Canards Wings

  43. 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.)

More Related