Sense and Avoid: Software Architecture version 1.0

Size: px

Start display at page:

Download "Sense and Avoid: Software Architecture version 1.0"

Buck Wilkins
6 years ago
Views:

1 Sense and Avoid: Software Architecture version 1.0 Team No Scrubs Computer Science Department California Polytechnic State University San Luis Obispo, CA November 11, 2015

2 Contents Contents Revision History 1. Introduction 2. Problem Description 3. Solution 3.1. Overview (Myra) 3.2. Components (Colin) Simulation Server (Jon) Sense and Avoid Processor (SAAP) (Mike) Cockpit Display of Traffic Information (CDTI) (Esha) 3.3. Design (Myra) Simulation Server (Jon) Communication from Simulation Server to SAAP (Jon) Sense and Avoid Processor (SAAP) (Mike) Communication from SAAP to CDTI (Colin) Cockpit Display of Traffic Information (CDTI) (Esha) 4. Test 4.1. Components and Design Test Configuration GUI (Vivian) Communication from Test Configuration GUI to Simulation Server (Vivian) Communication from SAAP back to Simulation Server (Esha) 5. Issues A. Glossary B. Issues List

3 Credits Name Date Reason for Changes Version Esha Joshi Document Owner 1.0 Colin Adams Document Owner 1.0 Jonathan Lin Document Owner 1.0 Vivian Fong Document Owner 1.0 Myra Lukens Document Owner 1.0 Mike Ryu Document Owner 1.0 Revision History Name Date Reason for Changes Version Esha Joshi Colin Adams Jonathan Lin Vivian Fong Myra Lukens Mike Ryu

5 1. Introduction [Tell the audience what this document is about. This should summarize the functionality covered by the design and scope of the design within the broader architecture. Related documents can be referenced in this section as well.] To be written in v2. 2. Problem Description [Tell the audience what problem is being solved, or requirements are being met, by this design. Include requirements or constraints that drive the direction of the design. Any quality attribute requirements or constraints should also be explained in this section.] To be written in v2.

6 3. Solution 3.1. Overview The Test Configuration GUI, Simulation Server, Sense and Avoid Algorithm, and the Cockpit Display of Traffic Information interact to form our solution. This section will describe the design of these components and interactions between them Components Figure 0 : Deployment diagram. The diagram above illustrates basic deployment structure of this project. There are three hardware layers: Ground Control System, On-Board Flight Computer, and Test (Simulation) Server. Test Server will be run on Linux OS, and will hold the information that would simulate the data that sensors generate in a real application.

7 Figure 1 : Component diagram. Figure 1 above is a component diagram that shows how the system is broken up and messages move throughout the system. Starting with the Simulation Server, there are four internal components each responsible for sending one of the data types (ADSB, TCAS, Radar, or Ownship) to the SAAP, via a connection to the Client. Once the Client receives the data, it will transform each into a common Sensor data type, and pass that on to the aggregator. The Aggregator will aggregate the Sensor data into CDTI Aircraft, so that each object represents a unique plane with backing data from at least one Sensor object. The CDTI Aircraft are then sent to the Smoother which will compare this new data set to prior sets, and smooth any drastic changes between them. It will then create a CDTI Report composed of the Aircraft, as well as any suggested maneuver. This Report is then sent to the Server to transmit to the CDTI, as well as to the Simulation Server. The CDTI will display this information via the GUI, while the Simulation Server will use the report to compare to the expected output for the particular test and report the results Simulation Server To be elaborated in v Sense and Avoid Processor (SAAP) To be elaborated in v2

8 Cockpit Display of Traffic Information (CDTI) The Cockpit Display of Traffic Information (CDTI) is one integral component that makes up our SAA System. It allows the pilot to view a graphical representation of the status of the ownship and surrounding airspace. Features : 1. Display a map of the airspace surrounding the ownship. 2. Display an alert message. 3. Zoom in and zoom out. 4. Configure traffic types Design Figure 2 : High Level Class Diagram Figure 2 above is a high level class diagram that represents the primary interactions and classes in our system. We have 6 primary packages: test_config,proto,util,simulation_server,saa,andcdti. The test_config package represents the Test Configuration GUI, where a user can create various tests that write to a file. The Simulation Server reads the data from this file, and passes it to the SAA. The SAA then interprets, aggregates, and smooths the data and creates a CDTIReport which it then sends to the CDTI. The CDTI interprets the data from the SAA and performs various operations such as coloring it before displaying it on the GUI.

