sie 250 final report

SIE 250Project Final Report

Group 18

Traffic Signal System Design Project.

Jordan LoQisong XiaoTerry Fuller

Mohammad RabataAdan O Bracamontes

December 10, 2014

1

Traffic Signal System: Concept of Operations

Contents 1.0 Purpose of the Document……………………………………………………………………..3 2.0 Scope of the Project……………………………………………………………………………...3 3.0 Referenced Documents………………………………………………………………………...3 4.0 Background…………………………………………………………………………………………4 5.0 Concept for the Proposed System…………………………………………………………4

o Case Studyo General Design

Design 1 Design 2 Design 3

6.0 User-Oriented Operational Descriptiono Stakeholders

7.0 Operational Needs 8.0 System Overview 9.0 Operational Environment 10.0 Support Environment 11.0 Operational Scenarios 12.0 Operational Impact System Requirements

o 1.0 Input and Output Functional Requirementso 2.0 Technology Requirementso 3.0 Input and Output Performance Requirementso 4.0 Utilization of Resources Requirementso 5.0 Trade-Off Requirementso 6.0 System Test Plan

System Designs System Model Systems Engineering Management Plan

o Team Memberso Team Dynamics

Roles Scribe Meetings

2

Concept of Operations

1.0 Purpose of the DocumentThe purpose is to optimize the performance of a traffic signal control. The

system model is designed around minimizing the total cost and optimizing the input

and output functionality of the model. By integrating technology and user processes

to the traffic signal model, the following goals will be accomplished:

Minimize delay between phases within the system.

Minimize the total cost of the system.

Increase the life span longevity of the system; goal is fifteen years

2.0 Scope of the ProjectThe scope is intended to focus on Speedway Blvd. with major intersections at

Mountain, Cherry, and Campbell Avenue. These three intersections are adjacent to

each other on the north side of the University of Arizona.

3.0 Referenced DocumentsAll of the referenced documents are available on SIE 250 FA14 001 910 D2L page.

SIE 250 Traffic Signal System Design Project.pdf

Traffic Model Data

o Traffic Technology Costs

o simpletrafficmodel.slx

o Campbell.xls

o Cherry.xls

o Euclid.xls

o Mountain.xls

o Park.xls

Optimal Green Times

o ideal.Delay.4Phase.xls

3

4.0 BackgroundThe city of Tucson is looking for a system design that will help save costs

maintaining their traffic signal model without sacrificing the overall performance of

the system. The main interest is Speedway Blvd. with points at Campbell, Cherry,

and Mountain Avenue. This area of interest is highly concentrated with traffic, as it

is North of the University of Arizona and South of the University Medical Center.

5.0 Concept for the Proposed System

The proposed design is based on the current traffic model for Speedway

Blvd. and the three intersections on Cherry, Mountain, and Campbell, with different

timing and different weather conditions.

Design 1: Basic

This particular design features a basic traffic model presented at a low cost.

Constructed around time-based traffic, this model does not include any sensors for

its components.

Design 2: Camera

This design utilizes a camera to detect queue size up to 3 and only output full

green if 3 cars are detected.

Design 3: Wire Loop

This design uses wire loop to detect if a car is present in the queue if not car

is present skip that movement.

6.0 User-Oriented Operational Description

Stakeholders

University of Arizona

University of Arizona Systems and Industrial Engineering Department

Arizona Department of Transportation

City of Tucson

Tucson Electrical Power

4

Comcast Internet

7.0 Operational Needs

Control Center manages each intersection to maintain its service and

technology. Power source is needed to provide the necessary electricity for the

system to be fully operational. An open feed such as direct and wireless sensors and

transmitters are required to send and receive signals to communicate between

personnel and mechanical hardware.

8.0 System Overview

9.0 Operational Environment

The traffic system has the ability to operate in any intersection that has the

capability to interoperate with video or control loop technology.

10.0 Support Environment

If any problems persist, we encourage reaching out to our 24/7 technical

support desk that can be made available by phone, email, or chat. Our service desk

can brief upon current traffic events and reports or simply answer any general

questions.

11.0 Operational Scenarios

Use Case:

ID: 1

Brief Description:

Primary Actor:

Secondary Actors:

Pre-Condition:

Main Flow:

5

Post-Condition:

Alternative Flow:

12.0 Operational Impact

We have complete confidence that our model will deliver a more optimized

flow of traffic, while focusing primarily on minimizing the time it takes at the

intersections of Cherry, Mountain, and Campbell Avenue. The lesser amount of time

that it takes to travel through either one of these intersections, the greater traffic

efficiency will be. This can benefit Tucson’s fuel economy as well as its carbon

