Simulation of Traffic Jams

Transcription

1 SHARON SHABTAI SHIMRIT YACOBI YUVAL BINENBOIM MORAN LEV LEHMAN Academic Advisor: Dr. Meir Kelah Technical Advisor: Mr. Roni Stern

2 Table Of Context I. Introduction Vision The problem domain Stakeholders Software context System Interfaces Hardware Interfaces Software Interfaces Events Server Interface Client Interface Experiment manager Interface II. Functional Requirements III. Non-Functional requirements IV. Usage Scenarios User Profiles- The Actors Use cases V. Appendixes. 29 2Page

3 1. Introduction 1.1 Vision The project, "Simulation of Traffic Jams", objective is to build an infrastructure for an experiment that will help test AI algorithms for driving cars in traffic jams. The vision of the project is to perform a simulation of many vehicles in a traffic jam, where some are controlled by computers running a certain AI algorithm, and some are regular users which drive however they want. The simulator will visually show the road as if you were in a real car and will interactively change as you drive. The main goal is to test different AI algorithms; these algorithms should control a car and drive it without making any car accidents in a traffic jam. After running an experiment with certain AI algorithm, the effectiveness of the algorithm can be measured and tested by allowing an admin user to view the simulation from above and gather different statistics about it. The experiment manager (or admin) will have a top side view of the roads, and will be able to see in real time what each user/ai Computer is doing. During any experiment all the data is recorded and analyzed by the simulator and the simulation results can be accessed by the experiment manager. 1.2 The Problem Domain Our Simulator operates within its own problem domain, it is a standalone aplicaton. Its goal is to enable testing of various AI algorithms which are developed by our client. These algorithms are trade secrets and therefore we cannot elaborate on them. Our simulator will enable these algorithms to control a car via a certain interface which will be described in the ADD document. 3Page

4 1.3 Stakeholders Expert- Roni Stern The stakeholder of this project is mainly Roni Stern who s also the expert behind the project s idea and design. Roni is trying to develop algorithms for driving in traffic jams and this simulator's purpose is to enable him to implement and check these algorithms. Customer- Roni Stern Roni is also the customer, he intends to use the simulator's results to test the AI algorithm behavior, and analyze it to help his research. Note: other researchers in the same field, with access to the simulator can also use it for future analysis. 1.4 Software context The Simulator consists of 3 main components Clients, Server and the Experiment manager, each are a separate module and connect to each other via a network protocol interface. Agent Agent Experiment Manager Internet Agent Agent Agent 4Page

5 Main Server This module enables the experiment manager to create and perform an experiment, and to document the results. It connects between all the experiment stations (clients) and operates them. It also receives data from all stations, processes it and distributes it throughout all the connected clients. The server receives as input several parameters on how to build the current experiment; it then builds the experiment and updates all the clients on the current experiment. During the experiment the server receives data from the different clients, it propagates this data to all the clients via the network, uses the data to update the bird's eye view in the experiment manager station and also stores the data. Once the experiment is over it analyzes all the data that was stored and displays it. Client The experiment includes two kinds of clients, a regular human client and an AI agent. The experiment might include many clients from each kind. (More detailed information will be described later). This module enables a real user controller or an AI algorithm, to drive a car using an experiment map built in the system. It shows a first person view of the car (from the inside of the car). Each agent will send and receive data concerning the current experiment to the server. The client starts with some initial data of the experiment; it creates the graphical view of the car. Once the experiment begins the Clients program receives inputs from the human user or the AI user, drives the car according to the input, and updates the server. The client's module includes an interactive view with friendly UI for the user, which changes the view according to it. We note that the client is frequently updated by the server with the newest events that occurred. 5Page

