Simulation of Traffic Jams

Sharon Shabtai 066557687

Shimrit Yacobi 039770284

Yuval Binenboim 201562626

Moran Lev Lehman 201654225

Academic Advisor: Dr. Meir Kelah

Technical Advisor: Mr. Roni Stern

Table Of Context

I. Introduction...... 3

1.1 Vision ...... 3

1.2 The problem domain ...... 3

1.3 Stakeholders ...... 4

1.4 Software context ...... 4

1.5 System Interfaces ...... 7

1.5.1 Hardware Interfaces ...... 7

1.5.2 Software Interfaces ...... 7

1.5.3 Events ……………...... 7

1.5.4 Server Interface ………………………………………………………………………………… 8

1.5.5 Client Interface …………………………………………………………………………………. 9

1.5.6 Experiment manager Interface ……………………………………………………..... 11

II. Functional Requirements ...... 13

III. Non-Functional requirements...... 14

IV. Usage Scenarios ...... 15

4.1 User Profiles- The Actors...... 15

4.2 Use cases………………...... 16

V. Appendixes ….…………………………………………………………………………………………………………… 29

1. Introduction

1.1Vision

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 AIalgorithms; 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.

1.3Stakeholders

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 enablehim to implement andcheck thesealgorithms.

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.

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.

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 usersworkstation) 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 therelevant data that originated from the experiment.

An example for the bird's-eye view can be followed by the Simulator example link:

1.5. System Interfaces

1.5.1 Hardware Interfaces: Our system does not interact with any hardware interface or any other systems.

1.5.2 Software Interfaces:

Not applicable for our simulator.

1.5.3Events

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.
  1. End of experiment – This event indicates that the current experiment is terminated and analyzing of the data should commence.
  1. Control events- The system will respond to GUI events from the user controlling the car.
  1. View's updates – Something changed in the experiment environment.
  1. Connection– An event of creating a connection between a client/experiment manager to the server.
  1. 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.

1.5.4Server Interface

The server will implement an interface In order to allow the client to connect and receive data.

Operation: Update Event

Used By: Client

Parameters:

Event - a description of the event committed by the client.

Return Values:

void

Operation: Connect

Used By: Client

Parameters:

details – the experiment participant's details.

Return Values:

void

Operation: Disconnect

Used By: Client

Parameters:

void.

Return Values:

void

Operation: Create simulation

Used By: Experiment manager

Parameters:

participants – list of the clients that takes part in the

experiment.

numberOfJunctions - the number of the junctions in the user's

view.

Return Values:

void

Operation: Start experiment

Used By: Experiment manager

Parameters:

void.

Return Values:

void.

Operation: Stop experiment

Used By: Experiment manager

Parameters:

void.

Return Values:

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

Parameters:

void.

Return Values:

The general data requested.

1.5.5Client 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

Parameters:

Details – the connection details.

Return Values:

Void

Operation: Update View

Used By: Server

Parameters:

View – the new view that the client is going to see.

Return Values:

Void.

Operation: Start

Used By: Server

Parameters:

View – The initial view

Return Values:

Void

Operation: Stop

Used By: Server

Parameters:

Void

Return Values:

Void

Operation: Command

Used By: User/ AI User

Parameters:

Type – the command type.

Return Values:

Void

1.5.6Experiment 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

Parameters:

Details – the connection details.

Return Values:

Void

Operation: Update View

Used By: Server

Parameters:

View – the new view that the experiment manager is going to see.

Return Values:

Void.

Operation: Update general data

Used By: Server

Parameters:

The updated data regarding the experiment (meta data e.g. client connected/disconnected…)

Return Values:

Void

Operation: Create simulation

Used By: Admin User

Parameters:

participants – list of the clients that takes part at the experiment.

numberOfJunctions - the number of the junctions in the view.

Return Values:

void.

Operation: Start experiment

Used By: Admin User

Parameters:

void.

Return Values:

void.

Operation: Stop experiment

Used By: Admin User

Parameters:

void.

Return Values:

results – the results of the experiment is an Excel data file with

all the experiment data and analysis.

2. Functional Requirements

Functionality / Description
1 / Experiment environment initiation / Creating a new experiment
2 / Start running experiment / Staring an experiment, updating the clients.
3 / Stopping experiment / Stopping the experiment, collecting data, analyzing the experiment results.
4 / Updating the experiment environment / Updating the server and clients that the environment has changed.
5 / Analyzing data / 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 experimentthis includes navigating the car and also controlling the speed by accelerating and breaking.

3. Non Functional Requirements

Reliability

After a user performs an action, the server and all theviews in the systemwill be updated according to that action.

The system doesn't support hardware failures, and is not required to support data recovery, self-stabilization and error-correction.

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

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

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 experimentby entering the system and waiting to be chosen for an experiment, once a user begins an experimenthe 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.

4.2 Use-cases

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. Theexperimentmanager started the experiment.

Post-Condition:

  1. The car starts moving according to the user operation:
  1. The location of the car changes in the system.
  2. The views of all the users and the experimentmanager, 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:
  2. The user presses a navigation key in the keyboard.
  3. A new location of the car is computed according to the user's command.
  4. A message that specified the new location of the car is sent from the user's computer to the server.
  5. The server updates the experimentManager and the rest of the users about the new location of the car.
  6. The experimentManager'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.
  2. The message will be sent again.
  3. The connection between the server and the client is lost.
  4. A proper message will appear on the screen.

Use Case 1 – Diagram

Use Case 2 – Enter The System

Name: Enter the system

Primary Actor: regular user, experimentmanager.

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
  7. 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.
  2. The message will be sent again.
  3. The connection between the server and the client is lost.
  4. A proper message will appear on the screen.
  5. The user entered illegal data.
  6. A proper message will appear on the screen.
  7. The window of registration is reopened.

Use Case 2 – Diagram

Use Case 3 – Exit the program

Name: Exit the program

Primary Actor: regular user, experimentmanager.

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 experimentmanager 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.
  2. The message will be sent again.

Use Case 3 – Diagram

Use Case 4 – Creating a new Experiment

Name: Creating a new experiment

Primary Actor: experimentmanager

Pre-Condition:

1. The experimentmanager computer is connected to the server.

2. The main menu window is open.

Post-Condition: A new experimentis created.

Description: The experimentmanager creates a new experimentconsisting of human users and AI users as he sees fit.

Trigger: The experimentmanager presses the "create exp" button.

Flow of events:

  1. A "creating experiment"window is opened.
  2. The experimentmanager fills the experimentdetails in the relevant fields inside the window.
  3. The experimentmanager presses the "create" button
  4. The experimentmanager's computer sends a message to the serverregarding the new experiment.
  5. A new experimentis created at the server.

Alternative flows:

  1. The experimentmanager entered illegal data.
  2. A proper message will appear on the screen.
  3. The creating experimentwindow is reopened.
  4. The connection between the server and the client is lost.
  5. A proper message will appear on the screen.

Use Case 4 – Diagram