footprint. Without sacrificing the safety of our drivers, our system guarantees that

there will be a reduction of vehicle accidents, due to our innovating phase clearance.

This gives the driver enough time and ability to safely proceed in and out of the

intersection. There is a great deal of impact that this traffic model bring to the city

of Tucson and most importantly to its people.

System Requirements

1.0 Input and Output Functional Requirements

1.1 TSS allow a theoretical flow rate of 1,800 vehicles per hour per lane.

1.2 TSS assume a four second yellow light clearance.

1.3 TSS assume a two second all-red clearance.

1.4 TSS shall be functional 24 hours a day, seven days a week.

1.5 TSS use a base system that can be fitted for different equipment.

1.6 TSS switch time modes (AM to PM; PM to AM).

1.7 TSS accept inputs.

1.8 TSS generate output readouts.

2.0 Technology Requirements

2.1 TSS have a fixed-signal for green lights.

6

2.2 TSS have video controllers and sensors.

2.3 TSS have control loops

2.4 TSS monitor current and previous traffic activity.

2.5 TSS be monitored from the control center.

3.0 Input and Output Performance Requirements

3.1 TSS be judged on its ability to collect data in real time.

3.2 TSS maintain traffic flow in real time.

3.3 TSS perform in any weather conditions.

3.4 TSS judge the traffic phases.

3.5 TSS be judged on Mean Time Between Failures (MTBF).

4.0 Utilization of Resources Requirements

4.1 TSS be judged based on setup costs.

4.2 TSS be judged basedon maintainability cost.

4.3 TSS be judged based on operational cost.

4.4 TSS be judged based on reliability of its components.

5.0 Trade-Off Requirements

5.1 TSS be weighed 0.6 for delay and 0.4 for queue size.

5.2 TSS weigh UMP and IMP equally: 0.5IMP+0.5UMP.

6.0 System Test Plan

6.1 TSS validate and verify application architecture requirements.

6.2 TSS validate and verify application business requirements.

6.1 TSS be tested for 180 days after its installation.

System Designs

Design 1This a basic traffic signals with a fixed green for all movements, with optimal green.

7

Simulink

This is our traffic controller for the model. The traffic controller is basic.

IMPThe following table is how the system performed

Average Delay

Average Delay Score

Average Queue Score

Moutain 30.2 0.3738 0.711Cherry 40.06 0.3393 0.5979Campbell 962.9 0.1526 0.1261Total 0.288566667 0.478333333

Design 2This design uses traffic camera to pick up queue size to skip a movement if zero queue is present. The system also detects queue size up to 3. If 3 are present the full green is output. If 2 or 1 are detected the green is minimize to account for less cars in the queue. It does also depending on PM or Am Traffic. The green is also not fixed there are different greens for each movement.

Here is part of our Simulink traffic controller. You can see it detects queue size and outputs green according to queue size.

8

IMPAverage Delay

Average Delay Score

Average Queue Score


Design 3This design uses wired loop to detect if there is a car present in the queue if not it skips that movement. The green is also not fixed there are different greens for each movement.

Here is part of our Simulink model

9

IMPAverage Delay

Average Delay Score

Average Queue Score


Design Recommendation

Model 1 Model 2 Model 3Average score 0.1764 0.4989 0.433Average Queue 0.479 0.577 0.5955over 60/40 0.29744 0.53014 0.498

Through our trade-off analysis we can see that model had the best overall score.

Therefore we recommend design two using traffic cameras to detected queue

size.

10

Team Summary

Team Members

Jordan Lo

Terry Fuller

Adan O Bracamontes

Mohammad Rabata

Qisong Xiao

Team Meetings

November 14th, 2014 11:00am – 11:50am, In-class meeting

Started Traffic Model

Started Concept of Operations

Started report

Attended: Jordan, Terry, Adan, Mohammad, Qisong

November 18th, 2014 4:15pm – 7:30pm, Main Library

System model progress

Begun Traffic Model PowerPoint

Started Design Recommendation


November 21st, 2014 11:00am – 11:50am, In-class meeting

In-class meeting

System model progress

Design Recommendation progress


November 25th, 2014 6:30pm – 7:45pm, Main Library

11

System model completed

Design Recommendation completed

Prepared In-Class presentation

Report progress


November 26th, 2014 11:00am – 11:50am, In-class meeting

Presented Traffic System PowerPoint to the class


December 8th, 2014 6:00pm – 8:00pm, Science and Engineering Library

Concept of Operations completed

Report progress

Team Meeting progress


December 9th, 2014 8:00pm – 10:00pm, Science and Engineering Library

Report completed

Team Meeting completed


12