6 Experiment manager This module is in charge of creating an experiment. It is located on the computer containing the server module. It enables an admin user to create an experiment according to whatever parameters he chooses. Once the admin user (which is also called an experiment manager, the same name as this module's name since this module is the admin users workstation) creates an experiment, the module shows a bird's-eye view of the cars, and the experiment map, during the experiment. The experiment manager is able to analyze and view the results and statistics gathered in the experiment. The experiment manager creates an experiment by defining all the different parameters regarding the experiment. After an experiment is created, the experiment manager decides when to start the experiment and when to end the experiment. During the experiment, the experiment manager shows a bird's eye view of all the cars and the map which is updated frequently. Once the experiment is over, the experiment manager receives an Excel data file with all the relevant data that originated from the experiment. An example for the bird's-eye view can be followed by the Simulator example link: 50pct-human.mov 6Page

7 1.5. System Interfaces Hardware Interfaces: Our system does not interact with any hardware interface or any other systems Software Interfaces: Not applicable for our simulator Events The main events in our Simulator are: 1. Start of experiment This event indicates a start of a new experiment, which the experiment manager created and started. 2. End of experiment This event indicates that the current experiment is terminated and analyzing of the data should commence. 3. Control events- The system will respond to GUI events from the user controlling the car. 4. View's updates Something changed in the experiment environment. 5. Connection An event of creating a connection between a client/ experiment manager to the server. 6. Disconnection The end of the connection between a client/ experiment manager to the server. A detail explanation on each event and its context is given below; the events are categorized by the interface which will receive them. 7Page

8 1.5.4 Server Interface The server will implement an interface In order to allow the client to connect and receive data. Operation: Update Event Used By: Client Event - a description of the event committed by the client. void Operation: Connect Used By: Client details the experiment participant's details. void Operation: Disconnect Used By: Client void. void Operation: Create simulation Used By: Experiment manager participants list of the clients that takes part in the experiment. numberofjunctions - the number of the junctions in the user's view. void 8Page

9 Operation: Start experiment Used By: Experiment manager void. void. Operation: Stop experiment Used By: Experiment manager void. results the results of the experiment is an Excel data file with all the experiment data and analysis, from the current experiment. Operation: Get general data from the server Used By: Experiment manager void. The general data requested. 9Page

10 1.5.5 Client Interface The client will implement an interface through which the server will update all the data about the experiment Operation: Connect to server Used By: User Details the connection details. Void Operation: Update View Used By: Server View the new view that the client is going to see. Void. Operation: Start Used By: Server View The initial view Void Operation: Stop Used By: Server Void Void Operation: Command Used By: User/ AI User Type the command type. Void 01Page

11 1.5.6 Experiment manager Interface The experiment manager will implement an interface through which the server will update all the data about the experiment. Operation: Connect to server Used By: Admin User Details the connection details. Void Operation: Update View Used By: Server View the new view that the experiment manager is going to see. Void. Operation: Update general data Used By: Server The updated data regarding the experiment (meta data e.g. client connected/disconnected ) Void Operation: Create simulation Used By: Admin User participants list of the clients that takes part at the experiment. numberofjunctions - the number of the junctions in the view. void. 00Page

12 Operation: Start experiment Used By: Admin User void. void. Operation: Stop experiment Used By: Admin User void. results the results of the experiment is an Excel data file with all the experiment data and analysis. 02Page

13 2. Functional Requirements Functionality 1 Experiment environment initiation 2 Start running experiment 3 Stopping experiment 4 Updating the experiment environment 5 Analyzing data Description Creating a new experiment Staring an experiment, updating the clients. Stopping the experiment, collecting data, analyzing the experiment results. Updating the server and clients that the environment has changed. In the end of the experiment, the system should analyze the results of the experiment 6 Connect The clients and the exp. Manager are able to connect to the server. 7 Disconnect The clients, exp. Manager & server are able to disconnect from each other. 8 Controlling the car Human user or AI should be able to control the car in the experiment this includes navigating the car and also controlling the speed by accelerating and breaking. 03Page

14 3. Non Functional Requirements Reliability After a user performs an action, the server and all the views in the system will be updated according to that action. The system doesn't support hardware failures, and is not required to support data recovery, self-stabilization and errorcorrection. In case of a network failure the system will need to be manually rebooted. Usability The system should be user friendly and easy to use, users can participate in the experiment without any advanced knowledge or instructions. Safety & Security Not relevant in our system. Speed & Throughput After a user performs an action it is updated in his view after at most 0.25 seconds, and after at most 0.5 seconds at 90% of all other views. Capacity An experiment can have at most 30 users connected simultaneously, of which at most 15 of them are AI users. Availability The user should be able to use all UI functionality at all times. Portability The system will work on any computer running the operating system Windows XP or higher. 04Page

15 4 Usage Scenarios 4.1 User Profiles The Actors The definition of an actor in the system depends on his role. A user can be an experiment manager or regular user. Regular user - a user of the application can be a human user or an AI user. A human user can be anyone who wants to participate in the experiment. An AI user can be one of the computers running the AI algorithms that we are going to implement. The regular user can participate in an experiment by entering the system and waiting to be chosen for an experiment, once a user begins an experiment he can drive his car throughout the map. Experiment manager an experiment manager is a human who is responsible for the creation of the experiment. An experiment manager can view all the cars in a bird's-eye view, and the map during the experiment. At the end of the experiment, the experiment manager can view the results and statistics. 05Page

16 4.2 Use-cases 06Page

17 Use Case 1 Controlling the car Name: Controlling the car Primary Actor: Regular user Pre-Condition: 1. Experiment is created. 2. The user already entered the system. 3. The experiment manager started the experiment. Post-Condition: 1. The car starts moving according to the user operation: a. The location of the car changes in the system. b. The views of all the users and the experiment manager, changes according to the action that occurred. Description: The user controls the movement of the car by pressing the keyboard. Trigger: User presses the navigation keys in the key board. Flow of events: 1. Loop: 1.1. The user presses a navigation key in the keyboard A new location of the car is computed according to the user's command A message that specified the new location of the car is sent from the user's computer to the server The server updates the experiment Manager and the rest of the users about the new location of the car The experiment Manager's and the user's views are changed according to the movement of the car. Alternative flows: 1. One of the messages between the server and the clients didn't reach its destination, because of a communication problem. a. The message will be sent again. 2. The connection between the server and the client is lost. a. A proper message will appear on the screen. 07Page

18 Use Case 1 Diagram 08Page

19 Use Case 2 Enter The System Name: Enter the system Primary Actor: regular user, experiment manager. Pre-Condition: none Post-Condition: The user's computer is connected to the server and is ready to start the experiment. Description: The user enters the system in order to participate in the experiment. Trigger: User presses the "enter" button. Flow of events: 1. A window of registration is opened. 2. The user fills details in the relevant fields. 3. The user presses the "enter" button. 4. The user's computer sends a connection request to the server. 5. A session is created between the server and the user's computer. 6. If the user is a regular user 6.1 Then: a waiting message appears on the user's screen. 6.2 ELSE: a new "create exp" window will appear on the screen. Alternative flows: 1. One of the messages between the server and the clients didn't reach its destination, because of a communication problem. a. The message will be sent again. 2. The connection between the server and the client is lost. a. A proper message will appear on the screen. 3. The user entered illegal data. a. A proper message will appear on the screen. b. The window of registration is reopened. 09Page

20 Use Case 2 Diagram 21Page

21 Use Case 3 Exit the program Name: Exit the program Primary Actor: regular user, experiment manager. Pre-Condition: 1. The user's computer is connected to the server. 2. The main menu window is open. Post-Condition: 1.The user's computer is not connected to the server. 2. The program is closed. Description: The user closes the program. Trigger: The user presses the "exit" button. Flow of events: 1. The user presses the "Exit" button on the main menu. 2. A disconnect message is sent to the server from the user. 3. The server updates the experiment manager that one of the users left the experiment. 4. The users program terminates. Alternative flows: 1. One of the messages between the server and the clients didn't reach its destination, because of a communication problem. a. The message will be sent again. 20Page

22 Use Case 3 Diagram 22Page

23 Use Case 4 Creating a new Experiment Name: Creating a new experiment Primary Actor: experiment manager Pre-Condition: 1. The experiment manager computer is connected to the server. 2. The main menu window is open. Post-Condition: A new experiment is created. Description: The experiment manager creates a new experiment consisting of human users and AI users as he sees fit. Trigger: The experiment manager presses the "create exp" button. Flow of events: 1. A "creating experiment" window is opened. 2. The experiment manager fills the experiment details in the relevant fields inside the window. 3. The experiment manager presses the "create" button 4. The experiment manager's computer sends a message to the server regarding the new experiment. 5. A new experiment is created at the server. Alternative flows: 1. The experiment manager entered illegal data. a. A proper message will appear on the screen. b. The creating experiment window is reopened. 2. The connection between the server and the client is lost. a. A proper message will appear on the screen. 23Page

24 Use Case 4 Diagram 24Page

25 Use Case 5 Starting an experiment Name: Starting an exp Primary Actor: experiment manager Pre-Condition: An experiment exists at the server after it was created by the experiment manager. Post-Condition: 1. The experiment begins. 2. All the users are updated and can start driving their cars. Description: The experiment manager wants to start running the experiment he has just created. Trigger: The experiment manager presses the "start" button. Flow of events: 1. The experiment manager presses the "start" button. 2. A proper message will be sent to the server from the experiment manager's computer. 3. A proper message will be sent from the server to all users' computers telling them that the experiment has started. 4. All the users get the control of their cars and can now start driving in the experiment. 5. The bird's eye view in the experiment manager station is initiated. 6. The server starts recording all the relevant data about the current experiment. Alternative flows: 1. One of the messages between the server and the clients didn't reach its destination, because of a communication problem. a. The message will be sent again. 2. The connection between the server and the client is lost. a. A proper message will appear on the screen. 25Page

26 Use Case 5 Diagram 26Page

27 Use Case 6 Stopping the Experiment Name: Stopping the experiment. Primary Actor: experiment manager Pre-Condition: An experiment is running. Post-Condition: 1. The experiment has ended. 2. All the users have been updated. 3. The experiment manager is updated about with the results and conclusions from the experiment in a form of an excel file. Description: The experiment manager wants to stop the current experiment. Trigger: The experiment manager presses the "stop" button. Flow of events: 1. The experiment manager presses the "stop" button. 2. A proper message will be sent to the server from the experiment manager's computer. 3. A proper message will be sent from the server to all users' computers. 4. A proper message will appear on the screen of all users. 5. The main menu window will be opened in all the users' computers. 6. An excel file will appear in the experiment manager's computer including the data results from the current experiment. Alternative flows: 1. One of the messages between the server and the clients didn't reach its destination, because of a communication problem. a. The message will be sent again. 2. The connection between the server and the client is lost. a. A proper message will appear on the screen. 27Page

28 Use Case 7 Diagram 28Page

29 5 Appendixes Risks 1. Slow response time There is a risk that the response time of the message transportation and the view update will be too slow, and the user will not have an updated snapshot of the current movements in the system. This situation might impair the functionality of the AI algorithm due to inconsistent and false data flow. The situation might be caused by low performance of the hardware or the software. 2. Misuse of the system by the human user Another risk might be caused by a user misusing the system, if the human user won't be able to control the car properly, or won't take the experiment seriously, then the AI Algorithm will basically be tested by using useless data and this could badly affect the results of the experiment. If the results are based on the assumption that human users should be behave like real life drivers then in such a case the results will be flawed ( this assumption is certainly acceptable for certain AI algorithms). 29Page