Software Design Description Report (SDD)

---

Table of contents

• 1. Introduction
  • 1.1. Purpose
  • 1.2. Project Scope
  • 1.3. Definitions, acronyms, and abbreviations (Glossary / Terminology)
  • 1.4. Overview of the Document
  • 1.5. Motivation
• 2. Architecture Design
  • 2.1 Description of Problem
  • 2.2 Technologies Used
  • 2.3. Architecture Design of AutoCar
• 3. Environment
  • 3.1. Modelling Environment
• 4. References

---

1. Introduction

This Software Design Description Report provides detailed information about the requirements of the AutoCar system software. This document includes the working principles of the proposed methods, and designs of the simulation.

1.1. Purpose

Our main purpose is “Increasing the survival rate of the patients or people on the emergency situations by clearing the emergency vehicle’s way with adding emergency vehicle priority awareness feature to autonomous cars”. We may cannot apply this project to our lives since generally people do not use autonomous cars today, but it may help to humans in the future when all cars on the roads become autonomous.

1.2. Project Scope

On this project we aimed to add emergency vehicle priority awareness feature to autonomous cars. The autonomous car that we simulate will be able to detect the emergency vehicles, and their location and direction. The autonomous car will use visual information; therefore, it is required to have multiple cameras mounted on the vehicle.

Our system will include:

• Lane detecting and following
• Object recognition and auto brake
• Virtual drive assistant
• Route Planning
• Emergency vehicle priority awareness

Current autonomous cars already have the first four of these features. We will add fifth one as a new feature to autonomous cars.

To be able to success on this project our car at least needs to follow the lane, not hit objects on the road and let the emergency vehicle pass by changing lanes. Other features may change according to the possibilities of the simulator.

1.3. Definitions, acronyms, and abbreviations (Glossary / Terminology)

Terminology	Definition
User	A person who interacts with the system.
SDD	The report that provides an overview of system’s design.
Autonomous Driving	A control mode which a vehicle doesn’t need a driver attention.
Emergency Vehicle	An emergency vehicle is any vehicle that is designated and authorized to respond to an emergency in a life-threatening situation [1].
Vehicle Priority	When a vehicle with higher priority approaches, all other traffic must stop or move to the right side to allow the vehicles pass through.
System	System software is a type of computer program that is designed to run a computer’s hardware and application programs [2].
Control Unit	The control unit (CU) is a component of a computer’s central processing unit (CPU) that directs the operation of the processor [3].
ADAS	Advanced driver-assistance systems.
LIDAR	Light Detection and Ranging, is a remote sensing method that uses light in the form of a pulsed laser to measure ranges (variable distances) to the Earth.[4]
GPS	The Global Positioning System (GPS), originally NAVSTAR GPS, is a satellite-based radio navigation system owned by the United States government. [5]

1.4. Overview of the Document

The remaining sections and their contents are listed below. Section 2 is the Architectural Design that defines the stage of project development. The subheading of this topic includes the identification and explanation of the problem and the technologies used. The architect details the general diagrams of the simulator program as a subtitle of the Design section. Sequence Diagram, Activity Diagram and Class Diagram. The continuation of section 2 includes the elaboration and detailed explanation of the project plan. Section 3 Environment. In this section, we have detailed and demonstrated the tools in the simulation environment.

1.5. Motivation

In this project, we chose today’s one of the most popular topic: Autonomous Vehicle. This project, which many engineers are curious about, was very suitable both for developing and keeping up with today’s technology. We examined the studies on this subject. In order to keep up with this technology, we followed current developments and improved our knowledge on this field. Since we wanted to obtain more accurate results, we decided to use simulation environments rather than building the system with limited hardware. For this purpose, we have searched simulators and chose the most appropriate one which is ‘Webots’. ‘Webots’ provides environment sound, radar sensor, Lidar sensor, map support etc.

---

2. ARCHITECTURE DESIGN

---

2.1. Description of Problem

Emergency vehicle priority is an important issue in the traffic. If we clear the way for emergency vehicles as quickly as possible, we can increase the survival rate of the patients or people on the emergency situations. Our project aiming to add vehicle priority awareness feature to autonomous cars. Of course, autonomous cars not common for today but in the future, everyone expected to use them.

2.2. Technologies Used

