CSE Capstone Project

1. CSE Capstone Project Final Presentation

2. Honeywell Avionics Displays Group • Display Group • Located in Dear Valley • Program and support cockpit displays • Displays are responsible for reporting various important flight information • Altitude, Speed, Pitch, etc. • Project Managers • Malachi Nordine • Mohammed Islam

3. The Hardware • Two main components: • Display Unit (DU) – Displays flight information in 2-D graphics. • Advanced Graphics Module (AGM) – The graphics engine which uses OpenGL libraries to draw primitives to one or more displays.

4. Project Overview • The purpose • Create a remote testing tool for the new advanced graphics module (AGM-200). • Testing tool checks for consistency for all primitives drawn by AGM-200. • The approach • Set up a client-server network between a remote PC and the AGM-200. • Commands: • Draw an OpenGL primitive. • Retrieve corresponding CRC value.

5. System Level Overview

6. Documentation • Honeywell’s protocol for doing documentation: • Requirements: SRS (System Requirement Specification) • Design: SRDD (System Requirement Design Document) • Testing: Test Plan • Goal: • Lower levels of documentation trace back to higher levels of documentation for requirement verification • Test Plan test cases -> SRDD requirements -> SRS requirements

7. SRS - Overview • The SRS focuses on the system-level requirements (the “what”), non implementation specific. • System Overview • General System Requirements • Quality Requirements • System Interface Requirements

8. SRS – General System Requirements • Main focus of SRS: general system requirements • Provide abstract non implementation specific description of each requirement • Provide test cases for each requirement • Represented by “shall” statements, must be testable • Each “shall” statement has a trace tag

9. SRDD - Overview • SRDD focuses on the lower-level implementation -specific requirements (the “how”) • It is a list of methods and classes that will eventually be implemented • Specific enough to explain exactly what a function does • Abstract enough so the programmer can implement the code anyway they want

10. SRDD – Example Function • setPrimitive tells the AGM-200 which drawing mode to be in. • SRDD “shall” statements trace back to SRS

11. Test Plan • Test plan is the lowest level in the documentation hierarchy. • The document is organized as a listing of test cases which correspond to all of the “shall” statements in the SRDD. • Not actual code, but descriptions of code that you will write that gives the coder freedom of implementation.

12. Client • Layered Design • Client • Transactions / Requests • GUI / Test Runner • Network • Decided to use UDP, but left TCP functionality in as product switch

13. GUI

14. Output

15. Class Structure • AGM_Client.jar: • package fit • package displayTool • DisplayFrame.java, DisplayTool.java • package tcpClient • NetClient.java, TCPClient.java, UDPClient.java • Request.java, Reply.java, Transaction.java • TestRunner.java • package fixtures • GenericRequestFixture.java • TransactionFixture.java • TCPApplet.java

16. Server Environment • Ran on the DEOS operating system • Proprietary real-time scheduling OS • Written in C++ • Time consuming setting up server project in visual studio • Memory, scheduling, threads, mutexes, mailboxes, etc. all entered manually into registry • Binary file and registry uploaded to the AGM using ftpshell and then ran • Debugging done through logProcessEvents and checked through telnet

17. Server Processes • We use two processes: • CRC • aClient • aClient has multiple threads: • Handle UDP connection • Draw HGL primitives • Receive a message from CRC process when the value of the CRC has changed

18. Client/Server Communication • Server waits for incoming UDP connection from client • Server receives string in following format using recvfrom(): • Function|Param1|Param2|…|ParamN • Unpack() parses it and reads parameters into an array of strings • Switch used to either change what is drawn or get a CRC value • sendto() is used to send status or CRC back to client

19. CRC Operation • CRC is calculated using a different process. • DEOS only allows “server” processes to interact with our process, and CRC calculation is not a “server” process (HGL is) • To get around this, we use a mailbox that is accessed by our main process. • CRC sends a new value to the mailbox each time it changes • Thread in main process keeps checking mailbox and stores value in global variable

20. OpenGL • Standard specification defining a cross-platform graphics API • Doesn’t provide the actual functionality; only an interface • Useful for abstraction and uniformity • Displays use OpenGL to convert geometric primitives (lines, shapes, etc) into pixels

21. HGL • Supported functions: • Draw Line • Draw Square • Draw Triangle • Draw Polygon • Clear Display • Set Color

22. Conclusion • Had some holdups along the way due to environment • We had to narrow the scope a bit, but in the end we built a working product • Opportunity to learn a thing or two about graphics, embedded software, and network programming

23. Questions?