Download Honeywell Team

CSE Capstone Project
Final Presentation
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
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.
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.
System Level Overview
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
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
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
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
SRDD – Example Function
•
setPrimitive tells the AGM-200 which drawing mode to be in.
•
SRDD “shall” statements trace back to SRS
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.
Client
 Layered Design
 Client
 Transactions / Requests
 GUI / Test Runner
 Network
 Decided to use UDP, but left TCP functionality in
as product switch
GUI
Output
tcpClient.fixtures.TransactionFixture
IP
port
Start?
agm
6969
true
tcpClient.fixtures.GenericRequestFixture
DrawSquare
GetReply?
true
tcpClient.fixtures.GenericRequestFixture
SetColorFlat
RR
GG
BB
GetReply?
22
33
FF
true
tcpClient.fixtures.GenericRequestFixture
GetReply?
0x7C4237D7
GetCRC
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
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
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
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
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
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
HGL
 Supported functions:
 Draw Line
 Draw Square
 Draw Triangle
 Draw Polygon
 Clear Display
 Set Color
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
Questions?