9 Figure 3 : High Level Sequence Diagram Figure 3 above is a high level sequence diagram of our system. It begins with a test being made via the Test Configuration GUI, which writes test information to a file. The Simulation Server uses a FileReader to read the various sensor data from the file. It then sends this data to the SAA Client, which creates CDTIAircraft objects from the sensor data. These CDTIAircraft objects are then smoothed via a Smoother, and the resulting CDTIAircraft are added to the CDTIReport object. This report is then sent via the SAAServer to the CDTI for display, and to the Simulation Server to compare the test results. The CDTI then reads the CDTIReport object and displays it onto the GUI.

10 Simulation Server Figure 4 : Simulation Server Figure 4 above shows the design of the server package. The Simulation Server class will instantiate new threads that use the Runnable ProtoMessenger classes. The ProtoMessenger class implements the Runnable interface to represent each individual type of sensor. The ProtoMessenger has a parsetoproto() function that needs to be implemented by child classes. The parsetoproto function will convert test data from text files (configured by the test configuration) into proto classes. Each child of ProtoMessenger also implements sendtoclient(), which sends all the relevant sensor data types to the SAA. These data types are represented using Google Protocol Buffers. Google Protocol buffers allows the server to serialize data to be sent over a network. Each child of

11 ProtoMessenger - OwnshipMessenger, RadarMessenger, TCASMessenger, and ADSBMessenger- will use their respective protocol buffer class : OwnshipProto, RadarProto, TCASProto, and ADSBProto. The threads will finish once file reading is done and test data is done reading Communication from Simulation Server to SAAP Figure 5 : Sequence Diagram of Simulation Server to SAAP Figure 5 above is a sequence diagram that describes the communication between the SAA and the Simulation server. The assumptions are that: The simulation server is running The client and simulation server have the same proto classes The client knows the IP address and socket number of the server When the client needs the simulation data, it will send a connection request to the server. The server will start 4 threads, one for each type of sensor. Once it is done starting those threads that contain connections to the client, the server will send the client a list of socket numbers that the client will use to create threads. Now, each SAA thread and each Server thread will connect one-to-one. Once the SAA threads are reading, the Messenger classes will send the parsed data in a form of Proto buffers to the client. The messenger will continue to send to the client if there is still data to be parsed and sent. Once all data is sent, the threads die and the server waits for more requests of data to come in.

12 Sense and Avoid Processor (SAAP) Figure 6 : Class Diagram of SAAP

13 Communication from SAAP to CDTI Figure 7 : Sequence diagram illustrating communication between SAAP to CDTI. Figure 7 above shows the sequence of communication between the SAAP and the CDTI. First, the CDTI will be turned on by a user. This will initiate the creation of the CDTI client and this client will then connect to the SAAP server. Once this connection is established, the server will continue to send the CDTI Reports to the CDTI, at roughly one second intervals, until the connection is closed. The connection will close if the CDTI or SAAP are turned off.

14 Cockpit Display of Traffic Information (CDTI) Figure 8 : Class diagram of CDTI package. Figure 8 above illustrates the design of the CDTI package. The package utilizes the M-V-C architecture and contains respective classes to represent each vital component of the CDTI design. The CDTIController contains a reference to the CDTIModel, which acts as the container object for the CDTI system. Once the CDTIModel changes, CDTIGui will be updated because it is an observer to the CDTIModel class. The CDTIModel extends the Observable class and contains methods for altering the configurable parameters for each traffic advisory metric: range, elevator, distance, and time. This class also has an instance of a CDTIReport. Once a connection has been forged between the SAA and CDTI, CDTIReport reads from the CDTIProto and sets the timestamp, ownship plane, advisory message string, advisory warning level, and list of planes. A list of CDTIPlanes is initialized in the CDTIReport - each of which is comprised of an id, position, and velocity. Position and velocity are wrapped in a Vector object. The advisory warning level is labelled as an integer representing a different Severity : PROXIMATE (0), TRAFFIC (1), or RESOLUTION (2).