This software will be developed with Webots Simulator and its libraries for autonomous cars in Python.

2.3. Architecture Design of AutoCar

2.3.1.1 Sequence Diagram

Figure 1 Sequence Diagram of our project.

Figure 1 shows sequence diagram of our project. The user gives order to voice assistant to choose the route and start it. After it starts Main controller handles everything by obtaining data from sensors and sends them to sub modules, takes necessarily actions.

2.3.1.2 Activity Diagram

Figure 2 Activity Diagram of our project.

Figure 2 shows activity flows in our program. User gives order to system by voice assistant after system starts to run it tries to reach destination by itself.

2.3.1.3. Class Diagram

Figure 3 Class Diagram of our project.

2.3.1.4. Database Diagram

Figure 4 Database Diagram of our project.

In our Database we have ‘DataBag’, ‘Scenario’, ‘TrafficPrimitive’ and ‘Behavior’ tables to relate all the driving data. We don’t need prior knowledge of driving scenarios and primitives, but we need manually defined several hypo-thetical scenario conditions.

2.3.2 Architecture Design of AutoCar

---

2.3.2.1 Create Route

Summary: The user can select his/her location, determine the target position. With giving order by voice assistant.

Actor: User

Precondition: The car must be connected to the Internet and keep the location settings open.

Basic Sequence:

1. The user calls voice assistant to start it.
2. The user tells desired destination location.
3. The user can select when to start travel.
4. The user can cancel the route.
   
   Exception:

• Location error due to cellular data or another external factor.
• Incorrect orientation if map information is out of date.
  
  Post Conditions: User must tell destination location information.
  
  Priority: Medium

---

2.3.2.2. Driving State

Summary: The car will try to reach the destination.

Actor: None

Precondition: The car must be connected to the Internet and keep the location settings open.

Basic Sequence:

1.Start engine.

1. Follow the path to the destination.
2. Avoid collisions.
3. Consider traffic rules.
4. Clear the way if emergency vehicle approaches.
   
   Exception: None
   
   Post Conditions: Sensors need to work well.
   
   Priority: High

---

2.3.2.3. Change Direction

Summary: The user can change the path with giving order by voice assistant.

Actor: User

Precondition: The car must be connected to the Internet and keep the location settings open.

Basic Sequence:

1. The user calls voice assistant to start it.
2. The user tells desired direction or lane.
3. The route will recalculate by system.
4. The car follows the new path.
   
   Exception: If there is not such a lane (ex: one right lane when there is not exists.) or direction (ex: when user orders to turn left but there is no way.).
   
   Post Conditions: Sensors need to work well.
   
   Priority: Medium

---

2.3.3 Project Plan

In our work plan everything is clearly described from start and finish dates to owner of the work and given workday for the job. After every documentation finished, we had sprints. At the total we made 4 sprints. If there are any tasks which are not completed on the time, 2 extra days, which are weekends, have been reserved for the purpose of completing these tasks.

Figure 5 Work Plan of our project.

3. ENVIRONMENT

---

3.1. Modelling Environment

In our project we will use simulation to be able to test our codes. Among of many self-driving simulators. Webots is a professional mobile robot simulation software package. It offers a rapid prototyping environment, that allows the user to create 3D virtual worlds with physics properties such as mass, joints, friction coefficients, etc. [6]. We chose Webots because it is cross platform, open source, supports many languages including Python and has environment sound. It’s also provides tools as OpenStreeMap to create our own world and SUMO (Simulation of Urban MObility) interface to simulate traffic and sensors as LIDAR, radar, GPS etc. We will create emergency vehicle models in Blender and transfer them to Webots because its car assets are limited.

Figure 6 A car using LIDAR from sample Webots world.

4. REFERENCES

• This document is written in GitHub flavored Markdown.
• IEEE Std 830™-1998(R2009) Recommended Practice for Software Requirements Specifications.

[1] https://en.wikipedia.org/wiki/Emergency_vehicle
[2] https://whatis.techtarget.com/definition/system-software
[3] https://en.wikipedia.org/wiki/Control_unit
[4] https://oceanservice.noaa.gov/facts/lidar.html
[5] https://en.wikipedia.org/wiki/Global_Positioning_System
[6] https://cyberbotics.com/doc/guide/introduction-to-webots