15 CDTIGui implements the Observer interface and contains CDTIMap and ConfigurationMenu. CDTIMap represents the map that displays the ownship icon, other aircraft icons, and the background image. ConfigurationMenu contains methods for zooming in/out, resetting values for configurable parameters, and displaying the CDTI alert messages.

16 4. Test 4.1. Components and Design As mentioned in the Solution Overview, test cases shall be created through the Test Configuration GUI and later validated in the Simulation Server. The Test Configuration GUI allows the user to drag-and-drop test aircrafts into a mock CDTI display and configure their absolute location and direction. Once a test is added, the system shall consume the user input and serialize the test cases into text files for the Simulation Server to parse. Once the Simulation Server sends the data to the SAA Server and constructs a CDTIReport, the object is sent back to the Simulation Server to compare with the original test case Test Configuration GUI The Test Configuration system shall follow the Model-View-Controller (MVC) design pattern to facilitate the construction and saving of tests. Figure 9 : Class diagram of test configuration package.

17 Figure 9 provides a rough design of the test_config package. The TestAircraft class contains a testid, aircraftid, as well as all absolute data to define the true location of the plane. The TestConfigurationModel acts as the container object for the test configuration system. The class contains a TestAircraft to represent the ownship and a collection of TestAircrafts to represent the intruders to simulate. TestConfigurationModel implements java.util.observable, allowing Observers to be notified of any changes. The TestConfigurationGUI extends java.util.observer and acts as the view to the model. The GUI class is responsible for displaying the system, interacting with the user, and relaying changes to the model. The class contains a CDTIMap ; more details on the CDTIMap class can be read in Section Cockpit Display of Traffic Information (CDTI). The TestConfigurationController interacts with both the model and the view to facilitate the interactions. It provides the methods to add, edit, and remove tests by writing and reading the test files in the test directory.

18 4.1.2.Communication from Test Configuration GUI to Simulation Server The Test Configuration GUI provides three main pieces of functionality to the user: adding, editing, and removing tests. The Simulation Server interacts with the Test Configuration system by parsing the tests from the test file directory. Figure 10 : Sequence diagram of test configuration GUI saving test files. F i gure 10 illustrates a sequence diagram that lays out the flow these three operations. Once the system is launched, the user may add a test from the GUI, prompting the controller to write the data to a text file in the test file directory. Afterward, the GUI is updated to reflect the operation. To edit a previous test, the GUI makes a call to the controller to load the test file, and the controller retrieves and reads the file from the directory. The GUI is then updated to display the saved test data, and the user may modify and commit changes to the existing test. The controller then commences to write the changes back to the file.

19 Lastly, the user may delete a test through the GUI, prompting the controller to remove the file from the file directory and signalling the GUI to update.

20 Communication from SAAP back to Simulation Server Figure 11 : Sequence diagram of communication from SAAP back to Simulation Server. Figure 11 illustrates a sequence diagram that lays out the flow of communication of the CDTIProto packet of data from SAAP back to the simulation server. Once the system is launched and a connection has been established via Google Protocol Server from the SAA (client) to the simulation server, the SAA will send the CDTIReport in the form of CDTIProto. The CDTIProto packet of data containing the correlated sensor data (advisory message string, advisory warning level, list of CDTIPlanes) will be tested in the simulation server for accuracy when the connection is active. We hope that the connection between the SAA and the simulation server will only need to be established once.

21 5. Issues [Any issues or open questions should be described here.] To be written in v2. A. Glossary [Define all the terms necessary to properly interpret the software architecture, including acronyms and abbreviations. You may wish to build a separate glossary that spans multiple projects or the entire organization, and just include terms specific to a single project in each software architecture.] To be written in v2. B. Issues List [This is a dynamic list of the open architecture issues that remain to be resolved, including TBDs, pending decisions, information that is needed, conflicts awaiting resolution, and the like.] To be written in v2.

Software Requirements Specification. <Project> for. Version 1.0 approved. Prepared by <author(s)> <Organization> <Date created>

Software Requirements Specification for Version 1.0 approved Prepared by Software Requirements Specification for Page 2 Table of Contents Revision